From xen-devel-bounces@lists.xen.org Mon Oct 01 00:42:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 00:42:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIU52-0006IL-He; Mon, 01 Oct 2012 00:41:52 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIU4z-0006IG-T3 for xen-devel@lists.xen.org; Mon, 01 Oct 2012 00:41:50 +0000 Received: from [85.158.139.211:22248] by server-7.bemta-5.messagelabs.com id B8/08-00431-DC6E8605; Mon, 01 Oct 2012 00:41:49 +0000 X-Env-Sender: ar16@imapmail.org X-Msg-Ref: server-6.tower-206.messagelabs.com!1349052107!20534312!1 X-Originating-IP: [66.111.4.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTExLjQuMjUgPT4gMjUzOTg=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6111 invoked from network); 1 Oct 2012 00:41:48 -0000 Received: from out1-smtp.messagingengine.com (HELO out1-smtp.messagingengine.com) (66.111.4.25) by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 00:41:48 -0000 Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 9C0C72094F for ; Sun, 30 Sep 2012 20:41:47 -0400 (EDT) Received: from web1.nyi.mail.srv.osa ([10.202.2.211]) by compute6.internal (MEProxy); Sun, 30 Sep 2012 20:41:47 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=imapmail.org; h= message-id:from:to:mime-version:content-transfer-encoding :content-type:subject:date:in-reply-to:references; s=mesmtp; bh= mt3/0xzkFht1VmT0V9mqkz1P/dQ=; b=ZpzuxE42FUA/x022UQkj6vWkGF1wWup8 40bS08mRZlg632p5ZsnhkwyLqZjHVqV9svEgaMSXXeIrxed7J8pj2jqcfSVI1FbQ KbWf4bnsVWTZD5zXTeTcnejJa23QCYlD0NV2I2kw08Di2P7TQbHsEsdzlryAI7tf 9v/byIfIb2A= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:subject:date:in-reply-to :references; s=smtpout; bh=mt3/0xzkFht1VmT0V9mqkz1P/dQ=; b=hPG6T 1GQfeFGAtU7mf7dPP0UHC1YyN34ENdHluEjlhTy0jWMMl4fAlDgBzOvToO9GCzVt uo5jOBNzz13jTHanTqgtyHKFloGdD3l4rPAnsDHH6IB6+oDO/JnmqmNUT5xEXrB5 X+rdbv1tCj5fgvACoHS3K+G2Eva7Et/25go8Ls= Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99) id 64FE5A0035D; Sun, 30 Sep 2012 20:41:47 -0400 (EDT) Message-Id: <1349052107.4228.140661134737301.34F5E5CB@webmail.messagingengine.com> X-Sasl-Enc: 4mMBejp2GVIHPFpuhQnHnvnnFwr6CbDhm4O5JdyYDUIO 1349052107 From: ar16@imapmail.org To: xen-devel@lists.xen.org MIME-Version: 1.0 X-Mailer: MessagingEngine.com Webmail Interface Date: Sun, 30 Sep 2012 17:41:47 -0700 In-Reply-To: <1348986146.22942.140661134484341.6F996F0F@webmail.messagingengine.com> References: <1348877636.5025.140661134113513.411BDE92@webmail.messagingengine.com> <1348882472.17803.140661134131069.4B02D98D@webmail.messagingengine.com> <1348986146.22942.140661134484341.6F996F0F@webmail.messagingengine.com> Subject: Re: [Xen-devel] Xen HVM Guest fails (errors) to launch on Opensuse 12.2's Xen 4.2 + 'xl' toolstack X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org hoping to provide some form of useful debug info, per 3.2. Debugging your program using Valgrind gdbserver and GDB http://valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserver i've attached, below, the output of: valgrind -v --vgdb=yes --vgdb-error=0 --track-origins=yes --trace-children=yes --leak-check=full --show-reachable=yes xl create -c /home/ar/test.cfg & the corresponding gdb session: gdb xl (gdb) target remote | /usr/lib64/valgrind/../../bin/vgdb --pid=7667 ... (gdb) continue ... (gdb) bt ... which appears to get a SIGTRAP at 101 libxl_utils.h: No such file or directory. although, ls -al /usr/include/libxl_utils.h -rw-r--r-- 1 root root 5.7K Sep 18 14:42 /usr/include/libxl_utils.h ====================================================================== valgrind -v --vgdb=yes --vgdb-error=0 --track-origins=yes --trace-children=yes --leak-check=full --show-reachable=yes xl create -c /home/ar/test.cfg ==7667== Memcheck, a memory error detector ==7667== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==7667== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==7667== Command: xl create -c /home/ar/test.cfg ==7667== --7667-- Valgrind options: --7667-- -v --7667-- --vgdb=yes --7667-- --vgdb-error=0 --7667-- --track-origins=yes --7667-- --trace-children=yes --7667-- --leak-check=full --7667-- --show-reachable=yes --7667-- Contents of /proc/version: --7667-- Linux version 3.4.6-2.10-xen (geeko@buildhost) (gcc version 4.7.1 20120723 [gcc-4_7-branch revision 189773] (SUSE Linux) ) #1 SMP Thu Jul 26 09:36:26 UTC 2012 (641c197) --7667-- Arch and hwcaps: AMD64, amd64-sse3-cx16-lzcnt --7667-- Page sizes: currently 4096, max supported 4096 --7667-- Valgrind library directory: /usr/lib64/valgrind --7667-- Reading syms from /usr/sbin/xl --7667-- Considering /usr/lib/debug/.build-id/30/a64409d9dfee58a099b01b8e833b012f11f0bd.debug .. --7667-- .. build-id is valid --7667-- Reading syms from /lib64/ld-2.15.so --7667-- Considering /usr/lib/debug/.build-id/e4/2d5feaef8b50f76c5d9011480021d8c76be03a.debug .. --7667-- .. build-id is valid --7667-- Reading syms from /usr/lib64/valgrind/memcheck-amd64-linux --7667-- Considering /usr/lib/debug/usr/lib64/valgrind/memcheck-amd64-linux.debug .. --7667-- .. CRC is valid --7667-- object doesn't have a dynamic symbol table --7667-- Scheduler: using generic scheduler lock implementation. --7667-- Reading suppressions file: /usr/lib64/valgrind/default.supp ==7667== (action at startup) vgdb me ... ==7667== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-7667-by-root-on-server ==7667== embedded gdbserver: writing to /tmp/vgdb-pipe-to-vgdb-from-7667-by-root-on-server ==7667== embedded gdbserver: shared mem /tmp/vgdb-pipe-shared-mem-vgdb-7667-by-root-on-server ==7667== ==7667== TO CONTROL THIS PROCESS USING vgdb (which you probably ==7667== don't want to do, unless you know exactly what you're doing, ==7667== or are doing some strange experiment): ==7667== /usr/lib64/valgrind/../../bin/vgdb --pid=7667 ...command... ==7667== ==7667== TO DEBUG THIS PROCESS USING GDB: start GDB like this ==7667== /path/to/gdb xl ==7667== and then give GDB the following command ==7667== target remote | /usr/lib64/valgrind/../../bin/vgdb --pid=7667 ==7667== --pid is optional if only one valgrind process is running ==7667== --7667-- REDIR: 0x4017980 (strlen) redirected to 0x3806c751 (vgPlain_amd64_linux_REDIR_FOR_strlen) --7667-- Reading syms from /usr/lib64/valgrind/vgpreload_core-amd64-linux.so --7667-- Considering /usr/lib/debug/.build-id/58/fafcae89b15a60beb5a94f5cebe506d63adbe2.debug .. --7667-- .. build-id is valid --7667-- Reading syms from /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so --7667-- Considering /usr/lib/debug/.build-id/19/a54751b3d366463830a2dcab6372e03b1cba14.debug .. --7667-- .. build-id is valid --7667-- REDIR: 0x40177f0 (index) redirected to 0x4c2c930 (index) --7667-- REDIR: 0x4017870 (strcmp) redirected to 0x4c2d940 (strcmp) --7667-- Reading syms from /usr/lib64/libxlutil.so.1.0.0 --7667-- Considering /usr/lib/debug/.build-id/57/db42dff0f5c8eaf2270b9b2c1749372e7a43eb.debug .. --7667-- .. build-id is valid --7667-- Reading syms from /usr/lib64/libxenlight.so.2.0.0 --7667-- Considering /usr/lib/debug/.build-id/c5/612d35a8a81737c65c7373b51b513aae115ead.debug .. --7667-- .. build-id is valid --7667-- Reading syms from /usr/lib64/libxenctrl.so.4.2.0 --7667-- Considering /usr/lib/debug/.build-id/b2/95761d280c399a5a6fcad017488f114c9eb134.debug .. --7667-- .. build-id is valid --7667-- Reading syms from /usr/lib64/libyajl.so.2.0.1 --7667-- Considering /usr/lib/debug/.build-id/99/9a0d33091222f1538223325db7f5e243dd63c9.debug .. --7667-- .. build-id is valid --7667-- Reading syms from /lib64/libpthread-2.15.so --7667-- Considering /usr/lib/debug/.build-id/d5/a497713b5ae7d06971fb34530b63d89a42e0af.debug .. --7667-- .. build-id is valid --7667-- Reading syms from /lib64/libc-2.15.so --7667-- Considering /usr/lib/debug/.build-id/74/a39090ae55f5852f5051263d722588db13bf55.debug .. --7667-- .. build-id is valid --7667-- Reading syms from /usr/lib64/libxenguest.so.4.2.0 --7667-- Considering /usr/lib/debug/.build-id/f0/4b4f86cb8506da6a8bfe4d5294c9f7708f8ddb.debug .. --7667-- .. build-id is valid --7667-- Reading syms from /usr/lib64/libxenstore.so.3.0.1 --7667-- Considering /usr/lib/debug/.build-id/82/5de7c92321f509c1f56f5c82de84f1391d5b16.debug .. --7667-- .. build-id is valid --7667-- Reading syms from /usr/local/lib64/libblktapctl.so.1.0.0 --7667-- Reading syms from /lib64/libutil-2.15.so --7667-- Considering /usr/lib/debug/.build-id/ff/73a066c7363459b2c6a83f8530333bacea5b53.debug .. --7667-- .. build-id is valid --7667-- Reading syms from /usr/lib64/libuuid.so.1.3.0 --7667-- Considering /usr/lib/debug/.build-id/6b/2300887663497904f5bd17e51e0f6e04849058.debug .. --7667-- .. build-id is valid --7667-- Reading syms from /lib64/libdl-2.15.so --7667-- Considering /usr/lib/debug/.build-id/d0/ec4dbdb0d7b15bb7a6454fefa923d5de1daf40.debug .. --7667-- .. build-id is valid --7667-- Reading syms from /usr/lib64/libbz2.so.1.0.6 --7667-- Considering /usr/lib/debug/.build-id/ec/1a7cb75fb00b3027653c7e44ab2ae5e1bdc323.debug .. --7667-- .. build-id is valid --7667-- Reading syms from /usr/lib64/liblzma.so.5.0.3 --7667-- Considering /usr/lib/debug/.build-id/40/ab1743eda0b177bfd7097de713d3842973ef98.debug .. --7667-- .. build-id is valid --7667-- Reading syms from /lib64/libz.so.1.2.7 --7667-- Considering /usr/lib/debug/.build-id/07/c94c65d4108bb9372f7943566cc01c54f161ca.debug .. --7667-- .. build-id is valid --7667-- REDIR: 0x596e4d0 (strncasecmp) redirected to 0x4a24750 (_vgnU_ifunc_wrapper) --7667-- REDIR: 0x5968590 (strnlen) redirected to 0x4a24750 (_vgnU_ifunc_wrapper) --7667-- REDIR: 0x596c200 (strcasecmp) redirected to 0x4a24750 (_vgnU_ifunc_wrapper) --7667-- REDIR: 0x5967e00 (strcpy) redirected to 0x4a24750 (_vgnU_ifunc_wrapper) --7667-- REDIR: 0x5968460 (strlen) redirected to 0x4a24750 (_vgnU_ifunc_wrapper) --7667-- REDIR: 0x596afe0 (memset) redirected to 0x4a24750 (_vgnU_ifunc_wrapper) --7667-- REDIR: 0x5970bb0 (memcpy@@GLIBC_2.14) redirected to 0x4a24750 (_vgnU_ifunc_wrapper) --7667-- REDIR: 0x59666b0 (strcat) redirected to 0x4a24750 (_vgnU_ifunc_wrapper) --7667-- REDIR: 0x5969f80 (__GI_strrchr) redirected to 0x4c2c750 (__GI_strrchr) --7667-- REDIR: 0x59684b0 (__GI_strlen) redirected to 0x4c2ccb0 (__GI_strlen) --7667-- REDIR: 0x5962bb0 (malloc) redirected to 0x4c2c200 (malloc) --7667-- REDIR: 0x59720f0 (strchrnul) redirected to 0x4c2f2c0 (strchrnul) --7667-- REDIR: 0x59630d0 (free) redirected to 0x4c2aef0 (free) --7667-- REDIR: 0x59dca60 (__strcpy_chk) redirected to 0x4c2f330 (__strcpy_chk) --7667-- REDIR: 0x5970c00 (__GI_memcpy) redirected to 0x4c2dc70 (memcpy@@GLIBC_2.14) --7667-- REDIR: 0x5968670 (strncmp) redirected to 0x4a24750 (_vgnU_ifunc_wrapper) --7667-- REDIR: 0x59686b0 (__GI_strncmp) redirected to 0x4c2d180 (__GI_strncmp) --7667-- REDIR: 0x59668f0 (__GI_strchr) redirected to 0x4c2c830 (__GI_strchr) --7667-- REDIR: 0x59668b0 (index) redirected to 0x4a24750 (_vgnU_ifunc_wrapper) Parsing config from /home/ar/test.cfg --7667-- REDIR: 0x5963160 (realloc) redirected to 0x4c2c400 (realloc) --7667-- REDIR: 0x5966970 (strcmp) redirected to 0x4a24750 (_vgnU_ifunc_wrapper) --7667-- REDIR: 0x59669b0 (__GI_strcmp) redirected to 0x4c2d8f0 (__GI_strcmp) --7667-- REDIR: 0xffffffffff600000 (???) redirected to 0x3806c733 (vgPlain_amd64_linux_REDIR_FOR_vgettimeofday) --7667-- REDIR: 0x5963c30 (calloc) redirected to 0x4c2a020 (calloc) --7667-- REDIR: 0x5975870 (__memset_x86_64) redirected to 0x4c2ed70 (memset) --7667-- REDIR: 0x5969f40 (rindex) redirected to 0x4a24750 (_vgnU_ifunc_wrapper) ==7667== Warning: noted but unhandled ioctl 0x305000 with no size/direction hints ==7667== This could cause spurious value errors to appear. ==7667== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. ==7667== Conditional jump or move depends on uninitialised value(s) ==7667== at 0x505FBC4: libxl__domain_build_info_setdefault (libxl_utils.h:101) ==7667== by 0x505B404: libxl_domain_need_memory (libxl.c:3514) ==7667== by 0x40CB8C: create_domain (xl_cmdimpl.c:1591) ==7667== by 0x410A60: main_create (xl_cmdimpl.c:3905) ==7667== by 0x406FFF: main (xl.c:267) ==7667== Uninitialised value was created by a stack allocation ==7667== at 0x4014225: _dl_runtime_resolve (dl-trampoline.S:43) ==7667== ==7667== (action on error) vgdb me ... ====================================================================== gdb xl GNU gdb (GDB) SUSE (7.4.50.20120603-78.5) Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-suse-linux". For bug reporting instructions, please see: ... Reading symbols from /usr/sbin/xl...Reading symbols from /usr/lib/debug/usr/sbin/xl.debug...done. done. (gdb) target remote | /usr/lib64/valgrind/../../bin/vgdb --pid=7667 Remote debugging using | /usr/lib64/valgrind/../../bin/vgdb --pid=7667 relaying data between gdb and process 7667 Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols from /usr/lib/debug/lib64/ld-2.15.so.debug...done. done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 [Switching to Thread 7667] 0x00000000040014e0 in _start () from /lib64/ld-linux-x86-64.so.2 (gdb) continue Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. 0x000000000505fbc4 in libxl_cpu_bitmap_alloc (max_cpus=6, cpumap=0x7fefff238, ctx=0x6f1e0b0) at libxl_utils.h:101 101 libxl_utils.h: No such file or directory. (gdb) bt #0 0x000000000505fbc4 in libxl_cpu_bitmap_alloc (max_cpus=6, cpumap=0x7fefff238, ctx=0x6f1e0b0) at libxl_utils.h:101 #1 libxl__domain_build_info_setdefault (gc=gc@entry=0x7fefff060, b_info=b_info@entry=0x7fefff220) at libxl_create.c:215 #2 0x000000000505b405 in libxl_domain_need_memory (ctx=, b_info=b_info@entry=0x7fefff220, need_memkb=need_memkb@entry=0x7fefff0f0) at libxl.c:3514 #3 0x000000000040cb8d in freemem (b_info=0x7fefff220) at xl_cmdimpl.c:1591 #4 create_domain (dom_info=dom_info@entry=0x7fefff4d0) at xl_cmdimpl.c:1874 #5 0x0000000000410a61 in main_create (argc=3, argv=0x7fefffac0) at xl_cmdimpl.c:3905 #6 0x0000000000407000 in main (argc=3, argv=0x7fefffac0) at xl.c:267 (gdb) ====================================================================== _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 00:42:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 00:42:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIU52-0006IL-He; Mon, 01 Oct 2012 00:41:52 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIU4z-0006IG-T3 for xen-devel@lists.xen.org; Mon, 01 Oct 2012 00:41:50 +0000 Received: from [85.158.139.211:22248] by server-7.bemta-5.messagelabs.com id B8/08-00431-DC6E8605; Mon, 01 Oct 2012 00:41:49 +0000 X-Env-Sender: ar16@imapmail.org X-Msg-Ref: server-6.tower-206.messagelabs.com!1349052107!20534312!1 X-Originating-IP: [66.111.4.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTExLjQuMjUgPT4gMjUzOTg=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6111 invoked from network); 1 Oct 2012 00:41:48 -0000 Received: from out1-smtp.messagingengine.com (HELO out1-smtp.messagingengine.com) (66.111.4.25) by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 00:41:48 -0000 Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 9C0C72094F for ; Sun, 30 Sep 2012 20:41:47 -0400 (EDT) Received: from web1.nyi.mail.srv.osa ([10.202.2.211]) by compute6.internal (MEProxy); Sun, 30 Sep 2012 20:41:47 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=imapmail.org; h= message-id:from:to:mime-version:content-transfer-encoding :content-type:subject:date:in-reply-to:references; s=mesmtp; bh= mt3/0xzkFht1VmT0V9mqkz1P/dQ=; b=ZpzuxE42FUA/x022UQkj6vWkGF1wWup8 40bS08mRZlg632p5ZsnhkwyLqZjHVqV9svEgaMSXXeIrxed7J8pj2jqcfSVI1FbQ KbWf4bnsVWTZD5zXTeTcnejJa23QCYlD0NV2I2kw08Di2P7TQbHsEsdzlryAI7tf 9v/byIfIb2A= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:subject:date:in-reply-to :references; s=smtpout; bh=mt3/0xzkFht1VmT0V9mqkz1P/dQ=; b=hPG6T 1GQfeFGAtU7mf7dPP0UHC1YyN34ENdHluEjlhTy0jWMMl4fAlDgBzOvToO9GCzVt uo5jOBNzz13jTHanTqgtyHKFloGdD3l4rPAnsDHH6IB6+oDO/JnmqmNUT5xEXrB5 X+rdbv1tCj5fgvACoHS3K+G2Eva7Et/25go8Ls= Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99) id 64FE5A0035D; Sun, 30 Sep 2012 20:41:47 -0400 (EDT) Message-Id: <1349052107.4228.140661134737301.34F5E5CB@webmail.messagingengine.com> X-Sasl-Enc: 4mMBejp2GVIHPFpuhQnHnvnnFwr6CbDhm4O5JdyYDUIO 1349052107 From: ar16@imapmail.org To: xen-devel@lists.xen.org MIME-Version: 1.0 X-Mailer: MessagingEngine.com Webmail Interface Date: Sun, 30 Sep 2012 17:41:47 -0700 In-Reply-To: <1348986146.22942.140661134484341.6F996F0F@webmail.messagingengine.com> References: <1348877636.5025.140661134113513.411BDE92@webmail.messagingengine.com> <1348882472.17803.140661134131069.4B02D98D@webmail.messagingengine.com> <1348986146.22942.140661134484341.6F996F0F@webmail.messagingengine.com> Subject: Re: [Xen-devel] Xen HVM Guest fails (errors) to launch on Opensuse 12.2's Xen 4.2 + 'xl' toolstack X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org hoping to provide some form of useful debug info, per 3.2. Debugging your program using Valgrind gdbserver and GDB http://valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserver i've attached, below, the output of: valgrind -v --vgdb=yes --vgdb-error=0 --track-origins=yes --trace-children=yes --leak-check=full --show-reachable=yes xl create -c /home/ar/test.cfg & the corresponding gdb session: gdb xl (gdb) target remote | /usr/lib64/valgrind/../../bin/vgdb --pid=7667 ... (gdb) continue ... (gdb) bt ... which appears to get a SIGTRAP at 101 libxl_utils.h: No such file or directory. although, ls -al /usr/include/libxl_utils.h -rw-r--r-- 1 root root 5.7K Sep 18 14:42 /usr/include/libxl_utils.h ====================================================================== valgrind -v --vgdb=yes --vgdb-error=0 --track-origins=yes --trace-children=yes --leak-check=full --show-reachable=yes xl create -c /home/ar/test.cfg ==7667== Memcheck, a memory error detector ==7667== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==7667== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==7667== Command: xl create -c /home/ar/test.cfg ==7667== --7667-- Valgrind options: --7667-- -v --7667-- --vgdb=yes --7667-- --vgdb-error=0 --7667-- --track-origins=yes --7667-- --trace-children=yes --7667-- --leak-check=full --7667-- --show-reachable=yes --7667-- Contents of /proc/version: --7667-- Linux version 3.4.6-2.10-xen (geeko@buildhost) (gcc version 4.7.1 20120723 [gcc-4_7-branch revision 189773] (SUSE Linux) ) #1 SMP Thu Jul 26 09:36:26 UTC 2012 (641c197) --7667-- Arch and hwcaps: AMD64, amd64-sse3-cx16-lzcnt --7667-- Page sizes: currently 4096, max supported 4096 --7667-- Valgrind library directory: /usr/lib64/valgrind --7667-- Reading syms from /usr/sbin/xl --7667-- Considering /usr/lib/debug/.build-id/30/a64409d9dfee58a099b01b8e833b012f11f0bd.debug .. --7667-- .. build-id is valid --7667-- Reading syms from /lib64/ld-2.15.so --7667-- Considering /usr/lib/debug/.build-id/e4/2d5feaef8b50f76c5d9011480021d8c76be03a.debug .. --7667-- .. build-id is valid --7667-- Reading syms from /usr/lib64/valgrind/memcheck-amd64-linux --7667-- Considering /usr/lib/debug/usr/lib64/valgrind/memcheck-amd64-linux.debug .. --7667-- .. CRC is valid --7667-- object doesn't have a dynamic symbol table --7667-- Scheduler: using generic scheduler lock implementation. --7667-- Reading suppressions file: /usr/lib64/valgrind/default.supp ==7667== (action at startup) vgdb me ... ==7667== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-7667-by-root-on-server ==7667== embedded gdbserver: writing to /tmp/vgdb-pipe-to-vgdb-from-7667-by-root-on-server ==7667== embedded gdbserver: shared mem /tmp/vgdb-pipe-shared-mem-vgdb-7667-by-root-on-server ==7667== ==7667== TO CONTROL THIS PROCESS USING vgdb (which you probably ==7667== don't want to do, unless you know exactly what you're doing, ==7667== or are doing some strange experiment): ==7667== /usr/lib64/valgrind/../../bin/vgdb --pid=7667 ...command... ==7667== ==7667== TO DEBUG THIS PROCESS USING GDB: start GDB like this ==7667== /path/to/gdb xl ==7667== and then give GDB the following command ==7667== target remote | /usr/lib64/valgrind/../../bin/vgdb --pid=7667 ==7667== --pid is optional if only one valgrind process is running ==7667== --7667-- REDIR: 0x4017980 (strlen) redirected to 0x3806c751 (vgPlain_amd64_linux_REDIR_FOR_strlen) --7667-- Reading syms from /usr/lib64/valgrind/vgpreload_core-amd64-linux.so --7667-- Considering /usr/lib/debug/.build-id/58/fafcae89b15a60beb5a94f5cebe506d63adbe2.debug .. --7667-- .. build-id is valid --7667-- Reading syms from /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so --7667-- Considering /usr/lib/debug/.build-id/19/a54751b3d366463830a2dcab6372e03b1cba14.debug .. --7667-- .. build-id is valid --7667-- REDIR: 0x40177f0 (index) redirected to 0x4c2c930 (index) --7667-- REDIR: 0x4017870 (strcmp) redirected to 0x4c2d940 (strcmp) --7667-- Reading syms from /usr/lib64/libxlutil.so.1.0.0 --7667-- Considering /usr/lib/debug/.build-id/57/db42dff0f5c8eaf2270b9b2c1749372e7a43eb.debug .. --7667-- .. build-id is valid --7667-- Reading syms from /usr/lib64/libxenlight.so.2.0.0 --7667-- Considering /usr/lib/debug/.build-id/c5/612d35a8a81737c65c7373b51b513aae115ead.debug .. --7667-- .. build-id is valid --7667-- Reading syms from /usr/lib64/libxenctrl.so.4.2.0 --7667-- Considering /usr/lib/debug/.build-id/b2/95761d280c399a5a6fcad017488f114c9eb134.debug .. --7667-- .. build-id is valid --7667-- Reading syms from /usr/lib64/libyajl.so.2.0.1 --7667-- Considering /usr/lib/debug/.build-id/99/9a0d33091222f1538223325db7f5e243dd63c9.debug .. --7667-- .. build-id is valid --7667-- Reading syms from /lib64/libpthread-2.15.so --7667-- Considering /usr/lib/debug/.build-id/d5/a497713b5ae7d06971fb34530b63d89a42e0af.debug .. --7667-- .. build-id is valid --7667-- Reading syms from /lib64/libc-2.15.so --7667-- Considering /usr/lib/debug/.build-id/74/a39090ae55f5852f5051263d722588db13bf55.debug .. --7667-- .. build-id is valid --7667-- Reading syms from /usr/lib64/libxenguest.so.4.2.0 --7667-- Considering /usr/lib/debug/.build-id/f0/4b4f86cb8506da6a8bfe4d5294c9f7708f8ddb.debug .. --7667-- .. build-id is valid --7667-- Reading syms from /usr/lib64/libxenstore.so.3.0.1 --7667-- Considering /usr/lib/debug/.build-id/82/5de7c92321f509c1f56f5c82de84f1391d5b16.debug .. --7667-- .. build-id is valid --7667-- Reading syms from /usr/local/lib64/libblktapctl.so.1.0.0 --7667-- Reading syms from /lib64/libutil-2.15.so --7667-- Considering /usr/lib/debug/.build-id/ff/73a066c7363459b2c6a83f8530333bacea5b53.debug .. --7667-- .. build-id is valid --7667-- Reading syms from /usr/lib64/libuuid.so.1.3.0 --7667-- Considering /usr/lib/debug/.build-id/6b/2300887663497904f5bd17e51e0f6e04849058.debug .. --7667-- .. build-id is valid --7667-- Reading syms from /lib64/libdl-2.15.so --7667-- Considering /usr/lib/debug/.build-id/d0/ec4dbdb0d7b15bb7a6454fefa923d5de1daf40.debug .. --7667-- .. build-id is valid --7667-- Reading syms from /usr/lib64/libbz2.so.1.0.6 --7667-- Considering /usr/lib/debug/.build-id/ec/1a7cb75fb00b3027653c7e44ab2ae5e1bdc323.debug .. --7667-- .. build-id is valid --7667-- Reading syms from /usr/lib64/liblzma.so.5.0.3 --7667-- Considering /usr/lib/debug/.build-id/40/ab1743eda0b177bfd7097de713d3842973ef98.debug .. --7667-- .. build-id is valid --7667-- Reading syms from /lib64/libz.so.1.2.7 --7667-- Considering /usr/lib/debug/.build-id/07/c94c65d4108bb9372f7943566cc01c54f161ca.debug .. --7667-- .. build-id is valid --7667-- REDIR: 0x596e4d0 (strncasecmp) redirected to 0x4a24750 (_vgnU_ifunc_wrapper) --7667-- REDIR: 0x5968590 (strnlen) redirected to 0x4a24750 (_vgnU_ifunc_wrapper) --7667-- REDIR: 0x596c200 (strcasecmp) redirected to 0x4a24750 (_vgnU_ifunc_wrapper) --7667-- REDIR: 0x5967e00 (strcpy) redirected to 0x4a24750 (_vgnU_ifunc_wrapper) --7667-- REDIR: 0x5968460 (strlen) redirected to 0x4a24750 (_vgnU_ifunc_wrapper) --7667-- REDIR: 0x596afe0 (memset) redirected to 0x4a24750 (_vgnU_ifunc_wrapper) --7667-- REDIR: 0x5970bb0 (memcpy@@GLIBC_2.14) redirected to 0x4a24750 (_vgnU_ifunc_wrapper) --7667-- REDIR: 0x59666b0 (strcat) redirected to 0x4a24750 (_vgnU_ifunc_wrapper) --7667-- REDIR: 0x5969f80 (__GI_strrchr) redirected to 0x4c2c750 (__GI_strrchr) --7667-- REDIR: 0x59684b0 (__GI_strlen) redirected to 0x4c2ccb0 (__GI_strlen) --7667-- REDIR: 0x5962bb0 (malloc) redirected to 0x4c2c200 (malloc) --7667-- REDIR: 0x59720f0 (strchrnul) redirected to 0x4c2f2c0 (strchrnul) --7667-- REDIR: 0x59630d0 (free) redirected to 0x4c2aef0 (free) --7667-- REDIR: 0x59dca60 (__strcpy_chk) redirected to 0x4c2f330 (__strcpy_chk) --7667-- REDIR: 0x5970c00 (__GI_memcpy) redirected to 0x4c2dc70 (memcpy@@GLIBC_2.14) --7667-- REDIR: 0x5968670 (strncmp) redirected to 0x4a24750 (_vgnU_ifunc_wrapper) --7667-- REDIR: 0x59686b0 (__GI_strncmp) redirected to 0x4c2d180 (__GI_strncmp) --7667-- REDIR: 0x59668f0 (__GI_strchr) redirected to 0x4c2c830 (__GI_strchr) --7667-- REDIR: 0x59668b0 (index) redirected to 0x4a24750 (_vgnU_ifunc_wrapper) Parsing config from /home/ar/test.cfg --7667-- REDIR: 0x5963160 (realloc) redirected to 0x4c2c400 (realloc) --7667-- REDIR: 0x5966970 (strcmp) redirected to 0x4a24750 (_vgnU_ifunc_wrapper) --7667-- REDIR: 0x59669b0 (__GI_strcmp) redirected to 0x4c2d8f0 (__GI_strcmp) --7667-- REDIR: 0xffffffffff600000 (???) redirected to 0x3806c733 (vgPlain_amd64_linux_REDIR_FOR_vgettimeofday) --7667-- REDIR: 0x5963c30 (calloc) redirected to 0x4c2a020 (calloc) --7667-- REDIR: 0x5975870 (__memset_x86_64) redirected to 0x4c2ed70 (memset) --7667-- REDIR: 0x5969f40 (rindex) redirected to 0x4a24750 (_vgnU_ifunc_wrapper) ==7667== Warning: noted but unhandled ioctl 0x305000 with no size/direction hints ==7667== This could cause spurious value errors to appear. ==7667== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. ==7667== Conditional jump or move depends on uninitialised value(s) ==7667== at 0x505FBC4: libxl__domain_build_info_setdefault (libxl_utils.h:101) ==7667== by 0x505B404: libxl_domain_need_memory (libxl.c:3514) ==7667== by 0x40CB8C: create_domain (xl_cmdimpl.c:1591) ==7667== by 0x410A60: main_create (xl_cmdimpl.c:3905) ==7667== by 0x406FFF: main (xl.c:267) ==7667== Uninitialised value was created by a stack allocation ==7667== at 0x4014225: _dl_runtime_resolve (dl-trampoline.S:43) ==7667== ==7667== (action on error) vgdb me ... ====================================================================== gdb xl GNU gdb (GDB) SUSE (7.4.50.20120603-78.5) Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-suse-linux". For bug reporting instructions, please see: ... Reading symbols from /usr/sbin/xl...Reading symbols from /usr/lib/debug/usr/sbin/xl.debug...done. done. (gdb) target remote | /usr/lib64/valgrind/../../bin/vgdb --pid=7667 Remote debugging using | /usr/lib64/valgrind/../../bin/vgdb --pid=7667 relaying data between gdb and process 7667 Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols from /usr/lib/debug/lib64/ld-2.15.so.debug...done. done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 [Switching to Thread 7667] 0x00000000040014e0 in _start () from /lib64/ld-linux-x86-64.so.2 (gdb) continue Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. 0x000000000505fbc4 in libxl_cpu_bitmap_alloc (max_cpus=6, cpumap=0x7fefff238, ctx=0x6f1e0b0) at libxl_utils.h:101 101 libxl_utils.h: No such file or directory. (gdb) bt #0 0x000000000505fbc4 in libxl_cpu_bitmap_alloc (max_cpus=6, cpumap=0x7fefff238, ctx=0x6f1e0b0) at libxl_utils.h:101 #1 libxl__domain_build_info_setdefault (gc=gc@entry=0x7fefff060, b_info=b_info@entry=0x7fefff220) at libxl_create.c:215 #2 0x000000000505b405 in libxl_domain_need_memory (ctx=, b_info=b_info@entry=0x7fefff220, need_memkb=need_memkb@entry=0x7fefff0f0) at libxl.c:3514 #3 0x000000000040cb8d in freemem (b_info=0x7fefff220) at xl_cmdimpl.c:1591 #4 create_domain (dom_info=dom_info@entry=0x7fefff4d0) at xl_cmdimpl.c:1874 #5 0x0000000000410a61 in main_create (argc=3, argv=0x7fefffac0) at xl_cmdimpl.c:3905 #6 0x0000000000407000 in main (argc=3, argv=0x7fefffac0) at xl.c:267 (gdb) ====================================================================== _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 02:01:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 02:01:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIVJY-0003cp-Ib; Mon, 01 Oct 2012 02:00:56 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIVJX-0003ck-KM for xen-devel@lists.xen.org; Mon, 01 Oct 2012 02:00:55 +0000 Received: from [85.158.137.99:8522] by server-15.bemta-3.messagelabs.com id B0/CC-18313-659F8605; Mon, 01 Oct 2012 02:00:54 +0000 X-Env-Sender: ar16@imapmail.org X-Msg-Ref: server-4.tower-217.messagelabs.com!1349056853!19729678!1 X-Originating-IP: [66.111.4.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTExLjQuMjUgPT4gMjUzOTg=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19976 invoked from network); 1 Oct 2012 02:00:54 -0000 Received: from out1-smtp.messagingengine.com (HELO out1-smtp.messagingengine.com) (66.111.4.25) by server-4.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 02:00:54 -0000 Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 0EF3C202FA for ; Sun, 30 Sep 2012 22:00:53 -0400 (EDT) Received: from web1.nyi.mail.srv.osa ([10.202.2.211]) by compute3.internal (MEProxy); Sun, 30 Sep 2012 22:00:53 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=imapmail.org; h= message-id:from:to:mime-version:content-transfer-encoding :content-type:subject:date:in-reply-to:references; s=mesmtp; bh= C+fgoikiQRoLva6zDERiZncDZKg=; b=d7PTPI/EDVm//Wsg7LazlmFh6VH4Q9Hj f0fbOpolgUOU0vdjx8EWdY0nGXN4rcJ2zLPGiQcLCGYIVzoorblUteQzUyXNgqCy fauqRWSA71qBa2wQqY5r2SMLDQllKjfGXCn/qc2VmQN3f4imWJn0WUJW+XgpCw8d ITLx11YFHlE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:subject:date:in-reply-to :references; s=smtpout; bh=C+fgoikiQRoLva6zDERiZncDZKg=; b=s5kiS BBS/qnlWmg00+BCoYMZcDVNWhDz2CgvqVLnZdD7mXxUCcItLjfzdt52rbI/B5/JX 0MJ2f64psKbrN9QXVMkM+7Qe0/peRRepk/7BaNysEIyZtb1li5NTwGPbfcjmdPqJ wKYsYUaJ5GG24LWzKp0I2hqsFjL7UQz+3f01Yo= Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99) id CBA5FA00218; Sun, 30 Sep 2012 22:00:52 -0400 (EDT) Message-Id: <1349056852.17264.140661134755737.289CBC17@webmail.messagingengine.com> X-Sasl-Enc: Gs2lMGguiZyVlMuX8xqJ2URvNkLQ3+I0bjhFdEDjhEx0 1349056852 From: ar16@imapmail.org To: xen-devel@lists.xen.org MIME-Version: 1.0 X-Mailer: MessagingEngine.com Webmail Interface Date: Sun, 30 Sep 2012 19:00:52 -0700 In-Reply-To: <1349052107.4228.140661134737301.34F5E5CB@webmail.messagingengine.com> References: <1348877636.5025.140661134113513.411BDE92@webmail.messagingengine.com> <1348882472.17803.140661134131069.4B02D98D@webmail.messagingengine.com> <1348986146.22942.140661134484341.6F996F0F@webmail.messagingengine.com> <1349052107.4228.140661134737301.34F5E5CB@webmail.messagingengine.com> Subject: Re: [Xen-devel] Xen HVM Guest fails (errors) to launch on Opensuse 12.2's Xen 4.2 + 'xl' toolstack X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Sun, Sep 30, 2012, at 05:41 PM, ar16@imapmail.org wrote: > 101 libxl_utils.h: No such file or directory. looking in a xen source tree cd src/xen-4.2-testing.hg grep libxl_utils `grep -rlni "libxl__domain_build_info_setdefault" tools/` tools/libxl/libxl_internal.h:#include "libxl_utils.h" cat tools/libxl/libxl_internal.h ... #define _protected #endif #include "flexarray.h" 76 #include "libxl_utils.h" #include "libxl_json.h" ... given, ls -1 /usr/include/libxl_* /usr/include/libxl_event.h /usr/include/libxl_json.h /usr/include/libxl_utils.h /usr/include/libxl_uuid.h should that not be: - #include "libxl_utils.h" + #include - #include "libxl_json.h" + #include ? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 02:01:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 02:01:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIVJY-0003cp-Ib; Mon, 01 Oct 2012 02:00:56 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIVJX-0003ck-KM for xen-devel@lists.xen.org; Mon, 01 Oct 2012 02:00:55 +0000 Received: from [85.158.137.99:8522] by server-15.bemta-3.messagelabs.com id B0/CC-18313-659F8605; Mon, 01 Oct 2012 02:00:54 +0000 X-Env-Sender: ar16@imapmail.org X-Msg-Ref: server-4.tower-217.messagelabs.com!1349056853!19729678!1 X-Originating-IP: [66.111.4.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTExLjQuMjUgPT4gMjUzOTg=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19976 invoked from network); 1 Oct 2012 02:00:54 -0000 Received: from out1-smtp.messagingengine.com (HELO out1-smtp.messagingengine.com) (66.111.4.25) by server-4.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 02:00:54 -0000 Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 0EF3C202FA for ; Sun, 30 Sep 2012 22:00:53 -0400 (EDT) Received: from web1.nyi.mail.srv.osa ([10.202.2.211]) by compute3.internal (MEProxy); Sun, 30 Sep 2012 22:00:53 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=imapmail.org; h= message-id:from:to:mime-version:content-transfer-encoding :content-type:subject:date:in-reply-to:references; s=mesmtp; bh= C+fgoikiQRoLva6zDERiZncDZKg=; b=d7PTPI/EDVm//Wsg7LazlmFh6VH4Q9Hj f0fbOpolgUOU0vdjx8EWdY0nGXN4rcJ2zLPGiQcLCGYIVzoorblUteQzUyXNgqCy fauqRWSA71qBa2wQqY5r2SMLDQllKjfGXCn/qc2VmQN3f4imWJn0WUJW+XgpCw8d ITLx11YFHlE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:subject:date:in-reply-to :references; s=smtpout; bh=C+fgoikiQRoLva6zDERiZncDZKg=; b=s5kiS BBS/qnlWmg00+BCoYMZcDVNWhDz2CgvqVLnZdD7mXxUCcItLjfzdt52rbI/B5/JX 0MJ2f64psKbrN9QXVMkM+7Qe0/peRRepk/7BaNysEIyZtb1li5NTwGPbfcjmdPqJ wKYsYUaJ5GG24LWzKp0I2hqsFjL7UQz+3f01Yo= Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99) id CBA5FA00218; Sun, 30 Sep 2012 22:00:52 -0400 (EDT) Message-Id: <1349056852.17264.140661134755737.289CBC17@webmail.messagingengine.com> X-Sasl-Enc: Gs2lMGguiZyVlMuX8xqJ2URvNkLQ3+I0bjhFdEDjhEx0 1349056852 From: ar16@imapmail.org To: xen-devel@lists.xen.org MIME-Version: 1.0 X-Mailer: MessagingEngine.com Webmail Interface Date: Sun, 30 Sep 2012 19:00:52 -0700 In-Reply-To: <1349052107.4228.140661134737301.34F5E5CB@webmail.messagingengine.com> References: <1348877636.5025.140661134113513.411BDE92@webmail.messagingengine.com> <1348882472.17803.140661134131069.4B02D98D@webmail.messagingengine.com> <1348986146.22942.140661134484341.6F996F0F@webmail.messagingengine.com> <1349052107.4228.140661134737301.34F5E5CB@webmail.messagingengine.com> Subject: Re: [Xen-devel] Xen HVM Guest fails (errors) to launch on Opensuse 12.2's Xen 4.2 + 'xl' toolstack X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Sun, Sep 30, 2012, at 05:41 PM, ar16@imapmail.org wrote: > 101 libxl_utils.h: No such file or directory. looking in a xen source tree cd src/xen-4.2-testing.hg grep libxl_utils `grep -rlni "libxl__domain_build_info_setdefault" tools/` tools/libxl/libxl_internal.h:#include "libxl_utils.h" cat tools/libxl/libxl_internal.h ... #define _protected #endif #include "flexarray.h" 76 #include "libxl_utils.h" #include "libxl_json.h" ... given, ls -1 /usr/include/libxl_* /usr/include/libxl_event.h /usr/include/libxl_json.h /usr/include/libxl_utils.h /usr/include/libxl_uuid.h should that not be: - #include "libxl_utils.h" + #include - #include "libxl_json.h" + #include ? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 04:47:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 04:47:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIXuH-00028T-BS; Mon, 01 Oct 2012 04:47:01 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIXuF-00028O-38 for xen-devel@lists.xensource.com; Mon, 01 Oct 2012 04:46:59 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1349066812!12952053!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI1NTM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7529 invoked from network); 1 Oct 2012 04:46:52 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 04:46:52 -0000 X-IronPort-AV: E=Sophos;i="4.80,514,1344211200"; d="scan'208";a="14857646" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 04:46:51 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 05:46:51 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TIXu6-0004vo-Tw; Mon, 01 Oct 2012 04:46:50 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1TIXu4-0005yF-Fk; Mon, 01 Oct 2012 05:46:48 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Mon, 1 Oct 2012 05:46:48 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 13904: tolerable FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 13904 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13904/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 5 xen-boot fail like 13903 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail like 13903 test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail like 13903 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail like 13903 Tests which did not succeed, but are not blocking: test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: xen bd953fda6106 baseline version: xen bd953fda6106 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-amd64-amd64-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 04:47:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 04:47:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIXuH-00028T-BS; Mon, 01 Oct 2012 04:47:01 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIXuF-00028O-38 for xen-devel@lists.xensource.com; Mon, 01 Oct 2012 04:46:59 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1349066812!12952053!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI1NTM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7529 invoked from network); 1 Oct 2012 04:46:52 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 04:46:52 -0000 X-IronPort-AV: E=Sophos;i="4.80,514,1344211200"; d="scan'208";a="14857646" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 04:46:51 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 05:46:51 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TIXu6-0004vo-Tw; Mon, 01 Oct 2012 04:46:50 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1TIXu4-0005yF-Fk; Mon, 01 Oct 2012 05:46:48 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Mon, 1 Oct 2012 05:46:48 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 13904: tolerable FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 13904 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13904/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 5 xen-boot fail like 13903 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail like 13903 test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail like 13903 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail like 13903 Tests which did not succeed, but are not blocking: test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: xen bd953fda6106 baseline version: xen bd953fda6106 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-amd64-amd64-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 06:43:24 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 06:43:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIZhj-00037r-Aa; Mon, 01 Oct 2012 06:42:11 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIZgT-00037d-ST for Xen-devel@lists.xen.org; Mon, 01 Oct 2012 06:42:09 +0000 Received: from [85.158.143.35:52644] by server-2.bemta-4.messagelabs.com id F3/CC-06610-91839605; Mon, 01 Oct 2012 06:28:41 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-11.tower-21.messagelabs.com!1349072920!13686168!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MjE2NjI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20554 invoked from network); 1 Oct 2012 06:28:40 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-11.tower-21.messagelabs.com with SMTP; 1 Oct 2012 06:28:40 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id F37112842; Mon, 1 Oct 2012 09:22:33 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 23FB32005D; Mon, 1 Oct 2012 09:22:33 +0300 (EEST) Date: Mon, 1 Oct 2012 09:22:32 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Valtteri Kiviniemi Message-ID: <20121001062232.GV8912@reaktio.net> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.0.4, kernel 3.5.0 HVM crash and kernel BUG X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Sun, Sep 30, 2012 at 11:18:03PM +0300, Valtteri Kiviniemi wrote: > Hi, > Hello, > I'm trying to get Windows Server 2008 R2 installation booting on Xen > 4.0.4. Using the following config: > > > The domU will start booting just fine, but after a few minutes the VNC > screen goes black. After that when typing "xm destroy ts" it will trigger > a kernel BUG: > > BUG: unable to handle kernel NULL pointer dereference at 0000000000000030 > IP: [] iput+0x3e/0x195 > PGD 0 > Oops: 0000 [#1] SMP > CPU 6 > Pid: 3571, comm: qemu-dm Not tainted 3.5.0-dom0 #1 First of all upgrade to latest 3.5.x Linux kernel release .. so at least 3.5.4. -- Pasi > /DQ77MK > RIP: e030:[] [] iput+0x3e/0x195 > RSP: e02b:ffff8800389ffbf8 EFLAGS: 00010246 > RAX: 0000000000000001 RBX: ffff8800377b0720 RCX: ffff8800501c0000 > RDX: ffff8800501c0000 RSI: ffff8800377b0790 RDI: ffff8800377b0790 > RBP: 0000000000000000 R08: ffffffff815cdd00 R09: 0000000000000016 > R10: fefefefefefefeff R11: ffff8800377b0400 R12: 00000001000a3e0c > R13: 0000000000000000 R14: 00000001000a3e0c R15: ffff8800389ffc28 > FS: 00007f1af70a8700(0000) GS:ffff880050180000(0000) > knlGS:0000000000000000 > CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b > CR2: 0000000000000030 CR3: 000000000156d000 CR4: 0000000000002660 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > Process qemu-dm (pid: 3571, threadinfo ffff8800389fe000, task > ffff88003a721260) > Stack: > ffff88003a6d6400 ffff8800377b0000 00000001000a3e0c ffffffff8133ce8f > ffff8800377b0400 ffffffff8134b6cd ffff8800389ffc28 ffff8800389ffc28 > ffff8800377b00f8 ffff8800377b0680 ffff880038cdcd60 ffff8800377b0000 > Call Trace: > [] ? sk_release_kernel+0x23/0x39 > [] ? netdev_run_todo+0x1e9/0x206 > [] ? tun_chr_close+0x4c/0x7b > [] ? fput+0xe4/0x1c5 > [] ? filp_close+0x61/0x68 > [] ? put_files_struct+0x62/0xb9 > [] ? do_exit+0x24a/0x74c > [] ? do_group_exit+0x6b/0x9d > [] ? get_signal_to_deliver+0x449/0x46e > [] ? do_signal+0x28/0x4c4 > [] ? pvclock_clocksource_read+0x48/0xbf > [] ? ktime_get_ts+0x66/0xa8 > [] ? poll_select_copy_remaining+0xe0/0xf5 > [] ? do_notify_resume+0x3b/0x74 > [] ? int_signal+0x12/0x17 > Code: 00 00 00 40 74 02 0f 0b 48 8d 77 70 48 8d bf 08 01 00 00 e8 8b 71 10 > 00 85 c0 0f 84 5d 01 00 00 48 8b 6b 18 f6 83 80 00 00 00 08 <4c> 8b 65 30 > 74 11 be 68 05 00 00 48 c7 c7 8e df 4f 81 e8 bb d0 > RIP [] iput+0x3e/0x195 > RSP > CR2: 0000000000000030 > ---[ end trace 67cc1654658fedcc ]--- > Fixing recursive fault but reboot is needed! > > I also tested Xen 4.2.0 and problem is the same. So is this a Xen bug or a > kernel bug? I am running vanilla [1]kernel.org kernel 3.5.0 and my > hardware is Intel Core i7-3770 CPU and Intel DQ77MK motherboard with > latest bios. > > Best regards, > Valtteri Kiviniemi > > References > > Visible links > 1. http://kernel.org/ > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 06:43:24 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 06:43:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIZhj-00037r-Aa; Mon, 01 Oct 2012 06:42:11 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIZgT-00037d-ST for Xen-devel@lists.xen.org; Mon, 01 Oct 2012 06:42:09 +0000 Received: from [85.158.143.35:52644] by server-2.bemta-4.messagelabs.com id F3/CC-06610-91839605; Mon, 01 Oct 2012 06:28:41 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-11.tower-21.messagelabs.com!1349072920!13686168!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MjE2NjI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20554 invoked from network); 1 Oct 2012 06:28:40 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-11.tower-21.messagelabs.com with SMTP; 1 Oct 2012 06:28:40 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id F37112842; Mon, 1 Oct 2012 09:22:33 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 23FB32005D; Mon, 1 Oct 2012 09:22:33 +0300 (EEST) Date: Mon, 1 Oct 2012 09:22:32 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Valtteri Kiviniemi Message-ID: <20121001062232.GV8912@reaktio.net> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.0.4, kernel 3.5.0 HVM crash and kernel BUG X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Sun, Sep 30, 2012 at 11:18:03PM +0300, Valtteri Kiviniemi wrote: > Hi, > Hello, > I'm trying to get Windows Server 2008 R2 installation booting on Xen > 4.0.4. Using the following config: > > > The domU will start booting just fine, but after a few minutes the VNC > screen goes black. After that when typing "xm destroy ts" it will trigger > a kernel BUG: > > BUG: unable to handle kernel NULL pointer dereference at 0000000000000030 > IP: [] iput+0x3e/0x195 > PGD 0 > Oops: 0000 [#1] SMP > CPU 6 > Pid: 3571, comm: qemu-dm Not tainted 3.5.0-dom0 #1 First of all upgrade to latest 3.5.x Linux kernel release .. so at least 3.5.4. -- Pasi > /DQ77MK > RIP: e030:[] [] iput+0x3e/0x195 > RSP: e02b:ffff8800389ffbf8 EFLAGS: 00010246 > RAX: 0000000000000001 RBX: ffff8800377b0720 RCX: ffff8800501c0000 > RDX: ffff8800501c0000 RSI: ffff8800377b0790 RDI: ffff8800377b0790 > RBP: 0000000000000000 R08: ffffffff815cdd00 R09: 0000000000000016 > R10: fefefefefefefeff R11: ffff8800377b0400 R12: 00000001000a3e0c > R13: 0000000000000000 R14: 00000001000a3e0c R15: ffff8800389ffc28 > FS: 00007f1af70a8700(0000) GS:ffff880050180000(0000) > knlGS:0000000000000000 > CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b > CR2: 0000000000000030 CR3: 000000000156d000 CR4: 0000000000002660 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > Process qemu-dm (pid: 3571, threadinfo ffff8800389fe000, task > ffff88003a721260) > Stack: > ffff88003a6d6400 ffff8800377b0000 00000001000a3e0c ffffffff8133ce8f > ffff8800377b0400 ffffffff8134b6cd ffff8800389ffc28 ffff8800389ffc28 > ffff8800377b00f8 ffff8800377b0680 ffff880038cdcd60 ffff8800377b0000 > Call Trace: > [] ? sk_release_kernel+0x23/0x39 > [] ? netdev_run_todo+0x1e9/0x206 > [] ? tun_chr_close+0x4c/0x7b > [] ? fput+0xe4/0x1c5 > [] ? filp_close+0x61/0x68 > [] ? put_files_struct+0x62/0xb9 > [] ? do_exit+0x24a/0x74c > [] ? do_group_exit+0x6b/0x9d > [] ? get_signal_to_deliver+0x449/0x46e > [] ? do_signal+0x28/0x4c4 > [] ? pvclock_clocksource_read+0x48/0xbf > [] ? ktime_get_ts+0x66/0xa8 > [] ? poll_select_copy_remaining+0xe0/0xf5 > [] ? do_notify_resume+0x3b/0x74 > [] ? int_signal+0x12/0x17 > Code: 00 00 00 40 74 02 0f 0b 48 8d 77 70 48 8d bf 08 01 00 00 e8 8b 71 10 > 00 85 c0 0f 84 5d 01 00 00 48 8b 6b 18 f6 83 80 00 00 00 08 <4c> 8b 65 30 > 74 11 be 68 05 00 00 48 c7 c7 8e df 4f 81 e8 bb d0 > RIP [] iput+0x3e/0x195 > RSP > CR2: 0000000000000030 > ---[ end trace 67cc1654658fedcc ]--- > Fixing recursive fault but reboot is needed! > > I also tested Xen 4.2.0 and problem is the same. So is this a Xen bug or a > kernel bug? I am running vanilla [1]kernel.org kernel 3.5.0 and my > hardware is Intel Core i7-3770 CPU and Intel DQ77MK motherboard with > latest bios. > > Best regards, > Valtteri Kiviniemi > > References > > Visible links > 1. http://kernel.org/ > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 08:39:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 08:39:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIbWk-0004sH-KF; Mon, 01 Oct 2012 08:38:58 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIbWj-0004sC-Bm for xen-devel@lists.xen.org; Mon, 01 Oct 2012 08:38:57 +0000 Received: from [85.158.139.83:41533] by server-9.bemta-5.messagelabs.com id EB/95-14846-0A659605; Mon, 01 Oct 2012 08:38:56 +0000 X-Env-Sender: Paul.Durrant@citrix.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1349080736!32285557!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI1NTM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18197 invoked from network); 1 Oct 2012 08:38:56 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 08:38:56 -0000 X-IronPort-AV: E=Sophos;i="4.80,514,1344211200"; d="scan'208";a="14862133" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 08:38:15 +0000 Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Mon, 1 Oct 2012 09:38:14 +0100 From: Paul Durrant To: Ian Jackson Date: Mon, 1 Oct 2012 09:38:15 +0100 Thread-Topic: [Xen-devel] [PATCH] Use new Xen public header for product numbers and names Thread-Index: Ac2dopgO3+oHbUUbQIyOUGlEiA+jNACDUoDQ Message-ID: <291EDFCB1E9E224A99088639C4762022EFF91D9EE4@LONPMAILBOX01.citrite.net> References: <1348667684-29202-1-git-send-email-paul.durrant@citrix.com> <20581.58542.402088.878499@mariner.uk.xensource.com> In-Reply-To: <20581.58542.402088.878499@mariner.uk.xensource.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] Use new Xen public header for product numbers and names X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > -----Original Message----- > From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com] > Sent: 28 September 2012 18:56 > To: Paul Durrant > Cc: xen-devel@lists.xen.org > Subject: Re: [Xen-devel] [PATCH] Use new Xen public header for product > numbers and names > > Paul Durrant writes ("[Xen-devel] [PATCH] Use new Xen public header for > product numbers and names"): > > xen/include/public/hvm/pvdrivers.h has been added as the register of > > product numbers used by the blacklisting protocol. > > Use the definitions therein rather then locally coded values. > > This approach duplicates the list as is IMO not acceptable: > > > + case PVDRIVERS_XENSOURCE_WINDOWS_ID: > > + product = PVDRIVERS_XENSOURCE_WINDOWS_NAME; > > + break; > > + case PVDRIVERS_GPLPV_WINDOWS_ID: > > + product = PVDRIVERS_GPLPV_WINDOWS_NAME; > > + break; > > + case PVDRIVERS_LINUX_ID: > > + product = PVDRIVERS_LINUX_NAME; > > + break; > > + case PVDRIVERS_EXPERIMENTAL_ID: > > + product = PVDRIVERS_EXPERIMENTAL_NAME; > > + break; > > We need to avoid this formulaic code which needs changing every time a > new entry is added. > Ok. I'll come up with something we can use to define an array and then we can iterate over that. Paul _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 08:39:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 08:39:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIbWk-0004sH-KF; Mon, 01 Oct 2012 08:38:58 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIbWj-0004sC-Bm for xen-devel@lists.xen.org; Mon, 01 Oct 2012 08:38:57 +0000 Received: from [85.158.139.83:41533] by server-9.bemta-5.messagelabs.com id EB/95-14846-0A659605; Mon, 01 Oct 2012 08:38:56 +0000 X-Env-Sender: Paul.Durrant@citrix.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1349080736!32285557!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI1NTM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18197 invoked from network); 1 Oct 2012 08:38:56 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 08:38:56 -0000 X-IronPort-AV: E=Sophos;i="4.80,514,1344211200"; d="scan'208";a="14862133" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 08:38:15 +0000 Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Mon, 1 Oct 2012 09:38:14 +0100 From: Paul Durrant To: Ian Jackson Date: Mon, 1 Oct 2012 09:38:15 +0100 Thread-Topic: [Xen-devel] [PATCH] Use new Xen public header for product numbers and names Thread-Index: Ac2dopgO3+oHbUUbQIyOUGlEiA+jNACDUoDQ Message-ID: <291EDFCB1E9E224A99088639C4762022EFF91D9EE4@LONPMAILBOX01.citrite.net> References: <1348667684-29202-1-git-send-email-paul.durrant@citrix.com> <20581.58542.402088.878499@mariner.uk.xensource.com> In-Reply-To: <20581.58542.402088.878499@mariner.uk.xensource.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] Use new Xen public header for product numbers and names X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > -----Original Message----- > From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com] > Sent: 28 September 2012 18:56 > To: Paul Durrant > Cc: xen-devel@lists.xen.org > Subject: Re: [Xen-devel] [PATCH] Use new Xen public header for product > numbers and names > > Paul Durrant writes ("[Xen-devel] [PATCH] Use new Xen public header for > product numbers and names"): > > xen/include/public/hvm/pvdrivers.h has been added as the register of > > product numbers used by the blacklisting protocol. > > Use the definitions therein rather then locally coded values. > > This approach duplicates the list as is IMO not acceptable: > > > + case PVDRIVERS_XENSOURCE_WINDOWS_ID: > > + product = PVDRIVERS_XENSOURCE_WINDOWS_NAME; > > + break; > > + case PVDRIVERS_GPLPV_WINDOWS_ID: > > + product = PVDRIVERS_GPLPV_WINDOWS_NAME; > > + break; > > + case PVDRIVERS_LINUX_ID: > > + product = PVDRIVERS_LINUX_NAME; > > + break; > > + case PVDRIVERS_EXPERIMENTAL_ID: > > + product = PVDRIVERS_EXPERIMENTAL_NAME; > > + break; > > We need to avoid this formulaic code which needs changing every time a > new entry is added. > Ok. I'll come up with something we can use to define an array and then we can iterate over that. Paul _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 09:40:42 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 09:40:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIcTz-0005Fd-Lh; Mon, 01 Oct 2012 09:40:11 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with smtp (Exim 4.72) (envelope-from ) id 1TIcTy-0005FV-T6 for xen-devel@lists.xensource.com; Mon, 01 Oct 2012 09:40:11 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1349084404!5304672!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25286 invoked from network); 1 Oct 2012 09:40:05 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-7.tower-27.messagelabs.com with SMTP; 1 Oct 2012 09:40:05 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 01 Oct 2012 10:40:04 +0100 Message-Id: <50698111020000780009EB2E@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Mon, 01 Oct 2012 10:40:01 +0100 From: "Jan Beulich" To: "Daniel Kiper" , "Konrad Rzeszutek Wilk" References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-2-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-3-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-4-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-5-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-6-git-send-email-daniel.kiper@oracle.com> <20120928162132.GC16262@localhost.localdomain> In-Reply-To: <20120928162132.GC16262@localhost.localdomain> Mime-Version: 1.0 Content-Disposition: inline Cc: andrew.cooper3@citrix.com, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org Subject: Re: [Xen-devel] [PATCH 05/11] x86/xen: Register resources required by kexec-tools X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 28.09.12 at 18:21, Konrad Rzeszutek Wilk wrote: > On Thu, Sep 27, 2012 at 08:06:32PM +0200, Daniel Kiper wrote: >> + for (i = 0; i < cpus; ++i) { > > Any specific reason for using '++i' instead of 'i++' ? For people occasionally also writing C++ code this is the canonical form. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 09:40:42 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 09:40:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIcTz-0005Fd-Lh; Mon, 01 Oct 2012 09:40:11 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with smtp (Exim 4.72) (envelope-from ) id 1TIcTy-0005FV-T6 for xen-devel@lists.xensource.com; Mon, 01 Oct 2012 09:40:11 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1349084404!5304672!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25286 invoked from network); 1 Oct 2012 09:40:05 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-7.tower-27.messagelabs.com with SMTP; 1 Oct 2012 09:40:05 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 01 Oct 2012 10:40:04 +0100 Message-Id: <50698111020000780009EB2E@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Mon, 01 Oct 2012 10:40:01 +0100 From: "Jan Beulich" To: "Daniel Kiper" , "Konrad Rzeszutek Wilk" References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-2-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-3-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-4-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-5-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-6-git-send-email-daniel.kiper@oracle.com> <20120928162132.GC16262@localhost.localdomain> In-Reply-To: <20120928162132.GC16262@localhost.localdomain> Mime-Version: 1.0 Content-Disposition: inline Cc: andrew.cooper3@citrix.com, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org Subject: Re: [Xen-devel] [PATCH 05/11] x86/xen: Register resources required by kexec-tools X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 28.09.12 at 18:21, Konrad Rzeszutek Wilk wrote: > On Thu, Sep 27, 2012 at 08:06:32PM +0200, Daniel Kiper wrote: >> + for (i = 0; i < cpus; ++i) { > > Any specific reason for using '++i' instead of 'i++' ? For people occasionally also writing C++ code this is the canonical form. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 09:42:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 09:42:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIcVr-0005KG-5h; Mon, 01 Oct 2012 09:42:07 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIcVq-0005K7-2h for xen-devel@lists.xen.org; Mon, 01 Oct 2012 09:42:06 +0000 X-Env-Sender: Paul.Durrant@citrix.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1349084511!11021275!3 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzI5Nzc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6196 invoked from network); 1 Oct 2012 09:41:54 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 09:41:54 -0000 X-IronPort-AV: E=Sophos;i="4.80,514,1344211200"; d="scan'208";a="39704057" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 09:41:35 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 05:41:35 -0400 Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=pauldu) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TIcVL-0006W8-6a; Mon, 01 Oct 2012 10:41:35 +0100 From: Paul Durrant To: xen-devel@lists.xen.org Date: Mon, 1 Oct 2012 10:41:30 +0100 Message-ID: <1349084491-13027-2-git-send-email-paul.durrant@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1349084491-13027-1-git-send-email-paul.durrant@citrix.com> References: <1349084491-13027-1-git-send-email-paul.durrant@citrix.com> MIME-Version: 1.0 Cc: Paul Durrant Subject: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as the register of product numbers. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org These product numbers are used by the QEMU blacklisting protocol in traditional QEMU and are currently coded directly into the xenstore.c source module. Since there are now multiple QEMUs this information should be pulled into a public header to avoid duplication/conflict. hvm-emulated-unplug.markdown has also been adjusted to reference the new header. Signed-off-by: Paul Durrant --- docs/misc/hvm-emulated-unplug.markdown | 2 +- xen/include/public/hvm/pvdrivers.h | 47 ++++++++++++++++++++++++++++++++ 2 files changed, 48 insertions(+), 1 deletions(-) create mode 100644 xen/include/public/hvm/pvdrivers.h diff --git a/docs/misc/hvm-emulated-unplug.markdown b/docs/misc/hvm-emulated-unplug.markdown index 707fbab..ec9ce83 100644 --- a/docs/misc/hvm-emulated-unplug.markdown +++ b/docs/misc/hvm-emulated-unplug.markdown @@ -65,4 +65,4 @@ decimal number. `{product_name}` is a string corresponding to the product number in step 3. The master registry of product names and numbers is in -qemu-xen-unstable's xenstore.c. +xen/include/public/hvm/pvdrivers.h diff --git a/xen/include/public/hvm/pvdrivers.h b/xen/include/public/hvm/pvdrivers.h new file mode 100644 index 0000000..13bf57b --- /dev/null +++ b/xen/include/public/hvm/pvdrivers.h @@ -0,0 +1,47 @@ +/* + * pvdrivers.h: Register of PV drivers product numbers. + * Copyright (c) 2012, Citrix Systems Inc. + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the "Software"), to + * deal in the Software without restriction, including without limitation the + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or + * sell copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER + * DEALINGS IN THE SOFTWARE. + */ + +#ifndef _XEN_PUBLIC_PVDRIVERS_H_ +#define _XEN_PUBLIC_PVDRIVERS_H_ + +/* + * This is the master registry of product numbers for + * PV drivers. + * If you need a new product number allocating, please + * post to xen-devel@lists.xensource.com. You should NOT use + * a product number without allocating one. + * If you maintain a separate versioning and distribution path + * for PV drivers you should have a separate product number so + * that your drivers can be separated from others. + * + * During development, you may use the product ID to + * indicate a driver which is yet to be released. + */ + +#define PVDRIVERS_PRODUCT_LIST(EACH) \ + EACH("xensource-windows", 0x0001) /* Citrix */ \ + EACH("gplpv-windows", 0x0002) /* James Harper */ \ + EACH("experimental", 0xffff) \ + EACH(NULL, 0x0000) /* terminator */ + +#endif /* _XEN_PUBLIC_PVDRIVERS_H_ */ -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 09:42:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 09:42:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIcVu-0005Kn-T6; Mon, 01 Oct 2012 09:42:10 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIcVt-0005KA-AD for xen-devel@lists.xen.org; Mon, 01 Oct 2012 09:42:09 +0000 X-Env-Sender: Paul.Durrant@citrix.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1349084511!11021275!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzI5Nzc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5945 invoked from network); 1 Oct 2012 09:41:52 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 09:41:52 -0000 X-IronPort-AV: E=Sophos;i="4.80,514,1344211200"; d="scan'208";a="39704055" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 09:41:35 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 05:41:35 -0400 Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=pauldu) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TIcVL-0006W8-4p; Mon, 01 Oct 2012 10:41:35 +0100 From: Paul Durrant To: xen-devel@lists.xen.org Date: Mon, 1 Oct 2012 10:41:29 +0100 Message-ID: <1349084491-13027-1-git-send-email-paul.durrant@citrix.com> X-Mailer: git-send-email 1.7.2.5 MIME-Version: 1.0 Cc: Paul Durrant Subject: [Xen-devel] [PATCH 0/2] PV drivers product number registration (v2) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org PV drivers in HVM guests typically make use off an 'unplug' protocol in QEMU to prevent co-existence of emulated devices. See docs/misc/hvm-emulated-unplug.markdown for details. The register of product numbers used by the blacklisting feature of this protocol is currently directly in the xenstore.c source moduleof traditional QEMU. It should really be in a Xen header file to prevent duplication/conflict between QEMU versions. Moreover the linux PV-on-HVM drivers make use of product number 3 seemingly without ever registering that number. This patch series introduces a new header and registers product number 3 for Linux's use. A subsequent patch to qemu-xen-unstable wll be created to make use of the new header. Version 2: I have re-coded at Ian Jackson's request in the form of macros that allow a switch statement or array to be easily generated from the product list. Signed-off-by: Paul Durrant _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 09:42:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 09:42:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIcVr-0005KG-5h; Mon, 01 Oct 2012 09:42:07 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIcVq-0005K7-2h for xen-devel@lists.xen.org; Mon, 01 Oct 2012 09:42:06 +0000 X-Env-Sender: Paul.Durrant@citrix.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1349084511!11021275!3 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzI5Nzc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6196 invoked from network); 1 Oct 2012 09:41:54 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 09:41:54 -0000 X-IronPort-AV: E=Sophos;i="4.80,514,1344211200"; d="scan'208";a="39704057" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 09:41:35 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 05:41:35 -0400 Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=pauldu) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TIcVL-0006W8-6a; Mon, 01 Oct 2012 10:41:35 +0100 From: Paul Durrant To: xen-devel@lists.xen.org Date: Mon, 1 Oct 2012 10:41:30 +0100 Message-ID: <1349084491-13027-2-git-send-email-paul.durrant@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1349084491-13027-1-git-send-email-paul.durrant@citrix.com> References: <1349084491-13027-1-git-send-email-paul.durrant@citrix.com> MIME-Version: 1.0 Cc: Paul Durrant Subject: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as the register of product numbers. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org These product numbers are used by the QEMU blacklisting protocol in traditional QEMU and are currently coded directly into the xenstore.c source module. Since there are now multiple QEMUs this information should be pulled into a public header to avoid duplication/conflict. hvm-emulated-unplug.markdown has also been adjusted to reference the new header. Signed-off-by: Paul Durrant --- docs/misc/hvm-emulated-unplug.markdown | 2 +- xen/include/public/hvm/pvdrivers.h | 47 ++++++++++++++++++++++++++++++++ 2 files changed, 48 insertions(+), 1 deletions(-) create mode 100644 xen/include/public/hvm/pvdrivers.h diff --git a/docs/misc/hvm-emulated-unplug.markdown b/docs/misc/hvm-emulated-unplug.markdown index 707fbab..ec9ce83 100644 --- a/docs/misc/hvm-emulated-unplug.markdown +++ b/docs/misc/hvm-emulated-unplug.markdown @@ -65,4 +65,4 @@ decimal number. `{product_name}` is a string corresponding to the product number in step 3. The master registry of product names and numbers is in -qemu-xen-unstable's xenstore.c. +xen/include/public/hvm/pvdrivers.h diff --git a/xen/include/public/hvm/pvdrivers.h b/xen/include/public/hvm/pvdrivers.h new file mode 100644 index 0000000..13bf57b --- /dev/null +++ b/xen/include/public/hvm/pvdrivers.h @@ -0,0 +1,47 @@ +/* + * pvdrivers.h: Register of PV drivers product numbers. + * Copyright (c) 2012, Citrix Systems Inc. + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the "Software"), to + * deal in the Software without restriction, including without limitation the + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or + * sell copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER + * DEALINGS IN THE SOFTWARE. + */ + +#ifndef _XEN_PUBLIC_PVDRIVERS_H_ +#define _XEN_PUBLIC_PVDRIVERS_H_ + +/* + * This is the master registry of product numbers for + * PV drivers. + * If you need a new product number allocating, please + * post to xen-devel@lists.xensource.com. You should NOT use + * a product number without allocating one. + * If you maintain a separate versioning and distribution path + * for PV drivers you should have a separate product number so + * that your drivers can be separated from others. + * + * During development, you may use the product ID to + * indicate a driver which is yet to be released. + */ + +#define PVDRIVERS_PRODUCT_LIST(EACH) \ + EACH("xensource-windows", 0x0001) /* Citrix */ \ + EACH("gplpv-windows", 0x0002) /* James Harper */ \ + EACH("experimental", 0xffff) \ + EACH(NULL, 0x0000) /* terminator */ + +#endif /* _XEN_PUBLIC_PVDRIVERS_H_ */ -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 09:42:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 09:42:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIcVu-0005Kn-T6; Mon, 01 Oct 2012 09:42:10 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIcVt-0005KA-AD for xen-devel@lists.xen.org; Mon, 01 Oct 2012 09:42:09 +0000 X-Env-Sender: Paul.Durrant@citrix.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1349084511!11021275!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzI5Nzc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5945 invoked from network); 1 Oct 2012 09:41:52 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 09:41:52 -0000 X-IronPort-AV: E=Sophos;i="4.80,514,1344211200"; d="scan'208";a="39704055" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 09:41:35 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 05:41:35 -0400 Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=pauldu) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TIcVL-0006W8-4p; Mon, 01 Oct 2012 10:41:35 +0100 From: Paul Durrant To: xen-devel@lists.xen.org Date: Mon, 1 Oct 2012 10:41:29 +0100 Message-ID: <1349084491-13027-1-git-send-email-paul.durrant@citrix.com> X-Mailer: git-send-email 1.7.2.5 MIME-Version: 1.0 Cc: Paul Durrant Subject: [Xen-devel] [PATCH 0/2] PV drivers product number registration (v2) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org PV drivers in HVM guests typically make use off an 'unplug' protocol in QEMU to prevent co-existence of emulated devices. See docs/misc/hvm-emulated-unplug.markdown for details. The register of product numbers used by the blacklisting feature of this protocol is currently directly in the xenstore.c source moduleof traditional QEMU. It should really be in a Xen header file to prevent duplication/conflict between QEMU versions. Moreover the linux PV-on-HVM drivers make use of product number 3 seemingly without ever registering that number. This patch series introduces a new header and registers product number 3 for Linux's use. A subsequent patch to qemu-xen-unstable wll be created to make use of the new header. Version 2: I have re-coded at Ian Jackson's request in the form of macros that allow a switch statement or array to be easily generated from the product list. Signed-off-by: Paul Durrant _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 09:42:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 09:42:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIcVu-0005Ke-Hk; Mon, 01 Oct 2012 09:42:10 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIcVs-0005K9-MY for xen-devel@lists.xen.org; Mon, 01 Oct 2012 09:42:08 +0000 X-Env-Sender: Paul.Durrant@citrix.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1349084511!11021275!2 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzI5Nzc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6104 invoked from network); 1 Oct 2012 09:41:53 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 09:41:53 -0000 X-IronPort-AV: E=Sophos;i="4.80,514,1344211200"; d="scan'208";a="39704056" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 09:41:35 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 05:41:35 -0400 Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=pauldu) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TIcVL-0006W8-8D; Mon, 01 Oct 2012 10:41:35 +0100 From: Paul Durrant To: xen-devel@lists.xen.org Date: Mon, 1 Oct 2012 10:41:31 +0100 Message-ID: <1349084491-13027-3-git-send-email-paul.durrant@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1349084491-13027-1-git-send-email-paul.durrant@citrix.com> References: <1349084491-13027-1-git-send-email-paul.durrant@citrix.com> MIME-Version: 1.0 Cc: Paul Durrant Subject: [Xen-devel] [PATCH 2/2] Register Linux PV-on-HVM drivers product number. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is already in use despite never being registereed. See XEN_IOPORT_LINUX_PRODNUM in include/xen/platform_pci.h Signed-off-by: Paul Durrant --- xen/include/public/hvm/pvdrivers.h | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/xen/include/public/hvm/pvdrivers.h b/xen/include/public/hvm/pvdrivers.h index 13bf57b..d117e5c 100644 --- a/xen/include/public/hvm/pvdrivers.h +++ b/xen/include/public/hvm/pvdrivers.h @@ -41,6 +41,7 @@ #define PVDRIVERS_PRODUCT_LIST(EACH) \ EACH("xensource-windows", 0x0001) /* Citrix */ \ EACH("gplpv-windows", 0x0002) /* James Harper */ \ + EACH("linux", 0x0003) \ EACH("experimental", 0xffff) \ EACH(NULL, 0x0000) /* terminator */ -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 09:42:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 09:42:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIcVu-0005Ke-Hk; Mon, 01 Oct 2012 09:42:10 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIcVs-0005K9-MY for xen-devel@lists.xen.org; Mon, 01 Oct 2012 09:42:08 +0000 X-Env-Sender: Paul.Durrant@citrix.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1349084511!11021275!2 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzI5Nzc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6104 invoked from network); 1 Oct 2012 09:41:53 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 09:41:53 -0000 X-IronPort-AV: E=Sophos;i="4.80,514,1344211200"; d="scan'208";a="39704056" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 09:41:35 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 05:41:35 -0400 Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=pauldu) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TIcVL-0006W8-8D; Mon, 01 Oct 2012 10:41:35 +0100 From: Paul Durrant To: xen-devel@lists.xen.org Date: Mon, 1 Oct 2012 10:41:31 +0100 Message-ID: <1349084491-13027-3-git-send-email-paul.durrant@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1349084491-13027-1-git-send-email-paul.durrant@citrix.com> References: <1349084491-13027-1-git-send-email-paul.durrant@citrix.com> MIME-Version: 1.0 Cc: Paul Durrant Subject: [Xen-devel] [PATCH 2/2] Register Linux PV-on-HVM drivers product number. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is already in use despite never being registereed. See XEN_IOPORT_LINUX_PRODNUM in include/xen/platform_pci.h Signed-off-by: Paul Durrant --- xen/include/public/hvm/pvdrivers.h | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/xen/include/public/hvm/pvdrivers.h b/xen/include/public/hvm/pvdrivers.h index 13bf57b..d117e5c 100644 --- a/xen/include/public/hvm/pvdrivers.h +++ b/xen/include/public/hvm/pvdrivers.h @@ -41,6 +41,7 @@ #define PVDRIVERS_PRODUCT_LIST(EACH) \ EACH("xensource-windows", 0x0001) /* Citrix */ \ EACH("gplpv-windows", 0x0002) /* James Harper */ \ + EACH("linux", 0x0003) \ EACH("experimental", 0xffff) \ EACH(NULL, 0x0000) /* terminator */ -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 09:44:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 09:44:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIcXh-0005ai-E8; Mon, 01 Oct 2012 09:44:01 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIcXg-0005aX-HA for xen-devel@lists.xen.org; Mon, 01 Oct 2012 09:44:00 +0000 Received: from [85.158.139.211:60723] by server-9.bemta-5.messagelabs.com id 42/80-14846-FD569605; Mon, 01 Oct 2012 09:43:59 +0000 X-Env-Sender: Paul.Durrant@citrix.com X-Msg-Ref: server-11.tower-206.messagelabs.com!1349084637!20592552!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzI5Nzc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10803 invoked from network); 1 Oct 2012 09:43:59 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 09:43:59 -0000 X-IronPort-AV: E=Sophos;i="4.80,514,1344211200"; d="scan'208";a="39704231" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 09:43:57 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 05:43:56 -0400 Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=pauldu) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TIcXc-0006Xy-CP; Mon, 01 Oct 2012 10:43:56 +0100 From: Paul Durrant To: xen-devel@lists.xen.org Date: Mon, 1 Oct 2012 10:43:53 +0100 Message-ID: <1349084633-13186-1-git-send-email-paul.durrant@citrix.com> X-Mailer: git-send-email 1.7.2.5 MIME-Version: 1.0 Cc: Paul Durrant Subject: [Xen-devel] [PATCH] Use new Xen public header for product numbers and names X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org xen/include/public/hvm/pvdrivers.h has been added as the register of product numbers used by the blacklisting protocol. Use the definitions therein rather then locally coded values. Signed-off-by: Paul Durrant --- xenstore.c | 23 +++++++---------------- 1 files changed, 7 insertions(+), 16 deletions(-) diff --git a/xenstore.c b/xenstore.c index 1857160..4382674 100644 --- a/xenstore.c +++ b/xenstore.c @@ -23,6 +23,8 @@ #include "qemu-timer.h" #include "qemu-xen.h" +#include + struct xs_handle *xsh = NULL; static char *media_filename[MAX_DRIVES+1]; static QEMUTimer *insert_timer = NULL; @@ -960,28 +962,17 @@ xenstore_pv_driver_build_blacklisted(uint16_t product_nr, char *tmp; const char *product; +#define PRODUCT(_name, _nr) case _nr: product = _name; break; switch (product_nr) { - /* - * In qemu-xen-unstable, this is the master registry of product - * numbers. If you need a new product number allocating, please - * post to xen-devel@lists.xensource.com. You should NOT use - * an existing product number without allocating one. - * - * If you maintain a seaparate versioning and distribution path - * for PV drivers you should have a separate product number so - * that your drivers can be separated from others'. - * - * During development, you may use the product ID 0xffff to - * indicate a driver which is yet to be released. - */ - case 1: product = "xensource-windows"; break; /* Citrix */ - case 2: product = "gplpv-windows"; break; /* James Harper */ - case 0xffff: product = "experimental"; break; + PVDRIVERS_PRODUCT_LIST(PRODUCT) default: /* Don't know what product this is -> we can't blacklist * it. */ return 0; } + +#undef PRODUCT + if (asprintf(&buf, "/mh/driver-blacklist/%s/%d", product, build_nr) < 0) return 0; tmp = xs_read(xsh, XBT_NULL, buf, NULL); -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 09:44:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 09:44:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIcXh-0005ai-E8; Mon, 01 Oct 2012 09:44:01 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIcXg-0005aX-HA for xen-devel@lists.xen.org; Mon, 01 Oct 2012 09:44:00 +0000 Received: from [85.158.139.211:60723] by server-9.bemta-5.messagelabs.com id 42/80-14846-FD569605; Mon, 01 Oct 2012 09:43:59 +0000 X-Env-Sender: Paul.Durrant@citrix.com X-Msg-Ref: server-11.tower-206.messagelabs.com!1349084637!20592552!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzI5Nzc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10803 invoked from network); 1 Oct 2012 09:43:59 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 09:43:59 -0000 X-IronPort-AV: E=Sophos;i="4.80,514,1344211200"; d="scan'208";a="39704231" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 09:43:57 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 05:43:56 -0400 Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=pauldu) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TIcXc-0006Xy-CP; Mon, 01 Oct 2012 10:43:56 +0100 From: Paul Durrant To: xen-devel@lists.xen.org Date: Mon, 1 Oct 2012 10:43:53 +0100 Message-ID: <1349084633-13186-1-git-send-email-paul.durrant@citrix.com> X-Mailer: git-send-email 1.7.2.5 MIME-Version: 1.0 Cc: Paul Durrant Subject: [Xen-devel] [PATCH] Use new Xen public header for product numbers and names X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org xen/include/public/hvm/pvdrivers.h has been added as the register of product numbers used by the blacklisting protocol. Use the definitions therein rather then locally coded values. Signed-off-by: Paul Durrant --- xenstore.c | 23 +++++++---------------- 1 files changed, 7 insertions(+), 16 deletions(-) diff --git a/xenstore.c b/xenstore.c index 1857160..4382674 100644 --- a/xenstore.c +++ b/xenstore.c @@ -23,6 +23,8 @@ #include "qemu-timer.h" #include "qemu-xen.h" +#include + struct xs_handle *xsh = NULL; static char *media_filename[MAX_DRIVES+1]; static QEMUTimer *insert_timer = NULL; @@ -960,28 +962,17 @@ xenstore_pv_driver_build_blacklisted(uint16_t product_nr, char *tmp; const char *product; +#define PRODUCT(_name, _nr) case _nr: product = _name; break; switch (product_nr) { - /* - * In qemu-xen-unstable, this is the master registry of product - * numbers. If you need a new product number allocating, please - * post to xen-devel@lists.xensource.com. You should NOT use - * an existing product number without allocating one. - * - * If you maintain a seaparate versioning and distribution path - * for PV drivers you should have a separate product number so - * that your drivers can be separated from others'. - * - * During development, you may use the product ID 0xffff to - * indicate a driver which is yet to be released. - */ - case 1: product = "xensource-windows"; break; /* Citrix */ - case 2: product = "gplpv-windows"; break; /* James Harper */ - case 0xffff: product = "experimental"; break; + PVDRIVERS_PRODUCT_LIST(PRODUCT) default: /* Don't know what product this is -> we can't blacklist * it. */ return 0; } + +#undef PRODUCT + if (asprintf(&buf, "/mh/driver-blacklist/%s/%d", product, build_nr) < 0) return 0; tmp = xs_read(xsh, XBT_NULL, buf, NULL); -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 09:45:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 09:45:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIcYK-0005gF-Rv; Mon, 01 Oct 2012 09:44:40 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with smtp (Exim 4.72) (envelope-from ) id 1TIcYJ-0005f3-DI for xen-devel@lists.xen.org; Mon, 01 Oct 2012 09:44:39 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-16.tower-27.messagelabs.com!1349084673!11577894!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12693 invoked from network); 1 Oct 2012 09:44:33 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-16.tower-27.messagelabs.com with SMTP; 1 Oct 2012 09:44:33 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 01 Oct 2012 10:44:33 +0100 Message-Id: <5069821D020000780009EB35@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Mon, 01 Oct 2012 10:44:29 +0100 From: "Jan Beulich" To: "Matt Wilson" References: <20f6976e28a1ce7e910e.1348894953@kaos-source-31003.sea31.amazon.com> <20120929184916.GB21253@u002268147cd4502c336d.ant.amazon.com> In-Reply-To: <20120929184916.GB21253@u002268147cd4502c336d.ant.amazon.com> Mime-Version: 1.0 Content-Disposition: inline Cc: Keir Fraser , xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH] xen/console: introduce a 'w' debug-key that dumps the console ring X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 29.09.12 at 20:49, Matt Wilson wrote: > On Sat, Sep 29, 2012 at 06:55:41AM +0100, Keir Fraser wrote: >> On 29/09/2012 06:02, "Matt Wilson" wrote: >> >> > This patch adds a new 'w' debug-key, chosen from the limited remaining >> > keys only due to its proximity to 'q', that dumps the console ring to >> > configured console devices. It's useful to for tracking down how an >> > unresponsive system got into a broken state via serial console. >> >> Why wouldn't everything on the ring already have been sent to the configured >> console devices? > > It would have been. But what if no one was looking, or dom0 cleared > the console, or placed it into a scrolling mode that prevents a > virtual terminal from placing output into a scrollback buffer. With > this patch, you can connect to a serial console after a machine > becomes unresponsive and gather clues on what went wrong. That's an operator error then. I completely agree with Keir that what you propose is pretty questionable (and you provide one argument against it already - the shortage of remaining keys). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 09:45:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 09:45:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIcYK-0005gF-Rv; Mon, 01 Oct 2012 09:44:40 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with smtp (Exim 4.72) (envelope-from ) id 1TIcYJ-0005f3-DI for xen-devel@lists.xen.org; Mon, 01 Oct 2012 09:44:39 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-16.tower-27.messagelabs.com!1349084673!11577894!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12693 invoked from network); 1 Oct 2012 09:44:33 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-16.tower-27.messagelabs.com with SMTP; 1 Oct 2012 09:44:33 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 01 Oct 2012 10:44:33 +0100 Message-Id: <5069821D020000780009EB35@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Mon, 01 Oct 2012 10:44:29 +0100 From: "Jan Beulich" To: "Matt Wilson" References: <20f6976e28a1ce7e910e.1348894953@kaos-source-31003.sea31.amazon.com> <20120929184916.GB21253@u002268147cd4502c336d.ant.amazon.com> In-Reply-To: <20120929184916.GB21253@u002268147cd4502c336d.ant.amazon.com> Mime-Version: 1.0 Content-Disposition: inline Cc: Keir Fraser , xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH] xen/console: introduce a 'w' debug-key that dumps the console ring X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 29.09.12 at 20:49, Matt Wilson wrote: > On Sat, Sep 29, 2012 at 06:55:41AM +0100, Keir Fraser wrote: >> On 29/09/2012 06:02, "Matt Wilson" wrote: >> >> > This patch adds a new 'w' debug-key, chosen from the limited remaining >> > keys only due to its proximity to 'q', that dumps the console ring to >> > configured console devices. It's useful to for tracking down how an >> > unresponsive system got into a broken state via serial console. >> >> Why wouldn't everything on the ring already have been sent to the configured >> console devices? > > It would have been. But what if no one was looking, or dom0 cleared > the console, or placed it into a scrolling mode that prevents a > virtual terminal from placing output into a scrollback buffer. With > this patch, you can connect to a serial console after a machine > becomes unresponsive and gather clues on what went wrong. That's an operator error then. I completely agree with Keir that what you propose is pretty questionable (and you provide one argument against it already - the shortage of remaining keys). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 10:13:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 10:13:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TId0H-0006Fi-G4; Mon, 01 Oct 2012 10:13:33 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TId0G-0006Fd-2J for xen-devel@lists.xen.org; Mon, 01 Oct 2012 10:13:32 +0000 Received: from [85.158.137.99:48758] by server-14.bemta-3.messagelabs.com id 1F/C7-25886-BCC69605; Mon, 01 Oct 2012 10:13:31 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-217.messagelabs.com!1349086410!14716528!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI1NjQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6596 invoked from network); 1 Oct 2012 10:13:30 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 10:13:30 -0000 X-IronPort-AV: E=Sophos;i="4.80,515,1344211200"; d="scan'208";a="14864816" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 10:13:28 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 11:13:28 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TId0C-0006yF-5T; Mon, 01 Oct 2012 10:13:28 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TId0B-0004Wq-Ou; Mon, 01 Oct 2012 11:13:27 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20585.27847.174145.345965@mariner.uk.xensource.com> Date: Mon, 1 Oct 2012 11:13:27 +0100 To: Paul Durrant In-Reply-To: <291EDFCB1E9E224A99088639C4762022EFF91D9EE4@LONPMAILBOX01.citrite.net> References: <1348667684-29202-1-git-send-email-paul.durrant@citrix.com> <20581.58542.402088.878499@mariner.uk.xensource.com> <291EDFCB1E9E224A99088639C4762022EFF91D9EE4@LONPMAILBOX01.citrite.net> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] Use new Xen public header for product numbers and names X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Paul Durrant writes ("RE: [Xen-devel] [PATCH] Use new Xen public header for product numbers and names"): > Ok. I'll come up with something we can use to define an array and > then we can iterate over that. Great. What do people think of this preprocessor approach, which I suggested earlier: #define PVDRIVERS_LIST(EACH) \ EACH(WINDOWS, 0x0001 /* Citrix */, "xensource-windows") \ ... That can be used to generate arrays, or switch statements, or whatever. For example in pvdrivers.h: #define PVDRIVERS_EACH_ENUM(name,num,string) \ PVDRIVERS_ID_##name = num, enum { PVDRIVERS_LIST(PVDRIVERS_EACH_ENUM) }; and then in qemu: #define PVDRIVERS_EACH_SWITCH(name,num,string) \ case PVDRIVERS_ID_##name: product = string; break; switch (id) { PVDRIVERS_LIST(PVDRIVERS_EACH_SWITCH) default: sprintf blah blah } If the indirect macro trick is too abstruse it's also possible to do this: #define PVDRIVERS_LIST \ PVDRIVERS_EACH(WINDOWS, 0x0001 /* Citrix */, "xensource-windows") \ ... That can be used to generate arrays, or switch statements, or whatever. For example in pvdrivers.h: #define PVDRIVERS_EACH(name,num,string) \ PVDRIVERS_ID_##name = num, enum { PVDRIVERS_LIST }; #undef PVDRIVERS_EACH and then in qemu: #define PVDRIVERS_EACH(name,num,string) \ case PVDRIVERS_ID_##name: product = string; break; switch (id) { PVDRIVERS_LIST default: sprintf blah blah } #undef PVDRIVERS_EACH A #define containing an array initialiser is the other obvious alternative although of course the macro-based approaches I sketch above can be used to define arrays but not vice versa. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 10:13:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 10:13:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TId0H-0006Fi-G4; Mon, 01 Oct 2012 10:13:33 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TId0G-0006Fd-2J for xen-devel@lists.xen.org; Mon, 01 Oct 2012 10:13:32 +0000 Received: from [85.158.137.99:48758] by server-14.bemta-3.messagelabs.com id 1F/C7-25886-BCC69605; Mon, 01 Oct 2012 10:13:31 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-217.messagelabs.com!1349086410!14716528!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI1NjQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6596 invoked from network); 1 Oct 2012 10:13:30 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 10:13:30 -0000 X-IronPort-AV: E=Sophos;i="4.80,515,1344211200"; d="scan'208";a="14864816" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 10:13:28 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 11:13:28 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TId0C-0006yF-5T; Mon, 01 Oct 2012 10:13:28 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TId0B-0004Wq-Ou; Mon, 01 Oct 2012 11:13:27 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20585.27847.174145.345965@mariner.uk.xensource.com> Date: Mon, 1 Oct 2012 11:13:27 +0100 To: Paul Durrant In-Reply-To: <291EDFCB1E9E224A99088639C4762022EFF91D9EE4@LONPMAILBOX01.citrite.net> References: <1348667684-29202-1-git-send-email-paul.durrant@citrix.com> <20581.58542.402088.878499@mariner.uk.xensource.com> <291EDFCB1E9E224A99088639C4762022EFF91D9EE4@LONPMAILBOX01.citrite.net> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] Use new Xen public header for product numbers and names X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Paul Durrant writes ("RE: [Xen-devel] [PATCH] Use new Xen public header for product numbers and names"): > Ok. I'll come up with something we can use to define an array and > then we can iterate over that. Great. What do people think of this preprocessor approach, which I suggested earlier: #define PVDRIVERS_LIST(EACH) \ EACH(WINDOWS, 0x0001 /* Citrix */, "xensource-windows") \ ... That can be used to generate arrays, or switch statements, or whatever. For example in pvdrivers.h: #define PVDRIVERS_EACH_ENUM(name,num,string) \ PVDRIVERS_ID_##name = num, enum { PVDRIVERS_LIST(PVDRIVERS_EACH_ENUM) }; and then in qemu: #define PVDRIVERS_EACH_SWITCH(name,num,string) \ case PVDRIVERS_ID_##name: product = string; break; switch (id) { PVDRIVERS_LIST(PVDRIVERS_EACH_SWITCH) default: sprintf blah blah } If the indirect macro trick is too abstruse it's also possible to do this: #define PVDRIVERS_LIST \ PVDRIVERS_EACH(WINDOWS, 0x0001 /* Citrix */, "xensource-windows") \ ... That can be used to generate arrays, or switch statements, or whatever. For example in pvdrivers.h: #define PVDRIVERS_EACH(name,num,string) \ PVDRIVERS_ID_##name = num, enum { PVDRIVERS_LIST }; #undef PVDRIVERS_EACH and then in qemu: #define PVDRIVERS_EACH(name,num,string) \ case PVDRIVERS_ID_##name: product = string; break; switch (id) { PVDRIVERS_LIST default: sprintf blah blah } #undef PVDRIVERS_EACH A #define containing an array initialiser is the other obvious alternative although of course the macro-based approaches I sketch above can be used to define arrays but not vice versa. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 10:29:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 10:29:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIdF0-0006Pp-2A; Mon, 01 Oct 2012 10:28:46 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIdEz-0006Pk-BH for xen-devel@lists.xen.org; Mon, 01 Oct 2012 10:28:45 +0000 Received: from [85.158.139.211:9699] by server-5.bemta-5.messagelabs.com id A6/67-21075-C5079605; Mon, 01 Oct 2012 10:28:44 +0000 X-Env-Sender: Paul.Durrant@citrix.com X-Msg-Ref: server-5.tower-206.messagelabs.com!1349087323!20552265!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI1NjQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13329 invoked from network); 1 Oct 2012 10:28:44 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 10:28:44 -0000 X-IronPort-AV: E=Sophos;i="4.80,515,1344211200"; d="scan'208";a="14865268" Received: from lonpmailmx02.citrite.net ([10.30.203.163]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 10:28:43 +0000 Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Mon, 1 Oct 2012 11:28:43 +0100 From: Paul Durrant To: Ian Jackson Date: Mon, 1 Oct 2012 11:28:45 +0100 Thread-Topic: [Xen-devel] [PATCH] Use new Xen public header for product numbers and names Thread-Index: Ac2fvWbv7lDniKrXSgK2+U8mHoTopgAAaxpQ Message-ID: <291EDFCB1E9E224A99088639C4762022EFF91D9F18@LONPMAILBOX01.citrite.net> References: <1348667684-29202-1-git-send-email-paul.durrant@citrix.com> <20581.58542.402088.878499@mariner.uk.xensource.com> <291EDFCB1E9E224A99088639C4762022EFF91D9EE4@LONPMAILBOX01.citrite.net> <20585.27847.174145.345965@mariner.uk.xensource.com> In-Reply-To: <20585.27847.174145.345965@mariner.uk.xensource.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] Use new Xen public header for product numbers and names X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > -----Original Message----- > > What do people think of this preprocessor approach, which I suggested > earlier: > > #define PVDRIVERS_LIST(EACH) \ > EACH(WINDOWS, 0x0001 /* Citrix */, "xensource-windows") \ > ... > I liked it so that's what I did :-) I added a terminator entry for convenience when defining an array. Not needed when defining a switch statement but harmless since it's a case that should never be hit. Paul _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 10:29:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 10:29:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIdF0-0006Pp-2A; Mon, 01 Oct 2012 10:28:46 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIdEz-0006Pk-BH for xen-devel@lists.xen.org; Mon, 01 Oct 2012 10:28:45 +0000 Received: from [85.158.139.211:9699] by server-5.bemta-5.messagelabs.com id A6/67-21075-C5079605; Mon, 01 Oct 2012 10:28:44 +0000 X-Env-Sender: Paul.Durrant@citrix.com X-Msg-Ref: server-5.tower-206.messagelabs.com!1349087323!20552265!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI1NjQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13329 invoked from network); 1 Oct 2012 10:28:44 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 10:28:44 -0000 X-IronPort-AV: E=Sophos;i="4.80,515,1344211200"; d="scan'208";a="14865268" Received: from lonpmailmx02.citrite.net ([10.30.203.163]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 10:28:43 +0000 Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Mon, 1 Oct 2012 11:28:43 +0100 From: Paul Durrant To: Ian Jackson Date: Mon, 1 Oct 2012 11:28:45 +0100 Thread-Topic: [Xen-devel] [PATCH] Use new Xen public header for product numbers and names Thread-Index: Ac2fvWbv7lDniKrXSgK2+U8mHoTopgAAaxpQ Message-ID: <291EDFCB1E9E224A99088639C4762022EFF91D9F18@LONPMAILBOX01.citrite.net> References: <1348667684-29202-1-git-send-email-paul.durrant@citrix.com> <20581.58542.402088.878499@mariner.uk.xensource.com> <291EDFCB1E9E224A99088639C4762022EFF91D9EE4@LONPMAILBOX01.citrite.net> <20585.27847.174145.345965@mariner.uk.xensource.com> In-Reply-To: <20585.27847.174145.345965@mariner.uk.xensource.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] Use new Xen public header for product numbers and names X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > -----Original Message----- > > What do people think of this preprocessor approach, which I suggested > earlier: > > #define PVDRIVERS_LIST(EACH) \ > EACH(WINDOWS, 0x0001 /* Citrix */, "xensource-windows") \ > ... > I liked it so that's what I did :-) I added a terminator entry for convenience when defining an array. Not needed when defining a switch statement but harmless since it's a case that should never be hit. Paul _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 10:33:36 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 10:33:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIdJP-0006YB-TQ; Mon, 01 Oct 2012 10:33:19 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIdJO-0006Y4-CA for xen-devel@lists.xen.org; Mon, 01 Oct 2012 10:33:18 +0000 Received: from [85.158.139.211:64602] by server-8.bemta-5.messagelabs.com id 0F/D4-18073-D6179605; Mon, 01 Oct 2012 10:33:17 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-6.tower-206.messagelabs.com!1349087596!20600878!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI1NjQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26134 invoked from network); 1 Oct 2012 10:33:16 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 10:33:16 -0000 X-IronPort-AV: E=Sophos;i="4.80,515,1344211200"; d="scan'208";a="14865428" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 10:33:16 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 11:33:16 +0100 Date: Mon, 1 Oct 2012 11:32:18 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Anthony PERARD In-Reply-To: <1348744360-2989-3-git-send-email-anthony.perard@citrix.com> Message-ID: References: <1348744360-2989-1-git-send-email-anthony.perard@citrix.com> <1348744360-2989-3-git-send-email-anthony.perard@citrix.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: Xen Devel , QEMU-devel , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH V4 2/5] xen: Introduce xen_modified_memory. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 27 Sep 2012, Anthony PERARD wrote: > This function is to be used during live migration. Every write access to the > guest memory should call this funcion so the Xen tools knows which pages are > dirty. > > Signed-off-by: Anthony PERARD Acked-by: Stefano Stabellini > hw/xen.h | 1 + > xen-all.c | 21 +++++++++++++++++++++ > xen-stub.c | 4 ++++ > 3 files changed, 26 insertions(+) > > diff --git a/hw/xen.h b/hw/xen.h > index e5926b7..d14e92d 100644 > --- a/hw/xen.h > +++ b/hw/xen.h > @@ -48,6 +48,7 @@ void xenstore_store_pv_console_info(int i, struct CharDriverState *chr); > struct MemoryRegion; > void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, > struct MemoryRegion *mr); > +void xen_modified_memory(ram_addr_t start, ram_addr_t length); > #endif > > struct MemoryRegion; > diff --git a/xen-all.c b/xen-all.c > index f75ae9f..b11542c 100644 > --- a/xen-all.c > +++ b/xen-all.c > @@ -1228,3 +1228,24 @@ void xen_shutdown_fatal_error(const char *fmt, ...) > /* destroy the domain */ > qemu_system_shutdown_request(); > } > + > +void xen_modified_memory(ram_addr_t start, ram_addr_t length) > +{ > + if (unlikely(xen_in_migration)) { > + int rc; > + ram_addr_t start_pfn, nb_pages; > + > + if (length == 0) { > + length = TARGET_PAGE_SIZE; > + } > + start_pfn = start >> TARGET_PAGE_BITS; > + nb_pages = ((start + length + TARGET_PAGE_SIZE - 1) >> TARGET_PAGE_BITS) > + - start_pfn; > + rc = xc_hvm_modified_memory(xen_xc, xen_domid, start_pfn, nb_pages); > + if (rc) { > + fprintf(stderr, > + "%s failed for "RAM_ADDR_FMT" ("RAM_ADDR_FMT"): %i, %s\n", > + __func__, start, nb_pages, rc, strerror(-rc)); > + } > + } > +} > diff --git a/xen-stub.c b/xen-stub.c > index 5e66ba8..9214392 100644 > --- a/xen-stub.c > +++ b/xen-stub.c > @@ -59,3 +59,7 @@ void xen_register_framebuffer(MemoryRegion *mr) > void qmp_xen_set_global_dirty_log(bool enable, Error **errp) > { > } > + > +void xen_modified_memory(ram_addr_t start, ram_addr_t length) > +{ > +} > -- > Anthony PERARD > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 10:33:36 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 10:33:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIdJP-0006YB-TQ; Mon, 01 Oct 2012 10:33:19 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIdJO-0006Y4-CA for xen-devel@lists.xen.org; Mon, 01 Oct 2012 10:33:18 +0000 Received: from [85.158.139.211:64602] by server-8.bemta-5.messagelabs.com id 0F/D4-18073-D6179605; Mon, 01 Oct 2012 10:33:17 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-6.tower-206.messagelabs.com!1349087596!20600878!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI1NjQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26134 invoked from network); 1 Oct 2012 10:33:16 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 10:33:16 -0000 X-IronPort-AV: E=Sophos;i="4.80,515,1344211200"; d="scan'208";a="14865428" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 10:33:16 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 11:33:16 +0100 Date: Mon, 1 Oct 2012 11:32:18 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Anthony PERARD In-Reply-To: <1348744360-2989-3-git-send-email-anthony.perard@citrix.com> Message-ID: References: <1348744360-2989-1-git-send-email-anthony.perard@citrix.com> <1348744360-2989-3-git-send-email-anthony.perard@citrix.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: Xen Devel , QEMU-devel , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH V4 2/5] xen: Introduce xen_modified_memory. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 27 Sep 2012, Anthony PERARD wrote: > This function is to be used during live migration. Every write access to the > guest memory should call this funcion so the Xen tools knows which pages are > dirty. > > Signed-off-by: Anthony PERARD Acked-by: Stefano Stabellini > hw/xen.h | 1 + > xen-all.c | 21 +++++++++++++++++++++ > xen-stub.c | 4 ++++ > 3 files changed, 26 insertions(+) > > diff --git a/hw/xen.h b/hw/xen.h > index e5926b7..d14e92d 100644 > --- a/hw/xen.h > +++ b/hw/xen.h > @@ -48,6 +48,7 @@ void xenstore_store_pv_console_info(int i, struct CharDriverState *chr); > struct MemoryRegion; > void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, > struct MemoryRegion *mr); > +void xen_modified_memory(ram_addr_t start, ram_addr_t length); > #endif > > struct MemoryRegion; > diff --git a/xen-all.c b/xen-all.c > index f75ae9f..b11542c 100644 > --- a/xen-all.c > +++ b/xen-all.c > @@ -1228,3 +1228,24 @@ void xen_shutdown_fatal_error(const char *fmt, ...) > /* destroy the domain */ > qemu_system_shutdown_request(); > } > + > +void xen_modified_memory(ram_addr_t start, ram_addr_t length) > +{ > + if (unlikely(xen_in_migration)) { > + int rc; > + ram_addr_t start_pfn, nb_pages; > + > + if (length == 0) { > + length = TARGET_PAGE_SIZE; > + } > + start_pfn = start >> TARGET_PAGE_BITS; > + nb_pages = ((start + length + TARGET_PAGE_SIZE - 1) >> TARGET_PAGE_BITS) > + - start_pfn; > + rc = xc_hvm_modified_memory(xen_xc, xen_domid, start_pfn, nb_pages); > + if (rc) { > + fprintf(stderr, > + "%s failed for "RAM_ADDR_FMT" ("RAM_ADDR_FMT"): %i, %s\n", > + __func__, start, nb_pages, rc, strerror(-rc)); > + } > + } > +} > diff --git a/xen-stub.c b/xen-stub.c > index 5e66ba8..9214392 100644 > --- a/xen-stub.c > +++ b/xen-stub.c > @@ -59,3 +59,7 @@ void xen_register_framebuffer(MemoryRegion *mr) > void qmp_xen_set_global_dirty_log(bool enable, Error **errp) > { > } > + > +void xen_modified_memory(ram_addr_t start, ram_addr_t length) > +{ > +} > -- > Anthony PERARD > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 10:34:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 10:34:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIdKX-0006dE-CA; Mon, 01 Oct 2012 10:34:29 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIdKW-0006d6-2s for xen-devel@lists.xen.org; Mon, 01 Oct 2012 10:34:28 +0000 Received: from [85.158.137.99:15899] by server-10.bemta-3.messagelabs.com id 1F/6B-02525-3B179605; Mon, 01 Oct 2012 10:34:27 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-8.tower-217.messagelabs.com!1349087666!14425141!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI1NjQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4483 invoked from network); 1 Oct 2012 10:34:26 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 10:34:26 -0000 X-IronPort-AV: E=Sophos;i="4.80,515,1344211200"; d="scan'208";a="14865475" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 10:34:26 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 11:34:26 +0100 Date: Mon, 1 Oct 2012 11:33:28 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Anthony PERARD In-Reply-To: <1348744360-2989-6-git-send-email-anthony.perard@citrix.com> Message-ID: References: <1348744360-2989-1-git-send-email-anthony.perard@citrix.com> <1348744360-2989-6-git-send-email-anthony.perard@citrix.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: Xen Devel , QEMU-devel , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH V4 5/5] xen: Set the vram dirty when an error occur. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 27 Sep 2012, Anthony PERARD wrote: > If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on all the > video ram. This case happens during migration. > > Signed-off-by: Anthony PERARD Acked-by: Stefano Stabellini > xen-all.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/xen-all.c b/xen-all.c > index b11542c..e6308be 100644 > --- a/xen-all.c > +++ b/xen-all.c > @@ -507,7 +507,8 @@ static void xen_sync_dirty_bitmap(XenIOState *state, > bitmap); > if (rc < 0) { > if (rc != -ENODATA) { > - fprintf(stderr, "xen: track_dirty_vram failed (0x" TARGET_FMT_plx > + memory_region_set_dirty(framebuffer, 0, size); > + DPRINTF("xen: track_dirty_vram failed (0x" TARGET_FMT_plx > ", 0x" TARGET_FMT_plx "): %s\n", > start_addr, start_addr + size, strerror(-rc)); > } > -- > Anthony PERARD > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 10:34:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 10:34:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIdKX-0006dE-CA; Mon, 01 Oct 2012 10:34:29 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIdKW-0006d6-2s for xen-devel@lists.xen.org; Mon, 01 Oct 2012 10:34:28 +0000 Received: from [85.158.137.99:15899] by server-10.bemta-3.messagelabs.com id 1F/6B-02525-3B179605; Mon, 01 Oct 2012 10:34:27 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-8.tower-217.messagelabs.com!1349087666!14425141!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI1NjQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4483 invoked from network); 1 Oct 2012 10:34:26 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 10:34:26 -0000 X-IronPort-AV: E=Sophos;i="4.80,515,1344211200"; d="scan'208";a="14865475" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 10:34:26 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 11:34:26 +0100 Date: Mon, 1 Oct 2012 11:33:28 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Anthony PERARD In-Reply-To: <1348744360-2989-6-git-send-email-anthony.perard@citrix.com> Message-ID: References: <1348744360-2989-1-git-send-email-anthony.perard@citrix.com> <1348744360-2989-6-git-send-email-anthony.perard@citrix.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: Xen Devel , QEMU-devel , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH V4 5/5] xen: Set the vram dirty when an error occur. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 27 Sep 2012, Anthony PERARD wrote: > If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on all the > video ram. This case happens during migration. > > Signed-off-by: Anthony PERARD Acked-by: Stefano Stabellini > xen-all.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/xen-all.c b/xen-all.c > index b11542c..e6308be 100644 > --- a/xen-all.c > +++ b/xen-all.c > @@ -507,7 +507,8 @@ static void xen_sync_dirty_bitmap(XenIOState *state, > bitmap); > if (rc < 0) { > if (rc != -ENODATA) { > - fprintf(stderr, "xen: track_dirty_vram failed (0x" TARGET_FMT_plx > + memory_region_set_dirty(framebuffer, 0, size); > + DPRINTF("xen: track_dirty_vram failed (0x" TARGET_FMT_plx > ", 0x" TARGET_FMT_plx "): %s\n", > start_addr, start_addr + size, strerror(-rc)); > } > -- > Anthony PERARD > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 10:36:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 10:36:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIdMG-0006kV-T1; Mon, 01 Oct 2012 10:36:16 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIdMF-0006kM-G0 for xen-devel@lists.xen.org; Mon, 01 Oct 2012 10:36:15 +0000 Received: from [85.158.138.51:29053] by server-13.bemta-3.messagelabs.com id F6/F0-11249-E1279605; Mon, 01 Oct 2012 10:36:14 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1349087773!24582995!1 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2290 invoked from network); 1 Oct 2012 10:36:13 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 10:36:13 -0000 Received: by eekb47 with SMTP id b47so2383240eek.32 for ; Mon, 01 Oct 2012 03:36:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=4mSLUdrohMFIvCbzQAQLyyJiXfNLloqHaEdbJT46zNk=; b=nNdRQ98WQ3RHEgYHPZB/8jkSUO6cP00TIX5FIkDeYH8S96aNxy4kR7U+vHc21v6M27 CVGUN3uTr0HkDoJFEo5tM+5jV9n553Dxl9+30nTFwmiIyTeu7yinn3//d52YUrLHMF05 0jGEhS6jL88x5/1ZKGw6TlD8Ea7tJMvOpbxGQdr/abZPwdl5EpvdfGY0aPTYSzxytjBA Y08dv8UEoiuXCPpA5YCFVYP/Dok0SJ9nGBvfjBenEyhAR+KwLDcv3MgRIunK+itU9+OX hH3WR72ZJbhbLNHlNz8i05XizSuMOXzxkdU7vrv9CKD8Srt1ZrHf8o30LH8Jm9I2X2cj qHHw== Received: by 10.14.179.137 with SMTP id h9mr17701605eem.22.1349087773225; Mon, 01 Oct 2012 03:36:13 -0700 (PDT) Received: from [192.168.1.69] (host86-183-156-141.range86-183.btcentralplus.com. [86.183.156.141]) by mx.google.com with ESMTPS id e7sm46901397eep.2.2012.10.01.03.36.11 (version=SSLv3 cipher=OTHER); Mon, 01 Oct 2012 03:36:12 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Mon, 01 Oct 2012 11:36:10 +0100 From: Keir Fraser To: Ian Jackson , Paul Durrant Message-ID: Thread-Topic: [Xen-devel] [PATCH] Use new Xen public header for product numbers and names Thread-Index: Ac2fwJJCKSiRe/DC6UC1EydRr0IblA== In-Reply-To: <20585.27847.174145.345965@mariner.uk.xensource.com> Mime-version: 1.0 Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] Use new Xen public header for product numbers and names X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 01/10/2012 11:13, "Ian Jackson" wrote: > Paul Durrant writes ("RE: [Xen-devel] [PATCH] Use new Xen public header for > product numbers and names"): >> Ok. I'll come up with something we can use to define an array and >> then we can iterate over that. > > Great. > > > What do people think of this preprocessor approach, which I suggested > earlier: My usual way to do this would be to place the list in its own header file: pvdrivers_list.h: EACH(WINDOWS, 0x0001, "xensource-windows") EACH(...) ... Then e.g., #define EACH(name,num,string) PVDRIVERS_ID_##name = num, enum { #include "pvdrivers_list.h" } #undef EACH Which is a bit more abstruse on the consuming side, but does avoid the list itself being an ugly multi-line macro monster. I don't have a strong opinion on this by the way. :) Just saying... -- Keir > #define PVDRIVERS_LIST(EACH) \ > EACH(WINDOWS, 0x0001 /* Citrix */, "xensource-windows") \ > ... > > That can be used to generate arrays, or switch statements, or > whatever. For example in pvdrivers.h: > > #define PVDRIVERS_EACH_ENUM(name,num,string) \ > PVDRIVERS_ID_##name = num, > enum { > PVDRIVERS_LIST(PVDRIVERS_EACH_ENUM) > }; > > and then in qemu: > > #define PVDRIVERS_EACH_SWITCH(name,num,string) \ > case PVDRIVERS_ID_##name: product = string; break; > > switch (id) { > PVDRIVERS_LIST(PVDRIVERS_EACH_SWITCH) > default: > sprintf blah blah > } > > > If the indirect macro trick is too abstruse it's also possible to do > this: > > #define PVDRIVERS_LIST \ > PVDRIVERS_EACH(WINDOWS, 0x0001 /* Citrix */, "xensource-windows") \ > ... > > That can be used to generate arrays, or switch statements, or > whatever. For example in pvdrivers.h: > > #define PVDRIVERS_EACH(name,num,string) \ > PVDRIVERS_ID_##name = num, > enum { > PVDRIVERS_LIST > }; > #undef PVDRIVERS_EACH > > and then in qemu: > > #define PVDRIVERS_EACH(name,num,string) \ > case PVDRIVERS_ID_##name: product = string; break; > > switch (id) { > PVDRIVERS_LIST > default: > sprintf blah blah > } > > #undef PVDRIVERS_EACH > > > A #define containing an array initialiser is the other obvious > alternative although of course the macro-based approaches I sketch > above can be used to define arrays but not vice versa. > > > Ian. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 10:36:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 10:36:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIdMG-0006kV-T1; Mon, 01 Oct 2012 10:36:16 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIdMF-0006kM-G0 for xen-devel@lists.xen.org; Mon, 01 Oct 2012 10:36:15 +0000 Received: from [85.158.138.51:29053] by server-13.bemta-3.messagelabs.com id F6/F0-11249-E1279605; Mon, 01 Oct 2012 10:36:14 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1349087773!24582995!1 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2290 invoked from network); 1 Oct 2012 10:36:13 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 10:36:13 -0000 Received: by eekb47 with SMTP id b47so2383240eek.32 for ; Mon, 01 Oct 2012 03:36:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=4mSLUdrohMFIvCbzQAQLyyJiXfNLloqHaEdbJT46zNk=; b=nNdRQ98WQ3RHEgYHPZB/8jkSUO6cP00TIX5FIkDeYH8S96aNxy4kR7U+vHc21v6M27 CVGUN3uTr0HkDoJFEo5tM+5jV9n553Dxl9+30nTFwmiIyTeu7yinn3//d52YUrLHMF05 0jGEhS6jL88x5/1ZKGw6TlD8Ea7tJMvOpbxGQdr/abZPwdl5EpvdfGY0aPTYSzxytjBA Y08dv8UEoiuXCPpA5YCFVYP/Dok0SJ9nGBvfjBenEyhAR+KwLDcv3MgRIunK+itU9+OX hH3WR72ZJbhbLNHlNz8i05XizSuMOXzxkdU7vrv9CKD8Srt1ZrHf8o30LH8Jm9I2X2cj qHHw== Received: by 10.14.179.137 with SMTP id h9mr17701605eem.22.1349087773225; Mon, 01 Oct 2012 03:36:13 -0700 (PDT) Received: from [192.168.1.69] (host86-183-156-141.range86-183.btcentralplus.com. [86.183.156.141]) by mx.google.com with ESMTPS id e7sm46901397eep.2.2012.10.01.03.36.11 (version=SSLv3 cipher=OTHER); Mon, 01 Oct 2012 03:36:12 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Mon, 01 Oct 2012 11:36:10 +0100 From: Keir Fraser To: Ian Jackson , Paul Durrant Message-ID: Thread-Topic: [Xen-devel] [PATCH] Use new Xen public header for product numbers and names Thread-Index: Ac2fwJJCKSiRe/DC6UC1EydRr0IblA== In-Reply-To: <20585.27847.174145.345965@mariner.uk.xensource.com> Mime-version: 1.0 Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] Use new Xen public header for product numbers and names X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 01/10/2012 11:13, "Ian Jackson" wrote: > Paul Durrant writes ("RE: [Xen-devel] [PATCH] Use new Xen public header for > product numbers and names"): >> Ok. I'll come up with something we can use to define an array and >> then we can iterate over that. > > Great. > > > What do people think of this preprocessor approach, which I suggested > earlier: My usual way to do this would be to place the list in its own header file: pvdrivers_list.h: EACH(WINDOWS, 0x0001, "xensource-windows") EACH(...) ... Then e.g., #define EACH(name,num,string) PVDRIVERS_ID_##name = num, enum { #include "pvdrivers_list.h" } #undef EACH Which is a bit more abstruse on the consuming side, but does avoid the list itself being an ugly multi-line macro monster. I don't have a strong opinion on this by the way. :) Just saying... -- Keir > #define PVDRIVERS_LIST(EACH) \ > EACH(WINDOWS, 0x0001 /* Citrix */, "xensource-windows") \ > ... > > That can be used to generate arrays, or switch statements, or > whatever. For example in pvdrivers.h: > > #define PVDRIVERS_EACH_ENUM(name,num,string) \ > PVDRIVERS_ID_##name = num, > enum { > PVDRIVERS_LIST(PVDRIVERS_EACH_ENUM) > }; > > and then in qemu: > > #define PVDRIVERS_EACH_SWITCH(name,num,string) \ > case PVDRIVERS_ID_##name: product = string; break; > > switch (id) { > PVDRIVERS_LIST(PVDRIVERS_EACH_SWITCH) > default: > sprintf blah blah > } > > > If the indirect macro trick is too abstruse it's also possible to do > this: > > #define PVDRIVERS_LIST \ > PVDRIVERS_EACH(WINDOWS, 0x0001 /* Citrix */, "xensource-windows") \ > ... > > That can be used to generate arrays, or switch statements, or > whatever. For example in pvdrivers.h: > > #define PVDRIVERS_EACH(name,num,string) \ > PVDRIVERS_ID_##name = num, > enum { > PVDRIVERS_LIST > }; > #undef PVDRIVERS_EACH > > and then in qemu: > > #define PVDRIVERS_EACH(name,num,string) \ > case PVDRIVERS_ID_##name: product = string; break; > > switch (id) { > PVDRIVERS_LIST > default: > sprintf blah blah > } > > #undef PVDRIVERS_EACH > > > A #define containing an array initialiser is the other obvious > alternative although of course the macro-based approaches I sketch > above can be used to define arrays but not vice versa. > > > Ian. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 10:37:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 10:37:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIdNT-0006s3-Cn; Mon, 01 Oct 2012 10:37:31 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIdNR-0006rn-Nm for xen-devel@lists.xen.org; Mon, 01 Oct 2012 10:37:29 +0000 Received: from [85.158.143.99:47677] by server-2.bemta-4.messagelabs.com id 4D/27-06610-96279605; Mon, 01 Oct 2012 10:37:29 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1349087847!31468439!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI1NjQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6283 invoked from network); 1 Oct 2012 10:37:28 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 10:37:28 -0000 X-IronPort-AV: E=Sophos;i="4.80,515,1344211200"; d="scan'208";a="14865573" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 10:37:27 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 11:37:27 +0100 Date: Mon, 1 Oct 2012 11:36:29 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Anthony PERARD In-Reply-To: <1348744360-2989-5-git-send-email-anthony.perard@citrix.com> Message-ID: References: <1348744360-2989-1-git-send-email-anthony.perard@citrix.com> <1348744360-2989-5-git-send-email-anthony.perard@citrix.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: Avi Kivity , Xen Devel , QEMU-devel , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH V4 4/5] exec, memory: Call to xen_modified_memory. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 27 Sep 2012, Anthony PERARD wrote: > This patch add some calls to xen_modified_memory to notify Xen about dirtybits > during migration. > > Signed-off-by: Anthony PERARD If I am not mistaken, this is the last patch that needs reviewing. Avi, are you OK with it? > exec.c | 1 + > memory.c | 2 ++ > 2 files changed, 3 insertions(+) > > diff --git a/exec.c b/exec.c > index 366684c..1114a09 100644 > --- a/exec.c > +++ b/exec.c > @@ -3427,6 +3427,7 @@ static void invalidate_and_set_dirty(target_phys_addr_t addr, > /* set dirty bit */ > cpu_physical_memory_set_dirty_flags(addr, (0xff & ~CODE_DIRTY_FLAG)); > } > + xen_modified_memory(addr, length); > } > > void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf, > diff --git a/memory.c b/memory.c > index 4f3ade0..015c544 100644 > --- a/memory.c > +++ b/memory.c > @@ -19,6 +19,7 @@ > #include "bitops.h" > #include "kvm.h" > #include > +#include "hw/xen.h" > > #define WANT_EXEC_OBSOLETE > #include "exec-obsolete.h" > @@ -1077,6 +1078,7 @@ void memory_region_set_dirty(MemoryRegion *mr, target_phys_addr_t addr, > target_phys_addr_t size) > { > assert(mr->terminates); > + xen_modified_memory(mr->ram_addr + addr, size); > return cpu_physical_memory_set_dirty_range(mr->ram_addr + addr, size, -1); > } > > -- > Anthony PERARD > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 10:37:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 10:37:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIdNT-0006s3-Cn; Mon, 01 Oct 2012 10:37:31 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIdNR-0006rn-Nm for xen-devel@lists.xen.org; Mon, 01 Oct 2012 10:37:29 +0000 Received: from [85.158.143.99:47677] by server-2.bemta-4.messagelabs.com id 4D/27-06610-96279605; Mon, 01 Oct 2012 10:37:29 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1349087847!31468439!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI1NjQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6283 invoked from network); 1 Oct 2012 10:37:28 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 10:37:28 -0000 X-IronPort-AV: E=Sophos;i="4.80,515,1344211200"; d="scan'208";a="14865573" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 10:37:27 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 11:37:27 +0100 Date: Mon, 1 Oct 2012 11:36:29 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Anthony PERARD In-Reply-To: <1348744360-2989-5-git-send-email-anthony.perard@citrix.com> Message-ID: References: <1348744360-2989-1-git-send-email-anthony.perard@citrix.com> <1348744360-2989-5-git-send-email-anthony.perard@citrix.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: Avi Kivity , Xen Devel , QEMU-devel , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH V4 4/5] exec, memory: Call to xen_modified_memory. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 27 Sep 2012, Anthony PERARD wrote: > This patch add some calls to xen_modified_memory to notify Xen about dirtybits > during migration. > > Signed-off-by: Anthony PERARD If I am not mistaken, this is the last patch that needs reviewing. Avi, are you OK with it? > exec.c | 1 + > memory.c | 2 ++ > 2 files changed, 3 insertions(+) > > diff --git a/exec.c b/exec.c > index 366684c..1114a09 100644 > --- a/exec.c > +++ b/exec.c > @@ -3427,6 +3427,7 @@ static void invalidate_and_set_dirty(target_phys_addr_t addr, > /* set dirty bit */ > cpu_physical_memory_set_dirty_flags(addr, (0xff & ~CODE_DIRTY_FLAG)); > } > + xen_modified_memory(addr, length); > } > > void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf, > diff --git a/memory.c b/memory.c > index 4f3ade0..015c544 100644 > --- a/memory.c > +++ b/memory.c > @@ -19,6 +19,7 @@ > #include "bitops.h" > #include "kvm.h" > #include > +#include "hw/xen.h" > > #define WANT_EXEC_OBSOLETE > #include "exec-obsolete.h" > @@ -1077,6 +1078,7 @@ void memory_region_set_dirty(MemoryRegion *mr, target_phys_addr_t addr, > target_phys_addr_t size) > { > assert(mr->terminates); > + xen_modified_memory(mr->ram_addr + addr, size); > return cpu_physical_memory_set_dirty_range(mr->ram_addr + addr, size, -1); > } > > -- > Anthony PERARD > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 10:41:15 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 10:41:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIdQu-000773-2g; Mon, 01 Oct 2012 10:41:04 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIdQt-00076v-3f for xen-devel@lists.xen.org; Mon, 01 Oct 2012 10:41:03 +0000 Received: from [85.158.138.51:14325] by server-3.bemta-3.messagelabs.com id 3A/A6-25962-E3379605; Mon, 01 Oct 2012 10:41:02 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-16.tower-174.messagelabs.com!1349088037!32532059!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI1NjQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23801 invoked from network); 1 Oct 2012 10:40:38 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 10:40:38 -0000 X-IronPort-AV: E=Sophos;i="4.80,515,1344211200"; d="scan'208";a="14865646" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 10:40:37 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 11:40:37 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TIdQT-0007Ha-6G; Mon, 01 Oct 2012 10:40:37 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TIdQT-0004Z2-21; Mon, 01 Oct 2012 11:40:37 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20585.29476.782177.703044@mariner.uk.xensource.com> Date: Mon, 1 Oct 2012 11:40:36 +0100 To: Keir Fraser , Paul Durrant In-Reply-To: <291EDFCB1E9E224A99088639C4762022EFF91D9F18@LONPMAILBOX01.citrite.net>, References: <20585.27847.174145.345965@mariner.uk.xensource.com> <1348667684-29202-1-git-send-email-paul.durrant@citrix.com> <20581.58542.402088.878499@mariner.uk.xensource.com> <291EDFCB1E9E224A99088639C4762022EFF91D9EE4@LONPMAILBOX01.citrite.net> <291EDFCB1E9E224A99088639C4762022EFF91D9F18@LONPMAILBOX01.citrite.net> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] Use new Xen public header for product numbers and names [and 1 more messages] X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Paul Durrant writes ("RE: [Xen-devel] [PATCH] Use new Xen public header for product numbers and names"): > I liked it so that's what I did :-) I added a terminator entry for > convenience when defining an array. Not needed when defining a > switch statement but harmless since it's a case that should never be > hit. Very well. Keir Fraser writes ("Re: [Xen-devel] [PATCH] Use new Xen public header for product numbers and names"): > My usual way to do this would be to place the list in its own header file: > > pvdrivers_list.h: > EACH(WINDOWS, 0x0001, "xensource-windows") > EACH(...) > ... > > Then e.g., > #define EACH(name,num,string) PVDRIVERS_ID_##name = num, > enum { > #include "pvdrivers_list.h" > } > #undef EACH > > Which is a bit more abstruse on the consuming side, but does avoid the list > itself being an ugly multi-line macro monster. This is fine by me too. Thanks, Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 10:41:15 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 10:41:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIdQu-000773-2g; Mon, 01 Oct 2012 10:41:04 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIdQt-00076v-3f for xen-devel@lists.xen.org; Mon, 01 Oct 2012 10:41:03 +0000 Received: from [85.158.138.51:14325] by server-3.bemta-3.messagelabs.com id 3A/A6-25962-E3379605; Mon, 01 Oct 2012 10:41:02 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-16.tower-174.messagelabs.com!1349088037!32532059!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI1NjQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23801 invoked from network); 1 Oct 2012 10:40:38 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 10:40:38 -0000 X-IronPort-AV: E=Sophos;i="4.80,515,1344211200"; d="scan'208";a="14865646" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 10:40:37 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 11:40:37 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TIdQT-0007Ha-6G; Mon, 01 Oct 2012 10:40:37 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TIdQT-0004Z2-21; Mon, 01 Oct 2012 11:40:37 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20585.29476.782177.703044@mariner.uk.xensource.com> Date: Mon, 1 Oct 2012 11:40:36 +0100 To: Keir Fraser , Paul Durrant In-Reply-To: <291EDFCB1E9E224A99088639C4762022EFF91D9F18@LONPMAILBOX01.citrite.net>, References: <20585.27847.174145.345965@mariner.uk.xensource.com> <1348667684-29202-1-git-send-email-paul.durrant@citrix.com> <20581.58542.402088.878499@mariner.uk.xensource.com> <291EDFCB1E9E224A99088639C4762022EFF91D9EE4@LONPMAILBOX01.citrite.net> <291EDFCB1E9E224A99088639C4762022EFF91D9F18@LONPMAILBOX01.citrite.net> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] Use new Xen public header for product numbers and names [and 1 more messages] X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Paul Durrant writes ("RE: [Xen-devel] [PATCH] Use new Xen public header for product numbers and names"): > I liked it so that's what I did :-) I added a terminator entry for > convenience when defining an array. Not needed when defining a > switch statement but harmless since it's a case that should never be > hit. Very well. Keir Fraser writes ("Re: [Xen-devel] [PATCH] Use new Xen public header for product numbers and names"): > My usual way to do this would be to place the list in its own header file: > > pvdrivers_list.h: > EACH(WINDOWS, 0x0001, "xensource-windows") > EACH(...) > ... > > Then e.g., > #define EACH(name,num,string) PVDRIVERS_ID_##name = num, > enum { > #include "pvdrivers_list.h" > } > #undef EACH > > Which is a bit more abstruse on the consuming side, but does avoid the list > itself being an ugly multi-line macro monster. This is fine by me too. Thanks, Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 11:37:36 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 11:37:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIeJA-0007mE-Bj; Mon, 01 Oct 2012 11:37:08 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIeJ9-0007m0-7O for xen-devel@lists.xen.org; Mon, 01 Oct 2012 11:37:07 +0000 Received: from [85.158.139.83:57969] by server-4.bemta-5.messagelabs.com id E1/58-20767-26089605; Mon, 01 Oct 2012 11:37:06 +0000 X-Env-Sender: daniel.kiper@oracle.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1349091423!25642963!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzc0OTkw\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29684 invoked from network); 1 Oct 2012 11:37:05 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 11:37:05 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q91Bawxa019089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Oct 2012 11:36:59 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q91BawT7026720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Oct 2012 11:36:58 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q91BavM9032226; Mon, 1 Oct 2012 06:36:57 -0500 Received: from host-192-168-1-59.local.net-space.pl (/89.174.63.77) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 01 Oct 2012 04:36:57 -0700 Date: Mon, 1 Oct 2012 13:36:43 +0200 From: Daniel Kiper To: Jan Beulich Message-ID: <20121001113046.GA2942@host-192-168-1-59.local.net-space.pl> References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-2-git-send-email-daniel.kiper@oracle.com> <5065729C020000780009E63B@nat28.tlf.novell.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <5065729C020000780009E63B@nat28.tlf.novell.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: andrew.cooper3@citrix.com, konrad.wilk@oracle.com, linux-kernel@vger.kernel.org, xen-devel Subject: Re: [Xen-devel] [PATCH 01/11] kexec: introduce kexec_ops struct X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, Sep 28, 2012 at 08:49:16AM +0100, Jan Beulich wrote: > >>> On 27.09.12 at 20:06, Daniel Kiper wrote: > > Some kexec/kdump implementations (e.g. Xen PVOPS) on different archs could > > not use default functions or require some changes in behavior of kexec/kdump > > generic code. To cope with that problem kexec_ops struct was introduced. > > It allows a developer to replace all or some functions and control some > > functionality of kexec/kdump generic code. > > I'm not convinced that doing this at the architecture independent > layer is really necessary/desirable. Nevertheless, if that's the right > place, then everything else looks good to me, except for a > cosmetic thing: I do not like this patch, too. However, this is the simplest solution. If you do not do that in that way then you must duplicate most of kernel/kexec.c functionality in architecture depndent files. > > @@ -392,7 +435,7 @@ static void kimage_free_page_list(struct list_head *list) > > > > page = list_entry(pos, struct page, lru); > > list_del(&page->lru); > > - kimage_free_pages(page); > > + (*kexec_ops.kimage_free_pages)(page); > > These constructs are generally better readable without the > explicit yet redundant indirection: > > kexec_ops.kimage_free_pages(page); I have done that in that way because during my work on memory hotplug Andrew Morton aligned my patches to that syntax. However, I do not insist on staying with it. Daniel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 11:37:36 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 11:37:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIeJA-0007mE-Bj; Mon, 01 Oct 2012 11:37:08 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIeJ9-0007m0-7O for xen-devel@lists.xen.org; Mon, 01 Oct 2012 11:37:07 +0000 Received: from [85.158.139.83:57969] by server-4.bemta-5.messagelabs.com id E1/58-20767-26089605; Mon, 01 Oct 2012 11:37:06 +0000 X-Env-Sender: daniel.kiper@oracle.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1349091423!25642963!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzc0OTkw\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29684 invoked from network); 1 Oct 2012 11:37:05 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 11:37:05 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q91Bawxa019089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Oct 2012 11:36:59 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q91BawT7026720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Oct 2012 11:36:58 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q91BavM9032226; Mon, 1 Oct 2012 06:36:57 -0500 Received: from host-192-168-1-59.local.net-space.pl (/89.174.63.77) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 01 Oct 2012 04:36:57 -0700 Date: Mon, 1 Oct 2012 13:36:43 +0200 From: Daniel Kiper To: Jan Beulich Message-ID: <20121001113046.GA2942@host-192-168-1-59.local.net-space.pl> References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-2-git-send-email-daniel.kiper@oracle.com> <5065729C020000780009E63B@nat28.tlf.novell.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <5065729C020000780009E63B@nat28.tlf.novell.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: andrew.cooper3@citrix.com, konrad.wilk@oracle.com, linux-kernel@vger.kernel.org, xen-devel Subject: Re: [Xen-devel] [PATCH 01/11] kexec: introduce kexec_ops struct X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, Sep 28, 2012 at 08:49:16AM +0100, Jan Beulich wrote: > >>> On 27.09.12 at 20:06, Daniel Kiper wrote: > > Some kexec/kdump implementations (e.g. Xen PVOPS) on different archs could > > not use default functions or require some changes in behavior of kexec/kdump > > generic code. To cope with that problem kexec_ops struct was introduced. > > It allows a developer to replace all or some functions and control some > > functionality of kexec/kdump generic code. > > I'm not convinced that doing this at the architecture independent > layer is really necessary/desirable. Nevertheless, if that's the right > place, then everything else looks good to me, except for a > cosmetic thing: I do not like this patch, too. However, this is the simplest solution. If you do not do that in that way then you must duplicate most of kernel/kexec.c functionality in architecture depndent files. > > @@ -392,7 +435,7 @@ static void kimage_free_page_list(struct list_head *list) > > > > page = list_entry(pos, struct page, lru); > > list_del(&page->lru); > > - kimage_free_pages(page); > > + (*kexec_ops.kimage_free_pages)(page); > > These constructs are generally better readable without the > explicit yet redundant indirection: > > kexec_ops.kimage_free_pages(page); I have done that in that way because during my work on memory hotplug Andrew Morton aligned my patches to that syntax. However, I do not insist on staying with it. Daniel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 11:39:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 11:39:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIeLH-0007s3-UP; Mon, 01 Oct 2012 11:39:19 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIeLG-0007ru-7y for xen-devel@lists.xensource.com; Mon, 01 Oct 2012 11:39:18 +0000 Received: from [85.158.138.51:28475] by server-9.bemta-3.messagelabs.com id B1/5B-20338-5E089605; Mon, 01 Oct 2012 11:39:17 +0000 X-Env-Sender: matej.zary@cvtisr.sk X-Msg-Ref: server-15.tower-174.messagelabs.com!1349091556!30839896!1 X-Originating-IP: [193.87.7.3] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14616 invoked from network); 1 Oct 2012 11:39:16 -0000 Received: from virgo.cvtisr.sk (HELO mail.cvtisr.sk) (193.87.7.3) by server-15.tower-174.messagelabs.com with SMTP; 1 Oct 2012 11:39:16 -0000 Received: from localhost (unknown [127.0.0.1]) by mail.cvtisr.sk (Postfix) with ESMTP id 3E1FD92E57; Mon, 1 Oct 2012 14:23:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at cvtisr.sk Received: from mail.cvtisr.sk ([127.0.0.1]) by localhost (mail.cvtisr.sk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htOgtD+lm2we; Mon, 1 Oct 2012 14:23:17 +0200 (CEST) Received: from aries.space.cvtisr.sk (unknown [192.168.1.51]) by mail.cvtisr.sk (Postfix) with ESMTP id 583BA92D7C; Mon, 1 Oct 2012 14:23:17 +0200 (CEST) Received: from Aries.space.cvtisr.sk ([::1]) by aries.space.cvtisr.sk ([::1]) with mapi; Mon, 1 Oct 2012 13:39:12 +0200 From: Zary Matej To: Mauro , =?iso-8859-2?Q?Pasi_K=E4rkk=E4inen?= Date: Mon, 1 Oct 2012 13:39:11 +0200 Thread-Topic: [Xen-users] [Xen-devel] Re: Xen 4 TSC problems Thread-Index: Ac2fQtLZ1TaTmbmgT4qXplstV7DiIAAhUT1Q Message-ID: <5DB0519124BB3D4DBEEB14426D4AC7EA6A72C9D58E@aries.space.cvtisr.sk> References: <65395f62-74e5-4910-b701-8df629c2ce3b@default> <20120930151314.GU8912@reaktio.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: Dan Magenheimer , "xen-devel@lists.xensource.com" , Keir Fraser , Jeremy Fitzhardinge , Olivier Hanesse , Keir Fraser , Xen Users , Mark Adams Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >From: xen-users-bounces@lists.xen.org [xen-users-bounces@lists.xen.org] On= Behalf Of Mauro [mrsanna1@gmail.com] >On 30 September 2012 17:13, Pasi K=E4rkk=E4inen wrote: >> On Sat, Sep 29, 2012 at 02:19:55PM +0200, Mauro wrote: >>> It's happened another time, system date 50 minutes ahead. >>> There is really no solution? >>> >> >> Try with a recent Xen hypervisor version. Xen 4.1.3 or 4.2.0. >> It helps a lot to know if the issue is still in the latest hypervisor ve= rsions or not. > >I'm using debian squeeze xen kernel and this kernel has xen 4.0. > Xen and kernel are two different things, you can mix and match them in many= ways. If you don't want to compile from source, use Xen packages from Debi= an Wheezy (4.1.3-2), Sid (4.1.3-3) or Experimental (4.2.0-1). I doubt you w= ill move forward without trying newer versions no matter how many mails you= write to list (all the people) ... :) Matej _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 11:39:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 11:39:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIeLH-0007s3-UP; Mon, 01 Oct 2012 11:39:19 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIeLG-0007ru-7y for xen-devel@lists.xensource.com; Mon, 01 Oct 2012 11:39:18 +0000 Received: from [85.158.138.51:28475] by server-9.bemta-3.messagelabs.com id B1/5B-20338-5E089605; Mon, 01 Oct 2012 11:39:17 +0000 X-Env-Sender: matej.zary@cvtisr.sk X-Msg-Ref: server-15.tower-174.messagelabs.com!1349091556!30839896!1 X-Originating-IP: [193.87.7.3] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14616 invoked from network); 1 Oct 2012 11:39:16 -0000 Received: from virgo.cvtisr.sk (HELO mail.cvtisr.sk) (193.87.7.3) by server-15.tower-174.messagelabs.com with SMTP; 1 Oct 2012 11:39:16 -0000 Received: from localhost (unknown [127.0.0.1]) by mail.cvtisr.sk (Postfix) with ESMTP id 3E1FD92E57; Mon, 1 Oct 2012 14:23:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at cvtisr.sk Received: from mail.cvtisr.sk ([127.0.0.1]) by localhost (mail.cvtisr.sk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htOgtD+lm2we; Mon, 1 Oct 2012 14:23:17 +0200 (CEST) Received: from aries.space.cvtisr.sk (unknown [192.168.1.51]) by mail.cvtisr.sk (Postfix) with ESMTP id 583BA92D7C; Mon, 1 Oct 2012 14:23:17 +0200 (CEST) Received: from Aries.space.cvtisr.sk ([::1]) by aries.space.cvtisr.sk ([::1]) with mapi; Mon, 1 Oct 2012 13:39:12 +0200 From: Zary Matej To: Mauro , =?iso-8859-2?Q?Pasi_K=E4rkk=E4inen?= Date: Mon, 1 Oct 2012 13:39:11 +0200 Thread-Topic: [Xen-users] [Xen-devel] Re: Xen 4 TSC problems Thread-Index: Ac2fQtLZ1TaTmbmgT4qXplstV7DiIAAhUT1Q Message-ID: <5DB0519124BB3D4DBEEB14426D4AC7EA6A72C9D58E@aries.space.cvtisr.sk> References: <65395f62-74e5-4910-b701-8df629c2ce3b@default> <20120930151314.GU8912@reaktio.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: Dan Magenheimer , "xen-devel@lists.xensource.com" , Keir Fraser , Jeremy Fitzhardinge , Olivier Hanesse , Keir Fraser , Xen Users , Mark Adams Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >From: xen-users-bounces@lists.xen.org [xen-users-bounces@lists.xen.org] On= Behalf Of Mauro [mrsanna1@gmail.com] >On 30 September 2012 17:13, Pasi K=E4rkk=E4inen wrote: >> On Sat, Sep 29, 2012 at 02:19:55PM +0200, Mauro wrote: >>> It's happened another time, system date 50 minutes ahead. >>> There is really no solution? >>> >> >> Try with a recent Xen hypervisor version. Xen 4.1.3 or 4.2.0. >> It helps a lot to know if the issue is still in the latest hypervisor ve= rsions or not. > >I'm using debian squeeze xen kernel and this kernel has xen 4.0. > Xen and kernel are two different things, you can mix and match them in many= ways. If you don't want to compile from source, use Xen packages from Debi= an Wheezy (4.1.3-2), Sid (4.1.3-3) or Experimental (4.2.0-1). I doubt you w= ill move forward without trying newer versions no matter how many mails you= write to list (all the people) ... :) Matej _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 12:53:37 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 12:53:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIfUk-0000wh-ES; Mon, 01 Oct 2012 12:53:10 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIfUi-0000wZ-VM for xen-devel@lists.xen.org; Mon, 01 Oct 2012 12:53:09 +0000 Received: from [85.158.138.51:35739] by server-14.bemta-3.messagelabs.com id AB/75-25886-43299605; Mon, 01 Oct 2012 12:53:08 +0000 X-Env-Sender: daniel.kiper@oracle.com X-Msg-Ref: server-3.tower-174.messagelabs.com!1349095985!24558725!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc4NTAwMQ==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25703 invoked from network); 1 Oct 2012 12:53:07 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 12:53:07 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q91Cr2b3028405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Oct 2012 12:53:02 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q91Cr0SB000435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Oct 2012 12:53:01 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q91Cr00r003812; Mon, 1 Oct 2012 07:53:00 -0500 Received: from host-192-168-1-59.local.net-space.pl (/89.174.63.77) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 01 Oct 2012 05:53:00 -0700 Date: Mon, 1 Oct 2012 14:52:52 +0200 From: Daniel Kiper To: Jan Beulich Message-ID: <20121001125252.GB2942@host-192-168-1-59.local.net-space.pl> References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-2-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-3-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-4-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-5-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-6-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-7-git-send-email-daniel.kiper@oracle.com> <506577E3020000780009E65B@nat28.tlf.novell.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <506577E3020000780009E65B@nat28.tlf.novell.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: andrew.cooper3@citrix.com, konrad.wilk@oracle.com, linux-kernel@vger.kernel.org, xen-devel Subject: Re: [Xen-devel] [PATCH 06/11] x86/xen: Add i386 kexec/kdump implementation X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, Sep 28, 2012 at 09:11:47AM +0100, Jan Beulich wrote: > >>> On 27.09.12 at 20:06, Daniel Kiper wrote: > > Add i386 kexec/kdump implementation. > > So this as well as the subsequent patch introduces quite a bit of > duplicate code. The old 2.6.18 kernel had an initial pair of cleanup > patches (attached in their forward ported form for 3.6-rc6) that > would allow reducing the amount of duplication, particularly by > eliminating the need to clone relocate_kernel_??.S altogether. Thanks. Please look below for more details. > Additionally, in the PAE case (which is the only relevant one for > a 32-bit Xen kernel) I'm missing the address restriction > enforcement for the PGD, without which the __ma() conversion > result may not fit into the field it gets stored into. Right. > Finally, as noticed in an earlier patch already, you appear to > re-introduce stuff long dropped from the kernel - the forward > ported kernels get away with just setting PA_CONTROL_PAGE, > PA_PGD, and PA_SWAP_PAGE in the page list. Since the number > and purpose of the pages is established entirely by the guest > kernel, all you need to obey is that the hypervisor expects > alternating PA_/VA_ pairs (where the VA_ ones can be left > unpopulated). Perhaps taking a look at a recent SLES kernel > would help... I have got ftp://ftp.suse.com/pub/projects/kernel/kotd/SLE11-SP2/src/kernel-source-3.0.43-6.1.src.rpm. Does kexec/kdump work in your environment? In my it does not. At least there is wrong assumption that vaddr = (unsigned long)relocate_kernel gets virtual address of relocate_kernel in Xen (I have tested only x86_64 implementation but as I saw i386 has similar problem). In real it is fix mapped in hypervisor which is completely different than address calculated in dom0 kernel. Virtual address of control page (and others) is only known by hypervisor kexec/kdump functions. It means that transition page table could be established by relocate_kernel code only. If you would like to do optimistation as you mentioned above you must reintroduce code for page table establishment into generic relocate_kernel_??.S. However, another problem arises. New generic code utilizes additional arguments such as swap page (and potentially could use others in the future). As I saw it is not possible to pass extra addresses through page_list[] in struct xen_kexec_image because its has insufficient size (I mean x86_64 because i386 is a bit different story). That is why relocate kernel code for Xen should stay (sadly) in separate files. Daniel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 12:53:37 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 12:53:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIfUk-0000wh-ES; Mon, 01 Oct 2012 12:53:10 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIfUi-0000wZ-VM for xen-devel@lists.xen.org; Mon, 01 Oct 2012 12:53:09 +0000 Received: from [85.158.138.51:35739] by server-14.bemta-3.messagelabs.com id AB/75-25886-43299605; Mon, 01 Oct 2012 12:53:08 +0000 X-Env-Sender: daniel.kiper@oracle.com X-Msg-Ref: server-3.tower-174.messagelabs.com!1349095985!24558725!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc4NTAwMQ==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25703 invoked from network); 1 Oct 2012 12:53:07 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 12:53:07 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q91Cr2b3028405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Oct 2012 12:53:02 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q91Cr0SB000435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Oct 2012 12:53:01 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q91Cr00r003812; Mon, 1 Oct 2012 07:53:00 -0500 Received: from host-192-168-1-59.local.net-space.pl (/89.174.63.77) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 01 Oct 2012 05:53:00 -0700 Date: Mon, 1 Oct 2012 14:52:52 +0200 From: Daniel Kiper To: Jan Beulich Message-ID: <20121001125252.GB2942@host-192-168-1-59.local.net-space.pl> References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-2-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-3-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-4-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-5-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-6-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-7-git-send-email-daniel.kiper@oracle.com> <506577E3020000780009E65B@nat28.tlf.novell.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <506577E3020000780009E65B@nat28.tlf.novell.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: andrew.cooper3@citrix.com, konrad.wilk@oracle.com, linux-kernel@vger.kernel.org, xen-devel Subject: Re: [Xen-devel] [PATCH 06/11] x86/xen: Add i386 kexec/kdump implementation X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, Sep 28, 2012 at 09:11:47AM +0100, Jan Beulich wrote: > >>> On 27.09.12 at 20:06, Daniel Kiper wrote: > > Add i386 kexec/kdump implementation. > > So this as well as the subsequent patch introduces quite a bit of > duplicate code. The old 2.6.18 kernel had an initial pair of cleanup > patches (attached in their forward ported form for 3.6-rc6) that > would allow reducing the amount of duplication, particularly by > eliminating the need to clone relocate_kernel_??.S altogether. Thanks. Please look below for more details. > Additionally, in the PAE case (which is the only relevant one for > a 32-bit Xen kernel) I'm missing the address restriction > enforcement for the PGD, without which the __ma() conversion > result may not fit into the field it gets stored into. Right. > Finally, as noticed in an earlier patch already, you appear to > re-introduce stuff long dropped from the kernel - the forward > ported kernels get away with just setting PA_CONTROL_PAGE, > PA_PGD, and PA_SWAP_PAGE in the page list. Since the number > and purpose of the pages is established entirely by the guest > kernel, all you need to obey is that the hypervisor expects > alternating PA_/VA_ pairs (where the VA_ ones can be left > unpopulated). Perhaps taking a look at a recent SLES kernel > would help... I have got ftp://ftp.suse.com/pub/projects/kernel/kotd/SLE11-SP2/src/kernel-source-3.0.43-6.1.src.rpm. Does kexec/kdump work in your environment? In my it does not. At least there is wrong assumption that vaddr = (unsigned long)relocate_kernel gets virtual address of relocate_kernel in Xen (I have tested only x86_64 implementation but as I saw i386 has similar problem). In real it is fix mapped in hypervisor which is completely different than address calculated in dom0 kernel. Virtual address of control page (and others) is only known by hypervisor kexec/kdump functions. It means that transition page table could be established by relocate_kernel code only. If you would like to do optimistation as you mentioned above you must reintroduce code for page table establishment into generic relocate_kernel_??.S. However, another problem arises. New generic code utilizes additional arguments such as swap page (and potentially could use others in the future). As I saw it is not possible to pass extra addresses through page_list[] in struct xen_kexec_image because its has insufficient size (I mean x86_64 because i386 is a bit different story). That is why relocate kernel code for Xen should stay (sadly) in separate files. Daniel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 13:02:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 13:02:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIfdP-0001CT-O6; Mon, 01 Oct 2012 13:02:07 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIfdO-0001CO-Ds for xen-devel@lists.xen.org; Mon, 01 Oct 2012 13:02:06 +0000 Received: from [85.158.138.51:61717] by server-9.bemta-3.messagelabs.com id 72/FC-20338-D4499605; Mon, 01 Oct 2012 13:02:05 +0000 X-Env-Sender: daniel.kiper@oracle.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1349096523!32593914!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc4NTAwMQ==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17801 invoked from network); 1 Oct 2012 13:02:04 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 13:02:04 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q91D20Js005283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Oct 2012 13:02:01 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q91D1xLS011751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Oct 2012 13:02:00 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q91D1xbr014991; Mon, 1 Oct 2012 08:01:59 -0500 Received: from host-192-168-1-59.local.net-space.pl (/89.174.63.77) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 01 Oct 2012 06:01:58 -0700 Date: Mon, 1 Oct 2012 15:01:51 +0200 From: Daniel Kiper To: Jan Beulich Message-ID: <20121001130151.GC2942@host-192-168-1-59.local.net-space.pl> References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-2-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-3-git-send-email-daniel.kiper@oracle.com> <50657462020000780009E64A@nat28.tlf.novell.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <50657462020000780009E64A@nat28.tlf.novell.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: andrew.cooper3@citrix.com, konrad.wilk@oracle.com, linux-kernel@vger.kernel.org, xen-devel Subject: Re: [Xen-devel] [PATCH 02/11] x86/kexec: Add extra pointers to transition page table PGD, PUD, PMD and PTE X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, Sep 28, 2012 at 08:56:50AM +0100, Jan Beulich wrote: > >>> On 27.09.12 at 20:06, Daniel Kiper wrote: > > Some implementations (e.g. Xen PVOPS) could not use part of identity page > > table to construct transition page table. It means that they require separate > > PUDs, PMDs and PTEs for virtual and physical (identity) mapping. To satisfy that > > requirement add extra pointer to PGD, PUD, PMD and PTE and align existing > > code. > > I'm puzzled by this - why would you need to reintroduce what had > been dropped a long time ago, when the forward ported kernels > don't need it? Xen itself doesn't need the extra entries, their > presence is purely a requirement of the specific kernel > implementation afaict. Hmmm... I will try to optimize that a bit. Daniel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 13:02:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 13:02:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIfdP-0001CT-O6; Mon, 01 Oct 2012 13:02:07 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIfdO-0001CO-Ds for xen-devel@lists.xen.org; Mon, 01 Oct 2012 13:02:06 +0000 Received: from [85.158.138.51:61717] by server-9.bemta-3.messagelabs.com id 72/FC-20338-D4499605; Mon, 01 Oct 2012 13:02:05 +0000 X-Env-Sender: daniel.kiper@oracle.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1349096523!32593914!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc4NTAwMQ==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17801 invoked from network); 1 Oct 2012 13:02:04 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 13:02:04 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q91D20Js005283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Oct 2012 13:02:01 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q91D1xLS011751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Oct 2012 13:02:00 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q91D1xbr014991; Mon, 1 Oct 2012 08:01:59 -0500 Received: from host-192-168-1-59.local.net-space.pl (/89.174.63.77) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 01 Oct 2012 06:01:58 -0700 Date: Mon, 1 Oct 2012 15:01:51 +0200 From: Daniel Kiper To: Jan Beulich Message-ID: <20121001130151.GC2942@host-192-168-1-59.local.net-space.pl> References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-2-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-3-git-send-email-daniel.kiper@oracle.com> <50657462020000780009E64A@nat28.tlf.novell.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <50657462020000780009E64A@nat28.tlf.novell.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: andrew.cooper3@citrix.com, konrad.wilk@oracle.com, linux-kernel@vger.kernel.org, xen-devel Subject: Re: [Xen-devel] [PATCH 02/11] x86/kexec: Add extra pointers to transition page table PGD, PUD, PMD and PTE X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, Sep 28, 2012 at 08:56:50AM +0100, Jan Beulich wrote: > >>> On 27.09.12 at 20:06, Daniel Kiper wrote: > > Some implementations (e.g. Xen PVOPS) could not use part of identity page > > table to construct transition page table. It means that they require separate > > PUDs, PMDs and PTEs for virtual and physical (identity) mapping. To satisfy that > > requirement add extra pointer to PGD, PUD, PMD and PTE and align existing > > code. > > I'm puzzled by this - why would you need to reintroduce what had > been dropped a long time ago, when the forward ported kernels > don't need it? Xen itself doesn't need the extra entries, their > presence is purely a requirement of the specific kernel > implementation afaict. Hmmm... I will try to optimize that a bit. Daniel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 13:16:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 13:16:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIfrM-0001er-5g; Mon, 01 Oct 2012 13:16:32 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIfrK-0001eg-NG for xen-devel@lists.xensource.com; Mon, 01 Oct 2012 13:16:31 +0000 Received: from [85.158.143.35:31552] by server-1.bemta-4.messagelabs.com id F2/6F-05684-EA799605; Mon, 01 Oct 2012 13:16:30 +0000 X-Env-Sender: daniel.kiper@oracle.com X-Msg-Ref: server-16.tower-21.messagelabs.com!1349097385!14347931!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc4NTAwMQ==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25424 invoked from network); 1 Oct 2012 13:16:27 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 13:16:27 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q91DGKlx022521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Oct 2012 13:16:21 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q91DGJ7i018921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Oct 2012 13:16:20 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q91DGJTu000751; Mon, 1 Oct 2012 08:16:19 -0500 Received: from host-192-168-1-59.local.net-space.pl (/89.174.63.77) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 01 Oct 2012 06:16:18 -0700 Date: Mon, 1 Oct 2012 15:16:11 +0200 From: Daniel Kiper To: Konrad Rzeszutek Wilk Message-ID: <20121001131611.GD2942@host-192-168-1-59.local.net-space.pl> References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-2-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-3-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-4-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-5-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-6-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-7-git-send-email-daniel.kiper@oracle.com> <20120928163941.GD16262@localhost.localdomain> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120928163941.GD16262@localhost.localdomain> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: andrew.cooper3@citrix.com, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, jbeulich@suse.com Subject: Re: [Xen-devel] [PATCH 06/11] x86/xen: Add i386 kexec/kdump implementation X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, Sep 28, 2012 at 12:39:44PM -0400, Konrad Rzeszutek Wilk wrote: > On Thu, Sep 27, 2012 at 08:06:33PM +0200, Daniel Kiper wrote: > > Add i386 kexec/kdump implementation. > > > > Signed-off-by: Daniel Kiper > > --- > > arch/x86/xen/machine_kexec_32.c | 245 ++++++++++++++++++++++++++++ > > arch/x86/xen/relocate_kernel_32.S | 323 +++++++++++++++++++++++++++++++++++++ > > 2 files changed, 568 insertions(+), 0 deletions(-) > > create mode 100644 arch/x86/xen/machine_kexec_32.c > > create mode 100644 arch/x86/xen/relocate_kernel_32.S > > > > diff --git a/arch/x86/xen/machine_kexec_32.c b/arch/x86/xen/machine_kexec_32.c > > new file mode 100644 > > index 0000000..6b5141e > > --- /dev/null > > +++ b/arch/x86/xen/machine_kexec_32.c > > @@ -0,0 +1,245 @@ > > +/* > > + * Copyright (c) 2011 Daniel Kiper > > + * Copyright (c) 2012 Daniel Kiper, Oracle Corporation > > + * > > + * kexec/kdump implementation for Xen was written by Daniel Kiper. > > + * Initial work on it was sponsored by Google under Google Summer > > + * of Code 2011 program and Citrix. Konrad Rzeszutek Wilk from Oracle > > + * was the mentor for this project. > > + * > > + * Some ideas are taken from: > > + * - native kexec/kdump implementation, > > + * - kexec/kdump implementation for Xen Linux Kernel Ver. 2.6.18, > > + * - PV-GRUB. > > + * > > + * This program is free software; you can redistribute it and/or modify > > + * it under the terms of the GNU General Public License as published by > > + * the Free Software Foundation; either version 2 of the License, or > > + * (at your option) any later version. > > + * > > + * This program is distributed in the hope that it will be useful, > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > > + * GNU General Public License for more details. > > + * > > + * You should have received a copy of the GNU General Public License along > > + * with this program. If not, see . > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#include > > +#include > > + > > +#include > > +#include > > +#include > > + > > +#define __ma(vaddr) (virt_to_machine(vaddr).maddr) > > + > > +static struct page *kimage_alloc_pages(gfp_t gfp_mask, > > + unsigned int order, > > + unsigned long limit) > > +{ > > + struct page *pages; > > + unsigned int address_bits, i; > > + > > + pages = alloc_pages(gfp_mask, order); > > + > > + if (!pages) > > + return NULL; > > + > > + address_bits = (limit == ULONG_MAX) ? BITS_PER_LONG : ilog2(limit); > > + > > + /* Relocate set of pages below given limit. */ > > + if (xen_create_contiguous_region((unsigned long)page_address(pages), > > + order, address_bits)) { > > + __free_pages(pages, order); > > + return NULL; > > + } > > + > > + pages->mapping = NULL; > > It shouldn't matter (as you did the alloc_page) but could you > add: > BUG_ON(PagePrivate(pages)) > in case somebody did do something weird beforehand. OK. > > + set_page_private(pages, order); > > + > > + for (i = 0; i < (1 << order); ++i) > > + SetPageReserved(pages + i); > > + > > + return pages; > > +} > > + > > +static void kimage_free_pages(struct page *page) > > +{ > > + unsigned int i, order; > > + > > + order = page_private(page); > > + > > + for (i = 0; i < (1 << order); ++i) > > + ClearPageReserved(page + i); > > + > > + xen_destroy_contiguous_region((unsigned long)page_address(page), order); > > + __free_pages(page, order); > > +} > > + > > +static unsigned long xen_page_to_mfn(struct page *page) > > +{ > > + return pfn_to_mfn(page_to_pfn(page)); > > +} > > + > > +static struct page *xen_mfn_to_page(unsigned long mfn) > > +{ > > + return pfn_to_page(mfn_to_pfn(mfn)); > > +} > > + > > +static unsigned long xen_virt_to_machine(volatile void *address) > > +{ > > + return virt_to_machine(address).maddr; > > +} > > + > > +static void *xen_machine_to_virt(unsigned long address) > > +{ > > + return phys_to_virt(machine_to_phys(XMADDR(address)).paddr); > > +} > > + > > +static void free_transition_pgtable(struct kimage *image) > > +{ > > + free_page((unsigned long)image->arch.pgd); > > + free_page((unsigned long)image->arch.pmd0); > > + free_page((unsigned long)image->arch.pmd1); > > + free_page((unsigned long)image->arch.pte0); > > + free_page((unsigned long)image->arch.pte1); > > +} > > + > > +static int alloc_transition_pgtable(struct kimage *image) > > +{ > > + image->arch.pgd = (pgd_t *)get_zeroed_page(GFP_KERNEL); > > + > > + if (!image->arch.pgd) > > + goto err; > > + > > + image->arch.pmd0 = (pmd_t *)get_zeroed_page(GFP_KERNEL); > > + > > + if (!image->arch.pmd0) > > + goto err; > > + > > + image->arch.pmd1 = (pmd_t *)get_zeroed_page(GFP_KERNEL); > > + > > + if (!image->arch.pmd1) > > + goto err; > > + > > + image->arch.pte0 = (pte_t *)get_zeroed_page(GFP_KERNEL); > > + > > + if (!image->arch.pte0) > > + goto err; > > + > > + image->arch.pte1 = (pte_t *)get_zeroed_page(GFP_KERNEL); > > + > > + if (!image->arch.pte1) > > + goto err; > > + > > + return 0; > > + > > +err: > > + free_transition_pgtable(image); > > + > > + return -ENOMEM; > > +} > > + > > +static int machine_xen_kexec_prepare(struct kimage *image) > > +{ > > +#ifdef CONFIG_KEXEC_JUMP > > + if (image->preserve_context) { > > + pr_info_once("kexec: Context preservation is not " > > + "supported in Xen domains.\n"); > > + return -ENOSYS; > > + } > > +#endif > > + > > + return alloc_transition_pgtable(image); > > +} > > + > > +static int machine_xen_kexec_load(struct kimage *image) > > +{ > > + void *control_page; > > + struct xen_kexec_load xkl = {}; > > + > > + if (!image) > > + return 0; > > Not -EINVAL? No, if image == NULL then it means that image is unloaded from memory and there is nothing to do by machine_xen_kexec_load(). Daniel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 13:16:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 13:16:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIfrM-0001er-5g; Mon, 01 Oct 2012 13:16:32 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIfrK-0001eg-NG for xen-devel@lists.xensource.com; Mon, 01 Oct 2012 13:16:31 +0000 Received: from [85.158.143.35:31552] by server-1.bemta-4.messagelabs.com id F2/6F-05684-EA799605; Mon, 01 Oct 2012 13:16:30 +0000 X-Env-Sender: daniel.kiper@oracle.com X-Msg-Ref: server-16.tower-21.messagelabs.com!1349097385!14347931!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc4NTAwMQ==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25424 invoked from network); 1 Oct 2012 13:16:27 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 13:16:27 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q91DGKlx022521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Oct 2012 13:16:21 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q91DGJ7i018921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Oct 2012 13:16:20 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q91DGJTu000751; Mon, 1 Oct 2012 08:16:19 -0500 Received: from host-192-168-1-59.local.net-space.pl (/89.174.63.77) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 01 Oct 2012 06:16:18 -0700 Date: Mon, 1 Oct 2012 15:16:11 +0200 From: Daniel Kiper To: Konrad Rzeszutek Wilk Message-ID: <20121001131611.GD2942@host-192-168-1-59.local.net-space.pl> References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-2-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-3-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-4-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-5-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-6-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-7-git-send-email-daniel.kiper@oracle.com> <20120928163941.GD16262@localhost.localdomain> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120928163941.GD16262@localhost.localdomain> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: andrew.cooper3@citrix.com, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, jbeulich@suse.com Subject: Re: [Xen-devel] [PATCH 06/11] x86/xen: Add i386 kexec/kdump implementation X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, Sep 28, 2012 at 12:39:44PM -0400, Konrad Rzeszutek Wilk wrote: > On Thu, Sep 27, 2012 at 08:06:33PM +0200, Daniel Kiper wrote: > > Add i386 kexec/kdump implementation. > > > > Signed-off-by: Daniel Kiper > > --- > > arch/x86/xen/machine_kexec_32.c | 245 ++++++++++++++++++++++++++++ > > arch/x86/xen/relocate_kernel_32.S | 323 +++++++++++++++++++++++++++++++++++++ > > 2 files changed, 568 insertions(+), 0 deletions(-) > > create mode 100644 arch/x86/xen/machine_kexec_32.c > > create mode 100644 arch/x86/xen/relocate_kernel_32.S > > > > diff --git a/arch/x86/xen/machine_kexec_32.c b/arch/x86/xen/machine_kexec_32.c > > new file mode 100644 > > index 0000000..6b5141e > > --- /dev/null > > +++ b/arch/x86/xen/machine_kexec_32.c > > @@ -0,0 +1,245 @@ > > +/* > > + * Copyright (c) 2011 Daniel Kiper > > + * Copyright (c) 2012 Daniel Kiper, Oracle Corporation > > + * > > + * kexec/kdump implementation for Xen was written by Daniel Kiper. > > + * Initial work on it was sponsored by Google under Google Summer > > + * of Code 2011 program and Citrix. Konrad Rzeszutek Wilk from Oracle > > + * was the mentor for this project. > > + * > > + * Some ideas are taken from: > > + * - native kexec/kdump implementation, > > + * - kexec/kdump implementation for Xen Linux Kernel Ver. 2.6.18, > > + * - PV-GRUB. > > + * > > + * This program is free software; you can redistribute it and/or modify > > + * it under the terms of the GNU General Public License as published by > > + * the Free Software Foundation; either version 2 of the License, or > > + * (at your option) any later version. > > + * > > + * This program is distributed in the hope that it will be useful, > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > > + * GNU General Public License for more details. > > + * > > + * You should have received a copy of the GNU General Public License along > > + * with this program. If not, see . > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#include > > +#include > > + > > +#include > > +#include > > +#include > > + > > +#define __ma(vaddr) (virt_to_machine(vaddr).maddr) > > + > > +static struct page *kimage_alloc_pages(gfp_t gfp_mask, > > + unsigned int order, > > + unsigned long limit) > > +{ > > + struct page *pages; > > + unsigned int address_bits, i; > > + > > + pages = alloc_pages(gfp_mask, order); > > + > > + if (!pages) > > + return NULL; > > + > > + address_bits = (limit == ULONG_MAX) ? BITS_PER_LONG : ilog2(limit); > > + > > + /* Relocate set of pages below given limit. */ > > + if (xen_create_contiguous_region((unsigned long)page_address(pages), > > + order, address_bits)) { > > + __free_pages(pages, order); > > + return NULL; > > + } > > + > > + pages->mapping = NULL; > > It shouldn't matter (as you did the alloc_page) but could you > add: > BUG_ON(PagePrivate(pages)) > in case somebody did do something weird beforehand. OK. > > + set_page_private(pages, order); > > + > > + for (i = 0; i < (1 << order); ++i) > > + SetPageReserved(pages + i); > > + > > + return pages; > > +} > > + > > +static void kimage_free_pages(struct page *page) > > +{ > > + unsigned int i, order; > > + > > + order = page_private(page); > > + > > + for (i = 0; i < (1 << order); ++i) > > + ClearPageReserved(page + i); > > + > > + xen_destroy_contiguous_region((unsigned long)page_address(page), order); > > + __free_pages(page, order); > > +} > > + > > +static unsigned long xen_page_to_mfn(struct page *page) > > +{ > > + return pfn_to_mfn(page_to_pfn(page)); > > +} > > + > > +static struct page *xen_mfn_to_page(unsigned long mfn) > > +{ > > + return pfn_to_page(mfn_to_pfn(mfn)); > > +} > > + > > +static unsigned long xen_virt_to_machine(volatile void *address) > > +{ > > + return virt_to_machine(address).maddr; > > +} > > + > > +static void *xen_machine_to_virt(unsigned long address) > > +{ > > + return phys_to_virt(machine_to_phys(XMADDR(address)).paddr); > > +} > > + > > +static void free_transition_pgtable(struct kimage *image) > > +{ > > + free_page((unsigned long)image->arch.pgd); > > + free_page((unsigned long)image->arch.pmd0); > > + free_page((unsigned long)image->arch.pmd1); > > + free_page((unsigned long)image->arch.pte0); > > + free_page((unsigned long)image->arch.pte1); > > +} > > + > > +static int alloc_transition_pgtable(struct kimage *image) > > +{ > > + image->arch.pgd = (pgd_t *)get_zeroed_page(GFP_KERNEL); > > + > > + if (!image->arch.pgd) > > + goto err; > > + > > + image->arch.pmd0 = (pmd_t *)get_zeroed_page(GFP_KERNEL); > > + > > + if (!image->arch.pmd0) > > + goto err; > > + > > + image->arch.pmd1 = (pmd_t *)get_zeroed_page(GFP_KERNEL); > > + > > + if (!image->arch.pmd1) > > + goto err; > > + > > + image->arch.pte0 = (pte_t *)get_zeroed_page(GFP_KERNEL); > > + > > + if (!image->arch.pte0) > > + goto err; > > + > > + image->arch.pte1 = (pte_t *)get_zeroed_page(GFP_KERNEL); > > + > > + if (!image->arch.pte1) > > + goto err; > > + > > + return 0; > > + > > +err: > > + free_transition_pgtable(image); > > + > > + return -ENOMEM; > > +} > > + > > +static int machine_xen_kexec_prepare(struct kimage *image) > > +{ > > +#ifdef CONFIG_KEXEC_JUMP > > + if (image->preserve_context) { > > + pr_info_once("kexec: Context preservation is not " > > + "supported in Xen domains.\n"); > > + return -ENOSYS; > > + } > > +#endif > > + > > + return alloc_transition_pgtable(image); > > +} > > + > > +static int machine_xen_kexec_load(struct kimage *image) > > +{ > > + void *control_page; > > + struct xen_kexec_load xkl = {}; > > + > > + if (!image) > > + return 0; > > Not -EINVAL? No, if image == NULL then it means that image is unloaded from memory and there is nothing to do by machine_xen_kexec_load(). Daniel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 13:22:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 13:22:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIfwq-0001tj-Uw; Mon, 01 Oct 2012 13:22:12 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIfwq-0001tc-5M for xen-devel@lists.xensource.com; Mon, 01 Oct 2012 13:22:12 +0000 Received: from [85.158.143.35:3797] by server-3.bemta-4.messagelabs.com id 16/D4-10986-30999605; Mon, 01 Oct 2012 13:22:11 +0000 X-Env-Sender: daniel.kiper@oracle.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1349097722!6095572!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzc0OTkw\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28132 invoked from network); 1 Oct 2012 13:22:03 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 13:22:03 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q91DLxL7029328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Oct 2012 13:22:00 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q91DLwVt028816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Oct 2012 13:21:59 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q91DLwIk005040; Mon, 1 Oct 2012 08:21:58 -0500 Received: from host-192-168-1-59.local.net-space.pl (/89.174.63.77) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 01 Oct 2012 06:21:57 -0700 Date: Mon, 1 Oct 2012 15:21:49 +0200 From: Daniel Kiper To: Konrad Rzeszutek Wilk Message-ID: <20121001132149.GE2942@host-192-168-1-59.local.net-space.pl> References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-2-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-3-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-4-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-5-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-6-git-send-email-daniel.kiper@oracle.com> <20120928162132.GC16262@localhost.localdomain> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120928162132.GC16262@localhost.localdomain> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: andrew.cooper3@citrix.com, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, jbeulich@suse.com Subject: Re: [Xen-devel] [PATCH 05/11] x86/xen: Register resources required by kexec-tools X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, Sep 28, 2012 at 12:21:35PM -0400, Konrad Rzeszutek Wilk wrote: > On Thu, Sep 27, 2012 at 08:06:32PM +0200, Daniel Kiper wrote: > > Register resources required by kexec-tools. > > > > Signed-off-by: Daniel Kiper > > --- > > arch/x86/xen/kexec.c | 150 ++++++++++++++++++++++++++++++++++++++++++++++++++ > > 1 files changed, 150 insertions(+), 0 deletions(-) > > create mode 100644 arch/x86/xen/kexec.c > > > > diff --git a/arch/x86/xen/kexec.c b/arch/x86/xen/kexec.c > > new file mode 100644 > > index 0000000..eb0108b > > --- /dev/null > > +++ b/arch/x86/xen/kexec.c > > @@ -0,0 +1,150 @@ > > +/* > > + * Copyright (c) 2011 Daniel Kiper > > + * Copyright (c) 2012 Daniel Kiper, Oracle Corporation > > + * > > + * kexec/kdump implementation for Xen was written by Daniel Kiper. > > + * Initial work on it was sponsored by Google under Google Summer > > + * of Code 2011 program and Citrix. Konrad Rzeszutek Wilk from Oracle > > + * was the mentor for this project. > > + * > > + * Some ideas are taken from: > > + * - native kexec/kdump implementation, > > + * - kexec/kdump implementation for Xen Linux Kernel Ver. 2.6.18, > > + * - PV-GRUB. > > + * > > + * This program is free software; you can redistribute it and/or modify > > + * it under the terms of the GNU General Public License as published by > > + * the Free Software Foundation; either version 2 of the License, or > > + * (at your option) any later version. > > + * > > + * This program is distributed in the hope that it will be useful, > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > > + * GNU General Public License for more details. > > + * > > + * You should have received a copy of the GNU General Public License along > > + * with this program. If not, see . > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#include > > +#include > > +#include > > + > > +#include > > + > > +unsigned long xen_vmcoreinfo_maddr = 0; > > +unsigned long xen_vmcoreinfo_max_size = 0; > > + > > +static int __init xen_init_kexec_resources(void) > > +{ > > + int rc; > > + static struct resource xen_hypervisor_res = { > > + .name = "Hypervisor code and data", > > + .flags = IORESOURCE_BUSY | IORESOURCE_MEM > > + }; > > + struct resource *cpu_res; > > + struct xen_kexec_range xkr; > > + struct xen_platform_op cpuinfo_op; > > + uint32_t cpus, i; > > + > > + if (!xen_initial_domain()) > > + return 0; > > + > > + if (strstr(boot_command_line, "crashkernel=")) > > + pr_info("kexec: Ignoring crashkernel option. " > > pr_warn? OK. > > + "It should be passed to Xen hypervisor.\n"); > > + > > + /* Register Crash kernel resource. */ > > + xkr.range = KEXEC_RANGE_MA_CRASH; > > + rc = HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, &xkr); > > + > > + if (rc) { > > + pr_info("kexec: %s: HYPERVISOR_kexec_op(KEXEC_RANGE_MA_CRASH)" > > + ": %i\n", __func__, rc); > > Perhaps pr_warn? Ditto. > > + return rc; > > + } > > + > > + if (!xkr.size) > > + return 0; > > + > > + crashk_res.start = xkr.start; > > + crashk_res.end = xkr.start + xkr.size - 1; > > + insert_resource(&iomem_resource, &crashk_res); > > + > > + /* Register Hypervisor code and data resource. */ > > + xkr.range = KEXEC_RANGE_MA_XEN; > > + rc = HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, &xkr); > > + > > + if (rc) { > > + pr_info("kexec: %s: HYPERVISOR_kexec_op(KEXEC_RANGE_MA_XEN)" > > pr_warn Ditto. > > + ": %i\n", __func__, rc); > > + return rc; > > + } > > + > > + xen_hypervisor_res.start = xkr.start; > > + xen_hypervisor_res.end = xkr.start + xkr.size - 1; > > + insert_resource(&iomem_resource, &xen_hypervisor_res); > > + > > + /* Determine maximum number of physical CPUs. */ > > + cpuinfo_op.cmd = XENPF_get_cpuinfo; > > + cpuinfo_op.u.pcpu_info.xen_cpuid = 0; > > + rc = HYPERVISOR_dom0_op(&cpuinfo_op); > > + > > + if (rc) { > > + pr_info("kexec: %s: HYPERVISOR_dom0_op(): %i\n", __func__, rc); > > pr_warn. Ditto. > > + return rc; > > + } > > + > > + cpus = cpuinfo_op.u.pcpu_info.max_present + 1; > > Do we care about the hotplug CPUs? Good point. I have not considered it yet. > > + > > + /* Register CPUs Crash note resources. */ > > + cpu_res = kcalloc(cpus, sizeof(struct resource), GFP_KERNEL); > > + > > + if (!cpu_res) { > > + pr_info("kexec: %s: kcalloc(): %i\n", __func__, -ENOMEM); > > + return -ENOMEM; > > + } > > + > > + for (i = 0; i < cpus; ++i) { > > Any specific reason for using '++i' instead of 'i++' ? It does not matter here but I prefer '++i' form. That is it. Daniel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 13:22:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 13:22:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIfwq-0001tj-Uw; Mon, 01 Oct 2012 13:22:12 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIfwq-0001tc-5M for xen-devel@lists.xensource.com; Mon, 01 Oct 2012 13:22:12 +0000 Received: from [85.158.143.35:3797] by server-3.bemta-4.messagelabs.com id 16/D4-10986-30999605; Mon, 01 Oct 2012 13:22:11 +0000 X-Env-Sender: daniel.kiper@oracle.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1349097722!6095572!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzc0OTkw\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28132 invoked from network); 1 Oct 2012 13:22:03 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 13:22:03 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q91DLxL7029328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Oct 2012 13:22:00 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q91DLwVt028816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Oct 2012 13:21:59 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q91DLwIk005040; Mon, 1 Oct 2012 08:21:58 -0500 Received: from host-192-168-1-59.local.net-space.pl (/89.174.63.77) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 01 Oct 2012 06:21:57 -0700 Date: Mon, 1 Oct 2012 15:21:49 +0200 From: Daniel Kiper To: Konrad Rzeszutek Wilk Message-ID: <20121001132149.GE2942@host-192-168-1-59.local.net-space.pl> References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-2-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-3-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-4-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-5-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-6-git-send-email-daniel.kiper@oracle.com> <20120928162132.GC16262@localhost.localdomain> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120928162132.GC16262@localhost.localdomain> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: andrew.cooper3@citrix.com, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, jbeulich@suse.com Subject: Re: [Xen-devel] [PATCH 05/11] x86/xen: Register resources required by kexec-tools X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, Sep 28, 2012 at 12:21:35PM -0400, Konrad Rzeszutek Wilk wrote: > On Thu, Sep 27, 2012 at 08:06:32PM +0200, Daniel Kiper wrote: > > Register resources required by kexec-tools. > > > > Signed-off-by: Daniel Kiper > > --- > > arch/x86/xen/kexec.c | 150 ++++++++++++++++++++++++++++++++++++++++++++++++++ > > 1 files changed, 150 insertions(+), 0 deletions(-) > > create mode 100644 arch/x86/xen/kexec.c > > > > diff --git a/arch/x86/xen/kexec.c b/arch/x86/xen/kexec.c > > new file mode 100644 > > index 0000000..eb0108b > > --- /dev/null > > +++ b/arch/x86/xen/kexec.c > > @@ -0,0 +1,150 @@ > > +/* > > + * Copyright (c) 2011 Daniel Kiper > > + * Copyright (c) 2012 Daniel Kiper, Oracle Corporation > > + * > > + * kexec/kdump implementation for Xen was written by Daniel Kiper. > > + * Initial work on it was sponsored by Google under Google Summer > > + * of Code 2011 program and Citrix. Konrad Rzeszutek Wilk from Oracle > > + * was the mentor for this project. > > + * > > + * Some ideas are taken from: > > + * - native kexec/kdump implementation, > > + * - kexec/kdump implementation for Xen Linux Kernel Ver. 2.6.18, > > + * - PV-GRUB. > > + * > > + * This program is free software; you can redistribute it and/or modify > > + * it under the terms of the GNU General Public License as published by > > + * the Free Software Foundation; either version 2 of the License, or > > + * (at your option) any later version. > > + * > > + * This program is distributed in the hope that it will be useful, > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > > + * GNU General Public License for more details. > > + * > > + * You should have received a copy of the GNU General Public License along > > + * with this program. If not, see . > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#include > > +#include > > +#include > > + > > +#include > > + > > +unsigned long xen_vmcoreinfo_maddr = 0; > > +unsigned long xen_vmcoreinfo_max_size = 0; > > + > > +static int __init xen_init_kexec_resources(void) > > +{ > > + int rc; > > + static struct resource xen_hypervisor_res = { > > + .name = "Hypervisor code and data", > > + .flags = IORESOURCE_BUSY | IORESOURCE_MEM > > + }; > > + struct resource *cpu_res; > > + struct xen_kexec_range xkr; > > + struct xen_platform_op cpuinfo_op; > > + uint32_t cpus, i; > > + > > + if (!xen_initial_domain()) > > + return 0; > > + > > + if (strstr(boot_command_line, "crashkernel=")) > > + pr_info("kexec: Ignoring crashkernel option. " > > pr_warn? OK. > > + "It should be passed to Xen hypervisor.\n"); > > + > > + /* Register Crash kernel resource. */ > > + xkr.range = KEXEC_RANGE_MA_CRASH; > > + rc = HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, &xkr); > > + > > + if (rc) { > > + pr_info("kexec: %s: HYPERVISOR_kexec_op(KEXEC_RANGE_MA_CRASH)" > > + ": %i\n", __func__, rc); > > Perhaps pr_warn? Ditto. > > + return rc; > > + } > > + > > + if (!xkr.size) > > + return 0; > > + > > + crashk_res.start = xkr.start; > > + crashk_res.end = xkr.start + xkr.size - 1; > > + insert_resource(&iomem_resource, &crashk_res); > > + > > + /* Register Hypervisor code and data resource. */ > > + xkr.range = KEXEC_RANGE_MA_XEN; > > + rc = HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, &xkr); > > + > > + if (rc) { > > + pr_info("kexec: %s: HYPERVISOR_kexec_op(KEXEC_RANGE_MA_XEN)" > > pr_warn Ditto. > > + ": %i\n", __func__, rc); > > + return rc; > > + } > > + > > + xen_hypervisor_res.start = xkr.start; > > + xen_hypervisor_res.end = xkr.start + xkr.size - 1; > > + insert_resource(&iomem_resource, &xen_hypervisor_res); > > + > > + /* Determine maximum number of physical CPUs. */ > > + cpuinfo_op.cmd = XENPF_get_cpuinfo; > > + cpuinfo_op.u.pcpu_info.xen_cpuid = 0; > > + rc = HYPERVISOR_dom0_op(&cpuinfo_op); > > + > > + if (rc) { > > + pr_info("kexec: %s: HYPERVISOR_dom0_op(): %i\n", __func__, rc); > > pr_warn. Ditto. > > + return rc; > > + } > > + > > + cpus = cpuinfo_op.u.pcpu_info.max_present + 1; > > Do we care about the hotplug CPUs? Good point. I have not considered it yet. > > + > > + /* Register CPUs Crash note resources. */ > > + cpu_res = kcalloc(cpus, sizeof(struct resource), GFP_KERNEL); > > + > > + if (!cpu_res) { > > + pr_info("kexec: %s: kcalloc(): %i\n", __func__, -ENOMEM); > > + return -ENOMEM; > > + } > > + > > + for (i = 0; i < cpus; ++i) { > > Any specific reason for using '++i' instead of 'i++' ? It does not matter here but I prefer '++i' form. That is it. Daniel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 13:28:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 13:28:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIg2v-00027N-Qy; Mon, 01 Oct 2012 13:28:29 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIg2v-00027I-1j for xen-devel@lists.xensource.com; Mon, 01 Oct 2012 13:28:29 +0000 Received: from [85.158.139.211:47646] by server-14.bemta-5.messagelabs.com id 5E/26-05772-C7A99605; Mon, 01 Oct 2012 13:28:28 +0000 X-Env-Sender: daniel.kiper@oracle.com X-Msg-Ref: server-16.tower-206.messagelabs.com!1349098106!20655711!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzc0OTkw\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3928 invoked from network); 1 Oct 2012 13:28:27 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 13:28:27 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q91DSOYi003822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Oct 2012 13:28:24 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q91DSNLx008433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Oct 2012 13:28:23 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q91DSM3c030238; Mon, 1 Oct 2012 08:28:22 -0500 Received: from host-192-168-1-59.local.net-space.pl (/89.174.63.77) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 01 Oct 2012 06:28:22 -0700 Date: Mon, 1 Oct 2012 15:28:15 +0200 From: Daniel Kiper To: Jan Beulich Message-ID: <20121001132815.GF2942@host-192-168-1-59.local.net-space.pl> References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-2-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-3-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-4-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-5-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-6-git-send-email-daniel.kiper@oracle.com> <20120928162132.GC16262@localhost.localdomain> <50698111020000780009EB2E@nat28.tlf.novell.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <50698111020000780009EB2E@nat28.tlf.novell.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: andrew.cooper3@citrix.com, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 05/11] x86/xen: Register resources required by kexec-tools X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, Oct 01, 2012 at 10:40:01AM +0100, Jan Beulich wrote: > >>> On 28.09.12 at 18:21, Konrad Rzeszutek Wilk wrote: > > On Thu, Sep 27, 2012 at 08:06:32PM +0200, Daniel Kiper wrote: > >> + for (i = 0; i < cpus; ++i) { > > > > Any specific reason for using '++i' instead of 'i++' ? > > For people occasionally also writing C++ code this is the > canonical form. Heh... I have not written any C++ code since the end of my C++ course at my university (~18 years). I am just prefer '++i' instead of 'i++'. That is it. Daniel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 13:28:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 13:28:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIg2v-00027N-Qy; Mon, 01 Oct 2012 13:28:29 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIg2v-00027I-1j for xen-devel@lists.xensource.com; Mon, 01 Oct 2012 13:28:29 +0000 Received: from [85.158.139.211:47646] by server-14.bemta-5.messagelabs.com id 5E/26-05772-C7A99605; Mon, 01 Oct 2012 13:28:28 +0000 X-Env-Sender: daniel.kiper@oracle.com X-Msg-Ref: server-16.tower-206.messagelabs.com!1349098106!20655711!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzc0OTkw\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3928 invoked from network); 1 Oct 2012 13:28:27 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 13:28:27 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q91DSOYi003822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Oct 2012 13:28:24 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q91DSNLx008433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Oct 2012 13:28:23 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q91DSM3c030238; Mon, 1 Oct 2012 08:28:22 -0500 Received: from host-192-168-1-59.local.net-space.pl (/89.174.63.77) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 01 Oct 2012 06:28:22 -0700 Date: Mon, 1 Oct 2012 15:28:15 +0200 From: Daniel Kiper To: Jan Beulich Message-ID: <20121001132815.GF2942@host-192-168-1-59.local.net-space.pl> References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-2-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-3-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-4-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-5-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-6-git-send-email-daniel.kiper@oracle.com> <20120928162132.GC16262@localhost.localdomain> <50698111020000780009EB2E@nat28.tlf.novell.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <50698111020000780009EB2E@nat28.tlf.novell.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: andrew.cooper3@citrix.com, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 05/11] x86/xen: Register resources required by kexec-tools X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, Oct 01, 2012 at 10:40:01AM +0100, Jan Beulich wrote: > >>> On 28.09.12 at 18:21, Konrad Rzeszutek Wilk wrote: > > On Thu, Sep 27, 2012 at 08:06:32PM +0200, Daniel Kiper wrote: > >> + for (i = 0; i < cpus; ++i) { > > > > Any specific reason for using '++i' instead of 'i++' ? > > For people occasionally also writing C++ code this is the > canonical form. Heh... I have not written any C++ code since the end of my C++ course at my university (~18 years). I am just prefer '++i' instead of 'i++'. That is it. Daniel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 13:34:44 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 13:34:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIg8g-0002IU-Q5; Mon, 01 Oct 2012 13:34:26 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIg8f-0002IO-7m for xen-devel@lists.xensource.com; Mon, 01 Oct 2012 13:34:25 +0000 Received: from [85.158.143.99:63588] by server-2.bemta-4.messagelabs.com id 43/93-06610-0EB99605; Mon, 01 Oct 2012 13:34:24 +0000 X-Env-Sender: daniel.kiper@oracle.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1349098462!27129103!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc4NTAwMQ==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10839 invoked from network); 1 Oct 2012 13:34:23 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 13:34:23 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q91DYJHw009268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Oct 2012 13:34:20 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q91DYHJZ020181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Oct 2012 13:34:19 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q91DYHLt002555; Mon, 1 Oct 2012 08:34:17 -0500 Received: from host-192-168-1-59.local.net-space.pl (/89.174.63.77) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 01 Oct 2012 06:34:16 -0700 Date: Mon, 1 Oct 2012 15:34:09 +0200 From: Daniel Kiper To: Konrad Rzeszutek Wilk Message-ID: <20121001133409.GG2942@host-192-168-1-59.local.net-space.pl> References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-2-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-3-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-4-git-send-email-daniel.kiper@oracle.com> <20120928161016.GB16262@localhost.localdomain> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120928161016.GB16262@localhost.localdomain> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: andrew.cooper3@citrix.com, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, jbeulich@suse.com Subject: Re: [Xen-devel] [PATCH 03/11] xen: Introduce architecture independent data for kexec/kdump X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, Sep 28, 2012 at 12:10:17PM -0400, Konrad Rzeszutek Wilk wrote: > On Thu, Sep 27, 2012 at 08:06:30PM +0200, Daniel Kiper wrote: > > Introduce architecture independent constants and structures > > Don't you mean 'dependent constants'? Right. > > required by Xen kexec/kdump implementation. > > > > Signed-off-by: Daniel Kiper > > --- > > include/xen/interface/xen.h | 33 +++++++++++++++++++++++++++++++++ > > 1 files changed, 33 insertions(+), 0 deletions(-) > > > > diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h > > index 0801468..ac19f9e 100644 > > --- a/include/xen/interface/xen.h > > +++ b/include/xen/interface/xen.h > > @@ -58,6 +58,7 @@ > > #define __HYPERVISOR_event_channel_op 32 > > #define __HYPERVISOR_physdev_op 33 > > #define __HYPERVISOR_hvm_op 34 > > +#define __HYPERVISOR_kexec_op 37 > > #define __HYPERVISOR_tmem_op 38 > > > > /* Architecture-specific hypercall definitions. */ > > @@ -232,7 +233,39 @@ DEFINE_GUEST_HANDLE_STRUCT(mmuext_op); > > #define VMASST_TYPE_pae_extended_cr3 3 > > #define MAX_VMASST_TYPE 3 > > > > +/* > > + * Commands to HYPERVISOR_kexec_op(). > > + */ > > +#define KEXEC_CMD_kexec 0 > > +#define KEXEC_CMD_kexec_load 1 > > +#define KEXEC_CMD_kexec_unload 2 > > +#define KEXEC_CMD_kexec_get_range 3 > > + > > +/* > > + * Memory ranges for kdump (utilized by HYPERVISOR_kexec_op()). > > + */ > > +#define KEXEC_RANGE_MA_CRASH 0 > > +#define KEXEC_RANGE_MA_XEN 1 > > +#define KEXEC_RANGE_MA_CPU 2 > > +#define KEXEC_RANGE_MA_XENHEAP 3 > > +#define KEXEC_RANGE_MA_BOOT_PARAM 4 > > +#define KEXEC_RANGE_MA_EFI_MEMMAP 5 > > +#define KEXEC_RANGE_MA_VMCOREINFO 6 > > + > > #ifndef __ASSEMBLY__ > > +struct xen_kexec_exec { > > + int type; > > +}; > > + > > +struct xen_kexec_range { > > + int range; > > + int nr; > > + unsigned long size; > > + unsigned long start; > > +}; > > Might want to include an little blurb saying what we expect > in case of running a 32-bit domain on a 64-bit hypervisor > where the start might be past 4GB? This is not true. All needed pages used by i386 relocate kernel code are always below 4 GiB. Daniel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 13:34:44 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 13:34:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIg8g-0002IU-Q5; Mon, 01 Oct 2012 13:34:26 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIg8f-0002IO-7m for xen-devel@lists.xensource.com; Mon, 01 Oct 2012 13:34:25 +0000 Received: from [85.158.143.99:63588] by server-2.bemta-4.messagelabs.com id 43/93-06610-0EB99605; Mon, 01 Oct 2012 13:34:24 +0000 X-Env-Sender: daniel.kiper@oracle.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1349098462!27129103!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc4NTAwMQ==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10839 invoked from network); 1 Oct 2012 13:34:23 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 13:34:23 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q91DYJHw009268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Oct 2012 13:34:20 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q91DYHJZ020181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Oct 2012 13:34:19 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q91DYHLt002555; Mon, 1 Oct 2012 08:34:17 -0500 Received: from host-192-168-1-59.local.net-space.pl (/89.174.63.77) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 01 Oct 2012 06:34:16 -0700 Date: Mon, 1 Oct 2012 15:34:09 +0200 From: Daniel Kiper To: Konrad Rzeszutek Wilk Message-ID: <20121001133409.GG2942@host-192-168-1-59.local.net-space.pl> References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-2-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-3-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-4-git-send-email-daniel.kiper@oracle.com> <20120928161016.GB16262@localhost.localdomain> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120928161016.GB16262@localhost.localdomain> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: andrew.cooper3@citrix.com, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, jbeulich@suse.com Subject: Re: [Xen-devel] [PATCH 03/11] xen: Introduce architecture independent data for kexec/kdump X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, Sep 28, 2012 at 12:10:17PM -0400, Konrad Rzeszutek Wilk wrote: > On Thu, Sep 27, 2012 at 08:06:30PM +0200, Daniel Kiper wrote: > > Introduce architecture independent constants and structures > > Don't you mean 'dependent constants'? Right. > > required by Xen kexec/kdump implementation. > > > > Signed-off-by: Daniel Kiper > > --- > > include/xen/interface/xen.h | 33 +++++++++++++++++++++++++++++++++ > > 1 files changed, 33 insertions(+), 0 deletions(-) > > > > diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h > > index 0801468..ac19f9e 100644 > > --- a/include/xen/interface/xen.h > > +++ b/include/xen/interface/xen.h > > @@ -58,6 +58,7 @@ > > #define __HYPERVISOR_event_channel_op 32 > > #define __HYPERVISOR_physdev_op 33 > > #define __HYPERVISOR_hvm_op 34 > > +#define __HYPERVISOR_kexec_op 37 > > #define __HYPERVISOR_tmem_op 38 > > > > /* Architecture-specific hypercall definitions. */ > > @@ -232,7 +233,39 @@ DEFINE_GUEST_HANDLE_STRUCT(mmuext_op); > > #define VMASST_TYPE_pae_extended_cr3 3 > > #define MAX_VMASST_TYPE 3 > > > > +/* > > + * Commands to HYPERVISOR_kexec_op(). > > + */ > > +#define KEXEC_CMD_kexec 0 > > +#define KEXEC_CMD_kexec_load 1 > > +#define KEXEC_CMD_kexec_unload 2 > > +#define KEXEC_CMD_kexec_get_range 3 > > + > > +/* > > + * Memory ranges for kdump (utilized by HYPERVISOR_kexec_op()). > > + */ > > +#define KEXEC_RANGE_MA_CRASH 0 > > +#define KEXEC_RANGE_MA_XEN 1 > > +#define KEXEC_RANGE_MA_CPU 2 > > +#define KEXEC_RANGE_MA_XENHEAP 3 > > +#define KEXEC_RANGE_MA_BOOT_PARAM 4 > > +#define KEXEC_RANGE_MA_EFI_MEMMAP 5 > > +#define KEXEC_RANGE_MA_VMCOREINFO 6 > > + > > #ifndef __ASSEMBLY__ > > +struct xen_kexec_exec { > > + int type; > > +}; > > + > > +struct xen_kexec_range { > > + int range; > > + int nr; > > + unsigned long size; > > + unsigned long start; > > +}; > > Might want to include an little blurb saying what we expect > in case of running a 32-bit domain on a 64-bit hypervisor > where the start might be past 4GB? This is not true. All needed pages used by i386 relocate kernel code are always below 4 GiB. Daniel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 13:40:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 13:40:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIgEf-0002Sc-LD; Mon, 01 Oct 2012 13:40:37 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIgEe-0002SX-8y for xen-devel@lists.xensource.com; Mon, 01 Oct 2012 13:40:36 +0000 Received: from [85.158.138.51:56249] by server-15.bemta-3.messagelabs.com id 54/DA-18313-35D99605; Mon, 01 Oct 2012 13:40:35 +0000 X-Env-Sender: daniel.kiper@oracle.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1349098833!30859959!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzc0OTkw\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29738 invoked from network); 1 Oct 2012 13:40:34 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 13:40:34 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q91DeUWd018586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Oct 2012 13:40:31 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q91DeT1l003333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Oct 2012 13:40:30 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q91DeTFr019096; Mon, 1 Oct 2012 08:40:29 -0500 Received: from host-192-168-1-59.local.net-space.pl (/89.174.63.77) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 01 Oct 2012 06:40:29 -0700 Date: Mon, 1 Oct 2012 15:40:21 +0200 From: Daniel Kiper To: Konrad Rzeszutek Wilk Message-ID: <20121001134021.GH2942@host-192-168-1-59.local.net-space.pl> References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-2-git-send-email-daniel.kiper@oracle.com> <20120928160728.GA16262@localhost.localdomain> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120928160728.GA16262@localhost.localdomain> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: andrew.cooper3@citrix.com, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, jbeulich@suse.com Subject: Re: [Xen-devel] [PATCH 01/11] kexec: introduce kexec_ops struct X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, Sep 28, 2012 at 12:07:42PM -0400, Konrad Rzeszutek Wilk wrote: > On Thu, Sep 27, 2012 at 08:06:28PM +0200, Daniel Kiper wrote: > > Some kexec/kdump implementations (e.g. Xen PVOPS) on different archs could > > not use default functions or require some changes in behavior of kexec/kdump > > generic code. To cope with that problem kexec_ops struct was introduced. > > It allows a developer to replace all or some functions and control some > > functionality of kexec/kdump generic code. > > > > Default behavior of kexec/kdump generic code is not changed. > > > > Signed-off-by: Daniel Kiper > > --- > > include/linux/kexec.h | 18 +++++++ > > kernel/kexec.c | 125 ++++++++++++++++++++++++++++++++++++------------- > > 2 files changed, 111 insertions(+), 32 deletions(-) > > > > diff --git a/include/linux/kexec.h b/include/linux/kexec.h > > index 37c5f72..beb08ca 100644 > > --- a/include/linux/kexec.h > > +++ b/include/linux/kexec.h > > @@ -165,7 +165,25 @@ struct kimage { > > #endif > > }; > > > > +struct kexec_ops { > > + bool always_use_normal_alloc; > > So most of these are self-explanatory. But the bool is not that clear > to me. Could you include a documentation comment explaining > its purpose and its implications? OK. > > + struct page *(*kimage_alloc_pages)(gfp_t gfp_mask, > > + unsigned int order, > > + unsigned long limit); > > + void (*kimage_free_pages)(struct page *page); > > + unsigned long (*page_to_pfn)(struct page *page); > > + struct page *(*pfn_to_page)(unsigned long pfn); > > + unsigned long (*virt_to_phys)(volatile void *address); > > + void *(*phys_to_virt)(unsigned long address); > > + int (*machine_kexec_prepare)(struct kimage *image); > > + int (*machine_kexec_load)(struct kimage *image); > > + void (*machine_kexec_cleanup)(struct kimage *image); > > + void (*machine_kexec_unload)(struct kimage *image); > > + void (*machine_kexec_shutdown)(void); > > + void (*machine_kexec)(struct kimage *image); > > +}; > > > > +extern struct kexec_ops kexec_ops; > > Is this neccessary? Yes, because it is used by Xen machine_kexec_??.c files. > > /* kexec interface functions */ > > extern void machine_kexec(struct kimage *image); > > diff --git a/kernel/kexec.c b/kernel/kexec.c > > index 0668d58..98556f3 100644 > > --- a/kernel/kexec.c > > +++ b/kernel/kexec.c > > @@ -56,6 +56,47 @@ struct resource crashk_res = { > > .flags = IORESOURCE_BUSY | IORESOURCE_MEM > > }; > > > > +static struct page *kimage_alloc_pages(gfp_t gfp_mask, > > + unsigned int order, > > + unsigned long limit); > > +static void kimage_free_pages(struct page *page); > > + > > +static unsigned long generic_page_to_pfn(struct page *page) > > +{ > > + return page_to_pfn(page); > > +} > > + > > +static struct page *generic_pfn_to_page(unsigned long pfn) > > +{ > > + return pfn_to_page(pfn); > > +} > > + > > +static unsigned long generic_virt_to_phys(volatile void *address) > > +{ > > + return virt_to_phys(address); > > +} > > + > > +static void *generic_phys_to_virt(unsigned long address) > > +{ > > + return phys_to_virt(address); > > +} > > + > > +struct kexec_ops kexec_ops = { > > + .always_use_normal_alloc = false, > > + .kimage_alloc_pages = kimage_alloc_pages, > > + .kimage_free_pages = kimage_free_pages, > > + .page_to_pfn = generic_page_to_pfn, > > + .pfn_to_page = generic_pfn_to_page, > > + .virt_to_phys = generic_virt_to_phys, > > + .phys_to_virt = generic_phys_to_virt, > > + .machine_kexec_prepare = machine_kexec_prepare, > > + .machine_kexec_load = NULL, > > Instead of NULL should they just point to some nop function? OK. Daniel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 13:40:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 13:40:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIgEf-0002Sc-LD; Mon, 01 Oct 2012 13:40:37 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIgEe-0002SX-8y for xen-devel@lists.xensource.com; Mon, 01 Oct 2012 13:40:36 +0000 Received: from [85.158.138.51:56249] by server-15.bemta-3.messagelabs.com id 54/DA-18313-35D99605; Mon, 01 Oct 2012 13:40:35 +0000 X-Env-Sender: daniel.kiper@oracle.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1349098833!30859959!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzc0OTkw\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29738 invoked from network); 1 Oct 2012 13:40:34 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 13:40:34 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q91DeUWd018586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Oct 2012 13:40:31 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q91DeT1l003333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Oct 2012 13:40:30 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q91DeTFr019096; Mon, 1 Oct 2012 08:40:29 -0500 Received: from host-192-168-1-59.local.net-space.pl (/89.174.63.77) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 01 Oct 2012 06:40:29 -0700 Date: Mon, 1 Oct 2012 15:40:21 +0200 From: Daniel Kiper To: Konrad Rzeszutek Wilk Message-ID: <20121001134021.GH2942@host-192-168-1-59.local.net-space.pl> References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-2-git-send-email-daniel.kiper@oracle.com> <20120928160728.GA16262@localhost.localdomain> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120928160728.GA16262@localhost.localdomain> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: andrew.cooper3@citrix.com, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, jbeulich@suse.com Subject: Re: [Xen-devel] [PATCH 01/11] kexec: introduce kexec_ops struct X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, Sep 28, 2012 at 12:07:42PM -0400, Konrad Rzeszutek Wilk wrote: > On Thu, Sep 27, 2012 at 08:06:28PM +0200, Daniel Kiper wrote: > > Some kexec/kdump implementations (e.g. Xen PVOPS) on different archs could > > not use default functions or require some changes in behavior of kexec/kdump > > generic code. To cope with that problem kexec_ops struct was introduced. > > It allows a developer to replace all or some functions and control some > > functionality of kexec/kdump generic code. > > > > Default behavior of kexec/kdump generic code is not changed. > > > > Signed-off-by: Daniel Kiper > > --- > > include/linux/kexec.h | 18 +++++++ > > kernel/kexec.c | 125 ++++++++++++++++++++++++++++++++++++------------- > > 2 files changed, 111 insertions(+), 32 deletions(-) > > > > diff --git a/include/linux/kexec.h b/include/linux/kexec.h > > index 37c5f72..beb08ca 100644 > > --- a/include/linux/kexec.h > > +++ b/include/linux/kexec.h > > @@ -165,7 +165,25 @@ struct kimage { > > #endif > > }; > > > > +struct kexec_ops { > > + bool always_use_normal_alloc; > > So most of these are self-explanatory. But the bool is not that clear > to me. Could you include a documentation comment explaining > its purpose and its implications? OK. > > + struct page *(*kimage_alloc_pages)(gfp_t gfp_mask, > > + unsigned int order, > > + unsigned long limit); > > + void (*kimage_free_pages)(struct page *page); > > + unsigned long (*page_to_pfn)(struct page *page); > > + struct page *(*pfn_to_page)(unsigned long pfn); > > + unsigned long (*virt_to_phys)(volatile void *address); > > + void *(*phys_to_virt)(unsigned long address); > > + int (*machine_kexec_prepare)(struct kimage *image); > > + int (*machine_kexec_load)(struct kimage *image); > > + void (*machine_kexec_cleanup)(struct kimage *image); > > + void (*machine_kexec_unload)(struct kimage *image); > > + void (*machine_kexec_shutdown)(void); > > + void (*machine_kexec)(struct kimage *image); > > +}; > > > > +extern struct kexec_ops kexec_ops; > > Is this neccessary? Yes, because it is used by Xen machine_kexec_??.c files. > > /* kexec interface functions */ > > extern void machine_kexec(struct kimage *image); > > diff --git a/kernel/kexec.c b/kernel/kexec.c > > index 0668d58..98556f3 100644 > > --- a/kernel/kexec.c > > +++ b/kernel/kexec.c > > @@ -56,6 +56,47 @@ struct resource crashk_res = { > > .flags = IORESOURCE_BUSY | IORESOURCE_MEM > > }; > > > > +static struct page *kimage_alloc_pages(gfp_t gfp_mask, > > + unsigned int order, > > + unsigned long limit); > > +static void kimage_free_pages(struct page *page); > > + > > +static unsigned long generic_page_to_pfn(struct page *page) > > +{ > > + return page_to_pfn(page); > > +} > > + > > +static struct page *generic_pfn_to_page(unsigned long pfn) > > +{ > > + return pfn_to_page(pfn); > > +} > > + > > +static unsigned long generic_virt_to_phys(volatile void *address) > > +{ > > + return virt_to_phys(address); > > +} > > + > > +static void *generic_phys_to_virt(unsigned long address) > > +{ > > + return phys_to_virt(address); > > +} > > + > > +struct kexec_ops kexec_ops = { > > + .always_use_normal_alloc = false, > > + .kimage_alloc_pages = kimage_alloc_pages, > > + .kimage_free_pages = kimage_free_pages, > > + .page_to_pfn = generic_page_to_pfn, > > + .pfn_to_page = generic_pfn_to_page, > > + .virt_to_phys = generic_virt_to_phys, > > + .phys_to_virt = generic_phys_to_virt, > > + .machine_kexec_prepare = machine_kexec_prepare, > > + .machine_kexec_load = NULL, > > Instead of NULL should they just point to some nop function? OK. Daniel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 13:51:03 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 13:51:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIgOU-0002cm-P5; Mon, 01 Oct 2012 13:50:46 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIgOS-0002cg-U9 for xen-devel@lists.xen.org; Mon, 01 Oct 2012 13:50:45 +0000 Received: from [85.158.138.51:51436] by server-8.bemta-3.messagelabs.com id 91/4D-16337-4BF99605; Mon, 01 Oct 2012 13:50:44 +0000 X-Env-Sender: Christoph.Egger@amd.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1349099438!24613524!1 X-Originating-IP: [65.55.88.10] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24094 invoked from network); 1 Oct 2012 13:50:43 -0000 Received: from mail-tx2.bigfish.com (HELO tx2outboundpool.messaging.microsoft.com) (65.55.88.10) by server-6.tower-174.messagelabs.com with AES128-SHA encrypted SMTP; 1 Oct 2012 13:50:43 -0000 Received: from mail209-tx2-R.bigfish.com (10.9.14.238) by TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id 14.1.225.23; Mon, 1 Oct 2012 13:50:38 +0000 Received: from mail209-tx2 (localhost [127.0.0.1]) by mail209-tx2-R.bigfish.com (Postfix) with ESMTP id 15D7F2C008E; Mon, 1 Oct 2012 13:50:38 +0000 (UTC) X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null); IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI X-SpamScore: -4 X-BigFish: VPS-4(zzbb2dI98dI1432I1418Izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh137ah13b6h1155h) Received: from mail209-tx2 (localhost.localdomain [127.0.0.1]) by mail209-tx2 (MessageSwitch) id 1349099435838746_26242; Mon, 1 Oct 2012 13:50:35 +0000 (UTC) Received: from TX2EHSMHS022.bigfish.com (unknown [10.9.14.245]) by mail209-tx2.bigfish.com (Postfix) with ESMTP id C9E0ED802B9; Mon, 1 Oct 2012 13:50:35 +0000 (UTC) Received: from ausb3twp02.amd.com (163.181.249.109) by TX2EHSMHS022.bigfish.com (10.9.99.122) with Microsoft SMTP Server id 14.1.225.23; Mon, 1 Oct 2012 13:50:34 +0000 X-WSS-ID: 0MB7VS6-02-5C7-02 X-M-MSG: Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com [163.181.249.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ausb3twp02.amd.com (Axway MailGate 3.8.1) with ESMTP id 2E0A5C8062; Mon, 1 Oct 2012 08:50:29 -0500 (CDT) Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep02.amd.com (163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1; Mon, 1 Oct 2012 08:50:37 -0500 Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag04.amd.com (163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 1 Oct 2012 08:50:32 -0500 Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com (172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Mon, 1 Oct 2012 09:50:31 -0400 Message-ID: <50699FA6.6070805@amd.com> Date: Mon, 1 Oct 2012 15:50:30 +0200 From: Christoph Egger User-Agent: Mozilla/5.0 (X11; NetBSD amd64; rv:11.0) Gecko/20120404 Thunderbird/11.0 MIME-Version: 1.0 To: Tim Deegan References: <505C733B.50205@amd.com> <20120927145356.GG8831@ocelot.phlegethon.org> In-Reply-To: <20120927145356.GG8831@ocelot.phlegethon.org> X-OriginatorOrg: amd.com Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] nestedsvm: fix paging mode X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 09/27/12 16:53, Tim Deegan wrote: > At 16:01 +0200 on 21 Sep (1348243291), Christoph Egger wrote: >> >> On VMRUN and VMEXIT emulation update the paging mode >> for Shadow-on-Nested. This allows Xen to walk the >> l1 hypervisors shadow page table correctly. >> Problem found with 64bit Win7 and 32bit XPMode where >> Win7 switches forth and back between long mode and >> PAE legacy pagetables. >> >> Signed-off-by: Christoph Egger > > Don't you have to do this in other cases as well? I think that > shadow-on-shadow might need it, at least. It is needed for all cases where the l1 guest does shadow paging. This includes: Shadow-on-Nested and Shadow-on-Shadow. Christoph -- ---to satisfy European Law for business letters: Advanced Micro Devices GmbH Einsteinring 24, 85689 Dornach b. Muenchen Geschaeftsfuehrer: Alberto Bozzo Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 13:51:03 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 13:51:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIgOU-0002cm-P5; Mon, 01 Oct 2012 13:50:46 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIgOS-0002cg-U9 for xen-devel@lists.xen.org; Mon, 01 Oct 2012 13:50:45 +0000 Received: from [85.158.138.51:51436] by server-8.bemta-3.messagelabs.com id 91/4D-16337-4BF99605; Mon, 01 Oct 2012 13:50:44 +0000 X-Env-Sender: Christoph.Egger@amd.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1349099438!24613524!1 X-Originating-IP: [65.55.88.10] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24094 invoked from network); 1 Oct 2012 13:50:43 -0000 Received: from mail-tx2.bigfish.com (HELO tx2outboundpool.messaging.microsoft.com) (65.55.88.10) by server-6.tower-174.messagelabs.com with AES128-SHA encrypted SMTP; 1 Oct 2012 13:50:43 -0000 Received: from mail209-tx2-R.bigfish.com (10.9.14.238) by TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id 14.1.225.23; Mon, 1 Oct 2012 13:50:38 +0000 Received: from mail209-tx2 (localhost [127.0.0.1]) by mail209-tx2-R.bigfish.com (Postfix) with ESMTP id 15D7F2C008E; Mon, 1 Oct 2012 13:50:38 +0000 (UTC) X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null); IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI X-SpamScore: -4 X-BigFish: VPS-4(zzbb2dI98dI1432I1418Izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh137ah13b6h1155h) Received: from mail209-tx2 (localhost.localdomain [127.0.0.1]) by mail209-tx2 (MessageSwitch) id 1349099435838746_26242; Mon, 1 Oct 2012 13:50:35 +0000 (UTC) Received: from TX2EHSMHS022.bigfish.com (unknown [10.9.14.245]) by mail209-tx2.bigfish.com (Postfix) with ESMTP id C9E0ED802B9; Mon, 1 Oct 2012 13:50:35 +0000 (UTC) Received: from ausb3twp02.amd.com (163.181.249.109) by TX2EHSMHS022.bigfish.com (10.9.99.122) with Microsoft SMTP Server id 14.1.225.23; Mon, 1 Oct 2012 13:50:34 +0000 X-WSS-ID: 0MB7VS6-02-5C7-02 X-M-MSG: Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com [163.181.249.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ausb3twp02.amd.com (Axway MailGate 3.8.1) with ESMTP id 2E0A5C8062; Mon, 1 Oct 2012 08:50:29 -0500 (CDT) Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep02.amd.com (163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1; Mon, 1 Oct 2012 08:50:37 -0500 Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag04.amd.com (163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 1 Oct 2012 08:50:32 -0500 Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com (172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Mon, 1 Oct 2012 09:50:31 -0400 Message-ID: <50699FA6.6070805@amd.com> Date: Mon, 1 Oct 2012 15:50:30 +0200 From: Christoph Egger User-Agent: Mozilla/5.0 (X11; NetBSD amd64; rv:11.0) Gecko/20120404 Thunderbird/11.0 MIME-Version: 1.0 To: Tim Deegan References: <505C733B.50205@amd.com> <20120927145356.GG8831@ocelot.phlegethon.org> In-Reply-To: <20120927145356.GG8831@ocelot.phlegethon.org> X-OriginatorOrg: amd.com Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] nestedsvm: fix paging mode X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 09/27/12 16:53, Tim Deegan wrote: > At 16:01 +0200 on 21 Sep (1348243291), Christoph Egger wrote: >> >> On VMRUN and VMEXIT emulation update the paging mode >> for Shadow-on-Nested. This allows Xen to walk the >> l1 hypervisors shadow page table correctly. >> Problem found with 64bit Win7 and 32bit XPMode where >> Win7 switches forth and back between long mode and >> PAE legacy pagetables. >> >> Signed-off-by: Christoph Egger > > Don't you have to do this in other cases as well? I think that > shadow-on-shadow might need it, at least. It is needed for all cases where the l1 guest does shadow paging. This includes: Shadow-on-Nested and Shadow-on-Shadow. Christoph -- ---to satisfy European Law for business letters: Advanced Micro Devices GmbH Einsteinring 24, 85689 Dornach b. Muenchen Geschaeftsfuehrer: Alberto Bozzo Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 13:55:23 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 13:55:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIgSi-0002kT-F3; Mon, 01 Oct 2012 13:55:08 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIgSg-0002kN-W8 for xen-devel@lists.xen.org; Mon, 01 Oct 2012 13:55:07 +0000 Received: from [85.158.139.211:5755] by server-9.bemta-5.messagelabs.com id 4E/F4-14846-AB0A9605; Mon, 01 Oct 2012 13:55:06 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-10.tower-206.messagelabs.com!1349099704!20600445!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19519 invoked from network); 1 Oct 2012 13:55:05 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-10.tower-206.messagelabs.com with SMTP; 1 Oct 2012 13:55:05 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 01 Oct 2012 14:55:04 +0100 Message-Id: <5069BCD5020000780009EC7D@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Mon, 01 Oct 2012 14:55:01 +0100 From: "Jan Beulich" To: "Daniel Kiper" References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-2-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-3-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-4-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-5-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-6-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-7-git-send-email-daniel.kiper@oracle.com> <506577E3020000780009E65B@nat28.tlf.novell.com> <20121001125252.GB2942@host-192-168-1-59.local.net-space.pl> In-Reply-To: <20121001125252.GB2942@host-192-168-1-59.local.net-space.pl> Mime-Version: 1.0 Content-Disposition: inline Cc: andrew.cooper3@citrix.com, konrad.wilk@oracle.com, linux-kernel@vger.kernel.org, xen-devel Subject: Re: [Xen-devel] [PATCH 06/11] x86/xen: Add i386 kexec/kdump implementation X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 01.10.12 at 14:52, Daniel Kiper wrote: > On Fri, Sep 28, 2012 at 09:11:47AM +0100, Jan Beulich wrote: >> Finally, as noticed in an earlier patch already, you appear to >> re-introduce stuff long dropped from the kernel - the forward >> ported kernels get away with just setting PA_CONTROL_PAGE, >> PA_PGD, and PA_SWAP_PAGE in the page list. Since the number >> and purpose of the pages is established entirely by the guest >> kernel, all you need to obey is that the hypervisor expects >> alternating PA_/VA_ pairs (where the VA_ ones can be left >> unpopulated). Perhaps taking a look at a recent SLES kernel >> would help... > > I have got > ftp://ftp.suse.com/pub/projects/kernel/kotd/SLE11-SP2/src/kernel-source-3.0. > 43-6.1.src.rpm. > Does kexec/kdump work in your environment? In my it does not. While I never ran it myself, I know kdump has been working on SLE for quite a long while (leaving aside hardware or firmware quirks requiring extra workarounds). > At least there is wrong assumption that > vaddr = (unsigned long)relocate_kernel > gets virtual address of relocate_kernel in Xen Where did you spot that? Afaics the only thing done with relocate_kernel is that it gets copied into the control page. > (I have tested only x86_64 implementation but > as I saw i386 has similar problem). In real it is > fix mapped in hypervisor which is completely > different than address calculated in dom0 kernel. > Virtual address of control page (and others) is > only known by hypervisor kexec/kdump functions. > It means that transition page table could be > established by relocate_kernel code only. > If you would like to do optimistation as you > mentioned above you must reintroduce code > for page table establishment into generic > relocate_kernel_??.S. However, another > problem arises. New generic code utilizes > additional arguments such as swap page > (and potentially could use others in the future). > As I saw it is not possible to pass extra addresses > through page_list[] in struct xen_kexec_image > because its has insufficient size (I mean > x86_64 because i386 is a bit different story). No - there's no meaning assigned by Xen to any of the slots, except for said assumption about them representing alternating PA_/VA_ pairs. Hence, as long as old entries get removed, new slots can easily be added (and the number of slots currently needed is far lower than what was used originally [2.6.18]). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 13:55:23 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 13:55:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIgSi-0002kT-F3; Mon, 01 Oct 2012 13:55:08 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIgSg-0002kN-W8 for xen-devel@lists.xen.org; Mon, 01 Oct 2012 13:55:07 +0000 Received: from [85.158.139.211:5755] by server-9.bemta-5.messagelabs.com id 4E/F4-14846-AB0A9605; Mon, 01 Oct 2012 13:55:06 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-10.tower-206.messagelabs.com!1349099704!20600445!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19519 invoked from network); 1 Oct 2012 13:55:05 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-10.tower-206.messagelabs.com with SMTP; 1 Oct 2012 13:55:05 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Mon, 01 Oct 2012 14:55:04 +0100 Message-Id: <5069BCD5020000780009EC7D@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Mon, 01 Oct 2012 14:55:01 +0100 From: "Jan Beulich" To: "Daniel Kiper" References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-2-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-3-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-4-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-5-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-6-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-7-git-send-email-daniel.kiper@oracle.com> <506577E3020000780009E65B@nat28.tlf.novell.com> <20121001125252.GB2942@host-192-168-1-59.local.net-space.pl> In-Reply-To: <20121001125252.GB2942@host-192-168-1-59.local.net-space.pl> Mime-Version: 1.0 Content-Disposition: inline Cc: andrew.cooper3@citrix.com, konrad.wilk@oracle.com, linux-kernel@vger.kernel.org, xen-devel Subject: Re: [Xen-devel] [PATCH 06/11] x86/xen: Add i386 kexec/kdump implementation X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 01.10.12 at 14:52, Daniel Kiper wrote: > On Fri, Sep 28, 2012 at 09:11:47AM +0100, Jan Beulich wrote: >> Finally, as noticed in an earlier patch already, you appear to >> re-introduce stuff long dropped from the kernel - the forward >> ported kernels get away with just setting PA_CONTROL_PAGE, >> PA_PGD, and PA_SWAP_PAGE in the page list. Since the number >> and purpose of the pages is established entirely by the guest >> kernel, all you need to obey is that the hypervisor expects >> alternating PA_/VA_ pairs (where the VA_ ones can be left >> unpopulated). Perhaps taking a look at a recent SLES kernel >> would help... > > I have got > ftp://ftp.suse.com/pub/projects/kernel/kotd/SLE11-SP2/src/kernel-source-3.0. > 43-6.1.src.rpm. > Does kexec/kdump work in your environment? In my it does not. While I never ran it myself, I know kdump has been working on SLE for quite a long while (leaving aside hardware or firmware quirks requiring extra workarounds). > At least there is wrong assumption that > vaddr = (unsigned long)relocate_kernel > gets virtual address of relocate_kernel in Xen Where did you spot that? Afaics the only thing done with relocate_kernel is that it gets copied into the control page. > (I have tested only x86_64 implementation but > as I saw i386 has similar problem). In real it is > fix mapped in hypervisor which is completely > different than address calculated in dom0 kernel. > Virtual address of control page (and others) is > only known by hypervisor kexec/kdump functions. > It means that transition page table could be > established by relocate_kernel code only. > If you would like to do optimistation as you > mentioned above you must reintroduce code > for page table establishment into generic > relocate_kernel_??.S. However, another > problem arises. New generic code utilizes > additional arguments such as swap page > (and potentially could use others in the future). > As I saw it is not possible to pass extra addresses > through page_list[] in struct xen_kexec_image > because its has insufficient size (I mean > x86_64 because i386 is a bit different story). No - there's no meaning assigned by Xen to any of the slots, except for said assumption about them representing alternating PA_/VA_ pairs. Hence, as long as old entries get removed, new slots can easily be added (and the number of slots currently needed is far lower than what was used originally [2.6.18]). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 14:04:31 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 14:04:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIgbT-0002zC-LA; Mon, 01 Oct 2012 14:04:11 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIgbS-0002z4-4F for xen-devel@lists.xen.org; Mon, 01 Oct 2012 14:04:10 +0000 Received: from [85.158.139.211:37244] by server-3.bemta-5.messagelabs.com id 4C/7C-16108-9D2A9605; Mon, 01 Oct 2012 14:04:09 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-12.tower-206.messagelabs.com!1349100247!19621385!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzkwMjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15285 invoked from network); 1 Oct 2012 14:04:08 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 14:04:08 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="209884624" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 14:04:07 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 10:04:06 -0400 Received: from [10.80.3.61] by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TIgbO-00022w-Ej; Mon, 01 Oct 2012 15:04:06 +0100 Message-ID: <5069A2D5.9010205@citrix.com> Date: Mon, 1 Oct 2012 15:04:05 +0100 From: Anthony PERARD User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120910 Thunderbird/15.0.1 MIME-Version: 1.0 To: Ian Jackson References: <1348666294-18182-1-git-send-email-anthony.perard@citrix.com> <1348666294-18182-2-git-send-email-anthony.perard@citrix.com> <20581.56505.946303.990641@mariner.uk.xensource.com> In-Reply-To: <20581.56505.946303.990641@mariner.uk.xensource.com> Cc: Ian Campbell , Xen Devel Subject: Re: [Xen-devel] [PATCH 1/2] libxl_json: Use libxl alloc function X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 09/28/2012 06:22 PM, Ian Jackson wrote: > Anthony PERARD writes ("[Xen-devel] [PATCH 1/2] libxl_json: Use libxl alloc function"): >> This patch makes use of the libxl allocation API and removes the check for >> allocation failure. >> >> This patch also assume that flexarray does not need to be freed as it will be >> gc'd in the next patch. > > Is this really the right way to structure this series ? It seems that > after applying only the first, the code has a memory leak. Yes, there is a memory leak if only this patch is applied. I'll find a better way to structure this patch series. -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 14:04:31 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 14:04:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIgbT-0002zC-LA; Mon, 01 Oct 2012 14:04:11 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIgbS-0002z4-4F for xen-devel@lists.xen.org; Mon, 01 Oct 2012 14:04:10 +0000 Received: from [85.158.139.211:37244] by server-3.bemta-5.messagelabs.com id 4C/7C-16108-9D2A9605; Mon, 01 Oct 2012 14:04:09 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-12.tower-206.messagelabs.com!1349100247!19621385!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzkwMjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15285 invoked from network); 1 Oct 2012 14:04:08 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 14:04:08 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="209884624" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 14:04:07 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 10:04:06 -0400 Received: from [10.80.3.61] by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TIgbO-00022w-Ej; Mon, 01 Oct 2012 15:04:06 +0100 Message-ID: <5069A2D5.9010205@citrix.com> Date: Mon, 1 Oct 2012 15:04:05 +0100 From: Anthony PERARD User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120910 Thunderbird/15.0.1 MIME-Version: 1.0 To: Ian Jackson References: <1348666294-18182-1-git-send-email-anthony.perard@citrix.com> <1348666294-18182-2-git-send-email-anthony.perard@citrix.com> <20581.56505.946303.990641@mariner.uk.xensource.com> In-Reply-To: <20581.56505.946303.990641@mariner.uk.xensource.com> Cc: Ian Campbell , Xen Devel Subject: Re: [Xen-devel] [PATCH 1/2] libxl_json: Use libxl alloc function X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 09/28/2012 06:22 PM, Ian Jackson wrote: > Anthony PERARD writes ("[Xen-devel] [PATCH 1/2] libxl_json: Use libxl alloc function"): >> This patch makes use of the libxl allocation API and removes the check for >> allocation failure. >> >> This patch also assume that flexarray does not need to be freed as it will be >> gc'd in the next patch. > > Is this really the right way to structure this series ? It seems that > after applying only the first, the code has a memory leak. Yes, there is a memory leak if only this patch is applied. I'll find a better way to structure this patch series. -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 14:15:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 14:15:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIgmA-0003AE-38; Mon, 01 Oct 2012 14:15:14 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIgm8-0003A6-Jn for xen-devel@lists.xen.org; Mon, 01 Oct 2012 14:15:12 +0000 Received: from [85.158.138.51:11593] by server-7.bemta-3.messagelabs.com id C7/36-15765-F65A9605; Mon, 01 Oct 2012 14:15:11 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1349100909!13964199!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzkwMjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2172 invoked from network); 1 Oct 2012 14:15:11 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 14:15:11 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="209886713" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 14:15:08 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 10:15:08 -0400 Received: from [10.80.3.61] by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TIgm4-0002v8-7H; Mon, 01 Oct 2012 15:15:08 +0100 Message-ID: <5069A56B.4000605@citrix.com> Date: Mon, 1 Oct 2012 15:15:07 +0100 From: Anthony PERARD User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120910 Thunderbird/15.0.1 MIME-Version: 1.0 To: Ian Jackson References: <1348666294-18182-1-git-send-email-anthony.perard@citrix.com> <1348666294-18182-3-git-send-email-anthony.perard@citrix.com> <20581.56805.294140.556698@mariner.uk.xensource.com> In-Reply-To: <20581.56805.294140.556698@mariner.uk.xensource.com> Cc: Ian Campbell , Xen Devel Subject: Re: [Xen-devel] [PATCH 2/2] libxl: Have flexarray using the GC X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 09/28/2012 06:27 PM, Ian Jackson wrote: > Anthony PERARD writes ("[Xen-devel] [PATCH 2/2] libxl: Have flexarray using the GC"): >> This patch makes the flexarray function libxl__gc aware. > ... >> -flexarray_t *flexarray_make(int size, int autogrow) >> +flexarray_t *flexarray_make(libxl__gc *gc, int size, int autogrow) > ... >> { > ... >> + array->gc = gc; > > If gc is NOGC then this does the wrong thing. Callers should be able > to specify NOGC for a flexarray which they want to survive across > multiple calls into libxl. I'm not sure I see your point here. If a something needs a NOGC'ed flexarray, then flexarray_make(NOGC, x, x) will give this. > For this all to work correctly, including error handling, I think > flexarray_grow and its callers need to take a gc from the context. It > would be wise to assert that the either 1. both the gc passed to make > and grow are NOGC or 2. they are the same. All right, I'll add gc to _grow and it's caller. And will assert on both condition. Thanks, -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 14:15:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 14:15:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIgmA-0003AE-38; Mon, 01 Oct 2012 14:15:14 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIgm8-0003A6-Jn for xen-devel@lists.xen.org; Mon, 01 Oct 2012 14:15:12 +0000 Received: from [85.158.138.51:11593] by server-7.bemta-3.messagelabs.com id C7/36-15765-F65A9605; Mon, 01 Oct 2012 14:15:11 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1349100909!13964199!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzkwMjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2172 invoked from network); 1 Oct 2012 14:15:11 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 14:15:11 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="209886713" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 14:15:08 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 10:15:08 -0400 Received: from [10.80.3.61] by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TIgm4-0002v8-7H; Mon, 01 Oct 2012 15:15:08 +0100 Message-ID: <5069A56B.4000605@citrix.com> Date: Mon, 1 Oct 2012 15:15:07 +0100 From: Anthony PERARD User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120910 Thunderbird/15.0.1 MIME-Version: 1.0 To: Ian Jackson References: <1348666294-18182-1-git-send-email-anthony.perard@citrix.com> <1348666294-18182-3-git-send-email-anthony.perard@citrix.com> <20581.56805.294140.556698@mariner.uk.xensource.com> In-Reply-To: <20581.56805.294140.556698@mariner.uk.xensource.com> Cc: Ian Campbell , Xen Devel Subject: Re: [Xen-devel] [PATCH 2/2] libxl: Have flexarray using the GC X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 09/28/2012 06:27 PM, Ian Jackson wrote: > Anthony PERARD writes ("[Xen-devel] [PATCH 2/2] libxl: Have flexarray using the GC"): >> This patch makes the flexarray function libxl__gc aware. > ... >> -flexarray_t *flexarray_make(int size, int autogrow) >> +flexarray_t *flexarray_make(libxl__gc *gc, int size, int autogrow) > ... >> { > ... >> + array->gc = gc; > > If gc is NOGC then this does the wrong thing. Callers should be able > to specify NOGC for a flexarray which they want to survive across > multiple calls into libxl. I'm not sure I see your point here. If a something needs a NOGC'ed flexarray, then flexarray_make(NOGC, x, x) will give this. > For this all to work correctly, including error handling, I think > flexarray_grow and its callers need to take a gc from the context. It > would be wise to assert that the either 1. both the gc passed to make > and grow are NOGC or 2. they are the same. All right, I'll add gc to _grow and it's caller. And will assert on both condition. Thanks, -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 14:18:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 14:18:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIgon-0003G0-LU; Mon, 01 Oct 2012 14:17:57 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIgom-0003Ft-Sc for xen-devel@lists.xensource.com; Mon, 01 Oct 2012 14:17:57 +0000 Received: from [85.158.139.211:7460] by server-5.bemta-5.messagelabs.com id C4/1D-21075-416A9605; Mon, 01 Oct 2012 14:17:56 +0000 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-14.tower-206.messagelabs.com!1349101075!20568124!1 X-Originating-IP: [74.125.83.43] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14668 invoked from network); 1 Oct 2012 14:17:55 -0000 Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com) (74.125.83.43) by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 14:17:55 -0000 Received: by eekc13 with SMTP id c13so2416694eek.30 for ; Mon, 01 Oct 2012 07:17:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=17CwRsbe04pZp+JpJbfOey9trFWuMUa45r0FbmrIAHw=; b=FdqUSPdNrtCb58w1mvFhSdvF2HYR6dI1uDIVRlcPRCEgg3QYLnx0drROvPZbA4b9Ie GbyMu1BGvjwdy8bKiSnp5G+Z3FG5GsznEvGOOX2pxyi4IWovg2ZERlUImVQeb4Xtqa2L FNSCYJk1sOZNwsI+R4EKRVbgWtPI76B5QFXuX5pOd96pyd/HgNlQSa3cidxHeEcW6nKh Jy+7YQw9+xameQ6CMBB4vLjOma2SLrIUqMrB/3aZmX+y2jmM5m8rqkvJww5Iq7cxf3yh l5bmVdJKvfeHdwvmZDxyWDcUc7QusHIoedihQRjVeGR+vfLFx+VNYyW6WB26jDg6C0n/ jwKA== MIME-Version: 1.0 Received: by 10.14.172.193 with SMTP id t41mr18296497eel.25.1349101075181; Mon, 01 Oct 2012 07:17:55 -0700 (PDT) Received: by 10.14.215.195 with HTTP; Mon, 1 Oct 2012 07:17:55 -0700 (PDT) In-Reply-To: References: Date: Mon, 1 Oct 2012 15:17:55 +0100 X-Google-Sender-Auth: Lg2_qS5IHFnAMQORdq6NHiSSS8A Message-ID: From: George Dunlap To: =?UTF-8?B?6ams56OK?= Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] =?utf-8?b?44CQY29uZnVzZWTjgJF3aGF0IGRvZXMgeGNfbWFw?= =?utf-8?b?X2ZvcmVpZ25fYmF0Y2ggZG/vvJ8=?= X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org T24gU2F0LCBTZXAgMjksIDIwMTIgYXQgNDowNyBBTSwg6ams56OKIDxhd2FyZS53aHlAZ21haWwu Y29tPiB3cm90ZToKPiBIae+8jCBhbGwKPiAgSW4gdG9vbHMvbGlieGMveGNfZG9tYWluX3NhdmUg LmMsIG9uZSBmdW5jdGlvbiBjYWxsZWQKPiBgbWFwX2FuZF9zYXZlX3AybV90YWJsZWAgd2hlcmUg dGhlcmUgZXhpc3RzIGEgY29uZnVzaW5nIHByb2JsZW0sIGFzIGlzIHNob3duCj4gYmVsb3c6Cj4K PiAgNjIxICAgIGxpdmVfcDJtX2ZyYW1lX2xpc3QgPQo+ICA2MjIgICAgICAgIHhjX21hcF9mb3Jl aWduX2JhdGNoKHhjX2hhbmRsZSwgZG9tLCBQUk9UX1JFQUQsCj4gIDYyMyAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgcDJtX2ZyYW1lX2xpc3RfbGlzdCwKPiAgNjI0ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBQMk1fRkxMX0VOVFJJRVMpOwo+Cj4gbWVtY3B5KHAybV9mcmFtZV9saXN0 LCBsaXZlX3AybV9mcmFtZV9saXN0LCBQMk1fR1VFU1RfRkxfU0laRSk7Cj4KPiAgNjU0ICAgIHAy bSA9IHhjX21hcF9mb3JlaWduX2JhdGNoKHhjX2hhbmRsZSwgZG9tLCBQUk9UX1JFQUQsCj4gIDY1 NSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwMm1fZnJhbWVfbGlzdCwKPiAgNjU2ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFAyTV9GTF9FTlRSSUVTKTsKPgo+Cj4gbWF5YmUg c29tZW9uZSBlbmNvdW50ZXJlZCB0aGUgc2FtZSBwcm9ibGVtLCB3b3VsZCB5b3UgaGVscCBtZT8K CldoYXQncyB0aGUgcHJvYmxlbT8KCj4gQmVzaWRlcywgd2hhdCdzIHRoZSBkaWZmZXJlbmNlIGJl dHdlZW4gSU9DVExfUFJJVkNNRF9NTUFQIGFuZAo+IElPQ1RMX1BSSVZDTURfTU1BUEJBVENIPwoK SU9DVExfUFJJVkNNRF9NTUFQIHdpbGwgb25seSBtYXAgYSBzaW5nbGUgcGFnZTsgTU1BUEJBVENI IHdpbGwgbWFwIGFuCmFycmF5IG9mIHBhZ2VzLgoKKFRvICJiYXRjaCIgc29tZXRoaW5nIGluIGNv bXB1dGluZyBtZWFucyB0byBkbyBhIGJ1bmNoIG9mIHRoaW5ncyBhbGwKdG9nZXRoZXIgcmF0aGVy IHRoYW4gZG9pbmcgdGhlbSBzZXBhcmF0ZWx5OyBlLmcuLCByYXRoZXIgdGhhbiBtYXBwaW5nCmVh Y2ggcGFnZSB3aXRoIGEgc2VwYXJhdGUgaW9jdGwsIHlvdSAiYmF0Y2giIHRoZW0gYWxsIHRvZ2V0 aGVyIGluIG9uZQppb2N0bC4pCgogLUdlb3JnZQoKX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlz dHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK From xen-devel-bounces@lists.xen.org Mon Oct 01 14:18:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 14:18:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIgon-0003G0-LU; Mon, 01 Oct 2012 14:17:57 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIgom-0003Ft-Sc for xen-devel@lists.xensource.com; Mon, 01 Oct 2012 14:17:57 +0000 Received: from [85.158.139.211:7460] by server-5.bemta-5.messagelabs.com id C4/1D-21075-416A9605; Mon, 01 Oct 2012 14:17:56 +0000 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-14.tower-206.messagelabs.com!1349101075!20568124!1 X-Originating-IP: [74.125.83.43] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14668 invoked from network); 1 Oct 2012 14:17:55 -0000 Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com) (74.125.83.43) by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 14:17:55 -0000 Received: by eekc13 with SMTP id c13so2416694eek.30 for ; Mon, 01 Oct 2012 07:17:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=17CwRsbe04pZp+JpJbfOey9trFWuMUa45r0FbmrIAHw=; b=FdqUSPdNrtCb58w1mvFhSdvF2HYR6dI1uDIVRlcPRCEgg3QYLnx0drROvPZbA4b9Ie GbyMu1BGvjwdy8bKiSnp5G+Z3FG5GsznEvGOOX2pxyi4IWovg2ZERlUImVQeb4Xtqa2L FNSCYJk1sOZNwsI+R4EKRVbgWtPI76B5QFXuX5pOd96pyd/HgNlQSa3cidxHeEcW6nKh Jy+7YQw9+xameQ6CMBB4vLjOma2SLrIUqMrB/3aZmX+y2jmM5m8rqkvJww5Iq7cxf3yh l5bmVdJKvfeHdwvmZDxyWDcUc7QusHIoedihQRjVeGR+vfLFx+VNYyW6WB26jDg6C0n/ jwKA== MIME-Version: 1.0 Received: by 10.14.172.193 with SMTP id t41mr18296497eel.25.1349101075181; Mon, 01 Oct 2012 07:17:55 -0700 (PDT) Received: by 10.14.215.195 with HTTP; Mon, 1 Oct 2012 07:17:55 -0700 (PDT) In-Reply-To: References: Date: Mon, 1 Oct 2012 15:17:55 +0100 X-Google-Sender-Auth: Lg2_qS5IHFnAMQORdq6NHiSSS8A Message-ID: From: George Dunlap To: =?UTF-8?B?6ams56OK?= Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] =?utf-8?b?44CQY29uZnVzZWTjgJF3aGF0IGRvZXMgeGNfbWFw?= =?utf-8?b?X2ZvcmVpZ25fYmF0Y2ggZG/vvJ8=?= X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org T24gU2F0LCBTZXAgMjksIDIwMTIgYXQgNDowNyBBTSwg6ams56OKIDxhd2FyZS53aHlAZ21haWwu Y29tPiB3cm90ZToKPiBIae+8jCBhbGwKPiAgSW4gdG9vbHMvbGlieGMveGNfZG9tYWluX3NhdmUg LmMsIG9uZSBmdW5jdGlvbiBjYWxsZWQKPiBgbWFwX2FuZF9zYXZlX3AybV90YWJsZWAgd2hlcmUg dGhlcmUgZXhpc3RzIGEgY29uZnVzaW5nIHByb2JsZW0sIGFzIGlzIHNob3duCj4gYmVsb3c6Cj4K PiAgNjIxICAgIGxpdmVfcDJtX2ZyYW1lX2xpc3QgPQo+ICA2MjIgICAgICAgIHhjX21hcF9mb3Jl aWduX2JhdGNoKHhjX2hhbmRsZSwgZG9tLCBQUk9UX1JFQUQsCj4gIDYyMyAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgcDJtX2ZyYW1lX2xpc3RfbGlzdCwKPiAgNjI0ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBQMk1fRkxMX0VOVFJJRVMpOwo+Cj4gbWVtY3B5KHAybV9mcmFtZV9saXN0 LCBsaXZlX3AybV9mcmFtZV9saXN0LCBQMk1fR1VFU1RfRkxfU0laRSk7Cj4KPiAgNjU0ICAgIHAy bSA9IHhjX21hcF9mb3JlaWduX2JhdGNoKHhjX2hhbmRsZSwgZG9tLCBQUk9UX1JFQUQsCj4gIDY1 NSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwMm1fZnJhbWVfbGlzdCwKPiAgNjU2ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFAyTV9GTF9FTlRSSUVTKTsKPgo+Cj4gbWF5YmUg c29tZW9uZSBlbmNvdW50ZXJlZCB0aGUgc2FtZSBwcm9ibGVtLCB3b3VsZCB5b3UgaGVscCBtZT8K CldoYXQncyB0aGUgcHJvYmxlbT8KCj4gQmVzaWRlcywgd2hhdCdzIHRoZSBkaWZmZXJlbmNlIGJl dHdlZW4gSU9DVExfUFJJVkNNRF9NTUFQIGFuZAo+IElPQ1RMX1BSSVZDTURfTU1BUEJBVENIPwoK SU9DVExfUFJJVkNNRF9NTUFQIHdpbGwgb25seSBtYXAgYSBzaW5nbGUgcGFnZTsgTU1BUEJBVENI IHdpbGwgbWFwIGFuCmFycmF5IG9mIHBhZ2VzLgoKKFRvICJiYXRjaCIgc29tZXRoaW5nIGluIGNv bXB1dGluZyBtZWFucyB0byBkbyBhIGJ1bmNoIG9mIHRoaW5ncyBhbGwKdG9nZXRoZXIgcmF0aGVy IHRoYW4gZG9pbmcgdGhlbSBzZXBhcmF0ZWx5OyBlLmcuLCByYXRoZXIgdGhhbiBtYXBwaW5nCmVh Y2ggcGFnZSB3aXRoIGEgc2VwYXJhdGUgaW9jdGwsIHlvdSAiYmF0Y2giIHRoZW0gYWxsIHRvZ2V0 aGVyIGluIG9uZQppb2N0bC4pCgogLUdlb3JnZQoKX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlz dHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK From xen-devel-bounces@lists.xen.org Mon Oct 01 14:18:39 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 14:18:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIgpD-0003Io-8K; Mon, 01 Oct 2012 14:18:23 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIgpC-0003If-3v for xen-devel@lists.xen.org; Mon, 01 Oct 2012 14:18:22 +0000 Received: from [85.158.139.83:59022] by server-9.bemta-5.messagelabs.com id 33/E1-14846-D26A9605; Mon, 01 Oct 2012 14:18:21 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1349101100!32882439!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI1NjQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21703 invoked from network); 1 Oct 2012 14:18:21 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 14:18:21 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="14871997" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 14:17:33 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 15:17:33 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TIgoP-0000DO-Ca; Mon, 01 Oct 2012 14:17:33 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TIgoP-0004lH-8Z; Mon, 01 Oct 2012 15:17:33 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20585.42493.151224.551455@mariner.uk.xensource.com> Date: Mon, 1 Oct 2012 15:17:33 +0100 To: Anthony PERARD In-Reply-To: <5069A56B.4000605@citrix.com> References: <1348666294-18182-1-git-send-email-anthony.perard@citrix.com> <1348666294-18182-3-git-send-email-anthony.perard@citrix.com> <20581.56805.294140.556698@mariner.uk.xensource.com> <5069A56B.4000605@citrix.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Ian Jackson , Ian Campbell , Xen Devel Subject: Re: [Xen-devel] [PATCH 2/2] libxl: Have flexarray using the GC X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Anthony PERARD writes ("Re: [Xen-devel] [PATCH 2/2] libxl: Have flexarray using the GC"): > On 09/28/2012 06:27 PM, Ian Jackson wrote: > > If gc is NOGC then this does the wrong thing. Callers should be able > > to specify NOGC for a flexarray which they want to survive across > > multiple calls into libxl. > > I'm not sure I see your point here. If a something needs a NOGC'ed > flexarray, then flexarray_make(NOGC, x, x) will give this. So then you put the flexarray in some long-term data structure, which survives the call to libxl and therefore the gc. Is it safe for NOGC's gc*, derived from the now-destroyed actual gc, to be embedded in the flexarray and reused later in a different libxl call with a different gc (but the same ctx) ? > > For this all to work correctly, including error handling, I think > > flexarray_grow and its callers need to take a gc from the context. It > > would be wise to assert that the either 1. both the gc passed to make > > and grow are NOGC or 2. they are the same. > > All right, I'll add gc to _grow and it's caller. And will assert on both > condition. Feel free instead to explain to me why I'm wrong :-). Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 14:18:39 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 14:18:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIgpD-0003Io-8K; Mon, 01 Oct 2012 14:18:23 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIgpC-0003If-3v for xen-devel@lists.xen.org; Mon, 01 Oct 2012 14:18:22 +0000 Received: from [85.158.139.83:59022] by server-9.bemta-5.messagelabs.com id 33/E1-14846-D26A9605; Mon, 01 Oct 2012 14:18:21 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1349101100!32882439!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI1NjQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21703 invoked from network); 1 Oct 2012 14:18:21 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 14:18:21 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="14871997" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 14:17:33 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 15:17:33 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TIgoP-0000DO-Ca; Mon, 01 Oct 2012 14:17:33 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TIgoP-0004lH-8Z; Mon, 01 Oct 2012 15:17:33 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20585.42493.151224.551455@mariner.uk.xensource.com> Date: Mon, 1 Oct 2012 15:17:33 +0100 To: Anthony PERARD In-Reply-To: <5069A56B.4000605@citrix.com> References: <1348666294-18182-1-git-send-email-anthony.perard@citrix.com> <1348666294-18182-3-git-send-email-anthony.perard@citrix.com> <20581.56805.294140.556698@mariner.uk.xensource.com> <5069A56B.4000605@citrix.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Ian Jackson , Ian Campbell , Xen Devel Subject: Re: [Xen-devel] [PATCH 2/2] libxl: Have flexarray using the GC X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Anthony PERARD writes ("Re: [Xen-devel] [PATCH 2/2] libxl: Have flexarray using the GC"): > On 09/28/2012 06:27 PM, Ian Jackson wrote: > > If gc is NOGC then this does the wrong thing. Callers should be able > > to specify NOGC for a flexarray which they want to survive across > > multiple calls into libxl. > > I'm not sure I see your point here. If a something needs a NOGC'ed > flexarray, then flexarray_make(NOGC, x, x) will give this. So then you put the flexarray in some long-term data structure, which survives the call to libxl and therefore the gc. Is it safe for NOGC's gc*, derived from the now-destroyed actual gc, to be embedded in the flexarray and reused later in a different libxl call with a different gc (but the same ctx) ? > > For this all to work correctly, including error handling, I think > > flexarray_grow and its callers need to take a gc from the context. It > > would be wise to assert that the either 1. both the gc passed to make > > and grow are NOGC or 2. they are the same. > > All right, I'll add gc to _grow and it's caller. And will assert on both > condition. Feel free instead to explain to me why I'm wrong :-). Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 14:24:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 14:24:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIguU-0003cL-0H; Mon, 01 Oct 2012 14:23:50 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIguS-0003cG-6M for xen-devel@lists.xen.org; Mon, 01 Oct 2012 14:23:48 +0000 Received: from [85.158.139.83:55724] by server-1.bemta-5.messagelabs.com id CB/67-09825-377A9605; Mon, 01 Oct 2012 14:23:47 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-2.tower-182.messagelabs.com!1349101425!30052196!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzkwMjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27734 invoked from network); 1 Oct 2012 14:23:46 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 14:23:46 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="209887812" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 14:23:44 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 10:23:44 -0400 Received: from [10.80.3.61] by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TIguO-0004a1-3P; Mon, 01 Oct 2012 15:23:44 +0100 Message-ID: <5069A76F.8040901@citrix.com> Date: Mon, 1 Oct 2012 15:23:43 +0100 From: Anthony PERARD User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120910 Thunderbird/15.0.1 MIME-Version: 1.0 To: Ian Jackson References: <1348666294-18182-1-git-send-email-anthony.perard@citrix.com> <1348666294-18182-3-git-send-email-anthony.perard@citrix.com> <20581.56805.294140.556698@mariner.uk.xensource.com> <5069A56B.4000605@citrix.com> <20585.42493.151224.551455@mariner.uk.xensource.com> In-Reply-To: <20585.42493.151224.551455@mariner.uk.xensource.com> Cc: Ian Campbell , Xen Devel Subject: Re: [Xen-devel] [PATCH 2/2] libxl: Have flexarray using the GC X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 10/01/2012 03:17 PM, Ian Jackson wrote: > Anthony PERARD writes ("Re: [Xen-devel] [PATCH 2/2] libxl: Have flexarray using the GC"): >> > On 09/28/2012 06:27 PM, Ian Jackson wrote: >>> > > If gc is NOGC then this does the wrong thing. Callers should be able >>> > > to specify NOGC for a flexarray which they want to survive across >>> > > multiple calls into libxl. >> > >> > I'm not sure I see your point here. If a something needs a NOGC'ed >> > flexarray, then flexarray_make(NOGC, x, x) will give this. > So then you put the flexarray in some long-term data structure, which > survives the call to libxl and therefore the gc. Is it safe for > NOGC's gc*, derived from the now-destroyed actual gc, to be embedded > in the flexarray and reused later in a different libxl call with a > different gc (but the same ctx) ? Ah, I now see the issue, a pointer that lead nowhere :S. Thanks, -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 14:24:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 14:24:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIguU-0003cL-0H; Mon, 01 Oct 2012 14:23:50 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIguS-0003cG-6M for xen-devel@lists.xen.org; Mon, 01 Oct 2012 14:23:48 +0000 Received: from [85.158.139.83:55724] by server-1.bemta-5.messagelabs.com id CB/67-09825-377A9605; Mon, 01 Oct 2012 14:23:47 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-2.tower-182.messagelabs.com!1349101425!30052196!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzkwMjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27734 invoked from network); 1 Oct 2012 14:23:46 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 14:23:46 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="209887812" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 14:23:44 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 10:23:44 -0400 Received: from [10.80.3.61] by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TIguO-0004a1-3P; Mon, 01 Oct 2012 15:23:44 +0100 Message-ID: <5069A76F.8040901@citrix.com> Date: Mon, 1 Oct 2012 15:23:43 +0100 From: Anthony PERARD User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120910 Thunderbird/15.0.1 MIME-Version: 1.0 To: Ian Jackson References: <1348666294-18182-1-git-send-email-anthony.perard@citrix.com> <1348666294-18182-3-git-send-email-anthony.perard@citrix.com> <20581.56805.294140.556698@mariner.uk.xensource.com> <5069A56B.4000605@citrix.com> <20585.42493.151224.551455@mariner.uk.xensource.com> In-Reply-To: <20585.42493.151224.551455@mariner.uk.xensource.com> Cc: Ian Campbell , Xen Devel Subject: Re: [Xen-devel] [PATCH 2/2] libxl: Have flexarray using the GC X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 10/01/2012 03:17 PM, Ian Jackson wrote: > Anthony PERARD writes ("Re: [Xen-devel] [PATCH 2/2] libxl: Have flexarray using the GC"): >> > On 09/28/2012 06:27 PM, Ian Jackson wrote: >>> > > If gc is NOGC then this does the wrong thing. Callers should be able >>> > > to specify NOGC for a flexarray which they want to survive across >>> > > multiple calls into libxl. >> > >> > I'm not sure I see your point here. If a something needs a NOGC'ed >> > flexarray, then flexarray_make(NOGC, x, x) will give this. > So then you put the flexarray in some long-term data structure, which > survives the call to libxl and therefore the gc. Is it safe for > NOGC's gc*, derived from the now-destroyed actual gc, to be embedded > in the flexarray and reused later in a different libxl call with a > different gc (but the same ctx) ? Ah, I now see the issue, a pointer that lead nowhere :S. Thanks, -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 14:25:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 14:25:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIgwE-0003h9-GX; Mon, 01 Oct 2012 14:25:38 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIgwD-0003gx-Ak for xen-devel@lists.xen.org; Mon, 01 Oct 2012 14:25:37 +0000 Received: from [85.158.138.51:30771] by server-9.bemta-3.messagelabs.com id CC/2B-20338-0E7A9605; Mon, 01 Oct 2012 14:25:36 +0000 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1349101535!32634476!1 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26467 invoked from network); 1 Oct 2012 14:25:35 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 14:25:35 -0000 Received: by eekb47 with SMTP id b47so2518752eek.32 for ; Mon, 01 Oct 2012 07:25:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=liTrqXu/P8FHhxzf4pGvNUsJQ2CE45BQuaeCBIb+jQQ=; b=cQpqSSJ81v5mQMar2BWw7WRCI1vVTQgBWQGldptmHI7qzHymvOy5VX17eMI71/fRKH lgUgzx/ioMPhrNo8cMa4pRNHsyNZqktuhiFSA8KVtk7jwocIUe9KHgFkdIEQ8Jp09Gzt yrf/iBY02g6hOZuVaEV4p8aUWJ0ixUKy2/7emtFy7Sh1QvjQO35HuR+ASnA5D0qE0ALo Az6o9rP7numG3nlyIsKB4e2AHq0YgSLLV9zwHigZdkUpUyfhipl7kg8UtOKjvYYP7erF jC5bxl8uTLsEaWtxusJ20gQewaUJLjjR4fQWJeJWqDls3s3L0InEfq+iK/pUkdt0k2Cc mf6Q== MIME-Version: 1.0 Received: by 10.14.212.72 with SMTP id x48mr18140867eeo.40.1349101535050; Mon, 01 Oct 2012 07:25:35 -0700 (PDT) Received: by 10.14.215.195 with HTTP; Mon, 1 Oct 2012 07:25:35 -0700 (PDT) In-Reply-To: References: <20120929050455.GA21253@u002268147cd4502c336d.ant.amazon.com> Date: Mon, 1 Oct 2012 15:25:35 +0100 X-Google-Sender-Auth: huyAPd7v7Cgsl7uNkiQj1uTz45Y Message-ID: From: George Dunlap To: Ben Guthro Cc: Lars Kurth , Keir Fraser , Ian Jackson , Matt Wilson , xen-devel@lists.xen.org Subject: Re: [Xen-devel] [ANNOUNCE] Switching to git for primary Xen repositories X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org +1. I actually prefer mercurial personally, but it's pretty clear that a large % of devs are already using git for xen development, using a mirror; and that's just silly. :-) -George On Sun, Sep 30, 2012 at 10:15 PM, Ben Guthro wrote: > +1 here. > > Having the SCM system consistent with the other 2 projects intimately tied > with Xen (linux, and qemu) has definite advantages. > > > On Sat, Sep 29, 2012 at 1:54 AM, Keir Fraser wrote: >> >> On 29/09/2012 06:04, "Matt Wilson" wrote: >> >> > On Fri, Sep 28, 2012 at 06:16:41PM +0100, Ian Jackson wrote: >> >> Keir writes: >> >>> Our plan therefore, with the 4.2.0 release soon out of the way, is >> >>> to switch to git for all of our primary repositories. We will plan >> >>> to mirror development activity into the old mercurial repositories >> >>> at least in the short term. >> >> >> >> So if we're having a vote on this, as discussed: >> >> >> >> +1 >> > >> > Enthusiastic +1 >> >> +1 >> >> > Matt >> >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 14:25:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 14:25:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIgwE-0003h9-GX; Mon, 01 Oct 2012 14:25:38 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIgwD-0003gx-Ak for xen-devel@lists.xen.org; Mon, 01 Oct 2012 14:25:37 +0000 Received: from [85.158.138.51:30771] by server-9.bemta-3.messagelabs.com id CC/2B-20338-0E7A9605; Mon, 01 Oct 2012 14:25:36 +0000 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1349101535!32634476!1 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26467 invoked from network); 1 Oct 2012 14:25:35 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 14:25:35 -0000 Received: by eekb47 with SMTP id b47so2518752eek.32 for ; Mon, 01 Oct 2012 07:25:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=liTrqXu/P8FHhxzf4pGvNUsJQ2CE45BQuaeCBIb+jQQ=; b=cQpqSSJ81v5mQMar2BWw7WRCI1vVTQgBWQGldptmHI7qzHymvOy5VX17eMI71/fRKH lgUgzx/ioMPhrNo8cMa4pRNHsyNZqktuhiFSA8KVtk7jwocIUe9KHgFkdIEQ8Jp09Gzt yrf/iBY02g6hOZuVaEV4p8aUWJ0ixUKy2/7emtFy7Sh1QvjQO35HuR+ASnA5D0qE0ALo Az6o9rP7numG3nlyIsKB4e2AHq0YgSLLV9zwHigZdkUpUyfhipl7kg8UtOKjvYYP7erF jC5bxl8uTLsEaWtxusJ20gQewaUJLjjR4fQWJeJWqDls3s3L0InEfq+iK/pUkdt0k2Cc mf6Q== MIME-Version: 1.0 Received: by 10.14.212.72 with SMTP id x48mr18140867eeo.40.1349101535050; Mon, 01 Oct 2012 07:25:35 -0700 (PDT) Received: by 10.14.215.195 with HTTP; Mon, 1 Oct 2012 07:25:35 -0700 (PDT) In-Reply-To: References: <20120929050455.GA21253@u002268147cd4502c336d.ant.amazon.com> Date: Mon, 1 Oct 2012 15:25:35 +0100 X-Google-Sender-Auth: huyAPd7v7Cgsl7uNkiQj1uTz45Y Message-ID: From: George Dunlap To: Ben Guthro Cc: Lars Kurth , Keir Fraser , Ian Jackson , Matt Wilson , xen-devel@lists.xen.org Subject: Re: [Xen-devel] [ANNOUNCE] Switching to git for primary Xen repositories X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org +1. I actually prefer mercurial personally, but it's pretty clear that a large % of devs are already using git for xen development, using a mirror; and that's just silly. :-) -George On Sun, Sep 30, 2012 at 10:15 PM, Ben Guthro wrote: > +1 here. > > Having the SCM system consistent with the other 2 projects intimately tied > with Xen (linux, and qemu) has definite advantages. > > > On Sat, Sep 29, 2012 at 1:54 AM, Keir Fraser wrote: >> >> On 29/09/2012 06:04, "Matt Wilson" wrote: >> >> > On Fri, Sep 28, 2012 at 06:16:41PM +0100, Ian Jackson wrote: >> >> Keir writes: >> >>> Our plan therefore, with the 4.2.0 release soon out of the way, is >> >>> to switch to git for all of our primary repositories. We will plan >> >>> to mirror development activity into the old mercurial repositories >> >>> at least in the short term. >> >> >> >> So if we're having a vote on this, as discussed: >> >> >> >> +1 >> > >> > Enthusiastic +1 >> >> +1 >> >> > Matt >> >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 14:48:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 14:48:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIhIB-0003xz-I2; Mon, 01 Oct 2012 14:48:19 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIhI9-0003xt-Qw for xen-devel@lists.xen.org; Mon, 01 Oct 2012 14:48:18 +0000 Received: from [85.158.138.51:6839] by server-3.bemta-3.messagelabs.com id 13/7F-25962-13DA9605; Mon, 01 Oct 2012 14:48:17 +0000 X-Env-Sender: jefranca@gmail.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1349102895!30870927!1 X-Originating-IP: [209.85.220.173] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2083 invoked from network); 1 Oct 2012 14:48:16 -0000 Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com) (209.85.220.173) by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 14:48:16 -0000 Received: by vcbfl15 with SMTP id fl15so7088534vcb.32 for ; Mon, 01 Oct 2012 07:48:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=wXv2jI1yLhewzb6rUjyhjlVC1XXhYsactl6nun+yH+k=; b=mikfjMYYl/pl+iRLi8rK+QjJ/YG7Ld9/yp802nB4BBk1EyhQ2cyjddaav4Vqziic95 l6e7eF2oDV7To8Ub0kxj8s243vCwuojhv/A+/wOKqJYSRv2OqoS0rjEIYF+VKnwgbDq/ kIeGmih0E2TUQS6T39VixU384jORY9NzNkjtYlG/6CFj6twmk0KlKnpwQcxXzXaKyL+q +T2Ayn7Zhh4dS+6amlw8PGUJUpBmC5eX5bx7wCtS97ahjhoaOyTx/CAmYKtvRqhblxsM kgwE0geDLLWcPeyAPFxtBYtcAkqcoFnSLeULEUyjq5pD5iq/LGK5kufWTZkVSjHSYd/p AOhw== MIME-Version: 1.0 Received: by 10.52.16.110 with SMTP id f14mr6932059vdd.8.1349102894795; Mon, 01 Oct 2012 07:48:14 -0700 (PDT) Received: by 10.58.64.9 with HTTP; Mon, 1 Oct 2012 07:48:14 -0700 (PDT) Date: Mon, 1 Oct 2012 11:48:14 -0300 Message-ID: From: =?ISO-8859-1?Q?Jos=E9_Eduardo_Fran=E7a?= To: xen-devel@lists.xen.org Subject: [Xen-devel] How to get the checkpoint size in remus code? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0723724620675977208==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============0723724620675977208== Content-Type: multipart/alternative; boundary=bcaec5040ca6cf49d404cb007eef --bcaec5040ca6cf49d404cb007eef Content-Type: text/plain; charset=ISO-8859-1 Hi, I'm doing my master research and I need to adapt remus code. Now... I wanna get the checkpoint size (memory + disk) on each period. Does someone know what function does this? I think some *fd *object's function in remus code could just get the memory size. Does someone help me? Thanks --bcaec5040ca6cf49d404cb007eef Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I'm doing my master research and I need to adapt remus code.= Now... I wanna get the checkpoint size (memory + disk) on each period. Doe= s someone know what function does this? I think some fd object's= function in remus code could just get the memory size.

Does someone help me?

Thanks
--bcaec5040ca6cf49d404cb007eef-- --===============0723724620675977208== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============0723724620675977208==-- From xen-devel-bounces@lists.xen.org Mon Oct 01 14:48:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 14:48:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIhIB-0003xz-I2; Mon, 01 Oct 2012 14:48:19 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIhI9-0003xt-Qw for xen-devel@lists.xen.org; Mon, 01 Oct 2012 14:48:18 +0000 Received: from [85.158.138.51:6839] by server-3.bemta-3.messagelabs.com id 13/7F-25962-13DA9605; Mon, 01 Oct 2012 14:48:17 +0000 X-Env-Sender: jefranca@gmail.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1349102895!30870927!1 X-Originating-IP: [209.85.220.173] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2083 invoked from network); 1 Oct 2012 14:48:16 -0000 Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com) (209.85.220.173) by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 14:48:16 -0000 Received: by vcbfl15 with SMTP id fl15so7088534vcb.32 for ; Mon, 01 Oct 2012 07:48:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=wXv2jI1yLhewzb6rUjyhjlVC1XXhYsactl6nun+yH+k=; b=mikfjMYYl/pl+iRLi8rK+QjJ/YG7Ld9/yp802nB4BBk1EyhQ2cyjddaav4Vqziic95 l6e7eF2oDV7To8Ub0kxj8s243vCwuojhv/A+/wOKqJYSRv2OqoS0rjEIYF+VKnwgbDq/ kIeGmih0E2TUQS6T39VixU384jORY9NzNkjtYlG/6CFj6twmk0KlKnpwQcxXzXaKyL+q +T2Ayn7Zhh4dS+6amlw8PGUJUpBmC5eX5bx7wCtS97ahjhoaOyTx/CAmYKtvRqhblxsM kgwE0geDLLWcPeyAPFxtBYtcAkqcoFnSLeULEUyjq5pD5iq/LGK5kufWTZkVSjHSYd/p AOhw== MIME-Version: 1.0 Received: by 10.52.16.110 with SMTP id f14mr6932059vdd.8.1349102894795; Mon, 01 Oct 2012 07:48:14 -0700 (PDT) Received: by 10.58.64.9 with HTTP; Mon, 1 Oct 2012 07:48:14 -0700 (PDT) Date: Mon, 1 Oct 2012 11:48:14 -0300 Message-ID: From: =?ISO-8859-1?Q?Jos=E9_Eduardo_Fran=E7a?= To: xen-devel@lists.xen.org Subject: [Xen-devel] How to get the checkpoint size in remus code? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0723724620675977208==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============0723724620675977208== Content-Type: multipart/alternative; boundary=bcaec5040ca6cf49d404cb007eef --bcaec5040ca6cf49d404cb007eef Content-Type: text/plain; charset=ISO-8859-1 Hi, I'm doing my master research and I need to adapt remus code. Now... I wanna get the checkpoint size (memory + disk) on each period. Does someone know what function does this? I think some *fd *object's function in remus code could just get the memory size. Does someone help me? Thanks --bcaec5040ca6cf49d404cb007eef Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I'm doing my master research and I need to adapt remus code.= Now... I wanna get the checkpoint size (memory + disk) on each period. Doe= s someone know what function does this? I think some fd object's= function in remus code could just get the memory size.

Does someone help me?

Thanks
--bcaec5040ca6cf49d404cb007eef-- --===============0723724620675977208== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============0723724620675977208==-- From xen-devel-bounces@lists.xen.org Mon Oct 01 14:53:07 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 14:53:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIhMa-00045j-8x; Mon, 01 Oct 2012 14:52:52 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIhMY-00045c-UA for xen-devel@lists.xen.org; Mon, 01 Oct 2012 14:52:51 +0000 Received: from [85.158.143.35:13619] by server-3.bemta-4.messagelabs.com id B5/7F-10986-24EA9605; Mon, 01 Oct 2012 14:52:50 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-14.tower-21.messagelabs.com!1349103148!17013308!1 X-Originating-IP: [81.169.146.162] X-SpamReason: No, hits=0.3 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MTU1NzM=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MTU1NzM=\n,MAILTO_TO_SPAM_ADDR X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12903 invoked from network); 1 Oct 2012 14:52:32 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162) by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 14:52:32 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGiy0IFwQ= X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-085-064.pools.arcor-ip.net [88.65.85.64]) by smtp.strato.de (joses mo27) (RZmta 30.19 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id k0788fo91DlXFF for ; Mon, 1 Oct 2012 16:52:28 +0200 (CEST) Received: by probook.site (Postfix, from userid 1000) id D53A11863E; Mon, 1 Oct 2012 16:52:27 +0200 (CEST) Date: Mon, 1 Oct 2012 16:52:27 +0200 From: Olaf Hering To: xen-devel@lists.xen.org Message-ID: <20121001145227.GA27262@aepfle.de> References: <1348877636.5025.140661134113513.411BDE92@webmail.messagingengine.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1348877636.5025.140661134113513.411BDE92@webmail.messagingengine.com> User-Agent: Mutt/1.5.21.rev5555 (2012-07-20) Subject: Re: [Xen-devel] Xen HVM Guest fails (errors) to launch on Opensuse 12.2's Xen 4.2 + 'xl' toolstack X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, Sep 28, ar16@imapmail.org wrote: > Atm, the guest is failing to launch, with a series of errors: > > ... > libxl: error: libxl_create.c:901:domcreate_rebuild_done: cannot > (re-)build domain: -3 This is caused by an incorrect patch in the xen package, libxl__build_hvm() returns an error unconditional. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 14:53:07 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 14:53:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIhMa-00045j-8x; Mon, 01 Oct 2012 14:52:52 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIhMY-00045c-UA for xen-devel@lists.xen.org; Mon, 01 Oct 2012 14:52:51 +0000 Received: from [85.158.143.35:13619] by server-3.bemta-4.messagelabs.com id B5/7F-10986-24EA9605; Mon, 01 Oct 2012 14:52:50 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-14.tower-21.messagelabs.com!1349103148!17013308!1 X-Originating-IP: [81.169.146.162] X-SpamReason: No, hits=0.3 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MTU1NzM=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MTU1NzM=\n,MAILTO_TO_SPAM_ADDR X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12903 invoked from network); 1 Oct 2012 14:52:32 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162) by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 14:52:32 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGiy0IFwQ= X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-085-064.pools.arcor-ip.net [88.65.85.64]) by smtp.strato.de (joses mo27) (RZmta 30.19 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id k0788fo91DlXFF for ; Mon, 1 Oct 2012 16:52:28 +0200 (CEST) Received: by probook.site (Postfix, from userid 1000) id D53A11863E; Mon, 1 Oct 2012 16:52:27 +0200 (CEST) Date: Mon, 1 Oct 2012 16:52:27 +0200 From: Olaf Hering To: xen-devel@lists.xen.org Message-ID: <20121001145227.GA27262@aepfle.de> References: <1348877636.5025.140661134113513.411BDE92@webmail.messagingengine.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1348877636.5025.140661134113513.411BDE92@webmail.messagingengine.com> User-Agent: Mutt/1.5.21.rev5555 (2012-07-20) Subject: Re: [Xen-devel] Xen HVM Guest fails (errors) to launch on Opensuse 12.2's Xen 4.2 + 'xl' toolstack X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, Sep 28, ar16@imapmail.org wrote: > Atm, the guest is failing to launch, with a series of errors: > > ... > libxl: error: libxl_create.c:901:domcreate_rebuild_done: cannot > (re-)build domain: -3 This is caused by an incorrect patch in the xen package, libxl__build_hvm() returns an error unconditional. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 14:57:57 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 14:57:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIhRE-0004FD-W2; Mon, 01 Oct 2012 14:57:40 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIhRE-0004F7-Dy for xen-devel@lists.xen.org; Mon, 01 Oct 2012 14:57:40 +0000 Received: from [85.158.137.99:60179] by server-8.bemta-3.messagelabs.com id 27/0C-16337-36FA9605; Mon, 01 Oct 2012 14:57:39 +0000 X-Env-Sender: jun.nakajima@intel.com X-Msg-Ref: server-9.tower-217.messagelabs.com!1349103457!16669961!1 X-Originating-IP: [143.182.124.22] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11534 invoked from network); 1 Oct 2012 14:57:38 -0000 Received: from mga07.intel.com (HELO azsmga101.ch.intel.com) (143.182.124.22) by server-9.tower-217.messagelabs.com with SMTP; 1 Oct 2012 14:57:38 -0000 Received: from mail-qc0-f173.google.com ([209.85.216.173]) by mga03.intel.com with ESMTP/TLS/RC4-SHA; 01 Oct 2012 07:57:36 -0700 Received: by qcab12 with SMTP id b12so5312030qca.32 for ; Mon, 01 Oct 2012 07:57:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=w+somjJ/Fg8kc3AqZXfL201zKyEBmFXGn9oGwh9Uj+Q=; b=JcO2kMzt0FAGTGYwhfui59O6T58gwY2M+plK13+LFmaXPQeEEILNqNptA1zHQSxYGW LVKJaw7xcAbjpWVZJYE0d6ppHBwAFNCu+66h9AECfnEUQReXn3HqsRsmUzFTK36magRW fshd9RmI/P9hN+1z/OJ1INFcqrhCtoYRr/DrteX5Hone91joQDBmOWWLDpj5YEcpCMhg qz8isXv8sp/NRkNj5qTKfpWvr0lIJGf7qd9aB06oxeNo0GNydw98LiIJQQgRVBbPd/Ba z0LXx2/AaY/L4TE+w3auROF8chYR4wgo6PyADJFyPjhsMh4KM3MViuEEHSUDpEBc7/ON WjIQ== MIME-Version: 1.0 Received: by 10.224.182.147 with SMTP id cc19mr35457435qab.44.1349103455146; Mon, 01 Oct 2012 07:57:35 -0700 (PDT) Received: by 10.229.33.138 with HTTP; Mon, 1 Oct 2012 07:57:35 -0700 (PDT) In-Reply-To: <506579D5020000780009E66E@nat28.tlf.novell.com> References: <5056F7AB020000780009BB19@nat28.tlf.novell.com> <506579D5020000780009E66E@nat28.tlf.novell.com> Date: Mon, 1 Oct 2012 07:57:35 -0700 Message-ID: From: "Nakajima, Jun" To: Jan Beulich X-Gm-Message-State: ALoCoQlPgCC/2noYEixeuMwWXLAnfy4Bawsze5oUdPiA5DlEKnGsjS9MMyDXMsVY5PKCVx29kAXB Cc: xen-devel Subject: Re: [Xen-devel] Ping: [PATCH] x86/Intel: add further support for Ivy Bridge CPU models X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, Sep 28, 2012 at 1:20 AM, Jan Beulich wrote: > > x86/Intel: add further support for Ivy Bridge CPU models > > And some initial Haswell ones at once. > > Signed-off-by: Jan Beulich > > --- a/xen/arch/x86/acpi/cpu_idle.c > +++ b/xen/arch/x86/acpi/cpu_idle.c > @@ -128,11 +128,15 @@ static void do_get_hw_residencies(void * > > switch ( c->x86_model ) > { > - /* Ivy bridge */ > - case 0x3A: > /* Sandy bridge */ > case 0x2A: > case 0x2D: > + /* Ivy bridge */ > + case 0x3A: > + case 0x3E: > + /* Haswell */ > + case 0x3c: > + case 0x45: > GET_PC2_RES(hw_res->pc2); > GET_CC7_RES(hw_res->cc7); > /* fall through */ > --- a/xen/arch/x86/hvm/vmx/vmx.c > +++ b/xen/arch/x86/hvm/vmx/vmx.c > @@ -1746,7 +1746,9 @@ static const struct lbr_info *last_branc > /* Sandy Bridge */ > case 42: case 45: > /* Ivy Bridge */ > - case 58: > + case 58: case 62: > + /* Haswell */ > + case 60: case 69: > return nh_lbr; > break; > /* Atom */ > --- a/xen/arch/x86/hvm/vmx/vpmu_core2.c > +++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c > @@ -747,6 +747,7 @@ int vmx_vpmu_initialise(struct vcpu *v, > case 46: > case 47: > case 58: > + case 62: > ret = core2_vpmu_initialise(v, vpmu_flags); > if ( !ret ) > vpmu->arch_vpmu_ops = &core2_vpmu_ops; > > > Looks good to me. -- Jun Intel Open Source Technology Center _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 14:57:57 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 14:57:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIhRE-0004FD-W2; Mon, 01 Oct 2012 14:57:40 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIhRE-0004F7-Dy for xen-devel@lists.xen.org; Mon, 01 Oct 2012 14:57:40 +0000 Received: from [85.158.137.99:60179] by server-8.bemta-3.messagelabs.com id 27/0C-16337-36FA9605; Mon, 01 Oct 2012 14:57:39 +0000 X-Env-Sender: jun.nakajima@intel.com X-Msg-Ref: server-9.tower-217.messagelabs.com!1349103457!16669961!1 X-Originating-IP: [143.182.124.22] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11534 invoked from network); 1 Oct 2012 14:57:38 -0000 Received: from mga07.intel.com (HELO azsmga101.ch.intel.com) (143.182.124.22) by server-9.tower-217.messagelabs.com with SMTP; 1 Oct 2012 14:57:38 -0000 Received: from mail-qc0-f173.google.com ([209.85.216.173]) by mga03.intel.com with ESMTP/TLS/RC4-SHA; 01 Oct 2012 07:57:36 -0700 Received: by qcab12 with SMTP id b12so5312030qca.32 for ; Mon, 01 Oct 2012 07:57:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=w+somjJ/Fg8kc3AqZXfL201zKyEBmFXGn9oGwh9Uj+Q=; b=JcO2kMzt0FAGTGYwhfui59O6T58gwY2M+plK13+LFmaXPQeEEILNqNptA1zHQSxYGW LVKJaw7xcAbjpWVZJYE0d6ppHBwAFNCu+66h9AECfnEUQReXn3HqsRsmUzFTK36magRW fshd9RmI/P9hN+1z/OJ1INFcqrhCtoYRr/DrteX5Hone91joQDBmOWWLDpj5YEcpCMhg qz8isXv8sp/NRkNj5qTKfpWvr0lIJGf7qd9aB06oxeNo0GNydw98LiIJQQgRVBbPd/Ba z0LXx2/AaY/L4TE+w3auROF8chYR4wgo6PyADJFyPjhsMh4KM3MViuEEHSUDpEBc7/ON WjIQ== MIME-Version: 1.0 Received: by 10.224.182.147 with SMTP id cc19mr35457435qab.44.1349103455146; Mon, 01 Oct 2012 07:57:35 -0700 (PDT) Received: by 10.229.33.138 with HTTP; Mon, 1 Oct 2012 07:57:35 -0700 (PDT) In-Reply-To: <506579D5020000780009E66E@nat28.tlf.novell.com> References: <5056F7AB020000780009BB19@nat28.tlf.novell.com> <506579D5020000780009E66E@nat28.tlf.novell.com> Date: Mon, 1 Oct 2012 07:57:35 -0700 Message-ID: From: "Nakajima, Jun" To: Jan Beulich X-Gm-Message-State: ALoCoQlPgCC/2noYEixeuMwWXLAnfy4Bawsze5oUdPiA5DlEKnGsjS9MMyDXMsVY5PKCVx29kAXB Cc: xen-devel Subject: Re: [Xen-devel] Ping: [PATCH] x86/Intel: add further support for Ivy Bridge CPU models X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, Sep 28, 2012 at 1:20 AM, Jan Beulich wrote: > > x86/Intel: add further support for Ivy Bridge CPU models > > And some initial Haswell ones at once. > > Signed-off-by: Jan Beulich > > --- a/xen/arch/x86/acpi/cpu_idle.c > +++ b/xen/arch/x86/acpi/cpu_idle.c > @@ -128,11 +128,15 @@ static void do_get_hw_residencies(void * > > switch ( c->x86_model ) > { > - /* Ivy bridge */ > - case 0x3A: > /* Sandy bridge */ > case 0x2A: > case 0x2D: > + /* Ivy bridge */ > + case 0x3A: > + case 0x3E: > + /* Haswell */ > + case 0x3c: > + case 0x45: > GET_PC2_RES(hw_res->pc2); > GET_CC7_RES(hw_res->cc7); > /* fall through */ > --- a/xen/arch/x86/hvm/vmx/vmx.c > +++ b/xen/arch/x86/hvm/vmx/vmx.c > @@ -1746,7 +1746,9 @@ static const struct lbr_info *last_branc > /* Sandy Bridge */ > case 42: case 45: > /* Ivy Bridge */ > - case 58: > + case 58: case 62: > + /* Haswell */ > + case 60: case 69: > return nh_lbr; > break; > /* Atom */ > --- a/xen/arch/x86/hvm/vmx/vpmu_core2.c > +++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c > @@ -747,6 +747,7 @@ int vmx_vpmu_initialise(struct vcpu *v, > case 46: > case 47: > case 58: > + case 62: > ret = core2_vpmu_initialise(v, vpmu_flags); > if ( !ret ) > vpmu->arch_vpmu_ops = &core2_vpmu_ops; > > > Looks good to me. -- Jun Intel Open Source Technology Center _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 15:02:59 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 15:02:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIhW4-0004Pu-Nn; Mon, 01 Oct 2012 15:02:40 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIhW2-0004Pn-RR for xen-devel@lists.xensource.com; Mon, 01 Oct 2012 15:02:39 +0000 Received: from [85.158.139.211:29348] by server-4.bemta-5.messagelabs.com id 34/4A-20767-E80B9605; Mon, 01 Oct 2012 15:02:38 +0000 X-Env-Sender: linux@eikelenboom.it X-Msg-Ref: server-16.tower-206.messagelabs.com!1349103756!20670660!1 X-Originating-IP: [188.40.164.121] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25706 invoked from network); 1 Oct 2012 15:02:36 -0000 Received: from static.121.164.40.188.clients.your-server.de (HELO smtp.eikelenboom.it) (188.40.164.121) by server-16.tower-206.messagelabs.com with AES256-SHA encrypted SMTP; 1 Oct 2012 15:02:36 -0000 Received: from 100-66-ftth.onsneteindhoven.nl ([88.159.66.100]:49525 helo=[172.16.1.20]) by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TIhX1-0004IJ-2M; Mon, 01 Oct 2012 17:03:39 +0200 Date: Mon, 1 Oct 2012 17:02:33 +0200 From: Sander Eikelenboom Organization: Eikelenboom IT services X-Priority: 3 (Normal) Message-ID: <227034703.20121001170233@eikelenboom.it> To: Wei Wang In-Reply-To: <74647167<506050F0.7020703@amd.com> References: <504764E2.4000809@amd.com> <326589347.20120906005936@eikelenboom.it> <5048A603.3070207@amd.com> <483486315.20120906155001@eikelenboom.it> <5048BB29.4040900@amd.com> <488803362.20120907093241@eikelenboom.it> <5049B650.4080101@amd.com> <74647167 <506050F0.7020703@amd.com> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Jan Beulich Subject: Re: [Xen-devel] [PATCH] amd iommu: Dump flags of IO page faults X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Monday, September 24, 2012, 2:24:16 PM, you wrote: > On 09/24/2012 10:38 AM, Sander Eikelenboom wrote: >> >> Friday, September 7, 2012, 10:54:40 AM, you wrote: >> >>> On 09/07/2012 09:32 AM, Sander Eikelenboom wrote: >>>> >>>> Thursday, September 6, 2012, 5:03:05 PM, you wrote: >>>> >>>>> On 09/06/2012 03:50 PM, Sander Eikelenboom wrote: >>>>>> >>>>>> Thursday, September 6, 2012, 3:32:51 PM, you wrote: >>>>>> >>>>>>> On 09/06/2012 12:59 AM, Sander Eikelenboom wrote: >>>>>>>> >>>>>>>> Wednesday, September 5, 2012, 4:42:42 PM, you wrote: >>>>>>>> >>>>>>>>> Hi Jan, >>>>>>>>> Attached patch dumps io page fault flags. The flags show the reason of >>>>>>>>> the fault and tell us if this is an unmapped interrupt fault or a DMA fault. >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Wei >>>>>>>> >>>>>>>>> signed-off-by: Wei Wang >>>>>>>> >>>>>>>> >>>>>>>> I have applied the patch and the flags seem to differ between the faults: >>>>>>>> >>>>>>>> AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000 >>>>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000 >>>>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d339e0, flags = 0x020 >>>>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d33a40, flags = 0x020 >>>>>> >>>>>>> OK, so they are not interrupt requests. I guess further information from >>>>>>> your system would be helpful to debug this issue: >>>>>>> 1) xl info >>>>>>> 2) xl list >>>>>>> 3) lscpi -vvv (NOTE: not in dom0 but in your guest) >>>>>>> 4) cat /proc/iomem (in both dom0 and your hvm guest) >>>>>> >>>>>> dom14 is not a HVM guest,it's a PV guest. >>>> >>>>> Ah, I see. PV guest is quite different than hvm, it does use p2m tables >>>>> as io page tables. So no-sharept option does not work in this case. PV >>>>> guests always use separated io page tables. There might be some >>>>> incorrect mappings on the page tables. I will check this on my side. >>>> >>>> I have reverted the machine to xen-4.1.4-pre (changeset 23353) and kept everything else the same. >>>> I haven't seen any IO PAGE FAULTS after that. >>>> >>>> I did spot some differences in the output from lspci between xen 4.1 and 4.2, related to MSI enabled or not for the IOMMU device. >>>> Have attached the xl/xm dmesg and lspci from booting with both versions. >>>> >>>> lspci: >>>> >>>> 00:00.2 Generic system peripheral [0806]: ATI Technologies Inc RD990 I/O Memory Management Unit (IOMMU) [1002:5a23] >>>> Subsystem: ATI Technologies Inc RD990 I/O Memory Management Unit (IOMMU) [1002:5a23] >>>> Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- >>>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast>TAbort-SERR->>> Latency: 0 >>>> Interrupt: pin A routed to IRQ 10 >>>> Capabilities: [40] Secure device >>>> 4.1: Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit+ >> >>> Eh... That is interesting. So which dom0 are you using? There is a c/s >>> in 4.2 to prevent recent dom0 to disable iommu interrupt (changeset >>> 25492:61844569a432) Otherwise, iommu cannot send any events including IO >>> PAGE faults. You could try to revert dom0 to an old version like 2.6 >>> pv_ops to see if you really have no io page faults on 4.1 >> >> Ok i finally got the time to do some more testing, tested 4.2 around that changeset, and made a copy of the guest using HVM instead of PV. >> >> The results: >> - On xen-4.1.* and a 3.6-rc6 kernel (dom0 and domU): the video device passed through works fine, both in a HVM as a PV guest, i don't see IO page faults getting reported. >> - On xen-4.2 changeset< 25492 and a 3.6-rc6 kernel (dom0 and domU): the video device passed through works fine, both in a HVM as a PV guest, i don't see IO page faults getting reported. >> - On xen-4.2 changeset> 25492 and a 3.6-rc6 kernel (dom0 and domU): the video device passed through works fine for a short while (around 5 to 10 minutes) in a PV guest, after that IO page faults get reported and the video freezes, i don't see any errors in the guest though. >> - On xen-unstable tip and a 3.6-rc6 kernel (dom0 and domU): >> PV: the video device passed through works fine for a short while (around 5 to 10 minutes), after that IO page faults get reported and the video freezes, i don't see any errors in the guest though. >> HVM: the video device passed through doesn't work from the start: >> - The device is there according to lspci >> - The video application start fine, but delivers a green image, so the device is not working properly. I don't see IO page faults though. >> >> Attached are (all with xen-unstable tip and the guest as HVM (domain 15): >> - xl dmesg >> - Patch which adds some more info, but all values reported seem to be zero (see xl dmesg) >> - lspci dom0 >> - lspci HVM guest > HI, > Thanks for the information, very very helpful for debugging. I hope I > could start to look at this right after sending my next iommu patch > queue upstream...another question is: Did you see this issue on a single > pv/hvm guest system or you only saw it on a system with about 16 running > VMs? I have an update on this one... The green screen when using a HVM guest was due to the driver no being able to communicate with the device via I2C. This problem disappeared when updating to the latest xen-unstable and 3.6-rc7 kernel with additionally the linux-next branch from konrad's tree pulled in. At the moment the HVM guest works: it shows video, it doesn't give IO PAGE FAULT's. Will try and see if it's also miraculously fixed for PV as well. > Thanks, > Wei >> >> >> >>>> 4.2: Capabilities: [54] MSI: Enable+ Count=1/1 Maskable- 64bit+ >>>> Address: 00000000fee0100c Data: 4128 >>>> Capabilities: [64] HyperTransport: MSI Mapping Enable+ Fixed+ >>>> >>>> Although it seems enabled, shouldn't the IRQ number used be much higher than 10 for MSI interrupts ? >> >>> The IRQ number is fine. MSI vector is stored at Data: 4128 >> >>>> >>>> There is another difference in the bridge device that's in front of the 0a:00.6 device that faults before the kernel is even booted. >>>> >>>> 00:03.0 PCI bridge [0604]: ATI Technologies Inc RD890 PCI to PCI bridge (PCI express gpp port C) [1002:5a17] (prog-if 00 [Normal decode]) >>>> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ >>>> 4.1: Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast>TAbort-SERR->>> 4.2: Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast>TAbort-SERR->>> Latency: 0, Cache Line Size: 64 bytes >>>> Bus: primary=00, secondary=0a, subordinate=0a, sec-latency=0 >>>> I/O behind bridge: 0000f000-00000fff >>>> Memory behind bridge: f9f00000-f9ffffff >>>> Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff >>>> 4.1: Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast>TAbort->>> 4.2: Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast>TAbort+>>> BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort->Reset- FastB2B- >>>> PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- >>>> Capabilities: [50] Power Management version 3 >>>> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) >>>> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- >>>> Capabilities: [58] Express (v2) Root Port (Slot+), MSI 00 >>>> DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s<64ns, L1<1us >>>> ExtTag+ RBE+ FLReset- >>>> DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- >>>> RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ >>>> MaxPayload 128 bytes, MaxReadReq 128 bytes >>>> DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- >>>> LnkCap: Port #1, Speed 5GT/s, Width x8, ASPM L0s L1, Latency L0<1us, L1<8us >>>> ClockPM- Surprise- LLActRep+ BwNot+ >>>> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk- >>>> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- >>>> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt- >>>> SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise- >>>> Slot #3, PowerLimit 10.000W; Interlock- NoCompl+ >>>> SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg- >>>> Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock- >>>> SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock- >>>> Changed: MRL- PresDet+ LinkState+ >> >>> The probably because of the IO_PAGE_FAULT. >> >>> Thanks, >>> Wei >> >>>> serveerstertje:~# lspci -t >>>> -[0000:00]-+-00.0 >>>> +-00.2 >>>> +-02.0-[0b]----00.0 >>>> +-03.0-[0a]--+-00.0 >>>> | +-00.1 >>>> | +-00.2 >>>> | +-00.3 >>>> | +-00.4 >>>> | +-00.5 >>>> | +-00.6 >>>> | \-00.7 >>>> +-05.0-[09]----00.0 >>>> +-06.0-[08]----00.0 >>>> +-0a.0-[07]----00.0 >>>> +-0b.0-[06]--+-00.0 >>>> | \-00.1 >>>> +-0c.0-[05]----00.0 >>>> +-0d.0-[04]--+-00.0 >>>> | +-00.1 >>>> | +-00.2 >>>> | +-00.3 >>>> | +-00.4 >>>> | +-00.5 >>>> | +-00.6 >>>> | \-00.7 >>>> +-11.0 >>>> +-12.0 >>>> +-12.2 >>>> +-13.0 >>>> +-13.2 >>>> +-14.0 >>>> +-14.3 >>>> +-14.4-[03]----06.0 >>>> +-14.5 >>>> +-15.0-[02]-- >>>> +-16.0 >>>> +-16.2 >>>> +-18.0 >>>> +-18.1 >>>> +-18.2 >>>> +-18.3 >>>> \-18.4 >>>> >>>> >>>> >>>> >>>> >>>>> Thanks, >>>>> Wei >>>> >>>>>> I will try to make a complete package, and try with one pv domain only where the devices are being passed through just to simplify the setup. >>>>>> >>>>>> >>>>>>> * I would also like to know the symptoms of device 0x0700 when IO_PF >>>>>>> happened. Did it stop working? >>>>>> >>>>>> Yes it stops working, the video capture just freezes, but the driver doesn't bail out. >>>>>> For the USB controller (0x0a06) it starts to give errors for usbdev_open in the guest. >>>>>> >>>>>>> (BTW: I copied a few options from your boot cmd line and it worked with >>>>>>> my RD890 system >>>>>> >>>>>>> dom0_mem=1024M,max:1024M loglvl=all loglvl_guest=all console_timestamps >>>>>>> cpuidle cpufreq=xen noreboot debug lapic=debug apic_verbosity=debug >>>>>>> apic=debug iommu=on,verbose,debug,no-sharept >>>>>> >>>>>>> * so, what OEM board you have?) >>>>>> >>>>>> MSI 890FXA-GD70 >>>>>> >>>>>>> Also from your log, these lines looks very strange: >>>>>> >>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to >>>>>>> read-only memory page. gfn=0xd5, mfn=0xa4a11 >>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to >>>>>>> read-only memory page. gfn=0xd7, mfn=0xa4a0f >>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to >>>>>>> read-only memory page. gfn=0xd9, mfn=0xa4a0d >>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to >>>>>>> read-only memory page. gfn=0xdb, mfn=0xa4a0b >>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to >>>>>>> read-only memory page. gfn=0xdd, mfn=0xa4a09 >>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to >>>>>>> read-only memory page. gfn=0xdf, mfn=0xa4a07 >>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to >>>>>>> read-only memory page. gfn=0xe1, mfn=0xa4a05 >>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to >>>>>>> read-only memory page. gfn=0xe3, mfn=0xa4a03 >>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to >>>>>>> read-only memory page. gfn=0xe5, mfn=0xa4a01 >>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to >>>>>>> read-only memory page. gfn=0xe7, mfn=0xa463f >>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to >>>>>>> read-only memory page. gfn=0xe9, mfn=0xa463d >>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to >>>>>>> read-only memory page. gfn=0xeb, mfn=0xa463b >>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to >>>>>>> read-only memory page. gfn=0xed, mfn=0xa4639 >>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to >>>>>>> read-only memory page. gfn=0xef, mfn=0xa4637 >>>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id >>>>>>> = 0x0a06, fault address = 0xc2c2c2c0 >>>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device >>>>>>> id = 0x0700, fault address = 0xa90f8300 >>>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device >>>>>>> id = 0x0700, fault address = 0xa90f8340 >>>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device >>>>>>> id = 0x0700, fault address = 0xa90f8380 >>>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device >>>>>>> id = 0x0700, fault address = 0xa90f83c0 >>>>>> >>>>>>> * they are just followed by the IO PAGE fault. Do you know where are >>>>>>> they from? Your video card driver maybe? >>>>>> >>>>>> From a HVM domain with a old (3.0.3) kernel, but the faults also occur without this domain being started. >>>>>> >>>>>> >>>>>>> Thanks, >>>>>>> Wei >>>>>> >>>>>> >>>>>>>> Complete xl dmesg and lspci -vvvknn attached. >>>>>>>> >>>>>>>> Thx >>>>>>>> >>>>>>>> -- >>>>>>>> Sander >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >> >> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 15:02:59 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 15:02:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIhW4-0004Pu-Nn; Mon, 01 Oct 2012 15:02:40 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIhW2-0004Pn-RR for xen-devel@lists.xensource.com; Mon, 01 Oct 2012 15:02:39 +0000 Received: from [85.158.139.211:29348] by server-4.bemta-5.messagelabs.com id 34/4A-20767-E80B9605; Mon, 01 Oct 2012 15:02:38 +0000 X-Env-Sender: linux@eikelenboom.it X-Msg-Ref: server-16.tower-206.messagelabs.com!1349103756!20670660!1 X-Originating-IP: [188.40.164.121] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25706 invoked from network); 1 Oct 2012 15:02:36 -0000 Received: from static.121.164.40.188.clients.your-server.de (HELO smtp.eikelenboom.it) (188.40.164.121) by server-16.tower-206.messagelabs.com with AES256-SHA encrypted SMTP; 1 Oct 2012 15:02:36 -0000 Received: from 100-66-ftth.onsneteindhoven.nl ([88.159.66.100]:49525 helo=[172.16.1.20]) by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TIhX1-0004IJ-2M; Mon, 01 Oct 2012 17:03:39 +0200 Date: Mon, 1 Oct 2012 17:02:33 +0200 From: Sander Eikelenboom Organization: Eikelenboom IT services X-Priority: 3 (Normal) Message-ID: <227034703.20121001170233@eikelenboom.it> To: Wei Wang In-Reply-To: <74647167<506050F0.7020703@amd.com> References: <504764E2.4000809@amd.com> <326589347.20120906005936@eikelenboom.it> <5048A603.3070207@amd.com> <483486315.20120906155001@eikelenboom.it> <5048BB29.4040900@amd.com> <488803362.20120907093241@eikelenboom.it> <5049B650.4080101@amd.com> <74647167 <506050F0.7020703@amd.com> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Jan Beulich Subject: Re: [Xen-devel] [PATCH] amd iommu: Dump flags of IO page faults X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Monday, September 24, 2012, 2:24:16 PM, you wrote: > On 09/24/2012 10:38 AM, Sander Eikelenboom wrote: >> >> Friday, September 7, 2012, 10:54:40 AM, you wrote: >> >>> On 09/07/2012 09:32 AM, Sander Eikelenboom wrote: >>>> >>>> Thursday, September 6, 2012, 5:03:05 PM, you wrote: >>>> >>>>> On 09/06/2012 03:50 PM, Sander Eikelenboom wrote: >>>>>> >>>>>> Thursday, September 6, 2012, 3:32:51 PM, you wrote: >>>>>> >>>>>>> On 09/06/2012 12:59 AM, Sander Eikelenboom wrote: >>>>>>>> >>>>>>>> Wednesday, September 5, 2012, 4:42:42 PM, you wrote: >>>>>>>> >>>>>>>>> Hi Jan, >>>>>>>>> Attached patch dumps io page fault flags. The flags show the reason of >>>>>>>>> the fault and tell us if this is an unmapped interrupt fault or a DMA fault. >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Wei >>>>>>>> >>>>>>>>> signed-off-by: Wei Wang >>>>>>>> >>>>>>>> >>>>>>>> I have applied the patch and the flags seem to differ between the faults: >>>>>>>> >>>>>>>> AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000 >>>>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000 >>>>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d339e0, flags = 0x020 >>>>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d33a40, flags = 0x020 >>>>>> >>>>>>> OK, so they are not interrupt requests. I guess further information from >>>>>>> your system would be helpful to debug this issue: >>>>>>> 1) xl info >>>>>>> 2) xl list >>>>>>> 3) lscpi -vvv (NOTE: not in dom0 but in your guest) >>>>>>> 4) cat /proc/iomem (in both dom0 and your hvm guest) >>>>>> >>>>>> dom14 is not a HVM guest,it's a PV guest. >>>> >>>>> Ah, I see. PV guest is quite different than hvm, it does use p2m tables >>>>> as io page tables. So no-sharept option does not work in this case. PV >>>>> guests always use separated io page tables. There might be some >>>>> incorrect mappings on the page tables. I will check this on my side. >>>> >>>> I have reverted the machine to xen-4.1.4-pre (changeset 23353) and kept everything else the same. >>>> I haven't seen any IO PAGE FAULTS after that. >>>> >>>> I did spot some differences in the output from lspci between xen 4.1 and 4.2, related to MSI enabled or not for the IOMMU device. >>>> Have attached the xl/xm dmesg and lspci from booting with both versions. >>>> >>>> lspci: >>>> >>>> 00:00.2 Generic system peripheral [0806]: ATI Technologies Inc RD990 I/O Memory Management Unit (IOMMU) [1002:5a23] >>>> Subsystem: ATI Technologies Inc RD990 I/O Memory Management Unit (IOMMU) [1002:5a23] >>>> Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- >>>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast>TAbort-SERR->>> Latency: 0 >>>> Interrupt: pin A routed to IRQ 10 >>>> Capabilities: [40] Secure device >>>> 4.1: Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit+ >> >>> Eh... That is interesting. So which dom0 are you using? There is a c/s >>> in 4.2 to prevent recent dom0 to disable iommu interrupt (changeset >>> 25492:61844569a432) Otherwise, iommu cannot send any events including IO >>> PAGE faults. You could try to revert dom0 to an old version like 2.6 >>> pv_ops to see if you really have no io page faults on 4.1 >> >> Ok i finally got the time to do some more testing, tested 4.2 around that changeset, and made a copy of the guest using HVM instead of PV. >> >> The results: >> - On xen-4.1.* and a 3.6-rc6 kernel (dom0 and domU): the video device passed through works fine, both in a HVM as a PV guest, i don't see IO page faults getting reported. >> - On xen-4.2 changeset< 25492 and a 3.6-rc6 kernel (dom0 and domU): the video device passed through works fine, both in a HVM as a PV guest, i don't see IO page faults getting reported. >> - On xen-4.2 changeset> 25492 and a 3.6-rc6 kernel (dom0 and domU): the video device passed through works fine for a short while (around 5 to 10 minutes) in a PV guest, after that IO page faults get reported and the video freezes, i don't see any errors in the guest though. >> - On xen-unstable tip and a 3.6-rc6 kernel (dom0 and domU): >> PV: the video device passed through works fine for a short while (around 5 to 10 minutes), after that IO page faults get reported and the video freezes, i don't see any errors in the guest though. >> HVM: the video device passed through doesn't work from the start: >> - The device is there according to lspci >> - The video application start fine, but delivers a green image, so the device is not working properly. I don't see IO page faults though. >> >> Attached are (all with xen-unstable tip and the guest as HVM (domain 15): >> - xl dmesg >> - Patch which adds some more info, but all values reported seem to be zero (see xl dmesg) >> - lspci dom0 >> - lspci HVM guest > HI, > Thanks for the information, very very helpful for debugging. I hope I > could start to look at this right after sending my next iommu patch > queue upstream...another question is: Did you see this issue on a single > pv/hvm guest system or you only saw it on a system with about 16 running > VMs? I have an update on this one... The green screen when using a HVM guest was due to the driver no being able to communicate with the device via I2C. This problem disappeared when updating to the latest xen-unstable and 3.6-rc7 kernel with additionally the linux-next branch from konrad's tree pulled in. At the moment the HVM guest works: it shows video, it doesn't give IO PAGE FAULT's. Will try and see if it's also miraculously fixed for PV as well. > Thanks, > Wei >> >> >> >>>> 4.2: Capabilities: [54] MSI: Enable+ Count=1/1 Maskable- 64bit+ >>>> Address: 00000000fee0100c Data: 4128 >>>> Capabilities: [64] HyperTransport: MSI Mapping Enable+ Fixed+ >>>> >>>> Although it seems enabled, shouldn't the IRQ number used be much higher than 10 for MSI interrupts ? >> >>> The IRQ number is fine. MSI vector is stored at Data: 4128 >> >>>> >>>> There is another difference in the bridge device that's in front of the 0a:00.6 device that faults before the kernel is even booted. >>>> >>>> 00:03.0 PCI bridge [0604]: ATI Technologies Inc RD890 PCI to PCI bridge (PCI express gpp port C) [1002:5a17] (prog-if 00 [Normal decode]) >>>> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ >>>> 4.1: Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast>TAbort-SERR->>> 4.2: Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast>TAbort-SERR->>> Latency: 0, Cache Line Size: 64 bytes >>>> Bus: primary=00, secondary=0a, subordinate=0a, sec-latency=0 >>>> I/O behind bridge: 0000f000-00000fff >>>> Memory behind bridge: f9f00000-f9ffffff >>>> Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff >>>> 4.1: Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast>TAbort->>> 4.2: Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast>TAbort+>>> BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort->Reset- FastB2B- >>>> PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- >>>> Capabilities: [50] Power Management version 3 >>>> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) >>>> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- >>>> Capabilities: [58] Express (v2) Root Port (Slot+), MSI 00 >>>> DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s<64ns, L1<1us >>>> ExtTag+ RBE+ FLReset- >>>> DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- >>>> RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ >>>> MaxPayload 128 bytes, MaxReadReq 128 bytes >>>> DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- >>>> LnkCap: Port #1, Speed 5GT/s, Width x8, ASPM L0s L1, Latency L0<1us, L1<8us >>>> ClockPM- Surprise- LLActRep+ BwNot+ >>>> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk- >>>> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- >>>> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt- >>>> SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise- >>>> Slot #3, PowerLimit 10.000W; Interlock- NoCompl+ >>>> SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg- >>>> Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock- >>>> SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock- >>>> Changed: MRL- PresDet+ LinkState+ >> >>> The probably because of the IO_PAGE_FAULT. >> >>> Thanks, >>> Wei >> >>>> serveerstertje:~# lspci -t >>>> -[0000:00]-+-00.0 >>>> +-00.2 >>>> +-02.0-[0b]----00.0 >>>> +-03.0-[0a]--+-00.0 >>>> | +-00.1 >>>> | +-00.2 >>>> | +-00.3 >>>> | +-00.4 >>>> | +-00.5 >>>> | +-00.6 >>>> | \-00.7 >>>> +-05.0-[09]----00.0 >>>> +-06.0-[08]----00.0 >>>> +-0a.0-[07]----00.0 >>>> +-0b.0-[06]--+-00.0 >>>> | \-00.1 >>>> +-0c.0-[05]----00.0 >>>> +-0d.0-[04]--+-00.0 >>>> | +-00.1 >>>> | +-00.2 >>>> | +-00.3 >>>> | +-00.4 >>>> | +-00.5 >>>> | +-00.6 >>>> | \-00.7 >>>> +-11.0 >>>> +-12.0 >>>> +-12.2 >>>> +-13.0 >>>> +-13.2 >>>> +-14.0 >>>> +-14.3 >>>> +-14.4-[03]----06.0 >>>> +-14.5 >>>> +-15.0-[02]-- >>>> +-16.0 >>>> +-16.2 >>>> +-18.0 >>>> +-18.1 >>>> +-18.2 >>>> +-18.3 >>>> \-18.4 >>>> >>>> >>>> >>>> >>>> >>>>> Thanks, >>>>> Wei >>>> >>>>>> I will try to make a complete package, and try with one pv domain only where the devices are being passed through just to simplify the setup. >>>>>> >>>>>> >>>>>>> * I would also like to know the symptoms of device 0x0700 when IO_PF >>>>>>> happened. Did it stop working? >>>>>> >>>>>> Yes it stops working, the video capture just freezes, but the driver doesn't bail out. >>>>>> For the USB controller (0x0a06) it starts to give errors for usbdev_open in the guest. >>>>>> >>>>>>> (BTW: I copied a few options from your boot cmd line and it worked with >>>>>>> my RD890 system >>>>>> >>>>>>> dom0_mem=1024M,max:1024M loglvl=all loglvl_guest=all console_timestamps >>>>>>> cpuidle cpufreq=xen noreboot debug lapic=debug apic_verbosity=debug >>>>>>> apic=debug iommu=on,verbose,debug,no-sharept >>>>>> >>>>>>> * so, what OEM board you have?) >>>>>> >>>>>> MSI 890FXA-GD70 >>>>>> >>>>>>> Also from your log, these lines looks very strange: >>>>>> >>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to >>>>>>> read-only memory page. gfn=0xd5, mfn=0xa4a11 >>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to >>>>>>> read-only memory page. gfn=0xd7, mfn=0xa4a0f >>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to >>>>>>> read-only memory page. gfn=0xd9, mfn=0xa4a0d >>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to >>>>>>> read-only memory page. gfn=0xdb, mfn=0xa4a0b >>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to >>>>>>> read-only memory page. gfn=0xdd, mfn=0xa4a09 >>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to >>>>>>> read-only memory page. gfn=0xdf, mfn=0xa4a07 >>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to >>>>>>> read-only memory page. gfn=0xe1, mfn=0xa4a05 >>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to >>>>>>> read-only memory page. gfn=0xe3, mfn=0xa4a03 >>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to >>>>>>> read-only memory page. gfn=0xe5, mfn=0xa4a01 >>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to >>>>>>> read-only memory page. gfn=0xe7, mfn=0xa463f >>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to >>>>>>> read-only memory page. gfn=0xe9, mfn=0xa463d >>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to >>>>>>> read-only memory page. gfn=0xeb, mfn=0xa463b >>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to >>>>>>> read-only memory page. gfn=0xed, mfn=0xa4639 >>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to >>>>>>> read-only memory page. gfn=0xef, mfn=0xa4637 >>>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id >>>>>>> = 0x0a06, fault address = 0xc2c2c2c0 >>>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device >>>>>>> id = 0x0700, fault address = 0xa90f8300 >>>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device >>>>>>> id = 0x0700, fault address = 0xa90f8340 >>>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device >>>>>>> id = 0x0700, fault address = 0xa90f8380 >>>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device >>>>>>> id = 0x0700, fault address = 0xa90f83c0 >>>>>> >>>>>>> * they are just followed by the IO PAGE fault. Do you know where are >>>>>>> they from? Your video card driver maybe? >>>>>> >>>>>> From a HVM domain with a old (3.0.3) kernel, but the faults also occur without this domain being started. >>>>>> >>>>>> >>>>>>> Thanks, >>>>>>> Wei >>>>>> >>>>>> >>>>>>>> Complete xl dmesg and lspci -vvvknn attached. >>>>>>>> >>>>>>>> Thx >>>>>>>> >>>>>>>> -- >>>>>>>> Sander >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >> >> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 15:11:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 15:11:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIheK-0004dI-V7; Mon, 01 Oct 2012 15:11:12 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIheJ-0004dD-0M for xen-devel@lists.xen.org; Mon, 01 Oct 2012 15:11:11 +0000 Received: from [85.158.137.99:13811] by server-2.bemta-3.messagelabs.com id D8/66-16514-E82B9605; Mon, 01 Oct 2012 15:11:10 +0000 X-Env-Sender: ar16@imapmail.org X-Msg-Ref: server-7.tower-217.messagelabs.com!1349104269!15037955!1 X-Originating-IP: [66.111.4.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTExLjQuMjUgPT4gMjU3NDI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22291 invoked from network); 1 Oct 2012 15:11:09 -0000 Received: from out1-smtp.messagingengine.com (HELO out1-smtp.messagingengine.com) (66.111.4.25) by server-7.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 15:11:09 -0000 Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id B5E99201C1; Mon, 1 Oct 2012 11:11:08 -0400 (EDT) Received: from web1.nyi.mail.srv.osa ([10.202.2.211]) by compute4.internal (MEProxy); Mon, 01 Oct 2012 11:11:08 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=imapmail.org; h= message-id:from:to:mime-version:content-transfer-encoding :content-type:in-reply-to:references:subject:date; s=mesmtp; bh= LLKLI41Hkik1NfblRUF3+WGJZoY=; b=K2hBV5QZrjbv/T0acb7xXKaD60cwIeof GrNWgWN16ZlYluOTACtVnokkVHtH/YiKUgHNU9d7HxGcqv9/DZNAvAnHQy2/kcyk u/Da3jyh76QUxVhTYlUxkl21bU6dwOKVrGFYXGokRzn7KI0vTS98q+e5dQS5Zm/7 dUgAnMJsLXA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=LLKLI41Hkik1NfblRUF3+WGJZoY=; b=C4t fOcj5codQXoqhb65eVd1bmfj7Bdy/gNVh9Xa1Xy3bAfu4QCG1+3/tJDoskvWymSB kaWr5Bvp9ueIJoz6L2iYmZMdbSXdAreNxMVlbxhfz61Pp+OuVaAi5Zt6qvxYoTjp yc5Ws3A6Y9ctKOulQBbUBaU9jURHTi0GA7sIaC2Q= Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99) id 8470BA00375; Mon, 1 Oct 2012 11:11:08 -0400 (EDT) Message-Id: <1349104268.4896.140661134999597.2388DD2A@webmail.messagingengine.com> X-Sasl-Enc: Rk+rNQbLYdSRGPMInFl7XcmWNxA2SQYF5VxeBjhp0bNl 1349104268 From: ar16@imapmail.org To: Olaf Hering , xen-devel@lists.xen.org MIME-Version: 1.0 X-Mailer: MessagingEngine.com Webmail Interface In-Reply-To: <20121001145227.GA27262@aepfle.de> References: <1348877636.5025.140661134113513.411BDE92@webmail.messagingengine.com> <20121001145227.GA27262@aepfle.de> Date: Mon, 01 Oct 2012 08:11:08 -0700 Subject: Re: [Xen-devel] Xen HVM Guest fails (errors) to launch on Opensuse 12.2's Xen 4.2 + 'xl' toolstack X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, Oct 1, 2012, at 07:52 AM, Olaf Hering wrote: > This is caused by an incorrect patch in the xen package, > libxl__build_hvm() returns an error unconditional. That's in the *distro* xen package, then? Over on the Opensuse side? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 15:11:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 15:11:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIheK-0004dI-V7; Mon, 01 Oct 2012 15:11:12 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIheJ-0004dD-0M for xen-devel@lists.xen.org; Mon, 01 Oct 2012 15:11:11 +0000 Received: from [85.158.137.99:13811] by server-2.bemta-3.messagelabs.com id D8/66-16514-E82B9605; Mon, 01 Oct 2012 15:11:10 +0000 X-Env-Sender: ar16@imapmail.org X-Msg-Ref: server-7.tower-217.messagelabs.com!1349104269!15037955!1 X-Originating-IP: [66.111.4.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTExLjQuMjUgPT4gMjU3NDI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22291 invoked from network); 1 Oct 2012 15:11:09 -0000 Received: from out1-smtp.messagingengine.com (HELO out1-smtp.messagingengine.com) (66.111.4.25) by server-7.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 15:11:09 -0000 Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id B5E99201C1; Mon, 1 Oct 2012 11:11:08 -0400 (EDT) Received: from web1.nyi.mail.srv.osa ([10.202.2.211]) by compute4.internal (MEProxy); Mon, 01 Oct 2012 11:11:08 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=imapmail.org; h= message-id:from:to:mime-version:content-transfer-encoding :content-type:in-reply-to:references:subject:date; s=mesmtp; bh= LLKLI41Hkik1NfblRUF3+WGJZoY=; b=K2hBV5QZrjbv/T0acb7xXKaD60cwIeof GrNWgWN16ZlYluOTACtVnokkVHtH/YiKUgHNU9d7HxGcqv9/DZNAvAnHQy2/kcyk u/Da3jyh76QUxVhTYlUxkl21bU6dwOKVrGFYXGokRzn7KI0vTS98q+e5dQS5Zm/7 dUgAnMJsLXA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=LLKLI41Hkik1NfblRUF3+WGJZoY=; b=C4t fOcj5codQXoqhb65eVd1bmfj7Bdy/gNVh9Xa1Xy3bAfu4QCG1+3/tJDoskvWymSB kaWr5Bvp9ueIJoz6L2iYmZMdbSXdAreNxMVlbxhfz61Pp+OuVaAi5Zt6qvxYoTjp yc5Ws3A6Y9ctKOulQBbUBaU9jURHTi0GA7sIaC2Q= Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99) id 8470BA00375; Mon, 1 Oct 2012 11:11:08 -0400 (EDT) Message-Id: <1349104268.4896.140661134999597.2388DD2A@webmail.messagingengine.com> X-Sasl-Enc: Rk+rNQbLYdSRGPMInFl7XcmWNxA2SQYF5VxeBjhp0bNl 1349104268 From: ar16@imapmail.org To: Olaf Hering , xen-devel@lists.xen.org MIME-Version: 1.0 X-Mailer: MessagingEngine.com Webmail Interface In-Reply-To: <20121001145227.GA27262@aepfle.de> References: <1348877636.5025.140661134113513.411BDE92@webmail.messagingengine.com> <20121001145227.GA27262@aepfle.de> Date: Mon, 01 Oct 2012 08:11:08 -0700 Subject: Re: [Xen-devel] Xen HVM Guest fails (errors) to launch on Opensuse 12.2's Xen 4.2 + 'xl' toolstack X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, Oct 1, 2012, at 07:52 AM, Olaf Hering wrote: > This is caused by an incorrect patch in the xen package, > libxl__build_hvm() returns an error unconditional. That's in the *distro* xen package, then? Over on the Opensuse side? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 15:12:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 15:12:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIhfa-0004h0-Dn; Mon, 01 Oct 2012 15:12:30 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIhfZ-0004gr-Hb for xen-devel@lists.xen.org; Mon, 01 Oct 2012 15:12:29 +0000 Received: from [85.158.138.51:46332] by server-2.bemta-3.messagelabs.com id A0/68-16514-CD2B9605; Mon, 01 Oct 2012 15:12:28 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1349104348!30969235!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI1NjQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4251 invoked from network); 1 Oct 2012 15:12:28 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 15:12:28 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="14873802" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 15:12:28 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 16:12:27 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TIhfX-0000nM-Mj; Mon, 01 Oct 2012 15:12:27 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TIhfX-0004oi-It; Mon, 01 Oct 2012 16:12:27 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20585.45787.302130.684768@mariner.uk.xensource.com> Date: Mon, 1 Oct 2012 16:12:27 +0100 To: Paul Durrant Newsgroups: chiark.mail.xen.devel In-Reply-To: <1349084491-13027-2-git-send-email-paul.durrant@citrix.com> References: <1349084491-13027-1-git-send-email-paul.durrant@citrix.com> <1349084491-13027-2-git-send-email-paul.durrant@citrix.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as the register of product numbers. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Paul Durrant writes ("[Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as the register of product numbers."): > +#define PVDRIVERS_PRODUCT_LIST(EACH) \ > + EACH("xensource-windows", 0x0001) /* Citrix */ \ > + EACH("gplpv-windows", 0x0002) /* James Harper */ \ > + EACH("experimental", 0xffff) \ > + EACH(NULL, 0x0000) /* terminator */ When you said a terminator, I thought you meant macro parameters to PVDRIVERS_PRODUCT_LIST which were invoked only between elements. This invocation of EACH is harmful. If the user wants to make an array out of this, they can add it themselves. But if they want to make a switch statement out of it, they can't. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 15:12:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 15:12:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIhfa-0004h0-Dn; Mon, 01 Oct 2012 15:12:30 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIhfZ-0004gr-Hb for xen-devel@lists.xen.org; Mon, 01 Oct 2012 15:12:29 +0000 Received: from [85.158.138.51:46332] by server-2.bemta-3.messagelabs.com id A0/68-16514-CD2B9605; Mon, 01 Oct 2012 15:12:28 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1349104348!30969235!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI1NjQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4251 invoked from network); 1 Oct 2012 15:12:28 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 15:12:28 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="14873802" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 15:12:28 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 16:12:27 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TIhfX-0000nM-Mj; Mon, 01 Oct 2012 15:12:27 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TIhfX-0004oi-It; Mon, 01 Oct 2012 16:12:27 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20585.45787.302130.684768@mariner.uk.xensource.com> Date: Mon, 1 Oct 2012 16:12:27 +0100 To: Paul Durrant Newsgroups: chiark.mail.xen.devel In-Reply-To: <1349084491-13027-2-git-send-email-paul.durrant@citrix.com> References: <1349084491-13027-1-git-send-email-paul.durrant@citrix.com> <1349084491-13027-2-git-send-email-paul.durrant@citrix.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as the register of product numbers. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Paul Durrant writes ("[Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as the register of product numbers."): > +#define PVDRIVERS_PRODUCT_LIST(EACH) \ > + EACH("xensource-windows", 0x0001) /* Citrix */ \ > + EACH("gplpv-windows", 0x0002) /* James Harper */ \ > + EACH("experimental", 0xffff) \ > + EACH(NULL, 0x0000) /* terminator */ When you said a terminator, I thought you meant macro parameters to PVDRIVERS_PRODUCT_LIST which were invoked only between elements. This invocation of EACH is harmful. If the user wants to make an array out of this, they can add it themselves. But if they want to make a switch statement out of it, they can't. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 15:14:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 15:14:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIhhh-0004pX-Uo; Mon, 01 Oct 2012 15:14:41 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIhhg-0004pQ-TC for xen-devel@lists.xen.org; Mon, 01 Oct 2012 15:14:41 +0000 Received: from [85.158.138.51:58944] by server-12.bemta-3.messagelabs.com id 43/A7-23730-063B9605; Mon, 01 Oct 2012 15:14:40 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1349104478!32603342!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI1NjQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17838 invoked from network); 1 Oct 2012 15:14:38 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 15:14:38 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="14873847" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 15:14:22 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 16:14:22 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TIhhO-0000r5-1i; Mon, 01 Oct 2012 15:14:22 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TIhhN-0004p4-Tz; Mon, 01 Oct 2012 16:14:21 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20585.45901.698074.351144@mariner.uk.xensource.com> Date: Mon, 1 Oct 2012 16:14:21 +0100 To: Paul Durrant Newsgroups: chiark.mail.xen.devel In-Reply-To: <1349084633-13186-1-git-send-email-paul.durrant@citrix.com> References: <1349084633-13186-1-git-send-email-paul.durrant@citrix.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH] Use new Xen public header for product numbers and names X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Paul Durrant writes ("[Xen-devel] [PATCH] Use new Xen public header for product numbers and names"): > xen/include/public/hvm/pvdrivers.h has been added as the > register of product numbers used by the blacklisting protocol. > Use the definitions therein rather then locally coded values. ... > +#define PRODUCT(_name, _nr) case _nr: product = _name; break; > switch (product_nr) { > - /* > - * In qemu-xen-unstable, this is the master registry of product > - * numbers. If you need a new product number allocating, please > - * post to xen-devel@lists.xensource.com. You should NOT use > - * an existing product number without allocating one. > - * > - * If you maintain a seaparate versioning and distribution path > - * for PV drivers you should have a separate product number so > - * that your drivers can be separated from others'. > - * > - * During development, you may use the product ID 0xffff to > - * indicate a driver which is yet to be released. > - */ > - case 1: product = "xensource-windows"; break; /* Citrix */ > - case 2: product = "gplpv-windows"; break; /* James Harper */ > - case 0xffff: product = "experimental"; break; > + PVDRIVERS_PRODUCT_LIST(PRODUCT) As a case in point, this generates: case 0: product = NULL; break; and then passes the NULL to asprintf. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 15:14:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 15:14:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIhhh-0004pX-Uo; Mon, 01 Oct 2012 15:14:41 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIhhg-0004pQ-TC for xen-devel@lists.xen.org; Mon, 01 Oct 2012 15:14:41 +0000 Received: from [85.158.138.51:58944] by server-12.bemta-3.messagelabs.com id 43/A7-23730-063B9605; Mon, 01 Oct 2012 15:14:40 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1349104478!32603342!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI1NjQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17838 invoked from network); 1 Oct 2012 15:14:38 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 15:14:38 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="14873847" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 15:14:22 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 16:14:22 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TIhhO-0000r5-1i; Mon, 01 Oct 2012 15:14:22 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TIhhN-0004p4-Tz; Mon, 01 Oct 2012 16:14:21 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20585.45901.698074.351144@mariner.uk.xensource.com> Date: Mon, 1 Oct 2012 16:14:21 +0100 To: Paul Durrant Newsgroups: chiark.mail.xen.devel In-Reply-To: <1349084633-13186-1-git-send-email-paul.durrant@citrix.com> References: <1349084633-13186-1-git-send-email-paul.durrant@citrix.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH] Use new Xen public header for product numbers and names X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Paul Durrant writes ("[Xen-devel] [PATCH] Use new Xen public header for product numbers and names"): > xen/include/public/hvm/pvdrivers.h has been added as the > register of product numbers used by the blacklisting protocol. > Use the definitions therein rather then locally coded values. ... > +#define PRODUCT(_name, _nr) case _nr: product = _name; break; > switch (product_nr) { > - /* > - * In qemu-xen-unstable, this is the master registry of product > - * numbers. If you need a new product number allocating, please > - * post to xen-devel@lists.xensource.com. You should NOT use > - * an existing product number without allocating one. > - * > - * If you maintain a seaparate versioning and distribution path > - * for PV drivers you should have a separate product number so > - * that your drivers can be separated from others'. > - * > - * During development, you may use the product ID 0xffff to > - * indicate a driver which is yet to be released. > - */ > - case 1: product = "xensource-windows"; break; /* Citrix */ > - case 2: product = "gplpv-windows"; break; /* James Harper */ > - case 0xffff: product = "experimental"; break; > + PVDRIVERS_PRODUCT_LIST(PRODUCT) As a case in point, this generates: case 0: product = NULL; break; and then passes the NULL to asprintf. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 15:19:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 15:19:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIhmS-00051w-Ln; Mon, 01 Oct 2012 15:19:36 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIhmR-00051p-GP for xen-devel@lists.xen.org; Mon, 01 Oct 2012 15:19:35 +0000 Received: from [85.158.139.83:8694] by server-6.bemta-5.messagelabs.com id 26/52-14717-684B9605; Mon, 01 Oct 2012 15:19:34 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1349104773!32241821!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI1NjQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10962 invoked from network); 1 Oct 2012 15:19:34 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 15:19:34 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="14873949" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 15:18:52 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 16:18:52 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TIhlj-0000sl-Uk; Mon, 01 Oct 2012 15:18:51 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TIhlj-0004pT-Q0; Mon, 01 Oct 2012 16:18:51 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20585.46171.710160.445825@mariner.uk.xensource.com> Date: Mon, 1 Oct 2012 16:18:51 +0100 To: "Jan Beulich" Newsgroups: chiark.mail.xen.devel In-Reply-To: <5069821D020000780009EB35@nat28.tlf.novell.com> References: <20f6976e28a1ce7e910e.1348894953@kaos-source-31003.sea31.amazon.com> <20120929184916.GB21253@u002268147cd4502c336d.ant.amazon.com> <5069821D020000780009EB35@nat28.tlf.novell.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Keir Fraser , Matt Wilson , xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH] xen/console: introduce a 'w' debug-key that dumps the console ring X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Jan Beulich writes ("Re: [Xen-devel] [PATCH] xen/console: introduce a 'w' debug-key that dumps the console ring"): > On 29.09.12 at 20:49, Matt Wilson wrote: > > It would have been. But what if no one was looking, or dom0 cleared > > the console, or placed it into a scrolling mode that prevents a > > virtual terminal from placing output into a scrollback buffer. With > > this patch, you can connect to a serial console after a machine > > becomes unresponsive and gather clues on what went wrong. > > That's an operator error then. Speaking as someone who does some sysadmin in their spare time, I think this would be a very useful feature. It is often the case that, best intentions notwithstanding, the arrangements for collecting serial output fail. Many serial concentrators and ipkvms are very bad. > I completely agree with Keir that what you propose is pretty > questionable (and you provide one argument against it already - the > shortage of remaining keys). If necessary we can have multi-keystroke keys, surely. We should start with assigning a prefix punctuation character which will give us another 52 letters to play with. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 15:19:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 15:19:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIhmS-00051w-Ln; Mon, 01 Oct 2012 15:19:36 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIhmR-00051p-GP for xen-devel@lists.xen.org; Mon, 01 Oct 2012 15:19:35 +0000 Received: from [85.158.139.83:8694] by server-6.bemta-5.messagelabs.com id 26/52-14717-684B9605; Mon, 01 Oct 2012 15:19:34 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1349104773!32241821!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI1NjQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10962 invoked from network); 1 Oct 2012 15:19:34 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 15:19:34 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="14873949" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 15:18:52 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 16:18:52 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TIhlj-0000sl-Uk; Mon, 01 Oct 2012 15:18:51 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TIhlj-0004pT-Q0; Mon, 01 Oct 2012 16:18:51 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20585.46171.710160.445825@mariner.uk.xensource.com> Date: Mon, 1 Oct 2012 16:18:51 +0100 To: "Jan Beulich" Newsgroups: chiark.mail.xen.devel In-Reply-To: <5069821D020000780009EB35@nat28.tlf.novell.com> References: <20f6976e28a1ce7e910e.1348894953@kaos-source-31003.sea31.amazon.com> <20120929184916.GB21253@u002268147cd4502c336d.ant.amazon.com> <5069821D020000780009EB35@nat28.tlf.novell.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Keir Fraser , Matt Wilson , xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH] xen/console: introduce a 'w' debug-key that dumps the console ring X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Jan Beulich writes ("Re: [Xen-devel] [PATCH] xen/console: introduce a 'w' debug-key that dumps the console ring"): > On 29.09.12 at 20:49, Matt Wilson wrote: > > It would have been. But what if no one was looking, or dom0 cleared > > the console, or placed it into a scrolling mode that prevents a > > virtual terminal from placing output into a scrollback buffer. With > > this patch, you can connect to a serial console after a machine > > becomes unresponsive and gather clues on what went wrong. > > That's an operator error then. Speaking as someone who does some sysadmin in their spare time, I think this would be a very useful feature. It is often the case that, best intentions notwithstanding, the arrangements for collecting serial output fail. Many serial concentrators and ipkvms are very bad. > I completely agree with Keir that what you propose is pretty > questionable (and you provide one argument against it already - the > shortage of remaining keys). If necessary we can have multi-keystroke keys, surely. We should start with assigning a prefix punctuation character which will give us another 52 letters to play with. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 15:22:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 15:22:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIhon-00058J-IY; Mon, 01 Oct 2012 15:22:01 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIhol-00058A-Gc for xen-devel@lists.xen.org; Mon, 01 Oct 2012 15:21:59 +0000 Received: from [85.158.138.51:6385] by server-15.bemta-3.messagelabs.com id 8E/B3-18313-615B9605; Mon, 01 Oct 2012 15:21:58 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-9.tower-174.messagelabs.com!1349104918!30970622!1 X-Originating-IP: [81.169.146.160] X-SpamReason: No, hits=0.3 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MjkxMjY=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MjkxMjY=\n,MAILTO_TO_SPAM_ADDR X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31718 invoked from network); 1 Oct 2012 15:21:58 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160) by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 15:21:58 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGiy0IFwQ= X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-085-064.pools.arcor-ip.net [88.65.85.64]) by smtp.strato.de (jorabe mo11) (RZmta 30.19 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 004540o91ETu05 ; Mon, 1 Oct 2012 17:21:57 +0200 (CEST) Received: by probook.site (Postfix, from userid 1000) id 3E7E71863E; Mon, 1 Oct 2012 17:21:57 +0200 (CEST) Date: Mon, 1 Oct 2012 17:21:57 +0200 From: Olaf Hering To: ar16@imapmail.org Message-ID: <20121001152157.GA31909@aepfle.de> References: <1348877636.5025.140661134113513.411BDE92@webmail.messagingengine.com> <20121001145227.GA27262@aepfle.de> <1349104268.4896.140661134999597.2388DD2A@webmail.messagingengine.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1349104268.4896.140661134999597.2388DD2A@webmail.messagingengine.com> User-Agent: Mutt/1.5.21.rev5555 (2012-07-20) Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen HVM Guest fails (errors) to launch on Opensuse 12.2's Xen 4.2 + 'xl' toolstack X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, Oct 01, ar16@imapmail.org wrote: > > > On Mon, Oct 1, 2012, at 07:52 AM, Olaf Hering wrote: > > This is caused by an incorrect patch in the xen package, > > libxl__build_hvm() returns an error unconditional. > > That's in the *distro* xen package, then? Over on the Opensuse side? Yes, the package update from 4.1 to 4.2 is broken in some areas as you found out. The package will be fixed soon. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 15:22:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 15:22:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIhon-00058J-IY; Mon, 01 Oct 2012 15:22:01 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIhol-00058A-Gc for xen-devel@lists.xen.org; Mon, 01 Oct 2012 15:21:59 +0000 Received: from [85.158.138.51:6385] by server-15.bemta-3.messagelabs.com id 8E/B3-18313-615B9605; Mon, 01 Oct 2012 15:21:58 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-9.tower-174.messagelabs.com!1349104918!30970622!1 X-Originating-IP: [81.169.146.160] X-SpamReason: No, hits=0.3 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MjkxMjY=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MjkxMjY=\n,MAILTO_TO_SPAM_ADDR X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31718 invoked from network); 1 Oct 2012 15:21:58 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160) by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 15:21:58 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGiy0IFwQ= X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-085-064.pools.arcor-ip.net [88.65.85.64]) by smtp.strato.de (jorabe mo11) (RZmta 30.19 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 004540o91ETu05 ; Mon, 1 Oct 2012 17:21:57 +0200 (CEST) Received: by probook.site (Postfix, from userid 1000) id 3E7E71863E; Mon, 1 Oct 2012 17:21:57 +0200 (CEST) Date: Mon, 1 Oct 2012 17:21:57 +0200 From: Olaf Hering To: ar16@imapmail.org Message-ID: <20121001152157.GA31909@aepfle.de> References: <1348877636.5025.140661134113513.411BDE92@webmail.messagingengine.com> <20121001145227.GA27262@aepfle.de> <1349104268.4896.140661134999597.2388DD2A@webmail.messagingengine.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1349104268.4896.140661134999597.2388DD2A@webmail.messagingengine.com> User-Agent: Mutt/1.5.21.rev5555 (2012-07-20) Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen HVM Guest fails (errors) to launch on Opensuse 12.2's Xen 4.2 + 'xl' toolstack X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, Oct 01, ar16@imapmail.org wrote: > > > On Mon, Oct 1, 2012, at 07:52 AM, Olaf Hering wrote: > > This is caused by an incorrect patch in the xen package, > > libxl__build_hvm() returns an error unconditional. > > That's in the *distro* xen package, then? Over on the Opensuse side? Yes, the package update from 4.1 to 4.2 is broken in some areas as you found out. The package will be fixed soon. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 15:24:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 15:24:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIhr5-0005Gn-At; Mon, 01 Oct 2012 15:24:23 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIhr3-0005Gf-W4 for xen-devel@lists.xen.org; Mon, 01 Oct 2012 15:24:22 +0000 Received: from [85.158.138.51:44088] by server-3.bemta-3.messagelabs.com id 72/08-25962-5A5B9605; Mon, 01 Oct 2012 15:24:21 +0000 X-Env-Sender: ar16@imapmail.org X-Msg-Ref: server-2.tower-174.messagelabs.com!1349105059!32604645!1 X-Originating-IP: [66.111.4.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTExLjQuMjUgPT4gMjU3NDI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17093 invoked from network); 1 Oct 2012 15:24:20 -0000 Received: from out1-smtp.messagingengine.com (HELO out1-smtp.messagingengine.com) (66.111.4.25) by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 15:24:20 -0000 Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id AE7BE20619; Mon, 1 Oct 2012 11:24:19 -0400 (EDT) Received: from web1.nyi.mail.srv.osa ([10.202.2.211]) by compute4.internal (MEProxy); Mon, 01 Oct 2012 11:24:19 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=imapmail.org; h= message-id:from:to:cc:mime-version:content-transfer-encoding :content-type:in-reply-to:references:subject:date; s=mesmtp; bh= LDg3psFSj7H2mrJnnrHkfOFu63M=; b=smeAWMHkPAiQnXaSK3vdcdJmInqxBIVJ MRbjzETC8+ahwG1j0pDqXjZNydf3PNbQBU4hcJw21fNUIvuLe9sx+8rzGjfiGtGy QaAn1+lWqkFHuL1eh+G88EqvwhAEvb2CSyMyB1eb+cG79t97sDC26DanqKwIu/X/ gC43m3jJCLE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:cc:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=LDg3psFSj7H2mrJnnrHkfOFu63M=; b=jzf j1pVi4obyh6AN+BPirEOWU/uwqt2GBVNFKIvtURPUSLLhAUYbgk2L52pfzF4Edui gEBY23SIYBaDJ18ouo0opxbqmUXdjMHLeHS37qg5+s+zRloGOKCCfIoZHol5K5CM +XjbOl8bOlXW2A18X4hMTwn9t3AiGW9OB2bJ5wvI= Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99) id 86E8AA00375; Mon, 1 Oct 2012 11:24:19 -0400 (EDT) Message-Id: <1349105059.7922.140661135006253.2F5A2FAF@webmail.messagingengine.com> X-Sasl-Enc: cLe+UTYeKTp6XNQFKbRt3O0w9k/m/rgH9VxaJMjuJosZ 1349105059 From: ar16@imapmail.org To: Olaf Hering MIME-Version: 1.0 X-Mailer: MessagingEngine.com Webmail Interface In-Reply-To: <20121001152157.GA31909@aepfle.de> References: <1348877636.5025.140661134113513.411BDE92@webmail.messagingengine.com> <20121001145227.GA27262@aepfle.de> <1349104268.4896.140661134999597.2388DD2A@webmail.messagingengine.com> <20121001152157.GA31909@aepfle.de> Date: Mon, 01 Oct 2012 08:24:19 -0700 Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen HVM Guest fails (errors) to launch on Opensuse 12.2's Xen 4.2 + 'xl' toolstack X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, Oct 1, 2012, at 08:21 AM, Olaf Hering wrote: > > That's in the *distro* xen package, then? Over on the Opensuse side? > > Yes, the package update from 4.1 to 4.2 is broken in some areas as you > found out. The package will be fixed soon. Thanks. Moving this back to https://bugzilla.novell.com/show_bug.cgi?id=782835 ... _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 15:24:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 15:24:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIhr5-0005Gn-At; Mon, 01 Oct 2012 15:24:23 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIhr3-0005Gf-W4 for xen-devel@lists.xen.org; Mon, 01 Oct 2012 15:24:22 +0000 Received: from [85.158.138.51:44088] by server-3.bemta-3.messagelabs.com id 72/08-25962-5A5B9605; Mon, 01 Oct 2012 15:24:21 +0000 X-Env-Sender: ar16@imapmail.org X-Msg-Ref: server-2.tower-174.messagelabs.com!1349105059!32604645!1 X-Originating-IP: [66.111.4.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTExLjQuMjUgPT4gMjU3NDI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17093 invoked from network); 1 Oct 2012 15:24:20 -0000 Received: from out1-smtp.messagingengine.com (HELO out1-smtp.messagingengine.com) (66.111.4.25) by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 15:24:20 -0000 Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id AE7BE20619; Mon, 1 Oct 2012 11:24:19 -0400 (EDT) Received: from web1.nyi.mail.srv.osa ([10.202.2.211]) by compute4.internal (MEProxy); Mon, 01 Oct 2012 11:24:19 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=imapmail.org; h= message-id:from:to:cc:mime-version:content-transfer-encoding :content-type:in-reply-to:references:subject:date; s=mesmtp; bh= LDg3psFSj7H2mrJnnrHkfOFu63M=; b=smeAWMHkPAiQnXaSK3vdcdJmInqxBIVJ MRbjzETC8+ahwG1j0pDqXjZNydf3PNbQBU4hcJw21fNUIvuLe9sx+8rzGjfiGtGy QaAn1+lWqkFHuL1eh+G88EqvwhAEvb2CSyMyB1eb+cG79t97sDC26DanqKwIu/X/ gC43m3jJCLE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:cc:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=LDg3psFSj7H2mrJnnrHkfOFu63M=; b=jzf j1pVi4obyh6AN+BPirEOWU/uwqt2GBVNFKIvtURPUSLLhAUYbgk2L52pfzF4Edui gEBY23SIYBaDJ18ouo0opxbqmUXdjMHLeHS37qg5+s+zRloGOKCCfIoZHol5K5CM +XjbOl8bOlXW2A18X4hMTwn9t3AiGW9OB2bJ5wvI= Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99) id 86E8AA00375; Mon, 1 Oct 2012 11:24:19 -0400 (EDT) Message-Id: <1349105059.7922.140661135006253.2F5A2FAF@webmail.messagingengine.com> X-Sasl-Enc: cLe+UTYeKTp6XNQFKbRt3O0w9k/m/rgH9VxaJMjuJosZ 1349105059 From: ar16@imapmail.org To: Olaf Hering MIME-Version: 1.0 X-Mailer: MessagingEngine.com Webmail Interface In-Reply-To: <20121001152157.GA31909@aepfle.de> References: <1348877636.5025.140661134113513.411BDE92@webmail.messagingengine.com> <20121001145227.GA27262@aepfle.de> <1349104268.4896.140661134999597.2388DD2A@webmail.messagingengine.com> <20121001152157.GA31909@aepfle.de> Date: Mon, 01 Oct 2012 08:24:19 -0700 Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen HVM Guest fails (errors) to launch on Opensuse 12.2's Xen 4.2 + 'xl' toolstack X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, Oct 1, 2012, at 08:21 AM, Olaf Hering wrote: > > That's in the *distro* xen package, then? Over on the Opensuse side? > > Yes, the package update from 4.1 to 4.2 is broken in some areas as you > found out. The package will be fixed soon. Thanks. Moving this back to https://bugzilla.novell.com/show_bug.cgi?id=782835 ... _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 15:31:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 15:31:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIhxS-0005U3-9W; Mon, 01 Oct 2012 15:30:58 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIhxQ-0005Ty-J0 for xen-devel@lists.xen.org; Mon, 01 Oct 2012 15:30:56 +0000 Received: from [85.158.143.99:37234] by server-3.bemta-4.messagelabs.com id 46/67-10986-F27B9605; Mon, 01 Oct 2012 15:30:55 +0000 X-Env-Sender: lmingcsce@gmail.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1349105454!26003685!1 X-Originating-IP: [209.85.161.173] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11166 invoked from network); 1 Oct 2012 15:30:55 -0000 Received: from mail-gg0-f173.google.com (HELO mail-gg0-f173.google.com) (209.85.161.173) by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 15:30:55 -0000 Received: by ggcs5 with SMTP id s5so32298ggc.32 for ; Mon, 01 Oct 2012 08:30:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=4aWFQX/dHi2khZLYfcI1bVVizyVmSipp5mZCKoy6Oto=; b=Gb0WKJzdum9qI1SMaF2s3+4rxtSrRFgNy81+KsMQwZS3eOnHY/QtIkDpTFWil6xzb/ Bj0f39my5+M2bgSVwt1mONr1EXBCs6MQy/eioo2Esy59hjkAzS+VMMs7Z1kAlUzPRXay HHxOO+JTaUQwhjlCvy1mwUoMBiqNB9EwdNR2kD8/GgzPXR24qu0Xx0Acff5GBLR44TlK hHtvHOfGP99gI7TnCV42DtUJO8hGzU014+ZeUephTU98VdGbnWs4bGvYRivq4ALu2CoW H6xXXGgULPlsG4yr4A8nmOLwq6An1VRsc82yRNuwj1//mO18QA0/uyZXmzzRT4UFd9MH 78UA== Received: by 10.236.124.44 with SMTP id w32mr15310429yhh.76.1349105453645; Mon, 01 Oct 2012 08:30:53 -0700 (PDT) Received: from [10.136.49.71] (n128-227-139-244.xlate.ufl.edu. [128.227.139.244]) by mx.google.com with ESMTPS id z30sm2574643yhh.6.2012.10.01.08.30.52 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 01 Oct 2012 08:30:52 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) From: lmingcsce In-Reply-To: Date: Mon, 1 Oct 2012 11:30:47 -0400 Message-Id: <75A1D5EB-12C7-4829-A3F7-4D77B2405FBB@gmail.com> References: To: =?iso-8859-1?Q?Jos=E9_Eduardo_Fran=E7a?= X-Mailer: Apple Mail (2.1283) Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] How to get the checkpoint size in remus code? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0540494438442533295==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============0540494438442533295== Content-Type: multipart/alternative; boundary="Apple-Mail=_2BE59EAC-4074-4C6A-8597-31A61489D77E" --Apple-Mail=_2BE59EAC-4074-4C6A-8597-31A61489D77E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Remus takes advantage of the last iteration of live migration to get = dirty memory and transfer to the backup machine. So you can get the = dirty memory size from live migration's dirty bitmap.=20 On Oct 1, 2012, at 10:48 AM, Jos=E9 Eduardo Fran=E7a wrote: > Hi, >=20 > I'm doing my master research and I need to adapt remus code. Now... I = wanna get the checkpoint size (memory + disk) on each period. Does = someone know what function does this? I think some fd object's function = in remus code could just get the memory size. >=20 > Does someone help me? >=20 > Thanks > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel --Apple-Mail=_2BE59EAC-4074-4C6A-8597-31A61489D77E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Remus = takes advantage of the last iteration of live migration to get dirty = memory and transfer to the backup machine. So you can get the dirty = memory size from live migration's dirty = bitmap. 

On Oct 1, 2012, at 10:48 AM, Jos=E9 = Eduardo Fran=E7a wrote:

Hi,

I'm doing my master research and I need to = adapt remus code. Now... I wanna get the checkpoint size (memory + disk) = on each period. Does someone know what function does this? I think some = fd object's function in remus code could just get the memory = size.

Does someone help me?

Thanks
_______________________________________________
Xen-devel mailing = list
Xen-devel@lists.xen.org
htt= p://lists.xen.org/xen-devel

= --Apple-Mail=_2BE59EAC-4074-4C6A-8597-31A61489D77E-- --===============0540494438442533295== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============0540494438442533295==-- From xen-devel-bounces@lists.xen.org Mon Oct 01 15:31:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 15:31:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIhxS-0005U3-9W; Mon, 01 Oct 2012 15:30:58 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIhxQ-0005Ty-J0 for xen-devel@lists.xen.org; Mon, 01 Oct 2012 15:30:56 +0000 Received: from [85.158.143.99:37234] by server-3.bemta-4.messagelabs.com id 46/67-10986-F27B9605; Mon, 01 Oct 2012 15:30:55 +0000 X-Env-Sender: lmingcsce@gmail.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1349105454!26003685!1 X-Originating-IP: [209.85.161.173] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11166 invoked from network); 1 Oct 2012 15:30:55 -0000 Received: from mail-gg0-f173.google.com (HELO mail-gg0-f173.google.com) (209.85.161.173) by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 15:30:55 -0000 Received: by ggcs5 with SMTP id s5so32298ggc.32 for ; Mon, 01 Oct 2012 08:30:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=4aWFQX/dHi2khZLYfcI1bVVizyVmSipp5mZCKoy6Oto=; b=Gb0WKJzdum9qI1SMaF2s3+4rxtSrRFgNy81+KsMQwZS3eOnHY/QtIkDpTFWil6xzb/ Bj0f39my5+M2bgSVwt1mONr1EXBCs6MQy/eioo2Esy59hjkAzS+VMMs7Z1kAlUzPRXay HHxOO+JTaUQwhjlCvy1mwUoMBiqNB9EwdNR2kD8/GgzPXR24qu0Xx0Acff5GBLR44TlK hHtvHOfGP99gI7TnCV42DtUJO8hGzU014+ZeUephTU98VdGbnWs4bGvYRivq4ALu2CoW H6xXXGgULPlsG4yr4A8nmOLwq6An1VRsc82yRNuwj1//mO18QA0/uyZXmzzRT4UFd9MH 78UA== Received: by 10.236.124.44 with SMTP id w32mr15310429yhh.76.1349105453645; Mon, 01 Oct 2012 08:30:53 -0700 (PDT) Received: from [10.136.49.71] (n128-227-139-244.xlate.ufl.edu. [128.227.139.244]) by mx.google.com with ESMTPS id z30sm2574643yhh.6.2012.10.01.08.30.52 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 01 Oct 2012 08:30:52 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) From: lmingcsce In-Reply-To: Date: Mon, 1 Oct 2012 11:30:47 -0400 Message-Id: <75A1D5EB-12C7-4829-A3F7-4D77B2405FBB@gmail.com> References: To: =?iso-8859-1?Q?Jos=E9_Eduardo_Fran=E7a?= X-Mailer: Apple Mail (2.1283) Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] How to get the checkpoint size in remus code? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0540494438442533295==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============0540494438442533295== Content-Type: multipart/alternative; boundary="Apple-Mail=_2BE59EAC-4074-4C6A-8597-31A61489D77E" --Apple-Mail=_2BE59EAC-4074-4C6A-8597-31A61489D77E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Remus takes advantage of the last iteration of live migration to get = dirty memory and transfer to the backup machine. So you can get the = dirty memory size from live migration's dirty bitmap.=20 On Oct 1, 2012, at 10:48 AM, Jos=E9 Eduardo Fran=E7a wrote: > Hi, >=20 > I'm doing my master research and I need to adapt remus code. Now... I = wanna get the checkpoint size (memory + disk) on each period. Does = someone know what function does this? I think some fd object's function = in remus code could just get the memory size. >=20 > Does someone help me? >=20 > Thanks > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel --Apple-Mail=_2BE59EAC-4074-4C6A-8597-31A61489D77E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Remus = takes advantage of the last iteration of live migration to get dirty = memory and transfer to the backup machine. So you can get the dirty = memory size from live migration's dirty = bitmap. 

On Oct 1, 2012, at 10:48 AM, Jos=E9 = Eduardo Fran=E7a wrote:

Hi,

I'm doing my master research and I need to = adapt remus code. Now... I wanna get the checkpoint size (memory + disk) = on each period. Does someone know what function does this? I think some = fd object's function in remus code could just get the memory = size.

Does someone help me?

Thanks
_______________________________________________
Xen-devel mailing = list
Xen-devel@lists.xen.org
htt= p://lists.xen.org/xen-devel

= --Apple-Mail=_2BE59EAC-4074-4C6A-8597-31A61489D77E-- --===============0540494438442533295== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============0540494438442533295==-- From xen-devel-bounces@lists.xen.org Mon Oct 01 15:51:14 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 15:51:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIiGl-0005gF-5h; Mon, 01 Oct 2012 15:50:55 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIiGj-0005gA-Pr for xen-devel@lists.xen.org; Mon, 01 Oct 2012 15:50:54 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1349106641!11077521!1 X-Originating-IP: [209.85.215.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28602 invoked from network); 1 Oct 2012 15:50:41 -0000 Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com) (209.85.215.173) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 15:50:41 -0000 Received: by eaaa1 with SMTP id a1so1936119eaa.32 for ; Mon, 01 Oct 2012 08:50:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=CkyX63282hSu8E9kSYr3kCKShxKzuGhMOcrm0OLVTCs=; b=ads0K+ANAdmQT5urvFjIZiUti6vew4cOoR8h7rJrzadnux+pinEw60GI0cY6eQNGMy uI1c1ELrl4oKx90vX3s1ANUgHIlbnQK5m2jxa7ifS07w27A0DNA5/H5yplh5SWUadV4k 38K/4uMMncsqujXVgdcTvgkD/ezk6MH8RB9DYJ+tF0TAEkJWHJX6TvX+dBv/SGH2FiX6 +Szfzj3Kj9Im9cI3gELAtWYUmQuTCzd+r3eJ3xS95qWMYnxQ7KuRMC8OCTfNxN6N/D/1 lFtPcwCZpn/Mb5QqY40pwN/VZZp6bNWzH3HxQRB3oPLvlQxjKYz91ZRY0ZGHPmK2lvqW /B7Q== Received: by 10.14.207.9 with SMTP id m9mr18575230eeo.5.1349106641158; Mon, 01 Oct 2012 08:50:41 -0700 (PDT) Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com. [86.183.156.141]) by mx.google.com with ESMTPS id i1sm15465143eeo.8.2012.10.01.08.50.38 (version=SSLv3 cipher=OTHER); Mon, 01 Oct 2012 08:50:40 -0700 (PDT) User-Agent: Microsoft-Entourage/12.34.0.120813 Date: Mon, 01 Oct 2012 16:50:31 +0100 From: Keir Fraser To: Ian Jackson , Jan Beulich Message-ID: Thread-Topic: [Xen-devel] [PATCH] xen/console: introduce a 'w' debug-key that dumps the console ring Thread-Index: Ac2f7HxKeaFQ8guH5k+BeWgRVg3xUA== In-Reply-To: <20585.46171.710160.445825@mariner.uk.xensource.com> Mime-version: 1.0 Cc: Matt Wilson , xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH] xen/console: introduce a 'w' debug-key that dumps the console ring X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 01/10/2012 16:18, "Ian Jackson" wrote: > Jan Beulich writes ("Re: [Xen-devel] [PATCH] xen/console: introduce a 'w' > debug-key that dumps the console ring"): >> On 29.09.12 at 20:49, Matt Wilson wrote: >>> It would have been. But what if no one was looking, or dom0 cleared >>> the console, or placed it into a scrolling mode that prevents a >>> virtual terminal from placing output into a scrollback buffer. With >>> this patch, you can connect to a serial console after a machine >>> becomes unresponsive and gather clues on what went wrong. >> >> That's an operator error then. > > Speaking as someone who does some sysadmin in their spare time, I > think this would be a very useful feature. It is often the case that, > best intentions notwithstanding, the arrangements for collecting > serial output fail. Many serial concentrators and ipkvms are very > bad. Yes, I must say that I found Matt's explanation quite compelling too. Clearly a large user of Xen is finding it useful, or it would not have been proposed. ;) So I will probably take the patch, and indeed running out of keys is a poor reason for rejecting, as we can switch to two letter combos or a really simple shell for extended commands. -- Keir >> I completely agree with Keir that what you propose is pretty >> questionable (and you provide one argument against it already - the >> shortage of remaining keys). > > If necessary we can have multi-keystroke keys, surely. We should > start with assigning a prefix punctuation character which will give us > another 52 letters to play with. > > Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 15:51:14 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 15:51:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIiGl-0005gF-5h; Mon, 01 Oct 2012 15:50:55 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIiGj-0005gA-Pr for xen-devel@lists.xen.org; Mon, 01 Oct 2012 15:50:54 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1349106641!11077521!1 X-Originating-IP: [209.85.215.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28602 invoked from network); 1 Oct 2012 15:50:41 -0000 Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com) (209.85.215.173) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 15:50:41 -0000 Received: by eaaa1 with SMTP id a1so1936119eaa.32 for ; Mon, 01 Oct 2012 08:50:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=CkyX63282hSu8E9kSYr3kCKShxKzuGhMOcrm0OLVTCs=; b=ads0K+ANAdmQT5urvFjIZiUti6vew4cOoR8h7rJrzadnux+pinEw60GI0cY6eQNGMy uI1c1ELrl4oKx90vX3s1ANUgHIlbnQK5m2jxa7ifS07w27A0DNA5/H5yplh5SWUadV4k 38K/4uMMncsqujXVgdcTvgkD/ezk6MH8RB9DYJ+tF0TAEkJWHJX6TvX+dBv/SGH2FiX6 +Szfzj3Kj9Im9cI3gELAtWYUmQuTCzd+r3eJ3xS95qWMYnxQ7KuRMC8OCTfNxN6N/D/1 lFtPcwCZpn/Mb5QqY40pwN/VZZp6bNWzH3HxQRB3oPLvlQxjKYz91ZRY0ZGHPmK2lvqW /B7Q== Received: by 10.14.207.9 with SMTP id m9mr18575230eeo.5.1349106641158; Mon, 01 Oct 2012 08:50:41 -0700 (PDT) Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com. [86.183.156.141]) by mx.google.com with ESMTPS id i1sm15465143eeo.8.2012.10.01.08.50.38 (version=SSLv3 cipher=OTHER); Mon, 01 Oct 2012 08:50:40 -0700 (PDT) User-Agent: Microsoft-Entourage/12.34.0.120813 Date: Mon, 01 Oct 2012 16:50:31 +0100 From: Keir Fraser To: Ian Jackson , Jan Beulich Message-ID: Thread-Topic: [Xen-devel] [PATCH] xen/console: introduce a 'w' debug-key that dumps the console ring Thread-Index: Ac2f7HxKeaFQ8guH5k+BeWgRVg3xUA== In-Reply-To: <20585.46171.710160.445825@mariner.uk.xensource.com> Mime-version: 1.0 Cc: Matt Wilson , xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH] xen/console: introduce a 'w' debug-key that dumps the console ring X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 01/10/2012 16:18, "Ian Jackson" wrote: > Jan Beulich writes ("Re: [Xen-devel] [PATCH] xen/console: introduce a 'w' > debug-key that dumps the console ring"): >> On 29.09.12 at 20:49, Matt Wilson wrote: >>> It would have been. But what if no one was looking, or dom0 cleared >>> the console, or placed it into a scrolling mode that prevents a >>> virtual terminal from placing output into a scrollback buffer. With >>> this patch, you can connect to a serial console after a machine >>> becomes unresponsive and gather clues on what went wrong. >> >> That's an operator error then. > > Speaking as someone who does some sysadmin in their spare time, I > think this would be a very useful feature. It is often the case that, > best intentions notwithstanding, the arrangements for collecting > serial output fail. Many serial concentrators and ipkvms are very > bad. Yes, I must say that I found Matt's explanation quite compelling too. Clearly a large user of Xen is finding it useful, or it would not have been proposed. ;) So I will probably take the patch, and indeed running out of keys is a poor reason for rejecting, as we can switch to two letter combos or a really simple shell for extended commands. -- Keir >> I completely agree with Keir that what you propose is pretty >> questionable (and you provide one argument against it already - the >> shortage of remaining keys). > > If necessary we can have multi-keystroke keys, surely. We should > start with assigning a prefix punctuation character which will give us > another 52 letters to play with. > > Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 16:08:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 16:08:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIiXm-0006WP-O3; Mon, 01 Oct 2012 16:08:30 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIiXl-0006WE-7n for xen-devel@lists.xen.org; Mon, 01 Oct 2012 16:08:29 +0000 Received: from [85.158.139.83:41757] by server-1.bemta-5.messagelabs.com id F4/DF-09825-CFFB9605; Mon, 01 Oct 2012 16:08:28 +0000 X-Env-Sender: Paul.Durrant@citrix.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1349107707!28957668!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI1NjQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22162 invoked from network); 1 Oct 2012 16:08:28 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 16:08:28 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="14875102" Received: from lonpmailmx02.citrite.net ([10.30.203.163]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 16:08:27 +0000 Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Mon, 1 Oct 2012 17:08:28 +0100 From: Paul Durrant To: Ian Jackson Date: Mon, 1 Oct 2012 17:08:30 +0100 Thread-Topic: [Xen-devel] [PATCH] Use new Xen public header for product numbers and names Thread-Index: Ac2f52/fKmX2HSSORcasjF5vW9AbUgABxsyQ Message-ID: <291EDFCB1E9E224A99088639C4762022FDDCAB6EB5@LONPMAILBOX01.citrite.net> References: <1349084633-13186-1-git-send-email-paul.durrant@citrix.com> <20585.45901.698074.351144@mariner.uk.xensource.com> In-Reply-To: <20585.45901.698074.351144@mariner.uk.xensource.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] Use new Xen public header for product numbers and names X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > -----Original Message----- > From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com] > Sent: 01 October 2012 16:14 > To: Paul Durrant > Cc: xen-devel@lists.xen.org > Subject: Re: [Xen-devel] [PATCH] Use new Xen public header for product > numbers and names > > Paul Durrant writes ("[Xen-devel] [PATCH] Use new Xen public header for > product numbers and names"): > > xen/include/public/hvm/pvdrivers.h has been added as the register of > > product numbers used by the blacklisting protocol. > > Use the definitions therein rather then locally coded values. > ... > > +#define PRODUCT(_name, _nr) case _nr: product = _name; break; > > switch (product_nr) { > > - /* > > - * In qemu-xen-unstable, this is the master registry of product > > - * numbers. If you need a new product number allocating, please > > - * post to xen-devel@lists.xensource.com. You should NOT use > > - * an existing product number without allocating one. > > - * > > - * If you maintain a seaparate versioning and distribution path > > - * for PV drivers you should have a separate product number so > > - * that your drivers can be separated from others'. > > - * > > - * During development, you may use the product ID 0xffff to > > - * indicate a driver which is yet to be released. > > - */ > > - case 1: product = "xensource-windows"; break; /* Citrix */ > > - case 2: product = "gplpv-windows"; break; /* James Harper */ > > - case 0xffff: product = "experimental"; break; > > + PVDRIVERS_PRODUCT_LIST(PRODUCT) > > As a case in point, this generates: > case 0: product = NULL; break; > and then passes the NULL to asprintf. > Nothing should be using product number 0, so is this a problem? Paul _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 16:08:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 16:08:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIiXm-0006WP-O3; Mon, 01 Oct 2012 16:08:30 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIiXl-0006WE-7n for xen-devel@lists.xen.org; Mon, 01 Oct 2012 16:08:29 +0000 Received: from [85.158.139.83:41757] by server-1.bemta-5.messagelabs.com id F4/DF-09825-CFFB9605; Mon, 01 Oct 2012 16:08:28 +0000 X-Env-Sender: Paul.Durrant@citrix.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1349107707!28957668!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI1NjQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22162 invoked from network); 1 Oct 2012 16:08:28 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 16:08:28 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="14875102" Received: from lonpmailmx02.citrite.net ([10.30.203.163]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 16:08:27 +0000 Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Mon, 1 Oct 2012 17:08:28 +0100 From: Paul Durrant To: Ian Jackson Date: Mon, 1 Oct 2012 17:08:30 +0100 Thread-Topic: [Xen-devel] [PATCH] Use new Xen public header for product numbers and names Thread-Index: Ac2f52/fKmX2HSSORcasjF5vW9AbUgABxsyQ Message-ID: <291EDFCB1E9E224A99088639C4762022FDDCAB6EB5@LONPMAILBOX01.citrite.net> References: <1349084633-13186-1-git-send-email-paul.durrant@citrix.com> <20585.45901.698074.351144@mariner.uk.xensource.com> In-Reply-To: <20585.45901.698074.351144@mariner.uk.xensource.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] Use new Xen public header for product numbers and names X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > -----Original Message----- > From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com] > Sent: 01 October 2012 16:14 > To: Paul Durrant > Cc: xen-devel@lists.xen.org > Subject: Re: [Xen-devel] [PATCH] Use new Xen public header for product > numbers and names > > Paul Durrant writes ("[Xen-devel] [PATCH] Use new Xen public header for > product numbers and names"): > > xen/include/public/hvm/pvdrivers.h has been added as the register of > > product numbers used by the blacklisting protocol. > > Use the definitions therein rather then locally coded values. > ... > > +#define PRODUCT(_name, _nr) case _nr: product = _name; break; > > switch (product_nr) { > > - /* > > - * In qemu-xen-unstable, this is the master registry of product > > - * numbers. If you need a new product number allocating, please > > - * post to xen-devel@lists.xensource.com. You should NOT use > > - * an existing product number without allocating one. > > - * > > - * If you maintain a seaparate versioning and distribution path > > - * for PV drivers you should have a separate product number so > > - * that your drivers can be separated from others'. > > - * > > - * During development, you may use the product ID 0xffff to > > - * indicate a driver which is yet to be released. > > - */ > > - case 1: product = "xensource-windows"; break; /* Citrix */ > > - case 2: product = "gplpv-windows"; break; /* James Harper */ > > - case 0xffff: product = "experimental"; break; > > + PVDRIVERS_PRODUCT_LIST(PRODUCT) > > As a case in point, this generates: > case 0: product = NULL; break; > and then passes the NULL to asprintf. > Nothing should be using product number 0, so is this a problem? Paul _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 16:18:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 16:18:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIigp-0006uD-Cy; Mon, 01 Oct 2012 16:17:51 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIign-0006tx-MK for xen-devel@lists.xen.org; Mon, 01 Oct 2012 16:17:49 +0000 Received: from [85.158.139.83:37283] by server-8.bemta-5.messagelabs.com id A5/84-18073-C22C9605; Mon, 01 Oct 2012 16:17:48 +0000 X-Env-Sender: Paul.Durrant@citrix.com X-Msg-Ref: server-16.tower-182.messagelabs.com!1349108268!25575074!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI1NjQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15654 invoked from network); 1 Oct 2012 16:17:48 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 16:17:48 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="14875292" Received: from lonpmailmx02.citrite.net ([10.30.203.163]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 16:17:48 +0000 Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Mon, 1 Oct 2012 17:17:48 +0100 From: Paul Durrant To: Ian Jackson Date: Mon, 1 Oct 2012 17:17:51 +0100 Thread-Topic: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as the register of product numbers. Thread-Index: Ac2f5yurfAGbDhUlR4Kk6vvaxrZeUQAB+yPw Message-ID: <291EDFCB1E9E224A99088639C4762022FDDCAB6EB9@LONPMAILBOX01.citrite.net> References: <1349084491-13027-1-git-send-email-paul.durrant@citrix.com> <1349084491-13027-2-git-send-email-paul.durrant@citrix.com> <20585.45787.302130.684768@mariner.uk.xensource.com> In-Reply-To: <20585.45787.302130.684768@mariner.uk.xensource.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as the register of product numbers. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > -----Original Message----- > From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com] > Sent: 01 October 2012 16:12 > To: Paul Durrant > Cc: xen-devel@lists.xen.org > Subject: Re: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve > as the register of product numbers. > > Paul Durrant writes ("[Xen-devel] [PATCH 1/2] Add a new pvdrivers header > to serve as the register of product numbers."): > > > +#define PVDRIVERS_PRODUCT_LIST(EACH) \ > > + EACH("xensource-windows", 0x0001) /* Citrix */ \ > > + EACH("gplpv-windows", 0x0002) /* James Harper */ \ > > + EACH("experimental", 0xffff) \ > > + EACH(NULL, 0x0000) /* terminator */ > > When you said a terminator, I thought you meant macro parameters to > PVDRIVERS_PRODUCT_LIST which were invoked only between elements. > > This invocation of EACH is harmful. If the user wants to make an array out of > this, they can add it themselves. But if they want to make a switch > statement out of it, they can't. > Ok. I thought it was helpful to reserve product number 0 for this purpose, but I'll ditch it. Paul _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 16:18:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 16:18:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIigp-0006uD-Cy; Mon, 01 Oct 2012 16:17:51 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIign-0006tx-MK for xen-devel@lists.xen.org; Mon, 01 Oct 2012 16:17:49 +0000 Received: from [85.158.139.83:37283] by server-8.bemta-5.messagelabs.com id A5/84-18073-C22C9605; Mon, 01 Oct 2012 16:17:48 +0000 X-Env-Sender: Paul.Durrant@citrix.com X-Msg-Ref: server-16.tower-182.messagelabs.com!1349108268!25575074!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI1NjQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15654 invoked from network); 1 Oct 2012 16:17:48 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 16:17:48 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="14875292" Received: from lonpmailmx02.citrite.net ([10.30.203.163]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 16:17:48 +0000 Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Mon, 1 Oct 2012 17:17:48 +0100 From: Paul Durrant To: Ian Jackson Date: Mon, 1 Oct 2012 17:17:51 +0100 Thread-Topic: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as the register of product numbers. Thread-Index: Ac2f5yurfAGbDhUlR4Kk6vvaxrZeUQAB+yPw Message-ID: <291EDFCB1E9E224A99088639C4762022FDDCAB6EB9@LONPMAILBOX01.citrite.net> References: <1349084491-13027-1-git-send-email-paul.durrant@citrix.com> <1349084491-13027-2-git-send-email-paul.durrant@citrix.com> <20585.45787.302130.684768@mariner.uk.xensource.com> In-Reply-To: <20585.45787.302130.684768@mariner.uk.xensource.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as the register of product numbers. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > -----Original Message----- > From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com] > Sent: 01 October 2012 16:12 > To: Paul Durrant > Cc: xen-devel@lists.xen.org > Subject: Re: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve > as the register of product numbers. > > Paul Durrant writes ("[Xen-devel] [PATCH 1/2] Add a new pvdrivers header > to serve as the register of product numbers."): > > > +#define PVDRIVERS_PRODUCT_LIST(EACH) \ > > + EACH("xensource-windows", 0x0001) /* Citrix */ \ > > + EACH("gplpv-windows", 0x0002) /* James Harper */ \ > > + EACH("experimental", 0xffff) \ > > + EACH(NULL, 0x0000) /* terminator */ > > When you said a terminator, I thought you meant macro parameters to > PVDRIVERS_PRODUCT_LIST which were invoked only between elements. > > This invocation of EACH is harmful. If the user wants to make an array out of > this, they can add it themselves. But if they want to make a switch > statement out of it, they can't. > Ok. I thought it was helpful to reserve product number 0 for this purpose, but I'll ditch it. Paul _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 16:26:05 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 16:26:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIioV-0007DB-AY; Mon, 01 Oct 2012 16:25:47 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIioT-0007D4-MD for xen-devel@lists.xen.org; Mon, 01 Oct 2012 16:25:46 +0000 Received: from [85.158.137.99:23268] by server-1.bemta-3.messagelabs.com id 7E/8C-16425-804C9605; Mon, 01 Oct 2012 16:25:44 +0000 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-6.tower-217.messagelabs.com!1349108743!14703178!1 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19517 invoked from network); 1 Oct 2012 16:25:43 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 16:25:43 -0000 Received: by eekb47 with SMTP id b47so2591990eek.32 for ; Mon, 01 Oct 2012 09:25:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=CatkqNsgwklgosktROPpKhWui9v75gjpLU+TNmbqcaw=; b=rxCBWXf+IdB+dIkSnwJPneaXWKfBPlEwE+oYz8Nt0LQtYvgTFh13X3LTdC2W36vyRA dlvWgI8xxKrK9CtVBUroHx9IPK13sH0NqWaX3KxaMQAbaEx0tfd6g7bMKU7gU+vmMZH+ fo0IMJSCXdZ6Yuq6tlT9ePCHin3ck1qMb+QoV8cMW6Ikr99TpwTmzJYhyrcLhJLUpdgU ltMVP/Oi8+uS2tsSoNLBTGXdjJLisiSP3L/tgKDUvqfLRd14y3MUqQ0nIAxd6DjN4h8B CfyLOitogNEY2cFTBiOJ75Xq5eVAh8WNC7XBNJutshJ83eb8JTfCr5rPLVGEw5KcTajk qZEA== MIME-Version: 1.0 Received: by 10.14.172.193 with SMTP id t41mr18778420eel.25.1349108743472; Mon, 01 Oct 2012 09:25:43 -0700 (PDT) Received: by 10.14.215.195 with HTTP; Mon, 1 Oct 2012 09:25:43 -0700 (PDT) Date: Mon, 1 Oct 2012 17:25:43 +0100 X-Google-Sender-Auth: ZiQkj6E-wzfczhT3-zbV_1OBQhA Message-ID: From: George Dunlap To: xen-devel@lists.xen.org Subject: [Xen-devel] Xen 4.3 development update X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This information will be mirrored on the Xen 4.3 Roadmap wiki page: http://wiki.xen.org/wiki/Xen_Roadmap/4.3 = Timeline = We are planning on a 9-month release cycle. Based on that, below are our estimated dates: * Feature Freeze: 25 March 2013 * First RC: 6 May 2013 * Release: 17 June 2013 The RCs and release will of course depend on stability and bugs, and will therefore be fairly unpredictable. The feature freeze may be slipped for especially important features which are near completion. = Feature tracking = Below is a list of features we're tracking for this release. Please respond to this mail with any updates to the status. There are a number of items whose owners are marked as "?". If you are working on this, or know who is working on it, please respond and let me know. Alternately, if you would *like* to work on it, please let me know as well. And if there is something you're working on you'd like tracked, please respond, and I will add it to the list. NB: Several of the items on this list are from external projects: linux, qemu, and libvirt. These are not part of the Xen tree, but are directly related to our users' experience (e.g., work in Linux or qemu) or to integration with other important projects (e.g., libvirt bindings). Since all of these are part of the Xen community work, and comes from the same pool of labor, it makes sense to track the progress here, even though they won't explicitly be released as part of 4.3. == Completed == * Linux console improvements -EHCI debug port * Default to QEMU upstream - pci pass-thru (external) == Not yet complete == * PVH mode, domU (w/ Linux) owner: mukesh@oracle status: ? * PVH mode, dom0 (w/ Linux) owner: mukesh@oracle status: ? * Event channel scalability owner: attilio@citrix status: initial design proposed Increase limit on event channels (currently 1024 for 32-bit guests, 4096 for 64-bit guests) * ARM server port owner: ijc@citrix status: Core hypervisor patches accepted; Linux paches pending * NUMA scheduler affinity critical owner: dario@citrix status: ? * NUMA Memory migration owner: dario@citrix status: ? * blktap3 owner: thanos@citrix status: in progress * Default to QEMU upstream - qemu-based stubdom (Linux or BSD libc) owner: anthony@citrix status: in progress qemu-upstream needs a more fully-featured libc than exists in minios. Either work on a minimalist linux-based stubdom with glibc, or port one of the BSD libcs to minios. - enable dirtybit tracking during migration (external) status: patches submitted to QEMU and to LibXL. - xl cd-{insert,eject} (external) status: intilal implementation submitted * Persistent grants (external) owner: @citrix status: Initial implementation posted * Multi-page blk rings (external) - blkback in kernel (konrad@oracle, ?@intel) - qemu blkback status: ? * Multi-page net protocol (external) owner: ijc@citrix or annie.li@oracle status: Initial patches posted (by Wei Liu) expand the network ring protocol to allow multiple pages for increased throughput * Scalability: 16TiB of RAM owner: jan@suse status: Not started * libvirt/libxl integration (external) - Migration owner: cyliu@suse (?) status: first draft implemented, not yet submitted - Itemize other things that need work To begin with, we need someone to go and make some lists: - Features available in libvirt/KVM not available in libvirt/libxl See http://libvirt.org/hvsupport.html - Features available in xl/Xen but not available in libvirt/Xen * V4V: Inter-domain communication owner (Xen): jean.guyader@citrix.com status (Xen): patches submitted owner (Linux driver): stefano.panella@citrix status (Linux driver): in progress * xl vm-{export,import} owner: ? status: ? Allow xl to import and export VMs to other formats; particularly ovf, perhaps the XenServer format, or more. * xl USB pass-through for PV guests owner: ? status: ? - Port the xend PV pass-through functionality to xl. - Make sure qemu-based USB with qemu-upstream works - Upstream the Linux frontend/backend drivers * openvswitch toostack integration owner: roger@citrix status: Sample script posted by Bastian ("[RFC] openvswitch support script") * Rationalized backend scripts (incl. driver domains) owner: roger@citrix status: ? * Linux console improvements owner: ? status: Stalled (see below) -xHCI debug port (Needs hardware) -Firewire (needs hardware) * CPUID-based idle (don't rely on ACPI info f/ dom0) owner: jan@suse status: done, to be submitted * Remove hardcoded mobprobe's in xencommons owner: ? status: ? * Make storage migration possible owner: ? status: ? There needs to be a way, either via command-line or via some hooks, that someone can build a "storage migration" feature on top of libxl or xl. * Full-VM snapshotting owner: ? status: ? Have a way of coordinating the taking and restoring of VM memory and disk snapshots. This would involve some investigation into the best way to accomplish this. * VM Cloning owner: ? status: May need review Again, a way of coordinating the memory and disk aspects. Research into the best way to do this would probably go along with the snapshotting feature. * Memory: Replace PoD with paging mechanism owner: george@citrix status: May need review * PV audio (audio for stubdom qemu) owner: stefano.panella@citrix status: ? * Managed domains? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 16:26:05 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 16:26:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIioV-0007DB-AY; Mon, 01 Oct 2012 16:25:47 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIioT-0007D4-MD for xen-devel@lists.xen.org; Mon, 01 Oct 2012 16:25:46 +0000 Received: from [85.158.137.99:23268] by server-1.bemta-3.messagelabs.com id 7E/8C-16425-804C9605; Mon, 01 Oct 2012 16:25:44 +0000 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-6.tower-217.messagelabs.com!1349108743!14703178!1 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19517 invoked from network); 1 Oct 2012 16:25:43 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 16:25:43 -0000 Received: by eekb47 with SMTP id b47so2591990eek.32 for ; Mon, 01 Oct 2012 09:25:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=CatkqNsgwklgosktROPpKhWui9v75gjpLU+TNmbqcaw=; b=rxCBWXf+IdB+dIkSnwJPneaXWKfBPlEwE+oYz8Nt0LQtYvgTFh13X3LTdC2W36vyRA dlvWgI8xxKrK9CtVBUroHx9IPK13sH0NqWaX3KxaMQAbaEx0tfd6g7bMKU7gU+vmMZH+ fo0IMJSCXdZ6Yuq6tlT9ePCHin3ck1qMb+QoV8cMW6Ikr99TpwTmzJYhyrcLhJLUpdgU ltMVP/Oi8+uS2tsSoNLBTGXdjJLisiSP3L/tgKDUvqfLRd14y3MUqQ0nIAxd6DjN4h8B CfyLOitogNEY2cFTBiOJ75Xq5eVAh8WNC7XBNJutshJ83eb8JTfCr5rPLVGEw5KcTajk qZEA== MIME-Version: 1.0 Received: by 10.14.172.193 with SMTP id t41mr18778420eel.25.1349108743472; Mon, 01 Oct 2012 09:25:43 -0700 (PDT) Received: by 10.14.215.195 with HTTP; Mon, 1 Oct 2012 09:25:43 -0700 (PDT) Date: Mon, 1 Oct 2012 17:25:43 +0100 X-Google-Sender-Auth: ZiQkj6E-wzfczhT3-zbV_1OBQhA Message-ID: From: George Dunlap To: xen-devel@lists.xen.org Subject: [Xen-devel] Xen 4.3 development update X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This information will be mirrored on the Xen 4.3 Roadmap wiki page: http://wiki.xen.org/wiki/Xen_Roadmap/4.3 = Timeline = We are planning on a 9-month release cycle. Based on that, below are our estimated dates: * Feature Freeze: 25 March 2013 * First RC: 6 May 2013 * Release: 17 June 2013 The RCs and release will of course depend on stability and bugs, and will therefore be fairly unpredictable. The feature freeze may be slipped for especially important features which are near completion. = Feature tracking = Below is a list of features we're tracking for this release. Please respond to this mail with any updates to the status. There are a number of items whose owners are marked as "?". If you are working on this, or know who is working on it, please respond and let me know. Alternately, if you would *like* to work on it, please let me know as well. And if there is something you're working on you'd like tracked, please respond, and I will add it to the list. NB: Several of the items on this list are from external projects: linux, qemu, and libvirt. These are not part of the Xen tree, but are directly related to our users' experience (e.g., work in Linux or qemu) or to integration with other important projects (e.g., libvirt bindings). Since all of these are part of the Xen community work, and comes from the same pool of labor, it makes sense to track the progress here, even though they won't explicitly be released as part of 4.3. == Completed == * Linux console improvements -EHCI debug port * Default to QEMU upstream - pci pass-thru (external) == Not yet complete == * PVH mode, domU (w/ Linux) owner: mukesh@oracle status: ? * PVH mode, dom0 (w/ Linux) owner: mukesh@oracle status: ? * Event channel scalability owner: attilio@citrix status: initial design proposed Increase limit on event channels (currently 1024 for 32-bit guests, 4096 for 64-bit guests) * ARM server port owner: ijc@citrix status: Core hypervisor patches accepted; Linux paches pending * NUMA scheduler affinity critical owner: dario@citrix status: ? * NUMA Memory migration owner: dario@citrix status: ? * blktap3 owner: thanos@citrix status: in progress * Default to QEMU upstream - qemu-based stubdom (Linux or BSD libc) owner: anthony@citrix status: in progress qemu-upstream needs a more fully-featured libc than exists in minios. Either work on a minimalist linux-based stubdom with glibc, or port one of the BSD libcs to minios. - enable dirtybit tracking during migration (external) status: patches submitted to QEMU and to LibXL. - xl cd-{insert,eject} (external) status: intilal implementation submitted * Persistent grants (external) owner: @citrix status: Initial implementation posted * Multi-page blk rings (external) - blkback in kernel (konrad@oracle, ?@intel) - qemu blkback status: ? * Multi-page net protocol (external) owner: ijc@citrix or annie.li@oracle status: Initial patches posted (by Wei Liu) expand the network ring protocol to allow multiple pages for increased throughput * Scalability: 16TiB of RAM owner: jan@suse status: Not started * libvirt/libxl integration (external) - Migration owner: cyliu@suse (?) status: first draft implemented, not yet submitted - Itemize other things that need work To begin with, we need someone to go and make some lists: - Features available in libvirt/KVM not available in libvirt/libxl See http://libvirt.org/hvsupport.html - Features available in xl/Xen but not available in libvirt/Xen * V4V: Inter-domain communication owner (Xen): jean.guyader@citrix.com status (Xen): patches submitted owner (Linux driver): stefano.panella@citrix status (Linux driver): in progress * xl vm-{export,import} owner: ? status: ? Allow xl to import and export VMs to other formats; particularly ovf, perhaps the XenServer format, or more. * xl USB pass-through for PV guests owner: ? status: ? - Port the xend PV pass-through functionality to xl. - Make sure qemu-based USB with qemu-upstream works - Upstream the Linux frontend/backend drivers * openvswitch toostack integration owner: roger@citrix status: Sample script posted by Bastian ("[RFC] openvswitch support script") * Rationalized backend scripts (incl. driver domains) owner: roger@citrix status: ? * Linux console improvements owner: ? status: Stalled (see below) -xHCI debug port (Needs hardware) -Firewire (needs hardware) * CPUID-based idle (don't rely on ACPI info f/ dom0) owner: jan@suse status: done, to be submitted * Remove hardcoded mobprobe's in xencommons owner: ? status: ? * Make storage migration possible owner: ? status: ? There needs to be a way, either via command-line or via some hooks, that someone can build a "storage migration" feature on top of libxl or xl. * Full-VM snapshotting owner: ? status: ? Have a way of coordinating the taking and restoring of VM memory and disk snapshots. This would involve some investigation into the best way to accomplish this. * VM Cloning owner: ? status: May need review Again, a way of coordinating the memory and disk aspects. Research into the best way to do this would probably go along with the snapshotting feature. * Memory: Replace PoD with paging mechanism owner: george@citrix status: May need review * PV audio (audio for stubdom qemu) owner: stefano.panella@citrix status: ? * Managed domains? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 16:27:59 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 16:27:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIiqM-0007Ir-R4; Mon, 01 Oct 2012 16:27:42 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIiqL-0007Ii-Ho for xen-devel@lists.xen.org; Mon, 01 Oct 2012 16:27:41 +0000 Received: from [85.158.137.99:43708] by server-2.bemta-3.messagelabs.com id C9/76-16514-A74C9605; Mon, 01 Oct 2012 16:27:38 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-13.tower-217.messagelabs.com!1349108858!19861920!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI1NjQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29171 invoked from network); 1 Oct 2012 16:27:38 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 16:27:38 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="14875617" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 16:27:37 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 17:27:37 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TIiqH-0001sj-Aa; Mon, 01 Oct 2012 16:27:37 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TIiqH-0004tZ-6e; Mon, 01 Oct 2012 17:27:37 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20585.50297.106231.155363@mariner.uk.xensource.com> Date: Mon, 1 Oct 2012 17:27:37 +0100 To: Paul Durrant Newsgroups: chiark.mail.xen.devel In-Reply-To: <291EDFCB1E9E224A99088639C4762022FDDCAB6EB9@LONPMAILBOX01.citrite.net>, <291EDFCB1E9E224A99088639C4762022FDDCAB6EB5@LONPMAILBOX01.citrite.net> References: <1349084633-13186-1-git-send-email-paul.durrant@citrix.com> <20585.45901.698074.351144@mariner.uk.xensource.com> <291EDFCB1E9E224A99088639C4762022FDDCAB6EB5@LONPMAILBOX01.citrite.net> <1349084491-13027-1-git-send-email-paul.durrant@citrix.com> <1349084491-13027-2-git-send-email-paul.durrant@citrix.com> <20585.45787.302130.684768@mariner.uk.xensource.com> <291EDFCB1E9E224A99088639C4762022FDDCAB6EB9@LONPMAILBOX01.citrite.net> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as the register of product numbers. [and 1 more messages] X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Paul Durrant writes ("RE: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as the register of product numbers."): > Ok. I thought it was helpful to reserve product number 0 for this purpose, but I'll ditch it. Well if you want to reserve it you could put a comment in the list saying "0 is reserved, do not use". Paul Durrant writes ("Re: [Xen-devel] [PATCH] Use new Xen public header for product numbers and names"): > Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]: > > As a case in point, this generates: > > case 0: product = NULL; break; > > and then passes the NULL to asprintf. > > Nothing should be using product number 0, so is this a problem? You're joking, right ? The guest can send any value it likes here and the result is that qemu might dereference NULL. (Although in practice asprintf doesn't crash on NULL strings in any implementation I'm aware of.) Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 16:27:59 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 16:27:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIiqM-0007Ir-R4; Mon, 01 Oct 2012 16:27:42 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIiqL-0007Ii-Ho for xen-devel@lists.xen.org; Mon, 01 Oct 2012 16:27:41 +0000 Received: from [85.158.137.99:43708] by server-2.bemta-3.messagelabs.com id C9/76-16514-A74C9605; Mon, 01 Oct 2012 16:27:38 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-13.tower-217.messagelabs.com!1349108858!19861920!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI1NjQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29171 invoked from network); 1 Oct 2012 16:27:38 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 16:27:38 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="14875617" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 16:27:37 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 17:27:37 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TIiqH-0001sj-Aa; Mon, 01 Oct 2012 16:27:37 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TIiqH-0004tZ-6e; Mon, 01 Oct 2012 17:27:37 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20585.50297.106231.155363@mariner.uk.xensource.com> Date: Mon, 1 Oct 2012 17:27:37 +0100 To: Paul Durrant Newsgroups: chiark.mail.xen.devel In-Reply-To: <291EDFCB1E9E224A99088639C4762022FDDCAB6EB9@LONPMAILBOX01.citrite.net>, <291EDFCB1E9E224A99088639C4762022FDDCAB6EB5@LONPMAILBOX01.citrite.net> References: <1349084633-13186-1-git-send-email-paul.durrant@citrix.com> <20585.45901.698074.351144@mariner.uk.xensource.com> <291EDFCB1E9E224A99088639C4762022FDDCAB6EB5@LONPMAILBOX01.citrite.net> <1349084491-13027-1-git-send-email-paul.durrant@citrix.com> <1349084491-13027-2-git-send-email-paul.durrant@citrix.com> <20585.45787.302130.684768@mariner.uk.xensource.com> <291EDFCB1E9E224A99088639C4762022FDDCAB6EB9@LONPMAILBOX01.citrite.net> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as the register of product numbers. [and 1 more messages] X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Paul Durrant writes ("RE: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as the register of product numbers."): > Ok. I thought it was helpful to reserve product number 0 for this purpose, but I'll ditch it. Well if you want to reserve it you could put a comment in the list saying "0 is reserved, do not use". Paul Durrant writes ("Re: [Xen-devel] [PATCH] Use new Xen public header for product numbers and names"): > Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]: > > As a case in point, this generates: > > case 0: product = NULL; break; > > and then passes the NULL to asprintf. > > Nothing should be using product number 0, so is this a problem? You're joking, right ? The guest can send any value it likes here and the result is that qemu might dereference NULL. (Although in practice asprintf doesn't crash on NULL strings in any implementation I'm aware of.) Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 16:28:56 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 16:28:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIirM-0007O1-14; Mon, 01 Oct 2012 16:28:44 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIirL-0007NB-3O for xen-devel@lists.xen.org; Mon, 01 Oct 2012 16:28:43 +0000 X-Env-Sender: Paul.Durrant@citrix.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1349108914!11082222!3 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzkwMjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11018 invoked from network); 1 Oct 2012 16:28:37 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 16:28:37 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="209905268" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 16:28:09 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 12:28:09 -0400 Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=pauldu) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TIiqm-0006jJ-Ka; Mon, 01 Oct 2012 17:28:08 +0100 From: Paul Durrant To: xen-devel@lists.xen.org Date: Mon, 1 Oct 2012 17:28:05 +0100 Message-ID: <1349108885-18900-3-git-send-email-paul.durrant@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1349108885-18900-1-git-send-email-paul.durrant@citrix.com> References: <1349108885-18900-1-git-send-email-paul.durrant@citrix.com> MIME-Version: 1.0 Cc: Paul Durrant Subject: [Xen-devel] [PATCH 2/2] Register Linux PV-on-HVM drivers product number. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is already in use despite never being registereed. See XEN_IOPORT_LINUX_PRODNUM in include/xen/platform_pci.h Signed-off-by: Paul Durrant --- xen/include/public/hvm/pvdrivers.h | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/xen/include/public/hvm/pvdrivers.h b/xen/include/public/hvm/pvdrivers.h index 0471ebc..4c6b705 100644 --- a/xen/include/public/hvm/pvdrivers.h +++ b/xen/include/public/hvm/pvdrivers.h @@ -41,6 +41,7 @@ #define PVDRIVERS_PRODUCT_LIST(EACH) \ EACH("xensource-windows", 0x0001) /* Citrix */ \ EACH("gplpv-windows", 0x0002) /* James Harper */ \ + EACH("linux", 0x0003) \ EACH("experimental", 0xffff) #endif /* _XEN_PUBLIC_PVDRIVERS_H_ */ -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 16:28:56 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 16:28:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIirM-0007O1-14; Mon, 01 Oct 2012 16:28:44 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIirL-0007NB-3O for xen-devel@lists.xen.org; Mon, 01 Oct 2012 16:28:43 +0000 X-Env-Sender: Paul.Durrant@citrix.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1349108914!11082222!3 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzkwMjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11018 invoked from network); 1 Oct 2012 16:28:37 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 16:28:37 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="209905268" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 16:28:09 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 12:28:09 -0400 Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=pauldu) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TIiqm-0006jJ-Ka; Mon, 01 Oct 2012 17:28:08 +0100 From: Paul Durrant To: xen-devel@lists.xen.org Date: Mon, 1 Oct 2012 17:28:05 +0100 Message-ID: <1349108885-18900-3-git-send-email-paul.durrant@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1349108885-18900-1-git-send-email-paul.durrant@citrix.com> References: <1349108885-18900-1-git-send-email-paul.durrant@citrix.com> MIME-Version: 1.0 Cc: Paul Durrant Subject: [Xen-devel] [PATCH 2/2] Register Linux PV-on-HVM drivers product number. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is already in use despite never being registereed. See XEN_IOPORT_LINUX_PRODNUM in include/xen/platform_pci.h Signed-off-by: Paul Durrant --- xen/include/public/hvm/pvdrivers.h | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/xen/include/public/hvm/pvdrivers.h b/xen/include/public/hvm/pvdrivers.h index 0471ebc..4c6b705 100644 --- a/xen/include/public/hvm/pvdrivers.h +++ b/xen/include/public/hvm/pvdrivers.h @@ -41,6 +41,7 @@ #define PVDRIVERS_PRODUCT_LIST(EACH) \ EACH("xensource-windows", 0x0001) /* Citrix */ \ EACH("gplpv-windows", 0x0002) /* James Harper */ \ + EACH("linux", 0x0003) \ EACH("experimental", 0xffff) #endif /* _XEN_PUBLIC_PVDRIVERS_H_ */ -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 16:28:57 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 16:28:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIirL-0007Nu-Km; Mon, 01 Oct 2012 16:28:43 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIirK-0007N8-Hp for xen-devel@lists.xen.org; Mon, 01 Oct 2012 16:28:42 +0000 X-Env-Sender: Paul.Durrant@citrix.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1349108914!11082222!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzkwMjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10971 invoked from network); 1 Oct 2012 16:28:36 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 16:28:36 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="209905266" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 16:28:09 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 12:28:08 -0400 Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=pauldu) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TIiqm-0006jJ-HK; Mon, 01 Oct 2012 17:28:08 +0100 From: Paul Durrant To: xen-devel@lists.xen.org Date: Mon, 1 Oct 2012 17:28:03 +0100 Message-ID: <1349108885-18900-1-git-send-email-paul.durrant@citrix.com> X-Mailer: git-send-email 1.7.2.5 MIME-Version: 1.0 Cc: Paul Durrant Subject: [Xen-devel] [PATCH 0/2] PV drivers product number registration (v3) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org PV drivers in HVM guests typically make use off an 'unplug' protocol in QEMU to prevent co-existence of emulated devices. See docs/misc/hvm-emulated-unplug.markdown for details. The register of product numbers used by the blacklisting feature of this protocol is currently directly in the xenstore.c source moduleof traditional QEMU. It should really be in a Xen header file to prevent duplication/conflict between QEMU versions. Moreover the linux PV-on-HVM drivers make use of product number 3 seemingly without ever registering that number. This patch series introduces a new header and registers product number 3 for Linux's use. A subsequent patch to qemu-xen-unstable wll be created to make use of the new header. Version 2: I have re-coded at Ian Jackson's request in the form of macros that allow a switch statement or array to be easily generated from the product list. Version 3: Ditching the terminator list entry. The associated QEMU patch is unmodified by this so not resending. Signed-off-by: Paul Durrant _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 16:28:57 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 16:28:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIirL-0007Nu-Km; Mon, 01 Oct 2012 16:28:43 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIirK-0007N8-Hp for xen-devel@lists.xen.org; Mon, 01 Oct 2012 16:28:42 +0000 X-Env-Sender: Paul.Durrant@citrix.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1349108914!11082222!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzkwMjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10971 invoked from network); 1 Oct 2012 16:28:36 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 16:28:36 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="209905266" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 16:28:09 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 12:28:08 -0400 Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=pauldu) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TIiqm-0006jJ-HK; Mon, 01 Oct 2012 17:28:08 +0100 From: Paul Durrant To: xen-devel@lists.xen.org Date: Mon, 1 Oct 2012 17:28:03 +0100 Message-ID: <1349108885-18900-1-git-send-email-paul.durrant@citrix.com> X-Mailer: git-send-email 1.7.2.5 MIME-Version: 1.0 Cc: Paul Durrant Subject: [Xen-devel] [PATCH 0/2] PV drivers product number registration (v3) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org PV drivers in HVM guests typically make use off an 'unplug' protocol in QEMU to prevent co-existence of emulated devices. See docs/misc/hvm-emulated-unplug.markdown for details. The register of product numbers used by the blacklisting feature of this protocol is currently directly in the xenstore.c source moduleof traditional QEMU. It should really be in a Xen header file to prevent duplication/conflict between QEMU versions. Moreover the linux PV-on-HVM drivers make use of product number 3 seemingly without ever registering that number. This patch series introduces a new header and registers product number 3 for Linux's use. A subsequent patch to qemu-xen-unstable wll be created to make use of the new header. Version 2: I have re-coded at Ian Jackson's request in the form of macros that allow a switch statement or array to be easily generated from the product list. Version 3: Ditching the terminator list entry. The associated QEMU patch is unmodified by this so not resending. Signed-off-by: Paul Durrant _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 16:28:57 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 16:28:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIirL-0007Ni-9V; Mon, 01 Oct 2012 16:28:43 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIirJ-0007Mz-FB for xen-devel@lists.xen.org; Mon, 01 Oct 2012 16:28:41 +0000 X-Env-Sender: Paul.Durrant@citrix.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1349108914!11082222!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzkwMjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10936 invoked from network); 1 Oct 2012 16:28:35 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 16:28:35 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="209905267" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 16:28:09 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 12:28:09 -0400 Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=pauldu) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TIiqm-0006jJ-Ix; Mon, 01 Oct 2012 17:28:08 +0100 From: Paul Durrant To: xen-devel@lists.xen.org Date: Mon, 1 Oct 2012 17:28:04 +0100 Message-ID: <1349108885-18900-2-git-send-email-paul.durrant@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1349108885-18900-1-git-send-email-paul.durrant@citrix.com> References: <1349108885-18900-1-git-send-email-paul.durrant@citrix.com> MIME-Version: 1.0 Cc: Paul Durrant Subject: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as the register of product numbers. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org These product numbers are used by the QEMU blacklisting protocol in traditional QEMU and are currently coded directly into the xenstore.c source module. Since there are now multiple QEMUs this information should be pulled into a public header to avoid duplication/conflict. hvm-emulated-unplug.markdown has also been adjusted to reference the new header. Signed-off-by: Paul Durrant --- docs/misc/hvm-emulated-unplug.markdown | 2 +- xen/include/public/hvm/pvdrivers.h | 46 ++++++++++++++++++++++++++++++++ 2 files changed, 47 insertions(+), 1 deletions(-) create mode 100644 xen/include/public/hvm/pvdrivers.h diff --git a/docs/misc/hvm-emulated-unplug.markdown b/docs/misc/hvm-emulated-unplug.markdown index 707fbab..ec9ce83 100644 --- a/docs/misc/hvm-emulated-unplug.markdown +++ b/docs/misc/hvm-emulated-unplug.markdown @@ -65,4 +65,4 @@ decimal number. `{product_name}` is a string corresponding to the product number in step 3. The master registry of product names and numbers is in -qemu-xen-unstable's xenstore.c. +xen/include/public/hvm/pvdrivers.h diff --git a/xen/include/public/hvm/pvdrivers.h b/xen/include/public/hvm/pvdrivers.h new file mode 100644 index 0000000..0471ebc --- /dev/null +++ b/xen/include/public/hvm/pvdrivers.h @@ -0,0 +1,46 @@ +/* + * pvdrivers.h: Register of PV drivers product numbers. + * Copyright (c) 2012, Citrix Systems Inc. + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the "Software"), to + * deal in the Software without restriction, including without limitation the + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or + * sell copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER + * DEALINGS IN THE SOFTWARE. + */ + +#ifndef _XEN_PUBLIC_PVDRIVERS_H_ +#define _XEN_PUBLIC_PVDRIVERS_H_ + +/* + * This is the master registry of product numbers for + * PV drivers. + * If you need a new product number allocating, please + * post to xen-devel@lists.xensource.com. You should NOT use + * a product number without allocating one. + * If you maintain a separate versioning and distribution path + * for PV drivers you should have a separate product number so + * that your drivers can be separated from others. + * + * During development, you may use the product ID to + * indicate a driver which is yet to be released. + */ + +#define PVDRIVERS_PRODUCT_LIST(EACH) \ + EACH("xensource-windows", 0x0001) /* Citrix */ \ + EACH("gplpv-windows", 0x0002) /* James Harper */ \ + EACH("experimental", 0xffff) + +#endif /* _XEN_PUBLIC_PVDRIVERS_H_ */ -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 16:28:57 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 16:28:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIirL-0007Ni-9V; Mon, 01 Oct 2012 16:28:43 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIirJ-0007Mz-FB for xen-devel@lists.xen.org; Mon, 01 Oct 2012 16:28:41 +0000 X-Env-Sender: Paul.Durrant@citrix.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1349108914!11082222!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzkwMjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10936 invoked from network); 1 Oct 2012 16:28:35 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 16:28:35 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="209905267" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 16:28:09 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 12:28:09 -0400 Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=pauldu) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TIiqm-0006jJ-Ix; Mon, 01 Oct 2012 17:28:08 +0100 From: Paul Durrant To: xen-devel@lists.xen.org Date: Mon, 1 Oct 2012 17:28:04 +0100 Message-ID: <1349108885-18900-2-git-send-email-paul.durrant@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1349108885-18900-1-git-send-email-paul.durrant@citrix.com> References: <1349108885-18900-1-git-send-email-paul.durrant@citrix.com> MIME-Version: 1.0 Cc: Paul Durrant Subject: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as the register of product numbers. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org These product numbers are used by the QEMU blacklisting protocol in traditional QEMU and are currently coded directly into the xenstore.c source module. Since there are now multiple QEMUs this information should be pulled into a public header to avoid duplication/conflict. hvm-emulated-unplug.markdown has also been adjusted to reference the new header. Signed-off-by: Paul Durrant --- docs/misc/hvm-emulated-unplug.markdown | 2 +- xen/include/public/hvm/pvdrivers.h | 46 ++++++++++++++++++++++++++++++++ 2 files changed, 47 insertions(+), 1 deletions(-) create mode 100644 xen/include/public/hvm/pvdrivers.h diff --git a/docs/misc/hvm-emulated-unplug.markdown b/docs/misc/hvm-emulated-unplug.markdown index 707fbab..ec9ce83 100644 --- a/docs/misc/hvm-emulated-unplug.markdown +++ b/docs/misc/hvm-emulated-unplug.markdown @@ -65,4 +65,4 @@ decimal number. `{product_name}` is a string corresponding to the product number in step 3. The master registry of product names and numbers is in -qemu-xen-unstable's xenstore.c. +xen/include/public/hvm/pvdrivers.h diff --git a/xen/include/public/hvm/pvdrivers.h b/xen/include/public/hvm/pvdrivers.h new file mode 100644 index 0000000..0471ebc --- /dev/null +++ b/xen/include/public/hvm/pvdrivers.h @@ -0,0 +1,46 @@ +/* + * pvdrivers.h: Register of PV drivers product numbers. + * Copyright (c) 2012, Citrix Systems Inc. + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the "Software"), to + * deal in the Software without restriction, including without limitation the + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or + * sell copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER + * DEALINGS IN THE SOFTWARE. + */ + +#ifndef _XEN_PUBLIC_PVDRIVERS_H_ +#define _XEN_PUBLIC_PVDRIVERS_H_ + +/* + * This is the master registry of product numbers for + * PV drivers. + * If you need a new product number allocating, please + * post to xen-devel@lists.xensource.com. You should NOT use + * a product number without allocating one. + * If you maintain a separate versioning and distribution path + * for PV drivers you should have a separate product number so + * that your drivers can be separated from others. + * + * During development, you may use the product ID to + * indicate a driver which is yet to be released. + */ + +#define PVDRIVERS_PRODUCT_LIST(EACH) \ + EACH("xensource-windows", 0x0001) /* Citrix */ \ + EACH("gplpv-windows", 0x0002) /* James Harper */ \ + EACH("experimental", 0xffff) + +#endif /* _XEN_PUBLIC_PVDRIVERS_H_ */ -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 16:33:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 16:33:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIivv-0007zB-Ut; Mon, 01 Oct 2012 16:33:27 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIivu-0007z2-KV for xen-devel@lists.xen.org; Mon, 01 Oct 2012 16:33:26 +0000 Received: from [85.158.138.51:55503] by server-15.bemta-3.messagelabs.com id 33/A4-18313-5D5C9605; Mon, 01 Oct 2012 16:33:25 +0000 X-Env-Sender: ketuzsezr@gmail.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1349109202!32168118!1 X-Originating-IP: [209.85.220.45] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17202 invoked from network); 1 Oct 2012 16:33:24 -0000 Received: from mail-pa0-f45.google.com (HELO mail-pa0-f45.google.com) (209.85.220.45) by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 16:33:24 -0000 Received: by padfb10 with SMTP id fb10so4487718pad.32 for ; Mon, 01 Oct 2012 09:33:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=vR/IeQa/2Qq1M1TqK9msjyJ50PzmWF6BJbFLG+chstY=; b=ZsE2RRHe2LHOU1DAZC0W0FxuWe2s5ckG0DcPGzJ6ym+4WMsVO4hUlzVqkdf0eY7pTN z63xxPW2FsP9ygJUP9TUODDHNCck2oUfICslld/eJFGgVTHMuptY7Vfb8uI5DyeUz8eE XZyi2FtJZ62bikqkVMbflNKHaCgXVRX7A+cr1TAWxJDEy+UWIyu+lxLM8Ey0vUZCefMD BXsmofhG0+n4nntU/wxaKUF6eD/3CxoKx5Nkb+w/fZamotFaBdTLbqvKONjIdUwWxd7M M/Z3nHOUu3tppAyFYEqXA2mtAkQfMRDVqxeIctN3gAvANpSSwHCU2smPj7IEePf/ZYBv 7jsA== MIME-Version: 1.0 Received: by 10.68.242.231 with SMTP id wt7mr42117333pbc.99.1349109202080; Mon, 01 Oct 2012 09:33:22 -0700 (PDT) Received: by 10.66.193.9 with HTTP; Mon, 1 Oct 2012 09:33:22 -0700 (PDT) In-Reply-To: <20120930161345.GA31109@dingwall.me.uk> References: <20120930161345.GA31109@dingwall.me.uk> Date: Mon, 1 Oct 2012 12:33:22 -0400 X-Google-Sender-Auth: DF3B5MqKo89HkAUyCHMgjUyClYQ Message-ID: From: Konrad Rzeszutek Wilk To: James Dingwall Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [james-xen@dingwall.me.uk: [Xen-users] Xen 4.2.0 - CPU Frequency Scaling] X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Sun, Sep 30, 2012 at 12:13 PM, James Dingwall wrote: > Hi, > > I didn't get any response on xen-users for this issue but so I'm hoping > -devel can help. Lets see if we can help you. > > I have had problems using cpu frequency scaling since the > xen-acpi-processor code was added to the mainline kernel source. I > wasn't sure if the problem I was seeing was related to the old version > (4.1.2) of Xen that I was using but now I'm on 4.2.0 and it still exists > I thought I would check if I have a misconfiguration or if I have > discovered a problem. My system is a dual AMD Opteron(tm) Processor > 2423 HE on kernel 3.4.8. > > The xen command line is: > console=vga,com2 com2=115200,8n1 dom0_mem=max:2048M dom0_max_vcpus=2 > dom0_vcpus_pin Do you nee the dom0_max_vcpus=2? If they are not present does the problem persist? > > The CPU scaling information reported by xenpm is below. The problem > is that only cpuid 1 can be managed separately, all the others are What exactly are you trying to manage? As in what are you doing? > bundled together and cannot be handled independently which used to be > possible with the old xen kernel. If further information would be > useful please let me know. > > Thanks, > James > > # xenpm get-cpufreq-para > cpu id : 0 > affected_cpus : 0 2 3 4 5 6 7 8 9 10 11 > cpuinfo frequency : max [2000000] min [800000] cur [800000] > scaling_driver : > scaling_avail_gov : userspace performance powersave ondemand > current_governor : ondemand > ondemand specific : > sampling_rate : max [10000000] min [10000] cur [20000] > up_threshold : 80 > scaling_avail_freq : 2000000 1500000 1300000 1000000 *800000 > scaling frequency : max [2000000] min [800000] cur [800000] > > cpu id : 1 > affected_cpus : 1 > cpuinfo frequency : max [2000000] min [800000] cur [800000] > scaling_driver : > scaling_avail_gov : userspace performance powersave ondemand > current_governor : ondemand > ondemand specific : > sampling_rate : max [10000000] min [10000] cur [20000] > up_threshold : 80 > scaling_avail_freq : 2000000 1500000 1300000 1000000 *800000 > scaling frequency : max [2000000] min [800000] cur [800000] > > cpu id : 2 > affected_cpus : 0 2 3 4 5 6 7 8 9 10 11 > cpuinfo frequency : max [2000000] min [800000] cur [800000] > scaling_driver : > scaling_avail_gov : userspace performance powersave ondemand > current_governor : ondemand > ondemand specific : > sampling_rate : max [10000000] min [10000] cur [20000] > up_threshold : 80 > scaling_avail_freq : 2000000 1500000 1300000 1000000 *800000 > scaling frequency : max [2000000] min [800000] cur [800000] > > cpu id : 3 > affected_cpus : 0 2 3 4 5 6 7 8 9 10 11 > cpuinfo frequency : max [2000000] min [800000] cur [800000] > scaling_driver : > scaling_avail_gov : userspace performance powersave ondemand > current_governor : ondemand > ondemand specific : > sampling_rate : max [10000000] min [10000] cur [20000] > up_threshold : 80 > scaling_avail_freq : 2000000 1500000 1300000 1000000 *800000 > scaling frequency : max [2000000] min [800000] cur [800000] > > cpu id : 4 > affected_cpus : 0 2 3 4 5 6 7 8 9 10 11 > cpuinfo frequency : max [2000000] min [800000] cur [800000] > scaling_driver : > scaling_avail_gov : userspace performance powersave ondemand > current_governor : ondemand > ondemand specific : > sampling_rate : max [10000000] min [10000] cur [20000] > up_threshold : 80 > scaling_avail_freq : 2000000 1500000 1300000 1000000 *800000 > scaling frequency : max [2000000] min [800000] cur [800000] > > cpu id : 5 > affected_cpus : 0 2 3 4 5 6 7 8 9 10 11 > cpuinfo frequency : max [2000000] min [800000] cur [800000] > scaling_driver : > scaling_avail_gov : userspace performance powersave ondemand > current_governor : ondemand > ondemand specific : > sampling_rate : max [10000000] min [10000] cur [20000] > up_threshold : 80 > scaling_avail_freq : 2000000 1500000 1300000 1000000 *800000 > scaling frequency : max [2000000] min [800000] cur [800000] > > cpu id : 6 > affected_cpus : 0 2 3 4 5 6 7 8 9 10 11 > cpuinfo frequency : max [2000000] min [800000] cur [800000] > scaling_driver : > scaling_avail_gov : userspace performance powersave ondemand > current_governor : ondemand > ondemand specific : > sampling_rate : max [10000000] min [10000] cur [20000] > up_threshold : 80 > scaling_avail_freq : 2000000 1500000 1300000 1000000 *800000 > scaling frequency : max [2000000] min [800000] cur [800000] > > cpu id : 7 > affected_cpus : 0 2 3 4 5 6 7 8 9 10 11 > cpuinfo frequency : max [2000000] min [800000] cur [800000] > scaling_driver : > scaling_avail_gov : userspace performance powersave ondemand > current_governor : ondemand > ondemand specific : > sampling_rate : max [10000000] min [10000] cur [20000] > up_threshold : 80 > scaling_avail_freq : 2000000 1500000 1300000 1000000 *800000 > scaling frequency : max [2000000] min [800000] cur [800000] > > cpu id : 8 > affected_cpus : 0 2 3 4 5 6 7 8 9 10 11 > cpuinfo frequency : max [2000000] min [800000] cur [800000] > scaling_driver : > scaling_avail_gov : userspace performance powersave ondemand > current_governor : ondemand > ondemand specific : > sampling_rate : max [10000000] min [10000] cur [20000] > up_threshold : 80 > scaling_avail_freq : 2000000 1500000 1300000 1000000 *800000 > scaling frequency : max [2000000] min [800000] cur [800000] > > cpu id : 9 > affected_cpus : 0 2 3 4 5 6 7 8 9 10 11 > cpuinfo frequency : max [2000000] min [800000] cur [800000] > scaling_driver : > scaling_avail_gov : userspace performance powersave ondemand > current_governor : ondemand > ondemand specific : > sampling_rate : max [10000000] min [10000] cur [20000] > up_threshold : 80 > scaling_avail_freq : 2000000 1500000 1300000 1000000 *800000 > scaling frequency : max [2000000] min [800000] cur [800000] > > cpu id : 10 > affected_cpus : 0 2 3 4 5 6 7 8 9 10 11 > cpuinfo frequency : max [2000000] min [800000] cur [800000] > scaling_driver : > scaling_avail_gov : userspace performance powersave ondemand > current_governor : ondemand > ondemand specific : > sampling_rate : max [10000000] min [10000] cur [20000] > up_threshold : 80 > scaling_avail_freq : 2000000 1500000 1300000 1000000 *800000 > scaling frequency : max [2000000] min [800000] cur [800000] > > cpu id : 11 > affected_cpus : 0 2 3 4 5 6 7 8 9 10 11 > cpuinfo frequency : max [2000000] min [800000] cur [800000] > scaling_driver : > scaling_avail_gov : userspace performance powersave ondemand > current_governor : ondemand > ondemand specific : > sampling_rate : max [10000000] min [10000] cur [20000] > up_threshold : 80 > scaling_avail_freq : 2000000 1500000 1300000 1000000 *800000 > scaling frequency : max [2000000] min [800000] cur [800000] > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 16:33:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 16:33:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIivv-0007zB-Ut; Mon, 01 Oct 2012 16:33:27 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIivu-0007z2-KV for xen-devel@lists.xen.org; Mon, 01 Oct 2012 16:33:26 +0000 Received: from [85.158.138.51:55503] by server-15.bemta-3.messagelabs.com id 33/A4-18313-5D5C9605; Mon, 01 Oct 2012 16:33:25 +0000 X-Env-Sender: ketuzsezr@gmail.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1349109202!32168118!1 X-Originating-IP: [209.85.220.45] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17202 invoked from network); 1 Oct 2012 16:33:24 -0000 Received: from mail-pa0-f45.google.com (HELO mail-pa0-f45.google.com) (209.85.220.45) by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 16:33:24 -0000 Received: by padfb10 with SMTP id fb10so4487718pad.32 for ; Mon, 01 Oct 2012 09:33:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=vR/IeQa/2Qq1M1TqK9msjyJ50PzmWF6BJbFLG+chstY=; b=ZsE2RRHe2LHOU1DAZC0W0FxuWe2s5ckG0DcPGzJ6ym+4WMsVO4hUlzVqkdf0eY7pTN z63xxPW2FsP9ygJUP9TUODDHNCck2oUfICslld/eJFGgVTHMuptY7Vfb8uI5DyeUz8eE XZyi2FtJZ62bikqkVMbflNKHaCgXVRX7A+cr1TAWxJDEy+UWIyu+lxLM8Ey0vUZCefMD BXsmofhG0+n4nntU/wxaKUF6eD/3CxoKx5Nkb+w/fZamotFaBdTLbqvKONjIdUwWxd7M M/Z3nHOUu3tppAyFYEqXA2mtAkQfMRDVqxeIctN3gAvANpSSwHCU2smPj7IEePf/ZYBv 7jsA== MIME-Version: 1.0 Received: by 10.68.242.231 with SMTP id wt7mr42117333pbc.99.1349109202080; Mon, 01 Oct 2012 09:33:22 -0700 (PDT) Received: by 10.66.193.9 with HTTP; Mon, 1 Oct 2012 09:33:22 -0700 (PDT) In-Reply-To: <20120930161345.GA31109@dingwall.me.uk> References: <20120930161345.GA31109@dingwall.me.uk> Date: Mon, 1 Oct 2012 12:33:22 -0400 X-Google-Sender-Auth: DF3B5MqKo89HkAUyCHMgjUyClYQ Message-ID: From: Konrad Rzeszutek Wilk To: James Dingwall Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [james-xen@dingwall.me.uk: [Xen-users] Xen 4.2.0 - CPU Frequency Scaling] X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Sun, Sep 30, 2012 at 12:13 PM, James Dingwall wrote: > Hi, > > I didn't get any response on xen-users for this issue but so I'm hoping > -devel can help. Lets see if we can help you. > > I have had problems using cpu frequency scaling since the > xen-acpi-processor code was added to the mainline kernel source. I > wasn't sure if the problem I was seeing was related to the old version > (4.1.2) of Xen that I was using but now I'm on 4.2.0 and it still exists > I thought I would check if I have a misconfiguration or if I have > discovered a problem. My system is a dual AMD Opteron(tm) Processor > 2423 HE on kernel 3.4.8. > > The xen command line is: > console=vga,com2 com2=115200,8n1 dom0_mem=max:2048M dom0_max_vcpus=2 > dom0_vcpus_pin Do you nee the dom0_max_vcpus=2? If they are not present does the problem persist? > > The CPU scaling information reported by xenpm is below. The problem > is that only cpuid 1 can be managed separately, all the others are What exactly are you trying to manage? As in what are you doing? > bundled together and cannot be handled independently which used to be > possible with the old xen kernel. If further information would be > useful please let me know. > > Thanks, > James > > # xenpm get-cpufreq-para > cpu id : 0 > affected_cpus : 0 2 3 4 5 6 7 8 9 10 11 > cpuinfo frequency : max [2000000] min [800000] cur [800000] > scaling_driver : > scaling_avail_gov : userspace performance powersave ondemand > current_governor : ondemand > ondemand specific : > sampling_rate : max [10000000] min [10000] cur [20000] > up_threshold : 80 > scaling_avail_freq : 2000000 1500000 1300000 1000000 *800000 > scaling frequency : max [2000000] min [800000] cur [800000] > > cpu id : 1 > affected_cpus : 1 > cpuinfo frequency : max [2000000] min [800000] cur [800000] > scaling_driver : > scaling_avail_gov : userspace performance powersave ondemand > current_governor : ondemand > ondemand specific : > sampling_rate : max [10000000] min [10000] cur [20000] > up_threshold : 80 > scaling_avail_freq : 2000000 1500000 1300000 1000000 *800000 > scaling frequency : max [2000000] min [800000] cur [800000] > > cpu id : 2 > affected_cpus : 0 2 3 4 5 6 7 8 9 10 11 > cpuinfo frequency : max [2000000] min [800000] cur [800000] > scaling_driver : > scaling_avail_gov : userspace performance powersave ondemand > current_governor : ondemand > ondemand specific : > sampling_rate : max [10000000] min [10000] cur [20000] > up_threshold : 80 > scaling_avail_freq : 2000000 1500000 1300000 1000000 *800000 > scaling frequency : max [2000000] min [800000] cur [800000] > > cpu id : 3 > affected_cpus : 0 2 3 4 5 6 7 8 9 10 11 > cpuinfo frequency : max [2000000] min [800000] cur [800000] > scaling_driver : > scaling_avail_gov : userspace performance powersave ondemand > current_governor : ondemand > ondemand specific : > sampling_rate : max [10000000] min [10000] cur [20000] > up_threshold : 80 > scaling_avail_freq : 2000000 1500000 1300000 1000000 *800000 > scaling frequency : max [2000000] min [800000] cur [800000] > > cpu id : 4 > affected_cpus : 0 2 3 4 5 6 7 8 9 10 11 > cpuinfo frequency : max [2000000] min [800000] cur [800000] > scaling_driver : > scaling_avail_gov : userspace performance powersave ondemand > current_governor : ondemand > ondemand specific : > sampling_rate : max [10000000] min [10000] cur [20000] > up_threshold : 80 > scaling_avail_freq : 2000000 1500000 1300000 1000000 *800000 > scaling frequency : max [2000000] min [800000] cur [800000] > > cpu id : 5 > affected_cpus : 0 2 3 4 5 6 7 8 9 10 11 > cpuinfo frequency : max [2000000] min [800000] cur [800000] > scaling_driver : > scaling_avail_gov : userspace performance powersave ondemand > current_governor : ondemand > ondemand specific : > sampling_rate : max [10000000] min [10000] cur [20000] > up_threshold : 80 > scaling_avail_freq : 2000000 1500000 1300000 1000000 *800000 > scaling frequency : max [2000000] min [800000] cur [800000] > > cpu id : 6 > affected_cpus : 0 2 3 4 5 6 7 8 9 10 11 > cpuinfo frequency : max [2000000] min [800000] cur [800000] > scaling_driver : > scaling_avail_gov : userspace performance powersave ondemand > current_governor : ondemand > ondemand specific : > sampling_rate : max [10000000] min [10000] cur [20000] > up_threshold : 80 > scaling_avail_freq : 2000000 1500000 1300000 1000000 *800000 > scaling frequency : max [2000000] min [800000] cur [800000] > > cpu id : 7 > affected_cpus : 0 2 3 4 5 6 7 8 9 10 11 > cpuinfo frequency : max [2000000] min [800000] cur [800000] > scaling_driver : > scaling_avail_gov : userspace performance powersave ondemand > current_governor : ondemand > ondemand specific : > sampling_rate : max [10000000] min [10000] cur [20000] > up_threshold : 80 > scaling_avail_freq : 2000000 1500000 1300000 1000000 *800000 > scaling frequency : max [2000000] min [800000] cur [800000] > > cpu id : 8 > affected_cpus : 0 2 3 4 5 6 7 8 9 10 11 > cpuinfo frequency : max [2000000] min [800000] cur [800000] > scaling_driver : > scaling_avail_gov : userspace performance powersave ondemand > current_governor : ondemand > ondemand specific : > sampling_rate : max [10000000] min [10000] cur [20000] > up_threshold : 80 > scaling_avail_freq : 2000000 1500000 1300000 1000000 *800000 > scaling frequency : max [2000000] min [800000] cur [800000] > > cpu id : 9 > affected_cpus : 0 2 3 4 5 6 7 8 9 10 11 > cpuinfo frequency : max [2000000] min [800000] cur [800000] > scaling_driver : > scaling_avail_gov : userspace performance powersave ondemand > current_governor : ondemand > ondemand specific : > sampling_rate : max [10000000] min [10000] cur [20000] > up_threshold : 80 > scaling_avail_freq : 2000000 1500000 1300000 1000000 *800000 > scaling frequency : max [2000000] min [800000] cur [800000] > > cpu id : 10 > affected_cpus : 0 2 3 4 5 6 7 8 9 10 11 > cpuinfo frequency : max [2000000] min [800000] cur [800000] > scaling_driver : > scaling_avail_gov : userspace performance powersave ondemand > current_governor : ondemand > ondemand specific : > sampling_rate : max [10000000] min [10000] cur [20000] > up_threshold : 80 > scaling_avail_freq : 2000000 1500000 1300000 1000000 *800000 > scaling frequency : max [2000000] min [800000] cur [800000] > > cpu id : 11 > affected_cpus : 0 2 3 4 5 6 7 8 9 10 11 > cpuinfo frequency : max [2000000] min [800000] cur [800000] > scaling_driver : > scaling_avail_gov : userspace performance powersave ondemand > current_governor : ondemand > ondemand specific : > sampling_rate : max [10000000] min [10000] cur [20000] > up_threshold : 80 > scaling_avail_freq : 2000000 1500000 1300000 1000000 *800000 > scaling frequency : max [2000000] min [800000] cur [800000] > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 16:38:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 16:38:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIj0R-00087k-O5; Mon, 01 Oct 2012 16:38:07 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIj0P-00087e-PA for xen-devel@lists.xen.org; Mon, 01 Oct 2012 16:38:05 +0000 Received: from [85.158.137.99:57797] by server-16.bemta-3.messagelabs.com id F6/BE-09129-DE6C9605; Mon, 01 Oct 2012 16:38:05 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-7.tower-217.messagelabs.com!1349109484!15049722!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI1NjQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24663 invoked from network); 1 Oct 2012 16:38:04 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 16:38:04 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="14875881" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 16:38:04 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 17:38:04 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TIj0O-00024J-3T; Mon, 01 Oct 2012 16:38:04 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TIj0N-0004uM-W6; Mon, 01 Oct 2012 17:38:03 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20585.50923.886126.938976@mariner.uk.xensource.com> Date: Mon, 1 Oct 2012 17:38:03 +0100 To: lars.kurth@xen.org Newsgroups: chiark.mail.xen.devel In-Reply-To: <50604343.1090506@xen.org> References: <20448.49637.38489.246434@mariner.uk.xensource.com> <1345718230.12501.79.camel@zakaz.uk.xensource.com> <50604343.1090506@xen.org> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] Security vulnerability process, and CVE-2012-0217 [vote?] X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Lars Kurth writes ("Re: [Xen-devel] Security vulnerability process, and CVE-2012-0217 [vote?]"): > Does anybody have any objections to Ian's changes in this patch series? > None of these appear significant changes. In line with the decision > making process, I would be happy to apply. But, I am also happy to run > this through a vote. They all seem uncontroversial to me and no-one has objected. You should go ahead and make the changes, I think. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 16:38:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 16:38:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIj0R-00087k-O5; Mon, 01 Oct 2012 16:38:07 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIj0P-00087e-PA for xen-devel@lists.xen.org; Mon, 01 Oct 2012 16:38:05 +0000 Received: from [85.158.137.99:57797] by server-16.bemta-3.messagelabs.com id F6/BE-09129-DE6C9605; Mon, 01 Oct 2012 16:38:05 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-7.tower-217.messagelabs.com!1349109484!15049722!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI1NjQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24663 invoked from network); 1 Oct 2012 16:38:04 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 16:38:04 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="14875881" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 16:38:04 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 17:38:04 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TIj0O-00024J-3T; Mon, 01 Oct 2012 16:38:04 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TIj0N-0004uM-W6; Mon, 01 Oct 2012 17:38:03 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20585.50923.886126.938976@mariner.uk.xensource.com> Date: Mon, 1 Oct 2012 17:38:03 +0100 To: lars.kurth@xen.org Newsgroups: chiark.mail.xen.devel In-Reply-To: <50604343.1090506@xen.org> References: <20448.49637.38489.246434@mariner.uk.xensource.com> <1345718230.12501.79.camel@zakaz.uk.xensource.com> <50604343.1090506@xen.org> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] Security vulnerability process, and CVE-2012-0217 [vote?] X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Lars Kurth writes ("Re: [Xen-devel] Security vulnerability process, and CVE-2012-0217 [vote?]"): > Does anybody have any objections to Ian's changes in this patch series? > None of these appear significant changes. In line with the decision > making process, I would be happy to apply. But, I am also happy to run > this through a vote. They all seem uncontroversial to me and no-one has objected. You should go ahead and make the changes, I think. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 16:42:56 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 16:42:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIj4t-0008HL-Ga; Mon, 01 Oct 2012 16:42:43 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIj4s-0008HE-2n for xen-devel@lists.xen.org; Mon, 01 Oct 2012 16:42:42 +0000 Received: from [85.158.143.35:41600] by server-1.bemta-4.messagelabs.com id FC/E8-05684-108C9605; Mon, 01 Oct 2012 16:42:41 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-10.tower-21.messagelabs.com!1349109760!11187021!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MjE1Mzg=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8105 invoked from network); 1 Oct 2012 16:42:40 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 16:42:40 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id BE0E0155F; Mon, 1 Oct 2012 19:42:39 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 418B42005D; Mon, 1 Oct 2012 19:42:39 +0300 (EEST) Date: Mon, 1 Oct 2012 19:42:39 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: George Dunlap Message-ID: <20121001164239.GE8912@reaktio.net> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.3 development update X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, Oct 01, 2012 at 05:25:43PM +0100, George Dunlap wrote: > > * xl USB pass-through for PV guests > owner: ? > status: ? > - Port the xend PV pass-through functionality to xl. > - Make sure qemu-based USB with qemu-upstream works > - Upstream the Linux frontend/backend drivers > I think this should be split into two separate tasks: * xl PVUSB pass-through for both PV and HVM guests owner: ? status: ? - xm/xend supports PVUSB pass-through to guests with PVUSB drivers (both PV and HVM guests). - port the xm/xend functionality to xl. - this PVUSB feature does not require support or emulation from Qemu. - upstream the Linux frontend/backend drivers. Current work-in-progress versions are in Konrad's git tree. - James Harper's GPLPV drivers for Windows include PVUSB frontend drivers. * xl USB pass-through for HVM guests using Qemu USB emulation owner: ? status: ? - xm/xend with qemu-traditional supports USB passthrough to HVM guests using the Qemu emulated USB controller. - port the xm/xend functionality to xl. - make sure USB passthrough with xl works with both qemu-traditional and qemu-upstream. - The HVM guest does not need any special drivers for this feature. -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 16:42:56 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 16:42:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIj4t-0008HL-Ga; Mon, 01 Oct 2012 16:42:43 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIj4s-0008HE-2n for xen-devel@lists.xen.org; Mon, 01 Oct 2012 16:42:42 +0000 Received: from [85.158.143.35:41600] by server-1.bemta-4.messagelabs.com id FC/E8-05684-108C9605; Mon, 01 Oct 2012 16:42:41 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-10.tower-21.messagelabs.com!1349109760!11187021!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MjE1Mzg=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8105 invoked from network); 1 Oct 2012 16:42:40 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 16:42:40 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id BE0E0155F; Mon, 1 Oct 2012 19:42:39 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 418B42005D; Mon, 1 Oct 2012 19:42:39 +0300 (EEST) Date: Mon, 1 Oct 2012 19:42:39 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: George Dunlap Message-ID: <20121001164239.GE8912@reaktio.net> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.3 development update X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, Oct 01, 2012 at 05:25:43PM +0100, George Dunlap wrote: > > * xl USB pass-through for PV guests > owner: ? > status: ? > - Port the xend PV pass-through functionality to xl. > - Make sure qemu-based USB with qemu-upstream works > - Upstream the Linux frontend/backend drivers > I think this should be split into two separate tasks: * xl PVUSB pass-through for both PV and HVM guests owner: ? status: ? - xm/xend supports PVUSB pass-through to guests with PVUSB drivers (both PV and HVM guests). - port the xm/xend functionality to xl. - this PVUSB feature does not require support or emulation from Qemu. - upstream the Linux frontend/backend drivers. Current work-in-progress versions are in Konrad's git tree. - James Harper's GPLPV drivers for Windows include PVUSB frontend drivers. * xl USB pass-through for HVM guests using Qemu USB emulation owner: ? status: ? - xm/xend with qemu-traditional supports USB passthrough to HVM guests using the Qemu emulated USB controller. - port the xm/xend functionality to xl. - make sure USB passthrough with xl works with both qemu-traditional and qemu-upstream. - The HVM guest does not need any special drivers for this feature. -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 16:44:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 16:44:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIj6G-0008N4-2U; Mon, 01 Oct 2012 16:44:08 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIj6E-0008Mv-QJ for xen-devel@lists.xen.org; Mon, 01 Oct 2012 16:44:06 +0000 Received: from [85.158.139.83:15258] by server-7.bemta-5.messagelabs.com id C1/53-00431-458C9605; Mon, 01 Oct 2012 16:44:04 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1349109843!32547550!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI1NjQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3087 invoked from network); 1 Oct 2012 16:44:04 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 16:44:04 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="14875997" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 16:44:03 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 17:44:03 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TIj6B-000287-Bw; Mon, 01 Oct 2012 16:44:03 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TIj6B-0004v3-8E; Mon, 01 Oct 2012 17:44:03 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20585.51282.934073.747200@mariner.uk.xensource.com> Date: Mon, 1 Oct 2012 17:44:02 +0100 To: Ian Campbell Newsgroups: chiark.mail.xen.devel In-Reply-To: <1348487103-2113-1-git-send-email-ian.campbell@citrix.com> References: <1348487103-2113-1-git-send-email-ian.campbell@citrix.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: keir@xen.org, xen-devel@lists.xen.org Subject: Re: [Xen-devel] [DOCDAY PATCH V2] docs: document/mark-up SCHEDOP_* X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Campbell writes ("[Xen-devel] [DOCDAY PATCH V2] docs: document/mark-up SCHEDOP_*"): > The biggest subtlety here is there additional argument when op == > SCHEDOP_shutdown and reason == SHUTDOWN_suspend and its interpretation by > xc_domain_{save,restore}. Add some clarifying comments to libxc as well. > > This patch moves some structs around but there is no functional change > other than improved documentation. Keir, should Ian just commit this ? Do you want to review and ack it ? I think it would be nice to be able to get these kind of docs patches in quickly in general. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 16:44:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 16:44:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIj6G-0008N4-2U; Mon, 01 Oct 2012 16:44:08 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIj6E-0008Mv-QJ for xen-devel@lists.xen.org; Mon, 01 Oct 2012 16:44:06 +0000 Received: from [85.158.139.83:15258] by server-7.bemta-5.messagelabs.com id C1/53-00431-458C9605; Mon, 01 Oct 2012 16:44:04 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1349109843!32547550!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI1NjQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3087 invoked from network); 1 Oct 2012 16:44:04 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 16:44:04 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="14875997" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 16:44:03 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 17:44:03 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TIj6B-000287-Bw; Mon, 01 Oct 2012 16:44:03 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TIj6B-0004v3-8E; Mon, 01 Oct 2012 17:44:03 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20585.51282.934073.747200@mariner.uk.xensource.com> Date: Mon, 1 Oct 2012 17:44:02 +0100 To: Ian Campbell Newsgroups: chiark.mail.xen.devel In-Reply-To: <1348487103-2113-1-git-send-email-ian.campbell@citrix.com> References: <1348487103-2113-1-git-send-email-ian.campbell@citrix.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: keir@xen.org, xen-devel@lists.xen.org Subject: Re: [Xen-devel] [DOCDAY PATCH V2] docs: document/mark-up SCHEDOP_* X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Campbell writes ("[Xen-devel] [DOCDAY PATCH V2] docs: document/mark-up SCHEDOP_*"): > The biggest subtlety here is there additional argument when op == > SCHEDOP_shutdown and reason == SHUTDOWN_suspend and its interpretation by > xc_domain_{save,restore}. Add some clarifying comments to libxc as well. > > This patch moves some structs around but there is no functional change > other than improved documentation. Keir, should Ian just commit this ? Do you want to review and ack it ? I think it would be nice to be able to get these kind of docs patches in quickly in general. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 16:51:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 16:51:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIjCw-00008q-8b; Mon, 01 Oct 2012 16:51:02 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIjCt-00008l-MO for xen-devel@lists.xensource.com; Mon, 01 Oct 2012 16:50:59 +0000 Received: from [85.158.143.35:11493] by server-2.bemta-4.messagelabs.com id C2/2A-06610-2F9C9605; Mon, 01 Oct 2012 16:50:58 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1349110258!12612135!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI1NjQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32164 invoked from network); 1 Oct 2012 16:50:58 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 16:50:58 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="14876096" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 16:50:06 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 17:50:06 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TIjC2-0002EZ-Fq; Mon, 01 Oct 2012 16:50:06 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TIjC2-0004vu-CA; Mon, 01 Oct 2012 17:50:06 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20585.51646.95260.536197@mariner.uk.xensource.com> Date: Mon, 1 Oct 2012 17:50:06 +0100 To: George Dunlap Newsgroups: chiark.mail.xen.devel In-Reply-To: <7e332fd064fac8d9d1ce.1348499997@elijah> References: <7e332fd064fac8d9d1ce.1348499997@elijah> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] [PATCH] docs: Document scheduler-related Xen command-line options X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org George Dunlap writes ("[Xen-devel] [PATCH] docs: Document scheduler-related Xen command-line options"): > docs: Document scheduler-related Xen command-line options Committed-by: Ian Jackson Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 16:51:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 16:51:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIjCw-00008q-8b; Mon, 01 Oct 2012 16:51:02 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIjCt-00008l-MO for xen-devel@lists.xensource.com; Mon, 01 Oct 2012 16:50:59 +0000 Received: from [85.158.143.35:11493] by server-2.bemta-4.messagelabs.com id C2/2A-06610-2F9C9605; Mon, 01 Oct 2012 16:50:58 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1349110258!12612135!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI1NjQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32164 invoked from network); 1 Oct 2012 16:50:58 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 16:50:58 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="14876096" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 16:50:06 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 17:50:06 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TIjC2-0002EZ-Fq; Mon, 01 Oct 2012 16:50:06 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TIjC2-0004vu-CA; Mon, 01 Oct 2012 17:50:06 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20585.51646.95260.536197@mariner.uk.xensource.com> Date: Mon, 1 Oct 2012 17:50:06 +0100 To: George Dunlap Newsgroups: chiark.mail.xen.devel In-Reply-To: <7e332fd064fac8d9d1ce.1348499997@elijah> References: <7e332fd064fac8d9d1ce.1348499997@elijah> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] [PATCH] docs: Document scheduler-related Xen command-line options X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org George Dunlap writes ("[Xen-devel] [PATCH] docs: Document scheduler-related Xen command-line options"): > docs: Document scheduler-related Xen command-line options Committed-by: Ian Jackson Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 16:52:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 16:52:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIjDi-0000CI-N5; Mon, 01 Oct 2012 16:51:50 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIjDh-0000C9-8r for xen-devel@lists.xensource.com; Mon, 01 Oct 2012 16:51:49 +0000 Received: from [85.158.143.35:13513] by server-1.bemta-4.messagelabs.com id 25/25-05684-42AC9605; Mon, 01 Oct 2012 16:51:48 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-2.tower-21.messagelabs.com!1349110306!9572385!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI1NjQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10651 invoked from network); 1 Oct 2012 16:51:47 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 16:51:47 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="14876128" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 16:51:43 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 17:51:43 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TIjDb-0002Gf-A5; Mon, 01 Oct 2012 16:51:43 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TIjDb-0004wL-6Q; Mon, 01 Oct 2012 17:51:43 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20585.51743.102094.192480@mariner.uk.xensource.com> Date: Mon, 1 Oct 2012 17:51:43 +0100 To: George Dunlap Newsgroups: chiark.mail.xen.devel In-Reply-To: References: X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] [PATCH] xen: Remove sched_credit_default_yield option X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org George Dunlap writes ("[Xen-devel] [PATCH] xen: Remove sched_credit_default_yield option"): > xen: Remove sched_credit_default_yield option > > The sched_credit_default_yield option was added when the behavior of > "SCHEDOP_yield" was changed in 4.1, to allow any users who had > problems to revert to the old behavior. The new behavior has been in > Xen.org xen since 4.1, and in XenServer even longer, and there is no > evidence of anyone having trouble with it. Remove the option. Who does this need an ack from ? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 16:52:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 16:52:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIjDi-0000CI-N5; Mon, 01 Oct 2012 16:51:50 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIjDh-0000C9-8r for xen-devel@lists.xensource.com; Mon, 01 Oct 2012 16:51:49 +0000 Received: from [85.158.143.35:13513] by server-1.bemta-4.messagelabs.com id 25/25-05684-42AC9605; Mon, 01 Oct 2012 16:51:48 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-2.tower-21.messagelabs.com!1349110306!9572385!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI1NjQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10651 invoked from network); 1 Oct 2012 16:51:47 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 16:51:47 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="14876128" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 16:51:43 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 17:51:43 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TIjDb-0002Gf-A5; Mon, 01 Oct 2012 16:51:43 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TIjDb-0004wL-6Q; Mon, 01 Oct 2012 17:51:43 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20585.51743.102094.192480@mariner.uk.xensource.com> Date: Mon, 1 Oct 2012 17:51:43 +0100 To: George Dunlap Newsgroups: chiark.mail.xen.devel In-Reply-To: References: X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] [PATCH] xen: Remove sched_credit_default_yield option X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org George Dunlap writes ("[Xen-devel] [PATCH] xen: Remove sched_credit_default_yield option"): > xen: Remove sched_credit_default_yield option > > The sched_credit_default_yield option was added when the behavior of > "SCHEDOP_yield" was changed in 4.1, to allow any users who had > problems to revert to the old behavior. The new behavior has been in > Xen.org xen since 4.1, and in XenServer even longer, and there is no > evidence of anyone having trouble with it. Remove the option. Who does this need an ack from ? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 16:54:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 16:54:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIjGB-0000MM-8l; Mon, 01 Oct 2012 16:54:23 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIjG9-0000MA-2y for xen-devel@lists.xen.org; Mon, 01 Oct 2012 16:54:21 +0000 Received: from [85.158.139.211:6896] by server-3.bemta-5.messagelabs.com id 51/F9-16108-CBAC9605; Mon, 01 Oct 2012 16:54:20 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-11.tower-206.messagelabs.com!1349110459!20658817!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI1NjQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16556 invoked from network); 1 Oct 2012 16:54:19 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 16:54:19 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="14876191" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 16:54:19 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 17:54:19 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TIjG6-0002HS-Rs; Mon, 01 Oct 2012 16:54:18 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TIjG6-0004ws-O9; Mon, 01 Oct 2012 17:54:18 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20585.51898.562068.647640@mariner.uk.xensource.com> Date: Mon, 1 Oct 2012 17:54:18 +0100 To: Ian Campbell , "xen-devel@lists.xen.org" Newsgroups: chiark.mail.xen.devel In-Reply-To: <20576.36383.707502.561841@mariner.uk.xensource.com> References: <1348500989-18281-1-git-send-email-ian.campbell@citrix.com> <20576.36383.707502.561841@mariner.uk.xensource.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Subject: Re: [Xen-devel] [PATCH] docs: initial documentation for xenstore paths X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Jackson writes ("Re: [Xen-devel] [PATCH] docs: initial documentation for xenstore paths"): > Ian Campbell writes ("[PATCH] docs: initial documentation for xenstore paths"): > > This is based upon my inspection of a system with a single PV domain > > and a single HVM domain running and is therefore very incomplete. > > Acked-by: Ian Jackson Committed-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 16:54:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 16:54:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIjGB-0000MM-8l; Mon, 01 Oct 2012 16:54:23 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIjG9-0000MA-2y for xen-devel@lists.xen.org; Mon, 01 Oct 2012 16:54:21 +0000 Received: from [85.158.139.211:6896] by server-3.bemta-5.messagelabs.com id 51/F9-16108-CBAC9605; Mon, 01 Oct 2012 16:54:20 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-11.tower-206.messagelabs.com!1349110459!20658817!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI1NjQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16556 invoked from network); 1 Oct 2012 16:54:19 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 16:54:19 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="14876191" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 16:54:19 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 17:54:19 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TIjG6-0002HS-Rs; Mon, 01 Oct 2012 16:54:18 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TIjG6-0004ws-O9; Mon, 01 Oct 2012 17:54:18 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20585.51898.562068.647640@mariner.uk.xensource.com> Date: Mon, 1 Oct 2012 17:54:18 +0100 To: Ian Campbell , "xen-devel@lists.xen.org" Newsgroups: chiark.mail.xen.devel In-Reply-To: <20576.36383.707502.561841@mariner.uk.xensource.com> References: <1348500989-18281-1-git-send-email-ian.campbell@citrix.com> <20576.36383.707502.561841@mariner.uk.xensource.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Subject: Re: [Xen-devel] [PATCH] docs: initial documentation for xenstore paths X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Jackson writes ("Re: [Xen-devel] [PATCH] docs: initial documentation for xenstore paths"): > Ian Campbell writes ("[PATCH] docs: initial documentation for xenstore paths"): > > This is based upon my inspection of a system with a single PV domain > > and a single HVM domain running and is therefore very incomplete. > > Acked-by: Ian Jackson Committed-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 16:54:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 16:54:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIjGN-0000Of-Q7; Mon, 01 Oct 2012 16:54:35 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIjGM-0000O5-9W for xen-devel@lists.xensource.com; Mon, 01 Oct 2012 16:54:34 +0000 Received: from [85.158.137.99:17027] by server-15.bemta-3.messagelabs.com id 04/BC-18313-9CAC9605; Mon, 01 Oct 2012 16:54:33 +0000 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-9.tower-217.messagelabs.com!1349110472!16685881!1 X-Originating-IP: [209.85.215.171] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5014 invoked from network); 1 Oct 2012 16:54:32 -0000 Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com) (209.85.215.171) by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 16:54:32 -0000 Received: by eaak14 with SMTP id k14so1385858eaa.30 for ; Mon, 01 Oct 2012 09:54:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=YKxKmvJsfXfS0fW77TtbOgnj2M4unEx8EZ1NntbAdeE=; b=bNw/tsk2Y/W8GG98af0jqSueKfz+1qR5RlslbkavkxFeFPMZuEjr0rkX9+f9j8OW+I d6F4lLhfInep4vr1xb0jW9jtRAEV8wRZ7hKbWz/8I9U9yaYgoA2470u2hQ4as1wG282f bGGt5TwBvglj+f7Sb10VfoRImDOVrk1ClggtBwFos+MOCDf2V75mBEZOKV5Dh4Db6kxt W3A6uLQ4Ktaf6SOa1cY8Lbhoa2e5snJWy9g02EuIZ0IvOTUEVBYeT7CJSgHXuD3yPTHw jx1EYL0YSpKXoLBlUsCSz/+Gg2KFbyOzLayZEE7onQeHykw/N0VP04NTtiQDrEvDb2vB DQoA== MIME-Version: 1.0 Received: by 10.14.200.134 with SMTP id z6mr16832122een.33.1349110472309; Mon, 01 Oct 2012 09:54:32 -0700 (PDT) Received: by 10.14.215.195 with HTTP; Mon, 1 Oct 2012 09:54:32 -0700 (PDT) In-Reply-To: <20585.51743.102094.192480@mariner.uk.xensource.com> References: <20585.51743.102094.192480@mariner.uk.xensource.com> Date: Mon, 1 Oct 2012 17:54:32 +0100 X-Google-Sender-Auth: UWUcap7AZoX_7K8_5XnfJiT2Nyo Message-ID: From: George Dunlap To: Ian Jackson , Keir Fraser , Jan Beulich Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] [PATCH] xen: Remove sched_credit_default_yield option X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, Oct 1, 2012 at 5:51 PM, Ian Jackson wrote: > George Dunlap writes ("[Xen-devel] [PATCH] xen: Remove sched_credit_default_yield option"): >> xen: Remove sched_credit_default_yield option >> >> The sched_credit_default_yield option was added when the behavior of >> "SCHEDOP_yield" was changed in 4.1, to allow any users who had >> problems to revert to the old behavior. The new behavior has been in >> Xen.org xen since 4.1, and in XenServer even longer, and there is no >> evidence of anyone having trouble with it. Remove the option. > > Who does this need an ack from ? Jan or Keir are the hypervisor committers. Normally Keir asks me for an ack for changes to the scheduler code. :-) -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 16:54:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 16:54:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIjGN-0000Of-Q7; Mon, 01 Oct 2012 16:54:35 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIjGM-0000O5-9W for xen-devel@lists.xensource.com; Mon, 01 Oct 2012 16:54:34 +0000 Received: from [85.158.137.99:17027] by server-15.bemta-3.messagelabs.com id 04/BC-18313-9CAC9605; Mon, 01 Oct 2012 16:54:33 +0000 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-9.tower-217.messagelabs.com!1349110472!16685881!1 X-Originating-IP: [209.85.215.171] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5014 invoked from network); 1 Oct 2012 16:54:32 -0000 Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com) (209.85.215.171) by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 16:54:32 -0000 Received: by eaak14 with SMTP id k14so1385858eaa.30 for ; Mon, 01 Oct 2012 09:54:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=YKxKmvJsfXfS0fW77TtbOgnj2M4unEx8EZ1NntbAdeE=; b=bNw/tsk2Y/W8GG98af0jqSueKfz+1qR5RlslbkavkxFeFPMZuEjr0rkX9+f9j8OW+I d6F4lLhfInep4vr1xb0jW9jtRAEV8wRZ7hKbWz/8I9U9yaYgoA2470u2hQ4as1wG282f bGGt5TwBvglj+f7Sb10VfoRImDOVrk1ClggtBwFos+MOCDf2V75mBEZOKV5Dh4Db6kxt W3A6uLQ4Ktaf6SOa1cY8Lbhoa2e5snJWy9g02EuIZ0IvOTUEVBYeT7CJSgHXuD3yPTHw jx1EYL0YSpKXoLBlUsCSz/+Gg2KFbyOzLayZEE7onQeHykw/N0VP04NTtiQDrEvDb2vB DQoA== MIME-Version: 1.0 Received: by 10.14.200.134 with SMTP id z6mr16832122een.33.1349110472309; Mon, 01 Oct 2012 09:54:32 -0700 (PDT) Received: by 10.14.215.195 with HTTP; Mon, 1 Oct 2012 09:54:32 -0700 (PDT) In-Reply-To: <20585.51743.102094.192480@mariner.uk.xensource.com> References: <20585.51743.102094.192480@mariner.uk.xensource.com> Date: Mon, 1 Oct 2012 17:54:32 +0100 X-Google-Sender-Auth: UWUcap7AZoX_7K8_5XnfJiT2Nyo Message-ID: From: George Dunlap To: Ian Jackson , Keir Fraser , Jan Beulich Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] [PATCH] xen: Remove sched_credit_default_yield option X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, Oct 1, 2012 at 5:51 PM, Ian Jackson wrote: > George Dunlap writes ("[Xen-devel] [PATCH] xen: Remove sched_credit_default_yield option"): >> xen: Remove sched_credit_default_yield option >> >> The sched_credit_default_yield option was added when the behavior of >> "SCHEDOP_yield" was changed in 4.1, to allow any users who had >> problems to revert to the old behavior. The new behavior has been in >> Xen.org xen since 4.1, and in XenServer even longer, and there is no >> evidence of anyone having trouble with it. Remove the option. > > Who does this need an ack from ? Jan or Keir are the hypervisor committers. Normally Keir asks me for an ack for changes to the scheduler code. :-) -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 16:56:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 16:56:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIjHr-0000b3-BT; Mon, 01 Oct 2012 16:56:07 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIjHp-0000aS-Os for xen-devel@lists.xen.org; Mon, 01 Oct 2012 16:56:05 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1349110559!7849706!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI1NjQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14378 invoked from network); 1 Oct 2012 16:55:59 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 16:55:59 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="14876221" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 16:55:42 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 17:55:42 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TIjHS-0002Hu-4E; Mon, 01 Oct 2012 16:55:42 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TIjHR-0004xH-Vi; Mon, 01 Oct 2012 17:55:41 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20585.51980.66172.73036@mariner.uk.xensource.com> Date: Mon, 1 Oct 2012 17:55:40 +0100 To: Paul Durrant Newsgroups: chiark.mail.xen.devel In-Reply-To: <1349108885-18900-2-git-send-email-paul.durrant@citrix.com> References: <1349108885-18900-1-git-send-email-paul.durrant@citrix.com> <1349108885-18900-2-git-send-email-paul.durrant@citrix.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: "Keir \(Xen.org\)" , Jan Beulich , xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as the register of product numbers. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Paul Durrant writes ("[Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as the register of product numbers."): > These product numbers are used by the QEMU blacklisting protocol in > traditional QEMU and are currently coded directly into the xenstore.c > source module. Since there are now multiple QEMUs this information > should be pulled into a public header to avoid duplication/conflict. > hvm-emulated-unplug.markdown has also been adjusted to reference the > new header. Acked-by: Ian Jackson Given the fact this is in a public header, we should probably get an ack from Keir or Jan. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 16:56:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 16:56:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIjHr-0000b3-BT; Mon, 01 Oct 2012 16:56:07 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIjHp-0000aS-Os for xen-devel@lists.xen.org; Mon, 01 Oct 2012 16:56:05 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1349110559!7849706!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI1NjQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14378 invoked from network); 1 Oct 2012 16:55:59 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 16:55:59 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="14876221" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 16:55:42 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 17:55:42 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TIjHS-0002Hu-4E; Mon, 01 Oct 2012 16:55:42 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TIjHR-0004xH-Vi; Mon, 01 Oct 2012 17:55:41 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20585.51980.66172.73036@mariner.uk.xensource.com> Date: Mon, 1 Oct 2012 17:55:40 +0100 To: Paul Durrant Newsgroups: chiark.mail.xen.devel In-Reply-To: <1349108885-18900-2-git-send-email-paul.durrant@citrix.com> References: <1349108885-18900-1-git-send-email-paul.durrant@citrix.com> <1349108885-18900-2-git-send-email-paul.durrant@citrix.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: "Keir \(Xen.org\)" , Jan Beulich , xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as the register of product numbers. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Paul Durrant writes ("[Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as the register of product numbers."): > These product numbers are used by the QEMU blacklisting protocol in > traditional QEMU and are currently coded directly into the xenstore.c > source module. Since there are now multiple QEMUs this information > should be pulled into a public header to avoid duplication/conflict. > hvm-emulated-unplug.markdown has also been adjusted to reference the > new header. Acked-by: Ian Jackson Given the fact this is in a public header, we should probably get an ack from Keir or Jan. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 16:56:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 16:56:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIjHt-0000bX-OU; Mon, 01 Oct 2012 16:56:09 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIjHs-0000ac-Cw for xen-devel@lists.xen.org; Mon, 01 Oct 2012 16:56:08 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1349110559!7849706!2 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI1NjQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14438 invoked from network); 1 Oct 2012 16:56:02 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 16:56:02 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="14876222" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 16:56:02 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 17:56:01 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TIjHl-0002I2-Ns; Mon, 01 Oct 2012 16:56:01 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TIjHl-0004xV-KG; Mon, 01 Oct 2012 17:56:01 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20585.52001.530460.911066@mariner.uk.xensource.com> Date: Mon, 1 Oct 2012 17:56:01 +0100 To: Paul Durrant Newsgroups: chiark.mail.xen.devel In-Reply-To: <1349108885-18900-3-git-send-email-paul.durrant@citrix.com> References: <1349108885-18900-1-git-send-email-paul.durrant@citrix.com> <1349108885-18900-3-git-send-email-paul.durrant@citrix.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH 2/2] Register Linux PV-on-HVM drivers product number. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Paul Durrant writes ("[Xen-devel] [PATCH 2/2] Register Linux PV-on-HVM drivers product number."): > This is already in use despite never being registereed. > See XEN_IOPORT_LINUX_PRODNUM in include/xen/platform_pci.h Very unfortunate. But > Signed-off-by: Paul Durrant Acked-by: Ian Jackson Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 16:56:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 16:56:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIjHt-0000bX-OU; Mon, 01 Oct 2012 16:56:09 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIjHs-0000ac-Cw for xen-devel@lists.xen.org; Mon, 01 Oct 2012 16:56:08 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1349110559!7849706!2 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI1NjQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14438 invoked from network); 1 Oct 2012 16:56:02 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 16:56:02 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="14876222" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 16:56:02 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 17:56:01 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TIjHl-0002I2-Ns; Mon, 01 Oct 2012 16:56:01 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TIjHl-0004xV-KG; Mon, 01 Oct 2012 17:56:01 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20585.52001.530460.911066@mariner.uk.xensource.com> Date: Mon, 1 Oct 2012 17:56:01 +0100 To: Paul Durrant Newsgroups: chiark.mail.xen.devel In-Reply-To: <1349108885-18900-3-git-send-email-paul.durrant@citrix.com> References: <1349108885-18900-1-git-send-email-paul.durrant@citrix.com> <1349108885-18900-3-git-send-email-paul.durrant@citrix.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH 2/2] Register Linux PV-on-HVM drivers product number. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Paul Durrant writes ("[Xen-devel] [PATCH 2/2] Register Linux PV-on-HVM drivers product number."): > This is already in use despite never being registereed. > See XEN_IOPORT_LINUX_PRODNUM in include/xen/platform_pci.h Very unfortunate. But > Signed-off-by: Paul Durrant Acked-by: Ian Jackson Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 17:01:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 17:01:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIjMr-00011r-Ha; Mon, 01 Oct 2012 17:01:17 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIjMq-00011k-8o for xen-devel@lists.xensource.com; Mon, 01 Oct 2012 17:01:16 +0000 Received: from [85.158.139.211:50973] by server-8.bemta-5.messagelabs.com id DC/3F-18073-B5CC9605; Mon, 01 Oct 2012 17:01:15 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-12.tower-206.messagelabs.com!1349110874!19644771!1 X-Originating-IP: [74.125.83.43] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10384 invoked from network); 1 Oct 2012 17:01:14 -0000 Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com) (74.125.83.43) by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 17:01:14 -0000 Received: by eekc13 with SMTP id c13so2512841eek.30 for ; Mon, 01 Oct 2012 10:01:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=oc+TR8tzJgYaed8P8lueQnUBar7kyut++Q6VwLKc1fI=; b=fw3JTDqCgKMakVyVyaA15WGHF7s6aCgOUSWpLNGVbTNIIxqoSao3EmQgCpKYTGxaMg 7P8YlWq5nIun0ONwxF/xQoKKUOXRdKJcsnWofyc78F3OvSYQkEgfj3dm4vr3cPvWHNuv nBtbmPZP/jF/iOOg2K26EYux9cqhYk7X5pz1AgPtMNRsWv1JkjCx0Ci/eCdlCZZ6qyNd +mmS8J1l5lhHSNw47fDahYbnWc24vTInm8qYhqgu7BfYT3is7t3p6ryroXdeZh2Fw0ao BSa0OhzWc+olJatHnYZLkj7NAZRpldebnbDiX+FyJN1L80WtqFIHGkyUXDv1H1J7WyHH h03w== Received: by 10.14.221.197 with SMTP id r45mr18997800eep.41.1349110874109; Mon, 01 Oct 2012 10:01:14 -0700 (PDT) Received: from [192.168.1.69] (host86-183-156-141.range86-183.btcentralplus.com. [86.183.156.141]) by mx.google.com with ESMTPS id z3sm49396136eel.15.2012.10.01.10.01.11 (version=SSLv3 cipher=OTHER); Mon, 01 Oct 2012 10:01:13 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Mon, 01 Oct 2012 18:01:09 +0100 From: Keir Fraser To: George Dunlap , Ian Jackson , Jan Beulich Message-ID: Thread-Topic: [Xen-devel] [PATCH] xen: Remove sched_credit_default_yield option Thread-Index: Ac2f9lpWJedfz1S0GUqHvNv2jz62vA== In-Reply-To: Mime-version: 1.0 Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] [PATCH] xen: Remove sched_credit_default_yield option X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 01/10/2012 17:54, "George Dunlap" wrote: > On Mon, Oct 1, 2012 at 5:51 PM, Ian Jackson wrote: >> George Dunlap writes ("[Xen-devel] [PATCH] xen: Remove >> sched_credit_default_yield option"): >>> xen: Remove sched_credit_default_yield option >>> >>> The sched_credit_default_yield option was added when the behavior of >>> "SCHEDOP_yield" was changed in 4.1, to allow any users who had >>> problems to revert to the old behavior. The new behavior has been in >>> Xen.org xen since 4.1, and in XenServer even longer, and there is no >>> evidence of anyone having trouble with it. Remove the option. >> >> Who does this need an ack from ? > > Jan or Keir are the hypervisor committers. Normally Keir asks me for > an ack for changes to the scheduler code. :-) I will apply it. :) -- Keir > -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 17:01:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 17:01:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIjMr-00011r-Ha; Mon, 01 Oct 2012 17:01:17 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIjMq-00011k-8o for xen-devel@lists.xensource.com; Mon, 01 Oct 2012 17:01:16 +0000 Received: from [85.158.139.211:50973] by server-8.bemta-5.messagelabs.com id DC/3F-18073-B5CC9605; Mon, 01 Oct 2012 17:01:15 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-12.tower-206.messagelabs.com!1349110874!19644771!1 X-Originating-IP: [74.125.83.43] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10384 invoked from network); 1 Oct 2012 17:01:14 -0000 Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com) (74.125.83.43) by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 17:01:14 -0000 Received: by eekc13 with SMTP id c13so2512841eek.30 for ; Mon, 01 Oct 2012 10:01:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=oc+TR8tzJgYaed8P8lueQnUBar7kyut++Q6VwLKc1fI=; b=fw3JTDqCgKMakVyVyaA15WGHF7s6aCgOUSWpLNGVbTNIIxqoSao3EmQgCpKYTGxaMg 7P8YlWq5nIun0ONwxF/xQoKKUOXRdKJcsnWofyc78F3OvSYQkEgfj3dm4vr3cPvWHNuv nBtbmPZP/jF/iOOg2K26EYux9cqhYk7X5pz1AgPtMNRsWv1JkjCx0Ci/eCdlCZZ6qyNd +mmS8J1l5lhHSNw47fDahYbnWc24vTInm8qYhqgu7BfYT3is7t3p6ryroXdeZh2Fw0ao BSa0OhzWc+olJatHnYZLkj7NAZRpldebnbDiX+FyJN1L80WtqFIHGkyUXDv1H1J7WyHH h03w== Received: by 10.14.221.197 with SMTP id r45mr18997800eep.41.1349110874109; Mon, 01 Oct 2012 10:01:14 -0700 (PDT) Received: from [192.168.1.69] (host86-183-156-141.range86-183.btcentralplus.com. [86.183.156.141]) by mx.google.com with ESMTPS id z3sm49396136eel.15.2012.10.01.10.01.11 (version=SSLv3 cipher=OTHER); Mon, 01 Oct 2012 10:01:13 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Mon, 01 Oct 2012 18:01:09 +0100 From: Keir Fraser To: George Dunlap , Ian Jackson , Jan Beulich Message-ID: Thread-Topic: [Xen-devel] [PATCH] xen: Remove sched_credit_default_yield option Thread-Index: Ac2f9lpWJedfz1S0GUqHvNv2jz62vA== In-Reply-To: Mime-version: 1.0 Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] [PATCH] xen: Remove sched_credit_default_yield option X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 01/10/2012 17:54, "George Dunlap" wrote: > On Mon, Oct 1, 2012 at 5:51 PM, Ian Jackson wrote: >> George Dunlap writes ("[Xen-devel] [PATCH] xen: Remove >> sched_credit_default_yield option"): >>> xen: Remove sched_credit_default_yield option >>> >>> The sched_credit_default_yield option was added when the behavior of >>> "SCHEDOP_yield" was changed in 4.1, to allow any users who had >>> problems to revert to the old behavior. The new behavior has been in >>> Xen.org xen since 4.1, and in XenServer even longer, and there is no >>> evidence of anyone having trouble with it. Remove the option. >> >> Who does this need an ack from ? > > Jan or Keir are the hypervisor committers. Normally Keir asks me for > an ack for changes to the scheduler code. :-) I will apply it. :) -- Keir > -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 17:02:05 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 17:02:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIjNU-00014s-1G; Mon, 01 Oct 2012 17:01:56 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIjNS-00014V-Fv for xen-devel@lists.xen.org; Mon, 01 Oct 2012 17:01:54 +0000 X-Env-Sender: ikozhukhov@gmail.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1349110907!9334769!1 X-Originating-IP: [209.85.215.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1920 invoked from network); 1 Oct 2012 17:01:48 -0000 Received: from mail-la0-f45.google.com (HELO mail-la0-f45.google.com) (209.85.215.45) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 17:01:48 -0000 Received: by lahm13 with SMTP id m13so2447897lah.32 for ; Mon, 01 Oct 2012 10:01:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding; bh=yO0CdjyxOXlXxGaXvk6vB2JLM8JucO5mgMppjM4k8iA=; b=LHpggnBq+sEswO0F8PAg+UBK9JxihallqFWFRnWViL84/y5HjJEUWsOIuvJcDd2hfM dXPN1PDQqKkbGzHjZCLOghStKA5ko/5AWyI1tlAimPd4TMy/FuWu8YAqVEu+Fe35i9rx dCqmxNSffS847VqJD0Q459gvOwiZbISfHrbSQsWI32858vch+0/mW19Ee5RUWFr93lAk qASixJkoT2UBBMgnJH9d4ZJQvYzEMhXeo7WZOur2KPCM/M1/fT4VExR3sIpJFz5LSajy iPrn9hv+UpdQ0cf/NFzuTDTJgGtUw066P9Ff1p0xOdpp23FixY/IJ1cXxlkCVU/tKtPz FhBg== Received: by 10.112.51.195 with SMTP id m3mr5502256lbo.17.1349110907652; Mon, 01 Oct 2012 10:01:47 -0700 (PDT) Received: from [172.16.90.16] ([91.204.58.44]) by mx.google.com with ESMTPS id tb8sm4762013lab.4.2012.10.01.10.01.40 (version=SSLv3 cipher=OTHER); Mon, 01 Oct 2012 10:01:46 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Mon, 01 Oct 2012 21:01:37 +0400 From: Igor Kozhukhov To: Pasi =?ISO-8859-1?B?S+Rya2vkaW5lbg==?= , George Dunlap Message-ID: Thread-Topic: [Xen-devel] Xen 4.3 development update In-Reply-To: <20121001164239.GE8912@reaktio.net> Mime-version: 1.0 Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.3 development update X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org And maybe add: * try to port xen-4.3 to illumos-based platform :) I have some progress - but have panic. --- Best regards, Igor Kozhukhov IRC# igork On 10/1/12 8:42 PM, "Pasi K=E4rkk=E4inen" wrote: >On Mon, Oct 01, 2012 at 05:25:43PM +0100, George Dunlap wrote: >> = >> * xl USB pass-through for PV guests >> owner: ? >> status: ? >> - Port the xend PV pass-through functionality to xl. >> - Make sure qemu-based USB with qemu-upstream works >> - Upstream the Linux frontend/backend drivers >> = > >I think this should be split into two separate tasks: > > * xl PVUSB pass-through for both PV and HVM guests > owner: ? = > status: ? = > - xm/xend supports PVUSB pass-through to guests with PVUSB drivers >(both PV and HVM guests). > - port the xm/xend functionality to xl. > - this PVUSB feature does not require support or emulation from Qemu. > - upstream the Linux frontend/backend drivers. Current >work-in-progress versions are in Konrad's git tree. > - James Harper's GPLPV drivers for Windows include PVUSB frontend >drivers. > > * xl USB pass-through for HVM guests using Qemu USB emulation > owner: ? = > status: ? > - xm/xend with qemu-traditional supports USB passthrough to HVM guests >using the Qemu emulated USB controller. > - port the xm/xend functionality to xl. > - make sure USB passthrough with xl works with both qemu-traditional >and qemu-upstream. > - The HVM guest does not need any special drivers for this feature. > > >-- Pasi > > >_______________________________________________ >Xen-devel mailing list >Xen-devel@lists.xen.org >http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 17:02:05 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 17:02:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIjNU-00014s-1G; Mon, 01 Oct 2012 17:01:56 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIjNS-00014V-Fv for xen-devel@lists.xen.org; Mon, 01 Oct 2012 17:01:54 +0000 X-Env-Sender: ikozhukhov@gmail.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1349110907!9334769!1 X-Originating-IP: [209.85.215.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1920 invoked from network); 1 Oct 2012 17:01:48 -0000 Received: from mail-la0-f45.google.com (HELO mail-la0-f45.google.com) (209.85.215.45) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 17:01:48 -0000 Received: by lahm13 with SMTP id m13so2447897lah.32 for ; Mon, 01 Oct 2012 10:01:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding; bh=yO0CdjyxOXlXxGaXvk6vB2JLM8JucO5mgMppjM4k8iA=; b=LHpggnBq+sEswO0F8PAg+UBK9JxihallqFWFRnWViL84/y5HjJEUWsOIuvJcDd2hfM dXPN1PDQqKkbGzHjZCLOghStKA5ko/5AWyI1tlAimPd4TMy/FuWu8YAqVEu+Fe35i9rx dCqmxNSffS847VqJD0Q459gvOwiZbISfHrbSQsWI32858vch+0/mW19Ee5RUWFr93lAk qASixJkoT2UBBMgnJH9d4ZJQvYzEMhXeo7WZOur2KPCM/M1/fT4VExR3sIpJFz5LSajy iPrn9hv+UpdQ0cf/NFzuTDTJgGtUw066P9Ff1p0xOdpp23FixY/IJ1cXxlkCVU/tKtPz FhBg== Received: by 10.112.51.195 with SMTP id m3mr5502256lbo.17.1349110907652; Mon, 01 Oct 2012 10:01:47 -0700 (PDT) Received: from [172.16.90.16] ([91.204.58.44]) by mx.google.com with ESMTPS id tb8sm4762013lab.4.2012.10.01.10.01.40 (version=SSLv3 cipher=OTHER); Mon, 01 Oct 2012 10:01:46 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Mon, 01 Oct 2012 21:01:37 +0400 From: Igor Kozhukhov To: Pasi =?ISO-8859-1?B?S+Rya2vkaW5lbg==?= , George Dunlap Message-ID: Thread-Topic: [Xen-devel] Xen 4.3 development update In-Reply-To: <20121001164239.GE8912@reaktio.net> Mime-version: 1.0 Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.3 development update X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org And maybe add: * try to port xen-4.3 to illumos-based platform :) I have some progress - but have panic. --- Best regards, Igor Kozhukhov IRC# igork On 10/1/12 8:42 PM, "Pasi K=E4rkk=E4inen" wrote: >On Mon, Oct 01, 2012 at 05:25:43PM +0100, George Dunlap wrote: >> = >> * xl USB pass-through for PV guests >> owner: ? >> status: ? >> - Port the xend PV pass-through functionality to xl. >> - Make sure qemu-based USB with qemu-upstream works >> - Upstream the Linux frontend/backend drivers >> = > >I think this should be split into two separate tasks: > > * xl PVUSB pass-through for both PV and HVM guests > owner: ? = > status: ? = > - xm/xend supports PVUSB pass-through to guests with PVUSB drivers >(both PV and HVM guests). > - port the xm/xend functionality to xl. > - this PVUSB feature does not require support or emulation from Qemu. > - upstream the Linux frontend/backend drivers. Current >work-in-progress versions are in Konrad's git tree. > - James Harper's GPLPV drivers for Windows include PVUSB frontend >drivers. > > * xl USB pass-through for HVM guests using Qemu USB emulation > owner: ? = > status: ? > - xm/xend with qemu-traditional supports USB passthrough to HVM guests >using the Qemu emulated USB controller. > - port the xm/xend functionality to xl. > - make sure USB passthrough with xl works with both qemu-traditional >and qemu-upstream. > - The HVM guest does not need any special drivers for this feature. > > >-- Pasi > > >_______________________________________________ >Xen-devel mailing list >Xen-devel@lists.xen.org >http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 17:19:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 17:19:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIjeQ-0001eG-VA; Mon, 01 Oct 2012 17:19:26 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIjeO-0001e9-OD for xen-devel@lists.xensource.com; Mon, 01 Oct 2012 17:19:24 +0000 Received: from [85.158.139.83:38719] by server-7.bemta-5.messagelabs.com id D4/9F-00431-B90D9605; Mon, 01 Oct 2012 17:19:23 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1349111961!32743245!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzkwMjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4490 invoked from network); 1 Oct 2012 17:19:23 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 17:19:23 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="209912237" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 17:19:21 +0000 Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 13:19:21 -0400 Message-ID: <5069D097.60606@citrix.com> Date: Mon, 1 Oct 2012 18:19:19 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120428 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: David Vrabel References: <1348243464-15903-1-git-send-email-david.vrabel@citrix.com> <1348243464-15903-3-git-send-email-david.vrabel@citrix.com> <5061EFB2.1080407@citrix.com> In-Reply-To: <5061EFB2.1080407@citrix.com> Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 2/6] xen-blkfront: handle backend CLOSED without CLOSING X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 25/09/12 18:53, David Vrabel wrote: > On 21/09/12 17:04, David Vrabel wrote: >> From: David Vrabel >> >> Backend drivers shouldn't transistion to CLOSED unless the frontend is >> CLOSED. If a backend does transition to CLOSED too soon then the >> frontend may not see the CLOSING state and will not properly shutdown. >> >> So, treat an unexpected backend CLOSED state the same as CLOSING. > > Didn't handle the frontend block device being mounted. Updated patch here. Konrad, can you ack this updated patch if you're happy with it. Thanks. David > 8<--------------------------------- > xen-blkfront: handle backend CLOSED without CLOSING > > Backend drivers shouldn't transistion to CLOSED unless the frontend is > CLOSED. If a backend does transition to CLOSED too soon then the > frontend may not see the CLOSING state and will not properly shutdown. > > So, treat an unexpected backend CLOSED state the same as CLOSING. > > If the backend is CLOSED then the frontend can't talk to it so go to > CLOSED immediately without waiting for the block device to be closed > or unmounted. > > Signed-off-by: David Vrabel > --- > drivers/block/xen-blkfront.c | 13 +++++++++---- > 1 files changed, 9 insertions(+), 4 deletions(-) > > diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c > index 2c2d2e5..c1f5f38 100644 > --- a/drivers/block/xen-blkfront.c > +++ b/drivers/block/xen-blkfront.c > @@ -1143,7 +1143,8 @@ static int blkfront_resume(struct xenbus_device *dev) > } > > static void > -blkfront_closing(struct blkfront_info *info) > +blkfront_closing(struct blkfront_info *info, > + enum xenbus_state backend_state) > { > struct xenbus_device *xbdev = info->xbdev; > struct block_device *bdev = NULL; > @@ -1167,7 +1168,8 @@ blkfront_closing(struct blkfront_info *info) > > mutex_lock(&bdev->bd_mutex); > > - if (bdev->bd_openers) { > + /* If the backend is already CLOSED, close now. */ > + if (bdev->bd_openers && backend_state != XenbusStateClosed) { > xenbus_dev_error(xbdev, -EBUSY, > "Device in use; refusing to close"); > xenbus_switch_state(xbdev, XenbusStateClosing); > @@ -1340,15 +1342,18 @@ static void blkback_changed(struct xenbus_device *dev, > case XenbusStateReconfiguring: > case XenbusStateReconfigured: > case XenbusStateUnknown: > - case XenbusStateClosed: > break; > > case XenbusStateConnected: > blkfront_connect(info); > break; > > + case XenbusStateClosed: > + if (dev->state == XenbusStateClosed) > + break; > + /* Missed the backend's Closing state -- fallthrough */ > case XenbusStateClosing: > - blkfront_closing(info); > + blkfront_closing(info, backend_state); > break; > } > } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 17:19:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 17:19:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIjeQ-0001eG-VA; Mon, 01 Oct 2012 17:19:26 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIjeO-0001e9-OD for xen-devel@lists.xensource.com; Mon, 01 Oct 2012 17:19:24 +0000 Received: from [85.158.139.83:38719] by server-7.bemta-5.messagelabs.com id D4/9F-00431-B90D9605; Mon, 01 Oct 2012 17:19:23 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1349111961!32743245!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzkwMjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4490 invoked from network); 1 Oct 2012 17:19:23 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 17:19:23 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="209912237" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 17:19:21 +0000 Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 13:19:21 -0400 Message-ID: <5069D097.60606@citrix.com> Date: Mon, 1 Oct 2012 18:19:19 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120428 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: David Vrabel References: <1348243464-15903-1-git-send-email-david.vrabel@citrix.com> <1348243464-15903-3-git-send-email-david.vrabel@citrix.com> <5061EFB2.1080407@citrix.com> In-Reply-To: <5061EFB2.1080407@citrix.com> Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 2/6] xen-blkfront: handle backend CLOSED without CLOSING X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 25/09/12 18:53, David Vrabel wrote: > On 21/09/12 17:04, David Vrabel wrote: >> From: David Vrabel >> >> Backend drivers shouldn't transistion to CLOSED unless the frontend is >> CLOSED. If a backend does transition to CLOSED too soon then the >> frontend may not see the CLOSING state and will not properly shutdown. >> >> So, treat an unexpected backend CLOSED state the same as CLOSING. > > Didn't handle the frontend block device being mounted. Updated patch here. Konrad, can you ack this updated patch if you're happy with it. Thanks. David > 8<--------------------------------- > xen-blkfront: handle backend CLOSED without CLOSING > > Backend drivers shouldn't transistion to CLOSED unless the frontend is > CLOSED. If a backend does transition to CLOSED too soon then the > frontend may not see the CLOSING state and will not properly shutdown. > > So, treat an unexpected backend CLOSED state the same as CLOSING. > > If the backend is CLOSED then the frontend can't talk to it so go to > CLOSED immediately without waiting for the block device to be closed > or unmounted. > > Signed-off-by: David Vrabel > --- > drivers/block/xen-blkfront.c | 13 +++++++++---- > 1 files changed, 9 insertions(+), 4 deletions(-) > > diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c > index 2c2d2e5..c1f5f38 100644 > --- a/drivers/block/xen-blkfront.c > +++ b/drivers/block/xen-blkfront.c > @@ -1143,7 +1143,8 @@ static int blkfront_resume(struct xenbus_device *dev) > } > > static void > -blkfront_closing(struct blkfront_info *info) > +blkfront_closing(struct blkfront_info *info, > + enum xenbus_state backend_state) > { > struct xenbus_device *xbdev = info->xbdev; > struct block_device *bdev = NULL; > @@ -1167,7 +1168,8 @@ blkfront_closing(struct blkfront_info *info) > > mutex_lock(&bdev->bd_mutex); > > - if (bdev->bd_openers) { > + /* If the backend is already CLOSED, close now. */ > + if (bdev->bd_openers && backend_state != XenbusStateClosed) { > xenbus_dev_error(xbdev, -EBUSY, > "Device in use; refusing to close"); > xenbus_switch_state(xbdev, XenbusStateClosing); > @@ -1340,15 +1342,18 @@ static void blkback_changed(struct xenbus_device *dev, > case XenbusStateReconfiguring: > case XenbusStateReconfigured: > case XenbusStateUnknown: > - case XenbusStateClosed: > break; > > case XenbusStateConnected: > blkfront_connect(info); > break; > > + case XenbusStateClosed: > + if (dev->state == XenbusStateClosed) > + break; > + /* Missed the backend's Closing state -- fallthrough */ > case XenbusStateClosing: > - blkfront_closing(info); > + blkfront_closing(info, backend_state); > break; > } > } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 17:34:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 17:34:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIjsT-00029d-5x; Mon, 01 Oct 2012 17:33:57 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIjsR-00029X-7V for xen-devel@lists.xen.org; Mon, 01 Oct 2012 17:33:55 +0000 X-Env-Sender: daniel.kiper@oracle.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1349112827!13032173!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzc0OTkw\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16598 invoked from network); 1 Oct 2012 17:33:48 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 17:33:48 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q91HXiLk016852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Oct 2012 17:33:45 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q91HXhgv001119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Oct 2012 17:33:44 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q91HXg9S006992; Mon, 1 Oct 2012 12:33:42 -0500 Received: from host-192-168-1-59.local.net-space.pl (/89.174.63.77) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 01 Oct 2012 10:33:42 -0700 Date: Mon, 1 Oct 2012 19:33:30 +0200 From: Daniel Kiper To: Jan Beulich Message-ID: <20121001173330.GA3120@host-192-168-1-59.local.net-space.pl> References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-2-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-3-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-4-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-5-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-6-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-7-git-send-email-daniel.kiper@oracle.com> <506577E3020000780009E65B@nat28.tlf.novell.com> <20121001125252.GB2942@host-192-168-1-59.local.net-space.pl> <5069BCD5020000780009EC7D@nat28.tlf.novell.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <5069BCD5020000780009EC7D@nat28.tlf.novell.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: andrew.cooper3@citrix.com, konrad.wilk@oracle.com, linux-kernel@vger.kernel.org, xen-devel Subject: Re: [Xen-devel] [PATCH 06/11] x86/xen: Add i386 kexec/kdump implementation X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, Oct 01, 2012 at 02:55:01PM +0100, Jan Beulich wrote: > >>> On 01.10.12 at 14:52, Daniel Kiper wrote: > > On Fri, Sep 28, 2012 at 09:11:47AM +0100, Jan Beulich wrote: > >> Finally, as noticed in an earlier patch already, you appear to > >> re-introduce stuff long dropped from the kernel - the forward > >> ported kernels get away with just setting PA_CONTROL_PAGE, > >> PA_PGD, and PA_SWAP_PAGE in the page list. Since the number > >> and purpose of the pages is established entirely by the guest > >> kernel, all you need to obey is that the hypervisor expects > >> alternating PA_/VA_ pairs (where the VA_ ones can be left > >> unpopulated). Perhaps taking a look at a recent SLES kernel > >> would help... > > > > I have got ftp://ftp.suse.com/pub/projects/kernel/kotd/SLE11-SP2/src/kernel-source-3.0.43-6.1.src.rpm. > > Does kexec/kdump work in your environment? In my it does not. > > While I never ran it myself, I know kdump has been working on > SLE for quite a long while (leaving aside hardware or firmware > quirks requiring extra workarounds). It should work on baremetal without any issue. However, I am almost sure that it does not work on Xen dom0 in any way. But maybe I missed something. > > At least there is wrong assumption that > > vaddr = (unsigned long)relocate_kernel > > gets virtual address of relocate_kernel in Xen > > Where did you spot that? Afaics the only thing done with > relocate_kernel is that it gets copied into the control page. arch/x86/kernel/machine_kexec_64.c:270 There is also similar thing in i386 code. > > (I have tested only x86_64 implementation but > > as I saw i386 has similar problem). In real it is > > fix mapped in hypervisor which is completely > > different than address calculated in dom0 kernel. > > Virtual address of control page (and others) is > > only known by hypervisor kexec/kdump functions. > > It means that transition page table could be > > established by relocate_kernel code only. > > If you would like to do optimistation as you > > mentioned above you must reintroduce code > > for page table establishment into generic > > relocate_kernel_??.S. However, another > > problem arises. New generic code utilizes > > additional arguments such as swap page > > (and potentially could use others in the future). > > As I saw it is not possible to pass extra addresses > > through page_list[] in struct xen_kexec_image > > because its has insufficient size (I mean > > x86_64 because i386 is a bit different story). > > No - there's no meaning assigned by Xen to any of the slots, > except for said assumption about them representing alternating I know that. > PA_/VA_ pairs. Hence, as long as old entries get removed, new > slots can easily be added (and the number of slots currently > needed is far lower than what was used originally [2.6.18]). As I said in other email I will try to optimize page table code. We will see what could be done. Daniel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 17:34:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 17:34:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIjsT-00029d-5x; Mon, 01 Oct 2012 17:33:57 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIjsR-00029X-7V for xen-devel@lists.xen.org; Mon, 01 Oct 2012 17:33:55 +0000 X-Env-Sender: daniel.kiper@oracle.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1349112827!13032173!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzc0OTkw\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16598 invoked from network); 1 Oct 2012 17:33:48 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 17:33:48 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q91HXiLk016852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Oct 2012 17:33:45 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q91HXhgv001119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Oct 2012 17:33:44 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q91HXg9S006992; Mon, 1 Oct 2012 12:33:42 -0500 Received: from host-192-168-1-59.local.net-space.pl (/89.174.63.77) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 01 Oct 2012 10:33:42 -0700 Date: Mon, 1 Oct 2012 19:33:30 +0200 From: Daniel Kiper To: Jan Beulich Message-ID: <20121001173330.GA3120@host-192-168-1-59.local.net-space.pl> References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-2-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-3-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-4-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-5-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-6-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-7-git-send-email-daniel.kiper@oracle.com> <506577E3020000780009E65B@nat28.tlf.novell.com> <20121001125252.GB2942@host-192-168-1-59.local.net-space.pl> <5069BCD5020000780009EC7D@nat28.tlf.novell.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <5069BCD5020000780009EC7D@nat28.tlf.novell.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: andrew.cooper3@citrix.com, konrad.wilk@oracle.com, linux-kernel@vger.kernel.org, xen-devel Subject: Re: [Xen-devel] [PATCH 06/11] x86/xen: Add i386 kexec/kdump implementation X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, Oct 01, 2012 at 02:55:01PM +0100, Jan Beulich wrote: > >>> On 01.10.12 at 14:52, Daniel Kiper wrote: > > On Fri, Sep 28, 2012 at 09:11:47AM +0100, Jan Beulich wrote: > >> Finally, as noticed in an earlier patch already, you appear to > >> re-introduce stuff long dropped from the kernel - the forward > >> ported kernels get away with just setting PA_CONTROL_PAGE, > >> PA_PGD, and PA_SWAP_PAGE in the page list. Since the number > >> and purpose of the pages is established entirely by the guest > >> kernel, all you need to obey is that the hypervisor expects > >> alternating PA_/VA_ pairs (where the VA_ ones can be left > >> unpopulated). Perhaps taking a look at a recent SLES kernel > >> would help... > > > > I have got ftp://ftp.suse.com/pub/projects/kernel/kotd/SLE11-SP2/src/kernel-source-3.0.43-6.1.src.rpm. > > Does kexec/kdump work in your environment? In my it does not. > > While I never ran it myself, I know kdump has been working on > SLE for quite a long while (leaving aside hardware or firmware > quirks requiring extra workarounds). It should work on baremetal without any issue. However, I am almost sure that it does not work on Xen dom0 in any way. But maybe I missed something. > > At least there is wrong assumption that > > vaddr = (unsigned long)relocate_kernel > > gets virtual address of relocate_kernel in Xen > > Where did you spot that? Afaics the only thing done with > relocate_kernel is that it gets copied into the control page. arch/x86/kernel/machine_kexec_64.c:270 There is also similar thing in i386 code. > > (I have tested only x86_64 implementation but > > as I saw i386 has similar problem). In real it is > > fix mapped in hypervisor which is completely > > different than address calculated in dom0 kernel. > > Virtual address of control page (and others) is > > only known by hypervisor kexec/kdump functions. > > It means that transition page table could be > > established by relocate_kernel code only. > > If you would like to do optimistation as you > > mentioned above you must reintroduce code > > for page table establishment into generic > > relocate_kernel_??.S. However, another > > problem arises. New generic code utilizes > > additional arguments such as swap page > > (and potentially could use others in the future). > > As I saw it is not possible to pass extra addresses > > through page_list[] in struct xen_kexec_image > > because its has insufficient size (I mean > > x86_64 because i386 is a bit different story). > > No - there's no meaning assigned by Xen to any of the slots, > except for said assumption about them representing alternating I know that. > PA_/VA_ pairs. Hence, as long as old entries get removed, new > slots can easily be added (and the number of slots currently > needed is far lower than what was used originally [2.6.18]). As I said in other email I will try to optimize page table code. We will see what could be done. Daniel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 17:47:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 17:47:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIk5T-0002OJ-BG; Mon, 01 Oct 2012 17:47:23 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIk5R-0002Nn-LT for xen-devel@lists.xensource.com; Mon, 01 Oct 2012 17:47:21 +0000 Received: from [85.158.139.211:34689] by server-3.bemta-5.messagelabs.com id D2/29-16108-827D9605; Mon, 01 Oct 2012 17:47:20 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-13.tower-206.messagelabs.com!1349113638!16676780!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzkwMjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18690 invoked from network); 1 Oct 2012 17:47:20 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 17:47:20 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="209915478" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 17:47:17 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 13:47:17 -0400 Received: from qabil.uk.xensource.com ([10.80.2.76]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TIk5M-0007qB-Q2; Mon, 01 Oct 2012 18:47:16 +0100 From: David Vrabel To: xen-devel@lists.xensource.com Date: Mon, 1 Oct 2012 18:47:07 +0100 Message-ID: <1349113629-6338-2-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1349113629-6338-1-git-send-email-david.vrabel@citrix.com> References: <1349113629-6338-1-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Cc: Frediano Ziglio , David Vrabel Subject: [Xen-devel] [PATCH 1/3] trace: allow for different sub-classes of TRC_PV_* tracepoints X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: David Vrabel We want to add additional sub-classes for TRC_PV tracepoints and to be able to only capture these new sub-classes. This cannot currently be done as the existing tracepoints all use a sub-class of 0xf. So, redefine the PV events to use a new sub-class. All the current tracepoints are tracing entry points to the hypervisor so the sub-class is named TRC_PV_ENTRY. This change does not affect xenalyze as that only looks at the main class and the event number and does not use the sub-class field. Signed-off-by: Frediano Ziglio Signed-off-by: David Vrabel Acked-by: George Dunlap --- tools/xentrace/formats | 44 ++++++++++++++++++++++---------------------- xen/include/public/trace.h | 35 +++++++++++++++++++++-------------- 2 files changed, 43 insertions(+), 36 deletions(-) diff --git a/tools/xentrace/formats b/tools/xentrace/formats index 04e54d5..71220c0 100644 --- a/tools/xentrace/formats +++ b/tools/xentrace/formats @@ -82,28 +82,28 @@ 0x0010f002 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) page_grant_unmap [ domid = %(1)d ] 0x0010f003 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) page_grant_transfer [ domid = %(1)d ] -0x0020f001 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) hypercall [ eip = 0x%(1)08x, eax = 0x%(2)08x ] -0x0020f101 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) hypercall [ rip = 0x%(2)08x%(1)08x, eax = 0x%(3)08x ] -0x0020f003 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) trap [ eip = 0x%(1)08x, trapnr:error = 0x%(2)08x ] -0x0020f103 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) trap [ rip = 0x%(2)08x%(1)08x, trapnr:error = 0x%(3)08x ] -0x0020f004 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) page_fault [ eip = 0x%(1)08x, addr = 0x%(2)08x, error = 0x%(3)08x ] -0x0020f104 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) page_fault [ rip = 0x%(2)08x%(1)08x, addr = 0x%(4)08x%(3)08x, error = 0x%(5)08x ] -0x0020f005 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) forced_invalid_op [ eip = 0x%(1)08x ] -0x0020f105 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) forced_invalid_op [ rip = 0x%(2)08x%(1)08x ] -0x0020f006 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) emulate_privop [ eip = 0x%(1)08x ] -0x0020f106 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) emulate_privop [ rip = 0x%(2)08x%(1)08x ] -0x0020f007 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) emulate_4G [ eip = 0x%(1)08x ] -0x0020f107 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) emulate_4G [ rip = 0x%(2)08x%(1)08x ] -0x0020f008 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) math_state_restore -0x0020f108 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) math_state_restore -0x0020f009 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) paging_fixup [ eip = 0x%(1)08x, addr = 0x%(2)08x ] -0x0020f109 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) paging_fixup [ rip = 0x%(2)08x%(1)08x, addr = 0x%(4)08x%(3)08x ] -0x0020f00a CPU%(cpu)d %(tsc)d (+%(reltsc)8d) gdt_ldt_mapping_fault [ eip = 0x%(1)08x, offset = 0x%(2)08x ] -0x0020f10a CPU%(cpu)d %(tsc)d (+%(reltsc)8d) gdt_ldt_mapping_fault [ rip = 0x%(2)08x%(1)08x, offset = 0x%(4)08x%(3)08x ] -0x0020f00b CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation [ addr = 0x%(3)08x, eip = 0x%(4)08x, npte = 0x%(2)08x%(1)08x ] -0x0020f10b CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation [ addr = 0x%(4)08x%(3)08x, rip = 0x%(6)08x%(5)08x, npte = 0x%(2)08x%(1)08x ] -0x0020f00c CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation_pae [ addr = 0x%(3)08x, eip = 0x%(4)08x, npte = 0x%(2)08x%(1)08x ] -0x0020f10c CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation_pae [ addr = 0x%(4)08x%(3)08x, rip = 0x%(6)08x%(5)08x, npte = 0x%(2)08x%(1)08x ] +0x00201001 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) hypercall [ eip = 0x%(1)08x, eax = 0x%(2)08x ] +0x00201101 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) hypercall [ rip = 0x%(2)08x%(1)08x, eax = 0x%(3)08x ] +0x00201003 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) trap [ eip = 0x%(1)08x, trapnr:error = 0x%(2)08x ] +0x00201103 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) trap [ rip = 0x%(2)08x%(1)08x, trapnr:error = 0x%(3)08x ] +0x00201004 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) page_fault [ eip = 0x%(1)08x, addr = 0x%(2)08x, error = 0x%(3)08x ] +0x00201104 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) page_fault [ rip = 0x%(2)08x%(1)08x, addr = 0x%(4)08x%(3)08x, error = 0x%(5)08x ] +0x00201005 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) forced_invalid_op [ eip = 0x%(1)08x ] +0x00201105 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) forced_invalid_op [ rip = 0x%(2)08x%(1)08x ] +0x00201006 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) emulate_privop [ eip = 0x%(1)08x ] +0x00201106 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) emulate_privop [ rip = 0x%(2)08x%(1)08x ] +0x00201007 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) emulate_4G [ eip = 0x%(1)08x ] +0x00201107 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) emulate_4G [ rip = 0x%(2)08x%(1)08x ] +0x00201008 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) math_state_restore +0x00201108 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) math_state_restore +0x00201009 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) paging_fixup [ eip = 0x%(1)08x, addr = 0x%(2)08x ] +0x00201109 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) paging_fixup [ rip = 0x%(2)08x%(1)08x, addr = 0x%(4)08x%(3)08x ] +0x0020100a CPU%(cpu)d %(tsc)d (+%(reltsc)8d) gdt_ldt_mapping_fault [ eip = 0x%(1)08x, offset = 0x%(2)08x ] +0x0020110a CPU%(cpu)d %(tsc)d (+%(reltsc)8d) gdt_ldt_mapping_fault [ rip = 0x%(2)08x%(1)08x, offset = 0x%(4)08x%(3)08x ] +0x0020100b CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation [ addr = 0x%(3)08x, eip = 0x%(4)08x, npte = 0x%(2)08x%(1)08x ] +0x0020110b CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation [ addr = 0x%(4)08x%(3)08x, rip = 0x%(6)08x%(5)08x, npte = 0x%(2)08x%(1)08x ] +0x0020100c CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation_pae [ addr = 0x%(3)08x, eip = 0x%(4)08x, npte = 0x%(2)08x%(1)08x ] +0x0020110c CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation_pae [ addr = 0x%(4)08x%(3)08x, rip = 0x%(6)08x%(5)08x, npte = 0x%(2)08x%(1)08x ] 0x0040f001 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) shadow_not_shadow [ gl1e = 0x%(2)08x%(1)08x, va = 0x%(3)08x, flags = 0x%(4)08x ] 0x0040f101 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) shadow_not_shadow [ gl1e = 0x%(2)08x%(1)08x, va = 0x%(4)08x%(3)08x, flags = 0x%(5)08x ] diff --git a/xen/include/public/trace.h b/xen/include/public/trace.h index 0dfabe9..1f154bb 100644 --- a/xen/include/public/trace.h +++ b/xen/include/public/trace.h @@ -94,20 +94,19 @@ #define TRC_MEM_POD_ZERO_RECLAIM (TRC_MEM + 17) #define TRC_MEM_POD_SUPERPAGE_SPLINTER (TRC_MEM + 18) - -#define TRC_PV_HYPERCALL (TRC_PV + 1) -#define TRC_PV_TRAP (TRC_PV + 3) -#define TRC_PV_PAGE_FAULT (TRC_PV + 4) -#define TRC_PV_FORCED_INVALID_OP (TRC_PV + 5) -#define TRC_PV_EMULATE_PRIVOP (TRC_PV + 6) -#define TRC_PV_EMULATE_4GB (TRC_PV + 7) -#define TRC_PV_MATH_STATE_RESTORE (TRC_PV + 8) -#define TRC_PV_PAGING_FIXUP (TRC_PV + 9) -#define TRC_PV_GDT_LDT_MAPPING_FAULT (TRC_PV + 10) -#define TRC_PV_PTWR_EMULATION (TRC_PV + 11) -#define TRC_PV_PTWR_EMULATION_PAE (TRC_PV + 12) - /* Indicates that addresses in trace record are 64 bits */ -#define TRC_64_FLAG (0x100) +#define TRC_PV_ENTRY 0x00201000 /* Hypervisor entry points for PV guests. */ + +#define TRC_PV_HYPERCALL (TRC_PV_ENTRY + 1) +#define TRC_PV_TRAP (TRC_PV_ENTRY + 3) +#define TRC_PV_PAGE_FAULT (TRC_PV_ENTRY + 4) +#define TRC_PV_FORCED_INVALID_OP (TRC_PV_ENTRY + 5) +#define TRC_PV_EMULATE_PRIVOP (TRC_PV_ENTRY + 6) +#define TRC_PV_EMULATE_4GB (TRC_PV_ENTRY + 7) +#define TRC_PV_MATH_STATE_RESTORE (TRC_PV_ENTRY + 8) +#define TRC_PV_PAGING_FIXUP (TRC_PV_ENTRY + 9) +#define TRC_PV_GDT_LDT_MAPPING_FAULT (TRC_PV_ENTRY + 10) +#define TRC_PV_PTWR_EMULATION (TRC_PV_ENTRY + 11) +#define TRC_PV_PTWR_EMULATION_PAE (TRC_PV_ENTRY + 12) #define TRC_SHADOW_NOT_SHADOW (TRC_SHADOW + 1) #define TRC_SHADOW_FAST_PROPAGATE (TRC_SHADOW + 2) @@ -187,6 +186,14 @@ #define TRC_HW_IRQ_UNMAPPED_VECTOR (TRC_HW_IRQ + 0x7) #define TRC_HW_IRQ_HANDLED (TRC_HW_IRQ + 0x8) +/* + * Event Flags + * + * Some events (e.g, TRC_PV_TRAP and TRC_HVM_IOMEM_READ) have multiple + * record formats. These event flags distinguish between the + * different formats. + */ +#define TRC_64_FLAG 0x100 /* Addresses are 64 bits (instead of 32 bits) */ /* This structure represents a single trace buffer record. */ struct t_rec { -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 17:47:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 17:47:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIk5T-0002OJ-BG; Mon, 01 Oct 2012 17:47:23 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIk5R-0002Nn-LT for xen-devel@lists.xensource.com; Mon, 01 Oct 2012 17:47:21 +0000 Received: from [85.158.139.211:34689] by server-3.bemta-5.messagelabs.com id D2/29-16108-827D9605; Mon, 01 Oct 2012 17:47:20 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-13.tower-206.messagelabs.com!1349113638!16676780!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzkwMjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18690 invoked from network); 1 Oct 2012 17:47:20 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 17:47:20 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="209915478" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 17:47:17 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 13:47:17 -0400 Received: from qabil.uk.xensource.com ([10.80.2.76]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TIk5M-0007qB-Q2; Mon, 01 Oct 2012 18:47:16 +0100 From: David Vrabel To: xen-devel@lists.xensource.com Date: Mon, 1 Oct 2012 18:47:07 +0100 Message-ID: <1349113629-6338-2-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1349113629-6338-1-git-send-email-david.vrabel@citrix.com> References: <1349113629-6338-1-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Cc: Frediano Ziglio , David Vrabel Subject: [Xen-devel] [PATCH 1/3] trace: allow for different sub-classes of TRC_PV_* tracepoints X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: David Vrabel We want to add additional sub-classes for TRC_PV tracepoints and to be able to only capture these new sub-classes. This cannot currently be done as the existing tracepoints all use a sub-class of 0xf. So, redefine the PV events to use a new sub-class. All the current tracepoints are tracing entry points to the hypervisor so the sub-class is named TRC_PV_ENTRY. This change does not affect xenalyze as that only looks at the main class and the event number and does not use the sub-class field. Signed-off-by: Frediano Ziglio Signed-off-by: David Vrabel Acked-by: George Dunlap --- tools/xentrace/formats | 44 ++++++++++++++++++++++---------------------- xen/include/public/trace.h | 35 +++++++++++++++++++++-------------- 2 files changed, 43 insertions(+), 36 deletions(-) diff --git a/tools/xentrace/formats b/tools/xentrace/formats index 04e54d5..71220c0 100644 --- a/tools/xentrace/formats +++ b/tools/xentrace/formats @@ -82,28 +82,28 @@ 0x0010f002 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) page_grant_unmap [ domid = %(1)d ] 0x0010f003 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) page_grant_transfer [ domid = %(1)d ] -0x0020f001 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) hypercall [ eip = 0x%(1)08x, eax = 0x%(2)08x ] -0x0020f101 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) hypercall [ rip = 0x%(2)08x%(1)08x, eax = 0x%(3)08x ] -0x0020f003 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) trap [ eip = 0x%(1)08x, trapnr:error = 0x%(2)08x ] -0x0020f103 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) trap [ rip = 0x%(2)08x%(1)08x, trapnr:error = 0x%(3)08x ] -0x0020f004 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) page_fault [ eip = 0x%(1)08x, addr = 0x%(2)08x, error = 0x%(3)08x ] -0x0020f104 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) page_fault [ rip = 0x%(2)08x%(1)08x, addr = 0x%(4)08x%(3)08x, error = 0x%(5)08x ] -0x0020f005 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) forced_invalid_op [ eip = 0x%(1)08x ] -0x0020f105 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) forced_invalid_op [ rip = 0x%(2)08x%(1)08x ] -0x0020f006 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) emulate_privop [ eip = 0x%(1)08x ] -0x0020f106 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) emulate_privop [ rip = 0x%(2)08x%(1)08x ] -0x0020f007 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) emulate_4G [ eip = 0x%(1)08x ] -0x0020f107 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) emulate_4G [ rip = 0x%(2)08x%(1)08x ] -0x0020f008 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) math_state_restore -0x0020f108 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) math_state_restore -0x0020f009 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) paging_fixup [ eip = 0x%(1)08x, addr = 0x%(2)08x ] -0x0020f109 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) paging_fixup [ rip = 0x%(2)08x%(1)08x, addr = 0x%(4)08x%(3)08x ] -0x0020f00a CPU%(cpu)d %(tsc)d (+%(reltsc)8d) gdt_ldt_mapping_fault [ eip = 0x%(1)08x, offset = 0x%(2)08x ] -0x0020f10a CPU%(cpu)d %(tsc)d (+%(reltsc)8d) gdt_ldt_mapping_fault [ rip = 0x%(2)08x%(1)08x, offset = 0x%(4)08x%(3)08x ] -0x0020f00b CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation [ addr = 0x%(3)08x, eip = 0x%(4)08x, npte = 0x%(2)08x%(1)08x ] -0x0020f10b CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation [ addr = 0x%(4)08x%(3)08x, rip = 0x%(6)08x%(5)08x, npte = 0x%(2)08x%(1)08x ] -0x0020f00c CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation_pae [ addr = 0x%(3)08x, eip = 0x%(4)08x, npte = 0x%(2)08x%(1)08x ] -0x0020f10c CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation_pae [ addr = 0x%(4)08x%(3)08x, rip = 0x%(6)08x%(5)08x, npte = 0x%(2)08x%(1)08x ] +0x00201001 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) hypercall [ eip = 0x%(1)08x, eax = 0x%(2)08x ] +0x00201101 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) hypercall [ rip = 0x%(2)08x%(1)08x, eax = 0x%(3)08x ] +0x00201003 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) trap [ eip = 0x%(1)08x, trapnr:error = 0x%(2)08x ] +0x00201103 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) trap [ rip = 0x%(2)08x%(1)08x, trapnr:error = 0x%(3)08x ] +0x00201004 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) page_fault [ eip = 0x%(1)08x, addr = 0x%(2)08x, error = 0x%(3)08x ] +0x00201104 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) page_fault [ rip = 0x%(2)08x%(1)08x, addr = 0x%(4)08x%(3)08x, error = 0x%(5)08x ] +0x00201005 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) forced_invalid_op [ eip = 0x%(1)08x ] +0x00201105 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) forced_invalid_op [ rip = 0x%(2)08x%(1)08x ] +0x00201006 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) emulate_privop [ eip = 0x%(1)08x ] +0x00201106 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) emulate_privop [ rip = 0x%(2)08x%(1)08x ] +0x00201007 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) emulate_4G [ eip = 0x%(1)08x ] +0x00201107 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) emulate_4G [ rip = 0x%(2)08x%(1)08x ] +0x00201008 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) math_state_restore +0x00201108 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) math_state_restore +0x00201009 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) paging_fixup [ eip = 0x%(1)08x, addr = 0x%(2)08x ] +0x00201109 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) paging_fixup [ rip = 0x%(2)08x%(1)08x, addr = 0x%(4)08x%(3)08x ] +0x0020100a CPU%(cpu)d %(tsc)d (+%(reltsc)8d) gdt_ldt_mapping_fault [ eip = 0x%(1)08x, offset = 0x%(2)08x ] +0x0020110a CPU%(cpu)d %(tsc)d (+%(reltsc)8d) gdt_ldt_mapping_fault [ rip = 0x%(2)08x%(1)08x, offset = 0x%(4)08x%(3)08x ] +0x0020100b CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation [ addr = 0x%(3)08x, eip = 0x%(4)08x, npte = 0x%(2)08x%(1)08x ] +0x0020110b CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation [ addr = 0x%(4)08x%(3)08x, rip = 0x%(6)08x%(5)08x, npte = 0x%(2)08x%(1)08x ] +0x0020100c CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation_pae [ addr = 0x%(3)08x, eip = 0x%(4)08x, npte = 0x%(2)08x%(1)08x ] +0x0020110c CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation_pae [ addr = 0x%(4)08x%(3)08x, rip = 0x%(6)08x%(5)08x, npte = 0x%(2)08x%(1)08x ] 0x0040f001 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) shadow_not_shadow [ gl1e = 0x%(2)08x%(1)08x, va = 0x%(3)08x, flags = 0x%(4)08x ] 0x0040f101 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) shadow_not_shadow [ gl1e = 0x%(2)08x%(1)08x, va = 0x%(4)08x%(3)08x, flags = 0x%(5)08x ] diff --git a/xen/include/public/trace.h b/xen/include/public/trace.h index 0dfabe9..1f154bb 100644 --- a/xen/include/public/trace.h +++ b/xen/include/public/trace.h @@ -94,20 +94,19 @@ #define TRC_MEM_POD_ZERO_RECLAIM (TRC_MEM + 17) #define TRC_MEM_POD_SUPERPAGE_SPLINTER (TRC_MEM + 18) - -#define TRC_PV_HYPERCALL (TRC_PV + 1) -#define TRC_PV_TRAP (TRC_PV + 3) -#define TRC_PV_PAGE_FAULT (TRC_PV + 4) -#define TRC_PV_FORCED_INVALID_OP (TRC_PV + 5) -#define TRC_PV_EMULATE_PRIVOP (TRC_PV + 6) -#define TRC_PV_EMULATE_4GB (TRC_PV + 7) -#define TRC_PV_MATH_STATE_RESTORE (TRC_PV + 8) -#define TRC_PV_PAGING_FIXUP (TRC_PV + 9) -#define TRC_PV_GDT_LDT_MAPPING_FAULT (TRC_PV + 10) -#define TRC_PV_PTWR_EMULATION (TRC_PV + 11) -#define TRC_PV_PTWR_EMULATION_PAE (TRC_PV + 12) - /* Indicates that addresses in trace record are 64 bits */ -#define TRC_64_FLAG (0x100) +#define TRC_PV_ENTRY 0x00201000 /* Hypervisor entry points for PV guests. */ + +#define TRC_PV_HYPERCALL (TRC_PV_ENTRY + 1) +#define TRC_PV_TRAP (TRC_PV_ENTRY + 3) +#define TRC_PV_PAGE_FAULT (TRC_PV_ENTRY + 4) +#define TRC_PV_FORCED_INVALID_OP (TRC_PV_ENTRY + 5) +#define TRC_PV_EMULATE_PRIVOP (TRC_PV_ENTRY + 6) +#define TRC_PV_EMULATE_4GB (TRC_PV_ENTRY + 7) +#define TRC_PV_MATH_STATE_RESTORE (TRC_PV_ENTRY + 8) +#define TRC_PV_PAGING_FIXUP (TRC_PV_ENTRY + 9) +#define TRC_PV_GDT_LDT_MAPPING_FAULT (TRC_PV_ENTRY + 10) +#define TRC_PV_PTWR_EMULATION (TRC_PV_ENTRY + 11) +#define TRC_PV_PTWR_EMULATION_PAE (TRC_PV_ENTRY + 12) #define TRC_SHADOW_NOT_SHADOW (TRC_SHADOW + 1) #define TRC_SHADOW_FAST_PROPAGATE (TRC_SHADOW + 2) @@ -187,6 +186,14 @@ #define TRC_HW_IRQ_UNMAPPED_VECTOR (TRC_HW_IRQ + 0x7) #define TRC_HW_IRQ_HANDLED (TRC_HW_IRQ + 0x8) +/* + * Event Flags + * + * Some events (e.g, TRC_PV_TRAP and TRC_HVM_IOMEM_READ) have multiple + * record formats. These event flags distinguish between the + * different formats. + */ +#define TRC_64_FLAG 0x100 /* Addresses are 64 bits (instead of 32 bits) */ /* This structure represents a single trace buffer record. */ struct t_rec { -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 17:47:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 17:47:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIk5S-0002OC-Vs; Mon, 01 Oct 2012 17:47:22 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIk5R-0002Nm-Fm for xen-devel@lists.xensource.com; Mon, 01 Oct 2012 17:47:21 +0000 Received: from [85.158.143.35:64707] by server-3.bemta-4.messagelabs.com id B8/13-10986-827D9605; Mon, 01 Oct 2012 17:47:20 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1349113637!20596248!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzI5Nzc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26508 invoked from network); 1 Oct 2012 17:47:19 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 17:47:19 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="39759605" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 17:47:17 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 13:47:17 -0400 Received: from qabil.uk.xensource.com ([10.80.2.76]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TIk5M-0007qB-OH; Mon, 01 Oct 2012 18:47:16 +0100 From: David Vrabel To: xen-devel@lists.xensource.com Date: Mon, 1 Oct 2012 18:47:06 +0100 Message-ID: <1349113629-6338-1-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 MIME-Version: 1.0 Cc: David Vrabel Subject: [Xen-devel] [PATCHv4 0/3] trace: improve hypercall tracing X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This series improves the usefulness of xentrace when tracing hypercalls: some hypercall arguments are added the trace record and the subcalls in multicalls are traced. xenalyze requires some patches to decode the new trace record format, these patches will be posted shortly. Changes since v3: - Trace arguments for a few more hypercalls (vcpu_op and sched_op). Changes since v2: - Changed all PV events to use a different subclass. - Put multicall subcalls into their own subclass (so they can be filtered out). - Use 12 bits to report which arguments are present in the PV_HYPERCALL_V2 trace record. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 17:47:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 17:47:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIk5S-0002OC-Vs; Mon, 01 Oct 2012 17:47:22 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIk5R-0002Nm-Fm for xen-devel@lists.xensource.com; Mon, 01 Oct 2012 17:47:21 +0000 Received: from [85.158.143.35:64707] by server-3.bemta-4.messagelabs.com id B8/13-10986-827D9605; Mon, 01 Oct 2012 17:47:20 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1349113637!20596248!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzI5Nzc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26508 invoked from network); 1 Oct 2012 17:47:19 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 17:47:19 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="39759605" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 17:47:17 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 13:47:17 -0400 Received: from qabil.uk.xensource.com ([10.80.2.76]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TIk5M-0007qB-OH; Mon, 01 Oct 2012 18:47:16 +0100 From: David Vrabel To: xen-devel@lists.xensource.com Date: Mon, 1 Oct 2012 18:47:06 +0100 Message-ID: <1349113629-6338-1-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 MIME-Version: 1.0 Cc: David Vrabel Subject: [Xen-devel] [PATCHv4 0/3] trace: improve hypercall tracing X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This series improves the usefulness of xentrace when tracing hypercalls: some hypercall arguments are added the trace record and the subcalls in multicalls are traced. xenalyze requires some patches to decode the new trace record format, these patches will be posted shortly. Changes since v3: - Trace arguments for a few more hypercalls (vcpu_op and sched_op). Changes since v2: - Changed all PV events to use a different subclass. - Put multicall subcalls into their own subclass (so they can be filtered out). - Use 12 bits to report which arguments are present in the PV_HYPERCALL_V2 trace record. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 17:47:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 17:47:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIk5U-0002OQ-Nz; Mon, 01 Oct 2012 17:47:24 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIk5S-0002Nw-AS for xen-devel@lists.xensource.com; Mon, 01 Oct 2012 17:47:22 +0000 Received: from [85.158.139.211:44796] by server-5.bemta-5.messagelabs.com id CA/9D-21075-927D9605; Mon, 01 Oct 2012 17:47:21 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-13.tower-206.messagelabs.com!1349113638!16676780!3 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzkwMjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18736 invoked from network); 1 Oct 2012 17:47:20 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 17:47:20 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="209915479" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 17:47:17 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 13:47:17 -0400 Received: from qabil.uk.xensource.com ([10.80.2.76]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TIk5M-0007qB-Qx; Mon, 01 Oct 2012 18:47:16 +0100 From: David Vrabel To: xen-devel@lists.xensource.com Date: Mon, 1 Oct 2012 18:47:09 +0100 Message-ID: <1349113629-6338-4-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1349113629-6338-1-git-send-email-david.vrabel@citrix.com> References: <1349113629-6338-1-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Cc: David Vrabel Subject: [Xen-devel] [PATCH 3/3] trace: trace hypercalls inside a multicall X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: David Vrabel Add a trace record for every hypercall inside a multicall. These use a new event ID (with a different sub-class ) so they may be filtered out if only the calls into hypervisor are of interest. Signed-off-by: David Vrabel Acked-by: George Dunlap --- tools/xentrace/formats | 1 + tools/xentrace/xentrace_format | 3 ++- xen/arch/x86/trace.c | 2 +- xen/common/compat/multicall.c | 12 ++++++++++++ xen/common/multicall.c | 16 ++++++++++++++++ xen/common/trace.c | 6 +++--- xen/include/public/trace.h | 4 +++- xen/include/xen/trace.h | 3 ++- 8 files changed, 40 insertions(+), 7 deletions(-) diff --git a/tools/xentrace/formats b/tools/xentrace/formats index fa935c8..928e1d7 100644 --- a/tools/xentrace/formats +++ b/tools/xentrace/formats @@ -105,6 +105,7 @@ 0x0020100c CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation_pae [ addr = 0x%(3)08x, eip = 0x%(4)08x, npte = 0x%(2)08x%(1)08x ] 0x0020110c CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation_pae [ addr = 0x%(4)08x%(3)08x, rip = 0x%(6)08x%(5)08x, npte = 0x%(2)08x%(1)08x ] 0x0020100d CPU%(cpu)d %(tsc)d (+%(reltsc)8d) hypercall [ op = 0x%(1)08x ] +0x0020200e CPU%(cpu)d %(tsc)d (+%(reltsc)8d) hypercall [ op = 0x%(1)08x ] 0x0040f001 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) shadow_not_shadow [ gl1e = 0x%(2)08x%(1)08x, va = 0x%(3)08x, flags = 0x%(4)08x ] 0x0040f101 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) shadow_not_shadow [ gl1e = 0x%(2)08x%(1)08x, va = 0x%(4)08x%(3)08x, flags = 0x%(5)08x ] diff --git a/tools/xentrace/xentrace_format b/tools/xentrace/xentrace_format index bdcab09..5ff85ae 100644 --- a/tools/xentrace/xentrace_format +++ b/tools/xentrace/xentrace_format @@ -112,6 +112,7 @@ last_tsc = [0] TRC_TRACE_IRQ = 0x1f004 TRC_PV_HYPERCALL_V2 = 0x20100d +TRC_PV_HYPERCALL_SUBCALL = 0x20100e NR_VECTORS = 256 irq_measure = [{'count':0, 'tot_cycles':0, 'max_cycles':0}] * NR_VECTORS @@ -199,7 +200,7 @@ while not interrupted: d3 = irq_measure[d1]['tot_cycles'] d4 = irq_measure[d1]['max_cycles'] - if event == TRC_PV_HYPERCALL_V2: + if event == TRC_PV_HYPERCALL_V2 or event == TRC_PV_HYPERCALL_SUBCALL: # Mask off the argument present bits. d1 &= 0x000fffff diff --git a/xen/arch/x86/trace.c b/xen/arch/x86/trace.c index f2c75bc..982ca88 100644 --- a/xen/arch/x86/trace.c +++ b/xen/arch/x86/trace.c @@ -30,7 +30,7 @@ void trace_hypercall(void) args[5] = regs->r9; } - __trace_hypercall(regs->eax, args); + __trace_hypercall(TRC_PV_HYPERCALL_V2, regs->eax, args); } void __trace_pv_trap(int trapnr, unsigned long eip, diff --git a/xen/common/compat/multicall.c b/xen/common/compat/multicall.c index 0eb1212..e7e2a40 100644 --- a/xen/common/compat/multicall.c +++ b/xen/common/compat/multicall.c @@ -5,6 +5,7 @@ #include #include #include +#include #define COMPAT typedef int ret_t; @@ -25,6 +26,17 @@ DEFINE_XEN_GUEST_HANDLE(multicall_entry_compat_t); #define do_multicall(l, n) compat_multicall(_##l, n) #define _XEN_GUEST_HANDLE(t) XEN_GUEST_HANDLE(t) +static void __trace_multicall_call(multicall_entry_t *call) +{ + unsigned long args[6]; + int i; + + for ( i = 0; i < ARRAY_SIZE(args); i++ ) + args[i] = call->args[i]; + + __trace_hypercall(TRC_PV_HYPERCALL_SUBCALL, call->op, args); +} + #include "../multicall.c" /* diff --git a/xen/common/multicall.c b/xen/common/multicall.c index 6c1a9d7..ca1839d 100644 --- a/xen/common/multicall.c +++ b/xen/common/multicall.c @@ -11,14 +11,28 @@ #include #include #include +#include #include #include #ifndef COMPAT typedef long ret_t; #define xlat_multicall_entry(mcs) + +static void __trace_multicall_call(multicall_entry_t *call) +{ + __trace_hypercall(TRC_PV_HYPERCALL_SUBCALL, call->op, call->args); +} #endif +static void trace_multicall_call(multicall_entry_t *call) +{ + if ( !tb_init_done ) + return; + + __trace_multicall_call(call); +} + ret_t do_multicall( XEN_GUEST_HANDLE(multicall_entry_t) call_list, unsigned int nr_calls) @@ -47,6 +61,8 @@ do_multicall( break; } + trace_multicall_call(&mcs->call); + do_multicall_call(&mcs->call); #ifndef NDEBUG diff --git a/xen/common/trace.c b/xen/common/trace.c index 57a5a36..ebb60df 100644 --- a/xen/common/trace.c +++ b/xen/common/trace.c @@ -816,7 +816,8 @@ unlock: tasklet_schedule(&trace_notify_dom0_tasklet); } -void __trace_hypercall(unsigned long op, const unsigned long *args) +void __trace_hypercall(uint32_t event, unsigned long op, + const unsigned long *args) { struct { uint32_t op; @@ -864,8 +865,7 @@ void __trace_hypercall(unsigned long op, const unsigned long *args) break; } - __trace_var(TRC_PV_HYPERCALL_V2, 1, - sizeof(uint32_t) * (1 + (a - d.args)), &d); + __trace_var(event, 1, sizeof(uint32_t) * (1 + (a - d.args)), &d); } /* diff --git a/xen/include/public/trace.h b/xen/include/public/trace.h index ef43b23..3c93805 100644 --- a/xen/include/public/trace.h +++ b/xen/include/public/trace.h @@ -94,7 +94,8 @@ #define TRC_MEM_POD_ZERO_RECLAIM (TRC_MEM + 17) #define TRC_MEM_POD_SUPERPAGE_SPLINTER (TRC_MEM + 18) -#define TRC_PV_ENTRY 0x00201000 /* Hypervisor entry points for PV guests. */ +#define TRC_PV_ENTRY 0x00201000 /* Hypervisor entry points for PV guests. */ +#define TRC_PV_SUBCALL 0x00202000 /* Sub-call in a multicall hypercall */ #define TRC_PV_HYPERCALL (TRC_PV_ENTRY + 1) #define TRC_PV_TRAP (TRC_PV_ENTRY + 3) @@ -108,6 +109,7 @@ #define TRC_PV_PTWR_EMULATION (TRC_PV_ENTRY + 11) #define TRC_PV_PTWR_EMULATION_PAE (TRC_PV_ENTRY + 12) #define TRC_PV_HYPERCALL_V2 (TRC_PV_ENTRY + 13) +#define TRC_PV_HYPERCALL_SUBCALL (TRC_PV_SUBCALL + 14) /* * TRC_PV_HYPERCALL_V2 format diff --git a/xen/include/xen/trace.h b/xen/include/xen/trace.h index f601aeb..3b8a7b3 100644 --- a/xen/include/xen/trace.h +++ b/xen/include/xen/trace.h @@ -44,7 +44,8 @@ static inline void trace_var(u32 event, int cycles, int extra, __trace_var(event, cycles, extra, extra_data); } -void __trace_hypercall(unsigned long call, const unsigned long *args); +void __trace_hypercall(uint32_t event, unsigned long op, + const unsigned long *args); /* Convenience macros for calling the trace function. */ #define TRACE_0D(_e) \ -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 17:47:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 17:47:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIk5U-0002OQ-Nz; Mon, 01 Oct 2012 17:47:24 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIk5S-0002Nw-AS for xen-devel@lists.xensource.com; Mon, 01 Oct 2012 17:47:22 +0000 Received: from [85.158.139.211:44796] by server-5.bemta-5.messagelabs.com id CA/9D-21075-927D9605; Mon, 01 Oct 2012 17:47:21 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-13.tower-206.messagelabs.com!1349113638!16676780!3 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzkwMjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18736 invoked from network); 1 Oct 2012 17:47:20 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 17:47:20 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="209915479" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 17:47:17 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 13:47:17 -0400 Received: from qabil.uk.xensource.com ([10.80.2.76]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TIk5M-0007qB-Qx; Mon, 01 Oct 2012 18:47:16 +0100 From: David Vrabel To: xen-devel@lists.xensource.com Date: Mon, 1 Oct 2012 18:47:09 +0100 Message-ID: <1349113629-6338-4-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1349113629-6338-1-git-send-email-david.vrabel@citrix.com> References: <1349113629-6338-1-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Cc: David Vrabel Subject: [Xen-devel] [PATCH 3/3] trace: trace hypercalls inside a multicall X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: David Vrabel Add a trace record for every hypercall inside a multicall. These use a new event ID (with a different sub-class ) so they may be filtered out if only the calls into hypervisor are of interest. Signed-off-by: David Vrabel Acked-by: George Dunlap --- tools/xentrace/formats | 1 + tools/xentrace/xentrace_format | 3 ++- xen/arch/x86/trace.c | 2 +- xen/common/compat/multicall.c | 12 ++++++++++++ xen/common/multicall.c | 16 ++++++++++++++++ xen/common/trace.c | 6 +++--- xen/include/public/trace.h | 4 +++- xen/include/xen/trace.h | 3 ++- 8 files changed, 40 insertions(+), 7 deletions(-) diff --git a/tools/xentrace/formats b/tools/xentrace/formats index fa935c8..928e1d7 100644 --- a/tools/xentrace/formats +++ b/tools/xentrace/formats @@ -105,6 +105,7 @@ 0x0020100c CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation_pae [ addr = 0x%(3)08x, eip = 0x%(4)08x, npte = 0x%(2)08x%(1)08x ] 0x0020110c CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation_pae [ addr = 0x%(4)08x%(3)08x, rip = 0x%(6)08x%(5)08x, npte = 0x%(2)08x%(1)08x ] 0x0020100d CPU%(cpu)d %(tsc)d (+%(reltsc)8d) hypercall [ op = 0x%(1)08x ] +0x0020200e CPU%(cpu)d %(tsc)d (+%(reltsc)8d) hypercall [ op = 0x%(1)08x ] 0x0040f001 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) shadow_not_shadow [ gl1e = 0x%(2)08x%(1)08x, va = 0x%(3)08x, flags = 0x%(4)08x ] 0x0040f101 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) shadow_not_shadow [ gl1e = 0x%(2)08x%(1)08x, va = 0x%(4)08x%(3)08x, flags = 0x%(5)08x ] diff --git a/tools/xentrace/xentrace_format b/tools/xentrace/xentrace_format index bdcab09..5ff85ae 100644 --- a/tools/xentrace/xentrace_format +++ b/tools/xentrace/xentrace_format @@ -112,6 +112,7 @@ last_tsc = [0] TRC_TRACE_IRQ = 0x1f004 TRC_PV_HYPERCALL_V2 = 0x20100d +TRC_PV_HYPERCALL_SUBCALL = 0x20100e NR_VECTORS = 256 irq_measure = [{'count':0, 'tot_cycles':0, 'max_cycles':0}] * NR_VECTORS @@ -199,7 +200,7 @@ while not interrupted: d3 = irq_measure[d1]['tot_cycles'] d4 = irq_measure[d1]['max_cycles'] - if event == TRC_PV_HYPERCALL_V2: + if event == TRC_PV_HYPERCALL_V2 or event == TRC_PV_HYPERCALL_SUBCALL: # Mask off the argument present bits. d1 &= 0x000fffff diff --git a/xen/arch/x86/trace.c b/xen/arch/x86/trace.c index f2c75bc..982ca88 100644 --- a/xen/arch/x86/trace.c +++ b/xen/arch/x86/trace.c @@ -30,7 +30,7 @@ void trace_hypercall(void) args[5] = regs->r9; } - __trace_hypercall(regs->eax, args); + __trace_hypercall(TRC_PV_HYPERCALL_V2, regs->eax, args); } void __trace_pv_trap(int trapnr, unsigned long eip, diff --git a/xen/common/compat/multicall.c b/xen/common/compat/multicall.c index 0eb1212..e7e2a40 100644 --- a/xen/common/compat/multicall.c +++ b/xen/common/compat/multicall.c @@ -5,6 +5,7 @@ #include #include #include +#include #define COMPAT typedef int ret_t; @@ -25,6 +26,17 @@ DEFINE_XEN_GUEST_HANDLE(multicall_entry_compat_t); #define do_multicall(l, n) compat_multicall(_##l, n) #define _XEN_GUEST_HANDLE(t) XEN_GUEST_HANDLE(t) +static void __trace_multicall_call(multicall_entry_t *call) +{ + unsigned long args[6]; + int i; + + for ( i = 0; i < ARRAY_SIZE(args); i++ ) + args[i] = call->args[i]; + + __trace_hypercall(TRC_PV_HYPERCALL_SUBCALL, call->op, args); +} + #include "../multicall.c" /* diff --git a/xen/common/multicall.c b/xen/common/multicall.c index 6c1a9d7..ca1839d 100644 --- a/xen/common/multicall.c +++ b/xen/common/multicall.c @@ -11,14 +11,28 @@ #include #include #include +#include #include #include #ifndef COMPAT typedef long ret_t; #define xlat_multicall_entry(mcs) + +static void __trace_multicall_call(multicall_entry_t *call) +{ + __trace_hypercall(TRC_PV_HYPERCALL_SUBCALL, call->op, call->args); +} #endif +static void trace_multicall_call(multicall_entry_t *call) +{ + if ( !tb_init_done ) + return; + + __trace_multicall_call(call); +} + ret_t do_multicall( XEN_GUEST_HANDLE(multicall_entry_t) call_list, unsigned int nr_calls) @@ -47,6 +61,8 @@ do_multicall( break; } + trace_multicall_call(&mcs->call); + do_multicall_call(&mcs->call); #ifndef NDEBUG diff --git a/xen/common/trace.c b/xen/common/trace.c index 57a5a36..ebb60df 100644 --- a/xen/common/trace.c +++ b/xen/common/trace.c @@ -816,7 +816,8 @@ unlock: tasklet_schedule(&trace_notify_dom0_tasklet); } -void __trace_hypercall(unsigned long op, const unsigned long *args) +void __trace_hypercall(uint32_t event, unsigned long op, + const unsigned long *args) { struct { uint32_t op; @@ -864,8 +865,7 @@ void __trace_hypercall(unsigned long op, const unsigned long *args) break; } - __trace_var(TRC_PV_HYPERCALL_V2, 1, - sizeof(uint32_t) * (1 + (a - d.args)), &d); + __trace_var(event, 1, sizeof(uint32_t) * (1 + (a - d.args)), &d); } /* diff --git a/xen/include/public/trace.h b/xen/include/public/trace.h index ef43b23..3c93805 100644 --- a/xen/include/public/trace.h +++ b/xen/include/public/trace.h @@ -94,7 +94,8 @@ #define TRC_MEM_POD_ZERO_RECLAIM (TRC_MEM + 17) #define TRC_MEM_POD_SUPERPAGE_SPLINTER (TRC_MEM + 18) -#define TRC_PV_ENTRY 0x00201000 /* Hypervisor entry points for PV guests. */ +#define TRC_PV_ENTRY 0x00201000 /* Hypervisor entry points for PV guests. */ +#define TRC_PV_SUBCALL 0x00202000 /* Sub-call in a multicall hypercall */ #define TRC_PV_HYPERCALL (TRC_PV_ENTRY + 1) #define TRC_PV_TRAP (TRC_PV_ENTRY + 3) @@ -108,6 +109,7 @@ #define TRC_PV_PTWR_EMULATION (TRC_PV_ENTRY + 11) #define TRC_PV_PTWR_EMULATION_PAE (TRC_PV_ENTRY + 12) #define TRC_PV_HYPERCALL_V2 (TRC_PV_ENTRY + 13) +#define TRC_PV_HYPERCALL_SUBCALL (TRC_PV_SUBCALL + 14) /* * TRC_PV_HYPERCALL_V2 format diff --git a/xen/include/xen/trace.h b/xen/include/xen/trace.h index f601aeb..3b8a7b3 100644 --- a/xen/include/xen/trace.h +++ b/xen/include/xen/trace.h @@ -44,7 +44,8 @@ static inline void trace_var(u32 event, int cycles, int extra, __trace_var(event, cycles, extra, extra_data); } -void __trace_hypercall(unsigned long call, const unsigned long *args); +void __trace_hypercall(uint32_t event, unsigned long op, + const unsigned long *args); /* Convenience macros for calling the trace function. */ #define TRACE_0D(_e) \ -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 17:47:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 17:47:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIk5S-0002O1-Jc; Mon, 01 Oct 2012 17:47:22 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIk5Q-0002Nl-RV for xen-devel@lists.xensource.com; Mon, 01 Oct 2012 17:47:21 +0000 Received: from [85.158.139.211:44755] by server-10.bemta-5.messagelabs.com id A7/95-16911-827D9605; Mon, 01 Oct 2012 17:47:20 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-13.tower-206.messagelabs.com!1349113638!16676780!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzkwMjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18673 invoked from network); 1 Oct 2012 17:47:19 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 17:47:19 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="209915477" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 17:47:17 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 13:47:17 -0400 Received: from qabil.uk.xensource.com ([10.80.2.76]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TIk5M-0007qB-QU; Mon, 01 Oct 2012 18:47:16 +0100 From: David Vrabel To: xen-devel@lists.xensource.com Date: Mon, 1 Oct 2012 18:47:08 +0100 Message-ID: <1349113629-6338-3-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1349113629-6338-1-git-send-email-david.vrabel@citrix.com> References: <1349113629-6338-1-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Cc: David Vrabel Subject: [Xen-devel] [PATCH 2/3] trace: improve usefulness of hypercall trace record X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: David Vrabel Trace hypercalls using a more useful trace record format. The EIP field is removed (it was always somewhere in the hypercall page) and include selected hypercall arguments (e.g., the number of calls in a multicall, and the number of PTE updates in an mmu_update etc.). 12 bits in the first extra word are used to indicate which arguments are present in the record and what size they are (32 or 64-bit). This is an incompatible record format so a new event ID is used so tools can distinguish between the two formats. Signed-off-by: David Vrabel Acked-by: George Dunlap --- tools/xentrace/formats | 1 + tools/xentrace/xentrace_format | 6 ++++ xen/arch/x86/trace.c | 35 +++++++++++--------------- xen/common/trace.c | 52 ++++++++++++++++++++++++++++++++++++++++ xen/include/public/trace.h | 30 +++++++++++++++++++++++ xen/include/xen/trace.h | 2 + 6 files changed, 106 insertions(+), 20 deletions(-) diff --git a/tools/xentrace/formats b/tools/xentrace/formats index 71220c0..fa935c8 100644 --- a/tools/xentrace/formats +++ b/tools/xentrace/formats @@ -104,6 +104,7 @@ 0x0020110b CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation [ addr = 0x%(4)08x%(3)08x, rip = 0x%(6)08x%(5)08x, npte = 0x%(2)08x%(1)08x ] 0x0020100c CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation_pae [ addr = 0x%(3)08x, eip = 0x%(4)08x, npte = 0x%(2)08x%(1)08x ] 0x0020110c CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation_pae [ addr = 0x%(4)08x%(3)08x, rip = 0x%(6)08x%(5)08x, npte = 0x%(2)08x%(1)08x ] +0x0020100d CPU%(cpu)d %(tsc)d (+%(reltsc)8d) hypercall [ op = 0x%(1)08x ] 0x0040f001 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) shadow_not_shadow [ gl1e = 0x%(2)08x%(1)08x, va = 0x%(3)08x, flags = 0x%(4)08x ] 0x0040f101 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) shadow_not_shadow [ gl1e = 0x%(2)08x%(1)08x, va = 0x%(4)08x%(3)08x, flags = 0x%(5)08x ] diff --git a/tools/xentrace/xentrace_format b/tools/xentrace/xentrace_format index e13b05b..bdcab09 100644 --- a/tools/xentrace/xentrace_format +++ b/tools/xentrace/xentrace_format @@ -111,6 +111,8 @@ D7REC = "IIIIIII" last_tsc = [0] TRC_TRACE_IRQ = 0x1f004 +TRC_PV_HYPERCALL_V2 = 0x20100d + NR_VECTORS = 256 irq_measure = [{'count':0, 'tot_cycles':0, 'max_cycles':0}] * NR_VECTORS @@ -197,6 +199,10 @@ while not interrupted: d3 = irq_measure[d1]['tot_cycles'] d4 = irq_measure[d1]['max_cycles'] + if event == TRC_PV_HYPERCALL_V2: + # Mask off the argument present bits. + d1 &= 0x000fffff + #tsc = (tscH<<32) | tscL #print i, tsc diff --git a/xen/arch/x86/trace.c b/xen/arch/x86/trace.c index 27fe150..f2c75bc 100644 --- a/xen/arch/x86/trace.c +++ b/xen/arch/x86/trace.c @@ -9,33 +9,28 @@ void trace_hypercall(void) { struct cpu_user_regs *regs = guest_cpu_user_regs(); + unsigned long args[6]; if ( is_pv_32on64_vcpu(current) ) { - struct { - u32 eip,eax; - } __attribute__((packed)) d; - - d.eip = regs->eip; - d.eax = regs->eax; - - __trace_var(TRC_PV_HYPERCALL, 1, sizeof(d), &d); + args[0] = regs->ebx; + args[1] = regs->ecx; + args[2] = regs->edx; + args[3] = regs->esi; + args[4] = regs->edi; + args[5] = regs->ebp; } else { - struct { - unsigned long eip; - u32 eax; - } __attribute__((packed)) d; - u32 event; - - event = TRC_PV_HYPERCALL; - event |= TRC_64_FLAG; - d.eip = regs->eip; - d.eax = regs->eax; - - __trace_var(event, 1/*tsc*/, sizeof(d), &d); + args[0] = regs->rdi; + args[1] = regs->rsi; + args[2] = regs->rdx; + args[3] = regs->r10; + args[4] = regs->r8; + args[5] = regs->r9; } + + __trace_hypercall(regs->eax, args); } void __trace_pv_trap(int trapnr, unsigned long eip, diff --git a/xen/common/trace.c b/xen/common/trace.c index cacaeb2..57a5a36 100644 --- a/xen/common/trace.c +++ b/xen/common/trace.c @@ -816,6 +816,58 @@ unlock: tasklet_schedule(&trace_notify_dom0_tasklet); } +void __trace_hypercall(unsigned long op, const unsigned long *args) +{ + struct { + uint32_t op; + uint32_t args[6]; + } __attribute__((packed)) d; + uint32_t *a = d.args; + +#define APPEND_ARG32(i) \ + do { \ + unsigned i_ = (i); \ + *a++ = args[(i_)]; \ + d.op |= TRC_PV_HYPERCALL_V2_ARG_32(i_); \ + } while( 0 ) + + /* + * This shouldn't happen as @op should be small enough but just in + * case, warn if the argument bits in the trace record would + * clobber the hypercall op. + */ + WARN_ON(op & TRC_PV_HYPERCALL_V2_ARG_MASK); + + d.op = op; + + switch ( op ) + { + case __HYPERVISOR_mmu_update: + APPEND_ARG32(1); /* count */ + break; + case __HYPERVISOR_multicall: + APPEND_ARG32(1); /* count */ + break; + case __HYPERVISOR_grant_table_op: + APPEND_ARG32(0); /* cmd */ + APPEND_ARG32(2); /* count */ + break; + case __HYPERVISOR_vcpu_op: + APPEND_ARG32(0); /* cmd */ + APPEND_ARG32(1); /* vcpuid */ + break; + case __HYPERVISOR_mmuext_op: + APPEND_ARG32(1); /* count */ + break; + case __HYPERVISOR_sched_op: + APPEND_ARG32(0); /* cmd */ + break; + } + + __trace_var(TRC_PV_HYPERCALL_V2, 1, + sizeof(uint32_t) * (1 + (a - d.args)), &d); +} + /* * Local variables: * mode: C diff --git a/xen/include/public/trace.h b/xen/include/public/trace.h index 1f154bb..ef43b23 100644 --- a/xen/include/public/trace.h +++ b/xen/include/public/trace.h @@ -107,6 +107,36 @@ #define TRC_PV_GDT_LDT_MAPPING_FAULT (TRC_PV_ENTRY + 10) #define TRC_PV_PTWR_EMULATION (TRC_PV_ENTRY + 11) #define TRC_PV_PTWR_EMULATION_PAE (TRC_PV_ENTRY + 12) +#define TRC_PV_HYPERCALL_V2 (TRC_PV_ENTRY + 13) + +/* + * TRC_PV_HYPERCALL_V2 format + * + * Only some of the hypercall argument are recorded. Bit fields A0 to + * A5 in the first extra word are set if the argument is present and + * the arguments themselves are packed sequentially in the following + * words. + * + * The TRC_64_FLAG bit is not set for these events (even if there are + * 64-bit arguments in the record). + * + * Word + * 0 bit 31 30|29 28|27 26|25 24|23 22|21 20|19 ... 0 + * A5 |A4 |A3 |A2 |A1 |A0 |Hypercall op + * 1 First 32 bit (or low word of first 64 bit) arg in record + * 2 Second 32 bit (or high word of first 64 bit) arg in record + * ... + * + * A0-A5 bitfield values: + * + * 00b Argument not present + * 01b 32-bit argument present + * 10b 64-bit argument present + * 11b Reserved + */ +#define TRC_PV_HYPERCALL_V2_ARG_32(i) (0x1 << (20 + 2*(i))) +#define TRC_PV_HYPERCALL_V2_ARG_64(i) (0x2 << (20 + 2*(i))) +#define TRC_PV_HYPERCALL_V2_ARG_MASK (0xfff00000) #define TRC_SHADOW_NOT_SHADOW (TRC_SHADOW + 1) #define TRC_SHADOW_FAST_PROPAGATE (TRC_SHADOW + 2) diff --git a/xen/include/xen/trace.h b/xen/include/xen/trace.h index b32f6c5..f601aeb 100644 --- a/xen/include/xen/trace.h +++ b/xen/include/xen/trace.h @@ -44,6 +44,8 @@ static inline void trace_var(u32 event, int cycles, int extra, __trace_var(event, cycles, extra, extra_data); } +void __trace_hypercall(unsigned long call, const unsigned long *args); + /* Convenience macros for calling the trace function. */ #define TRACE_0D(_e) \ do { \ -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 17:47:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 17:47:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIk5S-0002O1-Jc; Mon, 01 Oct 2012 17:47:22 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIk5Q-0002Nl-RV for xen-devel@lists.xensource.com; Mon, 01 Oct 2012 17:47:21 +0000 Received: from [85.158.139.211:44755] by server-10.bemta-5.messagelabs.com id A7/95-16911-827D9605; Mon, 01 Oct 2012 17:47:20 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-13.tower-206.messagelabs.com!1349113638!16676780!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzkwMjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18673 invoked from network); 1 Oct 2012 17:47:19 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 17:47:19 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="209915477" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 17:47:17 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 13:47:17 -0400 Received: from qabil.uk.xensource.com ([10.80.2.76]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TIk5M-0007qB-QU; Mon, 01 Oct 2012 18:47:16 +0100 From: David Vrabel To: xen-devel@lists.xensource.com Date: Mon, 1 Oct 2012 18:47:08 +0100 Message-ID: <1349113629-6338-3-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1349113629-6338-1-git-send-email-david.vrabel@citrix.com> References: <1349113629-6338-1-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Cc: David Vrabel Subject: [Xen-devel] [PATCH 2/3] trace: improve usefulness of hypercall trace record X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: David Vrabel Trace hypercalls using a more useful trace record format. The EIP field is removed (it was always somewhere in the hypercall page) and include selected hypercall arguments (e.g., the number of calls in a multicall, and the number of PTE updates in an mmu_update etc.). 12 bits in the first extra word are used to indicate which arguments are present in the record and what size they are (32 or 64-bit). This is an incompatible record format so a new event ID is used so tools can distinguish between the two formats. Signed-off-by: David Vrabel Acked-by: George Dunlap --- tools/xentrace/formats | 1 + tools/xentrace/xentrace_format | 6 ++++ xen/arch/x86/trace.c | 35 +++++++++++--------------- xen/common/trace.c | 52 ++++++++++++++++++++++++++++++++++++++++ xen/include/public/trace.h | 30 +++++++++++++++++++++++ xen/include/xen/trace.h | 2 + 6 files changed, 106 insertions(+), 20 deletions(-) diff --git a/tools/xentrace/formats b/tools/xentrace/formats index 71220c0..fa935c8 100644 --- a/tools/xentrace/formats +++ b/tools/xentrace/formats @@ -104,6 +104,7 @@ 0x0020110b CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation [ addr = 0x%(4)08x%(3)08x, rip = 0x%(6)08x%(5)08x, npte = 0x%(2)08x%(1)08x ] 0x0020100c CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation_pae [ addr = 0x%(3)08x, eip = 0x%(4)08x, npte = 0x%(2)08x%(1)08x ] 0x0020110c CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation_pae [ addr = 0x%(4)08x%(3)08x, rip = 0x%(6)08x%(5)08x, npte = 0x%(2)08x%(1)08x ] +0x0020100d CPU%(cpu)d %(tsc)d (+%(reltsc)8d) hypercall [ op = 0x%(1)08x ] 0x0040f001 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) shadow_not_shadow [ gl1e = 0x%(2)08x%(1)08x, va = 0x%(3)08x, flags = 0x%(4)08x ] 0x0040f101 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) shadow_not_shadow [ gl1e = 0x%(2)08x%(1)08x, va = 0x%(4)08x%(3)08x, flags = 0x%(5)08x ] diff --git a/tools/xentrace/xentrace_format b/tools/xentrace/xentrace_format index e13b05b..bdcab09 100644 --- a/tools/xentrace/xentrace_format +++ b/tools/xentrace/xentrace_format @@ -111,6 +111,8 @@ D7REC = "IIIIIII" last_tsc = [0] TRC_TRACE_IRQ = 0x1f004 +TRC_PV_HYPERCALL_V2 = 0x20100d + NR_VECTORS = 256 irq_measure = [{'count':0, 'tot_cycles':0, 'max_cycles':0}] * NR_VECTORS @@ -197,6 +199,10 @@ while not interrupted: d3 = irq_measure[d1]['tot_cycles'] d4 = irq_measure[d1]['max_cycles'] + if event == TRC_PV_HYPERCALL_V2: + # Mask off the argument present bits. + d1 &= 0x000fffff + #tsc = (tscH<<32) | tscL #print i, tsc diff --git a/xen/arch/x86/trace.c b/xen/arch/x86/trace.c index 27fe150..f2c75bc 100644 --- a/xen/arch/x86/trace.c +++ b/xen/arch/x86/trace.c @@ -9,33 +9,28 @@ void trace_hypercall(void) { struct cpu_user_regs *regs = guest_cpu_user_regs(); + unsigned long args[6]; if ( is_pv_32on64_vcpu(current) ) { - struct { - u32 eip,eax; - } __attribute__((packed)) d; - - d.eip = regs->eip; - d.eax = regs->eax; - - __trace_var(TRC_PV_HYPERCALL, 1, sizeof(d), &d); + args[0] = regs->ebx; + args[1] = regs->ecx; + args[2] = regs->edx; + args[3] = regs->esi; + args[4] = regs->edi; + args[5] = regs->ebp; } else { - struct { - unsigned long eip; - u32 eax; - } __attribute__((packed)) d; - u32 event; - - event = TRC_PV_HYPERCALL; - event |= TRC_64_FLAG; - d.eip = regs->eip; - d.eax = regs->eax; - - __trace_var(event, 1/*tsc*/, sizeof(d), &d); + args[0] = regs->rdi; + args[1] = regs->rsi; + args[2] = regs->rdx; + args[3] = regs->r10; + args[4] = regs->r8; + args[5] = regs->r9; } + + __trace_hypercall(regs->eax, args); } void __trace_pv_trap(int trapnr, unsigned long eip, diff --git a/xen/common/trace.c b/xen/common/trace.c index cacaeb2..57a5a36 100644 --- a/xen/common/trace.c +++ b/xen/common/trace.c @@ -816,6 +816,58 @@ unlock: tasklet_schedule(&trace_notify_dom0_tasklet); } +void __trace_hypercall(unsigned long op, const unsigned long *args) +{ + struct { + uint32_t op; + uint32_t args[6]; + } __attribute__((packed)) d; + uint32_t *a = d.args; + +#define APPEND_ARG32(i) \ + do { \ + unsigned i_ = (i); \ + *a++ = args[(i_)]; \ + d.op |= TRC_PV_HYPERCALL_V2_ARG_32(i_); \ + } while( 0 ) + + /* + * This shouldn't happen as @op should be small enough but just in + * case, warn if the argument bits in the trace record would + * clobber the hypercall op. + */ + WARN_ON(op & TRC_PV_HYPERCALL_V2_ARG_MASK); + + d.op = op; + + switch ( op ) + { + case __HYPERVISOR_mmu_update: + APPEND_ARG32(1); /* count */ + break; + case __HYPERVISOR_multicall: + APPEND_ARG32(1); /* count */ + break; + case __HYPERVISOR_grant_table_op: + APPEND_ARG32(0); /* cmd */ + APPEND_ARG32(2); /* count */ + break; + case __HYPERVISOR_vcpu_op: + APPEND_ARG32(0); /* cmd */ + APPEND_ARG32(1); /* vcpuid */ + break; + case __HYPERVISOR_mmuext_op: + APPEND_ARG32(1); /* count */ + break; + case __HYPERVISOR_sched_op: + APPEND_ARG32(0); /* cmd */ + break; + } + + __trace_var(TRC_PV_HYPERCALL_V2, 1, + sizeof(uint32_t) * (1 + (a - d.args)), &d); +} + /* * Local variables: * mode: C diff --git a/xen/include/public/trace.h b/xen/include/public/trace.h index 1f154bb..ef43b23 100644 --- a/xen/include/public/trace.h +++ b/xen/include/public/trace.h @@ -107,6 +107,36 @@ #define TRC_PV_GDT_LDT_MAPPING_FAULT (TRC_PV_ENTRY + 10) #define TRC_PV_PTWR_EMULATION (TRC_PV_ENTRY + 11) #define TRC_PV_PTWR_EMULATION_PAE (TRC_PV_ENTRY + 12) +#define TRC_PV_HYPERCALL_V2 (TRC_PV_ENTRY + 13) + +/* + * TRC_PV_HYPERCALL_V2 format + * + * Only some of the hypercall argument are recorded. Bit fields A0 to + * A5 in the first extra word are set if the argument is present and + * the arguments themselves are packed sequentially in the following + * words. + * + * The TRC_64_FLAG bit is not set for these events (even if there are + * 64-bit arguments in the record). + * + * Word + * 0 bit 31 30|29 28|27 26|25 24|23 22|21 20|19 ... 0 + * A5 |A4 |A3 |A2 |A1 |A0 |Hypercall op + * 1 First 32 bit (or low word of first 64 bit) arg in record + * 2 Second 32 bit (or high word of first 64 bit) arg in record + * ... + * + * A0-A5 bitfield values: + * + * 00b Argument not present + * 01b 32-bit argument present + * 10b 64-bit argument present + * 11b Reserved + */ +#define TRC_PV_HYPERCALL_V2_ARG_32(i) (0x1 << (20 + 2*(i))) +#define TRC_PV_HYPERCALL_V2_ARG_64(i) (0x2 << (20 + 2*(i))) +#define TRC_PV_HYPERCALL_V2_ARG_MASK (0xfff00000) #define TRC_SHADOW_NOT_SHADOW (TRC_SHADOW + 1) #define TRC_SHADOW_FAST_PROPAGATE (TRC_SHADOW + 2) diff --git a/xen/include/xen/trace.h b/xen/include/xen/trace.h index b32f6c5..f601aeb 100644 --- a/xen/include/xen/trace.h +++ b/xen/include/xen/trace.h @@ -44,6 +44,8 @@ static inline void trace_var(u32 event, int cycles, int extra, __trace_var(event, cycles, extra, extra_data); } +void __trace_hypercall(unsigned long call, const unsigned long *args); + /* Convenience macros for calling the trace function. */ #define TRACE_0D(_e) \ do { \ -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 17:54:11 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 17:54:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIkBu-00030t-AI; Mon, 01 Oct 2012 17:54:02 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIkBs-00030S-41 for xen-devel@lists.xensource.com; Mon, 01 Oct 2012 17:54:00 +0000 Received: from [85.158.139.83:24727] by server-8.bemta-5.messagelabs.com id 2C/E9-18073-7B8D9605; Mon, 01 Oct 2012 17:53:59 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1349114035!18841694!3 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzkwMjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19770 invoked from network); 1 Oct 2012 17:53:58 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 17:53:58 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="209916213" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 17:53:54 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 13:53:54 -0400 Received: from qabil.uk.xensource.com ([10.80.2.76]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TIkBl-0007vv-VX; Mon, 01 Oct 2012 18:53:53 +0100 MIME-Version: 1.0 X-Mercurial-Node: c57d9d4c7f3dc8eab759621b558bf815684b1244 Message-ID: In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Mon, 1 Oct 2012 18:52:39 +0100 From: David Vrabel To: xen-devel@lists.xensource.com Cc: David Vrabel , George Dunlap Subject: [Xen-devel] [PATCH 1 of 2] xenalyze: decode PV_HYPERCALL_V2 records X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Newer version of Xen produce TRC_PV_HYPERCALL_V2 records instead of the older TRC_PV_HYPERCALL format. This updated format doesn't included the IP but it does include select hypercall arguments. Signed-off-by: David Vrabel diff --git a/pv.h b/pv.h new file mode 100644 --- /dev/null +++ b/pv.h @@ -0,0 +1,41 @@ +/* + * PV event decoding. + * + * Copyright (C) 2012 Citrix Systems R&D Ltd. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms and conditions of the GNU General Public License, + * version 2, as published by the Free Software Foundation. + */ +#ifndef __PV_H + +#include "analyze.h" +#include "trace.h" + +#ifdef __cplusplus +extern "C" { +#endif + +#define ARG_MISSING 0x0 +#define ARG_32BIT 0x1 +#define ARG_64BIT 0x2 + +#define MMU_UPDATE_PREEMPTED (~(~0U>>1)) + +static inline uint32_t pv_hypercall_op(const struct record_info *ri) +{ + return ri->d[0] & ~TRC_PV_HYPERCALL_V2_ARG_MASK; +} + +static inline int pv_hypercall_arg_present(const struct record_info *ri, int arg) +{ + return (ri->d[0] >> (20 + 2*arg)) & 0x3; +} + +uint64_t pv_hypercall_arg(const struct record_info *ri, int i); + +#ifdef __cplusplus +} /* extern "C" */ +#endif + +#endif diff --git a/xenalyze.c b/xenalyze.c --- a/xenalyze.c +++ b/xenalyze.c @@ -32,6 +32,7 @@ #include "trace.h" #include "analyze.h" #include "mread.h" +#include "pv.h" #include #include #include @@ -1485,6 +1486,7 @@ enum { PV_GDT_LDT_MAPPING_FAULT, PV_PTWR_EMULATION, PV_PTWR_EMULATION_PAE, + PV_HYPERCALL_V2 = 13, PV_MAX }; @@ -1499,7 +1501,9 @@ char *pv_name[PV_MAX] = { [PV_PAGING_FIXUP]="paging fixup", [PV_GDT_LDT_MAPPING_FAULT]="gdt/ldt mapping fault", [PV_PTWR_EMULATION]="ptwr", - [PV_PTWR_EMULATION_PAE]="ptwr(pae)" + [PV_PTWR_EMULATION_PAE]="ptwr(pae)", + [PV_HYPERCALL_V2]="hypercall", + [PV_HYPERCALL_SUBCALL]="hypercall (subcall)", }; #define PV_HYPERCALL_MAX 56 @@ -6500,10 +6504,20 @@ void pv_summary(struct pv_data *pv) { printf("PV events:\n"); for(i=0; icount[i]) - printf(" %s %d\n", pv_name[i], pv->count[i]); + int count; + + count = pv->count[i]; + if (i == PV_HYPERCALL_V2) + count += pv->count[PV_HYPERCALL_SUBCALL]; + + if (count == 0) + continue; + + printf(" %s %d\n", pv_name[i], count); + switch(i) { case PV_HYPERCALL: + case PV_HYPERCALL_V2: for(j=0; jhypercall_count[j]) printf(" %-29s[%2d]: %6d\n", @@ -6523,6 +6537,168 @@ void pv_summary(struct pv_data *pv) { } } +uint64_t pv_hypercall_arg(const struct record_info *ri, int arg) +{ + int i, word; + + for (i = 0, word = 1; i < 6 && word < ri->extra_words; i++) { + int present = pv_hypercall_arg_present(ri, i); + + /* Is this the argument we're looking for? */ + if (i == arg) { + switch (present) { + case ARG_MISSING: + return 0; + case ARG_32BIT: + return ri->d[word]; + case ARG_64BIT: + return ((uint64_t)ri->d[word + 1] << 32) | ri->d[word]; + } + } + + /* Skip over any words for this argument. */ + word += present; + } + + return 0; +} + +static void pv_hypercall_print_args(const struct record_info *ri) +{ + int i, word; + + for (i = 0, word = 1; i < 6 && word < ri->extra_words; i++) { + int present = pv_hypercall_arg_present(ri, i); + + switch (present) { + case ARG_MISSING: + printf(" ??"); + break; + case ARG_32BIT: + printf(" %08x", ri->d[word]); + break; + case ARG_64BIT: + printf(" %016"PRIu64"", ((uint64_t)ri->d[word + 1] << 32) | ri->d[word]); + break; + } + + word += present; + } +} + +static const char *grant_table_op_cmd_to_str(uint32_t cmd) +{ + const char *cmd_str[] = { + "map_grant_ref", "unmap_grant_ref", "setup_table", "dump_table", + "transfer", "copy", "query_size", "unmap_and_replace", + "set_version", "get_status_frames", "get_version", "swap_grant_ref", + }; + static char buf[32]; + + if (cmd <= 11) + return cmd_str[cmd]; + + snprintf(buf, sizeof(buf), "unknown (%d)", cmd); + return buf; +} + +static const char *vcpu_op_cmd_to_str(uint32_t cmd) +{ + const char *cmd_str[] = { + "initialise", "up", "down", "is_up", "get_runstate_info", + "register_runstate_memory_area", "set_periodic_timer", + "stop_periodic_timer", "set_singleshot_timer", "stop_singleshot_timer", + "register_vcpu_info", "send_nmi", "get_physid", + "register_vcpu_time_memory_area", + }; + static char buf[32]; + + if (cmd <= 13) + return cmd_str[cmd]; + + snprintf(buf, sizeof(buf), "unknown (%d)", cmd); + return buf; +} + +static const char *sched_op_cmd_to_str(uint32_t cmd) +{ + const char *cmd_str[] = { + "yield", "block", "shutdown", "poll", "remote_shutdown", "shutdown_code", + "watchdog", + }; + static char buf[32]; + + if (cmd <= 6) + return cmd_str[cmd]; + + snprintf(buf, sizeof(buf), "unknown (%d)", cmd); + return buf; +} + +void pv_hypercall_v2_process(struct record_info *ri, struct pv_data *pv) +{ + int op = pv_hypercall_op(ri); + + if(opt.summary_info) { + if(op < PV_HYPERCALL_MAX) + pv->hypercall_count[op]++; + } + + if(opt.dump_all) { + if(op < HYPERCALL_MAX) + printf(" %s hypercall %2x (%s)", + ri->dump_header, op, hypercall_name[op]); + else + printf(" %s hypercall %2x", + ri->dump_header, op); + switch(op) { + case HYPERCALL_mmu_update: + { + uint32_t count = pv_hypercall_arg(ri, 1); + printf(" %d updates%s", count & ~MMU_UPDATE_PREEMPTED, + (count & MMU_UPDATE_PREEMPTED) ? " (preempted)" : ""); + } + break; + case HYPERCALL_multicall: + { + uint32_t calls = pv_hypercall_arg(ri, 1); + printf(" %d calls", calls); + } + break; + case HYPERCALL_grant_table_op: + { + uint32_t cmd = pv_hypercall_arg(ri, 0); + uint32_t count = pv_hypercall_arg(ri, 2); + printf(" %s %d ops", grant_table_op_cmd_to_str(cmd), count); + } + break; + case HYPERCALL_vcpu_op: + { + uint32_t cmd = pv_hypercall_arg(ri, 0); + uint32_t vcpuid = pv_hypercall_arg(ri, 1); + printf(" %s vcpu %d", vcpu_op_cmd_to_str(cmd), vcpuid); + } + break; + case HYPERCALL_mmuext_op: + { + uint32_t count = pv_hypercall_arg(ri, 1); + printf(" %d ops", count); + } + break; + case HYPERCALL_sched_op: + { + uint32_t cmd = pv_hypercall_arg(ri, 0); + printf(" %s", sched_op_cmd_to_str(cmd)); + } + break; + default: + pv_hypercall_print_args(ri); + break; + } + printf("\n"); + } +} + void pv_process(struct pcpu_info *p) { struct record_info *ri = &p->ri; @@ -6555,9 +6731,9 @@ void pv_process(struct pcpu_info *p) case PV_PTWR_EMULATION_PAE: pv_ptwr_emulation_process(ri, pv); break; - case PV_PAGE_FAULT: - //pv_pf_process(ri, pv); - //break; + case PV_HYPERCALL_V2: + pv_hypercall_v2_process(ri, pv); + break; default: pv_generic_process(ri, pv); break; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 17:54:11 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 17:54:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIkBu-00030t-AI; Mon, 01 Oct 2012 17:54:02 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIkBs-00030S-41 for xen-devel@lists.xensource.com; Mon, 01 Oct 2012 17:54:00 +0000 Received: from [85.158.139.83:24727] by server-8.bemta-5.messagelabs.com id 2C/E9-18073-7B8D9605; Mon, 01 Oct 2012 17:53:59 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1349114035!18841694!3 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzkwMjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19770 invoked from network); 1 Oct 2012 17:53:58 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 17:53:58 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="209916213" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 17:53:54 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 13:53:54 -0400 Received: from qabil.uk.xensource.com ([10.80.2.76]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TIkBl-0007vv-VX; Mon, 01 Oct 2012 18:53:53 +0100 MIME-Version: 1.0 X-Mercurial-Node: c57d9d4c7f3dc8eab759621b558bf815684b1244 Message-ID: In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Mon, 1 Oct 2012 18:52:39 +0100 From: David Vrabel To: xen-devel@lists.xensource.com Cc: David Vrabel , George Dunlap Subject: [Xen-devel] [PATCH 1 of 2] xenalyze: decode PV_HYPERCALL_V2 records X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Newer version of Xen produce TRC_PV_HYPERCALL_V2 records instead of the older TRC_PV_HYPERCALL format. This updated format doesn't included the IP but it does include select hypercall arguments. Signed-off-by: David Vrabel diff --git a/pv.h b/pv.h new file mode 100644 --- /dev/null +++ b/pv.h @@ -0,0 +1,41 @@ +/* + * PV event decoding. + * + * Copyright (C) 2012 Citrix Systems R&D Ltd. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms and conditions of the GNU General Public License, + * version 2, as published by the Free Software Foundation. + */ +#ifndef __PV_H + +#include "analyze.h" +#include "trace.h" + +#ifdef __cplusplus +extern "C" { +#endif + +#define ARG_MISSING 0x0 +#define ARG_32BIT 0x1 +#define ARG_64BIT 0x2 + +#define MMU_UPDATE_PREEMPTED (~(~0U>>1)) + +static inline uint32_t pv_hypercall_op(const struct record_info *ri) +{ + return ri->d[0] & ~TRC_PV_HYPERCALL_V2_ARG_MASK; +} + +static inline int pv_hypercall_arg_present(const struct record_info *ri, int arg) +{ + return (ri->d[0] >> (20 + 2*arg)) & 0x3; +} + +uint64_t pv_hypercall_arg(const struct record_info *ri, int i); + +#ifdef __cplusplus +} /* extern "C" */ +#endif + +#endif diff --git a/xenalyze.c b/xenalyze.c --- a/xenalyze.c +++ b/xenalyze.c @@ -32,6 +32,7 @@ #include "trace.h" #include "analyze.h" #include "mread.h" +#include "pv.h" #include #include #include @@ -1485,6 +1486,7 @@ enum { PV_GDT_LDT_MAPPING_FAULT, PV_PTWR_EMULATION, PV_PTWR_EMULATION_PAE, + PV_HYPERCALL_V2 = 13, PV_MAX }; @@ -1499,7 +1501,9 @@ char *pv_name[PV_MAX] = { [PV_PAGING_FIXUP]="paging fixup", [PV_GDT_LDT_MAPPING_FAULT]="gdt/ldt mapping fault", [PV_PTWR_EMULATION]="ptwr", - [PV_PTWR_EMULATION_PAE]="ptwr(pae)" + [PV_PTWR_EMULATION_PAE]="ptwr(pae)", + [PV_HYPERCALL_V2]="hypercall", + [PV_HYPERCALL_SUBCALL]="hypercall (subcall)", }; #define PV_HYPERCALL_MAX 56 @@ -6500,10 +6504,20 @@ void pv_summary(struct pv_data *pv) { printf("PV events:\n"); for(i=0; icount[i]) - printf(" %s %d\n", pv_name[i], pv->count[i]); + int count; + + count = pv->count[i]; + if (i == PV_HYPERCALL_V2) + count += pv->count[PV_HYPERCALL_SUBCALL]; + + if (count == 0) + continue; + + printf(" %s %d\n", pv_name[i], count); + switch(i) { case PV_HYPERCALL: + case PV_HYPERCALL_V2: for(j=0; jhypercall_count[j]) printf(" %-29s[%2d]: %6d\n", @@ -6523,6 +6537,168 @@ void pv_summary(struct pv_data *pv) { } } +uint64_t pv_hypercall_arg(const struct record_info *ri, int arg) +{ + int i, word; + + for (i = 0, word = 1; i < 6 && word < ri->extra_words; i++) { + int present = pv_hypercall_arg_present(ri, i); + + /* Is this the argument we're looking for? */ + if (i == arg) { + switch (present) { + case ARG_MISSING: + return 0; + case ARG_32BIT: + return ri->d[word]; + case ARG_64BIT: + return ((uint64_t)ri->d[word + 1] << 32) | ri->d[word]; + } + } + + /* Skip over any words for this argument. */ + word += present; + } + + return 0; +} + +static void pv_hypercall_print_args(const struct record_info *ri) +{ + int i, word; + + for (i = 0, word = 1; i < 6 && word < ri->extra_words; i++) { + int present = pv_hypercall_arg_present(ri, i); + + switch (present) { + case ARG_MISSING: + printf(" ??"); + break; + case ARG_32BIT: + printf(" %08x", ri->d[word]); + break; + case ARG_64BIT: + printf(" %016"PRIu64"", ((uint64_t)ri->d[word + 1] << 32) | ri->d[word]); + break; + } + + word += present; + } +} + +static const char *grant_table_op_cmd_to_str(uint32_t cmd) +{ + const char *cmd_str[] = { + "map_grant_ref", "unmap_grant_ref", "setup_table", "dump_table", + "transfer", "copy", "query_size", "unmap_and_replace", + "set_version", "get_status_frames", "get_version", "swap_grant_ref", + }; + static char buf[32]; + + if (cmd <= 11) + return cmd_str[cmd]; + + snprintf(buf, sizeof(buf), "unknown (%d)", cmd); + return buf; +} + +static const char *vcpu_op_cmd_to_str(uint32_t cmd) +{ + const char *cmd_str[] = { + "initialise", "up", "down", "is_up", "get_runstate_info", + "register_runstate_memory_area", "set_periodic_timer", + "stop_periodic_timer", "set_singleshot_timer", "stop_singleshot_timer", + "register_vcpu_info", "send_nmi", "get_physid", + "register_vcpu_time_memory_area", + }; + static char buf[32]; + + if (cmd <= 13) + return cmd_str[cmd]; + + snprintf(buf, sizeof(buf), "unknown (%d)", cmd); + return buf; +} + +static const char *sched_op_cmd_to_str(uint32_t cmd) +{ + const char *cmd_str[] = { + "yield", "block", "shutdown", "poll", "remote_shutdown", "shutdown_code", + "watchdog", + }; + static char buf[32]; + + if (cmd <= 6) + return cmd_str[cmd]; + + snprintf(buf, sizeof(buf), "unknown (%d)", cmd); + return buf; +} + +void pv_hypercall_v2_process(struct record_info *ri, struct pv_data *pv) +{ + int op = pv_hypercall_op(ri); + + if(opt.summary_info) { + if(op < PV_HYPERCALL_MAX) + pv->hypercall_count[op]++; + } + + if(opt.dump_all) { + if(op < HYPERCALL_MAX) + printf(" %s hypercall %2x (%s)", + ri->dump_header, op, hypercall_name[op]); + else + printf(" %s hypercall %2x", + ri->dump_header, op); + switch(op) { + case HYPERCALL_mmu_update: + { + uint32_t count = pv_hypercall_arg(ri, 1); + printf(" %d updates%s", count & ~MMU_UPDATE_PREEMPTED, + (count & MMU_UPDATE_PREEMPTED) ? " (preempted)" : ""); + } + break; + case HYPERCALL_multicall: + { + uint32_t calls = pv_hypercall_arg(ri, 1); + printf(" %d calls", calls); + } + break; + case HYPERCALL_grant_table_op: + { + uint32_t cmd = pv_hypercall_arg(ri, 0); + uint32_t count = pv_hypercall_arg(ri, 2); + printf(" %s %d ops", grant_table_op_cmd_to_str(cmd), count); + } + break; + case HYPERCALL_vcpu_op: + { + uint32_t cmd = pv_hypercall_arg(ri, 0); + uint32_t vcpuid = pv_hypercall_arg(ri, 1); + printf(" %s vcpu %d", vcpu_op_cmd_to_str(cmd), vcpuid); + } + break; + case HYPERCALL_mmuext_op: + { + uint32_t count = pv_hypercall_arg(ri, 1); + printf(" %d ops", count); + } + break; + case HYPERCALL_sched_op: + { + uint32_t cmd = pv_hypercall_arg(ri, 0); + printf(" %s", sched_op_cmd_to_str(cmd)); + } + break; + default: + pv_hypercall_print_args(ri); + break; + } + printf("\n"); + } +} + void pv_process(struct pcpu_info *p) { struct record_info *ri = &p->ri; @@ -6555,9 +6731,9 @@ void pv_process(struct pcpu_info *p) case PV_PTWR_EMULATION_PAE: pv_ptwr_emulation_process(ri, pv); break; - case PV_PAGE_FAULT: - //pv_pf_process(ri, pv); - //break; + case PV_HYPERCALL_V2: + pv_hypercall_v2_process(ri, pv); + break; default: pv_generic_process(ri, pv); break; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 17:54:11 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 17:54:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIkBs-00030c-H0; Mon, 01 Oct 2012 17:54:00 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIkBq-00030F-GF for xen-devel@lists.xensource.com; Mon, 01 Oct 2012 17:53:58 +0000 Received: from [85.158.139.83:63404] by server-13.bemta-5.messagelabs.com id 53/5E-16359-5B8D9605; Mon, 01 Oct 2012 17:53:57 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1349114035!18841694!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzkwMjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19716 invoked from network); 1 Oct 2012 17:53:57 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 17:53:57 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="209916211" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 17:53:54 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 13:53:54 -0400 Received: from qabil.uk.xensource.com ([10.80.2.76]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TIkBl-0007vv-V7; Mon, 01 Oct 2012 18:53:53 +0100 MIME-Version: 1.0 Message-ID: User-Agent: Mercurial-patchbomb/1.6.4 Date: Mon, 1 Oct 2012 18:52:38 +0100 From: David Vrabel To: xen-devel@lists.xensource.com Cc: David Vrabel , George Dunlap Subject: [Xen-devel] [PATCH 0 of 2] xenalyze: decode new hypercall trace records X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This series allows xenalyze to decode the new PV_HYPERCALL_V2 and PV_HYPERCALL_SUBCALL trace records being proposed for Xen 4.3. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 17:54:11 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 17:54:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIkBs-00030c-H0; Mon, 01 Oct 2012 17:54:00 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIkBq-00030F-GF for xen-devel@lists.xensource.com; Mon, 01 Oct 2012 17:53:58 +0000 Received: from [85.158.139.83:63404] by server-13.bemta-5.messagelabs.com id 53/5E-16359-5B8D9605; Mon, 01 Oct 2012 17:53:57 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1349114035!18841694!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzkwMjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19716 invoked from network); 1 Oct 2012 17:53:57 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 17:53:57 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="209916211" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 17:53:54 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 13:53:54 -0400 Received: from qabil.uk.xensource.com ([10.80.2.76]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TIkBl-0007vv-V7; Mon, 01 Oct 2012 18:53:53 +0100 MIME-Version: 1.0 Message-ID: User-Agent: Mercurial-patchbomb/1.6.4 Date: Mon, 1 Oct 2012 18:52:38 +0100 From: David Vrabel To: xen-devel@lists.xensource.com Cc: David Vrabel , George Dunlap Subject: [Xen-devel] [PATCH 0 of 2] xenalyze: decode new hypercall trace records X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This series allows xenalyze to decode the new PV_HYPERCALL_V2 and PV_HYPERCALL_SUBCALL trace records being proposed for Xen 4.3. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 17:54:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 17:54:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIkBs-00030k-Sp; Mon, 01 Oct 2012 17:54:00 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIkBr-00030H-7h for xen-devel@lists.xensource.com; Mon, 01 Oct 2012 17:53:59 +0000 Received: from [85.158.139.83:24670] by server-10.bemta-5.messagelabs.com id FA/3C-16911-6B8D9605; Mon, 01 Oct 2012 17:53:58 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1349114035!18841694!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzkwMjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19745 invoked from network); 1 Oct 2012 17:53:57 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 17:53:57 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="209916212" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 17:53:54 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 13:53:54 -0400 Received: from qabil.uk.xensource.com ([10.80.2.76]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TIkBl-0007vv-Vw; Mon, 01 Oct 2012 18:53:53 +0100 MIME-Version: 1.0 X-Mercurial-Node: b5bd6833f6344294d62812264aa8d4e48bc16744 Message-ID: In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Mon, 1 Oct 2012 18:52:40 +0100 From: David Vrabel To: xen-devel@lists.xensource.com Cc: David Vrabel , George Dunlap Subject: [Xen-devel] [PATCH 2 of 2] xenalyze: decode PV_HYPERCALL_SUBCALL events X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Decode the PV_HYPERCALL_SUBCALL events which are used for calls within a multicall hypercall. They are indented so its easier to see which multicall they were part of. Signed-off-by: David Vrabel --- diff --git a/xenalyze.c b/xenalyze.c --- a/xenalyze.c +++ b/xenalyze.c @@ -1487,6 +1487,7 @@ enum { PV_PTWR_EMULATION, PV_PTWR_EMULATION_PAE, PV_HYPERCALL_V2 = 13, + PV_HYPERCALL_SUBCALL = 14, PV_MAX }; @@ -6635,7 +6636,8 @@ static const char *sched_op_cmd_to_str(u return buf; } -void pv_hypercall_v2_process(struct record_info *ri, struct pv_data *pv) +void pv_hypercall_v2_process(struct record_info *ri, struct pv_data *pv, + const char *indent) { int op = pv_hypercall_op(ri); @@ -6646,11 +6648,11 @@ void pv_hypercall_v2_process(struct reco if(opt.dump_all) { if(op < HYPERCALL_MAX) - printf(" %s hypercall %2x (%s)", - ri->dump_header, op, hypercall_name[op]); + printf(" %s%s hypercall %2x (%s)", + ri->dump_header, indent, op, hypercall_name[op]); else - printf(" %s hypercall %2x", - ri->dump_header, op); + printf(" %s%s hypercall %2x", + ri->dump_header, indent, op); switch(op) { case HYPERCALL_mmu_update: { @@ -6732,7 +6734,10 @@ void pv_process(struct pcpu_info *p) pv_ptwr_emulation_process(ri, pv); break; case PV_HYPERCALL_V2: - pv_hypercall_v2_process(ri, pv); + pv_hypercall_v2_process(ri, pv, ""); + break; + case PV_HYPERCALL_SUBCALL: + pv_hypercall_v2_process(ri, pv, " "); break; default: pv_generic_process(ri, pv); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 17:54:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 17:54:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIkBs-00030k-Sp; Mon, 01 Oct 2012 17:54:00 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIkBr-00030H-7h for xen-devel@lists.xensource.com; Mon, 01 Oct 2012 17:53:59 +0000 Received: from [85.158.139.83:24670] by server-10.bemta-5.messagelabs.com id FA/3C-16911-6B8D9605; Mon, 01 Oct 2012 17:53:58 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1349114035!18841694!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzkwMjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19745 invoked from network); 1 Oct 2012 17:53:57 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 17:53:57 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="209916212" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 17:53:54 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 13:53:54 -0400 Received: from qabil.uk.xensource.com ([10.80.2.76]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TIkBl-0007vv-Vw; Mon, 01 Oct 2012 18:53:53 +0100 MIME-Version: 1.0 X-Mercurial-Node: b5bd6833f6344294d62812264aa8d4e48bc16744 Message-ID: In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Mon, 1 Oct 2012 18:52:40 +0100 From: David Vrabel To: xen-devel@lists.xensource.com Cc: David Vrabel , George Dunlap Subject: [Xen-devel] [PATCH 2 of 2] xenalyze: decode PV_HYPERCALL_SUBCALL events X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Decode the PV_HYPERCALL_SUBCALL events which are used for calls within a multicall hypercall. They are indented so its easier to see which multicall they were part of. Signed-off-by: David Vrabel --- diff --git a/xenalyze.c b/xenalyze.c --- a/xenalyze.c +++ b/xenalyze.c @@ -1487,6 +1487,7 @@ enum { PV_PTWR_EMULATION, PV_PTWR_EMULATION_PAE, PV_HYPERCALL_V2 = 13, + PV_HYPERCALL_SUBCALL = 14, PV_MAX }; @@ -6635,7 +6636,8 @@ static const char *sched_op_cmd_to_str(u return buf; } -void pv_hypercall_v2_process(struct record_info *ri, struct pv_data *pv) +void pv_hypercall_v2_process(struct record_info *ri, struct pv_data *pv, + const char *indent) { int op = pv_hypercall_op(ri); @@ -6646,11 +6648,11 @@ void pv_hypercall_v2_process(struct reco if(opt.dump_all) { if(op < HYPERCALL_MAX) - printf(" %s hypercall %2x (%s)", - ri->dump_header, op, hypercall_name[op]); + printf(" %s%s hypercall %2x (%s)", + ri->dump_header, indent, op, hypercall_name[op]); else - printf(" %s hypercall %2x", - ri->dump_header, op); + printf(" %s%s hypercall %2x", + ri->dump_header, indent, op); switch(op) { case HYPERCALL_mmu_update: { @@ -6732,7 +6734,10 @@ void pv_process(struct pcpu_info *p) pv_ptwr_emulation_process(ri, pv); break; case PV_HYPERCALL_V2: - pv_hypercall_v2_process(ri, pv); + pv_hypercall_v2_process(ri, pv, ""); + break; + case PV_HYPERCALL_SUBCALL: + pv_hypercall_v2_process(ri, pv, " "); break; default: pv_generic_process(ri, pv); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 18:42:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 18:42:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIkwI-0003uA-9o; Mon, 01 Oct 2012 18:41:58 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIkwG-0003u5-Ka for xen-devel@lists.xen.org; Mon, 01 Oct 2012 18:41:56 +0000 Received: from [85.158.143.35:63350] by server-3.bemta-4.messagelabs.com id E2/78-10986-3F3E9605; Mon, 01 Oct 2012 18:41:55 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-12.tower-21.messagelabs.com!1349116913!12622365!1 X-Originating-IP: [128.244.251.36] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG, UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25266 invoked from network); 1 Oct 2012 18:41:54 -0000 Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36) by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 18:41:54 -0000 Received: from ([128.244.207.89]) by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.154053510; Mon, 01 Oct 2012 14:41:44 -0400 Message-ID: <5069E396.5040205@jhuapl.edu> Date: Mon, 01 Oct 2012 14:40:22 -0400 From: Matthew Fioravante User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: George Dunlap References: <1348765860-11359-1-git-send-email-matthew.fioravante@jhuapl.edu> <1348765860-11359-3-git-send-email-matthew.fioravante@jhuapl.edu> <5065CAE9.30602@jhuapl.edu> <5065D333.6080600@jhuapl.edu> In-Reply-To: <5065D333.6080600@jhuapl.edu> X-Enigmail-Version: 1.4.4 Cc: "Ian.Campbell@citrix.com" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 11/11] add vtpm support to libxl X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5039706155493392055==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a cryptographically signed message in MIME format. --===============5039706155493392055== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090506050307040207000408" This is a cryptographically signed message in MIME format. --------------ms090506050307040207000408 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 09/28/2012 12:41 PM, Matthew Fioravante wrote: > On 09/28/2012 12:39 PM, George Dunlap wrote: >> On Fri, Sep 28, 2012 at 5:06 PM, Matthew Fioravante >> wrote: >>> On 09/28/2012 11:03 AM, George Dunlap wrote: >>>> On Thu, Sep 27, 2012 at 6:11 PM, Matthew Fioravante >>>> wrote: >>>>> This patch adds vtpm support to libxl. It adds vtpm parsing to conf= ig >>>>> files and 3 new xl commands: >>>>> vtpm-attach >>>>> vtpm-detach >>>>> vtpm-list >>>>> >>>>> Signed-off-by: Matthew Fioravante >>>> Overall looks good to me -- just a few comments below about the conf= ig >>>> file handling (see below). >>>> >>>> Thanks for all your work on this. >>>> >>>>> @@ -601,6 +605,8 @@ static void domcreate_bootloader_done(libxl__eg= c *egc, >>>>> static void domcreate_launch_dm(libxl__egc *egc, libxl__multidev *= aodevs, >>>>> int ret); >>>>> >>>>> +static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multide= v *multidev, >>>>> + int ret); >>>>> static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev = *aodevs, >>>>> int ret); >>>>> >>>>> @@ -1084,13 +1090,13 @@ static void domcreate_devmodel_started(libx= l__egc *egc, >>>>> if (d_config->num_nics > 0) { >>>>> /* Attach nics */ >>>>> libxl__multidev_begin(ao, &dcs->multidev); >>>>> - dcs->multidev.callback =3D domcreate_attach_pci; >>>>> + dcs->multidev.callback =3D domcreate_attach_vtpms; >>>> Wow -- what a weird convention you've had to try to figure out and >>>> modify here. Well done. :-) >>> It was really tricky. Is there no better way to handle asynchronous >>> code? This method seems really error prone and almost impossible to f= ollow. >> Well I didn't write it. :-) I haven't taken the time to figure out >> why it might have been written that way; but at first glance, I tend >> to agree with you. For about 10 minutes I was convinced you had made >> some kind of weird error, by sprinkling "vtpm" around things that >> obviously were supposed to be about nics and pci devices, until I >> realized you were just following the existing "call chain" convention.= >> >>>>> + p =3D strtok(buf2, ","); >>>>> + if (!p) >>>>> + goto skip_vtpm; >>>> Is the purpose of this so that you can have "empty" vtpm slots? >>>> (Since even when skipping, you still increment the num_vtpms counter= ?) >>> That would make a default vtpm with a randomly generated uuid and >>> backend=3Ddom0. Considering that were getting rid of the process mode= l, it >>> probably makes sense to force the user to specify a backend domain id= >>> because no vtpm device will ever connect to dom0 anymore. >> Ah, right. Either way is OK with me, but a comment would be useful. := -) >> >>>>> + } >>>>> + } else if(!strcmp(p, "uuid")) { >>>>> + if( libxl_uuid_from_string(&vtpm->uuid, p2 + 1= ) ) { >>>>> + fprintf(stderr, "Failed to parse vtpm UUID= : %s\n", p2 + 1); >>>>> + exit(1); >>>>> + } >>>>> + } >>>> If I'm parsing this right, it looks like you will just silently igno= re >>>> other arguments -- it seems like throwing an error would be better; >>>> especially to catch things like typos. Otherwise, if someone does >>>> something like "uid=3D[whatever]", it will act like uuid isn't there= and >>>> create a new one, instead of alerting the user to the fact that he'd= >>>> made a typo in the config file. >>> The behavior here is there if the user passes an invalid uuid string = it >>> will fail with a parse error, but if the user does not specify a uuid= at >>> all, one will be randomly generated. Random generation happens in the= >>> vtpm types constructor in the xl type system. >> I think you misunderstood my comment; I'm not actually talking about >> the uuid clause that's there, but the "none of the above" clause >> that's missing. The code says (in pseudocode): >> >> if("backend") >> parse backend; >> else if("uuid") >> parse uuid; >> >> But what if it's neither "backend" or "uuid", but something else -- >> say, "uid" or "backedn"? Then instead of giving an error, it will >> just skip that argument and go on to the next one; and if the user >> *intended* to type "backend" instead of "backedn", it will silently >> use the default, giving her no clue as to what the problem might be. >> I'm proposing adding (again in pseudocode): >> >> else >> error("Unrecognized argument: %s\n", p); >> >> Does that make sense? >> > Yeah, didn't see that. Good catch. >>> This brings up a bigger wart in the vtpm implementation. >> It's 5:30pm on a Friday, so I'm going to put off grokking the rest of >> this until Monday morning. :-) > Agreed, enjoy your weekend :) >> Have a good weekend, >> -George >> >>> Its kind of confusing now because the linux guest uses a tpmfront/bac= k >>> pair to talk to the vtpm, and then vtpm uses another tpmfront/back pa= ir >>> to talk to the manager. You have to specify the uuid on the vtpm's >>> tpmfront device because that is the device the manager sees. You do n= ot >>> have to specify one on the linux domains device. >>> >>> I'd argue that now, especially with the process model gone, the uuid >>> should be a parameter of the vtpm itself and not the tpmfront/back >>> communication channels. >>> >>> The problem is that this uuid needs to specified by the "control doma= in" >>> or dom0. By attaching the uuid to the device, the manager can trust t= he >>> uuid attached to whoever is trying to connect to him. >>> >>> One idea is to make the uuid a commandline parameter for the mini-os >>> domain and have the vtpm pass the id down to the manager. That means >>> however that any rogue domain could potentially connect to the manage= r >>> and send him someone elses uuid, and thus being able to access the vt= pms >>> stored secrets. >>> >>> However one could argue that no domain would be able to connect to th= e >>> manager to do this anyway because they would have to create a >>> tpmfront/back device pair and the only way to do that is to break int= o >>> the "control domain." If one can do this, then one could just as easi= ly >>> set their device uuid to whatever they want. >>> >>> I hope all that made sense. Do you see any flaws in my reasoning? If = so >>> I should probably get uuids out of the vtpm devices and simplify this= >>> whole thing. Actually thinking about it more, uuids have to be attached to the driver. If 2 vtpms connect to the manager, one could send the uuid of the other and get access to someone elses secrets. TL;DR version uuids must remain part of the driver. >>> >>>> -George >>> >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xen.org >>> http://lists.xen.org/xen-devel >>> > --------------ms090506050307040207000408 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4 NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50 ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz 4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTEyMTAwMTE4NDAyMlowIwYJKoZIhvcNAQkEMRYEFONcBoYD9Y69okB9 QYVcQfEIZ7AjMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAWgjR3CBH80QD34EIm0i4khcA98esTPuT6 DxQSxEzRiZmEIRVlvmgV6LLKJSGq+wVeL8/AWNqSL3W3VlPh76w8W05mEW3XPU1JokqkWYvQ uGUM8/I82dQ1UlFB7uoDcn6hAd3ej6px4vK+jYP+iFGWWKj48iEZ/5Yk3tBqlp8fNwAAAAAA AA== --------------ms090506050307040207000408-- --===============5039706155493392055== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============5039706155493392055==-- From xen-devel-bounces@lists.xen.org Mon Oct 01 18:42:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 18:42:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIkwI-0003uA-9o; Mon, 01 Oct 2012 18:41:58 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIkwG-0003u5-Ka for xen-devel@lists.xen.org; Mon, 01 Oct 2012 18:41:56 +0000 Received: from [85.158.143.35:63350] by server-3.bemta-4.messagelabs.com id E2/78-10986-3F3E9605; Mon, 01 Oct 2012 18:41:55 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-12.tower-21.messagelabs.com!1349116913!12622365!1 X-Originating-IP: [128.244.251.36] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG, UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25266 invoked from network); 1 Oct 2012 18:41:54 -0000 Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36) by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 18:41:54 -0000 Received: from ([128.244.207.89]) by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.154053510; Mon, 01 Oct 2012 14:41:44 -0400 Message-ID: <5069E396.5040205@jhuapl.edu> Date: Mon, 01 Oct 2012 14:40:22 -0400 From: Matthew Fioravante User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: George Dunlap References: <1348765860-11359-1-git-send-email-matthew.fioravante@jhuapl.edu> <1348765860-11359-3-git-send-email-matthew.fioravante@jhuapl.edu> <5065CAE9.30602@jhuapl.edu> <5065D333.6080600@jhuapl.edu> In-Reply-To: <5065D333.6080600@jhuapl.edu> X-Enigmail-Version: 1.4.4 Cc: "Ian.Campbell@citrix.com" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 11/11] add vtpm support to libxl X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5039706155493392055==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a cryptographically signed message in MIME format. --===============5039706155493392055== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090506050307040207000408" This is a cryptographically signed message in MIME format. --------------ms090506050307040207000408 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 09/28/2012 12:41 PM, Matthew Fioravante wrote: > On 09/28/2012 12:39 PM, George Dunlap wrote: >> On Fri, Sep 28, 2012 at 5:06 PM, Matthew Fioravante >> wrote: >>> On 09/28/2012 11:03 AM, George Dunlap wrote: >>>> On Thu, Sep 27, 2012 at 6:11 PM, Matthew Fioravante >>>> wrote: >>>>> This patch adds vtpm support to libxl. It adds vtpm parsing to conf= ig >>>>> files and 3 new xl commands: >>>>> vtpm-attach >>>>> vtpm-detach >>>>> vtpm-list >>>>> >>>>> Signed-off-by: Matthew Fioravante >>>> Overall looks good to me -- just a few comments below about the conf= ig >>>> file handling (see below). >>>> >>>> Thanks for all your work on this. >>>> >>>>> @@ -601,6 +605,8 @@ static void domcreate_bootloader_done(libxl__eg= c *egc, >>>>> static void domcreate_launch_dm(libxl__egc *egc, libxl__multidev *= aodevs, >>>>> int ret); >>>>> >>>>> +static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multide= v *multidev, >>>>> + int ret); >>>>> static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev = *aodevs, >>>>> int ret); >>>>> >>>>> @@ -1084,13 +1090,13 @@ static void domcreate_devmodel_started(libx= l__egc *egc, >>>>> if (d_config->num_nics > 0) { >>>>> /* Attach nics */ >>>>> libxl__multidev_begin(ao, &dcs->multidev); >>>>> - dcs->multidev.callback =3D domcreate_attach_pci; >>>>> + dcs->multidev.callback =3D domcreate_attach_vtpms; >>>> Wow -- what a weird convention you've had to try to figure out and >>>> modify here. Well done. :-) >>> It was really tricky. Is there no better way to handle asynchronous >>> code? This method seems really error prone and almost impossible to f= ollow. >> Well I didn't write it. :-) I haven't taken the time to figure out >> why it might have been written that way; but at first glance, I tend >> to agree with you. For about 10 minutes I was convinced you had made >> some kind of weird error, by sprinkling "vtpm" around things that >> obviously were supposed to be about nics and pci devices, until I >> realized you were just following the existing "call chain" convention.= >> >>>>> + p =3D strtok(buf2, ","); >>>>> + if (!p) >>>>> + goto skip_vtpm; >>>> Is the purpose of this so that you can have "empty" vtpm slots? >>>> (Since even when skipping, you still increment the num_vtpms counter= ?) >>> That would make a default vtpm with a randomly generated uuid and >>> backend=3Ddom0. Considering that were getting rid of the process mode= l, it >>> probably makes sense to force the user to specify a backend domain id= >>> because no vtpm device will ever connect to dom0 anymore. >> Ah, right. Either way is OK with me, but a comment would be useful. := -) >> >>>>> + } >>>>> + } else if(!strcmp(p, "uuid")) { >>>>> + if( libxl_uuid_from_string(&vtpm->uuid, p2 + 1= ) ) { >>>>> + fprintf(stderr, "Failed to parse vtpm UUID= : %s\n", p2 + 1); >>>>> + exit(1); >>>>> + } >>>>> + } >>>> If I'm parsing this right, it looks like you will just silently igno= re >>>> other arguments -- it seems like throwing an error would be better; >>>> especially to catch things like typos. Otherwise, if someone does >>>> something like "uid=3D[whatever]", it will act like uuid isn't there= and >>>> create a new one, instead of alerting the user to the fact that he'd= >>>> made a typo in the config file. >>> The behavior here is there if the user passes an invalid uuid string = it >>> will fail with a parse error, but if the user does not specify a uuid= at >>> all, one will be randomly generated. Random generation happens in the= >>> vtpm types constructor in the xl type system. >> I think you misunderstood my comment; I'm not actually talking about >> the uuid clause that's there, but the "none of the above" clause >> that's missing. The code says (in pseudocode): >> >> if("backend") >> parse backend; >> else if("uuid") >> parse uuid; >> >> But what if it's neither "backend" or "uuid", but something else -- >> say, "uid" or "backedn"? Then instead of giving an error, it will >> just skip that argument and go on to the next one; and if the user >> *intended* to type "backend" instead of "backedn", it will silently >> use the default, giving her no clue as to what the problem might be. >> I'm proposing adding (again in pseudocode): >> >> else >> error("Unrecognized argument: %s\n", p); >> >> Does that make sense? >> > Yeah, didn't see that. Good catch. >>> This brings up a bigger wart in the vtpm implementation. >> It's 5:30pm on a Friday, so I'm going to put off grokking the rest of >> this until Monday morning. :-) > Agreed, enjoy your weekend :) >> Have a good weekend, >> -George >> >>> Its kind of confusing now because the linux guest uses a tpmfront/bac= k >>> pair to talk to the vtpm, and then vtpm uses another tpmfront/back pa= ir >>> to talk to the manager. You have to specify the uuid on the vtpm's >>> tpmfront device because that is the device the manager sees. You do n= ot >>> have to specify one on the linux domains device. >>> >>> I'd argue that now, especially with the process model gone, the uuid >>> should be a parameter of the vtpm itself and not the tpmfront/back >>> communication channels. >>> >>> The problem is that this uuid needs to specified by the "control doma= in" >>> or dom0. By attaching the uuid to the device, the manager can trust t= he >>> uuid attached to whoever is trying to connect to him. >>> >>> One idea is to make the uuid a commandline parameter for the mini-os >>> domain and have the vtpm pass the id down to the manager. That means >>> however that any rogue domain could potentially connect to the manage= r >>> and send him someone elses uuid, and thus being able to access the vt= pms >>> stored secrets. >>> >>> However one could argue that no domain would be able to connect to th= e >>> manager to do this anyway because they would have to create a >>> tpmfront/back device pair and the only way to do that is to break int= o >>> the "control domain." If one can do this, then one could just as easi= ly >>> set their device uuid to whatever they want. >>> >>> I hope all that made sense. Do you see any flaws in my reasoning? If = so >>> I should probably get uuids out of the vtpm devices and simplify this= >>> whole thing. Actually thinking about it more, uuids have to be attached to the driver. If 2 vtpms connect to the manager, one could send the uuid of the other and get access to someone elses secrets. TL;DR version uuids must remain part of the driver. >>> >>>> -George >>> >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xen.org >>> http://lists.xen.org/xen-devel >>> > --------------ms090506050307040207000408 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4 NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50 ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz 4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTEyMTAwMTE4NDAyMlowIwYJKoZIhvcNAQkEMRYEFONcBoYD9Y69okB9 QYVcQfEIZ7AjMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAWgjR3CBH80QD34EIm0i4khcA98esTPuT6 DxQSxEzRiZmEIRVlvmgV6LLKJSGq+wVeL8/AWNqSL3W3VlPh76w8W05mEW3XPU1JokqkWYvQ uGUM8/I82dQ1UlFB7uoDcn6hAd3ej6px4vK+jYP+iFGWWKj48iEZ/5Yk3tBqlp8fNwAAAAAA AA== --------------ms090506050307040207000408-- --===============5039706155493392055== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============5039706155493392055==-- From xen-devel-bounces@lists.xen.org Mon Oct 01 19:19:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 19:19:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIlVj-0004Mb-9t; Mon, 01 Oct 2012 19:18:35 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIlVh-0004MU-6L for xen-devel@lists.xensource.com; Mon, 01 Oct 2012 19:18:33 +0000 Received: from [85.158.143.35:14933] by server-2.bemta-4.messagelabs.com id A3/8A-06610-88CE9605; Mon, 01 Oct 2012 19:18:32 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-12.tower-21.messagelabs.com!1349119111!12625875!1 X-Originating-IP: [81.169.146.162] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MTU1NzM=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MTU1NzM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24275 invoked from network); 1 Oct 2012 19:18:32 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162) by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 19:18:32 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGiy0IFwQ= X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-085-064.pools.arcor-ip.net [88.65.85.64]) by smtp.strato.de (jored mo21) (RZmta 30.20 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 60129bo91I7K7f ; Mon, 1 Oct 2012 21:18:25 +0200 (CEST) Received: by probook.site (Postfix, from userid 1000) id 46CBE1863E; Mon, 1 Oct 2012 21:18:24 +0200 (CEST) From: Olaf Hering To: Jeremy Fitzhardinge , Konrad Rzeszutek Wilk Date: Mon, 1 Oct 2012 21:18:01 +0200 Message-Id: <1349119081-9081-1-git-send-email-olaf@aepfle.de> X-Mailer: git-send-email 1.7.12 Cc: Olaf Hering , xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org Subject: [Xen-devel] [PATCH] xen pv-on-hvm: add pfn_is_ram helper for kdump X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Register pfn_is_ram helper speed up reading /proc/vmcore in the kdump kernel. See commit message of 997c136f518c ("fs/proc/vmcore.c: add hook to read_from_oldmem() to check for non-ram pages") for details. It makes use of a new hvmop HVMOP_get_mem_type which was introduced in xen 4.2 (23298:26413986e6e0) and backported to 4.1.1. The new function is currently only enabled for reading /proc/vmcore. Later it will be used also for the kexec kernel. Since that requires more changes in the generic kernel make it static for the time being. Signed-off-by: Olaf Hering --- v2: - remove typedefs arch/x86/xen/mmu.c | 41 ++++++++++++++++++++++++++++++++++++++ include/xen/interface/hvm/hvm_op.h | 19 ++++++++++++++++++ 2 files changed, 60 insertions(+) diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c index 5141d80..973962a 100644 --- a/arch/x86/xen/mmu.c +++ b/arch/x86/xen/mmu.c @@ -47,6 +47,7 @@ #include #include #include +#include #include @@ -2272,6 +2273,43 @@ void xen_destroy_contiguous_region(unsigned long vstart, unsigned int order) EXPORT_SYMBOL_GPL(xen_destroy_contiguous_region); #ifdef CONFIG_XEN_PVHVM +#ifdef CONFIG_PROC_VMCORE +/* + * This function is used in two contexts: + * - the kdump kernel has to check whether a pfn of the crashed kernel + * was a ballooned page. vmcore is using this function to decide + * whether to access a pfn of the crashed kernel. + * - the kexec kernel has to check whether a pfn was ballooned by the + * previous kernel. If the pfn is ballooned, handle it properly. + * Returns 0 if the pfn is not backed by a RAM page, the caller may + * handle the pfn special in this case. + */ +static int xen_oldmem_pfn_is_ram(unsigned long pfn) +{ + struct xen_hvm_get_mem_type a = { + .domid = DOMID_SELF, + .pfn = pfn, + }; + int ram; + + if (HYPERVISOR_hvm_op(HVMOP_get_mem_type, &a)) + return -ENXIO; + + switch (a.mem_type) { + case HVMMEM_mmio_dm: + ram = 0; + break; + case HVMMEM_ram_rw: + case HVMMEM_ram_ro: + default: + ram = 1; + break; + } + + return ram; +} +#endif + static void xen_hvm_exit_mmap(struct mm_struct *mm) { struct xen_hvm_pagetable_dying a; @@ -2302,6 +2340,9 @@ void __init xen_hvm_init_mmu_ops(void) { if (is_pagetable_dying_supported()) pv_mmu_ops.exit_mmap = xen_hvm_exit_mmap; +#ifdef CONFIG_PROC_VMCORE + register_oldmem_pfn_is_ram(&xen_oldmem_pfn_is_ram); +#endif } #endif diff --git a/include/xen/interface/hvm/hvm_op.h b/include/xen/interface/hvm/hvm_op.h index a4827f4..956a046 100644 --- a/include/xen/interface/hvm/hvm_op.h +++ b/include/xen/interface/hvm/hvm_op.h @@ -43,4 +43,23 @@ struct xen_hvm_pagetable_dying { typedef struct xen_hvm_pagetable_dying xen_hvm_pagetable_dying_t; DEFINE_GUEST_HANDLE_STRUCT(xen_hvm_pagetable_dying_t); +enum hvmmem_type_t { + HVMMEM_ram_rw, /* Normal read/write guest RAM */ + HVMMEM_ram_ro, /* Read-only; writes are discarded */ + HVMMEM_mmio_dm, /* Reads and write go to the device model */ +}; + +#define HVMOP_get_mem_type 15 +/* Return hvmmem_type_t for the specified pfn. */ +struct xen_hvm_get_mem_type { + /* Domain to be queried. */ + domid_t domid; + /* OUT variable. */ + uint16_t mem_type; + uint16_t pad[2]; /* align next field on 8-byte boundary */ + /* IN variable. */ + uint64_t pfn; +}; +DEFINE_GUEST_HANDLE_STRUCT(xen_hvm_get_mem_type); + #endif /* __XEN_PUBLIC_HVM_HVM_OP_H__ */ -- 1.7.12 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 19:19:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 19:19:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIlVj-0004Mb-9t; Mon, 01 Oct 2012 19:18:35 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIlVh-0004MU-6L for xen-devel@lists.xensource.com; Mon, 01 Oct 2012 19:18:33 +0000 Received: from [85.158.143.35:14933] by server-2.bemta-4.messagelabs.com id A3/8A-06610-88CE9605; Mon, 01 Oct 2012 19:18:32 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-12.tower-21.messagelabs.com!1349119111!12625875!1 X-Originating-IP: [81.169.146.162] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MTU1NzM=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MTU1NzM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24275 invoked from network); 1 Oct 2012 19:18:32 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162) by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 19:18:32 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGiy0IFwQ= X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-085-064.pools.arcor-ip.net [88.65.85.64]) by smtp.strato.de (jored mo21) (RZmta 30.20 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 60129bo91I7K7f ; Mon, 1 Oct 2012 21:18:25 +0200 (CEST) Received: by probook.site (Postfix, from userid 1000) id 46CBE1863E; Mon, 1 Oct 2012 21:18:24 +0200 (CEST) From: Olaf Hering To: Jeremy Fitzhardinge , Konrad Rzeszutek Wilk Date: Mon, 1 Oct 2012 21:18:01 +0200 Message-Id: <1349119081-9081-1-git-send-email-olaf@aepfle.de> X-Mailer: git-send-email 1.7.12 Cc: Olaf Hering , xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org Subject: [Xen-devel] [PATCH] xen pv-on-hvm: add pfn_is_ram helper for kdump X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Register pfn_is_ram helper speed up reading /proc/vmcore in the kdump kernel. See commit message of 997c136f518c ("fs/proc/vmcore.c: add hook to read_from_oldmem() to check for non-ram pages") for details. It makes use of a new hvmop HVMOP_get_mem_type which was introduced in xen 4.2 (23298:26413986e6e0) and backported to 4.1.1. The new function is currently only enabled for reading /proc/vmcore. Later it will be used also for the kexec kernel. Since that requires more changes in the generic kernel make it static for the time being. Signed-off-by: Olaf Hering --- v2: - remove typedefs arch/x86/xen/mmu.c | 41 ++++++++++++++++++++++++++++++++++++++ include/xen/interface/hvm/hvm_op.h | 19 ++++++++++++++++++ 2 files changed, 60 insertions(+) diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c index 5141d80..973962a 100644 --- a/arch/x86/xen/mmu.c +++ b/arch/x86/xen/mmu.c @@ -47,6 +47,7 @@ #include #include #include +#include #include @@ -2272,6 +2273,43 @@ void xen_destroy_contiguous_region(unsigned long vstart, unsigned int order) EXPORT_SYMBOL_GPL(xen_destroy_contiguous_region); #ifdef CONFIG_XEN_PVHVM +#ifdef CONFIG_PROC_VMCORE +/* + * This function is used in two contexts: + * - the kdump kernel has to check whether a pfn of the crashed kernel + * was a ballooned page. vmcore is using this function to decide + * whether to access a pfn of the crashed kernel. + * - the kexec kernel has to check whether a pfn was ballooned by the + * previous kernel. If the pfn is ballooned, handle it properly. + * Returns 0 if the pfn is not backed by a RAM page, the caller may + * handle the pfn special in this case. + */ +static int xen_oldmem_pfn_is_ram(unsigned long pfn) +{ + struct xen_hvm_get_mem_type a = { + .domid = DOMID_SELF, + .pfn = pfn, + }; + int ram; + + if (HYPERVISOR_hvm_op(HVMOP_get_mem_type, &a)) + return -ENXIO; + + switch (a.mem_type) { + case HVMMEM_mmio_dm: + ram = 0; + break; + case HVMMEM_ram_rw: + case HVMMEM_ram_ro: + default: + ram = 1; + break; + } + + return ram; +} +#endif + static void xen_hvm_exit_mmap(struct mm_struct *mm) { struct xen_hvm_pagetable_dying a; @@ -2302,6 +2340,9 @@ void __init xen_hvm_init_mmu_ops(void) { if (is_pagetable_dying_supported()) pv_mmu_ops.exit_mmap = xen_hvm_exit_mmap; +#ifdef CONFIG_PROC_VMCORE + register_oldmem_pfn_is_ram(&xen_oldmem_pfn_is_ram); +#endif } #endif diff --git a/include/xen/interface/hvm/hvm_op.h b/include/xen/interface/hvm/hvm_op.h index a4827f4..956a046 100644 --- a/include/xen/interface/hvm/hvm_op.h +++ b/include/xen/interface/hvm/hvm_op.h @@ -43,4 +43,23 @@ struct xen_hvm_pagetable_dying { typedef struct xen_hvm_pagetable_dying xen_hvm_pagetable_dying_t; DEFINE_GUEST_HANDLE_STRUCT(xen_hvm_pagetable_dying_t); +enum hvmmem_type_t { + HVMMEM_ram_rw, /* Normal read/write guest RAM */ + HVMMEM_ram_ro, /* Read-only; writes are discarded */ + HVMMEM_mmio_dm, /* Reads and write go to the device model */ +}; + +#define HVMOP_get_mem_type 15 +/* Return hvmmem_type_t for the specified pfn. */ +struct xen_hvm_get_mem_type { + /* Domain to be queried. */ + domid_t domid; + /* OUT variable. */ + uint16_t mem_type; + uint16_t pad[2]; /* align next field on 8-byte boundary */ + /* IN variable. */ + uint64_t pfn; +}; +DEFINE_GUEST_HANDLE_STRUCT(xen_hvm_get_mem_type); + #endif /* __XEN_PUBLIC_HVM_HVM_OP_H__ */ -- 1.7.12 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 19:24:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 19:24:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIlbH-0004Zw-AM; Mon, 01 Oct 2012 19:24:19 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIlbG-0004Zq-J2 for xen-devel@lists.xen.org; Mon, 01 Oct 2012 19:24:18 +0000 Received: from [85.158.143.35:12092] by server-1.bemta-4.messagelabs.com id A4/8C-05684-1EDE9605; Mon, 01 Oct 2012 19:24:17 +0000 X-Env-Sender: ikozhukhov@gmail.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1349119456!11955334!1 X-Originating-IP: [209.85.215.45] X-SpamReason: No, hits=0.7 required=7.0 tests=HTML_60_70,HTML_MESSAGE, MIME_QP_LONG_LINE,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28157 invoked from network); 1 Oct 2012 19:24:17 -0000 Received: from mail-la0-f45.google.com (HELO mail-la0-f45.google.com) (209.85.215.45) by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 19:24:17 -0000 Received: by lahm13 with SMTP id m13so2522149lah.32 for ; Mon, 01 Oct 2012 12:24:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version:content-type; bh=sf97zsZkTQKeTyGuA66X0MSbnFG95tfrjMfo6G/koas=; b=YiDZNjlxKEKXHZJRywt1Rsnc4ZgnTSO4payA2Ej7QgWju3ViVxBgWur23N8PkIJfWW 997ppSTkBneY3XUPZ7E4Bh6uzwZs+buo1Zg6gL/tq5AWK2Rd+tuvzeC+cQE4PuY/s1DR nrhlIvj0x7KY7H4vmZGBM50NSBjvwn0XnO+MnWD2wE/MqecVQZn8dF+58Cs78F9YE34g NrlqDbgy2PRJ+R32sqe2iWG0milQIy8Y0I2CZLApvpfirpTlgVpsYrSUWGRs+p6aFnL/ iYNdL53Le18n2l7xrYHCS3UOPUF4NfO2zDlnPCvBil7iD5vw3yd6+DnzGNKH7yfylJCS /gCg== Received: by 10.152.144.168 with SMTP id sn8mr12534730lab.1.1349119456472; Mon, 01 Oct 2012 12:24:16 -0700 (PDT) Received: from [172.16.90.16] ([91.204.58.44]) by mx.google.com with ESMTPS id sx3sm1244331lab.9.2012.10.01.12.24.11 (version=SSLv3 cipher=OTHER); Mon, 01 Oct 2012 12:24:15 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Mon, 01 Oct 2012 23:24:06 +0400 From: Igor Kozhukhov To: Message-ID: Thread-Topic: xen-4.3 (unstable) panic Mime-version: 1.0 Subject: [Xen-devel] xen-4.3 (unstable) panic X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3636991297924135375==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============3636991297924135375== Content-type: multipart/alternative; boundary="B_3431978652_47350930" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3431978652_47350930 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hello All, I try port xen-unstable to illumos-based platform. I have made some changes on illumos and built xen, but have panic - take a look http://pastebin.com/fZSrExek I'd like to see some comments - what I need to check/update. --- Best regards, Igor Kozhukhov IRC# igork --B_3431978652_47350930 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Hello All,

I try port xen-unstable to illumos-based platform.

I have made some changes on illumos and built xen, but hav= e panic - take a look http://pas= tebin.com/fZSrExek

I'd like to see some comment= s - what I need to check/update.

---
Best regards,
Igor Kozhukhov
IRC# igork
--B_3431978652_47350930-- --===============3636991297924135375== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============3636991297924135375==-- From xen-devel-bounces@lists.xen.org Mon Oct 01 19:24:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 19:24:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIlbH-0004Zw-AM; Mon, 01 Oct 2012 19:24:19 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIlbG-0004Zq-J2 for xen-devel@lists.xen.org; Mon, 01 Oct 2012 19:24:18 +0000 Received: from [85.158.143.35:12092] by server-1.bemta-4.messagelabs.com id A4/8C-05684-1EDE9605; Mon, 01 Oct 2012 19:24:17 +0000 X-Env-Sender: ikozhukhov@gmail.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1349119456!11955334!1 X-Originating-IP: [209.85.215.45] X-SpamReason: No, hits=0.7 required=7.0 tests=HTML_60_70,HTML_MESSAGE, MIME_QP_LONG_LINE,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28157 invoked from network); 1 Oct 2012 19:24:17 -0000 Received: from mail-la0-f45.google.com (HELO mail-la0-f45.google.com) (209.85.215.45) by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 19:24:17 -0000 Received: by lahm13 with SMTP id m13so2522149lah.32 for ; Mon, 01 Oct 2012 12:24:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version:content-type; bh=sf97zsZkTQKeTyGuA66X0MSbnFG95tfrjMfo6G/koas=; b=YiDZNjlxKEKXHZJRywt1Rsnc4ZgnTSO4payA2Ej7QgWju3ViVxBgWur23N8PkIJfWW 997ppSTkBneY3XUPZ7E4Bh6uzwZs+buo1Zg6gL/tq5AWK2Rd+tuvzeC+cQE4PuY/s1DR nrhlIvj0x7KY7H4vmZGBM50NSBjvwn0XnO+MnWD2wE/MqecVQZn8dF+58Cs78F9YE34g NrlqDbgy2PRJ+R32sqe2iWG0milQIy8Y0I2CZLApvpfirpTlgVpsYrSUWGRs+p6aFnL/ iYNdL53Le18n2l7xrYHCS3UOPUF4NfO2zDlnPCvBil7iD5vw3yd6+DnzGNKH7yfylJCS /gCg== Received: by 10.152.144.168 with SMTP id sn8mr12534730lab.1.1349119456472; Mon, 01 Oct 2012 12:24:16 -0700 (PDT) Received: from [172.16.90.16] ([91.204.58.44]) by mx.google.com with ESMTPS id sx3sm1244331lab.9.2012.10.01.12.24.11 (version=SSLv3 cipher=OTHER); Mon, 01 Oct 2012 12:24:15 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Mon, 01 Oct 2012 23:24:06 +0400 From: Igor Kozhukhov To: Message-ID: Thread-Topic: xen-4.3 (unstable) panic Mime-version: 1.0 Subject: [Xen-devel] xen-4.3 (unstable) panic X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3636991297924135375==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============3636991297924135375== Content-type: multipart/alternative; boundary="B_3431978652_47350930" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3431978652_47350930 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hello All, I try port xen-unstable to illumos-based platform. I have made some changes on illumos and built xen, but have panic - take a look http://pastebin.com/fZSrExek I'd like to see some comments - what I need to check/update. --- Best regards, Igor Kozhukhov IRC# igork --B_3431978652_47350930 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Hello All,

I try port xen-unstable to illumos-based platform.

I have made some changes on illumos and built xen, but hav= e panic - take a look http://pas= tebin.com/fZSrExek

I'd like to see some comment= s - what I need to check/update.

---
Best regards,
Igor Kozhukhov
IRC# igork
--B_3431978652_47350930-- --===============3636991297924135375== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============3636991297924135375==-- From xen-devel-bounces@lists.xen.org Mon Oct 01 19:55:39 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 19:55:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIm5F-0005IO-26; Mon, 01 Oct 2012 19:55:17 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIm5D-0005IF-8T for xen-devel@lists.xen.org; Mon, 01 Oct 2012 19:55:15 +0000 Received: from [85.158.138.51:19379] by server-12.bemta-3.messagelabs.com id FD/F0-23730-225F9605; Mon, 01 Oct 2012 19:55:14 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-2.tower-174.messagelabs.com!1349121310!32631670!1 X-Originating-IP: [128.244.251.36] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG, UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4634 invoked from network); 1 Oct 2012 19:55:12 -0000 Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36) by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 19:55:12 -0000 Received: from ([128.244.207.89]) by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.154059678; Mon, 01 Oct 2012 15:55:00 -0400 From: Matthew Fioravante To: George.Dunlap@eu.citrix.com, Ian.Campbell@citrix.com, xen-devel@lists.xen.org Date: Mon, 1 Oct 2012 15:53:30 -0400 Message-Id: <1349121210-3310-1-git-send-email-matthew.fioravante@jhuapl.edu> X-Mailer: git-send-email 1.7.9.5 Cc: Matthew Fioravante Subject: [Xen-devel] [PATCH 11/11] add vtpm support to libxl X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch adds vtpm support to libxl. It adds vtpm parsing to config files and 3 new xl commands: vtpm-attach vtpm-detach vtpm-list Signed-off-by: Matthew Fioravante --- Changed since previous * Minor parsing fixes * backend parameter is now mandatory (docs updated) * fixed some comments diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5 index 428da21..9f6ee5a 100644 --- a/docs/man/xl.cfg.pod.5 +++ b/docs/man/xl.cfg.pod.5 @@ -298,6 +298,35 @@ Specifies the networking provision (both emulated network adapters, and Xen virtual interfaces) to provided to the guest. See F. +=item B + +Specifies the virtual trusted platform module to be +provided to the guest. Please see F +for more details. + +Each B is a comma-separated list of C +settings, from the following list: + +=over 4 + +=item C + +Specify the backend domain name of id. This value is required! +If this domain is a guest, the backend should be set to the +vtpm domain name. If this domain is a vtpm, the +backend should be set to the vtpm manager domain name. + +=item C + +Specify the uuid of this vtpm device. The uuid is used to uniquely +identify the vtpm device. You can create one using the uuidgen +program on unix systems. If left unspecified, a new uuid +will be randomly generated every time the domain boots. +If this is a vtpm domain, you should specify a value. The +value is optional if this is a guest domain. + +=back + =item B Specifies the paravirtual framebuffer devices which should be supplied diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1 index 25ce777..be9ad4c 100644 --- a/docs/man/xl.pod.1 +++ b/docs/man/xl.pod.1 @@ -1101,6 +1101,31 @@ List virtual network interfaces for a domain. =back +=head2 VTPM DEVICES + +=over 4 + +=item B I I + +Creates a new vtpm device in the domain specified by I. +I describes the device to attach, using the same format as the +B string in the domain config file. See L for +more information. + +=item B I I + +Removes the vtpm device from the domain specified by I. +I is the numeric device id given to the virtual trusted +platform module device. You will need to run B to determine that number. +Alternatively the I of the vtpm can be used to +select the virtual device to detach. + +=item B I + +List virtual trusted platform modules for a domain. + +=back + =head1 PCI PASS-THROUGH =over 4 diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c index 1606eb1..17094ca 100644 --- a/tools/libxl/libxl.c +++ b/tools/libxl/libxl.c @@ -1726,6 +1726,246 @@ out: } /******************************************************************************/ +int libxl__device_vtpm_setdefault(libxl__gc *gc, libxl_device_vtpm *vtpm) +{ + if(libxl_uuid_is_nil(&vtpm->uuid)) { + libxl_uuid_generate(&vtpm->uuid); + } + return 0; +} + +static int libxl__device_from_vtpm(libxl__gc *gc, uint32_t domid, + libxl_device_vtpm *vtpm, + libxl__device *device) +{ + device->backend_devid = vtpm->devid; + device->backend_domid = vtpm->backend_domid; + device->backend_kind = LIBXL__DEVICE_KIND_VTPM; + device->devid = vtpm->devid; + device->domid = domid; + device->kind = LIBXL__DEVICE_KIND_VTPM; + + return 0; +} + +void libxl__device_vtpm_add(libxl__egc *egc, uint32_t domid, + libxl_device_vtpm *vtpm, + libxl__ao_device *aodev) +{ + STATE_AO_GC(aodev->ao); + flexarray_t *front; + flexarray_t *back; + libxl__device *device; + char *dompath, **l; + unsigned int nb, rc; + + rc = libxl__device_vtpm_setdefault(gc, vtpm); + if (rc) goto out; + + front = flexarray_make(16, 1); + if (!front) { + rc = ERROR_NOMEM; + goto out; + } + back = flexarray_make(16, 1); + if (!back) { + rc = ERROR_NOMEM; + goto out; + } + + if(vtpm->devid == -1) { + if (!(dompath = libxl__xs_get_dompath(gc, domid))) { + rc = ERROR_FAIL; + goto out_free; + } + l = libxl__xs_directory(gc, XBT_NULL, libxl__sprintf(gc, "%s/device/vtpm", dompath), &nb); + if(l == NULL || nb == 0) { + vtpm->devid = 0; + } else { + vtpm->devid = strtoul(l[nb - 1], NULL, 10) + 1; + } + } + + GCNEW(device); + rc = libxl__device_from_vtpm(gc, domid, vtpm, device); + if ( rc != 0 ) goto out_free; + + flexarray_append(back, "frontend-id"); + flexarray_append(back, libxl__sprintf(gc, "%d", domid)); + flexarray_append(back, "online"); + flexarray_append(back, "1"); + flexarray_append(back, "state"); + flexarray_append(back, libxl__sprintf(gc, "%d", 1)); + + flexarray_append(back, "uuid"); + flexarray_append(back, libxl__sprintf(gc, LIBXL_UUID_FMT, LIBXL_UUID_BYTES(vtpm->uuid))); + flexarray_append(back, "instance"); /* MAYBE CAN GET RID OF THIS */ + flexarray_append(back, "0"); + flexarray_append(back, "pref_instance"); /* MAYBE CAN GET RID OF THIS */ + flexarray_append(back, "0"); + flexarray_append(back, "resume"); + flexarray_append(back, "False"); + flexarray_append(back, "ready"); /* MAYBE CAN GET RID OF THIS */ + flexarray_append(back, "1"); + + flexarray_append(front, "backend-id"); + flexarray_append(front, libxl__sprintf(gc, "%d", vtpm->backend_domid)); + flexarray_append(front, "state"); + flexarray_append(front, libxl__sprintf(gc, "%d", 1)); + flexarray_append(front, "handle"); + flexarray_append(front, libxl__sprintf(gc, "%d", vtpm->devid)); + + libxl__device_generic_add(gc, XBT_NULL, device, + libxl__xs_kvs_of_flexarray(gc, back, back->count), + libxl__xs_kvs_of_flexarray(gc, front, front->count)); + + aodev->dev = device; + aodev->action = DEVICE_CONNECT; + libxl__wait_device_connection(egc, aodev); + + rc = 0; +out_free: + flexarray_free(back); + flexarray_free(front); +out: + aodev->rc = rc; + if(rc) aodev->callback(egc, aodev); + return; +} + +static void libxl__device_vtpm_from_xs_fe(libxl__gc *gc, + const char* fe_path, + libxl_device_vtpm *vtpm) +{ + char* tmp; + + memset(vtpm, 0, sizeof(*vtpm)); + tmp = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/handle", fe_path)); + if (tmp) { + vtpm->devid = atoi(tmp); + } + tmp = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/backend-id", fe_path)); + if(tmp) { + vtpm->backend_domid = atoi(tmp); + } + tmp = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/uuid", fe_path)); + if(tmp) { + libxl_uuid_from_string(&(vtpm->uuid), tmp); + } +} + +libxl_device_vtpm *libxl_device_vtpm_list(libxl_ctx *ctx, uint32_t domid, int *num) +{ + GC_INIT(ctx); + + libxl_device_vtpm* vtpms = NULL; + char* fe_path = NULL; + char** dir = NULL; + unsigned int ndirs = 0; + + *num = 0; + + fe_path = libxl__sprintf(gc, "%s/device/vtpm", libxl__xs_get_dompath(gc, domid)); + dir = libxl__xs_directory(gc, XBT_NULL, fe_path, &ndirs); + if(dir) { + vtpms = malloc(sizeof(*vtpms) * ndirs); + libxl_device_vtpm* vtpm; + libxl_device_vtpm* end = vtpms + ndirs; + for(vtpm = vtpms; vtpm < end; ++vtpm, ++dir) { + const char* path = libxl__sprintf(gc, "%s/%s", fe_path, *dir); + libxl__device_vtpm_from_xs_fe(gc, path, vtpm); + } + } + *num = ndirs; + + GC_FREE; + return vtpms; +} + +int libxl_device_vtpm_getinfo(libxl_ctx *ctx, uint32_t domid, + libxl_device_vtpm *vtpm, libxl_vtpminfo *vtpminfo) +{ + GC_INIT(ctx); + char *dompath, *vtpmpath; + char *val; + int rc = 0; + + libxl_vtpminfo_init(vtpminfo); + dompath = libxl__xs_get_dompath(gc, domid); + vtpminfo->devid = vtpm->devid; + + vtpmpath = libxl__sprintf(gc, "%s/device/vtpm/%d", dompath, vtpminfo->devid); + vtpminfo->backend = xs_read(ctx->xsh, XBT_NULL, + libxl__sprintf(gc, "%s/backend", vtpmpath), NULL); + if (!vtpminfo->backend) { + goto err; + } + if(!libxl__xs_read(gc, XBT_NULL, vtpminfo->backend)) { + goto err; + } + + val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/backend-id", vtpmpath)); + vtpminfo->backend_id = val ? strtoul(val, NULL, 10) : -1; + val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/state", vtpmpath)); + vtpminfo->state = val ? strtoul(val, NULL, 10) : -1; + val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/event-channel", vtpmpath)); + vtpminfo->evtch = val ? strtoul(val, NULL, 10) : -1; + val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/ring-ref", vtpmpath)); + vtpminfo->rref = val ? strtoul(val, NULL, 10) : -1; + vtpminfo->frontend = xs_read(ctx->xsh, XBT_NULL, + libxl__sprintf(gc, "%s/frontend", vtpminfo->backend), NULL); + val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/frontend-id", vtpminfo->backend)); + vtpminfo->frontend_id = val ? strtoul(val, NULL, 10) : -1; + + val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/uuid", vtpminfo->backend)); + if(val == NULL) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s/uuid does not exist!\n", vtpminfo->backend); + goto err; + } + if(libxl_uuid_from_string(&(vtpminfo->uuid), val)) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s/uuid is a malformed uuid?? (%s) Probably a bug!\n", vtpminfo->backend, val); + goto err; + } + + goto exit; +err: + rc = ERROR_FAIL; +exit: + GC_FREE; + return rc; +} + +int libxl_devid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid, + int devid, libxl_device_vtpm *vtpm) +{ + libxl_device_vtpm *vtpms; + int nb, i; + int rc; + + vtpms = libxl_device_vtpm_list(ctx, domid, &nb); + if (!vtpms) + return ERROR_FAIL; + + memset(vtpm, 0, sizeof (libxl_device_vtpm)); + rc = 1; + for (i = 0; i < nb; ++i) { + if(devid == vtpms[i].devid) { + vtpm->backend_domid = vtpms[i].backend_domid; + vtpm->devid = vtpms[i].devid; + libxl_uuid_copy(&vtpm->uuid, &vtpms[i].uuid); + rc = 0; + break; + } + } + + for (i=0; ivkbs[i]); free(d_config->vkbs); + for (i=0; inum_vtpms; i++) + libxl_device_vtpm_dispose(&d_config->vtpms[i]); + free(d_config->vtpms); + libxl_domain_create_info_dispose(&d_config->c_info); libxl_domain_build_info_dispose(&d_config->b_info); } @@ -601,6 +605,8 @@ static void domcreate_bootloader_done(libxl__egc *egc, static void domcreate_launch_dm(libxl__egc *egc, libxl__multidev *aodevs, int ret); +static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multidev *multidev, + int ret); static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev *aodevs, int ret); @@ -1084,13 +1090,13 @@ static void domcreate_devmodel_started(libxl__egc *egc, if (d_config->num_nics > 0) { /* Attach nics */ libxl__multidev_begin(ao, &dcs->multidev); - dcs->multidev.callback = domcreate_attach_pci; + dcs->multidev.callback = domcreate_attach_vtpms; libxl__add_nics(egc, ao, domid, d_config, &dcs->multidev); libxl__multidev_prepared(egc, &dcs->multidev, 0); return; } - domcreate_attach_pci(egc, &dcs->multidev, 0); + domcreate_attach_vtpms(egc, &dcs->multidev, 0); return; error_out: @@ -1098,6 +1104,36 @@ error_out: domcreate_complete(egc, dcs, ret); } +static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multidev *multidev, int ret) { + libxl__domain_create_state *dcs = CONTAINER_OF(multidev, *dcs, multidev); + STATE_AO_GC(dcs->ao); + int domid = dcs->guest_domid; + + libxl_domain_config* const d_config = dcs->guest_config; + + if(ret) { + LOG(ERROR, "unable to add nic devices"); + goto error_out; + } + + /* Plug vtpm devices */ + if (d_config->num_vtpms > 0) { + /* Attach vtpms */ + libxl__multidev_begin(ao, &dcs->multidev); + dcs->multidev.callback = domcreate_attach_pci; + libxl__add_vtpms(egc, ao, domid, d_config, &dcs->multidev); + libxl__multidev_prepared(egc, &dcs->multidev, 0); + return; + } + + domcreate_attach_pci(egc, multidev, 0); + return; + +error_out: + assert(ret); + domcreate_complete(egc, dcs, ret); +} + static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev *multidev, int ret) { @@ -1111,7 +1147,7 @@ static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev *multidev, libxl_domain_config *const d_config = dcs->guest_config; if (ret) { - LOG(ERROR, "unable to add nic devices"); + LOG(ERROR, "unable to add vtpm devices"); goto error_out; } diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c index c3283f1..51dd06e 100644 --- a/tools/libxl/libxl_device.c +++ b/tools/libxl/libxl_device.c @@ -497,6 +497,7 @@ void libxl__multidev_prepared(libxl__egc *egc, * The following functions are defined: * libxl__add_disks * libxl__add_nics + * libxl__add_vtpms */ #define DEFINE_DEVICES_ADD(type) \ @@ -515,6 +516,7 @@ void libxl__multidev_prepared(libxl__egc *egc, DEFINE_DEVICES_ADD(disk) DEFINE_DEVICES_ADD(nic) +DEFINE_DEVICES_ADD(vtpm) #undef DEFINE_DEVICES_ADD diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index b6f54ba..e9a7cbb 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -954,6 +954,7 @@ _hidden int libxl__device_disk_setdefault(libxl__gc *gc, libxl_device_disk *disk); _hidden int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic, uint32_t domid); +_hidden int libxl__device_vtpm_setdefault(libxl__gc *gc, libxl_device_vtpm *vtpm); _hidden int libxl__device_vfb_setdefault(libxl__gc *gc, libxl_device_vfb *vfb); _hidden int libxl__device_vkb_setdefault(libxl__gc *gc, libxl_device_vkb *vkb); _hidden int libxl__device_pci_setdefault(libxl__gc *gc, libxl_device_pci *pci); @@ -1975,6 +1976,10 @@ _hidden void libxl__device_nic_add(libxl__egc *egc, uint32_t domid, libxl_device_nic *nic, libxl__ao_device *aodev); +_hidden void libxl__device_vtpm_add(libxl__egc *egc, uint32_t domid, + libxl_device_vtpm *vtpm, + 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); @@ -2407,6 +2412,10 @@ _hidden void libxl__add_nics(libxl__egc *egc, libxl__ao *ao, uint32_t domid, libxl_domain_config *d_config, libxl__multidev *multidev); +_hidden void libxl__add_vtpms(libxl__egc *egc, libxl__ao *ao, uint32_t domid, + libxl_domain_config *d_config, + libxl__multidev *multidev); + /*----- device model creation -----*/ /* First layer; wraps libxl__spawn_spawn. */ diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl index de111a6..7eac4a8 100644 --- a/tools/libxl/libxl_types.idl +++ b/tools/libxl/libxl_types.idl @@ -395,6 +395,12 @@ libxl_device_pci = Struct("device_pci", [ ("permissive", bool), ]) +libxl_device_vtpm = Struct("device_vtpm", [ + ("backend_domid", libxl_domid), + ("devid", libxl_devid), + ("uuid", libxl_uuid), +]) + libxl_diskinfo = Struct("diskinfo", [ ("backend", string), ("backend_id", uint32), @@ -418,6 +424,18 @@ libxl_nicinfo = Struct("nicinfo", [ ("rref_rx", integer), ], dir=DIR_OUT) +libxl_vtpminfo = Struct("vtpminfo", [ + ("backend", string), + ("backend_id", uint32), + ("frontend", string), + ("frontend_id", uint32), + ("devid", libxl_devid), + ("state", integer), + ("evtch", integer), + ("rref", integer), + ("uuid", libxl_uuid), + ], dir=DIR_OUT) + libxl_vcpuinfo = Struct("vcpuinfo", [ ("vcpuid", uint32), ("cpu", uint32), diff --git a/tools/libxl/libxl_types_internal.idl b/tools/libxl/libxl_types_internal.idl index 5ac8c9c..c40120e 100644 --- a/tools/libxl/libxl_types_internal.idl +++ b/tools/libxl/libxl_types_internal.idl @@ -19,6 +19,7 @@ libxl__device_kind = Enumeration("device_kind", [ (5, "VFB"), (6, "VKBD"), (7, "CONSOLE"), + (8, "VTPM"), ]) libxl__console_backend = Enumeration("console_backend", [ diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c index 55cd299..73a158a 100644 --- a/tools/libxl/libxl_utils.c +++ b/tools/libxl/libxl_utils.c @@ -463,6 +463,35 @@ int libxl_pipe(libxl_ctx *ctx, int pipes[2]) return 0; } +int libxl_uuid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid, + libxl_uuid* uuid, libxl_device_vtpm *vtpm) +{ + libxl_device_vtpm *vtpms; + int nb, i; + int rc; + + vtpms = libxl_device_vtpm_list(ctx, domid, &nb); + if (!vtpms) + return ERROR_FAIL; + + memset(vtpm, 0, sizeof (libxl_device_vtpm)); + rc = 1; + for (i = 0; i < nb; ++i) { + if(!libxl_uuid_compare(uuid, &vtpms[i].uuid)) { + vtpm->backend_domid = vtpms[i].backend_domid; + vtpm->devid = vtpms[i].devid; + libxl_uuid_copy(&vtpm->uuid, &vtpms[i].uuid); + rc = 0; + break; + } + } + + for (i=0; inum_vtpms = 0; + d_config->vtpms = NULL; + while ((buf = xlu_cfg_get_listitem (vtpms, d_config->num_vtpms)) != NULL) { + libxl_device_vtpm *vtpm; + char * buf2 = strdup(buf); + char *p, *p2; + bool got_backend = false; + + d_config->vtpms = (libxl_device_vtpm *) realloc(d_config->vtpms, sizeof(libxl_device_vtpm) * (d_config->num_vtpms+1)); + vtpm = d_config->vtpms + d_config->num_vtpms; + libxl_device_vtpm_init(vtpm); + vtpm->devid = d_config->num_vtpms; + + p = strtok(buf2, ","); + if(p) { + do { + while(*p == ' ') + ++p; + if ((p2 = strchr(p, '=')) == NULL) + break; + *p2 = '\0'; + if (!strcmp(p, "backend")) { + if(domain_qualifier_to_domid(p2 + 1, &(vtpm->backend_domid), 0)) + { + fprintf(stderr, "Specified vtpm backend domain `%s' does not exist!\n", p2 + 1); + exit(1); + } + got_backend = true; + } else if(!strcmp(p, "uuid")) { + if( libxl_uuid_from_string(&vtpm->uuid, p2 + 1) ) { + fprintf(stderr, "Failed to parse vtpm UUID: %s\n", p2 + 1); + exit(1); + } + } else { + fprintf(stderr, "Unknown string `%s' in vtpm spec\n", p); + exit(1); + } + } while ((p = strtok(NULL, ",")) != NULL); + } + if(!got_backend) { + fprintf(stderr, "vtpm spec missing required backend field!\n"); + exit(1); + } + free(buf2); + d_config->num_vtpms++; + } + } + if (!xlu_cfg_get_list (config, "vif", &nics, 0, 0)) { d_config->num_nics = 0; d_config->nics = NULL; @@ -1070,7 +1119,7 @@ static void parse_config_data(const char *config_source, p = strtok(buf2, ","); if (!p) - goto skip; + goto skip_nic; do { while (*p == ' ') p++; @@ -1134,7 +1183,7 @@ static void parse_config_data(const char *config_source, fprintf(stderr, "the accel parameter for vifs is currently not supported\n"); } } while ((p = strtok(NULL, ",")) != NULL); -skip: +skip_nic: free(buf2); d_config->num_nics++; } @@ -5570,6 +5619,131 @@ int main_blockdetach(int argc, char **argv) return rc; } +int main_vtpmattach(int argc, char **argv) +{ + int opt; + libxl_device_vtpm vtpm; + char *oparg; + unsigned int val; + uint32_t domid; + + if ((opt = def_getopt(argc, argv, "", "vtpm-attach", 1)) != -1) + return opt; + + if (domain_qualifier_to_domid(argv[optind], &domid, 0) < 0) { + fprintf(stderr, "%s is an invalid domain identifier\n", argv[optind]); + return 1; + } + ++optind; + + libxl_device_vtpm_init(&vtpm); + for (argv += optind, argc -= optind; argc > 0; ++argv, --argc) { + if (MATCH_OPTION("uuid", *argv, oparg)) { + if(libxl_uuid_from_string(&(vtpm.uuid), oparg)) { + fprintf(stderr, "Invalid uuid specified (%s)\n", oparg); + return 1; + } + } else if (MATCH_OPTION("backend", *argv, oparg)) { + if(domain_qualifier_to_domid(oparg, &val, 0)) { + fprintf(stderr, "Specified backend domain does not exist, defaulting to Dom0\n"); + val = 0; + } + vtpm.backend_domid = val; + } else { + fprintf(stderr, "unrecognized argument `%s'\n", *argv); + return 1; + } + } + + if(dryrun_only) { + char* json = libxl_device_vtpm_to_json(ctx, &vtpm); + printf("vtpm: %s\n", json); + free(json); + libxl_device_vtpm_dispose(&vtpm); + if (ferror(stdout) || fflush(stdout)) { perror("stdout"); exit(-1); } + return 0; + } + + if (libxl_device_vtpm_add(ctx, domid, &vtpm, 0)) { + fprintf(stderr, "libxl_device_vtpm_add failed.\n"); + return 1; + } + libxl_device_vtpm_dispose(&vtpm); + return 0; +} + +int main_vtpmlist(int argc, char **argv) +{ + int opt; + libxl_device_vtpm *vtpms; + libxl_vtpminfo vtpminfo; + int nb, i; + + if ((opt = def_getopt(argc, argv, "", "vtpm-list", 1)) != -1) + return opt; + + /* Idx BE UUID Hdl Sta evch rref BE-path */ + printf("%-3s %-2s %-36s %-6s %-5s %-6s %-5s %-10s\n", + "Idx", "BE", "Uuid", "handle", "state", "evt-ch", "ring-ref", "BE-path"); + for (argv += optind, argc -= optind; argc > 0; --argc, ++argv) { + uint32_t domid; + if (domain_qualifier_to_domid(*argv, &domid, 0) < 0) { + fprintf(stderr, "%s is an invalid domain identifier\n", *argv); + continue; + } + if (!(vtpms = libxl_device_vtpm_list(ctx, domid, &nb))) { + continue; + } + for (i = 0; i < nb; ++i) { + if(!libxl_device_vtpm_getinfo(ctx, domid, &vtpms[i], &vtpminfo)) { + /* Idx BE UUID Hdl Sta evch rref BE-path*/ + printf("%-3d %-2d " LIBXL_UUID_FMT " %6d %5d %6d %8d %-30s\n", + vtpminfo.devid, vtpminfo.backend_id, + LIBXL_UUID_BYTES(vtpminfo.uuid), + vtpminfo.devid, vtpminfo.state, vtpminfo.evtch, + vtpminfo.rref, vtpminfo.backend); + + libxl_vtpminfo_dispose(&vtpminfo); + } + libxl_device_vtpm_dispose(&vtpms[i]); + } + free(vtpms); + } + return 0; +} + +int main_vtpmdetach(int argc, char **argv) +{ + uint32_t domid; + int opt, rc=0; + libxl_device_vtpm vtpm; + libxl_uuid uuid; + + if ((opt = def_getopt(argc, argv, "", "vtpm-detach", 2)) != -1) + return opt; + + domid = find_domain(argv[optind]); + + if ( libxl_uuid_from_string(&uuid, argv[optind+1])) { + if (libxl_devid_to_device_vtpm(ctx, domid, atoi(argv[optind+1]), &vtpm)) { + fprintf(stderr, "Unknown device %s.\n", argv[optind+1]); + return 1; + } + } else { + if (libxl_uuid_to_device_vtpm(ctx, domid, &uuid, &vtpm)) { + fprintf(stderr, "Unknown device %s.\n", argv[optind+1]); + return 1; + } + } + rc = libxl_device_vtpm_remove(ctx, domid, &vtpm, 0); + if (rc) { + fprintf(stderr, "libxl_device_vtpm_remove failed.\n"); + } + libxl_device_vtpm_dispose(&vtpm); + return rc; +} + + static char *uptime_to_string(unsigned long uptime, int short_mode) { int sec, min, hour, day; diff --git a/tools/libxl/xl_cmdtable.c b/tools/libxl/xl_cmdtable.c index 85ea768..7c018eb 100644 --- a/tools/libxl/xl_cmdtable.c +++ b/tools/libxl/xl_cmdtable.c @@ -338,6 +338,21 @@ struct cmd_spec cmd_table[] = { "Destroy a domain's virtual block device", " ", }, + { "vtpm-attach", + &main_vtpmattach, 0, 1, + "Create a new virtual TPM device", + " [uuid=] [backend=]", + }, + { "vtpm-list", + &main_vtpmlist, 0, 0, + "List virtual TPM devices for a domain", + "", + }, + { "vtpm-detach", + &main_vtpmdetach, 0, 1, + "Destroy a domain's virtual TPM device", + " ", + }, { "uptime", &main_uptime, 0, 0, "Print uptime for all/some domains", -- 1.7.4.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 19:55:39 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 19:55:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIm5F-0005IO-26; Mon, 01 Oct 2012 19:55:17 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIm5D-0005IF-8T for xen-devel@lists.xen.org; Mon, 01 Oct 2012 19:55:15 +0000 Received: from [85.158.138.51:19379] by server-12.bemta-3.messagelabs.com id FD/F0-23730-225F9605; Mon, 01 Oct 2012 19:55:14 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-2.tower-174.messagelabs.com!1349121310!32631670!1 X-Originating-IP: [128.244.251.36] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG, UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4634 invoked from network); 1 Oct 2012 19:55:12 -0000 Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36) by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 19:55:12 -0000 Received: from ([128.244.207.89]) by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.154059678; Mon, 01 Oct 2012 15:55:00 -0400 From: Matthew Fioravante To: George.Dunlap@eu.citrix.com, Ian.Campbell@citrix.com, xen-devel@lists.xen.org Date: Mon, 1 Oct 2012 15:53:30 -0400 Message-Id: <1349121210-3310-1-git-send-email-matthew.fioravante@jhuapl.edu> X-Mailer: git-send-email 1.7.9.5 Cc: Matthew Fioravante Subject: [Xen-devel] [PATCH 11/11] add vtpm support to libxl X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch adds vtpm support to libxl. It adds vtpm parsing to config files and 3 new xl commands: vtpm-attach vtpm-detach vtpm-list Signed-off-by: Matthew Fioravante --- Changed since previous * Minor parsing fixes * backend parameter is now mandatory (docs updated) * fixed some comments diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5 index 428da21..9f6ee5a 100644 --- a/docs/man/xl.cfg.pod.5 +++ b/docs/man/xl.cfg.pod.5 @@ -298,6 +298,35 @@ Specifies the networking provision (both emulated network adapters, and Xen virtual interfaces) to provided to the guest. See F. +=item B + +Specifies the virtual trusted platform module to be +provided to the guest. Please see F +for more details. + +Each B is a comma-separated list of C +settings, from the following list: + +=over 4 + +=item C + +Specify the backend domain name of id. This value is required! +If this domain is a guest, the backend should be set to the +vtpm domain name. If this domain is a vtpm, the +backend should be set to the vtpm manager domain name. + +=item C + +Specify the uuid of this vtpm device. The uuid is used to uniquely +identify the vtpm device. You can create one using the uuidgen +program on unix systems. If left unspecified, a new uuid +will be randomly generated every time the domain boots. +If this is a vtpm domain, you should specify a value. The +value is optional if this is a guest domain. + +=back + =item B Specifies the paravirtual framebuffer devices which should be supplied diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1 index 25ce777..be9ad4c 100644 --- a/docs/man/xl.pod.1 +++ b/docs/man/xl.pod.1 @@ -1101,6 +1101,31 @@ List virtual network interfaces for a domain. =back +=head2 VTPM DEVICES + +=over 4 + +=item B I I + +Creates a new vtpm device in the domain specified by I. +I describes the device to attach, using the same format as the +B string in the domain config file. See L for +more information. + +=item B I I + +Removes the vtpm device from the domain specified by I. +I is the numeric device id given to the virtual trusted +platform module device. You will need to run B to determine that number. +Alternatively the I of the vtpm can be used to +select the virtual device to detach. + +=item B I + +List virtual trusted platform modules for a domain. + +=back + =head1 PCI PASS-THROUGH =over 4 diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c index 1606eb1..17094ca 100644 --- a/tools/libxl/libxl.c +++ b/tools/libxl/libxl.c @@ -1726,6 +1726,246 @@ out: } /******************************************************************************/ +int libxl__device_vtpm_setdefault(libxl__gc *gc, libxl_device_vtpm *vtpm) +{ + if(libxl_uuid_is_nil(&vtpm->uuid)) { + libxl_uuid_generate(&vtpm->uuid); + } + return 0; +} + +static int libxl__device_from_vtpm(libxl__gc *gc, uint32_t domid, + libxl_device_vtpm *vtpm, + libxl__device *device) +{ + device->backend_devid = vtpm->devid; + device->backend_domid = vtpm->backend_domid; + device->backend_kind = LIBXL__DEVICE_KIND_VTPM; + device->devid = vtpm->devid; + device->domid = domid; + device->kind = LIBXL__DEVICE_KIND_VTPM; + + return 0; +} + +void libxl__device_vtpm_add(libxl__egc *egc, uint32_t domid, + libxl_device_vtpm *vtpm, + libxl__ao_device *aodev) +{ + STATE_AO_GC(aodev->ao); + flexarray_t *front; + flexarray_t *back; + libxl__device *device; + char *dompath, **l; + unsigned int nb, rc; + + rc = libxl__device_vtpm_setdefault(gc, vtpm); + if (rc) goto out; + + front = flexarray_make(16, 1); + if (!front) { + rc = ERROR_NOMEM; + goto out; + } + back = flexarray_make(16, 1); + if (!back) { + rc = ERROR_NOMEM; + goto out; + } + + if(vtpm->devid == -1) { + if (!(dompath = libxl__xs_get_dompath(gc, domid))) { + rc = ERROR_FAIL; + goto out_free; + } + l = libxl__xs_directory(gc, XBT_NULL, libxl__sprintf(gc, "%s/device/vtpm", dompath), &nb); + if(l == NULL || nb == 0) { + vtpm->devid = 0; + } else { + vtpm->devid = strtoul(l[nb - 1], NULL, 10) + 1; + } + } + + GCNEW(device); + rc = libxl__device_from_vtpm(gc, domid, vtpm, device); + if ( rc != 0 ) goto out_free; + + flexarray_append(back, "frontend-id"); + flexarray_append(back, libxl__sprintf(gc, "%d", domid)); + flexarray_append(back, "online"); + flexarray_append(back, "1"); + flexarray_append(back, "state"); + flexarray_append(back, libxl__sprintf(gc, "%d", 1)); + + flexarray_append(back, "uuid"); + flexarray_append(back, libxl__sprintf(gc, LIBXL_UUID_FMT, LIBXL_UUID_BYTES(vtpm->uuid))); + flexarray_append(back, "instance"); /* MAYBE CAN GET RID OF THIS */ + flexarray_append(back, "0"); + flexarray_append(back, "pref_instance"); /* MAYBE CAN GET RID OF THIS */ + flexarray_append(back, "0"); + flexarray_append(back, "resume"); + flexarray_append(back, "False"); + flexarray_append(back, "ready"); /* MAYBE CAN GET RID OF THIS */ + flexarray_append(back, "1"); + + flexarray_append(front, "backend-id"); + flexarray_append(front, libxl__sprintf(gc, "%d", vtpm->backend_domid)); + flexarray_append(front, "state"); + flexarray_append(front, libxl__sprintf(gc, "%d", 1)); + flexarray_append(front, "handle"); + flexarray_append(front, libxl__sprintf(gc, "%d", vtpm->devid)); + + libxl__device_generic_add(gc, XBT_NULL, device, + libxl__xs_kvs_of_flexarray(gc, back, back->count), + libxl__xs_kvs_of_flexarray(gc, front, front->count)); + + aodev->dev = device; + aodev->action = DEVICE_CONNECT; + libxl__wait_device_connection(egc, aodev); + + rc = 0; +out_free: + flexarray_free(back); + flexarray_free(front); +out: + aodev->rc = rc; + if(rc) aodev->callback(egc, aodev); + return; +} + +static void libxl__device_vtpm_from_xs_fe(libxl__gc *gc, + const char* fe_path, + libxl_device_vtpm *vtpm) +{ + char* tmp; + + memset(vtpm, 0, sizeof(*vtpm)); + tmp = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/handle", fe_path)); + if (tmp) { + vtpm->devid = atoi(tmp); + } + tmp = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/backend-id", fe_path)); + if(tmp) { + vtpm->backend_domid = atoi(tmp); + } + tmp = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/uuid", fe_path)); + if(tmp) { + libxl_uuid_from_string(&(vtpm->uuid), tmp); + } +} + +libxl_device_vtpm *libxl_device_vtpm_list(libxl_ctx *ctx, uint32_t domid, int *num) +{ + GC_INIT(ctx); + + libxl_device_vtpm* vtpms = NULL; + char* fe_path = NULL; + char** dir = NULL; + unsigned int ndirs = 0; + + *num = 0; + + fe_path = libxl__sprintf(gc, "%s/device/vtpm", libxl__xs_get_dompath(gc, domid)); + dir = libxl__xs_directory(gc, XBT_NULL, fe_path, &ndirs); + if(dir) { + vtpms = malloc(sizeof(*vtpms) * ndirs); + libxl_device_vtpm* vtpm; + libxl_device_vtpm* end = vtpms + ndirs; + for(vtpm = vtpms; vtpm < end; ++vtpm, ++dir) { + const char* path = libxl__sprintf(gc, "%s/%s", fe_path, *dir); + libxl__device_vtpm_from_xs_fe(gc, path, vtpm); + } + } + *num = ndirs; + + GC_FREE; + return vtpms; +} + +int libxl_device_vtpm_getinfo(libxl_ctx *ctx, uint32_t domid, + libxl_device_vtpm *vtpm, libxl_vtpminfo *vtpminfo) +{ + GC_INIT(ctx); + char *dompath, *vtpmpath; + char *val; + int rc = 0; + + libxl_vtpminfo_init(vtpminfo); + dompath = libxl__xs_get_dompath(gc, domid); + vtpminfo->devid = vtpm->devid; + + vtpmpath = libxl__sprintf(gc, "%s/device/vtpm/%d", dompath, vtpminfo->devid); + vtpminfo->backend = xs_read(ctx->xsh, XBT_NULL, + libxl__sprintf(gc, "%s/backend", vtpmpath), NULL); + if (!vtpminfo->backend) { + goto err; + } + if(!libxl__xs_read(gc, XBT_NULL, vtpminfo->backend)) { + goto err; + } + + val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/backend-id", vtpmpath)); + vtpminfo->backend_id = val ? strtoul(val, NULL, 10) : -1; + val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/state", vtpmpath)); + vtpminfo->state = val ? strtoul(val, NULL, 10) : -1; + val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/event-channel", vtpmpath)); + vtpminfo->evtch = val ? strtoul(val, NULL, 10) : -1; + val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/ring-ref", vtpmpath)); + vtpminfo->rref = val ? strtoul(val, NULL, 10) : -1; + vtpminfo->frontend = xs_read(ctx->xsh, XBT_NULL, + libxl__sprintf(gc, "%s/frontend", vtpminfo->backend), NULL); + val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/frontend-id", vtpminfo->backend)); + vtpminfo->frontend_id = val ? strtoul(val, NULL, 10) : -1; + + val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/uuid", vtpminfo->backend)); + if(val == NULL) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s/uuid does not exist!\n", vtpminfo->backend); + goto err; + } + if(libxl_uuid_from_string(&(vtpminfo->uuid), val)) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s/uuid is a malformed uuid?? (%s) Probably a bug!\n", vtpminfo->backend, val); + goto err; + } + + goto exit; +err: + rc = ERROR_FAIL; +exit: + GC_FREE; + return rc; +} + +int libxl_devid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid, + int devid, libxl_device_vtpm *vtpm) +{ + libxl_device_vtpm *vtpms; + int nb, i; + int rc; + + vtpms = libxl_device_vtpm_list(ctx, domid, &nb); + if (!vtpms) + return ERROR_FAIL; + + memset(vtpm, 0, sizeof (libxl_device_vtpm)); + rc = 1; + for (i = 0; i < nb; ++i) { + if(devid == vtpms[i].devid) { + vtpm->backend_domid = vtpms[i].backend_domid; + vtpm->devid = vtpms[i].devid; + libxl_uuid_copy(&vtpm->uuid, &vtpms[i].uuid); + rc = 0; + break; + } + } + + for (i=0; ivkbs[i]); free(d_config->vkbs); + for (i=0; inum_vtpms; i++) + libxl_device_vtpm_dispose(&d_config->vtpms[i]); + free(d_config->vtpms); + libxl_domain_create_info_dispose(&d_config->c_info); libxl_domain_build_info_dispose(&d_config->b_info); } @@ -601,6 +605,8 @@ static void domcreate_bootloader_done(libxl__egc *egc, static void domcreate_launch_dm(libxl__egc *egc, libxl__multidev *aodevs, int ret); +static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multidev *multidev, + int ret); static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev *aodevs, int ret); @@ -1084,13 +1090,13 @@ static void domcreate_devmodel_started(libxl__egc *egc, if (d_config->num_nics > 0) { /* Attach nics */ libxl__multidev_begin(ao, &dcs->multidev); - dcs->multidev.callback = domcreate_attach_pci; + dcs->multidev.callback = domcreate_attach_vtpms; libxl__add_nics(egc, ao, domid, d_config, &dcs->multidev); libxl__multidev_prepared(egc, &dcs->multidev, 0); return; } - domcreate_attach_pci(egc, &dcs->multidev, 0); + domcreate_attach_vtpms(egc, &dcs->multidev, 0); return; error_out: @@ -1098,6 +1104,36 @@ error_out: domcreate_complete(egc, dcs, ret); } +static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multidev *multidev, int ret) { + libxl__domain_create_state *dcs = CONTAINER_OF(multidev, *dcs, multidev); + STATE_AO_GC(dcs->ao); + int domid = dcs->guest_domid; + + libxl_domain_config* const d_config = dcs->guest_config; + + if(ret) { + LOG(ERROR, "unable to add nic devices"); + goto error_out; + } + + /* Plug vtpm devices */ + if (d_config->num_vtpms > 0) { + /* Attach vtpms */ + libxl__multidev_begin(ao, &dcs->multidev); + dcs->multidev.callback = domcreate_attach_pci; + libxl__add_vtpms(egc, ao, domid, d_config, &dcs->multidev); + libxl__multidev_prepared(egc, &dcs->multidev, 0); + return; + } + + domcreate_attach_pci(egc, multidev, 0); + return; + +error_out: + assert(ret); + domcreate_complete(egc, dcs, ret); +} + static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev *multidev, int ret) { @@ -1111,7 +1147,7 @@ static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev *multidev, libxl_domain_config *const d_config = dcs->guest_config; if (ret) { - LOG(ERROR, "unable to add nic devices"); + LOG(ERROR, "unable to add vtpm devices"); goto error_out; } diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c index c3283f1..51dd06e 100644 --- a/tools/libxl/libxl_device.c +++ b/tools/libxl/libxl_device.c @@ -497,6 +497,7 @@ void libxl__multidev_prepared(libxl__egc *egc, * The following functions are defined: * libxl__add_disks * libxl__add_nics + * libxl__add_vtpms */ #define DEFINE_DEVICES_ADD(type) \ @@ -515,6 +516,7 @@ void libxl__multidev_prepared(libxl__egc *egc, DEFINE_DEVICES_ADD(disk) DEFINE_DEVICES_ADD(nic) +DEFINE_DEVICES_ADD(vtpm) #undef DEFINE_DEVICES_ADD diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index b6f54ba..e9a7cbb 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -954,6 +954,7 @@ _hidden int libxl__device_disk_setdefault(libxl__gc *gc, libxl_device_disk *disk); _hidden int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic, uint32_t domid); +_hidden int libxl__device_vtpm_setdefault(libxl__gc *gc, libxl_device_vtpm *vtpm); _hidden int libxl__device_vfb_setdefault(libxl__gc *gc, libxl_device_vfb *vfb); _hidden int libxl__device_vkb_setdefault(libxl__gc *gc, libxl_device_vkb *vkb); _hidden int libxl__device_pci_setdefault(libxl__gc *gc, libxl_device_pci *pci); @@ -1975,6 +1976,10 @@ _hidden void libxl__device_nic_add(libxl__egc *egc, uint32_t domid, libxl_device_nic *nic, libxl__ao_device *aodev); +_hidden void libxl__device_vtpm_add(libxl__egc *egc, uint32_t domid, + libxl_device_vtpm *vtpm, + 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); @@ -2407,6 +2412,10 @@ _hidden void libxl__add_nics(libxl__egc *egc, libxl__ao *ao, uint32_t domid, libxl_domain_config *d_config, libxl__multidev *multidev); +_hidden void libxl__add_vtpms(libxl__egc *egc, libxl__ao *ao, uint32_t domid, + libxl_domain_config *d_config, + libxl__multidev *multidev); + /*----- device model creation -----*/ /* First layer; wraps libxl__spawn_spawn. */ diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl index de111a6..7eac4a8 100644 --- a/tools/libxl/libxl_types.idl +++ b/tools/libxl/libxl_types.idl @@ -395,6 +395,12 @@ libxl_device_pci = Struct("device_pci", [ ("permissive", bool), ]) +libxl_device_vtpm = Struct("device_vtpm", [ + ("backend_domid", libxl_domid), + ("devid", libxl_devid), + ("uuid", libxl_uuid), +]) + libxl_diskinfo = Struct("diskinfo", [ ("backend", string), ("backend_id", uint32), @@ -418,6 +424,18 @@ libxl_nicinfo = Struct("nicinfo", [ ("rref_rx", integer), ], dir=DIR_OUT) +libxl_vtpminfo = Struct("vtpminfo", [ + ("backend", string), + ("backend_id", uint32), + ("frontend", string), + ("frontend_id", uint32), + ("devid", libxl_devid), + ("state", integer), + ("evtch", integer), + ("rref", integer), + ("uuid", libxl_uuid), + ], dir=DIR_OUT) + libxl_vcpuinfo = Struct("vcpuinfo", [ ("vcpuid", uint32), ("cpu", uint32), diff --git a/tools/libxl/libxl_types_internal.idl b/tools/libxl/libxl_types_internal.idl index 5ac8c9c..c40120e 100644 --- a/tools/libxl/libxl_types_internal.idl +++ b/tools/libxl/libxl_types_internal.idl @@ -19,6 +19,7 @@ libxl__device_kind = Enumeration("device_kind", [ (5, "VFB"), (6, "VKBD"), (7, "CONSOLE"), + (8, "VTPM"), ]) libxl__console_backend = Enumeration("console_backend", [ diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c index 55cd299..73a158a 100644 --- a/tools/libxl/libxl_utils.c +++ b/tools/libxl/libxl_utils.c @@ -463,6 +463,35 @@ int libxl_pipe(libxl_ctx *ctx, int pipes[2]) return 0; } +int libxl_uuid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid, + libxl_uuid* uuid, libxl_device_vtpm *vtpm) +{ + libxl_device_vtpm *vtpms; + int nb, i; + int rc; + + vtpms = libxl_device_vtpm_list(ctx, domid, &nb); + if (!vtpms) + return ERROR_FAIL; + + memset(vtpm, 0, sizeof (libxl_device_vtpm)); + rc = 1; + for (i = 0; i < nb; ++i) { + if(!libxl_uuid_compare(uuid, &vtpms[i].uuid)) { + vtpm->backend_domid = vtpms[i].backend_domid; + vtpm->devid = vtpms[i].devid; + libxl_uuid_copy(&vtpm->uuid, &vtpms[i].uuid); + rc = 0; + break; + } + } + + for (i=0; inum_vtpms = 0; + d_config->vtpms = NULL; + while ((buf = xlu_cfg_get_listitem (vtpms, d_config->num_vtpms)) != NULL) { + libxl_device_vtpm *vtpm; + char * buf2 = strdup(buf); + char *p, *p2; + bool got_backend = false; + + d_config->vtpms = (libxl_device_vtpm *) realloc(d_config->vtpms, sizeof(libxl_device_vtpm) * (d_config->num_vtpms+1)); + vtpm = d_config->vtpms + d_config->num_vtpms; + libxl_device_vtpm_init(vtpm); + vtpm->devid = d_config->num_vtpms; + + p = strtok(buf2, ","); + if(p) { + do { + while(*p == ' ') + ++p; + if ((p2 = strchr(p, '=')) == NULL) + break; + *p2 = '\0'; + if (!strcmp(p, "backend")) { + if(domain_qualifier_to_domid(p2 + 1, &(vtpm->backend_domid), 0)) + { + fprintf(stderr, "Specified vtpm backend domain `%s' does not exist!\n", p2 + 1); + exit(1); + } + got_backend = true; + } else if(!strcmp(p, "uuid")) { + if( libxl_uuid_from_string(&vtpm->uuid, p2 + 1) ) { + fprintf(stderr, "Failed to parse vtpm UUID: %s\n", p2 + 1); + exit(1); + } + } else { + fprintf(stderr, "Unknown string `%s' in vtpm spec\n", p); + exit(1); + } + } while ((p = strtok(NULL, ",")) != NULL); + } + if(!got_backend) { + fprintf(stderr, "vtpm spec missing required backend field!\n"); + exit(1); + } + free(buf2); + d_config->num_vtpms++; + } + } + if (!xlu_cfg_get_list (config, "vif", &nics, 0, 0)) { d_config->num_nics = 0; d_config->nics = NULL; @@ -1070,7 +1119,7 @@ static void parse_config_data(const char *config_source, p = strtok(buf2, ","); if (!p) - goto skip; + goto skip_nic; do { while (*p == ' ') p++; @@ -1134,7 +1183,7 @@ static void parse_config_data(const char *config_source, fprintf(stderr, "the accel parameter for vifs is currently not supported\n"); } } while ((p = strtok(NULL, ",")) != NULL); -skip: +skip_nic: free(buf2); d_config->num_nics++; } @@ -5570,6 +5619,131 @@ int main_blockdetach(int argc, char **argv) return rc; } +int main_vtpmattach(int argc, char **argv) +{ + int opt; + libxl_device_vtpm vtpm; + char *oparg; + unsigned int val; + uint32_t domid; + + if ((opt = def_getopt(argc, argv, "", "vtpm-attach", 1)) != -1) + return opt; + + if (domain_qualifier_to_domid(argv[optind], &domid, 0) < 0) { + fprintf(stderr, "%s is an invalid domain identifier\n", argv[optind]); + return 1; + } + ++optind; + + libxl_device_vtpm_init(&vtpm); + for (argv += optind, argc -= optind; argc > 0; ++argv, --argc) { + if (MATCH_OPTION("uuid", *argv, oparg)) { + if(libxl_uuid_from_string(&(vtpm.uuid), oparg)) { + fprintf(stderr, "Invalid uuid specified (%s)\n", oparg); + return 1; + } + } else if (MATCH_OPTION("backend", *argv, oparg)) { + if(domain_qualifier_to_domid(oparg, &val, 0)) { + fprintf(stderr, "Specified backend domain does not exist, defaulting to Dom0\n"); + val = 0; + } + vtpm.backend_domid = val; + } else { + fprintf(stderr, "unrecognized argument `%s'\n", *argv); + return 1; + } + } + + if(dryrun_only) { + char* json = libxl_device_vtpm_to_json(ctx, &vtpm); + printf("vtpm: %s\n", json); + free(json); + libxl_device_vtpm_dispose(&vtpm); + if (ferror(stdout) || fflush(stdout)) { perror("stdout"); exit(-1); } + return 0; + } + + if (libxl_device_vtpm_add(ctx, domid, &vtpm, 0)) { + fprintf(stderr, "libxl_device_vtpm_add failed.\n"); + return 1; + } + libxl_device_vtpm_dispose(&vtpm); + return 0; +} + +int main_vtpmlist(int argc, char **argv) +{ + int opt; + libxl_device_vtpm *vtpms; + libxl_vtpminfo vtpminfo; + int nb, i; + + if ((opt = def_getopt(argc, argv, "", "vtpm-list", 1)) != -1) + return opt; + + /* Idx BE UUID Hdl Sta evch rref BE-path */ + printf("%-3s %-2s %-36s %-6s %-5s %-6s %-5s %-10s\n", + "Idx", "BE", "Uuid", "handle", "state", "evt-ch", "ring-ref", "BE-path"); + for (argv += optind, argc -= optind; argc > 0; --argc, ++argv) { + uint32_t domid; + if (domain_qualifier_to_domid(*argv, &domid, 0) < 0) { + fprintf(stderr, "%s is an invalid domain identifier\n", *argv); + continue; + } + if (!(vtpms = libxl_device_vtpm_list(ctx, domid, &nb))) { + continue; + } + for (i = 0; i < nb; ++i) { + if(!libxl_device_vtpm_getinfo(ctx, domid, &vtpms[i], &vtpminfo)) { + /* Idx BE UUID Hdl Sta evch rref BE-path*/ + printf("%-3d %-2d " LIBXL_UUID_FMT " %6d %5d %6d %8d %-30s\n", + vtpminfo.devid, vtpminfo.backend_id, + LIBXL_UUID_BYTES(vtpminfo.uuid), + vtpminfo.devid, vtpminfo.state, vtpminfo.evtch, + vtpminfo.rref, vtpminfo.backend); + + libxl_vtpminfo_dispose(&vtpminfo); + } + libxl_device_vtpm_dispose(&vtpms[i]); + } + free(vtpms); + } + return 0; +} + +int main_vtpmdetach(int argc, char **argv) +{ + uint32_t domid; + int opt, rc=0; + libxl_device_vtpm vtpm; + libxl_uuid uuid; + + if ((opt = def_getopt(argc, argv, "", "vtpm-detach", 2)) != -1) + return opt; + + domid = find_domain(argv[optind]); + + if ( libxl_uuid_from_string(&uuid, argv[optind+1])) { + if (libxl_devid_to_device_vtpm(ctx, domid, atoi(argv[optind+1]), &vtpm)) { + fprintf(stderr, "Unknown device %s.\n", argv[optind+1]); + return 1; + } + } else { + if (libxl_uuid_to_device_vtpm(ctx, domid, &uuid, &vtpm)) { + fprintf(stderr, "Unknown device %s.\n", argv[optind+1]); + return 1; + } + } + rc = libxl_device_vtpm_remove(ctx, domid, &vtpm, 0); + if (rc) { + fprintf(stderr, "libxl_device_vtpm_remove failed.\n"); + } + libxl_device_vtpm_dispose(&vtpm); + return rc; +} + + static char *uptime_to_string(unsigned long uptime, int short_mode) { int sec, min, hour, day; diff --git a/tools/libxl/xl_cmdtable.c b/tools/libxl/xl_cmdtable.c index 85ea768..7c018eb 100644 --- a/tools/libxl/xl_cmdtable.c +++ b/tools/libxl/xl_cmdtable.c @@ -338,6 +338,21 @@ struct cmd_spec cmd_table[] = { "Destroy a domain's virtual block device", " ", }, + { "vtpm-attach", + &main_vtpmattach, 0, 1, + "Create a new virtual TPM device", + " [uuid=] [backend=]", + }, + { "vtpm-list", + &main_vtpmlist, 0, 0, + "List virtual TPM devices for a domain", + "", + }, + { "vtpm-detach", + &main_vtpmdetach, 0, 1, + "Destroy a domain's virtual TPM device", + " ", + }, { "uptime", &main_uptime, 0, 0, "Print uptime for all/some domains", -- 1.7.4.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 20:04:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 20:04:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TImDp-0005XF-9y; Mon, 01 Oct 2012 20:04:09 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TImDn-0005XA-IK for xen-devel@lists.xen.org; Mon, 01 Oct 2012 20:04:07 +0000 Received: from [85.158.139.83:24840] by server-14.bemta-5.messagelabs.com id E5/0E-05772-637F9605; Mon, 01 Oct 2012 20:04:06 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-13.tower-182.messagelabs.com!1349121843!32398359!1 X-Originating-IP: [128.244.251.37] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6616 invoked from network); 1 Oct 2012 20:04:04 -0000 Received: from piper.jhuapl.edu (HELO jhuapl.edu) (128.244.251.37) by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 20:04:04 -0000 Received: from ([128.244.207.97]) by piper.jhuapl.edu with ESMTP with TLS id 5Y8HCH1.145895581; Mon, 01 Oct 2012 16:03:53 -0400 From: Matthew Fioravante To: xen-devel@lists.xen.org, Ian.Campbell@citrix.com Date: Mon, 1 Oct 2012 16:03:56 -0400 Message-Id: <1349121836-13157-1-git-send-email-matthew.fioravante@jhuapl.edu> X-Mailer: git-send-email 1.7.4.4 Cc: Matthew Fioravante Subject: [Xen-devel] [PATCH] Matthew Fioravante now maintains VTPM X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org See MAINTAINERS file Signed-off-by: Matthew Fioravante diff --git a/MAINTAINERS b/MAINTAINERS index 094fe9e..f562efa 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -261,6 +261,21 @@ S: Supported F: tools/xentrace/ F: xen/common/trace.c +VTPM +M: Matthew Fioravante +S: Supported +F: tools/vtpm +F: tools/vtpm_manager +F: extras/minios-os/tpmfront.c +F: extras/minios-os/tpmback.c +F: extras/minios-os/tpm-tis.c +F: extras/minios-os/include/tpmfront.h +F: extras/minios-os/include/tpmback.h +F: extras/minios-os/include/tpm-tis.h +F: stubdom/vtpm +F: stubdom/vtpmmgr +F: docs/misc/vtpm.txt + THE REST M: Keir Fraser L: xen-devel@lists.xen.org -- 1.7.4.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 20:04:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 20:04:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TImDp-0005XF-9y; Mon, 01 Oct 2012 20:04:09 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TImDn-0005XA-IK for xen-devel@lists.xen.org; Mon, 01 Oct 2012 20:04:07 +0000 Received: from [85.158.139.83:24840] by server-14.bemta-5.messagelabs.com id E5/0E-05772-637F9605; Mon, 01 Oct 2012 20:04:06 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-13.tower-182.messagelabs.com!1349121843!32398359!1 X-Originating-IP: [128.244.251.37] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6616 invoked from network); 1 Oct 2012 20:04:04 -0000 Received: from piper.jhuapl.edu (HELO jhuapl.edu) (128.244.251.37) by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 20:04:04 -0000 Received: from ([128.244.207.97]) by piper.jhuapl.edu with ESMTP with TLS id 5Y8HCH1.145895581; Mon, 01 Oct 2012 16:03:53 -0400 From: Matthew Fioravante To: xen-devel@lists.xen.org, Ian.Campbell@citrix.com Date: Mon, 1 Oct 2012 16:03:56 -0400 Message-Id: <1349121836-13157-1-git-send-email-matthew.fioravante@jhuapl.edu> X-Mailer: git-send-email 1.7.4.4 Cc: Matthew Fioravante Subject: [Xen-devel] [PATCH] Matthew Fioravante now maintains VTPM X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org See MAINTAINERS file Signed-off-by: Matthew Fioravante diff --git a/MAINTAINERS b/MAINTAINERS index 094fe9e..f562efa 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -261,6 +261,21 @@ S: Supported F: tools/xentrace/ F: xen/common/trace.c +VTPM +M: Matthew Fioravante +S: Supported +F: tools/vtpm +F: tools/vtpm_manager +F: extras/minios-os/tpmfront.c +F: extras/minios-os/tpmback.c +F: extras/minios-os/tpm-tis.c +F: extras/minios-os/include/tpmfront.h +F: extras/minios-os/include/tpmback.h +F: extras/minios-os/include/tpm-tis.h +F: stubdom/vtpm +F: stubdom/vtpmmgr +F: docs/misc/vtpm.txt + THE REST M: Keir Fraser L: xen-devel@lists.xen.org -- 1.7.4.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 20:05:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 20:05:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TImEK-0005ZD-Nc; Mon, 01 Oct 2012 20:04:40 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TImEI-0005Yu-Va for xen-devel@lists.xen.org; Mon, 01 Oct 2012 20:04:39 +0000 Received: from [85.158.139.211:22167] by server-4.bemta-5.messagelabs.com id F5/BA-20767-657F9605; Mon, 01 Oct 2012 20:04:38 +0000 X-Env-Sender: dan.magenheimer@oracle.com X-Msg-Ref: server-7.tower-206.messagelabs.com!1349121874!20212228!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc4NTAwMQ==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14851 invoked from network); 1 Oct 2012 20:04:35 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 20:04:35 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q91K3v9Z005132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Oct 2012 20:03:58 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q91K3sgw007486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Oct 2012 20:03:54 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q91K3qnT002121; Mon, 1 Oct 2012 15:03:52 -0500 MIME-Version: 1.0 Message-ID: <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> Date: Mon, 1 Oct 2012 13:03:37 -0700 (PDT) From: Dan Magenheimer To: Ian Jackson References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> In-Reply-To: <20581.55931.246130.308384@mariner.uk.xensource.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7 (607090) [OL 12.0.6661.5003 (x86)] X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: Olaf Hering , Keir Fraser , Konrad Wilk , George Dunlap , Kurt Hackel , tim@xen.org, xen-devel@lists.xen.org, George Shuklin , Dario Faggioli , Andres Lagar-Cavilla Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com] > Sent: Friday, September 28, 2012 11:12 AM > To: Dan Magenheimer > Cc: xen-devel@lists.xen.org; Kurt Hackel; Konrad Wilk > Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) > > Dan Magenheimer writes ("[Xen-devel] domain creation vs querying free memory (xend and xl)"): > > But the second domain launch fails, possibly after > > several minutes because, actually, there isn't enough > > physical RAM for both. > > This is a real problem. The solution is not easy, and may not make it > for 4.3. It would involve a rework of the memory handling code in > libxl. [broadening cc to "Xen memory technology people", please forward/add if I missed someone] Hi Ian -- If you can estimate the difficulty, it would appear you have a specific libxl design in mind? Maybe it would be useful to brainstorm a bit to see if there might be a simpler/different solution? Bearing in mind that I know almost nothing about xl or the tools layer, and that, as a result, I tend to look for hypervisor solutions, I'm thinking it's not possible to solve this without direct participation of the hypervisor anyway, at least while ensuring the solution will successfully work with any memory technology that involves ballooning with the possibility of overcommit (i.e. tmem, page sharing and host-swapping, manual ballooning, PoD)... EVEN if the toolset is single threaded (i.e. only one domain may be created at a time, such as xapi). [1] As a result, I've cc'ed other parties involved in memory technologies who can chime in if they think the above statement is incorrect for their technology... Back to design brainstorming: The way I am thinking about it, the tools need to be involved to the extent that they would need to communicate to the hypervisor the following facts (probably via new hypercall): X1) I am launching a domain X and it is eventually going to consume up to a maximum of N MB. Please tell me if there is sufficient RAM available AND, if so, reserve it until I tell you I am done. ("AND" implies transactional semantics) X2) The launch of X is complete and I will not be requesting the allocation of any more RAM for it. Please release the reservation, whether or not I've requested a total of N MB. The calls may be nested or partially ordered, i.e. X1...Y1...Y2...X2 X1...Y1...X2...Y2 and the hypervisor must be able to deal with this. Then there would need to be two "versions" of "xm/xl free". We can quibble about which should be the default, but they would be: - "xl --reserved free" asks the hypervisor how much RAM is available taking into account reservations - "xm --raw free" asks the hypervisor for the instantaneous amount of RAM unallocated, not counting reservations When the tools are not launching a domain (that is there has been a matching X2 for all X1), the results of the above "free" queries are always identical. So, IanJ, does this match up with the design you were thinking about? Thanks, Dan [1] I think the core culprits are (a) the hypervisor accounts for memory allocation of pages strictly on a first-come-first-served basis and (b) the tools don't have any form of need-this-much-memory "transaction" model _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 20:05:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 20:05:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TImEK-0005ZD-Nc; Mon, 01 Oct 2012 20:04:40 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TImEI-0005Yu-Va for xen-devel@lists.xen.org; Mon, 01 Oct 2012 20:04:39 +0000 Received: from [85.158.139.211:22167] by server-4.bemta-5.messagelabs.com id F5/BA-20767-657F9605; Mon, 01 Oct 2012 20:04:38 +0000 X-Env-Sender: dan.magenheimer@oracle.com X-Msg-Ref: server-7.tower-206.messagelabs.com!1349121874!20212228!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc4NTAwMQ==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14851 invoked from network); 1 Oct 2012 20:04:35 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 20:04:35 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q91K3v9Z005132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Oct 2012 20:03:58 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q91K3sgw007486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Oct 2012 20:03:54 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q91K3qnT002121; Mon, 1 Oct 2012 15:03:52 -0500 MIME-Version: 1.0 Message-ID: <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> Date: Mon, 1 Oct 2012 13:03:37 -0700 (PDT) From: Dan Magenheimer To: Ian Jackson References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> In-Reply-To: <20581.55931.246130.308384@mariner.uk.xensource.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7 (607090) [OL 12.0.6661.5003 (x86)] X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: Olaf Hering , Keir Fraser , Konrad Wilk , George Dunlap , Kurt Hackel , tim@xen.org, xen-devel@lists.xen.org, George Shuklin , Dario Faggioli , Andres Lagar-Cavilla Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com] > Sent: Friday, September 28, 2012 11:12 AM > To: Dan Magenheimer > Cc: xen-devel@lists.xen.org; Kurt Hackel; Konrad Wilk > Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) > > Dan Magenheimer writes ("[Xen-devel] domain creation vs querying free memory (xend and xl)"): > > But the second domain launch fails, possibly after > > several minutes because, actually, there isn't enough > > physical RAM for both. > > This is a real problem. The solution is not easy, and may not make it > for 4.3. It would involve a rework of the memory handling code in > libxl. [broadening cc to "Xen memory technology people", please forward/add if I missed someone] Hi Ian -- If you can estimate the difficulty, it would appear you have a specific libxl design in mind? Maybe it would be useful to brainstorm a bit to see if there might be a simpler/different solution? Bearing in mind that I know almost nothing about xl or the tools layer, and that, as a result, I tend to look for hypervisor solutions, I'm thinking it's not possible to solve this without direct participation of the hypervisor anyway, at least while ensuring the solution will successfully work with any memory technology that involves ballooning with the possibility of overcommit (i.e. tmem, page sharing and host-swapping, manual ballooning, PoD)... EVEN if the toolset is single threaded (i.e. only one domain may be created at a time, such as xapi). [1] As a result, I've cc'ed other parties involved in memory technologies who can chime in if they think the above statement is incorrect for their technology... Back to design brainstorming: The way I am thinking about it, the tools need to be involved to the extent that they would need to communicate to the hypervisor the following facts (probably via new hypercall): X1) I am launching a domain X and it is eventually going to consume up to a maximum of N MB. Please tell me if there is sufficient RAM available AND, if so, reserve it until I tell you I am done. ("AND" implies transactional semantics) X2) The launch of X is complete and I will not be requesting the allocation of any more RAM for it. Please release the reservation, whether or not I've requested a total of N MB. The calls may be nested or partially ordered, i.e. X1...Y1...Y2...X2 X1...Y1...X2...Y2 and the hypervisor must be able to deal with this. Then there would need to be two "versions" of "xm/xl free". We can quibble about which should be the default, but they would be: - "xl --reserved free" asks the hypervisor how much RAM is available taking into account reservations - "xm --raw free" asks the hypervisor for the instantaneous amount of RAM unallocated, not counting reservations When the tools are not launching a domain (that is there has been a matching X2 for all X1), the results of the above "free" queries are always identical. So, IanJ, does this match up with the design you were thinking about? Thanks, Dan [1] I think the core culprits are (a) the hypervisor accounts for memory allocation of pages strictly on a first-come-first-served basis and (b) the tools don't have any form of need-this-much-memory "transaction" model _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 20:12:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 20:12:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TImLu-0005pe-Oo; Mon, 01 Oct 2012 20:12:30 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TImLt-0005pZ-EW for xen-devel@lists.xen.org; Mon, 01 Oct 2012 20:12:29 +0000 Received: from [85.158.139.211:10581] by server-8.bemta-5.messagelabs.com id B2/7A-18073-C29F9605; Mon, 01 Oct 2012 20:12:28 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-5.tower-206.messagelabs.com!1349122346!20626826!1 X-Originating-IP: [128.244.251.37] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6691 invoked from network); 1 Oct 2012 20:12:27 -0000 Received: from piper.jhuapl.edu (HELO jhuapl.edu) (128.244.251.37) by server-5.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 20:12:27 -0000 Received: from ([128.244.207.97]) by piper.jhuapl.edu with ESMTP with TLS id 5Y8HCH1.145896370; Mon, 01 Oct 2012 16:12:16 -0400 From: Matthew Fioravante To: xen-devel@lists.xen.org, Ian.Campbell@citrix.com Date: Mon, 1 Oct 2012 16:12:20 -0400 Message-Id: <1349122340-13436-1-git-send-email-matthew.fioravante@jhuapl.edu> X-Mailer: git-send-email 1.7.4.4 Cc: Matthew Fioravante Subject: [Xen-devel] [PATCH] Matthew Fioravante now maintains VTPM X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org See MAINTAINERS file Signed-off-by: Matthew Fioravante --- Changes since last * Change spaces to tabs, as thats what everything else uses. diff --git a/MAINTAINERS b/MAINTAINERS index 094fe9e..1b73c4f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -261,6 +261,21 @@ S: Supported F: tools/xentrace/ F: xen/common/trace.c +VTPM +M: Matthew Fioravante +S: Supported +F: tools/vtpm +F: tools/vtpm_manager +F: extras/minios-os/tpmfront.c +F: extras/minios-os/tpmback.c +F: extras/minios-os/tpm-tis.c +F: extras/minios-os/include/tpmfront.h +F: extras/minios-os/include/tpmback.h +F: extras/minios-os/include/tpm-tis.h +F: stubdom/vtpm +F: stubdom/vtpmmgr +F: docs/misc/vtpm.txt + THE REST M: Keir Fraser L: xen-devel@lists.xen.org -- 1.7.4.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 20:12:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 20:12:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TImLu-0005pe-Oo; Mon, 01 Oct 2012 20:12:30 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TImLt-0005pZ-EW for xen-devel@lists.xen.org; Mon, 01 Oct 2012 20:12:29 +0000 Received: from [85.158.139.211:10581] by server-8.bemta-5.messagelabs.com id B2/7A-18073-C29F9605; Mon, 01 Oct 2012 20:12:28 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-5.tower-206.messagelabs.com!1349122346!20626826!1 X-Originating-IP: [128.244.251.37] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6691 invoked from network); 1 Oct 2012 20:12:27 -0000 Received: from piper.jhuapl.edu (HELO jhuapl.edu) (128.244.251.37) by server-5.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 20:12:27 -0000 Received: from ([128.244.207.97]) by piper.jhuapl.edu with ESMTP with TLS id 5Y8HCH1.145896370; Mon, 01 Oct 2012 16:12:16 -0400 From: Matthew Fioravante To: xen-devel@lists.xen.org, Ian.Campbell@citrix.com Date: Mon, 1 Oct 2012 16:12:20 -0400 Message-Id: <1349122340-13436-1-git-send-email-matthew.fioravante@jhuapl.edu> X-Mailer: git-send-email 1.7.4.4 Cc: Matthew Fioravante Subject: [Xen-devel] [PATCH] Matthew Fioravante now maintains VTPM X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org See MAINTAINERS file Signed-off-by: Matthew Fioravante --- Changes since last * Change spaces to tabs, as thats what everything else uses. diff --git a/MAINTAINERS b/MAINTAINERS index 094fe9e..1b73c4f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -261,6 +261,21 @@ S: Supported F: tools/xentrace/ F: xen/common/trace.c +VTPM +M: Matthew Fioravante +S: Supported +F: tools/vtpm +F: tools/vtpm_manager +F: extras/minios-os/tpmfront.c +F: extras/minios-os/tpmback.c +F: extras/minios-os/tpm-tis.c +F: extras/minios-os/include/tpmfront.h +F: extras/minios-os/include/tpmback.h +F: extras/minios-os/include/tpm-tis.h +F: stubdom/vtpm +F: stubdom/vtpmmgr +F: docs/misc/vtpm.txt + THE REST M: Keir Fraser L: xen-devel@lists.xen.org -- 1.7.4.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 20:36:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 20:36:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TImip-000625-5w; Mon, 01 Oct 2012 20:36:11 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TImin-00061x-PJ for xen-devel@lists.xensource.com; Mon, 01 Oct 2012 20:36:10 +0000 Received: from [85.158.143.35:6995] by server-1.bemta-4.messagelabs.com id FA/EC-05684-8BEF9605; Mon, 01 Oct 2012 20:36:08 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1349123767!13476805!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI1NjQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5685 invoked from network); 1 Oct 2012 20:36:07 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 20:36:07 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="14878911" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 20:36:06 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 21:36:06 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TImik-00041K-CA; Mon, 01 Oct 2012 20:36:06 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1TImij-0000vc-TS; Mon, 01 Oct 2012 21:36:06 +0100 To: Message-ID: From: xen.org Date: Mon, 1 Oct 2012 21:36:06 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 13905: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 13905 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13905/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-win-vcpus1 12 guest-localmigrate/x10 fail REGR. vs. 13904 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 5 xen-boot fail like 13904 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail like 13904 test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail like 13904 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail like 13904 Tests which did not succeed, but are not blocking: test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: xen f242352da553 baseline version: xen bd953fda6106 ------------------------------------------------------------ People who touched revisions under test: George Dunlap Ian Campbell Ian Jackson Jan Beulich Keir Fraser ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-amd64-amd64-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 25969:f242352da553 tag: tip user: Ian Campbell date: Mon Oct 01 17:54:11 2012 +0100 docs: initial documentation for xenstore paths This is based upon my inspection of a system with a single PV domain and a single HVM domain running and is therefore very incomplete. Signed-off-by: Ian Campbell Acked-by: Ian Jackson Committed-by: Ian Jackson changeset: 25968:91e8fd3cf266 user: George Dunlap date: Mon Oct 01 17:49:01 2012 +0100 docs: Document scheduler-related Xen command-line options Signed-off-by: George Dunlap Acked-by: Ian Campbell Committed-by: Ian Jackson changeset: 25967:bd953fda6106 user: Jan Beulich date: Fri Sep 28 10:59:41 2012 +0200 x86: replace literal numbers In various cases, 256 was being used instead of NR_VECTORS or a derived ARRAY_SIZE() expression. In one case (guest_has_trap_callback()), a wrong (unrelated) constant was used instead of NR_VECTORS. Signed-off-by: Jan Beulich Acked-by: Keir Fraser (qemu changes not included) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 20:36:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 20:36:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TImip-000625-5w; Mon, 01 Oct 2012 20:36:11 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TImin-00061x-PJ for xen-devel@lists.xensource.com; Mon, 01 Oct 2012 20:36:10 +0000 Received: from [85.158.143.35:6995] by server-1.bemta-4.messagelabs.com id FA/EC-05684-8BEF9605; Mon, 01 Oct 2012 20:36:08 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1349123767!13476805!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI1NjQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5685 invoked from network); 1 Oct 2012 20:36:07 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2012 20:36:07 -0000 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="14878911" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Oct 2012 20:36:06 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 21:36:06 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TImik-00041K-CA; Mon, 01 Oct 2012 20:36:06 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1TImij-0000vc-TS; Mon, 01 Oct 2012 21:36:06 +0100 To: Message-ID: From: xen.org Date: Mon, 1 Oct 2012 21:36:06 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 13905: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 13905 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13905/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-win-vcpus1 12 guest-localmigrate/x10 fail REGR. vs. 13904 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 5 xen-boot fail like 13904 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail like 13904 test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail like 13904 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail like 13904 Tests which did not succeed, but are not blocking: test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: xen f242352da553 baseline version: xen bd953fda6106 ------------------------------------------------------------ People who touched revisions under test: George Dunlap Ian Campbell Ian Jackson Jan Beulich Keir Fraser ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-amd64-amd64-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 25969:f242352da553 tag: tip user: Ian Campbell date: Mon Oct 01 17:54:11 2012 +0100 docs: initial documentation for xenstore paths This is based upon my inspection of a system with a single PV domain and a single HVM domain running and is therefore very incomplete. Signed-off-by: Ian Campbell Acked-by: Ian Jackson Committed-by: Ian Jackson changeset: 25968:91e8fd3cf266 user: George Dunlap date: Mon Oct 01 17:49:01 2012 +0100 docs: Document scheduler-related Xen command-line options Signed-off-by: George Dunlap Acked-by: Ian Campbell Committed-by: Ian Jackson changeset: 25967:bd953fda6106 user: Jan Beulich date: Fri Sep 28 10:59:41 2012 +0200 x86: replace literal numbers In various cases, 256 was being used instead of NR_VECTORS or a derived ARRAY_SIZE() expression. In one case (guest_has_trap_callback()), a wrong (unrelated) constant was used instead of NR_VECTORS. Signed-off-by: Jan Beulich Acked-by: Keir Fraser (qemu changes not included) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 21:29:14 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 21:29:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TInXa-0006Qy-KB; Mon, 01 Oct 2012 21:28:38 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TInXZ-0006Qt-Oh for Xen-devel@lists.xensource.com; Mon, 01 Oct 2012 21:28:37 +0000 Received: from [85.158.139.83:9313] by server-5.bemta-5.messagelabs.com id 59/45-21075-50B0A605; Mon, 01 Oct 2012 21:28:37 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1349126915!28988816!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzc0OTkw\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3055 invoked from network); 1 Oct 2012 21:28:36 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 21:28:36 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q91LST0U024417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Oct 2012 21:28:30 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q91LSSsE028517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Oct 2012 21:28:29 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q91LSS1m026010; Mon, 1 Oct 2012 16:28:28 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 01 Oct 2012 14:28:28 -0700 Date: Mon, 1 Oct 2012 14:28:26 -0700 From: Mukesh Rathor To: Ian Campbell Message-ID: <20121001142826.1ebf7b0f@mantra.us.oracle.com> In-Reply-To: <1348581263.11229.21.camel@zakaz.uk.xensource.com> References: <20120921121202.3163c379@mantra.us.oracle.com> <1348581263.11229.21.camel@zakaz.uk.xensource.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 0/8]: PVH (PV guest with extensions) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 25 Sep 2012 14:54:23 +0100 Ian Campbell wrote: > On Fri, 2012-09-21 at 20:12 +0100, Mukesh Rathor wrote: > > Hi guys, > > > > Ok, I've made all the changes from prev RFC patch submission. > > Did I miss the patch with the changes to arch/x86/xen/xen-head.S which > declare the features which are used here as supported by the kernel > image? > > Ian. > Strange, adding following to head.S ELFNOTE(Xen, XEN_ELFNOTE_PADDR_OFFSET, _ASM_PTR 0) ELFNOTE(Xen, XEN_ELFNOTE_GUEST_PVH, .long 1) <-------- and xenstore won't start in dom0. What gives? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 21:29:14 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 21:29:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TInXa-0006Qy-KB; Mon, 01 Oct 2012 21:28:38 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TInXZ-0006Qt-Oh for Xen-devel@lists.xensource.com; Mon, 01 Oct 2012 21:28:37 +0000 Received: from [85.158.139.83:9313] by server-5.bemta-5.messagelabs.com id 59/45-21075-50B0A605; Mon, 01 Oct 2012 21:28:37 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1349126915!28988816!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzc0OTkw\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3055 invoked from network); 1 Oct 2012 21:28:36 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 21:28:36 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q91LST0U024417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Oct 2012 21:28:30 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q91LSSsE028517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Oct 2012 21:28:29 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q91LSS1m026010; Mon, 1 Oct 2012 16:28:28 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 01 Oct 2012 14:28:28 -0700 Date: Mon, 1 Oct 2012 14:28:26 -0700 From: Mukesh Rathor To: Ian Campbell Message-ID: <20121001142826.1ebf7b0f@mantra.us.oracle.com> In-Reply-To: <1348581263.11229.21.camel@zakaz.uk.xensource.com> References: <20120921121202.3163c379@mantra.us.oracle.com> <1348581263.11229.21.camel@zakaz.uk.xensource.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 0/8]: PVH (PV guest with extensions) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 25 Sep 2012 14:54:23 +0100 Ian Campbell wrote: > On Fri, 2012-09-21 at 20:12 +0100, Mukesh Rathor wrote: > > Hi guys, > > > > Ok, I've made all the changes from prev RFC patch submission. > > Did I miss the patch with the changes to arch/x86/xen/xen-head.S which > declare the features which are used here as supported by the kernel > image? > > Ian. > Strange, adding following to head.S ELFNOTE(Xen, XEN_ELFNOTE_PADDR_OFFSET, _ASM_PTR 0) ELFNOTE(Xen, XEN_ELFNOTE_GUEST_PVH, .long 1) <-------- and xenstore won't start in dom0. What gives? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 21:33:22 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 21:33:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TInbj-0006Yy-BX; Mon, 01 Oct 2012 21:32:55 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TInbi-0006Yr-3k for Xen-devel@lists.xensource.com; Mon, 01 Oct 2012 21:32:54 +0000 Received: from [85.158.139.211:45196] by server-3.bemta-5.messagelabs.com id 47/B1-16108-50C0A605; Mon, 01 Oct 2012 21:32:53 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-6.tower-206.messagelabs.com!1349127171!20680412!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc4NTAwMQ==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32456 invoked from network); 1 Oct 2012 21:32:52 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 21:32:52 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q91LWjDb024997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Oct 2012 21:32:46 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q91LWjgC011989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Oct 2012 21:32:45 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q91LWjZQ028779; Mon, 1 Oct 2012 16:32:45 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 01 Oct 2012 14:32:45 -0700 Date: Mon, 1 Oct 2012 14:32:44 -0700 From: Mukesh Rathor To: Stefano Stabellini Message-ID: <20121001143244.36b4c270@mantra.us.oracle.com> In-Reply-To: References: <20120921121556.1a0ea8af@mantra.us.oracle.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "Xen-devel@lists.xensource.com" , Ian Campbell , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, 24 Sep 2012 12:55:31 +0100 Stefano Stabellini wrote: > There are few code style issues on this patch, I suggest you run it > through scripts/checkpatch.pl, it should be able to catch all these > errors. All patches were run thru checkpatch.pl already. So not sure what you are referring to. > > + struct pvh_remap_data *remapp = data; > > + struct xen_pvh_pfn_info *pvhp = remapp->pvhinfop; > > + unsigned long pfn = > > page_to_pfn(pvhp->pi_paga[pvhp->pi_next_todo++]); > > + pte_t pteval = pte_mkspecial(pfn_pte(pfn, remapp->prot)); > > + > > + if ((rc=pvh_add_to_xen_p2m(pfn, remapp->fgmfn, > > remapp->domid))) > > + return rc; > > + native_set_pte(ptep, pteval); > > Do we actually need the pte to be "special"? > I would think that being in the guest p2m, it is actually quite a > normal page. Hmm... well, doesn't like removing "special": BUG: Bad page map in process xl pte:800000027b57b467 pmd:2b408d067 page:ffffea0008afb2e8 count:1 mapcount:-1 mapping: (null) index:0x0 page flags: 0x40000000000414(referenced|dirty|reserved) addr:00007fb4345b0000 vm_flags:000a44fb anon_vma: (null) mapping:ffff88003911a3d0 index:4 vma->vm_ops->fault: privcmd_fault+0x0/0x40 vma->vm_file->f_op->mmap: privcmd_mmap+0x0/0x30 Pid: 2737, comm: xl Tainted: G B 3.6.0-rc6-merge+ #17 Call Trace: [] print_bad_pte+0x1dc/0x250 [] zap_pte_range+0x45e/0x4c0 [] unmap_page_range+0x1ae/0x310 [] unmap_single_vma+0x61/0xe0 [] unmap_vmas+0x54/0xa0 [] unmap_region+0xab/0x120 [] ? privcmd_ioctl+0x93/0x100 [] do_munmap+0x25d/0x380 This from: if (unlikely(page_mapcount(page) < 0)) print_bad_pte(vma, addr, ptent, page); So, the mapcount must be not be getting set in "normal" case properly it appears. Marking it special causes it so skip few things. Debugging... thanks, Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 21:33:22 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 21:33:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TInbj-0006Yy-BX; Mon, 01 Oct 2012 21:32:55 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TInbi-0006Yr-3k for Xen-devel@lists.xensource.com; Mon, 01 Oct 2012 21:32:54 +0000 Received: from [85.158.139.211:45196] by server-3.bemta-5.messagelabs.com id 47/B1-16108-50C0A605; Mon, 01 Oct 2012 21:32:53 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-6.tower-206.messagelabs.com!1349127171!20680412!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc4NTAwMQ==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32456 invoked from network); 1 Oct 2012 21:32:52 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 21:32:52 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q91LWjDb024997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Oct 2012 21:32:46 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q91LWjgC011989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Oct 2012 21:32:45 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q91LWjZQ028779; Mon, 1 Oct 2012 16:32:45 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 01 Oct 2012 14:32:45 -0700 Date: Mon, 1 Oct 2012 14:32:44 -0700 From: Mukesh Rathor To: Stefano Stabellini Message-ID: <20121001143244.36b4c270@mantra.us.oracle.com> In-Reply-To: References: <20120921121556.1a0ea8af@mantra.us.oracle.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "Xen-devel@lists.xensource.com" , Ian Campbell , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, 24 Sep 2012 12:55:31 +0100 Stefano Stabellini wrote: > There are few code style issues on this patch, I suggest you run it > through scripts/checkpatch.pl, it should be able to catch all these > errors. All patches were run thru checkpatch.pl already. So not sure what you are referring to. > > + struct pvh_remap_data *remapp = data; > > + struct xen_pvh_pfn_info *pvhp = remapp->pvhinfop; > > + unsigned long pfn = > > page_to_pfn(pvhp->pi_paga[pvhp->pi_next_todo++]); > > + pte_t pteval = pte_mkspecial(pfn_pte(pfn, remapp->prot)); > > + > > + if ((rc=pvh_add_to_xen_p2m(pfn, remapp->fgmfn, > > remapp->domid))) > > + return rc; > > + native_set_pte(ptep, pteval); > > Do we actually need the pte to be "special"? > I would think that being in the guest p2m, it is actually quite a > normal page. Hmm... well, doesn't like removing "special": BUG: Bad page map in process xl pte:800000027b57b467 pmd:2b408d067 page:ffffea0008afb2e8 count:1 mapcount:-1 mapping: (null) index:0x0 page flags: 0x40000000000414(referenced|dirty|reserved) addr:00007fb4345b0000 vm_flags:000a44fb anon_vma: (null) mapping:ffff88003911a3d0 index:4 vma->vm_ops->fault: privcmd_fault+0x0/0x40 vma->vm_file->f_op->mmap: privcmd_mmap+0x0/0x30 Pid: 2737, comm: xl Tainted: G B 3.6.0-rc6-merge+ #17 Call Trace: [] print_bad_pte+0x1dc/0x250 [] zap_pte_range+0x45e/0x4c0 [] unmap_page_range+0x1ae/0x310 [] unmap_single_vma+0x61/0xe0 [] unmap_vmas+0x54/0xa0 [] unmap_region+0xab/0x120 [] ? privcmd_ioctl+0x93/0x100 [] do_munmap+0x25d/0x380 This from: if (unlikely(page_mapcount(page) < 0)) print_bad_pte(vma, addr, ptent, page); So, the mapcount must be not be getting set in "normal" case properly it appears. Marking it special causes it so skip few things. Debugging... thanks, Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 21:36:48 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 21:36:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TInf9-0006q3-Kb; Mon, 01 Oct 2012 21:36:27 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TInf8-0006pw-PW for xen-devel@lists.xen.org; Mon, 01 Oct 2012 21:36:26 +0000 Received: from [85.158.143.35:27745] by server-3.bemta-4.messagelabs.com id A6/F1-10986-ADC0A605; Mon, 01 Oct 2012 21:36:26 +0000 X-Env-Sender: m.a.young@durham.ac.uk X-Msg-Ref: server-5.tower-21.messagelabs.com!1349127384!4214398!1 X-Originating-IP: [129.234.248.2] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMiA9PiA4NTQ4Ng==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17001 invoked from network); 1 Oct 2012 21:36:25 -0000 Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2) by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 21:36:25 -0000 Received: from smtphost2.dur.ac.uk (smtphost2.dur.ac.uk [129.234.252.2]) by hermes2.dur.ac.uk (8.13.8/8.13.8) with ESMTP id q91La38g025582; Mon, 1 Oct 2012 22:36:08 +0100 Received: from procyon.dur.ac.uk (procyon.dur.ac.uk [129.234.250.129]) by smtphost2.dur.ac.uk (8.14.4/8.14.4) with ESMTP id q91LZwo0010577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Oct 2012 22:35:58 +0100 Received: from procyon.dur.ac.uk (localhost [127.0.0.1]) by procyon.dur.ac.uk (8.14.3/8.11.1) with ESMTP id q91LZwCw026725; Mon, 1 Oct 2012 22:35:58 +0100 Received: from localhost (dcl0may@localhost) by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id q91LZvhd026701; Mon, 1 Oct 2012 22:35:57 +0100 Date: Mon, 1 Oct 2012 22:35:57 +0100 (BST) From: M A Young To: xen-devel@lists.xen.org Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean X-DurhamAcUk-MailScanner-ID: q91La38g025582 Cc: Stefano Stabellini , Konrad Rzeszutek Wilk Subject: [Xen-devel] some recent xen kernel bugs in Fedora X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org There have been a few xen kernel bug reported recently in Fedora. In https://bugzilla.redhat.com/show_bug.cgi?id=861977 someone is getting the error WARNING: at arch/x86/xen/setup.c:88 xen_memory_setup with the kernel 3.5.4-2.fc17.x86_64 (which is roughly 3.5.4 plus patches from the 3.5.5 patch queue including the backports of xen/boot: Disable NUMA for PV guests 8d54db795dfb1049d45dc34f0dddbc5347ec5642 xen/boot: Disable BIOS SMP MP table search bd49940a35ec7d488ae63bd625639893b3385b97 xen/m2p: do not reuse kmap_op->dev_bus_addr 2fc136eecd0c647a6b13fcd00d0c41a1a28f35a5 plus xen-pciback-restore-pci-config-space-after-FLR.patch In https://bugzilla.redhat.com/show_bug.cgi?id=858893 there is a NULL pointer dereference at xennet_poll+0x94e/0xf10 in 3.6.0-0.rc2.git2.1.fc18.x86_64 There is also https://bugzilla.redhat.com/show_bug.cgi?id=859466 where xen 4.2 does not boot on MacBook with a 3.5 kernel unless xsave=off which seems to relate to https://lists.fedoraproject.org/pipermail/xen/2012-August/005879.html Michael Young _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 21:36:48 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 21:36:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TInf9-0006q3-Kb; Mon, 01 Oct 2012 21:36:27 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TInf8-0006pw-PW for xen-devel@lists.xen.org; Mon, 01 Oct 2012 21:36:26 +0000 Received: from [85.158.143.35:27745] by server-3.bemta-4.messagelabs.com id A6/F1-10986-ADC0A605; Mon, 01 Oct 2012 21:36:26 +0000 X-Env-Sender: m.a.young@durham.ac.uk X-Msg-Ref: server-5.tower-21.messagelabs.com!1349127384!4214398!1 X-Originating-IP: [129.234.248.2] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMiA9PiA4NTQ4Ng==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17001 invoked from network); 1 Oct 2012 21:36:25 -0000 Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2) by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 21:36:25 -0000 Received: from smtphost2.dur.ac.uk (smtphost2.dur.ac.uk [129.234.252.2]) by hermes2.dur.ac.uk (8.13.8/8.13.8) with ESMTP id q91La38g025582; Mon, 1 Oct 2012 22:36:08 +0100 Received: from procyon.dur.ac.uk (procyon.dur.ac.uk [129.234.250.129]) by smtphost2.dur.ac.uk (8.14.4/8.14.4) with ESMTP id q91LZwo0010577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Oct 2012 22:35:58 +0100 Received: from procyon.dur.ac.uk (localhost [127.0.0.1]) by procyon.dur.ac.uk (8.14.3/8.11.1) with ESMTP id q91LZwCw026725; Mon, 1 Oct 2012 22:35:58 +0100 Received: from localhost (dcl0may@localhost) by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id q91LZvhd026701; Mon, 1 Oct 2012 22:35:57 +0100 Date: Mon, 1 Oct 2012 22:35:57 +0100 (BST) From: M A Young To: xen-devel@lists.xen.org Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean X-DurhamAcUk-MailScanner-ID: q91La38g025582 Cc: Stefano Stabellini , Konrad Rzeszutek Wilk Subject: [Xen-devel] some recent xen kernel bugs in Fedora X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org There have been a few xen kernel bug reported recently in Fedora. In https://bugzilla.redhat.com/show_bug.cgi?id=861977 someone is getting the error WARNING: at arch/x86/xen/setup.c:88 xen_memory_setup with the kernel 3.5.4-2.fc17.x86_64 (which is roughly 3.5.4 plus patches from the 3.5.5 patch queue including the backports of xen/boot: Disable NUMA for PV guests 8d54db795dfb1049d45dc34f0dddbc5347ec5642 xen/boot: Disable BIOS SMP MP table search bd49940a35ec7d488ae63bd625639893b3385b97 xen/m2p: do not reuse kmap_op->dev_bus_addr 2fc136eecd0c647a6b13fcd00d0c41a1a28f35a5 plus xen-pciback-restore-pci-config-space-after-FLR.patch In https://bugzilla.redhat.com/show_bug.cgi?id=858893 there is a NULL pointer dereference at xennet_poll+0x94e/0xf10 in 3.6.0-0.rc2.git2.1.fc18.x86_64 There is also https://bugzilla.redhat.com/show_bug.cgi?id=859466 where xen 4.2 does not boot on MacBook with a 3.5 kernel unless xsave=off which seems to relate to https://lists.fedoraproject.org/pipermail/xen/2012-August/005879.html Michael Young _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 21:45:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 21:45:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TInnX-0007B9-UX; Mon, 01 Oct 2012 21:45:07 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TInnV-0007B2-WA for Xen-devel@lists.xensource.com; Mon, 01 Oct 2012 21:45:06 +0000 Received: from [85.158.143.35:51472] by server-2.bemta-4.messagelabs.com id 59/A1-06610-1EE0A605; Mon, 01 Oct 2012 21:45:05 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1349127902!13481792!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc4NjIwNQ==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16375 invoked from network); 1 Oct 2012 21:45:04 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 21:45:04 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q91LiwA2002778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Oct 2012 21:44:58 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q91LivT5000579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Oct 2012 21:44:57 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q91LivWt007427; Mon, 1 Oct 2012 16:44:57 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 01 Oct 2012 14:44:56 -0700 Date: Mon, 1 Oct 2012 14:44:55 -0700 From: Mukesh Rathor To: Mukesh Rathor Message-ID: <20121001144455.3ba7e10b@mantra.us.oracle.com> In-Reply-To: <20121001143244.36b4c270@mantra.us.oracle.com> References: <20120921121556.1a0ea8af@mantra.us.oracle.com> <20121001143244.36b4c270@mantra.us.oracle.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "Xen-devel@lists.xensource.com" , Ian Campbell , Konrad Rzeszutek Wilk , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, 1 Oct 2012 14:32:44 -0700 Mukesh Rathor wrote: > > > > + struct pvh_remap_data *remapp = data; > > > + struct xen_pvh_pfn_info *pvhp = remapp->pvhinfop; > > > + unsigned long pfn = > > > page_to_pfn(pvhp->pi_paga[pvhp->pi_next_todo++]); > > > + pte_t pteval = pte_mkspecial(pfn_pte(pfn, remapp->prot)); > > > + > > > + if ((rc=pvh_add_to_xen_p2m(pfn, remapp->fgmfn, > > > remapp->domid))) > > > + return rc; > > > + native_set_pte(ptep, pteval); > > > > Do we actually need the pte to be "special"? > > I would think that being in the guest p2m, it is actually quite a > > normal page. > > Hmm... well, doesn't like removing "special": > > > BUG: Bad page map in process xl pte:800000027b57b467 pmd:2b408d067 > page:ffffea0008afb2e8 count:1 mapcount:-1 mapping: (null) > index:0x0 page flags: 0x40000000000414(referenced|dirty|reserved) > addr:00007fb4345b0000 vm_flags:000a44fb anon_vma: (null) > mapping:ffff88003911a3d0 index:4 vma->vm_ops->fault: > privcmd_fault+0x0/0x40 vma->vm_file->f_op->mmap: privcmd_mmap+0x0/0x30 > Pid: 2737, comm: xl Tainted: G B 3.6.0-rc6-merge+ #17 > Call Trace: > [] print_bad_pte+0x1dc/0x250 > [] zap_pte_range+0x45e/0x4c0 > [] unmap_page_range+0x1ae/0x310 > [] unmap_single_vma+0x61/0xe0 > [] unmap_vmas+0x54/0xa0 > [] unmap_region+0xab/0x120 > [] ? privcmd_ioctl+0x93/0x100 > [] do_munmap+0x25d/0x380 > > This from: > if (unlikely(page_mapcount(page) < 0)) > print_bad_pte(vma, addr, ptent, page); > > > So, the mapcount must be not be getting set in "normal" case properly > it appears. Marking it special causes it so skip few things. > Debugging... Shall I just leave it special for now, and come back and revisit this later? thanks Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Mon Oct 01 21:45:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Oct 2012 21:45:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TInnX-0007B9-UX; Mon, 01 Oct 2012 21:45:07 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TInnV-0007B2-WA for Xen-devel@lists.xensource.com; Mon, 01 Oct 2012 21:45:06 +0000 Received: from [85.158.143.35:51472] by server-2.bemta-4.messagelabs.com id 59/A1-06610-1EE0A605; Mon, 01 Oct 2012 21:45:05 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1349127902!13481792!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc4NjIwNQ==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16375 invoked from network); 1 Oct 2012 21:45:04 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Oct 2012 21:45:04 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q91LiwA2002778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Oct 2012 21:44:58 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q91LivT5000579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Oct 2012 21:44:57 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q91LivWt007427; Mon, 1 Oct 2012 16:44:57 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 01 Oct 2012 14:44:56 -0700 Date: Mon, 1 Oct 2012 14:44:55 -0700 From: Mukesh Rathor To: Mukesh Rathor Message-ID: <20121001144455.3ba7e10b@mantra.us.oracle.com> In-Reply-To: <20121001143244.36b4c270@mantra.us.oracle.com> References: <20120921121556.1a0ea8af@mantra.us.oracle.com> <20121001143244.36b4c270@mantra.us.oracle.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "Xen-devel@lists.xensource.com" , Ian Campbell , Konrad Rzeszutek Wilk , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, 1 Oct 2012 14:32:44 -0700 Mukesh Rathor wrote: > > > > + struct pvh_remap_data *remapp = data; > > > + struct xen_pvh_pfn_info *pvhp = remapp->pvhinfop; > > > + unsigned long pfn = > > > page_to_pfn(pvhp->pi_paga[pvhp->pi_next_todo++]); > > > + pte_t pteval = pte_mkspecial(pfn_pte(pfn, remapp->prot)); > > > + > > > + if ((rc=pvh_add_to_xen_p2m(pfn, remapp->fgmfn, > > > remapp->domid))) > > > + return rc; > > > + native_set_pte(ptep, pteval); > > > > Do we actually need the pte to be "special"? > > I would think that being in the guest p2m, it is actually quite a > > normal page. > > Hmm... well, doesn't like removing "special": > > > BUG: Bad page map in process xl pte:800000027b57b467 pmd:2b408d067 > page:ffffea0008afb2e8 count:1 mapcount:-1 mapping: (null) > index:0x0 page flags: 0x40000000000414(referenced|dirty|reserved) > addr:00007fb4345b0000 vm_flags:000a44fb anon_vma: (null) > mapping:ffff88003911a3d0 index:4 vma->vm_ops->fault: > privcmd_fault+0x0/0x40 vma->vm_file->f_op->mmap: privcmd_mmap+0x0/0x30 > Pid: 2737, comm: xl Tainted: G B 3.6.0-rc6-merge+ #17 > Call Trace: > [] print_bad_pte+0x1dc/0x250 > [] zap_pte_range+0x45e/0x4c0 > [] unmap_page_range+0x1ae/0x310 > [] unmap_single_vma+0x61/0xe0 > [] unmap_vmas+0x54/0xa0 > [] unmap_region+0xab/0x120 > [] ? privcmd_ioctl+0x93/0x100 > [] do_munmap+0x25d/0x380 > > This from: > if (unlikely(page_mapcount(page) < 0)) > print_bad_pte(vma, addr, ptent, page); > > > So, the mapcount must be not be getting set in "normal" case properly > it appears. Marking it special causes it so skip few things. > Debugging... Shall I just leave it special for now, and come back and revisit this later? thanks Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 01:36:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 01:36:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIrOZ-0005wB-9e; Tue, 02 Oct 2012 01:35:35 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIrOY-0005w6-16 for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 01:35:34 +0000 Received: from [85.158.143.35:62815] by server-1.bemta-4.messagelabs.com id B2/C4-05684-5E44A605; Tue, 02 Oct 2012 01:35:33 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1349141731!11226911!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI2OTQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3655 invoked from network); 2 Oct 2012 01:35:31 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 01:35:31 -0000 X-IronPort-AV: E=Sophos;i="4.80,520,1344211200"; d="scan'208";a="14881283" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 01:35:30 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 02:35:30 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TIrOT-0005jl-SZ; Tue, 02 Oct 2012 01:35:29 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1TIrOT-0000gK-Rw; Tue, 02 Oct 2012 02:35:29 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Tue, 2 Oct 2012 02:35:29 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 13906: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 13906 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13906/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 5 xen-boot fail like 13904 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail like 13904 test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail like 13904 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail like 13904 Tests which did not succeed, but are not blocking: test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: xen 5fbdbf585f5f baseline version: xen bd953fda6106 ------------------------------------------------------------ People who touched revisions under test: George Dunlap Ian Campbell Ian Jackson Jan Beulich Keir Fraser Matt Wilson Paul Durrant Xiantao Zhang Xudong Hao ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-amd64-amd64-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable + revision=5fbdbf585f5f + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 5fbdbf585f5f + branch=xen-unstable + revision=5fbdbf585f5f + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + . cri-common ++ umask 002 + select_xenbranch + case "$branch" in + tree=xen + xenbranch=xen-unstable + '[' xxen = xlinux ']' + linuxbranch=linux + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg ++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.xen-unstable ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git ++ : daily-cron.xen-unstable + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git + info_linux_tree xen-unstable + case $1 in + return 1 + case "$branch" in + cd /export/home/osstest/repos/xen-unstable.hg + hg push -r 5fbdbf585f5f ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 7 changesets with 14 changes to 12 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 01:36:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 01:36:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIrOZ-0005wB-9e; Tue, 02 Oct 2012 01:35:35 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIrOY-0005w6-16 for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 01:35:34 +0000 Received: from [85.158.143.35:62815] by server-1.bemta-4.messagelabs.com id B2/C4-05684-5E44A605; Tue, 02 Oct 2012 01:35:33 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1349141731!11226911!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI2OTQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3655 invoked from network); 2 Oct 2012 01:35:31 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 01:35:31 -0000 X-IronPort-AV: E=Sophos;i="4.80,520,1344211200"; d="scan'208";a="14881283" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 01:35:30 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 02:35:30 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TIrOT-0005jl-SZ; Tue, 02 Oct 2012 01:35:29 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1TIrOT-0000gK-Rw; Tue, 02 Oct 2012 02:35:29 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Tue, 2 Oct 2012 02:35:29 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 13906: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 13906 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13906/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 5 xen-boot fail like 13904 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail like 13904 test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail like 13904 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail like 13904 Tests which did not succeed, but are not blocking: test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: xen 5fbdbf585f5f baseline version: xen bd953fda6106 ------------------------------------------------------------ People who touched revisions under test: George Dunlap Ian Campbell Ian Jackson Jan Beulich Keir Fraser Matt Wilson Paul Durrant Xiantao Zhang Xudong Hao ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-amd64-amd64-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable + revision=5fbdbf585f5f + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 5fbdbf585f5f + branch=xen-unstable + revision=5fbdbf585f5f + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + . cri-common ++ umask 002 + select_xenbranch + case "$branch" in + tree=xen + xenbranch=xen-unstable + '[' xxen = xlinux ']' + linuxbranch=linux + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg ++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.xen-unstable ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git ++ : daily-cron.xen-unstable + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git + info_linux_tree xen-unstable + case $1 in + return 1 + case "$branch" in + cd /export/home/osstest/repos/xen-unstable.hg + hg push -r 5fbdbf585f5f ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 7 changesets with 14 changes to 12 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 04:34:44 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 04:34:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIuBM-00079w-VV; Tue, 02 Oct 2012 04:34:08 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with smtp (Exim 4.72) (envelope-from ) id 1TIuBK-00079r-Md for Xen-devel@lists.xensource.com; Tue, 02 Oct 2012 04:34:06 +0000 X-Env-Sender: sfr@canb.auug.org.au X-Msg-Ref: server-6.tower-27.messagelabs.com!1349152439!7546181!1 X-Originating-IP: [203.10.76.10] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27403 invoked from network); 2 Oct 2012 04:34:00 -0000 Received: from haggis.pcug.org.au (HELO members.tip.net.au) (203.10.76.10) by server-6.tower-27.messagelabs.com with SMTP; 2 Oct 2012 04:34:00 -0000 Received: from canb.auug.org.au (ibmaus65.lnk.telstra.net [165.228.126.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by members.tip.net.au (Postfix) with ESMTPSA id 148F91640EA; Tue, 2 Oct 2012 14:33:54 +1000 (EST) Date: Tue, 2 Oct 2012 14:33:50 +1000 From: Stephen Rothwell To: Konrad Rzeszutek Wilk Message-Id: <20121002143350.0fc9812c8ace3bd986ee7d34@canb.auug.org.au> X-Mailer: Sylpheed 3.2.0 (GTK+ 2.24.10; i486-pc-linux-gnu) Mime-Version: 1.0 Cc: Xen Devel , Jeremy Fitzhardinge , linux-next@vger.kernel.org, linux-kernel@vger.kernel.org, Stefano Stabellini Subject: [Xen-devel] linux-next: build failure after merge of the xen-two tree X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1112691651066613485==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============1112691651066613485== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA256"; boundary="Signature=_Tue__2_Oct_2012_14_33_50_+1000_micA0leKeScAbAre" --Signature=_Tue__2_Oct_2012_14_33_50_+1000_micA0leKeScAbAre Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Konrad, After merging the xen-two tree, today's linux-next build (x86_64 allmodconfig) failed like this: arch/x86/built-in.o: In function `xen_start_kernel': (.init.text+0xa88): undefined reference to `xen_acpi_notify_hypervisor_stat= e' drivers/built-in.o: In function `dbgp_reset_prep': (.text+0x12ddeb): undefined reference to `xen_dbgp_reset_prep' drivers/built-in.o: In function `dbgp_external_startup': (.text+0x12e6a9): undefined reference to `xen_dbgp_external_startup' I have used the xen-two tree from next-20121001 for today. --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au --Signature=_Tue__2_Oct_2012_14_33_50_+1000_micA0leKeScAbAre Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQam6uAAoJEECxmPOUX5FEAQsP/1ucAy3YMQCb6yYkbVKChhOk 5fEkHtcS/hnmf5Chv4lrKstgdE9mxk8d4Qo+0GsclBTV6vzZlPnq9ScXePQiAa/4 nEJYlLN3gGbXxJw/ljNRSFJIZ9rpiBMSmjnDNzQAZ0AjAs8c7aGFc2ImhtfjehkY tc46MyjDvslcyMklGEEx5+6MaeKzgmUF0Ci3sJRYu5iBfDEGgvWqW5HMLazrtqET WBLUyBDht80UGhW8c7BUjPrRT4AuxSyoTpnsFlzjQtPkkhimocRL9qk40BiJu0rI OhVow0H9WZ63Kfc7Wxc7CmcOhjvky7htGBEh9qUjSuaw4x5XQWdpoAMHuETv26T5 Ftycd7R7tPLzwQzjb68r81exIXLnM8qj6t2tStDq8/clDbrhehhHL1+KYKvoWul9 jPDO1L3M3n4uwtQGsTVhXk+2vWipQRGmCQER06c+YDd71OF1QyIuOeaigyABeL2j Eht8zdwCeWSMyheQEKl/iYDomaI3e7knT3YTfrZyztuDFHPD+KscapGd4EEoxjmP D9if1YURnBqsvzj6TWXBUWiYSEeDGxoXvuZt0+l13vdnn5cws6l2GQ5tOurdW4tO d4ljx2uDogIynfQAyxlzBxgV5a/ASx3apiX3rE2xugCWkgzpBgiNPCgm/lndCyqi IM5febp1LdKPhYMqznj+ =VO1T -----END PGP SIGNATURE----- --Signature=_Tue__2_Oct_2012_14_33_50_+1000_micA0leKeScAbAre-- --===============1112691651066613485== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============1112691651066613485==-- From xen-devel-bounces@lists.xen.org Tue Oct 02 04:34:44 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 04:34:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIuBM-00079w-VV; Tue, 02 Oct 2012 04:34:08 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with smtp (Exim 4.72) (envelope-from ) id 1TIuBK-00079r-Md for Xen-devel@lists.xensource.com; Tue, 02 Oct 2012 04:34:06 +0000 X-Env-Sender: sfr@canb.auug.org.au X-Msg-Ref: server-6.tower-27.messagelabs.com!1349152439!7546181!1 X-Originating-IP: [203.10.76.10] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27403 invoked from network); 2 Oct 2012 04:34:00 -0000 Received: from haggis.pcug.org.au (HELO members.tip.net.au) (203.10.76.10) by server-6.tower-27.messagelabs.com with SMTP; 2 Oct 2012 04:34:00 -0000 Received: from canb.auug.org.au (ibmaus65.lnk.telstra.net [165.228.126.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by members.tip.net.au (Postfix) with ESMTPSA id 148F91640EA; Tue, 2 Oct 2012 14:33:54 +1000 (EST) Date: Tue, 2 Oct 2012 14:33:50 +1000 From: Stephen Rothwell To: Konrad Rzeszutek Wilk Message-Id: <20121002143350.0fc9812c8ace3bd986ee7d34@canb.auug.org.au> X-Mailer: Sylpheed 3.2.0 (GTK+ 2.24.10; i486-pc-linux-gnu) Mime-Version: 1.0 Cc: Xen Devel , Jeremy Fitzhardinge , linux-next@vger.kernel.org, linux-kernel@vger.kernel.org, Stefano Stabellini Subject: [Xen-devel] linux-next: build failure after merge of the xen-two tree X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1112691651066613485==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============1112691651066613485== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA256"; boundary="Signature=_Tue__2_Oct_2012_14_33_50_+1000_micA0leKeScAbAre" --Signature=_Tue__2_Oct_2012_14_33_50_+1000_micA0leKeScAbAre Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Konrad, After merging the xen-two tree, today's linux-next build (x86_64 allmodconfig) failed like this: arch/x86/built-in.o: In function `xen_start_kernel': (.init.text+0xa88): undefined reference to `xen_acpi_notify_hypervisor_stat= e' drivers/built-in.o: In function `dbgp_reset_prep': (.text+0x12ddeb): undefined reference to `xen_dbgp_reset_prep' drivers/built-in.o: In function `dbgp_external_startup': (.text+0x12e6a9): undefined reference to `xen_dbgp_external_startup' I have used the xen-two tree from next-20121001 for today. --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au --Signature=_Tue__2_Oct_2012_14_33_50_+1000_micA0leKeScAbAre Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQam6uAAoJEECxmPOUX5FEAQsP/1ucAy3YMQCb6yYkbVKChhOk 5fEkHtcS/hnmf5Chv4lrKstgdE9mxk8d4Qo+0GsclBTV6vzZlPnq9ScXePQiAa/4 nEJYlLN3gGbXxJw/ljNRSFJIZ9rpiBMSmjnDNzQAZ0AjAs8c7aGFc2ImhtfjehkY tc46MyjDvslcyMklGEEx5+6MaeKzgmUF0Ci3sJRYu5iBfDEGgvWqW5HMLazrtqET WBLUyBDht80UGhW8c7BUjPrRT4AuxSyoTpnsFlzjQtPkkhimocRL9qk40BiJu0rI OhVow0H9WZ63Kfc7Wxc7CmcOhjvky7htGBEh9qUjSuaw4x5XQWdpoAMHuETv26T5 Ftycd7R7tPLzwQzjb68r81exIXLnM8qj6t2tStDq8/clDbrhehhHL1+KYKvoWul9 jPDO1L3M3n4uwtQGsTVhXk+2vWipQRGmCQER06c+YDd71OF1QyIuOeaigyABeL2j Eht8zdwCeWSMyheQEKl/iYDomaI3e7knT3YTfrZyztuDFHPD+KscapGd4EEoxjmP D9if1YURnBqsvzj6TWXBUWiYSEeDGxoXvuZt0+l13vdnn5cws6l2GQ5tOurdW4tO d4ljx2uDogIynfQAyxlzBxgV5a/ASx3apiX3rE2xugCWkgzpBgiNPCgm/lndCyqi IM5febp1LdKPhYMqznj+ =VO1T -----END PGP SIGNATURE----- --Signature=_Tue__2_Oct_2012_14_33_50_+1000_micA0leKeScAbAre-- --===============1112691651066613485== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============1112691651066613485==-- From xen-devel-bounces@lists.xen.org Tue Oct 02 05:09:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 05:09:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIujQ-0007w4-NL; Tue, 02 Oct 2012 05:09:20 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIujO-0007vz-GB for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 05:09:18 +0000 Received: from [85.158.139.83:21875] by server-4.bemta-5.messagelabs.com id 76/3E-20767-DF67A605; Tue, 02 Oct 2012 05:09:17 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1349154556!30780037!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI2OTQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15727 invoked from network); 2 Oct 2012 05:09:16 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 05:09:16 -0000 X-IronPort-AV: E=Sophos;i="4.80,521,1344211200"; d="scan'208";a="14882624" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 05:09:14 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 06:09:14 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TIujK-0006ru-88; Tue, 02 Oct 2012 05:09:14 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1TIujJ-0000r3-Nx; Tue, 02 Oct 2012 06:09:14 +0100 To: Message-ID: From: xen.org Date: Tue, 2 Oct 2012 06:09:13 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 13909: tolerable FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 13909 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13909/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 5 xen-boot fail like 13906 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail like 13906 test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail like 13906 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail like 13906 Tests which did not succeed, but are not blocking: test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: xen 5fbdbf585f5f baseline version: xen 5fbdbf585f5f jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-amd64-amd64-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 05:09:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 05:09:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIujQ-0007w4-NL; Tue, 02 Oct 2012 05:09:20 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIujO-0007vz-GB for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 05:09:18 +0000 Received: from [85.158.139.83:21875] by server-4.bemta-5.messagelabs.com id 76/3E-20767-DF67A605; Tue, 02 Oct 2012 05:09:17 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1349154556!30780037!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI2OTQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15727 invoked from network); 2 Oct 2012 05:09:16 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 05:09:16 -0000 X-IronPort-AV: E=Sophos;i="4.80,521,1344211200"; d="scan'208";a="14882624" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 05:09:14 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 06:09:14 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TIujK-0006ru-88; Tue, 02 Oct 2012 05:09:14 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1TIujJ-0000r3-Nx; Tue, 02 Oct 2012 06:09:14 +0100 To: Message-ID: From: xen.org Date: Tue, 2 Oct 2012 06:09:13 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 13909: tolerable FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 13909 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13909/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 5 xen-boot fail like 13906 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail like 13906 test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail like 13906 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail like 13906 Tests which did not succeed, but are not blocking: test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: xen 5fbdbf585f5f baseline version: xen 5fbdbf585f5f jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-amd64-amd64-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 06:38:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 06:38:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIw6n-0008Ls-Nt; Tue, 02 Oct 2012 06:37:33 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIw6l-0008Ln-PQ for xen-devel@lists.xen.org; Tue, 02 Oct 2012 06:37:31 +0000 Received: from [85.158.138.51:4423] by server-3.bemta-3.messagelabs.com id C1/8E-25962-AAB8A605; Tue, 02 Oct 2012 06:37:30 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-8.tower-174.messagelabs.com!1349159850!32684344!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MjI2NTM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16728 invoked from network); 2 Oct 2012 06:37:30 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 06:37:30 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id AF63C1DA9; Tue, 2 Oct 2012 09:37:29 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id EFF5B20058; Tue, 2 Oct 2012 09:37:28 +0300 (EEST) Date: Tue, 2 Oct 2012 09:37:28 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Igor Kozhukhov Message-ID: <20121002063728.GH8912@reaktio.net> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] xen-4.3 (unstable) panic X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, Oct 01, 2012 at 11:24:06PM +0400, Igor Kozhukhov wrote: > Hello All, > I try port xen-unstable to illumos-based platform. > I have made some changes on illumos and built xen, but have panic - take a > look [1]http://pastebin.com/fZSrExek > I'd like to see some comments - what I need to check/update. kmdb: single-step stop on division by zero (#de) trap kmdb: target stopped at: sti+0x85: popq %r10 [0]> $C ffffff0003ed1c20 sti+0x85() ffffff0003e05970 switch_sp_and_call+0x13() ffffff0003e059d0 do_interrupt+0x14a() ffffff0003e05a80 xen_callback_handler+0x42d(ffffff0003e05a90, fffffffffbc1d778) ffffff0003e05a90 xen_callback+0x18f() ffffff0003e05ba0 __hypercall2+0xa() ffffff0003e05bb0 HYPERVISOR_block+0x10() ffffff0003e05bc0 mach_cpu_idle+0x1d() ffffff0003e05bf0 cpu_idle+0xfe() ffffff0003e05c00 cpu_idle_adaptive+0x13() ffffff0003e05c20 idle+0x41() ffffff0003e05c30 thread_start+8() So it stopped/crashed because of a division by zero in the dom0 kernel? You need to fix the kernel not to do a divizion by zero? -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 06:38:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 06:38:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIw6n-0008Ls-Nt; Tue, 02 Oct 2012 06:37:33 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIw6l-0008Ln-PQ for xen-devel@lists.xen.org; Tue, 02 Oct 2012 06:37:31 +0000 Received: from [85.158.138.51:4423] by server-3.bemta-3.messagelabs.com id C1/8E-25962-AAB8A605; Tue, 02 Oct 2012 06:37:30 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-8.tower-174.messagelabs.com!1349159850!32684344!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MjI2NTM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16728 invoked from network); 2 Oct 2012 06:37:30 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 06:37:30 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id AF63C1DA9; Tue, 2 Oct 2012 09:37:29 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id EFF5B20058; Tue, 2 Oct 2012 09:37:28 +0300 (EEST) Date: Tue, 2 Oct 2012 09:37:28 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Igor Kozhukhov Message-ID: <20121002063728.GH8912@reaktio.net> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] xen-4.3 (unstable) panic X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, Oct 01, 2012 at 11:24:06PM +0400, Igor Kozhukhov wrote: > Hello All, > I try port xen-unstable to illumos-based platform. > I have made some changes on illumos and built xen, but have panic - take a > look [1]http://pastebin.com/fZSrExek > I'd like to see some comments - what I need to check/update. kmdb: single-step stop on division by zero (#de) trap kmdb: target stopped at: sti+0x85: popq %r10 [0]> $C ffffff0003ed1c20 sti+0x85() ffffff0003e05970 switch_sp_and_call+0x13() ffffff0003e059d0 do_interrupt+0x14a() ffffff0003e05a80 xen_callback_handler+0x42d(ffffff0003e05a90, fffffffffbc1d778) ffffff0003e05a90 xen_callback+0x18f() ffffff0003e05ba0 __hypercall2+0xa() ffffff0003e05bb0 HYPERVISOR_block+0x10() ffffff0003e05bc0 mach_cpu_idle+0x1d() ffffff0003e05bf0 cpu_idle+0xfe() ffffff0003e05c00 cpu_idle_adaptive+0x13() ffffff0003e05c20 idle+0x41() ffffff0003e05c30 thread_start+8() So it stopped/crashed because of a division by zero in the dom0 kernel? You need to fix the kernel not to do a divizion by zero? -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 08:18:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 08:18:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIxg0-0001Ip-Tt; Tue, 02 Oct 2012 08:18:00 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIxfz-0001Ik-Tf for xen-devel@lists.xen.org; Tue, 02 Oct 2012 08:18:00 +0000 Received: from [85.158.143.99:56789] by server-1.bemta-4.messagelabs.com id 31/0F-05684-733AA605; Tue, 02 Oct 2012 08:17:59 +0000 X-Env-Sender: ikozhukhov@gmail.com X-Msg-Ref: server-16.tower-216.messagelabs.com!1349165878!21269407!1 X-Originating-IP: [209.85.215.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19590 invoked from network); 2 Oct 2012 08:17:58 -0000 Received: from mail-la0-f45.google.com (HELO mail-la0-f45.google.com) (209.85.215.45) by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 08:17:58 -0000 Received: by lahm13 with SMTP id m13so2798227lah.32 for ; Tue, 02 Oct 2012 01:17:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding; bh=E0maoSUIX9IcmJHv9jm1O+L6NWcV0scKyQbzSqaVS40=; b=fbjk/ixnek9tVSvJ82/y43pJU0tXDBWXHd9sOvCykjuL4AKgLw5QnRrsmOzXd+RXf+ MDZyILesa3IoJG3jilTHs6OX05fm5U/9jBUMhMQZexLiPBnaDmJsIEzkmBTSVD35FrXi uxcNceIBZgauAbXc/I2QZcQYIKOtVBeTssHZ1ltwcHddWuUDJ6QG6QjSoZKqo4N5H6Lm kRPSNkoqWe4qcfPz6mKOK5cAX/yXOKgqfLadqIrOUkU/PLjQuOAGNo2HHwjYly5ZrFqk lqWU1D8N71SixmVcX04ROFdPyzLJwjRVU9jt0iRYvaSv6LHZoIXJGlGubQgP2UtY/2dZ 3RnA== Received: by 10.112.25.99 with SMTP id b3mr298234lbg.114.1349165877889; Tue, 02 Oct 2012 01:17:57 -0700 (PDT) Received: from [172.16.90.16] ([91.204.58.44]) by mx.google.com with ESMTPS id lr17sm181974lab.12.2012.10.02.01.17.55 (version=SSLv3 cipher=OTHER); Tue, 02 Oct 2012 01:17:56 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Tue, 02 Oct 2012 12:17:51 +0400 From: Igor Kozhukhov To: Pasi =?ISO-8859-1?B?S+Rya2vkaW5lbg==?= Message-ID: Thread-Topic: [Xen-devel] xen-4.3 (unstable) panic In-Reply-To: <20121002063728.GH8912@reaktio.net> Mime-version: 1.0 Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] xen-4.3 (unstable) panic X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Yes - I try to find panic on dom0. I see differences in XEN_SYSCTL_cpu_hotplug implementation between xen-3.x and xen-4.x - was removed response on 4.x. --- Best regards, Igor Kozhukhov IRC# igork On 10/2/12 10:37 AM, "Pasi K=E4rkk=E4inen" wrote: >On Mon, Oct 01, 2012 at 11:24:06PM +0400, Igor Kozhukhov wrote: >> Hello All, >> I try port xen-unstable to illumos-based platform. >> I have made some changes on illumos and built xen, but have panic - >>take a >> look [1]http://pastebin.com/fZSrExek >> I'd like to see some comments - what I need to check/update. > >kmdb: single-step stop on division by zero (#de) trap >kmdb: target stopped at: >sti+0x85: popq %r10 >[0]> $C >ffffff0003ed1c20 sti+0x85() >ffffff0003e05970 switch_sp_and_call+0x13() >ffffff0003e059d0 do_interrupt+0x14a() >ffffff0003e05a80 xen_callback_handler+0x42d(ffffff0003e05a90, >fffffffffbc1d778) >ffffff0003e05a90 xen_callback+0x18f() >ffffff0003e05ba0 __hypercall2+0xa() >ffffff0003e05bb0 HYPERVISOR_block+0x10() >ffffff0003e05bc0 mach_cpu_idle+0x1d() >ffffff0003e05bf0 cpu_idle+0xfe() >ffffff0003e05c00 cpu_idle_adaptive+0x13() >ffffff0003e05c20 idle+0x41() >ffffff0003e05c30 thread_start+8() > >So it stopped/crashed because of a division by zero in the dom0 kernel? >You need to fix the kernel not to do a divizion by zero? > >-- Pasi > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 08:18:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 08:18:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIxg0-0001Ip-Tt; Tue, 02 Oct 2012 08:18:00 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIxfz-0001Ik-Tf for xen-devel@lists.xen.org; Tue, 02 Oct 2012 08:18:00 +0000 Received: from [85.158.143.99:56789] by server-1.bemta-4.messagelabs.com id 31/0F-05684-733AA605; Tue, 02 Oct 2012 08:17:59 +0000 X-Env-Sender: ikozhukhov@gmail.com X-Msg-Ref: server-16.tower-216.messagelabs.com!1349165878!21269407!1 X-Originating-IP: [209.85.215.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19590 invoked from network); 2 Oct 2012 08:17:58 -0000 Received: from mail-la0-f45.google.com (HELO mail-la0-f45.google.com) (209.85.215.45) by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 08:17:58 -0000 Received: by lahm13 with SMTP id m13so2798227lah.32 for ; Tue, 02 Oct 2012 01:17:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding; bh=E0maoSUIX9IcmJHv9jm1O+L6NWcV0scKyQbzSqaVS40=; b=fbjk/ixnek9tVSvJ82/y43pJU0tXDBWXHd9sOvCykjuL4AKgLw5QnRrsmOzXd+RXf+ MDZyILesa3IoJG3jilTHs6OX05fm5U/9jBUMhMQZexLiPBnaDmJsIEzkmBTSVD35FrXi uxcNceIBZgauAbXc/I2QZcQYIKOtVBeTssHZ1ltwcHddWuUDJ6QG6QjSoZKqo4N5H6Lm kRPSNkoqWe4qcfPz6mKOK5cAX/yXOKgqfLadqIrOUkU/PLjQuOAGNo2HHwjYly5ZrFqk lqWU1D8N71SixmVcX04ROFdPyzLJwjRVU9jt0iRYvaSv6LHZoIXJGlGubQgP2UtY/2dZ 3RnA== Received: by 10.112.25.99 with SMTP id b3mr298234lbg.114.1349165877889; Tue, 02 Oct 2012 01:17:57 -0700 (PDT) Received: from [172.16.90.16] ([91.204.58.44]) by mx.google.com with ESMTPS id lr17sm181974lab.12.2012.10.02.01.17.55 (version=SSLv3 cipher=OTHER); Tue, 02 Oct 2012 01:17:56 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Tue, 02 Oct 2012 12:17:51 +0400 From: Igor Kozhukhov To: Pasi =?ISO-8859-1?B?S+Rya2vkaW5lbg==?= Message-ID: Thread-Topic: [Xen-devel] xen-4.3 (unstable) panic In-Reply-To: <20121002063728.GH8912@reaktio.net> Mime-version: 1.0 Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] xen-4.3 (unstable) panic X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Yes - I try to find panic on dom0. I see differences in XEN_SYSCTL_cpu_hotplug implementation between xen-3.x and xen-4.x - was removed response on 4.x. --- Best regards, Igor Kozhukhov IRC# igork On 10/2/12 10:37 AM, "Pasi K=E4rkk=E4inen" wrote: >On Mon, Oct 01, 2012 at 11:24:06PM +0400, Igor Kozhukhov wrote: >> Hello All, >> I try port xen-unstable to illumos-based platform. >> I have made some changes on illumos and built xen, but have panic - >>take a >> look [1]http://pastebin.com/fZSrExek >> I'd like to see some comments - what I need to check/update. > >kmdb: single-step stop on division by zero (#de) trap >kmdb: target stopped at: >sti+0x85: popq %r10 >[0]> $C >ffffff0003ed1c20 sti+0x85() >ffffff0003e05970 switch_sp_and_call+0x13() >ffffff0003e059d0 do_interrupt+0x14a() >ffffff0003e05a80 xen_callback_handler+0x42d(ffffff0003e05a90, >fffffffffbc1d778) >ffffff0003e05a90 xen_callback+0x18f() >ffffff0003e05ba0 __hypercall2+0xa() >ffffff0003e05bb0 HYPERVISOR_block+0x10() >ffffff0003e05bc0 mach_cpu_idle+0x1d() >ffffff0003e05bf0 cpu_idle+0xfe() >ffffff0003e05c00 cpu_idle_adaptive+0x13() >ffffff0003e05c20 idle+0x41() >ffffff0003e05c30 thread_start+8() > >So it stopped/crashed because of a division by zero in the dom0 kernel? >You need to fix the kernel not to do a divizion by zero? > >-- Pasi > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 08:35:30 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 08:35:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIxwU-0001eL-9a; Tue, 02 Oct 2012 08:35:02 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIxwS-0001e5-Lr for xen-devel@lists.xen.org; Tue, 02 Oct 2012 08:35:00 +0000 X-Env-Sender: Paul.Durrant@citrix.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1349166894!13100635!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI2OTQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 536 invoked from network); 2 Oct 2012 08:34:54 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 08:34:54 -0000 X-IronPort-AV: E=Sophos;i="4.80,522,1344211200"; d="scan'208";a="14885691" Received: from lonpmailmx02.citrite.net ([10.30.203.163]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 08:34:54 +0000 Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Tue, 2 Oct 2012 09:34:54 +0100 From: Paul Durrant To: Ian Jackson Date: Tue, 2 Oct 2012 09:34:56 +0100 Thread-Topic: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as the register of product numbers. Thread-Index: Ac2f9ZfdENLT7/LeRGyy+7XYFiRMWgAgoaTQ Message-ID: <291EDFCB1E9E224A99088639C4762022FDDCAB6EFF@LONPMAILBOX01.citrite.net> References: <1349108885-18900-1-git-send-email-paul.durrant@citrix.com> <1349108885-18900-2-git-send-email-paul.durrant@citrix.com> <20585.51980.66172.73036@mariner.uk.xensource.com> In-Reply-To: <20585.51980.66172.73036@mariner.uk.xensource.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "Keir \(Xen.org\)" , Jan Beulich , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as the register of product numbers. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > -----Original Message----- > From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com] > Sent: 01 October 2012 17:56 > To: Paul Durrant > Cc: xen-devel@lists.xen.org; Keir (Xen.org); Jan Beulich > Subject: Re: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve > as the register of product numbers. > > Paul Durrant writes ("[Xen-devel] [PATCH 1/2] Add a new pvdrivers header > to serve as the register of product numbers."): > > These product numbers are used by the QEMU blacklisting protocol in > > traditional QEMU and are currently coded directly into the xenstore.c > > source module. Since there are now multiple QEMUs this information > > should be pulled into a public header to avoid duplication/conflict. > > hvm-emulated-unplug.markdown has also been adjusted to reference the > > new header. > > Acked-by: Ian Jackson > > Given the fact this is in a public header, we should probably get an ack from > Keir or Jan. > Thanks. Paul _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 08:35:30 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 08:35:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIxwU-0001eL-9a; Tue, 02 Oct 2012 08:35:02 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIxwS-0001e5-Lr for xen-devel@lists.xen.org; Tue, 02 Oct 2012 08:35:00 +0000 X-Env-Sender: Paul.Durrant@citrix.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1349166894!13100635!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI2OTQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 536 invoked from network); 2 Oct 2012 08:34:54 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 08:34:54 -0000 X-IronPort-AV: E=Sophos;i="4.80,522,1344211200"; d="scan'208";a="14885691" Received: from lonpmailmx02.citrite.net ([10.30.203.163]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 08:34:54 +0000 Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Tue, 2 Oct 2012 09:34:54 +0100 From: Paul Durrant To: Ian Jackson Date: Tue, 2 Oct 2012 09:34:56 +0100 Thread-Topic: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as the register of product numbers. Thread-Index: Ac2f9ZfdENLT7/LeRGyy+7XYFiRMWgAgoaTQ Message-ID: <291EDFCB1E9E224A99088639C4762022FDDCAB6EFF@LONPMAILBOX01.citrite.net> References: <1349108885-18900-1-git-send-email-paul.durrant@citrix.com> <1349108885-18900-2-git-send-email-paul.durrant@citrix.com> <20585.51980.66172.73036@mariner.uk.xensource.com> In-Reply-To: <20585.51980.66172.73036@mariner.uk.xensource.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "Keir \(Xen.org\)" , Jan Beulich , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as the register of product numbers. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > -----Original Message----- > From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com] > Sent: 01 October 2012 17:56 > To: Paul Durrant > Cc: xen-devel@lists.xen.org; Keir (Xen.org); Jan Beulich > Subject: Re: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve > as the register of product numbers. > > Paul Durrant writes ("[Xen-devel] [PATCH 1/2] Add a new pvdrivers header > to serve as the register of product numbers."): > > These product numbers are used by the QEMU blacklisting protocol in > > traditional QEMU and are currently coded directly into the xenstore.c > > source module. Since there are now multiple QEMUs this information > > should be pulled into a public header to avoid duplication/conflict. > > hvm-emulated-unplug.markdown has also been adjusted to reference the > > new header. > > Acked-by: Ian Jackson > > Given the fact this is in a public header, we should probably get an ack from > Keir or Jan. > Thanks. Paul _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 09:10:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 09:10:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIyUZ-000257-Dn; Tue, 02 Oct 2012 09:10:15 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIyUY-00024y-BX for xen-devel@lists.xen.org; Tue, 02 Oct 2012 09:10:14 +0000 Received: from [85.158.143.99:32854] by server-1.bemta-4.messagelabs.com id C9/87-05684-57FAA605; Tue, 02 Oct 2012 09:10:13 +0000 X-Env-Sender: singapore.mr.teo.en.ming@gmail.com X-Msg-Ref: server-11.tower-216.messagelabs.com!1349169010!24991862!1 X-Originating-IP: [209.85.210.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8353 invoked from network); 2 Oct 2012 09:10:12 -0000 Received: from mail-da0-f45.google.com (HELO mail-da0-f45.google.com) (209.85.210.45) by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 09:10:12 -0000 Received: by dadn15 with SMTP id n15so1884003dad.32 for ; Tue, 02 Oct 2012 02:10:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:subject:content-type:content-transfer-encoding; bh=F0lCKIdPKfa7j4VMz30XWnln1oz8kp1HtcBNgBNcXi0=; b=BqsBis3DbOgQgzI8RclzvfYyKFVVFJDV/KdtdoeiZetkAPKdsQ/nSrZtklphX4m0Yt BJLpASuk266QPieNh8ZWSZap/qKEfXbRgKfIiIyMGg+UhQMjyCHZVDBTGqib3L8Tc7QG YGKHGqL2QUCJpQaD0uQR7m2DlyZLDWnXITndbwoa0sjbREdZKH3LEfi/+8OL1mCNoBNY j6XYqAR+Y1pT5rX6yuliIocGK1Y7T3W2Uu1/abG+S8y2cj4Dg53Pd+kSruU3rDsWdgyi WxvybDs30xqlv6/ebrFwQDs/DQCbhajTOEvz0j96xf7eIuDKCztX2adfQWS6HmwrB0Nk f+GA== Received: by 10.68.220.104 with SMTP id pv8mr2560983pbc.119.1349169009680; Tue, 02 Oct 2012 02:10:09 -0700 (PDT) Received: from [192.168.1.2] (cm152.gamma205.maxonline.com.sg. [202.156.205.152]) by mx.google.com with ESMTPS id py9sm629797pbb.20.2012.10.02.02.10.07 (version=SSLv3 cipher=OTHER); Tue, 02 Oct 2012 02:10:08 -0700 (PDT) Message-ID: <506AAF6D.4060409@gmail.com> Date: Tue, 02 Oct 2012 17:10:05 +0800 From: "Teo En Ming (Zhang Enming)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: "xen-users@lists.xen.org" , "xen-devel@lists.xen.org" , "Teo En Ming (Zhang Enming)" Subject: [Xen-devel] Xen 4.2.0 does not have the file passthrough.c X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hi, Xen 4.2.0 official tarball does not have the file passthrough.c. Does it mean that Xen 4.2.0 does not support vga passthrough? -- Yours sincerely, Mr. Teo En Ming (Zhang Enming) Singapore _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 09:10:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 09:10:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIyUZ-000257-Dn; Tue, 02 Oct 2012 09:10:15 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIyUY-00024y-BX for xen-devel@lists.xen.org; Tue, 02 Oct 2012 09:10:14 +0000 Received: from [85.158.143.99:32854] by server-1.bemta-4.messagelabs.com id C9/87-05684-57FAA605; Tue, 02 Oct 2012 09:10:13 +0000 X-Env-Sender: singapore.mr.teo.en.ming@gmail.com X-Msg-Ref: server-11.tower-216.messagelabs.com!1349169010!24991862!1 X-Originating-IP: [209.85.210.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8353 invoked from network); 2 Oct 2012 09:10:12 -0000 Received: from mail-da0-f45.google.com (HELO mail-da0-f45.google.com) (209.85.210.45) by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 09:10:12 -0000 Received: by dadn15 with SMTP id n15so1884003dad.32 for ; Tue, 02 Oct 2012 02:10:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:subject:content-type:content-transfer-encoding; bh=F0lCKIdPKfa7j4VMz30XWnln1oz8kp1HtcBNgBNcXi0=; b=BqsBis3DbOgQgzI8RclzvfYyKFVVFJDV/KdtdoeiZetkAPKdsQ/nSrZtklphX4m0Yt BJLpASuk266QPieNh8ZWSZap/qKEfXbRgKfIiIyMGg+UhQMjyCHZVDBTGqib3L8Tc7QG YGKHGqL2QUCJpQaD0uQR7m2DlyZLDWnXITndbwoa0sjbREdZKH3LEfi/+8OL1mCNoBNY j6XYqAR+Y1pT5rX6yuliIocGK1Y7T3W2Uu1/abG+S8y2cj4Dg53Pd+kSruU3rDsWdgyi WxvybDs30xqlv6/ebrFwQDs/DQCbhajTOEvz0j96xf7eIuDKCztX2adfQWS6HmwrB0Nk f+GA== Received: by 10.68.220.104 with SMTP id pv8mr2560983pbc.119.1349169009680; Tue, 02 Oct 2012 02:10:09 -0700 (PDT) Received: from [192.168.1.2] (cm152.gamma205.maxonline.com.sg. [202.156.205.152]) by mx.google.com with ESMTPS id py9sm629797pbb.20.2012.10.02.02.10.07 (version=SSLv3 cipher=OTHER); Tue, 02 Oct 2012 02:10:08 -0700 (PDT) Message-ID: <506AAF6D.4060409@gmail.com> Date: Tue, 02 Oct 2012 17:10:05 +0800 From: "Teo En Ming (Zhang Enming)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: "xen-users@lists.xen.org" , "xen-devel@lists.xen.org" , "Teo En Ming (Zhang Enming)" Subject: [Xen-devel] Xen 4.2.0 does not have the file passthrough.c X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hi, Xen 4.2.0 official tarball does not have the file passthrough.c. Does it mean that Xen 4.2.0 does not support vga passthrough? -- Yours sincerely, Mr. Teo En Ming (Zhang Enming) Singapore _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 09:10:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 09:10:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIyUe-00025a-CZ; Tue, 02 Oct 2012 09:10:20 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIyUd-00025Q-OQ for xen-devel@lists.xen.org; Tue, 02 Oct 2012 09:10:19 +0000 Received: from [85.158.138.51:32812] by server-13.bemta-3.messagelabs.com id 83/77-11249-A7FAA605; Tue, 02 Oct 2012 09:10:18 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1349169018!24825976!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI2OTQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13522 invoked from network); 2 Oct 2012 09:10:18 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 09:10:18 -0000 X-IronPort-AV: E=Sophos;i="4.80,522,1344211200"; d="scan'208";a="14886688" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 09:10:17 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 10:10:17 +0100 Message-ID: <1349169015.650.11.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Matthew Fioravante Date: Tue, 2 Oct 2012 10:10:15 +0100 In-Reply-To: <5065ACB7.3040902@jhuapl.edu> References: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu> <5065ACB7.3040902@jhuapl.edu> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: George Dunlap , "samuel.thibault@ens-lyon.org" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 01/11] Add ioread/iowrite functions to mini-os X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-09-28 at 14:57 +0100, Matthew Fioravante wrote: > On 09/28/2012 06:16 AM, George Dunlap wrote: > > On Thu, Sep 27, 2012 at 6:09 PM, Matthew Fioravante > > wrote: > >> This patch adds iowritexx() and ioreadxx() functions for interacting > >> with hardware memory to mini-os. The functions are available in a header > >> iorw.h > >> > >> Signed-off-by: Matthew Fioravante > >> Acked-by: Samuel Thibault > >> > >> diff --git a/extras/mini-os/arch/ia64/iorw.c b/extras/mini-os/arch/ia64/iorw.c > > Is there any reason to have the ia64 stuff? ia64 isn't supported in > > Xen anymore, AFAIK. > Maybe not. But until ia64 support is removed from mini-os the function > bodies should exist so stuff will compile. I thought I had dropped all the remnants of ia64 in mini-os in commit 25882:485e6db28b93 "tools: drop ia64 support". Let me know if you think I've missed something, but: > >> new file mode 100644 > >> index 0000000..aa58807 > >> --- /dev/null > >> +++ b/extras/mini-os/arch/ia64/iorw.c $ ls extras/mini-os/arch/ia64/iorw.c ls: cannot access extras/mini-os/arch/ia64/iorw.c: No such file or directory I think perhaps you just need to rebase? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 09:10:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 09:10:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIyUe-00025a-CZ; Tue, 02 Oct 2012 09:10:20 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIyUd-00025Q-OQ for xen-devel@lists.xen.org; Tue, 02 Oct 2012 09:10:19 +0000 Received: from [85.158.138.51:32812] by server-13.bemta-3.messagelabs.com id 83/77-11249-A7FAA605; Tue, 02 Oct 2012 09:10:18 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1349169018!24825976!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI2OTQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13522 invoked from network); 2 Oct 2012 09:10:18 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 09:10:18 -0000 X-IronPort-AV: E=Sophos;i="4.80,522,1344211200"; d="scan'208";a="14886688" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 09:10:17 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 10:10:17 +0100 Message-ID: <1349169015.650.11.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Matthew Fioravante Date: Tue, 2 Oct 2012 10:10:15 +0100 In-Reply-To: <5065ACB7.3040902@jhuapl.edu> References: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu> <5065ACB7.3040902@jhuapl.edu> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: George Dunlap , "samuel.thibault@ens-lyon.org" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 01/11] Add ioread/iowrite functions to mini-os X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-09-28 at 14:57 +0100, Matthew Fioravante wrote: > On 09/28/2012 06:16 AM, George Dunlap wrote: > > On Thu, Sep 27, 2012 at 6:09 PM, Matthew Fioravante > > wrote: > >> This patch adds iowritexx() and ioreadxx() functions for interacting > >> with hardware memory to mini-os. The functions are available in a header > >> iorw.h > >> > >> Signed-off-by: Matthew Fioravante > >> Acked-by: Samuel Thibault > >> > >> diff --git a/extras/mini-os/arch/ia64/iorw.c b/extras/mini-os/arch/ia64/iorw.c > > Is there any reason to have the ia64 stuff? ia64 isn't supported in > > Xen anymore, AFAIK. > Maybe not. But until ia64 support is removed from mini-os the function > bodies should exist so stuff will compile. I thought I had dropped all the remnants of ia64 in mini-os in commit 25882:485e6db28b93 "tools: drop ia64 support". Let me know if you think I've missed something, but: > >> new file mode 100644 > >> index 0000000..aa58807 > >> --- /dev/null > >> +++ b/extras/mini-os/arch/ia64/iorw.c $ ls extras/mini-os/arch/ia64/iorw.c ls: cannot access extras/mini-os/arch/ia64/iorw.c: No such file or directory I think perhaps you just need to rebase? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 09:10:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 09:10:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIyUm-00026k-P3; Tue, 02 Oct 2012 09:10:28 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIyUl-00026W-OL for xen-devel@lists.xen.org; Tue, 02 Oct 2012 09:10:28 +0000 Received: from [85.158.139.83:18386] by server-2.bemta-5.messagelabs.com id 63/37-28944-28FAA605; Tue, 02 Oct 2012 09:10:26 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-8.tower-182.messagelabs.com!1349169025!18929641!1 X-Originating-IP: [81.29.64.94] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10403 invoked from network); 2 Oct 2012 09:10:25 -0000 Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94) by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 09:10:25 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1TIyUb-000P2u-Vn; Tue, 02 Oct 2012 09:10:17 +0000 Date: Tue, 2 Oct 2012 10:10:17 +0100 From: Tim Deegan To: Dan Magenheimer Message-ID: <20121002091017.GA95926@ocelot.phlegethon.org> References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> User-Agent: Mutt/1.4.2.1i Cc: Olaf Hering , Keir Fraser , Konrad Wilk , George Dunlap , Kurt Hackel , Ian Jackson , xen-devel@lists.xen.org, George Shuklin , Dario Faggioli , Andres Lagar-Cavilla Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org At 13:03 -0700 on 01 Oct (1349096617), Dan Magenheimer wrote: > Bearing in mind that I know almost nothing about xl or > the tools layer, and that, as a result, I tend to look > for hypervisor solutions, I'm thinking it's not possible to > solve this without direct participation of the hypervisor anyway, > at least while ensuring the solution will successfully > work with any memory technology that involves ballooning > with the possibility of overcommit (i.e. tmem, page sharing > and host-swapping, manual ballooning, PoD)... EVEN if the > toolset is single threaded (i.e. only one domain may > be created at a time, such as xapi). [1] TTBOMK, Xapi actually _has_ solved this problem, even with ballooning and PoD. I don't know if they have any plans to support sharing, swapping or tmem, though. Adding a 'reservation' of free pages that may only be allocated by a given domain should be straightforward enough, but I'm not sure it helps much. In the 'balloon-to-fit' model where all memory is already allocated to some domain (or tmem), some part of the toolstack needs to sort out freeing up the memory before allocating it to another VM. Surely that component needs to handle the exclusion too - otherwise a series of small VM creations could stall a large one indefinitely. Cheers, Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 09:10:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 09:10:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIyUm-00026k-P3; Tue, 02 Oct 2012 09:10:28 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIyUl-00026W-OL for xen-devel@lists.xen.org; Tue, 02 Oct 2012 09:10:28 +0000 Received: from [85.158.139.83:18386] by server-2.bemta-5.messagelabs.com id 63/37-28944-28FAA605; Tue, 02 Oct 2012 09:10:26 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-8.tower-182.messagelabs.com!1349169025!18929641!1 X-Originating-IP: [81.29.64.94] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10403 invoked from network); 2 Oct 2012 09:10:25 -0000 Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94) by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 09:10:25 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1TIyUb-000P2u-Vn; Tue, 02 Oct 2012 09:10:17 +0000 Date: Tue, 2 Oct 2012 10:10:17 +0100 From: Tim Deegan To: Dan Magenheimer Message-ID: <20121002091017.GA95926@ocelot.phlegethon.org> References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> User-Agent: Mutt/1.4.2.1i Cc: Olaf Hering , Keir Fraser , Konrad Wilk , George Dunlap , Kurt Hackel , Ian Jackson , xen-devel@lists.xen.org, George Shuklin , Dario Faggioli , Andres Lagar-Cavilla Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org At 13:03 -0700 on 01 Oct (1349096617), Dan Magenheimer wrote: > Bearing in mind that I know almost nothing about xl or > the tools layer, and that, as a result, I tend to look > for hypervisor solutions, I'm thinking it's not possible to > solve this without direct participation of the hypervisor anyway, > at least while ensuring the solution will successfully > work with any memory technology that involves ballooning > with the possibility of overcommit (i.e. tmem, page sharing > and host-swapping, manual ballooning, PoD)... EVEN if the > toolset is single threaded (i.e. only one domain may > be created at a time, such as xapi). [1] TTBOMK, Xapi actually _has_ solved this problem, even with ballooning and PoD. I don't know if they have any plans to support sharing, swapping or tmem, though. Adding a 'reservation' of free pages that may only be allocated by a given domain should be straightforward enough, but I'm not sure it helps much. In the 'balloon-to-fit' model where all memory is already allocated to some domain (or tmem), some part of the toolstack needs to sort out freeing up the memory before allocating it to another VM. Surely that component needs to handle the exclusion too - otherwise a series of small VM creations could stall a large one indefinitely. Cheers, Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 09:21:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 09:21:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIyee-0002pZ-7A; Tue, 02 Oct 2012 09:20:40 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIyec-0002pO-WF for xen-devel@lists.xen.org; Tue, 02 Oct 2012 09:20:39 +0000 Received: from [85.158.143.35:43851] by server-1.bemta-4.messagelabs.com id 56/1D-05684-6E1BA605; Tue, 02 Oct 2012 09:20:38 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1349169636!4275941!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI2OTQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7674 invoked from network); 2 Oct 2012 09:20:37 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 09:20:37 -0000 X-IronPort-AV: E=Sophos;i="4.80,522,1344211200"; d="scan'208";a="14886967" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 09:20:36 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 10:20:36 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TIyea-0008Fq-D2; Tue, 02 Oct 2012 09:20:36 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TIyea-0005i6-7G; Tue, 02 Oct 2012 10:20:36 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20586.45540.50108.911066@mariner.uk.xensource.com> Date: Tue, 2 Oct 2012 10:20:36 +0100 To: Andres Lagar-Cavilla Newsgroups: chiark.mail.xen.devel In-Reply-To: References: X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Keir Fraser , Jan Beulich , xen-devel Subject: Re: [Xen-devel] Backport request: 25914:cd2a831d0a41 to xen-4.2-testing.hg X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Andres Lagar-Cavilla writes ("[Xen-devel] Backport request: 25914:cd2a831d0a41 to xen-4.2-testing.hg"): > It seems back porting has started. I would have asked for a few others, but I've been beaten to the punch! Done. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 09:21:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 09:21:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIyee-0002pZ-7A; Tue, 02 Oct 2012 09:20:40 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIyec-0002pO-WF for xen-devel@lists.xen.org; Tue, 02 Oct 2012 09:20:39 +0000 Received: from [85.158.143.35:43851] by server-1.bemta-4.messagelabs.com id 56/1D-05684-6E1BA605; Tue, 02 Oct 2012 09:20:38 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1349169636!4275941!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI2OTQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7674 invoked from network); 2 Oct 2012 09:20:37 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 09:20:37 -0000 X-IronPort-AV: E=Sophos;i="4.80,522,1344211200"; d="scan'208";a="14886967" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 09:20:36 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 10:20:36 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TIyea-0008Fq-D2; Tue, 02 Oct 2012 09:20:36 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TIyea-0005i6-7G; Tue, 02 Oct 2012 10:20:36 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20586.45540.50108.911066@mariner.uk.xensource.com> Date: Tue, 2 Oct 2012 10:20:36 +0100 To: Andres Lagar-Cavilla Newsgroups: chiark.mail.xen.devel In-Reply-To: References: X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Keir Fraser , Jan Beulich , xen-devel Subject: Re: [Xen-devel] Backport request: 25914:cd2a831d0a41 to xen-4.2-testing.hg X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Andres Lagar-Cavilla writes ("[Xen-devel] Backport request: 25914:cd2a831d0a41 to xen-4.2-testing.hg"): > It seems back porting has started. I would have asked for a few others, but I've been beaten to the punch! Done. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 09:25:42 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 09:25:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIyjC-000319-1j; Tue, 02 Oct 2012 09:25:22 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIyjA-000312-JT for xen-devel@lists.xen.org; Tue, 02 Oct 2012 09:25:20 +0000 Received: from [85.158.137.99:40367] by server-2.bemta-3.messagelabs.com id 80/C5-16514-FF2BA605; Tue, 02 Oct 2012 09:25:19 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-217.messagelabs.com!1349169918!14569536!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI2OTQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6970 invoked from network); 2 Oct 2012 09:25:18 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 09:25:18 -0000 X-IronPort-AV: E=Sophos;i="4.80,522,1344211200"; d="scan'208";a="14887092" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 09:25:18 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 10:25:17 +0100 Message-ID: <1349169916.650.15.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Paul Durrant Date: Tue, 2 Oct 2012 10:25:16 +0100 In-Reply-To: <291EDFCB1E9E224A99088639C4762022FDDCAB6EB5@LONPMAILBOX01.citrite.net> References: <1349084633-13186-1-git-send-email-paul.durrant@citrix.com> <20585.45901.698074.351144@mariner.uk.xensource.com> <291EDFCB1E9E224A99088639C4762022FDDCAB6EB5@LONPMAILBOX01.citrite.net> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: Ian Jackson , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] Use new Xen public header for product numbers and names X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, 2012-10-01 at 17:08 +0100, Paul Durrant wrote: > > -----Original Message----- > > From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com] > > Sent: 01 October 2012 16:14 > > To: Paul Durrant > > Cc: xen-devel@lists.xen.org > > Subject: Re: [Xen-devel] [PATCH] Use new Xen public header for product > > numbers and names > > > > Paul Durrant writes ("[Xen-devel] [PATCH] Use new Xen public header for > > product numbers and names"): > > > xen/include/public/hvm/pvdrivers.h has been added as the register of > > > product numbers used by the blacklisting protocol. > > > Use the definitions therein rather then locally coded values. > > ... > > > +#define PRODUCT(_name, _nr) case _nr: product = _name; break; > > > switch (product_nr) { > > > - /* > > > - * In qemu-xen-unstable, this is the master registry of product > > > - * numbers. If you need a new product number allocating, please > > > - * post to xen-devel@lists.xensource.com. You should NOT use > > > - * an existing product number without allocating one. > > > - * > > > - * If you maintain a seaparate versioning and distribution path > > > - * for PV drivers you should have a separate product number so > > > - * that your drivers can be separated from others'. > > > - * > > > - * During development, you may use the product ID 0xffff to > > > - * indicate a driver which is yet to be released. > > > - */ > > > - case 1: product = "xensource-windows"; break; /* Citrix */ > > > - case 2: product = "gplpv-windows"; break; /* James Harper */ > > > - case 0xffff: product = "experimental"; break; > > > + PVDRIVERS_PRODUCT_LIST(PRODUCT) > > > > As a case in point, this generates: > > case 0: product = NULL; break; > > and then passes the NULL to asprintf. > > > > Nothing should be using product number 0, so is this a problem? In some circumstances (I think) the product number may come from the guest, which may be malicious. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 09:25:42 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 09:25:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIyjC-000319-1j; Tue, 02 Oct 2012 09:25:22 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIyjA-000312-JT for xen-devel@lists.xen.org; Tue, 02 Oct 2012 09:25:20 +0000 Received: from [85.158.137.99:40367] by server-2.bemta-3.messagelabs.com id 80/C5-16514-FF2BA605; Tue, 02 Oct 2012 09:25:19 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-217.messagelabs.com!1349169918!14569536!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI2OTQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6970 invoked from network); 2 Oct 2012 09:25:18 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 09:25:18 -0000 X-IronPort-AV: E=Sophos;i="4.80,522,1344211200"; d="scan'208";a="14887092" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 09:25:18 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 10:25:17 +0100 Message-ID: <1349169916.650.15.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Paul Durrant Date: Tue, 2 Oct 2012 10:25:16 +0100 In-Reply-To: <291EDFCB1E9E224A99088639C4762022FDDCAB6EB5@LONPMAILBOX01.citrite.net> References: <1349084633-13186-1-git-send-email-paul.durrant@citrix.com> <20585.45901.698074.351144@mariner.uk.xensource.com> <291EDFCB1E9E224A99088639C4762022FDDCAB6EB5@LONPMAILBOX01.citrite.net> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: Ian Jackson , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] Use new Xen public header for product numbers and names X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, 2012-10-01 at 17:08 +0100, Paul Durrant wrote: > > -----Original Message----- > > From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com] > > Sent: 01 October 2012 16:14 > > To: Paul Durrant > > Cc: xen-devel@lists.xen.org > > Subject: Re: [Xen-devel] [PATCH] Use new Xen public header for product > > numbers and names > > > > Paul Durrant writes ("[Xen-devel] [PATCH] Use new Xen public header for > > product numbers and names"): > > > xen/include/public/hvm/pvdrivers.h has been added as the register of > > > product numbers used by the blacklisting protocol. > > > Use the definitions therein rather then locally coded values. > > ... > > > +#define PRODUCT(_name, _nr) case _nr: product = _name; break; > > > switch (product_nr) { > > > - /* > > > - * In qemu-xen-unstable, this is the master registry of product > > > - * numbers. If you need a new product number allocating, please > > > - * post to xen-devel@lists.xensource.com. You should NOT use > > > - * an existing product number without allocating one. > > > - * > > > - * If you maintain a seaparate versioning and distribution path > > > - * for PV drivers you should have a separate product number so > > > - * that your drivers can be separated from others'. > > > - * > > > - * During development, you may use the product ID 0xffff to > > > - * indicate a driver which is yet to be released. > > > - */ > > > - case 1: product = "xensource-windows"; break; /* Citrix */ > > > - case 2: product = "gplpv-windows"; break; /* James Harper */ > > > - case 0xffff: product = "experimental"; break; > > > + PVDRIVERS_PRODUCT_LIST(PRODUCT) > > > > As a case in point, this generates: > > case 0: product = NULL; break; > > and then passes the NULL to asprintf. > > > > Nothing should be using product number 0, so is this a problem? In some circumstances (I think) the product number may come from the guest, which may be malicious. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 09:27:03 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 09:27:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIyka-00036V-Gx; Tue, 02 Oct 2012 09:26:48 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIykZ-00036P-Eb for xen-devel@lists.xen.org; Tue, 02 Oct 2012 09:26:47 +0000 Received: from [85.158.139.211:36624] by server-9.bemta-5.messagelabs.com id BD/AE-14846-653BA605; Tue, 02 Oct 2012 09:26:46 +0000 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-13.tower-206.messagelabs.com!1349170005!16754960!1 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9677 invoked from network); 2 Oct 2012 09:26:46 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 09:26:46 -0000 Received: by eekb47 with SMTP id b47so3021915eek.32 for ; Tue, 02 Oct 2012 02:26:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=6v4Ryb+E3NvUAbHGTNlkjWH+VNj01IpY1wcVN2oN8bs=; b=gkdGZn0EKtKjfT7ze2nSh608bquQRlzoDQmpvfPJuSYTR1nGuTfIatD6jMUChRysid GFC4mRg8RE+T6SqazcHQGWua3rCo8KMCW7Wm0TG6d+ErAjpZRDj1NZLhW4Lzd92UQIfo RTpdxwg/lMY7yEWNl/7KSqItkzNjVh44EnLwqfD0zV7OiBsTCUz8+VNybJVFaHy7Mzi7 zZKOoOhdWiw6dArctk2V/zOkXKZjUjogtdH9yjyOUlw0hmntYCcVpyRqM/bxwhe7veoa SVMxuXEG0R2NZNLk9dl2mgFDmbjy1wb8OXbnf4+iZ07tRlGXvsMjz4RPbEUUVsvIK8Jp vX5A== MIME-Version: 1.0 Received: by 10.14.201.73 with SMTP id a49mr21102040eeo.39.1349170005745; Tue, 02 Oct 2012 02:26:45 -0700 (PDT) Received: by 10.14.215.195 with HTTP; Tue, 2 Oct 2012 02:26:45 -0700 (PDT) In-Reply-To: <20121001164239.GE8912@reaktio.net> References: <20121001164239.GE8912@reaktio.net> Date: Tue, 2 Oct 2012 10:26:45 +0100 X-Google-Sender-Auth: YLnU01PlbjDMzRMVjbd45F2Uz0s Message-ID: From: George Dunlap To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.3 development update X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, Oct 1, 2012 at 5:42 PM, Pasi K=E4rkk=E4inen wrote: > On Mon, Oct 01, 2012 at 05:25:43PM +0100, George Dunlap wrote: >> >> * xl USB pass-through for PV guests >> owner: ? >> status: ? >> - Port the xend PV pass-through functionality to xl. >> - Make sure qemu-based USB with qemu-upstream works >> - Upstream the Linux frontend/backend drivers >> > > I think this should be split into two separate tasks: That does make sense. I've updated my notes accordingly. Just to verify: xm/xend *already* supports both PVUSB and passthrough via Q= EMU? -George > > * xl PVUSB pass-through for both PV and HVM guests > owner: ? > status: ? > - xm/xend supports PVUSB pass-through to guests with PVUSB drivers (bo= th PV and HVM guests). > - port the xm/xend functionality to xl. > - this PVUSB feature does not require support or emulation from Qemu. > - upstream the Linux frontend/backend drivers. Current work-in-progres= s versions are in Konrad's git tree. > - James Harper's GPLPV drivers for Windows include PVUSB frontend driv= ers. > > * xl USB pass-through for HVM guests using Qemu USB emulation > owner: ? > status: ? > - xm/xend with qemu-traditional supports USB passthrough to HVM guests= using the Qemu emulated USB controller. > - port the xm/xend functionality to xl. > - make sure USB passthrough with xl works with both qemu-traditional a= nd qemu-upstream. > - The HVM guest does not need any special drivers for this feature. > > > -- Pasi > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 09:27:03 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 09:27:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIyka-00036V-Gx; Tue, 02 Oct 2012 09:26:48 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIykZ-00036P-Eb for xen-devel@lists.xen.org; Tue, 02 Oct 2012 09:26:47 +0000 Received: from [85.158.139.211:36624] by server-9.bemta-5.messagelabs.com id BD/AE-14846-653BA605; Tue, 02 Oct 2012 09:26:46 +0000 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-13.tower-206.messagelabs.com!1349170005!16754960!1 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9677 invoked from network); 2 Oct 2012 09:26:46 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 09:26:46 -0000 Received: by eekb47 with SMTP id b47so3021915eek.32 for ; Tue, 02 Oct 2012 02:26:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=6v4Ryb+E3NvUAbHGTNlkjWH+VNj01IpY1wcVN2oN8bs=; b=gkdGZn0EKtKjfT7ze2nSh608bquQRlzoDQmpvfPJuSYTR1nGuTfIatD6jMUChRysid GFC4mRg8RE+T6SqazcHQGWua3rCo8KMCW7Wm0TG6d+ErAjpZRDj1NZLhW4Lzd92UQIfo RTpdxwg/lMY7yEWNl/7KSqItkzNjVh44EnLwqfD0zV7OiBsTCUz8+VNybJVFaHy7Mzi7 zZKOoOhdWiw6dArctk2V/zOkXKZjUjogtdH9yjyOUlw0hmntYCcVpyRqM/bxwhe7veoa SVMxuXEG0R2NZNLk9dl2mgFDmbjy1wb8OXbnf4+iZ07tRlGXvsMjz4RPbEUUVsvIK8Jp vX5A== MIME-Version: 1.0 Received: by 10.14.201.73 with SMTP id a49mr21102040eeo.39.1349170005745; Tue, 02 Oct 2012 02:26:45 -0700 (PDT) Received: by 10.14.215.195 with HTTP; Tue, 2 Oct 2012 02:26:45 -0700 (PDT) In-Reply-To: <20121001164239.GE8912@reaktio.net> References: <20121001164239.GE8912@reaktio.net> Date: Tue, 2 Oct 2012 10:26:45 +0100 X-Google-Sender-Auth: YLnU01PlbjDMzRMVjbd45F2Uz0s Message-ID: From: George Dunlap To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.3 development update X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, Oct 1, 2012 at 5:42 PM, Pasi K=E4rkk=E4inen wrote: > On Mon, Oct 01, 2012 at 05:25:43PM +0100, George Dunlap wrote: >> >> * xl USB pass-through for PV guests >> owner: ? >> status: ? >> - Port the xend PV pass-through functionality to xl. >> - Make sure qemu-based USB with qemu-upstream works >> - Upstream the Linux frontend/backend drivers >> > > I think this should be split into two separate tasks: That does make sense. I've updated my notes accordingly. Just to verify: xm/xend *already* supports both PVUSB and passthrough via Q= EMU? -George > > * xl PVUSB pass-through for both PV and HVM guests > owner: ? > status: ? > - xm/xend supports PVUSB pass-through to guests with PVUSB drivers (bo= th PV and HVM guests). > - port the xm/xend functionality to xl. > - this PVUSB feature does not require support or emulation from Qemu. > - upstream the Linux frontend/backend drivers. Current work-in-progres= s versions are in Konrad's git tree. > - James Harper's GPLPV drivers for Windows include PVUSB frontend driv= ers. > > * xl USB pass-through for HVM guests using Qemu USB emulation > owner: ? > status: ? > - xm/xend with qemu-traditional supports USB passthrough to HVM guests= using the Qemu emulated USB controller. > - port the xm/xend functionality to xl. > - make sure USB passthrough with xl works with both qemu-traditional a= nd qemu-upstream. > - The HVM guest does not need any special drivers for this feature. > > > -- Pasi > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 09:29:42 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 09:29:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIynB-0003FQ-2v; Tue, 02 Oct 2012 09:29:29 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIynA-0003F5-3X for xen-devel@lists.xen.org; Tue, 02 Oct 2012 09:29:28 +0000 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-16.tower-27.messagelabs.com!1349170161!11721702!1 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19697 invoked from network); 2 Oct 2012 09:29:21 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 09:29:21 -0000 Received: by eekb47 with SMTP id b47so3024121eek.32 for ; Tue, 02 Oct 2012 02:29:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=hvJYCUy0t5R6KWz0CEcjLcWmAa2b1lQPCxmr1SZ4s3o=; b=NJ8MFniB1K3qURpGizo69Pa6Wqhu+W4iNqb0P7YNv0QWDn1PidP9J+cFbEkXi+y+Qn CXdhtcpccS4LLHp2SgEN+G40XSYfC4rB2wAygerjWqM6d8k/h4Mq3XJFlHp79+sjd14z h+9zchl4YTm7YQy/aiq3ajACIYAh9GK4XmKk6M5+Sq/Xjzbvh94ePYS8T37xWYMwQ2dN J20k31btSgTxvElsVyO4jPhIXbyN9QcoznTQ5L1f6rCj7IEvJ163B0zTMMuEpG9nSus7 +iEnXarsPOiJyQKF3h+LgVOoPfOVneBG1hV09VAvmE+JtnV0UGN+o71d6bjYbtBAD8mY tv+g== MIME-Version: 1.0 Received: by 10.14.201.73 with SMTP id a49mr21109654eeo.39.1349170161184; Tue, 02 Oct 2012 02:29:21 -0700 (PDT) Received: by 10.14.215.195 with HTTP; Tue, 2 Oct 2012 02:29:21 -0700 (PDT) In-Reply-To: References: Date: Tue, 2 Oct 2012 10:29:21 +0100 X-Google-Sender-Auth: csfTrSfDD_60vT-7RxMBqSoLIJk Message-ID: From: George Dunlap To: xen-devel@lists.xen.org, Mukesh Rathor Subject: Re: [Xen-devel] Xen 4.3 development update X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, Oct 1, 2012 at 5:25 PM, George Dunlap wrote: > * PVH mode, domU (w/ Linux) > owner: mukesh@oracle > status: ? > > * PVH mode, dom0 (w/ Linux) > owner: mukesh@oracle > status: ? Mukesh, have the xen-side patches been posted yet? Any ETA on those? Thanks, -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 09:29:42 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 09:29:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIynB-0003FQ-2v; Tue, 02 Oct 2012 09:29:29 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIynA-0003F5-3X for xen-devel@lists.xen.org; Tue, 02 Oct 2012 09:29:28 +0000 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-16.tower-27.messagelabs.com!1349170161!11721702!1 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19697 invoked from network); 2 Oct 2012 09:29:21 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 09:29:21 -0000 Received: by eekb47 with SMTP id b47so3024121eek.32 for ; Tue, 02 Oct 2012 02:29:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=hvJYCUy0t5R6KWz0CEcjLcWmAa2b1lQPCxmr1SZ4s3o=; b=NJ8MFniB1K3qURpGizo69Pa6Wqhu+W4iNqb0P7YNv0QWDn1PidP9J+cFbEkXi+y+Qn CXdhtcpccS4LLHp2SgEN+G40XSYfC4rB2wAygerjWqM6d8k/h4Mq3XJFlHp79+sjd14z h+9zchl4YTm7YQy/aiq3ajACIYAh9GK4XmKk6M5+Sq/Xjzbvh94ePYS8T37xWYMwQ2dN J20k31btSgTxvElsVyO4jPhIXbyN9QcoznTQ5L1f6rCj7IEvJ163B0zTMMuEpG9nSus7 +iEnXarsPOiJyQKF3h+LgVOoPfOVneBG1hV09VAvmE+JtnV0UGN+o71d6bjYbtBAD8mY tv+g== MIME-Version: 1.0 Received: by 10.14.201.73 with SMTP id a49mr21109654eeo.39.1349170161184; Tue, 02 Oct 2012 02:29:21 -0700 (PDT) Received: by 10.14.215.195 with HTTP; Tue, 2 Oct 2012 02:29:21 -0700 (PDT) In-Reply-To: References: Date: Tue, 2 Oct 2012 10:29:21 +0100 X-Google-Sender-Auth: csfTrSfDD_60vT-7RxMBqSoLIJk Message-ID: From: George Dunlap To: xen-devel@lists.xen.org, Mukesh Rathor Subject: Re: [Xen-devel] Xen 4.3 development update X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, Oct 1, 2012 at 5:25 PM, George Dunlap wrote: > * PVH mode, domU (w/ Linux) > owner: mukesh@oracle > status: ? > > * PVH mode, dom0 (w/ Linux) > owner: mukesh@oracle > status: ? Mukesh, have the xen-side patches been posted yet? Any ETA on those? Thanks, -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 09:35:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 09:35:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIyt3-0003VI-1s; Tue, 02 Oct 2012 09:35:33 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIyt1-0003VD-JX for Xen-devel@lists.xensource.com; Tue, 02 Oct 2012 09:35:31 +0000 Received: from [85.158.138.51:5089] by server-6.bemta-3.messagelabs.com id 0C/AF-11085-265BA605; Tue, 02 Oct 2012 09:35:30 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1349170529!23874549!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI2OTQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1861 invoked from network); 2 Oct 2012 09:35:30 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 09:35:30 -0000 X-IronPort-AV: E=Sophos;i="4.80,522,1344211200"; d="scan'208";a="14887444" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 09:35:29 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 10:35:29 +0100 Message-ID: <1349170528.650.18.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Mukesh Rathor Date: Tue, 2 Oct 2012 10:35:28 +0100 In-Reply-To: <20121001142826.1ebf7b0f@mantra.us.oracle.com> References: <20120921121202.3163c379@mantra.us.oracle.com> <1348581263.11229.21.camel@zakaz.uk.xensource.com> <20121001142826.1ebf7b0f@mantra.us.oracle.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 0/8]: PVH (PV guest with extensions) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, 2012-10-01 at 22:28 +0100, Mukesh Rathor wrote: > On Tue, 25 Sep 2012 14:54:23 +0100 > Ian Campbell wrote: > > > On Fri, 2012-09-21 at 20:12 +0100, Mukesh Rathor wrote: > > > Hi guys, > > > > > > Ok, I've made all the changes from prev RFC patch submission. > > > > Did I miss the patch with the changes to arch/x86/xen/xen-head.S which > > declare the features which are used here as supported by the kernel > > image? > > > > Ian. > > > > Strange, adding following to head.S > > ELFNOTE(Xen, XEN_ELFNOTE_PADDR_OFFSET, _ASM_PTR 0) > ELFNOTE(Xen, XEN_ELFNOTE_GUEST_PVH, .long 1) <-------- > > and xenstore won't start in dom0. What gives? I have no idea, I can't think of any way that xenstored would be able to even see the notes given in the dom0 kernel image. Are you sure you only that one exact change? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 09:35:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 09:35:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIyt3-0003VI-1s; Tue, 02 Oct 2012 09:35:33 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIyt1-0003VD-JX for Xen-devel@lists.xensource.com; Tue, 02 Oct 2012 09:35:31 +0000 Received: from [85.158.138.51:5089] by server-6.bemta-3.messagelabs.com id 0C/AF-11085-265BA605; Tue, 02 Oct 2012 09:35:30 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1349170529!23874549!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI2OTQ=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1861 invoked from network); 2 Oct 2012 09:35:30 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 09:35:30 -0000 X-IronPort-AV: E=Sophos;i="4.80,522,1344211200"; d="scan'208";a="14887444" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 09:35:29 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 10:35:29 +0100 Message-ID: <1349170528.650.18.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Mukesh Rathor Date: Tue, 2 Oct 2012 10:35:28 +0100 In-Reply-To: <20121001142826.1ebf7b0f@mantra.us.oracle.com> References: <20120921121202.3163c379@mantra.us.oracle.com> <1348581263.11229.21.camel@zakaz.uk.xensource.com> <20121001142826.1ebf7b0f@mantra.us.oracle.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 0/8]: PVH (PV guest with extensions) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, 2012-10-01 at 22:28 +0100, Mukesh Rathor wrote: > On Tue, 25 Sep 2012 14:54:23 +0100 > Ian Campbell wrote: > > > On Fri, 2012-09-21 at 20:12 +0100, Mukesh Rathor wrote: > > > Hi guys, > > > > > > Ok, I've made all the changes from prev RFC patch submission. > > > > Did I miss the patch with the changes to arch/x86/xen/xen-head.S which > > declare the features which are used here as supported by the kernel > > image? > > > > Ian. > > > > Strange, adding following to head.S > > ELFNOTE(Xen, XEN_ELFNOTE_PADDR_OFFSET, _ASM_PTR 0) > ELFNOTE(Xen, XEN_ELFNOTE_GUEST_PVH, .long 1) <-------- > > and xenstore won't start in dom0. What gives? I have no idea, I can't think of any way that xenstored would be able to even see the notes given in the dom0 kernel image. Are you sure you only that one exact change? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 09:36:15 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 09:36:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIytQ-0003Wy-F5; Tue, 02 Oct 2012 09:35:56 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIytP-0003Wn-FQ for xen-devel@lists.xen.org; Tue, 02 Oct 2012 09:35:55 +0000 Received: from [85.158.138.51:35569] by server-1.bemta-3.messagelabs.com id 18/43-16425-A75BA605; Tue, 02 Oct 2012 09:35:54 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1349170550!32701575!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10690 invoked from network); 2 Oct 2012 09:35:50 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-2.tower-174.messagelabs.com with SMTP; 2 Oct 2012 09:35:50 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 02 Oct 2012 10:35:50 +0100 Message-Id: <506AD193020000780009EFC9@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Tue, 02 Oct 2012 10:35:47 +0100 From: "Jan Beulich" To: "George Dunlap" References: In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.3 development update X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 01.10.12 at 18:25, George Dunlap wrote: > * CPUID-based idle (don't rely on ACPI info f/ dom0) > owner: jan@suse > status: done, to be submitted Committed and hence done. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 09:36:15 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 09:36:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIytQ-0003Wy-F5; Tue, 02 Oct 2012 09:35:56 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIytP-0003Wn-FQ for xen-devel@lists.xen.org; Tue, 02 Oct 2012 09:35:55 +0000 Received: from [85.158.138.51:35569] by server-1.bemta-3.messagelabs.com id 18/43-16425-A75BA605; Tue, 02 Oct 2012 09:35:54 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1349170550!32701575!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10690 invoked from network); 2 Oct 2012 09:35:50 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-2.tower-174.messagelabs.com with SMTP; 2 Oct 2012 09:35:50 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 02 Oct 2012 10:35:50 +0100 Message-Id: <506AD193020000780009EFC9@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Tue, 02 Oct 2012 10:35:47 +0100 From: "Jan Beulich" To: "George Dunlap" References: In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.3 development update X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 01.10.12 at 18:25, George Dunlap wrote: > * CPUID-based idle (don't rely on ACPI info f/ dom0) > owner: jan@suse > status: done, to be submitted Committed and hence done. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 09:43:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 09:43:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIz00-0003mi-FR; Tue, 02 Oct 2012 09:42:44 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIyzy-0003md-Jm for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 09:42:42 +0000 Received: from [85.158.139.211:52699] by server-3.bemta-5.messagelabs.com id 34/94-16108-117BA605; Tue, 02 Oct 2012 09:42:41 +0000 X-Env-Sender: fantonifabio@tiscali.it X-Msg-Ref: server-16.tower-206.messagelabs.com!1349170960!20770597!1 X-Originating-IP: [94.23.245.208] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 411 invoked from network); 2 Oct 2012 09:42:40 -0000 Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208) by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 09:42:40 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by lnx3.fantu.it (Postfix) with ESMTP id 6E5FE4008FE for ; Tue, 2 Oct 2012 11:42:40 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it Received: from lnx3.fantu.it ([127.0.0.1]) by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAm+hAB2Q-8g for ; Tue, 2 Oct 2012 11:42:40 +0200 (CEST) Received: from [192.168.178.50] (host51-78-dynamic.2-87-r.retail.telecomitalia.it [87.2.78.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: prova@fantu.it) by lnx3.fantu.it (Postfix) with ESMTPSA id B51E0400267 for ; Tue, 2 Oct 2012 11:42:39 +0200 (CEST) Message-ID: <506AB70D.90908@tiscali.it> Date: Tue, 02 Oct 2012 11:42:37 +0200 From: Fabio Fantoni User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: xen-devel Subject: [Xen-devel] Unable to install Precise domU PV on xen 4.2.0 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: fantonifabio@tiscali.it List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5092653344589177987==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Questo è un messaggio firmato digitalmente in formato MIME. --===============5092653344589177987== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060408000105060802020703" Questo è un messaggio firmato digitalmente in formato MIME. --------------ms060408000105060802020703 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable Dom0 is wheezy 64 bit, kernel 3.2.23-1 from debian repository, xen 4.2.0 = compiled from source When I try to install Precise domU PV with this xl configuration file: -------------------------------------------- PRECISE.cfg ---------------- name=3D'PRECISE' memory=3D1024 vcpus=3D2 disk=3D['/mnt/vm/disks/PRECISE.disk1.xm,raw,xvda1,rw',=20 '/mnt/vm/disks/PRECISE.disk2.xm,raw,xvda2,rw'] #disk=3D['/mnt/vm/disks/PRECISE.disk1.xm,raw,xvda,rw'] vif=3D['bridge=3Dxenbr0'] vfb=3D['vnc=3D1,vncunused=3D1,vnclisten=3D0.0.0.0,keymap=3Dit'] xen_platform_pci=3D1 #bootloader=3D'pygrub' #kernel =3D "/usr/lib/xen/boot/pv-grub-x86_64.gz" #extra =3D "(hd0,0)/grub/grub.cfg" # Only for installation kernel=3D"/boot/domu/precise/vmlinuz" ramdisk=3D"/boot/domu/precise/initrd.gz" extra =3D "debian-installer/exit/always_halt=3Dtrue -- quiet console=3Dhv= c0" -------------------------------------------- The vmlinux and initrd take from here: http://archive.ubuntu.com/ubuntu/dists/precise-updates/main/installer-amd= 64/current/images/netboot/xen/ xl create /etc/xen/PRECISE.cfg Parsing config from /etc/xen/PRECISE.cfg libxl: error: libxl_device.c:858:device_backend_callback: unable to=20 disconnect device with path /local/domain/0/backend/vbd/2/51713 libxl: error: libxl_device.c:858:device_backend_callback: unable to=20 disconnect device with path /local/domain/0/backend/vbd/2/51714 libxl: error: libxl_create.c:933:domcreate_launch_dm: unable to add disk = devices libxl: error: libxl_device.c:858:device_backend_callback: unable to=20 disconnect device with path /local/domain/0/backend/vbd/2/51713 libxl: error: libxl_blktap2.c:73:libxl__device_destroy_tapdisk: Unable=20 to find type aio disk /mnt/vm/disks/PRECISE.disk1.xm: No such file or=20 directory libxl: error: libxl_device.c:858:device_backend_callback: unable to=20 disconnect device with path /local/domain/0/backend/vbd/2/51714 libxl: error: libxl.c:1465:devices_destroy_cb: libxl__devices_destroy=20 failed for 2 /mnt/vm/disks/PRECISE.disk1.xm exist, domU hvm with raw disks works Is xen bug, kernel bug or my error? Thanks for any reply --------------ms060408000105060802020703 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: Firma crittografica S/MIME MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi 8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y 2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT +HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC 0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV 10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2 YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8 h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1 kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8 oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+ qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1 XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTEyMTAwMjA5NDIzN1owIwYJKoZIhvcNAQkEMRYEFB9fWFVFUE7I/430qKKnJCcU ObSzMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEACSMJqoPL/JitzRa/MRIEQBze Ug2glT8H/XBrkJNS/WYuNbAbUY4gSu+2h7LPIuECiNbXvKHS1X7ox4POBvO54IfGgpXMqrUc ozR9ghdtU58Ud3eCjU/DIkodW7SPVYsxUkJ3OnvWo4yEp5isl6nQmCiVM0mtZAXb+3IoyglS DMyDbXtVUSwAAgQHtBji5n2rpu2JFmJn9wvM14Oietv1NcSYY0YXxu6y+oFfGQevP8g3EfZ9 3sMtHPE5Wd6wJuig2xKtF8mlmOddaNH8R1eixllcfm5aI6LXPFaIgiFGb/fY11tMChlOigHG nda6dnv038eFB+BUZjxo/ICIGI8emQAAAAAAAA== --------------ms060408000105060802020703-- --===============5092653344589177987== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============5092653344589177987==-- From xen-devel-bounces@lists.xen.org Tue Oct 02 09:43:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 09:43:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIz00-0003mi-FR; Tue, 02 Oct 2012 09:42:44 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIyzy-0003md-Jm for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 09:42:42 +0000 Received: from [85.158.139.211:52699] by server-3.bemta-5.messagelabs.com id 34/94-16108-117BA605; Tue, 02 Oct 2012 09:42:41 +0000 X-Env-Sender: fantonifabio@tiscali.it X-Msg-Ref: server-16.tower-206.messagelabs.com!1349170960!20770597!1 X-Originating-IP: [94.23.245.208] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 411 invoked from network); 2 Oct 2012 09:42:40 -0000 Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208) by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 09:42:40 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by lnx3.fantu.it (Postfix) with ESMTP id 6E5FE4008FE for ; Tue, 2 Oct 2012 11:42:40 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it Received: from lnx3.fantu.it ([127.0.0.1]) by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAm+hAB2Q-8g for ; Tue, 2 Oct 2012 11:42:40 +0200 (CEST) Received: from [192.168.178.50] (host51-78-dynamic.2-87-r.retail.telecomitalia.it [87.2.78.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: prova@fantu.it) by lnx3.fantu.it (Postfix) with ESMTPSA id B51E0400267 for ; Tue, 2 Oct 2012 11:42:39 +0200 (CEST) Message-ID: <506AB70D.90908@tiscali.it> Date: Tue, 02 Oct 2012 11:42:37 +0200 From: Fabio Fantoni User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: xen-devel Subject: [Xen-devel] Unable to install Precise domU PV on xen 4.2.0 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: fantonifabio@tiscali.it List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5092653344589177987==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Questo è un messaggio firmato digitalmente in formato MIME. --===============5092653344589177987== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060408000105060802020703" Questo è un messaggio firmato digitalmente in formato MIME. --------------ms060408000105060802020703 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable Dom0 is wheezy 64 bit, kernel 3.2.23-1 from debian repository, xen 4.2.0 = compiled from source When I try to install Precise domU PV with this xl configuration file: -------------------------------------------- PRECISE.cfg ---------------- name=3D'PRECISE' memory=3D1024 vcpus=3D2 disk=3D['/mnt/vm/disks/PRECISE.disk1.xm,raw,xvda1,rw',=20 '/mnt/vm/disks/PRECISE.disk2.xm,raw,xvda2,rw'] #disk=3D['/mnt/vm/disks/PRECISE.disk1.xm,raw,xvda,rw'] vif=3D['bridge=3Dxenbr0'] vfb=3D['vnc=3D1,vncunused=3D1,vnclisten=3D0.0.0.0,keymap=3Dit'] xen_platform_pci=3D1 #bootloader=3D'pygrub' #kernel =3D "/usr/lib/xen/boot/pv-grub-x86_64.gz" #extra =3D "(hd0,0)/grub/grub.cfg" # Only for installation kernel=3D"/boot/domu/precise/vmlinuz" ramdisk=3D"/boot/domu/precise/initrd.gz" extra =3D "debian-installer/exit/always_halt=3Dtrue -- quiet console=3Dhv= c0" -------------------------------------------- The vmlinux and initrd take from here: http://archive.ubuntu.com/ubuntu/dists/precise-updates/main/installer-amd= 64/current/images/netboot/xen/ xl create /etc/xen/PRECISE.cfg Parsing config from /etc/xen/PRECISE.cfg libxl: error: libxl_device.c:858:device_backend_callback: unable to=20 disconnect device with path /local/domain/0/backend/vbd/2/51713 libxl: error: libxl_device.c:858:device_backend_callback: unable to=20 disconnect device with path /local/domain/0/backend/vbd/2/51714 libxl: error: libxl_create.c:933:domcreate_launch_dm: unable to add disk = devices libxl: error: libxl_device.c:858:device_backend_callback: unable to=20 disconnect device with path /local/domain/0/backend/vbd/2/51713 libxl: error: libxl_blktap2.c:73:libxl__device_destroy_tapdisk: Unable=20 to find type aio disk /mnt/vm/disks/PRECISE.disk1.xm: No such file or=20 directory libxl: error: libxl_device.c:858:device_backend_callback: unable to=20 disconnect device with path /local/domain/0/backend/vbd/2/51714 libxl: error: libxl.c:1465:devices_destroy_cb: libxl__devices_destroy=20 failed for 2 /mnt/vm/disks/PRECISE.disk1.xm exist, domU hvm with raw disks works Is xen bug, kernel bug or my error? Thanks for any reply --------------ms060408000105060802020703 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: Firma crittografica S/MIME MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi 8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y 2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT +HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC 0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV 10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2 YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8 h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1 kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8 oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+ qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1 XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTEyMTAwMjA5NDIzN1owIwYJKoZIhvcNAQkEMRYEFB9fWFVFUE7I/430qKKnJCcU ObSzMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEACSMJqoPL/JitzRa/MRIEQBze Ug2glT8H/XBrkJNS/WYuNbAbUY4gSu+2h7LPIuECiNbXvKHS1X7ox4POBvO54IfGgpXMqrUc ozR9ghdtU58Ud3eCjU/DIkodW7SPVYsxUkJ3OnvWo4yEp5isl6nQmCiVM0mtZAXb+3IoyglS DMyDbXtVUSwAAgQHtBji5n2rpu2JFmJn9wvM14Oietv1NcSYY0YXxu6y+oFfGQevP8g3EfZ9 3sMtHPE5Wd6wJuig2xKtF8mlmOddaNH8R1eixllcfm5aI6LXPFaIgiFGb/fY11tMChlOigHG nda6dnv038eFB+BUZjxo/ICIGI8emQAAAAAAAA== --------------ms060408000105060802020703-- --===============5092653344589177987== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============5092653344589177987==-- From xen-devel-bounces@lists.xen.org Tue Oct 02 09:43:39 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 09:43:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIz0f-0003pS-Tc; Tue, 02 Oct 2012 09:43:25 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIz0d-0003pG-VV for xen-devel@lists.xen.org; Tue, 02 Oct 2012 09:43:24 +0000 Received: from [85.158.138.51:55824] by server-10.bemta-3.messagelabs.com id 29/C2-02525-B37BA605; Tue, 02 Oct 2012 09:43:23 +0000 X-Env-Sender: lukas@laukamp.me X-Msg-Ref: server-15.tower-174.messagelabs.com!1349171002!30974189!1 X-Originating-IP: [5.9.218.245] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29398 invoked from network); 2 Oct 2012 09:43:22 -0000 Received: from mailer0.lippux.de (HELO mailer0.lippux.de) (5.9.218.245) by server-15.tower-174.messagelabs.com with SMTP; 2 Oct 2012 09:43:22 -0000 Received: from localhost (localhost [127.0.0.1]) by mailer0.lippux.de (Postfix) with ESMTP id C029B423D31; Tue, 2 Oct 2012 11:43:21 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mailer0.lippux.de Received: from mailer0.lippux.de ([127.0.0.1]) by localhost (mailer0.lippux.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uylNMuFF70Fs; Tue, 2 Oct 2012 11:43:21 +0200 (CEST) Received: from ashlynn.lippux.de (unknown [5.9.218.242]) (Authenticated sender: lukas@laukamp.me) by mailer0.lippux.de (Postfix) with ESMTPSA id 77B31423D25; Tue, 2 Oct 2012 11:43:21 +0200 (CEST) Message-ID: <506AB739.6030705@laukamp.me> Date: Tue, 02 Oct 2012 11:43:21 +0200 From: Lukas Laukamp User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Teo En Ming (Zhang Enming)" References: <506AAF6D.4060409@gmail.com> In-Reply-To: <506AAF6D.4060409@gmail.com> Cc: "xen-users@lists.xen.org" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [Xen-users] Xen 4.2.0 does not have the file passthrough.c X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Am 02.10.2012 11:10, schrieb Teo En Ming (Zhang Enming): > Hi, > > Xen 4.2.0 official tarball does not have the file passthrough.c. > > Does it mean that Xen 4.2.0 does not support vga passthrough? > Hey, Xen 4.2.0 should be able to do VGA and PCI passtrough. You should see information about the possibility of this in the xm dmesg/xl dmesg output. I backported the Xen 4.2.0 from Debian experimental to squeeze and it have this feature. Best Regards _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 09:43:39 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 09:43:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIz0f-0003pS-Tc; Tue, 02 Oct 2012 09:43:25 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIz0d-0003pG-VV for xen-devel@lists.xen.org; Tue, 02 Oct 2012 09:43:24 +0000 Received: from [85.158.138.51:55824] by server-10.bemta-3.messagelabs.com id 29/C2-02525-B37BA605; Tue, 02 Oct 2012 09:43:23 +0000 X-Env-Sender: lukas@laukamp.me X-Msg-Ref: server-15.tower-174.messagelabs.com!1349171002!30974189!1 X-Originating-IP: [5.9.218.245] X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29398 invoked from network); 2 Oct 2012 09:43:22 -0000 Received: from mailer0.lippux.de (HELO mailer0.lippux.de) (5.9.218.245) by server-15.tower-174.messagelabs.com with SMTP; 2 Oct 2012 09:43:22 -0000 Received: from localhost (localhost [127.0.0.1]) by mailer0.lippux.de (Postfix) with ESMTP id C029B423D31; Tue, 2 Oct 2012 11:43:21 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mailer0.lippux.de Received: from mailer0.lippux.de ([127.0.0.1]) by localhost (mailer0.lippux.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uylNMuFF70Fs; Tue, 2 Oct 2012 11:43:21 +0200 (CEST) Received: from ashlynn.lippux.de (unknown [5.9.218.242]) (Authenticated sender: lukas@laukamp.me) by mailer0.lippux.de (Postfix) with ESMTPSA id 77B31423D25; Tue, 2 Oct 2012 11:43:21 +0200 (CEST) Message-ID: <506AB739.6030705@laukamp.me> Date: Tue, 02 Oct 2012 11:43:21 +0200 From: Lukas Laukamp User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Teo En Ming (Zhang Enming)" References: <506AAF6D.4060409@gmail.com> In-Reply-To: <506AAF6D.4060409@gmail.com> Cc: "xen-users@lists.xen.org" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [Xen-users] Xen 4.2.0 does not have the file passthrough.c X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Am 02.10.2012 11:10, schrieb Teo En Ming (Zhang Enming): > Hi, > > Xen 4.2.0 official tarball does not have the file passthrough.c. > > Does it mean that Xen 4.2.0 does not support vga passthrough? > Hey, Xen 4.2.0 should be able to do VGA and PCI passtrough. You should see information about the possibility of this in the xm dmesg/xl dmesg output. I backported the Xen 4.2.0 from Debian experimental to squeeze and it have this feature. Best Regards _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 09:47:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 09:47:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIz4T-00045P-RV; Tue, 02 Oct 2012 09:47:21 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIz4R-000458-Qq for xen-devel@lists.xen.org; Tue, 02 Oct 2012 09:47:20 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1349171233!13111687!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15506 invoked from network); 2 Oct 2012 09:47:13 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 09:47:13 -0000 X-IronPort-AV: E=Sophos;i="4.80,522,1344211200"; d="scan'208";a="14887762" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 09:47:13 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 10:47:12 +0100 Message-ID: <1349171231.650.25.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Tim Deegan Date: Tue, 2 Oct 2012 10:47:11 +0100 In-Reply-To: <20121002091017.GA95926@ocelot.phlegethon.org> References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> <20121002091017.GA95926@ocelot.phlegethon.org> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: Dan Magenheimer , "Keir \(Xen.org\)" , Konrad Wilk , George Dunlap , Kurt Hackel , Ian Jackson , Olaf Hering , "xen-devel@lists.xen.org" , George Shuklin , Dario Faggioli , Andres Lagar-Cavilla Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-10-02 at 10:10 +0100, Tim Deegan wrote: > At 13:03 -0700 on 01 Oct (1349096617), Dan Magenheimer wrote: > > Bearing in mind that I know almost nothing about xl or > > the tools layer, and that, as a result, I tend to look > > for hypervisor solutions, I'm thinking it's not possible to > > solve this without direct participation of the hypervisor anyway, > > at least while ensuring the solution will successfully > > work with any memory technology that involves ballooning > > with the possibility of overcommit (i.e. tmem, page sharing > > and host-swapping, manual ballooning, PoD)... EVEN if the > > toolset is single threaded (i.e. only one domain may > > be created at a time, such as xapi). [1] > > TTBOMK, Xapi actually _has_ solved this problem, even with ballooning > and PoD. I don't know if they have any plans to support sharing, > swapping or tmem, though. > > Adding a 'reservation' of free pages that may only be allocated by a > given domain should be straightforward enough, but I'm not sure it helps > much. In the 'balloon-to-fit' model where all memory is already > allocated to some domain (or tmem), some part of the toolstack needs to > sort out freeing up the memory before allocating it to another VM. > Surely that component needs to handle the exclusion too - otherwise a > series of small VM creations could stall a large one indefinitely. xl today has a big lock around domain creation, which solves the original issue which Dan describes but has the issue which you describe. IIRC Dario was going to be looking at adding something to (one or more of) xen, libxl and xl to allow this to be handled more cleverly as part of the NUMA work in 4.3. I think that the intention was still that there would be a critical section within all of the colluding xl instances where memory was set aside for a particular domain, possibly with hypervisor assistance. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 09:47:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 09:47:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIz4T-00045P-RV; Tue, 02 Oct 2012 09:47:21 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIz4R-000458-Qq for xen-devel@lists.xen.org; Tue, 02 Oct 2012 09:47:20 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1349171233!13111687!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15506 invoked from network); 2 Oct 2012 09:47:13 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 09:47:13 -0000 X-IronPort-AV: E=Sophos;i="4.80,522,1344211200"; d="scan'208";a="14887762" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 09:47:13 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 10:47:12 +0100 Message-ID: <1349171231.650.25.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Tim Deegan Date: Tue, 2 Oct 2012 10:47:11 +0100 In-Reply-To: <20121002091017.GA95926@ocelot.phlegethon.org> References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> <20121002091017.GA95926@ocelot.phlegethon.org> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: Dan Magenheimer , "Keir \(Xen.org\)" , Konrad Wilk , George Dunlap , Kurt Hackel , Ian Jackson , Olaf Hering , "xen-devel@lists.xen.org" , George Shuklin , Dario Faggioli , Andres Lagar-Cavilla Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-10-02 at 10:10 +0100, Tim Deegan wrote: > At 13:03 -0700 on 01 Oct (1349096617), Dan Magenheimer wrote: > > Bearing in mind that I know almost nothing about xl or > > the tools layer, and that, as a result, I tend to look > > for hypervisor solutions, I'm thinking it's not possible to > > solve this without direct participation of the hypervisor anyway, > > at least while ensuring the solution will successfully > > work with any memory technology that involves ballooning > > with the possibility of overcommit (i.e. tmem, page sharing > > and host-swapping, manual ballooning, PoD)... EVEN if the > > toolset is single threaded (i.e. only one domain may > > be created at a time, such as xapi). [1] > > TTBOMK, Xapi actually _has_ solved this problem, even with ballooning > and PoD. I don't know if they have any plans to support sharing, > swapping or tmem, though. > > Adding a 'reservation' of free pages that may only be allocated by a > given domain should be straightforward enough, but I'm not sure it helps > much. In the 'balloon-to-fit' model where all memory is already > allocated to some domain (or tmem), some part of the toolstack needs to > sort out freeing up the memory before allocating it to another VM. > Surely that component needs to handle the exclusion too - otherwise a > series of small VM creations could stall a large one indefinitely. xl today has a big lock around domain creation, which solves the original issue which Dan describes but has the issue which you describe. IIRC Dario was going to be looking at adding something to (one or more of) xen, libxl and xl to allow this to be handled more cleverly as part of the NUMA work in 4.3. I think that the intention was still that there would be a critical section within all of the colluding xl instances where memory was set aside for a particular domain, possibly with hypervisor assistance. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 09:59:15 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 09:59:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIzFl-0004IC-3C; Tue, 02 Oct 2012 09:59:01 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIzFj-0004I7-U9 for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 09:59:00 +0000 Received: from [85.158.139.83:56491] by server-2.bemta-5.messagelabs.com id FC/1D-28944-2EABA605; Tue, 02 Oct 2012 09:58:58 +0000 X-Env-Sender: lukas@laukamp.me X-Msg-Ref: server-14.tower-182.messagelabs.com!1349171937!28742885!1 X-Originating-IP: [5.9.218.245] X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_30_40,HTML_MESSAGE, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13607 invoked from network); 2 Oct 2012 09:58:57 -0000 Received: from mailer0.lippux.de (HELO mailer0.lippux.de) (5.9.218.245) by server-14.tower-182.messagelabs.com with SMTP; 2 Oct 2012 09:58:57 -0000 Received: from localhost (localhost [127.0.0.1]) by mailer0.lippux.de (Postfix) with ESMTP id 2D8AA423D38; Tue, 2 Oct 2012 11:58:57 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mailer0.lippux.de Received: from mailer0.lippux.de ([127.0.0.1]) by localhost (mailer0.lippux.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2woptm-jExZ; Tue, 2 Oct 2012 11:58:56 +0200 (CEST) Received: from ashlynn.lippux.de (unknown [5.9.218.242]) (Authenticated sender: lukas@laukamp.me) by mailer0.lippux.de (Postfix) with ESMTPSA id A9BB6423D2F; Tue, 2 Oct 2012 11:58:56 +0200 (CEST) Message-ID: <506ABADC.5090400@laukamp.me> Date: Tue, 02 Oct 2012 11:58:52 +0200 From: Lukas Laukamp User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: fantonifabio@tiscali.it References: <506AB70D.90908@tiscali.it> In-Reply-To: <506AB70D.90908@tiscali.it> Cc: xen-devel Subject: Re: [Xen-devel] Unable to install Precise domU PV on xen 4.2.0 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============9203524640479730267==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a multi-part message in MIME format. --===============9203524640479730267== Content-Type: multipart/alternative; boundary="------------040509030604050005020801" This is a multi-part message in MIME format. --------------040509030604050005020801 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Am 02.10.2012 11:42, schrieb Fabio Fantoni: > Dom0 is wheezy 64 bit, kernel 3.2.23-1 from debian repository, xen > 4.2.0 compiled from source > > When I try to install Precise domU PV with this xl configuration file: > -------------------------------------------- > PRECISE.cfg > ---------------- > name='PRECISE' > memory=1024 > vcpus=2 > disk=['/mnt/vm/disks/PRECISE.disk1.xm,raw,xvda1,rw', > '/mnt/vm/disks/PRECISE.disk2.xm,raw,xvda2,rw'] > #disk=['/mnt/vm/disks/PRECISE.disk1.xm,raw,xvda,rw'] > vif=['bridge=xenbr0'] > vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it'] > xen_platform_pci=1 > #bootloader='pygrub' > #kernel = "/usr/lib/xen/boot/pv-grub-x86_64.gz" > #extra = "(hd0,0)/grub/grub.cfg" > # Only for installation > kernel="/boot/domu/precise/vmlinuz" > ramdisk="/boot/domu/precise/initrd.gz" > extra = "debian-installer/exit/always_halt=true -- quiet console=hvc0" > -------------------------------------------- > > The vmlinux and initrd take from here: > http://archive.ubuntu.com/ubuntu/dists/precise-updates/main/installer-amd64/current/images/netboot/xen/ > > > xl create /etc/xen/PRECISE.cfg > Parsing config from /etc/xen/PRECISE.cfg > libxl: error: libxl_device.c:858:device_backend_callback: unable to > disconnect device with path /local/domain/0/backend/vbd/2/51713 > libxl: error: libxl_device.c:858:device_backend_callback: unable to > disconnect device with path /local/domain/0/backend/vbd/2/51714 > libxl: error: libxl_create.c:933:domcreate_launch_dm: unable to add > disk devices > libxl: error: libxl_device.c:858:device_backend_callback: unable to > disconnect device with path /local/domain/0/backend/vbd/2/51713 > libxl: error: libxl_blktap2.c:73:libxl__device_destroy_tapdisk: Unable > to find type aio disk /mnt/vm/disks/PRECISE.disk1.xm: No such file or > directory > libxl: error: libxl_device.c:858:device_backend_callback: unable to > disconnect device with path /local/domain/0/backend/vbd/2/51714 > libxl: error: libxl.c:1465:devices_destroy_cb: libxl__devices_destroy > failed for 2 > > /mnt/vm/disks/PRECISE.disk1.xm exist, domU hvm with raw disks works > > Is xen bug, kernel bug or my error? > Thanks for any reply > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel Hello, I think that the raw parameter isn't needed and is the reason for the device connecting error. Another way to install the guest would be to use debootstrap. This definitly works. Best Regards --------------040509030604050005020801 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Am 02.10.2012 11:42, schrieb Fabio Fantoni:
Dom0 is wheezy 64 bit, kernel 3.2.23-1 from debian repository, xen 4.2.0 compiled from source

When I try to install Precise domU PV with this xl configuration file:
--------------------------------------------
PRECISE.cfg
----------------
name='PRECISE'
memory=1024
vcpus=2
disk=['/mnt/vm/disks/PRECISE.disk1.xm,raw,xvda1,rw', '/mnt/vm/disks/PRECISE.disk2.xm,raw,xvda2,rw']
#disk=['/mnt/vm/disks/PRECISE.disk1.xm,raw,xvda,rw']
vif=['bridge=xenbr0']
vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it']
xen_platform_pci=1
#bootloader='pygrub'
#kernel = "/usr/lib/xen/boot/pv-grub-x86_64.gz"
#extra = "(hd0,0)/grub/grub.cfg"
# Only for installation
kernel="/boot/domu/precise/vmlinuz"
ramdisk="/boot/domu/precise/initrd.gz"
extra = "debian-installer/exit/always_halt=true -- quiet console=hvc0"
--------------------------------------------

The vmlinux and initrd take from here:
http://archive.ubuntu.com/ubuntu/dists/precise-updates/main/installer-amd64/current/images/netboot/xen/

xl create /etc/xen/PRECISE.cfg
Parsing config from /etc/xen/PRECISE.cfg
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vbd/2/51713
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vbd/2/51714
libxl: error: libxl_create.c:933:domcreate_launch_dm: unable to add disk devices
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vbd/2/51713
libxl: error: libxl_blktap2.c:73:libxl__device_destroy_tapdisk: Unable to find type aio disk /mnt/vm/disks/PRECISE.disk1.xm: No such file or directory
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vbd/2/51714
libxl: error: libxl.c:1465:devices_destroy_cb: libxl__devices_destroy failed for 2

/mnt/vm/disks/PRECISE.disk1.xm exist, domU hvm with raw disks works

Is xen bug, kernel bug or my error?
Thanks for any reply 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Hello,

I think that the raw parameter isn't needed and is the reason for the device connecting error. Another way to install the guest would be to use debootstrap. This definitly works.

Best Regards
--------------040509030604050005020801-- --===============9203524640479730267== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============9203524640479730267==-- From xen-devel-bounces@lists.xen.org Tue Oct 02 09:59:15 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 09:59:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIzFl-0004IC-3C; Tue, 02 Oct 2012 09:59:01 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIzFj-0004I7-U9 for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 09:59:00 +0000 Received: from [85.158.139.83:56491] by server-2.bemta-5.messagelabs.com id FC/1D-28944-2EABA605; Tue, 02 Oct 2012 09:58:58 +0000 X-Env-Sender: lukas@laukamp.me X-Msg-Ref: server-14.tower-182.messagelabs.com!1349171937!28742885!1 X-Originating-IP: [5.9.218.245] X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_30_40,HTML_MESSAGE, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13607 invoked from network); 2 Oct 2012 09:58:57 -0000 Received: from mailer0.lippux.de (HELO mailer0.lippux.de) (5.9.218.245) by server-14.tower-182.messagelabs.com with SMTP; 2 Oct 2012 09:58:57 -0000 Received: from localhost (localhost [127.0.0.1]) by mailer0.lippux.de (Postfix) with ESMTP id 2D8AA423D38; Tue, 2 Oct 2012 11:58:57 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mailer0.lippux.de Received: from mailer0.lippux.de ([127.0.0.1]) by localhost (mailer0.lippux.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2woptm-jExZ; Tue, 2 Oct 2012 11:58:56 +0200 (CEST) Received: from ashlynn.lippux.de (unknown [5.9.218.242]) (Authenticated sender: lukas@laukamp.me) by mailer0.lippux.de (Postfix) with ESMTPSA id A9BB6423D2F; Tue, 2 Oct 2012 11:58:56 +0200 (CEST) Message-ID: <506ABADC.5090400@laukamp.me> Date: Tue, 02 Oct 2012 11:58:52 +0200 From: Lukas Laukamp User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: fantonifabio@tiscali.it References: <506AB70D.90908@tiscali.it> In-Reply-To: <506AB70D.90908@tiscali.it> Cc: xen-devel Subject: Re: [Xen-devel] Unable to install Precise domU PV on xen 4.2.0 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============9203524640479730267==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a multi-part message in MIME format. --===============9203524640479730267== Content-Type: multipart/alternative; boundary="------------040509030604050005020801" This is a multi-part message in MIME format. --------------040509030604050005020801 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Am 02.10.2012 11:42, schrieb Fabio Fantoni: > Dom0 is wheezy 64 bit, kernel 3.2.23-1 from debian repository, xen > 4.2.0 compiled from source > > When I try to install Precise domU PV with this xl configuration file: > -------------------------------------------- > PRECISE.cfg > ---------------- > name='PRECISE' > memory=1024 > vcpus=2 > disk=['/mnt/vm/disks/PRECISE.disk1.xm,raw,xvda1,rw', > '/mnt/vm/disks/PRECISE.disk2.xm,raw,xvda2,rw'] > #disk=['/mnt/vm/disks/PRECISE.disk1.xm,raw,xvda,rw'] > vif=['bridge=xenbr0'] > vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it'] > xen_platform_pci=1 > #bootloader='pygrub' > #kernel = "/usr/lib/xen/boot/pv-grub-x86_64.gz" > #extra = "(hd0,0)/grub/grub.cfg" > # Only for installation > kernel="/boot/domu/precise/vmlinuz" > ramdisk="/boot/domu/precise/initrd.gz" > extra = "debian-installer/exit/always_halt=true -- quiet console=hvc0" > -------------------------------------------- > > The vmlinux and initrd take from here: > http://archive.ubuntu.com/ubuntu/dists/precise-updates/main/installer-amd64/current/images/netboot/xen/ > > > xl create /etc/xen/PRECISE.cfg > Parsing config from /etc/xen/PRECISE.cfg > libxl: error: libxl_device.c:858:device_backend_callback: unable to > disconnect device with path /local/domain/0/backend/vbd/2/51713 > libxl: error: libxl_device.c:858:device_backend_callback: unable to > disconnect device with path /local/domain/0/backend/vbd/2/51714 > libxl: error: libxl_create.c:933:domcreate_launch_dm: unable to add > disk devices > libxl: error: libxl_device.c:858:device_backend_callback: unable to > disconnect device with path /local/domain/0/backend/vbd/2/51713 > libxl: error: libxl_blktap2.c:73:libxl__device_destroy_tapdisk: Unable > to find type aio disk /mnt/vm/disks/PRECISE.disk1.xm: No such file or > directory > libxl: error: libxl_device.c:858:device_backend_callback: unable to > disconnect device with path /local/domain/0/backend/vbd/2/51714 > libxl: error: libxl.c:1465:devices_destroy_cb: libxl__devices_destroy > failed for 2 > > /mnt/vm/disks/PRECISE.disk1.xm exist, domU hvm with raw disks works > > Is xen bug, kernel bug or my error? > Thanks for any reply > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel Hello, I think that the raw parameter isn't needed and is the reason for the device connecting error. Another way to install the guest would be to use debootstrap. This definitly works. Best Regards --------------040509030604050005020801 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Am 02.10.2012 11:42, schrieb Fabio Fantoni:
Dom0 is wheezy 64 bit, kernel 3.2.23-1 from debian repository, xen 4.2.0 compiled from source

When I try to install Precise domU PV with this xl configuration file:
--------------------------------------------
PRECISE.cfg
----------------
name='PRECISE'
memory=1024
vcpus=2
disk=['/mnt/vm/disks/PRECISE.disk1.xm,raw,xvda1,rw', '/mnt/vm/disks/PRECISE.disk2.xm,raw,xvda2,rw']
#disk=['/mnt/vm/disks/PRECISE.disk1.xm,raw,xvda,rw']
vif=['bridge=xenbr0']
vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it']
xen_platform_pci=1
#bootloader='pygrub'
#kernel = "/usr/lib/xen/boot/pv-grub-x86_64.gz"
#extra = "(hd0,0)/grub/grub.cfg"
# Only for installation
kernel="/boot/domu/precise/vmlinuz"
ramdisk="/boot/domu/precise/initrd.gz"
extra = "debian-installer/exit/always_halt=true -- quiet console=hvc0"
--------------------------------------------

The vmlinux and initrd take from here:
http://archive.ubuntu.com/ubuntu/dists/precise-updates/main/installer-amd64/current/images/netboot/xen/

xl create /etc/xen/PRECISE.cfg
Parsing config from /etc/xen/PRECISE.cfg
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vbd/2/51713
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vbd/2/51714
libxl: error: libxl_create.c:933:domcreate_launch_dm: unable to add disk devices
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vbd/2/51713
libxl: error: libxl_blktap2.c:73:libxl__device_destroy_tapdisk: Unable to find type aio disk /mnt/vm/disks/PRECISE.disk1.xm: No such file or directory
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vbd/2/51714
libxl: error: libxl.c:1465:devices_destroy_cb: libxl__devices_destroy failed for 2

/mnt/vm/disks/PRECISE.disk1.xm exist, domU hvm with raw disks works

Is xen bug, kernel bug or my error?
Thanks for any reply 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Hello,

I think that the raw parameter isn't needed and is the reason for the device connecting error. Another way to install the guest would be to use debootstrap. This definitly works.

Best Regards
--------------040509030604050005020801-- --===============9203524640479730267== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============9203524640479730267==-- From xen-devel-bounces@lists.xen.org Tue Oct 02 10:06:48 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 10:06:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIzN4-0004Z6-5v; Tue, 02 Oct 2012 10:06:34 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIzN2-0004Z1-BZ for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 10:06:32 +0000 Received: from [85.158.137.99:15895] by server-15.bemta-3.messagelabs.com id 06/F7-18313-7ACBA605; Tue, 02 Oct 2012 10:06:31 +0000 X-Env-Sender: fantonifabio@tiscali.it X-Msg-Ref: server-12.tower-217.messagelabs.com!1349172390!16809430!1 X-Originating-IP: [94.23.245.208] X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_40_50,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17102 invoked from network); 2 Oct 2012 10:06:30 -0000 Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208) by server-12.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 10:06:30 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by lnx3.fantu.it (Postfix) with ESMTP id 1D26A400375; Tue, 2 Oct 2012 12:06:30 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it Received: from lnx3.fantu.it ([127.0.0.1]) by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTXvoNIMoLbR; Tue, 2 Oct 2012 12:06:29 +0200 (CEST) Received: from [192.168.178.50] (host51-78-dynamic.2-87-r.retail.telecomitalia.it [87.2.78.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: prova@fantu.it) by lnx3.fantu.it (Postfix) with ESMTPSA id D183E400251; Tue, 2 Oct 2012 12:06:28 +0200 (CEST) Message-ID: <506ABCA1.5010602@tiscali.it> Date: Tue, 02 Oct 2012 12:06:25 +0200 From: Fabio Fantoni User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Lukas Laukamp References: <506AB70D.90908@tiscali.it> <506ABADC.5090400@laukamp.me> In-Reply-To: <506ABADC.5090400@laukamp.me> Cc: xen-devel Subject: Re: [Xen-devel] Unable to install Precise domU PV on xen 4.2.0 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: fantonifabio@tiscali.it List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7438487063850488406==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Questo è un messaggio firmato digitalmente in formato MIME. --===============7438487063850488406== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080802070200040006090104" Questo è un messaggio firmato digitalmente in formato MIME. --------------ms080802070200040006090104 Content-Type: multipart/alternative; boundary="------------070607060606030600010704" This is a multi-part message in MIME format. --------------070607060606030600010704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Il 02/10/2012 11:58, Lukas Laukamp ha scritto: > Am 02.10.2012 11:42, schrieb Fabio Fantoni: >> Dom0 is wheezy 64 bit, kernel 3.2.23-1 from debian repository, xen=20 >> 4.2.0 compiled from source >> >> When I try to install Precise domU PV with this xl configuration file:= >> -------------------------------------------- >> PRECISE.cfg >> ---------------- >> name=3D'PRECISE' >> memory=3D1024 >> vcpus=3D2 >> disk=3D['/mnt/vm/disks/PRECISE.disk1.xm,raw,xvda1,rw',=20 >> '/mnt/vm/disks/PRECISE.disk2.xm,raw,xvda2,rw'] >> #disk=3D['/mnt/vm/disks/PRECISE.disk1.xm,raw,xvda,rw'] >> vif=3D['bridge=3Dxenbr0'] >> vfb=3D['vnc=3D1,vncunused=3D1,vnclisten=3D0.0.0.0,keymap=3Dit'] >> xen_platform_pci=3D1 >> #bootloader=3D'pygrub' >> #kernel =3D "/usr/lib/xen/boot/pv-grub-x86_64.gz" >> #extra =3D "(hd0,0)/grub/grub.cfg" >> # Only for installation >> kernel=3D"/boot/domu/precise/vmlinuz" >> ramdisk=3D"/boot/domu/precise/initrd.gz" >> extra =3D "debian-installer/exit/always_halt=3Dtrue -- quiet console=3D= hvc0" >> -------------------------------------------- >> >> The vmlinux and initrd take from here: >> http://archive.ubuntu.com/ubuntu/dists/precise-updates/main/installer-= amd64/current/images/netboot/xen/=20 >> >> >> xl create /etc/xen/PRECISE.cfg >> Parsing config from /etc/xen/PRECISE.cfg >> libxl: error: libxl_device.c:858:device_backend_callback: unable to=20 >> disconnect device with path /local/domain/0/backend/vbd/2/51713 >> libxl: error: libxl_device.c:858:device_backend_callback: unable to=20 >> disconnect device with path /local/domain/0/backend/vbd/2/51714 >> libxl: error: libxl_create.c:933:domcreate_launch_dm: unable to add=20 >> disk devices >> libxl: error: libxl_device.c:858:device_backend_callback: unable to=20 >> disconnect device with path /local/domain/0/backend/vbd/2/51713 >> libxl: error: libxl_blktap2.c:73:libxl__device_destroy_tapdisk:=20 >> Unable to find type aio disk /mnt/vm/disks/PRECISE.disk1.xm: No such=20 >> file or directory >> libxl: error: libxl_device.c:858:device_backend_callback: unable to=20 >> disconnect device with path /local/domain/0/backend/vbd/2/51714 >> libxl: error: libxl.c:1465:devices_destroy_cb: libxl__devices_destroy = >> failed for 2 >> >> /mnt/vm/disks/PRECISE.disk1.xm exist, domU hvm with raw disks works >> >> Is xen bug, kernel bug or my error? >> Thanks for any reply >> >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel > > Hello, > > I think that the raw parameter isn't needed and is the reason for the=20 > device connecting error. Another way to install the guest would be to=20 > use debootstrap. This definitly works. > > Best Regards > > Nessun virus nel messaggio. > Controllato da AVG - www.avg.com > Versione: 2012.0.2221 / Database dei virus: 2441/5303 - Data di=20 > rilascio: 01/10/2012 > Format seem necessary or give this error: /etc/xen/PRECISE.cfg: config parsing error in disk specification:=20 unknown value for format: near `xvda1' in=20 `/mnt/vm/disks/PRECISE.disk1.xm,xvda1,rw' --------------070607060606030600010704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Il 02/10/2012 11:58, Lukas Laukamp ha scritto:
Am 02.10.2012 11:42, schrieb Fabio Fantoni:
Do= m0 is wheezy 64 bit, kernel 3.2.23-1 from debian repository, xen 4.2.0 compiled from source

When I try to install Precise domU PV with this xl configuration file:
--------------------------------------------
PRECISE.cfg
----------------
name=3D'PRECISE'
memory=3D1024
vcpus=3D2
disk=3D['/mnt/vm/disks/PRECISE.disk1.xm,raw,xvda1,rw', '/mnt/vm/disks/PRECISE.disk2.xm,raw,xvda2,rw']
#disk=3D['/mnt/vm/disks/PRECISE.disk1.xm,raw,xvda,rw']
vif=3D['bridge=3Dxenbr0']
vfb=3D['vnc=3D1,vncunused=3D1,vnclisten=3D0.0.0.0,keymap=3Dit'] <= br> xen_platform_pci=3D1
#bootloader=3D'pygrub'
#kernel =3D "/usr/lib/xen/boot/pv-grub-x86_64.gz"
#extra =3D "(hd0,0)/grub/grub.cfg"
# Only for installation
kernel=3D"/boot/domu/precise/vmlinuz"
ramdisk=3D"/boot/domu/precise/initrd.gz"
extra =3D "debian-installer/exit/always_halt=3Dtrue -- quiet console=3Dhvc0"
--------------------------------------------

The vmlinux and initrd take from here:
http://archive.ubuntu.com/ubuntu/= dists/precise-updates/main/installer-amd64/current/images/netboot/xen/

xl create /etc/xen/PRECISE.cfg
Parsing config from /etc/xen/PRECISE.cfg
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vbd/2/51713
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vbd/2/51714
libxl: error: libxl_create.c:933:domcreate_launch_dm: unable to add disk devices
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vbd/2/51713
libxl: error: libxl_blktap2.c:73:libxl__device_destroy_tapdisk: Unable to find type aio disk /mnt/vm/disks/PRECISE.disk1.xm: No such file or directory
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vbd/2/51714
libxl: error: libxl.c:1465:devices_destroy_cb: libxl__devices_destroy failed for 2

/mnt/vm/disks/PRECISE.disk1.xm exist, domU hvm with raw disks works

Is xen bug, kernel bug or my error?
Thanks for any reply 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Hello,

I think that the raw parameter isn't needed and is the reason for the device connecting error. Another way to install the guest would be to use debootstrap. This definitly works.

Best Regards

Nessu= n virus nel messaggio.
Controllato da AVG - www.avg.com
Versione: 2012.0.2221 / Database dei virus: 2441/5303 - Data di rilascio: 01/10/2012

Format seem necessary or give this error:
/etc/xen/PRECISE.cfg: config parsing error in disk specification: unknown value for format: near `xvda1' in `/mnt/vm/disks/PRECISE.disk1.xm,xvda1,rw'
--------------070607060606030600010704-- --------------ms080802070200040006090104 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: Firma crittografica S/MIME MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi 8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y 2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT +HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC 0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV 10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2 YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8 h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1 kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8 oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+ qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1 XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTEyMTAwMjEwMDYyNVowIwYJKoZIhvcNAQkEMRYEFO62vT+O+iSmVZUAHggD7/sk vCkNMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAenF2q2wPvQb+hz3+Qe+oTePb EIiOncMdWkRE2X3TtqW0NnFOw8t9frrE0TJllRtsdsQR0C2naDIvTkL9R8fO+E11beKTrwJS 6USxN58ESQ+tCj2priMy7pPplv/WJzwefxtsYmnpFjjZsnz+uTv1trHHPxIu/eD/CSUjeejN rN0r+uEI2/wKxSFFUj+LbjKHAgxV1R4ibUP/n1e930U0bmUMY6BBjUmJUTW6b5DqQ5EsZW2p Uja/FEinakJEd2LbSDNCrLWDOd9ow6jSyl/Bpp0GI3mUNIStMYbZ9wlWz0KyS7TXtGB+LKIP s14AAjNdh/2bj2+pZ5zwbr+Xp2KHugAAAAAAAA== --------------ms080802070200040006090104-- --===============7438487063850488406== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============7438487063850488406==-- From xen-devel-bounces@lists.xen.org Tue Oct 02 10:06:48 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 10:06:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIzN4-0004Z6-5v; Tue, 02 Oct 2012 10:06:34 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIzN2-0004Z1-BZ for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 10:06:32 +0000 Received: from [85.158.137.99:15895] by server-15.bemta-3.messagelabs.com id 06/F7-18313-7ACBA605; Tue, 02 Oct 2012 10:06:31 +0000 X-Env-Sender: fantonifabio@tiscali.it X-Msg-Ref: server-12.tower-217.messagelabs.com!1349172390!16809430!1 X-Originating-IP: [94.23.245.208] X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_40_50,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17102 invoked from network); 2 Oct 2012 10:06:30 -0000 Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208) by server-12.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 10:06:30 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by lnx3.fantu.it (Postfix) with ESMTP id 1D26A400375; Tue, 2 Oct 2012 12:06:30 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it Received: from lnx3.fantu.it ([127.0.0.1]) by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTXvoNIMoLbR; Tue, 2 Oct 2012 12:06:29 +0200 (CEST) Received: from [192.168.178.50] (host51-78-dynamic.2-87-r.retail.telecomitalia.it [87.2.78.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: prova@fantu.it) by lnx3.fantu.it (Postfix) with ESMTPSA id D183E400251; Tue, 2 Oct 2012 12:06:28 +0200 (CEST) Message-ID: <506ABCA1.5010602@tiscali.it> Date: Tue, 02 Oct 2012 12:06:25 +0200 From: Fabio Fantoni User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Lukas Laukamp References: <506AB70D.90908@tiscali.it> <506ABADC.5090400@laukamp.me> In-Reply-To: <506ABADC.5090400@laukamp.me> Cc: xen-devel Subject: Re: [Xen-devel] Unable to install Precise domU PV on xen 4.2.0 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: fantonifabio@tiscali.it List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7438487063850488406==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Questo è un messaggio firmato digitalmente in formato MIME. --===============7438487063850488406== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080802070200040006090104" Questo è un messaggio firmato digitalmente in formato MIME. --------------ms080802070200040006090104 Content-Type: multipart/alternative; boundary="------------070607060606030600010704" This is a multi-part message in MIME format. --------------070607060606030600010704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Il 02/10/2012 11:58, Lukas Laukamp ha scritto: > Am 02.10.2012 11:42, schrieb Fabio Fantoni: >> Dom0 is wheezy 64 bit, kernel 3.2.23-1 from debian repository, xen=20 >> 4.2.0 compiled from source >> >> When I try to install Precise domU PV with this xl configuration file:= >> -------------------------------------------- >> PRECISE.cfg >> ---------------- >> name=3D'PRECISE' >> memory=3D1024 >> vcpus=3D2 >> disk=3D['/mnt/vm/disks/PRECISE.disk1.xm,raw,xvda1,rw',=20 >> '/mnt/vm/disks/PRECISE.disk2.xm,raw,xvda2,rw'] >> #disk=3D['/mnt/vm/disks/PRECISE.disk1.xm,raw,xvda,rw'] >> vif=3D['bridge=3Dxenbr0'] >> vfb=3D['vnc=3D1,vncunused=3D1,vnclisten=3D0.0.0.0,keymap=3Dit'] >> xen_platform_pci=3D1 >> #bootloader=3D'pygrub' >> #kernel =3D "/usr/lib/xen/boot/pv-grub-x86_64.gz" >> #extra =3D "(hd0,0)/grub/grub.cfg" >> # Only for installation >> kernel=3D"/boot/domu/precise/vmlinuz" >> ramdisk=3D"/boot/domu/precise/initrd.gz" >> extra =3D "debian-installer/exit/always_halt=3Dtrue -- quiet console=3D= hvc0" >> -------------------------------------------- >> >> The vmlinux and initrd take from here: >> http://archive.ubuntu.com/ubuntu/dists/precise-updates/main/installer-= amd64/current/images/netboot/xen/=20 >> >> >> xl create /etc/xen/PRECISE.cfg >> Parsing config from /etc/xen/PRECISE.cfg >> libxl: error: libxl_device.c:858:device_backend_callback: unable to=20 >> disconnect device with path /local/domain/0/backend/vbd/2/51713 >> libxl: error: libxl_device.c:858:device_backend_callback: unable to=20 >> disconnect device with path /local/domain/0/backend/vbd/2/51714 >> libxl: error: libxl_create.c:933:domcreate_launch_dm: unable to add=20 >> disk devices >> libxl: error: libxl_device.c:858:device_backend_callback: unable to=20 >> disconnect device with path /local/domain/0/backend/vbd/2/51713 >> libxl: error: libxl_blktap2.c:73:libxl__device_destroy_tapdisk:=20 >> Unable to find type aio disk /mnt/vm/disks/PRECISE.disk1.xm: No such=20 >> file or directory >> libxl: error: libxl_device.c:858:device_backend_callback: unable to=20 >> disconnect device with path /local/domain/0/backend/vbd/2/51714 >> libxl: error: libxl.c:1465:devices_destroy_cb: libxl__devices_destroy = >> failed for 2 >> >> /mnt/vm/disks/PRECISE.disk1.xm exist, domU hvm with raw disks works >> >> Is xen bug, kernel bug or my error? >> Thanks for any reply >> >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel > > Hello, > > I think that the raw parameter isn't needed and is the reason for the=20 > device connecting error. Another way to install the guest would be to=20 > use debootstrap. This definitly works. > > Best Regards > > Nessun virus nel messaggio. > Controllato da AVG - www.avg.com > Versione: 2012.0.2221 / Database dei virus: 2441/5303 - Data di=20 > rilascio: 01/10/2012 > Format seem necessary or give this error: /etc/xen/PRECISE.cfg: config parsing error in disk specification:=20 unknown value for format: near `xvda1' in=20 `/mnt/vm/disks/PRECISE.disk1.xm,xvda1,rw' --------------070607060606030600010704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Il 02/10/2012 11:58, Lukas Laukamp ha scritto:
Am 02.10.2012 11:42, schrieb Fabio Fantoni:
Do= m0 is wheezy 64 bit, kernel 3.2.23-1 from debian repository, xen 4.2.0 compiled from source

When I try to install Precise domU PV with this xl configuration file:
--------------------------------------------
PRECISE.cfg
----------------
name=3D'PRECISE'
memory=3D1024
vcpus=3D2
disk=3D['/mnt/vm/disks/PRECISE.disk1.xm,raw,xvda1,rw', '/mnt/vm/disks/PRECISE.disk2.xm,raw,xvda2,rw']
#disk=3D['/mnt/vm/disks/PRECISE.disk1.xm,raw,xvda,rw']
vif=3D['bridge=3Dxenbr0']
vfb=3D['vnc=3D1,vncunused=3D1,vnclisten=3D0.0.0.0,keymap=3Dit'] <= br> xen_platform_pci=3D1
#bootloader=3D'pygrub'
#kernel =3D "/usr/lib/xen/boot/pv-grub-x86_64.gz"
#extra =3D "(hd0,0)/grub/grub.cfg"
# Only for installation
kernel=3D"/boot/domu/precise/vmlinuz"
ramdisk=3D"/boot/domu/precise/initrd.gz"
extra =3D "debian-installer/exit/always_halt=3Dtrue -- quiet console=3Dhvc0"
--------------------------------------------

The vmlinux and initrd take from here:
http://archive.ubuntu.com/ubuntu/= dists/precise-updates/main/installer-amd64/current/images/netboot/xen/

xl create /etc/xen/PRECISE.cfg
Parsing config from /etc/xen/PRECISE.cfg
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vbd/2/51713
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vbd/2/51714
libxl: error: libxl_create.c:933:domcreate_launch_dm: unable to add disk devices
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vbd/2/51713
libxl: error: libxl_blktap2.c:73:libxl__device_destroy_tapdisk: Unable to find type aio disk /mnt/vm/disks/PRECISE.disk1.xm: No such file or directory
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vbd/2/51714
libxl: error: libxl.c:1465:devices_destroy_cb: libxl__devices_destroy failed for 2

/mnt/vm/disks/PRECISE.disk1.xm exist, domU hvm with raw disks works

Is xen bug, kernel bug or my error?
Thanks for any reply 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Hello,

I think that the raw parameter isn't needed and is the reason for the device connecting error. Another way to install the guest would be to use debootstrap. This definitly works.

Best Regards

Nessu= n virus nel messaggio.
Controllato da AVG - www.avg.com
Versione: 2012.0.2221 / Database dei virus: 2441/5303 - Data di rilascio: 01/10/2012

Format seem necessary or give this error:
/etc/xen/PRECISE.cfg: config parsing error in disk specification: unknown value for format: near `xvda1' in `/mnt/vm/disks/PRECISE.disk1.xm,xvda1,rw'
--------------070607060606030600010704-- --------------ms080802070200040006090104 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: Firma crittografica S/MIME MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi 8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y 2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT +HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC 0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV 10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2 YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8 h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1 kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8 oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+ qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1 XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTEyMTAwMjEwMDYyNVowIwYJKoZIhvcNAQkEMRYEFO62vT+O+iSmVZUAHggD7/sk vCkNMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAenF2q2wPvQb+hz3+Qe+oTePb EIiOncMdWkRE2X3TtqW0NnFOw8t9frrE0TJllRtsdsQR0C2naDIvTkL9R8fO+E11beKTrwJS 6USxN58ESQ+tCj2priMy7pPplv/WJzwefxtsYmnpFjjZsnz+uTv1trHHPxIu/eD/CSUjeejN rN0r+uEI2/wKxSFFUj+LbjKHAgxV1R4ibUP/n1e930U0bmUMY6BBjUmJUTW6b5DqQ5EsZW2p Uja/FEinakJEd2LbSDNCrLWDOd9ow6jSyl/Bpp0GI3mUNIStMYbZ9wlWz0KyS7TXtGB+LKIP s14AAjNdh/2bj2+pZ5zwbr+Xp2KHugAAAAAAAA== --------------ms080802070200040006090104-- --===============7438487063850488406== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============7438487063850488406==-- From xen-devel-bounces@lists.xen.org Tue Oct 02 10:08:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 10:08:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIzOH-0004dJ-MV; Tue, 02 Oct 2012 10:07:49 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIzOG-0004d6-3Z for xen-devel@lists.xen.org; Tue, 02 Oct 2012 10:07:48 +0000 Received: from [85.158.139.83:23789] by server-10.bemta-5.messagelabs.com id E0/27-16911-3FCBA605; Tue, 02 Oct 2012 10:07:47 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-2.tower-182.messagelabs.com!1349172466!30178964!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MjMzMTI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13907 invoked from network); 2 Oct 2012 10:07:46 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 10:07:46 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id 035531C30; Tue, 2 Oct 2012 13:07:45 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 86BC720058; Tue, 2 Oct 2012 13:07:45 +0300 (EEST) Date: Tue, 2 Oct 2012 13:07:45 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: George Dunlap Message-ID: <20121002100745.GJ8912@reaktio.net> References: <20121001164239.GE8912@reaktio.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.3 development update X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, Oct 02, 2012 at 10:26:45AM +0100, George Dunlap wrote: > On Mon, Oct 1, 2012 at 5:42 PM, Pasi K=E4rkk=E4inen wrote: > > On Mon, Oct 01, 2012 at 05:25:43PM +0100, George Dunlap wrote: > >> > >> * xl USB pass-through for PV guests > >> owner: ? > >> status: ? > >> - Port the xend PV pass-through functionality to xl. > >> - Make sure qemu-based USB with qemu-upstream works > >> - Upstream the Linux frontend/backend drivers > >> > > > > I think this should be split into two separate tasks: > = > That does make sense. I've updated my notes accordingly. > = Thanks. > Just to verify: xm/xend *already* supports both PVUSB and passthrough via= QEMU? > Correct! -- Pasi = > -George > = > > > > * xl PVUSB pass-through for both PV and HVM guests > > owner: ? > > status: ? > > - xm/xend supports PVUSB pass-through to guests with PVUSB drivers (= both PV and HVM guests). > > - port the xm/xend functionality to xl. > > - this PVUSB feature does not require support or emulation from Qemu. > > - upstream the Linux frontend/backend drivers. Current work-in-progr= ess versions are in Konrad's git tree. > > - James Harper's GPLPV drivers for Windows include PVUSB frontend dr= ivers. > > > > * xl USB pass-through for HVM guests using Qemu USB emulation > > owner: ? > > status: ? > > - xm/xend with qemu-traditional supports USB passthrough to HVM gues= ts using the Qemu emulated USB controller. > > - port the xm/xend functionality to xl. > > - make sure USB passthrough with xl works with both qemu-traditional= and qemu-upstream. > > - The HVM guest does not need any special drivers for this feature. > > > > > > -- Pasi > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xen.org > > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 10:08:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 10:08:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIzOH-0004dJ-MV; Tue, 02 Oct 2012 10:07:49 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIzOG-0004d6-3Z for xen-devel@lists.xen.org; Tue, 02 Oct 2012 10:07:48 +0000 Received: from [85.158.139.83:23789] by server-10.bemta-5.messagelabs.com id E0/27-16911-3FCBA605; Tue, 02 Oct 2012 10:07:47 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-2.tower-182.messagelabs.com!1349172466!30178964!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MjMzMTI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13907 invoked from network); 2 Oct 2012 10:07:46 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 10:07:46 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id 035531C30; Tue, 2 Oct 2012 13:07:45 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 86BC720058; Tue, 2 Oct 2012 13:07:45 +0300 (EEST) Date: Tue, 2 Oct 2012 13:07:45 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: George Dunlap Message-ID: <20121002100745.GJ8912@reaktio.net> References: <20121001164239.GE8912@reaktio.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.3 development update X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, Oct 02, 2012 at 10:26:45AM +0100, George Dunlap wrote: > On Mon, Oct 1, 2012 at 5:42 PM, Pasi K=E4rkk=E4inen wrote: > > On Mon, Oct 01, 2012 at 05:25:43PM +0100, George Dunlap wrote: > >> > >> * xl USB pass-through for PV guests > >> owner: ? > >> status: ? > >> - Port the xend PV pass-through functionality to xl. > >> - Make sure qemu-based USB with qemu-upstream works > >> - Upstream the Linux frontend/backend drivers > >> > > > > I think this should be split into two separate tasks: > = > That does make sense. I've updated my notes accordingly. > = Thanks. > Just to verify: xm/xend *already* supports both PVUSB and passthrough via= QEMU? > Correct! -- Pasi = > -George > = > > > > * xl PVUSB pass-through for both PV and HVM guests > > owner: ? > > status: ? > > - xm/xend supports PVUSB pass-through to guests with PVUSB drivers (= both PV and HVM guests). > > - port the xm/xend functionality to xl. > > - this PVUSB feature does not require support or emulation from Qemu. > > - upstream the Linux frontend/backend drivers. Current work-in-progr= ess versions are in Konrad's git tree. > > - James Harper's GPLPV drivers for Windows include PVUSB frontend dr= ivers. > > > > * xl USB pass-through for HVM guests using Qemu USB emulation > > owner: ? > > status: ? > > - xm/xend with qemu-traditional supports USB passthrough to HVM gues= ts using the Qemu emulated USB controller. > > - port the xm/xend functionality to xl. > > - make sure USB passthrough with xl works with both qemu-traditional= and qemu-upstream. > > - The HVM guest does not need any special drivers for this feature. > > > > > > -- Pasi > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xen.org > > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 10:20:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 10:20:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIza1-0004r1-VE; Tue, 02 Oct 2012 10:19:57 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIza0-0004qs-7F for xen-devel@lists.xen.org; Tue, 02 Oct 2012 10:19:56 +0000 Received: from [85.158.139.83:58538] by server-5.bemta-5.messagelabs.com id DB/9F-21075-BCFBA605; Tue, 02 Oct 2012 10:19:55 +0000 X-Env-Sender: singapore.mr.teo.en.ming@gmail.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1349173192!28747472!1 X-Originating-IP: [209.85.160.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8912 invoked from network); 2 Oct 2012 10:19:54 -0000 Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com) (209.85.160.45) by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 10:19:54 -0000 Received: by pbbrp2 with SMTP id rp2so8913792pbb.32 for ; Tue, 02 Oct 2012 03:19:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=8oVyQrxiHtV7m1UebBgxW2gebLYyuB4QpT/LiWEOo4E=; b=ll+aWVGlZ03doXT4onxqUrbSBrP14YeOkCunL8moBwFA03lQQ+vn+FqYEGn/jCULJi n9i/s21IFfeUVPPAOaFqlmYQBambR/yMBU9/mrfaawWob3uJAyOe+GqL7TgV8bRv46J1 5QNLO0lcocrsbM2tG9F8FvaNF/cjLw5ZP49/oF+UvJkYSmZaGS2i72bUPxcTCUpfmdQf Yzjs50Zv7yhk5f/2Wcaqfz7/Zkst/wdkyKw4Sol4FvGLWaINSHLcpqJifHnUpMUKTxte jChBFNhTyhaXcSqHeZK95irO1BNOr27LTlqP72du9ft3X2eSHiSJQTk6/uAp9+zWTbaV OCbA== Received: by 10.66.84.229 with SMTP id c5mr14177203paz.76.1349173192490; Tue, 02 Oct 2012 03:19:52 -0700 (PDT) Received: from [192.168.1.2] (cm152.gamma205.maxonline.com.sg. [202.156.205.152]) by mx.google.com with ESMTPS id jv10sm708414pbc.23.2012.10.02.03.19.50 (version=SSLv3 cipher=OTHER); Tue, 02 Oct 2012 03:19:51 -0700 (PDT) Message-ID: <506ABFC5.9050600@gmail.com> Date: Tue, 02 Oct 2012 18:19:49 +0800 From: "Teo En Ming (Zhang Enming)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Lukas Laukamp References: <506AAF6D.4060409@gmail.com> <506AB739.6030705@laukamp.me> In-Reply-To: <506AB739.6030705@laukamp.me> Cc: "xen-users@lists.xen.org" , "Teo En Ming \(Zhang Enming\)" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [Xen-users] Xen 4.2.0 does not have the file passthrough.c X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 02/10/2012 17:43, Lukas Laukamp wrote: > Am 02.10.2012 11:10, schrieb Teo En Ming (Zhang Enming): >> Hi, >> >> Xen 4.2.0 official tarball does not have the file passthrough.c. >> >> Does it mean that Xen 4.2.0 does not support vga passthrough? >> > > Hey, > > Xen 4.2.0 should be able to do VGA and PCI passtrough. You should see > information about the possibility of this in the xm dmesg/xl dmesg > output. I backported the Xen 4.2.0 from Debian experimental to squeeze > and it have this feature. > > Best Regards > Hi, I was trying to patch the file pass-through.c when the patch file complained that pass-through.c cannot be found, meaning that Xen 4.2.0 does not support VGA passthrough. -- Yours sincerely, Mr. Teo En Ming (Zhang Enming) Singapore _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 10:20:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 10:20:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIza1-0004r1-VE; Tue, 02 Oct 2012 10:19:57 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIza0-0004qs-7F for xen-devel@lists.xen.org; Tue, 02 Oct 2012 10:19:56 +0000 Received: from [85.158.139.83:58538] by server-5.bemta-5.messagelabs.com id DB/9F-21075-BCFBA605; Tue, 02 Oct 2012 10:19:55 +0000 X-Env-Sender: singapore.mr.teo.en.ming@gmail.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1349173192!28747472!1 X-Originating-IP: [209.85.160.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8912 invoked from network); 2 Oct 2012 10:19:54 -0000 Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com) (209.85.160.45) by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 10:19:54 -0000 Received: by pbbrp2 with SMTP id rp2so8913792pbb.32 for ; Tue, 02 Oct 2012 03:19:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=8oVyQrxiHtV7m1UebBgxW2gebLYyuB4QpT/LiWEOo4E=; b=ll+aWVGlZ03doXT4onxqUrbSBrP14YeOkCunL8moBwFA03lQQ+vn+FqYEGn/jCULJi n9i/s21IFfeUVPPAOaFqlmYQBambR/yMBU9/mrfaawWob3uJAyOe+GqL7TgV8bRv46J1 5QNLO0lcocrsbM2tG9F8FvaNF/cjLw5ZP49/oF+UvJkYSmZaGS2i72bUPxcTCUpfmdQf Yzjs50Zv7yhk5f/2Wcaqfz7/Zkst/wdkyKw4Sol4FvGLWaINSHLcpqJifHnUpMUKTxte jChBFNhTyhaXcSqHeZK95irO1BNOr27LTlqP72du9ft3X2eSHiSJQTk6/uAp9+zWTbaV OCbA== Received: by 10.66.84.229 with SMTP id c5mr14177203paz.76.1349173192490; Tue, 02 Oct 2012 03:19:52 -0700 (PDT) Received: from [192.168.1.2] (cm152.gamma205.maxonline.com.sg. [202.156.205.152]) by mx.google.com with ESMTPS id jv10sm708414pbc.23.2012.10.02.03.19.50 (version=SSLv3 cipher=OTHER); Tue, 02 Oct 2012 03:19:51 -0700 (PDT) Message-ID: <506ABFC5.9050600@gmail.com> Date: Tue, 02 Oct 2012 18:19:49 +0800 From: "Teo En Ming (Zhang Enming)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Lukas Laukamp References: <506AAF6D.4060409@gmail.com> <506AB739.6030705@laukamp.me> In-Reply-To: <506AB739.6030705@laukamp.me> Cc: "xen-users@lists.xen.org" , "Teo En Ming \(Zhang Enming\)" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [Xen-users] Xen 4.2.0 does not have the file passthrough.c X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 02/10/2012 17:43, Lukas Laukamp wrote: > Am 02.10.2012 11:10, schrieb Teo En Ming (Zhang Enming): >> Hi, >> >> Xen 4.2.0 official tarball does not have the file passthrough.c. >> >> Does it mean that Xen 4.2.0 does not support vga passthrough? >> > > Hey, > > Xen 4.2.0 should be able to do VGA and PCI passtrough. You should see > information about the possibility of this in the xm dmesg/xl dmesg > output. I backported the Xen 4.2.0 from Debian experimental to squeeze > and it have this feature. > > Best Regards > Hi, I was trying to patch the file pass-through.c when the patch file complained that pass-through.c cannot be found, meaning that Xen 4.2.0 does not support VGA passthrough. -- Yours sincerely, Mr. Teo En Ming (Zhang Enming) Singapore _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 10:26:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 10:26:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIzfh-0005J9-NY; Tue, 02 Oct 2012 10:25:49 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIzfg-0005J0-SF for xen-devel@lists.xen.org; Tue, 02 Oct 2012 10:25:49 +0000 Received: from [85.158.139.211:23919] by server-4.bemta-5.messagelabs.com id F7/78-20767-C21CA605; Tue, 02 Oct 2012 10:25:48 +0000 X-Env-Sender: avi@redhat.com X-Msg-Ref: server-3.tower-206.messagelabs.com!1349173546!20726750!1 X-Originating-IP: [209.132.183.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTY4NTA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15381 invoked from network); 2 Oct 2012 10:25:47 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-3.tower-206.messagelabs.com with SMTP; 2 Oct 2012 10:25:47 -0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q92APfwb023666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Oct 2012 06:25:41 -0400 Received: from balrog.usersys.tlv.redhat.com (dhcp-4-121.tlv.redhat.com [10.35.4.121]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q92APZti014242; Tue, 2 Oct 2012 06:25:37 -0400 Message-ID: <506AC11F.1030402@redhat.com> Date: Tue, 02 Oct 2012 12:25:35 +0200 From: Avi Kivity User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: Stefano Stabellini References: <1348744360-2989-1-git-send-email-anthony.perard@citrix.com> <1348744360-2989-5-git-send-email-anthony.perard@citrix.com> In-Reply-To: X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 Cc: Anthony PERARD , QEMU-devel , Xen Devel Subject: Re: [Xen-devel] [PATCH V4 4/5] exec, memory: Call to xen_modified_memory. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 10/01/2012 12:36 PM, Stefano Stabellini wrote: > On Thu, 27 Sep 2012, Anthony PERARD wrote: >> This patch add some calls to xen_modified_memory to notify Xen about dirtybits >> during migration. >> >> Signed-off-by: Anthony PERARD > > If I am not mistaken, this is the last patch that needs reviewing. > Avi, are you OK with it? > > > >> exec.c | 1 + >> memory.c | 2 ++ >> 2 files changed, 3 insertions(+) >> >> diff --git a/exec.c b/exec.c >> index 366684c..1114a09 100644 >> --- a/exec.c >> +++ b/exec.c >> @@ -3427,6 +3427,7 @@ static void invalidate_and_set_dirty(target_phys_addr_t addr, >> /* set dirty bit */ >> cpu_physical_memory_set_dirty_flags(addr, (0xff & ~CODE_DIRTY_FLAG)); >> } >> + xen_modified_memory(addr, length); >> } >> >> void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf, >> diff --git a/memory.c b/memory.c >> index 4f3ade0..015c544 100644 >> --- a/memory.c >> +++ b/memory.c >> @@ -19,6 +19,7 @@ >> #include "bitops.h" >> #include "kvm.h" >> #include >> +#include "hw/xen.h" >> >> #define WANT_EXEC_OBSOLETE >> #include "exec-obsolete.h" >> @@ -1077,6 +1078,7 @@ void memory_region_set_dirty(MemoryRegion *mr, target_phys_addr_t addr, >> target_phys_addr_t size) >> { >> assert(mr->terminates); >> + xen_modified_memory(mr->ram_addr + addr, size); >> return cpu_physical_memory_set_dirty_range(mr->ram_addr + addr, size, -1); >> } I would prefer this bit pushed into cpu_physical_set_dirty_range(). Possibly the first bit too? -- error compiling committee.c: too many arguments to function _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 10:26:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 10:26:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIzfh-0005J9-NY; Tue, 02 Oct 2012 10:25:49 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIzfg-0005J0-SF for xen-devel@lists.xen.org; Tue, 02 Oct 2012 10:25:49 +0000 Received: from [85.158.139.211:23919] by server-4.bemta-5.messagelabs.com id F7/78-20767-C21CA605; Tue, 02 Oct 2012 10:25:48 +0000 X-Env-Sender: avi@redhat.com X-Msg-Ref: server-3.tower-206.messagelabs.com!1349173546!20726750!1 X-Originating-IP: [209.132.183.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTY4NTA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15381 invoked from network); 2 Oct 2012 10:25:47 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-3.tower-206.messagelabs.com with SMTP; 2 Oct 2012 10:25:47 -0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q92APfwb023666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Oct 2012 06:25:41 -0400 Received: from balrog.usersys.tlv.redhat.com (dhcp-4-121.tlv.redhat.com [10.35.4.121]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q92APZti014242; Tue, 2 Oct 2012 06:25:37 -0400 Message-ID: <506AC11F.1030402@redhat.com> Date: Tue, 02 Oct 2012 12:25:35 +0200 From: Avi Kivity User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: Stefano Stabellini References: <1348744360-2989-1-git-send-email-anthony.perard@citrix.com> <1348744360-2989-5-git-send-email-anthony.perard@citrix.com> In-Reply-To: X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 Cc: Anthony PERARD , QEMU-devel , Xen Devel Subject: Re: [Xen-devel] [PATCH V4 4/5] exec, memory: Call to xen_modified_memory. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 10/01/2012 12:36 PM, Stefano Stabellini wrote: > On Thu, 27 Sep 2012, Anthony PERARD wrote: >> This patch add some calls to xen_modified_memory to notify Xen about dirtybits >> during migration. >> >> Signed-off-by: Anthony PERARD > > If I am not mistaken, this is the last patch that needs reviewing. > Avi, are you OK with it? > > > >> exec.c | 1 + >> memory.c | 2 ++ >> 2 files changed, 3 insertions(+) >> >> diff --git a/exec.c b/exec.c >> index 366684c..1114a09 100644 >> --- a/exec.c >> +++ b/exec.c >> @@ -3427,6 +3427,7 @@ static void invalidate_and_set_dirty(target_phys_addr_t addr, >> /* set dirty bit */ >> cpu_physical_memory_set_dirty_flags(addr, (0xff & ~CODE_DIRTY_FLAG)); >> } >> + xen_modified_memory(addr, length); >> } >> >> void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf, >> diff --git a/memory.c b/memory.c >> index 4f3ade0..015c544 100644 >> --- a/memory.c >> +++ b/memory.c >> @@ -19,6 +19,7 @@ >> #include "bitops.h" >> #include "kvm.h" >> #include >> +#include "hw/xen.h" >> >> #define WANT_EXEC_OBSOLETE >> #include "exec-obsolete.h" >> @@ -1077,6 +1078,7 @@ void memory_region_set_dirty(MemoryRegion *mr, target_phys_addr_t addr, >> target_phys_addr_t size) >> { >> assert(mr->terminates); >> + xen_modified_memory(mr->ram_addr + addr, size); >> return cpu_physical_memory_set_dirty_range(mr->ram_addr + addr, size, -1); >> } I would prefer this bit pushed into cpu_physical_set_dirty_range(). Possibly the first bit too? -- error compiling committee.c: too many arguments to function _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 10:35:05 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 10:35:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIzoO-0005bI-VT; Tue, 02 Oct 2012 10:34:48 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIzoN-0005bD-4C for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 10:34:47 +0000 Received: from [85.158.138.51:26421] by server-2.bemta-3.messagelabs.com id 25/E2-16514-643CA605; Tue, 02 Oct 2012 10:34:46 +0000 X-Env-Sender: lukas@laukamp.me X-Msg-Ref: server-10.tower-174.messagelabs.com!1349174085!25159897!1 X-Originating-IP: [5.9.218.245] X-SpamReason: No, hits=0.8 required=7.0 tests=HTML_40_50,HTML_MESSAGE, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23595 invoked from network); 2 Oct 2012 10:34:45 -0000 Received: from mailer0.lippux.de (HELO mailer0.lippux.de) (5.9.218.245) by server-10.tower-174.messagelabs.com with SMTP; 2 Oct 2012 10:34:45 -0000 Received: from localhost (localhost [127.0.0.1]) by mailer0.lippux.de (Postfix) with ESMTP id 9BC5C423D48; Tue, 2 Oct 2012 12:34:44 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mailer0.lippux.de Received: from mailer0.lippux.de ([127.0.0.1]) by localhost (mailer0.lippux.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40tNI6IermZn; Tue, 2 Oct 2012 12:34:44 +0200 (CEST) Received: from ashlynn.lippux.de (unknown [5.9.218.242]) (Authenticated sender: lukas@laukamp.me) by mailer0.lippux.de (Postfix) with ESMTPSA id 10A6A423D49; Tue, 2 Oct 2012 12:34:44 +0200 (CEST) Message-ID: <506AC344.7070704@laukamp.me> Date: Tue, 02 Oct 2012 12:34:44 +0200 From: Lukas Laukamp User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: fantonifabio@tiscali.it References: <506AB70D.90908@tiscali.it> <506ABADC.5090400@laukamp.me> <506ABCA1.5010602@tiscali.it> In-Reply-To: <506ABCA1.5010602@tiscali.it> Cc: xen-devel Subject: Re: [Xen-devel] Unable to install Precise domU PV on xen 4.2.0 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6271200284332621497==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a multi-part message in MIME format. --===============6271200284332621497== Content-Type: multipart/alternative; boundary="------------080009030605040603090600" This is a multi-part message in MIME format. --------------080009030605040603090600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Am 02.10.2012 12:06, schrieb Fabio Fantoni: > Il 02/10/2012 11:58, Lukas Laukamp ha scritto: >> Am 02.10.2012 11:42, schrieb Fabio Fantoni: >>> Dom0 is wheezy 64 bit, kernel 3.2.23-1 from debian repository, xen >>> 4.2.0 compiled from source >>> >>> When I try to install Precise domU PV with this xl configuration file: >>> -------------------------------------------- >>> PRECISE.cfg >>> ---------------- >>> name='PRECISE' >>> memory=1024 >>> vcpus=2 >>> disk=['/mnt/vm/disks/PRECISE.disk1.xm,raw,xvda1,rw', >>> '/mnt/vm/disks/PRECISE.disk2.xm,raw,xvda2,rw'] >>> #disk=['/mnt/vm/disks/PRECISE.disk1.xm,raw,xvda,rw'] >>> vif=['bridge=xenbr0'] >>> vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it'] >>> xen_platform_pci=1 >>> #bootloader='pygrub' >>> #kernel = "/usr/lib/xen/boot/pv-grub-x86_64.gz" >>> #extra = "(hd0,0)/grub/grub.cfg" >>> # Only for installation >>> kernel="/boot/domu/precise/vmlinuz" >>> ramdisk="/boot/domu/precise/initrd.gz" >>> extra = "debian-installer/exit/always_halt=true -- quiet console=hvc0" >>> -------------------------------------------- >>> >>> The vmlinux and initrd take from here: >>> http://archive.ubuntu.com/ubuntu/dists/precise-updates/main/installer-amd64/current/images/netboot/xen/ >>> >>> >>> xl create /etc/xen/PRECISE.cfg >>> Parsing config from /etc/xen/PRECISE.cfg >>> libxl: error: libxl_device.c:858:device_backend_callback: unable to >>> disconnect device with path /local/domain/0/backend/vbd/2/51713 >>> libxl: error: libxl_device.c:858:device_backend_callback: unable to >>> disconnect device with path /local/domain/0/backend/vbd/2/51714 >>> libxl: error: libxl_create.c:933:domcreate_launch_dm: unable to add >>> disk devices >>> libxl: error: libxl_device.c:858:device_backend_callback: unable to >>> disconnect device with path /local/domain/0/backend/vbd/2/51713 >>> libxl: error: libxl_blktap2.c:73:libxl__device_destroy_tapdisk: >>> Unable to find type aio disk /mnt/vm/disks/PRECISE.disk1.xm: No such >>> file or directory >>> libxl: error: libxl_device.c:858:device_backend_callback: unable to >>> disconnect device with path /local/domain/0/backend/vbd/2/51714 >>> libxl: error: libxl.c:1465:devices_destroy_cb: >>> libxl__devices_destroy failed for 2 >>> >>> /mnt/vm/disks/PRECISE.disk1.xm exist, domU hvm with raw disks works >>> >>> Is xen bug, kernel bug or my error? >>> Thanks for any reply >>> >>> >>> >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xen.org >>> http://lists.xen.org/xen-devel >> >> Hello, >> >> I think that the raw parameter isn't needed and is the reason for the >> device connecting error. Another way to install the guest would be to >> use debootstrap. This definitly works. >> >> Best Regards >> >> Nessun virus nel messaggio. >> Controllato da AVG - www.avg.com >> Versione: 2012.0.2221 / Database dei virus: 2441/5303 - Data di >> rilascio: 01/10/2012 >> > Format seem necessary or give this error: > /etc/xen/PRECISE.cfg: config parsing error in disk specification: > unknown value for format: near `xvda1' in > `/mnt/vm/disks/PRECISE.disk1.xm,xvda1,rw' > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel Hello, do you also have tried to install the guest with debootstrap? Best Regards --------------080009030605040603090600 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Am 02.10.2012 12:06, schrieb Fabio Fantoni:
Il 02/10/2012 11:58, Lukas Laukamp ha scritto:
Am 02.10.2012 11:42, schrieb Fabio Fantoni:
Dom0 is wheezy 64 bit, kernel 3.2.23-1 from debian repository, xen 4.2.0 compiled from source

When I try to install Precise domU PV with this xl configuration file:
--------------------------------------------
PRECISE.cfg
----------------
name='PRECISE'
memory=1024
vcpus=2
disk=['/mnt/vm/disks/PRECISE.disk1.xm,raw,xvda1,rw', '/mnt/vm/disks/PRECISE.disk2.xm,raw,xvda2,rw']
#disk=['/mnt/vm/disks/PRECISE.disk1.xm,raw,xvda,rw']
vif=['bridge=xenbr0']
vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it']
xen_platform_pci=1
#bootloader='pygrub'
#kernel = "/usr/lib/xen/boot/pv-grub-x86_64.gz"
#extra = "(hd0,0)/grub/grub.cfg"
# Only for installation
kernel="/boot/domu/precise/vmlinuz"
ramdisk="/boot/domu/precise/initrd.gz"
extra = "debian-installer/exit/always_halt=true -- quiet console=hvc0"
--------------------------------------------

The vmlinux and initrd take from here:
http://archive.ubuntu.com/ubuntu/dists/precise-updates/main/installer-amd64/current/images/netboot/xen/

xl create /etc/xen/PRECISE.cfg
Parsing config from /etc/xen/PRECISE.cfg
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vbd/2/51713
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vbd/2/51714
libxl: error: libxl_create.c:933:domcreate_launch_dm: unable to add disk devices
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vbd/2/51713
libxl: error: libxl_blktap2.c:73:libxl__device_destroy_tapdisk: Unable to find type aio disk /mnt/vm/disks/PRECISE.disk1.xm: No such file or directory
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vbd/2/51714
libxl: error: libxl.c:1465:devices_destroy_cb: libxl__devices_destroy failed for 2

/mnt/vm/disks/PRECISE.disk1.xm exist, domU hvm with raw disks works

Is xen bug, kernel bug or my error?
Thanks for any reply 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Hello,

I think that the raw parameter isn't needed and is the reason for the device connecting error. Another way to install the guest would be to use debootstrap. This definitly works.

Best Regards

Nessun virus nel messaggio.
Controllato da AVG - www.avg.com
Versione: 2012.0.2221 / Database dei virus: 2441/5303 - Data di rilascio: 01/10/2012

Format seem necessary or give this error:
/etc/xen/PRECISE.cfg: config parsing error in disk specification: unknown value for format: near `xvda1' in `/mnt/vm/disks/PRECISE.disk1.xm,xvda1,rw'


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Hello,

do you also have tried to install the guest with debootstrap?

Best Regards
--------------080009030605040603090600-- --===============6271200284332621497== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6271200284332621497==-- From xen-devel-bounces@lists.xen.org Tue Oct 02 10:35:05 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 10:35:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIzoO-0005bI-VT; Tue, 02 Oct 2012 10:34:48 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TIzoN-0005bD-4C for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 10:34:47 +0000 Received: from [85.158.138.51:26421] by server-2.bemta-3.messagelabs.com id 25/E2-16514-643CA605; Tue, 02 Oct 2012 10:34:46 +0000 X-Env-Sender: lukas@laukamp.me X-Msg-Ref: server-10.tower-174.messagelabs.com!1349174085!25159897!1 X-Originating-IP: [5.9.218.245] X-SpamReason: No, hits=0.8 required=7.0 tests=HTML_40_50,HTML_MESSAGE, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23595 invoked from network); 2 Oct 2012 10:34:45 -0000 Received: from mailer0.lippux.de (HELO mailer0.lippux.de) (5.9.218.245) by server-10.tower-174.messagelabs.com with SMTP; 2 Oct 2012 10:34:45 -0000 Received: from localhost (localhost [127.0.0.1]) by mailer0.lippux.de (Postfix) with ESMTP id 9BC5C423D48; Tue, 2 Oct 2012 12:34:44 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mailer0.lippux.de Received: from mailer0.lippux.de ([127.0.0.1]) by localhost (mailer0.lippux.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40tNI6IermZn; Tue, 2 Oct 2012 12:34:44 +0200 (CEST) Received: from ashlynn.lippux.de (unknown [5.9.218.242]) (Authenticated sender: lukas@laukamp.me) by mailer0.lippux.de (Postfix) with ESMTPSA id 10A6A423D49; Tue, 2 Oct 2012 12:34:44 +0200 (CEST) Message-ID: <506AC344.7070704@laukamp.me> Date: Tue, 02 Oct 2012 12:34:44 +0200 From: Lukas Laukamp User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: fantonifabio@tiscali.it References: <506AB70D.90908@tiscali.it> <506ABADC.5090400@laukamp.me> <506ABCA1.5010602@tiscali.it> In-Reply-To: <506ABCA1.5010602@tiscali.it> Cc: xen-devel Subject: Re: [Xen-devel] Unable to install Precise domU PV on xen 4.2.0 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6271200284332621497==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a multi-part message in MIME format. --===============6271200284332621497== Content-Type: multipart/alternative; boundary="------------080009030605040603090600" This is a multi-part message in MIME format. --------------080009030605040603090600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Am 02.10.2012 12:06, schrieb Fabio Fantoni: > Il 02/10/2012 11:58, Lukas Laukamp ha scritto: >> Am 02.10.2012 11:42, schrieb Fabio Fantoni: >>> Dom0 is wheezy 64 bit, kernel 3.2.23-1 from debian repository, xen >>> 4.2.0 compiled from source >>> >>> When I try to install Precise domU PV with this xl configuration file: >>> -------------------------------------------- >>> PRECISE.cfg >>> ---------------- >>> name='PRECISE' >>> memory=1024 >>> vcpus=2 >>> disk=['/mnt/vm/disks/PRECISE.disk1.xm,raw,xvda1,rw', >>> '/mnt/vm/disks/PRECISE.disk2.xm,raw,xvda2,rw'] >>> #disk=['/mnt/vm/disks/PRECISE.disk1.xm,raw,xvda,rw'] >>> vif=['bridge=xenbr0'] >>> vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it'] >>> xen_platform_pci=1 >>> #bootloader='pygrub' >>> #kernel = "/usr/lib/xen/boot/pv-grub-x86_64.gz" >>> #extra = "(hd0,0)/grub/grub.cfg" >>> # Only for installation >>> kernel="/boot/domu/precise/vmlinuz" >>> ramdisk="/boot/domu/precise/initrd.gz" >>> extra = "debian-installer/exit/always_halt=true -- quiet console=hvc0" >>> -------------------------------------------- >>> >>> The vmlinux and initrd take from here: >>> http://archive.ubuntu.com/ubuntu/dists/precise-updates/main/installer-amd64/current/images/netboot/xen/ >>> >>> >>> xl create /etc/xen/PRECISE.cfg >>> Parsing config from /etc/xen/PRECISE.cfg >>> libxl: error: libxl_device.c:858:device_backend_callback: unable to >>> disconnect device with path /local/domain/0/backend/vbd/2/51713 >>> libxl: error: libxl_device.c:858:device_backend_callback: unable to >>> disconnect device with path /local/domain/0/backend/vbd/2/51714 >>> libxl: error: libxl_create.c:933:domcreate_launch_dm: unable to add >>> disk devices >>> libxl: error: libxl_device.c:858:device_backend_callback: unable to >>> disconnect device with path /local/domain/0/backend/vbd/2/51713 >>> libxl: error: libxl_blktap2.c:73:libxl__device_destroy_tapdisk: >>> Unable to find type aio disk /mnt/vm/disks/PRECISE.disk1.xm: No such >>> file or directory >>> libxl: error: libxl_device.c:858:device_backend_callback: unable to >>> disconnect device with path /local/domain/0/backend/vbd/2/51714 >>> libxl: error: libxl.c:1465:devices_destroy_cb: >>> libxl__devices_destroy failed for 2 >>> >>> /mnt/vm/disks/PRECISE.disk1.xm exist, domU hvm with raw disks works >>> >>> Is xen bug, kernel bug or my error? >>> Thanks for any reply >>> >>> >>> >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xen.org >>> http://lists.xen.org/xen-devel >> >> Hello, >> >> I think that the raw parameter isn't needed and is the reason for the >> device connecting error. Another way to install the guest would be to >> use debootstrap. This definitly works. >> >> Best Regards >> >> Nessun virus nel messaggio. >> Controllato da AVG - www.avg.com >> Versione: 2012.0.2221 / Database dei virus: 2441/5303 - Data di >> rilascio: 01/10/2012 >> > Format seem necessary or give this error: > /etc/xen/PRECISE.cfg: config parsing error in disk specification: > unknown value for format: near `xvda1' in > `/mnt/vm/disks/PRECISE.disk1.xm,xvda1,rw' > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel Hello, do you also have tried to install the guest with debootstrap? Best Regards --------------080009030605040603090600 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Am 02.10.2012 12:06, schrieb Fabio Fantoni:
Il 02/10/2012 11:58, Lukas Laukamp ha scritto:
Am 02.10.2012 11:42, schrieb Fabio Fantoni:
Dom0 is wheezy 64 bit, kernel 3.2.23-1 from debian repository, xen 4.2.0 compiled from source

When I try to install Precise domU PV with this xl configuration file:
--------------------------------------------
PRECISE.cfg
----------------
name='PRECISE'
memory=1024
vcpus=2
disk=['/mnt/vm/disks/PRECISE.disk1.xm,raw,xvda1,rw', '/mnt/vm/disks/PRECISE.disk2.xm,raw,xvda2,rw']
#disk=['/mnt/vm/disks/PRECISE.disk1.xm,raw,xvda,rw']
vif=['bridge=xenbr0']
vfb=['vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it']
xen_platform_pci=1
#bootloader='pygrub'
#kernel = "/usr/lib/xen/boot/pv-grub-x86_64.gz"
#extra = "(hd0,0)/grub/grub.cfg"
# Only for installation
kernel="/boot/domu/precise/vmlinuz"
ramdisk="/boot/domu/precise/initrd.gz"
extra = "debian-installer/exit/always_halt=true -- quiet console=hvc0"
--------------------------------------------

The vmlinux and initrd take from here:
http://archive.ubuntu.com/ubuntu/dists/precise-updates/main/installer-amd64/current/images/netboot/xen/

xl create /etc/xen/PRECISE.cfg
Parsing config from /etc/xen/PRECISE.cfg
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vbd/2/51713
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vbd/2/51714
libxl: error: libxl_create.c:933:domcreate_launch_dm: unable to add disk devices
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vbd/2/51713
libxl: error: libxl_blktap2.c:73:libxl__device_destroy_tapdisk: Unable to find type aio disk /mnt/vm/disks/PRECISE.disk1.xm: No such file or directory
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vbd/2/51714
libxl: error: libxl.c:1465:devices_destroy_cb: libxl__devices_destroy failed for 2

/mnt/vm/disks/PRECISE.disk1.xm exist, domU hvm with raw disks works

Is xen bug, kernel bug or my error?
Thanks for any reply 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Hello,

I think that the raw parameter isn't needed and is the reason for the device connecting error. Another way to install the guest would be to use debootstrap. This definitly works.

Best Regards

Nessun virus nel messaggio.
Controllato da AVG - www.avg.com
Versione: 2012.0.2221 / Database dei virus: 2441/5303 - Data di rilascio: 01/10/2012

Format seem necessary or give this error:
/etc/xen/PRECISE.cfg: config parsing error in disk specification: unknown value for format: near `xvda1' in `/mnt/vm/disks/PRECISE.disk1.xm,xvda1,rw'


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Hello,

do you also have tried to install the guest with debootstrap?

Best Regards
--------------080009030605040603090600-- --===============6271200284332621497== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6271200284332621497==-- From xen-devel-bounces@lists.xen.org Tue Oct 02 10:47:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 10:47:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ004-0005lR-7S; Tue, 02 Oct 2012 10:46:52 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ003-0005lM-9y for xen-devel@lists.xen.org; Tue, 02 Oct 2012 10:46:51 +0000 Received: from [85.158.139.83:36872] by server-9.bemta-5.messagelabs.com id 25/26-14846-A16CA605; Tue, 02 Oct 2012 10:46:50 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-10.tower-182.messagelabs.com!1349174809!33314836!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31984 invoked from network); 2 Oct 2012 10:46:49 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 10:46:49 -0000 X-IronPort-AV: E=Sophos;i="4.80,522,1344211200"; d="scan'208";a="14889319" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 10:46:45 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 11:46:45 +0100 Message-ID: <1349174804.650.33.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Ian Jackson Date: Tue, 2 Oct 2012 11:46:44 +0100 In-Reply-To: <20585.51898.562068.647640@mariner.uk.xensource.com> References: <1348500989-18281-1-git-send-email-ian.campbell@citrix.com> <20576.36383.707502.561841@mariner.uk.xensource.com> <20585.51898.562068.647640@mariner.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] docs: initial documentation for xenstore paths X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, 2012-10-01 at 17:54 +0100, Ian Jackson wrote: > Ian Jackson writes ("Re: [Xen-devel] [PATCH] docs: initial documentation for xenstore paths"): > > Ian Campbell writes ("[PATCH] docs: initial documentation for xenstore paths"): > > > This is based upon my inspection of a system with a single PV domain > > > and a single HVM domain running and is therefore very incomplete. > > > > Acked-by: Ian Jackson > > Committed-by: Ian Jackson Thanks, looks like I committed but forgot to push both this and George's sched related cmdline patch before I went on vacation. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 10:47:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 10:47:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ004-0005lR-7S; Tue, 02 Oct 2012 10:46:52 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ003-0005lM-9y for xen-devel@lists.xen.org; Tue, 02 Oct 2012 10:46:51 +0000 Received: from [85.158.139.83:36872] by server-9.bemta-5.messagelabs.com id 25/26-14846-A16CA605; Tue, 02 Oct 2012 10:46:50 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-10.tower-182.messagelabs.com!1349174809!33314836!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31984 invoked from network); 2 Oct 2012 10:46:49 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 10:46:49 -0000 X-IronPort-AV: E=Sophos;i="4.80,522,1344211200"; d="scan'208";a="14889319" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 10:46:45 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 11:46:45 +0100 Message-ID: <1349174804.650.33.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Ian Jackson Date: Tue, 2 Oct 2012 11:46:44 +0100 In-Reply-To: <20585.51898.562068.647640@mariner.uk.xensource.com> References: <1348500989-18281-1-git-send-email-ian.campbell@citrix.com> <20576.36383.707502.561841@mariner.uk.xensource.com> <20585.51898.562068.647640@mariner.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] docs: initial documentation for xenstore paths X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, 2012-10-01 at 17:54 +0100, Ian Jackson wrote: > Ian Jackson writes ("Re: [Xen-devel] [PATCH] docs: initial documentation for xenstore paths"): > > Ian Campbell writes ("[PATCH] docs: initial documentation for xenstore paths"): > > > This is based upon my inspection of a system with a single PV domain > > > and a single HVM domain running and is therefore very incomplete. > > > > Acked-by: Ian Jackson > > Committed-by: Ian Jackson Thanks, looks like I committed but forgot to push both this and George's sched related cmdline patch before I went on vacation. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 10:47:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 10:47:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ00k-0005o1-Kw; Tue, 02 Oct 2012 10:47:34 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ00j-0005nu-U9 for Xen-devel@lists.xensource.com; Tue, 02 Oct 2012 10:47:34 +0000 Received: from [85.158.139.83:42899] by server-15.bemta-5.messagelabs.com id 27/19-19430-546CA605; Tue, 02 Oct 2012 10:47:33 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1349174852!32493511!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25999 invoked from network); 2 Oct 2012 10:47:32 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 10:47:32 -0000 X-IronPort-AV: E=Sophos;i="4.80,522,1344211200"; d="scan'208";a="14889336" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 10:47:31 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 11:47:31 +0100 Date: Tue, 2 Oct 2012 11:46:32 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Mukesh Rathor In-Reply-To: <20121001143244.36b4c270@mantra.us.oracle.com> Message-ID: References: <20120921121556.1a0ea8af@mantra.us.oracle.com> <20121001143244.36b4c270@mantra.us.oracle.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: Ian Campbell , Konrad Rzeszutek Wilk , "Xen-devel@lists.xensource.com" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, 1 Oct 2012, Mukesh Rathor wrote: > On Mon, 24 Sep 2012 12:55:31 +0100 > Stefano Stabellini wrote: > > > There are few code style issues on this patch, I suggest you run it > > through scripts/checkpatch.pl, it should be able to catch all these > > errors. > > All patches were run thru checkpatch.pl already. So not sure what you > are referring to. I'll go back to your series and tell you whenever I find a code style issue. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 10:47:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 10:47:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ00k-0005o1-Kw; Tue, 02 Oct 2012 10:47:34 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ00j-0005nu-U9 for Xen-devel@lists.xensource.com; Tue, 02 Oct 2012 10:47:34 +0000 Received: from [85.158.139.83:42899] by server-15.bemta-5.messagelabs.com id 27/19-19430-546CA605; Tue, 02 Oct 2012 10:47:33 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1349174852!32493511!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25999 invoked from network); 2 Oct 2012 10:47:32 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 10:47:32 -0000 X-IronPort-AV: E=Sophos;i="4.80,522,1344211200"; d="scan'208";a="14889336" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 10:47:31 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 11:47:31 +0100 Date: Tue, 2 Oct 2012 11:46:32 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Mukesh Rathor In-Reply-To: <20121001143244.36b4c270@mantra.us.oracle.com> Message-ID: References: <20120921121556.1a0ea8af@mantra.us.oracle.com> <20121001143244.36b4c270@mantra.us.oracle.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: Ian Campbell , Konrad Rzeszutek Wilk , "Xen-devel@lists.xensource.com" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, 1 Oct 2012, Mukesh Rathor wrote: > On Mon, 24 Sep 2012 12:55:31 +0100 > Stefano Stabellini wrote: > > > There are few code style issues on this patch, I suggest you run it > > through scripts/checkpatch.pl, it should be able to catch all these > > errors. > > All patches were run thru checkpatch.pl already. So not sure what you > are referring to. I'll go back to your series and tell you whenever I find a code style issue. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 10:49:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 10:49:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ02O-0005yT-AB; Tue, 02 Oct 2012 10:49:16 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ02M-0005yH-FY for Xen-devel@lists.xensource.com; Tue, 02 Oct 2012 10:49:14 +0000 Received: from [85.158.137.99:53894] by server-12.bemta-3.messagelabs.com id 8D/72-23730-9A6CA605; Tue, 02 Oct 2012 10:49:13 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-5.tower-217.messagelabs.com!1349174952!15194541!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10225 invoked from network); 2 Oct 2012 10:49:13 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 10:49:13 -0000 X-IronPort-AV: E=Sophos;i="4.80,522,1344211200"; d="scan'208";a="14889363" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 10:49:12 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 11:49:12 +0100 Date: Tue, 2 Oct 2012 11:48:13 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Mukesh Rathor In-Reply-To: <20120921121511.30001c08@mantra.us.oracle.com> Message-ID: References: <20120921121511.30001c08@mantra.us.oracle.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Ian Campbell , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 1/8]: PVH basic and hader file changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 21 Sep 2012, Mukesh Rathor wrote: > --- > arch/x86/include/asm/xen/interface.h | 8 +++++++- > arch/x86/include/asm/xen/page.h | 3 +++ > arch/x86/xen/irq.c | 5 ++++- > arch/x86/xen/p2m.c | 2 +- > drivers/xen/cpu_hotplug.c | 4 +++- > drivers/xen/events.c | 12 ++++++++---- > drivers/xen/xenbus/xenbus_client.c | 2 +- > drivers/xen/xenbus/xenbus_probe.c | 6 +++++- > include/xen/interface/memory.h | 27 +++++++++++++++++++++++++++ > include/xen/interface/physdev.h | 10 ++++++++++ > 10 files changed, 69 insertions(+), 10 deletions(-) > > diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h > index cbf0c9d..1d22131 100644 > --- a/arch/x86/include/asm/xen/interface.h > +++ b/arch/x86/include/asm/xen/interface.h > @@ -136,7 +136,13 @@ struct vcpu_guest_context { > struct cpu_user_regs user_regs; /* User-level CPU registers */ > struct trap_info trap_ctxt[256]; /* Virtual IDT */ > unsigned long ldt_base, ldt_ents; /* LDT (linear address, # ents) */ > - unsigned long gdt_frames[16], gdt_ents; /* GDT (machine frames, # ents) */ > + union { > + struct { > + /* PV: GDT (machine frames, # ents).*/ > + unsigned long gdt_frames[16], gdt_ents; > + }; > + unsigned long gdtaddr, gdtsz; /* PVH: GDTR addr and size */ > + }; > unsigned long kernel_ss, kernel_sp; /* Virtual TSS (only SS1/SP1) */ > /* NB. User pagetable on x86/64 is placed in ctrlreg[1]. */ > unsigned long ctrlreg[8]; /* CR0-CR7 (control registers) */ > diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h > index 93971e8..d1cfb96 100644 > --- a/arch/x86/include/asm/xen/page.h > +++ b/arch/x86/include/asm/xen/page.h > @@ -158,6 +158,9 @@ static inline xpaddr_t machine_to_phys(xmaddr_t machine) > static inline unsigned long mfn_to_local_pfn(unsigned long mfn) > { > unsigned long pfn = mfn_to_pfn(mfn); > + > + if (xen_feature(XENFEAT_auto_translated_physmap)) > + return mfn; > if (get_phys_to_machine(pfn) != mfn) > return -1; /* force !pfn_valid() */ > return pfn; > diff --git a/arch/x86/xen/irq.c b/arch/x86/xen/irq.c > index 1573376..31959a7 100644 > --- a/arch/x86/xen/irq.c > +++ b/arch/x86/xen/irq.c > @@ -5,6 +5,7 @@ > #include > #include > #include > +#include > > #include > #include > @@ -128,6 +129,8 @@ static const struct pv_irq_ops xen_irq_ops __initconst = { > > void __init xen_init_irq_ops(void) > { > - pv_irq_ops = xen_irq_ops; > + /* For PVH we use default pv_irq_ops settings */ > + if (!xen_feature(XENFEAT_hvm_callback_vector)) > + pv_irq_ops = xen_irq_ops; > x86_init.irqs.intr_init = xen_init_IRQ; > } > diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c > index 64effdc..a954f83 100644 > --- a/arch/x86/xen/p2m.c > +++ b/arch/x86/xen/p2m.c > @@ -626,7 +626,7 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn) > { > unsigned topidx, mididx, idx; > > - if (unlikely(xen_feature(XENFEAT_auto_translated_physmap))) { > + if (xen_feature(XENFEAT_auto_translated_physmap)) { > BUG_ON(pfn != mfn && mfn != INVALID_P2M_ENTRY); > return true; > } > diff --git a/drivers/xen/cpu_hotplug.c b/drivers/xen/cpu_hotplug.c > index 4dcfced..de6bcf9 100644 > --- a/drivers/xen/cpu_hotplug.c > +++ b/drivers/xen/cpu_hotplug.c > @@ -2,6 +2,7 @@ > > #include > #include > +#include > > #include > #include > @@ -100,7 +101,8 @@ static int __init setup_vcpu_hotplug_event(void) > static struct notifier_block xsn_cpu = { > .notifier_call = setup_cpu_watcher }; > > - if (!xen_pv_domain()) > + /* PVH TBD/FIXME: future work */ > + if (!xen_pv_domain() || xen_feature(XENFEAT_auto_translated_physmap)) > return -ENODEV; > > register_xenstore_notifier(&xsn_cpu); > diff --git a/drivers/xen/events.c b/drivers/xen/events.c > index 7595581..f656791 100644 > --- a/drivers/xen/events.c > +++ b/drivers/xen/events.c > @@ -1755,7 +1755,7 @@ int xen_set_callback_via(uint64_t via) > } > EXPORT_SYMBOL_GPL(xen_set_callback_via); > > -#ifdef CONFIG_XEN_PVHVM > + > /* Vector callbacks are better than PCI interrupts to receive event > * channel notifications because we can receive vector callbacks on any > * vcpu and we don't need PCI support or APIC interactions. */ > @@ -1779,9 +1779,6 @@ void xen_callback_vector(void) > alloc_intr_gate(XEN_HVM_EVTCHN_CALLBACK, xen_hvm_callback_vector); > } > } > -#else > -void xen_callback_vector(void) {} > -#endif > > void __init xen_init_IRQ(void) > { > @@ -1814,6 +1811,13 @@ void __init xen_init_IRQ(void) > if (xen_initial_domain()) > pci_xen_initial_domain(); > > + if (xen_feature(XENFEAT_hvm_callback_vector)) { > + xen_callback_vector(); > + return; > + } > + > + /* PVH: TBD/FIXME: debug and fix eio map to work with pvh */ > + > pirq_eoi_map = (void *)__get_free_page(GFP_KERNEL|__GFP_ZERO); > eoi_gmfn.gmfn = virt_to_mfn(pirq_eoi_map); > rc = HYPERVISOR_physdev_op(PHYSDEVOP_pirq_eoi_gmfn_v2, &eoi_gmfn); > diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c > index b3e146e..a81e66b 100644 > --- a/drivers/xen/xenbus/xenbus_client.c > +++ b/drivers/xen/xenbus/xenbus_client.c > @@ -743,7 +743,7 @@ static const struct xenbus_ring_ops ring_ops_hvm = { > > void __init xenbus_ring_ops_init(void) > { > - if (xen_pv_domain()) > + if (xen_pv_domain() && !xen_feature(XENFEAT_auto_translated_physmap)) > ring_ops = &ring_ops_pv; > else > ring_ops = &ring_ops_hvm; > diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c > index b793723..481dc72 100644 > --- a/drivers/xen/xenbus/xenbus_probe.c > +++ b/drivers/xen/xenbus/xenbus_probe.c > @@ -749,7 +749,11 @@ static int __init xenbus_init(void) > if (err) > goto out_error; > } > - xen_store_interface = mfn_to_virt(xen_store_mfn); > + if (xen_feature(XENFEAT_auto_translated_physmap)) code style: spaces vs tabs > + /* mfn is actually a pfn */ > + xen_store_interface = __va(xen_store_mfn< + else > + xen_store_interface = mfn_to_virt(xen_store_mfn); > } > > /* Initialize the interface to xenstore. */ > diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h > index eac3ce1..f150fa1c 100644 > --- a/include/xen/interface/memory.h > +++ b/include/xen/interface/memory.h > @@ -163,11 +163,22 @@ struct xen_add_to_physmap { > /* Which domain to change the mapping for. */ > domid_t domid; > > + union { > + /* Number of pages to go through for gmfn_range */ > + uint16_t size; > + /* IFF XENMAPSPACE_gmfn_foreign */ > + domid_t foreign_domid; > + } u; code style: mixed spaces and tabs > /* Source mapping space. */ > #define XENMAPSPACE_shared_info 0 /* shared info page */ > #define XENMAPSPACE_grant_table 1 /* grant table page */ > +#define XENMAPSPACE_gmfn 2 /* GMFN */ > +#define XENMAPSPACE_gmfn_range 3 /* GMFN range */ > +#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */ > unsigned int space; > > +#define XENMAPIDX_grant_table_status 0x80000000 > + > /* Index into source mapping space. */ > unsigned long idx; > > @@ -234,4 +245,20 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_memory_map); > * during a driver critical region. > */ > extern spinlock_t xen_reservation_lock; > + > +/* > + * Unmaps the page appearing at a particular GPFN from the specified guest's > + * pseudophysical address space. > + * arg == addr of xen_remove_from_physmap_t. > + */ > +#define XENMEM_remove_from_physmap 15 > +struct xen_remove_from_physmap { > + /* Which domain to change the mapping for. */ > + domid_t domid; > + > + /* GPFN of the current mapping of the page. */ > + unsigned long gpfn; > +}; > +DEFINE_GUEST_HANDLE_STRUCT(xen_remove_from_physmap); > + > #endif /* __XEN_PUBLIC_MEMORY_H__ */ > diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h > index 9ce788d..80f792e 100644 > --- a/include/xen/interface/physdev.h > +++ b/include/xen/interface/physdev.h > @@ -258,6 +258,16 @@ struct physdev_pci_device { > uint8_t devfn; > }; > > +#define PHYSDEVOP_pvh_map_iomem 29 > +struct physdev_map_iomem { > + /* IN */ > + uint64_t first_gfn; > + uint64_t first_mfn; > + uint32_t nr_mfns; > + uint32_t add_mapping; /* 1 == add mapping; 0 == unmap */ > + > +}; > + > /* > * Notify that some PIRQ-bound event channels have been unmasked. > * ** This command is obsolete since interface version 0x00030202 and is ** > -- > 1.7.2.3 > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 10:49:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 10:49:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ02O-0005yT-AB; Tue, 02 Oct 2012 10:49:16 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ02M-0005yH-FY for Xen-devel@lists.xensource.com; Tue, 02 Oct 2012 10:49:14 +0000 Received: from [85.158.137.99:53894] by server-12.bemta-3.messagelabs.com id 8D/72-23730-9A6CA605; Tue, 02 Oct 2012 10:49:13 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-5.tower-217.messagelabs.com!1349174952!15194541!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10225 invoked from network); 2 Oct 2012 10:49:13 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 10:49:13 -0000 X-IronPort-AV: E=Sophos;i="4.80,522,1344211200"; d="scan'208";a="14889363" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 10:49:12 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 11:49:12 +0100 Date: Tue, 2 Oct 2012 11:48:13 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Mukesh Rathor In-Reply-To: <20120921121511.30001c08@mantra.us.oracle.com> Message-ID: References: <20120921121511.30001c08@mantra.us.oracle.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Ian Campbell , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 1/8]: PVH basic and hader file changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 21 Sep 2012, Mukesh Rathor wrote: > --- > arch/x86/include/asm/xen/interface.h | 8 +++++++- > arch/x86/include/asm/xen/page.h | 3 +++ > arch/x86/xen/irq.c | 5 ++++- > arch/x86/xen/p2m.c | 2 +- > drivers/xen/cpu_hotplug.c | 4 +++- > drivers/xen/events.c | 12 ++++++++---- > drivers/xen/xenbus/xenbus_client.c | 2 +- > drivers/xen/xenbus/xenbus_probe.c | 6 +++++- > include/xen/interface/memory.h | 27 +++++++++++++++++++++++++++ > include/xen/interface/physdev.h | 10 ++++++++++ > 10 files changed, 69 insertions(+), 10 deletions(-) > > diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h > index cbf0c9d..1d22131 100644 > --- a/arch/x86/include/asm/xen/interface.h > +++ b/arch/x86/include/asm/xen/interface.h > @@ -136,7 +136,13 @@ struct vcpu_guest_context { > struct cpu_user_regs user_regs; /* User-level CPU registers */ > struct trap_info trap_ctxt[256]; /* Virtual IDT */ > unsigned long ldt_base, ldt_ents; /* LDT (linear address, # ents) */ > - unsigned long gdt_frames[16], gdt_ents; /* GDT (machine frames, # ents) */ > + union { > + struct { > + /* PV: GDT (machine frames, # ents).*/ > + unsigned long gdt_frames[16], gdt_ents; > + }; > + unsigned long gdtaddr, gdtsz; /* PVH: GDTR addr and size */ > + }; > unsigned long kernel_ss, kernel_sp; /* Virtual TSS (only SS1/SP1) */ > /* NB. User pagetable on x86/64 is placed in ctrlreg[1]. */ > unsigned long ctrlreg[8]; /* CR0-CR7 (control registers) */ > diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h > index 93971e8..d1cfb96 100644 > --- a/arch/x86/include/asm/xen/page.h > +++ b/arch/x86/include/asm/xen/page.h > @@ -158,6 +158,9 @@ static inline xpaddr_t machine_to_phys(xmaddr_t machine) > static inline unsigned long mfn_to_local_pfn(unsigned long mfn) > { > unsigned long pfn = mfn_to_pfn(mfn); > + > + if (xen_feature(XENFEAT_auto_translated_physmap)) > + return mfn; > if (get_phys_to_machine(pfn) != mfn) > return -1; /* force !pfn_valid() */ > return pfn; > diff --git a/arch/x86/xen/irq.c b/arch/x86/xen/irq.c > index 1573376..31959a7 100644 > --- a/arch/x86/xen/irq.c > +++ b/arch/x86/xen/irq.c > @@ -5,6 +5,7 @@ > #include > #include > #include > +#include > > #include > #include > @@ -128,6 +129,8 @@ static const struct pv_irq_ops xen_irq_ops __initconst = { > > void __init xen_init_irq_ops(void) > { > - pv_irq_ops = xen_irq_ops; > + /* For PVH we use default pv_irq_ops settings */ > + if (!xen_feature(XENFEAT_hvm_callback_vector)) > + pv_irq_ops = xen_irq_ops; > x86_init.irqs.intr_init = xen_init_IRQ; > } > diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c > index 64effdc..a954f83 100644 > --- a/arch/x86/xen/p2m.c > +++ b/arch/x86/xen/p2m.c > @@ -626,7 +626,7 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn) > { > unsigned topidx, mididx, idx; > > - if (unlikely(xen_feature(XENFEAT_auto_translated_physmap))) { > + if (xen_feature(XENFEAT_auto_translated_physmap)) { > BUG_ON(pfn != mfn && mfn != INVALID_P2M_ENTRY); > return true; > } > diff --git a/drivers/xen/cpu_hotplug.c b/drivers/xen/cpu_hotplug.c > index 4dcfced..de6bcf9 100644 > --- a/drivers/xen/cpu_hotplug.c > +++ b/drivers/xen/cpu_hotplug.c > @@ -2,6 +2,7 @@ > > #include > #include > +#include > > #include > #include > @@ -100,7 +101,8 @@ static int __init setup_vcpu_hotplug_event(void) > static struct notifier_block xsn_cpu = { > .notifier_call = setup_cpu_watcher }; > > - if (!xen_pv_domain()) > + /* PVH TBD/FIXME: future work */ > + if (!xen_pv_domain() || xen_feature(XENFEAT_auto_translated_physmap)) > return -ENODEV; > > register_xenstore_notifier(&xsn_cpu); > diff --git a/drivers/xen/events.c b/drivers/xen/events.c > index 7595581..f656791 100644 > --- a/drivers/xen/events.c > +++ b/drivers/xen/events.c > @@ -1755,7 +1755,7 @@ int xen_set_callback_via(uint64_t via) > } > EXPORT_SYMBOL_GPL(xen_set_callback_via); > > -#ifdef CONFIG_XEN_PVHVM > + > /* Vector callbacks are better than PCI interrupts to receive event > * channel notifications because we can receive vector callbacks on any > * vcpu and we don't need PCI support or APIC interactions. */ > @@ -1779,9 +1779,6 @@ void xen_callback_vector(void) > alloc_intr_gate(XEN_HVM_EVTCHN_CALLBACK, xen_hvm_callback_vector); > } > } > -#else > -void xen_callback_vector(void) {} > -#endif > > void __init xen_init_IRQ(void) > { > @@ -1814,6 +1811,13 @@ void __init xen_init_IRQ(void) > if (xen_initial_domain()) > pci_xen_initial_domain(); > > + if (xen_feature(XENFEAT_hvm_callback_vector)) { > + xen_callback_vector(); > + return; > + } > + > + /* PVH: TBD/FIXME: debug and fix eio map to work with pvh */ > + > pirq_eoi_map = (void *)__get_free_page(GFP_KERNEL|__GFP_ZERO); > eoi_gmfn.gmfn = virt_to_mfn(pirq_eoi_map); > rc = HYPERVISOR_physdev_op(PHYSDEVOP_pirq_eoi_gmfn_v2, &eoi_gmfn); > diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c > index b3e146e..a81e66b 100644 > --- a/drivers/xen/xenbus/xenbus_client.c > +++ b/drivers/xen/xenbus/xenbus_client.c > @@ -743,7 +743,7 @@ static const struct xenbus_ring_ops ring_ops_hvm = { > > void __init xenbus_ring_ops_init(void) > { > - if (xen_pv_domain()) > + if (xen_pv_domain() && !xen_feature(XENFEAT_auto_translated_physmap)) > ring_ops = &ring_ops_pv; > else > ring_ops = &ring_ops_hvm; > diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c > index b793723..481dc72 100644 > --- a/drivers/xen/xenbus/xenbus_probe.c > +++ b/drivers/xen/xenbus/xenbus_probe.c > @@ -749,7 +749,11 @@ static int __init xenbus_init(void) > if (err) > goto out_error; > } > - xen_store_interface = mfn_to_virt(xen_store_mfn); > + if (xen_feature(XENFEAT_auto_translated_physmap)) code style: spaces vs tabs > + /* mfn is actually a pfn */ > + xen_store_interface = __va(xen_store_mfn< + else > + xen_store_interface = mfn_to_virt(xen_store_mfn); > } > > /* Initialize the interface to xenstore. */ > diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h > index eac3ce1..f150fa1c 100644 > --- a/include/xen/interface/memory.h > +++ b/include/xen/interface/memory.h > @@ -163,11 +163,22 @@ struct xen_add_to_physmap { > /* Which domain to change the mapping for. */ > domid_t domid; > > + union { > + /* Number of pages to go through for gmfn_range */ > + uint16_t size; > + /* IFF XENMAPSPACE_gmfn_foreign */ > + domid_t foreign_domid; > + } u; code style: mixed spaces and tabs > /* Source mapping space. */ > #define XENMAPSPACE_shared_info 0 /* shared info page */ > #define XENMAPSPACE_grant_table 1 /* grant table page */ > +#define XENMAPSPACE_gmfn 2 /* GMFN */ > +#define XENMAPSPACE_gmfn_range 3 /* GMFN range */ > +#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */ > unsigned int space; > > +#define XENMAPIDX_grant_table_status 0x80000000 > + > /* Index into source mapping space. */ > unsigned long idx; > > @@ -234,4 +245,20 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_memory_map); > * during a driver critical region. > */ > extern spinlock_t xen_reservation_lock; > + > +/* > + * Unmaps the page appearing at a particular GPFN from the specified guest's > + * pseudophysical address space. > + * arg == addr of xen_remove_from_physmap_t. > + */ > +#define XENMEM_remove_from_physmap 15 > +struct xen_remove_from_physmap { > + /* Which domain to change the mapping for. */ > + domid_t domid; > + > + /* GPFN of the current mapping of the page. */ > + unsigned long gpfn; > +}; > +DEFINE_GUEST_HANDLE_STRUCT(xen_remove_from_physmap); > + > #endif /* __XEN_PUBLIC_MEMORY_H__ */ > diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h > index 9ce788d..80f792e 100644 > --- a/include/xen/interface/physdev.h > +++ b/include/xen/interface/physdev.h > @@ -258,6 +258,16 @@ struct physdev_pci_device { > uint8_t devfn; > }; > > +#define PHYSDEVOP_pvh_map_iomem 29 > +struct physdev_map_iomem { > + /* IN */ > + uint64_t first_gfn; > + uint64_t first_mfn; > + uint32_t nr_mfns; > + uint32_t add_mapping; /* 1 == add mapping; 0 == unmap */ > + > +}; > + > /* > * Notify that some PIRQ-bound event channels have been unmasked. > * ** This command is obsolete since interface version 0x00030202 and is ** > -- > 1.7.2.3 > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 10:50:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 10:50:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ039-00065g-Op; Tue, 02 Oct 2012 10:50:03 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ037-000653-19 for xen-devel@lists.xen.org; Tue, 02 Oct 2012 10:50:01 +0000 Received: from [85.158.139.83:63779] by server-16.bemta-5.messagelabs.com id EE/E6-05998-8D6CA605; Tue, 02 Oct 2012 10:50:00 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1349174999!28502545!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13608 invoked from network); 2 Oct 2012 10:49:59 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 10:49:59 -0000 X-IronPort-AV: E=Sophos;i="4.80,522,1344211200"; d="scan'208";a="14889403" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 10:49:59 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 11:49:58 +0100 Message-ID: <1349174997.650.34.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Matthew Fioravante Date: Tue, 2 Oct 2012 11:49:57 +0100 In-Reply-To: <1348765802-11314-4-git-send-email-matthew.fioravante@jhuapl.edu> References: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu> <1348765802-11314-4-git-send-email-matthew.fioravante@jhuapl.edu> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "samuel.thibault@ens-lyon.org" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 04/11] Disable the mfn_is_ram() check, it doesn't work correctly on all systems X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-09-27 at 18:09 +0100, Matthew Fioravante wrote: > This patch disables the mfn_is_ram check in mini-os. The current check > is insufficient and fails on some systems with larger than 4gb memory. > > Signed-off-by: Matthew Fioravante > Acked-by: Samuel Thibault Further down the thread with the Ack Samuel said: We can probably just remove the check in __do_ioremap, which AFAIK is the only call. since this function is a bit pointless now. > > diff --git a/extras/mini-os/arch/x86/mm.c b/extras/mini-os/arch/x86/mm.c > index 80aceac..5813a08 100644 > --- a/extras/mini-os/arch/x86/mm.c > +++ b/extras/mini-os/arch/x86/mm.c > @@ -850,6 +850,8 @@ unsigned long alloc_contig_pages(int order, unsigned int addr_bits) > static long system_ram_end_mfn; > int mfn_is_ram(unsigned long mfn) > { > + /* This is broken on systems with large ammounts of ram. Always return 0 for now */ > + return 0; > /* very crude check if a given MFN is memory or not. Probably should > * make this a little more sophisticated ;) */ > return (mfn <= system_ram_end_mfn) ? 1 : 0; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 10:50:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 10:50:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ039-00065g-Op; Tue, 02 Oct 2012 10:50:03 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ037-000653-19 for xen-devel@lists.xen.org; Tue, 02 Oct 2012 10:50:01 +0000 Received: from [85.158.139.83:63779] by server-16.bemta-5.messagelabs.com id EE/E6-05998-8D6CA605; Tue, 02 Oct 2012 10:50:00 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1349174999!28502545!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13608 invoked from network); 2 Oct 2012 10:49:59 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 10:49:59 -0000 X-IronPort-AV: E=Sophos;i="4.80,522,1344211200"; d="scan'208";a="14889403" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 10:49:59 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 11:49:58 +0100 Message-ID: <1349174997.650.34.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Matthew Fioravante Date: Tue, 2 Oct 2012 11:49:57 +0100 In-Reply-To: <1348765802-11314-4-git-send-email-matthew.fioravante@jhuapl.edu> References: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu> <1348765802-11314-4-git-send-email-matthew.fioravante@jhuapl.edu> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "samuel.thibault@ens-lyon.org" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 04/11] Disable the mfn_is_ram() check, it doesn't work correctly on all systems X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-09-27 at 18:09 +0100, Matthew Fioravante wrote: > This patch disables the mfn_is_ram check in mini-os. The current check > is insufficient and fails on some systems with larger than 4gb memory. > > Signed-off-by: Matthew Fioravante > Acked-by: Samuel Thibault Further down the thread with the Ack Samuel said: We can probably just remove the check in __do_ioremap, which AFAIK is the only call. since this function is a bit pointless now. > > diff --git a/extras/mini-os/arch/x86/mm.c b/extras/mini-os/arch/x86/mm.c > index 80aceac..5813a08 100644 > --- a/extras/mini-os/arch/x86/mm.c > +++ b/extras/mini-os/arch/x86/mm.c > @@ -850,6 +850,8 @@ unsigned long alloc_contig_pages(int order, unsigned int addr_bits) > static long system_ram_end_mfn; > int mfn_is_ram(unsigned long mfn) > { > + /* This is broken on systems with large ammounts of ram. Always return 0 for now */ > + return 0; > /* very crude check if a given MFN is memory or not. Probably should > * make this a little more sophisticated ;) */ > return (mfn <= system_ram_end_mfn) ? 1 : 0; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 10:51:59 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 10:51:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ04n-0006KB-KD; Tue, 02 Oct 2012 10:51:45 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ04l-0006JE-P7 for Xen-devel@lists.xensource.com; Tue, 02 Oct 2012 10:51:44 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1349175079!6152699!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25594 invoked from network); 2 Oct 2012 10:51:19 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 10:51:19 -0000 X-IronPort-AV: E=Sophos;i="4.80,522,1344211200"; d="scan'208";a="14889433" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 10:50:57 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 11:50:57 +0100 Date: Tue, 2 Oct 2012 11:49:58 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Mukesh Rathor In-Reply-To: <20120921121556.1a0ea8af@mantra.us.oracle.com> Message-ID: References: <20120921121556.1a0ea8af@mantra.us.oracle.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Ian Campbell , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 21 Sep 2012, Mukesh Rathor wrote: > --- > arch/x86/xen/mmu.c | 180 +++++++++++++++++++++++++++++++++++++++++++++++-- > arch/x86/xen/mmu.h | 2 + > include/xen/xen-ops.h | 12 +++- > 3 files changed, 188 insertions(+), 6 deletions(-) > > diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c > index b65a761..9b5a5ef 100644 > --- a/arch/x86/xen/mmu.c > +++ b/arch/x86/xen/mmu.c > @@ -73,6 +73,7 @@ > #include > #include > #include > +#include > > #include "multicalls.h" > #include "mmu.h" > @@ -330,6 +331,26 @@ static void xen_set_pte(pte_t *ptep, pte_t pteval) > __xen_set_pte(ptep, pteval); > } > > +void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn, > + int nr_mfns, int add_mapping) > +{ > + struct physdev_map_iomem iomem; > + > + iomem.first_gfn = pfn; > + iomem.first_mfn = mfn; > + iomem.nr_mfns = nr_mfns; > + iomem.add_mapping = add_mapping; > + > + if (HYPERVISOR_physdev_op(PHYSDEVOP_pvh_map_iomem, &iomem)) > + BUG(); > +} > + > +static void xen_dom0pvh_set_pte_at(struct mm_struct *mm, unsigned long addr, > + pte_t *ptep, pte_t pteval) > +{ > + native_set_pte(ptep, pteval); > +} > + > static void xen_set_pte_at(struct mm_struct *mm, unsigned long addr, > pte_t *ptep, pte_t pteval) > { > @@ -1197,6 +1218,10 @@ static void xen_post_allocator_init(void); > static void __init xen_pagetable_setup_done(pgd_t *base) > { > xen_setup_shared_info(); > + > + if (xen_feature(XENFEAT_auto_translated_physmap)) > + return; > + > xen_post_allocator_init(); > } > > @@ -1455,6 +1480,10 @@ static void __init xen_set_pte_init(pte_t *ptep, pte_t pte) > static void pin_pagetable_pfn(unsigned cmd, unsigned long pfn) > { > struct mmuext_op op; > + > + if (xen_feature(XENFEAT_writable_page_tables)) > + return; > + > op.cmd = cmd; > op.arg1.mfn = pfn_to_mfn(pfn); > if (HYPERVISOR_mmuext_op(&op, 1, NULL, DOMID_SELF)) > @@ -1652,6 +1681,10 @@ static void set_page_prot(void *addr, pgprot_t prot) > unsigned long pfn = __pa(addr) >> PAGE_SHIFT; > pte_t pte = pfn_pte(pfn, prot); > > + /* recall for PVH, page tables are native. */ > + if (xen_feature(XENFEAT_auto_translated_physmap)) > + return; > + > if (HYPERVISOR_update_va_mapping((unsigned long)addr, pte, 0)) > BUG(); > } > @@ -1729,6 +1762,9 @@ static void convert_pfn_mfn(void *v) > pte_t *pte = v; > int i; > > + if (xen_feature(XENFEAT_auto_translated_physmap)) > + return; > + > /* All levels are converted the same way, so just treat them > as ptes. */ > for (i = 0; i < PTRS_PER_PTE; i++) > @@ -1745,6 +1781,7 @@ static void convert_pfn_mfn(void *v) > * but that's enough to get __va working. We need to fill in the rest > * of the physical mapping once some sort of allocator has been set > * up. > + * NOTE: for PVH, the page tables are native. > */ > pgd_t * __init xen_setup_kernel_pagetable(pgd_t *pgd, > unsigned long max_pfn) > @@ -1802,9 +1839,13 @@ pgd_t * __init xen_setup_kernel_pagetable(pgd_t *pgd, > * structure to attach it to, so make sure we just set kernel > * pgd. > */ > - xen_mc_batch(); > - __xen_write_cr3(true, __pa(pgd)); > - xen_mc_issue(PARAVIRT_LAZY_CPU); > + if (xen_feature(XENFEAT_writable_page_tables)) { > + native_write_cr3(__pa(pgd)); > + } else { > + xen_mc_batch(); > + __xen_write_cr3(true, __pa(pgd)); > + xen_mc_issue(PARAVIRT_LAZY_CPU); > + } > > memblock_reserve(__pa(xen_start_info->pt_base), > xen_start_info->nr_pt_frames * PAGE_SIZE); > @@ -2067,9 +2108,21 @@ static const struct pv_mmu_ops xen_mmu_ops __initconst = { > > void __init xen_init_mmu_ops(void) > { > + x86_init.paging.pagetable_setup_done = xen_pagetable_setup_done; > + > + if (xen_feature(XENFEAT_auto_translated_physmap)) { > + pv_mmu_ops.flush_tlb_others = xen_flush_tlb_others; > + > + /* set_pte* for PCI devices to map iomem. */ > + if (xen_initial_domain()) { > + pv_mmu_ops.set_pte = native_set_pte; > + pv_mmu_ops.set_pte_at = xen_dom0pvh_set_pte_at; > + } > + return; > + } > + > x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve; > x86_init.paging.pagetable_setup_start = xen_pagetable_setup_start; > - x86_init.paging.pagetable_setup_done = xen_pagetable_setup_done; > pv_mmu_ops = xen_mmu_ops; > > memset(dummy_mapping, 0xff, PAGE_SIZE); > @@ -2305,6 +2358,92 @@ void __init xen_hvm_init_mmu_ops(void) > } > #endif > > +/* Map foreign gmfn, fgmfn, to local pfn, lpfn. This for the user space > + * creating new guest on PVH dom0 and needs to map domU pages. > + */ > +static int pvh_add_to_xen_p2m(unsigned long lpfn, unsigned long fgmfn, > + unsigned int domid) > +{ > + int rc; > + struct xen_add_to_physmap xatp = { .u.foreign_domid = domid }; > + > + xatp.gpfn = lpfn; > + xatp.idx = fgmfn; > + xatp.domid = DOMID_SELF; > + xatp.space = XENMAPSPACE_gmfn_foreign; > + rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp); > + if (rc) > + pr_warn("d0: Failed to map pfn to mfn rc:%d pfn:%lx mfn:%lx\n", > + rc, lpfn, fgmfn); > + return rc; > +} > + > +int pvh_rem_xen_p2m(unsigned long spfn, int count) > +{ > + struct xen_remove_from_physmap xrp; > + int i, rc; > + > + for (i=0; i < count; i++) { i = 0 > + xrp.domid = DOMID_SELF; > + xrp.gpfn = spfn+i; spfn + i > + rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, &xrp); > + if (rc) { > + pr_warn("Failed to unmap pfn:%lx rc:%d done:%d\n", > + spfn+i, rc, i); spfn + i > + return 1; > + } > + } > + return 0; > +} > +EXPORT_SYMBOL_GPL(pvh_rem_xen_p2m); > + > +struct pvh_remap_data { > + unsigned long fgmfn; /* foreign domain's gmfn */ > + pgprot_t prot; > + domid_t domid; > + struct xen_pvh_pfn_info *pvhinfop; > +}; > + > +static int pvh_map_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr, > + void *data) > +{ > + int rc; > + struct pvh_remap_data *remapp = data; > + struct xen_pvh_pfn_info *pvhp = remapp->pvhinfop; > + unsigned long pfn = page_to_pfn(pvhp->pi_paga[pvhp->pi_next_todo++]); > + pte_t pteval = pte_mkspecial(pfn_pte(pfn, remapp->prot)); > + > + if ((rc=pvh_add_to_xen_p2m(pfn, remapp->fgmfn, remapp->domid))) > + return rc; rc = pvh_add_to_xen_p2m > + native_set_pte(ptep, pteval); > + > + return 0; > +} > + > +/* The only caller at moment passes one gmfn at a time. > + * PVH TBD/FIXME: expand this in future to honor batch requests. > + */ > +static int pvh_remap_gmfn_range(struct vm_area_struct *vma, > + unsigned long addr, unsigned long mfn, int nr, > + pgprot_t prot, unsigned domid, > + struct xen_pvh_pfn_info *pvhp) > +{ > + int err; > + struct pvh_remap_data pvhdata; > + > + if (nr > 1) > + return -EINVAL; > + > + pvhdata.fgmfn = mfn; > + pvhdata.prot = prot; > + pvhdata.domid = domid; > + pvhdata.pvhinfop = pvhp; > + err = apply_to_page_range(vma->vm_mm, addr, nr << PAGE_SHIFT, > + pvh_map_pte_fn, &pvhdata); > + flush_tlb_all(); > + return err; > +} > + > #define REMAP_BATCH_SIZE 16 > > struct remap_data { > @@ -2329,7 +2468,9 @@ static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token, > int xen_remap_domain_mfn_range(struct vm_area_struct *vma, > unsigned long addr, > unsigned long mfn, int nr, > - pgprot_t prot, unsigned domid) > + pgprot_t prot, unsigned domid, > + struct xen_pvh_pfn_info *pvhp) > + > { > struct remap_data rmd; > struct mmu_update mmu_update[REMAP_BATCH_SIZE]; > @@ -2342,6 +2483,12 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma, > BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_RESERVED | VM_IO)) == > (VM_PFNMAP | VM_RESERVED | VM_IO))); > > + if (xen_feature(XENFEAT_auto_translated_physmap)) { > + /* We need to update the local page tables and the xen HAP */ > + return pvh_remap_gmfn_range(vma, addr, mfn, nr, prot, domid, > + pvhp); > + } > + > rmd.mfn = mfn; > rmd.prot = prot; > > @@ -2371,3 +2518,26 @@ out: > return err; > } > EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range); > + > +/* Returns: Number of pages unmapped */ > +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma, > + struct xen_pvh_pfn_info *pvhp) > +{ > + int count = 0; > + > + if (!pvhp || !xen_feature(XENFEAT_auto_translated_physmap)) > + return 0; > + > + while (pvhp->pi_next_todo--) { > + unsigned long pfn; > + > + /* the mmu has already cleaned up the process mmu resources at > + * this point (lookup_address will return NULL). */ > + pfn = page_to_pfn(pvhp->pi_paga[pvhp->pi_next_todo]); > + pvh_rem_xen_p2m(pfn, 1); > + count++; > + } > + flush_tlb_all(); > + return count; > +} > +EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range); > diff --git a/arch/x86/xen/mmu.h b/arch/x86/xen/mmu.h > index 73809bb..6d0bb56 100644 > --- a/arch/x86/xen/mmu.h > +++ b/arch/x86/xen/mmu.h > @@ -23,4 +23,6 @@ unsigned long xen_read_cr2_direct(void); > > extern void xen_init_mmu_ops(void); > extern void xen_hvm_init_mmu_ops(void); > +extern void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn, > + int nr_mfns, int add_mapping); > #endif /* _XEN_MMU_H */ > diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h > index 6a198e4..6c5ad83 100644 > --- a/include/xen/xen-ops.h > +++ b/include/xen/xen-ops.h > @@ -24,9 +24,19 @@ int xen_create_contiguous_region(unsigned long vstart, unsigned int order, > void xen_destroy_contiguous_region(unsigned long vstart, unsigned int order); > > struct vm_area_struct; > +struct xen_pvh_pfn_info; > int xen_remap_domain_mfn_range(struct vm_area_struct *vma, > unsigned long addr, > unsigned long mfn, int nr, > - pgprot_t prot, unsigned domid); > + pgprot_t prot, unsigned domid, > + struct xen_pvh_pfn_info *pvhp); > +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma, > + struct xen_pvh_pfn_info *pvhp); > + > +struct xen_pvh_pfn_info { > + struct page **pi_paga; /* pfn info page array */ > + int pi_num_pgs; > + int pi_next_todo; > +}; > > #endif /* INCLUDE_XEN_OPS_H */ > -- > 1.7.2.3 > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 10:51:59 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 10:51:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ04n-0006KB-KD; Tue, 02 Oct 2012 10:51:45 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ04l-0006JE-P7 for Xen-devel@lists.xensource.com; Tue, 02 Oct 2012 10:51:44 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1349175079!6152699!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25594 invoked from network); 2 Oct 2012 10:51:19 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 10:51:19 -0000 X-IronPort-AV: E=Sophos;i="4.80,522,1344211200"; d="scan'208";a="14889433" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 10:50:57 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 11:50:57 +0100 Date: Tue, 2 Oct 2012 11:49:58 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Mukesh Rathor In-Reply-To: <20120921121556.1a0ea8af@mantra.us.oracle.com> Message-ID: References: <20120921121556.1a0ea8af@mantra.us.oracle.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Ian Campbell , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 21 Sep 2012, Mukesh Rathor wrote: > --- > arch/x86/xen/mmu.c | 180 +++++++++++++++++++++++++++++++++++++++++++++++-- > arch/x86/xen/mmu.h | 2 + > include/xen/xen-ops.h | 12 +++- > 3 files changed, 188 insertions(+), 6 deletions(-) > > diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c > index b65a761..9b5a5ef 100644 > --- a/arch/x86/xen/mmu.c > +++ b/arch/x86/xen/mmu.c > @@ -73,6 +73,7 @@ > #include > #include > #include > +#include > > #include "multicalls.h" > #include "mmu.h" > @@ -330,6 +331,26 @@ static void xen_set_pte(pte_t *ptep, pte_t pteval) > __xen_set_pte(ptep, pteval); > } > > +void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn, > + int nr_mfns, int add_mapping) > +{ > + struct physdev_map_iomem iomem; > + > + iomem.first_gfn = pfn; > + iomem.first_mfn = mfn; > + iomem.nr_mfns = nr_mfns; > + iomem.add_mapping = add_mapping; > + > + if (HYPERVISOR_physdev_op(PHYSDEVOP_pvh_map_iomem, &iomem)) > + BUG(); > +} > + > +static void xen_dom0pvh_set_pte_at(struct mm_struct *mm, unsigned long addr, > + pte_t *ptep, pte_t pteval) > +{ > + native_set_pte(ptep, pteval); > +} > + > static void xen_set_pte_at(struct mm_struct *mm, unsigned long addr, > pte_t *ptep, pte_t pteval) > { > @@ -1197,6 +1218,10 @@ static void xen_post_allocator_init(void); > static void __init xen_pagetable_setup_done(pgd_t *base) > { > xen_setup_shared_info(); > + > + if (xen_feature(XENFEAT_auto_translated_physmap)) > + return; > + > xen_post_allocator_init(); > } > > @@ -1455,6 +1480,10 @@ static void __init xen_set_pte_init(pte_t *ptep, pte_t pte) > static void pin_pagetable_pfn(unsigned cmd, unsigned long pfn) > { > struct mmuext_op op; > + > + if (xen_feature(XENFEAT_writable_page_tables)) > + return; > + > op.cmd = cmd; > op.arg1.mfn = pfn_to_mfn(pfn); > if (HYPERVISOR_mmuext_op(&op, 1, NULL, DOMID_SELF)) > @@ -1652,6 +1681,10 @@ static void set_page_prot(void *addr, pgprot_t prot) > unsigned long pfn = __pa(addr) >> PAGE_SHIFT; > pte_t pte = pfn_pte(pfn, prot); > > + /* recall for PVH, page tables are native. */ > + if (xen_feature(XENFEAT_auto_translated_physmap)) > + return; > + > if (HYPERVISOR_update_va_mapping((unsigned long)addr, pte, 0)) > BUG(); > } > @@ -1729,6 +1762,9 @@ static void convert_pfn_mfn(void *v) > pte_t *pte = v; > int i; > > + if (xen_feature(XENFEAT_auto_translated_physmap)) > + return; > + > /* All levels are converted the same way, so just treat them > as ptes. */ > for (i = 0; i < PTRS_PER_PTE; i++) > @@ -1745,6 +1781,7 @@ static void convert_pfn_mfn(void *v) > * but that's enough to get __va working. We need to fill in the rest > * of the physical mapping once some sort of allocator has been set > * up. > + * NOTE: for PVH, the page tables are native. > */ > pgd_t * __init xen_setup_kernel_pagetable(pgd_t *pgd, > unsigned long max_pfn) > @@ -1802,9 +1839,13 @@ pgd_t * __init xen_setup_kernel_pagetable(pgd_t *pgd, > * structure to attach it to, so make sure we just set kernel > * pgd. > */ > - xen_mc_batch(); > - __xen_write_cr3(true, __pa(pgd)); > - xen_mc_issue(PARAVIRT_LAZY_CPU); > + if (xen_feature(XENFEAT_writable_page_tables)) { > + native_write_cr3(__pa(pgd)); > + } else { > + xen_mc_batch(); > + __xen_write_cr3(true, __pa(pgd)); > + xen_mc_issue(PARAVIRT_LAZY_CPU); > + } > > memblock_reserve(__pa(xen_start_info->pt_base), > xen_start_info->nr_pt_frames * PAGE_SIZE); > @@ -2067,9 +2108,21 @@ static const struct pv_mmu_ops xen_mmu_ops __initconst = { > > void __init xen_init_mmu_ops(void) > { > + x86_init.paging.pagetable_setup_done = xen_pagetable_setup_done; > + > + if (xen_feature(XENFEAT_auto_translated_physmap)) { > + pv_mmu_ops.flush_tlb_others = xen_flush_tlb_others; > + > + /* set_pte* for PCI devices to map iomem. */ > + if (xen_initial_domain()) { > + pv_mmu_ops.set_pte = native_set_pte; > + pv_mmu_ops.set_pte_at = xen_dom0pvh_set_pte_at; > + } > + return; > + } > + > x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve; > x86_init.paging.pagetable_setup_start = xen_pagetable_setup_start; > - x86_init.paging.pagetable_setup_done = xen_pagetable_setup_done; > pv_mmu_ops = xen_mmu_ops; > > memset(dummy_mapping, 0xff, PAGE_SIZE); > @@ -2305,6 +2358,92 @@ void __init xen_hvm_init_mmu_ops(void) > } > #endif > > +/* Map foreign gmfn, fgmfn, to local pfn, lpfn. This for the user space > + * creating new guest on PVH dom0 and needs to map domU pages. > + */ > +static int pvh_add_to_xen_p2m(unsigned long lpfn, unsigned long fgmfn, > + unsigned int domid) > +{ > + int rc; > + struct xen_add_to_physmap xatp = { .u.foreign_domid = domid }; > + > + xatp.gpfn = lpfn; > + xatp.idx = fgmfn; > + xatp.domid = DOMID_SELF; > + xatp.space = XENMAPSPACE_gmfn_foreign; > + rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp); > + if (rc) > + pr_warn("d0: Failed to map pfn to mfn rc:%d pfn:%lx mfn:%lx\n", > + rc, lpfn, fgmfn); > + return rc; > +} > + > +int pvh_rem_xen_p2m(unsigned long spfn, int count) > +{ > + struct xen_remove_from_physmap xrp; > + int i, rc; > + > + for (i=0; i < count; i++) { i = 0 > + xrp.domid = DOMID_SELF; > + xrp.gpfn = spfn+i; spfn + i > + rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, &xrp); > + if (rc) { > + pr_warn("Failed to unmap pfn:%lx rc:%d done:%d\n", > + spfn+i, rc, i); spfn + i > + return 1; > + } > + } > + return 0; > +} > +EXPORT_SYMBOL_GPL(pvh_rem_xen_p2m); > + > +struct pvh_remap_data { > + unsigned long fgmfn; /* foreign domain's gmfn */ > + pgprot_t prot; > + domid_t domid; > + struct xen_pvh_pfn_info *pvhinfop; > +}; > + > +static int pvh_map_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr, > + void *data) > +{ > + int rc; > + struct pvh_remap_data *remapp = data; > + struct xen_pvh_pfn_info *pvhp = remapp->pvhinfop; > + unsigned long pfn = page_to_pfn(pvhp->pi_paga[pvhp->pi_next_todo++]); > + pte_t pteval = pte_mkspecial(pfn_pte(pfn, remapp->prot)); > + > + if ((rc=pvh_add_to_xen_p2m(pfn, remapp->fgmfn, remapp->domid))) > + return rc; rc = pvh_add_to_xen_p2m > + native_set_pte(ptep, pteval); > + > + return 0; > +} > + > +/* The only caller at moment passes one gmfn at a time. > + * PVH TBD/FIXME: expand this in future to honor batch requests. > + */ > +static int pvh_remap_gmfn_range(struct vm_area_struct *vma, > + unsigned long addr, unsigned long mfn, int nr, > + pgprot_t prot, unsigned domid, > + struct xen_pvh_pfn_info *pvhp) > +{ > + int err; > + struct pvh_remap_data pvhdata; > + > + if (nr > 1) > + return -EINVAL; > + > + pvhdata.fgmfn = mfn; > + pvhdata.prot = prot; > + pvhdata.domid = domid; > + pvhdata.pvhinfop = pvhp; > + err = apply_to_page_range(vma->vm_mm, addr, nr << PAGE_SHIFT, > + pvh_map_pte_fn, &pvhdata); > + flush_tlb_all(); > + return err; > +} > + > #define REMAP_BATCH_SIZE 16 > > struct remap_data { > @@ -2329,7 +2468,9 @@ static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token, > int xen_remap_domain_mfn_range(struct vm_area_struct *vma, > unsigned long addr, > unsigned long mfn, int nr, > - pgprot_t prot, unsigned domid) > + pgprot_t prot, unsigned domid, > + struct xen_pvh_pfn_info *pvhp) > + > { > struct remap_data rmd; > struct mmu_update mmu_update[REMAP_BATCH_SIZE]; > @@ -2342,6 +2483,12 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma, > BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_RESERVED | VM_IO)) == > (VM_PFNMAP | VM_RESERVED | VM_IO))); > > + if (xen_feature(XENFEAT_auto_translated_physmap)) { > + /* We need to update the local page tables and the xen HAP */ > + return pvh_remap_gmfn_range(vma, addr, mfn, nr, prot, domid, > + pvhp); > + } > + > rmd.mfn = mfn; > rmd.prot = prot; > > @@ -2371,3 +2518,26 @@ out: > return err; > } > EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range); > + > +/* Returns: Number of pages unmapped */ > +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma, > + struct xen_pvh_pfn_info *pvhp) > +{ > + int count = 0; > + > + if (!pvhp || !xen_feature(XENFEAT_auto_translated_physmap)) > + return 0; > + > + while (pvhp->pi_next_todo--) { > + unsigned long pfn; > + > + /* the mmu has already cleaned up the process mmu resources at > + * this point (lookup_address will return NULL). */ > + pfn = page_to_pfn(pvhp->pi_paga[pvhp->pi_next_todo]); > + pvh_rem_xen_p2m(pfn, 1); > + count++; > + } > + flush_tlb_all(); > + return count; > +} > +EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range); > diff --git a/arch/x86/xen/mmu.h b/arch/x86/xen/mmu.h > index 73809bb..6d0bb56 100644 > --- a/arch/x86/xen/mmu.h > +++ b/arch/x86/xen/mmu.h > @@ -23,4 +23,6 @@ unsigned long xen_read_cr2_direct(void); > > extern void xen_init_mmu_ops(void); > extern void xen_hvm_init_mmu_ops(void); > +extern void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn, > + int nr_mfns, int add_mapping); > #endif /* _XEN_MMU_H */ > diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h > index 6a198e4..6c5ad83 100644 > --- a/include/xen/xen-ops.h > +++ b/include/xen/xen-ops.h > @@ -24,9 +24,19 @@ int xen_create_contiguous_region(unsigned long vstart, unsigned int order, > void xen_destroy_contiguous_region(unsigned long vstart, unsigned int order); > > struct vm_area_struct; > +struct xen_pvh_pfn_info; > int xen_remap_domain_mfn_range(struct vm_area_struct *vma, > unsigned long addr, > unsigned long mfn, int nr, > - pgprot_t prot, unsigned domid); > + pgprot_t prot, unsigned domid, > + struct xen_pvh_pfn_info *pvhp); > +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma, > + struct xen_pvh_pfn_info *pvhp); > + > +struct xen_pvh_pfn_info { > + struct page **pi_paga; /* pfn info page array */ > + int pi_num_pgs; > + int pi_next_todo; > +}; > > #endif /* INCLUDE_XEN_OPS_H */ > -- > 1.7.2.3 > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 10:52:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 10:52:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ05J-0006QG-2L; Tue, 02 Oct 2012 10:52:17 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ05H-0006Pk-6D for Xen-devel@lists.xensource.com; Tue, 02 Oct 2012 10:52:15 +0000 Received: from [85.158.137.99:27984] by server-10.bemta-3.messagelabs.com id 81/60-02525-E57CA605; Tue, 02 Oct 2012 10:52:14 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-4.tower-217.messagelabs.com!1349175133!19955785!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6780 invoked from network); 2 Oct 2012 10:52:14 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 10:52:14 -0000 X-IronPort-AV: E=Sophos;i="4.80,522,1344211200"; d="scan'208";a="14889462" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 10:52:13 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 11:52:13 +0100 Date: Tue, 2 Oct 2012 11:51:14 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Mukesh Rathor In-Reply-To: <20120921121752.5fa80b35@mantra.us.oracle.com> Message-ID: References: <20120921121752.5fa80b35@mantra.us.oracle.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Ian Campbell , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 4/8]: PVH setup changes... X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 21 Sep 2012, Mukesh Rathor wrote: > > --- > arch/x86/xen/setup.c | 51 ++++++++++++++++++++++++++++++++++++++++++------- > 1 files changed, 43 insertions(+), 8 deletions(-) > > diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c > index ead8557..fba442e 100644 > --- a/arch/x86/xen/setup.c > +++ b/arch/x86/xen/setup.c > @@ -26,6 +26,7 @@ > #include > #include > #include > +#include "mmu.h" > #include "xen-ops.h" > #include "vdso.h" > > @@ -222,6 +223,26 @@ static void __init xen_set_identity_and_release_chunk( > *identity += set_phys_range_identity(start_pfn, end_pfn); > } > > +/* For PVH, the pfns [0..MAX] are mapped to mfn's in the EPT/NPT. The mfns > + * are released as part of this 1:1 mapping hypercall back to the dom heap. We > + * don't use the xen_do_chunk() PV does above because when P2M/EPT/NPT is > + * updated, the mfns are already lost as part of the p2m update. > + * Also, we map the entire IO space, ie, beyond max_pfn_mapped. > + */ > +static void __init xen_pvh_identity_map_chunk(unsigned long start_pfn, > + unsigned long end_pfn, unsigned long *released, > + unsigned long *identity) > +{ > + unsigned long pfn; > + int numpfns=1, add_mapping=1; int numpfns = 1, add_mapping = 1 > + for (pfn = start_pfn; pfn < end_pfn; pfn++) > + xen_set_clr_mmio_pvh_pte(pfn, pfn, numpfns, add_mapping); > + > + *released += end_pfn - start_pfn; > + *identity += end_pfn - start_pfn; > +} > + > static unsigned long __init xen_set_identity_and_release( > const struct e820entry *list, size_t map_size, unsigned long nr_pages) > { > @@ -230,6 +251,7 @@ static unsigned long __init xen_set_identity_and_release( > unsigned long identity = 0; > const struct e820entry *entry; > int i; > + int xlated_phys = xen_feature(XENFEAT_auto_translated_physmap); > > /* > * Combine non-RAM regions and gaps until a RAM region (or the > @@ -251,11 +273,16 @@ static unsigned long __init xen_set_identity_and_release( > if (entry->type == E820_RAM) > end_pfn = PFN_UP(entry->addr); > > - if (start_pfn < end_pfn) > - xen_set_identity_and_release_chunk( > - start_pfn, end_pfn, nr_pages, > - &released, &identity); > - > + if (start_pfn < end_pfn) { > + if (xlated_phys) { > + xen_pvh_identity_map_chunk(start_pfn, > + end_pfn, &released, &identity); > + } else { > + xen_set_identity_and_release_chunk( > + start_pfn, end_pfn, nr_pages, > + &released, &identity); > + } > + } > start = end; > } > } > @@ -500,10 +527,9 @@ void __cpuinit xen_enable_syscall(void) > #endif /* CONFIG_X86_64 */ > } > > -void __init xen_arch_setup(void) > +/* Non auto translated PV domain, ie, it's not PVH. */ > +static __init void inline xen_non_pvh_arch_setup(void) > { > - xen_panic_handler_init(); > - > HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_4gb_segments); > HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_writable_pagetables); > > @@ -517,6 +543,15 @@ void __init xen_arch_setup(void) > > xen_enable_sysenter(); > xen_enable_syscall(); > +} > + > +/* This function not called for HVM domain */ > +void __init xen_arch_setup(void) > +{ > + xen_panic_handler_init(); > + > + if (!xen_feature(XENFEAT_auto_translated_physmap)) > + xen_non_pvh_arch_setup(); > > #ifdef CONFIG_ACPI > if (!(xen_start_info->flags & SIF_INITDOMAIN)) { > -- > 1.7.2.3 > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 10:52:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 10:52:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ05J-0006QG-2L; Tue, 02 Oct 2012 10:52:17 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ05H-0006Pk-6D for Xen-devel@lists.xensource.com; Tue, 02 Oct 2012 10:52:15 +0000 Received: from [85.158.137.99:27984] by server-10.bemta-3.messagelabs.com id 81/60-02525-E57CA605; Tue, 02 Oct 2012 10:52:14 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-4.tower-217.messagelabs.com!1349175133!19955785!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6780 invoked from network); 2 Oct 2012 10:52:14 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 10:52:14 -0000 X-IronPort-AV: E=Sophos;i="4.80,522,1344211200"; d="scan'208";a="14889462" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 10:52:13 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 11:52:13 +0100 Date: Tue, 2 Oct 2012 11:51:14 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Mukesh Rathor In-Reply-To: <20120921121752.5fa80b35@mantra.us.oracle.com> Message-ID: References: <20120921121752.5fa80b35@mantra.us.oracle.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Ian Campbell , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 4/8]: PVH setup changes... X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 21 Sep 2012, Mukesh Rathor wrote: > > --- > arch/x86/xen/setup.c | 51 ++++++++++++++++++++++++++++++++++++++++++------- > 1 files changed, 43 insertions(+), 8 deletions(-) > > diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c > index ead8557..fba442e 100644 > --- a/arch/x86/xen/setup.c > +++ b/arch/x86/xen/setup.c > @@ -26,6 +26,7 @@ > #include > #include > #include > +#include "mmu.h" > #include "xen-ops.h" > #include "vdso.h" > > @@ -222,6 +223,26 @@ static void __init xen_set_identity_and_release_chunk( > *identity += set_phys_range_identity(start_pfn, end_pfn); > } > > +/* For PVH, the pfns [0..MAX] are mapped to mfn's in the EPT/NPT. The mfns > + * are released as part of this 1:1 mapping hypercall back to the dom heap. We > + * don't use the xen_do_chunk() PV does above because when P2M/EPT/NPT is > + * updated, the mfns are already lost as part of the p2m update. > + * Also, we map the entire IO space, ie, beyond max_pfn_mapped. > + */ > +static void __init xen_pvh_identity_map_chunk(unsigned long start_pfn, > + unsigned long end_pfn, unsigned long *released, > + unsigned long *identity) > +{ > + unsigned long pfn; > + int numpfns=1, add_mapping=1; int numpfns = 1, add_mapping = 1 > + for (pfn = start_pfn; pfn < end_pfn; pfn++) > + xen_set_clr_mmio_pvh_pte(pfn, pfn, numpfns, add_mapping); > + > + *released += end_pfn - start_pfn; > + *identity += end_pfn - start_pfn; > +} > + > static unsigned long __init xen_set_identity_and_release( > const struct e820entry *list, size_t map_size, unsigned long nr_pages) > { > @@ -230,6 +251,7 @@ static unsigned long __init xen_set_identity_and_release( > unsigned long identity = 0; > const struct e820entry *entry; > int i; > + int xlated_phys = xen_feature(XENFEAT_auto_translated_physmap); > > /* > * Combine non-RAM regions and gaps until a RAM region (or the > @@ -251,11 +273,16 @@ static unsigned long __init xen_set_identity_and_release( > if (entry->type == E820_RAM) > end_pfn = PFN_UP(entry->addr); > > - if (start_pfn < end_pfn) > - xen_set_identity_and_release_chunk( > - start_pfn, end_pfn, nr_pages, > - &released, &identity); > - > + if (start_pfn < end_pfn) { > + if (xlated_phys) { > + xen_pvh_identity_map_chunk(start_pfn, > + end_pfn, &released, &identity); > + } else { > + xen_set_identity_and_release_chunk( > + start_pfn, end_pfn, nr_pages, > + &released, &identity); > + } > + } > start = end; > } > } > @@ -500,10 +527,9 @@ void __cpuinit xen_enable_syscall(void) > #endif /* CONFIG_X86_64 */ > } > > -void __init xen_arch_setup(void) > +/* Non auto translated PV domain, ie, it's not PVH. */ > +static __init void inline xen_non_pvh_arch_setup(void) > { > - xen_panic_handler_init(); > - > HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_4gb_segments); > HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_writable_pagetables); > > @@ -517,6 +543,15 @@ void __init xen_arch_setup(void) > > xen_enable_sysenter(); > xen_enable_syscall(); > +} > + > +/* This function not called for HVM domain */ > +void __init xen_arch_setup(void) > +{ > + xen_panic_handler_init(); > + > + if (!xen_feature(XENFEAT_auto_translated_physmap)) > + xen_non_pvh_arch_setup(); > > #ifdef CONFIG_ACPI > if (!(xen_start_info->flags & SIF_INITDOMAIN)) { > -- > 1.7.2.3 > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 10:54:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 10:54:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ06x-0006d9-IW; Tue, 02 Oct 2012 10:53:59 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ06w-0006d0-Hj for Xen-devel@lists.xensource.com; Tue, 02 Oct 2012 10:53:58 +0000 Received: from [85.158.139.211:13668] by server-15.bemta-5.messagelabs.com id E4/88-19430-5C7CA605; Tue, 02 Oct 2012 10:53:57 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-11.tower-206.messagelabs.com!1349175236!20758230!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31895 invoked from network); 2 Oct 2012 10:53:57 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 10:53:57 -0000 X-IronPort-AV: E=Sophos;i="4.80,522,1344211200"; d="scan'208";a="14889523" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 10:53:56 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 11:53:56 +0100 Date: Tue, 2 Oct 2012 11:52:57 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Mukesh Rathor In-Reply-To: <20120921121928.1c5765bc@mantra.us.oracle.com> Message-ID: References: <20120921121928.1c5765bc@mantra.us.oracle.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Ian Campbell , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 6/8]: PVH ballooning and grant changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 21 Sep 2012, Mukesh Rathor wrote: > > --- > drivers/xen/balloon.c | 35 ++++++++++++++++++++++++++++------- > drivers/xen/gntdev.c | 3 ++- > drivers/xen/grant-table.c | 25 +++++++++++++++++++++---- > 3 files changed, 51 insertions(+), 12 deletions(-) > > diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c > index 31ab82f..85a6917 100644 > --- a/drivers/xen/balloon.c > +++ b/drivers/xen/balloon.c > @@ -358,10 +358,21 @@ static enum bp_state increase_reservation(unsigned long nr_pages) > BUG_ON(!xen_feature(XENFEAT_auto_translated_physmap) && > phys_to_machine_mapping_valid(pfn)); > > - set_phys_to_machine(pfn, frame_list[i]); > + if (xen_pv_domain() && > + xen_feature(XENFEAT_auto_translated_physmap)) { > + /* PVH: we just need to update native page table */ > + pte_t *ptep; > + unsigned int level; > + void *addr = __va(pfn << PAGE_SHIFT); > + ptep = lookup_address((unsigned long)addr, &level); > + set_pte(ptep, pfn_pte(pfn, PAGE_KERNEL)); > + } else > + set_phys_to_machine(pfn, frame_list[i]); > > /* Link back into the page tables if not highmem. */ > - if (xen_pv_domain() && !PageHighMem(page)) { > + if (xen_pv_domain() && !PageHighMem(page) && > + !xen_feature(XENFEAT_auto_translated_physmap)) { > + > int ret; > ret = HYPERVISOR_update_va_mapping( > (unsigned long)__va(pfn << PAGE_SHIFT), > @@ -418,12 +429,21 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp) > scrub_page(page); > > if (xen_pv_domain() && !PageHighMem(page)) { > - ret = HYPERVISOR_update_va_mapping( > - (unsigned long)__va(pfn << PAGE_SHIFT), > - __pte_ma(0), 0); > - BUG_ON(ret); > + if (xen_feature(XENFEAT_auto_translated_physmap)) { > + unsigned int level; > + pte_t *ptep; > + void *addr = __va(pfn << PAGE_SHIFT); > + ptep = lookup_address((unsigned long)addr, > + &level); > + set_pte(ptep, __pte(0)); > + > + } else { > + ret = HYPERVISOR_update_va_mapping( > + (unsigned long)__va(pfn << PAGE_SHIFT), > + __pte_ma(0), 0); > + BUG_ON(ret); > + } > } > - > } > > /* Ensure that ballooned highmem pages don't have kmaps. */ > @@ -433,6 +453,7 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp) > /* No more mappings: invalidate P2M and add to balloon. */ > for (i = 0; i < nr_pages; i++) { > pfn = mfn_to_pfn(frame_list[i]); > + /* PVH note: following will noop for auto translated */ > __set_phys_to_machine(pfn, INVALID_P2M_ENTRY); > balloon_append(pfn_to_page(pfn)); > } > diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c > index 1ffd03b..35d1e3c 100644 > --- a/drivers/xen/gntdev.c > +++ b/drivers/xen/gntdev.c > @@ -802,7 +802,8 @@ static int __init gntdev_init(void) > if (!xen_domain()) > return -ENODEV; > > - use_ptemod = xen_pv_domain(); > + use_ptemod = xen_pv_domain() && > + !xen_feature(XENFEAT_auto_translated_physmap); > > err = misc_register(&gntdev_miscdev); > if (err != 0) { > diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c > index 0bfc1ef..d831d52 100644 > --- a/drivers/xen/grant-table.c > +++ b/drivers/xen/grant-table.c > @@ -974,14 +974,19 @@ static void gnttab_unmap_frames_v2(void) > static int gnttab_map(unsigned int start_idx, unsigned int end_idx) > { > struct gnttab_setup_table setup; > - unsigned long *frames; > + unsigned long *frames, start_gpfn; > unsigned int nr_gframes = end_idx + 1; > int rc; > > - if (xen_hvm_domain()) { > + if (xen_hvm_domain() || xen_feature(XENFEAT_auto_translated_physmap)) { > struct xen_add_to_physmap xatp; > unsigned int i = end_idx; > rc = 0; > + > + if (xen_hvm_domain()) > + start_gpfn = xen_hvm_resume_frames >> PAGE_SHIFT; > + else > + start_gpfn = virt_to_pfn(gnttab_shared.addr); > /* > * Loop backwards, so that the first hypercall has the largest > * index, ensuring that the table will grow only once. > @@ -990,7 +995,7 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx) > xatp.domid = DOMID_SELF; > xatp.idx = i; > xatp.space = XENMAPSPACE_grant_table; > - xatp.gpfn = (xen_hvm_resume_frames >> PAGE_SHIFT) + i; > + xatp.gpfn = start_gpfn + i; > rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp); > if (rc != 0) { > printk(KERN_WARNING > @@ -1053,7 +1058,7 @@ static void gnttab_request_version(void) > int rc; > struct gnttab_set_version gsv; > > - if (xen_hvm_domain()) > + if (xen_hvm_domain() || xen_feature(XENFEAT_auto_translated_physmap)) > gsv.version = 1; > else > gsv.version = 2; > @@ -1081,12 +1086,24 @@ static void gnttab_request_version(void) > int gnttab_resume(void) > { > unsigned int max_nr_gframes; > + char *kmsg="Failed to kmalloc pages for pv in hvm grant frames\n"; msg = "Failed > > gnttab_request_version(); > max_nr_gframes = gnttab_max_grant_frames(); > if (max_nr_gframes < nr_grant_frames) > return -ENOSYS; > > + /* PVH note: xen will free existing kmalloc'd mfn in > + * XENMEM_add_to_physmap */ > + if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap) && > + !gnttab_shared.addr) { > + gnttab_shared.addr = > + kmalloc(max_nr_gframes * PAGE_SIZE, GFP_KERNEL); > + if ( !gnttab_shared.addr ) { if (!gnttab_shared.addr) { > + printk(KERN_WARNING "%s", kmsg); > + return -ENOMEM; > + } > + } > if (xen_pv_domain()) > return gnttab_map(0, nr_grant_frames - 1); > > -- > 1.7.2.3 > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 10:54:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 10:54:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ06x-0006d9-IW; Tue, 02 Oct 2012 10:53:59 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ06w-0006d0-Hj for Xen-devel@lists.xensource.com; Tue, 02 Oct 2012 10:53:58 +0000 Received: from [85.158.139.211:13668] by server-15.bemta-5.messagelabs.com id E4/88-19430-5C7CA605; Tue, 02 Oct 2012 10:53:57 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-11.tower-206.messagelabs.com!1349175236!20758230!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31895 invoked from network); 2 Oct 2012 10:53:57 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 10:53:57 -0000 X-IronPort-AV: E=Sophos;i="4.80,522,1344211200"; d="scan'208";a="14889523" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 10:53:56 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 11:53:56 +0100 Date: Tue, 2 Oct 2012 11:52:57 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Mukesh Rathor In-Reply-To: <20120921121928.1c5765bc@mantra.us.oracle.com> Message-ID: References: <20120921121928.1c5765bc@mantra.us.oracle.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Ian Campbell , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 6/8]: PVH ballooning and grant changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 21 Sep 2012, Mukesh Rathor wrote: > > --- > drivers/xen/balloon.c | 35 ++++++++++++++++++++++++++++------- > drivers/xen/gntdev.c | 3 ++- > drivers/xen/grant-table.c | 25 +++++++++++++++++++++---- > 3 files changed, 51 insertions(+), 12 deletions(-) > > diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c > index 31ab82f..85a6917 100644 > --- a/drivers/xen/balloon.c > +++ b/drivers/xen/balloon.c > @@ -358,10 +358,21 @@ static enum bp_state increase_reservation(unsigned long nr_pages) > BUG_ON(!xen_feature(XENFEAT_auto_translated_physmap) && > phys_to_machine_mapping_valid(pfn)); > > - set_phys_to_machine(pfn, frame_list[i]); > + if (xen_pv_domain() && > + xen_feature(XENFEAT_auto_translated_physmap)) { > + /* PVH: we just need to update native page table */ > + pte_t *ptep; > + unsigned int level; > + void *addr = __va(pfn << PAGE_SHIFT); > + ptep = lookup_address((unsigned long)addr, &level); > + set_pte(ptep, pfn_pte(pfn, PAGE_KERNEL)); > + } else > + set_phys_to_machine(pfn, frame_list[i]); > > /* Link back into the page tables if not highmem. */ > - if (xen_pv_domain() && !PageHighMem(page)) { > + if (xen_pv_domain() && !PageHighMem(page) && > + !xen_feature(XENFEAT_auto_translated_physmap)) { > + > int ret; > ret = HYPERVISOR_update_va_mapping( > (unsigned long)__va(pfn << PAGE_SHIFT), > @@ -418,12 +429,21 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp) > scrub_page(page); > > if (xen_pv_domain() && !PageHighMem(page)) { > - ret = HYPERVISOR_update_va_mapping( > - (unsigned long)__va(pfn << PAGE_SHIFT), > - __pte_ma(0), 0); > - BUG_ON(ret); > + if (xen_feature(XENFEAT_auto_translated_physmap)) { > + unsigned int level; > + pte_t *ptep; > + void *addr = __va(pfn << PAGE_SHIFT); > + ptep = lookup_address((unsigned long)addr, > + &level); > + set_pte(ptep, __pte(0)); > + > + } else { > + ret = HYPERVISOR_update_va_mapping( > + (unsigned long)__va(pfn << PAGE_SHIFT), > + __pte_ma(0), 0); > + BUG_ON(ret); > + } > } > - > } > > /* Ensure that ballooned highmem pages don't have kmaps. */ > @@ -433,6 +453,7 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp) > /* No more mappings: invalidate P2M and add to balloon. */ > for (i = 0; i < nr_pages; i++) { > pfn = mfn_to_pfn(frame_list[i]); > + /* PVH note: following will noop for auto translated */ > __set_phys_to_machine(pfn, INVALID_P2M_ENTRY); > balloon_append(pfn_to_page(pfn)); > } > diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c > index 1ffd03b..35d1e3c 100644 > --- a/drivers/xen/gntdev.c > +++ b/drivers/xen/gntdev.c > @@ -802,7 +802,8 @@ static int __init gntdev_init(void) > if (!xen_domain()) > return -ENODEV; > > - use_ptemod = xen_pv_domain(); > + use_ptemod = xen_pv_domain() && > + !xen_feature(XENFEAT_auto_translated_physmap); > > err = misc_register(&gntdev_miscdev); > if (err != 0) { > diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c > index 0bfc1ef..d831d52 100644 > --- a/drivers/xen/grant-table.c > +++ b/drivers/xen/grant-table.c > @@ -974,14 +974,19 @@ static void gnttab_unmap_frames_v2(void) > static int gnttab_map(unsigned int start_idx, unsigned int end_idx) > { > struct gnttab_setup_table setup; > - unsigned long *frames; > + unsigned long *frames, start_gpfn; > unsigned int nr_gframes = end_idx + 1; > int rc; > > - if (xen_hvm_domain()) { > + if (xen_hvm_domain() || xen_feature(XENFEAT_auto_translated_physmap)) { > struct xen_add_to_physmap xatp; > unsigned int i = end_idx; > rc = 0; > + > + if (xen_hvm_domain()) > + start_gpfn = xen_hvm_resume_frames >> PAGE_SHIFT; > + else > + start_gpfn = virt_to_pfn(gnttab_shared.addr); > /* > * Loop backwards, so that the first hypercall has the largest > * index, ensuring that the table will grow only once. > @@ -990,7 +995,7 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx) > xatp.domid = DOMID_SELF; > xatp.idx = i; > xatp.space = XENMAPSPACE_grant_table; > - xatp.gpfn = (xen_hvm_resume_frames >> PAGE_SHIFT) + i; > + xatp.gpfn = start_gpfn + i; > rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp); > if (rc != 0) { > printk(KERN_WARNING > @@ -1053,7 +1058,7 @@ static void gnttab_request_version(void) > int rc; > struct gnttab_set_version gsv; > > - if (xen_hvm_domain()) > + if (xen_hvm_domain() || xen_feature(XENFEAT_auto_translated_physmap)) > gsv.version = 1; > else > gsv.version = 2; > @@ -1081,12 +1086,24 @@ static void gnttab_request_version(void) > int gnttab_resume(void) > { > unsigned int max_nr_gframes; > + char *kmsg="Failed to kmalloc pages for pv in hvm grant frames\n"; msg = "Failed > > gnttab_request_version(); > max_nr_gframes = gnttab_max_grant_frames(); > if (max_nr_gframes < nr_grant_frames) > return -ENOSYS; > > + /* PVH note: xen will free existing kmalloc'd mfn in > + * XENMEM_add_to_physmap */ > + if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap) && > + !gnttab_shared.addr) { > + gnttab_shared.addr = > + kmalloc(max_nr_gframes * PAGE_SIZE, GFP_KERNEL); > + if ( !gnttab_shared.addr ) { if (!gnttab_shared.addr) { > + printk(KERN_WARNING "%s", kmsg); > + return -ENOMEM; > + } > + } > if (xen_pv_domain()) > return gnttab_map(0, nr_grant_frames - 1); > > -- > 1.7.2.3 > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 10:56:14 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 10:56:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ090-0006oZ-40; Tue, 02 Oct 2012 10:56:06 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ08y-0006oO-9M for Xen-devel@lists.xensource.com; Tue, 02 Oct 2012 10:56:04 +0000 Received: from [85.158.143.35:43581] by server-3.bemta-4.messagelabs.com id BD/78-10986-348CA605; Tue, 02 Oct 2012 10:56:03 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1349175310!4723803!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10754 invoked from network); 2 Oct 2012 10:55:10 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 10:55:10 -0000 X-IronPort-AV: E=Sophos;i="4.80,522,1344211200"; d="scan'208";a="14889555" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 10:55:10 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 11:55:10 +0100 Date: Tue, 2 Oct 2012 11:54:11 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Mukesh Rathor In-Reply-To: <20120921122123.33489ce1@mantra.us.oracle.com> Message-ID: References: <20120921122123.33489ce1@mantra.us.oracle.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Ian Campbell , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 7/8]: PVH privcmd changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 21 Sep 2012, Mukesh Rathor wrote: > > --- > drivers/xen/privcmd.c | 77 ++++++++++++++++++++++++++++++++++++++++++++---- > 1 files changed, 70 insertions(+), 7 deletions(-) > > diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c > index ccee0f1..195d89f 100644 > --- a/drivers/xen/privcmd.c > +++ b/drivers/xen/privcmd.c > @@ -33,6 +33,7 @@ > #include > #include > #include > +#include > > #include "privcmd.h" > > @@ -178,7 +179,7 @@ static int mmap_mfn_range(void *data, void *state) > msg->va & PAGE_MASK, > msg->mfn, msg->npages, > vma->vm_page_prot, > - st->domain); > + st->domain, NULL); > if (rc < 0) > return rc; > > @@ -199,6 +200,10 @@ static long privcmd_ioctl_mmap(void __user *udata) > if (!xen_initial_domain()) > return -EPERM; > > + /* PVH: TBD/FIXME. For now we only support privcmd_ioctl_mmap_batch */ > + if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap)) > + return -ENOSYS; > + > if (copy_from_user(&mmapcmd, udata, sizeof(mmapcmd))) > return -EFAULT; > > @@ -251,13 +256,18 @@ struct mmap_batch_state { > xen_pfn_t __user *user; > }; > > +/* PVH dom0 fyi: if domU being created is PV, then mfn is mfn(addr on bus). If > + * it's PVH then mfn is pfn (input to HAP). */ > static int mmap_batch_fn(void *data, void *state) > { > xen_pfn_t *mfnp = data; > struct mmap_batch_state *st = state; > + struct vm_area_struct *vma = st->vma; > + struct xen_pvh_pfn_info *pvhp = vma ? vma->vm_private_data : NULL; > > - if (xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1, > - st->vma->vm_page_prot, st->domain) < 0) { > + if (xen_remap_domain_mfn_range(vma, st->va & PAGE_MASK, *mfnp, 1, > + vma->vm_page_prot, st->domain, > + pvhp) < 0) { > *mfnp |= 0xf0000000U; > st->err++; > } > @@ -274,6 +284,40 @@ static int mmap_return_errors(void *data, void *state) > return put_user(*mfnp, st->user++); > } > > +/* Allocate pfns that are then mapped with gmfns from foreign domid. Update > + * the vma with the page info to use later. > + * Returns: 0 if success, otherwise -errno > + */ > +static int pvh_privcmd_resv_pfns(struct vm_area_struct *vma, int numpgs) > +{ > + int rc; > + struct xen_pvh_pfn_info *pvhp; > + > + pvhp = kzalloc(sizeof(struct xen_pvh_pfn_info), GFP_KERNEL); > + if (pvhp == NULL) > + return -ENOMEM; > + > + pvhp->pi_paga = kcalloc(numpgs, sizeof(pvhp->pi_paga[0]), GFP_KERNEL); > + if (pvhp->pi_paga == NULL) { > + kfree(pvhp); > + return -ENOMEM; > + } > + > + rc = alloc_xenballooned_pages(numpgs, pvhp->pi_paga, 0); > + if (rc != 0) { > + pr_warn("%s Could not alloc %d pfns rc:%d\n", __FUNCTION__, > + numpgs, rc); > + kfree(pvhp->pi_paga); > + kfree(pvhp); > + return -ENOMEM; > + } > + pvhp->pi_num_pgs = numpgs; > + BUG_ON(vma->vm_private_data != (void *)1); > + vma->vm_private_data = pvhp; > + > + return 0; > +} > + > static struct vm_operations_struct privcmd_vm_ops; > > static long privcmd_ioctl_mmap_batch(void __user *udata) > @@ -315,6 +359,12 @@ static long privcmd_ioctl_mmap_batch(void __user *udata) > goto out; > } > > + if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap)) { > + if ((ret=pvh_privcmd_resv_pfns(vma, m.num))) { ret = pvh_privcmd_resv_pfns > + up_write(&mm->mmap_sem); > + goto out; > + } > + } > state.domain = m.dom; > state.vma = vma; > state.va = m.addr; > @@ -365,6 +415,22 @@ static long privcmd_ioctl(struct file *file, > return ret; > } > > +static void privcmd_close(struct vm_area_struct *vma) > +{ > + int count; > + struct xen_pvh_pfn_info *pvhp = vma ? vma->vm_private_data : NULL; > + > + if (!xen_pv_domain() || !pvhp || > + !xen_feature(XENFEAT_auto_translated_physmap)) > + return; > + > + count = xen_unmap_domain_mfn_range(vma, pvhp); > + while (count--) > + free_xenballooned_pages(1, &pvhp->pi_paga[count]); > + kfree(pvhp->pi_paga); > + kfree(pvhp); > +} > + > static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf) > { > printk(KERN_DEBUG "privcmd_fault: vma=%p %lx-%lx, pgoff=%lx, uv=%p\n", > @@ -375,15 +441,12 @@ static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf) > } > > static struct vm_operations_struct privcmd_vm_ops = { > + .close = privcmd_close, > .fault = privcmd_fault > }; > > static int privcmd_mmap(struct file *file, struct vm_area_struct *vma) > { > - /* Unsupported for auto-translate guests. */ > - if (xen_feature(XENFEAT_auto_translated_physmap)) > - return -ENOSYS; > - > /* DONTCOPY is essential for Xen because copy_page_range doesn't know > * how to recreate these mappings */ > vma->vm_flags |= VM_RESERVED | VM_IO | VM_DONTCOPY | VM_PFNMAP; > -- > 1.7.2.3 > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 10:56:14 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 10:56:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ090-0006oZ-40; Tue, 02 Oct 2012 10:56:06 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ08y-0006oO-9M for Xen-devel@lists.xensource.com; Tue, 02 Oct 2012 10:56:04 +0000 Received: from [85.158.143.35:43581] by server-3.bemta-4.messagelabs.com id BD/78-10986-348CA605; Tue, 02 Oct 2012 10:56:03 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1349175310!4723803!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10754 invoked from network); 2 Oct 2012 10:55:10 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 10:55:10 -0000 X-IronPort-AV: E=Sophos;i="4.80,522,1344211200"; d="scan'208";a="14889555" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 10:55:10 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 11:55:10 +0100 Date: Tue, 2 Oct 2012 11:54:11 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Mukesh Rathor In-Reply-To: <20120921122123.33489ce1@mantra.us.oracle.com> Message-ID: References: <20120921122123.33489ce1@mantra.us.oracle.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Ian Campbell , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 7/8]: PVH privcmd changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 21 Sep 2012, Mukesh Rathor wrote: > > --- > drivers/xen/privcmd.c | 77 ++++++++++++++++++++++++++++++++++++++++++++---- > 1 files changed, 70 insertions(+), 7 deletions(-) > > diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c > index ccee0f1..195d89f 100644 > --- a/drivers/xen/privcmd.c > +++ b/drivers/xen/privcmd.c > @@ -33,6 +33,7 @@ > #include > #include > #include > +#include > > #include "privcmd.h" > > @@ -178,7 +179,7 @@ static int mmap_mfn_range(void *data, void *state) > msg->va & PAGE_MASK, > msg->mfn, msg->npages, > vma->vm_page_prot, > - st->domain); > + st->domain, NULL); > if (rc < 0) > return rc; > > @@ -199,6 +200,10 @@ static long privcmd_ioctl_mmap(void __user *udata) > if (!xen_initial_domain()) > return -EPERM; > > + /* PVH: TBD/FIXME. For now we only support privcmd_ioctl_mmap_batch */ > + if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap)) > + return -ENOSYS; > + > if (copy_from_user(&mmapcmd, udata, sizeof(mmapcmd))) > return -EFAULT; > > @@ -251,13 +256,18 @@ struct mmap_batch_state { > xen_pfn_t __user *user; > }; > > +/* PVH dom0 fyi: if domU being created is PV, then mfn is mfn(addr on bus). If > + * it's PVH then mfn is pfn (input to HAP). */ > static int mmap_batch_fn(void *data, void *state) > { > xen_pfn_t *mfnp = data; > struct mmap_batch_state *st = state; > + struct vm_area_struct *vma = st->vma; > + struct xen_pvh_pfn_info *pvhp = vma ? vma->vm_private_data : NULL; > > - if (xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1, > - st->vma->vm_page_prot, st->domain) < 0) { > + if (xen_remap_domain_mfn_range(vma, st->va & PAGE_MASK, *mfnp, 1, > + vma->vm_page_prot, st->domain, > + pvhp) < 0) { > *mfnp |= 0xf0000000U; > st->err++; > } > @@ -274,6 +284,40 @@ static int mmap_return_errors(void *data, void *state) > return put_user(*mfnp, st->user++); > } > > +/* Allocate pfns that are then mapped with gmfns from foreign domid. Update > + * the vma with the page info to use later. > + * Returns: 0 if success, otherwise -errno > + */ > +static int pvh_privcmd_resv_pfns(struct vm_area_struct *vma, int numpgs) > +{ > + int rc; > + struct xen_pvh_pfn_info *pvhp; > + > + pvhp = kzalloc(sizeof(struct xen_pvh_pfn_info), GFP_KERNEL); > + if (pvhp == NULL) > + return -ENOMEM; > + > + pvhp->pi_paga = kcalloc(numpgs, sizeof(pvhp->pi_paga[0]), GFP_KERNEL); > + if (pvhp->pi_paga == NULL) { > + kfree(pvhp); > + return -ENOMEM; > + } > + > + rc = alloc_xenballooned_pages(numpgs, pvhp->pi_paga, 0); > + if (rc != 0) { > + pr_warn("%s Could not alloc %d pfns rc:%d\n", __FUNCTION__, > + numpgs, rc); > + kfree(pvhp->pi_paga); > + kfree(pvhp); > + return -ENOMEM; > + } > + pvhp->pi_num_pgs = numpgs; > + BUG_ON(vma->vm_private_data != (void *)1); > + vma->vm_private_data = pvhp; > + > + return 0; > +} > + > static struct vm_operations_struct privcmd_vm_ops; > > static long privcmd_ioctl_mmap_batch(void __user *udata) > @@ -315,6 +359,12 @@ static long privcmd_ioctl_mmap_batch(void __user *udata) > goto out; > } > > + if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap)) { > + if ((ret=pvh_privcmd_resv_pfns(vma, m.num))) { ret = pvh_privcmd_resv_pfns > + up_write(&mm->mmap_sem); > + goto out; > + } > + } > state.domain = m.dom; > state.vma = vma; > state.va = m.addr; > @@ -365,6 +415,22 @@ static long privcmd_ioctl(struct file *file, > return ret; > } > > +static void privcmd_close(struct vm_area_struct *vma) > +{ > + int count; > + struct xen_pvh_pfn_info *pvhp = vma ? vma->vm_private_data : NULL; > + > + if (!xen_pv_domain() || !pvhp || > + !xen_feature(XENFEAT_auto_translated_physmap)) > + return; > + > + count = xen_unmap_domain_mfn_range(vma, pvhp); > + while (count--) > + free_xenballooned_pages(1, &pvhp->pi_paga[count]); > + kfree(pvhp->pi_paga); > + kfree(pvhp); > +} > + > static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf) > { > printk(KERN_DEBUG "privcmd_fault: vma=%p %lx-%lx, pgoff=%lx, uv=%p\n", > @@ -375,15 +441,12 @@ static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf) > } > > static struct vm_operations_struct privcmd_vm_ops = { > + .close = privcmd_close, > .fault = privcmd_fault > }; > > static int privcmd_mmap(struct file *file, struct vm_area_struct *vma) > { > - /* Unsupported for auto-translate guests. */ > - if (xen_feature(XENFEAT_auto_translated_physmap)) > - return -ENOSYS; > - > /* DONTCOPY is essential for Xen because copy_page_range doesn't know > * how to recreate these mappings */ > vma->vm_flags |= VM_RESERVED | VM_IO | VM_DONTCOPY | VM_PFNMAP; > -- > 1.7.2.3 > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 10:58:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 10:58:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ0BA-0006zd-Rx; Tue, 02 Oct 2012 10:58:20 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ0B9-0006zF-0i for xen-devel@lists.xen.org; Tue, 02 Oct 2012 10:58:19 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1349175466!7047876!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17110 invoked from network); 2 Oct 2012 10:57:47 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 10:57:47 -0000 X-IronPort-AV: E=Sophos;i="4.80,522,1344211200"; d="scan'208";a="14889624" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 10:57:46 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 11:57:46 +0100 Message-ID: <1349175465.650.39.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Matthew Fioravante Date: Tue, 2 Oct 2012 11:57:45 +0100 In-Reply-To: <1348765802-11314-8-git-send-email-matthew.fioravante@jhuapl.edu> References: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu> <1348765802-11314-8-git-send-email-matthew.fioravante@jhuapl.edu> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "samuel.thibault@ens-lyon.org" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 08/11] add tpmfront, tpm_tis, and tpmback drivers to mini-os X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > diff --git a/extras/mini-os/include/tpm_tis.h b/extras/mini-os/include/tpm_tis.h > new file mode 100644 > index 0000000..b463cea > --- /dev/null > +++ b/extras/mini-os/include/tpm_tis.h > @@ -0,0 +1,74 @@ > +/* > + * Copyright (c) 2010-2012 United States Government, as represented by > + * the Secretary of Defense. All rights reserved. > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License version 2 > + * as published by the Free Software Foundation; or, when distributed > + * separately from the Linux kernel or incorporated into other > + * software packages, subject to the following license: > + * > + * Permission is hereby granted, free of charge, to any person obtaining a copy > + * of this source file (the "Software"), to deal in the Software without > + * restriction, including without limitation the rights to use, copy, modify, > + * merge, publish, distribute, sublicense, and/or sell copies of the Software, > + * and to permit persons to whom the Software is furnished to do so, subject to > + * the following conditions: > + * > + * The above copyright notice and this permission notice shall be included in > + * all copies or substantial portions of the Software. > + * > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE > + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS > + * IN THE SOFTWARE. > + * > + * Based upon the files: > + * drivers/char/tpm/tpm_tis.c > + * drivers/char/tpm/tpm.c > + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation Given that then I don't think you have the authority to dual license code owned by IBM as GPL or the MIT style thing above -- these files are subject to the licensing terms of those original files (which looks to be GPL v2 only). It might be acceptable to have a GPL header as the primary followed by a "modifications by Matthew Fioravante/US Gov/Secretary Defense are also licensed under... .MIT thing ...." but I'd want to see a second opinion on that I think. I didn't check all the other licensing thoroughly but I expect similar comments will apply elsewhere too. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 10:58:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 10:58:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ0BA-0006zd-Rx; Tue, 02 Oct 2012 10:58:20 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ0B9-0006zF-0i for xen-devel@lists.xen.org; Tue, 02 Oct 2012 10:58:19 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1349175466!7047876!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17110 invoked from network); 2 Oct 2012 10:57:47 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 10:57:47 -0000 X-IronPort-AV: E=Sophos;i="4.80,522,1344211200"; d="scan'208";a="14889624" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 10:57:46 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 11:57:46 +0100 Message-ID: <1349175465.650.39.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Matthew Fioravante Date: Tue, 2 Oct 2012 11:57:45 +0100 In-Reply-To: <1348765802-11314-8-git-send-email-matthew.fioravante@jhuapl.edu> References: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu> <1348765802-11314-8-git-send-email-matthew.fioravante@jhuapl.edu> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "samuel.thibault@ens-lyon.org" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 08/11] add tpmfront, tpm_tis, and tpmback drivers to mini-os X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > diff --git a/extras/mini-os/include/tpm_tis.h b/extras/mini-os/include/tpm_tis.h > new file mode 100644 > index 0000000..b463cea > --- /dev/null > +++ b/extras/mini-os/include/tpm_tis.h > @@ -0,0 +1,74 @@ > +/* > + * Copyright (c) 2010-2012 United States Government, as represented by > + * the Secretary of Defense. All rights reserved. > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License version 2 > + * as published by the Free Software Foundation; or, when distributed > + * separately from the Linux kernel or incorporated into other > + * software packages, subject to the following license: > + * > + * Permission is hereby granted, free of charge, to any person obtaining a copy > + * of this source file (the "Software"), to deal in the Software without > + * restriction, including without limitation the rights to use, copy, modify, > + * merge, publish, distribute, sublicense, and/or sell copies of the Software, > + * and to permit persons to whom the Software is furnished to do so, subject to > + * the following conditions: > + * > + * The above copyright notice and this permission notice shall be included in > + * all copies or substantial portions of the Software. > + * > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE > + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS > + * IN THE SOFTWARE. > + * > + * Based upon the files: > + * drivers/char/tpm/tpm_tis.c > + * drivers/char/tpm/tpm.c > + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation Given that then I don't think you have the authority to dual license code owned by IBM as GPL or the MIT style thing above -- these files are subject to the licensing terms of those original files (which looks to be GPL v2 only). It might be acceptable to have a GPL header as the primary followed by a "modifications by Matthew Fioravante/US Gov/Secretary Defense are also licensed under... .MIT thing ...." but I'd want to see a second opinion on that I think. I didn't check all the other licensing thoroughly but I expect similar comments will apply elsewhere too. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 11:08:30 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 11:08:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ0Kp-0007TM-JW; Tue, 02 Oct 2012 11:08:19 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ0Kn-0007T7-Ud for xen-devel@lists.xen.org; Tue, 02 Oct 2012 11:08:18 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1349176090!13125040!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5068 invoked from network); 2 Oct 2012 11:08:11 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 11:08:11 -0000 X-IronPort-AV: E=Sophos;i="4.80,522,1344211200"; d="scan'208";a="14889889" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 11:08:10 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 12:08:10 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TJ0Kf-0000Mw-QN; Tue, 02 Oct 2012 11:08:09 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TJ0Kf-0005o6-Mr; Tue, 02 Oct 2012 12:08:09 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20586.51993.446171.870600@mariner.uk.xensource.com> Date: Tue, 2 Oct 2012 12:08:09 +0100 To: Ian Campbell Newsgroups: chiark.mail.xen.devel In-Reply-To: <1349175465.650.39.camel@zakaz.uk.xensource.com> References: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu> <1348765802-11314-8-git-send-email-matthew.fioravante@jhuapl.edu> <1349175465.650.39.camel@zakaz.uk.xensource.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Matthew Fioravante , "samuel.thibault@ens-lyon.org" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 08/11] add tpmfront, tpm_tis, and tpmback drivers to mini-os X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Campbell writes ("Re: [Xen-devel] [PATCH 08/11] add tpmfront, tpm_tis, and tpmback drivers to mini-os"): > > diff --git a/extras/mini-os/include/tpm_tis.h b/extras/mini-os/include/tpm_tis.h > > new file mode 100644 > > index 0000000..b463cea > > --- /dev/null > > +++ b/extras/mini-os/include/tpm_tis.h > > @@ -0,0 +1,74 @@ > > +/* > > + * Copyright (c) 2010-2012 United States Government, as represented by > > + * the Secretary of Defense. All rights reserved. > > + * > > + * This program is free software; you can redistribute it and/or > > + * modify it under the terms of the GNU General Public License version 2 > > + * as published by the Free Software Foundation; or, when distributed > > + * separately from the Linux kernel or incorporated into other > > + * software packages, subject to the following license: > > + * > > + * Permission is hereby granted, free of charge, to any person > > + * obtaining a copy of this source file (the "Software"), to deal [ MIT licence continues ] ... > > + * Based upon the files: > > + * drivers/char/tpm/tpm_tis.c > > + * drivers/char/tpm/tpm.c > > + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation > > Given that then I don't think you have the authority to dual license > code owned by IBM as GPL or the MIT style thing above -- these files are > subject to the licensing terms of those original files (which looks to > be GPL v2 only). Indeed so. This is totally forbidden, I'm afraid. Are you sure you know what you are doing with the licensing here ? Do you have anyone nearby who could help you with this ? The basic principle is that the existing source file licence must remain unchanged. > It might be acceptable to have a GPL header as the primary followed by a > "modifications by Matthew Fioravante/US Gov/Secretary Defense are also > licensed under... .MIT thing ...." but I'd want to see a second opinion > on that I think. This is in theory possible but in practice not a good idea. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 11:08:30 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 11:08:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ0Kp-0007TM-JW; Tue, 02 Oct 2012 11:08:19 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ0Kn-0007T7-Ud for xen-devel@lists.xen.org; Tue, 02 Oct 2012 11:08:18 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1349176090!13125040!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5068 invoked from network); 2 Oct 2012 11:08:11 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 11:08:11 -0000 X-IronPort-AV: E=Sophos;i="4.80,522,1344211200"; d="scan'208";a="14889889" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 11:08:10 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 12:08:10 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TJ0Kf-0000Mw-QN; Tue, 02 Oct 2012 11:08:09 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TJ0Kf-0005o6-Mr; Tue, 02 Oct 2012 12:08:09 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20586.51993.446171.870600@mariner.uk.xensource.com> Date: Tue, 2 Oct 2012 12:08:09 +0100 To: Ian Campbell Newsgroups: chiark.mail.xen.devel In-Reply-To: <1349175465.650.39.camel@zakaz.uk.xensource.com> References: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu> <1348765802-11314-8-git-send-email-matthew.fioravante@jhuapl.edu> <1349175465.650.39.camel@zakaz.uk.xensource.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Matthew Fioravante , "samuel.thibault@ens-lyon.org" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 08/11] add tpmfront, tpm_tis, and tpmback drivers to mini-os X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Campbell writes ("Re: [Xen-devel] [PATCH 08/11] add tpmfront, tpm_tis, and tpmback drivers to mini-os"): > > diff --git a/extras/mini-os/include/tpm_tis.h b/extras/mini-os/include/tpm_tis.h > > new file mode 100644 > > index 0000000..b463cea > > --- /dev/null > > +++ b/extras/mini-os/include/tpm_tis.h > > @@ -0,0 +1,74 @@ > > +/* > > + * Copyright (c) 2010-2012 United States Government, as represented by > > + * the Secretary of Defense. All rights reserved. > > + * > > + * This program is free software; you can redistribute it and/or > > + * modify it under the terms of the GNU General Public License version 2 > > + * as published by the Free Software Foundation; or, when distributed > > + * separately from the Linux kernel or incorporated into other > > + * software packages, subject to the following license: > > + * > > + * Permission is hereby granted, free of charge, to any person > > + * obtaining a copy of this source file (the "Software"), to deal [ MIT licence continues ] ... > > + * Based upon the files: > > + * drivers/char/tpm/tpm_tis.c > > + * drivers/char/tpm/tpm.c > > + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation > > Given that then I don't think you have the authority to dual license > code owned by IBM as GPL or the MIT style thing above -- these files are > subject to the licensing terms of those original files (which looks to > be GPL v2 only). Indeed so. This is totally forbidden, I'm afraid. Are you sure you know what you are doing with the licensing here ? Do you have anyone nearby who could help you with this ? The basic principle is that the existing source file licence must remain unchanged. > It might be acceptable to have a GPL header as the primary followed by a > "modifications by Matthew Fioravante/US Gov/Secretary Defense are also > licensed under... .MIT thing ...." but I'd want to see a second opinion > on that I think. This is in theory possible but in practice not a good idea. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 11:25:17 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 11:25:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ0b0-0007kQ-66; Tue, 02 Oct 2012 11:25:02 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ0ay-0007kL-5P for Xen-devel@lists.xensource.com; Tue, 02 Oct 2012 11:25:00 +0000 Received: from [85.158.143.35:46748] by server-2.bemta-4.messagelabs.com id 27/DA-06610-B0FCA605; Tue, 02 Oct 2012 11:24:59 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1349177098!19284341!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13541 invoked from network); 2 Oct 2012 11:24:58 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 11:24:58 -0000 X-IronPort-AV: E=Sophos;i="4.80,522,1344211200"; d="scan'208";a="14890312" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 11:24:57 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 12:24:57 +0100 Date: Tue, 2 Oct 2012 12:23:58 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Mukesh Rathor In-Reply-To: <20121001144455.3ba7e10b@mantra.us.oracle.com> Message-ID: References: <20120921121556.1a0ea8af@mantra.us.oracle.com> <20121001143244.36b4c270@mantra.us.oracle.com> <20121001144455.3ba7e10b@mantra.us.oracle.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Ian Campbell , Konrad Rzeszutek Wilk , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, 1 Oct 2012, Mukesh Rathor wrote: > On Mon, 1 Oct 2012 14:32:44 -0700 > Mukesh Rathor wrote: > > > > > > > + struct pvh_remap_data *remapp = data; > > > > + struct xen_pvh_pfn_info *pvhp = remapp->pvhinfop; > > > > + unsigned long pfn = > > > > page_to_pfn(pvhp->pi_paga[pvhp->pi_next_todo++]); > > > > + pte_t pteval = pte_mkspecial(pfn_pte(pfn, remapp->prot)); > > > > + > > > > + if ((rc=pvh_add_to_xen_p2m(pfn, remapp->fgmfn, > > > > remapp->domid))) > > > > + return rc; > > > > + native_set_pte(ptep, pteval); > > > > > > Do we actually need the pte to be "special"? > > > I would think that being in the guest p2m, it is actually quite a > > > normal page. > > > > Hmm... well, doesn't like removing "special": > > > > > > BUG: Bad page map in process xl pte:800000027b57b467 pmd:2b408d067 > > page:ffffea0008afb2e8 count:1 mapcount:-1 mapping: (null) > > index:0x0 page flags: 0x40000000000414(referenced|dirty|reserved) > > addr:00007fb4345b0000 vm_flags:000a44fb anon_vma: (null) > > mapping:ffff88003911a3d0 index:4 vma->vm_ops->fault: > > privcmd_fault+0x0/0x40 vma->vm_file->f_op->mmap: privcmd_mmap+0x0/0x30 > > Pid: 2737, comm: xl Tainted: G B 3.6.0-rc6-merge+ #17 > > Call Trace: > > [] print_bad_pte+0x1dc/0x250 > > [] zap_pte_range+0x45e/0x4c0 > > [] unmap_page_range+0x1ae/0x310 > > [] unmap_single_vma+0x61/0xe0 > > [] unmap_vmas+0x54/0xa0 > > [] unmap_region+0xab/0x120 > > [] ? privcmd_ioctl+0x93/0x100 > > [] do_munmap+0x25d/0x380 > > > > This from: > > if (unlikely(page_mapcount(page) < 0)) > > print_bad_pte(vma, addr, ptent, page); > > > > > > So, the mapcount must be not be getting set in "normal" case properly > > it appears. Marking it special causes it so skip few things. > > Debugging... > > Shall I just leave it special for now, and come back and revisit > this later? special is going to create troubles if somebody starts using these pages in unexpected ways (for example dma from hardware ot gupf). Also I fail to see how this case is any different from mapping pages using gntdev (see gntdev_mmap) that works fine without special. Maybe we are not setting some vm_flags that we are supposed to set (VM_RESERVED | VM_IO | VM_DONTCOPY)? I see that we are setting them in privcmd_mmap but not in privcmd_ioctl_mmap_batch... _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 11:25:17 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 11:25:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ0b0-0007kQ-66; Tue, 02 Oct 2012 11:25:02 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ0ay-0007kL-5P for Xen-devel@lists.xensource.com; Tue, 02 Oct 2012 11:25:00 +0000 Received: from [85.158.143.35:46748] by server-2.bemta-4.messagelabs.com id 27/DA-06610-B0FCA605; Tue, 02 Oct 2012 11:24:59 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1349177098!19284341!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13541 invoked from network); 2 Oct 2012 11:24:58 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 11:24:58 -0000 X-IronPort-AV: E=Sophos;i="4.80,522,1344211200"; d="scan'208";a="14890312" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 11:24:57 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 12:24:57 +0100 Date: Tue, 2 Oct 2012 12:23:58 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Mukesh Rathor In-Reply-To: <20121001144455.3ba7e10b@mantra.us.oracle.com> Message-ID: References: <20120921121556.1a0ea8af@mantra.us.oracle.com> <20121001143244.36b4c270@mantra.us.oracle.com> <20121001144455.3ba7e10b@mantra.us.oracle.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Ian Campbell , Konrad Rzeszutek Wilk , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, 1 Oct 2012, Mukesh Rathor wrote: > On Mon, 1 Oct 2012 14:32:44 -0700 > Mukesh Rathor wrote: > > > > > > > + struct pvh_remap_data *remapp = data; > > > > + struct xen_pvh_pfn_info *pvhp = remapp->pvhinfop; > > > > + unsigned long pfn = > > > > page_to_pfn(pvhp->pi_paga[pvhp->pi_next_todo++]); > > > > + pte_t pteval = pte_mkspecial(pfn_pte(pfn, remapp->prot)); > > > > + > > > > + if ((rc=pvh_add_to_xen_p2m(pfn, remapp->fgmfn, > > > > remapp->domid))) > > > > + return rc; > > > > + native_set_pte(ptep, pteval); > > > > > > Do we actually need the pte to be "special"? > > > I would think that being in the guest p2m, it is actually quite a > > > normal page. > > > > Hmm... well, doesn't like removing "special": > > > > > > BUG: Bad page map in process xl pte:800000027b57b467 pmd:2b408d067 > > page:ffffea0008afb2e8 count:1 mapcount:-1 mapping: (null) > > index:0x0 page flags: 0x40000000000414(referenced|dirty|reserved) > > addr:00007fb4345b0000 vm_flags:000a44fb anon_vma: (null) > > mapping:ffff88003911a3d0 index:4 vma->vm_ops->fault: > > privcmd_fault+0x0/0x40 vma->vm_file->f_op->mmap: privcmd_mmap+0x0/0x30 > > Pid: 2737, comm: xl Tainted: G B 3.6.0-rc6-merge+ #17 > > Call Trace: > > [] print_bad_pte+0x1dc/0x250 > > [] zap_pte_range+0x45e/0x4c0 > > [] unmap_page_range+0x1ae/0x310 > > [] unmap_single_vma+0x61/0xe0 > > [] unmap_vmas+0x54/0xa0 > > [] unmap_region+0xab/0x120 > > [] ? privcmd_ioctl+0x93/0x100 > > [] do_munmap+0x25d/0x380 > > > > This from: > > if (unlikely(page_mapcount(page) < 0)) > > print_bad_pte(vma, addr, ptent, page); > > > > > > So, the mapcount must be not be getting set in "normal" case properly > > it appears. Marking it special causes it so skip few things. > > Debugging... > > Shall I just leave it special for now, and come back and revisit > this later? special is going to create troubles if somebody starts using these pages in unexpected ways (for example dma from hardware ot gupf). Also I fail to see how this case is any different from mapping pages using gntdev (see gntdev_mmap) that works fine without special. Maybe we are not setting some vm_flags that we are supposed to set (VM_RESERVED | VM_IO | VM_DONTCOPY)? I see that we are setting them in privcmd_mmap but not in privcmd_ioctl_mmap_batch... _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 12:05:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 12:05:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ1EB-0000cE-Ku; Tue, 02 Oct 2012 12:05:31 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ1E9-0000bz-Uu for xen-devel@lists.xen.org; Tue, 02 Oct 2012 12:05:30 +0000 Received: from [85.158.137.99:57022] by server-4.bemta-3.messagelabs.com id A3/85-14155-988DA605; Tue, 02 Oct 2012 12:05:29 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-16.tower-217.messagelabs.com!1349179528!19942887!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MjMzMTI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32453 invoked from network); 2 Oct 2012 12:05:28 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-16.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 12:05:28 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id 9384924E5; Tue, 2 Oct 2012 15:05:27 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 3DAB720058; Tue, 2 Oct 2012 15:05:27 +0300 (EEST) Date: Tue, 2 Oct 2012 15:05:27 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: "Teo En Ming (Zhang Enming)" Message-ID: <20121002120527.GK8912@reaktio.net> References: <506AAF6D.4060409@gmail.com> <506AB739.6030705@laukamp.me> <506ABFC5.9050600@gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <506ABFC5.9050600@gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "xen-users@lists.xen.org" , "xen-devel@lists.xen.org" , Lukas Laukamp Subject: Re: [Xen-devel] [Xen-users] Xen 4.2.0 does not have the file passthrough.c X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, Oct 02, 2012 at 06:19:49PM +0800, Teo En Ming (Zhang Enming) wrote: > On 02/10/2012 17:43, Lukas Laukamp wrote: > >Am 02.10.2012 11:10, schrieb Teo En Ming (Zhang Enming): > >>Hi, > >> > >>Xen 4.2.0 official tarball does not have the file passthrough.c. > >> > >>Does it mean that Xen 4.2.0 does not support vga passthrough? > >> > > > >Hey, > > > >Xen 4.2.0 should be able to do VGA and PCI passtrough. You should > >see information about the possibility of this in the xm dmesg/xl > >dmesg output. I backported the Xen 4.2.0 from Debian experimental > >to squeeze and it have this feature. > > > >Best Regards > > > > Hi, > > I was trying to patch the file pass-through.c when the patch file > complained that pass-through.c cannot be found, meaning that Xen > 4.2.0 does not support VGA passthrough. > pass-through.c is most probably in Qemu, not in Xen. -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 12:05:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 12:05:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ1EB-0000cE-Ku; Tue, 02 Oct 2012 12:05:31 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ1E9-0000bz-Uu for xen-devel@lists.xen.org; Tue, 02 Oct 2012 12:05:30 +0000 Received: from [85.158.137.99:57022] by server-4.bemta-3.messagelabs.com id A3/85-14155-988DA605; Tue, 02 Oct 2012 12:05:29 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-16.tower-217.messagelabs.com!1349179528!19942887!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MjMzMTI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32453 invoked from network); 2 Oct 2012 12:05:28 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-16.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 12:05:28 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id 9384924E5; Tue, 2 Oct 2012 15:05:27 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 3DAB720058; Tue, 2 Oct 2012 15:05:27 +0300 (EEST) Date: Tue, 2 Oct 2012 15:05:27 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: "Teo En Ming (Zhang Enming)" Message-ID: <20121002120527.GK8912@reaktio.net> References: <506AAF6D.4060409@gmail.com> <506AB739.6030705@laukamp.me> <506ABFC5.9050600@gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <506ABFC5.9050600@gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "xen-users@lists.xen.org" , "xen-devel@lists.xen.org" , Lukas Laukamp Subject: Re: [Xen-devel] [Xen-users] Xen 4.2.0 does not have the file passthrough.c X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, Oct 02, 2012 at 06:19:49PM +0800, Teo En Ming (Zhang Enming) wrote: > On 02/10/2012 17:43, Lukas Laukamp wrote: > >Am 02.10.2012 11:10, schrieb Teo En Ming (Zhang Enming): > >>Hi, > >> > >>Xen 4.2.0 official tarball does not have the file passthrough.c. > >> > >>Does it mean that Xen 4.2.0 does not support vga passthrough? > >> > > > >Hey, > > > >Xen 4.2.0 should be able to do VGA and PCI passtrough. You should > >see information about the possibility of this in the xm dmesg/xl > >dmesg output. I backported the Xen 4.2.0 from Debian experimental > >to squeeze and it have this feature. > > > >Best Regards > > > > Hi, > > I was trying to patch the file pass-through.c when the patch file > complained that pass-through.c cannot be found, meaning that Xen > 4.2.0 does not support VGA passthrough. > pass-through.c is most probably in Qemu, not in Xen. -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 12:11:37 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 12:11:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ1Jm-000127-3E; Tue, 02 Oct 2012 12:11:18 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ1Jk-000121-H6 for Xen-devel@lists.xen.org; Tue, 02 Oct 2012 12:11:17 +0000 Received: from [85.158.143.35:32415] by server-1.bemta-4.messagelabs.com id EF/FF-05684-3E9DA605; Tue, 02 Oct 2012 12:11:15 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1349179868!14577554!1 X-Originating-IP: [209.85.160.173] X-SpamReason: No, hits=1.4 required=7.0 tests=BODY_RANDOM_LONG, HTML_40_50, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, ML_RADAR_SPEW_LINKS_23, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8573 invoked from network); 2 Oct 2012 12:11:09 -0000 Received: from mail-gh0-f173.google.com (HELO mail-gh0-f173.google.com) (209.85.160.173) by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 12:11:09 -0000 Received: by ghy16 with SMTP id 16so1869648ghy.32 for ; Tue, 02 Oct 2012 05:11:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oxsFxO/pbW77JqLKwHo3ZM9eK+wlLo/mp+c89GzYwEo=; b=G6IB35PQhj3NlpJX2ME/c3hn09zgRUjBUjWz6xJb4zzmRXaW/o2MVqZTI/n748ly5N Uml2rmfCOwWH5cSiM0mO2vj2nd/5pTwnKWeHNWRMDKeZ7uGNSfzJoR5r7+ieyd9V5RKv o+2cvyimuD/H8TUtmXsKfQSudHI0MQ3Wok6zxa8y+KkXrVJsqiOGgxbd5tZ/Wwadmqms BshiOr0R8HGpao2Mm7tRj2p7eFDC3x/Wee2Q3RgrmjX9gnYBAkFvaNnJPEJGVrAoIxiF LgUJqQ3DHAAyQTrPwEiEjyBPZQh8D16Rgejmndy5q47HVxzxHJohOBq3BHvxgR6cgQ/K tZUw== MIME-Version: 1.0 Received: by 10.236.151.99 with SMTP id a63mr18355479yhk.120.1349179867929; Tue, 02 Oct 2012 05:11:07 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Tue, 2 Oct 2012 05:11:07 -0700 (PDT) In-Reply-To: References: <20121001062232.GV8912@reaktio.net> <20121001144042.GC8912@reaktio.net> <20121001160117.GD8912@reaktio.net> <20121001164757.GF8912@reaktio.net> <20121001182437.GG8912@reaktio.net> Date: Tue, 2 Oct 2012 15:11:07 +0300 Message-ID: From: Valtteri Kiviniemi To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= Cc: Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.0.4, kernel 3.5.0 HVM crash and kernel BUG X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7769507901113686720==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============7769507901113686720== Content-Type: multipart/alternative; boundary=20cf303a2e35c41b0104cb126a25 --20cf303a2e35c41b0104cb126a25 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Another update: I wanted to check that if a Linux HVM would boot with working VNC console, so I tried to launch a Debian Squeeze installer on HVM. It refused to start ant told me that vbd hotplug scripts were not working. After that failure even the Windows domU would not anymore start which was previously starting ok. The hotplug scripts also starts hanging on the processes. root 9401 0.1 0.1 17700 1640 ? S 15:05 0:00 /bin/bash /etc/xen/scripts/xen-hotplug-cleanup root 9441 0.1 0.1 17700 1644 ? S 15:05 0:00 /bin/bash /etc/xen/scripts/xen-hotplug-cleanup root 9481 0.1 0.1 17700 1640 ? S 15:05 0:00 /bin/bash /etc/xen/scripts/xen-hotplug-cleanup root 9560 0.1 0.1 17700 1640 ? S 15:05 0:00 /bin/bash /etc/xen/scripts/xen-hotplug-cleanup root 10738 0.1 0.1 17696 1636 ? S 15:05 0:00 /bin/bash /etc/xen/scripts/xen-hotplug-cleanup root 10747 0.1 0.1 17792 1736 ? S 15:05 0:00 /bin/bash /etc/xen/scripts/block remove root 11286 0.0 0.0 4080 324 ? S 15:06 0:00 sleep 1 root 11290 0.0 0.0 4080 324 ? S 15:06 0:00 sleep 1 root 11294 0.0 0.0 4080 324 ? S 15:06 0:00 sleep 1 root 11298 0.0 0.0 4080 324 ? S 15:06 0:00 sleep 1 root 11302 0.0 0.0 4080 320 ? S 15:06 0:00 sleep 1 root 11306 0.0 0.0 4080 320 ? S 15:06 0:00 sleep 1 Then I did a xm destroy and I had again the kernel BUG on dmesg. So it seems that the problem is not fixed by using 3.6.0. Udev version is 175-7. 2012/10/1 Valtteri Kiviniemi > Hi, > > CPU: Intel Core i7-3770 3.4GHz > http://ark.intel.com/products/65719/ > > MB: Intel DQ77MK (latest bios updated) > > http://www.intel.com/content/www/us/en/motherboards/desktop-motherboards/= desktop-board-dq77mk.html > > Memory: 32GB (4 x 8GB DDR3-1600MHz) > > Host is Debian wheezy/testing, Xen 4.0.4 and latest 3.6.0 kernel. > > Noticed also some errors in xm dmesg: > > root@xen-2:~# xm dmesg > > (XEN) Xen version 4.0.4 (root@dataproof.fi) (gcc version 4.7.1 (Debian > 4.7.1-7) ) Sun Sep 30 20:28:26 EEST 2012 > (XEN) Latest ChangeSet: unavailable > (XEN) Bootloader: GNU GRUB 0.97 > (XEN) Command line: dom0_mem=3D1280M cpufreq=3Dxen clocksource=3Dhpet > (XEN) Video information: > (XEN) VGA is text mode 80x25, font 8x16 > (XEN) VBE/DDC methods: none; EDID transfer time: 0 seconds > (XEN) EDID info not retrieved because no DDC retrieval method detected > (XEN) Disc information: > (XEN) Found 4 MBR signatures > (XEN) Found 4 EDD information structures > (XEN) Xen-e820 RAM map: > (XEN) 0000000000000000 - 000000000009d800 (usable) > (XEN) 000000000009d800 - 00000000000a0000 (reserved) > (XEN) 00000000000e0000 - 0000000000100000 (reserved) > (XEN) 0000000000100000 - 0000000020000000 (usable) > (XEN) 0000000020000000 - 0000000020200000 (reserved) > (XEN) 0000000020200000 - 0000000040004000 (usable) > (XEN) 0000000040004000 - 0000000040005000 (reserved) > (XEN) 0000000040005000 - 00000000dbe44000 (usable) > (XEN) 00000000dbe44000 - 00000000dc2d7000 (reserved) > (XEN) 00000000dc2d7000 - 00000000dc2e7000 (ACPI data) > (XEN) 00000000dc2e7000 - 00000000dc40c000 (ACPI NVS) > (XEN) 00000000dc40c000 - 00000000dc6af000 (reserved) > (XEN) 00000000dc6af000 - 00000000dc6b0000 (usable) > (XEN) 00000000dc6b0000 - 00000000dc6f3000 (ACPI NVS) > (XEN) 00000000dc6f3000 - 00000000dd000000 (usable) > (XEN) 00000000dd800000 - 00000000dfa00000 (reserved) > (XEN) 00000000f8000000 - 00000000fc000000 (reserved) > (XEN) 00000000fec00000 - 00000000fec01000 (reserved) > (XEN) 00000000fed00000 - 00000000fed04000 (reserved) > (XEN) 00000000fed1c000 - 00000000fed20000 (reserved) > (XEN) 00000000fee00000 - 00000000fee01000 (reserved) > (XEN) 00000000ff000000 - 0000000100000000 (reserved) > (XEN) 0000000100000000 - 000000081e600000 (usable) > (XEN) ACPI: RSDP 000F0490, 0024 (r2 INTEL) > (XEN) ACPI: XSDT DC2DB080, 007C (r1 INTEL DQ77MK 32 AMI 1001= 3) > (XEN) ACPI: FACP DC2E51F0, 010C (r5 INTEL DQ77MK 32 AMI 1001= 3) > (XEN) ACPI Warning (tbfadt-0232): FADT (revision 5) is longer than ACPI > 2.0 version, truncating length 0x10C to 0xF4 [20070126] > (XEN) ACPI: DSDT DC2DB188, A061 (r2 INTEL DQ77MK 32 INTL 2005111= 7) > (XEN) ACPI: FACS DC40A080, 0040 > (XEN) ACPI: APIC DC2E5300, 0092 (r3 INTEL DQ77MK 32 AMI 1001= 3) > (XEN) ACPI: FPDT DC2E5398, 0044 (r1 INTEL DQ77MK 32 AMI 1001= 3) > (XEN) ACPI: TCPA DC2E53E0, 0032 (r2 INTEL DQ77MK 32 MSFT 100001= 3) > (XEN) ACPI: MCFG DC2E5418, 003C (r1 INTEL DQ77MK 32 MSFT 9= 7) > (XEN) ACPI: HPET DC2E5458, 0038 (r1 INTEL DQ77MK 32 AMI. = 5) > (XEN) ACPI: SSDT DC2E5490, 036D (r1 INTEL DQ77MK 32 INTL 2009111= 2) > (XEN) ACPI: SSDT DC2E5800, 09AA (r1 INTEL DQ77MK 32 INTL 2005111= 7) > (XEN) ACPI: SSDT DC2E61B0, 0A92 (r1 INTEL DQ77MK 32 INTL 2005111= 7) > (XEN) ACPI: DMAR DC2E6C48, 00B8 (r1 INTEL DQ77MK 32 INTL = 1) > (XEN) ACPI: ASF! DC2E6D00, 00A5 (r32 INTEL DQ77MK 32 TFSM > F4240) > (XEN) System RAM: 32682MB (33467320kB) > (XEN) Domain heap initialised > (XEN) ACPI: 32/64X FACS address mismatch in FADT - > dc40a080/0000000000000000, using 32 > (XEN) Processor #0 7:10 APIC version 21 > (XEN) Processor #2 7:10 APIC version 21 > (XEN) Processor #4 7:10 APIC version 21 > (XEN) Processor #6 7:10 APIC version 21 > (XEN) Processor #1 7:10 APIC version 21 > (XEN) Processor #3 7:10 APIC version 21 > (XEN) Processor #5 7:10 APIC version 21 > (XEN) Processor #7 7:10 APIC version 21 > (XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 > (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs > (XEN) Switched to APIC driver x2apic_cluster. > (XEN) x2APIC mode enabled. > (XEN) Using scheduler: SMP Credit Scheduler (credit) > (XEN) Detected 3392.369 MHz processor. > (XEN) Initing memory sharing. > (XEN) VMX: Supported advanced features: > (XEN) - APIC MMIO access virtualisation > (XEN) - APIC TPR shadow > (XEN) - Extended Page Tables (EPT) > (XEN) - Virtual-Processor Identifiers (VPID) > (XEN) - Virtual NMI > (XEN) - MSR direct-access bitmap > (XEN) - Unrestricted Guest > (XEN) EPT supports 2MB super page. > (XEN) HVM: ASIDs enabled. > (XEN) HVM: VMX enabled > (XEN) HVM: Hardware Assisted Paging detected. > (XEN) Intel VT-d Snoop Control not enabled. > (XEN) Intel VT-d Dom0 DMA Passthrough not enabled. > (XEN) Intel VT-d Queued Invalidation enabled. > (XEN) Intel VT-d Interrupt Remapping enabled. > (XEN) I/O virtualisation enabled > (XEN) - Dom0 mode: Relaxed > (XEN) Enabled directed EOI with ioapic_ack_old on! > (XEN) Total of 8 processors activated. > (XEN) ENABLING IO-APIC IRQs > (XEN) -> Using old ACK method > (XEN) TSC is reliable, synchronization unnecessary > (XEN) Platform timer appears to have unexpectedly wrapped 1 times. > (XEN) Platform timer is 14.318MHz HPET > (XEN) Allocated console ring of 16 KiB. > (XEN) Brought up 8 CPUs > (XEN) *** LOADING DOMAIN 0 *** > (XEN) Xen kernel: 64-bit, lsb, compat32 > (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1ae7000 > (XEN) PHYSICAL MEMORY ARRANGEMENT: > (XEN) Dom0 alloc.: 0000000804000000->0000000806000000 (319488 pages to > be allocated) > (XEN) VIRTUAL MEMORY ARRANGEMENT: > (XEN) Loaded kernel: ffffffff81000000->ffffffff81ae7000 > (XEN) Init. ramdisk: ffffffff81ae7000->ffffffff81ae7000 > (XEN) Phys-Mach map: ffffffff81ae7000->ffffffff81d67000 > (XEN) Start info: ffffffff81d67000->ffffffff81d674b4 > (XEN) Page tables: ffffffff81d68000->ffffffff81d7b000 > (XEN) Boot stack: ffffffff81d7b000->ffffffff81d7c000 > (XEN) TOTAL: ffffffff80000000->ffffffff82000000 > (XEN) ENTRY ADDRESS: ffffffff815e3210 > (XEN) Dom0 has maximum 8 VCPUs > (XEN) [VT-D]iommu.c:718: BIOS did not enable IGD for VT properly. > Disabling IGD VT-d engine. > (XEN) Scrubbing Free RAM: done. > (XEN) Xen trace buffers: disabled > (XEN) Std. Loglevel: Errors and warnings > (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings) > (XEN) Xen is relinquishing VGA console. > (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input > to Xen) > (XEN) Freed 172kB init memory. > (XEN) traps.c:2333:d0 Domain attempted WRMSR 000000000000008b from > 00000012:00000000 to 00000000:00000000. > > - Valtteri > > > 2012/10/1 Pasi K=E4rkk=E4inen > >> On Mon, Oct 01, 2012 at 09:12:50PM +0300, Valtteri Kiviniemi wrote: >> > Hi, >> > >> > Lowering memory or vcpu's does not help, problem is the same. I >> originally >> > installed Xen 4.2.0 and the problem was same on that too. Then I >> > downgraded back to 4.0.4 since I thought that this might be a bug o= n >> > 4.2.0. I have been previously running Windows Server 2008 R2 >> succesfully >> > on Xen 4.0.x on different hardware with this same config. Hyperviso= r >> is >> > 64bit and windows is 64bit. >> > >> > Any ideas what to try next? >> > >> >> What kind of hardware is that? >> >> xen.org automated testing regularly tests Windows VMs, and it works OK >> there. >> >> -- Pasi >> >> > Ps. qemu-dm.log is the following: >> > >> > domid: 10 >> > config qemu network with xen bridge for tap10.0 xenbr0 >> > Using file /dev/virtuals/ts in read-write mode >> > Using file /media/iso/windows_server_2008_r2_sp1.iso in read-only >> mode >> > Watching /local/domain/0/device-model/10/logdirty/cmd >> > Watching /local/domain/0/device-model/10/command >> > qemu_map_cache_init nr_buckets =3D 10000 size 4194304 >> > shared page at pfn feffd >> > buffered io page at pfn feffb >> > Guest uuid =3D 52f19e23-2955-c27d-a22c-60c5d8c60d5a >> > Time offset set 0 >> > populating video RAM at ff000000 >> > mapping video RAM from ff000000 >> > Register xen platform. >> > Done register platform. >> > platform_fixed_ioport: changed ro/rw state of ROM memory area. now >> is rw >> > state. >> > xs_read(/local/domain/0/device-model/10/xen_extended_power_mgmt): >> read >> > error >> > medium change watch on `hdc' (index: 1): >> > /media/iso/windows_server_2008_r2_sp1.iso >> > I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size:= 0 >> > Log-dirty: no command yet. >> > xs_read(/local/domain/10/log-throttling): read error >> > qemu: ignoring not-understood drive `/local/domain/10/log-throttlin= g' >> > medium change watch on `/local/domain/10/log-throttling' - unknown >> device, >> > ignored >> > cirrus vga map change while on lfb mode >> > mapping vram to f0000000 - f0400000 >> > platform_fixed_ioport: changed ro/rw state of ROM memory area. now >> is rw >> > state. >> > platform_fixed_ioport: changed ro/rw state of ROM memory area. now >> is ro >> > state. >> > >> > 2012/10/1 Pasi K=E4rkk=E4inen <[1]pasik@iki.fi> >> > >> > On Mon, Oct 01, 2012 at 07:23:44PM +0300, Valtteri Kiviniemi wrot= e: >> > > Hi, >> > > >> > > I have tried other config files, but the problem is the same= . >> At >> > the >> > > moment I'm using a config file from another server where I >> have a >> > working >> > > Windows Server 2008 R2 installation, so I dont think that >> there is >> > > anything wrong with my config: >> > > >> > >> > Did you try with less vcpus, for example 2 ? >> > how about with less memory, say 2 GB ? >> > >> > Did you try with later Xen versions? Is that a 32bit Xen, or 64bi= t >> Xen >> > hypervisor? >> > >> > -- Pasi >> > > kernel =3D "/usr/lib/xen/boot/hvmloader" >> > > builder =3D "hvm" >> > > shadow_memory =3D "8" >> > > memory =3D "4096" >> > > name =3D "ts" >> > > vcpus =3D "8" >> > > cpus =3D ["0", "1", "2", "3", "4", "5", "6", "7"] >> > > pae =3D "1" >> > > acpi =3D "1" >> > > apic =3D "1" >> > > vfb =3D [ 'type=3Dvnc, vnclisten=3D10.100.100.50, vncpasswd= =3Dxxx' ] >> > > xen_extended_power_mgmt =3D "0" >> > > vif =3D [ "type=3Dioemu, mac=3D00:16:3e:d7:d7:5d, bridge=3Dx= enbr0" ] >> > > disk =3D [ "phy:/dev/virtuals/ts,hda,w", >> > > "file:/media/iso/windows_server_2008_r2_sp1.iso,hdc:cdrom,r"= ] >> > > on_poweroff =3D "destroy" >> > > on_reboot =3D "restart" >> > > on_crash =3D "restart" >> > > viridian =3D "1" >> > > device_model =3D "/usr/lib/xen/bin/qemu-dm" >> > > boot =3D "dc" >> > > snapshot =3D "0" >> > > vncconsole =3D "1" >> > > sdl =3D "0" >> > > opengl =3D "0" >> > > vnc =3D "1" >> > > nographic =3D "0" >> > > stdvga =3D "0" >> > > tsc_mode =3D "1" >> > > monitor =3D "0" >> > > localtime =3D "1" >> > > usb =3D "0" >> > > keymap =3D "fi" >> > > xen_platform_pci =3D "1" >> > > pci_msitranslate =3D "1" >> > > pci_power_mgmt =3D "0" >> > > >> > > 2012/10/1 Pasi K=E4rkk=E4inen <[1][2]pasik@iki.fi> >> > > >> > > On Mon, Oct 01, 2012 at 06:46:08PM +0300, Valtteri Kivinie= mi >> > wrote: >> > > > Hi, >> > > > >> > > > Yes, I have viridian=3D1 on my domU config. >> > > > >> > > >> > > Try with some known good domU configfile. >> > > >> > > -- Pasi >> > > > 2012/10/1 Pasi K=E4rkk=E4inen <[1][2][3]pasik@iki.fi> >> > > > >> > > > On Mon, Oct 01, 2012 at 05:06:53PM +0300, Valtteri >> > Kiviniemi >> > > wrote: >> > > > > Hi, >> > > > > >> > > > > I'm now using 3.6.0 and can't reproduce that >> crash >> > anymore, >> > > so it >> > > > seems >> > > > > that it was a kernel bug. >> > > > > >> > > > >> > > > OK. >> > > > > However I'm still getting black screen on VNC >> > > > > when trying to install Windows Server 2008 R2. >> I can >> > see the >> > > > "windows is >> > > > > loading files" screen but after the installer >> starts >> > the VNC >> > > > display goes >> > > > > black. >> > > > > >> > > > > Any ideas? >> > > > > >> > > > >> > > > Do you have viridian=3D1 specified for the windows = vm? >> > > > >> > > > -- Pasi >> > > > >> > > > > - Valtteri >> > > > > >> > > > > 2012/10/1 Pasi K=E4rkk=E4inen <[1][2][3][4] >> pasik@iki.fi> >> > > > > >> > > > > On Sun, Sep 30, 2012 at 11:18:03PM +0300, >> Valtteri >> > > Kiviniemi >> > > > wrote: >> > > > > > Hi, >> > > > > > >> > > > > >> > > > > Hello, >> > > > > > I'm trying to get Windows Server 2008 R= 2 >> > installation >> > > > booting on >> > > > > Xen >> > > > > > 4.0.4. Using the following config: >> > > > > > >> > > > > >> > > > > >> > > > > > >> > > > > > The domU will start booting just fine, >> but >> > after a >> > > few >> > > > minutes the >> > > > > VNC >> > > > > > screen goes black. After that when >> typing "xm >> > destroy >> > > ts" it >> > > > will >> > > > > trigger >> > > > > > a kernel BUG: >> > > > > > >> > > > > > BUG: unable to handle kernel NULL point= er >> > dereference >> > > at >> > > > > 0000000000000030 >> > > > > > IP: [] iput+0x3e/0x19= 5 >> > > > > > PGD 0 >> > > > > > Oops: 0000 [#1] SMP >> > > > > > CPU 6 >> > > > > > Pid: 3571, comm: qemu-dm Not tainted >> > 3.5.0-dom0 #1 >> > > > > >> > > > > First of all upgrade to latest 3.5.x Linux >> kernel >> > release >> > > .. so >> > > > at least >> > > > > 3.5.4. >> > > > > >> > > > > -- Pasi >> > > > > >> > > > > > /DQ77MK >> > > > > > RIP: e030:[] >> > [] >> > > > > iput+0x3e/0x195 >> > > > > > RSP: e02b:ffff8800389ffbf8 EFLAGS: >> 00010246 >> > > > > > RAX: 0000000000000001 RBX: >> ffff8800377b0720 >> > RCX: >> > > > ffff8800501c0000 >> > > > > > RDX: ffff8800501c0000 RSI: >> ffff8800377b0790 >> > RDI: >> > > > ffff8800377b0790 >> > > > > > RBP: 0000000000000000 R08: >> ffffffff815cdd00 >> > R09: >> > > > 0000000000000016 >> > > > > > R10: fefefefefefefeff R11: >> ffff8800377b0400 >> > R12: >> > > > 00000001000a3e0c >> > > > > > R13: 0000000000000000 R14: >> 00000001000a3e0c >> > R15: >> > > > ffff8800389ffc28 >> > > > > > FS: 00007f1af70a8700(0000) >> > GS:ffff880050180000(0000) >> > > > > > knlGS:0000000000000000 >> > > > > > CS: e033 DS: 0000 ES: 0000 CR0: >> > 000000008005003b >> > > > > > CR2: 0000000000000030 CR3: >> 000000000156d000 >> > CR4: >> > > > 0000000000002660 >> > > > > > DR0: 0000000000000000 DR1: >> 0000000000000000 >> > DR2: >> > > > 0000000000000000 >> > > > > > DR3: 0000000000000000 DR6: >> 00000000ffff0ff0 >> > DR7: >> > > > 0000000000000400 >> > > > > > Process qemu-dm (pid: 3571, threadinfo >> > > ffff8800389fe000, >> > > > task >> > > > > > ffff88003a721260) >> > > > > > Stack: >> > > > > > ffff88003a6d6400 ffff8800377b0000 >> > 00000001000a3e0c >> > > > > ffffffff8133ce8f >> > > > > > ffff8800377b0400 ffffffff8134b6cd >> > ffff8800389ffc28 >> > > > > ffff8800389ffc28 >> > > > > > ffff8800377b00f8 ffff8800377b0680 >> > ffff880038cdcd60 >> > > > > ffff8800377b0000 >> > > > > > Call Trace: >> > > > > > [] ? >> > sk_release_kernel+0x23/0x39 >> > > > > > [] ? >> > netdev_run_todo+0x1e9/0x206 >> > > > > > [] ? >> > tun_chr_close+0x4c/0x7b >> > > > > > [] ? fput+0xe4/0x1c5 >> > > > > > [] ? >> filp_close+0x61/0x68 >> > > > > > [] ? >> > put_files_struct+0x62/0xb9 >> > > > > > [] ? >> do_exit+0x24a/0x74c >> > > > > > [] ? >> > do_group_exit+0x6b/0x9d >> > > > > > [] ? >> > > get_signal_to_deliver+0x449/0x46e >> > > > > > [] ? >> do_signal+0x28/0x4c4 >> > > > > > [] ? >> > > pvclock_clocksource_read+0x48/0xbf >> > > > > > [] ? >> ktime_get_ts+0x66/0xa8 >> > > > > > [] ? >> > > poll_select_copy_remaining+0xe0/0xf5 >> > > > > > [] ? >> > do_notify_resume+0x3b/0x74 >> > > > > > [] ? >> int_signal+0x12/0x17 >> > > > > > Code: 00 00 00 40 74 02 0f 0b 48 8d 77 >> 70 48 >> > 8d bf 08 >> > > 01 00 >> > > > 00 e8 >> > > > > 8b 71 10 >> > > > > > 00 85 c0 0f 84 5d 01 00 00 48 8b 6b 18 >> f6 83 >> > 80 00 00 >> > > 00 08 >> > > > <4c> 8b >> > > > > 65 30 >> > > > > > 74 11 be 68 05 00 00 48 c7 c7 8e df 4f >> 81 e8 >> > bb d0 >> > > > > > RIP [] iput+0x3e/0x1= 95 >> > > > > > RSP >> > > > > > CR2: 0000000000000030 >> > > > > > ---[ end trace 67cc1654658fedcc ]--- >> > > > > > Fixing recursive fault but reboot is >> needed! >> > > > > > >> > > > > > I also tested Xen 4.2.0 and problem is >> the >> > same. So >> > > is this >> > > > a Xen >> > > > > bug or a >> > > > > > kernel bug? I am running vanilla >> > > [1][2][3][4][5]kernel.org kernel >> > > > 3.5.0 and >> > > > > my >> > > > > > hardware is Intel Core i7-3770 CPU and >> Intel >> > DQ77MK >> > > > motherboard >> > > > > with >> > > > > > latest bios. >> > > > > > >> > > > > > Best regards, >> > > > > > Valtteri Kiviniemi >> > > > > > >> > > > > > References >> > > > > > >> > > > > > Visible links >> > > > > > 1. [3][4][5][6]http://kernel.org/ >> > > > > >> > > > > > >> _______________________________________________ >> > > > > > Xen-devel mailing list >> > > > > > [4][5][6][7]Xen-devel@lists.xen.org >> > > > > > [5][6][7][8]http://lists.xen.org/xen-devel >> > > > > >> > > > > References >> > > > > >> > > > > Visible links >> > > > > 1. mailto:[7][8][9]pasik@iki.fi >> > > > > 2. [8][9][10]http://kernel.org/ >> > > > > 3. [9][10][11]http://kernel.org/ >> > > > > 4. mailto:[10][11][12]Xen-devel@lists.xen.org >> > > > > 5. [11][12][13]http://lists.xen.org/xen-devel >> > > > >> > > > References >> > > > >> > > > Visible links >> > > > 1. mailto:[13][14]pasik@iki.fi >> > > > 2. mailto:[14][15]pasik@iki.fi >> > > > 3. [15][16]http://kernel.org/ >> > > > 4. [16][17]http://kernel.org/ >> > > > 5. mailto:[17][18]Xen-devel@lists.xen.org >> > > > 6. [18][19]http://lists.xen.org/xen-devel >> > > > 7. mailto:[19][20]pasik@iki.fi >> > > > 8. [20][21]http://kernel.org/ >> > > > 9. [21][22]http://kernel.org/ >> > > > 10. mailto:[22][23]Xen-devel@lists.xen.org >> > > > 11. [23][24]http://lists.xen.org/xen-devel >> > > >> > > References >> > > >> > > Visible links >> > > 1. mailto:[25]pasik@iki.fi >> > > 2. mailto:[26]pasik@iki.fi >> > > 3. mailto:[27]pasik@iki.fi >> > > 4. [28]http://kernel.org/ >> > > 5. [29]http://kernel.org/ >> > > 6. mailto:[30]Xen-devel@lists.xen.org >> > > 7. [31]http://lists.xen.org/xen-devel >> > > 8. mailto:[32]pasik@iki.fi >> > > 9. [33]http://kernel.org/ >> > > 10. [34]http://kernel.org/ >> > > 11. mailto:[35]Xen-devel@lists.xen.org >> > > 12. [36]http://lists.xen.org/xen-devel >> > > 13. mailto:[37]pasik@iki.fi >> > > 14. mailto:[38]pasik@iki.fi >> > > 15. [39]http://kernel.org/ >> > > 16. [40]http://kernel.org/ >> > > 17. mailto:[41]Xen-devel@lists.xen.org >> > > 18. [42]http://lists.xen.org/xen-devel >> > > 19. mailto:[43]pasik@iki.fi >> > > 20. [44]http://kernel.org/ >> > > 21. [45]http://kernel.org/ >> > > 22. mailto:[46]Xen-devel@lists.xen.org >> > > 23. [47]http://lists.xen.org/xen-devel >> > >> > References >> > >> > Visible links >> > 1. mailto:pasik@iki.fi >> > 2. mailto:pasik@iki.fi >> > 3. mailto:pasik@iki.fi >> > 4. mailto:pasik@iki.fi >> > 5. http://kernel.org/ >> > 6. http://kernel.org/ >> > 7. mailto:Xen-devel@lists.xen.org >> > 8. http://lists.xen.org/xen-devel >> > 9. mailto:pasik@iki.fi >> > 10. http://kernel.org/ >> > 11. http://kernel.org/ >> > 12. mailto:Xen-devel@lists.xen.org >> > 13. http://lists.xen.org/xen-devel >> > 14. mailto:pasik@iki.fi >> > 15. mailto:pasik@iki.fi >> > 16. http://kernel.org/ >> > 17. http://kernel.org/ >> > 18. mailto:Xen-devel@lists.xen.org >> > 19. http://lists.xen.org/xen-devel >> > 20. mailto:pasik@iki.fi >> > 21. http://kernel.org/ >> > 22. http://kernel.org/ >> > 23. mailto:Xen-devel@lists.xen.org >> > 24. http://lists.xen.org/xen-devel >> > 25. mailto:pasik@iki.fi >> > 26. mailto:pasik@iki.fi >> > 27. mailto:pasik@iki.fi >> > 28. http://kernel.org/ >> > 29. http://kernel.org/ >> > 30. mailto:Xen-devel@lists.xen.org >> > 31. http://lists.xen.org/xen-devel >> > 32. mailto:pasik@iki.fi >> > 33. http://kernel.org/ >> > 34. http://kernel.org/ >> > 35. mailto:Xen-devel@lists.xen.org >> > 36. http://lists.xen.org/xen-devel >> > 37. mailto:pasik@iki.fi >> > 38. mailto:pasik@iki.fi >> > 39. http://kernel.org/ >> > 40. http://kernel.org/ >> > 41. mailto:Xen-devel@lists.xen.org >> > 42. http://lists.xen.org/xen-devel >> > 43. mailto:pasik@iki.fi >> > 44. http://kernel.org/ >> > 45. http://kernel.org/ >> > 46. mailto:Xen-devel@lists.xen.org >> > 47. http://lists.xen.org/xen-devel >> > > --20cf303a2e35c41b0104cb126a25 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

Another update:

I wanted to check that if a Linux HVM= would boot with working VNC console, so I tried to launch a Debian Squeeze= installer on HVM. It refused to start ant told me that vbd hotplug scripts= were not working. After that failure even the Windows domU would not anymo= re start which was previously starting ok.

The hotplug scripts also starts hanging on the processes.

root= =A0=A0=A0=A0=A0 9401=A0 0.1=A0 0.1=A0 17700=A0 1640 ?=A0=A0=A0=A0=A0=A0=A0 = S=A0=A0=A0 15:05=A0=A0 0:00 /bin/bash /etc/xen/scripts/xen-hotplug-cleanup<= br>root=A0=A0=A0=A0=A0 9441=A0 0.1=A0 0.1=A0 17700=A0 1644 ?=A0=A0=A0=A0=A0= =A0=A0 S=A0=A0=A0 15:05=A0=A0 0:00 /bin/bash /etc/xen/scripts/xen-hotplug-c= leanup
root=A0=A0=A0=A0=A0 9481=A0 0.1=A0 0.1=A0 17700=A0 1640 ?=A0=A0=A0=A0=A0=A0= =A0 S=A0=A0=A0 15:05=A0=A0 0:00 /bin/bash /etc/xen/scripts/xen-hotplug-clea= nup
root=A0=A0=A0=A0=A0 9560=A0 0.1=A0 0.1=A0 17700=A0 1640 ?=A0=A0=A0= =A0=A0=A0=A0 S=A0=A0=A0 15:05=A0=A0 0:00 /bin/bash /etc/xen/scripts/xen-hot= plug-cleanup
root=A0=A0=A0=A0 10738=A0 0.1=A0 0.1=A0 17696=A0 1636 ?=A0=A0=A0=A0=A0=A0= =A0 S=A0=A0=A0 15:05=A0=A0 0:00 /bin/bash /etc/xen/scripts/xen-hotplug-clea= nup
root=A0=A0=A0=A0 10747=A0 0.1=A0 0.1=A0 17792=A0 1736 ?=A0=A0=A0=A0= =A0=A0=A0 S=A0=A0=A0 15:05=A0=A0 0:00 /bin/bash /etc/xen/scripts/block remo= ve
root=A0=A0=A0=A0 11286=A0 0.0=A0 0.0=A0=A0 4080=A0=A0 324 ?=A0=A0=A0=A0=A0= =A0=A0 S=A0=A0=A0 15:06=A0=A0 0:00 sleep 1
root=A0=A0=A0=A0 11290=A0 0.0= =A0 0.0=A0=A0 4080=A0=A0 324 ?=A0=A0=A0=A0=A0=A0=A0 S=A0=A0=A0 15:06=A0=A0 = 0:00 sleep 1
root=A0=A0=A0=A0 11294=A0 0.0=A0 0.0=A0=A0 4080=A0=A0 324 ?= =A0=A0=A0=A0=A0=A0=A0 S=A0=A0=A0 15:06=A0=A0 0:00 sleep 1
root=A0=A0=A0=A0 11298=A0 0.0=A0 0.0=A0=A0 4080=A0=A0 324 ?=A0=A0=A0=A0=A0= =A0=A0 S=A0=A0=A0 15:06=A0=A0 0:00 sleep 1
root=A0=A0=A0=A0 11302=A0 0.0= =A0 0.0=A0=A0 4080=A0=A0 320 ?=A0=A0=A0=A0=A0=A0=A0 S=A0=A0=A0 15:06=A0=A0 = 0:00 sleep 1
root=A0=A0=A0=A0 11306=A0 0.0=A0 0.0=A0=A0 4080=A0=A0 320 ?= =A0=A0=A0=A0=A0=A0=A0 S=A0=A0=A0 15:06=A0=A0 0:00 sleep 1

Then I did a xm destroy and I had again the kernel BUG on dmesg. So it = seems that the problem is not fixed by using 3.6.0. Udev version is 175-7.<= br>
=A0


2012/10/1 Valtteri Kivinie= mi <kiviniemi.valtteri@gmail.com>
Hi,

CPU: Intel Core i7-3770 3.4GHzhttp://= ark.intel.com/products/65719/

MB: Intel DQ77MK (latest bios updated)
http://www.intel.com/content/www/us/en/motherboard= s/desktop-motherboards/desktop-board-dq77mk.html

Memory: 32GB (4 x 8GB DDR3-1600MHz)

Host is Debian wheezy/testin= g, Xen 4.0.4 and latest 3.6.0 kernel.

Noticed also some errors in xm= dmesg:

root@xen-2:~# xm dmesg

(XEN) Xen version 4.0.4 (root@dataproof.fi) (g= cc version 4.7.1 (Debian 4.7.1-7) ) Sun Sep 30 20:28:26 EEST 2012
(XEN) Latest ChangeSet: unavailable
(XEN) Bootloader: GNU GRUB 0.97
(= XEN) Command line: dom0_mem=3D1280M cpufreq=3Dxen clocksource=3Dhpet
(XE= N) Video information:
(XEN)=A0 VGA is text mode 80x25, font 8x16
(XEN= )=A0 VBE/DDC methods: none; EDID transfer time: 0 seconds
(XEN)=A0 EDID info not retrieved because no DDC retrieval method detected(XEN) Disc information:
(XEN)=A0 Found 4 MBR signatures
(XEN)=A0 Fo= und 4 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)=A0 000= 0000000000000 - 000000000009d800 (usable)
(XEN)=A0 000000000009d800 - 00000000000a0000 (reserved)
(XEN)=A0 0000000= 0000e0000 - 0000000000100000 (reserved)
(XEN)=A0 0000000000100000 - 0000= 000020000000 (usable)
(XEN)=A0 0000000020000000 - 0000000020200000 (rese= rved)
(XEN)=A0 0000000020200000 - 0000000040004000 (usable)
(XEN)=A0 000000004= 0004000 - 0000000040005000 (reserved)
(XEN)=A0 0000000040005000 - 000000= 00dbe44000 (usable)
(XEN)=A0 00000000dbe44000 - 00000000dc2d7000 (reserv= ed)
(XEN)=A0 00000000dc2d7000 - 00000000dc2e7000 (ACPI data)
(XEN)=A0 000000= 00dc2e7000 - 00000000dc40c000 (ACPI NVS)
(XEN)=A0 00000000dc40c000 - 000= 00000dc6af000 (reserved)
(XEN)=A0 00000000dc6af000 - 00000000dc6b0000 (u= sable)
(XEN)=A0 00000000dc6b0000 - 00000000dc6f3000 (ACPI NVS)
(XEN)=A0 0000000= 0dc6f3000 - 00000000dd000000 (usable)
(XEN)=A0 00000000dd800000 - 000000= 00dfa00000 (reserved)
(XEN)=A0 00000000f8000000 - 00000000fc000000 (rese= rved)
(XEN)=A0 00000000fec00000 - 00000000fec01000 (reserved)
(XEN)=A0 0000000= 0fed00000 - 00000000fed04000 (reserved)
(XEN)=A0 00000000fed1c000 - 0000= 0000fed20000 (reserved)
(XEN)=A0 00000000fee00000 - 00000000fee01000 (re= served)
(XEN)=A0 00000000ff000000 - 0000000100000000 (reserved)
(XEN)=A0 0000000= 100000000 - 000000081e600000 (usable)
(XEN) ACPI: RSDP 000F0490, 0024 (r= 2=A0 INTEL)
(XEN) ACPI: XSDT DC2DB080, 007C (r1 INTEL=A0 DQ77MK=A0=A0=A0= =A0=A0=A0=A0=A0 32 AMI=A0=A0=A0=A0 10013)
(XEN) ACPI: FACP DC2E51F0, 010C (r5 INTEL=A0 DQ77MK=A0=A0=A0=A0=A0=A0=A0=A0= 32 AMI=A0=A0=A0=A0 10013)
(XEN) ACPI Warning (tbfadt-0232): FADT (revis= ion 5) is longer than ACPI 2.0 version, truncating length 0x10C to 0xF4 [20= 070126]
(XEN) ACPI: DSDT DC2DB188, A061 (r2 INTEL=A0 DQ77MK=A0=A0=A0=A0= =A0=A0=A0=A0 32 INTL 20051117)
(XEN) ACPI: FACS DC40A080, 0040
(XEN) ACPI: APIC DC2E5300, 0092 (r3 INTE= L=A0 DQ77MK=A0=A0=A0=A0=A0=A0=A0=A0 32 AMI=A0=A0=A0=A0 10013)
(XEN) ACPI= : FPDT DC2E5398, 0044 (r1 INTEL=A0 DQ77MK=A0=A0=A0=A0=A0=A0=A0=A0 32 AMI=A0= =A0=A0=A0 10013)
(XEN) ACPI: TCPA DC2E53E0, 0032 (r2 INTEL=A0 DQ77MK=A0= =A0=A0=A0=A0=A0=A0=A0 32 MSFT=A0 1000013)
(XEN) ACPI: MCFG DC2E5418, 003C (r1 INTEL=A0 DQ77MK=A0=A0=A0=A0=A0=A0=A0=A0= 32 MSFT=A0=A0=A0=A0=A0=A0 97)
(XEN) ACPI: HPET DC2E5458, 0038 (r1 INTEL= =A0 DQ77MK=A0=A0=A0=A0=A0=A0=A0=A0 32 AMI.=A0=A0=A0=A0=A0=A0=A0 5)
(XEN)= ACPI: SSDT DC2E5490, 036D (r1 INTEL=A0 DQ77MK=A0=A0=A0=A0=A0=A0=A0=A0 32 I= NTL 20091112)
(XEN) ACPI: SSDT DC2E5800, 09AA (r1 INTEL=A0 DQ77MK=A0=A0=A0=A0=A0=A0=A0=A0= 32 INTL 20051117)
(XEN) ACPI: SSDT DC2E61B0, 0A92 (r1 INTEL=A0 DQ77MK= =A0=A0=A0=A0=A0=A0=A0=A0 32 INTL 20051117)
(XEN) ACPI: DMAR DC2E6C48, 00= B8 (r1 INTEL=A0 DQ77MK=A0=A0=A0=A0=A0=A0=A0=A0 32 INTL=A0=A0=A0=A0=A0=A0=A0= 1)
(XEN) ACPI: ASF! DC2E6D00, 00A5 (r32 INTEL=A0 DQ77MK=A0=A0=A0=A0=A0=A0=A0= =A0 32 TFSM=A0=A0=A0 F4240)
(XEN) System RAM: 32682MB (33467320kB)
(X= EN) Domain heap initialised
(XEN) ACPI: 32/64X FACS address mismatch in = FADT - dc40a080/0000000000000000, using 32
(XEN) Processor #0 7:10 APIC version 21
(XEN) Processor #2 7:10 APIC ver= sion 21
(XEN) Processor #4 7:10 APIC version 21
(XEN) Processor #6 7:= 10 APIC version 21
(XEN) Processor #1 7:10 APIC version 21
(XEN) Proc= essor #3 7:10 APIC version 21
(XEN) Processor #5 7:10 APIC version 21
(XEN) Processor #7 7:10 APIC ver= sion 21
(XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI = 0-23
(XEN) Enabling APIC mode:=A0 Flat.=A0 Using 1 I/O APICs
(XEN) Sw= itched to APIC driver x2apic_cluster.
(XEN) x2APIC mode enabled.
(XEN) Using scheduler: SMP Credit Scheduler (= credit)
(XEN) Detected 3392.369 MHz processor.
(XEN) Initing memory s= haring.
(XEN) VMX: Supported advanced features:
(XEN)=A0 - APIC MMIO = access virtualisation
(XEN)=A0 - APIC TPR shadow
(XEN)=A0 - Extended Page Tables (EPT)
(XEN= )=A0 - Virtual-Processor Identifiers (VPID)
(XEN)=A0 - Virtual NMI
(X= EN)=A0 - MSR direct-access bitmap
(XEN)=A0 - Unrestricted Guest
(XEN)= EPT supports 2MB super page.
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware = Assisted Paging detected.
(XEN) Intel VT-d Snoop Control not enabled.(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
(XEN) Intel VT-d Que= ued Invalidation enabled.
(XEN) Intel VT-d Interrupt Remapping enabled.
(XEN) I/O virtualisation e= nabled
(XEN)=A0 - Dom0 mode: Relaxed
(XEN) Enabled directed EOI with = ioapic_ack_old on!
(XEN) Total of 8 processors activated.
(XEN) ENABL= ING IO-APIC IRQs
(XEN)=A0 -> Using old ACK method
(XEN) TSC is reliable, synchronizati= on unnecessary
(XEN) Platform timer appears to have unexpectedly wrapped= 1 times.
(XEN) Platform timer is 14.318MHz HPET
(XEN) Allocated cons= ole ring of 16 KiB.
(XEN) Brought up 8 CPUs
(XEN) *** LOADING DOMAIN 0 ***
(XEN)=A0 Xen= =A0 kernel: 64-bit, lsb, compat32
(XEN)=A0 Dom0 kernel: 64-bit, PAE, lsb= , paddr 0x1000000 -> 0x1ae7000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
= (XEN)=A0 Dom0 alloc.:=A0=A0 0000000804000000->0000000806000000 (319488 p= ages to be allocated)
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)=A0 Loaded kernel: ffffffff810000= 00->ffffffff81ae7000
(XEN)=A0 Init. ramdisk: ffffffff81ae7000->fff= fffff81ae7000
(XEN)=A0 Phys-Mach map: ffffffff81ae7000->ffffffff81d67= 000
(XEN)=A0 Start info:=A0=A0=A0 ffffffff81d67000->ffffffff81d674b4
(XEN= )=A0 Page tables:=A0=A0 ffffffff81d68000->ffffffff81d7b000
(XEN)=A0 B= oot stack:=A0=A0=A0 ffffffff81d7b000->ffffffff81d7c000
(XEN)=A0 TOTAL= :=A0=A0=A0=A0=A0=A0=A0=A0 ffffffff80000000->ffffffff82000000
(XEN)=A0 ENTRY ADDRESS: ffffffff815e3210
(XEN) Dom0 has maximum 8 VCPUs<= br>(XEN) [VT-D]iommu.c:718: BIOS did not enable IGD for VT properly.=A0 Dis= abling IGD VT-d engine.
(XEN) Scrubbing Free RAM: done.
(XEN) Xen tra= ce buffers: disabled
(XEN) Std. Loglevel: Errors and warnings
(XEN) Guest Loglevel: Nothing (= Rate-limited: Errors and warnings)
(XEN) Xen is relinquishing VGA consol= e.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times = to switch input to Xen)
(XEN) Freed 172kB init memory.
(XEN) traps.c:2333:d0 Domain attempted WR= MSR 000000000000008b from 00000012:00000000 to 00000000:00000000.

- Valtteri


2012/10/1 Pasi K=E4rkk= =E4inen <pasik@iki.fi>
On Mon, Oct 01, 2012 at 09:12:50PM +030= 0, Valtteri Kiviniemi wrote:
> =A0 =A0Hi,
>
> =A0 =A0Lowering memory or vcpu's does not help, problem= is the same. I originally
> =A0 =A0installed Xen 4.2.0 and the problem was same on that too. Then = I
> =A0 =A0downgraded back to 4.0.4 since I thought that this might be a b= ug on
> =A0 =A04.2.0. I have been previously running Windows Server 2008 R2 su= ccesfully
> =A0 =A0on Xen 4.0.x on different hardware with this same config. Hyper= visor is
> =A0 =A064bit and windows is 64bit.
>
> =A0 =A0Any ideas what to try next?
>

What kind of hardware is that?

xen.org automated testing = regularly tests Windows VMs, and it works OK there.

-- Pasi

> =A0 =A0Ps. qemu-dm.log is the following:
>
> =A0 =A0domid: 10
> =A0 =A0config qemu network with xen bridge for =A0tap10.0 xenbr0
> =A0 =A0Using file /dev/virtuals/ts in read-write mode
> =A0 =A0Using file /media/iso/windows_server_2008_r2_sp1.iso in read-on= ly mode
> =A0 =A0Watching /local/domain/0/device-model/10/logdirty/cmd
> =A0 =A0Watching /local/domain/0/device-model/10/command
> =A0 =A0qemu_map_cache_init nr_buckets =3D 10000 size 4194304
> =A0 =A0shared page at pfn feffd
> =A0 =A0buffered io page at pfn feffb
> =A0 =A0Guest uuid =3D 52f19e23-2955-c27d-a22c-60c5d8c60d5a
> =A0 =A0Time offset set 0
> =A0 =A0populating video RAM at ff000000
> =A0 =A0mapping video RAM from ff000000
> =A0 =A0Register xen platform.
> =A0 =A0Done register platform.
> =A0 =A0platform_fixed_ioport: changed ro/rw state of ROM memory area. = now is rw
> =A0 =A0state.
> =A0 =A0xs_read(/local/domain/0/device-model/10/xen_extended_power_mgmt= ): read
> =A0 =A0error
> =A0 =A0medium change watch on `hdc' (index: 1):
> =A0 =A0/media/iso/windows_server_2008_r2_sp1.iso
> =A0 =A0I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, s= ize: 0
> =A0 =A0Log-dirty: no command yet.
> =A0 =A0xs_read(/local/domain/10/log-throttling): read error
> =A0 =A0qemu: ignoring not-understood drive `/local/domain/10/log-throt= tling'
> =A0 =A0medium change watch on `/local/domain/10/log-throttling' - = unknown device,
> =A0 =A0ignored
> =A0 =A0cirrus vga map change while on lfb mode
> =A0 =A0mapping vram to f0000000 - f0400000
> =A0 =A0platform_fixed_ioport: changed ro/rw state of ROM memory area. = now is rw
> =A0 =A0state.
> =A0 =A0platform_fixed_ioport: changed ro/rw state of ROM memory area. = now is ro
> =A0 =A0state.
>
> =A0 =A02012/10/1 Pasi K=E4rkk=E4inen <[1]pasik@iki.fi>
>
> =A0 =A0 =A0On Mon, Oct 01, 2012 at 07:23:44PM +0300, Valtteri Kiviniem= i wrote:
> =A0 =A0 =A0> =A0 =A0Hi,
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0I have tried other config files, but the proble= m is the same. At
> =A0 =A0 =A0the
> =A0 =A0 =A0> =A0 =A0moment I'm using a config file from another= server where I have a
> =A0 =A0 =A0working
> =A0 =A0 =A0> =A0 =A0Windows Server 2008 R2 installation, so I dont = think that there is
> =A0 =A0 =A0> =A0 =A0anything wrong with my config:
> =A0 =A0 =A0>
>
> =A0 =A0 =A0Did you try with less vcpus, for example 2 ?
> =A0 =A0 =A0how about with less memory, say 2 GB ?
>
> =A0 =A0 =A0Did you try with later Xen versions? Is that a 32bit Xen, o= r 64bit Xen
> =A0 =A0 =A0hypervisor?
>
> =A0 =A0 =A0-- Pasi
> =A0 =A0 =A0> =A0 =A0kernel =3D "/usr/lib/xen/boot/hvmloader&qu= ot;
> =A0 =A0 =A0> =A0 =A0builder =3D "hvm"
> =A0 =A0 =A0> =A0 =A0shadow_memory =3D "8"
> =A0 =A0 =A0> =A0 =A0memory =3D "4096"
> =A0 =A0 =A0> =A0 =A0name =3D "ts"
> =A0 =A0 =A0> =A0 =A0vcpus =3D "8"
> =A0 =A0 =A0> =A0 =A0cpus =3D ["0", "1", "2= ", "3", "4", "5", "6", "7= "]
> =A0 =A0 =A0> =A0 =A0pae =3D "1"
> =A0 =A0 =A0> =A0 =A0acpi =3D "1"
> =A0 =A0 =A0> =A0 =A0apic =3D "1"
> =A0 =A0 =A0> =A0 =A0vfb =3D [ 'type=3Dvnc, vnclisten=3D10.100.1= 00.50, vncpasswd=3Dxxx' ]
> =A0 =A0 =A0> =A0 =A0xen_extended_power_mgmt =3D "0"
> =A0 =A0 =A0> =A0 =A0vif =3D [ "type=3Dioemu, mac=3D00:16:3e:d7= :d7:5d, bridge=3Dxenbr0" ]
> =A0 =A0 =A0> =A0 =A0disk =3D [ "phy:/dev/virtuals/ts,hda,w&quo= t;,
> =A0 =A0 =A0> =A0 =A0"file:/media/iso/windows_server_2008_r2_sp= 1.iso,hdc:cdrom,r" ]
> =A0 =A0 =A0> =A0 =A0on_poweroff =3D "destroy"
> =A0 =A0 =A0> =A0 =A0on_reboot =3D "restart"
> =A0 =A0 =A0> =A0 =A0on_crash =3D "restart"
> =A0 =A0 =A0> =A0 =A0viridian =3D "1"
> =A0 =A0 =A0> =A0 =A0device_model =3D "/usr/lib/xen/bin/qemu-dm= "
> =A0 =A0 =A0> =A0 =A0boot =3D "dc"
> =A0 =A0 =A0> =A0 =A0snapshot =3D "0"
> =A0 =A0 =A0> =A0 =A0vncconsole =3D "1"
> =A0 =A0 =A0> =A0 =A0sdl =3D "0"
> =A0 =A0 =A0> =A0 =A0opengl =3D "0"
> =A0 =A0 =A0> =A0 =A0vnc =3D "1"
> =A0 =A0 =A0> =A0 =A0nographic =3D "0"
> =A0 =A0 =A0> =A0 =A0stdvga =3D "0"
> =A0 =A0 =A0> =A0 =A0tsc_mode =3D "1"
> =A0 =A0 =A0> =A0 =A0monitor =3D "0"
> =A0 =A0 =A0> =A0 =A0localtime =3D "1"
> =A0 =A0 =A0> =A0 =A0usb =3D "0"
> =A0 =A0 =A0> =A0 =A0keymap =3D "fi"
> =A0 =A0 =A0> =A0 =A0xen_platform_pci =3D "1"
> =A0 =A0 =A0> =A0 =A0pci_msitranslate =3D "1"
> =A0 =A0 =A0> =A0 =A0pci_power_mgmt =3D "0"
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A02012/10/1 Pasi K=E4rkk=E4= inen <[1][2][3]pasik@i= ki.fi>
> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0On Mon, Oct 01, 2012 at 05:= 06:53PM +0300, Valtteri
> =A0 =A0 =A0Kiviniemi
> =A0 =A0 =A0> =A0 =A0 =A0wrote:
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0Hi,
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0I'm now usi= ng 3.6.0 and can't reproduce that crash
> =A0 =A0 =A0anymore,
> =A0 =A0 =A0> =A0 =A0 =A0so it
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0seems
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0that it was a k= ernel bug.
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0OK.
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0However I'm= still getting black screen on VNC
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0when trying to = install Windows Server 2008 R2. I can
> =A0 =A0 =A0see the
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0"windows is
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0loading files&q= uot; screen but after the installer starts
> =A0 =A0 =A0the VNC
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0display goes
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0black.
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0Any ideas?
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0Do you have viridian=3D1 sp= ecified for the windows vm?
> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0-- Pasi
> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0- Valtteri
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A02012/10/1= Pasi K=E4rkk=E4inen <[1][2][3][4]pasik@iki.fi>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0On Sun, Sep= 30, 2012 at 11:18:03PM +0300, Valtteri
> =A0 =A0 =A0> =A0 =A0 =A0Kiviniemi
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0wrote:
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0Hi,
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0Hello,
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0I'm trying to get Windows Server 2008 R2
> =A0 =A0 =A0installation
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0booting on
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0Xen
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A04.0.4. Using the following config:
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0<snip>= ;
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0The domU will start booting just fine, but
> =A0 =A0 =A0after a
> =A0 =A0 =A0> =A0 =A0 =A0few
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0minutes the
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0VNC
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0screen goes black. After that when typing "xm
> =A0 =A0 =A0destroy
> =A0 =A0 =A0> =A0 =A0 =A0ts" it
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0will
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0trigger
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0a kernel BUG:
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0BUG: unable to handle kernel NULL pointer
> =A0 =A0 =A0dereference
> =A0 =A0 =A0> =A0 =A0 =A0at
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A000000000000= 00030
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0IP: [<ffffffff810c50c4>] iput+0x3e/0x195
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0PGD 0
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0Oops: 0000 [#1] SMP
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0CPU 6
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0Pid: 3571, comm: qemu-dm Not tainted
> =A0 =A0 =A03.5.0-dom0 #1
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0First of al= l upgrade to latest 3.5.x Linux kernel
> =A0 =A0 =A0release
> =A0 =A0 =A0> =A0 =A0 =A0.. so
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0at least
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A03.5.4.
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0-- Pasi
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0/DQ77MK
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0RIP: e030:[<ffffffff810c50c4>]
> =A0 =A0 =A0 [<ffffffff810c50c4>]
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0iput+0x3e/0= x195
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0RSP: e02b:ffff8800389ffbf8 =A0EFLAGS: 00010246
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0RAX: 0000000000000001 RBX: ffff8800377b0720
> =A0 =A0 =A0RCX:
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0ffff8800501c0000
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0RDX: ffff8800501c0000 RSI: ffff8800377b0790
> =A0 =A0 =A0RDI:
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0ffff8800377b0790
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0RBP: 0000000000000000 R08: ffffffff815cdd00
> =A0 =A0 =A0R09:
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A00000000000000016
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0R10: fefefefefefefeff R11: ffff8800377b0400
> =A0 =A0 =A0R12:
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A000000001000a3e0c
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0R13: 0000000000000000 R14: 00000001000a3e0c
> =A0 =A0 =A0R15:
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0ffff8800389ffc28
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0FS: =A000007f1af70a8700(0000)
> =A0 =A0 =A0GS:ffff880050180000(0000)
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0knlGS:0000000000000000
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0CS: =A0e033 DS: 0000 ES: 0000 CR0:
> =A0 =A0 =A0000000008005003b
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0CR2: 0000000000000030 CR3: 000000000156d000
> =A0 =A0 =A0CR4:
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A00000000000002660
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0DR0: 0000000000000000 DR1: 0000000000000000
> =A0 =A0 =A0DR2:
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A00000000000000000
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0DR3: 0000000000000000 DR6: 00000000ffff0ff0
> =A0 =A0 =A0DR7:
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A00000000000000400
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0Process qemu-dm (pid: 3571, threadinfo
> =A0 =A0 =A0> =A0 =A0 =A0ffff8800389fe000,
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0task
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0ffff88003a721260)
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0Stack:
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0 ffff88003a6d6400 ffff8800377b0000
> =A0 =A0 =A000000001000a3e0c
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0ffffffff813= 3ce8f
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0 ffff8800377b0400 ffffffff8134b6cd
> =A0 =A0 =A0ffff8800389ffc28
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0ffff8800389= ffc28
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0 ffff8800377b00f8 ffff8800377b0680
> =A0 =A0 =A0ffff880038cdcd60
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0ffff8800377= b0000
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0Call Trace:
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0 [<ffffffff8133ce8f>] ?
> =A0 =A0 =A0sk_release_kernel+0x23/0x39
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0 [<ffffffff8134b6cd>] ?
> =A0 =A0 =A0netdev_run_todo+0x1e9/0x206
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0 [<ffffffff8129798f>] ?
> =A0 =A0 =A0tun_chr_close+0x4c/0x7b
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0 [<ffffffff810b39d3>] ? fput+0xe4/0x1c5
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0 [<ffffffff810b202c>] ? filp_close+0x61/0x68
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0 [<ffffffff81035e62>] ?
> =A0 =A0 =A0put_files_struct+0x62/0xb9
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0 [<ffffffff81036374>] ? do_exit+0x24a/0x74c
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0 [<ffffffff81036906>] ?
> =A0 =A0 =A0do_group_exit+0x6b/0x9d
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0 [<ffffffff8103ea0b>] ?
> =A0 =A0 =A0> =A0 =A0 =A0get_signal_to_deliver+0x449/0x46e
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0 [<ffffffff81009fa5>] ? do_signal+0x28/0x4c4
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0 [<ffffffff81027079>] ?
> =A0 =A0 =A0> =A0 =A0 =A0pvclock_clocksource_read+0x48/0xbf
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0 [<ffffffff8105b745>] ? ktime_get_ts+0x66/0xa8
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0 [<ffffffff810bfb18>] ?
> =A0 =A0 =A0> =A0 =A0 =A0poll_select_copy_remaining+0xe0/0xf5
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0 [<ffffffff8100a48d>] ?
> =A0 =A0 =A0do_notify_resume+0x3b/0x74
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0 [<ffffffff81411a70>] ? int_signal+0x12/0x17
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0Code: 00 00 00 40 74 02 0f 0b 48 8d 77 70 48
> =A0 =A0 =A08d bf 08
> =A0 =A0 =A0> =A0 =A0 =A001 00
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A000 e8
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A08b 71 10 > =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A000 85 c0 0f 84 5d 01 00 00 48 8b 6b 18 f6 83
> =A0 =A0 =A080 00 00
> =A0 =A0 =A0> =A0 =A0 =A000 08
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0<4c> 8b
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A065 30
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A074 11 be 68 05 00 00 48 c7 c7 8e df 4f 81 e8
> =A0 =A0 =A0bb d0
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0RIP =A0[<ffffffff810c50c4>] iput+0x3e/0x195
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0 RSP <ffff8800389ffbf8>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0CR2: 0000000000000030
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0---[ end trace 67cc1654658fedcc ]---
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0Fixing recursive fault but reboot is needed!
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0I also tested Xen 4.2.0 and problem is the
> =A0 =A0 =A0same. So
> =A0 =A0 =A0> =A0 =A0 =A0is this
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0a Xen
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0bug or a > =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0kernel bug? I am running vanilla
> =A0 =A0 =A0> =A0 =A0 =A0[1][2][3][4][5]kernel.org kernel
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A03.5.0 and
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0my
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0hardware is Intel Core i7-3770 CPU and Intel
> =A0 =A0 =A0DQ77MK
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0motherboard
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0with
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0latest bios.
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0Best regards,
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0Valtteri Kiviniemi
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> Refere= nces
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0Visible links
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A01. [3][4][5][6]http= ://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> ______= _________________________________________
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> Xen-de= vel mailing list
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> [4][5]= [6][7]Xen-deve= l@lists.xen.org
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> [5][6]= [7][8]http://l= ists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> References
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0Visible links > =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A01. mailto:[7][8= ][9]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A02. [8][9][10]http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A03. [9][10][11]<= a href=3D"http://kernel.org/" target=3D"_blank">http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A04. mailto:[10][= 11][12]Xen-dev= el@lists.xen.org
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A05. [11][12][13]= http://lists.x= en.org/xen-devel
> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> References
> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0Visible links
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A01. mailto:[13][14]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A02. mailto:[14][15]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A03. [15][16]http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A04. [16][17]http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A05. mailto:[17][18]Xen-devel@lists.xen.org=
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A06. [18][19]http://lists.xen.org/xen-devel=
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A07. mailto:[19][20]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A08. [20][21]http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A09. [21][22]http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 10. mailto:[22][23]Xen-devel@lists.xen.org > =A0 =A0 =A0> =A0 =A0 =A0> =A0 11. [23][24]http://lists.xen.org/xen-devel > =A0 =A0 =A0>
> =A0 =A0 =A0> References
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0Visible links
> =A0 =A0 =A0> =A0 =A01. mailto:[25]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A02. mailto:[26]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A03. mailto:[27]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A04. [28]http://kernel.org/
> =A0 =A0 =A0> =A0 =A05. [29]http://kernel.org/
> =A0 =A0 =A0> =A0 =A06. mailto:[30]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 =A07. [31]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 =A08. mailto:[32]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A09. [33]http://kernel.org/
> =A0 =A0 =A0> =A0 10. [34]http://kernel.org/
> =A0 =A0 =A0> =A0 11. mailto:[35]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 12. [36]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 13. mailto:[37]pasik@iki.fi
> =A0 =A0 =A0> =A0 14. mailto:[38]pasik@iki.fi
> =A0 =A0 =A0> =A0 15. [39]http://kernel.org/
> =A0 =A0 =A0> =A0 16. [40]http://kernel.org/
> =A0 =A0 =A0> =A0 17. mailto:[41]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 18. [42]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 19. mailto:[43]pasik@iki.fi
> =A0 =A0 =A0> =A0 20. [44]http://kernel.org/
> =A0 =A0 =A0> =A0 21. [45]http://kernel.org/
> =A0 =A0 =A0> =A0 22. mailto:[46]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 23. [47]http://lists.xen.org/xen-devel
>
> References
>
> =A0 =A0Visible links
> =A0 =A01. mailto:pas= ik@iki.fi
> =A0 =A02. mailto:pas= ik@iki.fi
> =A0 =A03. mailto:pas= ik@iki.fi
> =A0 =A04. mailto:pasik@iki.fi
> =A0 =A05. http://kern= el.org/
> =A0 =A06. http://kern= el.org/
> =A0 =A07. mailto:Xen-devel@lists.xen.org
> =A0 =A08. http://lists.xen.org/xen-devel
> =A0 =A09. mailto:pas= ik@iki.fi
> =A0 10. http://kernel= .org/
> =A0 11. http://kernel= .org/
> =A0 12. mailto:Xen-devel@lists.xen.org
> =A0 13. h= ttp://lists.xen.org/xen-devel
> =A0 14. mailto:pasik= @iki.fi
> =A0 15. mailto:pasik= @iki.fi
> =A0 16. http://kernel= .org/
> =A0 17. http://kernel= .org/
> =A0 18. mailto:Xen-devel@lists.xen.org
> =A0 19. h= ttp://lists.xen.org/xen-devel
> =A0 20. mailto:pasik= @iki.fi
> =A0 21. http://kernel= .org/
> =A0 22. http://kernel= .org/
> =A0 23. mailto:Xen-devel@lists.xen.org
> =A0 24. h= ttp://lists.xen.org/xen-devel
> =A0 25. mailto:pasik= @iki.fi
> =A0 26. mailto:pasik= @iki.fi
> =A0 27. mailto:pasik= @iki.fi
> =A0 28. http://kernel= .org/
> =A0 29. http://kernel= .org/
> =A0 30. mailto:Xen-devel@lists.xen.org
> =A0 31. h= ttp://lists.xen.org/xen-devel
> =A0 32. mailto:pasik= @iki.fi
> =A0 33. http://kernel= .org/
> =A0 34. http://kernel= .org/
> =A0 35. mailto:Xen-devel@lists.xen.org
> =A0 36. h= ttp://lists.xen.org/xen-devel
> =A0 37. mailto:pasik= @iki.fi
> =A0 38. mailto:pasik= @iki.fi
> =A0 39. http://kernel= .org/
> =A0 40. http://kernel= .org/
> =A0 41. mailto:Xen-devel@lists.xen.org
> =A0 42. h= ttp://lists.xen.org/xen-devel
> =A0 43. mailto:pasik= @iki.fi
> =A0 44. http://kernel= .org/
> =A0 45. http://kernel= .org/
> =A0 46. mailto:Xen-devel@lists.xen.org
> =A0 47. h= ttp://lists.xen.org/xen-devel


--20cf303a2e35c41b0104cb126a25-- --===============7769507901113686720== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============7769507901113686720==-- From xen-devel-bounces@lists.xen.org Tue Oct 02 12:11:37 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 12:11:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ1Jm-000127-3E; Tue, 02 Oct 2012 12:11:18 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ1Jk-000121-H6 for Xen-devel@lists.xen.org; Tue, 02 Oct 2012 12:11:17 +0000 Received: from [85.158.143.35:32415] by server-1.bemta-4.messagelabs.com id EF/FF-05684-3E9DA605; Tue, 02 Oct 2012 12:11:15 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1349179868!14577554!1 X-Originating-IP: [209.85.160.173] X-SpamReason: No, hits=1.4 required=7.0 tests=BODY_RANDOM_LONG, HTML_40_50, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, ML_RADAR_SPEW_LINKS_23, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8573 invoked from network); 2 Oct 2012 12:11:09 -0000 Received: from mail-gh0-f173.google.com (HELO mail-gh0-f173.google.com) (209.85.160.173) by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 12:11:09 -0000 Received: by ghy16 with SMTP id 16so1869648ghy.32 for ; Tue, 02 Oct 2012 05:11:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oxsFxO/pbW77JqLKwHo3ZM9eK+wlLo/mp+c89GzYwEo=; b=G6IB35PQhj3NlpJX2ME/c3hn09zgRUjBUjWz6xJb4zzmRXaW/o2MVqZTI/n748ly5N Uml2rmfCOwWH5cSiM0mO2vj2nd/5pTwnKWeHNWRMDKeZ7uGNSfzJoR5r7+ieyd9V5RKv o+2cvyimuD/H8TUtmXsKfQSudHI0MQ3Wok6zxa8y+KkXrVJsqiOGgxbd5tZ/Wwadmqms BshiOr0R8HGpao2Mm7tRj2p7eFDC3x/Wee2Q3RgrmjX9gnYBAkFvaNnJPEJGVrAoIxiF LgUJqQ3DHAAyQTrPwEiEjyBPZQh8D16Rgejmndy5q47HVxzxHJohOBq3BHvxgR6cgQ/K tZUw== MIME-Version: 1.0 Received: by 10.236.151.99 with SMTP id a63mr18355479yhk.120.1349179867929; Tue, 02 Oct 2012 05:11:07 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Tue, 2 Oct 2012 05:11:07 -0700 (PDT) In-Reply-To: References: <20121001062232.GV8912@reaktio.net> <20121001144042.GC8912@reaktio.net> <20121001160117.GD8912@reaktio.net> <20121001164757.GF8912@reaktio.net> <20121001182437.GG8912@reaktio.net> Date: Tue, 2 Oct 2012 15:11:07 +0300 Message-ID: From: Valtteri Kiviniemi To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= Cc: Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.0.4, kernel 3.5.0 HVM crash and kernel BUG X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7769507901113686720==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============7769507901113686720== Content-Type: multipart/alternative; boundary=20cf303a2e35c41b0104cb126a25 --20cf303a2e35c41b0104cb126a25 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Another update: I wanted to check that if a Linux HVM would boot with working VNC console, so I tried to launch a Debian Squeeze installer on HVM. It refused to start ant told me that vbd hotplug scripts were not working. After that failure even the Windows domU would not anymore start which was previously starting ok. The hotplug scripts also starts hanging on the processes. root 9401 0.1 0.1 17700 1640 ? S 15:05 0:00 /bin/bash /etc/xen/scripts/xen-hotplug-cleanup root 9441 0.1 0.1 17700 1644 ? S 15:05 0:00 /bin/bash /etc/xen/scripts/xen-hotplug-cleanup root 9481 0.1 0.1 17700 1640 ? S 15:05 0:00 /bin/bash /etc/xen/scripts/xen-hotplug-cleanup root 9560 0.1 0.1 17700 1640 ? S 15:05 0:00 /bin/bash /etc/xen/scripts/xen-hotplug-cleanup root 10738 0.1 0.1 17696 1636 ? S 15:05 0:00 /bin/bash /etc/xen/scripts/xen-hotplug-cleanup root 10747 0.1 0.1 17792 1736 ? S 15:05 0:00 /bin/bash /etc/xen/scripts/block remove root 11286 0.0 0.0 4080 324 ? S 15:06 0:00 sleep 1 root 11290 0.0 0.0 4080 324 ? S 15:06 0:00 sleep 1 root 11294 0.0 0.0 4080 324 ? S 15:06 0:00 sleep 1 root 11298 0.0 0.0 4080 324 ? S 15:06 0:00 sleep 1 root 11302 0.0 0.0 4080 320 ? S 15:06 0:00 sleep 1 root 11306 0.0 0.0 4080 320 ? S 15:06 0:00 sleep 1 Then I did a xm destroy and I had again the kernel BUG on dmesg. So it seems that the problem is not fixed by using 3.6.0. Udev version is 175-7. 2012/10/1 Valtteri Kiviniemi > Hi, > > CPU: Intel Core i7-3770 3.4GHz > http://ark.intel.com/products/65719/ > > MB: Intel DQ77MK (latest bios updated) > > http://www.intel.com/content/www/us/en/motherboards/desktop-motherboards/= desktop-board-dq77mk.html > > Memory: 32GB (4 x 8GB DDR3-1600MHz) > > Host is Debian wheezy/testing, Xen 4.0.4 and latest 3.6.0 kernel. > > Noticed also some errors in xm dmesg: > > root@xen-2:~# xm dmesg > > (XEN) Xen version 4.0.4 (root@dataproof.fi) (gcc version 4.7.1 (Debian > 4.7.1-7) ) Sun Sep 30 20:28:26 EEST 2012 > (XEN) Latest ChangeSet: unavailable > (XEN) Bootloader: GNU GRUB 0.97 > (XEN) Command line: dom0_mem=3D1280M cpufreq=3Dxen clocksource=3Dhpet > (XEN) Video information: > (XEN) VGA is text mode 80x25, font 8x16 > (XEN) VBE/DDC methods: none; EDID transfer time: 0 seconds > (XEN) EDID info not retrieved because no DDC retrieval method detected > (XEN) Disc information: > (XEN) Found 4 MBR signatures > (XEN) Found 4 EDD information structures > (XEN) Xen-e820 RAM map: > (XEN) 0000000000000000 - 000000000009d800 (usable) > (XEN) 000000000009d800 - 00000000000a0000 (reserved) > (XEN) 00000000000e0000 - 0000000000100000 (reserved) > (XEN) 0000000000100000 - 0000000020000000 (usable) > (XEN) 0000000020000000 - 0000000020200000 (reserved) > (XEN) 0000000020200000 - 0000000040004000 (usable) > (XEN) 0000000040004000 - 0000000040005000 (reserved) > (XEN) 0000000040005000 - 00000000dbe44000 (usable) > (XEN) 00000000dbe44000 - 00000000dc2d7000 (reserved) > (XEN) 00000000dc2d7000 - 00000000dc2e7000 (ACPI data) > (XEN) 00000000dc2e7000 - 00000000dc40c000 (ACPI NVS) > (XEN) 00000000dc40c000 - 00000000dc6af000 (reserved) > (XEN) 00000000dc6af000 - 00000000dc6b0000 (usable) > (XEN) 00000000dc6b0000 - 00000000dc6f3000 (ACPI NVS) > (XEN) 00000000dc6f3000 - 00000000dd000000 (usable) > (XEN) 00000000dd800000 - 00000000dfa00000 (reserved) > (XEN) 00000000f8000000 - 00000000fc000000 (reserved) > (XEN) 00000000fec00000 - 00000000fec01000 (reserved) > (XEN) 00000000fed00000 - 00000000fed04000 (reserved) > (XEN) 00000000fed1c000 - 00000000fed20000 (reserved) > (XEN) 00000000fee00000 - 00000000fee01000 (reserved) > (XEN) 00000000ff000000 - 0000000100000000 (reserved) > (XEN) 0000000100000000 - 000000081e600000 (usable) > (XEN) ACPI: RSDP 000F0490, 0024 (r2 INTEL) > (XEN) ACPI: XSDT DC2DB080, 007C (r1 INTEL DQ77MK 32 AMI 1001= 3) > (XEN) ACPI: FACP DC2E51F0, 010C (r5 INTEL DQ77MK 32 AMI 1001= 3) > (XEN) ACPI Warning (tbfadt-0232): FADT (revision 5) is longer than ACPI > 2.0 version, truncating length 0x10C to 0xF4 [20070126] > (XEN) ACPI: DSDT DC2DB188, A061 (r2 INTEL DQ77MK 32 INTL 2005111= 7) > (XEN) ACPI: FACS DC40A080, 0040 > (XEN) ACPI: APIC DC2E5300, 0092 (r3 INTEL DQ77MK 32 AMI 1001= 3) > (XEN) ACPI: FPDT DC2E5398, 0044 (r1 INTEL DQ77MK 32 AMI 1001= 3) > (XEN) ACPI: TCPA DC2E53E0, 0032 (r2 INTEL DQ77MK 32 MSFT 100001= 3) > (XEN) ACPI: MCFG DC2E5418, 003C (r1 INTEL DQ77MK 32 MSFT 9= 7) > (XEN) ACPI: HPET DC2E5458, 0038 (r1 INTEL DQ77MK 32 AMI. = 5) > (XEN) ACPI: SSDT DC2E5490, 036D (r1 INTEL DQ77MK 32 INTL 2009111= 2) > (XEN) ACPI: SSDT DC2E5800, 09AA (r1 INTEL DQ77MK 32 INTL 2005111= 7) > (XEN) ACPI: SSDT DC2E61B0, 0A92 (r1 INTEL DQ77MK 32 INTL 2005111= 7) > (XEN) ACPI: DMAR DC2E6C48, 00B8 (r1 INTEL DQ77MK 32 INTL = 1) > (XEN) ACPI: ASF! DC2E6D00, 00A5 (r32 INTEL DQ77MK 32 TFSM > F4240) > (XEN) System RAM: 32682MB (33467320kB) > (XEN) Domain heap initialised > (XEN) ACPI: 32/64X FACS address mismatch in FADT - > dc40a080/0000000000000000, using 32 > (XEN) Processor #0 7:10 APIC version 21 > (XEN) Processor #2 7:10 APIC version 21 > (XEN) Processor #4 7:10 APIC version 21 > (XEN) Processor #6 7:10 APIC version 21 > (XEN) Processor #1 7:10 APIC version 21 > (XEN) Processor #3 7:10 APIC version 21 > (XEN) Processor #5 7:10 APIC version 21 > (XEN) Processor #7 7:10 APIC version 21 > (XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 > (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs > (XEN) Switched to APIC driver x2apic_cluster. > (XEN) x2APIC mode enabled. > (XEN) Using scheduler: SMP Credit Scheduler (credit) > (XEN) Detected 3392.369 MHz processor. > (XEN) Initing memory sharing. > (XEN) VMX: Supported advanced features: > (XEN) - APIC MMIO access virtualisation > (XEN) - APIC TPR shadow > (XEN) - Extended Page Tables (EPT) > (XEN) - Virtual-Processor Identifiers (VPID) > (XEN) - Virtual NMI > (XEN) - MSR direct-access bitmap > (XEN) - Unrestricted Guest > (XEN) EPT supports 2MB super page. > (XEN) HVM: ASIDs enabled. > (XEN) HVM: VMX enabled > (XEN) HVM: Hardware Assisted Paging detected. > (XEN) Intel VT-d Snoop Control not enabled. > (XEN) Intel VT-d Dom0 DMA Passthrough not enabled. > (XEN) Intel VT-d Queued Invalidation enabled. > (XEN) Intel VT-d Interrupt Remapping enabled. > (XEN) I/O virtualisation enabled > (XEN) - Dom0 mode: Relaxed > (XEN) Enabled directed EOI with ioapic_ack_old on! > (XEN) Total of 8 processors activated. > (XEN) ENABLING IO-APIC IRQs > (XEN) -> Using old ACK method > (XEN) TSC is reliable, synchronization unnecessary > (XEN) Platform timer appears to have unexpectedly wrapped 1 times. > (XEN) Platform timer is 14.318MHz HPET > (XEN) Allocated console ring of 16 KiB. > (XEN) Brought up 8 CPUs > (XEN) *** LOADING DOMAIN 0 *** > (XEN) Xen kernel: 64-bit, lsb, compat32 > (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1ae7000 > (XEN) PHYSICAL MEMORY ARRANGEMENT: > (XEN) Dom0 alloc.: 0000000804000000->0000000806000000 (319488 pages to > be allocated) > (XEN) VIRTUAL MEMORY ARRANGEMENT: > (XEN) Loaded kernel: ffffffff81000000->ffffffff81ae7000 > (XEN) Init. ramdisk: ffffffff81ae7000->ffffffff81ae7000 > (XEN) Phys-Mach map: ffffffff81ae7000->ffffffff81d67000 > (XEN) Start info: ffffffff81d67000->ffffffff81d674b4 > (XEN) Page tables: ffffffff81d68000->ffffffff81d7b000 > (XEN) Boot stack: ffffffff81d7b000->ffffffff81d7c000 > (XEN) TOTAL: ffffffff80000000->ffffffff82000000 > (XEN) ENTRY ADDRESS: ffffffff815e3210 > (XEN) Dom0 has maximum 8 VCPUs > (XEN) [VT-D]iommu.c:718: BIOS did not enable IGD for VT properly. > Disabling IGD VT-d engine. > (XEN) Scrubbing Free RAM: done. > (XEN) Xen trace buffers: disabled > (XEN) Std. Loglevel: Errors and warnings > (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings) > (XEN) Xen is relinquishing VGA console. > (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input > to Xen) > (XEN) Freed 172kB init memory. > (XEN) traps.c:2333:d0 Domain attempted WRMSR 000000000000008b from > 00000012:00000000 to 00000000:00000000. > > - Valtteri > > > 2012/10/1 Pasi K=E4rkk=E4inen > >> On Mon, Oct 01, 2012 at 09:12:50PM +0300, Valtteri Kiviniemi wrote: >> > Hi, >> > >> > Lowering memory or vcpu's does not help, problem is the same. I >> originally >> > installed Xen 4.2.0 and the problem was same on that too. Then I >> > downgraded back to 4.0.4 since I thought that this might be a bug o= n >> > 4.2.0. I have been previously running Windows Server 2008 R2 >> succesfully >> > on Xen 4.0.x on different hardware with this same config. Hyperviso= r >> is >> > 64bit and windows is 64bit. >> > >> > Any ideas what to try next? >> > >> >> What kind of hardware is that? >> >> xen.org automated testing regularly tests Windows VMs, and it works OK >> there. >> >> -- Pasi >> >> > Ps. qemu-dm.log is the following: >> > >> > domid: 10 >> > config qemu network with xen bridge for tap10.0 xenbr0 >> > Using file /dev/virtuals/ts in read-write mode >> > Using file /media/iso/windows_server_2008_r2_sp1.iso in read-only >> mode >> > Watching /local/domain/0/device-model/10/logdirty/cmd >> > Watching /local/domain/0/device-model/10/command >> > qemu_map_cache_init nr_buckets =3D 10000 size 4194304 >> > shared page at pfn feffd >> > buffered io page at pfn feffb >> > Guest uuid =3D 52f19e23-2955-c27d-a22c-60c5d8c60d5a >> > Time offset set 0 >> > populating video RAM at ff000000 >> > mapping video RAM from ff000000 >> > Register xen platform. >> > Done register platform. >> > platform_fixed_ioport: changed ro/rw state of ROM memory area. now >> is rw >> > state. >> > xs_read(/local/domain/0/device-model/10/xen_extended_power_mgmt): >> read >> > error >> > medium change watch on `hdc' (index: 1): >> > /media/iso/windows_server_2008_r2_sp1.iso >> > I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size:= 0 >> > Log-dirty: no command yet. >> > xs_read(/local/domain/10/log-throttling): read error >> > qemu: ignoring not-understood drive `/local/domain/10/log-throttlin= g' >> > medium change watch on `/local/domain/10/log-throttling' - unknown >> device, >> > ignored >> > cirrus vga map change while on lfb mode >> > mapping vram to f0000000 - f0400000 >> > platform_fixed_ioport: changed ro/rw state of ROM memory area. now >> is rw >> > state. >> > platform_fixed_ioport: changed ro/rw state of ROM memory area. now >> is ro >> > state. >> > >> > 2012/10/1 Pasi K=E4rkk=E4inen <[1]pasik@iki.fi> >> > >> > On Mon, Oct 01, 2012 at 07:23:44PM +0300, Valtteri Kiviniemi wrot= e: >> > > Hi, >> > > >> > > I have tried other config files, but the problem is the same= . >> At >> > the >> > > moment I'm using a config file from another server where I >> have a >> > working >> > > Windows Server 2008 R2 installation, so I dont think that >> there is >> > > anything wrong with my config: >> > > >> > >> > Did you try with less vcpus, for example 2 ? >> > how about with less memory, say 2 GB ? >> > >> > Did you try with later Xen versions? Is that a 32bit Xen, or 64bi= t >> Xen >> > hypervisor? >> > >> > -- Pasi >> > > kernel =3D "/usr/lib/xen/boot/hvmloader" >> > > builder =3D "hvm" >> > > shadow_memory =3D "8" >> > > memory =3D "4096" >> > > name =3D "ts" >> > > vcpus =3D "8" >> > > cpus =3D ["0", "1", "2", "3", "4", "5", "6", "7"] >> > > pae =3D "1" >> > > acpi =3D "1" >> > > apic =3D "1" >> > > vfb =3D [ 'type=3Dvnc, vnclisten=3D10.100.100.50, vncpasswd= =3Dxxx' ] >> > > xen_extended_power_mgmt =3D "0" >> > > vif =3D [ "type=3Dioemu, mac=3D00:16:3e:d7:d7:5d, bridge=3Dx= enbr0" ] >> > > disk =3D [ "phy:/dev/virtuals/ts,hda,w", >> > > "file:/media/iso/windows_server_2008_r2_sp1.iso,hdc:cdrom,r"= ] >> > > on_poweroff =3D "destroy" >> > > on_reboot =3D "restart" >> > > on_crash =3D "restart" >> > > viridian =3D "1" >> > > device_model =3D "/usr/lib/xen/bin/qemu-dm" >> > > boot =3D "dc" >> > > snapshot =3D "0" >> > > vncconsole =3D "1" >> > > sdl =3D "0" >> > > opengl =3D "0" >> > > vnc =3D "1" >> > > nographic =3D "0" >> > > stdvga =3D "0" >> > > tsc_mode =3D "1" >> > > monitor =3D "0" >> > > localtime =3D "1" >> > > usb =3D "0" >> > > keymap =3D "fi" >> > > xen_platform_pci =3D "1" >> > > pci_msitranslate =3D "1" >> > > pci_power_mgmt =3D "0" >> > > >> > > 2012/10/1 Pasi K=E4rkk=E4inen <[1][2]pasik@iki.fi> >> > > >> > > On Mon, Oct 01, 2012 at 06:46:08PM +0300, Valtteri Kivinie= mi >> > wrote: >> > > > Hi, >> > > > >> > > > Yes, I have viridian=3D1 on my domU config. >> > > > >> > > >> > > Try with some known good domU configfile. >> > > >> > > -- Pasi >> > > > 2012/10/1 Pasi K=E4rkk=E4inen <[1][2][3]pasik@iki.fi> >> > > > >> > > > On Mon, Oct 01, 2012 at 05:06:53PM +0300, Valtteri >> > Kiviniemi >> > > wrote: >> > > > > Hi, >> > > > > >> > > > > I'm now using 3.6.0 and can't reproduce that >> crash >> > anymore, >> > > so it >> > > > seems >> > > > > that it was a kernel bug. >> > > > > >> > > > >> > > > OK. >> > > > > However I'm still getting black screen on VNC >> > > > > when trying to install Windows Server 2008 R2. >> I can >> > see the >> > > > "windows is >> > > > > loading files" screen but after the installer >> starts >> > the VNC >> > > > display goes >> > > > > black. >> > > > > >> > > > > Any ideas? >> > > > > >> > > > >> > > > Do you have viridian=3D1 specified for the windows = vm? >> > > > >> > > > -- Pasi >> > > > >> > > > > - Valtteri >> > > > > >> > > > > 2012/10/1 Pasi K=E4rkk=E4inen <[1][2][3][4] >> pasik@iki.fi> >> > > > > >> > > > > On Sun, Sep 30, 2012 at 11:18:03PM +0300, >> Valtteri >> > > Kiviniemi >> > > > wrote: >> > > > > > Hi, >> > > > > > >> > > > > >> > > > > Hello, >> > > > > > I'm trying to get Windows Server 2008 R= 2 >> > installation >> > > > booting on >> > > > > Xen >> > > > > > 4.0.4. Using the following config: >> > > > > > >> > > > > >> > > > > >> > > > > > >> > > > > > The domU will start booting just fine, >> but >> > after a >> > > few >> > > > minutes the >> > > > > VNC >> > > > > > screen goes black. After that when >> typing "xm >> > destroy >> > > ts" it >> > > > will >> > > > > trigger >> > > > > > a kernel BUG: >> > > > > > >> > > > > > BUG: unable to handle kernel NULL point= er >> > dereference >> > > at >> > > > > 0000000000000030 >> > > > > > IP: [] iput+0x3e/0x19= 5 >> > > > > > PGD 0 >> > > > > > Oops: 0000 [#1] SMP >> > > > > > CPU 6 >> > > > > > Pid: 3571, comm: qemu-dm Not tainted >> > 3.5.0-dom0 #1 >> > > > > >> > > > > First of all upgrade to latest 3.5.x Linux >> kernel >> > release >> > > .. so >> > > > at least >> > > > > 3.5.4. >> > > > > >> > > > > -- Pasi >> > > > > >> > > > > > /DQ77MK >> > > > > > RIP: e030:[] >> > [] >> > > > > iput+0x3e/0x195 >> > > > > > RSP: e02b:ffff8800389ffbf8 EFLAGS: >> 00010246 >> > > > > > RAX: 0000000000000001 RBX: >> ffff8800377b0720 >> > RCX: >> > > > ffff8800501c0000 >> > > > > > RDX: ffff8800501c0000 RSI: >> ffff8800377b0790 >> > RDI: >> > > > ffff8800377b0790 >> > > > > > RBP: 0000000000000000 R08: >> ffffffff815cdd00 >> > R09: >> > > > 0000000000000016 >> > > > > > R10: fefefefefefefeff R11: >> ffff8800377b0400 >> > R12: >> > > > 00000001000a3e0c >> > > > > > R13: 0000000000000000 R14: >> 00000001000a3e0c >> > R15: >> > > > ffff8800389ffc28 >> > > > > > FS: 00007f1af70a8700(0000) >> > GS:ffff880050180000(0000) >> > > > > > knlGS:0000000000000000 >> > > > > > CS: e033 DS: 0000 ES: 0000 CR0: >> > 000000008005003b >> > > > > > CR2: 0000000000000030 CR3: >> 000000000156d000 >> > CR4: >> > > > 0000000000002660 >> > > > > > DR0: 0000000000000000 DR1: >> 0000000000000000 >> > DR2: >> > > > 0000000000000000 >> > > > > > DR3: 0000000000000000 DR6: >> 00000000ffff0ff0 >> > DR7: >> > > > 0000000000000400 >> > > > > > Process qemu-dm (pid: 3571, threadinfo >> > > ffff8800389fe000, >> > > > task >> > > > > > ffff88003a721260) >> > > > > > Stack: >> > > > > > ffff88003a6d6400 ffff8800377b0000 >> > 00000001000a3e0c >> > > > > ffffffff8133ce8f >> > > > > > ffff8800377b0400 ffffffff8134b6cd >> > ffff8800389ffc28 >> > > > > ffff8800389ffc28 >> > > > > > ffff8800377b00f8 ffff8800377b0680 >> > ffff880038cdcd60 >> > > > > ffff8800377b0000 >> > > > > > Call Trace: >> > > > > > [] ? >> > sk_release_kernel+0x23/0x39 >> > > > > > [] ? >> > netdev_run_todo+0x1e9/0x206 >> > > > > > [] ? >> > tun_chr_close+0x4c/0x7b >> > > > > > [] ? fput+0xe4/0x1c5 >> > > > > > [] ? >> filp_close+0x61/0x68 >> > > > > > [] ? >> > put_files_struct+0x62/0xb9 >> > > > > > [] ? >> do_exit+0x24a/0x74c >> > > > > > [] ? >> > do_group_exit+0x6b/0x9d >> > > > > > [] ? >> > > get_signal_to_deliver+0x449/0x46e >> > > > > > [] ? >> do_signal+0x28/0x4c4 >> > > > > > [] ? >> > > pvclock_clocksource_read+0x48/0xbf >> > > > > > [] ? >> ktime_get_ts+0x66/0xa8 >> > > > > > [] ? >> > > poll_select_copy_remaining+0xe0/0xf5 >> > > > > > [] ? >> > do_notify_resume+0x3b/0x74 >> > > > > > [] ? >> int_signal+0x12/0x17 >> > > > > > Code: 00 00 00 40 74 02 0f 0b 48 8d 77 >> 70 48 >> > 8d bf 08 >> > > 01 00 >> > > > 00 e8 >> > > > > 8b 71 10 >> > > > > > 00 85 c0 0f 84 5d 01 00 00 48 8b 6b 18 >> f6 83 >> > 80 00 00 >> > > 00 08 >> > > > <4c> 8b >> > > > > 65 30 >> > > > > > 74 11 be 68 05 00 00 48 c7 c7 8e df 4f >> 81 e8 >> > bb d0 >> > > > > > RIP [] iput+0x3e/0x1= 95 >> > > > > > RSP >> > > > > > CR2: 0000000000000030 >> > > > > > ---[ end trace 67cc1654658fedcc ]--- >> > > > > > Fixing recursive fault but reboot is >> needed! >> > > > > > >> > > > > > I also tested Xen 4.2.0 and problem is >> the >> > same. So >> > > is this >> > > > a Xen >> > > > > bug or a >> > > > > > kernel bug? I am running vanilla >> > > [1][2][3][4][5]kernel.org kernel >> > > > 3.5.0 and >> > > > > my >> > > > > > hardware is Intel Core i7-3770 CPU and >> Intel >> > DQ77MK >> > > > motherboard >> > > > > with >> > > > > > latest bios. >> > > > > > >> > > > > > Best regards, >> > > > > > Valtteri Kiviniemi >> > > > > > >> > > > > > References >> > > > > > >> > > > > > Visible links >> > > > > > 1. [3][4][5][6]http://kernel.org/ >> > > > > >> > > > > > >> _______________________________________________ >> > > > > > Xen-devel mailing list >> > > > > > [4][5][6][7]Xen-devel@lists.xen.org >> > > > > > [5][6][7][8]http://lists.xen.org/xen-devel >> > > > > >> > > > > References >> > > > > >> > > > > Visible links >> > > > > 1. mailto:[7][8][9]pasik@iki.fi >> > > > > 2. [8][9][10]http://kernel.org/ >> > > > > 3. [9][10][11]http://kernel.org/ >> > > > > 4. mailto:[10][11][12]Xen-devel@lists.xen.org >> > > > > 5. [11][12][13]http://lists.xen.org/xen-devel >> > > > >> > > > References >> > > > >> > > > Visible links >> > > > 1. mailto:[13][14]pasik@iki.fi >> > > > 2. mailto:[14][15]pasik@iki.fi >> > > > 3. [15][16]http://kernel.org/ >> > > > 4. [16][17]http://kernel.org/ >> > > > 5. mailto:[17][18]Xen-devel@lists.xen.org >> > > > 6. [18][19]http://lists.xen.org/xen-devel >> > > > 7. mailto:[19][20]pasik@iki.fi >> > > > 8. [20][21]http://kernel.org/ >> > > > 9. [21][22]http://kernel.org/ >> > > > 10. mailto:[22][23]Xen-devel@lists.xen.org >> > > > 11. [23][24]http://lists.xen.org/xen-devel >> > > >> > > References >> > > >> > > Visible links >> > > 1. mailto:[25]pasik@iki.fi >> > > 2. mailto:[26]pasik@iki.fi >> > > 3. mailto:[27]pasik@iki.fi >> > > 4. [28]http://kernel.org/ >> > > 5. [29]http://kernel.org/ >> > > 6. mailto:[30]Xen-devel@lists.xen.org >> > > 7. [31]http://lists.xen.org/xen-devel >> > > 8. mailto:[32]pasik@iki.fi >> > > 9. [33]http://kernel.org/ >> > > 10. [34]http://kernel.org/ >> > > 11. mailto:[35]Xen-devel@lists.xen.org >> > > 12. [36]http://lists.xen.org/xen-devel >> > > 13. mailto:[37]pasik@iki.fi >> > > 14. mailto:[38]pasik@iki.fi >> > > 15. [39]http://kernel.org/ >> > > 16. [40]http://kernel.org/ >> > > 17. mailto:[41]Xen-devel@lists.xen.org >> > > 18. [42]http://lists.xen.org/xen-devel >> > > 19. mailto:[43]pasik@iki.fi >> > > 20. [44]http://kernel.org/ >> > > 21. [45]http://kernel.org/ >> > > 22. mailto:[46]Xen-devel@lists.xen.org >> > > 23. [47]http://lists.xen.org/xen-devel >> > >> > References >> > >> > Visible links >> > 1. mailto:pasik@iki.fi >> > 2. mailto:pasik@iki.fi >> > 3. mailto:pasik@iki.fi >> > 4. mailto:pasik@iki.fi >> > 5. http://kernel.org/ >> > 6. http://kernel.org/ >> > 7. mailto:Xen-devel@lists.xen.org >> > 8. http://lists.xen.org/xen-devel >> > 9. mailto:pasik@iki.fi >> > 10. http://kernel.org/ >> > 11. http://kernel.org/ >> > 12. mailto:Xen-devel@lists.xen.org >> > 13. http://lists.xen.org/xen-devel >> > 14. mailto:pasik@iki.fi >> > 15. mailto:pasik@iki.fi >> > 16. http://kernel.org/ >> > 17. http://kernel.org/ >> > 18. mailto:Xen-devel@lists.xen.org >> > 19. http://lists.xen.org/xen-devel >> > 20. mailto:pasik@iki.fi >> > 21. http://kernel.org/ >> > 22. http://kernel.org/ >> > 23. mailto:Xen-devel@lists.xen.org >> > 24. http://lists.xen.org/xen-devel >> > 25. mailto:pasik@iki.fi >> > 26. mailto:pasik@iki.fi >> > 27. mailto:pasik@iki.fi >> > 28. http://kernel.org/ >> > 29. http://kernel.org/ >> > 30. mailto:Xen-devel@lists.xen.org >> > 31. http://lists.xen.org/xen-devel >> > 32. mailto:pasik@iki.fi >> > 33. http://kernel.org/ >> > 34. http://kernel.org/ >> > 35. mailto:Xen-devel@lists.xen.org >> > 36. http://lists.xen.org/xen-devel >> > 37. mailto:pasik@iki.fi >> > 38. mailto:pasik@iki.fi >> > 39. http://kernel.org/ >> > 40. http://kernel.org/ >> > 41. mailto:Xen-devel@lists.xen.org >> > 42. http://lists.xen.org/xen-devel >> > 43. mailto:pasik@iki.fi >> > 44. http://kernel.org/ >> > 45. http://kernel.org/ >> > 46. mailto:Xen-devel@lists.xen.org >> > 47. http://lists.xen.org/xen-devel >> > > --20cf303a2e35c41b0104cb126a25 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

Another update:

I wanted to check that if a Linux HVM= would boot with working VNC console, so I tried to launch a Debian Squeeze= installer on HVM. It refused to start ant told me that vbd hotplug scripts= were not working. After that failure even the Windows domU would not anymo= re start which was previously starting ok.

The hotplug scripts also starts hanging on the processes.

root= =A0=A0=A0=A0=A0 9401=A0 0.1=A0 0.1=A0 17700=A0 1640 ?=A0=A0=A0=A0=A0=A0=A0 = S=A0=A0=A0 15:05=A0=A0 0:00 /bin/bash /etc/xen/scripts/xen-hotplug-cleanup<= br>root=A0=A0=A0=A0=A0 9441=A0 0.1=A0 0.1=A0 17700=A0 1644 ?=A0=A0=A0=A0=A0= =A0=A0 S=A0=A0=A0 15:05=A0=A0 0:00 /bin/bash /etc/xen/scripts/xen-hotplug-c= leanup
root=A0=A0=A0=A0=A0 9481=A0 0.1=A0 0.1=A0 17700=A0 1640 ?=A0=A0=A0=A0=A0=A0= =A0 S=A0=A0=A0 15:05=A0=A0 0:00 /bin/bash /etc/xen/scripts/xen-hotplug-clea= nup
root=A0=A0=A0=A0=A0 9560=A0 0.1=A0 0.1=A0 17700=A0 1640 ?=A0=A0=A0= =A0=A0=A0=A0 S=A0=A0=A0 15:05=A0=A0 0:00 /bin/bash /etc/xen/scripts/xen-hot= plug-cleanup
root=A0=A0=A0=A0 10738=A0 0.1=A0 0.1=A0 17696=A0 1636 ?=A0=A0=A0=A0=A0=A0= =A0 S=A0=A0=A0 15:05=A0=A0 0:00 /bin/bash /etc/xen/scripts/xen-hotplug-clea= nup
root=A0=A0=A0=A0 10747=A0 0.1=A0 0.1=A0 17792=A0 1736 ?=A0=A0=A0=A0= =A0=A0=A0 S=A0=A0=A0 15:05=A0=A0 0:00 /bin/bash /etc/xen/scripts/block remo= ve
root=A0=A0=A0=A0 11286=A0 0.0=A0 0.0=A0=A0 4080=A0=A0 324 ?=A0=A0=A0=A0=A0= =A0=A0 S=A0=A0=A0 15:06=A0=A0 0:00 sleep 1
root=A0=A0=A0=A0 11290=A0 0.0= =A0 0.0=A0=A0 4080=A0=A0 324 ?=A0=A0=A0=A0=A0=A0=A0 S=A0=A0=A0 15:06=A0=A0 = 0:00 sleep 1
root=A0=A0=A0=A0 11294=A0 0.0=A0 0.0=A0=A0 4080=A0=A0 324 ?= =A0=A0=A0=A0=A0=A0=A0 S=A0=A0=A0 15:06=A0=A0 0:00 sleep 1
root=A0=A0=A0=A0 11298=A0 0.0=A0 0.0=A0=A0 4080=A0=A0 324 ?=A0=A0=A0=A0=A0= =A0=A0 S=A0=A0=A0 15:06=A0=A0 0:00 sleep 1
root=A0=A0=A0=A0 11302=A0 0.0= =A0 0.0=A0=A0 4080=A0=A0 320 ?=A0=A0=A0=A0=A0=A0=A0 S=A0=A0=A0 15:06=A0=A0 = 0:00 sleep 1
root=A0=A0=A0=A0 11306=A0 0.0=A0 0.0=A0=A0 4080=A0=A0 320 ?= =A0=A0=A0=A0=A0=A0=A0 S=A0=A0=A0 15:06=A0=A0 0:00 sleep 1

Then I did a xm destroy and I had again the kernel BUG on dmesg. So it = seems that the problem is not fixed by using 3.6.0. Udev version is 175-7.<= br>
=A0


2012/10/1 Valtteri Kivinie= mi <kiviniemi.valtteri@gmail.com>
Hi,

CPU: Intel Core i7-3770 3.4GHzhttp://= ark.intel.com/products/65719/

MB: Intel DQ77MK (latest bios updated)
http://www.intel.com/content/www/us/en/motherboard= s/desktop-motherboards/desktop-board-dq77mk.html

Memory: 32GB (4 x 8GB DDR3-1600MHz)

Host is Debian wheezy/testin= g, Xen 4.0.4 and latest 3.6.0 kernel.

Noticed also some errors in xm= dmesg:

root@xen-2:~# xm dmesg

(XEN) Xen version 4.0.4 (root@dataproof.fi) (g= cc version 4.7.1 (Debian 4.7.1-7) ) Sun Sep 30 20:28:26 EEST 2012
(XEN) Latest ChangeSet: unavailable
(XEN) Bootloader: GNU GRUB 0.97
(= XEN) Command line: dom0_mem=3D1280M cpufreq=3Dxen clocksource=3Dhpet
(XE= N) Video information:
(XEN)=A0 VGA is text mode 80x25, font 8x16
(XEN= )=A0 VBE/DDC methods: none; EDID transfer time: 0 seconds
(XEN)=A0 EDID info not retrieved because no DDC retrieval method detected(XEN) Disc information:
(XEN)=A0 Found 4 MBR signatures
(XEN)=A0 Fo= und 4 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)=A0 000= 0000000000000 - 000000000009d800 (usable)
(XEN)=A0 000000000009d800 - 00000000000a0000 (reserved)
(XEN)=A0 0000000= 0000e0000 - 0000000000100000 (reserved)
(XEN)=A0 0000000000100000 - 0000= 000020000000 (usable)
(XEN)=A0 0000000020000000 - 0000000020200000 (rese= rved)
(XEN)=A0 0000000020200000 - 0000000040004000 (usable)
(XEN)=A0 000000004= 0004000 - 0000000040005000 (reserved)
(XEN)=A0 0000000040005000 - 000000= 00dbe44000 (usable)
(XEN)=A0 00000000dbe44000 - 00000000dc2d7000 (reserv= ed)
(XEN)=A0 00000000dc2d7000 - 00000000dc2e7000 (ACPI data)
(XEN)=A0 000000= 00dc2e7000 - 00000000dc40c000 (ACPI NVS)
(XEN)=A0 00000000dc40c000 - 000= 00000dc6af000 (reserved)
(XEN)=A0 00000000dc6af000 - 00000000dc6b0000 (u= sable)
(XEN)=A0 00000000dc6b0000 - 00000000dc6f3000 (ACPI NVS)
(XEN)=A0 0000000= 0dc6f3000 - 00000000dd000000 (usable)
(XEN)=A0 00000000dd800000 - 000000= 00dfa00000 (reserved)
(XEN)=A0 00000000f8000000 - 00000000fc000000 (rese= rved)
(XEN)=A0 00000000fec00000 - 00000000fec01000 (reserved)
(XEN)=A0 0000000= 0fed00000 - 00000000fed04000 (reserved)
(XEN)=A0 00000000fed1c000 - 0000= 0000fed20000 (reserved)
(XEN)=A0 00000000fee00000 - 00000000fee01000 (re= served)
(XEN)=A0 00000000ff000000 - 0000000100000000 (reserved)
(XEN)=A0 0000000= 100000000 - 000000081e600000 (usable)
(XEN) ACPI: RSDP 000F0490, 0024 (r= 2=A0 INTEL)
(XEN) ACPI: XSDT DC2DB080, 007C (r1 INTEL=A0 DQ77MK=A0=A0=A0= =A0=A0=A0=A0=A0 32 AMI=A0=A0=A0=A0 10013)
(XEN) ACPI: FACP DC2E51F0, 010C (r5 INTEL=A0 DQ77MK=A0=A0=A0=A0=A0=A0=A0=A0= 32 AMI=A0=A0=A0=A0 10013)
(XEN) ACPI Warning (tbfadt-0232): FADT (revis= ion 5) is longer than ACPI 2.0 version, truncating length 0x10C to 0xF4 [20= 070126]
(XEN) ACPI: DSDT DC2DB188, A061 (r2 INTEL=A0 DQ77MK=A0=A0=A0=A0= =A0=A0=A0=A0 32 INTL 20051117)
(XEN) ACPI: FACS DC40A080, 0040
(XEN) ACPI: APIC DC2E5300, 0092 (r3 INTE= L=A0 DQ77MK=A0=A0=A0=A0=A0=A0=A0=A0 32 AMI=A0=A0=A0=A0 10013)
(XEN) ACPI= : FPDT DC2E5398, 0044 (r1 INTEL=A0 DQ77MK=A0=A0=A0=A0=A0=A0=A0=A0 32 AMI=A0= =A0=A0=A0 10013)
(XEN) ACPI: TCPA DC2E53E0, 0032 (r2 INTEL=A0 DQ77MK=A0= =A0=A0=A0=A0=A0=A0=A0 32 MSFT=A0 1000013)
(XEN) ACPI: MCFG DC2E5418, 003C (r1 INTEL=A0 DQ77MK=A0=A0=A0=A0=A0=A0=A0=A0= 32 MSFT=A0=A0=A0=A0=A0=A0 97)
(XEN) ACPI: HPET DC2E5458, 0038 (r1 INTEL= =A0 DQ77MK=A0=A0=A0=A0=A0=A0=A0=A0 32 AMI.=A0=A0=A0=A0=A0=A0=A0 5)
(XEN)= ACPI: SSDT DC2E5490, 036D (r1 INTEL=A0 DQ77MK=A0=A0=A0=A0=A0=A0=A0=A0 32 I= NTL 20091112)
(XEN) ACPI: SSDT DC2E5800, 09AA (r1 INTEL=A0 DQ77MK=A0=A0=A0=A0=A0=A0=A0=A0= 32 INTL 20051117)
(XEN) ACPI: SSDT DC2E61B0, 0A92 (r1 INTEL=A0 DQ77MK= =A0=A0=A0=A0=A0=A0=A0=A0 32 INTL 20051117)
(XEN) ACPI: DMAR DC2E6C48, 00= B8 (r1 INTEL=A0 DQ77MK=A0=A0=A0=A0=A0=A0=A0=A0 32 INTL=A0=A0=A0=A0=A0=A0=A0= 1)
(XEN) ACPI: ASF! DC2E6D00, 00A5 (r32 INTEL=A0 DQ77MK=A0=A0=A0=A0=A0=A0=A0= =A0 32 TFSM=A0=A0=A0 F4240)
(XEN) System RAM: 32682MB (33467320kB)
(X= EN) Domain heap initialised
(XEN) ACPI: 32/64X FACS address mismatch in = FADT - dc40a080/0000000000000000, using 32
(XEN) Processor #0 7:10 APIC version 21
(XEN) Processor #2 7:10 APIC ver= sion 21
(XEN) Processor #4 7:10 APIC version 21
(XEN) Processor #6 7:= 10 APIC version 21
(XEN) Processor #1 7:10 APIC version 21
(XEN) Proc= essor #3 7:10 APIC version 21
(XEN) Processor #5 7:10 APIC version 21
(XEN) Processor #7 7:10 APIC ver= sion 21
(XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI = 0-23
(XEN) Enabling APIC mode:=A0 Flat.=A0 Using 1 I/O APICs
(XEN) Sw= itched to APIC driver x2apic_cluster.
(XEN) x2APIC mode enabled.
(XEN) Using scheduler: SMP Credit Scheduler (= credit)
(XEN) Detected 3392.369 MHz processor.
(XEN) Initing memory s= haring.
(XEN) VMX: Supported advanced features:
(XEN)=A0 - APIC MMIO = access virtualisation
(XEN)=A0 - APIC TPR shadow
(XEN)=A0 - Extended Page Tables (EPT)
(XEN= )=A0 - Virtual-Processor Identifiers (VPID)
(XEN)=A0 - Virtual NMI
(X= EN)=A0 - MSR direct-access bitmap
(XEN)=A0 - Unrestricted Guest
(XEN)= EPT supports 2MB super page.
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware = Assisted Paging detected.
(XEN) Intel VT-d Snoop Control not enabled.(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
(XEN) Intel VT-d Que= ued Invalidation enabled.
(XEN) Intel VT-d Interrupt Remapping enabled.
(XEN) I/O virtualisation e= nabled
(XEN)=A0 - Dom0 mode: Relaxed
(XEN) Enabled directed EOI with = ioapic_ack_old on!
(XEN) Total of 8 processors activated.
(XEN) ENABL= ING IO-APIC IRQs
(XEN)=A0 -> Using old ACK method
(XEN) TSC is reliable, synchronizati= on unnecessary
(XEN) Platform timer appears to have unexpectedly wrapped= 1 times.
(XEN) Platform timer is 14.318MHz HPET
(XEN) Allocated cons= ole ring of 16 KiB.
(XEN) Brought up 8 CPUs
(XEN) *** LOADING DOMAIN 0 ***
(XEN)=A0 Xen= =A0 kernel: 64-bit, lsb, compat32
(XEN)=A0 Dom0 kernel: 64-bit, PAE, lsb= , paddr 0x1000000 -> 0x1ae7000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
= (XEN)=A0 Dom0 alloc.:=A0=A0 0000000804000000->0000000806000000 (319488 p= ages to be allocated)
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)=A0 Loaded kernel: ffffffff810000= 00->ffffffff81ae7000
(XEN)=A0 Init. ramdisk: ffffffff81ae7000->fff= fffff81ae7000
(XEN)=A0 Phys-Mach map: ffffffff81ae7000->ffffffff81d67= 000
(XEN)=A0 Start info:=A0=A0=A0 ffffffff81d67000->ffffffff81d674b4
(XEN= )=A0 Page tables:=A0=A0 ffffffff81d68000->ffffffff81d7b000
(XEN)=A0 B= oot stack:=A0=A0=A0 ffffffff81d7b000->ffffffff81d7c000
(XEN)=A0 TOTAL= :=A0=A0=A0=A0=A0=A0=A0=A0 ffffffff80000000->ffffffff82000000
(XEN)=A0 ENTRY ADDRESS: ffffffff815e3210
(XEN) Dom0 has maximum 8 VCPUs<= br>(XEN) [VT-D]iommu.c:718: BIOS did not enable IGD for VT properly.=A0 Dis= abling IGD VT-d engine.
(XEN) Scrubbing Free RAM: done.
(XEN) Xen tra= ce buffers: disabled
(XEN) Std. Loglevel: Errors and warnings
(XEN) Guest Loglevel: Nothing (= Rate-limited: Errors and warnings)
(XEN) Xen is relinquishing VGA consol= e.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times = to switch input to Xen)
(XEN) Freed 172kB init memory.
(XEN) traps.c:2333:d0 Domain attempted WR= MSR 000000000000008b from 00000012:00000000 to 00000000:00000000.

- Valtteri


2012/10/1 Pasi K=E4rkk= =E4inen <pasik@iki.fi>
On Mon, Oct 01, 2012 at 09:12:50PM +030= 0, Valtteri Kiviniemi wrote:
> =A0 =A0Hi,
>
> =A0 =A0Lowering memory or vcpu's does not help, problem= is the same. I originally
> =A0 =A0installed Xen 4.2.0 and the problem was same on that too. Then = I
> =A0 =A0downgraded back to 4.0.4 since I thought that this might be a b= ug on
> =A0 =A04.2.0. I have been previously running Windows Server 2008 R2 su= ccesfully
> =A0 =A0on Xen 4.0.x on different hardware with this same config. Hyper= visor is
> =A0 =A064bit and windows is 64bit.
>
> =A0 =A0Any ideas what to try next?
>

What kind of hardware is that?

xen.org automated testing = regularly tests Windows VMs, and it works OK there.

-- Pasi

> =A0 =A0Ps. qemu-dm.log is the following:
>
> =A0 =A0domid: 10
> =A0 =A0config qemu network with xen bridge for =A0tap10.0 xenbr0
> =A0 =A0Using file /dev/virtuals/ts in read-write mode
> =A0 =A0Using file /media/iso/windows_server_2008_r2_sp1.iso in read-on= ly mode
> =A0 =A0Watching /local/domain/0/device-model/10/logdirty/cmd
> =A0 =A0Watching /local/domain/0/device-model/10/command
> =A0 =A0qemu_map_cache_init nr_buckets =3D 10000 size 4194304
> =A0 =A0shared page at pfn feffd
> =A0 =A0buffered io page at pfn feffb
> =A0 =A0Guest uuid =3D 52f19e23-2955-c27d-a22c-60c5d8c60d5a
> =A0 =A0Time offset set 0
> =A0 =A0populating video RAM at ff000000
> =A0 =A0mapping video RAM from ff000000
> =A0 =A0Register xen platform.
> =A0 =A0Done register platform.
> =A0 =A0platform_fixed_ioport: changed ro/rw state of ROM memory area. = now is rw
> =A0 =A0state.
> =A0 =A0xs_read(/local/domain/0/device-model/10/xen_extended_power_mgmt= ): read
> =A0 =A0error
> =A0 =A0medium change watch on `hdc' (index: 1):
> =A0 =A0/media/iso/windows_server_2008_r2_sp1.iso
> =A0 =A0I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, s= ize: 0
> =A0 =A0Log-dirty: no command yet.
> =A0 =A0xs_read(/local/domain/10/log-throttling): read error
> =A0 =A0qemu: ignoring not-understood drive `/local/domain/10/log-throt= tling'
> =A0 =A0medium change watch on `/local/domain/10/log-throttling' - = unknown device,
> =A0 =A0ignored
> =A0 =A0cirrus vga map change while on lfb mode
> =A0 =A0mapping vram to f0000000 - f0400000
> =A0 =A0platform_fixed_ioport: changed ro/rw state of ROM memory area. = now is rw
> =A0 =A0state.
> =A0 =A0platform_fixed_ioport: changed ro/rw state of ROM memory area. = now is ro
> =A0 =A0state.
>
> =A0 =A02012/10/1 Pasi K=E4rkk=E4inen <[1]pasik@iki.fi>
>
> =A0 =A0 =A0On Mon, Oct 01, 2012 at 07:23:44PM +0300, Valtteri Kiviniem= i wrote:
> =A0 =A0 =A0> =A0 =A0Hi,
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0I have tried other config files, but the proble= m is the same. At
> =A0 =A0 =A0the
> =A0 =A0 =A0> =A0 =A0moment I'm using a config file from another= server where I have a
> =A0 =A0 =A0working
> =A0 =A0 =A0> =A0 =A0Windows Server 2008 R2 installation, so I dont = think that there is
> =A0 =A0 =A0> =A0 =A0anything wrong with my config:
> =A0 =A0 =A0>
>
> =A0 =A0 =A0Did you try with less vcpus, for example 2 ?
> =A0 =A0 =A0how about with less memory, say 2 GB ?
>
> =A0 =A0 =A0Did you try with later Xen versions? Is that a 32bit Xen, o= r 64bit Xen
> =A0 =A0 =A0hypervisor?
>
> =A0 =A0 =A0-- Pasi
> =A0 =A0 =A0> =A0 =A0kernel =3D "/usr/lib/xen/boot/hvmloader&qu= ot;
> =A0 =A0 =A0> =A0 =A0builder =3D "hvm"
> =A0 =A0 =A0> =A0 =A0shadow_memory =3D "8"
> =A0 =A0 =A0> =A0 =A0memory =3D "4096"
> =A0 =A0 =A0> =A0 =A0name =3D "ts"
> =A0 =A0 =A0> =A0 =A0vcpus =3D "8"
> =A0 =A0 =A0> =A0 =A0cpus =3D ["0", "1", "2= ", "3", "4", "5", "6", "7= "]
> =A0 =A0 =A0> =A0 =A0pae =3D "1"
> =A0 =A0 =A0> =A0 =A0acpi =3D "1"
> =A0 =A0 =A0> =A0 =A0apic =3D "1"
> =A0 =A0 =A0> =A0 =A0vfb =3D [ 'type=3Dvnc, vnclisten=3D10.100.1= 00.50, vncpasswd=3Dxxx' ]
> =A0 =A0 =A0> =A0 =A0xen_extended_power_mgmt =3D "0"
> =A0 =A0 =A0> =A0 =A0vif =3D [ "type=3Dioemu, mac=3D00:16:3e:d7= :d7:5d, bridge=3Dxenbr0" ]
> =A0 =A0 =A0> =A0 =A0disk =3D [ "phy:/dev/virtuals/ts,hda,w&quo= t;,
> =A0 =A0 =A0> =A0 =A0"file:/media/iso/windows_server_2008_r2_sp= 1.iso,hdc:cdrom,r" ]
> =A0 =A0 =A0> =A0 =A0on_poweroff =3D "destroy"
> =A0 =A0 =A0> =A0 =A0on_reboot =3D "restart"
> =A0 =A0 =A0> =A0 =A0on_crash =3D "restart"
> =A0 =A0 =A0> =A0 =A0viridian =3D "1"
> =A0 =A0 =A0> =A0 =A0device_model =3D "/usr/lib/xen/bin/qemu-dm= "
> =A0 =A0 =A0> =A0 =A0boot =3D "dc"
> =A0 =A0 =A0> =A0 =A0snapshot =3D "0"
> =A0 =A0 =A0> =A0 =A0vncconsole =3D "1"
> =A0 =A0 =A0> =A0 =A0sdl =3D "0"
> =A0 =A0 =A0> =A0 =A0opengl =3D "0"
> =A0 =A0 =A0> =A0 =A0vnc =3D "1"
> =A0 =A0 =A0> =A0 =A0nographic =3D "0"
> =A0 =A0 =A0> =A0 =A0stdvga =3D "0"
> =A0 =A0 =A0> =A0 =A0tsc_mode =3D "1"
> =A0 =A0 =A0> =A0 =A0monitor =3D "0"
> =A0 =A0 =A0> =A0 =A0localtime =3D "1"
> =A0 =A0 =A0> =A0 =A0usb =3D "0"
> =A0 =A0 =A0> =A0 =A0keymap =3D "fi"
> =A0 =A0 =A0> =A0 =A0xen_platform_pci =3D "1"
> =A0 =A0 =A0> =A0 =A0pci_msitranslate =3D "1"
> =A0 =A0 =A0> =A0 =A0pci_power_mgmt =3D "0"
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A02012/10/1 Pasi K=E4rkk=E4= inen <[1][2][3]pasik@i= ki.fi>
> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0On Mon, Oct 01, 2012 at 05:= 06:53PM +0300, Valtteri
> =A0 =A0 =A0Kiviniemi
> =A0 =A0 =A0> =A0 =A0 =A0wrote:
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0Hi,
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0I'm now usi= ng 3.6.0 and can't reproduce that crash
> =A0 =A0 =A0anymore,
> =A0 =A0 =A0> =A0 =A0 =A0so it
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0seems
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0that it was a k= ernel bug.
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0OK.
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0However I'm= still getting black screen on VNC
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0when trying to = install Windows Server 2008 R2. I can
> =A0 =A0 =A0see the
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0"windows is
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0loading files&q= uot; screen but after the installer starts
> =A0 =A0 =A0the VNC
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0display goes
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0black.
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0Any ideas?
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0Do you have viridian=3D1 sp= ecified for the windows vm?
> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0-- Pasi
> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0- Valtteri
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A02012/10/1= Pasi K=E4rkk=E4inen <[1][2][3][4]pasik@iki.fi>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0On Sun, Sep= 30, 2012 at 11:18:03PM +0300, Valtteri
> =A0 =A0 =A0> =A0 =A0 =A0Kiviniemi
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0wrote:
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0Hi,
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0Hello,
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0I'm trying to get Windows Server 2008 R2
> =A0 =A0 =A0installation
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0booting on
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0Xen
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A04.0.4. Using the following config:
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0<snip>= ;
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0The domU will start booting just fine, but
> =A0 =A0 =A0after a
> =A0 =A0 =A0> =A0 =A0 =A0few
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0minutes the
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0VNC
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0screen goes black. After that when typing "xm
> =A0 =A0 =A0destroy
> =A0 =A0 =A0> =A0 =A0 =A0ts" it
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0will
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0trigger
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0a kernel BUG:
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0BUG: unable to handle kernel NULL pointer
> =A0 =A0 =A0dereference
> =A0 =A0 =A0> =A0 =A0 =A0at
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A000000000000= 00030
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0IP: [<ffffffff810c50c4>] iput+0x3e/0x195
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0PGD 0
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0Oops: 0000 [#1] SMP
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0CPU 6
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0Pid: 3571, comm: qemu-dm Not tainted
> =A0 =A0 =A03.5.0-dom0 #1
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0First of al= l upgrade to latest 3.5.x Linux kernel
> =A0 =A0 =A0release
> =A0 =A0 =A0> =A0 =A0 =A0.. so
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0at least
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A03.5.4.
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0-- Pasi
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0/DQ77MK
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0RIP: e030:[<ffffffff810c50c4>]
> =A0 =A0 =A0 [<ffffffff810c50c4>]
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0iput+0x3e/0= x195
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0RSP: e02b:ffff8800389ffbf8 =A0EFLAGS: 00010246
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0RAX: 0000000000000001 RBX: ffff8800377b0720
> =A0 =A0 =A0RCX:
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0ffff8800501c0000
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0RDX: ffff8800501c0000 RSI: ffff8800377b0790
> =A0 =A0 =A0RDI:
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0ffff8800377b0790
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0RBP: 0000000000000000 R08: ffffffff815cdd00
> =A0 =A0 =A0R09:
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A00000000000000016
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0R10: fefefefefefefeff R11: ffff8800377b0400
> =A0 =A0 =A0R12:
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A000000001000a3e0c
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0R13: 0000000000000000 R14: 00000001000a3e0c
> =A0 =A0 =A0R15:
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0ffff8800389ffc28
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0FS: =A000007f1af70a8700(0000)
> =A0 =A0 =A0GS:ffff880050180000(0000)
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0knlGS:0000000000000000
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0CS: =A0e033 DS: 0000 ES: 0000 CR0:
> =A0 =A0 =A0000000008005003b
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0CR2: 0000000000000030 CR3: 000000000156d000
> =A0 =A0 =A0CR4:
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A00000000000002660
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0DR0: 0000000000000000 DR1: 0000000000000000
> =A0 =A0 =A0DR2:
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A00000000000000000
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0DR3: 0000000000000000 DR6: 00000000ffff0ff0
> =A0 =A0 =A0DR7:
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A00000000000000400
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0Process qemu-dm (pid: 3571, threadinfo
> =A0 =A0 =A0> =A0 =A0 =A0ffff8800389fe000,
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0task
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0ffff88003a721260)
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0Stack:
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0 ffff88003a6d6400 ffff8800377b0000
> =A0 =A0 =A000000001000a3e0c
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0ffffffff813= 3ce8f
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0 ffff8800377b0400 ffffffff8134b6cd
> =A0 =A0 =A0ffff8800389ffc28
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0ffff8800389= ffc28
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0 ffff8800377b00f8 ffff8800377b0680
> =A0 =A0 =A0ffff880038cdcd60
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0ffff8800377= b0000
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0Call Trace:
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0 [<ffffffff8133ce8f>] ?
> =A0 =A0 =A0sk_release_kernel+0x23/0x39
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0 [<ffffffff8134b6cd>] ?
> =A0 =A0 =A0netdev_run_todo+0x1e9/0x206
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0 [<ffffffff8129798f>] ?
> =A0 =A0 =A0tun_chr_close+0x4c/0x7b
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0 [<ffffffff810b39d3>] ? fput+0xe4/0x1c5
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0 [<ffffffff810b202c>] ? filp_close+0x61/0x68
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0 [<ffffffff81035e62>] ?
> =A0 =A0 =A0put_files_struct+0x62/0xb9
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0 [<ffffffff81036374>] ? do_exit+0x24a/0x74c
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0 [<ffffffff81036906>] ?
> =A0 =A0 =A0do_group_exit+0x6b/0x9d
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0 [<ffffffff8103ea0b>] ?
> =A0 =A0 =A0> =A0 =A0 =A0get_signal_to_deliver+0x449/0x46e
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0 [<ffffffff81009fa5>] ? do_signal+0x28/0x4c4
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0 [<ffffffff81027079>] ?
> =A0 =A0 =A0> =A0 =A0 =A0pvclock_clocksource_read+0x48/0xbf
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0 [<ffffffff8105b745>] ? ktime_get_ts+0x66/0xa8
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0 [<ffffffff810bfb18>] ?
> =A0 =A0 =A0> =A0 =A0 =A0poll_select_copy_remaining+0xe0/0xf5
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0 [<ffffffff8100a48d>] ?
> =A0 =A0 =A0do_notify_resume+0x3b/0x74
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0 [<ffffffff81411a70>] ? int_signal+0x12/0x17
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0Code: 00 00 00 40 74 02 0f 0b 48 8d 77 70 48
> =A0 =A0 =A08d bf 08
> =A0 =A0 =A0> =A0 =A0 =A001 00
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A000 e8
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A08b 71 10 > =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A000 85 c0 0f 84 5d 01 00 00 48 8b 6b 18 f6 83
> =A0 =A0 =A080 00 00
> =A0 =A0 =A0> =A0 =A0 =A000 08
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0<4c> 8b
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A065 30
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A074 11 be 68 05 00 00 48 c7 c7 8e df 4f 81 e8
> =A0 =A0 =A0bb d0
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0RIP =A0[<ffffffff810c50c4>] iput+0x3e/0x195
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0 RSP <ffff8800389ffbf8>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0CR2: 0000000000000030
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0---[ end trace 67cc1654658fedcc ]---
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0Fixing recursive fault but reboot is needed!
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0I also tested Xen 4.2.0 and problem is the
> =A0 =A0 =A0same. So
> =A0 =A0 =A0> =A0 =A0 =A0is this
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0a Xen
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0bug or a > =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0kernel bug? I am running vanilla
> =A0 =A0 =A0> =A0 =A0 =A0[1][2][3][4][5]kernel.org kernel
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A03.5.0 and
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0my
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0hardware is Intel Core i7-3770 CPU and Intel
> =A0 =A0 =A0DQ77MK
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0motherboard
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0with
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0latest bios.
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0Best regards,
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0Valtteri Kiviniemi
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> Refere= nces
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0Visible links
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A01. [3][4][5][6]http= ://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> ______= _________________________________________
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> Xen-de= vel mailing list
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> [4][5]= [6][7]Xen-deve= l@lists.xen.org
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> [5][6]= [7][8]http://l= ists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> References
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0Visible links > =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A01. mailto:[7][8= ][9]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A02. [8][9][10]http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A03. [9][10][11]<= a href=3D"http://kernel.org/" target=3D"_blank">http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A04. mailto:[10][= 11][12]Xen-dev= el@lists.xen.org
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A05. [11][12][13]= http://lists.x= en.org/xen-devel
> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> References
> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0Visible links
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A01. mailto:[13][14]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A02. mailto:[14][15]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A03. [15][16]http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A04. [16][17]http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A05. mailto:[17][18]Xen-devel@lists.xen.org=
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A06. [18][19]http://lists.xen.org/xen-devel=
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A07. mailto:[19][20]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A08. [20][21]http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A09. [21][22]http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0> =A0 10. mailto:[22][23]Xen-devel@lists.xen.org > =A0 =A0 =A0> =A0 =A0 =A0> =A0 11. [23][24]http://lists.xen.org/xen-devel > =A0 =A0 =A0>
> =A0 =A0 =A0> References
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0Visible links
> =A0 =A0 =A0> =A0 =A01. mailto:[25]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A02. mailto:[26]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A03. mailto:[27]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A04. [28]http://kernel.org/
> =A0 =A0 =A0> =A0 =A05. [29]http://kernel.org/
> =A0 =A0 =A0> =A0 =A06. mailto:[30]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 =A07. [31]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 =A08. mailto:[32]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A09. [33]http://kernel.org/
> =A0 =A0 =A0> =A0 10. [34]http://kernel.org/
> =A0 =A0 =A0> =A0 11. mailto:[35]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 12. [36]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 13. mailto:[37]pasik@iki.fi
> =A0 =A0 =A0> =A0 14. mailto:[38]pasik@iki.fi
> =A0 =A0 =A0> =A0 15. [39]http://kernel.org/
> =A0 =A0 =A0> =A0 16. [40]http://kernel.org/
> =A0 =A0 =A0> =A0 17. mailto:[41]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 18. [42]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 19. mailto:[43]pasik@iki.fi
> =A0 =A0 =A0> =A0 20. [44]http://kernel.org/
> =A0 =A0 =A0> =A0 21. [45]http://kernel.org/
> =A0 =A0 =A0> =A0 22. mailto:[46]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 23. [47]http://lists.xen.org/xen-devel
>
> References
>
> =A0 =A0Visible links
> =A0 =A01. mailto:pas= ik@iki.fi
> =A0 =A02. mailto:pas= ik@iki.fi
> =A0 =A03. mailto:pas= ik@iki.fi
> =A0 =A04. mailto:pasik@iki.fi
> =A0 =A05. http://kern= el.org/
> =A0 =A06. http://kern= el.org/
> =A0 =A07. mailto:Xen-devel@lists.xen.org
> =A0 =A08. http://lists.xen.org/xen-devel
> =A0 =A09. mailto:pas= ik@iki.fi
> =A0 10. http://kernel= .org/
> =A0 11. http://kernel= .org/
> =A0 12. mailto:Xen-devel@lists.xen.org
> =A0 13. h= ttp://lists.xen.org/xen-devel
> =A0 14. mailto:pasik= @iki.fi
> =A0 15. mailto:pasik= @iki.fi
> =A0 16. http://kernel= .org/
> =A0 17. http://kernel= .org/
> =A0 18. mailto:Xen-devel@lists.xen.org
> =A0 19. h= ttp://lists.xen.org/xen-devel
> =A0 20. mailto:pasik= @iki.fi
> =A0 21. http://kernel= .org/
> =A0 22. http://kernel= .org/
> =A0 23. mailto:Xen-devel@lists.xen.org
> =A0 24. h= ttp://lists.xen.org/xen-devel
> =A0 25. mailto:pasik= @iki.fi
> =A0 26. mailto:pasik= @iki.fi
> =A0 27. mailto:pasik= @iki.fi
> =A0 28. http://kernel= .org/
> =A0 29. http://kernel= .org/
> =A0 30. mailto:Xen-devel@lists.xen.org
> =A0 31. h= ttp://lists.xen.org/xen-devel
> =A0 32. mailto:pasik= @iki.fi
> =A0 33. http://kernel= .org/
> =A0 34. http://kernel= .org/
> =A0 35. mailto:Xen-devel@lists.xen.org
> =A0 36. h= ttp://lists.xen.org/xen-devel
> =A0 37. mailto:pasik= @iki.fi
> =A0 38. mailto:pasik= @iki.fi
> =A0 39. http://kernel= .org/
> =A0 40. http://kernel= .org/
> =A0 41. mailto:Xen-devel@lists.xen.org
> =A0 42. h= ttp://lists.xen.org/xen-devel
> =A0 43. mailto:pasik= @iki.fi
> =A0 44. http://kernel= .org/
> =A0 45. http://kernel= .org/
> =A0 46. mailto:Xen-devel@lists.xen.org
> =A0 47. h= ttp://lists.xen.org/xen-devel


--20cf303a2e35c41b0104cb126a25-- --===============7769507901113686720== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============7769507901113686720==-- From xen-devel-bounces@lists.xen.org Tue Oct 02 12:19:57 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 12:19:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ1Rp-0001JV-Hc; Tue, 02 Oct 2012 12:19:37 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ1Rn-0001JQ-Qg for Xen-devel@lists.xen.org; Tue, 02 Oct 2012 12:19:36 +0000 Received: from [85.158.139.83:16759] by server-3.bemta-5.messagelabs.com id B7/FC-16108-6DBDA605; Tue, 02 Oct 2012 12:19:34 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-9.tower-182.messagelabs.com!1349180373!32385068!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MjMzMTI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1373 invoked from network); 2 Oct 2012 12:19:34 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 12:19:34 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id 4E5B92B78; Tue, 2 Oct 2012 15:19:33 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id D8A3520058; Tue, 2 Oct 2012 15:19:32 +0300 (EEST) Date: Tue, 2 Oct 2012 15:19:32 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Valtteri Kiviniemi Message-ID: <20121002121932.GL8912@reaktio.net> References: <20121001144042.GC8912@reaktio.net> <20121001160117.GD8912@reaktio.net> <20121001164757.GF8912@reaktio.net> <20121001182437.GG8912@reaktio.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.0.4, kernel 3.5.0 HVM crash and kernel BUG X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, Oct 02, 2012 at 03:11:07PM +0300, Valtteri Kiviniemi wrote: > Hi, > = > Another update: > = > I wanted to check that if a Linux HVM would boot with working VNC cons= ole, > so I tried to launch a Debian Squeeze installer on HVM. It refused to > start ant told me that vbd hotplug scripts were not working. After that > failure even the Windows domU would not anymore start which was previo= usly > starting ok. > = > The hotplug scripts also starts hanging on the processes. > = > root 9401 0.1 0.1 17700 1640 ? S 15:05 0:00 /bin/= bash > /etc/xen/scripts/xen-hotplug-cleanup > root 9441 0.1 0.1 17700 1644 ? S 15:05 0:00 /bin/= bash > /etc/xen/scripts/xen-hotplug-cleanup > root 9481 0.1 0.1 17700 1640 ? S 15:05 0:00 /bin/= bash > /etc/xen/scripts/xen-hotplug-cleanup > root 9560 0.1 0.1 17700 1640 ? S 15:05 0:00 /bin/= bash > /etc/xen/scripts/xen-hotplug-cleanup > root 10738 0.1 0.1 17696 1636 ? S 15:05 0:00 /bin/= bash > /etc/xen/scripts/xen-hotplug-cleanup > root 10747 0.1 0.1 17792 1736 ? S 15:05 0:00 /bin/= bash > /etc/xen/scripts/block remove > root 11286 0.0 0.0 4080 324 ? S 15:06 0:00 sleep= 1 > root 11290 0.0 0.0 4080 324 ? S 15:06 0:00 sleep= 1 > root 11294 0.0 0.0 4080 324 ? S 15:06 0:00 sleep= 1 > root 11298 0.0 0.0 4080 324 ? S 15:06 0:00 sleep= 1 > root 11302 0.0 0.0 4080 320 ? S 15:06 0:00 sleep= 1 > root 11306 0.0 0.0 4080 320 ? S 15:06 0:00 sleep= 1 > = > Then I did a xm destroy and I had again the kernel BUG on dmesg. So it > seems that the problem is not fixed by using 3.6.0. Udev version is 17= 5-7. > = So you have definitely something broken in your system, probably in your dom0 kernel. Try with Linux 3.5.4 or 3.4.x, = and see how that goes. Any errors in dom0 dmesg? How about in /var/log/xen/* ? = -- Pasi > = > = > 2012/10/1 Valtteri Kiviniemi <[1]kiviniemi.valtteri@gmail.com> > = > Hi, > = > CPU: Intel Core i7-3770 3.4GHz > [2]http://ark.intel.com/products/65719/ > = > MB: Intel DQ77MK (latest bios updated) > [3]http://www.intel.com/content/www/us/en/motherboards/desktop-mothe= rboards/desktop-board-dq77mk.html > = > Memory: 32GB (4 x 8GB DDR3-1600MHz) > = > Host is Debian wheezy/testing, Xen 4.0.4 and latest 3.6.0 kernel. > = > Noticed also some errors in xm dmesg: > = > root@xen-2:~# xm dmesg > = > (XEN) Xen version 4.0.4 ([4]root@dataproof.fi) (gcc version 4.7.1 > (Debian 4.7.1-7) ) Sun Sep 30 20:28:26 EEST 2012 > (XEN) Latest ChangeSet: unavailable > (XEN) Bootloader: GNU GRUB 0.97 > (XEN) Command line: dom0_mem=3D1280M cpufreq=3Dxen clocksource=3Dhpet > (XEN) Video information: > (XEN) VGA is text mode 80x25, font 8x16 > (XEN) VBE/DDC methods: none; EDID transfer time: 0 seconds > (XEN) EDID info not retrieved because no DDC retrieval method detec= ted > (XEN) Disc information: > (XEN) Found 4 MBR signatures > (XEN) Found 4 EDD information structures > (XEN) Xen-e820 RAM map: > (XEN) 0000000000000000 - 000000000009d800 (usable) > (XEN) 000000000009d800 - 00000000000a0000 (reserved) > (XEN) 00000000000e0000 - 0000000000100000 (reserved) > (XEN) 0000000000100000 - 0000000020000000 (usable) > (XEN) 0000000020000000 - 0000000020200000 (reserved) > (XEN) 0000000020200000 - 0000000040004000 (usable) > (XEN) 0000000040004000 - 0000000040005000 (reserved) > (XEN) 0000000040005000 - 00000000dbe44000 (usable) > (XEN) 00000000dbe44000 - 00000000dc2d7000 (reserved) > (XEN) 00000000dc2d7000 - 00000000dc2e7000 (ACPI data) > (XEN) 00000000dc2e7000 - 00000000dc40c000 (ACPI NVS) > (XEN) 00000000dc40c000 - 00000000dc6af000 (reserved) > (XEN) 00000000dc6af000 - 00000000dc6b0000 (usable) > (XEN) 00000000dc6b0000 - 00000000dc6f3000 (ACPI NVS) > (XEN) 00000000dc6f3000 - 00000000dd000000 (usable) > (XEN) 00000000dd800000 - 00000000dfa00000 (reserved) > (XEN) 00000000f8000000 - 00000000fc000000 (reserved) > (XEN) 00000000fec00000 - 00000000fec01000 (reserved) > (XEN) 00000000fed00000 - 00000000fed04000 (reserved) > (XEN) 00000000fed1c000 - 00000000fed20000 (reserved) > (XEN) 00000000fee00000 - 00000000fee01000 (reserved) > (XEN) 00000000ff000000 - 0000000100000000 (reserved) > (XEN) 0000000100000000 - 000000081e600000 (usable) > (XEN) ACPI: RSDP 000F0490, 0024 (r2 INTEL) > (XEN) ACPI: XSDT DC2DB080, 007C (r1 INTEL DQ77MK 32 AMI > 10013) > (XEN) ACPI: FACP DC2E51F0, 010C (r5 INTEL DQ77MK 32 AMI > 10013) > (XEN) ACPI Warning (tbfadt-0232): FADT (revision 5) is longer than A= CPI > 2.0 version, truncating length 0x10C to 0xF4 [20070126] > (XEN) ACPI: DSDT DC2DB188, A061 (r2 INTEL DQ77MK 32 INTL > 20051117) > (XEN) ACPI: FACS DC40A080, 0040 > (XEN) ACPI: APIC DC2E5300, 0092 (r3 INTEL DQ77MK 32 AMI > 10013) > (XEN) ACPI: FPDT DC2E5398, 0044 (r1 INTEL DQ77MK 32 AMI > 10013) > (XEN) ACPI: TCPA DC2E53E0, 0032 (r2 INTEL DQ77MK 32 MSFT > 1000013) > (XEN) ACPI: MCFG DC2E5418, 003C (r1 INTEL DQ77MK 32 MSFT > 97) > (XEN) ACPI: HPET DC2E5458, 0038 (r1 INTEL DQ77MK 32 AMI. > 5) > (XEN) ACPI: SSDT DC2E5490, 036D (r1 INTEL DQ77MK 32 INTL > 20091112) > (XEN) ACPI: SSDT DC2E5800, 09AA (r1 INTEL DQ77MK 32 INTL > 20051117) > (XEN) ACPI: SSDT DC2E61B0, 0A92 (r1 INTEL DQ77MK 32 INTL > 20051117) > (XEN) ACPI: DMAR DC2E6C48, 00B8 (r1 INTEL DQ77MK 32 INTL > 1) > (XEN) ACPI: ASF! DC2E6D00, 00A5 (r32 INTEL DQ77MK 32 TFSM > F4240) > (XEN) System RAM: 32682MB (33467320kB) > (XEN) Domain heap initialised > (XEN) ACPI: 32/64X FACS address mismatch in FADT - > dc40a080/0000000000000000, using 32 > (XEN) Processor #0 7:10 APIC version 21 > (XEN) Processor #2 7:10 APIC version 21 > (XEN) Processor #4 7:10 APIC version 21 > (XEN) Processor #6 7:10 APIC version 21 > (XEN) Processor #1 7:10 APIC version 21 > (XEN) Processor #3 7:10 APIC version 21 > (XEN) Processor #5 7:10 APIC version 21 > (XEN) Processor #7 7:10 APIC version 21 > (XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 > (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs > (XEN) Switched to APIC driver x2apic_cluster. > (XEN) x2APIC mode enabled. > (XEN) Using scheduler: SMP Credit Scheduler (credit) > (XEN) Detected 3392.369 MHz processor. > (XEN) Initing memory sharing. > (XEN) VMX: Supported advanced features: > (XEN) - APIC MMIO access virtualisation > (XEN) - APIC TPR shadow > (XEN) - Extended Page Tables (EPT) > (XEN) - Virtual-Processor Identifiers (VPID) > (XEN) - Virtual NMI > (XEN) - MSR direct-access bitmap > (XEN) - Unrestricted Guest > (XEN) EPT supports 2MB super page. > (XEN) HVM: ASIDs enabled. > (XEN) HVM: VMX enabled > (XEN) HVM: Hardware Assisted Paging detected. > (XEN) Intel VT-d Snoop Control not enabled. > (XEN) Intel VT-d Dom0 DMA Passthrough not enabled. > (XEN) Intel VT-d Queued Invalidation enabled. > (XEN) Intel VT-d Interrupt Remapping enabled. > (XEN) I/O virtualisation enabled > (XEN) - Dom0 mode: Relaxed > (XEN) Enabled directed EOI with ioapic_ack_old on! > (XEN) Total of 8 processors activated. > (XEN) ENABLING IO-APIC IRQs > (XEN) -> Using old ACK method > (XEN) TSC is reliable, synchronization unnecessary > (XEN) Platform timer appears to have unexpectedly wrapped 1 times. > (XEN) Platform timer is 14.318MHz HPET > (XEN) Allocated console ring of 16 KiB. > (XEN) Brought up 8 CPUs > (XEN) *** LOADING DOMAIN 0 *** > (XEN) Xen kernel: 64-bit, lsb, compat32 > (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1ae7000 > (XEN) PHYSICAL MEMORY ARRANGEMENT: > (XEN) Dom0 alloc.: 0000000804000000->0000000806000000 (319488 pag= es > to be allocated) > (XEN) VIRTUAL MEMORY ARRANGEMENT: > (XEN) Loaded kernel: ffffffff81000000->ffffffff81ae7000 > (XEN) Init. ramdisk: ffffffff81ae7000->ffffffff81ae7000 > (XEN) Phys-Mach map: ffffffff81ae7000->ffffffff81d67000 > (XEN) Start info: ffffffff81d67000->ffffffff81d674b4 > (XEN) Page tables: ffffffff81d68000->ffffffff81d7b000 > (XEN) Boot stack: ffffffff81d7b000->ffffffff81d7c000 > (XEN) TOTAL: ffffffff80000000->ffffffff82000000 > (XEN) ENTRY ADDRESS: ffffffff815e3210 > (XEN) Dom0 has maximum 8 VCPUs > (XEN) [VT-D]iommu.c:718: BIOS did not enable IGD for VT properly. > Disabling IGD VT-d engine. > (XEN) Scrubbing Free RAM: done. > (XEN) Xen trace buffers: disabled > (XEN) Std. Loglevel: Errors and warnings > (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings) > (XEN) Xen is relinquishing VGA console. > (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch > input to Xen) > (XEN) Freed 172kB init memory. > (XEN) traps.c:2333:d0 Domain attempted WRMSR 000000000000008b from > 00000012:00000000 to 00000000:00000000. > = > - Valtteri > = > 2012/10/1 Pasi K=E4rkk=E4inen <[5]pasik@iki.fi> > = > On Mon, Oct 01, 2012 at 09:12:50PM +0300, Valtteri Kiviniemi wrote: > > Hi, > > > > Lowering memory or vcpu's does not help, problem is the same.= I > originally > > installed Xen 4.2.0 and the problem was same on that too. The= n I > > downgraded back to 4.0.4 since I thought that this might be a= bug > on > > 4.2.0. I have been previously running Windows Server 2008 R2 > succesfully > > on Xen 4.0.x on different hardware with this same config. > Hypervisor is > > 64bit and windows is 64bit. > > > > Any ideas what to try next? > > > = > What kind of hardware is that? > = > [6]xen.org automated testing regularly tests Windows VMs, and it w= orks > OK there. > = > -- Pasi > > Ps. qemu-dm.log is the following: > > > > domid: 10 > > config qemu network with xen bridge for tap10.0 xenbr0 > > Using file /dev/virtuals/ts in read-write mode > > Using file /media/iso/windows_server_2008_r2_sp1.iso in read-= only > mode > > Watching /local/domain/0/device-model/10/logdirty/cmd > > Watching /local/domain/0/device-model/10/command > > qemu_map_cache_init nr_buckets =3D 10000 size 4194304 > > shared page at pfn feffd > > buffered io page at pfn feffb > > Guest uuid =3D 52f19e23-2955-c27d-a22c-60c5d8c60d5a > > Time offset set 0 > > populating video RAM at ff000000 > > mapping video RAM from ff000000 > > Register xen platform. > > Done register platform. > > platform_fixed_ioport: changed ro/rw state of ROM memory area. > now is rw > > state. > > xs_read(/local/domain/0/device-model/10/xen_extended_power_mg= mt): > read > > error > > medium change watch on `hdc' (index: 1): > > /media/iso/windows_server_2008_r2_sp1.iso > > I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, > size: 0 > > Log-dirty: no command yet. > > xs_read(/local/domain/10/log-throttling): read error > > qemu: ignoring not-understood drive > `/local/domain/10/log-throttling' > > medium change watch on `/local/domain/10/log-throttling' - > unknown device, > > ignored > > cirrus vga map change while on lfb mode > > mapping vram to f0000000 - f0400000 > > platform_fixed_ioport: changed ro/rw state of ROM memory area. > now is rw > > state. > > platform_fixed_ioport: changed ro/rw state of ROM memory area. > now is ro > > state. > > > > 2012/10/1 Pasi K=E4rkk=E4inen <[1][7]pasik@iki.fi> > > > > On Mon, Oct 01, 2012 at 07:23:44PM +0300, Valtteri Kiviniemi > wrote: > > > Hi, > > > > > > I have tried other config files, but the problem is the > same. At > > the > > > moment I'm using a config file from another server whe= re I > have a > > working > > > Windows Server 2008 R2 installation, so I dont think t= hat > there is > > > anything wrong with my config: > > > > > > > Did you try with less vcpus, for example 2 ? > > how about with less memory, say 2 GB ? > > > > Did you try with later Xen versions? Is that a 32bit Xen, or > 64bit Xen > > hypervisor? > > > > -- Pasi > > > kernel =3D "/usr/lib/xen/boot/hvmloader" > > > builder =3D "hvm" > > > shadow_memory =3D "8" > > > memory =3D "4096" > > > name =3D "ts" > > > vcpus =3D "8" > > > cpus =3D ["0", "1", "2", "3", "4", "5", "6", "7"] > > > pae =3D "1" > > > acpi =3D "1" > > > apic =3D "1" > > > vfb =3D [ 'type=3Dvnc, vnclisten=3D10.100.100.50, vncp= asswd=3Dxxx' > ] > > > xen_extended_power_mgmt =3D "0" > > > vif =3D [ "type=3Dioemu, mac=3D00:16:3e:d7:d7:5d, brid= ge=3Dxenbr0" > ] > > > disk =3D [ "phy:/dev/virtuals/ts,hda,w", > > > > "file:/media/iso/windows_server_2008_r2_sp1.iso,hdc:cdrom,r" ] > > > on_poweroff =3D "destroy" > > > on_reboot =3D "restart" > > > on_crash =3D "restart" > > > viridian =3D "1" > > > device_model =3D "/usr/lib/xen/bin/qemu-dm" > > > boot =3D "dc" > > > snapshot =3D "0" > > > vncconsole =3D "1" > > > sdl =3D "0" > > > opengl =3D "0" > > > vnc =3D "1" > > > nographic =3D "0" > > > stdvga =3D "0" > > > tsc_mode =3D "1" > > > monitor =3D "0" > > > localtime =3D "1" > > > usb =3D "0" > > > keymap =3D "fi" > > > xen_platform_pci =3D "1" > > > pci_msitranslate =3D "1" > > > pci_power_mgmt =3D "0" > > > > > > 2012/10/1 Pasi K=E4rkk=E4inen <[1][2][8]pasik@iki.fi> > > > > > > On Mon, Oct 01, 2012 at 06:46:08PM +0300, Valtteri > Kiviniemi > > wrote: > > > > Hi, > > > > > > > > Yes, I have viridian=3D1 on my domU config. > > > > > > > > > > Try with some known good domU configfile. > > > > > > -- Pasi > > > > 2012/10/1 Pasi K=E4rkk=E4inen > <[1][2][3][9]pasik@iki.fi> > > > > > > > > On Mon, Oct 01, 2012 at 05:06:53PM +0300, > Valtteri > > Kiviniemi > > > wrote: > > > > > Hi, > > > > > > > > > > I'm now using 3.6.0 and can't reproduce = that > crash > > anymore, > > > so it > > > > seems > > > > > that it was a kernel bug. > > > > > > > > > > > > > OK. > > > > > However I'm still getting black screen on > VNC > > > > > when trying to install Windows Server 20= 08 > R2. I can > > see the > > > > "windows is > > > > > loading files" screen but after the > installer starts > > the VNC > > > > display goes > > > > > black. > > > > > > > > > > Any ideas? > > > > > > > > > > > > > Do you have viridian=3D1 specified for the wi= ndows > vm? > > > > > > > > -- Pasi > > > > > > > > > - Valtteri > > > > > > > > > > 2012/10/1 Pasi K=E4rkk=E4inen > <[1][2][3][4][10]pasik@iki.fi> > > > > > > > > > > On Sun, Sep 30, 2012 at 11:18:03PM +03= 00, > Valtteri > > > Kiviniemi > > > > wrote: > > > > > > Hi, > > > > > > > > > > > > > > > > Hello, > > > > > > I'm trying to get Windows Server = 2008 > R2 > > installation > > > > booting on > > > > > Xen > > > > > > 4.0.4. Using the following config: > > > > > > > > > > > > > > > > > > > > > > > > > > > > The domU will start booting just > fine, but > > after a > > > few > > > > minutes the > > > > > VNC > > > > > > screen goes black. After that when > typing "xm > > destroy > > > ts" it > > > > will > > > > > trigger > > > > > > a kernel BUG: > > > > > > > > > > > > BUG: unable to handle kernel NULL > pointer > > dereference > > > at > > > > > 0000000000000030 > > > > > > IP: [] > iput+0x3e/0x195 > > > > > > PGD 0 > > > > > > Oops: 0000 [#1] SMP > > > > > > CPU 6 > > > > > > Pid: 3571, comm: qemu-dm Not tain= ted > > 3.5.0-dom0 #1 > > > > > > > > > > First of all upgrade to latest 3.5.x L= inux > kernel > > release > > > .. so > > > > at least > > > > > 3.5.4. > > > > > > > > > > -- Pasi > > > > > > > > > > > /DQ77MK > > > > > > RIP: e030:[] > > [] > > > > > iput+0x3e/0x195 > > > > > > RSP: e02b:ffff8800389ffbf8 EFLAG= S: > 00010246 > > > > > > RAX: 0000000000000001 RBX: > ffff8800377b0720 > > RCX: > > > > ffff8800501c0000 > > > > > > RDX: ffff8800501c0000 RSI: > ffff8800377b0790 > > RDI: > > > > ffff8800377b0790 > > > > > > RBP: 0000000000000000 R08: > ffffffff815cdd00 > > R09: > > > > 0000000000000016 > > > > > > R10: fefefefefefefeff R11: > ffff8800377b0400 > > R12: > > > > 00000001000a3e0c > > > > > > R13: 0000000000000000 R14: > 00000001000a3e0c > > R15: > > > > ffff8800389ffc28 > > > > > > FS: 00007f1af70a8700(0000) > > GS:ffff880050180000(0000) > > > > > > knlGS:0000000000000000 > > > > > > CS: e033 DS: 0000 ES: 0000 CR0: > > 000000008005003b > > > > > > CR2: 0000000000000030 CR3: > 000000000156d000 > > CR4: > > > > 0000000000002660 > > > > > > DR0: 0000000000000000 DR1: > 0000000000000000 > > DR2: > > > > 0000000000000000 > > > > > > DR3: 0000000000000000 DR6: > 00000000ffff0ff0 > > DR7: > > > > 0000000000000400 > > > > > > Process qemu-dm (pid: 3571, > threadinfo > > > ffff8800389fe000, > > > > task > > > > > > ffff88003a721260) > > > > > > Stack: > > > > > > ffff88003a6d6400 ffff8800377b0000 > > 00000001000a3e0c > > > > > ffffffff8133ce8f > > > > > > ffff8800377b0400 ffffffff8134b6cd > > ffff8800389ffc28 > > > > > ffff8800389ffc28 > > > > > > ffff8800377b00f8 ffff8800377b0680 > > ffff880038cdcd60 > > > > > ffff8800377b0000 > > > > > > Call Trace: > > > > > > [] ? > > sk_release_kernel+0x23/0x39 > > > > > > [] ? > > netdev_run_todo+0x1e9/0x206 > > > > > > [] ? > > tun_chr_close+0x4c/0x7b > > > > > > [] ? > fput+0xe4/0x1c5 > > > > > > [] ? > filp_close+0x61/0x68 > > > > > > [] ? > > put_files_struct+0x62/0xb9 > > > > > > [] ? > do_exit+0x24a/0x74c > > > > > > [] ? > > do_group_exit+0x6b/0x9d > > > > > > [] ? > > > get_signal_to_deliver+0x449/0x46e > > > > > > [] ? > do_signal+0x28/0x4c4 > > > > > > [] ? > > > pvclock_clocksource_read+0x48/0xbf > > > > > > [] ? > ktime_get_ts+0x66/0xa8 > > > > > > [] ? > > > poll_select_copy_remaining+0xe0/0xf5 > > > > > > [] ? > > do_notify_resume+0x3b/0x74 > > > > > > [] ? > int_signal+0x12/0x17 > > > > > > Code: 00 00 00 40 74 02 0f 0b 48 = 8d > 77 70 48 > > 8d bf 08 > > > 01 00 > > > > 00 e8 > > > > > 8b 71 10 > > > > > > 00 85 c0 0f 84 5d 01 00 00 48 8b = 6b > 18 f6 83 > > 80 00 00 > > > 00 08 > > > > <4c> 8b > > > > > 65 30 > > > > > > 74 11 be 68 05 00 00 48 c7 c7 8e = df > 4f 81 e8 > > bb d0 > > > > > > RIP [] > iput+0x3e/0x195 > > > > > > RSP > > > > > > CR2: 0000000000000030 > > > > > > ---[ end trace 67cc1654658fedcc ]= --- > > > > > > Fixing recursive fault but reboot= is > needed! > > > > > > > > > > > > I also tested Xen 4.2.0 and probl= em > is the > > same. So > > > is this > > > > a Xen > > > > > bug or a > > > > > > kernel bug? I am running vanilla > > > [1][2][3][4][5][11]kernel.org kernel > > > > 3.5.0 and > > > > > my > > > > > > hardware is Intel Core i7-3770 CPU > and Intel > > DQ77MK > > > > motherboard > > > > > with > > > > > > latest bios. > > > > > > > > > > > > Best regards, > > > > > > Valtteri Kiviniemi > > > > > > > > > > > > References > > > > > > > > > > > > Visible links > > > > > > 1. [3][4][5][6][12]http://kernel.= org/ > > > > > > > > > > > > _______________________________________________ > > > > > > Xen-devel mailing list > > > > > > [4][5][6][7][13]Xen-devel@lists.xen.= org > > > > > > > [5][6][7][8][14]http://lists.xen.org/xen-devel > > > > > > > > > > References > > > > > > > > > > Visible links > > > > > 1. mailto:[7][8][9][15]pasik@iki.fi > > > > > 2. [8][9][10][16]http://kernel.org/ > > > > > 3. [9][10][11][17]http://kernel.org/ > > > > > 4. > mailto:[10][11][12][18]Xen-devel@lists.xen.org > > > > > 5. > [11][12][13][19]http://lists.xen.org/xen-devel > > > > > > > > References > > > > > > > > Visible links > > > > 1. mailto:[13][14][20]pasik@iki.fi > > > > 2. mailto:[14][15][21]pasik@iki.fi > > > > 3. [15][16][22]http://kernel.org/ > > > > 4. [16][17][23]http://kernel.org/ > > > > 5. mailto:[17][18][24]Xen-devel@lists.xen.org > > > > 6. [18][19][25]http://lists.xen.org/xen-devel > > > > 7. mailto:[19][20][26]pasik@iki.fi > > > > 8. [20][21][27]http://kernel.org/ > > > > 9. [21][22][28]http://kernel.org/ > > > > 10. mailto:[22][23][29]Xen-devel@lists.xen.org > > > > 11. [23][24][30]http://lists.xen.org/xen-devel > > > > > > References > > > > > > Visible links > > > 1. mailto:[25][31]pasik@iki.fi > > > 2. mailto:[26][32]pasik@iki.fi > > > 3. mailto:[27][33]pasik@iki.fi > > > 4. [28][34]http://kernel.org/ > > > 5. [29][35]http://kernel.org/ > > > 6. mailto:[30][36]Xen-devel@lists.xen.org > > > 7. [31][37]http://lists.xen.org/xen-devel > > > 8. mailto:[32][38]pasik@iki.fi > > > 9. [33][39]http://kernel.org/ > > > 10. [34][40]http://kernel.org/ > > > 11. mailto:[35][41]Xen-devel@lists.xen.org > > > 12. [36][42]http://lists.xen.org/xen-devel > > > 13. mailto:[37][43]pasik@iki.fi > > > 14. mailto:[38][44]pasik@iki.fi > > > 15. [39][45]http://kernel.org/ > > > 16. [40][46]http://kernel.org/ > > > 17. mailto:[41][47]Xen-devel@lists.xen.org > > > 18. [42][48]http://lists.xen.org/xen-devel > > > 19. mailto:[43][49]pasik@iki.fi > > > 20. [44][50]http://kernel.org/ > > > 21. [45][51]http://kernel.org/ > > > 22. mailto:[46][52]Xen-devel@lists.xen.org > > > 23. [47][53]http://lists.xen.org/xen-devel > > > > References > > > > Visible links > > 1. mailto:[54]pasik@iki.fi > > 2. mailto:[55]pasik@iki.fi > > 3. mailto:[56]pasik@iki.fi > > 4. mailto:[57]pasik@iki.fi > > 5. [58]http://kernel.org/ > > 6. [59]http://kernel.org/ > > 7. mailto:[60]Xen-devel@lists.xen.org > > 8. [61]http://lists.xen.org/xen-devel > > 9. mailto:[62]pasik@iki.fi > > 10. [63]http://kernel.org/ > > 11. [64]http://kernel.org/ > > 12. mailto:[65]Xen-devel@lists.xen.org > > 13. [66]http://lists.xen.org/xen-devel > > 14. mailto:[67]pasik@iki.fi > > 15. mailto:[68]pasik@iki.fi > > 16. [69]http://kernel.org/ > > 17. [70]http://kernel.org/ > > 18. mailto:[71]Xen-devel@lists.xen.org > > 19. [72]http://lists.xen.org/xen-devel > > 20. mailto:[73]pasik@iki.fi > > 21. [74]http://kernel.org/ > > 22. [75]http://kernel.org/ > > 23. mailto:[76]Xen-devel@lists.xen.org > > 24. [77]http://lists.xen.org/xen-devel > > 25. mailto:[78]pasik@iki.fi > > 26. mailto:[79]pasik@iki.fi > > 27. mailto:[80]pasik@iki.fi > > 28. [81]http://kernel.org/ > > 29. [82]http://kernel.org/ > > 30. mailto:[83]Xen-devel@lists.xen.org > > 31. [84]http://lists.xen.org/xen-devel > > 32. mailto:[85]pasik@iki.fi > > 33. [86]http://kernel.org/ > > 34. [87]http://kernel.org/ > > 35. mailto:[88]Xen-devel@lists.xen.org > > 36. [89]http://lists.xen.org/xen-devel > > 37. mailto:[90]pasik@iki.fi > > 38. mailto:[91]pasik@iki.fi > > 39. [92]http://kernel.org/ > > 40. [93]http://kernel.org/ > > 41. mailto:[94]Xen-devel@lists.xen.org > > 42. [95]http://lists.xen.org/xen-devel > > 43. mailto:[96]pasik@iki.fi > > 44. [97]http://kernel.org/ > > 45. [98]http://kernel.org/ > > 46. mailto:[99]Xen-devel@lists.xen.org > > 47. [100]http://lists.xen.org/xen-devel > = > References > = > Visible links > 1. mailto:kiviniemi.valtteri@gmail.com > 2. http://ark.intel.com/products/65719/ > 3. http://www.intel.com/content/www/us/en/motherboards/desktop-motherb= oards/desktop-board-dq77mk.html > 4. mailto:root@dataproof.fi > 5. mailto:pasik@iki.fi > 6. http://xen.org/ > 7. mailto:pasik@iki.fi > 8. mailto:pasik@iki.fi > 9. mailto:pasik@iki.fi > 10. mailto:pasik@iki.fi > 11. http://kernel.org/ > 12. http://kernel.org/ > 13. mailto:Xen-devel@lists.xen.org > 14. http://lists.xen.org/xen-devel > 15. mailto:pasik@iki.fi > 16. http://kernel.org/ > 17. http://kernel.org/ > 18. mailto:Xen-devel@lists.xen.org > 19. http://lists.xen.org/xen-devel > 20. mailto:pasik@iki.fi > 21. mailto:pasik@iki.fi > 22. http://kernel.org/ > 23. http://kernel.org/ > 24. mailto:Xen-devel@lists.xen.org > 25. http://lists.xen.org/xen-devel > 26. mailto:pasik@iki.fi > 27. http://kernel.org/ > 28. http://kernel.org/ > 29. mailto:Xen-devel@lists.xen.org > 30. http://lists.xen.org/xen-devel > 31. mailto:pasik@iki.fi > 32. mailto:pasik@iki.fi > 33. mailto:pasik@iki.fi > 34. http://kernel.org/ > 35. http://kernel.org/ > 36. mailto:Xen-devel@lists.xen.org > 37. http://lists.xen.org/xen-devel > 38. mailto:pasik@iki.fi > 39. http://kernel.org/ > 40. http://kernel.org/ > 41. mailto:Xen-devel@lists.xen.org > 42. http://lists.xen.org/xen-devel > 43. mailto:pasik@iki.fi > 44. mailto:pasik@iki.fi > 45. http://kernel.org/ > 46. http://kernel.org/ > 47. mailto:Xen-devel@lists.xen.org > 48. http://lists.xen.org/xen-devel > 49. mailto:pasik@iki.fi > 50. http://kernel.org/ > 51. http://kernel.org/ > 52. mailto:Xen-devel@lists.xen.org > 53. http://lists.xen.org/xen-devel > 54. mailto:pasik@iki.fi > 55. mailto:pasik@iki.fi > 56. mailto:pasik@iki.fi > 57. mailto:pasik@iki.fi > 58. http://kernel.org/ > 59. http://kernel.org/ > 60. mailto:Xen-devel@lists.xen.org > 61. http://lists.xen.org/xen-devel > 62. mailto:pasik@iki.fi > 63. http://kernel.org/ > 64. http://kernel.org/ > 65. mailto:Xen-devel@lists.xen.org > 66. http://lists.xen.org/xen-devel > 67. mailto:pasik@iki.fi > 68. mailto:pasik@iki.fi > 69. http://kernel.org/ > 70. http://kernel.org/ > 71. mailto:Xen-devel@lists.xen.org > 72. http://lists.xen.org/xen-devel > 73. mailto:pasik@iki.fi > 74. http://kernel.org/ > 75. http://kernel.org/ > 76. mailto:Xen-devel@lists.xen.org > 77. http://lists.xen.org/xen-devel > 78. mailto:pasik@iki.fi > 79. mailto:pasik@iki.fi > 80. mailto:pasik@iki.fi > 81. http://kernel.org/ > 82. http://kernel.org/ > 83. mailto:Xen-devel@lists.xen.org > 84. http://lists.xen.org/xen-devel > 85. mailto:pasik@iki.fi > 86. http://kernel.org/ > 87. http://kernel.org/ > 88. mailto:Xen-devel@lists.xen.org > 89. http://lists.xen.org/xen-devel > 90. mailto:pasik@iki.fi > 91. mailto:pasik@iki.fi > 92. http://kernel.org/ > 93. http://kernel.org/ > 94. mailto:Xen-devel@lists.xen.org > 95. http://lists.xen.org/xen-devel > 96. mailto:pasik@iki.fi > 97. http://kernel.org/ > 98. http://kernel.org/ > 99. mailto:Xen-devel@lists.xen.org > 100. http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 12:19:57 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 12:19:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ1Rp-0001JV-Hc; Tue, 02 Oct 2012 12:19:37 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ1Rn-0001JQ-Qg for Xen-devel@lists.xen.org; Tue, 02 Oct 2012 12:19:36 +0000 Received: from [85.158.139.83:16759] by server-3.bemta-5.messagelabs.com id B7/FC-16108-6DBDA605; Tue, 02 Oct 2012 12:19:34 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-9.tower-182.messagelabs.com!1349180373!32385068!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MjMzMTI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1373 invoked from network); 2 Oct 2012 12:19:34 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 12:19:34 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id 4E5B92B78; Tue, 2 Oct 2012 15:19:33 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id D8A3520058; Tue, 2 Oct 2012 15:19:32 +0300 (EEST) Date: Tue, 2 Oct 2012 15:19:32 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Valtteri Kiviniemi Message-ID: <20121002121932.GL8912@reaktio.net> References: <20121001144042.GC8912@reaktio.net> <20121001160117.GD8912@reaktio.net> <20121001164757.GF8912@reaktio.net> <20121001182437.GG8912@reaktio.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.0.4, kernel 3.5.0 HVM crash and kernel BUG X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, Oct 02, 2012 at 03:11:07PM +0300, Valtteri Kiviniemi wrote: > Hi, > = > Another update: > = > I wanted to check that if a Linux HVM would boot with working VNC cons= ole, > so I tried to launch a Debian Squeeze installer on HVM. It refused to > start ant told me that vbd hotplug scripts were not working. After that > failure even the Windows domU would not anymore start which was previo= usly > starting ok. > = > The hotplug scripts also starts hanging on the processes. > = > root 9401 0.1 0.1 17700 1640 ? S 15:05 0:00 /bin/= bash > /etc/xen/scripts/xen-hotplug-cleanup > root 9441 0.1 0.1 17700 1644 ? S 15:05 0:00 /bin/= bash > /etc/xen/scripts/xen-hotplug-cleanup > root 9481 0.1 0.1 17700 1640 ? S 15:05 0:00 /bin/= bash > /etc/xen/scripts/xen-hotplug-cleanup > root 9560 0.1 0.1 17700 1640 ? S 15:05 0:00 /bin/= bash > /etc/xen/scripts/xen-hotplug-cleanup > root 10738 0.1 0.1 17696 1636 ? S 15:05 0:00 /bin/= bash > /etc/xen/scripts/xen-hotplug-cleanup > root 10747 0.1 0.1 17792 1736 ? S 15:05 0:00 /bin/= bash > /etc/xen/scripts/block remove > root 11286 0.0 0.0 4080 324 ? S 15:06 0:00 sleep= 1 > root 11290 0.0 0.0 4080 324 ? S 15:06 0:00 sleep= 1 > root 11294 0.0 0.0 4080 324 ? S 15:06 0:00 sleep= 1 > root 11298 0.0 0.0 4080 324 ? S 15:06 0:00 sleep= 1 > root 11302 0.0 0.0 4080 320 ? S 15:06 0:00 sleep= 1 > root 11306 0.0 0.0 4080 320 ? S 15:06 0:00 sleep= 1 > = > Then I did a xm destroy and I had again the kernel BUG on dmesg. So it > seems that the problem is not fixed by using 3.6.0. Udev version is 17= 5-7. > = So you have definitely something broken in your system, probably in your dom0 kernel. Try with Linux 3.5.4 or 3.4.x, = and see how that goes. Any errors in dom0 dmesg? How about in /var/log/xen/* ? = -- Pasi > = > = > 2012/10/1 Valtteri Kiviniemi <[1]kiviniemi.valtteri@gmail.com> > = > Hi, > = > CPU: Intel Core i7-3770 3.4GHz > [2]http://ark.intel.com/products/65719/ > = > MB: Intel DQ77MK (latest bios updated) > [3]http://www.intel.com/content/www/us/en/motherboards/desktop-mothe= rboards/desktop-board-dq77mk.html > = > Memory: 32GB (4 x 8GB DDR3-1600MHz) > = > Host is Debian wheezy/testing, Xen 4.0.4 and latest 3.6.0 kernel. > = > Noticed also some errors in xm dmesg: > = > root@xen-2:~# xm dmesg > = > (XEN) Xen version 4.0.4 ([4]root@dataproof.fi) (gcc version 4.7.1 > (Debian 4.7.1-7) ) Sun Sep 30 20:28:26 EEST 2012 > (XEN) Latest ChangeSet: unavailable > (XEN) Bootloader: GNU GRUB 0.97 > (XEN) Command line: dom0_mem=3D1280M cpufreq=3Dxen clocksource=3Dhpet > (XEN) Video information: > (XEN) VGA is text mode 80x25, font 8x16 > (XEN) VBE/DDC methods: none; EDID transfer time: 0 seconds > (XEN) EDID info not retrieved because no DDC retrieval method detec= ted > (XEN) Disc information: > (XEN) Found 4 MBR signatures > (XEN) Found 4 EDD information structures > (XEN) Xen-e820 RAM map: > (XEN) 0000000000000000 - 000000000009d800 (usable) > (XEN) 000000000009d800 - 00000000000a0000 (reserved) > (XEN) 00000000000e0000 - 0000000000100000 (reserved) > (XEN) 0000000000100000 - 0000000020000000 (usable) > (XEN) 0000000020000000 - 0000000020200000 (reserved) > (XEN) 0000000020200000 - 0000000040004000 (usable) > (XEN) 0000000040004000 - 0000000040005000 (reserved) > (XEN) 0000000040005000 - 00000000dbe44000 (usable) > (XEN) 00000000dbe44000 - 00000000dc2d7000 (reserved) > (XEN) 00000000dc2d7000 - 00000000dc2e7000 (ACPI data) > (XEN) 00000000dc2e7000 - 00000000dc40c000 (ACPI NVS) > (XEN) 00000000dc40c000 - 00000000dc6af000 (reserved) > (XEN) 00000000dc6af000 - 00000000dc6b0000 (usable) > (XEN) 00000000dc6b0000 - 00000000dc6f3000 (ACPI NVS) > (XEN) 00000000dc6f3000 - 00000000dd000000 (usable) > (XEN) 00000000dd800000 - 00000000dfa00000 (reserved) > (XEN) 00000000f8000000 - 00000000fc000000 (reserved) > (XEN) 00000000fec00000 - 00000000fec01000 (reserved) > (XEN) 00000000fed00000 - 00000000fed04000 (reserved) > (XEN) 00000000fed1c000 - 00000000fed20000 (reserved) > (XEN) 00000000fee00000 - 00000000fee01000 (reserved) > (XEN) 00000000ff000000 - 0000000100000000 (reserved) > (XEN) 0000000100000000 - 000000081e600000 (usable) > (XEN) ACPI: RSDP 000F0490, 0024 (r2 INTEL) > (XEN) ACPI: XSDT DC2DB080, 007C (r1 INTEL DQ77MK 32 AMI > 10013) > (XEN) ACPI: FACP DC2E51F0, 010C (r5 INTEL DQ77MK 32 AMI > 10013) > (XEN) ACPI Warning (tbfadt-0232): FADT (revision 5) is longer than A= CPI > 2.0 version, truncating length 0x10C to 0xF4 [20070126] > (XEN) ACPI: DSDT DC2DB188, A061 (r2 INTEL DQ77MK 32 INTL > 20051117) > (XEN) ACPI: FACS DC40A080, 0040 > (XEN) ACPI: APIC DC2E5300, 0092 (r3 INTEL DQ77MK 32 AMI > 10013) > (XEN) ACPI: FPDT DC2E5398, 0044 (r1 INTEL DQ77MK 32 AMI > 10013) > (XEN) ACPI: TCPA DC2E53E0, 0032 (r2 INTEL DQ77MK 32 MSFT > 1000013) > (XEN) ACPI: MCFG DC2E5418, 003C (r1 INTEL DQ77MK 32 MSFT > 97) > (XEN) ACPI: HPET DC2E5458, 0038 (r1 INTEL DQ77MK 32 AMI. > 5) > (XEN) ACPI: SSDT DC2E5490, 036D (r1 INTEL DQ77MK 32 INTL > 20091112) > (XEN) ACPI: SSDT DC2E5800, 09AA (r1 INTEL DQ77MK 32 INTL > 20051117) > (XEN) ACPI: SSDT DC2E61B0, 0A92 (r1 INTEL DQ77MK 32 INTL > 20051117) > (XEN) ACPI: DMAR DC2E6C48, 00B8 (r1 INTEL DQ77MK 32 INTL > 1) > (XEN) ACPI: ASF! DC2E6D00, 00A5 (r32 INTEL DQ77MK 32 TFSM > F4240) > (XEN) System RAM: 32682MB (33467320kB) > (XEN) Domain heap initialised > (XEN) ACPI: 32/64X FACS address mismatch in FADT - > dc40a080/0000000000000000, using 32 > (XEN) Processor #0 7:10 APIC version 21 > (XEN) Processor #2 7:10 APIC version 21 > (XEN) Processor #4 7:10 APIC version 21 > (XEN) Processor #6 7:10 APIC version 21 > (XEN) Processor #1 7:10 APIC version 21 > (XEN) Processor #3 7:10 APIC version 21 > (XEN) Processor #5 7:10 APIC version 21 > (XEN) Processor #7 7:10 APIC version 21 > (XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 > (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs > (XEN) Switched to APIC driver x2apic_cluster. > (XEN) x2APIC mode enabled. > (XEN) Using scheduler: SMP Credit Scheduler (credit) > (XEN) Detected 3392.369 MHz processor. > (XEN) Initing memory sharing. > (XEN) VMX: Supported advanced features: > (XEN) - APIC MMIO access virtualisation > (XEN) - APIC TPR shadow > (XEN) - Extended Page Tables (EPT) > (XEN) - Virtual-Processor Identifiers (VPID) > (XEN) - Virtual NMI > (XEN) - MSR direct-access bitmap > (XEN) - Unrestricted Guest > (XEN) EPT supports 2MB super page. > (XEN) HVM: ASIDs enabled. > (XEN) HVM: VMX enabled > (XEN) HVM: Hardware Assisted Paging detected. > (XEN) Intel VT-d Snoop Control not enabled. > (XEN) Intel VT-d Dom0 DMA Passthrough not enabled. > (XEN) Intel VT-d Queued Invalidation enabled. > (XEN) Intel VT-d Interrupt Remapping enabled. > (XEN) I/O virtualisation enabled > (XEN) - Dom0 mode: Relaxed > (XEN) Enabled directed EOI with ioapic_ack_old on! > (XEN) Total of 8 processors activated. > (XEN) ENABLING IO-APIC IRQs > (XEN) -> Using old ACK method > (XEN) TSC is reliable, synchronization unnecessary > (XEN) Platform timer appears to have unexpectedly wrapped 1 times. > (XEN) Platform timer is 14.318MHz HPET > (XEN) Allocated console ring of 16 KiB. > (XEN) Brought up 8 CPUs > (XEN) *** LOADING DOMAIN 0 *** > (XEN) Xen kernel: 64-bit, lsb, compat32 > (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1ae7000 > (XEN) PHYSICAL MEMORY ARRANGEMENT: > (XEN) Dom0 alloc.: 0000000804000000->0000000806000000 (319488 pag= es > to be allocated) > (XEN) VIRTUAL MEMORY ARRANGEMENT: > (XEN) Loaded kernel: ffffffff81000000->ffffffff81ae7000 > (XEN) Init. ramdisk: ffffffff81ae7000->ffffffff81ae7000 > (XEN) Phys-Mach map: ffffffff81ae7000->ffffffff81d67000 > (XEN) Start info: ffffffff81d67000->ffffffff81d674b4 > (XEN) Page tables: ffffffff81d68000->ffffffff81d7b000 > (XEN) Boot stack: ffffffff81d7b000->ffffffff81d7c000 > (XEN) TOTAL: ffffffff80000000->ffffffff82000000 > (XEN) ENTRY ADDRESS: ffffffff815e3210 > (XEN) Dom0 has maximum 8 VCPUs > (XEN) [VT-D]iommu.c:718: BIOS did not enable IGD for VT properly. > Disabling IGD VT-d engine. > (XEN) Scrubbing Free RAM: done. > (XEN) Xen trace buffers: disabled > (XEN) Std. Loglevel: Errors and warnings > (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings) > (XEN) Xen is relinquishing VGA console. > (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch > input to Xen) > (XEN) Freed 172kB init memory. > (XEN) traps.c:2333:d0 Domain attempted WRMSR 000000000000008b from > 00000012:00000000 to 00000000:00000000. > = > - Valtteri > = > 2012/10/1 Pasi K=E4rkk=E4inen <[5]pasik@iki.fi> > = > On Mon, Oct 01, 2012 at 09:12:50PM +0300, Valtteri Kiviniemi wrote: > > Hi, > > > > Lowering memory or vcpu's does not help, problem is the same.= I > originally > > installed Xen 4.2.0 and the problem was same on that too. The= n I > > downgraded back to 4.0.4 since I thought that this might be a= bug > on > > 4.2.0. I have been previously running Windows Server 2008 R2 > succesfully > > on Xen 4.0.x on different hardware with this same config. > Hypervisor is > > 64bit and windows is 64bit. > > > > Any ideas what to try next? > > > = > What kind of hardware is that? > = > [6]xen.org automated testing regularly tests Windows VMs, and it w= orks > OK there. > = > -- Pasi > > Ps. qemu-dm.log is the following: > > > > domid: 10 > > config qemu network with xen bridge for tap10.0 xenbr0 > > Using file /dev/virtuals/ts in read-write mode > > Using file /media/iso/windows_server_2008_r2_sp1.iso in read-= only > mode > > Watching /local/domain/0/device-model/10/logdirty/cmd > > Watching /local/domain/0/device-model/10/command > > qemu_map_cache_init nr_buckets =3D 10000 size 4194304 > > shared page at pfn feffd > > buffered io page at pfn feffb > > Guest uuid =3D 52f19e23-2955-c27d-a22c-60c5d8c60d5a > > Time offset set 0 > > populating video RAM at ff000000 > > mapping video RAM from ff000000 > > Register xen platform. > > Done register platform. > > platform_fixed_ioport: changed ro/rw state of ROM memory area. > now is rw > > state. > > xs_read(/local/domain/0/device-model/10/xen_extended_power_mg= mt): > read > > error > > medium change watch on `hdc' (index: 1): > > /media/iso/windows_server_2008_r2_sp1.iso > > I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, > size: 0 > > Log-dirty: no command yet. > > xs_read(/local/domain/10/log-throttling): read error > > qemu: ignoring not-understood drive > `/local/domain/10/log-throttling' > > medium change watch on `/local/domain/10/log-throttling' - > unknown device, > > ignored > > cirrus vga map change while on lfb mode > > mapping vram to f0000000 - f0400000 > > platform_fixed_ioport: changed ro/rw state of ROM memory area. > now is rw > > state. > > platform_fixed_ioport: changed ro/rw state of ROM memory area. > now is ro > > state. > > > > 2012/10/1 Pasi K=E4rkk=E4inen <[1][7]pasik@iki.fi> > > > > On Mon, Oct 01, 2012 at 07:23:44PM +0300, Valtteri Kiviniemi > wrote: > > > Hi, > > > > > > I have tried other config files, but the problem is the > same. At > > the > > > moment I'm using a config file from another server whe= re I > have a > > working > > > Windows Server 2008 R2 installation, so I dont think t= hat > there is > > > anything wrong with my config: > > > > > > > Did you try with less vcpus, for example 2 ? > > how about with less memory, say 2 GB ? > > > > Did you try with later Xen versions? Is that a 32bit Xen, or > 64bit Xen > > hypervisor? > > > > -- Pasi > > > kernel =3D "/usr/lib/xen/boot/hvmloader" > > > builder =3D "hvm" > > > shadow_memory =3D "8" > > > memory =3D "4096" > > > name =3D "ts" > > > vcpus =3D "8" > > > cpus =3D ["0", "1", "2", "3", "4", "5", "6", "7"] > > > pae =3D "1" > > > acpi =3D "1" > > > apic =3D "1" > > > vfb =3D [ 'type=3Dvnc, vnclisten=3D10.100.100.50, vncp= asswd=3Dxxx' > ] > > > xen_extended_power_mgmt =3D "0" > > > vif =3D [ "type=3Dioemu, mac=3D00:16:3e:d7:d7:5d, brid= ge=3Dxenbr0" > ] > > > disk =3D [ "phy:/dev/virtuals/ts,hda,w", > > > > "file:/media/iso/windows_server_2008_r2_sp1.iso,hdc:cdrom,r" ] > > > on_poweroff =3D "destroy" > > > on_reboot =3D "restart" > > > on_crash =3D "restart" > > > viridian =3D "1" > > > device_model =3D "/usr/lib/xen/bin/qemu-dm" > > > boot =3D "dc" > > > snapshot =3D "0" > > > vncconsole =3D "1" > > > sdl =3D "0" > > > opengl =3D "0" > > > vnc =3D "1" > > > nographic =3D "0" > > > stdvga =3D "0" > > > tsc_mode =3D "1" > > > monitor =3D "0" > > > localtime =3D "1" > > > usb =3D "0" > > > keymap =3D "fi" > > > xen_platform_pci =3D "1" > > > pci_msitranslate =3D "1" > > > pci_power_mgmt =3D "0" > > > > > > 2012/10/1 Pasi K=E4rkk=E4inen <[1][2][8]pasik@iki.fi> > > > > > > On Mon, Oct 01, 2012 at 06:46:08PM +0300, Valtteri > Kiviniemi > > wrote: > > > > Hi, > > > > > > > > Yes, I have viridian=3D1 on my domU config. > > > > > > > > > > Try with some known good domU configfile. > > > > > > -- Pasi > > > > 2012/10/1 Pasi K=E4rkk=E4inen > <[1][2][3][9]pasik@iki.fi> > > > > > > > > On Mon, Oct 01, 2012 at 05:06:53PM +0300, > Valtteri > > Kiviniemi > > > wrote: > > > > > Hi, > > > > > > > > > > I'm now using 3.6.0 and can't reproduce = that > crash > > anymore, > > > so it > > > > seems > > > > > that it was a kernel bug. > > > > > > > > > > > > > OK. > > > > > However I'm still getting black screen on > VNC > > > > > when trying to install Windows Server 20= 08 > R2. I can > > see the > > > > "windows is > > > > > loading files" screen but after the > installer starts > > the VNC > > > > display goes > > > > > black. > > > > > > > > > > Any ideas? > > > > > > > > > > > > > Do you have viridian=3D1 specified for the wi= ndows > vm? > > > > > > > > -- Pasi > > > > > > > > > - Valtteri > > > > > > > > > > 2012/10/1 Pasi K=E4rkk=E4inen > <[1][2][3][4][10]pasik@iki.fi> > > > > > > > > > > On Sun, Sep 30, 2012 at 11:18:03PM +03= 00, > Valtteri > > > Kiviniemi > > > > wrote: > > > > > > Hi, > > > > > > > > > > > > > > > > Hello, > > > > > > I'm trying to get Windows Server = 2008 > R2 > > installation > > > > booting on > > > > > Xen > > > > > > 4.0.4. Using the following config: > > > > > > > > > > > > > > > > > > > > > > > > > > > > The domU will start booting just > fine, but > > after a > > > few > > > > minutes the > > > > > VNC > > > > > > screen goes black. After that when > typing "xm > > destroy > > > ts" it > > > > will > > > > > trigger > > > > > > a kernel BUG: > > > > > > > > > > > > BUG: unable to handle kernel NULL > pointer > > dereference > > > at > > > > > 0000000000000030 > > > > > > IP: [] > iput+0x3e/0x195 > > > > > > PGD 0 > > > > > > Oops: 0000 [#1] SMP > > > > > > CPU 6 > > > > > > Pid: 3571, comm: qemu-dm Not tain= ted > > 3.5.0-dom0 #1 > > > > > > > > > > First of all upgrade to latest 3.5.x L= inux > kernel > > release > > > .. so > > > > at least > > > > > 3.5.4. > > > > > > > > > > -- Pasi > > > > > > > > > > > /DQ77MK > > > > > > RIP: e030:[] > > [] > > > > > iput+0x3e/0x195 > > > > > > RSP: e02b:ffff8800389ffbf8 EFLAG= S: > 00010246 > > > > > > RAX: 0000000000000001 RBX: > ffff8800377b0720 > > RCX: > > > > ffff8800501c0000 > > > > > > RDX: ffff8800501c0000 RSI: > ffff8800377b0790 > > RDI: > > > > ffff8800377b0790 > > > > > > RBP: 0000000000000000 R08: > ffffffff815cdd00 > > R09: > > > > 0000000000000016 > > > > > > R10: fefefefefefefeff R11: > ffff8800377b0400 > > R12: > > > > 00000001000a3e0c > > > > > > R13: 0000000000000000 R14: > 00000001000a3e0c > > R15: > > > > ffff8800389ffc28 > > > > > > FS: 00007f1af70a8700(0000) > > GS:ffff880050180000(0000) > > > > > > knlGS:0000000000000000 > > > > > > CS: e033 DS: 0000 ES: 0000 CR0: > > 000000008005003b > > > > > > CR2: 0000000000000030 CR3: > 000000000156d000 > > CR4: > > > > 0000000000002660 > > > > > > DR0: 0000000000000000 DR1: > 0000000000000000 > > DR2: > > > > 0000000000000000 > > > > > > DR3: 0000000000000000 DR6: > 00000000ffff0ff0 > > DR7: > > > > 0000000000000400 > > > > > > Process qemu-dm (pid: 3571, > threadinfo > > > ffff8800389fe000, > > > > task > > > > > > ffff88003a721260) > > > > > > Stack: > > > > > > ffff88003a6d6400 ffff8800377b0000 > > 00000001000a3e0c > > > > > ffffffff8133ce8f > > > > > > ffff8800377b0400 ffffffff8134b6cd > > ffff8800389ffc28 > > > > > ffff8800389ffc28 > > > > > > ffff8800377b00f8 ffff8800377b0680 > > ffff880038cdcd60 > > > > > ffff8800377b0000 > > > > > > Call Trace: > > > > > > [] ? > > sk_release_kernel+0x23/0x39 > > > > > > [] ? > > netdev_run_todo+0x1e9/0x206 > > > > > > [] ? > > tun_chr_close+0x4c/0x7b > > > > > > [] ? > fput+0xe4/0x1c5 > > > > > > [] ? > filp_close+0x61/0x68 > > > > > > [] ? > > put_files_struct+0x62/0xb9 > > > > > > [] ? > do_exit+0x24a/0x74c > > > > > > [] ? > > do_group_exit+0x6b/0x9d > > > > > > [] ? > > > get_signal_to_deliver+0x449/0x46e > > > > > > [] ? > do_signal+0x28/0x4c4 > > > > > > [] ? > > > pvclock_clocksource_read+0x48/0xbf > > > > > > [] ? > ktime_get_ts+0x66/0xa8 > > > > > > [] ? > > > poll_select_copy_remaining+0xe0/0xf5 > > > > > > [] ? > > do_notify_resume+0x3b/0x74 > > > > > > [] ? > int_signal+0x12/0x17 > > > > > > Code: 00 00 00 40 74 02 0f 0b 48 = 8d > 77 70 48 > > 8d bf 08 > > > 01 00 > > > > 00 e8 > > > > > 8b 71 10 > > > > > > 00 85 c0 0f 84 5d 01 00 00 48 8b = 6b > 18 f6 83 > > 80 00 00 > > > 00 08 > > > > <4c> 8b > > > > > 65 30 > > > > > > 74 11 be 68 05 00 00 48 c7 c7 8e = df > 4f 81 e8 > > bb d0 > > > > > > RIP [] > iput+0x3e/0x195 > > > > > > RSP > > > > > > CR2: 0000000000000030 > > > > > > ---[ end trace 67cc1654658fedcc ]= --- > > > > > > Fixing recursive fault but reboot= is > needed! > > > > > > > > > > > > I also tested Xen 4.2.0 and probl= em > is the > > same. So > > > is this > > > > a Xen > > > > > bug or a > > > > > > kernel bug? I am running vanilla > > > [1][2][3][4][5][11]kernel.org kernel > > > > 3.5.0 and > > > > > my > > > > > > hardware is Intel Core i7-3770 CPU > and Intel > > DQ77MK > > > > motherboard > > > > > with > > > > > > latest bios. > > > > > > > > > > > > Best regards, > > > > > > Valtteri Kiviniemi > > > > > > > > > > > > References > > > > > > > > > > > > Visible links > > > > > > 1. [3][4][5][6][12]http://kernel.= org/ > > > > > > > > > > > > _______________________________________________ > > > > > > Xen-devel mailing list > > > > > > [4][5][6][7][13]Xen-devel@lists.xen.= org > > > > > > > [5][6][7][8][14]http://lists.xen.org/xen-devel > > > > > > > > > > References > > > > > > > > > > Visible links > > > > > 1. mailto:[7][8][9][15]pasik@iki.fi > > > > > 2. [8][9][10][16]http://kernel.org/ > > > > > 3. [9][10][11][17]http://kernel.org/ > > > > > 4. > mailto:[10][11][12][18]Xen-devel@lists.xen.org > > > > > 5. > [11][12][13][19]http://lists.xen.org/xen-devel > > > > > > > > References > > > > > > > > Visible links > > > > 1. mailto:[13][14][20]pasik@iki.fi > > > > 2. mailto:[14][15][21]pasik@iki.fi > > > > 3. [15][16][22]http://kernel.org/ > > > > 4. [16][17][23]http://kernel.org/ > > > > 5. mailto:[17][18][24]Xen-devel@lists.xen.org > > > > 6. [18][19][25]http://lists.xen.org/xen-devel > > > > 7. mailto:[19][20][26]pasik@iki.fi > > > > 8. [20][21][27]http://kernel.org/ > > > > 9. [21][22][28]http://kernel.org/ > > > > 10. mailto:[22][23][29]Xen-devel@lists.xen.org > > > > 11. [23][24][30]http://lists.xen.org/xen-devel > > > > > > References > > > > > > Visible links > > > 1. mailto:[25][31]pasik@iki.fi > > > 2. mailto:[26][32]pasik@iki.fi > > > 3. mailto:[27][33]pasik@iki.fi > > > 4. [28][34]http://kernel.org/ > > > 5. [29][35]http://kernel.org/ > > > 6. mailto:[30][36]Xen-devel@lists.xen.org > > > 7. [31][37]http://lists.xen.org/xen-devel > > > 8. mailto:[32][38]pasik@iki.fi > > > 9. [33][39]http://kernel.org/ > > > 10. [34][40]http://kernel.org/ > > > 11. mailto:[35][41]Xen-devel@lists.xen.org > > > 12. [36][42]http://lists.xen.org/xen-devel > > > 13. mailto:[37][43]pasik@iki.fi > > > 14. mailto:[38][44]pasik@iki.fi > > > 15. [39][45]http://kernel.org/ > > > 16. [40][46]http://kernel.org/ > > > 17. mailto:[41][47]Xen-devel@lists.xen.org > > > 18. [42][48]http://lists.xen.org/xen-devel > > > 19. mailto:[43][49]pasik@iki.fi > > > 20. [44][50]http://kernel.org/ > > > 21. [45][51]http://kernel.org/ > > > 22. mailto:[46][52]Xen-devel@lists.xen.org > > > 23. [47][53]http://lists.xen.org/xen-devel > > > > References > > > > Visible links > > 1. mailto:[54]pasik@iki.fi > > 2. mailto:[55]pasik@iki.fi > > 3. mailto:[56]pasik@iki.fi > > 4. mailto:[57]pasik@iki.fi > > 5. [58]http://kernel.org/ > > 6. [59]http://kernel.org/ > > 7. mailto:[60]Xen-devel@lists.xen.org > > 8. [61]http://lists.xen.org/xen-devel > > 9. mailto:[62]pasik@iki.fi > > 10. [63]http://kernel.org/ > > 11. [64]http://kernel.org/ > > 12. mailto:[65]Xen-devel@lists.xen.org > > 13. [66]http://lists.xen.org/xen-devel > > 14. mailto:[67]pasik@iki.fi > > 15. mailto:[68]pasik@iki.fi > > 16. [69]http://kernel.org/ > > 17. [70]http://kernel.org/ > > 18. mailto:[71]Xen-devel@lists.xen.org > > 19. [72]http://lists.xen.org/xen-devel > > 20. mailto:[73]pasik@iki.fi > > 21. [74]http://kernel.org/ > > 22. [75]http://kernel.org/ > > 23. mailto:[76]Xen-devel@lists.xen.org > > 24. [77]http://lists.xen.org/xen-devel > > 25. mailto:[78]pasik@iki.fi > > 26. mailto:[79]pasik@iki.fi > > 27. mailto:[80]pasik@iki.fi > > 28. [81]http://kernel.org/ > > 29. [82]http://kernel.org/ > > 30. mailto:[83]Xen-devel@lists.xen.org > > 31. [84]http://lists.xen.org/xen-devel > > 32. mailto:[85]pasik@iki.fi > > 33. [86]http://kernel.org/ > > 34. [87]http://kernel.org/ > > 35. mailto:[88]Xen-devel@lists.xen.org > > 36. [89]http://lists.xen.org/xen-devel > > 37. mailto:[90]pasik@iki.fi > > 38. mailto:[91]pasik@iki.fi > > 39. [92]http://kernel.org/ > > 40. [93]http://kernel.org/ > > 41. mailto:[94]Xen-devel@lists.xen.org > > 42. [95]http://lists.xen.org/xen-devel > > 43. mailto:[96]pasik@iki.fi > > 44. [97]http://kernel.org/ > > 45. [98]http://kernel.org/ > > 46. mailto:[99]Xen-devel@lists.xen.org > > 47. [100]http://lists.xen.org/xen-devel > = > References > = > Visible links > 1. mailto:kiviniemi.valtteri@gmail.com > 2. http://ark.intel.com/products/65719/ > 3. http://www.intel.com/content/www/us/en/motherboards/desktop-motherb= oards/desktop-board-dq77mk.html > 4. mailto:root@dataproof.fi > 5. mailto:pasik@iki.fi > 6. http://xen.org/ > 7. mailto:pasik@iki.fi > 8. mailto:pasik@iki.fi > 9. mailto:pasik@iki.fi > 10. mailto:pasik@iki.fi > 11. http://kernel.org/ > 12. http://kernel.org/ > 13. mailto:Xen-devel@lists.xen.org > 14. http://lists.xen.org/xen-devel > 15. mailto:pasik@iki.fi > 16. http://kernel.org/ > 17. http://kernel.org/ > 18. mailto:Xen-devel@lists.xen.org > 19. http://lists.xen.org/xen-devel > 20. mailto:pasik@iki.fi > 21. mailto:pasik@iki.fi > 22. http://kernel.org/ > 23. http://kernel.org/ > 24. mailto:Xen-devel@lists.xen.org > 25. http://lists.xen.org/xen-devel > 26. mailto:pasik@iki.fi > 27. http://kernel.org/ > 28. http://kernel.org/ > 29. mailto:Xen-devel@lists.xen.org > 30. http://lists.xen.org/xen-devel > 31. mailto:pasik@iki.fi > 32. mailto:pasik@iki.fi > 33. mailto:pasik@iki.fi > 34. http://kernel.org/ > 35. http://kernel.org/ > 36. mailto:Xen-devel@lists.xen.org > 37. http://lists.xen.org/xen-devel > 38. mailto:pasik@iki.fi > 39. http://kernel.org/ > 40. http://kernel.org/ > 41. mailto:Xen-devel@lists.xen.org > 42. http://lists.xen.org/xen-devel > 43. mailto:pasik@iki.fi > 44. mailto:pasik@iki.fi > 45. http://kernel.org/ > 46. http://kernel.org/ > 47. mailto:Xen-devel@lists.xen.org > 48. http://lists.xen.org/xen-devel > 49. mailto:pasik@iki.fi > 50. http://kernel.org/ > 51. http://kernel.org/ > 52. mailto:Xen-devel@lists.xen.org > 53. http://lists.xen.org/xen-devel > 54. mailto:pasik@iki.fi > 55. mailto:pasik@iki.fi > 56. mailto:pasik@iki.fi > 57. mailto:pasik@iki.fi > 58. http://kernel.org/ > 59. http://kernel.org/ > 60. mailto:Xen-devel@lists.xen.org > 61. http://lists.xen.org/xen-devel > 62. mailto:pasik@iki.fi > 63. http://kernel.org/ > 64. http://kernel.org/ > 65. mailto:Xen-devel@lists.xen.org > 66. http://lists.xen.org/xen-devel > 67. mailto:pasik@iki.fi > 68. mailto:pasik@iki.fi > 69. http://kernel.org/ > 70. http://kernel.org/ > 71. mailto:Xen-devel@lists.xen.org > 72. http://lists.xen.org/xen-devel > 73. mailto:pasik@iki.fi > 74. http://kernel.org/ > 75. http://kernel.org/ > 76. mailto:Xen-devel@lists.xen.org > 77. http://lists.xen.org/xen-devel > 78. mailto:pasik@iki.fi > 79. mailto:pasik@iki.fi > 80. mailto:pasik@iki.fi > 81. http://kernel.org/ > 82. http://kernel.org/ > 83. mailto:Xen-devel@lists.xen.org > 84. http://lists.xen.org/xen-devel > 85. mailto:pasik@iki.fi > 86. http://kernel.org/ > 87. http://kernel.org/ > 88. mailto:Xen-devel@lists.xen.org > 89. http://lists.xen.org/xen-devel > 90. mailto:pasik@iki.fi > 91. mailto:pasik@iki.fi > 92. http://kernel.org/ > 93. http://kernel.org/ > 94. mailto:Xen-devel@lists.xen.org > 95. http://lists.xen.org/xen-devel > 96. mailto:pasik@iki.fi > 97. http://kernel.org/ > 98. http://kernel.org/ > 99. mailto:Xen-devel@lists.xen.org > 100. http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 13:01:36 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 13:01:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ265-0001iI-Ax; Tue, 02 Oct 2012 13:01:13 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ263-0001iD-8i for Xen-devel@lists.xen.org; Tue, 02 Oct 2012 13:01:12 +0000 Received: from [85.158.138.51:50687] by server-10.bemta-3.messagelabs.com id 18/61-02525-695EA605; Tue, 02 Oct 2012 13:01:10 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1349182864!31011395!1 X-Originating-IP: [209.85.161.173] X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG, HTML_50_60, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, ML_RADAR_SPEW_LINKS_23, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20398 invoked from network); 2 Oct 2012 13:01:05 -0000 Received: from mail-gg0-f173.google.com (HELO mail-gg0-f173.google.com) (209.85.161.173) by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 13:01:05 -0000 Received: by ggcs5 with SMTP id s5so304690ggc.32 for ; Tue, 02 Oct 2012 06:01:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ir0+tuAmtRhNQbD09Y57LO3kK8QWLx7zPO8tOWzMMjs=; b=MUpKQAOxaQ9/G1QA+M6m2mSJG7UUKEzR0e78+VZYgAcjn3rcklOVV8thoszosxnFTV fp9Z6hzHocf7ZdrkKz5CeI6P/io7IsOcSSzN5VYb2VAshw+YzmxiNwpGXJ5RbRW7mbLn 7AjMGK26AiROnhzJCVGpELT4pI2clO513B3KSs5E/Hlq8OtbSQd8BoIA3GZikcseILBE taqFOH1k4roejwdqBCGUQRcVaGwPVjQTkLitm9yOwwRhaQGdO51Bfy4BH2vP6aWTYXzQ O6J0DEIvCDC+tJd2hyskyUrwFQhkyPM6IcNQwdVb/nNIVaCfkjsL7N60JpeM8kjmNLwD IWsA== MIME-Version: 1.0 Received: by 10.101.166.35 with SMTP id t35mr5666116ano.63.1349182864121; Tue, 02 Oct 2012 06:01:04 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Tue, 2 Oct 2012 06:01:04 -0700 (PDT) In-Reply-To: <20121002121932.GL8912@reaktio.net> References: <20121001144042.GC8912@reaktio.net> <20121001160117.GD8912@reaktio.net> <20121001164757.GF8912@reaktio.net> <20121001182437.GG8912@reaktio.net> <20121002121932.GL8912@reaktio.net> Date: Tue, 2 Oct 2012 16:01:04 +0300 Message-ID: From: Valtteri Kiviniemi To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= Cc: Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.0.4, kernel 3.5.0 HVM crash and kernel BUG X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0697706113319296394==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============0697706113319296394== Content-Type: multipart/alternative; boundary=001636ef09ad5a601804cb131d45 --001636ef09ad5a601804cb131d45 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, I already tried 3.2, 3.5, 3.5.0, 3.6.0-rc7 and 3.6.0, same problem all of those. My dom0 config is the same config that I'am using on other server where HVM is working, so I dont think that it is a config problem. I have triple checked everything and all should be ok. dom0 dmesg shows the same crash that I have previously posted here. /var/log/xen/ does not contain any specific errors. Could this be some kind of broblem with my motherboard bios being buggy or CPU not supported? I'm using the new intel Ivy Bridge processor which has integrated GPU, but that should not probably cause these kind of problems. Or maybe some ACPI problem? xm dmesg is showing some notices about ACPI. Is there any ACPI kernel parameters that I should try booting? This has to be somekind of problem with my hardware, or then maybe it could be a kernel problem too. I just really cant figure this out myself, I have tried everything. Lets take a quick summary of what has been tested, what hardware I'm using etc. Xen-versions tested: 4.2.0, 4.0.4 Kernel-versions tested: 3.2.0, 3.5.0, 3.5.4, 3.6.0-rc7, 3.6.0 Host OS: Debian testing/wheezy, udev version 175-7, 2.13-35, python version 2.7.3~rc2-2.1 Hardware: CPU: Intel Core i7-3770 3.4GHz MB: Intel DQ77MK (latest bios updated) Memory: 32GB (4 x 8GB DDR3-1600MHz) All relevant log files and configs: dom0 dmesg: http://nago.fi/dmesg.txt qemu-dm log: http://nago.fi/qemu-dm.txt xm dmesg log: http://nago.fi/xm-dmesg.txt domU config: http://nago.fi/domu-config.txt dom0 kernel config: http://nago.fi/dom0-config.txt I have also tried playing with every setting on that domU that I can think of and tried different configs etc. - Valtteri 2012/10/2 Pasi K=E4rkk=E4inen > On Tue, Oct 02, 2012 at 03:11:07PM +0300, Valtteri Kiviniemi wrote: > > Hi, > > > > Another update: > > > > I wanted to check that if a Linux HVM would boot with working VNC > console, > > so I tried to launch a Debian Squeeze installer on HVM. It refused t= o > > start ant told me that vbd hotplug scripts were not working. After > that > > failure even the Windows domU would not anymore start which was > previously > > starting ok. > > > > The hotplug scripts also starts hanging on the processes. > > > > root 9401 0.1 0.1 17700 1640 ? S 15:05 0:00 > /bin/bash > > /etc/xen/scripts/xen-hotplug-cleanup > > root 9441 0.1 0.1 17700 1644 ? S 15:05 0:00 > /bin/bash > > /etc/xen/scripts/xen-hotplug-cleanup > > root 9481 0.1 0.1 17700 1640 ? S 15:05 0:00 > /bin/bash > > /etc/xen/scripts/xen-hotplug-cleanup > > root 9560 0.1 0.1 17700 1640 ? S 15:05 0:00 > /bin/bash > > /etc/xen/scripts/xen-hotplug-cleanup > > root 10738 0.1 0.1 17696 1636 ? S 15:05 0:00 > /bin/bash > > /etc/xen/scripts/xen-hotplug-cleanup > > root 10747 0.1 0.1 17792 1736 ? S 15:05 0:00 > /bin/bash > > /etc/xen/scripts/block remove > > root 11286 0.0 0.0 4080 324 ? S 15:06 0:00 > sleep 1 > > root 11290 0.0 0.0 4080 324 ? S 15:06 0:00 > sleep 1 > > root 11294 0.0 0.0 4080 324 ? S 15:06 0:00 > sleep 1 > > root 11298 0.0 0.0 4080 324 ? S 15:06 0:00 > sleep 1 > > root 11302 0.0 0.0 4080 320 ? S 15:06 0:00 > sleep 1 > > root 11306 0.0 0.0 4080 320 ? S 15:06 0:00 > sleep 1 > > > > Then I did a xm destroy and I had again the kernel BUG on dmesg. So = it > > seems that the problem is not fixed by using 3.6.0. Udev version is > 175-7. > > > > So you have definitely something broken in your system, > probably in your dom0 kernel. Try with Linux 3.5.4 or 3.4.x, > and see how that goes. > > Any errors in dom0 dmesg? How about in /var/log/xen/* ? > > -- Pasi > > > > > > > 2012/10/1 Valtteri Kiviniemi <[1]kiviniemi.valtteri@gmail.com> > > > > Hi, > > > > CPU: Intel Core i7-3770 3.4GHz > > [2]http://ark.intel.com/products/65719/ > > > > MB: Intel DQ77MK (latest bios updated) > > [3] > http://www.intel.com/content/www/us/en/motherboards/desktop-motherboards/= desktop-board-dq77mk.html > > > > Memory: 32GB (4 x 8GB DDR3-1600MHz) > > > > Host is Debian wheezy/testing, Xen 4.0.4 and latest 3.6.0 kernel. > > > > Noticed also some errors in xm dmesg: > > > > root@xen-2:~# xm dmesg > > > > (XEN) Xen version 4.0.4 ([4]root@dataproof.fi) (gcc version 4.7.1 > > (Debian 4.7.1-7) ) Sun Sep 30 20:28:26 EEST 2012 > > (XEN) Latest ChangeSet: unavailable > > (XEN) Bootloader: GNU GRUB 0.97 > > (XEN) Command line: dom0_mem=3D1280M cpufreq=3Dxen clocksource=3Dh= pet > > (XEN) Video information: > > (XEN) VGA is text mode 80x25, font 8x16 > > (XEN) VBE/DDC methods: none; EDID transfer time: 0 seconds > > (XEN) EDID info not retrieved because no DDC retrieval method > detected > > (XEN) Disc information: > > (XEN) Found 4 MBR signatures > > (XEN) Found 4 EDD information structures > > (XEN) Xen-e820 RAM map: > > (XEN) 0000000000000000 - 000000000009d800 (usable) > > (XEN) 000000000009d800 - 00000000000a0000 (reserved) > > (XEN) 00000000000e0000 - 0000000000100000 (reserved) > > (XEN) 0000000000100000 - 0000000020000000 (usable) > > (XEN) 0000000020000000 - 0000000020200000 (reserved) > > (XEN) 0000000020200000 - 0000000040004000 (usable) > > (XEN) 0000000040004000 - 0000000040005000 (reserved) > > (XEN) 0000000040005000 - 00000000dbe44000 (usable) > > (XEN) 00000000dbe44000 - 00000000dc2d7000 (reserved) > > (XEN) 00000000dc2d7000 - 00000000dc2e7000 (ACPI data) > > (XEN) 00000000dc2e7000 - 00000000dc40c000 (ACPI NVS) > > (XEN) 00000000dc40c000 - 00000000dc6af000 (reserved) > > (XEN) 00000000dc6af000 - 00000000dc6b0000 (usable) > > (XEN) 00000000dc6b0000 - 00000000dc6f3000 (ACPI NVS) > > (XEN) 00000000dc6f3000 - 00000000dd000000 (usable) > > (XEN) 00000000dd800000 - 00000000dfa00000 (reserved) > > (XEN) 00000000f8000000 - 00000000fc000000 (reserved) > > (XEN) 00000000fec00000 - 00000000fec01000 (reserved) > > (XEN) 00000000fed00000 - 00000000fed04000 (reserved) > > (XEN) 00000000fed1c000 - 00000000fed20000 (reserved) > > (XEN) 00000000fee00000 - 00000000fee01000 (reserved) > > (XEN) 00000000ff000000 - 0000000100000000 (reserved) > > (XEN) 0000000100000000 - 000000081e600000 (usable) > > (XEN) ACPI: RSDP 000F0490, 0024 (r2 INTEL) > > (XEN) ACPI: XSDT DC2DB080, 007C (r1 INTEL DQ77MK 32 AMI > > 10013) > > (XEN) ACPI: FACP DC2E51F0, 010C (r5 INTEL DQ77MK 32 AMI > > 10013) > > (XEN) ACPI Warning (tbfadt-0232): FADT (revision 5) is longer than > ACPI > > 2.0 version, truncating length 0x10C to 0xF4 [20070126] > > (XEN) ACPI: DSDT DC2DB188, A061 (r2 INTEL DQ77MK 32 INTL > > 20051117) > > (XEN) ACPI: FACS DC40A080, 0040 > > (XEN) ACPI: APIC DC2E5300, 0092 (r3 INTEL DQ77MK 32 AMI > > 10013) > > (XEN) ACPI: FPDT DC2E5398, 0044 (r1 INTEL DQ77MK 32 AMI > > 10013) > > (XEN) ACPI: TCPA DC2E53E0, 0032 (r2 INTEL DQ77MK 32 MSFT > > 1000013) > > (XEN) ACPI: MCFG DC2E5418, 003C (r1 INTEL DQ77MK 32 MSFT > > 97) > > (XEN) ACPI: HPET DC2E5458, 0038 (r1 INTEL DQ77MK 32 AMI. > > 5) > > (XEN) ACPI: SSDT DC2E5490, 036D (r1 INTEL DQ77MK 32 INTL > > 20091112) > > (XEN) ACPI: SSDT DC2E5800, 09AA (r1 INTEL DQ77MK 32 INTL > > 20051117) > > (XEN) ACPI: SSDT DC2E61B0, 0A92 (r1 INTEL DQ77MK 32 INTL > > 20051117) > > (XEN) ACPI: DMAR DC2E6C48, 00B8 (r1 INTEL DQ77MK 32 INTL > > 1) > > (XEN) ACPI: ASF! DC2E6D00, 00A5 (r32 INTEL DQ77MK 32 TFSM > > F4240) > > (XEN) System RAM: 32682MB (33467320kB) > > (XEN) Domain heap initialised > > (XEN) ACPI: 32/64X FACS address mismatch in FADT - > > dc40a080/0000000000000000, using 32 > > (XEN) Processor #0 7:10 APIC version 21 > > (XEN) Processor #2 7:10 APIC version 21 > > (XEN) Processor #4 7:10 APIC version 21 > > (XEN) Processor #6 7:10 APIC version 21 > > (XEN) Processor #1 7:10 APIC version 21 > > (XEN) Processor #3 7:10 APIC version 21 > > (XEN) Processor #5 7:10 APIC version 21 > > (XEN) Processor #7 7:10 APIC version 21 > > (XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-= 23 > > (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs > > (XEN) Switched to APIC driver x2apic_cluster. > > (XEN) x2APIC mode enabled. > > (XEN) Using scheduler: SMP Credit Scheduler (credit) > > (XEN) Detected 3392.369 MHz processor. > > (XEN) Initing memory sharing. > > (XEN) VMX: Supported advanced features: > > (XEN) - APIC MMIO access virtualisation > > (XEN) - APIC TPR shadow > > (XEN) - Extended Page Tables (EPT) > > (XEN) - Virtual-Processor Identifiers (VPID) > > (XEN) - Virtual NMI > > (XEN) - MSR direct-access bitmap > > (XEN) - Unrestricted Guest > > (XEN) EPT supports 2MB super page. > > (XEN) HVM: ASIDs enabled. > > (XEN) HVM: VMX enabled > > (XEN) HVM: Hardware Assisted Paging detected. > > (XEN) Intel VT-d Snoop Control not enabled. > > (XEN) Intel VT-d Dom0 DMA Passthrough not enabled. > > (XEN) Intel VT-d Queued Invalidation enabled. > > (XEN) Intel VT-d Interrupt Remapping enabled. > > (XEN) I/O virtualisation enabled > > (XEN) - Dom0 mode: Relaxed > > (XEN) Enabled directed EOI with ioapic_ack_old on! > > (XEN) Total of 8 processors activated. > > (XEN) ENABLING IO-APIC IRQs > > (XEN) -> Using old ACK method > > (XEN) TSC is reliable, synchronization unnecessary > > (XEN) Platform timer appears to have unexpectedly wrapped 1 times. > > (XEN) Platform timer is 14.318MHz HPET > > (XEN) Allocated console ring of 16 KiB. > > (XEN) Brought up 8 CPUs > > (XEN) *** LOADING DOMAIN 0 *** > > (XEN) Xen kernel: 64-bit, lsb, compat32 > > (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1ae7000 > > (XEN) PHYSICAL MEMORY ARRANGEMENT: > > (XEN) Dom0 alloc.: 0000000804000000->0000000806000000 (319488 > pages > > to be allocated) > > (XEN) VIRTUAL MEMORY ARRANGEMENT: > > (XEN) Loaded kernel: ffffffff81000000->ffffffff81ae7000 > > (XEN) Init. ramdisk: ffffffff81ae7000->ffffffff81ae7000 > > (XEN) Phys-Mach map: ffffffff81ae7000->ffffffff81d67000 > > (XEN) Start info: ffffffff81d67000->ffffffff81d674b4 > > (XEN) Page tables: ffffffff81d68000->ffffffff81d7b000 > > (XEN) Boot stack: ffffffff81d7b000->ffffffff81d7c000 > > (XEN) TOTAL: ffffffff80000000->ffffffff82000000 > > (XEN) ENTRY ADDRESS: ffffffff815e3210 > > (XEN) Dom0 has maximum 8 VCPUs > > (XEN) [VT-D]iommu.c:718: BIOS did not enable IGD for VT properly. > > Disabling IGD VT-d engine. > > (XEN) Scrubbing Free RAM: done. > > (XEN) Xen trace buffers: disabled > > (XEN) Std. Loglevel: Errors and warnings > > (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings) > > (XEN) Xen is relinquishing VGA console. > > (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switc= h > > input to Xen) > > (XEN) Freed 172kB init memory. > > (XEN) traps.c:2333:d0 Domain attempted WRMSR 000000000000008b from > > 00000012:00000000 to 00000000:00000000. > > > > - Valtteri > > > > 2012/10/1 Pasi K=E4rkk=E4inen <[5]pasik@iki.fi> > > > > On Mon, Oct 01, 2012 at 09:12:50PM +0300, Valtteri Kiviniemi > wrote: > > > Hi, > > > > > > Lowering memory or vcpu's does not help, problem is the > same. I > > originally > > > installed Xen 4.2.0 and the problem was same on that too. > Then I > > > downgraded back to 4.0.4 since I thought that this might be > a bug > > on > > > 4.2.0. I have been previously running Windows Server 2008 R= 2 > > succesfully > > > on Xen 4.0.x on different hardware with this same config. > > Hypervisor is > > > 64bit and windows is 64bit. > > > > > > Any ideas what to try next? > > > > > > > What kind of hardware is that? > > > > [6]xen.org automated testing regularly tests Windows VMs, and it > works > > OK there. > > > > -- Pasi > > > Ps. qemu-dm.log is the following: > > > > > > domid: 10 > > > config qemu network with xen bridge for tap10.0 xenbr0 > > > Using file /dev/virtuals/ts in read-write mode > > > Using file /media/iso/windows_server_2008_r2_sp1.iso in > read-only > > mode > > > Watching /local/domain/0/device-model/10/logdirty/cmd > > > Watching /local/domain/0/device-model/10/command > > > qemu_map_cache_init nr_buckets =3D 10000 size 4194304 > > > shared page at pfn feffd > > > buffered io page at pfn feffb > > > Guest uuid =3D 52f19e23-2955-c27d-a22c-60c5d8c60d5a > > > Time offset set 0 > > > populating video RAM at ff000000 > > > mapping video RAM from ff000000 > > > Register xen platform. > > > Done register platform. > > > platform_fixed_ioport: changed ro/rw state of ROM memory > area. > > now is rw > > > state. > > > > xs_read(/local/domain/0/device-model/10/xen_extended_power_mgmt): > > read > > > error > > > medium change watch on `hdc' (index: 1): > > > /media/iso/windows_server_2008_r2_sp1.iso > > > I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: = 0, > > size: 0 > > > Log-dirty: no command yet. > > > xs_read(/local/domain/10/log-throttling): read error > > > qemu: ignoring not-understood drive > > `/local/domain/10/log-throttling' > > > medium change watch on `/local/domain/10/log-throttling' - > > unknown device, > > > ignored > > > cirrus vga map change while on lfb mode > > > mapping vram to f0000000 - f0400000 > > > platform_fixed_ioport: changed ro/rw state of ROM memory > area. > > now is rw > > > state. > > > platform_fixed_ioport: changed ro/rw state of ROM memory > area. > > now is ro > > > state. > > > > > > 2012/10/1 Pasi K=E4rkk=E4inen <[1][7]pasik@iki.fi> > > > > > > On Mon, Oct 01, 2012 at 07:23:44PM +0300, Valtteri > Kiviniemi > > wrote: > > > > Hi, > > > > > > > > I have tried other config files, but the problem is > the > > same. At > > > the > > > > moment I'm using a config file from another server > where I > > have a > > > working > > > > Windows Server 2008 R2 installation, so I dont think > that > > there is > > > > anything wrong with my config: > > > > > > > > > > Did you try with less vcpus, for example 2 ? > > > how about with less memory, say 2 GB ? > > > > > > Did you try with later Xen versions? Is that a 32bit Xen, > or > > 64bit Xen > > > hypervisor? > > > > > > -- Pasi > > > > kernel =3D "/usr/lib/xen/boot/hvmloader" > > > > builder =3D "hvm" > > > > shadow_memory =3D "8" > > > > memory =3D "4096" > > > > name =3D "ts" > > > > vcpus =3D "8" > > > > cpus =3D ["0", "1", "2", "3", "4", "5", "6", "7"] > > > > pae =3D "1" > > > > acpi =3D "1" > > > > apic =3D "1" > > > > vfb =3D [ 'type=3Dvnc, vnclisten=3D10.100.100.50, > vncpasswd=3Dxxx' > > ] > > > > xen_extended_power_mgmt =3D "0" > > > > vif =3D [ "type=3Dioemu, mac=3D00:16:3e:d7:d7:5d, > bridge=3Dxenbr0" > > ] > > > > disk =3D [ "phy:/dev/virtuals/ts,hda,w", > > > > > > "file:/media/iso/windows_server_2008_r2_sp1.iso,hdc:cdrom,r" ] > > > > on_poweroff =3D "destroy" > > > > on_reboot =3D "restart" > > > > on_crash =3D "restart" > > > > viridian =3D "1" > > > > device_model =3D "/usr/lib/xen/bin/qemu-dm" > > > > boot =3D "dc" > > > > snapshot =3D "0" > > > > vncconsole =3D "1" > > > > sdl =3D "0" > > > > opengl =3D "0" > > > > vnc =3D "1" > > > > nographic =3D "0" > > > > stdvga =3D "0" > > > > tsc_mode =3D "1" > > > > monitor =3D "0" > > > > localtime =3D "1" > > > > usb =3D "0" > > > > keymap =3D "fi" > > > > xen_platform_pci =3D "1" > > > > pci_msitranslate =3D "1" > > > > pci_power_mgmt =3D "0" > > > > > > > > 2012/10/1 Pasi K=E4rkk=E4inen <[1][2][8]pasik@iki.fi= > > > > > > > > > On Mon, Oct 01, 2012 at 06:46:08PM +0300, Valtteri > > Kiviniemi > > > wrote: > > > > > Hi, > > > > > > > > > > Yes, I have viridian=3D1 on my domU config. > > > > > > > > > > > > > Try with some known good domU configfile. > > > > > > > > -- Pasi > > > > > 2012/10/1 Pasi K=E4rkk=E4inen > > <[1][2][3][9]pasik@iki.fi> > > > > > > > > > > On Mon, Oct 01, 2012 at 05:06:53PM +0300, > > Valtteri > > > Kiviniemi > > > > wrote: > > > > > > Hi, > > > > > > > > > > > > I'm now using 3.6.0 and can't reproduc= e > that > > crash > > > anymore, > > > > so it > > > > > seems > > > > > > that it was a kernel bug. > > > > > > > > > > > > > > > > OK. > > > > > > However I'm still getting black screen > on > > VNC > > > > > > when trying to install Windows Server > 2008 > > R2. I can > > > see the > > > > > "windows is > > > > > > loading files" screen but after the > > installer starts > > > the VNC > > > > > display goes > > > > > > black. > > > > > > > > > > > > Any ideas? > > > > > > > > > > > > > > > > Do you have viridian=3D1 specified for the > windows > > vm? > > > > > > > > > > -- Pasi > > > > > > > > > > > - Valtteri > > > > > > > > > > > > 2012/10/1 Pasi K=E4rkk=E4inen > > <[1][2][3][4][10]pasik@iki.fi> > > > > > > > > > > > > On Sun, Sep 30, 2012 at 11:18:03PM > +0300, > > Valtteri > > > > Kiviniemi > > > > > wrote: > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > Hello, > > > > > > > I'm trying to get Windows Serve= r > 2008 > > R2 > > > installation > > > > > booting on > > > > > > Xen > > > > > > > 4.0.4. Using the following > config: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The domU will start booting jus= t > > fine, but > > > after a > > > > few > > > > > minutes the > > > > > > VNC > > > > > > > screen goes black. After that > when > > typing "xm > > > destroy > > > > ts" it > > > > > will > > > > > > trigger > > > > > > > a kernel BUG: > > > > > > > > > > > > > > BUG: unable to handle kernel NU= LL > > pointer > > > dereference > > > > at > > > > > > 0000000000000030 > > > > > > > IP: [] > > iput+0x3e/0x195 > > > > > > > PGD 0 > > > > > > > Oops: 0000 [#1] SMP > > > > > > > CPU 6 > > > > > > > Pid: 3571, comm: qemu-dm Not > tainted > > > 3.5.0-dom0 #1 > > > > > > > > > > > > First of all upgrade to latest 3.5.x > Linux > > kernel > > > release > > > > .. so > > > > > at least > > > > > > 3.5.4. > > > > > > > > > > > > -- Pasi > > > > > > > > > > > > > /DQ77MK > > > > > > > RIP: e030:[] > > > [] > > > > > > iput+0x3e/0x195 > > > > > > > RSP: e02b:ffff8800389ffbf8 > EFLAGS: > > 00010246 > > > > > > > RAX: 0000000000000001 RBX: > > ffff8800377b0720 > > > RCX: > > > > > ffff8800501c0000 > > > > > > > RDX: ffff8800501c0000 RSI: > > ffff8800377b0790 > > > RDI: > > > > > ffff8800377b0790 > > > > > > > RBP: 0000000000000000 R08: > > ffffffff815cdd00 > > > R09: > > > > > 0000000000000016 > > > > > > > R10: fefefefefefefeff R11: > > ffff8800377b0400 > > > R12: > > > > > 00000001000a3e0c > > > > > > > R13: 0000000000000000 R14: > > 00000001000a3e0c > > > R15: > > > > > ffff8800389ffc28 > > > > > > > FS: 00007f1af70a8700(0000) > > > GS:ffff880050180000(0000) > > > > > > > knlGS:0000000000000000 > > > > > > > CS: e033 DS: 0000 ES: 0000 CR0= : > > > 000000008005003b > > > > > > > CR2: 0000000000000030 CR3: > > 000000000156d000 > > > CR4: > > > > > 0000000000002660 > > > > > > > DR0: 0000000000000000 DR1: > > 0000000000000000 > > > DR2: > > > > > 0000000000000000 > > > > > > > DR3: 0000000000000000 DR6: > > 00000000ffff0ff0 > > > DR7: > > > > > 0000000000000400 > > > > > > > Process qemu-dm (pid: 3571, > > threadinfo > > > > ffff8800389fe000, > > > > > task > > > > > > > ffff88003a721260) > > > > > > > Stack: > > > > > > > ffff88003a6d6400 > ffff8800377b0000 > > > 00000001000a3e0c > > > > > > ffffffff8133ce8f > > > > > > > ffff8800377b0400 > ffffffff8134b6cd > > > ffff8800389ffc28 > > > > > > ffff8800389ffc28 > > > > > > > ffff8800377b00f8 > ffff8800377b0680 > > > ffff880038cdcd60 > > > > > > ffff8800377b0000 > > > > > > > Call Trace: > > > > > > > [] ? > > > sk_release_kernel+0x23/0x39 > > > > > > > [] ? > > > netdev_run_todo+0x1e9/0x206 > > > > > > > [] ? > > > tun_chr_close+0x4c/0x7b > > > > > > > [] ? > > fput+0xe4/0x1c5 > > > > > > > [] ? > > filp_close+0x61/0x68 > > > > > > > [] ? > > > put_files_struct+0x62/0xb9 > > > > > > > [] ? > > do_exit+0x24a/0x74c > > > > > > > [] ? > > > do_group_exit+0x6b/0x9d > > > > > > > [] ? > > > > get_signal_to_deliver+0x449/0x46e > > > > > > > [] ? > > do_signal+0x28/0x4c4 > > > > > > > [] ? > > > > pvclock_clocksource_read+0x48/0xbf > > > > > > > [] ? > > ktime_get_ts+0x66/0xa8 > > > > > > > [] ? > > > > poll_select_copy_remaining+0xe0/0xf5 > > > > > > > [] ? > > > do_notify_resume+0x3b/0x74 > > > > > > > [] ? > > int_signal+0x12/0x17 > > > > > > > Code: 00 00 00 40 74 02 0f 0b 4= 8 > 8d > > 77 70 48 > > > 8d bf 08 > > > > 01 00 > > > > > 00 e8 > > > > > > 8b 71 10 > > > > > > > 00 85 c0 0f 84 5d 01 00 00 48 8= b > 6b > > 18 f6 83 > > > 80 00 00 > > > > 00 08 > > > > > <4c> 8b > > > > > > 65 30 > > > > > > > 74 11 be 68 05 00 00 48 c7 c7 8= e > df > > 4f 81 e8 > > > bb d0 > > > > > > > RIP [] > > iput+0x3e/0x195 > > > > > > > RSP > > > > > > > CR2: 0000000000000030 > > > > > > > ---[ end trace 67cc1654658fedcc > ]--- > > > > > > > Fixing recursive fault but > reboot is > > needed! > > > > > > > > > > > > > > I also tested Xen 4.2.0 and > problem > > is the > > > same. So > > > > is this > > > > > a Xen > > > > > > bug or a > > > > > > > kernel bug? I am running vanill= a > > > > [1][2][3][4][5][11]kernel.org kernel > > > > > 3.5.0 and > > > > > > my > > > > > > > hardware is Intel Core i7-3770 > CPU > > and Intel > > > DQ77MK > > > > > motherboard > > > > > > with > > > > > > > latest bios. > > > > > > > > > > > > > > Best regards, > > > > > > > Valtteri Kiviniemi > > > > > > > > > > > > > > References > > > > > > > > > > > > > > Visible links > > > > > > > 1. [3][4][5][6][12] > http://kernel.org/ > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Xen-devel mailing list > > > > > > > [4][5][6][7][13] > Xen-devel@lists.xen.org > > > > > > > > > [5][6][7][8][14]http://lists.xen.org/xen-devel > > > > > > > > > > > > References > > > > > > > > > > > > Visible links > > > > > > 1. mailto:[7][8][9][15]pasik@iki.fi > > > > > > 2. [8][9][10][16]http://kernel.org/ > > > > > > 3. [9][10][11][17]http://kernel.org/ > > > > > > 4. > > mailto:[10][11][12][18]Xen-devel@lists.xen.org > > > > > > 5. > > [11][12][13][19]http://lists.xen.org/xen-devel > > > > > > > > > > References > > > > > > > > > > Visible links > > > > > 1. mailto:[13][14][20]pasik@iki.fi > > > > > 2. mailto:[14][15][21]pasik@iki.fi > > > > > 3. [15][16][22]http://kernel.org/ > > > > > 4. [16][17][23]http://kernel.org/ > > > > > 5. mailto:[17][18][24]Xen-devel@lists.xen.org > > > > > 6. [18][19][25]http://lists.xen.org/xen-devel > > > > > 7. mailto:[19][20][26]pasik@iki.fi > > > > > 8. [20][21][27]http://kernel.org/ > > > > > 9. [21][22][28]http://kernel.org/ > > > > > 10. mailto:[22][23][29]Xen-devel@lists.xen.org > > > > > 11. [23][24][30]http://lists.xen.org/xen-devel > > > > > > > > References > > > > > > > > Visible links > > > > 1. mailto:[25][31]pasik@iki.fi > > > > 2. mailto:[26][32]pasik@iki.fi > > > > 3. mailto:[27][33]pasik@iki.fi > > > > 4. [28][34]http://kernel.org/ > > > > 5. [29][35]http://kernel.org/ > > > > 6. mailto:[30][36]Xen-devel@lists.xen.org > > > > 7. [31][37]http://lists.xen.org/xen-devel > > > > 8. mailto:[32][38]pasik@iki.fi > > > > 9. [33][39]http://kernel.org/ > > > > 10. [34][40]http://kernel.org/ > > > > 11. mailto:[35][41]Xen-devel@lists.xen.org > > > > 12. [36][42]http://lists.xen.org/xen-devel > > > > 13. mailto:[37][43]pasik@iki.fi > > > > 14. mailto:[38][44]pasik@iki.fi > > > > 15. [39][45]http://kernel.org/ > > > > 16. [40][46]http://kernel.org/ > > > > 17. mailto:[41][47]Xen-devel@lists.xen.org > > > > 18. [42][48]http://lists.xen.org/xen-devel > > > > 19. mailto:[43][49]pasik@iki.fi > > > > 20. [44][50]http://kernel.org/ > > > > 21. [45][51]http://kernel.org/ > > > > 22. mailto:[46][52]Xen-devel@lists.xen.org > > > > 23. [47][53]http://lists.xen.org/xen-devel > > > > > > References > > > > > > Visible links > > > 1. mailto:[54]pasik@iki.fi > > > 2. mailto:[55]pasik@iki.fi > > > 3. mailto:[56]pasik@iki.fi > > > 4. mailto:[57]pasik@iki.fi > > > 5. [58]http://kernel.org/ > > > 6. [59]http://kernel.org/ > > > 7. mailto:[60]Xen-devel@lists.xen.org > > > 8. [61]http://lists.xen.org/xen-devel > > > 9. mailto:[62]pasik@iki.fi > > > 10. [63]http://kernel.org/ > > > 11. [64]http://kernel.org/ > > > 12. mailto:[65]Xen-devel@lists.xen.org > > > 13. [66]http://lists.xen.org/xen-devel > > > 14. mailto:[67]pasik@iki.fi > > > 15. mailto:[68]pasik@iki.fi > > > 16. [69]http://kernel.org/ > > > 17. [70]http://kernel.org/ > > > 18. mailto:[71]Xen-devel@lists.xen.org > > > 19. [72]http://lists.xen.org/xen-devel > > > 20. mailto:[73]pasik@iki.fi > > > 21. [74]http://kernel.org/ > > > 22. [75]http://kernel.org/ > > > 23. mailto:[76]Xen-devel@lists.xen.org > > > 24. [77]http://lists.xen.org/xen-devel > > > 25. mailto:[78]pasik@iki.fi > > > 26. mailto:[79]pasik@iki.fi > > > 27. mailto:[80]pasik@iki.fi > > > 28. [81]http://kernel.org/ > > > 29. [82]http://kernel.org/ > > > 30. mailto:[83]Xen-devel@lists.xen.org > > > 31. [84]http://lists.xen.org/xen-devel > > > 32. mailto:[85]pasik@iki.fi > > > 33. [86]http://kernel.org/ > > > 34. [87]http://kernel.org/ > > > 35. mailto:[88]Xen-devel@lists.xen.org > > > 36. [89]http://lists.xen.org/xen-devel > > > 37. mailto:[90]pasik@iki.fi > > > 38. mailto:[91]pasik@iki.fi > > > 39. [92]http://kernel.org/ > > > 40. [93]http://kernel.org/ > > > 41. mailto:[94]Xen-devel@lists.xen.org > > > 42. [95]http://lists.xen.org/xen-devel > > > 43. mailto:[96]pasik@iki.fi > > > 44. [97]http://kernel.org/ > > > 45. [98]http://kernel.org/ > > > 46. mailto:[99]Xen-devel@lists.xen.org > > > 47. [100]http://lists.xen.org/xen-devel > > > > References > > > > Visible links > > 1. mailto:kiviniemi.valtteri@gmail.com > > 2. http://ark.intel.com/products/65719/ > > 3. > http://www.intel.com/content/www/us/en/motherboards/desktop-motherboards/= desktop-board-dq77mk.html > > 4. mailto:root@dataproof.fi > > 5. mailto:pasik@iki.fi > > 6. http://xen.org/ > > 7. mailto:pasik@iki.fi > > 8. mailto:pasik@iki.fi > > 9. mailto:pasik@iki.fi > > 10. mailto:pasik@iki.fi > > 11. http://kernel.org/ > > 12. http://kernel.org/ > > 13. mailto:Xen-devel@lists.xen.org > > 14. http://lists.xen.org/xen-devel > > 15. mailto:pasik@iki.fi > > 16. http://kernel.org/ > > 17. http://kernel.org/ > > 18. mailto:Xen-devel@lists.xen.org > > 19. http://lists.xen.org/xen-devel > > 20. mailto:pasik@iki.fi > > 21. mailto:pasik@iki.fi > > 22. http://kernel.org/ > > 23. http://kernel.org/ > > 24. mailto:Xen-devel@lists.xen.org > > 25. http://lists.xen.org/xen-devel > > 26. mailto:pasik@iki.fi > > 27. http://kernel.org/ > > 28. http://kernel.org/ > > 29. mailto:Xen-devel@lists.xen.org > > 30. http://lists.xen.org/xen-devel > > 31. mailto:pasik@iki.fi > > 32. mailto:pasik@iki.fi > > 33. mailto:pasik@iki.fi > > 34. http://kernel.org/ > > 35. http://kernel.org/ > > 36. mailto:Xen-devel@lists.xen.org > > 37. http://lists.xen.org/xen-devel > > 38. mailto:pasik@iki.fi > > 39. http://kernel.org/ > > 40. http://kernel.org/ > > 41. mailto:Xen-devel@lists.xen.org > > 42. http://lists.xen.org/xen-devel > > 43. mailto:pasik@iki.fi > > 44. mailto:pasik@iki.fi > > 45. http://kernel.org/ > > 46. http://kernel.org/ > > 47. mailto:Xen-devel@lists.xen.org > > 48. http://lists.xen.org/xen-devel > > 49. mailto:pasik@iki.fi > > 50. http://kernel.org/ > > 51. http://kernel.org/ > > 52. mailto:Xen-devel@lists.xen.org > > 53. http://lists.xen.org/xen-devel > > 54. mailto:pasik@iki.fi > > 55. mailto:pasik@iki.fi > > 56. mailto:pasik@iki.fi > > 57. mailto:pasik@iki.fi > > 58. http://kernel.org/ > > 59. http://kernel.org/ > > 60. mailto:Xen-devel@lists.xen.org > > 61. http://lists.xen.org/xen-devel > > 62. mailto:pasik@iki.fi > > 63. http://kernel.org/ > > 64. http://kernel.org/ > > 65. mailto:Xen-devel@lists.xen.org > > 66. http://lists.xen.org/xen-devel > > 67. mailto:pasik@iki.fi > > 68. mailto:pasik@iki.fi > > 69. http://kernel.org/ > > 70. http://kernel.org/ > > 71. mailto:Xen-devel@lists.xen.org > > 72. http://lists.xen.org/xen-devel > > 73. mailto:pasik@iki.fi > > 74. http://kernel.org/ > > 75. http://kernel.org/ > > 76. mailto:Xen-devel@lists.xen.org > > 77. http://lists.xen.org/xen-devel > > 78. mailto:pasik@iki.fi > > 79. mailto:pasik@iki.fi > > 80. mailto:pasik@iki.fi > > 81. http://kernel.org/ > > 82. http://kernel.org/ > > 83. mailto:Xen-devel@lists.xen.org > > 84. http://lists.xen.org/xen-devel > > 85. mailto:pasik@iki.fi > > 86. http://kernel.org/ > > 87. http://kernel.org/ > > 88. mailto:Xen-devel@lists.xen.org > > 89. http://lists.xen.org/xen-devel > > 90. mailto:pasik@iki.fi > > 91. mailto:pasik@iki.fi > > 92. http://kernel.org/ > > 93. http://kernel.org/ > > 94. mailto:Xen-devel@lists.xen.org > > 95. http://lists.xen.org/xen-devel > > 96. mailto:pasik@iki.fi > > 97. http://kernel.org/ > > 98. http://kernel.org/ > > 99. mailto:Xen-devel@lists.xen.org > > 100. http://lists.xen.org/xen-devel > --001636ef09ad5a601804cb131d45 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I already tried 3.2, 3.5, 3.5.0, 3.6.0-rc7 and 3.6.0, same probl= em all of those. My dom0 config is the same config that I'am using on o= ther server where HVM is working, so I dont think that it is a config probl= em. I have triple checked everything and all should be ok. dom0 dmesg shows= the same crash that I have previously posted here. /var/log/xen/ does not = contain any specific errors.

Could this be some kind of broblem with my motherboard bios being buggy= or CPU not supported? I'm using the new intel Ivy Bridge processor whi= ch has integrated GPU, but that should not probably cause these kind of pro= blems. Or maybe some ACPI problem? xm dmesg is showing some notices about A= CPI. Is there any ACPI kernel parameters that I should try booting? This ha= s to be somekind of problem with my hardware, or then maybe it could be a k= ernel problem too. I just really cant figure this out myself, I have tried = everything.

Lets take a quick summary of what has been tested, what hardware I'= m using etc.

Xen-versions tested: 4.2.0, 4.0.4
Kernel-versions te= sted: 3.2.0, 3.5.0, 3.5.4, 3.6.0-rc7, 3.6.0

Host OS: Debian testing/= wheezy, udev version 175-7, 2.13-35, python version 2.7.3~rc2-2.1

Hardware:

CPU: Intel Core i7-3770 3.4GHz
MB: Intel DQ77MK (l= atest bios updated)
Memory: 32GB (4 x 8GB DDR3-1600MHz)

All relev= ant log files and configs:

dom0 dmesg: http://nago.fi/dmesg.txt
qemu-dm log: http://nago.fi/qemu-dm.= txt
xm dmesg log: http://nag= o.fi/xm-dmesg.txt
domU config: http://nago.fi/domu-config.txt
dom0 kernel config: http://nago.= fi/dom0-config.txt

I have also tried playing with every setting = on that domU that I can think of and tried different configs etc.

- Valtteri

2012/10/2 Pasi K=E4rkk=E4inen = <pas= ik@iki.fi>
On Tue, Oct 02, 2012 at 03:11:07PM +0300, Valtteri Kivini= emi wrote:
> =A0 =A0Hi,
>
> =A0 =A0Another update:
>
> =A0 =A0I wanted to check that if a Linux HVM would boot with working V= NC console,
> =A0 =A0so I tried to launch a Debian Squeeze installer on HVM. It refu= sed to
> =A0 =A0start ant told me that vbd hotplug scripts were not working. Af= ter that
> =A0 =A0failure even the Windows domU would not anymore start which was= previously
> =A0 =A0starting ok.
>
> =A0 =A0The hotplug scripts also starts hanging on the processes.
>
> =A0 =A0root =A0 =A0 =A09401 =A00.1 =A00.1 =A017700 =A01640 ? =A0 =A0 = =A0 =A0S =A0 =A015:05 =A0 0:00 /bin/bash
> =A0 =A0/etc/xen/scripts/xen-hotplug-cleanup
> =A0 =A0root =A0 =A0 =A09441 =A00.1 =A00.1 =A017700 =A01644 ? =A0 =A0 = =A0 =A0S =A0 =A015:05 =A0 0:00 /bin/bash
> =A0 =A0/etc/xen/scripts/xen-hotplug-cleanup
> =A0 =A0root =A0 =A0 =A09481 =A00.1 =A00.1 =A017700 =A01640 ? =A0 =A0 = =A0 =A0S =A0 =A015:05 =A0 0:00 /bin/bash
> =A0 =A0/etc/xen/scripts/xen-hotplug-cleanup
> =A0 =A0root =A0 =A0 =A09560 =A00.1 =A00.1 =A017700 =A01640 ? =A0 =A0 = =A0 =A0S =A0 =A015:05 =A0 0:00 /bin/bash
> =A0 =A0/etc/xen/scripts/xen-hotplug-cleanup
> =A0 =A0root =A0 =A0 10738 =A00.1 =A00.1 =A017696 =A01636 ? =A0 =A0 =A0= =A0S =A0 =A015:05 =A0 0:00 /bin/bash
> =A0 =A0/etc/xen/scripts/xen-hotplug-cleanup
> =A0 =A0root =A0 =A0 10747 =A00.1 =A00.1 =A017792 =A01736 ? =A0 =A0 =A0= =A0S =A0 =A015:05 =A0 0:00 /bin/bash
> =A0 =A0/etc/xen/scripts/block remove
> =A0 =A0root =A0 =A0 11286 =A00.0 =A00.0 =A0 4080 =A0 324 ? =A0 =A0 =A0= =A0S =A0 =A015:06 =A0 0:00 sleep 1
> =A0 =A0root =A0 =A0 11290 =A00.0 =A00.0 =A0 4080 =A0 324 ? =A0 =A0 =A0= =A0S =A0 =A015:06 =A0 0:00 sleep 1
> =A0 =A0root =A0 =A0 11294 =A00.0 =A00.0 =A0 4080 =A0 324 ? =A0 =A0 =A0= =A0S =A0 =A015:06 =A0 0:00 sleep 1
> =A0 =A0root =A0 =A0 11298 =A00.0 =A00.0 =A0 4080 =A0 324 ? =A0 =A0 =A0= =A0S =A0 =A015:06 =A0 0:00 sleep 1
> =A0 =A0root =A0 =A0 11302 =A00.0 =A00.0 =A0 4080 =A0 320 ? =A0 =A0 =A0= =A0S =A0 =A015:06 =A0 0:00 sleep 1
> =A0 =A0root =A0 =A0 11306 =A00.0 =A00.0 =A0 4080 =A0 320 ? =A0 =A0 =A0= =A0S =A0 =A015:06 =A0 0:00 sleep 1
>
> =A0 =A0Then I did a xm destroy and I had again the kernel BUG on dmesg= . So it
> =A0 =A0seems that the problem is not fixed by using 3.6.0. Udev versio= n is 175-7.
>

So you have definitely something broken in your system,
probably in your dom0 kernel. Try with Linux 3.5.4 or 3.4.x,
and see how that goes.

Any errors in dom0 dmesg? How about in /var/log/xen/* ?

-- Pasi

>
>
> =A0 =A02012/10/1 Valtteri Kiviniemi <[1]kiviniemi.valtteri@gmail.com>
>
> =A0 =A0 =A0Hi,
>
> =A0 =A0 =A0CPU: Intel Core i7-3770 3.4GHz
> =A0 =A0 =A0[2]http://ark.intel.com/products/65719/
>
> =A0 =A0 =A0MB: Intel DQ77MK (latest bios updated)
> =A0 =A0 =A0[3]http://www.intel.com/content/www/us/en/motherboards/desktop-motherboard= s/desktop-board-dq77mk.html
>
> =A0 =A0 =A0Memory: 32GB (4 x 8GB DDR3-1600MHz)
>
> =A0 =A0 =A0Host is Debian wheezy/testing, Xen 4.0.4 and latest 3.6.0 k= ernel.
>
> =A0 =A0 =A0Noticed also some errors in xm dmesg:
>
> =A0 =A0 =A0root@xen-2:~# xm dmesg
>
> =A0 =A0 =A0(XEN) Xen version 4.0.4 ([4]root@dataproof.fi) (gcc version 4.7.1
> =A0 =A0 =A0(Debian 4.7.1-7) ) Sun Sep 30 20:28:= 26 EEST 2012
> =A0 =A0 =A0(XEN) Latest ChangeSet: unavailable
> =A0 =A0 =A0(XEN) Bootloader: GNU GRUB 0.97
> =A0 =A0 =A0(XEN) Command line: dom0_mem=3D1280M cpufreq=3Dxen clocksou= rce=3Dhpet
> =A0 =A0 =A0(XEN) Video information:
> =A0 =A0 =A0(XEN) =A0VGA is text mode 80x25, font 8x16
> =A0 =A0 =A0(XEN) =A0VBE/DDC methods: none; EDID transfer time: 0 secon= ds
> =A0 =A0 =A0(XEN) =A0EDID info not retrieved because no DDC retrieval m= ethod detected
> =A0 =A0 =A0(XEN) Disc information:
> =A0 =A0 =A0(XEN) =A0Found 4 MBR signatures
> =A0 =A0 =A0(XEN) =A0Found 4 EDD information structures
> =A0 =A0 =A0(XEN) Xen-e820 RAM map:
> =A0 =A0 =A0(XEN) =A00000000000000000 - 000000000009d800 (usable)
> =A0 =A0 =A0(XEN) =A0000000000009d800 - 00000000000a0000 (reserved)
> =A0 =A0 =A0(XEN) =A000000000000e0000 - 0000000000100000 (reserved)
> =A0 =A0 =A0(XEN) =A00000000000100000 - 0000000020000000 (usable)
> =A0 =A0 =A0(XEN) =A00000000020000000 - 0000000020200000 (reserved)
> =A0 =A0 =A0(XEN) =A00000000020200000 - 0000000040004000 (usable)
> =A0 =A0 =A0(XEN) =A00000000040004000 - 0000000040005000 (reserved)
> =A0 =A0 =A0(XEN) =A00000000040005000 - 00000000dbe44000 (usable)
> =A0 =A0 =A0(XEN) =A000000000dbe44000 - 00000000dc2d7000 (reserved)
> =A0 =A0 =A0(XEN) =A000000000dc2d7000 - 00000000dc2e7000 (ACPI data) > =A0 =A0 =A0(XEN) =A000000000dc2e7000 - 00000000dc40c000 (ACPI NVS)
> =A0 =A0 =A0(XEN) =A000000000dc40c000 - 00000000dc6af000 (reserved)
> =A0 =A0 =A0(XEN) =A000000000dc6af000 - 00000000dc6b0000 (usable)
> =A0 =A0 =A0(XEN) =A000000000dc6b0000 - 00000000dc6f3000 (ACPI NVS)
> =A0 =A0 =A0(XEN) =A000000000dc6f3000 - 00000000dd000000 (usable)
> =A0 =A0 =A0(XEN) =A000000000dd800000 - 00000000dfa00000 (reserved)
> =A0 =A0 =A0(XEN) =A000000000f8000000 - 00000000fc000000 (reserved)
> =A0 =A0 =A0(XEN) =A000000000fec00000 - 00000000fec01000 (reserved)
> =A0 =A0 =A0(XEN) =A000000000fed00000 - 00000000fed04000 (reserved)
> =A0 =A0 =A0(XEN) =A000000000fed1c000 - 00000000fed20000 (reserved)
> =A0 =A0 =A0(XEN) =A000000000fee00000 - 00000000fee01000 (reserved)
> =A0 =A0 =A0(XEN) =A000000000ff000000 - 0000000100000000 (reserved)
> =A0 =A0 =A0(XEN) =A00000000100000000 - 000000081e600000 (usable)
> =A0 =A0 =A0(XEN) ACPI: RSDP 000F0490, 0024 (r2 =A0INTEL)
> =A0 =A0 =A0(XEN) ACPI: XSDT DC2DB080, 007C (r1 INTEL =A0DQ77MK =A0 =A0= =A0 =A0 32 AMI
> =A0 =A0 =A010013)
> =A0 =A0 =A0(XEN) ACPI: FACP DC2E51F0, 010C (r5 INTEL =A0DQ77MK =A0 =A0= =A0 =A0 32 AMI
> =A0 =A0 =A010013)
> =A0 =A0 =A0(XEN) ACPI Warning (tbfadt-0232): FADT (revision 5) is long= er than ACPI
> =A0 =A0 =A02.0 version, truncating length 0x10C to 0xF4 [20070126]
> =A0 =A0 =A0(XEN) ACPI: DSDT DC2DB188, A061 (r2 INTEL =A0DQ77MK =A0 =A0= =A0 =A0 32 INTL
> =A0 =A0 =A020051117)
> =A0 =A0 =A0(XEN) ACPI: FACS DC40A080, 0040
> =A0 =A0 =A0(XEN) ACPI: APIC DC2E5300, 0092 (r3 INTEL =A0DQ77MK =A0 =A0= =A0 =A0 32 AMI
> =A0 =A0 =A010013)
> =A0 =A0 =A0(XEN) ACPI: FPDT DC2E5398, 0044 (r1 INTEL =A0DQ77MK =A0 =A0= =A0 =A0 32 AMI
> =A0 =A0 =A010013)
> =A0 =A0 =A0(XEN) ACPI: TCPA DC2E53E0, 0032 (r2 INTEL =A0DQ77MK =A0 =A0= =A0 =A0 32 MSFT
> =A0 =A0 =A01000013)
> =A0 =A0 =A0(XEN) ACPI: MCFG DC2E5418, 003C (r1 INTEL =A0DQ77MK =A0 =A0= =A0 =A0 32 MSFT
> =A0 =A0 =A097)
> =A0 =A0 =A0(XEN) ACPI: HPET DC2E5458, 0038 (r1 INTEL =A0DQ77MK =A0 =A0= =A0 =A0 32 AMI.
> =A0 =A0 =A05)
> =A0 =A0 =A0(XEN) ACPI: SSDT DC2E5490, 036D (r1 INTEL =A0DQ77MK =A0 =A0= =A0 =A0 32 INTL
> =A0 =A0 =A020091112)
> =A0 =A0 =A0(XEN) ACPI: SSDT DC2E5800, 09AA (r1 INTEL =A0DQ77MK =A0 =A0= =A0 =A0 32 INTL
> =A0 =A0 =A020051117)
> =A0 =A0 =A0(XEN) ACPI: SSDT DC2E61B0, 0A92 (r1 INTEL =A0DQ77MK =A0 =A0= =A0 =A0 32 INTL
> =A0 =A0 =A020051117)
> =A0 =A0 =A0(XEN) ACPI: DMAR DC2E6C48, 00B8 (r1 INTEL =A0DQ77MK =A0 =A0= =A0 =A0 32 INTL
> =A0 =A0 =A01)
> =A0 =A0 =A0(XEN) ACPI: ASF! DC2E6D00, 00A5 (r32 INTEL =A0DQ77MK =A0 = =A0 =A0 =A0 32 TFSM
> =A0 =A0 =A0F4240)
> =A0 =A0 =A0(XEN) System RAM: 32682MB (33467320kB)
> =A0 =A0 =A0(XEN) Domain heap initialised
> =A0 =A0 =A0(XEN) ACPI: 32/64X FACS address mismatch in FADT -
> =A0 =A0 =A0dc40a080/0000000000000000, using 32
> =A0 =A0 =A0(XEN) Processor #0 7:10 APIC version 21
> =A0 =A0 =A0(XEN) Processor #2 7:10 APIC version 21
> =A0 =A0 =A0(XEN) Processor #4 7:10 APIC version 21
> =A0 =A0 =A0(XEN) Processor #6 7:10 APIC version 21
> =A0 =A0 =A0(XEN) Processor #1 7:10 APIC version 21
> =A0 =A0 =A0(XEN) Processor #3 7:10 APIC version 21
> =A0 =A0 =A0(XEN) Processor #5 7:10 APIC version 21
> =A0 =A0 =A0(XEN) Processor #7 7:10 APIC version 21
> =A0 =A0 =A0(XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000,= GSI 0-23
> =A0 =A0 =A0(XEN) Enabling APIC mode: =A0Flat. =A0Using 1 I/O APICs
> =A0 =A0 =A0(XEN) Switched to APIC driver x2apic_cluster.
> =A0 =A0 =A0(XEN) x2APIC mode enabled.
> =A0 =A0 =A0(XEN) Using scheduler: SMP Credit Scheduler (credit)
> =A0 =A0 =A0(XEN) Detected 3392.369 MHz processor.
> =A0 =A0 =A0(XEN) Initing memory sharing.
> =A0 =A0 =A0(XEN) VMX: Supported advanced features:
> =A0 =A0 =A0(XEN) =A0- APIC MMIO access virtualisation
> =A0 =A0 =A0(XEN) =A0- APIC TPR shadow
> =A0 =A0 =A0(XEN) =A0- Extended Page Tables (EPT)
> =A0 =A0 =A0(XEN) =A0- Virtual-Processor Identifiers (VPID)
> =A0 =A0 =A0(XEN) =A0- Virtual NMI
> =A0 =A0 =A0(XEN) =A0- MSR direct-access bitmap
> =A0 =A0 =A0(XEN) =A0- Unrestricted Guest
> =A0 =A0 =A0(XEN) EPT supports 2MB super page.
> =A0 =A0 =A0(XEN) HVM: ASIDs enabled.
> =A0 =A0 =A0(XEN) HVM: VMX enabled
> =A0 =A0 =A0(XEN) HVM: Hardware Assisted Paging detected.
> =A0 =A0 =A0(XEN) Intel VT-d Snoop Control not enabled.
> =A0 =A0 =A0(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
> =A0 =A0 =A0(XEN) Intel VT-d Queued Invalidation enabled.
> =A0 =A0 =A0(XEN) Intel VT-d Interrupt Remapping enabled.
> =A0 =A0 =A0(XEN) I/O virtualisation enabled
> =A0 =A0 =A0(XEN) =A0- Dom0 mode: Relaxed
> =A0 =A0 =A0(XEN) Enabled directed EOI with ioapic_ack_old on!
> =A0 =A0 =A0(XEN) Total of 8 processors activated.
> =A0 =A0 =A0(XEN) ENABLING IO-APIC IRQs
> =A0 =A0 =A0(XEN) =A0-> Using old ACK method
> =A0 =A0 =A0(XEN) TSC is reliable, synchronization unnecessary
> =A0 =A0 =A0(XEN) Platform timer appears to have unexpectedly wrapped 1= times.
> =A0 =A0 =A0(XEN) Platform timer is 14.318MHz HPET
> =A0 =A0 =A0(XEN) Allocated console ring of 16 KiB.
> =A0 =A0 =A0(XEN) Brought up 8 CPUs
> =A0 =A0 =A0(XEN) *** LOADING DOMAIN 0 ***
> =A0 =A0 =A0(XEN) =A0Xen =A0kernel: 64-bit, lsb, compat32
> =A0 =A0 =A0(XEN) =A0Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -&g= t; 0x1ae7000
> =A0 =A0 =A0(XEN) PHYSICAL MEMORY ARRANGEMENT:
> =A0 =A0 =A0(XEN) =A0Dom0 alloc.: =A0 0000000804000000->000000080600= 0000 (319488 pages
> =A0 =A0 =A0to be allocated)
> =A0 =A0 =A0(XEN) VIRTUAL MEMORY ARRANGEMENT:
> =A0 =A0 =A0(XEN) =A0Loaded kernel: ffffffff81000000->ffffffff81ae70= 00
> =A0 =A0 =A0(XEN) =A0Init. ramdisk: ffffffff81ae7000->ffffffff81ae70= 00
> =A0 =A0 =A0(XEN) =A0Phys-Mach map: ffffffff81ae7000->ffffffff81d670= 00
> =A0 =A0 =A0(XEN) =A0Start info: =A0 =A0ffffffff81d67000->ffffffff81= d674b4
> =A0 =A0 =A0(XEN) =A0Page tables: =A0 ffffffff81d68000->ffffffff81d7= b000
> =A0 =A0 =A0(XEN) =A0Boot stack: =A0 =A0ffffffff81d7b000->ffffffff81= d7c000
> =A0 =A0 =A0(XEN) =A0TOTAL: =A0 =A0 =A0 =A0 ffffffff80000000->ffffff= ff82000000
> =A0 =A0 =A0(XEN) =A0ENTRY ADDRESS: ffffffff815e3210
> =A0 =A0 =A0(XEN) Dom0 has maximum 8 VCPUs
> =A0 =A0 =A0(XEN) [VT-D]iommu.c:718: BIOS did not enable IGD for VT pro= perly.
> =A0 =A0 =A0Disabling IGD VT-d engine.
> =A0 =A0 =A0(XEN) Scrubbing Free RAM: done.
> =A0 =A0 =A0(XEN) Xen trace buffers: disabled
> =A0 =A0 =A0(XEN) Std. Loglevel: Errors and warnings
> =A0 =A0 =A0(XEN) Guest Loglevel: Nothing (Rate-limited: Errors and war= nings)
> =A0 =A0 =A0(XEN) Xen is relinquishing VGA console.
> =A0 =A0 =A0(XEN) *** Serial input -> DOM0 (type 'CTRL-a' th= ree times to switch
> =A0 =A0 =A0input to Xen)
> =A0 =A0 =A0(XEN) Freed 172kB init memory.
> =A0 =A0 =A0(XEN) traps.c:2333:d0 Domain attempted WRMSR 00000000000000= 8b from
> =A0 =A0 =A000000012:00000000 to 00000000:00000000.
>
> =A0 =A0 =A0- Valtteri
>
> =A0 =A0 =A02012/10/1 Pasi K=E4rkk=E4inen <[5]pasik@iki.fi>
>
> =A0 =A0 =A0 =A0On Mon, Oct 01, 2012 at 09:12:50PM +0300, Valtteri Kivi= niemi wrote:
> =A0 =A0 =A0 =A0> =A0 =A0Hi,
> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0Lowering memory or vcpu's does not help= , problem is the same. I
> =A0 =A0 =A0 =A0originally
> =A0 =A0 =A0 =A0> =A0 =A0installed Xen 4.2.0 and the problem was sam= e on that too. Then I
> =A0 =A0 =A0 =A0> =A0 =A0downgraded back to 4.0.4 since I thought th= at this might be a bug
> =A0 =A0 =A0 =A0on
> =A0 =A0 =A0 =A0> =A0 =A04.2.0. I have been previously running Windo= ws Server 2008 R2
> =A0 =A0 =A0 =A0succesfully
> =A0 =A0 =A0 =A0> =A0 =A0on Xen 4.0.x on different hardware with thi= s same config.
> =A0 =A0 =A0 =A0Hypervisor is
> =A0 =A0 =A0 =A0> =A0 =A064bit and windows is 64bit.
> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0Any ideas what to try next?
> =A0 =A0 =A0 =A0>
>
> =A0 =A0 =A0 =A0What kind of hardware is that?
>
> =A0 =A0 =A0 =A0[6]x= en.org automated testing regularly tests Windows VMs, and it works
> =A0 =A0 =A0 =A0OK there.
>
> =A0 =A0 =A0 =A0-- Pasi
> =A0 =A0 =A0 =A0> =A0 =A0Ps. qemu-dm.log is the following:
> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0domid: 10
> =A0 =A0 =A0 =A0> =A0 =A0config qemu network with xen bridge for =A0= tap10.0 xenbr0
> =A0 =A0 =A0 =A0> =A0 =A0Using file /dev/virtuals/ts in read-write m= ode
> =A0 =A0 =A0 =A0> =A0 =A0Using file /media/iso/windows_server_2008_r= 2_sp1.iso in read-only
> =A0 =A0 =A0 =A0mode
> =A0 =A0 =A0 =A0> =A0 =A0Watching /local/domain/0/device-model/10/lo= gdirty/cmd
> =A0 =A0 =A0 =A0> =A0 =A0Watching /local/domain/0/device-model/10/co= mmand
> =A0 =A0 =A0 =A0> =A0 =A0qemu_map_cache_init nr_buckets =3D 10000 si= ze 4194304
> =A0 =A0 =A0 =A0> =A0 =A0shared page at pfn feffd
> =A0 =A0 =A0 =A0> =A0 =A0buffered io page at pfn feffb
> =A0 =A0 =A0 =A0> =A0 =A0Guest uuid =3D 52f19e23-2955-c27d-a22c-60c5= d8c60d5a
> =A0 =A0 =A0 =A0> =A0 =A0Time offset set 0
> =A0 =A0 =A0 =A0> =A0 =A0populating video RAM at ff000000
> =A0 =A0 =A0 =A0> =A0 =A0mapping video RAM from ff000000
> =A0 =A0 =A0 =A0> =A0 =A0Register xen platform.
> =A0 =A0 =A0 =A0> =A0 =A0Done register platform.
> =A0 =A0 =A0 =A0> =A0 =A0platform_fixed_ioport: changed ro/rw state = of ROM memory area.
> =A0 =A0 =A0 =A0now is rw
> =A0 =A0 =A0 =A0> =A0 =A0state.
> =A0 =A0 =A0 =A0> =A0 =A0xs_read(/local/domain/0/device-model/10/xen= _extended_power_mgmt):
> =A0 =A0 =A0 =A0read
> =A0 =A0 =A0 =A0> =A0 =A0error
> =A0 =A0 =A0 =A0> =A0 =A0medium change watch on `hdc' (index: 1)= :
> =A0 =A0 =A0 =A0> =A0 =A0/media/iso/windows_server_2008_r2_sp1.iso > =A0 =A0 =A0 =A0> =A0 =A0I/O request not ready: 0, ptr: 0, port: 0, = data: 0, count: 0,
> =A0 =A0 =A0 =A0size: 0
> =A0 =A0 =A0 =A0> =A0 =A0Log-dirty: no command yet.
> =A0 =A0 =A0 =A0> =A0 =A0xs_read(/local/domain/10/log-throttling): r= ead error
> =A0 =A0 =A0 =A0> =A0 =A0qemu: ignoring not-understood drive
> =A0 =A0 =A0 =A0`/local/domain/10/log-throttling'
> =A0 =A0 =A0 =A0> =A0 =A0medium change watch on `/local/domain/10/lo= g-throttling' -
> =A0 =A0 =A0 =A0unknown device,
> =A0 =A0 =A0 =A0> =A0 =A0ignored
> =A0 =A0 =A0 =A0> =A0 =A0cirrus vga map change while on lfb mode
> =A0 =A0 =A0 =A0> =A0 =A0mapping vram to f0000000 - f0400000
> =A0 =A0 =A0 =A0> =A0 =A0platform_fixed_ioport: changed ro/rw state = of ROM memory area.
> =A0 =A0 =A0 =A0now is rw
> =A0 =A0 =A0 =A0> =A0 =A0state.
> =A0 =A0 =A0 =A0> =A0 =A0platform_fixed_ioport: changed ro/rw state = of ROM memory area.
> =A0 =A0 =A0 =A0now is ro
> =A0 =A0 =A0 =A0> =A0 =A0state.
> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A02012/10/1 Pasi K=E4rkk=E4inen &= lt;[1][7]pasik@iki.fi>
> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0On Mon, Oct 01, 2012 at 07:23:44PM +030= 0, Valtteri Kiviniemi
> =A0 =A0 =A0 =A0wrote:
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0Hi,
> =A0 =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0I have tried other config f= iles, but the problem is the
> =A0 =A0 =A0 =A0same. At
> =A0 =A0 =A0 =A0> =A0 =A0 =A0the
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0moment I'm using a conf= ig file from another server where I
> =A0 =A0 =A0 =A0have a
> =A0 =A0 =A0 =A0> =A0 =A0 =A0working
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0Windows Server 2008 R2 inst= allation, so I dont think that
> =A0 =A0 =A0 =A0there is
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0anything wrong with my conf= ig:
> =A0 =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0Did you try with less vcpus, for exampl= e 2 ?
> =A0 =A0 =A0 =A0> =A0 =A0 =A0how about with less memory, say 2 GB ?<= br> > =A0 =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0Did you try with later Xen versions? Is= that a 32bit Xen, or
> =A0 =A0 =A0 =A064bit Xen
> =A0 =A0 =A0 =A0> =A0 =A0 =A0hypervisor?
> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0-- Pasi
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0kernel =3D "/usr/lib/x= en/boot/hvmloader"
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0builder =3D "hvm"=
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0shadow_memory =3D "8&q= uot;
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0memory =3D "4096"=
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0name =3D "ts"
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0vcpus =3D "8"
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0cpus =3D ["0", &q= uot;1", "2", "3", "4", "5", &q= uot;6", "7"]
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0pae =3D "1"
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0acpi =3D "1"
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0apic =3D "1"
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0vfb =3D [ 'type=3Dvnc, = vnclisten=3D10.100.100.50, vncpasswd=3Dxxx'
> =A0 =A0 =A0 =A0]
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0xen_extended_power_mgmt =3D= "0"
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0vif =3D [ "type=3Dioem= u, mac=3D00:16:3e:d7:d7:5d, bridge=3Dxenbr0"
> =A0 =A0 =A0 =A0]
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0disk =3D [ "phy:/dev/v= irtuals/ts,hda,w",
> =A0 =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0 =A0 "file:/media/iso/windows_server_2008_r2_sp1.iso,h= dc:cdrom,r" ]
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0on_poweroff =3D "destr= oy"
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0on_reboot =3D "restart= "
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0on_crash =3D "restart&= quot;
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0viridian =3D "1"<= br> > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0device_model =3D "/usr= /lib/xen/bin/qemu-dm"
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0boot =3D "dc"
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0snapshot =3D "0"<= br> > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0vncconsole =3D "1"= ;
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0sdl =3D "0"
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0opengl =3D "0" > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0vnc =3D "1"
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0nographic =3D "0"=
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0stdvga =3D "0" > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0tsc_mode =3D "1"<= br> > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0monitor =3D "0" > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0localtime =3D "1"=
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0usb =3D "0"
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0keymap =3D "fi" > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0xen_platform_pci =3D "= 1"
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0pci_msitranslate =3D "= 1"
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0pci_power_mgmt =3D "0&= quot;
> =A0 =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A02012/10/1 Pasi = K=E4rkk=E4inen <[1][2][8]pasik@iki.fi>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0On Mon, Oct 01, 2012 at= 06:46:08PM +0300, Valtteri
> =A0 =A0 =A0 =A0Kiviniemi
> =A0 =A0 =A0 =A0> =A0 =A0 =A0wrote:
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0Hi,
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0Yes, I have= viridian=3D1 on my domU config.
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0Try with some known goo= d domU configfile.
> =A0 =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0-- Pasi
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A02012/10/1 P= asi K=E4rkk=E4inen
> =A0 =A0 =A0 =A0<[1][2][3][9]p= asik@iki.fi>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0= >
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0On Mon,= Oct 01, 2012 at 05:06:53PM +0300,
> =A0 =A0 =A0 =A0Valtteri
> =A0 =A0 =A0 =A0> =A0 =A0 =A0Kiviniemi
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0wrote:
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0Hi,
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0I'm now using 3.6.0 and can't reproduce that
> =A0 =A0 =A0 =A0crash
> =A0 =A0 =A0 =A0> =A0 =A0 =A0anymore,
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0so it
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0seems > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0that it was a kernel bug.
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0OK.
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0However I'm still getting black screen on
> =A0 =A0 =A0 =A0VNC
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0when trying to install Windows Server 2008
> =A0 =A0 =A0 =A0R2. I can
> =A0 =A0 =A0 =A0> =A0 =A0 =A0see the
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0"w= indows is
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0loading files" screen but after the
> =A0 =A0 =A0 =A0installer starts
> =A0 =A0 =A0 =A0> =A0 =A0 =A0the VNC
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0display= goes
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0black.
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0Any ideas?
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0Do you = have viridian=3D1 specified for the windows
> =A0 =A0 =A0 =A0vm?
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0-- Pasi=
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0- Valtteri
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A02012/10/1 Pasi K=E4rkk=E4inen
> =A0 =A0 =A0 =A0<[1][2][3][4][10]pasik@iki.fi>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0= > =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0On Sun, Sep 30, 2012 at 11:18:03PM +0300,
> =A0 =A0 =A0 =A0Valtteri
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0Kiviniemi
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0wrote:<= br> > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0Hi,
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0Hello,
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0I'm trying to get Windows Server 2008
> =A0 =A0 =A0 =A0R2
> =A0 =A0 =A0 =A0> =A0 =A0 =A0installation
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0booting= on
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0Xen
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A04.0.4. Using the following config:
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0<snip>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0The domU will start booting just
> =A0 =A0 =A0 =A0fine, but
> =A0 =A0 =A0 =A0> =A0 =A0 =A0after a
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0few
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0minutes= the
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0VNC
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0screen goes black. After that when
> =A0 =A0 =A0 =A0typing "xm
> =A0 =A0 =A0 =A0> =A0 =A0 =A0destroy
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0ts" it
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0will > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0trigger
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0a kernel BUG:
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0BUG: unable to handle kernel NULL
> =A0 =A0 =A0 =A0pointer
> =A0 =A0 =A0 =A0> =A0 =A0 =A0dereference
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0at
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A00000000000000030
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0IP: [<ffffffff810c50c4>]
> =A0 =A0 =A0 =A0iput+0x3e/0x195
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0PGD 0
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0Oops: 0000 [#1] SMP
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0CPU 6
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0Pid: 3571, comm: qemu-dm Not tainted
> =A0 =A0 =A0 =A0> =A0 =A0 =A03.5.0-dom0 #1
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0First of all upgrade to latest 3.5.x Linux
> =A0 =A0 =A0 =A0kernel
> =A0 =A0 =A0 =A0> =A0 =A0 =A0release
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0.. so
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0at leas= t
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A03.5.4.
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0-- Pasi
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0/DQ77MK
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0RIP: e030:[<ffffffff810c50c4>]
> =A0 =A0 =A0 =A0> =A0 =A0 =A0 [<ffffffff810c50c4>]
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0iput+0x3e/0x195
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0RSP: e02b:ffff8800389ffbf8 =A0EFLAGS:
> =A0 =A0 =A0 =A000010246
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0RAX: 0000000000000001 RBX:
> =A0 =A0 =A0 =A0ffff8800377b0720
> =A0 =A0 =A0 =A0> =A0 =A0 =A0RCX:
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0ffff880= 0501c0000
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0RDX: ffff8800501c0000 RSI:
> =A0 =A0 =A0 =A0ffff8800377b0790
> =A0 =A0 =A0 =A0> =A0 =A0 =A0RDI:
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0ffff880= 0377b0790
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0RBP: 0000000000000000 R08:
> =A0 =A0 =A0 =A0ffffffff815cdd00
> =A0 =A0 =A0 =A0> =A0 =A0 =A0R09:
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A00000000= 000000016
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0R10: fefefefefefefeff R11:
> =A0 =A0 =A0 =A0ffff8800377b0400
> =A0 =A0 =A0 =A0> =A0 =A0 =A0R12:
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A00000000= 1000a3e0c
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0R13: 0000000000000000 R14:
> =A0 =A0 =A0 =A000000001000a3e0c
> =A0 =A0 =A0 =A0> =A0 =A0 =A0R15:
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0ffff880= 0389ffc28
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0FS: =A000007f1af70a8700(0000)
> =A0 =A0 =A0 =A0> =A0 =A0 =A0GS:ffff880050180000(0000)
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0knlGS:0000000000000000
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0CS: =A0e033 DS: 0000 ES: 0000 CR0:
> =A0 =A0 =A0 =A0> =A0 =A0 =A0000000008005003b
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0CR2: 0000000000000030 CR3:
> =A0 =A0 =A0 =A0000000000156d000
> =A0 =A0 =A0 =A0> =A0 =A0 =A0CR4:
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A00000000= 000002660
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0DR0: 0000000000000000 DR1:
> =A0 =A0 =A0 =A00000000000000000
> =A0 =A0 =A0 =A0> =A0 =A0 =A0DR2:
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A00000000= 000000000
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0DR3: 0000000000000000 DR6:
> =A0 =A0 =A0 =A000000000ffff0ff0
> =A0 =A0 =A0 =A0> =A0 =A0 =A0DR7:
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A00000000= 000000400
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0Process qemu-dm (pid: 3571,
> =A0 =A0 =A0 =A0threadinfo
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0ffff8800389fe000,
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0task > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0ffff88003a721260)
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0Stack:
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 ffff88003a6d6400 ffff8800377b0000
> =A0 =A0 =A0 =A0> =A0 =A0 =A000000001000a3e0c
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0ffffffff8133ce8f
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 ffff8800377b0400 ffffffff8134b6cd
> =A0 =A0 =A0 =A0> =A0 =A0 =A0ffff8800389ffc28
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0ffff8800389ffc28
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 ffff8800377b00f8 ffff8800377b0680
> =A0 =A0 =A0 =A0> =A0 =A0 =A0ffff880038cdcd60
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0ffff8800377b0000
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0Call Trace:
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 [<ffffffff8133ce8f>] ?
> =A0 =A0 =A0 =A0> =A0 =A0 =A0sk_release_kernel+0x23/0x39
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 [<ffffffff8134b6cd>] ?
> =A0 =A0 =A0 =A0> =A0 =A0 =A0netdev_run_todo+0x1e9/0x206
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 [<ffffffff8129798f>] ?
> =A0 =A0 =A0 =A0> =A0 =A0 =A0tun_chr_close+0x4c/0x7b
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 [<ffffffff810b39d3>] ?
> =A0 =A0 =A0 =A0fput+0xe4/0x1c5
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 [<ffffffff810b202c>] ?
> =A0 =A0 =A0 =A0filp_close+0x61/0x68
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 [<ffffffff81035e62>] ?
> =A0 =A0 =A0 =A0> =A0 =A0 =A0put_files_struct+0x62/0xb9
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 [<ffffffff81036374>] ?
> =A0 =A0 =A0 =A0do_exit+0x24a/0x74c
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 [<ffffffff81036906>] ?
> =A0 =A0 =A0 =A0> =A0 =A0 =A0do_group_exit+0x6b/0x9d
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 [<ffffffff8103ea0b>] ?
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0get_signal_to_deliver+0= x449/0x46e
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 [<ffffffff81009fa5>] ?
> =A0 =A0 =A0 =A0do_signal+0x28/0x4c4
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 [<ffffffff81027079>] ?
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0pvclock_clocksource_rea= d+0x48/0xbf
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 [<ffffffff8105b745>] ?
> =A0 =A0 =A0 =A0ktime_get_ts+0x66/0xa8
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 [<ffffffff810bfb18>] ?
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0poll_select_copy_remain= ing+0xe0/0xf5
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 [<ffffffff8100a48d>] ?
> =A0 =A0 =A0 =A0> =A0 =A0 =A0do_notify_resume+0x3b/0x74
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 [<ffffffff81411a70>] ?
> =A0 =A0 =A0 =A0int_signal+0x12/0x17
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0Code: 00 00 00 40 74 02 0f 0b 48 8d
> =A0 =A0 =A0 =A077 70 48
> =A0 =A0 =A0 =A0> =A0 =A0 =A08d bf 08
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A001 00
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A000 e8 > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A08b 71 10
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A000 85 c0 0f 84 5d 01 00 00 48 8b 6b
> =A0 =A0 =A0 =A018 f6 83
> =A0 =A0 =A0 =A0> =A0 =A0 =A080 00 00
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A000 08
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0<4c&= gt; 8b
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A065 30
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A074 11 be 68 05 00 00 48 c7 c7 8e df
> =A0 =A0 =A0 =A04f 81 e8
> =A0 =A0 =A0 =A0> =A0 =A0 =A0bb d0
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0RIP =A0[<ffffffff810c50c4>]
> =A0 =A0 =A0 =A0iput+0x3e/0x195
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 RSP <ffff8800389ffbf8>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0CR2: 0000000000000030
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0---[ end trace 67cc1654658fedcc ]---
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0Fixing recursive fault but reboot is
> =A0 =A0 =A0 =A0needed!
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0I also tested Xen 4.2.0 and problem
> =A0 =A0 =A0 =A0is the
> =A0 =A0 =A0 =A0> =A0 =A0 =A0same. So
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0is this
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0a Xen > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0bug or a
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0kernel bug? I am running vanilla
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0[1][2][3][4= ][5][11]kernel.org kern= el
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A03.5.0 and
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0my
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0hardware is Intel Core i7-3770 CPU
> =A0 =A0 =A0 =A0and Intel
> =A0 =A0 =A0 =A0> =A0 =A0 =A0DQ77MK
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0motherb= oard
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0with
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0latest bios.
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0Best regards,
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0Valtteri Kiviniemi
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> References
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0Visible links
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0&= gt; =A0 =A0 =A0> =A0 =A01. [3][4][5][6][12]http://kernel.org/
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0>
> =A0 =A0 =A0 =A0_______________________________________________
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> Xen-devel mailing list
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> [4][5][6][7][13]= Xen-devel@lists.xen.org
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0>
> =A0 =A0 =A0 =A0[5][6][7][8][14]http://lists.xen.org/xen-devel
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> Re= ferences
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0Visible links
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A01. mailto:[7][8][9][15]pasik@iki.fi<= /a>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A02. [8][9][10][16]ht= tp://kernel.org/
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A03. [9][10][11][17]h= ttp://kernel.org/
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A04.
> =A0 =A0 =A0 =A0mailto:[10][11][12][18]Xen-devel@lists.xen.org
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A05.
> =A0 =A0 =A0 =A0[11][12][13][19]http://lists.xen.org/xen-devel
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> References
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0Visible lin= ks
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A01. mailto:[= 13][14][20]pasik@iki.fi
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A02. mailto:[= 14][15][21]pasik@iki.fi
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A03. [15][16]= [22]http://kernel.org/=
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A04. [16][17]= [23]http://kernel.org/=
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A05. mailto:[= 17][18][24]Xen-devel@lists.xen.o= rg
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A06. [18][19]= [25]http://lis= ts.xen.org/xen-devel
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A07. mailto:[= 19][20][26]pasik@iki.fi
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A08. [20][21]= [27]http://kernel.org/=
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A09. [21][22]= [28]http://kernel.org/=
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 10. mailto:[22= ][23][29]Xen-devel@lists.xen.org=
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 11. [23][24][3= 0]http://lists= .xen.org/xen-devel
> =A0 =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> References
> =A0 =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0Visible links
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A01. mailto:[25][31]pasik@iki.fi
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A02. mailto:[26][32]pasik@iki.fi
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A03. mailto:[27][33]pasik@iki.fi
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A04. [28][34]http://kernel.org/
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A05. [29][35]http://kernel.org/
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A06. mailto:[30][36]Xen-devel@lists.xen.org
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A07. [31][37]http://lists.xen.org/xen-devel=
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A08. mailto:[32][38]pasik@iki.fi
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A09. [33][39]http://kernel.org/
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 10. [34][40]http://kernel.org/
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 11. mailto:[35][41]Xen-devel@lists.xen.org
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 12. [36][42]http://lists.xen.org/xen-devel
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 13. mailto:[37][43]pasik@iki.fi
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 14. mailto:[38][44]pasik@iki.fi
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 15. [39][45]http://kernel.org/
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 16. [40][46]http://kernel.org/
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 17. mailto:[41][47]Xen-devel@lists.xen.org
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 18. [42][48]http://lists.xen.org/xen-devel
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 19. mailto:[43][49]pasik@iki.fi
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 20. [44][50]http://kernel.org/
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 21. [45][51]http://kernel.org/
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 22. mailto:[46][52]Xen-devel@lists.xen.org
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 23. [47][53]http://lists.xen.org/xen-devel
> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> References
> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0Visible links
> =A0 =A0 =A0 =A0> =A0 =A01. mailto:[54]pasik@iki.fi
> =A0 =A0 =A0 =A0> =A0 =A02. mailto:[55]pasik@iki.fi
> =A0 =A0 =A0 =A0> =A0 =A03. mailto:[56]pasik@iki.fi
> =A0 =A0 =A0 =A0> =A0 =A04. mailto:[57]pasik@iki.fi
> =A0 =A0 =A0 =A0> =A0 =A05. [58]http://kernel.org/
> =A0 =A0 =A0 =A0> =A0 =A06. [59]http://kernel.org/
> =A0 =A0 =A0 =A0> =A0 =A07. mailto:[60]Xen-devel@lists.xen.org
> =A0 =A0 =A0 =A0> =A0 =A08. [61]http://lists.xen.org/xen-devel
> =A0 =A0 =A0 =A0> =A0 =A09. mailto:[62]pasik@iki.fi
> =A0 =A0 =A0 =A0> =A0 10. [63]http://kernel.org/
> =A0 =A0 =A0 =A0> =A0 11. [64]http://kernel.org/
> =A0 =A0 =A0 =A0> =A0 12. mailto:[65]Xen-devel@lists.xen.org
> =A0 =A0 =A0 =A0> =A0 13. [66]http://lists.xen.org/xen-devel
> =A0 =A0 =A0 =A0> =A0 14. mailto:[67]pasik@iki.fi
> =A0 =A0 =A0 =A0> =A0 15. mailto:[68]pasik@iki.fi
> =A0 =A0 =A0 =A0> =A0 16. [69]http://kernel.org/
> =A0 =A0 =A0 =A0> =A0 17. [70]http://kernel.org/
> =A0 =A0 =A0 =A0> =A0 18. mailto:[71]Xen-devel@lists.xen.org
> =A0 =A0 =A0 =A0> =A0 19. [72]http://lists.xen.org/xen-devel
> =A0 =A0 =A0 =A0> =A0 20. mailto:[73]pasik@iki.fi
> =A0 =A0 =A0 =A0> =A0 21. [74]http://kernel.org/
> =A0 =A0 =A0 =A0> =A0 22. [75]http://kernel.org/
> =A0 =A0 =A0 =A0> =A0 23. mailto:[76]Xen-devel@lists.xen.org
> =A0 =A0 =A0 =A0> =A0 24. [77]http://lists.xen.org/xen-devel
> =A0 =A0 =A0 =A0> =A0 25. mailto:[78]pasik@iki.fi
> =A0 =A0 =A0 =A0> =A0 26. mailto:[79]pasik@iki.fi
> =A0 =A0 =A0 =A0> =A0 27. mailto:[80]pasik@iki.fi
> =A0 =A0 =A0 =A0> =A0 28. [81]http://kernel.org/
> =A0 =A0 =A0 =A0> =A0 29. [82]http://kernel.org/
> =A0 =A0 =A0 =A0> =A0 30. mailto:[83]Xen-devel@lists.xen.org
> =A0 =A0 =A0 =A0> =A0 31. [84]http://lists.xen.org/xen-devel
> =A0 =A0 =A0 =A0> =A0 32. mailto:[85]pasik@iki.fi
> =A0 =A0 =A0 =A0> =A0 33. [86]http://kernel.org/
> =A0 =A0 =A0 =A0> =A0 34. [87]http://kernel.org/
> =A0 =A0 =A0 =A0> =A0 35. mailto:[88]Xen-devel@lists.xen.org
> =A0 =A0 =A0 =A0> =A0 36. [89]http://lists.xen.org/xen-devel
> =A0 =A0 =A0 =A0> =A0 37. mailto:[90]pasik@iki.fi
> =A0 =A0 =A0 =A0> =A0 38. mailto:[91]pasik@iki.fi
> =A0 =A0 =A0 =A0> =A0 39. [92]http://kernel.org/
> =A0 =A0 =A0 =A0> =A0 40. [93]http://kernel.org/
> =A0 =A0 =A0 =A0> =A0 41. mailto:[94]Xen-devel@lists.xen.org
> =A0 =A0 =A0 =A0> =A0 42. [95]http://lists.xen.org/xen-devel
> =A0 =A0 =A0 =A0> =A0 43. mailto:[96]pasik@iki.fi
> =A0 =A0 =A0 =A0> =A0 44. [97]http://kernel.org/
> =A0 =A0 =A0 =A0> =A0 45. [98]http://kernel.org/
> =A0 =A0 =A0 =A0> =A0 46. mailto:[99]Xen-devel@lists.xen.org
> =A0 =A0 =A0 =A0> =A0 47. [100]http://lists.xen.org/xen-devel
>
> References
>
> =A0 =A0Visible links
> =A0 =A01. mailto:kivin= iemi.valtteri@gmail.com
> =A0 =A02. http://ark.intel.com/products/65719/
> =A0 =A03. http:/= /www.intel.com/content/www/us/en/motherboards/desktop-motherboards/desktop-= board-dq77mk.html
> =A0 =A04. mailto:root@dataproof.f= i
> =A0 =A05. mailto:pasik@iki.fi
> =A0 =A06. http://xen.org= /
> =A0 =A07. mailto:pasik@iki.fi
> =A0 =A08. mailto:pasik@iki.fi
> =A0 =A09. mailto:pasik@iki.fi
> =A0 10. mailto:pasik@iki.fi
> =A0 11. http://kernel= .org/
> =A0 12. http://kernel= .org/
> =A0 13. mailto:Xen-devel@li= sts.xen.org
> =A0 14. h= ttp://lists.xen.org/xen-devel
> =A0 15. mailto:pasik= @iki.fi
> =A0 16. http://kernel= .org/
> =A0 17. http://kernel= .org/
> =A0 18. mailto:Xen-devel@li= sts.xen.org
> =A0 19. h= ttp://lists.xen.org/xen-devel
> =A0 20. mailto:pasik@iki.fi
> =A0 21. mailto:pasik@iki.fi<= br> > =A0 22. http://kernel= .org/
> =A0 23. http://kernel= .org/
> =A0 24. mailto:Xen-devel@li= sts.xen.org
> =A0 25. h= ttp://lists.xen.org/xen-devel
> =A0 26. mailto:pasik@iki.fi
> =A0 27. http://kernel= .org/
> =A0 28. http://kernel= .org/
> =A0 29. mailto:Xen-devel@li= sts.xen.org
> =A0 30. h= ttp://lists.xen.org/xen-devel
> =A0 31. mailto:pasik@iki.fi
> =A0 32. mailto:pasik@iki.fi
> =A0 33. mailto:pasik@iki.fi
> =A0 34. http://kernel= .org/
> =A0 35. http://kernel= .org/
> =A0 36. mailto:Xen-devel@li= sts.xen.org
> =A0 37. h= ttp://lists.xen.org/xen-devel
> =A0 38. mailto:pasik= @iki.fi
> =A0 39. http://kernel= .org/
> =A0 40. http://kernel= .org/
> =A0 41. mailto:Xen-devel@li= sts.xen.org
> =A0 42. h= ttp://lists.xen.org/xen-devel
> =A0 43. mailto:pasik@iki.fi
> =A0 44. mailto:pasik@iki.fi<= br> > =A0 45. http://kernel= .org/
> =A0 46. http://kernel= .org/
> =A0 47. mailto:Xen-devel@li= sts.xen.org
> =A0 48. h= ttp://lists.xen.org/xen-devel
> =A0 49. mailto:pasik@iki.fi
> =A0 50. http://kernel= .org/
> =A0 51. http://kernel= .org/
> =A0 52. mailto:Xen-devel@li= sts.xen.org
> =A0 53. h= ttp://lists.xen.org/xen-devel
> =A0 54. mailto:pasik@iki.fi
> =A0 55. mailto:pasik@iki.fi
> =A0 56. mailto:pasik@iki.fi
> =A0 57. mailto:pasik@iki.fi
> =A0 58. http://kernel= .org/
> =A0 59. http://kernel= .org/
> =A0 60. mailto:Xen-devel@li= sts.xen.org
> =A0 61. h= ttp://lists.xen.org/xen-devel
> =A0 62. mailto:pasik@iki.fi
> =A0 63. http://kernel= .org/
> =A0 64. http://kernel= .org/
> =A0 65. mailto:Xen-devel@li= sts.xen.org
> =A0 66. h= ttp://lists.xen.org/xen-devel
> =A0 67. mailto:pasik@iki.fi
> =A0 68. mailto:pasik@iki.fi
> =A0 69. http://kernel= .org/
> =A0 70. http://kernel= .org/
> =A0 71. mailto:Xen-devel@li= sts.xen.org
> =A0 72. h= ttp://lists.xen.org/xen-devel
> =A0 73. mailto:pasik@iki.fi
> =A0 74. http://kernel= .org/
> =A0 75. http://kernel= .org/
> =A0 76. mailto:Xen-devel@li= sts.xen.org
> =A0 77. h= ttp://lists.xen.org/xen-devel
> =A0 78. mailto:pasik@iki.fi
> =A0 79. mailto:pasik@iki.fi
> =A0 80. mailto:pasik@iki.fi
> =A0 81. http://kernel= .org/
> =A0 82. http://kernel= .org/
> =A0 83. mailto:Xen-devel@li= sts.xen.org
> =A0 84. h= ttp://lists.xen.org/xen-devel
> =A0 85. mailto:pasik@iki.fi
> =A0 86. http://kernel= .org/
> =A0 87. http://kernel= .org/
> =A0 88. mailto:Xen-devel@li= sts.xen.org
> =A0 89. h= ttp://lists.xen.org/xen-devel
> =A0 90. mailto:pasik@iki.fi
> =A0 91. mailto:pasik@iki.fi
> =A0 92. http://kernel= .org/
> =A0 93. http://kernel= .org/
> =A0 94. mailto:Xen-devel@li= sts.xen.org
> =A0 95. h= ttp://lists.xen.org/xen-devel
> =A0 96. mailto:pasik@iki.fi
> =A0 97. http://kernel= .org/
> =A0 98. http://kernel= .org/
> =A0 99. mailto:Xen-devel@li= sts.xen.org
> =A0100. h= ttp://lists.xen.org/xen-devel

--001636ef09ad5a601804cb131d45-- --===============0697706113319296394== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============0697706113319296394==-- From xen-devel-bounces@lists.xen.org Tue Oct 02 13:01:36 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 13:01:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ265-0001iI-Ax; Tue, 02 Oct 2012 13:01:13 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ263-0001iD-8i for Xen-devel@lists.xen.org; Tue, 02 Oct 2012 13:01:12 +0000 Received: from [85.158.138.51:50687] by server-10.bemta-3.messagelabs.com id 18/61-02525-695EA605; Tue, 02 Oct 2012 13:01:10 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1349182864!31011395!1 X-Originating-IP: [209.85.161.173] X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG, HTML_50_60, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, ML_RADAR_SPEW_LINKS_23, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20398 invoked from network); 2 Oct 2012 13:01:05 -0000 Received: from mail-gg0-f173.google.com (HELO mail-gg0-f173.google.com) (209.85.161.173) by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 13:01:05 -0000 Received: by ggcs5 with SMTP id s5so304690ggc.32 for ; Tue, 02 Oct 2012 06:01:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ir0+tuAmtRhNQbD09Y57LO3kK8QWLx7zPO8tOWzMMjs=; b=MUpKQAOxaQ9/G1QA+M6m2mSJG7UUKEzR0e78+VZYgAcjn3rcklOVV8thoszosxnFTV fp9Z6hzHocf7ZdrkKz5CeI6P/io7IsOcSSzN5VYb2VAshw+YzmxiNwpGXJ5RbRW7mbLn 7AjMGK26AiROnhzJCVGpELT4pI2clO513B3KSs5E/Hlq8OtbSQd8BoIA3GZikcseILBE taqFOH1k4roejwdqBCGUQRcVaGwPVjQTkLitm9yOwwRhaQGdO51Bfy4BH2vP6aWTYXzQ O6J0DEIvCDC+tJd2hyskyUrwFQhkyPM6IcNQwdVb/nNIVaCfkjsL7N60JpeM8kjmNLwD IWsA== MIME-Version: 1.0 Received: by 10.101.166.35 with SMTP id t35mr5666116ano.63.1349182864121; Tue, 02 Oct 2012 06:01:04 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Tue, 2 Oct 2012 06:01:04 -0700 (PDT) In-Reply-To: <20121002121932.GL8912@reaktio.net> References: <20121001144042.GC8912@reaktio.net> <20121001160117.GD8912@reaktio.net> <20121001164757.GF8912@reaktio.net> <20121001182437.GG8912@reaktio.net> <20121002121932.GL8912@reaktio.net> Date: Tue, 2 Oct 2012 16:01:04 +0300 Message-ID: From: Valtteri Kiviniemi To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= Cc: Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.0.4, kernel 3.5.0 HVM crash and kernel BUG X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0697706113319296394==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============0697706113319296394== Content-Type: multipart/alternative; boundary=001636ef09ad5a601804cb131d45 --001636ef09ad5a601804cb131d45 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, I already tried 3.2, 3.5, 3.5.0, 3.6.0-rc7 and 3.6.0, same problem all of those. My dom0 config is the same config that I'am using on other server where HVM is working, so I dont think that it is a config problem. I have triple checked everything and all should be ok. dom0 dmesg shows the same crash that I have previously posted here. /var/log/xen/ does not contain any specific errors. Could this be some kind of broblem with my motherboard bios being buggy or CPU not supported? I'm using the new intel Ivy Bridge processor which has integrated GPU, but that should not probably cause these kind of problems. Or maybe some ACPI problem? xm dmesg is showing some notices about ACPI. Is there any ACPI kernel parameters that I should try booting? This has to be somekind of problem with my hardware, or then maybe it could be a kernel problem too. I just really cant figure this out myself, I have tried everything. Lets take a quick summary of what has been tested, what hardware I'm using etc. Xen-versions tested: 4.2.0, 4.0.4 Kernel-versions tested: 3.2.0, 3.5.0, 3.5.4, 3.6.0-rc7, 3.6.0 Host OS: Debian testing/wheezy, udev version 175-7, 2.13-35, python version 2.7.3~rc2-2.1 Hardware: CPU: Intel Core i7-3770 3.4GHz MB: Intel DQ77MK (latest bios updated) Memory: 32GB (4 x 8GB DDR3-1600MHz) All relevant log files and configs: dom0 dmesg: http://nago.fi/dmesg.txt qemu-dm log: http://nago.fi/qemu-dm.txt xm dmesg log: http://nago.fi/xm-dmesg.txt domU config: http://nago.fi/domu-config.txt dom0 kernel config: http://nago.fi/dom0-config.txt I have also tried playing with every setting on that domU that I can think of and tried different configs etc. - Valtteri 2012/10/2 Pasi K=E4rkk=E4inen > On Tue, Oct 02, 2012 at 03:11:07PM +0300, Valtteri Kiviniemi wrote: > > Hi, > > > > Another update: > > > > I wanted to check that if a Linux HVM would boot with working VNC > console, > > so I tried to launch a Debian Squeeze installer on HVM. It refused t= o > > start ant told me that vbd hotplug scripts were not working. After > that > > failure even the Windows domU would not anymore start which was > previously > > starting ok. > > > > The hotplug scripts also starts hanging on the processes. > > > > root 9401 0.1 0.1 17700 1640 ? S 15:05 0:00 > /bin/bash > > /etc/xen/scripts/xen-hotplug-cleanup > > root 9441 0.1 0.1 17700 1644 ? S 15:05 0:00 > /bin/bash > > /etc/xen/scripts/xen-hotplug-cleanup > > root 9481 0.1 0.1 17700 1640 ? S 15:05 0:00 > /bin/bash > > /etc/xen/scripts/xen-hotplug-cleanup > > root 9560 0.1 0.1 17700 1640 ? S 15:05 0:00 > /bin/bash > > /etc/xen/scripts/xen-hotplug-cleanup > > root 10738 0.1 0.1 17696 1636 ? S 15:05 0:00 > /bin/bash > > /etc/xen/scripts/xen-hotplug-cleanup > > root 10747 0.1 0.1 17792 1736 ? S 15:05 0:00 > /bin/bash > > /etc/xen/scripts/block remove > > root 11286 0.0 0.0 4080 324 ? S 15:06 0:00 > sleep 1 > > root 11290 0.0 0.0 4080 324 ? S 15:06 0:00 > sleep 1 > > root 11294 0.0 0.0 4080 324 ? S 15:06 0:00 > sleep 1 > > root 11298 0.0 0.0 4080 324 ? S 15:06 0:00 > sleep 1 > > root 11302 0.0 0.0 4080 320 ? S 15:06 0:00 > sleep 1 > > root 11306 0.0 0.0 4080 320 ? S 15:06 0:00 > sleep 1 > > > > Then I did a xm destroy and I had again the kernel BUG on dmesg. So = it > > seems that the problem is not fixed by using 3.6.0. Udev version is > 175-7. > > > > So you have definitely something broken in your system, > probably in your dom0 kernel. Try with Linux 3.5.4 or 3.4.x, > and see how that goes. > > Any errors in dom0 dmesg? How about in /var/log/xen/* ? > > -- Pasi > > > > > > > 2012/10/1 Valtteri Kiviniemi <[1]kiviniemi.valtteri@gmail.com> > > > > Hi, > > > > CPU: Intel Core i7-3770 3.4GHz > > [2]http://ark.intel.com/products/65719/ > > > > MB: Intel DQ77MK (latest bios updated) > > [3] > http://www.intel.com/content/www/us/en/motherboards/desktop-motherboards/= desktop-board-dq77mk.html > > > > Memory: 32GB (4 x 8GB DDR3-1600MHz) > > > > Host is Debian wheezy/testing, Xen 4.0.4 and latest 3.6.0 kernel. > > > > Noticed also some errors in xm dmesg: > > > > root@xen-2:~# xm dmesg > > > > (XEN) Xen version 4.0.4 ([4]root@dataproof.fi) (gcc version 4.7.1 > > (Debian 4.7.1-7) ) Sun Sep 30 20:28:26 EEST 2012 > > (XEN) Latest ChangeSet: unavailable > > (XEN) Bootloader: GNU GRUB 0.97 > > (XEN) Command line: dom0_mem=3D1280M cpufreq=3Dxen clocksource=3Dh= pet > > (XEN) Video information: > > (XEN) VGA is text mode 80x25, font 8x16 > > (XEN) VBE/DDC methods: none; EDID transfer time: 0 seconds > > (XEN) EDID info not retrieved because no DDC retrieval method > detected > > (XEN) Disc information: > > (XEN) Found 4 MBR signatures > > (XEN) Found 4 EDD information structures > > (XEN) Xen-e820 RAM map: > > (XEN) 0000000000000000 - 000000000009d800 (usable) > > (XEN) 000000000009d800 - 00000000000a0000 (reserved) > > (XEN) 00000000000e0000 - 0000000000100000 (reserved) > > (XEN) 0000000000100000 - 0000000020000000 (usable) > > (XEN) 0000000020000000 - 0000000020200000 (reserved) > > (XEN) 0000000020200000 - 0000000040004000 (usable) > > (XEN) 0000000040004000 - 0000000040005000 (reserved) > > (XEN) 0000000040005000 - 00000000dbe44000 (usable) > > (XEN) 00000000dbe44000 - 00000000dc2d7000 (reserved) > > (XEN) 00000000dc2d7000 - 00000000dc2e7000 (ACPI data) > > (XEN) 00000000dc2e7000 - 00000000dc40c000 (ACPI NVS) > > (XEN) 00000000dc40c000 - 00000000dc6af000 (reserved) > > (XEN) 00000000dc6af000 - 00000000dc6b0000 (usable) > > (XEN) 00000000dc6b0000 - 00000000dc6f3000 (ACPI NVS) > > (XEN) 00000000dc6f3000 - 00000000dd000000 (usable) > > (XEN) 00000000dd800000 - 00000000dfa00000 (reserved) > > (XEN) 00000000f8000000 - 00000000fc000000 (reserved) > > (XEN) 00000000fec00000 - 00000000fec01000 (reserved) > > (XEN) 00000000fed00000 - 00000000fed04000 (reserved) > > (XEN) 00000000fed1c000 - 00000000fed20000 (reserved) > > (XEN) 00000000fee00000 - 00000000fee01000 (reserved) > > (XEN) 00000000ff000000 - 0000000100000000 (reserved) > > (XEN) 0000000100000000 - 000000081e600000 (usable) > > (XEN) ACPI: RSDP 000F0490, 0024 (r2 INTEL) > > (XEN) ACPI: XSDT DC2DB080, 007C (r1 INTEL DQ77MK 32 AMI > > 10013) > > (XEN) ACPI: FACP DC2E51F0, 010C (r5 INTEL DQ77MK 32 AMI > > 10013) > > (XEN) ACPI Warning (tbfadt-0232): FADT (revision 5) is longer than > ACPI > > 2.0 version, truncating length 0x10C to 0xF4 [20070126] > > (XEN) ACPI: DSDT DC2DB188, A061 (r2 INTEL DQ77MK 32 INTL > > 20051117) > > (XEN) ACPI: FACS DC40A080, 0040 > > (XEN) ACPI: APIC DC2E5300, 0092 (r3 INTEL DQ77MK 32 AMI > > 10013) > > (XEN) ACPI: FPDT DC2E5398, 0044 (r1 INTEL DQ77MK 32 AMI > > 10013) > > (XEN) ACPI: TCPA DC2E53E0, 0032 (r2 INTEL DQ77MK 32 MSFT > > 1000013) > > (XEN) ACPI: MCFG DC2E5418, 003C (r1 INTEL DQ77MK 32 MSFT > > 97) > > (XEN) ACPI: HPET DC2E5458, 0038 (r1 INTEL DQ77MK 32 AMI. > > 5) > > (XEN) ACPI: SSDT DC2E5490, 036D (r1 INTEL DQ77MK 32 INTL > > 20091112) > > (XEN) ACPI: SSDT DC2E5800, 09AA (r1 INTEL DQ77MK 32 INTL > > 20051117) > > (XEN) ACPI: SSDT DC2E61B0, 0A92 (r1 INTEL DQ77MK 32 INTL > > 20051117) > > (XEN) ACPI: DMAR DC2E6C48, 00B8 (r1 INTEL DQ77MK 32 INTL > > 1) > > (XEN) ACPI: ASF! DC2E6D00, 00A5 (r32 INTEL DQ77MK 32 TFSM > > F4240) > > (XEN) System RAM: 32682MB (33467320kB) > > (XEN) Domain heap initialised > > (XEN) ACPI: 32/64X FACS address mismatch in FADT - > > dc40a080/0000000000000000, using 32 > > (XEN) Processor #0 7:10 APIC version 21 > > (XEN) Processor #2 7:10 APIC version 21 > > (XEN) Processor #4 7:10 APIC version 21 > > (XEN) Processor #6 7:10 APIC version 21 > > (XEN) Processor #1 7:10 APIC version 21 > > (XEN) Processor #3 7:10 APIC version 21 > > (XEN) Processor #5 7:10 APIC version 21 > > (XEN) Processor #7 7:10 APIC version 21 > > (XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-= 23 > > (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs > > (XEN) Switched to APIC driver x2apic_cluster. > > (XEN) x2APIC mode enabled. > > (XEN) Using scheduler: SMP Credit Scheduler (credit) > > (XEN) Detected 3392.369 MHz processor. > > (XEN) Initing memory sharing. > > (XEN) VMX: Supported advanced features: > > (XEN) - APIC MMIO access virtualisation > > (XEN) - APIC TPR shadow > > (XEN) - Extended Page Tables (EPT) > > (XEN) - Virtual-Processor Identifiers (VPID) > > (XEN) - Virtual NMI > > (XEN) - MSR direct-access bitmap > > (XEN) - Unrestricted Guest > > (XEN) EPT supports 2MB super page. > > (XEN) HVM: ASIDs enabled. > > (XEN) HVM: VMX enabled > > (XEN) HVM: Hardware Assisted Paging detected. > > (XEN) Intel VT-d Snoop Control not enabled. > > (XEN) Intel VT-d Dom0 DMA Passthrough not enabled. > > (XEN) Intel VT-d Queued Invalidation enabled. > > (XEN) Intel VT-d Interrupt Remapping enabled. > > (XEN) I/O virtualisation enabled > > (XEN) - Dom0 mode: Relaxed > > (XEN) Enabled directed EOI with ioapic_ack_old on! > > (XEN) Total of 8 processors activated. > > (XEN) ENABLING IO-APIC IRQs > > (XEN) -> Using old ACK method > > (XEN) TSC is reliable, synchronization unnecessary > > (XEN) Platform timer appears to have unexpectedly wrapped 1 times. > > (XEN) Platform timer is 14.318MHz HPET > > (XEN) Allocated console ring of 16 KiB. > > (XEN) Brought up 8 CPUs > > (XEN) *** LOADING DOMAIN 0 *** > > (XEN) Xen kernel: 64-bit, lsb, compat32 > > (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1ae7000 > > (XEN) PHYSICAL MEMORY ARRANGEMENT: > > (XEN) Dom0 alloc.: 0000000804000000->0000000806000000 (319488 > pages > > to be allocated) > > (XEN) VIRTUAL MEMORY ARRANGEMENT: > > (XEN) Loaded kernel: ffffffff81000000->ffffffff81ae7000 > > (XEN) Init. ramdisk: ffffffff81ae7000->ffffffff81ae7000 > > (XEN) Phys-Mach map: ffffffff81ae7000->ffffffff81d67000 > > (XEN) Start info: ffffffff81d67000->ffffffff81d674b4 > > (XEN) Page tables: ffffffff81d68000->ffffffff81d7b000 > > (XEN) Boot stack: ffffffff81d7b000->ffffffff81d7c000 > > (XEN) TOTAL: ffffffff80000000->ffffffff82000000 > > (XEN) ENTRY ADDRESS: ffffffff815e3210 > > (XEN) Dom0 has maximum 8 VCPUs > > (XEN) [VT-D]iommu.c:718: BIOS did not enable IGD for VT properly. > > Disabling IGD VT-d engine. > > (XEN) Scrubbing Free RAM: done. > > (XEN) Xen trace buffers: disabled > > (XEN) Std. Loglevel: Errors and warnings > > (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings) > > (XEN) Xen is relinquishing VGA console. > > (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switc= h > > input to Xen) > > (XEN) Freed 172kB init memory. > > (XEN) traps.c:2333:d0 Domain attempted WRMSR 000000000000008b from > > 00000012:00000000 to 00000000:00000000. > > > > - Valtteri > > > > 2012/10/1 Pasi K=E4rkk=E4inen <[5]pasik@iki.fi> > > > > On Mon, Oct 01, 2012 at 09:12:50PM +0300, Valtteri Kiviniemi > wrote: > > > Hi, > > > > > > Lowering memory or vcpu's does not help, problem is the > same. I > > originally > > > installed Xen 4.2.0 and the problem was same on that too. > Then I > > > downgraded back to 4.0.4 since I thought that this might be > a bug > > on > > > 4.2.0. I have been previously running Windows Server 2008 R= 2 > > succesfully > > > on Xen 4.0.x on different hardware with this same config. > > Hypervisor is > > > 64bit and windows is 64bit. > > > > > > Any ideas what to try next? > > > > > > > What kind of hardware is that? > > > > [6]xen.org automated testing regularly tests Windows VMs, and it > works > > OK there. > > > > -- Pasi > > > Ps. qemu-dm.log is the following: > > > > > > domid: 10 > > > config qemu network with xen bridge for tap10.0 xenbr0 > > > Using file /dev/virtuals/ts in read-write mode > > > Using file /media/iso/windows_server_2008_r2_sp1.iso in > read-only > > mode > > > Watching /local/domain/0/device-model/10/logdirty/cmd > > > Watching /local/domain/0/device-model/10/command > > > qemu_map_cache_init nr_buckets =3D 10000 size 4194304 > > > shared page at pfn feffd > > > buffered io page at pfn feffb > > > Guest uuid =3D 52f19e23-2955-c27d-a22c-60c5d8c60d5a > > > Time offset set 0 > > > populating video RAM at ff000000 > > > mapping video RAM from ff000000 > > > Register xen platform. > > > Done register platform. > > > platform_fixed_ioport: changed ro/rw state of ROM memory > area. > > now is rw > > > state. > > > > xs_read(/local/domain/0/device-model/10/xen_extended_power_mgmt): > > read > > > error > > > medium change watch on `hdc' (index: 1): > > > /media/iso/windows_server_2008_r2_sp1.iso > > > I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: = 0, > > size: 0 > > > Log-dirty: no command yet. > > > xs_read(/local/domain/10/log-throttling): read error > > > qemu: ignoring not-understood drive > > `/local/domain/10/log-throttling' > > > medium change watch on `/local/domain/10/log-throttling' - > > unknown device, > > > ignored > > > cirrus vga map change while on lfb mode > > > mapping vram to f0000000 - f0400000 > > > platform_fixed_ioport: changed ro/rw state of ROM memory > area. > > now is rw > > > state. > > > platform_fixed_ioport: changed ro/rw state of ROM memory > area. > > now is ro > > > state. > > > > > > 2012/10/1 Pasi K=E4rkk=E4inen <[1][7]pasik@iki.fi> > > > > > > On Mon, Oct 01, 2012 at 07:23:44PM +0300, Valtteri > Kiviniemi > > wrote: > > > > Hi, > > > > > > > > I have tried other config files, but the problem is > the > > same. At > > > the > > > > moment I'm using a config file from another server > where I > > have a > > > working > > > > Windows Server 2008 R2 installation, so I dont think > that > > there is > > > > anything wrong with my config: > > > > > > > > > > Did you try with less vcpus, for example 2 ? > > > how about with less memory, say 2 GB ? > > > > > > Did you try with later Xen versions? Is that a 32bit Xen, > or > > 64bit Xen > > > hypervisor? > > > > > > -- Pasi > > > > kernel =3D "/usr/lib/xen/boot/hvmloader" > > > > builder =3D "hvm" > > > > shadow_memory =3D "8" > > > > memory =3D "4096" > > > > name =3D "ts" > > > > vcpus =3D "8" > > > > cpus =3D ["0", "1", "2", "3", "4", "5", "6", "7"] > > > > pae =3D "1" > > > > acpi =3D "1" > > > > apic =3D "1" > > > > vfb =3D [ 'type=3Dvnc, vnclisten=3D10.100.100.50, > vncpasswd=3Dxxx' > > ] > > > > xen_extended_power_mgmt =3D "0" > > > > vif =3D [ "type=3Dioemu, mac=3D00:16:3e:d7:d7:5d, > bridge=3Dxenbr0" > > ] > > > > disk =3D [ "phy:/dev/virtuals/ts,hda,w", > > > > > > "file:/media/iso/windows_server_2008_r2_sp1.iso,hdc:cdrom,r" ] > > > > on_poweroff =3D "destroy" > > > > on_reboot =3D "restart" > > > > on_crash =3D "restart" > > > > viridian =3D "1" > > > > device_model =3D "/usr/lib/xen/bin/qemu-dm" > > > > boot =3D "dc" > > > > snapshot =3D "0" > > > > vncconsole =3D "1" > > > > sdl =3D "0" > > > > opengl =3D "0" > > > > vnc =3D "1" > > > > nographic =3D "0" > > > > stdvga =3D "0" > > > > tsc_mode =3D "1" > > > > monitor =3D "0" > > > > localtime =3D "1" > > > > usb =3D "0" > > > > keymap =3D "fi" > > > > xen_platform_pci =3D "1" > > > > pci_msitranslate =3D "1" > > > > pci_power_mgmt =3D "0" > > > > > > > > 2012/10/1 Pasi K=E4rkk=E4inen <[1][2][8]pasik@iki.fi= > > > > > > > > > On Mon, Oct 01, 2012 at 06:46:08PM +0300, Valtteri > > Kiviniemi > > > wrote: > > > > > Hi, > > > > > > > > > > Yes, I have viridian=3D1 on my domU config. > > > > > > > > > > > > > Try with some known good domU configfile. > > > > > > > > -- Pasi > > > > > 2012/10/1 Pasi K=E4rkk=E4inen > > <[1][2][3][9]pasik@iki.fi> > > > > > > > > > > On Mon, Oct 01, 2012 at 05:06:53PM +0300, > > Valtteri > > > Kiviniemi > > > > wrote: > > > > > > Hi, > > > > > > > > > > > > I'm now using 3.6.0 and can't reproduc= e > that > > crash > > > anymore, > > > > so it > > > > > seems > > > > > > that it was a kernel bug. > > > > > > > > > > > > > > > > OK. > > > > > > However I'm still getting black screen > on > > VNC > > > > > > when trying to install Windows Server > 2008 > > R2. I can > > > see the > > > > > "windows is > > > > > > loading files" screen but after the > > installer starts > > > the VNC > > > > > display goes > > > > > > black. > > > > > > > > > > > > Any ideas? > > > > > > > > > > > > > > > > Do you have viridian=3D1 specified for the > windows > > vm? > > > > > > > > > > -- Pasi > > > > > > > > > > > - Valtteri > > > > > > > > > > > > 2012/10/1 Pasi K=E4rkk=E4inen > > <[1][2][3][4][10]pasik@iki.fi> > > > > > > > > > > > > On Sun, Sep 30, 2012 at 11:18:03PM > +0300, > > Valtteri > > > > Kiviniemi > > > > > wrote: > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > Hello, > > > > > > > I'm trying to get Windows Serve= r > 2008 > > R2 > > > installation > > > > > booting on > > > > > > Xen > > > > > > > 4.0.4. Using the following > config: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The domU will start booting jus= t > > fine, but > > > after a > > > > few > > > > > minutes the > > > > > > VNC > > > > > > > screen goes black. After that > when > > typing "xm > > > destroy > > > > ts" it > > > > > will > > > > > > trigger > > > > > > > a kernel BUG: > > > > > > > > > > > > > > BUG: unable to handle kernel NU= LL > > pointer > > > dereference > > > > at > > > > > > 0000000000000030 > > > > > > > IP: [] > > iput+0x3e/0x195 > > > > > > > PGD 0 > > > > > > > Oops: 0000 [#1] SMP > > > > > > > CPU 6 > > > > > > > Pid: 3571, comm: qemu-dm Not > tainted > > > 3.5.0-dom0 #1 > > > > > > > > > > > > First of all upgrade to latest 3.5.x > Linux > > kernel > > > release > > > > .. so > > > > > at least > > > > > > 3.5.4. > > > > > > > > > > > > -- Pasi > > > > > > > > > > > > > /DQ77MK > > > > > > > RIP: e030:[] > > > [] > > > > > > iput+0x3e/0x195 > > > > > > > RSP: e02b:ffff8800389ffbf8 > EFLAGS: > > 00010246 > > > > > > > RAX: 0000000000000001 RBX: > > ffff8800377b0720 > > > RCX: > > > > > ffff8800501c0000 > > > > > > > RDX: ffff8800501c0000 RSI: > > ffff8800377b0790 > > > RDI: > > > > > ffff8800377b0790 > > > > > > > RBP: 0000000000000000 R08: > > ffffffff815cdd00 > > > R09: > > > > > 0000000000000016 > > > > > > > R10: fefefefefefefeff R11: > > ffff8800377b0400 > > > R12: > > > > > 00000001000a3e0c > > > > > > > R13: 0000000000000000 R14: > > 00000001000a3e0c > > > R15: > > > > > ffff8800389ffc28 > > > > > > > FS: 00007f1af70a8700(0000) > > > GS:ffff880050180000(0000) > > > > > > > knlGS:0000000000000000 > > > > > > > CS: e033 DS: 0000 ES: 0000 CR0= : > > > 000000008005003b > > > > > > > CR2: 0000000000000030 CR3: > > 000000000156d000 > > > CR4: > > > > > 0000000000002660 > > > > > > > DR0: 0000000000000000 DR1: > > 0000000000000000 > > > DR2: > > > > > 0000000000000000 > > > > > > > DR3: 0000000000000000 DR6: > > 00000000ffff0ff0 > > > DR7: > > > > > 0000000000000400 > > > > > > > Process qemu-dm (pid: 3571, > > threadinfo > > > > ffff8800389fe000, > > > > > task > > > > > > > ffff88003a721260) > > > > > > > Stack: > > > > > > > ffff88003a6d6400 > ffff8800377b0000 > > > 00000001000a3e0c > > > > > > ffffffff8133ce8f > > > > > > > ffff8800377b0400 > ffffffff8134b6cd > > > ffff8800389ffc28 > > > > > > ffff8800389ffc28 > > > > > > > ffff8800377b00f8 > ffff8800377b0680 > > > ffff880038cdcd60 > > > > > > ffff8800377b0000 > > > > > > > Call Trace: > > > > > > > [] ? > > > sk_release_kernel+0x23/0x39 > > > > > > > [] ? > > > netdev_run_todo+0x1e9/0x206 > > > > > > > [] ? > > > tun_chr_close+0x4c/0x7b > > > > > > > [] ? > > fput+0xe4/0x1c5 > > > > > > > [] ? > > filp_close+0x61/0x68 > > > > > > > [] ? > > > put_files_struct+0x62/0xb9 > > > > > > > [] ? > > do_exit+0x24a/0x74c > > > > > > > [] ? > > > do_group_exit+0x6b/0x9d > > > > > > > [] ? > > > > get_signal_to_deliver+0x449/0x46e > > > > > > > [] ? > > do_signal+0x28/0x4c4 > > > > > > > [] ? > > > > pvclock_clocksource_read+0x48/0xbf > > > > > > > [] ? > > ktime_get_ts+0x66/0xa8 > > > > > > > [] ? > > > > poll_select_copy_remaining+0xe0/0xf5 > > > > > > > [] ? > > > do_notify_resume+0x3b/0x74 > > > > > > > [] ? > > int_signal+0x12/0x17 > > > > > > > Code: 00 00 00 40 74 02 0f 0b 4= 8 > 8d > > 77 70 48 > > > 8d bf 08 > > > > 01 00 > > > > > 00 e8 > > > > > > 8b 71 10 > > > > > > > 00 85 c0 0f 84 5d 01 00 00 48 8= b > 6b > > 18 f6 83 > > > 80 00 00 > > > > 00 08 > > > > > <4c> 8b > > > > > > 65 30 > > > > > > > 74 11 be 68 05 00 00 48 c7 c7 8= e > df > > 4f 81 e8 > > > bb d0 > > > > > > > RIP [] > > iput+0x3e/0x195 > > > > > > > RSP > > > > > > > CR2: 0000000000000030 > > > > > > > ---[ end trace 67cc1654658fedcc > ]--- > > > > > > > Fixing recursive fault but > reboot is > > needed! > > > > > > > > > > > > > > I also tested Xen 4.2.0 and > problem > > is the > > > same. So > > > > is this > > > > > a Xen > > > > > > bug or a > > > > > > > kernel bug? I am running vanill= a > > > > [1][2][3][4][5][11]kernel.org kernel > > > > > 3.5.0 and > > > > > > my > > > > > > > hardware is Intel Core i7-3770 > CPU > > and Intel > > > DQ77MK > > > > > motherboard > > > > > > with > > > > > > > latest bios. > > > > > > > > > > > > > > Best regards, > > > > > > > Valtteri Kiviniemi > > > > > > > > > > > > > > References > > > > > > > > > > > > > > Visible links > > > > > > > 1. [3][4][5][6][12] > http://kernel.org/ > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Xen-devel mailing list > > > > > > > [4][5][6][7][13] > Xen-devel@lists.xen.org > > > > > > > > > [5][6][7][8][14]http://lists.xen.org/xen-devel > > > > > > > > > > > > References > > > > > > > > > > > > Visible links > > > > > > 1. mailto:[7][8][9][15]pasik@iki.fi > > > > > > 2. [8][9][10][16]http://kernel.org/ > > > > > > 3. [9][10][11][17]http://kernel.org/ > > > > > > 4. > > mailto:[10][11][12][18]Xen-devel@lists.xen.org > > > > > > 5. > > [11][12][13][19]http://lists.xen.org/xen-devel > > > > > > > > > > References > > > > > > > > > > Visible links > > > > > 1. mailto:[13][14][20]pasik@iki.fi > > > > > 2. mailto:[14][15][21]pasik@iki.fi > > > > > 3. [15][16][22]http://kernel.org/ > > > > > 4. [16][17][23]http://kernel.org/ > > > > > 5. mailto:[17][18][24]Xen-devel@lists.xen.org > > > > > 6. [18][19][25]http://lists.xen.org/xen-devel > > > > > 7. mailto:[19][20][26]pasik@iki.fi > > > > > 8. [20][21][27]http://kernel.org/ > > > > > 9. [21][22][28]http://kernel.org/ > > > > > 10. mailto:[22][23][29]Xen-devel@lists.xen.org > > > > > 11. [23][24][30]http://lists.xen.org/xen-devel > > > > > > > > References > > > > > > > > Visible links > > > > 1. mailto:[25][31]pasik@iki.fi > > > > 2. mailto:[26][32]pasik@iki.fi > > > > 3. mailto:[27][33]pasik@iki.fi > > > > 4. [28][34]http://kernel.org/ > > > > 5. [29][35]http://kernel.org/ > > > > 6. mailto:[30][36]Xen-devel@lists.xen.org > > > > 7. [31][37]http://lists.xen.org/xen-devel > > > > 8. mailto:[32][38]pasik@iki.fi > > > > 9. [33][39]http://kernel.org/ > > > > 10. [34][40]http://kernel.org/ > > > > 11. mailto:[35][41]Xen-devel@lists.xen.org > > > > 12. [36][42]http://lists.xen.org/xen-devel > > > > 13. mailto:[37][43]pasik@iki.fi > > > > 14. mailto:[38][44]pasik@iki.fi > > > > 15. [39][45]http://kernel.org/ > > > > 16. [40][46]http://kernel.org/ > > > > 17. mailto:[41][47]Xen-devel@lists.xen.org > > > > 18. [42][48]http://lists.xen.org/xen-devel > > > > 19. mailto:[43][49]pasik@iki.fi > > > > 20. [44][50]http://kernel.org/ > > > > 21. [45][51]http://kernel.org/ > > > > 22. mailto:[46][52]Xen-devel@lists.xen.org > > > > 23. [47][53]http://lists.xen.org/xen-devel > > > > > > References > > > > > > Visible links > > > 1. mailto:[54]pasik@iki.fi > > > 2. mailto:[55]pasik@iki.fi > > > 3. mailto:[56]pasik@iki.fi > > > 4. mailto:[57]pasik@iki.fi > > > 5. [58]http://kernel.org/ > > > 6. [59]http://kernel.org/ > > > 7. mailto:[60]Xen-devel@lists.xen.org > > > 8. [61]http://lists.xen.org/xen-devel > > > 9. mailto:[62]pasik@iki.fi > > > 10. [63]http://kernel.org/ > > > 11. [64]http://kernel.org/ > > > 12. mailto:[65]Xen-devel@lists.xen.org > > > 13. [66]http://lists.xen.org/xen-devel > > > 14. mailto:[67]pasik@iki.fi > > > 15. mailto:[68]pasik@iki.fi > > > 16. [69]http://kernel.org/ > > > 17. [70]http://kernel.org/ > > > 18. mailto:[71]Xen-devel@lists.xen.org > > > 19. [72]http://lists.xen.org/xen-devel > > > 20. mailto:[73]pasik@iki.fi > > > 21. [74]http://kernel.org/ > > > 22. [75]http://kernel.org/ > > > 23. mailto:[76]Xen-devel@lists.xen.org > > > 24. [77]http://lists.xen.org/xen-devel > > > 25. mailto:[78]pasik@iki.fi > > > 26. mailto:[79]pasik@iki.fi > > > 27. mailto:[80]pasik@iki.fi > > > 28. [81]http://kernel.org/ > > > 29. [82]http://kernel.org/ > > > 30. mailto:[83]Xen-devel@lists.xen.org > > > 31. [84]http://lists.xen.org/xen-devel > > > 32. mailto:[85]pasik@iki.fi > > > 33. [86]http://kernel.org/ > > > 34. [87]http://kernel.org/ > > > 35. mailto:[88]Xen-devel@lists.xen.org > > > 36. [89]http://lists.xen.org/xen-devel > > > 37. mailto:[90]pasik@iki.fi > > > 38. mailto:[91]pasik@iki.fi > > > 39. [92]http://kernel.org/ > > > 40. [93]http://kernel.org/ > > > 41. mailto:[94]Xen-devel@lists.xen.org > > > 42. [95]http://lists.xen.org/xen-devel > > > 43. mailto:[96]pasik@iki.fi > > > 44. [97]http://kernel.org/ > > > 45. [98]http://kernel.org/ > > > 46. mailto:[99]Xen-devel@lists.xen.org > > > 47. [100]http://lists.xen.org/xen-devel > > > > References > > > > Visible links > > 1. mailto:kiviniemi.valtteri@gmail.com > > 2. http://ark.intel.com/products/65719/ > > 3. > http://www.intel.com/content/www/us/en/motherboards/desktop-motherboards/= desktop-board-dq77mk.html > > 4. mailto:root@dataproof.fi > > 5. mailto:pasik@iki.fi > > 6. http://xen.org/ > > 7. mailto:pasik@iki.fi > > 8. mailto:pasik@iki.fi > > 9. mailto:pasik@iki.fi > > 10. mailto:pasik@iki.fi > > 11. http://kernel.org/ > > 12. http://kernel.org/ > > 13. mailto:Xen-devel@lists.xen.org > > 14. http://lists.xen.org/xen-devel > > 15. mailto:pasik@iki.fi > > 16. http://kernel.org/ > > 17. http://kernel.org/ > > 18. mailto:Xen-devel@lists.xen.org > > 19. http://lists.xen.org/xen-devel > > 20. mailto:pasik@iki.fi > > 21. mailto:pasik@iki.fi > > 22. http://kernel.org/ > > 23. http://kernel.org/ > > 24. mailto:Xen-devel@lists.xen.org > > 25. http://lists.xen.org/xen-devel > > 26. mailto:pasik@iki.fi > > 27. http://kernel.org/ > > 28. http://kernel.org/ > > 29. mailto:Xen-devel@lists.xen.org > > 30. http://lists.xen.org/xen-devel > > 31. mailto:pasik@iki.fi > > 32. mailto:pasik@iki.fi > > 33. mailto:pasik@iki.fi > > 34. http://kernel.org/ > > 35. http://kernel.org/ > > 36. mailto:Xen-devel@lists.xen.org > > 37. http://lists.xen.org/xen-devel > > 38. mailto:pasik@iki.fi > > 39. http://kernel.org/ > > 40. http://kernel.org/ > > 41. mailto:Xen-devel@lists.xen.org > > 42. http://lists.xen.org/xen-devel > > 43. mailto:pasik@iki.fi > > 44. mailto:pasik@iki.fi > > 45. http://kernel.org/ > > 46. http://kernel.org/ > > 47. mailto:Xen-devel@lists.xen.org > > 48. http://lists.xen.org/xen-devel > > 49. mailto:pasik@iki.fi > > 50. http://kernel.org/ > > 51. http://kernel.org/ > > 52. mailto:Xen-devel@lists.xen.org > > 53. http://lists.xen.org/xen-devel > > 54. mailto:pasik@iki.fi > > 55. mailto:pasik@iki.fi > > 56. mailto:pasik@iki.fi > > 57. mailto:pasik@iki.fi > > 58. http://kernel.org/ > > 59. http://kernel.org/ > > 60. mailto:Xen-devel@lists.xen.org > > 61. http://lists.xen.org/xen-devel > > 62. mailto:pasik@iki.fi > > 63. http://kernel.org/ > > 64. http://kernel.org/ > > 65. mailto:Xen-devel@lists.xen.org > > 66. http://lists.xen.org/xen-devel > > 67. mailto:pasik@iki.fi > > 68. mailto:pasik@iki.fi > > 69. http://kernel.org/ > > 70. http://kernel.org/ > > 71. mailto:Xen-devel@lists.xen.org > > 72. http://lists.xen.org/xen-devel > > 73. mailto:pasik@iki.fi > > 74. http://kernel.org/ > > 75. http://kernel.org/ > > 76. mailto:Xen-devel@lists.xen.org > > 77. http://lists.xen.org/xen-devel > > 78. mailto:pasik@iki.fi > > 79. mailto:pasik@iki.fi > > 80. mailto:pasik@iki.fi > > 81. http://kernel.org/ > > 82. http://kernel.org/ > > 83. mailto:Xen-devel@lists.xen.org > > 84. http://lists.xen.org/xen-devel > > 85. mailto:pasik@iki.fi > > 86. http://kernel.org/ > > 87. http://kernel.org/ > > 88. mailto:Xen-devel@lists.xen.org > > 89. http://lists.xen.org/xen-devel > > 90. mailto:pasik@iki.fi > > 91. mailto:pasik@iki.fi > > 92. http://kernel.org/ > > 93. http://kernel.org/ > > 94. mailto:Xen-devel@lists.xen.org > > 95. http://lists.xen.org/xen-devel > > 96. mailto:pasik@iki.fi > > 97. http://kernel.org/ > > 98. http://kernel.org/ > > 99. mailto:Xen-devel@lists.xen.org > > 100. http://lists.xen.org/xen-devel > --001636ef09ad5a601804cb131d45 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I already tried 3.2, 3.5, 3.5.0, 3.6.0-rc7 and 3.6.0, same probl= em all of those. My dom0 config is the same config that I'am using on o= ther server where HVM is working, so I dont think that it is a config probl= em. I have triple checked everything and all should be ok. dom0 dmesg shows= the same crash that I have previously posted here. /var/log/xen/ does not = contain any specific errors.

Could this be some kind of broblem with my motherboard bios being buggy= or CPU not supported? I'm using the new intel Ivy Bridge processor whi= ch has integrated GPU, but that should not probably cause these kind of pro= blems. Or maybe some ACPI problem? xm dmesg is showing some notices about A= CPI. Is there any ACPI kernel parameters that I should try booting? This ha= s to be somekind of problem with my hardware, or then maybe it could be a k= ernel problem too. I just really cant figure this out myself, I have tried = everything.

Lets take a quick summary of what has been tested, what hardware I'= m using etc.

Xen-versions tested: 4.2.0, 4.0.4
Kernel-versions te= sted: 3.2.0, 3.5.0, 3.5.4, 3.6.0-rc7, 3.6.0

Host OS: Debian testing/= wheezy, udev version 175-7, 2.13-35, python version 2.7.3~rc2-2.1

Hardware:

CPU: Intel Core i7-3770 3.4GHz
MB: Intel DQ77MK (l= atest bios updated)
Memory: 32GB (4 x 8GB DDR3-1600MHz)

All relev= ant log files and configs:

dom0 dmesg: http://nago.fi/dmesg.txt
qemu-dm log: http://nago.fi/qemu-dm.= txt
xm dmesg log: http://nag= o.fi/xm-dmesg.txt
domU config: http://nago.fi/domu-config.txt
dom0 kernel config: http://nago.= fi/dom0-config.txt

I have also tried playing with every setting = on that domU that I can think of and tried different configs etc.

- Valtteri

2012/10/2 Pasi K=E4rkk=E4inen = <pas= ik@iki.fi>
On Tue, Oct 02, 2012 at 03:11:07PM +0300, Valtteri Kivini= emi wrote:
> =A0 =A0Hi,
>
> =A0 =A0Another update:
>
> =A0 =A0I wanted to check that if a Linux HVM would boot with working V= NC console,
> =A0 =A0so I tried to launch a Debian Squeeze installer on HVM. It refu= sed to
> =A0 =A0start ant told me that vbd hotplug scripts were not working. Af= ter that
> =A0 =A0failure even the Windows domU would not anymore start which was= previously
> =A0 =A0starting ok.
>
> =A0 =A0The hotplug scripts also starts hanging on the processes.
>
> =A0 =A0root =A0 =A0 =A09401 =A00.1 =A00.1 =A017700 =A01640 ? =A0 =A0 = =A0 =A0S =A0 =A015:05 =A0 0:00 /bin/bash
> =A0 =A0/etc/xen/scripts/xen-hotplug-cleanup
> =A0 =A0root =A0 =A0 =A09441 =A00.1 =A00.1 =A017700 =A01644 ? =A0 =A0 = =A0 =A0S =A0 =A015:05 =A0 0:00 /bin/bash
> =A0 =A0/etc/xen/scripts/xen-hotplug-cleanup
> =A0 =A0root =A0 =A0 =A09481 =A00.1 =A00.1 =A017700 =A01640 ? =A0 =A0 = =A0 =A0S =A0 =A015:05 =A0 0:00 /bin/bash
> =A0 =A0/etc/xen/scripts/xen-hotplug-cleanup
> =A0 =A0root =A0 =A0 =A09560 =A00.1 =A00.1 =A017700 =A01640 ? =A0 =A0 = =A0 =A0S =A0 =A015:05 =A0 0:00 /bin/bash
> =A0 =A0/etc/xen/scripts/xen-hotplug-cleanup
> =A0 =A0root =A0 =A0 10738 =A00.1 =A00.1 =A017696 =A01636 ? =A0 =A0 =A0= =A0S =A0 =A015:05 =A0 0:00 /bin/bash
> =A0 =A0/etc/xen/scripts/xen-hotplug-cleanup
> =A0 =A0root =A0 =A0 10747 =A00.1 =A00.1 =A017792 =A01736 ? =A0 =A0 =A0= =A0S =A0 =A015:05 =A0 0:00 /bin/bash
> =A0 =A0/etc/xen/scripts/block remove
> =A0 =A0root =A0 =A0 11286 =A00.0 =A00.0 =A0 4080 =A0 324 ? =A0 =A0 =A0= =A0S =A0 =A015:06 =A0 0:00 sleep 1
> =A0 =A0root =A0 =A0 11290 =A00.0 =A00.0 =A0 4080 =A0 324 ? =A0 =A0 =A0= =A0S =A0 =A015:06 =A0 0:00 sleep 1
> =A0 =A0root =A0 =A0 11294 =A00.0 =A00.0 =A0 4080 =A0 324 ? =A0 =A0 =A0= =A0S =A0 =A015:06 =A0 0:00 sleep 1
> =A0 =A0root =A0 =A0 11298 =A00.0 =A00.0 =A0 4080 =A0 324 ? =A0 =A0 =A0= =A0S =A0 =A015:06 =A0 0:00 sleep 1
> =A0 =A0root =A0 =A0 11302 =A00.0 =A00.0 =A0 4080 =A0 320 ? =A0 =A0 =A0= =A0S =A0 =A015:06 =A0 0:00 sleep 1
> =A0 =A0root =A0 =A0 11306 =A00.0 =A00.0 =A0 4080 =A0 320 ? =A0 =A0 =A0= =A0S =A0 =A015:06 =A0 0:00 sleep 1
>
> =A0 =A0Then I did a xm destroy and I had again the kernel BUG on dmesg= . So it
> =A0 =A0seems that the problem is not fixed by using 3.6.0. Udev versio= n is 175-7.
>

So you have definitely something broken in your system,
probably in your dom0 kernel. Try with Linux 3.5.4 or 3.4.x,
and see how that goes.

Any errors in dom0 dmesg? How about in /var/log/xen/* ?

-- Pasi

>
>
> =A0 =A02012/10/1 Valtteri Kiviniemi <[1]kiviniemi.valtteri@gmail.com>
>
> =A0 =A0 =A0Hi,
>
> =A0 =A0 =A0CPU: Intel Core i7-3770 3.4GHz
> =A0 =A0 =A0[2]http://ark.intel.com/products/65719/
>
> =A0 =A0 =A0MB: Intel DQ77MK (latest bios updated)
> =A0 =A0 =A0[3]http://www.intel.com/content/www/us/en/motherboards/desktop-motherboard= s/desktop-board-dq77mk.html
>
> =A0 =A0 =A0Memory: 32GB (4 x 8GB DDR3-1600MHz)
>
> =A0 =A0 =A0Host is Debian wheezy/testing, Xen 4.0.4 and latest 3.6.0 k= ernel.
>
> =A0 =A0 =A0Noticed also some errors in xm dmesg:
>
> =A0 =A0 =A0root@xen-2:~# xm dmesg
>
> =A0 =A0 =A0(XEN) Xen version 4.0.4 ([4]root@dataproof.fi) (gcc version 4.7.1
> =A0 =A0 =A0(Debian 4.7.1-7) ) Sun Sep 30 20:28:= 26 EEST 2012
> =A0 =A0 =A0(XEN) Latest ChangeSet: unavailable
> =A0 =A0 =A0(XEN) Bootloader: GNU GRUB 0.97
> =A0 =A0 =A0(XEN) Command line: dom0_mem=3D1280M cpufreq=3Dxen clocksou= rce=3Dhpet
> =A0 =A0 =A0(XEN) Video information:
> =A0 =A0 =A0(XEN) =A0VGA is text mode 80x25, font 8x16
> =A0 =A0 =A0(XEN) =A0VBE/DDC methods: none; EDID transfer time: 0 secon= ds
> =A0 =A0 =A0(XEN) =A0EDID info not retrieved because no DDC retrieval m= ethod detected
> =A0 =A0 =A0(XEN) Disc information:
> =A0 =A0 =A0(XEN) =A0Found 4 MBR signatures
> =A0 =A0 =A0(XEN) =A0Found 4 EDD information structures
> =A0 =A0 =A0(XEN) Xen-e820 RAM map:
> =A0 =A0 =A0(XEN) =A00000000000000000 - 000000000009d800 (usable)
> =A0 =A0 =A0(XEN) =A0000000000009d800 - 00000000000a0000 (reserved)
> =A0 =A0 =A0(XEN) =A000000000000e0000 - 0000000000100000 (reserved)
> =A0 =A0 =A0(XEN) =A00000000000100000 - 0000000020000000 (usable)
> =A0 =A0 =A0(XEN) =A00000000020000000 - 0000000020200000 (reserved)
> =A0 =A0 =A0(XEN) =A00000000020200000 - 0000000040004000 (usable)
> =A0 =A0 =A0(XEN) =A00000000040004000 - 0000000040005000 (reserved)
> =A0 =A0 =A0(XEN) =A00000000040005000 - 00000000dbe44000 (usable)
> =A0 =A0 =A0(XEN) =A000000000dbe44000 - 00000000dc2d7000 (reserved)
> =A0 =A0 =A0(XEN) =A000000000dc2d7000 - 00000000dc2e7000 (ACPI data) > =A0 =A0 =A0(XEN) =A000000000dc2e7000 - 00000000dc40c000 (ACPI NVS)
> =A0 =A0 =A0(XEN) =A000000000dc40c000 - 00000000dc6af000 (reserved)
> =A0 =A0 =A0(XEN) =A000000000dc6af000 - 00000000dc6b0000 (usable)
> =A0 =A0 =A0(XEN) =A000000000dc6b0000 - 00000000dc6f3000 (ACPI NVS)
> =A0 =A0 =A0(XEN) =A000000000dc6f3000 - 00000000dd000000 (usable)
> =A0 =A0 =A0(XEN) =A000000000dd800000 - 00000000dfa00000 (reserved)
> =A0 =A0 =A0(XEN) =A000000000f8000000 - 00000000fc000000 (reserved)
> =A0 =A0 =A0(XEN) =A000000000fec00000 - 00000000fec01000 (reserved)
> =A0 =A0 =A0(XEN) =A000000000fed00000 - 00000000fed04000 (reserved)
> =A0 =A0 =A0(XEN) =A000000000fed1c000 - 00000000fed20000 (reserved)
> =A0 =A0 =A0(XEN) =A000000000fee00000 - 00000000fee01000 (reserved)
> =A0 =A0 =A0(XEN) =A000000000ff000000 - 0000000100000000 (reserved)
> =A0 =A0 =A0(XEN) =A00000000100000000 - 000000081e600000 (usable)
> =A0 =A0 =A0(XEN) ACPI: RSDP 000F0490, 0024 (r2 =A0INTEL)
> =A0 =A0 =A0(XEN) ACPI: XSDT DC2DB080, 007C (r1 INTEL =A0DQ77MK =A0 =A0= =A0 =A0 32 AMI
> =A0 =A0 =A010013)
> =A0 =A0 =A0(XEN) ACPI: FACP DC2E51F0, 010C (r5 INTEL =A0DQ77MK =A0 =A0= =A0 =A0 32 AMI
> =A0 =A0 =A010013)
> =A0 =A0 =A0(XEN) ACPI Warning (tbfadt-0232): FADT (revision 5) is long= er than ACPI
> =A0 =A0 =A02.0 version, truncating length 0x10C to 0xF4 [20070126]
> =A0 =A0 =A0(XEN) ACPI: DSDT DC2DB188, A061 (r2 INTEL =A0DQ77MK =A0 =A0= =A0 =A0 32 INTL
> =A0 =A0 =A020051117)
> =A0 =A0 =A0(XEN) ACPI: FACS DC40A080, 0040
> =A0 =A0 =A0(XEN) ACPI: APIC DC2E5300, 0092 (r3 INTEL =A0DQ77MK =A0 =A0= =A0 =A0 32 AMI
> =A0 =A0 =A010013)
> =A0 =A0 =A0(XEN) ACPI: FPDT DC2E5398, 0044 (r1 INTEL =A0DQ77MK =A0 =A0= =A0 =A0 32 AMI
> =A0 =A0 =A010013)
> =A0 =A0 =A0(XEN) ACPI: TCPA DC2E53E0, 0032 (r2 INTEL =A0DQ77MK =A0 =A0= =A0 =A0 32 MSFT
> =A0 =A0 =A01000013)
> =A0 =A0 =A0(XEN) ACPI: MCFG DC2E5418, 003C (r1 INTEL =A0DQ77MK =A0 =A0= =A0 =A0 32 MSFT
> =A0 =A0 =A097)
> =A0 =A0 =A0(XEN) ACPI: HPET DC2E5458, 0038 (r1 INTEL =A0DQ77MK =A0 =A0= =A0 =A0 32 AMI.
> =A0 =A0 =A05)
> =A0 =A0 =A0(XEN) ACPI: SSDT DC2E5490, 036D (r1 INTEL =A0DQ77MK =A0 =A0= =A0 =A0 32 INTL
> =A0 =A0 =A020091112)
> =A0 =A0 =A0(XEN) ACPI: SSDT DC2E5800, 09AA (r1 INTEL =A0DQ77MK =A0 =A0= =A0 =A0 32 INTL
> =A0 =A0 =A020051117)
> =A0 =A0 =A0(XEN) ACPI: SSDT DC2E61B0, 0A92 (r1 INTEL =A0DQ77MK =A0 =A0= =A0 =A0 32 INTL
> =A0 =A0 =A020051117)
> =A0 =A0 =A0(XEN) ACPI: DMAR DC2E6C48, 00B8 (r1 INTEL =A0DQ77MK =A0 =A0= =A0 =A0 32 INTL
> =A0 =A0 =A01)
> =A0 =A0 =A0(XEN) ACPI: ASF! DC2E6D00, 00A5 (r32 INTEL =A0DQ77MK =A0 = =A0 =A0 =A0 32 TFSM
> =A0 =A0 =A0F4240)
> =A0 =A0 =A0(XEN) System RAM: 32682MB (33467320kB)
> =A0 =A0 =A0(XEN) Domain heap initialised
> =A0 =A0 =A0(XEN) ACPI: 32/64X FACS address mismatch in FADT -
> =A0 =A0 =A0dc40a080/0000000000000000, using 32
> =A0 =A0 =A0(XEN) Processor #0 7:10 APIC version 21
> =A0 =A0 =A0(XEN) Processor #2 7:10 APIC version 21
> =A0 =A0 =A0(XEN) Processor #4 7:10 APIC version 21
> =A0 =A0 =A0(XEN) Processor #6 7:10 APIC version 21
> =A0 =A0 =A0(XEN) Processor #1 7:10 APIC version 21
> =A0 =A0 =A0(XEN) Processor #3 7:10 APIC version 21
> =A0 =A0 =A0(XEN) Processor #5 7:10 APIC version 21
> =A0 =A0 =A0(XEN) Processor #7 7:10 APIC version 21
> =A0 =A0 =A0(XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000,= GSI 0-23
> =A0 =A0 =A0(XEN) Enabling APIC mode: =A0Flat. =A0Using 1 I/O APICs
> =A0 =A0 =A0(XEN) Switched to APIC driver x2apic_cluster.
> =A0 =A0 =A0(XEN) x2APIC mode enabled.
> =A0 =A0 =A0(XEN) Using scheduler: SMP Credit Scheduler (credit)
> =A0 =A0 =A0(XEN) Detected 3392.369 MHz processor.
> =A0 =A0 =A0(XEN) Initing memory sharing.
> =A0 =A0 =A0(XEN) VMX: Supported advanced features:
> =A0 =A0 =A0(XEN) =A0- APIC MMIO access virtualisation
> =A0 =A0 =A0(XEN) =A0- APIC TPR shadow
> =A0 =A0 =A0(XEN) =A0- Extended Page Tables (EPT)
> =A0 =A0 =A0(XEN) =A0- Virtual-Processor Identifiers (VPID)
> =A0 =A0 =A0(XEN) =A0- Virtual NMI
> =A0 =A0 =A0(XEN) =A0- MSR direct-access bitmap
> =A0 =A0 =A0(XEN) =A0- Unrestricted Guest
> =A0 =A0 =A0(XEN) EPT supports 2MB super page.
> =A0 =A0 =A0(XEN) HVM: ASIDs enabled.
> =A0 =A0 =A0(XEN) HVM: VMX enabled
> =A0 =A0 =A0(XEN) HVM: Hardware Assisted Paging detected.
> =A0 =A0 =A0(XEN) Intel VT-d Snoop Control not enabled.
> =A0 =A0 =A0(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
> =A0 =A0 =A0(XEN) Intel VT-d Queued Invalidation enabled.
> =A0 =A0 =A0(XEN) Intel VT-d Interrupt Remapping enabled.
> =A0 =A0 =A0(XEN) I/O virtualisation enabled
> =A0 =A0 =A0(XEN) =A0- Dom0 mode: Relaxed
> =A0 =A0 =A0(XEN) Enabled directed EOI with ioapic_ack_old on!
> =A0 =A0 =A0(XEN) Total of 8 processors activated.
> =A0 =A0 =A0(XEN) ENABLING IO-APIC IRQs
> =A0 =A0 =A0(XEN) =A0-> Using old ACK method
> =A0 =A0 =A0(XEN) TSC is reliable, synchronization unnecessary
> =A0 =A0 =A0(XEN) Platform timer appears to have unexpectedly wrapped 1= times.
> =A0 =A0 =A0(XEN) Platform timer is 14.318MHz HPET
> =A0 =A0 =A0(XEN) Allocated console ring of 16 KiB.
> =A0 =A0 =A0(XEN) Brought up 8 CPUs
> =A0 =A0 =A0(XEN) *** LOADING DOMAIN 0 ***
> =A0 =A0 =A0(XEN) =A0Xen =A0kernel: 64-bit, lsb, compat32
> =A0 =A0 =A0(XEN) =A0Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -&g= t; 0x1ae7000
> =A0 =A0 =A0(XEN) PHYSICAL MEMORY ARRANGEMENT:
> =A0 =A0 =A0(XEN) =A0Dom0 alloc.: =A0 0000000804000000->000000080600= 0000 (319488 pages
> =A0 =A0 =A0to be allocated)
> =A0 =A0 =A0(XEN) VIRTUAL MEMORY ARRANGEMENT:
> =A0 =A0 =A0(XEN) =A0Loaded kernel: ffffffff81000000->ffffffff81ae70= 00
> =A0 =A0 =A0(XEN) =A0Init. ramdisk: ffffffff81ae7000->ffffffff81ae70= 00
> =A0 =A0 =A0(XEN) =A0Phys-Mach map: ffffffff81ae7000->ffffffff81d670= 00
> =A0 =A0 =A0(XEN) =A0Start info: =A0 =A0ffffffff81d67000->ffffffff81= d674b4
> =A0 =A0 =A0(XEN) =A0Page tables: =A0 ffffffff81d68000->ffffffff81d7= b000
> =A0 =A0 =A0(XEN) =A0Boot stack: =A0 =A0ffffffff81d7b000->ffffffff81= d7c000
> =A0 =A0 =A0(XEN) =A0TOTAL: =A0 =A0 =A0 =A0 ffffffff80000000->ffffff= ff82000000
> =A0 =A0 =A0(XEN) =A0ENTRY ADDRESS: ffffffff815e3210
> =A0 =A0 =A0(XEN) Dom0 has maximum 8 VCPUs
> =A0 =A0 =A0(XEN) [VT-D]iommu.c:718: BIOS did not enable IGD for VT pro= perly.
> =A0 =A0 =A0Disabling IGD VT-d engine.
> =A0 =A0 =A0(XEN) Scrubbing Free RAM: done.
> =A0 =A0 =A0(XEN) Xen trace buffers: disabled
> =A0 =A0 =A0(XEN) Std. Loglevel: Errors and warnings
> =A0 =A0 =A0(XEN) Guest Loglevel: Nothing (Rate-limited: Errors and war= nings)
> =A0 =A0 =A0(XEN) Xen is relinquishing VGA console.
> =A0 =A0 =A0(XEN) *** Serial input -> DOM0 (type 'CTRL-a' th= ree times to switch
> =A0 =A0 =A0input to Xen)
> =A0 =A0 =A0(XEN) Freed 172kB init memory.
> =A0 =A0 =A0(XEN) traps.c:2333:d0 Domain attempted WRMSR 00000000000000= 8b from
> =A0 =A0 =A000000012:00000000 to 00000000:00000000.
>
> =A0 =A0 =A0- Valtteri
>
> =A0 =A0 =A02012/10/1 Pasi K=E4rkk=E4inen <[5]pasik@iki.fi>
>
> =A0 =A0 =A0 =A0On Mon, Oct 01, 2012 at 09:12:50PM +0300, Valtteri Kivi= niemi wrote:
> =A0 =A0 =A0 =A0> =A0 =A0Hi,
> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0Lowering memory or vcpu's does not help= , problem is the same. I
> =A0 =A0 =A0 =A0originally
> =A0 =A0 =A0 =A0> =A0 =A0installed Xen 4.2.0 and the problem was sam= e on that too. Then I
> =A0 =A0 =A0 =A0> =A0 =A0downgraded back to 4.0.4 since I thought th= at this might be a bug
> =A0 =A0 =A0 =A0on
> =A0 =A0 =A0 =A0> =A0 =A04.2.0. I have been previously running Windo= ws Server 2008 R2
> =A0 =A0 =A0 =A0succesfully
> =A0 =A0 =A0 =A0> =A0 =A0on Xen 4.0.x on different hardware with thi= s same config.
> =A0 =A0 =A0 =A0Hypervisor is
> =A0 =A0 =A0 =A0> =A0 =A064bit and windows is 64bit.
> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0Any ideas what to try next?
> =A0 =A0 =A0 =A0>
>
> =A0 =A0 =A0 =A0What kind of hardware is that?
>
> =A0 =A0 =A0 =A0[6]x= en.org automated testing regularly tests Windows VMs, and it works
> =A0 =A0 =A0 =A0OK there.
>
> =A0 =A0 =A0 =A0-- Pasi
> =A0 =A0 =A0 =A0> =A0 =A0Ps. qemu-dm.log is the following:
> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0domid: 10
> =A0 =A0 =A0 =A0> =A0 =A0config qemu network with xen bridge for =A0= tap10.0 xenbr0
> =A0 =A0 =A0 =A0> =A0 =A0Using file /dev/virtuals/ts in read-write m= ode
> =A0 =A0 =A0 =A0> =A0 =A0Using file /media/iso/windows_server_2008_r= 2_sp1.iso in read-only
> =A0 =A0 =A0 =A0mode
> =A0 =A0 =A0 =A0> =A0 =A0Watching /local/domain/0/device-model/10/lo= gdirty/cmd
> =A0 =A0 =A0 =A0> =A0 =A0Watching /local/domain/0/device-model/10/co= mmand
> =A0 =A0 =A0 =A0> =A0 =A0qemu_map_cache_init nr_buckets =3D 10000 si= ze 4194304
> =A0 =A0 =A0 =A0> =A0 =A0shared page at pfn feffd
> =A0 =A0 =A0 =A0> =A0 =A0buffered io page at pfn feffb
> =A0 =A0 =A0 =A0> =A0 =A0Guest uuid =3D 52f19e23-2955-c27d-a22c-60c5= d8c60d5a
> =A0 =A0 =A0 =A0> =A0 =A0Time offset set 0
> =A0 =A0 =A0 =A0> =A0 =A0populating video RAM at ff000000
> =A0 =A0 =A0 =A0> =A0 =A0mapping video RAM from ff000000
> =A0 =A0 =A0 =A0> =A0 =A0Register xen platform.
> =A0 =A0 =A0 =A0> =A0 =A0Done register platform.
> =A0 =A0 =A0 =A0> =A0 =A0platform_fixed_ioport: changed ro/rw state = of ROM memory area.
> =A0 =A0 =A0 =A0now is rw
> =A0 =A0 =A0 =A0> =A0 =A0state.
> =A0 =A0 =A0 =A0> =A0 =A0xs_read(/local/domain/0/device-model/10/xen= _extended_power_mgmt):
> =A0 =A0 =A0 =A0read
> =A0 =A0 =A0 =A0> =A0 =A0error
> =A0 =A0 =A0 =A0> =A0 =A0medium change watch on `hdc' (index: 1)= :
> =A0 =A0 =A0 =A0> =A0 =A0/media/iso/windows_server_2008_r2_sp1.iso > =A0 =A0 =A0 =A0> =A0 =A0I/O request not ready: 0, ptr: 0, port: 0, = data: 0, count: 0,
> =A0 =A0 =A0 =A0size: 0
> =A0 =A0 =A0 =A0> =A0 =A0Log-dirty: no command yet.
> =A0 =A0 =A0 =A0> =A0 =A0xs_read(/local/domain/10/log-throttling): r= ead error
> =A0 =A0 =A0 =A0> =A0 =A0qemu: ignoring not-understood drive
> =A0 =A0 =A0 =A0`/local/domain/10/log-throttling'
> =A0 =A0 =A0 =A0> =A0 =A0medium change watch on `/local/domain/10/lo= g-throttling' -
> =A0 =A0 =A0 =A0unknown device,
> =A0 =A0 =A0 =A0> =A0 =A0ignored
> =A0 =A0 =A0 =A0> =A0 =A0cirrus vga map change while on lfb mode
> =A0 =A0 =A0 =A0> =A0 =A0mapping vram to f0000000 - f0400000
> =A0 =A0 =A0 =A0> =A0 =A0platform_fixed_ioport: changed ro/rw state = of ROM memory area.
> =A0 =A0 =A0 =A0now is rw
> =A0 =A0 =A0 =A0> =A0 =A0state.
> =A0 =A0 =A0 =A0> =A0 =A0platform_fixed_ioport: changed ro/rw state = of ROM memory area.
> =A0 =A0 =A0 =A0now is ro
> =A0 =A0 =A0 =A0> =A0 =A0state.
> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A02012/10/1 Pasi K=E4rkk=E4inen &= lt;[1][7]pasik@iki.fi>
> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0On Mon, Oct 01, 2012 at 07:23:44PM +030= 0, Valtteri Kiviniemi
> =A0 =A0 =A0 =A0wrote:
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0Hi,
> =A0 =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0I have tried other config f= iles, but the problem is the
> =A0 =A0 =A0 =A0same. At
> =A0 =A0 =A0 =A0> =A0 =A0 =A0the
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0moment I'm using a conf= ig file from another server where I
> =A0 =A0 =A0 =A0have a
> =A0 =A0 =A0 =A0> =A0 =A0 =A0working
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0Windows Server 2008 R2 inst= allation, so I dont think that
> =A0 =A0 =A0 =A0there is
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0anything wrong with my conf= ig:
> =A0 =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0Did you try with less vcpus, for exampl= e 2 ?
> =A0 =A0 =A0 =A0> =A0 =A0 =A0how about with less memory, say 2 GB ?<= br> > =A0 =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0Did you try with later Xen versions? Is= that a 32bit Xen, or
> =A0 =A0 =A0 =A064bit Xen
> =A0 =A0 =A0 =A0> =A0 =A0 =A0hypervisor?
> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0-- Pasi
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0kernel =3D "/usr/lib/x= en/boot/hvmloader"
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0builder =3D "hvm"=
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0shadow_memory =3D "8&q= uot;
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0memory =3D "4096"=
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0name =3D "ts"
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0vcpus =3D "8"
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0cpus =3D ["0", &q= uot;1", "2", "3", "4", "5", &q= uot;6", "7"]
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0pae =3D "1"
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0acpi =3D "1"
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0apic =3D "1"
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0vfb =3D [ 'type=3Dvnc, = vnclisten=3D10.100.100.50, vncpasswd=3Dxxx'
> =A0 =A0 =A0 =A0]
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0xen_extended_power_mgmt =3D= "0"
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0vif =3D [ "type=3Dioem= u, mac=3D00:16:3e:d7:d7:5d, bridge=3Dxenbr0"
> =A0 =A0 =A0 =A0]
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0disk =3D [ "phy:/dev/v= irtuals/ts,hda,w",
> =A0 =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0 =A0 "file:/media/iso/windows_server_2008_r2_sp1.iso,h= dc:cdrom,r" ]
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0on_poweroff =3D "destr= oy"
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0on_reboot =3D "restart= "
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0on_crash =3D "restart&= quot;
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0viridian =3D "1"<= br> > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0device_model =3D "/usr= /lib/xen/bin/qemu-dm"
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0boot =3D "dc"
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0snapshot =3D "0"<= br> > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0vncconsole =3D "1"= ;
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0sdl =3D "0"
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0opengl =3D "0" > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0vnc =3D "1"
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0nographic =3D "0"=
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0stdvga =3D "0" > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0tsc_mode =3D "1"<= br> > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0monitor =3D "0" > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0localtime =3D "1"=
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0usb =3D "0"
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0keymap =3D "fi" > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0xen_platform_pci =3D "= 1"
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0pci_msitranslate =3D "= 1"
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0pci_power_mgmt =3D "0&= quot;
> =A0 =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A02012/10/1 Pasi = K=E4rkk=E4inen <[1][2][8]pasik@iki.fi>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0On Mon, Oct 01, 2012 at= 06:46:08PM +0300, Valtteri
> =A0 =A0 =A0 =A0Kiviniemi
> =A0 =A0 =A0 =A0> =A0 =A0 =A0wrote:
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0Hi,
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0Yes, I have= viridian=3D1 on my domU config.
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0Try with some known goo= d domU configfile.
> =A0 =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0-- Pasi
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A02012/10/1 P= asi K=E4rkk=E4inen
> =A0 =A0 =A0 =A0<[1][2][3][9]p= asik@iki.fi>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0= >
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0On Mon,= Oct 01, 2012 at 05:06:53PM +0300,
> =A0 =A0 =A0 =A0Valtteri
> =A0 =A0 =A0 =A0> =A0 =A0 =A0Kiviniemi
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0wrote:
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0Hi,
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0I'm now using 3.6.0 and can't reproduce that
> =A0 =A0 =A0 =A0crash
> =A0 =A0 =A0 =A0> =A0 =A0 =A0anymore,
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0so it
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0seems > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0that it was a kernel bug.
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0OK.
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0However I'm still getting black screen on
> =A0 =A0 =A0 =A0VNC
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0when trying to install Windows Server 2008
> =A0 =A0 =A0 =A0R2. I can
> =A0 =A0 =A0 =A0> =A0 =A0 =A0see the
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0"w= indows is
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0loading files" screen but after the
> =A0 =A0 =A0 =A0installer starts
> =A0 =A0 =A0 =A0> =A0 =A0 =A0the VNC
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0display= goes
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0black.
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0Any ideas?
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0Do you = have viridian=3D1 specified for the windows
> =A0 =A0 =A0 =A0vm?
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0-- Pasi=
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0- Valtteri
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A02012/10/1 Pasi K=E4rkk=E4inen
> =A0 =A0 =A0 =A0<[1][2][3][4][10]pasik@iki.fi>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0= > =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0On Sun, Sep 30, 2012 at 11:18:03PM +0300,
> =A0 =A0 =A0 =A0Valtteri
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0Kiviniemi
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0wrote:<= br> > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0Hi,
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0Hello,
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0I'm trying to get Windows Server 2008
> =A0 =A0 =A0 =A0R2
> =A0 =A0 =A0 =A0> =A0 =A0 =A0installation
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0booting= on
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0Xen
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A04.0.4. Using the following config:
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0<snip>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0The domU will start booting just
> =A0 =A0 =A0 =A0fine, but
> =A0 =A0 =A0 =A0> =A0 =A0 =A0after a
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0few
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0minutes= the
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0VNC
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0screen goes black. After that when
> =A0 =A0 =A0 =A0typing "xm
> =A0 =A0 =A0 =A0> =A0 =A0 =A0destroy
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0ts" it
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0will > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0trigger
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0a kernel BUG:
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0BUG: unable to handle kernel NULL
> =A0 =A0 =A0 =A0pointer
> =A0 =A0 =A0 =A0> =A0 =A0 =A0dereference
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0at
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A00000000000000030
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0IP: [<ffffffff810c50c4>]
> =A0 =A0 =A0 =A0iput+0x3e/0x195
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0PGD 0
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0Oops: 0000 [#1] SMP
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0CPU 6
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0Pid: 3571, comm: qemu-dm Not tainted
> =A0 =A0 =A0 =A0> =A0 =A0 =A03.5.0-dom0 #1
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0First of all upgrade to latest 3.5.x Linux
> =A0 =A0 =A0 =A0kernel
> =A0 =A0 =A0 =A0> =A0 =A0 =A0release
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0.. so
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0at leas= t
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A03.5.4.
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0-- Pasi
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0/DQ77MK
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0RIP: e030:[<ffffffff810c50c4>]
> =A0 =A0 =A0 =A0> =A0 =A0 =A0 [<ffffffff810c50c4>]
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0iput+0x3e/0x195
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0RSP: e02b:ffff8800389ffbf8 =A0EFLAGS:
> =A0 =A0 =A0 =A000010246
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0RAX: 0000000000000001 RBX:
> =A0 =A0 =A0 =A0ffff8800377b0720
> =A0 =A0 =A0 =A0> =A0 =A0 =A0RCX:
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0ffff880= 0501c0000
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0RDX: ffff8800501c0000 RSI:
> =A0 =A0 =A0 =A0ffff8800377b0790
> =A0 =A0 =A0 =A0> =A0 =A0 =A0RDI:
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0ffff880= 0377b0790
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0RBP: 0000000000000000 R08:
> =A0 =A0 =A0 =A0ffffffff815cdd00
> =A0 =A0 =A0 =A0> =A0 =A0 =A0R09:
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A00000000= 000000016
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0R10: fefefefefefefeff R11:
> =A0 =A0 =A0 =A0ffff8800377b0400
> =A0 =A0 =A0 =A0> =A0 =A0 =A0R12:
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A00000000= 1000a3e0c
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0R13: 0000000000000000 R14:
> =A0 =A0 =A0 =A000000001000a3e0c
> =A0 =A0 =A0 =A0> =A0 =A0 =A0R15:
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0ffff880= 0389ffc28
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0FS: =A000007f1af70a8700(0000)
> =A0 =A0 =A0 =A0> =A0 =A0 =A0GS:ffff880050180000(0000)
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0knlGS:0000000000000000
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0CS: =A0e033 DS: 0000 ES: 0000 CR0:
> =A0 =A0 =A0 =A0> =A0 =A0 =A0000000008005003b
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0CR2: 0000000000000030 CR3:
> =A0 =A0 =A0 =A0000000000156d000
> =A0 =A0 =A0 =A0> =A0 =A0 =A0CR4:
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A00000000= 000002660
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0DR0: 0000000000000000 DR1:
> =A0 =A0 =A0 =A00000000000000000
> =A0 =A0 =A0 =A0> =A0 =A0 =A0DR2:
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A00000000= 000000000
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0DR3: 0000000000000000 DR6:
> =A0 =A0 =A0 =A000000000ffff0ff0
> =A0 =A0 =A0 =A0> =A0 =A0 =A0DR7:
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A00000000= 000000400
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0Process qemu-dm (pid: 3571,
> =A0 =A0 =A0 =A0threadinfo
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0ffff8800389fe000,
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0task > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0ffff88003a721260)
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0Stack:
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 ffff88003a6d6400 ffff8800377b0000
> =A0 =A0 =A0 =A0> =A0 =A0 =A000000001000a3e0c
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0ffffffff8133ce8f
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 ffff8800377b0400 ffffffff8134b6cd
> =A0 =A0 =A0 =A0> =A0 =A0 =A0ffff8800389ffc28
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0ffff8800389ffc28
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 ffff8800377b00f8 ffff8800377b0680
> =A0 =A0 =A0 =A0> =A0 =A0 =A0ffff880038cdcd60
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0ffff8800377b0000
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0Call Trace:
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 [<ffffffff8133ce8f>] ?
> =A0 =A0 =A0 =A0> =A0 =A0 =A0sk_release_kernel+0x23/0x39
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 [<ffffffff8134b6cd>] ?
> =A0 =A0 =A0 =A0> =A0 =A0 =A0netdev_run_todo+0x1e9/0x206
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 [<ffffffff8129798f>] ?
> =A0 =A0 =A0 =A0> =A0 =A0 =A0tun_chr_close+0x4c/0x7b
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 [<ffffffff810b39d3>] ?
> =A0 =A0 =A0 =A0fput+0xe4/0x1c5
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 [<ffffffff810b202c>] ?
> =A0 =A0 =A0 =A0filp_close+0x61/0x68
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 [<ffffffff81035e62>] ?
> =A0 =A0 =A0 =A0> =A0 =A0 =A0put_files_struct+0x62/0xb9
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 [<ffffffff81036374>] ?
> =A0 =A0 =A0 =A0do_exit+0x24a/0x74c
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 [<ffffffff81036906>] ?
> =A0 =A0 =A0 =A0> =A0 =A0 =A0do_group_exit+0x6b/0x9d
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 [<ffffffff8103ea0b>] ?
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0get_signal_to_deliver+0= x449/0x46e
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 [<ffffffff81009fa5>] ?
> =A0 =A0 =A0 =A0do_signal+0x28/0x4c4
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 [<ffffffff81027079>] ?
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0pvclock_clocksource_rea= d+0x48/0xbf
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 [<ffffffff8105b745>] ?
> =A0 =A0 =A0 =A0ktime_get_ts+0x66/0xa8
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 [<ffffffff810bfb18>] ?
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0poll_select_copy_remain= ing+0xe0/0xf5
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 [<ffffffff8100a48d>] ?
> =A0 =A0 =A0 =A0> =A0 =A0 =A0do_notify_resume+0x3b/0x74
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 [<ffffffff81411a70>] ?
> =A0 =A0 =A0 =A0int_signal+0x12/0x17
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0Code: 00 00 00 40 74 02 0f 0b 48 8d
> =A0 =A0 =A0 =A077 70 48
> =A0 =A0 =A0 =A0> =A0 =A0 =A08d bf 08
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A001 00
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A000 e8 > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A08b 71 10
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A000 85 c0 0f 84 5d 01 00 00 48 8b 6b
> =A0 =A0 =A0 =A018 f6 83
> =A0 =A0 =A0 =A0> =A0 =A0 =A080 00 00
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A000 08
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0<4c&= gt; 8b
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A065 30
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A074 11 be 68 05 00 00 48 c7 c7 8e df
> =A0 =A0 =A0 =A04f 81 e8
> =A0 =A0 =A0 =A0> =A0 =A0 =A0bb d0
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0RIP =A0[<ffffffff810c50c4>]
> =A0 =A0 =A0 =A0iput+0x3e/0x195
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 RSP <ffff8800389ffbf8>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0CR2: 0000000000000030
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0---[ end trace 67cc1654658fedcc ]---
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0Fixing recursive fault but reboot is
> =A0 =A0 =A0 =A0needed!
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0I also tested Xen 4.2.0 and problem
> =A0 =A0 =A0 =A0is the
> =A0 =A0 =A0 =A0> =A0 =A0 =A0same. So
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0is this
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0a Xen > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0bug or a
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0kernel bug? I am running vanilla
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0[1][2][3][4= ][5][11]kernel.org kern= el
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A03.5.0 and
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0my
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0hardware is Intel Core i7-3770 CPU
> =A0 =A0 =A0 =A0and Intel
> =A0 =A0 =A0 =A0> =A0 =A0 =A0DQ77MK
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0motherb= oard
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0with
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0latest bios.
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0Best regards,
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0Valtteri Kiviniemi
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> References
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0Visible links
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0&= gt; =A0 =A0 =A0> =A0 =A01. [3][4][5][6][12]http://kernel.org/
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0>
> =A0 =A0 =A0 =A0_______________________________________________
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> Xen-devel mailing list
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> [4][5][6][7][13]= Xen-devel@lists.xen.org
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0>
> =A0 =A0 =A0 =A0[5][6][7][8][14]http://lists.xen.org/xen-devel
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> Re= ferences
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> > =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0Visible links
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A01. mailto:[7][8][9][15]pasik@iki.fi<= /a>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A02. [8][9][10][16]ht= tp://kernel.org/
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A03. [9][10][11][17]h= ttp://kernel.org/
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A04.
> =A0 =A0 =A0 =A0mailto:[10][11][12][18]Xen-devel@lists.xen.org
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A05.
> =A0 =A0 =A0 =A0[11][12][13][19]http://lists.xen.org/xen-devel
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> References
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0Visible lin= ks
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A01. mailto:[= 13][14][20]pasik@iki.fi
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A02. mailto:[= 14][15][21]pasik@iki.fi
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A03. [15][16]= [22]http://kernel.org/=
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A04. [16][17]= [23]http://kernel.org/=
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A05. mailto:[= 17][18][24]Xen-devel@lists.xen.o= rg
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A06. [18][19]= [25]http://lis= ts.xen.org/xen-devel
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A07. mailto:[= 19][20][26]pasik@iki.fi
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A08. [20][21]= [27]http://kernel.org/=
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A09. [21][22]= [28]http://kernel.org/=
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 10. mailto:[22= ][23][29]Xen-devel@lists.xen.org=
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> =A0 11. [23][24][3= 0]http://lists= .xen.org/xen-devel
> =A0 =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> References
> =A0 =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0Visible links
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A01. mailto:[25][31]pasik@iki.fi
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A02. mailto:[26][32]pasik@iki.fi
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A03. mailto:[27][33]pasik@iki.fi
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A04. [28][34]http://kernel.org/
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A05. [29][35]http://kernel.org/
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A06. mailto:[30][36]Xen-devel@lists.xen.org
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A07. [31][37]http://lists.xen.org/xen-devel=
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A08. mailto:[32][38]pasik@iki.fi
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A09. [33][39]http://kernel.org/
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 10. [34][40]http://kernel.org/
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 11. mailto:[35][41]Xen-devel@lists.xen.org
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 12. [36][42]http://lists.xen.org/xen-devel
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 13. mailto:[37][43]pasik@iki.fi
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 14. mailto:[38][44]pasik@iki.fi
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 15. [39][45]http://kernel.org/
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 16. [40][46]http://kernel.org/
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 17. mailto:[41][47]Xen-devel@lists.xen.org
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 18. [42][48]http://lists.xen.org/xen-devel
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 19. mailto:[43][49]pasik@iki.fi
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 20. [44][50]http://kernel.org/
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 21. [45][51]http://kernel.org/
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 22. mailto:[46][52]Xen-devel@lists.xen.org
> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 23. [47][53]http://lists.xen.org/xen-devel
> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> References
> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> =A0 =A0Visible links
> =A0 =A0 =A0 =A0> =A0 =A01. mailto:[54]pasik@iki.fi
> =A0 =A0 =A0 =A0> =A0 =A02. mailto:[55]pasik@iki.fi
> =A0 =A0 =A0 =A0> =A0 =A03. mailto:[56]pasik@iki.fi
> =A0 =A0 =A0 =A0> =A0 =A04. mailto:[57]pasik@iki.fi
> =A0 =A0 =A0 =A0> =A0 =A05. [58]http://kernel.org/
> =A0 =A0 =A0 =A0> =A0 =A06. [59]http://kernel.org/
> =A0 =A0 =A0 =A0> =A0 =A07. mailto:[60]Xen-devel@lists.xen.org
> =A0 =A0 =A0 =A0> =A0 =A08. [61]http://lists.xen.org/xen-devel
> =A0 =A0 =A0 =A0> =A0 =A09. mailto:[62]pasik@iki.fi
> =A0 =A0 =A0 =A0> =A0 10. [63]http://kernel.org/
> =A0 =A0 =A0 =A0> =A0 11. [64]http://kernel.org/
> =A0 =A0 =A0 =A0> =A0 12. mailto:[65]Xen-devel@lists.xen.org
> =A0 =A0 =A0 =A0> =A0 13. [66]http://lists.xen.org/xen-devel
> =A0 =A0 =A0 =A0> =A0 14. mailto:[67]pasik@iki.fi
> =A0 =A0 =A0 =A0> =A0 15. mailto:[68]pasik@iki.fi
> =A0 =A0 =A0 =A0> =A0 16. [69]http://kernel.org/
> =A0 =A0 =A0 =A0> =A0 17. [70]http://kernel.org/
> =A0 =A0 =A0 =A0> =A0 18. mailto:[71]Xen-devel@lists.xen.org
> =A0 =A0 =A0 =A0> =A0 19. [72]http://lists.xen.org/xen-devel
> =A0 =A0 =A0 =A0> =A0 20. mailto:[73]pasik@iki.fi
> =A0 =A0 =A0 =A0> =A0 21. [74]http://kernel.org/
> =A0 =A0 =A0 =A0> =A0 22. [75]http://kernel.org/
> =A0 =A0 =A0 =A0> =A0 23. mailto:[76]Xen-devel@lists.xen.org
> =A0 =A0 =A0 =A0> =A0 24. [77]http://lists.xen.org/xen-devel
> =A0 =A0 =A0 =A0> =A0 25. mailto:[78]pasik@iki.fi
> =A0 =A0 =A0 =A0> =A0 26. mailto:[79]pasik@iki.fi
> =A0 =A0 =A0 =A0> =A0 27. mailto:[80]pasik@iki.fi
> =A0 =A0 =A0 =A0> =A0 28. [81]http://kernel.org/
> =A0 =A0 =A0 =A0> =A0 29. [82]http://kernel.org/
> =A0 =A0 =A0 =A0> =A0 30. mailto:[83]Xen-devel@lists.xen.org
> =A0 =A0 =A0 =A0> =A0 31. [84]http://lists.xen.org/xen-devel
> =A0 =A0 =A0 =A0> =A0 32. mailto:[85]pasik@iki.fi
> =A0 =A0 =A0 =A0> =A0 33. [86]http://kernel.org/
> =A0 =A0 =A0 =A0> =A0 34. [87]http://kernel.org/
> =A0 =A0 =A0 =A0> =A0 35. mailto:[88]Xen-devel@lists.xen.org
> =A0 =A0 =A0 =A0> =A0 36. [89]http://lists.xen.org/xen-devel
> =A0 =A0 =A0 =A0> =A0 37. mailto:[90]pasik@iki.fi
> =A0 =A0 =A0 =A0> =A0 38. mailto:[91]pasik@iki.fi
> =A0 =A0 =A0 =A0> =A0 39. [92]http://kernel.org/
> =A0 =A0 =A0 =A0> =A0 40. [93]http://kernel.org/
> =A0 =A0 =A0 =A0> =A0 41. mailto:[94]Xen-devel@lists.xen.org
> =A0 =A0 =A0 =A0> =A0 42. [95]http://lists.xen.org/xen-devel
> =A0 =A0 =A0 =A0> =A0 43. mailto:[96]pasik@iki.fi
> =A0 =A0 =A0 =A0> =A0 44. [97]http://kernel.org/
> =A0 =A0 =A0 =A0> =A0 45. [98]http://kernel.org/
> =A0 =A0 =A0 =A0> =A0 46. mailto:[99]Xen-devel@lists.xen.org
> =A0 =A0 =A0 =A0> =A0 47. [100]http://lists.xen.org/xen-devel
>
> References
>
> =A0 =A0Visible links
> =A0 =A01. mailto:kivin= iemi.valtteri@gmail.com
> =A0 =A02. http://ark.intel.com/products/65719/
> =A0 =A03. http:/= /www.intel.com/content/www/us/en/motherboards/desktop-motherboards/desktop-= board-dq77mk.html
> =A0 =A04. mailto:root@dataproof.f= i
> =A0 =A05. mailto:pasik@iki.fi
> =A0 =A06. http://xen.org= /
> =A0 =A07. mailto:pasik@iki.fi
> =A0 =A08. mailto:pasik@iki.fi
> =A0 =A09. mailto:pasik@iki.fi
> =A0 10. mailto:pasik@iki.fi
> =A0 11. http://kernel= .org/
> =A0 12. http://kernel= .org/
> =A0 13. mailto:Xen-devel@li= sts.xen.org
> =A0 14. h= ttp://lists.xen.org/xen-devel
> =A0 15. mailto:pasik= @iki.fi
> =A0 16. http://kernel= .org/
> =A0 17. http://kernel= .org/
> =A0 18. mailto:Xen-devel@li= sts.xen.org
> =A0 19. h= ttp://lists.xen.org/xen-devel
> =A0 20. mailto:pasik@iki.fi
> =A0 21. mailto:pasik@iki.fi<= br> > =A0 22. http://kernel= .org/
> =A0 23. http://kernel= .org/
> =A0 24. mailto:Xen-devel@li= sts.xen.org
> =A0 25. h= ttp://lists.xen.org/xen-devel
> =A0 26. mailto:pasik@iki.fi
> =A0 27. http://kernel= .org/
> =A0 28. http://kernel= .org/
> =A0 29. mailto:Xen-devel@li= sts.xen.org
> =A0 30. h= ttp://lists.xen.org/xen-devel
> =A0 31. mailto:pasik@iki.fi
> =A0 32. mailto:pasik@iki.fi
> =A0 33. mailto:pasik@iki.fi
> =A0 34. http://kernel= .org/
> =A0 35. http://kernel= .org/
> =A0 36. mailto:Xen-devel@li= sts.xen.org
> =A0 37. h= ttp://lists.xen.org/xen-devel
> =A0 38. mailto:pasik= @iki.fi
> =A0 39. http://kernel= .org/
> =A0 40. http://kernel= .org/
> =A0 41. mailto:Xen-devel@li= sts.xen.org
> =A0 42. h= ttp://lists.xen.org/xen-devel
> =A0 43. mailto:pasik@iki.fi
> =A0 44. mailto:pasik@iki.fi<= br> > =A0 45. http://kernel= .org/
> =A0 46. http://kernel= .org/
> =A0 47. mailto:Xen-devel@li= sts.xen.org
> =A0 48. h= ttp://lists.xen.org/xen-devel
> =A0 49. mailto:pasik@iki.fi
> =A0 50. http://kernel= .org/
> =A0 51. http://kernel= .org/
> =A0 52. mailto:Xen-devel@li= sts.xen.org
> =A0 53. h= ttp://lists.xen.org/xen-devel
> =A0 54. mailto:pasik@iki.fi
> =A0 55. mailto:pasik@iki.fi
> =A0 56. mailto:pasik@iki.fi
> =A0 57. mailto:pasik@iki.fi
> =A0 58. http://kernel= .org/
> =A0 59. http://kernel= .org/
> =A0 60. mailto:Xen-devel@li= sts.xen.org
> =A0 61. h= ttp://lists.xen.org/xen-devel
> =A0 62. mailto:pasik@iki.fi
> =A0 63. http://kernel= .org/
> =A0 64. http://kernel= .org/
> =A0 65. mailto:Xen-devel@li= sts.xen.org
> =A0 66. h= ttp://lists.xen.org/xen-devel
> =A0 67. mailto:pasik@iki.fi
> =A0 68. mailto:pasik@iki.fi
> =A0 69. http://kernel= .org/
> =A0 70. http://kernel= .org/
> =A0 71. mailto:Xen-devel@li= sts.xen.org
> =A0 72. h= ttp://lists.xen.org/xen-devel
> =A0 73. mailto:pasik@iki.fi
> =A0 74. http://kernel= .org/
> =A0 75. http://kernel= .org/
> =A0 76. mailto:Xen-devel@li= sts.xen.org
> =A0 77. h= ttp://lists.xen.org/xen-devel
> =A0 78. mailto:pasik@iki.fi
> =A0 79. mailto:pasik@iki.fi
> =A0 80. mailto:pasik@iki.fi
> =A0 81. http://kernel= .org/
> =A0 82. http://kernel= .org/
> =A0 83. mailto:Xen-devel@li= sts.xen.org
> =A0 84. h= ttp://lists.xen.org/xen-devel
> =A0 85. mailto:pasik@iki.fi
> =A0 86. http://kernel= .org/
> =A0 87. http://kernel= .org/
> =A0 88. mailto:Xen-devel@li= sts.xen.org
> =A0 89. h= ttp://lists.xen.org/xen-devel
> =A0 90. mailto:pasik@iki.fi
> =A0 91. mailto:pasik@iki.fi
> =A0 92. http://kernel= .org/
> =A0 93. http://kernel= .org/
> =A0 94. mailto:Xen-devel@li= sts.xen.org
> =A0 95. h= ttp://lists.xen.org/xen-devel
> =A0 96. mailto:pasik@iki.fi
> =A0 97. http://kernel= .org/
> =A0 98. http://kernel= .org/
> =A0 99. mailto:Xen-devel@li= sts.xen.org
> =A0100. h= ttp://lists.xen.org/xen-devel

--001636ef09ad5a601804cb131d45-- --===============0697706113319296394== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============0697706113319296394==-- From xen-devel-bounces@lists.xen.org Tue Oct 02 13:14:48 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 13:14:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ2Im-0001x2-4J; Tue, 02 Oct 2012 13:14:20 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ2Ik-0001wx-0S for Xen-devel@lists.xen.org; Tue, 02 Oct 2012 13:14:18 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-6.tower-27.messagelabs.com!1349183647!7617922!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MjMzMTI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20691 invoked from network); 2 Oct 2012 13:14:08 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 13:14:08 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id 56B182860; Tue, 2 Oct 2012 16:14:07 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 3818120058; Tue, 2 Oct 2012 16:14:07 +0300 (EEST) Date: Tue, 2 Oct 2012 16:14:07 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Valtteri Kiviniemi Message-ID: <20121002131407.GM8912@reaktio.net> References: <20121001160117.GD8912@reaktio.net> <20121001164757.GF8912@reaktio.net> <20121001182437.GG8912@reaktio.net> <20121002121932.GL8912@reaktio.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.0.4, kernel 3.5.0 HVM crash and kernel BUG X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, Oct 02, 2012 at 04:01:04PM +0300, Valtteri Kiviniemi wrote: > Hi, > = > I already tried 3.2, 3.5, 3.5.0, 3.6.0-rc7 and 3.6.0, same problem all= of > those. My dom0 config is the same config that I'am using on other serv= er > where HVM is working, so I dont think that it is a config problem. I h= ave > triple checked everything and all should be ok. dom0 dmesg shows the s= ame > crash that I have previously posted here. /var/log/xen/ does not conta= in > any specific errors. > = > Could this be some kind of broblem with my motherboard bios being bugg= y or > CPU not supported? I'm using the new intel Ivy Bridge processor which = has > integrated GPU, but that should not probably cause these kind of probl= ems. > Or maybe some ACPI problem? xm dmesg is showing some notices about ACP= I. > Is there any ACPI kernel parameters that I should try booting? This ha= s to > be somekind of problem with my hardware, or then maybe it could be a > kernel problem too. I just really cant figure this out myself, I have > tried everything. > = Hmm.. I have some distant memories of seeing a patch that fixes a bug on recent Ivy Bridge systems, but I can't find a link right now. = Maybe you're affected by that.. Also: Did you already post the crash log, with all the debug/verbose option= s enabled for both Xen and dom0 kernel? = -- Pasi > Lets take a quick summary of what has been tested, what hardware I'm u= sing > etc. > = > Xen-versions tested: 4.2.0, 4.0.4 > Kernel-versions tested: 3.2.0, 3.5.0, 3.5.4, 3.6.0-rc7, 3.6.0 > = > Host OS: Debian testing/wheezy, udev version 175-7, 2.13-35, python > version 2.7.3~rc2-2.1 > = > Hardware: > = > CPU: Intel Core i7-3770 3.4GHz > MB: Intel DQ77MK (latest bios updated) > Memory: 32GB (4 x 8GB DDR3-1600MHz) > = > All relevant log files and configs: > = > dom0 dmesg: [1]http://nago.fi/dmesg.txt > qemu-dm log: [2]http://nago.fi/qemu-dm.txt > xm dmesg log: [3]http://nago.fi/xm-dmesg.txt > domU config: [4]http://nago.fi/domu-config.txt > dom0 kernel config: [5]http://nago.fi/dom0-config.txt > = > I have also tried playing with every setting on that domU that I can t= hink > of and tried different configs etc. > = > - Valtteri > = > 2012/10/2 Pasi K=E4rkk=E4inen <[6]pasik@iki.fi> > = > On Tue, Oct 02, 2012 at 03:11:07PM +0300, Valtteri Kiviniemi wrote: > > Hi, > > > > Another update: > > > > I wanted to check that if a Linux HVM would boot with working V= NC > console, > > so I tried to launch a Debian Squeeze installer on HVM. It refu= sed > to > > start ant told me that vbd hotplug scripts were not working. Af= ter > that > > failure even the Windows domU would not anymore start which was > previously > > starting ok. > > > > The hotplug scripts also starts hanging on the processes. > > > > root 9401 0.1 0.1 17700 1640 ? S 15:05 0:00 > /bin/bash > > /etc/xen/scripts/xen-hotplug-cleanup > > root 9441 0.1 0.1 17700 1644 ? S 15:05 0:00 > /bin/bash > > /etc/xen/scripts/xen-hotplug-cleanup > > root 9481 0.1 0.1 17700 1640 ? S 15:05 0:00 > /bin/bash > > /etc/xen/scripts/xen-hotplug-cleanup > > root 9560 0.1 0.1 17700 1640 ? S 15:05 0:00 > /bin/bash > > /etc/xen/scripts/xen-hotplug-cleanup > > root 10738 0.1 0.1 17696 1636 ? S 15:05 0:00 > /bin/bash > > /etc/xen/scripts/xen-hotplug-cleanup > > root 10747 0.1 0.1 17792 1736 ? S 15:05 0:00 > /bin/bash > > /etc/xen/scripts/block remove > > root 11286 0.0 0.0 4080 324 ? S 15:06 0:00 > sleep 1 > > root 11290 0.0 0.0 4080 324 ? S 15:06 0:00 > sleep 1 > > root 11294 0.0 0.0 4080 324 ? S 15:06 0:00 > sleep 1 > > root 11298 0.0 0.0 4080 324 ? S 15:06 0:00 > sleep 1 > > root 11302 0.0 0.0 4080 320 ? S 15:06 0:00 > sleep 1 > > root 11306 0.0 0.0 4080 320 ? S 15:06 0:00 > sleep 1 > > > > Then I did a xm destroy and I had again the kernel BUG on dmesg= . So > it > > seems that the problem is not fixed by using 3.6.0. Udev versio= n is > 175-7. > > > = > So you have definitely something broken in your system, > probably in your dom0 kernel. Try with Linux 3.5.4 or 3.4.x, > and see how that goes. > = > Any errors in dom0 dmesg? How about in /var/log/xen/* ? > = > -- Pasi > = > > > > > > 2012/10/1 Valtteri Kiviniemi <[1][7]kiviniemi.valtteri@gmail.co= m> > > > > Hi, > > > > CPU: Intel Core i7-3770 3.4GHz > > [2][8]http://ark.intel.com/products/65719/ > > > > MB: Intel DQ77MK (latest bios updated) > > > [3][9]http://www.intel.com/content/www/us/en/motherboards/desktop-m= otherboards/desktop-board-dq77mk.html > > > > Memory: 32GB (4 x 8GB DDR3-1600MHz) > > > > Host is Debian wheezy/testing, Xen 4.0.4 and latest 3.6.0 ker= nel. > > > > Noticed also some errors in xm dmesg: > > > > root@xen-2:~# xm dmesg > > > > (XEN) Xen version 4.0.4 ([4][10]root@dataproof.fi) (gcc versi= on > 4.7.1 > > (Debian 4.7.1-7) ) Sun Sep 30 20:28:26 EEST 2012 > > (XEN) Latest ChangeSet: unavailable > > (XEN) Bootloader: GNU GRUB 0.97 > > (XEN) Command line: dom0_mem=3D1280M cpufreq=3Dxen clocksourc= e=3Dhpet > > (XEN) Video information: > > (XEN) VGA is text mode 80x25, font 8x16 > > (XEN) VBE/DDC methods: none; EDID transfer time: 0 seconds > > (XEN) EDID info not retrieved because no DDC retrieval method > detected > > (XEN) Disc information: > > (XEN) Found 4 MBR signatures > > (XEN) Found 4 EDD information structures > > (XEN) Xen-e820 RAM map: > > (XEN) 0000000000000000 - 000000000009d800 (usable) > > (XEN) 000000000009d800 - 00000000000a0000 (reserved) > > (XEN) 00000000000e0000 - 0000000000100000 (reserved) > > (XEN) 0000000000100000 - 0000000020000000 (usable) > > (XEN) 0000000020000000 - 0000000020200000 (reserved) > > (XEN) 0000000020200000 - 0000000040004000 (usable) > > (XEN) 0000000040004000 - 0000000040005000 (reserved) > > (XEN) 0000000040005000 - 00000000dbe44000 (usable) > > (XEN) 00000000dbe44000 - 00000000dc2d7000 (reserved) > > (XEN) 00000000dc2d7000 - 00000000dc2e7000 (ACPI data) > > (XEN) 00000000dc2e7000 - 00000000dc40c000 (ACPI NVS) > > (XEN) 00000000dc40c000 - 00000000dc6af000 (reserved) > > (XEN) 00000000dc6af000 - 00000000dc6b0000 (usable) > > (XEN) 00000000dc6b0000 - 00000000dc6f3000 (ACPI NVS) > > (XEN) 00000000dc6f3000 - 00000000dd000000 (usable) > > (XEN) 00000000dd800000 - 00000000dfa00000 (reserved) > > (XEN) 00000000f8000000 - 00000000fc000000 (reserved) > > (XEN) 00000000fec00000 - 00000000fec01000 (reserved) > > (XEN) 00000000fed00000 - 00000000fed04000 (reserved) > > (XEN) 00000000fed1c000 - 00000000fed20000 (reserved) > > (XEN) 00000000fee00000 - 00000000fee01000 (reserved) > > (XEN) 00000000ff000000 - 0000000100000000 (reserved) > > (XEN) 0000000100000000 - 000000081e600000 (usable) > > (XEN) ACPI: RSDP 000F0490, 0024 (r2 INTEL) > > (XEN) ACPI: XSDT DC2DB080, 007C (r1 INTEL DQ77MK 32 = AMI > > 10013) > > (XEN) ACPI: FACP DC2E51F0, 010C (r5 INTEL DQ77MK 32 = AMI > > 10013) > > (XEN) ACPI Warning (tbfadt-0232): FADT (revision 5) is longer > than ACPI > > 2.0 version, truncating length 0x10C to 0xF4 [20070126] > > (XEN) ACPI: DSDT DC2DB188, A061 (r2 INTEL DQ77MK 32 = INTL > > 20051117) > > (XEN) ACPI: FACS DC40A080, 0040 > > (XEN) ACPI: APIC DC2E5300, 0092 (r3 INTEL DQ77MK 32 = AMI > > 10013) > > (XEN) ACPI: FPDT DC2E5398, 0044 (r1 INTEL DQ77MK 32 = AMI > > 10013) > > (XEN) ACPI: TCPA DC2E53E0, 0032 (r2 INTEL DQ77MK 32 = MSFT > > 1000013) > > (XEN) ACPI: MCFG DC2E5418, 003C (r1 INTEL DQ77MK 32 = MSFT > > 97) > > (XEN) ACPI: HPET DC2E5458, 0038 (r1 INTEL DQ77MK 32 = AMI. > > 5) > > (XEN) ACPI: SSDT DC2E5490, 036D (r1 INTEL DQ77MK 32 = INTL > > 20091112) > > (XEN) ACPI: SSDT DC2E5800, 09AA (r1 INTEL DQ77MK 32 = INTL > > 20051117) > > (XEN) ACPI: SSDT DC2E61B0, 0A92 (r1 INTEL DQ77MK 32 = INTL > > 20051117) > > (XEN) ACPI: DMAR DC2E6C48, 00B8 (r1 INTEL DQ77MK 32 = INTL > > 1) > > (XEN) ACPI: ASF! DC2E6D00, 00A5 (r32 INTEL DQ77MK 32 > TFSM > > F4240) > > (XEN) System RAM: 32682MB (33467320kB) > > (XEN) Domain heap initialised > > (XEN) ACPI: 32/64X FACS address mismatch in FADT - > > dc40a080/0000000000000000, using 32 > > (XEN) Processor #0 7:10 APIC version 21 > > (XEN) Processor #2 7:10 APIC version 21 > > (XEN) Processor #4 7:10 APIC version 21 > > (XEN) Processor #6 7:10 APIC version 21 > > (XEN) Processor #1 7:10 APIC version 21 > > (XEN) Processor #3 7:10 APIC version 21 > > (XEN) Processor #5 7:10 APIC version 21 > > (XEN) Processor #7 7:10 APIC version 21 > > (XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, G= SI > 0-23 > > (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs > > (XEN) Switched to APIC driver x2apic_cluster. > > (XEN) x2APIC mode enabled. > > (XEN) Using scheduler: SMP Credit Scheduler (credit) > > (XEN) Detected 3392.369 MHz processor. > > (XEN) Initing memory sharing. > > (XEN) VMX: Supported advanced features: > > (XEN) - APIC MMIO access virtualisation > > (XEN) - APIC TPR shadow > > (XEN) - Extended Page Tables (EPT) > > (XEN) - Virtual-Processor Identifiers (VPID) > > (XEN) - Virtual NMI > > (XEN) - MSR direct-access bitmap > > (XEN) - Unrestricted Guest > > (XEN) EPT supports 2MB super page. > > (XEN) HVM: ASIDs enabled. > > (XEN) HVM: VMX enabled > > (XEN) HVM: Hardware Assisted Paging detected. > > (XEN) Intel VT-d Snoop Control not enabled. > > (XEN) Intel VT-d Dom0 DMA Passthrough not enabled. > > (XEN) Intel VT-d Queued Invalidation enabled. > > (XEN) Intel VT-d Interrupt Remapping enabled. > > (XEN) I/O virtualisation enabled > > (XEN) - Dom0 mode: Relaxed > > (XEN) Enabled directed EOI with ioapic_ack_old on! > > (XEN) Total of 8 processors activated. > > (XEN) ENABLING IO-APIC IRQs > > (XEN) -> Using old ACK method > > (XEN) TSC is reliable, synchronization unnecessary > > (XEN) Platform timer appears to have unexpectedly wrapped 1 > times. > > (XEN) Platform timer is 14.318MHz HPET > > (XEN) Allocated console ring of 16 KiB. > > (XEN) Brought up 8 CPUs > > (XEN) *** LOADING DOMAIN 0 *** > > (XEN) Xen kernel: 64-bit, lsb, compat32 > > (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> > 0x1ae7000 > > (XEN) PHYSICAL MEMORY ARRANGEMENT: > > (XEN) Dom0 alloc.: 0000000804000000->0000000806000000 (319= 488 > pages > > to be allocated) > > (XEN) VIRTUAL MEMORY ARRANGEMENT: > > (XEN) Loaded kernel: ffffffff81000000->ffffffff81ae7000 > > (XEN) Init. ramdisk: ffffffff81ae7000->ffffffff81ae7000 > > (XEN) Phys-Mach map: ffffffff81ae7000->ffffffff81d67000 > > (XEN) Start info: ffffffff81d67000->ffffffff81d674b4 > > (XEN) Page tables: ffffffff81d68000->ffffffff81d7b000 > > (XEN) Boot stack: ffffffff81d7b000->ffffffff81d7c000 > > (XEN) TOTAL: ffffffff80000000->ffffffff82000000 > > (XEN) ENTRY ADDRESS: ffffffff815e3210 > > (XEN) Dom0 has maximum 8 VCPUs > > (XEN) [VT-D]iommu.c:718: BIOS did not enable IGD for VT prope= rly. > > Disabling IGD VT-d engine. > > (XEN) Scrubbing Free RAM: done. > > (XEN) Xen trace buffers: disabled > > (XEN) Std. Loglevel: Errors and warnings > > (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warni= ngs) > > (XEN) Xen is relinquishing VGA console. > > (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to > switch > > input to Xen) > > (XEN) Freed 172kB init memory. > > (XEN) traps.c:2333:d0 Domain attempted WRMSR 000000000000008b > from > > 00000012:00000000 to 00000000:00000000. > > > > - Valtteri > > > > 2012/10/1 Pasi K=E4rkk=E4inen <[5][11]pasik@iki.fi> > > > > On Mon, Oct 01, 2012 at 09:12:50PM +0300, Valtteri Kiviniemi > wrote: > > > Hi, > > > > > > Lowering memory or vcpu's does not help, problem is the > same. I > > originally > > > installed Xen 4.2.0 and the problem was same on that t= oo. > Then I > > > downgraded back to 4.0.4 since I thought that this mig= ht > be a bug > > on > > > 4.2.0. I have been previously running Windows Server 2= 008 > R2 > > succesfully > > > on Xen 4.0.x on different hardware with this same conf= ig. > > Hypervisor is > > > 64bit and windows is 64bit. > > > > > > Any ideas what to try next? > > > > > > > What kind of hardware is that? > > > > [6][12]xen.org automated testing regularly tests Windows VM= s, > and it works > > OK there. > > > > -- Pasi > > > Ps. qemu-dm.log is the following: > > > > > > domid: 10 > > > config qemu network with xen bridge for tap10.0 xenbr0 > > > Using file /dev/virtuals/ts in read-write mode > > > Using file /media/iso/windows_server_2008_r2_sp1.iso in > read-only > > mode > > > Watching /local/domain/0/device-model/10/logdirty/cmd > > > Watching /local/domain/0/device-model/10/command > > > qemu_map_cache_init nr_buckets =3D 10000 size 4194304 > > > shared page at pfn feffd > > > buffered io page at pfn feffb > > > Guest uuid =3D 52f19e23-2955-c27d-a22c-60c5d8c60d5a > > > Time offset set 0 > > > populating video RAM at ff000000 > > > mapping video RAM from ff000000 > > > Register xen platform. > > > Done register platform. > > > platform_fixed_ioport: changed ro/rw state of ROM memo= ry > area. > > now is rw > > > state. > > > > xs_read(/local/domain/0/device-model/10/xen_extended_power_mgmt): > > read > > > error > > > medium change watch on `hdc' (index: 1): > > > /media/iso/windows_server_2008_r2_sp1.iso > > > I/O request not ready: 0, ptr: 0, port: 0, data: 0, co= unt: > 0, > > size: 0 > > > Log-dirty: no command yet. > > > xs_read(/local/domain/10/log-throttling): read error > > > qemu: ignoring not-understood drive > > `/local/domain/10/log-throttling' > > > medium change watch on `/local/domain/10/log-throttlin= g' - > > unknown device, > > > ignored > > > cirrus vga map change while on lfb mode > > > mapping vram to f0000000 - f0400000 > > > platform_fixed_ioport: changed ro/rw state of ROM memo= ry > area. > > now is rw > > > state. > > > platform_fixed_ioport: changed ro/rw state of ROM memo= ry > area. > > now is ro > > > state. > > > > > > 2012/10/1 Pasi K=E4rkk=E4inen <[1][7][13]pasik@iki.fi> > > > > > > On Mon, Oct 01, 2012 at 07:23:44PM +0300, Valtteri > Kiviniemi > > wrote: > > > > Hi, > > > > > > > > I have tried other config files, but the proble= m is > the > > same. At > > > the > > > > moment I'm using a config file from another ser= ver > where I > > have a > > > working > > > > Windows Server 2008 R2 installation, so I dont > think that > > there is > > > > anything wrong with my config: > > > > > > > > > > Did you try with less vcpus, for example 2 ? > > > how about with less memory, say 2 GB ? > > > > > > Did you try with later Xen versions? Is that a 32bit > Xen, or > > 64bit Xen > > > hypervisor? > > > > > > -- Pasi > > > > kernel =3D "/usr/lib/xen/boot/hvmloader" > > > > builder =3D "hvm" > > > > shadow_memory =3D "8" > > > > memory =3D "4096" > > > > name =3D "ts" > > > > vcpus =3D "8" > > > > cpus =3D ["0", "1", "2", "3", "4", "5", "6", "7= "] > > > > pae =3D "1" > > > > acpi =3D "1" > > > > apic =3D "1" > > > > vfb =3D [ 'type=3Dvnc, vnclisten=3D10.100.100.5= 0, > vncpasswd=3Dxxx' > > ] > > > > xen_extended_power_mgmt =3D "0" > > > > vif =3D [ "type=3Dioemu, mac=3D00:16:3e:d7:d7:5= d, > bridge=3Dxenbr0" > > ] > > > > disk =3D [ "phy:/dev/virtuals/ts,hda,w", > > > > > > "file:/media/iso/windows_server_2008_r2_sp1.iso,hdc:cdrom,= r" ] > > > > on_poweroff =3D "destroy" > > > > on_reboot =3D "restart" > > > > on_crash =3D "restart" > > > > viridian =3D "1" > > > > device_model =3D "/usr/lib/xen/bin/qemu-dm" > > > > boot =3D "dc" > > > > snapshot =3D "0" > > > > vncconsole =3D "1" > > > > sdl =3D "0" > > > > opengl =3D "0" > > > > vnc =3D "1" > > > > nographic =3D "0" > > > > stdvga =3D "0" > > > > tsc_mode =3D "1" > > > > monitor =3D "0" > > > > localtime =3D "1" > > > > usb =3D "0" > > > > keymap =3D "fi" > > > > xen_platform_pci =3D "1" > > > > pci_msitranslate =3D "1" > > > > pci_power_mgmt =3D "0" > > > > > > > > 2012/10/1 Pasi K=E4rkk=E4inen > <[1][2][8][14]pasik@iki.fi> > > > > > > > > On Mon, Oct 01, 2012 at 06:46:08PM +0300, > Valtteri > > Kiviniemi > > > wrote: > > > > > Hi, > > > > > > > > > > Yes, I have viridian=3D1 on my domU conf= ig. > > > > > > > > > > > > > Try with some known good domU configfile. > > > > > > > > -- Pasi > > > > > 2012/10/1 Pasi K=E4rkk=E4inen > > <[1][2][3][9][15]pasik@iki.fi> > > > > > > > > > > On Mon, Oct 01, 2012 at 05:06:53PM +03= 00, > > Valtteri > > > Kiviniemi > > > > wrote: > > > > > > Hi, > > > > > > > > > > > > I'm now using 3.6.0 and can't > reproduce that > > crash > > > anymore, > > > > so it > > > > > seems > > > > > > that it was a kernel bug. > > > > > > > > > > > > > > > > OK. > > > > > > However I'm still getting black > screen on > > VNC > > > > > > when trying to install Windows Se= rver > 2008 > > R2. I can > > > see the > > > > > "windows is > > > > > > loading files" screen but after t= he > > installer starts > > > the VNC > > > > > display goes > > > > > > black. > > > > > > > > > > > > Any ideas? > > > > > > > > > > > > > > > > Do you have viridian=3D1 specified for= the > windows > > vm? > > > > > > > > > > -- Pasi > > > > > > > > > > > - Valtteri > > > > > > > > > > > > 2012/10/1 Pasi K=E4rkk=E4inen > > <[1][2][3][4][10][16]pasik@iki.fi> > > > > > > > > > > > > On Sun, Sep 30, 2012 at 11:18:0= 3PM > +0300, > > Valtteri > > > > Kiviniemi > > > > > wrote: > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > Hello, > > > > > > > I'm trying to get Windows > Server 2008 > > R2 > > > installation > > > > > booting on > > > > > > Xen > > > > > > > 4.0.4. Using the following > config: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The domU will start booting > just > > fine, but > > > after a > > > > few > > > > > minutes the > > > > > > VNC > > > > > > > screen goes black. After t= hat > when > > typing "xm > > > destroy > > > > ts" it > > > > > will > > > > > > trigger > > > > > > > a kernel BUG: > > > > > > > > > > > > > > BUG: unable to handle kern= el > NULL > > pointer > > > dereference > > > > at > > > > > > 0000000000000030 > > > > > > > IP: [] > > iput+0x3e/0x195 > > > > > > > PGD 0 > > > > > > > Oops: 0000 [#1] SMP > > > > > > > CPU 6 > > > > > > > Pid: 3571, comm: qemu-dm N= ot > tainted > > > 3.5.0-dom0 #1 > > > > > > > > > > > > First of all upgrade to latest > 3.5.x Linux > > kernel > > > release > > > > .. so > > > > > at least > > > > > > 3.5.4. > > > > > > > > > > > > -- Pasi > > > > > > > > > > > > > /DQ77MK > > > > > > > RIP: e030:[] > > > [] > > > > > > iput+0x3e/0x195 > > > > > > > RSP: e02b:ffff8800389ffbf8 > EFLAGS: > > 00010246 > > > > > > > RAX: 0000000000000001 RBX: > > ffff8800377b0720 > > > RCX: > > > > > ffff8800501c0000 > > > > > > > RDX: ffff8800501c0000 RSI: > > ffff8800377b0790 > > > RDI: > > > > > ffff8800377b0790 > > > > > > > RBP: 0000000000000000 R08: > > ffffffff815cdd00 > > > R09: > > > > > 0000000000000016 > > > > > > > R10: fefefefefefefeff R11: > > ffff8800377b0400 > > > R12: > > > > > 00000001000a3e0c > > > > > > > R13: 0000000000000000 R14: > > 00000001000a3e0c > > > R15: > > > > > ffff8800389ffc28 > > > > > > > FS: 00007f1af70a8700(0000) > > > GS:ffff880050180000(0000) > > > > > > > knlGS:0000000000000000 > > > > > > > CS: e033 DS: 0000 ES: 0000 > CR0: > > > 000000008005003b > > > > > > > CR2: 0000000000000030 CR3: > > 000000000156d000 > > > CR4: > > > > > 0000000000002660 > > > > > > > DR0: 0000000000000000 DR1: > > 0000000000000000 > > > DR2: > > > > > 0000000000000000 > > > > > > > DR3: 0000000000000000 DR6: > > 00000000ffff0ff0 > > > DR7: > > > > > 0000000000000400 > > > > > > > Process qemu-dm (pid: 3571, > > threadinfo > > > > ffff8800389fe000, > > > > > task > > > > > > > ffff88003a721260) > > > > > > > Stack: > > > > > > > ffff88003a6d6400 > ffff8800377b0000 > > > 00000001000a3e0c > > > > > > ffffffff8133ce8f > > > > > > > ffff8800377b0400 > ffffffff8134b6cd > > > ffff8800389ffc28 > > > > > > ffff8800389ffc28 > > > > > > > ffff8800377b00f8 > ffff8800377b0680 > > > ffff880038cdcd60 > > > > > > ffff8800377b0000 > > > > > > > Call Trace: > > > > > > > [] ? > > > sk_release_kernel+0x23/0x39 > > > > > > > [] ? > > > netdev_run_todo+0x1e9/0x206 > > > > > > > [] ? > > > tun_chr_close+0x4c/0x7b > > > > > > > [] ? > > fput+0xe4/0x1c5 > > > > > > > [] ? > > filp_close+0x61/0x68 > > > > > > > [] ? > > > put_files_struct+0x62/0xb9 > > > > > > > [] ? > > do_exit+0x24a/0x74c > > > > > > > [] ? > > > do_group_exit+0x6b/0x9d > > > > > > > [] ? > > > > get_signal_to_deliver+0x449/0x46e > > > > > > > [] ? > > do_signal+0x28/0x4c4 > > > > > > > [] ? > > > > pvclock_clocksource_read+0x48/0xbf > > > > > > > [] ? > > ktime_get_ts+0x66/0xa8 > > > > > > > [] ? > > > > poll_select_copy_remaining+0xe0/0xf5 > > > > > > > [] ? > > > do_notify_resume+0x3b/0x74 > > > > > > > [] ? > > int_signal+0x12/0x17 > > > > > > > Code: 00 00 00 40 74 02 0f= 0b > 48 8d > > 77 70 48 > > > 8d bf 08 > > > > 01 00 > > > > > 00 e8 > > > > > > 8b 71 10 > > > > > > > 00 85 c0 0f 84 5d 01 00 00= 48 > 8b 6b > > 18 f6 83 > > > 80 00 00 > > > > 00 08 > > > > > <4c> 8b > > > > > > 65 30 > > > > > > > 74 11 be 68 05 00 00 48 c7= c7 > 8e df > > 4f 81 e8 > > > bb d0 > > > > > > > RIP [] > > iput+0x3e/0x195 > > > > > > > RSP > > > > > > > CR2: 0000000000000030 > > > > > > > ---[ end trace > 67cc1654658fedcc ]--- > > > > > > > Fixing recursive fault but > reboot is > > needed! > > > > > > > > > > > > > > I also tested Xen 4.2.0 and > problem > > is the > > > same. So > > > > is this > > > > > a Xen > > > > > > bug or a > > > > > > > kernel bug? I am running > vanilla > > > > [1][2][3][4][5][11][17]kernel.org kernel > > > > > 3.5.0 and > > > > > > my > > > > > > > hardware is Intel Core i7-= 3770 > CPU > > and Intel > > > DQ77MK > > > > > motherboard > > > > > > with > > > > > > > latest bios. > > > > > > > > > > > > > > Best regards, > > > > > > > Valtteri Kiviniemi > > > > > > > > > > > > > > References > > > > > > > > > > > > > > Visible links > > > > > > > 1. > [3][4][5][6][12][18]http://kernel.org/ > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Xen-devel mailing list > > > > > > > > [4][5][6][7][13][19]Xen-devel@lists.xen.org > > > > > > > > > [5][6][7][8][14][20]http://lists.xen.org/xen-devel > > > > > > > > > > > > References > > > > > > > > > > > > Visible links > > > > > > 1. > mailto:[7][8][9][15][21]pasik@iki.fi > > > > > > 2. > [8][9][10][16][22]http://kernel.org/ > > > > > > 3. > [9][10][11][17][23]http://kernel.org/ > > > > > > 4. > > mailto:[10][11][12][18][24]Xen-devel@lists.xen.org > > > > > > 5. > > [11][12][13][19][25]http://lists.xen.org/xen-devel > > > > > > > > > > References > > > > > > > > > > Visible links > > > > > 1. mailto:[13][14][20][26]pasik@iki.fi > > > > > 2. mailto:[14][15][21][27]pasik@iki.fi > > > > > 3. [15][16][22][28]http://kernel.org/ > > > > > 4. [16][17][23][29]http://kernel.org/ > > > > > 5. > mailto:[17][18][24][30]Xen-devel@lists.xen.org > > > > > 6. > [18][19][25][31]http://lists.xen.org/xen-devel > > > > > 7. mailto:[19][20][26][32]pasik@iki.fi > > > > > 8. [20][21][27][33]http://kernel.org/ > > > > > 9. [21][22][28][34]http://kernel.org/ > > > > > 10. > mailto:[22][23][29][35]Xen-devel@lists.xen.org > > > > > 11. > [23][24][30][36]http://lists.xen.org/xen-devel > > > > > > > > References > > > > > > > > Visible links > > > > 1. mailto:[25][31][37]pasik@iki.fi > > > > 2. mailto:[26][32][38]pasik@iki.fi > > > > 3. mailto:[27][33][39]pasik@iki.fi > > > > 4. [28][34][40]http://kernel.org/ > > > > 5. [29][35][41]http://kernel.org/ > > > > 6. mailto:[30][36][42]Xen-devel@lists.xen.org > > > > 7. [31][37][43]http://lists.xen.org/xen-devel > > > > 8. mailto:[32][38][44]pasik@iki.fi > > > > 9. [33][39][45]http://kernel.org/ > > > > 10. [34][40][46]http://kernel.org/ > > > > 11. mailto:[35][41][47]Xen-devel@lists.xen.org > > > > 12. [36][42][48]http://lists.xen.org/xen-devel > > > > 13. mailto:[37][43][49]pasik@iki.fi > > > > 14. mailto:[38][44][50]pasik@iki.fi > > > > 15. [39][45][51]http://kernel.org/ > > > > 16. [40][46][52]http://kernel.org/ > > > > 17. mailto:[41][47][53]Xen-devel@lists.xen.org > > > > 18. [42][48][54]http://lists.xen.org/xen-devel > > > > 19. mailto:[43][49][55]pasik@iki.fi > > > > 20. [44][50][56]http://kernel.org/ > > > > 21. [45][51][57]http://kernel.org/ > > > > 22. mailto:[46][52][58]Xen-devel@lists.xen.org > > > > 23. [47][53][59]http://lists.xen.org/xen-devel > > > > > > References > > > > > > Visible links > > > 1. mailto:[54][60]pasik@iki.fi > > > 2. mailto:[55][61]pasik@iki.fi > > > 3. mailto:[56][62]pasik@iki.fi > > > 4. mailto:[57][63]pasik@iki.fi > > > 5. [58][64]http://kernel.org/ > > > 6. [59][65]http://kernel.org/ > > > 7. mailto:[60][66]Xen-devel@lists.xen.org > > > 8. [61][67]http://lists.xen.org/xen-devel > > > 9. mailto:[62][68]pasik@iki.fi > > > 10. [63][69]http://kernel.org/ > > > 11. [64][70]http://kernel.org/ > > > 12. mailto:[65][71]Xen-devel@lists.xen.org > > > 13. [66][72]http://lists.xen.org/xen-devel > > > 14. mailto:[67][73]pasik@iki.fi > > > 15. mailto:[68][74]pasik@iki.fi > > > 16. [69][75]http://kernel.org/ > > > 17. [70][76]http://kernel.org/ > > > 18. mailto:[71][77]Xen-devel@lists.xen.org > > > 19. [72][78]http://lists.xen.org/xen-devel > > > 20. mailto:[73][79]pasik@iki.fi > > > 21. [74][80]http://kernel.org/ > > > 22. [75][81]http://kernel.org/ > > > 23. mailto:[76][82]Xen-devel@lists.xen.org > > > 24. [77][83]http://lists.xen.org/xen-devel > > > 25. mailto:[78][84]pasik@iki.fi > > > 26. mailto:[79][85]pasik@iki.fi > > > 27. mailto:[80][86]pasik@iki.fi > > > 28. [81][87]http://kernel.org/ > > > 29. [82][88]http://kernel.org/ > > > 30. mailto:[83][89]Xen-devel@lists.xen.org > > > 31. [84][90]http://lists.xen.org/xen-devel > > > 32. mailto:[85][91]pasik@iki.fi > > > 33. [86][92]http://kernel.org/ > > > 34. [87][93]http://kernel.org/ > > > 35. mailto:[88][94]Xen-devel@lists.xen.org > > > 36. [89][95]http://lists.xen.org/xen-devel > > > 37. mailto:[90][96]pasik@iki.fi > > > 38. mailto:[91][97]pasik@iki.fi > > > 39. [92][98]http://kernel.org/ > > > 40. [93][99]http://kernel.org/ > > > 41. mailto:[94][100]Xen-devel@lists.xen.org > > > 42. [95][101]http://lists.xen.org/xen-devel > > > 43. mailto:[96][102]pasik@iki.fi > > > 44. [97][103]http://kernel.org/ > > > 45. [98][104]http://kernel.org/ > > > 46. mailto:[99][105]Xen-devel@lists.xen.org > > > 47. [100][106]http://lists.xen.org/xen-devel > > > > References > > > > Visible links > > 1. mailto:[107]kiviniemi.valtteri@gmail.com > > 2. [108]http://ark.intel.com/products/65719/ > > 3. > [109]http://www.intel.com/content/www/us/en/motherboards/desktop-mot= herboards/desktop-board-dq77mk.html > > 4. mailto:[110]root@dataproof.fi > > 5. mailto:[111]pasik@iki.fi > > 6. [112]http://xen.org/ > > 7. mailto:[113]pasik@iki.fi > > 8. mailto:[114]pasik@iki.fi > > 9. mailto:[115]pasik@iki.fi > > 10. mailto:[116]pasik@iki.fi > > 11. [117]http://kernel.org/ > > 12. [118]http://kernel.org/ > > 13. mailto:[119]Xen-devel@lists.xen.org > > 14. [120]http://lists.xen.org/xen-devel > > 15. mailto:[121]pasik@iki.fi > > 16. [122]http://kernel.org/ > > 17. [123]http://kernel.org/ > > 18. mailto:[124]Xen-devel@lists.xen.org > > 19. [125]http://lists.xen.org/xen-devel > > 20. mailto:[126]pasik@iki.fi > > 21. mailto:[127]pasik@iki.fi > > 22. [128]http://kernel.org/ > > 23. [129]http://kernel.org/ > > 24. mailto:[130]Xen-devel@lists.xen.org > > 25. [131]http://lists.xen.org/xen-devel > > 26. mailto:[132]pasik@iki.fi > > 27. [133]http://kernel.org/ > > 28. [134]http://kernel.org/ > > 29. mailto:[135]Xen-devel@lists.xen.org > > 30. [136]http://lists.xen.org/xen-devel > > 31. mailto:[137]pasik@iki.fi > > 32. mailto:[138]pasik@iki.fi > > 33. mailto:[139]pasik@iki.fi > > 34. [140]http://kernel.org/ > > 35. [141]http://kernel.org/ > > 36. mailto:[142]Xen-devel@lists.xen.org > > 37. [143]http://lists.xen.org/xen-devel > > 38. mailto:[144]pasik@iki.fi > > 39. [145]http://kernel.org/ > > 40. [146]http://kernel.org/ > > 41. mailto:[147]Xen-devel@lists.xen.org > > 42. [148]http://lists.xen.org/xen-devel > > 43. mailto:[149]pasik@iki.fi > > 44. mailto:[150]pasik@iki.fi > > 45. [151]http://kernel.org/ > > 46. [152]http://kernel.org/ > > 47. mailto:[153]Xen-devel@lists.xen.org > > 48. [154]http://lists.xen.org/xen-devel > > 49. mailto:[155]pasik@iki.fi > > 50. [156]http://kernel.org/ > > 51. [157]http://kernel.org/ > > 52. mailto:[158]Xen-devel@lists.xen.org > > 53. [159]http://lists.xen.org/xen-devel > > 54. mailto:[160]pasik@iki.fi > > 55. mailto:[161]pasik@iki.fi > > 56. mailto:[162]pasik@iki.fi > > 57. mailto:[163]pasik@iki.fi > > 58. [164]http://kernel.org/ > > 59. [165]http://kernel.org/ > > 60. mailto:[166]Xen-devel@lists.xen.org > > 61. [167]http://lists.xen.org/xen-devel > > 62. mailto:[168]pasik@iki.fi > > 63. [169]http://kernel.org/ > > 64. [170]http://kernel.org/ > > 65. mailto:[171]Xen-devel@lists.xen.org > > 66. [172]http://lists.xen.org/xen-devel > > 67. mailto:[173]pasik@iki.fi > > 68. mailto:[174]pasik@iki.fi > > 69. [175]http://kernel.org/ > > 70. [176]http://kernel.org/ > > 71. mailto:[177]Xen-devel@lists.xen.org > > 72. [178]http://lists.xen.org/xen-devel > > 73. mailto:[179]pasik@iki.fi > > 74. [180]http://kernel.org/ > > 75. [181]http://kernel.org/ > > 76. mailto:[182]Xen-devel@lists.xen.org > > 77. [183]http://lists.xen.org/xen-devel > > 78. mailto:[184]pasik@iki.fi > > 79. mailto:[185]pasik@iki.fi > > 80. mailto:[186]pasik@iki.fi > > 81. [187]http://kernel.org/ > > 82. [188]http://kernel.org/ > > 83. mailto:[189]Xen-devel@lists.xen.org > > 84. [190]http://lists.xen.org/xen-devel > > 85. mailto:[191]pasik@iki.fi > > 86. [192]http://kernel.org/ > > 87. [193]http://kernel.org/ > > 88. mailto:[194]Xen-devel@lists.xen.org > > 89. [195]http://lists.xen.org/xen-devel > > 90. mailto:[196]pasik@iki.fi > > 91. mailto:[197]pasik@iki.fi > > 92. [198]http://kernel.org/ > > 93. [199]http://kernel.org/ > > 94. mailto:[200]Xen-devel@lists.xen.org > > 95. [201]http://lists.xen.org/xen-devel > > 96. mailto:[202]pasik@iki.fi > > 97. [203]http://kernel.org/ > > 98. [204]http://kernel.org/ > > 99. mailto:[205]Xen-devel@lists.xen.org > > 100. [206]http://lists.xen.org/xen-devel > = > References > = > Visible links > 1. http://nago.fi/dmesg.txt > 2. http://nago.fi/qemu-dm.txt > 3. http://nago.fi/xm-dmesg.txt > 4. http://nago.fi/domu-config.txt > 5. http://nago.fi/dom0-config.txt > 6. mailto:pasik@iki.fi > 7. mailto:kiviniemi.valtteri@gmail.com > 8. http://ark.intel.com/products/65719/ > 9. http://www.intel.com/content/www/us/en/motherboards/desktop-motherb= oards/desktop-board-dq77mk.html > 10. mailto:root@dataproof.fi > 11. mailto:pasik@iki.fi > 12. http://xen.org/ > 13. mailto:pasik@iki.fi > 14. mailto:pasik@iki.fi > 15. mailto:pasik@iki.fi > 16. mailto:pasik@iki.fi > 17. http://kernel.org/ > 18. http://kernel.org/ > 19. mailto:Xen-devel@lists.xen.org > 20. http://lists.xen.org/xen-devel > 21. mailto:pasik@iki.fi > 22. http://kernel.org/ > 23. http://kernel.org/ > 24. mailto:Xen-devel@lists.xen.org > 25. http://lists.xen.org/xen-devel > 26. mailto:pasik@iki.fi > 27. mailto:pasik@iki.fi > 28. http://kernel.org/ > 29. http://kernel.org/ > 30. mailto:Xen-devel@lists.xen.org > 31. http://lists.xen.org/xen-devel > 32. mailto:pasik@iki.fi > 33. http://kernel.org/ > 34. http://kernel.org/ > 35. mailto:Xen-devel@lists.xen.org > 36. http://lists.xen.org/xen-devel > 37. mailto:pasik@iki.fi > 38. mailto:pasik@iki.fi > 39. mailto:pasik@iki.fi > 40. http://kernel.org/ > 41. http://kernel.org/ > 42. mailto:Xen-devel@lists.xen.org > 43. http://lists.xen.org/xen-devel > 44. mailto:pasik@iki.fi > 45. http://kernel.org/ > 46. http://kernel.org/ > 47. mailto:Xen-devel@lists.xen.org > 48. http://lists.xen.org/xen-devel > 49. mailto:pasik@iki.fi > 50. mailto:pasik@iki.fi > 51. http://kernel.org/ > 52. http://kernel.org/ > 53. mailto:Xen-devel@lists.xen.org > 54. http://lists.xen.org/xen-devel > 55. mailto:pasik@iki.fi > 56. http://kernel.org/ > 57. http://kernel.org/ > 58. mailto:Xen-devel@lists.xen.org > 59. http://lists.xen.org/xen-devel > 60. mailto:pasik@iki.fi > 61. mailto:pasik@iki.fi > 62. mailto:pasik@iki.fi > 63. mailto:pasik@iki.fi > 64. http://kernel.org/ > 65. http://kernel.org/ > 66. mailto:Xen-devel@lists.xen.org > 67. http://lists.xen.org/xen-devel > 68. mailto:pasik@iki.fi > 69. http://kernel.org/ > 70. http://kernel.org/ > 71. mailto:Xen-devel@lists.xen.org > 72. http://lists.xen.org/xen-devel > 73. mailto:pasik@iki.fi > 74. mailto:pasik@iki.fi > 75. http://kernel.org/ > 76. http://kernel.org/ > 77. mailto:Xen-devel@lists.xen.org > 78. http://lists.xen.org/xen-devel > 79. mailto:pasik@iki.fi > 80. http://kernel.org/ > 81. http://kernel.org/ > 82. mailto:Xen-devel@lists.xen.org > 83. http://lists.xen.org/xen-devel > 84. mailto:pasik@iki.fi > 85. mailto:pasik@iki.fi > 86. mailto:pasik@iki.fi > 87. http://kernel.org/ > 88. http://kernel.org/ > 89. mailto:Xen-devel@lists.xen.org > 90. http://lists.xen.org/xen-devel > 91. mailto:pasik@iki.fi > 92. http://kernel.org/ > 93. http://kernel.org/ > 94. mailto:Xen-devel@lists.xen.org > 95. http://lists.xen.org/xen-devel > 96. mailto:pasik@iki.fi > 97. mailto:pasik@iki.fi > 98. http://kernel.org/ > 99. http://kernel.org/ > 100. mailto:Xen-devel@lists.xen.org > 101. http://lists.xen.org/xen-devel > 102. mailto:pasik@iki.fi > 103. http://kernel.org/ > 104. http://kernel.org/ > 105. mailto:Xen-devel@lists.xen.org > 106. http://lists.xen.org/xen-devel > 107. mailto:kiviniemi.valtteri@gmail.com > 108. http://ark.intel.com/products/65719/ > 109. http://www.intel.com/content/www/us/en/motherboards/desktop-motherb= oards/desktop-board-dq77mk.html > 110. mailto:root@dataproof.fi > 111. mailto:pasik@iki.fi > 112. http://xen.org/ > 113. mailto:pasik@iki.fi > 114. mailto:pasik@iki.fi > 115. mailto:pasik@iki.fi > 116. mailto:pasik@iki.fi > 117. http://kernel.org/ > 118. http://kernel.org/ > 119. mailto:Xen-devel@lists.xen.org > 120. http://lists.xen.org/xen-devel > 121. mailto:pasik@iki.fi > 122. http://kernel.org/ > 123. http://kernel.org/ > 124. mailto:Xen-devel@lists.xen.org > 125. http://lists.xen.org/xen-devel > 126. mailto:pasik@iki.fi > 127. mailto:pasik@iki.fi > 128. http://kernel.org/ > 129. http://kernel.org/ > 130. mailto:Xen-devel@lists.xen.org > 131. http://lists.xen.org/xen-devel > 132. mailto:pasik@iki.fi > 133. http://kernel.org/ > 134. http://kernel.org/ > 135. mailto:Xen-devel@lists.xen.org > 136. http://lists.xen.org/xen-devel > 137. mailto:pasik@iki.fi > 138. mailto:pasik@iki.fi > 139. mailto:pasik@iki.fi > 140. http://kernel.org/ > 141. http://kernel.org/ > 142. mailto:Xen-devel@lists.xen.org > 143. http://lists.xen.org/xen-devel > 144. mailto:pasik@iki.fi > 145. http://kernel.org/ > 146. http://kernel.org/ > 147. mailto:Xen-devel@lists.xen.org > 148. http://lists.xen.org/xen-devel > 149. mailto:pasik@iki.fi > 150. mailto:pasik@iki.fi > 151. http://kernel.org/ > 152. http://kernel.org/ > 153. mailto:Xen-devel@lists.xen.org > 154. http://lists.xen.org/xen-devel > 155. mailto:pasik@iki.fi > 156. http://kernel.org/ > 157. http://kernel.org/ > 158. mailto:Xen-devel@lists.xen.org > 159. http://lists.xen.org/xen-devel > 160. mailto:pasik@iki.fi > 161. mailto:pasik@iki.fi > 162. mailto:pasik@iki.fi > 163. mailto:pasik@iki.fi > 164. http://kernel.org/ > 165. http://kernel.org/ > 166. mailto:Xen-devel@lists.xen.org > 167. http://lists.xen.org/xen-devel > 168. mailto:pasik@iki.fi > 169. http://kernel.org/ > 170. http://kernel.org/ > 171. mailto:Xen-devel@lists.xen.org > 172. http://lists.xen.org/xen-devel > 173. mailto:pasik@iki.fi > 174. mailto:pasik@iki.fi > 175. http://kernel.org/ > 176. http://kernel.org/ > 177. mailto:Xen-devel@lists.xen.org > 178. http://lists.xen.org/xen-devel > 179. mailto:pasik@iki.fi > 180. http://kernel.org/ > 181. http://kernel.org/ > 182. mailto:Xen-devel@lists.xen.org > 183. http://lists.xen.org/xen-devel > 184. mailto:pasik@iki.fi > 185. mailto:pasik@iki.fi > 186. mailto:pasik@iki.fi > 187. http://kernel.org/ > 188. http://kernel.org/ > 189. mailto:Xen-devel@lists.xen.org > 190. http://lists.xen.org/xen-devel > 191. mailto:pasik@iki.fi > 192. http://kernel.org/ > 193. http://kernel.org/ > 194. mailto:Xen-devel@lists.xen.org > 195. http://lists.xen.org/xen-devel > 196. mailto:pasik@iki.fi > 197. mailto:pasik@iki.fi > 198. http://kernel.org/ > 199. http://kernel.org/ > 200. mailto:Xen-devel@lists.xen.org > 201. http://lists.xen.org/xen-devel > 202. mailto:pasik@iki.fi > 203. http://kernel.org/ > 204. http://kernel.org/ > 205. mailto:Xen-devel@lists.xen.org > 206. http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 13:14:48 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 13:14:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ2Im-0001x2-4J; Tue, 02 Oct 2012 13:14:20 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ2Ik-0001wx-0S for Xen-devel@lists.xen.org; Tue, 02 Oct 2012 13:14:18 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-6.tower-27.messagelabs.com!1349183647!7617922!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MjMzMTI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20691 invoked from network); 2 Oct 2012 13:14:08 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 13:14:08 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id 56B182860; Tue, 2 Oct 2012 16:14:07 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 3818120058; Tue, 2 Oct 2012 16:14:07 +0300 (EEST) Date: Tue, 2 Oct 2012 16:14:07 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Valtteri Kiviniemi Message-ID: <20121002131407.GM8912@reaktio.net> References: <20121001160117.GD8912@reaktio.net> <20121001164757.GF8912@reaktio.net> <20121001182437.GG8912@reaktio.net> <20121002121932.GL8912@reaktio.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.0.4, kernel 3.5.0 HVM crash and kernel BUG X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, Oct 02, 2012 at 04:01:04PM +0300, Valtteri Kiviniemi wrote: > Hi, > = > I already tried 3.2, 3.5, 3.5.0, 3.6.0-rc7 and 3.6.0, same problem all= of > those. My dom0 config is the same config that I'am using on other serv= er > where HVM is working, so I dont think that it is a config problem. I h= ave > triple checked everything and all should be ok. dom0 dmesg shows the s= ame > crash that I have previously posted here. /var/log/xen/ does not conta= in > any specific errors. > = > Could this be some kind of broblem with my motherboard bios being bugg= y or > CPU not supported? I'm using the new intel Ivy Bridge processor which = has > integrated GPU, but that should not probably cause these kind of probl= ems. > Or maybe some ACPI problem? xm dmesg is showing some notices about ACP= I. > Is there any ACPI kernel parameters that I should try booting? This ha= s to > be somekind of problem with my hardware, or then maybe it could be a > kernel problem too. I just really cant figure this out myself, I have > tried everything. > = Hmm.. I have some distant memories of seeing a patch that fixes a bug on recent Ivy Bridge systems, but I can't find a link right now. = Maybe you're affected by that.. Also: Did you already post the crash log, with all the debug/verbose option= s enabled for both Xen and dom0 kernel? = -- Pasi > Lets take a quick summary of what has been tested, what hardware I'm u= sing > etc. > = > Xen-versions tested: 4.2.0, 4.0.4 > Kernel-versions tested: 3.2.0, 3.5.0, 3.5.4, 3.6.0-rc7, 3.6.0 > = > Host OS: Debian testing/wheezy, udev version 175-7, 2.13-35, python > version 2.7.3~rc2-2.1 > = > Hardware: > = > CPU: Intel Core i7-3770 3.4GHz > MB: Intel DQ77MK (latest bios updated) > Memory: 32GB (4 x 8GB DDR3-1600MHz) > = > All relevant log files and configs: > = > dom0 dmesg: [1]http://nago.fi/dmesg.txt > qemu-dm log: [2]http://nago.fi/qemu-dm.txt > xm dmesg log: [3]http://nago.fi/xm-dmesg.txt > domU config: [4]http://nago.fi/domu-config.txt > dom0 kernel config: [5]http://nago.fi/dom0-config.txt > = > I have also tried playing with every setting on that domU that I can t= hink > of and tried different configs etc. > = > - Valtteri > = > 2012/10/2 Pasi K=E4rkk=E4inen <[6]pasik@iki.fi> > = > On Tue, Oct 02, 2012 at 03:11:07PM +0300, Valtteri Kiviniemi wrote: > > Hi, > > > > Another update: > > > > I wanted to check that if a Linux HVM would boot with working V= NC > console, > > so I tried to launch a Debian Squeeze installer on HVM. It refu= sed > to > > start ant told me that vbd hotplug scripts were not working. Af= ter > that > > failure even the Windows domU would not anymore start which was > previously > > starting ok. > > > > The hotplug scripts also starts hanging on the processes. > > > > root 9401 0.1 0.1 17700 1640 ? S 15:05 0:00 > /bin/bash > > /etc/xen/scripts/xen-hotplug-cleanup > > root 9441 0.1 0.1 17700 1644 ? S 15:05 0:00 > /bin/bash > > /etc/xen/scripts/xen-hotplug-cleanup > > root 9481 0.1 0.1 17700 1640 ? S 15:05 0:00 > /bin/bash > > /etc/xen/scripts/xen-hotplug-cleanup > > root 9560 0.1 0.1 17700 1640 ? S 15:05 0:00 > /bin/bash > > /etc/xen/scripts/xen-hotplug-cleanup > > root 10738 0.1 0.1 17696 1636 ? S 15:05 0:00 > /bin/bash > > /etc/xen/scripts/xen-hotplug-cleanup > > root 10747 0.1 0.1 17792 1736 ? S 15:05 0:00 > /bin/bash > > /etc/xen/scripts/block remove > > root 11286 0.0 0.0 4080 324 ? S 15:06 0:00 > sleep 1 > > root 11290 0.0 0.0 4080 324 ? S 15:06 0:00 > sleep 1 > > root 11294 0.0 0.0 4080 324 ? S 15:06 0:00 > sleep 1 > > root 11298 0.0 0.0 4080 324 ? S 15:06 0:00 > sleep 1 > > root 11302 0.0 0.0 4080 320 ? S 15:06 0:00 > sleep 1 > > root 11306 0.0 0.0 4080 320 ? S 15:06 0:00 > sleep 1 > > > > Then I did a xm destroy and I had again the kernel BUG on dmesg= . So > it > > seems that the problem is not fixed by using 3.6.0. Udev versio= n is > 175-7. > > > = > So you have definitely something broken in your system, > probably in your dom0 kernel. Try with Linux 3.5.4 or 3.4.x, > and see how that goes. > = > Any errors in dom0 dmesg? How about in /var/log/xen/* ? > = > -- Pasi > = > > > > > > 2012/10/1 Valtteri Kiviniemi <[1][7]kiviniemi.valtteri@gmail.co= m> > > > > Hi, > > > > CPU: Intel Core i7-3770 3.4GHz > > [2][8]http://ark.intel.com/products/65719/ > > > > MB: Intel DQ77MK (latest bios updated) > > > [3][9]http://www.intel.com/content/www/us/en/motherboards/desktop-m= otherboards/desktop-board-dq77mk.html > > > > Memory: 32GB (4 x 8GB DDR3-1600MHz) > > > > Host is Debian wheezy/testing, Xen 4.0.4 and latest 3.6.0 ker= nel. > > > > Noticed also some errors in xm dmesg: > > > > root@xen-2:~# xm dmesg > > > > (XEN) Xen version 4.0.4 ([4][10]root@dataproof.fi) (gcc versi= on > 4.7.1 > > (Debian 4.7.1-7) ) Sun Sep 30 20:28:26 EEST 2012 > > (XEN) Latest ChangeSet: unavailable > > (XEN) Bootloader: GNU GRUB 0.97 > > (XEN) Command line: dom0_mem=3D1280M cpufreq=3Dxen clocksourc= e=3Dhpet > > (XEN) Video information: > > (XEN) VGA is text mode 80x25, font 8x16 > > (XEN) VBE/DDC methods: none; EDID transfer time: 0 seconds > > (XEN) EDID info not retrieved because no DDC retrieval method > detected > > (XEN) Disc information: > > (XEN) Found 4 MBR signatures > > (XEN) Found 4 EDD information structures > > (XEN) Xen-e820 RAM map: > > (XEN) 0000000000000000 - 000000000009d800 (usable) > > (XEN) 000000000009d800 - 00000000000a0000 (reserved) > > (XEN) 00000000000e0000 - 0000000000100000 (reserved) > > (XEN) 0000000000100000 - 0000000020000000 (usable) > > (XEN) 0000000020000000 - 0000000020200000 (reserved) > > (XEN) 0000000020200000 - 0000000040004000 (usable) > > (XEN) 0000000040004000 - 0000000040005000 (reserved) > > (XEN) 0000000040005000 - 00000000dbe44000 (usable) > > (XEN) 00000000dbe44000 - 00000000dc2d7000 (reserved) > > (XEN) 00000000dc2d7000 - 00000000dc2e7000 (ACPI data) > > (XEN) 00000000dc2e7000 - 00000000dc40c000 (ACPI NVS) > > (XEN) 00000000dc40c000 - 00000000dc6af000 (reserved) > > (XEN) 00000000dc6af000 - 00000000dc6b0000 (usable) > > (XEN) 00000000dc6b0000 - 00000000dc6f3000 (ACPI NVS) > > (XEN) 00000000dc6f3000 - 00000000dd000000 (usable) > > (XEN) 00000000dd800000 - 00000000dfa00000 (reserved) > > (XEN) 00000000f8000000 - 00000000fc000000 (reserved) > > (XEN) 00000000fec00000 - 00000000fec01000 (reserved) > > (XEN) 00000000fed00000 - 00000000fed04000 (reserved) > > (XEN) 00000000fed1c000 - 00000000fed20000 (reserved) > > (XEN) 00000000fee00000 - 00000000fee01000 (reserved) > > (XEN) 00000000ff000000 - 0000000100000000 (reserved) > > (XEN) 0000000100000000 - 000000081e600000 (usable) > > (XEN) ACPI: RSDP 000F0490, 0024 (r2 INTEL) > > (XEN) ACPI: XSDT DC2DB080, 007C (r1 INTEL DQ77MK 32 = AMI > > 10013) > > (XEN) ACPI: FACP DC2E51F0, 010C (r5 INTEL DQ77MK 32 = AMI > > 10013) > > (XEN) ACPI Warning (tbfadt-0232): FADT (revision 5) is longer > than ACPI > > 2.0 version, truncating length 0x10C to 0xF4 [20070126] > > (XEN) ACPI: DSDT DC2DB188, A061 (r2 INTEL DQ77MK 32 = INTL > > 20051117) > > (XEN) ACPI: FACS DC40A080, 0040 > > (XEN) ACPI: APIC DC2E5300, 0092 (r3 INTEL DQ77MK 32 = AMI > > 10013) > > (XEN) ACPI: FPDT DC2E5398, 0044 (r1 INTEL DQ77MK 32 = AMI > > 10013) > > (XEN) ACPI: TCPA DC2E53E0, 0032 (r2 INTEL DQ77MK 32 = MSFT > > 1000013) > > (XEN) ACPI: MCFG DC2E5418, 003C (r1 INTEL DQ77MK 32 = MSFT > > 97) > > (XEN) ACPI: HPET DC2E5458, 0038 (r1 INTEL DQ77MK 32 = AMI. > > 5) > > (XEN) ACPI: SSDT DC2E5490, 036D (r1 INTEL DQ77MK 32 = INTL > > 20091112) > > (XEN) ACPI: SSDT DC2E5800, 09AA (r1 INTEL DQ77MK 32 = INTL > > 20051117) > > (XEN) ACPI: SSDT DC2E61B0, 0A92 (r1 INTEL DQ77MK 32 = INTL > > 20051117) > > (XEN) ACPI: DMAR DC2E6C48, 00B8 (r1 INTEL DQ77MK 32 = INTL > > 1) > > (XEN) ACPI: ASF! DC2E6D00, 00A5 (r32 INTEL DQ77MK 32 > TFSM > > F4240) > > (XEN) System RAM: 32682MB (33467320kB) > > (XEN) Domain heap initialised > > (XEN) ACPI: 32/64X FACS address mismatch in FADT - > > dc40a080/0000000000000000, using 32 > > (XEN) Processor #0 7:10 APIC version 21 > > (XEN) Processor #2 7:10 APIC version 21 > > (XEN) Processor #4 7:10 APIC version 21 > > (XEN) Processor #6 7:10 APIC version 21 > > (XEN) Processor #1 7:10 APIC version 21 > > (XEN) Processor #3 7:10 APIC version 21 > > (XEN) Processor #5 7:10 APIC version 21 > > (XEN) Processor #7 7:10 APIC version 21 > > (XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, G= SI > 0-23 > > (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs > > (XEN) Switched to APIC driver x2apic_cluster. > > (XEN) x2APIC mode enabled. > > (XEN) Using scheduler: SMP Credit Scheduler (credit) > > (XEN) Detected 3392.369 MHz processor. > > (XEN) Initing memory sharing. > > (XEN) VMX: Supported advanced features: > > (XEN) - APIC MMIO access virtualisation > > (XEN) - APIC TPR shadow > > (XEN) - Extended Page Tables (EPT) > > (XEN) - Virtual-Processor Identifiers (VPID) > > (XEN) - Virtual NMI > > (XEN) - MSR direct-access bitmap > > (XEN) - Unrestricted Guest > > (XEN) EPT supports 2MB super page. > > (XEN) HVM: ASIDs enabled. > > (XEN) HVM: VMX enabled > > (XEN) HVM: Hardware Assisted Paging detected. > > (XEN) Intel VT-d Snoop Control not enabled. > > (XEN) Intel VT-d Dom0 DMA Passthrough not enabled. > > (XEN) Intel VT-d Queued Invalidation enabled. > > (XEN) Intel VT-d Interrupt Remapping enabled. > > (XEN) I/O virtualisation enabled > > (XEN) - Dom0 mode: Relaxed > > (XEN) Enabled directed EOI with ioapic_ack_old on! > > (XEN) Total of 8 processors activated. > > (XEN) ENABLING IO-APIC IRQs > > (XEN) -> Using old ACK method > > (XEN) TSC is reliable, synchronization unnecessary > > (XEN) Platform timer appears to have unexpectedly wrapped 1 > times. > > (XEN) Platform timer is 14.318MHz HPET > > (XEN) Allocated console ring of 16 KiB. > > (XEN) Brought up 8 CPUs > > (XEN) *** LOADING DOMAIN 0 *** > > (XEN) Xen kernel: 64-bit, lsb, compat32 > > (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> > 0x1ae7000 > > (XEN) PHYSICAL MEMORY ARRANGEMENT: > > (XEN) Dom0 alloc.: 0000000804000000->0000000806000000 (319= 488 > pages > > to be allocated) > > (XEN) VIRTUAL MEMORY ARRANGEMENT: > > (XEN) Loaded kernel: ffffffff81000000->ffffffff81ae7000 > > (XEN) Init. ramdisk: ffffffff81ae7000->ffffffff81ae7000 > > (XEN) Phys-Mach map: ffffffff81ae7000->ffffffff81d67000 > > (XEN) Start info: ffffffff81d67000->ffffffff81d674b4 > > (XEN) Page tables: ffffffff81d68000->ffffffff81d7b000 > > (XEN) Boot stack: ffffffff81d7b000->ffffffff81d7c000 > > (XEN) TOTAL: ffffffff80000000->ffffffff82000000 > > (XEN) ENTRY ADDRESS: ffffffff815e3210 > > (XEN) Dom0 has maximum 8 VCPUs > > (XEN) [VT-D]iommu.c:718: BIOS did not enable IGD for VT prope= rly. > > Disabling IGD VT-d engine. > > (XEN) Scrubbing Free RAM: done. > > (XEN) Xen trace buffers: disabled > > (XEN) Std. Loglevel: Errors and warnings > > (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warni= ngs) > > (XEN) Xen is relinquishing VGA console. > > (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to > switch > > input to Xen) > > (XEN) Freed 172kB init memory. > > (XEN) traps.c:2333:d0 Domain attempted WRMSR 000000000000008b > from > > 00000012:00000000 to 00000000:00000000. > > > > - Valtteri > > > > 2012/10/1 Pasi K=E4rkk=E4inen <[5][11]pasik@iki.fi> > > > > On Mon, Oct 01, 2012 at 09:12:50PM +0300, Valtteri Kiviniemi > wrote: > > > Hi, > > > > > > Lowering memory or vcpu's does not help, problem is the > same. I > > originally > > > installed Xen 4.2.0 and the problem was same on that t= oo. > Then I > > > downgraded back to 4.0.4 since I thought that this mig= ht > be a bug > > on > > > 4.2.0. I have been previously running Windows Server 2= 008 > R2 > > succesfully > > > on Xen 4.0.x on different hardware with this same conf= ig. > > Hypervisor is > > > 64bit and windows is 64bit. > > > > > > Any ideas what to try next? > > > > > > > What kind of hardware is that? > > > > [6][12]xen.org automated testing regularly tests Windows VM= s, > and it works > > OK there. > > > > -- Pasi > > > Ps. qemu-dm.log is the following: > > > > > > domid: 10 > > > config qemu network with xen bridge for tap10.0 xenbr0 > > > Using file /dev/virtuals/ts in read-write mode > > > Using file /media/iso/windows_server_2008_r2_sp1.iso in > read-only > > mode > > > Watching /local/domain/0/device-model/10/logdirty/cmd > > > Watching /local/domain/0/device-model/10/command > > > qemu_map_cache_init nr_buckets =3D 10000 size 4194304 > > > shared page at pfn feffd > > > buffered io page at pfn feffb > > > Guest uuid =3D 52f19e23-2955-c27d-a22c-60c5d8c60d5a > > > Time offset set 0 > > > populating video RAM at ff000000 > > > mapping video RAM from ff000000 > > > Register xen platform. > > > Done register platform. > > > platform_fixed_ioport: changed ro/rw state of ROM memo= ry > area. > > now is rw > > > state. > > > > xs_read(/local/domain/0/device-model/10/xen_extended_power_mgmt): > > read > > > error > > > medium change watch on `hdc' (index: 1): > > > /media/iso/windows_server_2008_r2_sp1.iso > > > I/O request not ready: 0, ptr: 0, port: 0, data: 0, co= unt: > 0, > > size: 0 > > > Log-dirty: no command yet. > > > xs_read(/local/domain/10/log-throttling): read error > > > qemu: ignoring not-understood drive > > `/local/domain/10/log-throttling' > > > medium change watch on `/local/domain/10/log-throttlin= g' - > > unknown device, > > > ignored > > > cirrus vga map change while on lfb mode > > > mapping vram to f0000000 - f0400000 > > > platform_fixed_ioport: changed ro/rw state of ROM memo= ry > area. > > now is rw > > > state. > > > platform_fixed_ioport: changed ro/rw state of ROM memo= ry > area. > > now is ro > > > state. > > > > > > 2012/10/1 Pasi K=E4rkk=E4inen <[1][7][13]pasik@iki.fi> > > > > > > On Mon, Oct 01, 2012 at 07:23:44PM +0300, Valtteri > Kiviniemi > > wrote: > > > > Hi, > > > > > > > > I have tried other config files, but the proble= m is > the > > same. At > > > the > > > > moment I'm using a config file from another ser= ver > where I > > have a > > > working > > > > Windows Server 2008 R2 installation, so I dont > think that > > there is > > > > anything wrong with my config: > > > > > > > > > > Did you try with less vcpus, for example 2 ? > > > how about with less memory, say 2 GB ? > > > > > > Did you try with later Xen versions? Is that a 32bit > Xen, or > > 64bit Xen > > > hypervisor? > > > > > > -- Pasi > > > > kernel =3D "/usr/lib/xen/boot/hvmloader" > > > > builder =3D "hvm" > > > > shadow_memory =3D "8" > > > > memory =3D "4096" > > > > name =3D "ts" > > > > vcpus =3D "8" > > > > cpus =3D ["0", "1", "2", "3", "4", "5", "6", "7= "] > > > > pae =3D "1" > > > > acpi =3D "1" > > > > apic =3D "1" > > > > vfb =3D [ 'type=3Dvnc, vnclisten=3D10.100.100.5= 0, > vncpasswd=3Dxxx' > > ] > > > > xen_extended_power_mgmt =3D "0" > > > > vif =3D [ "type=3Dioemu, mac=3D00:16:3e:d7:d7:5= d, > bridge=3Dxenbr0" > > ] > > > > disk =3D [ "phy:/dev/virtuals/ts,hda,w", > > > > > > "file:/media/iso/windows_server_2008_r2_sp1.iso,hdc:cdrom,= r" ] > > > > on_poweroff =3D "destroy" > > > > on_reboot =3D "restart" > > > > on_crash =3D "restart" > > > > viridian =3D "1" > > > > device_model =3D "/usr/lib/xen/bin/qemu-dm" > > > > boot =3D "dc" > > > > snapshot =3D "0" > > > > vncconsole =3D "1" > > > > sdl =3D "0" > > > > opengl =3D "0" > > > > vnc =3D "1" > > > > nographic =3D "0" > > > > stdvga =3D "0" > > > > tsc_mode =3D "1" > > > > monitor =3D "0" > > > > localtime =3D "1" > > > > usb =3D "0" > > > > keymap =3D "fi" > > > > xen_platform_pci =3D "1" > > > > pci_msitranslate =3D "1" > > > > pci_power_mgmt =3D "0" > > > > > > > > 2012/10/1 Pasi K=E4rkk=E4inen > <[1][2][8][14]pasik@iki.fi> > > > > > > > > On Mon, Oct 01, 2012 at 06:46:08PM +0300, > Valtteri > > Kiviniemi > > > wrote: > > > > > Hi, > > > > > > > > > > Yes, I have viridian=3D1 on my domU conf= ig. > > > > > > > > > > > > > Try with some known good domU configfile. > > > > > > > > -- Pasi > > > > > 2012/10/1 Pasi K=E4rkk=E4inen > > <[1][2][3][9][15]pasik@iki.fi> > > > > > > > > > > On Mon, Oct 01, 2012 at 05:06:53PM +03= 00, > > Valtteri > > > Kiviniemi > > > > wrote: > > > > > > Hi, > > > > > > > > > > > > I'm now using 3.6.0 and can't > reproduce that > > crash > > > anymore, > > > > so it > > > > > seems > > > > > > that it was a kernel bug. > > > > > > > > > > > > > > > > OK. > > > > > > However I'm still getting black > screen on > > VNC > > > > > > when trying to install Windows Se= rver > 2008 > > R2. I can > > > see the > > > > > "windows is > > > > > > loading files" screen but after t= he > > installer starts > > > the VNC > > > > > display goes > > > > > > black. > > > > > > > > > > > > Any ideas? > > > > > > > > > > > > > > > > Do you have viridian=3D1 specified for= the > windows > > vm? > > > > > > > > > > -- Pasi > > > > > > > > > > > - Valtteri > > > > > > > > > > > > 2012/10/1 Pasi K=E4rkk=E4inen > > <[1][2][3][4][10][16]pasik@iki.fi> > > > > > > > > > > > > On Sun, Sep 30, 2012 at 11:18:0= 3PM > +0300, > > Valtteri > > > > Kiviniemi > > > > > wrote: > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > Hello, > > > > > > > I'm trying to get Windows > Server 2008 > > R2 > > > installation > > > > > booting on > > > > > > Xen > > > > > > > 4.0.4. Using the following > config: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The domU will start booting > just > > fine, but > > > after a > > > > few > > > > > minutes the > > > > > > VNC > > > > > > > screen goes black. After t= hat > when > > typing "xm > > > destroy > > > > ts" it > > > > > will > > > > > > trigger > > > > > > > a kernel BUG: > > > > > > > > > > > > > > BUG: unable to handle kern= el > NULL > > pointer > > > dereference > > > > at > > > > > > 0000000000000030 > > > > > > > IP: [] > > iput+0x3e/0x195 > > > > > > > PGD 0 > > > > > > > Oops: 0000 [#1] SMP > > > > > > > CPU 6 > > > > > > > Pid: 3571, comm: qemu-dm N= ot > tainted > > > 3.5.0-dom0 #1 > > > > > > > > > > > > First of all upgrade to latest > 3.5.x Linux > > kernel > > > release > > > > .. so > > > > > at least > > > > > > 3.5.4. > > > > > > > > > > > > -- Pasi > > > > > > > > > > > > > /DQ77MK > > > > > > > RIP: e030:[] > > > [] > > > > > > iput+0x3e/0x195 > > > > > > > RSP: e02b:ffff8800389ffbf8 > EFLAGS: > > 00010246 > > > > > > > RAX: 0000000000000001 RBX: > > ffff8800377b0720 > > > RCX: > > > > > ffff8800501c0000 > > > > > > > RDX: ffff8800501c0000 RSI: > > ffff8800377b0790 > > > RDI: > > > > > ffff8800377b0790 > > > > > > > RBP: 0000000000000000 R08: > > ffffffff815cdd00 > > > R09: > > > > > 0000000000000016 > > > > > > > R10: fefefefefefefeff R11: > > ffff8800377b0400 > > > R12: > > > > > 00000001000a3e0c > > > > > > > R13: 0000000000000000 R14: > > 00000001000a3e0c > > > R15: > > > > > ffff8800389ffc28 > > > > > > > FS: 00007f1af70a8700(0000) > > > GS:ffff880050180000(0000) > > > > > > > knlGS:0000000000000000 > > > > > > > CS: e033 DS: 0000 ES: 0000 > CR0: > > > 000000008005003b > > > > > > > CR2: 0000000000000030 CR3: > > 000000000156d000 > > > CR4: > > > > > 0000000000002660 > > > > > > > DR0: 0000000000000000 DR1: > > 0000000000000000 > > > DR2: > > > > > 0000000000000000 > > > > > > > DR3: 0000000000000000 DR6: > > 00000000ffff0ff0 > > > DR7: > > > > > 0000000000000400 > > > > > > > Process qemu-dm (pid: 3571, > > threadinfo > > > > ffff8800389fe000, > > > > > task > > > > > > > ffff88003a721260) > > > > > > > Stack: > > > > > > > ffff88003a6d6400 > ffff8800377b0000 > > > 00000001000a3e0c > > > > > > ffffffff8133ce8f > > > > > > > ffff8800377b0400 > ffffffff8134b6cd > > > ffff8800389ffc28 > > > > > > ffff8800389ffc28 > > > > > > > ffff8800377b00f8 > ffff8800377b0680 > > > ffff880038cdcd60 > > > > > > ffff8800377b0000 > > > > > > > Call Trace: > > > > > > > [] ? > > > sk_release_kernel+0x23/0x39 > > > > > > > [] ? > > > netdev_run_todo+0x1e9/0x206 > > > > > > > [] ? > > > tun_chr_close+0x4c/0x7b > > > > > > > [] ? > > fput+0xe4/0x1c5 > > > > > > > [] ? > > filp_close+0x61/0x68 > > > > > > > [] ? > > > put_files_struct+0x62/0xb9 > > > > > > > [] ? > > do_exit+0x24a/0x74c > > > > > > > [] ? > > > do_group_exit+0x6b/0x9d > > > > > > > [] ? > > > > get_signal_to_deliver+0x449/0x46e > > > > > > > [] ? > > do_signal+0x28/0x4c4 > > > > > > > [] ? > > > > pvclock_clocksource_read+0x48/0xbf > > > > > > > [] ? > > ktime_get_ts+0x66/0xa8 > > > > > > > [] ? > > > > poll_select_copy_remaining+0xe0/0xf5 > > > > > > > [] ? > > > do_notify_resume+0x3b/0x74 > > > > > > > [] ? > > int_signal+0x12/0x17 > > > > > > > Code: 00 00 00 40 74 02 0f= 0b > 48 8d > > 77 70 48 > > > 8d bf 08 > > > > 01 00 > > > > > 00 e8 > > > > > > 8b 71 10 > > > > > > > 00 85 c0 0f 84 5d 01 00 00= 48 > 8b 6b > > 18 f6 83 > > > 80 00 00 > > > > 00 08 > > > > > <4c> 8b > > > > > > 65 30 > > > > > > > 74 11 be 68 05 00 00 48 c7= c7 > 8e df > > 4f 81 e8 > > > bb d0 > > > > > > > RIP [] > > iput+0x3e/0x195 > > > > > > > RSP > > > > > > > CR2: 0000000000000030 > > > > > > > ---[ end trace > 67cc1654658fedcc ]--- > > > > > > > Fixing recursive fault but > reboot is > > needed! > > > > > > > > > > > > > > I also tested Xen 4.2.0 and > problem > > is the > > > same. So > > > > is this > > > > > a Xen > > > > > > bug or a > > > > > > > kernel bug? I am running > vanilla > > > > [1][2][3][4][5][11][17]kernel.org kernel > > > > > 3.5.0 and > > > > > > my > > > > > > > hardware is Intel Core i7-= 3770 > CPU > > and Intel > > > DQ77MK > > > > > motherboard > > > > > > with > > > > > > > latest bios. > > > > > > > > > > > > > > Best regards, > > > > > > > Valtteri Kiviniemi > > > > > > > > > > > > > > References > > > > > > > > > > > > > > Visible links > > > > > > > 1. > [3][4][5][6][12][18]http://kernel.org/ > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Xen-devel mailing list > > > > > > > > [4][5][6][7][13][19]Xen-devel@lists.xen.org > > > > > > > > > [5][6][7][8][14][20]http://lists.xen.org/xen-devel > > > > > > > > > > > > References > > > > > > > > > > > > Visible links > > > > > > 1. > mailto:[7][8][9][15][21]pasik@iki.fi > > > > > > 2. > [8][9][10][16][22]http://kernel.org/ > > > > > > 3. > [9][10][11][17][23]http://kernel.org/ > > > > > > 4. > > mailto:[10][11][12][18][24]Xen-devel@lists.xen.org > > > > > > 5. > > [11][12][13][19][25]http://lists.xen.org/xen-devel > > > > > > > > > > References > > > > > > > > > > Visible links > > > > > 1. mailto:[13][14][20][26]pasik@iki.fi > > > > > 2. mailto:[14][15][21][27]pasik@iki.fi > > > > > 3. [15][16][22][28]http://kernel.org/ > > > > > 4. [16][17][23][29]http://kernel.org/ > > > > > 5. > mailto:[17][18][24][30]Xen-devel@lists.xen.org > > > > > 6. > [18][19][25][31]http://lists.xen.org/xen-devel > > > > > 7. mailto:[19][20][26][32]pasik@iki.fi > > > > > 8. [20][21][27][33]http://kernel.org/ > > > > > 9. [21][22][28][34]http://kernel.org/ > > > > > 10. > mailto:[22][23][29][35]Xen-devel@lists.xen.org > > > > > 11. > [23][24][30][36]http://lists.xen.org/xen-devel > > > > > > > > References > > > > > > > > Visible links > > > > 1. mailto:[25][31][37]pasik@iki.fi > > > > 2. mailto:[26][32][38]pasik@iki.fi > > > > 3. mailto:[27][33][39]pasik@iki.fi > > > > 4. [28][34][40]http://kernel.org/ > > > > 5. [29][35][41]http://kernel.org/ > > > > 6. mailto:[30][36][42]Xen-devel@lists.xen.org > > > > 7. [31][37][43]http://lists.xen.org/xen-devel > > > > 8. mailto:[32][38][44]pasik@iki.fi > > > > 9. [33][39][45]http://kernel.org/ > > > > 10. [34][40][46]http://kernel.org/ > > > > 11. mailto:[35][41][47]Xen-devel@lists.xen.org > > > > 12. [36][42][48]http://lists.xen.org/xen-devel > > > > 13. mailto:[37][43][49]pasik@iki.fi > > > > 14. mailto:[38][44][50]pasik@iki.fi > > > > 15. [39][45][51]http://kernel.org/ > > > > 16. [40][46][52]http://kernel.org/ > > > > 17. mailto:[41][47][53]Xen-devel@lists.xen.org > > > > 18. [42][48][54]http://lists.xen.org/xen-devel > > > > 19. mailto:[43][49][55]pasik@iki.fi > > > > 20. [44][50][56]http://kernel.org/ > > > > 21. [45][51][57]http://kernel.org/ > > > > 22. mailto:[46][52][58]Xen-devel@lists.xen.org > > > > 23. [47][53][59]http://lists.xen.org/xen-devel > > > > > > References > > > > > > Visible links > > > 1. mailto:[54][60]pasik@iki.fi > > > 2. mailto:[55][61]pasik@iki.fi > > > 3. mailto:[56][62]pasik@iki.fi > > > 4. mailto:[57][63]pasik@iki.fi > > > 5. [58][64]http://kernel.org/ > > > 6. [59][65]http://kernel.org/ > > > 7. mailto:[60][66]Xen-devel@lists.xen.org > > > 8. [61][67]http://lists.xen.org/xen-devel > > > 9. mailto:[62][68]pasik@iki.fi > > > 10. [63][69]http://kernel.org/ > > > 11. [64][70]http://kernel.org/ > > > 12. mailto:[65][71]Xen-devel@lists.xen.org > > > 13. [66][72]http://lists.xen.org/xen-devel > > > 14. mailto:[67][73]pasik@iki.fi > > > 15. mailto:[68][74]pasik@iki.fi > > > 16. [69][75]http://kernel.org/ > > > 17. [70][76]http://kernel.org/ > > > 18. mailto:[71][77]Xen-devel@lists.xen.org > > > 19. [72][78]http://lists.xen.org/xen-devel > > > 20. mailto:[73][79]pasik@iki.fi > > > 21. [74][80]http://kernel.org/ > > > 22. [75][81]http://kernel.org/ > > > 23. mailto:[76][82]Xen-devel@lists.xen.org > > > 24. [77][83]http://lists.xen.org/xen-devel > > > 25. mailto:[78][84]pasik@iki.fi > > > 26. mailto:[79][85]pasik@iki.fi > > > 27. mailto:[80][86]pasik@iki.fi > > > 28. [81][87]http://kernel.org/ > > > 29. [82][88]http://kernel.org/ > > > 30. mailto:[83][89]Xen-devel@lists.xen.org > > > 31. [84][90]http://lists.xen.org/xen-devel > > > 32. mailto:[85][91]pasik@iki.fi > > > 33. [86][92]http://kernel.org/ > > > 34. [87][93]http://kernel.org/ > > > 35. mailto:[88][94]Xen-devel@lists.xen.org > > > 36. [89][95]http://lists.xen.org/xen-devel > > > 37. mailto:[90][96]pasik@iki.fi > > > 38. mailto:[91][97]pasik@iki.fi > > > 39. [92][98]http://kernel.org/ > > > 40. [93][99]http://kernel.org/ > > > 41. mailto:[94][100]Xen-devel@lists.xen.org > > > 42. [95][101]http://lists.xen.org/xen-devel > > > 43. mailto:[96][102]pasik@iki.fi > > > 44. [97][103]http://kernel.org/ > > > 45. [98][104]http://kernel.org/ > > > 46. mailto:[99][105]Xen-devel@lists.xen.org > > > 47. [100][106]http://lists.xen.org/xen-devel > > > > References > > > > Visible links > > 1. mailto:[107]kiviniemi.valtteri@gmail.com > > 2. [108]http://ark.intel.com/products/65719/ > > 3. > [109]http://www.intel.com/content/www/us/en/motherboards/desktop-mot= herboards/desktop-board-dq77mk.html > > 4. mailto:[110]root@dataproof.fi > > 5. mailto:[111]pasik@iki.fi > > 6. [112]http://xen.org/ > > 7. mailto:[113]pasik@iki.fi > > 8. mailto:[114]pasik@iki.fi > > 9. mailto:[115]pasik@iki.fi > > 10. mailto:[116]pasik@iki.fi > > 11. [117]http://kernel.org/ > > 12. [118]http://kernel.org/ > > 13. mailto:[119]Xen-devel@lists.xen.org > > 14. [120]http://lists.xen.org/xen-devel > > 15. mailto:[121]pasik@iki.fi > > 16. [122]http://kernel.org/ > > 17. [123]http://kernel.org/ > > 18. mailto:[124]Xen-devel@lists.xen.org > > 19. [125]http://lists.xen.org/xen-devel > > 20. mailto:[126]pasik@iki.fi > > 21. mailto:[127]pasik@iki.fi > > 22. [128]http://kernel.org/ > > 23. [129]http://kernel.org/ > > 24. mailto:[130]Xen-devel@lists.xen.org > > 25. [131]http://lists.xen.org/xen-devel > > 26. mailto:[132]pasik@iki.fi > > 27. [133]http://kernel.org/ > > 28. [134]http://kernel.org/ > > 29. mailto:[135]Xen-devel@lists.xen.org > > 30. [136]http://lists.xen.org/xen-devel > > 31. mailto:[137]pasik@iki.fi > > 32. mailto:[138]pasik@iki.fi > > 33. mailto:[139]pasik@iki.fi > > 34. [140]http://kernel.org/ > > 35. [141]http://kernel.org/ > > 36. mailto:[142]Xen-devel@lists.xen.org > > 37. [143]http://lists.xen.org/xen-devel > > 38. mailto:[144]pasik@iki.fi > > 39. [145]http://kernel.org/ > > 40. [146]http://kernel.org/ > > 41. mailto:[147]Xen-devel@lists.xen.org > > 42. [148]http://lists.xen.org/xen-devel > > 43. mailto:[149]pasik@iki.fi > > 44. mailto:[150]pasik@iki.fi > > 45. [151]http://kernel.org/ > > 46. [152]http://kernel.org/ > > 47. mailto:[153]Xen-devel@lists.xen.org > > 48. [154]http://lists.xen.org/xen-devel > > 49. mailto:[155]pasik@iki.fi > > 50. [156]http://kernel.org/ > > 51. [157]http://kernel.org/ > > 52. mailto:[158]Xen-devel@lists.xen.org > > 53. [159]http://lists.xen.org/xen-devel > > 54. mailto:[160]pasik@iki.fi > > 55. mailto:[161]pasik@iki.fi > > 56. mailto:[162]pasik@iki.fi > > 57. mailto:[163]pasik@iki.fi > > 58. [164]http://kernel.org/ > > 59. [165]http://kernel.org/ > > 60. mailto:[166]Xen-devel@lists.xen.org > > 61. [167]http://lists.xen.org/xen-devel > > 62. mailto:[168]pasik@iki.fi > > 63. [169]http://kernel.org/ > > 64. [170]http://kernel.org/ > > 65. mailto:[171]Xen-devel@lists.xen.org > > 66. [172]http://lists.xen.org/xen-devel > > 67. mailto:[173]pasik@iki.fi > > 68. mailto:[174]pasik@iki.fi > > 69. [175]http://kernel.org/ > > 70. [176]http://kernel.org/ > > 71. mailto:[177]Xen-devel@lists.xen.org > > 72. [178]http://lists.xen.org/xen-devel > > 73. mailto:[179]pasik@iki.fi > > 74. [180]http://kernel.org/ > > 75. [181]http://kernel.org/ > > 76. mailto:[182]Xen-devel@lists.xen.org > > 77. [183]http://lists.xen.org/xen-devel > > 78. mailto:[184]pasik@iki.fi > > 79. mailto:[185]pasik@iki.fi > > 80. mailto:[186]pasik@iki.fi > > 81. [187]http://kernel.org/ > > 82. [188]http://kernel.org/ > > 83. mailto:[189]Xen-devel@lists.xen.org > > 84. [190]http://lists.xen.org/xen-devel > > 85. mailto:[191]pasik@iki.fi > > 86. [192]http://kernel.org/ > > 87. [193]http://kernel.org/ > > 88. mailto:[194]Xen-devel@lists.xen.org > > 89. [195]http://lists.xen.org/xen-devel > > 90. mailto:[196]pasik@iki.fi > > 91. mailto:[197]pasik@iki.fi > > 92. [198]http://kernel.org/ > > 93. [199]http://kernel.org/ > > 94. mailto:[200]Xen-devel@lists.xen.org > > 95. [201]http://lists.xen.org/xen-devel > > 96. mailto:[202]pasik@iki.fi > > 97. [203]http://kernel.org/ > > 98. [204]http://kernel.org/ > > 99. mailto:[205]Xen-devel@lists.xen.org > > 100. [206]http://lists.xen.org/xen-devel > = > References > = > Visible links > 1. http://nago.fi/dmesg.txt > 2. http://nago.fi/qemu-dm.txt > 3. http://nago.fi/xm-dmesg.txt > 4. http://nago.fi/domu-config.txt > 5. http://nago.fi/dom0-config.txt > 6. mailto:pasik@iki.fi > 7. mailto:kiviniemi.valtteri@gmail.com > 8. http://ark.intel.com/products/65719/ > 9. http://www.intel.com/content/www/us/en/motherboards/desktop-motherb= oards/desktop-board-dq77mk.html > 10. mailto:root@dataproof.fi > 11. mailto:pasik@iki.fi > 12. http://xen.org/ > 13. mailto:pasik@iki.fi > 14. mailto:pasik@iki.fi > 15. mailto:pasik@iki.fi > 16. mailto:pasik@iki.fi > 17. http://kernel.org/ > 18. http://kernel.org/ > 19. mailto:Xen-devel@lists.xen.org > 20. http://lists.xen.org/xen-devel > 21. mailto:pasik@iki.fi > 22. http://kernel.org/ > 23. http://kernel.org/ > 24. mailto:Xen-devel@lists.xen.org > 25. http://lists.xen.org/xen-devel > 26. mailto:pasik@iki.fi > 27. mailto:pasik@iki.fi > 28. http://kernel.org/ > 29. http://kernel.org/ > 30. mailto:Xen-devel@lists.xen.org > 31. http://lists.xen.org/xen-devel > 32. mailto:pasik@iki.fi > 33. http://kernel.org/ > 34. http://kernel.org/ > 35. mailto:Xen-devel@lists.xen.org > 36. http://lists.xen.org/xen-devel > 37. mailto:pasik@iki.fi > 38. mailto:pasik@iki.fi > 39. mailto:pasik@iki.fi > 40. http://kernel.org/ > 41. http://kernel.org/ > 42. mailto:Xen-devel@lists.xen.org > 43. http://lists.xen.org/xen-devel > 44. mailto:pasik@iki.fi > 45. http://kernel.org/ > 46. http://kernel.org/ > 47. mailto:Xen-devel@lists.xen.org > 48. http://lists.xen.org/xen-devel > 49. mailto:pasik@iki.fi > 50. mailto:pasik@iki.fi > 51. http://kernel.org/ > 52. http://kernel.org/ > 53. mailto:Xen-devel@lists.xen.org > 54. http://lists.xen.org/xen-devel > 55. mailto:pasik@iki.fi > 56. http://kernel.org/ > 57. http://kernel.org/ > 58. mailto:Xen-devel@lists.xen.org > 59. http://lists.xen.org/xen-devel > 60. mailto:pasik@iki.fi > 61. mailto:pasik@iki.fi > 62. mailto:pasik@iki.fi > 63. mailto:pasik@iki.fi > 64. http://kernel.org/ > 65. http://kernel.org/ > 66. mailto:Xen-devel@lists.xen.org > 67. http://lists.xen.org/xen-devel > 68. mailto:pasik@iki.fi > 69. http://kernel.org/ > 70. http://kernel.org/ > 71. mailto:Xen-devel@lists.xen.org > 72. http://lists.xen.org/xen-devel > 73. mailto:pasik@iki.fi > 74. mailto:pasik@iki.fi > 75. http://kernel.org/ > 76. http://kernel.org/ > 77. mailto:Xen-devel@lists.xen.org > 78. http://lists.xen.org/xen-devel > 79. mailto:pasik@iki.fi > 80. http://kernel.org/ > 81. http://kernel.org/ > 82. mailto:Xen-devel@lists.xen.org > 83. http://lists.xen.org/xen-devel > 84. mailto:pasik@iki.fi > 85. mailto:pasik@iki.fi > 86. mailto:pasik@iki.fi > 87. http://kernel.org/ > 88. http://kernel.org/ > 89. mailto:Xen-devel@lists.xen.org > 90. http://lists.xen.org/xen-devel > 91. mailto:pasik@iki.fi > 92. http://kernel.org/ > 93. http://kernel.org/ > 94. mailto:Xen-devel@lists.xen.org > 95. http://lists.xen.org/xen-devel > 96. mailto:pasik@iki.fi > 97. mailto:pasik@iki.fi > 98. http://kernel.org/ > 99. http://kernel.org/ > 100. mailto:Xen-devel@lists.xen.org > 101. http://lists.xen.org/xen-devel > 102. mailto:pasik@iki.fi > 103. http://kernel.org/ > 104. http://kernel.org/ > 105. mailto:Xen-devel@lists.xen.org > 106. http://lists.xen.org/xen-devel > 107. mailto:kiviniemi.valtteri@gmail.com > 108. http://ark.intel.com/products/65719/ > 109. http://www.intel.com/content/www/us/en/motherboards/desktop-motherb= oards/desktop-board-dq77mk.html > 110. mailto:root@dataproof.fi > 111. mailto:pasik@iki.fi > 112. http://xen.org/ > 113. mailto:pasik@iki.fi > 114. mailto:pasik@iki.fi > 115. mailto:pasik@iki.fi > 116. mailto:pasik@iki.fi > 117. http://kernel.org/ > 118. http://kernel.org/ > 119. mailto:Xen-devel@lists.xen.org > 120. http://lists.xen.org/xen-devel > 121. mailto:pasik@iki.fi > 122. http://kernel.org/ > 123. http://kernel.org/ > 124. mailto:Xen-devel@lists.xen.org > 125. http://lists.xen.org/xen-devel > 126. mailto:pasik@iki.fi > 127. mailto:pasik@iki.fi > 128. http://kernel.org/ > 129. http://kernel.org/ > 130. mailto:Xen-devel@lists.xen.org > 131. http://lists.xen.org/xen-devel > 132. mailto:pasik@iki.fi > 133. http://kernel.org/ > 134. http://kernel.org/ > 135. mailto:Xen-devel@lists.xen.org > 136. http://lists.xen.org/xen-devel > 137. mailto:pasik@iki.fi > 138. mailto:pasik@iki.fi > 139. mailto:pasik@iki.fi > 140. http://kernel.org/ > 141. http://kernel.org/ > 142. mailto:Xen-devel@lists.xen.org > 143. http://lists.xen.org/xen-devel > 144. mailto:pasik@iki.fi > 145. http://kernel.org/ > 146. http://kernel.org/ > 147. mailto:Xen-devel@lists.xen.org > 148. http://lists.xen.org/xen-devel > 149. mailto:pasik@iki.fi > 150. mailto:pasik@iki.fi > 151. http://kernel.org/ > 152. http://kernel.org/ > 153. mailto:Xen-devel@lists.xen.org > 154. http://lists.xen.org/xen-devel > 155. mailto:pasik@iki.fi > 156. http://kernel.org/ > 157. http://kernel.org/ > 158. mailto:Xen-devel@lists.xen.org > 159. http://lists.xen.org/xen-devel > 160. mailto:pasik@iki.fi > 161. mailto:pasik@iki.fi > 162. mailto:pasik@iki.fi > 163. mailto:pasik@iki.fi > 164. http://kernel.org/ > 165. http://kernel.org/ > 166. mailto:Xen-devel@lists.xen.org > 167. http://lists.xen.org/xen-devel > 168. mailto:pasik@iki.fi > 169. http://kernel.org/ > 170. http://kernel.org/ > 171. mailto:Xen-devel@lists.xen.org > 172. http://lists.xen.org/xen-devel > 173. mailto:pasik@iki.fi > 174. mailto:pasik@iki.fi > 175. http://kernel.org/ > 176. http://kernel.org/ > 177. mailto:Xen-devel@lists.xen.org > 178. http://lists.xen.org/xen-devel > 179. mailto:pasik@iki.fi > 180. http://kernel.org/ > 181. http://kernel.org/ > 182. mailto:Xen-devel@lists.xen.org > 183. http://lists.xen.org/xen-devel > 184. mailto:pasik@iki.fi > 185. mailto:pasik@iki.fi > 186. mailto:pasik@iki.fi > 187. http://kernel.org/ > 188. http://kernel.org/ > 189. mailto:Xen-devel@lists.xen.org > 190. http://lists.xen.org/xen-devel > 191. mailto:pasik@iki.fi > 192. http://kernel.org/ > 193. http://kernel.org/ > 194. mailto:Xen-devel@lists.xen.org > 195. http://lists.xen.org/xen-devel > 196. mailto:pasik@iki.fi > 197. mailto:pasik@iki.fi > 198. http://kernel.org/ > 199. http://kernel.org/ > 200. mailto:Xen-devel@lists.xen.org > 201. http://lists.xen.org/xen-devel > 202. mailto:pasik@iki.fi > 203. http://kernel.org/ > 204. http://kernel.org/ > 205. mailto:Xen-devel@lists.xen.org > 206. http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 13:16:30 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 13:16:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ2KF-00022F-R6; Tue, 02 Oct 2012 13:15:51 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ2KF-000227-37 for Xen-devel@lists.xensource.com; Tue, 02 Oct 2012 13:15:51 +0000 Received: from [85.158.139.83:56336] by server-8.bemta-5.messagelabs.com id 67/C6-18073-509EA605; Tue, 02 Oct 2012 13:15:49 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1349183748!28531346!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc4Nzc1OQ==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27881 invoked from network); 2 Oct 2012 13:15:49 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 13:15:49 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q92DFcX4000738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Oct 2012 13:15:38 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q92DFaC4005592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Oct 2012 13:15:37 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q92DFax1016672; Tue, 2 Oct 2012 08:15:36 -0500 Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 02 Oct 2012 06:15:36 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 7DC8D4032D; Tue, 2 Oct 2012 09:04:11 -0400 (EDT) Date: Tue, 2 Oct 2012 09:04:11 -0400 From: Konrad Rzeszutek Wilk To: Stefano Stabellini Message-ID: <20121002130411.GC9009@phenom.dumpdata.com> References: <20120921121511.30001c08@mantra.us.oracle.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "Xen-devel@lists.xensource.com" , Ian Campbell Subject: Re: [Xen-devel] [PATCH v1 1/8]: PVH basic and hader file changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org The title says ' hader' - it should say 'header'. Also there is a missing description of what it does, and how this works. For an example check out: f4cec35b0d4b90d96e3770a3d1e68ea882e7a7c8 (which added the 1-1 P2M notion), or: 357a3cfb147ee8e97c6f9cdc51e9a33aa56f7d99 (for the > 128gb support). It needs to be verbose with lots of details. On Tue, Oct 02, 2012 at 11:48:13AM +0100, Stefano Stabellini wrote: > On Fri, 21 Sep 2012, Mukesh Rathor wrote: > > --- > > arch/x86/include/asm/xen/interface.h | 8 +++++++- > > arch/x86/include/asm/xen/page.h | 3 +++ > > arch/x86/xen/irq.c | 5 ++++- > > arch/x86/xen/p2m.c | 2 +- > > drivers/xen/cpu_hotplug.c | 4 +++- > > drivers/xen/events.c | 12 ++++++++---- > > drivers/xen/xenbus/xenbus_client.c | 2 +- > > drivers/xen/xenbus/xenbus_probe.c | 6 +++++- > > include/xen/interface/memory.h | 27 +++++++++++++++++++++++++++ > > include/xen/interface/physdev.h | 10 ++++++++++ > > 10 files changed, 69 insertions(+), 10 deletions(-) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 13:16:30 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 13:16:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ2KF-00022F-R6; Tue, 02 Oct 2012 13:15:51 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ2KF-000227-37 for Xen-devel@lists.xensource.com; Tue, 02 Oct 2012 13:15:51 +0000 Received: from [85.158.139.83:56336] by server-8.bemta-5.messagelabs.com id 67/C6-18073-509EA605; Tue, 02 Oct 2012 13:15:49 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1349183748!28531346!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc4Nzc1OQ==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27881 invoked from network); 2 Oct 2012 13:15:49 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 13:15:49 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q92DFcX4000738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Oct 2012 13:15:38 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q92DFaC4005592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Oct 2012 13:15:37 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q92DFax1016672; Tue, 2 Oct 2012 08:15:36 -0500 Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 02 Oct 2012 06:15:36 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 7DC8D4032D; Tue, 2 Oct 2012 09:04:11 -0400 (EDT) Date: Tue, 2 Oct 2012 09:04:11 -0400 From: Konrad Rzeszutek Wilk To: Stefano Stabellini Message-ID: <20121002130411.GC9009@phenom.dumpdata.com> References: <20120921121511.30001c08@mantra.us.oracle.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "Xen-devel@lists.xensource.com" , Ian Campbell Subject: Re: [Xen-devel] [PATCH v1 1/8]: PVH basic and hader file changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org The title says ' hader' - it should say 'header'. Also there is a missing description of what it does, and how this works. For an example check out: f4cec35b0d4b90d96e3770a3d1e68ea882e7a7c8 (which added the 1-1 P2M notion), or: 357a3cfb147ee8e97c6f9cdc51e9a33aa56f7d99 (for the > 128gb support). It needs to be verbose with lots of details. On Tue, Oct 02, 2012 at 11:48:13AM +0100, Stefano Stabellini wrote: > On Fri, 21 Sep 2012, Mukesh Rathor wrote: > > --- > > arch/x86/include/asm/xen/interface.h | 8 +++++++- > > arch/x86/include/asm/xen/page.h | 3 +++ > > arch/x86/xen/irq.c | 5 ++++- > > arch/x86/xen/p2m.c | 2 +- > > drivers/xen/cpu_hotplug.c | 4 +++- > > drivers/xen/events.c | 12 ++++++++---- > > drivers/xen/xenbus/xenbus_client.c | 2 +- > > drivers/xen/xenbus/xenbus_probe.c | 6 +++++- > > include/xen/interface/memory.h | 27 +++++++++++++++++++++++++++ > > include/xen/interface/physdev.h | 10 ++++++++++ > > 10 files changed, 69 insertions(+), 10 deletions(-) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 13:21:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 13:21:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ2P5-0002FR-IH; Tue, 02 Oct 2012 13:20:51 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ2P4-0002FL-KX for Xen-devel@lists.xensource.com; Tue, 02 Oct 2012 13:20:50 +0000 Received: from [85.158.139.211:55715] by server-1.bemta-5.messagelabs.com id B8/34-09825-13AEA605; Tue, 02 Oct 2012 13:20:49 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-14.tower-206.messagelabs.com!1349184047!20713198!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzc3NzIy\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11949 invoked from network); 2 Oct 2012 13:20:49 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 13:20:49 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q92DKbG4006923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Oct 2012 13:20:38 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q92DKaHN014377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Oct 2012 13:20:37 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q92DKaPC020329; Tue, 2 Oct 2012 08:20:36 -0500 Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 02 Oct 2012 06:20:36 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 87EBB4032D; Tue, 2 Oct 2012 09:09:11 -0400 (EDT) Date: Tue, 2 Oct 2012 09:09:11 -0400 From: Konrad Rzeszutek Wilk To: Mukesh Rathor Message-ID: <20121002130911.GD9009@phenom.dumpdata.com> References: <20120921121202.3163c379@mantra.us.oracle.com> <1348581263.11229.21.camel@zakaz.uk.xensource.com> <20121001142826.1ebf7b0f@mantra.us.oracle.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20121001142826.1ebf7b0f@mantra.us.oracle.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "Xen-devel@lists.xensource.com" , Ian Campbell , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v1 0/8]: PVH (PV guest with extensions) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, Oct 01, 2012 at 02:28:26PM -0700, Mukesh Rathor wrote: > On Tue, 25 Sep 2012 14:54:23 +0100 > Ian Campbell wrote: > > > On Fri, 2012-09-21 at 20:12 +0100, Mukesh Rathor wrote: > > > Hi guys, > > > > > > Ok, I've made all the changes from prev RFC patch submission. > > > > Did I miss the patch with the changes to arch/x86/xen/xen-head.S which > > declare the features which are used here as supported by the kernel > > image? > > > > Ian. > > > > Strange, adding following to head.S > > ELFNOTE(Xen, XEN_ELFNOTE_PADDR_OFFSET, _ASM_PTR 0) > ELFNOTE(Xen, XEN_ELFNOTE_GUEST_PVH, .long 1) <-------- > > and xenstore won't start in dom0. What gives? What is XEN_ELFNOTE_GUEST_PVH number? You might be re-using a value that is defined for a different purpose? Did you check the Xen hypervisor header files? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 13:21:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 13:21:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ2P5-0002FR-IH; Tue, 02 Oct 2012 13:20:51 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ2P4-0002FL-KX for Xen-devel@lists.xensource.com; Tue, 02 Oct 2012 13:20:50 +0000 Received: from [85.158.139.211:55715] by server-1.bemta-5.messagelabs.com id B8/34-09825-13AEA605; Tue, 02 Oct 2012 13:20:49 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-14.tower-206.messagelabs.com!1349184047!20713198!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzc3NzIy\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11949 invoked from network); 2 Oct 2012 13:20:49 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 13:20:49 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q92DKbG4006923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Oct 2012 13:20:38 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q92DKaHN014377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Oct 2012 13:20:37 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q92DKaPC020329; Tue, 2 Oct 2012 08:20:36 -0500 Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 02 Oct 2012 06:20:36 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 87EBB4032D; Tue, 2 Oct 2012 09:09:11 -0400 (EDT) Date: Tue, 2 Oct 2012 09:09:11 -0400 From: Konrad Rzeszutek Wilk To: Mukesh Rathor Message-ID: <20121002130911.GD9009@phenom.dumpdata.com> References: <20120921121202.3163c379@mantra.us.oracle.com> <1348581263.11229.21.camel@zakaz.uk.xensource.com> <20121001142826.1ebf7b0f@mantra.us.oracle.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20121001142826.1ebf7b0f@mantra.us.oracle.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "Xen-devel@lists.xensource.com" , Ian Campbell , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v1 0/8]: PVH (PV guest with extensions) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, Oct 01, 2012 at 02:28:26PM -0700, Mukesh Rathor wrote: > On Tue, 25 Sep 2012 14:54:23 +0100 > Ian Campbell wrote: > > > On Fri, 2012-09-21 at 20:12 +0100, Mukesh Rathor wrote: > > > Hi guys, > > > > > > Ok, I've made all the changes from prev RFC patch submission. > > > > Did I miss the patch with the changes to arch/x86/xen/xen-head.S which > > declare the features which are used here as supported by the kernel > > image? > > > > Ian. > > > > Strange, adding following to head.S > > ELFNOTE(Xen, XEN_ELFNOTE_PADDR_OFFSET, _ASM_PTR 0) > ELFNOTE(Xen, XEN_ELFNOTE_GUEST_PVH, .long 1) <-------- > > and xenstore won't start in dom0. What gives? What is XEN_ELFNOTE_GUEST_PVH number? You might be re-using a value that is defined for a different purpose? Did you check the Xen hypervisor header files? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 13:33:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 13:33:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ2av-0002Qz-Qg; Tue, 02 Oct 2012 13:33:05 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ2au-0002Qa-8q; Tue, 02 Oct 2012 13:33:04 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1349184772!5487440!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7977 invoked from network); 2 Oct 2012 13:32:52 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 13:32:52 -0000 X-IronPort-AV: E=Sophos;i="4.80,523,1344211200"; d="scan'208";a="14893926" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 13:32:49 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 14:32:49 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TJ2af-0001DC-3P; Tue, 02 Oct 2012 13:32:49 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TJ2ae-0005v6-VT; Tue, 02 Oct 2012 14:32:48 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20586.60672.682384.549818@mariner.uk.xensource.com> Date: Tue, 2 Oct 2012 14:32:48 +0100 To: "Teo En Ming (Zhang Enming)" Newsgroups: chiark.mail.xen.devel In-Reply-To: References: <506AAF6D.4060409@gmail.com> <506AB739.6030705@laukamp.me> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: "xen-users@lists.xen.org" , "xen-devel@lists.xen.org" , Lukas Laukamp Subject: Re: [Xen-devel] [Xen-users] Xen 4.2.0 does not have the file passthrough.c X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Teo En Ming (Zhang Enming) writes ("Re: [Xen-devel] [Xen-users] Xen 4.2.0 does not have the file passthrough.c"): > I was trying to patch the file pass-through.c when the patch file > complained that pass-through.c cannot be found, meaning that Xen 4.2.0 > does not support VGA passthrough. You are wrong. $ tar zvvtf xen-4.2.0.tar.gz | fgrep pass-through.c | wc -l 1 $ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 13:33:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 13:33:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ2av-0002Qz-Qg; Tue, 02 Oct 2012 13:33:05 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ2au-0002Qa-8q; Tue, 02 Oct 2012 13:33:04 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1349184772!5487440!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7977 invoked from network); 2 Oct 2012 13:32:52 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 13:32:52 -0000 X-IronPort-AV: E=Sophos;i="4.80,523,1344211200"; d="scan'208";a="14893926" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 13:32:49 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 14:32:49 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TJ2af-0001DC-3P; Tue, 02 Oct 2012 13:32:49 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TJ2ae-0005v6-VT; Tue, 02 Oct 2012 14:32:48 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20586.60672.682384.549818@mariner.uk.xensource.com> Date: Tue, 2 Oct 2012 14:32:48 +0100 To: "Teo En Ming (Zhang Enming)" Newsgroups: chiark.mail.xen.devel In-Reply-To: References: <506AAF6D.4060409@gmail.com> <506AB739.6030705@laukamp.me> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: "xen-users@lists.xen.org" , "xen-devel@lists.xen.org" , Lukas Laukamp Subject: Re: [Xen-devel] [Xen-users] Xen 4.2.0 does not have the file passthrough.c X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Teo En Ming (Zhang Enming) writes ("Re: [Xen-devel] [Xen-users] Xen 4.2.0 does not have the file passthrough.c"): > I was trying to patch the file pass-through.c when the patch file > complained that pass-through.c cannot be found, meaning that Xen 4.2.0 > does not support VGA passthrough. You are wrong. $ tar zvvtf xen-4.2.0.tar.gz | fgrep pass-through.c | wc -l 1 $ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 13:35:17 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 13:35:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ2co-0002cw-0C; Tue, 02 Oct 2012 13:35:02 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ2cm-0002cg-3b for xen-devel@lists.xen.org; Tue, 02 Oct 2012 13:35:00 +0000 Received: from [85.158.139.83:14805] by server-10.bemta-5.messagelabs.com id D8/87-16911-38DEA605; Tue, 02 Oct 2012 13:34:59 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1349184898!32887165!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7109 invoked from network); 2 Oct 2012 13:34:58 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 13:34:58 -0000 X-IronPort-AV: E=Sophos;i="4.80,523,1344211200"; d="scan'208";a="14893978" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 13:34:23 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 14:34:23 +0100 Message-ID: <1349184862.650.52.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Matthew Fioravante Date: Tue, 2 Oct 2012 14:34:22 +0100 In-Reply-To: <1348765860-11359-1-git-send-email-matthew.fioravante@jhuapl.edu> References: <1348765860-11359-1-git-send-email-matthew.fioravante@jhuapl.edu> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 09/11] add iomem support to libxl X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-09-27 at 18:10 +0100, Matthew Fioravante wrote: > This patch adds a new option for xen config files for > directly mapping hardware io memory into a vm. > > Signed-off-by: Matthew Fioravante > > diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5 > index 013270d..428da21 100644 > --- a/docs/man/xl.cfg.pod.5 > +++ b/docs/man/xl.cfg.pod.5 > @@ -496,6 +496,17 @@ is given in hexadecimal and may either a span e.g. C<2f8-2ff> > It is recommended to use this option only for trusted VMs under > administrator control. > > +=item B > + > +Allow guest to access specific hardware I/O memory pages. B > +is a physical page number. B is the number > +of pages beginning with B to allow access. Both values > +must be given in hexadecimal. > + > +It is recommended to use this option only for trusted VMs under > +administrator control. > + > + > =item B > > Allow a guest to access specific physical IRQs. > diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c > index ef17f05..6cb586b 100644 > --- a/tools/libxl/libxl_create.c > +++ b/tools/libxl/libxl_create.c > @@ -963,6 +963,24 @@ static void domcreate_launch_dm(libxl__egc *egc, libxl__multidev *multidev, > } > } > > + for (i = 0; i < d_config->b_info.num_iomem; i++) { > + libxl_iomem_range *io = &d_config->b_info.iomem[i]; > + > + LOG(DEBUG, "dom%d iomem %"PRIx64"-%"PRIx64, > + domid, io->start, io->start + io->number - 1); > + > + ret = xc_domain_iomem_permission(CTX->xch, domid, > + io->start, io->number, 1); > + if ( ret<0 ) { This should be if (ret < 0) { > + LOGE(ERROR, > + "failed give dom%d access to iomem range %"PRIx64"-%"PRIx64, > + domid, io->start, io->start + io->number - 1); > + ret = ERROR_FAIL; > + } > + } > + > + > + > for (i = 0; i < d_config->num_nics; i++) { > /* We have to init the nic here, because we still haven't > * called libxl_device_nic_add at this point, but qemu needs > diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl > index 6d5c578..cf83c60 100644 > --- a/tools/libxl/libxl_types.idl > +++ b/tools/libxl/libxl_types.idl > @@ -140,6 +140,11 @@ libxl_ioport_range = Struct("ioport_range", [ > ("number", uint32), > ]) > > +libxl_iomem_range = Struct("iomem_range", [ > + ("start", uint64), > + ("number", uint64), > + ]) > + > libxl_vga_interface_info = Struct("vga_interface_info", [ > ("kind", libxl_vga_interface_type), > ]) > @@ -284,6 +289,7 @@ libxl_domain_build_info = Struct("domain_build_info",[ > > ("ioports", Array(libxl_ioport_range, "num_ioports")), > ("irqs", Array(uint32, "num_irqs")), > + ("iomem", Array(libxl_iomem_range, "num_iomem")), > > ("u", KeyedUnion(None, libxl_domain_type, "type", > [("hvm", Struct(None, [("firmware", string), > diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c > index 1627cac..fe8e925 100644 > --- a/tools/libxl/xl_cmdimpl.c > +++ b/tools/libxl/xl_cmdimpl.c > @@ -574,8 +574,8 @@ static void parse_config_data(const char *config_source, > long l; > XLU_Config *config; > XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids; > - XLU_ConfigList *ioports, *irqs; > - int num_ioports, num_irqs; > + XLU_ConfigList *ioports, *irqs, *iomem; > + int num_ioports, num_irqs, num_iomem; > int pci_power_mgmt = 0; > int pci_msitranslate = 0; > int pci_permissive = 0; > @@ -1005,6 +1005,30 @@ static void parse_config_data(const char *config_source, > } > } > > + if (!xlu_cfg_get_list(config, "iomem", &iomem, &num_iomem, 0)) { > + b_info->num_iomem = num_iomem; > + b_info->iomem = calloc(num_iomem, sizeof(*b_info->iomem)); > + if (b_info->iomem == NULL) { > + fprintf(stderr, "unable to allocate memory for iomem\n"); > + exit(-1); > + } > + for (i = 0; i < num_iomem; i++) { > + buf = xlu_cfg_get_listitem (iomem, i); > + if (!buf) { > + fprintf(stderr, > + "xl: Unable to get element %d in iomem list\n", i); > + exit(1); > + } > + if(sscanf(buf, "%" SCNx64",%" SCNx64, &b_info->iomem[i].start, &b_info->iomem[i].number) != 2) { Can we split this over multiple lines please, to keep it under the 75-80 column limit mention in coding style. > + fprintf(stderr, > + "xl: Invalid argument parsing iomem: %s\n", buf); > + exit(1); > + } > + } > + } > + > + > + > if (!xlu_cfg_get_list (config, "disk", &vbds, 0, 0)) { > d_config->num_disks = 0; > d_config->disks = NULL; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 13:35:17 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 13:35:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ2co-0002cw-0C; Tue, 02 Oct 2012 13:35:02 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ2cm-0002cg-3b for xen-devel@lists.xen.org; Tue, 02 Oct 2012 13:35:00 +0000 Received: from [85.158.139.83:14805] by server-10.bemta-5.messagelabs.com id D8/87-16911-38DEA605; Tue, 02 Oct 2012 13:34:59 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1349184898!32887165!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7109 invoked from network); 2 Oct 2012 13:34:58 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 13:34:58 -0000 X-IronPort-AV: E=Sophos;i="4.80,523,1344211200"; d="scan'208";a="14893978" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 13:34:23 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 14:34:23 +0100 Message-ID: <1349184862.650.52.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Matthew Fioravante Date: Tue, 2 Oct 2012 14:34:22 +0100 In-Reply-To: <1348765860-11359-1-git-send-email-matthew.fioravante@jhuapl.edu> References: <1348765860-11359-1-git-send-email-matthew.fioravante@jhuapl.edu> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 09/11] add iomem support to libxl X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-09-27 at 18:10 +0100, Matthew Fioravante wrote: > This patch adds a new option for xen config files for > directly mapping hardware io memory into a vm. > > Signed-off-by: Matthew Fioravante > > diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5 > index 013270d..428da21 100644 > --- a/docs/man/xl.cfg.pod.5 > +++ b/docs/man/xl.cfg.pod.5 > @@ -496,6 +496,17 @@ is given in hexadecimal and may either a span e.g. C<2f8-2ff> > It is recommended to use this option only for trusted VMs under > administrator control. > > +=item B > + > +Allow guest to access specific hardware I/O memory pages. B > +is a physical page number. B is the number > +of pages beginning with B to allow access. Both values > +must be given in hexadecimal. > + > +It is recommended to use this option only for trusted VMs under > +administrator control. > + > + > =item B > > Allow a guest to access specific physical IRQs. > diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c > index ef17f05..6cb586b 100644 > --- a/tools/libxl/libxl_create.c > +++ b/tools/libxl/libxl_create.c > @@ -963,6 +963,24 @@ static void domcreate_launch_dm(libxl__egc *egc, libxl__multidev *multidev, > } > } > > + for (i = 0; i < d_config->b_info.num_iomem; i++) { > + libxl_iomem_range *io = &d_config->b_info.iomem[i]; > + > + LOG(DEBUG, "dom%d iomem %"PRIx64"-%"PRIx64, > + domid, io->start, io->start + io->number - 1); > + > + ret = xc_domain_iomem_permission(CTX->xch, domid, > + io->start, io->number, 1); > + if ( ret<0 ) { This should be if (ret < 0) { > + LOGE(ERROR, > + "failed give dom%d access to iomem range %"PRIx64"-%"PRIx64, > + domid, io->start, io->start + io->number - 1); > + ret = ERROR_FAIL; > + } > + } > + > + > + > for (i = 0; i < d_config->num_nics; i++) { > /* We have to init the nic here, because we still haven't > * called libxl_device_nic_add at this point, but qemu needs > diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl > index 6d5c578..cf83c60 100644 > --- a/tools/libxl/libxl_types.idl > +++ b/tools/libxl/libxl_types.idl > @@ -140,6 +140,11 @@ libxl_ioport_range = Struct("ioport_range", [ > ("number", uint32), > ]) > > +libxl_iomem_range = Struct("iomem_range", [ > + ("start", uint64), > + ("number", uint64), > + ]) > + > libxl_vga_interface_info = Struct("vga_interface_info", [ > ("kind", libxl_vga_interface_type), > ]) > @@ -284,6 +289,7 @@ libxl_domain_build_info = Struct("domain_build_info",[ > > ("ioports", Array(libxl_ioport_range, "num_ioports")), > ("irqs", Array(uint32, "num_irqs")), > + ("iomem", Array(libxl_iomem_range, "num_iomem")), > > ("u", KeyedUnion(None, libxl_domain_type, "type", > [("hvm", Struct(None, [("firmware", string), > diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c > index 1627cac..fe8e925 100644 > --- a/tools/libxl/xl_cmdimpl.c > +++ b/tools/libxl/xl_cmdimpl.c > @@ -574,8 +574,8 @@ static void parse_config_data(const char *config_source, > long l; > XLU_Config *config; > XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids; > - XLU_ConfigList *ioports, *irqs; > - int num_ioports, num_irqs; > + XLU_ConfigList *ioports, *irqs, *iomem; > + int num_ioports, num_irqs, num_iomem; > int pci_power_mgmt = 0; > int pci_msitranslate = 0; > int pci_permissive = 0; > @@ -1005,6 +1005,30 @@ static void parse_config_data(const char *config_source, > } > } > > + if (!xlu_cfg_get_list(config, "iomem", &iomem, &num_iomem, 0)) { > + b_info->num_iomem = num_iomem; > + b_info->iomem = calloc(num_iomem, sizeof(*b_info->iomem)); > + if (b_info->iomem == NULL) { > + fprintf(stderr, "unable to allocate memory for iomem\n"); > + exit(-1); > + } > + for (i = 0; i < num_iomem; i++) { > + buf = xlu_cfg_get_listitem (iomem, i); > + if (!buf) { > + fprintf(stderr, > + "xl: Unable to get element %d in iomem list\n", i); > + exit(1); > + } > + if(sscanf(buf, "%" SCNx64",%" SCNx64, &b_info->iomem[i].start, &b_info->iomem[i].number) != 2) { Can we split this over multiple lines please, to keep it under the 75-80 column limit mention in coding style. > + fprintf(stderr, > + "xl: Invalid argument parsing iomem: %s\n", buf); > + exit(1); > + } > + } > + } > + > + > + > if (!xlu_cfg_get_list (config, "disk", &vbds, 0, 0)) { > d_config->num_disks = 0; > d_config->disks = NULL; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 13:36:56 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 13:36:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ2eO-0002oK-GJ; Tue, 02 Oct 2012 13:36:40 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ2eM-0002o5-MW for xen-devel@lists.xen.org; Tue, 02 Oct 2012 13:36:38 +0000 Received: from [85.158.139.83:59821] by server-7.bemta-5.messagelabs.com id 20/A2-00431-5EDEA605; Tue, 02 Oct 2012 13:36:37 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-16.tower-182.messagelabs.com!1349184997!25728037!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23018 invoked from network); 2 Oct 2012 13:36:37 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 13:36:37 -0000 X-IronPort-AV: E=Sophos;i="4.80,523,1344211200"; d="scan'208";a="14894038" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 13:36:37 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 14:36:37 +0100 Message-ID: <1349184995.650.54.camel@zakaz.uk.xensource.com> From: Ian Campbell To: George Dunlap Date: Tue, 2 Oct 2012 14:36:35 +0100 In-Reply-To: References: <1348765860-11359-1-git-send-email-matthew.fioravante@jhuapl.edu> <1348765860-11359-2-git-send-email-matthew.fioravante@jhuapl.edu> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: Matthew Fioravante , Ian Jackson , Jan Beulich , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 10/11] make devid a type so it is initialized properly X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-09-28 at 14:23 +0100, George Dunlap wrote: > On Thu, Sep 27, 2012 at 6:10 PM, Matthew Fioravante > wrote: > > Previously device ids in libxl were treated as integers meaning they > > were being initialized to 0, which is a valid device id. This patch > > makes devid its own type in libxl and initializes it to -1, an invalid > > value. > > > > This fixes a bug where if you try to do a xl DEV-attach multiple > > time it will continuously try to reattach device 0 instead of > > generating a new device id. > > > > Signed-off-by: Matthew Fioravante > > Reviewed-by: George Dunlap Acked-by: Ian Campbell > Should this be backported to 4.2-testing? That's a good question. I think it is basically a bugfix to the API and since basically the only way to correctly use the current interface is for the application to always initialise that field changing the initial value seems harmless from a backwards compat PoV. Ian. > > -George > > > > > diff --git a/tools/libxl/gentest.py b/tools/libxl/gentest.py > > index 2915f71..84b4fd7 100644 > > --- a/tools/libxl/gentest.py > > +++ b/tools/libxl/gentest.py > > @@ -60,7 +60,7 @@ def gen_rand_init(ty, v, indent = " ", parent = None): > > passby=idl.PASS_BY_REFERENCE)) > > elif ty.typename in ["libxl_uuid", "libxl_mac", "libxl_hwcap"]: > > s += "rand_bytes((uint8_t *)%s, sizeof(*%s));\n" % (v,v) > > - elif ty.typename in ["libxl_domid"] or isinstance(ty, idl.Number): > > + elif ty.typename in ["libxl_domid", "libxl_devid"] or isinstance(ty, idl.Number): > > s += "%s = rand() %% (sizeof(%s)*8);\n" % \ > > (ty.pass_arg(v, parent is None), > > ty.pass_arg(v, parent is None)) > > diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h > > index 599c7f1..7a7c419 100644 > > --- a/tools/libxl/libxl.h > > +++ b/tools/libxl/libxl.h > > @@ -307,6 +307,7 @@ void libxl_cpuid_dispose(libxl_cpuid_policy_list *cpuid_list); > > #define LIBXL_PCI_FUNC_ALL (~0U) > > > > typedef uint32_t libxl_domid; > > +typedef int libxl_devid; > > > > /* > > * Formatting Enumerations. > > diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl > > index cf83c60..de111a6 100644 > > --- a/tools/libxl/libxl_types.idl > > +++ b/tools/libxl/libxl_types.idl > > @@ -8,6 +8,7 @@ namespace("libxl_") > > libxl_defbool = Builtin("defbool", passby=PASS_BY_REFERENCE) > > > > libxl_domid = Builtin("domid", json_fn = "yajl_gen_integer", autogenerate_json = False) > > +libxl_devid = Builtin("devid", json_fn = "yajl_gen_integer", autogenerate_json = False, signed = True, init_val="-1") > > libxl_uuid = Builtin("uuid", passby=PASS_BY_REFERENCE) > > libxl_mac = Builtin("mac", passby=PASS_BY_REFERENCE) > > libxl_bitmap = Builtin("bitmap", dispose_fn="libxl_bitmap_dispose", passby=PASS_BY_REFERENCE) > > @@ -343,7 +344,7 @@ libxl_domain_build_info = Struct("domain_build_info",[ > > > > libxl_device_vfb = Struct("device_vfb", [ > > ("backend_domid", libxl_domid), > > - ("devid", integer), > > + ("devid", libxl_devid), > > ("vnc", libxl_vnc_info), > > ("sdl", libxl_sdl_info), > > # set keyboard layout, default is en-us keyboard > > @@ -352,7 +353,7 @@ libxl_device_vfb = Struct("device_vfb", [ > > > > libxl_device_vkb = Struct("device_vkb", [ > > ("backend_domid", libxl_domid), > > - ("devid", integer), > > + ("devid", libxl_devid), > > ]) > > > > libxl_device_disk = Struct("device_disk", [ > > @@ -369,7 +370,7 @@ libxl_device_disk = Struct("device_disk", [ > > > > libxl_device_nic = Struct("device_nic", [ > > ("backend_domid", libxl_domid), > > - ("devid", integer), > > + ("devid", libxl_devid), > > ("mtu", integer), > > ("model", string), > > ("mac", libxl_mac), > > @@ -399,7 +400,7 @@ libxl_diskinfo = Struct("diskinfo", [ > > ("backend_id", uint32), > > ("frontend", string), > > ("frontend_id", uint32), > > - ("devid", integer), > > + ("devid", libxl_devid), > > ("state", integer), > > ("evtch", integer), > > ("rref", integer), > > @@ -410,7 +411,7 @@ libxl_nicinfo = Struct("nicinfo", [ > > ("backend_id", uint32), > > ("frontend", string), > > ("frontend_id", uint32), > > - ("devid", integer), > > + ("devid", libxl_devid), > > ("state", integer), > > ("evtch", integer), > > ("rref_tx", integer), > > diff --git a/tools/ocaml/libs/xl/genwrap.py b/tools/ocaml/libs/xl/genwrap.py > > index 42f374e..97d088d 100644 > > --- a/tools/ocaml/libs/xl/genwrap.py > > +++ b/tools/ocaml/libs/xl/genwrap.py > > @@ -10,6 +10,7 @@ builtins = { > > "int": ("int", "%(c)s = Int_val(%(o)s)", "Val_int(%(c)s)" ), > > "char *": ("string", "%(c)s = dup_String_val(gc, %(o)s)", "caml_copy_string(%(c)s)"), > > "libxl_domid": ("domid", "%(c)s = Int_val(%(o)s)", "Val_int(%(c)s)" ), > > + "libxl_devid": ("devid", "%(c)s = Int_val(%(o)s)", "Val_int(%(c)s)" ), > > "libxl_defbool": ("bool option", "%(c)s = Defbool_val(%(o)s)", "Val_defbool(%(c)s)" ), > > "libxl_uuid": ("int array", "Uuid_val(gc, lg, &%(c)s, %(o)s)", "Val_uuid(&%(c)s)"), > > "libxl_key_value_list": ("(string * string) list", None, None), > > @@ -41,8 +42,8 @@ def stub_fn_name(ty, name): > > return "stub_xl_%s_%s" % (ty.rawname,name) > > > > def ocaml_type_of(ty): > > - if ty.rawname == "domid": > > - return "domid" > > + if ty.rawname in ["domid","devid"]: > > + return ty.rawname > > elif isinstance(ty,idl.UInt): > > if ty.width in [8, 16]: > > # handle as ints > > diff --git a/tools/ocaml/libs/xl/xenlight.ml.in b/tools/ocaml/libs/xl/xenlight.ml.in > > index c47623c..dcc1a38 100644 > > --- a/tools/ocaml/libs/xl/xenlight.ml.in > > +++ b/tools/ocaml/libs/xl/xenlight.ml.in > > @@ -16,6 +16,7 @@ > > exception Error of string > > > > type domid = int > > +type devid = int > > > > (* @@LIBXL_TYPES@@ *) > > > > diff --git a/tools/ocaml/libs/xl/xenlight.mli.in b/tools/ocaml/libs/xl/xenlight.mli.in > > index 4717bac..3fd0165 100644 > > --- a/tools/ocaml/libs/xl/xenlight.mli.in > > +++ b/tools/ocaml/libs/xl/xenlight.mli.in > > @@ -16,6 +16,7 @@ > > exception Error of string > > > > type domid = int > > +type devid = int > > > > (* @@LIBXL_TYPES@@ *) > > > > diff --git a/tools/python/xen/lowlevel/xl/xl.c b/tools/python/xen/lowlevel/xl/xl.c > > index 0551c76..32f982a 100644 > > --- a/tools/python/xen/lowlevel/xl/xl.c > > +++ b/tools/python/xen/lowlevel/xl/xl.c > > @@ -281,6 +281,11 @@ int attrib__libxl_domid_set(PyObject *v, libxl_domid *domid) { > > return 0; > > } > > > > +int attrib__libxl_devid_set(PyObject *v, libxl_devid *devid) { > > + *devid = PyInt_AsLong(v); > > + return 0; > > +} > > + > > int attrib__struct_in_addr_set(PyObject *v, struct in_addr *pptr) > > { > > PyErr_SetString(PyExc_NotImplementedError, "Setting in_addr"); > > @@ -342,6 +347,10 @@ PyObject *attrib__libxl_domid_get(libxl_domid *domid) { > > return PyInt_FromLong(*domid); > > } > > > > +PyObject *attrib__libxl_devid_get(libxl_devid *devid) { > > + return PyInt_FromLong(*devid); > > +} > > + > > PyObject *attrib__struct_in_addr_get(struct in_addr *pptr) > > { > > PyErr_SetString(PyExc_NotImplementedError, "Getting in_addr"); > > -- > > 1.7.9.5 > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xen.org > > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 13:36:56 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 13:36:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ2eO-0002oK-GJ; Tue, 02 Oct 2012 13:36:40 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ2eM-0002o5-MW for xen-devel@lists.xen.org; Tue, 02 Oct 2012 13:36:38 +0000 Received: from [85.158.139.83:59821] by server-7.bemta-5.messagelabs.com id 20/A2-00431-5EDEA605; Tue, 02 Oct 2012 13:36:37 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-16.tower-182.messagelabs.com!1349184997!25728037!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23018 invoked from network); 2 Oct 2012 13:36:37 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 13:36:37 -0000 X-IronPort-AV: E=Sophos;i="4.80,523,1344211200"; d="scan'208";a="14894038" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 13:36:37 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 14:36:37 +0100 Message-ID: <1349184995.650.54.camel@zakaz.uk.xensource.com> From: Ian Campbell To: George Dunlap Date: Tue, 2 Oct 2012 14:36:35 +0100 In-Reply-To: References: <1348765860-11359-1-git-send-email-matthew.fioravante@jhuapl.edu> <1348765860-11359-2-git-send-email-matthew.fioravante@jhuapl.edu> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: Matthew Fioravante , Ian Jackson , Jan Beulich , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 10/11] make devid a type so it is initialized properly X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-09-28 at 14:23 +0100, George Dunlap wrote: > On Thu, Sep 27, 2012 at 6:10 PM, Matthew Fioravante > wrote: > > Previously device ids in libxl were treated as integers meaning they > > were being initialized to 0, which is a valid device id. This patch > > makes devid its own type in libxl and initializes it to -1, an invalid > > value. > > > > This fixes a bug where if you try to do a xl DEV-attach multiple > > time it will continuously try to reattach device 0 instead of > > generating a new device id. > > > > Signed-off-by: Matthew Fioravante > > Reviewed-by: George Dunlap Acked-by: Ian Campbell > Should this be backported to 4.2-testing? That's a good question. I think it is basically a bugfix to the API and since basically the only way to correctly use the current interface is for the application to always initialise that field changing the initial value seems harmless from a backwards compat PoV. Ian. > > -George > > > > > diff --git a/tools/libxl/gentest.py b/tools/libxl/gentest.py > > index 2915f71..84b4fd7 100644 > > --- a/tools/libxl/gentest.py > > +++ b/tools/libxl/gentest.py > > @@ -60,7 +60,7 @@ def gen_rand_init(ty, v, indent = " ", parent = None): > > passby=idl.PASS_BY_REFERENCE)) > > elif ty.typename in ["libxl_uuid", "libxl_mac", "libxl_hwcap"]: > > s += "rand_bytes((uint8_t *)%s, sizeof(*%s));\n" % (v,v) > > - elif ty.typename in ["libxl_domid"] or isinstance(ty, idl.Number): > > + elif ty.typename in ["libxl_domid", "libxl_devid"] or isinstance(ty, idl.Number): > > s += "%s = rand() %% (sizeof(%s)*8);\n" % \ > > (ty.pass_arg(v, parent is None), > > ty.pass_arg(v, parent is None)) > > diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h > > index 599c7f1..7a7c419 100644 > > --- a/tools/libxl/libxl.h > > +++ b/tools/libxl/libxl.h > > @@ -307,6 +307,7 @@ void libxl_cpuid_dispose(libxl_cpuid_policy_list *cpuid_list); > > #define LIBXL_PCI_FUNC_ALL (~0U) > > > > typedef uint32_t libxl_domid; > > +typedef int libxl_devid; > > > > /* > > * Formatting Enumerations. > > diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl > > index cf83c60..de111a6 100644 > > --- a/tools/libxl/libxl_types.idl > > +++ b/tools/libxl/libxl_types.idl > > @@ -8,6 +8,7 @@ namespace("libxl_") > > libxl_defbool = Builtin("defbool", passby=PASS_BY_REFERENCE) > > > > libxl_domid = Builtin("domid", json_fn = "yajl_gen_integer", autogenerate_json = False) > > +libxl_devid = Builtin("devid", json_fn = "yajl_gen_integer", autogenerate_json = False, signed = True, init_val="-1") > > libxl_uuid = Builtin("uuid", passby=PASS_BY_REFERENCE) > > libxl_mac = Builtin("mac", passby=PASS_BY_REFERENCE) > > libxl_bitmap = Builtin("bitmap", dispose_fn="libxl_bitmap_dispose", passby=PASS_BY_REFERENCE) > > @@ -343,7 +344,7 @@ libxl_domain_build_info = Struct("domain_build_info",[ > > > > libxl_device_vfb = Struct("device_vfb", [ > > ("backend_domid", libxl_domid), > > - ("devid", integer), > > + ("devid", libxl_devid), > > ("vnc", libxl_vnc_info), > > ("sdl", libxl_sdl_info), > > # set keyboard layout, default is en-us keyboard > > @@ -352,7 +353,7 @@ libxl_device_vfb = Struct("device_vfb", [ > > > > libxl_device_vkb = Struct("device_vkb", [ > > ("backend_domid", libxl_domid), > > - ("devid", integer), > > + ("devid", libxl_devid), > > ]) > > > > libxl_device_disk = Struct("device_disk", [ > > @@ -369,7 +370,7 @@ libxl_device_disk = Struct("device_disk", [ > > > > libxl_device_nic = Struct("device_nic", [ > > ("backend_domid", libxl_domid), > > - ("devid", integer), > > + ("devid", libxl_devid), > > ("mtu", integer), > > ("model", string), > > ("mac", libxl_mac), > > @@ -399,7 +400,7 @@ libxl_diskinfo = Struct("diskinfo", [ > > ("backend_id", uint32), > > ("frontend", string), > > ("frontend_id", uint32), > > - ("devid", integer), > > + ("devid", libxl_devid), > > ("state", integer), > > ("evtch", integer), > > ("rref", integer), > > @@ -410,7 +411,7 @@ libxl_nicinfo = Struct("nicinfo", [ > > ("backend_id", uint32), > > ("frontend", string), > > ("frontend_id", uint32), > > - ("devid", integer), > > + ("devid", libxl_devid), > > ("state", integer), > > ("evtch", integer), > > ("rref_tx", integer), > > diff --git a/tools/ocaml/libs/xl/genwrap.py b/tools/ocaml/libs/xl/genwrap.py > > index 42f374e..97d088d 100644 > > --- a/tools/ocaml/libs/xl/genwrap.py > > +++ b/tools/ocaml/libs/xl/genwrap.py > > @@ -10,6 +10,7 @@ builtins = { > > "int": ("int", "%(c)s = Int_val(%(o)s)", "Val_int(%(c)s)" ), > > "char *": ("string", "%(c)s = dup_String_val(gc, %(o)s)", "caml_copy_string(%(c)s)"), > > "libxl_domid": ("domid", "%(c)s = Int_val(%(o)s)", "Val_int(%(c)s)" ), > > + "libxl_devid": ("devid", "%(c)s = Int_val(%(o)s)", "Val_int(%(c)s)" ), > > "libxl_defbool": ("bool option", "%(c)s = Defbool_val(%(o)s)", "Val_defbool(%(c)s)" ), > > "libxl_uuid": ("int array", "Uuid_val(gc, lg, &%(c)s, %(o)s)", "Val_uuid(&%(c)s)"), > > "libxl_key_value_list": ("(string * string) list", None, None), > > @@ -41,8 +42,8 @@ def stub_fn_name(ty, name): > > return "stub_xl_%s_%s" % (ty.rawname,name) > > > > def ocaml_type_of(ty): > > - if ty.rawname == "domid": > > - return "domid" > > + if ty.rawname in ["domid","devid"]: > > + return ty.rawname > > elif isinstance(ty,idl.UInt): > > if ty.width in [8, 16]: > > # handle as ints > > diff --git a/tools/ocaml/libs/xl/xenlight.ml.in b/tools/ocaml/libs/xl/xenlight.ml.in > > index c47623c..dcc1a38 100644 > > --- a/tools/ocaml/libs/xl/xenlight.ml.in > > +++ b/tools/ocaml/libs/xl/xenlight.ml.in > > @@ -16,6 +16,7 @@ > > exception Error of string > > > > type domid = int > > +type devid = int > > > > (* @@LIBXL_TYPES@@ *) > > > > diff --git a/tools/ocaml/libs/xl/xenlight.mli.in b/tools/ocaml/libs/xl/xenlight.mli.in > > index 4717bac..3fd0165 100644 > > --- a/tools/ocaml/libs/xl/xenlight.mli.in > > +++ b/tools/ocaml/libs/xl/xenlight.mli.in > > @@ -16,6 +16,7 @@ > > exception Error of string > > > > type domid = int > > +type devid = int > > > > (* @@LIBXL_TYPES@@ *) > > > > diff --git a/tools/python/xen/lowlevel/xl/xl.c b/tools/python/xen/lowlevel/xl/xl.c > > index 0551c76..32f982a 100644 > > --- a/tools/python/xen/lowlevel/xl/xl.c > > +++ b/tools/python/xen/lowlevel/xl/xl.c > > @@ -281,6 +281,11 @@ int attrib__libxl_domid_set(PyObject *v, libxl_domid *domid) { > > return 0; > > } > > > > +int attrib__libxl_devid_set(PyObject *v, libxl_devid *devid) { > > + *devid = PyInt_AsLong(v); > > + return 0; > > +} > > + > > int attrib__struct_in_addr_set(PyObject *v, struct in_addr *pptr) > > { > > PyErr_SetString(PyExc_NotImplementedError, "Setting in_addr"); > > @@ -342,6 +347,10 @@ PyObject *attrib__libxl_domid_get(libxl_domid *domid) { > > return PyInt_FromLong(*domid); > > } > > > > +PyObject *attrib__libxl_devid_get(libxl_devid *devid) { > > + return PyInt_FromLong(*devid); > > +} > > + > > PyObject *attrib__struct_in_addr_get(struct in_addr *pptr) > > { > > PyErr_SetString(PyExc_NotImplementedError, "Getting in_addr"); > > -- > > 1.7.9.5 > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xen.org > > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 13:45:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 13:45:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ2mf-0003AK-LP; Tue, 02 Oct 2012 13:45:13 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ2mf-0003AE-1d for xen-devel@lists.xen.org; Tue, 02 Oct 2012 13:45:13 +0000 Received: from [85.158.143.35:35240] by server-3.bemta-4.messagelabs.com id 97/DE-10986-8EFEA605; Tue, 02 Oct 2012 13:45:12 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1349185510!20727620!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14933 invoked from network); 2 Oct 2012 13:45:10 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 13:45:10 -0000 X-IronPort-AV: E=Sophos;i="4.80,523,1344211200"; d="scan'208";a="14894240" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 13:44:10 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 14:44:10 +0100 Message-ID: <1349185449.650.55.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Matthew Fioravante Date: Tue, 2 Oct 2012 14:44:09 +0100 In-Reply-To: <5069E396.5040205@jhuapl.edu> References: <1348765860-11359-1-git-send-email-matthew.fioravante@jhuapl.edu> <1348765860-11359-3-git-send-email-matthew.fioravante@jhuapl.edu> <5065CAE9.30602@jhuapl.edu> <5065D333.6080600@jhuapl.edu> <5069E396.5040205@jhuapl.edu> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: George Dunlap , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 11/11] add vtpm support to libxl X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, 2012-10-01 at 19:40 +0100, Matthew Fioravante wrote: > Actually thinking about it more, uuids have to be attached to the > driver. If 2 vtpms connect to the manager, one could send the uuid of > the other and get access to someone elses secrets. > > TL;DR version > > uuids must remain part of the driver. What stops the driver lying about the UUID in a similar way? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 13:45:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 13:45:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ2mf-0003AK-LP; Tue, 02 Oct 2012 13:45:13 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ2mf-0003AE-1d for xen-devel@lists.xen.org; Tue, 02 Oct 2012 13:45:13 +0000 Received: from [85.158.143.35:35240] by server-3.bemta-4.messagelabs.com id 97/DE-10986-8EFEA605; Tue, 02 Oct 2012 13:45:12 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1349185510!20727620!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14933 invoked from network); 2 Oct 2012 13:45:10 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 13:45:10 -0000 X-IronPort-AV: E=Sophos;i="4.80,523,1344211200"; d="scan'208";a="14894240" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 13:44:10 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 14:44:10 +0100 Message-ID: <1349185449.650.55.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Matthew Fioravante Date: Tue, 2 Oct 2012 14:44:09 +0100 In-Reply-To: <5069E396.5040205@jhuapl.edu> References: <1348765860-11359-1-git-send-email-matthew.fioravante@jhuapl.edu> <1348765860-11359-3-git-send-email-matthew.fioravante@jhuapl.edu> <5065CAE9.30602@jhuapl.edu> <5065D333.6080600@jhuapl.edu> <5069E396.5040205@jhuapl.edu> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: George Dunlap , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 11/11] add vtpm support to libxl X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, 2012-10-01 at 19:40 +0100, Matthew Fioravante wrote: > Actually thinking about it more, uuids have to be attached to the > driver. If 2 vtpms connect to the manager, one could send the uuid of > the other and get access to someone elses secrets. > > TL;DR version > > uuids must remain part of the driver. What stops the driver lying about the UUID in a similar way? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 13:47:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 13:47:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ2oA-0003HH-F2; Tue, 02 Oct 2012 13:46:46 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ2o8-0003H5-0N for Xen-devel@lists.xen.org; Tue, 02 Oct 2012 13:46:44 +0000 Received: from [85.158.143.99:50042] by server-1.bemta-4.messagelabs.com id 52/DD-05684-340FA605; Tue, 02 Oct 2012 13:46:43 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1349185597!26447331!1 X-Originating-IP: [209.85.213.45] X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG, HTML_50_60, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, ML_RADAR_SPEW_LINKS_23, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5168 invoked from network); 2 Oct 2012 13:46:38 -0000 Received: from mail-yh0-f45.google.com (HELO mail-yh0-f45.google.com) (209.85.213.45) by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 13:46:38 -0000 Received: by yhpp34 with SMTP id p34so545820yhp.32 for ; Tue, 02 Oct 2012 06:46:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=12xj8OTRd1T2y4ocYFttuY6YY4iM8g/28fWIyrB70Uc=; b=ItTR/TYCXuX97wdGSrmTnBLRJsczw0US45a94kuryPdUx9czFitroSuSxusVoKhBPQ DuhLr9pA9E1gkotMyBtjo0C6PXJEAxqOw4kgfY2574zzI5Nw8Pzb3tC/7EJDWYls8gtX +lv4Mp/KBQkx9whrpMxTa48RWCG7BV51xoKxxRZPj0XUoH3KihuSGAw1K9ID+rRl/tZz HNUDiq0JK/YvyCrDPU7PkLov+RSFYhqaev1hOiBpZCdisogCDAy5MQZmQZtDp4wQFSAc PXvmE357yn4eCtxzErrC3uRlnr4WxAMMvB6eQoPMxDz11RBoxXn8EjoqleMm7xQIhCYL p9Cw== MIME-Version: 1.0 Received: by 10.236.193.105 with SMTP id j69mr15921725yhn.21.1349185597304; Tue, 02 Oct 2012 06:46:37 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Tue, 2 Oct 2012 06:46:37 -0700 (PDT) In-Reply-To: <20121002131407.GM8912@reaktio.net> References: <20121001160117.GD8912@reaktio.net> <20121001164757.GF8912@reaktio.net> <20121001182437.GG8912@reaktio.net> <20121002121932.GL8912@reaktio.net> <20121002131407.GM8912@reaktio.net> Date: Tue, 2 Oct 2012 16:46:37 +0300 Message-ID: From: Valtteri Kiviniemi To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= Cc: Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.0.4, kernel 3.5.0 HVM crash and kernel BUG X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5962986339054632322==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============5962986339054632322== Content-Type: multipart/alternative; boundary=20cf30563c0d436e7b04cb13c0b5 --20cf30563c0d436e7b04cb13c0b5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, I have not enabled debug on Xen or dom0 kernel. Could you tell me the parameters for Xen coompilation needed to enable debugging? And If you would also happen to know what are the options needed to enable kernel debugging in menuconfig? Well I can probably manage to get the kernel debugging enabled myself, but if you happen to know them please share so maybe I can get everything enabled at the first try :) Thanks! - Valtteri 2012/10/2 Pasi K=E4rkk=E4inen > On Tue, Oct 02, 2012 at 04:01:04PM +0300, Valtteri Kiviniemi wrote: > > Hi, > > > > I already tried 3.2, 3.5, 3.5.0, 3.6.0-rc7 and 3.6.0, same problem > all of > > those. My dom0 config is the same config that I'am using on other > server > > where HVM is working, so I dont think that it is a config problem. I > have > > triple checked everything and all should be ok. dom0 dmesg shows the > same > > crash that I have previously posted here. /var/log/xen/ does not > contain > > any specific errors. > > > > Could this be some kind of broblem with my motherboard bios being > buggy or > > CPU not supported? I'm using the new intel Ivy Bridge processor whic= h > has > > integrated GPU, but that should not probably cause these kind of > problems. > > Or maybe some ACPI problem? xm dmesg is showing some notices about > ACPI. > > Is there any ACPI kernel parameters that I should try booting? This > has to > > be somekind of problem with my hardware, or then maybe it could be a > > kernel problem too. I just really cant figure this out myself, I hav= e > > tried everything. > > > > Hmm.. I have some distant memories of seeing a patch that fixes a bug > on recent Ivy Bridge systems, but I can't find a link right now. > Maybe you're affected by that.. > > Also: Did you already post the crash log, with all the debug/verbose > options enabled for both Xen and dom0 kernel? > > -- Pasi > > > Lets take a quick summary of what has been tested, what hardware I'm > using > > etc. > > > > Xen-versions tested: 4.2.0, 4.0.4 > > Kernel-versions tested: 3.2.0, 3.5.0, 3.5.4, 3.6.0-rc7, 3.6.0 > > > > Host OS: Debian testing/wheezy, udev version 175-7, 2.13-35, python > > version 2.7.3~rc2-2.1 > > > > Hardware: > > > > CPU: Intel Core i7-3770 3.4GHz > > MB: Intel DQ77MK (latest bios updated) > > Memory: 32GB (4 x 8GB DDR3-1600MHz) > > > > All relevant log files and configs: > > > > dom0 dmesg: [1]http://nago.fi/dmesg.txt > > qemu-dm log: [2]http://nago.fi/qemu-dm.txt > > xm dmesg log: [3]http://nago.fi/xm-dmesg.txt > > domU config: [4]http://nago.fi/domu-config.txt > > dom0 kernel config: [5]http://nago.fi/dom0-config.txt > > > > I have also tried playing with every setting on that domU that I can > think > > of and tried different configs etc. > > > > - Valtteri > > > > 2012/10/2 Pasi K=E4rkk=E4inen <[6]pasik@iki.fi> > > > > On Tue, Oct 02, 2012 at 03:11:07PM +0300, Valtteri Kiviniemi wrote= : > > > Hi, > > > > > > Another update: > > > > > > I wanted to check that if a Linux HVM would boot with working > VNC > > console, > > > so I tried to launch a Debian Squeeze installer on HVM. It > refused > > to > > > start ant told me that vbd hotplug scripts were not working. > After > > that > > > failure even the Windows domU would not anymore start which w= as > > previously > > > starting ok. > > > > > > The hotplug scripts also starts hanging on the processes. > > > > > > root 9401 0.1 0.1 17700 1640 ? S 15:05 > 0:00 > > /bin/bash > > > /etc/xen/scripts/xen-hotplug-cleanup > > > root 9441 0.1 0.1 17700 1644 ? S 15:05 > 0:00 > > /bin/bash > > > /etc/xen/scripts/xen-hotplug-cleanup > > > root 9481 0.1 0.1 17700 1640 ? S 15:05 > 0:00 > > /bin/bash > > > /etc/xen/scripts/xen-hotplug-cleanup > > > root 9560 0.1 0.1 17700 1640 ? S 15:05 > 0:00 > > /bin/bash > > > /etc/xen/scripts/xen-hotplug-cleanup > > > root 10738 0.1 0.1 17696 1636 ? S 15:05 > 0:00 > > /bin/bash > > > /etc/xen/scripts/xen-hotplug-cleanup > > > root 10747 0.1 0.1 17792 1736 ? S 15:05 > 0:00 > > /bin/bash > > > /etc/xen/scripts/block remove > > > root 11286 0.0 0.0 4080 324 ? S 15:06 > 0:00 > > sleep 1 > > > root 11290 0.0 0.0 4080 324 ? S 15:06 > 0:00 > > sleep 1 > > > root 11294 0.0 0.0 4080 324 ? S 15:06 > 0:00 > > sleep 1 > > > root 11298 0.0 0.0 4080 324 ? S 15:06 > 0:00 > > sleep 1 > > > root 11302 0.0 0.0 4080 320 ? S 15:06 > 0:00 > > sleep 1 > > > root 11306 0.0 0.0 4080 320 ? S 15:06 > 0:00 > > sleep 1 > > > > > > Then I did a xm destroy and I had again the kernel BUG on > dmesg. So > > it > > > seems that the problem is not fixed by using 3.6.0. Udev > version is > > 175-7. > > > > > > > So you have definitely something broken in your system, > > probably in your dom0 kernel. Try with Linux 3.5.4 or 3.4.x, > > and see how that goes. > > > > Any errors in dom0 dmesg? How about in /var/log/xen/* ? > > > > -- Pasi > > > > > > > > > > > 2012/10/1 Valtteri Kiviniemi <[1][7] > kiviniemi.valtteri@gmail.com> > > > > > > Hi, > > > > > > CPU: Intel Core i7-3770 3.4GHz > > > [2][8]http://ark.intel.com/products/65719/ > > > > > > MB: Intel DQ77MK (latest bios updated) > > > > > [3][9] > http://www.intel.com/content/www/us/en/motherboards/desktop-motherboards/= desktop-board-dq77mk.html > > > > > > Memory: 32GB (4 x 8GB DDR3-1600MHz) > > > > > > Host is Debian wheezy/testing, Xen 4.0.4 and latest 3.6.0 > kernel. > > > > > > Noticed also some errors in xm dmesg: > > > > > > root@xen-2:~# xm dmesg > > > > > > (XEN) Xen version 4.0.4 ([4][10]root@dataproof.fi) (gcc > version > > 4.7.1 > > > (Debian 4.7.1-7) ) Sun Sep 30 20:28:26 EEST 2012 > > > (XEN) Latest ChangeSet: unavailable > > > (XEN) Bootloader: GNU GRUB 0.97 > > > (XEN) Command line: dom0_mem=3D1280M cpufreq=3Dxen > clocksource=3Dhpet > > > (XEN) Video information: > > > (XEN) VGA is text mode 80x25, font 8x16 > > > (XEN) VBE/DDC methods: none; EDID transfer time: 0 seconds > > > (XEN) EDID info not retrieved because no DDC retrieval > method > > detected > > > (XEN) Disc information: > > > (XEN) Found 4 MBR signatures > > > (XEN) Found 4 EDD information structures > > > (XEN) Xen-e820 RAM map: > > > (XEN) 0000000000000000 - 000000000009d800 (usable) > > > (XEN) 000000000009d800 - 00000000000a0000 (reserved) > > > (XEN) 00000000000e0000 - 0000000000100000 (reserved) > > > (XEN) 0000000000100000 - 0000000020000000 (usable) > > > (XEN) 0000000020000000 - 0000000020200000 (reserved) > > > (XEN) 0000000020200000 - 0000000040004000 (usable) > > > (XEN) 0000000040004000 - 0000000040005000 (reserved) > > > (XEN) 0000000040005000 - 00000000dbe44000 (usable) > > > (XEN) 00000000dbe44000 - 00000000dc2d7000 (reserved) > > > (XEN) 00000000dc2d7000 - 00000000dc2e7000 (ACPI data) > > > (XEN) 00000000dc2e7000 - 00000000dc40c000 (ACPI NVS) > > > (XEN) 00000000dc40c000 - 00000000dc6af000 (reserved) > > > (XEN) 00000000dc6af000 - 00000000dc6b0000 (usable) > > > (XEN) 00000000dc6b0000 - 00000000dc6f3000 (ACPI NVS) > > > (XEN) 00000000dc6f3000 - 00000000dd000000 (usable) > > > (XEN) 00000000dd800000 - 00000000dfa00000 (reserved) > > > (XEN) 00000000f8000000 - 00000000fc000000 (reserved) > > > (XEN) 00000000fec00000 - 00000000fec01000 (reserved) > > > (XEN) 00000000fed00000 - 00000000fed04000 (reserved) > > > (XEN) 00000000fed1c000 - 00000000fed20000 (reserved) > > > (XEN) 00000000fee00000 - 00000000fee01000 (reserved) > > > (XEN) 00000000ff000000 - 0000000100000000 (reserved) > > > (XEN) 0000000100000000 - 000000081e600000 (usable) > > > (XEN) ACPI: RSDP 000F0490, 0024 (r2 INTEL) > > > (XEN) ACPI: XSDT DC2DB080, 007C (r1 INTEL DQ77MK 3= 2 > AMI > > > 10013) > > > (XEN) ACPI: FACP DC2E51F0, 010C (r5 INTEL DQ77MK 3= 2 > AMI > > > 10013) > > > (XEN) ACPI Warning (tbfadt-0232): FADT (revision 5) is long= er > > than ACPI > > > 2.0 version, truncating length 0x10C to 0xF4 [20070126] > > > (XEN) ACPI: DSDT DC2DB188, A061 (r2 INTEL DQ77MK 3= 2 > INTL > > > 20051117) > > > (XEN) ACPI: FACS DC40A080, 0040 > > > (XEN) ACPI: APIC DC2E5300, 0092 (r3 INTEL DQ77MK 3= 2 > AMI > > > 10013) > > > (XEN) ACPI: FPDT DC2E5398, 0044 (r1 INTEL DQ77MK 3= 2 > AMI > > > 10013) > > > (XEN) ACPI: TCPA DC2E53E0, 0032 (r2 INTEL DQ77MK 3= 2 > MSFT > > > 1000013) > > > (XEN) ACPI: MCFG DC2E5418, 003C (r1 INTEL DQ77MK 3= 2 > MSFT > > > 97) > > > (XEN) ACPI: HPET DC2E5458, 0038 (r1 INTEL DQ77MK 3= 2 > AMI. > > > 5) > > > (XEN) ACPI: SSDT DC2E5490, 036D (r1 INTEL DQ77MK 3= 2 > INTL > > > 20091112) > > > (XEN) ACPI: SSDT DC2E5800, 09AA (r1 INTEL DQ77MK 3= 2 > INTL > > > 20051117) > > > (XEN) ACPI: SSDT DC2E61B0, 0A92 (r1 INTEL DQ77MK 3= 2 > INTL > > > 20051117) > > > (XEN) ACPI: DMAR DC2E6C48, 00B8 (r1 INTEL DQ77MK 3= 2 > INTL > > > 1) > > > (XEN) ACPI: ASF! DC2E6D00, 00A5 (r32 INTEL DQ77MK = 32 > > TFSM > > > F4240) > > > (XEN) System RAM: 32682MB (33467320kB) > > > (XEN) Domain heap initialised > > > (XEN) ACPI: 32/64X FACS address mismatch in FADT - > > > dc40a080/0000000000000000, using 32 > > > (XEN) Processor #0 7:10 APIC version 21 > > > (XEN) Processor #2 7:10 APIC version 21 > > > (XEN) Processor #4 7:10 APIC version 21 > > > (XEN) Processor #6 7:10 APIC version 21 > > > (XEN) Processor #1 7:10 APIC version 21 > > > (XEN) Processor #3 7:10 APIC version 21 > > > (XEN) Processor #5 7:10 APIC version 21 > > > (XEN) Processor #7 7:10 APIC version 21 > > > (XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, > GSI > > 0-23 > > > (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs > > > (XEN) Switched to APIC driver x2apic_cluster. > > > (XEN) x2APIC mode enabled. > > > (XEN) Using scheduler: SMP Credit Scheduler (credit) > > > (XEN) Detected 3392.369 MHz processor. > > > (XEN) Initing memory sharing. > > > (XEN) VMX: Supported advanced features: > > > (XEN) - APIC MMIO access virtualisation > > > (XEN) - APIC TPR shadow > > > (XEN) - Extended Page Tables (EPT) > > > (XEN) - Virtual-Processor Identifiers (VPID) > > > (XEN) - Virtual NMI > > > (XEN) - MSR direct-access bitmap > > > (XEN) - Unrestricted Guest > > > (XEN) EPT supports 2MB super page. > > > (XEN) HVM: ASIDs enabled. > > > (XEN) HVM: VMX enabled > > > (XEN) HVM: Hardware Assisted Paging detected. > > > (XEN) Intel VT-d Snoop Control not enabled. > > > (XEN) Intel VT-d Dom0 DMA Passthrough not enabled. > > > (XEN) Intel VT-d Queued Invalidation enabled. > > > (XEN) Intel VT-d Interrupt Remapping enabled. > > > (XEN) I/O virtualisation enabled > > > (XEN) - Dom0 mode: Relaxed > > > (XEN) Enabled directed EOI with ioapic_ack_old on! > > > (XEN) Total of 8 processors activated. > > > (XEN) ENABLING IO-APIC IRQs > > > (XEN) -> Using old ACK method > > > (XEN) TSC is reliable, synchronization unnecessary > > > (XEN) Platform timer appears to have unexpectedly wrapped 1 > > times. > > > (XEN) Platform timer is 14.318MHz HPET > > > (XEN) Allocated console ring of 16 KiB. > > > (XEN) Brought up 8 CPUs > > > (XEN) *** LOADING DOMAIN 0 *** > > > (XEN) Xen kernel: 64-bit, lsb, compat32 > > > (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> > > 0x1ae7000 > > > (XEN) PHYSICAL MEMORY ARRANGEMENT: > > > (XEN) Dom0 alloc.: 0000000804000000->0000000806000000 > (319488 > > pages > > > to be allocated) > > > (XEN) VIRTUAL MEMORY ARRANGEMENT: > > > (XEN) Loaded kernel: ffffffff81000000->ffffffff81ae7000 > > > (XEN) Init. ramdisk: ffffffff81ae7000->ffffffff81ae7000 > > > (XEN) Phys-Mach map: ffffffff81ae7000->ffffffff81d67000 > > > (XEN) Start info: ffffffff81d67000->ffffffff81d674b4 > > > (XEN) Page tables: ffffffff81d68000->ffffffff81d7b000 > > > (XEN) Boot stack: ffffffff81d7b000->ffffffff81d7c000 > > > (XEN) TOTAL: ffffffff80000000->ffffffff82000000 > > > (XEN) ENTRY ADDRESS: ffffffff815e3210 > > > (XEN) Dom0 has maximum 8 VCPUs > > > (XEN) [VT-D]iommu.c:718: BIOS did not enable IGD for VT > properly. > > > Disabling IGD VT-d engine. > > > (XEN) Scrubbing Free RAM: done. > > > (XEN) Xen trace buffers: disabled > > > (XEN) Std. Loglevel: Errors and warnings > > > (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and > warnings) > > > (XEN) Xen is relinquishing VGA console. > > > (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times t= o > > switch > > > input to Xen) > > > (XEN) Freed 172kB init memory. > > > (XEN) traps.c:2333:d0 Domain attempted WRMSR 00000000000000= 8b > > from > > > 00000012:00000000 to 00000000:00000000. > > > > > > - Valtteri > > > > > > 2012/10/1 Pasi K=E4rkk=E4inen <[5][11]pasik@iki.fi> > > > > > > On Mon, Oct 01, 2012 at 09:12:50PM +0300, Valtteri > Kiviniemi > > wrote: > > > > Hi, > > > > > > > > Lowering memory or vcpu's does not help, problem is > the > > same. I > > > originally > > > > installed Xen 4.2.0 and the problem was same on that > too. > > Then I > > > > downgraded back to 4.0.4 since I thought that this > might > > be a bug > > > on > > > > 4.2.0. I have been previously running Windows Server > 2008 > > R2 > > > succesfully > > > > on Xen 4.0.x on different hardware with this same > config. > > > Hypervisor is > > > > 64bit and windows is 64bit. > > > > > > > > Any ideas what to try next? > > > > > > > > > > What kind of hardware is that? > > > > > > [6][12]xen.org automated testing regularly tests Windows > VMs, > > and it works > > > OK there. > > > > > > -- Pasi > > > > Ps. qemu-dm.log is the following: > > > > > > > > domid: 10 > > > > config qemu network with xen bridge for tap10.0 > xenbr0 > > > > Using file /dev/virtuals/ts in read-write mode > > > > Using file /media/iso/windows_server_2008_r2_sp1.iso > in > > read-only > > > mode > > > > Watching /local/domain/0/device-model/10/logdirty/cm= d > > > > Watching /local/domain/0/device-model/10/command > > > > qemu_map_cache_init nr_buckets =3D 10000 size 419430= 4 > > > > shared page at pfn feffd > > > > buffered io page at pfn feffb > > > > Guest uuid =3D 52f19e23-2955-c27d-a22c-60c5d8c60d5a > > > > Time offset set 0 > > > > populating video RAM at ff000000 > > > > mapping video RAM from ff000000 > > > > Register xen platform. > > > > Done register platform. > > > > platform_fixed_ioport: changed ro/rw state of ROM > memory > > area. > > > now is rw > > > > state. > > > > > > xs_read(/local/domain/0/device-model/10/xen_extended_power_mgmt): > > > read > > > > error > > > > medium change watch on `hdc' (index: 1): > > > > /media/iso/windows_server_2008_r2_sp1.iso > > > > I/O request not ready: 0, ptr: 0, port: 0, data: 0, > count: > > 0, > > > size: 0 > > > > Log-dirty: no command yet. > > > > xs_read(/local/domain/10/log-throttling): read error > > > > qemu: ignoring not-understood drive > > > `/local/domain/10/log-throttling' > > > > medium change watch on > `/local/domain/10/log-throttling' - > > > unknown device, > > > > ignored > > > > cirrus vga map change while on lfb mode > > > > mapping vram to f0000000 - f0400000 > > > > platform_fixed_ioport: changed ro/rw state of ROM > memory > > area. > > > now is rw > > > > state. > > > > platform_fixed_ioport: changed ro/rw state of ROM > memory > > area. > > > now is ro > > > > state. > > > > > > > > 2012/10/1 Pasi K=E4rkk=E4inen <[1][7][13]pasik@iki.f= i> > > > > > > > > On Mon, Oct 01, 2012 at 07:23:44PM +0300, Valtteri > > Kiviniemi > > > wrote: > > > > > Hi, > > > > > > > > > > I have tried other config files, but the > problem is > > the > > > same. At > > > > the > > > > > moment I'm using a config file from another > server > > where I > > > have a > > > > working > > > > > Windows Server 2008 R2 installation, so I don= t > > think that > > > there is > > > > > anything wrong with my config: > > > > > > > > > > > > > Did you try with less vcpus, for example 2 ? > > > > how about with less memory, say 2 GB ? > > > > > > > > Did you try with later Xen versions? Is that a 32b= it > > Xen, or > > > 64bit Xen > > > > hypervisor? > > > > > > > > -- Pasi > > > > > kernel =3D "/usr/lib/xen/boot/hvmloader" > > > > > builder =3D "hvm" > > > > > shadow_memory =3D "8" > > > > > memory =3D "4096" > > > > > name =3D "ts" > > > > > vcpus =3D "8" > > > > > cpus =3D ["0", "1", "2", "3", "4", "5", "6", = "7"] > > > > > pae =3D "1" > > > > > acpi =3D "1" > > > > > apic =3D "1" > > > > > vfb =3D [ 'type=3Dvnc, vnclisten=3D10.100.100= .50, > > vncpasswd=3Dxxx' > > > ] > > > > > xen_extended_power_mgmt =3D "0" > > > > > vif =3D [ "type=3Dioemu, mac=3D00:16:3e:d7:d7= :5d, > > bridge=3Dxenbr0" > > > ] > > > > > disk =3D [ "phy:/dev/virtuals/ts,hda,w", > > > > > > > > > "file:/media/iso/windows_server_2008_r2_sp1.iso,hdc:cdrom,r" ] > > > > > on_poweroff =3D "destroy" > > > > > on_reboot =3D "restart" > > > > > on_crash =3D "restart" > > > > > viridian =3D "1" > > > > > device_model =3D "/usr/lib/xen/bin/qemu-dm" > > > > > boot =3D "dc" > > > > > snapshot =3D "0" > > > > > vncconsole =3D "1" > > > > > sdl =3D "0" > > > > > opengl =3D "0" > > > > > vnc =3D "1" > > > > > nographic =3D "0" > > > > > stdvga =3D "0" > > > > > tsc_mode =3D "1" > > > > > monitor =3D "0" > > > > > localtime =3D "1" > > > > > usb =3D "0" > > > > > keymap =3D "fi" > > > > > xen_platform_pci =3D "1" > > > > > pci_msitranslate =3D "1" > > > > > pci_power_mgmt =3D "0" > > > > > > > > > > 2012/10/1 Pasi K=E4rkk=E4inen > > <[1][2][8][14]pasik@iki.fi> > > > > > > > > > > On Mon, Oct 01, 2012 at 06:46:08PM +0300, > > Valtteri > > > Kiviniemi > > > > wrote: > > > > > > Hi, > > > > > > > > > > > > Yes, I have viridian=3D1 on my domU > config. > > > > > > > > > > > > > > > > Try with some known good domU configfile. > > > > > > > > > > -- Pasi > > > > > > 2012/10/1 Pasi K=E4rkk=E4inen > > > <[1][2][3][9][15]pasik@iki.fi> > > > > > > > > > > > > On Mon, Oct 01, 2012 at 05:06:53PM > +0300, > > > Valtteri > > > > Kiviniemi > > > > > wrote: > > > > > > > Hi, > > > > > > > > > > > > > > I'm now using 3.6.0 and can't > > reproduce that > > > crash > > > > anymore, > > > > > so it > > > > > > seems > > > > > > > that it was a kernel bug. > > > > > > > > > > > > > > > > > > > OK. > > > > > > > However I'm still getting black > > screen on > > > VNC > > > > > > > when trying to install Windows > Server > > 2008 > > > R2. I can > > > > see the > > > > > > "windows is > > > > > > > loading files" screen but after > the > > > installer starts > > > > the VNC > > > > > > display goes > > > > > > > black. > > > > > > > > > > > > > > Any ideas? > > > > > > > > > > > > > > > > > > > Do you have viridian=3D1 specified f= or > the > > windows > > > vm? > > > > > > > > > > > > -- Pasi > > > > > > > > > > > > > - Valtteri > > > > > > > > > > > > > > 2012/10/1 Pasi K=E4rkk=E4inen > > > <[1][2][3][4][10][16]pasik@iki.fi> > > > > > > > > > > > > > > On Sun, Sep 30, 2012 at > 11:18:03PM > > +0300, > > > Valtteri > > > > > Kiviniemi > > > > > > wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > I'm trying to get Window= s > > Server 2008 > > > R2 > > > > installation > > > > > > booting on > > > > > > > Xen > > > > > > > > 4.0.4. Using the followi= ng > > config: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The domU will start > booting > > just > > > fine, but > > > > after a > > > > > few > > > > > > minutes the > > > > > > > VNC > > > > > > > > screen goes black. After > that > > when > > > typing "xm > > > > destroy > > > > > ts" it > > > > > > will > > > > > > > trigger > > > > > > > > a kernel BUG: > > > > > > > > > > > > > > > > BUG: unable to handle > kernel > > NULL > > > pointer > > > > dereference > > > > > at > > > > > > > 0000000000000030 > > > > > > > > IP: [] > > > iput+0x3e/0x195 > > > > > > > > PGD 0 > > > > > > > > Oops: 0000 [#1] SMP > > > > > > > > CPU 6 > > > > > > > > Pid: 3571, comm: qemu-dm > Not > > tainted > > > > 3.5.0-dom0 #1 > > > > > > > > > > > > > > First of all upgrade to lates= t > > 3.5.x Linux > > > kernel > > > > release > > > > > .. so > > > > > > at least > > > > > > > 3.5.4. > > > > > > > > > > > > > > -- Pasi > > > > > > > > > > > > > > > /DQ77MK > > > > > > > > RIP: > e030:[] > > > > [] > > > > > > > iput+0x3e/0x195 > > > > > > > > RSP: e02b:ffff8800389ffb= f8 > > EFLAGS: > > > 00010246 > > > > > > > > RAX: 0000000000000001 RB= X: > > > ffff8800377b0720 > > > > RCX: > > > > > > ffff8800501c0000 > > > > > > > > RDX: ffff8800501c0000 RS= I: > > > ffff8800377b0790 > > > > RDI: > > > > > > ffff8800377b0790 > > > > > > > > RBP: 0000000000000000 R0= 8: > > > ffffffff815cdd00 > > > > R09: > > > > > > 0000000000000016 > > > > > > > > R10: fefefefefefefeff R1= 1: > > > ffff8800377b0400 > > > > R12: > > > > > > 00000001000a3e0c > > > > > > > > R13: 0000000000000000 R1= 4: > > > 00000001000a3e0c > > > > R15: > > > > > > ffff8800389ffc28 > > > > > > > > FS: > 00007f1af70a8700(0000) > > > > GS:ffff880050180000(0000) > > > > > > > > knlGS:0000000000000000 > > > > > > > > CS: e033 DS: 0000 ES: > 0000 > > CR0: > > > > 000000008005003b > > > > > > > > CR2: 0000000000000030 CR= 3: > > > 000000000156d000 > > > > CR4: > > > > > > 0000000000002660 > > > > > > > > DR0: 0000000000000000 DR= 1: > > > 0000000000000000 > > > > DR2: > > > > > > 0000000000000000 > > > > > > > > DR3: 0000000000000000 DR= 6: > > > 00000000ffff0ff0 > > > > DR7: > > > > > > 0000000000000400 > > > > > > > > Process qemu-dm (pid: > 3571, > > > threadinfo > > > > > ffff8800389fe000, > > > > > > task > > > > > > > > ffff88003a721260) > > > > > > > > Stack: > > > > > > > > ffff88003a6d6400 > > ffff8800377b0000 > > > > 00000001000a3e0c > > > > > > > ffffffff8133ce8f > > > > > > > > ffff8800377b0400 > > ffffffff8134b6cd > > > > ffff8800389ffc28 > > > > > > > ffff8800389ffc28 > > > > > > > > ffff8800377b00f8 > > ffff8800377b0680 > > > > ffff880038cdcd60 > > > > > > > ffff8800377b0000 > > > > > > > > Call Trace: > > > > > > > > [] ? > > > > sk_release_kernel+0x23/0x39 > > > > > > > > [] ? > > > > netdev_run_todo+0x1e9/0x206 > > > > > > > > [] ? > > > > tun_chr_close+0x4c/0x7b > > > > > > > > [] ? > > > fput+0xe4/0x1c5 > > > > > > > > [] ? > > > filp_close+0x61/0x68 > > > > > > > > [] ? > > > > put_files_struct+0x62/0xb9 > > > > > > > > [] ? > > > do_exit+0x24a/0x74c > > > > > > > > [] ? > > > > do_group_exit+0x6b/0x9d > > > > > > > > [] ? > > > > > get_signal_to_deliver+0x449/0x46e > > > > > > > > [] ? > > > do_signal+0x28/0x4c4 > > > > > > > > [] ? > > > > > pvclock_clocksource_read+0x48/0xbf > > > > > > > > [] ? > > > ktime_get_ts+0x66/0xa8 > > > > > > > > [] ? > > > > > poll_select_copy_remaining+0xe0/0xf5 > > > > > > > > [] ? > > > > do_notify_resume+0x3b/0x74 > > > > > > > > [] ? > > > int_signal+0x12/0x17 > > > > > > > > Code: 00 00 00 40 74 02 > 0f 0b > > 48 8d > > > 77 70 48 > > > > 8d bf 08 > > > > > 01 00 > > > > > > 00 e8 > > > > > > > 8b 71 10 > > > > > > > > 00 85 c0 0f 84 5d 01 00 > 00 48 > > 8b 6b > > > 18 f6 83 > > > > 80 00 00 > > > > > 00 08 > > > > > > <4c> 8b > > > > > > > 65 30 > > > > > > > > 74 11 be 68 05 00 00 48 > c7 c7 > > 8e df > > > 4f 81 e8 > > > > bb d0 > > > > > > > > RIP [= ] > > > iput+0x3e/0x195 > > > > > > > > RSP > > > > > > > > CR2: 0000000000000030 > > > > > > > > ---[ end trace > > 67cc1654658fedcc ]--- > > > > > > > > Fixing recursive fault b= ut > > reboot is > > > needed! > > > > > > > > > > > > > > > > I also tested Xen 4.2.0 > and > > problem > > > is the > > > > same. So > > > > > is this > > > > > > a Xen > > > > > > > bug or a > > > > > > > > kernel bug? I am running > > vanilla > > > > > [1][2][3][4][5][11][17]kernel.org kernel > > > > > > 3.5.0 and > > > > > > > my > > > > > > > > hardware is Intel Core > i7-3770 > > CPU > > > and Intel > > > > DQ77MK > > > > > > motherboard > > > > > > > with > > > > > > > > latest bios. > > > > > > > > > > > > > > > > Best regards, > > > > > > > > Valtteri Kiviniemi > > > > > > > > > > > > > > > > References > > > > > > > > > > > > > > > > Visible links > > > > > > > > 1. > > [3][4][5][6][12][18]http://kernel.org/ > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Xen-devel mailing list > > > > > > > > > > [4][5][6][7][13][19]Xen-devel@lists.xen.org > > > > > > > > > > > [5][6][7][8][14][20]http://lists.xen.org/xen-devel > > > > > > > > > > > > > > References > > > > > > > > > > > > > > Visible links > > > > > > > 1. > > mailto:[7][8][9][15][21]pasik@iki.fi > > > > > > > 2. > > [8][9][10][16][22]http://kernel.org/ > > > > > > > 3. > > [9][10][11][17][23]http://kernel.org/ > > > > > > > 4. > > > mailto:[10][11][12][18][24]Xen-devel@lists.xen.org > > > > > > > 5. > > > [11][12][13][19][25]http://lists.xen.org/xen-devel > > > > > > > > > > > > References > > > > > > > > > > > > Visible links > > > > > > 1. mailto:[13][14][20][26]pasik@iki.fi > > > > > > 2. mailto:[14][15][21][27]pasik@iki.fi > > > > > > 3. [15][16][22][28]http://kernel.org/ > > > > > > 4. [16][17][23][29]http://kernel.org/ > > > > > > 5. > > mailto:[17][18][24][30]Xen-devel@lists.xen.org > > > > > > 6. > > [18][19][25][31]http://lists.xen.org/xen-devel > > > > > > 7. mailto:[19][20][26][32]pasik@iki.fi > > > > > > 8. [20][21][27][33]http://kernel.org/ > > > > > > 9. [21][22][28][34]http://kernel.org/ > > > > > > 10. > > mailto:[22][23][29][35]Xen-devel@lists.xen.org > > > > > > 11. > > [23][24][30][36]http://lists.xen.org/xen-devel > > > > > > > > > > References > > > > > > > > > > Visible links > > > > > 1. mailto:[25][31][37]pasik@iki.fi > > > > > 2. mailto:[26][32][38]pasik@iki.fi > > > > > 3. mailto:[27][33][39]pasik@iki.fi > > > > > 4. [28][34][40]http://kernel.org/ > > > > > 5. [29][35][41]http://kernel.org/ > > > > > 6. mailto:[30][36][42]Xen-devel@lists.xen.org > > > > > 7. [31][37][43]http://lists.xen.org/xen-devel > > > > > 8. mailto:[32][38][44]pasik@iki.fi > > > > > 9. [33][39][45]http://kernel.org/ > > > > > 10. [34][40][46]http://kernel.org/ > > > > > 11. mailto:[35][41][47]Xen-devel@lists.xen.org > > > > > 12. [36][42][48]http://lists.xen.org/xen-devel > > > > > 13. mailto:[37][43][49]pasik@iki.fi > > > > > 14. mailto:[38][44][50]pasik@iki.fi > > > > > 15. [39][45][51]http://kernel.org/ > > > > > 16. [40][46][52]http://kernel.org/ > > > > > 17. mailto:[41][47][53]Xen-devel@lists.xen.org > > > > > 18. [42][48][54]http://lists.xen.org/xen-devel > > > > > 19. mailto:[43][49][55]pasik@iki.fi > > > > > 20. [44][50][56]http://kernel.org/ > > > > > 21. [45][51][57]http://kernel.org/ > > > > > 22. mailto:[46][52][58]Xen-devel@lists.xen.org > > > > > 23. [47][53][59]http://lists.xen.org/xen-devel > > > > > > > > References > > > > > > > > Visible links > > > > 1. mailto:[54][60]pasik@iki.fi > > > > 2. mailto:[55][61]pasik@iki.fi > > > > 3. mailto:[56][62]pasik@iki.fi > > > > 4. mailto:[57][63]pasik@iki.fi > > > > 5. [58][64]http://kernel.org/ > > > > 6. [59][65]http://kernel.org/ > > > > 7. mailto:[60][66]Xen-devel@lists.xen.org > > > > 8. [61][67]http://lists.xen.org/xen-devel > > > > 9. mailto:[62][68]pasik@iki.fi > > > > 10. [63][69]http://kernel.org/ > > > > 11. [64][70]http://kernel.org/ > > > > 12. mailto:[65][71]Xen-devel@lists.xen.org > > > > 13. [66][72]http://lists.xen.org/xen-devel > > > > 14. mailto:[67][73]pasik@iki.fi > > > > 15. mailto:[68][74]pasik@iki.fi > > > > 16. [69][75]http://kernel.org/ > > > > 17. [70][76]http://kernel.org/ > > > > 18. mailto:[71][77]Xen-devel@lists.xen.org > > > > 19. [72][78]http://lists.xen.org/xen-devel > > > > 20. mailto:[73][79]pasik@iki.fi > > > > 21. [74][80]http://kernel.org/ > > > > 22. [75][81]http://kernel.org/ > > > > 23. mailto:[76][82]Xen-devel@lists.xen.org > > > > 24. [77][83]http://lists.xen.org/xen-devel > > > > 25. mailto:[78][84]pasik@iki.fi > > > > 26. mailto:[79][85]pasik@iki.fi > > > > 27. mailto:[80][86]pasik@iki.fi > > > > 28. [81][87]http://kernel.org/ > > > > 29. [82][88]http://kernel.org/ > > > > 30. mailto:[83][89]Xen-devel@lists.xen.org > > > > 31. [84][90]http://lists.xen.org/xen-devel > > > > 32. mailto:[85][91]pasik@iki.fi > > > > 33. [86][92]http://kernel.org/ > > > > 34. [87][93]http://kernel.org/ > > > > 35. mailto:[88][94]Xen-devel@lists.xen.org > > > > 36. [89][95]http://lists.xen.org/xen-devel > > > > 37. mailto:[90][96]pasik@iki.fi > > > > 38. mailto:[91][97]pasik@iki.fi > > > > 39. [92][98]http://kernel.org/ > > > > 40. [93][99]http://kernel.org/ > > > > 41. mailto:[94][100]Xen-devel@lists.xen.org > > > > 42. [95][101]http://lists.xen.org/xen-devel > > > > 43. mailto:[96][102]pasik@iki.fi > > > > 44. [97][103]http://kernel.org/ > > > > 45. [98][104]http://kernel.org/ > > > > 46. mailto:[99][105]Xen-devel@lists.xen.org > > > > 47. [100][106]http://lists.xen.org/xen-devel > > > > > > References > > > > > > Visible links > > > 1. mailto:[107]kiviniemi.valtteri@gmail.com > > > 2. [108]http://ark.intel.com/products/65719/ > > > 3. > > [109] > http://www.intel.com/content/www/us/en/motherboards/desktop-motherboards/= desktop-board-dq77mk.html > > > 4. mailto:[110]root@dataproof.fi > > > 5. mailto:[111]pasik@iki.fi > > > 6. [112]http://xen.org/ > > > 7. mailto:[113]pasik@iki.fi > > > 8. mailto:[114]pasik@iki.fi > > > 9. mailto:[115]pasik@iki.fi > > > 10. mailto:[116]pasik@iki.fi > > > 11. [117]http://kernel.org/ > > > 12. [118]http://kernel.org/ > > > 13. mailto:[119]Xen-devel@lists.xen.org > > > 14. [120]http://lists.xen.org/xen-devel > > > 15. mailto:[121]pasik@iki.fi > > > 16. [122]http://kernel.org/ > > > 17. [123]http://kernel.org/ > > > 18. mailto:[124]Xen-devel@lists.xen.org > > > 19. [125]http://lists.xen.org/xen-devel > > > 20. mailto:[126]pasik@iki.fi > > > 21. mailto:[127]pasik@iki.fi > > > 22. [128]http://kernel.org/ > > > 23. [129]http://kernel.org/ > > > 24. mailto:[130]Xen-devel@lists.xen.org > > > 25. [131]http://lists.xen.org/xen-devel > > > 26. mailto:[132]pasik@iki.fi > > > 27. [133]http://kernel.org/ > > > 28. [134]http://kernel.org/ > > > 29. mailto:[135]Xen-devel@lists.xen.org > > > 30. [136]http://lists.xen.org/xen-devel > > > 31. mailto:[137]pasik@iki.fi > > > 32. mailto:[138]pasik@iki.fi > > > 33. mailto:[139]pasik@iki.fi > > > 34. [140]http://kernel.org/ > > > 35. [141]http://kernel.org/ > > > 36. mailto:[142]Xen-devel@lists.xen.org > > > 37. [143]http://lists.xen.org/xen-devel > > > 38. mailto:[144]pasik@iki.fi > > > 39. [145]http://kernel.org/ > > > 40. [146]http://kernel.org/ > > > 41. mailto:[147]Xen-devel@lists.xen.org > > > 42. [148]http://lists.xen.org/xen-devel > > > 43. mailto:[149]pasik@iki.fi > > > 44. mailto:[150]pasik@iki.fi > > > 45. [151]http://kernel.org/ > > > 46. [152]http://kernel.org/ > > > 47. mailto:[153]Xen-devel@lists.xen.org > > > 48. [154]http://lists.xen.org/xen-devel > > > 49. mailto:[155]pasik@iki.fi > > > 50. [156]http://kernel.org/ > > > 51. [157]http://kernel.org/ > > > 52. mailto:[158]Xen-devel@lists.xen.org > > > 53. [159]http://lists.xen.org/xen-devel > > > 54. mailto:[160]pasik@iki.fi > > > 55. mailto:[161]pasik@iki.fi > > > 56. mailto:[162]pasik@iki.fi > > > 57. mailto:[163]pasik@iki.fi > > > 58. [164]http://kernel.org/ > > > 59. [165]http://kernel.org/ > > > 60. mailto:[166]Xen-devel@lists.xen.org > > > 61. [167]http://lists.xen.org/xen-devel > > > 62. mailto:[168]pasik@iki.fi > > > 63. [169]http://kernel.org/ > > > 64. [170]http://kernel.org/ > > > 65. mailto:[171]Xen-devel@lists.xen.org > > > 66. [172]http://lists.xen.org/xen-devel > > > 67. mailto:[173]pasik@iki.fi > > > 68. mailto:[174]pasik@iki.fi > > > 69. [175]http://kernel.org/ > > > 70. [176]http://kernel.org/ > > > 71. mailto:[177]Xen-devel@lists.xen.org > > > 72. [178]http://lists.xen.org/xen-devel > > > 73. mailto:[179]pasik@iki.fi > > > 74. [180]http://kernel.org/ > > > 75. [181]http://kernel.org/ > > > 76. mailto:[182]Xen-devel@lists.xen.org > > > 77. [183]http://lists.xen.org/xen-devel > > > 78. mailto:[184]pasik@iki.fi > > > 79. mailto:[185]pasik@iki.fi > > > 80. mailto:[186]pasik@iki.fi > > > 81. [187]http://kernel.org/ > > > 82. [188]http://kernel.org/ > > > 83. mailto:[189]Xen-devel@lists.xen.org > > > 84. [190]http://lists.xen.org/xen-devel > > > 85. mailto:[191]pasik@iki.fi > > > 86. [192]http://kernel.org/ > > > 87. [193]http://kernel.org/ > > > 88. mailto:[194]Xen-devel@lists.xen.org > > > 89. [195]http://lists.xen.org/xen-devel > > > 90. mailto:[196]pasik@iki.fi > > > 91. mailto:[197]pasik@iki.fi > > > 92. [198]http://kernel.org/ > > > 93. [199]http://kernel.org/ > > > 94. mailto:[200]Xen-devel@lists.xen.org > > > 95. [201]http://lists.xen.org/xen-devel > > > 96. mailto:[202]pasik@iki.fi > > > 97. [203]http://kernel.org/ > > > 98. [204]http://kernel.org/ > > > 99. mailto:[205]Xen-devel@lists.xen.org > > > 100. [206]http://lists.xen.org/xen-devel > > > > References > > > > Visible links > > 1. http://nago.fi/dmesg.txt > > 2. http://nago.fi/qemu-dm.txt > > 3. http://nago.fi/xm-dmesg.txt > > 4. http://nago.fi/domu-config.txt > > 5. http://nago.fi/dom0-config.txt > > 6. mailto:pasik@iki.fi > > 7. mailto:kiviniemi.valtteri@gmail.com > > 8. http://ark.intel.com/products/65719/ > > 9. > http://www.intel.com/content/www/us/en/motherboards/desktop-motherboards/= desktop-board-dq77mk.html > > 10. mailto:root@dataproof.fi > > 11. mailto:pasik@iki.fi > > 12. http://xen.org/ > > 13. mailto:pasik@iki.fi > > 14. mailto:pasik@iki.fi > > 15. mailto:pasik@iki.fi > > 16. mailto:pasik@iki.fi > > 17. http://kernel.org/ > > 18. http://kernel.org/ > > 19. mailto:Xen-devel@lists.xen.org > > 20. http://lists.xen.org/xen-devel > > 21. mailto:pasik@iki.fi > > 22. http://kernel.org/ > > 23. http://kernel.org/ > > 24. mailto:Xen-devel@lists.xen.org > > 25. http://lists.xen.org/xen-devel > > 26. mailto:pasik@iki.fi > > 27. mailto:pasik@iki.fi > > 28. http://kernel.org/ > > 29. http://kernel.org/ > > 30. mailto:Xen-devel@lists.xen.org > > 31. http://lists.xen.org/xen-devel > > 32. mailto:pasik@iki.fi > > 33. http://kernel.org/ > > 34. http://kernel.org/ > > 35. mailto:Xen-devel@lists.xen.org > > 36. http://lists.xen.org/xen-devel > > 37. mailto:pasik@iki.fi > > 38. mailto:pasik@iki.fi > > 39. mailto:pasik@iki.fi > > 40. http://kernel.org/ > > 41. http://kernel.org/ > > 42. mailto:Xen-devel@lists.xen.org > > 43. http://lists.xen.org/xen-devel > > 44. mailto:pasik@iki.fi > > 45. http://kernel.org/ > > 46. http://kernel.org/ > > 47. mailto:Xen-devel@lists.xen.org > > 48. http://lists.xen.org/xen-devel > > 49. mailto:pasik@iki.fi > > 50. mailto:pasik@iki.fi > > 51. http://kernel.org/ > > 52. http://kernel.org/ > > 53. mailto:Xen-devel@lists.xen.org > > 54. http://lists.xen.org/xen-devel > > 55. mailto:pasik@iki.fi > > 56. http://kernel.org/ > > 57. http://kernel.org/ > > 58. mailto:Xen-devel@lists.xen.org > > 59. http://lists.xen.org/xen-devel > > 60. mailto:pasik@iki.fi > > 61. mailto:pasik@iki.fi > > 62. mailto:pasik@iki.fi > > 63. mailto:pasik@iki.fi > > 64. http://kernel.org/ > > 65. http://kernel.org/ > > 66. mailto:Xen-devel@lists.xen.org > > 67. http://lists.xen.org/xen-devel > > 68. mailto:pasik@iki.fi > > 69. http://kernel.org/ > > 70. http://kernel.org/ > > 71. mailto:Xen-devel@lists.xen.org > > 72. http://lists.xen.org/xen-devel > > 73. mailto:pasik@iki.fi > > 74. mailto:pasik@iki.fi > > 75. http://kernel.org/ > > 76. http://kernel.org/ > > 77. mailto:Xen-devel@lists.xen.org > > 78. http://lists.xen.org/xen-devel > > 79. mailto:pasik@iki.fi > > 80. http://kernel.org/ > > 81. http://kernel.org/ > > 82. mailto:Xen-devel@lists.xen.org > > 83. http://lists.xen.org/xen-devel > > 84. mailto:pasik@iki.fi > > 85. mailto:pasik@iki.fi > > 86. mailto:pasik@iki.fi > > 87. http://kernel.org/ > > 88. http://kernel.org/ > > 89. mailto:Xen-devel@lists.xen.org > > 90. http://lists.xen.org/xen-devel > > 91. mailto:pasik@iki.fi > > 92. http://kernel.org/ > > 93. http://kernel.org/ > > 94. mailto:Xen-devel@lists.xen.org > > 95. http://lists.xen.org/xen-devel > > 96. mailto:pasik@iki.fi > > 97. mailto:pasik@iki.fi > > 98. http://kernel.org/ > > 99. http://kernel.org/ > > 100. mailto:Xen-devel@lists.xen.org > > 101. http://lists.xen.org/xen-devel > > 102. mailto:pasik@iki.fi > > 103. http://kernel.org/ > > 104. http://kernel.org/ > > 105. mailto:Xen-devel@lists.xen.org > > 106. http://lists.xen.org/xen-devel > > 107. mailto:kiviniemi.valtteri@gmail.com > > 108. http://ark.intel.com/products/65719/ > > 109. > http://www.intel.com/content/www/us/en/motherboards/desktop-motherboards/= desktop-board-dq77mk.html > > 110. mailto:root@dataproof.fi > > 111. mailto:pasik@iki.fi > > 112. http://xen.org/ > > 113. mailto:pasik@iki.fi > > 114. mailto:pasik@iki.fi > > 115. mailto:pasik@iki.fi > > 116. mailto:pasik@iki.fi > > 117. http://kernel.org/ > > 118. http://kernel.org/ > > 119. mailto:Xen-devel@lists.xen.org > > 120. http://lists.xen.org/xen-devel > > 121. mailto:pasik@iki.fi > > 122. http://kernel.org/ > > 123. http://kernel.org/ > > 124. mailto:Xen-devel@lists.xen.org > > 125. http://lists.xen.org/xen-devel > > 126. mailto:pasik@iki.fi > > 127. mailto:pasik@iki.fi > > 128. http://kernel.org/ > > 129. http://kernel.org/ > > 130. mailto:Xen-devel@lists.xen.org > > 131. http://lists.xen.org/xen-devel > > 132. mailto:pasik@iki.fi > > 133. http://kernel.org/ > > 134. http://kernel.org/ > > 135. mailto:Xen-devel@lists.xen.org > > 136. http://lists.xen.org/xen-devel > > 137. mailto:pasik@iki.fi > > 138. mailto:pasik@iki.fi > > 139. mailto:pasik@iki.fi > > 140. http://kernel.org/ > > 141. http://kernel.org/ > > 142. mailto:Xen-devel@lists.xen.org > > 143. http://lists.xen.org/xen-devel > > 144. mailto:pasik@iki.fi > > 145. http://kernel.org/ > > 146. http://kernel.org/ > > 147. mailto:Xen-devel@lists.xen.org > > 148. http://lists.xen.org/xen-devel > > 149. mailto:pasik@iki.fi > > 150. mailto:pasik@iki.fi > > 151. http://kernel.org/ > > 152. http://kernel.org/ > > 153. mailto:Xen-devel@lists.xen.org > > 154. http://lists.xen.org/xen-devel > > 155. mailto:pasik@iki.fi > > 156. http://kernel.org/ > > 157. http://kernel.org/ > > 158. mailto:Xen-devel@lists.xen.org > > 159. http://lists.xen.org/xen-devel > > 160. mailto:pasik@iki.fi > > 161. mailto:pasik@iki.fi > > 162. mailto:pasik@iki.fi > > 163. mailto:pasik@iki.fi > > 164. http://kernel.org/ > > 165. http://kernel.org/ > > 166. mailto:Xen-devel@lists.xen.org > > 167. http://lists.xen.org/xen-devel > > 168. mailto:pasik@iki.fi > > 169. http://kernel.org/ > > 170. http://kernel.org/ > > 171. mailto:Xen-devel@lists.xen.org > > 172. http://lists.xen.org/xen-devel > > 173. mailto:pasik@iki.fi > > 174. mailto:pasik@iki.fi > > 175. http://kernel.org/ > > 176. http://kernel.org/ > > 177. mailto:Xen-devel@lists.xen.org > > 178. http://lists.xen.org/xen-devel > > 179. mailto:pasik@iki.fi > > 180. http://kernel.org/ > > 181. http://kernel.org/ > > 182. mailto:Xen-devel@lists.xen.org > > 183. http://lists.xen.org/xen-devel > > 184. mailto:pasik@iki.fi > > 185. mailto:pasik@iki.fi > > 186. mailto:pasik@iki.fi > > 187. http://kernel.org/ > > 188. http://kernel.org/ > > 189. mailto:Xen-devel@lists.xen.org > > 190. http://lists.xen.org/xen-devel > > 191. mailto:pasik@iki.fi > > 192. http://kernel.org/ > > 193. http://kernel.org/ > > 194. mailto:Xen-devel@lists.xen.org > > 195. http://lists.xen.org/xen-devel > > 196. mailto:pasik@iki.fi > > 197. mailto:pasik@iki.fi > > 198. http://kernel.org/ > > 199. http://kernel.org/ > > 200. mailto:Xen-devel@lists.xen.org > > 201. http://lists.xen.org/xen-devel > > 202. mailto:pasik@iki.fi > > 203. http://kernel.org/ > > 204. http://kernel.org/ > > 205. mailto:Xen-devel@lists.xen.org > > 206. http://lists.xen.org/xen-devel > --20cf30563c0d436e7b04cb13c0b5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I have not enabled debug on Xen or dom0 kernel. Could you tell m= e the parameters for Xen coompilation needed to enable debugging? And If yo= u would also happen to know what are the options needed to enable kernel de= bugging in menuconfig? Well I can probably manage to get the kernel debuggi= ng enabled myself, but if you happen to know them please share so maybe I c= an get everything enabled at the first try :)

Thanks!

- Valtteri

2012/10/2 P= asi K=E4rkk=E4inen <pasik@iki.fi>
On Tue, Oct 02, 2012 at 04:01:04PM +0300, Valtteri Kivini= emi wrote:
> =A0 =A0Hi,
>
> =A0 =A0I already tried 3.2, 3.5, 3.5.0, 3.6.0-= rc7 and 3.6.0, same problem all of
> =A0 =A0those. My dom0 config is the same config that I'am using on= other server
> =A0 =A0where HVM is working, so I dont think that it is a config probl= em. I have
> =A0 =A0triple checked everything and all should be ok. dom0 dmesg show= s the same
> =A0 =A0crash that I have previously posted here. /var/log/xen/ does no= t contain
> =A0 =A0any specific errors.
>
> =A0 =A0Could this be some kind of broblem with my motherboard bios bei= ng buggy or
> =A0 =A0CPU not supported? I'm using the new intel Ivy Bridge proce= ssor which has
> =A0 =A0integrated GPU, but that should not probably cause these kind o= f problems.
> =A0 =A0Or maybe some ACPI problem? xm dmesg is showing some notices ab= out ACPI.
> =A0 =A0Is there any ACPI kernel parameters that I should try booting? = This has to
> =A0 =A0be somekind of problem with my hardware, or then maybe it could= be a
> =A0 =A0kernel problem too. I just really cant figure this out myself, = I have
> =A0 =A0tried everything.
>

Hmm.. I have some distant memories of seeing a patch that fixes a bug=
on recent Ivy Bridge systems, but I can't find a link right now.
Maybe you're affected by that..

Also: Did you already post the crash log, with all the debug/verbose option= s enabled for both Xen and dom0 kernel?

-- Pasi

> =A0 =A0Lets take a quick summary of what has been tested, what hardwar= e I'm using
> =A0 =A0etc.
>
> =A0 =A0Xen-versions tested: 4.2.0, 4.0.4
> =A0 =A0Kernel-versions tested: 3.2.0, 3.5.0, 3.5.4, 3.6.0-rc7, 3.6.0 >
> =A0 =A0Host OS: Debian testing/wheezy, udev version 175-7, 2.13-35, py= thon
> =A0 =A0version 2.7.3~rc2-2.1
>
> =A0 =A0Hardware:
>
> =A0 =A0CPU: Intel Core i7-3770 3.4GHz
> =A0 =A0MB: Intel DQ77MK (latest bios updated)
> =A0 =A0Memory: 32GB (4 x 8GB DDR3-1600MHz)
>
> =A0 =A0All relevant log files and configs:
>
> =A0 =A0dom0 dmesg: [1]http://nago.fi/dmesg.txt
> =A0 =A0qemu-dm log: [2]http://nago.fi/qemu-dm.txt
> =A0 =A0xm dmesg log: [3]http://nago.fi/xm-dmesg.txt
> =A0 =A0domU config: [4]http://nago.fi/domu-config.txt
> =A0 =A0dom0 kernel config: [5]http://nago.fi/dom0-config.txt
>
> =A0 =A0I have also tried playing with every setting on that domU that = I can think
> =A0 =A0of and tried different configs etc.
>
> =A0 =A0- Valtteri
>
> =A0 =A02012/10/2 Pasi K=E4rkk=E4inen <[6]pasik@iki.fi>
>
> =A0 =A0 =A0On Tue, Oct 02, 2012 at 03:11:07PM +0300, Valtteri Kiviniem= i wrote:
> =A0 =A0 =A0> =A0 =A0Hi,
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0Another update:
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0I wanted to check that if a Linux HVM would boo= t with working VNC
> =A0 =A0 =A0console,
> =A0 =A0 =A0> =A0 =A0so I tried to launch a Debian Squeeze installer= on HVM. It refused
> =A0 =A0 =A0to
> =A0 =A0 =A0> =A0 =A0start ant told me that vbd hotplug scripts were= not working. After
> =A0 =A0 =A0that
> =A0 =A0 =A0> =A0 =A0failure even the Windows domU would not anymore= start which was
> =A0 =A0 =A0previously
> =A0 =A0 =A0> =A0 =A0starting ok.
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0The hotplug scripts also starts hanging on the = processes.
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0root =A0 =A0 =A09401 =A00.1 =A00.1 =A017700 =A0= 1640 ? =A0 =A0 =A0 =A0S =A0 =A015:05 =A0 0:00
> =A0 =A0 =A0/bin/bash
> =A0 =A0 =A0> =A0 =A0/etc/xen/scripts/xen-hotplug-cleanup
> =A0 =A0 =A0> =A0 =A0root =A0 =A0 =A09441 =A00.1 =A00.1 =A017700 =A0= 1644 ? =A0 =A0 =A0 =A0S =A0 =A015:05 =A0 0:00
> =A0 =A0 =A0/bin/bash
> =A0 =A0 =A0> =A0 =A0/etc/xen/scripts/xen-hotplug-cleanup
> =A0 =A0 =A0> =A0 =A0root =A0 =A0 =A09481 =A00.1 =A00.1 =A017700 =A0= 1640 ? =A0 =A0 =A0 =A0S =A0 =A015:05 =A0 0:00
> =A0 =A0 =A0/bin/bash
> =A0 =A0 =A0> =A0 =A0/etc/xen/scripts/xen-hotplug-cleanup
> =A0 =A0 =A0> =A0 =A0root =A0 =A0 =A09560 =A00.1 =A00.1 =A017700 =A0= 1640 ? =A0 =A0 =A0 =A0S =A0 =A015:05 =A0 0:00
> =A0 =A0 =A0/bin/bash
> =A0 =A0 =A0> =A0 =A0/etc/xen/scripts/xen-hotplug-cleanup
> =A0 =A0 =A0> =A0 =A0root =A0 =A0 10738 =A00.1 =A00.1 =A017696 =A016= 36 ? =A0 =A0 =A0 =A0S =A0 =A015:05 =A0 0:00
> =A0 =A0 =A0/bin/bash
> =A0 =A0 =A0> =A0 =A0/etc/xen/scripts/xen-hotplug-cleanup
> =A0 =A0 =A0> =A0 =A0root =A0 =A0 10747 =A00.1 =A00.1 =A017792 =A017= 36 ? =A0 =A0 =A0 =A0S =A0 =A015:05 =A0 0:00
> =A0 =A0 =A0/bin/bash
> =A0 =A0 =A0> =A0 =A0/etc/xen/scripts/block remove
> =A0 =A0 =A0> =A0 =A0root =A0 =A0 11286 =A00.0 =A00.0 =A0 4080 =A0 3= 24 ? =A0 =A0 =A0 =A0S =A0 =A015:06 =A0 0:00
> =A0 =A0 =A0sleep 1
> =A0 =A0 =A0> =A0 =A0root =A0 =A0 11290 =A00.0 =A00.0 =A0 4080 =A0 3= 24 ? =A0 =A0 =A0 =A0S =A0 =A015:06 =A0 0:00
> =A0 =A0 =A0sleep 1
> =A0 =A0 =A0> =A0 =A0root =A0 =A0 11294 =A00.0 =A00.0 =A0 4080 =A0 3= 24 ? =A0 =A0 =A0 =A0S =A0 =A015:06 =A0 0:00
> =A0 =A0 =A0sleep 1
> =A0 =A0 =A0> =A0 =A0root =A0 =A0 11298 =A00.0 =A00.0 =A0 4080 =A0 3= 24 ? =A0 =A0 =A0 =A0S =A0 =A015:06 =A0 0:00
> =A0 =A0 =A0sleep 1
> =A0 =A0 =A0> =A0 =A0root =A0 =A0 11302 =A00.0 =A00.0 =A0 4080 =A0 3= 20 ? =A0 =A0 =A0 =A0S =A0 =A015:06 =A0 0:00
> =A0 =A0 =A0sleep 1
> =A0 =A0 =A0> =A0 =A0root =A0 =A0 11306 =A00.0 =A00.0 =A0 4080 =A0 3= 20 ? =A0 =A0 =A0 =A0S =A0 =A015:06 =A0 0:00
> =A0 =A0 =A0sleep 1
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0Then I did a xm destroy and I had again the ker= nel BUG on dmesg. So
> =A0 =A0 =A0it
> =A0 =A0 =A0> =A0 =A0seems that the problem is not fixed by using 3.= 6.0. Udev version is
> =A0 =A0 =A0175-7.
> =A0 =A0 =A0>
>
> =A0 =A0 =A0So you have definitely something broken in your system,
> =A0 =A0 =A0probably in your dom0 kernel. Try with Linux 3.5.4 or 3.4.x= ,
> =A0 =A0 =A0and see how that goes.
>
> =A0 =A0 =A0Any errors in dom0 dmesg? How about in /var/log/xen/* ?
>
> =A0 =A0 =A0-- Pasi
>
> =A0 =A0 =A0>
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A02012/10/1 Valtteri Kiviniemi <[1= ][7]kiviniemi.valtteri@gmai= l.com>
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0Hi,
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0CPU: Intel Core i7-3770 3.4GHz
> =A0 =A0 =A0> =A0 =A0 =A0[2][8]http://ark.intel.com/products/65719/
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0MB: Intel DQ77MK (latest bios updated)
> =A0 =A0 =A0>
> =A0 =A0 =A0 [3][9]http://www.intel.com/content/www/us/en/motherboards/desktop-motherb= oards/desktop-board-dq77mk.html
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0Memory: 32GB (4 x 8GB DDR3-1600MHz)
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0Host is Debian wheezy/testing, Xen 4.0.4 an= d latest 3.6.0 kernel.
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0Noticed also some errors in xm dmesg:
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0root@xen-2:~# xm dmesg
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Xen version 4.0.4 ([4][10]root@dataproof.fi) (gcc version
> =A0 =A0 =A04.7.1
> =A0 =A0 =A0> =A0 =A0 =A0(Debian 4.7.1-7) ) Sun Sep 30 20:28:26 EEST= 2012
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Latest ChangeSet: unavailable
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Bootloader: GNU GRUB 0.97
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Command line: dom0_mem=3D1280M cpufre= q=3Dxen clocksource=3Dhpet
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Video information:
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0VGA is text mode 80x25, font 8x16<= br> > =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0VBE/DDC methods: none; EDID transf= er time: 0 seconds
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0EDID info not retrieved because no= DDC retrieval method
> =A0 =A0 =A0detected
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Disc information:
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0Found 4 MBR signatures
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0Found 4 EDD information structures=
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Xen-e820 RAM map:
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A00000000000000000 - 000000000009d80= 0 (usable)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0000000000009d800 - 00000000000a000= 0 (reserved)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A000000000000e0000 - 000000000010000= 0 (reserved)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A00000000000100000 - 000000002000000= 0 (usable)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A00000000020000000 - 000000002020000= 0 (reserved)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A00000000020200000 - 000000004000400= 0 (usable)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A00000000040004000 - 000000004000500= 0 (reserved)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A00000000040005000 - 00000000dbe4400= 0 (usable)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A000000000dbe44000 - 00000000dc2d700= 0 (reserved)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A000000000dc2d7000 - 00000000dc2e700= 0 (ACPI data)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A000000000dc2e7000 - 00000000dc40c00= 0 (ACPI NVS)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A000000000dc40c000 - 00000000dc6af00= 0 (reserved)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A000000000dc6af000 - 00000000dc6b000= 0 (usable)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A000000000dc6b0000 - 00000000dc6f300= 0 (ACPI NVS)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A000000000dc6f3000 - 00000000dd00000= 0 (usable)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A000000000dd800000 - 00000000dfa0000= 0 (reserved)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A000000000f8000000 - 00000000fc00000= 0 (reserved)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A000000000fec00000 - 00000000fec0100= 0 (reserved)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A000000000fed00000 - 00000000fed0400= 0 (reserved)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A000000000fed1c000 - 00000000fed2000= 0 (reserved)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A000000000fee00000 - 00000000fee0100= 0 (reserved)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A000000000ff000000 - 000000010000000= 0 (reserved)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A00000000100000000 - 000000081e60000= 0 (usable)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) ACPI: RSDP 000F0490, 0024 (r2 =A0INTE= L)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) ACPI: XSDT DC2DB080, 007C (r1 INTEL = =A0DQ77MK =A0 =A0 =A0 =A0 32 AMI
> =A0 =A0 =A0> =A0 =A0 =A010013)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) ACPI: FACP DC2E51F0, 010C (r5 INTEL = =A0DQ77MK =A0 =A0 =A0 =A0 32 AMI
> =A0 =A0 =A0> =A0 =A0 =A010013)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) ACPI Warning (tbfadt-0232): FADT (rev= ision 5) is longer
> =A0 =A0 =A0than ACPI
> =A0 =A0 =A0> =A0 =A0 =A02.0 version, truncating length 0x10C to 0xF= 4 [20070126]
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) ACPI: DSDT DC2DB188, A061 (r2 INTEL = =A0DQ77MK =A0 =A0 =A0 =A0 32 INTL
> =A0 =A0 =A0> =A0 =A0 =A020051117)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) ACPI: FACS DC40A080, 0040
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) ACPI: APIC DC2E5300, 0092 (r3 INTEL = =A0DQ77MK =A0 =A0 =A0 =A0 32 AMI
> =A0 =A0 =A0> =A0 =A0 =A010013)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) ACPI: FPDT DC2E5398, 0044 (r1 INTEL = =A0DQ77MK =A0 =A0 =A0 =A0 32 AMI
> =A0 =A0 =A0> =A0 =A0 =A010013)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) ACPI: TCPA DC2E53E0, 0032 (r2 INTEL = =A0DQ77MK =A0 =A0 =A0 =A0 32 MSFT
> =A0 =A0 =A0> =A0 =A0 =A01000013)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) ACPI: MCFG DC2E5418, 003C (r1 INTEL = =A0DQ77MK =A0 =A0 =A0 =A0 32 MSFT
> =A0 =A0 =A0> =A0 =A0 =A097)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) ACPI: HPET DC2E5458, 0038 (r1 INTEL = =A0DQ77MK =A0 =A0 =A0 =A0 32 AMI.
> =A0 =A0 =A0> =A0 =A0 =A05)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) ACPI: SSDT DC2E5490, 036D (r1 INTEL = =A0DQ77MK =A0 =A0 =A0 =A0 32 INTL
> =A0 =A0 =A0> =A0 =A0 =A020091112)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) ACPI: SSDT DC2E5800, 09AA (r1 INTEL = =A0DQ77MK =A0 =A0 =A0 =A0 32 INTL
> =A0 =A0 =A0> =A0 =A0 =A020051117)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) ACPI: SSDT DC2E61B0, 0A92 (r1 INTEL = =A0DQ77MK =A0 =A0 =A0 =A0 32 INTL
> =A0 =A0 =A0> =A0 =A0 =A020051117)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) ACPI: DMAR DC2E6C48, 00B8 (r1 INTEL = =A0DQ77MK =A0 =A0 =A0 =A0 32 INTL
> =A0 =A0 =A0> =A0 =A0 =A01)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) ACPI: ASF! DC2E6D00, 00A5 (r32 INTEL = =A0DQ77MK =A0 =A0 =A0 =A0 32
> =A0 =A0 =A0TFSM
> =A0 =A0 =A0> =A0 =A0 =A0F4240)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) System RAM: 32682MB (33467320kB)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Domain heap initialised
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) ACPI: 32/64X FACS address mismatch in= FADT -
> =A0 =A0 =A0> =A0 =A0 =A0dc40a080/0000000000000000, using 32
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Processor #0 7:10 APIC version 21
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Processor #2 7:10 APIC version 21
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Processor #4 7:10 APIC version 21
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Processor #6 7:10 APIC version 21
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Processor #1 7:10 APIC version 21
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Processor #3 7:10 APIC version 21
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Processor #5 7:10 APIC version 21
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Processor #7 7:10 APIC version 21
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) IOAPIC[0]: apic_id 2, version 32, add= ress 0xfec00000, GSI
> =A0 =A0 =A00-23
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Enabling APIC mode: =A0Flat. =A0Using= 1 I/O APICs
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Switched to APIC driver x2apic_cluste= r.
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) x2APIC mode enabled.
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Using scheduler: SMP Credit Scheduler= (credit)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Detected 3392.369 MHz processor.
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Initing memory sharing.
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) VMX: Supported advanced features:
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0- APIC MMIO access virtualisation<= br> > =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0- APIC TPR shadow
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0- Extended Page Tables (EPT)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0- Virtual-Processor Identifiers (V= PID)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0- Virtual NMI
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0- MSR direct-access bitmap
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0- Unrestricted Guest
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) EPT supports 2MB super page.
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) HVM: ASIDs enabled.
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) HVM: VMX enabled
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) HVM: Hardware Assisted Paging detecte= d.
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Intel VT-d Snoop Control not enabled.=
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Intel VT-d Dom0 DMA Passthrough not e= nabled.
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Intel VT-d Queued Invalidation enable= d.
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Intel VT-d Interrupt Remapping enable= d.
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) I/O virtualisation enabled
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0- Dom0 mode: Relaxed
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Enabled directed EOI with ioapic_ack_= old on!
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Total of 8 processors activated.
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) ENABLING IO-APIC IRQs
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0-> Using old ACK method
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) TSC is reliable, synchronization unne= cessary
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Platform timer appears to have unexpe= ctedly wrapped 1
> =A0 =A0 =A0times.
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Platform timer is 14.318MHz HPET
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Allocated console ring of 16 KiB.
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Brought up 8 CPUs
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) *** LOADING DOMAIN 0 ***
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0Xen =A0kernel: 64-bit, lsb, compat= 32
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0Dom0 kernel: 64-bit, PAE, lsb, pad= dr 0x1000000 ->
> =A0 =A0 =A00x1ae7000
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) PHYSICAL MEMORY ARRANGEMENT:
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0Dom0 alloc.: =A0 0000000804000000-= >0000000806000000 (319488
> =A0 =A0 =A0pages
> =A0 =A0 =A0> =A0 =A0 =A0to be allocated)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) VIRTUAL MEMORY ARRANGEMENT:
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0Loaded kernel: ffffffff81000000-&g= t;ffffffff81ae7000
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0Init. ramdisk: ffffffff81ae7000-&g= t;ffffffff81ae7000
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0Phys-Mach map: ffffffff81ae7000-&g= t;ffffffff81d67000
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0Start info: =A0 =A0ffffffff81d6700= 0->ffffffff81d674b4
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0Page tables: =A0 ffffffff81d68000-= >ffffffff81d7b000
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0Boot stack: =A0 =A0ffffffff81d7b00= 0->ffffffff81d7c000
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0TOTAL: =A0 =A0 =A0 =A0 ffffffff800= 00000->ffffffff82000000
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0ENTRY ADDRESS: ffffffff815e3210 > =A0 =A0 =A0> =A0 =A0 =A0(XEN) Dom0 has maximum 8 VCPUs
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) [VT-D]iommu.c:718: BIOS did not enabl= e IGD for VT properly.
> =A0 =A0 =A0> =A0 =A0 =A0Disabling IGD VT-d engine.
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Scrubbing Free RAM: done.
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Xen trace buffers: disabled
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Std. Loglevel: Errors and warnings > =A0 =A0 =A0> =A0 =A0 =A0(XEN) Guest Loglevel: Nothing (Rate-limited= : Errors and warnings)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Xen is relinquishing VGA console.
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) *** Serial input -> DOM0 (type = 9;CTRL-a' three times to
> =A0 =A0 =A0switch
> =A0 =A0 =A0> =A0 =A0 =A0input to Xen)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Freed 172kB init memory.
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) traps.c:2333:d0 Domain attempted WRMS= R 000000000000008b
> =A0 =A0 =A0from
> =A0 =A0 =A0> =A0 =A0 =A000000012:00000000 to 00000000:00000000.
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0- Valtteri
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A02012/10/1 Pasi K=E4rkk=E4inen &= lt;[5][11]pasik@iki.fi>
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0On Mon, Oct 01, 2012 at 09:12:50PM +030= 0, Valtteri Kiviniemi
> =A0 =A0 =A0wrote:
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0Hi,
> =A0 =A0 =A0> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0Lowering memory or vcpu'= ;s does not help, problem is the
> =A0 =A0 =A0same. I
> =A0 =A0 =A0> =A0 =A0 =A0 =A0originally
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0installed Xen 4.2.0 and the= problem was same on that too.
> =A0 =A0 =A0Then I
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0downgraded back to 4.0.4 si= nce I thought that this might
> =A0 =A0 =A0be a bug
> =A0 =A0 =A0> =A0 =A0 =A0 =A0on
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A04.2.0. I have been previous= ly running Windows Server 2008
> =A0 =A0 =A0R2
> =A0 =A0 =A0> =A0 =A0 =A0 =A0succesfully
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0on Xen 4.0.x on different h= ardware with this same config.
> =A0 =A0 =A0> =A0 =A0 =A0 =A0Hypervisor is
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A064bit and windows is 64bit.=
> =A0 =A0 =A0> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0Any ideas what to try next?=
> =A0 =A0 =A0> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0What kind of hardware is that?
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0[6][12]xen.org automated testing regularly tests Windows VM= s,
> =A0 =A0 =A0and it works
> =A0 =A0 =A0> =A0 =A0 =A0 =A0OK there.
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0-- Pasi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0Ps. qemu-dm.log is the foll= owing:
> =A0 =A0 =A0> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0domid: 10
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0config qemu network with xe= n bridge for =A0tap10.0 xenbr0
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0Using file /dev/virtuals/ts= in read-write mode
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0Using file /media/iso/windo= ws_server_2008_r2_sp1.iso in
> =A0 =A0 =A0read-only
> =A0 =A0 =A0> =A0 =A0 =A0 =A0mode
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0Watching /local/domain/0/de= vice-model/10/logdirty/cmd
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0Watching /local/domain/0/de= vice-model/10/command
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0qemu_map_cache_init nr_buck= ets =3D 10000 size 4194304
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0shared page at pfn feffd > =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0buffered io page at pfn fef= fb
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0Guest uuid =3D 52f19e23-295= 5-c27d-a22c-60c5d8c60d5a
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0Time offset set 0
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0populating video RAM at ff0= 00000
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0mapping video RAM from ff00= 0000
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0Register xen platform.
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0Done register platform.
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0platform_fixed_ioport: chan= ged ro/rw state of ROM memory
> =A0 =A0 =A0area.
> =A0 =A0 =A0> =A0 =A0 =A0 =A0now is rw
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0state.
> =A0 =A0 =A0> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0 xs_read(/local/domain/0/device-model/10/xen_extended_power= _mgmt):
> =A0 =A0 =A0> =A0 =A0 =A0 =A0read
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0error
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0medium change watch on `hdc= ' (index: 1):
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0/media/iso/windows_server_2= 008_r2_sp1.iso
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0I/O request not ready: 0, p= tr: 0, port: 0, data: 0, count:
> =A0 =A0 =A00,
> =A0 =A0 =A0> =A0 =A0 =A0 =A0size: 0
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0Log-dirty: no command yet.<= br> > =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0xs_read(/local/domain/10/lo= g-throttling): read error
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0qemu: ignoring not-understo= od drive
> =A0 =A0 =A0> =A0 =A0 =A0 =A0`/local/domain/10/log-throttling' > =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0medium change watch on `/lo= cal/domain/10/log-throttling' -
> =A0 =A0 =A0> =A0 =A0 =A0 =A0unknown device,
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0ignored
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0cirrus vga map change while= on lfb mode
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0mapping vram to f0000000 - = f0400000
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0platform_fixed_ioport: chan= ged ro/rw state of ROM memory
> =A0 =A0 =A0area.
> =A0 =A0 =A0> =A0 =A0 =A0 =A0now is rw
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0state.
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0platform_fixed_ioport: chan= ged ro/rw state of ROM memory
> =A0 =A0 =A0area.
> =A0 =A0 =A0> =A0 =A0 =A0 =A0now is ro
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0state.
> =A0 =A0 =A0> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A02012/10/1 Pasi = K=E4rkk=E4inen <[1][7][13]pasik@iki.fi>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0On Mon, Oct 01, 2012 at= 07:23:44PM +0300, Valtteri
> =A0 =A0 =A0Kiviniemi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0wrote:
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0Hi,
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0I have trie= d other config files, but the problem is
> =A0 =A0 =A0the
> =A0 =A0 =A0> =A0 =A0 =A0 =A0same. At
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0the
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0moment I= 9;m using a config file from another server
> =A0 =A0 =A0where I
> =A0 =A0 =A0> =A0 =A0 =A0 =A0have a
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0working
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0Windows Ser= ver 2008 R2 installation, so I dont
> =A0 =A0 =A0think that
> =A0 =A0 =A0> =A0 =A0 =A0 =A0there is
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0anything wr= ong with my config:
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0Did you try with less v= cpus, for example 2 ?
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0how about with less mem= ory, say 2 GB ?
> =A0 =A0 =A0> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0Did you try with later = Xen versions? Is that a 32bit
> =A0 =A0 =A0Xen, or
> =A0 =A0 =A0> =A0 =A0 =A0 =A064bit Xen
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0hypervisor?
> =A0 =A0 =A0> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0-- Pasi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0kernel =3D = "/usr/lib/xen/boot/hvmloader"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0builder =3D= "hvm"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0shadow_memo= ry =3D "8"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0memory =3D = "4096"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0name =3D &q= uot;ts"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0vcpus =3D &= quot;8"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0cpus =3D [&= quot;0", "1", "2", "3", "4", &= quot;5", "6", "7"]
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0pae =3D &qu= ot;1"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0acpi =3D &q= uot;1"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0apic =3D &q= uot;1"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0vfb =3D [ &= #39;type=3Dvnc, vnclisten=3D10.100.100.50,
> =A0 =A0 =A0vncpasswd=3Dxxx'
> =A0 =A0 =A0> =A0 =A0 =A0 =A0]
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0xen_extende= d_power_mgmt =3D "0"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0vif =3D [ &= quot;type=3Dioemu, mac=3D00:16:3e:d7:d7:5d,
> =A0 =A0 =A0bridge=3Dxenbr0"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0]
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0disk =3D [ = "phy:/dev/virtuals/ts,hda,w",
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0 "file:/media/iso/windows_server_2= 008_r2_sp1.iso,hdc:cdrom,r" ]
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0on_poweroff= =3D "destroy"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0on_reboot = =3D "restart"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0on_crash = =3D "restart"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0viridian = =3D "1"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0device_mode= l =3D "/usr/lib/xen/bin/qemu-dm"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0boot =3D &q= uot;dc"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0snapshot = =3D "0"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0vncconsole = =3D "1"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0sdl =3D &qu= ot;0"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0opengl =3D = "0"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0vnc =3D &qu= ot;1"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0nographic = =3D "0"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0stdvga =3D = "0"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0tsc_mode = =3D "1"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0monitor =3D= "0"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0localtime = =3D "1"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0usb =3D &qu= ot;0"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0keymap =3D = "fi"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0xen_platfor= m_pci =3D "1"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0pci_msitran= slate =3D "1"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0pci_power_m= gmt =3D "0"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A02012/10/1 P= asi K=E4rkk=E4inen
> =A0 =A0 =A0<[1][2][8][14]pasik@iki.fi>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0><= br> > =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0On Mon,= Oct 01, 2012 at 06:46:08PM +0300,
> =A0 =A0 =A0Valtteri
> =A0 =A0 =A0> =A0 =A0 =A0 =A0Kiviniemi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0wrote:
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0Hi,
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> > =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0Yes, I have viridian=3D1 on my domU config.
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> > =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0Try wit= h some known good domU configfile.
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0-- Pasi=
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A02012/10/1 Pasi K=E4rkk=E4inen
> =A0 =A0 =A0> =A0 =A0 =A0 =A0<[1][2][3][9][15]pasik@iki.fi>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0= > =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0On Mon, Oct 01, 2012 at 05:06:53PM +0300,
> =A0 =A0 =A0> =A0 =A0 =A0 =A0Valtteri
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0Kiviniemi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0wrote:<= br> > =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0Hi,
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0I'm now using 3.6.0 and can't
> =A0 =A0 =A0reproduce that
> =A0 =A0 =A0> =A0 =A0 =A0 =A0crash
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0anymore,
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0so it > =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0seems
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0that it was a kernel bug.
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> > =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0OK.
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0However I'm still getting black
> =A0 =A0 =A0screen on
> =A0 =A0 =A0> =A0 =A0 =A0 =A0VNC
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0when trying to install Windows Server
> =A0 =A0 =A02008
> =A0 =A0 =A0> =A0 =A0 =A0 =A0R2. I can
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0see the
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0"windows is
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0loading files" screen but after the
> =A0 =A0 =A0> =A0 =A0 =A0 =A0installer starts
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0the VNC
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0display goes
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0black.
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0Any ideas?
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> > =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0Do you have viridian=3D1 specified for the
> =A0 =A0 =A0windows
> =A0 =A0 =A0> =A0 =A0 =A0 =A0vm?
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> > =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0-- Pasi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> > =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0- Valtteri
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A02012/10/1 Pasi K=E4rkk=E4inen
> =A0 =A0 =A0> =A0 =A0 =A0 =A0<[1][2][3][4][10][16]pasik@iki.fi>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0= > =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0On Sun, Sep 30, 2012 at 11:18:03PM
> =A0 =A0 =A0+0300,
> =A0 =A0 =A0> =A0 =A0 =A0 =A0Valtteri
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0Kivinie= mi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0wrote:
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0Hi,
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0Hello,
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0I'm trying to get Windows
> =A0 =A0 =A0Server 2008
> =A0 =A0 =A0> =A0 =A0 =A0 =A0R2
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0installation
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0booting on
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0Xen
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A04.0.4. Using the following
> =A0 =A0 =A0config:
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0<snip>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0The domU will start booting
> =A0 =A0 =A0just
> =A0 =A0 =A0> =A0 =A0 =A0 =A0fine, but
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0after a
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0few
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0minutes the
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0VNC
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0screen goes black. After that
> =A0 =A0 =A0when
> =A0 =A0 =A0> =A0 =A0 =A0 =A0typing "xm
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0destroy
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0ts"= ; it
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0will
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0trigger
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0a kernel BUG:
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0BUG: unable to handle kernel
> =A0 =A0 =A0NULL
> =A0 =A0 =A0> =A0 =A0 =A0 =A0pointer
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0dereference
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0at
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A00000000000000030
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0IP: [<ffffffff810c50c4>]
> =A0 =A0 =A0> =A0 =A0 =A0 =A0iput+0x3e/0x195
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0PGD 0
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0Oops: 0000 [#1] SMP
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0CPU 6
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0Pid: 3571, comm: qemu-dm Not
> =A0 =A0 =A0tainted
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A03.5.0-dom0 #1
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0First of all upgrade to latest
> =A0 =A0 =A03.5.x Linux
> =A0 =A0 =A0> =A0 =A0 =A0 =A0kernel
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0release
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0.. so > =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0at least
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A03.5.4.
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0-- Pasi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0/DQ77MK
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0RIP: e030:[<ffffffff810c50c4>]=
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0 [<ffffffff810c50c4&= gt;]
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0iput+0x3e/0x195
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0RSP: e02b:ffff8800389ffbf8
> =A0 =A0 =A0 EFLAGS:
> =A0 =A0 =A0> =A0 =A0 =A0 =A000010246
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0RAX: 0000000000000001 RBX:
> =A0 =A0 =A0> =A0 =A0 =A0 =A0ffff8800377b0720
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0RCX:
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0ffff8800501c0000
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0RDX: ffff8800501c0000 RSI:
> =A0 =A0 =A0> =A0 =A0 =A0 =A0ffff8800377b0790
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0RDI:
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0ffff8800377b0790
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0RBP: 0000000000000000 R08:
> =A0 =A0 =A0> =A0 =A0 =A0 =A0ffffffff815cdd00
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0R09:
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A00000000000000016
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0R10: fefefefefefefeff R11:
> =A0 =A0 =A0> =A0 =A0 =A0 =A0ffff8800377b0400
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0R12:
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A000000001000a3e0c
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0R13: 0000000000000000 R14:
> =A0 =A0 =A0> =A0 =A0 =A0 =A000000001000a3e0c
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0R15:
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0ffff8800389ffc28
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0FS: =A000007f1af70a8700(0000)
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0GS:ffff880050180000(000= 0)
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0knlGS:0000000000000000
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0CS: =A0e033 DS: 0000 ES: 0000
> =A0 =A0 =A0CR0:
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0000000008005003b
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0CR2: 0000000000000030 CR3:
> =A0 =A0 =A0> =A0 =A0 =A0 =A0000000000156d000
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0CR4:
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A00000000000002660
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0DR0: 0000000000000000 DR1:
> =A0 =A0 =A0> =A0 =A0 =A0 =A00000000000000000
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0DR2:
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A00000000000000000
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0DR3: 0000000000000000 DR6:
> =A0 =A0 =A0> =A0 =A0 =A0 =A000000000ffff0ff0
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0DR7:
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A00000000000000400
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0Process qemu-dm (pid: 3571,
> =A0 =A0 =A0> =A0 =A0 =A0 =A0threadinfo
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0ffff880= 0389fe000,
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0task
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0ffff88003a721260)
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0Stack:
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 ffff88003a6d6400
> =A0 =A0 =A0ffff8800377b0000
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A000000001000a3e0c
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0ffffffff8133ce8f
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 ffff8800377b0400
> =A0 =A0 =A0ffffffff8134b6cd
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0ffff8800389ffc28
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0ffff8800389ffc28
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 ffff8800377b00f8
> =A0 =A0 =A0ffff8800377b0680
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0ffff880038cdcd60
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0ffff8800377b0000
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0Call Trace:
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 [<ffffffff8133ce8f>] ?
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0sk_release_kernel+0x23/= 0x39
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 [<ffffffff8134b6cd>] ?
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0netdev_run_todo+0x1e9/0= x206
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 [<ffffffff8129798f>] ?
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0tun_chr_close+0x4c/0x7b=
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 [<ffffffff810b39d3>] ?
> =A0 =A0 =A0> =A0 =A0 =A0 =A0fput+0xe4/0x1c5
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 [<ffffffff810b202c>] ?
> =A0 =A0 =A0> =A0 =A0 =A0 =A0filp_close+0x61/0x68
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 [<ffffffff81035e62>] ?
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0put_files_struct+0x62/0= xb9
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 [<ffffffff81036374>] ?
> =A0 =A0 =A0> =A0 =A0 =A0 =A0do_exit+0x24a/0x74c
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 [<ffffffff81036906>] ?
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0do_group_exit+0x6b/0x9d=
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 [<ffffffff8103ea0b>] ?
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0get_sig= nal_to_deliver+0x449/0x46e
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 [<ffffffff81009fa5>] ?
> =A0 =A0 =A0> =A0 =A0 =A0 =A0do_signal+0x28/0x4c4
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 [<ffffffff81027079>] ?
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0pvclock= _clocksource_read+0x48/0xbf
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 [<ffffffff8105b745>] ?
> =A0 =A0 =A0> =A0 =A0 =A0 =A0ktime_get_ts+0x66/0xa8
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 [<ffffffff810bfb18>] ?
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0poll_se= lect_copy_remaining+0xe0/0xf5
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 [<ffffffff8100a48d>] ?
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0do_notify_resume+0x3b/0= x74
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 [<ffffffff81411a70>] ?
> =A0 =A0 =A0> =A0 =A0 =A0 =A0int_signal+0x12/0x17
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0Code: 00 00 00 40 74 02 0f 0b
> =A0 =A0 =A048 8d
> =A0 =A0 =A0> =A0 =A0 =A0 =A077 70 48
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A08d bf 08
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A001 00 > =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A000 e8
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A08b 71 10
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A000 85 c0 0f 84 5d 01 00 00 48
> =A0 =A0 =A08b 6b
> =A0 =A0 =A0> =A0 =A0 =A0 =A018 f6 83
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A080 00 00
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A000 08 > =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0<4c> 8b
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A065 30
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A074 11 be 68 05 00 00 48 c7 c7
> =A0 =A0 =A08e df
> =A0 =A0 =A0> =A0 =A0 =A0 =A04f 81 e8
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0bb d0
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0RIP =A0[<ffffffff810c50c4>] > =A0 =A0 =A0> =A0 =A0 =A0 =A0iput+0x3e/0x195
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 RSP <ffff8800389ffbf8>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0CR2: 0000000000000030
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0---[ end trace
> =A0 =A0 =A067cc1654658fedcc ]---
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0Fixing recursive fault but
> =A0 =A0 =A0reboot is
> =A0 =A0 =A0> =A0 =A0 =A0 =A0needed!
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0I also tested Xen 4.2.0 and
> =A0 =A0 =A0problem
> =A0 =A0 =A0> =A0 =A0 =A0 =A0is the
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0same. So
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0is this=
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0a Xen
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0bug or a
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0kernel bug? I am running
> =A0 =A0 =A0vanilla
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0 =A0[1][2][3][4][5][11][17]kernel.org kernel
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A03.5.0 and
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0my
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0hardware is Intel Core i7-3770
> =A0 =A0 =A0CPU
> =A0 =A0 =A0> =A0 =A0 =A0 =A0and Intel
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0DQ77MK
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0motherboard
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0with
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0latest bios.
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0Best regards,
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0Valtteri Kiviniemi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> References
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0Visible links
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A01.
> =A0 =A0 =A0[3][4][5][6][12][18]http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0_______________________________________= ________
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> Xen-devel mailing list
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0[4][5][6][7][13][19]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0[5][6][7][8][14][20]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> References
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0Visible links
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A01.
> =A0 =A0 =A0mailto:[7][8][9][15][21]pas= ik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A02.
> =A0 =A0 =A0[8][9][10][16][22]http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A03.
> =A0 =A0 =A0[9][10][11][17][23]http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A04.
> =A0 =A0 =A0> =A0 =A0 =A0 =A0mailto:[10][11][12][18][24]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A05.
> =A0 =A0 =A0> =A0 =A0 =A0 =A0[11][12][13][19][25]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> > =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> Re= ferences
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> > =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0Visible links
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A01. mailto:[13][14][20][26]pasik@iki.= fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A02. mailto:[14][15][21][27]pasik@iki.= fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A03. [15][16][22][28]= http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A04. [16][17][23][29]= http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A05.
> =A0 =A0 =A0mailto:[17][18][24][30]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A06.
> =A0 =A0 =A0[18][19][25][31]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A07. mailto:[19][20][26][32]pasik@iki.= fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A08. [20][21][27][33]= http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A09. [21][22][28][34]= http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 10.
> =A0 =A0 =A0mailto:[22][23][29][35]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 11.
> =A0 =A0 =A0[23][24][30][36]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> References
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0Visible lin= ks
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A01. mailto:[= 25][31][37]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A02. mailto:[= 26][32][38]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A03. mailto:[= 27][33][39]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A04. [28][34]= [40]http://kernel.org/=
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A05. [29][35]= [41]http://kernel.org/=
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A06. mailto:[= 30][36][42]Xen-devel@lists.xen.o= rg
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A07. [31][37]= [43]http://lis= ts.xen.org/xen-devel
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A08. mailto:[= 32][38][44]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A09. [33][39]= [45]http://kernel.org/=
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 10. [34][40][4= 6]http://kernel.org/ > =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 11. mailto:[35= ][41][47]Xen-devel@lists.xen.org=
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 12. [36][42][4= 8]http://lists= .xen.org/xen-devel
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 13. mailto:[37= ][43][49]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 14. mailto:[38= ][44][50]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 15. [39][45][5= 1]http://kernel.org/ > =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 16. [40][46][5= 2]http://kernel.org/ > =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 17. mailto:[41= ][47][53]Xen-devel@lists.xen.org=
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 18. [42][48][5= 4]http://lists= .xen.org/xen-devel
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 19. mailto:[43= ][49][55]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 20. [44][50][5= 6]http://kernel.org/ > =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 21. [45][51][5= 7]http://kernel.org/ > =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 22. mailto:[46= ][52][58]Xen-devel@lists.xen.org=
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 23. [47][53][5= 9]http://lists= .xen.org/xen-devel
> =A0 =A0 =A0> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> References
> =A0 =A0 =A0> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0Visible links
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A01. mailto:[54][60]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A02. mailto:[55][61]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A03. mailto:[56][62]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A04. mailto:[57][63]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A05. [58][64]http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A06. [59][65]http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A07. mailto:[60][66]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A08. [61][67]http://lists.xen.org/xen-devel=
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A09. mailto:[62][68]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 10. [63][69]http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 11. [64][70]http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 12. mailto:[65][71]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 13. [66][72]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 14. mailto:[67][73]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 15. mailto:[68][74]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 16. [69][75]http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 17. [70][76]http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 18. mailto:[71][77]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 19. [72][78]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 20. mailto:[73][79]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 21. [74][80]http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 22. [75][81]http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 23. mailto:[76][82]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 24. [77][83]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 25. mailto:[78][84]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 26. mailto:[79][85]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 27. mailto:[80][86]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 28. [81][87]http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 29. [82][88]http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 30. mailto:[83][89]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 31. [84][90]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 32. mailto:[85][91]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 33. [86][92]http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 34. [87][93]http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 35. mailto:[88][94]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 36. [89][95]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 37. mailto:[90][96]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 38. mailto:[91][97]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 39. [92][98]http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 40. [93][99]http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 41. mailto:[94][100]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 42. [95][101]http://lists.xen.org/xen-devel<= /a>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 43. mailto:[96][102]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 44. [97][103]http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 45. [98][104]http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 46. mailto:[99][105]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 47. [100][106]http://lists.xen.org/xen-devel=
> =A0 =A0 =A0>
> =A0 =A0 =A0> References
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0Visible links
> =A0 =A0 =A0> =A0 =A01. mailto:[107]kiviniemi.valtteri@gmail.com
> =A0 =A0 =A0> =A0 =A02. [108]http://ark.intel.com/products/65719/
> =A0 =A0 =A0> =A0 =A03.
> =A0 =A0 =A0[109]= http://www.intel.com/content/www/us/en/motherboards/desktop-motherboards/de= sktop-board-dq77mk.html
> =A0 =A0 =A0> =A0 =A04. mailto:[110]root@dataproof.fi
> =A0 =A0 =A0> =A0 =A05. mailto:[111]= pasik@iki.fi
> =A0 =A0 =A0> =A0 =A06. [112]http://xen.org/
> =A0 =A0 =A0> =A0 =A07. mailto:[113]= pasik@iki.fi
> =A0 =A0 =A0> =A0 =A08. mailto:[114]= pasik@iki.fi
> =A0 =A0 =A0> =A0 =A09. mailto:[115]= pasik@iki.fi
> =A0 =A0 =A0> =A0 10. mailto:[116]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 11. [117]http://kernel.org/
> =A0 =A0 =A0> =A0 12. [118]http://kernel.org/
> =A0 =A0 =A0> =A0 13. mailto:[119]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 14. [120]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 15. mailto:[121]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 16. [122]http://kernel.org/
> =A0 =A0 =A0> =A0 17. [123]http://kernel.org/
> =A0 =A0 =A0> =A0 18. mailto:[124]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 19. [125]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 20. mailto:[126]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 21. mailto:[127]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 22. [128]http://kernel.org/
> =A0 =A0 =A0> =A0 23. [129]http://kernel.org/
> =A0 =A0 =A0> =A0 24. mailto:[130]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 25. [131]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 26. mailto:[132]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 27. [133]http://kernel.org/
> =A0 =A0 =A0> =A0 28. [134]http://kernel.org/
> =A0 =A0 =A0> =A0 29. mailto:[135]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 30. [136]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 31. mailto:[137]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 32. mailto:[138]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 33. mailto:[139]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 34. [140]http://kernel.org/
> =A0 =A0 =A0> =A0 35. [141]http://kernel.org/
> =A0 =A0 =A0> =A0 36. mailto:[142]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 37. [143]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 38. mailto:[144]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 39. [145]http://kernel.org/
> =A0 =A0 =A0> =A0 40. [146]http://kernel.org/
> =A0 =A0 =A0> =A0 41. mailto:[147]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 42. [148]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 43. mailto:[149]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 44. mailto:[150]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 45. [151]http://kernel.org/
> =A0 =A0 =A0> =A0 46. [152]http://kernel.org/
> =A0 =A0 =A0> =A0 47. mailto:[153]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 48. [154]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 49. mailto:[155]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 50. [156]http://kernel.org/
> =A0 =A0 =A0> =A0 51. [157]http://kernel.org/
> =A0 =A0 =A0> =A0 52. mailto:[158]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 53. [159]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 54. mailto:[160]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 55. mailto:[161]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 56. mailto:[162]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 57. mailto:[163]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 58. [164]http://kernel.org/
> =A0 =A0 =A0> =A0 59. [165]http://kernel.org/
> =A0 =A0 =A0> =A0 60. mailto:[166]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 61. [167]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 62. mailto:[168]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 63. [169]http://kernel.org/
> =A0 =A0 =A0> =A0 64. [170]http://kernel.org/
> =A0 =A0 =A0> =A0 65. mailto:[171]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 66. [172]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 67. mailto:[173]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 68. mailto:[174]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 69. [175]http://kernel.org/
> =A0 =A0 =A0> =A0 70. [176]http://kernel.org/
> =A0 =A0 =A0> =A0 71. mailto:[177]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 72. [178]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 73. mailto:[179]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 74. [180]http://kernel.org/
> =A0 =A0 =A0> =A0 75. [181]http://kernel.org/
> =A0 =A0 =A0> =A0 76. mailto:[182]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 77. [183]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 78. mailto:[184]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 79. mailto:[185]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 80. mailto:[186]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 81. [187]http://kernel.org/
> =A0 =A0 =A0> =A0 82. [188]http://kernel.org/
> =A0 =A0 =A0> =A0 83. mailto:[189]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 84. [190]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 85. mailto:[191]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 86. [192]http://kernel.org/
> =A0 =A0 =A0> =A0 87. [193]http://kernel.org/
> =A0 =A0 =A0> =A0 88. mailto:[194]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 89. [195]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 90. mailto:[196]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 91. mailto:[197]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 92. [198]http://kernel.org/
> =A0 =A0 =A0> =A0 93. [199]http://kernel.org/
> =A0 =A0 =A0> =A0 94. mailto:[200]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 95. [201]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 96. mailto:[202]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 97. [203]http://kernel.org/
> =A0 =A0 =A0> =A0 98. [204]http://kernel.org/
> =A0 =A0 =A0> =A0 99. mailto:[205]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0100. [206]http://lists.xen.org/xen-devel
>
> References
>
> =A0 =A0Visible links
> =A0 =A01. http:= //nago.fi/dmesg.txt
> =A0 =A02. htt= p://nago.fi/qemu-dm.txt
> =A0 =A03. ht= tp://nago.fi/xm-dmesg.txt
> =A0 =A04. http://nago.fi/domu-config.txt
> =A0 =A05. http://nago.fi/dom0-config.txt
> =A0 =A06. mailto:pasik@iki.fi
> =A0 =A07. mailto:kivin= iemi.valtteri@gmail.com
> =A0 =A08. http://ark.intel.com/products/65719/
> =A0 =A09. http:/= /www.intel.com/content/www/us/en/motherboards/desktop-motherboards/desktop-= board-dq77mk.html
> =A0 10. mailto:root@dataproof.fi<= /a>
> =A0 11. mailto:pasik@iki.fi
> =A0 12. http://xen.org/<= /a>
> =A0 13. mailto:pasik@iki.fi
> =A0 14. mailto:pasik= @iki.fi
> =A0 15. mailto:pasik@iki.fi
> =A0 16. mailto:pasik@iki.fi<= br> > =A0 17. http://kernel= .org/
> =A0 18. http://kernel= .org/
> =A0 19. mailto:Xen-devel@li= sts.xen.org
> =A0 20. h= ttp://lists.xen.org/xen-devel
> =A0 21. mailto:pasik= @iki.fi
> =A0 22. http://kernel= .org/
> =A0 23. http://kernel= .org/
> =A0 24. mailto:Xen-devel@li= sts.xen.org
> =A0 25. h= ttp://lists.xen.org/xen-devel
> =A0 26. mailto:pasik@iki.fi
> =A0 27. mailto:pasik@iki.fi
> =A0 28. http://kernel= .org/
> =A0 29. http://kernel= .org/
> =A0 30. mailto:Xen-devel@li= sts.xen.org
> =A0 31. h= ttp://lists.xen.org/xen-devel
> =A0 32. mailto:pasik@iki.fi
> =A0 33. http://kernel= .org/
> =A0 34. http://kernel= .org/
> =A0 35. mailto:Xen-devel@li= sts.xen.org
> =A0 36. h= ttp://lists.xen.org/xen-devel
> =A0 37. mailto:pasik@iki.fi
> =A0 38. mailto:pasik@iki.fi
> =A0 39. mailto:pasik@iki.fi<= br> > =A0 40. http://kernel= .org/
> =A0 41. http://kernel= .org/
> =A0 42. mailto:Xen-devel@li= sts.xen.org
> =A0 43. h= ttp://lists.xen.org/xen-devel
> =A0 44. mailto:pasik= @iki.fi
> =A0 45. http://kernel= .org/
> =A0 46. http://kernel= .org/
> =A0 47. mailto:Xen-devel@li= sts.xen.org
> =A0 48. h= ttp://lists.xen.org/xen-devel
> =A0 49. mailto:pasik@iki.fi
> =A0 50. mailto:pasik@iki.fi<= br> > =A0 51. http://kernel= .org/
> =A0 52. http://kernel= .org/
> =A0 53. mailto:Xen-devel@li= sts.xen.org
> =A0 54. h= ttp://lists.xen.org/xen-devel
> =A0 55. mailto:pasik@iki.fi
> =A0 56. http://kernel= .org/
> =A0 57. http://kernel= .org/
> =A0 58. mailto:Xen-devel@li= sts.xen.org
> =A0 59. h= ttp://lists.xen.org/xen-devel
> =A0 60. mailto:pasik@iki.fi
> =A0 61. mailto:pasik@iki.fi
> =A0 62. mailto:pasik@iki.fi
> =A0 63. mailto:pasik@iki.fi
> =A0 64. http://kernel= .org/
> =A0 65. http://kernel= .org/
> =A0 66. mailto:Xen-devel@li= sts.xen.org
> =A0 67. h= ttp://lists.xen.org/xen-devel
> =A0 68. mailto:pasik= @iki.fi
> =A0 69. http://kernel= .org/
> =A0 70. http://kernel= .org/
> =A0 71. mailto:Xen-devel@li= sts.xen.org
> =A0 72. h= ttp://lists.xen.org/xen-devel
> =A0 73. mailto:pasik@iki.fi
> =A0 74. mailto:pasik@iki.fi<= br> > =A0 75. http://kernel= .org/
> =A0 76. http://kernel= .org/
> =A0 77. mailto:Xen-devel@li= sts.xen.org
> =A0 78. h= ttp://lists.xen.org/xen-devel
> =A0 79. mailto:pasik@iki.fi
> =A0 80. http://kernel= .org/
> =A0 81. http://kernel= .org/
> =A0 82. mailto:Xen-devel@li= sts.xen.org
> =A0 83. h= ttp://lists.xen.org/xen-devel
> =A0 84. mailto:pasik@iki.fi
> =A0 85. mailto:pasik@iki.fi
> =A0 86. mailto:pasik@iki.fi
> =A0 87. http://kernel= .org/
> =A0 88. http://kernel= .org/
> =A0 89. mailto:Xen-devel@li= sts.xen.org
> =A0 90. h= ttp://lists.xen.org/xen-devel
> =A0 91. mailto:pasik= @iki.fi
> =A0 92. http://kernel= .org/
> =A0 93. http://kernel= .org/
> =A0 94. mailto:Xen-devel@li= sts.xen.org
> =A0 95. h= ttp://lists.xen.org/xen-devel
> =A0 96. mailto:pasik@iki.fi
> =A0 97. mailto:pasik@iki.fi<= br> > =A0 98. http://kernel= .org/
> =A0 99. http://kernel= .org/
> =A0100. mailto:Xen-devel@li= sts.xen.org
> =A0101. h= ttp://lists.xen.org/xen-devel
> =A0102. mailto:pasik@iki.fi
> =A0103. http://kernel= .org/
> =A0104. http://kernel= .org/
> =A0105. mailto:Xen-devel@li= sts.xen.org
> =A0106. h= ttp://lists.xen.org/xen-devel
> =A0107. mailto:kivinie= mi.valtteri@gmail.com
> =A0108. http://ark.intel.com/products/65719/
> =A0109. http://w= ww.intel.com/content/www/us/en/motherboards/desktop-motherboards/desktop-bo= ard-dq77mk.html
> =A0110. mailto:root@dataproof.fi<= /a>
> =A0111. mailto:pasik@iki.fi
> =A0112. http://xen.org/<= /a>
> =A0113. mailto:pasik@iki.fi
> =A0114. mailto:pasik@iki.fi
> =A0115. mailto:pasik@iki.fi
> =A0116. mailto:pasik@iki.fi
> =A0117. http://kernel= .org/
> =A0118. http://kernel= .org/
> =A0119. mailto:Xen-devel@li= sts.xen.org
> =A0120. h= ttp://lists.xen.org/xen-devel
> =A0121. mailto:pasik@iki.fi
> =A0122. http://kernel= .org/
> =A0123. http://kernel= .org/
> =A0124. mailto:Xen-devel@li= sts.xen.org
> =A0125. h= ttp://lists.xen.org/xen-devel
> =A0126. mailto:pasik@iki.fi
> =A0127. mailto:pasik@iki.fi
> =A0128. http://kernel= .org/
> =A0129. http://kernel= .org/
> =A0130. mailto:Xen-devel@li= sts.xen.org
> =A0131. h= ttp://lists.xen.org/xen-devel
> =A0132. mailto:pasik@iki.fi
> =A0133. http://kernel= .org/
> =A0134. http://kernel= .org/
> =A0135. mailto:Xen-devel@li= sts.xen.org
> =A0136. h= ttp://lists.xen.org/xen-devel
> =A0137. mailto:pasik@iki.fi
> =A0138. mailto:pasik@iki.fi
> =A0139. mailto:pasik@iki.fi
> =A0140. http://kernel= .org/
> =A0141. http://kernel= .org/
> =A0142. mailto:Xen-devel@li= sts.xen.org
> =A0143. h= ttp://lists.xen.org/xen-devel
> =A0144. mailto:pasik@iki.fi
> =A0145. http://kernel= .org/
> =A0146. http://kernel= .org/
> =A0147. mailto:Xen-devel@li= sts.xen.org
> =A0148. h= ttp://lists.xen.org/xen-devel
> =A0149. mailto:pasik@iki.fi
> =A0150. mailto:pasik@iki.fi
> =A0151. http://kernel= .org/
> =A0152. http://kernel= .org/
> =A0153. mailto:Xen-devel@li= sts.xen.org
> =A0154. h= ttp://lists.xen.org/xen-devel
> =A0155. mailto:pasik@iki.fi
> =A0156. http://kernel= .org/
> =A0157. http://kernel= .org/
> =A0158. mailto:Xen-devel@li= sts.xen.org
> =A0159. h= ttp://lists.xen.org/xen-devel
> =A0160. mailto:pasik@iki.fi
> =A0161. mailto:pasik@iki.fi
> =A0162. mailto:pasik@iki.fi
> =A0163. mailto:pasik@iki.fi
> =A0164. http://kernel= .org/
> =A0165. http://kernel= .org/
> =A0166. mailto:Xen-devel@li= sts.xen.org
> =A0167. h= ttp://lists.xen.org/xen-devel
> =A0168. mailto:pasik@iki.fi
> =A0169. http://kernel= .org/
> =A0170. http://kernel= .org/
> =A0171. mailto:Xen-devel@li= sts.xen.org
> =A0172. h= ttp://lists.xen.org/xen-devel
> =A0173. mailto:pasik@iki.fi
> =A0174. mailto:pasik@iki.fi
> =A0175. http://kernel= .org/
> =A0176. http://kernel= .org/
> =A0177. mailto:Xen-devel@li= sts.xen.org
> =A0178. h= ttp://lists.xen.org/xen-devel
> =A0179. mailto:pasik@iki.fi
> =A0180. http://kernel= .org/
> =A0181. http://kernel= .org/
> =A0182. mailto:Xen-devel@li= sts.xen.org
> =A0183. h= ttp://lists.xen.org/xen-devel
> =A0184. mailto:pasik@iki.fi
> =A0185. mailto:pasik@iki.fi
> =A0186. mailto:pasik@iki.fi
> =A0187. http://kernel= .org/
> =A0188. http://kernel= .org/
> =A0189. mailto:Xen-devel@li= sts.xen.org
> =A0190. h= ttp://lists.xen.org/xen-devel
> =A0191. mailto:pasik@iki.fi
> =A0192. http://kernel= .org/
> =A0193. http://kernel= .org/
> =A0194. mailto:Xen-devel@li= sts.xen.org
> =A0195. h= ttp://lists.xen.org/xen-devel
> =A0196. mailto:pasik@iki.fi
> =A0197. mailto:pasik@iki.fi
> =A0198. http://kernel= .org/
> =A0199. http://kernel= .org/
> =A0200. mailto:Xen-devel@li= sts.xen.org
> =A0201. h= ttp://lists.xen.org/xen-devel
> =A0202. mailto:pasik@iki.fi
> =A0203. http://kernel= .org/
> =A0204. http://kernel= .org/
> =A0205. mailto:Xen-devel@li= sts.xen.org
> =A0206. h= ttp://lists.xen.org/xen-devel

--20cf30563c0d436e7b04cb13c0b5-- --===============5962986339054632322== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============5962986339054632322==-- From xen-devel-bounces@lists.xen.org Tue Oct 02 13:47:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 13:47:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ2oA-0003HH-F2; Tue, 02 Oct 2012 13:46:46 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ2o8-0003H5-0N for Xen-devel@lists.xen.org; Tue, 02 Oct 2012 13:46:44 +0000 Received: from [85.158.143.99:50042] by server-1.bemta-4.messagelabs.com id 52/DD-05684-340FA605; Tue, 02 Oct 2012 13:46:43 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1349185597!26447331!1 X-Originating-IP: [209.85.213.45] X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG, HTML_50_60, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, ML_RADAR_SPEW_LINKS_23, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5168 invoked from network); 2 Oct 2012 13:46:38 -0000 Received: from mail-yh0-f45.google.com (HELO mail-yh0-f45.google.com) (209.85.213.45) by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 13:46:38 -0000 Received: by yhpp34 with SMTP id p34so545820yhp.32 for ; Tue, 02 Oct 2012 06:46:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=12xj8OTRd1T2y4ocYFttuY6YY4iM8g/28fWIyrB70Uc=; b=ItTR/TYCXuX97wdGSrmTnBLRJsczw0US45a94kuryPdUx9czFitroSuSxusVoKhBPQ DuhLr9pA9E1gkotMyBtjo0C6PXJEAxqOw4kgfY2574zzI5Nw8Pzb3tC/7EJDWYls8gtX +lv4Mp/KBQkx9whrpMxTa48RWCG7BV51xoKxxRZPj0XUoH3KihuSGAw1K9ID+rRl/tZz HNUDiq0JK/YvyCrDPU7PkLov+RSFYhqaev1hOiBpZCdisogCDAy5MQZmQZtDp4wQFSAc PXvmE357yn4eCtxzErrC3uRlnr4WxAMMvB6eQoPMxDz11RBoxXn8EjoqleMm7xQIhCYL p9Cw== MIME-Version: 1.0 Received: by 10.236.193.105 with SMTP id j69mr15921725yhn.21.1349185597304; Tue, 02 Oct 2012 06:46:37 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Tue, 2 Oct 2012 06:46:37 -0700 (PDT) In-Reply-To: <20121002131407.GM8912@reaktio.net> References: <20121001160117.GD8912@reaktio.net> <20121001164757.GF8912@reaktio.net> <20121001182437.GG8912@reaktio.net> <20121002121932.GL8912@reaktio.net> <20121002131407.GM8912@reaktio.net> Date: Tue, 2 Oct 2012 16:46:37 +0300 Message-ID: From: Valtteri Kiviniemi To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= Cc: Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.0.4, kernel 3.5.0 HVM crash and kernel BUG X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5962986339054632322==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============5962986339054632322== Content-Type: multipart/alternative; boundary=20cf30563c0d436e7b04cb13c0b5 --20cf30563c0d436e7b04cb13c0b5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, I have not enabled debug on Xen or dom0 kernel. Could you tell me the parameters for Xen coompilation needed to enable debugging? And If you would also happen to know what are the options needed to enable kernel debugging in menuconfig? Well I can probably manage to get the kernel debugging enabled myself, but if you happen to know them please share so maybe I can get everything enabled at the first try :) Thanks! - Valtteri 2012/10/2 Pasi K=E4rkk=E4inen > On Tue, Oct 02, 2012 at 04:01:04PM +0300, Valtteri Kiviniemi wrote: > > Hi, > > > > I already tried 3.2, 3.5, 3.5.0, 3.6.0-rc7 and 3.6.0, same problem > all of > > those. My dom0 config is the same config that I'am using on other > server > > where HVM is working, so I dont think that it is a config problem. I > have > > triple checked everything and all should be ok. dom0 dmesg shows the > same > > crash that I have previously posted here. /var/log/xen/ does not > contain > > any specific errors. > > > > Could this be some kind of broblem with my motherboard bios being > buggy or > > CPU not supported? I'm using the new intel Ivy Bridge processor whic= h > has > > integrated GPU, but that should not probably cause these kind of > problems. > > Or maybe some ACPI problem? xm dmesg is showing some notices about > ACPI. > > Is there any ACPI kernel parameters that I should try booting? This > has to > > be somekind of problem with my hardware, or then maybe it could be a > > kernel problem too. I just really cant figure this out myself, I hav= e > > tried everything. > > > > Hmm.. I have some distant memories of seeing a patch that fixes a bug > on recent Ivy Bridge systems, but I can't find a link right now. > Maybe you're affected by that.. > > Also: Did you already post the crash log, with all the debug/verbose > options enabled for both Xen and dom0 kernel? > > -- Pasi > > > Lets take a quick summary of what has been tested, what hardware I'm > using > > etc. > > > > Xen-versions tested: 4.2.0, 4.0.4 > > Kernel-versions tested: 3.2.0, 3.5.0, 3.5.4, 3.6.0-rc7, 3.6.0 > > > > Host OS: Debian testing/wheezy, udev version 175-7, 2.13-35, python > > version 2.7.3~rc2-2.1 > > > > Hardware: > > > > CPU: Intel Core i7-3770 3.4GHz > > MB: Intel DQ77MK (latest bios updated) > > Memory: 32GB (4 x 8GB DDR3-1600MHz) > > > > All relevant log files and configs: > > > > dom0 dmesg: [1]http://nago.fi/dmesg.txt > > qemu-dm log: [2]http://nago.fi/qemu-dm.txt > > xm dmesg log: [3]http://nago.fi/xm-dmesg.txt > > domU config: [4]http://nago.fi/domu-config.txt > > dom0 kernel config: [5]http://nago.fi/dom0-config.txt > > > > I have also tried playing with every setting on that domU that I can > think > > of and tried different configs etc. > > > > - Valtteri > > > > 2012/10/2 Pasi K=E4rkk=E4inen <[6]pasik@iki.fi> > > > > On Tue, Oct 02, 2012 at 03:11:07PM +0300, Valtteri Kiviniemi wrote= : > > > Hi, > > > > > > Another update: > > > > > > I wanted to check that if a Linux HVM would boot with working > VNC > > console, > > > so I tried to launch a Debian Squeeze installer on HVM. It > refused > > to > > > start ant told me that vbd hotplug scripts were not working. > After > > that > > > failure even the Windows domU would not anymore start which w= as > > previously > > > starting ok. > > > > > > The hotplug scripts also starts hanging on the processes. > > > > > > root 9401 0.1 0.1 17700 1640 ? S 15:05 > 0:00 > > /bin/bash > > > /etc/xen/scripts/xen-hotplug-cleanup > > > root 9441 0.1 0.1 17700 1644 ? S 15:05 > 0:00 > > /bin/bash > > > /etc/xen/scripts/xen-hotplug-cleanup > > > root 9481 0.1 0.1 17700 1640 ? S 15:05 > 0:00 > > /bin/bash > > > /etc/xen/scripts/xen-hotplug-cleanup > > > root 9560 0.1 0.1 17700 1640 ? S 15:05 > 0:00 > > /bin/bash > > > /etc/xen/scripts/xen-hotplug-cleanup > > > root 10738 0.1 0.1 17696 1636 ? S 15:05 > 0:00 > > /bin/bash > > > /etc/xen/scripts/xen-hotplug-cleanup > > > root 10747 0.1 0.1 17792 1736 ? S 15:05 > 0:00 > > /bin/bash > > > /etc/xen/scripts/block remove > > > root 11286 0.0 0.0 4080 324 ? S 15:06 > 0:00 > > sleep 1 > > > root 11290 0.0 0.0 4080 324 ? S 15:06 > 0:00 > > sleep 1 > > > root 11294 0.0 0.0 4080 324 ? S 15:06 > 0:00 > > sleep 1 > > > root 11298 0.0 0.0 4080 324 ? S 15:06 > 0:00 > > sleep 1 > > > root 11302 0.0 0.0 4080 320 ? S 15:06 > 0:00 > > sleep 1 > > > root 11306 0.0 0.0 4080 320 ? S 15:06 > 0:00 > > sleep 1 > > > > > > Then I did a xm destroy and I had again the kernel BUG on > dmesg. So > > it > > > seems that the problem is not fixed by using 3.6.0. Udev > version is > > 175-7. > > > > > > > So you have definitely something broken in your system, > > probably in your dom0 kernel. Try with Linux 3.5.4 or 3.4.x, > > and see how that goes. > > > > Any errors in dom0 dmesg? How about in /var/log/xen/* ? > > > > -- Pasi > > > > > > > > > > > 2012/10/1 Valtteri Kiviniemi <[1][7] > kiviniemi.valtteri@gmail.com> > > > > > > Hi, > > > > > > CPU: Intel Core i7-3770 3.4GHz > > > [2][8]http://ark.intel.com/products/65719/ > > > > > > MB: Intel DQ77MK (latest bios updated) > > > > > [3][9] > http://www.intel.com/content/www/us/en/motherboards/desktop-motherboards/= desktop-board-dq77mk.html > > > > > > Memory: 32GB (4 x 8GB DDR3-1600MHz) > > > > > > Host is Debian wheezy/testing, Xen 4.0.4 and latest 3.6.0 > kernel. > > > > > > Noticed also some errors in xm dmesg: > > > > > > root@xen-2:~# xm dmesg > > > > > > (XEN) Xen version 4.0.4 ([4][10]root@dataproof.fi) (gcc > version > > 4.7.1 > > > (Debian 4.7.1-7) ) Sun Sep 30 20:28:26 EEST 2012 > > > (XEN) Latest ChangeSet: unavailable > > > (XEN) Bootloader: GNU GRUB 0.97 > > > (XEN) Command line: dom0_mem=3D1280M cpufreq=3Dxen > clocksource=3Dhpet > > > (XEN) Video information: > > > (XEN) VGA is text mode 80x25, font 8x16 > > > (XEN) VBE/DDC methods: none; EDID transfer time: 0 seconds > > > (XEN) EDID info not retrieved because no DDC retrieval > method > > detected > > > (XEN) Disc information: > > > (XEN) Found 4 MBR signatures > > > (XEN) Found 4 EDD information structures > > > (XEN) Xen-e820 RAM map: > > > (XEN) 0000000000000000 - 000000000009d800 (usable) > > > (XEN) 000000000009d800 - 00000000000a0000 (reserved) > > > (XEN) 00000000000e0000 - 0000000000100000 (reserved) > > > (XEN) 0000000000100000 - 0000000020000000 (usable) > > > (XEN) 0000000020000000 - 0000000020200000 (reserved) > > > (XEN) 0000000020200000 - 0000000040004000 (usable) > > > (XEN) 0000000040004000 - 0000000040005000 (reserved) > > > (XEN) 0000000040005000 - 00000000dbe44000 (usable) > > > (XEN) 00000000dbe44000 - 00000000dc2d7000 (reserved) > > > (XEN) 00000000dc2d7000 - 00000000dc2e7000 (ACPI data) > > > (XEN) 00000000dc2e7000 - 00000000dc40c000 (ACPI NVS) > > > (XEN) 00000000dc40c000 - 00000000dc6af000 (reserved) > > > (XEN) 00000000dc6af000 - 00000000dc6b0000 (usable) > > > (XEN) 00000000dc6b0000 - 00000000dc6f3000 (ACPI NVS) > > > (XEN) 00000000dc6f3000 - 00000000dd000000 (usable) > > > (XEN) 00000000dd800000 - 00000000dfa00000 (reserved) > > > (XEN) 00000000f8000000 - 00000000fc000000 (reserved) > > > (XEN) 00000000fec00000 - 00000000fec01000 (reserved) > > > (XEN) 00000000fed00000 - 00000000fed04000 (reserved) > > > (XEN) 00000000fed1c000 - 00000000fed20000 (reserved) > > > (XEN) 00000000fee00000 - 00000000fee01000 (reserved) > > > (XEN) 00000000ff000000 - 0000000100000000 (reserved) > > > (XEN) 0000000100000000 - 000000081e600000 (usable) > > > (XEN) ACPI: RSDP 000F0490, 0024 (r2 INTEL) > > > (XEN) ACPI: XSDT DC2DB080, 007C (r1 INTEL DQ77MK 3= 2 > AMI > > > 10013) > > > (XEN) ACPI: FACP DC2E51F0, 010C (r5 INTEL DQ77MK 3= 2 > AMI > > > 10013) > > > (XEN) ACPI Warning (tbfadt-0232): FADT (revision 5) is long= er > > than ACPI > > > 2.0 version, truncating length 0x10C to 0xF4 [20070126] > > > (XEN) ACPI: DSDT DC2DB188, A061 (r2 INTEL DQ77MK 3= 2 > INTL > > > 20051117) > > > (XEN) ACPI: FACS DC40A080, 0040 > > > (XEN) ACPI: APIC DC2E5300, 0092 (r3 INTEL DQ77MK 3= 2 > AMI > > > 10013) > > > (XEN) ACPI: FPDT DC2E5398, 0044 (r1 INTEL DQ77MK 3= 2 > AMI > > > 10013) > > > (XEN) ACPI: TCPA DC2E53E0, 0032 (r2 INTEL DQ77MK 3= 2 > MSFT > > > 1000013) > > > (XEN) ACPI: MCFG DC2E5418, 003C (r1 INTEL DQ77MK 3= 2 > MSFT > > > 97) > > > (XEN) ACPI: HPET DC2E5458, 0038 (r1 INTEL DQ77MK 3= 2 > AMI. > > > 5) > > > (XEN) ACPI: SSDT DC2E5490, 036D (r1 INTEL DQ77MK 3= 2 > INTL > > > 20091112) > > > (XEN) ACPI: SSDT DC2E5800, 09AA (r1 INTEL DQ77MK 3= 2 > INTL > > > 20051117) > > > (XEN) ACPI: SSDT DC2E61B0, 0A92 (r1 INTEL DQ77MK 3= 2 > INTL > > > 20051117) > > > (XEN) ACPI: DMAR DC2E6C48, 00B8 (r1 INTEL DQ77MK 3= 2 > INTL > > > 1) > > > (XEN) ACPI: ASF! DC2E6D00, 00A5 (r32 INTEL DQ77MK = 32 > > TFSM > > > F4240) > > > (XEN) System RAM: 32682MB (33467320kB) > > > (XEN) Domain heap initialised > > > (XEN) ACPI: 32/64X FACS address mismatch in FADT - > > > dc40a080/0000000000000000, using 32 > > > (XEN) Processor #0 7:10 APIC version 21 > > > (XEN) Processor #2 7:10 APIC version 21 > > > (XEN) Processor #4 7:10 APIC version 21 > > > (XEN) Processor #6 7:10 APIC version 21 > > > (XEN) Processor #1 7:10 APIC version 21 > > > (XEN) Processor #3 7:10 APIC version 21 > > > (XEN) Processor #5 7:10 APIC version 21 > > > (XEN) Processor #7 7:10 APIC version 21 > > > (XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, > GSI > > 0-23 > > > (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs > > > (XEN) Switched to APIC driver x2apic_cluster. > > > (XEN) x2APIC mode enabled. > > > (XEN) Using scheduler: SMP Credit Scheduler (credit) > > > (XEN) Detected 3392.369 MHz processor. > > > (XEN) Initing memory sharing. > > > (XEN) VMX: Supported advanced features: > > > (XEN) - APIC MMIO access virtualisation > > > (XEN) - APIC TPR shadow > > > (XEN) - Extended Page Tables (EPT) > > > (XEN) - Virtual-Processor Identifiers (VPID) > > > (XEN) - Virtual NMI > > > (XEN) - MSR direct-access bitmap > > > (XEN) - Unrestricted Guest > > > (XEN) EPT supports 2MB super page. > > > (XEN) HVM: ASIDs enabled. > > > (XEN) HVM: VMX enabled > > > (XEN) HVM: Hardware Assisted Paging detected. > > > (XEN) Intel VT-d Snoop Control not enabled. > > > (XEN) Intel VT-d Dom0 DMA Passthrough not enabled. > > > (XEN) Intel VT-d Queued Invalidation enabled. > > > (XEN) Intel VT-d Interrupt Remapping enabled. > > > (XEN) I/O virtualisation enabled > > > (XEN) - Dom0 mode: Relaxed > > > (XEN) Enabled directed EOI with ioapic_ack_old on! > > > (XEN) Total of 8 processors activated. > > > (XEN) ENABLING IO-APIC IRQs > > > (XEN) -> Using old ACK method > > > (XEN) TSC is reliable, synchronization unnecessary > > > (XEN) Platform timer appears to have unexpectedly wrapped 1 > > times. > > > (XEN) Platform timer is 14.318MHz HPET > > > (XEN) Allocated console ring of 16 KiB. > > > (XEN) Brought up 8 CPUs > > > (XEN) *** LOADING DOMAIN 0 *** > > > (XEN) Xen kernel: 64-bit, lsb, compat32 > > > (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> > > 0x1ae7000 > > > (XEN) PHYSICAL MEMORY ARRANGEMENT: > > > (XEN) Dom0 alloc.: 0000000804000000->0000000806000000 > (319488 > > pages > > > to be allocated) > > > (XEN) VIRTUAL MEMORY ARRANGEMENT: > > > (XEN) Loaded kernel: ffffffff81000000->ffffffff81ae7000 > > > (XEN) Init. ramdisk: ffffffff81ae7000->ffffffff81ae7000 > > > (XEN) Phys-Mach map: ffffffff81ae7000->ffffffff81d67000 > > > (XEN) Start info: ffffffff81d67000->ffffffff81d674b4 > > > (XEN) Page tables: ffffffff81d68000->ffffffff81d7b000 > > > (XEN) Boot stack: ffffffff81d7b000->ffffffff81d7c000 > > > (XEN) TOTAL: ffffffff80000000->ffffffff82000000 > > > (XEN) ENTRY ADDRESS: ffffffff815e3210 > > > (XEN) Dom0 has maximum 8 VCPUs > > > (XEN) [VT-D]iommu.c:718: BIOS did not enable IGD for VT > properly. > > > Disabling IGD VT-d engine. > > > (XEN) Scrubbing Free RAM: done. > > > (XEN) Xen trace buffers: disabled > > > (XEN) Std. Loglevel: Errors and warnings > > > (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and > warnings) > > > (XEN) Xen is relinquishing VGA console. > > > (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times t= o > > switch > > > input to Xen) > > > (XEN) Freed 172kB init memory. > > > (XEN) traps.c:2333:d0 Domain attempted WRMSR 00000000000000= 8b > > from > > > 00000012:00000000 to 00000000:00000000. > > > > > > - Valtteri > > > > > > 2012/10/1 Pasi K=E4rkk=E4inen <[5][11]pasik@iki.fi> > > > > > > On Mon, Oct 01, 2012 at 09:12:50PM +0300, Valtteri > Kiviniemi > > wrote: > > > > Hi, > > > > > > > > Lowering memory or vcpu's does not help, problem is > the > > same. I > > > originally > > > > installed Xen 4.2.0 and the problem was same on that > too. > > Then I > > > > downgraded back to 4.0.4 since I thought that this > might > > be a bug > > > on > > > > 4.2.0. I have been previously running Windows Server > 2008 > > R2 > > > succesfully > > > > on Xen 4.0.x on different hardware with this same > config. > > > Hypervisor is > > > > 64bit and windows is 64bit. > > > > > > > > Any ideas what to try next? > > > > > > > > > > What kind of hardware is that? > > > > > > [6][12]xen.org automated testing regularly tests Windows > VMs, > > and it works > > > OK there. > > > > > > -- Pasi > > > > Ps. qemu-dm.log is the following: > > > > > > > > domid: 10 > > > > config qemu network with xen bridge for tap10.0 > xenbr0 > > > > Using file /dev/virtuals/ts in read-write mode > > > > Using file /media/iso/windows_server_2008_r2_sp1.iso > in > > read-only > > > mode > > > > Watching /local/domain/0/device-model/10/logdirty/cm= d > > > > Watching /local/domain/0/device-model/10/command > > > > qemu_map_cache_init nr_buckets =3D 10000 size 419430= 4 > > > > shared page at pfn feffd > > > > buffered io page at pfn feffb > > > > Guest uuid =3D 52f19e23-2955-c27d-a22c-60c5d8c60d5a > > > > Time offset set 0 > > > > populating video RAM at ff000000 > > > > mapping video RAM from ff000000 > > > > Register xen platform. > > > > Done register platform. > > > > platform_fixed_ioport: changed ro/rw state of ROM > memory > > area. > > > now is rw > > > > state. > > > > > > xs_read(/local/domain/0/device-model/10/xen_extended_power_mgmt): > > > read > > > > error > > > > medium change watch on `hdc' (index: 1): > > > > /media/iso/windows_server_2008_r2_sp1.iso > > > > I/O request not ready: 0, ptr: 0, port: 0, data: 0, > count: > > 0, > > > size: 0 > > > > Log-dirty: no command yet. > > > > xs_read(/local/domain/10/log-throttling): read error > > > > qemu: ignoring not-understood drive > > > `/local/domain/10/log-throttling' > > > > medium change watch on > `/local/domain/10/log-throttling' - > > > unknown device, > > > > ignored > > > > cirrus vga map change while on lfb mode > > > > mapping vram to f0000000 - f0400000 > > > > platform_fixed_ioport: changed ro/rw state of ROM > memory > > area. > > > now is rw > > > > state. > > > > platform_fixed_ioport: changed ro/rw state of ROM > memory > > area. > > > now is ro > > > > state. > > > > > > > > 2012/10/1 Pasi K=E4rkk=E4inen <[1][7][13]pasik@iki.f= i> > > > > > > > > On Mon, Oct 01, 2012 at 07:23:44PM +0300, Valtteri > > Kiviniemi > > > wrote: > > > > > Hi, > > > > > > > > > > I have tried other config files, but the > problem is > > the > > > same. At > > > > the > > > > > moment I'm using a config file from another > server > > where I > > > have a > > > > working > > > > > Windows Server 2008 R2 installation, so I don= t > > think that > > > there is > > > > > anything wrong with my config: > > > > > > > > > > > > > Did you try with less vcpus, for example 2 ? > > > > how about with less memory, say 2 GB ? > > > > > > > > Did you try with later Xen versions? Is that a 32b= it > > Xen, or > > > 64bit Xen > > > > hypervisor? > > > > > > > > -- Pasi > > > > > kernel =3D "/usr/lib/xen/boot/hvmloader" > > > > > builder =3D "hvm" > > > > > shadow_memory =3D "8" > > > > > memory =3D "4096" > > > > > name =3D "ts" > > > > > vcpus =3D "8" > > > > > cpus =3D ["0", "1", "2", "3", "4", "5", "6", = "7"] > > > > > pae =3D "1" > > > > > acpi =3D "1" > > > > > apic =3D "1" > > > > > vfb =3D [ 'type=3Dvnc, vnclisten=3D10.100.100= .50, > > vncpasswd=3Dxxx' > > > ] > > > > > xen_extended_power_mgmt =3D "0" > > > > > vif =3D [ "type=3Dioemu, mac=3D00:16:3e:d7:d7= :5d, > > bridge=3Dxenbr0" > > > ] > > > > > disk =3D [ "phy:/dev/virtuals/ts,hda,w", > > > > > > > > > "file:/media/iso/windows_server_2008_r2_sp1.iso,hdc:cdrom,r" ] > > > > > on_poweroff =3D "destroy" > > > > > on_reboot =3D "restart" > > > > > on_crash =3D "restart" > > > > > viridian =3D "1" > > > > > device_model =3D "/usr/lib/xen/bin/qemu-dm" > > > > > boot =3D "dc" > > > > > snapshot =3D "0" > > > > > vncconsole =3D "1" > > > > > sdl =3D "0" > > > > > opengl =3D "0" > > > > > vnc =3D "1" > > > > > nographic =3D "0" > > > > > stdvga =3D "0" > > > > > tsc_mode =3D "1" > > > > > monitor =3D "0" > > > > > localtime =3D "1" > > > > > usb =3D "0" > > > > > keymap =3D "fi" > > > > > xen_platform_pci =3D "1" > > > > > pci_msitranslate =3D "1" > > > > > pci_power_mgmt =3D "0" > > > > > > > > > > 2012/10/1 Pasi K=E4rkk=E4inen > > <[1][2][8][14]pasik@iki.fi> > > > > > > > > > > On Mon, Oct 01, 2012 at 06:46:08PM +0300, > > Valtteri > > > Kiviniemi > > > > wrote: > > > > > > Hi, > > > > > > > > > > > > Yes, I have viridian=3D1 on my domU > config. > > > > > > > > > > > > > > > > Try with some known good domU configfile. > > > > > > > > > > -- Pasi > > > > > > 2012/10/1 Pasi K=E4rkk=E4inen > > > <[1][2][3][9][15]pasik@iki.fi> > > > > > > > > > > > > On Mon, Oct 01, 2012 at 05:06:53PM > +0300, > > > Valtteri > > > > Kiviniemi > > > > > wrote: > > > > > > > Hi, > > > > > > > > > > > > > > I'm now using 3.6.0 and can't > > reproduce that > > > crash > > > > anymore, > > > > > so it > > > > > > seems > > > > > > > that it was a kernel bug. > > > > > > > > > > > > > > > > > > > OK. > > > > > > > However I'm still getting black > > screen on > > > VNC > > > > > > > when trying to install Windows > Server > > 2008 > > > R2. I can > > > > see the > > > > > > "windows is > > > > > > > loading files" screen but after > the > > > installer starts > > > > the VNC > > > > > > display goes > > > > > > > black. > > > > > > > > > > > > > > Any ideas? > > > > > > > > > > > > > > > > > > > Do you have viridian=3D1 specified f= or > the > > windows > > > vm? > > > > > > > > > > > > -- Pasi > > > > > > > > > > > > > - Valtteri > > > > > > > > > > > > > > 2012/10/1 Pasi K=E4rkk=E4inen > > > <[1][2][3][4][10][16]pasik@iki.fi> > > > > > > > > > > > > > > On Sun, Sep 30, 2012 at > 11:18:03PM > > +0300, > > > Valtteri > > > > > Kiviniemi > > > > > > wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > I'm trying to get Window= s > > Server 2008 > > > R2 > > > > installation > > > > > > booting on > > > > > > > Xen > > > > > > > > 4.0.4. Using the followi= ng > > config: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The domU will start > booting > > just > > > fine, but > > > > after a > > > > > few > > > > > > minutes the > > > > > > > VNC > > > > > > > > screen goes black. After > that > > when > > > typing "xm > > > > destroy > > > > > ts" it > > > > > > will > > > > > > > trigger > > > > > > > > a kernel BUG: > > > > > > > > > > > > > > > > BUG: unable to handle > kernel > > NULL > > > pointer > > > > dereference > > > > > at > > > > > > > 0000000000000030 > > > > > > > > IP: [] > > > iput+0x3e/0x195 > > > > > > > > PGD 0 > > > > > > > > Oops: 0000 [#1] SMP > > > > > > > > CPU 6 > > > > > > > > Pid: 3571, comm: qemu-dm > Not > > tainted > > > > 3.5.0-dom0 #1 > > > > > > > > > > > > > > First of all upgrade to lates= t > > 3.5.x Linux > > > kernel > > > > release > > > > > .. so > > > > > > at least > > > > > > > 3.5.4. > > > > > > > > > > > > > > -- Pasi > > > > > > > > > > > > > > > /DQ77MK > > > > > > > > RIP: > e030:[] > > > > [] > > > > > > > iput+0x3e/0x195 > > > > > > > > RSP: e02b:ffff8800389ffb= f8 > > EFLAGS: > > > 00010246 > > > > > > > > RAX: 0000000000000001 RB= X: > > > ffff8800377b0720 > > > > RCX: > > > > > > ffff8800501c0000 > > > > > > > > RDX: ffff8800501c0000 RS= I: > > > ffff8800377b0790 > > > > RDI: > > > > > > ffff8800377b0790 > > > > > > > > RBP: 0000000000000000 R0= 8: > > > ffffffff815cdd00 > > > > R09: > > > > > > 0000000000000016 > > > > > > > > R10: fefefefefefefeff R1= 1: > > > ffff8800377b0400 > > > > R12: > > > > > > 00000001000a3e0c > > > > > > > > R13: 0000000000000000 R1= 4: > > > 00000001000a3e0c > > > > R15: > > > > > > ffff8800389ffc28 > > > > > > > > FS: > 00007f1af70a8700(0000) > > > > GS:ffff880050180000(0000) > > > > > > > > knlGS:0000000000000000 > > > > > > > > CS: e033 DS: 0000 ES: > 0000 > > CR0: > > > > 000000008005003b > > > > > > > > CR2: 0000000000000030 CR= 3: > > > 000000000156d000 > > > > CR4: > > > > > > 0000000000002660 > > > > > > > > DR0: 0000000000000000 DR= 1: > > > 0000000000000000 > > > > DR2: > > > > > > 0000000000000000 > > > > > > > > DR3: 0000000000000000 DR= 6: > > > 00000000ffff0ff0 > > > > DR7: > > > > > > 0000000000000400 > > > > > > > > Process qemu-dm (pid: > 3571, > > > threadinfo > > > > > ffff8800389fe000, > > > > > > task > > > > > > > > ffff88003a721260) > > > > > > > > Stack: > > > > > > > > ffff88003a6d6400 > > ffff8800377b0000 > > > > 00000001000a3e0c > > > > > > > ffffffff8133ce8f > > > > > > > > ffff8800377b0400 > > ffffffff8134b6cd > > > > ffff8800389ffc28 > > > > > > > ffff8800389ffc28 > > > > > > > > ffff8800377b00f8 > > ffff8800377b0680 > > > > ffff880038cdcd60 > > > > > > > ffff8800377b0000 > > > > > > > > Call Trace: > > > > > > > > [] ? > > > > sk_release_kernel+0x23/0x39 > > > > > > > > [] ? > > > > netdev_run_todo+0x1e9/0x206 > > > > > > > > [] ? > > > > tun_chr_close+0x4c/0x7b > > > > > > > > [] ? > > > fput+0xe4/0x1c5 > > > > > > > > [] ? > > > filp_close+0x61/0x68 > > > > > > > > [] ? > > > > put_files_struct+0x62/0xb9 > > > > > > > > [] ? > > > do_exit+0x24a/0x74c > > > > > > > > [] ? > > > > do_group_exit+0x6b/0x9d > > > > > > > > [] ? > > > > > get_signal_to_deliver+0x449/0x46e > > > > > > > > [] ? > > > do_signal+0x28/0x4c4 > > > > > > > > [] ? > > > > > pvclock_clocksource_read+0x48/0xbf > > > > > > > > [] ? > > > ktime_get_ts+0x66/0xa8 > > > > > > > > [] ? > > > > > poll_select_copy_remaining+0xe0/0xf5 > > > > > > > > [] ? > > > > do_notify_resume+0x3b/0x74 > > > > > > > > [] ? > > > int_signal+0x12/0x17 > > > > > > > > Code: 00 00 00 40 74 02 > 0f 0b > > 48 8d > > > 77 70 48 > > > > 8d bf 08 > > > > > 01 00 > > > > > > 00 e8 > > > > > > > 8b 71 10 > > > > > > > > 00 85 c0 0f 84 5d 01 00 > 00 48 > > 8b 6b > > > 18 f6 83 > > > > 80 00 00 > > > > > 00 08 > > > > > > <4c> 8b > > > > > > > 65 30 > > > > > > > > 74 11 be 68 05 00 00 48 > c7 c7 > > 8e df > > > 4f 81 e8 > > > > bb d0 > > > > > > > > RIP [= ] > > > iput+0x3e/0x195 > > > > > > > > RSP > > > > > > > > CR2: 0000000000000030 > > > > > > > > ---[ end trace > > 67cc1654658fedcc ]--- > > > > > > > > Fixing recursive fault b= ut > > reboot is > > > needed! > > > > > > > > > > > > > > > > I also tested Xen 4.2.0 > and > > problem > > > is the > > > > same. So > > > > > is this > > > > > > a Xen > > > > > > > bug or a > > > > > > > > kernel bug? I am running > > vanilla > > > > > [1][2][3][4][5][11][17]kernel.org kernel > > > > > > 3.5.0 and > > > > > > > my > > > > > > > > hardware is Intel Core > i7-3770 > > CPU > > > and Intel > > > > DQ77MK > > > > > > motherboard > > > > > > > with > > > > > > > > latest bios. > > > > > > > > > > > > > > > > Best regards, > > > > > > > > Valtteri Kiviniemi > > > > > > > > > > > > > > > > References > > > > > > > > > > > > > > > > Visible links > > > > > > > > 1. > > [3][4][5][6][12][18]http://kernel.org/ > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Xen-devel mailing list > > > > > > > > > > [4][5][6][7][13][19]Xen-devel@lists.xen.org > > > > > > > > > > > [5][6][7][8][14][20]http://lists.xen.org/xen-devel > > > > > > > > > > > > > > References > > > > > > > > > > > > > > Visible links > > > > > > > 1. > > mailto:[7][8][9][15][21]pasik@iki.fi > > > > > > > 2. > > [8][9][10][16][22]http://kernel.org/ > > > > > > > 3. > > [9][10][11][17][23]http://kernel.org/ > > > > > > > 4. > > > mailto:[10][11][12][18][24]Xen-devel@lists.xen.org > > > > > > > 5. > > > [11][12][13][19][25]http://lists.xen.org/xen-devel > > > > > > > > > > > > References > > > > > > > > > > > > Visible links > > > > > > 1. mailto:[13][14][20][26]pasik@iki.fi > > > > > > 2. mailto:[14][15][21][27]pasik@iki.fi > > > > > > 3. [15][16][22][28]http://kernel.org/ > > > > > > 4. [16][17][23][29]http://kernel.org/ > > > > > > 5. > > mailto:[17][18][24][30]Xen-devel@lists.xen.org > > > > > > 6. > > [18][19][25][31]http://lists.xen.org/xen-devel > > > > > > 7. mailto:[19][20][26][32]pasik@iki.fi > > > > > > 8. [20][21][27][33]http://kernel.org/ > > > > > > 9. [21][22][28][34]http://kernel.org/ > > > > > > 10. > > mailto:[22][23][29][35]Xen-devel@lists.xen.org > > > > > > 11. > > [23][24][30][36]http://lists.xen.org/xen-devel > > > > > > > > > > References > > > > > > > > > > Visible links > > > > > 1. mailto:[25][31][37]pasik@iki.fi > > > > > 2. mailto:[26][32][38]pasik@iki.fi > > > > > 3. mailto:[27][33][39]pasik@iki.fi > > > > > 4. [28][34][40]http://kernel.org/ > > > > > 5. [29][35][41]http://kernel.org/ > > > > > 6. mailto:[30][36][42]Xen-devel@lists.xen.org > > > > > 7. [31][37][43]http://lists.xen.org/xen-devel > > > > > 8. mailto:[32][38][44]pasik@iki.fi > > > > > 9. [33][39][45]http://kernel.org/ > > > > > 10. [34][40][46]http://kernel.org/ > > > > > 11. mailto:[35][41][47]Xen-devel@lists.xen.org > > > > > 12. [36][42][48]http://lists.xen.org/xen-devel > > > > > 13. mailto:[37][43][49]pasik@iki.fi > > > > > 14. mailto:[38][44][50]pasik@iki.fi > > > > > 15. [39][45][51]http://kernel.org/ > > > > > 16. [40][46][52]http://kernel.org/ > > > > > 17. mailto:[41][47][53]Xen-devel@lists.xen.org > > > > > 18. [42][48][54]http://lists.xen.org/xen-devel > > > > > 19. mailto:[43][49][55]pasik@iki.fi > > > > > 20. [44][50][56]http://kernel.org/ > > > > > 21. [45][51][57]http://kernel.org/ > > > > > 22. mailto:[46][52][58]Xen-devel@lists.xen.org > > > > > 23. [47][53][59]http://lists.xen.org/xen-devel > > > > > > > > References > > > > > > > > Visible links > > > > 1. mailto:[54][60]pasik@iki.fi > > > > 2. mailto:[55][61]pasik@iki.fi > > > > 3. mailto:[56][62]pasik@iki.fi > > > > 4. mailto:[57][63]pasik@iki.fi > > > > 5. [58][64]http://kernel.org/ > > > > 6. [59][65]http://kernel.org/ > > > > 7. mailto:[60][66]Xen-devel@lists.xen.org > > > > 8. [61][67]http://lists.xen.org/xen-devel > > > > 9. mailto:[62][68]pasik@iki.fi > > > > 10. [63][69]http://kernel.org/ > > > > 11. [64][70]http://kernel.org/ > > > > 12. mailto:[65][71]Xen-devel@lists.xen.org > > > > 13. [66][72]http://lists.xen.org/xen-devel > > > > 14. mailto:[67][73]pasik@iki.fi > > > > 15. mailto:[68][74]pasik@iki.fi > > > > 16. [69][75]http://kernel.org/ > > > > 17. [70][76]http://kernel.org/ > > > > 18. mailto:[71][77]Xen-devel@lists.xen.org > > > > 19. [72][78]http://lists.xen.org/xen-devel > > > > 20. mailto:[73][79]pasik@iki.fi > > > > 21. [74][80]http://kernel.org/ > > > > 22. [75][81]http://kernel.org/ > > > > 23. mailto:[76][82]Xen-devel@lists.xen.org > > > > 24. [77][83]http://lists.xen.org/xen-devel > > > > 25. mailto:[78][84]pasik@iki.fi > > > > 26. mailto:[79][85]pasik@iki.fi > > > > 27. mailto:[80][86]pasik@iki.fi > > > > 28. [81][87]http://kernel.org/ > > > > 29. [82][88]http://kernel.org/ > > > > 30. mailto:[83][89]Xen-devel@lists.xen.org > > > > 31. [84][90]http://lists.xen.org/xen-devel > > > > 32. mailto:[85][91]pasik@iki.fi > > > > 33. [86][92]http://kernel.org/ > > > > 34. [87][93]http://kernel.org/ > > > > 35. mailto:[88][94]Xen-devel@lists.xen.org > > > > 36. [89][95]http://lists.xen.org/xen-devel > > > > 37. mailto:[90][96]pasik@iki.fi > > > > 38. mailto:[91][97]pasik@iki.fi > > > > 39. [92][98]http://kernel.org/ > > > > 40. [93][99]http://kernel.org/ > > > > 41. mailto:[94][100]Xen-devel@lists.xen.org > > > > 42. [95][101]http://lists.xen.org/xen-devel > > > > 43. mailto:[96][102]pasik@iki.fi > > > > 44. [97][103]http://kernel.org/ > > > > 45. [98][104]http://kernel.org/ > > > > 46. mailto:[99][105]Xen-devel@lists.xen.org > > > > 47. [100][106]http://lists.xen.org/xen-devel > > > > > > References > > > > > > Visible links > > > 1. mailto:[107]kiviniemi.valtteri@gmail.com > > > 2. [108]http://ark.intel.com/products/65719/ > > > 3. > > [109] > http://www.intel.com/content/www/us/en/motherboards/desktop-motherboards/= desktop-board-dq77mk.html > > > 4. mailto:[110]root@dataproof.fi > > > 5. mailto:[111]pasik@iki.fi > > > 6. [112]http://xen.org/ > > > 7. mailto:[113]pasik@iki.fi > > > 8. mailto:[114]pasik@iki.fi > > > 9. mailto:[115]pasik@iki.fi > > > 10. mailto:[116]pasik@iki.fi > > > 11. [117]http://kernel.org/ > > > 12. [118]http://kernel.org/ > > > 13. mailto:[119]Xen-devel@lists.xen.org > > > 14. [120]http://lists.xen.org/xen-devel > > > 15. mailto:[121]pasik@iki.fi > > > 16. [122]http://kernel.org/ > > > 17. [123]http://kernel.org/ > > > 18. mailto:[124]Xen-devel@lists.xen.org > > > 19. [125]http://lists.xen.org/xen-devel > > > 20. mailto:[126]pasik@iki.fi > > > 21. mailto:[127]pasik@iki.fi > > > 22. [128]http://kernel.org/ > > > 23. [129]http://kernel.org/ > > > 24. mailto:[130]Xen-devel@lists.xen.org > > > 25. [131]http://lists.xen.org/xen-devel > > > 26. mailto:[132]pasik@iki.fi > > > 27. [133]http://kernel.org/ > > > 28. [134]http://kernel.org/ > > > 29. mailto:[135]Xen-devel@lists.xen.org > > > 30. [136]http://lists.xen.org/xen-devel > > > 31. mailto:[137]pasik@iki.fi > > > 32. mailto:[138]pasik@iki.fi > > > 33. mailto:[139]pasik@iki.fi > > > 34. [140]http://kernel.org/ > > > 35. [141]http://kernel.org/ > > > 36. mailto:[142]Xen-devel@lists.xen.org > > > 37. [143]http://lists.xen.org/xen-devel > > > 38. mailto:[144]pasik@iki.fi > > > 39. [145]http://kernel.org/ > > > 40. [146]http://kernel.org/ > > > 41. mailto:[147]Xen-devel@lists.xen.org > > > 42. [148]http://lists.xen.org/xen-devel > > > 43. mailto:[149]pasik@iki.fi > > > 44. mailto:[150]pasik@iki.fi > > > 45. [151]http://kernel.org/ > > > 46. [152]http://kernel.org/ > > > 47. mailto:[153]Xen-devel@lists.xen.org > > > 48. [154]http://lists.xen.org/xen-devel > > > 49. mailto:[155]pasik@iki.fi > > > 50. [156]http://kernel.org/ > > > 51. [157]http://kernel.org/ > > > 52. mailto:[158]Xen-devel@lists.xen.org > > > 53. [159]http://lists.xen.org/xen-devel > > > 54. mailto:[160]pasik@iki.fi > > > 55. mailto:[161]pasik@iki.fi > > > 56. mailto:[162]pasik@iki.fi > > > 57. mailto:[163]pasik@iki.fi > > > 58. [164]http://kernel.org/ > > > 59. [165]http://kernel.org/ > > > 60. mailto:[166]Xen-devel@lists.xen.org > > > 61. [167]http://lists.xen.org/xen-devel > > > 62. mailto:[168]pasik@iki.fi > > > 63. [169]http://kernel.org/ > > > 64. [170]http://kernel.org/ > > > 65. mailto:[171]Xen-devel@lists.xen.org > > > 66. [172]http://lists.xen.org/xen-devel > > > 67. mailto:[173]pasik@iki.fi > > > 68. mailto:[174]pasik@iki.fi > > > 69. [175]http://kernel.org/ > > > 70. [176]http://kernel.org/ > > > 71. mailto:[177]Xen-devel@lists.xen.org > > > 72. [178]http://lists.xen.org/xen-devel > > > 73. mailto:[179]pasik@iki.fi > > > 74. [180]http://kernel.org/ > > > 75. [181]http://kernel.org/ > > > 76. mailto:[182]Xen-devel@lists.xen.org > > > 77. [183]http://lists.xen.org/xen-devel > > > 78. mailto:[184]pasik@iki.fi > > > 79. mailto:[185]pasik@iki.fi > > > 80. mailto:[186]pasik@iki.fi > > > 81. [187]http://kernel.org/ > > > 82. [188]http://kernel.org/ > > > 83. mailto:[189]Xen-devel@lists.xen.org > > > 84. [190]http://lists.xen.org/xen-devel > > > 85. mailto:[191]pasik@iki.fi > > > 86. [192]http://kernel.org/ > > > 87. [193]http://kernel.org/ > > > 88. mailto:[194]Xen-devel@lists.xen.org > > > 89. [195]http://lists.xen.org/xen-devel > > > 90. mailto:[196]pasik@iki.fi > > > 91. mailto:[197]pasik@iki.fi > > > 92. [198]http://kernel.org/ > > > 93. [199]http://kernel.org/ > > > 94. mailto:[200]Xen-devel@lists.xen.org > > > 95. [201]http://lists.xen.org/xen-devel > > > 96. mailto:[202]pasik@iki.fi > > > 97. [203]http://kernel.org/ > > > 98. [204]http://kernel.org/ > > > 99. mailto:[205]Xen-devel@lists.xen.org > > > 100. [206]http://lists.xen.org/xen-devel > > > > References > > > > Visible links > > 1. http://nago.fi/dmesg.txt > > 2. http://nago.fi/qemu-dm.txt > > 3. http://nago.fi/xm-dmesg.txt > > 4. http://nago.fi/domu-config.txt > > 5. http://nago.fi/dom0-config.txt > > 6. mailto:pasik@iki.fi > > 7. mailto:kiviniemi.valtteri@gmail.com > > 8. http://ark.intel.com/products/65719/ > > 9. > http://www.intel.com/content/www/us/en/motherboards/desktop-motherboards/= desktop-board-dq77mk.html > > 10. mailto:root@dataproof.fi > > 11. mailto:pasik@iki.fi > > 12. http://xen.org/ > > 13. mailto:pasik@iki.fi > > 14. mailto:pasik@iki.fi > > 15. mailto:pasik@iki.fi > > 16. mailto:pasik@iki.fi > > 17. http://kernel.org/ > > 18. http://kernel.org/ > > 19. mailto:Xen-devel@lists.xen.org > > 20. http://lists.xen.org/xen-devel > > 21. mailto:pasik@iki.fi > > 22. http://kernel.org/ > > 23. http://kernel.org/ > > 24. mailto:Xen-devel@lists.xen.org > > 25. http://lists.xen.org/xen-devel > > 26. mailto:pasik@iki.fi > > 27. mailto:pasik@iki.fi > > 28. http://kernel.org/ > > 29. http://kernel.org/ > > 30. mailto:Xen-devel@lists.xen.org > > 31. http://lists.xen.org/xen-devel > > 32. mailto:pasik@iki.fi > > 33. http://kernel.org/ > > 34. http://kernel.org/ > > 35. mailto:Xen-devel@lists.xen.org > > 36. http://lists.xen.org/xen-devel > > 37. mailto:pasik@iki.fi > > 38. mailto:pasik@iki.fi > > 39. mailto:pasik@iki.fi > > 40. http://kernel.org/ > > 41. http://kernel.org/ > > 42. mailto:Xen-devel@lists.xen.org > > 43. http://lists.xen.org/xen-devel > > 44. mailto:pasik@iki.fi > > 45. http://kernel.org/ > > 46. http://kernel.org/ > > 47. mailto:Xen-devel@lists.xen.org > > 48. http://lists.xen.org/xen-devel > > 49. mailto:pasik@iki.fi > > 50. mailto:pasik@iki.fi > > 51. http://kernel.org/ > > 52. http://kernel.org/ > > 53. mailto:Xen-devel@lists.xen.org > > 54. http://lists.xen.org/xen-devel > > 55. mailto:pasik@iki.fi > > 56. http://kernel.org/ > > 57. http://kernel.org/ > > 58. mailto:Xen-devel@lists.xen.org > > 59. http://lists.xen.org/xen-devel > > 60. mailto:pasik@iki.fi > > 61. mailto:pasik@iki.fi > > 62. mailto:pasik@iki.fi > > 63. mailto:pasik@iki.fi > > 64. http://kernel.org/ > > 65. http://kernel.org/ > > 66. mailto:Xen-devel@lists.xen.org > > 67. http://lists.xen.org/xen-devel > > 68. mailto:pasik@iki.fi > > 69. http://kernel.org/ > > 70. http://kernel.org/ > > 71. mailto:Xen-devel@lists.xen.org > > 72. http://lists.xen.org/xen-devel > > 73. mailto:pasik@iki.fi > > 74. mailto:pasik@iki.fi > > 75. http://kernel.org/ > > 76. http://kernel.org/ > > 77. mailto:Xen-devel@lists.xen.org > > 78. http://lists.xen.org/xen-devel > > 79. mailto:pasik@iki.fi > > 80. http://kernel.org/ > > 81. http://kernel.org/ > > 82. mailto:Xen-devel@lists.xen.org > > 83. http://lists.xen.org/xen-devel > > 84. mailto:pasik@iki.fi > > 85. mailto:pasik@iki.fi > > 86. mailto:pasik@iki.fi > > 87. http://kernel.org/ > > 88. http://kernel.org/ > > 89. mailto:Xen-devel@lists.xen.org > > 90. http://lists.xen.org/xen-devel > > 91. mailto:pasik@iki.fi > > 92. http://kernel.org/ > > 93. http://kernel.org/ > > 94. mailto:Xen-devel@lists.xen.org > > 95. http://lists.xen.org/xen-devel > > 96. mailto:pasik@iki.fi > > 97. mailto:pasik@iki.fi > > 98. http://kernel.org/ > > 99. http://kernel.org/ > > 100. mailto:Xen-devel@lists.xen.org > > 101. http://lists.xen.org/xen-devel > > 102. mailto:pasik@iki.fi > > 103. http://kernel.org/ > > 104. http://kernel.org/ > > 105. mailto:Xen-devel@lists.xen.org > > 106. http://lists.xen.org/xen-devel > > 107. mailto:kiviniemi.valtteri@gmail.com > > 108. http://ark.intel.com/products/65719/ > > 109. > http://www.intel.com/content/www/us/en/motherboards/desktop-motherboards/= desktop-board-dq77mk.html > > 110. mailto:root@dataproof.fi > > 111. mailto:pasik@iki.fi > > 112. http://xen.org/ > > 113. mailto:pasik@iki.fi > > 114. mailto:pasik@iki.fi > > 115. mailto:pasik@iki.fi > > 116. mailto:pasik@iki.fi > > 117. http://kernel.org/ > > 118. http://kernel.org/ > > 119. mailto:Xen-devel@lists.xen.org > > 120. http://lists.xen.org/xen-devel > > 121. mailto:pasik@iki.fi > > 122. http://kernel.org/ > > 123. http://kernel.org/ > > 124. mailto:Xen-devel@lists.xen.org > > 125. http://lists.xen.org/xen-devel > > 126. mailto:pasik@iki.fi > > 127. mailto:pasik@iki.fi > > 128. http://kernel.org/ > > 129. http://kernel.org/ > > 130. mailto:Xen-devel@lists.xen.org > > 131. http://lists.xen.org/xen-devel > > 132. mailto:pasik@iki.fi > > 133. http://kernel.org/ > > 134. http://kernel.org/ > > 135. mailto:Xen-devel@lists.xen.org > > 136. http://lists.xen.org/xen-devel > > 137. mailto:pasik@iki.fi > > 138. mailto:pasik@iki.fi > > 139. mailto:pasik@iki.fi > > 140. http://kernel.org/ > > 141. http://kernel.org/ > > 142. mailto:Xen-devel@lists.xen.org > > 143. http://lists.xen.org/xen-devel > > 144. mailto:pasik@iki.fi > > 145. http://kernel.org/ > > 146. http://kernel.org/ > > 147. mailto:Xen-devel@lists.xen.org > > 148. http://lists.xen.org/xen-devel > > 149. mailto:pasik@iki.fi > > 150. mailto:pasik@iki.fi > > 151. http://kernel.org/ > > 152. http://kernel.org/ > > 153. mailto:Xen-devel@lists.xen.org > > 154. http://lists.xen.org/xen-devel > > 155. mailto:pasik@iki.fi > > 156. http://kernel.org/ > > 157. http://kernel.org/ > > 158. mailto:Xen-devel@lists.xen.org > > 159. http://lists.xen.org/xen-devel > > 160. mailto:pasik@iki.fi > > 161. mailto:pasik@iki.fi > > 162. mailto:pasik@iki.fi > > 163. mailto:pasik@iki.fi > > 164. http://kernel.org/ > > 165. http://kernel.org/ > > 166. mailto:Xen-devel@lists.xen.org > > 167. http://lists.xen.org/xen-devel > > 168. mailto:pasik@iki.fi > > 169. http://kernel.org/ > > 170. http://kernel.org/ > > 171. mailto:Xen-devel@lists.xen.org > > 172. http://lists.xen.org/xen-devel > > 173. mailto:pasik@iki.fi > > 174. mailto:pasik@iki.fi > > 175. http://kernel.org/ > > 176. http://kernel.org/ > > 177. mailto:Xen-devel@lists.xen.org > > 178. http://lists.xen.org/xen-devel > > 179. mailto:pasik@iki.fi > > 180. http://kernel.org/ > > 181. http://kernel.org/ > > 182. mailto:Xen-devel@lists.xen.org > > 183. http://lists.xen.org/xen-devel > > 184. mailto:pasik@iki.fi > > 185. mailto:pasik@iki.fi > > 186. mailto:pasik@iki.fi > > 187. http://kernel.org/ > > 188. http://kernel.org/ > > 189. mailto:Xen-devel@lists.xen.org > > 190. http://lists.xen.org/xen-devel > > 191. mailto:pasik@iki.fi > > 192. http://kernel.org/ > > 193. http://kernel.org/ > > 194. mailto:Xen-devel@lists.xen.org > > 195. http://lists.xen.org/xen-devel > > 196. mailto:pasik@iki.fi > > 197. mailto:pasik@iki.fi > > 198. http://kernel.org/ > > 199. http://kernel.org/ > > 200. mailto:Xen-devel@lists.xen.org > > 201. http://lists.xen.org/xen-devel > > 202. mailto:pasik@iki.fi > > 203. http://kernel.org/ > > 204. http://kernel.org/ > > 205. mailto:Xen-devel@lists.xen.org > > 206. http://lists.xen.org/xen-devel > --20cf30563c0d436e7b04cb13c0b5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I have not enabled debug on Xen or dom0 kernel. Could you tell m= e the parameters for Xen coompilation needed to enable debugging? And If yo= u would also happen to know what are the options needed to enable kernel de= bugging in menuconfig? Well I can probably manage to get the kernel debuggi= ng enabled myself, but if you happen to know them please share so maybe I c= an get everything enabled at the first try :)

Thanks!

- Valtteri

2012/10/2 P= asi K=E4rkk=E4inen <pasik@iki.fi>
On Tue, Oct 02, 2012 at 04:01:04PM +0300, Valtteri Kivini= emi wrote:
> =A0 =A0Hi,
>
> =A0 =A0I already tried 3.2, 3.5, 3.5.0, 3.6.0-= rc7 and 3.6.0, same problem all of
> =A0 =A0those. My dom0 config is the same config that I'am using on= other server
> =A0 =A0where HVM is working, so I dont think that it is a config probl= em. I have
> =A0 =A0triple checked everything and all should be ok. dom0 dmesg show= s the same
> =A0 =A0crash that I have previously posted here. /var/log/xen/ does no= t contain
> =A0 =A0any specific errors.
>
> =A0 =A0Could this be some kind of broblem with my motherboard bios bei= ng buggy or
> =A0 =A0CPU not supported? I'm using the new intel Ivy Bridge proce= ssor which has
> =A0 =A0integrated GPU, but that should not probably cause these kind o= f problems.
> =A0 =A0Or maybe some ACPI problem? xm dmesg is showing some notices ab= out ACPI.
> =A0 =A0Is there any ACPI kernel parameters that I should try booting? = This has to
> =A0 =A0be somekind of problem with my hardware, or then maybe it could= be a
> =A0 =A0kernel problem too. I just really cant figure this out myself, = I have
> =A0 =A0tried everything.
>

Hmm.. I have some distant memories of seeing a patch that fixes a bug=
on recent Ivy Bridge systems, but I can't find a link right now.
Maybe you're affected by that..

Also: Did you already post the crash log, with all the debug/verbose option= s enabled for both Xen and dom0 kernel?

-- Pasi

> =A0 =A0Lets take a quick summary of what has been tested, what hardwar= e I'm using
> =A0 =A0etc.
>
> =A0 =A0Xen-versions tested: 4.2.0, 4.0.4
> =A0 =A0Kernel-versions tested: 3.2.0, 3.5.0, 3.5.4, 3.6.0-rc7, 3.6.0 >
> =A0 =A0Host OS: Debian testing/wheezy, udev version 175-7, 2.13-35, py= thon
> =A0 =A0version 2.7.3~rc2-2.1
>
> =A0 =A0Hardware:
>
> =A0 =A0CPU: Intel Core i7-3770 3.4GHz
> =A0 =A0MB: Intel DQ77MK (latest bios updated)
> =A0 =A0Memory: 32GB (4 x 8GB DDR3-1600MHz)
>
> =A0 =A0All relevant log files and configs:
>
> =A0 =A0dom0 dmesg: [1]http://nago.fi/dmesg.txt
> =A0 =A0qemu-dm log: [2]http://nago.fi/qemu-dm.txt
> =A0 =A0xm dmesg log: [3]http://nago.fi/xm-dmesg.txt
> =A0 =A0domU config: [4]http://nago.fi/domu-config.txt
> =A0 =A0dom0 kernel config: [5]http://nago.fi/dom0-config.txt
>
> =A0 =A0I have also tried playing with every setting on that domU that = I can think
> =A0 =A0of and tried different configs etc.
>
> =A0 =A0- Valtteri
>
> =A0 =A02012/10/2 Pasi K=E4rkk=E4inen <[6]pasik@iki.fi>
>
> =A0 =A0 =A0On Tue, Oct 02, 2012 at 03:11:07PM +0300, Valtteri Kiviniem= i wrote:
> =A0 =A0 =A0> =A0 =A0Hi,
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0Another update:
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0I wanted to check that if a Linux HVM would boo= t with working VNC
> =A0 =A0 =A0console,
> =A0 =A0 =A0> =A0 =A0so I tried to launch a Debian Squeeze installer= on HVM. It refused
> =A0 =A0 =A0to
> =A0 =A0 =A0> =A0 =A0start ant told me that vbd hotplug scripts were= not working. After
> =A0 =A0 =A0that
> =A0 =A0 =A0> =A0 =A0failure even the Windows domU would not anymore= start which was
> =A0 =A0 =A0previously
> =A0 =A0 =A0> =A0 =A0starting ok.
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0The hotplug scripts also starts hanging on the = processes.
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0root =A0 =A0 =A09401 =A00.1 =A00.1 =A017700 =A0= 1640 ? =A0 =A0 =A0 =A0S =A0 =A015:05 =A0 0:00
> =A0 =A0 =A0/bin/bash
> =A0 =A0 =A0> =A0 =A0/etc/xen/scripts/xen-hotplug-cleanup
> =A0 =A0 =A0> =A0 =A0root =A0 =A0 =A09441 =A00.1 =A00.1 =A017700 =A0= 1644 ? =A0 =A0 =A0 =A0S =A0 =A015:05 =A0 0:00
> =A0 =A0 =A0/bin/bash
> =A0 =A0 =A0> =A0 =A0/etc/xen/scripts/xen-hotplug-cleanup
> =A0 =A0 =A0> =A0 =A0root =A0 =A0 =A09481 =A00.1 =A00.1 =A017700 =A0= 1640 ? =A0 =A0 =A0 =A0S =A0 =A015:05 =A0 0:00
> =A0 =A0 =A0/bin/bash
> =A0 =A0 =A0> =A0 =A0/etc/xen/scripts/xen-hotplug-cleanup
> =A0 =A0 =A0> =A0 =A0root =A0 =A0 =A09560 =A00.1 =A00.1 =A017700 =A0= 1640 ? =A0 =A0 =A0 =A0S =A0 =A015:05 =A0 0:00
> =A0 =A0 =A0/bin/bash
> =A0 =A0 =A0> =A0 =A0/etc/xen/scripts/xen-hotplug-cleanup
> =A0 =A0 =A0> =A0 =A0root =A0 =A0 10738 =A00.1 =A00.1 =A017696 =A016= 36 ? =A0 =A0 =A0 =A0S =A0 =A015:05 =A0 0:00
> =A0 =A0 =A0/bin/bash
> =A0 =A0 =A0> =A0 =A0/etc/xen/scripts/xen-hotplug-cleanup
> =A0 =A0 =A0> =A0 =A0root =A0 =A0 10747 =A00.1 =A00.1 =A017792 =A017= 36 ? =A0 =A0 =A0 =A0S =A0 =A015:05 =A0 0:00
> =A0 =A0 =A0/bin/bash
> =A0 =A0 =A0> =A0 =A0/etc/xen/scripts/block remove
> =A0 =A0 =A0> =A0 =A0root =A0 =A0 11286 =A00.0 =A00.0 =A0 4080 =A0 3= 24 ? =A0 =A0 =A0 =A0S =A0 =A015:06 =A0 0:00
> =A0 =A0 =A0sleep 1
> =A0 =A0 =A0> =A0 =A0root =A0 =A0 11290 =A00.0 =A00.0 =A0 4080 =A0 3= 24 ? =A0 =A0 =A0 =A0S =A0 =A015:06 =A0 0:00
> =A0 =A0 =A0sleep 1
> =A0 =A0 =A0> =A0 =A0root =A0 =A0 11294 =A00.0 =A00.0 =A0 4080 =A0 3= 24 ? =A0 =A0 =A0 =A0S =A0 =A015:06 =A0 0:00
> =A0 =A0 =A0sleep 1
> =A0 =A0 =A0> =A0 =A0root =A0 =A0 11298 =A00.0 =A00.0 =A0 4080 =A0 3= 24 ? =A0 =A0 =A0 =A0S =A0 =A015:06 =A0 0:00
> =A0 =A0 =A0sleep 1
> =A0 =A0 =A0> =A0 =A0root =A0 =A0 11302 =A00.0 =A00.0 =A0 4080 =A0 3= 20 ? =A0 =A0 =A0 =A0S =A0 =A015:06 =A0 0:00
> =A0 =A0 =A0sleep 1
> =A0 =A0 =A0> =A0 =A0root =A0 =A0 11306 =A00.0 =A00.0 =A0 4080 =A0 3= 20 ? =A0 =A0 =A0 =A0S =A0 =A015:06 =A0 0:00
> =A0 =A0 =A0sleep 1
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0Then I did a xm destroy and I had again the ker= nel BUG on dmesg. So
> =A0 =A0 =A0it
> =A0 =A0 =A0> =A0 =A0seems that the problem is not fixed by using 3.= 6.0. Udev version is
> =A0 =A0 =A0175-7.
> =A0 =A0 =A0>
>
> =A0 =A0 =A0So you have definitely something broken in your system,
> =A0 =A0 =A0probably in your dom0 kernel. Try with Linux 3.5.4 or 3.4.x= ,
> =A0 =A0 =A0and see how that goes.
>
> =A0 =A0 =A0Any errors in dom0 dmesg? How about in /var/log/xen/* ?
>
> =A0 =A0 =A0-- Pasi
>
> =A0 =A0 =A0>
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A02012/10/1 Valtteri Kiviniemi <[1= ][7]kiviniemi.valtteri@gmai= l.com>
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0Hi,
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0CPU: Intel Core i7-3770 3.4GHz
> =A0 =A0 =A0> =A0 =A0 =A0[2][8]http://ark.intel.com/products/65719/
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0MB: Intel DQ77MK (latest bios updated)
> =A0 =A0 =A0>
> =A0 =A0 =A0 [3][9]http://www.intel.com/content/www/us/en/motherboards/desktop-motherb= oards/desktop-board-dq77mk.html
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0Memory: 32GB (4 x 8GB DDR3-1600MHz)
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0Host is Debian wheezy/testing, Xen 4.0.4 an= d latest 3.6.0 kernel.
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0Noticed also some errors in xm dmesg:
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0root@xen-2:~# xm dmesg
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Xen version 4.0.4 ([4][10]root@dataproof.fi) (gcc version
> =A0 =A0 =A04.7.1
> =A0 =A0 =A0> =A0 =A0 =A0(Debian 4.7.1-7) ) Sun Sep 30 20:28:26 EEST= 2012
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Latest ChangeSet: unavailable
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Bootloader: GNU GRUB 0.97
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Command line: dom0_mem=3D1280M cpufre= q=3Dxen clocksource=3Dhpet
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Video information:
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0VGA is text mode 80x25, font 8x16<= br> > =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0VBE/DDC methods: none; EDID transf= er time: 0 seconds
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0EDID info not retrieved because no= DDC retrieval method
> =A0 =A0 =A0detected
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Disc information:
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0Found 4 MBR signatures
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0Found 4 EDD information structures=
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Xen-e820 RAM map:
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A00000000000000000 - 000000000009d80= 0 (usable)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0000000000009d800 - 00000000000a000= 0 (reserved)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A000000000000e0000 - 000000000010000= 0 (reserved)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A00000000000100000 - 000000002000000= 0 (usable)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A00000000020000000 - 000000002020000= 0 (reserved)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A00000000020200000 - 000000004000400= 0 (usable)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A00000000040004000 - 000000004000500= 0 (reserved)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A00000000040005000 - 00000000dbe4400= 0 (usable)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A000000000dbe44000 - 00000000dc2d700= 0 (reserved)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A000000000dc2d7000 - 00000000dc2e700= 0 (ACPI data)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A000000000dc2e7000 - 00000000dc40c00= 0 (ACPI NVS)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A000000000dc40c000 - 00000000dc6af00= 0 (reserved)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A000000000dc6af000 - 00000000dc6b000= 0 (usable)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A000000000dc6b0000 - 00000000dc6f300= 0 (ACPI NVS)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A000000000dc6f3000 - 00000000dd00000= 0 (usable)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A000000000dd800000 - 00000000dfa0000= 0 (reserved)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A000000000f8000000 - 00000000fc00000= 0 (reserved)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A000000000fec00000 - 00000000fec0100= 0 (reserved)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A000000000fed00000 - 00000000fed0400= 0 (reserved)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A000000000fed1c000 - 00000000fed2000= 0 (reserved)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A000000000fee00000 - 00000000fee0100= 0 (reserved)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A000000000ff000000 - 000000010000000= 0 (reserved)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A00000000100000000 - 000000081e60000= 0 (usable)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) ACPI: RSDP 000F0490, 0024 (r2 =A0INTE= L)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) ACPI: XSDT DC2DB080, 007C (r1 INTEL = =A0DQ77MK =A0 =A0 =A0 =A0 32 AMI
> =A0 =A0 =A0> =A0 =A0 =A010013)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) ACPI: FACP DC2E51F0, 010C (r5 INTEL = =A0DQ77MK =A0 =A0 =A0 =A0 32 AMI
> =A0 =A0 =A0> =A0 =A0 =A010013)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) ACPI Warning (tbfadt-0232): FADT (rev= ision 5) is longer
> =A0 =A0 =A0than ACPI
> =A0 =A0 =A0> =A0 =A0 =A02.0 version, truncating length 0x10C to 0xF= 4 [20070126]
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) ACPI: DSDT DC2DB188, A061 (r2 INTEL = =A0DQ77MK =A0 =A0 =A0 =A0 32 INTL
> =A0 =A0 =A0> =A0 =A0 =A020051117)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) ACPI: FACS DC40A080, 0040
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) ACPI: APIC DC2E5300, 0092 (r3 INTEL = =A0DQ77MK =A0 =A0 =A0 =A0 32 AMI
> =A0 =A0 =A0> =A0 =A0 =A010013)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) ACPI: FPDT DC2E5398, 0044 (r1 INTEL = =A0DQ77MK =A0 =A0 =A0 =A0 32 AMI
> =A0 =A0 =A0> =A0 =A0 =A010013)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) ACPI: TCPA DC2E53E0, 0032 (r2 INTEL = =A0DQ77MK =A0 =A0 =A0 =A0 32 MSFT
> =A0 =A0 =A0> =A0 =A0 =A01000013)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) ACPI: MCFG DC2E5418, 003C (r1 INTEL = =A0DQ77MK =A0 =A0 =A0 =A0 32 MSFT
> =A0 =A0 =A0> =A0 =A0 =A097)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) ACPI: HPET DC2E5458, 0038 (r1 INTEL = =A0DQ77MK =A0 =A0 =A0 =A0 32 AMI.
> =A0 =A0 =A0> =A0 =A0 =A05)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) ACPI: SSDT DC2E5490, 036D (r1 INTEL = =A0DQ77MK =A0 =A0 =A0 =A0 32 INTL
> =A0 =A0 =A0> =A0 =A0 =A020091112)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) ACPI: SSDT DC2E5800, 09AA (r1 INTEL = =A0DQ77MK =A0 =A0 =A0 =A0 32 INTL
> =A0 =A0 =A0> =A0 =A0 =A020051117)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) ACPI: SSDT DC2E61B0, 0A92 (r1 INTEL = =A0DQ77MK =A0 =A0 =A0 =A0 32 INTL
> =A0 =A0 =A0> =A0 =A0 =A020051117)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) ACPI: DMAR DC2E6C48, 00B8 (r1 INTEL = =A0DQ77MK =A0 =A0 =A0 =A0 32 INTL
> =A0 =A0 =A0> =A0 =A0 =A01)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) ACPI: ASF! DC2E6D00, 00A5 (r32 INTEL = =A0DQ77MK =A0 =A0 =A0 =A0 32
> =A0 =A0 =A0TFSM
> =A0 =A0 =A0> =A0 =A0 =A0F4240)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) System RAM: 32682MB (33467320kB)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Domain heap initialised
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) ACPI: 32/64X FACS address mismatch in= FADT -
> =A0 =A0 =A0> =A0 =A0 =A0dc40a080/0000000000000000, using 32
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Processor #0 7:10 APIC version 21
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Processor #2 7:10 APIC version 21
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Processor #4 7:10 APIC version 21
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Processor #6 7:10 APIC version 21
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Processor #1 7:10 APIC version 21
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Processor #3 7:10 APIC version 21
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Processor #5 7:10 APIC version 21
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Processor #7 7:10 APIC version 21
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) IOAPIC[0]: apic_id 2, version 32, add= ress 0xfec00000, GSI
> =A0 =A0 =A00-23
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Enabling APIC mode: =A0Flat. =A0Using= 1 I/O APICs
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Switched to APIC driver x2apic_cluste= r.
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) x2APIC mode enabled.
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Using scheduler: SMP Credit Scheduler= (credit)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Detected 3392.369 MHz processor.
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Initing memory sharing.
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) VMX: Supported advanced features:
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0- APIC MMIO access virtualisation<= br> > =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0- APIC TPR shadow
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0- Extended Page Tables (EPT)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0- Virtual-Processor Identifiers (V= PID)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0- Virtual NMI
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0- MSR direct-access bitmap
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0- Unrestricted Guest
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) EPT supports 2MB super page.
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) HVM: ASIDs enabled.
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) HVM: VMX enabled
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) HVM: Hardware Assisted Paging detecte= d.
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Intel VT-d Snoop Control not enabled.=
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Intel VT-d Dom0 DMA Passthrough not e= nabled.
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Intel VT-d Queued Invalidation enable= d.
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Intel VT-d Interrupt Remapping enable= d.
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) I/O virtualisation enabled
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0- Dom0 mode: Relaxed
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Enabled directed EOI with ioapic_ack_= old on!
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Total of 8 processors activated.
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) ENABLING IO-APIC IRQs
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0-> Using old ACK method
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) TSC is reliable, synchronization unne= cessary
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Platform timer appears to have unexpe= ctedly wrapped 1
> =A0 =A0 =A0times.
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Platform timer is 14.318MHz HPET
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Allocated console ring of 16 KiB.
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Brought up 8 CPUs
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) *** LOADING DOMAIN 0 ***
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0Xen =A0kernel: 64-bit, lsb, compat= 32
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0Dom0 kernel: 64-bit, PAE, lsb, pad= dr 0x1000000 ->
> =A0 =A0 =A00x1ae7000
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) PHYSICAL MEMORY ARRANGEMENT:
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0Dom0 alloc.: =A0 0000000804000000-= >0000000806000000 (319488
> =A0 =A0 =A0pages
> =A0 =A0 =A0> =A0 =A0 =A0to be allocated)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) VIRTUAL MEMORY ARRANGEMENT:
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0Loaded kernel: ffffffff81000000-&g= t;ffffffff81ae7000
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0Init. ramdisk: ffffffff81ae7000-&g= t;ffffffff81ae7000
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0Phys-Mach map: ffffffff81ae7000-&g= t;ffffffff81d67000
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0Start info: =A0 =A0ffffffff81d6700= 0->ffffffff81d674b4
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0Page tables: =A0 ffffffff81d68000-= >ffffffff81d7b000
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0Boot stack: =A0 =A0ffffffff81d7b00= 0->ffffffff81d7c000
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0TOTAL: =A0 =A0 =A0 =A0 ffffffff800= 00000->ffffffff82000000
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) =A0ENTRY ADDRESS: ffffffff815e3210 > =A0 =A0 =A0> =A0 =A0 =A0(XEN) Dom0 has maximum 8 VCPUs
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) [VT-D]iommu.c:718: BIOS did not enabl= e IGD for VT properly.
> =A0 =A0 =A0> =A0 =A0 =A0Disabling IGD VT-d engine.
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Scrubbing Free RAM: done.
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Xen trace buffers: disabled
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Std. Loglevel: Errors and warnings > =A0 =A0 =A0> =A0 =A0 =A0(XEN) Guest Loglevel: Nothing (Rate-limited= : Errors and warnings)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Xen is relinquishing VGA console.
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) *** Serial input -> DOM0 (type = 9;CTRL-a' three times to
> =A0 =A0 =A0switch
> =A0 =A0 =A0> =A0 =A0 =A0input to Xen)
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) Freed 172kB init memory.
> =A0 =A0 =A0> =A0 =A0 =A0(XEN) traps.c:2333:d0 Domain attempted WRMS= R 000000000000008b
> =A0 =A0 =A0from
> =A0 =A0 =A0> =A0 =A0 =A000000012:00000000 to 00000000:00000000.
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0- Valtteri
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A02012/10/1 Pasi K=E4rkk=E4inen &= lt;[5][11]pasik@iki.fi>
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0On Mon, Oct 01, 2012 at 09:12:50PM +030= 0, Valtteri Kiviniemi
> =A0 =A0 =A0wrote:
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0Hi,
> =A0 =A0 =A0> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0Lowering memory or vcpu'= ;s does not help, problem is the
> =A0 =A0 =A0same. I
> =A0 =A0 =A0> =A0 =A0 =A0 =A0originally
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0installed Xen 4.2.0 and the= problem was same on that too.
> =A0 =A0 =A0Then I
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0downgraded back to 4.0.4 si= nce I thought that this might
> =A0 =A0 =A0be a bug
> =A0 =A0 =A0> =A0 =A0 =A0 =A0on
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A04.2.0. I have been previous= ly running Windows Server 2008
> =A0 =A0 =A0R2
> =A0 =A0 =A0> =A0 =A0 =A0 =A0succesfully
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0on Xen 4.0.x on different h= ardware with this same config.
> =A0 =A0 =A0> =A0 =A0 =A0 =A0Hypervisor is
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A064bit and windows is 64bit.=
> =A0 =A0 =A0> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0Any ideas what to try next?=
> =A0 =A0 =A0> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0What kind of hardware is that?
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0[6][12]xen.org automated testing regularly tests Windows VM= s,
> =A0 =A0 =A0and it works
> =A0 =A0 =A0> =A0 =A0 =A0 =A0OK there.
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0-- Pasi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0Ps. qemu-dm.log is the foll= owing:
> =A0 =A0 =A0> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0domid: 10
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0config qemu network with xe= n bridge for =A0tap10.0 xenbr0
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0Using file /dev/virtuals/ts= in read-write mode
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0Using file /media/iso/windo= ws_server_2008_r2_sp1.iso in
> =A0 =A0 =A0read-only
> =A0 =A0 =A0> =A0 =A0 =A0 =A0mode
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0Watching /local/domain/0/de= vice-model/10/logdirty/cmd
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0Watching /local/domain/0/de= vice-model/10/command
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0qemu_map_cache_init nr_buck= ets =3D 10000 size 4194304
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0shared page at pfn feffd > =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0buffered io page at pfn fef= fb
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0Guest uuid =3D 52f19e23-295= 5-c27d-a22c-60c5d8c60d5a
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0Time offset set 0
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0populating video RAM at ff0= 00000
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0mapping video RAM from ff00= 0000
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0Register xen platform.
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0Done register platform.
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0platform_fixed_ioport: chan= ged ro/rw state of ROM memory
> =A0 =A0 =A0area.
> =A0 =A0 =A0> =A0 =A0 =A0 =A0now is rw
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0state.
> =A0 =A0 =A0> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0 xs_read(/local/domain/0/device-model/10/xen_extended_power= _mgmt):
> =A0 =A0 =A0> =A0 =A0 =A0 =A0read
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0error
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0medium change watch on `hdc= ' (index: 1):
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0/media/iso/windows_server_2= 008_r2_sp1.iso
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0I/O request not ready: 0, p= tr: 0, port: 0, data: 0, count:
> =A0 =A0 =A00,
> =A0 =A0 =A0> =A0 =A0 =A0 =A0size: 0
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0Log-dirty: no command yet.<= br> > =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0xs_read(/local/domain/10/lo= g-throttling): read error
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0qemu: ignoring not-understo= od drive
> =A0 =A0 =A0> =A0 =A0 =A0 =A0`/local/domain/10/log-throttling' > =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0medium change watch on `/lo= cal/domain/10/log-throttling' -
> =A0 =A0 =A0> =A0 =A0 =A0 =A0unknown device,
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0ignored
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0cirrus vga map change while= on lfb mode
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0mapping vram to f0000000 - = f0400000
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0platform_fixed_ioport: chan= ged ro/rw state of ROM memory
> =A0 =A0 =A0area.
> =A0 =A0 =A0> =A0 =A0 =A0 =A0now is rw
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0state.
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0platform_fixed_ioport: chan= ged ro/rw state of ROM memory
> =A0 =A0 =A0area.
> =A0 =A0 =A0> =A0 =A0 =A0 =A0now is ro
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0state.
> =A0 =A0 =A0> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A02012/10/1 Pasi = K=E4rkk=E4inen <[1][7][13]pasik@iki.fi>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0On Mon, Oct 01, 2012 at= 07:23:44PM +0300, Valtteri
> =A0 =A0 =A0Kiviniemi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0wrote:
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0Hi,
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0I have trie= d other config files, but the problem is
> =A0 =A0 =A0the
> =A0 =A0 =A0> =A0 =A0 =A0 =A0same. At
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0the
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0moment I= 9;m using a config file from another server
> =A0 =A0 =A0where I
> =A0 =A0 =A0> =A0 =A0 =A0 =A0have a
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0working
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0Windows Ser= ver 2008 R2 installation, so I dont
> =A0 =A0 =A0think that
> =A0 =A0 =A0> =A0 =A0 =A0 =A0there is
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0anything wr= ong with my config:
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0Did you try with less v= cpus, for example 2 ?
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0how about with less mem= ory, say 2 GB ?
> =A0 =A0 =A0> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0Did you try with later = Xen versions? Is that a 32bit
> =A0 =A0 =A0Xen, or
> =A0 =A0 =A0> =A0 =A0 =A0 =A064bit Xen
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0hypervisor?
> =A0 =A0 =A0> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0-- Pasi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0kernel =3D = "/usr/lib/xen/boot/hvmloader"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0builder =3D= "hvm"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0shadow_memo= ry =3D "8"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0memory =3D = "4096"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0name =3D &q= uot;ts"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0vcpus =3D &= quot;8"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0cpus =3D [&= quot;0", "1", "2", "3", "4", &= quot;5", "6", "7"]
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0pae =3D &qu= ot;1"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0acpi =3D &q= uot;1"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0apic =3D &q= uot;1"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0vfb =3D [ &= #39;type=3Dvnc, vnclisten=3D10.100.100.50,
> =A0 =A0 =A0vncpasswd=3Dxxx'
> =A0 =A0 =A0> =A0 =A0 =A0 =A0]
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0xen_extende= d_power_mgmt =3D "0"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0vif =3D [ &= quot;type=3Dioemu, mac=3D00:16:3e:d7:d7:5d,
> =A0 =A0 =A0bridge=3Dxenbr0"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0]
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0disk =3D [ = "phy:/dev/virtuals/ts,hda,w",
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0 "file:/media/iso/windows_server_2= 008_r2_sp1.iso,hdc:cdrom,r" ]
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0on_poweroff= =3D "destroy"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0on_reboot = =3D "restart"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0on_crash = =3D "restart"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0viridian = =3D "1"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0device_mode= l =3D "/usr/lib/xen/bin/qemu-dm"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0boot =3D &q= uot;dc"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0snapshot = =3D "0"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0vncconsole = =3D "1"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0sdl =3D &qu= ot;0"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0opengl =3D = "0"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0vnc =3D &qu= ot;1"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0nographic = =3D "0"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0stdvga =3D = "0"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0tsc_mode = =3D "1"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0monitor =3D= "0"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0localtime = =3D "1"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0usb =3D &qu= ot;0"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0keymap =3D = "fi"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0xen_platfor= m_pci =3D "1"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0pci_msitran= slate =3D "1"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0pci_power_m= gmt =3D "0"
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A02012/10/1 P= asi K=E4rkk=E4inen
> =A0 =A0 =A0<[1][2][8][14]pasik@iki.fi>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0><= br> > =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0On Mon,= Oct 01, 2012 at 06:46:08PM +0300,
> =A0 =A0 =A0Valtteri
> =A0 =A0 =A0> =A0 =A0 =A0 =A0Kiviniemi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0wrote:
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0Hi,
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> > =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0Yes, I have viridian=3D1 on my domU config.
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> > =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0Try wit= h some known good domU configfile.
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0-- Pasi=
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A02012/10/1 Pasi K=E4rkk=E4inen
> =A0 =A0 =A0> =A0 =A0 =A0 =A0<[1][2][3][9][15]pasik@iki.fi>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0= > =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0On Mon, Oct 01, 2012 at 05:06:53PM +0300,
> =A0 =A0 =A0> =A0 =A0 =A0 =A0Valtteri
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0Kiviniemi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0wrote:<= br> > =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0Hi,
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0I'm now using 3.6.0 and can't
> =A0 =A0 =A0reproduce that
> =A0 =A0 =A0> =A0 =A0 =A0 =A0crash
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0anymore,
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0so it > =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0seems
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0that it was a kernel bug.
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> > =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0OK.
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0However I'm still getting black
> =A0 =A0 =A0screen on
> =A0 =A0 =A0> =A0 =A0 =A0 =A0VNC
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0when trying to install Windows Server
> =A0 =A0 =A02008
> =A0 =A0 =A0> =A0 =A0 =A0 =A0R2. I can
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0see the
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0"windows is
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0loading files" screen but after the
> =A0 =A0 =A0> =A0 =A0 =A0 =A0installer starts
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0the VNC
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0display goes
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0black.
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0Any ideas?
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> > =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0Do you have viridian=3D1 specified for the
> =A0 =A0 =A0windows
> =A0 =A0 =A0> =A0 =A0 =A0 =A0vm?
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> > =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0-- Pasi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> > =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0- Valtteri
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A02012/10/1 Pasi K=E4rkk=E4inen
> =A0 =A0 =A0> =A0 =A0 =A0 =A0<[1][2][3][4][10][16]pasik@iki.fi>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0= > =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0On Sun, Sep 30, 2012 at 11:18:03PM
> =A0 =A0 =A0+0300,
> =A0 =A0 =A0> =A0 =A0 =A0 =A0Valtteri
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0Kivinie= mi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0wrote:
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0Hi,
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0Hello,
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0I'm trying to get Windows
> =A0 =A0 =A0Server 2008
> =A0 =A0 =A0> =A0 =A0 =A0 =A0R2
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0installation
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0booting on
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0Xen
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A04.0.4. Using the following
> =A0 =A0 =A0config:
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0<snip>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0The domU will start booting
> =A0 =A0 =A0just
> =A0 =A0 =A0> =A0 =A0 =A0 =A0fine, but
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0after a
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0few
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0minutes the
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0VNC
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0screen goes black. After that
> =A0 =A0 =A0when
> =A0 =A0 =A0> =A0 =A0 =A0 =A0typing "xm
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0destroy
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0ts"= ; it
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0will
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0trigger
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0a kernel BUG:
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0BUG: unable to handle kernel
> =A0 =A0 =A0NULL
> =A0 =A0 =A0> =A0 =A0 =A0 =A0pointer
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0dereference
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0at
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A00000000000000030
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0IP: [<ffffffff810c50c4>]
> =A0 =A0 =A0> =A0 =A0 =A0 =A0iput+0x3e/0x195
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0PGD 0
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0Oops: 0000 [#1] SMP
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0CPU 6
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0Pid: 3571, comm: qemu-dm Not
> =A0 =A0 =A0tainted
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A03.5.0-dom0 #1
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0First of all upgrade to latest
> =A0 =A0 =A03.5.x Linux
> =A0 =A0 =A0> =A0 =A0 =A0 =A0kernel
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0release
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0.. so > =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0at least
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A03.5.4.
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0-- Pasi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0/DQ77MK
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0RIP: e030:[<ffffffff810c50c4>]=
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0 [<ffffffff810c50c4&= gt;]
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0iput+0x3e/0x195
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0RSP: e02b:ffff8800389ffbf8
> =A0 =A0 =A0 EFLAGS:
> =A0 =A0 =A0> =A0 =A0 =A0 =A000010246
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0RAX: 0000000000000001 RBX:
> =A0 =A0 =A0> =A0 =A0 =A0 =A0ffff8800377b0720
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0RCX:
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0ffff8800501c0000
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0RDX: ffff8800501c0000 RSI:
> =A0 =A0 =A0> =A0 =A0 =A0 =A0ffff8800377b0790
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0RDI:
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0ffff8800377b0790
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0RBP: 0000000000000000 R08:
> =A0 =A0 =A0> =A0 =A0 =A0 =A0ffffffff815cdd00
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0R09:
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A00000000000000016
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0R10: fefefefefefefeff R11:
> =A0 =A0 =A0> =A0 =A0 =A0 =A0ffff8800377b0400
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0R12:
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A000000001000a3e0c
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0R13: 0000000000000000 R14:
> =A0 =A0 =A0> =A0 =A0 =A0 =A000000001000a3e0c
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0R15:
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0ffff8800389ffc28
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0FS: =A000007f1af70a8700(0000)
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0GS:ffff880050180000(000= 0)
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0knlGS:0000000000000000
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0CS: =A0e033 DS: 0000 ES: 0000
> =A0 =A0 =A0CR0:
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0000000008005003b
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0CR2: 0000000000000030 CR3:
> =A0 =A0 =A0> =A0 =A0 =A0 =A0000000000156d000
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0CR4:
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A00000000000002660
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0DR0: 0000000000000000 DR1:
> =A0 =A0 =A0> =A0 =A0 =A0 =A00000000000000000
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0DR2:
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A00000000000000000
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0DR3: 0000000000000000 DR6:
> =A0 =A0 =A0> =A0 =A0 =A0 =A000000000ffff0ff0
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0DR7:
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A00000000000000400
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0Process qemu-dm (pid: 3571,
> =A0 =A0 =A0> =A0 =A0 =A0 =A0threadinfo
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0ffff880= 0389fe000,
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0task
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0ffff88003a721260)
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0Stack:
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 ffff88003a6d6400
> =A0 =A0 =A0ffff8800377b0000
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A000000001000a3e0c
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0ffffffff8133ce8f
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 ffff8800377b0400
> =A0 =A0 =A0ffffffff8134b6cd
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0ffff8800389ffc28
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0ffff8800389ffc28
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 ffff8800377b00f8
> =A0 =A0 =A0ffff8800377b0680
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0ffff880038cdcd60
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0ffff8800377b0000
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0Call Trace:
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 [<ffffffff8133ce8f>] ?
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0sk_release_kernel+0x23/= 0x39
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 [<ffffffff8134b6cd>] ?
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0netdev_run_todo+0x1e9/0= x206
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 [<ffffffff8129798f>] ?
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0tun_chr_close+0x4c/0x7b=
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 [<ffffffff810b39d3>] ?
> =A0 =A0 =A0> =A0 =A0 =A0 =A0fput+0xe4/0x1c5
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 [<ffffffff810b202c>] ?
> =A0 =A0 =A0> =A0 =A0 =A0 =A0filp_close+0x61/0x68
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 [<ffffffff81035e62>] ?
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0put_files_struct+0x62/0= xb9
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 [<ffffffff81036374>] ?
> =A0 =A0 =A0> =A0 =A0 =A0 =A0do_exit+0x24a/0x74c
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 [<ffffffff81036906>] ?
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0do_group_exit+0x6b/0x9d=
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 [<ffffffff8103ea0b>] ?
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0get_sig= nal_to_deliver+0x449/0x46e
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 [<ffffffff81009fa5>] ?
> =A0 =A0 =A0> =A0 =A0 =A0 =A0do_signal+0x28/0x4c4
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 [<ffffffff81027079>] ?
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0pvclock= _clocksource_read+0x48/0xbf
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 [<ffffffff8105b745>] ?
> =A0 =A0 =A0> =A0 =A0 =A0 =A0ktime_get_ts+0x66/0xa8
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 [<ffffffff810bfb18>] ?
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0poll_se= lect_copy_remaining+0xe0/0xf5
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 [<ffffffff8100a48d>] ?
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0do_notify_resume+0x3b/0= x74
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 [<ffffffff81411a70>] ?
> =A0 =A0 =A0> =A0 =A0 =A0 =A0int_signal+0x12/0x17
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0Code: 00 00 00 40 74 02 0f 0b
> =A0 =A0 =A048 8d
> =A0 =A0 =A0> =A0 =A0 =A0 =A077 70 48
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A08d bf 08
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A001 00 > =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A000 e8
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A08b 71 10
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A000 85 c0 0f 84 5d 01 00 00 48
> =A0 =A0 =A08b 6b
> =A0 =A0 =A0> =A0 =A0 =A0 =A018 f6 83
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A080 00 00
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A000 08 > =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0<4c> 8b
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A065 30
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A074 11 be 68 05 00 00 48 c7 c7
> =A0 =A0 =A08e df
> =A0 =A0 =A0> =A0 =A0 =A0 =A04f 81 e8
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0bb d0
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0RIP =A0[<ffffffff810c50c4>] > =A0 =A0 =A0> =A0 =A0 =A0 =A0iput+0x3e/0x195
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 RSP <ffff8800389ffbf8>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0CR2: 0000000000000030
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0---[ end trace
> =A0 =A0 =A067cc1654658fedcc ]---
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0Fixing recursive fault but
> =A0 =A0 =A0reboot is
> =A0 =A0 =A0> =A0 =A0 =A0 =A0needed!
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0I also tested Xen 4.2.0 and
> =A0 =A0 =A0problem
> =A0 =A0 =A0> =A0 =A0 =A0 =A0is the
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0same. So
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0is this=
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0a Xen
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0bug or a
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0kernel bug? I am running
> =A0 =A0 =A0vanilla
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 = =A0 =A0[1][2][3][4][5][11][17]kernel.org kernel
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A03.5.0 and
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0my
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0hardware is Intel Core i7-3770
> =A0 =A0 =A0CPU
> =A0 =A0 =A0> =A0 =A0 =A0 =A0and Intel
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0DQ77MK
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0motherboard
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0with
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0latest bios.
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0Best regards,
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0Valtteri Kiviniemi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> References
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0Visible links
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A01.
> =A0 =A0 =A0[3][4][5][6][12][18]http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0_______________________________________= ________
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0> Xen-devel mailing list
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0[4][5][6][7][13][19]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0[5][6][7][8][14][20]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> References
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A0Visible links
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A01.
> =A0 =A0 =A0mailto:[7][8][9][15][21]pas= ik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A02.
> =A0 =A0 =A0[8][9][10][16][22]http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A03.
> =A0 =A0 =A0[9][10][11][17][23]http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A04.
> =A0 =A0 =A0> =A0 =A0 =A0 =A0mailto:[10][11][12][18][24]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0 =A0> =A0 =A05.
> =A0 =A0 =A0> =A0 =A0 =A0 =A0[11][12][13][19][25]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> > =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> Re= ferences
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> > =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A0Visible links
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A01. mailto:[13][14][20][26]pasik@iki.= fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A02. mailto:[14][15][21][27]pasik@iki.= fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A03. [15][16][22][28]= http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A04. [16][17][23][29]= http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A05.
> =A0 =A0 =A0mailto:[17][18][24][30]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A06.
> =A0 =A0 =A0[18][19][25][31]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A07. mailto:[19][20][26][32]pasik@iki.= fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A08. [20][21][27][33]= http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 =A09. [21][22][28][34]= http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 10.
> =A0 =A0 =A0mailto:[22][23][29][35]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0 =A0> = =A0 11.
> =A0 =A0 =A0[23][24][30][36]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> References
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A0Visible lin= ks
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A01. mailto:[= 25][31][37]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A02. mailto:[= 26][32][38]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A03. mailto:[= 27][33][39]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A04. [28][34]= [40]http://kernel.org/=
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A05. [29][35]= [41]http://kernel.org/=
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A06. mailto:[= 30][36][42]Xen-devel@lists.xen.o= rg
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A07. [31][37]= [43]http://lis= ts.xen.org/xen-devel
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A08. mailto:[= 32][38][44]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 =A09. [33][39]= [45]http://kernel.org/=
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 10. [34][40][4= 6]http://kernel.org/ > =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 11. mailto:[35= ][41][47]Xen-devel@lists.xen.org=
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 12. [36][42][4= 8]http://lists= .xen.org/xen-devel
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 13. mailto:[37= ][43][49]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 14. mailto:[38= ][44][50]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 15. [39][45][5= 1]http://kernel.org/ > =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 16. [40][46][5= 2]http://kernel.org/ > =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 17. mailto:[41= ][47][53]Xen-devel@lists.xen.org=
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 18. [42][48][5= 4]http://lists= .xen.org/xen-devel
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 19. mailto:[43= ][49][55]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 20. [44][50][5= 6]http://kernel.org/ > =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 21. [45][51][5= 7]http://kernel.org/ > =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 22. mailto:[46= ][52][58]Xen-devel@lists.xen.org=
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0 =A0> =A0 23. [47][53][5= 9]http://lists= .xen.org/xen-devel
> =A0 =A0 =A0> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> References
> =A0 =A0 =A0> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A0Visible links
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A01. mailto:[54][60]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A02. mailto:[55][61]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A03. mailto:[56][62]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A04. mailto:[57][63]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A05. [58][64]http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A06. [59][65]http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A07. mailto:[60][66]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A08. [61][67]http://lists.xen.org/xen-devel=
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 =A09. mailto:[62][68]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 10. [63][69]http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 11. [64][70]http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 12. mailto:[65][71]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 13. [66][72]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 14. mailto:[67][73]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 15. mailto:[68][74]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 16. [69][75]http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 17. [70][76]http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 18. mailto:[71][77]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 19. [72][78]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 20. mailto:[73][79]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 21. [74][80]http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 22. [75][81]http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 23. mailto:[76][82]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 24. [77][83]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 25. mailto:[78][84]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 26. mailto:[79][85]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 27. mailto:[80][86]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 28. [81][87]http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 29. [82][88]http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 30. mailto:[83][89]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 31. [84][90]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 32. mailto:[85][91]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 33. [86][92]http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 34. [87][93]http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 35. mailto:[88][94]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 36. [89][95]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 37. mailto:[90][96]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 38. mailto:[91][97]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 39. [92][98]http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 40. [93][99]http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 41. mailto:[94][100]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 42. [95][101]http://lists.xen.org/xen-devel<= /a>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 43. mailto:[96][102]pasik@iki.fi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 44. [97][103]http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 45. [98][104]http://kernel.org/
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 46. mailto:[99][105]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> =A0 47. [100][106]http://lists.xen.org/xen-devel=
> =A0 =A0 =A0>
> =A0 =A0 =A0> References
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0Visible links
> =A0 =A0 =A0> =A0 =A01. mailto:[107]kiviniemi.valtteri@gmail.com
> =A0 =A0 =A0> =A0 =A02. [108]http://ark.intel.com/products/65719/
> =A0 =A0 =A0> =A0 =A03.
> =A0 =A0 =A0[109]= http://www.intel.com/content/www/us/en/motherboards/desktop-motherboards/de= sktop-board-dq77mk.html
> =A0 =A0 =A0> =A0 =A04. mailto:[110]root@dataproof.fi
> =A0 =A0 =A0> =A0 =A05. mailto:[111]= pasik@iki.fi
> =A0 =A0 =A0> =A0 =A06. [112]http://xen.org/
> =A0 =A0 =A0> =A0 =A07. mailto:[113]= pasik@iki.fi
> =A0 =A0 =A0> =A0 =A08. mailto:[114]= pasik@iki.fi
> =A0 =A0 =A0> =A0 =A09. mailto:[115]= pasik@iki.fi
> =A0 =A0 =A0> =A0 10. mailto:[116]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 11. [117]http://kernel.org/
> =A0 =A0 =A0> =A0 12. [118]http://kernel.org/
> =A0 =A0 =A0> =A0 13. mailto:[119]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 14. [120]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 15. mailto:[121]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 16. [122]http://kernel.org/
> =A0 =A0 =A0> =A0 17. [123]http://kernel.org/
> =A0 =A0 =A0> =A0 18. mailto:[124]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 19. [125]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 20. mailto:[126]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 21. mailto:[127]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 22. [128]http://kernel.org/
> =A0 =A0 =A0> =A0 23. [129]http://kernel.org/
> =A0 =A0 =A0> =A0 24. mailto:[130]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 25. [131]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 26. mailto:[132]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 27. [133]http://kernel.org/
> =A0 =A0 =A0> =A0 28. [134]http://kernel.org/
> =A0 =A0 =A0> =A0 29. mailto:[135]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 30. [136]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 31. mailto:[137]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 32. mailto:[138]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 33. mailto:[139]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 34. [140]http://kernel.org/
> =A0 =A0 =A0> =A0 35. [141]http://kernel.org/
> =A0 =A0 =A0> =A0 36. mailto:[142]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 37. [143]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 38. mailto:[144]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 39. [145]http://kernel.org/
> =A0 =A0 =A0> =A0 40. [146]http://kernel.org/
> =A0 =A0 =A0> =A0 41. mailto:[147]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 42. [148]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 43. mailto:[149]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 44. mailto:[150]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 45. [151]http://kernel.org/
> =A0 =A0 =A0> =A0 46. [152]http://kernel.org/
> =A0 =A0 =A0> =A0 47. mailto:[153]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 48. [154]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 49. mailto:[155]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 50. [156]http://kernel.org/
> =A0 =A0 =A0> =A0 51. [157]http://kernel.org/
> =A0 =A0 =A0> =A0 52. mailto:[158]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 53. [159]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 54. mailto:[160]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 55. mailto:[161]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 56. mailto:[162]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 57. mailto:[163]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 58. [164]http://kernel.org/
> =A0 =A0 =A0> =A0 59. [165]http://kernel.org/
> =A0 =A0 =A0> =A0 60. mailto:[166]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 61. [167]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 62. mailto:[168]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 63. [169]http://kernel.org/
> =A0 =A0 =A0> =A0 64. [170]http://kernel.org/
> =A0 =A0 =A0> =A0 65. mailto:[171]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 66. [172]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 67. mailto:[173]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 68. mailto:[174]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 69. [175]http://kernel.org/
> =A0 =A0 =A0> =A0 70. [176]http://kernel.org/
> =A0 =A0 =A0> =A0 71. mailto:[177]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 72. [178]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 73. mailto:[179]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 74. [180]http://kernel.org/
> =A0 =A0 =A0> =A0 75. [181]http://kernel.org/
> =A0 =A0 =A0> =A0 76. mailto:[182]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 77. [183]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 78. mailto:[184]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 79. mailto:[185]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 80. mailto:[186]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 81. [187]http://kernel.org/
> =A0 =A0 =A0> =A0 82. [188]http://kernel.org/
> =A0 =A0 =A0> =A0 83. mailto:[189]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 84. [190]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 85. mailto:[191]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 86. [192]http://kernel.org/
> =A0 =A0 =A0> =A0 87. [193]http://kernel.org/
> =A0 =A0 =A0> =A0 88. mailto:[194]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 89. [195]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 90. mailto:[196]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 91. mailto:[197]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 92. [198]http://kernel.org/
> =A0 =A0 =A0> =A0 93. [199]http://kernel.org/
> =A0 =A0 =A0> =A0 94. mailto:[200]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0 95. [201]http://lists.xen.org/xen-devel
> =A0 =A0 =A0> =A0 96. mailto:[202]pa= sik@iki.fi
> =A0 =A0 =A0> =A0 97. [203]http://kernel.org/
> =A0 =A0 =A0> =A0 98. [204]http://kernel.org/
> =A0 =A0 =A0> =A0 99. mailto:[205]Xen-devel@lists.xen.org
> =A0 =A0 =A0> =A0100. [206]http://lists.xen.org/xen-devel
>
> References
>
> =A0 =A0Visible links
> =A0 =A01. http:= //nago.fi/dmesg.txt
> =A0 =A02. htt= p://nago.fi/qemu-dm.txt
> =A0 =A03. ht= tp://nago.fi/xm-dmesg.txt
> =A0 =A04. http://nago.fi/domu-config.txt
> =A0 =A05. http://nago.fi/dom0-config.txt
> =A0 =A06. mailto:pasik@iki.fi
> =A0 =A07. mailto:kivin= iemi.valtteri@gmail.com
> =A0 =A08. http://ark.intel.com/products/65719/
> =A0 =A09. http:/= /www.intel.com/content/www/us/en/motherboards/desktop-motherboards/desktop-= board-dq77mk.html
> =A0 10. mailto:root@dataproof.fi<= /a>
> =A0 11. mailto:pasik@iki.fi
> =A0 12. http://xen.org/<= /a>
> =A0 13. mailto:pasik@iki.fi
> =A0 14. mailto:pasik= @iki.fi
> =A0 15. mailto:pasik@iki.fi
> =A0 16. mailto:pasik@iki.fi<= br> > =A0 17. http://kernel= .org/
> =A0 18. http://kernel= .org/
> =A0 19. mailto:Xen-devel@li= sts.xen.org
> =A0 20. h= ttp://lists.xen.org/xen-devel
> =A0 21. mailto:pasik= @iki.fi
> =A0 22. http://kernel= .org/
> =A0 23. http://kernel= .org/
> =A0 24. mailto:Xen-devel@li= sts.xen.org
> =A0 25. h= ttp://lists.xen.org/xen-devel
> =A0 26. mailto:pasik@iki.fi
> =A0 27. mailto:pasik@iki.fi
> =A0 28. http://kernel= .org/
> =A0 29. http://kernel= .org/
> =A0 30. mailto:Xen-devel@li= sts.xen.org
> =A0 31. h= ttp://lists.xen.org/xen-devel
> =A0 32. mailto:pasik@iki.fi
> =A0 33. http://kernel= .org/
> =A0 34. http://kernel= .org/
> =A0 35. mailto:Xen-devel@li= sts.xen.org
> =A0 36. h= ttp://lists.xen.org/xen-devel
> =A0 37. mailto:pasik@iki.fi
> =A0 38. mailto:pasik@iki.fi
> =A0 39. mailto:pasik@iki.fi<= br> > =A0 40. http://kernel= .org/
> =A0 41. http://kernel= .org/
> =A0 42. mailto:Xen-devel@li= sts.xen.org
> =A0 43. h= ttp://lists.xen.org/xen-devel
> =A0 44. mailto:pasik= @iki.fi
> =A0 45. http://kernel= .org/
> =A0 46. http://kernel= .org/
> =A0 47. mailto:Xen-devel@li= sts.xen.org
> =A0 48. h= ttp://lists.xen.org/xen-devel
> =A0 49. mailto:pasik@iki.fi
> =A0 50. mailto:pasik@iki.fi<= br> > =A0 51. http://kernel= .org/
> =A0 52. http://kernel= .org/
> =A0 53. mailto:Xen-devel@li= sts.xen.org
> =A0 54. h= ttp://lists.xen.org/xen-devel
> =A0 55. mailto:pasik@iki.fi
> =A0 56. http://kernel= .org/
> =A0 57. http://kernel= .org/
> =A0 58. mailto:Xen-devel@li= sts.xen.org
> =A0 59. h= ttp://lists.xen.org/xen-devel
> =A0 60. mailto:pasik@iki.fi
> =A0 61. mailto:pasik@iki.fi
> =A0 62. mailto:pasik@iki.fi
> =A0 63. mailto:pasik@iki.fi
> =A0 64. http://kernel= .org/
> =A0 65. http://kernel= .org/
> =A0 66. mailto:Xen-devel@li= sts.xen.org
> =A0 67. h= ttp://lists.xen.org/xen-devel
> =A0 68. mailto:pasik= @iki.fi
> =A0 69. http://kernel= .org/
> =A0 70. http://kernel= .org/
> =A0 71. mailto:Xen-devel@li= sts.xen.org
> =A0 72. h= ttp://lists.xen.org/xen-devel
> =A0 73. mailto:pasik@iki.fi
> =A0 74. mailto:pasik@iki.fi<= br> > =A0 75. http://kernel= .org/
> =A0 76. http://kernel= .org/
> =A0 77. mailto:Xen-devel@li= sts.xen.org
> =A0 78. h= ttp://lists.xen.org/xen-devel
> =A0 79. mailto:pasik@iki.fi
> =A0 80. http://kernel= .org/
> =A0 81. http://kernel= .org/
> =A0 82. mailto:Xen-devel@li= sts.xen.org
> =A0 83. h= ttp://lists.xen.org/xen-devel
> =A0 84. mailto:pasik@iki.fi
> =A0 85. mailto:pasik@iki.fi
> =A0 86. mailto:pasik@iki.fi
> =A0 87. http://kernel= .org/
> =A0 88. http://kernel= .org/
> =A0 89. mailto:Xen-devel@li= sts.xen.org
> =A0 90. h= ttp://lists.xen.org/xen-devel
> =A0 91. mailto:pasik= @iki.fi
> =A0 92. http://kernel= .org/
> =A0 93. http://kernel= .org/
> =A0 94. mailto:Xen-devel@li= sts.xen.org
> =A0 95. h= ttp://lists.xen.org/xen-devel
> =A0 96. mailto:pasik@iki.fi
> =A0 97. mailto:pasik@iki.fi<= br> > =A0 98. http://kernel= .org/
> =A0 99. http://kernel= .org/
> =A0100. mailto:Xen-devel@li= sts.xen.org
> =A0101. h= ttp://lists.xen.org/xen-devel
> =A0102. mailto:pasik@iki.fi
> =A0103. http://kernel= .org/
> =A0104. http://kernel= .org/
> =A0105. mailto:Xen-devel@li= sts.xen.org
> =A0106. h= ttp://lists.xen.org/xen-devel
> =A0107. mailto:kivinie= mi.valtteri@gmail.com
> =A0108. http://ark.intel.com/products/65719/
> =A0109. http://w= ww.intel.com/content/www/us/en/motherboards/desktop-motherboards/desktop-bo= ard-dq77mk.html
> =A0110. mailto:root@dataproof.fi<= /a>
> =A0111. mailto:pasik@iki.fi
> =A0112. http://xen.org/<= /a>
> =A0113. mailto:pasik@iki.fi
> =A0114. mailto:pasik@iki.fi
> =A0115. mailto:pasik@iki.fi
> =A0116. mailto:pasik@iki.fi
> =A0117. http://kernel= .org/
> =A0118. http://kernel= .org/
> =A0119. mailto:Xen-devel@li= sts.xen.org
> =A0120. h= ttp://lists.xen.org/xen-devel
> =A0121. mailto:pasik@iki.fi
> =A0122. http://kernel= .org/
> =A0123. http://kernel= .org/
> =A0124. mailto:Xen-devel@li= sts.xen.org
> =A0125. h= ttp://lists.xen.org/xen-devel
> =A0126. mailto:pasik@iki.fi
> =A0127. mailto:pasik@iki.fi
> =A0128. http://kernel= .org/
> =A0129. http://kernel= .org/
> =A0130. mailto:Xen-devel@li= sts.xen.org
> =A0131. h= ttp://lists.xen.org/xen-devel
> =A0132. mailto:pasik@iki.fi
> =A0133. http://kernel= .org/
> =A0134. http://kernel= .org/
> =A0135. mailto:Xen-devel@li= sts.xen.org
> =A0136. h= ttp://lists.xen.org/xen-devel
> =A0137. mailto:pasik@iki.fi
> =A0138. mailto:pasik@iki.fi
> =A0139. mailto:pasik@iki.fi
> =A0140. http://kernel= .org/
> =A0141. http://kernel= .org/
> =A0142. mailto:Xen-devel@li= sts.xen.org
> =A0143. h= ttp://lists.xen.org/xen-devel
> =A0144. mailto:pasik@iki.fi
> =A0145. http://kernel= .org/
> =A0146. http://kernel= .org/
> =A0147. mailto:Xen-devel@li= sts.xen.org
> =A0148. h= ttp://lists.xen.org/xen-devel
> =A0149. mailto:pasik@iki.fi
> =A0150. mailto:pasik@iki.fi
> =A0151. http://kernel= .org/
> =A0152. http://kernel= .org/
> =A0153. mailto:Xen-devel@li= sts.xen.org
> =A0154. h= ttp://lists.xen.org/xen-devel
> =A0155. mailto:pasik@iki.fi
> =A0156. http://kernel= .org/
> =A0157. http://kernel= .org/
> =A0158. mailto:Xen-devel@li= sts.xen.org
> =A0159. h= ttp://lists.xen.org/xen-devel
> =A0160. mailto:pasik@iki.fi
> =A0161. mailto:pasik@iki.fi
> =A0162. mailto:pasik@iki.fi
> =A0163. mailto:pasik@iki.fi
> =A0164. http://kernel= .org/
> =A0165. http://kernel= .org/
> =A0166. mailto:Xen-devel@li= sts.xen.org
> =A0167. h= ttp://lists.xen.org/xen-devel
> =A0168. mailto:pasik@iki.fi
> =A0169. http://kernel= .org/
> =A0170. http://kernel= .org/
> =A0171. mailto:Xen-devel@li= sts.xen.org
> =A0172. h= ttp://lists.xen.org/xen-devel
> =A0173. mailto:pasik@iki.fi
> =A0174. mailto:pasik@iki.fi
> =A0175. http://kernel= .org/
> =A0176. http://kernel= .org/
> =A0177. mailto:Xen-devel@li= sts.xen.org
> =A0178. h= ttp://lists.xen.org/xen-devel
> =A0179. mailto:pasik@iki.fi
> =A0180. http://kernel= .org/
> =A0181. http://kernel= .org/
> =A0182. mailto:Xen-devel@li= sts.xen.org
> =A0183. h= ttp://lists.xen.org/xen-devel
> =A0184. mailto:pasik@iki.fi
> =A0185. mailto:pasik@iki.fi
> =A0186. mailto:pasik@iki.fi
> =A0187. http://kernel= .org/
> =A0188. http://kernel= .org/
> =A0189. mailto:Xen-devel@li= sts.xen.org
> =A0190. h= ttp://lists.xen.org/xen-devel
> =A0191. mailto:pasik@iki.fi
> =A0192. http://kernel= .org/
> =A0193. http://kernel= .org/
> =A0194. mailto:Xen-devel@li= sts.xen.org
> =A0195. h= ttp://lists.xen.org/xen-devel
> =A0196. mailto:pasik@iki.fi
> =A0197. mailto:pasik@iki.fi
> =A0198. http://kernel= .org/
> =A0199. http://kernel= .org/
> =A0200. mailto:Xen-devel@li= sts.xen.org
> =A0201. h= ttp://lists.xen.org/xen-devel
> =A0202. mailto:pasik@iki.fi
> =A0203. http://kernel= .org/
> =A0204. http://kernel= .org/
> =A0205. mailto:Xen-devel@li= sts.xen.org
> =A0206. h= ttp://lists.xen.org/xen-devel

--20cf30563c0d436e7b04cb13c0b5-- --===============5962986339054632322== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============5962986339054632322==-- From xen-devel-bounces@lists.xen.org Tue Oct 02 13:53:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 13:53:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ2uI-0003We-LU; Tue, 02 Oct 2012 13:53:06 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ2uH-0003WZ-Li for xen-devel@lists.xen.org; Tue, 02 Oct 2012 13:53:05 +0000 Received: from [85.158.143.99:64582] by server-3.bemta-4.messagelabs.com id 53/5D-10986-0C1FA605; Tue, 02 Oct 2012 13:53:04 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1349185984!31654233!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19939 invoked from network); 2 Oct 2012 13:53:04 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 13:53:04 -0000 X-IronPort-AV: E=Sophos;i="4.80,523,1344211200"; d="scan'208";a="14894589" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 13:53:03 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 14:53:03 +0100 Message-ID: <1349185981.650.63.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Matthew Fioravante Date: Tue, 2 Oct 2012 14:53:01 +0100 In-Reply-To: <1349122340-13436-1-git-send-email-matthew.fioravante@jhuapl.edu> References: <1349122340-13436-1-git-send-email-matthew.fioravante@jhuapl.edu> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] Matthew Fioravante now maintains VTPM X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, 2012-10-01 at 21:12 +0100, Matthew Fioravante wrote: > See MAINTAINERS file > > Signed-off-by: Matthew Fioravante Thanks. This file is actually alphabetical so this entry is out of place. I think (but I'm not sure) that directory entries are supposed to have a trailing / -- this is most likely for the benefit of Linux-style get-maintainer.pl tools but judging from the existing entries we seem to be following it. > --- > Changes since last > * Change spaces to tabs, as thats what everything else uses. > > diff --git a/MAINTAINERS b/MAINTAINERS > index 094fe9e..1b73c4f 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -261,6 +261,21 @@ S: Supported > F: tools/xentrace/ > F: xen/common/trace.c > > +VTPM > +M: Matthew Fioravante > +S: Supported > +F: tools/vtpm > +F: tools/vtpm_manager > +F: extras/minios-os/tpmfront.c > +F: extras/minios-os/tpmback.c > +F: extras/minios-os/tpm-tis.c > +F: extras/minios-os/include/tpmfront.h > +F: extras/minios-os/include/tpmback.h > +F: extras/minios-os/include/tpm-tis.h > +F: stubdom/vtpm > +F: stubdom/vtpmmgr > +F: docs/misc/vtpm.txt > + > THE REST > M: Keir Fraser > L: xen-devel@lists.xen.org _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 13:53:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 13:53:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ2uI-0003We-LU; Tue, 02 Oct 2012 13:53:06 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ2uH-0003WZ-Li for xen-devel@lists.xen.org; Tue, 02 Oct 2012 13:53:05 +0000 Received: from [85.158.143.99:64582] by server-3.bemta-4.messagelabs.com id 53/5D-10986-0C1FA605; Tue, 02 Oct 2012 13:53:04 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1349185984!31654233!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19939 invoked from network); 2 Oct 2012 13:53:04 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 13:53:04 -0000 X-IronPort-AV: E=Sophos;i="4.80,523,1344211200"; d="scan'208";a="14894589" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 13:53:03 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 14:53:03 +0100 Message-ID: <1349185981.650.63.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Matthew Fioravante Date: Tue, 2 Oct 2012 14:53:01 +0100 In-Reply-To: <1349122340-13436-1-git-send-email-matthew.fioravante@jhuapl.edu> References: <1349122340-13436-1-git-send-email-matthew.fioravante@jhuapl.edu> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] Matthew Fioravante now maintains VTPM X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, 2012-10-01 at 21:12 +0100, Matthew Fioravante wrote: > See MAINTAINERS file > > Signed-off-by: Matthew Fioravante Thanks. This file is actually alphabetical so this entry is out of place. I think (but I'm not sure) that directory entries are supposed to have a trailing / -- this is most likely for the benefit of Linux-style get-maintainer.pl tools but judging from the existing entries we seem to be following it. > --- > Changes since last > * Change spaces to tabs, as thats what everything else uses. > > diff --git a/MAINTAINERS b/MAINTAINERS > index 094fe9e..1b73c4f 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -261,6 +261,21 @@ S: Supported > F: tools/xentrace/ > F: xen/common/trace.c > > +VTPM > +M: Matthew Fioravante > +S: Supported > +F: tools/vtpm > +F: tools/vtpm_manager > +F: extras/minios-os/tpmfront.c > +F: extras/minios-os/tpmback.c > +F: extras/minios-os/tpm-tis.c > +F: extras/minios-os/include/tpmfront.h > +F: extras/minios-os/include/tpmback.h > +F: extras/minios-os/include/tpm-tis.h > +F: stubdom/vtpm > +F: stubdom/vtpmmgr > +F: docs/misc/vtpm.txt > + > THE REST > M: Keir Fraser > L: xen-devel@lists.xen.org _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 13:54:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 13:54:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ2vk-0003bs-86; Tue, 02 Oct 2012 13:54:36 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ2vi-0003bi-6n for Xen-devel@lists.xen.org; Tue, 02 Oct 2012 13:54:34 +0000 Received: from [85.158.138.51:45063] by server-11.bemta-3.messagelabs.com id 85/8F-21460-912FA605; Tue, 02 Oct 2012 13:54:33 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-12.tower-174.messagelabs.com!1349186071!24878674!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MjMzMTI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28469 invoked from network); 2 Oct 2012 13:54:32 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 13:54:32 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id 9325A25C6; Tue, 2 Oct 2012 16:54:31 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 725F420058; Tue, 2 Oct 2012 16:54:31 +0300 (EEST) Date: Tue, 2 Oct 2012 16:54:31 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Valtteri Kiviniemi Message-ID: <20121002135431.GN8912@reaktio.net> References: <20121001164757.GF8912@reaktio.net> <20121001182437.GG8912@reaktio.net> <20121002121932.GL8912@reaktio.net> <20121002131407.GM8912@reaktio.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.0.4, kernel 3.5.0 HVM crash and kernel BUG X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, Oct 02, 2012 at 04:46:37PM +0300, Valtteri Kiviniemi wrote: > Hi, > = > I have not enabled debug on Xen or dom0 kernel. Could you tell me the > parameters for Xen coompilation needed to enable debugging? And If you > would also happen to know what are the options needed to enable kernel > debugging in menuconfig? Well I can probably manage to get the kernel > debugging enabled myself, but if you happen to know them please share = so > maybe I can get everything enabled at the first try :) > I didn't mean compilation options, just the xen/kernel cmdline options, please use these: xen.gz loglvl=3Dall guest_loglvl=3Dall sync_console lapic=3Ddebug apic_verb= osity=3Ddebug apic=3Ddebug iommu=3Doff vmlinuz console=3Dhvc0 earlyprintk=3Dxen nomodeset initcall_debug debug log= level=3D10 Plus your serial console settings for xen.gz, of course. -- Pasi = > Thanks! > = > - Valtteri > = > 2012/10/2 Pasi K=E4rkk=E4inen <[1]pasik@iki.fi> > = > On Tue, Oct 02, 2012 at 04:01:04PM +0300, Valtteri Kiviniemi wrote: > > Hi, > > > > I already tried 3.2, 3.5, 3.5.0, 3.6.0-rc7 and 3.6.0, same prob= lem > all of > > those. My dom0 config is the same config that I'am using on oth= er > server > > where HVM is working, so I dont think that it is a config probl= em. > I have > > triple checked everything and all should be ok. dom0 dmesg shows > the same > > crash that I have previously posted here. /var/log/xen/ does not > contain > > any specific errors. > > > > Could this be some kind of broblem with my motherboard bios bei= ng > buggy or > > CPU not supported? I'm using the new intel Ivy Bridge processor > which has > > integrated GPU, but that should not probably cause these kind of > problems. > > Or maybe some ACPI problem? xm dmesg is showing some notices ab= out > ACPI. > > Is there any ACPI kernel parameters that I should try booting? = This > has to > > be somekind of problem with my hardware, or then maybe it could= be > a > > kernel problem too. I just really cant figure this out myself, I > have > > tried everything. > > > = > Hmm.. I have some distant memories of seeing a patch that fixes a bug > on recent Ivy Bridge systems, but I can't find a link right now. > Maybe you're affected by that.. > = > Also: Did you already post the crash log, with all the debug/verbose > options enabled for both Xen and dom0 kernel? > = > -- Pasi > > Lets take a quick summary of what has been tested, what hardware > I'm using > > etc. > > > > Xen-versions tested: 4.2.0, 4.0.4 > > Kernel-versions tested: 3.2.0, 3.5.0, 3.5.4, 3.6.0-rc7, 3.6.0 > > > > Host OS: Debian testing/wheezy, udev version 175-7, 2.13-35, py= thon > > version 2.7.3~rc2-2.1 > > > > Hardware: > > > > CPU: Intel Core i7-3770 3.4GHz > > MB: Intel DQ77MK (latest bios updated) > > Memory: 32GB (4 x 8GB DDR3-1600MHz) > > > > All relevant log files and configs: > > > > dom0 dmesg: [1][2]http://nago.fi/dmesg.txt > > qemu-dm log: [2][3]http://nago.fi/qemu-dm.txt > > xm dmesg log: [3][4]http://nago.fi/xm-dmesg.txt > > domU config: [4][5]http://nago.fi/domu-config.txt > > dom0 kernel config: [5][6]http://nago.fi/dom0-config.txt > > > > I have also tried playing with every setting on that domU that I > can think > > of and tried different configs etc. > > > > - Valtteri > > > > 2012/10/2 Pasi K=E4rkk=E4inen <[6][7]pasik@iki.fi> > > > > On Tue, Oct 02, 2012 at 03:11:07PM +0300, Valtteri Kiviniemi > wrote: > > > Hi, > > > > > > Another update: > > > > > > I wanted to check that if a Linux HVM would boot with > working VNC > > console, > > > so I tried to launch a Debian Squeeze installer on HVM. = It > refused > > to > > > start ant told me that vbd hotplug scripts were not work= ing. > After > > that > > > failure even the Windows domU would not anymore start wh= ich > was > > previously > > > starting ok. > > > > > > The hotplug scripts also starts hanging on the processes. > > > > > > root 9401 0.1 0.1 17700 1640 ? S 15:05 > 0:00 > > /bin/bash > > > /etc/xen/scripts/xen-hotplug-cleanup > > > root 9441 0.1 0.1 17700 1644 ? S 15:05 > 0:00 > > /bin/bash > > > /etc/xen/scripts/xen-hotplug-cleanup > > > root 9481 0.1 0.1 17700 1640 ? S 15:05 > 0:00 > > /bin/bash > > > /etc/xen/scripts/xen-hotplug-cleanup > > > root 9560 0.1 0.1 17700 1640 ? S 15:05 > 0:00 > > /bin/bash > > > /etc/xen/scripts/xen-hotplug-cleanup > > > root 10738 0.1 0.1 17696 1636 ? S 15:05 > 0:00 > > /bin/bash > > > /etc/xen/scripts/xen-hotplug-cleanup > > > root 10747 0.1 0.1 17792 1736 ? S 15:05 > 0:00 > > /bin/bash > > > /etc/xen/scripts/block remove > > > root 11286 0.0 0.0 4080 324 ? S 15:06 > 0:00 > > sleep 1 > > > root 11290 0.0 0.0 4080 324 ? S 15:06 > 0:00 > > sleep 1 > > > root 11294 0.0 0.0 4080 324 ? S 15:06 > 0:00 > > sleep 1 > > > root 11298 0.0 0.0 4080 324 ? S 15:06 > 0:00 > > sleep 1 > > > root 11302 0.0 0.0 4080 320 ? S 15:06 > 0:00 > > sleep 1 > > > root 11306 0.0 0.0 4080 320 ? S 15:06 > 0:00 > > sleep 1 > > > > > > Then I did a xm destroy and I had again the kernel BUG on > dmesg. So > > it > > > seems that the problem is not fixed by using 3.6.0. Udev > version is > > 175-7. > > > > > > > So you have definitely something broken in your system, > > probably in your dom0 kernel. Try with Linux 3.5.4 or 3.4.x, > > and see how that goes. > > > > Any errors in dom0 dmesg? How about in /var/log/xen/* ? > > > > -- Pasi > > > > > > > > > > > 2012/10/1 Valtteri Kiviniemi > <[1][7][8]kiviniemi.valtteri@gmail.com> > > > > > > Hi, > > > > > > CPU: Intel Core i7-3770 3.4GHz > > > [2][8][9]http://ark.intel.com/products/65719/ > > > > > > MB: Intel DQ77MK (latest bios updated) > > > > > > [3][9][10]http://www.intel.com/content/www/us/en/motherboards/deskto= p-motherboards/desktop-board-dq77mk.html > > > > > > Memory: 32GB (4 x 8GB DDR3-1600MHz) > > > > > > Host is Debian wheezy/testing, Xen 4.0.4 and latest 3.= 6.0 > kernel. > > > > > > Noticed also some errors in xm dmesg: > > > > > > root@xen-2:~# xm dmesg > > > > > > (XEN) Xen version 4.0.4 ([4][10][11]root@dataproof.fi) > (gcc version > > 4.7.1 > > > (Debian 4.7.1-7) ) Sun Sep 30 20:28:26 EEST 2012 > > > (XEN) Latest ChangeSet: unavailable > > > (XEN) Bootloader: GNU GRUB 0.97 > > > (XEN) Command line: dom0_mem=3D1280M cpufreq=3Dxen > clocksource=3Dhpet > > > (XEN) Video information: > > > (XEN) VGA is text mode 80x25, font 8x16 > > > (XEN) VBE/DDC methods: none; EDID transfer time: 0 > seconds > > > (XEN) EDID info not retrieved because no DDC retrieval > method > > detected > > > (XEN) Disc information: > > > (XEN) Found 4 MBR signatures > > > (XEN) Found 4 EDD information structures > > > (XEN) Xen-e820 RAM map: > > > (XEN) 0000000000000000 - 000000000009d800 (usable) > > > (XEN) 000000000009d800 - 00000000000a0000 (reserved) > > > (XEN) 00000000000e0000 - 0000000000100000 (reserved) > > > (XEN) 0000000000100000 - 0000000020000000 (usable) > > > (XEN) 0000000020000000 - 0000000020200000 (reserved) > > > (XEN) 0000000020200000 - 0000000040004000 (usable) > > > (XEN) 0000000040004000 - 0000000040005000 (reserved) > > > (XEN) 0000000040005000 - 00000000dbe44000 (usable) > > > (XEN) 00000000dbe44000 - 00000000dc2d7000 (reserved) > > > (XEN) 00000000dc2d7000 - 00000000dc2e7000 (ACPI data) > > > (XEN) 00000000dc2e7000 - 00000000dc40c000 (ACPI NVS) > > > (XEN) 00000000dc40c000 - 00000000dc6af000 (reserved) > > > (XEN) 00000000dc6af000 - 00000000dc6b0000 (usable) > > > (XEN) 00000000dc6b0000 - 00000000dc6f3000 (ACPI NVS) > > > (XEN) 00000000dc6f3000 - 00000000dd000000 (usable) > > > (XEN) 00000000dd800000 - 00000000dfa00000 (reserved) > > > (XEN) 00000000f8000000 - 00000000fc000000 (reserved) > > > (XEN) 00000000fec00000 - 00000000fec01000 (reserved) > > > (XEN) 00000000fed00000 - 00000000fed04000 (reserved) > > > (XEN) 00000000fed1c000 - 00000000fed20000 (reserved) > > > (XEN) 00000000fee00000 - 00000000fee01000 (reserved) > > > (XEN) 00000000ff000000 - 0000000100000000 (reserved) > > > (XEN) 0000000100000000 - 000000081e600000 (usable) > > > (XEN) ACPI: RSDP 000F0490, 0024 (r2 INTEL) > > > (XEN) ACPI: XSDT DC2DB080, 007C (r1 INTEL DQ77MK > 32 AMI > > > 10013) > > > (XEN) ACPI: FACP DC2E51F0, 010C (r5 INTEL DQ77MK > 32 AMI > > > 10013) > > > (XEN) ACPI Warning (tbfadt-0232): FADT (revision 5) is > longer > > than ACPI > > > 2.0 version, truncating length 0x10C to 0xF4 [20070126] > > > (XEN) ACPI: DSDT DC2DB188, A061 (r2 INTEL DQ77MK > 32 INTL > > > 20051117) > > > (XEN) ACPI: FACS DC40A080, 0040 > > > (XEN) ACPI: APIC DC2E5300, 0092 (r3 INTEL DQ77MK > 32 AMI > > > 10013) > > > (XEN) ACPI: FPDT DC2E5398, 0044 (r1 INTEL DQ77MK > 32 AMI > > > 10013) > > > (XEN) ACPI: TCPA DC2E53E0, 0032 (r2 INTEL DQ77MK > 32 MSFT > > > 1000013) > > > (XEN) ACPI: MCFG DC2E5418, 003C (r1 INTEL DQ77MK > 32 MSFT > > > 97) > > > (XEN) ACPI: HPET DC2E5458, 0038 (r1 INTEL DQ77MK > 32 AMI. > > > 5) > > > (XEN) ACPI: SSDT DC2E5490, 036D (r1 INTEL DQ77MK > 32 INTL > > > 20091112) > > > (XEN) ACPI: SSDT DC2E5800, 09AA (r1 INTEL DQ77MK > 32 INTL > > > 20051117) > > > (XEN) ACPI: SSDT DC2E61B0, 0A92 (r1 INTEL DQ77MK > 32 INTL > > > 20051117) > > > (XEN) ACPI: DMAR DC2E6C48, 00B8 (r1 INTEL DQ77MK > 32 INTL > > > 1) > > > (XEN) ACPI: ASF! DC2E6D00, 00A5 (r32 INTEL DQ77MK > 32 > > TFSM > > > F4240) > > > (XEN) System RAM: 32682MB (33467320kB) > > > (XEN) Domain heap initialised > > > (XEN) ACPI: 32/64X FACS address mismatch in FADT - > > > dc40a080/0000000000000000, using 32 > > > (XEN) Processor #0 7:10 APIC version 21 > > > (XEN) Processor #2 7:10 APIC version 21 > > > (XEN) Processor #4 7:10 APIC version 21 > > > (XEN) Processor #6 7:10 APIC version 21 > > > (XEN) Processor #1 7:10 APIC version 21 > > > (XEN) Processor #3 7:10 APIC version 21 > > > (XEN) Processor #5 7:10 APIC version 21 > > > (XEN) Processor #7 7:10 APIC version 21 > > > (XEN) IOAPIC[0]: apic_id 2, version 32, address > 0xfec00000, GSI > > 0-23 > > > (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs > > > (XEN) Switched to APIC driver x2apic_cluster. > > > (XEN) x2APIC mode enabled. > > > (XEN) Using scheduler: SMP Credit Scheduler (credit) > > > (XEN) Detected 3392.369 MHz processor. > > > (XEN) Initing memory sharing. > > > (XEN) VMX: Supported advanced features: > > > (XEN) - APIC MMIO access virtualisation > > > (XEN) - APIC TPR shadow > > > (XEN) - Extended Page Tables (EPT) > > > (XEN) - Virtual-Processor Identifiers (VPID) > > > (XEN) - Virtual NMI > > > (XEN) - MSR direct-access bitmap > > > (XEN) - Unrestricted Guest > > > (XEN) EPT supports 2MB super page. > > > (XEN) HVM: ASIDs enabled. > > > (XEN) HVM: VMX enabled > > > (XEN) HVM: Hardware Assisted Paging detected. > > > (XEN) Intel VT-d Snoop Control not enabled. > > > (XEN) Intel VT-d Dom0 DMA Passthrough not enabled. > > > (XEN) Intel VT-d Queued Invalidation enabled. > > > (XEN) Intel VT-d Interrupt Remapping enabled. > > > (XEN) I/O virtualisation enabled > > > (XEN) - Dom0 mode: Relaxed > > > (XEN) Enabled directed EOI with ioapic_ack_old on! > > > (XEN) Total of 8 processors activated. > > > (XEN) ENABLING IO-APIC IRQs > > > (XEN) -> Using old ACK method > > > (XEN) TSC is reliable, synchronization unnecessary > > > (XEN) Platform timer appears to have unexpectedly wrap= ped > 1 > > times. > > > (XEN) Platform timer is 14.318MHz HPET > > > (XEN) Allocated console ring of 16 KiB. > > > (XEN) Brought up 8 CPUs > > > (XEN) *** LOADING DOMAIN 0 *** > > > (XEN) Xen kernel: 64-bit, lsb, compat32 > > > (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 = -> > > 0x1ae7000 > > > (XEN) PHYSICAL MEMORY ARRANGEMENT: > > > (XEN) Dom0 alloc.: 0000000804000000->00000008060000= 00 > (319488 > > pages > > > to be allocated) > > > (XEN) VIRTUAL MEMORY ARRANGEMENT: > > > (XEN) Loaded kernel: ffffffff81000000->ffffffff81ae70= 00 > > > (XEN) Init. ramdisk: ffffffff81ae7000->ffffffff81ae70= 00 > > > (XEN) Phys-Mach map: ffffffff81ae7000->ffffffff81d670= 00 > > > (XEN) Start info: ffffffff81d67000->ffffffff81d674= b4 > > > (XEN) Page tables: ffffffff81d68000->ffffffff81d7b0= 00 > > > (XEN) Boot stack: ffffffff81d7b000->ffffffff81d7c0= 00 > > > (XEN) TOTAL: ffffffff80000000->ffffffff820000= 00 > > > (XEN) ENTRY ADDRESS: ffffffff815e3210 > > > (XEN) Dom0 has maximum 8 VCPUs > > > (XEN) [VT-D]iommu.c:718: BIOS did not enable IGD for VT > properly. > > > Disabling IGD VT-d engine. > > > (XEN) Scrubbing Free RAM: done. > > > (XEN) Xen trace buffers: disabled > > > (XEN) Std. Loglevel: Errors and warnings > > > (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and > warnings) > > > (XEN) Xen is relinquishing VGA console. > > > (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three ti= mes > to > > switch > > > input to Xen) > > > (XEN) Freed 172kB init memory. > > > (XEN) traps.c:2333:d0 Domain attempted WRMSR > 000000000000008b > > from > > > 00000012:00000000 to 00000000:00000000. > > > > > > - Valtteri > > > > > > 2012/10/1 Pasi K=E4rkk=E4inen <[5][11][12]pasik@iki.fi> > > > > > > On Mon, Oct 01, 2012 at 09:12:50PM +0300, Valtteri > Kiviniemi > > wrote: > > > > Hi, > > > > > > > > Lowering memory or vcpu's does not help, proble= m is > the > > same. I > > > originally > > > > installed Xen 4.2.0 and the problem was same on > that too. > > Then I > > > > downgraded back to 4.0.4 since I thought that t= his > might > > be a bug > > > on > > > > 4.2.0. I have been previously running Windows > Server 2008 > > R2 > > > succesfully > > > > on Xen 4.0.x on different hardware with this sa= me > config. > > > Hypervisor is > > > > 64bit and windows is 64bit. > > > > > > > > Any ideas what to try next? > > > > > > > > > > What kind of hardware is that? > > > > > > [6][12][13]xen.org automated testing regularly tests > Windows VMs, > > and it works > > > OK there. > > > > > > -- Pasi > > > > Ps. qemu-dm.log is the following: > > > > > > > > domid: 10 > > > > config qemu network with xen bridge for tap10.0 > xenbr0 > > > > Using file /dev/virtuals/ts in read-write mode > > > > Using file > /media/iso/windows_server_2008_r2_sp1.iso in > > read-only > > > mode > > > > Watching > /local/domain/0/device-model/10/logdirty/cmd > > > > Watching /local/domain/0/device-model/10/command > > > > qemu_map_cache_init nr_buckets =3D 10000 size 4= 194304 > > > > shared page at pfn feffd > > > > buffered io page at pfn feffb > > > > Guest uuid =3D 52f19e23-2955-c27d-a22c-60c5d8c6= 0d5a > > > > Time offset set 0 > > > > populating video RAM at ff000000 > > > > mapping video RAM from ff000000 > > > > Register xen platform. > > > > Done register platform. > > > > platform_fixed_ioport: changed ro/rw state of R= OM > memory > > area. > > > now is rw > > > > state. > > > > > > > xs_read(/local/domain/0/device-model/10/xen_extended_power_mgmt): > > > read > > > > error > > > > medium change watch on `hdc' (index: 1): > > > > /media/iso/windows_server_2008_r2_sp1.iso > > > > I/O request not ready: 0, ptr: 0, port: 0, data= : 0, > count: > > 0, > > > size: 0 > > > > Log-dirty: no command yet. > > > > xs_read(/local/domain/10/log-throttling): read > error > > > > qemu: ignoring not-understood drive > > > `/local/domain/10/log-throttling' > > > > medium change watch on > `/local/domain/10/log-throttling' - > > > unknown device, > > > > ignored > > > > cirrus vga map change while on lfb mode > > > > mapping vram to f0000000 - f0400000 > > > > platform_fixed_ioport: changed ro/rw state of R= OM > memory > > area. > > > now is rw > > > > state. > > > > platform_fixed_ioport: changed ro/rw state of R= OM > memory > > area. > > > now is ro > > > > state. > > > > > > > > 2012/10/1 Pasi K=E4rkk=E4inen > <[1][7][13][14]pasik@iki.fi> > > > > > > > > On Mon, Oct 01, 2012 at 07:23:44PM +0300, > Valtteri > > Kiviniemi > > > wrote: > > > > > Hi, > > > > > > > > > > I have tried other config files, but the > problem is > > the > > > same. At > > > > the > > > > > moment I'm using a config file from anot= her > server > > where I > > > have a > > > > working > > > > > Windows Server 2008 R2 installation, so I > dont > > think that > > > there is > > > > > anything wrong with my config: > > > > > > > > > > > > > Did you try with less vcpus, for example 2 ? > > > > how about with less memory, say 2 GB ? > > > > > > > > Did you try with later Xen versions? Is that a > 32bit > > Xen, or > > > 64bit Xen > > > > hypervisor? > > > > > > > > -- Pasi > > > > > kernel =3D "/usr/lib/xen/boot/hvmloader" > > > > > builder =3D "hvm" > > > > > shadow_memory =3D "8" > > > > > memory =3D "4096" > > > > > name =3D "ts" > > > > > vcpus =3D "8" > > > > > cpus =3D ["0", "1", "2", "3", "4", "5", = "6", > "7"] > > > > > pae =3D "1" > > > > > acpi =3D "1" > > > > > apic =3D "1" > > > > > vfb =3D [ 'type=3Dvnc, vnclisten=3D10.10= 0.100.50, > > vncpasswd=3Dxxx' > > > ] > > > > > xen_extended_power_mgmt =3D "0" > > > > > vif =3D [ "type=3Dioemu, mac=3D00:16:3e:= d7:d7:5d, > > bridge=3Dxenbr0" > > > ] > > > > > disk =3D [ "phy:/dev/virtuals/ts,hda,w", > > > > > > > > > "file:/media/iso/windows_server_2008_r2_sp1.iso,hdc:cdrom,r" ] > > > > > on_poweroff =3D "destroy" > > > > > on_reboot =3D "restart" > > > > > on_crash =3D "restart" > > > > > viridian =3D "1" > > > > > device_model =3D "/usr/lib/xen/bin/qemu-= dm" > > > > > boot =3D "dc" > > > > > snapshot =3D "0" > > > > > vncconsole =3D "1" > > > > > sdl =3D "0" > > > > > opengl =3D "0" > > > > > vnc =3D "1" > > > > > nographic =3D "0" > > > > > stdvga =3D "0" > > > > > tsc_mode =3D "1" > > > > > monitor =3D "0" > > > > > localtime =3D "1" > > > > > usb =3D "0" > > > > > keymap =3D "fi" > > > > > xen_platform_pci =3D "1" > > > > > pci_msitranslate =3D "1" > > > > > pci_power_mgmt =3D "0" > > > > > > > > > > 2012/10/1 Pasi K=E4rkk=E4inen > > <[1][2][8][14][15]pasik@iki.fi> > > > > > > > > > > On Mon, Oct 01, 2012 at 06:46:08PM +03= 00, > > Valtteri > > > Kiviniemi > > > > wrote: > > > > > > Hi, > > > > > > > > > > > > Yes, I have viridian=3D1 on my do= mU > config. > > > > > > > > > > > > > > > > Try with some known good domU configfi= le. > > > > > > > > > > -- Pasi > > > > > > 2012/10/1 Pasi K=E4rkk=E4inen > > > <[1][2][3][9][15][16]pasik@iki.fi> > > > > > > > > > > > > On Mon, Oct 01, 2012 at 05:06:5= 3PM > +0300, > > > Valtteri > > > > Kiviniemi > > > > > wrote: > > > > > > > Hi, > > > > > > > > > > > > > > I'm now using 3.6.0 and ca= n't > > reproduce that > > > crash > > > > anymore, > > > > > so it > > > > > > seems > > > > > > > that it was a kernel bug. > > > > > > > > > > > > > > > > > > > OK. > > > > > > > However I'm still getting > black > > screen on > > > VNC > > > > > > > when trying to install Win= dows > Server > > 2008 > > > R2. I can > > > > see the > > > > > > "windows is > > > > > > > loading files" screen but > after the > > > installer starts > > > > the VNC > > > > > > display goes > > > > > > > black. > > > > > > > > > > > > > > Any ideas? > > > > > > > > > > > > > > > > > > > Do you have viridian=3D1 specif= ied > for the > > windows > > > vm? > > > > > > > > > > > > -- Pasi > > > > > > > > > > > > > - Valtteri > > > > > > > > > > > > > > 2012/10/1 Pasi K=E4rkk=E4i= nen > > > <[1][2][3][4][10][16][17]pasik@iki.fi> > > > > > > > > > > > > > > On Sun, Sep 30, 2012 at > 11:18:03PM > > +0300, > > > Valtteri > > > > > Kiviniemi > > > > > > wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > I'm trying to get > Windows > > Server 2008 > > > R2 > > > > installation > > > > > > booting on > > > > > > > Xen > > > > > > > > 4.0.4. Using the > following > > config: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The domU will start > booting > > just > > > fine, but > > > > after a > > > > > few > > > > > > minutes the > > > > > > > VNC > > > > > > > > screen goes black. > After that > > when > > > typing "xm > > > > destroy > > > > > ts" it > > > > > > will > > > > > > > trigger > > > > > > > > a kernel BUG: > > > > > > > > > > > > > > > > BUG: unable to hand= le > kernel > > NULL > > > pointer > > > > dereference > > > > > at > > > > > > > 0000000000000030 > > > > > > > > IP: > [] > > > iput+0x3e/0x195 > > > > > > > > PGD 0 > > > > > > > > Oops: 0000 [#1] SMP > > > > > > > > CPU 6 > > > > > > > > Pid: 3571, comm: > qemu-dm Not > > tainted > > > > 3.5.0-dom0 #1 > > > > > > > > > > > > > > First of all upgrade to > latest > > 3.5.x Linux > > > kernel > > > > release > > > > > .. so > > > > > > at least > > > > > > > 3.5.4. > > > > > > > > > > > > > > -- Pasi > > > > > > > > > > > > > > > /DQ77MK > > > > > > > > RIP: > e030:[] > > > > [] > > > > > > > iput+0x3e/0x195 > > > > > > > > RSP: > e02b:ffff8800389ffbf8 > > EFLAGS: > > > 00010246 > > > > > > > > RAX: 00000000000000= 01 > RBX: > > > ffff8800377b0720 > > > > RCX: > > > > > > ffff8800501c0000 > > > > > > > > RDX: ffff8800501c00= 00 > RSI: > > > ffff8800377b0790 > > > > RDI: > > > > > > ffff8800377b0790 > > > > > > > > RBP: 00000000000000= 00 > R08: > > > ffffffff815cdd00 > > > > R09: > > > > > > 0000000000000016 > > > > > > > > R10: fefefefefefefe= ff > R11: > > > ffff8800377b0400 > > > > R12: > > > > > > 00000001000a3e0c > > > > > > > > R13: 00000000000000= 00 > R14: > > > 00000001000a3e0c > > > > R15: > > > > > > ffff8800389ffc28 > > > > > > > > FS: > 00007f1af70a8700(0000) > > > > GS:ffff880050180000(0000) > > > > > > > > knlGS:0000000000000= 000 > > > > > > > > CS: e033 DS: 0000 = ES: > 0000 > > CR0: > > > > 000000008005003b > > > > > > > > CR2: 00000000000000= 30 > CR3: > > > 000000000156d000 > > > > CR4: > > > > > > 0000000000002660 > > > > > > > > DR0: 00000000000000= 00 > DR1: > > > 0000000000000000 > > > > DR2: > > > > > > 0000000000000000 > > > > > > > > DR3: 00000000000000= 00 > DR6: > > > 00000000ffff0ff0 > > > > DR7: > > > > > > 0000000000000400 > > > > > > > > Process qemu-dm (pi= d: > 3571, > > > threadinfo > > > > > ffff8800389fe000, > > > > > > task > > > > > > > > ffff88003a721260) > > > > > > > > Stack: > > > > > > > > ffff88003a6d6400 > > ffff8800377b0000 > > > > 00000001000a3e0c > > > > > > > ffffffff8133ce8f > > > > > > > > ffff8800377b0400 > > ffffffff8134b6cd > > > > ffff8800389ffc28 > > > > > > > ffff8800389ffc28 > > > > > > > > ffff8800377b00f8 > > ffff8800377b0680 > > > > ffff880038cdcd60 > > > > > > > ffff8800377b0000 > > > > > > > > Call Trace: > > > > > > > > [] ? > > > > sk_release_kernel+0x23/0x39 > > > > > > > > [] ? > > > > netdev_run_todo+0x1e9/0x206 > > > > > > > > [] ? > > > > tun_chr_close+0x4c/0x7b > > > > > > > > [] ? > > > fput+0xe4/0x1c5 > > > > > > > > [] ? > > > filp_close+0x61/0x68 > > > > > > > > [] ? > > > > put_files_struct+0x62/0xb9 > > > > > > > > [] ? > > > do_exit+0x24a/0x74c > > > > > > > > [] ? > > > > do_group_exit+0x6b/0x9d > > > > > > > > [] ? > > > > > get_signal_to_deliver+0x449/0x46e > > > > > > > > [] ? > > > do_signal+0x28/0x4c4 > > > > > > > > [] ? > > > > > pvclock_clocksource_read+0x48/0xbf > > > > > > > > [] ? > > > ktime_get_ts+0x66/0xa8 > > > > > > > > [] ? > > > > > poll_select_copy_remaining+0xe0/0xf5 > > > > > > > > [] ? > > > > do_notify_resume+0x3b/0x74 > > > > > > > > [] ? > > > int_signal+0x12/0x17 > > > > > > > > Code: 00 00 00 40 7= 4 02 > 0f 0b > > 48 8d > > > 77 70 48 > > > > 8d bf 08 > > > > > 01 00 > > > > > > 00 e8 > > > > > > > 8b 71 10 > > > > > > > > 00 85 c0 0f 84 5d 0= 1 00 > 00 48 > > 8b 6b > > > 18 f6 83 > > > > 80 00 00 > > > > > 00 08 > > > > > > <4c> 8b > > > > > > > 65 30 > > > > > > > > 74 11 be 68 05 00 0= 0 48 > c7 c7 > > 8e df > > > 4f 81 e8 > > > > bb d0 > > > > > > > > RIP > [] > > > iput+0x3e/0x195 > > > > > > > > RSP > > > > > > > > CR2: 00000000000000= 30 > > > > > > > > ---[ end trace > > 67cc1654658fedcc ]--- > > > > > > > > Fixing recursive fa= ult > but > > reboot is > > > needed! > > > > > > > > > > > > > > > > I also tested Xen 4= .2.0 > and > > problem > > > is the > > > > same. So > > > > > is this > > > > > > a Xen > > > > > > > bug or a > > > > > > > > kernel bug? I am > running > > vanilla > > > > > [1][2][3][4][5][11][17][18]kernel.org > kernel > > > > > > 3.5.0 and > > > > > > > my > > > > > > > > hardware is Intel C= ore > i7-3770 > > CPU > > > and Intel > > > > DQ77MK > > > > > > motherboard > > > > > > > with > > > > > > > > latest bios. > > > > > > > > > > > > > > > > Best regards, > > > > > > > > Valtteri Kiviniemi > > > > > > > > > > > > > > > > References > > > > > > > > > > > > > > > > Visible links > > > > > > > > 1. > > [3][4][5][6][12][18][19]http://kernel.org/ > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Xen-devel mailing list > > > > > > > > > > [4][5][6][7][13][19][20]Xen-devel@lists.xen.org > > > > > > > > > > > [5][6][7][8][14][20][21]http://lists.xen.org/xen-dev= el > > > > > > > > > > > > > > References > > > > > > > > > > > > > > Visible links > > > > > > > 1. > > mailto:[7][8][9][15][21][22]pasik@iki.fi > > > > > > > 2. > > [8][9][10][16][22][23]http://kernel.org/ > > > > > > > 3. > > [9][10][11][17][23][24]http://kernel.org/ > > > > > > > 4. > > > mailto:[10][11][12][18][24][25]Xen-devel@lists.xen.o= rg > > > > > > > 5. > > > [11][12][13][19][25][26]http://lists.xen.org/xen-dev= el > > > > > > > > > > > > References > > > > > > > > > > > > Visible links > > > > > > 1. > mailto:[13][14][20][26][27]pasik@iki.fi > > > > > > 2. > mailto:[14][15][21][27][28]pasik@iki.fi > > > > > > 3. > [15][16][22][28][29]http://kernel.org/ > > > > > > 4. > [16][17][23][29][30]http://kernel.org/ > > > > > > 5. > > mailto:[17][18][24][30][31]Xen-devel@lists.xen.org > > > > > > 6. > > [18][19][25][31][32]http://lists.xen.org/xen-devel > > > > > > 7. > mailto:[19][20][26][32][33]pasik@iki.fi > > > > > > 8. > [20][21][27][33][34]http://kernel.org/ > > > > > > 9. > [21][22][28][34][35]http://kernel.org/ > > > > > > 10. > > mailto:[22][23][29][35][36]Xen-devel@lists.xen.org > > > > > > 11. > > [23][24][30][36][37]http://lists.xen.org/xen-devel > > > > > > > > > > References > > > > > > > > > > Visible links > > > > > 1. mailto:[25][31][37][38]pasik@iki.fi > > > > > 2. mailto:[26][32][38][39]pasik@iki.fi > > > > > 3. mailto:[27][33][39][40]pasik@iki.fi > > > > > 4. [28][34][40][41]http://kernel.org/ > > > > > 5. [29][35][41][42]http://kernel.org/ > > > > > 6. > mailto:[30][36][42][43]Xen-devel@lists.xen.org > > > > > 7. > [31][37][43][44]http://lists.xen.org/xen-devel > > > > > 8. mailto:[32][38][44][45]pasik@iki.fi > > > > > 9. [33][39][45][46]http://kernel.org/ > > > > > 10. [34][40][46][47]http://kernel.org/ > > > > > 11. > mailto:[35][41][47][48]Xen-devel@lists.xen.org > > > > > 12. > [36][42][48][49]http://lists.xen.org/xen-devel > > > > > 13. mailto:[37][43][49][50]pasik@iki.fi > > > > > 14. mailto:[38][44][50][51]pasik@iki.fi > > > > > 15. [39][45][51][52]http://kernel.org/ > > > > > 16. [40][46][52][53]http://kernel.org/ > > > > > 17. > mailto:[41][47][53][54]Xen-devel@lists.xen.org > > > > > 18. > [42][48][54][55]http://lists.xen.org/xen-devel > > > > > 19. mailto:[43][49][55][56]pasik@iki.fi > > > > > 20. [44][50][56][57]http://kernel.org/ > > > > > 21. [45][51][57][58]http://kernel.org/ > > > > > 22. > mailto:[46][52][58][59]Xen-devel@lists.xen.org > > > > > 23. > [47][53][59][60]http://lists.xen.org/xen-devel > > > > > > > > References > > > > > > > > Visible links > > > > 1. mailto:[54][60][61]pasik@iki.fi > > > > 2. mailto:[55][61][62]pasik@iki.fi > > > > 3. mailto:[56][62][63]pasik@iki.fi > > > > 4. mailto:[57][63][64]pasik@iki.fi > > > > 5. [58][64][65]http://kernel.org/ > > > > 6. [59][65][66]http://kernel.org/ > > > > 7. mailto:[60][66][67]Xen-devel@lists.xen.org > > > > 8. [61][67][68]http://lists.xen.org/xen-devel > > > > 9. mailto:[62][68][69]pasik@iki.fi > > > > 10. [63][69][70]http://kernel.org/ > > > > 11. [64][70][71]http://kernel.org/ > > > > 12. mailto:[65][71][72]Xen-devel@lists.xen.org > > > > 13. [66][72][73]http://lists.xen.org/xen-devel > > > > 14. mailto:[67][73][74]pasik@iki.fi > > > > 15. mailto:[68][74][75]pasik@iki.fi > > > > 16. [69][75][76]http://kernel.org/ > > > > 17. [70][76][77]http://kernel.org/ > > > > 18. mailto:[71][77][78]Xen-devel@lists.xen.org > > > > 19. [72][78][79]http://lists.xen.org/xen-devel > > > > 20. mailto:[73][79][80]pasik@iki.fi > > > > 21. [74][80][81]http://kernel.org/ > > > > 22. [75][81][82]http://kernel.org/ > > > > 23. mailto:[76][82][83]Xen-devel@lists.xen.org > > > > 24. [77][83][84]http://lists.xen.org/xen-devel > > > > 25. mailto:[78][84][85]pasik@iki.fi > > > > 26. mailto:[79][85][86]pasik@iki.fi > > > > 27. mailto:[80][86][87]pasik@iki.fi > > > > 28. [81][87][88]http://kernel.org/ > > > > 29. [82][88][89]http://kernel.org/ > > > > 30. mailto:[83][89][90]Xen-devel@lists.xen.org > > > > 31. [84][90][91]http://lists.xen.org/xen-devel > > > > 32. mailto:[85][91][92]pasik@iki.fi > > > > 33. [86][92][93]http://kernel.org/ > > > > 34. [87][93][94]http://kernel.org/ > > > > 35. mailto:[88][94][95]Xen-devel@lists.xen.org > > > > 36. [89][95][96]http://lists.xen.org/xen-devel > > > > 37. mailto:[90][96][97]pasik@iki.fi > > > > 38. mailto:[91][97][98]pasik@iki.fi > > > > 39. [92][98][99]http://kernel.org/ > > > > 40. [93][99][100]http://kernel.org/ > > > > 41. mailto:[94][100][101]Xen-devel@lists.xen.org > > > > 42. [95][101][102]http://lists.xen.org/xen-devel > > > > 43. mailto:[96][102][103]pasik@iki.fi > > > > 44. [97][103][104]http://kernel.org/ > > > > 45. [98][104][105]http://kernel.org/ > > > > 46. mailto:[99][105][106]Xen-devel@lists.xen.org > > > > 47. [100][106][107]http://lists.xen.org/xen-devel > > > > > > References > > > > > > Visible links > > > 1. mailto:[107][108]kiviniemi.valtteri@gmail.com > > > 2. [108][109]http://ark.intel.com/products/65719/ > > > 3. > > > [109][110]http://www.intel.com/content/www/us/en/motherboards/deskt= op-motherboards/desktop-board-dq77mk.html > > > 4. mailto:[110][111]root@dataproof.fi > > > 5. mailto:[111][112]pasik@iki.fi > > > 6. [112][113]http://xen.org/ > > > 7. mailto:[113][114]pasik@iki.fi > > > 8. mailto:[114][115]pasik@iki.fi > > > 9. mailto:[115][116]pasik@iki.fi > > > 10. mailto:[116][117]pasik@iki.fi > > > 11. [117][118]http://kernel.org/ > > > 12. [118][119]http://kernel.org/ > > > 13. mailto:[119][120]Xen-devel@lists.xen.org > > > 14. [120][121]http://lists.xen.org/xen-devel > > > 15. mailto:[121][122]pasik@iki.fi > > > 16. [122][123]http://kernel.org/ > > > 17. [123][124]http://kernel.org/ > > > 18. mailto:[124][125]Xen-devel@lists.xen.org > > > 19. [125][126]http://lists.xen.org/xen-devel > > > 20. mailto:[126][127]pasik@iki.fi > > > 21. mailto:[127][128]pasik@iki.fi > > > 22. [128][129]http://kernel.org/ > > > 23. [129][130]http://kernel.org/ > > > 24. mailto:[130][131]Xen-devel@lists.xen.org > > > 25. [131][132]http://lists.xen.org/xen-devel > > > 26. mailto:[132][133]pasik@iki.fi > > > 27. [133][134]http://kernel.org/ > > > 28. [134][135]http://kernel.org/ > > > 29. mailto:[135][136]Xen-devel@lists.xen.org > > > 30. [136][137]http://lists.xen.org/xen-devel > > > 31. mailto:[137][138]pasik@iki.fi > > > 32. mailto:[138][139]pasik@iki.fi > > > 33. mailto:[139][140]pasik@iki.fi > > > 34. [140][141]http://kernel.org/ > > > 35. [141][142]http://kernel.org/ > > > 36. mailto:[142][143]Xen-devel@lists.xen.org > > > 37. [143][144]http://lists.xen.org/xen-devel > > > 38. mailto:[144][145]pasik@iki.fi > > > 39. [145][146]http://kernel.org/ > > > 40. [146][147]http://kernel.org/ > > > 41. mailto:[147][148]Xen-devel@lists.xen.org > > > 42. [148][149]http://lists.xen.org/xen-devel > > > 43. mailto:[149][150]pasik@iki.fi > > > 44. mailto:[150][151]pasik@iki.fi > > > 45. [151][152]http://kernel.org/ > > > 46. [152][153]http://kernel.org/ > > > 47. mailto:[153][154]Xen-devel@lists.xen.org > > > 48. [154][155]http://lists.xen.org/xen-devel > > > 49. mailto:[155][156]pasik@iki.fi > > > 50. [156][157]http://kernel.org/ > > > 51. [157][158]http://kernel.org/ > > > 52. mailto:[158][159]Xen-devel@lists.xen.org > > > 53. [159][160]http://lists.xen.org/xen-devel > > > 54. mailto:[160][161]pasik@iki.fi > > > 55. mailto:[161][162]pasik@iki.fi > > > 56. mailto:[162][163]pasik@iki.fi > > > 57. mailto:[163][164]pasik@iki.fi > > > 58. [164][165]http://kernel.org/ > > > 59. [165][166]http://kernel.org/ > > > 60. mailto:[166][167]Xen-devel@lists.xen.org > > > 61. [167][168]http://lists.xen.org/xen-devel > > > 62. mailto:[168][169]pasik@iki.fi > > > 63. [169][170]http://kernel.org/ > > > 64. [170][171]http://kernel.org/ > > > 65. mailto:[171][172]Xen-devel@lists.xen.org > > > 66. [172][173]http://lists.xen.org/xen-devel > > > 67. mailto:[173][174]pasik@iki.fi > > > 68. mailto:[174][175]pasik@iki.fi > > > 69. [175][176]http://kernel.org/ > > > 70. [176][177]http://kernel.org/ > > > 71. mailto:[177][178]Xen-devel@lists.xen.org > > > 72. [178][179]http://lists.xen.org/xen-devel > > > 73. mailto:[179][180]pasik@iki.fi > > > 74. [180][181]http://kernel.org/ > > > 75. [181][182]http://kernel.org/ > > > 76. mailto:[182][183]Xen-devel@lists.xen.org > > > 77. [183][184]http://lists.xen.org/xen-devel > > > 78. mailto:[184][185]pasik@iki.fi > > > 79. mailto:[185][186]pasik@iki.fi > > > 80. mailto:[186][187]pasik@iki.fi > > > 81. [187][188]http://kernel.org/ > > > 82. [188][189]http://kernel.org/ > > > 83. mailto:[189][190]Xen-devel@lists.xen.org > > > 84. [190][191]http://lists.xen.org/xen-devel > > > 85. mailto:[191][192]pasik@iki.fi > > > 86. [192][193]http://kernel.org/ > > > 87. [193][194]http://kernel.org/ > > > 88. mailto:[194][195]Xen-devel@lists.xen.org > > > 89. [195][196]http://lists.xen.org/xen-devel > > > 90. mailto:[196][197]pasik@iki.fi > > > 91. mailto:[197][198]pasik@iki.fi > > > 92. [198][199]http://kernel.org/ > > > 93. [199][200]http://kernel.org/ > > > 94. mailto:[200][201]Xen-devel@lists.xen.org > > > 95. [201][202]http://lists.xen.org/xen-devel > > > 96. mailto:[202][203]pasik@iki.fi > > > 97. [203][204]http://kernel.org/ > > > 98. [204][205]http://kernel.org/ > > > 99. mailto:[205][206]Xen-devel@lists.xen.org > > > 100. [206][207]http://lists.xen.org/xen-devel > > > > References > > > > Visible links > > 1. [208]http://nago.fi/dmesg.txt > > 2. [209]http://nago.fi/qemu-dm.txt > > 3. [210]http://nago.fi/xm-dmesg.txt > > 4. [211]http://nago.fi/domu-config.txt > > 5. [212]http://nago.fi/dom0-config.txt > > 6. mailto:[213]pasik@iki.fi > > 7. mailto:[214]kiviniemi.valtteri@gmail.com > > 8. [215]http://ark.intel.com/products/65719/ > > 9. > [216]http://www.intel.com/content/www/us/en/motherboards/desktop-mot= herboards/desktop-board-dq77mk.html > > 10. mailto:[217]root@dataproof.fi > > 11. mailto:[218]pasik@iki.fi > > 12. [219]http://xen.org/ > > 13. mailto:[220]pasik@iki.fi > > 14. mailto:[221]pasik@iki.fi > > 15. mailto:[222]pasik@iki.fi > > 16. mailto:[223]pasik@iki.fi > > 17. [224]http://kernel.org/ > > 18. [225]http://kernel.org/ > > 19. mailto:[226]Xen-devel@lists.xen.org > > 20. [227]http://lists.xen.org/xen-devel > > 21. mailto:[228]pasik@iki.fi > > 22. [229]http://kernel.org/ > > 23. [230]http://kernel.org/ > > 24. mailto:[231]Xen-devel@lists.xen.org > > 25. [232]http://lists.xen.org/xen-devel > > 26. mailto:[233]pasik@iki.fi > > 27. mailto:[234]pasik@iki.fi > > 28. [235]http://kernel.org/ > > 29. [236]http://kernel.org/ > > 30. mailto:[237]Xen-devel@lists.xen.org > > 31. [238]http://lists.xen.org/xen-devel > > 32. mailto:[239]pasik@iki.fi > > 33. [240]http://kernel.org/ > > 34. [241]http://kernel.org/ > > 35. mailto:[242]Xen-devel@lists.xen.org > > 36. [243]http://lists.xen.org/xen-devel > > 37. mailto:[244]pasik@iki.fi > > 38. mailto:[245]pasik@iki.fi > > 39. mailto:[246]pasik@iki.fi > > 40. [247]http://kernel.org/ > > 41. [248]http://kernel.org/ > > 42. mailto:[249]Xen-devel@lists.xen.org > > 43. [250]http://lists.xen.org/xen-devel > > 44. mailto:[251]pasik@iki.fi > > 45. [252]http://kernel.org/ > > 46. [253]http://kernel.org/ > > 47. mailto:[254]Xen-devel@lists.xen.org > > 48. [255]http://lists.xen.org/xen-devel > > 49. mailto:[256]pasik@iki.fi > > 50. mailto:[257]pasik@iki.fi > > 51. [258]http://kernel.org/ > > 52. [259]http://kernel.org/ > > 53. mailto:[260]Xen-devel@lists.xen.org > > 54. [261]http://lists.xen.org/xen-devel > > 55. mailto:[262]pasik@iki.fi > > 56. [263]http://kernel.org/ > > 57. [264]http://kernel.org/ > > 58. mailto:[265]Xen-devel@lists.xen.org > > 59. [266]http://lists.xen.org/xen-devel > > 60. mailto:[267]pasik@iki.fi > > 61. mailto:[268]pasik@iki.fi > > 62. mailto:[269]pasik@iki.fi > > 63. mailto:[270]pasik@iki.fi > > 64. [271]http://kernel.org/ > > 65. [272]http://kernel.org/ > > 66. mailto:[273]Xen-devel@lists.xen.org > > 67. [274]http://lists.xen.org/xen-devel > > 68. mailto:[275]pasik@iki.fi > > 69. [276]http://kernel.org/ > > 70. [277]http://kernel.org/ > > 71. mailto:[278]Xen-devel@lists.xen.org > > 72. [279]http://lists.xen.org/xen-devel > > 73. mailto:[280]pasik@iki.fi > > 74. mailto:[281]pasik@iki.fi > > 75. [282]http://kernel.org/ > > 76. [283]http://kernel.org/ > > 77. mailto:[284]Xen-devel@lists.xen.org > > 78. [285]http://lists.xen.org/xen-devel > > 79. mailto:[286]pasik@iki.fi > > 80. [287]http://kernel.org/ > > 81. [288]http://kernel.org/ > > 82. mailto:[289]Xen-devel@lists.xen.org > > 83. [290]http://lists.xen.org/xen-devel > > 84. mailto:[291]pasik@iki.fi > > 85. mailto:[292]pasik@iki.fi > > 86. mailto:[293]pasik@iki.fi > > 87. [294]http://kernel.org/ > > 88. [295]http://kernel.org/ > > 89. mailto:[296]Xen-devel@lists.xen.org > > 90. [297]http://lists.xen.org/xen-devel > > 91. mailto:[298]pasik@iki.fi > > 92. [299]http://kernel.org/ > > 93. [300]http://kernel.org/ > > 94. mailto:[301]Xen-devel@lists.xen.org > > 95. [302]http://lists.xen.org/xen-devel > > 96. mailto:[303]pasik@iki.fi > > 97. mailto:[304]pasik@iki.fi > > 98. [305]http://kernel.org/ > > 99. [306]http://kernel.org/ > > 100. mailto:[307]Xen-devel@lists.xen.org > > 101. [308]http://lists.xen.org/xen-devel > > 102. mailto:[309]pasik@iki.fi > > 103. [310]http://kernel.org/ > > 104. [311]http://kernel.org/ > > 105. mailto:[312]Xen-devel@lists.xen.org > > 106. [313]http://lists.xen.org/xen-devel > > 107. mailto:[314]kiviniemi.valtteri@gmail.com > > 108. [315]http://ark.intel.com/products/65719/ > > 109. > [316]http://www.intel.com/content/www/us/en/motherboards/desktop-mot= herboards/desktop-board-dq77mk.html > > 110. mailto:[317]root@dataproof.fi > > 111. mailto:[318]pasik@iki.fi > > 112. [319]http://xen.org/ > > 113. mailto:[320]pasik@iki.fi > > 114. mailto:[321]pasik@iki.fi > > 115. mailto:[322]pasik@iki.fi > > 116. mailto:[323]pasik@iki.fi > > 117. [324]http://kernel.org/ > > 118. [325]http://kernel.org/ > > 119. mailto:[326]Xen-devel@lists.xen.org > > 120. [327]http://lists.xen.org/xen-devel > > 121. mailto:[328]pasik@iki.fi > > 122. [329]http://kernel.org/ > > 123. [330]http://kernel.org/ > > 124. mailto:[331]Xen-devel@lists.xen.org > > 125. [332]http://lists.xen.org/xen-devel > > 126. mailto:[333]pasik@iki.fi > > 127. mailto:[334]pasik@iki.fi > > 128. [335]http://kernel.org/ > > 129. [336]http://kernel.org/ > > 130. mailto:[337]Xen-devel@lists.xen.org > > 131. [338]http://lists.xen.org/xen-devel > > 132. mailto:[339]pasik@iki.fi > > 133. [340]http://kernel.org/ > > 134. [341]http://kernel.org/ > > 135. mailto:[342]Xen-devel@lists.xen.org > > 136. [343]http://lists.xen.org/xen-devel > > 137. mailto:[344]pasik@iki.fi > > 138. mailto:[345]pasik@iki.fi > > 139. mailto:[346]pasik@iki.fi > > 140. [347]http://kernel.org/ > > 141. [348]http://kernel.org/ > > 142. mailto:[349]Xen-devel@lists.xen.org > > 143. [350]http://lists.xen.org/xen-devel > > 144. mailto:[351]pasik@iki.fi > > 145. [352]http://kernel.org/ > > 146. [353]http://kernel.org/ > > 147. mailto:[354]Xen-devel@lists.xen.org > > 148. [355]http://lists.xen.org/xen-devel > > 149. mailto:[356]pasik@iki.fi > > 150. mailto:[357]pasik@iki.fi > > 151. [358]http://kernel.org/ > > 152. [359]http://kernel.org/ > > 153. mailto:[360]Xen-devel@lists.xen.org > > 154. [361]http://lists.xen.org/xen-devel > > 155. mailto:[362]pasik@iki.fi > > 156. [363]http://kernel.org/ > > 157. [364]http://kernel.org/ > > 158. mailto:[365]Xen-devel@lists.xen.org > > 159. [366]http://lists.xen.org/xen-devel > > 160. mailto:[367]pasik@iki.fi > > 161. mailto:[368]pasik@iki.fi > > 162. mailto:[369]pasik@iki.fi > > 163. mailto:[370]pasik@iki.fi > > 164. [371]http://kernel.org/ > > 165. [372]http://kernel.org/ > > 166. mailto:[373]Xen-devel@lists.xen.org > > 167. [374]http://lists.xen.org/xen-devel > > 168. mailto:[375]pasik@iki.fi > > 169. [376]http://kernel.org/ > > 170. [377]http://kernel.org/ > > 171. mailto:[378]Xen-devel@lists.xen.org > > 172. [379]http://lists.xen.org/xen-devel > > 173. mailto:[380]pasik@iki.fi > > 174. mailto:[381]pasik@iki.fi > > 175. [382]http://kernel.org/ > > 176. [383]http://kernel.org/ > > 177. mailto:[384]Xen-devel@lists.xen.org > > 178. [385]http://lists.xen.org/xen-devel > > 179. mailto:[386]pasik@iki.fi > > 180. [387]http://kernel.org/ > > 181. [388]http://kernel.org/ > > 182. mailto:[389]Xen-devel@lists.xen.org > > 183. [390]http://lists.xen.org/xen-devel > > 184. mailto:[391]pasik@iki.fi > > 185. mailto:[392]pasik@iki.fi > > 186. mailto:[393]pasik@iki.fi > > 187. [394]http://kernel.org/ > > 188. [395]http://kernel.org/ > > 189. mailto:[396]Xen-devel@lists.xen.org > > 190. [397]http://lists.xen.org/xen-devel > > 191. mailto:[398]pasik@iki.fi > > 192. [399]http://kernel.org/ > > 193. [400]http://kernel.org/ > > 194. mailto:[401]Xen-devel@lists.xen.org > > 195. [402]http://lists.xen.org/xen-devel > > 196. mailto:[403]pasik@iki.fi > > 197. mailto:[404]pasik@iki.fi > > 198. [405]http://kernel.org/ > > 199. [406]http://kernel.org/ > > 200. mailto:[407]Xen-devel@lists.xen.org > > 201. [408]http://lists.xen.org/xen-devel > > 202. mailto:[409]pasik@iki.fi > > 203. [410]http://kernel.org/ > > 204. [411]http://kernel.org/ > > 205. mailto:[412]Xen-devel@lists.xen.org > > 206. [413]http://lists.xen.org/xen-devel > = > References > = > Visible links > 1. mailto:pasik@iki.fi > 2. http://nago.fi/dmesg.txt > 3. http://nago.fi/qemu-dm.txt > 4. http://nago.fi/xm-dmesg.txt > 5. http://nago.fi/domu-config.txt > 6. http://nago.fi/dom0-config.txt > 7. mailto:pasik@iki.fi > 8. mailto:kiviniemi.valtteri@gmail.com > 9. http://ark.intel.com/products/65719/ > 10. http://www.intel.com/content/www/us/en/motherboards/desktop-motherb= oards/desktop-board-dq77mk.html > 11. mailto:root@dataproof.fi > 12. mailto:pasik@iki.fi > 13. http://xen.org/ > 14. mailto:pasik@iki.fi > 15. mailto:pasik@iki.fi > 16. mailto:pasik@iki.fi > 17. mailto:pasik@iki.fi > 18. http://kernel.org/ > 19. http://kernel.org/ > 20. mailto:Xen-devel@lists.xen.org > 21. http://lists.xen.org/xen-devel > 22. mailto:pasik@iki.fi > 23. http://kernel.org/ > 24. http://kernel.org/ > 25. mailto:Xen-devel@lists.xen.org > 26. http://lists.xen.org/xen-devel > 27. mailto:pasik@iki.fi > 28. mailto:pasik@iki.fi > 29. http://kernel.org/ > 30. http://kernel.org/ > 31. mailto:Xen-devel@lists.xen.org > 32. http://lists.xen.org/xen-devel > 33. mailto:pasik@iki.fi > 34. http://kernel.org/ > 35. http://kernel.org/ > 36. mailto:Xen-devel@lists.xen.org > 37. http://lists.xen.org/xen-devel > 38. mailto:pasik@iki.fi > 39. mailto:pasik@iki.fi > 40. mailto:pasik@iki.fi > 41. http://kernel.org/ > 42. http://kernel.org/ > 43. mailto:Xen-devel@lists.xen.org > 44. http://lists.xen.org/xen-devel > 45. mailto:pasik@iki.fi > 46. http://kernel.org/ > 47. http://kernel.org/ > 48. mailto:Xen-devel@lists.xen.org > 49. http://lists.xen.org/xen-devel > 50. mailto:pasik@iki.fi > 51. mailto:pasik@iki.fi > 52. http://kernel.org/ > 53. http://kernel.org/ > 54. mailto:Xen-devel@lists.xen.org > 55. http://lists.xen.org/xen-devel > 56. mailto:pasik@iki.fi > 57. http://kernel.org/ > 58. http://kernel.org/ > 59. mailto:Xen-devel@lists.xen.org > 60. http://lists.xen.org/xen-devel > 61. mailto:pasik@iki.fi > 62. mailto:pasik@iki.fi > 63. mailto:pasik@iki.fi > 64. mailto:pasik@iki.fi > 65. http://kernel.org/ > 66. http://kernel.org/ > 67. mailto:Xen-devel@lists.xen.org > 68. http://lists.xen.org/xen-devel > 69. mailto:pasik@iki.fi > 70. http://kernel.org/ > 71. http://kernel.org/ > 72. mailto:Xen-devel@lists.xen.org > 73. http://lists.xen.org/xen-devel > 74. mailto:pasik@iki.fi > 75. mailto:pasik@iki.fi > 76. http://kernel.org/ > 77. http://kernel.org/ > 78. mailto:Xen-devel@lists.xen.org > 79. http://lists.xen.org/xen-devel > 80. mailto:pasik@iki.fi > 81. http://kernel.org/ > 82. http://kernel.org/ > 83. mailto:Xen-devel@lists.xen.org > 84. http://lists.xen.org/xen-devel > 85. mailto:pasik@iki.fi > 86. mailto:pasik@iki.fi > 87. mailto:pasik@iki.fi > 88. http://kernel.org/ > 89. http://kernel.org/ > 90. mailto:Xen-devel@lists.xen.org > 91. http://lists.xen.org/xen-devel > 92. mailto:pasik@iki.fi > 93. http://kernel.org/ > 94. http://kernel.org/ > 95. mailto:Xen-devel@lists.xen.org > 96. http://lists.xen.org/xen-devel > 97. mailto:pasik@iki.fi > 98. mailto:pasik@iki.fi > 99. http://kernel.org/ > 100. http://kernel.org/ > 101. mailto:Xen-devel@lists.xen.org > 102. http://lists.xen.org/xen-devel > 103. mailto:pasik@iki.fi > 104. http://kernel.org/ > 105. http://kernel.org/ > 106. mailto:Xen-devel@lists.xen.org > 107. http://lists.xen.org/xen-devel > 108. mailto:kiviniemi.valtteri@gmail.com > 109. http://ark.intel.com/products/65719/ > 110. http://www.intel.com/content/www/us/en/motherboards/desktop-motherb= oards/desktop-board-dq77mk.html > 111. mailto:root@dataproof.fi > 112. mailto:pasik@iki.fi > 113. http://xen.org/ > 114. mailto:pasik@iki.fi > 115. mailto:pasik@iki.fi > 116. mailto:pasik@iki.fi > 117. mailto:pasik@iki.fi > 118. http://kernel.org/ > 119. http://kernel.org/ > 120. mailto:Xen-devel@lists.xen.org > 121. http://lists.xen.org/xen-devel > 122. mailto:pasik@iki.fi > 123. http://kernel.org/ > 124. http://kernel.org/ > 125. mailto:Xen-devel@lists.xen.org > 126. http://lists.xen.org/xen-devel > 127. mailto:pasik@iki.fi > 128. mailto:pasik@iki.fi > 129. http://kernel.org/ > 130. http://kernel.org/ > 131. mailto:Xen-devel@lists.xen.org > 132. http://lists.xen.org/xen-devel > 133. mailto:pasik@iki.fi > 134. http://kernel.org/ > 135. http://kernel.org/ > 136. mailto:Xen-devel@lists.xen.org > 137. http://lists.xen.org/xen-devel > 138. mailto:pasik@iki.fi > 139. mailto:pasik@iki.fi > 140. mailto:pasik@iki.fi > 141. http://kernel.org/ > 142. http://kernel.org/ > 143. mailto:Xen-devel@lists.xen.org > 144. http://lists.xen.org/xen-devel > 145. mailto:pasik@iki.fi > 146. http://kernel.org/ > 147. http://kernel.org/ > 148. mailto:Xen-devel@lists.xen.org > 149. http://lists.xen.org/xen-devel > 150. mailto:pasik@iki.fi > 151. mailto:pasik@iki.fi > 152. http://kernel.org/ > 153. http://kernel.org/ > 154. mailto:Xen-devel@lists.xen.org > 155. http://lists.xen.org/xen-devel > 156. mailto:pasik@iki.fi > 157. http://kernel.org/ > 158. http://kernel.org/ > 159. mailto:Xen-devel@lists.xen.org > 160. http://lists.xen.org/xen-devel > 161. mailto:pasik@iki.fi > 162. mailto:pasik@iki.fi > 163. mailto:pasik@iki.fi > 164. mailto:pasik@iki.fi > 165. http://kernel.org/ > 166. http://kernel.org/ > 167. mailto:Xen-devel@lists.xen.org > 168. http://lists.xen.org/xen-devel > 169. mailto:pasik@iki.fi > 170. http://kernel.org/ > 171. http://kernel.org/ > 172. mailto:Xen-devel@lists.xen.org > 173. http://lists.xen.org/xen-devel > 174. mailto:pasik@iki.fi > 175. mailto:pasik@iki.fi > 176. http://kernel.org/ > 177. http://kernel.org/ > 178. mailto:Xen-devel@lists.xen.org > 179. http://lists.xen.org/xen-devel > 180. mailto:pasik@iki.fi > 181. http://kernel.org/ > 182. http://kernel.org/ > 183. mailto:Xen-devel@lists.xen.org > 184. http://lists.xen.org/xen-devel > 185. mailto:pasik@iki.fi > 186. mailto:pasik@iki.fi > 187. mailto:pasik@iki.fi > 188. http://kernel.org/ > 189. http://kernel.org/ > 190. mailto:Xen-devel@lists.xen.org > 191. http://lists.xen.org/xen-devel > 192. mailto:pasik@iki.fi > 193. http://kernel.org/ > 194. http://kernel.org/ > 195. mailto:Xen-devel@lists.xen.org > 196. http://lists.xen.org/xen-devel > 197. mailto:pasik@iki.fi > 198. mailto:pasik@iki.fi > 199. http://kernel.org/ > 200. http://kernel.org/ > 201. mailto:Xen-devel@lists.xen.org > 202. http://lists.xen.org/xen-devel > 203. mailto:pasik@iki.fi > 204. http://kernel.org/ > 205. http://kernel.org/ > 206. mailto:Xen-devel@lists.xen.org > 207. http://lists.xen.org/xen-devel > 208. http://nago.fi/dmesg.txt > 209. http://nago.fi/qemu-dm.txt > 210. http://nago.fi/xm-dmesg.txt > 211. http://nago.fi/domu-config.txt > 212. http://nago.fi/dom0-config.txt > 213. mailto:pasik@iki.fi > 214. mailto:kiviniemi.valtteri@gmail.com > 215. http://ark.intel.com/products/65719/ > 216. http://www.intel.com/content/www/us/en/motherboards/desktop-motherb= oards/desktop-board-dq77mk.html > 217. mailto:root@dataproof.fi > 218. mailto:pasik@iki.fi > 219. http://xen.org/ > 220. mailto:pasik@iki.fi > 221. mailto:pasik@iki.fi > 222. mailto:pasik@iki.fi > 223. mailto:pasik@iki.fi > 224. http://kernel.org/ > 225. http://kernel.org/ > 226. mailto:Xen-devel@lists.xen.org > 227. http://lists.xen.org/xen-devel > 228. mailto:pasik@iki.fi > 229. http://kernel.org/ > 230. http://kernel.org/ > 231. mailto:Xen-devel@lists.xen.org > 232. http://lists.xen.org/xen-devel > 233. mailto:pasik@iki.fi > 234. mailto:pasik@iki.fi > 235. http://kernel.org/ > 236. http://kernel.org/ > 237. mailto:Xen-devel@lists.xen.org > 238. http://lists.xen.org/xen-devel > 239. mailto:pasik@iki.fi > 240. http://kernel.org/ > 241. http://kernel.org/ > 242. mailto:Xen-devel@lists.xen.org > 243. http://lists.xen.org/xen-devel > 244. mailto:pasik@iki.fi > 245. mailto:pasik@iki.fi > 246. mailto:pasik@iki.fi > 247. http://kernel.org/ > 248. http://kernel.org/ > 249. mailto:Xen-devel@lists.xen.org > 250. http://lists.xen.org/xen-devel > 251. mailto:pasik@iki.fi > 252. http://kernel.org/ > 253. http://kernel.org/ > 254. mailto:Xen-devel@lists.xen.org > 255. http://lists.xen.org/xen-devel > 256. mailto:pasik@iki.fi > 257. mailto:pasik@iki.fi > 258. http://kernel.org/ > 259. http://kernel.org/ > 260. mailto:Xen-devel@lists.xen.org > 261. http://lists.xen.org/xen-devel > 262. mailto:pasik@iki.fi > 263. http://kernel.org/ > 264. http://kernel.org/ > 265. mailto:Xen-devel@lists.xen.org > 266. http://lists.xen.org/xen-devel > 267. mailto:pasik@iki.fi > 268. mailto:pasik@iki.fi > 269. mailto:pasik@iki.fi > 270. mailto:pasik@iki.fi > 271. http://kernel.org/ > 272. http://kernel.org/ > 273. mailto:Xen-devel@lists.xen.org > 274. http://lists.xen.org/xen-devel > 275. mailto:pasik@iki.fi > 276. http://kernel.org/ > 277. http://kernel.org/ > 278. mailto:Xen-devel@lists.xen.org > 279. http://lists.xen.org/xen-devel > 280. mailto:pasik@iki.fi > 281. mailto:pasik@iki.fi > 282. http://kernel.org/ > 283. http://kernel.org/ > 284. mailto:Xen-devel@lists.xen.org > 285. http://lists.xen.org/xen-devel > 286. mailto:pasik@iki.fi > 287. http://kernel.org/ > 288. http://kernel.org/ > 289. mailto:Xen-devel@lists.xen.org > 290. http://lists.xen.org/xen-devel > 291. mailto:pasik@iki.fi > 292. mailto:pasik@iki.fi > 293. mailto:pasik@iki.fi > 294. http://kernel.org/ > 295. http://kernel.org/ > 296. mailto:Xen-devel@lists.xen.org > 297. http://lists.xen.org/xen-devel > 298. mailto:pasik@iki.fi > 299. http://kernel.org/ > 300. http://kernel.org/ > 301. mailto:Xen-devel@lists.xen.org > 302. http://lists.xen.org/xen-devel > 303. mailto:pasik@iki.fi > 304. mailto:pasik@iki.fi > 305. http://kernel.org/ > 306. http://kernel.org/ > 307. mailto:Xen-devel@lists.xen.org > 308. http://lists.xen.org/xen-devel > 309. mailto:pasik@iki.fi > 310. http://kernel.org/ > 311. http://kernel.org/ > 312. mailto:Xen-devel@lists.xen.org > 313. http://lists.xen.org/xen-devel > 314. mailto:kiviniemi.valtteri@gmail.com > 315. http://ark.intel.com/products/65719/ > 316. http://www.intel.com/content/www/us/en/motherboards/desktop-motherb= oards/desktop-board-dq77mk.html > 317. mailto:root@dataproof.fi > 318. mailto:pasik@iki.fi > 319. http://xen.org/ > 320. mailto:pasik@iki.fi > 321. mailto:pasik@iki.fi > 322. mailto:pasik@iki.fi > 323. mailto:pasik@iki.fi > 324. http://kernel.org/ > 325. http://kernel.org/ > 326. mailto:Xen-devel@lists.xen.org > 327. http://lists.xen.org/xen-devel > 328. mailto:pasik@iki.fi > 329. http://kernel.org/ > 330. http://kernel.org/ > 331. mailto:Xen-devel@lists.xen.org > 332. http://lists.xen.org/xen-devel > 333. mailto:pasik@iki.fi > 334. mailto:pasik@iki.fi > 335. http://kernel.org/ > 336. http://kernel.org/ > 337. mailto:Xen-devel@lists.xen.org > 338. http://lists.xen.org/xen-devel > 339. mailto:pasik@iki.fi > 340. http://kernel.org/ > 341. http://kernel.org/ > 342. mailto:Xen-devel@lists.xen.org > 343. http://lists.xen.org/xen-devel > 344. mailto:pasik@iki.fi > 345. mailto:pasik@iki.fi > 346. mailto:pasik@iki.fi > 347. http://kernel.org/ > 348. http://kernel.org/ > 349. mailto:Xen-devel@lists.xen.org > 350. http://lists.xen.org/xen-devel > 351. mailto:pasik@iki.fi > 352. http://kernel.org/ > 353. http://kernel.org/ > 354. mailto:Xen-devel@lists.xen.org > 355. http://lists.xen.org/xen-devel > 356. mailto:pasik@iki.fi > 357. mailto:pasik@iki.fi > 358. http://kernel.org/ > 359. http://kernel.org/ > 360. mailto:Xen-devel@lists.xen.org > 361. http://lists.xen.org/xen-devel > 362. mailto:pasik@iki.fi > 363. http://kernel.org/ > 364. http://kernel.org/ > 365. mailto:Xen-devel@lists.xen.org > 366. http://lists.xen.org/xen-devel > 367. mailto:pasik@iki.fi > 368. mailto:pasik@iki.fi > 369. mailto:pasik@iki.fi > 370. mailto:pasik@iki.fi > 371. http://kernel.org/ > 372. http://kernel.org/ > 373. mailto:Xen-devel@lists.xen.org > 374. http://lists.xen.org/xen-devel > 375. mailto:pasik@iki.fi > 376. http://kernel.org/ > 377. http://kernel.org/ > 378. mailto:Xen-devel@lists.xen.org > 379. http://lists.xen.org/xen-devel > 380. mailto:pasik@iki.fi > 381. mailto:pasik@iki.fi > 382. http://kernel.org/ > 383. http://kernel.org/ > 384. mailto:Xen-devel@lists.xen.org > 385. http://lists.xen.org/xen-devel > 386. mailto:pasik@iki.fi > 387. http://kernel.org/ > 388. http://kernel.org/ > 389. mailto:Xen-devel@lists.xen.org > 390. http://lists.xen.org/xen-devel > 391. mailto:pasik@iki.fi > 392. mailto:pasik@iki.fi > 393. mailto:pasik@iki.fi > 394. http://kernel.org/ > 395. http://kernel.org/ > 396. mailto:Xen-devel@lists.xen.org > 397. http://lists.xen.org/xen-devel > 398. mailto:pasik@iki.fi > 399. http://kernel.org/ > 400. http://kernel.org/ > 401. mailto:Xen-devel@lists.xen.org > 402. http://lists.xen.org/xen-devel > 403. mailto:pasik@iki.fi > 404. mailto:pasik@iki.fi > 405. http://kernel.org/ > 406. http://kernel.org/ > 407. mailto:Xen-devel@lists.xen.org > 408. http://lists.xen.org/xen-devel > 409. mailto:pasik@iki.fi > 410. http://kernel.org/ > 411. http://kernel.org/ > 412. mailto:Xen-devel@lists.xen.org > 413. http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 13:54:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 13:54:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ2vk-0003bs-86; Tue, 02 Oct 2012 13:54:36 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ2vi-0003bi-6n for Xen-devel@lists.xen.org; Tue, 02 Oct 2012 13:54:34 +0000 Received: from [85.158.138.51:45063] by server-11.bemta-3.messagelabs.com id 85/8F-21460-912FA605; Tue, 02 Oct 2012 13:54:33 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-12.tower-174.messagelabs.com!1349186071!24878674!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MjMzMTI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28469 invoked from network); 2 Oct 2012 13:54:32 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 13:54:32 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id 9325A25C6; Tue, 2 Oct 2012 16:54:31 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 725F420058; Tue, 2 Oct 2012 16:54:31 +0300 (EEST) Date: Tue, 2 Oct 2012 16:54:31 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Valtteri Kiviniemi Message-ID: <20121002135431.GN8912@reaktio.net> References: <20121001164757.GF8912@reaktio.net> <20121001182437.GG8912@reaktio.net> <20121002121932.GL8912@reaktio.net> <20121002131407.GM8912@reaktio.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.0.4, kernel 3.5.0 HVM crash and kernel BUG X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, Oct 02, 2012 at 04:46:37PM +0300, Valtteri Kiviniemi wrote: > Hi, > = > I have not enabled debug on Xen or dom0 kernel. Could you tell me the > parameters for Xen coompilation needed to enable debugging? And If you > would also happen to know what are the options needed to enable kernel > debugging in menuconfig? Well I can probably manage to get the kernel > debugging enabled myself, but if you happen to know them please share = so > maybe I can get everything enabled at the first try :) > I didn't mean compilation options, just the xen/kernel cmdline options, please use these: xen.gz loglvl=3Dall guest_loglvl=3Dall sync_console lapic=3Ddebug apic_verb= osity=3Ddebug apic=3Ddebug iommu=3Doff vmlinuz console=3Dhvc0 earlyprintk=3Dxen nomodeset initcall_debug debug log= level=3D10 Plus your serial console settings for xen.gz, of course. -- Pasi = > Thanks! > = > - Valtteri > = > 2012/10/2 Pasi K=E4rkk=E4inen <[1]pasik@iki.fi> > = > On Tue, Oct 02, 2012 at 04:01:04PM +0300, Valtteri Kiviniemi wrote: > > Hi, > > > > I already tried 3.2, 3.5, 3.5.0, 3.6.0-rc7 and 3.6.0, same prob= lem > all of > > those. My dom0 config is the same config that I'am using on oth= er > server > > where HVM is working, so I dont think that it is a config probl= em. > I have > > triple checked everything and all should be ok. dom0 dmesg shows > the same > > crash that I have previously posted here. /var/log/xen/ does not > contain > > any specific errors. > > > > Could this be some kind of broblem with my motherboard bios bei= ng > buggy or > > CPU not supported? I'm using the new intel Ivy Bridge processor > which has > > integrated GPU, but that should not probably cause these kind of > problems. > > Or maybe some ACPI problem? xm dmesg is showing some notices ab= out > ACPI. > > Is there any ACPI kernel parameters that I should try booting? = This > has to > > be somekind of problem with my hardware, or then maybe it could= be > a > > kernel problem too. I just really cant figure this out myself, I > have > > tried everything. > > > = > Hmm.. I have some distant memories of seeing a patch that fixes a bug > on recent Ivy Bridge systems, but I can't find a link right now. > Maybe you're affected by that.. > = > Also: Did you already post the crash log, with all the debug/verbose > options enabled for both Xen and dom0 kernel? > = > -- Pasi > > Lets take a quick summary of what has been tested, what hardware > I'm using > > etc. > > > > Xen-versions tested: 4.2.0, 4.0.4 > > Kernel-versions tested: 3.2.0, 3.5.0, 3.5.4, 3.6.0-rc7, 3.6.0 > > > > Host OS: Debian testing/wheezy, udev version 175-7, 2.13-35, py= thon > > version 2.7.3~rc2-2.1 > > > > Hardware: > > > > CPU: Intel Core i7-3770 3.4GHz > > MB: Intel DQ77MK (latest bios updated) > > Memory: 32GB (4 x 8GB DDR3-1600MHz) > > > > All relevant log files and configs: > > > > dom0 dmesg: [1][2]http://nago.fi/dmesg.txt > > qemu-dm log: [2][3]http://nago.fi/qemu-dm.txt > > xm dmesg log: [3][4]http://nago.fi/xm-dmesg.txt > > domU config: [4][5]http://nago.fi/domu-config.txt > > dom0 kernel config: [5][6]http://nago.fi/dom0-config.txt > > > > I have also tried playing with every setting on that domU that I > can think > > of and tried different configs etc. > > > > - Valtteri > > > > 2012/10/2 Pasi K=E4rkk=E4inen <[6][7]pasik@iki.fi> > > > > On Tue, Oct 02, 2012 at 03:11:07PM +0300, Valtteri Kiviniemi > wrote: > > > Hi, > > > > > > Another update: > > > > > > I wanted to check that if a Linux HVM would boot with > working VNC > > console, > > > so I tried to launch a Debian Squeeze installer on HVM. = It > refused > > to > > > start ant told me that vbd hotplug scripts were not work= ing. > After > > that > > > failure even the Windows domU would not anymore start wh= ich > was > > previously > > > starting ok. > > > > > > The hotplug scripts also starts hanging on the processes. > > > > > > root 9401 0.1 0.1 17700 1640 ? S 15:05 > 0:00 > > /bin/bash > > > /etc/xen/scripts/xen-hotplug-cleanup > > > root 9441 0.1 0.1 17700 1644 ? S 15:05 > 0:00 > > /bin/bash > > > /etc/xen/scripts/xen-hotplug-cleanup > > > root 9481 0.1 0.1 17700 1640 ? S 15:05 > 0:00 > > /bin/bash > > > /etc/xen/scripts/xen-hotplug-cleanup > > > root 9560 0.1 0.1 17700 1640 ? S 15:05 > 0:00 > > /bin/bash > > > /etc/xen/scripts/xen-hotplug-cleanup > > > root 10738 0.1 0.1 17696 1636 ? S 15:05 > 0:00 > > /bin/bash > > > /etc/xen/scripts/xen-hotplug-cleanup > > > root 10747 0.1 0.1 17792 1736 ? S 15:05 > 0:00 > > /bin/bash > > > /etc/xen/scripts/block remove > > > root 11286 0.0 0.0 4080 324 ? S 15:06 > 0:00 > > sleep 1 > > > root 11290 0.0 0.0 4080 324 ? S 15:06 > 0:00 > > sleep 1 > > > root 11294 0.0 0.0 4080 324 ? S 15:06 > 0:00 > > sleep 1 > > > root 11298 0.0 0.0 4080 324 ? S 15:06 > 0:00 > > sleep 1 > > > root 11302 0.0 0.0 4080 320 ? S 15:06 > 0:00 > > sleep 1 > > > root 11306 0.0 0.0 4080 320 ? S 15:06 > 0:00 > > sleep 1 > > > > > > Then I did a xm destroy and I had again the kernel BUG on > dmesg. So > > it > > > seems that the problem is not fixed by using 3.6.0. Udev > version is > > 175-7. > > > > > > > So you have definitely something broken in your system, > > probably in your dom0 kernel. Try with Linux 3.5.4 or 3.4.x, > > and see how that goes. > > > > Any errors in dom0 dmesg? How about in /var/log/xen/* ? > > > > -- Pasi > > > > > > > > > > > 2012/10/1 Valtteri Kiviniemi > <[1][7][8]kiviniemi.valtteri@gmail.com> > > > > > > Hi, > > > > > > CPU: Intel Core i7-3770 3.4GHz > > > [2][8][9]http://ark.intel.com/products/65719/ > > > > > > MB: Intel DQ77MK (latest bios updated) > > > > > > [3][9][10]http://www.intel.com/content/www/us/en/motherboards/deskto= p-motherboards/desktop-board-dq77mk.html > > > > > > Memory: 32GB (4 x 8GB DDR3-1600MHz) > > > > > > Host is Debian wheezy/testing, Xen 4.0.4 and latest 3.= 6.0 > kernel. > > > > > > Noticed also some errors in xm dmesg: > > > > > > root@xen-2:~# xm dmesg > > > > > > (XEN) Xen version 4.0.4 ([4][10][11]root@dataproof.fi) > (gcc version > > 4.7.1 > > > (Debian 4.7.1-7) ) Sun Sep 30 20:28:26 EEST 2012 > > > (XEN) Latest ChangeSet: unavailable > > > (XEN) Bootloader: GNU GRUB 0.97 > > > (XEN) Command line: dom0_mem=3D1280M cpufreq=3Dxen > clocksource=3Dhpet > > > (XEN) Video information: > > > (XEN) VGA is text mode 80x25, font 8x16 > > > (XEN) VBE/DDC methods: none; EDID transfer time: 0 > seconds > > > (XEN) EDID info not retrieved because no DDC retrieval > method > > detected > > > (XEN) Disc information: > > > (XEN) Found 4 MBR signatures > > > (XEN) Found 4 EDD information structures > > > (XEN) Xen-e820 RAM map: > > > (XEN) 0000000000000000 - 000000000009d800 (usable) > > > (XEN) 000000000009d800 - 00000000000a0000 (reserved) > > > (XEN) 00000000000e0000 - 0000000000100000 (reserved) > > > (XEN) 0000000000100000 - 0000000020000000 (usable) > > > (XEN) 0000000020000000 - 0000000020200000 (reserved) > > > (XEN) 0000000020200000 - 0000000040004000 (usable) > > > (XEN) 0000000040004000 - 0000000040005000 (reserved) > > > (XEN) 0000000040005000 - 00000000dbe44000 (usable) > > > (XEN) 00000000dbe44000 - 00000000dc2d7000 (reserved) > > > (XEN) 00000000dc2d7000 - 00000000dc2e7000 (ACPI data) > > > (XEN) 00000000dc2e7000 - 00000000dc40c000 (ACPI NVS) > > > (XEN) 00000000dc40c000 - 00000000dc6af000 (reserved) > > > (XEN) 00000000dc6af000 - 00000000dc6b0000 (usable) > > > (XEN) 00000000dc6b0000 - 00000000dc6f3000 (ACPI NVS) > > > (XEN) 00000000dc6f3000 - 00000000dd000000 (usable) > > > (XEN) 00000000dd800000 - 00000000dfa00000 (reserved) > > > (XEN) 00000000f8000000 - 00000000fc000000 (reserved) > > > (XEN) 00000000fec00000 - 00000000fec01000 (reserved) > > > (XEN) 00000000fed00000 - 00000000fed04000 (reserved) > > > (XEN) 00000000fed1c000 - 00000000fed20000 (reserved) > > > (XEN) 00000000fee00000 - 00000000fee01000 (reserved) > > > (XEN) 00000000ff000000 - 0000000100000000 (reserved) > > > (XEN) 0000000100000000 - 000000081e600000 (usable) > > > (XEN) ACPI: RSDP 000F0490, 0024 (r2 INTEL) > > > (XEN) ACPI: XSDT DC2DB080, 007C (r1 INTEL DQ77MK > 32 AMI > > > 10013) > > > (XEN) ACPI: FACP DC2E51F0, 010C (r5 INTEL DQ77MK > 32 AMI > > > 10013) > > > (XEN) ACPI Warning (tbfadt-0232): FADT (revision 5) is > longer > > than ACPI > > > 2.0 version, truncating length 0x10C to 0xF4 [20070126] > > > (XEN) ACPI: DSDT DC2DB188, A061 (r2 INTEL DQ77MK > 32 INTL > > > 20051117) > > > (XEN) ACPI: FACS DC40A080, 0040 > > > (XEN) ACPI: APIC DC2E5300, 0092 (r3 INTEL DQ77MK > 32 AMI > > > 10013) > > > (XEN) ACPI: FPDT DC2E5398, 0044 (r1 INTEL DQ77MK > 32 AMI > > > 10013) > > > (XEN) ACPI: TCPA DC2E53E0, 0032 (r2 INTEL DQ77MK > 32 MSFT > > > 1000013) > > > (XEN) ACPI: MCFG DC2E5418, 003C (r1 INTEL DQ77MK > 32 MSFT > > > 97) > > > (XEN) ACPI: HPET DC2E5458, 0038 (r1 INTEL DQ77MK > 32 AMI. > > > 5) > > > (XEN) ACPI: SSDT DC2E5490, 036D (r1 INTEL DQ77MK > 32 INTL > > > 20091112) > > > (XEN) ACPI: SSDT DC2E5800, 09AA (r1 INTEL DQ77MK > 32 INTL > > > 20051117) > > > (XEN) ACPI: SSDT DC2E61B0, 0A92 (r1 INTEL DQ77MK > 32 INTL > > > 20051117) > > > (XEN) ACPI: DMAR DC2E6C48, 00B8 (r1 INTEL DQ77MK > 32 INTL > > > 1) > > > (XEN) ACPI: ASF! DC2E6D00, 00A5 (r32 INTEL DQ77MK > 32 > > TFSM > > > F4240) > > > (XEN) System RAM: 32682MB (33467320kB) > > > (XEN) Domain heap initialised > > > (XEN) ACPI: 32/64X FACS address mismatch in FADT - > > > dc40a080/0000000000000000, using 32 > > > (XEN) Processor #0 7:10 APIC version 21 > > > (XEN) Processor #2 7:10 APIC version 21 > > > (XEN) Processor #4 7:10 APIC version 21 > > > (XEN) Processor #6 7:10 APIC version 21 > > > (XEN) Processor #1 7:10 APIC version 21 > > > (XEN) Processor #3 7:10 APIC version 21 > > > (XEN) Processor #5 7:10 APIC version 21 > > > (XEN) Processor #7 7:10 APIC version 21 > > > (XEN) IOAPIC[0]: apic_id 2, version 32, address > 0xfec00000, GSI > > 0-23 > > > (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs > > > (XEN) Switched to APIC driver x2apic_cluster. > > > (XEN) x2APIC mode enabled. > > > (XEN) Using scheduler: SMP Credit Scheduler (credit) > > > (XEN) Detected 3392.369 MHz processor. > > > (XEN) Initing memory sharing. > > > (XEN) VMX: Supported advanced features: > > > (XEN) - APIC MMIO access virtualisation > > > (XEN) - APIC TPR shadow > > > (XEN) - Extended Page Tables (EPT) > > > (XEN) - Virtual-Processor Identifiers (VPID) > > > (XEN) - Virtual NMI > > > (XEN) - MSR direct-access bitmap > > > (XEN) - Unrestricted Guest > > > (XEN) EPT supports 2MB super page. > > > (XEN) HVM: ASIDs enabled. > > > (XEN) HVM: VMX enabled > > > (XEN) HVM: Hardware Assisted Paging detected. > > > (XEN) Intel VT-d Snoop Control not enabled. > > > (XEN) Intel VT-d Dom0 DMA Passthrough not enabled. > > > (XEN) Intel VT-d Queued Invalidation enabled. > > > (XEN) Intel VT-d Interrupt Remapping enabled. > > > (XEN) I/O virtualisation enabled > > > (XEN) - Dom0 mode: Relaxed > > > (XEN) Enabled directed EOI with ioapic_ack_old on! > > > (XEN) Total of 8 processors activated. > > > (XEN) ENABLING IO-APIC IRQs > > > (XEN) -> Using old ACK method > > > (XEN) TSC is reliable, synchronization unnecessary > > > (XEN) Platform timer appears to have unexpectedly wrap= ped > 1 > > times. > > > (XEN) Platform timer is 14.318MHz HPET > > > (XEN) Allocated console ring of 16 KiB. > > > (XEN) Brought up 8 CPUs > > > (XEN) *** LOADING DOMAIN 0 *** > > > (XEN) Xen kernel: 64-bit, lsb, compat32 > > > (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 = -> > > 0x1ae7000 > > > (XEN) PHYSICAL MEMORY ARRANGEMENT: > > > (XEN) Dom0 alloc.: 0000000804000000->00000008060000= 00 > (319488 > > pages > > > to be allocated) > > > (XEN) VIRTUAL MEMORY ARRANGEMENT: > > > (XEN) Loaded kernel: ffffffff81000000->ffffffff81ae70= 00 > > > (XEN) Init. ramdisk: ffffffff81ae7000->ffffffff81ae70= 00 > > > (XEN) Phys-Mach map: ffffffff81ae7000->ffffffff81d670= 00 > > > (XEN) Start info: ffffffff81d67000->ffffffff81d674= b4 > > > (XEN) Page tables: ffffffff81d68000->ffffffff81d7b0= 00 > > > (XEN) Boot stack: ffffffff81d7b000->ffffffff81d7c0= 00 > > > (XEN) TOTAL: ffffffff80000000->ffffffff820000= 00 > > > (XEN) ENTRY ADDRESS: ffffffff815e3210 > > > (XEN) Dom0 has maximum 8 VCPUs > > > (XEN) [VT-D]iommu.c:718: BIOS did not enable IGD for VT > properly. > > > Disabling IGD VT-d engine. > > > (XEN) Scrubbing Free RAM: done. > > > (XEN) Xen trace buffers: disabled > > > (XEN) Std. Loglevel: Errors and warnings > > > (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and > warnings) > > > (XEN) Xen is relinquishing VGA console. > > > (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three ti= mes > to > > switch > > > input to Xen) > > > (XEN) Freed 172kB init memory. > > > (XEN) traps.c:2333:d0 Domain attempted WRMSR > 000000000000008b > > from > > > 00000012:00000000 to 00000000:00000000. > > > > > > - Valtteri > > > > > > 2012/10/1 Pasi K=E4rkk=E4inen <[5][11][12]pasik@iki.fi> > > > > > > On Mon, Oct 01, 2012 at 09:12:50PM +0300, Valtteri > Kiviniemi > > wrote: > > > > Hi, > > > > > > > > Lowering memory or vcpu's does not help, proble= m is > the > > same. I > > > originally > > > > installed Xen 4.2.0 and the problem was same on > that too. > > Then I > > > > downgraded back to 4.0.4 since I thought that t= his > might > > be a bug > > > on > > > > 4.2.0. I have been previously running Windows > Server 2008 > > R2 > > > succesfully > > > > on Xen 4.0.x on different hardware with this sa= me > config. > > > Hypervisor is > > > > 64bit and windows is 64bit. > > > > > > > > Any ideas what to try next? > > > > > > > > > > What kind of hardware is that? > > > > > > [6][12][13]xen.org automated testing regularly tests > Windows VMs, > > and it works > > > OK there. > > > > > > -- Pasi > > > > Ps. qemu-dm.log is the following: > > > > > > > > domid: 10 > > > > config qemu network with xen bridge for tap10.0 > xenbr0 > > > > Using file /dev/virtuals/ts in read-write mode > > > > Using file > /media/iso/windows_server_2008_r2_sp1.iso in > > read-only > > > mode > > > > Watching > /local/domain/0/device-model/10/logdirty/cmd > > > > Watching /local/domain/0/device-model/10/command > > > > qemu_map_cache_init nr_buckets =3D 10000 size 4= 194304 > > > > shared page at pfn feffd > > > > buffered io page at pfn feffb > > > > Guest uuid =3D 52f19e23-2955-c27d-a22c-60c5d8c6= 0d5a > > > > Time offset set 0 > > > > populating video RAM at ff000000 > > > > mapping video RAM from ff000000 > > > > Register xen platform. > > > > Done register platform. > > > > platform_fixed_ioport: changed ro/rw state of R= OM > memory > > area. > > > now is rw > > > > state. > > > > > > > xs_read(/local/domain/0/device-model/10/xen_extended_power_mgmt): > > > read > > > > error > > > > medium change watch on `hdc' (index: 1): > > > > /media/iso/windows_server_2008_r2_sp1.iso > > > > I/O request not ready: 0, ptr: 0, port: 0, data= : 0, > count: > > 0, > > > size: 0 > > > > Log-dirty: no command yet. > > > > xs_read(/local/domain/10/log-throttling): read > error > > > > qemu: ignoring not-understood drive > > > `/local/domain/10/log-throttling' > > > > medium change watch on > `/local/domain/10/log-throttling' - > > > unknown device, > > > > ignored > > > > cirrus vga map change while on lfb mode > > > > mapping vram to f0000000 - f0400000 > > > > platform_fixed_ioport: changed ro/rw state of R= OM > memory > > area. > > > now is rw > > > > state. > > > > platform_fixed_ioport: changed ro/rw state of R= OM > memory > > area. > > > now is ro > > > > state. > > > > > > > > 2012/10/1 Pasi K=E4rkk=E4inen > <[1][7][13][14]pasik@iki.fi> > > > > > > > > On Mon, Oct 01, 2012 at 07:23:44PM +0300, > Valtteri > > Kiviniemi > > > wrote: > > > > > Hi, > > > > > > > > > > I have tried other config files, but the > problem is > > the > > > same. At > > > > the > > > > > moment I'm using a config file from anot= her > server > > where I > > > have a > > > > working > > > > > Windows Server 2008 R2 installation, so I > dont > > think that > > > there is > > > > > anything wrong with my config: > > > > > > > > > > > > > Did you try with less vcpus, for example 2 ? > > > > how about with less memory, say 2 GB ? > > > > > > > > Did you try with later Xen versions? Is that a > 32bit > > Xen, or > > > 64bit Xen > > > > hypervisor? > > > > > > > > -- Pasi > > > > > kernel =3D "/usr/lib/xen/boot/hvmloader" > > > > > builder =3D "hvm" > > > > > shadow_memory =3D "8" > > > > > memory =3D "4096" > > > > > name =3D "ts" > > > > > vcpus =3D "8" > > > > > cpus =3D ["0", "1", "2", "3", "4", "5", = "6", > "7"] > > > > > pae =3D "1" > > > > > acpi =3D "1" > > > > > apic =3D "1" > > > > > vfb =3D [ 'type=3Dvnc, vnclisten=3D10.10= 0.100.50, > > vncpasswd=3Dxxx' > > > ] > > > > > xen_extended_power_mgmt =3D "0" > > > > > vif =3D [ "type=3Dioemu, mac=3D00:16:3e:= d7:d7:5d, > > bridge=3Dxenbr0" > > > ] > > > > > disk =3D [ "phy:/dev/virtuals/ts,hda,w", > > > > > > > > > "file:/media/iso/windows_server_2008_r2_sp1.iso,hdc:cdrom,r" ] > > > > > on_poweroff =3D "destroy" > > > > > on_reboot =3D "restart" > > > > > on_crash =3D "restart" > > > > > viridian =3D "1" > > > > > device_model =3D "/usr/lib/xen/bin/qemu-= dm" > > > > > boot =3D "dc" > > > > > snapshot =3D "0" > > > > > vncconsole =3D "1" > > > > > sdl =3D "0" > > > > > opengl =3D "0" > > > > > vnc =3D "1" > > > > > nographic =3D "0" > > > > > stdvga =3D "0" > > > > > tsc_mode =3D "1" > > > > > monitor =3D "0" > > > > > localtime =3D "1" > > > > > usb =3D "0" > > > > > keymap =3D "fi" > > > > > xen_platform_pci =3D "1" > > > > > pci_msitranslate =3D "1" > > > > > pci_power_mgmt =3D "0" > > > > > > > > > > 2012/10/1 Pasi K=E4rkk=E4inen > > <[1][2][8][14][15]pasik@iki.fi> > > > > > > > > > > On Mon, Oct 01, 2012 at 06:46:08PM +03= 00, > > Valtteri > > > Kiviniemi > > > > wrote: > > > > > > Hi, > > > > > > > > > > > > Yes, I have viridian=3D1 on my do= mU > config. > > > > > > > > > > > > > > > > Try with some known good domU configfi= le. > > > > > > > > > > -- Pasi > > > > > > 2012/10/1 Pasi K=E4rkk=E4inen > > > <[1][2][3][9][15][16]pasik@iki.fi> > > > > > > > > > > > > On Mon, Oct 01, 2012 at 05:06:5= 3PM > +0300, > > > Valtteri > > > > Kiviniemi > > > > > wrote: > > > > > > > Hi, > > > > > > > > > > > > > > I'm now using 3.6.0 and ca= n't > > reproduce that > > > crash > > > > anymore, > > > > > so it > > > > > > seems > > > > > > > that it was a kernel bug. > > > > > > > > > > > > > > > > > > > OK. > > > > > > > However I'm still getting > black > > screen on > > > VNC > > > > > > > when trying to install Win= dows > Server > > 2008 > > > R2. I can > > > > see the > > > > > > "windows is > > > > > > > loading files" screen but > after the > > > installer starts > > > > the VNC > > > > > > display goes > > > > > > > black. > > > > > > > > > > > > > > Any ideas? > > > > > > > > > > > > > > > > > > > Do you have viridian=3D1 specif= ied > for the > > windows > > > vm? > > > > > > > > > > > > -- Pasi > > > > > > > > > > > > > - Valtteri > > > > > > > > > > > > > > 2012/10/1 Pasi K=E4rkk=E4i= nen > > > <[1][2][3][4][10][16][17]pasik@iki.fi> > > > > > > > > > > > > > > On Sun, Sep 30, 2012 at > 11:18:03PM > > +0300, > > > Valtteri > > > > > Kiviniemi > > > > > > wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > I'm trying to get > Windows > > Server 2008 > > > R2 > > > > installation > > > > > > booting on > > > > > > > Xen > > > > > > > > 4.0.4. Using the > following > > config: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The domU will start > booting > > just > > > fine, but > > > > after a > > > > > few > > > > > > minutes the > > > > > > > VNC > > > > > > > > screen goes black. > After that > > when > > > typing "xm > > > > destroy > > > > > ts" it > > > > > > will > > > > > > > trigger > > > > > > > > a kernel BUG: > > > > > > > > > > > > > > > > BUG: unable to hand= le > kernel > > NULL > > > pointer > > > > dereference > > > > > at > > > > > > > 0000000000000030 > > > > > > > > IP: > [] > > > iput+0x3e/0x195 > > > > > > > > PGD 0 > > > > > > > > Oops: 0000 [#1] SMP > > > > > > > > CPU 6 > > > > > > > > Pid: 3571, comm: > qemu-dm Not > > tainted > > > > 3.5.0-dom0 #1 > > > > > > > > > > > > > > First of all upgrade to > latest > > 3.5.x Linux > > > kernel > > > > release > > > > > .. so > > > > > > at least > > > > > > > 3.5.4. > > > > > > > > > > > > > > -- Pasi > > > > > > > > > > > > > > > /DQ77MK > > > > > > > > RIP: > e030:[] > > > > [] > > > > > > > iput+0x3e/0x195 > > > > > > > > RSP: > e02b:ffff8800389ffbf8 > > EFLAGS: > > > 00010246 > > > > > > > > RAX: 00000000000000= 01 > RBX: > > > ffff8800377b0720 > > > > RCX: > > > > > > ffff8800501c0000 > > > > > > > > RDX: ffff8800501c00= 00 > RSI: > > > ffff8800377b0790 > > > > RDI: > > > > > > ffff8800377b0790 > > > > > > > > RBP: 00000000000000= 00 > R08: > > > ffffffff815cdd00 > > > > R09: > > > > > > 0000000000000016 > > > > > > > > R10: fefefefefefefe= ff > R11: > > > ffff8800377b0400 > > > > R12: > > > > > > 00000001000a3e0c > > > > > > > > R13: 00000000000000= 00 > R14: > > > 00000001000a3e0c > > > > R15: > > > > > > ffff8800389ffc28 > > > > > > > > FS: > 00007f1af70a8700(0000) > > > > GS:ffff880050180000(0000) > > > > > > > > knlGS:0000000000000= 000 > > > > > > > > CS: e033 DS: 0000 = ES: > 0000 > > CR0: > > > > 000000008005003b > > > > > > > > CR2: 00000000000000= 30 > CR3: > > > 000000000156d000 > > > > CR4: > > > > > > 0000000000002660 > > > > > > > > DR0: 00000000000000= 00 > DR1: > > > 0000000000000000 > > > > DR2: > > > > > > 0000000000000000 > > > > > > > > DR3: 00000000000000= 00 > DR6: > > > 00000000ffff0ff0 > > > > DR7: > > > > > > 0000000000000400 > > > > > > > > Process qemu-dm (pi= d: > 3571, > > > threadinfo > > > > > ffff8800389fe000, > > > > > > task > > > > > > > > ffff88003a721260) > > > > > > > > Stack: > > > > > > > > ffff88003a6d6400 > > ffff8800377b0000 > > > > 00000001000a3e0c > > > > > > > ffffffff8133ce8f > > > > > > > > ffff8800377b0400 > > ffffffff8134b6cd > > > > ffff8800389ffc28 > > > > > > > ffff8800389ffc28 > > > > > > > > ffff8800377b00f8 > > ffff8800377b0680 > > > > ffff880038cdcd60 > > > > > > > ffff8800377b0000 > > > > > > > > Call Trace: > > > > > > > > [] ? > > > > sk_release_kernel+0x23/0x39 > > > > > > > > [] ? > > > > netdev_run_todo+0x1e9/0x206 > > > > > > > > [] ? > > > > tun_chr_close+0x4c/0x7b > > > > > > > > [] ? > > > fput+0xe4/0x1c5 > > > > > > > > [] ? > > > filp_close+0x61/0x68 > > > > > > > > [] ? > > > > put_files_struct+0x62/0xb9 > > > > > > > > [] ? > > > do_exit+0x24a/0x74c > > > > > > > > [] ? > > > > do_group_exit+0x6b/0x9d > > > > > > > > [] ? > > > > > get_signal_to_deliver+0x449/0x46e > > > > > > > > [] ? > > > do_signal+0x28/0x4c4 > > > > > > > > [] ? > > > > > pvclock_clocksource_read+0x48/0xbf > > > > > > > > [] ? > > > ktime_get_ts+0x66/0xa8 > > > > > > > > [] ? > > > > > poll_select_copy_remaining+0xe0/0xf5 > > > > > > > > [] ? > > > > do_notify_resume+0x3b/0x74 > > > > > > > > [] ? > > > int_signal+0x12/0x17 > > > > > > > > Code: 00 00 00 40 7= 4 02 > 0f 0b > > 48 8d > > > 77 70 48 > > > > 8d bf 08 > > > > > 01 00 > > > > > > 00 e8 > > > > > > > 8b 71 10 > > > > > > > > 00 85 c0 0f 84 5d 0= 1 00 > 00 48 > > 8b 6b > > > 18 f6 83 > > > > 80 00 00 > > > > > 00 08 > > > > > > <4c> 8b > > > > > > > 65 30 > > > > > > > > 74 11 be 68 05 00 0= 0 48 > c7 c7 > > 8e df > > > 4f 81 e8 > > > > bb d0 > > > > > > > > RIP > [] > > > iput+0x3e/0x195 > > > > > > > > RSP > > > > > > > > CR2: 00000000000000= 30 > > > > > > > > ---[ end trace > > 67cc1654658fedcc ]--- > > > > > > > > Fixing recursive fa= ult > but > > reboot is > > > needed! > > > > > > > > > > > > > > > > I also tested Xen 4= .2.0 > and > > problem > > > is the > > > > same. So > > > > > is this > > > > > > a Xen > > > > > > > bug or a > > > > > > > > kernel bug? I am > running > > vanilla > > > > > [1][2][3][4][5][11][17][18]kernel.org > kernel > > > > > > 3.5.0 and > > > > > > > my > > > > > > > > hardware is Intel C= ore > i7-3770 > > CPU > > > and Intel > > > > DQ77MK > > > > > > motherboard > > > > > > > with > > > > > > > > latest bios. > > > > > > > > > > > > > > > > Best regards, > > > > > > > > Valtteri Kiviniemi > > > > > > > > > > > > > > > > References > > > > > > > > > > > > > > > > Visible links > > > > > > > > 1. > > [3][4][5][6][12][18][19]http://kernel.org/ > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Xen-devel mailing list > > > > > > > > > > [4][5][6][7][13][19][20]Xen-devel@lists.xen.org > > > > > > > > > > > [5][6][7][8][14][20][21]http://lists.xen.org/xen-dev= el > > > > > > > > > > > > > > References > > > > > > > > > > > > > > Visible links > > > > > > > 1. > > mailto:[7][8][9][15][21][22]pasik@iki.fi > > > > > > > 2. > > [8][9][10][16][22][23]http://kernel.org/ > > > > > > > 3. > > [9][10][11][17][23][24]http://kernel.org/ > > > > > > > 4. > > > mailto:[10][11][12][18][24][25]Xen-devel@lists.xen.o= rg > > > > > > > 5. > > > [11][12][13][19][25][26]http://lists.xen.org/xen-dev= el > > > > > > > > > > > > References > > > > > > > > > > > > Visible links > > > > > > 1. > mailto:[13][14][20][26][27]pasik@iki.fi > > > > > > 2. > mailto:[14][15][21][27][28]pasik@iki.fi > > > > > > 3. > [15][16][22][28][29]http://kernel.org/ > > > > > > 4. > [16][17][23][29][30]http://kernel.org/ > > > > > > 5. > > mailto:[17][18][24][30][31]Xen-devel@lists.xen.org > > > > > > 6. > > [18][19][25][31][32]http://lists.xen.org/xen-devel > > > > > > 7. > mailto:[19][20][26][32][33]pasik@iki.fi > > > > > > 8. > [20][21][27][33][34]http://kernel.org/ > > > > > > 9. > [21][22][28][34][35]http://kernel.org/ > > > > > > 10. > > mailto:[22][23][29][35][36]Xen-devel@lists.xen.org > > > > > > 11. > > [23][24][30][36][37]http://lists.xen.org/xen-devel > > > > > > > > > > References > > > > > > > > > > Visible links > > > > > 1. mailto:[25][31][37][38]pasik@iki.fi > > > > > 2. mailto:[26][32][38][39]pasik@iki.fi > > > > > 3. mailto:[27][33][39][40]pasik@iki.fi > > > > > 4. [28][34][40][41]http://kernel.org/ > > > > > 5. [29][35][41][42]http://kernel.org/ > > > > > 6. > mailto:[30][36][42][43]Xen-devel@lists.xen.org > > > > > 7. > [31][37][43][44]http://lists.xen.org/xen-devel > > > > > 8. mailto:[32][38][44][45]pasik@iki.fi > > > > > 9. [33][39][45][46]http://kernel.org/ > > > > > 10. [34][40][46][47]http://kernel.org/ > > > > > 11. > mailto:[35][41][47][48]Xen-devel@lists.xen.org > > > > > 12. > [36][42][48][49]http://lists.xen.org/xen-devel > > > > > 13. mailto:[37][43][49][50]pasik@iki.fi > > > > > 14. mailto:[38][44][50][51]pasik@iki.fi > > > > > 15. [39][45][51][52]http://kernel.org/ > > > > > 16. [40][46][52][53]http://kernel.org/ > > > > > 17. > mailto:[41][47][53][54]Xen-devel@lists.xen.org > > > > > 18. > [42][48][54][55]http://lists.xen.org/xen-devel > > > > > 19. mailto:[43][49][55][56]pasik@iki.fi > > > > > 20. [44][50][56][57]http://kernel.org/ > > > > > 21. [45][51][57][58]http://kernel.org/ > > > > > 22. > mailto:[46][52][58][59]Xen-devel@lists.xen.org > > > > > 23. > [47][53][59][60]http://lists.xen.org/xen-devel > > > > > > > > References > > > > > > > > Visible links > > > > 1. mailto:[54][60][61]pasik@iki.fi > > > > 2. mailto:[55][61][62]pasik@iki.fi > > > > 3. mailto:[56][62][63]pasik@iki.fi > > > > 4. mailto:[57][63][64]pasik@iki.fi > > > > 5. [58][64][65]http://kernel.org/ > > > > 6. [59][65][66]http://kernel.org/ > > > > 7. mailto:[60][66][67]Xen-devel@lists.xen.org > > > > 8. [61][67][68]http://lists.xen.org/xen-devel > > > > 9. mailto:[62][68][69]pasik@iki.fi > > > > 10. [63][69][70]http://kernel.org/ > > > > 11. [64][70][71]http://kernel.org/ > > > > 12. mailto:[65][71][72]Xen-devel@lists.xen.org > > > > 13. [66][72][73]http://lists.xen.org/xen-devel > > > > 14. mailto:[67][73][74]pasik@iki.fi > > > > 15. mailto:[68][74][75]pasik@iki.fi > > > > 16. [69][75][76]http://kernel.org/ > > > > 17. [70][76][77]http://kernel.org/ > > > > 18. mailto:[71][77][78]Xen-devel@lists.xen.org > > > > 19. [72][78][79]http://lists.xen.org/xen-devel > > > > 20. mailto:[73][79][80]pasik@iki.fi > > > > 21. [74][80][81]http://kernel.org/ > > > > 22. [75][81][82]http://kernel.org/ > > > > 23. mailto:[76][82][83]Xen-devel@lists.xen.org > > > > 24. [77][83][84]http://lists.xen.org/xen-devel > > > > 25. mailto:[78][84][85]pasik@iki.fi > > > > 26. mailto:[79][85][86]pasik@iki.fi > > > > 27. mailto:[80][86][87]pasik@iki.fi > > > > 28. [81][87][88]http://kernel.org/ > > > > 29. [82][88][89]http://kernel.org/ > > > > 30. mailto:[83][89][90]Xen-devel@lists.xen.org > > > > 31. [84][90][91]http://lists.xen.org/xen-devel > > > > 32. mailto:[85][91][92]pasik@iki.fi > > > > 33. [86][92][93]http://kernel.org/ > > > > 34. [87][93][94]http://kernel.org/ > > > > 35. mailto:[88][94][95]Xen-devel@lists.xen.org > > > > 36. [89][95][96]http://lists.xen.org/xen-devel > > > > 37. mailto:[90][96][97]pasik@iki.fi > > > > 38. mailto:[91][97][98]pasik@iki.fi > > > > 39. [92][98][99]http://kernel.org/ > > > > 40. [93][99][100]http://kernel.org/ > > > > 41. mailto:[94][100][101]Xen-devel@lists.xen.org > > > > 42. [95][101][102]http://lists.xen.org/xen-devel > > > > 43. mailto:[96][102][103]pasik@iki.fi > > > > 44. [97][103][104]http://kernel.org/ > > > > 45. [98][104][105]http://kernel.org/ > > > > 46. mailto:[99][105][106]Xen-devel@lists.xen.org > > > > 47. [100][106][107]http://lists.xen.org/xen-devel > > > > > > References > > > > > > Visible links > > > 1. mailto:[107][108]kiviniemi.valtteri@gmail.com > > > 2. [108][109]http://ark.intel.com/products/65719/ > > > 3. > > > [109][110]http://www.intel.com/content/www/us/en/motherboards/deskt= op-motherboards/desktop-board-dq77mk.html > > > 4. mailto:[110][111]root@dataproof.fi > > > 5. mailto:[111][112]pasik@iki.fi > > > 6. [112][113]http://xen.org/ > > > 7. mailto:[113][114]pasik@iki.fi > > > 8. mailto:[114][115]pasik@iki.fi > > > 9. mailto:[115][116]pasik@iki.fi > > > 10. mailto:[116][117]pasik@iki.fi > > > 11. [117][118]http://kernel.org/ > > > 12. [118][119]http://kernel.org/ > > > 13. mailto:[119][120]Xen-devel@lists.xen.org > > > 14. [120][121]http://lists.xen.org/xen-devel > > > 15. mailto:[121][122]pasik@iki.fi > > > 16. [122][123]http://kernel.org/ > > > 17. [123][124]http://kernel.org/ > > > 18. mailto:[124][125]Xen-devel@lists.xen.org > > > 19. [125][126]http://lists.xen.org/xen-devel > > > 20. mailto:[126][127]pasik@iki.fi > > > 21. mailto:[127][128]pasik@iki.fi > > > 22. [128][129]http://kernel.org/ > > > 23. [129][130]http://kernel.org/ > > > 24. mailto:[130][131]Xen-devel@lists.xen.org > > > 25. [131][132]http://lists.xen.org/xen-devel > > > 26. mailto:[132][133]pasik@iki.fi > > > 27. [133][134]http://kernel.org/ > > > 28. [134][135]http://kernel.org/ > > > 29. mailto:[135][136]Xen-devel@lists.xen.org > > > 30. [136][137]http://lists.xen.org/xen-devel > > > 31. mailto:[137][138]pasik@iki.fi > > > 32. mailto:[138][139]pasik@iki.fi > > > 33. mailto:[139][140]pasik@iki.fi > > > 34. [140][141]http://kernel.org/ > > > 35. [141][142]http://kernel.org/ > > > 36. mailto:[142][143]Xen-devel@lists.xen.org > > > 37. [143][144]http://lists.xen.org/xen-devel > > > 38. mailto:[144][145]pasik@iki.fi > > > 39. [145][146]http://kernel.org/ > > > 40. [146][147]http://kernel.org/ > > > 41. mailto:[147][148]Xen-devel@lists.xen.org > > > 42. [148][149]http://lists.xen.org/xen-devel > > > 43. mailto:[149][150]pasik@iki.fi > > > 44. mailto:[150][151]pasik@iki.fi > > > 45. [151][152]http://kernel.org/ > > > 46. [152][153]http://kernel.org/ > > > 47. mailto:[153][154]Xen-devel@lists.xen.org > > > 48. [154][155]http://lists.xen.org/xen-devel > > > 49. mailto:[155][156]pasik@iki.fi > > > 50. [156][157]http://kernel.org/ > > > 51. [157][158]http://kernel.org/ > > > 52. mailto:[158][159]Xen-devel@lists.xen.org > > > 53. [159][160]http://lists.xen.org/xen-devel > > > 54. mailto:[160][161]pasik@iki.fi > > > 55. mailto:[161][162]pasik@iki.fi > > > 56. mailto:[162][163]pasik@iki.fi > > > 57. mailto:[163][164]pasik@iki.fi > > > 58. [164][165]http://kernel.org/ > > > 59. [165][166]http://kernel.org/ > > > 60. mailto:[166][167]Xen-devel@lists.xen.org > > > 61. [167][168]http://lists.xen.org/xen-devel > > > 62. mailto:[168][169]pasik@iki.fi > > > 63. [169][170]http://kernel.org/ > > > 64. [170][171]http://kernel.org/ > > > 65. mailto:[171][172]Xen-devel@lists.xen.org > > > 66. [172][173]http://lists.xen.org/xen-devel > > > 67. mailto:[173][174]pasik@iki.fi > > > 68. mailto:[174][175]pasik@iki.fi > > > 69. [175][176]http://kernel.org/ > > > 70. [176][177]http://kernel.org/ > > > 71. mailto:[177][178]Xen-devel@lists.xen.org > > > 72. [178][179]http://lists.xen.org/xen-devel > > > 73. mailto:[179][180]pasik@iki.fi > > > 74. [180][181]http://kernel.org/ > > > 75. [181][182]http://kernel.org/ > > > 76. mailto:[182][183]Xen-devel@lists.xen.org > > > 77. [183][184]http://lists.xen.org/xen-devel > > > 78. mailto:[184][185]pasik@iki.fi > > > 79. mailto:[185][186]pasik@iki.fi > > > 80. mailto:[186][187]pasik@iki.fi > > > 81. [187][188]http://kernel.org/ > > > 82. [188][189]http://kernel.org/ > > > 83. mailto:[189][190]Xen-devel@lists.xen.org > > > 84. [190][191]http://lists.xen.org/xen-devel > > > 85. mailto:[191][192]pasik@iki.fi > > > 86. [192][193]http://kernel.org/ > > > 87. [193][194]http://kernel.org/ > > > 88. mailto:[194][195]Xen-devel@lists.xen.org > > > 89. [195][196]http://lists.xen.org/xen-devel > > > 90. mailto:[196][197]pasik@iki.fi > > > 91. mailto:[197][198]pasik@iki.fi > > > 92. [198][199]http://kernel.org/ > > > 93. [199][200]http://kernel.org/ > > > 94. mailto:[200][201]Xen-devel@lists.xen.org > > > 95. [201][202]http://lists.xen.org/xen-devel > > > 96. mailto:[202][203]pasik@iki.fi > > > 97. [203][204]http://kernel.org/ > > > 98. [204][205]http://kernel.org/ > > > 99. mailto:[205][206]Xen-devel@lists.xen.org > > > 100. [206][207]http://lists.xen.org/xen-devel > > > > References > > > > Visible links > > 1. [208]http://nago.fi/dmesg.txt > > 2. [209]http://nago.fi/qemu-dm.txt > > 3. [210]http://nago.fi/xm-dmesg.txt > > 4. [211]http://nago.fi/domu-config.txt > > 5. [212]http://nago.fi/dom0-config.txt > > 6. mailto:[213]pasik@iki.fi > > 7. mailto:[214]kiviniemi.valtteri@gmail.com > > 8. [215]http://ark.intel.com/products/65719/ > > 9. > [216]http://www.intel.com/content/www/us/en/motherboards/desktop-mot= herboards/desktop-board-dq77mk.html > > 10. mailto:[217]root@dataproof.fi > > 11. mailto:[218]pasik@iki.fi > > 12. [219]http://xen.org/ > > 13. mailto:[220]pasik@iki.fi > > 14. mailto:[221]pasik@iki.fi > > 15. mailto:[222]pasik@iki.fi > > 16. mailto:[223]pasik@iki.fi > > 17. [224]http://kernel.org/ > > 18. [225]http://kernel.org/ > > 19. mailto:[226]Xen-devel@lists.xen.org > > 20. [227]http://lists.xen.org/xen-devel > > 21. mailto:[228]pasik@iki.fi > > 22. [229]http://kernel.org/ > > 23. [230]http://kernel.org/ > > 24. mailto:[231]Xen-devel@lists.xen.org > > 25. [232]http://lists.xen.org/xen-devel > > 26. mailto:[233]pasik@iki.fi > > 27. mailto:[234]pasik@iki.fi > > 28. [235]http://kernel.org/ > > 29. [236]http://kernel.org/ > > 30. mailto:[237]Xen-devel@lists.xen.org > > 31. [238]http://lists.xen.org/xen-devel > > 32. mailto:[239]pasik@iki.fi > > 33. [240]http://kernel.org/ > > 34. [241]http://kernel.org/ > > 35. mailto:[242]Xen-devel@lists.xen.org > > 36. [243]http://lists.xen.org/xen-devel > > 37. mailto:[244]pasik@iki.fi > > 38. mailto:[245]pasik@iki.fi > > 39. mailto:[246]pasik@iki.fi > > 40. [247]http://kernel.org/ > > 41. [248]http://kernel.org/ > > 42. mailto:[249]Xen-devel@lists.xen.org > > 43. [250]http://lists.xen.org/xen-devel > > 44. mailto:[251]pasik@iki.fi > > 45. [252]http://kernel.org/ > > 46. [253]http://kernel.org/ > > 47. mailto:[254]Xen-devel@lists.xen.org > > 48. [255]http://lists.xen.org/xen-devel > > 49. mailto:[256]pasik@iki.fi > > 50. mailto:[257]pasik@iki.fi > > 51. [258]http://kernel.org/ > > 52. [259]http://kernel.org/ > > 53. mailto:[260]Xen-devel@lists.xen.org > > 54. [261]http://lists.xen.org/xen-devel > > 55. mailto:[262]pasik@iki.fi > > 56. [263]http://kernel.org/ > > 57. [264]http://kernel.org/ > > 58. mailto:[265]Xen-devel@lists.xen.org > > 59. [266]http://lists.xen.org/xen-devel > > 60. mailto:[267]pasik@iki.fi > > 61. mailto:[268]pasik@iki.fi > > 62. mailto:[269]pasik@iki.fi > > 63. mailto:[270]pasik@iki.fi > > 64. [271]http://kernel.org/ > > 65. [272]http://kernel.org/ > > 66. mailto:[273]Xen-devel@lists.xen.org > > 67. [274]http://lists.xen.org/xen-devel > > 68. mailto:[275]pasik@iki.fi > > 69. [276]http://kernel.org/ > > 70. [277]http://kernel.org/ > > 71. mailto:[278]Xen-devel@lists.xen.org > > 72. [279]http://lists.xen.org/xen-devel > > 73. mailto:[280]pasik@iki.fi > > 74. mailto:[281]pasik@iki.fi > > 75. [282]http://kernel.org/ > > 76. [283]http://kernel.org/ > > 77. mailto:[284]Xen-devel@lists.xen.org > > 78. [285]http://lists.xen.org/xen-devel > > 79. mailto:[286]pasik@iki.fi > > 80. [287]http://kernel.org/ > > 81. [288]http://kernel.org/ > > 82. mailto:[289]Xen-devel@lists.xen.org > > 83. [290]http://lists.xen.org/xen-devel > > 84. mailto:[291]pasik@iki.fi > > 85. mailto:[292]pasik@iki.fi > > 86. mailto:[293]pasik@iki.fi > > 87. [294]http://kernel.org/ > > 88. [295]http://kernel.org/ > > 89. mailto:[296]Xen-devel@lists.xen.org > > 90. [297]http://lists.xen.org/xen-devel > > 91. mailto:[298]pasik@iki.fi > > 92. [299]http://kernel.org/ > > 93. [300]http://kernel.org/ > > 94. mailto:[301]Xen-devel@lists.xen.org > > 95. [302]http://lists.xen.org/xen-devel > > 96. mailto:[303]pasik@iki.fi > > 97. mailto:[304]pasik@iki.fi > > 98. [305]http://kernel.org/ > > 99. [306]http://kernel.org/ > > 100. mailto:[307]Xen-devel@lists.xen.org > > 101. [308]http://lists.xen.org/xen-devel > > 102. mailto:[309]pasik@iki.fi > > 103. [310]http://kernel.org/ > > 104. [311]http://kernel.org/ > > 105. mailto:[312]Xen-devel@lists.xen.org > > 106. [313]http://lists.xen.org/xen-devel > > 107. mailto:[314]kiviniemi.valtteri@gmail.com > > 108. [315]http://ark.intel.com/products/65719/ > > 109. > [316]http://www.intel.com/content/www/us/en/motherboards/desktop-mot= herboards/desktop-board-dq77mk.html > > 110. mailto:[317]root@dataproof.fi > > 111. mailto:[318]pasik@iki.fi > > 112. [319]http://xen.org/ > > 113. mailto:[320]pasik@iki.fi > > 114. mailto:[321]pasik@iki.fi > > 115. mailto:[322]pasik@iki.fi > > 116. mailto:[323]pasik@iki.fi > > 117. [324]http://kernel.org/ > > 118. [325]http://kernel.org/ > > 119. mailto:[326]Xen-devel@lists.xen.org > > 120. [327]http://lists.xen.org/xen-devel > > 121. mailto:[328]pasik@iki.fi > > 122. [329]http://kernel.org/ > > 123. [330]http://kernel.org/ > > 124. mailto:[331]Xen-devel@lists.xen.org > > 125. [332]http://lists.xen.org/xen-devel > > 126. mailto:[333]pasik@iki.fi > > 127. mailto:[334]pasik@iki.fi > > 128. [335]http://kernel.org/ > > 129. [336]http://kernel.org/ > > 130. mailto:[337]Xen-devel@lists.xen.org > > 131. [338]http://lists.xen.org/xen-devel > > 132. mailto:[339]pasik@iki.fi > > 133. [340]http://kernel.org/ > > 134. [341]http://kernel.org/ > > 135. mailto:[342]Xen-devel@lists.xen.org > > 136. [343]http://lists.xen.org/xen-devel > > 137. mailto:[344]pasik@iki.fi > > 138. mailto:[345]pasik@iki.fi > > 139. mailto:[346]pasik@iki.fi > > 140. [347]http://kernel.org/ > > 141. [348]http://kernel.org/ > > 142. mailto:[349]Xen-devel@lists.xen.org > > 143. [350]http://lists.xen.org/xen-devel > > 144. mailto:[351]pasik@iki.fi > > 145. [352]http://kernel.org/ > > 146. [353]http://kernel.org/ > > 147. mailto:[354]Xen-devel@lists.xen.org > > 148. [355]http://lists.xen.org/xen-devel > > 149. mailto:[356]pasik@iki.fi > > 150. mailto:[357]pasik@iki.fi > > 151. [358]http://kernel.org/ > > 152. [359]http://kernel.org/ > > 153. mailto:[360]Xen-devel@lists.xen.org > > 154. [361]http://lists.xen.org/xen-devel > > 155. mailto:[362]pasik@iki.fi > > 156. [363]http://kernel.org/ > > 157. [364]http://kernel.org/ > > 158. mailto:[365]Xen-devel@lists.xen.org > > 159. [366]http://lists.xen.org/xen-devel > > 160. mailto:[367]pasik@iki.fi > > 161. mailto:[368]pasik@iki.fi > > 162. mailto:[369]pasik@iki.fi > > 163. mailto:[370]pasik@iki.fi > > 164. [371]http://kernel.org/ > > 165. [372]http://kernel.org/ > > 166. mailto:[373]Xen-devel@lists.xen.org > > 167. [374]http://lists.xen.org/xen-devel > > 168. mailto:[375]pasik@iki.fi > > 169. [376]http://kernel.org/ > > 170. [377]http://kernel.org/ > > 171. mailto:[378]Xen-devel@lists.xen.org > > 172. [379]http://lists.xen.org/xen-devel > > 173. mailto:[380]pasik@iki.fi > > 174. mailto:[381]pasik@iki.fi > > 175. [382]http://kernel.org/ > > 176. [383]http://kernel.org/ > > 177. mailto:[384]Xen-devel@lists.xen.org > > 178. [385]http://lists.xen.org/xen-devel > > 179. mailto:[386]pasik@iki.fi > > 180. [387]http://kernel.org/ > > 181. [388]http://kernel.org/ > > 182. mailto:[389]Xen-devel@lists.xen.org > > 183. [390]http://lists.xen.org/xen-devel > > 184. mailto:[391]pasik@iki.fi > > 185. mailto:[392]pasik@iki.fi > > 186. mailto:[393]pasik@iki.fi > > 187. [394]http://kernel.org/ > > 188. [395]http://kernel.org/ > > 189. mailto:[396]Xen-devel@lists.xen.org > > 190. [397]http://lists.xen.org/xen-devel > > 191. mailto:[398]pasik@iki.fi > > 192. [399]http://kernel.org/ > > 193. [400]http://kernel.org/ > > 194. mailto:[401]Xen-devel@lists.xen.org > > 195. [402]http://lists.xen.org/xen-devel > > 196. mailto:[403]pasik@iki.fi > > 197. mailto:[404]pasik@iki.fi > > 198. [405]http://kernel.org/ > > 199. [406]http://kernel.org/ > > 200. mailto:[407]Xen-devel@lists.xen.org > > 201. [408]http://lists.xen.org/xen-devel > > 202. mailto:[409]pasik@iki.fi > > 203. [410]http://kernel.org/ > > 204. [411]http://kernel.org/ > > 205. mailto:[412]Xen-devel@lists.xen.org > > 206. [413]http://lists.xen.org/xen-devel > = > References > = > Visible links > 1. mailto:pasik@iki.fi > 2. http://nago.fi/dmesg.txt > 3. http://nago.fi/qemu-dm.txt > 4. http://nago.fi/xm-dmesg.txt > 5. http://nago.fi/domu-config.txt > 6. http://nago.fi/dom0-config.txt > 7. mailto:pasik@iki.fi > 8. mailto:kiviniemi.valtteri@gmail.com > 9. http://ark.intel.com/products/65719/ > 10. http://www.intel.com/content/www/us/en/motherboards/desktop-motherb= oards/desktop-board-dq77mk.html > 11. mailto:root@dataproof.fi > 12. mailto:pasik@iki.fi > 13. http://xen.org/ > 14. mailto:pasik@iki.fi > 15. mailto:pasik@iki.fi > 16. mailto:pasik@iki.fi > 17. mailto:pasik@iki.fi > 18. http://kernel.org/ > 19. http://kernel.org/ > 20. mailto:Xen-devel@lists.xen.org > 21. http://lists.xen.org/xen-devel > 22. mailto:pasik@iki.fi > 23. http://kernel.org/ > 24. http://kernel.org/ > 25. mailto:Xen-devel@lists.xen.org > 26. http://lists.xen.org/xen-devel > 27. mailto:pasik@iki.fi > 28. mailto:pasik@iki.fi > 29. http://kernel.org/ > 30. http://kernel.org/ > 31. mailto:Xen-devel@lists.xen.org > 32. http://lists.xen.org/xen-devel > 33. mailto:pasik@iki.fi > 34. http://kernel.org/ > 35. http://kernel.org/ > 36. mailto:Xen-devel@lists.xen.org > 37. http://lists.xen.org/xen-devel > 38. mailto:pasik@iki.fi > 39. mailto:pasik@iki.fi > 40. mailto:pasik@iki.fi > 41. http://kernel.org/ > 42. http://kernel.org/ > 43. mailto:Xen-devel@lists.xen.org > 44. http://lists.xen.org/xen-devel > 45. mailto:pasik@iki.fi > 46. http://kernel.org/ > 47. http://kernel.org/ > 48. mailto:Xen-devel@lists.xen.org > 49. http://lists.xen.org/xen-devel > 50. mailto:pasik@iki.fi > 51. mailto:pasik@iki.fi > 52. http://kernel.org/ > 53. http://kernel.org/ > 54. mailto:Xen-devel@lists.xen.org > 55. http://lists.xen.org/xen-devel > 56. mailto:pasik@iki.fi > 57. http://kernel.org/ > 58. http://kernel.org/ > 59. mailto:Xen-devel@lists.xen.org > 60. http://lists.xen.org/xen-devel > 61. mailto:pasik@iki.fi > 62. mailto:pasik@iki.fi > 63. mailto:pasik@iki.fi > 64. mailto:pasik@iki.fi > 65. http://kernel.org/ > 66. http://kernel.org/ > 67. mailto:Xen-devel@lists.xen.org > 68. http://lists.xen.org/xen-devel > 69. mailto:pasik@iki.fi > 70. http://kernel.org/ > 71. http://kernel.org/ > 72. mailto:Xen-devel@lists.xen.org > 73. http://lists.xen.org/xen-devel > 74. mailto:pasik@iki.fi > 75. mailto:pasik@iki.fi > 76. http://kernel.org/ > 77. http://kernel.org/ > 78. mailto:Xen-devel@lists.xen.org > 79. http://lists.xen.org/xen-devel > 80. mailto:pasik@iki.fi > 81. http://kernel.org/ > 82. http://kernel.org/ > 83. mailto:Xen-devel@lists.xen.org > 84. http://lists.xen.org/xen-devel > 85. mailto:pasik@iki.fi > 86. mailto:pasik@iki.fi > 87. mailto:pasik@iki.fi > 88. http://kernel.org/ > 89. http://kernel.org/ > 90. mailto:Xen-devel@lists.xen.org > 91. http://lists.xen.org/xen-devel > 92. mailto:pasik@iki.fi > 93. http://kernel.org/ > 94. http://kernel.org/ > 95. mailto:Xen-devel@lists.xen.org > 96. http://lists.xen.org/xen-devel > 97. mailto:pasik@iki.fi > 98. mailto:pasik@iki.fi > 99. http://kernel.org/ > 100. http://kernel.org/ > 101. mailto:Xen-devel@lists.xen.org > 102. http://lists.xen.org/xen-devel > 103. mailto:pasik@iki.fi > 104. http://kernel.org/ > 105. http://kernel.org/ > 106. mailto:Xen-devel@lists.xen.org > 107. http://lists.xen.org/xen-devel > 108. mailto:kiviniemi.valtteri@gmail.com > 109. http://ark.intel.com/products/65719/ > 110. http://www.intel.com/content/www/us/en/motherboards/desktop-motherb= oards/desktop-board-dq77mk.html > 111. mailto:root@dataproof.fi > 112. mailto:pasik@iki.fi > 113. http://xen.org/ > 114. mailto:pasik@iki.fi > 115. mailto:pasik@iki.fi > 116. mailto:pasik@iki.fi > 117. mailto:pasik@iki.fi > 118. http://kernel.org/ > 119. http://kernel.org/ > 120. mailto:Xen-devel@lists.xen.org > 121. http://lists.xen.org/xen-devel > 122. mailto:pasik@iki.fi > 123. http://kernel.org/ > 124. http://kernel.org/ > 125. mailto:Xen-devel@lists.xen.org > 126. http://lists.xen.org/xen-devel > 127. mailto:pasik@iki.fi > 128. mailto:pasik@iki.fi > 129. http://kernel.org/ > 130. http://kernel.org/ > 131. mailto:Xen-devel@lists.xen.org > 132. http://lists.xen.org/xen-devel > 133. mailto:pasik@iki.fi > 134. http://kernel.org/ > 135. http://kernel.org/ > 136. mailto:Xen-devel@lists.xen.org > 137. http://lists.xen.org/xen-devel > 138. mailto:pasik@iki.fi > 139. mailto:pasik@iki.fi > 140. mailto:pasik@iki.fi > 141. http://kernel.org/ > 142. http://kernel.org/ > 143. mailto:Xen-devel@lists.xen.org > 144. http://lists.xen.org/xen-devel > 145. mailto:pasik@iki.fi > 146. http://kernel.org/ > 147. http://kernel.org/ > 148. mailto:Xen-devel@lists.xen.org > 149. http://lists.xen.org/xen-devel > 150. mailto:pasik@iki.fi > 151. mailto:pasik@iki.fi > 152. http://kernel.org/ > 153. http://kernel.org/ > 154. mailto:Xen-devel@lists.xen.org > 155. http://lists.xen.org/xen-devel > 156. mailto:pasik@iki.fi > 157. http://kernel.org/ > 158. http://kernel.org/ > 159. mailto:Xen-devel@lists.xen.org > 160. http://lists.xen.org/xen-devel > 161. mailto:pasik@iki.fi > 162. mailto:pasik@iki.fi > 163. mailto:pasik@iki.fi > 164. mailto:pasik@iki.fi > 165. http://kernel.org/ > 166. http://kernel.org/ > 167. mailto:Xen-devel@lists.xen.org > 168. http://lists.xen.org/xen-devel > 169. mailto:pasik@iki.fi > 170. http://kernel.org/ > 171. http://kernel.org/ > 172. mailto:Xen-devel@lists.xen.org > 173. http://lists.xen.org/xen-devel > 174. mailto:pasik@iki.fi > 175. mailto:pasik@iki.fi > 176. http://kernel.org/ > 177. http://kernel.org/ > 178. mailto:Xen-devel@lists.xen.org > 179. http://lists.xen.org/xen-devel > 180. mailto:pasik@iki.fi > 181. http://kernel.org/ > 182. http://kernel.org/ > 183. mailto:Xen-devel@lists.xen.org > 184. http://lists.xen.org/xen-devel > 185. mailto:pasik@iki.fi > 186. mailto:pasik@iki.fi > 187. mailto:pasik@iki.fi > 188. http://kernel.org/ > 189. http://kernel.org/ > 190. mailto:Xen-devel@lists.xen.org > 191. http://lists.xen.org/xen-devel > 192. mailto:pasik@iki.fi > 193. http://kernel.org/ > 194. http://kernel.org/ > 195. mailto:Xen-devel@lists.xen.org > 196. http://lists.xen.org/xen-devel > 197. mailto:pasik@iki.fi > 198. mailto:pasik@iki.fi > 199. http://kernel.org/ > 200. http://kernel.org/ > 201. mailto:Xen-devel@lists.xen.org > 202. http://lists.xen.org/xen-devel > 203. mailto:pasik@iki.fi > 204. http://kernel.org/ > 205. http://kernel.org/ > 206. mailto:Xen-devel@lists.xen.org > 207. http://lists.xen.org/xen-devel > 208. http://nago.fi/dmesg.txt > 209. http://nago.fi/qemu-dm.txt > 210. http://nago.fi/xm-dmesg.txt > 211. http://nago.fi/domu-config.txt > 212. http://nago.fi/dom0-config.txt > 213. mailto:pasik@iki.fi > 214. mailto:kiviniemi.valtteri@gmail.com > 215. http://ark.intel.com/products/65719/ > 216. http://www.intel.com/content/www/us/en/motherboards/desktop-motherb= oards/desktop-board-dq77mk.html > 217. mailto:root@dataproof.fi > 218. mailto:pasik@iki.fi > 219. http://xen.org/ > 220. mailto:pasik@iki.fi > 221. mailto:pasik@iki.fi > 222. mailto:pasik@iki.fi > 223. mailto:pasik@iki.fi > 224. http://kernel.org/ > 225. http://kernel.org/ > 226. mailto:Xen-devel@lists.xen.org > 227. http://lists.xen.org/xen-devel > 228. mailto:pasik@iki.fi > 229. http://kernel.org/ > 230. http://kernel.org/ > 231. mailto:Xen-devel@lists.xen.org > 232. http://lists.xen.org/xen-devel > 233. mailto:pasik@iki.fi > 234. mailto:pasik@iki.fi > 235. http://kernel.org/ > 236. http://kernel.org/ > 237. mailto:Xen-devel@lists.xen.org > 238. http://lists.xen.org/xen-devel > 239. mailto:pasik@iki.fi > 240. http://kernel.org/ > 241. http://kernel.org/ > 242. mailto:Xen-devel@lists.xen.org > 243. http://lists.xen.org/xen-devel > 244. mailto:pasik@iki.fi > 245. mailto:pasik@iki.fi > 246. mailto:pasik@iki.fi > 247. http://kernel.org/ > 248. http://kernel.org/ > 249. mailto:Xen-devel@lists.xen.org > 250. http://lists.xen.org/xen-devel > 251. mailto:pasik@iki.fi > 252. http://kernel.org/ > 253. http://kernel.org/ > 254. mailto:Xen-devel@lists.xen.org > 255. http://lists.xen.org/xen-devel > 256. mailto:pasik@iki.fi > 257. mailto:pasik@iki.fi > 258. http://kernel.org/ > 259. http://kernel.org/ > 260. mailto:Xen-devel@lists.xen.org > 261. http://lists.xen.org/xen-devel > 262. mailto:pasik@iki.fi > 263. http://kernel.org/ > 264. http://kernel.org/ > 265. mailto:Xen-devel@lists.xen.org > 266. http://lists.xen.org/xen-devel > 267. mailto:pasik@iki.fi > 268. mailto:pasik@iki.fi > 269. mailto:pasik@iki.fi > 270. mailto:pasik@iki.fi > 271. http://kernel.org/ > 272. http://kernel.org/ > 273. mailto:Xen-devel@lists.xen.org > 274. http://lists.xen.org/xen-devel > 275. mailto:pasik@iki.fi > 276. http://kernel.org/ > 277. http://kernel.org/ > 278. mailto:Xen-devel@lists.xen.org > 279. http://lists.xen.org/xen-devel > 280. mailto:pasik@iki.fi > 281. mailto:pasik@iki.fi > 282. http://kernel.org/ > 283. http://kernel.org/ > 284. mailto:Xen-devel@lists.xen.org > 285. http://lists.xen.org/xen-devel > 286. mailto:pasik@iki.fi > 287. http://kernel.org/ > 288. http://kernel.org/ > 289. mailto:Xen-devel@lists.xen.org > 290. http://lists.xen.org/xen-devel > 291. mailto:pasik@iki.fi > 292. mailto:pasik@iki.fi > 293. mailto:pasik@iki.fi > 294. http://kernel.org/ > 295. http://kernel.org/ > 296. mailto:Xen-devel@lists.xen.org > 297. http://lists.xen.org/xen-devel > 298. mailto:pasik@iki.fi > 299. http://kernel.org/ > 300. http://kernel.org/ > 301. mailto:Xen-devel@lists.xen.org > 302. http://lists.xen.org/xen-devel > 303. mailto:pasik@iki.fi > 304. mailto:pasik@iki.fi > 305. http://kernel.org/ > 306. http://kernel.org/ > 307. mailto:Xen-devel@lists.xen.org > 308. http://lists.xen.org/xen-devel > 309. mailto:pasik@iki.fi > 310. http://kernel.org/ > 311. http://kernel.org/ > 312. mailto:Xen-devel@lists.xen.org > 313. http://lists.xen.org/xen-devel > 314. mailto:kiviniemi.valtteri@gmail.com > 315. http://ark.intel.com/products/65719/ > 316. http://www.intel.com/content/www/us/en/motherboards/desktop-motherb= oards/desktop-board-dq77mk.html > 317. mailto:root@dataproof.fi > 318. mailto:pasik@iki.fi > 319. http://xen.org/ > 320. mailto:pasik@iki.fi > 321. mailto:pasik@iki.fi > 322. mailto:pasik@iki.fi > 323. mailto:pasik@iki.fi > 324. http://kernel.org/ > 325. http://kernel.org/ > 326. mailto:Xen-devel@lists.xen.org > 327. http://lists.xen.org/xen-devel > 328. mailto:pasik@iki.fi > 329. http://kernel.org/ > 330. http://kernel.org/ > 331. mailto:Xen-devel@lists.xen.org > 332. http://lists.xen.org/xen-devel > 333. mailto:pasik@iki.fi > 334. mailto:pasik@iki.fi > 335. http://kernel.org/ > 336. http://kernel.org/ > 337. mailto:Xen-devel@lists.xen.org > 338. http://lists.xen.org/xen-devel > 339. mailto:pasik@iki.fi > 340. http://kernel.org/ > 341. http://kernel.org/ > 342. mailto:Xen-devel@lists.xen.org > 343. http://lists.xen.org/xen-devel > 344. mailto:pasik@iki.fi > 345. mailto:pasik@iki.fi > 346. mailto:pasik@iki.fi > 347. http://kernel.org/ > 348. http://kernel.org/ > 349. mailto:Xen-devel@lists.xen.org > 350. http://lists.xen.org/xen-devel > 351. mailto:pasik@iki.fi > 352. http://kernel.org/ > 353. http://kernel.org/ > 354. mailto:Xen-devel@lists.xen.org > 355. http://lists.xen.org/xen-devel > 356. mailto:pasik@iki.fi > 357. mailto:pasik@iki.fi > 358. http://kernel.org/ > 359. http://kernel.org/ > 360. mailto:Xen-devel@lists.xen.org > 361. http://lists.xen.org/xen-devel > 362. mailto:pasik@iki.fi > 363. http://kernel.org/ > 364. http://kernel.org/ > 365. mailto:Xen-devel@lists.xen.org > 366. http://lists.xen.org/xen-devel > 367. mailto:pasik@iki.fi > 368. mailto:pasik@iki.fi > 369. mailto:pasik@iki.fi > 370. mailto:pasik@iki.fi > 371. http://kernel.org/ > 372. http://kernel.org/ > 373. mailto:Xen-devel@lists.xen.org > 374. http://lists.xen.org/xen-devel > 375. mailto:pasik@iki.fi > 376. http://kernel.org/ > 377. http://kernel.org/ > 378. mailto:Xen-devel@lists.xen.org > 379. http://lists.xen.org/xen-devel > 380. mailto:pasik@iki.fi > 381. mailto:pasik@iki.fi > 382. http://kernel.org/ > 383. http://kernel.org/ > 384. mailto:Xen-devel@lists.xen.org > 385. http://lists.xen.org/xen-devel > 386. mailto:pasik@iki.fi > 387. http://kernel.org/ > 388. http://kernel.org/ > 389. mailto:Xen-devel@lists.xen.org > 390. http://lists.xen.org/xen-devel > 391. mailto:pasik@iki.fi > 392. mailto:pasik@iki.fi > 393. mailto:pasik@iki.fi > 394. http://kernel.org/ > 395. http://kernel.org/ > 396. mailto:Xen-devel@lists.xen.org > 397. http://lists.xen.org/xen-devel > 398. mailto:pasik@iki.fi > 399. http://kernel.org/ > 400. http://kernel.org/ > 401. mailto:Xen-devel@lists.xen.org > 402. http://lists.xen.org/xen-devel > 403. mailto:pasik@iki.fi > 404. mailto:pasik@iki.fi > 405. http://kernel.org/ > 406. http://kernel.org/ > 407. mailto:Xen-devel@lists.xen.org > 408. http://lists.xen.org/xen-devel > 409. mailto:pasik@iki.fi > 410. http://kernel.org/ > 411. http://kernel.org/ > 412. mailto:Xen-devel@lists.xen.org > 413. http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 13:55:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 13:55:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ2w6-0003eK-T1; Tue, 02 Oct 2012 13:54:58 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ2w6-0003dk-0N for xen-devel@lists.xen.org; Tue, 02 Oct 2012 13:54:58 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1349186091!7076376!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29051 invoked from network); 2 Oct 2012 13:54:51 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 13:54:51 -0000 X-IronPort-AV: E=Sophos;i="4.80,523,1344211200"; d="scan'208";a="14894632" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 13:54:29 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 14:54:29 +0100 Message-ID: <1349186068.650.64.camel@zakaz.uk.xensource.com> From: Ian Campbell To: George Dunlap Date: Tue, 2 Oct 2012 14:54:28 +0100 In-Reply-To: References: <1348765860-11359-1-git-send-email-matthew.fioravante@jhuapl.edu> <1348765860-11359-3-git-send-email-matthew.fioravante@jhuapl.edu> <5065CAE9.30602@jhuapl.edu> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: Matthew Fioravante , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 11/11] add vtpm support to libxl X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-09-28 at 17:39 +0100, George Dunlap wrote: > >>> @@ -1084,13 +1090,13 @@ static void domcreate_devmodel_started(libxl__egc *egc, > >>> if (d_config->num_nics > 0) { > >>> /* Attach nics */ > >>> libxl__multidev_begin(ao, &dcs->multidev); > >>> - dcs->multidev.callback = domcreate_attach_pci; > >>> + dcs->multidev.callback = domcreate_attach_vtpms; > >> Wow -- what a weird convention you've had to try to figure out and > >> modify here. Well done. :-) > > It was really tricky. Is there no better way to handle asynchronous > > code? This method seems really error prone and almost impossible to follow. > > Well I didn't write it. :-) I haven't taken the time to figure out > why it might have been written that way; but at first glance, I tend > to agree with you. For about 10 minutes I was convinced you had made > some kind of weird error, by sprinkling "vtpm" around things that > obviously were supposed to be about nics and pci devices, until I > realized you were just following the existing "call chain" convention. One big improvement would be to stop treating the preamble of "do_bar" as the error handling of the preceding "do_foo", in the case where bar happens to follow foo in the async chain. For example nic attach's completion handler should be called domcreate_nicattach_done, which then calls the next step instead of putting the nic error handling at the front of domcreate_attach_pci because that happens to be the next call in the chain. It's not quite ideal but it would be substantially less confusing. If there was further some way to make the what to call next step table driven then even better. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 13:55:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 13:55:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ2w6-0003eK-T1; Tue, 02 Oct 2012 13:54:58 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ2w6-0003dk-0N for xen-devel@lists.xen.org; Tue, 02 Oct 2012 13:54:58 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1349186091!7076376!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29051 invoked from network); 2 Oct 2012 13:54:51 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 13:54:51 -0000 X-IronPort-AV: E=Sophos;i="4.80,523,1344211200"; d="scan'208";a="14894632" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 13:54:29 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 14:54:29 +0100 Message-ID: <1349186068.650.64.camel@zakaz.uk.xensource.com> From: Ian Campbell To: George Dunlap Date: Tue, 2 Oct 2012 14:54:28 +0100 In-Reply-To: References: <1348765860-11359-1-git-send-email-matthew.fioravante@jhuapl.edu> <1348765860-11359-3-git-send-email-matthew.fioravante@jhuapl.edu> <5065CAE9.30602@jhuapl.edu> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: Matthew Fioravante , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 11/11] add vtpm support to libxl X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-09-28 at 17:39 +0100, George Dunlap wrote: > >>> @@ -1084,13 +1090,13 @@ static void domcreate_devmodel_started(libxl__egc *egc, > >>> if (d_config->num_nics > 0) { > >>> /* Attach nics */ > >>> libxl__multidev_begin(ao, &dcs->multidev); > >>> - dcs->multidev.callback = domcreate_attach_pci; > >>> + dcs->multidev.callback = domcreate_attach_vtpms; > >> Wow -- what a weird convention you've had to try to figure out and > >> modify here. Well done. :-) > > It was really tricky. Is there no better way to handle asynchronous > > code? This method seems really error prone and almost impossible to follow. > > Well I didn't write it. :-) I haven't taken the time to figure out > why it might have been written that way; but at first glance, I tend > to agree with you. For about 10 minutes I was convinced you had made > some kind of weird error, by sprinkling "vtpm" around things that > obviously were supposed to be about nics and pci devices, until I > realized you were just following the existing "call chain" convention. One big improvement would be to stop treating the preamble of "do_bar" as the error handling of the preceding "do_foo", in the case where bar happens to follow foo in the async chain. For example nic attach's completion handler should be called domcreate_nicattach_done, which then calls the next step instead of putting the nic error handling at the front of domcreate_attach_pci because that happens to be the next call in the chain. It's not quite ideal but it would be substantially less confusing. If there was further some way to make the what to call next step table driven then even better. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 14:02:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:02:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ33H-00044M-SC; Tue, 02 Oct 2012 14:02:23 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ33G-00044H-AM for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 14:02:22 +0000 Received: from [85.158.143.35:11038] by server-3.bemta-4.messagelabs.com id A0/DD-10986-DE3FA605; Tue, 02 Oct 2012 14:02:21 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1349186540!13592157!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15141 invoked from network); 2 Oct 2012 14:02:21 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 14:02:21 -0000 X-IronPort-AV: E=Sophos;i="4.80,523,1344211200"; d="scan'208";a="14894930" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 14:02:20 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 15:02:19 +0100 Message-ID: <1349186538.650.69.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Sander Eikelenboom Date: Tue, 2 Oct 2012 15:02:18 +0100 In-Reply-To: <158082007.20120927221137@eikelenboom.it> References: <1348565712.3452.141.camel@zakaz.uk.xensource.com> <15210025463.20120925171143@eikelenboom.it> <1348586949.12592.10.camel@zakaz.uk.xensource.com> <158082007.20120927221137@eikelenboom.it> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Ian Jackson Subject: Re: [Xen-devel] [PATCH 0 of 3] xl and hotplug: Introduce and use shutdown and reboot xm compatibility options X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org T24gVGh1LCAyMDEyLTA5LTI3IGF0IDIxOjExICswMTAwLCBTYW5kZXIgRWlrZWxlbmJvb20gd3Jv dGU6Cj4gVHVlc2RheSwgU2VwdGVtYmVyIDI1LCAyMDEyLCA1OjI5OjA5IFBNLCB5b3Ugd3JvdGU6 Cj4gCj4gPiBPbiBUdWUsIDIwMTItMDktMjUgYXQgMTY6MTEgKzAxMDAsIFNhbmRlciBFaWtlbGVu Ym9vbSB3cm90ZToKPiAKPiA+PiBUaGUgb25seSByZWxhdGl2ZSBzaW1wbGUgaW1wbGVtZW50YXRp b24gaSB0aG91Z2h0IG9mIHdhcyBkaXJlY3QKPiA+PiBzaHV0dGluZyBkb3duIGFsbCwgYW5kIHdo ZW4gdGhlIC13IHBhcmFtZXRlciB3YXMgc2V0LCBqdXN0IGxvb3AgYW5kCj4gPj4gd2FpdCBvbiBl dmVudHMgdW50aWwgdGhlIG9ubHkgcnVubmluZyBkb21haW4gaXMgZG9tYWluLTAuCj4gPj4gQWx0 aG91Z2ggdGhpcyBleGFjdGx5IGRvZXMgd2hhdCBoYXMgdG8gYmUgZG9uZSwgaXQgc29tZWhvdyBz b3VuZHMgYQo+ID4+IGJpdCBkaXJ0eS4KPiAKPiA+IEkgdGhpbmsgeW91IGNhbiBhbGxvY2F0ZSBh biBhcnJheSBvZiBsaWJ4bF9ldmVuYWJsZV9kb21haW5fZGVhdGgqLCBvZgo+ID4gbnJfZG9tcyBp biBzaXplIGFuZCB0aGVuIGFzIHlvdSBzaHV0ZG93biBlYWNoIGRvbWFpbiBjYWxsCj4gPiBsaWJ4 bF9ldmVuYWJsZV9kb21haW5fZGVhdGggZm9yIGl0IHRvby4KPiAKPiA+IFRoZW4geW91IGxvb3Ag d2FpdGluZyBmb3IgZGVzdHJveSBldmVudHMsIGNhbGxpbmcKPiA+IGxpYnhsX2V2ZGlzYWJsZV9k b21haW5fZGVhdGggYXMgZWFjaCBkb21haW4gZGllcywgd2hpbGUgY291bnRpbmcgYmFjawo+ID4g ZnJvbSBucl9kb21zIHVudGlsIDAuIFdoZW4gaXQgcmVhY2hlcyAwIGV2ZXJ5dGhpbmcgeW91IGFz a2VkIGZvciBoYXMKPiA+IGJlZW4gc2h1dGRvd24uCj4gCj4gPiBPciBzb21ldGhpbmcgbGlrZSB0 aGF0LCBJJ3ZlIG5vdCBhY3R1YWxseSBpbXBsZW1lbnRlZCBpdCA7LSkKPiAKPiA+IElhbi4KPiAK PiBJdCdzIHRpbWUgdG8gY2FsbCBkZWZlYXQsIHdpdGhvdXQgcHJvcGVyIEMgc2tpbGxzIGl0IHNl ZW1zIGEgYml0IHRvbwo+IGhhcmQgdG8gZmlndXJlIGl0IG91dC4KClRoYXQncyBvaywgSSdsbCBh ZGQgaXQgdG8gbXkgVE9ETyB0byBwaWNrdXAgd2hlcmUgeW91IGxlZnQgb2ZmICh1bmxlc3MKc29t ZW9uZSBiZWF0cyBtZSB0byBpdCkuCgpUaGFua3MgZm9yIHRha2luZyBpdCB0aGlzIGZhciEgRldJ VyB5b3Ugc2VlbWVkIHRvIGJlIHByZXR0eSBjbG9zZS4KCj4gQ2FuJ3Qgc2VlbSB0byBnZXQgdGhl IGhhbmcgb2YgaG93IHRvIGtlZXAgYSByZWZlcmVuY2UgdG8KPiBsaWJ4bF9ldmdlbl9kb21haW5f ZGVhdGggYW5kIHVzZSBpdCB0byBjaGVjayBpZiB0aGUgZG9taWQgb2YgdGhlIGV2ZW50Cj4gaXMg dGhlIHNhbWUgYXMgdGhhdCBmcm9tIGEgZG9tYWluIHdlIGFyZSB3YWl0aW5nIHRvIHNodXRkb3du Lgo+IFRoZSByZXN0IG9mIHRoZSBjb2RlIGRvZXNuJ3QgZ2l2ZSBtZSBtdWNoIHBvaW50ZXJzIHNp bmNlIGFsbCBjb21tYW5kcwo+IHNlZW0gdG8gb3BlcmF0ZSBvbiBhIHNpbmdsZSBkb21pZCBhdCBv bmNlLgo+IAo+IFRoZSBjb25jb2N0aW9uIGJlbG93IGxlYWRzIHRvOgo+IHhsX2NtZGltcGwuYzog SW4gZnVuY3Rpb24gw6JzaHV0ZG93bl9kb21haW7DojoKPiB4bF9jbWRpbXBsLmM6Mjc2NjogZXJy b3I6IGRlcmVmZXJlbmNpbmcgcG9pbnRlciB0byBpbmNvbXBsZXRlIHR5cGUKCkluIGNhc2UgeW91 IGFyZSBpbnRlcmVzdGVkIHRoaXMgaXMgYmVjYXVzZSB0aGUgbGlieGxfZXZnZW5fZG9tYWluX2Rl YXRoCnR5cGUgaXMgb3BhcXVlIHRvIHVzZXJzIG9mIGxpYnhsIHNvIGNvbnN0cnVjdHMgbGlrZQpk b21haW5zX3dhaXRfc2h1dGRvd25baV0tPmRvbWlkIGFyZSBub3QgcG9zc2libGUuCgpUaGUgYW5z d2VyIGlzIHRvIHVzZSB0aGUgM3JkIGFyZ3VtZW50IHRvIGxpYnhsX2V2ZW5hYmxlX2RvbWFpbl9k ZWF0aAoodGhlIG9uZSBvZiB0eXBlIGxpYnhsX2V2X3VzZXIpIHRvIHBhc3MgYSAiY2xvc3VyZSIs IHRoaXMgdmFsdWUgaXMKcmV0dXJuZWQgaW4gdGhlIGV2ZW50J3MgImZvcl91c2VyIiBmaWVsZC4g VGhlIGFwcGxpY2F0aW9uIGNhbiB1c2UgdGhpcwp0byBzdG9yZSBkYXRhIHNwZWNpZmljIHRvIHRo aXMgcGFydGljdWxhciBldmVudCAtLSBpbiB0aGlzIGNhc2UgaXQgd291bGQKcHJvYmFibHkgYmUg c3VmZmljaWVudCB0byBqdXN0IHBhc3MgdGhlIGRvbWlkIGhlcmUgYnV0IGluIHByaW5jaXBhbCBv bmUKY291bGQgcGFzcyBhIHBvaW50ZXIgdG8gYW55IGRhdGFzdHJ1Y3R1cmUuCgpUaGFua3MgYWdh aW4sCklhbi4KCj4gCj4gCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIHRvb2xzL2xpYnhs L3hsX2NtZGltcGwuYyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiBpbmRleCAxNjI3Y2Fj Li5iOTAwODExIDEwMDY0NAo+IEBAIC0yNjg0LDY3ICsyNjg0LDk4IEBAIHN0YXRpYyB2b2lkIGRl c3Ryb3lfZG9tYWluKHVpbnQzMl90IGRvbWlkKQo+ICAgICAgfQo+ICAgICAgcmMgPSBsaWJ4bF9k b21haW5fZGVzdHJveShjdHgsIGRvbWlkLCAwKTsKPiAgICAgIGlmIChyYykgeyBmcHJpbnRmKHN0 ZGVyciwiZGVzdHJveSBmYWlsZWQgKHJjPSVkKVxuIixyYyk7IGV4aXQoLTEpOyB9Cj4gIH0KPiAg Cj4gLXN0YXRpYyB2b2lkIHNodXRkb3duX2RvbWFpbih1aW50MzJfdCBkb21pZCwgaW50IHdhaXRf Zm9yX2l0LAo+IC0gICAgICAgICAgICAgICAgICAgICAgICAgICAgaW50IGZhbGxiYWNrX3RyaWdn ZXIpCj4gK3N0YXRpYyBpbnQgc2h1dGRvd25fZG9tYWluKGNvbnN0IGxpYnhsX2RvbWluZm8gKmRv bWluZm8sIGludCBuYl9kb21haW4sCj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbnQg d2FpdF9mb3JfaXQsIGludCBmYWxsYmFja190cmlnZ2VyKQo+ICB7Cj4gLSAgICBpbnQgcmM7Cj4g LSAgICBsaWJ4bF9ldmVudCAqZXZlbnQ7Cj4gKyAgICBpbnQgaSwgcmMsIG5iX3NodXRkb3duX3Bl bmRpbmc7Cj4gKyAgICBpbnQgcmV0ID0gMDsKPiArICAgIGxpYnhsX2V2Z2VuX2RvbWFpbl9kZWF0 aCAqZG9tYWluc193YWl0X3NodXRkb3duW25iX2RvbWFpbl07Cj4gKyAgICAgICAKPiArICAgIGZv ciAoaSA9IDA7IGkgPCBuYl9kb21haW47IGkrKykgewo+ICsgICAgICAgIHVpbnQzMl90IGRvbWlk ID0gZG9taW5mb1tpXS5kb21pZDsKPiArICAgICAgICBpZighbGlieGxfZG9taWRfdmFsaWRfZ3Vl c3QoZG9taWQpKQo+ICsgICAgICAgICAgICBjb250aW51ZTsKPiAgCj4gLSAgICByYz1saWJ4bF9k b21haW5fc2h1dGRvd24oY3R4LCBkb21pZCk7Cj4gLSAgICBpZiAocmMgPT0gRVJST1JfTk9QQVJB VklSVCkgewo+IC0gICAgICAgIGlmIChmYWxsYmFja190cmlnZ2VyKSB7Cj4gLSAgICAgICAgICAg IGZwcmludGYoc3RkZXJyLCAiUFYgY29udHJvbCBpbnRlcmZhY2Ugbm90IGF2YWlsYWJsZToiCj4g LSAgICAgICAgICAgICAgICAgICAgIiBzZW5kaW5nIEFDUEkgcG93ZXIgYnV0dG9uIGV2ZW50Llxu Iik7Cj4gLSAgICAgICAgICAgIHJjID0gbGlieGxfc2VuZF90cmlnZ2VyKGN0eCwgZG9taWQsIExJ QlhMX1RSSUdHRVJfUE9XRVIsIDApOwo+IC0gICAgICAgIH0gZWxzZSB7Cj4gLSAgICAgICAgICAg IGZwcmludGYoc3RkZXJyLCAiUFYgY29udHJvbCBpbnRlcmZhY2Ugbm90IGF2YWlsYWJsZToiCj4g LSAgICAgICAgICAgICAgICAgICAgIiBleHRlcm5hbCBncmFjZWZ1bCBzaHV0ZG93biBub3QgcG9z c2libGUuXG4iKTsKPiAtICAgICAgICAgICAgZnByaW50ZihzdGRlcnIsICJVc2UgXCItRlwiIHRv IGZhbGxiYWNrIHRvIEFDUEkgcG93ZXIgZXZlbnQuXG4iKTsKPiArICAgICAgICByYyA9IGxpYnhs X2RvbWFpbl9zaHV0ZG93bihjdHgsIGRvbWlkKTsKPiArCj4gKyAgICAgICAgaWYgKHJjID09IEVS Uk9SX05PUEFSQVZJUlQpIHsKPiArICAgICAgICAgICAgaWYgKGZhbGxiYWNrX3RyaWdnZXIpIHsK PiArICAgICAgICAgICAgICAgIGZwcmludGYoc3RkZXJyLCAiUFYgY29udHJvbCBpbnRlcmZhY2Ug bm90IGF2YWlsYWJsZToiCj4gKyAgICAgICAgICAgICAgICAgICAgICAgICIgc2VuZGluZyBBQ1BJ IHBvd2VyIGJ1dHRvbiBldmVudC5cbiIpOwo+ICsgICAgICAgICAgICAgICAgcmMgPSBsaWJ4bF9z ZW5kX3RyaWdnZXIoY3R4LCBkb21pZCwgTElCWExfVFJJR0dFUl9QT1dFUiwgMCk7Cj4gKyAgICAg ICAgICAgIH0gZWxzZSB7Cj4gKyAgICAgICAgICAgICAgICBmcHJpbnRmKHN0ZGVyciwgIlBWIGNv bnRyb2wgaW50ZXJmYWNlIG5vdCBhdmFpbGFibGU6Igo+ICsgICAgICAgICAgICAgICAgICAgICAg ICAiIGV4dGVybmFsIGdyYWNlZnVsIHNodXRkb3duIG5vdCBwb3NzaWJsZS5cbiIpOwo+ICsgICAg ICAgICAgICAgICAgZnByaW50ZihzdGRlcnIsCj4gKyAgICAgICAgICAgICAgICAgICAgIlVzZSBc Ii1GXCIgdG8gZmFsbGJhY2sgdG8gQUNQSSBwb3dlciBldmVudC5cbiIpOwo+ICsgICAgICAgICAg ICB9Cj4gKyAgICAgICAgfQo+ICsgICAgICAgIAo+ICsgICAgICAgIGlmIChyYykgewo+ICsgICAg ICAgICAgICBmcHJpbnRmKHN0ZGVyciwic2h1dGRvd24gb2YgZG9tYWluICVkIGZhaWxlZCAocmM9 JWQpXG4iLCBkb21pZCwgcmMpOwo+ICsgICAgICAgICAgICByZXQgPSAtMTsKPiArICAgICAgICAg ICAgY29udGludWU7Cj4gKyAgICAgICAgfQo+ICsKPiArICAgICAgICBpZiAod2FpdF9mb3JfaXQp IHsKPiArICAgICAgICAgICAgcmMgPSBsaWJ4bF9ldmVuYWJsZV9kb21haW5fZGVhdGgoY3R4LCBk b21pZCwgMCwgJmRvbWFpbnNfd2FpdF9zaHV0ZG93bltpXSk7Cj4gKyAgICAgICAgICAgIGlmIChy Yykgewo+ICsgICAgICAgICAgICAgICAgZnByaW50ZihzdGRlcnIsIndhaXQgZm9yIGRlYXRoIG9m IGRvbWFpbiAlZCBmYWlsZWQiCj4gKyAgICAgICAgICAgICAgICAgICAgIiAoZXZnZW4sIHJjPSVk KVxuIiwgZG9taWQsIHJjKTsKPiArICAgICAgICAgICAgICAgIHJldCA9IC0xOwo+ICsgICAgICAg ICAgICB9IGVsc2Ugewo+ICsgICAgICAgICAgICAgICAgbmJfc2h1dGRvd25fcGVuZGluZysrOwo+ ICsgICAgICAgICAgICB9IAo+ICAgICAgICAgIH0KPiAtICAgIH0KPiAtICAgIGlmIChyYykgewo+ IC0gICAgICAgIGZwcmludGYoc3RkZXJyLCJzaHV0ZG93biBmYWlsZWQgKHJjPSVkKVxuIixyYyk7 ZXhpdCgtMSk7Cj4gICAgICB9Cj4gIAo+ICAgICAgaWYgKHdhaXRfZm9yX2l0KSB7Cj4gLSAgICAg ICAgbGlieGxfZXZnZW5fZG9tYWluX2RlYXRoICpkZWF0aHc7Cj4gKyAgICAgICAgd2hpbGUgKG5i X3NodXRkb3duX3BlbmRpbmcgPiAwKSB7Cj4gKyAgICAgICAgICAgIGxpYnhsX2V2ZW50ICpldmVu dDsKPiArICAgICAgICAgICAgcmMgPSBsaWJ4bF9ldmVudF93YWl0KGN0eCwgJmV2ZW50LCBMSUJY TF9FVkVOVE1BU0tfQUxMLCAwLDApOwo+ICsgICAgICAgICAgICBpZiAocmMpIHsKPiArICAgICAg ICAgICAgICAgIExPRygiRmFpbGVkIHRvIGdldCBldmVudCAocmM9JWQpIiwgcmMpOwo+ICsgICAg ICAgICAgICAgICAgcmV0dXJuIC0xOwo+ICsgICAgICAgICAgICB9Cj4gIAo+IC0gICAgICAgIHJj ID0gbGlieGxfZXZlbmFibGVfZG9tYWluX2RlYXRoKGN0eCwgZG9taWQsIDAsICZkZWF0aHcpOwo+ IC0gICAgICAgIGlmIChyYykgewo+IC0gICAgICAgICAgICBmcHJpbnRmKHN0ZGVyciwid2FpdCBm b3IgZGVhdGggZmFpbGVkIChldmdlbiwgcmM9JWQpXG4iLHJjKTsKPiAtICAgICAgICAgICAgZXhp dCgtMSk7Cj4gLSAgICAgICAgfQo+ICsgICAgICAgICAgICB1aW50MzJfdCBldmVudF9kb21pZCA9 IGV2ZW50LT5kb21pZDsKPiArICAgICAgICAgICAgc3dpdGNoIChldmVudC0+dHlwZSkgewo+ICAK PiAtICAgICAgICBmb3IgKDs7KSB7Cj4gLSAgICAgICAgICAgIHJjID0gZG9tYWluX3dhaXRfZXZl bnQoZG9taWQsICZldmVudCk7Cj4gLSAgICAgICAgICAgIGlmIChyYykgZXhpdCgtMSk7Cj4gKyAg ICAgICAgICAgICAgICBjYXNlIExJQlhMX0VWRU5UX1RZUEVfRE9NQUlOX0RFQVRIOgo+ICsgICAg ICAgICAgICAgICAgICAgIExPRygiRG9tYWluICVkIGhhcyBiZWVuIGRlc3Ryb3llZCIsIGV2ZW50 X2RvbWlkKTsKPiArICAgICAgICAgICAgICAgICAgICBicmVhazsKPiAgCj4gLSAgICAgICAgICAg IHN3aXRjaCAoZXZlbnQtPnR5cGUpIHsKPiArICAgICAgICAgICAgICAgIGNhc2UgTElCWExfRVZF TlRfVFlQRV9ET01BSU5fU0hVVERPV046Cj4gKyAgICAgICAgICAgICAgICAgICAgTE9HKCJEb21h aW4gJWQgaGFzIGJlZW4gc2h1dCBkb3duLCByZWFzb24gY29kZSAlZCAleCIsCj4gKyAgICAgICAg ICAgICAgICAgICAgICAgIGV2ZW50X2RvbWlkLAo+ICsgICAgICAgICAgICAgICAgICAgICAgICBl dmVudC0+dS5kb21haW5fc2h1dGRvd24uc2h1dGRvd25fcmVhc29uLAo+ICsgICAgICAgICAgICAg ICAgICAgICAgICBldmVudC0+dS5kb21haW5fc2h1dGRvd24uc2h1dGRvd25fcmVhc29uKTsKPiAr ICAgICAgICAgICAgICAgICAgICBicmVhazsKPiAgCj4gLSAgICAgICAgICAgIGNhc2UgTElCWExf RVZFTlRfVFlQRV9ET01BSU5fREVBVEg6Cj4gLSAgICAgICAgICAgICAgICBMT0coIkRvbWFpbiAl ZCBoYXMgYmVlbiBkZXN0cm95ZWQiLCBkb21pZCk7Cj4gLSAgICAgICAgICAgICAgICBnb3RvIGRv bmU7Cj4gKyAgICAgICAgICAgICAgICBkZWZhdWx0Ogo+ICsgICAgICAgICAgICAgICAgICAgIGNv bnRpbnVlOwo+ICsgICAgICAgICAgICAgICAgICAgIGJyZWFrOwo+ICsgICAgICAgICAgICB9Cj4g IAo+IC0gICAgICAgICAgICBjYXNlIExJQlhMX0VWRU5UX1RZUEVfRE9NQUlOX1NIVVRET1dOOgo+ IC0gICAgICAgICAgICAgICAgTE9HKCJEb21haW4gJWQgaGFzIGJlZW4gc2h1dCBkb3duLCByZWFz b24gY29kZSAlZCAleCIsIGRvbWlkLAo+IC0gICAgICAgICAgICAgICAgICAgIGV2ZW50LT51LmRv bWFpbl9zaHV0ZG93bi5zaHV0ZG93bl9yZWFzb24sCj4gLSAgICAgICAgICAgICAgICAgICAgZXZl bnQtPnUuZG9tYWluX3NodXRkb3duLnNodXRkb3duX3JlYXNvbik7Cj4gLSAgICAgICAgICAgICAg ICBnb3RvIGRvbmU7Cj4gKyAgICAgICAgICAgIGZvciAoaSA9IDA7IGkgPCBuYl9kb21haW47IGkr Kykgewo+ICsgICAgICAgICAgICAgICAgaWYgKCFkb21haW5zX3dhaXRfc2h1dGRvd25baV0pCj4g KyAgICAgICAgICAgICAgICAgICAgY29udGludWU7Cj4gIAo+IC0gICAgICAgICAgICBkZWZhdWx0 Ogo+IC0gICAgICAgICAgICAgICAgTE9HKCJVbmV4cGVjdGVkIGV2ZW50IHR5cGUgJWQiLCBldmVu dC0+dHlwZSk7Cj4gLSAgICAgICAgICAgICAgICBicmVhazsKPiArICAgICAgICAgICAgICAgIGlm IChkb21haW5zX3dhaXRfc2h1dGRvd25baV0tPmRvbWlkID09IGV2ZW50X2RvbWlkKXsKPiArICAg ICAgICAgICAgICAgICAgICBsaWJ4bF9ldmRpc2FibGVfZG9tYWluX2RlYXRoKGN0eCwgZG9tYWlu c193YWl0X3NodXRkb3duW2ldKTsKPiArICAgICAgICAgICAgICAgICAgICBkb21haW5zX3dhaXRf c2h1dGRvd25baV0gPSBOVUxMOwo+ICsgICAgICAgICAgICAgICAgICAgIG5iX3NodXRkb3duX3Bl bmRpbmctLTsKPiArICAgICAgICAgICAgICAgIH0KPiAgICAgICAgICAgICAgfQo+ICAgICAgICAg ICAgICBsaWJ4bF9ldmVudF9mcmVlKGN0eCwgZXZlbnQpOwo+ICAgICAgICAgIH0KPiAtICAgIGRv bmU6Cj4gLSAgICAgICAgbGlieGxfZXZlbnRfZnJlZShjdHgsIGV2ZW50KTsKPiAtICAgICAgICBs aWJ4bF9ldmRpc2FibGVfZG9tYWluX2RlYXRoKGN0eCwgZGVhdGh3KTsKPiAgICAgIH0KPiArCj4g KyAgICByZXR1cm4gcmV0Owo+ICB9Cj4gIAo+ICBzdGF0aWMgdm9pZCByZWJvb3RfZG9tYWluKHVp bnQzMl90IGRvbWlkLCBpbnQgZmFsbGJhY2tfdHJpZ2dlcikKPiAgewo+ICAgICAgaW50IHJjOwo+ IEBAIC0zNjc0LDI5ICszNzA1LDgyIEBAIGludCBtYWluX2Rlc3Ryb3koaW50IGFyZ2MsIGNoYXIg Kiphcmd2KQo+ICAgICAgcmV0dXJuIDA7Cj4gIH0KPiAgCj4gIGludCBtYWluX3NodXRkb3duKGlu dCBhcmdjLCBjaGFyICoqYXJndikKPiAgewo+ICsgICAgbGlieGxfZG9taW5mbyBkb21pbmZvX2J1 ZjsKPiArICAgIGxpYnhsX2RvbWluZm8gKmRvbWluZm8sICpkb21pbmZvX2ZyZWUgPSBOVUxMOwo+ ICsgICAgaW50IG5iX2RvbWFpbiwgcmM7Cj4gICAgICBpbnQgb3B0Owo+ICsgICAgaW50IG9wdGlv bl9pbmRleCA9IDA7Cj4gKyAgICBpbnQgYWxsID0gMDsKPiAgICAgIGludCB3YWl0X2Zvcl9pdCA9 IDA7Cj4gICAgICBpbnQgZmFsbGJhY2tfdHJpZ2dlciA9IDA7Cj4gKyAgICBzdGF0aWMgc3RydWN0 IG9wdGlvbiBsb25nX29wdGlvbnNbXSA9IHsKPiArICAgICAgICB7ImFsbCIsIDAsIDAsICdhJ30s Cj4gKyAgICAgICAgeyJ3YWl0IiwgMCwgMCwgJ3cnfSwKPiArICAgICAgICB7MCwgMCwgMCwgMH0K PiArICAgIH07Cj4gIAo+IC0gICAgd2hpbGUgKChvcHQgPSBkZWZfZ2V0b3B0KGFyZ2MsIGFyZ3Ys ICJ3RiIsICJzaHV0ZG93biIsIDEpKSAhPSAtMSkgewo+ICsgICAgd2hpbGUgKChvcHQgPSBnZXRv cHRfbG9uZyhhcmdjLCBhcmd2LCAiYXdGIiwgbG9uZ19vcHRpb25zLCAmb3B0aW9uX2luZGV4KSkg IT0gLTEpIHsKPiAgICAgICAgICBzd2l0Y2ggKG9wdCkgewo+ICAgICAgICAgIGNhc2UgMDogY2Fz ZSAyOgo+ICAgICAgICAgICAgICByZXR1cm4gb3B0Owo+ICsgICAgICAgIGNhc2UgJ2EnOgo+ICsg ICAgICAgICAgICBhbGwgPSAxOwo+ICsgICAgICAgICAgICBicmVhazsKPiAgICAgICAgICBjYXNl ICd3JzoKPiAgICAgICAgICAgICAgd2FpdF9mb3JfaXQgPSAxOwo+ICAgICAgICAgICAgICBicmVh azsKPiAgICAgICAgICBjYXNlICdGJzoKPiAgICAgICAgICAgICAgZmFsbGJhY2tfdHJpZ2dlciA9 IDE7Cj4gICAgICAgICAgICAgIGJyZWFrOwo+ICAgICAgICAgIH0KPiAgICAgIH0KPiAgCj4gLSAg ICBzaHV0ZG93bl9kb21haW4oZmluZF9kb21haW4oYXJndltvcHRpbmRdKSwgd2FpdF9mb3JfaXQs IGZhbGxiYWNrX3RyaWdnZXIpOwo+IC0gICAgcmV0dXJuIDA7Cj4gKyAgICBpZiAoIWFyZ3Zbb3B0 aW5kXSAmJiAhYWxsKSB7Cj4gKyAgICAgICAgZnByaW50ZihzdGRlcnIsICJZb3UgbXVzdCBzcGVj aWZ5IC1hIG9yIGEgdmFsaWQgZG9tYWluIGlkLlxuXG4iKTsKPiArICAgICAgICByZXR1cm4gb3B0 Owo+ICsgICAgfQo+ICsKPiArICAgIGlmIChhbGwpIHsKPiArICAgICAgICBkb21pbmZvID0gbGli eGxfbGlzdF9kb21haW4oY3R4LCAmbmJfZG9tYWluKTsKPiArICAgICAgICBpZiAoIWRvbWluZm8p IHsKPiArICAgICAgICAgICAgZnByaW50ZihzdGRlcnIsICJsaWJ4bF9kb21haW5faW5mb2xpc3Qg ZmFpbGVkLlxuIik7Cj4gKyAgICAgICAgICAgIHJldHVybiAtMTsKPiArICAgICAgICB9Cj4gKyAg ICAgICAgZG9taW5mb19mcmVlID0gZG9taW5mbzsKPiArICAgIH0gZWxzZSB7Cj4gKyAgICAgICAg dWludDMyX3QgZG9taWQgPSBmaW5kX2RvbWFpbihhcmd2W29wdGluZF0pOwo+ICsgICAgICAgIGlm IChkb21pZCA9PSAwKSB7Cj4gKyAgICAgICAgICAgIGZwcmludGYoc3RkZXJyLCAiRXJyb3I6IERv bWFpbi0wIGNhbid0IGJlIHNodXRkb3duIGJ5IHRoaXMgY29tbWFuZFxuIik7Cj4gKyAgICAgICAg ICAgIHJldHVybiAtMTsKPiArICAgICAgICB9Cj4gKwo+ICsgICAgICAgIHJjID0gbGlieGxfZG9t YWluX2luZm8oY3R4LCAmZG9taW5mb19idWYsIGRvbWlkKTsKPiArCj4gKyAgICAgICAgaWYgKHJj ID09IEVSUk9SX0lOVkFMKSB7Cj4gKyAgICAgICAgICAgIGZwcmludGYoc3RkZXJyLCAiRXJyb3I6 IERvbWFpbiBcJyVzXCcgZG9lcyBub3QgZXhpc3QuXG4iLAo+ICsgICAgICAgICAgICAgICAgYXJn dltvcHRpbmRdKTsKPiArICAgICAgICAgICAgcmV0dXJuIC1yYzsKPiArICAgICAgICB9Cj4gKyAg ICAgICAgaWYgKHJjKSB7Cj4gKyAgICAgICAgICAgIGZwcmludGYoc3RkZXJyLCAibGlieGxfZG9t YWluX2luZm8gZmFpbGVkIChjb2RlICVkKS5cbiIsIHJjKTsKPiArICAgICAgICAgICAgcmV0dXJu IC1yYzsKPiArICAgICAgICB9Cj4gKyAgICAgICAgZG9taW5mbyA9ICZkb21pbmZvX2J1ZjsKPiAr ICAgICAgICBuYl9kb21haW4gPSAxOwo+ICsgICAgfQo+ICsKPiArICAgIHJjID0gc2h1dGRvd25f ZG9tYWluKGRvbWluZm8sIG5iX2RvbWFpbiwgd2FpdF9mb3JfaXQsIGZhbGxiYWNrX3RyaWdnZXIp Owo+ICsKPiArICAgIGlmIChkb21pbmZvX2ZyZWUpCj4gKyAgICAgICAgbGlieGxfZG9taW5mb19s aXN0X2ZyZWUoZG9taW5mb19mcmVlLCBuYl9kb21haW4pOwo+ICsgICAgZWxzZQo+ICsgICAgICAg IGxpYnhsX2RvbWluZm9fZGlzcG9zZShkb21pbmZvKTsKPiArCj4gKyAgICByZXR1cm4gLXJjOwo+ ICB9Cj4gIAo+ICBpbnQgbWFpbl9yZWJvb3QoaW50IGFyZ2MsIGNoYXIgKiphcmd2KQo+ICB7Cj4g ICAgICBpbnQgb3B0Owo+IAo+IAo+IAo+IAoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0 cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo= From xen-devel-bounces@lists.xen.org Tue Oct 02 14:02:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:02:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ33H-00044M-SC; Tue, 02 Oct 2012 14:02:23 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ33G-00044H-AM for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 14:02:22 +0000 Received: from [85.158.143.35:11038] by server-3.bemta-4.messagelabs.com id A0/DD-10986-DE3FA605; Tue, 02 Oct 2012 14:02:21 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1349186540!13592157!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15141 invoked from network); 2 Oct 2012 14:02:21 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 14:02:21 -0000 X-IronPort-AV: E=Sophos;i="4.80,523,1344211200"; d="scan'208";a="14894930" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 14:02:20 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 15:02:19 +0100 Message-ID: <1349186538.650.69.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Sander Eikelenboom Date: Tue, 2 Oct 2012 15:02:18 +0100 In-Reply-To: <158082007.20120927221137@eikelenboom.it> References: <1348565712.3452.141.camel@zakaz.uk.xensource.com> <15210025463.20120925171143@eikelenboom.it> <1348586949.12592.10.camel@zakaz.uk.xensource.com> <158082007.20120927221137@eikelenboom.it> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Ian Jackson Subject: Re: [Xen-devel] [PATCH 0 of 3] xl and hotplug: Introduce and use shutdown and reboot xm compatibility options X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org T24gVGh1LCAyMDEyLTA5LTI3IGF0IDIxOjExICswMTAwLCBTYW5kZXIgRWlrZWxlbmJvb20gd3Jv dGU6Cj4gVHVlc2RheSwgU2VwdGVtYmVyIDI1LCAyMDEyLCA1OjI5OjA5IFBNLCB5b3Ugd3JvdGU6 Cj4gCj4gPiBPbiBUdWUsIDIwMTItMDktMjUgYXQgMTY6MTEgKzAxMDAsIFNhbmRlciBFaWtlbGVu Ym9vbSB3cm90ZToKPiAKPiA+PiBUaGUgb25seSByZWxhdGl2ZSBzaW1wbGUgaW1wbGVtZW50YXRp b24gaSB0aG91Z2h0IG9mIHdhcyBkaXJlY3QKPiA+PiBzaHV0dGluZyBkb3duIGFsbCwgYW5kIHdo ZW4gdGhlIC13IHBhcmFtZXRlciB3YXMgc2V0LCBqdXN0IGxvb3AgYW5kCj4gPj4gd2FpdCBvbiBl dmVudHMgdW50aWwgdGhlIG9ubHkgcnVubmluZyBkb21haW4gaXMgZG9tYWluLTAuCj4gPj4gQWx0 aG91Z2ggdGhpcyBleGFjdGx5IGRvZXMgd2hhdCBoYXMgdG8gYmUgZG9uZSwgaXQgc29tZWhvdyBz b3VuZHMgYQo+ID4+IGJpdCBkaXJ0eS4KPiAKPiA+IEkgdGhpbmsgeW91IGNhbiBhbGxvY2F0ZSBh biBhcnJheSBvZiBsaWJ4bF9ldmVuYWJsZV9kb21haW5fZGVhdGgqLCBvZgo+ID4gbnJfZG9tcyBp biBzaXplIGFuZCB0aGVuIGFzIHlvdSBzaHV0ZG93biBlYWNoIGRvbWFpbiBjYWxsCj4gPiBsaWJ4 bF9ldmVuYWJsZV9kb21haW5fZGVhdGggZm9yIGl0IHRvby4KPiAKPiA+IFRoZW4geW91IGxvb3Ag d2FpdGluZyBmb3IgZGVzdHJveSBldmVudHMsIGNhbGxpbmcKPiA+IGxpYnhsX2V2ZGlzYWJsZV9k b21haW5fZGVhdGggYXMgZWFjaCBkb21haW4gZGllcywgd2hpbGUgY291bnRpbmcgYmFjawo+ID4g ZnJvbSBucl9kb21zIHVudGlsIDAuIFdoZW4gaXQgcmVhY2hlcyAwIGV2ZXJ5dGhpbmcgeW91IGFz a2VkIGZvciBoYXMKPiA+IGJlZW4gc2h1dGRvd24uCj4gCj4gPiBPciBzb21ldGhpbmcgbGlrZSB0 aGF0LCBJJ3ZlIG5vdCBhY3R1YWxseSBpbXBsZW1lbnRlZCBpdCA7LSkKPiAKPiA+IElhbi4KPiAK PiBJdCdzIHRpbWUgdG8gY2FsbCBkZWZlYXQsIHdpdGhvdXQgcHJvcGVyIEMgc2tpbGxzIGl0IHNl ZW1zIGEgYml0IHRvbwo+IGhhcmQgdG8gZmlndXJlIGl0IG91dC4KClRoYXQncyBvaywgSSdsbCBh ZGQgaXQgdG8gbXkgVE9ETyB0byBwaWNrdXAgd2hlcmUgeW91IGxlZnQgb2ZmICh1bmxlc3MKc29t ZW9uZSBiZWF0cyBtZSB0byBpdCkuCgpUaGFua3MgZm9yIHRha2luZyBpdCB0aGlzIGZhciEgRldJ VyB5b3Ugc2VlbWVkIHRvIGJlIHByZXR0eSBjbG9zZS4KCj4gQ2FuJ3Qgc2VlbSB0byBnZXQgdGhl IGhhbmcgb2YgaG93IHRvIGtlZXAgYSByZWZlcmVuY2UgdG8KPiBsaWJ4bF9ldmdlbl9kb21haW5f ZGVhdGggYW5kIHVzZSBpdCB0byBjaGVjayBpZiB0aGUgZG9taWQgb2YgdGhlIGV2ZW50Cj4gaXMg dGhlIHNhbWUgYXMgdGhhdCBmcm9tIGEgZG9tYWluIHdlIGFyZSB3YWl0aW5nIHRvIHNodXRkb3du Lgo+IFRoZSByZXN0IG9mIHRoZSBjb2RlIGRvZXNuJ3QgZ2l2ZSBtZSBtdWNoIHBvaW50ZXJzIHNp bmNlIGFsbCBjb21tYW5kcwo+IHNlZW0gdG8gb3BlcmF0ZSBvbiBhIHNpbmdsZSBkb21pZCBhdCBv bmNlLgo+IAo+IFRoZSBjb25jb2N0aW9uIGJlbG93IGxlYWRzIHRvOgo+IHhsX2NtZGltcGwuYzog SW4gZnVuY3Rpb24gw6JzaHV0ZG93bl9kb21haW7DojoKPiB4bF9jbWRpbXBsLmM6Mjc2NjogZXJy b3I6IGRlcmVmZXJlbmNpbmcgcG9pbnRlciB0byBpbmNvbXBsZXRlIHR5cGUKCkluIGNhc2UgeW91 IGFyZSBpbnRlcmVzdGVkIHRoaXMgaXMgYmVjYXVzZSB0aGUgbGlieGxfZXZnZW5fZG9tYWluX2Rl YXRoCnR5cGUgaXMgb3BhcXVlIHRvIHVzZXJzIG9mIGxpYnhsIHNvIGNvbnN0cnVjdHMgbGlrZQpk b21haW5zX3dhaXRfc2h1dGRvd25baV0tPmRvbWlkIGFyZSBub3QgcG9zc2libGUuCgpUaGUgYW5z d2VyIGlzIHRvIHVzZSB0aGUgM3JkIGFyZ3VtZW50IHRvIGxpYnhsX2V2ZW5hYmxlX2RvbWFpbl9k ZWF0aAoodGhlIG9uZSBvZiB0eXBlIGxpYnhsX2V2X3VzZXIpIHRvIHBhc3MgYSAiY2xvc3VyZSIs IHRoaXMgdmFsdWUgaXMKcmV0dXJuZWQgaW4gdGhlIGV2ZW50J3MgImZvcl91c2VyIiBmaWVsZC4g VGhlIGFwcGxpY2F0aW9uIGNhbiB1c2UgdGhpcwp0byBzdG9yZSBkYXRhIHNwZWNpZmljIHRvIHRo aXMgcGFydGljdWxhciBldmVudCAtLSBpbiB0aGlzIGNhc2UgaXQgd291bGQKcHJvYmFibHkgYmUg c3VmZmljaWVudCB0byBqdXN0IHBhc3MgdGhlIGRvbWlkIGhlcmUgYnV0IGluIHByaW5jaXBhbCBv bmUKY291bGQgcGFzcyBhIHBvaW50ZXIgdG8gYW55IGRhdGFzdHJ1Y3R1cmUuCgpUaGFua3MgYWdh aW4sCklhbi4KCj4gCj4gCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIHRvb2xzL2xpYnhs L3hsX2NtZGltcGwuYyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiBpbmRleCAxNjI3Y2Fj Li5iOTAwODExIDEwMDY0NAo+IEBAIC0yNjg0LDY3ICsyNjg0LDk4IEBAIHN0YXRpYyB2b2lkIGRl c3Ryb3lfZG9tYWluKHVpbnQzMl90IGRvbWlkKQo+ICAgICAgfQo+ICAgICAgcmMgPSBsaWJ4bF9k b21haW5fZGVzdHJveShjdHgsIGRvbWlkLCAwKTsKPiAgICAgIGlmIChyYykgeyBmcHJpbnRmKHN0 ZGVyciwiZGVzdHJveSBmYWlsZWQgKHJjPSVkKVxuIixyYyk7IGV4aXQoLTEpOyB9Cj4gIH0KPiAg Cj4gLXN0YXRpYyB2b2lkIHNodXRkb3duX2RvbWFpbih1aW50MzJfdCBkb21pZCwgaW50IHdhaXRf Zm9yX2l0LAo+IC0gICAgICAgICAgICAgICAgICAgICAgICAgICAgaW50IGZhbGxiYWNrX3RyaWdn ZXIpCj4gK3N0YXRpYyBpbnQgc2h1dGRvd25fZG9tYWluKGNvbnN0IGxpYnhsX2RvbWluZm8gKmRv bWluZm8sIGludCBuYl9kb21haW4sCj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbnQg d2FpdF9mb3JfaXQsIGludCBmYWxsYmFja190cmlnZ2VyKQo+ICB7Cj4gLSAgICBpbnQgcmM7Cj4g LSAgICBsaWJ4bF9ldmVudCAqZXZlbnQ7Cj4gKyAgICBpbnQgaSwgcmMsIG5iX3NodXRkb3duX3Bl bmRpbmc7Cj4gKyAgICBpbnQgcmV0ID0gMDsKPiArICAgIGxpYnhsX2V2Z2VuX2RvbWFpbl9kZWF0 aCAqZG9tYWluc193YWl0X3NodXRkb3duW25iX2RvbWFpbl07Cj4gKyAgICAgICAKPiArICAgIGZv ciAoaSA9IDA7IGkgPCBuYl9kb21haW47IGkrKykgewo+ICsgICAgICAgIHVpbnQzMl90IGRvbWlk ID0gZG9taW5mb1tpXS5kb21pZDsKPiArICAgICAgICBpZighbGlieGxfZG9taWRfdmFsaWRfZ3Vl c3QoZG9taWQpKQo+ICsgICAgICAgICAgICBjb250aW51ZTsKPiAgCj4gLSAgICByYz1saWJ4bF9k b21haW5fc2h1dGRvd24oY3R4LCBkb21pZCk7Cj4gLSAgICBpZiAocmMgPT0gRVJST1JfTk9QQVJB VklSVCkgewo+IC0gICAgICAgIGlmIChmYWxsYmFja190cmlnZ2VyKSB7Cj4gLSAgICAgICAgICAg IGZwcmludGYoc3RkZXJyLCAiUFYgY29udHJvbCBpbnRlcmZhY2Ugbm90IGF2YWlsYWJsZToiCj4g LSAgICAgICAgICAgICAgICAgICAgIiBzZW5kaW5nIEFDUEkgcG93ZXIgYnV0dG9uIGV2ZW50Llxu Iik7Cj4gLSAgICAgICAgICAgIHJjID0gbGlieGxfc2VuZF90cmlnZ2VyKGN0eCwgZG9taWQsIExJ QlhMX1RSSUdHRVJfUE9XRVIsIDApOwo+IC0gICAgICAgIH0gZWxzZSB7Cj4gLSAgICAgICAgICAg IGZwcmludGYoc3RkZXJyLCAiUFYgY29udHJvbCBpbnRlcmZhY2Ugbm90IGF2YWlsYWJsZToiCj4g LSAgICAgICAgICAgICAgICAgICAgIiBleHRlcm5hbCBncmFjZWZ1bCBzaHV0ZG93biBub3QgcG9z c2libGUuXG4iKTsKPiAtICAgICAgICAgICAgZnByaW50ZihzdGRlcnIsICJVc2UgXCItRlwiIHRv IGZhbGxiYWNrIHRvIEFDUEkgcG93ZXIgZXZlbnQuXG4iKTsKPiArICAgICAgICByYyA9IGxpYnhs X2RvbWFpbl9zaHV0ZG93bihjdHgsIGRvbWlkKTsKPiArCj4gKyAgICAgICAgaWYgKHJjID09IEVS Uk9SX05PUEFSQVZJUlQpIHsKPiArICAgICAgICAgICAgaWYgKGZhbGxiYWNrX3RyaWdnZXIpIHsK PiArICAgICAgICAgICAgICAgIGZwcmludGYoc3RkZXJyLCAiUFYgY29udHJvbCBpbnRlcmZhY2Ug bm90IGF2YWlsYWJsZToiCj4gKyAgICAgICAgICAgICAgICAgICAgICAgICIgc2VuZGluZyBBQ1BJ IHBvd2VyIGJ1dHRvbiBldmVudC5cbiIpOwo+ICsgICAgICAgICAgICAgICAgcmMgPSBsaWJ4bF9z ZW5kX3RyaWdnZXIoY3R4LCBkb21pZCwgTElCWExfVFJJR0dFUl9QT1dFUiwgMCk7Cj4gKyAgICAg ICAgICAgIH0gZWxzZSB7Cj4gKyAgICAgICAgICAgICAgICBmcHJpbnRmKHN0ZGVyciwgIlBWIGNv bnRyb2wgaW50ZXJmYWNlIG5vdCBhdmFpbGFibGU6Igo+ICsgICAgICAgICAgICAgICAgICAgICAg ICAiIGV4dGVybmFsIGdyYWNlZnVsIHNodXRkb3duIG5vdCBwb3NzaWJsZS5cbiIpOwo+ICsgICAg ICAgICAgICAgICAgZnByaW50ZihzdGRlcnIsCj4gKyAgICAgICAgICAgICAgICAgICAgIlVzZSBc Ii1GXCIgdG8gZmFsbGJhY2sgdG8gQUNQSSBwb3dlciBldmVudC5cbiIpOwo+ICsgICAgICAgICAg ICB9Cj4gKyAgICAgICAgfQo+ICsgICAgICAgIAo+ICsgICAgICAgIGlmIChyYykgewo+ICsgICAg ICAgICAgICBmcHJpbnRmKHN0ZGVyciwic2h1dGRvd24gb2YgZG9tYWluICVkIGZhaWxlZCAocmM9 JWQpXG4iLCBkb21pZCwgcmMpOwo+ICsgICAgICAgICAgICByZXQgPSAtMTsKPiArICAgICAgICAg ICAgY29udGludWU7Cj4gKyAgICAgICAgfQo+ICsKPiArICAgICAgICBpZiAod2FpdF9mb3JfaXQp IHsKPiArICAgICAgICAgICAgcmMgPSBsaWJ4bF9ldmVuYWJsZV9kb21haW5fZGVhdGgoY3R4LCBk b21pZCwgMCwgJmRvbWFpbnNfd2FpdF9zaHV0ZG93bltpXSk7Cj4gKyAgICAgICAgICAgIGlmIChy Yykgewo+ICsgICAgICAgICAgICAgICAgZnByaW50ZihzdGRlcnIsIndhaXQgZm9yIGRlYXRoIG9m IGRvbWFpbiAlZCBmYWlsZWQiCj4gKyAgICAgICAgICAgICAgICAgICAgIiAoZXZnZW4sIHJjPSVk KVxuIiwgZG9taWQsIHJjKTsKPiArICAgICAgICAgICAgICAgIHJldCA9IC0xOwo+ICsgICAgICAg ICAgICB9IGVsc2Ugewo+ICsgICAgICAgICAgICAgICAgbmJfc2h1dGRvd25fcGVuZGluZysrOwo+ ICsgICAgICAgICAgICB9IAo+ICAgICAgICAgIH0KPiAtICAgIH0KPiAtICAgIGlmIChyYykgewo+ IC0gICAgICAgIGZwcmludGYoc3RkZXJyLCJzaHV0ZG93biBmYWlsZWQgKHJjPSVkKVxuIixyYyk7 ZXhpdCgtMSk7Cj4gICAgICB9Cj4gIAo+ICAgICAgaWYgKHdhaXRfZm9yX2l0KSB7Cj4gLSAgICAg ICAgbGlieGxfZXZnZW5fZG9tYWluX2RlYXRoICpkZWF0aHc7Cj4gKyAgICAgICAgd2hpbGUgKG5i X3NodXRkb3duX3BlbmRpbmcgPiAwKSB7Cj4gKyAgICAgICAgICAgIGxpYnhsX2V2ZW50ICpldmVu dDsKPiArICAgICAgICAgICAgcmMgPSBsaWJ4bF9ldmVudF93YWl0KGN0eCwgJmV2ZW50LCBMSUJY TF9FVkVOVE1BU0tfQUxMLCAwLDApOwo+ICsgICAgICAgICAgICBpZiAocmMpIHsKPiArICAgICAg ICAgICAgICAgIExPRygiRmFpbGVkIHRvIGdldCBldmVudCAocmM9JWQpIiwgcmMpOwo+ICsgICAg ICAgICAgICAgICAgcmV0dXJuIC0xOwo+ICsgICAgICAgICAgICB9Cj4gIAo+IC0gICAgICAgIHJj ID0gbGlieGxfZXZlbmFibGVfZG9tYWluX2RlYXRoKGN0eCwgZG9taWQsIDAsICZkZWF0aHcpOwo+ IC0gICAgICAgIGlmIChyYykgewo+IC0gICAgICAgICAgICBmcHJpbnRmKHN0ZGVyciwid2FpdCBm b3IgZGVhdGggZmFpbGVkIChldmdlbiwgcmM9JWQpXG4iLHJjKTsKPiAtICAgICAgICAgICAgZXhp dCgtMSk7Cj4gLSAgICAgICAgfQo+ICsgICAgICAgICAgICB1aW50MzJfdCBldmVudF9kb21pZCA9 IGV2ZW50LT5kb21pZDsKPiArICAgICAgICAgICAgc3dpdGNoIChldmVudC0+dHlwZSkgewo+ICAK PiAtICAgICAgICBmb3IgKDs7KSB7Cj4gLSAgICAgICAgICAgIHJjID0gZG9tYWluX3dhaXRfZXZl bnQoZG9taWQsICZldmVudCk7Cj4gLSAgICAgICAgICAgIGlmIChyYykgZXhpdCgtMSk7Cj4gKyAg ICAgICAgICAgICAgICBjYXNlIExJQlhMX0VWRU5UX1RZUEVfRE9NQUlOX0RFQVRIOgo+ICsgICAg ICAgICAgICAgICAgICAgIExPRygiRG9tYWluICVkIGhhcyBiZWVuIGRlc3Ryb3llZCIsIGV2ZW50 X2RvbWlkKTsKPiArICAgICAgICAgICAgICAgICAgICBicmVhazsKPiAgCj4gLSAgICAgICAgICAg IHN3aXRjaCAoZXZlbnQtPnR5cGUpIHsKPiArICAgICAgICAgICAgICAgIGNhc2UgTElCWExfRVZF TlRfVFlQRV9ET01BSU5fU0hVVERPV046Cj4gKyAgICAgICAgICAgICAgICAgICAgTE9HKCJEb21h aW4gJWQgaGFzIGJlZW4gc2h1dCBkb3duLCByZWFzb24gY29kZSAlZCAleCIsCj4gKyAgICAgICAg ICAgICAgICAgICAgICAgIGV2ZW50X2RvbWlkLAo+ICsgICAgICAgICAgICAgICAgICAgICAgICBl dmVudC0+dS5kb21haW5fc2h1dGRvd24uc2h1dGRvd25fcmVhc29uLAo+ICsgICAgICAgICAgICAg ICAgICAgICAgICBldmVudC0+dS5kb21haW5fc2h1dGRvd24uc2h1dGRvd25fcmVhc29uKTsKPiAr ICAgICAgICAgICAgICAgICAgICBicmVhazsKPiAgCj4gLSAgICAgICAgICAgIGNhc2UgTElCWExf RVZFTlRfVFlQRV9ET01BSU5fREVBVEg6Cj4gLSAgICAgICAgICAgICAgICBMT0coIkRvbWFpbiAl ZCBoYXMgYmVlbiBkZXN0cm95ZWQiLCBkb21pZCk7Cj4gLSAgICAgICAgICAgICAgICBnb3RvIGRv bmU7Cj4gKyAgICAgICAgICAgICAgICBkZWZhdWx0Ogo+ICsgICAgICAgICAgICAgICAgICAgIGNv bnRpbnVlOwo+ICsgICAgICAgICAgICAgICAgICAgIGJyZWFrOwo+ICsgICAgICAgICAgICB9Cj4g IAo+IC0gICAgICAgICAgICBjYXNlIExJQlhMX0VWRU5UX1RZUEVfRE9NQUlOX1NIVVRET1dOOgo+ IC0gICAgICAgICAgICAgICAgTE9HKCJEb21haW4gJWQgaGFzIGJlZW4gc2h1dCBkb3duLCByZWFz b24gY29kZSAlZCAleCIsIGRvbWlkLAo+IC0gICAgICAgICAgICAgICAgICAgIGV2ZW50LT51LmRv bWFpbl9zaHV0ZG93bi5zaHV0ZG93bl9yZWFzb24sCj4gLSAgICAgICAgICAgICAgICAgICAgZXZl bnQtPnUuZG9tYWluX3NodXRkb3duLnNodXRkb3duX3JlYXNvbik7Cj4gLSAgICAgICAgICAgICAg ICBnb3RvIGRvbmU7Cj4gKyAgICAgICAgICAgIGZvciAoaSA9IDA7IGkgPCBuYl9kb21haW47IGkr Kykgewo+ICsgICAgICAgICAgICAgICAgaWYgKCFkb21haW5zX3dhaXRfc2h1dGRvd25baV0pCj4g KyAgICAgICAgICAgICAgICAgICAgY29udGludWU7Cj4gIAo+IC0gICAgICAgICAgICBkZWZhdWx0 Ogo+IC0gICAgICAgICAgICAgICAgTE9HKCJVbmV4cGVjdGVkIGV2ZW50IHR5cGUgJWQiLCBldmVu dC0+dHlwZSk7Cj4gLSAgICAgICAgICAgICAgICBicmVhazsKPiArICAgICAgICAgICAgICAgIGlm IChkb21haW5zX3dhaXRfc2h1dGRvd25baV0tPmRvbWlkID09IGV2ZW50X2RvbWlkKXsKPiArICAg ICAgICAgICAgICAgICAgICBsaWJ4bF9ldmRpc2FibGVfZG9tYWluX2RlYXRoKGN0eCwgZG9tYWlu c193YWl0X3NodXRkb3duW2ldKTsKPiArICAgICAgICAgICAgICAgICAgICBkb21haW5zX3dhaXRf c2h1dGRvd25baV0gPSBOVUxMOwo+ICsgICAgICAgICAgICAgICAgICAgIG5iX3NodXRkb3duX3Bl bmRpbmctLTsKPiArICAgICAgICAgICAgICAgIH0KPiAgICAgICAgICAgICAgfQo+ICAgICAgICAg ICAgICBsaWJ4bF9ldmVudF9mcmVlKGN0eCwgZXZlbnQpOwo+ICAgICAgICAgIH0KPiAtICAgIGRv bmU6Cj4gLSAgICAgICAgbGlieGxfZXZlbnRfZnJlZShjdHgsIGV2ZW50KTsKPiAtICAgICAgICBs aWJ4bF9ldmRpc2FibGVfZG9tYWluX2RlYXRoKGN0eCwgZGVhdGh3KTsKPiAgICAgIH0KPiArCj4g KyAgICByZXR1cm4gcmV0Owo+ICB9Cj4gIAo+ICBzdGF0aWMgdm9pZCByZWJvb3RfZG9tYWluKHVp bnQzMl90IGRvbWlkLCBpbnQgZmFsbGJhY2tfdHJpZ2dlcikKPiAgewo+ICAgICAgaW50IHJjOwo+ IEBAIC0zNjc0LDI5ICszNzA1LDgyIEBAIGludCBtYWluX2Rlc3Ryb3koaW50IGFyZ2MsIGNoYXIg Kiphcmd2KQo+ICAgICAgcmV0dXJuIDA7Cj4gIH0KPiAgCj4gIGludCBtYWluX3NodXRkb3duKGlu dCBhcmdjLCBjaGFyICoqYXJndikKPiAgewo+ICsgICAgbGlieGxfZG9taW5mbyBkb21pbmZvX2J1 ZjsKPiArICAgIGxpYnhsX2RvbWluZm8gKmRvbWluZm8sICpkb21pbmZvX2ZyZWUgPSBOVUxMOwo+ ICsgICAgaW50IG5iX2RvbWFpbiwgcmM7Cj4gICAgICBpbnQgb3B0Owo+ICsgICAgaW50IG9wdGlv bl9pbmRleCA9IDA7Cj4gKyAgICBpbnQgYWxsID0gMDsKPiAgICAgIGludCB3YWl0X2Zvcl9pdCA9 IDA7Cj4gICAgICBpbnQgZmFsbGJhY2tfdHJpZ2dlciA9IDA7Cj4gKyAgICBzdGF0aWMgc3RydWN0 IG9wdGlvbiBsb25nX29wdGlvbnNbXSA9IHsKPiArICAgICAgICB7ImFsbCIsIDAsIDAsICdhJ30s Cj4gKyAgICAgICAgeyJ3YWl0IiwgMCwgMCwgJ3cnfSwKPiArICAgICAgICB7MCwgMCwgMCwgMH0K PiArICAgIH07Cj4gIAo+IC0gICAgd2hpbGUgKChvcHQgPSBkZWZfZ2V0b3B0KGFyZ2MsIGFyZ3Ys ICJ3RiIsICJzaHV0ZG93biIsIDEpKSAhPSAtMSkgewo+ICsgICAgd2hpbGUgKChvcHQgPSBnZXRv cHRfbG9uZyhhcmdjLCBhcmd2LCAiYXdGIiwgbG9uZ19vcHRpb25zLCAmb3B0aW9uX2luZGV4KSkg IT0gLTEpIHsKPiAgICAgICAgICBzd2l0Y2ggKG9wdCkgewo+ICAgICAgICAgIGNhc2UgMDogY2Fz ZSAyOgo+ICAgICAgICAgICAgICByZXR1cm4gb3B0Owo+ICsgICAgICAgIGNhc2UgJ2EnOgo+ICsg ICAgICAgICAgICBhbGwgPSAxOwo+ICsgICAgICAgICAgICBicmVhazsKPiAgICAgICAgICBjYXNl ICd3JzoKPiAgICAgICAgICAgICAgd2FpdF9mb3JfaXQgPSAxOwo+ICAgICAgICAgICAgICBicmVh azsKPiAgICAgICAgICBjYXNlICdGJzoKPiAgICAgICAgICAgICAgZmFsbGJhY2tfdHJpZ2dlciA9 IDE7Cj4gICAgICAgICAgICAgIGJyZWFrOwo+ICAgICAgICAgIH0KPiAgICAgIH0KPiAgCj4gLSAg ICBzaHV0ZG93bl9kb21haW4oZmluZF9kb21haW4oYXJndltvcHRpbmRdKSwgd2FpdF9mb3JfaXQs IGZhbGxiYWNrX3RyaWdnZXIpOwo+IC0gICAgcmV0dXJuIDA7Cj4gKyAgICBpZiAoIWFyZ3Zbb3B0 aW5kXSAmJiAhYWxsKSB7Cj4gKyAgICAgICAgZnByaW50ZihzdGRlcnIsICJZb3UgbXVzdCBzcGVj aWZ5IC1hIG9yIGEgdmFsaWQgZG9tYWluIGlkLlxuXG4iKTsKPiArICAgICAgICByZXR1cm4gb3B0 Owo+ICsgICAgfQo+ICsKPiArICAgIGlmIChhbGwpIHsKPiArICAgICAgICBkb21pbmZvID0gbGli eGxfbGlzdF9kb21haW4oY3R4LCAmbmJfZG9tYWluKTsKPiArICAgICAgICBpZiAoIWRvbWluZm8p IHsKPiArICAgICAgICAgICAgZnByaW50ZihzdGRlcnIsICJsaWJ4bF9kb21haW5faW5mb2xpc3Qg ZmFpbGVkLlxuIik7Cj4gKyAgICAgICAgICAgIHJldHVybiAtMTsKPiArICAgICAgICB9Cj4gKyAg ICAgICAgZG9taW5mb19mcmVlID0gZG9taW5mbzsKPiArICAgIH0gZWxzZSB7Cj4gKyAgICAgICAg dWludDMyX3QgZG9taWQgPSBmaW5kX2RvbWFpbihhcmd2W29wdGluZF0pOwo+ICsgICAgICAgIGlm IChkb21pZCA9PSAwKSB7Cj4gKyAgICAgICAgICAgIGZwcmludGYoc3RkZXJyLCAiRXJyb3I6IERv bWFpbi0wIGNhbid0IGJlIHNodXRkb3duIGJ5IHRoaXMgY29tbWFuZFxuIik7Cj4gKyAgICAgICAg ICAgIHJldHVybiAtMTsKPiArICAgICAgICB9Cj4gKwo+ICsgICAgICAgIHJjID0gbGlieGxfZG9t YWluX2luZm8oY3R4LCAmZG9taW5mb19idWYsIGRvbWlkKTsKPiArCj4gKyAgICAgICAgaWYgKHJj ID09IEVSUk9SX0lOVkFMKSB7Cj4gKyAgICAgICAgICAgIGZwcmludGYoc3RkZXJyLCAiRXJyb3I6 IERvbWFpbiBcJyVzXCcgZG9lcyBub3QgZXhpc3QuXG4iLAo+ICsgICAgICAgICAgICAgICAgYXJn dltvcHRpbmRdKTsKPiArICAgICAgICAgICAgcmV0dXJuIC1yYzsKPiArICAgICAgICB9Cj4gKyAg ICAgICAgaWYgKHJjKSB7Cj4gKyAgICAgICAgICAgIGZwcmludGYoc3RkZXJyLCAibGlieGxfZG9t YWluX2luZm8gZmFpbGVkIChjb2RlICVkKS5cbiIsIHJjKTsKPiArICAgICAgICAgICAgcmV0dXJu IC1yYzsKPiArICAgICAgICB9Cj4gKyAgICAgICAgZG9taW5mbyA9ICZkb21pbmZvX2J1ZjsKPiAr ICAgICAgICBuYl9kb21haW4gPSAxOwo+ICsgICAgfQo+ICsKPiArICAgIHJjID0gc2h1dGRvd25f ZG9tYWluKGRvbWluZm8sIG5iX2RvbWFpbiwgd2FpdF9mb3JfaXQsIGZhbGxiYWNrX3RyaWdnZXIp Owo+ICsKPiArICAgIGlmIChkb21pbmZvX2ZyZWUpCj4gKyAgICAgICAgbGlieGxfZG9taW5mb19s aXN0X2ZyZWUoZG9taW5mb19mcmVlLCBuYl9kb21haW4pOwo+ICsgICAgZWxzZQo+ICsgICAgICAg IGxpYnhsX2RvbWluZm9fZGlzcG9zZShkb21pbmZvKTsKPiArCj4gKyAgICByZXR1cm4gLXJjOwo+ ICB9Cj4gIAo+ICBpbnQgbWFpbl9yZWJvb3QoaW50IGFyZ2MsIGNoYXIgKiphcmd2KQo+ICB7Cj4g ICAgICBpbnQgb3B0Owo+IAo+IAo+IAo+IAoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0 cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo= From xen-devel-bounces@lists.xen.org Tue Oct 02 14:03:37 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:03:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ34F-00048P-E9; Tue, 02 Oct 2012 14:03:23 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ34E-00048F-4S for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 14:03:22 +0000 Received: from [85.158.143.99:58536] by server-3.bemta-4.messagelabs.com id 47/CF-10986-924FA605; Tue, 02 Oct 2012 14:03:21 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1349186596!31964902!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc4Nzc1OQ==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22821 invoked from network); 2 Oct 2012 14:03:18 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 14:03:18 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q92E3Ewf022554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Oct 2012 14:03:15 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q92E3DYD000322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Oct 2012 14:03:13 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q92E3Cdh018613; Tue, 2 Oct 2012 09:03:12 -0500 Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 02 Oct 2012 07:03:12 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 8E4C74032D; Tue, 2 Oct 2012 09:51:47 -0400 (EDT) Date: Tue, 2 Oct 2012 09:51:47 -0400 From: Konrad Rzeszutek Wilk To: Linus Torvalds , linux-kernel@vger.kernel.org Message-ID: <20121002135147.GA15735@phenom.dumpdata.com> MIME-Version: 1.0 User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: xen-devel@lists.xensource.com Subject: [Xen-devel] [GIT PULL] (xen) stable/for-linus-3.7-x86-tag X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4931502778296491969==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============4931502778296491969== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IS0zKkzwUGydFO0o" Content-Disposition: inline --IS0zKkzwUGydFO0o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hey Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-linus-3.7-x86-tag which as features/fixes for the x86 and the generic side of the Xen tree. The signed tag has the wealth of details of what it contains, so I am copying it here: Features: * When hotplugging PCI devices in a PV guest we can allocate Xen-SWIOTLB later. * Cleanup Xen SWIOTLB. * Support pages out grants from HVM domains in the backends. * Support wild cards in xen-pciback.hide=(BDF) arguments. * Update grant status updates with upstream hypervisor. * Boot PV guests with more than 128GB. * Cleanup Xen MMU code/add comments. * Obtain XENVERS using a preferred method. * Lay out generic changes to support Xen ARM. * Allow privcmd ioctl for HVM (used to do only PV). * Do v2 of mmap_batch for privcmd ioctls. * If hypervisor saves the LED keyboard light - we will now instruct the kernel about its state. Fixes: * More fixes to Xen PCI backend for various calls/FLR/etc. * With more than 4GB in a 64-bit PV guest disable native SWIOTLB. * Fix up smatch warnings. * Fix up various return values in privmcmd and mm. It is rather a big pull - and some of them are architecture specific to prep for the Xen ARM patches. The 1-2 line changes are additions of #include files to support compilation under ARM. There are also changes to SWIOTLB - to allow it to be used later in the boot process (so we can hotplug PCI devices and allocate SWIOTLB in case we hadn't started it). IA64 does this too - so the patches expand the existing function - and have been tested with success on IA64 to make sure they do not introduce regressions. Please pull! Andres Lagar-Cavilla (3): xen/privcmd: add PRIVCMD_MMAPBATCH_V2 ioctl xen/privcmd: Fix mmap batch ioctl error status copy back. xen/gndev: Xen backend support for paged out grant targets V4. Dan Carpenter (1): xen/privcmd: return -EFAULT on error Daniel De Graaf (1): xen/sysfs: Use XENVER_guest_handle to query UUID David Vrabel (1): xen/mm: return more precise error from xen_remap_domain_range() Ian Campbell (1): xen: resynchronise grant table status codes with upstream Jan Beulich (3): xen-pciback: support wild cards in slot specifications xen/vga: add the xen EFI video mode support xen-pciback: properly clean up after calling pcistub_device_find() Konrad Rzeszutek Wilk (31): xen/perf: Define .glob for the different hypercalls. xen/p2m: Fix the comment describing the P2M tree. xen/x86: Use memblock_reserve for sensitive areas. xen/x86: Workaround 64-bit hypervisor and 32-bit initial domain. xen/swiotlb: Simplify the logic. xen/swiotlb: With more than 4GB on 64-bit, disable the native SWIOTLB. swiotlb: add the late swiotlb initialization function with iotlb memory xen/apic/xenbus/swiotlb/pcifront/grant/tmem: Make functions or variables static. xen/swiotlb: Remove functions not needed anymore. xen/swiotlb: Fix compile warnings when using plain integer instead of NULL pointer. Revert "xen/x86: Workaround 64-bit hypervisor and 32-bit initial domain." and "xen/x86: Use memblock_reserve for sensitive areas." xen/mmu: The xen_setup_kernel_pagetable doesn't need to return anything. xen/mmu: Provide comments describing the _ka and _va aliasing issue xen/mmu: use copy_page instead of memcpy. xen/mmu: For 64-bit do not call xen_map_identity_early xen/mmu: Recycle the Xen provided L4, L3, and L2 pages xen/p2m: Add logic to revector a P2M tree to use __va leafs. xen/mmu: Copy and revector the P2M tree. xen/mmu: Remove from __ka space PMD entries for pagetables. xen/mmu: Release just the MFN list, not MFN list and part of pagetables. xen/p2m: When revectoring deal with holes in the P2M array. xen/mmu: If the revector fails, don't attempt to revector anything else. xen/swiotlb: Move the nr_tbl determination in its own function. xen/swiotlb: Move the error strings to its own function. xen/swiotlb: Use the swiotlb_late_init_with_tbl to init Xen-SWIOTLB late when PV PCI is used. xen/swiotlb: For early initialization, return zero on success. xen/pcifront: Use Xen-SWIOTLB when initting if required. xen/swiotlb: Remove functions not needed anymore. xen/swiotlb: Fix compile warnings when using plain integer instead of NULL pointer. xen/x86: retrieve keyboard shift status flags from hypervisor. xen/pciback: Restore the PCI config space after an FLR. Stefano Stabellini (7): xen: update xen_add_to_physmap interface xen: missing includes xen/events: fix unmask_evtchn for PV on HVM guests xen: clear IRQ_NOAUTOEN and IRQ_NOREQUEST xen: Introduce xen_pfn_t for pfn and mfn types xen: allow privcmd for HVM guests xen/arm: compile and run xenbus arch/ia64/include/asm/xen/interface.h | 7 +- arch/x86/include/asm/xen/interface.h | 7 + arch/x86/include/asm/xen/swiotlb-xen.h | 2 + arch/x86/xen/apic.c | 3 +- arch/x86/xen/enlighten.c | 15 ++- arch/x86/xen/mmu.c | 190 ++++++++++++++++++++++------ arch/x86/xen/p2m.c | 92 +++++++++++++- arch/x86/xen/pci-swiotlb-xen.c | 52 +++++++- arch/x86/xen/platform-pci-unplug.c | 1 + arch/x86/xen/setup.c | 18 +++ arch/x86/xen/vga.c | 7 + arch/x86/xen/xen-head.S | 56 ++++++++- arch/x86/xen/xen-ops.h | 3 +- drivers/net/xen-netback/netback.c | 11 +-- drivers/pci/xen-pcifront.c | 15 ++- drivers/tty/hvc/hvc_xen.c | 2 + drivers/xen/events.c | 18 +++- drivers/xen/gntdev.c | 2 +- drivers/xen/grant-table.c | 67 +++++++++- drivers/xen/privcmd.c | 135 +++++++++++++++----- drivers/xen/swiotlb-xen.c | 119 +++++++++++------- drivers/xen/sys-hypervisor.c | 13 ++- drivers/xen/tmem.c | 1 + drivers/xen/xen-pciback/pci_stub.c | 136 ++++++++++++++++----- drivers/xen/xenbus/xenbus_client.c | 6 +- drivers/xen/xenbus/xenbus_comms.c | 2 +- drivers/xen/xenbus/xenbus_dev_backend.c | 2 +- drivers/xen/xenbus/xenbus_probe.c | 56 ++++++--- drivers/xen/xenbus/xenbus_probe_frontend.c | 1 + drivers/xen/xenbus/xenbus_xs.c | 3 +- include/linux/swiotlb.h | 1 + include/xen/grant_table.h | 12 ++ include/xen/interface/grant_table.h | 12 ++- include/xen/interface/memory.h | 9 +- include/xen/interface/platform.h | 7 +- include/xen/interface/version.h | 3 + include/xen/interface/xen.h | 8 +- include/xen/privcmd.h | 27 ++++- include/xen/swiotlb-xen.h | 11 +-- lib/swiotlb.c | 33 ++++-- 40 files changed, 916 insertions(+), 249 deletions(-) --IS0zKkzwUGydFO0o Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJQavFvAAoJEFjIrFwIi8fJDxMIAKeMJjmXwo+jbz3ZEss36zIu ZM1G1TGGWEs/CfiHFlb2CbiLQOijUxkteKUh2NIOVPmmFj/pUk9oXCi6l7bZRxDl +Z8bWnoCBVx9xOrU8iTVKop+0qvLX8Py4kRy6V8TmVhRe17A2fOX+2kdP4xYRP+h 4lG6JmclUPvgGjgamsp2VXbbkMLF2RsADxLx2hFx1UfnuqhFoMlF8bbsQPwBLXY0 iXap0JNIbQKcBMIlh7Pm2Z7RGbAySzok614avT+lXmPdEj48KBhe27ZGzx/CcI2/ ZOgPLI3ptVfknAsGiamrzbN8+8laeK2GPfZQStdgtczwaFcRzHmZdEuYmLAlzY4= =gXM4 -----END PGP SIGNATURE----- --IS0zKkzwUGydFO0o-- --===============4931502778296491969== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============4931502778296491969==-- From xen-devel-bounces@lists.xen.org Tue Oct 02 14:03:37 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:03:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ34F-00048P-E9; Tue, 02 Oct 2012 14:03:23 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ34E-00048F-4S for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 14:03:22 +0000 Received: from [85.158.143.99:58536] by server-3.bemta-4.messagelabs.com id 47/CF-10986-924FA605; Tue, 02 Oct 2012 14:03:21 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1349186596!31964902!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc4Nzc1OQ==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22821 invoked from network); 2 Oct 2012 14:03:18 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 14:03:18 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q92E3Ewf022554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Oct 2012 14:03:15 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q92E3DYD000322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Oct 2012 14:03:13 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q92E3Cdh018613; Tue, 2 Oct 2012 09:03:12 -0500 Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 02 Oct 2012 07:03:12 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 8E4C74032D; Tue, 2 Oct 2012 09:51:47 -0400 (EDT) Date: Tue, 2 Oct 2012 09:51:47 -0400 From: Konrad Rzeszutek Wilk To: Linus Torvalds , linux-kernel@vger.kernel.org Message-ID: <20121002135147.GA15735@phenom.dumpdata.com> MIME-Version: 1.0 User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: xen-devel@lists.xensource.com Subject: [Xen-devel] [GIT PULL] (xen) stable/for-linus-3.7-x86-tag X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4931502778296491969==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============4931502778296491969== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IS0zKkzwUGydFO0o" Content-Disposition: inline --IS0zKkzwUGydFO0o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hey Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-linus-3.7-x86-tag which as features/fixes for the x86 and the generic side of the Xen tree. The signed tag has the wealth of details of what it contains, so I am copying it here: Features: * When hotplugging PCI devices in a PV guest we can allocate Xen-SWIOTLB later. * Cleanup Xen SWIOTLB. * Support pages out grants from HVM domains in the backends. * Support wild cards in xen-pciback.hide=(BDF) arguments. * Update grant status updates with upstream hypervisor. * Boot PV guests with more than 128GB. * Cleanup Xen MMU code/add comments. * Obtain XENVERS using a preferred method. * Lay out generic changes to support Xen ARM. * Allow privcmd ioctl for HVM (used to do only PV). * Do v2 of mmap_batch for privcmd ioctls. * If hypervisor saves the LED keyboard light - we will now instruct the kernel about its state. Fixes: * More fixes to Xen PCI backend for various calls/FLR/etc. * With more than 4GB in a 64-bit PV guest disable native SWIOTLB. * Fix up smatch warnings. * Fix up various return values in privmcmd and mm. It is rather a big pull - and some of them are architecture specific to prep for the Xen ARM patches. The 1-2 line changes are additions of #include files to support compilation under ARM. There are also changes to SWIOTLB - to allow it to be used later in the boot process (so we can hotplug PCI devices and allocate SWIOTLB in case we hadn't started it). IA64 does this too - so the patches expand the existing function - and have been tested with success on IA64 to make sure they do not introduce regressions. Please pull! Andres Lagar-Cavilla (3): xen/privcmd: add PRIVCMD_MMAPBATCH_V2 ioctl xen/privcmd: Fix mmap batch ioctl error status copy back. xen/gndev: Xen backend support for paged out grant targets V4. Dan Carpenter (1): xen/privcmd: return -EFAULT on error Daniel De Graaf (1): xen/sysfs: Use XENVER_guest_handle to query UUID David Vrabel (1): xen/mm: return more precise error from xen_remap_domain_range() Ian Campbell (1): xen: resynchronise grant table status codes with upstream Jan Beulich (3): xen-pciback: support wild cards in slot specifications xen/vga: add the xen EFI video mode support xen-pciback: properly clean up after calling pcistub_device_find() Konrad Rzeszutek Wilk (31): xen/perf: Define .glob for the different hypercalls. xen/p2m: Fix the comment describing the P2M tree. xen/x86: Use memblock_reserve for sensitive areas. xen/x86: Workaround 64-bit hypervisor and 32-bit initial domain. xen/swiotlb: Simplify the logic. xen/swiotlb: With more than 4GB on 64-bit, disable the native SWIOTLB. swiotlb: add the late swiotlb initialization function with iotlb memory xen/apic/xenbus/swiotlb/pcifront/grant/tmem: Make functions or variables static. xen/swiotlb: Remove functions not needed anymore. xen/swiotlb: Fix compile warnings when using plain integer instead of NULL pointer. Revert "xen/x86: Workaround 64-bit hypervisor and 32-bit initial domain." and "xen/x86: Use memblock_reserve for sensitive areas." xen/mmu: The xen_setup_kernel_pagetable doesn't need to return anything. xen/mmu: Provide comments describing the _ka and _va aliasing issue xen/mmu: use copy_page instead of memcpy. xen/mmu: For 64-bit do not call xen_map_identity_early xen/mmu: Recycle the Xen provided L4, L3, and L2 pages xen/p2m: Add logic to revector a P2M tree to use __va leafs. xen/mmu: Copy and revector the P2M tree. xen/mmu: Remove from __ka space PMD entries for pagetables. xen/mmu: Release just the MFN list, not MFN list and part of pagetables. xen/p2m: When revectoring deal with holes in the P2M array. xen/mmu: If the revector fails, don't attempt to revector anything else. xen/swiotlb: Move the nr_tbl determination in its own function. xen/swiotlb: Move the error strings to its own function. xen/swiotlb: Use the swiotlb_late_init_with_tbl to init Xen-SWIOTLB late when PV PCI is used. xen/swiotlb: For early initialization, return zero on success. xen/pcifront: Use Xen-SWIOTLB when initting if required. xen/swiotlb: Remove functions not needed anymore. xen/swiotlb: Fix compile warnings when using plain integer instead of NULL pointer. xen/x86: retrieve keyboard shift status flags from hypervisor. xen/pciback: Restore the PCI config space after an FLR. Stefano Stabellini (7): xen: update xen_add_to_physmap interface xen: missing includes xen/events: fix unmask_evtchn for PV on HVM guests xen: clear IRQ_NOAUTOEN and IRQ_NOREQUEST xen: Introduce xen_pfn_t for pfn and mfn types xen: allow privcmd for HVM guests xen/arm: compile and run xenbus arch/ia64/include/asm/xen/interface.h | 7 +- arch/x86/include/asm/xen/interface.h | 7 + arch/x86/include/asm/xen/swiotlb-xen.h | 2 + arch/x86/xen/apic.c | 3 +- arch/x86/xen/enlighten.c | 15 ++- arch/x86/xen/mmu.c | 190 ++++++++++++++++++++++------ arch/x86/xen/p2m.c | 92 +++++++++++++- arch/x86/xen/pci-swiotlb-xen.c | 52 +++++++- arch/x86/xen/platform-pci-unplug.c | 1 + arch/x86/xen/setup.c | 18 +++ arch/x86/xen/vga.c | 7 + arch/x86/xen/xen-head.S | 56 ++++++++- arch/x86/xen/xen-ops.h | 3 +- drivers/net/xen-netback/netback.c | 11 +-- drivers/pci/xen-pcifront.c | 15 ++- drivers/tty/hvc/hvc_xen.c | 2 + drivers/xen/events.c | 18 +++- drivers/xen/gntdev.c | 2 +- drivers/xen/grant-table.c | 67 +++++++++- drivers/xen/privcmd.c | 135 +++++++++++++++----- drivers/xen/swiotlb-xen.c | 119 +++++++++++------- drivers/xen/sys-hypervisor.c | 13 ++- drivers/xen/tmem.c | 1 + drivers/xen/xen-pciback/pci_stub.c | 136 ++++++++++++++++----- drivers/xen/xenbus/xenbus_client.c | 6 +- drivers/xen/xenbus/xenbus_comms.c | 2 +- drivers/xen/xenbus/xenbus_dev_backend.c | 2 +- drivers/xen/xenbus/xenbus_probe.c | 56 ++++++--- drivers/xen/xenbus/xenbus_probe_frontend.c | 1 + drivers/xen/xenbus/xenbus_xs.c | 3 +- include/linux/swiotlb.h | 1 + include/xen/grant_table.h | 12 ++ include/xen/interface/grant_table.h | 12 ++- include/xen/interface/memory.h | 9 +- include/xen/interface/platform.h | 7 +- include/xen/interface/version.h | 3 + include/xen/interface/xen.h | 8 +- include/xen/privcmd.h | 27 ++++- include/xen/swiotlb-xen.h | 11 +-- lib/swiotlb.c | 33 ++++-- 40 files changed, 916 insertions(+), 249 deletions(-) --IS0zKkzwUGydFO0o Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJQavFvAAoJEFjIrFwIi8fJDxMIAKeMJjmXwo+jbz3ZEss36zIu ZM1G1TGGWEs/CfiHFlb2CbiLQOijUxkteKUh2NIOVPmmFj/pUk9oXCi6l7bZRxDl +Z8bWnoCBVx9xOrU8iTVKop+0qvLX8Py4kRy6V8TmVhRe17A2fOX+2kdP4xYRP+h 4lG6JmclUPvgGjgamsp2VXbbkMLF2RsADxLx2hFx1UfnuqhFoMlF8bbsQPwBLXY0 iXap0JNIbQKcBMIlh7Pm2Z7RGbAySzok614avT+lXmPdEj48KBhe27ZGzx/CcI2/ ZOgPLI3ptVfknAsGiamrzbN8+8laeK2GPfZQStdgtczwaFcRzHmZdEuYmLAlzY4= =gXM4 -----END PGP SIGNATURE----- --IS0zKkzwUGydFO0o-- --===============4931502778296491969== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============4931502778296491969==-- From xen-devel-bounces@lists.xen.org Tue Oct 02 14:04:39 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:04:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ35K-0004Hr-I6; Tue, 02 Oct 2012 14:04:30 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ35J-0004HZ-Dy for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:04:29 +0000 Received: from [85.158.139.83:53788] by server-15.bemta-5.messagelabs.com id C0/C4-19430-C64FA605; Tue, 02 Oct 2012 14:04:28 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-9.tower-182.messagelabs.com!1349186666!32405104!1 X-Originating-IP: [128.244.251.37] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9943 invoked from network); 2 Oct 2012 14:04:28 -0000 Received: from piper.jhuapl.edu (HELO jhuapl.edu) (128.244.251.37) by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 14:04:28 -0000 Received: from ([128.244.207.97]) by piper.jhuapl.edu with ESMTP with TLS id 5Y8HCH1.145941389; Tue, 02 Oct 2012 10:04:14 -0400 From: Matthew Fioravante To: xen-devel@lists.xen.org, Ian.Campbell@citrix.com Date: Tue, 2 Oct 2012 10:04:18 -0400 Message-Id: <1349186658-14536-1-git-send-email-matthew.fioravante@jhuapl.edu> X-Mailer: git-send-email 1.7.4.4 Cc: Matthew Fioravante Subject: [Xen-devel] [PATCH] Matthew Fioravante now maintains VTPM X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org See MAINTAINERS file Signed-off-by: Matthew Fioravante --- Change since last revision * Maintain alphabetical order * add slashes to directories diff --git a/MAINTAINERS b/MAINTAINERS index 094fe9e..0bde721 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -242,6 +242,21 @@ S: Supported T: hg http://xenbits.xen.org/linux-2.6.18-xen.hg F: drivers/xen/usb*/ +VTPM +M: Matthew Fioravante +S: Supported +F: tools/vtpm/ +F: tools/vtpm_manager/ +F: extras/minios-os/tpmfront.c +F: extras/minios-os/tpmback.c +F: extras/minios-os/tpm-tis.c +F: extras/minios-os/include/tpmfront.h +F: extras/minios-os/include/tpmback.h +F: extras/minios-os/include/tpm-tis.h +F: stubdom/vtpm/ +F: stubdom/vtpmmgr/ +F: docs/misc/vtpm.txt + X86 ARCHITECTURE M: Keir Fraser M: Jan Beulich -- 1.7.4.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 14:04:39 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:04:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ35K-0004Hr-I6; Tue, 02 Oct 2012 14:04:30 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ35J-0004HZ-Dy for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:04:29 +0000 Received: from [85.158.139.83:53788] by server-15.bemta-5.messagelabs.com id C0/C4-19430-C64FA605; Tue, 02 Oct 2012 14:04:28 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-9.tower-182.messagelabs.com!1349186666!32405104!1 X-Originating-IP: [128.244.251.37] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9943 invoked from network); 2 Oct 2012 14:04:28 -0000 Received: from piper.jhuapl.edu (HELO jhuapl.edu) (128.244.251.37) by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 14:04:28 -0000 Received: from ([128.244.207.97]) by piper.jhuapl.edu with ESMTP with TLS id 5Y8HCH1.145941389; Tue, 02 Oct 2012 10:04:14 -0400 From: Matthew Fioravante To: xen-devel@lists.xen.org, Ian.Campbell@citrix.com Date: Tue, 2 Oct 2012 10:04:18 -0400 Message-Id: <1349186658-14536-1-git-send-email-matthew.fioravante@jhuapl.edu> X-Mailer: git-send-email 1.7.4.4 Cc: Matthew Fioravante Subject: [Xen-devel] [PATCH] Matthew Fioravante now maintains VTPM X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org See MAINTAINERS file Signed-off-by: Matthew Fioravante --- Change since last revision * Maintain alphabetical order * add slashes to directories diff --git a/MAINTAINERS b/MAINTAINERS index 094fe9e..0bde721 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -242,6 +242,21 @@ S: Supported T: hg http://xenbits.xen.org/linux-2.6.18-xen.hg F: drivers/xen/usb*/ +VTPM +M: Matthew Fioravante +S: Supported +F: tools/vtpm/ +F: tools/vtpm_manager/ +F: extras/minios-os/tpmfront.c +F: extras/minios-os/tpmback.c +F: extras/minios-os/tpm-tis.c +F: extras/minios-os/include/tpmfront.h +F: extras/minios-os/include/tpmback.h +F: extras/minios-os/include/tpm-tis.h +F: stubdom/vtpm/ +F: stubdom/vtpmmgr/ +F: docs/misc/vtpm.txt + X86 ARCHITECTURE M: Keir Fraser M: Jan Beulich -- 1.7.4.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 14:07:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:07:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ38Q-0004r0-0h; Tue, 02 Oct 2012 14:07:42 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ38O-0004qi-VS for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:07:41 +0000 Received: from [85.158.138.51:21956] by server-3.bemta-3.messagelabs.com id 0F/24-25962-C25FA605; Tue, 02 Oct 2012 14:07:40 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-4.tower-174.messagelabs.com!1349186857!32306400!1 X-Originating-IP: [128.244.251.36] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20672 invoked from network); 2 Oct 2012 14:07:38 -0000 Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36) by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 14:07:38 -0000 Received: from ([128.244.207.89]) by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.154106902; Tue, 02 Oct 2012 10:07:31 -0400 Message-ID: <506AF4D2.4010904@jhuapl.edu> Date: Tue, 02 Oct 2012 10:06:10 -0400 From: Matthew Fioravante User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Ian Campbell References: <1348765860-11359-1-git-send-email-matthew.fioravante@jhuapl.edu> <1349184862.650.52.camel@zakaz.uk.xensource.com> In-Reply-To: <1349184862.650.52.camel@zakaz.uk.xensource.com> X-Enigmail-Version: 1.4.4 Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 09/11] add iomem support to libxl X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6852169546263713510==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a cryptographically signed message in MIME format. --===============6852169546263713510== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090009030703060109020103" This is a cryptographically signed message in MIME format. --------------ms090009030703060109020103 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/02/2012 09:34 AM, Ian Campbell wrote: > On Thu, 2012-09-27 at 18:10 +0100, Matthew Fioravante wrote: >> This patch adds a new option for xen config files for >> directly mapping hardware io memory into a vm. >> >> Signed-off-by: Matthew Fioravante >> >> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5 >> index 013270d..428da21 100644 >> --- a/docs/man/xl.cfg.pod.5 >> +++ b/docs/man/xl.cfg.pod.5 >> @@ -496,6 +496,17 @@ is given in hexadecimal and may either a span e.g= =2E C<2f8-2ff> >> It is recommended to use this option only for trusted VMs under >> administrator control. >> =20 >> +=3Ditem B >> + >> +Allow guest to access specific hardware I/O memory pages. B >> +is a physical page number. B is the number >> +of pages beginning with B to allow access. Both values >> +must be given in hexadecimal. >> + >> +It is recommended to use this option only for trusted VMs under >> +administrator control. >> + >> + >> =3Ditem B >> =20 >> Allow a guest to access specific physical IRQs. >> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c >> index ef17f05..6cb586b 100644 >> --- a/tools/libxl/libxl_create.c >> +++ b/tools/libxl/libxl_create.c >> @@ -963,6 +963,24 @@ static void domcreate_launch_dm(libxl__egc *egc, = libxl__multidev *multidev, >> } >> } >> =20 >> + for (i =3D 0; i < d_config->b_info.num_iomem; i++) { >> + libxl_iomem_range *io =3D &d_config->b_info.iomem[i]; >> + >> + LOG(DEBUG, "dom%d iomem %"PRIx64"-%"PRIx64, >> + domid, io->start, io->start + io->number - 1); >> + >> + ret =3D xc_domain_iomem_permission(CTX->xch, domid, >> + io->start, io->number, 1); >> + if ( ret<0 ) { > This should be > if (ret < 0) { Looks like it was like that also for ioports and irqs. I fixed all 3. > >> + LOGE(ERROR, >> + "failed give dom%d access to iomem range %"PRIx64"-%= "PRIx64, >> + domid, io->start, io->start + io->number - 1); >> + ret =3D ERROR_FAIL; >> + } >> + } >> + >> + >> + >> for (i =3D 0; i < d_config->num_nics; i++) { >> /* We have to init the nic here, because we still haven't >> * called libxl_device_nic_add at this point, but qemu needs >> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl= >> index 6d5c578..cf83c60 100644 >> --- a/tools/libxl/libxl_types.idl >> +++ b/tools/libxl/libxl_types.idl >> @@ -140,6 +140,11 @@ libxl_ioport_range =3D Struct("ioport_range", [ >> ("number", uint32), >> ]) >> =20 >> +libxl_iomem_range =3D Struct("iomem_range", [ >> + ("start", uint64), >> + ("number", uint64), >> + ]) >> + >> libxl_vga_interface_info =3D Struct("vga_interface_info", [ >> ("kind", libxl_vga_interface_type), >> ]) >> @@ -284,6 +289,7 @@ libxl_domain_build_info =3D Struct("domain_build_i= nfo",[ >> =20 >> ("ioports", Array(libxl_ioport_range, "num_ioports")), >> ("irqs", Array(uint32, "num_irqs")), >> + ("iomem", Array(libxl_iomem_range, "num_iomem")), >> =20 >> ("u", KeyedUnion(None, libxl_domain_type, "type", >> [("hvm", Struct(None, [("firmware", string), >> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c >> index 1627cac..fe8e925 100644 >> --- a/tools/libxl/xl_cmdimpl.c >> +++ b/tools/libxl/xl_cmdimpl.c >> @@ -574,8 +574,8 @@ static void parse_config_data(const char *config_s= ource, >> long l; >> XLU_Config *config; >> XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids; >> - XLU_ConfigList *ioports, *irqs; >> - int num_ioports, num_irqs; >> + XLU_ConfigList *ioports, *irqs, *iomem; >> + int num_ioports, num_irqs, num_iomem; >> int pci_power_mgmt =3D 0; >> int pci_msitranslate =3D 0; >> int pci_permissive =3D 0; >> @@ -1005,6 +1005,30 @@ static void parse_config_data(const char *confi= g_source, >> } >> } >> =20 >> + if (!xlu_cfg_get_list(config, "iomem", &iomem, &num_iomem, 0)) { >> + b_info->num_iomem =3D num_iomem; >> + b_info->iomem =3D calloc(num_iomem, sizeof(*b_info->iomem)); >> + if (b_info->iomem =3D=3D NULL) { >> + fprintf(stderr, "unable to allocate memory for iomem\n");= >> + exit(-1); >> + } >> + for (i =3D 0; i < num_iomem; i++) { >> + buf =3D xlu_cfg_get_listitem (iomem, i); >> + if (!buf) { >> + fprintf(stderr, >> + "xl: Unable to get element %d in iomem list\n= ", i); >> + exit(1); >> + } >> + if(sscanf(buf, "%" SCNx64",%" SCNx64, &b_info->iomem[i].s= tart, &b_info->iomem[i].number) !=3D 2) { > Can we split this over multiple lines please, to keep it under the 75-8= 0 > column limit mention in coding style. fixed > >> + fprintf(stderr, >> + "xl: Invalid argument parsing iomem: %s\n", bu= f); >> + exit(1); >> + } >> + } >> + } >> + >> + >> + >> if (!xlu_cfg_get_list (config, "disk", &vbds, 0, 0)) { >> d_config->num_disks =3D 0; >> d_config->disks =3D NULL; > --------------ms090009030703060109020103 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4 NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50 ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz 4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTEyMTAwMjE0MDYxMFowIwYJKoZIhvcNAQkEMRYEFC4d4YlYP6DWLsSL kzNlqVF8Dx3SMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYALKJ4uuACKZz3Udd6E/XgwOt/KX0AwZkS4 +I4apoJeI11modXzlcpxefZ4j7hxde83Ux0XebA1ijU+nsg8EY06rtLoaxXrHm2fpNDiiatL r5NRz2FuGzod4c97xeCjPxHXlHU8FJJjPPXnydFt2PQZMDAQdthrGdMx8DqAePkw1AAAAAAA AA== --------------ms090009030703060109020103-- --===============6852169546263713510== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6852169546263713510==-- From xen-devel-bounces@lists.xen.org Tue Oct 02 14:07:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:07:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ38Q-0004r0-0h; Tue, 02 Oct 2012 14:07:42 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ38O-0004qi-VS for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:07:41 +0000 Received: from [85.158.138.51:21956] by server-3.bemta-3.messagelabs.com id 0F/24-25962-C25FA605; Tue, 02 Oct 2012 14:07:40 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-4.tower-174.messagelabs.com!1349186857!32306400!1 X-Originating-IP: [128.244.251.36] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20672 invoked from network); 2 Oct 2012 14:07:38 -0000 Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36) by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 14:07:38 -0000 Received: from ([128.244.207.89]) by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.154106902; Tue, 02 Oct 2012 10:07:31 -0400 Message-ID: <506AF4D2.4010904@jhuapl.edu> Date: Tue, 02 Oct 2012 10:06:10 -0400 From: Matthew Fioravante User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Ian Campbell References: <1348765860-11359-1-git-send-email-matthew.fioravante@jhuapl.edu> <1349184862.650.52.camel@zakaz.uk.xensource.com> In-Reply-To: <1349184862.650.52.camel@zakaz.uk.xensource.com> X-Enigmail-Version: 1.4.4 Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 09/11] add iomem support to libxl X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6852169546263713510==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a cryptographically signed message in MIME format. --===============6852169546263713510== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090009030703060109020103" This is a cryptographically signed message in MIME format. --------------ms090009030703060109020103 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/02/2012 09:34 AM, Ian Campbell wrote: > On Thu, 2012-09-27 at 18:10 +0100, Matthew Fioravante wrote: >> This patch adds a new option for xen config files for >> directly mapping hardware io memory into a vm. >> >> Signed-off-by: Matthew Fioravante >> >> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5 >> index 013270d..428da21 100644 >> --- a/docs/man/xl.cfg.pod.5 >> +++ b/docs/man/xl.cfg.pod.5 >> @@ -496,6 +496,17 @@ is given in hexadecimal and may either a span e.g= =2E C<2f8-2ff> >> It is recommended to use this option only for trusted VMs under >> administrator control. >> =20 >> +=3Ditem B >> + >> +Allow guest to access specific hardware I/O memory pages. B >> +is a physical page number. B is the number >> +of pages beginning with B to allow access. Both values >> +must be given in hexadecimal. >> + >> +It is recommended to use this option only for trusted VMs under >> +administrator control. >> + >> + >> =3Ditem B >> =20 >> Allow a guest to access specific physical IRQs. >> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c >> index ef17f05..6cb586b 100644 >> --- a/tools/libxl/libxl_create.c >> +++ b/tools/libxl/libxl_create.c >> @@ -963,6 +963,24 @@ static void domcreate_launch_dm(libxl__egc *egc, = libxl__multidev *multidev, >> } >> } >> =20 >> + for (i =3D 0; i < d_config->b_info.num_iomem; i++) { >> + libxl_iomem_range *io =3D &d_config->b_info.iomem[i]; >> + >> + LOG(DEBUG, "dom%d iomem %"PRIx64"-%"PRIx64, >> + domid, io->start, io->start + io->number - 1); >> + >> + ret =3D xc_domain_iomem_permission(CTX->xch, domid, >> + io->start, io->number, 1); >> + if ( ret<0 ) { > This should be > if (ret < 0) { Looks like it was like that also for ioports and irqs. I fixed all 3. > >> + LOGE(ERROR, >> + "failed give dom%d access to iomem range %"PRIx64"-%= "PRIx64, >> + domid, io->start, io->start + io->number - 1); >> + ret =3D ERROR_FAIL; >> + } >> + } >> + >> + >> + >> for (i =3D 0; i < d_config->num_nics; i++) { >> /* We have to init the nic here, because we still haven't >> * called libxl_device_nic_add at this point, but qemu needs >> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl= >> index 6d5c578..cf83c60 100644 >> --- a/tools/libxl/libxl_types.idl >> +++ b/tools/libxl/libxl_types.idl >> @@ -140,6 +140,11 @@ libxl_ioport_range =3D Struct("ioport_range", [ >> ("number", uint32), >> ]) >> =20 >> +libxl_iomem_range =3D Struct("iomem_range", [ >> + ("start", uint64), >> + ("number", uint64), >> + ]) >> + >> libxl_vga_interface_info =3D Struct("vga_interface_info", [ >> ("kind", libxl_vga_interface_type), >> ]) >> @@ -284,6 +289,7 @@ libxl_domain_build_info =3D Struct("domain_build_i= nfo",[ >> =20 >> ("ioports", Array(libxl_ioport_range, "num_ioports")), >> ("irqs", Array(uint32, "num_irqs")), >> + ("iomem", Array(libxl_iomem_range, "num_iomem")), >> =20 >> ("u", KeyedUnion(None, libxl_domain_type, "type", >> [("hvm", Struct(None, [("firmware", string), >> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c >> index 1627cac..fe8e925 100644 >> --- a/tools/libxl/xl_cmdimpl.c >> +++ b/tools/libxl/xl_cmdimpl.c >> @@ -574,8 +574,8 @@ static void parse_config_data(const char *config_s= ource, >> long l; >> XLU_Config *config; >> XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids; >> - XLU_ConfigList *ioports, *irqs; >> - int num_ioports, num_irqs; >> + XLU_ConfigList *ioports, *irqs, *iomem; >> + int num_ioports, num_irqs, num_iomem; >> int pci_power_mgmt =3D 0; >> int pci_msitranslate =3D 0; >> int pci_permissive =3D 0; >> @@ -1005,6 +1005,30 @@ static void parse_config_data(const char *confi= g_source, >> } >> } >> =20 >> + if (!xlu_cfg_get_list(config, "iomem", &iomem, &num_iomem, 0)) { >> + b_info->num_iomem =3D num_iomem; >> + b_info->iomem =3D calloc(num_iomem, sizeof(*b_info->iomem)); >> + if (b_info->iomem =3D=3D NULL) { >> + fprintf(stderr, "unable to allocate memory for iomem\n");= >> + exit(-1); >> + } >> + for (i =3D 0; i < num_iomem; i++) { >> + buf =3D xlu_cfg_get_listitem (iomem, i); >> + if (!buf) { >> + fprintf(stderr, >> + "xl: Unable to get element %d in iomem list\n= ", i); >> + exit(1); >> + } >> + if(sscanf(buf, "%" SCNx64",%" SCNx64, &b_info->iomem[i].s= tart, &b_info->iomem[i].number) !=3D 2) { > Can we split this over multiple lines please, to keep it under the 75-8= 0 > column limit mention in coding style. fixed > >> + fprintf(stderr, >> + "xl: Invalid argument parsing iomem: %s\n", bu= f); >> + exit(1); >> + } >> + } >> + } >> + >> + >> + >> if (!xlu_cfg_get_list (config, "disk", &vbds, 0, 0)) { >> d_config->num_disks =3D 0; >> d_config->disks =3D NULL; > --------------ms090009030703060109020103 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4 NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50 ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz 4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTEyMTAwMjE0MDYxMFowIwYJKoZIhvcNAQkEMRYEFC4d4YlYP6DWLsSL kzNlqVF8Dx3SMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYALKJ4uuACKZz3Udd6E/XgwOt/KX0AwZkS4 +I4apoJeI11modXzlcpxefZ4j7hxde83Ux0XebA1ijU+nsg8EY06rtLoaxXrHm2fpNDiiatL r5NRz2FuGzod4c97xeCjPxHXlHU8FJJjPPXnydFt2PQZMDAQdthrGdMx8DqAePkw1AAAAAAA AA== --------------ms090009030703060109020103-- --===============6852169546263713510== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6852169546263713510==-- From xen-devel-bounces@lists.xen.org Tue Oct 02 14:10:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:10:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3Ah-00055M-Io; Tue, 02 Oct 2012 14:10:03 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3Af-000557-Ro for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:10:02 +0000 Received: from [85.158.138.51:51327] by server-7.bemta-3.messagelabs.com id 93/4E-15765-9B5FA605; Tue, 02 Oct 2012 14:10:01 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-14.tower-174.messagelabs.com!1349186998!26475712!1 X-Originating-IP: [128.244.251.36] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3528 invoked from network); 2 Oct 2012 14:10:00 -0000 Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36) by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 14:10:00 -0000 Received: from ([128.244.207.97]) by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.154107196; Tue, 02 Oct 2012 10:09:54 -0400 From: Matthew Fioravante To: xen-devel@lists.xen.org, Ian.Campbell@citrix.com Date: Tue, 2 Oct 2012 10:09:52 -0400 Message-Id: <1349186992-14871-1-git-send-email-matthew.fioravante@jhuapl.edu> X-Mailer: git-send-email 1.7.4.4 Cc: Matthew Fioravante Subject: [Xen-devel] [PATCH 09/12] add iomem support to libxl X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch adds a new option for xen config files for directly mapping hardware io memory into a vm. Signed-off-by: Matthew Fioravante --- Changes since last * fix minor spacing errors * condense long line to 80 column width limit diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5 index 013270d..428da21 100644 --- a/docs/man/xl.cfg.pod.5 +++ b/docs/man/xl.cfg.pod.5 @@ -496,6 +496,17 @@ is given in hexadecimal and may either a span e.g. C<2f8-2ff> It is recommended to use this option only for trusted VMs under administrator control. +=item B + +Allow guest to access specific hardware I/O memory pages. B +is a physical page number. B is the number +of pages beginning with B to allow access. Both values +must be given in hexadecimal. + +It is recommended to use this option only for trusted VMs under +administrator control. + + =item B Allow a guest to access specific physical IRQs. diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index ef17f05..96f9018 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -942,7 +942,7 @@ static void domcreate_launch_dm(libxl__egc *egc, libxl__multidev *multidev, ret = xc_domain_ioport_permission(CTX->xch, domid, io->first, io->number, 1); - if ( ret<0 ){ + if ( ret < 0 ){ LOGE(ERROR, "failed give dom%d access to ioports %"PRIx32"-%"PRIx32, domid, io->first, io->first + io->number - 1); @@ -956,13 +956,31 @@ static void domcreate_launch_dm(libxl__egc *egc, libxl__multidev *multidev, LOG(DEBUG, "dom%d irq %"PRIx32, domid, irq); ret = xc_domain_irq_permission(CTX->xch, domid, irq, 1); - if ( ret<0 ){ + if ( ret < 0 ){ LOGE(ERROR, "failed give dom%d access to irq %"PRId32, domid, irq); ret = ERROR_FAIL; } } + for (i = 0; i < d_config->b_info.num_iomem; i++) { + libxl_iomem_range *io = &d_config->b_info.iomem[i]; + + LOG(DEBUG, "dom%d iomem %"PRIx64"-%"PRIx64, + domid, io->start, io->start + io->number - 1); + + ret = xc_domain_iomem_permission(CTX->xch, domid, + io->start, io->number, 1); + if ( ret < 0 ) { + LOGE(ERROR, + "failed give dom%d access to iomem range %"PRIx64"-%"PRIx64, + domid, io->start, io->start + io->number - 1); + ret = ERROR_FAIL; + } + } + + + for (i = 0; i < d_config->num_nics; i++) { /* We have to init the nic here, because we still haven't * called libxl_device_nic_add at this point, but qemu needs diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl index 6d5c578..cf83c60 100644 --- a/tools/libxl/libxl_types.idl +++ b/tools/libxl/libxl_types.idl @@ -140,6 +140,11 @@ libxl_ioport_range = Struct("ioport_range", [ ("number", uint32), ]) +libxl_iomem_range = Struct("iomem_range", [ + ("start", uint64), + ("number", uint64), + ]) + libxl_vga_interface_info = Struct("vga_interface_info", [ ("kind", libxl_vga_interface_type), ]) @@ -284,6 +289,7 @@ libxl_domain_build_info = Struct("domain_build_info",[ ("ioports", Array(libxl_ioport_range, "num_ioports")), ("irqs", Array(uint32, "num_irqs")), + ("iomem", Array(libxl_iomem_range, "num_iomem")), ("u", KeyedUnion(None, libxl_domain_type, "type", [("hvm", Struct(None, [("firmware", string), diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c index 1627cac..f13d983 100644 --- a/tools/libxl/xl_cmdimpl.c +++ b/tools/libxl/xl_cmdimpl.c @@ -574,8 +574,8 @@ static void parse_config_data(const char *config_source, long l; XLU_Config *config; XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids; - XLU_ConfigList *ioports, *irqs; - int num_ioports, num_irqs; + XLU_ConfigList *ioports, *irqs, *iomem; + int num_ioports, num_irqs, num_iomem; int pci_power_mgmt = 0; int pci_msitranslate = 0; int pci_permissive = 0; @@ -1005,6 +1005,33 @@ static void parse_config_data(const char *config_source, } } + if (!xlu_cfg_get_list(config, "iomem", &iomem, &num_iomem, 0)) { + b_info->num_iomem = num_iomem; + b_info->iomem = calloc(num_iomem, sizeof(*b_info->iomem)); + if (b_info->iomem == NULL) { + fprintf(stderr, "unable to allocate memory for iomem\n"); + exit(-1); + } + for (i = 0; i < num_iomem; i++) { + buf = xlu_cfg_get_listitem (iomem, i); + if (!buf) { + fprintf(stderr, + "xl: Unable to get element %d in iomem list\n", i); + exit(1); + } + if(sscanf(buf, "%" SCNx64",%" SCNx64, + &b_info->iomem[i].start, + &b_info->iomem[i].number) + != 2) { + fprintf(stderr, + "xl: Invalid argument parsing iomem: %s\n", buf); + exit(1); + } + } + } + + + if (!xlu_cfg_get_list (config, "disk", &vbds, 0, 0)) { d_config->num_disks = 0; d_config->disks = NULL; -- 1.7.4.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 14:10:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:10:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3Ah-00055M-Io; Tue, 02 Oct 2012 14:10:03 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3Af-000557-Ro for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:10:02 +0000 Received: from [85.158.138.51:51327] by server-7.bemta-3.messagelabs.com id 93/4E-15765-9B5FA605; Tue, 02 Oct 2012 14:10:01 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-14.tower-174.messagelabs.com!1349186998!26475712!1 X-Originating-IP: [128.244.251.36] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3528 invoked from network); 2 Oct 2012 14:10:00 -0000 Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36) by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 14:10:00 -0000 Received: from ([128.244.207.97]) by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.154107196; Tue, 02 Oct 2012 10:09:54 -0400 From: Matthew Fioravante To: xen-devel@lists.xen.org, Ian.Campbell@citrix.com Date: Tue, 2 Oct 2012 10:09:52 -0400 Message-Id: <1349186992-14871-1-git-send-email-matthew.fioravante@jhuapl.edu> X-Mailer: git-send-email 1.7.4.4 Cc: Matthew Fioravante Subject: [Xen-devel] [PATCH 09/12] add iomem support to libxl X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch adds a new option for xen config files for directly mapping hardware io memory into a vm. Signed-off-by: Matthew Fioravante --- Changes since last * fix minor spacing errors * condense long line to 80 column width limit diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5 index 013270d..428da21 100644 --- a/docs/man/xl.cfg.pod.5 +++ b/docs/man/xl.cfg.pod.5 @@ -496,6 +496,17 @@ is given in hexadecimal and may either a span e.g. C<2f8-2ff> It is recommended to use this option only for trusted VMs under administrator control. +=item B + +Allow guest to access specific hardware I/O memory pages. B +is a physical page number. B is the number +of pages beginning with B to allow access. Both values +must be given in hexadecimal. + +It is recommended to use this option only for trusted VMs under +administrator control. + + =item B Allow a guest to access specific physical IRQs. diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index ef17f05..96f9018 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -942,7 +942,7 @@ static void domcreate_launch_dm(libxl__egc *egc, libxl__multidev *multidev, ret = xc_domain_ioport_permission(CTX->xch, domid, io->first, io->number, 1); - if ( ret<0 ){ + if ( ret < 0 ){ LOGE(ERROR, "failed give dom%d access to ioports %"PRIx32"-%"PRIx32, domid, io->first, io->first + io->number - 1); @@ -956,13 +956,31 @@ static void domcreate_launch_dm(libxl__egc *egc, libxl__multidev *multidev, LOG(DEBUG, "dom%d irq %"PRIx32, domid, irq); ret = xc_domain_irq_permission(CTX->xch, domid, irq, 1); - if ( ret<0 ){ + if ( ret < 0 ){ LOGE(ERROR, "failed give dom%d access to irq %"PRId32, domid, irq); ret = ERROR_FAIL; } } + for (i = 0; i < d_config->b_info.num_iomem; i++) { + libxl_iomem_range *io = &d_config->b_info.iomem[i]; + + LOG(DEBUG, "dom%d iomem %"PRIx64"-%"PRIx64, + domid, io->start, io->start + io->number - 1); + + ret = xc_domain_iomem_permission(CTX->xch, domid, + io->start, io->number, 1); + if ( ret < 0 ) { + LOGE(ERROR, + "failed give dom%d access to iomem range %"PRIx64"-%"PRIx64, + domid, io->start, io->start + io->number - 1); + ret = ERROR_FAIL; + } + } + + + for (i = 0; i < d_config->num_nics; i++) { /* We have to init the nic here, because we still haven't * called libxl_device_nic_add at this point, but qemu needs diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl index 6d5c578..cf83c60 100644 --- a/tools/libxl/libxl_types.idl +++ b/tools/libxl/libxl_types.idl @@ -140,6 +140,11 @@ libxl_ioport_range = Struct("ioport_range", [ ("number", uint32), ]) +libxl_iomem_range = Struct("iomem_range", [ + ("start", uint64), + ("number", uint64), + ]) + libxl_vga_interface_info = Struct("vga_interface_info", [ ("kind", libxl_vga_interface_type), ]) @@ -284,6 +289,7 @@ libxl_domain_build_info = Struct("domain_build_info",[ ("ioports", Array(libxl_ioport_range, "num_ioports")), ("irqs", Array(uint32, "num_irqs")), + ("iomem", Array(libxl_iomem_range, "num_iomem")), ("u", KeyedUnion(None, libxl_domain_type, "type", [("hvm", Struct(None, [("firmware", string), diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c index 1627cac..f13d983 100644 --- a/tools/libxl/xl_cmdimpl.c +++ b/tools/libxl/xl_cmdimpl.c @@ -574,8 +574,8 @@ static void parse_config_data(const char *config_source, long l; XLU_Config *config; XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids; - XLU_ConfigList *ioports, *irqs; - int num_ioports, num_irqs; + XLU_ConfigList *ioports, *irqs, *iomem; + int num_ioports, num_irqs, num_iomem; int pci_power_mgmt = 0; int pci_msitranslate = 0; int pci_permissive = 0; @@ -1005,6 +1005,33 @@ static void parse_config_data(const char *config_source, } } + if (!xlu_cfg_get_list(config, "iomem", &iomem, &num_iomem, 0)) { + b_info->num_iomem = num_iomem; + b_info->iomem = calloc(num_iomem, sizeof(*b_info->iomem)); + if (b_info->iomem == NULL) { + fprintf(stderr, "unable to allocate memory for iomem\n"); + exit(-1); + } + for (i = 0; i < num_iomem; i++) { + buf = xlu_cfg_get_listitem (iomem, i); + if (!buf) { + fprintf(stderr, + "xl: Unable to get element %d in iomem list\n", i); + exit(1); + } + if(sscanf(buf, "%" SCNx64",%" SCNx64, + &b_info->iomem[i].start, + &b_info->iomem[i].number) + != 2) { + fprintf(stderr, + "xl: Invalid argument parsing iomem: %s\n", buf); + exit(1); + } + } + } + + + if (!xlu_cfg_get_list (config, "disk", &vbds, 0, 0)) { d_config->num_disks = 0; d_config->disks = NULL; -- 1.7.4.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 14:12:09 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:12:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3CY-0005FS-8J; Tue, 02 Oct 2012 14:11:58 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3CW-0005FJ-OY for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:11:56 +0000 Received: from [85.158.139.211:30523] by server-11.bemta-5.messagelabs.com id 73/EA-13866-C26FA605; Tue, 02 Oct 2012 14:11:56 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-7.tower-206.messagelabs.com!1349187114!20325906!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzc3NzIy\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30009 invoked from network); 2 Oct 2012 14:11:55 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 14:11:55 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q92EBTKM000496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Oct 2012 14:11:30 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q92EBS8M017580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Oct 2012 14:11:29 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q92EBS2k001987; Tue, 2 Oct 2012 09:11:28 -0500 Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 02 Oct 2012 07:11:27 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 245BE4032D; Tue, 2 Oct 2012 10:00:03 -0400 (EDT) Date: Tue, 2 Oct 2012 10:00:03 -0400 From: Konrad Rzeszutek Wilk To: M A Young Message-ID: <20121002140003.GC15735@phenom.dumpdata.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: Stefano Stabellini , xen-devel@lists.xen.org Subject: Re: [Xen-devel] some recent xen kernel bugs in Fedora X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, Oct 01, 2012 at 10:35:57PM +0100, M A Young wrote: > There have been a few xen kernel bug reported recently in Fedora. > > In https://bugzilla.redhat.com/show_bug.cgi?id=861977 someone is > getting the error WARNING: at arch/x86/xen/setup.c:88 > xen_memory_setup with the kernel 3.5.4-2.fc17.x86_64 (which is > roughly 3.5.4 plus patches from the 3.5.5 patch queue including the > backports of > xen/boot: Disable NUMA for PV guests 8d54db795dfb1049d45dc34f0dddbc5347ec5642 > xen/boot: Disable BIOS SMP MP table search bd49940a35ec7d488ae63bd625639893b3385b97 > xen/m2p: do not reuse kmap_op->dev_bus_addr 2fc136eecd0c647a6b13fcd00d0c41a1a28f35a5 > plus xen-pciback-restore-pci-config-space-after-FLR.patch Oh, so that WARN was suppose to catch rather weird cases - and it did! FYI, It was added by xen/setup: Fix one-off error when adding for-balloon PFNs to the P2M. Let me help figure out what the issue is. > > In https://bugzilla.redhat.com/show_bug.cgi?id=858893 there is a > NULL pointer dereference at xennet_poll+0x94e/0xf10 in > 3.6.0-0.rc2.git2.1.fc18.x86_64 That should be fixed with 3.6.0-rc5. > > There is also https://bugzilla.redhat.com/show_bug.cgi?id=859466 > where xen 4.2 does not boot on MacBook with a 3.5 kernel unless > xsave=off which seems to relate to > https://lists.fedoraproject.org/pipermail/xen/2012-August/005879.html There was another discussion and the Fedora kernel engineers mentioned they removed the patch that broke this. Here is the thread: https://bugzilla.redhat.com/show_bug.cgi?id=859466 > > Michael Young _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 14:12:09 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:12:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3CY-0005FS-8J; Tue, 02 Oct 2012 14:11:58 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3CW-0005FJ-OY for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:11:56 +0000 Received: from [85.158.139.211:30523] by server-11.bemta-5.messagelabs.com id 73/EA-13866-C26FA605; Tue, 02 Oct 2012 14:11:56 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-7.tower-206.messagelabs.com!1349187114!20325906!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzc3NzIy\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30009 invoked from network); 2 Oct 2012 14:11:55 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 14:11:55 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q92EBTKM000496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Oct 2012 14:11:30 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q92EBS8M017580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Oct 2012 14:11:29 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q92EBS2k001987; Tue, 2 Oct 2012 09:11:28 -0500 Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 02 Oct 2012 07:11:27 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 245BE4032D; Tue, 2 Oct 2012 10:00:03 -0400 (EDT) Date: Tue, 2 Oct 2012 10:00:03 -0400 From: Konrad Rzeszutek Wilk To: M A Young Message-ID: <20121002140003.GC15735@phenom.dumpdata.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: Stefano Stabellini , xen-devel@lists.xen.org Subject: Re: [Xen-devel] some recent xen kernel bugs in Fedora X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, Oct 01, 2012 at 10:35:57PM +0100, M A Young wrote: > There have been a few xen kernel bug reported recently in Fedora. > > In https://bugzilla.redhat.com/show_bug.cgi?id=861977 someone is > getting the error WARNING: at arch/x86/xen/setup.c:88 > xen_memory_setup with the kernel 3.5.4-2.fc17.x86_64 (which is > roughly 3.5.4 plus patches from the 3.5.5 patch queue including the > backports of > xen/boot: Disable NUMA for PV guests 8d54db795dfb1049d45dc34f0dddbc5347ec5642 > xen/boot: Disable BIOS SMP MP table search bd49940a35ec7d488ae63bd625639893b3385b97 > xen/m2p: do not reuse kmap_op->dev_bus_addr 2fc136eecd0c647a6b13fcd00d0c41a1a28f35a5 > plus xen-pciback-restore-pci-config-space-after-FLR.patch Oh, so that WARN was suppose to catch rather weird cases - and it did! FYI, It was added by xen/setup: Fix one-off error when adding for-balloon PFNs to the P2M. Let me help figure out what the issue is. > > In https://bugzilla.redhat.com/show_bug.cgi?id=858893 there is a > NULL pointer dereference at xennet_poll+0x94e/0xf10 in > 3.6.0-0.rc2.git2.1.fc18.x86_64 That should be fixed with 3.6.0-rc5. > > There is also https://bugzilla.redhat.com/show_bug.cgi?id=859466 > where xen 4.2 does not boot on MacBook with a 3.5 kernel unless > xsave=off which seems to relate to > https://lists.fedoraproject.org/pipermail/xen/2012-August/005879.html There was another discussion and the Fedora kernel engineers mentioned they removed the patch that broke this. Here is the thread: https://bugzilla.redhat.com/show_bug.cgi?id=859466 > > Michael Young _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 14:12:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:12:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3Cd-0005GD-Kb; Tue, 02 Oct 2012 14:12:03 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3Cb-0005FK-WF for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:12:02 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1349187112!7079412!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1205 invoked from network); 2 Oct 2012 14:11:52 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 14:11:52 -0000 X-IronPort-AV: E=Sophos;i="4.80,523,1344211200"; d="scan'208";a="14895355" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 14:11:52 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 15:11:52 +0100 Message-ID: <1349187110.650.73.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Matthew Fioravante Date: Tue, 2 Oct 2012 15:11:50 +0100 In-Reply-To: <1349186658-14536-1-git-send-email-matthew.fioravante@jhuapl.edu> References: <1349186658-14536-1-git-send-email-matthew.fioravante@jhuapl.edu> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] Matthew Fioravante now maintains VTPM X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-10-02 at 15:04 +0100, Matthew Fioravante wrote: > See MAINTAINERS file > > Signed-off-by: Matthew Fioravante Acked-by: Ian Campbell > --- > Change since last revision > * Maintain alphabetical order > * add slashes to directories > > diff --git a/MAINTAINERS b/MAINTAINERS > index 094fe9e..0bde721 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -242,6 +242,21 @@ S: Supported > T: hg http://xenbits.xen.org/linux-2.6.18-xen.hg > F: drivers/xen/usb*/ > > +VTPM > +M: Matthew Fioravante > +S: Supported > +F: tools/vtpm/ > +F: tools/vtpm_manager/ > +F: extras/minios-os/tpmfront.c > +F: extras/minios-os/tpmback.c > +F: extras/minios-os/tpm-tis.c > +F: extras/minios-os/include/tpmfront.h > +F: extras/minios-os/include/tpmback.h > +F: extras/minios-os/include/tpm-tis.h > +F: stubdom/vtpm/ > +F: stubdom/vtpmmgr/ > +F: docs/misc/vtpm.txt > + > X86 ARCHITECTURE > M: Keir Fraser > M: Jan Beulich _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 14:12:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:12:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3Cd-0005GD-Kb; Tue, 02 Oct 2012 14:12:03 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3Cb-0005FK-WF for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:12:02 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1349187112!7079412!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1205 invoked from network); 2 Oct 2012 14:11:52 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 14:11:52 -0000 X-IronPort-AV: E=Sophos;i="4.80,523,1344211200"; d="scan'208";a="14895355" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 14:11:52 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 15:11:52 +0100 Message-ID: <1349187110.650.73.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Matthew Fioravante Date: Tue, 2 Oct 2012 15:11:50 +0100 In-Reply-To: <1349186658-14536-1-git-send-email-matthew.fioravante@jhuapl.edu> References: <1349186658-14536-1-git-send-email-matthew.fioravante@jhuapl.edu> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] Matthew Fioravante now maintains VTPM X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-10-02 at 15:04 +0100, Matthew Fioravante wrote: > See MAINTAINERS file > > Signed-off-by: Matthew Fioravante Acked-by: Ian Campbell > --- > Change since last revision > * Maintain alphabetical order > * add slashes to directories > > diff --git a/MAINTAINERS b/MAINTAINERS > index 094fe9e..0bde721 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -242,6 +242,21 @@ S: Supported > T: hg http://xenbits.xen.org/linux-2.6.18-xen.hg > F: drivers/xen/usb*/ > > +VTPM > +M: Matthew Fioravante > +S: Supported > +F: tools/vtpm/ > +F: tools/vtpm_manager/ > +F: extras/minios-os/tpmfront.c > +F: extras/minios-os/tpmback.c > +F: extras/minios-os/tpm-tis.c > +F: extras/minios-os/include/tpmfront.h > +F: extras/minios-os/include/tpmback.h > +F: extras/minios-os/include/tpm-tis.h > +F: stubdom/vtpm/ > +F: stubdom/vtpmmgr/ > +F: docs/misc/vtpm.txt > + > X86 ARCHITECTURE > M: Keir Fraser > M: Jan Beulich _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 14:16:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:16:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3GM-0005f6-8g; Tue, 02 Oct 2012 14:15:54 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3GL-0005ew-9c for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:15:53 +0000 Received: from [85.158.143.35:25294] by server-2.bemta-4.messagelabs.com id E8/6B-06610-817FA605; Tue, 02 Oct 2012 14:15:52 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1349187349!13594667!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4813 invoked from network); 2 Oct 2012 14:15:50 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 14:15:50 -0000 X-IronPort-AV: E=Sophos;i="4.80,523,1344211200"; d="scan'208";a="14895466" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 14:15:47 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 15:15:47 +0100 Message-ID: <1349187346.650.74.camel@zakaz.uk.xensource.com> From: Ian Campbell To: George Dunlap Date: Tue, 2 Oct 2012 15:15:46 +0100 In-Reply-To: References: <20120929050455.GA21253@u002268147cd4502c336d.ant.amazon.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: Lars Kurth , Ian Jackson , "xen-devel@lists.xen.org" , Keir Fraser , Ben Guthro , Matt Wilson Subject: Re: [Xen-devel] [ANNOUNCE] Switching to git for primary Xen repositories X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, 2012-10-01 at 15:25 +0100, George Dunlap wrote: > +1. +1 > I actually prefer mercurial personally, but it's pretty clear that a > large % of devs are already using git for xen development, using a > mirror; and that's just silly. :-) I'm pretty comfortable with both git and hg but I've found myself using the git mirror more frequently recently. For committer type activities tools like git am and rebase -i etc are far superior to the hg equivalents, at least with the Squeeze versions of both tools. Ian. > > -George > > On Sun, Sep 30, 2012 at 10:15 PM, Ben Guthro wrote: > > +1 here. > > > > Having the SCM system consistent with the other 2 projects intimately tied > > with Xen (linux, and qemu) has definite advantages. > > > > > > On Sat, Sep 29, 2012 at 1:54 AM, Keir Fraser wrote: > >> > >> On 29/09/2012 06:04, "Matt Wilson" wrote: > >> > >> > On Fri, Sep 28, 2012 at 06:16:41PM +0100, Ian Jackson wrote: > >> >> Keir writes: > >> >>> Our plan therefore, with the 4.2.0 release soon out of the way, is > >> >>> to switch to git for all of our primary repositories. We will plan > >> >>> to mirror development activity into the old mercurial repositories > >> >>> at least in the short term. > >> >> > >> >> So if we're having a vote on this, as discussed: > >> >> > >> >> +1 > >> > > >> > Enthusiastic +1 > >> > >> +1 > >> > >> > Matt > >> > >> > >> > >> _______________________________________________ > >> Xen-devel mailing list > >> Xen-devel@lists.xen.org > >> http://lists.xen.org/xen-devel > > > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xen.org > > http://lists.xen.org/xen-devel > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 14:16:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:16:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3GM-0005f6-8g; Tue, 02 Oct 2012 14:15:54 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3GL-0005ew-9c for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:15:53 +0000 Received: from [85.158.143.35:25294] by server-2.bemta-4.messagelabs.com id E8/6B-06610-817FA605; Tue, 02 Oct 2012 14:15:52 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1349187349!13594667!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4813 invoked from network); 2 Oct 2012 14:15:50 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 14:15:50 -0000 X-IronPort-AV: E=Sophos;i="4.80,523,1344211200"; d="scan'208";a="14895466" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 14:15:47 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 15:15:47 +0100 Message-ID: <1349187346.650.74.camel@zakaz.uk.xensource.com> From: Ian Campbell To: George Dunlap Date: Tue, 2 Oct 2012 15:15:46 +0100 In-Reply-To: References: <20120929050455.GA21253@u002268147cd4502c336d.ant.amazon.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: Lars Kurth , Ian Jackson , "xen-devel@lists.xen.org" , Keir Fraser , Ben Guthro , Matt Wilson Subject: Re: [Xen-devel] [ANNOUNCE] Switching to git for primary Xen repositories X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, 2012-10-01 at 15:25 +0100, George Dunlap wrote: > +1. +1 > I actually prefer mercurial personally, but it's pretty clear that a > large % of devs are already using git for xen development, using a > mirror; and that's just silly. :-) I'm pretty comfortable with both git and hg but I've found myself using the git mirror more frequently recently. For committer type activities tools like git am and rebase -i etc are far superior to the hg equivalents, at least with the Squeeze versions of both tools. Ian. > > -George > > On Sun, Sep 30, 2012 at 10:15 PM, Ben Guthro wrote: > > +1 here. > > > > Having the SCM system consistent with the other 2 projects intimately tied > > with Xen (linux, and qemu) has definite advantages. > > > > > > On Sat, Sep 29, 2012 at 1:54 AM, Keir Fraser wrote: > >> > >> On 29/09/2012 06:04, "Matt Wilson" wrote: > >> > >> > On Fri, Sep 28, 2012 at 06:16:41PM +0100, Ian Jackson wrote: > >> >> Keir writes: > >> >>> Our plan therefore, with the 4.2.0 release soon out of the way, is > >> >>> to switch to git for all of our primary repositories. We will plan > >> >>> to mirror development activity into the old mercurial repositories > >> >>> at least in the short term. > >> >> > >> >> So if we're having a vote on this, as discussed: > >> >> > >> >> +1 > >> > > >> > Enthusiastic +1 > >> > >> +1 > >> > >> > Matt > >> > >> > >> > >> _______________________________________________ > >> Xen-devel mailing list > >> Xen-devel@lists.xen.org > >> http://lists.xen.org/xen-devel > > > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xen.org > > http://lists.xen.org/xen-devel > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 14:19:09 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:19:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3JF-0005rO-0T; Tue, 02 Oct 2012 14:18:53 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3JC-0005rD-T5 for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:18:51 +0000 Received: from [85.158.139.83:58157] by server-4.bemta-5.messagelabs.com id 84/CD-20767-AC7FA605; Tue, 02 Oct 2012 14:18:50 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-12.tower-182.messagelabs.com!1349187527!32896143!1 X-Originating-IP: [128.244.251.36] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16601 invoked from network); 2 Oct 2012 14:18:49 -0000 Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36) by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 14:18:49 -0000 Received: from ([128.244.207.89]) by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.154108432; Tue, 02 Oct 2012 10:18:29 -0400 Message-ID: <506AF764.5040701@jhuapl.edu> Date: Tue, 02 Oct 2012 10:17:08 -0400 From: Matthew Fioravante User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Ian Campbell References: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu> <1348765802-11314-8-git-send-email-matthew.fioravante@jhuapl.edu> <1349175465.650.39.camel@zakaz.uk.xensource.com> In-Reply-To: <1349175465.650.39.camel@zakaz.uk.xensource.com> X-Enigmail-Version: 1.4.4 Cc: "samuel.thibault@ens-lyon.org" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 08/11] add tpmfront, tpm_tis, and tpmback drivers to mini-os X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0195709421912400937==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a cryptographically signed message in MIME format. --===============0195709421912400937== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040103090501090501060108" This is a cryptographically signed message in MIME format. --------------ms040103090501090501060108 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/02/2012 06:57 AM, Ian Campbell wrote: >> diff --git a/extras/mini-os/include/tpm_tis.h b/extras/mini-os/include= /tpm_tis.h >> new file mode 100644 >> index 0000000..b463cea >> --- /dev/null >> +++ b/extras/mini-os/include/tpm_tis.h >> @@ -0,0 +1,74 @@ >> +/* >> + * Copyright (c) 2010-2012 United States Government, as represented b= y >> + * the Secretary of Defense. All rights reserved. >> + * >> + * This program is free software; you can redistribute it and/or >> + * modify it under the terms of the GNU General Public License versio= n 2 >> + * as published by the Free Software Foundation; or, when distributed= >> + * separately from the Linux kernel or incorporated into other >> + * software packages, subject to the following license: >> + * >> + * Permission is hereby granted, free of charge, to any person obtain= ing a copy >> + * of this source file (the "Software"), to deal in the Software with= out >> + * restriction, including without limitation the rights to use, copy,= modify, >> + * merge, publish, distribute, sublicense, and/or sell copies of the = Software, >> + * and to permit persons to whom the Software is furnished to do so, = subject to >> + * the following conditions: >> + * >> + * The above copyright notice and this permission notice shall be inc= luded in >> + * all copies or substantial portions of the Software. >> + * >> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EX= PRESS OR >> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTAB= ILITY, >> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT = SHALL THE >> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR O= THER >> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, AR= ISING >> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHE= R DEALINGS >> + * IN THE SOFTWARE. >> + * >> + * Based upon the files: >> + * drivers/char/tpm/tpm_tis.c >> + * drivers/char/tpm/tpm.c >> + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporatio= n > Given that then I don't think you have the authority to dual license > code owned by IBM as GPL or the MIT style thing above -- these files ar= e > subject to the licensing terms of those original files (which looks to > be GPL v2 only). > > It might be acceptable to have a GPL header as the primary followed by = a > "modifications by Matthew Fioravante/US Gov/Secretary Defense are also > licensed under... .MIT thing ...." but I'd want to see a second opinion= > on that I think. > > I didn't check all the other licensing thoroughly but I expect similar > comments will apply elsewhere too. As far as I understand (I'm in no way a copyright lawyer), there is a difference between copyright and license. What this is trying to convey is that the changes are copyrighted by the US Govt and the license being offered is GPLv2. > Ian. > > --------------ms040103090501090501060108 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4 NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50 ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz 4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTEyMTAwMjE0MTcwOFowIwYJKoZIhvcNAQkEMRYEFFWL1fSM6Yp+m19N vWdptFQL1coLMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBqDB+1lABAispxuiS32bbnuQMOCxtKT85z LxAayx9Q1H56j6lIyMpIJfghpPQLhvypCCyQS3CAUkRiv66aN1tILy/Nklkdkh2VJzY2OYMj pi7UyJ6uz6NpJom/1pAiwEoIg1es9IkQ0JSBQR6rjV4+KY6QI7E6eEtBzjxz3tlAZgAAAAAA AA== --------------ms040103090501090501060108-- --===============0195709421912400937== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============0195709421912400937==-- From xen-devel-bounces@lists.xen.org Tue Oct 02 14:19:09 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:19:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3JF-0005rO-0T; Tue, 02 Oct 2012 14:18:53 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3JC-0005rD-T5 for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:18:51 +0000 Received: from [85.158.139.83:58157] by server-4.bemta-5.messagelabs.com id 84/CD-20767-AC7FA605; Tue, 02 Oct 2012 14:18:50 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-12.tower-182.messagelabs.com!1349187527!32896143!1 X-Originating-IP: [128.244.251.36] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16601 invoked from network); 2 Oct 2012 14:18:49 -0000 Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36) by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 14:18:49 -0000 Received: from ([128.244.207.89]) by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.154108432; Tue, 02 Oct 2012 10:18:29 -0400 Message-ID: <506AF764.5040701@jhuapl.edu> Date: Tue, 02 Oct 2012 10:17:08 -0400 From: Matthew Fioravante User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Ian Campbell References: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu> <1348765802-11314-8-git-send-email-matthew.fioravante@jhuapl.edu> <1349175465.650.39.camel@zakaz.uk.xensource.com> In-Reply-To: <1349175465.650.39.camel@zakaz.uk.xensource.com> X-Enigmail-Version: 1.4.4 Cc: "samuel.thibault@ens-lyon.org" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 08/11] add tpmfront, tpm_tis, and tpmback drivers to mini-os X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0195709421912400937==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a cryptographically signed message in MIME format. --===============0195709421912400937== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040103090501090501060108" This is a cryptographically signed message in MIME format. --------------ms040103090501090501060108 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/02/2012 06:57 AM, Ian Campbell wrote: >> diff --git a/extras/mini-os/include/tpm_tis.h b/extras/mini-os/include= /tpm_tis.h >> new file mode 100644 >> index 0000000..b463cea >> --- /dev/null >> +++ b/extras/mini-os/include/tpm_tis.h >> @@ -0,0 +1,74 @@ >> +/* >> + * Copyright (c) 2010-2012 United States Government, as represented b= y >> + * the Secretary of Defense. All rights reserved. >> + * >> + * This program is free software; you can redistribute it and/or >> + * modify it under the terms of the GNU General Public License versio= n 2 >> + * as published by the Free Software Foundation; or, when distributed= >> + * separately from the Linux kernel or incorporated into other >> + * software packages, subject to the following license: >> + * >> + * Permission is hereby granted, free of charge, to any person obtain= ing a copy >> + * of this source file (the "Software"), to deal in the Software with= out >> + * restriction, including without limitation the rights to use, copy,= modify, >> + * merge, publish, distribute, sublicense, and/or sell copies of the = Software, >> + * and to permit persons to whom the Software is furnished to do so, = subject to >> + * the following conditions: >> + * >> + * The above copyright notice and this permission notice shall be inc= luded in >> + * all copies or substantial portions of the Software. >> + * >> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EX= PRESS OR >> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTAB= ILITY, >> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT = SHALL THE >> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR O= THER >> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, AR= ISING >> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHE= R DEALINGS >> + * IN THE SOFTWARE. >> + * >> + * Based upon the files: >> + * drivers/char/tpm/tpm_tis.c >> + * drivers/char/tpm/tpm.c >> + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporatio= n > Given that then I don't think you have the authority to dual license > code owned by IBM as GPL or the MIT style thing above -- these files ar= e > subject to the licensing terms of those original files (which looks to > be GPL v2 only). > > It might be acceptable to have a GPL header as the primary followed by = a > "modifications by Matthew Fioravante/US Gov/Secretary Defense are also > licensed under... .MIT thing ...." but I'd want to see a second opinion= > on that I think. > > I didn't check all the other licensing thoroughly but I expect similar > comments will apply elsewhere too. As far as I understand (I'm in no way a copyright lawyer), there is a difference between copyright and license. What this is trying to convey is that the changes are copyrighted by the US Govt and the license being offered is GPLv2. > Ian. > > --------------ms040103090501090501060108 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4 NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50 ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz 4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTEyMTAwMjE0MTcwOFowIwYJKoZIhvcNAQkEMRYEFFWL1fSM6Yp+m19N vWdptFQL1coLMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBqDB+1lABAispxuiS32bbnuQMOCxtKT85z LxAayx9Q1H56j6lIyMpIJfghpPQLhvypCCyQS3CAUkRiv66aN1tILy/Nklkdkh2VJzY2OYMj pi7UyJ6uz6NpJom/1pAiwEoIg1es9IkQ0JSBQR6rjV4+KY6QI7E6eEtBzjxz3tlAZgAAAAAA AA== --------------ms040103090501090501060108-- --===============0195709421912400937== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============0195709421912400937==-- From xen-devel-bounces@lists.xen.org Tue Oct 02 14:20:27 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:20:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3Ka-0005xT-Fz; Tue, 02 Oct 2012 14:20:16 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3KY-0005xH-8i for Xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:20:14 +0000 Received: from [85.158.139.211:45806] by server-10.bemta-5.messagelabs.com id AA/E3-16911-D18FA605; Tue, 02 Oct 2012 14:20:13 +0000 X-Env-Sender: ketuzsezr@gmail.com X-Msg-Ref: server-10.tower-206.messagelabs.com!1349187609!20754674!1 X-Originating-IP: [209.85.160.45] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22511 invoked from network); 2 Oct 2012 14:20:11 -0000 Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com) (209.85.160.45) by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 14:20:11 -0000 Received: by pbbrp2 with SMTP id rp2so9098953pbb.32 for ; Tue, 02 Oct 2012 07:20:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ooC1rOYCL3G4n/5U/gHUeG8Xagxl762Ra/ulAVlTlKA=; b=wEo2IGN5K7vxbROjrEhxwuUJJqrDJsTxrExVGJTFz/8TUguoUYdw1pXJ5UQjWBxkz+ 4gX5rSPwF609G9o5AqWH6AcJwpwDRWa8SufqiFe2n7C+f+HGxodfu0JfMjTyMyw8iiAk nRZ3qD64Z5RGg5/m5tN/k6qFzJ1LY2z+NVWadd/1ZohKNxR4y7Wz5N5pT2v3Ipq0U9fh /ECpbUVFAXV/v0eIdl9zxEO716w3NggsfrCA97uDFmxvHbn/2wZFus+1k9gedNOLZRHM rfoeEh68hr7EJwc3Q0W9BCfv4bYDI7N2O+9EtRgd5Fpm2c5TgAP9yEfP7H/2vw2aYepq TpkA== MIME-Version: 1.0 Received: by 10.66.82.3 with SMTP id e3mr44547276pay.56.1349187609015; Tue, 02 Oct 2012 07:20:09 -0700 (PDT) Received: by 10.66.193.9 with HTTP; Tue, 2 Oct 2012 07:20:08 -0700 (PDT) In-Reply-To: References: <20121001144042.GC8912@reaktio.net> <20121001160117.GD8912@reaktio.net> <20121001164757.GF8912@reaktio.net> <20121001182437.GG8912@reaktio.net> <20121002121932.GL8912@reaktio.net> Date: Tue, 2 Oct 2012 10:20:08 -0400 X-Google-Sender-Auth: 0b4BKIF5y3Hkw8NGILI6yRztwCk Message-ID: From: Konrad Rzeszutek Wilk To: Valtteri Kiviniemi Cc: Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.0.4, kernel 3.5.0 HVM crash and kernel BUG X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, Oct 2, 2012 at 9:01 AM, Valtteri Kiviniemi wrote: > Hi, > > I already tried 3.2, 3.5, 3.5.0, 3.6.0-rc7 and 3.6.0, same problem all of > those. My dom0 config is the same config that I'am using on other server > where HVM is working, so I dont think that it is a config problem. I have > triple checked everything and all should be ok. dom0 dmesg shows the same > crash that I have previously posted here. /var/log/xen/ does not contain any > specific errors. > > Could this be some kind of broblem with my motherboard bios being buggy or > CPU not supported? I'm using the new intel Ivy Bridge processor which has > integrated GPU, but that should not probably cause these kind of problems. > Or maybe some ACPI problem? xm dmesg is showing some notices about ACPI. Is > there any ACPI kernel parameters that I should try booting? This has to be > somekind of problem with my hardware, or then maybe it could be a kernel > problem too. I just really cant figure this out myself, I have tried > everything. > > Lets take a quick summary of what has been tested, what hardware I'm using > etc. > > Xen-versions tested: 4.2.0, 4.0.4 > Kernel-versions tested: 3.2.0, 3.5.0, 3.5.4, 3.6.0-rc7, 3.6.0 > > Host OS: Debian testing/wheezy, udev version 175-7, 2.13-35, python version > 2.7.3~rc2-2.1 > > Hardware: > > CPU: Intel Core i7-3770 3.4GHz > MB: Intel DQ77MK (latest bios updated) > Memory: 32GB (4 x 8GB DDR3-1600MHz) > > All relevant log files and configs: > > dom0 dmesg: http://nago.fi/dmesg.txt > qemu-dm log: http://nago.fi/qemu-dm.txt > xm dmesg log: http://nago.fi/xm-dmesg.txt > domU config: http://nago.fi/domu-config.txt > dom0 kernel config: http://nago.fi/dom0-config.txt > > I have also tried playing with every setting on that domU that I can think > of and tried different configs etc. This is troubling. You seem to trigger the QEMU closing the tunX (your Windows's guest network interface) which then crashes somehow. Just to make sure that this is the case - can you try launching your guest without network and seeing what happens? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 14:20:27 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:20:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3Ka-0005xT-Fz; Tue, 02 Oct 2012 14:20:16 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3KY-0005xH-8i for Xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:20:14 +0000 Received: from [85.158.139.211:45806] by server-10.bemta-5.messagelabs.com id AA/E3-16911-D18FA605; Tue, 02 Oct 2012 14:20:13 +0000 X-Env-Sender: ketuzsezr@gmail.com X-Msg-Ref: server-10.tower-206.messagelabs.com!1349187609!20754674!1 X-Originating-IP: [209.85.160.45] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22511 invoked from network); 2 Oct 2012 14:20:11 -0000 Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com) (209.85.160.45) by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 14:20:11 -0000 Received: by pbbrp2 with SMTP id rp2so9098953pbb.32 for ; Tue, 02 Oct 2012 07:20:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ooC1rOYCL3G4n/5U/gHUeG8Xagxl762Ra/ulAVlTlKA=; b=wEo2IGN5K7vxbROjrEhxwuUJJqrDJsTxrExVGJTFz/8TUguoUYdw1pXJ5UQjWBxkz+ 4gX5rSPwF609G9o5AqWH6AcJwpwDRWa8SufqiFe2n7C+f+HGxodfu0JfMjTyMyw8iiAk nRZ3qD64Z5RGg5/m5tN/k6qFzJ1LY2z+NVWadd/1ZohKNxR4y7Wz5N5pT2v3Ipq0U9fh /ECpbUVFAXV/v0eIdl9zxEO716w3NggsfrCA97uDFmxvHbn/2wZFus+1k9gedNOLZRHM rfoeEh68hr7EJwc3Q0W9BCfv4bYDI7N2O+9EtRgd5Fpm2c5TgAP9yEfP7H/2vw2aYepq TpkA== MIME-Version: 1.0 Received: by 10.66.82.3 with SMTP id e3mr44547276pay.56.1349187609015; Tue, 02 Oct 2012 07:20:09 -0700 (PDT) Received: by 10.66.193.9 with HTTP; Tue, 2 Oct 2012 07:20:08 -0700 (PDT) In-Reply-To: References: <20121001144042.GC8912@reaktio.net> <20121001160117.GD8912@reaktio.net> <20121001164757.GF8912@reaktio.net> <20121001182437.GG8912@reaktio.net> <20121002121932.GL8912@reaktio.net> Date: Tue, 2 Oct 2012 10:20:08 -0400 X-Google-Sender-Auth: 0b4BKIF5y3Hkw8NGILI6yRztwCk Message-ID: From: Konrad Rzeszutek Wilk To: Valtteri Kiviniemi Cc: Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.0.4, kernel 3.5.0 HVM crash and kernel BUG X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, Oct 2, 2012 at 9:01 AM, Valtteri Kiviniemi wrote: > Hi, > > I already tried 3.2, 3.5, 3.5.0, 3.6.0-rc7 and 3.6.0, same problem all of > those. My dom0 config is the same config that I'am using on other server > where HVM is working, so I dont think that it is a config problem. I have > triple checked everything and all should be ok. dom0 dmesg shows the same > crash that I have previously posted here. /var/log/xen/ does not contain any > specific errors. > > Could this be some kind of broblem with my motherboard bios being buggy or > CPU not supported? I'm using the new intel Ivy Bridge processor which has > integrated GPU, but that should not probably cause these kind of problems. > Or maybe some ACPI problem? xm dmesg is showing some notices about ACPI. Is > there any ACPI kernel parameters that I should try booting? This has to be > somekind of problem with my hardware, or then maybe it could be a kernel > problem too. I just really cant figure this out myself, I have tried > everything. > > Lets take a quick summary of what has been tested, what hardware I'm using > etc. > > Xen-versions tested: 4.2.0, 4.0.4 > Kernel-versions tested: 3.2.0, 3.5.0, 3.5.4, 3.6.0-rc7, 3.6.0 > > Host OS: Debian testing/wheezy, udev version 175-7, 2.13-35, python version > 2.7.3~rc2-2.1 > > Hardware: > > CPU: Intel Core i7-3770 3.4GHz > MB: Intel DQ77MK (latest bios updated) > Memory: 32GB (4 x 8GB DDR3-1600MHz) > > All relevant log files and configs: > > dom0 dmesg: http://nago.fi/dmesg.txt > qemu-dm log: http://nago.fi/qemu-dm.txt > xm dmesg log: http://nago.fi/xm-dmesg.txt > domU config: http://nago.fi/domu-config.txt > dom0 kernel config: http://nago.fi/dom0-config.txt > > I have also tried playing with every setting on that domU that I can think > of and tried different configs etc. This is troubling. You seem to trigger the QEMU closing the tunX (your Windows's guest network interface) which then crashes somehow. Just to make sure that this is the case - can you try launching your guest without network and seeing what happens? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 14:22:07 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:22:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3ME-00066r-10; Tue, 02 Oct 2012 14:21:58 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3MC-00066d-EO for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:21:56 +0000 Received: from [85.158.138.51:65190] by server-3.bemta-3.messagelabs.com id F6/BD-25962-388FA605; Tue, 02 Oct 2012 14:21:55 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-4.tower-174.messagelabs.com!1349187712!32308638!1 X-Originating-IP: [128.244.251.36] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30279 invoked from network); 2 Oct 2012 14:21:54 -0000 Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36) by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 14:21:54 -0000 Received: from ([128.244.207.89]) by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.154108769; Tue, 02 Oct 2012 10:21:35 -0400 Message-ID: <506AF81E.4090506@jhuapl.edu> Date: Tue, 02 Oct 2012 10:20:14 -0400 From: Matthew Fioravante User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Ian Campbell References: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu> <1348765802-11314-4-git-send-email-matthew.fioravante@jhuapl.edu> <1349174997.650.34.camel@zakaz.uk.xensource.com> In-Reply-To: <1349174997.650.34.camel@zakaz.uk.xensource.com> X-Enigmail-Version: 1.4.4 Cc: "samuel.thibault@ens-lyon.org" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 04/11] Disable the mfn_is_ram() check, it doesn't work correctly on all systems X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0580388976824812647==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a cryptographically signed message in MIME format. --===============0580388976824812647== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020207010900020403080801" This is a cryptographically signed message in MIME format. --------------ms020207010900020403080801 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/02/2012 06:49 AM, Ian Campbell wrote: > On Thu, 2012-09-27 at 18:09 +0100, Matthew Fioravante wrote: >> This patch disables the mfn_is_ram check in mini-os. The current check= >> is insufficient and fails on some systems with larger than 4gb memory.= >> >> Signed-off-by: Matthew Fioravante >> Acked-by: Samuel Thibault > Further down the thread with the Ack Samuel said: > We can probably just remove the check in __do_ioremap, which > AFAIK is the only call. > > since this function is a bit pointless now. I think its a question of whether or not we want to leave it for someone to implement correctly later (by getting the memory map from the hypervisor/ doing e820 calls) or get rid of it entirely. Since its only purpose seems to be for preventing mini-os devs from making logical errors I'd be more inclined to just get rid of it. Do you all agree? If so I can send a new patch with it taken out. > >> diff --git a/extras/mini-os/arch/x86/mm.c b/extras/mini-os/arch/x86/mm= =2Ec >> index 80aceac..5813a08 100644 >> --- a/extras/mini-os/arch/x86/mm.c >> +++ b/extras/mini-os/arch/x86/mm.c >> @@ -850,6 +850,8 @@ unsigned long alloc_contig_pages(int order, unsign= ed int addr_bits) >> static long system_ram_end_mfn; >> int mfn_is_ram(unsigned long mfn) >> { >> + /* This is broken on systems with large ammounts of ram. Always re= turn 0 for now */ >> + return 0; >> /* very crude check if a given MFN is memory or not. Probably sho= uld >> * make this a little more sophisticated ;) */ >> return (mfn <=3D system_ram_end_mfn) ? 1 : 0; > --------------ms020207010900020403080801 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4 NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50 ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz 4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTEyMTAwMjE0MjAxNFowIwYJKoZIhvcNAQkEMRYEFO/c6PqCCNtYE489 gGbv7tvDKm/VMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBaDBBJ8wxFly/txkc075+NL4NujlUHSndb ZLpvuINua4Kf3n/rtfuyZ7A+bV2nQcww42nx3zOvhJeZM0GrY+U8ZuBY1EvLqbsdtVl4wofH i0NySyCNkM4dSpI5IGZRrTOpc+esIIlXOpX9hOIlMFo2VvvQlQcrIT7IRxOmHaY+AQAAAAAA AA== --------------ms020207010900020403080801-- --===============0580388976824812647== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============0580388976824812647==-- From xen-devel-bounces@lists.xen.org Tue Oct 02 14:22:07 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:22:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3ME-00066r-10; Tue, 02 Oct 2012 14:21:58 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3MC-00066d-EO for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:21:56 +0000 Received: from [85.158.138.51:65190] by server-3.bemta-3.messagelabs.com id F6/BD-25962-388FA605; Tue, 02 Oct 2012 14:21:55 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-4.tower-174.messagelabs.com!1349187712!32308638!1 X-Originating-IP: [128.244.251.36] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30279 invoked from network); 2 Oct 2012 14:21:54 -0000 Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36) by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 14:21:54 -0000 Received: from ([128.244.207.89]) by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.154108769; Tue, 02 Oct 2012 10:21:35 -0400 Message-ID: <506AF81E.4090506@jhuapl.edu> Date: Tue, 02 Oct 2012 10:20:14 -0400 From: Matthew Fioravante User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Ian Campbell References: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu> <1348765802-11314-4-git-send-email-matthew.fioravante@jhuapl.edu> <1349174997.650.34.camel@zakaz.uk.xensource.com> In-Reply-To: <1349174997.650.34.camel@zakaz.uk.xensource.com> X-Enigmail-Version: 1.4.4 Cc: "samuel.thibault@ens-lyon.org" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 04/11] Disable the mfn_is_ram() check, it doesn't work correctly on all systems X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0580388976824812647==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a cryptographically signed message in MIME format. --===============0580388976824812647== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020207010900020403080801" This is a cryptographically signed message in MIME format. --------------ms020207010900020403080801 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/02/2012 06:49 AM, Ian Campbell wrote: > On Thu, 2012-09-27 at 18:09 +0100, Matthew Fioravante wrote: >> This patch disables the mfn_is_ram check in mini-os. The current check= >> is insufficient and fails on some systems with larger than 4gb memory.= >> >> Signed-off-by: Matthew Fioravante >> Acked-by: Samuel Thibault > Further down the thread with the Ack Samuel said: > We can probably just remove the check in __do_ioremap, which > AFAIK is the only call. > > since this function is a bit pointless now. I think its a question of whether or not we want to leave it for someone to implement correctly later (by getting the memory map from the hypervisor/ doing e820 calls) or get rid of it entirely. Since its only purpose seems to be for preventing mini-os devs from making logical errors I'd be more inclined to just get rid of it. Do you all agree? If so I can send a new patch with it taken out. > >> diff --git a/extras/mini-os/arch/x86/mm.c b/extras/mini-os/arch/x86/mm= =2Ec >> index 80aceac..5813a08 100644 >> --- a/extras/mini-os/arch/x86/mm.c >> +++ b/extras/mini-os/arch/x86/mm.c >> @@ -850,6 +850,8 @@ unsigned long alloc_contig_pages(int order, unsign= ed int addr_bits) >> static long system_ram_end_mfn; >> int mfn_is_ram(unsigned long mfn) >> { >> + /* This is broken on systems with large ammounts of ram. Always re= turn 0 for now */ >> + return 0; >> /* very crude check if a given MFN is memory or not. Probably sho= uld >> * make this a little more sophisticated ;) */ >> return (mfn <=3D system_ram_end_mfn) ? 1 : 0; > --------------ms020207010900020403080801 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4 NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50 ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz 4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTEyMTAwMjE0MjAxNFowIwYJKoZIhvcNAQkEMRYEFO/c6PqCCNtYE489 gGbv7tvDKm/VMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBaDBBJ8wxFly/txkc075+NL4NujlUHSndb ZLpvuINua4Kf3n/rtfuyZ7A+bV2nQcww42nx3zOvhJeZM0GrY+U8ZuBY1EvLqbsdtVl4wofH i0NySyCNkM4dSpI5IGZRrTOpc+esIIlXOpX9hOIlMFo2VvvQlQcrIT7IRxOmHaY+AQAAAAAA AA== --------------ms020207010900020403080801-- --===============0580388976824812647== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============0580388976824812647==-- From xen-devel-bounces@lists.xen.org Tue Oct 02 14:25:31 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:25:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3PR-0006KB-L4; Tue, 02 Oct 2012 14:25:17 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3PQ-0006K4-AE for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:25:16 +0000 Received: from [85.158.139.211:60228] by server-14.bemta-5.messagelabs.com id 89/3E-05772-B49FA605; Tue, 02 Oct 2012 14:25:15 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-13.tower-206.messagelabs.com!1349187912!16805061!1 X-Originating-IP: [128.244.251.36] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22150 invoked from network); 2 Oct 2012 14:25:13 -0000 Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36) by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 14:25:13 -0000 Received: from ([128.244.207.89]) by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.154109210; Tue, 02 Oct 2012 10:24:54 -0400 Message-ID: <506AF8E4.9010400@jhuapl.edu> Date: Tue, 02 Oct 2012 10:23:32 -0400 From: Matthew Fioravante User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Ian Campbell References: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu> <5065ACB7.3040902@jhuapl.edu> <1349169015.650.11.camel@zakaz.uk.xensource.com> In-Reply-To: <1349169015.650.11.camel@zakaz.uk.xensource.com> X-Enigmail-Version: 1.4.4 Cc: George Dunlap , "samuel.thibault@ens-lyon.org" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 01/11] Add ioread/iowrite functions to mini-os X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5404326762314496729==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a cryptographically signed message in MIME format. --===============5404326762314496729== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090707040505050907090800" This is a cryptographically signed message in MIME format. --------------ms090707040505050907090800 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/02/2012 05:10 AM, Ian Campbell wrote: > On Fri, 2012-09-28 at 14:57 +0100, Matthew Fioravante wrote: >> On 09/28/2012 06:16 AM, George Dunlap wrote: >>> On Thu, Sep 27, 2012 at 6:09 PM, Matthew Fioravante >>> wrote: >>>> This patch adds iowritexx() and ioreadxx() functions for interacting= >>>> with hardware memory to mini-os. The functions are available in a he= ader >>>> iorw.h >>>> >>>> Signed-off-by: Matthew Fioravante >>>> Acked-by: Samuel Thibault >>>> >>>> diff --git a/extras/mini-os/arch/ia64/iorw.c b/extras/mini-os/arch/i= a64/iorw.c >>> Is there any reason to have the ia64 stuff? ia64 isn't supported in >>> Xen anymore, AFAIK. >> Maybe not. But until ia64 support is removed from mini-os the function= >> bodies should exist so stuff will compile. > I thought I had dropped all the remnants of ia64 in mini-os in commit > 25882:485e6db28b93 "tools: drop ia64 support". Let me know if you think= > I've missed something, but: > >>>> new file mode 100644 >>>> index 0000000..aa58807 >>>> --- /dev/null >>>> +++ b/extras/mini-os/arch/ia64/iorw.c > $ ls extras/mini-os/arch/ia64/iorw.c > ls: cannot access extras/mini-os/arch/ia64/iorw.c: No such file or dire= ctory > > I think perhaps you just need to rebase? Sorry about that, I missed that entirely. These patches were written a long time ago when ia64 was still in and since iorw.c never existed in the first place the patch just happily added it. Anyway, its been removed= =2E > Ian. > --------------ms090707040505050907090800 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4 NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50 ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz 4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTEyMTAwMjE0MjMzMlowIwYJKoZIhvcNAQkEMRYEFPrE68iwkrIWEduw 9Vs4jKhc0yCOMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBdGJRsSzR0yfQ+f5703j0GckCblLAyH0EU ZDlTCxCc5uoayWlFNKoQkhoqukdDi39uEwaxqPrhzOgf6FibDrF/Acin2CKg6mgbkdSOK3QD MeQvZSSzyNCCA9msSavUUOyZcr1hRKTk1Lrmg4aTr+LBrhfbYXgmDWbBQ+k9yr2LXQAAAAAA AA== --------------ms090707040505050907090800-- --===============5404326762314496729== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============5404326762314496729==-- From xen-devel-bounces@lists.xen.org Tue Oct 02 14:25:31 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:25:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3PR-0006KB-L4; Tue, 02 Oct 2012 14:25:17 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3PQ-0006K4-AE for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:25:16 +0000 Received: from [85.158.139.211:60228] by server-14.bemta-5.messagelabs.com id 89/3E-05772-B49FA605; Tue, 02 Oct 2012 14:25:15 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-13.tower-206.messagelabs.com!1349187912!16805061!1 X-Originating-IP: [128.244.251.36] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22150 invoked from network); 2 Oct 2012 14:25:13 -0000 Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36) by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 14:25:13 -0000 Received: from ([128.244.207.89]) by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.154109210; Tue, 02 Oct 2012 10:24:54 -0400 Message-ID: <506AF8E4.9010400@jhuapl.edu> Date: Tue, 02 Oct 2012 10:23:32 -0400 From: Matthew Fioravante User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Ian Campbell References: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu> <5065ACB7.3040902@jhuapl.edu> <1349169015.650.11.camel@zakaz.uk.xensource.com> In-Reply-To: <1349169015.650.11.camel@zakaz.uk.xensource.com> X-Enigmail-Version: 1.4.4 Cc: George Dunlap , "samuel.thibault@ens-lyon.org" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 01/11] Add ioread/iowrite functions to mini-os X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5404326762314496729==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a cryptographically signed message in MIME format. --===============5404326762314496729== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090707040505050907090800" This is a cryptographically signed message in MIME format. --------------ms090707040505050907090800 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/02/2012 05:10 AM, Ian Campbell wrote: > On Fri, 2012-09-28 at 14:57 +0100, Matthew Fioravante wrote: >> On 09/28/2012 06:16 AM, George Dunlap wrote: >>> On Thu, Sep 27, 2012 at 6:09 PM, Matthew Fioravante >>> wrote: >>>> This patch adds iowritexx() and ioreadxx() functions for interacting= >>>> with hardware memory to mini-os. The functions are available in a he= ader >>>> iorw.h >>>> >>>> Signed-off-by: Matthew Fioravante >>>> Acked-by: Samuel Thibault >>>> >>>> diff --git a/extras/mini-os/arch/ia64/iorw.c b/extras/mini-os/arch/i= a64/iorw.c >>> Is there any reason to have the ia64 stuff? ia64 isn't supported in >>> Xen anymore, AFAIK. >> Maybe not. But until ia64 support is removed from mini-os the function= >> bodies should exist so stuff will compile. > I thought I had dropped all the remnants of ia64 in mini-os in commit > 25882:485e6db28b93 "tools: drop ia64 support". Let me know if you think= > I've missed something, but: > >>>> new file mode 100644 >>>> index 0000000..aa58807 >>>> --- /dev/null >>>> +++ b/extras/mini-os/arch/ia64/iorw.c > $ ls extras/mini-os/arch/ia64/iorw.c > ls: cannot access extras/mini-os/arch/ia64/iorw.c: No such file or dire= ctory > > I think perhaps you just need to rebase? Sorry about that, I missed that entirely. These patches were written a long time ago when ia64 was still in and since iorw.c never existed in the first place the patch just happily added it. Anyway, its been removed= =2E > Ian. > --------------ms090707040505050907090800 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4 NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50 ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz 4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTEyMTAwMjE0MjMzMlowIwYJKoZIhvcNAQkEMRYEFPrE68iwkrIWEduw 9Vs4jKhc0yCOMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBdGJRsSzR0yfQ+f5703j0GckCblLAyH0EU ZDlTCxCc5uoayWlFNKoQkhoqukdDi39uEwaxqPrhzOgf6FibDrF/Acin2CKg6mgbkdSOK3QD MeQvZSSzyNCCA9msSavUUOyZcr1hRKTk1Lrmg4aTr+LBrhfbYXgmDWbBQ+k9yr2LXQAAAAAA AA== --------------ms090707040505050907090800-- --===============5404326762314496729== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============5404326762314496729==-- From xen-devel-bounces@lists.xen.org Tue Oct 02 14:28:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:28:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3S1-0006Rf-7K; Tue, 02 Oct 2012 14:27:57 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3Rz-0006RU-2h for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:27:55 +0000 Received: from [85.158.138.51:8322] by server-7.bemta-3.messagelabs.com id 9C/1E-15765-AE9FA605; Tue, 02 Oct 2012 14:27:54 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-12.tower-174.messagelabs.com!1349188072!24884108!1 X-Originating-IP: [128.244.251.36] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8757 invoked from network); 2 Oct 2012 14:27:53 -0000 Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36) by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 14:27:53 -0000 Received: from ([128.244.207.97]) by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.154109554; Tue, 02 Oct 2012 10:27:34 -0400 From: Matthew Fioravante To: xen-devel@lists.xen.org, Ian.Campbell@citrix.com, samuel.thibault@ens-lyon.org Date: Tue, 2 Oct 2012 10:27:32 -0400 Message-Id: <1349188052-15639-1-git-send-email-matthew.fioravante@jhuapl.edu> X-Mailer: git-send-email 1.7.4.4 Cc: Matthew Fioravante Subject: [Xen-devel] [PATCH 01/12] Add ioread/iowrite functions to mini-os X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch adds iowritexx() and ioreadxx() functions for interacting with hardware memory to mini-os. The functions are available in a header iorw.h Signed-off-by: Matthew Fioravante Acked-by: Samuel Thibault --- Changes since last * remove ia64 support diff --git a/extras/mini-os/arch/x86/iorw.c b/extras/mini-os/arch/x86/iorw.c new file mode 100644 index 0000000..3080769 --- /dev/null +++ b/extras/mini-os/arch/x86/iorw.c @@ -0,0 +1,35 @@ +#include + +void iowrite8(volatile void* addr, uint8_t val) +{ + *((volatile uint8_t*)addr) = val; +} +void iowrite16(volatile void* addr, uint16_t val) +{ + *((volatile uint16_t*)addr) = val; +} +void iowrite32(volatile void* addr, uint32_t val) +{ + *((volatile uint32_t*)addr) = val; +} +void iowrite64(volatile void* addr, uint64_t val) +{ + *((volatile uint64_t*)addr) = val; +} + +uint8_t ioread8(volatile void* addr) +{ + return *((volatile uint8_t*) addr); +} +uint16_t ioread16(volatile void* addr) +{ + return *((volatile uint16_t*) addr); +} +uint32_t ioread32(volatile void* addr) +{ + return *((volatile uint32_t*) addr); +} +uint64_t ioread64(volatile void* addr) +{ + return *((volatile uint64_t*) addr); +} diff --git a/extras/mini-os/include/iorw.h b/extras/mini-os/include/iorw.h new file mode 100644 index 0000000..d5ec065 --- /dev/null +++ b/extras/mini-os/include/iorw.h @@ -0,0 +1,16 @@ +#ifndef MINIOS_IORW_H +#define MINIOS_IORW_H + +#include + +void iowrite8(volatile void* addr, uint8_t val); +void iowrite16(volatile void* addr, uint16_t val); +void iowrite32(volatile void* addr, uint32_t val); +void iowrite64(volatile void* addr, uint64_t val); + +uint8_t ioread8(volatile void* addr); +uint16_t ioread16(volatile void* addr); +uint32_t ioread32(volatile void* addr); +uint64_t ioread64(volatile void* addr); + +#endif -- 1.7.4.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 14:28:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:28:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3S1-0006Rf-7K; Tue, 02 Oct 2012 14:27:57 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3Rz-0006RU-2h for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:27:55 +0000 Received: from [85.158.138.51:8322] by server-7.bemta-3.messagelabs.com id 9C/1E-15765-AE9FA605; Tue, 02 Oct 2012 14:27:54 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-12.tower-174.messagelabs.com!1349188072!24884108!1 X-Originating-IP: [128.244.251.36] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8757 invoked from network); 2 Oct 2012 14:27:53 -0000 Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36) by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 14:27:53 -0000 Received: from ([128.244.207.97]) by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.154109554; Tue, 02 Oct 2012 10:27:34 -0400 From: Matthew Fioravante To: xen-devel@lists.xen.org, Ian.Campbell@citrix.com, samuel.thibault@ens-lyon.org Date: Tue, 2 Oct 2012 10:27:32 -0400 Message-Id: <1349188052-15639-1-git-send-email-matthew.fioravante@jhuapl.edu> X-Mailer: git-send-email 1.7.4.4 Cc: Matthew Fioravante Subject: [Xen-devel] [PATCH 01/12] Add ioread/iowrite functions to mini-os X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch adds iowritexx() and ioreadxx() functions for interacting with hardware memory to mini-os. The functions are available in a header iorw.h Signed-off-by: Matthew Fioravante Acked-by: Samuel Thibault --- Changes since last * remove ia64 support diff --git a/extras/mini-os/arch/x86/iorw.c b/extras/mini-os/arch/x86/iorw.c new file mode 100644 index 0000000..3080769 --- /dev/null +++ b/extras/mini-os/arch/x86/iorw.c @@ -0,0 +1,35 @@ +#include + +void iowrite8(volatile void* addr, uint8_t val) +{ + *((volatile uint8_t*)addr) = val; +} +void iowrite16(volatile void* addr, uint16_t val) +{ + *((volatile uint16_t*)addr) = val; +} +void iowrite32(volatile void* addr, uint32_t val) +{ + *((volatile uint32_t*)addr) = val; +} +void iowrite64(volatile void* addr, uint64_t val) +{ + *((volatile uint64_t*)addr) = val; +} + +uint8_t ioread8(volatile void* addr) +{ + return *((volatile uint8_t*) addr); +} +uint16_t ioread16(volatile void* addr) +{ + return *((volatile uint16_t*) addr); +} +uint32_t ioread32(volatile void* addr) +{ + return *((volatile uint32_t*) addr); +} +uint64_t ioread64(volatile void* addr) +{ + return *((volatile uint64_t*) addr); +} diff --git a/extras/mini-os/include/iorw.h b/extras/mini-os/include/iorw.h new file mode 100644 index 0000000..d5ec065 --- /dev/null +++ b/extras/mini-os/include/iorw.h @@ -0,0 +1,16 @@ +#ifndef MINIOS_IORW_H +#define MINIOS_IORW_H + +#include + +void iowrite8(volatile void* addr, uint8_t val); +void iowrite16(volatile void* addr, uint16_t val); +void iowrite32(volatile void* addr, uint32_t val); +void iowrite64(volatile void* addr, uint64_t val); + +uint8_t ioread8(volatile void* addr); +uint16_t ioread16(volatile void* addr); +uint32_t ioread32(volatile void* addr); +uint64_t ioread64(volatile void* addr); + +#endif -- 1.7.4.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 14:28:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:28:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3SR-0006Vk-QL; Tue, 02 Oct 2012 14:28:23 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3SQ-0006V1-Qc for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:28:23 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1349187972!8476577!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28373 invoked from network); 2 Oct 2012 14:26:12 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 14:26:12 -0000 X-IronPort-AV: E=Sophos;i="4.80,523,1344211200"; d="scan'208";a="14895831" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 14:26:12 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 15:26:12 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TJ3QJ-0001VX-PS; Tue, 02 Oct 2012 14:26:11 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TJ3QJ-0005yR-LX; Tue, 02 Oct 2012 15:26:11 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20586.63875.490107.170343@mariner.uk.xensource.com> Date: Tue, 2 Oct 2012 15:26:11 +0100 To: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= Newsgroups: chiark.mail.xen.devel In-Reply-To: <20121001164239.GE8912@reaktio.net> References: <20121001164239.GE8912@reaktio.net> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: George Dunlap , xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.3 development update X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Pasi K=E4rkk=E4inen writes ("Re: [Xen-devel] Xen 4.3 development update"): > * xl PVUSB pass-through for both PV and HVM guests > owner: ? = > status: ? = > - xm/xend supports PVUSB pass-through to guests with PVUSB drivers (bo= th PV and HVM guests). > - port the xm/xend functionality to xl. > - this PVUSB feature does not require support or emulation from Qemu. > - upstream the Linux frontend/backend drivers. Current work-in-progres= s versions are in Konrad's git tree. > - James Harper's GPLPV drivers for Windows include PVUSB frontend driv= ers. Right. I think upstreaming the frontend/backend is critical for this. Is this related to the usb-over-ip support that I found a few years ago in linux-staging ? At the time that was very buggy. > * xl USB pass-through for HVM guests using Qemu USB emulation > owner: ? = > status: ? > - xm/xend with qemu-traditional supports USB passthrough to HVM guests= using the Qemu emulated USB controller. > - port the xm/xend functionality to xl. > - make sure USB passthrough with xl works with both qemu-traditional a= nd qemu-upstream. > - The HVM guest does not need any special drivers for this feature. I think this is just a matter of plumbing in libxl (presumably, now, plumbing to qemu-upstream). Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 14:28:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:28:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3SR-0006Vk-QL; Tue, 02 Oct 2012 14:28:23 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3SQ-0006V1-Qc for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:28:23 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1349187972!8476577!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28373 invoked from network); 2 Oct 2012 14:26:12 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 14:26:12 -0000 X-IronPort-AV: E=Sophos;i="4.80,523,1344211200"; d="scan'208";a="14895831" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 14:26:12 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 15:26:12 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TJ3QJ-0001VX-PS; Tue, 02 Oct 2012 14:26:11 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TJ3QJ-0005yR-LX; Tue, 02 Oct 2012 15:26:11 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20586.63875.490107.170343@mariner.uk.xensource.com> Date: Tue, 2 Oct 2012 15:26:11 +0100 To: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= Newsgroups: chiark.mail.xen.devel In-Reply-To: <20121001164239.GE8912@reaktio.net> References: <20121001164239.GE8912@reaktio.net> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: George Dunlap , xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.3 development update X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Pasi K=E4rkk=E4inen writes ("Re: [Xen-devel] Xen 4.3 development update"): > * xl PVUSB pass-through for both PV and HVM guests > owner: ? = > status: ? = > - xm/xend supports PVUSB pass-through to guests with PVUSB drivers (bo= th PV and HVM guests). > - port the xm/xend functionality to xl. > - this PVUSB feature does not require support or emulation from Qemu. > - upstream the Linux frontend/backend drivers. Current work-in-progres= s versions are in Konrad's git tree. > - James Harper's GPLPV drivers for Windows include PVUSB frontend driv= ers. Right. I think upstreaming the frontend/backend is critical for this. Is this related to the usb-over-ip support that I found a few years ago in linux-staging ? At the time that was very buggy. > * xl USB pass-through for HVM guests using Qemu USB emulation > owner: ? = > status: ? > - xm/xend with qemu-traditional supports USB passthrough to HVM guests= using the Qemu emulated USB controller. > - port the xm/xend functionality to xl. > - make sure USB passthrough with xl works with both qemu-traditional a= nd qemu-upstream. > - The HVM guest does not need any special drivers for this feature. I think this is just a matter of plumbing in libxl (presumably, now, plumbing to qemu-upstream). Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 14:32:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:32:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3Wa-0006mE-GW; Tue, 02 Oct 2012 14:32:40 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3WZ-0006m9-5X for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:32:39 +0000 Received: from [85.158.143.35:39280] by server-2.bemta-4.messagelabs.com id A9/95-06610-60BFA605; Tue, 02 Oct 2012 14:32:38 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-16.tower-21.messagelabs.com!1349188350!14525665!1 X-Originating-IP: [128.244.251.36] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1109 invoked from network); 2 Oct 2012 14:32:31 -0000 Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36) by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 14:32:31 -0000 Received: from ([128.244.207.89]) by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.154110198; Tue, 02 Oct 2012 10:32:25 -0400 Message-ID: <506AFAA8.9050900@jhuapl.edu> Date: Tue, 02 Oct 2012 10:31:04 -0400 From: Matthew Fioravante User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Ian Campbell References: <1348765860-11359-1-git-send-email-matthew.fioravante@jhuapl.edu> <1348765860-11359-3-git-send-email-matthew.fioravante@jhuapl.edu> <5065CAE9.30602@jhuapl.edu> <5065D333.6080600@jhuapl.edu> <5069E396.5040205@jhuapl.edu> <1349185449.650.55.camel@zakaz.uk.xensource.com> In-Reply-To: <1349185449.650.55.camel@zakaz.uk.xensource.com> X-Enigmail-Version: 1.4.4 Cc: George Dunlap , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 11/11] add vtpm support to libxl X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7663946303385334936==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a cryptographically signed message in MIME format. --===============7663946303385334936== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090206050801020900010800" This is a cryptographically signed message in MIME format. --------------ms090206050801020900010800 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/02/2012 09:44 AM, Ian Campbell wrote: > On Mon, 2012-10-01 at 19:40 +0100, Matthew Fioravante wrote: > >> Actually thinking about it more, uuids have to be attached to the >> driver. If 2 vtpms connect to the manager, one could send the uuid of >> the other and get access to someone elses secrets. >> >> TL;DR version >> >> uuids must remain part of the driver. > What stops the driver lying about the UUID in a similar way? The tpm backend driver (in the manager) will read the uuid from xenstore. So as long as we trust xenstore ( and the entities who created the entry, named libxl in dom0), we can trust the uuid and thus the identity of the vtpm connecting to us. > > Ian. > --------------ms090206050801020900010800 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4 NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50 ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz 4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTEyMTAwMjE0MzEwNFowIwYJKoZIhvcNAQkEMRYEFDr+WDu1iCUM+Sx3 jMtowI+xqWFhMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAaJQrGpgA4stopk9uXmeMYlu5hCngI+k0j CcWyKKM4YnkyW16ky1vCAGS42cES9z/KbW2bZqrTnnqd62HZwHzo49MIB0n8i8MSLN7872KS 1SRaGWyeY/g9iMbztFfw9d5gsfKdCZrFNbe7IUm02w4WrZMsFSkI3B0JswXYXZZ2YgAAAAAA AA== --------------ms090206050801020900010800-- --===============7663946303385334936== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============7663946303385334936==-- From xen-devel-bounces@lists.xen.org Tue Oct 02 14:32:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:32:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3Wa-0006mE-GW; Tue, 02 Oct 2012 14:32:40 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3WZ-0006m9-5X for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:32:39 +0000 Received: from [85.158.143.35:39280] by server-2.bemta-4.messagelabs.com id A9/95-06610-60BFA605; Tue, 02 Oct 2012 14:32:38 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-16.tower-21.messagelabs.com!1349188350!14525665!1 X-Originating-IP: [128.244.251.36] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1109 invoked from network); 2 Oct 2012 14:32:31 -0000 Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36) by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 14:32:31 -0000 Received: from ([128.244.207.89]) by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.154110198; Tue, 02 Oct 2012 10:32:25 -0400 Message-ID: <506AFAA8.9050900@jhuapl.edu> Date: Tue, 02 Oct 2012 10:31:04 -0400 From: Matthew Fioravante User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Ian Campbell References: <1348765860-11359-1-git-send-email-matthew.fioravante@jhuapl.edu> <1348765860-11359-3-git-send-email-matthew.fioravante@jhuapl.edu> <5065CAE9.30602@jhuapl.edu> <5065D333.6080600@jhuapl.edu> <5069E396.5040205@jhuapl.edu> <1349185449.650.55.camel@zakaz.uk.xensource.com> In-Reply-To: <1349185449.650.55.camel@zakaz.uk.xensource.com> X-Enigmail-Version: 1.4.4 Cc: George Dunlap , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 11/11] add vtpm support to libxl X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7663946303385334936==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a cryptographically signed message in MIME format. --===============7663946303385334936== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090206050801020900010800" This is a cryptographically signed message in MIME format. --------------ms090206050801020900010800 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/02/2012 09:44 AM, Ian Campbell wrote: > On Mon, 2012-10-01 at 19:40 +0100, Matthew Fioravante wrote: > >> Actually thinking about it more, uuids have to be attached to the >> driver. If 2 vtpms connect to the manager, one could send the uuid of >> the other and get access to someone elses secrets. >> >> TL;DR version >> >> uuids must remain part of the driver. > What stops the driver lying about the UUID in a similar way? The tpm backend driver (in the manager) will read the uuid from xenstore. So as long as we trust xenstore ( and the entities who created the entry, named libxl in dom0), we can trust the uuid and thus the identity of the vtpm connecting to us. > > Ian. > --------------ms090206050801020900010800 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4 NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50 ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz 4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTEyMTAwMjE0MzEwNFowIwYJKoZIhvcNAQkEMRYEFDr+WDu1iCUM+Sx3 jMtowI+xqWFhMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAaJQrGpgA4stopk9uXmeMYlu5hCngI+k0j CcWyKKM4YnkyW16ky1vCAGS42cES9z/KbW2bZqrTnnqd62HZwHzo49MIB0n8i8MSLN7872KS 1SRaGWyeY/g9iMbztFfw9d5gsfKdCZrFNbe7IUm02w4WrZMsFSkI3B0JswXYXZZ2YgAAAAAA AA== --------------ms090206050801020900010800-- --===============7663946303385334936== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============7663946303385334936==-- From xen-devel-bounces@lists.xen.org Tue Oct 02 14:32:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:32:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3Wg-0006n0-Sx; Tue, 02 Oct 2012 14:32:46 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3We-0006mh-QK for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:32:45 +0000 Received: from [85.158.139.211:64935] by server-14.bemta-5.messagelabs.com id 6C/81-05772-C0BFA605; Tue, 02 Oct 2012 14:32:44 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-10.tower-206.messagelabs.com!1349188363!20756604!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17658 invoked from network); 2 Oct 2012 14:32:43 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 14:32:43 -0000 X-IronPort-AV: E=Sophos;i="4.80,523,1344211200"; d="scan'208";a="14896136" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 14:32:43 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 15:32:43 +0100 Message-ID: <1349188361.650.77.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Ian Jackson Date: Tue, 2 Oct 2012 15:32:41 +0100 In-Reply-To: <20586.63875.490107.170343@mariner.uk.xensource.com> References: <20121001164239.GE8912@reaktio.net> <20586.63875.490107.170343@mariner.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: George Dunlap , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Xen 4.3 development update X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org T24gVHVlLCAyMDEyLTEwLTAyIGF0IDE1OjI2ICswMTAwLCBJYW4gSmFja3NvbiB3cm90ZToKPiBQ YXNpIEvDpHJra8OkaW5lbiB3cml0ZXMgKCJSZTogW1hlbi1kZXZlbF0gWGVuIDQuMyBkZXZlbG9w bWVudCB1cGRhdGUiKToKPiA+ICAqIHhsIFBWVVNCIHBhc3MtdGhyb3VnaCBmb3IgYm90aCBQViBh bmQgSFZNIGd1ZXN0cwo+ID4gICAgb3duZXI6ID8gCj4gPiAgICBzdGF0dXM6ID8gCj4gPiAgICAt IHhtL3hlbmQgc3VwcG9ydHMgUFZVU0IgcGFzcy10aHJvdWdoIHRvIGd1ZXN0cyB3aXRoIFBWVVNC IGRyaXZlcnMgKGJvdGggUFYgYW5kIEhWTSBndWVzdHMpLgo+ID4gICAgLSBwb3J0IHRoZSB4bS94 ZW5kIGZ1bmN0aW9uYWxpdHkgdG8geGwuCj4gPiAgICAtIHRoaXMgUFZVU0IgZmVhdHVyZSBkb2Vz IG5vdCByZXF1aXJlIHN1cHBvcnQgb3IgZW11bGF0aW9uIGZyb20gUWVtdS4KPiA+ICAgIC0gdXBz dHJlYW0gdGhlIExpbnV4IGZyb250ZW5kL2JhY2tlbmQgZHJpdmVycy4gQ3VycmVudCB3b3JrLWlu LXByb2dyZXNzIHZlcnNpb25zIGFyZSBpbiBLb25yYWQncyBnaXQgdHJlZS4KPiA+ICAgIC0gSmFt ZXMgSGFycGVyJ3MgR1BMUFYgZHJpdmVycyBmb3IgV2luZG93cyBpbmNsdWRlIFBWVVNCIGZyb250 ZW5kIGRyaXZlcnMuCj4gCj4gUmlnaHQuICBJIHRoaW5rIHVwc3RyZWFtaW5nIHRoZSBmcm9udGVu ZC9iYWNrZW5kIGlzIGNyaXRpY2FsIGZvcgo+IHRoaXMuICBJcyB0aGlzIHJlbGF0ZWQgdG8gdGhl IHVzYi1vdmVyLWlwIHN1cHBvcnQgdGhhdCBJIGZvdW5kIGEgZmV3Cj4geWVhcnMgYWdvIGluIGxp bnV4LXN0YWdpbmcgPyAgQXQgdGhlIHRpbWUgdGhhdCB3YXMgdmVyeSBidWdneS4KCkkgZG9uJ3Qg dGhpbmsgc28sIGl0J3MgdGhlIFhlbiBQViBVU0IgcHJvdG9jb2wgZGVmaW5lZCBpbgp4ZW4vaW5j bHVkZS9wdWJsaWMvaW8vdXNiaWYuaC4KCj4gPiAgKiB4bCBVU0IgcGFzcy10aHJvdWdoIGZvciBI Vk0gZ3Vlc3RzIHVzaW5nIFFlbXUgVVNCIGVtdWxhdGlvbgo+ID4gICAgb3duZXI6ID8gCj4gPiAg ICBzdGF0dXM6ID8KPiA+ICAgIC0geG0veGVuZCB3aXRoIHFlbXUtdHJhZGl0aW9uYWwgc3VwcG9y dHMgVVNCIHBhc3N0aHJvdWdoIHRvIEhWTSBndWVzdHMgdXNpbmcgdGhlIFFlbXUgZW11bGF0ZWQg VVNCIGNvbnRyb2xsZXIuCj4gPiAgICAtIHBvcnQgdGhlIHhtL3hlbmQgZnVuY3Rpb25hbGl0eSB0 byB4bC4KPiA+ICAgIC0gbWFrZSBzdXJlIFVTQiBwYXNzdGhyb3VnaCB3aXRoIHhsIHdvcmtzIHdp dGggYm90aCBxZW11LXRyYWRpdGlvbmFsIGFuZCBxZW11LXVwc3RyZWFtLgo+ID4gICAgLSBUaGUg SFZNIGd1ZXN0IGRvZXMgbm90IG5lZWQgYW55IHNwZWNpYWwgZHJpdmVycyBmb3IgdGhpcyBmZWF0 dXJlLgo+IAo+IEkgdGhpbmsgdGhpcyBpcyBqdXN0IGEgbWF0dGVyIG9mIHBsdW1iaW5nIGluIGxp YnhsIChwcmVzdW1hYmx5LCBub3csCj4gcGx1bWJpbmcgdG8gcWVtdS11cHN0cmVhbSkuCgpBc3N1 bWluZyBxZW11LXVwc3RyZWFtIGhhcyB0aGUgbmVjZXNzYXJ5IGZlYXR1cmUuLi4KCklhbi4KCgoK X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y Zy94ZW4tZGV2ZWwK From xen-devel-bounces@lists.xen.org Tue Oct 02 14:32:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:32:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3Wg-0006n0-Sx; Tue, 02 Oct 2012 14:32:46 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3We-0006mh-QK for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:32:45 +0000 Received: from [85.158.139.211:64935] by server-14.bemta-5.messagelabs.com id 6C/81-05772-C0BFA605; Tue, 02 Oct 2012 14:32:44 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-10.tower-206.messagelabs.com!1349188363!20756604!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17658 invoked from network); 2 Oct 2012 14:32:43 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 14:32:43 -0000 X-IronPort-AV: E=Sophos;i="4.80,523,1344211200"; d="scan'208";a="14896136" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 14:32:43 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 15:32:43 +0100 Message-ID: <1349188361.650.77.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Ian Jackson Date: Tue, 2 Oct 2012 15:32:41 +0100 In-Reply-To: <20586.63875.490107.170343@mariner.uk.xensource.com> References: <20121001164239.GE8912@reaktio.net> <20586.63875.490107.170343@mariner.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: George Dunlap , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Xen 4.3 development update X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org T24gVHVlLCAyMDEyLTEwLTAyIGF0IDE1OjI2ICswMTAwLCBJYW4gSmFja3NvbiB3cm90ZToKPiBQ YXNpIEvDpHJra8OkaW5lbiB3cml0ZXMgKCJSZTogW1hlbi1kZXZlbF0gWGVuIDQuMyBkZXZlbG9w bWVudCB1cGRhdGUiKToKPiA+ICAqIHhsIFBWVVNCIHBhc3MtdGhyb3VnaCBmb3IgYm90aCBQViBh bmQgSFZNIGd1ZXN0cwo+ID4gICAgb3duZXI6ID8gCj4gPiAgICBzdGF0dXM6ID8gCj4gPiAgICAt IHhtL3hlbmQgc3VwcG9ydHMgUFZVU0IgcGFzcy10aHJvdWdoIHRvIGd1ZXN0cyB3aXRoIFBWVVNC IGRyaXZlcnMgKGJvdGggUFYgYW5kIEhWTSBndWVzdHMpLgo+ID4gICAgLSBwb3J0IHRoZSB4bS94 ZW5kIGZ1bmN0aW9uYWxpdHkgdG8geGwuCj4gPiAgICAtIHRoaXMgUFZVU0IgZmVhdHVyZSBkb2Vz IG5vdCByZXF1aXJlIHN1cHBvcnQgb3IgZW11bGF0aW9uIGZyb20gUWVtdS4KPiA+ICAgIC0gdXBz dHJlYW0gdGhlIExpbnV4IGZyb250ZW5kL2JhY2tlbmQgZHJpdmVycy4gQ3VycmVudCB3b3JrLWlu LXByb2dyZXNzIHZlcnNpb25zIGFyZSBpbiBLb25yYWQncyBnaXQgdHJlZS4KPiA+ICAgIC0gSmFt ZXMgSGFycGVyJ3MgR1BMUFYgZHJpdmVycyBmb3IgV2luZG93cyBpbmNsdWRlIFBWVVNCIGZyb250 ZW5kIGRyaXZlcnMuCj4gCj4gUmlnaHQuICBJIHRoaW5rIHVwc3RyZWFtaW5nIHRoZSBmcm9udGVu ZC9iYWNrZW5kIGlzIGNyaXRpY2FsIGZvcgo+IHRoaXMuICBJcyB0aGlzIHJlbGF0ZWQgdG8gdGhl IHVzYi1vdmVyLWlwIHN1cHBvcnQgdGhhdCBJIGZvdW5kIGEgZmV3Cj4geWVhcnMgYWdvIGluIGxp bnV4LXN0YWdpbmcgPyAgQXQgdGhlIHRpbWUgdGhhdCB3YXMgdmVyeSBidWdneS4KCkkgZG9uJ3Qg dGhpbmsgc28sIGl0J3MgdGhlIFhlbiBQViBVU0IgcHJvdG9jb2wgZGVmaW5lZCBpbgp4ZW4vaW5j bHVkZS9wdWJsaWMvaW8vdXNiaWYuaC4KCj4gPiAgKiB4bCBVU0IgcGFzcy10aHJvdWdoIGZvciBI Vk0gZ3Vlc3RzIHVzaW5nIFFlbXUgVVNCIGVtdWxhdGlvbgo+ID4gICAgb3duZXI6ID8gCj4gPiAg ICBzdGF0dXM6ID8KPiA+ICAgIC0geG0veGVuZCB3aXRoIHFlbXUtdHJhZGl0aW9uYWwgc3VwcG9y dHMgVVNCIHBhc3N0aHJvdWdoIHRvIEhWTSBndWVzdHMgdXNpbmcgdGhlIFFlbXUgZW11bGF0ZWQg VVNCIGNvbnRyb2xsZXIuCj4gPiAgICAtIHBvcnQgdGhlIHhtL3hlbmQgZnVuY3Rpb25hbGl0eSB0 byB4bC4KPiA+ICAgIC0gbWFrZSBzdXJlIFVTQiBwYXNzdGhyb3VnaCB3aXRoIHhsIHdvcmtzIHdp dGggYm90aCBxZW11LXRyYWRpdGlvbmFsIGFuZCBxZW11LXVwc3RyZWFtLgo+ID4gICAgLSBUaGUg SFZNIGd1ZXN0IGRvZXMgbm90IG5lZWQgYW55IHNwZWNpYWwgZHJpdmVycyBmb3IgdGhpcyBmZWF0 dXJlLgo+IAo+IEkgdGhpbmsgdGhpcyBpcyBqdXN0IGEgbWF0dGVyIG9mIHBsdW1iaW5nIGluIGxp YnhsIChwcmVzdW1hYmx5LCBub3csCj4gcGx1bWJpbmcgdG8gcWVtdS11cHN0cmVhbSkuCgpBc3N1 bWluZyBxZW11LXVwc3RyZWFtIGhhcyB0aGUgbmVjZXNzYXJ5IGZlYXR1cmUuLi4KCklhbi4KCgoK X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y Zy94ZW4tZGV2ZWwK From xen-devel-bounces@lists.xen.org Tue Oct 02 14:33:42 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:33:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3XS-0006ve-C4; Tue, 02 Oct 2012 14:33:34 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3XR-0006vH-Gj for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:33:33 +0000 Received: from [85.158.143.35:53705] by server-2.bemta-4.messagelabs.com id 82/37-06610-C3BFA605; Tue, 02 Oct 2012 14:33:32 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-2.tower-21.messagelabs.com!1349188412!9712837!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18196 invoked from network); 2 Oct 2012 14:33:32 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-2.tower-21.messagelabs.com with SMTP; 2 Oct 2012 14:33:32 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 02 Oct 2012 15:33:31 +0100 Message-Id: <506B1758020000780009F1CD@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Tue, 02 Oct 2012 15:33:28 +0100 From: "Jan Beulich" To: "xen-devel" Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part81B0B628.1__=" Cc: Wei Wang Subject: [Xen-devel] [PATCH] AMD IOMMU: fix find_iommu_from_bdf_cap() X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part81B0B628.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline The arguments passed for the "cap_offset" parameter get read from 16- bit fields, so the parameter should also have (at least) 16 bits. While fixing this I also noticed that this was yet another case where PCI segment information wasn't properly propagated, so a respective first parameter gets added to the function at once. Signed-off-by: Jan Beulich --- a/xen/drivers/passthrough/amd/iommu_acpi.c +++ b/xen/drivers/passthrough/amd/iommu_acpi.c @@ -86,12 +86,13 @@ static void __init add_ivrs_mapping_entr } =20 static struct amd_iommu * __init find_iommu_from_bdf_cap( - u16 bdf, u8 cap_offset) + u16 seg, u16 bdf, u16 cap_offset) { struct amd_iommu *iommu; =20 for_each_amd_iommu ( iommu ) - if ( (iommu->bdf =3D=3D bdf) && (iommu->cap_offset =3D=3D = cap_offset) ) + if ( (iommu->seg =3D=3D seg) && (iommu->bdf =3D=3D bdf) && + (iommu->cap_offset =3D=3D cap_offset) ) return iommu; =20 return NULL; @@ -319,10 +320,11 @@ static int __init parse_ivmd_device_iomm const struct acpi_ivrs_memory *ivmd_block, unsigned long base, unsigned long limit, u8 iw, u8 ir) { + int seg =3D 0; /* XXX */ struct amd_iommu *iommu; =20 /* find target IOMMU */ - iommu =3D find_iommu_from_bdf_cap(ivmd_block->header.device_id, + iommu =3D find_iommu_from_bdf_cap(seg, ivmd_block->header.device_id, ivmd_block->aux_data); if ( !iommu ) { @@ -669,7 +671,8 @@ static int __init parse_ivhd_block(const return -ENODEV; } =20 - iommu =3D find_iommu_from_bdf_cap(ivhd_block->header.device_id, + iommu =3D find_iommu_from_bdf_cap(ivhd_block->pci_segment_group, + ivhd_block->header.device_id, ivhd_block->capability_offset); if ( !iommu ) { --=__Part81B0B628.1__= Content-Type: text/plain; name="AMD-IOMMU-cap-width.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="AMD-IOMMU-cap-width.patch" AMD IOMMU: fix find_iommu_from_bdf_cap()=0A=0AThe arguments passed for the = "cap_offset" parameter get read from 16-=0Abit fields, so the parameter = should also have (at least) 16 bits.=0A=0AWhile fixing this I also noticed = that this was yet another case where=0APCI segment information wasn't = properly propagated, so a respective=0Afirst parameter gets added to the = function at once.=0A=0ASigned-off-by: Jan Beulich =0A=0A= --- a/xen/drivers/passthrough/amd/iommu_acpi.c=0A+++ b/xen/drivers/passthro= ugh/amd/iommu_acpi.c=0A@@ -86,12 +86,13 @@ static void __init add_ivrs_mapp= ing_entr=0A }=0A =0A static struct amd_iommu * __init find_iommu_from_bdf_c= ap(=0A- u16 bdf, u8 cap_offset)=0A+ u16 seg, u16 bdf, u16 cap_offset)= =0A {=0A struct amd_iommu *iommu;=0A =0A for_each_amd_iommu ( = iommu )=0A- if ( (iommu->bdf =3D=3D bdf) && (iommu->cap_offset = =3D=3D cap_offset) )=0A+ if ( (iommu->seg =3D=3D seg) && (iommu->bdf= =3D=3D bdf) &&=0A+ (iommu->cap_offset =3D=3D cap_offset) )=0A = return iommu;=0A =0A return NULL;=0A@@ -319,10 +320,11 @@ = static int __init parse_ivmd_device_iomm=0A const struct acpi_ivrs_memo= ry *ivmd_block,=0A unsigned long base, unsigned long limit, u8 iw, u8 = ir)=0A {=0A+ int seg =3D 0; /* XXX */=0A struct amd_iommu *iommu;=0A= =0A /* find target IOMMU */=0A- iommu =3D find_iommu_from_bdf_cap(i= vmd_block->header.device_id,=0A+ iommu =3D find_iommu_from_bdf_cap(seg, = ivmd_block->header.device_id,=0A = ivmd_block->aux_data);=0A if ( !iommu )=0A {=0A@@ -669,7 +671,8 @@ = static int __init parse_ivhd_block(const=0A return -ENODEV;=0A = }=0A =0A- iommu =3D find_iommu_from_bdf_cap(ivhd_block->header.device_id= ,=0A+ iommu =3D find_iommu_from_bdf_cap(ivhd_block->pci_segment_group,= =0A+ ivhd_block->header.device_id,=0A = ivhd_block->capability_offset);=0A = if ( !iommu )=0A {=0A --=__Part81B0B628.1__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --=__Part81B0B628.1__=-- From xen-devel-bounces@lists.xen.org Tue Oct 02 14:33:42 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:33:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3XS-0006ve-C4; Tue, 02 Oct 2012 14:33:34 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3XR-0006vH-Gj for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:33:33 +0000 Received: from [85.158.143.35:53705] by server-2.bemta-4.messagelabs.com id 82/37-06610-C3BFA605; Tue, 02 Oct 2012 14:33:32 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-2.tower-21.messagelabs.com!1349188412!9712837!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18196 invoked from network); 2 Oct 2012 14:33:32 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-2.tower-21.messagelabs.com with SMTP; 2 Oct 2012 14:33:32 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 02 Oct 2012 15:33:31 +0100 Message-Id: <506B1758020000780009F1CD@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Tue, 02 Oct 2012 15:33:28 +0100 From: "Jan Beulich" To: "xen-devel" Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part81B0B628.1__=" Cc: Wei Wang Subject: [Xen-devel] [PATCH] AMD IOMMU: fix find_iommu_from_bdf_cap() X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part81B0B628.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline The arguments passed for the "cap_offset" parameter get read from 16- bit fields, so the parameter should also have (at least) 16 bits. While fixing this I also noticed that this was yet another case where PCI segment information wasn't properly propagated, so a respective first parameter gets added to the function at once. Signed-off-by: Jan Beulich --- a/xen/drivers/passthrough/amd/iommu_acpi.c +++ b/xen/drivers/passthrough/amd/iommu_acpi.c @@ -86,12 +86,13 @@ static void __init add_ivrs_mapping_entr } =20 static struct amd_iommu * __init find_iommu_from_bdf_cap( - u16 bdf, u8 cap_offset) + u16 seg, u16 bdf, u16 cap_offset) { struct amd_iommu *iommu; =20 for_each_amd_iommu ( iommu ) - if ( (iommu->bdf =3D=3D bdf) && (iommu->cap_offset =3D=3D = cap_offset) ) + if ( (iommu->seg =3D=3D seg) && (iommu->bdf =3D=3D bdf) && + (iommu->cap_offset =3D=3D cap_offset) ) return iommu; =20 return NULL; @@ -319,10 +320,11 @@ static int __init parse_ivmd_device_iomm const struct acpi_ivrs_memory *ivmd_block, unsigned long base, unsigned long limit, u8 iw, u8 ir) { + int seg =3D 0; /* XXX */ struct amd_iommu *iommu; =20 /* find target IOMMU */ - iommu =3D find_iommu_from_bdf_cap(ivmd_block->header.device_id, + iommu =3D find_iommu_from_bdf_cap(seg, ivmd_block->header.device_id, ivmd_block->aux_data); if ( !iommu ) { @@ -669,7 +671,8 @@ static int __init parse_ivhd_block(const return -ENODEV; } =20 - iommu =3D find_iommu_from_bdf_cap(ivhd_block->header.device_id, + iommu =3D find_iommu_from_bdf_cap(ivhd_block->pci_segment_group, + ivhd_block->header.device_id, ivhd_block->capability_offset); if ( !iommu ) { --=__Part81B0B628.1__= Content-Type: text/plain; name="AMD-IOMMU-cap-width.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="AMD-IOMMU-cap-width.patch" AMD IOMMU: fix find_iommu_from_bdf_cap()=0A=0AThe arguments passed for the = "cap_offset" parameter get read from 16-=0Abit fields, so the parameter = should also have (at least) 16 bits.=0A=0AWhile fixing this I also noticed = that this was yet another case where=0APCI segment information wasn't = properly propagated, so a respective=0Afirst parameter gets added to the = function at once.=0A=0ASigned-off-by: Jan Beulich =0A=0A= --- a/xen/drivers/passthrough/amd/iommu_acpi.c=0A+++ b/xen/drivers/passthro= ugh/amd/iommu_acpi.c=0A@@ -86,12 +86,13 @@ static void __init add_ivrs_mapp= ing_entr=0A }=0A =0A static struct amd_iommu * __init find_iommu_from_bdf_c= ap(=0A- u16 bdf, u8 cap_offset)=0A+ u16 seg, u16 bdf, u16 cap_offset)= =0A {=0A struct amd_iommu *iommu;=0A =0A for_each_amd_iommu ( = iommu )=0A- if ( (iommu->bdf =3D=3D bdf) && (iommu->cap_offset = =3D=3D cap_offset) )=0A+ if ( (iommu->seg =3D=3D seg) && (iommu->bdf= =3D=3D bdf) &&=0A+ (iommu->cap_offset =3D=3D cap_offset) )=0A = return iommu;=0A =0A return NULL;=0A@@ -319,10 +320,11 @@ = static int __init parse_ivmd_device_iomm=0A const struct acpi_ivrs_memo= ry *ivmd_block,=0A unsigned long base, unsigned long limit, u8 iw, u8 = ir)=0A {=0A+ int seg =3D 0; /* XXX */=0A struct amd_iommu *iommu;=0A= =0A /* find target IOMMU */=0A- iommu =3D find_iommu_from_bdf_cap(i= vmd_block->header.device_id,=0A+ iommu =3D find_iommu_from_bdf_cap(seg, = ivmd_block->header.device_id,=0A = ivmd_block->aux_data);=0A if ( !iommu )=0A {=0A@@ -669,7 +671,8 @@ = static int __init parse_ivhd_block(const=0A return -ENODEV;=0A = }=0A =0A- iommu =3D find_iommu_from_bdf_cap(ivhd_block->header.device_id= ,=0A+ iommu =3D find_iommu_from_bdf_cap(ivhd_block->pci_segment_group,= =0A+ ivhd_block->header.device_id,=0A = ivhd_block->capability_offset);=0A = if ( !iommu )=0A {=0A --=__Part81B0B628.1__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --=__Part81B0B628.1__=-- From xen-devel-bounces@lists.xen.org Tue Oct 02 14:37:27 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:37:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3b0-0007DX-0z; Tue, 02 Oct 2012 14:37:14 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3ay-0007DP-8X for Xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:37:12 +0000 Received: from [85.158.139.211:2601] by server-15.bemta-5.messagelabs.com id 5A/3C-19430-71CFA605; Tue, 02 Oct 2012 14:37:11 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-8.tower-206.messagelabs.com!1349188629!20772327!1 X-Originating-IP: [209.85.213.173] X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG, HTML_20_30, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31068 invoked from network); 2 Oct 2012 14:37:10 -0000 Received: from mail-yx0-f173.google.com (HELO mail-yx0-f173.google.com) (209.85.213.173) by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 14:37:10 -0000 Received: by yenl3 with SMTP id l3so1921820yen.32 for ; Tue, 02 Oct 2012 07:37:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3nTG/AQdPWWBHmcwwUyNcKNW5ehgtbaAlDhK7DowIHU=; b=AyMd8bXQnlCzkYl/7xMB8dC5Xcnu21HgXrNxUY3bCSzUh18tJw7Adybk2uP5SO5KsU u7ox+d9dq68k5VhbB4LBPvVVADbKWOB8Qn3z9/NbAjVed/mr/nvlUxpAmQj1Ti+XrhUC WxzZmDI56n12vpXPetIkOib6ZTHhF76P2hxvEdi1lrHMQ3rDhJvweRR0rHL8BWgVc8WC WGlBCh4fbmxr8bpuKMtqMXt8N9kbaQK0b7hP70UYAVQE7j62yiO5pqRt/l+KPff5bwvF 3cwqZxWQCpyUc3QekY6YWX3VjYUJm5ETer6UmAu5WrNrr8mzEV5HyE3bAHjS5c2vJCEO zSzA== MIME-Version: 1.0 Received: by 10.236.52.33 with SMTP id d21mr15627923yhc.58.1349188628979; Tue, 02 Oct 2012 07:37:08 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Tue, 2 Oct 2012 07:37:08 -0700 (PDT) In-Reply-To: References: <20121001144042.GC8912@reaktio.net> <20121001160117.GD8912@reaktio.net> <20121001164757.GF8912@reaktio.net> <20121001182437.GG8912@reaktio.net> <20121002121932.GL8912@reaktio.net> Date: Tue, 2 Oct 2012 17:37:08 +0300 Message-ID: From: Valtteri Kiviniemi To: Konrad Rzeszutek Wilk Cc: Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.0.4, kernel 3.5.0 HVM crash and kernel BUG X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1960366268848015410==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============1960366268848015410== Content-Type: multipart/alternative; boundary=bcaec508f31cf7218f04cb147409 --bcaec508f31cf7218f04cb147409 Content-Type: text/plain; charset=ISO-8859-1 Hi, Tried boogin with vif-parameters commented out, result is the same: Error: Device 768 (vbd) could not be connected. Hotplug scripts not working. But what is more troubling with these issues I'm having is the fact that this "hotpluf scripts not working" came out of nowhere. I was able to boot my Windows domU just fine earlier with only problem being that the VNC output was just black screen after Windows installer had started. Then I tried to create a Linux HVM (debian squeeze) and then I got that "Hotplug scripts not working" error. And after trying to start Windows domU again it says that same "Hotplug scripts not working" error. If I reboot the machine and start my Windows domU it will start again just fine, but the VNC output is just black screen. Then again, if I start the Linux HVM domU I will again get that "Hotplug scripts not working" error and then the Windows domU wont start either again and tells the same "Hotplug scripts not working" error. So this is pretty confusing and troubling indeed. I will reboot the machine later and put those boot parameters that Pasi mentioned. - Valtteri 2012/10/2 Konrad Rzeszutek Wilk > On Tue, Oct 2, 2012 at 9:01 AM, Valtteri Kiviniemi > wrote: > > Hi, > > > > I already tried 3.2, 3.5, 3.5.0, 3.6.0-rc7 and 3.6.0, same problem all of > > those. My dom0 config is the same config that I'am using on other server > > where HVM is working, so I dont think that it is a config problem. I have > > triple checked everything and all should be ok. dom0 dmesg shows the same > > crash that I have previously posted here. /var/log/xen/ does not contain > any > > specific errors. > > > > Could this be some kind of broblem with my motherboard bios being buggy > or > > CPU not supported? I'm using the new intel Ivy Bridge processor which has > > integrated GPU, but that should not probably cause these kind of > problems. > > Or maybe some ACPI problem? xm dmesg is showing some notices about ACPI. > Is > > there any ACPI kernel parameters that I should try booting? This has to > be > > somekind of problem with my hardware, or then maybe it could be a kernel > > problem too. I just really cant figure this out myself, I have tried > > everything. > > > > Lets take a quick summary of what has been tested, what hardware I'm > using > > etc. > > > > Xen-versions tested: 4.2.0, 4.0.4 > > Kernel-versions tested: 3.2.0, 3.5.0, 3.5.4, 3.6.0-rc7, 3.6.0 > > > > Host OS: Debian testing/wheezy, udev version 175-7, 2.13-35, python > version > > 2.7.3~rc2-2.1 > > > > Hardware: > > > > CPU: Intel Core i7-3770 3.4GHz > > MB: Intel DQ77MK (latest bios updated) > > Memory: 32GB (4 x 8GB DDR3-1600MHz) > > > > All relevant log files and configs: > > > > dom0 dmesg: http://nago.fi/dmesg.txt > > qemu-dm log: http://nago.fi/qemu-dm.txt > > xm dmesg log: http://nago.fi/xm-dmesg.txt > > domU config: http://nago.fi/domu-config.txt > > dom0 kernel config: http://nago.fi/dom0-config.txt > > > > I have also tried playing with every setting on that domU that I can > think > > of and tried different configs etc. > > This is troubling. You seem to trigger the QEMU closing the tunX (your > Windows's guest network interface) which then crashes somehow. > Just to make sure that this is the case - can you try launching your > guest without network and seeing what happens? > --bcaec508f31cf7218f04cb147409 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Tried boogin with vif-parameters commented out, result is the sa= me:

Error: Device 768 (vbd) could not be connected. Hotplug scripts = not working.

But what is more troubling with these issues I'm ha= ving is the fact that this "hotpluf scripts not working" came out= of nowhere. I was able to boot my Windows domU just fine earlier with only= problem being that the VNC output was just black screen after Windows inst= aller had started. Then I tried to create a Linux HVM (debian squeeze) and = then I got that "Hotplug scripts not working" error. And after tr= ying to start Windows domU again it says that same "Hotplug scripts no= t working" error.

If I reboot the machine and start my Windows domU it will start again j= ust fine, but the VNC output is just black screen. Then again, if I start t= he Linux HVM domU I will again get that "Hotplug scripts not working&q= uot; error and then the Windows domU wont start either again and tells the = same "Hotplug scripts not working" error.

So this is pretty confusing and troubling indeed.

I will reboot = the machine later and put those boot parameters that Pasi mentioned.
- Valtteri


2012/10/2 Konrad Rzeszute= k Wilk <konrad@kernel.org>
On T= ue, Oct 2, 2012 at 9:01 AM, Valtteri Kiviniemi
<kiviniemi.valtteri@gmai= l.com> wrote:
> Hi,
>
> I already tried 3.2, 3.5, 3.5.0, 3.6.0-rc7 and 3.6.0, same problem all= of
> those. My dom0 config is the same config that I'am using on other = server
> where HVM is working, so I dont think that it is a config problem. I h= ave
> triple checked everything and all should be ok. dom0 dmesg shows the s= ame
> crash that I have previously posted here. /var/log/xen/ does not conta= in any
> specific errors.
>
> Could this be some kind of broblem with my motherboard bios being bugg= y or
> CPU not supported? I'm using the new intel Ivy Bridge processor wh= ich has
> integrated GPU, but that should not probably cause these kind of probl= ems.
> Or maybe some ACPI problem? xm dmesg is showing some notices about ACP= I. Is
> there any ACPI kernel parameters that I should try booting? This has t= o be
> somekind of problem with my hardware, or then maybe it could be a kern= el
> problem too. I just really cant figure this out myself, I have tried > everything.
>
> Lets take a quick summary of what has been tested, what hardware I'= ;m using
> etc.
>
> Xen-versions tested: 4.2.0, 4.0.4
> Kernel-versions tested: 3.2.0, 3.5.0, 3.5.4, 3.6.0-rc7, 3.6.0
>
> Host OS: Debian testing/wheezy, udev version 175-7, 2.13-35, python ve= rsion
> 2.7.3~rc2-2.1
>
> Hardware:
>
> CPU: Intel Core i7-3770 3.4GHz
> MB: Intel DQ77MK (latest bios updated)
> Memory: 32GB (4 x 8GB DDR3-1600MHz)
>
> All relevant log files and configs:
>
> dom0 dmesg: htt= p://nago.fi/dmesg.txt
> qemu-dm log: = http://nago.fi/qemu-dm.txt
> xm dmesg log: http://nago.fi/xm-dmesg.txt
> domU config: http://nago.fi/domu-config.txt
> dom0 kernel config: http://nago.fi/dom0-config.txt
>
> I have also tried playing with every setting on that domU that I can t= hink
> of and tried different configs etc.

This is troubling. You seem to trigger the QEMU closing the tun= X (your
Windows's guest network interface) which then crashes somehow.
Just to make sure that this is the case - can you try launching your
guest without network and seeing what happens?

--bcaec508f31cf7218f04cb147409-- --===============1960366268848015410== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============1960366268848015410==-- From xen-devel-bounces@lists.xen.org Tue Oct 02 14:37:27 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:37:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3b0-0007DX-0z; Tue, 02 Oct 2012 14:37:14 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3ay-0007DP-8X for Xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:37:12 +0000 Received: from [85.158.139.211:2601] by server-15.bemta-5.messagelabs.com id 5A/3C-19430-71CFA605; Tue, 02 Oct 2012 14:37:11 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-8.tower-206.messagelabs.com!1349188629!20772327!1 X-Originating-IP: [209.85.213.173] X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG, HTML_20_30, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31068 invoked from network); 2 Oct 2012 14:37:10 -0000 Received: from mail-yx0-f173.google.com (HELO mail-yx0-f173.google.com) (209.85.213.173) by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 14:37:10 -0000 Received: by yenl3 with SMTP id l3so1921820yen.32 for ; Tue, 02 Oct 2012 07:37:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3nTG/AQdPWWBHmcwwUyNcKNW5ehgtbaAlDhK7DowIHU=; b=AyMd8bXQnlCzkYl/7xMB8dC5Xcnu21HgXrNxUY3bCSzUh18tJw7Adybk2uP5SO5KsU u7ox+d9dq68k5VhbB4LBPvVVADbKWOB8Qn3z9/NbAjVed/mr/nvlUxpAmQj1Ti+XrhUC WxzZmDI56n12vpXPetIkOib6ZTHhF76P2hxvEdi1lrHMQ3rDhJvweRR0rHL8BWgVc8WC WGlBCh4fbmxr8bpuKMtqMXt8N9kbaQK0b7hP70UYAVQE7j62yiO5pqRt/l+KPff5bwvF 3cwqZxWQCpyUc3QekY6YWX3VjYUJm5ETer6UmAu5WrNrr8mzEV5HyE3bAHjS5c2vJCEO zSzA== MIME-Version: 1.0 Received: by 10.236.52.33 with SMTP id d21mr15627923yhc.58.1349188628979; Tue, 02 Oct 2012 07:37:08 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Tue, 2 Oct 2012 07:37:08 -0700 (PDT) In-Reply-To: References: <20121001144042.GC8912@reaktio.net> <20121001160117.GD8912@reaktio.net> <20121001164757.GF8912@reaktio.net> <20121001182437.GG8912@reaktio.net> <20121002121932.GL8912@reaktio.net> Date: Tue, 2 Oct 2012 17:37:08 +0300 Message-ID: From: Valtteri Kiviniemi To: Konrad Rzeszutek Wilk Cc: Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.0.4, kernel 3.5.0 HVM crash and kernel BUG X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1960366268848015410==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============1960366268848015410== Content-Type: multipart/alternative; boundary=bcaec508f31cf7218f04cb147409 --bcaec508f31cf7218f04cb147409 Content-Type: text/plain; charset=ISO-8859-1 Hi, Tried boogin with vif-parameters commented out, result is the same: Error: Device 768 (vbd) could not be connected. Hotplug scripts not working. But what is more troubling with these issues I'm having is the fact that this "hotpluf scripts not working" came out of nowhere. I was able to boot my Windows domU just fine earlier with only problem being that the VNC output was just black screen after Windows installer had started. Then I tried to create a Linux HVM (debian squeeze) and then I got that "Hotplug scripts not working" error. And after trying to start Windows domU again it says that same "Hotplug scripts not working" error. If I reboot the machine and start my Windows domU it will start again just fine, but the VNC output is just black screen. Then again, if I start the Linux HVM domU I will again get that "Hotplug scripts not working" error and then the Windows domU wont start either again and tells the same "Hotplug scripts not working" error. So this is pretty confusing and troubling indeed. I will reboot the machine later and put those boot parameters that Pasi mentioned. - Valtteri 2012/10/2 Konrad Rzeszutek Wilk > On Tue, Oct 2, 2012 at 9:01 AM, Valtteri Kiviniemi > wrote: > > Hi, > > > > I already tried 3.2, 3.5, 3.5.0, 3.6.0-rc7 and 3.6.0, same problem all of > > those. My dom0 config is the same config that I'am using on other server > > where HVM is working, so I dont think that it is a config problem. I have > > triple checked everything and all should be ok. dom0 dmesg shows the same > > crash that I have previously posted here. /var/log/xen/ does not contain > any > > specific errors. > > > > Could this be some kind of broblem with my motherboard bios being buggy > or > > CPU not supported? I'm using the new intel Ivy Bridge processor which has > > integrated GPU, but that should not probably cause these kind of > problems. > > Or maybe some ACPI problem? xm dmesg is showing some notices about ACPI. > Is > > there any ACPI kernel parameters that I should try booting? This has to > be > > somekind of problem with my hardware, or then maybe it could be a kernel > > problem too. I just really cant figure this out myself, I have tried > > everything. > > > > Lets take a quick summary of what has been tested, what hardware I'm > using > > etc. > > > > Xen-versions tested: 4.2.0, 4.0.4 > > Kernel-versions tested: 3.2.0, 3.5.0, 3.5.4, 3.6.0-rc7, 3.6.0 > > > > Host OS: Debian testing/wheezy, udev version 175-7, 2.13-35, python > version > > 2.7.3~rc2-2.1 > > > > Hardware: > > > > CPU: Intel Core i7-3770 3.4GHz > > MB: Intel DQ77MK (latest bios updated) > > Memory: 32GB (4 x 8GB DDR3-1600MHz) > > > > All relevant log files and configs: > > > > dom0 dmesg: http://nago.fi/dmesg.txt > > qemu-dm log: http://nago.fi/qemu-dm.txt > > xm dmesg log: http://nago.fi/xm-dmesg.txt > > domU config: http://nago.fi/domu-config.txt > > dom0 kernel config: http://nago.fi/dom0-config.txt > > > > I have also tried playing with every setting on that domU that I can > think > > of and tried different configs etc. > > This is troubling. You seem to trigger the QEMU closing the tunX (your > Windows's guest network interface) which then crashes somehow. > Just to make sure that this is the case - can you try launching your > guest without network and seeing what happens? > --bcaec508f31cf7218f04cb147409 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Tried boogin with vif-parameters commented out, result is the sa= me:

Error: Device 768 (vbd) could not be connected. Hotplug scripts = not working.

But what is more troubling with these issues I'm ha= ving is the fact that this "hotpluf scripts not working" came out= of nowhere. I was able to boot my Windows domU just fine earlier with only= problem being that the VNC output was just black screen after Windows inst= aller had started. Then I tried to create a Linux HVM (debian squeeze) and = then I got that "Hotplug scripts not working" error. And after tr= ying to start Windows domU again it says that same "Hotplug scripts no= t working" error.

If I reboot the machine and start my Windows domU it will start again j= ust fine, but the VNC output is just black screen. Then again, if I start t= he Linux HVM domU I will again get that "Hotplug scripts not working&q= uot; error and then the Windows domU wont start either again and tells the = same "Hotplug scripts not working" error.

So this is pretty confusing and troubling indeed.

I will reboot = the machine later and put those boot parameters that Pasi mentioned.
- Valtteri


2012/10/2 Konrad Rzeszute= k Wilk <konrad@kernel.org>
On T= ue, Oct 2, 2012 at 9:01 AM, Valtteri Kiviniemi
<kiviniemi.valtteri@gmai= l.com> wrote:
> Hi,
>
> I already tried 3.2, 3.5, 3.5.0, 3.6.0-rc7 and 3.6.0, same problem all= of
> those. My dom0 config is the same config that I'am using on other = server
> where HVM is working, so I dont think that it is a config problem. I h= ave
> triple checked everything and all should be ok. dom0 dmesg shows the s= ame
> crash that I have previously posted here. /var/log/xen/ does not conta= in any
> specific errors.
>
> Could this be some kind of broblem with my motherboard bios being bugg= y or
> CPU not supported? I'm using the new intel Ivy Bridge processor wh= ich has
> integrated GPU, but that should not probably cause these kind of probl= ems.
> Or maybe some ACPI problem? xm dmesg is showing some notices about ACP= I. Is
> there any ACPI kernel parameters that I should try booting? This has t= o be
> somekind of problem with my hardware, or then maybe it could be a kern= el
> problem too. I just really cant figure this out myself, I have tried > everything.
>
> Lets take a quick summary of what has been tested, what hardware I'= ;m using
> etc.
>
> Xen-versions tested: 4.2.0, 4.0.4
> Kernel-versions tested: 3.2.0, 3.5.0, 3.5.4, 3.6.0-rc7, 3.6.0
>
> Host OS: Debian testing/wheezy, udev version 175-7, 2.13-35, python ve= rsion
> 2.7.3~rc2-2.1
>
> Hardware:
>
> CPU: Intel Core i7-3770 3.4GHz
> MB: Intel DQ77MK (latest bios updated)
> Memory: 32GB (4 x 8GB DDR3-1600MHz)
>
> All relevant log files and configs:
>
> dom0 dmesg: htt= p://nago.fi/dmesg.txt
> qemu-dm log: = http://nago.fi/qemu-dm.txt
> xm dmesg log: http://nago.fi/xm-dmesg.txt
> domU config: http://nago.fi/domu-config.txt
> dom0 kernel config: http://nago.fi/dom0-config.txt
>
> I have also tried playing with every setting on that domU that I can t= hink
> of and tried different configs etc.

This is troubling. You seem to trigger the QEMU closing the tun= X (your
Windows's guest network interface) which then crashes somehow.
Just to make sure that this is the case - can you try launching your
guest without network and seeing what happens?

--bcaec508f31cf7218f04cb147409-- --===============1960366268848015410== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============1960366268848015410==-- From xen-devel-bounces@lists.xen.org Tue Oct 02 14:39:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:39:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3cu-0007MR-Of; Tue, 02 Oct 2012 14:39:12 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3cs-0007MD-DL for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:39:10 +0000 Received: from [85.158.143.35:32071] by server-1.bemta-4.messagelabs.com id 08/44-05684-C8CFA605; Tue, 02 Oct 2012 14:39:08 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1349188747!17171547!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32763 invoked from network); 2 Oct 2012 14:39:07 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-14.tower-21.messagelabs.com with SMTP; 2 Oct 2012 14:39:07 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 02 Oct 2012 15:39:07 +0100 Message-Id: <506B18A7020000780009F1E4@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Tue, 02 Oct 2012 15:39:03 +0100 From: "Jan Beulich" To: "xen-devel" Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part39080E97.1__=" Cc: xiantao.zhang@intel.com Subject: [Xen-devel] [PATCH] VT-d: drop bogus checks X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part39080E97.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline There were a number of cases where an "iommu" retrieved got passed to another function before being NULL-checked. While this by itself was not a problem as the called function did the checks, it is confusing to the reader and redundant in several cases (particularly with NULL- checking the return value of iommu_ir_ctrl()). Drop the redundant checks (also ones where the sole caller of a function did the checking already), and at once make the three similar functions proper inline instead of extern ones (they were prototyped in the wrong header file anyway, so would have needed touching sooner or later). Signed-off-by: Jan Beulich --- a/xen/drivers/passthrough/vtd/intremap.c +++ b/xen/drivers/passthrough/vtd/intremap.c @@ -217,13 +217,6 @@ static int remap_entry_to_ioapic_rte( unsigned long flags; struct ir_ctrl *ir_ctrl =3D iommu_ir_ctrl(iommu); =20 - if ( ir_ctrl =3D=3D NULL ) - { - dprintk(XENLOG_ERR VTDPREFIX, - "remap_entry_to_ioapic_rte: ir_ctl is not ready\n"); - return -EFAULT; - } - if ( index < 0 || index > IREMAP_ENTRY_NR - 1 ) { dprintk(XENLOG_ERR VTDPREFIX, @@ -358,8 +351,7 @@ unsigned int io_apic_read_remap_rte( struct iommu *iommu =3D ioapic_to_iommu(IO_APIC_ID(apic)); struct ir_ctrl *ir_ctrl =3D iommu_ir_ctrl(iommu); =20 - if ( !iommu || !ir_ctrl || ir_ctrl->iremap_maddr =3D=3D 0 || - (ir_ctrl->iremap_num =3D=3D 0) || + if ( !ir_ctrl || !ir_ctrl->iremap_maddr || !ir_ctrl->iremap_num || ( (index =3D apic_pin_2_ir_idx[apic][ioapic_pin]) < 0 ) ) return __io_apic_read(apic, reg); =20 @@ -385,7 +377,7 @@ void io_apic_write_remap_rte( struct ir_ctrl *ir_ctrl =3D iommu_ir_ctrl(iommu); int saved_mask; =20 - if ( !iommu || !ir_ctrl || ir_ctrl->iremap_maddr =3D=3D 0 ) + if ( !ir_ctrl || !ir_ctrl->iremap_maddr ) { __io_apic_write(apic, reg, value); return; @@ -475,13 +467,6 @@ static int remap_entry_to_msi_msg( unsigned long flags; struct ir_ctrl *ir_ctrl =3D iommu_ir_ctrl(iommu); =20 - if ( ir_ctrl =3D=3D NULL ) - { - dprintk(XENLOG_ERR VTDPREFIX, - "remap_entry_to_msi_msg: ir_ctl =3D=3D NULL"); - return -EFAULT; - } - remap_rte =3D (struct msi_msg_remap_entry *) msg; index =3D (remap_rte->address_lo.index_15 << 15) | remap_rte->address_lo.index_0_14; @@ -644,7 +629,7 @@ void msi_msg_read_remap_rte( iommu =3D drhd->iommu; =20 ir_ctrl =3D iommu_ir_ctrl(iommu); - if ( !iommu || !ir_ctrl || ir_ctrl->iremap_maddr =3D=3D 0 ) + if ( !ir_ctrl || !ir_ctrl->iremap_maddr ) return; =20 remap_entry_to_msi_msg(iommu, msg); @@ -663,7 +648,7 @@ void msi_msg_write_remap_rte( iommu =3D drhd->iommu; =20 ir_ctrl =3D iommu_ir_ctrl(iommu); - if ( !iommu || !ir_ctrl || ir_ctrl->iremap_maddr =3D=3D 0 ) + if ( !ir_ctrl || !ir_ctrl->iremap_maddr ) return; =20 msi_msg_to_remap_entry(iommu, pdev, msi_desc, msg); --- a/xen/drivers/passthrough/vtd/iommu.c +++ b/xen/drivers/passthrough/vtd/iommu.c @@ -153,21 +153,6 @@ static void __init free_intel_iommu(stru xfree(intel); } =20 -struct qi_ctrl *iommu_qi_ctrl(struct iommu *iommu) -{ - return iommu ? &iommu->intel->qi_ctrl : NULL; -} - -struct ir_ctrl *iommu_ir_ctrl(struct iommu *iommu) -{ - return iommu ? &iommu->intel->ir_ctrl : NULL; -} - -struct iommu_flush *iommu_get_flush(struct iommu *iommu) -{ - return iommu ? &iommu->intel->flush : NULL; -} - static int iommus_incoherent; static void __iommu_flush_cache(void *addr, unsigned int size) { --- a/xen/drivers/passthrough/vtd/iommu.h +++ b/xen/drivers/passthrough/vtd/iommu.h @@ -20,7 +20,7 @@ #ifndef _INTEL_IOMMU_H_ #define _INTEL_IOMMU_H_ =20 -#include +#include =20 /* * Intel IOMMU register specification per version 1.0 public spec. @@ -510,6 +510,21 @@ struct intel_iommu { struct acpi_drhd_unit *drhd; }; =20 +static inline struct qi_ctrl *iommu_qi_ctrl(struct iommu *iommu) +{ + return iommu ? &iommu->intel->qi_ctrl : NULL; +} + +static inline struct ir_ctrl *iommu_ir_ctrl(struct iommu *iommu) +{ + return iommu ? &iommu->intel->ir_ctrl : NULL; +} + +static inline struct iommu_flush *iommu_get_flush(struct iommu *iommu) +{ + return iommu ? &iommu->intel->flush : NULL; +} + #define INTEL_IOMMU_DEBUG(fmt, args...) \ do \ { \ --- a/xen/drivers/passthrough/vtd/utils.c +++ b/xen/drivers/passthrough/vtd/utils.c @@ -267,8 +267,7 @@ static void dump_iommu_info(unsigned cha { iommu =3D ioapic_to_iommu(mp_ioapics[apic].mpc_apicid); ir_ctrl =3D iommu_ir_ctrl(iommu); - if ( !iommu || !ir_ctrl || ir_ctrl->iremap_maddr =3D=3D 0 || - ir_ctrl->iremap_num =3D=3D 0 ) + if ( !ir_ctrl || !ir_ctrl->iremap_maddr || !ir_ctrl->iremap_nu= m ) continue; =20 printk( "\nRedirection table of IOAPIC %x:\n", apic); --- a/xen/include/xen/iommu.h +++ b/xen/include/xen/iommu.h @@ -106,9 +106,6 @@ struct msi_desc; struct msi_msg; void msi_msg_read_remap_rte(struct msi_desc *msi_desc, struct msi_msg = *msg); void msi_msg_write_remap_rte(struct msi_desc *msi_desc, struct msi_msg = *msg); -struct qi_ctrl *iommu_qi_ctrl(struct iommu *iommu); -struct ir_ctrl *iommu_ir_ctrl(struct iommu *iommu); -struct iommu_flush *iommu_get_flush(struct iommu *iommu); void hvm_dpci_isairq_eoi(struct domain *d, unsigned int isairq); struct hvm_irq_dpci *domain_get_irq_dpci(const struct domain *); void free_hvm_irq_dpci(struct hvm_irq_dpci *dpci); --=__Part39080E97.1__= Content-Type: text/plain; name="VT-d-drop-bogus-checks.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="VT-d-drop-bogus-checks.patch" VT-d: drop bogus checks=0A=0AThere were a number of cases where an "iommu" = retrieved got passed to=0Aanother function before being NULL-checked. = While this by itself was=0Anot a problem as the called function did the = checks, it is confusing to=0Athe reader and redundant in several cases = (particularly with NULL-=0Achecking the return value of iommu_ir_ctrl()). = Drop the redundant=0Achecks (also ones where the sole caller of a function = did the checking=0Aalready), and at once make the three similar functions = proper inline=0Ainstead of extern ones (they were prototyped in the wrong = header file=0Aanyway, so would have needed touching sooner or later).=0A=0A= Signed-off-by: Jan Beulich =0A=0A--- a/xen/drivers/passt= hrough/vtd/intremap.c=0A+++ b/xen/drivers/passthrough/vtd/intremap.c=0A@@ = -217,13 +217,6 @@ static int remap_entry_to_ioapic_rte(=0A unsigned = long flags;=0A struct ir_ctrl *ir_ctrl =3D iommu_ir_ctrl(iommu);=0A = =0A- if ( ir_ctrl =3D=3D NULL )=0A- {=0A- dprintk(XENLOG_ERR = VTDPREFIX,=0A- "remap_entry_to_ioapic_rte: ir_ctl is not = ready\n");=0A- return -EFAULT;=0A- }=0A-=0A if ( index < 0 = || index > IREMAP_ENTRY_NR - 1 )=0A {=0A dprintk(XENLOG_ERR = VTDPREFIX,=0A@@ -358,8 +351,7 @@ unsigned int io_apic_read_remap_rte(=0A = struct iommu *iommu =3D ioapic_to_iommu(IO_APIC_ID(apic));=0A struct = ir_ctrl *ir_ctrl =3D iommu_ir_ctrl(iommu);=0A =0A- if ( !iommu || = !ir_ctrl || ir_ctrl->iremap_maddr =3D=3D 0 ||=0A- (ir_ctrl->iremap_n= um =3D=3D 0) ||=0A+ if ( !ir_ctrl || !ir_ctrl->iremap_maddr || = !ir_ctrl->iremap_num ||=0A ( (index =3D apic_pin_2_ir_idx[apic][ioa= pic_pin]) < 0 ) )=0A return __io_apic_read(apic, reg);=0A =0A@@ = -385,7 +377,7 @@ void io_apic_write_remap_rte(=0A struct ir_ctrl = *ir_ctrl =3D iommu_ir_ctrl(iommu);=0A int saved_mask;=0A =0A- if ( = !iommu || !ir_ctrl || ir_ctrl->iremap_maddr =3D=3D 0 )=0A+ if ( = !ir_ctrl || !ir_ctrl->iremap_maddr )=0A {=0A __io_apic_write(ap= ic, reg, value);=0A return;=0A@@ -475,13 +467,6 @@ static int = remap_entry_to_msi_msg(=0A unsigned long flags;=0A struct ir_ctrl = *ir_ctrl =3D iommu_ir_ctrl(iommu);=0A =0A- if ( ir_ctrl =3D=3D NULL = )=0A- {=0A- dprintk(XENLOG_ERR VTDPREFIX,=0A- = "remap_entry_to_msi_msg: ir_ctl =3D=3D NULL");=0A- return = -EFAULT;=0A- }=0A-=0A remap_rte =3D (struct msi_msg_remap_entry *) = msg;=0A index =3D (remap_rte->address_lo.index_15 << 15) |=0A = remap_rte->address_lo.index_0_14;=0A@@ -644,7 +629,7 @@ void msi_msg_re= ad_remap_rte(=0A iommu =3D drhd->iommu;=0A =0A ir_ctrl =3D = iommu_ir_ctrl(iommu);=0A- if ( !iommu || !ir_ctrl || ir_ctrl->iremap_mad= dr =3D=3D 0 )=0A+ if ( !ir_ctrl || !ir_ctrl->iremap_maddr )=0A = return;=0A =0A remap_entry_to_msi_msg(iommu, msg);=0A@@ -663,7 +648,7 = @@ void msi_msg_write_remap_rte(=0A iommu =3D drhd->iommu;=0A =0A = ir_ctrl =3D iommu_ir_ctrl(iommu);=0A- if ( !iommu || !ir_ctrl || = ir_ctrl->iremap_maddr =3D=3D 0 )=0A+ if ( !ir_ctrl || !ir_ctrl->iremap_m= addr )=0A return;=0A =0A msi_msg_to_remap_entry(iommu, pdev, = msi_desc, msg);=0A--- a/xen/drivers/passthrough/vtd/iommu.c=0A+++ = b/xen/drivers/passthrough/vtd/iommu.c=0A@@ -153,21 +153,6 @@ static void = __init free_intel_iommu(stru=0A xfree(intel);=0A }=0A =0A-struct = qi_ctrl *iommu_qi_ctrl(struct iommu *iommu)=0A-{=0A- return iommu ? = &iommu->intel->qi_ctrl : NULL;=0A-}=0A-=0A-struct ir_ctrl *iommu_ir_ctrl(st= ruct iommu *iommu)=0A-{=0A- return iommu ? &iommu->intel->ir_ctrl : = NULL;=0A-}=0A-=0A-struct iommu_flush *iommu_get_flush(struct iommu = *iommu)=0A-{=0A- return iommu ? &iommu->intel->flush : NULL;=0A-}=0A-=0A= static int iommus_incoherent;=0A static void __iommu_flush_cache(void = *addr, unsigned int size)=0A {=0A--- a/xen/drivers/passthrough/vtd/iommu.h= =0A+++ b/xen/drivers/passthrough/vtd/iommu.h=0A@@ -20,7 +20,7 @@=0A = #ifndef _INTEL_IOMMU_H_=0A #define _INTEL_IOMMU_H_=0A =0A-#include = =0A+#include =0A =0A /*=0A * Intel IOMMU = register specification per version 1.0 public spec.=0A@@ -510,6 +510,21 @@ = struct intel_iommu {=0A struct acpi_drhd_unit *drhd;=0A };=0A = =0A+static inline struct qi_ctrl *iommu_qi_ctrl(struct iommu *iommu)=0A+{= =0A+ return iommu ? &iommu->intel->qi_ctrl : NULL;=0A+}=0A+=0A+static = inline struct ir_ctrl *iommu_ir_ctrl(struct iommu *iommu)=0A+{=0A+ = return iommu ? &iommu->intel->ir_ctrl : NULL;=0A+}=0A+=0A+static inline = struct iommu_flush *iommu_get_flush(struct iommu *iommu)=0A+{=0A+ = return iommu ? &iommu->intel->flush : NULL;=0A+}=0A+=0A #define INTEL_IOMMU= _DEBUG(fmt, args...) \=0A do \=0A { \=0A--- a/xen/drivers/passth= rough/vtd/utils.c=0A+++ b/xen/drivers/passthrough/vtd/utils.c=0A@@ -267,8 = +267,7 @@ static void dump_iommu_info(unsigned cha=0A {=0A = iommu =3D ioapic_to_iommu(mp_ioapics[apic].mpc_apicid);=0A = ir_ctrl =3D iommu_ir_ctrl(iommu);=0A- if ( !iommu || !ir_ctrl = || ir_ctrl->iremap_maddr =3D=3D 0 ||=0A- ir_ctrl->iremap_num= =3D=3D 0 )=0A+ if ( !ir_ctrl || !ir_ctrl->iremap_maddr || = !ir_ctrl->iremap_num )=0A continue;=0A =0A = printk( "\nRedirection table of IOAPIC %x:\n", apic);=0A--- a/xen/include/x= en/iommu.h=0A+++ b/xen/include/xen/iommu.h=0A@@ -106,9 +106,6 @@ struct = msi_desc;=0A struct msi_msg;=0A void msi_msg_read_remap_rte(struct = msi_desc *msi_desc, struct msi_msg *msg);=0A void msi_msg_write_remap_rte(s= truct msi_desc *msi_desc, struct msi_msg *msg);=0A-struct qi_ctrl = *iommu_qi_ctrl(struct iommu *iommu);=0A-struct ir_ctrl *iommu_ir_ctrl(struc= t iommu *iommu);=0A-struct iommu_flush *iommu_get_flush(struct iommu = *iommu);=0A void hvm_dpci_isairq_eoi(struct domain *d, unsigned int = isairq);=0A struct hvm_irq_dpci *domain_get_irq_dpci(const struct domain = *);=0A void free_hvm_irq_dpci(struct hvm_irq_dpci *dpci);=0A --=__Part39080E97.1__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --=__Part39080E97.1__=-- From xen-devel-bounces@lists.xen.org Tue Oct 02 14:39:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:39:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3cu-0007MR-Of; Tue, 02 Oct 2012 14:39:12 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3cs-0007MD-DL for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:39:10 +0000 Received: from [85.158.143.35:32071] by server-1.bemta-4.messagelabs.com id 08/44-05684-C8CFA605; Tue, 02 Oct 2012 14:39:08 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1349188747!17171547!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32763 invoked from network); 2 Oct 2012 14:39:07 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-14.tower-21.messagelabs.com with SMTP; 2 Oct 2012 14:39:07 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 02 Oct 2012 15:39:07 +0100 Message-Id: <506B18A7020000780009F1E4@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Tue, 02 Oct 2012 15:39:03 +0100 From: "Jan Beulich" To: "xen-devel" Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part39080E97.1__=" Cc: xiantao.zhang@intel.com Subject: [Xen-devel] [PATCH] VT-d: drop bogus checks X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part39080E97.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline There were a number of cases where an "iommu" retrieved got passed to another function before being NULL-checked. While this by itself was not a problem as the called function did the checks, it is confusing to the reader and redundant in several cases (particularly with NULL- checking the return value of iommu_ir_ctrl()). Drop the redundant checks (also ones where the sole caller of a function did the checking already), and at once make the three similar functions proper inline instead of extern ones (they were prototyped in the wrong header file anyway, so would have needed touching sooner or later). Signed-off-by: Jan Beulich --- a/xen/drivers/passthrough/vtd/intremap.c +++ b/xen/drivers/passthrough/vtd/intremap.c @@ -217,13 +217,6 @@ static int remap_entry_to_ioapic_rte( unsigned long flags; struct ir_ctrl *ir_ctrl =3D iommu_ir_ctrl(iommu); =20 - if ( ir_ctrl =3D=3D NULL ) - { - dprintk(XENLOG_ERR VTDPREFIX, - "remap_entry_to_ioapic_rte: ir_ctl is not ready\n"); - return -EFAULT; - } - if ( index < 0 || index > IREMAP_ENTRY_NR - 1 ) { dprintk(XENLOG_ERR VTDPREFIX, @@ -358,8 +351,7 @@ unsigned int io_apic_read_remap_rte( struct iommu *iommu =3D ioapic_to_iommu(IO_APIC_ID(apic)); struct ir_ctrl *ir_ctrl =3D iommu_ir_ctrl(iommu); =20 - if ( !iommu || !ir_ctrl || ir_ctrl->iremap_maddr =3D=3D 0 || - (ir_ctrl->iremap_num =3D=3D 0) || + if ( !ir_ctrl || !ir_ctrl->iremap_maddr || !ir_ctrl->iremap_num || ( (index =3D apic_pin_2_ir_idx[apic][ioapic_pin]) < 0 ) ) return __io_apic_read(apic, reg); =20 @@ -385,7 +377,7 @@ void io_apic_write_remap_rte( struct ir_ctrl *ir_ctrl =3D iommu_ir_ctrl(iommu); int saved_mask; =20 - if ( !iommu || !ir_ctrl || ir_ctrl->iremap_maddr =3D=3D 0 ) + if ( !ir_ctrl || !ir_ctrl->iremap_maddr ) { __io_apic_write(apic, reg, value); return; @@ -475,13 +467,6 @@ static int remap_entry_to_msi_msg( unsigned long flags; struct ir_ctrl *ir_ctrl =3D iommu_ir_ctrl(iommu); =20 - if ( ir_ctrl =3D=3D NULL ) - { - dprintk(XENLOG_ERR VTDPREFIX, - "remap_entry_to_msi_msg: ir_ctl =3D=3D NULL"); - return -EFAULT; - } - remap_rte =3D (struct msi_msg_remap_entry *) msg; index =3D (remap_rte->address_lo.index_15 << 15) | remap_rte->address_lo.index_0_14; @@ -644,7 +629,7 @@ void msi_msg_read_remap_rte( iommu =3D drhd->iommu; =20 ir_ctrl =3D iommu_ir_ctrl(iommu); - if ( !iommu || !ir_ctrl || ir_ctrl->iremap_maddr =3D=3D 0 ) + if ( !ir_ctrl || !ir_ctrl->iremap_maddr ) return; =20 remap_entry_to_msi_msg(iommu, msg); @@ -663,7 +648,7 @@ void msi_msg_write_remap_rte( iommu =3D drhd->iommu; =20 ir_ctrl =3D iommu_ir_ctrl(iommu); - if ( !iommu || !ir_ctrl || ir_ctrl->iremap_maddr =3D=3D 0 ) + if ( !ir_ctrl || !ir_ctrl->iremap_maddr ) return; =20 msi_msg_to_remap_entry(iommu, pdev, msi_desc, msg); --- a/xen/drivers/passthrough/vtd/iommu.c +++ b/xen/drivers/passthrough/vtd/iommu.c @@ -153,21 +153,6 @@ static void __init free_intel_iommu(stru xfree(intel); } =20 -struct qi_ctrl *iommu_qi_ctrl(struct iommu *iommu) -{ - return iommu ? &iommu->intel->qi_ctrl : NULL; -} - -struct ir_ctrl *iommu_ir_ctrl(struct iommu *iommu) -{ - return iommu ? &iommu->intel->ir_ctrl : NULL; -} - -struct iommu_flush *iommu_get_flush(struct iommu *iommu) -{ - return iommu ? &iommu->intel->flush : NULL; -} - static int iommus_incoherent; static void __iommu_flush_cache(void *addr, unsigned int size) { --- a/xen/drivers/passthrough/vtd/iommu.h +++ b/xen/drivers/passthrough/vtd/iommu.h @@ -20,7 +20,7 @@ #ifndef _INTEL_IOMMU_H_ #define _INTEL_IOMMU_H_ =20 -#include +#include =20 /* * Intel IOMMU register specification per version 1.0 public spec. @@ -510,6 +510,21 @@ struct intel_iommu { struct acpi_drhd_unit *drhd; }; =20 +static inline struct qi_ctrl *iommu_qi_ctrl(struct iommu *iommu) +{ + return iommu ? &iommu->intel->qi_ctrl : NULL; +} + +static inline struct ir_ctrl *iommu_ir_ctrl(struct iommu *iommu) +{ + return iommu ? &iommu->intel->ir_ctrl : NULL; +} + +static inline struct iommu_flush *iommu_get_flush(struct iommu *iommu) +{ + return iommu ? &iommu->intel->flush : NULL; +} + #define INTEL_IOMMU_DEBUG(fmt, args...) \ do \ { \ --- a/xen/drivers/passthrough/vtd/utils.c +++ b/xen/drivers/passthrough/vtd/utils.c @@ -267,8 +267,7 @@ static void dump_iommu_info(unsigned cha { iommu =3D ioapic_to_iommu(mp_ioapics[apic].mpc_apicid); ir_ctrl =3D iommu_ir_ctrl(iommu); - if ( !iommu || !ir_ctrl || ir_ctrl->iremap_maddr =3D=3D 0 || - ir_ctrl->iremap_num =3D=3D 0 ) + if ( !ir_ctrl || !ir_ctrl->iremap_maddr || !ir_ctrl->iremap_nu= m ) continue; =20 printk( "\nRedirection table of IOAPIC %x:\n", apic); --- a/xen/include/xen/iommu.h +++ b/xen/include/xen/iommu.h @@ -106,9 +106,6 @@ struct msi_desc; struct msi_msg; void msi_msg_read_remap_rte(struct msi_desc *msi_desc, struct msi_msg = *msg); void msi_msg_write_remap_rte(struct msi_desc *msi_desc, struct msi_msg = *msg); -struct qi_ctrl *iommu_qi_ctrl(struct iommu *iommu); -struct ir_ctrl *iommu_ir_ctrl(struct iommu *iommu); -struct iommu_flush *iommu_get_flush(struct iommu *iommu); void hvm_dpci_isairq_eoi(struct domain *d, unsigned int isairq); struct hvm_irq_dpci *domain_get_irq_dpci(const struct domain *); void free_hvm_irq_dpci(struct hvm_irq_dpci *dpci); --=__Part39080E97.1__= Content-Type: text/plain; name="VT-d-drop-bogus-checks.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="VT-d-drop-bogus-checks.patch" VT-d: drop bogus checks=0A=0AThere were a number of cases where an "iommu" = retrieved got passed to=0Aanother function before being NULL-checked. = While this by itself was=0Anot a problem as the called function did the = checks, it is confusing to=0Athe reader and redundant in several cases = (particularly with NULL-=0Achecking the return value of iommu_ir_ctrl()). = Drop the redundant=0Achecks (also ones where the sole caller of a function = did the checking=0Aalready), and at once make the three similar functions = proper inline=0Ainstead of extern ones (they were prototyped in the wrong = header file=0Aanyway, so would have needed touching sooner or later).=0A=0A= Signed-off-by: Jan Beulich =0A=0A--- a/xen/drivers/passt= hrough/vtd/intremap.c=0A+++ b/xen/drivers/passthrough/vtd/intremap.c=0A@@ = -217,13 +217,6 @@ static int remap_entry_to_ioapic_rte(=0A unsigned = long flags;=0A struct ir_ctrl *ir_ctrl =3D iommu_ir_ctrl(iommu);=0A = =0A- if ( ir_ctrl =3D=3D NULL )=0A- {=0A- dprintk(XENLOG_ERR = VTDPREFIX,=0A- "remap_entry_to_ioapic_rte: ir_ctl is not = ready\n");=0A- return -EFAULT;=0A- }=0A-=0A if ( index < 0 = || index > IREMAP_ENTRY_NR - 1 )=0A {=0A dprintk(XENLOG_ERR = VTDPREFIX,=0A@@ -358,8 +351,7 @@ unsigned int io_apic_read_remap_rte(=0A = struct iommu *iommu =3D ioapic_to_iommu(IO_APIC_ID(apic));=0A struct = ir_ctrl *ir_ctrl =3D iommu_ir_ctrl(iommu);=0A =0A- if ( !iommu || = !ir_ctrl || ir_ctrl->iremap_maddr =3D=3D 0 ||=0A- (ir_ctrl->iremap_n= um =3D=3D 0) ||=0A+ if ( !ir_ctrl || !ir_ctrl->iremap_maddr || = !ir_ctrl->iremap_num ||=0A ( (index =3D apic_pin_2_ir_idx[apic][ioa= pic_pin]) < 0 ) )=0A return __io_apic_read(apic, reg);=0A =0A@@ = -385,7 +377,7 @@ void io_apic_write_remap_rte(=0A struct ir_ctrl = *ir_ctrl =3D iommu_ir_ctrl(iommu);=0A int saved_mask;=0A =0A- if ( = !iommu || !ir_ctrl || ir_ctrl->iremap_maddr =3D=3D 0 )=0A+ if ( = !ir_ctrl || !ir_ctrl->iremap_maddr )=0A {=0A __io_apic_write(ap= ic, reg, value);=0A return;=0A@@ -475,13 +467,6 @@ static int = remap_entry_to_msi_msg(=0A unsigned long flags;=0A struct ir_ctrl = *ir_ctrl =3D iommu_ir_ctrl(iommu);=0A =0A- if ( ir_ctrl =3D=3D NULL = )=0A- {=0A- dprintk(XENLOG_ERR VTDPREFIX,=0A- = "remap_entry_to_msi_msg: ir_ctl =3D=3D NULL");=0A- return = -EFAULT;=0A- }=0A-=0A remap_rte =3D (struct msi_msg_remap_entry *) = msg;=0A index =3D (remap_rte->address_lo.index_15 << 15) |=0A = remap_rte->address_lo.index_0_14;=0A@@ -644,7 +629,7 @@ void msi_msg_re= ad_remap_rte(=0A iommu =3D drhd->iommu;=0A =0A ir_ctrl =3D = iommu_ir_ctrl(iommu);=0A- if ( !iommu || !ir_ctrl || ir_ctrl->iremap_mad= dr =3D=3D 0 )=0A+ if ( !ir_ctrl || !ir_ctrl->iremap_maddr )=0A = return;=0A =0A remap_entry_to_msi_msg(iommu, msg);=0A@@ -663,7 +648,7 = @@ void msi_msg_write_remap_rte(=0A iommu =3D drhd->iommu;=0A =0A = ir_ctrl =3D iommu_ir_ctrl(iommu);=0A- if ( !iommu || !ir_ctrl || = ir_ctrl->iremap_maddr =3D=3D 0 )=0A+ if ( !ir_ctrl || !ir_ctrl->iremap_m= addr )=0A return;=0A =0A msi_msg_to_remap_entry(iommu, pdev, = msi_desc, msg);=0A--- a/xen/drivers/passthrough/vtd/iommu.c=0A+++ = b/xen/drivers/passthrough/vtd/iommu.c=0A@@ -153,21 +153,6 @@ static void = __init free_intel_iommu(stru=0A xfree(intel);=0A }=0A =0A-struct = qi_ctrl *iommu_qi_ctrl(struct iommu *iommu)=0A-{=0A- return iommu ? = &iommu->intel->qi_ctrl : NULL;=0A-}=0A-=0A-struct ir_ctrl *iommu_ir_ctrl(st= ruct iommu *iommu)=0A-{=0A- return iommu ? &iommu->intel->ir_ctrl : = NULL;=0A-}=0A-=0A-struct iommu_flush *iommu_get_flush(struct iommu = *iommu)=0A-{=0A- return iommu ? &iommu->intel->flush : NULL;=0A-}=0A-=0A= static int iommus_incoherent;=0A static void __iommu_flush_cache(void = *addr, unsigned int size)=0A {=0A--- a/xen/drivers/passthrough/vtd/iommu.h= =0A+++ b/xen/drivers/passthrough/vtd/iommu.h=0A@@ -20,7 +20,7 @@=0A = #ifndef _INTEL_IOMMU_H_=0A #define _INTEL_IOMMU_H_=0A =0A-#include = =0A+#include =0A =0A /*=0A * Intel IOMMU = register specification per version 1.0 public spec.=0A@@ -510,6 +510,21 @@ = struct intel_iommu {=0A struct acpi_drhd_unit *drhd;=0A };=0A = =0A+static inline struct qi_ctrl *iommu_qi_ctrl(struct iommu *iommu)=0A+{= =0A+ return iommu ? &iommu->intel->qi_ctrl : NULL;=0A+}=0A+=0A+static = inline struct ir_ctrl *iommu_ir_ctrl(struct iommu *iommu)=0A+{=0A+ = return iommu ? &iommu->intel->ir_ctrl : NULL;=0A+}=0A+=0A+static inline = struct iommu_flush *iommu_get_flush(struct iommu *iommu)=0A+{=0A+ = return iommu ? &iommu->intel->flush : NULL;=0A+}=0A+=0A #define INTEL_IOMMU= _DEBUG(fmt, args...) \=0A do \=0A { \=0A--- a/xen/drivers/passth= rough/vtd/utils.c=0A+++ b/xen/drivers/passthrough/vtd/utils.c=0A@@ -267,8 = +267,7 @@ static void dump_iommu_info(unsigned cha=0A {=0A = iommu =3D ioapic_to_iommu(mp_ioapics[apic].mpc_apicid);=0A = ir_ctrl =3D iommu_ir_ctrl(iommu);=0A- if ( !iommu || !ir_ctrl = || ir_ctrl->iremap_maddr =3D=3D 0 ||=0A- ir_ctrl->iremap_num= =3D=3D 0 )=0A+ if ( !ir_ctrl || !ir_ctrl->iremap_maddr || = !ir_ctrl->iremap_num )=0A continue;=0A =0A = printk( "\nRedirection table of IOAPIC %x:\n", apic);=0A--- a/xen/include/x= en/iommu.h=0A+++ b/xen/include/xen/iommu.h=0A@@ -106,9 +106,6 @@ struct = msi_desc;=0A struct msi_msg;=0A void msi_msg_read_remap_rte(struct = msi_desc *msi_desc, struct msi_msg *msg);=0A void msi_msg_write_remap_rte(s= truct msi_desc *msi_desc, struct msi_msg *msg);=0A-struct qi_ctrl = *iommu_qi_ctrl(struct iommu *iommu);=0A-struct ir_ctrl *iommu_ir_ctrl(struc= t iommu *iommu);=0A-struct iommu_flush *iommu_get_flush(struct iommu = *iommu);=0A void hvm_dpci_isairq_eoi(struct domain *d, unsigned int = isairq);=0A struct hvm_irq_dpci *domain_get_irq_dpci(const struct domain = *);=0A void free_hvm_irq_dpci(struct hvm_irq_dpci *dpci);=0A --=__Part39080E97.1__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --=__Part39080E97.1__=-- From xen-devel-bounces@lists.xen.org Tue Oct 02 14:41:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:41:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3fH-0007Zq-UY; Tue, 02 Oct 2012 14:41:39 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3fG-0007ZZ-Bh for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:41:38 +0000 Received: from [85.158.139.83:6979] by server-11.bemta-5.messagelabs.com id AF/0B-13866-12DFA605; Tue, 02 Oct 2012 14:41:37 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-7.tower-182.messagelabs.com!1349188896!29121712!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MjMzMTI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14646 invoked from network); 2 Oct 2012 14:41:36 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 14:41:36 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id 755321623; Tue, 2 Oct 2012 17:41:35 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 21E3F20058; Tue, 2 Oct 2012 17:41:35 +0300 (EEST) Date: Tue, 2 Oct 2012 17:41:35 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Ian Jackson Message-ID: <20121002144134.GO8912@reaktio.net> References: <20121001164239.GE8912@reaktio.net> <20586.63875.490107.170343@mariner.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20586.63875.490107.170343@mariner.uk.xensource.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: George Dunlap , xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.3 development update X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, Oct 02, 2012 at 03:26:11PM +0100, Ian Jackson wrote: > Pasi K=E4rkk=E4inen writes ("Re: [Xen-devel] Xen 4.3 development update"): > > * xl PVUSB pass-through for both PV and HVM guests > > owner: ? = > > status: ? = > > - xm/xend supports PVUSB pass-through to guests with PVUSB drivers (= both PV and HVM guests). > > - port the xm/xend functionality to xl. > > - this PVUSB feature does not require support or emulation from Qemu. > > - upstream the Linux frontend/backend drivers. Current work-in-progr= ess versions are in Konrad's git tree. > > - James Harper's GPLPV drivers for Windows include PVUSB frontend dr= ivers. > = > Right. I think upstreaming the frontend/backend is critical for > this. > Indeed! > Is this related to the usb-over-ip support that I found a few > years ago in linux-staging ? At the time that was very buggy. > I don't think so. PVUSB is a separate protocol/feature afaik. Xen PVUSB was originally developed by Fujitsu: http://www.xen.org/files/xensummit_oracle09/PVUSB.pdf http://www.xen.org/files/xensummit_intel09/PVUSBStatusUpdate.pdf more info: http://wiki.xen.org/wiki/Xen_USB_Passthrough = > > * xl USB pass-through for HVM guests using Qemu USB emulation > > owner: ? = > > status: ? > > - xm/xend with qemu-traditional supports USB passthrough to HVM gues= ts using the Qemu emulated USB controller. > > - port the xm/xend functionality to xl. > > - make sure USB passthrough with xl works with both qemu-traditional= and qemu-upstream. > > - The HVM guest does not need any special drivers for this feature. > = > I think this is just a matter of plumbing in libxl (presumably, now, > plumbing to qemu-upstream). > Yep, this one should be pretty easy! -- Pasi = _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 14:41:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:41:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3fH-0007Zq-UY; Tue, 02 Oct 2012 14:41:39 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3fG-0007ZZ-Bh for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:41:38 +0000 Received: from [85.158.139.83:6979] by server-11.bemta-5.messagelabs.com id AF/0B-13866-12DFA605; Tue, 02 Oct 2012 14:41:37 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-7.tower-182.messagelabs.com!1349188896!29121712!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MjMzMTI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14646 invoked from network); 2 Oct 2012 14:41:36 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 14:41:36 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id 755321623; Tue, 2 Oct 2012 17:41:35 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 21E3F20058; Tue, 2 Oct 2012 17:41:35 +0300 (EEST) Date: Tue, 2 Oct 2012 17:41:35 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Ian Jackson Message-ID: <20121002144134.GO8912@reaktio.net> References: <20121001164239.GE8912@reaktio.net> <20586.63875.490107.170343@mariner.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20586.63875.490107.170343@mariner.uk.xensource.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: George Dunlap , xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.3 development update X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, Oct 02, 2012 at 03:26:11PM +0100, Ian Jackson wrote: > Pasi K=E4rkk=E4inen writes ("Re: [Xen-devel] Xen 4.3 development update"): > > * xl PVUSB pass-through for both PV and HVM guests > > owner: ? = > > status: ? = > > - xm/xend supports PVUSB pass-through to guests with PVUSB drivers (= both PV and HVM guests). > > - port the xm/xend functionality to xl. > > - this PVUSB feature does not require support or emulation from Qemu. > > - upstream the Linux frontend/backend drivers. Current work-in-progr= ess versions are in Konrad's git tree. > > - James Harper's GPLPV drivers for Windows include PVUSB frontend dr= ivers. > = > Right. I think upstreaming the frontend/backend is critical for > this. > Indeed! > Is this related to the usb-over-ip support that I found a few > years ago in linux-staging ? At the time that was very buggy. > I don't think so. PVUSB is a separate protocol/feature afaik. Xen PVUSB was originally developed by Fujitsu: http://www.xen.org/files/xensummit_oracle09/PVUSB.pdf http://www.xen.org/files/xensummit_intel09/PVUSBStatusUpdate.pdf more info: http://wiki.xen.org/wiki/Xen_USB_Passthrough = > > * xl USB pass-through for HVM guests using Qemu USB emulation > > owner: ? = > > status: ? > > - xm/xend with qemu-traditional supports USB passthrough to HVM gues= ts using the Qemu emulated USB controller. > > - port the xm/xend functionality to xl. > > - make sure USB passthrough with xl works with both qemu-traditional= and qemu-upstream. > > - The HVM guest does not need any special drivers for this feature. > = > I think this is just a matter of plumbing in libxl (presumably, now, > plumbing to qemu-upstream). > Yep, this one should be pretty easy! -- Pasi = _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 14:43:03 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:43:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3gW-0007l8-EN; Tue, 02 Oct 2012 14:42:56 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3gU-0007kp-GW for Xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:42:54 +0000 Received: from [85.158.137.99:35189] by server-4.bemta-3.messagelabs.com id 80/39-14155-D6DFA605; Tue, 02 Oct 2012 14:42:53 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-12.tower-217.messagelabs.com!1349188971!16857072!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MjMzMTI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19776 invoked from network); 2 Oct 2012 14:42:52 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-12.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 14:42:52 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id 2C606164D; Tue, 2 Oct 2012 17:42:51 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 16DE920058; Tue, 2 Oct 2012 17:42:51 +0300 (EEST) Date: Tue, 2 Oct 2012 17:42:51 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Valtteri Kiviniemi Message-ID: <20121002144251.GP8912@reaktio.net> References: <20121001164757.GF8912@reaktio.net> <20121001182437.GG8912@reaktio.net> <20121002121932.GL8912@reaktio.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Konrad Rzeszutek Wilk , Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.0.4, kernel 3.5.0 HVM crash and kernel BUG X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, Oct 02, 2012 at 05:37:08PM +0300, Valtteri Kiviniemi wrote: > Hi, > > Tried boogin with vif-parameters commented out, result is the same: > > Error: Device 768 (vbd) could not be connected. Hotplug scripts not > working. > > But what is more troubling with these issues I'm having is the fact that > this "hotpluf scripts not working" came out of nowhere. I was able to boot > my Windows domU just fine earlier with only problem being that the VNC > output was just black screen after Windows installer had started. Then I > tried to create a Linux HVM (debian squeeze) and then I got that "Hotplug > scripts not working" error. And after trying to start Windows domU again > it says that same "Hotplug scripts not working" error. > > If I reboot the machine and start my Windows domU it will start again just > fine, but the VNC output is just black screen. Then again, if I start the > Linux HVM domU I will again get that "Hotplug scripts not working" error > and then the Windows domU wont start either again and tells the same > "Hotplug scripts not working" error. > > So this is pretty confusing and troubling indeed. > > I will reboot the machine later and put those boot parameters that Pasi > mentioned. > My parameters were meant for the case where your server crashes, to be able to get a proper boot and crash logs to analyze it. -- Pasi > - Valtteri > > 2012/10/2 Konrad Rzeszutek Wilk <[1]konrad@kernel.org> > > On Tue, Oct 2, 2012 at 9:01 AM, Valtteri Kiviniemi > <[2]kiviniemi.valtteri@gmail.com> wrote: > > Hi, > > > > I already tried 3.2, 3.5, 3.5.0, 3.6.0-rc7 and 3.6.0, same problem all > of > > those. My dom0 config is the same config that I'am using on other > server > > where HVM is working, so I dont think that it is a config problem. I > have > > triple checked everything and all should be ok. dom0 dmesg shows the > same > > crash that I have previously posted here. /var/log/xen/ does not > contain any > > specific errors. > > > > Could this be some kind of broblem with my motherboard bios being > buggy or > > CPU not supported? I'm using the new intel Ivy Bridge processor which > has > > integrated GPU, but that should not probably cause these kind of > problems. > > Or maybe some ACPI problem? xm dmesg is showing some notices about > ACPI. Is > > there any ACPI kernel parameters that I should try booting? This has > to be > > somekind of problem with my hardware, or then maybe it could be a > kernel > > problem too. I just really cant figure this out myself, I have tried > > everything. > > > > Lets take a quick summary of what has been tested, what hardware I'm > using > > etc. > > > > Xen-versions tested: 4.2.0, 4.0.4 > > Kernel-versions tested: 3.2.0, 3.5.0, 3.5.4, 3.6.0-rc7, 3.6.0 > > > > Host OS: Debian testing/wheezy, udev version 175-7, 2.13-35, python > version > > 2.7.3~rc2-2.1 > > > > Hardware: > > > > CPU: Intel Core i7-3770 3.4GHz > > MB: Intel DQ77MK (latest bios updated) > > Memory: 32GB (4 x 8GB DDR3-1600MHz) > > > > All relevant log files and configs: > > > > dom0 dmesg: [3]http://nago.fi/dmesg.txt > > qemu-dm log: [4]http://nago.fi/qemu-dm.txt > > xm dmesg log: [5]http://nago.fi/xm-dmesg.txt > > domU config: [6]http://nago.fi/domu-config.txt > > dom0 kernel config: [7]http://nago.fi/dom0-config.txt > > > > I have also tried playing with every setting on that domU that I can > think > > of and tried different configs etc. > > This is troubling. You seem to trigger the QEMU closing the tunX (your > Windows's guest network interface) which then crashes somehow. > Just to make sure that this is the case - can you try launching your > guest without network and seeing what happens? > > References > > Visible links > 1. mailto:konrad@kernel.org > 2. mailto:kiviniemi.valtteri@gmail.com > 3. http://nago.fi/dmesg.txt > 4. http://nago.fi/qemu-dm.txt > 5. http://nago.fi/xm-dmesg.txt > 6. http://nago.fi/domu-config.txt > 7. http://nago.fi/dom0-config.txt _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 14:43:03 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:43:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3gW-0007l8-EN; Tue, 02 Oct 2012 14:42:56 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3gU-0007kp-GW for Xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:42:54 +0000 Received: from [85.158.137.99:35189] by server-4.bemta-3.messagelabs.com id 80/39-14155-D6DFA605; Tue, 02 Oct 2012 14:42:53 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-12.tower-217.messagelabs.com!1349188971!16857072!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MjMzMTI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19776 invoked from network); 2 Oct 2012 14:42:52 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-12.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 14:42:52 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id 2C606164D; Tue, 2 Oct 2012 17:42:51 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 16DE920058; Tue, 2 Oct 2012 17:42:51 +0300 (EEST) Date: Tue, 2 Oct 2012 17:42:51 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Valtteri Kiviniemi Message-ID: <20121002144251.GP8912@reaktio.net> References: <20121001164757.GF8912@reaktio.net> <20121001182437.GG8912@reaktio.net> <20121002121932.GL8912@reaktio.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Konrad Rzeszutek Wilk , Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.0.4, kernel 3.5.0 HVM crash and kernel BUG X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, Oct 02, 2012 at 05:37:08PM +0300, Valtteri Kiviniemi wrote: > Hi, > > Tried boogin with vif-parameters commented out, result is the same: > > Error: Device 768 (vbd) could not be connected. Hotplug scripts not > working. > > But what is more troubling with these issues I'm having is the fact that > this "hotpluf scripts not working" came out of nowhere. I was able to boot > my Windows domU just fine earlier with only problem being that the VNC > output was just black screen after Windows installer had started. Then I > tried to create a Linux HVM (debian squeeze) and then I got that "Hotplug > scripts not working" error. And after trying to start Windows domU again > it says that same "Hotplug scripts not working" error. > > If I reboot the machine and start my Windows domU it will start again just > fine, but the VNC output is just black screen. Then again, if I start the > Linux HVM domU I will again get that "Hotplug scripts not working" error > and then the Windows domU wont start either again and tells the same > "Hotplug scripts not working" error. > > So this is pretty confusing and troubling indeed. > > I will reboot the machine later and put those boot parameters that Pasi > mentioned. > My parameters were meant for the case where your server crashes, to be able to get a proper boot and crash logs to analyze it. -- Pasi > - Valtteri > > 2012/10/2 Konrad Rzeszutek Wilk <[1]konrad@kernel.org> > > On Tue, Oct 2, 2012 at 9:01 AM, Valtteri Kiviniemi > <[2]kiviniemi.valtteri@gmail.com> wrote: > > Hi, > > > > I already tried 3.2, 3.5, 3.5.0, 3.6.0-rc7 and 3.6.0, same problem all > of > > those. My dom0 config is the same config that I'am using on other > server > > where HVM is working, so I dont think that it is a config problem. I > have > > triple checked everything and all should be ok. dom0 dmesg shows the > same > > crash that I have previously posted here. /var/log/xen/ does not > contain any > > specific errors. > > > > Could this be some kind of broblem with my motherboard bios being > buggy or > > CPU not supported? I'm using the new intel Ivy Bridge processor which > has > > integrated GPU, but that should not probably cause these kind of > problems. > > Or maybe some ACPI problem? xm dmesg is showing some notices about > ACPI. Is > > there any ACPI kernel parameters that I should try booting? This has > to be > > somekind of problem with my hardware, or then maybe it could be a > kernel > > problem too. I just really cant figure this out myself, I have tried > > everything. > > > > Lets take a quick summary of what has been tested, what hardware I'm > using > > etc. > > > > Xen-versions tested: 4.2.0, 4.0.4 > > Kernel-versions tested: 3.2.0, 3.5.0, 3.5.4, 3.6.0-rc7, 3.6.0 > > > > Host OS: Debian testing/wheezy, udev version 175-7, 2.13-35, python > version > > 2.7.3~rc2-2.1 > > > > Hardware: > > > > CPU: Intel Core i7-3770 3.4GHz > > MB: Intel DQ77MK (latest bios updated) > > Memory: 32GB (4 x 8GB DDR3-1600MHz) > > > > All relevant log files and configs: > > > > dom0 dmesg: [3]http://nago.fi/dmesg.txt > > qemu-dm log: [4]http://nago.fi/qemu-dm.txt > > xm dmesg log: [5]http://nago.fi/xm-dmesg.txt > > domU config: [6]http://nago.fi/domu-config.txt > > dom0 kernel config: [7]http://nago.fi/dom0-config.txt > > > > I have also tried playing with every setting on that domU that I can > think > > of and tried different configs etc. > > This is troubling. You seem to trigger the QEMU closing the tunX (your > Windows's guest network interface) which then crashes somehow. > Just to make sure that this is the case - can you try launching your > guest without network and seeing what happens? > > References > > Visible links > 1. mailto:konrad@kernel.org > 2. mailto:kiviniemi.valtteri@gmail.com > 3. http://nago.fi/dmesg.txt > 4. http://nago.fi/qemu-dm.txt > 5. http://nago.fi/xm-dmesg.txt > 6. http://nago.fi/domu-config.txt > 7. http://nago.fi/dom0-config.txt _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 14:44:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:44:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3hM-0007sD-TV; Tue, 02 Oct 2012 14:43:48 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3hL-0007rt-F8 for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:43:47 +0000 Received: from [85.158.138.51:2466] by server-4.bemta-3.messagelabs.com id E1/BA-14155-2ADFA605; Tue, 02 Oct 2012 14:43:46 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-12.tower-174.messagelabs.com!1349189024!24886762!1 X-Originating-IP: [128.244.251.37] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3546 invoked from network); 2 Oct 2012 14:43:45 -0000 Received: from piper.jhuapl.edu (HELO jhuapl.edu) (128.244.251.37) by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 14:43:45 -0000 Received: from ([128.244.207.97]) by piper.jhuapl.edu with ESMTP with TLS id 5Y8HCH1.145946360; Tue, 02 Oct 2012 10:43:18 -0400 From: Matthew Fioravante To: xen-devel@lists.xen.org, samuel.thibault@ens-lyon.org, Ian.Campbell@citrix.com Date: Tue, 2 Oct 2012 10:43:24 -0400 Message-Id: <1349189004-17133-1-git-send-email-matthew.fioravante@jhuapl.edu> X-Mailer: git-send-email 1.7.4.4 Cc: Matthew Fioravante Subject: [Xen-devel] [PATCH 04/12] Disable the mfn_is_ram() check, it doesn't work correctly on all systems X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch disables the mfn_is_ram check in mini-os. The current check is insufficient and fails on some systems with larger than 4gb memory. Signed-off-by: Matthew Fioravante --- Changes since last * remove the function and checking mechanism entirely * removed Acked by: as this is a significant change from the last patch. Someone should probably Ack it again. diff --git a/extras/mini-os/arch/x86/ioremap.c b/extras/mini-os/arch/x86/ioremap.c index c7f8186..4384b1c 100644 --- a/extras/mini-os/arch/x86/ioremap.c +++ b/extras/mini-os/arch/x86/ioremap.c @@ -35,7 +35,6 @@ static void *__do_ioremap(unsigned long phys_addr, unsigned long size, unsigned long va; unsigned long mfns, mfn; unsigned long num_pages, offset; - int i; /* allow non page aligned addresses but for mapping we need to align them */ offset = (phys_addr & ~PAGE_MASK); @@ -43,21 +42,9 @@ static void *__do_ioremap(unsigned long phys_addr, unsigned long size, phys_addr &= PAGE_MASK; mfns = mfn = phys_addr >> PAGE_SHIFT; - /* sanity checks on list of MFNs */ - for ( i = 0; i < num_pages; i++, mfn++ ) - { - if ( mfn_is_ram(mfn) ) - { - printk("ioremap: mfn 0x%ulx is RAM\n", mfn); - goto mfn_invalid; - } - } va = (unsigned long)map_frames_ex(&mfns, num_pages, 0, 1, 1, DOMID_IO, NULL, prot); return (void *)(va + offset); - -mfn_invalid: - return NULL; } void *ioremap(unsigned long phys_addr, unsigned long size) diff --git a/extras/mini-os/arch/x86/mm.c b/extras/mini-os/arch/x86/mm.c index 80aceac..35df15b 100644 --- a/extras/mini-os/arch/x86/mm.c +++ b/extras/mini-os/arch/x86/mm.c @@ -845,18 +845,6 @@ unsigned long alloc_contig_pages(int order, unsigned int addr_bits) } /* - * Check if a given MFN refers to real memory - */ -static long system_ram_end_mfn; -int mfn_is_ram(unsigned long mfn) -{ - /* very crude check if a given MFN is memory or not. Probably should - * make this a little more sophisticated ;) */ - return (mfn <= system_ram_end_mfn) ? 1 : 0; -} - - -/* * Clear some of the bootstrap memory */ static void clear_bootstrap(void) @@ -951,10 +939,6 @@ void arch_init_mm(unsigned long* start_pfn_p, unsigned long* max_pfn_p) clear_bootstrap(); set_readonly(&_text, &_erodata); - /* get the number of physical pages the system has. Used to check for - * system memory. */ - system_ram_end_mfn = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL); - *start_pfn_p = start_pfn; *max_pfn_p = max_pfn; } diff --git a/extras/mini-os/include/x86/arch_mm.h b/extras/mini-os/include/x86/arch_mm.h index a95632a..23cfca7 100644 --- a/extras/mini-os/include/x86/arch_mm.h +++ b/extras/mini-os/include/x86/arch_mm.h @@ -229,6 +229,5 @@ static __inline__ paddr_t machine_to_phys(maddr_t machine) #define do_map_zero(start, n) do_map_frames(start, &mfn_zero, n, 0, 0, DOMID_SELF, NULL, L1_PROT_RO) pgentry_t *need_pgt(unsigned long addr); -int mfn_is_ram(unsigned long mfn); #endif /* _ARCH_MM_H_ */ -- 1.7.4.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 14:44:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:44:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3hM-0007sD-TV; Tue, 02 Oct 2012 14:43:48 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3hL-0007rt-F8 for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:43:47 +0000 Received: from [85.158.138.51:2466] by server-4.bemta-3.messagelabs.com id E1/BA-14155-2ADFA605; Tue, 02 Oct 2012 14:43:46 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-12.tower-174.messagelabs.com!1349189024!24886762!1 X-Originating-IP: [128.244.251.37] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3546 invoked from network); 2 Oct 2012 14:43:45 -0000 Received: from piper.jhuapl.edu (HELO jhuapl.edu) (128.244.251.37) by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 14:43:45 -0000 Received: from ([128.244.207.97]) by piper.jhuapl.edu with ESMTP with TLS id 5Y8HCH1.145946360; Tue, 02 Oct 2012 10:43:18 -0400 From: Matthew Fioravante To: xen-devel@lists.xen.org, samuel.thibault@ens-lyon.org, Ian.Campbell@citrix.com Date: Tue, 2 Oct 2012 10:43:24 -0400 Message-Id: <1349189004-17133-1-git-send-email-matthew.fioravante@jhuapl.edu> X-Mailer: git-send-email 1.7.4.4 Cc: Matthew Fioravante Subject: [Xen-devel] [PATCH 04/12] Disable the mfn_is_ram() check, it doesn't work correctly on all systems X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch disables the mfn_is_ram check in mini-os. The current check is insufficient and fails on some systems with larger than 4gb memory. Signed-off-by: Matthew Fioravante --- Changes since last * remove the function and checking mechanism entirely * removed Acked by: as this is a significant change from the last patch. Someone should probably Ack it again. diff --git a/extras/mini-os/arch/x86/ioremap.c b/extras/mini-os/arch/x86/ioremap.c index c7f8186..4384b1c 100644 --- a/extras/mini-os/arch/x86/ioremap.c +++ b/extras/mini-os/arch/x86/ioremap.c @@ -35,7 +35,6 @@ static void *__do_ioremap(unsigned long phys_addr, unsigned long size, unsigned long va; unsigned long mfns, mfn; unsigned long num_pages, offset; - int i; /* allow non page aligned addresses but for mapping we need to align them */ offset = (phys_addr & ~PAGE_MASK); @@ -43,21 +42,9 @@ static void *__do_ioremap(unsigned long phys_addr, unsigned long size, phys_addr &= PAGE_MASK; mfns = mfn = phys_addr >> PAGE_SHIFT; - /* sanity checks on list of MFNs */ - for ( i = 0; i < num_pages; i++, mfn++ ) - { - if ( mfn_is_ram(mfn) ) - { - printk("ioremap: mfn 0x%ulx is RAM\n", mfn); - goto mfn_invalid; - } - } va = (unsigned long)map_frames_ex(&mfns, num_pages, 0, 1, 1, DOMID_IO, NULL, prot); return (void *)(va + offset); - -mfn_invalid: - return NULL; } void *ioremap(unsigned long phys_addr, unsigned long size) diff --git a/extras/mini-os/arch/x86/mm.c b/extras/mini-os/arch/x86/mm.c index 80aceac..35df15b 100644 --- a/extras/mini-os/arch/x86/mm.c +++ b/extras/mini-os/arch/x86/mm.c @@ -845,18 +845,6 @@ unsigned long alloc_contig_pages(int order, unsigned int addr_bits) } /* - * Check if a given MFN refers to real memory - */ -static long system_ram_end_mfn; -int mfn_is_ram(unsigned long mfn) -{ - /* very crude check if a given MFN is memory or not. Probably should - * make this a little more sophisticated ;) */ - return (mfn <= system_ram_end_mfn) ? 1 : 0; -} - - -/* * Clear some of the bootstrap memory */ static void clear_bootstrap(void) @@ -951,10 +939,6 @@ void arch_init_mm(unsigned long* start_pfn_p, unsigned long* max_pfn_p) clear_bootstrap(); set_readonly(&_text, &_erodata); - /* get the number of physical pages the system has. Used to check for - * system memory. */ - system_ram_end_mfn = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL); - *start_pfn_p = start_pfn; *max_pfn_p = max_pfn; } diff --git a/extras/mini-os/include/x86/arch_mm.h b/extras/mini-os/include/x86/arch_mm.h index a95632a..23cfca7 100644 --- a/extras/mini-os/include/x86/arch_mm.h +++ b/extras/mini-os/include/x86/arch_mm.h @@ -229,6 +229,5 @@ static __inline__ paddr_t machine_to_phys(maddr_t machine) #define do_map_zero(start, n) do_map_frames(start, &mfn_zero, n, 0, 0, DOMID_SELF, NULL, L1_PROT_RO) pgentry_t *need_pgt(unsigned long addr); -int mfn_is_ram(unsigned long mfn); #endif /* _ARCH_MM_H_ */ -- 1.7.4.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 14:44:09 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:44:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3hY-0007uj-EJ; Tue, 02 Oct 2012 14:44:00 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3hW-0007uO-V5 for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:43:59 +0000 Received: from [85.158.137.99:53714] by server-7.bemta-3.messagelabs.com id 55/C9-15765-EADFA605; Tue, 02 Oct 2012 14:43:58 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-16.tower-217.messagelabs.com!1349189037!19968969!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10435 invoked from network); 2 Oct 2012 14:43:57 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 14:43:57 -0000 X-IronPort-AV: E=Sophos;i="4.80,523,1344211200"; d="scan'208";a="14896540" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 14:43:56 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 15:43:56 +0100 Message-ID: <1349189034.650.85.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Matthew Fioravante Date: Tue, 2 Oct 2012 15:43:54 +0100 In-Reply-To: <506AFAA8.9050900@jhuapl.edu> References: <1348765860-11359-1-git-send-email-matthew.fioravante@jhuapl.edu> <1348765860-11359-3-git-send-email-matthew.fioravante@jhuapl.edu> <5065CAE9.30602@jhuapl.edu> <5065D333.6080600@jhuapl.edu> <5069E396.5040205@jhuapl.edu> <1349185449.650.55.camel@zakaz.uk.xensource.com> <506AFAA8.9050900@jhuapl.edu> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: George Dunlap , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 11/11] add vtpm support to libxl X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-10-02 at 15:31 +0100, Matthew Fioravante wrote: > On 10/02/2012 09:44 AM, Ian Campbell wrote: > > On Mon, 2012-10-01 at 19:40 +0100, Matthew Fioravante wrote: > > > >> Actually thinking about it more, uuids have to be attached to the > >> driver. If 2 vtpms connect to the manager, one could send the uuid of > >> the other and get access to someone elses secrets. > >> > >> TL;DR version > >> > >> uuids must remain part of the driver. > > What stops the driver lying about the UUID in a similar way? > The tpm backend driver (in the manager) will read the uuid from > xenstore. So as long as we trust xenstore ( and the entities who created > the entry, named libxl in dom0), we can trust the uuid and thus the > identity of the vtpm connecting to us. OK, why does that same argument not apply when the toolstack passes the UUID to the manager domain instead? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 14:44:09 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:44:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3hY-0007uj-EJ; Tue, 02 Oct 2012 14:44:00 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3hW-0007uO-V5 for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:43:59 +0000 Received: from [85.158.137.99:53714] by server-7.bemta-3.messagelabs.com id 55/C9-15765-EADFA605; Tue, 02 Oct 2012 14:43:58 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-16.tower-217.messagelabs.com!1349189037!19968969!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10435 invoked from network); 2 Oct 2012 14:43:57 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 14:43:57 -0000 X-IronPort-AV: E=Sophos;i="4.80,523,1344211200"; d="scan'208";a="14896540" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 14:43:56 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 15:43:56 +0100 Message-ID: <1349189034.650.85.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Matthew Fioravante Date: Tue, 2 Oct 2012 15:43:54 +0100 In-Reply-To: <506AFAA8.9050900@jhuapl.edu> References: <1348765860-11359-1-git-send-email-matthew.fioravante@jhuapl.edu> <1348765860-11359-3-git-send-email-matthew.fioravante@jhuapl.edu> <5065CAE9.30602@jhuapl.edu> <5065D333.6080600@jhuapl.edu> <5069E396.5040205@jhuapl.edu> <1349185449.650.55.camel@zakaz.uk.xensource.com> <506AFAA8.9050900@jhuapl.edu> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: George Dunlap , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 11/11] add vtpm support to libxl X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-10-02 at 15:31 +0100, Matthew Fioravante wrote: > On 10/02/2012 09:44 AM, Ian Campbell wrote: > > On Mon, 2012-10-01 at 19:40 +0100, Matthew Fioravante wrote: > > > >> Actually thinking about it more, uuids have to be attached to the > >> driver. If 2 vtpms connect to the manager, one could send the uuid of > >> the other and get access to someone elses secrets. > >> > >> TL;DR version > >> > >> uuids must remain part of the driver. > > What stops the driver lying about the UUID in a similar way? > The tpm backend driver (in the manager) will read the uuid from > xenstore. So as long as we trust xenstore ( and the entities who created > the entry, named libxl in dom0), we can trust the uuid and thus the > identity of the vtpm connecting to us. OK, why does that same argument not apply when the toolstack passes the UUID to the manager domain instead? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 14:44:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:44:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3hy-000825-ST; Tue, 02 Oct 2012 14:44:26 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3hx-00080L-Nw for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:44:25 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1349189059!3387545!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5814 invoked from network); 2 Oct 2012 14:44:19 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 14:44:19 -0000 X-IronPort-AV: E=Sophos;i="4.80,523,1344211200"; d="scan'208";a="14896553" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 14:44:19 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 15:44:19 +0100 Message-ID: <1349189057.650.86.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Matthew Fioravante Date: Tue, 2 Oct 2012 15:44:17 +0100 In-Reply-To: <506AF764.5040701@jhuapl.edu> References: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu> <1348765802-11314-8-git-send-email-matthew.fioravante@jhuapl.edu> <1349175465.650.39.camel@zakaz.uk.xensource.com> <506AF764.5040701@jhuapl.edu> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "samuel.thibault@ens-lyon.org" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 08/11] add tpmfront, tpm_tis, and tpmback drivers to mini-os X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-10-02 at 15:17 +0100, Matthew Fioravante wrote: > On 10/02/2012 06:57 AM, Ian Campbell wrote: > >> diff --git a/extras/mini-os/include/tpm_tis.h b/extras/mini-os/include/tpm_tis.h > >> new file mode 100644 > >> index 0000000..b463cea > >> --- /dev/null > >> +++ b/extras/mini-os/include/tpm_tis.h > >> @@ -0,0 +1,74 @@ > >> +/* > >> + * Copyright (c) 2010-2012 United States Government, as represented by > >> + * the Secretary of Defense. All rights reserved. > >> + * > >> + * This program is free software; you can redistribute it and/or > >> + * modify it under the terms of the GNU General Public License version 2 > >> + * as published by the Free Software Foundation; or, when distributed > >> + * separately from the Linux kernel or incorporated into other > >> + * software packages, subject to the following license: > >> + * > >> + * Permission is hereby granted, free of charge, to any person obtaining a copy > >> + * of this source file (the "Software"), to deal in the Software without > >> + * restriction, including without limitation the rights to use, copy, modify, > >> + * merge, publish, distribute, sublicense, and/or sell copies of the Software, > >> + * and to permit persons to whom the Software is furnished to do so, subject to > >> + * the following conditions: > >> + * > >> + * The above copyright notice and this permission notice shall be included in > >> + * all copies or substantial portions of the Software. > >> + * > >> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR > >> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > >> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE > >> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER > >> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING > >> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS > >> + * IN THE SOFTWARE. > >> + * > >> + * Based upon the files: > >> + * drivers/char/tpm/tpm_tis.c > >> + * drivers/char/tpm/tpm.c > >> + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation > > Given that then I don't think you have the authority to dual license > > code owned by IBM as GPL or the MIT style thing above -- these files are > > subject to the licensing terms of those original files (which looks to > > be GPL v2 only). > > > > It might be acceptable to have a GPL header as the primary followed by a > > "modifications by Matthew Fioravante/US Gov/Secretary Defense are also > > licensed under... .MIT thing ...." but I'd want to see a second opinion > > on that I think. > > > > I didn't check all the other licensing thoroughly but I expect similar > > comments will apply elsewhere too. > As far as I understand (I'm in no way a copyright lawyer), there is a > difference between copyright and license. What this is trying to convey > is that the changes are copyrighted by the US Govt and the license being > offered is GPLv2. The license which your header offers is not the GPLv2 though -- it says GPLv2 or MIT license, specifically it says: "; or, when distributed separately from the Linux kernel or incorporated into other software packages, subject to the following license: ". If that is not your intention then you have written the wrong thing in your header. Perhaps you would find the "How to Apply These Terms to Your New Programs" bit of http://www.gnu.org/licenses/gpl-2.0.html useful? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 14:44:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:44:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3hy-000825-ST; Tue, 02 Oct 2012 14:44:26 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3hx-00080L-Nw for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:44:25 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1349189059!3387545!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5814 invoked from network); 2 Oct 2012 14:44:19 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 14:44:19 -0000 X-IronPort-AV: E=Sophos;i="4.80,523,1344211200"; d="scan'208";a="14896553" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 14:44:19 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 15:44:19 +0100 Message-ID: <1349189057.650.86.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Matthew Fioravante Date: Tue, 2 Oct 2012 15:44:17 +0100 In-Reply-To: <506AF764.5040701@jhuapl.edu> References: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu> <1348765802-11314-8-git-send-email-matthew.fioravante@jhuapl.edu> <1349175465.650.39.camel@zakaz.uk.xensource.com> <506AF764.5040701@jhuapl.edu> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "samuel.thibault@ens-lyon.org" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 08/11] add tpmfront, tpm_tis, and tpmback drivers to mini-os X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-10-02 at 15:17 +0100, Matthew Fioravante wrote: > On 10/02/2012 06:57 AM, Ian Campbell wrote: > >> diff --git a/extras/mini-os/include/tpm_tis.h b/extras/mini-os/include/tpm_tis.h > >> new file mode 100644 > >> index 0000000..b463cea > >> --- /dev/null > >> +++ b/extras/mini-os/include/tpm_tis.h > >> @@ -0,0 +1,74 @@ > >> +/* > >> + * Copyright (c) 2010-2012 United States Government, as represented by > >> + * the Secretary of Defense. All rights reserved. > >> + * > >> + * This program is free software; you can redistribute it and/or > >> + * modify it under the terms of the GNU General Public License version 2 > >> + * as published by the Free Software Foundation; or, when distributed > >> + * separately from the Linux kernel or incorporated into other > >> + * software packages, subject to the following license: > >> + * > >> + * Permission is hereby granted, free of charge, to any person obtaining a copy > >> + * of this source file (the "Software"), to deal in the Software without > >> + * restriction, including without limitation the rights to use, copy, modify, > >> + * merge, publish, distribute, sublicense, and/or sell copies of the Software, > >> + * and to permit persons to whom the Software is furnished to do so, subject to > >> + * the following conditions: > >> + * > >> + * The above copyright notice and this permission notice shall be included in > >> + * all copies or substantial portions of the Software. > >> + * > >> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR > >> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > >> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE > >> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER > >> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING > >> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS > >> + * IN THE SOFTWARE. > >> + * > >> + * Based upon the files: > >> + * drivers/char/tpm/tpm_tis.c > >> + * drivers/char/tpm/tpm.c > >> + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation > > Given that then I don't think you have the authority to dual license > > code owned by IBM as GPL or the MIT style thing above -- these files are > > subject to the licensing terms of those original files (which looks to > > be GPL v2 only). > > > > It might be acceptable to have a GPL header as the primary followed by a > > "modifications by Matthew Fioravante/US Gov/Secretary Defense are also > > licensed under... .MIT thing ...." but I'd want to see a second opinion > > on that I think. > > > > I didn't check all the other licensing thoroughly but I expect similar > > comments will apply elsewhere too. > As far as I understand (I'm in no way a copyright lawyer), there is a > difference between copyright and license. What this is trying to convey > is that the changes are copyrighted by the US Govt and the license being > offered is GPLv2. The license which your header offers is not the GPLv2 though -- it says GPLv2 or MIT license, specifically it says: "; or, when distributed separately from the Linux kernel or incorporated into other software packages, subject to the following license: ". If that is not your intention then you have written the wrong thing in your header. Perhaps you would find the "How to Apply These Terms to Your New Programs" bit of http://www.gnu.org/licenses/gpl-2.0.html useful? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 14:46:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:46:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3k7-0008Nn-Ee; Tue, 02 Oct 2012 14:46:39 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3k6-0008NZ-7F for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:46:38 +0000 Received: from [85.158.139.211:38490] by server-16.bemta-5.messagelabs.com id E8/0F-05998-D4EFA605; Tue, 02 Oct 2012 14:46:37 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-15.tower-206.messagelabs.com!1349189196!20833713!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19352 invoked from network); 2 Oct 2012 14:46:36 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-15.tower-206.messagelabs.com with SMTP; 2 Oct 2012 14:46:36 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 02 Oct 2012 15:46:36 +0100 Message-Id: <506B1A69020000780009F20F@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Tue, 02 Oct 2012 15:46:33 +0100 From: "Jan Beulich" To: "xen-devel" Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__PartF5C4C259.0__=" Subject: [Xen-devel] [PATCH] x86: get the MWAIT idle driver in sync with the ACPI one X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartF5C4C259.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline .. with respect to behavior when there is no HPET broadcast support (for using the PIT broadcast instead, it requires explicitly enabling CPU idle management). Signed-off-by: Jan Beulich --- a/xen/arch/x86/cpu/mwait-idle.c +++ b/xen/arch/x86/cpu/mwait-idle.c @@ -501,11 +501,14 @@ int __init mwait_idle_init(struct notifi return -ENODEV; =20 err =3D mwait_idle_probe(); - if (!err) { - if (!boot_cpu_has(X86_FEATURE_ARAT)) - hpet_broadcast_init(); - if (!lapic_timer_init()) + if (!err && !boot_cpu_has(X86_FEATURE_ARAT)) { + hpet_broadcast_init(); + if (xen_cpuidle < 0 && !hpet_broadcast_is_available()) + err =3D -ENODEV; + else if(!lapic_timer_init()) err =3D -EINVAL; + if (err) + pr_debug(PREFIX "not used (%d)\n", err); } if (!err) { nfb->notifier_call =3D mwait_idle_cpu_init; --=__PartF5C4C259.0__= Content-Type: text/plain; name="x86-MWAIT-idle-match-ACPI.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="x86-MWAIT-idle-match-ACPI.patch" x86: get the MWAIT idle driver in sync with the ACPI one=0A=0A.. with = respect to behavior when there is no HPET broadcast support=0A(for using = the PIT broadcast instead, it requires explicitly enabling=0ACPU idle = management).=0A=0ASigned-off-by: Jan Beulich =0A=0A--- = a/xen/arch/x86/cpu/mwait-idle.c=0A+++ b/xen/arch/x86/cpu/mwait-idle.c=0A@@ = -501,11 +501,14 @@ int __init mwait_idle_init(struct notifi=0A = return -ENODEV;=0A =0A err =3D mwait_idle_probe();=0A- if (!err) {=0A- = if (!boot_cpu_has(X86_FEATURE_ARAT))=0A- hpet_broadc= ast_init();=0A- if (!lapic_timer_init())=0A+ if (!err && = !boot_cpu_has(X86_FEATURE_ARAT)) {=0A+ hpet_broadcast_init();=0A+ = if (xen_cpuidle < 0 && !hpet_broadcast_is_available())=0A+ = err =3D -ENODEV;=0A+ else if(!lapic_timer_init())=0A = err =3D -EINVAL;=0A+ if (err)=0A+ = pr_debug(PREFIX "not used (%d)\n", err);=0A }=0A if (!err) {=0A = nfb->notifier_call =3D mwait_idle_cpu_init;=0A --=__PartF5C4C259.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --=__PartF5C4C259.0__=-- From xen-devel-bounces@lists.xen.org Tue Oct 02 14:46:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:46:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3k7-0008Nn-Ee; Tue, 02 Oct 2012 14:46:39 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3k6-0008NZ-7F for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:46:38 +0000 Received: from [85.158.139.211:38490] by server-16.bemta-5.messagelabs.com id E8/0F-05998-D4EFA605; Tue, 02 Oct 2012 14:46:37 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-15.tower-206.messagelabs.com!1349189196!20833713!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19352 invoked from network); 2 Oct 2012 14:46:36 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-15.tower-206.messagelabs.com with SMTP; 2 Oct 2012 14:46:36 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 02 Oct 2012 15:46:36 +0100 Message-Id: <506B1A69020000780009F20F@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Tue, 02 Oct 2012 15:46:33 +0100 From: "Jan Beulich" To: "xen-devel" Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__PartF5C4C259.0__=" Subject: [Xen-devel] [PATCH] x86: get the MWAIT idle driver in sync with the ACPI one X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartF5C4C259.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline .. with respect to behavior when there is no HPET broadcast support (for using the PIT broadcast instead, it requires explicitly enabling CPU idle management). Signed-off-by: Jan Beulich --- a/xen/arch/x86/cpu/mwait-idle.c +++ b/xen/arch/x86/cpu/mwait-idle.c @@ -501,11 +501,14 @@ int __init mwait_idle_init(struct notifi return -ENODEV; =20 err =3D mwait_idle_probe(); - if (!err) { - if (!boot_cpu_has(X86_FEATURE_ARAT)) - hpet_broadcast_init(); - if (!lapic_timer_init()) + if (!err && !boot_cpu_has(X86_FEATURE_ARAT)) { + hpet_broadcast_init(); + if (xen_cpuidle < 0 && !hpet_broadcast_is_available()) + err =3D -ENODEV; + else if(!lapic_timer_init()) err =3D -EINVAL; + if (err) + pr_debug(PREFIX "not used (%d)\n", err); } if (!err) { nfb->notifier_call =3D mwait_idle_cpu_init; --=__PartF5C4C259.0__= Content-Type: text/plain; name="x86-MWAIT-idle-match-ACPI.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="x86-MWAIT-idle-match-ACPI.patch" x86: get the MWAIT idle driver in sync with the ACPI one=0A=0A.. with = respect to behavior when there is no HPET broadcast support=0A(for using = the PIT broadcast instead, it requires explicitly enabling=0ACPU idle = management).=0A=0ASigned-off-by: Jan Beulich =0A=0A--- = a/xen/arch/x86/cpu/mwait-idle.c=0A+++ b/xen/arch/x86/cpu/mwait-idle.c=0A@@ = -501,11 +501,14 @@ int __init mwait_idle_init(struct notifi=0A = return -ENODEV;=0A =0A err =3D mwait_idle_probe();=0A- if (!err) {=0A- = if (!boot_cpu_has(X86_FEATURE_ARAT))=0A- hpet_broadc= ast_init();=0A- if (!lapic_timer_init())=0A+ if (!err && = !boot_cpu_has(X86_FEATURE_ARAT)) {=0A+ hpet_broadcast_init();=0A+ = if (xen_cpuidle < 0 && !hpet_broadcast_is_available())=0A+ = err =3D -ENODEV;=0A+ else if(!lapic_timer_init())=0A = err =3D -EINVAL;=0A+ if (err)=0A+ = pr_debug(PREFIX "not used (%d)\n", err);=0A }=0A if (!err) {=0A = nfb->notifier_call =3D mwait_idle_cpu_init;=0A --=__PartF5C4C259.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --=__PartF5C4C259.0__=-- From xen-devel-bounces@lists.xen.org Tue Oct 02 14:49:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:49:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3mY-0000BM-0O; Tue, 02 Oct 2012 14:49:10 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3mW-0000BE-HR for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:49:08 +0000 Received: from [85.158.143.35:43834] by server-3.bemta-4.messagelabs.com id 0B/6B-10986-3EEFA605; Tue, 02 Oct 2012 14:49:07 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-15.tower-21.messagelabs.com!1349189342!16022360!1 X-Originating-IP: [128.244.251.36] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23748 invoked from network); 2 Oct 2012 14:49:03 -0000 Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36) by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 14:49:03 -0000 Received: from ([128.244.207.89]) by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.154112130; Tue, 02 Oct 2012 10:48:57 -0400 Message-ID: <506AFE88.1080806@jhuapl.edu> Date: Tue, 02 Oct 2012 10:47:36 -0400 From: Matthew Fioravante User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Ian Campbell References: <1348765860-11359-1-git-send-email-matthew.fioravante@jhuapl.edu> <1348765860-11359-3-git-send-email-matthew.fioravante@jhuapl.edu> <5065CAE9.30602@jhuapl.edu> <5065D333.6080600@jhuapl.edu> <5069E396.5040205@jhuapl.edu> <1349185449.650.55.camel@zakaz.uk.xensource.com> <506AFAA8.9050900@jhuapl.edu> <1349189034.650.85.camel@zakaz.uk.xensource.com> In-Reply-To: <1349189034.650.85.camel@zakaz.uk.xensource.com> X-Enigmail-Version: 1.4.4 Cc: George Dunlap , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 11/11] add vtpm support to libxl X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6149785794508243656==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a cryptographically signed message in MIME format. --===============6149785794508243656== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060103000408090100080008" This is a cryptographically signed message in MIME format. --------------ms060103000408090100080008 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/02/2012 10:43 AM, Ian Campbell wrote: > On Tue, 2012-10-02 at 15:31 +0100, Matthew Fioravante wrote: >> On 10/02/2012 09:44 AM, Ian Campbell wrote: >>> On Mon, 2012-10-01 at 19:40 +0100, Matthew Fioravante wrote: >>> >>>> Actually thinking about it more, uuids have to be attached to the >>>> driver. If 2 vtpms connect to the manager, one could send the uuid o= f >>>> the other and get access to someone elses secrets. >>>> >>>> TL;DR version >>>> >>>> uuids must remain part of the driver. >>> What stops the driver lying about the UUID in a similar way? >> The tpm backend driver (in the manager) will read the uuid from >> xenstore. So as long as we trust xenstore ( and the entities who creat= ed >> the entry, named libxl in dom0), we can trust the uuid and thus the >> identity of the vtpm connecting to us. > OK, why does that same argument not apply when the toolstack passes the= > UUID to the manager domain instead? The other implementation I mentioned is where the toolstack would just create a front/back pair and the vtpm itself would send its uuid. If the toolstack can be fooled ( as simple as replacing the vtpm kernel image) then it will connect a bogus vtpm to the manager which can then send the uuid of any real vtpm and get at its secrets. In essense, attaching the uuid to the driver is basically a convenient way of having the toolstack domain tell the vtpm manager the identity of the vtpm. If it wasn't attached to the driver there would have to be some other daemon or special case code to do this. This problem might go away later if/when we have measured boot of vtpms but that is not currently implemented. > > Ian. > > --------------ms060103000408090100080008 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4 NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50 ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz 4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTEyMTAwMjE0NDczNlowIwYJKoZIhvcNAQkEMRYEFC/Zeixml13YRA/Q lGieZqG7to7iMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAcMRTITFY8M4UR0QFGI5icVg8NYFjCe3gO 184Qt/23DOkAGCk+E05YMKTuvvHNlt2OmZObuZQoaalUz2f8GuQO77/5oLG7nl4LypaBKJAz ZFxd2+BxrkABJhn1nIitaUIVnpl4RYitclHnRzbANfpgBA4nPFWV1jRwdDTj9E1fwQAAAAAA AA== --------------ms060103000408090100080008-- --===============6149785794508243656== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6149785794508243656==-- From xen-devel-bounces@lists.xen.org Tue Oct 02 14:49:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:49:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3mY-0000BM-0O; Tue, 02 Oct 2012 14:49:10 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3mW-0000BE-HR for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:49:08 +0000 Received: from [85.158.143.35:43834] by server-3.bemta-4.messagelabs.com id 0B/6B-10986-3EEFA605; Tue, 02 Oct 2012 14:49:07 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-15.tower-21.messagelabs.com!1349189342!16022360!1 X-Originating-IP: [128.244.251.36] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23748 invoked from network); 2 Oct 2012 14:49:03 -0000 Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36) by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 14:49:03 -0000 Received: from ([128.244.207.89]) by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.154112130; Tue, 02 Oct 2012 10:48:57 -0400 Message-ID: <506AFE88.1080806@jhuapl.edu> Date: Tue, 02 Oct 2012 10:47:36 -0400 From: Matthew Fioravante User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Ian Campbell References: <1348765860-11359-1-git-send-email-matthew.fioravante@jhuapl.edu> <1348765860-11359-3-git-send-email-matthew.fioravante@jhuapl.edu> <5065CAE9.30602@jhuapl.edu> <5065D333.6080600@jhuapl.edu> <5069E396.5040205@jhuapl.edu> <1349185449.650.55.camel@zakaz.uk.xensource.com> <506AFAA8.9050900@jhuapl.edu> <1349189034.650.85.camel@zakaz.uk.xensource.com> In-Reply-To: <1349189034.650.85.camel@zakaz.uk.xensource.com> X-Enigmail-Version: 1.4.4 Cc: George Dunlap , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 11/11] add vtpm support to libxl X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6149785794508243656==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a cryptographically signed message in MIME format. --===============6149785794508243656== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060103000408090100080008" This is a cryptographically signed message in MIME format. --------------ms060103000408090100080008 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/02/2012 10:43 AM, Ian Campbell wrote: > On Tue, 2012-10-02 at 15:31 +0100, Matthew Fioravante wrote: >> On 10/02/2012 09:44 AM, Ian Campbell wrote: >>> On Mon, 2012-10-01 at 19:40 +0100, Matthew Fioravante wrote: >>> >>>> Actually thinking about it more, uuids have to be attached to the >>>> driver. If 2 vtpms connect to the manager, one could send the uuid o= f >>>> the other and get access to someone elses secrets. >>>> >>>> TL;DR version >>>> >>>> uuids must remain part of the driver. >>> What stops the driver lying about the UUID in a similar way? >> The tpm backend driver (in the manager) will read the uuid from >> xenstore. So as long as we trust xenstore ( and the entities who creat= ed >> the entry, named libxl in dom0), we can trust the uuid and thus the >> identity of the vtpm connecting to us. > OK, why does that same argument not apply when the toolstack passes the= > UUID to the manager domain instead? The other implementation I mentioned is where the toolstack would just create a front/back pair and the vtpm itself would send its uuid. If the toolstack can be fooled ( as simple as replacing the vtpm kernel image) then it will connect a bogus vtpm to the manager which can then send the uuid of any real vtpm and get at its secrets. In essense, attaching the uuid to the driver is basically a convenient way of having the toolstack domain tell the vtpm manager the identity of the vtpm. If it wasn't attached to the driver there would have to be some other daemon or special case code to do this. This problem might go away later if/when we have measured boot of vtpms but that is not currently implemented. > > Ian. > > --------------ms060103000408090100080008 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4 NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50 ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz 4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTEyMTAwMjE0NDczNlowIwYJKoZIhvcNAQkEMRYEFC/Zeixml13YRA/Q lGieZqG7to7iMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAcMRTITFY8M4UR0QFGI5icVg8NYFjCe3gO 184Qt/23DOkAGCk+E05YMKTuvvHNlt2OmZObuZQoaalUz2f8GuQO77/5oLG7nl4LypaBKJAz ZFxd2+BxrkABJhn1nIitaUIVnpl4RYitclHnRzbANfpgBA4nPFWV1jRwdDTj9E1fwQAAAAAA AA== --------------ms060103000408090100080008-- --===============6149785794508243656== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6149785794508243656==-- From xen-devel-bounces@lists.xen.org Tue Oct 02 14:51:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:51:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3oO-0000Kf-IY; Tue, 02 Oct 2012 14:51:04 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3oM-0000KV-FG for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:51:02 +0000 Received: from [85.158.138.51:8981] by server-1.bemta-3.messagelabs.com id AE/73-16425-55FFA605; Tue, 02 Oct 2012 14:51:01 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-14.tower-174.messagelabs.com!1349189446!26482367!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MjMzMTI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27751 invoked from network); 2 Oct 2012 14:50:47 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 14:50:47 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id 7F16A2018; Tue, 2 Oct 2012 17:50:45 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id C6B3320058; Tue, 2 Oct 2012 17:50:44 +0300 (EEST) Date: Tue, 2 Oct 2012 17:50:44 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Ian Campbell Message-ID: <20121002145044.GQ8912@reaktio.net> References: <20121001164239.GE8912@reaktio.net> <20586.63875.490107.170343@mariner.uk.xensource.com> <1349188361.650.77.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1349188361.650.77.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: George Dunlap , Ian Jackson , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Xen 4.3 development update X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, Oct 02, 2012 at 03:32:41PM +0100, Ian Campbell wrote: > > > > * xl USB pass-through for HVM guests using Qemu USB emulation > > > owner: ? > > > status: ? > > > - xm/xend with qemu-traditional supports USB passthrough to HVM guests using the Qemu emulated USB controller. > > > - port the xm/xend functionality to xl. > > > - make sure USB passthrough with xl works with both qemu-traditional and qemu-upstream. > > > - The HVM guest does not need any special drivers for this feature. > > > > I think this is just a matter of plumbing in libxl (presumably, now, > > plumbing to qemu-upstream). > > Assuming qemu-upstream has the necessary feature... > Yes, qemu-upstream supports host USB device pass-through. references: http://www.linux-kvm.org/page/USB_Host_Device_Assigned_to_Guest http://david.wragg.org/blog/2009/03/using-usb-pass-through-under-libvirt.html http://david.wragg.org/blog/2009/03/usb-pass-through-with-libvirt-and-kvm.html So basicly the qemu cmdline needs to have: -usb -usbdevice host:xxxx:yyyy -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 14:51:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:51:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3oO-0000Kf-IY; Tue, 02 Oct 2012 14:51:04 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3oM-0000KV-FG for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:51:02 +0000 Received: from [85.158.138.51:8981] by server-1.bemta-3.messagelabs.com id AE/73-16425-55FFA605; Tue, 02 Oct 2012 14:51:01 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-14.tower-174.messagelabs.com!1349189446!26482367!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MjMzMTI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27751 invoked from network); 2 Oct 2012 14:50:47 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 14:50:47 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id 7F16A2018; Tue, 2 Oct 2012 17:50:45 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id C6B3320058; Tue, 2 Oct 2012 17:50:44 +0300 (EEST) Date: Tue, 2 Oct 2012 17:50:44 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Ian Campbell Message-ID: <20121002145044.GQ8912@reaktio.net> References: <20121001164239.GE8912@reaktio.net> <20586.63875.490107.170343@mariner.uk.xensource.com> <1349188361.650.77.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1349188361.650.77.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: George Dunlap , Ian Jackson , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Xen 4.3 development update X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, Oct 02, 2012 at 03:32:41PM +0100, Ian Campbell wrote: > > > > * xl USB pass-through for HVM guests using Qemu USB emulation > > > owner: ? > > > status: ? > > > - xm/xend with qemu-traditional supports USB passthrough to HVM guests using the Qemu emulated USB controller. > > > - port the xm/xend functionality to xl. > > > - make sure USB passthrough with xl works with both qemu-traditional and qemu-upstream. > > > - The HVM guest does not need any special drivers for this feature. > > > > I think this is just a matter of plumbing in libxl (presumably, now, > > plumbing to qemu-upstream). > > Assuming qemu-upstream has the necessary feature... > Yes, qemu-upstream supports host USB device pass-through. references: http://www.linux-kvm.org/page/USB_Host_Device_Assigned_to_Guest http://david.wragg.org/blog/2009/03/using-usb-pass-through-under-libvirt.html http://david.wragg.org/blog/2009/03/usb-pass-through-with-libvirt-and-kvm.html So basicly the qemu cmdline needs to have: -usb -usbdevice host:xxxx:yyyy -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 14:55:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:55:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3sT-0000ZB-9D; Tue, 02 Oct 2012 14:55:17 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3sS-0000Z2-8y for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:55:16 +0000 Received: from [85.158.138.51:57462] by server-4.bemta-3.messagelabs.com id 50/7D-14155-3500B605; Tue, 02 Oct 2012 14:55:15 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1349189714!31122747!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17193 invoked from network); 2 Oct 2012 14:55:14 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-9.tower-174.messagelabs.com with SMTP; 2 Oct 2012 14:55:14 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 02 Oct 2012 15:55:14 +0100 Message-Id: <506B1C6E020000780009F221@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Tue, 02 Oct 2012 15:55:10 +0100 From: "Jan Beulich" To: "xen-devel" Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part0D3C3B5E.0__=" Subject: [Xen-devel] [PATCH] VT-d: make remap_entry_to_msi_msg() return consistent message X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part0D3C3B5E.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline During debugging of another problem I found that in x2APIC mode, the destination field of the low address value wasn't passed back correctly. While this is benign in most cases (as the value isn't being used anywhere), it can be confusing (and misguiding) when printing the value read or when comparing it to the one previously passed into the inverse function. Signed-off-by: Jan Beulich --- a/xen/drivers/passthrough/vtd/intremap.c +++ b/xen/drivers/passthrough/vtd/intremap.c @@ -504,7 +504,11 @@ static int remap_entry_to_msi_msg( MSI_ADDR_REDIRECTION_CPU: MSI_ADDR_REDIRECTION_LOWPRI); if ( x2apic_enabled ) + { msg->dest32 =3D iremap_entry->lo.dst; + msg->address_lo |=3D + (iremap_entry->lo.dst & 0xff) << MSI_ADDR_DEST_ID_SHIFT; + } else msg->address_lo |=3D ((iremap_entry->lo.dst >> 8) & 0xff ) << MSI_ADDR_DEST_ID_SHIF= T; --=__Part0D3C3B5E.0__= Content-Type: text/plain; name="VT-d-read-MSI-full.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="VT-d-read-MSI-full.patch" VT-d: make remap_entry_to_msi_msg() return consistent message=0A=0ADuring = debugging of another problem I found that in x2APIC mode, the=0Adestination= field of the low address value wasn't passed back=0Acorrectly. While this = is benign in most cases (as the value isn't being=0Aused anywhere), it can = be confusing (and misguiding) when printing the=0Avalue read or when = comparing it to the one previously passed into the=0Ainverse function.=0A= =0ASigned-off-by: Jan Beulich =0A=0A--- a/xen/drivers/pa= ssthrough/vtd/intremap.c=0A+++ b/xen/drivers/passthrough/vtd/intremap.c=0A@= @ -504,7 +504,11 @@ static int remap_entry_to_msi_msg(=0A = MSI_ADDR_REDIRECTION_CPU:=0A MSI_ADDR_REDIRECTION_LOWPRI);=0A = if ( x2apic_enabled )=0A+ {=0A msg->dest32 =3D iremap_entry->= lo.dst;=0A+ msg->address_lo |=3D=0A+ (iremap_entry->lo.ds= t & 0xff) << MSI_ADDR_DEST_ID_SHIFT;=0A+ }=0A else=0A = msg->address_lo |=3D=0A ((iremap_entry->lo.dst >> 8) & 0xff ) = << MSI_ADDR_DEST_ID_SHIFT;=0A --=__Part0D3C3B5E.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --=__Part0D3C3B5E.0__=-- From xen-devel-bounces@lists.xen.org Tue Oct 02 14:55:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:55:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3sT-0000ZB-9D; Tue, 02 Oct 2012 14:55:17 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3sS-0000Z2-8y for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:55:16 +0000 Received: from [85.158.138.51:57462] by server-4.bemta-3.messagelabs.com id 50/7D-14155-3500B605; Tue, 02 Oct 2012 14:55:15 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1349189714!31122747!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17193 invoked from network); 2 Oct 2012 14:55:14 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-9.tower-174.messagelabs.com with SMTP; 2 Oct 2012 14:55:14 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 02 Oct 2012 15:55:14 +0100 Message-Id: <506B1C6E020000780009F221@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Tue, 02 Oct 2012 15:55:10 +0100 From: "Jan Beulich" To: "xen-devel" Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part0D3C3B5E.0__=" Subject: [Xen-devel] [PATCH] VT-d: make remap_entry_to_msi_msg() return consistent message X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part0D3C3B5E.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline During debugging of another problem I found that in x2APIC mode, the destination field of the low address value wasn't passed back correctly. While this is benign in most cases (as the value isn't being used anywhere), it can be confusing (and misguiding) when printing the value read or when comparing it to the one previously passed into the inverse function. Signed-off-by: Jan Beulich --- a/xen/drivers/passthrough/vtd/intremap.c +++ b/xen/drivers/passthrough/vtd/intremap.c @@ -504,7 +504,11 @@ static int remap_entry_to_msi_msg( MSI_ADDR_REDIRECTION_CPU: MSI_ADDR_REDIRECTION_LOWPRI); if ( x2apic_enabled ) + { msg->dest32 =3D iremap_entry->lo.dst; + msg->address_lo |=3D + (iremap_entry->lo.dst & 0xff) << MSI_ADDR_DEST_ID_SHIFT; + } else msg->address_lo |=3D ((iremap_entry->lo.dst >> 8) & 0xff ) << MSI_ADDR_DEST_ID_SHIF= T; --=__Part0D3C3B5E.0__= Content-Type: text/plain; name="VT-d-read-MSI-full.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="VT-d-read-MSI-full.patch" VT-d: make remap_entry_to_msi_msg() return consistent message=0A=0ADuring = debugging of another problem I found that in x2APIC mode, the=0Adestination= field of the low address value wasn't passed back=0Acorrectly. While this = is benign in most cases (as the value isn't being=0Aused anywhere), it can = be confusing (and misguiding) when printing the=0Avalue read or when = comparing it to the one previously passed into the=0Ainverse function.=0A= =0ASigned-off-by: Jan Beulich =0A=0A--- a/xen/drivers/pa= ssthrough/vtd/intremap.c=0A+++ b/xen/drivers/passthrough/vtd/intremap.c=0A@= @ -504,7 +504,11 @@ static int remap_entry_to_msi_msg(=0A = MSI_ADDR_REDIRECTION_CPU:=0A MSI_ADDR_REDIRECTION_LOWPRI);=0A = if ( x2apic_enabled )=0A+ {=0A msg->dest32 =3D iremap_entry->= lo.dst;=0A+ msg->address_lo |=3D=0A+ (iremap_entry->lo.ds= t & 0xff) << MSI_ADDR_DEST_ID_SHIFT;=0A+ }=0A else=0A = msg->address_lo |=3D=0A ((iremap_entry->lo.dst >> 8) & 0xff ) = << MSI_ADDR_DEST_ID_SHIFT;=0A --=__Part0D3C3B5E.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --=__Part0D3C3B5E.0__=-- From xen-devel-bounces@lists.xen.org Tue Oct 02 14:56:31 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:56:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3tS-0000dj-Oq; Tue, 02 Oct 2012 14:56:18 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3tR-0000da-3k for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:56:17 +0000 Received: from [85.158.139.211:64807] by server-11.bemta-5.messagelabs.com id 26/DF-13866-0900B605; Tue, 02 Oct 2012 14:56:16 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-12.tower-206.messagelabs.com!1349189775!19780288!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23955 invoked from network); 2 Oct 2012 14:56:15 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 14:56:15 -0000 X-IronPort-AV: E=Sophos;i="4.80,523,1344211200"; d="scan'208";a="14896966" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 14:56:03 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 15:56:03 +0100 Message-ID: <1349189762.650.87.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= Date: Tue, 2 Oct 2012 15:56:02 +0100 In-Reply-To: <20121002145044.GQ8912@reaktio.net> References: <20121001164239.GE8912@reaktio.net> <20586.63875.490107.170343@mariner.uk.xensource.com> <1349188361.650.77.camel@zakaz.uk.xensource.com> <20121002145044.GQ8912@reaktio.net> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: George Dunlap , Ian Jackson , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Xen 4.3 development update X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org T24gVHVlLCAyMDEyLTEwLTAyIGF0IDE1OjUwICswMTAwLCBQYXNpIEvDpHJra8OkaW5lbiB3cm90 ZToKPiBPbiBUdWUsIE9jdCAwMiwgMjAxMiBhdCAwMzozMjo0MVBNICswMTAwLCBJYW4gQ2FtcGJl bGwgd3JvdGU6Cj4gPiAKPiA+ID4gPiAgKiB4bCBVU0IgcGFzcy10aHJvdWdoIGZvciBIVk0gZ3Vl c3RzIHVzaW5nIFFlbXUgVVNCIGVtdWxhdGlvbgo+ID4gPiA+ICAgIG93bmVyOiA/IAo+ID4gPiA+ ICAgIHN0YXR1czogPwo+ID4gPiA+ICAgIC0geG0veGVuZCB3aXRoIHFlbXUtdHJhZGl0aW9uYWwg c3VwcG9ydHMgVVNCIHBhc3N0aHJvdWdoIHRvIEhWTSBndWVzdHMgdXNpbmcgdGhlIFFlbXUgZW11 bGF0ZWQgVVNCIGNvbnRyb2xsZXIuCj4gPiA+ID4gICAgLSBwb3J0IHRoZSB4bS94ZW5kIGZ1bmN0 aW9uYWxpdHkgdG8geGwuCj4gPiA+ID4gICAgLSBtYWtlIHN1cmUgVVNCIHBhc3N0aHJvdWdoIHdp dGggeGwgd29ya3Mgd2l0aCBib3RoIHFlbXUtdHJhZGl0aW9uYWwgYW5kIHFlbXUtdXBzdHJlYW0u Cj4gPiA+ID4gICAgLSBUaGUgSFZNIGd1ZXN0IGRvZXMgbm90IG5lZWQgYW55IHNwZWNpYWwgZHJp dmVycyBmb3IgdGhpcyBmZWF0dXJlLgo+ID4gPiAKPiA+ID4gSSB0aGluayB0aGlzIGlzIGp1c3Qg YSBtYXR0ZXIgb2YgcGx1bWJpbmcgaW4gbGlieGwgKHByZXN1bWFibHksIG5vdywKPiA+ID4gcGx1 bWJpbmcgdG8gcWVtdS11cHN0cmVhbSkuCj4gPiAKPiA+IEFzc3VtaW5nIHFlbXUtdXBzdHJlYW0g aGFzIHRoZSBuZWNlc3NhcnkgZmVhdHVyZS4uLgo+ID4gCj4gCj4gWWVzLCBxZW11LXVwc3RyZWFt IHN1cHBvcnRzIGhvc3QgVVNCIGRldmljZSBwYXNzLXRocm91Z2guCj4gCj4gcmVmZXJlbmNlczoK PiBodHRwOi8vd3d3LmxpbnV4LWt2bS5vcmcvcGFnZS9VU0JfSG9zdF9EZXZpY2VfQXNzaWduZWRf dG9fR3Vlc3QKPiBodHRwOi8vZGF2aWQud3JhZ2cub3JnL2Jsb2cvMjAwOS8wMy91c2luZy11c2It cGFzcy10aHJvdWdoLXVuZGVyLWxpYnZpcnQuaHRtbAo+IGh0dHA6Ly9kYXZpZC53cmFnZy5vcmcv YmxvZy8yMDA5LzAzL3VzYi1wYXNzLXRocm91Z2gtd2l0aC1saWJ2aXJ0LWFuZC1rdm0uaHRtbAo+ IAo+IFNvIGJhc2ljbHkgdGhlIHFlbXUgY21kbGluZSBuZWVkcyB0byBoYXZlOgo+IC11c2IgLXVz YmRldmljZSBob3N0Onh4eHg6eXl5eQoKSWYgeW91IGRvIHRoaXMgdmlhIHhsJ3MgZGV2aWNlX21v ZGVsX2FyZ3M9IGNvbmZpZyBvcHRpb24gdGhlbiBkb2VzIHRoaXMKSnVzdCBXb3JrPwoKSWFuLgoK Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZl bCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== From xen-devel-bounces@lists.xen.org Tue Oct 02 14:56:31 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:56:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3tS-0000dj-Oq; Tue, 02 Oct 2012 14:56:18 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3tR-0000da-3k for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:56:17 +0000 Received: from [85.158.139.211:64807] by server-11.bemta-5.messagelabs.com id 26/DF-13866-0900B605; Tue, 02 Oct 2012 14:56:16 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-12.tower-206.messagelabs.com!1349189775!19780288!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23955 invoked from network); 2 Oct 2012 14:56:15 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 14:56:15 -0000 X-IronPort-AV: E=Sophos;i="4.80,523,1344211200"; d="scan'208";a="14896966" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 14:56:03 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 15:56:03 +0100 Message-ID: <1349189762.650.87.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= Date: Tue, 2 Oct 2012 15:56:02 +0100 In-Reply-To: <20121002145044.GQ8912@reaktio.net> References: <20121001164239.GE8912@reaktio.net> <20586.63875.490107.170343@mariner.uk.xensource.com> <1349188361.650.77.camel@zakaz.uk.xensource.com> <20121002145044.GQ8912@reaktio.net> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: George Dunlap , Ian Jackson , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Xen 4.3 development update X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org T24gVHVlLCAyMDEyLTEwLTAyIGF0IDE1OjUwICswMTAwLCBQYXNpIEvDpHJra8OkaW5lbiB3cm90 ZToKPiBPbiBUdWUsIE9jdCAwMiwgMjAxMiBhdCAwMzozMjo0MVBNICswMTAwLCBJYW4gQ2FtcGJl bGwgd3JvdGU6Cj4gPiAKPiA+ID4gPiAgKiB4bCBVU0IgcGFzcy10aHJvdWdoIGZvciBIVk0gZ3Vl c3RzIHVzaW5nIFFlbXUgVVNCIGVtdWxhdGlvbgo+ID4gPiA+ICAgIG93bmVyOiA/IAo+ID4gPiA+ ICAgIHN0YXR1czogPwo+ID4gPiA+ICAgIC0geG0veGVuZCB3aXRoIHFlbXUtdHJhZGl0aW9uYWwg c3VwcG9ydHMgVVNCIHBhc3N0aHJvdWdoIHRvIEhWTSBndWVzdHMgdXNpbmcgdGhlIFFlbXUgZW11 bGF0ZWQgVVNCIGNvbnRyb2xsZXIuCj4gPiA+ID4gICAgLSBwb3J0IHRoZSB4bS94ZW5kIGZ1bmN0 aW9uYWxpdHkgdG8geGwuCj4gPiA+ID4gICAgLSBtYWtlIHN1cmUgVVNCIHBhc3N0aHJvdWdoIHdp dGggeGwgd29ya3Mgd2l0aCBib3RoIHFlbXUtdHJhZGl0aW9uYWwgYW5kIHFlbXUtdXBzdHJlYW0u Cj4gPiA+ID4gICAgLSBUaGUgSFZNIGd1ZXN0IGRvZXMgbm90IG5lZWQgYW55IHNwZWNpYWwgZHJp dmVycyBmb3IgdGhpcyBmZWF0dXJlLgo+ID4gPiAKPiA+ID4gSSB0aGluayB0aGlzIGlzIGp1c3Qg YSBtYXR0ZXIgb2YgcGx1bWJpbmcgaW4gbGlieGwgKHByZXN1bWFibHksIG5vdywKPiA+ID4gcGx1 bWJpbmcgdG8gcWVtdS11cHN0cmVhbSkuCj4gPiAKPiA+IEFzc3VtaW5nIHFlbXUtdXBzdHJlYW0g aGFzIHRoZSBuZWNlc3NhcnkgZmVhdHVyZS4uLgo+ID4gCj4gCj4gWWVzLCBxZW11LXVwc3RyZWFt IHN1cHBvcnRzIGhvc3QgVVNCIGRldmljZSBwYXNzLXRocm91Z2guCj4gCj4gcmVmZXJlbmNlczoK PiBodHRwOi8vd3d3LmxpbnV4LWt2bS5vcmcvcGFnZS9VU0JfSG9zdF9EZXZpY2VfQXNzaWduZWRf dG9fR3Vlc3QKPiBodHRwOi8vZGF2aWQud3JhZ2cub3JnL2Jsb2cvMjAwOS8wMy91c2luZy11c2It cGFzcy10aHJvdWdoLXVuZGVyLWxpYnZpcnQuaHRtbAo+IGh0dHA6Ly9kYXZpZC53cmFnZy5vcmcv YmxvZy8yMDA5LzAzL3VzYi1wYXNzLXRocm91Z2gtd2l0aC1saWJ2aXJ0LWFuZC1rdm0uaHRtbAo+ IAo+IFNvIGJhc2ljbHkgdGhlIHFlbXUgY21kbGluZSBuZWVkcyB0byBoYXZlOgo+IC11c2IgLXVz YmRldmljZSBob3N0Onh4eHg6eXl5eQoKSWYgeW91IGRvIHRoaXMgdmlhIHhsJ3MgZGV2aWNlX21v ZGVsX2FyZ3M9IGNvbmZpZyBvcHRpb24gdGhlbiBkb2VzIHRoaXMKSnVzdCBXb3JrPwoKSWFuLgoK Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZl bCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== From xen-devel-bounces@lists.xen.org Tue Oct 02 14:57:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:57:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3u4-0000hu-Bc; Tue, 02 Oct 2012 14:56:56 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3u2-0000gy-FA for Xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:56:54 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1349189741!8480574!1 X-Originating-IP: [209.85.161.173] X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG, HTML_30_40, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26094 invoked from network); 2 Oct 2012 14:55:43 -0000 Received: from mail-gg0-f173.google.com (HELO mail-gg0-f173.google.com) (209.85.161.173) by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 14:55:43 -0000 Received: by ggcs5 with SMTP id s5so346276ggc.32 for ; Tue, 02 Oct 2012 07:55:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mh4aQ6xp6O3Q3PSnXer5b/SfY4JRtG3NYtFHtL+KXD0=; b=xYvjOS0IH7NhsHmNBjdV2b7gWNPGoEnxoCJCkWc5dIcwwNNWSamaiGsiJSoQMlptqY T6PSW18tbGmRBYwcYqr91H4OEC1cnr1obd2dyrH020B4Gcs+JM1QSm/fywpdxewbb4vg DKxgqJd7Bj+K3SpsEXZ3yIsrxYEhftit0EfIDggIgD7C7qMp84VLA5dcAbRN8c95ONAC PtR0bpsSyUibOPbCZWxJRWQz5+MFbzUFdg9p0gSYVk2q6i0I2Ha/Ds5t0MctuVejImcx SZVOQAOkMgHYTXzIgpmn6AtT+GZvVs+Ok1K8Fxk2x7DiQogdWMqozaQqnbfW0/zc2u47 OC+g== MIME-Version: 1.0 Received: by 10.101.141.40 with SMTP id t40mr5789698ann.77.1349189741110; Tue, 02 Oct 2012 07:55:41 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Tue, 2 Oct 2012 07:55:41 -0700 (PDT) In-Reply-To: <20121002144251.GP8912@reaktio.net> References: <20121001164757.GF8912@reaktio.net> <20121001182437.GG8912@reaktio.net> <20121002121932.GL8912@reaktio.net> <20121002144251.GP8912@reaktio.net> Date: Tue, 2 Oct 2012 17:55:41 +0300 Message-ID: From: Valtteri Kiviniemi To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= Cc: Konrad Rzeszutek Wilk , Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.0.4, kernel 3.5.0 HVM crash and kernel BUG X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5777695712422036436==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============5777695712422036436== Content-Type: multipart/alternative; boundary=0016e6d27c7d40e4da04cb14b7e1 --0016e6d27c7d40e4da04cb14b7e1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Yes, I understood for what the parameters were for. I'ts been a long time since I last had major problems with Xen (maybe 3.1 or something, been using Xen since version 2) and I had a shady recollection that Xen was required to be build debugging enabled in order to get any usable debugging data. But anyway, I cant reproduce that kernel crash everytime, it just happens sometimes. Major problem is the black screen on VNC and second problem seems to be that everytime i try to run Linux in HVM mode it somehow breaks the hotplug scripts. - Valtteri 2012/10/2 Pasi K=E4rkk=E4inen > On Tue, Oct 02, 2012 at 05:37:08PM +0300, Valtteri Kiviniemi wrote: > > Hi, > > > > Tried boogin with vif-parameters commented out, result is the same: > > > > Error: Device 768 (vbd) could not be connected. Hotplug scripts not > > working. > > > > But what is more troubling with these issues I'm having is the fact > that > > this "hotpluf scripts not working" came out of nowhere. I was able t= o > boot > > my Windows domU just fine earlier with only problem being that the V= NC > > output was just black screen after Windows installer had started. > Then I > > tried to create a Linux HVM (debian squeeze) and then I got that > "Hotplug > > scripts not working" error. And after trying to start Windows domU > again > > it says that same "Hotplug scripts not working" error. > > > > If I reboot the machine and start my Windows domU it will start agai= n > just > > fine, but the VNC output is just black screen. Then again, if I star= t > the > > Linux HVM domU I will again get that "Hotplug scripts not working" > error > > and then the Windows domU wont start either again and tells the same > > "Hotplug scripts not working" error. > > > > So this is pretty confusing and troubling indeed. > > > > I will reboot the machine later and put those boot parameters that > Pasi > > mentioned. > > > > My parameters were meant for the case where your server crashes, > to be able to get a proper boot and crash logs to analyze it. > > -- Pasi > > > > - Valtteri > > > > 2012/10/2 Konrad Rzeszutek Wilk <[1]konrad@kernel.org> > > > > On Tue, Oct 2, 2012 at 9:01 AM, Valtteri Kiviniemi > > <[2]kiviniemi.valtteri@gmail.com> wrote: > > > Hi, > > > > > > I already tried 3.2, 3.5, 3.5.0, 3.6.0-rc7 and 3.6.0, same > problem all > > of > > > those. My dom0 config is the same config that I'am using on othe= r > > server > > > where HVM is working, so I dont think that it is a config > problem. I > > have > > > triple checked everything and all should be ok. dom0 dmesg shows > the > > same > > > crash that I have previously posted here. /var/log/xen/ does not > > contain any > > > specific errors. > > > > > > Could this be some kind of broblem with my motherboard bios bein= g > > buggy or > > > CPU not supported? I'm using the new intel Ivy Bridge processor > which > > has > > > integrated GPU, but that should not probably cause these kind of > > problems. > > > Or maybe some ACPI problem? xm dmesg is showing some notices abo= ut > > ACPI. Is > > > there any ACPI kernel parameters that I should try booting? This > has > > to be > > > somekind of problem with my hardware, or then maybe it could be = a > > kernel > > > problem too. I just really cant figure this out myself, I have > tried > > > everything. > > > > > > Lets take a quick summary of what has been tested, what hardware > I'm > > using > > > etc. > > > > > > Xen-versions tested: 4.2.0, 4.0.4 > > > Kernel-versions tested: 3.2.0, 3.5.0, 3.5.4, 3.6.0-rc7, 3.6.0 > > > > > > Host OS: Debian testing/wheezy, udev version 175-7, 2.13-35, > python > > version > > > 2.7.3~rc2-2.1 > > > > > > Hardware: > > > > > > CPU: Intel Core i7-3770 3.4GHz > > > MB: Intel DQ77MK (latest bios updated) > > > Memory: 32GB (4 x 8GB DDR3-1600MHz) > > > > > > All relevant log files and configs: > > > > > > dom0 dmesg: [3]http://nago.fi/dmesg.txt > > > qemu-dm log: [4]http://nago.fi/qemu-dm.txt > > > xm dmesg log: [5]http://nago.fi/xm-dmesg.txt > > > domU config: [6]http://nago.fi/domu-config.txt > > > dom0 kernel config: [7]http://nago.fi/dom0-config.txt > > > > > > I have also tried playing with every setting on that domU that I > can > > think > > > of and tried different configs etc. > > > > This is troubling. You seem to trigger the QEMU closing the tunX > (your > > Windows's guest network interface) which then crashes somehow. > > Just to make sure that this is the case - can you try launching yo= ur > > guest without network and seeing what happens? > > > > References > > > > Visible links > > 1. mailto:konrad@kernel.org > > 2. mailto:kiviniemi.valtteri@gmail.com > > 3. http://nago.fi/dmesg.txt > > 4. http://nago.fi/qemu-dm.txt > > 5. http://nago.fi/xm-dmesg.txt > > 6. http://nago.fi/domu-config.txt > > 7. http://nago.fi/dom0-config.txt > --0016e6d27c7d40e4da04cb14b7e1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Yes, I understood for what the parameters were for. I'ts bee= n a long time since I last had major problems with Xen (maybe 3.1 or someth= ing, been using Xen since version 2) and I had a shady recollection that Xe= n was required to be build debugging enabled in order to get any usable deb= ugging data.

But anyway, I cant reproduce that kernel crash everytime, it just happe= ns sometimes. Major problem is the black screen on VNC and second problem s= eems to be that everytime i try to run Linux in HVM mode it somehow breaks = the hotplug scripts.

- Valtteri

2012/10/2 Pasi K=E4rkk=E4= inen <pasik@iki.fi>
On Tue, Oct 02, 2012 at 05:37:08PM +0300, Valtteri Kivini= emi wrote:
> =A0 =A0Hi,
>
> =A0 =A0Tried boogin with vif-parameters commented out, result is the s= ame:
>
> =A0 =A0Error: Device 768 (vbd) could not be connected. Hotplug scripts= not
> =A0 =A0working.
>
> =A0 =A0But what is more troubling with these issues I'm having is = the fact that
> =A0 =A0this "hotpluf scripts not working" came out of nowher= e. I was able to boot
> =A0 =A0my Windows domU just fine earlier with only problem being that = the VNC
> =A0 =A0output was just black screen after Windows installer had starte= d. Then I
> =A0 =A0tried to create a Linux HVM (debian squeeze) and then I got tha= t "Hotplug
> =A0 =A0scripts not working" error. And after trying to start Wind= ows domU again
> =A0 =A0it says that same "Hotplug scripts not working" error= .
>
> =A0 =A0If I reboot the machine and start my Windows domU it will start= again just
> =A0 =A0fine, but the VNC output is just black screen. Then again, if I= start the
> =A0 =A0Linux HVM domU I will again get that "Hotplug scripts not = working" error
> =A0 =A0and then the Windows domU wont start either again and tells the= same
> =A0 =A0"Hotplug scripts not working" error.
>
> =A0 =A0So this is pretty confusing and troubling indeed.
>
> =A0 =A0I will reboot the machine later and put those boot parameters t= hat Pasi
> =A0 =A0mentioned.
>

My parameters were meant for the case where your server crashes,
to be able to get a proper boot and crash logs to analyze it.

-- Pasi


> =A0 =A0- Valtteri
>
> =A0 =A02012/10/2 Konrad Rzeszutek Wilk <[1]konrad@kernel.org>
>
> =A0 =A0 =A0On Tue, Oct 2, 2012 at 9:01 AM, Valtteri Kiviniemi
> =A0 =A0 =A0<[2]kiviniemi.valtteri@gmail.com> wrote:
> =A0 =A0 =A0> Hi,
> =A0 =A0 =A0>
> =A0 =A0 =A0> I already tried 3.2, 3.5, 3.5.0, 3.6.0-rc7 and 3.6.0, = same problem all
> =A0 =A0 =A0of
> =A0 =A0 =A0> those. My dom0 config is the same config that I'am= using on other
> =A0 =A0 =A0server
> =A0 =A0 =A0> where HVM is working, so I dont think that it is a con= fig problem. I
> =A0 =A0 =A0have
> =A0 =A0 =A0> triple checked everything and all should be ok. dom0 d= mesg shows the
> =A0 =A0 =A0same
> =A0 =A0 =A0> crash that I have previously posted here. /var/log/xen= / does not
> =A0 =A0 =A0contain any
> =A0 =A0 =A0> specific errors.
> =A0 =A0 =A0>
> =A0 =A0 =A0> Could this be some kind of broblem with my motherboard= bios being
> =A0 =A0 =A0buggy or
> =A0 =A0 =A0> CPU not supported? I'm using the new intel Ivy Bri= dge processor which
> =A0 =A0 =A0has
> =A0 =A0 =A0> integrated GPU, but that should not probably cause the= se kind of
> =A0 =A0 =A0problems.
> =A0 =A0 =A0> Or maybe some ACPI problem? xm dmesg is showing some n= otices about
> =A0 =A0 =A0ACPI. Is
> =A0 =A0 =A0> there any ACPI kernel parameters that I should try boo= ting? This has
> =A0 =A0 =A0to be
> =A0 =A0 =A0> somekind of problem with my hardware, or then maybe it= could be a
> =A0 =A0 =A0kernel
> =A0 =A0 =A0> problem too. I just really cant figure this out myself= , I have tried
> =A0 =A0 =A0> everything.
> =A0 =A0 =A0>
> =A0 =A0 =A0> Lets take a quick summary of what has been tested, wha= t hardware I'm
> =A0 =A0 =A0using
> =A0 =A0 =A0> etc.
> =A0 =A0 =A0>
> =A0 =A0 =A0> Xen-versions tested: 4.2.0, 4.0.4
> =A0 =A0 =A0> Kernel-versions tested: 3.2.0, 3.5.0, 3.5.4, 3.6.0-rc7= , 3.6.0
> =A0 =A0 =A0>
> =A0 =A0 =A0> Host OS: Debian testing/wheezy, udev version 175-7, 2.= 13-35, python
> =A0 =A0 =A0version
> =A0 =A0 =A0> 2.7.3~rc2-2.1
> =A0 =A0 =A0>
> =A0 =A0 =A0> Hardware:
> =A0 =A0 =A0>
> =A0 =A0 =A0> CPU: Intel Core i7-3770 3.4GHz
> =A0 =A0 =A0> MB: Intel DQ77MK (latest bios updated)
> =A0 =A0 =A0> Memory: 32GB (4 x 8GB DDR3-1600MHz)
> =A0 =A0 =A0>
> =A0 =A0 =A0> All relevant log files and configs:
> =A0 =A0 =A0>
> =A0 =A0 =A0> dom0 dmesg: [3]http://nago.fi/dmesg.txt
> =A0 =A0 =A0> qemu-dm log: [4]http://nago.fi/qemu-dm.txt
> =A0 =A0 =A0> xm dmesg log: [5]http://nago.fi/xm-dmesg.txt
> =A0 =A0 =A0> domU config: [6]http://nago.fi/domu-config.txt
> =A0 =A0 =A0> dom0 kernel config: [7]http://nago.fi/dom0-config.txt
> =A0 =A0 =A0>
> =A0 =A0 =A0> I have also tried playing with every setting on that d= omU that I can
> =A0 =A0 =A0think
> =A0 =A0 =A0> of and tried different configs etc.
>
> =A0 =A0 =A0This is troubling. You seem to trigger the QEMU closing the= tunX (your
> =A0 =A0 =A0Windows's guest network interface) which then crashes s= omehow.
> =A0 =A0 =A0Just to make sure that this is the case - can you try launc= hing your
> =A0 =A0 =A0guest without network and seeing what happens?
>
> References
>
> =A0 =A0Visible links
> =A0 =A01. mailto:konrad@kernel.or= g
> =A0 =A02. mailto:kivin= iemi.valtteri@gmail.com
> =A0 =A03. http:= //nago.fi/dmesg.txt
> =A0 =A04. htt= p://nago.fi/qemu-dm.txt
> =A0 =A05. ht= tp://nago.fi/xm-dmesg.txt
> =A0 =A06. http://nago.fi/domu-config.txt
> =A0 =A07. http://nago.fi/dom0-config.txt

--0016e6d27c7d40e4da04cb14b7e1-- --===============5777695712422036436== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============5777695712422036436==-- From xen-devel-bounces@lists.xen.org Tue Oct 02 14:57:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:57:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3u4-0000hu-Bc; Tue, 02 Oct 2012 14:56:56 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3u2-0000gy-FA for Xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:56:54 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1349189741!8480574!1 X-Originating-IP: [209.85.161.173] X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG, HTML_30_40, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26094 invoked from network); 2 Oct 2012 14:55:43 -0000 Received: from mail-gg0-f173.google.com (HELO mail-gg0-f173.google.com) (209.85.161.173) by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 14:55:43 -0000 Received: by ggcs5 with SMTP id s5so346276ggc.32 for ; Tue, 02 Oct 2012 07:55:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mh4aQ6xp6O3Q3PSnXer5b/SfY4JRtG3NYtFHtL+KXD0=; b=xYvjOS0IH7NhsHmNBjdV2b7gWNPGoEnxoCJCkWc5dIcwwNNWSamaiGsiJSoQMlptqY T6PSW18tbGmRBYwcYqr91H4OEC1cnr1obd2dyrH020B4Gcs+JM1QSm/fywpdxewbb4vg DKxgqJd7Bj+K3SpsEXZ3yIsrxYEhftit0EfIDggIgD7C7qMp84VLA5dcAbRN8c95ONAC PtR0bpsSyUibOPbCZWxJRWQz5+MFbzUFdg9p0gSYVk2q6i0I2Ha/Ds5t0MctuVejImcx SZVOQAOkMgHYTXzIgpmn6AtT+GZvVs+Ok1K8Fxk2x7DiQogdWMqozaQqnbfW0/zc2u47 OC+g== MIME-Version: 1.0 Received: by 10.101.141.40 with SMTP id t40mr5789698ann.77.1349189741110; Tue, 02 Oct 2012 07:55:41 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Tue, 2 Oct 2012 07:55:41 -0700 (PDT) In-Reply-To: <20121002144251.GP8912@reaktio.net> References: <20121001164757.GF8912@reaktio.net> <20121001182437.GG8912@reaktio.net> <20121002121932.GL8912@reaktio.net> <20121002144251.GP8912@reaktio.net> Date: Tue, 2 Oct 2012 17:55:41 +0300 Message-ID: From: Valtteri Kiviniemi To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= Cc: Konrad Rzeszutek Wilk , Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.0.4, kernel 3.5.0 HVM crash and kernel BUG X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5777695712422036436==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============5777695712422036436== Content-Type: multipart/alternative; boundary=0016e6d27c7d40e4da04cb14b7e1 --0016e6d27c7d40e4da04cb14b7e1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Yes, I understood for what the parameters were for. I'ts been a long time since I last had major problems with Xen (maybe 3.1 or something, been using Xen since version 2) and I had a shady recollection that Xen was required to be build debugging enabled in order to get any usable debugging data. But anyway, I cant reproduce that kernel crash everytime, it just happens sometimes. Major problem is the black screen on VNC and second problem seems to be that everytime i try to run Linux in HVM mode it somehow breaks the hotplug scripts. - Valtteri 2012/10/2 Pasi K=E4rkk=E4inen > On Tue, Oct 02, 2012 at 05:37:08PM +0300, Valtteri Kiviniemi wrote: > > Hi, > > > > Tried boogin with vif-parameters commented out, result is the same: > > > > Error: Device 768 (vbd) could not be connected. Hotplug scripts not > > working. > > > > But what is more troubling with these issues I'm having is the fact > that > > this "hotpluf scripts not working" came out of nowhere. I was able t= o > boot > > my Windows domU just fine earlier with only problem being that the V= NC > > output was just black screen after Windows installer had started. > Then I > > tried to create a Linux HVM (debian squeeze) and then I got that > "Hotplug > > scripts not working" error. And after trying to start Windows domU > again > > it says that same "Hotplug scripts not working" error. > > > > If I reboot the machine and start my Windows domU it will start agai= n > just > > fine, but the VNC output is just black screen. Then again, if I star= t > the > > Linux HVM domU I will again get that "Hotplug scripts not working" > error > > and then the Windows domU wont start either again and tells the same > > "Hotplug scripts not working" error. > > > > So this is pretty confusing and troubling indeed. > > > > I will reboot the machine later and put those boot parameters that > Pasi > > mentioned. > > > > My parameters were meant for the case where your server crashes, > to be able to get a proper boot and crash logs to analyze it. > > -- Pasi > > > > - Valtteri > > > > 2012/10/2 Konrad Rzeszutek Wilk <[1]konrad@kernel.org> > > > > On Tue, Oct 2, 2012 at 9:01 AM, Valtteri Kiviniemi > > <[2]kiviniemi.valtteri@gmail.com> wrote: > > > Hi, > > > > > > I already tried 3.2, 3.5, 3.5.0, 3.6.0-rc7 and 3.6.0, same > problem all > > of > > > those. My dom0 config is the same config that I'am using on othe= r > > server > > > where HVM is working, so I dont think that it is a config > problem. I > > have > > > triple checked everything and all should be ok. dom0 dmesg shows > the > > same > > > crash that I have previously posted here. /var/log/xen/ does not > > contain any > > > specific errors. > > > > > > Could this be some kind of broblem with my motherboard bios bein= g > > buggy or > > > CPU not supported? I'm using the new intel Ivy Bridge processor > which > > has > > > integrated GPU, but that should not probably cause these kind of > > problems. > > > Or maybe some ACPI problem? xm dmesg is showing some notices abo= ut > > ACPI. Is > > > there any ACPI kernel parameters that I should try booting? This > has > > to be > > > somekind of problem with my hardware, or then maybe it could be = a > > kernel > > > problem too. I just really cant figure this out myself, I have > tried > > > everything. > > > > > > Lets take a quick summary of what has been tested, what hardware > I'm > > using > > > etc. > > > > > > Xen-versions tested: 4.2.0, 4.0.4 > > > Kernel-versions tested: 3.2.0, 3.5.0, 3.5.4, 3.6.0-rc7, 3.6.0 > > > > > > Host OS: Debian testing/wheezy, udev version 175-7, 2.13-35, > python > > version > > > 2.7.3~rc2-2.1 > > > > > > Hardware: > > > > > > CPU: Intel Core i7-3770 3.4GHz > > > MB: Intel DQ77MK (latest bios updated) > > > Memory: 32GB (4 x 8GB DDR3-1600MHz) > > > > > > All relevant log files and configs: > > > > > > dom0 dmesg: [3]http://nago.fi/dmesg.txt > > > qemu-dm log: [4]http://nago.fi/qemu-dm.txt > > > xm dmesg log: [5]http://nago.fi/xm-dmesg.txt > > > domU config: [6]http://nago.fi/domu-config.txt > > > dom0 kernel config: [7]http://nago.fi/dom0-config.txt > > > > > > I have also tried playing with every setting on that domU that I > can > > think > > > of and tried different configs etc. > > > > This is troubling. You seem to trigger the QEMU closing the tunX > (your > > Windows's guest network interface) which then crashes somehow. > > Just to make sure that this is the case - can you try launching yo= ur > > guest without network and seeing what happens? > > > > References > > > > Visible links > > 1. mailto:konrad@kernel.org > > 2. mailto:kiviniemi.valtteri@gmail.com > > 3. http://nago.fi/dmesg.txt > > 4. http://nago.fi/qemu-dm.txt > > 5. http://nago.fi/xm-dmesg.txt > > 6. http://nago.fi/domu-config.txt > > 7. http://nago.fi/dom0-config.txt > --0016e6d27c7d40e4da04cb14b7e1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Yes, I understood for what the parameters were for. I'ts bee= n a long time since I last had major problems with Xen (maybe 3.1 or someth= ing, been using Xen since version 2) and I had a shady recollection that Xe= n was required to be build debugging enabled in order to get any usable deb= ugging data.

But anyway, I cant reproduce that kernel crash everytime, it just happe= ns sometimes. Major problem is the black screen on VNC and second problem s= eems to be that everytime i try to run Linux in HVM mode it somehow breaks = the hotplug scripts.

- Valtteri

2012/10/2 Pasi K=E4rkk=E4= inen <pasik@iki.fi>
On Tue, Oct 02, 2012 at 05:37:08PM +0300, Valtteri Kivini= emi wrote:
> =A0 =A0Hi,
>
> =A0 =A0Tried boogin with vif-parameters commented out, result is the s= ame:
>
> =A0 =A0Error: Device 768 (vbd) could not be connected. Hotplug scripts= not
> =A0 =A0working.
>
> =A0 =A0But what is more troubling with these issues I'm having is = the fact that
> =A0 =A0this "hotpluf scripts not working" came out of nowher= e. I was able to boot
> =A0 =A0my Windows domU just fine earlier with only problem being that = the VNC
> =A0 =A0output was just black screen after Windows installer had starte= d. Then I
> =A0 =A0tried to create a Linux HVM (debian squeeze) and then I got tha= t "Hotplug
> =A0 =A0scripts not working" error. And after trying to start Wind= ows domU again
> =A0 =A0it says that same "Hotplug scripts not working" error= .
>
> =A0 =A0If I reboot the machine and start my Windows domU it will start= again just
> =A0 =A0fine, but the VNC output is just black screen. Then again, if I= start the
> =A0 =A0Linux HVM domU I will again get that "Hotplug scripts not = working" error
> =A0 =A0and then the Windows domU wont start either again and tells the= same
> =A0 =A0"Hotplug scripts not working" error.
>
> =A0 =A0So this is pretty confusing and troubling indeed.
>
> =A0 =A0I will reboot the machine later and put those boot parameters t= hat Pasi
> =A0 =A0mentioned.
>

My parameters were meant for the case where your server crashes,
to be able to get a proper boot and crash logs to analyze it.

-- Pasi


> =A0 =A0- Valtteri
>
> =A0 =A02012/10/2 Konrad Rzeszutek Wilk <[1]konrad@kernel.org>
>
> =A0 =A0 =A0On Tue, Oct 2, 2012 at 9:01 AM, Valtteri Kiviniemi
> =A0 =A0 =A0<[2]kiviniemi.valtteri@gmail.com> wrote:
> =A0 =A0 =A0> Hi,
> =A0 =A0 =A0>
> =A0 =A0 =A0> I already tried 3.2, 3.5, 3.5.0, 3.6.0-rc7 and 3.6.0, = same problem all
> =A0 =A0 =A0of
> =A0 =A0 =A0> those. My dom0 config is the same config that I'am= using on other
> =A0 =A0 =A0server
> =A0 =A0 =A0> where HVM is working, so I dont think that it is a con= fig problem. I
> =A0 =A0 =A0have
> =A0 =A0 =A0> triple checked everything and all should be ok. dom0 d= mesg shows the
> =A0 =A0 =A0same
> =A0 =A0 =A0> crash that I have previously posted here. /var/log/xen= / does not
> =A0 =A0 =A0contain any
> =A0 =A0 =A0> specific errors.
> =A0 =A0 =A0>
> =A0 =A0 =A0> Could this be some kind of broblem with my motherboard= bios being
> =A0 =A0 =A0buggy or
> =A0 =A0 =A0> CPU not supported? I'm using the new intel Ivy Bri= dge processor which
> =A0 =A0 =A0has
> =A0 =A0 =A0> integrated GPU, but that should not probably cause the= se kind of
> =A0 =A0 =A0problems.
> =A0 =A0 =A0> Or maybe some ACPI problem? xm dmesg is showing some n= otices about
> =A0 =A0 =A0ACPI. Is
> =A0 =A0 =A0> there any ACPI kernel parameters that I should try boo= ting? This has
> =A0 =A0 =A0to be
> =A0 =A0 =A0> somekind of problem with my hardware, or then maybe it= could be a
> =A0 =A0 =A0kernel
> =A0 =A0 =A0> problem too. I just really cant figure this out myself= , I have tried
> =A0 =A0 =A0> everything.
> =A0 =A0 =A0>
> =A0 =A0 =A0> Lets take a quick summary of what has been tested, wha= t hardware I'm
> =A0 =A0 =A0using
> =A0 =A0 =A0> etc.
> =A0 =A0 =A0>
> =A0 =A0 =A0> Xen-versions tested: 4.2.0, 4.0.4
> =A0 =A0 =A0> Kernel-versions tested: 3.2.0, 3.5.0, 3.5.4, 3.6.0-rc7= , 3.6.0
> =A0 =A0 =A0>
> =A0 =A0 =A0> Host OS: Debian testing/wheezy, udev version 175-7, 2.= 13-35, python
> =A0 =A0 =A0version
> =A0 =A0 =A0> 2.7.3~rc2-2.1
> =A0 =A0 =A0>
> =A0 =A0 =A0> Hardware:
> =A0 =A0 =A0>
> =A0 =A0 =A0> CPU: Intel Core i7-3770 3.4GHz
> =A0 =A0 =A0> MB: Intel DQ77MK (latest bios updated)
> =A0 =A0 =A0> Memory: 32GB (4 x 8GB DDR3-1600MHz)
> =A0 =A0 =A0>
> =A0 =A0 =A0> All relevant log files and configs:
> =A0 =A0 =A0>
> =A0 =A0 =A0> dom0 dmesg: [3]http://nago.fi/dmesg.txt
> =A0 =A0 =A0> qemu-dm log: [4]http://nago.fi/qemu-dm.txt
> =A0 =A0 =A0> xm dmesg log: [5]http://nago.fi/xm-dmesg.txt
> =A0 =A0 =A0> domU config: [6]http://nago.fi/domu-config.txt
> =A0 =A0 =A0> dom0 kernel config: [7]http://nago.fi/dom0-config.txt
> =A0 =A0 =A0>
> =A0 =A0 =A0> I have also tried playing with every setting on that d= omU that I can
> =A0 =A0 =A0think
> =A0 =A0 =A0> of and tried different configs etc.
>
> =A0 =A0 =A0This is troubling. You seem to trigger the QEMU closing the= tunX (your
> =A0 =A0 =A0Windows's guest network interface) which then crashes s= omehow.
> =A0 =A0 =A0Just to make sure that this is the case - can you try launc= hing your
> =A0 =A0 =A0guest without network and seeing what happens?
>
> References
>
> =A0 =A0Visible links
> =A0 =A01. mailto:konrad@kernel.or= g
> =A0 =A02. mailto:kivin= iemi.valtteri@gmail.com
> =A0 =A03. http:= //nago.fi/dmesg.txt
> =A0 =A04. htt= p://nago.fi/qemu-dm.txt
> =A0 =A05. ht= tp://nago.fi/xm-dmesg.txt
> =A0 =A06. http://nago.fi/domu-config.txt
> =A0 =A07. http://nago.fi/dom0-config.txt

--0016e6d27c7d40e4da04cb14b7e1-- --===============5777695712422036436== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============5777695712422036436==-- From xen-devel-bounces@lists.xen.org Tue Oct 02 14:59:05 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:59:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3vv-0000tv-TZ; Tue, 02 Oct 2012 14:58:51 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3vu-0000tZ-DD for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:58:51 +0000 Received: from [85.158.143.35:48062] by server-1.bemta-4.messagelabs.com id 4A/61-05684-9210B605; Tue, 02 Oct 2012 14:58:49 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-10.tower-21.messagelabs.com!1349189922!11328621!1 X-Originating-IP: [128.244.251.37] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21192 invoked from network); 2 Oct 2012 14:58:43 -0000 Received: from piper.jhuapl.edu (HELO jhuapl.edu) (128.244.251.37) by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 14:58:43 -0000 Received: from ([128.244.207.97]) by piper.jhuapl.edu with ESMTP with TLS id 5Y8HCH1.145948028; Tue, 02 Oct 2012 10:58:16 -0400 From: Matthew Fioravante To: xen-devel@lists.xen.org, samuel.thibault@ens-lyon.org, Ian.Campbell@citrix.com Date: Tue, 2 Oct 2012 10:58:23 -0400 Message-Id: <1349189903-17524-1-git-send-email-matthew.fioravante@jhuapl.edu> X-Mailer: git-send-email 1.7.4.4 Cc: Matthew Fioravante Subject: [Xen-devel] [PATCH 08/12] add tpmfront, tpm_tis, and tpmback drivers to mini-os X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch adds 3 new drivers to mini-os. tpmfront - paravirtualized tpm frontend driver tpmback - paravirtualized tpm backend driver tpm_tis - hardware tpm driver Unfortunately these drivers were derived from GPL licensed linux kernel drivers so they must carry the GPL license. However, since mini-os now supports conditional compilation, hopefully these drivers can be included into the xen tree and conditionally removed from non-gpl projects. By default they are disabled in the makefile. Signed-off-by: Matthew Fioravante --- Changes since last: * Fixed incorrect license text diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile index 2422db3..2302a23 100644 --- a/extras/mini-os/Makefile +++ b/extras/mini-os/Makefile @@ -22,6 +22,9 @@ CONFIG_QEMU_XS_ARGS ?= n CONFIG_TEST ?= n CONFIG_PCIFRONT ?= n CONFIG_BLKFRONT ?= y +CONFIG_TPMFRONT ?= n +CONFIG_TPM_TIS ?= n +CONFIG_TPMBACK ?= n CONFIG_NETFRONT ?= y CONFIG_FBFRONT ?= y CONFIG_KBDFRONT ?= y @@ -36,6 +39,9 @@ flags-$(CONFIG_SPARSE_BSS) += -DCONFIG_SPARSE_BSS flags-$(CONFIG_QEMU_XS_ARGS) += -DCONFIG_QEMU_XS_ARGS flags-$(CONFIG_PCIFRONT) += -DCONFIG_PCIFRONT flags-$(CONFIG_BLKFRONT) += -DCONFIG_BLKFRONT +flags-$(CONFIG_TPMFRONT) += -DCONFIG_TPMFRONT +flags-$(CONFIG_TPM_TIS) += -DCONFIG_TPM_TIS +flags-$(CONFIG_TPMBACK) += -DCONFIG_TPMBACK flags-$(CONFIG_NETFRONT) += -DCONFIG_NETFRONT flags-$(CONFIG_KBDFRONT) += -DCONFIG_KBDFRONT flags-$(CONFIG_FBFRONT) += -DCONFIG_FBFRONT @@ -67,6 +73,9 @@ TARGET := mini-os SUBDIRS := lib xenbus console src-$(CONFIG_BLKFRONT) += blkfront.c +src-$(CONFIG_TPMFRONT) += tpmfront.c +src-$(CONFIG_TPM_TIS) += tpm_tis.c +src-$(CONFIG_TPMBACK) += tpmback.c src-y += daytime.c src-y += events.c src-$(CONFIG_FBFRONT) += fbfront.c diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h index d4641b6..935bede 100644 --- a/extras/mini-os/include/lib.h +++ b/extras/mini-os/include/lib.h @@ -142,6 +142,8 @@ enum fd_type { FTYPE_FB, FTYPE_MEM, FTYPE_SAVEFILE, + FTYPE_TPMFRONT, + FTYPE_TPM_TIS, }; LIST_HEAD(evtchn_port_list, evtchn_port_info); @@ -185,6 +187,20 @@ extern struct file { struct { struct consfront_dev *dev; } cons; +#ifdef CONFIG_TPMFRONT + struct { + struct tpmfront_dev *dev; + int respgot; + off_t offset; + } tpmfront; +#endif +#ifdef CONFIG_TPM_TIS + struct { + struct tpm_chip *dev; + int respgot; + off_t offset; + } tpm_tis; +#endif #ifdef CONFIG_XENBUS struct { /* To each xenbus FD is associated a queue of watch events for this diff --git a/extras/mini-os/include/tpm_tis.h b/extras/mini-os/include/tpm_tis.h new file mode 100644 index 0000000..a076a70 --- /dev/null +++ b/extras/mini-os/include/tpm_tis.h @@ -0,0 +1,64 @@ +/* + * Copyright (c) 2010-2012 United States Government, as represented by + * the Secretary of Defense. All rights reserved. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version 2 + * of the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + * + * Based upon the files: + * drivers/char/tpm/tpm_tis.c + * drivers/char/tpm/tpm.c + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation + */ +#ifndef TPM_TIS_H +#define TPM_TIS_H + +#include +#include + +#define TPM_TIS_EN_LOCL0 1 +#define TPM_TIS_EN_LOCL1 (1 << 1) +#define TPM_TIS_EN_LOCL2 (1 << 2) +#define TPM_TIS_EN_LOCL3 (1 << 3) +#define TPM_TIS_EN_LOCL4 (1 << 4) +#define TPM_TIS_EN_LOCLALL (TPM_TIS_EN_LOCL0 | TPM_TIS_EN_LOCL1 | TPM_TIS_EN_LOCL2 | TPM_TIS_EN_LOCL3 | TPM_TIS_EN_LOCL4) +#define TPM_TIS_LOCL_INT_TO_FLAG(x) (1 << x) +#define TPM_BASEADDR 0xFED40000 +#define TPM_PROBE_IRQ 0xFFFF + +struct tpm_chip; + +struct tpm_chip* init_tpm_tis(unsigned long baseaddr, int localities, unsigned int irq); +void shutdown_tpm_tis(struct tpm_chip* tpm); + +int tpm_tis_request_locality(struct tpm_chip* tpm, int locality); +int tpm_tis_cmd(struct tpm_chip* tpm, uint8_t* req, size_t reqlen, uint8_t** resp, size_t* resplen); + +#ifdef HAVE_LIBC +#include +#include +/* POSIX IO functions: + * use tpm_tis_open() to get a file descriptor to the tpm device + * use write() on the fd to send a command to the backend. You must + * include the entire command in a single call to write(). + * use read() on the fd to read the response. You can use + * fstat() to get the size of the response and lseek() to seek on it. + */ +int tpm_tis_open(struct tpm_chip* tpm); +int tpm_tis_posix_read(int fd, uint8_t* buf, size_t count); +int tpm_tis_posix_write(int fd, const uint8_t* buf, size_t count); +int tpm_tis_posix_fstat(int fd, struct stat* buf); +#endif + +#endif diff --git a/extras/mini-os/include/tpmback.h b/extras/mini-os/include/tpmback.h new file mode 100644 index 0000000..4315e55 --- /dev/null +++ b/extras/mini-os/include/tpmback.h @@ -0,0 +1,96 @@ +/* + * Copyright (c) 2010-2012 United States Government, as represented by + * the Secretary of Defense. All rights reserved. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version 2 + * of the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + * + * Based upon the files: + * drivers/xen/tpmbk.c + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation + */ +#include +#include +#include +#include +#ifndef TPMBACK_H +#define TPMBACK_H + +struct tpmcmd { + domid_t domid; /* Domid of the frontend */ + unsigned int handle; /* Handle of the frontend */ + char* uuid; /* uuid of the tpm interface - allocated internally, dont free it */ + + unsigned int req_len; /* Size of the command in buf - set by tpmback driver */ + uint8_t* req; /* tpm command bits, allocated by driver, DON'T FREE IT */ + unsigned int resp_len; /* Size of the outgoing command, + you set this before passing the cmd object to tpmback_resp */ + uint8_t* resp; /* Buffer for response - YOU MUST ALLOCATE IT, YOU MUST ALSO FREE IT */ +}; +typedef struct tpmcmd tpmcmd_t; + +/* Initialize the tpm backend driver + * @exclusive_domname - This is NULL terminated list of vtpm uuid strings. If this list + * is non-empty, then only frontend domains with vtpm uuid's matching + * entries in this list will be allowed to connect. + * Other connections will be immediatly closed. + * Set this argument to NULL to allow any vtpm to connect. + */ +void init_tpmback(char** exclusive_uuids); +/* Shutdown tpm backend driver */ +void shutdown_tpmback(void); + +/* Blocks until a tpm command is sent from any front end. + * Returns a pointer to the tpm command to handle. + * Do not try to free this pointer or the req buffer + * This function will return NULL if the tpm backend driver + * is shutdown or any other error occurs */ +tpmcmd_t* tpmback_req_any(void); + +/* Blocks until a tpm command from the frontend at domid/handle + * is sent. + * Returns NULL if domid/handle is not connected, tpmback is + * shutdown or shutting down, or if there is an error + */ +tpmcmd_t* tpmback_req(domid_t domid, unsigned int handle); + +/* Send the response to the tpm command back to the frontend + * This function will free the tpmcmd object, but you must free the resp + * buffer yourself */ +void tpmback_resp(tpmcmd_t* tpmcmd); + +/* Waits for the first frontend to connect and then sets domid and handle appropriately. + * If one or more frontends are already connected, this will set domid and handle to one + * of them arbitrarily. The main use for this function is to wait until a single + * frontend connection has occured. + * returns 0 on success, non-zero on failure */ +int tpmback_wait_for_frontend_connect(domid_t *domid, unsigned int *handle); + +/* returns the number of frontends connected */ +int tpmback_num_frontends(void); + +/* Returns the uuid of the specified frontend, NULL on error */ +char* tpmback_get_uuid(domid_t domid, unsigned int handle); + +/* Specify a function to call when a new tpm device connects */ +void tpmback_set_open_callback(void (*cb)(domid_t, unsigned int)); + +/* Specify a function to call when a tpm device disconnects */ +void tpmback_set_close_callback(void (*cb)(domid_t, unsigned int)); + +//Not Implemented +void tpmback_set_suspend_callback(void (*cb)(domid_t, unsigned int)); +void tpmback_set_resume_callback(void (*cb)(domid_t, unsigned int)); + +#endif diff --git a/extras/mini-os/include/tpmfront.h b/extras/mini-os/include/tpmfront.h new file mode 100644 index 0000000..7e3d357 --- /dev/null +++ b/extras/mini-os/include/tpmfront.h @@ -0,0 +1,97 @@ +/* + * Copyright (c) 2010-2012 United States Government, as represented by + * the Secretary of Defense. All rights reserved. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version 2 + * of the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + * + + * + * Based upon the files: + * drivers/char/tpm/tpm_vtpm.c + * drivers/char/tpm/tpm_xen.c + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation + */ +#ifndef TPMFRONT_H +#define TPMFRONT_H + +#include +#include +#include +#include +#include +#include +#include + +struct tpmfront_dev { + grant_ref_t ring_ref; + evtchn_port_t evtchn; + + tpmif_tx_interface_t* tx; + + void** pages; + + domid_t bedomid; + char* nodename; + char* bepath; + + XenbusState state; + + uint8_t waiting; + struct wait_queue_head waitq; + + uint8_t* respbuf; + size_t resplen; + +#ifdef HAVE_LIBC + int fd; +#endif + +}; + + +/*Initialize frontend */ +struct tpmfront_dev* init_tpmfront(const char* nodename); +/*Shutdown frontend */ +void shutdown_tpmfront(struct tpmfront_dev* dev); + +/* Send a tpm command to the backend and wait for the response + * + * @dev - frontend device + * @req - request buffer + * @reqlen - length of request buffer + * @resp - *resp will be set to internal response buffer, don't free it! Value is undefined on error + * @resplen - *resplen will be set to the length of the response. Value is undefined on error + * + * returns 0 on success, non zero on failure. + * */ +int tpmfront_cmd(struct tpmfront_dev* dev, uint8_t* req, size_t reqlen, uint8_t** resp, size_t* resplen); + +#ifdef HAVE_LIBC +#include +/* POSIX IO functions: + * use tpmfront_open() to get a file descriptor to the tpm device + * use write() on the fd to send a command to the backend. You must + * include the entire command in a single call to write(). + * use read() on the fd to read the response. You can use + * fstat() to get the size of the response and lseek() to seek on it. + */ +int tpmfront_open(struct tpmfront_dev* dev); +int tpmfront_posix_read(int fd, uint8_t* buf, size_t count); +int tpmfront_posix_write(int fd, const uint8_t* buf, size_t count); +int tpmfront_posix_fstat(int fd, struct stat* buf); +#endif + + +#endif diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c index 6cb97b1..d212969 100644 --- a/extras/mini-os/lib/sys.c +++ b/extras/mini-os/lib/sys.c @@ -27,6 +27,8 @@ #include #include #include +#include +#include #include #include @@ -294,6 +296,16 @@ int read(int fd, void *buf, size_t nbytes) return blkfront_posix_read(fd, buf, nbytes); } #endif +#ifdef CONFIG_TPMFRONT + case FTYPE_TPMFRONT: { + return tpmfront_posix_read(fd, buf, nbytes); + } +#endif +#ifdef CONFIG_TPM_TIS + case FTYPE_TPM_TIS: { + return tpm_tis_posix_read(fd, buf, nbytes); + } +#endif default: break; } @@ -330,6 +342,14 @@ int write(int fd, const void *buf, size_t nbytes) case FTYPE_BLK: return blkfront_posix_write(fd, buf, nbytes); #endif +#ifdef CONFIG_TPMFRONT + case FTYPE_TPMFRONT: + return tpmfront_posix_write(fd, buf, nbytes); +#endif +#ifdef CONFIG_TPM_TIS + case FTYPE_TPM_TIS: + return tpm_tis_posix_write(fd, buf, nbytes); +#endif default: break; } @@ -341,8 +361,16 @@ int write(int fd, const void *buf, size_t nbytes) off_t lseek(int fd, off_t offset, int whence) { switch(files[fd].type) { +#if defined(CONFIG_BLKFRONT) || defined(CONFIG_TPMFRONT) || defined(CONFIG_TPM_TIS) #ifdef CONFIG_BLKFRONT case FTYPE_BLK: +#endif +#ifdef CONFIG_TPMFRNT + case FTYPE_TPMFRONT: +#endif +#ifdef CONFIG_TPM_TIS + case FTYPE_TPM_TIS: +#endif switch (whence) { case SEEK_SET: files[fd].file.offset = offset; @@ -420,6 +448,18 @@ int close(int fd) files[fd].type = FTYPE_NONE; return 0; #endif +#ifdef CONFIG_TPMFRONT + case FTYPE_TPMFRONT: + shutdown_tpmfront(files[fd].tpmfront.dev); + files[fd].type = FTYPE_NONE; + return 0; +#endif +#ifdef CONFIG_TPM_TIS + case FTYPE_TPM_TIS: + shutdown_tpm_tis(files[fd].tpm_tis.dev); + files[fd].type = FTYPE_NONE; + return 0; +#endif #ifdef CONFIG_KBDFRONT case FTYPE_KBD: shutdown_kbdfront(files[fd].kbd.dev); @@ -489,6 +529,14 @@ int fstat(int fd, struct stat *buf) case FTYPE_BLK: return blkfront_posix_fstat(fd, buf); #endif +#ifdef CONFIG_TPMFRONT + case FTYPE_TPMFRONT: + return tpmfront_posix_fstat(fd, buf); +#endif +#ifdef CONFIG_TPM_TIS + case FTYPE_TPM_TIS: + return tpm_tis_posix_fstat(fd, buf); +#endif default: break; } diff --git a/extras/mini-os/tpm_tis.c b/extras/mini-os/tpm_tis.c new file mode 100644 index 0000000..d94f798 --- /dev/null +++ b/extras/mini-os/tpm_tis.c @@ -0,0 +1,1345 @@ +/* + * Copyright (c) 2010-2012 United States Government, as represented by + * the Secretary of Defense. All rights reserved. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version 2 + * of the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + * + * Based upon the files: + * drivers/char/tpm/tpm_tis.c + * drivers/char/tpm/tpm.c + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#ifndef min + #define min( a, b ) ( ((a) < (b)) ? (a) : (b) ) +#endif + +#define TPM_HEADER_SIZE 10 + +#define TPM_BUFSIZE 2048 + +struct tpm_input_header { + uint16_t tag; + uint32_t length; + uint32_t ordinal; +}__attribute__((packed)); + +struct tpm_output_header { + uint16_t tag; + uint32_t length; + uint32_t return_code; +}__attribute__((packed)); + +struct stclear_flags_t { + uint16_t tag; + uint8_t deactivated; + uint8_t disableForceClear; + uint8_t physicalPresence; + uint8_t physicalPresenceLock; + uint8_t bGlobalLock; +}__attribute__((packed)); + +struct tpm_version_t { + uint8_t Major; + uint8_t Minor; + uint8_t revMajor; + uint8_t revMinor; +}__attribute__((packed)); + +struct tpm_version_1_2_t { + uint16_t tag; + uint8_t Major; + uint8_t Minor; + uint8_t revMajor; + uint8_t revMinor; +}__attribute__((packed)); + +struct timeout_t { + uint32_t a; + uint32_t b; + uint32_t c; + uint32_t d; +}__attribute__((packed)); + +struct duration_t { + uint32_t tpm_short; + uint32_t tpm_medium; + uint32_t tpm_long; +}__attribute__((packed)); + +struct permanent_flags_t { + uint16_t tag; + uint8_t disable; + uint8_t ownership; + uint8_t deactivated; + uint8_t readPubek; + uint8_t disableOwnerClear; + uint8_t allowMaintenance; + uint8_t physicalPresenceLifetimeLock; + uint8_t physicalPresenceHWEnable; + uint8_t physicalPresenceCMDEnable; + uint8_t CEKPUsed; + uint8_t TPMpost; + uint8_t TPMpostLock; + uint8_t FIPS; + uint8_t operator; + uint8_t enableRevokeEK; + uint8_t nvLocked; + uint8_t readSRKPub; + uint8_t tpmEstablished; + uint8_t maintenanceDone; + uint8_t disableFullDALogicInfo; +}__attribute__((packed)); + +typedef union { + struct permanent_flags_t perm_flags; + struct stclear_flags_t stclear_flags; + bool owned; + uint32_t num_pcrs; + struct tpm_version_t tpm_version; + struct tpm_version_1_2_t tpm_version_1_2; + uint32_t manufacturer_id; + struct timeout_t timeout; + struct duration_t duration; +} cap_t; + +struct tpm_getcap_params_in { + uint32_t cap; + uint32_t subcap_size; + uint32_t subcap; +}__attribute__((packed)); + +struct tpm_getcap_params_out { + uint32_t cap_size; + cap_t cap; +}__attribute__((packed)); + +struct tpm_readpubek_params_out { + uint8_t algorithm[4]; + uint8_t encscheme[2]; + uint8_t sigscheme[2]; + uint32_t paramsize; + uint8_t parameters[12]; /*assuming RSA*/ + uint32_t keysize; + uint8_t modulus[256]; + uint8_t checksum[20]; +}__attribute__((packed)); + +typedef union { + struct tpm_input_header in; + struct tpm_output_header out; +} tpm_cmd_header; + +#define TPM_DIGEST_SIZE 20 +struct tpm_pcrread_out { + uint8_t pcr_result[TPM_DIGEST_SIZE]; +}__attribute__((packed)); + +struct tpm_pcrread_in { + uint32_t pcr_idx; +}__attribute__((packed)); + +struct tpm_pcrextend_in { + uint32_t pcr_idx; + uint8_t hash[TPM_DIGEST_SIZE]; +}__attribute__((packed)); + +typedef union { + struct tpm_getcap_params_out getcap_out; + struct tpm_readpubek_params_out readpubek_out; + uint8_t readpubek_out_buffer[sizeof(struct tpm_readpubek_params_out)]; + struct tpm_getcap_params_in getcap_in; + struct tpm_pcrread_in pcrread_in; + struct tpm_pcrread_out pcrread_out; + struct tpm_pcrextend_in pcrextend_in; +} tpm_cmd_params; + +struct tpm_cmd_t { + tpm_cmd_header header; + tpm_cmd_params params; +}__attribute__((packed)); + + +enum tpm_duration { + TPM_SHORT = 0, + TPM_MEDIUM = 1, + TPM_LONG = 2, + TPM_UNDEFINED, +}; + +#define TPM_MAX_ORDINAL 243 +#define TPM_MAX_PROTECTED_ORDINAL 12 +#define TPM_PROTECTED_ORDINAL_MASK 0xFF + +extern const uint8_t tpm_protected_ordinal_duration[TPM_MAX_PROTECTED_ORDINAL]; +extern const uint8_t tpm_ordinal_duration[TPM_MAX_ORDINAL]; + +#define TPM_DIGEST_SIZE 20 +#define TPM_ERROR_SIZE 10 +#define TPM_RET_CODE_IDX 6 + +/* tpm_capabilities */ +#define TPM_CAP_FLAG cpu_to_be32(4) +#define TPM_CAP_PROP cpu_to_be32(5) +#define CAP_VERSION_1_1 cpu_to_be32(0x06) +#define CAP_VERSION_1_2 cpu_to_be32(0x1A) + +/* tpm_sub_capabilities */ +#define TPM_CAP_PROP_PCR cpu_to_be32(0x101) +#define TPM_CAP_PROP_MANUFACTURER cpu_to_be32(0x103) +#define TPM_CAP_FLAG_PERM cpu_to_be32(0x108) +#define TPM_CAP_FLAG_VOL cpu_to_be32(0x109) +#define TPM_CAP_PROP_OWNER cpu_to_be32(0x111) +#define TPM_CAP_PROP_TIS_TIMEOUT cpu_to_be32(0x115) +#define TPM_CAP_PROP_TIS_DURATION cpu_to_be32(0x120) + + +#define TPM_INTERNAL_RESULT_SIZE 200 +#define TPM_TAG_RQU_COMMAND cpu_to_be16(193) +#define TPM_ORD_GET_CAP cpu_to_be32(101) + +extern const struct tpm_input_header tpm_getcap_header; + + + +const uint8_t tpm_protected_ordinal_duration[TPM_MAX_PROTECTED_ORDINAL] = { + TPM_UNDEFINED, /* 0 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 5 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 10 */ + TPM_SHORT, +}; + +const uint8_t tpm_ordinal_duration[TPM_MAX_ORDINAL] = { + TPM_UNDEFINED, /* 0 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 5 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 10 */ + TPM_SHORT, + TPM_MEDIUM, + TPM_LONG, + TPM_LONG, + TPM_MEDIUM, /* 15 */ + TPM_SHORT, + TPM_SHORT, + TPM_MEDIUM, + TPM_LONG, + TPM_SHORT, /* 20 */ + TPM_SHORT, + TPM_MEDIUM, + TPM_MEDIUM, + TPM_MEDIUM, + TPM_SHORT, /* 25 */ + TPM_SHORT, + TPM_MEDIUM, + TPM_SHORT, + TPM_SHORT, + TPM_MEDIUM, /* 30 */ + TPM_LONG, + TPM_MEDIUM, + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, /* 35 */ + TPM_MEDIUM, + TPM_MEDIUM, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_MEDIUM, /* 40 */ + TPM_LONG, + TPM_MEDIUM, + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, /* 45 */ + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_LONG, + TPM_MEDIUM, /* 50 */ + TPM_MEDIUM, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 55 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_MEDIUM, /* 60 */ + TPM_MEDIUM, + TPM_MEDIUM, + TPM_SHORT, + TPM_SHORT, + TPM_MEDIUM, /* 65 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 70 */ + TPM_SHORT, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 75 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_LONG, /* 80 */ + TPM_UNDEFINED, + TPM_MEDIUM, + TPM_LONG, + TPM_SHORT, + TPM_UNDEFINED, /* 85 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 90 */ + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_UNDEFINED, /* 95 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_MEDIUM, /* 100 */ + TPM_SHORT, + TPM_SHORT, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 105 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 110 */ + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, /* 115 */ + TPM_SHORT, + TPM_SHORT, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_LONG, /* 120 */ + TPM_LONG, + TPM_MEDIUM, + TPM_UNDEFINED, + TPM_SHORT, + TPM_SHORT, /* 125 */ + TPM_SHORT, + TPM_LONG, + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, /* 130 */ + TPM_MEDIUM, + TPM_UNDEFINED, + TPM_SHORT, + TPM_MEDIUM, + TPM_UNDEFINED, /* 135 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 140 */ + TPM_SHORT, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 145 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 150 */ + TPM_MEDIUM, + TPM_MEDIUM, + TPM_SHORT, + TPM_SHORT, + TPM_UNDEFINED, /* 155 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 160 */ + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 165 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_LONG, /* 170 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 175 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_MEDIUM, /* 180 */ + TPM_SHORT, + TPM_MEDIUM, + TPM_MEDIUM, + TPM_MEDIUM, + TPM_MEDIUM, /* 185 */ + TPM_SHORT, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 190 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 195 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 200 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, + TPM_SHORT, /* 205 */ + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_MEDIUM, /* 210 */ + TPM_UNDEFINED, + TPM_MEDIUM, + TPM_MEDIUM, + TPM_MEDIUM, + TPM_UNDEFINED, /* 215 */ + TPM_MEDIUM, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, + TPM_SHORT, /* 220 */ + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_UNDEFINED, /* 225 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 230 */ + TPM_LONG, + TPM_MEDIUM, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 235 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 240 */ + TPM_UNDEFINED, + TPM_MEDIUM, +}; + +const struct tpm_input_header tpm_getcap_header = { + .tag = TPM_TAG_RQU_COMMAND, + .length = cpu_to_be32(22), + .ordinal = TPM_ORD_GET_CAP +}; + + +enum tis_access { + TPM_ACCESS_VALID = 0x80, + TPM_ACCESS_ACTIVE_LOCALITY = 0x20, /* (R) */ + TPM_ACCESS_RELINQUISH_LOCALITY = 0x20,/* (W) */ + TPM_ACCESS_REQUEST_PENDING = 0x04, /* (W) */ + TPM_ACCESS_REQUEST_USE = 0x02, /* (W) */ +}; + +enum tis_status { + TPM_STS_VALID = 0x80, /* (R) */ + TPM_STS_COMMAND_READY = 0x40, /* (R) */ + TPM_STS_DATA_AVAIL = 0x10, /* (R) */ + TPM_STS_DATA_EXPECT = 0x08, /* (R) */ + TPM_STS_GO = 0x20, /* (W) */ +}; + +enum tis_int_flags { + TPM_GLOBAL_INT_ENABLE = 0x80000000, + TPM_INTF_BURST_COUNT_STATIC = 0x100, + TPM_INTF_CMD_READY_INT = 0x080, + TPM_INTF_INT_EDGE_FALLING = 0x040, + TPM_INTF_INT_EDGE_RISING = 0x020, + TPM_INTF_INT_LEVEL_LOW = 0x010, + TPM_INTF_INT_LEVEL_HIGH = 0x008, + TPM_INTF_LOCALITY_CHANGE_INT = 0x004, + TPM_INTF_STS_VALID_INT = 0x002, + TPM_INTF_DATA_AVAIL_INT = 0x001, +}; + +enum tis_defaults { + TIS_MEM_BASE = 0xFED40000, + TIS_MEM_LEN = 0x5000, + TIS_SHORT_TIMEOUT = 750, /*ms*/ + TIS_LONG_TIMEOUT = 2000, /*2 sec */ +}; + +#define TPM_TIMEOUT 5 + +#define TPM_ACCESS(t, l) (((uint8_t*)t->pages[l]) + 0x0000) +#define TPM_INT_ENABLE(t, l) ((uint32_t*)(((uint8_t*)t->pages[l]) + 0x0008)) +#define TPM_INT_VECTOR(t, l) (((uint8_t*)t->pages[l]) + 0x000C) +#define TPM_INT_STATUS(t, l) (((uint8_t*)t->pages[l]) + 0x0010) +#define TPM_INTF_CAPS(t, l) ((uint32_t*)(((uint8_t*)t->pages[l]) + 0x0014)) +#define TPM_STS(t, l) ((uint8_t*)(((uint8_t*)t->pages[l]) + 0x0018)) +#define TPM_DATA_FIFO(t, l) (((uint8_t*)t->pages[l]) + 0x0024) + +#define TPM_DID_VID(t, l) ((uint32_t*)(((uint8_t*)t->pages[l]) + 0x0F00)) +#define TPM_RID(t, l) (((uint8_t*)t->pages[l]) + 0x0F04) + +struct tpm_chip { + int enabled_localities; + int locality; + unsigned long baseaddr; + uint8_t* pages[5]; + int did, vid, rid; + + uint8_t data_buffer[TPM_BUFSIZE]; + int data_len; + + s_time_t timeout_a, timeout_b, timeout_c, timeout_d; + s_time_t duration[3]; + +#ifdef HAVE_LIBC + int fd; +#endif + + unsigned int irq; + struct wait_queue_head read_queue; + struct wait_queue_head int_queue; +}; + + +static void __init_tpm_chip(struct tpm_chip* tpm) { + tpm->enabled_localities = TPM_TIS_EN_LOCLALL; + tpm->locality = -1; + tpm->baseaddr = 0; + tpm->pages[0] = tpm->pages[1] = tpm->pages[2] = tpm->pages[3] = tpm->pages[4] = NULL; + tpm->vid = 0; + tpm->did = 0; + tpm->irq = 0; + init_waitqueue_head(&tpm->read_queue); + init_waitqueue_head(&tpm->int_queue); + + tpm->data_len = -1; + +#ifdef HAVE_LIBC + tpm->fd = -1; +#endif +} + +/* + * Returns max number of nsecs to wait + */ +s_time_t tpm_calc_ordinal_duration(struct tpm_chip *chip, + uint32_t ordinal) +{ + int duration_idx = TPM_UNDEFINED; + s_time_t duration = 0; + + if (ordinal < TPM_MAX_ORDINAL) + duration_idx = tpm_ordinal_duration[ordinal]; + else if ((ordinal & TPM_PROTECTED_ORDINAL_MASK) < + TPM_MAX_PROTECTED_ORDINAL) + duration_idx = + tpm_protected_ordinal_duration[ordinal & + TPM_PROTECTED_ORDINAL_MASK]; + + if (duration_idx != TPM_UNDEFINED) { + duration = chip->duration[duration_idx]; + } + + if (duration <= 0) { + return SECONDS(120); + } + else + { + return duration; + } +} + + +static int locality_enabled(struct tpm_chip* tpm, int l) { + return tpm->enabled_localities & (1 << l); +} + +static int check_locality(struct tpm_chip* tpm, int l) { + if(locality_enabled(tpm, l) && (ioread8(TPM_ACCESS(tpm, l)) & + (TPM_ACCESS_ACTIVE_LOCALITY | TPM_ACCESS_VALID)) == + (TPM_ACCESS_ACTIVE_LOCALITY | TPM_ACCESS_VALID)) { + return l; + } + return -1; +} + +void release_locality(struct tpm_chip* tpm, int l, int force) +{ + if (locality_enabled(tpm, l) && (force || (ioread8(TPM_ACCESS(tpm, l)) & + (TPM_ACCESS_REQUEST_PENDING | TPM_ACCESS_VALID)) == + (TPM_ACCESS_REQUEST_PENDING | TPM_ACCESS_VALID))) { + iowrite8(TPM_ACCESS(tpm, l), TPM_ACCESS_RELINQUISH_LOCALITY); + } +} + +int tpm_tis_request_locality(struct tpm_chip* tpm, int l) { + + s_time_t stop; + /*Make sure locality is valid */ + if(!locality_enabled(tpm, l)) { + printk("tpm_tis_change_locality() Tried to change to locality %d, but it is disabled or invalid!\n", l); + return -1; + } + /* Check if we already have the current locality */ + if(check_locality(tpm, l) >= 0) { + return tpm->locality = l; + } + /* Set the new locality*/ + iowrite8(TPM_ACCESS(tpm, l), TPM_ACCESS_REQUEST_USE); + + if(tpm->irq) { + /* Wait for interrupt */ + wait_event_deadline(tpm->int_queue, (check_locality(tpm, l) >= 0), NOW() + tpm->timeout_a); + + /* FIXME: Handle timeout event, should return error in that case */ + return l; + } else { + /* Wait for burstcount */ + stop = NOW() + tpm->timeout_a; + do { + if(check_locality(tpm, l) >= 0) { + return tpm->locality = l; + } + msleep(TPM_TIMEOUT); + } while(NOW() < stop); + } + + printk("REQ LOCALITY FAILURE\n"); + return -1; +} + +static uint8_t tpm_tis_status(struct tpm_chip* tpm) { + return ioread8(TPM_STS(tpm, tpm->locality)); +} + +/* This causes the current command to be aborted */ +static void tpm_tis_ready(struct tpm_chip* tpm) { + iowrite8(TPM_STS(tpm, tpm->locality), TPM_STS_COMMAND_READY); +} +#define tpm_tis_cancel_cmd(v) tpm_tis_ready(v) + +static int get_burstcount(struct tpm_chip* tpm) { + s_time_t stop; + int burstcnt; + + stop = NOW() + tpm->timeout_d; + do { + burstcnt = ioread8((TPM_STS(tpm, tpm->locality) + 1)); + burstcnt += ioread8(TPM_STS(tpm, tpm->locality) + 2) << 8; + + if (burstcnt) { + return burstcnt; + } + msleep(TPM_TIMEOUT); + } while(NOW() < stop); + return -EBUSY; +} + +static int wait_for_stat(struct tpm_chip* tpm, uint8_t mask, + unsigned long timeout, struct wait_queue_head* queue) { + s_time_t stop; + uint8_t status; + + status = tpm_tis_status(tpm); + if((status & mask) == mask) { + return 0; + } + + if(tpm->irq) { + wait_event_deadline(*queue, ((tpm_tis_status(tpm) & mask) == mask), timeout); + /* FIXME: Check for timeout and return -ETIME */ + return 0; + } else { + stop = NOW() + timeout; + do { + msleep(TPM_TIMEOUT); + status = tpm_tis_status(tpm); + if((status & mask) == mask) + return 0; + } while( NOW() < stop); + } + return -ETIME; +} + +static int recv_data(struct tpm_chip* tpm, uint8_t* buf, size_t count) { + int size = 0; + int burstcnt; + while( size < count && + wait_for_stat(tpm, + TPM_STS_DATA_AVAIL | TPM_STS_VALID, + tpm->timeout_c, + &tpm->read_queue) + == 0) { + burstcnt = get_burstcount(tpm); + for(; burstcnt > 0 && size < count; --burstcnt) + { + buf[size++] = ioread8(TPM_DATA_FIFO(tpm, tpm->locality)); + } + } + return size; +} + +int tpm_tis_recv(struct tpm_chip* tpm, uint8_t* buf, size_t count) { + int size = 0; + int expected, status; + + if (count < TPM_HEADER_SIZE) { + size = -EIO; + goto out; + } + + /* read first 10 bytes, including tag, paramsize, and result */ + if((size = + recv_data(tpm, buf, TPM_HEADER_SIZE)) < TPM_HEADER_SIZE) { + printk("Error reading tpm cmd header\n"); + goto out; + } + + expected = be32_to_cpu(*((uint32_t*)(buf + 2))); + if(expected > count) { + size = -EIO; + goto out; + } + + if((size += recv_data(tpm, & buf[TPM_HEADER_SIZE], + expected - TPM_HEADER_SIZE)) < expected) { + printk("Unable to read rest of tpm command size=%d expected=%d\n", size, expected); + size = -ETIME; + goto out; + } + + wait_for_stat(tpm, TPM_STS_VALID, tpm->timeout_c, &tpm->int_queue); + status = tpm_tis_status(tpm); + if(status & TPM_STS_DATA_AVAIL) { + printk("Error: left over data\n"); + size = -EIO; + goto out; + } + +out: + tpm_tis_ready(tpm); + release_locality(tpm, tpm->locality, 0); + return size; +} +int tpm_tis_send(struct tpm_chip* tpm, uint8_t* buf, size_t len) { + int rc; + int status, burstcnt = 0; + int count = 0; + uint32_t ordinal; + + if(tpm_tis_request_locality(tpm, tpm->locality) < 0) { + return -EBUSY; + } + + status = tpm_tis_status(tpm); + if((status & TPM_STS_COMMAND_READY) == 0) { + tpm_tis_ready(tpm); + if(wait_for_stat(tpm, TPM_STS_COMMAND_READY, tpm->timeout_b, &tpm->int_queue) < 0) { + rc = -ETIME; + goto out_err; + } + } + + while(count < len - 1) { + burstcnt = get_burstcount(tpm); + for(;burstcnt > 0 && count < len -1; --burstcnt) { + iowrite8(TPM_DATA_FIFO(tpm, tpm->locality), buf[count++]); + } + + wait_for_stat(tpm, TPM_STS_VALID, tpm->timeout_c, &tpm->int_queue); + status = tpm_tis_status(tpm); + if((status & TPM_STS_DATA_EXPECT) == 0) { + rc = -EIO; + goto out_err; + } + } + + /*Write last byte*/ + iowrite8(TPM_DATA_FIFO(tpm, tpm->locality), buf[count]); + wait_for_stat(tpm, TPM_STS_VALID, tpm->timeout_c, &tpm->read_queue); + status = tpm_tis_status(tpm); + if((status & TPM_STS_DATA_EXPECT) != 0) { + rc = -EIO; + goto out_err; + } + + /*go and do it*/ + iowrite8(TPM_STS(tpm, tpm->locality), TPM_STS_GO); + + if(tpm->irq) { + /*Wait for interrupt */ + ordinal = be32_to_cpu(*(buf + 6)); + if(wait_for_stat(tpm, + TPM_STS_DATA_AVAIL | TPM_STS_VALID, + tpm_calc_ordinal_duration(tpm, ordinal), + &tpm->read_queue) < 0) { + rc = -ETIME; + goto out_err; + } + } +#ifdef HAVE_LIBC + if(tpm->fd >= 0) { + files[tpm->fd].read = 0; + files[tpm->fd].tpm_tis.respgot = 0; + files[tpm->fd].tpm_tis.offset = 0; + } +#endif + return len; + +out_err: + tpm_tis_ready(tpm); + release_locality(tpm, tpm->locality, 0); + return rc; +} + +static void tpm_tis_irq_handler(evtchn_port_t port, struct pt_regs *regs, void* data) +{ + struct tpm_chip* tpm = data; + uint32_t interrupt; + int i; + + interrupt = ioread32(TPM_INT_STATUS(tpm, tpm->locality)); + if(interrupt == 0) { + return; + } + + if(interrupt & TPM_INTF_DATA_AVAIL_INT) { + wake_up(&tpm->read_queue); + } + if(interrupt & TPM_INTF_LOCALITY_CHANGE_INT) { + for(i = 0; i < 5; ++i) { + if(check_locality(tpm, i) >= 0) { + break; + } + } + } + if(interrupt & (TPM_INTF_LOCALITY_CHANGE_INT | TPM_INTF_STS_VALID_INT | + TPM_INTF_CMD_READY_INT)) { + wake_up(&tpm->int_queue); + } + + /* Clear interrupts handled with TPM_EOI */ + iowrite32(TPM_INT_STATUS(tpm, tpm->locality), interrupt); + ioread32(TPM_INT_STATUS(tpm, tpm->locality)); + return; +} + +/* + * Internal kernel interface to transmit TPM commands + */ +static ssize_t tpm_transmit(struct tpm_chip *chip, const uint8_t *buf, + size_t bufsiz) +{ + ssize_t rc; + uint32_t count, ordinal; + s_time_t stop; + + count = be32_to_cpu(*((uint32_t *) (buf + 2))); + ordinal = be32_to_cpu(*((uint32_t *) (buf + 6))); + if (count == 0) + return -ENODATA; + if (count > bufsiz) { + printk("Error: invalid count value %x %zx \n", count, bufsiz); + return -E2BIG; + } + + //down(&chip->tpm_mutex); + + if ((rc = tpm_tis_send(chip, (uint8_t *) buf, count)) < 0) { + printk("tpm_transmit: tpm_send: error %zd\n", rc); + goto out; + } + + if (chip->irq) + goto out_recv; + + stop = NOW() + tpm_calc_ordinal_duration(chip, ordinal); + do { + uint8_t status = tpm_tis_status(chip); + if ((status & (TPM_STS_DATA_AVAIL | TPM_STS_VALID)) == + (TPM_STS_DATA_AVAIL | TPM_STS_VALID)) + goto out_recv; + + if ((status == TPM_STS_COMMAND_READY)) { + printk("TPM Error: Operation Canceled\n"); + rc = -ECANCELED; + goto out; + } + + msleep(TPM_TIMEOUT); /* CHECK */ + rmb(); + } while (NOW() < stop); + + /* Cancel the command */ + tpm_tis_cancel_cmd(chip); + printk("TPM Operation Timed out\n"); + rc = -ETIME; + goto out; + +out_recv: + if((rc = tpm_tis_recv(chip, (uint8_t *) buf, bufsiz)) < 0) { + printk("tpm_transmit: tpm_recv: error %d\n", rc); + } +out: + //up(&chip->tpm_mutex); + return rc; +} + +static ssize_t transmit_cmd(struct tpm_chip *chip, struct tpm_cmd_t *cmd, + int len, const char *desc) +{ + int err; + + len = tpm_transmit(chip,(uint8_t *) cmd, len); + if (len < 0) + return len; + if (len == TPM_ERROR_SIZE) { + err = be32_to_cpu(cmd->header.out.return_code); + printk("A TPM error (%d) occurred %s\n", err, desc); + return err; + } + return 0; +} + +void tpm_get_timeouts(struct tpm_chip *chip) +{ + struct tpm_cmd_t tpm_cmd; + struct timeout_t *timeout_cap; + struct duration_t *duration_cap; + ssize_t rc; + uint32_t timeout; + + tpm_cmd.header.in = tpm_getcap_header; + tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP; + tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4); + tpm_cmd.params.getcap_in.subcap = TPM_CAP_PROP_TIS_TIMEOUT; + + if((rc = transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE, + "attempting to determine the timeouts")) != 0) { + printk("transmit failed %d\n", rc); + goto duration; + } + + if (be32_to_cpu(tpm_cmd.params.getcap_out.cap_size) + != 4 * sizeof(uint32_t)) { + printk("Out len check failure %lu \n", be32_to_cpu(tpm_cmd.header.out.length)); + goto duration; + } + + timeout_cap = &tpm_cmd.params.getcap_out.cap.timeout; + /* Don't overwrite default if value is 0 */ + timeout = be32_to_cpu(timeout_cap->a); + if (timeout) + chip->timeout_a = MICROSECS(timeout); /*Convert to msec */ + timeout = be32_to_cpu(timeout_cap->b); + if (timeout) + chip->timeout_b = MICROSECS(timeout); /*Convert to msec */ + timeout = be32_to_cpu(timeout_cap->c); + if (timeout) + chip->timeout_c = MICROSECS(timeout); /*Convert to msec */ + timeout = be32_to_cpu(timeout_cap->d); + if (timeout) + chip->timeout_d = MICROSECS(timeout); /*Convert to msec */ + +duration: + tpm_cmd.header.in = tpm_getcap_header; + tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP; + tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4); + tpm_cmd.params.getcap_in.subcap = TPM_CAP_PROP_TIS_DURATION; + + if((rc = transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE, + "attempting to determine the durations")) < 0) { + return; + } + + if (be32_to_cpu(tpm_cmd.params.getcap_out.cap_size) + != 3 * sizeof(uint32_t)) { + return; + } + duration_cap = &tpm_cmd.params.getcap_out.cap.duration; + chip->duration[TPM_SHORT] = be32_to_cpu(duration_cap->tpm_short); + /* The Broadcom BCM0102 chipset in a Dell Latitude D820 gets the above + * value wrong and apparently reports msecs rather than usecs. So we + * fix up the resulting too-small TPM_SHORT value to make things work. + */ + if (chip->duration[TPM_SHORT] < 10) { + chip->duration[TPM_SHORT] = MILLISECS(chip->duration[TPM_SHORT]); + } else { + chip->duration[TPM_SHORT] = MICROSECS(chip->duration[TPM_SHORT]); + } + + chip->duration[TPM_MEDIUM] = MICROSECS(be32_to_cpu(duration_cap->tpm_medium)); + chip->duration[TPM_LONG] = MICROSECS(be32_to_cpu(duration_cap->tpm_long)); +} + + + +void tpm_continue_selftest(struct tpm_chip* chip) { + uint8_t data[] = { + 0, 193, /* TPM_TAG_RQU_COMMAND */ + 0, 0, 0, 10, /* length */ + 0, 0, 0, 83, /* TPM_ORD_GetCapability */ + }; + + tpm_transmit(chip, data, sizeof(data)); +} + +ssize_t tpm_getcap(struct tpm_chip *chip, uint32_t subcap_id, cap_t *cap, + const char *desc) +{ + struct tpm_cmd_t tpm_cmd; + int rc; + + tpm_cmd.header.in = tpm_getcap_header; + if (subcap_id == CAP_VERSION_1_1 || subcap_id == CAP_VERSION_1_2) { + tpm_cmd.params.getcap_in.cap = subcap_id; + /*subcap field not necessary */ + tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(0); + tpm_cmd.header.in.length -= cpu_to_be32(sizeof(uint32_t)); + } else { + if (subcap_id == TPM_CAP_FLAG_PERM || + subcap_id == TPM_CAP_FLAG_VOL) + tpm_cmd.params.getcap_in.cap = TPM_CAP_FLAG; + else + tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP; + tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4); + tpm_cmd.params.getcap_in.subcap = subcap_id; + } + rc = transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE, desc); + if (!rc) + *cap = tpm_cmd.params.getcap_out.cap; + return rc; +} + + +struct tpm_chip* init_tpm_tis(unsigned long baseaddr, int localities, unsigned int irq) +{ + int i; + unsigned long addr; + struct tpm_chip* tpm = NULL; + uint32_t didvid; + uint32_t intfcaps; + uint32_t intmask; + + printk("============= Init TPM TIS Driver ==============\n"); + + /*Sanity check the localities input */ + if(localities & ~TPM_TIS_EN_LOCLALL) { + printk("init_tpm_tis() Invalid locality specification! %X\n", localities); + goto abort_egress; + } + + printk("IOMEM Machine Base Address: %lX\n", baseaddr); + + /* Create the tpm data structure */ + tpm = malloc(sizeof(struct tpm_chip)); + __init_tpm_chip(tpm); + + /* Set the enabled localities - if 0 we leave default as all enabled */ + if(localities != 0) { + tpm->enabled_localities = localities; + } + printk("Enabled Localities: "); + for(i = 0; i < 5; ++i) { + if(locality_enabled(tpm, i)) { + printk("%d ", i); + } + } + printk("\n"); + + /* Set the base machine address */ + tpm->baseaddr = baseaddr; + + /* Set default timeouts */ + tpm->timeout_a = MILLISECS(TIS_SHORT_TIMEOUT); + tpm->timeout_b = MILLISECS(TIS_LONG_TIMEOUT); + tpm->timeout_c = MILLISECS(TIS_SHORT_TIMEOUT); + tpm->timeout_d = MILLISECS(TIS_SHORT_TIMEOUT); + + /*Map the mmio pages */ + addr = tpm->baseaddr; + for(i = 0; i < 5; ++i) { + if(locality_enabled(tpm, i)) { + /* Map the page in now */ + if((tpm->pages[i] = ioremap_nocache(addr, PAGE_SIZE)) == NULL) { + printk("Unable to map iomem page a address %p\n", addr); + goto abort_egress; + } + + /* Set default locality to the first enabled one */ + if (tpm->locality < 0) { + if(tpm_tis_request_locality(tpm, i) < 0) { + printk("Unable to request locality %d??\n", i); + goto abort_egress; + } + } + } + addr += PAGE_SIZE; + } + + + /* Get the vendor and device ids */ + didvid = ioread32(TPM_DID_VID(tpm, tpm->locality)); + tpm->did = didvid >> 16; + tpm->vid = didvid & 0xFFFF; + + + /* Get the revision id */ + tpm->rid = ioread8(TPM_RID(tpm, tpm->locality)); + + printk("1.2 TPM (device-id=0x%X vendor-id = %X rev-id = %X)\n", tpm->did, tpm->vid, tpm->rid); + + intfcaps = ioread32(TPM_INTF_CAPS(tpm, tpm->locality)); + printk("TPM interface capabilities (0x%x):\n", intfcaps); + if (intfcaps & TPM_INTF_BURST_COUNT_STATIC) + printk("\tBurst Count Static\n"); + if (intfcaps & TPM_INTF_CMD_READY_INT) + printk("\tCommand Ready Int Support\n"); + if (intfcaps & TPM_INTF_INT_EDGE_FALLING) + printk("\tInterrupt Edge Falling\n"); + if (intfcaps & TPM_INTF_INT_EDGE_RISING) + printk("\tInterrupt Edge Rising\n"); + if (intfcaps & TPM_INTF_INT_LEVEL_LOW) + printk("\tInterrupt Level Low\n"); + if (intfcaps & TPM_INTF_INT_LEVEL_HIGH) + printk("\tInterrupt Level High\n"); + if (intfcaps & TPM_INTF_LOCALITY_CHANGE_INT) + printk("\tLocality Change Int Support\n"); + if (intfcaps & TPM_INTF_STS_VALID_INT) + printk("\tSts Valid Int Support\n"); + if (intfcaps & TPM_INTF_DATA_AVAIL_INT) + printk("\tData Avail Int Support\n"); + + /*Interupt setup */ + intmask = ioread32(TPM_INT_ENABLE(tpm, tpm->locality)); + + intmask |= TPM_INTF_CMD_READY_INT + | TPM_INTF_LOCALITY_CHANGE_INT | TPM_INTF_DATA_AVAIL_INT + | TPM_INTF_STS_VALID_INT; + + iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), intmask); + + /*If interupts are enabled, handle it */ + if(irq) { + if(irq != TPM_PROBE_IRQ) { + tpm->irq = irq; + } else { + /*FIXME add irq probing feature later */ + printk("IRQ probing not implemented\n"); + } + } + + if(tpm->irq) { + iowrite8(TPM_INT_VECTOR(tpm, tpm->locality), tpm->irq); + + if(bind_pirq(tpm->irq, 1, tpm_tis_irq_handler, tpm) != 0) { + printk("Unabled to request irq: %u for use\n", tpm->irq); + printk("Will use polling mode\n"); + tpm->irq = 0; + } else { + /* Clear all existing */ + iowrite32(TPM_INT_STATUS(tpm, tpm->locality), ioread32(TPM_INT_STATUS(tpm, tpm->locality))); + + /* Turn on interrupts */ + iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), intmask | TPM_GLOBAL_INT_ENABLE); + } + } + + tpm_get_timeouts(tpm); + tpm_continue_selftest(tpm); + + + return tpm; +abort_egress: + if(tpm != NULL) { + shutdown_tpm_tis(tpm); + } + return NULL; +} + +void shutdown_tpm_tis(struct tpm_chip* tpm){ + int i; + + printk("Shutting down tpm_tis device\n"); + + iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), ~TPM_GLOBAL_INT_ENABLE); + + /*Unmap all of the mmio pages */ + for(i = 0; i < 5; ++i) { + if(tpm->pages[i] != NULL) { + iounmap(tpm->pages[i], PAGE_SIZE); + tpm->pages[i] = NULL; + } + } + free(tpm); + return; +} + + +int tpm_tis_cmd(struct tpm_chip* tpm, uint8_t* req, size_t reqlen, uint8_t** resp, size_t* resplen) +{ + if(tpm->locality < 0) { + printk("tpm_tis_cmd() failed! locality not set!\n"); + return -1; + } + if(reqlen > TPM_BUFSIZE) { + reqlen = TPM_BUFSIZE; + } + memcpy(tpm->data_buffer, req, reqlen); + *resplen = tpm_transmit(tpm, tpm->data_buffer, TPM_BUFSIZE); + + *resp = malloc(*resplen); + memcpy(*resp, tpm->data_buffer, *resplen); + return 0; +} + +#ifdef HAVE_LIBC +int tpm_tis_open(struct tpm_chip* tpm) +{ + /* Silently prevent multiple opens */ + if(tpm->fd != -1) { + return tpm->fd; + } + + tpm->fd = alloc_fd(FTYPE_TPM_TIS); + printk("tpm_tis_open() -> %d\n", tpm->fd); + files[tpm->fd].tpm_tis.dev = tpm; + files[tpm->fd].tpm_tis.offset = 0; + files[tpm->fd].tpm_tis.respgot = 0; + return tpm->fd; +} + +int tpm_tis_posix_write(int fd, const uint8_t* buf, size_t count) +{ + struct tpm_chip* tpm; + tpm = files[fd].tpm_tis.dev; + + if(tpm->locality < 0) { + printk("tpm_tis_posix_write() failed! locality not set!\n"); + errno = EINPROGRESS; + return -1; + } + if(count == 0) { + return 0; + } + + /* Return an error if we are already processing a command */ + if(count > TPM_BUFSIZE) { + count = TPM_BUFSIZE; + } + /* Send the command now */ + memcpy(tpm->data_buffer, buf, count); + if((tpm->data_len = tpm_transmit(tpm, tpm->data_buffer, TPM_BUFSIZE)) < 0) { + errno = EIO; + return -1; + } + return count; +} + +int tpm_tis_posix_read(int fd, uint8_t* buf, size_t count) +{ + int rc; + struct tpm_chip* tpm; + tpm = files[fd].tpm_tis.dev; + + if(count == 0) { + return 0; + } + + /* If there is no tpm resp to read, return EIO */ + if(tpm->data_len < 0) { + errno = EIO; + return -1; + } + + + /* Handle EOF case */ + if(files[fd].tpm_tis.offset >= tpm->data_len) { + rc = 0; + } else { + rc = min(tpm->data_len - files[fd].tpm_tis.offset, count); + memcpy(buf, tpm->data_buffer + files[fd].tpm_tis.offset, rc); + } + files[fd].tpm_tis.offset += rc; + /* Reset the data pending flag */ + return rc; +} +int tpm_tis_posix_fstat(int fd, struct stat* buf) +{ + struct tpm_chip* tpm; + tpm = files[fd].tpm_tis.dev; + + buf->st_mode = O_RDWR; + buf->st_uid = 0; + buf->st_gid = 0; + buf->st_size = be32_to_cpu(*((uint32_t*)(tpm->data_buffer + 2))); + buf->st_atime = buf->st_mtime = buf->st_ctime = time(NULL); + return 0; +} + + +#endif diff --git a/extras/mini-os/tpmback.c b/extras/mini-os/tpmback.c new file mode 100644 index 0000000..03bd20c --- /dev/null +++ b/extras/mini-os/tpmback.c @@ -0,0 +1,1115 @@ +/* + * Copyright (c) 2010-2012 United States Government, as represented by + * the Secretary of Defense. All rights reserved. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version 2 + * of the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + * + * Based upon the files: + * drivers/xen/tpmbk.c + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + + +#ifndef HAVE_LIBC +#define strtoul simple_strtoul +#endif + +//#define TPMBACK_PRINT_DEBUG +#ifdef TPMBACK_PRINT_DEBUG +#define TPMBACK_DEBUG(fmt,...) printk("Tpmback:Debug("__FILE__":%d) " fmt, __LINE__, ##__VA_ARGS__) +#define TPMBACK_DEBUG_MORE(fmt,...) printk(fmt, ##__VA_ARGS__) +#else +#define TPMBACK_DEBUG(fmt,...) +#endif +#define TPMBACK_ERR(fmt,...) printk("Tpmback:Error " fmt, ##__VA_ARGS__) +#define TPMBACK_LOG(fmt,...) printk("Tpmback:Info " fmt, ##__VA_ARGS__) + +#define min(a,b) (((a) < (b)) ? (a) : (b)) + +/* Default size of the tpmif array at initialization */ +#define DEF_ARRAY_SIZE 1 + +/* tpmif and tpmdev flags */ +#define TPMIF_CLOSED 1 +#define TPMIF_REQ_READY 2 + +struct tpmif { + domid_t domid; + unsigned int handle; + + char* fe_path; + char* fe_state_path; + + /* Locally bound event channel*/ + evtchn_port_t evtchn; + + /* Shared page */ + tpmif_tx_interface_t* tx; + + /* pointer to TPMIF_RX_RING_SIZE pages */ + void** pages; + + enum xenbus_state state; + enum { DISCONNECTED, DISCONNECTING, CONNECTED } status; + + char* uuid; + + /* state flags */ + int flags; +}; +typedef struct tpmif tpmif_t; + +struct tpmback_dev { + + tpmif_t** tpmlist; + unsigned long num_tpms; + unsigned long num_alloc; + + struct gntmap map; + + /* True if at least one tpmif has a request to be handled */ + int flags; + + /* exclusive domains, see init_tpmback comment in tpmback.h */ + char** exclusive_uuids; + + xenbus_event_queue events; + + /* Callbacks */ + void (*open_callback)(domid_t, unsigned int); + void (*close_callback)(domid_t, unsigned int); + void (*suspend_callback)(domid_t, unsigned int); + void (*resume_callback)(domid_t, unsigned int); +}; +typedef struct tpmback_dev tpmback_dev_t; + +enum { EV_NONE, EV_NEWFE, EV_STCHNG } tpm_ev_enum; + +/* Global objects */ +static struct thread* eventthread = NULL; +static tpmback_dev_t gtpmdev = { + .tpmlist = NULL, + .num_tpms = 0, + .num_alloc = 0, + .flags = TPMIF_CLOSED, + .events = NULL, + .open_callback = NULL, + .close_callback = NULL, + .suspend_callback = NULL, + .resume_callback = NULL, +}; +struct wait_queue_head waitq; +int globalinit = 0; + +/************************************ + * TPMIF SORTED ARRAY FUNCTIONS + * tpmback_dev_t.tpmlist is a sorted array, sorted by domid and then handle number + * Duplicates are not allowed + * **********************************/ + +inline void tpmif_req_ready(tpmif_t* tpmif) { + tpmif->flags |= TPMIF_REQ_READY; + gtpmdev.flags |= TPMIF_REQ_READY; +} + +inline void tpmdev_check_req(void) { + int i; + int flags; + local_irq_save(flags); + for(i = 0; i < gtpmdev.num_tpms; ++i) { + if(gtpmdev.tpmlist[i]->flags & TPMIF_REQ_READY) { + gtpmdev.flags |= TPMIF_REQ_READY; + local_irq_restore(flags); + return; + } + } + gtpmdev.flags &= ~TPMIF_REQ_READY; + local_irq_restore(flags); +} + +inline void tpmif_req_finished(tpmif_t* tpmif) { + tpmif->flags &= ~TPMIF_REQ_READY; + tpmdev_check_req(); +} + +int __get_tpmif_index(int st, int n, domid_t domid, unsigned int handle) +{ + int i = st + n /2; + tpmif_t* tmp; + + if( n <= 0 ) + return -1; + + tmp = gtpmdev.tpmlist[i]; + if(domid == tmp->domid && tmp->handle == handle) { + return i; + } else if ( (domid < tmp->domid) || + (domid == tmp->domid && handle < tmp->handle)) { + return __get_tpmif_index(st, n/2, domid, handle); + } else { + return __get_tpmif_index(i + 1, n/2 - ((n +1) % 2), domid, handle); + } +} + +/* Returns the array index of the tpmif domid/handle. Returns -1 if no such tpmif exists */ +int get_tpmif_index(domid_t domid, unsigned int handle) +{ + int flags; + int index; + local_irq_save(flags); + index = __get_tpmif_index(0, gtpmdev.num_tpms, domid, handle); + local_irq_restore(flags); + return index; +} + +/* Returns the tpmif domid/handle or NULL if none exists */ +tpmif_t* get_tpmif(domid_t domid, unsigned int handle) +{ + int flags; + int i; + tpmif_t* ret; + local_irq_save(flags); + i = get_tpmif_index(domid, handle); + if (i < 0) { + ret = NULL; + } else { + ret = gtpmdev.tpmlist[i]; + } + local_irq_restore(flags); + return ret; +} + +/* Remove the given tpmif. Returns 0 if it was removed, -1 if it was not removed */ +int remove_tpmif(tpmif_t* tpmif) +{ + int i, j; + char* err; + int flags; + local_irq_save(flags); + + /* Find the index in the array if it exists */ + i = get_tpmif_index(tpmif->domid, tpmif->handle); + if (i < 0) { + goto error; + } + + /* Remove the interface from the list */ + for(j = i; j < gtpmdev.num_tpms - 1; ++j) { + gtpmdev.tpmlist[j] = gtpmdev.tpmlist[j+1]; + } + gtpmdev.tpmlist[j] = NULL; + --gtpmdev.num_tpms; + + /* If removed tpm was the only ready tpm, then we need to check and turn off the ready flag */ + tpmdev_check_req(); + + local_irq_restore(flags); + + /* Stop listening for events on this tpm interface */ + if((err = xenbus_unwatch_path_token(XBT_NIL, tpmif->fe_state_path, tpmif->fe_state_path))) { + TPMBACK_ERR("Unable to unwatch path token `%s' Error was %s Ignoring..\n", tpmif->fe_state_path, err); + free(err); + } + + return 0; +error: + local_irq_restore(flags); + return -1; +} + +/* Insert tpmif into dev->tpmlist. Returns 0 on success and non zero on error. + * It is an error to insert a tpmif with the same domid and handle + * number + * as something already in the list */ +int insert_tpmif(tpmif_t* tpmif) +{ + int flags; + unsigned int i, j; + tpmif_t* tmp; + char* err; + + local_irq_save(flags); + + /*Check if we need to allocate more space */ + if (gtpmdev.num_tpms == gtpmdev.num_alloc) { + gtpmdev.num_alloc *= 2; + gtpmdev.tpmlist = realloc(gtpmdev.tpmlist, gtpmdev.num_alloc); + } + + /*Find where to put the new interface */ + for(i = 0; i < gtpmdev.num_tpms; ++i) + { + tmp = gtpmdev.tpmlist[i]; + if(tpmif->domid == tmp->domid && tpmif->handle == tmp->handle) { + TPMBACK_ERR("Tried to insert duplicate tpm interface %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle); + goto error; + } + if((tpmif->domid < tmp->domid) || + (tpmif->domid == tmp->domid && tpmif->handle < tmp->handle)) { + break; + } + } + + /*Shift all the tpm pointers past i down one */ + for(j = gtpmdev.num_tpms; j > i; --j) { + gtpmdev.tpmlist[j] = gtpmdev.tpmlist[j-1]; + } + + /*Add the new interface */ + gtpmdev.tpmlist[i] = tpmif; + ++gtpmdev.num_tpms; + + /*Should not be needed, anything inserted with ready flag is probably an error */ + tpmdev_check_req(); + + local_irq_restore(flags); + + /*Listen for state changes on the new interface */ + if((err = xenbus_watch_path_token(XBT_NIL, tpmif->fe_state_path, tpmif->fe_state_path, >pmdev.events))) + { + /* if we got an error here we should carefully remove the interface and then return */ + TPMBACK_ERR("Unable to watch path token `%s' Error was %s\n", tpmif->fe_state_path, err); + free(err); + remove_tpmif(tpmif); + goto error_post_irq; + } + + return 0; +error: + local_irq_restore(flags); +error_post_irq: + return -1; +} + + +/***************** + * CHANGE BACKEND STATE + * *****************/ +/*Attempts to change the backend state in xenstore + * returns 0 on success and non-zero on error */ +int tpmif_change_state(tpmif_t* tpmif, enum xenbus_state state) +{ + char path[512]; + char *value; + char *err; + enum xenbus_state readst; + TPMBACK_DEBUG("Backend state change %u/%u from=%d to=%d\n", (unsigned int) tpmif->domid, tpmif->handle, tpmif->state, state); + if (tpmif->state == state) + return 0; + + snprintf(path, 512, "backend/vtpm/%u/%u/state", (unsigned int) tpmif->domid, tpmif->handle); + + if((err = xenbus_read(XBT_NIL, path, &value))) { + TPMBACK_ERR("Unable to read backend state %s, error was %s\n", path, err); + free(err); + return -1; + } + if(sscanf(value, "%d", &readst) != 1) { + TPMBACK_ERR("Non integer value (%s) in %s ??\n", value, path); + free(value); + return -1; + } + free(value); + + /* It's possible that the backend state got updated by hotplug or something else behind our back */ + if(readst != tpmif->state) { + TPMBACK_DEBUG("tpm interface state was %d but xenstore state was %d!\n", tpmif->state, readst); + tpmif->state = readst; + } + + /*If if the state isnt changing, then we dont update xenstore b/c we dont want to fire extraneous events */ + if(tpmif->state == state) { + return 0; + } + + /*update xenstore*/ + snprintf(path, 512, "backend/vtpm/%u/%u", (unsigned int) tpmif->domid, tpmif->handle); + if((err = xenbus_printf(XBT_NIL, path, "state", "%u", state))) { + TPMBACK_ERR("Error writing to xenstore %s, error was %s new state=%d\n", path, err, state); + free(err); + return -1; + } + + tpmif->state = state; + + return 0; +} +/********************************** + * TPMIF CREATION AND DELETION + * *******************************/ +inline tpmif_t* __init_tpmif(domid_t domid, unsigned int handle) +{ + tpmif_t* tpmif; + tpmif = malloc(sizeof(*tpmif)); + tpmif->domid = domid; + tpmif->handle = handle; + tpmif->fe_path = NULL; + tpmif->fe_state_path = NULL; + tpmif->state = XenbusStateInitialising; + tpmif->status = DISCONNECTED; + tpmif->tx = NULL; + tpmif->pages = NULL; + tpmif->flags = 0; + tpmif->uuid = NULL; + return tpmif; +} + +void __free_tpmif(tpmif_t* tpmif) +{ + if(tpmif->pages) { + free(tpmif->pages); + } + if(tpmif->fe_path) { + free(tpmif->fe_path); + } + if(tpmif->fe_state_path) { + free(tpmif->fe_state_path); + } + if(tpmif->uuid) { + free(tpmif->uuid); + } + free(tpmif); +} +/* Creates a new tpm interface, adds it to the sorted array and returns it. + * returns NULL on error + * If the tpm interface already exists, it is returned*/ +tpmif_t* new_tpmif(domid_t domid, unsigned int handle) +{ + tpmif_t* tpmif; + char* err; + char path[512]; + + /* Make sure we haven't already created this tpm + * Double events can occur */ + if((tpmif = get_tpmif(domid, handle)) != NULL) { + return tpmif; + } + + tpmif = __init_tpmif(domid, handle); + + /* Get the uuid from xenstore */ + snprintf(path, 512, "backend/vtpm/%u/%u/uuid", (unsigned int) domid, handle); + if((err = xenbus_read(XBT_NIL, path, &tpmif->uuid))) { + TPMBACK_ERR("Error reading %s, Error = %s\n", path, err); + free(err); + goto error; + } + + /* Do the exclusive uuid check now */ + if(gtpmdev.exclusive_uuids != NULL) { + char** ptr; + + /* Check that its in the whitelist */ + for(ptr = gtpmdev.exclusive_uuids; *ptr != NULL; ++ptr) { + if(!strcmp(tpmif->uuid, *ptr)) { + break; + } + } + /* If *ptr == NULL then we went through the whole list without a match, so close the connection */ + if(*ptr == NULL) { + tpmif_change_state(tpmif, XenbusStateClosed); + TPMBACK_ERR("Frontend %u/%u tried to connect with invalid uuid=%s\n", (unsigned int) domid, handle, tpmif->uuid); + goto error; + } + } + + /* allocate pages to be used for shared mapping */ + if((tpmif->pages = malloc(sizeof(void*) * TPMIF_TX_RING_SIZE)) == NULL) { + goto error; + } + memset(tpmif->pages, 0, sizeof(void*) * TPMIF_TX_RING_SIZE); + + if(tpmif_change_state(tpmif, XenbusStateInitWait)) { + goto error; + } + + snprintf(path, 512, "backend/vtpm/%u/%u/frontend", (unsigned int) domid, handle); + if((err = xenbus_read(XBT_NIL, path, &tpmif->fe_path))) { + TPMBACK_ERR("Error creating new tpm instance xenbus_read(%s), Error = %s", path, err); + free(err); + goto error; + } + + /*Set the state path */ + tpmif->fe_state_path = malloc(strlen(tpmif->fe_path) + 7); + strcpy(tpmif->fe_state_path, tpmif->fe_path); + strcat(tpmif->fe_state_path, "/state"); + + if(insert_tpmif(tpmif)) { + goto error; + } + TPMBACK_DEBUG("New tpmif %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle); + /* Do the callback now */ + if(gtpmdev.open_callback) { + gtpmdev.open_callback(tpmif->domid, tpmif->handle); + } + return tpmif; +error: + __free_tpmif(tpmif); + return NULL; + +} + +/* Removes tpmif from dev->tpmlist and frees it's memory usage */ +void free_tpmif(tpmif_t* tpmif) +{ + char* err; + char path[512]; + TPMBACK_DEBUG("Free tpmif %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle); + if(tpmif->flags & TPMIF_CLOSED) { + TPMBACK_ERR("Tried to free an instance twice! Theres a bug somewhere!\n"); + BUG(); + } + tpmif->flags = TPMIF_CLOSED; + + tpmif_change_state(tpmif, XenbusStateClosing); + + /* Unmap share page and unbind event channel */ + if(tpmif->status == CONNECTED) { + tpmif->status = DISCONNECTING; + mask_evtchn(tpmif->evtchn); + + if(gntmap_munmap(>pmdev.map, (unsigned long)tpmif->tx, 1)) { + TPMBACK_ERR("%u/%u Error occured while trying to unmap shared page\n", (unsigned int) tpmif->domid, tpmif->handle); + } + + unbind_evtchn(tpmif->evtchn); + } + tpmif->status = DISCONNECTED; + tpmif_change_state(tpmif, XenbusStateClosed); + + /* Do the callback now */ + if(gtpmdev.close_callback) { + gtpmdev.close_callback(tpmif->domid, tpmif->handle); + } + + /* remove from array */ + remove_tpmif(tpmif); + + /* Wake up anyone possibly waiting on this interface and let them exit */ + wake_up(&waitq); + schedule(); + + /* Remove the old xenbus entries */ + snprintf(path, 512, "backend/vtpm/%u/%u", (unsigned int) tpmif->domid, tpmif->handle); + if((err = xenbus_rm(XBT_NIL, path))) { + TPMBACK_ERR("Error cleaning up xenbus entries path=%s error=%s\n", path, err); + free(err); + } + + TPMBACK_LOG("Frontend %u/%u disconnected\n", (unsigned int) tpmif->domid, tpmif->handle); + + /* free memory */ + __free_tpmif(tpmif); + +} + +/********************** + * REMAINING TPMBACK FUNCTIONS + * ********************/ + +/*Event channel handler */ +void tpmback_handler(evtchn_port_t port, struct pt_regs *regs, void *data) +{ + tpmif_t* tpmif = (tpmif_t*) data; + tpmif_tx_request_t* tx = &tpmif->tx->ring[0].req; + /* Throw away 0 size events, these can trigger from event channel unmasking */ + if(tx->size == 0) + return; + + TPMBACK_DEBUG("EVENT CHANNEL FIRE %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle); + tpmif_req_ready(tpmif); + wake_up(&waitq); + +} + +/* Connect to frontend */ +int connect_fe(tpmif_t* tpmif) +{ + char path[512]; + char* err, *value; + uint32_t domid; + grant_ref_t ringref; + evtchn_port_t evtchn; + + /* If already connected then quit */ + if (tpmif->status == CONNECTED) { + TPMBACK_DEBUG("%u/%u tried to connect while it was already connected?\n", (unsigned int) tpmif->domid, tpmif->handle); + return 0; + } + + /* Fetch the grant reference */ + snprintf(path, 512, "%s/ring-ref", tpmif->fe_path); + if((err = xenbus_read(XBT_NIL, path, &value))) { + TPMBACK_ERR("Error creating new tpm instance xenbus_read(%s) Error = %s", path, err); + free(err); + return -1; + } + if(sscanf(value, "%d", &ringref) != 1) { + TPMBACK_ERR("Non integer value (%s) in %s ??\n", value, path); + free(value); + return -1; + } + free(value); + + + /* Fetch the event channel*/ + snprintf(path, 512, "%s/event-channel", tpmif->fe_path); + if((err = xenbus_read(XBT_NIL, path, &value))) { + TPMBACK_ERR("Error creating new tpm instance xenbus_read(%s) Error = %s", path, err); + free(err); + return -1; + } + if(sscanf(value, "%d", &evtchn) != 1) { + TPMBACK_ERR("Non integer value (%s) in %s ??\n", value, path); + free(value); + return -1; + } + free(value); + + domid = tpmif->domid; + if((tpmif->tx = gntmap_map_grant_refs(>pmdev.map, 1, &domid, 0, &ringref, PROT_READ | PROT_WRITE)) == NULL) { + TPMBACK_ERR("Failed to map grant reference %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle); + return -1; + } + memset(tpmif->tx, 0, PAGE_SIZE); + + /*Bind the event channel */ + if((evtchn_bind_interdomain(tpmif->domid, evtchn, tpmback_handler, tpmif, &tpmif->evtchn))) + { + TPMBACK_ERR("%u/%u Unable to bind to interdomain event channel!\n", (unsigned int) tpmif->domid, tpmif->handle); + goto error_post_map; + } + unmask_evtchn(tpmif->evtchn); + + /* Write the ready flag and change status to connected */ + snprintf(path, 512, "backend/vtpm/%u/%u", (unsigned int) tpmif->domid, tpmif->handle); + if((err = xenbus_printf(XBT_NIL, path, "ready", "%u", 1))) { + TPMBACK_ERR("%u/%u Unable to write ready flag on connect_fe()\n", (unsigned int) tpmif->domid, tpmif->handle); + free(err); + goto error_post_evtchn; + } + tpmif->status = CONNECTED; + if((tpmif_change_state(tpmif, XenbusStateConnected))){ + goto error_post_evtchn; + } + + TPMBACK_LOG("Frontend %u/%u connected\n", (unsigned int) tpmif->domid, tpmif->handle); + + return 0; +error_post_evtchn: + mask_evtchn(tpmif->evtchn); + unbind_evtchn(tpmif->evtchn); +error_post_map: + gntmap_munmap(>pmdev.map, (unsigned long)tpmif->tx, 1); + return -1; +} + +static int frontend_changed(tpmif_t* tpmif) +{ + int state = xenbus_read_integer(tpmif->fe_state_path); + if(state < 0) { + state = XenbusStateUnknown; + } + + TPMBACK_DEBUG("Frontend %u/%u state changed to %d\n", (unsigned int) tpmif->domid, tpmif->handle, state); + + switch (state) { + case XenbusStateInitialising: + case XenbusStateInitialised: + break; + + case XenbusStateConnected: + if(connect_fe(tpmif)) { + TPMBACK_ERR("Failed to connect to front end %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle); + tpmif_change_state(tpmif, XenbusStateClosed); + return -1; + } + break; + + case XenbusStateClosing: + tpmif_change_state(tpmif, XenbusStateClosing); + break; + + case XenbusStateUnknown: /* keep it here */ + case XenbusStateClosed: + free_tpmif(tpmif); + break; + + default: + TPMBACK_DEBUG("BAD STATE CHANGE %u/%u state = %d for tpmif\n", (unsigned int) tpmif->domid, tpmif->handle, state); + return -1; + } + return 0; +} + + +/* parses the string that comes out of xenbus_watch_wait_return. */ +static int parse_eventstr(const char* evstr, domid_t* domid, unsigned int* handle) +{ + int ret; + char cmd[40]; + char* err; + char* value; + unsigned int udomid = 0; + tpmif_t* tpmif; + /* First check for new frontends, this occurs when /backend/vtpm// gets created. Note we what the sscanf to fail on the last %s */ + if (sscanf(evstr, "backend/vtpm/%u/%u/%40s", &udomid, handle, cmd) == 2) { + *domid = udomid; + /* Make sure the entry exists, if this event triggers because the entry dissapeared then ignore it */ + if((err = xenbus_read(XBT_NIL, evstr, &value))) { + free(err); + return EV_NONE; + } + free(value); + /* Make sure the tpmif entry does not already exist, this should not happen */ + if((tpmif = get_tpmif(*domid, *handle)) != NULL) { + TPMBACK_DEBUG("Duplicate tpm entries! %u %u\n", tpmif->domid, tpmif->handle); + return EV_NONE; + } + return EV_NEWFE; + } else if((ret = sscanf(evstr, "/local/domain/%u/device/vtpm/%u/%40s", &udomid, handle, cmd)) == 3) { + *domid = udomid; + if (!strcmp(cmd, "state")) + return EV_STCHNG; + } + return EV_NONE; +} + +void handle_backend_event(char* evstr) { + tpmif_t* tpmif; + domid_t domid; + unsigned int handle; + int event; + + TPMBACK_DEBUG("Xenbus Event: %s\n", evstr); + + event = parse_eventstr(evstr, &domid, &handle); + + switch(event) { + case EV_NEWFE: + if(new_tpmif(domid, handle) == NULL) { + TPMBACK_ERR("Failed to create new tpm instance %u/%u\n", (unsigned int) domid, handle); + } + wake_up(&waitq); + break; + case EV_STCHNG: + if((tpmif = get_tpmif(domid, handle))) { + frontend_changed(tpmif); + } else { + TPMBACK_DEBUG("Event Received for non-existant tpm! instance=%u/%u xenbus_event=%s\n", (unsigned int) domid, handle, evstr); + } + break; + } +} + +/* Runs through the given path and creates events recursively + * for all of its children. + * @path - xenstore path to scan */ +static void generate_backend_events(const char* path) +{ + char* err; + int i, len; + char **dirs; + char *entry; + + if((err = xenbus_ls(XBT_NIL, path, &dirs)) != NULL) { + free(err); + return; + } + + for(i = 0; dirs[i] != NULL; ++i) { + len = strlen(path) + strlen(dirs[i]) + 2; + entry = malloc(len); + snprintf(entry, len, "%s/%s", path, dirs[i]); + + /* Generate and handle event for the entry itself */ + handle_backend_event(entry); + + /* Do children */ + generate_backend_events(entry); + + /* Cleanup */ + free(entry); + free(dirs[i]); + } + free(dirs); + return; +} + +char* tpmback_get_uuid(domid_t domid, unsigned int handle) +{ + tpmif_t* tpmif; + if((tpmif = get_tpmif(domid, handle)) == NULL) { + TPMBACK_DEBUG("get_uuid() failed, %u/%u is an invalid frontend\n", (unsigned int) domid, handle); + return NULL; + } + + return tpmif->uuid; +} + +void tpmback_set_open_callback(void (*cb)(domid_t, unsigned int)) +{ + gtpmdev.open_callback = cb; +} +void tpmback_set_close_callback(void (*cb)(domid_t, unsigned int)) +{ + gtpmdev.close_callback = cb; +} +void tpmback_set_suspend_callback(void (*cb)(domid_t, unsigned int)) +{ + gtpmdev.suspend_callback = cb; +} +void tpmback_set_resume_callback(void (*cb)(domid_t, unsigned int)) +{ + gtpmdev.resume_callback = cb; +} + +static void event_listener(void) +{ + const char* bepath = "backend/vtpm"; + char **path; + char* err; + + /* Setup the backend device watch */ + if((err = xenbus_watch_path_token(XBT_NIL, bepath, bepath, >pmdev.events)) != NULL) { + TPMBACK_ERR("xenbus_watch_path_token(%s) failed with error %s!\n", bepath, err); + free(err); + goto egress; + } + + /* Check for any frontends that connected before we set the watch. + * This is almost guaranteed to happen if both domains are started + * immediatly one after the other. + * We do this by manually generating events on everything in the backend + * path */ + generate_backend_events(bepath); + + /* Wait and listen for changes in frontend connections */ + while(1) { + path = xenbus_wait_for_watch_return(>pmdev.events); + + /*If quit flag was set then exit */ + if(gtpmdev.flags & TPMIF_CLOSED) { + TPMBACK_DEBUG("listener thread got quit event. Exiting..\n"); + free(path); + break; + } + handle_backend_event(*path); + free(path); + + } + + if((err = xenbus_unwatch_path_token(XBT_NIL, bepath, bepath)) != NULL) { + free(err); + } +egress: + return; +} + +void event_thread(void* p) { + event_listener(); +} + +void init_tpmback(char** exclusive_uuids) +{ + if(!globalinit) { + init_waitqueue_head(&waitq); + globalinit = 1; + } + printk("============= Init TPM BACK ================\n"); + gtpmdev.tpmlist = malloc(sizeof(tpmif_t*) * DEF_ARRAY_SIZE); + gtpmdev.num_alloc = DEF_ARRAY_SIZE; + gtpmdev.num_tpms = 0; + gtpmdev.flags = 0; + gtpmdev.exclusive_uuids = exclusive_uuids; + + gtpmdev.open_callback = gtpmdev.close_callback = NULL; + gtpmdev.suspend_callback = gtpmdev.resume_callback = NULL; + + eventthread = create_thread("tpmback-listener", event_thread, NULL); + +} + +void shutdown_tpmback(void) +{ + /* Disable callbacks */ + gtpmdev.open_callback = gtpmdev.close_callback = NULL; + gtpmdev.suspend_callback = gtpmdev.resume_callback = NULL; + + TPMBACK_LOG("Shutting down tpm backend\n"); + /* Set the quit flag */ + gtpmdev.flags = TPMIF_CLOSED; + + //printk("num tpms is %d\n", gtpmdev.num_tpms); + /*Free all backend instances */ + while(gtpmdev.num_tpms) { + free_tpmif(gtpmdev.tpmlist[0]); + } + free(gtpmdev.tpmlist); + gtpmdev.tpmlist = NULL; + gtpmdev.num_alloc = 0; + + /* Wake up anyone possibly waiting on the device and let them exit */ + wake_up(&waitq); + schedule(); +} + +inline void init_tpmcmd(tpmcmd_t* tpmcmd, domid_t domid, unsigned int handle, char* uuid) +{ + tpmcmd->domid = domid; + tpmcmd->handle = handle; + tpmcmd->uuid = uuid; + tpmcmd->req = NULL; + tpmcmd->req_len = 0; + tpmcmd->resp = NULL; + tpmcmd->resp_len = 0; +} + +tpmcmd_t* get_request(tpmif_t* tpmif) { + tpmcmd_t* cmd; + tpmif_tx_request_t* tx; + int offset; + int tocopy; + int i; + uint32_t domid; + int flags; + + local_irq_save(flags); + + /* Allocate the cmd object to hold the data */ + if((cmd = malloc(sizeof(*cmd))) == NULL) { + goto error; + } + init_tpmcmd(cmd, tpmif->domid, tpmif->handle, tpmif->uuid); + + tx = &tpmif->tx->ring[0].req; + cmd->req_len = tx->size; + /* Allocate the buffer */ + if(cmd->req_len) { + if((cmd->req = malloc(cmd->req_len)) == NULL) { + goto error; + } + } + /* Copy the bits from the shared pages */ + offset = 0; + for(i = 0; i < TPMIF_TX_RING_SIZE && offset < cmd->req_len; ++i) { + tx = &tpmif->tx->ring[i].req; + + /* Map the page with the data */ + domid = (uint32_t)tpmif->domid; + if((tpmif->pages[i] = gntmap_map_grant_refs(>pmdev.map, 1, &domid, 0, &tx->ref, PROT_READ)) == NULL) { + TPMBACK_ERR("%u/%u Unable to map shared page during read!\n", (unsigned int) tpmif->domid, tpmif->handle); + goto error; + } + + /* do the copy now */ + tocopy = min(cmd->req_len - offset, PAGE_SIZE); + memcpy(&cmd->req[offset], tpmif->pages[i], tocopy); + offset += tocopy; + + /* release the page */ + gntmap_munmap(>pmdev.map, (unsigned long)tpmif->pages[i], 1); + + } + +#ifdef TPMBACK_PRINT_DEBUG + TPMBACK_DEBUG("Received Tpm Command from %u/%u of size %u", (unsigned int) tpmif->domid, tpmif->handle, cmd->req_len); + for(i = 0; i < cmd->req_len; ++i) { + if (!(i % 30)) { + TPMBACK_DEBUG_MORE("\n"); + } + TPMBACK_DEBUG_MORE("%02hhX ", cmd->req[i]); + } + TPMBACK_DEBUG_MORE("\n\n"); +#endif + + local_irq_restore(flags); + return cmd; +error: + if(cmd != NULL) { + if (cmd->req != NULL) { + free(cmd->req); + cmd->req = NULL; + } + free(cmd); + cmd = NULL; + } + local_irq_restore(flags); + return NULL; + +} + +void send_response(tpmcmd_t* cmd, tpmif_t* tpmif) +{ + tpmif_tx_request_t* tx; + int offset; + int i; + uint32_t domid; + int tocopy; + int flags; + + local_irq_save(flags); + + tx = &tpmif->tx->ring[0].req; + tx->size = cmd->resp_len; + + offset = 0; + for(i = 0; i < TPMIF_TX_RING_SIZE && offset < cmd->resp_len; ++i) { + tx = &tpmif->tx->ring[i].req; + + /* Map the page with the data */ + domid = (uint32_t)tpmif->domid; + if((tpmif->pages[i] = gntmap_map_grant_refs(>pmdev.map, 1, &domid, 0, &tx->ref, PROT_WRITE)) == NULL) { + TPMBACK_ERR("%u/%u Unable to map shared page during write!\n", (unsigned int) tpmif->domid, tpmif->handle); + goto error; + } + + /* do the copy now */ + tocopy = min(cmd->resp_len - offset, PAGE_SIZE); + memcpy(tpmif->pages[i], &cmd->resp[offset], tocopy); + offset += tocopy; + + /* release the page */ + gntmap_munmap(>pmdev.map, (unsigned long)tpmif->pages[i], 1); + + } + +#ifdef TPMBACK_PRINT_DEBUG + TPMBACK_DEBUG("Sent response to %u/%u of size %u", (unsigned int) tpmif->domid, tpmif->handle, cmd->resp_len); + for(i = 0; i < cmd->resp_len; ++i) { + if (!(i % 30)) { + TPMBACK_DEBUG_MORE("\n"); + } + TPMBACK_DEBUG_MORE("%02hhX ", cmd->resp[i]); + } + TPMBACK_DEBUG_MORE("\n\n"); +#endif + /* clear the ready flag and send the event channel notice to the frontend */ + tpmif_req_finished(tpmif); + notify_remote_via_evtchn(tpmif->evtchn); +error: + local_irq_restore(flags); + return; +} + +tpmcmd_t* tpmback_req_any(void) +{ + int i; + /* Block until something has a request */ + wait_event(waitq, (gtpmdev.flags & (TPMIF_REQ_READY | TPMIF_CLOSED))); + + /* Check if were shutting down */ + if(gtpmdev.flags & TPMIF_CLOSED) { + /* if something was waiting for us to give up the queue so it can shutdown, let it finish */ + schedule(); + return NULL; + } + + for(i = 0; i < gtpmdev.num_tpms; ++i) { + if(gtpmdev.tpmlist[i]->flags & TPMIF_REQ_READY) { + return get_request(gtpmdev.tpmlist[i]); + } + } + + TPMBACK_ERR("backend request ready flag was set but no interfaces were actually ready\n"); + return NULL; +} + +tpmcmd_t* tpmback_req(domid_t domid, unsigned int handle) +{ + tpmif_t* tpmif; + tpmif = get_tpmif(domid, handle); + if(tpmif == NULL) { + return NULL; + } + + wait_event(waitq, (tpmif->flags & (TPMIF_REQ_READY | TPMIF_CLOSED) || gtpmdev.flags & TPMIF_CLOSED)); + + /* Check if were shutting down */ + if(tpmif->flags & TPMIF_CLOSED || gtpmdev.flags & TPMIF_CLOSED) { + /* if something was waiting for us to give up the queue so it can free this instance, let it finish */ + schedule(); + return NULL; + } + + return get_request(tpmif); +} + +void tpmback_resp(tpmcmd_t* tpmcmd) +{ + tpmif_t* tpmif; + + /* Get the associated interface, if it doesnt exist then just quit */ + tpmif = get_tpmif(tpmcmd->domid, tpmcmd->handle); + if(tpmif == NULL) { + TPMBACK_ERR("Tried to send a reponse to non existant frontend %u/%u\n", (unsigned int) tpmcmd->domid, tpmcmd->handle); + goto end; + } + + if(!(tpmif->flags & TPMIF_REQ_READY)) { + TPMBACK_ERR("Tried to send response to a frontend that was not waiting for one %u/%u\n", (unsigned int) tpmcmd->domid, tpmcmd->handle); + goto end; + } + + /* Send response to frontend */ + send_response(tpmcmd, tpmif); + +end: + if(tpmcmd->req != NULL) { + free(tpmcmd->req); + } + free(tpmcmd); + return; +} + +int tpmback_wait_for_frontend_connect(domid_t *domid, unsigned int *handle) +{ + tpmif_t* tpmif; + int flags; + wait_event(waitq, ((gtpmdev.num_tpms > 0) || gtpmdev.flags & TPMIF_CLOSED)); + if(gtpmdev.flags & TPMIF_CLOSED) { + return -1; + } + local_irq_save(flags); + tpmif = gtpmdev.tpmlist[0]; + *domid = tpmif->domid; + *handle = tpmif->handle; + local_irq_restore(flags); + + return 0; +} + +int tpmback_num_frontends(void) +{ + return gtpmdev.num_tpms; +} diff --git a/extras/mini-os/tpmfront.c b/extras/mini-os/tpmfront.c new file mode 100644 index 0000000..84fc6af --- /dev/null +++ b/extras/mini-os/tpmfront.c @@ -0,0 +1,607 @@ +/* + * Copyright (c) 2010-2012 United States Government, as represented by + * the Secretary of Defense. All rights reserved. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version 2 + * of the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + * + * Based upon the files: + * drivers/char/tpm/tpm_vtpm.c + * drivers/char/tpm/tpm_xen.c + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +//#define TPMFRONT_PRINT_DEBUG +#ifdef TPMFRONT_PRINT_DEBUG +#define TPMFRONT_DEBUG(fmt,...) printk("Tpmfront:Debug("__FILE__":%d) " fmt, __LINE__, ##__VA_ARGS__) +#define TPMFRONT_DEBUG_MORE(fmt,...) printk(fmt, ##__VA_ARGS__) +#else +#define TPMFRONT_DEBUG(fmt,...) +#endif +#define TPMFRONT_ERR(fmt,...) printk("Tpmfront:Error " fmt, ##__VA_ARGS__) +#define TPMFRONT_LOG(fmt,...) printk("Tpmfront:Info " fmt, ##__VA_ARGS__) + +#define min(a,b) (((a) < (b)) ? (a) : (b)) + +void tpmfront_handler(evtchn_port_t port, struct pt_regs *regs, void *data) { + struct tpmfront_dev* dev = (struct tpmfront_dev*) data; + /*If we get a response when we didnt make a request, just ignore it */ + if(!dev->waiting) { + return; + } + + dev->waiting = 0; +#ifdef HAVE_LIBC + if(dev->fd >= 0) { + files[dev->fd].read = 1; + } +#endif + wake_up(&dev->waitq); +} + +static int publish_xenbus(struct tpmfront_dev* dev) { + xenbus_transaction_t xbt; + int retry; + char* err; + /* Write the grant reference and event channel to xenstore */ +again: + if((err = xenbus_transaction_start(&xbt))) { + TPMFRONT_ERR("Unable to start xenbus transaction, error was %s\n", err); + free(err); + return -1; + } + + if((err = xenbus_printf(xbt, dev->nodename, "ring-ref", "%u", (unsigned int) dev->ring_ref))) { + TPMFRONT_ERR("Unable to write %s/ring-ref, error was %s\n", dev->nodename, err); + free(err); + goto abort_transaction; + } + + if((err = xenbus_printf(xbt, dev->nodename, "event-channel", "%u", (unsigned int) dev->evtchn))) { + TPMFRONT_ERR("Unable to write %s/event-channel, error was %s\n", dev->nodename, err); + free(err); + goto abort_transaction; + } + + if((err = xenbus_transaction_end(xbt, 0, &retry))) { + TPMFRONT_ERR("Unable to complete xenbus transaction, error was %s\n", err); + free(err); + return -1; + } + if(retry) { + goto again; + } + + return 0; +abort_transaction: + if((err = xenbus_transaction_end(xbt, 1, &retry))) { + free(err); + } + return -1; +} + +static int wait_for_backend_connect(xenbus_event_queue* events, char* path) +{ + int state; + + TPMFRONT_LOG("Waiting for backend connection..\n"); + /* Wait for the backend to connect */ + while(1) { + state = xenbus_read_integer(path); + if ( state < 0) + state = XenbusStateUnknown; + switch(state) { + /* Bad states, we quit with error */ + case XenbusStateUnknown: + case XenbusStateClosing: + case XenbusStateClosed: + TPMFRONT_ERR("Unable to connect to backend\n"); + return -1; + /* If backend is connected then break out of loop */ + case XenbusStateConnected: + TPMFRONT_LOG("Backend Connected\n"); + return 0; + default: + xenbus_wait_for_watch(events); + } + } + +} + +static int wait_for_backend_closed(xenbus_event_queue* events, char* path) +{ + int state; + + TPMFRONT_LOG("Waiting for backend to close..\n"); + while(1) { + state = xenbus_read_integer(path); + if ( state < 0) + state = XenbusStateUnknown; + switch(state) { + case XenbusStateUnknown: + TPMFRONT_ERR("Backend Unknown state, forcing shutdown\n"); + return -1; + case XenbusStateClosed: + TPMFRONT_LOG("Backend Closed\n"); + return 0; + default: + xenbus_wait_for_watch(events); + } + } + +} + +static int wait_for_backend_state_changed(struct tpmfront_dev* dev, XenbusState state) { + char* err; + int ret = 0; + xenbus_event_queue events = NULL; + char path[512]; + + snprintf(path, 512, "%s/state", dev->bepath); + /*Setup the watch to wait for the backend */ + if((err = xenbus_watch_path_token(XBT_NIL, path, path, &events))) { + TPMFRONT_ERR("Could not set a watch on %s, error was %s\n", path, err); + free(err); + return -1; + } + + /* Do the actual wait loop now */ + switch(state) { + case XenbusStateConnected: + ret = wait_for_backend_connect(&events, path); + break; + case XenbusStateClosed: + ret = wait_for_backend_closed(&events, path); + break; + default: + break; + } + + if((err = xenbus_unwatch_path_token(XBT_NIL, path, path))) { + TPMFRONT_ERR("Unable to unwatch %s, error was %s, ignoring..\n", path, err); + free(err); + } + return ret; +} + +static int tpmfront_connect(struct tpmfront_dev* dev) +{ + char* err; + /* Create shared page */ + dev->tx = (tpmif_tx_interface_t*) alloc_page(); + if(dev->tx == NULL) { + TPMFRONT_ERR("Unable to allocate page for shared memory\n"); + goto error; + } + memset(dev->tx, 0, PAGE_SIZE); + dev->ring_ref = gnttab_grant_access(dev->bedomid, virt_to_mfn(dev->tx), 0); + TPMFRONT_DEBUG("grant ref is %lu\n", (unsigned long) dev->ring_ref); + + /*Create event channel */ + if(evtchn_alloc_unbound(dev->bedomid, tpmfront_handler, dev, &dev->evtchn)) { + TPMFRONT_ERR("Unable to allocate event channel\n"); + goto error_postmap; + } + unmask_evtchn(dev->evtchn); + TPMFRONT_DEBUG("event channel is %lu\n", (unsigned long) dev->evtchn); + + /* Write the entries to xenstore */ + if(publish_xenbus(dev)) { + goto error_postevtchn; + } + + /* Change state to connected */ + dev->state = XenbusStateConnected; + + /* Tell the backend that we are ready */ + if((err = xenbus_printf(XBT_NIL, dev->nodename, "state", "%u", dev->state))) { + TPMFRONT_ERR("Unable to write to xenstore %s/state, value=%u", dev->nodename, XenbusStateConnected); + free(err); + goto error; + } + + return 0; +error_postevtchn: + mask_evtchn(dev->evtchn); + unbind_evtchn(dev->evtchn); +error_postmap: + gnttab_end_access(dev->ring_ref); + free_page(dev->tx); +error: + return -1; +} + +struct tpmfront_dev* init_tpmfront(const char* _nodename) +{ + struct tpmfront_dev* dev; + const char* nodename; + char path[512]; + char* value, *err; + unsigned long long ival; + int i; + + printk("============= Init TPM Front ================\n"); + + dev = malloc(sizeof(struct tpmfront_dev)); + memset(dev, 0, sizeof(struct tpmfront_dev)); + +#ifdef HAVE_LIBC + dev->fd = -1; +#endif + + nodename = _nodename ? _nodename : "device/vtpm/0"; + dev->nodename = strdup(nodename); + + init_waitqueue_head(&dev->waitq); + + /* Get backend domid */ + snprintf(path, 512, "%s/backend-id", dev->nodename); + if((err = xenbus_read(XBT_NIL, path, &value))) { + TPMFRONT_ERR("Unable to read %s during tpmfront initialization! error = %s\n", path, err); + free(err); + goto error; + } + if(sscanf(value, "%llu", &ival) != 1) { + TPMFRONT_ERR("%s has non-integer value (%s)\n", path, value); + free(value); + goto error; + } + free(value); + dev->bedomid = ival; + + /* Get backend xenstore path */ + snprintf(path, 512, "%s/backend", dev->nodename); + if((err = xenbus_read(XBT_NIL, path, &dev->bepath))) { + TPMFRONT_ERR("Unable to read %s during tpmfront initialization! error = %s\n", path, err); + free(err); + goto error; + } + + /* Create and publish grant reference and event channel */ + if (tpmfront_connect(dev)) { + goto error; + } + + /* Wait for backend to connect */ + if( wait_for_backend_state_changed(dev, XenbusStateConnected)) { + goto error; + } + + /* Allocate pages that will contain the messages */ + dev->pages = malloc(sizeof(void*) * TPMIF_TX_RING_SIZE); + if(dev->pages == NULL) { + goto error; + } + memset(dev->pages, 0, sizeof(void*) * TPMIF_TX_RING_SIZE); + for(i = 0; i < TPMIF_TX_RING_SIZE; ++i) { + dev->pages[i] = (void*)alloc_page(); + if(dev->pages[i] == NULL) { + goto error; + } + } + + TPMFRONT_LOG("Initialization Completed successfully\n"); + + return dev; + +error: + shutdown_tpmfront(dev); + return NULL; +} +void shutdown_tpmfront(struct tpmfront_dev* dev) +{ + char* err; + char path[512]; + int i; + tpmif_tx_request_t* tx; + if(dev == NULL) { + return; + } + TPMFRONT_LOG("Shutting down tpmfront\n"); + /* disconnect */ + if(dev->state == XenbusStateConnected) { + dev->state = XenbusStateClosing; + //FIXME: Transaction for this? + /* Tell backend we are closing */ + if((err = xenbus_printf(XBT_NIL, dev->nodename, "state", "%u", (unsigned int) dev->state))) { + free(err); + } + + /* Clean up xenstore entries */ + snprintf(path, 512, "%s/event-channel", dev->nodename); + if((err = xenbus_rm(XBT_NIL, path))) { + free(err); + } + snprintf(path, 512, "%s/ring-ref", dev->nodename); + if((err = xenbus_rm(XBT_NIL, path))) { + free(err); + } + + /* Tell backend we are closed */ + dev->state = XenbusStateClosed; + if((err = xenbus_printf(XBT_NIL, dev->nodename, "state", "%u", (unsigned int) dev->state))) { + TPMFRONT_ERR("Unable to write to %s, error was %s", dev->nodename, err); + free(err); + } + + /* Wait for the backend to close and unmap shared pages, ignore any errors */ + wait_for_backend_state_changed(dev, XenbusStateClosed); + + /* Cleanup any shared pages */ + if(dev->pages) { + for(i = 0; i < TPMIF_TX_RING_SIZE; ++i) { + if(dev->pages[i]) { + tx = &dev->tx->ring[i].req; + if(tx->ref != 0) { + gnttab_end_access(tx->ref); + } + free_page(dev->pages[i]); + } + } + free(dev->pages); + } + + /* Close event channel and unmap shared page */ + mask_evtchn(dev->evtchn); + unbind_evtchn(dev->evtchn); + gnttab_end_access(dev->ring_ref); + + free_page(dev->tx); + + } + + /* Cleanup memory usage */ + if(dev->respbuf) { + free(dev->respbuf); + } + if(dev->bepath) { + free(dev->bepath); + } + if(dev->nodename) { + free(dev->nodename); + } + free(dev); +} + +int tpmfront_send(struct tpmfront_dev* dev, const uint8_t* msg, size_t length) +{ + int i; + tpmif_tx_request_t* tx = NULL; + /* Error Checking */ + if(dev == NULL || dev->state != XenbusStateConnected) { + TPMFRONT_ERR("Tried to send message through disconnected frontend\n"); + return -1; + } + +#ifdef TPMFRONT_PRINT_DEBUG + TPMFRONT_DEBUG("Sending Msg to backend size=%u", (unsigned int) length); + for(i = 0; i < length; ++i) { + if(!(i % 30)) { + TPMFRONT_DEBUG_MORE("\n"); + } + TPMFRONT_DEBUG_MORE("%02X ", msg[i]); + } + TPMFRONT_DEBUG_MORE("\n"); +#endif + + /* Copy to shared pages now */ + for(i = 0; length > 0 && i < TPMIF_TX_RING_SIZE; ++i) { + /* Share the page */ + tx = &dev->tx->ring[i].req; + tx->unused = 0; + tx->addr = virt_to_mach(dev->pages[i]); + tx->ref = gnttab_grant_access(dev->bedomid, virt_to_mfn(dev->pages[i]), 0); + /* Copy the bits to the page */ + tx->size = length > PAGE_SIZE ? PAGE_SIZE : length; + memcpy(dev->pages[i], &msg[i * PAGE_SIZE], tx->size); + + /* Update counters */ + length -= tx->size; + } + dev->waiting = 1; + dev->resplen = 0; +#ifdef HAVE_LIBC + if(dev->fd >= 0) { + files[dev->fd].read = 0; + files[dev->fd].tpmfront.respgot = 0; + files[dev->fd].tpmfront.offset = 0; + } +#endif + notify_remote_via_evtchn(dev->evtchn); + return 0; +} +int tpmfront_recv(struct tpmfront_dev* dev, uint8_t** msg, size_t *length) +{ + tpmif_tx_request_t* tx; + int i; + if(dev == NULL || dev->state != XenbusStateConnected) { + TPMFRONT_ERR("Tried to receive message from disconnected frontend\n"); + return -1; + } + /*Wait for the response */ + wait_event(dev->waitq, (!dev->waiting)); + + /* Initialize */ + *msg = NULL; + *length = 0; + + /* special case, just quit */ + tx = &dev->tx->ring[0].req; + if(tx->size == 0 ) { + goto quit; + } + /* Get the total size */ + tx = &dev->tx->ring[0].req; + for(i = 0; i < TPMIF_TX_RING_SIZE && tx->size > 0; ++i) { + tx = &dev->tx->ring[i].req; + *length += tx->size; + } + /* Alloc the buffer */ + if(dev->respbuf) { + free(dev->respbuf); + } + *msg = dev->respbuf = malloc(*length); + dev->resplen = *length; + /* Copy the bits */ + tx = &dev->tx->ring[0].req; + for(i = 0; i < TPMIF_TX_RING_SIZE && tx->size > 0; ++i) { + tx = &dev->tx->ring[i].req; + memcpy(&(*msg)[i * PAGE_SIZE], dev->pages[i], tx->size); + gnttab_end_access(tx->ref); + tx->ref = 0; + } +#ifdef TPMFRONT_PRINT_DEBUG + TPMFRONT_DEBUG("Received response from backend size=%u", (unsigned int) *length); + for(i = 0; i < *length; ++i) { + if(!(i % 30)) { + TPMFRONT_DEBUG_MORE("\n"); + } + TPMFRONT_DEBUG_MORE("%02X ", (*msg)[i]); + } + TPMFRONT_DEBUG_MORE("\n"); +#endif +#ifdef HAVE_LIBC + if(dev->fd >= 0) { + files[dev->fd].tpmfront.respgot = 1; + } +#endif +quit: + return 0; +} + +int tpmfront_cmd(struct tpmfront_dev* dev, uint8_t* req, size_t reqlen, uint8_t** resp, size_t* resplen) +{ + int rc; + if((rc = tpmfront_send(dev, req, reqlen))) { + return rc; + } + if((rc = tpmfront_recv(dev, resp, resplen))) { + return rc; + } + + return 0; +} + +#ifdef HAVE_LIBC +#include +int tpmfront_open(struct tpmfront_dev* dev) +{ + /* Silently prevent multiple opens */ + if(dev->fd != -1) { + return dev->fd; + } + + dev->fd = alloc_fd(FTYPE_TPMFRONT); + printk("tpmfront_open(%s) -> %d\n", dev->nodename, dev->fd); + files[dev->fd].tpmfront.dev = dev; + files[dev->fd].tpmfront.offset = 0; + files[dev->fd].tpmfront.respgot = 0; + return dev->fd; +} + +int tpmfront_posix_write(int fd, const uint8_t* buf, size_t count) +{ + int rc; + struct tpmfront_dev* dev; + dev = files[fd].tpmfront.dev; + + if(count == 0) { + return 0; + } + + /* Return an error if we are already processing a command */ + if(dev->waiting) { + errno = EINPROGRESS; + return -1; + } + /* Send the command now */ + if((rc = tpmfront_send(dev, buf, count)) != 0) { + errno = EIO; + return -1; + } + return count; +} + +int tpmfront_posix_read(int fd, uint8_t* buf, size_t count) +{ + int rc; + uint8_t* dummybuf; + size_t dummysz; + struct tpmfront_dev* dev; + + dev = files[fd].tpmfront.dev; + + if(count == 0) { + return 0; + } + + /* get the response if we haven't already */ + if(files[dev->fd].tpmfront.respgot == 0) { + if ((rc = tpmfront_recv(dev, &dummybuf, &dummysz)) != 0) { + errno = EIO; + return -1; + } + } + + /* handle EOF case */ + if(files[dev->fd].tpmfront.offset >= dev->resplen) { + return 0; + } + + /* Compute the number of bytes and do the copy operation */ + if((rc = min(count, dev->resplen - files[dev->fd].tpmfront.offset)) != 0) { + memcpy(buf, dev->respbuf + files[dev->fd].tpmfront.offset, rc); + files[dev->fd].tpmfront.offset += rc; + } + + return rc; +} + +int tpmfront_posix_fstat(int fd, struct stat* buf) +{ + uint8_t* dummybuf; + size_t dummysz; + int rc; + struct tpmfront_dev* dev = files[fd].tpmfront.dev; + + /* If we have a response waiting, then read it now from the backend + * so we can get its length*/ + if(dev->waiting || (files[dev->fd].read == 1 && !files[dev->fd].tpmfront.respgot)) { + if ((rc = tpmfront_recv(dev, &dummybuf, &dummysz)) != 0) { + errno = EIO; + return -1; + } + } + + buf->st_mode = O_RDWR; + buf->st_uid = 0; + buf->st_gid = 0; + buf->st_size = dev->resplen; + buf->st_atime = buf->st_mtime = buf->st_ctime = time(NULL); + + return 0; +} + + +#endif -- 1.7.4.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 14:59:05 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:59:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3vv-0000tv-TZ; Tue, 02 Oct 2012 14:58:51 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3vu-0000tZ-DD for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:58:51 +0000 Received: from [85.158.143.35:48062] by server-1.bemta-4.messagelabs.com id 4A/61-05684-9210B605; Tue, 02 Oct 2012 14:58:49 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-10.tower-21.messagelabs.com!1349189922!11328621!1 X-Originating-IP: [128.244.251.37] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21192 invoked from network); 2 Oct 2012 14:58:43 -0000 Received: from piper.jhuapl.edu (HELO jhuapl.edu) (128.244.251.37) by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 14:58:43 -0000 Received: from ([128.244.207.97]) by piper.jhuapl.edu with ESMTP with TLS id 5Y8HCH1.145948028; Tue, 02 Oct 2012 10:58:16 -0400 From: Matthew Fioravante To: xen-devel@lists.xen.org, samuel.thibault@ens-lyon.org, Ian.Campbell@citrix.com Date: Tue, 2 Oct 2012 10:58:23 -0400 Message-Id: <1349189903-17524-1-git-send-email-matthew.fioravante@jhuapl.edu> X-Mailer: git-send-email 1.7.4.4 Cc: Matthew Fioravante Subject: [Xen-devel] [PATCH 08/12] add tpmfront, tpm_tis, and tpmback drivers to mini-os X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch adds 3 new drivers to mini-os. tpmfront - paravirtualized tpm frontend driver tpmback - paravirtualized tpm backend driver tpm_tis - hardware tpm driver Unfortunately these drivers were derived from GPL licensed linux kernel drivers so they must carry the GPL license. However, since mini-os now supports conditional compilation, hopefully these drivers can be included into the xen tree and conditionally removed from non-gpl projects. By default they are disabled in the makefile. Signed-off-by: Matthew Fioravante --- Changes since last: * Fixed incorrect license text diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile index 2422db3..2302a23 100644 --- a/extras/mini-os/Makefile +++ b/extras/mini-os/Makefile @@ -22,6 +22,9 @@ CONFIG_QEMU_XS_ARGS ?= n CONFIG_TEST ?= n CONFIG_PCIFRONT ?= n CONFIG_BLKFRONT ?= y +CONFIG_TPMFRONT ?= n +CONFIG_TPM_TIS ?= n +CONFIG_TPMBACK ?= n CONFIG_NETFRONT ?= y CONFIG_FBFRONT ?= y CONFIG_KBDFRONT ?= y @@ -36,6 +39,9 @@ flags-$(CONFIG_SPARSE_BSS) += -DCONFIG_SPARSE_BSS flags-$(CONFIG_QEMU_XS_ARGS) += -DCONFIG_QEMU_XS_ARGS flags-$(CONFIG_PCIFRONT) += -DCONFIG_PCIFRONT flags-$(CONFIG_BLKFRONT) += -DCONFIG_BLKFRONT +flags-$(CONFIG_TPMFRONT) += -DCONFIG_TPMFRONT +flags-$(CONFIG_TPM_TIS) += -DCONFIG_TPM_TIS +flags-$(CONFIG_TPMBACK) += -DCONFIG_TPMBACK flags-$(CONFIG_NETFRONT) += -DCONFIG_NETFRONT flags-$(CONFIG_KBDFRONT) += -DCONFIG_KBDFRONT flags-$(CONFIG_FBFRONT) += -DCONFIG_FBFRONT @@ -67,6 +73,9 @@ TARGET := mini-os SUBDIRS := lib xenbus console src-$(CONFIG_BLKFRONT) += blkfront.c +src-$(CONFIG_TPMFRONT) += tpmfront.c +src-$(CONFIG_TPM_TIS) += tpm_tis.c +src-$(CONFIG_TPMBACK) += tpmback.c src-y += daytime.c src-y += events.c src-$(CONFIG_FBFRONT) += fbfront.c diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h index d4641b6..935bede 100644 --- a/extras/mini-os/include/lib.h +++ b/extras/mini-os/include/lib.h @@ -142,6 +142,8 @@ enum fd_type { FTYPE_FB, FTYPE_MEM, FTYPE_SAVEFILE, + FTYPE_TPMFRONT, + FTYPE_TPM_TIS, }; LIST_HEAD(evtchn_port_list, evtchn_port_info); @@ -185,6 +187,20 @@ extern struct file { struct { struct consfront_dev *dev; } cons; +#ifdef CONFIG_TPMFRONT + struct { + struct tpmfront_dev *dev; + int respgot; + off_t offset; + } tpmfront; +#endif +#ifdef CONFIG_TPM_TIS + struct { + struct tpm_chip *dev; + int respgot; + off_t offset; + } tpm_tis; +#endif #ifdef CONFIG_XENBUS struct { /* To each xenbus FD is associated a queue of watch events for this diff --git a/extras/mini-os/include/tpm_tis.h b/extras/mini-os/include/tpm_tis.h new file mode 100644 index 0000000..a076a70 --- /dev/null +++ b/extras/mini-os/include/tpm_tis.h @@ -0,0 +1,64 @@ +/* + * Copyright (c) 2010-2012 United States Government, as represented by + * the Secretary of Defense. All rights reserved. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version 2 + * of the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + * + * Based upon the files: + * drivers/char/tpm/tpm_tis.c + * drivers/char/tpm/tpm.c + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation + */ +#ifndef TPM_TIS_H +#define TPM_TIS_H + +#include +#include + +#define TPM_TIS_EN_LOCL0 1 +#define TPM_TIS_EN_LOCL1 (1 << 1) +#define TPM_TIS_EN_LOCL2 (1 << 2) +#define TPM_TIS_EN_LOCL3 (1 << 3) +#define TPM_TIS_EN_LOCL4 (1 << 4) +#define TPM_TIS_EN_LOCLALL (TPM_TIS_EN_LOCL0 | TPM_TIS_EN_LOCL1 | TPM_TIS_EN_LOCL2 | TPM_TIS_EN_LOCL3 | TPM_TIS_EN_LOCL4) +#define TPM_TIS_LOCL_INT_TO_FLAG(x) (1 << x) +#define TPM_BASEADDR 0xFED40000 +#define TPM_PROBE_IRQ 0xFFFF + +struct tpm_chip; + +struct tpm_chip* init_tpm_tis(unsigned long baseaddr, int localities, unsigned int irq); +void shutdown_tpm_tis(struct tpm_chip* tpm); + +int tpm_tis_request_locality(struct tpm_chip* tpm, int locality); +int tpm_tis_cmd(struct tpm_chip* tpm, uint8_t* req, size_t reqlen, uint8_t** resp, size_t* resplen); + +#ifdef HAVE_LIBC +#include +#include +/* POSIX IO functions: + * use tpm_tis_open() to get a file descriptor to the tpm device + * use write() on the fd to send a command to the backend. You must + * include the entire command in a single call to write(). + * use read() on the fd to read the response. You can use + * fstat() to get the size of the response and lseek() to seek on it. + */ +int tpm_tis_open(struct tpm_chip* tpm); +int tpm_tis_posix_read(int fd, uint8_t* buf, size_t count); +int tpm_tis_posix_write(int fd, const uint8_t* buf, size_t count); +int tpm_tis_posix_fstat(int fd, struct stat* buf); +#endif + +#endif diff --git a/extras/mini-os/include/tpmback.h b/extras/mini-os/include/tpmback.h new file mode 100644 index 0000000..4315e55 --- /dev/null +++ b/extras/mini-os/include/tpmback.h @@ -0,0 +1,96 @@ +/* + * Copyright (c) 2010-2012 United States Government, as represented by + * the Secretary of Defense. All rights reserved. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version 2 + * of the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + * + * Based upon the files: + * drivers/xen/tpmbk.c + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation + */ +#include +#include +#include +#include +#ifndef TPMBACK_H +#define TPMBACK_H + +struct tpmcmd { + domid_t domid; /* Domid of the frontend */ + unsigned int handle; /* Handle of the frontend */ + char* uuid; /* uuid of the tpm interface - allocated internally, dont free it */ + + unsigned int req_len; /* Size of the command in buf - set by tpmback driver */ + uint8_t* req; /* tpm command bits, allocated by driver, DON'T FREE IT */ + unsigned int resp_len; /* Size of the outgoing command, + you set this before passing the cmd object to tpmback_resp */ + uint8_t* resp; /* Buffer for response - YOU MUST ALLOCATE IT, YOU MUST ALSO FREE IT */ +}; +typedef struct tpmcmd tpmcmd_t; + +/* Initialize the tpm backend driver + * @exclusive_domname - This is NULL terminated list of vtpm uuid strings. If this list + * is non-empty, then only frontend domains with vtpm uuid's matching + * entries in this list will be allowed to connect. + * Other connections will be immediatly closed. + * Set this argument to NULL to allow any vtpm to connect. + */ +void init_tpmback(char** exclusive_uuids); +/* Shutdown tpm backend driver */ +void shutdown_tpmback(void); + +/* Blocks until a tpm command is sent from any front end. + * Returns a pointer to the tpm command to handle. + * Do not try to free this pointer or the req buffer + * This function will return NULL if the tpm backend driver + * is shutdown or any other error occurs */ +tpmcmd_t* tpmback_req_any(void); + +/* Blocks until a tpm command from the frontend at domid/handle + * is sent. + * Returns NULL if domid/handle is not connected, tpmback is + * shutdown or shutting down, or if there is an error + */ +tpmcmd_t* tpmback_req(domid_t domid, unsigned int handle); + +/* Send the response to the tpm command back to the frontend + * This function will free the tpmcmd object, but you must free the resp + * buffer yourself */ +void tpmback_resp(tpmcmd_t* tpmcmd); + +/* Waits for the first frontend to connect and then sets domid and handle appropriately. + * If one or more frontends are already connected, this will set domid and handle to one + * of them arbitrarily. The main use for this function is to wait until a single + * frontend connection has occured. + * returns 0 on success, non-zero on failure */ +int tpmback_wait_for_frontend_connect(domid_t *domid, unsigned int *handle); + +/* returns the number of frontends connected */ +int tpmback_num_frontends(void); + +/* Returns the uuid of the specified frontend, NULL on error */ +char* tpmback_get_uuid(domid_t domid, unsigned int handle); + +/* Specify a function to call when a new tpm device connects */ +void tpmback_set_open_callback(void (*cb)(domid_t, unsigned int)); + +/* Specify a function to call when a tpm device disconnects */ +void tpmback_set_close_callback(void (*cb)(domid_t, unsigned int)); + +//Not Implemented +void tpmback_set_suspend_callback(void (*cb)(domid_t, unsigned int)); +void tpmback_set_resume_callback(void (*cb)(domid_t, unsigned int)); + +#endif diff --git a/extras/mini-os/include/tpmfront.h b/extras/mini-os/include/tpmfront.h new file mode 100644 index 0000000..7e3d357 --- /dev/null +++ b/extras/mini-os/include/tpmfront.h @@ -0,0 +1,97 @@ +/* + * Copyright (c) 2010-2012 United States Government, as represented by + * the Secretary of Defense. All rights reserved. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version 2 + * of the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + * + + * + * Based upon the files: + * drivers/char/tpm/tpm_vtpm.c + * drivers/char/tpm/tpm_xen.c + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation + */ +#ifndef TPMFRONT_H +#define TPMFRONT_H + +#include +#include +#include +#include +#include +#include +#include + +struct tpmfront_dev { + grant_ref_t ring_ref; + evtchn_port_t evtchn; + + tpmif_tx_interface_t* tx; + + void** pages; + + domid_t bedomid; + char* nodename; + char* bepath; + + XenbusState state; + + uint8_t waiting; + struct wait_queue_head waitq; + + uint8_t* respbuf; + size_t resplen; + +#ifdef HAVE_LIBC + int fd; +#endif + +}; + + +/*Initialize frontend */ +struct tpmfront_dev* init_tpmfront(const char* nodename); +/*Shutdown frontend */ +void shutdown_tpmfront(struct tpmfront_dev* dev); + +/* Send a tpm command to the backend and wait for the response + * + * @dev - frontend device + * @req - request buffer + * @reqlen - length of request buffer + * @resp - *resp will be set to internal response buffer, don't free it! Value is undefined on error + * @resplen - *resplen will be set to the length of the response. Value is undefined on error + * + * returns 0 on success, non zero on failure. + * */ +int tpmfront_cmd(struct tpmfront_dev* dev, uint8_t* req, size_t reqlen, uint8_t** resp, size_t* resplen); + +#ifdef HAVE_LIBC +#include +/* POSIX IO functions: + * use tpmfront_open() to get a file descriptor to the tpm device + * use write() on the fd to send a command to the backend. You must + * include the entire command in a single call to write(). + * use read() on the fd to read the response. You can use + * fstat() to get the size of the response and lseek() to seek on it. + */ +int tpmfront_open(struct tpmfront_dev* dev); +int tpmfront_posix_read(int fd, uint8_t* buf, size_t count); +int tpmfront_posix_write(int fd, const uint8_t* buf, size_t count); +int tpmfront_posix_fstat(int fd, struct stat* buf); +#endif + + +#endif diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c index 6cb97b1..d212969 100644 --- a/extras/mini-os/lib/sys.c +++ b/extras/mini-os/lib/sys.c @@ -27,6 +27,8 @@ #include #include #include +#include +#include #include #include @@ -294,6 +296,16 @@ int read(int fd, void *buf, size_t nbytes) return blkfront_posix_read(fd, buf, nbytes); } #endif +#ifdef CONFIG_TPMFRONT + case FTYPE_TPMFRONT: { + return tpmfront_posix_read(fd, buf, nbytes); + } +#endif +#ifdef CONFIG_TPM_TIS + case FTYPE_TPM_TIS: { + return tpm_tis_posix_read(fd, buf, nbytes); + } +#endif default: break; } @@ -330,6 +342,14 @@ int write(int fd, const void *buf, size_t nbytes) case FTYPE_BLK: return blkfront_posix_write(fd, buf, nbytes); #endif +#ifdef CONFIG_TPMFRONT + case FTYPE_TPMFRONT: + return tpmfront_posix_write(fd, buf, nbytes); +#endif +#ifdef CONFIG_TPM_TIS + case FTYPE_TPM_TIS: + return tpm_tis_posix_write(fd, buf, nbytes); +#endif default: break; } @@ -341,8 +361,16 @@ int write(int fd, const void *buf, size_t nbytes) off_t lseek(int fd, off_t offset, int whence) { switch(files[fd].type) { +#if defined(CONFIG_BLKFRONT) || defined(CONFIG_TPMFRONT) || defined(CONFIG_TPM_TIS) #ifdef CONFIG_BLKFRONT case FTYPE_BLK: +#endif +#ifdef CONFIG_TPMFRNT + case FTYPE_TPMFRONT: +#endif +#ifdef CONFIG_TPM_TIS + case FTYPE_TPM_TIS: +#endif switch (whence) { case SEEK_SET: files[fd].file.offset = offset; @@ -420,6 +448,18 @@ int close(int fd) files[fd].type = FTYPE_NONE; return 0; #endif +#ifdef CONFIG_TPMFRONT + case FTYPE_TPMFRONT: + shutdown_tpmfront(files[fd].tpmfront.dev); + files[fd].type = FTYPE_NONE; + return 0; +#endif +#ifdef CONFIG_TPM_TIS + case FTYPE_TPM_TIS: + shutdown_tpm_tis(files[fd].tpm_tis.dev); + files[fd].type = FTYPE_NONE; + return 0; +#endif #ifdef CONFIG_KBDFRONT case FTYPE_KBD: shutdown_kbdfront(files[fd].kbd.dev); @@ -489,6 +529,14 @@ int fstat(int fd, struct stat *buf) case FTYPE_BLK: return blkfront_posix_fstat(fd, buf); #endif +#ifdef CONFIG_TPMFRONT + case FTYPE_TPMFRONT: + return tpmfront_posix_fstat(fd, buf); +#endif +#ifdef CONFIG_TPM_TIS + case FTYPE_TPM_TIS: + return tpm_tis_posix_fstat(fd, buf); +#endif default: break; } diff --git a/extras/mini-os/tpm_tis.c b/extras/mini-os/tpm_tis.c new file mode 100644 index 0000000..d94f798 --- /dev/null +++ b/extras/mini-os/tpm_tis.c @@ -0,0 +1,1345 @@ +/* + * Copyright (c) 2010-2012 United States Government, as represented by + * the Secretary of Defense. All rights reserved. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version 2 + * of the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + * + * Based upon the files: + * drivers/char/tpm/tpm_tis.c + * drivers/char/tpm/tpm.c + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#ifndef min + #define min( a, b ) ( ((a) < (b)) ? (a) : (b) ) +#endif + +#define TPM_HEADER_SIZE 10 + +#define TPM_BUFSIZE 2048 + +struct tpm_input_header { + uint16_t tag; + uint32_t length; + uint32_t ordinal; +}__attribute__((packed)); + +struct tpm_output_header { + uint16_t tag; + uint32_t length; + uint32_t return_code; +}__attribute__((packed)); + +struct stclear_flags_t { + uint16_t tag; + uint8_t deactivated; + uint8_t disableForceClear; + uint8_t physicalPresence; + uint8_t physicalPresenceLock; + uint8_t bGlobalLock; +}__attribute__((packed)); + +struct tpm_version_t { + uint8_t Major; + uint8_t Minor; + uint8_t revMajor; + uint8_t revMinor; +}__attribute__((packed)); + +struct tpm_version_1_2_t { + uint16_t tag; + uint8_t Major; + uint8_t Minor; + uint8_t revMajor; + uint8_t revMinor; +}__attribute__((packed)); + +struct timeout_t { + uint32_t a; + uint32_t b; + uint32_t c; + uint32_t d; +}__attribute__((packed)); + +struct duration_t { + uint32_t tpm_short; + uint32_t tpm_medium; + uint32_t tpm_long; +}__attribute__((packed)); + +struct permanent_flags_t { + uint16_t tag; + uint8_t disable; + uint8_t ownership; + uint8_t deactivated; + uint8_t readPubek; + uint8_t disableOwnerClear; + uint8_t allowMaintenance; + uint8_t physicalPresenceLifetimeLock; + uint8_t physicalPresenceHWEnable; + uint8_t physicalPresenceCMDEnable; + uint8_t CEKPUsed; + uint8_t TPMpost; + uint8_t TPMpostLock; + uint8_t FIPS; + uint8_t operator; + uint8_t enableRevokeEK; + uint8_t nvLocked; + uint8_t readSRKPub; + uint8_t tpmEstablished; + uint8_t maintenanceDone; + uint8_t disableFullDALogicInfo; +}__attribute__((packed)); + +typedef union { + struct permanent_flags_t perm_flags; + struct stclear_flags_t stclear_flags; + bool owned; + uint32_t num_pcrs; + struct tpm_version_t tpm_version; + struct tpm_version_1_2_t tpm_version_1_2; + uint32_t manufacturer_id; + struct timeout_t timeout; + struct duration_t duration; +} cap_t; + +struct tpm_getcap_params_in { + uint32_t cap; + uint32_t subcap_size; + uint32_t subcap; +}__attribute__((packed)); + +struct tpm_getcap_params_out { + uint32_t cap_size; + cap_t cap; +}__attribute__((packed)); + +struct tpm_readpubek_params_out { + uint8_t algorithm[4]; + uint8_t encscheme[2]; + uint8_t sigscheme[2]; + uint32_t paramsize; + uint8_t parameters[12]; /*assuming RSA*/ + uint32_t keysize; + uint8_t modulus[256]; + uint8_t checksum[20]; +}__attribute__((packed)); + +typedef union { + struct tpm_input_header in; + struct tpm_output_header out; +} tpm_cmd_header; + +#define TPM_DIGEST_SIZE 20 +struct tpm_pcrread_out { + uint8_t pcr_result[TPM_DIGEST_SIZE]; +}__attribute__((packed)); + +struct tpm_pcrread_in { + uint32_t pcr_idx; +}__attribute__((packed)); + +struct tpm_pcrextend_in { + uint32_t pcr_idx; + uint8_t hash[TPM_DIGEST_SIZE]; +}__attribute__((packed)); + +typedef union { + struct tpm_getcap_params_out getcap_out; + struct tpm_readpubek_params_out readpubek_out; + uint8_t readpubek_out_buffer[sizeof(struct tpm_readpubek_params_out)]; + struct tpm_getcap_params_in getcap_in; + struct tpm_pcrread_in pcrread_in; + struct tpm_pcrread_out pcrread_out; + struct tpm_pcrextend_in pcrextend_in; +} tpm_cmd_params; + +struct tpm_cmd_t { + tpm_cmd_header header; + tpm_cmd_params params; +}__attribute__((packed)); + + +enum tpm_duration { + TPM_SHORT = 0, + TPM_MEDIUM = 1, + TPM_LONG = 2, + TPM_UNDEFINED, +}; + +#define TPM_MAX_ORDINAL 243 +#define TPM_MAX_PROTECTED_ORDINAL 12 +#define TPM_PROTECTED_ORDINAL_MASK 0xFF + +extern const uint8_t tpm_protected_ordinal_duration[TPM_MAX_PROTECTED_ORDINAL]; +extern const uint8_t tpm_ordinal_duration[TPM_MAX_ORDINAL]; + +#define TPM_DIGEST_SIZE 20 +#define TPM_ERROR_SIZE 10 +#define TPM_RET_CODE_IDX 6 + +/* tpm_capabilities */ +#define TPM_CAP_FLAG cpu_to_be32(4) +#define TPM_CAP_PROP cpu_to_be32(5) +#define CAP_VERSION_1_1 cpu_to_be32(0x06) +#define CAP_VERSION_1_2 cpu_to_be32(0x1A) + +/* tpm_sub_capabilities */ +#define TPM_CAP_PROP_PCR cpu_to_be32(0x101) +#define TPM_CAP_PROP_MANUFACTURER cpu_to_be32(0x103) +#define TPM_CAP_FLAG_PERM cpu_to_be32(0x108) +#define TPM_CAP_FLAG_VOL cpu_to_be32(0x109) +#define TPM_CAP_PROP_OWNER cpu_to_be32(0x111) +#define TPM_CAP_PROP_TIS_TIMEOUT cpu_to_be32(0x115) +#define TPM_CAP_PROP_TIS_DURATION cpu_to_be32(0x120) + + +#define TPM_INTERNAL_RESULT_SIZE 200 +#define TPM_TAG_RQU_COMMAND cpu_to_be16(193) +#define TPM_ORD_GET_CAP cpu_to_be32(101) + +extern const struct tpm_input_header tpm_getcap_header; + + + +const uint8_t tpm_protected_ordinal_duration[TPM_MAX_PROTECTED_ORDINAL] = { + TPM_UNDEFINED, /* 0 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 5 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 10 */ + TPM_SHORT, +}; + +const uint8_t tpm_ordinal_duration[TPM_MAX_ORDINAL] = { + TPM_UNDEFINED, /* 0 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 5 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 10 */ + TPM_SHORT, + TPM_MEDIUM, + TPM_LONG, + TPM_LONG, + TPM_MEDIUM, /* 15 */ + TPM_SHORT, + TPM_SHORT, + TPM_MEDIUM, + TPM_LONG, + TPM_SHORT, /* 20 */ + TPM_SHORT, + TPM_MEDIUM, + TPM_MEDIUM, + TPM_MEDIUM, + TPM_SHORT, /* 25 */ + TPM_SHORT, + TPM_MEDIUM, + TPM_SHORT, + TPM_SHORT, + TPM_MEDIUM, /* 30 */ + TPM_LONG, + TPM_MEDIUM, + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, /* 35 */ + TPM_MEDIUM, + TPM_MEDIUM, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_MEDIUM, /* 40 */ + TPM_LONG, + TPM_MEDIUM, + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, /* 45 */ + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_LONG, + TPM_MEDIUM, /* 50 */ + TPM_MEDIUM, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 55 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_MEDIUM, /* 60 */ + TPM_MEDIUM, + TPM_MEDIUM, + TPM_SHORT, + TPM_SHORT, + TPM_MEDIUM, /* 65 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 70 */ + TPM_SHORT, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 75 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_LONG, /* 80 */ + TPM_UNDEFINED, + TPM_MEDIUM, + TPM_LONG, + TPM_SHORT, + TPM_UNDEFINED, /* 85 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 90 */ + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_UNDEFINED, /* 95 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_MEDIUM, /* 100 */ + TPM_SHORT, + TPM_SHORT, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 105 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 110 */ + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, /* 115 */ + TPM_SHORT, + TPM_SHORT, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_LONG, /* 120 */ + TPM_LONG, + TPM_MEDIUM, + TPM_UNDEFINED, + TPM_SHORT, + TPM_SHORT, /* 125 */ + TPM_SHORT, + TPM_LONG, + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, /* 130 */ + TPM_MEDIUM, + TPM_UNDEFINED, + TPM_SHORT, + TPM_MEDIUM, + TPM_UNDEFINED, /* 135 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 140 */ + TPM_SHORT, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 145 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 150 */ + TPM_MEDIUM, + TPM_MEDIUM, + TPM_SHORT, + TPM_SHORT, + TPM_UNDEFINED, /* 155 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 160 */ + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 165 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_LONG, /* 170 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 175 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_MEDIUM, /* 180 */ + TPM_SHORT, + TPM_MEDIUM, + TPM_MEDIUM, + TPM_MEDIUM, + TPM_MEDIUM, /* 185 */ + TPM_SHORT, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 190 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 195 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 200 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, + TPM_SHORT, /* 205 */ + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_MEDIUM, /* 210 */ + TPM_UNDEFINED, + TPM_MEDIUM, + TPM_MEDIUM, + TPM_MEDIUM, + TPM_UNDEFINED, /* 215 */ + TPM_MEDIUM, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, + TPM_SHORT, /* 220 */ + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_UNDEFINED, /* 225 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 230 */ + TPM_LONG, + TPM_MEDIUM, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 235 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 240 */ + TPM_UNDEFINED, + TPM_MEDIUM, +}; + +const struct tpm_input_header tpm_getcap_header = { + .tag = TPM_TAG_RQU_COMMAND, + .length = cpu_to_be32(22), + .ordinal = TPM_ORD_GET_CAP +}; + + +enum tis_access { + TPM_ACCESS_VALID = 0x80, + TPM_ACCESS_ACTIVE_LOCALITY = 0x20, /* (R) */ + TPM_ACCESS_RELINQUISH_LOCALITY = 0x20,/* (W) */ + TPM_ACCESS_REQUEST_PENDING = 0x04, /* (W) */ + TPM_ACCESS_REQUEST_USE = 0x02, /* (W) */ +}; + +enum tis_status { + TPM_STS_VALID = 0x80, /* (R) */ + TPM_STS_COMMAND_READY = 0x40, /* (R) */ + TPM_STS_DATA_AVAIL = 0x10, /* (R) */ + TPM_STS_DATA_EXPECT = 0x08, /* (R) */ + TPM_STS_GO = 0x20, /* (W) */ +}; + +enum tis_int_flags { + TPM_GLOBAL_INT_ENABLE = 0x80000000, + TPM_INTF_BURST_COUNT_STATIC = 0x100, + TPM_INTF_CMD_READY_INT = 0x080, + TPM_INTF_INT_EDGE_FALLING = 0x040, + TPM_INTF_INT_EDGE_RISING = 0x020, + TPM_INTF_INT_LEVEL_LOW = 0x010, + TPM_INTF_INT_LEVEL_HIGH = 0x008, + TPM_INTF_LOCALITY_CHANGE_INT = 0x004, + TPM_INTF_STS_VALID_INT = 0x002, + TPM_INTF_DATA_AVAIL_INT = 0x001, +}; + +enum tis_defaults { + TIS_MEM_BASE = 0xFED40000, + TIS_MEM_LEN = 0x5000, + TIS_SHORT_TIMEOUT = 750, /*ms*/ + TIS_LONG_TIMEOUT = 2000, /*2 sec */ +}; + +#define TPM_TIMEOUT 5 + +#define TPM_ACCESS(t, l) (((uint8_t*)t->pages[l]) + 0x0000) +#define TPM_INT_ENABLE(t, l) ((uint32_t*)(((uint8_t*)t->pages[l]) + 0x0008)) +#define TPM_INT_VECTOR(t, l) (((uint8_t*)t->pages[l]) + 0x000C) +#define TPM_INT_STATUS(t, l) (((uint8_t*)t->pages[l]) + 0x0010) +#define TPM_INTF_CAPS(t, l) ((uint32_t*)(((uint8_t*)t->pages[l]) + 0x0014)) +#define TPM_STS(t, l) ((uint8_t*)(((uint8_t*)t->pages[l]) + 0x0018)) +#define TPM_DATA_FIFO(t, l) (((uint8_t*)t->pages[l]) + 0x0024) + +#define TPM_DID_VID(t, l) ((uint32_t*)(((uint8_t*)t->pages[l]) + 0x0F00)) +#define TPM_RID(t, l) (((uint8_t*)t->pages[l]) + 0x0F04) + +struct tpm_chip { + int enabled_localities; + int locality; + unsigned long baseaddr; + uint8_t* pages[5]; + int did, vid, rid; + + uint8_t data_buffer[TPM_BUFSIZE]; + int data_len; + + s_time_t timeout_a, timeout_b, timeout_c, timeout_d; + s_time_t duration[3]; + +#ifdef HAVE_LIBC + int fd; +#endif + + unsigned int irq; + struct wait_queue_head read_queue; + struct wait_queue_head int_queue; +}; + + +static void __init_tpm_chip(struct tpm_chip* tpm) { + tpm->enabled_localities = TPM_TIS_EN_LOCLALL; + tpm->locality = -1; + tpm->baseaddr = 0; + tpm->pages[0] = tpm->pages[1] = tpm->pages[2] = tpm->pages[3] = tpm->pages[4] = NULL; + tpm->vid = 0; + tpm->did = 0; + tpm->irq = 0; + init_waitqueue_head(&tpm->read_queue); + init_waitqueue_head(&tpm->int_queue); + + tpm->data_len = -1; + +#ifdef HAVE_LIBC + tpm->fd = -1; +#endif +} + +/* + * Returns max number of nsecs to wait + */ +s_time_t tpm_calc_ordinal_duration(struct tpm_chip *chip, + uint32_t ordinal) +{ + int duration_idx = TPM_UNDEFINED; + s_time_t duration = 0; + + if (ordinal < TPM_MAX_ORDINAL) + duration_idx = tpm_ordinal_duration[ordinal]; + else if ((ordinal & TPM_PROTECTED_ORDINAL_MASK) < + TPM_MAX_PROTECTED_ORDINAL) + duration_idx = + tpm_protected_ordinal_duration[ordinal & + TPM_PROTECTED_ORDINAL_MASK]; + + if (duration_idx != TPM_UNDEFINED) { + duration = chip->duration[duration_idx]; + } + + if (duration <= 0) { + return SECONDS(120); + } + else + { + return duration; + } +} + + +static int locality_enabled(struct tpm_chip* tpm, int l) { + return tpm->enabled_localities & (1 << l); +} + +static int check_locality(struct tpm_chip* tpm, int l) { + if(locality_enabled(tpm, l) && (ioread8(TPM_ACCESS(tpm, l)) & + (TPM_ACCESS_ACTIVE_LOCALITY | TPM_ACCESS_VALID)) == + (TPM_ACCESS_ACTIVE_LOCALITY | TPM_ACCESS_VALID)) { + return l; + } + return -1; +} + +void release_locality(struct tpm_chip* tpm, int l, int force) +{ + if (locality_enabled(tpm, l) && (force || (ioread8(TPM_ACCESS(tpm, l)) & + (TPM_ACCESS_REQUEST_PENDING | TPM_ACCESS_VALID)) == + (TPM_ACCESS_REQUEST_PENDING | TPM_ACCESS_VALID))) { + iowrite8(TPM_ACCESS(tpm, l), TPM_ACCESS_RELINQUISH_LOCALITY); + } +} + +int tpm_tis_request_locality(struct tpm_chip* tpm, int l) { + + s_time_t stop; + /*Make sure locality is valid */ + if(!locality_enabled(tpm, l)) { + printk("tpm_tis_change_locality() Tried to change to locality %d, but it is disabled or invalid!\n", l); + return -1; + } + /* Check if we already have the current locality */ + if(check_locality(tpm, l) >= 0) { + return tpm->locality = l; + } + /* Set the new locality*/ + iowrite8(TPM_ACCESS(tpm, l), TPM_ACCESS_REQUEST_USE); + + if(tpm->irq) { + /* Wait for interrupt */ + wait_event_deadline(tpm->int_queue, (check_locality(tpm, l) >= 0), NOW() + tpm->timeout_a); + + /* FIXME: Handle timeout event, should return error in that case */ + return l; + } else { + /* Wait for burstcount */ + stop = NOW() + tpm->timeout_a; + do { + if(check_locality(tpm, l) >= 0) { + return tpm->locality = l; + } + msleep(TPM_TIMEOUT); + } while(NOW() < stop); + } + + printk("REQ LOCALITY FAILURE\n"); + return -1; +} + +static uint8_t tpm_tis_status(struct tpm_chip* tpm) { + return ioread8(TPM_STS(tpm, tpm->locality)); +} + +/* This causes the current command to be aborted */ +static void tpm_tis_ready(struct tpm_chip* tpm) { + iowrite8(TPM_STS(tpm, tpm->locality), TPM_STS_COMMAND_READY); +} +#define tpm_tis_cancel_cmd(v) tpm_tis_ready(v) + +static int get_burstcount(struct tpm_chip* tpm) { + s_time_t stop; + int burstcnt; + + stop = NOW() + tpm->timeout_d; + do { + burstcnt = ioread8((TPM_STS(tpm, tpm->locality) + 1)); + burstcnt += ioread8(TPM_STS(tpm, tpm->locality) + 2) << 8; + + if (burstcnt) { + return burstcnt; + } + msleep(TPM_TIMEOUT); + } while(NOW() < stop); + return -EBUSY; +} + +static int wait_for_stat(struct tpm_chip* tpm, uint8_t mask, + unsigned long timeout, struct wait_queue_head* queue) { + s_time_t stop; + uint8_t status; + + status = tpm_tis_status(tpm); + if((status & mask) == mask) { + return 0; + } + + if(tpm->irq) { + wait_event_deadline(*queue, ((tpm_tis_status(tpm) & mask) == mask), timeout); + /* FIXME: Check for timeout and return -ETIME */ + return 0; + } else { + stop = NOW() + timeout; + do { + msleep(TPM_TIMEOUT); + status = tpm_tis_status(tpm); + if((status & mask) == mask) + return 0; + } while( NOW() < stop); + } + return -ETIME; +} + +static int recv_data(struct tpm_chip* tpm, uint8_t* buf, size_t count) { + int size = 0; + int burstcnt; + while( size < count && + wait_for_stat(tpm, + TPM_STS_DATA_AVAIL | TPM_STS_VALID, + tpm->timeout_c, + &tpm->read_queue) + == 0) { + burstcnt = get_burstcount(tpm); + for(; burstcnt > 0 && size < count; --burstcnt) + { + buf[size++] = ioread8(TPM_DATA_FIFO(tpm, tpm->locality)); + } + } + return size; +} + +int tpm_tis_recv(struct tpm_chip* tpm, uint8_t* buf, size_t count) { + int size = 0; + int expected, status; + + if (count < TPM_HEADER_SIZE) { + size = -EIO; + goto out; + } + + /* read first 10 bytes, including tag, paramsize, and result */ + if((size = + recv_data(tpm, buf, TPM_HEADER_SIZE)) < TPM_HEADER_SIZE) { + printk("Error reading tpm cmd header\n"); + goto out; + } + + expected = be32_to_cpu(*((uint32_t*)(buf + 2))); + if(expected > count) { + size = -EIO; + goto out; + } + + if((size += recv_data(tpm, & buf[TPM_HEADER_SIZE], + expected - TPM_HEADER_SIZE)) < expected) { + printk("Unable to read rest of tpm command size=%d expected=%d\n", size, expected); + size = -ETIME; + goto out; + } + + wait_for_stat(tpm, TPM_STS_VALID, tpm->timeout_c, &tpm->int_queue); + status = tpm_tis_status(tpm); + if(status & TPM_STS_DATA_AVAIL) { + printk("Error: left over data\n"); + size = -EIO; + goto out; + } + +out: + tpm_tis_ready(tpm); + release_locality(tpm, tpm->locality, 0); + return size; +} +int tpm_tis_send(struct tpm_chip* tpm, uint8_t* buf, size_t len) { + int rc; + int status, burstcnt = 0; + int count = 0; + uint32_t ordinal; + + if(tpm_tis_request_locality(tpm, tpm->locality) < 0) { + return -EBUSY; + } + + status = tpm_tis_status(tpm); + if((status & TPM_STS_COMMAND_READY) == 0) { + tpm_tis_ready(tpm); + if(wait_for_stat(tpm, TPM_STS_COMMAND_READY, tpm->timeout_b, &tpm->int_queue) < 0) { + rc = -ETIME; + goto out_err; + } + } + + while(count < len - 1) { + burstcnt = get_burstcount(tpm); + for(;burstcnt > 0 && count < len -1; --burstcnt) { + iowrite8(TPM_DATA_FIFO(tpm, tpm->locality), buf[count++]); + } + + wait_for_stat(tpm, TPM_STS_VALID, tpm->timeout_c, &tpm->int_queue); + status = tpm_tis_status(tpm); + if((status & TPM_STS_DATA_EXPECT) == 0) { + rc = -EIO; + goto out_err; + } + } + + /*Write last byte*/ + iowrite8(TPM_DATA_FIFO(tpm, tpm->locality), buf[count]); + wait_for_stat(tpm, TPM_STS_VALID, tpm->timeout_c, &tpm->read_queue); + status = tpm_tis_status(tpm); + if((status & TPM_STS_DATA_EXPECT) != 0) { + rc = -EIO; + goto out_err; + } + + /*go and do it*/ + iowrite8(TPM_STS(tpm, tpm->locality), TPM_STS_GO); + + if(tpm->irq) { + /*Wait for interrupt */ + ordinal = be32_to_cpu(*(buf + 6)); + if(wait_for_stat(tpm, + TPM_STS_DATA_AVAIL | TPM_STS_VALID, + tpm_calc_ordinal_duration(tpm, ordinal), + &tpm->read_queue) < 0) { + rc = -ETIME; + goto out_err; + } + } +#ifdef HAVE_LIBC + if(tpm->fd >= 0) { + files[tpm->fd].read = 0; + files[tpm->fd].tpm_tis.respgot = 0; + files[tpm->fd].tpm_tis.offset = 0; + } +#endif + return len; + +out_err: + tpm_tis_ready(tpm); + release_locality(tpm, tpm->locality, 0); + return rc; +} + +static void tpm_tis_irq_handler(evtchn_port_t port, struct pt_regs *regs, void* data) +{ + struct tpm_chip* tpm = data; + uint32_t interrupt; + int i; + + interrupt = ioread32(TPM_INT_STATUS(tpm, tpm->locality)); + if(interrupt == 0) { + return; + } + + if(interrupt & TPM_INTF_DATA_AVAIL_INT) { + wake_up(&tpm->read_queue); + } + if(interrupt & TPM_INTF_LOCALITY_CHANGE_INT) { + for(i = 0; i < 5; ++i) { + if(check_locality(tpm, i) >= 0) { + break; + } + } + } + if(interrupt & (TPM_INTF_LOCALITY_CHANGE_INT | TPM_INTF_STS_VALID_INT | + TPM_INTF_CMD_READY_INT)) { + wake_up(&tpm->int_queue); + } + + /* Clear interrupts handled with TPM_EOI */ + iowrite32(TPM_INT_STATUS(tpm, tpm->locality), interrupt); + ioread32(TPM_INT_STATUS(tpm, tpm->locality)); + return; +} + +/* + * Internal kernel interface to transmit TPM commands + */ +static ssize_t tpm_transmit(struct tpm_chip *chip, const uint8_t *buf, + size_t bufsiz) +{ + ssize_t rc; + uint32_t count, ordinal; + s_time_t stop; + + count = be32_to_cpu(*((uint32_t *) (buf + 2))); + ordinal = be32_to_cpu(*((uint32_t *) (buf + 6))); + if (count == 0) + return -ENODATA; + if (count > bufsiz) { + printk("Error: invalid count value %x %zx \n", count, bufsiz); + return -E2BIG; + } + + //down(&chip->tpm_mutex); + + if ((rc = tpm_tis_send(chip, (uint8_t *) buf, count)) < 0) { + printk("tpm_transmit: tpm_send: error %zd\n", rc); + goto out; + } + + if (chip->irq) + goto out_recv; + + stop = NOW() + tpm_calc_ordinal_duration(chip, ordinal); + do { + uint8_t status = tpm_tis_status(chip); + if ((status & (TPM_STS_DATA_AVAIL | TPM_STS_VALID)) == + (TPM_STS_DATA_AVAIL | TPM_STS_VALID)) + goto out_recv; + + if ((status == TPM_STS_COMMAND_READY)) { + printk("TPM Error: Operation Canceled\n"); + rc = -ECANCELED; + goto out; + } + + msleep(TPM_TIMEOUT); /* CHECK */ + rmb(); + } while (NOW() < stop); + + /* Cancel the command */ + tpm_tis_cancel_cmd(chip); + printk("TPM Operation Timed out\n"); + rc = -ETIME; + goto out; + +out_recv: + if((rc = tpm_tis_recv(chip, (uint8_t *) buf, bufsiz)) < 0) { + printk("tpm_transmit: tpm_recv: error %d\n", rc); + } +out: + //up(&chip->tpm_mutex); + return rc; +} + +static ssize_t transmit_cmd(struct tpm_chip *chip, struct tpm_cmd_t *cmd, + int len, const char *desc) +{ + int err; + + len = tpm_transmit(chip,(uint8_t *) cmd, len); + if (len < 0) + return len; + if (len == TPM_ERROR_SIZE) { + err = be32_to_cpu(cmd->header.out.return_code); + printk("A TPM error (%d) occurred %s\n", err, desc); + return err; + } + return 0; +} + +void tpm_get_timeouts(struct tpm_chip *chip) +{ + struct tpm_cmd_t tpm_cmd; + struct timeout_t *timeout_cap; + struct duration_t *duration_cap; + ssize_t rc; + uint32_t timeout; + + tpm_cmd.header.in = tpm_getcap_header; + tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP; + tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4); + tpm_cmd.params.getcap_in.subcap = TPM_CAP_PROP_TIS_TIMEOUT; + + if((rc = transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE, + "attempting to determine the timeouts")) != 0) { + printk("transmit failed %d\n", rc); + goto duration; + } + + if (be32_to_cpu(tpm_cmd.params.getcap_out.cap_size) + != 4 * sizeof(uint32_t)) { + printk("Out len check failure %lu \n", be32_to_cpu(tpm_cmd.header.out.length)); + goto duration; + } + + timeout_cap = &tpm_cmd.params.getcap_out.cap.timeout; + /* Don't overwrite default if value is 0 */ + timeout = be32_to_cpu(timeout_cap->a); + if (timeout) + chip->timeout_a = MICROSECS(timeout); /*Convert to msec */ + timeout = be32_to_cpu(timeout_cap->b); + if (timeout) + chip->timeout_b = MICROSECS(timeout); /*Convert to msec */ + timeout = be32_to_cpu(timeout_cap->c); + if (timeout) + chip->timeout_c = MICROSECS(timeout); /*Convert to msec */ + timeout = be32_to_cpu(timeout_cap->d); + if (timeout) + chip->timeout_d = MICROSECS(timeout); /*Convert to msec */ + +duration: + tpm_cmd.header.in = tpm_getcap_header; + tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP; + tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4); + tpm_cmd.params.getcap_in.subcap = TPM_CAP_PROP_TIS_DURATION; + + if((rc = transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE, + "attempting to determine the durations")) < 0) { + return; + } + + if (be32_to_cpu(tpm_cmd.params.getcap_out.cap_size) + != 3 * sizeof(uint32_t)) { + return; + } + duration_cap = &tpm_cmd.params.getcap_out.cap.duration; + chip->duration[TPM_SHORT] = be32_to_cpu(duration_cap->tpm_short); + /* The Broadcom BCM0102 chipset in a Dell Latitude D820 gets the above + * value wrong and apparently reports msecs rather than usecs. So we + * fix up the resulting too-small TPM_SHORT value to make things work. + */ + if (chip->duration[TPM_SHORT] < 10) { + chip->duration[TPM_SHORT] = MILLISECS(chip->duration[TPM_SHORT]); + } else { + chip->duration[TPM_SHORT] = MICROSECS(chip->duration[TPM_SHORT]); + } + + chip->duration[TPM_MEDIUM] = MICROSECS(be32_to_cpu(duration_cap->tpm_medium)); + chip->duration[TPM_LONG] = MICROSECS(be32_to_cpu(duration_cap->tpm_long)); +} + + + +void tpm_continue_selftest(struct tpm_chip* chip) { + uint8_t data[] = { + 0, 193, /* TPM_TAG_RQU_COMMAND */ + 0, 0, 0, 10, /* length */ + 0, 0, 0, 83, /* TPM_ORD_GetCapability */ + }; + + tpm_transmit(chip, data, sizeof(data)); +} + +ssize_t tpm_getcap(struct tpm_chip *chip, uint32_t subcap_id, cap_t *cap, + const char *desc) +{ + struct tpm_cmd_t tpm_cmd; + int rc; + + tpm_cmd.header.in = tpm_getcap_header; + if (subcap_id == CAP_VERSION_1_1 || subcap_id == CAP_VERSION_1_2) { + tpm_cmd.params.getcap_in.cap = subcap_id; + /*subcap field not necessary */ + tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(0); + tpm_cmd.header.in.length -= cpu_to_be32(sizeof(uint32_t)); + } else { + if (subcap_id == TPM_CAP_FLAG_PERM || + subcap_id == TPM_CAP_FLAG_VOL) + tpm_cmd.params.getcap_in.cap = TPM_CAP_FLAG; + else + tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP; + tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4); + tpm_cmd.params.getcap_in.subcap = subcap_id; + } + rc = transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE, desc); + if (!rc) + *cap = tpm_cmd.params.getcap_out.cap; + return rc; +} + + +struct tpm_chip* init_tpm_tis(unsigned long baseaddr, int localities, unsigned int irq) +{ + int i; + unsigned long addr; + struct tpm_chip* tpm = NULL; + uint32_t didvid; + uint32_t intfcaps; + uint32_t intmask; + + printk("============= Init TPM TIS Driver ==============\n"); + + /*Sanity check the localities input */ + if(localities & ~TPM_TIS_EN_LOCLALL) { + printk("init_tpm_tis() Invalid locality specification! %X\n", localities); + goto abort_egress; + } + + printk("IOMEM Machine Base Address: %lX\n", baseaddr); + + /* Create the tpm data structure */ + tpm = malloc(sizeof(struct tpm_chip)); + __init_tpm_chip(tpm); + + /* Set the enabled localities - if 0 we leave default as all enabled */ + if(localities != 0) { + tpm->enabled_localities = localities; + } + printk("Enabled Localities: "); + for(i = 0; i < 5; ++i) { + if(locality_enabled(tpm, i)) { + printk("%d ", i); + } + } + printk("\n"); + + /* Set the base machine address */ + tpm->baseaddr = baseaddr; + + /* Set default timeouts */ + tpm->timeout_a = MILLISECS(TIS_SHORT_TIMEOUT); + tpm->timeout_b = MILLISECS(TIS_LONG_TIMEOUT); + tpm->timeout_c = MILLISECS(TIS_SHORT_TIMEOUT); + tpm->timeout_d = MILLISECS(TIS_SHORT_TIMEOUT); + + /*Map the mmio pages */ + addr = tpm->baseaddr; + for(i = 0; i < 5; ++i) { + if(locality_enabled(tpm, i)) { + /* Map the page in now */ + if((tpm->pages[i] = ioremap_nocache(addr, PAGE_SIZE)) == NULL) { + printk("Unable to map iomem page a address %p\n", addr); + goto abort_egress; + } + + /* Set default locality to the first enabled one */ + if (tpm->locality < 0) { + if(tpm_tis_request_locality(tpm, i) < 0) { + printk("Unable to request locality %d??\n", i); + goto abort_egress; + } + } + } + addr += PAGE_SIZE; + } + + + /* Get the vendor and device ids */ + didvid = ioread32(TPM_DID_VID(tpm, tpm->locality)); + tpm->did = didvid >> 16; + tpm->vid = didvid & 0xFFFF; + + + /* Get the revision id */ + tpm->rid = ioread8(TPM_RID(tpm, tpm->locality)); + + printk("1.2 TPM (device-id=0x%X vendor-id = %X rev-id = %X)\n", tpm->did, tpm->vid, tpm->rid); + + intfcaps = ioread32(TPM_INTF_CAPS(tpm, tpm->locality)); + printk("TPM interface capabilities (0x%x):\n", intfcaps); + if (intfcaps & TPM_INTF_BURST_COUNT_STATIC) + printk("\tBurst Count Static\n"); + if (intfcaps & TPM_INTF_CMD_READY_INT) + printk("\tCommand Ready Int Support\n"); + if (intfcaps & TPM_INTF_INT_EDGE_FALLING) + printk("\tInterrupt Edge Falling\n"); + if (intfcaps & TPM_INTF_INT_EDGE_RISING) + printk("\tInterrupt Edge Rising\n"); + if (intfcaps & TPM_INTF_INT_LEVEL_LOW) + printk("\tInterrupt Level Low\n"); + if (intfcaps & TPM_INTF_INT_LEVEL_HIGH) + printk("\tInterrupt Level High\n"); + if (intfcaps & TPM_INTF_LOCALITY_CHANGE_INT) + printk("\tLocality Change Int Support\n"); + if (intfcaps & TPM_INTF_STS_VALID_INT) + printk("\tSts Valid Int Support\n"); + if (intfcaps & TPM_INTF_DATA_AVAIL_INT) + printk("\tData Avail Int Support\n"); + + /*Interupt setup */ + intmask = ioread32(TPM_INT_ENABLE(tpm, tpm->locality)); + + intmask |= TPM_INTF_CMD_READY_INT + | TPM_INTF_LOCALITY_CHANGE_INT | TPM_INTF_DATA_AVAIL_INT + | TPM_INTF_STS_VALID_INT; + + iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), intmask); + + /*If interupts are enabled, handle it */ + if(irq) { + if(irq != TPM_PROBE_IRQ) { + tpm->irq = irq; + } else { + /*FIXME add irq probing feature later */ + printk("IRQ probing not implemented\n"); + } + } + + if(tpm->irq) { + iowrite8(TPM_INT_VECTOR(tpm, tpm->locality), tpm->irq); + + if(bind_pirq(tpm->irq, 1, tpm_tis_irq_handler, tpm) != 0) { + printk("Unabled to request irq: %u for use\n", tpm->irq); + printk("Will use polling mode\n"); + tpm->irq = 0; + } else { + /* Clear all existing */ + iowrite32(TPM_INT_STATUS(tpm, tpm->locality), ioread32(TPM_INT_STATUS(tpm, tpm->locality))); + + /* Turn on interrupts */ + iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), intmask | TPM_GLOBAL_INT_ENABLE); + } + } + + tpm_get_timeouts(tpm); + tpm_continue_selftest(tpm); + + + return tpm; +abort_egress: + if(tpm != NULL) { + shutdown_tpm_tis(tpm); + } + return NULL; +} + +void shutdown_tpm_tis(struct tpm_chip* tpm){ + int i; + + printk("Shutting down tpm_tis device\n"); + + iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), ~TPM_GLOBAL_INT_ENABLE); + + /*Unmap all of the mmio pages */ + for(i = 0; i < 5; ++i) { + if(tpm->pages[i] != NULL) { + iounmap(tpm->pages[i], PAGE_SIZE); + tpm->pages[i] = NULL; + } + } + free(tpm); + return; +} + + +int tpm_tis_cmd(struct tpm_chip* tpm, uint8_t* req, size_t reqlen, uint8_t** resp, size_t* resplen) +{ + if(tpm->locality < 0) { + printk("tpm_tis_cmd() failed! locality not set!\n"); + return -1; + } + if(reqlen > TPM_BUFSIZE) { + reqlen = TPM_BUFSIZE; + } + memcpy(tpm->data_buffer, req, reqlen); + *resplen = tpm_transmit(tpm, tpm->data_buffer, TPM_BUFSIZE); + + *resp = malloc(*resplen); + memcpy(*resp, tpm->data_buffer, *resplen); + return 0; +} + +#ifdef HAVE_LIBC +int tpm_tis_open(struct tpm_chip* tpm) +{ + /* Silently prevent multiple opens */ + if(tpm->fd != -1) { + return tpm->fd; + } + + tpm->fd = alloc_fd(FTYPE_TPM_TIS); + printk("tpm_tis_open() -> %d\n", tpm->fd); + files[tpm->fd].tpm_tis.dev = tpm; + files[tpm->fd].tpm_tis.offset = 0; + files[tpm->fd].tpm_tis.respgot = 0; + return tpm->fd; +} + +int tpm_tis_posix_write(int fd, const uint8_t* buf, size_t count) +{ + struct tpm_chip* tpm; + tpm = files[fd].tpm_tis.dev; + + if(tpm->locality < 0) { + printk("tpm_tis_posix_write() failed! locality not set!\n"); + errno = EINPROGRESS; + return -1; + } + if(count == 0) { + return 0; + } + + /* Return an error if we are already processing a command */ + if(count > TPM_BUFSIZE) { + count = TPM_BUFSIZE; + } + /* Send the command now */ + memcpy(tpm->data_buffer, buf, count); + if((tpm->data_len = tpm_transmit(tpm, tpm->data_buffer, TPM_BUFSIZE)) < 0) { + errno = EIO; + return -1; + } + return count; +} + +int tpm_tis_posix_read(int fd, uint8_t* buf, size_t count) +{ + int rc; + struct tpm_chip* tpm; + tpm = files[fd].tpm_tis.dev; + + if(count == 0) { + return 0; + } + + /* If there is no tpm resp to read, return EIO */ + if(tpm->data_len < 0) { + errno = EIO; + return -1; + } + + + /* Handle EOF case */ + if(files[fd].tpm_tis.offset >= tpm->data_len) { + rc = 0; + } else { + rc = min(tpm->data_len - files[fd].tpm_tis.offset, count); + memcpy(buf, tpm->data_buffer + files[fd].tpm_tis.offset, rc); + } + files[fd].tpm_tis.offset += rc; + /* Reset the data pending flag */ + return rc; +} +int tpm_tis_posix_fstat(int fd, struct stat* buf) +{ + struct tpm_chip* tpm; + tpm = files[fd].tpm_tis.dev; + + buf->st_mode = O_RDWR; + buf->st_uid = 0; + buf->st_gid = 0; + buf->st_size = be32_to_cpu(*((uint32_t*)(tpm->data_buffer + 2))); + buf->st_atime = buf->st_mtime = buf->st_ctime = time(NULL); + return 0; +} + + +#endif diff --git a/extras/mini-os/tpmback.c b/extras/mini-os/tpmback.c new file mode 100644 index 0000000..03bd20c --- /dev/null +++ b/extras/mini-os/tpmback.c @@ -0,0 +1,1115 @@ +/* + * Copyright (c) 2010-2012 United States Government, as represented by + * the Secretary of Defense. All rights reserved. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version 2 + * of the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + * + * Based upon the files: + * drivers/xen/tpmbk.c + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + + +#ifndef HAVE_LIBC +#define strtoul simple_strtoul +#endif + +//#define TPMBACK_PRINT_DEBUG +#ifdef TPMBACK_PRINT_DEBUG +#define TPMBACK_DEBUG(fmt,...) printk("Tpmback:Debug("__FILE__":%d) " fmt, __LINE__, ##__VA_ARGS__) +#define TPMBACK_DEBUG_MORE(fmt,...) printk(fmt, ##__VA_ARGS__) +#else +#define TPMBACK_DEBUG(fmt,...) +#endif +#define TPMBACK_ERR(fmt,...) printk("Tpmback:Error " fmt, ##__VA_ARGS__) +#define TPMBACK_LOG(fmt,...) printk("Tpmback:Info " fmt, ##__VA_ARGS__) + +#define min(a,b) (((a) < (b)) ? (a) : (b)) + +/* Default size of the tpmif array at initialization */ +#define DEF_ARRAY_SIZE 1 + +/* tpmif and tpmdev flags */ +#define TPMIF_CLOSED 1 +#define TPMIF_REQ_READY 2 + +struct tpmif { + domid_t domid; + unsigned int handle; + + char* fe_path; + char* fe_state_path; + + /* Locally bound event channel*/ + evtchn_port_t evtchn; + + /* Shared page */ + tpmif_tx_interface_t* tx; + + /* pointer to TPMIF_RX_RING_SIZE pages */ + void** pages; + + enum xenbus_state state; + enum { DISCONNECTED, DISCONNECTING, CONNECTED } status; + + char* uuid; + + /* state flags */ + int flags; +}; +typedef struct tpmif tpmif_t; + +struct tpmback_dev { + + tpmif_t** tpmlist; + unsigned long num_tpms; + unsigned long num_alloc; + + struct gntmap map; + + /* True if at least one tpmif has a request to be handled */ + int flags; + + /* exclusive domains, see init_tpmback comment in tpmback.h */ + char** exclusive_uuids; + + xenbus_event_queue events; + + /* Callbacks */ + void (*open_callback)(domid_t, unsigned int); + void (*close_callback)(domid_t, unsigned int); + void (*suspend_callback)(domid_t, unsigned int); + void (*resume_callback)(domid_t, unsigned int); +}; +typedef struct tpmback_dev tpmback_dev_t; + +enum { EV_NONE, EV_NEWFE, EV_STCHNG } tpm_ev_enum; + +/* Global objects */ +static struct thread* eventthread = NULL; +static tpmback_dev_t gtpmdev = { + .tpmlist = NULL, + .num_tpms = 0, + .num_alloc = 0, + .flags = TPMIF_CLOSED, + .events = NULL, + .open_callback = NULL, + .close_callback = NULL, + .suspend_callback = NULL, + .resume_callback = NULL, +}; +struct wait_queue_head waitq; +int globalinit = 0; + +/************************************ + * TPMIF SORTED ARRAY FUNCTIONS + * tpmback_dev_t.tpmlist is a sorted array, sorted by domid and then handle number + * Duplicates are not allowed + * **********************************/ + +inline void tpmif_req_ready(tpmif_t* tpmif) { + tpmif->flags |= TPMIF_REQ_READY; + gtpmdev.flags |= TPMIF_REQ_READY; +} + +inline void tpmdev_check_req(void) { + int i; + int flags; + local_irq_save(flags); + for(i = 0; i < gtpmdev.num_tpms; ++i) { + if(gtpmdev.tpmlist[i]->flags & TPMIF_REQ_READY) { + gtpmdev.flags |= TPMIF_REQ_READY; + local_irq_restore(flags); + return; + } + } + gtpmdev.flags &= ~TPMIF_REQ_READY; + local_irq_restore(flags); +} + +inline void tpmif_req_finished(tpmif_t* tpmif) { + tpmif->flags &= ~TPMIF_REQ_READY; + tpmdev_check_req(); +} + +int __get_tpmif_index(int st, int n, domid_t domid, unsigned int handle) +{ + int i = st + n /2; + tpmif_t* tmp; + + if( n <= 0 ) + return -1; + + tmp = gtpmdev.tpmlist[i]; + if(domid == tmp->domid && tmp->handle == handle) { + return i; + } else if ( (domid < tmp->domid) || + (domid == tmp->domid && handle < tmp->handle)) { + return __get_tpmif_index(st, n/2, domid, handle); + } else { + return __get_tpmif_index(i + 1, n/2 - ((n +1) % 2), domid, handle); + } +} + +/* Returns the array index of the tpmif domid/handle. Returns -1 if no such tpmif exists */ +int get_tpmif_index(domid_t domid, unsigned int handle) +{ + int flags; + int index; + local_irq_save(flags); + index = __get_tpmif_index(0, gtpmdev.num_tpms, domid, handle); + local_irq_restore(flags); + return index; +} + +/* Returns the tpmif domid/handle or NULL if none exists */ +tpmif_t* get_tpmif(domid_t domid, unsigned int handle) +{ + int flags; + int i; + tpmif_t* ret; + local_irq_save(flags); + i = get_tpmif_index(domid, handle); + if (i < 0) { + ret = NULL; + } else { + ret = gtpmdev.tpmlist[i]; + } + local_irq_restore(flags); + return ret; +} + +/* Remove the given tpmif. Returns 0 if it was removed, -1 if it was not removed */ +int remove_tpmif(tpmif_t* tpmif) +{ + int i, j; + char* err; + int flags; + local_irq_save(flags); + + /* Find the index in the array if it exists */ + i = get_tpmif_index(tpmif->domid, tpmif->handle); + if (i < 0) { + goto error; + } + + /* Remove the interface from the list */ + for(j = i; j < gtpmdev.num_tpms - 1; ++j) { + gtpmdev.tpmlist[j] = gtpmdev.tpmlist[j+1]; + } + gtpmdev.tpmlist[j] = NULL; + --gtpmdev.num_tpms; + + /* If removed tpm was the only ready tpm, then we need to check and turn off the ready flag */ + tpmdev_check_req(); + + local_irq_restore(flags); + + /* Stop listening for events on this tpm interface */ + if((err = xenbus_unwatch_path_token(XBT_NIL, tpmif->fe_state_path, tpmif->fe_state_path))) { + TPMBACK_ERR("Unable to unwatch path token `%s' Error was %s Ignoring..\n", tpmif->fe_state_path, err); + free(err); + } + + return 0; +error: + local_irq_restore(flags); + return -1; +} + +/* Insert tpmif into dev->tpmlist. Returns 0 on success and non zero on error. + * It is an error to insert a tpmif with the same domid and handle + * number + * as something already in the list */ +int insert_tpmif(tpmif_t* tpmif) +{ + int flags; + unsigned int i, j; + tpmif_t* tmp; + char* err; + + local_irq_save(flags); + + /*Check if we need to allocate more space */ + if (gtpmdev.num_tpms == gtpmdev.num_alloc) { + gtpmdev.num_alloc *= 2; + gtpmdev.tpmlist = realloc(gtpmdev.tpmlist, gtpmdev.num_alloc); + } + + /*Find where to put the new interface */ + for(i = 0; i < gtpmdev.num_tpms; ++i) + { + tmp = gtpmdev.tpmlist[i]; + if(tpmif->domid == tmp->domid && tpmif->handle == tmp->handle) { + TPMBACK_ERR("Tried to insert duplicate tpm interface %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle); + goto error; + } + if((tpmif->domid < tmp->domid) || + (tpmif->domid == tmp->domid && tpmif->handle < tmp->handle)) { + break; + } + } + + /*Shift all the tpm pointers past i down one */ + for(j = gtpmdev.num_tpms; j > i; --j) { + gtpmdev.tpmlist[j] = gtpmdev.tpmlist[j-1]; + } + + /*Add the new interface */ + gtpmdev.tpmlist[i] = tpmif; + ++gtpmdev.num_tpms; + + /*Should not be needed, anything inserted with ready flag is probably an error */ + tpmdev_check_req(); + + local_irq_restore(flags); + + /*Listen for state changes on the new interface */ + if((err = xenbus_watch_path_token(XBT_NIL, tpmif->fe_state_path, tpmif->fe_state_path, >pmdev.events))) + { + /* if we got an error here we should carefully remove the interface and then return */ + TPMBACK_ERR("Unable to watch path token `%s' Error was %s\n", tpmif->fe_state_path, err); + free(err); + remove_tpmif(tpmif); + goto error_post_irq; + } + + return 0; +error: + local_irq_restore(flags); +error_post_irq: + return -1; +} + + +/***************** + * CHANGE BACKEND STATE + * *****************/ +/*Attempts to change the backend state in xenstore + * returns 0 on success and non-zero on error */ +int tpmif_change_state(tpmif_t* tpmif, enum xenbus_state state) +{ + char path[512]; + char *value; + char *err; + enum xenbus_state readst; + TPMBACK_DEBUG("Backend state change %u/%u from=%d to=%d\n", (unsigned int) tpmif->domid, tpmif->handle, tpmif->state, state); + if (tpmif->state == state) + return 0; + + snprintf(path, 512, "backend/vtpm/%u/%u/state", (unsigned int) tpmif->domid, tpmif->handle); + + if((err = xenbus_read(XBT_NIL, path, &value))) { + TPMBACK_ERR("Unable to read backend state %s, error was %s\n", path, err); + free(err); + return -1; + } + if(sscanf(value, "%d", &readst) != 1) { + TPMBACK_ERR("Non integer value (%s) in %s ??\n", value, path); + free(value); + return -1; + } + free(value); + + /* It's possible that the backend state got updated by hotplug or something else behind our back */ + if(readst != tpmif->state) { + TPMBACK_DEBUG("tpm interface state was %d but xenstore state was %d!\n", tpmif->state, readst); + tpmif->state = readst; + } + + /*If if the state isnt changing, then we dont update xenstore b/c we dont want to fire extraneous events */ + if(tpmif->state == state) { + return 0; + } + + /*update xenstore*/ + snprintf(path, 512, "backend/vtpm/%u/%u", (unsigned int) tpmif->domid, tpmif->handle); + if((err = xenbus_printf(XBT_NIL, path, "state", "%u", state))) { + TPMBACK_ERR("Error writing to xenstore %s, error was %s new state=%d\n", path, err, state); + free(err); + return -1; + } + + tpmif->state = state; + + return 0; +} +/********************************** + * TPMIF CREATION AND DELETION + * *******************************/ +inline tpmif_t* __init_tpmif(domid_t domid, unsigned int handle) +{ + tpmif_t* tpmif; + tpmif = malloc(sizeof(*tpmif)); + tpmif->domid = domid; + tpmif->handle = handle; + tpmif->fe_path = NULL; + tpmif->fe_state_path = NULL; + tpmif->state = XenbusStateInitialising; + tpmif->status = DISCONNECTED; + tpmif->tx = NULL; + tpmif->pages = NULL; + tpmif->flags = 0; + tpmif->uuid = NULL; + return tpmif; +} + +void __free_tpmif(tpmif_t* tpmif) +{ + if(tpmif->pages) { + free(tpmif->pages); + } + if(tpmif->fe_path) { + free(tpmif->fe_path); + } + if(tpmif->fe_state_path) { + free(tpmif->fe_state_path); + } + if(tpmif->uuid) { + free(tpmif->uuid); + } + free(tpmif); +} +/* Creates a new tpm interface, adds it to the sorted array and returns it. + * returns NULL on error + * If the tpm interface already exists, it is returned*/ +tpmif_t* new_tpmif(domid_t domid, unsigned int handle) +{ + tpmif_t* tpmif; + char* err; + char path[512]; + + /* Make sure we haven't already created this tpm + * Double events can occur */ + if((tpmif = get_tpmif(domid, handle)) != NULL) { + return tpmif; + } + + tpmif = __init_tpmif(domid, handle); + + /* Get the uuid from xenstore */ + snprintf(path, 512, "backend/vtpm/%u/%u/uuid", (unsigned int) domid, handle); + if((err = xenbus_read(XBT_NIL, path, &tpmif->uuid))) { + TPMBACK_ERR("Error reading %s, Error = %s\n", path, err); + free(err); + goto error; + } + + /* Do the exclusive uuid check now */ + if(gtpmdev.exclusive_uuids != NULL) { + char** ptr; + + /* Check that its in the whitelist */ + for(ptr = gtpmdev.exclusive_uuids; *ptr != NULL; ++ptr) { + if(!strcmp(tpmif->uuid, *ptr)) { + break; + } + } + /* If *ptr == NULL then we went through the whole list without a match, so close the connection */ + if(*ptr == NULL) { + tpmif_change_state(tpmif, XenbusStateClosed); + TPMBACK_ERR("Frontend %u/%u tried to connect with invalid uuid=%s\n", (unsigned int) domid, handle, tpmif->uuid); + goto error; + } + } + + /* allocate pages to be used for shared mapping */ + if((tpmif->pages = malloc(sizeof(void*) * TPMIF_TX_RING_SIZE)) == NULL) { + goto error; + } + memset(tpmif->pages, 0, sizeof(void*) * TPMIF_TX_RING_SIZE); + + if(tpmif_change_state(tpmif, XenbusStateInitWait)) { + goto error; + } + + snprintf(path, 512, "backend/vtpm/%u/%u/frontend", (unsigned int) domid, handle); + if((err = xenbus_read(XBT_NIL, path, &tpmif->fe_path))) { + TPMBACK_ERR("Error creating new tpm instance xenbus_read(%s), Error = %s", path, err); + free(err); + goto error; + } + + /*Set the state path */ + tpmif->fe_state_path = malloc(strlen(tpmif->fe_path) + 7); + strcpy(tpmif->fe_state_path, tpmif->fe_path); + strcat(tpmif->fe_state_path, "/state"); + + if(insert_tpmif(tpmif)) { + goto error; + } + TPMBACK_DEBUG("New tpmif %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle); + /* Do the callback now */ + if(gtpmdev.open_callback) { + gtpmdev.open_callback(tpmif->domid, tpmif->handle); + } + return tpmif; +error: + __free_tpmif(tpmif); + return NULL; + +} + +/* Removes tpmif from dev->tpmlist and frees it's memory usage */ +void free_tpmif(tpmif_t* tpmif) +{ + char* err; + char path[512]; + TPMBACK_DEBUG("Free tpmif %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle); + if(tpmif->flags & TPMIF_CLOSED) { + TPMBACK_ERR("Tried to free an instance twice! Theres a bug somewhere!\n"); + BUG(); + } + tpmif->flags = TPMIF_CLOSED; + + tpmif_change_state(tpmif, XenbusStateClosing); + + /* Unmap share page and unbind event channel */ + if(tpmif->status == CONNECTED) { + tpmif->status = DISCONNECTING; + mask_evtchn(tpmif->evtchn); + + if(gntmap_munmap(>pmdev.map, (unsigned long)tpmif->tx, 1)) { + TPMBACK_ERR("%u/%u Error occured while trying to unmap shared page\n", (unsigned int) tpmif->domid, tpmif->handle); + } + + unbind_evtchn(tpmif->evtchn); + } + tpmif->status = DISCONNECTED; + tpmif_change_state(tpmif, XenbusStateClosed); + + /* Do the callback now */ + if(gtpmdev.close_callback) { + gtpmdev.close_callback(tpmif->domid, tpmif->handle); + } + + /* remove from array */ + remove_tpmif(tpmif); + + /* Wake up anyone possibly waiting on this interface and let them exit */ + wake_up(&waitq); + schedule(); + + /* Remove the old xenbus entries */ + snprintf(path, 512, "backend/vtpm/%u/%u", (unsigned int) tpmif->domid, tpmif->handle); + if((err = xenbus_rm(XBT_NIL, path))) { + TPMBACK_ERR("Error cleaning up xenbus entries path=%s error=%s\n", path, err); + free(err); + } + + TPMBACK_LOG("Frontend %u/%u disconnected\n", (unsigned int) tpmif->domid, tpmif->handle); + + /* free memory */ + __free_tpmif(tpmif); + +} + +/********************** + * REMAINING TPMBACK FUNCTIONS + * ********************/ + +/*Event channel handler */ +void tpmback_handler(evtchn_port_t port, struct pt_regs *regs, void *data) +{ + tpmif_t* tpmif = (tpmif_t*) data; + tpmif_tx_request_t* tx = &tpmif->tx->ring[0].req; + /* Throw away 0 size events, these can trigger from event channel unmasking */ + if(tx->size == 0) + return; + + TPMBACK_DEBUG("EVENT CHANNEL FIRE %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle); + tpmif_req_ready(tpmif); + wake_up(&waitq); + +} + +/* Connect to frontend */ +int connect_fe(tpmif_t* tpmif) +{ + char path[512]; + char* err, *value; + uint32_t domid; + grant_ref_t ringref; + evtchn_port_t evtchn; + + /* If already connected then quit */ + if (tpmif->status == CONNECTED) { + TPMBACK_DEBUG("%u/%u tried to connect while it was already connected?\n", (unsigned int) tpmif->domid, tpmif->handle); + return 0; + } + + /* Fetch the grant reference */ + snprintf(path, 512, "%s/ring-ref", tpmif->fe_path); + if((err = xenbus_read(XBT_NIL, path, &value))) { + TPMBACK_ERR("Error creating new tpm instance xenbus_read(%s) Error = %s", path, err); + free(err); + return -1; + } + if(sscanf(value, "%d", &ringref) != 1) { + TPMBACK_ERR("Non integer value (%s) in %s ??\n", value, path); + free(value); + return -1; + } + free(value); + + + /* Fetch the event channel*/ + snprintf(path, 512, "%s/event-channel", tpmif->fe_path); + if((err = xenbus_read(XBT_NIL, path, &value))) { + TPMBACK_ERR("Error creating new tpm instance xenbus_read(%s) Error = %s", path, err); + free(err); + return -1; + } + if(sscanf(value, "%d", &evtchn) != 1) { + TPMBACK_ERR("Non integer value (%s) in %s ??\n", value, path); + free(value); + return -1; + } + free(value); + + domid = tpmif->domid; + if((tpmif->tx = gntmap_map_grant_refs(>pmdev.map, 1, &domid, 0, &ringref, PROT_READ | PROT_WRITE)) == NULL) { + TPMBACK_ERR("Failed to map grant reference %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle); + return -1; + } + memset(tpmif->tx, 0, PAGE_SIZE); + + /*Bind the event channel */ + if((evtchn_bind_interdomain(tpmif->domid, evtchn, tpmback_handler, tpmif, &tpmif->evtchn))) + { + TPMBACK_ERR("%u/%u Unable to bind to interdomain event channel!\n", (unsigned int) tpmif->domid, tpmif->handle); + goto error_post_map; + } + unmask_evtchn(tpmif->evtchn); + + /* Write the ready flag and change status to connected */ + snprintf(path, 512, "backend/vtpm/%u/%u", (unsigned int) tpmif->domid, tpmif->handle); + if((err = xenbus_printf(XBT_NIL, path, "ready", "%u", 1))) { + TPMBACK_ERR("%u/%u Unable to write ready flag on connect_fe()\n", (unsigned int) tpmif->domid, tpmif->handle); + free(err); + goto error_post_evtchn; + } + tpmif->status = CONNECTED; + if((tpmif_change_state(tpmif, XenbusStateConnected))){ + goto error_post_evtchn; + } + + TPMBACK_LOG("Frontend %u/%u connected\n", (unsigned int) tpmif->domid, tpmif->handle); + + return 0; +error_post_evtchn: + mask_evtchn(tpmif->evtchn); + unbind_evtchn(tpmif->evtchn); +error_post_map: + gntmap_munmap(>pmdev.map, (unsigned long)tpmif->tx, 1); + return -1; +} + +static int frontend_changed(tpmif_t* tpmif) +{ + int state = xenbus_read_integer(tpmif->fe_state_path); + if(state < 0) { + state = XenbusStateUnknown; + } + + TPMBACK_DEBUG("Frontend %u/%u state changed to %d\n", (unsigned int) tpmif->domid, tpmif->handle, state); + + switch (state) { + case XenbusStateInitialising: + case XenbusStateInitialised: + break; + + case XenbusStateConnected: + if(connect_fe(tpmif)) { + TPMBACK_ERR("Failed to connect to front end %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle); + tpmif_change_state(tpmif, XenbusStateClosed); + return -1; + } + break; + + case XenbusStateClosing: + tpmif_change_state(tpmif, XenbusStateClosing); + break; + + case XenbusStateUnknown: /* keep it here */ + case XenbusStateClosed: + free_tpmif(tpmif); + break; + + default: + TPMBACK_DEBUG("BAD STATE CHANGE %u/%u state = %d for tpmif\n", (unsigned int) tpmif->domid, tpmif->handle, state); + return -1; + } + return 0; +} + + +/* parses the string that comes out of xenbus_watch_wait_return. */ +static int parse_eventstr(const char* evstr, domid_t* domid, unsigned int* handle) +{ + int ret; + char cmd[40]; + char* err; + char* value; + unsigned int udomid = 0; + tpmif_t* tpmif; + /* First check for new frontends, this occurs when /backend/vtpm// gets created. Note we what the sscanf to fail on the last %s */ + if (sscanf(evstr, "backend/vtpm/%u/%u/%40s", &udomid, handle, cmd) == 2) { + *domid = udomid; + /* Make sure the entry exists, if this event triggers because the entry dissapeared then ignore it */ + if((err = xenbus_read(XBT_NIL, evstr, &value))) { + free(err); + return EV_NONE; + } + free(value); + /* Make sure the tpmif entry does not already exist, this should not happen */ + if((tpmif = get_tpmif(*domid, *handle)) != NULL) { + TPMBACK_DEBUG("Duplicate tpm entries! %u %u\n", tpmif->domid, tpmif->handle); + return EV_NONE; + } + return EV_NEWFE; + } else if((ret = sscanf(evstr, "/local/domain/%u/device/vtpm/%u/%40s", &udomid, handle, cmd)) == 3) { + *domid = udomid; + if (!strcmp(cmd, "state")) + return EV_STCHNG; + } + return EV_NONE; +} + +void handle_backend_event(char* evstr) { + tpmif_t* tpmif; + domid_t domid; + unsigned int handle; + int event; + + TPMBACK_DEBUG("Xenbus Event: %s\n", evstr); + + event = parse_eventstr(evstr, &domid, &handle); + + switch(event) { + case EV_NEWFE: + if(new_tpmif(domid, handle) == NULL) { + TPMBACK_ERR("Failed to create new tpm instance %u/%u\n", (unsigned int) domid, handle); + } + wake_up(&waitq); + break; + case EV_STCHNG: + if((tpmif = get_tpmif(domid, handle))) { + frontend_changed(tpmif); + } else { + TPMBACK_DEBUG("Event Received for non-existant tpm! instance=%u/%u xenbus_event=%s\n", (unsigned int) domid, handle, evstr); + } + break; + } +} + +/* Runs through the given path and creates events recursively + * for all of its children. + * @path - xenstore path to scan */ +static void generate_backend_events(const char* path) +{ + char* err; + int i, len; + char **dirs; + char *entry; + + if((err = xenbus_ls(XBT_NIL, path, &dirs)) != NULL) { + free(err); + return; + } + + for(i = 0; dirs[i] != NULL; ++i) { + len = strlen(path) + strlen(dirs[i]) + 2; + entry = malloc(len); + snprintf(entry, len, "%s/%s", path, dirs[i]); + + /* Generate and handle event for the entry itself */ + handle_backend_event(entry); + + /* Do children */ + generate_backend_events(entry); + + /* Cleanup */ + free(entry); + free(dirs[i]); + } + free(dirs); + return; +} + +char* tpmback_get_uuid(domid_t domid, unsigned int handle) +{ + tpmif_t* tpmif; + if((tpmif = get_tpmif(domid, handle)) == NULL) { + TPMBACK_DEBUG("get_uuid() failed, %u/%u is an invalid frontend\n", (unsigned int) domid, handle); + return NULL; + } + + return tpmif->uuid; +} + +void tpmback_set_open_callback(void (*cb)(domid_t, unsigned int)) +{ + gtpmdev.open_callback = cb; +} +void tpmback_set_close_callback(void (*cb)(domid_t, unsigned int)) +{ + gtpmdev.close_callback = cb; +} +void tpmback_set_suspend_callback(void (*cb)(domid_t, unsigned int)) +{ + gtpmdev.suspend_callback = cb; +} +void tpmback_set_resume_callback(void (*cb)(domid_t, unsigned int)) +{ + gtpmdev.resume_callback = cb; +} + +static void event_listener(void) +{ + const char* bepath = "backend/vtpm"; + char **path; + char* err; + + /* Setup the backend device watch */ + if((err = xenbus_watch_path_token(XBT_NIL, bepath, bepath, >pmdev.events)) != NULL) { + TPMBACK_ERR("xenbus_watch_path_token(%s) failed with error %s!\n", bepath, err); + free(err); + goto egress; + } + + /* Check for any frontends that connected before we set the watch. + * This is almost guaranteed to happen if both domains are started + * immediatly one after the other. + * We do this by manually generating events on everything in the backend + * path */ + generate_backend_events(bepath); + + /* Wait and listen for changes in frontend connections */ + while(1) { + path = xenbus_wait_for_watch_return(>pmdev.events); + + /*If quit flag was set then exit */ + if(gtpmdev.flags & TPMIF_CLOSED) { + TPMBACK_DEBUG("listener thread got quit event. Exiting..\n"); + free(path); + break; + } + handle_backend_event(*path); + free(path); + + } + + if((err = xenbus_unwatch_path_token(XBT_NIL, bepath, bepath)) != NULL) { + free(err); + } +egress: + return; +} + +void event_thread(void* p) { + event_listener(); +} + +void init_tpmback(char** exclusive_uuids) +{ + if(!globalinit) { + init_waitqueue_head(&waitq); + globalinit = 1; + } + printk("============= Init TPM BACK ================\n"); + gtpmdev.tpmlist = malloc(sizeof(tpmif_t*) * DEF_ARRAY_SIZE); + gtpmdev.num_alloc = DEF_ARRAY_SIZE; + gtpmdev.num_tpms = 0; + gtpmdev.flags = 0; + gtpmdev.exclusive_uuids = exclusive_uuids; + + gtpmdev.open_callback = gtpmdev.close_callback = NULL; + gtpmdev.suspend_callback = gtpmdev.resume_callback = NULL; + + eventthread = create_thread("tpmback-listener", event_thread, NULL); + +} + +void shutdown_tpmback(void) +{ + /* Disable callbacks */ + gtpmdev.open_callback = gtpmdev.close_callback = NULL; + gtpmdev.suspend_callback = gtpmdev.resume_callback = NULL; + + TPMBACK_LOG("Shutting down tpm backend\n"); + /* Set the quit flag */ + gtpmdev.flags = TPMIF_CLOSED; + + //printk("num tpms is %d\n", gtpmdev.num_tpms); + /*Free all backend instances */ + while(gtpmdev.num_tpms) { + free_tpmif(gtpmdev.tpmlist[0]); + } + free(gtpmdev.tpmlist); + gtpmdev.tpmlist = NULL; + gtpmdev.num_alloc = 0; + + /* Wake up anyone possibly waiting on the device and let them exit */ + wake_up(&waitq); + schedule(); +} + +inline void init_tpmcmd(tpmcmd_t* tpmcmd, domid_t domid, unsigned int handle, char* uuid) +{ + tpmcmd->domid = domid; + tpmcmd->handle = handle; + tpmcmd->uuid = uuid; + tpmcmd->req = NULL; + tpmcmd->req_len = 0; + tpmcmd->resp = NULL; + tpmcmd->resp_len = 0; +} + +tpmcmd_t* get_request(tpmif_t* tpmif) { + tpmcmd_t* cmd; + tpmif_tx_request_t* tx; + int offset; + int tocopy; + int i; + uint32_t domid; + int flags; + + local_irq_save(flags); + + /* Allocate the cmd object to hold the data */ + if((cmd = malloc(sizeof(*cmd))) == NULL) { + goto error; + } + init_tpmcmd(cmd, tpmif->domid, tpmif->handle, tpmif->uuid); + + tx = &tpmif->tx->ring[0].req; + cmd->req_len = tx->size; + /* Allocate the buffer */ + if(cmd->req_len) { + if((cmd->req = malloc(cmd->req_len)) == NULL) { + goto error; + } + } + /* Copy the bits from the shared pages */ + offset = 0; + for(i = 0; i < TPMIF_TX_RING_SIZE && offset < cmd->req_len; ++i) { + tx = &tpmif->tx->ring[i].req; + + /* Map the page with the data */ + domid = (uint32_t)tpmif->domid; + if((tpmif->pages[i] = gntmap_map_grant_refs(>pmdev.map, 1, &domid, 0, &tx->ref, PROT_READ)) == NULL) { + TPMBACK_ERR("%u/%u Unable to map shared page during read!\n", (unsigned int) tpmif->domid, tpmif->handle); + goto error; + } + + /* do the copy now */ + tocopy = min(cmd->req_len - offset, PAGE_SIZE); + memcpy(&cmd->req[offset], tpmif->pages[i], tocopy); + offset += tocopy; + + /* release the page */ + gntmap_munmap(>pmdev.map, (unsigned long)tpmif->pages[i], 1); + + } + +#ifdef TPMBACK_PRINT_DEBUG + TPMBACK_DEBUG("Received Tpm Command from %u/%u of size %u", (unsigned int) tpmif->domid, tpmif->handle, cmd->req_len); + for(i = 0; i < cmd->req_len; ++i) { + if (!(i % 30)) { + TPMBACK_DEBUG_MORE("\n"); + } + TPMBACK_DEBUG_MORE("%02hhX ", cmd->req[i]); + } + TPMBACK_DEBUG_MORE("\n\n"); +#endif + + local_irq_restore(flags); + return cmd; +error: + if(cmd != NULL) { + if (cmd->req != NULL) { + free(cmd->req); + cmd->req = NULL; + } + free(cmd); + cmd = NULL; + } + local_irq_restore(flags); + return NULL; + +} + +void send_response(tpmcmd_t* cmd, tpmif_t* tpmif) +{ + tpmif_tx_request_t* tx; + int offset; + int i; + uint32_t domid; + int tocopy; + int flags; + + local_irq_save(flags); + + tx = &tpmif->tx->ring[0].req; + tx->size = cmd->resp_len; + + offset = 0; + for(i = 0; i < TPMIF_TX_RING_SIZE && offset < cmd->resp_len; ++i) { + tx = &tpmif->tx->ring[i].req; + + /* Map the page with the data */ + domid = (uint32_t)tpmif->domid; + if((tpmif->pages[i] = gntmap_map_grant_refs(>pmdev.map, 1, &domid, 0, &tx->ref, PROT_WRITE)) == NULL) { + TPMBACK_ERR("%u/%u Unable to map shared page during write!\n", (unsigned int) tpmif->domid, tpmif->handle); + goto error; + } + + /* do the copy now */ + tocopy = min(cmd->resp_len - offset, PAGE_SIZE); + memcpy(tpmif->pages[i], &cmd->resp[offset], tocopy); + offset += tocopy; + + /* release the page */ + gntmap_munmap(>pmdev.map, (unsigned long)tpmif->pages[i], 1); + + } + +#ifdef TPMBACK_PRINT_DEBUG + TPMBACK_DEBUG("Sent response to %u/%u of size %u", (unsigned int) tpmif->domid, tpmif->handle, cmd->resp_len); + for(i = 0; i < cmd->resp_len; ++i) { + if (!(i % 30)) { + TPMBACK_DEBUG_MORE("\n"); + } + TPMBACK_DEBUG_MORE("%02hhX ", cmd->resp[i]); + } + TPMBACK_DEBUG_MORE("\n\n"); +#endif + /* clear the ready flag and send the event channel notice to the frontend */ + tpmif_req_finished(tpmif); + notify_remote_via_evtchn(tpmif->evtchn); +error: + local_irq_restore(flags); + return; +} + +tpmcmd_t* tpmback_req_any(void) +{ + int i; + /* Block until something has a request */ + wait_event(waitq, (gtpmdev.flags & (TPMIF_REQ_READY | TPMIF_CLOSED))); + + /* Check if were shutting down */ + if(gtpmdev.flags & TPMIF_CLOSED) { + /* if something was waiting for us to give up the queue so it can shutdown, let it finish */ + schedule(); + return NULL; + } + + for(i = 0; i < gtpmdev.num_tpms; ++i) { + if(gtpmdev.tpmlist[i]->flags & TPMIF_REQ_READY) { + return get_request(gtpmdev.tpmlist[i]); + } + } + + TPMBACK_ERR("backend request ready flag was set but no interfaces were actually ready\n"); + return NULL; +} + +tpmcmd_t* tpmback_req(domid_t domid, unsigned int handle) +{ + tpmif_t* tpmif; + tpmif = get_tpmif(domid, handle); + if(tpmif == NULL) { + return NULL; + } + + wait_event(waitq, (tpmif->flags & (TPMIF_REQ_READY | TPMIF_CLOSED) || gtpmdev.flags & TPMIF_CLOSED)); + + /* Check if were shutting down */ + if(tpmif->flags & TPMIF_CLOSED || gtpmdev.flags & TPMIF_CLOSED) { + /* if something was waiting for us to give up the queue so it can free this instance, let it finish */ + schedule(); + return NULL; + } + + return get_request(tpmif); +} + +void tpmback_resp(tpmcmd_t* tpmcmd) +{ + tpmif_t* tpmif; + + /* Get the associated interface, if it doesnt exist then just quit */ + tpmif = get_tpmif(tpmcmd->domid, tpmcmd->handle); + if(tpmif == NULL) { + TPMBACK_ERR("Tried to send a reponse to non existant frontend %u/%u\n", (unsigned int) tpmcmd->domid, tpmcmd->handle); + goto end; + } + + if(!(tpmif->flags & TPMIF_REQ_READY)) { + TPMBACK_ERR("Tried to send response to a frontend that was not waiting for one %u/%u\n", (unsigned int) tpmcmd->domid, tpmcmd->handle); + goto end; + } + + /* Send response to frontend */ + send_response(tpmcmd, tpmif); + +end: + if(tpmcmd->req != NULL) { + free(tpmcmd->req); + } + free(tpmcmd); + return; +} + +int tpmback_wait_for_frontend_connect(domid_t *domid, unsigned int *handle) +{ + tpmif_t* tpmif; + int flags; + wait_event(waitq, ((gtpmdev.num_tpms > 0) || gtpmdev.flags & TPMIF_CLOSED)); + if(gtpmdev.flags & TPMIF_CLOSED) { + return -1; + } + local_irq_save(flags); + tpmif = gtpmdev.tpmlist[0]; + *domid = tpmif->domid; + *handle = tpmif->handle; + local_irq_restore(flags); + + return 0; +} + +int tpmback_num_frontends(void) +{ + return gtpmdev.num_tpms; +} diff --git a/extras/mini-os/tpmfront.c b/extras/mini-os/tpmfront.c new file mode 100644 index 0000000..84fc6af --- /dev/null +++ b/extras/mini-os/tpmfront.c @@ -0,0 +1,607 @@ +/* + * Copyright (c) 2010-2012 United States Government, as represented by + * the Secretary of Defense. All rights reserved. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version 2 + * of the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + * + * Based upon the files: + * drivers/char/tpm/tpm_vtpm.c + * drivers/char/tpm/tpm_xen.c + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +//#define TPMFRONT_PRINT_DEBUG +#ifdef TPMFRONT_PRINT_DEBUG +#define TPMFRONT_DEBUG(fmt,...) printk("Tpmfront:Debug("__FILE__":%d) " fmt, __LINE__, ##__VA_ARGS__) +#define TPMFRONT_DEBUG_MORE(fmt,...) printk(fmt, ##__VA_ARGS__) +#else +#define TPMFRONT_DEBUG(fmt,...) +#endif +#define TPMFRONT_ERR(fmt,...) printk("Tpmfront:Error " fmt, ##__VA_ARGS__) +#define TPMFRONT_LOG(fmt,...) printk("Tpmfront:Info " fmt, ##__VA_ARGS__) + +#define min(a,b) (((a) < (b)) ? (a) : (b)) + +void tpmfront_handler(evtchn_port_t port, struct pt_regs *regs, void *data) { + struct tpmfront_dev* dev = (struct tpmfront_dev*) data; + /*If we get a response when we didnt make a request, just ignore it */ + if(!dev->waiting) { + return; + } + + dev->waiting = 0; +#ifdef HAVE_LIBC + if(dev->fd >= 0) { + files[dev->fd].read = 1; + } +#endif + wake_up(&dev->waitq); +} + +static int publish_xenbus(struct tpmfront_dev* dev) { + xenbus_transaction_t xbt; + int retry; + char* err; + /* Write the grant reference and event channel to xenstore */ +again: + if((err = xenbus_transaction_start(&xbt))) { + TPMFRONT_ERR("Unable to start xenbus transaction, error was %s\n", err); + free(err); + return -1; + } + + if((err = xenbus_printf(xbt, dev->nodename, "ring-ref", "%u", (unsigned int) dev->ring_ref))) { + TPMFRONT_ERR("Unable to write %s/ring-ref, error was %s\n", dev->nodename, err); + free(err); + goto abort_transaction; + } + + if((err = xenbus_printf(xbt, dev->nodename, "event-channel", "%u", (unsigned int) dev->evtchn))) { + TPMFRONT_ERR("Unable to write %s/event-channel, error was %s\n", dev->nodename, err); + free(err); + goto abort_transaction; + } + + if((err = xenbus_transaction_end(xbt, 0, &retry))) { + TPMFRONT_ERR("Unable to complete xenbus transaction, error was %s\n", err); + free(err); + return -1; + } + if(retry) { + goto again; + } + + return 0; +abort_transaction: + if((err = xenbus_transaction_end(xbt, 1, &retry))) { + free(err); + } + return -1; +} + +static int wait_for_backend_connect(xenbus_event_queue* events, char* path) +{ + int state; + + TPMFRONT_LOG("Waiting for backend connection..\n"); + /* Wait for the backend to connect */ + while(1) { + state = xenbus_read_integer(path); + if ( state < 0) + state = XenbusStateUnknown; + switch(state) { + /* Bad states, we quit with error */ + case XenbusStateUnknown: + case XenbusStateClosing: + case XenbusStateClosed: + TPMFRONT_ERR("Unable to connect to backend\n"); + return -1; + /* If backend is connected then break out of loop */ + case XenbusStateConnected: + TPMFRONT_LOG("Backend Connected\n"); + return 0; + default: + xenbus_wait_for_watch(events); + } + } + +} + +static int wait_for_backend_closed(xenbus_event_queue* events, char* path) +{ + int state; + + TPMFRONT_LOG("Waiting for backend to close..\n"); + while(1) { + state = xenbus_read_integer(path); + if ( state < 0) + state = XenbusStateUnknown; + switch(state) { + case XenbusStateUnknown: + TPMFRONT_ERR("Backend Unknown state, forcing shutdown\n"); + return -1; + case XenbusStateClosed: + TPMFRONT_LOG("Backend Closed\n"); + return 0; + default: + xenbus_wait_for_watch(events); + } + } + +} + +static int wait_for_backend_state_changed(struct tpmfront_dev* dev, XenbusState state) { + char* err; + int ret = 0; + xenbus_event_queue events = NULL; + char path[512]; + + snprintf(path, 512, "%s/state", dev->bepath); + /*Setup the watch to wait for the backend */ + if((err = xenbus_watch_path_token(XBT_NIL, path, path, &events))) { + TPMFRONT_ERR("Could not set a watch on %s, error was %s\n", path, err); + free(err); + return -1; + } + + /* Do the actual wait loop now */ + switch(state) { + case XenbusStateConnected: + ret = wait_for_backend_connect(&events, path); + break; + case XenbusStateClosed: + ret = wait_for_backend_closed(&events, path); + break; + default: + break; + } + + if((err = xenbus_unwatch_path_token(XBT_NIL, path, path))) { + TPMFRONT_ERR("Unable to unwatch %s, error was %s, ignoring..\n", path, err); + free(err); + } + return ret; +} + +static int tpmfront_connect(struct tpmfront_dev* dev) +{ + char* err; + /* Create shared page */ + dev->tx = (tpmif_tx_interface_t*) alloc_page(); + if(dev->tx == NULL) { + TPMFRONT_ERR("Unable to allocate page for shared memory\n"); + goto error; + } + memset(dev->tx, 0, PAGE_SIZE); + dev->ring_ref = gnttab_grant_access(dev->bedomid, virt_to_mfn(dev->tx), 0); + TPMFRONT_DEBUG("grant ref is %lu\n", (unsigned long) dev->ring_ref); + + /*Create event channel */ + if(evtchn_alloc_unbound(dev->bedomid, tpmfront_handler, dev, &dev->evtchn)) { + TPMFRONT_ERR("Unable to allocate event channel\n"); + goto error_postmap; + } + unmask_evtchn(dev->evtchn); + TPMFRONT_DEBUG("event channel is %lu\n", (unsigned long) dev->evtchn); + + /* Write the entries to xenstore */ + if(publish_xenbus(dev)) { + goto error_postevtchn; + } + + /* Change state to connected */ + dev->state = XenbusStateConnected; + + /* Tell the backend that we are ready */ + if((err = xenbus_printf(XBT_NIL, dev->nodename, "state", "%u", dev->state))) { + TPMFRONT_ERR("Unable to write to xenstore %s/state, value=%u", dev->nodename, XenbusStateConnected); + free(err); + goto error; + } + + return 0; +error_postevtchn: + mask_evtchn(dev->evtchn); + unbind_evtchn(dev->evtchn); +error_postmap: + gnttab_end_access(dev->ring_ref); + free_page(dev->tx); +error: + return -1; +} + +struct tpmfront_dev* init_tpmfront(const char* _nodename) +{ + struct tpmfront_dev* dev; + const char* nodename; + char path[512]; + char* value, *err; + unsigned long long ival; + int i; + + printk("============= Init TPM Front ================\n"); + + dev = malloc(sizeof(struct tpmfront_dev)); + memset(dev, 0, sizeof(struct tpmfront_dev)); + +#ifdef HAVE_LIBC + dev->fd = -1; +#endif + + nodename = _nodename ? _nodename : "device/vtpm/0"; + dev->nodename = strdup(nodename); + + init_waitqueue_head(&dev->waitq); + + /* Get backend domid */ + snprintf(path, 512, "%s/backend-id", dev->nodename); + if((err = xenbus_read(XBT_NIL, path, &value))) { + TPMFRONT_ERR("Unable to read %s during tpmfront initialization! error = %s\n", path, err); + free(err); + goto error; + } + if(sscanf(value, "%llu", &ival) != 1) { + TPMFRONT_ERR("%s has non-integer value (%s)\n", path, value); + free(value); + goto error; + } + free(value); + dev->bedomid = ival; + + /* Get backend xenstore path */ + snprintf(path, 512, "%s/backend", dev->nodename); + if((err = xenbus_read(XBT_NIL, path, &dev->bepath))) { + TPMFRONT_ERR("Unable to read %s during tpmfront initialization! error = %s\n", path, err); + free(err); + goto error; + } + + /* Create and publish grant reference and event channel */ + if (tpmfront_connect(dev)) { + goto error; + } + + /* Wait for backend to connect */ + if( wait_for_backend_state_changed(dev, XenbusStateConnected)) { + goto error; + } + + /* Allocate pages that will contain the messages */ + dev->pages = malloc(sizeof(void*) * TPMIF_TX_RING_SIZE); + if(dev->pages == NULL) { + goto error; + } + memset(dev->pages, 0, sizeof(void*) * TPMIF_TX_RING_SIZE); + for(i = 0; i < TPMIF_TX_RING_SIZE; ++i) { + dev->pages[i] = (void*)alloc_page(); + if(dev->pages[i] == NULL) { + goto error; + } + } + + TPMFRONT_LOG("Initialization Completed successfully\n"); + + return dev; + +error: + shutdown_tpmfront(dev); + return NULL; +} +void shutdown_tpmfront(struct tpmfront_dev* dev) +{ + char* err; + char path[512]; + int i; + tpmif_tx_request_t* tx; + if(dev == NULL) { + return; + } + TPMFRONT_LOG("Shutting down tpmfront\n"); + /* disconnect */ + if(dev->state == XenbusStateConnected) { + dev->state = XenbusStateClosing; + //FIXME: Transaction for this? + /* Tell backend we are closing */ + if((err = xenbus_printf(XBT_NIL, dev->nodename, "state", "%u", (unsigned int) dev->state))) { + free(err); + } + + /* Clean up xenstore entries */ + snprintf(path, 512, "%s/event-channel", dev->nodename); + if((err = xenbus_rm(XBT_NIL, path))) { + free(err); + } + snprintf(path, 512, "%s/ring-ref", dev->nodename); + if((err = xenbus_rm(XBT_NIL, path))) { + free(err); + } + + /* Tell backend we are closed */ + dev->state = XenbusStateClosed; + if((err = xenbus_printf(XBT_NIL, dev->nodename, "state", "%u", (unsigned int) dev->state))) { + TPMFRONT_ERR("Unable to write to %s, error was %s", dev->nodename, err); + free(err); + } + + /* Wait for the backend to close and unmap shared pages, ignore any errors */ + wait_for_backend_state_changed(dev, XenbusStateClosed); + + /* Cleanup any shared pages */ + if(dev->pages) { + for(i = 0; i < TPMIF_TX_RING_SIZE; ++i) { + if(dev->pages[i]) { + tx = &dev->tx->ring[i].req; + if(tx->ref != 0) { + gnttab_end_access(tx->ref); + } + free_page(dev->pages[i]); + } + } + free(dev->pages); + } + + /* Close event channel and unmap shared page */ + mask_evtchn(dev->evtchn); + unbind_evtchn(dev->evtchn); + gnttab_end_access(dev->ring_ref); + + free_page(dev->tx); + + } + + /* Cleanup memory usage */ + if(dev->respbuf) { + free(dev->respbuf); + } + if(dev->bepath) { + free(dev->bepath); + } + if(dev->nodename) { + free(dev->nodename); + } + free(dev); +} + +int tpmfront_send(struct tpmfront_dev* dev, const uint8_t* msg, size_t length) +{ + int i; + tpmif_tx_request_t* tx = NULL; + /* Error Checking */ + if(dev == NULL || dev->state != XenbusStateConnected) { + TPMFRONT_ERR("Tried to send message through disconnected frontend\n"); + return -1; + } + +#ifdef TPMFRONT_PRINT_DEBUG + TPMFRONT_DEBUG("Sending Msg to backend size=%u", (unsigned int) length); + for(i = 0; i < length; ++i) { + if(!(i % 30)) { + TPMFRONT_DEBUG_MORE("\n"); + } + TPMFRONT_DEBUG_MORE("%02X ", msg[i]); + } + TPMFRONT_DEBUG_MORE("\n"); +#endif + + /* Copy to shared pages now */ + for(i = 0; length > 0 && i < TPMIF_TX_RING_SIZE; ++i) { + /* Share the page */ + tx = &dev->tx->ring[i].req; + tx->unused = 0; + tx->addr = virt_to_mach(dev->pages[i]); + tx->ref = gnttab_grant_access(dev->bedomid, virt_to_mfn(dev->pages[i]), 0); + /* Copy the bits to the page */ + tx->size = length > PAGE_SIZE ? PAGE_SIZE : length; + memcpy(dev->pages[i], &msg[i * PAGE_SIZE], tx->size); + + /* Update counters */ + length -= tx->size; + } + dev->waiting = 1; + dev->resplen = 0; +#ifdef HAVE_LIBC + if(dev->fd >= 0) { + files[dev->fd].read = 0; + files[dev->fd].tpmfront.respgot = 0; + files[dev->fd].tpmfront.offset = 0; + } +#endif + notify_remote_via_evtchn(dev->evtchn); + return 0; +} +int tpmfront_recv(struct tpmfront_dev* dev, uint8_t** msg, size_t *length) +{ + tpmif_tx_request_t* tx; + int i; + if(dev == NULL || dev->state != XenbusStateConnected) { + TPMFRONT_ERR("Tried to receive message from disconnected frontend\n"); + return -1; + } + /*Wait for the response */ + wait_event(dev->waitq, (!dev->waiting)); + + /* Initialize */ + *msg = NULL; + *length = 0; + + /* special case, just quit */ + tx = &dev->tx->ring[0].req; + if(tx->size == 0 ) { + goto quit; + } + /* Get the total size */ + tx = &dev->tx->ring[0].req; + for(i = 0; i < TPMIF_TX_RING_SIZE && tx->size > 0; ++i) { + tx = &dev->tx->ring[i].req; + *length += tx->size; + } + /* Alloc the buffer */ + if(dev->respbuf) { + free(dev->respbuf); + } + *msg = dev->respbuf = malloc(*length); + dev->resplen = *length; + /* Copy the bits */ + tx = &dev->tx->ring[0].req; + for(i = 0; i < TPMIF_TX_RING_SIZE && tx->size > 0; ++i) { + tx = &dev->tx->ring[i].req; + memcpy(&(*msg)[i * PAGE_SIZE], dev->pages[i], tx->size); + gnttab_end_access(tx->ref); + tx->ref = 0; + } +#ifdef TPMFRONT_PRINT_DEBUG + TPMFRONT_DEBUG("Received response from backend size=%u", (unsigned int) *length); + for(i = 0; i < *length; ++i) { + if(!(i % 30)) { + TPMFRONT_DEBUG_MORE("\n"); + } + TPMFRONT_DEBUG_MORE("%02X ", (*msg)[i]); + } + TPMFRONT_DEBUG_MORE("\n"); +#endif +#ifdef HAVE_LIBC + if(dev->fd >= 0) { + files[dev->fd].tpmfront.respgot = 1; + } +#endif +quit: + return 0; +} + +int tpmfront_cmd(struct tpmfront_dev* dev, uint8_t* req, size_t reqlen, uint8_t** resp, size_t* resplen) +{ + int rc; + if((rc = tpmfront_send(dev, req, reqlen))) { + return rc; + } + if((rc = tpmfront_recv(dev, resp, resplen))) { + return rc; + } + + return 0; +} + +#ifdef HAVE_LIBC +#include +int tpmfront_open(struct tpmfront_dev* dev) +{ + /* Silently prevent multiple opens */ + if(dev->fd != -1) { + return dev->fd; + } + + dev->fd = alloc_fd(FTYPE_TPMFRONT); + printk("tpmfront_open(%s) -> %d\n", dev->nodename, dev->fd); + files[dev->fd].tpmfront.dev = dev; + files[dev->fd].tpmfront.offset = 0; + files[dev->fd].tpmfront.respgot = 0; + return dev->fd; +} + +int tpmfront_posix_write(int fd, const uint8_t* buf, size_t count) +{ + int rc; + struct tpmfront_dev* dev; + dev = files[fd].tpmfront.dev; + + if(count == 0) { + return 0; + } + + /* Return an error if we are already processing a command */ + if(dev->waiting) { + errno = EINPROGRESS; + return -1; + } + /* Send the command now */ + if((rc = tpmfront_send(dev, buf, count)) != 0) { + errno = EIO; + return -1; + } + return count; +} + +int tpmfront_posix_read(int fd, uint8_t* buf, size_t count) +{ + int rc; + uint8_t* dummybuf; + size_t dummysz; + struct tpmfront_dev* dev; + + dev = files[fd].tpmfront.dev; + + if(count == 0) { + return 0; + } + + /* get the response if we haven't already */ + if(files[dev->fd].tpmfront.respgot == 0) { + if ((rc = tpmfront_recv(dev, &dummybuf, &dummysz)) != 0) { + errno = EIO; + return -1; + } + } + + /* handle EOF case */ + if(files[dev->fd].tpmfront.offset >= dev->resplen) { + return 0; + } + + /* Compute the number of bytes and do the copy operation */ + if((rc = min(count, dev->resplen - files[dev->fd].tpmfront.offset)) != 0) { + memcpy(buf, dev->respbuf + files[dev->fd].tpmfront.offset, rc); + files[dev->fd].tpmfront.offset += rc; + } + + return rc; +} + +int tpmfront_posix_fstat(int fd, struct stat* buf) +{ + uint8_t* dummybuf; + size_t dummysz; + int rc; + struct tpmfront_dev* dev = files[fd].tpmfront.dev; + + /* If we have a response waiting, then read it now from the backend + * so we can get its length*/ + if(dev->waiting || (files[dev->fd].read == 1 && !files[dev->fd].tpmfront.respgot)) { + if ((rc = tpmfront_recv(dev, &dummybuf, &dummysz)) != 0) { + errno = EIO; + return -1; + } + } + + buf->st_mode = O_RDWR; + buf->st_uid = 0; + buf->st_gid = 0; + buf->st_size = dev->resplen; + buf->st_atime = buf->st_mtime = buf->st_ctime = time(NULL); + + return 0; +} + + +#endif -- 1.7.4.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 14:59:11 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:59:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3w7-0000w0-KX; Tue, 02 Oct 2012 14:59:03 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3w5-0000vk-Ul for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 14:59:02 +0000 Received: from [85.158.143.99:23063] by server-3.bemta-4.messagelabs.com id 9E/FA-10986-5310B605; Tue, 02 Oct 2012 14:59:01 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1349189940!25570616!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27232 invoked from network); 2 Oct 2012 14:59:00 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 14:59:00 -0000 X-IronPort-AV: E=Sophos;i="4.80,523,1344211200"; d="scan'208";a="14897081" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 14:58:56 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 15:58:56 +0100 Date: Tue, 2 Oct 2012 15:57:57 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Konrad Rzeszutek Wilk Message-ID: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org Subject: [Xen-devel] [PATCH] xen: mark xen_init_IRQ __init X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org xen_init_IRQ should be marked __init because it calls other functions marked __init and is always called by functions marked __init (on both x86 and arm). Also remove the unused EXPORT_SYMBOL_GPL(xen_init_IRQ). Both changes were introduced by "xen/arm: receive Xen events on ARM". Signed-off-by: Stefano Stabellini diff --git a/drivers/xen/events.c b/drivers/xen/events.c index 8672211..59e10a1 100644 --- a/drivers/xen/events.c +++ b/drivers/xen/events.c @@ -1802,7 +1802,7 @@ void xen_callback_vector(void) void xen_callback_vector(void) {} #endif -void xen_init_IRQ(void) +void __init xen_init_IRQ(void) { int i; @@ -1846,4 +1846,3 @@ void xen_init_IRQ(void) } #endif } -EXPORT_SYMBOL_GPL(xen_init_IRQ); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 14:59:11 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:59:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3w7-0000w0-KX; Tue, 02 Oct 2012 14:59:03 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3w5-0000vk-Ul for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 14:59:02 +0000 Received: from [85.158.143.99:23063] by server-3.bemta-4.messagelabs.com id 9E/FA-10986-5310B605; Tue, 02 Oct 2012 14:59:01 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1349189940!25570616!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27232 invoked from network); 2 Oct 2012 14:59:00 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 14:59:00 -0000 X-IronPort-AV: E=Sophos;i="4.80,523,1344211200"; d="scan'208";a="14897081" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 14:58:56 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 15:58:56 +0100 Date: Tue, 2 Oct 2012 15:57:57 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Konrad Rzeszutek Wilk Message-ID: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org Subject: [Xen-devel] [PATCH] xen: mark xen_init_IRQ __init X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org xen_init_IRQ should be marked __init because it calls other functions marked __init and is always called by functions marked __init (on both x86 and arm). Also remove the unused EXPORT_SYMBOL_GPL(xen_init_IRQ). Both changes were introduced by "xen/arm: receive Xen events on ARM". Signed-off-by: Stefano Stabellini diff --git a/drivers/xen/events.c b/drivers/xen/events.c index 8672211..59e10a1 100644 --- a/drivers/xen/events.c +++ b/drivers/xen/events.c @@ -1802,7 +1802,7 @@ void xen_callback_vector(void) void xen_callback_vector(void) {} #endif -void xen_init_IRQ(void) +void __init xen_init_IRQ(void) { int i; @@ -1846,4 +1846,3 @@ void xen_init_IRQ(void) } #endif } -EXPORT_SYMBOL_GPL(xen_init_IRQ); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 14:59:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:59:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3wf-00012w-29; Tue, 02 Oct 2012 14:59:37 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3we-00012f-CZ for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:59:36 +0000 Received: from [85.158.139.83:23965] by server-9.bemta-5.messagelabs.com id A0/0C-14846-7510B605; Tue, 02 Oct 2012 14:59:35 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1349189974!29197848!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2673 invoked from network); 2 Oct 2012 14:59:35 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 14:59:35 -0000 X-IronPort-AV: E=Sophos;i="4.80,523,1344211200"; d="scan'208";a="14897102" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 14:59:34 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 15:59:34 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TJ3wc-0001l1-DQ; Tue, 02 Oct 2012 14:59:34 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TJ3wc-00062e-8q; Tue, 02 Oct 2012 15:59:34 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20587.342.66210.677204@mariner.uk.xensource.com> Date: Tue, 2 Oct 2012 15:59:34 +0100 To: Newsgroups: chiark.mail.xen.devel In-Reply-To: <5065B82B.8080003@oracle.com> References: <505C3647.1030003@oracle.com> <20120921143430.GA3522@phenom.dumpdata.com> <5062C16A.1020306@oracle.com> <20120926123534.GF7356@phenom.dumpdata.com> <5063EAFB.1070307@oracle.com> <20120927115918.GE8832@phenom.dumpdata.com> <50657D4B.9040303@oracle.com> <20120928140109.GA7483@localhost.localdomain> <20581.45245.846208.289785@mariner.uk.xensource.com> <5065B82B.8080003@oracle.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Konrad Rzeszutek Wilk , Dan Magenheimer , Konrad Rzeszutek Wilk , Feng Jin , xen-devel Subject: Re: [Xen-devel] Is: Contention in block script when doing guest saving. Was:Re: an issue with 'xm save' X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Zhenzhong Duan writes ("Re: [Xen-devel] Is: Contention in block script when doing guest saving. Was:Re: an issue with 'xm save'"): > Attachment is part of xen-hotplug.log that will show the spin. > Original file is nearly 7G big. I fetch first 1000 lines. Thanks. This is quite mystifying to me. Picking a representative example, and translating it to what I think the syscalls would be: > + eval 'exec 200>>/var/run/xen-hotplug/block' > ++ exec fd = open("/var/run/xen-hotplug/block", O_WRONLY|O_APPEND|O_CREAT, 0666); dup2(fd, 200); close(fd); > + flock -x 200 flock(200, LOCK_EX); > ++ perl -e ' > open STDIN, "<&200" or die $!; dup2(200, 0); > my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum; fstat(0, &stdin_stat); > my $file_inum = (stat $ARGV[0])[1]; stat("/var/run/xen-hotplug/block", &file_stat); > print "y\n" if $fd_inum eq $file_inum; if (stdin_stat.st_ino == file_stat.st_ino) puts("y"); > ' /var/run/xen-hotplug/block > + rightfile= And here we see that perl didn't print "y" so the two files must be different. Let's try something else: can you strace it ? That is, get it to the point where it's spinning, find the pid of the relevant shell process, and strace -f -vvs500 -ooutput.strace PID where PID is the pid in question ? Let that run for a fraction of a second and then ^C it. The output may shed some light. Thanks, Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 14:59:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 14:59:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3wf-00012w-29; Tue, 02 Oct 2012 14:59:37 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3we-00012f-CZ for xen-devel@lists.xen.org; Tue, 02 Oct 2012 14:59:36 +0000 Received: from [85.158.139.83:23965] by server-9.bemta-5.messagelabs.com id A0/0C-14846-7510B605; Tue, 02 Oct 2012 14:59:35 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1349189974!29197848!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2673 invoked from network); 2 Oct 2012 14:59:35 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 14:59:35 -0000 X-IronPort-AV: E=Sophos;i="4.80,523,1344211200"; d="scan'208";a="14897102" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 14:59:34 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 15:59:34 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TJ3wc-0001l1-DQ; Tue, 02 Oct 2012 14:59:34 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TJ3wc-00062e-8q; Tue, 02 Oct 2012 15:59:34 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20587.342.66210.677204@mariner.uk.xensource.com> Date: Tue, 2 Oct 2012 15:59:34 +0100 To: Newsgroups: chiark.mail.xen.devel In-Reply-To: <5065B82B.8080003@oracle.com> References: <505C3647.1030003@oracle.com> <20120921143430.GA3522@phenom.dumpdata.com> <5062C16A.1020306@oracle.com> <20120926123534.GF7356@phenom.dumpdata.com> <5063EAFB.1070307@oracle.com> <20120927115918.GE8832@phenom.dumpdata.com> <50657D4B.9040303@oracle.com> <20120928140109.GA7483@localhost.localdomain> <20581.45245.846208.289785@mariner.uk.xensource.com> <5065B82B.8080003@oracle.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Konrad Rzeszutek Wilk , Dan Magenheimer , Konrad Rzeszutek Wilk , Feng Jin , xen-devel Subject: Re: [Xen-devel] Is: Contention in block script when doing guest saving. Was:Re: an issue with 'xm save' X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Zhenzhong Duan writes ("Re: [Xen-devel] Is: Contention in block script when doing guest saving. Was:Re: an issue with 'xm save'"): > Attachment is part of xen-hotplug.log that will show the spin. > Original file is nearly 7G big. I fetch first 1000 lines. Thanks. This is quite mystifying to me. Picking a representative example, and translating it to what I think the syscalls would be: > + eval 'exec 200>>/var/run/xen-hotplug/block' > ++ exec fd = open("/var/run/xen-hotplug/block", O_WRONLY|O_APPEND|O_CREAT, 0666); dup2(fd, 200); close(fd); > + flock -x 200 flock(200, LOCK_EX); > ++ perl -e ' > open STDIN, "<&200" or die $!; dup2(200, 0); > my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum; fstat(0, &stdin_stat); > my $file_inum = (stat $ARGV[0])[1]; stat("/var/run/xen-hotplug/block", &file_stat); > print "y\n" if $fd_inum eq $file_inum; if (stdin_stat.st_ino == file_stat.st_ino) puts("y"); > ' /var/run/xen-hotplug/block > + rightfile= And here we see that perl didn't print "y" so the two files must be different. Let's try something else: can you strace it ? That is, get it to the point where it's spinning, find the pid of the relevant shell process, and strace -f -vvs500 -ooutput.strace PID where PID is the pid in question ? Let that run for a fraction of a second and then ^C it. The output may shed some light. Thanks, Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 15:01:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 15:01:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3xx-0001HY-Im; Tue, 02 Oct 2012 15:00:57 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with smtp (Exim 4.72) (envelope-from ) id 1TJ3xw-0001Gl-CG for xen-devel@lists.xen.org; Tue, 02 Oct 2012 15:00:56 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1349190010!6203490!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12394 invoked from network); 2 Oct 2012 15:00:10 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-15.tower-27.messagelabs.com with SMTP; 2 Oct 2012 15:00:10 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 02 Oct 2012 16:00:10 +0100 Message-Id: <506B1D97020000780009F22A@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Tue, 02 Oct 2012 16:00:07 +0100 From: "Jan Beulich" To: "xen-devel" Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part35040367.1__=" Cc: xiantao.zhang@intel.com Subject: [Xen-devel] [PATCH] IOMMU: remove vendor specific bits from generic code X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part35040367.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline - names of functions used independent of vendor should not have vendor specific names - vendor specific declarations should not live inn generic headers - other vendor specific items should not be used in generic code Signed-off-by: Jan Beulich -- Note that this will only apply cleanly on top of "VT-d: drop bogus checks", sent out a few minutes ago. --- a/xen/arch/x86/domctl.c +++ b/xen/arch/x86/domctl.c @@ -776,7 +776,7 @@ long arch_do_domctl( if ( iommu_enabled ) { spin_lock(&pcidevs_lock); - ret =3D pt_irq_create_bind_vtd(d, bind); + ret =3D pt_irq_create_bind(d, bind); spin_unlock(&pcidevs_lock); } if ( ret < 0 ) @@ -806,7 +806,7 @@ long arch_do_domctl( if ( iommu_enabled ) { spin_lock(&pcidevs_lock); - ret =3D pt_irq_destroy_bind_vtd(d, bind); + ret =3D pt_irq_destroy_bind(d, bind); spin_unlock(&pcidevs_lock); } if ( ret < 0 ) --- a/xen/drivers/passthrough/io.c +++ b/xen/drivers/passthrough/io.c @@ -95,7 +95,7 @@ void free_hvm_irq_dpci(struct hvm_irq_dp xfree(dpci); } =20 -int pt_irq_create_bind_vtd( +int pt_irq_create_bind( struct domain *d, xen_domctl_bind_pt_irq_t *pt_irq_bind) { struct hvm_irq_dpci *hvm_irq_dpci =3D NULL; @@ -277,14 +277,14 @@ int pt_irq_create_bind_vtd( spin_unlock(&d->event_lock); =20 if ( iommu_verbose ) - dprintk(VTDPREFIX, + dprintk(XENLOG_G_INFO, "d%d: bind: m_gsi=3D%u g_gsi=3D%u device=3D%u = intx=3D%u\n", d->domain_id, pirq, guest_gsi, device, intx); } return 0; } =20 -int pt_irq_destroy_bind_vtd( +int pt_irq_destroy_bind( struct domain *d, xen_domctl_bind_pt_irq_t *pt_irq_bind) { struct hvm_irq_dpci *hvm_irq_dpci =3D NULL; @@ -302,7 +302,7 @@ int pt_irq_destroy_bind_vtd( link =3D hvm_pci_intx_link(device, intx); =20 if ( iommu_verbose ) - dprintk(VTDPREFIX, + dprintk(XENLOG_G_INFO, "d%d: unbind: m_gsi=3D%u g_gsi=3D%u device=3D%u intx=3D%u\= n", d->domain_id, machine_gsi, guest_gsi, device, intx); =20 @@ -360,7 +360,7 @@ int pt_irq_destroy_bind_vtd( spin_unlock(&d->event_lock); =20 if ( iommu_verbose ) - dprintk(VTDPREFIX, + dprintk(XENLOG_G_INFO, "d%d unmap: m_irq=3D%u device=3D%u intx=3D%u\n", d->domain_id, machine_gsi, device, intx); =20 --- a/xen/drivers/passthrough/iommu.c +++ b/xen/drivers/passthrough/iommu.c @@ -364,7 +364,7 @@ int deassign_device(struct domain *d, u1 =20 if ( pdev->domain !=3D d ) { - dprintk(XENLOG_ERR VTDPREFIX, + dprintk(XENLOG_G_ERR, "d%d: deassign a device not owned\n", d->domain_id); return -EINVAL; } @@ -372,8 +372,8 @@ int deassign_device(struct domain *d, u1 ret =3D hd->platform_ops->reassign_device(d, dom0, seg, bus, devfn); if ( ret ) { - dprintk(XENLOG_ERR VTDPREFIX, - "d%d: Deassign device (%04x:%02x:%02x.%u) failed!\n", + dprintk(XENLOG_G_ERR, + "d%d: deassign device (%04x:%02x:%02x.%u) failed\n", d->domain_id, seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));= return ret; } --- a/xen/drivers/passthrough/vtd/extern.h +++ b/xen/drivers/passthrough/vtd/extern.h @@ -24,6 +24,8 @@ #include "dmar.h" #include =20 +#define VTDPREFIX "[VT-D]" + extern bool_t rwbf_quirk; =20 void print_iommu_regs(struct acpi_drhd_unit *drhd); @@ -79,6 +81,15 @@ int domain_context_mapping_one(struct do int domain_context_unmap_one(struct domain *domain, struct iommu *iommu, u8 bus, u8 devfn); =20 +unsigned int io_apic_read_remap_rte(unsigned int apic, unsigned int reg); +void io_apic_write_remap_rte(unsigned int apic, + unsigned int reg, unsigned int value); + +struct msi_desc; +struct msi_msg; +void msi_msg_read_remap_rte(struct msi_desc *, struct msi_msg *); +void msi_msg_write_remap_rte(struct msi_desc *, struct msi_msg *); + int is_igd_vt_enabled_quirk(void); void platform_quirks_init(void); void vtd_ops_preamble_quirk(struct iommu* iommu); --- a/xen/drivers/passthrough/vtd/iommu.h +++ b/xen/drivers/passthrough/vtd/iommu.h @@ -510,6 +510,22 @@ struct intel_iommu { struct acpi_drhd_unit *drhd; }; =20 +struct iommu { + struct list_head list; + void __iomem *reg; /* Pointer to hardware regs, virtual addr */ + u32 index; /* Sequence number of iommu */ + u32 nr_pt_levels; + u64 cap; + u64 ecap; + spinlock_t lock; /* protect context, domain ids */ + spinlock_t register_lock; /* protect iommu register handling */ + u64 root_maddr; /* root entry machine address */ + int irq; + struct intel_iommu *intel; + unsigned long *domid_bitmap; /* domain id bitmap */ + u16 *domid_map; /* domain id mapping array */ +}; + static inline struct qi_ctrl *iommu_qi_ctrl(struct iommu *iommu) { return iommu ? &iommu->intel->qi_ctrl : NULL; --- a/xen/include/xen/iommu.h +++ b/xen/include/xen/iommu.h @@ -48,22 +48,6 @@ extern struct rangeset *mmio_ro_ranges; #define PAGE_MASK_4K (((u64)-1) << PAGE_SHIFT_4K) #define PAGE_ALIGN_4K(addr) (((addr) + PAGE_SIZE_4K - 1) & PAGE_MASK_4K) =20 -struct iommu { - struct list_head list; - void __iomem *reg; /* Pointer to hardware regs, virtual addr */ - u32 index; /* Sequence number of iommu */ - u32 nr_pt_levels; - u64 cap; - u64 ecap; - spinlock_t lock; /* protect context, domain ids */ - spinlock_t register_lock; /* protect iommu register handling */ - u64 root_maddr; /* root entry machine address */ - int irq; - struct intel_iommu *intel; - unsigned long *domid_bitmap; /* domain id bitmap */ - u16 *domid_map; /* domain id mapping array */ -}; - int iommu_setup(void); int iommu_supports_eim(void); int iommu_enable_x2apic_IR(void); @@ -94,25 +78,18 @@ void pt_pci_init(void); struct pirq; int hvm_do_IRQ_dpci(struct domain *, struct pirq *); int dpci_ioport_intercept(ioreq_t *p); -int pt_irq_create_bind_vtd(struct domain *d, - xen_domctl_bind_pt_irq_t *pt_irq_bind); -int pt_irq_destroy_bind_vtd(struct domain *d, - xen_domctl_bind_pt_irq_t *pt_irq_bind); -unsigned int io_apic_read_remap_rte(unsigned int apic, unsigned int reg); -void io_apic_write_remap_rte(unsigned int apic, - unsigned int reg, unsigned int value); +int pt_irq_create_bind(struct domain *, xen_domctl_bind_pt_irq_t *); +int pt_irq_destroy_bind(struct domain *, xen_domctl_bind_pt_irq_t *); =20 -struct msi_desc; -struct msi_msg; -void msi_msg_read_remap_rte(struct msi_desc *msi_desc, struct msi_msg = *msg); -void msi_msg_write_remap_rte(struct msi_desc *msi_desc, struct msi_msg = *msg); void hvm_dpci_isairq_eoi(struct domain *d, unsigned int isairq); struct hvm_irq_dpci *domain_get_irq_dpci(const struct domain *); void free_hvm_irq_dpci(struct hvm_irq_dpci *dpci); bool_t pt_irq_need_timer(uint32_t flags); =20 #define PT_IRQ_TIME_OUT MILLISECS(8) -#define VTDPREFIX "[VT-D]" + +struct msi_desc; +struct msi_msg; =20 struct iommu_ops { int (*init)(struct domain *d); --=__Part35040367.1__= Content-Type: text/plain; name="IOMMU-generalize.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="IOMMU-generalize.patch" IOMMU: remove vendor specific bits from generic code=0A=0A- names of = functions used independent of vendor should not have vendor=0A specific = names=0A- vendor specific declarations should not live inn generic = headers=0A- other vendor specific items should not be used in generic = code=0A=0ASigned-off-by: Jan Beulich =0A--=0ANote that = this will only apply cleanly on top of "VT-d: drop bogus=0Achecks", sent = out a few minutes ago.=0A=0A--- a/xen/arch/x86/domctl.c=0A+++ b/xen/arch/x8= 6/domctl.c=0A@@ -776,7 +776,7 @@ long arch_do_domctl(=0A if ( = iommu_enabled )=0A {=0A spin_lock(&pcidevs_lock);=0A- = ret =3D pt_irq_create_bind_vtd(d, bind);=0A+ ret =3D = pt_irq_create_bind(d, bind);=0A spin_unlock(&pcidevs_lock);=0A = }=0A if ( ret < 0 )=0A@@ -806,7 +806,7 @@ long arch_do_domc= tl(=0A if ( iommu_enabled )=0A {=0A spin_lock(&= pcidevs_lock);=0A- ret =3D pt_irq_destroy_bind_vtd(d, bind);=0A+= ret =3D pt_irq_destroy_bind(d, bind);=0A spin_unloc= k(&pcidevs_lock);=0A }=0A if ( ret < 0 )=0A--- a/xen/driver= s/passthrough/io.c=0A+++ b/xen/drivers/passthrough/io.c=0A@@ -95,7 +95,7 = @@ void free_hvm_irq_dpci(struct hvm_irq_dp=0A xfree(dpci);=0A }=0A = =0A-int pt_irq_create_bind_vtd(=0A+int pt_irq_create_bind(=0A struct = domain *d, xen_domctl_bind_pt_irq_t *pt_irq_bind)=0A {=0A struct = hvm_irq_dpci *hvm_irq_dpci =3D NULL;=0A@@ -277,14 +277,14 @@ int pt_irq_cre= ate_bind_vtd(=0A spin_unlock(&d->event_lock);=0A =0A if ( = iommu_verbose )=0A- dprintk(VTDPREFIX,=0A+ dprintk(XE= NLOG_G_INFO,=0A "d%d: bind: m_gsi=3D%u g_gsi=3D%u = device=3D%u intx=3D%u\n",=0A d->domain_id, pirq, = guest_gsi, device, intx);=0A }=0A return 0;=0A }=0A =0A-int = pt_irq_destroy_bind_vtd(=0A+int pt_irq_destroy_bind(=0A struct domain = *d, xen_domctl_bind_pt_irq_t *pt_irq_bind)=0A {=0A struct hvm_irq_dpci = *hvm_irq_dpci =3D NULL;=0A@@ -302,7 +302,7 @@ int pt_irq_destroy_bind_vtd(= =0A link =3D hvm_pci_intx_link(device, intx);=0A =0A if ( = iommu_verbose )=0A- dprintk(VTDPREFIX,=0A+ dprintk(XENLOG_G_I= NFO,=0A "d%d: unbind: m_gsi=3D%u g_gsi=3D%u device=3D%u = intx=3D%u\n",=0A d->domain_id, machine_gsi, guest_gsi, = device, intx);=0A =0A@@ -360,7 +360,7 @@ int pt_irq_destroy_bind_vtd(=0A = spin_unlock(&d->event_lock);=0A =0A if ( iommu_verbose )=0A- = dprintk(VTDPREFIX,=0A+ dprintk(XENLOG_G_INFO,=0A = "d%d unmap: m_irq=3D%u device=3D%u intx=3D%u\n",=0A = d->domain_id, machine_gsi, device, intx);=0A =0A--- a/xen/drivers/passthrou= gh/iommu.c=0A+++ b/xen/drivers/passthrough/iommu.c=0A@@ -364,7 +364,7 @@ = int deassign_device(struct domain *d, u1=0A =0A if ( pdev->domain !=3D = d )=0A {=0A- dprintk(XENLOG_ERR VTDPREFIX,=0A+ dprintk(XE= NLOG_G_ERR,=0A "d%d: deassign a device not owned\n", = d->domain_id);=0A return -EINVAL;=0A }=0A@@ -372,8 +372,8 @@ = int deassign_device(struct domain *d, u1=0A ret =3D hd->platform_ops->r= eassign_device(d, dom0, seg, bus, devfn);=0A if ( ret )=0A {=0A- = dprintk(XENLOG_ERR VTDPREFIX,=0A- "d%d: Deassign = device (%04x:%02x:%02x.%u) failed!\n",=0A+ dprintk(XENLOG_G_ERR,=0A+= "d%d: deassign device (%04x:%02x:%02x.%u) failed\n",=0A = d->domain_id, seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));=0A = return ret;=0A }=0A--- a/xen/drivers/passthrough/vtd/extern.h= =0A+++ b/xen/drivers/passthrough/vtd/extern.h=0A@@ -24,6 +24,8 @@=0A = #include "dmar.h"=0A #include =0A =0A+#define VTDPREFIX = "[VT-D]"=0A+=0A extern bool_t rwbf_quirk;=0A =0A void print_iommu_regs(stru= ct acpi_drhd_unit *drhd);=0A@@ -79,6 +81,15 @@ int domain_context_mapping_o= ne(struct do=0A int domain_context_unmap_one(struct domain *domain, struct = iommu *iommu,=0A u8 bus, u8 devfn);=0A = =0A+unsigned int io_apic_read_remap_rte(unsigned int apic, unsigned int = reg);=0A+void io_apic_write_remap_rte(unsigned int apic,=0A+ = unsigned int reg, unsigned int value);=0A+=0A+struct = msi_desc;=0A+struct msi_msg;=0A+void msi_msg_read_remap_rte(struct = msi_desc *, struct msi_msg *);=0A+void msi_msg_write_remap_rte(struct = msi_desc *, struct msi_msg *);=0A+=0A int is_igd_vt_enabled_quirk(void);=0A= void platform_quirks_init(void);=0A void vtd_ops_preamble_quirk(struct = iommu* iommu);=0A--- a/xen/drivers/passthrough/vtd/iommu.h=0A+++ b/xen/driv= ers/passthrough/vtd/iommu.h=0A@@ -510,6 +510,22 @@ struct intel_iommu {=0A = struct acpi_drhd_unit *drhd;=0A };=0A =0A+struct iommu {=0A+ struct = list_head list;=0A+ void __iomem *reg; /* Pointer to hardware regs, = virtual addr */=0A+ u32 index; /* Sequence number of iommu = */=0A+ u32 nr_pt_levels;=0A+ u64 cap;=0A+ u64 ecap;=0A+ = spinlock_t lock; /* protect context, domain ids */=0A+ spinlock_t = register_lock; /* protect iommu register handling */=0A+ u64 root_maddr;= /* root entry machine address */=0A+ int irq;=0A+ struct intel_iommu= *intel;=0A+ unsigned long *domid_bitmap; /* domain id bitmap */=0A+ = u16 *domid_map; /* domain id mapping array */=0A+};=0A+=0A = static inline struct qi_ctrl *iommu_qi_ctrl(struct iommu *iommu)=0A {=0A = return iommu ? &iommu->intel->qi_ctrl : NULL;=0A--- a/xen/include/xen/iom= mu.h=0A+++ b/xen/include/xen/iommu.h=0A@@ -48,22 +48,6 @@ extern struct = rangeset *mmio_ro_ranges;=0A #define PAGE_MASK_4K (((u64)-1) << = PAGE_SHIFT_4K)=0A #define PAGE_ALIGN_4K(addr) (((addr) + PAGE_SIZE_4K - 1) = & PAGE_MASK_4K)=0A =0A-struct iommu {=0A- struct list_head list;=0A- = void __iomem *reg; /* Pointer to hardware regs, virtual addr */=0A- u32 = index; /* Sequence number of iommu */=0A- u32 nr_pt_levels;=0A- = u64 cap;=0A- u64 ecap;=0A- spinlock_t lock; /* protect context, = domain ids */=0A- spinlock_t register_lock; /* protect iommu register = handling */=0A- u64 root_maddr; /* root entry machine address */=0A- = int irq;=0A- struct intel_iommu *intel;=0A- unsigned long *domid_bitm= ap; /* domain id bitmap */=0A- u16 *domid_map; /* domain = id mapping array */=0A-};=0A-=0A int iommu_setup(void);=0A int iommu_suppor= ts_eim(void);=0A int iommu_enable_x2apic_IR(void);=0A@@ -94,25 +78,18 @@ = void pt_pci_init(void);=0A struct pirq;=0A int hvm_do_IRQ_dpci(struct = domain *, struct pirq *);=0A int dpci_ioport_intercept(ioreq_t *p);=0A-int = pt_irq_create_bind_vtd(struct domain *d,=0A- = xen_domctl_bind_pt_irq_t *pt_irq_bind);=0A-int pt_irq_destroy_bind_vtd(stru= ct domain *d,=0A- xen_domctl_bind_pt_irq_t = *pt_irq_bind);=0A-unsigned int io_apic_read_remap_rte(unsigned int apic, = unsigned int reg);=0A-void io_apic_write_remap_rte(unsigned int apic,=0A- = unsigned int reg, unsigned int value);=0A+int = pt_irq_create_bind(struct domain *, xen_domctl_bind_pt_irq_t *);=0A+int = pt_irq_destroy_bind(struct domain *, xen_domctl_bind_pt_irq_t *);=0A = =0A-struct msi_desc;=0A-struct msi_msg;=0A-void msi_msg_read_remap_rte(stru= ct msi_desc *msi_desc, struct msi_msg *msg);=0A-void msi_msg_write_remap_rt= e(struct msi_desc *msi_desc, struct msi_msg *msg);=0A void hvm_dpci_isairq_= eoi(struct domain *d, unsigned int isairq);=0A struct hvm_irq_dpci = *domain_get_irq_dpci(const struct domain *);=0A void free_hvm_irq_dpci(stru= ct hvm_irq_dpci *dpci);=0A bool_t pt_irq_need_timer(uint32_t flags);=0A = =0A #define PT_IRQ_TIME_OUT MILLISECS(8)=0A-#define VTDPREFIX "[VT-D]"=0A+= =0A+struct msi_desc;=0A+struct msi_msg;=0A =0A struct iommu_ops {=0A = int (*init)(struct domain *d);=0A --=__Part35040367.1__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --=__Part35040367.1__=-- From xen-devel-bounces@lists.xen.org Tue Oct 02 15:01:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 15:01:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3xx-0001HY-Im; Tue, 02 Oct 2012 15:00:57 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with smtp (Exim 4.72) (envelope-from ) id 1TJ3xw-0001Gl-CG for xen-devel@lists.xen.org; Tue, 02 Oct 2012 15:00:56 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1349190010!6203490!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12394 invoked from network); 2 Oct 2012 15:00:10 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-15.tower-27.messagelabs.com with SMTP; 2 Oct 2012 15:00:10 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 02 Oct 2012 16:00:10 +0100 Message-Id: <506B1D97020000780009F22A@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Tue, 02 Oct 2012 16:00:07 +0100 From: "Jan Beulich" To: "xen-devel" Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part35040367.1__=" Cc: xiantao.zhang@intel.com Subject: [Xen-devel] [PATCH] IOMMU: remove vendor specific bits from generic code X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part35040367.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline - names of functions used independent of vendor should not have vendor specific names - vendor specific declarations should not live inn generic headers - other vendor specific items should not be used in generic code Signed-off-by: Jan Beulich -- Note that this will only apply cleanly on top of "VT-d: drop bogus checks", sent out a few minutes ago. --- a/xen/arch/x86/domctl.c +++ b/xen/arch/x86/domctl.c @@ -776,7 +776,7 @@ long arch_do_domctl( if ( iommu_enabled ) { spin_lock(&pcidevs_lock); - ret =3D pt_irq_create_bind_vtd(d, bind); + ret =3D pt_irq_create_bind(d, bind); spin_unlock(&pcidevs_lock); } if ( ret < 0 ) @@ -806,7 +806,7 @@ long arch_do_domctl( if ( iommu_enabled ) { spin_lock(&pcidevs_lock); - ret =3D pt_irq_destroy_bind_vtd(d, bind); + ret =3D pt_irq_destroy_bind(d, bind); spin_unlock(&pcidevs_lock); } if ( ret < 0 ) --- a/xen/drivers/passthrough/io.c +++ b/xen/drivers/passthrough/io.c @@ -95,7 +95,7 @@ void free_hvm_irq_dpci(struct hvm_irq_dp xfree(dpci); } =20 -int pt_irq_create_bind_vtd( +int pt_irq_create_bind( struct domain *d, xen_domctl_bind_pt_irq_t *pt_irq_bind) { struct hvm_irq_dpci *hvm_irq_dpci =3D NULL; @@ -277,14 +277,14 @@ int pt_irq_create_bind_vtd( spin_unlock(&d->event_lock); =20 if ( iommu_verbose ) - dprintk(VTDPREFIX, + dprintk(XENLOG_G_INFO, "d%d: bind: m_gsi=3D%u g_gsi=3D%u device=3D%u = intx=3D%u\n", d->domain_id, pirq, guest_gsi, device, intx); } return 0; } =20 -int pt_irq_destroy_bind_vtd( +int pt_irq_destroy_bind( struct domain *d, xen_domctl_bind_pt_irq_t *pt_irq_bind) { struct hvm_irq_dpci *hvm_irq_dpci =3D NULL; @@ -302,7 +302,7 @@ int pt_irq_destroy_bind_vtd( link =3D hvm_pci_intx_link(device, intx); =20 if ( iommu_verbose ) - dprintk(VTDPREFIX, + dprintk(XENLOG_G_INFO, "d%d: unbind: m_gsi=3D%u g_gsi=3D%u device=3D%u intx=3D%u\= n", d->domain_id, machine_gsi, guest_gsi, device, intx); =20 @@ -360,7 +360,7 @@ int pt_irq_destroy_bind_vtd( spin_unlock(&d->event_lock); =20 if ( iommu_verbose ) - dprintk(VTDPREFIX, + dprintk(XENLOG_G_INFO, "d%d unmap: m_irq=3D%u device=3D%u intx=3D%u\n", d->domain_id, machine_gsi, device, intx); =20 --- a/xen/drivers/passthrough/iommu.c +++ b/xen/drivers/passthrough/iommu.c @@ -364,7 +364,7 @@ int deassign_device(struct domain *d, u1 =20 if ( pdev->domain !=3D d ) { - dprintk(XENLOG_ERR VTDPREFIX, + dprintk(XENLOG_G_ERR, "d%d: deassign a device not owned\n", d->domain_id); return -EINVAL; } @@ -372,8 +372,8 @@ int deassign_device(struct domain *d, u1 ret =3D hd->platform_ops->reassign_device(d, dom0, seg, bus, devfn); if ( ret ) { - dprintk(XENLOG_ERR VTDPREFIX, - "d%d: Deassign device (%04x:%02x:%02x.%u) failed!\n", + dprintk(XENLOG_G_ERR, + "d%d: deassign device (%04x:%02x:%02x.%u) failed\n", d->domain_id, seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));= return ret; } --- a/xen/drivers/passthrough/vtd/extern.h +++ b/xen/drivers/passthrough/vtd/extern.h @@ -24,6 +24,8 @@ #include "dmar.h" #include =20 +#define VTDPREFIX "[VT-D]" + extern bool_t rwbf_quirk; =20 void print_iommu_regs(struct acpi_drhd_unit *drhd); @@ -79,6 +81,15 @@ int domain_context_mapping_one(struct do int domain_context_unmap_one(struct domain *domain, struct iommu *iommu, u8 bus, u8 devfn); =20 +unsigned int io_apic_read_remap_rte(unsigned int apic, unsigned int reg); +void io_apic_write_remap_rte(unsigned int apic, + unsigned int reg, unsigned int value); + +struct msi_desc; +struct msi_msg; +void msi_msg_read_remap_rte(struct msi_desc *, struct msi_msg *); +void msi_msg_write_remap_rte(struct msi_desc *, struct msi_msg *); + int is_igd_vt_enabled_quirk(void); void platform_quirks_init(void); void vtd_ops_preamble_quirk(struct iommu* iommu); --- a/xen/drivers/passthrough/vtd/iommu.h +++ b/xen/drivers/passthrough/vtd/iommu.h @@ -510,6 +510,22 @@ struct intel_iommu { struct acpi_drhd_unit *drhd; }; =20 +struct iommu { + struct list_head list; + void __iomem *reg; /* Pointer to hardware regs, virtual addr */ + u32 index; /* Sequence number of iommu */ + u32 nr_pt_levels; + u64 cap; + u64 ecap; + spinlock_t lock; /* protect context, domain ids */ + spinlock_t register_lock; /* protect iommu register handling */ + u64 root_maddr; /* root entry machine address */ + int irq; + struct intel_iommu *intel; + unsigned long *domid_bitmap; /* domain id bitmap */ + u16 *domid_map; /* domain id mapping array */ +}; + static inline struct qi_ctrl *iommu_qi_ctrl(struct iommu *iommu) { return iommu ? &iommu->intel->qi_ctrl : NULL; --- a/xen/include/xen/iommu.h +++ b/xen/include/xen/iommu.h @@ -48,22 +48,6 @@ extern struct rangeset *mmio_ro_ranges; #define PAGE_MASK_4K (((u64)-1) << PAGE_SHIFT_4K) #define PAGE_ALIGN_4K(addr) (((addr) + PAGE_SIZE_4K - 1) & PAGE_MASK_4K) =20 -struct iommu { - struct list_head list; - void __iomem *reg; /* Pointer to hardware regs, virtual addr */ - u32 index; /* Sequence number of iommu */ - u32 nr_pt_levels; - u64 cap; - u64 ecap; - spinlock_t lock; /* protect context, domain ids */ - spinlock_t register_lock; /* protect iommu register handling */ - u64 root_maddr; /* root entry machine address */ - int irq; - struct intel_iommu *intel; - unsigned long *domid_bitmap; /* domain id bitmap */ - u16 *domid_map; /* domain id mapping array */ -}; - int iommu_setup(void); int iommu_supports_eim(void); int iommu_enable_x2apic_IR(void); @@ -94,25 +78,18 @@ void pt_pci_init(void); struct pirq; int hvm_do_IRQ_dpci(struct domain *, struct pirq *); int dpci_ioport_intercept(ioreq_t *p); -int pt_irq_create_bind_vtd(struct domain *d, - xen_domctl_bind_pt_irq_t *pt_irq_bind); -int pt_irq_destroy_bind_vtd(struct domain *d, - xen_domctl_bind_pt_irq_t *pt_irq_bind); -unsigned int io_apic_read_remap_rte(unsigned int apic, unsigned int reg); -void io_apic_write_remap_rte(unsigned int apic, - unsigned int reg, unsigned int value); +int pt_irq_create_bind(struct domain *, xen_domctl_bind_pt_irq_t *); +int pt_irq_destroy_bind(struct domain *, xen_domctl_bind_pt_irq_t *); =20 -struct msi_desc; -struct msi_msg; -void msi_msg_read_remap_rte(struct msi_desc *msi_desc, struct msi_msg = *msg); -void msi_msg_write_remap_rte(struct msi_desc *msi_desc, struct msi_msg = *msg); void hvm_dpci_isairq_eoi(struct domain *d, unsigned int isairq); struct hvm_irq_dpci *domain_get_irq_dpci(const struct domain *); void free_hvm_irq_dpci(struct hvm_irq_dpci *dpci); bool_t pt_irq_need_timer(uint32_t flags); =20 #define PT_IRQ_TIME_OUT MILLISECS(8) -#define VTDPREFIX "[VT-D]" + +struct msi_desc; +struct msi_msg; =20 struct iommu_ops { int (*init)(struct domain *d); --=__Part35040367.1__= Content-Type: text/plain; name="IOMMU-generalize.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="IOMMU-generalize.patch" IOMMU: remove vendor specific bits from generic code=0A=0A- names of = functions used independent of vendor should not have vendor=0A specific = names=0A- vendor specific declarations should not live inn generic = headers=0A- other vendor specific items should not be used in generic = code=0A=0ASigned-off-by: Jan Beulich =0A--=0ANote that = this will only apply cleanly on top of "VT-d: drop bogus=0Achecks", sent = out a few minutes ago.=0A=0A--- a/xen/arch/x86/domctl.c=0A+++ b/xen/arch/x8= 6/domctl.c=0A@@ -776,7 +776,7 @@ long arch_do_domctl(=0A if ( = iommu_enabled )=0A {=0A spin_lock(&pcidevs_lock);=0A- = ret =3D pt_irq_create_bind_vtd(d, bind);=0A+ ret =3D = pt_irq_create_bind(d, bind);=0A spin_unlock(&pcidevs_lock);=0A = }=0A if ( ret < 0 )=0A@@ -806,7 +806,7 @@ long arch_do_domc= tl(=0A if ( iommu_enabled )=0A {=0A spin_lock(&= pcidevs_lock);=0A- ret =3D pt_irq_destroy_bind_vtd(d, bind);=0A+= ret =3D pt_irq_destroy_bind(d, bind);=0A spin_unloc= k(&pcidevs_lock);=0A }=0A if ( ret < 0 )=0A--- a/xen/driver= s/passthrough/io.c=0A+++ b/xen/drivers/passthrough/io.c=0A@@ -95,7 +95,7 = @@ void free_hvm_irq_dpci(struct hvm_irq_dp=0A xfree(dpci);=0A }=0A = =0A-int pt_irq_create_bind_vtd(=0A+int pt_irq_create_bind(=0A struct = domain *d, xen_domctl_bind_pt_irq_t *pt_irq_bind)=0A {=0A struct = hvm_irq_dpci *hvm_irq_dpci =3D NULL;=0A@@ -277,14 +277,14 @@ int pt_irq_cre= ate_bind_vtd(=0A spin_unlock(&d->event_lock);=0A =0A if ( = iommu_verbose )=0A- dprintk(VTDPREFIX,=0A+ dprintk(XE= NLOG_G_INFO,=0A "d%d: bind: m_gsi=3D%u g_gsi=3D%u = device=3D%u intx=3D%u\n",=0A d->domain_id, pirq, = guest_gsi, device, intx);=0A }=0A return 0;=0A }=0A =0A-int = pt_irq_destroy_bind_vtd(=0A+int pt_irq_destroy_bind(=0A struct domain = *d, xen_domctl_bind_pt_irq_t *pt_irq_bind)=0A {=0A struct hvm_irq_dpci = *hvm_irq_dpci =3D NULL;=0A@@ -302,7 +302,7 @@ int pt_irq_destroy_bind_vtd(= =0A link =3D hvm_pci_intx_link(device, intx);=0A =0A if ( = iommu_verbose )=0A- dprintk(VTDPREFIX,=0A+ dprintk(XENLOG_G_I= NFO,=0A "d%d: unbind: m_gsi=3D%u g_gsi=3D%u device=3D%u = intx=3D%u\n",=0A d->domain_id, machine_gsi, guest_gsi, = device, intx);=0A =0A@@ -360,7 +360,7 @@ int pt_irq_destroy_bind_vtd(=0A = spin_unlock(&d->event_lock);=0A =0A if ( iommu_verbose )=0A- = dprintk(VTDPREFIX,=0A+ dprintk(XENLOG_G_INFO,=0A = "d%d unmap: m_irq=3D%u device=3D%u intx=3D%u\n",=0A = d->domain_id, machine_gsi, device, intx);=0A =0A--- a/xen/drivers/passthrou= gh/iommu.c=0A+++ b/xen/drivers/passthrough/iommu.c=0A@@ -364,7 +364,7 @@ = int deassign_device(struct domain *d, u1=0A =0A if ( pdev->domain !=3D = d )=0A {=0A- dprintk(XENLOG_ERR VTDPREFIX,=0A+ dprintk(XE= NLOG_G_ERR,=0A "d%d: deassign a device not owned\n", = d->domain_id);=0A return -EINVAL;=0A }=0A@@ -372,8 +372,8 @@ = int deassign_device(struct domain *d, u1=0A ret =3D hd->platform_ops->r= eassign_device(d, dom0, seg, bus, devfn);=0A if ( ret )=0A {=0A- = dprintk(XENLOG_ERR VTDPREFIX,=0A- "d%d: Deassign = device (%04x:%02x:%02x.%u) failed!\n",=0A+ dprintk(XENLOG_G_ERR,=0A+= "d%d: deassign device (%04x:%02x:%02x.%u) failed\n",=0A = d->domain_id, seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));=0A = return ret;=0A }=0A--- a/xen/drivers/passthrough/vtd/extern.h= =0A+++ b/xen/drivers/passthrough/vtd/extern.h=0A@@ -24,6 +24,8 @@=0A = #include "dmar.h"=0A #include =0A =0A+#define VTDPREFIX = "[VT-D]"=0A+=0A extern bool_t rwbf_quirk;=0A =0A void print_iommu_regs(stru= ct acpi_drhd_unit *drhd);=0A@@ -79,6 +81,15 @@ int domain_context_mapping_o= ne(struct do=0A int domain_context_unmap_one(struct domain *domain, struct = iommu *iommu,=0A u8 bus, u8 devfn);=0A = =0A+unsigned int io_apic_read_remap_rte(unsigned int apic, unsigned int = reg);=0A+void io_apic_write_remap_rte(unsigned int apic,=0A+ = unsigned int reg, unsigned int value);=0A+=0A+struct = msi_desc;=0A+struct msi_msg;=0A+void msi_msg_read_remap_rte(struct = msi_desc *, struct msi_msg *);=0A+void msi_msg_write_remap_rte(struct = msi_desc *, struct msi_msg *);=0A+=0A int is_igd_vt_enabled_quirk(void);=0A= void platform_quirks_init(void);=0A void vtd_ops_preamble_quirk(struct = iommu* iommu);=0A--- a/xen/drivers/passthrough/vtd/iommu.h=0A+++ b/xen/driv= ers/passthrough/vtd/iommu.h=0A@@ -510,6 +510,22 @@ struct intel_iommu {=0A = struct acpi_drhd_unit *drhd;=0A };=0A =0A+struct iommu {=0A+ struct = list_head list;=0A+ void __iomem *reg; /* Pointer to hardware regs, = virtual addr */=0A+ u32 index; /* Sequence number of iommu = */=0A+ u32 nr_pt_levels;=0A+ u64 cap;=0A+ u64 ecap;=0A+ = spinlock_t lock; /* protect context, domain ids */=0A+ spinlock_t = register_lock; /* protect iommu register handling */=0A+ u64 root_maddr;= /* root entry machine address */=0A+ int irq;=0A+ struct intel_iommu= *intel;=0A+ unsigned long *domid_bitmap; /* domain id bitmap */=0A+ = u16 *domid_map; /* domain id mapping array */=0A+};=0A+=0A = static inline struct qi_ctrl *iommu_qi_ctrl(struct iommu *iommu)=0A {=0A = return iommu ? &iommu->intel->qi_ctrl : NULL;=0A--- a/xen/include/xen/iom= mu.h=0A+++ b/xen/include/xen/iommu.h=0A@@ -48,22 +48,6 @@ extern struct = rangeset *mmio_ro_ranges;=0A #define PAGE_MASK_4K (((u64)-1) << = PAGE_SHIFT_4K)=0A #define PAGE_ALIGN_4K(addr) (((addr) + PAGE_SIZE_4K - 1) = & PAGE_MASK_4K)=0A =0A-struct iommu {=0A- struct list_head list;=0A- = void __iomem *reg; /* Pointer to hardware regs, virtual addr */=0A- u32 = index; /* Sequence number of iommu */=0A- u32 nr_pt_levels;=0A- = u64 cap;=0A- u64 ecap;=0A- spinlock_t lock; /* protect context, = domain ids */=0A- spinlock_t register_lock; /* protect iommu register = handling */=0A- u64 root_maddr; /* root entry machine address */=0A- = int irq;=0A- struct intel_iommu *intel;=0A- unsigned long *domid_bitm= ap; /* domain id bitmap */=0A- u16 *domid_map; /* domain = id mapping array */=0A-};=0A-=0A int iommu_setup(void);=0A int iommu_suppor= ts_eim(void);=0A int iommu_enable_x2apic_IR(void);=0A@@ -94,25 +78,18 @@ = void pt_pci_init(void);=0A struct pirq;=0A int hvm_do_IRQ_dpci(struct = domain *, struct pirq *);=0A int dpci_ioport_intercept(ioreq_t *p);=0A-int = pt_irq_create_bind_vtd(struct domain *d,=0A- = xen_domctl_bind_pt_irq_t *pt_irq_bind);=0A-int pt_irq_destroy_bind_vtd(stru= ct domain *d,=0A- xen_domctl_bind_pt_irq_t = *pt_irq_bind);=0A-unsigned int io_apic_read_remap_rte(unsigned int apic, = unsigned int reg);=0A-void io_apic_write_remap_rte(unsigned int apic,=0A- = unsigned int reg, unsigned int value);=0A+int = pt_irq_create_bind(struct domain *, xen_domctl_bind_pt_irq_t *);=0A+int = pt_irq_destroy_bind(struct domain *, xen_domctl_bind_pt_irq_t *);=0A = =0A-struct msi_desc;=0A-struct msi_msg;=0A-void msi_msg_read_remap_rte(stru= ct msi_desc *msi_desc, struct msi_msg *msg);=0A-void msi_msg_write_remap_rt= e(struct msi_desc *msi_desc, struct msi_msg *msg);=0A void hvm_dpci_isairq_= eoi(struct domain *d, unsigned int isairq);=0A struct hvm_irq_dpci = *domain_get_irq_dpci(const struct domain *);=0A void free_hvm_irq_dpci(stru= ct hvm_irq_dpci *dpci);=0A bool_t pt_irq_need_timer(uint32_t flags);=0A = =0A #define PT_IRQ_TIME_OUT MILLISECS(8)=0A-#define VTDPREFIX "[VT-D]"=0A+= =0A+struct msi_desc;=0A+struct msi_msg;=0A =0A struct iommu_ops {=0A = int (*init)(struct domain *d);=0A --=__Part35040367.1__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --=__Part35040367.1__=-- From xen-devel-bounces@lists.xen.org Tue Oct 02 15:01:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 15:01:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3yn-0001PM-0v; Tue, 02 Oct 2012 15:01:49 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3yl-0001Ow-3v for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 15:01:47 +0000 Received: from [85.158.139.83:2785] by server-4.bemta-5.messagelabs.com id AF/90-20767-AD10B605; Tue, 02 Oct 2012 15:01:46 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1349190105!27472231!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24768 invoked from network); 2 Oct 2012 15:01:45 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 15:01:45 -0000 X-IronPort-AV: E=Sophos;i="4.80,523,1344211200"; d="scan'208";a="14897169" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 15:01:42 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 16:01:42 +0100 Date: Tue, 2 Oct 2012 16:00:43 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Konrad Rzeszutek Wilk Message-ID: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, Stefano Stabellini Subject: [Xen-devel] [PATCH] xen/Makefile: fix dom-y build X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org We need to add $(dom0-y) to obj-$(CONFIG_XEN_DOM0) after dom0-y is defined otherwise we end up adding nothing. Signed-off-by: Stefano Stabellini diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile index cd28aae..275abfc 100644 --- a/drivers/xen/Makefile +++ b/drivers/xen/Makefile @@ -8,10 +8,10 @@ obj-y += xenbus/ nostackp := $(call cc-option, -fno-stack-protector) CFLAGS_features.o := $(nostackp) -obj-$(CONFIG_XEN_DOM0) += $(dom0-y) dom0-$(CONFIG_PCI) += pci.o dom0-$(CONFIG_ACPI) += acpi.o dom0-$(CONFIG_X86) += pcpu.o +obj-$(CONFIG_XEN_DOM0) += $(dom0-y) obj-$(CONFIG_BLOCK) += biomerge.o obj-$(CONFIG_XEN_XENCOMM) += xencomm.o obj-$(CONFIG_XEN_BALLOON) += xen-balloon.o _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 15:01:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 15:01:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3yn-0001PM-0v; Tue, 02 Oct 2012 15:01:49 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3yl-0001Ow-3v for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 15:01:47 +0000 Received: from [85.158.139.83:2785] by server-4.bemta-5.messagelabs.com id AF/90-20767-AD10B605; Tue, 02 Oct 2012 15:01:46 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1349190105!27472231!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24768 invoked from network); 2 Oct 2012 15:01:45 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 15:01:45 -0000 X-IronPort-AV: E=Sophos;i="4.80,523,1344211200"; d="scan'208";a="14897169" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 15:01:42 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 16:01:42 +0100 Date: Tue, 2 Oct 2012 16:00:43 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Konrad Rzeszutek Wilk Message-ID: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, Stefano Stabellini Subject: [Xen-devel] [PATCH] xen/Makefile: fix dom-y build X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org We need to add $(dom0-y) to obj-$(CONFIG_XEN_DOM0) after dom0-y is defined otherwise we end up adding nothing. Signed-off-by: Stefano Stabellini diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile index cd28aae..275abfc 100644 --- a/drivers/xen/Makefile +++ b/drivers/xen/Makefile @@ -8,10 +8,10 @@ obj-y += xenbus/ nostackp := $(call cc-option, -fno-stack-protector) CFLAGS_features.o := $(nostackp) -obj-$(CONFIG_XEN_DOM0) += $(dom0-y) dom0-$(CONFIG_PCI) += pci.o dom0-$(CONFIG_ACPI) += acpi.o dom0-$(CONFIG_X86) += pcpu.o +obj-$(CONFIG_XEN_DOM0) += $(dom0-y) obj-$(CONFIG_BLOCK) += biomerge.o obj-$(CONFIG_XEN_XENCOMM) += xencomm.o obj-$(CONFIG_XEN_BALLOON) += xen-balloon.o _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 15:02:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 15:02:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3zW-0001X8-GN; Tue, 02 Oct 2012 15:02:34 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3zV-0001Wu-1z for xen-devel@lists.xen.org; Tue, 02 Oct 2012 15:02:33 +0000 Received: from [85.158.137.99:13463] by server-10.bemta-3.messagelabs.com id 0A/8B-02525-8020B605; Tue, 02 Oct 2012 15:02:32 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-16.tower-217.messagelabs.com!1349190151!19972059!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17225 invoked from network); 2 Oct 2012 15:02:32 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 15:02:32 -0000 X-IronPort-AV: E=Sophos;i="4.80,523,1344211200"; d="scan'208";a="14897202" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 15:02:31 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 16:02:31 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TJ3zS-0001na-TV; Tue, 02 Oct 2012 15:02:30 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TJ3zS-00063t-Q0; Tue, 02 Oct 2012 16:02:30 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20587.518.534423.770104@mariner.uk.xensource.com> Date: Tue, 2 Oct 2012 16:02:30 +0100 To: Ian Campbell , "Keir (Xen.org)" , "xen-devel@lists.xen.org" Newsgroups: chiark.mail.xen.devel In-Reply-To: <20577.49067.710246.317319@mariner.uk.xensource.com> References: <1348566052.3452.145.camel@zakaz.uk.xensource.com> <20577.33326.654049.560825@mariner.uk.xensource.com> <1348576819.3452.199.camel@zakaz.uk.xensource.com> <20577.49067.710246.317319@mariner.uk.xensource.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Subject: Re: [Xen-devel] [PATCH] tools: bump SONAMEs for changes during 4.2 development cycle X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Jackson writes ("Re: [Xen-devel] [PATCH] tools: bump SONAMEs for changes during 4.2 development cycle"): > Ian Campbell writes ("Re: [Xen-devel] [PATCH] tools: bump SONAMEs for changes during 4.2 development cycle"): > > On Tue, 2012-09-25 at 11:06 +0100, Ian Jackson wrote: > > > Also for 4.2. > > > > I assume you'll do that once it passes through a test? > > Yes. Now done. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 15:02:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 15:02:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3zW-0001X8-GN; Tue, 02 Oct 2012 15:02:34 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ3zV-0001Wu-1z for xen-devel@lists.xen.org; Tue, 02 Oct 2012 15:02:33 +0000 Received: from [85.158.137.99:13463] by server-10.bemta-3.messagelabs.com id 0A/8B-02525-8020B605; Tue, 02 Oct 2012 15:02:32 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-16.tower-217.messagelabs.com!1349190151!19972059!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17225 invoked from network); 2 Oct 2012 15:02:32 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 15:02:32 -0000 X-IronPort-AV: E=Sophos;i="4.80,523,1344211200"; d="scan'208";a="14897202" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 15:02:31 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 16:02:31 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TJ3zS-0001na-TV; Tue, 02 Oct 2012 15:02:30 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TJ3zS-00063t-Q0; Tue, 02 Oct 2012 16:02:30 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20587.518.534423.770104@mariner.uk.xensource.com> Date: Tue, 2 Oct 2012 16:02:30 +0100 To: Ian Campbell , "Keir (Xen.org)" , "xen-devel@lists.xen.org" Newsgroups: chiark.mail.xen.devel In-Reply-To: <20577.49067.710246.317319@mariner.uk.xensource.com> References: <1348566052.3452.145.camel@zakaz.uk.xensource.com> <20577.33326.654049.560825@mariner.uk.xensource.com> <1348576819.3452.199.camel@zakaz.uk.xensource.com> <20577.49067.710246.317319@mariner.uk.xensource.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Subject: Re: [Xen-devel] [PATCH] tools: bump SONAMEs for changes during 4.2 development cycle X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Jackson writes ("Re: [Xen-devel] [PATCH] tools: bump SONAMEs for changes during 4.2 development cycle"): > Ian Campbell writes ("Re: [Xen-devel] [PATCH] tools: bump SONAMEs for changes during 4.2 development cycle"): > > On Tue, 2012-09-25 at 11:06 +0100, Ian Jackson wrote: > > > Also for 4.2. > > > > I assume you'll do that once it passes through a test? > > Yes. Now done. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 15:06:24 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 15:06:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ435-0001y0-AG; Tue, 02 Oct 2012 15:06:15 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ434-0001xt-9P for xen-devel@lists.xen.org; Tue, 02 Oct 2012 15:06:14 +0000 Received: from [85.158.139.211:2885] by server-14.bemta-5.messagelabs.com id F1/58-05772-5E20B605; Tue, 02 Oct 2012 15:06:13 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-206.messagelabs.com!1349190372!20771923!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18168 invoked from network); 2 Oct 2012 15:06:13 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 15:06:13 -0000 X-IronPort-AV: E=Sophos;i="4.80,523,1344211200"; d="scan'208";a="14897362" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 15:05:52 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 16:05:52 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TJ42i-0001s3-8S; Tue, 02 Oct 2012 15:05:52 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TJ42i-00064E-4e; Tue, 02 Oct 2012 16:05:52 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20587.720.26324.396214@mariner.uk.xensource.com> Date: Tue, 2 Oct 2012 16:05:52 +0100 To: Matthew Fioravante Newsgroups: chiark.mail.xen.devel In-Reply-To: <1349122340-13436-1-git-send-email-matthew.fioravante@jhuapl.edu> References: <1349122340-13436-1-git-send-email-matthew.fioravante@jhuapl.edu> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: keir@xen.org, Ian.Campbell@citrix.com, xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH] Matthew Fioravante now maintains VTPM X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Matthew Fioravante writes ("[Xen-devel] [PATCH] Matthew Fioravante now maintains VTPM"): > See MAINTAINERS file I think it is a good idea to formally record your maintainership, thanks. Acked-by: Ian Jackson (CC Keir) Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 15:06:24 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 15:06:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ435-0001y0-AG; Tue, 02 Oct 2012 15:06:15 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ434-0001xt-9P for xen-devel@lists.xen.org; Tue, 02 Oct 2012 15:06:14 +0000 Received: from [85.158.139.211:2885] by server-14.bemta-5.messagelabs.com id F1/58-05772-5E20B605; Tue, 02 Oct 2012 15:06:13 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-206.messagelabs.com!1349190372!20771923!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18168 invoked from network); 2 Oct 2012 15:06:13 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 15:06:13 -0000 X-IronPort-AV: E=Sophos;i="4.80,523,1344211200"; d="scan'208";a="14897362" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 15:05:52 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 16:05:52 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TJ42i-0001s3-8S; Tue, 02 Oct 2012 15:05:52 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TJ42i-00064E-4e; Tue, 02 Oct 2012 16:05:52 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20587.720.26324.396214@mariner.uk.xensource.com> Date: Tue, 2 Oct 2012 16:05:52 +0100 To: Matthew Fioravante Newsgroups: chiark.mail.xen.devel In-Reply-To: <1349122340-13436-1-git-send-email-matthew.fioravante@jhuapl.edu> References: <1349122340-13436-1-git-send-email-matthew.fioravante@jhuapl.edu> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: keir@xen.org, Ian.Campbell@citrix.com, xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH] Matthew Fioravante now maintains VTPM X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Matthew Fioravante writes ("[Xen-devel] [PATCH] Matthew Fioravante now maintains VTPM"): > See MAINTAINERS file I think it is a good idea to formally record your maintainership, thanks. Acked-by: Ian Jackson (CC Keir) Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 15:14:36 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 15:14:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4As-0002CH-Ep; Tue, 02 Oct 2012 15:14:18 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4Aq-0002CC-5h for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 15:14:16 +0000 Received: from [85.158.137.99:43301] by server-10.bemta-3.messagelabs.com id 69/43-02525-7C40B605; Tue, 02 Oct 2012 15:14:15 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-6.tower-217.messagelabs.com!1349190854!14851422!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22091 invoked from network); 2 Oct 2012 15:14:15 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 15:14:15 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="14897631" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 15:14:14 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 16:14:14 +0100 Date: Tue, 2 Oct 2012 16:13:15 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Konrad Rzeszutek Wilk Message-ID: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: sfr@canb.auug.org.au, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, JBeulich@suse.com, Stefano Stabellini Subject: [Xen-devel] [PATCH] xen/Makefile: resolve merge conflict with 9fa5780beea1 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch is actually a merge conflict resolution between Konrad's Xen tree and the following commit: commit 9fa5780beea1274d498a224822397100022da7d4 Author: Jan Beulich Date: Tue Sep 18 12:23:02 2012 +0100 USB EHCI/Xen: propagate controller reset information to hypervisor Compile dbgp.o only if CONFIG_USB is defined. After all xen_dbgp_op relies on hcd_to_bus. This patch should be applied on top of http://marc.info/?l=linux-kernel&m=134919011231980&w=2 Reported-by: Stephen Rothwell Signed-off-by: Stefano Stabellini diff --cc drivers/xen/Makefile index a4a3cab,275abfc..33711ad --- a/drivers/xen/Makefile +++ b/drivers/xen/Makefile @@@ -4,8 -8,11 +8,12 @@@ obj-y += xenbus nostackp := $(call cc-option, -fno-stack-protector) CFLAGS_features.o := $(nostackp) + dom0-$(CONFIG_PCI) += pci.o + dom0-$(CONFIG_ACPI) += acpi.o + dom0-$(CONFIG_X86) += pcpu.o ++dom0-$(CONFIG_USB) += dbgp.o + obj-$(CONFIG_XEN_DOM0) += $(dom0-y) obj-$(CONFIG_BLOCK) += biomerge.o - obj-$(CONFIG_HOTPLUG_CPU) += cpu_hotplug.o obj-$(CONFIG_XEN_XENCOMM) += xencomm.o obj-$(CONFIG_XEN_BALLOON) += xen-balloon.o obj-$(CONFIG_XEN_SELFBALLOONING) += xen-selfballoon.o _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 15:14:36 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 15:14:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4As-0002CH-Ep; Tue, 02 Oct 2012 15:14:18 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4Aq-0002CC-5h for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 15:14:16 +0000 Received: from [85.158.137.99:43301] by server-10.bemta-3.messagelabs.com id 69/43-02525-7C40B605; Tue, 02 Oct 2012 15:14:15 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-6.tower-217.messagelabs.com!1349190854!14851422!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22091 invoked from network); 2 Oct 2012 15:14:15 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 15:14:15 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="14897631" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 15:14:14 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 16:14:14 +0100 Date: Tue, 2 Oct 2012 16:13:15 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Konrad Rzeszutek Wilk Message-ID: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: sfr@canb.auug.org.au, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, JBeulich@suse.com, Stefano Stabellini Subject: [Xen-devel] [PATCH] xen/Makefile: resolve merge conflict with 9fa5780beea1 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch is actually a merge conflict resolution between Konrad's Xen tree and the following commit: commit 9fa5780beea1274d498a224822397100022da7d4 Author: Jan Beulich Date: Tue Sep 18 12:23:02 2012 +0100 USB EHCI/Xen: propagate controller reset information to hypervisor Compile dbgp.o only if CONFIG_USB is defined. After all xen_dbgp_op relies on hcd_to_bus. This patch should be applied on top of http://marc.info/?l=linux-kernel&m=134919011231980&w=2 Reported-by: Stephen Rothwell Signed-off-by: Stefano Stabellini diff --cc drivers/xen/Makefile index a4a3cab,275abfc..33711ad --- a/drivers/xen/Makefile +++ b/drivers/xen/Makefile @@@ -4,8 -8,11 +8,12 @@@ obj-y += xenbus nostackp := $(call cc-option, -fno-stack-protector) CFLAGS_features.o := $(nostackp) + dom0-$(CONFIG_PCI) += pci.o + dom0-$(CONFIG_ACPI) += acpi.o + dom0-$(CONFIG_X86) += pcpu.o ++dom0-$(CONFIG_USB) += dbgp.o + obj-$(CONFIG_XEN_DOM0) += $(dom0-y) obj-$(CONFIG_BLOCK) += biomerge.o - obj-$(CONFIG_HOTPLUG_CPU) += cpu_hotplug.o obj-$(CONFIG_XEN_XENCOMM) += xencomm.o obj-$(CONFIG_XEN_BALLOON) += xen-balloon.o obj-$(CONFIG_XEN_SELFBALLOONING) += xen-selfballoon.o _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 15:16:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 15:16:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4DC-0002Kw-0F; Tue, 02 Oct 2012 15:16:42 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4DA-0002Kp-OR for xen-devel@lists.xen.org; Tue, 02 Oct 2012 15:16:40 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-7.tower-27.messagelabs.com!1349190993!5502981!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MjMzMTI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22373 invoked from network); 2 Oct 2012 15:16:34 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 15:16:34 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id DEFCF1B47; Tue, 2 Oct 2012 18:16:32 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 867A520058; Tue, 2 Oct 2012 18:16:32 +0300 (EEST) Date: Tue, 2 Oct 2012 18:16:32 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Ian Campbell Message-ID: <20121002151632.GR8912@reaktio.net> References: <20121001164239.GE8912@reaktio.net> <20586.63875.490107.170343@mariner.uk.xensource.com> <1349188361.650.77.camel@zakaz.uk.xensource.com> <20121002145044.GQ8912@reaktio.net> <1349189762.650.87.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1349189762.650.87.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: George Dunlap , Ian Jackson , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Xen 4.3 development update X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, Oct 02, 2012 at 03:56:02PM +0100, Ian Campbell wrote: > On Tue, 2012-10-02 at 15:50 +0100, Pasi K=E4rkk=E4inen wrote: > > On Tue, Oct 02, 2012 at 03:32:41PM +0100, Ian Campbell wrote: > > > = > > > > > * xl USB pass-through for HVM guests using Qemu USB emulation > > > > > owner: ? = > > > > > status: ? > > > > > - xm/xend with qemu-traditional supports USB passthrough to HV= M guests using the Qemu emulated USB controller. > > > > > - port the xm/xend functionality to xl. > > > > > - make sure USB passthrough with xl works with both qemu-tradi= tional and qemu-upstream. > > > > > - The HVM guest does not need any special drivers for this fea= ture. > > > > = > > > > I think this is just a matter of plumbing in libxl (presumably, now, > > > > plumbing to qemu-upstream). > > > = > > > Assuming qemu-upstream has the necessary feature... > > > = > > = > > Yes, qemu-upstream supports host USB device pass-through. > > = > > references: > > http://www.linux-kvm.org/page/USB_Host_Device_Assigned_to_Guest > > http://david.wragg.org/blog/2009/03/using-usb-pass-through-under-libvir= t.html > > http://david.wragg.org/blog/2009/03/usb-pass-through-with-libvirt-and-k= vm.html > > = > > So basicly the qemu cmdline needs to have: > > -usb -usbdevice host:xxxx:yyyy > = > If you do this via xl's device_model_args=3D config option then does this > Just Work? > = It should work. Someone has to try it.. = (I'm currently away from the machine where I could test this.) -- Pasi = _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 15:16:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 15:16:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4DC-0002Kw-0F; Tue, 02 Oct 2012 15:16:42 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4DA-0002Kp-OR for xen-devel@lists.xen.org; Tue, 02 Oct 2012 15:16:40 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-7.tower-27.messagelabs.com!1349190993!5502981!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MjMzMTI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22373 invoked from network); 2 Oct 2012 15:16:34 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 15:16:34 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id DEFCF1B47; Tue, 2 Oct 2012 18:16:32 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 867A520058; Tue, 2 Oct 2012 18:16:32 +0300 (EEST) Date: Tue, 2 Oct 2012 18:16:32 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Ian Campbell Message-ID: <20121002151632.GR8912@reaktio.net> References: <20121001164239.GE8912@reaktio.net> <20586.63875.490107.170343@mariner.uk.xensource.com> <1349188361.650.77.camel@zakaz.uk.xensource.com> <20121002145044.GQ8912@reaktio.net> <1349189762.650.87.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1349189762.650.87.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: George Dunlap , Ian Jackson , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Xen 4.3 development update X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, Oct 02, 2012 at 03:56:02PM +0100, Ian Campbell wrote: > On Tue, 2012-10-02 at 15:50 +0100, Pasi K=E4rkk=E4inen wrote: > > On Tue, Oct 02, 2012 at 03:32:41PM +0100, Ian Campbell wrote: > > > = > > > > > * xl USB pass-through for HVM guests using Qemu USB emulation > > > > > owner: ? = > > > > > status: ? > > > > > - xm/xend with qemu-traditional supports USB passthrough to HV= M guests using the Qemu emulated USB controller. > > > > > - port the xm/xend functionality to xl. > > > > > - make sure USB passthrough with xl works with both qemu-tradi= tional and qemu-upstream. > > > > > - The HVM guest does not need any special drivers for this fea= ture. > > > > = > > > > I think this is just a matter of plumbing in libxl (presumably, now, > > > > plumbing to qemu-upstream). > > > = > > > Assuming qemu-upstream has the necessary feature... > > > = > > = > > Yes, qemu-upstream supports host USB device pass-through. > > = > > references: > > http://www.linux-kvm.org/page/USB_Host_Device_Assigned_to_Guest > > http://david.wragg.org/blog/2009/03/using-usb-pass-through-under-libvir= t.html > > http://david.wragg.org/blog/2009/03/usb-pass-through-with-libvirt-and-k= vm.html > > = > > So basicly the qemu cmdline needs to have: > > -usb -usbdevice host:xxxx:yyyy > = > If you do this via xl's device_model_args=3D config option then does this > Just Work? > = It should work. Someone has to try it.. = (I'm currently away from the machine where I could test this.) -- Pasi = _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 15:17:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 15:17:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4DU-0002Mt-DC; Tue, 02 Oct 2012 15:17:00 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4DT-0002MZ-9F for xen-devel@lists.xen.org; Tue, 02 Oct 2012 15:16:59 +0000 Received: from [85.158.143.35:11246] by server-1.bemta-4.messagelabs.com id CE/5C-05684-A650B605; Tue, 02 Oct 2012 15:16:58 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-6.tower-21.messagelabs.com!1349191016!20741933!1 X-Originating-IP: [128.244.251.36] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3521 invoked from network); 2 Oct 2012 15:16:57 -0000 Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36) by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 15:16:57 -0000 Received: from ([128.244.207.89]) by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.154116406; Tue, 02 Oct 2012 11:16:47 -0400 Message-ID: <506B050E.2090705@jhuapl.edu> Date: Tue, 02 Oct 2012 11:15:26 -0400 From: Matthew Fioravante User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Ian Jackson References: <1349122340-13436-1-git-send-email-matthew.fioravante@jhuapl.edu> <20587.720.26324.396214@mariner.uk.xensource.com> In-Reply-To: <20587.720.26324.396214@mariner.uk.xensource.com> X-Enigmail-Version: 1.4.4 Cc: "keir@xen.org" , "Ian.Campbell@citrix.com" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] Matthew Fioravante now maintains VTPM X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0814866362496433536==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a cryptographically signed message in MIME format. --===============0814866362496433536== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020500070306030202020306" This is a cryptographically signed message in MIME format. --------------ms020500070306030202020306 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 10/02/2012 11:05 AM, Ian Jackson wrote: > Matthew Fioravante writes ("[Xen-devel] [PATCH] Matthew Fioravante now = maintains VTPM"): >> See MAINTAINERS file > I think it is a good idea to formally record your maintainership, > thanks. Sorry, what exactly do you mean by that? Do you need a formal statement in email? A statement in the patch commit description? > > Acked-by: Ian Jackson > > (CC Keir) > > Ian. --------------ms020500070306030202020306 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4 NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50 ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz 4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTEyMTAwMjE1MTUyNlowIwYJKoZIhvcNAQkEMRYEFH/6EMi1fMrsDG4j ok68G51K7T1IMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYCNRcsFThIO1nKxYrelZluSv3V9yoVRvB1X CTtOs/LlVCN2nEdYHT1U/hYcW6RiXWLA9ZrIXR122QaIuFuXhwlv0hGLm1JyuzJnF9AYQWgk h80lhrVFlL5tPi+65p2nakDO8cUqwXWRe2D48YDWdkHhp32+VxvrrifzKVHX0Jh5yQAAAAAA AA== --------------ms020500070306030202020306-- --===============0814866362496433536== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============0814866362496433536==-- From xen-devel-bounces@lists.xen.org Tue Oct 02 15:17:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 15:17:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4DU-0002Mt-DC; Tue, 02 Oct 2012 15:17:00 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4DT-0002MZ-9F for xen-devel@lists.xen.org; Tue, 02 Oct 2012 15:16:59 +0000 Received: from [85.158.143.35:11246] by server-1.bemta-4.messagelabs.com id CE/5C-05684-A650B605; Tue, 02 Oct 2012 15:16:58 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-6.tower-21.messagelabs.com!1349191016!20741933!1 X-Originating-IP: [128.244.251.36] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3521 invoked from network); 2 Oct 2012 15:16:57 -0000 Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36) by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 15:16:57 -0000 Received: from ([128.244.207.89]) by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.154116406; Tue, 02 Oct 2012 11:16:47 -0400 Message-ID: <506B050E.2090705@jhuapl.edu> Date: Tue, 02 Oct 2012 11:15:26 -0400 From: Matthew Fioravante User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Ian Jackson References: <1349122340-13436-1-git-send-email-matthew.fioravante@jhuapl.edu> <20587.720.26324.396214@mariner.uk.xensource.com> In-Reply-To: <20587.720.26324.396214@mariner.uk.xensource.com> X-Enigmail-Version: 1.4.4 Cc: "keir@xen.org" , "Ian.Campbell@citrix.com" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] Matthew Fioravante now maintains VTPM X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0814866362496433536==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a cryptographically signed message in MIME format. --===============0814866362496433536== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020500070306030202020306" This is a cryptographically signed message in MIME format. --------------ms020500070306030202020306 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 10/02/2012 11:05 AM, Ian Jackson wrote: > Matthew Fioravante writes ("[Xen-devel] [PATCH] Matthew Fioravante now = maintains VTPM"): >> See MAINTAINERS file > I think it is a good idea to formally record your maintainership, > thanks. Sorry, what exactly do you mean by that? Do you need a formal statement in email? A statement in the patch commit description? > > Acked-by: Ian Jackson > > (CC Keir) > > Ian. --------------ms020500070306030202020306 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4 NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50 ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz 4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTEyMTAwMjE1MTUyNlowIwYJKoZIhvcNAQkEMRYEFH/6EMi1fMrsDG4j ok68G51K7T1IMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYCNRcsFThIO1nKxYrelZluSv3V9yoVRvB1X CTtOs/LlVCN2nEdYHT1U/hYcW6RiXWLA9ZrIXR122QaIuFuXhwlv0hGLm1JyuzJnF9AYQWgk h80lhrVFlL5tPi+65p2nakDO8cUqwXWRe2D48YDWdkHhp32+VxvrrifzKVHX0Jh5yQAAAAAA AA== --------------ms020500070306030202020306-- --===============0814866362496433536== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============0814866362496433536==-- From xen-devel-bounces@lists.xen.org Tue Oct 02 15:20:57 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 15:20:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4H9-0002dk-2A; Tue, 02 Oct 2012 15:20:47 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4H6-0002dc-U7 for xen-devel@lists.xen.org; Tue, 02 Oct 2012 15:20:45 +0000 Received: from [85.158.143.35:28328] by server-1.bemta-4.messagelabs.com id 1B/41-05684-C460B605; Tue, 02 Oct 2012 15:20:44 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1349191243!16026897!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28663 invoked from network); 2 Oct 2012 15:20:43 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-15.tower-21.messagelabs.com with SMTP; 2 Oct 2012 15:20:43 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 02 Oct 2012 16:20:42 +0100 Message-Id: <506B2268020000780009F273@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Tue, 02 Oct 2012 16:20:40 +0100 From: "Jan Beulich" To: "xen-devel" Mime-Version: 1.0 Content-Disposition: inline Subject: [Xen-devel] [PATCH 0/3] x86: adjust entry frame generation X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This set of patches converts the way frames gets created from using PUSHes/POPs to using MOVes, thus allowing (in certain cases) to avoid saving/restoring part of the register set. While the place where the (small) win from this comes from varies between CPUs, the net effect is a 1 to 2% reduction on a combined interruption entry and exit when the full state save can be avoided. 1: use MOV instead of PUSH/POP when saving/restoring register state 2: consolidate frame state manipulation functions 3: save only partial register state where possible Signed-off-by: Jan Beulich _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 15:20:57 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 15:20:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4H9-0002dk-2A; Tue, 02 Oct 2012 15:20:47 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4H6-0002dc-U7 for xen-devel@lists.xen.org; Tue, 02 Oct 2012 15:20:45 +0000 Received: from [85.158.143.35:28328] by server-1.bemta-4.messagelabs.com id 1B/41-05684-C460B605; Tue, 02 Oct 2012 15:20:44 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1349191243!16026897!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28663 invoked from network); 2 Oct 2012 15:20:43 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-15.tower-21.messagelabs.com with SMTP; 2 Oct 2012 15:20:43 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 02 Oct 2012 16:20:42 +0100 Message-Id: <506B2268020000780009F273@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Tue, 02 Oct 2012 16:20:40 +0100 From: "Jan Beulich" To: "xen-devel" Mime-Version: 1.0 Content-Disposition: inline Subject: [Xen-devel] [PATCH 0/3] x86: adjust entry frame generation X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This set of patches converts the way frames gets created from using PUSHes/POPs to using MOVes, thus allowing (in certain cases) to avoid saving/restoring part of the register set. While the place where the (small) win from this comes from varies between CPUs, the net effect is a 1 to 2% reduction on a combined interruption entry and exit when the full state save can be avoided. 1: use MOV instead of PUSH/POP when saving/restoring register state 2: consolidate frame state manipulation functions 3: save only partial register state where possible Signed-off-by: Jan Beulich _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 15:22:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 15:22:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4IP-0002jG-KN; Tue, 02 Oct 2012 15:22:05 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4IO-0002jA-7x for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 15:22:04 +0000 Received: from [85.158.139.211:38767] by server-9.bemta-5.messagelabs.com id FA/A2-14846-B960B605; Tue, 02 Oct 2012 15:22:03 +0000 X-Env-Sender: sfr@canb.auug.org.au X-Msg-Ref: server-4.tower-206.messagelabs.com!1349191321!20808607!1 X-Originating-IP: [203.10.76.10] X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24072 invoked from network); 2 Oct 2012 15:22:02 -0000 Received: from haggis.pcug.org.au (HELO members.tip.net.au) (203.10.76.10) by server-4.tower-206.messagelabs.com with SMTP; 2 Oct 2012 15:22:02 -0000 Received: from canb.auug.org.au (ash.rothwell.emu.id.au [IPv6:2402:b800:7003:7010:223:14ff:fe30:c8e4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by members.tip.net.au (Postfix) with ESMTPSA id 4D3481640EA; Wed, 3 Oct 2012 01:22:00 +1000 (EST) Date: Wed, 3 Oct 2012 01:21:59 +1000 From: Stephen Rothwell To: Stefano Stabellini Message-Id: <20121003012159.029e5282fa108697eaa3a9ff@canb.auug.org.au> In-Reply-To: References: X-Mailer: Sylpheed 3.2.0 (GTK+ 2.24.10; i486-pc-linux-gnu) Mime-Version: 1.0 Cc: JBeulich@suse.com, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH] xen/Makefile: resolve merge conflict with 9fa5780beea1 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1618114935765367751==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============1618114935765367751== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA256"; boundary="Signature=_Wed__3_Oct_2012_01_21_59_+1000_pG.fPmj3ziZxjhp2" --Signature=_Wed__3_Oct_2012_01_21_59_+1000_pG.fPmj3ziZxjhp2 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, 2 Oct 2012 16:13:15 +0100 Stefano Stabellini wrote: > > This patch is actually a merge conflict resolution between Konrad's Xen > tree and the following commit: >=20 > commit 9fa5780beea1274d498a224822397100022da7d4 > Author: Jan Beulich > Date: Tue Sep 18 12:23:02 2012 +0100 >=20 > USB EHCI/Xen: propagate controller reset information to hypervisor >=20 >=20 > Compile dbgp.o only if CONFIG_USB is defined. > After all xen_dbgp_op relies on hcd_to_bus. >=20 > This patch should be applied on top of=20 >=20 > http://marc.info/?l=3Dlinux-kernel&m=3D134919011231980&w=3D2 >=20 >=20 > Reported-by: Stephen Rothwell > Signed-off-by: Stefano Stabellini I'll use this resolution if it is needed tomorrow. Assuming that the other build problem with the xen-two tree is fixed, of course. --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au --Signature=_Wed__3_Oct_2012_01_21_59_+1000_pG.fPmj3ziZxjhp2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQawaXAAoJEECxmPOUX5FEmCwP/i1qnJV8Gg636RBjQL1DnKEG wS3xy+qoZjcYA8yyxg2fIv5xinO7BCcrIcTiYHRNCr4/O38O8dPk9Fi5/t39jTHt D5DK5P8T6i5Q6WdmEzHN/YFgnOpYx+UC8jsmA4zq18+qhhQtqhGomHEFqsKjXblL k7DjmBuRrrptWA7VbJADFMKcmXTEjbuiJPyIsVZNQ6pSXh/FuC3iDV7U41tSRBd2 gzb9thERjBPKdkXPk8ERYdwR36FuQloooBk6tXe/0utxPHnEf4sTRctlVtVPIKqT xNWD3hlWR1KmDapjzMgBDS3vYxS+golkaPEZ83kdIuWriCs1jfI0jAR+m0V6/F6U YcWe75i5nrIVIK6bJHx8TltiHmHIvShz7NHyrAtK0HaKUIZjTyCYOX3CEfw3zXc/ ijDffBeiidnsfHTZistc16f+BBacBrZf0SdGfAnfiJ0Tq2HE38warwlbP9cpQt9Q h1F1KmsQEWmxQyjWCA8QDZh+4XMKblVSmUhqby4YofHCeUn4N466CvXUXDUaogSU EFtB0SaUuZTcW8Z2/UFAqn8Z/mTv40zW4Ruj9gs/0YUuQvYXp1CrA5pk2FVK7jge 9sbzhk9If45X5D4KIl6NmBotXEdX6f4FnUHva0nSVCgWPTDVZznaPsOzskYWfw0a 2lPfFVSiqeOfzLgnPo51 =dG5J -----END PGP SIGNATURE----- --Signature=_Wed__3_Oct_2012_01_21_59_+1000_pG.fPmj3ziZxjhp2-- --===============1618114935765367751== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============1618114935765367751==-- From xen-devel-bounces@lists.xen.org Tue Oct 02 15:22:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 15:22:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4IP-0002jG-KN; Tue, 02 Oct 2012 15:22:05 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4IO-0002jA-7x for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 15:22:04 +0000 Received: from [85.158.139.211:38767] by server-9.bemta-5.messagelabs.com id FA/A2-14846-B960B605; Tue, 02 Oct 2012 15:22:03 +0000 X-Env-Sender: sfr@canb.auug.org.au X-Msg-Ref: server-4.tower-206.messagelabs.com!1349191321!20808607!1 X-Originating-IP: [203.10.76.10] X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24072 invoked from network); 2 Oct 2012 15:22:02 -0000 Received: from haggis.pcug.org.au (HELO members.tip.net.au) (203.10.76.10) by server-4.tower-206.messagelabs.com with SMTP; 2 Oct 2012 15:22:02 -0000 Received: from canb.auug.org.au (ash.rothwell.emu.id.au [IPv6:2402:b800:7003:7010:223:14ff:fe30:c8e4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by members.tip.net.au (Postfix) with ESMTPSA id 4D3481640EA; Wed, 3 Oct 2012 01:22:00 +1000 (EST) Date: Wed, 3 Oct 2012 01:21:59 +1000 From: Stephen Rothwell To: Stefano Stabellini Message-Id: <20121003012159.029e5282fa108697eaa3a9ff@canb.auug.org.au> In-Reply-To: References: X-Mailer: Sylpheed 3.2.0 (GTK+ 2.24.10; i486-pc-linux-gnu) Mime-Version: 1.0 Cc: JBeulich@suse.com, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH] xen/Makefile: resolve merge conflict with 9fa5780beea1 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1618114935765367751==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============1618114935765367751== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA256"; boundary="Signature=_Wed__3_Oct_2012_01_21_59_+1000_pG.fPmj3ziZxjhp2" --Signature=_Wed__3_Oct_2012_01_21_59_+1000_pG.fPmj3ziZxjhp2 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, 2 Oct 2012 16:13:15 +0100 Stefano Stabellini wrote: > > This patch is actually a merge conflict resolution between Konrad's Xen > tree and the following commit: >=20 > commit 9fa5780beea1274d498a224822397100022da7d4 > Author: Jan Beulich > Date: Tue Sep 18 12:23:02 2012 +0100 >=20 > USB EHCI/Xen: propagate controller reset information to hypervisor >=20 >=20 > Compile dbgp.o only if CONFIG_USB is defined. > After all xen_dbgp_op relies on hcd_to_bus. >=20 > This patch should be applied on top of=20 >=20 > http://marc.info/?l=3Dlinux-kernel&m=3D134919011231980&w=3D2 >=20 >=20 > Reported-by: Stephen Rothwell > Signed-off-by: Stefano Stabellini I'll use this resolution if it is needed tomorrow. Assuming that the other build problem with the xen-two tree is fixed, of course. --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au --Signature=_Wed__3_Oct_2012_01_21_59_+1000_pG.fPmj3ziZxjhp2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQawaXAAoJEECxmPOUX5FEmCwP/i1qnJV8Gg636RBjQL1DnKEG wS3xy+qoZjcYA8yyxg2fIv5xinO7BCcrIcTiYHRNCr4/O38O8dPk9Fi5/t39jTHt D5DK5P8T6i5Q6WdmEzHN/YFgnOpYx+UC8jsmA4zq18+qhhQtqhGomHEFqsKjXblL k7DjmBuRrrptWA7VbJADFMKcmXTEjbuiJPyIsVZNQ6pSXh/FuC3iDV7U41tSRBd2 gzb9thERjBPKdkXPk8ERYdwR36FuQloooBk6tXe/0utxPHnEf4sTRctlVtVPIKqT xNWD3hlWR1KmDapjzMgBDS3vYxS+golkaPEZ83kdIuWriCs1jfI0jAR+m0V6/F6U YcWe75i5nrIVIK6bJHx8TltiHmHIvShz7NHyrAtK0HaKUIZjTyCYOX3CEfw3zXc/ ijDffBeiidnsfHTZistc16f+BBacBrZf0SdGfAnfiJ0Tq2HE38warwlbP9cpQt9Q h1F1KmsQEWmxQyjWCA8QDZh+4XMKblVSmUhqby4YofHCeUn4N466CvXUXDUaogSU EFtB0SaUuZTcW8Z2/UFAqn8Z/mTv40zW4Ruj9gs/0YUuQvYXp1CrA5pk2FVK7jge 9sbzhk9If45X5D4KIl6NmBotXEdX6f4FnUHva0nSVCgWPTDVZznaPsOzskYWfw0a 2lPfFVSiqeOfzLgnPo51 =dG5J -----END PGP SIGNATURE----- --Signature=_Wed__3_Oct_2012_01_21_59_+1000_pG.fPmj3ziZxjhp2-- --===============1618114935765367751== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============1618114935765367751==-- From xen-devel-bounces@lists.xen.org Tue Oct 02 15:25:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 15:25:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4LK-0002vq-9H; Tue, 02 Oct 2012 15:25:06 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4LI-0002vi-OJ for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 15:25:04 +0000 Received: from [85.158.143.35:47516] by server-1.bemta-4.messagelabs.com id A7/17-05684-0570B605; Tue, 02 Oct 2012 15:25:04 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1349191503!6275773!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14331 invoked from network); 2 Oct 2012 15:25:03 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-4.tower-21.messagelabs.com with SMTP; 2 Oct 2012 15:25:03 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 02 Oct 2012 16:25:02 +0100 Message-Id: <506B236C020000780009F281@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Tue, 02 Oct 2012 16:25:00 +0100 From: "Jan Beulich" To: "Stefano Stabellini" , "Konrad Rzeszutek Wilk" References: In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: sfr@canb.auug.org.au, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org Subject: Re: [Xen-devel] [PATCH] xen/Makefile: resolve merge conflict with 9fa5780beea1 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 02.10.12 at 17:13, Stefano Stabellini wrote: > This patch is actually a merge conflict resolution between Konrad's Xen > tree and the following commit: > > commit 9fa5780beea1274d498a224822397100022da7d4 > Author: Jan Beulich > Date: Tue Sep 18 12:23:02 2012 +0100 > > USB EHCI/Xen: propagate controller reset information to hypervisor > > > Compile dbgp.o only if CONFIG_USB is defined. Now this is wrong: USB is a tristate config option, yet dbgp.o must be built in. This is why I suggested to use USB_SUPPORT (if anything at all). Jan > After all xen_dbgp_op relies on hcd_to_bus. > > This patch should be applied on top of > > http://marc.info/?l=linux-kernel&m=134919011231980&w=2 > > > Reported-by: Stephen Rothwell > Signed-off-by: Stefano Stabellini > > diff --cc drivers/xen/Makefile > index a4a3cab,275abfc..33711ad > --- a/drivers/xen/Makefile > +++ b/drivers/xen/Makefile > @@@ -4,8 -8,11 +8,12 @@@ obj-y += xenbus > nostackp := $(call cc-option, -fno-stack-protector) > CFLAGS_features.o := $(nostackp) > > + dom0-$(CONFIG_PCI) += pci.o > + dom0-$(CONFIG_ACPI) += acpi.o > + dom0-$(CONFIG_X86) += pcpu.o > ++dom0-$(CONFIG_USB) += dbgp.o > + obj-$(CONFIG_XEN_DOM0) += $(dom0-y) > obj-$(CONFIG_BLOCK) += biomerge.o > - obj-$(CONFIG_HOTPLUG_CPU) += cpu_hotplug.o > obj-$(CONFIG_XEN_XENCOMM) += xencomm.o > obj-$(CONFIG_XEN_BALLOON) += xen-balloon.o > obj-$(CONFIG_XEN_SELFBALLOONING) += xen-selfballoon.o _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 15:25:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 15:25:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4LK-0002vq-9H; Tue, 02 Oct 2012 15:25:06 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4LI-0002vi-OJ for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 15:25:04 +0000 Received: from [85.158.143.35:47516] by server-1.bemta-4.messagelabs.com id A7/17-05684-0570B605; Tue, 02 Oct 2012 15:25:04 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1349191503!6275773!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14331 invoked from network); 2 Oct 2012 15:25:03 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-4.tower-21.messagelabs.com with SMTP; 2 Oct 2012 15:25:03 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 02 Oct 2012 16:25:02 +0100 Message-Id: <506B236C020000780009F281@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Tue, 02 Oct 2012 16:25:00 +0100 From: "Jan Beulich" To: "Stefano Stabellini" , "Konrad Rzeszutek Wilk" References: In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: sfr@canb.auug.org.au, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org Subject: Re: [Xen-devel] [PATCH] xen/Makefile: resolve merge conflict with 9fa5780beea1 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 02.10.12 at 17:13, Stefano Stabellini wrote: > This patch is actually a merge conflict resolution between Konrad's Xen > tree and the following commit: > > commit 9fa5780beea1274d498a224822397100022da7d4 > Author: Jan Beulich > Date: Tue Sep 18 12:23:02 2012 +0100 > > USB EHCI/Xen: propagate controller reset information to hypervisor > > > Compile dbgp.o only if CONFIG_USB is defined. Now this is wrong: USB is a tristate config option, yet dbgp.o must be built in. This is why I suggested to use USB_SUPPORT (if anything at all). Jan > After all xen_dbgp_op relies on hcd_to_bus. > > This patch should be applied on top of > > http://marc.info/?l=linux-kernel&m=134919011231980&w=2 > > > Reported-by: Stephen Rothwell > Signed-off-by: Stefano Stabellini > > diff --cc drivers/xen/Makefile > index a4a3cab,275abfc..33711ad > --- a/drivers/xen/Makefile > +++ b/drivers/xen/Makefile > @@@ -4,8 -8,11 +8,12 @@@ obj-y += xenbus > nostackp := $(call cc-option, -fno-stack-protector) > CFLAGS_features.o := $(nostackp) > > + dom0-$(CONFIG_PCI) += pci.o > + dom0-$(CONFIG_ACPI) += acpi.o > + dom0-$(CONFIG_X86) += pcpu.o > ++dom0-$(CONFIG_USB) += dbgp.o > + obj-$(CONFIG_XEN_DOM0) += $(dom0-y) > obj-$(CONFIG_BLOCK) += biomerge.o > - obj-$(CONFIG_HOTPLUG_CPU) += cpu_hotplug.o > obj-$(CONFIG_XEN_XENCOMM) += xencomm.o > obj-$(CONFIG_XEN_BALLOON) += xen-balloon.o > obj-$(CONFIG_XEN_SELFBALLOONING) += xen-selfballoon.o _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 15:27:06 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 15:27:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4N1-00033G-RA; Tue, 02 Oct 2012 15:26:51 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4Mz-00032z-Gu for xen-devel@lists.xen.org; Tue, 02 Oct 2012 15:26:49 +0000 Received: from [85.158.143.35:9232] by server-2.bemta-4.messagelabs.com id E0/E3-06610-8B70B605; Tue, 02 Oct 2012 15:26:48 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1349191585!12753274!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG, UPPERCASE_25_50 X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11334 invoked from network); 2 Oct 2012 15:26:32 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-12.tower-21.messagelabs.com with SMTP; 2 Oct 2012 15:26:32 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 02 Oct 2012 16:26:24 +0100 Message-Id: <506B23BF020000780009F29A@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Tue, 02 Oct 2012 16:26:23 +0100 From: "Jan Beulich" To: "xen-devel" References: <506B2268020000780009F273@nat28.tlf.novell.com> In-Reply-To: <506B2268020000780009F273@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__PartDBEAED8F.0__=" Subject: [Xen-devel] [PATCH 1/3] x86: use MOV instead of PUSH/POP when saving/restoring register state X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartDBEAED8F.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Signed-off-by: Jan Beulich --- a/xen/arch/x86/x86_64/compat/entry.S +++ b/xen/arch/x86/x86_64/compat/entry.S @@ -21,8 +21,7 @@ ENTRY(compat_hypercall) UNLIKELY_START(ne, msi_check) movl $HYPERCALL_VECTOR,%edi call check_for_unexpected_msi - RESTORE_ALL - SAVE_ALL + LOAD_C_CLOBBERED UNLIKELY_END(msi_check) =20 GET_CURRENT(%rbx) @@ -173,8 +172,7 @@ compat_bad_hypercall: /* %rbx: struct vcpu, interrupts disabled */ compat_restore_all_guest: ASSERT_INTERRUPTS_DISABLED - RESTORE_ALL - addq $8,%rsp + RESTORE_ALL adj=3D8 .Lft0: iretq =20 .section .fixup,"ax" --- a/xen/arch/x86/x86_64/entry.S +++ b/xen/arch/x86/x86_64/entry.S @@ -47,12 +47,10 @@ restore_all_guest: cmpl $1,%ecx ja .Lforce_iret =20 - addq $8,%rsp - popq %rcx # RIP - popq %r11 # CS - cmpw $FLAT_USER_CS32,%r11 - popq %r11 # RFLAGS - popq %rsp # RSP + cmpw $FLAT_USER_CS32,16(%rsp)# CS + movq 8(%rsp),%rcx # RIP + movq 24(%rsp),%r11 # RFLAGS + movq 32(%rsp),%rsp # RSP je 1f sysretq 1: sysretl @@ -101,8 +99,7 @@ failsafe_callback: ALIGN /* No special register assumptions. */ restore_all_xen: - RESTORE_ALL - addq $8,%rsp + RESTORE_ALL adj=3D8 iretq =20 /* @@ -311,8 +308,7 @@ ENTRY(int80_direct_trap) UNLIKELY_START(ne, msi_check) movl $0x80,%edi call check_for_unexpected_msi - RESTORE_ALL - SAVE_ALL + LOAD_C_CLOBBERED UNLIKELY_END(msi_check) =20 GET_CURRENT(%rbx) --- a/xen/include/asm-x86/x86_64/asm_defns.h +++ b/xen/include/asm-x86/x86_64/asm_defns.h @@ -5,11 +5,11 @@ =20 #ifdef CONFIG_FRAME_POINTER /* Indicate special exception stack frame by inverting the frame pointer. = */ -#define SETUP_EXCEPTION_FRAME_POINTER \ - movq %rsp,%rbp; \ +#define SETUP_EXCEPTION_FRAME_POINTER(offs) \ + leaq offs(%rsp),%rbp; \ notq %rbp #else -#define SETUP_EXCEPTION_FRAME_POINTER +#define SETUP_EXCEPTION_FRAME_POINTER(off) #endif =20 #ifndef NDEBUG @@ -27,40 +27,49 @@ #define ASSERT_INTERRUPTS_DISABLED ASSERT_INTERRUPT_STATUS(z) =20 #define SAVE_ALL \ + addq $-(UREGS_error_code-UREGS_r15), %rsp; \ cld; \ - pushq %rdi; \ - pushq %rsi; \ - pushq %rdx; \ - pushq %rcx; \ - pushq %rax; \ - pushq %r8; \ - pushq %r9; \ - pushq %r10; \ - pushq %r11; \ - pushq %rbx; \ - pushq %rbp; \ - SETUP_EXCEPTION_FRAME_POINTER; \ - pushq %r12; \ - pushq %r13; \ - pushq %r14; \ - pushq %r15; - -#define RESTORE_ALL \ - popq %r15; \ - popq %r14; \ - popq %r13; \ - popq %r12; \ - popq %rbp; \ - popq %rbx; \ - popq %r11; \ - popq %r10; \ - popq %r9; \ - popq %r8; \ - popq %rax; \ - popq %rcx; \ - popq %rdx; \ - popq %rsi; \ - popq %rdi; + movq %rdi,UREGS_rdi(%rsp); \ + movq %rsi,UREGS_rsi(%rsp); \ + movq %rdx,UREGS_rdx(%rsp); \ + movq %rcx,UREGS_rcx(%rsp); \ + movq %rax,UREGS_rax(%rsp); \ + movq %r8,UREGS_r8(%rsp); \ + movq %r9,UREGS_r9(%rsp); \ + movq %r10,UREGS_r10(%rsp); \ + movq %r11,UREGS_r11(%rsp); \ + movq %rbx,UREGS_rbx(%rsp); \ + movq %rbp,UREGS_rbp(%rsp); \ + SETUP_EXCEPTION_FRAME_POINTER(UREGS_rbp); \ + movq %r12,UREGS_r12(%rsp); \ + movq %r13,UREGS_r13(%rsp); \ + movq %r14,UREGS_r14(%rsp); \ + movq %r15,UREGS_r15(%rsp); \ + +#ifdef __ASSEMBLY__ +.macro LOAD_C_CLOBBERED + movq UREGS_r11(%rsp),%r11 + movq UREGS_r10(%rsp),%r10 + movq UREGS_r9(%rsp),%r9 + movq UREGS_r8(%rsp),%r8 + movq UREGS_rax(%rsp),%rax + movq UREGS_rcx(%rsp),%rcx + movq UREGS_rdx(%rsp),%rdx + movq UREGS_rsi(%rsp),%rsi + movq UREGS_rdi(%rsp),%rdi +.endm + +.macro RESTORE_ALL adj=3D0 + movq UREGS_r15(%rsp),%r15 + movq UREGS_r14(%rsp),%r14 + movq UREGS_r13(%rsp),%r13 + movq UREGS_r12(%rsp),%r12 + movq UREGS_rbp(%rsp),%rbp + movq UREGS_rbx(%rsp),%rbx + LOAD_C_CLOBBERED + subq $-(UREGS_error_code-UREGS_r15+\adj), %rsp +.endm +#endif =20 #ifdef PERF_COUNTERS #define PERFC_INCR(_name,_idx,_cur) \ @@ -94,7 +103,7 @@ __asm__( \ "\n" __ALIGN_STR"\n" \ "common_interrupt:\n\t" \ - STR(SAVE_ALL) \ + STR(SAVE_ALL) "\n\t" \ "movq %rsp,%rdi\n\t" \ "callq " STR(do_IRQ) "\n\t" \ "jmp ret_from_intr\n"); --=__PartDBEAED8F.0__= Content-Type: text/plain; name="x86-save-restore-all-mov.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="x86-save-restore-all-mov.patch" x86: use MOV instead of PUSH/POP when saving/restoring register state=0A=0A= Signed-off-by: Jan Beulich =0A=0A--- a/xen/arch/x86/x86_= 64/compat/entry.S=0A+++ b/xen/arch/x86/x86_64/compat/entry.S=0A@@ -21,8 = +21,7 @@ ENTRY(compat_hypercall)=0A UNLIKELY_START(ne, msi_check)=0A = movl $HYPERCALL_VECTOR,%edi=0A call check_for_unexpected_msi=0A= - RESTORE_ALL=0A- SAVE_ALL=0A+ LOAD_C_CLOBBERED=0A = UNLIKELY_END(msi_check)=0A =0A GET_CURRENT(%rbx)=0A@@ -173,8 = +172,7 @@ compat_bad_hypercall:=0A /* %rbx: struct vcpu, interrupts = disabled */=0A compat_restore_all_guest:=0A ASSERT_INTERRUPTS_DISAB= LED=0A- RESTORE_ALL=0A- addq $8,%rsp=0A+ RESTORE_ALL = adj=3D8=0A .Lft0: iretq=0A =0A .section .fixup,"ax"=0A--- a/xen/arch/x86/x= 86_64/entry.S=0A+++ b/xen/arch/x86/x86_64/entry.S=0A@@ -47,12 +47,10 @@ = restore_all_guest:=0A cmpl $1,%ecx=0A ja .Lforce_iret= =0A =0A- addq $8,%rsp=0A- popq %rcx # = RIP=0A- popq %r11 # CS=0A- cmpw = $FLAT_USER_CS32,%r11=0A- popq %r11 # RFLAGS=0A- = popq %rsp # RSP=0A+ cmpw $FLAT_USER_CS32= ,16(%rsp)# CS=0A+ movq 8(%rsp),%rcx # RIP=0A+ = movq 24(%rsp),%r11 # RFLAGS=0A+ movq 32(%rsp),%rsp = # RSP=0A je 1f=0A sysretq=0A 1: sysretl=0A@@ = -101,8 +99,7 @@ failsafe_callback:=0A ALIGN=0A /* No special = register assumptions. */=0A restore_all_xen:=0A- RESTORE_ALL=0A- = addq $8,%rsp=0A+ RESTORE_ALL adj=3D8=0A iretq=0A =0A = /*=0A@@ -311,8 +308,7 @@ ENTRY(int80_direct_trap)=0A UNLIKELY_START(ne, = msi_check)=0A movl $0x80,%edi=0A call check_for_unexpecte= d_msi=0A- RESTORE_ALL=0A- SAVE_ALL=0A+ LOAD_C_CLOBBERE= D=0A UNLIKELY_END(msi_check)=0A =0A GET_CURRENT(%rbx)=0A--- = a/xen/include/asm-x86/x86_64/asm_defns.h=0A+++ b/xen/include/asm-x86/x86_64= /asm_defns.h=0A@@ -5,11 +5,11 @@=0A =0A #ifdef CONFIG_FRAME_POINTER=0A /* = Indicate special exception stack frame by inverting the frame pointer. = */=0A-#define SETUP_EXCEPTION_FRAME_POINTER \=0A- movq = %rsp,%rbp; \=0A+#define SETUP_EXCEPTION_FRAME_POINTE= R(offs) \=0A+ leaq offs(%rsp),%rbp; \=0A = notq %rbp=0A #else=0A-#define SETUP_EXCEPTION_FRAME_POINTER=0A+#define = SETUP_EXCEPTION_FRAME_POINTER(off)=0A #endif=0A =0A #ifndef NDEBUG=0A@@ = -27,40 +27,49 @@=0A #define ASSERT_INTERRUPTS_DISABLED ASSERT_INTERRUPT_STA= TUS(z)=0A =0A #define SAVE_ALL \=0A+ = addq $-(UREGS_error_code-UREGS_r15), %rsp; \=0A cld; = \=0A- pushq %rdi; = \=0A- pushq %rsi; \=0A- pushq = %rdx; \=0A- pushq %rcx; = \=0A- pushq %rax; \=0A- = pushq %r8; \=0A- pushq %r9; = \=0A- pushq %r10; = \=0A- pushq %r11; \=0A- pushq = %rbx; \=0A- pushq %rbp; = \=0A- SETUP_EXCEPTION_FRAME_POINTER; \=0A- = pushq %r12; \=0A- pushq %r13; = \=0A- pushq %r14; = \=0A- pushq %r15;=0A-=0A-#define RESTORE_ALL = \=0A- popq %r15; \=0A- = popq %r14; \=0A- popq %r13; = \=0A- popq %r12; = \=0A- popq %rbp; \=0A- popq = %rbx; \=0A- popq %r11; = \=0A- popq %r10; \=0A- = popq %r9; \=0A- popq %r8; = \=0A- popq %rax; = \=0A- popq %rcx; \=0A- popq = %rdx; \=0A- popq %rsi; = \=0A- popq %rdi;=0A+ movq %rdi,UREGS_rdi(%rsp);= \=0A+ movq %rsi,UREGS_rsi(%rsp); \=0A+ = movq %rdx,UREGS_rdx(%rsp); \=0A+ movq %rcx,UREGS_r= cx(%rsp); \=0A+ movq %rax,UREGS_rax(%rsp); = \=0A+ movq %r8,UREGS_r8(%rsp); \=0A+ movq = %r9,UREGS_r9(%rsp); \=0A+ movq %r10,UREGS_r10(%rsp); = \=0A+ movq %r11,UREGS_r11(%rsp); \=0A+ = movq %rbx,UREGS_rbx(%rsp); \=0A+ movq %rbp,UREGS_rb= p(%rsp); \=0A+ SETUP_EXCEPTION_FRAME_POINTER(UREGS_rbp);= \=0A+ movq %r12,UREGS_r12(%rsp); \=0A+ movq = %r13,UREGS_r13(%rsp); \=0A+ movq %r14,UREGS_r14(%rsp); = \=0A+ movq %r15,UREGS_r15(%rsp); \=0A+=0A+#= ifdef __ASSEMBLY__=0A+.macro LOAD_C_CLOBBERED=0A+ movq UREGS_r11(%r= sp),%r11=0A+ movq UREGS_r10(%rsp),%r10=0A+ movq UREGS_r9(%r= sp),%r9=0A+ movq UREGS_r8(%rsp),%r8=0A+ movq UREGS_rax(%rsp= ),%rax=0A+ movq UREGS_rcx(%rsp),%rcx=0A+ movq UREGS_rdx(%rs= p),%rdx=0A+ movq UREGS_rsi(%rsp),%rsi=0A+ movq UREGS_rdi(%r= sp),%rdi=0A+.endm=0A+=0A+.macro RESTORE_ALL adj=3D0=0A+ movq = UREGS_r15(%rsp),%r15=0A+ movq UREGS_r14(%rsp),%r14=0A+ movq = UREGS_r13(%rsp),%r13=0A+ movq UREGS_r12(%rsp),%r12=0A+ = movq UREGS_rbp(%rsp),%rbp=0A+ movq UREGS_rbx(%rsp),%rbx=0A+ = LOAD_C_CLOBBERED=0A+ subq $-(UREGS_error_code-UREGS_r15+\adj), = %rsp=0A+.endm=0A+#endif=0A =0A #ifdef PERF_COUNTERS=0A #define PERFC_INCR(_= name,_idx,_cur) \=0A@@ -94,7 +103,7 @@=0A __asm__( = \=0A "\n" __ALIGN_STR"\n" = \=0A "common_interrupt:\n\t" \=0A- = STR(SAVE_ALL) \=0A+ STR(SAVE_ALL) "\n\t" = \=0A "movq %rsp,%rdi\n\t" = \=0A "callq " STR(do_IRQ) "\n\t" \=0A "jmp = ret_from_intr\n");=0A --=__PartDBEAED8F.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --=__PartDBEAED8F.0__=-- From xen-devel-bounces@lists.xen.org Tue Oct 02 15:27:06 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 15:27:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4N1-00033G-RA; Tue, 02 Oct 2012 15:26:51 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4Mz-00032z-Gu for xen-devel@lists.xen.org; Tue, 02 Oct 2012 15:26:49 +0000 Received: from [85.158.143.35:9232] by server-2.bemta-4.messagelabs.com id E0/E3-06610-8B70B605; Tue, 02 Oct 2012 15:26:48 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1349191585!12753274!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG, UPPERCASE_25_50 X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11334 invoked from network); 2 Oct 2012 15:26:32 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-12.tower-21.messagelabs.com with SMTP; 2 Oct 2012 15:26:32 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 02 Oct 2012 16:26:24 +0100 Message-Id: <506B23BF020000780009F29A@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Tue, 02 Oct 2012 16:26:23 +0100 From: "Jan Beulich" To: "xen-devel" References: <506B2268020000780009F273@nat28.tlf.novell.com> In-Reply-To: <506B2268020000780009F273@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__PartDBEAED8F.0__=" Subject: [Xen-devel] [PATCH 1/3] x86: use MOV instead of PUSH/POP when saving/restoring register state X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartDBEAED8F.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Signed-off-by: Jan Beulich --- a/xen/arch/x86/x86_64/compat/entry.S +++ b/xen/arch/x86/x86_64/compat/entry.S @@ -21,8 +21,7 @@ ENTRY(compat_hypercall) UNLIKELY_START(ne, msi_check) movl $HYPERCALL_VECTOR,%edi call check_for_unexpected_msi - RESTORE_ALL - SAVE_ALL + LOAD_C_CLOBBERED UNLIKELY_END(msi_check) =20 GET_CURRENT(%rbx) @@ -173,8 +172,7 @@ compat_bad_hypercall: /* %rbx: struct vcpu, interrupts disabled */ compat_restore_all_guest: ASSERT_INTERRUPTS_DISABLED - RESTORE_ALL - addq $8,%rsp + RESTORE_ALL adj=3D8 .Lft0: iretq =20 .section .fixup,"ax" --- a/xen/arch/x86/x86_64/entry.S +++ b/xen/arch/x86/x86_64/entry.S @@ -47,12 +47,10 @@ restore_all_guest: cmpl $1,%ecx ja .Lforce_iret =20 - addq $8,%rsp - popq %rcx # RIP - popq %r11 # CS - cmpw $FLAT_USER_CS32,%r11 - popq %r11 # RFLAGS - popq %rsp # RSP + cmpw $FLAT_USER_CS32,16(%rsp)# CS + movq 8(%rsp),%rcx # RIP + movq 24(%rsp),%r11 # RFLAGS + movq 32(%rsp),%rsp # RSP je 1f sysretq 1: sysretl @@ -101,8 +99,7 @@ failsafe_callback: ALIGN /* No special register assumptions. */ restore_all_xen: - RESTORE_ALL - addq $8,%rsp + RESTORE_ALL adj=3D8 iretq =20 /* @@ -311,8 +308,7 @@ ENTRY(int80_direct_trap) UNLIKELY_START(ne, msi_check) movl $0x80,%edi call check_for_unexpected_msi - RESTORE_ALL - SAVE_ALL + LOAD_C_CLOBBERED UNLIKELY_END(msi_check) =20 GET_CURRENT(%rbx) --- a/xen/include/asm-x86/x86_64/asm_defns.h +++ b/xen/include/asm-x86/x86_64/asm_defns.h @@ -5,11 +5,11 @@ =20 #ifdef CONFIG_FRAME_POINTER /* Indicate special exception stack frame by inverting the frame pointer. = */ -#define SETUP_EXCEPTION_FRAME_POINTER \ - movq %rsp,%rbp; \ +#define SETUP_EXCEPTION_FRAME_POINTER(offs) \ + leaq offs(%rsp),%rbp; \ notq %rbp #else -#define SETUP_EXCEPTION_FRAME_POINTER +#define SETUP_EXCEPTION_FRAME_POINTER(off) #endif =20 #ifndef NDEBUG @@ -27,40 +27,49 @@ #define ASSERT_INTERRUPTS_DISABLED ASSERT_INTERRUPT_STATUS(z) =20 #define SAVE_ALL \ + addq $-(UREGS_error_code-UREGS_r15), %rsp; \ cld; \ - pushq %rdi; \ - pushq %rsi; \ - pushq %rdx; \ - pushq %rcx; \ - pushq %rax; \ - pushq %r8; \ - pushq %r9; \ - pushq %r10; \ - pushq %r11; \ - pushq %rbx; \ - pushq %rbp; \ - SETUP_EXCEPTION_FRAME_POINTER; \ - pushq %r12; \ - pushq %r13; \ - pushq %r14; \ - pushq %r15; - -#define RESTORE_ALL \ - popq %r15; \ - popq %r14; \ - popq %r13; \ - popq %r12; \ - popq %rbp; \ - popq %rbx; \ - popq %r11; \ - popq %r10; \ - popq %r9; \ - popq %r8; \ - popq %rax; \ - popq %rcx; \ - popq %rdx; \ - popq %rsi; \ - popq %rdi; + movq %rdi,UREGS_rdi(%rsp); \ + movq %rsi,UREGS_rsi(%rsp); \ + movq %rdx,UREGS_rdx(%rsp); \ + movq %rcx,UREGS_rcx(%rsp); \ + movq %rax,UREGS_rax(%rsp); \ + movq %r8,UREGS_r8(%rsp); \ + movq %r9,UREGS_r9(%rsp); \ + movq %r10,UREGS_r10(%rsp); \ + movq %r11,UREGS_r11(%rsp); \ + movq %rbx,UREGS_rbx(%rsp); \ + movq %rbp,UREGS_rbp(%rsp); \ + SETUP_EXCEPTION_FRAME_POINTER(UREGS_rbp); \ + movq %r12,UREGS_r12(%rsp); \ + movq %r13,UREGS_r13(%rsp); \ + movq %r14,UREGS_r14(%rsp); \ + movq %r15,UREGS_r15(%rsp); \ + +#ifdef __ASSEMBLY__ +.macro LOAD_C_CLOBBERED + movq UREGS_r11(%rsp),%r11 + movq UREGS_r10(%rsp),%r10 + movq UREGS_r9(%rsp),%r9 + movq UREGS_r8(%rsp),%r8 + movq UREGS_rax(%rsp),%rax + movq UREGS_rcx(%rsp),%rcx + movq UREGS_rdx(%rsp),%rdx + movq UREGS_rsi(%rsp),%rsi + movq UREGS_rdi(%rsp),%rdi +.endm + +.macro RESTORE_ALL adj=3D0 + movq UREGS_r15(%rsp),%r15 + movq UREGS_r14(%rsp),%r14 + movq UREGS_r13(%rsp),%r13 + movq UREGS_r12(%rsp),%r12 + movq UREGS_rbp(%rsp),%rbp + movq UREGS_rbx(%rsp),%rbx + LOAD_C_CLOBBERED + subq $-(UREGS_error_code-UREGS_r15+\adj), %rsp +.endm +#endif =20 #ifdef PERF_COUNTERS #define PERFC_INCR(_name,_idx,_cur) \ @@ -94,7 +103,7 @@ __asm__( \ "\n" __ALIGN_STR"\n" \ "common_interrupt:\n\t" \ - STR(SAVE_ALL) \ + STR(SAVE_ALL) "\n\t" \ "movq %rsp,%rdi\n\t" \ "callq " STR(do_IRQ) "\n\t" \ "jmp ret_from_intr\n"); --=__PartDBEAED8F.0__= Content-Type: text/plain; name="x86-save-restore-all-mov.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="x86-save-restore-all-mov.patch" x86: use MOV instead of PUSH/POP when saving/restoring register state=0A=0A= Signed-off-by: Jan Beulich =0A=0A--- a/xen/arch/x86/x86_= 64/compat/entry.S=0A+++ b/xen/arch/x86/x86_64/compat/entry.S=0A@@ -21,8 = +21,7 @@ ENTRY(compat_hypercall)=0A UNLIKELY_START(ne, msi_check)=0A = movl $HYPERCALL_VECTOR,%edi=0A call check_for_unexpected_msi=0A= - RESTORE_ALL=0A- SAVE_ALL=0A+ LOAD_C_CLOBBERED=0A = UNLIKELY_END(msi_check)=0A =0A GET_CURRENT(%rbx)=0A@@ -173,8 = +172,7 @@ compat_bad_hypercall:=0A /* %rbx: struct vcpu, interrupts = disabled */=0A compat_restore_all_guest:=0A ASSERT_INTERRUPTS_DISAB= LED=0A- RESTORE_ALL=0A- addq $8,%rsp=0A+ RESTORE_ALL = adj=3D8=0A .Lft0: iretq=0A =0A .section .fixup,"ax"=0A--- a/xen/arch/x86/x= 86_64/entry.S=0A+++ b/xen/arch/x86/x86_64/entry.S=0A@@ -47,12 +47,10 @@ = restore_all_guest:=0A cmpl $1,%ecx=0A ja .Lforce_iret= =0A =0A- addq $8,%rsp=0A- popq %rcx # = RIP=0A- popq %r11 # CS=0A- cmpw = $FLAT_USER_CS32,%r11=0A- popq %r11 # RFLAGS=0A- = popq %rsp # RSP=0A+ cmpw $FLAT_USER_CS32= ,16(%rsp)# CS=0A+ movq 8(%rsp),%rcx # RIP=0A+ = movq 24(%rsp),%r11 # RFLAGS=0A+ movq 32(%rsp),%rsp = # RSP=0A je 1f=0A sysretq=0A 1: sysretl=0A@@ = -101,8 +99,7 @@ failsafe_callback:=0A ALIGN=0A /* No special = register assumptions. */=0A restore_all_xen:=0A- RESTORE_ALL=0A- = addq $8,%rsp=0A+ RESTORE_ALL adj=3D8=0A iretq=0A =0A = /*=0A@@ -311,8 +308,7 @@ ENTRY(int80_direct_trap)=0A UNLIKELY_START(ne, = msi_check)=0A movl $0x80,%edi=0A call check_for_unexpecte= d_msi=0A- RESTORE_ALL=0A- SAVE_ALL=0A+ LOAD_C_CLOBBERE= D=0A UNLIKELY_END(msi_check)=0A =0A GET_CURRENT(%rbx)=0A--- = a/xen/include/asm-x86/x86_64/asm_defns.h=0A+++ b/xen/include/asm-x86/x86_64= /asm_defns.h=0A@@ -5,11 +5,11 @@=0A =0A #ifdef CONFIG_FRAME_POINTER=0A /* = Indicate special exception stack frame by inverting the frame pointer. = */=0A-#define SETUP_EXCEPTION_FRAME_POINTER \=0A- movq = %rsp,%rbp; \=0A+#define SETUP_EXCEPTION_FRAME_POINTE= R(offs) \=0A+ leaq offs(%rsp),%rbp; \=0A = notq %rbp=0A #else=0A-#define SETUP_EXCEPTION_FRAME_POINTER=0A+#define = SETUP_EXCEPTION_FRAME_POINTER(off)=0A #endif=0A =0A #ifndef NDEBUG=0A@@ = -27,40 +27,49 @@=0A #define ASSERT_INTERRUPTS_DISABLED ASSERT_INTERRUPT_STA= TUS(z)=0A =0A #define SAVE_ALL \=0A+ = addq $-(UREGS_error_code-UREGS_r15), %rsp; \=0A cld; = \=0A- pushq %rdi; = \=0A- pushq %rsi; \=0A- pushq = %rdx; \=0A- pushq %rcx; = \=0A- pushq %rax; \=0A- = pushq %r8; \=0A- pushq %r9; = \=0A- pushq %r10; = \=0A- pushq %r11; \=0A- pushq = %rbx; \=0A- pushq %rbp; = \=0A- SETUP_EXCEPTION_FRAME_POINTER; \=0A- = pushq %r12; \=0A- pushq %r13; = \=0A- pushq %r14; = \=0A- pushq %r15;=0A-=0A-#define RESTORE_ALL = \=0A- popq %r15; \=0A- = popq %r14; \=0A- popq %r13; = \=0A- popq %r12; = \=0A- popq %rbp; \=0A- popq = %rbx; \=0A- popq %r11; = \=0A- popq %r10; \=0A- = popq %r9; \=0A- popq %r8; = \=0A- popq %rax; = \=0A- popq %rcx; \=0A- popq = %rdx; \=0A- popq %rsi; = \=0A- popq %rdi;=0A+ movq %rdi,UREGS_rdi(%rsp);= \=0A+ movq %rsi,UREGS_rsi(%rsp); \=0A+ = movq %rdx,UREGS_rdx(%rsp); \=0A+ movq %rcx,UREGS_r= cx(%rsp); \=0A+ movq %rax,UREGS_rax(%rsp); = \=0A+ movq %r8,UREGS_r8(%rsp); \=0A+ movq = %r9,UREGS_r9(%rsp); \=0A+ movq %r10,UREGS_r10(%rsp); = \=0A+ movq %r11,UREGS_r11(%rsp); \=0A+ = movq %rbx,UREGS_rbx(%rsp); \=0A+ movq %rbp,UREGS_rb= p(%rsp); \=0A+ SETUP_EXCEPTION_FRAME_POINTER(UREGS_rbp);= \=0A+ movq %r12,UREGS_r12(%rsp); \=0A+ movq = %r13,UREGS_r13(%rsp); \=0A+ movq %r14,UREGS_r14(%rsp); = \=0A+ movq %r15,UREGS_r15(%rsp); \=0A+=0A+#= ifdef __ASSEMBLY__=0A+.macro LOAD_C_CLOBBERED=0A+ movq UREGS_r11(%r= sp),%r11=0A+ movq UREGS_r10(%rsp),%r10=0A+ movq UREGS_r9(%r= sp),%r9=0A+ movq UREGS_r8(%rsp),%r8=0A+ movq UREGS_rax(%rsp= ),%rax=0A+ movq UREGS_rcx(%rsp),%rcx=0A+ movq UREGS_rdx(%rs= p),%rdx=0A+ movq UREGS_rsi(%rsp),%rsi=0A+ movq UREGS_rdi(%r= sp),%rdi=0A+.endm=0A+=0A+.macro RESTORE_ALL adj=3D0=0A+ movq = UREGS_r15(%rsp),%r15=0A+ movq UREGS_r14(%rsp),%r14=0A+ movq = UREGS_r13(%rsp),%r13=0A+ movq UREGS_r12(%rsp),%r12=0A+ = movq UREGS_rbp(%rsp),%rbp=0A+ movq UREGS_rbx(%rsp),%rbx=0A+ = LOAD_C_CLOBBERED=0A+ subq $-(UREGS_error_code-UREGS_r15+\adj), = %rsp=0A+.endm=0A+#endif=0A =0A #ifdef PERF_COUNTERS=0A #define PERFC_INCR(_= name,_idx,_cur) \=0A@@ -94,7 +103,7 @@=0A __asm__( = \=0A "\n" __ALIGN_STR"\n" = \=0A "common_interrupt:\n\t" \=0A- = STR(SAVE_ALL) \=0A+ STR(SAVE_ALL) "\n\t" = \=0A "movq %rsp,%rdi\n\t" = \=0A "callq " STR(do_IRQ) "\n\t" \=0A "jmp = ret_from_intr\n");=0A --=__PartDBEAED8F.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --=__PartDBEAED8F.0__=-- From xen-devel-bounces@lists.xen.org Tue Oct 02 15:27:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 15:27:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4Ng-00037h-Gz; Tue, 02 Oct 2012 15:27:32 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4Ne-00037Q-VJ for xen-devel@lists.xen.org; Tue, 02 Oct 2012 15:27:31 +0000 Received: from [85.158.143.35:58455] by server-2.bemta-4.messagelabs.com id 40/C4-06610-2E70B605; Tue, 02 Oct 2012 15:27:30 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1349191618!12089099!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8171 invoked from network); 2 Oct 2012 15:26:59 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-7.tower-21.messagelabs.com with SMTP; 2 Oct 2012 15:26:59 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 02 Oct 2012 16:26:58 +0100 Message-Id: <506B23DF020000780009F29E@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Tue, 02 Oct 2012 16:26:55 +0100 From: "Jan Beulich" To: "xen-devel" , "Jan Beulich" References: <506B2268020000780009F273@nat28.tlf.novell.com> In-Reply-To: <506B2268020000780009F273@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__PartFBCACDAF.0__=" Subject: [Xen-devel] [PATCH 2/3] x86: consolidate frame state manipulation functions X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartFBCACDAF.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Rather than doing this in multiple places, have a single central function (decode_register()) to be used by all other code. Signed-off-by: Jan Beulich --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -1585,7 +1585,7 @@ int hvm_mov_to_cr(unsigned int cr, unsig struct vcpu *curr =3D current; unsigned long val, *reg; =20 - if ( (reg =3D get_x86_gpr(guest_cpu_user_regs(), gpr)) =3D=3D NULL ) + if ( (reg =3D decode_register(gpr, guest_cpu_user_regs(), 0)) =3D=3D = NULL ) { gdprintk(XENLOG_ERR, "invalid gpr: %u\n", gpr); goto exit_and_crash; @@ -1627,7 +1627,7 @@ int hvm_mov_from_cr(unsigned int cr, uns struct vcpu *curr =3D current; unsigned long val =3D 0, *reg; =20 - if ( (reg =3D get_x86_gpr(guest_cpu_user_regs(), gpr)) =3D=3D NULL ) + if ( (reg =3D decode_register(gpr, guest_cpu_user_regs(), 0)) =3D=3D = NULL ) { gdprintk(XENLOG_ERR, "invalid gpr: %u\n", gpr); goto exit_and_crash; --- a/xen/arch/x86/hvm/vmx/vvmx.c +++ b/xen/arch/x86/hvm/vmx/vvmx.c @@ -223,56 +223,18 @@ void __set_vvmcs(void *vvmcs, u32 vmcs_e static unsigned long reg_read(struct cpu_user_regs *regs, enum vmx_regs_enc index) { - unsigned long value =3D 0; + unsigned long *pval =3D decode_register(index, regs, 0); =20 - switch ( index ) { - CASE_GET_REG(RAX, eax); - CASE_GET_REG(RCX, ecx); - CASE_GET_REG(RDX, edx); - CASE_GET_REG(RBX, ebx); - CASE_GET_REG(RBP, ebp); - CASE_GET_REG(RSI, esi); - CASE_GET_REG(RDI, edi); - CASE_GET_REG(RSP, esp); - CASE_GET_REG(R8, r8); - CASE_GET_REG(R9, r9); - CASE_GET_REG(R10, r10); - CASE_GET_REG(R11, r11); - CASE_GET_REG(R12, r12); - CASE_GET_REG(R13, r13); - CASE_GET_REG(R14, r14); - CASE_GET_REG(R15, r15); - default: - break; - } - - return value; + return *pval; } =20 static void reg_write(struct cpu_user_regs *regs, enum vmx_regs_enc index, unsigned long value) { - switch ( index ) { - CASE_SET_REG(RAX, eax); - CASE_SET_REG(RCX, ecx); - CASE_SET_REG(RDX, edx); - CASE_SET_REG(RBX, ebx); - CASE_SET_REG(RBP, ebp); - CASE_SET_REG(RSI, esi); - CASE_SET_REG(RDI, edi); - CASE_SET_REG(RSP, esp); - CASE_SET_REG(R8, r8); - CASE_SET_REG(R9, r9); - CASE_SET_REG(R10, r10); - CASE_SET_REG(R11, r11); - CASE_SET_REG(R12, r12); - CASE_SET_REG(R13, r13); - CASE_SET_REG(R14, r14); - CASE_SET_REG(R15, r15); - default: - break; - } + unsigned long *pval =3D decode_register(index, regs, 0); + + *pval =3D value; } =20 static inline u32 __n2_exec_control(struct vcpu *v) --- a/xen/arch/x86/traps.c +++ b/xen/arch/x86/traps.c @@ -367,34 +367,6 @@ void vcpu_show_execution_state(struct vc vcpu_unpause(v); } =20 -unsigned long *get_x86_gpr(struct cpu_user_regs *regs, unsigned int = modrm_reg) -{ - void *p; - - switch ( modrm_reg ) - { - case 0: p =3D ®s->eax; break; - case 1: p =3D ®s->ecx; break; - case 2: p =3D ®s->edx; break; - case 3: p =3D ®s->ebx; break; - case 4: p =3D ®s->esp; break; - case 5: p =3D ®s->ebp; break; - case 6: p =3D ®s->esi; break; - case 7: p =3D ®s->edi; break; - case 8: p =3D ®s->r8; break; - case 9: p =3D ®s->r9; break; - case 10: p =3D ®s->r10; break; - case 11: p =3D ®s->r11; break; - case 12: p =3D ®s->r12; break; - case 13: p =3D ®s->r13; break; - case 14: p =3D ®s->r14; break; - case 15: p =3D ®s->r15; break; - default: p =3D NULL; break; - } - - return p; -} - static char *trapstr(int trapnr) { static char *strings[] =3D {=20 --- a/xen/include/asm-x86/processor.h +++ b/xen/include/asm-x86/processor.h @@ -552,8 +552,6 @@ void microcode_set_module(unsigned int); int microcode_update(XEN_GUEST_HANDLE(const_void), unsigned long len); int microcode_resume_cpu(int cpu); =20 -unsigned long *get_x86_gpr(struct cpu_user_regs *regs, unsigned int = modrm_reg); - #endif /* !__ASSEMBLY__ */ =20 #endif /* __ASM_X86_PROCESSOR_H */ --=__PartFBCACDAF.0__= Content-Type: text/plain; name="x86-drop-get_x86_gpr.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="x86-drop-get_x86_gpr.patch" x86: consolidate frame state manipulation functions=0A=0ARather than doing = this in multiple places, have a single central=0Afunction (decode_register(= )) to be used by all other code.=0A=0ASigned-off-by: Jan Beulich =0A=0A--- a/xen/arch/x86/hvm/hvm.c=0A+++ b/xen/arch/x86/hvm/hvm.c= =0A@@ -1585,7 +1585,7 @@ int hvm_mov_to_cr(unsigned int cr, unsig=0A = struct vcpu *curr =3D current;=0A unsigned long val, *reg;=0A =0A- = if ( (reg =3D get_x86_gpr(guest_cpu_user_regs(), gpr)) =3D=3D NULL )=0A+ = if ( (reg =3D decode_register(gpr, guest_cpu_user_regs(), 0)) =3D=3D NULL = )=0A {=0A gdprintk(XENLOG_ERR, "invalid gpr: %u\n", gpr);=0A = goto exit_and_crash;=0A@@ -1627,7 +1627,7 @@ int hvm_mov_from_cr(unsi= gned int cr, uns=0A struct vcpu *curr =3D current;=0A unsigned = long val =3D 0, *reg;=0A =0A- if ( (reg =3D get_x86_gpr(guest_cpu_user_r= egs(), gpr)) =3D=3D NULL )=0A+ if ( (reg =3D decode_register(gpr, = guest_cpu_user_regs(), 0)) =3D=3D NULL )=0A {=0A gdprintk(XENLO= G_ERR, "invalid gpr: %u\n", gpr);=0A goto exit_and_crash;=0A--- = a/xen/arch/x86/hvm/vmx/vvmx.c=0A+++ b/xen/arch/x86/hvm/vmx/vvmx.c=0A@@ = -223,56 +223,18 @@ void __set_vvmcs(void *vvmcs, u32 vmcs_e=0A static = unsigned long reg_read(struct cpu_user_regs *regs,=0A = enum vmx_regs_enc index)=0A {=0A- unsigned long value =3D = 0;=0A+ unsigned long *pval =3D decode_register(index, regs, 0);=0A =0A- = switch ( index ) {=0A- CASE_GET_REG(RAX, eax);=0A- CASE_GET_REG(RC= X, ecx);=0A- CASE_GET_REG(RDX, edx);=0A- CASE_GET_REG(RBX, ebx);=0A- = CASE_GET_REG(RBP, ebp);=0A- CASE_GET_REG(RSI, esi);=0A- CASE_GET_R= EG(RDI, edi);=0A- CASE_GET_REG(RSP, esp);=0A- CASE_GET_REG(R8, = r8);=0A- CASE_GET_REG(R9, r9);=0A- CASE_GET_REG(R10, r10);=0A- = CASE_GET_REG(R11, r11);=0A- CASE_GET_REG(R12, r12);=0A- CASE_GET_REG(= R13, r13);=0A- CASE_GET_REG(R14, r14);=0A- CASE_GET_REG(R15, = r15);=0A- default:=0A- break;=0A- }=0A-=0A- return = value;=0A+ return *pval;=0A }=0A =0A static void reg_write(struct = cpu_user_regs *regs,=0A enum vmx_regs_enc index,=0A = unsigned long value)=0A {=0A- switch ( index ) = {=0A- CASE_SET_REG(RAX, eax);=0A- CASE_SET_REG(RCX, ecx);=0A- = CASE_SET_REG(RDX, edx);=0A- CASE_SET_REG(RBX, ebx);=0A- CASE_SET_REG(= RBP, ebp);=0A- CASE_SET_REG(RSI, esi);=0A- CASE_SET_REG(RDI, = edi);=0A- CASE_SET_REG(RSP, esp);=0A- CASE_SET_REG(R8, r8);=0A- = CASE_SET_REG(R9, r9);=0A- CASE_SET_REG(R10, r10);=0A- CASE_SET_REG(R1= 1, r11);=0A- CASE_SET_REG(R12, r12);=0A- CASE_SET_REG(R13, r13);=0A- = CASE_SET_REG(R14, r14);=0A- CASE_SET_REG(R15, r15);=0A- = default:=0A- break;=0A- }=0A+ unsigned long *pval =3D = decode_register(index, regs, 0);=0A+=0A+ *pval =3D value;=0A }=0A =0A = static inline u32 __n2_exec_control(struct vcpu *v)=0A--- a/xen/arch/x86/tr= aps.c=0A+++ b/xen/arch/x86/traps.c=0A@@ -367,34 +367,6 @@ void vcpu_show_ex= ecution_state(struct vc=0A vcpu_unpause(v);=0A }=0A =0A-unsigned long = *get_x86_gpr(struct cpu_user_regs *regs, unsigned int modrm_reg)=0A-{=0A- = void *p;=0A-=0A- switch ( modrm_reg )=0A- {=0A- case 0: p =3D = ®s->eax; break;=0A- case 1: p =3D ®s->ecx; break;=0A- case = 2: p =3D ®s->edx; break;=0A- case 3: p =3D ®s->ebx; break;=0A- = case 4: p =3D ®s->esp; break;=0A- case 5: p =3D ®s->ebp; = break;=0A- case 6: p =3D ®s->esi; break;=0A- case 7: p =3D = ®s->edi; break;=0A- case 8: p =3D ®s->r8; break;=0A- case = 9: p =3D ®s->r9; break;=0A- case 10: p =3D ®s->r10; break;=0A- = case 11: p =3D ®s->r11; break;=0A- case 12: p =3D ®s->r12; = break;=0A- case 13: p =3D ®s->r13; break;=0A- case 14: p =3D = ®s->r14; break;=0A- case 15: p =3D ®s->r15; break;=0A- = default: p =3D NULL; break;=0A- }=0A-=0A- return p;=0A-}=0A-=0A = static char *trapstr(int trapnr)=0A {=0A static char *strings[] =3D { = =0A--- a/xen/include/asm-x86/processor.h=0A+++ b/xen/include/asm-x86/proces= sor.h=0A@@ -552,8 +552,6 @@ void microcode_set_module(unsigned int);=0A = int microcode_update(XEN_GUEST_HANDLE(const_void), unsigned long len);=0A = int microcode_resume_cpu(int cpu);=0A =0A-unsigned long *get_x86_gpr(struct= cpu_user_regs *regs, unsigned int modrm_reg);=0A-=0A #endif /* !__ASSEMBLY= __ */=0A =0A #endif /* __ASM_X86_PROCESSOR_H */=0A --=__PartFBCACDAF.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --=__PartFBCACDAF.0__=-- From xen-devel-bounces@lists.xen.org Tue Oct 02 15:27:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 15:27:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4Ng-00037h-Gz; Tue, 02 Oct 2012 15:27:32 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4Ne-00037Q-VJ for xen-devel@lists.xen.org; Tue, 02 Oct 2012 15:27:31 +0000 Received: from [85.158.143.35:58455] by server-2.bemta-4.messagelabs.com id 40/C4-06610-2E70B605; Tue, 02 Oct 2012 15:27:30 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1349191618!12089099!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8171 invoked from network); 2 Oct 2012 15:26:59 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-7.tower-21.messagelabs.com with SMTP; 2 Oct 2012 15:26:59 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 02 Oct 2012 16:26:58 +0100 Message-Id: <506B23DF020000780009F29E@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Tue, 02 Oct 2012 16:26:55 +0100 From: "Jan Beulich" To: "xen-devel" , "Jan Beulich" References: <506B2268020000780009F273@nat28.tlf.novell.com> In-Reply-To: <506B2268020000780009F273@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__PartFBCACDAF.0__=" Subject: [Xen-devel] [PATCH 2/3] x86: consolidate frame state manipulation functions X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartFBCACDAF.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Rather than doing this in multiple places, have a single central function (decode_register()) to be used by all other code. Signed-off-by: Jan Beulich --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -1585,7 +1585,7 @@ int hvm_mov_to_cr(unsigned int cr, unsig struct vcpu *curr =3D current; unsigned long val, *reg; =20 - if ( (reg =3D get_x86_gpr(guest_cpu_user_regs(), gpr)) =3D=3D NULL ) + if ( (reg =3D decode_register(gpr, guest_cpu_user_regs(), 0)) =3D=3D = NULL ) { gdprintk(XENLOG_ERR, "invalid gpr: %u\n", gpr); goto exit_and_crash; @@ -1627,7 +1627,7 @@ int hvm_mov_from_cr(unsigned int cr, uns struct vcpu *curr =3D current; unsigned long val =3D 0, *reg; =20 - if ( (reg =3D get_x86_gpr(guest_cpu_user_regs(), gpr)) =3D=3D NULL ) + if ( (reg =3D decode_register(gpr, guest_cpu_user_regs(), 0)) =3D=3D = NULL ) { gdprintk(XENLOG_ERR, "invalid gpr: %u\n", gpr); goto exit_and_crash; --- a/xen/arch/x86/hvm/vmx/vvmx.c +++ b/xen/arch/x86/hvm/vmx/vvmx.c @@ -223,56 +223,18 @@ void __set_vvmcs(void *vvmcs, u32 vmcs_e static unsigned long reg_read(struct cpu_user_regs *regs, enum vmx_regs_enc index) { - unsigned long value =3D 0; + unsigned long *pval =3D decode_register(index, regs, 0); =20 - switch ( index ) { - CASE_GET_REG(RAX, eax); - CASE_GET_REG(RCX, ecx); - CASE_GET_REG(RDX, edx); - CASE_GET_REG(RBX, ebx); - CASE_GET_REG(RBP, ebp); - CASE_GET_REG(RSI, esi); - CASE_GET_REG(RDI, edi); - CASE_GET_REG(RSP, esp); - CASE_GET_REG(R8, r8); - CASE_GET_REG(R9, r9); - CASE_GET_REG(R10, r10); - CASE_GET_REG(R11, r11); - CASE_GET_REG(R12, r12); - CASE_GET_REG(R13, r13); - CASE_GET_REG(R14, r14); - CASE_GET_REG(R15, r15); - default: - break; - } - - return value; + return *pval; } =20 static void reg_write(struct cpu_user_regs *regs, enum vmx_regs_enc index, unsigned long value) { - switch ( index ) { - CASE_SET_REG(RAX, eax); - CASE_SET_REG(RCX, ecx); - CASE_SET_REG(RDX, edx); - CASE_SET_REG(RBX, ebx); - CASE_SET_REG(RBP, ebp); - CASE_SET_REG(RSI, esi); - CASE_SET_REG(RDI, edi); - CASE_SET_REG(RSP, esp); - CASE_SET_REG(R8, r8); - CASE_SET_REG(R9, r9); - CASE_SET_REG(R10, r10); - CASE_SET_REG(R11, r11); - CASE_SET_REG(R12, r12); - CASE_SET_REG(R13, r13); - CASE_SET_REG(R14, r14); - CASE_SET_REG(R15, r15); - default: - break; - } + unsigned long *pval =3D decode_register(index, regs, 0); + + *pval =3D value; } =20 static inline u32 __n2_exec_control(struct vcpu *v) --- a/xen/arch/x86/traps.c +++ b/xen/arch/x86/traps.c @@ -367,34 +367,6 @@ void vcpu_show_execution_state(struct vc vcpu_unpause(v); } =20 -unsigned long *get_x86_gpr(struct cpu_user_regs *regs, unsigned int = modrm_reg) -{ - void *p; - - switch ( modrm_reg ) - { - case 0: p =3D ®s->eax; break; - case 1: p =3D ®s->ecx; break; - case 2: p =3D ®s->edx; break; - case 3: p =3D ®s->ebx; break; - case 4: p =3D ®s->esp; break; - case 5: p =3D ®s->ebp; break; - case 6: p =3D ®s->esi; break; - case 7: p =3D ®s->edi; break; - case 8: p =3D ®s->r8; break; - case 9: p =3D ®s->r9; break; - case 10: p =3D ®s->r10; break; - case 11: p =3D ®s->r11; break; - case 12: p =3D ®s->r12; break; - case 13: p =3D ®s->r13; break; - case 14: p =3D ®s->r14; break; - case 15: p =3D ®s->r15; break; - default: p =3D NULL; break; - } - - return p; -} - static char *trapstr(int trapnr) { static char *strings[] =3D {=20 --- a/xen/include/asm-x86/processor.h +++ b/xen/include/asm-x86/processor.h @@ -552,8 +552,6 @@ void microcode_set_module(unsigned int); int microcode_update(XEN_GUEST_HANDLE(const_void), unsigned long len); int microcode_resume_cpu(int cpu); =20 -unsigned long *get_x86_gpr(struct cpu_user_regs *regs, unsigned int = modrm_reg); - #endif /* !__ASSEMBLY__ */ =20 #endif /* __ASM_X86_PROCESSOR_H */ --=__PartFBCACDAF.0__= Content-Type: text/plain; name="x86-drop-get_x86_gpr.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="x86-drop-get_x86_gpr.patch" x86: consolidate frame state manipulation functions=0A=0ARather than doing = this in multiple places, have a single central=0Afunction (decode_register(= )) to be used by all other code.=0A=0ASigned-off-by: Jan Beulich =0A=0A--- a/xen/arch/x86/hvm/hvm.c=0A+++ b/xen/arch/x86/hvm/hvm.c= =0A@@ -1585,7 +1585,7 @@ int hvm_mov_to_cr(unsigned int cr, unsig=0A = struct vcpu *curr =3D current;=0A unsigned long val, *reg;=0A =0A- = if ( (reg =3D get_x86_gpr(guest_cpu_user_regs(), gpr)) =3D=3D NULL )=0A+ = if ( (reg =3D decode_register(gpr, guest_cpu_user_regs(), 0)) =3D=3D NULL = )=0A {=0A gdprintk(XENLOG_ERR, "invalid gpr: %u\n", gpr);=0A = goto exit_and_crash;=0A@@ -1627,7 +1627,7 @@ int hvm_mov_from_cr(unsi= gned int cr, uns=0A struct vcpu *curr =3D current;=0A unsigned = long val =3D 0, *reg;=0A =0A- if ( (reg =3D get_x86_gpr(guest_cpu_user_r= egs(), gpr)) =3D=3D NULL )=0A+ if ( (reg =3D decode_register(gpr, = guest_cpu_user_regs(), 0)) =3D=3D NULL )=0A {=0A gdprintk(XENLO= G_ERR, "invalid gpr: %u\n", gpr);=0A goto exit_and_crash;=0A--- = a/xen/arch/x86/hvm/vmx/vvmx.c=0A+++ b/xen/arch/x86/hvm/vmx/vvmx.c=0A@@ = -223,56 +223,18 @@ void __set_vvmcs(void *vvmcs, u32 vmcs_e=0A static = unsigned long reg_read(struct cpu_user_regs *regs,=0A = enum vmx_regs_enc index)=0A {=0A- unsigned long value =3D = 0;=0A+ unsigned long *pval =3D decode_register(index, regs, 0);=0A =0A- = switch ( index ) {=0A- CASE_GET_REG(RAX, eax);=0A- CASE_GET_REG(RC= X, ecx);=0A- CASE_GET_REG(RDX, edx);=0A- CASE_GET_REG(RBX, ebx);=0A- = CASE_GET_REG(RBP, ebp);=0A- CASE_GET_REG(RSI, esi);=0A- CASE_GET_R= EG(RDI, edi);=0A- CASE_GET_REG(RSP, esp);=0A- CASE_GET_REG(R8, = r8);=0A- CASE_GET_REG(R9, r9);=0A- CASE_GET_REG(R10, r10);=0A- = CASE_GET_REG(R11, r11);=0A- CASE_GET_REG(R12, r12);=0A- CASE_GET_REG(= R13, r13);=0A- CASE_GET_REG(R14, r14);=0A- CASE_GET_REG(R15, = r15);=0A- default:=0A- break;=0A- }=0A-=0A- return = value;=0A+ return *pval;=0A }=0A =0A static void reg_write(struct = cpu_user_regs *regs,=0A enum vmx_regs_enc index,=0A = unsigned long value)=0A {=0A- switch ( index ) = {=0A- CASE_SET_REG(RAX, eax);=0A- CASE_SET_REG(RCX, ecx);=0A- = CASE_SET_REG(RDX, edx);=0A- CASE_SET_REG(RBX, ebx);=0A- CASE_SET_REG(= RBP, ebp);=0A- CASE_SET_REG(RSI, esi);=0A- CASE_SET_REG(RDI, = edi);=0A- CASE_SET_REG(RSP, esp);=0A- CASE_SET_REG(R8, r8);=0A- = CASE_SET_REG(R9, r9);=0A- CASE_SET_REG(R10, r10);=0A- CASE_SET_REG(R1= 1, r11);=0A- CASE_SET_REG(R12, r12);=0A- CASE_SET_REG(R13, r13);=0A- = CASE_SET_REG(R14, r14);=0A- CASE_SET_REG(R15, r15);=0A- = default:=0A- break;=0A- }=0A+ unsigned long *pval =3D = decode_register(index, regs, 0);=0A+=0A+ *pval =3D value;=0A }=0A =0A = static inline u32 __n2_exec_control(struct vcpu *v)=0A--- a/xen/arch/x86/tr= aps.c=0A+++ b/xen/arch/x86/traps.c=0A@@ -367,34 +367,6 @@ void vcpu_show_ex= ecution_state(struct vc=0A vcpu_unpause(v);=0A }=0A =0A-unsigned long = *get_x86_gpr(struct cpu_user_regs *regs, unsigned int modrm_reg)=0A-{=0A- = void *p;=0A-=0A- switch ( modrm_reg )=0A- {=0A- case 0: p =3D = ®s->eax; break;=0A- case 1: p =3D ®s->ecx; break;=0A- case = 2: p =3D ®s->edx; break;=0A- case 3: p =3D ®s->ebx; break;=0A- = case 4: p =3D ®s->esp; break;=0A- case 5: p =3D ®s->ebp; = break;=0A- case 6: p =3D ®s->esi; break;=0A- case 7: p =3D = ®s->edi; break;=0A- case 8: p =3D ®s->r8; break;=0A- case = 9: p =3D ®s->r9; break;=0A- case 10: p =3D ®s->r10; break;=0A- = case 11: p =3D ®s->r11; break;=0A- case 12: p =3D ®s->r12; = break;=0A- case 13: p =3D ®s->r13; break;=0A- case 14: p =3D = ®s->r14; break;=0A- case 15: p =3D ®s->r15; break;=0A- = default: p =3D NULL; break;=0A- }=0A-=0A- return p;=0A-}=0A-=0A = static char *trapstr(int trapnr)=0A {=0A static char *strings[] =3D { = =0A--- a/xen/include/asm-x86/processor.h=0A+++ b/xen/include/asm-x86/proces= sor.h=0A@@ -552,8 +552,6 @@ void microcode_set_module(unsigned int);=0A = int microcode_update(XEN_GUEST_HANDLE(const_void), unsigned long len);=0A = int microcode_resume_cpu(int cpu);=0A =0A-unsigned long *get_x86_gpr(struct= cpu_user_regs *regs, unsigned int modrm_reg);=0A-=0A #endif /* !__ASSEMBLY= __ */=0A =0A #endif /* __ASM_X86_PROCESSOR_H */=0A --=__PartFBCACDAF.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --=__PartFBCACDAF.0__=-- From xen-devel-bounces@lists.xen.org Tue Oct 02 15:28:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 15:28:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4O0-0003B9-UK; Tue, 02 Oct 2012 15:27:52 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4Nz-0003Ah-Hg for xen-devel@lists.xen.org; Tue, 02 Oct 2012 15:27:51 +0000 Received: from [85.158.143.35:59652] by server-3.bemta-4.messagelabs.com id 91/A4-10986-6F70B605; Tue, 02 Oct 2012 15:27:50 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1349191668!6276185!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25884 invoked from network); 2 Oct 2012 15:27:48 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-4.tower-21.messagelabs.com with SMTP; 2 Oct 2012 15:27:48 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 02 Oct 2012 16:27:46 +0100 Message-Id: <506B2410020000780009F2A3@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Tue, 02 Oct 2012 16:27:44 +0100 From: "Jan Beulich" To: "xen-devel" References: <506B2268020000780009F273@nat28.tlf.novell.com> In-Reply-To: <506B2268020000780009F273@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__PartB48582E0.0__=" Subject: [Xen-devel] [PATCH 3/3] x86: save/restore only partial register state where possible X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartB48582E0.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline ... and make restore conditional not only upon having saved the state, but also upon whether saved state was actually modified (and register values are known to have been preserved). Note that RBP is unconditionally considered a volatile register (i.e. irrespective of CONFIG_FRAME_POINTER), since the RBP handling would become overly complicated due to the need to save/restore it on the compat mode hypercall path [6th argument]. Note further that for compat mode code paths, saving/restoring R8...R15 is entirely unnecessary - we don't allow those guests to enter 64-bit mode, and hence they have no way of seeing these registers' contents (and there consequently also is no information leak, except if the context saving domctl would be considered such). Finally, note that this may not properly deal with gdbstub's needs, yet (but if so, I can't really suggest adjustments, as I don't know that code). Signed-off-by: Jan Beulich --- a/tools/tests/x86_emulator/x86_emulate.c +++ b/tools/tests/x86_emulator/x86_emulate.c @@ -10,6 +10,7 @@ typedef bool bool_t; #define BUG() abort() =20 #define cpu_has_amd_erratum(nr) 0 +#define mark_regs_dirty(r) ((void)(r)) =20 #include "x86_emulate/x86_emulate.h" #include "x86_emulate/x86_emulate.c" --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -138,6 +138,7 @@ static void continue_idle_domain(struct=20 static void continue_nonidle_domain(struct vcpu *v) { check_wakeup_from_wait(); + mark_regs_dirty(guest_cpu_user_regs()); reset_stack_and_jump(ret_from_intr); } =20 @@ -1307,7 +1308,7 @@ static void load_segments(struct vcpu *n if ( test_bit(_VGCF_failsafe_disables_events, &n->arch.vgc_fla= gs) ) vcpu_info(n, evtchn_upcall_mask) =3D 1; =20 - regs->entry_vector =3D TRAP_syscall; + regs->entry_vector |=3D TRAP_syscall; regs->_eflags &=3D 0xFFFCBEFFUL; regs->ss =3D FLAT_COMPAT_KERNEL_SS; regs->_esp =3D (unsigned long)(esp-7); @@ -1349,7 +1350,7 @@ static void load_segments(struct vcpu *n if ( test_bit(_VGCF_failsafe_disables_events, &n->arch.vgc_flags) = ) vcpu_info(n, evtchn_upcall_mask) =3D 1; =20 - regs->entry_vector =3D TRAP_syscall; + regs->entry_vector |=3D TRAP_syscall; regs->rflags &=3D ~(X86_EFLAGS_AC|X86_EFLAGS_VM|X86_EFLAGS_R= F| X86_EFLAGS_NT|X86_EFLAGS_TF); regs->ss =3D FLAT_KERNEL_SS; --- a/xen/arch/x86/irq.c +++ b/xen/arch/x86/irq.c @@ -704,7 +704,7 @@ void irq_complete_move(struct irq_desc * if (likely(!desc->arch.move_in_progress)) return; =20 - vector =3D get_irq_regs()->entry_vector; + vector =3D (u8)get_irq_regs()->entry_vector; me =3D smp_processor_id(); =20 if ( vector =3D=3D desc->arch.vector && @@ -798,7 +798,7 @@ void do_IRQ(struct cpu_user_regs *regs) struct irqaction *action; uint32_t tsc_in; struct irq_desc *desc; - unsigned int vector =3D regs->entry_vector; + unsigned int vector =3D (u8)regs->entry_vector; int irq =3D __get_cpu_var(vector_irq[vector]); struct cpu_user_regs *old_regs =3D set_irq_regs(regs); =20 @@ -892,7 +892,7 @@ void do_IRQ(struct cpu_user_regs *regs) =20 out: if ( desc->handler->end ) - desc->handler->end(desc, regs->entry_vector); + desc->handler->end(desc, vector); out_no_end: spin_unlock(&desc->lock); out_no_unlock: @@ -1113,7 +1113,7 @@ static void __do_IRQ_guest(int irq) struct domain *d; int i, sp; struct pending_eoi *peoi =3D this_cpu(pending_eoi); - int vector =3D get_irq_regs()->entry_vector; + unsigned int vector =3D (u8)get_irq_regs()->entry_vector; =20 if ( unlikely(action->nr_guests =3D=3D 0) ) { --- a/xen/arch/x86/traps.c +++ b/xen/arch/x86/traps.c @@ -2082,6 +2082,7 @@ static int emulate_privileged_op(struct=20 goto fail; if ( admin_io_okay(port, op_bytes, v, regs) ) { + mark_regs_dirty(regs); io_emul(regs); =20 } else @@ -2111,6 +2112,7 @@ static int emulate_privileged_op(struct=20 goto fail; if ( admin_io_okay(port, op_bytes, v, regs) ) { + mark_regs_dirty(regs); io_emul(regs); =20 if ( (op_bytes =3D=3D 1) && pv_post_outb_hook ) pv_post_outb_hook(port, regs->eax); --- a/xen/arch/x86/x86_64/compat/entry.S +++ b/xen/arch/x86/x86_64/compat/entry.S @@ -14,8 +14,7 @@ =20 ENTRY(compat_hypercall) pushq $0 - movl $TRAP_syscall,4(%rsp) - SAVE_ALL + SAVE_VOLATILE type=3DTRAP_syscall compat=3D1 =20 cmpb $0,untrusted_msi(%rip) UNLIKELY_START(ne, msi_check) @@ -126,6 +125,7 @@ compat_test_guest_events: /* %rbx: struct vcpu */ compat_process_softirqs: sti + andl $~TRAP_regs_partial,UREGS_entry_vector(%rsp) call do_softirq jmp compat_test_all_events =20 @@ -172,7 +172,7 @@ compat_bad_hypercall: /* %rbx: struct vcpu, interrupts disabled */ compat_restore_all_guest: ASSERT_INTERRUPTS_DISABLED - RESTORE_ALL adj=3D8 + RESTORE_ALL adj=3D8 compat=3D1 .Lft0: iretq =20 .section .fixup,"ax" @@ -243,7 +243,7 @@ UNLIKELY_END(compat_syscall_gpf) =20 ENTRY(compat_sysenter) movq VCPU_trap_ctxt(%rbx),%rcx - cmpl $TRAP_gp_fault,UREGS_entry_vector(%rsp) + cmpb $TRAP_gp_fault,UREGS_entry_vector(%rsp) movzwl VCPU_sysenter_sel(%rbx),%eax movzwl TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_cs(%rcx),%ecx cmovel %ecx,%eax --- a/xen/arch/x86/x86_64/entry.S +++ b/xen/arch/x86/x86_64/entry.S @@ -123,9 +123,8 @@ ENTRY(syscall_enter) movl $FLAT_KERNEL_SS,24(%rsp) pushq %rcx pushq $0 - movl $TRAP_syscall,4(%rsp) - movq 24(%rsp),%r11 /* Re-load user RFLAGS into %r11 before = SAVE_ALL */ - SAVE_ALL + movq 24(%rsp),%r11 /* Re-load user RFLAGS into %r11 before = saving */ + SAVE_VOLATILE TRAP_syscall GET_CURRENT(%rbx) movq VCPU_domain(%rbx),%rcx testb $1,DOMAIN_is_32bit_pv(%rcx) @@ -222,6 +221,7 @@ test_guest_events: /* %rbx: struct vcpu */ process_softirqs: sti =20 + SAVE_PRESERVED call do_softirq jmp test_all_events =20 @@ -275,8 +275,7 @@ sysenter_eflags_saved: pushq $3 /* ring 3 null cs */ pushq $0 /* null rip */ pushq $0 - movl $TRAP_syscall,4(%rsp) - SAVE_ALL + SAVE_VOLATILE TRAP_syscall GET_CURRENT(%rbx) cmpb $0,VCPU_sysenter_disables_events(%rbx) movq VCPU_sysenter_addr(%rbx),%rax @@ -286,6 +285,7 @@ sysenter_eflags_saved: leal (,%rcx,TBF_INTERRUPT),%ecx UNLIKELY_START(z, sysenter_gpf) movq VCPU_trap_ctxt(%rbx),%rsi + SAVE_PRESERVED movl $TRAP_gp_fault,UREGS_entry_vector(%rsp) movl %eax,TRAPBOUNCE_error_code(%rdx) movq TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_eip(%rsi),%rax @@ -302,7 +302,7 @@ UNLIKELY_END(sysenter_gpf) =20 ENTRY(int80_direct_trap) pushq $0 - SAVE_ALL + SAVE_VOLATILE 0x80 =20 cmpb $0,untrusted_msi(%rip) UNLIKELY_START(ne, msi_check) @@ -331,6 +331,7 @@ int80_slow_path: * IDT entry with DPL=3D=3D0. */ movl $((0x80 << 3) | 0x2),UREGS_error_code(%rsp) + SAVE_PRESERVED movl $TRAP_gp_fault,UREGS_entry_vector(%rsp) /* A GPF wouldn't have incremented the instruction pointer. */ subq $2,UREGS_rip(%rsp) @@ -412,7 +413,7 @@ UNLIKELY_END(bounce_failsafe) /* Rewrite our stack frame and return to guest-OS mode. */ /* IA32 Ref. Vol. 3: TF, VM, RF and NT flags are cleared on trap. = */ /* Also clear AC: alignment checks shouldn't trigger in kernel = mode. */ - movl $TRAP_syscall,UREGS_entry_vector+8(%rsp) + orl $TRAP_syscall,UREGS_entry_vector+8(%rsp) andl $~(X86_EFLAGS_AC|X86_EFLAGS_VM|X86_EFLAGS_RF|\ X86_EFLAGS_NT|X86_EFLAGS_TF),UREGS_eflags+8(%rsp) movq $FLAT_KERNEL_SS,UREGS_ss+8(%rsp) @@ -477,7 +478,7 @@ handle_exception_saved: jz exception_with_ints_disabled sti 1: movq %rsp,%rdi - movl UREGS_entry_vector(%rsp),%eax + movzbl UREGS_entry_vector(%rsp),%eax leaq exception_table(%rip),%rdx GET_CURRENT(%rbx) PERFC_INCR(exceptions, %rax, %rbx) @@ -518,7 +519,7 @@ exception_with_ints_disabled: =20 /* No special register assumptions. */ FATAL_exception_with_ints_disabled: - movl UREGS_entry_vector(%rsp),%edi + movzbl UREGS_entry_vector(%rsp),%edi movq %rsp,%rsi call fatal_trap ud2 @@ -624,7 +625,7 @@ handle_ist_exception: movq %rdi,%rsp rep movsq 1: movq %rsp,%rdi - movl UREGS_entry_vector(%rsp),%eax + movzbl UREGS_entry_vector(%rsp),%eax leaq exception_table(%rip),%rdx callq *(%rdx,%rax,8) jmp ret_from_intr --- a/xen/arch/x86/x86_64/traps.c +++ b/xen/arch/x86/x86_64/traps.c @@ -67,10 +67,15 @@ static void _show_registers( regs->rbp, regs->rsp, regs->r8); printk("r9: %016lx r10: %016lx r11: %016lx\n", regs->r9, regs->r10, regs->r11); - printk("r12: %016lx r13: %016lx r14: %016lx\n", - regs->r12, regs->r13, regs->r14); - printk("r15: %016lx cr0: %016lx cr4: %016lx\n", - regs->r15, crs[0], crs[4]); + if ( !(regs->entry_vector & TRAP_regs_partial) ) + { + printk("r12: %016lx r13: %016lx r14: %016lx\n", + regs->r12, regs->r13, regs->r14); + printk("r15: %016lx cr0: %016lx cr4: %016lx\n", + regs->r15, crs[0], crs[4]); + } + else + printk("cr0: %016lx cr4: %016lx\n", crs[0], crs[4]); printk("cr3: %016lx cr2: %016lx\n", crs[3], crs[2]); printk("ds: %04x es: %04x fs: %04x gs: %04x " "ss: %04x cs: %04x\n", @@ -301,7 +306,7 @@ unsigned long do_iret(void) =20 if ( !(iret_saved.flags & VGCF_in_syscall) ) { - regs->entry_vector =3D 0; + regs->entry_vector &=3D ~TRAP_syscall; regs->r11 =3D iret_saved.r11; regs->rcx =3D iret_saved.rcx; } --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++ b/xen/arch/x86/x86_emulate/x86_emulate.c @@ -1292,10 +1292,10 @@ decode_register( case 9: p =3D ®s->r9; break; case 10: p =3D ®s->r10; break; case 11: p =3D ®s->r11; break; - case 12: p =3D ®s->r12; break; - case 13: p =3D ®s->r13; break; - case 14: p =3D ®s->r14; break; - case 15: p =3D ®s->r15; break; + case 12: mark_regs_dirty(regs); p =3D ®s->r12; break; + case 13: mark_regs_dirty(regs); p =3D ®s->r13; break; + case 14: mark_regs_dirty(regs); p =3D ®s->r14; break; + case 15: mark_regs_dirty(regs); p =3D ®s->r15; break; #endif default: BUG(); p =3D NULL; break; } --- a/xen/arch/x86/x86_emulate.c +++ b/xen/arch/x86/x86_emulate.c @@ -10,6 +10,7 @@ */ =20 #include +#include /* mark_regs_dirty() */ #include /* current_cpu_info */ #include /* cpu_has_amd_erratum() */ =20 --- a/xen/common/wait.c +++ b/xen/common/wait.c @@ -124,10 +124,12 @@ void wake_up_all(struct waitqueue_head * =20 static void __prepare_to_wait(struct waitqueue_vcpu *wqv) { - char *cpu_info =3D (char *)get_cpu_info(); + struct cpu_info *cpu_info =3D get_cpu_info(); struct vcpu *curr =3D current; unsigned long dummy; + u32 entry_vector =3D cpu_info->guest_cpu_user_regs.entry_vector; =20 + cpu_info->guest_cpu_user_regs.entry_vector &=3D ~TRAP_regs_partial; ASSERT(wqv->esp =3D=3D 0); =20 /* Save current VCPU affinity; force wakeup on *this* CPU only. */ @@ -157,6 +159,8 @@ static void __prepare_to_wait(struct wai gdprintk(XENLOG_ERR, "Stack too large in %s\n", __FUNCTION__); domain_crash_synchronous(); } + + cpu_info->guest_cpu_user_regs.entry_vector =3D entry_vector; } =20 static void __finish_wait(struct waitqueue_vcpu *wqv) --- a/xen/include/asm-x86/x86_64/asm_defns.h +++ b/xen/include/asm-x86/x86_64/asm_defns.h @@ -26,6 +26,17 @@ #define ASSERT_INTERRUPTS_ENABLED ASSERT_INTERRUPT_STATUS(nz) #define ASSERT_INTERRUPTS_DISABLED ASSERT_INTERRUPT_STATUS(z) =20 +#define _TRAP_regs_partial 16 +#define _TRAP_regs_dirty 17 +#define TRAP_regs_partial (1 << _TRAP_regs_partial) +#define TRAP_regs_dirty (1 << _TRAP_regs_dirty) + +#define mark_regs_dirty(r) ({ \ + struct cpu_user_regs *r__ =3D (r); \ + ASSERT(!((r__)->entry_vector & TRAP_regs_partial)); \ + r__->entry_vector |=3D TRAP_regs_dirty; \ +}) + #define SAVE_ALL \ addq $-(UREGS_error_code-UREGS_r15), %rsp; \ cld; \ @@ -47,11 +58,49 @@ movq %r15,UREGS_r15(%rsp); \ =20 #ifdef __ASSEMBLY__ -.macro LOAD_C_CLOBBERED + +.macro SAVE_VOLATILE type compat=3D0 +.if \compat + movl $\type,UREGS_entry_vector-UREGS_error_code(%rsp) +.else + movl $\type|TRAP_regs_partial,\ + UREGS_entry_vector-UREGS_error_code(%rsp) +.endif + addq $-(UREGS_error_code-UREGS_r15),%rsp + cld + movq %rdi,UREGS_rdi(%rsp) + movq %rsi,UREGS_rsi(%rsp) + movq %rdx,UREGS_rdx(%rsp) + movq %rcx,UREGS_rcx(%rsp) + movq %rax,UREGS_rax(%rsp) +.if !\compat + movq %r8,UREGS_r8(%rsp) + movq %r9,UREGS_r9(%rsp) + movq %r10,UREGS_r10(%rsp) + movq %r11,UREGS_r11(%rsp) +.endif + movq %rbx,UREGS_rbx(%rsp) + movq %rbp,UREGS_rbp(%rsp) + SETUP_EXCEPTION_FRAME_POINTER(UREGS_rbp) +.endm + +.macro SAVE_PRESERVED + btrl $_TRAP_regs_partial,UREGS_entry_vector(%rsp) + jnc 987f + movq %r12,UREGS_r12(%rsp) + movq %r13,UREGS_r13(%rsp) + movq %r14,UREGS_r14(%rsp) + movq %r15,UREGS_r15(%rsp) +987: +.endm + +.macro LOAD_C_CLOBBERED compat=3D0 +.if !\compat movq UREGS_r11(%rsp),%r11 movq UREGS_r10(%rsp),%r10 movq UREGS_r9(%rsp),%r9 movq UREGS_r8(%rsp),%r8 +.endif movq UREGS_rax(%rsp),%rax movq UREGS_rcx(%rsp),%rcx movq UREGS_rdx(%rsp),%rdx @@ -59,16 +108,38 @@ movq UREGS_rdi(%rsp),%rdi .endm =20 -.macro RESTORE_ALL adj=3D0 +.macro RESTORE_ALL adj=3D0 compat=3D0 +.if !\compat + testl $TRAP_regs_dirty,UREGS_entry_vector(%rsp) +.endif + LOAD_C_CLOBBERED \compat +.if !\compat + jz 987f movq UREGS_r15(%rsp),%r15 movq UREGS_r14(%rsp),%r14 movq UREGS_r13(%rsp),%r13 movq UREGS_r12(%rsp),%r12 - movq UREGS_rbp(%rsp),%rbp +#ifndef NDEBUG + .subsection 1 +987: testl $TRAP_regs_partial,UREGS_entry_vector(%rsp) + jnz 987f + cmpq UREGS_r15(%rsp),%r15 + jne 789f + cmpq UREGS_r14(%rsp),%r14 + jne 789f + cmpq UREGS_r13(%rsp),%r13 + jne 789f + cmpq UREGS_r12(%rsp),%r12 + je 987f +789: ud2 + .subsection 0 +#endif +.endif +987: movq UREGS_rbp(%rsp),%rbp movq UREGS_rbx(%rsp),%rbx - LOAD_C_CLOBBERED subq $-(UREGS_error_code-UREGS_r15+\adj), %rsp .endm + #endif =20 #ifdef PERF_COUNTERS --=__PartB48582E0.0__= Content-Type: text/plain; name="x86-save-restore-reduce.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="x86-save-restore-reduce.patch" x86: save/restore only partial register state where possible=0A=0A... and = make restore conditional not only upon having saved the state,=0Abut also = upon whether saved state was actually modified (and register=0Avalues are = known to have been preserved).=0A=0ANote that RBP is unconditionally = considered a volatile register (i.e.=0Airrespective of CONFIG_FRAME_POINTER= ), since the RBP handling would=0Abecome overly complicated due to the = need to save/restore it on the=0Acompat mode hypercall path [6th argument].= =0A=0ANote further that for compat mode code paths, saving/restoring = R8...R15=0Ais entirely unnecessary - we don't allow those guests to enter = 64-bit=0Amode, and hence they have no way of seeing these registers' = contents=0A(and there consequently also is no information leak, except if = the=0Acontext saving domctl would be considered such).=0A=0AFinally, note = that this may not properly deal with gdbstub's needs, yet=0A(but if so, I = can't really suggest adjustments, as I don't know that=0Acode).=0A=0ASigned= -off-by: Jan Beulich =0A=0A--- a/tools/tests/x86_emulato= r/x86_emulate.c=0A+++ b/tools/tests/x86_emulator/x86_emulate.c=0A@@ -10,6 = +10,7 @@ typedef bool bool_t;=0A #define BUG() abort()=0A =0A #define = cpu_has_amd_erratum(nr) 0=0A+#define mark_regs_dirty(r) ((void)(r))=0A =0A = #include "x86_emulate/x86_emulate.h"=0A #include "x86_emulate/x86_emulate.c= "=0A--- a/xen/arch/x86/domain.c=0A+++ b/xen/arch/x86/domain.c=0A@@ -138,6 = +138,7 @@ static void continue_idle_domain(struct =0A static void = continue_nonidle_domain(struct vcpu *v)=0A {=0A check_wakeup_from_wait(= );=0A+ mark_regs_dirty(guest_cpu_user_regs());=0A reset_stack_and_ju= mp(ret_from_intr);=0A }=0A =0A@@ -1307,7 +1308,7 @@ static void load_segmen= ts(struct vcpu *n=0A if ( test_bit(_VGCF_failsafe_disables_even= ts, &n->arch.vgc_flags) )=0A vcpu_info(n, evtchn_upcall_mas= k) =3D 1;=0A =0A- regs->entry_vector =3D TRAP_syscall;=0A+ = regs->entry_vector |=3D TRAP_syscall;=0A regs->_eflags = &=3D 0xFFFCBEFFUL;=0A regs->ss =3D FLAT_COMPAT_K= ERNEL_SS;=0A regs->_esp =3D (unsigned long)(esp-7);=0A= @@ -1349,7 +1350,7 @@ static void load_segments(struct vcpu *n=0A = if ( test_bit(_VGCF_failsafe_disables_events, &n->arch.vgc_flags) )=0A = vcpu_info(n, evtchn_upcall_mask) =3D 1;=0A =0A- regs->entry_= vector =3D TRAP_syscall;=0A+ regs->entry_vector |=3D TRAP_syscall;= =0A regs->rflags &=3D ~(X86_EFLAGS_AC|X86_EFLAGS_VM|X86_EFLAG= S_RF|=0A X86_EFLAGS_NT|X86_EFLAGS_TF);=0A = regs->ss =3D FLAT_KERNEL_SS;=0A--- a/xen/arch/x86/irq.c= =0A+++ b/xen/arch/x86/irq.c=0A@@ -704,7 +704,7 @@ void irq_complete_move(st= ruct irq_desc *=0A if (likely(!desc->arch.move_in_progress))=0A = return;=0A =0A- vector =3D get_irq_regs()->entry_vector;=0A+ vector = =3D (u8)get_irq_regs()->entry_vector;=0A me =3D smp_processor_id();=0A = =0A if ( vector =3D=3D desc->arch.vector &&=0A@@ -798,7 +798,7 @@ void = do_IRQ(struct cpu_user_regs *regs)=0A struct irqaction *action;=0A = uint32_t tsc_in;=0A struct irq_desc *desc;=0A- unsigned = int vector =3D regs->entry_vector;=0A+ unsigned int vector = =3D (u8)regs->entry_vector;=0A int irq =3D __get_cpu_var(vector_irq[vec= tor]);=0A struct cpu_user_regs *old_regs =3D set_irq_regs(regs);=0A = =0A@@ -892,7 +892,7 @@ void do_IRQ(struct cpu_user_regs *regs)=0A =0A = out:=0A if ( desc->handler->end )=0A- desc->handler->end(desc, = regs->entry_vector);=0A+ desc->handler->end(desc, vector);=0A = out_no_end:=0A spin_unlock(&desc->lock);=0A out_no_unlock:=0A@@ = -1113,7 +1113,7 @@ static void __do_IRQ_guest(int irq)=0A struct = domain *d;=0A int i, sp;=0A struct pending_eoi= *peoi =3D this_cpu(pending_eoi);=0A- int vector =3D get_irq_regs()->ent= ry_vector;=0A+ unsigned int vector =3D (u8)get_irq_regs()->entry_= vector;=0A =0A if ( unlikely(action->nr_guests =3D=3D 0) )=0A = {=0A--- a/xen/arch/x86/traps.c=0A+++ b/xen/arch/x86/traps.c=0A@@ -2082,6 = +2082,7 @@ static int emulate_privileged_op(struct =0A goto = fail;=0A if ( admin_io_okay(port, op_bytes, v, regs) )=0A = {=0A+ mark_regs_dirty(regs);=0A io_emul(regs); = =0A }=0A else=0A@@ -2111,6 +2112,7 @@ static int = emulate_privileged_op(struct =0A goto fail;=0A if ( = admin_io_okay(port, op_bytes, v, regs) )=0A {=0A+ = mark_regs_dirty(regs);=0A io_emul(regs); =0A = if ( (op_bytes =3D=3D 1) && pv_post_outb_hook )=0A = pv_post_outb_hook(port, regs->eax);=0A--- a/xen/arch/x86/x86_64/compat/entr= y.S=0A+++ b/xen/arch/x86/x86_64/compat/entry.S=0A@@ -14,8 +14,7 @@=0A =0A = ENTRY(compat_hypercall)=0A pushq $0=0A- movl $TRAP_syscall,= 4(%rsp)=0A- SAVE_ALL=0A+ SAVE_VOLATILE type=3DTRAP_syscall = compat=3D1=0A =0A cmpb $0,untrusted_msi(%rip)=0A UNLIKELY_START(ne= , msi_check)=0A@@ -126,6 +125,7 @@ compat_test_guest_events:=0A /* %rbx: = struct vcpu */=0A compat_process_softirqs:=0A sti=0A+ andl = $~TRAP_regs_partial,UREGS_entry_vector(%rsp)=0A call do_softirq=0A= jmp compat_test_all_events=0A =0A@@ -172,7 +172,7 @@ compat_bad_= hypercall:=0A /* %rbx: struct vcpu, interrupts disabled */=0A compat_restor= e_all_guest:=0A ASSERT_INTERRUPTS_DISABLED=0A- RESTORE_ALL = adj=3D8=0A+ RESTORE_ALL adj=3D8 compat=3D1=0A .Lft0: iretq=0A =0A = .section .fixup,"ax"=0A@@ -243,7 +243,7 @@ UNLIKELY_END(compat_syscall_gpf)= =0A =0A ENTRY(compat_sysenter)=0A movq VCPU_trap_ctxt(%rbx),%rcx= =0A- cmpl $TRAP_gp_fault,UREGS_entry_vector(%rsp)=0A+ cmpb = $TRAP_gp_fault,UREGS_entry_vector(%rsp)=0A movzwl VCPU_sysenter_sel= (%rbx),%eax=0A movzwl TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_cs= (%rcx),%ecx=0A cmovel %ecx,%eax=0A--- a/xen/arch/x86/x86_64/entry.S= =0A+++ b/xen/arch/x86/x86_64/entry.S=0A@@ -123,9 +123,8 @@ ENTRY(syscall_en= ter)=0A movl $FLAT_KERNEL_SS,24(%rsp)=0A pushq %rcx=0A = pushq $0=0A- movl $TRAP_syscall,4(%rsp)=0A- movq = 24(%rsp),%r11 /* Re-load user RFLAGS into %r11 before SAVE_ALL */=0A- = SAVE_ALL=0A+ movq 24(%rsp),%r11 /* Re-load user RFLAGS into %r11 = before saving */=0A+ SAVE_VOLATILE TRAP_syscall=0A = GET_CURRENT(%rbx)=0A movq VCPU_domain(%rbx),%rcx=0A testb = $1,DOMAIN_is_32bit_pv(%rcx)=0A@@ -222,6 +221,7 @@ test_guest_events:=0A /* = %rbx: struct vcpu */=0A process_softirqs:=0A sti =0A+ = SAVE_PRESERVED=0A call do_softirq=0A jmp test_all_events= =0A =0A@@ -275,8 +275,7 @@ sysenter_eflags_saved:=0A pushq $3 /* = ring 3 null cs */=0A pushq $0 /* null rip */=0A pushq = $0=0A- movl $TRAP_syscall,4(%rsp)=0A- SAVE_ALL=0A+ = SAVE_VOLATILE TRAP_syscall=0A GET_CURRENT(%rbx)=0A cmpb = $0,VCPU_sysenter_disables_events(%rbx)=0A movq VCPU_sysenter_addr(= %rbx),%rax=0A@@ -286,6 +285,7 @@ sysenter_eflags_saved:=0A leal = (,%rcx,TBF_INTERRUPT),%ecx=0A UNLIKELY_START(z, sysenter_gpf)=0A = movq VCPU_trap_ctxt(%rbx),%rsi=0A+ SAVE_PRESERVED=0A movl = $TRAP_gp_fault,UREGS_entry_vector(%rsp)=0A movl %eax,TRAPBOUNCE_er= ror_code(%rdx)=0A movq TRAP_gp_fault * TRAPINFO_sizeof + = TRAPINFO_eip(%rsi),%rax=0A@@ -302,7 +302,7 @@ UNLIKELY_END(sysenter_gpf)=0A= =0A ENTRY(int80_direct_trap)=0A pushq $0=0A- SAVE_ALL=0A+ = SAVE_VOLATILE 0x80=0A =0A cmpb $0,untrusted_msi(%rip)=0A = UNLIKELY_START(ne, msi_check)=0A@@ -331,6 +331,7 @@ int80_slow_path:=0A = * IDT entry with DPL=3D=3D0.=0A */=0A movl $((0x80 = << 3) | 0x2),UREGS_error_code(%rsp)=0A+ SAVE_PRESERVED=0A = movl $TRAP_gp_fault,UREGS_entry_vector(%rsp)=0A /* A GPF wouldn't = have incremented the instruction pointer. */=0A subq $2,UREGS_rip(= %rsp)=0A@@ -412,7 +413,7 @@ UNLIKELY_END(bounce_failsafe)=0A /* = Rewrite our stack frame and return to guest-OS mode. */=0A /* IA32 = Ref. Vol. 3: TF, VM, RF and NT flags are cleared on trap. */=0A /* = Also clear AC: alignment checks shouldn't trigger in kernel mode. */=0A- = movl $TRAP_syscall,UREGS_entry_vector+8(%rsp)=0A+ orl = $TRAP_syscall,UREGS_entry_vector+8(%rsp)=0A andl $~(X86_EFLAGS_AC|= X86_EFLAGS_VM|X86_EFLAGS_RF|\=0A X86_EFLAGS_NT|X86_EFLAGS_= TF),UREGS_eflags+8(%rsp)=0A movq $FLAT_KERNEL_SS,UREGS_ss+8(%rsp)= =0A@@ -477,7 +478,7 @@ handle_exception_saved:=0A jz exception_w= ith_ints_disabled=0A sti=0A 1: movq %rsp,%rdi=0A- = movl UREGS_entry_vector(%rsp),%eax=0A+ movzbl UREGS_entry_vector(%r= sp),%eax=0A leaq exception_table(%rip),%rdx=0A GET_CURRENT= (%rbx)=0A PERFC_INCR(exceptions, %rax, %rbx)=0A@@ -518,7 +519,7 @@ = exception_with_ints_disabled:=0A =0A /* No special register assumptions. = */=0A FATAL_exception_with_ints_disabled:=0A- movl UREGS_entry_vect= or(%rsp),%edi=0A+ movzbl UREGS_entry_vector(%rsp),%edi=0A = movq %rsp,%rsi=0A call fatal_trap=0A ud2=0A@@ -624,7 = +625,7 @@ handle_ist_exception:=0A movq %rdi,%rsp=0A rep = movsq=0A 1: movq %rsp,%rdi=0A- movl UREGS_entry_vector(%rsp)= ,%eax=0A+ movzbl UREGS_entry_vector(%rsp),%eax=0A leaq = exception_table(%rip),%rdx=0A callq *(%rdx,%rax,8)=0A jmp = ret_from_intr=0A--- a/xen/arch/x86/x86_64/traps.c=0A+++ b/xen/arch/x86/x86= _64/traps.c=0A@@ -67,10 +67,15 @@ static void _show_registers(=0A = regs->rbp, regs->rsp, regs->r8);=0A printk("r9: %016lx r10: = %016lx r11: %016lx\n",=0A regs->r9, regs->r10, regs->r11);=0A= - printk("r12: %016lx r13: %016lx r14: %016lx\n",=0A- = regs->r12, regs->r13, regs->r14);=0A- printk("r15: %016lx cr0: %016lx = cr4: %016lx\n",=0A- regs->r15, crs[0], crs[4]);=0A+ if ( = !(regs->entry_vector & TRAP_regs_partial) )=0A+ {=0A+ printk("r12= : %016lx r13: %016lx r14: %016lx\n",=0A+ regs->r12, = regs->r13, regs->r14);=0A+ printk("r15: %016lx cr0: %016lx cr4: = %016lx\n",=0A+ regs->r15, crs[0], crs[4]);=0A+ }=0A+ = else=0A+ printk("cr0: %016lx cr4: %016lx\n", crs[0], crs[4]);=0A = printk("cr3: %016lx cr2: %016lx\n", crs[3], crs[2]);=0A printk("ds= : %04x es: %04x fs: %04x gs: %04x "=0A "ss: %04x cs: = %04x\n",=0A@@ -301,7 +306,7 @@ unsigned long do_iret(void)=0A =0A if ( = !(iret_saved.flags & VGCF_in_syscall) )=0A {=0A- regs->entry_vec= tor =3D 0;=0A+ regs->entry_vector &=3D ~TRAP_syscall;=0A = regs->r11 =3D iret_saved.r11;=0A regs->rcx =3D iret_saved.rcx;=0A = }=0A--- a/xen/arch/x86/x86_emulate/x86_emulate.c=0A+++ b/xen/arch/x86/x8= 6_emulate/x86_emulate.c=0A@@ -1292,10 +1292,10 @@ decode_register(=0A = case 9: p =3D ®s->r9; break;=0A case 10: p =3D ®s->r10; = break;=0A case 11: p =3D ®s->r11; break;=0A- case 12: p =3D = ®s->r12; break;=0A- case 13: p =3D ®s->r13; break;=0A- case = 14: p =3D ®s->r14; break;=0A- case 15: p =3D ®s->r15; break;=0A+ = case 12: mark_regs_dirty(regs); p =3D ®s->r12; break;=0A+ case 13: = mark_regs_dirty(regs); p =3D ®s->r13; break;=0A+ case 14: mark_regs_d= irty(regs); p =3D ®s->r14; break;=0A+ case 15: mark_regs_dirty(regs);= p =3D ®s->r15; break;=0A #endif=0A default: BUG(); p =3D NULL; = break;=0A }=0A--- a/xen/arch/x86/x86_emulate.c=0A+++ b/xen/arch/x86/x86= _emulate.c=0A@@ -10,6 +10,7 @@=0A */=0A =0A #include = =0A+#include /* mark_regs_dirty() */=0A #include = /* current_cpu_info */=0A #include /* = cpu_has_amd_erratum() */=0A =0A--- a/xen/common/wait.c=0A+++ b/xen/common/w= ait.c=0A@@ -124,10 +124,12 @@ void wake_up_all(struct waitqueue_head *=0A = =0A static void __prepare_to_wait(struct waitqueue_vcpu *wqv)=0A {=0A- = char *cpu_info =3D (char *)get_cpu_info();=0A+ struct cpu_info = *cpu_info =3D get_cpu_info();=0A struct vcpu *curr =3D current;=0A = unsigned long dummy;=0A+ u32 entry_vector =3D cpu_info->guest_cpu_user_r= egs.entry_vector;=0A =0A+ cpu_info->guest_cpu_user_regs.entry_vector = &=3D ~TRAP_regs_partial;=0A ASSERT(wqv->esp =3D=3D 0);=0A =0A /* = Save current VCPU affinity; force wakeup on *this* CPU only. */=0A@@ = -157,6 +159,8 @@ static void __prepare_to_wait(struct wai=0A = gdprintk(XENLOG_ERR, "Stack too large in %s\n", __FUNCTION__);=0A = domain_crash_synchronous();=0A }=0A+=0A+ cpu_info->guest_cpu_user_re= gs.entry_vector =3D entry_vector;=0A }=0A =0A static void __finish_wait(str= uct waitqueue_vcpu *wqv)=0A--- a/xen/include/asm-x86/x86_64/asm_defns.h=0A+= ++ b/xen/include/asm-x86/x86_64/asm_defns.h=0A@@ -26,6 +26,17 @@=0A = #define ASSERT_INTERRUPTS_ENABLED ASSERT_INTERRUPT_STATUS(nz)=0A #define = ASSERT_INTERRUPTS_DISABLED ASSERT_INTERRUPT_STATUS(z)=0A =0A+#define = _TRAP_regs_partial 16=0A+#define _TRAP_regs_dirty 17=0A+#define = TRAP_regs_partial (1 << _TRAP_regs_partial)=0A+#define TRAP_regs_dirty = (1 << _TRAP_regs_dirty)=0A+=0A+#define mark_regs_dirty(r) ({ \=0A+ = struct cpu_user_regs *r__ =3D (r); \=0A+ ASSERT(!((r__)->entry_vecto= r & TRAP_regs_partial)); \=0A+ r__->entry_vector |=3D TRAP_regs_dirt= y; \=0A+})=0A+=0A #define SAVE_ALL \=0A = addq $-(UREGS_error_code-UREGS_r15), %rsp; \=0A cld; = \=0A@@ -47,11 +58,49 @@=0A movq = %r15,UREGS_r15(%rsp); \=0A =0A #ifdef __ASSEMBLY__=0A-.macro = LOAD_C_CLOBBERED=0A+=0A+.macro SAVE_VOLATILE type compat=3D0=0A+.if = \compat=0A+ movl $\type,UREGS_entry_vector-UREGS_error_code(%rsp)= =0A+.else=0A+ movl $\type|TRAP_regs_partial,\=0A+ = UREGS_entry_vector-UREGS_error_code(%rsp)=0A+.endif=0A+ addq = $-(UREGS_error_code-UREGS_r15),%rsp=0A+ cld=0A+ movq = %rdi,UREGS_rdi(%rsp)=0A+ movq %rsi,UREGS_rsi(%rsp)=0A+ movq = %rdx,UREGS_rdx(%rsp)=0A+ movq %rcx,UREGS_rcx(%rsp)=0A+ = movq %rax,UREGS_rax(%rsp)=0A+.if !\compat=0A+ movq %r8,UREGS_r8(%r= sp)=0A+ movq %r9,UREGS_r9(%rsp)=0A+ movq %r10,UREGS_r10(%rs= p)=0A+ movq %r11,UREGS_r11(%rsp)=0A+.endif=0A+ movq = %rbx,UREGS_rbx(%rsp)=0A+ movq %rbp,UREGS_rbp(%rsp)=0A+ = SETUP_EXCEPTION_FRAME_POINTER(UREGS_rbp)=0A+.endm=0A+=0A+.macro SAVE_PRESER= VED=0A+ btrl $_TRAP_regs_partial,UREGS_entry_vector(%rsp)=0A+ = jnc 987f=0A+ movq %r12,UREGS_r12(%rsp)=0A+ movq = %r13,UREGS_r13(%rsp)=0A+ movq %r14,UREGS_r14(%rsp)=0A+ movq = %r15,UREGS_r15(%rsp)=0A+987:=0A+.endm=0A+=0A+.macro LOAD_C_CLOBBERED = compat=3D0=0A+.if !\compat=0A movq UREGS_r11(%rsp),%r11=0A = movq UREGS_r10(%rsp),%r10=0A movq UREGS_r9(%rsp),%r9=0A = movq UREGS_r8(%rsp),%r8=0A+.endif=0A movq UREGS_rax(%rsp),%rax=0A= movq UREGS_rcx(%rsp),%rcx=0A movq UREGS_rdx(%rsp),%rdx= =0A@@ -59,16 +108,38 @@=0A movq UREGS_rdi(%rsp),%rdi=0A .endm=0A = =0A-.macro RESTORE_ALL adj=3D0=0A+.macro RESTORE_ALL adj=3D0 compat=3D0=0A+= .if !\compat=0A+ testl $TRAP_regs_dirty,UREGS_entry_vector(%rsp)=0A+= .endif=0A+ LOAD_C_CLOBBERED \compat=0A+.if !\compat=0A+ jz = 987f=0A movq UREGS_r15(%rsp),%r15=0A movq UREGS_r14(%rsp= ),%r14=0A movq UREGS_r13(%rsp),%r13=0A movq UREGS_r12(%rs= p),%r12=0A- movq UREGS_rbp(%rsp),%rbp=0A+#ifndef NDEBUG=0A+ = .subsection 1=0A+987: testl $TRAP_regs_partial,UREGS_entry_vector(%rsp)= =0A+ jnz 987f=0A+ cmpq UREGS_r15(%rsp),%r15=0A+ = jne 789f=0A+ cmpq UREGS_r14(%rsp),%r14=0A+ jne 789f=0A+ = cmpq UREGS_r13(%rsp),%r13=0A+ jne 789f=0A+ cmpq = UREGS_r12(%rsp),%r12=0A+ je 987f=0A+789: ud2=0A+ = .subsection 0=0A+#endif=0A+.endif=0A+987: movq UREGS_rbp(%rsp),%rbp=0A = movq UREGS_rbx(%rsp),%rbx=0A- LOAD_C_CLOBBERED=0A = subq $-(UREGS_error_code-UREGS_r15+\adj), %rsp=0A .endm=0A+=0A #endif=0A = =0A #ifdef PERF_COUNTERS=0A --=__PartB48582E0.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --=__PartB48582E0.0__=-- From xen-devel-bounces@lists.xen.org Tue Oct 02 15:28:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 15:28:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4O0-0003B9-UK; Tue, 02 Oct 2012 15:27:52 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4Nz-0003Ah-Hg for xen-devel@lists.xen.org; Tue, 02 Oct 2012 15:27:51 +0000 Received: from [85.158.143.35:59652] by server-3.bemta-4.messagelabs.com id 91/A4-10986-6F70B605; Tue, 02 Oct 2012 15:27:50 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1349191668!6276185!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25884 invoked from network); 2 Oct 2012 15:27:48 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-4.tower-21.messagelabs.com with SMTP; 2 Oct 2012 15:27:48 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 02 Oct 2012 16:27:46 +0100 Message-Id: <506B2410020000780009F2A3@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Tue, 02 Oct 2012 16:27:44 +0100 From: "Jan Beulich" To: "xen-devel" References: <506B2268020000780009F273@nat28.tlf.novell.com> In-Reply-To: <506B2268020000780009F273@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__PartB48582E0.0__=" Subject: [Xen-devel] [PATCH 3/3] x86: save/restore only partial register state where possible X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartB48582E0.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline ... and make restore conditional not only upon having saved the state, but also upon whether saved state was actually modified (and register values are known to have been preserved). Note that RBP is unconditionally considered a volatile register (i.e. irrespective of CONFIG_FRAME_POINTER), since the RBP handling would become overly complicated due to the need to save/restore it on the compat mode hypercall path [6th argument]. Note further that for compat mode code paths, saving/restoring R8...R15 is entirely unnecessary - we don't allow those guests to enter 64-bit mode, and hence they have no way of seeing these registers' contents (and there consequently also is no information leak, except if the context saving domctl would be considered such). Finally, note that this may not properly deal with gdbstub's needs, yet (but if so, I can't really suggest adjustments, as I don't know that code). Signed-off-by: Jan Beulich --- a/tools/tests/x86_emulator/x86_emulate.c +++ b/tools/tests/x86_emulator/x86_emulate.c @@ -10,6 +10,7 @@ typedef bool bool_t; #define BUG() abort() =20 #define cpu_has_amd_erratum(nr) 0 +#define mark_regs_dirty(r) ((void)(r)) =20 #include "x86_emulate/x86_emulate.h" #include "x86_emulate/x86_emulate.c" --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -138,6 +138,7 @@ static void continue_idle_domain(struct=20 static void continue_nonidle_domain(struct vcpu *v) { check_wakeup_from_wait(); + mark_regs_dirty(guest_cpu_user_regs()); reset_stack_and_jump(ret_from_intr); } =20 @@ -1307,7 +1308,7 @@ static void load_segments(struct vcpu *n if ( test_bit(_VGCF_failsafe_disables_events, &n->arch.vgc_fla= gs) ) vcpu_info(n, evtchn_upcall_mask) =3D 1; =20 - regs->entry_vector =3D TRAP_syscall; + regs->entry_vector |=3D TRAP_syscall; regs->_eflags &=3D 0xFFFCBEFFUL; regs->ss =3D FLAT_COMPAT_KERNEL_SS; regs->_esp =3D (unsigned long)(esp-7); @@ -1349,7 +1350,7 @@ static void load_segments(struct vcpu *n if ( test_bit(_VGCF_failsafe_disables_events, &n->arch.vgc_flags) = ) vcpu_info(n, evtchn_upcall_mask) =3D 1; =20 - regs->entry_vector =3D TRAP_syscall; + regs->entry_vector |=3D TRAP_syscall; regs->rflags &=3D ~(X86_EFLAGS_AC|X86_EFLAGS_VM|X86_EFLAGS_R= F| X86_EFLAGS_NT|X86_EFLAGS_TF); regs->ss =3D FLAT_KERNEL_SS; --- a/xen/arch/x86/irq.c +++ b/xen/arch/x86/irq.c @@ -704,7 +704,7 @@ void irq_complete_move(struct irq_desc * if (likely(!desc->arch.move_in_progress)) return; =20 - vector =3D get_irq_regs()->entry_vector; + vector =3D (u8)get_irq_regs()->entry_vector; me =3D smp_processor_id(); =20 if ( vector =3D=3D desc->arch.vector && @@ -798,7 +798,7 @@ void do_IRQ(struct cpu_user_regs *regs) struct irqaction *action; uint32_t tsc_in; struct irq_desc *desc; - unsigned int vector =3D regs->entry_vector; + unsigned int vector =3D (u8)regs->entry_vector; int irq =3D __get_cpu_var(vector_irq[vector]); struct cpu_user_regs *old_regs =3D set_irq_regs(regs); =20 @@ -892,7 +892,7 @@ void do_IRQ(struct cpu_user_regs *regs) =20 out: if ( desc->handler->end ) - desc->handler->end(desc, regs->entry_vector); + desc->handler->end(desc, vector); out_no_end: spin_unlock(&desc->lock); out_no_unlock: @@ -1113,7 +1113,7 @@ static void __do_IRQ_guest(int irq) struct domain *d; int i, sp; struct pending_eoi *peoi =3D this_cpu(pending_eoi); - int vector =3D get_irq_regs()->entry_vector; + unsigned int vector =3D (u8)get_irq_regs()->entry_vector; =20 if ( unlikely(action->nr_guests =3D=3D 0) ) { --- a/xen/arch/x86/traps.c +++ b/xen/arch/x86/traps.c @@ -2082,6 +2082,7 @@ static int emulate_privileged_op(struct=20 goto fail; if ( admin_io_okay(port, op_bytes, v, regs) ) { + mark_regs_dirty(regs); io_emul(regs); =20 } else @@ -2111,6 +2112,7 @@ static int emulate_privileged_op(struct=20 goto fail; if ( admin_io_okay(port, op_bytes, v, regs) ) { + mark_regs_dirty(regs); io_emul(regs); =20 if ( (op_bytes =3D=3D 1) && pv_post_outb_hook ) pv_post_outb_hook(port, regs->eax); --- a/xen/arch/x86/x86_64/compat/entry.S +++ b/xen/arch/x86/x86_64/compat/entry.S @@ -14,8 +14,7 @@ =20 ENTRY(compat_hypercall) pushq $0 - movl $TRAP_syscall,4(%rsp) - SAVE_ALL + SAVE_VOLATILE type=3DTRAP_syscall compat=3D1 =20 cmpb $0,untrusted_msi(%rip) UNLIKELY_START(ne, msi_check) @@ -126,6 +125,7 @@ compat_test_guest_events: /* %rbx: struct vcpu */ compat_process_softirqs: sti + andl $~TRAP_regs_partial,UREGS_entry_vector(%rsp) call do_softirq jmp compat_test_all_events =20 @@ -172,7 +172,7 @@ compat_bad_hypercall: /* %rbx: struct vcpu, interrupts disabled */ compat_restore_all_guest: ASSERT_INTERRUPTS_DISABLED - RESTORE_ALL adj=3D8 + RESTORE_ALL adj=3D8 compat=3D1 .Lft0: iretq =20 .section .fixup,"ax" @@ -243,7 +243,7 @@ UNLIKELY_END(compat_syscall_gpf) =20 ENTRY(compat_sysenter) movq VCPU_trap_ctxt(%rbx),%rcx - cmpl $TRAP_gp_fault,UREGS_entry_vector(%rsp) + cmpb $TRAP_gp_fault,UREGS_entry_vector(%rsp) movzwl VCPU_sysenter_sel(%rbx),%eax movzwl TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_cs(%rcx),%ecx cmovel %ecx,%eax --- a/xen/arch/x86/x86_64/entry.S +++ b/xen/arch/x86/x86_64/entry.S @@ -123,9 +123,8 @@ ENTRY(syscall_enter) movl $FLAT_KERNEL_SS,24(%rsp) pushq %rcx pushq $0 - movl $TRAP_syscall,4(%rsp) - movq 24(%rsp),%r11 /* Re-load user RFLAGS into %r11 before = SAVE_ALL */ - SAVE_ALL + movq 24(%rsp),%r11 /* Re-load user RFLAGS into %r11 before = saving */ + SAVE_VOLATILE TRAP_syscall GET_CURRENT(%rbx) movq VCPU_domain(%rbx),%rcx testb $1,DOMAIN_is_32bit_pv(%rcx) @@ -222,6 +221,7 @@ test_guest_events: /* %rbx: struct vcpu */ process_softirqs: sti =20 + SAVE_PRESERVED call do_softirq jmp test_all_events =20 @@ -275,8 +275,7 @@ sysenter_eflags_saved: pushq $3 /* ring 3 null cs */ pushq $0 /* null rip */ pushq $0 - movl $TRAP_syscall,4(%rsp) - SAVE_ALL + SAVE_VOLATILE TRAP_syscall GET_CURRENT(%rbx) cmpb $0,VCPU_sysenter_disables_events(%rbx) movq VCPU_sysenter_addr(%rbx),%rax @@ -286,6 +285,7 @@ sysenter_eflags_saved: leal (,%rcx,TBF_INTERRUPT),%ecx UNLIKELY_START(z, sysenter_gpf) movq VCPU_trap_ctxt(%rbx),%rsi + SAVE_PRESERVED movl $TRAP_gp_fault,UREGS_entry_vector(%rsp) movl %eax,TRAPBOUNCE_error_code(%rdx) movq TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_eip(%rsi),%rax @@ -302,7 +302,7 @@ UNLIKELY_END(sysenter_gpf) =20 ENTRY(int80_direct_trap) pushq $0 - SAVE_ALL + SAVE_VOLATILE 0x80 =20 cmpb $0,untrusted_msi(%rip) UNLIKELY_START(ne, msi_check) @@ -331,6 +331,7 @@ int80_slow_path: * IDT entry with DPL=3D=3D0. */ movl $((0x80 << 3) | 0x2),UREGS_error_code(%rsp) + SAVE_PRESERVED movl $TRAP_gp_fault,UREGS_entry_vector(%rsp) /* A GPF wouldn't have incremented the instruction pointer. */ subq $2,UREGS_rip(%rsp) @@ -412,7 +413,7 @@ UNLIKELY_END(bounce_failsafe) /* Rewrite our stack frame and return to guest-OS mode. */ /* IA32 Ref. Vol. 3: TF, VM, RF and NT flags are cleared on trap. = */ /* Also clear AC: alignment checks shouldn't trigger in kernel = mode. */ - movl $TRAP_syscall,UREGS_entry_vector+8(%rsp) + orl $TRAP_syscall,UREGS_entry_vector+8(%rsp) andl $~(X86_EFLAGS_AC|X86_EFLAGS_VM|X86_EFLAGS_RF|\ X86_EFLAGS_NT|X86_EFLAGS_TF),UREGS_eflags+8(%rsp) movq $FLAT_KERNEL_SS,UREGS_ss+8(%rsp) @@ -477,7 +478,7 @@ handle_exception_saved: jz exception_with_ints_disabled sti 1: movq %rsp,%rdi - movl UREGS_entry_vector(%rsp),%eax + movzbl UREGS_entry_vector(%rsp),%eax leaq exception_table(%rip),%rdx GET_CURRENT(%rbx) PERFC_INCR(exceptions, %rax, %rbx) @@ -518,7 +519,7 @@ exception_with_ints_disabled: =20 /* No special register assumptions. */ FATAL_exception_with_ints_disabled: - movl UREGS_entry_vector(%rsp),%edi + movzbl UREGS_entry_vector(%rsp),%edi movq %rsp,%rsi call fatal_trap ud2 @@ -624,7 +625,7 @@ handle_ist_exception: movq %rdi,%rsp rep movsq 1: movq %rsp,%rdi - movl UREGS_entry_vector(%rsp),%eax + movzbl UREGS_entry_vector(%rsp),%eax leaq exception_table(%rip),%rdx callq *(%rdx,%rax,8) jmp ret_from_intr --- a/xen/arch/x86/x86_64/traps.c +++ b/xen/arch/x86/x86_64/traps.c @@ -67,10 +67,15 @@ static void _show_registers( regs->rbp, regs->rsp, regs->r8); printk("r9: %016lx r10: %016lx r11: %016lx\n", regs->r9, regs->r10, regs->r11); - printk("r12: %016lx r13: %016lx r14: %016lx\n", - regs->r12, regs->r13, regs->r14); - printk("r15: %016lx cr0: %016lx cr4: %016lx\n", - regs->r15, crs[0], crs[4]); + if ( !(regs->entry_vector & TRAP_regs_partial) ) + { + printk("r12: %016lx r13: %016lx r14: %016lx\n", + regs->r12, regs->r13, regs->r14); + printk("r15: %016lx cr0: %016lx cr4: %016lx\n", + regs->r15, crs[0], crs[4]); + } + else + printk("cr0: %016lx cr4: %016lx\n", crs[0], crs[4]); printk("cr3: %016lx cr2: %016lx\n", crs[3], crs[2]); printk("ds: %04x es: %04x fs: %04x gs: %04x " "ss: %04x cs: %04x\n", @@ -301,7 +306,7 @@ unsigned long do_iret(void) =20 if ( !(iret_saved.flags & VGCF_in_syscall) ) { - regs->entry_vector =3D 0; + regs->entry_vector &=3D ~TRAP_syscall; regs->r11 =3D iret_saved.r11; regs->rcx =3D iret_saved.rcx; } --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++ b/xen/arch/x86/x86_emulate/x86_emulate.c @@ -1292,10 +1292,10 @@ decode_register( case 9: p =3D ®s->r9; break; case 10: p =3D ®s->r10; break; case 11: p =3D ®s->r11; break; - case 12: p =3D ®s->r12; break; - case 13: p =3D ®s->r13; break; - case 14: p =3D ®s->r14; break; - case 15: p =3D ®s->r15; break; + case 12: mark_regs_dirty(regs); p =3D ®s->r12; break; + case 13: mark_regs_dirty(regs); p =3D ®s->r13; break; + case 14: mark_regs_dirty(regs); p =3D ®s->r14; break; + case 15: mark_regs_dirty(regs); p =3D ®s->r15; break; #endif default: BUG(); p =3D NULL; break; } --- a/xen/arch/x86/x86_emulate.c +++ b/xen/arch/x86/x86_emulate.c @@ -10,6 +10,7 @@ */ =20 #include +#include /* mark_regs_dirty() */ #include /* current_cpu_info */ #include /* cpu_has_amd_erratum() */ =20 --- a/xen/common/wait.c +++ b/xen/common/wait.c @@ -124,10 +124,12 @@ void wake_up_all(struct waitqueue_head * =20 static void __prepare_to_wait(struct waitqueue_vcpu *wqv) { - char *cpu_info =3D (char *)get_cpu_info(); + struct cpu_info *cpu_info =3D get_cpu_info(); struct vcpu *curr =3D current; unsigned long dummy; + u32 entry_vector =3D cpu_info->guest_cpu_user_regs.entry_vector; =20 + cpu_info->guest_cpu_user_regs.entry_vector &=3D ~TRAP_regs_partial; ASSERT(wqv->esp =3D=3D 0); =20 /* Save current VCPU affinity; force wakeup on *this* CPU only. */ @@ -157,6 +159,8 @@ static void __prepare_to_wait(struct wai gdprintk(XENLOG_ERR, "Stack too large in %s\n", __FUNCTION__); domain_crash_synchronous(); } + + cpu_info->guest_cpu_user_regs.entry_vector =3D entry_vector; } =20 static void __finish_wait(struct waitqueue_vcpu *wqv) --- a/xen/include/asm-x86/x86_64/asm_defns.h +++ b/xen/include/asm-x86/x86_64/asm_defns.h @@ -26,6 +26,17 @@ #define ASSERT_INTERRUPTS_ENABLED ASSERT_INTERRUPT_STATUS(nz) #define ASSERT_INTERRUPTS_DISABLED ASSERT_INTERRUPT_STATUS(z) =20 +#define _TRAP_regs_partial 16 +#define _TRAP_regs_dirty 17 +#define TRAP_regs_partial (1 << _TRAP_regs_partial) +#define TRAP_regs_dirty (1 << _TRAP_regs_dirty) + +#define mark_regs_dirty(r) ({ \ + struct cpu_user_regs *r__ =3D (r); \ + ASSERT(!((r__)->entry_vector & TRAP_regs_partial)); \ + r__->entry_vector |=3D TRAP_regs_dirty; \ +}) + #define SAVE_ALL \ addq $-(UREGS_error_code-UREGS_r15), %rsp; \ cld; \ @@ -47,11 +58,49 @@ movq %r15,UREGS_r15(%rsp); \ =20 #ifdef __ASSEMBLY__ -.macro LOAD_C_CLOBBERED + +.macro SAVE_VOLATILE type compat=3D0 +.if \compat + movl $\type,UREGS_entry_vector-UREGS_error_code(%rsp) +.else + movl $\type|TRAP_regs_partial,\ + UREGS_entry_vector-UREGS_error_code(%rsp) +.endif + addq $-(UREGS_error_code-UREGS_r15),%rsp + cld + movq %rdi,UREGS_rdi(%rsp) + movq %rsi,UREGS_rsi(%rsp) + movq %rdx,UREGS_rdx(%rsp) + movq %rcx,UREGS_rcx(%rsp) + movq %rax,UREGS_rax(%rsp) +.if !\compat + movq %r8,UREGS_r8(%rsp) + movq %r9,UREGS_r9(%rsp) + movq %r10,UREGS_r10(%rsp) + movq %r11,UREGS_r11(%rsp) +.endif + movq %rbx,UREGS_rbx(%rsp) + movq %rbp,UREGS_rbp(%rsp) + SETUP_EXCEPTION_FRAME_POINTER(UREGS_rbp) +.endm + +.macro SAVE_PRESERVED + btrl $_TRAP_regs_partial,UREGS_entry_vector(%rsp) + jnc 987f + movq %r12,UREGS_r12(%rsp) + movq %r13,UREGS_r13(%rsp) + movq %r14,UREGS_r14(%rsp) + movq %r15,UREGS_r15(%rsp) +987: +.endm + +.macro LOAD_C_CLOBBERED compat=3D0 +.if !\compat movq UREGS_r11(%rsp),%r11 movq UREGS_r10(%rsp),%r10 movq UREGS_r9(%rsp),%r9 movq UREGS_r8(%rsp),%r8 +.endif movq UREGS_rax(%rsp),%rax movq UREGS_rcx(%rsp),%rcx movq UREGS_rdx(%rsp),%rdx @@ -59,16 +108,38 @@ movq UREGS_rdi(%rsp),%rdi .endm =20 -.macro RESTORE_ALL adj=3D0 +.macro RESTORE_ALL adj=3D0 compat=3D0 +.if !\compat + testl $TRAP_regs_dirty,UREGS_entry_vector(%rsp) +.endif + LOAD_C_CLOBBERED \compat +.if !\compat + jz 987f movq UREGS_r15(%rsp),%r15 movq UREGS_r14(%rsp),%r14 movq UREGS_r13(%rsp),%r13 movq UREGS_r12(%rsp),%r12 - movq UREGS_rbp(%rsp),%rbp +#ifndef NDEBUG + .subsection 1 +987: testl $TRAP_regs_partial,UREGS_entry_vector(%rsp) + jnz 987f + cmpq UREGS_r15(%rsp),%r15 + jne 789f + cmpq UREGS_r14(%rsp),%r14 + jne 789f + cmpq UREGS_r13(%rsp),%r13 + jne 789f + cmpq UREGS_r12(%rsp),%r12 + je 987f +789: ud2 + .subsection 0 +#endif +.endif +987: movq UREGS_rbp(%rsp),%rbp movq UREGS_rbx(%rsp),%rbx - LOAD_C_CLOBBERED subq $-(UREGS_error_code-UREGS_r15+\adj), %rsp .endm + #endif =20 #ifdef PERF_COUNTERS --=__PartB48582E0.0__= Content-Type: text/plain; name="x86-save-restore-reduce.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="x86-save-restore-reduce.patch" x86: save/restore only partial register state where possible=0A=0A... and = make restore conditional not only upon having saved the state,=0Abut also = upon whether saved state was actually modified (and register=0Avalues are = known to have been preserved).=0A=0ANote that RBP is unconditionally = considered a volatile register (i.e.=0Airrespective of CONFIG_FRAME_POINTER= ), since the RBP handling would=0Abecome overly complicated due to the = need to save/restore it on the=0Acompat mode hypercall path [6th argument].= =0A=0ANote further that for compat mode code paths, saving/restoring = R8...R15=0Ais entirely unnecessary - we don't allow those guests to enter = 64-bit=0Amode, and hence they have no way of seeing these registers' = contents=0A(and there consequently also is no information leak, except if = the=0Acontext saving domctl would be considered such).=0A=0AFinally, note = that this may not properly deal with gdbstub's needs, yet=0A(but if so, I = can't really suggest adjustments, as I don't know that=0Acode).=0A=0ASigned= -off-by: Jan Beulich =0A=0A--- a/tools/tests/x86_emulato= r/x86_emulate.c=0A+++ b/tools/tests/x86_emulator/x86_emulate.c=0A@@ -10,6 = +10,7 @@ typedef bool bool_t;=0A #define BUG() abort()=0A =0A #define = cpu_has_amd_erratum(nr) 0=0A+#define mark_regs_dirty(r) ((void)(r))=0A =0A = #include "x86_emulate/x86_emulate.h"=0A #include "x86_emulate/x86_emulate.c= "=0A--- a/xen/arch/x86/domain.c=0A+++ b/xen/arch/x86/domain.c=0A@@ -138,6 = +138,7 @@ static void continue_idle_domain(struct =0A static void = continue_nonidle_domain(struct vcpu *v)=0A {=0A check_wakeup_from_wait(= );=0A+ mark_regs_dirty(guest_cpu_user_regs());=0A reset_stack_and_ju= mp(ret_from_intr);=0A }=0A =0A@@ -1307,7 +1308,7 @@ static void load_segmen= ts(struct vcpu *n=0A if ( test_bit(_VGCF_failsafe_disables_even= ts, &n->arch.vgc_flags) )=0A vcpu_info(n, evtchn_upcall_mas= k) =3D 1;=0A =0A- regs->entry_vector =3D TRAP_syscall;=0A+ = regs->entry_vector |=3D TRAP_syscall;=0A regs->_eflags = &=3D 0xFFFCBEFFUL;=0A regs->ss =3D FLAT_COMPAT_K= ERNEL_SS;=0A regs->_esp =3D (unsigned long)(esp-7);=0A= @@ -1349,7 +1350,7 @@ static void load_segments(struct vcpu *n=0A = if ( test_bit(_VGCF_failsafe_disables_events, &n->arch.vgc_flags) )=0A = vcpu_info(n, evtchn_upcall_mask) =3D 1;=0A =0A- regs->entry_= vector =3D TRAP_syscall;=0A+ regs->entry_vector |=3D TRAP_syscall;= =0A regs->rflags &=3D ~(X86_EFLAGS_AC|X86_EFLAGS_VM|X86_EFLAG= S_RF|=0A X86_EFLAGS_NT|X86_EFLAGS_TF);=0A = regs->ss =3D FLAT_KERNEL_SS;=0A--- a/xen/arch/x86/irq.c= =0A+++ b/xen/arch/x86/irq.c=0A@@ -704,7 +704,7 @@ void irq_complete_move(st= ruct irq_desc *=0A if (likely(!desc->arch.move_in_progress))=0A = return;=0A =0A- vector =3D get_irq_regs()->entry_vector;=0A+ vector = =3D (u8)get_irq_regs()->entry_vector;=0A me =3D smp_processor_id();=0A = =0A if ( vector =3D=3D desc->arch.vector &&=0A@@ -798,7 +798,7 @@ void = do_IRQ(struct cpu_user_regs *regs)=0A struct irqaction *action;=0A = uint32_t tsc_in;=0A struct irq_desc *desc;=0A- unsigned = int vector =3D regs->entry_vector;=0A+ unsigned int vector = =3D (u8)regs->entry_vector;=0A int irq =3D __get_cpu_var(vector_irq[vec= tor]);=0A struct cpu_user_regs *old_regs =3D set_irq_regs(regs);=0A = =0A@@ -892,7 +892,7 @@ void do_IRQ(struct cpu_user_regs *regs)=0A =0A = out:=0A if ( desc->handler->end )=0A- desc->handler->end(desc, = regs->entry_vector);=0A+ desc->handler->end(desc, vector);=0A = out_no_end:=0A spin_unlock(&desc->lock);=0A out_no_unlock:=0A@@ = -1113,7 +1113,7 @@ static void __do_IRQ_guest(int irq)=0A struct = domain *d;=0A int i, sp;=0A struct pending_eoi= *peoi =3D this_cpu(pending_eoi);=0A- int vector =3D get_irq_regs()->ent= ry_vector;=0A+ unsigned int vector =3D (u8)get_irq_regs()->entry_= vector;=0A =0A if ( unlikely(action->nr_guests =3D=3D 0) )=0A = {=0A--- a/xen/arch/x86/traps.c=0A+++ b/xen/arch/x86/traps.c=0A@@ -2082,6 = +2082,7 @@ static int emulate_privileged_op(struct =0A goto = fail;=0A if ( admin_io_okay(port, op_bytes, v, regs) )=0A = {=0A+ mark_regs_dirty(regs);=0A io_emul(regs); = =0A }=0A else=0A@@ -2111,6 +2112,7 @@ static int = emulate_privileged_op(struct =0A goto fail;=0A if ( = admin_io_okay(port, op_bytes, v, regs) )=0A {=0A+ = mark_regs_dirty(regs);=0A io_emul(regs); =0A = if ( (op_bytes =3D=3D 1) && pv_post_outb_hook )=0A = pv_post_outb_hook(port, regs->eax);=0A--- a/xen/arch/x86/x86_64/compat/entr= y.S=0A+++ b/xen/arch/x86/x86_64/compat/entry.S=0A@@ -14,8 +14,7 @@=0A =0A = ENTRY(compat_hypercall)=0A pushq $0=0A- movl $TRAP_syscall,= 4(%rsp)=0A- SAVE_ALL=0A+ SAVE_VOLATILE type=3DTRAP_syscall = compat=3D1=0A =0A cmpb $0,untrusted_msi(%rip)=0A UNLIKELY_START(ne= , msi_check)=0A@@ -126,6 +125,7 @@ compat_test_guest_events:=0A /* %rbx: = struct vcpu */=0A compat_process_softirqs:=0A sti=0A+ andl = $~TRAP_regs_partial,UREGS_entry_vector(%rsp)=0A call do_softirq=0A= jmp compat_test_all_events=0A =0A@@ -172,7 +172,7 @@ compat_bad_= hypercall:=0A /* %rbx: struct vcpu, interrupts disabled */=0A compat_restor= e_all_guest:=0A ASSERT_INTERRUPTS_DISABLED=0A- RESTORE_ALL = adj=3D8=0A+ RESTORE_ALL adj=3D8 compat=3D1=0A .Lft0: iretq=0A =0A = .section .fixup,"ax"=0A@@ -243,7 +243,7 @@ UNLIKELY_END(compat_syscall_gpf)= =0A =0A ENTRY(compat_sysenter)=0A movq VCPU_trap_ctxt(%rbx),%rcx= =0A- cmpl $TRAP_gp_fault,UREGS_entry_vector(%rsp)=0A+ cmpb = $TRAP_gp_fault,UREGS_entry_vector(%rsp)=0A movzwl VCPU_sysenter_sel= (%rbx),%eax=0A movzwl TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_cs= (%rcx),%ecx=0A cmovel %ecx,%eax=0A--- a/xen/arch/x86/x86_64/entry.S= =0A+++ b/xen/arch/x86/x86_64/entry.S=0A@@ -123,9 +123,8 @@ ENTRY(syscall_en= ter)=0A movl $FLAT_KERNEL_SS,24(%rsp)=0A pushq %rcx=0A = pushq $0=0A- movl $TRAP_syscall,4(%rsp)=0A- movq = 24(%rsp),%r11 /* Re-load user RFLAGS into %r11 before SAVE_ALL */=0A- = SAVE_ALL=0A+ movq 24(%rsp),%r11 /* Re-load user RFLAGS into %r11 = before saving */=0A+ SAVE_VOLATILE TRAP_syscall=0A = GET_CURRENT(%rbx)=0A movq VCPU_domain(%rbx),%rcx=0A testb = $1,DOMAIN_is_32bit_pv(%rcx)=0A@@ -222,6 +221,7 @@ test_guest_events:=0A /* = %rbx: struct vcpu */=0A process_softirqs:=0A sti =0A+ = SAVE_PRESERVED=0A call do_softirq=0A jmp test_all_events= =0A =0A@@ -275,8 +275,7 @@ sysenter_eflags_saved:=0A pushq $3 /* = ring 3 null cs */=0A pushq $0 /* null rip */=0A pushq = $0=0A- movl $TRAP_syscall,4(%rsp)=0A- SAVE_ALL=0A+ = SAVE_VOLATILE TRAP_syscall=0A GET_CURRENT(%rbx)=0A cmpb = $0,VCPU_sysenter_disables_events(%rbx)=0A movq VCPU_sysenter_addr(= %rbx),%rax=0A@@ -286,6 +285,7 @@ sysenter_eflags_saved:=0A leal = (,%rcx,TBF_INTERRUPT),%ecx=0A UNLIKELY_START(z, sysenter_gpf)=0A = movq VCPU_trap_ctxt(%rbx),%rsi=0A+ SAVE_PRESERVED=0A movl = $TRAP_gp_fault,UREGS_entry_vector(%rsp)=0A movl %eax,TRAPBOUNCE_er= ror_code(%rdx)=0A movq TRAP_gp_fault * TRAPINFO_sizeof + = TRAPINFO_eip(%rsi),%rax=0A@@ -302,7 +302,7 @@ UNLIKELY_END(sysenter_gpf)=0A= =0A ENTRY(int80_direct_trap)=0A pushq $0=0A- SAVE_ALL=0A+ = SAVE_VOLATILE 0x80=0A =0A cmpb $0,untrusted_msi(%rip)=0A = UNLIKELY_START(ne, msi_check)=0A@@ -331,6 +331,7 @@ int80_slow_path:=0A = * IDT entry with DPL=3D=3D0.=0A */=0A movl $((0x80 = << 3) | 0x2),UREGS_error_code(%rsp)=0A+ SAVE_PRESERVED=0A = movl $TRAP_gp_fault,UREGS_entry_vector(%rsp)=0A /* A GPF wouldn't = have incremented the instruction pointer. */=0A subq $2,UREGS_rip(= %rsp)=0A@@ -412,7 +413,7 @@ UNLIKELY_END(bounce_failsafe)=0A /* = Rewrite our stack frame and return to guest-OS mode. */=0A /* IA32 = Ref. Vol. 3: TF, VM, RF and NT flags are cleared on trap. */=0A /* = Also clear AC: alignment checks shouldn't trigger in kernel mode. */=0A- = movl $TRAP_syscall,UREGS_entry_vector+8(%rsp)=0A+ orl = $TRAP_syscall,UREGS_entry_vector+8(%rsp)=0A andl $~(X86_EFLAGS_AC|= X86_EFLAGS_VM|X86_EFLAGS_RF|\=0A X86_EFLAGS_NT|X86_EFLAGS_= TF),UREGS_eflags+8(%rsp)=0A movq $FLAT_KERNEL_SS,UREGS_ss+8(%rsp)= =0A@@ -477,7 +478,7 @@ handle_exception_saved:=0A jz exception_w= ith_ints_disabled=0A sti=0A 1: movq %rsp,%rdi=0A- = movl UREGS_entry_vector(%rsp),%eax=0A+ movzbl UREGS_entry_vector(%r= sp),%eax=0A leaq exception_table(%rip),%rdx=0A GET_CURRENT= (%rbx)=0A PERFC_INCR(exceptions, %rax, %rbx)=0A@@ -518,7 +519,7 @@ = exception_with_ints_disabled:=0A =0A /* No special register assumptions. = */=0A FATAL_exception_with_ints_disabled:=0A- movl UREGS_entry_vect= or(%rsp),%edi=0A+ movzbl UREGS_entry_vector(%rsp),%edi=0A = movq %rsp,%rsi=0A call fatal_trap=0A ud2=0A@@ -624,7 = +625,7 @@ handle_ist_exception:=0A movq %rdi,%rsp=0A rep = movsq=0A 1: movq %rsp,%rdi=0A- movl UREGS_entry_vector(%rsp)= ,%eax=0A+ movzbl UREGS_entry_vector(%rsp),%eax=0A leaq = exception_table(%rip),%rdx=0A callq *(%rdx,%rax,8)=0A jmp = ret_from_intr=0A--- a/xen/arch/x86/x86_64/traps.c=0A+++ b/xen/arch/x86/x86= _64/traps.c=0A@@ -67,10 +67,15 @@ static void _show_registers(=0A = regs->rbp, regs->rsp, regs->r8);=0A printk("r9: %016lx r10: = %016lx r11: %016lx\n",=0A regs->r9, regs->r10, regs->r11);=0A= - printk("r12: %016lx r13: %016lx r14: %016lx\n",=0A- = regs->r12, regs->r13, regs->r14);=0A- printk("r15: %016lx cr0: %016lx = cr4: %016lx\n",=0A- regs->r15, crs[0], crs[4]);=0A+ if ( = !(regs->entry_vector & TRAP_regs_partial) )=0A+ {=0A+ printk("r12= : %016lx r13: %016lx r14: %016lx\n",=0A+ regs->r12, = regs->r13, regs->r14);=0A+ printk("r15: %016lx cr0: %016lx cr4: = %016lx\n",=0A+ regs->r15, crs[0], crs[4]);=0A+ }=0A+ = else=0A+ printk("cr0: %016lx cr4: %016lx\n", crs[0], crs[4]);=0A = printk("cr3: %016lx cr2: %016lx\n", crs[3], crs[2]);=0A printk("ds= : %04x es: %04x fs: %04x gs: %04x "=0A "ss: %04x cs: = %04x\n",=0A@@ -301,7 +306,7 @@ unsigned long do_iret(void)=0A =0A if ( = !(iret_saved.flags & VGCF_in_syscall) )=0A {=0A- regs->entry_vec= tor =3D 0;=0A+ regs->entry_vector &=3D ~TRAP_syscall;=0A = regs->r11 =3D iret_saved.r11;=0A regs->rcx =3D iret_saved.rcx;=0A = }=0A--- a/xen/arch/x86/x86_emulate/x86_emulate.c=0A+++ b/xen/arch/x86/x8= 6_emulate/x86_emulate.c=0A@@ -1292,10 +1292,10 @@ decode_register(=0A = case 9: p =3D ®s->r9; break;=0A case 10: p =3D ®s->r10; = break;=0A case 11: p =3D ®s->r11; break;=0A- case 12: p =3D = ®s->r12; break;=0A- case 13: p =3D ®s->r13; break;=0A- case = 14: p =3D ®s->r14; break;=0A- case 15: p =3D ®s->r15; break;=0A+ = case 12: mark_regs_dirty(regs); p =3D ®s->r12; break;=0A+ case 13: = mark_regs_dirty(regs); p =3D ®s->r13; break;=0A+ case 14: mark_regs_d= irty(regs); p =3D ®s->r14; break;=0A+ case 15: mark_regs_dirty(regs);= p =3D ®s->r15; break;=0A #endif=0A default: BUG(); p =3D NULL; = break;=0A }=0A--- a/xen/arch/x86/x86_emulate.c=0A+++ b/xen/arch/x86/x86= _emulate.c=0A@@ -10,6 +10,7 @@=0A */=0A =0A #include = =0A+#include /* mark_regs_dirty() */=0A #include = /* current_cpu_info */=0A #include /* = cpu_has_amd_erratum() */=0A =0A--- a/xen/common/wait.c=0A+++ b/xen/common/w= ait.c=0A@@ -124,10 +124,12 @@ void wake_up_all(struct waitqueue_head *=0A = =0A static void __prepare_to_wait(struct waitqueue_vcpu *wqv)=0A {=0A- = char *cpu_info =3D (char *)get_cpu_info();=0A+ struct cpu_info = *cpu_info =3D get_cpu_info();=0A struct vcpu *curr =3D current;=0A = unsigned long dummy;=0A+ u32 entry_vector =3D cpu_info->guest_cpu_user_r= egs.entry_vector;=0A =0A+ cpu_info->guest_cpu_user_regs.entry_vector = &=3D ~TRAP_regs_partial;=0A ASSERT(wqv->esp =3D=3D 0);=0A =0A /* = Save current VCPU affinity; force wakeup on *this* CPU only. */=0A@@ = -157,6 +159,8 @@ static void __prepare_to_wait(struct wai=0A = gdprintk(XENLOG_ERR, "Stack too large in %s\n", __FUNCTION__);=0A = domain_crash_synchronous();=0A }=0A+=0A+ cpu_info->guest_cpu_user_re= gs.entry_vector =3D entry_vector;=0A }=0A =0A static void __finish_wait(str= uct waitqueue_vcpu *wqv)=0A--- a/xen/include/asm-x86/x86_64/asm_defns.h=0A+= ++ b/xen/include/asm-x86/x86_64/asm_defns.h=0A@@ -26,6 +26,17 @@=0A = #define ASSERT_INTERRUPTS_ENABLED ASSERT_INTERRUPT_STATUS(nz)=0A #define = ASSERT_INTERRUPTS_DISABLED ASSERT_INTERRUPT_STATUS(z)=0A =0A+#define = _TRAP_regs_partial 16=0A+#define _TRAP_regs_dirty 17=0A+#define = TRAP_regs_partial (1 << _TRAP_regs_partial)=0A+#define TRAP_regs_dirty = (1 << _TRAP_regs_dirty)=0A+=0A+#define mark_regs_dirty(r) ({ \=0A+ = struct cpu_user_regs *r__ =3D (r); \=0A+ ASSERT(!((r__)->entry_vecto= r & TRAP_regs_partial)); \=0A+ r__->entry_vector |=3D TRAP_regs_dirt= y; \=0A+})=0A+=0A #define SAVE_ALL \=0A = addq $-(UREGS_error_code-UREGS_r15), %rsp; \=0A cld; = \=0A@@ -47,11 +58,49 @@=0A movq = %r15,UREGS_r15(%rsp); \=0A =0A #ifdef __ASSEMBLY__=0A-.macro = LOAD_C_CLOBBERED=0A+=0A+.macro SAVE_VOLATILE type compat=3D0=0A+.if = \compat=0A+ movl $\type,UREGS_entry_vector-UREGS_error_code(%rsp)= =0A+.else=0A+ movl $\type|TRAP_regs_partial,\=0A+ = UREGS_entry_vector-UREGS_error_code(%rsp)=0A+.endif=0A+ addq = $-(UREGS_error_code-UREGS_r15),%rsp=0A+ cld=0A+ movq = %rdi,UREGS_rdi(%rsp)=0A+ movq %rsi,UREGS_rsi(%rsp)=0A+ movq = %rdx,UREGS_rdx(%rsp)=0A+ movq %rcx,UREGS_rcx(%rsp)=0A+ = movq %rax,UREGS_rax(%rsp)=0A+.if !\compat=0A+ movq %r8,UREGS_r8(%r= sp)=0A+ movq %r9,UREGS_r9(%rsp)=0A+ movq %r10,UREGS_r10(%rs= p)=0A+ movq %r11,UREGS_r11(%rsp)=0A+.endif=0A+ movq = %rbx,UREGS_rbx(%rsp)=0A+ movq %rbp,UREGS_rbp(%rsp)=0A+ = SETUP_EXCEPTION_FRAME_POINTER(UREGS_rbp)=0A+.endm=0A+=0A+.macro SAVE_PRESER= VED=0A+ btrl $_TRAP_regs_partial,UREGS_entry_vector(%rsp)=0A+ = jnc 987f=0A+ movq %r12,UREGS_r12(%rsp)=0A+ movq = %r13,UREGS_r13(%rsp)=0A+ movq %r14,UREGS_r14(%rsp)=0A+ movq = %r15,UREGS_r15(%rsp)=0A+987:=0A+.endm=0A+=0A+.macro LOAD_C_CLOBBERED = compat=3D0=0A+.if !\compat=0A movq UREGS_r11(%rsp),%r11=0A = movq UREGS_r10(%rsp),%r10=0A movq UREGS_r9(%rsp),%r9=0A = movq UREGS_r8(%rsp),%r8=0A+.endif=0A movq UREGS_rax(%rsp),%rax=0A= movq UREGS_rcx(%rsp),%rcx=0A movq UREGS_rdx(%rsp),%rdx= =0A@@ -59,16 +108,38 @@=0A movq UREGS_rdi(%rsp),%rdi=0A .endm=0A = =0A-.macro RESTORE_ALL adj=3D0=0A+.macro RESTORE_ALL adj=3D0 compat=3D0=0A+= .if !\compat=0A+ testl $TRAP_regs_dirty,UREGS_entry_vector(%rsp)=0A+= .endif=0A+ LOAD_C_CLOBBERED \compat=0A+.if !\compat=0A+ jz = 987f=0A movq UREGS_r15(%rsp),%r15=0A movq UREGS_r14(%rsp= ),%r14=0A movq UREGS_r13(%rsp),%r13=0A movq UREGS_r12(%rs= p),%r12=0A- movq UREGS_rbp(%rsp),%rbp=0A+#ifndef NDEBUG=0A+ = .subsection 1=0A+987: testl $TRAP_regs_partial,UREGS_entry_vector(%rsp)= =0A+ jnz 987f=0A+ cmpq UREGS_r15(%rsp),%r15=0A+ = jne 789f=0A+ cmpq UREGS_r14(%rsp),%r14=0A+ jne 789f=0A+ = cmpq UREGS_r13(%rsp),%r13=0A+ jne 789f=0A+ cmpq = UREGS_r12(%rsp),%r12=0A+ je 987f=0A+789: ud2=0A+ = .subsection 0=0A+#endif=0A+.endif=0A+987: movq UREGS_rbp(%rsp),%rbp=0A = movq UREGS_rbx(%rsp),%rbx=0A- LOAD_C_CLOBBERED=0A = subq $-(UREGS_error_code-UREGS_r15+\adj), %rsp=0A .endm=0A+=0A #endif=0A = =0A #ifdef PERF_COUNTERS=0A --=__PartB48582E0.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --=__PartB48582E0.0__=-- From xen-devel-bounces@lists.xen.org Tue Oct 02 15:29:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 15:29:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4Pq-0003Pq-Mm; Tue, 02 Oct 2012 15:29:46 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4Pq-0003Pe-0f for xen-devel@lists.xen.org; Tue, 02 Oct 2012 15:29:46 +0000 Received: from [85.158.139.83:12648] by server-12.bemta-5.messagelabs.com id 61/89-20729-9680B605; Tue, 02 Oct 2012 15:29:45 +0000 X-Env-Sender: samuel.thibault@ens-lyon.org X-Msg-Ref: server-4.tower-182.messagelabs.com!1349191784!28557531!1 X-Originating-IP: [192.134.164.105] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20796 invoked from network); 2 Oct 2012 15:29:44 -0000 Received: from mail4-relais-sop.national.inria.fr (HELO mail4-relais-sop.national.inria.fr) (192.134.164.105) by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 15:29:44 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344204000"; d="scan'208";a="157608958" Received: from unknown (HELO type.ipv6) ([193.50.110.199]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 02 Oct 2012 17:29:44 +0200 Received: from samy by type.ipv6 with local (Exim 4.80) (envelope-from ) id 1TJ4Po-0004Zm-26; Tue, 02 Oct 2012 17:29:44 +0200 Date: Tue, 2 Oct 2012 17:29:44 +0200 From: Samuel Thibault To: Matthew Fioravante Message-ID: <20121002152944.GE19216@type.bordeaux.inria.fr> Mail-Followup-To: Samuel Thibault , Matthew Fioravante , xen-devel@lists.xen.org, Ian.Campbell@citrix.com References: <1349189004-17133-1-git-send-email-matthew.fioravante@jhuapl.edu> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1349189004-17133-1-git-send-email-matthew.fioravante@jhuapl.edu> User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30) Cc: Ian.Campbell@citrix.com, xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH 04/12] Disable the mfn_is_ram() check, it doesn't work correctly on all systems X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Matthew Fioravante, le Tue 02 Oct 2012 10:43:24 -0400, a =E9crit : > This patch disables the mfn_is_ram check in mini-os. The current check > is insufficient and fails on some systems with larger than 4gb memory. > = > Signed-off-by: Matthew Fioravante Acked-by: Samuel Thibault _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 15:29:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 15:29:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4Pq-0003Pq-Mm; Tue, 02 Oct 2012 15:29:46 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4Pq-0003Pe-0f for xen-devel@lists.xen.org; Tue, 02 Oct 2012 15:29:46 +0000 Received: from [85.158.139.83:12648] by server-12.bemta-5.messagelabs.com id 61/89-20729-9680B605; Tue, 02 Oct 2012 15:29:45 +0000 X-Env-Sender: samuel.thibault@ens-lyon.org X-Msg-Ref: server-4.tower-182.messagelabs.com!1349191784!28557531!1 X-Originating-IP: [192.134.164.105] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20796 invoked from network); 2 Oct 2012 15:29:44 -0000 Received: from mail4-relais-sop.national.inria.fr (HELO mail4-relais-sop.national.inria.fr) (192.134.164.105) by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 15:29:44 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344204000"; d="scan'208";a="157608958" Received: from unknown (HELO type.ipv6) ([193.50.110.199]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 02 Oct 2012 17:29:44 +0200 Received: from samy by type.ipv6 with local (Exim 4.80) (envelope-from ) id 1TJ4Po-0004Zm-26; Tue, 02 Oct 2012 17:29:44 +0200 Date: Tue, 2 Oct 2012 17:29:44 +0200 From: Samuel Thibault To: Matthew Fioravante Message-ID: <20121002152944.GE19216@type.bordeaux.inria.fr> Mail-Followup-To: Samuel Thibault , Matthew Fioravante , xen-devel@lists.xen.org, Ian.Campbell@citrix.com References: <1349189004-17133-1-git-send-email-matthew.fioravante@jhuapl.edu> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1349189004-17133-1-git-send-email-matthew.fioravante@jhuapl.edu> User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30) Cc: Ian.Campbell@citrix.com, xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH 04/12] Disable the mfn_is_ram() check, it doesn't work correctly on all systems X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Matthew Fioravante, le Tue 02 Oct 2012 10:43:24 -0400, a =E9crit : > This patch disables the mfn_is_ram check in mini-os. The current check > is insufficient and fails on some systems with larger than 4gb memory. > = > Signed-off-by: Matthew Fioravante Acked-by: Samuel Thibault _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 15:31:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 15:31:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4RB-0003bG-Bu; Tue, 02 Oct 2012 15:31:09 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4R9-0003b5-IU for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 15:31:07 +0000 Received: from [85.158.143.99:41873] by server-2.bemta-4.messagelabs.com id 37/89-06610-AB80B605; Tue, 02 Oct 2012 15:31:06 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1349191865!32616230!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 980 invoked from network); 2 Oct 2012 15:31:06 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 15:31:06 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="14898130" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 15:31:05 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 16:31:05 +0100 Date: Tue, 2 Oct 2012 16:30:06 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Jan Beulich In-Reply-To: <506B236C020000780009F281@nat28.tlf.novell.com> Message-ID: References: <506B236C020000780009F281@nat28.tlf.novell.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: "sfr@canb.auug.org.au" , Konrad Rzeszutek Wilk , "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH] xen/Makefile: resolve merge conflict with 9fa5780beea1 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2 Oct 2012, Jan Beulich wrote: > >>> On 02.10.12 at 17:13, Stefano Stabellini wrote: > > This patch is actually a merge conflict resolution between Konrad's Xen > > tree and the following commit: > > > > commit 9fa5780beea1274d498a224822397100022da7d4 > > Author: Jan Beulich > > Date: Tue Sep 18 12:23:02 2012 +0100 > > > > USB EHCI/Xen: propagate controller reset information to hypervisor > > > > > > Compile dbgp.o only if CONFIG_USB is defined. > > Now this is wrong: USB is a tristate config option, yet dbgp.o > must be built in. This is why I suggested to use USB_SUPPORT > (if anything at all). I see. You are right. I'll re-send the patch. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 15:31:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 15:31:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4RB-0003bG-Bu; Tue, 02 Oct 2012 15:31:09 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4R9-0003b5-IU for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 15:31:07 +0000 Received: from [85.158.143.99:41873] by server-2.bemta-4.messagelabs.com id 37/89-06610-AB80B605; Tue, 02 Oct 2012 15:31:06 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1349191865!32616230!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 980 invoked from network); 2 Oct 2012 15:31:06 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 15:31:06 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="14898130" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 15:31:05 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 16:31:05 +0100 Date: Tue, 2 Oct 2012 16:30:06 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Jan Beulich In-Reply-To: <506B236C020000780009F281@nat28.tlf.novell.com> Message-ID: References: <506B236C020000780009F281@nat28.tlf.novell.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: "sfr@canb.auug.org.au" , Konrad Rzeszutek Wilk , "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH] xen/Makefile: resolve merge conflict with 9fa5780beea1 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2 Oct 2012, Jan Beulich wrote: > >>> On 02.10.12 at 17:13, Stefano Stabellini wrote: > > This patch is actually a merge conflict resolution between Konrad's Xen > > tree and the following commit: > > > > commit 9fa5780beea1274d498a224822397100022da7d4 > > Author: Jan Beulich > > Date: Tue Sep 18 12:23:02 2012 +0100 > > > > USB EHCI/Xen: propagate controller reset information to hypervisor > > > > > > Compile dbgp.o only if CONFIG_USB is defined. > > Now this is wrong: USB is a tristate config option, yet dbgp.o > must be built in. This is why I suggested to use USB_SUPPORT > (if anything at all). I see. You are right. I'll re-send the patch. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 15:43:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 15:43:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4dF-00041c-LV; Tue, 02 Oct 2012 15:43:37 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4dD-00041X-EX for xen-devel@lists.xen.org; Tue, 02 Oct 2012 15:43:35 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1349192608!7640265!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10244 invoked from network); 2 Oct 2012 15:43:29 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 15:43:29 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="14898451" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 15:43:27 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 16:43:27 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TJ4d5-0002Gz-2p; Tue, 02 Oct 2012 15:43:27 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TJ4d4-00066i-U8; Tue, 02 Oct 2012 16:43:26 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20587.2974.838248.954668@mariner.uk.xensource.com> Date: Tue, 2 Oct 2012 16:43:26 +0100 To: Matthew Fioravante Newsgroups: chiark.mail.xen.devel In-Reply-To: <506B050E.2090705@jhuapl.edu> References: <1349122340-13436-1-git-send-email-matthew.fioravante@jhuapl.edu> <20587.720.26324.396214@mariner.uk.xensource.com> <506B050E.2090705@jhuapl.edu> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: "keir@xen.org" , "Ian.Campbell@citrix.com" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] Matthew Fioravante now maintains VTPM X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Matthew Fioravante writes ("Re: [Xen-devel] [PATCH] Matthew Fioravante now maintains VTPM"): > On 10/02/2012 11:05 AM, Ian Jackson wrote: > > Matthew Fioravante writes ("[Xen-devel] [PATCH] Matthew Fioravante now maintains VTPM"): > >> See MAINTAINERS file > > I think it is a good idea to formally record your maintainership, > > thanks. > Sorry, what exactly do you mean by that? Do you need a formal statement > in email? A statement in the patch commit description? I meant that this is exactly what you are doing with your MAINTAINERS file patch, of which I approve. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 15:43:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 15:43:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4dF-00041c-LV; Tue, 02 Oct 2012 15:43:37 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4dD-00041X-EX for xen-devel@lists.xen.org; Tue, 02 Oct 2012 15:43:35 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1349192608!7640265!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10244 invoked from network); 2 Oct 2012 15:43:29 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 15:43:29 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="14898451" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 15:43:27 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 16:43:27 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TJ4d5-0002Gz-2p; Tue, 02 Oct 2012 15:43:27 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TJ4d4-00066i-U8; Tue, 02 Oct 2012 16:43:26 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20587.2974.838248.954668@mariner.uk.xensource.com> Date: Tue, 2 Oct 2012 16:43:26 +0100 To: Matthew Fioravante Newsgroups: chiark.mail.xen.devel In-Reply-To: <506B050E.2090705@jhuapl.edu> References: <1349122340-13436-1-git-send-email-matthew.fioravante@jhuapl.edu> <20587.720.26324.396214@mariner.uk.xensource.com> <506B050E.2090705@jhuapl.edu> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: "keir@xen.org" , "Ian.Campbell@citrix.com" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] Matthew Fioravante now maintains VTPM X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Matthew Fioravante writes ("Re: [Xen-devel] [PATCH] Matthew Fioravante now maintains VTPM"): > On 10/02/2012 11:05 AM, Ian Jackson wrote: > > Matthew Fioravante writes ("[Xen-devel] [PATCH] Matthew Fioravante now maintains VTPM"): > >> See MAINTAINERS file > > I think it is a good idea to formally record your maintainership, > > thanks. > Sorry, what exactly do you mean by that? Do you need a formal statement > in email? A statement in the patch commit description? I meant that this is exactly what you are doing with your MAINTAINERS file patch, of which I approve. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 15:56:57 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 15:56:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4pr-0004C0-JZ; Tue, 02 Oct 2012 15:56:39 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4pp-0004Bs-Om for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 15:56:38 +0000 Received: from [85.158.138.51:63877] by server-8.bemta-3.messagelabs.com id 55/E9-16337-4BE0B605; Tue, 02 Oct 2012 15:56:36 +0000 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-14.tower-174.messagelabs.com!1349193395!26491898!1 X-Originating-IP: [74.125.83.43] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1837 invoked from network); 2 Oct 2012 15:56:35 -0000 Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com) (74.125.83.43) by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 15:56:35 -0000 Received: by eekc13 with SMTP id c13so3287407eek.30 for ; Tue, 02 Oct 2012 08:56:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=YCIaqPs7vKVStF3uXLx6cky/4pkT3g/pdKOesdEoWKs=; b=SVwspt+ldA7h93+d8koS9WqmTd4Xf6ScStM0me1hIOAk35HEqAhiy1NlD7icdhxdKQ thOXxyBttggDBktBY0BAA7lsZVUHOIH4C9lVQs6NNLsXeSABMeoydMZo2iHxSBuSt3ev hV00AL81p/haLfvBF1EIeUxYDZ4hE6LwHe2jxBH3vWqp9H0OoNcdVckgYEK/olS5Cftz Q8w97EMxYVMY4npyn3s+FBSTE42nLaWaRRi5VfBCJm0ZOOwYUR8KPzC/QLbgGJhl9dV+ IkgxeboKolRzgJlCtkEe2IhtJ/ymx5rQ/p8dbPiZpf+IxniNUCSua0M+0BUPD6LnaqLz RXeg== MIME-Version: 1.0 Received: by 10.14.212.72 with SMTP id x48mr22691305eeo.40.1349193395272; Tue, 02 Oct 2012 08:56:35 -0700 (PDT) Received: by 10.14.215.195 with HTTP; Tue, 2 Oct 2012 08:56:35 -0700 (PDT) In-Reply-To: <1349113629-6338-2-git-send-email-david.vrabel@citrix.com> References: <1349113629-6338-1-git-send-email-david.vrabel@citrix.com> <1349113629-6338-2-git-send-email-david.vrabel@citrix.com> Date: Tue, 2 Oct 2012 16:56:35 +0100 X-Google-Sender-Auth: K0sZa2p9glbIeG0NzR8fkP9EOkM Message-ID: From: George Dunlap To: David Vrabel Cc: Frediano Ziglio , xen-devel@lists.xensource.com Subject: Re: [Xen-devel] [PATCH 1/3] trace: allow for different sub-classes of TRC_PV_* tracepoints X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, Oct 1, 2012 at 6:47 PM, David Vrabel wrote: > From: David Vrabel > > We want to add additional sub-classes for TRC_PV tracepoints and to be > able to only capture these new sub-classes. This cannot currently be > done as the existing tracepoints all use a sub-class of 0xf. > > So, redefine the PV events to use a new sub-class. All the current > tracepoints are tracing entry points to the hypervisor so the > sub-class is named TRC_PV_ENTRY. > > This change does not affect xenalyze as that only looks at the main > class and the event number and does not use the sub-class field. > > Signed-off-by: Frediano Ziglio > Signed-off-by: David Vrabel > Acked-by: George Dunlap Ack re-confirmed. > --- > tools/xentrace/formats | 44 ++++++++++++++++++++++---------------------- > xen/include/public/trace.h | 35 +++++++++++++++++++++-------------- > 2 files changed, 43 insertions(+), 36 deletions(-) > > diff --git a/tools/xentrace/formats b/tools/xentrace/formats > index 04e54d5..71220c0 100644 > --- a/tools/xentrace/formats > +++ b/tools/xentrace/formats > @@ -82,28 +82,28 @@ > 0x0010f002 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) page_grant_unmap [ domid = %(1)d ] > 0x0010f003 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) page_grant_transfer [ domid = %(1)d ] > > -0x0020f001 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) hypercall [ eip = 0x%(1)08x, eax = 0x%(2)08x ] > -0x0020f101 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) hypercall [ rip = 0x%(2)08x%(1)08x, eax = 0x%(3)08x ] > -0x0020f003 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) trap [ eip = 0x%(1)08x, trapnr:error = 0x%(2)08x ] > -0x0020f103 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) trap [ rip = 0x%(2)08x%(1)08x, trapnr:error = 0x%(3)08x ] > -0x0020f004 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) page_fault [ eip = 0x%(1)08x, addr = 0x%(2)08x, error = 0x%(3)08x ] > -0x0020f104 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) page_fault [ rip = 0x%(2)08x%(1)08x, addr = 0x%(4)08x%(3)08x, error = 0x%(5)08x ] > -0x0020f005 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) forced_invalid_op [ eip = 0x%(1)08x ] > -0x0020f105 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) forced_invalid_op [ rip = 0x%(2)08x%(1)08x ] > -0x0020f006 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) emulate_privop [ eip = 0x%(1)08x ] > -0x0020f106 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) emulate_privop [ rip = 0x%(2)08x%(1)08x ] > -0x0020f007 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) emulate_4G [ eip = 0x%(1)08x ] > -0x0020f107 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) emulate_4G [ rip = 0x%(2)08x%(1)08x ] > -0x0020f008 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) math_state_restore > -0x0020f108 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) math_state_restore > -0x0020f009 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) paging_fixup [ eip = 0x%(1)08x, addr = 0x%(2)08x ] > -0x0020f109 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) paging_fixup [ rip = 0x%(2)08x%(1)08x, addr = 0x%(4)08x%(3)08x ] > -0x0020f00a CPU%(cpu)d %(tsc)d (+%(reltsc)8d) gdt_ldt_mapping_fault [ eip = 0x%(1)08x, offset = 0x%(2)08x ] > -0x0020f10a CPU%(cpu)d %(tsc)d (+%(reltsc)8d) gdt_ldt_mapping_fault [ rip = 0x%(2)08x%(1)08x, offset = 0x%(4)08x%(3)08x ] > -0x0020f00b CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation [ addr = 0x%(3)08x, eip = 0x%(4)08x, npte = 0x%(2)08x%(1)08x ] > -0x0020f10b CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation [ addr = 0x%(4)08x%(3)08x, rip = 0x%(6)08x%(5)08x, npte = 0x%(2)08x%(1)08x ] > -0x0020f00c CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation_pae [ addr = 0x%(3)08x, eip = 0x%(4)08x, npte = 0x%(2)08x%(1)08x ] > -0x0020f10c CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation_pae [ addr = 0x%(4)08x%(3)08x, rip = 0x%(6)08x%(5)08x, npte = 0x%(2)08x%(1)08x ] > +0x00201001 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) hypercall [ eip = 0x%(1)08x, eax = 0x%(2)08x ] > +0x00201101 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) hypercall [ rip = 0x%(2)08x%(1)08x, eax = 0x%(3)08x ] > +0x00201003 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) trap [ eip = 0x%(1)08x, trapnr:error = 0x%(2)08x ] > +0x00201103 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) trap [ rip = 0x%(2)08x%(1)08x, trapnr:error = 0x%(3)08x ] > +0x00201004 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) page_fault [ eip = 0x%(1)08x, addr = 0x%(2)08x, error = 0x%(3)08x ] > +0x00201104 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) page_fault [ rip = 0x%(2)08x%(1)08x, addr = 0x%(4)08x%(3)08x, error = 0x%(5)08x ] > +0x00201005 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) forced_invalid_op [ eip = 0x%(1)08x ] > +0x00201105 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) forced_invalid_op [ rip = 0x%(2)08x%(1)08x ] > +0x00201006 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) emulate_privop [ eip = 0x%(1)08x ] > +0x00201106 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) emulate_privop [ rip = 0x%(2)08x%(1)08x ] > +0x00201007 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) emulate_4G [ eip = 0x%(1)08x ] > +0x00201107 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) emulate_4G [ rip = 0x%(2)08x%(1)08x ] > +0x00201008 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) math_state_restore > +0x00201108 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) math_state_restore > +0x00201009 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) paging_fixup [ eip = 0x%(1)08x, addr = 0x%(2)08x ] > +0x00201109 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) paging_fixup [ rip = 0x%(2)08x%(1)08x, addr = 0x%(4)08x%(3)08x ] > +0x0020100a CPU%(cpu)d %(tsc)d (+%(reltsc)8d) gdt_ldt_mapping_fault [ eip = 0x%(1)08x, offset = 0x%(2)08x ] > +0x0020110a CPU%(cpu)d %(tsc)d (+%(reltsc)8d) gdt_ldt_mapping_fault [ rip = 0x%(2)08x%(1)08x, offset = 0x%(4)08x%(3)08x ] > +0x0020100b CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation [ addr = 0x%(3)08x, eip = 0x%(4)08x, npte = 0x%(2)08x%(1)08x ] > +0x0020110b CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation [ addr = 0x%(4)08x%(3)08x, rip = 0x%(6)08x%(5)08x, npte = 0x%(2)08x%(1)08x ] > +0x0020100c CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation_pae [ addr = 0x%(3)08x, eip = 0x%(4)08x, npte = 0x%(2)08x%(1)08x ] > +0x0020110c CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation_pae [ addr = 0x%(4)08x%(3)08x, rip = 0x%(6)08x%(5)08x, npte = 0x%(2)08x%(1)08x ] > > 0x0040f001 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) shadow_not_shadow [ gl1e = 0x%(2)08x%(1)08x, va = 0x%(3)08x, flags = 0x%(4)08x ] > 0x0040f101 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) shadow_not_shadow [ gl1e = 0x%(2)08x%(1)08x, va = 0x%(4)08x%(3)08x, flags = 0x%(5)08x ] > diff --git a/xen/include/public/trace.h b/xen/include/public/trace.h > index 0dfabe9..1f154bb 100644 > --- a/xen/include/public/trace.h > +++ b/xen/include/public/trace.h > @@ -94,20 +94,19 @@ > #define TRC_MEM_POD_ZERO_RECLAIM (TRC_MEM + 17) > #define TRC_MEM_POD_SUPERPAGE_SPLINTER (TRC_MEM + 18) > > - > -#define TRC_PV_HYPERCALL (TRC_PV + 1) > -#define TRC_PV_TRAP (TRC_PV + 3) > -#define TRC_PV_PAGE_FAULT (TRC_PV + 4) > -#define TRC_PV_FORCED_INVALID_OP (TRC_PV + 5) > -#define TRC_PV_EMULATE_PRIVOP (TRC_PV + 6) > -#define TRC_PV_EMULATE_4GB (TRC_PV + 7) > -#define TRC_PV_MATH_STATE_RESTORE (TRC_PV + 8) > -#define TRC_PV_PAGING_FIXUP (TRC_PV + 9) > -#define TRC_PV_GDT_LDT_MAPPING_FAULT (TRC_PV + 10) > -#define TRC_PV_PTWR_EMULATION (TRC_PV + 11) > -#define TRC_PV_PTWR_EMULATION_PAE (TRC_PV + 12) > - /* Indicates that addresses in trace record are 64 bits */ > -#define TRC_64_FLAG (0x100) > +#define TRC_PV_ENTRY 0x00201000 /* Hypervisor entry points for PV guests. */ > + > +#define TRC_PV_HYPERCALL (TRC_PV_ENTRY + 1) > +#define TRC_PV_TRAP (TRC_PV_ENTRY + 3) > +#define TRC_PV_PAGE_FAULT (TRC_PV_ENTRY + 4) > +#define TRC_PV_FORCED_INVALID_OP (TRC_PV_ENTRY + 5) > +#define TRC_PV_EMULATE_PRIVOP (TRC_PV_ENTRY + 6) > +#define TRC_PV_EMULATE_4GB (TRC_PV_ENTRY + 7) > +#define TRC_PV_MATH_STATE_RESTORE (TRC_PV_ENTRY + 8) > +#define TRC_PV_PAGING_FIXUP (TRC_PV_ENTRY + 9) > +#define TRC_PV_GDT_LDT_MAPPING_FAULT (TRC_PV_ENTRY + 10) > +#define TRC_PV_PTWR_EMULATION (TRC_PV_ENTRY + 11) > +#define TRC_PV_PTWR_EMULATION_PAE (TRC_PV_ENTRY + 12) > > #define TRC_SHADOW_NOT_SHADOW (TRC_SHADOW + 1) > #define TRC_SHADOW_FAST_PROPAGATE (TRC_SHADOW + 2) > @@ -187,6 +186,14 @@ > #define TRC_HW_IRQ_UNMAPPED_VECTOR (TRC_HW_IRQ + 0x7) > #define TRC_HW_IRQ_HANDLED (TRC_HW_IRQ + 0x8) > > +/* > + * Event Flags > + * > + * Some events (e.g, TRC_PV_TRAP and TRC_HVM_IOMEM_READ) have multiple > + * record formats. These event flags distinguish between the > + * different formats. > + */ > +#define TRC_64_FLAG 0x100 /* Addresses are 64 bits (instead of 32 bits) */ > > /* This structure represents a single trace buffer record. */ > struct t_rec { > -- > 1.7.2.5 > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 15:56:57 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 15:56:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4pr-0004C0-JZ; Tue, 02 Oct 2012 15:56:39 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ4pp-0004Bs-Om for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 15:56:38 +0000 Received: from [85.158.138.51:63877] by server-8.bemta-3.messagelabs.com id 55/E9-16337-4BE0B605; Tue, 02 Oct 2012 15:56:36 +0000 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-14.tower-174.messagelabs.com!1349193395!26491898!1 X-Originating-IP: [74.125.83.43] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1837 invoked from network); 2 Oct 2012 15:56:35 -0000 Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com) (74.125.83.43) by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 15:56:35 -0000 Received: by eekc13 with SMTP id c13so3287407eek.30 for ; Tue, 02 Oct 2012 08:56:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=YCIaqPs7vKVStF3uXLx6cky/4pkT3g/pdKOesdEoWKs=; b=SVwspt+ldA7h93+d8koS9WqmTd4Xf6ScStM0me1hIOAk35HEqAhiy1NlD7icdhxdKQ thOXxyBttggDBktBY0BAA7lsZVUHOIH4C9lVQs6NNLsXeSABMeoydMZo2iHxSBuSt3ev hV00AL81p/haLfvBF1EIeUxYDZ4hE6LwHe2jxBH3vWqp9H0OoNcdVckgYEK/olS5Cftz Q8w97EMxYVMY4npyn3s+FBSTE42nLaWaRRi5VfBCJm0ZOOwYUR8KPzC/QLbgGJhl9dV+ IkgxeboKolRzgJlCtkEe2IhtJ/ymx5rQ/p8dbPiZpf+IxniNUCSua0M+0BUPD6LnaqLz RXeg== MIME-Version: 1.0 Received: by 10.14.212.72 with SMTP id x48mr22691305eeo.40.1349193395272; Tue, 02 Oct 2012 08:56:35 -0700 (PDT) Received: by 10.14.215.195 with HTTP; Tue, 2 Oct 2012 08:56:35 -0700 (PDT) In-Reply-To: <1349113629-6338-2-git-send-email-david.vrabel@citrix.com> References: <1349113629-6338-1-git-send-email-david.vrabel@citrix.com> <1349113629-6338-2-git-send-email-david.vrabel@citrix.com> Date: Tue, 2 Oct 2012 16:56:35 +0100 X-Google-Sender-Auth: K0sZa2p9glbIeG0NzR8fkP9EOkM Message-ID: From: George Dunlap To: David Vrabel Cc: Frediano Ziglio , xen-devel@lists.xensource.com Subject: Re: [Xen-devel] [PATCH 1/3] trace: allow for different sub-classes of TRC_PV_* tracepoints X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, Oct 1, 2012 at 6:47 PM, David Vrabel wrote: > From: David Vrabel > > We want to add additional sub-classes for TRC_PV tracepoints and to be > able to only capture these new sub-classes. This cannot currently be > done as the existing tracepoints all use a sub-class of 0xf. > > So, redefine the PV events to use a new sub-class. All the current > tracepoints are tracing entry points to the hypervisor so the > sub-class is named TRC_PV_ENTRY. > > This change does not affect xenalyze as that only looks at the main > class and the event number and does not use the sub-class field. > > Signed-off-by: Frediano Ziglio > Signed-off-by: David Vrabel > Acked-by: George Dunlap Ack re-confirmed. > --- > tools/xentrace/formats | 44 ++++++++++++++++++++++---------------------- > xen/include/public/trace.h | 35 +++++++++++++++++++++-------------- > 2 files changed, 43 insertions(+), 36 deletions(-) > > diff --git a/tools/xentrace/formats b/tools/xentrace/formats > index 04e54d5..71220c0 100644 > --- a/tools/xentrace/formats > +++ b/tools/xentrace/formats > @@ -82,28 +82,28 @@ > 0x0010f002 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) page_grant_unmap [ domid = %(1)d ] > 0x0010f003 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) page_grant_transfer [ domid = %(1)d ] > > -0x0020f001 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) hypercall [ eip = 0x%(1)08x, eax = 0x%(2)08x ] > -0x0020f101 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) hypercall [ rip = 0x%(2)08x%(1)08x, eax = 0x%(3)08x ] > -0x0020f003 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) trap [ eip = 0x%(1)08x, trapnr:error = 0x%(2)08x ] > -0x0020f103 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) trap [ rip = 0x%(2)08x%(1)08x, trapnr:error = 0x%(3)08x ] > -0x0020f004 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) page_fault [ eip = 0x%(1)08x, addr = 0x%(2)08x, error = 0x%(3)08x ] > -0x0020f104 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) page_fault [ rip = 0x%(2)08x%(1)08x, addr = 0x%(4)08x%(3)08x, error = 0x%(5)08x ] > -0x0020f005 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) forced_invalid_op [ eip = 0x%(1)08x ] > -0x0020f105 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) forced_invalid_op [ rip = 0x%(2)08x%(1)08x ] > -0x0020f006 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) emulate_privop [ eip = 0x%(1)08x ] > -0x0020f106 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) emulate_privop [ rip = 0x%(2)08x%(1)08x ] > -0x0020f007 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) emulate_4G [ eip = 0x%(1)08x ] > -0x0020f107 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) emulate_4G [ rip = 0x%(2)08x%(1)08x ] > -0x0020f008 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) math_state_restore > -0x0020f108 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) math_state_restore > -0x0020f009 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) paging_fixup [ eip = 0x%(1)08x, addr = 0x%(2)08x ] > -0x0020f109 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) paging_fixup [ rip = 0x%(2)08x%(1)08x, addr = 0x%(4)08x%(3)08x ] > -0x0020f00a CPU%(cpu)d %(tsc)d (+%(reltsc)8d) gdt_ldt_mapping_fault [ eip = 0x%(1)08x, offset = 0x%(2)08x ] > -0x0020f10a CPU%(cpu)d %(tsc)d (+%(reltsc)8d) gdt_ldt_mapping_fault [ rip = 0x%(2)08x%(1)08x, offset = 0x%(4)08x%(3)08x ] > -0x0020f00b CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation [ addr = 0x%(3)08x, eip = 0x%(4)08x, npte = 0x%(2)08x%(1)08x ] > -0x0020f10b CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation [ addr = 0x%(4)08x%(3)08x, rip = 0x%(6)08x%(5)08x, npte = 0x%(2)08x%(1)08x ] > -0x0020f00c CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation_pae [ addr = 0x%(3)08x, eip = 0x%(4)08x, npte = 0x%(2)08x%(1)08x ] > -0x0020f10c CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation_pae [ addr = 0x%(4)08x%(3)08x, rip = 0x%(6)08x%(5)08x, npte = 0x%(2)08x%(1)08x ] > +0x00201001 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) hypercall [ eip = 0x%(1)08x, eax = 0x%(2)08x ] > +0x00201101 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) hypercall [ rip = 0x%(2)08x%(1)08x, eax = 0x%(3)08x ] > +0x00201003 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) trap [ eip = 0x%(1)08x, trapnr:error = 0x%(2)08x ] > +0x00201103 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) trap [ rip = 0x%(2)08x%(1)08x, trapnr:error = 0x%(3)08x ] > +0x00201004 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) page_fault [ eip = 0x%(1)08x, addr = 0x%(2)08x, error = 0x%(3)08x ] > +0x00201104 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) page_fault [ rip = 0x%(2)08x%(1)08x, addr = 0x%(4)08x%(3)08x, error = 0x%(5)08x ] > +0x00201005 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) forced_invalid_op [ eip = 0x%(1)08x ] > +0x00201105 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) forced_invalid_op [ rip = 0x%(2)08x%(1)08x ] > +0x00201006 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) emulate_privop [ eip = 0x%(1)08x ] > +0x00201106 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) emulate_privop [ rip = 0x%(2)08x%(1)08x ] > +0x00201007 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) emulate_4G [ eip = 0x%(1)08x ] > +0x00201107 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) emulate_4G [ rip = 0x%(2)08x%(1)08x ] > +0x00201008 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) math_state_restore > +0x00201108 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) math_state_restore > +0x00201009 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) paging_fixup [ eip = 0x%(1)08x, addr = 0x%(2)08x ] > +0x00201109 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) paging_fixup [ rip = 0x%(2)08x%(1)08x, addr = 0x%(4)08x%(3)08x ] > +0x0020100a CPU%(cpu)d %(tsc)d (+%(reltsc)8d) gdt_ldt_mapping_fault [ eip = 0x%(1)08x, offset = 0x%(2)08x ] > +0x0020110a CPU%(cpu)d %(tsc)d (+%(reltsc)8d) gdt_ldt_mapping_fault [ rip = 0x%(2)08x%(1)08x, offset = 0x%(4)08x%(3)08x ] > +0x0020100b CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation [ addr = 0x%(3)08x, eip = 0x%(4)08x, npte = 0x%(2)08x%(1)08x ] > +0x0020110b CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation [ addr = 0x%(4)08x%(3)08x, rip = 0x%(6)08x%(5)08x, npte = 0x%(2)08x%(1)08x ] > +0x0020100c CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation_pae [ addr = 0x%(3)08x, eip = 0x%(4)08x, npte = 0x%(2)08x%(1)08x ] > +0x0020110c CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation_pae [ addr = 0x%(4)08x%(3)08x, rip = 0x%(6)08x%(5)08x, npte = 0x%(2)08x%(1)08x ] > > 0x0040f001 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) shadow_not_shadow [ gl1e = 0x%(2)08x%(1)08x, va = 0x%(3)08x, flags = 0x%(4)08x ] > 0x0040f101 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) shadow_not_shadow [ gl1e = 0x%(2)08x%(1)08x, va = 0x%(4)08x%(3)08x, flags = 0x%(5)08x ] > diff --git a/xen/include/public/trace.h b/xen/include/public/trace.h > index 0dfabe9..1f154bb 100644 > --- a/xen/include/public/trace.h > +++ b/xen/include/public/trace.h > @@ -94,20 +94,19 @@ > #define TRC_MEM_POD_ZERO_RECLAIM (TRC_MEM + 17) > #define TRC_MEM_POD_SUPERPAGE_SPLINTER (TRC_MEM + 18) > > - > -#define TRC_PV_HYPERCALL (TRC_PV + 1) > -#define TRC_PV_TRAP (TRC_PV + 3) > -#define TRC_PV_PAGE_FAULT (TRC_PV + 4) > -#define TRC_PV_FORCED_INVALID_OP (TRC_PV + 5) > -#define TRC_PV_EMULATE_PRIVOP (TRC_PV + 6) > -#define TRC_PV_EMULATE_4GB (TRC_PV + 7) > -#define TRC_PV_MATH_STATE_RESTORE (TRC_PV + 8) > -#define TRC_PV_PAGING_FIXUP (TRC_PV + 9) > -#define TRC_PV_GDT_LDT_MAPPING_FAULT (TRC_PV + 10) > -#define TRC_PV_PTWR_EMULATION (TRC_PV + 11) > -#define TRC_PV_PTWR_EMULATION_PAE (TRC_PV + 12) > - /* Indicates that addresses in trace record are 64 bits */ > -#define TRC_64_FLAG (0x100) > +#define TRC_PV_ENTRY 0x00201000 /* Hypervisor entry points for PV guests. */ > + > +#define TRC_PV_HYPERCALL (TRC_PV_ENTRY + 1) > +#define TRC_PV_TRAP (TRC_PV_ENTRY + 3) > +#define TRC_PV_PAGE_FAULT (TRC_PV_ENTRY + 4) > +#define TRC_PV_FORCED_INVALID_OP (TRC_PV_ENTRY + 5) > +#define TRC_PV_EMULATE_PRIVOP (TRC_PV_ENTRY + 6) > +#define TRC_PV_EMULATE_4GB (TRC_PV_ENTRY + 7) > +#define TRC_PV_MATH_STATE_RESTORE (TRC_PV_ENTRY + 8) > +#define TRC_PV_PAGING_FIXUP (TRC_PV_ENTRY + 9) > +#define TRC_PV_GDT_LDT_MAPPING_FAULT (TRC_PV_ENTRY + 10) > +#define TRC_PV_PTWR_EMULATION (TRC_PV_ENTRY + 11) > +#define TRC_PV_PTWR_EMULATION_PAE (TRC_PV_ENTRY + 12) > > #define TRC_SHADOW_NOT_SHADOW (TRC_SHADOW + 1) > #define TRC_SHADOW_FAST_PROPAGATE (TRC_SHADOW + 2) > @@ -187,6 +186,14 @@ > #define TRC_HW_IRQ_UNMAPPED_VECTOR (TRC_HW_IRQ + 0x7) > #define TRC_HW_IRQ_HANDLED (TRC_HW_IRQ + 0x8) > > +/* > + * Event Flags > + * > + * Some events (e.g, TRC_PV_TRAP and TRC_HVM_IOMEM_READ) have multiple > + * record formats. These event flags distinguish between the > + * different formats. > + */ > +#define TRC_64_FLAG 0x100 /* Addresses are 64 bits (instead of 32 bits) */ > > /* This structure represents a single trace buffer record. */ > struct t_rec { > -- > 1.7.2.5 > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 16:10:05 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 16:10:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ52b-0005F5-6i; Tue, 02 Oct 2012 16:09:49 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ52Z-0005F0-Sh for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 16:09:48 +0000 Received: from [85.158.143.99:22674] by server-2.bemta-4.messagelabs.com id 0D/5A-06610-BC11B605; Tue, 02 Oct 2012 16:09:47 +0000 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-8.tower-216.messagelabs.com!1349194186!22806624!1 X-Originating-IP: [74.125.83.43] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1095 invoked from network); 2 Oct 2012 16:09:46 -0000 Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com) (74.125.83.43) by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 16:09:46 -0000 Received: by eekc13 with SMTP id c13so3300794eek.30 for ; Tue, 02 Oct 2012 09:09:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=boqnGOqJ/LE/jnPOgD/ipqXTb4Dprp30BNbSP7MSZIs=; b=lXDCgBK/DUQdYmUdbSLpMTDgAq/dvDzAyisKK2JPlfhJq7BbZlqcYyQQb7zuOglI6S qbRFR7Vd40DT2WHRH1WWg+bpzKNU3pcV1s9Fd9nZE/1DoJccbsTHxDyzc9SU7lyCJzLc tZRmRuecRQLblnUyV5Js80AfUvyV0kalcTmWnhQwfiNPjMd+B4GOw3akiVYgEDuHmMdu 80/RZIf5bssRQmUhlJSFKjsEHBP0qXX0f9vDR8/0WYyyNPR+HLZK/5jHuxmnLJxVQVB4 ovWjLTMhKTIBoPMOokvryIPDqfa2fY3sUU7PD+BkvzzB4KzjGJ/Z1A+28rl1dD+d7Nlr Qr4A== MIME-Version: 1.0 Received: by 10.14.180.68 with SMTP id i44mr22971030eem.20.1349194186197; Tue, 02 Oct 2012 09:09:46 -0700 (PDT) Received: by 10.14.215.195 with HTTP; Tue, 2 Oct 2012 09:09:46 -0700 (PDT) In-Reply-To: <1349113629-6338-3-git-send-email-david.vrabel@citrix.com> References: <1349113629-6338-1-git-send-email-david.vrabel@citrix.com> <1349113629-6338-3-git-send-email-david.vrabel@citrix.com> Date: Tue, 2 Oct 2012 17:09:46 +0100 X-Google-Sender-Auth: BjY_ZLQIbMeToCsUDF-0-TdozoY Message-ID: From: George Dunlap To: David Vrabel Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] [PATCH 2/3] trace: improve usefulness of hypercall trace record X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, Oct 1, 2012 at 6:47 PM, David Vrabel wrote: > From: David Vrabel > > Trace hypercalls using a more useful trace record format. > > The EIP field is removed (it was always somewhere in the hypercall > page) and include selected hypercall arguments (e.g., the number of > calls in a multicall, and the number of PTE updates in an mmu_update > etc.). 12 bits in the first extra word are used to indicate which > arguments are present in the record and what size they are (32 or > 64-bit). > > This is an incompatible record format so a new event ID is used so > tools can distinguish between the two formats. > > Signed-off-by: David Vrabel > Acked-by: George Dunlap Looking at it again, I do have one comment (see below) -- so I guess that would be technically withdrawing the Ack until we sort it out. > diff --git a/xen/arch/x86/trace.c b/xen/arch/x86/trace.c > index 27fe150..f2c75bc 100644 > --- a/xen/arch/x86/trace.c > +++ b/xen/arch/x86/trace.c > @@ -9,33 +9,28 @@ > void trace_hypercall(void) In most places, "trace_*" means "Call unconditionally; inside it will check tb_init_done", while "__trace_*" means, "I have already checked that tb_init_done is set, don't bother checking it." It seems not to be the case here -- entry.S checks tb_init_done before calling "trace_hypercall". Could you either: * Come up with a naming scheme consistent with the rest of the calls (e.g., __trace_hypercall_x86 and __trace_hypercall), or * Put a comment at the top of trace_hypercall() noting that it's an exception to the general rule? > + switch ( op ) > + { > + case __HYPERVISOR_mmu_update: > + APPEND_ARG32(1); /* count */ > + break; > + case __HYPERVISOR_multicall: > + APPEND_ARG32(1); /* count */ > + break; > + case __HYPERVISOR_grant_table_op: > + APPEND_ARG32(0); /* cmd */ > + APPEND_ARG32(2); /* count */ > + break; > + case __HYPERVISOR_vcpu_op: > + APPEND_ARG32(0); /* cmd */ > + APPEND_ARG32(1); /* vcpuid */ > + break; > + case __HYPERVISOR_mmuext_op: > + APPEND_ARG32(1); /* count */ > + break; > + case __HYPERVISOR_sched_op: > + APPEND_ARG32(0); /* cmd */ > + break; > + } I may have commented on this before -- I wonder if doing some kind of array might be better than a big switch statement. I think with only a few hypercalls, a switch statement is probably acceptable; but as we add more, the code is going to get bloated. So I guess, I'll accept it this time, but as you add more, Real Soon I'll probably ask for a more efficient implementation. :-) Thanks, -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 16:10:05 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 16:10:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ52b-0005F5-6i; Tue, 02 Oct 2012 16:09:49 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ52Z-0005F0-Sh for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 16:09:48 +0000 Received: from [85.158.143.99:22674] by server-2.bemta-4.messagelabs.com id 0D/5A-06610-BC11B605; Tue, 02 Oct 2012 16:09:47 +0000 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-8.tower-216.messagelabs.com!1349194186!22806624!1 X-Originating-IP: [74.125.83.43] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1095 invoked from network); 2 Oct 2012 16:09:46 -0000 Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com) (74.125.83.43) by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 16:09:46 -0000 Received: by eekc13 with SMTP id c13so3300794eek.30 for ; Tue, 02 Oct 2012 09:09:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=boqnGOqJ/LE/jnPOgD/ipqXTb4Dprp30BNbSP7MSZIs=; b=lXDCgBK/DUQdYmUdbSLpMTDgAq/dvDzAyisKK2JPlfhJq7BbZlqcYyQQb7zuOglI6S qbRFR7Vd40DT2WHRH1WWg+bpzKNU3pcV1s9Fd9nZE/1DoJccbsTHxDyzc9SU7lyCJzLc tZRmRuecRQLblnUyV5Js80AfUvyV0kalcTmWnhQwfiNPjMd+B4GOw3akiVYgEDuHmMdu 80/RZIf5bssRQmUhlJSFKjsEHBP0qXX0f9vDR8/0WYyyNPR+HLZK/5jHuxmnLJxVQVB4 ovWjLTMhKTIBoPMOokvryIPDqfa2fY3sUU7PD+BkvzzB4KzjGJ/Z1A+28rl1dD+d7Nlr Qr4A== MIME-Version: 1.0 Received: by 10.14.180.68 with SMTP id i44mr22971030eem.20.1349194186197; Tue, 02 Oct 2012 09:09:46 -0700 (PDT) Received: by 10.14.215.195 with HTTP; Tue, 2 Oct 2012 09:09:46 -0700 (PDT) In-Reply-To: <1349113629-6338-3-git-send-email-david.vrabel@citrix.com> References: <1349113629-6338-1-git-send-email-david.vrabel@citrix.com> <1349113629-6338-3-git-send-email-david.vrabel@citrix.com> Date: Tue, 2 Oct 2012 17:09:46 +0100 X-Google-Sender-Auth: BjY_ZLQIbMeToCsUDF-0-TdozoY Message-ID: From: George Dunlap To: David Vrabel Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] [PATCH 2/3] trace: improve usefulness of hypercall trace record X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, Oct 1, 2012 at 6:47 PM, David Vrabel wrote: > From: David Vrabel > > Trace hypercalls using a more useful trace record format. > > The EIP field is removed (it was always somewhere in the hypercall > page) and include selected hypercall arguments (e.g., the number of > calls in a multicall, and the number of PTE updates in an mmu_update > etc.). 12 bits in the first extra word are used to indicate which > arguments are present in the record and what size they are (32 or > 64-bit). > > This is an incompatible record format so a new event ID is used so > tools can distinguish between the two formats. > > Signed-off-by: David Vrabel > Acked-by: George Dunlap Looking at it again, I do have one comment (see below) -- so I guess that would be technically withdrawing the Ack until we sort it out. > diff --git a/xen/arch/x86/trace.c b/xen/arch/x86/trace.c > index 27fe150..f2c75bc 100644 > --- a/xen/arch/x86/trace.c > +++ b/xen/arch/x86/trace.c > @@ -9,33 +9,28 @@ > void trace_hypercall(void) In most places, "trace_*" means "Call unconditionally; inside it will check tb_init_done", while "__trace_*" means, "I have already checked that tb_init_done is set, don't bother checking it." It seems not to be the case here -- entry.S checks tb_init_done before calling "trace_hypercall". Could you either: * Come up with a naming scheme consistent with the rest of the calls (e.g., __trace_hypercall_x86 and __trace_hypercall), or * Put a comment at the top of trace_hypercall() noting that it's an exception to the general rule? > + switch ( op ) > + { > + case __HYPERVISOR_mmu_update: > + APPEND_ARG32(1); /* count */ > + break; > + case __HYPERVISOR_multicall: > + APPEND_ARG32(1); /* count */ > + break; > + case __HYPERVISOR_grant_table_op: > + APPEND_ARG32(0); /* cmd */ > + APPEND_ARG32(2); /* count */ > + break; > + case __HYPERVISOR_vcpu_op: > + APPEND_ARG32(0); /* cmd */ > + APPEND_ARG32(1); /* vcpuid */ > + break; > + case __HYPERVISOR_mmuext_op: > + APPEND_ARG32(1); /* count */ > + break; > + case __HYPERVISOR_sched_op: > + APPEND_ARG32(0); /* cmd */ > + break; > + } I may have commented on this before -- I wonder if doing some kind of array might be better than a big switch statement. I think with only a few hypercalls, a switch statement is probably acceptable; but as we add more, the code is going to get bloated. So I guess, I'll accept it this time, but as you add more, Real Soon I'll probably ask for a more efficient implementation. :-) Thanks, -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 16:12:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 16:12:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ54z-0005Lp-OO; Tue, 02 Oct 2012 16:12:17 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ54y-0005Lj-M1 for xen-devel@lists.xen.org; Tue, 02 Oct 2012 16:12:17 +0000 Received: from [85.158.139.83:56309] by server-4.bemta-5.messagelabs.com id 69/DC-20767-F521B605; Tue, 02 Oct 2012 16:12:15 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-2.tower-182.messagelabs.com!1349194334!30251273!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29337 invoked from network); 2 Oct 2012 16:12:15 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 16:12:15 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="14899164" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 16:12:14 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 17:12:14 +0100 Message-ID: <1349194332.650.102.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Matthew Fioravante Date: Tue, 2 Oct 2012 17:12:12 +0100 In-Reply-To: <1349189903-17524-1-git-send-email-matthew.fioravante@jhuapl.edu> References: <1349189903-17524-1-git-send-email-matthew.fioravante@jhuapl.edu> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "samuel.thibault@ens-lyon.org" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 08/12] add tpmfront, tpm_tis, and tpmback drivers to mini-os X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-10-02 at 15:58 +0100, Matthew Fioravante wrote: > diff --git a/extras/mini-os/include/tpm_tis.h b/extras/mini-os/include/tpm_tis.h > new file mode 100644 > index 0000000..a076a70 > --- /dev/null > +++ b/extras/mini-os/include/tpm_tis.h > @@ -0,0 +1,64 @@ > +/* > + * Copyright (c) 2010-2012 United States Government, as represented by > + * the Secretary of Defense. All rights reserved. > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License > + * as published by the Free Software Foundation; either version 2 > + * of the License, or (at your option) any later version. Sorry, but the original Linux files don't seem to use the "or (at your option) any later version" part so I think you must not either. > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. > + * > + * Based upon the files: > + * drivers/char/tpm/tpm_tis.c > + * drivers/char/tpm/tpm.c > + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation > + */ > diff --git a/extras/mini-os/include/tpmback.h b/extras/mini-os/include/tpmback.h > new file mode 100644 > index 0000000..4315e55 > --- /dev/null > +++ b/extras/mini-os/include/tpmback.h > @@ -0,0 +1,96 @@ > +/* > + * Copyright (c) 2010-2012 United States Government, as represented by > + * the Secretary of Defense. All rights reserved. > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License > + * as published by the Free Software Foundation; either version 2 > + * of the License, or (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. > + * > + * Based upon the files: > + * drivers/xen/tpmbk.c Where can I find this file? I looked in upstream Linux and linux-2.6.18-xen.hg. > diff --git a/extras/mini-os/include/tpmfront.h b/extras/mini-os/include/tpmfront.h > new file mode 100644 > index 0000000..7e3d357 > --- /dev/null > +++ b/extras/mini-os/include/tpmfront.h > @@ -0,0 +1,97 @@ > +/* > + * Copyright (c) 2010-2012 United States Government, as represented by > + * the Secretary of Defense. All rights reserved. > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License > + * as published by the Free Software Foundation; either version 2 > + * of the License, or (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. > + * > + > + * > + * Based upon the files: > + * drivers/char/tpm/tpm_vtpm.c This one is GPLv2 only (not or later) also. > + * drivers/char/tpm/tpm_xen.c This one does actually have the MIT alternative but given that you have combined it with the above it makes sense to omit that. > + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation tpm_xen.c also has "Copyright (c) 2002-2004, K A Fraser", not just IBM and that needs to be retained I think. > diff --git a/extras/mini-os/tpm_tis.c b/extras/mini-os/tpm_tis.c > new file mode 100644 > index 0000000..d94f798 > --- /dev/null > +++ b/extras/mini-os/tpm_tis.c > @@ -0,0 +1,1345 @@ > +/* > + * Copyright (c) 2010-2012 United States Government, as represented by > + * the Secretary of Defense. All rights reserved. > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License > + * as published by the Free Software Foundation; either version 2 > + * of the License, or (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. > + * > + * Based upon the files: > + * drivers/char/tpm/tpm_tis.c > + * drivers/char/tpm/tpm.c > + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation You seem to have copied this 2006 date from one source and applied it to all these files even though the files which they are derived from have differing dates. e.g. drivers/char/tpm/tpm.c says "Copyright (C) 2004 IBM Corporation" while drivers/char/tpm/tpm_tis.c says "Copyright (C) 2005, 2006 IBM Corporation". I think it is important legally to retain the precise copyright for the code from which you have derived. I'm afraid this is going to re-checking against all the files you have derived from. You also need to retain any other copyrights, such as Keir's. I think this would be far less error prone if you were to copy the exact bits from each file. e.g. * Based upon the files: * ======== * drivers/char/tpm/tpm_tis.c: * * ======= * drivers/char/tpm/tpm.c: * */ And do this for every file which from which you have derived code. I'm sorry this is so tedious but it is important to get things like licensing and copyright ownership correct. > diff --git a/extras/mini-os/tpmback.c b/extras/mini-os/tpmback.c > new file mode 100644 > index 0000000..03bd20c > --- /dev/null > +++ b/extras/mini-os/tpmback.c > @@ -0,0 +1,1115 @@ > +/* > + * Copyright (c) 2010-2012 United States Government, as represented by > + * the Secretary of Defense. All rights reserved. > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License > + * as published by the Free Software Foundation; either version 2 > + * of the License, or (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. > + * > + * Based upon the files: > + * drivers/xen/tpmbk.c Do you mean ./drivers/xen/tpmback/tpmback.c ? > + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation > + */ [...] > diff --git a/extras/mini-os/tpmfront.c b/extras/mini-os/tpmfront.c > new file mode 100644 > index 0000000..84fc6af > --- /dev/null > +++ b/extras/mini-os/tpmfront.c > @@ -0,0 +1,607 @@ > +/* > + * Copyright (c) 2010-2012 United States Government, as represented by > + * the Secretary of Defense. All rights reserved. > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License > + * as published by the Free Software Foundation; either version 2 > + * of the License, or (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. > + * > + * Based upon the files: > + * drivers/char/tpm/tpm_vtpm.c > + * drivers/char/tpm/tpm_xen.c > + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation Again not "...or later". Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 16:12:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 16:12:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ54z-0005Lp-OO; Tue, 02 Oct 2012 16:12:17 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ54y-0005Lj-M1 for xen-devel@lists.xen.org; Tue, 02 Oct 2012 16:12:17 +0000 Received: from [85.158.139.83:56309] by server-4.bemta-5.messagelabs.com id 69/DC-20767-F521B605; Tue, 02 Oct 2012 16:12:15 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-2.tower-182.messagelabs.com!1349194334!30251273!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29337 invoked from network); 2 Oct 2012 16:12:15 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 16:12:15 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="14899164" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 16:12:14 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 17:12:14 +0100 Message-ID: <1349194332.650.102.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Matthew Fioravante Date: Tue, 2 Oct 2012 17:12:12 +0100 In-Reply-To: <1349189903-17524-1-git-send-email-matthew.fioravante@jhuapl.edu> References: <1349189903-17524-1-git-send-email-matthew.fioravante@jhuapl.edu> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "samuel.thibault@ens-lyon.org" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 08/12] add tpmfront, tpm_tis, and tpmback drivers to mini-os X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-10-02 at 15:58 +0100, Matthew Fioravante wrote: > diff --git a/extras/mini-os/include/tpm_tis.h b/extras/mini-os/include/tpm_tis.h > new file mode 100644 > index 0000000..a076a70 > --- /dev/null > +++ b/extras/mini-os/include/tpm_tis.h > @@ -0,0 +1,64 @@ > +/* > + * Copyright (c) 2010-2012 United States Government, as represented by > + * the Secretary of Defense. All rights reserved. > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License > + * as published by the Free Software Foundation; either version 2 > + * of the License, or (at your option) any later version. Sorry, but the original Linux files don't seem to use the "or (at your option) any later version" part so I think you must not either. > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. > + * > + * Based upon the files: > + * drivers/char/tpm/tpm_tis.c > + * drivers/char/tpm/tpm.c > + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation > + */ > diff --git a/extras/mini-os/include/tpmback.h b/extras/mini-os/include/tpmback.h > new file mode 100644 > index 0000000..4315e55 > --- /dev/null > +++ b/extras/mini-os/include/tpmback.h > @@ -0,0 +1,96 @@ > +/* > + * Copyright (c) 2010-2012 United States Government, as represented by > + * the Secretary of Defense. All rights reserved. > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License > + * as published by the Free Software Foundation; either version 2 > + * of the License, or (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. > + * > + * Based upon the files: > + * drivers/xen/tpmbk.c Where can I find this file? I looked in upstream Linux and linux-2.6.18-xen.hg. > diff --git a/extras/mini-os/include/tpmfront.h b/extras/mini-os/include/tpmfront.h > new file mode 100644 > index 0000000..7e3d357 > --- /dev/null > +++ b/extras/mini-os/include/tpmfront.h > @@ -0,0 +1,97 @@ > +/* > + * Copyright (c) 2010-2012 United States Government, as represented by > + * the Secretary of Defense. All rights reserved. > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License > + * as published by the Free Software Foundation; either version 2 > + * of the License, or (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. > + * > + > + * > + * Based upon the files: > + * drivers/char/tpm/tpm_vtpm.c This one is GPLv2 only (not or later) also. > + * drivers/char/tpm/tpm_xen.c This one does actually have the MIT alternative but given that you have combined it with the above it makes sense to omit that. > + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation tpm_xen.c also has "Copyright (c) 2002-2004, K A Fraser", not just IBM and that needs to be retained I think. > diff --git a/extras/mini-os/tpm_tis.c b/extras/mini-os/tpm_tis.c > new file mode 100644 > index 0000000..d94f798 > --- /dev/null > +++ b/extras/mini-os/tpm_tis.c > @@ -0,0 +1,1345 @@ > +/* > + * Copyright (c) 2010-2012 United States Government, as represented by > + * the Secretary of Defense. All rights reserved. > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License > + * as published by the Free Software Foundation; either version 2 > + * of the License, or (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. > + * > + * Based upon the files: > + * drivers/char/tpm/tpm_tis.c > + * drivers/char/tpm/tpm.c > + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation You seem to have copied this 2006 date from one source and applied it to all these files even though the files which they are derived from have differing dates. e.g. drivers/char/tpm/tpm.c says "Copyright (C) 2004 IBM Corporation" while drivers/char/tpm/tpm_tis.c says "Copyright (C) 2005, 2006 IBM Corporation". I think it is important legally to retain the precise copyright for the code from which you have derived. I'm afraid this is going to re-checking against all the files you have derived from. You also need to retain any other copyrights, such as Keir's. I think this would be far less error prone if you were to copy the exact bits from each file. e.g. * Based upon the files: * ======== * drivers/char/tpm/tpm_tis.c: * * ======= * drivers/char/tpm/tpm.c: * */ And do this for every file which from which you have derived code. I'm sorry this is so tedious but it is important to get things like licensing and copyright ownership correct. > diff --git a/extras/mini-os/tpmback.c b/extras/mini-os/tpmback.c > new file mode 100644 > index 0000000..03bd20c > --- /dev/null > +++ b/extras/mini-os/tpmback.c > @@ -0,0 +1,1115 @@ > +/* > + * Copyright (c) 2010-2012 United States Government, as represented by > + * the Secretary of Defense. All rights reserved. > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License > + * as published by the Free Software Foundation; either version 2 > + * of the License, or (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. > + * > + * Based upon the files: > + * drivers/xen/tpmbk.c Do you mean ./drivers/xen/tpmback/tpmback.c ? > + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation > + */ [...] > diff --git a/extras/mini-os/tpmfront.c b/extras/mini-os/tpmfront.c > new file mode 100644 > index 0000000..84fc6af > --- /dev/null > +++ b/extras/mini-os/tpmfront.c > @@ -0,0 +1,607 @@ > +/* > + * Copyright (c) 2010-2012 United States Government, as represented by > + * the Secretary of Defense. All rights reserved. > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License > + * as published by the Free Software Foundation; either version 2 > + * of the License, or (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. > + * > + * Based upon the files: > + * drivers/char/tpm/tpm_vtpm.c > + * drivers/char/tpm/tpm_xen.c > + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation Again not "...or later". Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 16:16:17 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 16:16:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ58Y-0005XD-IG; Tue, 02 Oct 2012 16:15:58 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ58W-0005X3-Gw for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 16:15:56 +0000 Received: from [85.158.139.83:18172] by server-11.bemta-5.messagelabs.com id 06/6F-13866-B331B605; Tue, 02 Oct 2012 16:15:55 +0000 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-2.tower-182.messagelabs.com!1349194555!30251979!1 X-Originating-IP: [74.125.83.43] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10067 invoked from network); 2 Oct 2012 16:15:55 -0000 Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com) (74.125.83.43) by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 16:15:55 -0000 Received: by eekc13 with SMTP id c13so3306783eek.30 for ; Tue, 02 Oct 2012 09:15:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=M9R5hZbkXg1cuiRmMVTH/3Rdj0HhH0zQQJd4UNbC2hc=; b=eLJdBqv5kNdgl3JldKJozLw0BnXnd7mXoJQdQklgvKrwzzqeyYlbI5SvSGAkslGstr PAaKGgFCxzy9B6DVfwO6ql6YzcgygIXKSnrVWMGCH4OPDeB1v7Ko/f60Ieo8ubGxHGH9 jDOybZY4rztRA7jBs52EzlN/3oAE01nyHUjwa+OHTxBDeRZfdNgXhg167Zs5OQ6PZkxA Y0N28M+jBEa3x4jZs03iDqW40JR2VL67evyxZwiKvZXSXnz5ULrIyJ/uTV+10x7o4LQO nFjPfV7oAKYLjDk40oA6TcGJHtFWh6AeY7/0LidmITlGU83hzEq7qESkvW7y+92AJeUa gnaQ== MIME-Version: 1.0 Received: by 10.14.212.72 with SMTP id x48mr22772131eeo.40.1349194555170; Tue, 02 Oct 2012 09:15:55 -0700 (PDT) Received: by 10.14.215.195 with HTTP; Tue, 2 Oct 2012 09:15:55 -0700 (PDT) In-Reply-To: <1349113629-6338-4-git-send-email-david.vrabel@citrix.com> References: <1349113629-6338-1-git-send-email-david.vrabel@citrix.com> <1349113629-6338-4-git-send-email-david.vrabel@citrix.com> Date: Tue, 2 Oct 2012 17:15:55 +0100 X-Google-Sender-Auth: a1nUKf3kTtpEmL_eiz1_BSi3MTQ Message-ID: From: George Dunlap To: David Vrabel Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] [PATCH 3/3] trace: trace hypercalls inside a multicall X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, Oct 1, 2012 at 6:47 PM, David Vrabel wrote: > From: David Vrabel > > Add a trace record for every hypercall inside a multicall. These use > a new event ID (with a different sub-class ) so they may be filtered > out if only the calls into hypervisor are of interest. > > Signed-off-by: David Vrabel > Acked-by: George Dunlap Re-confirming the Ack. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 16:16:17 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 16:16:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ58Y-0005XD-IG; Tue, 02 Oct 2012 16:15:58 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ58W-0005X3-Gw for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 16:15:56 +0000 Received: from [85.158.139.83:18172] by server-11.bemta-5.messagelabs.com id 06/6F-13866-B331B605; Tue, 02 Oct 2012 16:15:55 +0000 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-2.tower-182.messagelabs.com!1349194555!30251979!1 X-Originating-IP: [74.125.83.43] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10067 invoked from network); 2 Oct 2012 16:15:55 -0000 Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com) (74.125.83.43) by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 16:15:55 -0000 Received: by eekc13 with SMTP id c13so3306783eek.30 for ; Tue, 02 Oct 2012 09:15:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=M9R5hZbkXg1cuiRmMVTH/3Rdj0HhH0zQQJd4UNbC2hc=; b=eLJdBqv5kNdgl3JldKJozLw0BnXnd7mXoJQdQklgvKrwzzqeyYlbI5SvSGAkslGstr PAaKGgFCxzy9B6DVfwO6ql6YzcgygIXKSnrVWMGCH4OPDeB1v7Ko/f60Ieo8ubGxHGH9 jDOybZY4rztRA7jBs52EzlN/3oAE01nyHUjwa+OHTxBDeRZfdNgXhg167Zs5OQ6PZkxA Y0N28M+jBEa3x4jZs03iDqW40JR2VL67evyxZwiKvZXSXnz5ULrIyJ/uTV+10x7o4LQO nFjPfV7oAKYLjDk40oA6TcGJHtFWh6AeY7/0LidmITlGU83hzEq7qESkvW7y+92AJeUa gnaQ== MIME-Version: 1.0 Received: by 10.14.212.72 with SMTP id x48mr22772131eeo.40.1349194555170; Tue, 02 Oct 2012 09:15:55 -0700 (PDT) Received: by 10.14.215.195 with HTTP; Tue, 2 Oct 2012 09:15:55 -0700 (PDT) In-Reply-To: <1349113629-6338-4-git-send-email-david.vrabel@citrix.com> References: <1349113629-6338-1-git-send-email-david.vrabel@citrix.com> <1349113629-6338-4-git-send-email-david.vrabel@citrix.com> Date: Tue, 2 Oct 2012 17:15:55 +0100 X-Google-Sender-Auth: a1nUKf3kTtpEmL_eiz1_BSi3MTQ Message-ID: From: George Dunlap To: David Vrabel Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] [PATCH 3/3] trace: trace hypercalls inside a multicall X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, Oct 1, 2012 at 6:47 PM, David Vrabel wrote: > From: David Vrabel > > Add a trace record for every hypercall inside a multicall. These use > a new event ID (with a different sub-class ) so they may be filtered > out if only the calls into hypervisor are of interest. > > Signed-off-by: David Vrabel > Acked-by: George Dunlap Re-confirming the Ack. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 16:17:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 16:17:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ59V-0005bo-1p; Tue, 02 Oct 2012 16:16:57 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ59T-0005bc-BE for xen-devel@lists.xen.org; Tue, 02 Oct 2012 16:16:55 +0000 Received: from [85.158.139.211:14096] by server-6.bemta-5.messagelabs.com id EF/BD-14717-6731B605; Tue, 02 Oct 2012 16:16:54 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-9.tower-206.messagelabs.com!1349194612!19289823!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzkyODg=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10096 invoked from network); 2 Oct 2012 16:16:54 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 16:16:54 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="210040122" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 16:16:12 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 12:16:12 -0400 Received: from [10.80.3.61] by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJ58l-0002M9-TA; Tue, 02 Oct 2012 17:16:11 +0100 Message-ID: <506B134B.20006@citrix.com> Date: Tue, 2 Oct 2012 17:16:11 +0100 From: Anthony PERARD User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120910 Thunderbird/15.0.1 MIME-Version: 1.0 To: Avi Kivity References: <1348744360-2989-1-git-send-email-anthony.perard@citrix.com> <1348744360-2989-5-git-send-email-anthony.perard@citrix.com> <506AC11F.1030402@redhat.com> In-Reply-To: <506AC11F.1030402@redhat.com> Cc: Xen Devel , QEMU-devel , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH V4 4/5] exec, memory: Call to xen_modified_memory. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 10/02/2012 11:25 AM, Avi Kivity wrote: > On 10/01/2012 12:36 PM, Stefano Stabellini wrote: >> On Thu, 27 Sep 2012, Anthony PERARD wrote: >>> This patch add some calls to xen_modified_memory to notify Xen about dirtybits >>> during migration. >>> >>> Signed-off-by: Anthony PERARD >> >> If I am not mistaken, this is the last patch that needs reviewing. >> Avi, are you OK with it? >> >> >> >>> exec.c | 1 + >>> memory.c | 2 ++ >>> 2 files changed, 3 insertions(+) >>> >>> diff --git a/exec.c b/exec.c >>> index 366684c..1114a09 100644 >>> --- a/exec.c >>> +++ b/exec.c >>> @@ -3427,6 +3427,7 @@ static void invalidate_and_set_dirty(target_phys_addr_t addr, >>> /* set dirty bit */ >>> cpu_physical_memory_set_dirty_flags(addr, (0xff & ~CODE_DIRTY_FLAG)); >>> } >>> + xen_modified_memory(addr, length); >>> } >>> >>> void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf, >>> diff --git a/memory.c b/memory.c >>> index 4f3ade0..015c544 100644 >>> --- a/memory.c >>> +++ b/memory.c >>> @@ -19,6 +19,7 @@ >>> #include "bitops.h" >>> #include "kvm.h" >>> #include >>> +#include "hw/xen.h" >>> >>> #define WANT_EXEC_OBSOLETE >>> #include "exec-obsolete.h" >>> @@ -1077,6 +1078,7 @@ void memory_region_set_dirty(MemoryRegion *mr, target_phys_addr_t addr, >>> target_phys_addr_t size) >>> { >>> assert(mr->terminates); >>> + xen_modified_memory(mr->ram_addr + addr, size); >>> return cpu_physical_memory_set_dirty_range(mr->ram_addr + addr, size, -1); >>> } > > I would prefer this bit pushed into cpu_physical_set_dirty_range(). Ok, I will call the function from cpu_physical_memory_set_dirty_range() instead of from memory_region_set_dirty. > Possibly the first bit too? But the call from invalidate_and_set_dirty, I can not remove it because it does not work. The xen function must be called without condition as xen and qemu does not maintained the same dirtymap. -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 16:17:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 16:17:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ59V-0005bo-1p; Tue, 02 Oct 2012 16:16:57 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ59T-0005bc-BE for xen-devel@lists.xen.org; Tue, 02 Oct 2012 16:16:55 +0000 Received: from [85.158.139.211:14096] by server-6.bemta-5.messagelabs.com id EF/BD-14717-6731B605; Tue, 02 Oct 2012 16:16:54 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-9.tower-206.messagelabs.com!1349194612!19289823!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzkyODg=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10096 invoked from network); 2 Oct 2012 16:16:54 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 16:16:54 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="210040122" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 16:16:12 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 12:16:12 -0400 Received: from [10.80.3.61] by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJ58l-0002M9-TA; Tue, 02 Oct 2012 17:16:11 +0100 Message-ID: <506B134B.20006@citrix.com> Date: Tue, 2 Oct 2012 17:16:11 +0100 From: Anthony PERARD User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120910 Thunderbird/15.0.1 MIME-Version: 1.0 To: Avi Kivity References: <1348744360-2989-1-git-send-email-anthony.perard@citrix.com> <1348744360-2989-5-git-send-email-anthony.perard@citrix.com> <506AC11F.1030402@redhat.com> In-Reply-To: <506AC11F.1030402@redhat.com> Cc: Xen Devel , QEMU-devel , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH V4 4/5] exec, memory: Call to xen_modified_memory. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 10/02/2012 11:25 AM, Avi Kivity wrote: > On 10/01/2012 12:36 PM, Stefano Stabellini wrote: >> On Thu, 27 Sep 2012, Anthony PERARD wrote: >>> This patch add some calls to xen_modified_memory to notify Xen about dirtybits >>> during migration. >>> >>> Signed-off-by: Anthony PERARD >> >> If I am not mistaken, this is the last patch that needs reviewing. >> Avi, are you OK with it? >> >> >> >>> exec.c | 1 + >>> memory.c | 2 ++ >>> 2 files changed, 3 insertions(+) >>> >>> diff --git a/exec.c b/exec.c >>> index 366684c..1114a09 100644 >>> --- a/exec.c >>> +++ b/exec.c >>> @@ -3427,6 +3427,7 @@ static void invalidate_and_set_dirty(target_phys_addr_t addr, >>> /* set dirty bit */ >>> cpu_physical_memory_set_dirty_flags(addr, (0xff & ~CODE_DIRTY_FLAG)); >>> } >>> + xen_modified_memory(addr, length); >>> } >>> >>> void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf, >>> diff --git a/memory.c b/memory.c >>> index 4f3ade0..015c544 100644 >>> --- a/memory.c >>> +++ b/memory.c >>> @@ -19,6 +19,7 @@ >>> #include "bitops.h" >>> #include "kvm.h" >>> #include >>> +#include "hw/xen.h" >>> >>> #define WANT_EXEC_OBSOLETE >>> #include "exec-obsolete.h" >>> @@ -1077,6 +1078,7 @@ void memory_region_set_dirty(MemoryRegion *mr, target_phys_addr_t addr, >>> target_phys_addr_t size) >>> { >>> assert(mr->terminates); >>> + xen_modified_memory(mr->ram_addr + addr, size); >>> return cpu_physical_memory_set_dirty_range(mr->ram_addr + addr, size, -1); >>> } > > I would prefer this bit pushed into cpu_physical_set_dirty_range(). Ok, I will call the function from cpu_physical_memory_set_dirty_range() instead of from memory_region_set_dirty. > Possibly the first bit too? But the call from invalidate_and_set_dirty, I can not remove it because it does not work. The xen function must be called without condition as xen and qemu does not maintained the same dirtymap. -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 16:19:23 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 16:19:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5Bd-0005oi-ON; Tue, 02 Oct 2012 16:19:09 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5Bb-0005oN-Qz for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 16:19:08 +0000 Received: from [85.158.137.99:47514] by server-3.bemta-3.messagelabs.com id B9/EA-25962-AF31B605; Tue, 02 Oct 2012 16:19:06 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-4.tower-217.messagelabs.com!1349194746!20010345!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6574 invoked from network); 2 Oct 2012 16:19:06 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 16:19:06 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="14899356" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 16:19:05 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 17:19:06 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TJ5BZ-0002Va-IN; Tue, 02 Oct 2012 16:19:05 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1TJ5BZ-00079v-4x; Tue, 02 Oct 2012 17:19:05 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Tue, 2 Oct 2012 17:19:05 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.2-testing test] 13910: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 13910 xen-4.2-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13910/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-i386-i386-xl-qemuu-winxpsp3 9 guest-localmigrate fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: xen 906b3a2fcd0a baseline version: xen 2b59edeb0fdd ------------------------------------------------------------ People who touched revisions under test: Andres Lagar-Cavilla Dan Magenheimer Ian Campbell Ian Jackson Zhenzhong Duan ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-4.2-testing + revision=906b3a2fcd0a + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.2-testing 906b3a2fcd0a + branch=xen-4.2-testing + revision=906b3a2fcd0a + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + . cri-common ++ umask 002 + select_xenbranch + case "$branch" in + tree=xen + xenbranch=xen-4.2-testing + '[' xxen = xlinux ']' + linuxbranch=linux + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : http://xenbits.xen.org/hg/staging/xen-4.2-testing.hg ++ : git://xenbits.xen.org/staging/qemu-xen-4.2-testing.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.xen-4.2-testing ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-4.2-testing.git ++ : daily-cron.xen-4.2-testing + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.2-testing.git + info_linux_tree xen-4.2-testing + case $1 in + return 1 + case "$branch" in + cd /export/home/osstest/repos/xen-4.2-testing.hg + hg push -r 906b3a2fcd0a ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 1 changesets with 1 changes to 1 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 16:19:23 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 16:19:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5Bd-0005oi-ON; Tue, 02 Oct 2012 16:19:09 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5Bb-0005oN-Qz for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 16:19:08 +0000 Received: from [85.158.137.99:47514] by server-3.bemta-3.messagelabs.com id B9/EA-25962-AF31B605; Tue, 02 Oct 2012 16:19:06 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-4.tower-217.messagelabs.com!1349194746!20010345!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6574 invoked from network); 2 Oct 2012 16:19:06 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 16:19:06 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="14899356" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 16:19:05 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 17:19:06 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TJ5BZ-0002Va-IN; Tue, 02 Oct 2012 16:19:05 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1TJ5BZ-00079v-4x; Tue, 02 Oct 2012 17:19:05 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Tue, 2 Oct 2012 17:19:05 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.2-testing test] 13910: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 13910 xen-4.2-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13910/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-i386-i386-xl-qemuu-winxpsp3 9 guest-localmigrate fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: xen 906b3a2fcd0a baseline version: xen 2b59edeb0fdd ------------------------------------------------------------ People who touched revisions under test: Andres Lagar-Cavilla Dan Magenheimer Ian Campbell Ian Jackson Zhenzhong Duan ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-4.2-testing + revision=906b3a2fcd0a + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.2-testing 906b3a2fcd0a + branch=xen-4.2-testing + revision=906b3a2fcd0a + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + . cri-common ++ umask 002 + select_xenbranch + case "$branch" in + tree=xen + xenbranch=xen-4.2-testing + '[' xxen = xlinux ']' + linuxbranch=linux + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : http://xenbits.xen.org/hg/staging/xen-4.2-testing.hg ++ : git://xenbits.xen.org/staging/qemu-xen-4.2-testing.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.xen-4.2-testing ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-4.2-testing.git ++ : daily-cron.xen-4.2-testing + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.2-testing.git + info_linux_tree xen-4.2-testing + case $1 in + return 1 + case "$branch" in + cd /export/home/osstest/repos/xen-4.2-testing.hg + hg push -r 906b3a2fcd0a ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 1 changesets with 1 changes to 1 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 16:20:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 16:20:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5D1-0005xs-7f; Tue, 02 Oct 2012 16:20:35 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5Cy-0005xc-Up for xen-devel@lists.xen.org; Tue, 02 Oct 2012 16:20:33 +0000 Received: from [85.158.139.211:3517] by server-15.bemta-5.messagelabs.com id 4C/05-19430-0541B605; Tue, 02 Oct 2012 16:20:32 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-13.tower-206.messagelabs.com!1349194825!16820148!1 X-Originating-IP: [128.244.251.37] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32144 invoked from network); 2 Oct 2012 16:20:26 -0000 Received: from piper.jhuapl.edu (HELO jhuapl.edu) (128.244.251.37) by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 16:20:26 -0000 Received: from ([128.244.207.97]) by piper.jhuapl.edu with ESMTP with TLS id 5Y8HCH1.145958854; Tue, 02 Oct 2012 12:19:57 -0400 From: Matthew Fioravante To: xen-devel@lists.xen.org, samuel.thibault@ens-lyon.org, Ian.Campbell@citrix.com Date: Tue, 2 Oct 2012 12:20:04 -0400 Message-Id: <1349194804-17973-1-git-send-email-matthew.fioravante@jhuapl.edu> X-Mailer: git-send-email 1.7.4.4 Cc: Matthew Fioravante Subject: [Xen-devel] [PATCH 08/12] add tpmfront, tpm_tis, and tpmback drivers to mini-os X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch adds 3 new drivers to mini-os. tpmfront - paravirtualized tpm frontend driver tpmback - paravirtualized tpm backend driver tpm_tis - hardware tpm driver Unfortunately these drivers were derived from GPL licensed linux kernel drivers so they must carry the GPL license. However, since mini-os now supports conditional compilation, hopefully these drivers can be included into the xen tree and conditionally removed from non-gpl projects. By default they are disabled in the makefile. Signed-off-by: Matthew Fioravante --- Changes since last version: * remove (or later version) clause from license diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile index 2422db3..2302a23 100644 --- a/extras/mini-os/Makefile +++ b/extras/mini-os/Makefile @@ -22,6 +22,9 @@ CONFIG_QEMU_XS_ARGS ?= n CONFIG_TEST ?= n CONFIG_PCIFRONT ?= n CONFIG_BLKFRONT ?= y +CONFIG_TPMFRONT ?= n +CONFIG_TPM_TIS ?= n +CONFIG_TPMBACK ?= n CONFIG_NETFRONT ?= y CONFIG_FBFRONT ?= y CONFIG_KBDFRONT ?= y @@ -36,6 +39,9 @@ flags-$(CONFIG_SPARSE_BSS) += -DCONFIG_SPARSE_BSS flags-$(CONFIG_QEMU_XS_ARGS) += -DCONFIG_QEMU_XS_ARGS flags-$(CONFIG_PCIFRONT) += -DCONFIG_PCIFRONT flags-$(CONFIG_BLKFRONT) += -DCONFIG_BLKFRONT +flags-$(CONFIG_TPMFRONT) += -DCONFIG_TPMFRONT +flags-$(CONFIG_TPM_TIS) += -DCONFIG_TPM_TIS +flags-$(CONFIG_TPMBACK) += -DCONFIG_TPMBACK flags-$(CONFIG_NETFRONT) += -DCONFIG_NETFRONT flags-$(CONFIG_KBDFRONT) += -DCONFIG_KBDFRONT flags-$(CONFIG_FBFRONT) += -DCONFIG_FBFRONT @@ -67,6 +73,9 @@ TARGET := mini-os SUBDIRS := lib xenbus console src-$(CONFIG_BLKFRONT) += blkfront.c +src-$(CONFIG_TPMFRONT) += tpmfront.c +src-$(CONFIG_TPM_TIS) += tpm_tis.c +src-$(CONFIG_TPMBACK) += tpmback.c src-y += daytime.c src-y += events.c src-$(CONFIG_FBFRONT) += fbfront.c diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h index d4641b6..935bede 100644 --- a/extras/mini-os/include/lib.h +++ b/extras/mini-os/include/lib.h @@ -142,6 +142,8 @@ enum fd_type { FTYPE_FB, FTYPE_MEM, FTYPE_SAVEFILE, + FTYPE_TPMFRONT, + FTYPE_TPM_TIS, }; LIST_HEAD(evtchn_port_list, evtchn_port_info); @@ -185,6 +187,20 @@ extern struct file { struct { struct consfront_dev *dev; } cons; +#ifdef CONFIG_TPMFRONT + struct { + struct tpmfront_dev *dev; + int respgot; + off_t offset; + } tpmfront; +#endif +#ifdef CONFIG_TPM_TIS + struct { + struct tpm_chip *dev; + int respgot; + off_t offset; + } tpm_tis; +#endif #ifdef CONFIG_XENBUS struct { /* To each xenbus FD is associated a queue of watch events for this diff --git a/extras/mini-os/include/tpm_tis.h b/extras/mini-os/include/tpm_tis.h new file mode 100644 index 0000000..c25f01c --- /dev/null +++ b/extras/mini-os/include/tpm_tis.h @@ -0,0 +1,64 @@ +/* + * Copyright (c) 2010-2012 United States Government, as represented by + * the Secretary of Defense. All rights reserved. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation, version 2 + * of the License + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + * + * Based upon the files: + * drivers/char/tpm/tpm_tis.c + * drivers/char/tpm/tpm.c + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation + */ +#ifndef TPM_TIS_H +#define TPM_TIS_H + +#include +#include + +#define TPM_TIS_EN_LOCL0 1 +#define TPM_TIS_EN_LOCL1 (1 << 1) +#define TPM_TIS_EN_LOCL2 (1 << 2) +#define TPM_TIS_EN_LOCL3 (1 << 3) +#define TPM_TIS_EN_LOCL4 (1 << 4) +#define TPM_TIS_EN_LOCLALL (TPM_TIS_EN_LOCL0 | TPM_TIS_EN_LOCL1 | TPM_TIS_EN_LOCL2 | TPM_TIS_EN_LOCL3 | TPM_TIS_EN_LOCL4) +#define TPM_TIS_LOCL_INT_TO_FLAG(x) (1 << x) +#define TPM_BASEADDR 0xFED40000 +#define TPM_PROBE_IRQ 0xFFFF + +struct tpm_chip; + +struct tpm_chip* init_tpm_tis(unsigned long baseaddr, int localities, unsigned int irq); +void shutdown_tpm_tis(struct tpm_chip* tpm); + +int tpm_tis_request_locality(struct tpm_chip* tpm, int locality); +int tpm_tis_cmd(struct tpm_chip* tpm, uint8_t* req, size_t reqlen, uint8_t** resp, size_t* resplen); + +#ifdef HAVE_LIBC +#include +#include +/* POSIX IO functions: + * use tpm_tis_open() to get a file descriptor to the tpm device + * use write() on the fd to send a command to the backend. You must + * include the entire command in a single call to write(). + * use read() on the fd to read the response. You can use + * fstat() to get the size of the response and lseek() to seek on it. + */ +int tpm_tis_open(struct tpm_chip* tpm); +int tpm_tis_posix_read(int fd, uint8_t* buf, size_t count); +int tpm_tis_posix_write(int fd, const uint8_t* buf, size_t count); +int tpm_tis_posix_fstat(int fd, struct stat* buf); +#endif + +#endif diff --git a/extras/mini-os/include/tpmback.h b/extras/mini-os/include/tpmback.h new file mode 100644 index 0000000..60e504e --- /dev/null +++ b/extras/mini-os/include/tpmback.h @@ -0,0 +1,96 @@ +/* + * Copyright (c) 2010-2012 United States Government, as represented by + * the Secretary of Defense. All rights reserved. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation, version 2 + * of the License + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + * + * Based upon the files: + * drivers/xen/tpmbk.c + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation + */ +#include +#include +#include +#include +#ifndef TPMBACK_H +#define TPMBACK_H + +struct tpmcmd { + domid_t domid; /* Domid of the frontend */ + unsigned int handle; /* Handle of the frontend */ + char* uuid; /* uuid of the tpm interface - allocated internally, dont free it */ + + unsigned int req_len; /* Size of the command in buf - set by tpmback driver */ + uint8_t* req; /* tpm command bits, allocated by driver, DON'T FREE IT */ + unsigned int resp_len; /* Size of the outgoing command, + you set this before passing the cmd object to tpmback_resp */ + uint8_t* resp; /* Buffer for response - YOU MUST ALLOCATE IT, YOU MUST ALSO FREE IT */ +}; +typedef struct tpmcmd tpmcmd_t; + +/* Initialize the tpm backend driver + * @exclusive_domname - This is NULL terminated list of vtpm uuid strings. If this list + * is non-empty, then only frontend domains with vtpm uuid's matching + * entries in this list will be allowed to connect. + * Other connections will be immediatly closed. + * Set this argument to NULL to allow any vtpm to connect. + */ +void init_tpmback(char** exclusive_uuids); +/* Shutdown tpm backend driver */ +void shutdown_tpmback(void); + +/* Blocks until a tpm command is sent from any front end. + * Returns a pointer to the tpm command to handle. + * Do not try to free this pointer or the req buffer + * This function will return NULL if the tpm backend driver + * is shutdown or any other error occurs */ +tpmcmd_t* tpmback_req_any(void); + +/* Blocks until a tpm command from the frontend at domid/handle + * is sent. + * Returns NULL if domid/handle is not connected, tpmback is + * shutdown or shutting down, or if there is an error + */ +tpmcmd_t* tpmback_req(domid_t domid, unsigned int handle); + +/* Send the response to the tpm command back to the frontend + * This function will free the tpmcmd object, but you must free the resp + * buffer yourself */ +void tpmback_resp(tpmcmd_t* tpmcmd); + +/* Waits for the first frontend to connect and then sets domid and handle appropriately. + * If one or more frontends are already connected, this will set domid and handle to one + * of them arbitrarily. The main use for this function is to wait until a single + * frontend connection has occured. + * returns 0 on success, non-zero on failure */ +int tpmback_wait_for_frontend_connect(domid_t *domid, unsigned int *handle); + +/* returns the number of frontends connected */ +int tpmback_num_frontends(void); + +/* Returns the uuid of the specified frontend, NULL on error */ +char* tpmback_get_uuid(domid_t domid, unsigned int handle); + +/* Specify a function to call when a new tpm device connects */ +void tpmback_set_open_callback(void (*cb)(domid_t, unsigned int)); + +/* Specify a function to call when a tpm device disconnects */ +void tpmback_set_close_callback(void (*cb)(domid_t, unsigned int)); + +//Not Implemented +void tpmback_set_suspend_callback(void (*cb)(domid_t, unsigned int)); +void tpmback_set_resume_callback(void (*cb)(domid_t, unsigned int)); + +#endif diff --git a/extras/mini-os/include/tpmfront.h b/extras/mini-os/include/tpmfront.h new file mode 100644 index 0000000..89b18fb --- /dev/null +++ b/extras/mini-os/include/tpmfront.h @@ -0,0 +1,97 @@ +/* + * Copyright (c) 2010-2012 United States Government, as represented by + * the Secretary of Defense. All rights reserved. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation, version 2 + * of the License + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + * + + * + * Based upon the files: + * drivers/char/tpm/tpm_vtpm.c + * drivers/char/tpm/tpm_xen.c + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation + */ +#ifndef TPMFRONT_H +#define TPMFRONT_H + +#include +#include +#include +#include +#include +#include +#include + +struct tpmfront_dev { + grant_ref_t ring_ref; + evtchn_port_t evtchn; + + tpmif_tx_interface_t* tx; + + void** pages; + + domid_t bedomid; + char* nodename; + char* bepath; + + XenbusState state; + + uint8_t waiting; + struct wait_queue_head waitq; + + uint8_t* respbuf; + size_t resplen; + +#ifdef HAVE_LIBC + int fd; +#endif + +}; + + +/*Initialize frontend */ +struct tpmfront_dev* init_tpmfront(const char* nodename); +/*Shutdown frontend */ +void shutdown_tpmfront(struct tpmfront_dev* dev); + +/* Send a tpm command to the backend and wait for the response + * + * @dev - frontend device + * @req - request buffer + * @reqlen - length of request buffer + * @resp - *resp will be set to internal response buffer, don't free it! Value is undefined on error + * @resplen - *resplen will be set to the length of the response. Value is undefined on error + * + * returns 0 on success, non zero on failure. + * */ +int tpmfront_cmd(struct tpmfront_dev* dev, uint8_t* req, size_t reqlen, uint8_t** resp, size_t* resplen); + +#ifdef HAVE_LIBC +#include +/* POSIX IO functions: + * use tpmfront_open() to get a file descriptor to the tpm device + * use write() on the fd to send a command to the backend. You must + * include the entire command in a single call to write(). + * use read() on the fd to read the response. You can use + * fstat() to get the size of the response and lseek() to seek on it. + */ +int tpmfront_open(struct tpmfront_dev* dev); +int tpmfront_posix_read(int fd, uint8_t* buf, size_t count); +int tpmfront_posix_write(int fd, const uint8_t* buf, size_t count); +int tpmfront_posix_fstat(int fd, struct stat* buf); +#endif + + +#endif diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c index 6cb97b1..d212969 100644 --- a/extras/mini-os/lib/sys.c +++ b/extras/mini-os/lib/sys.c @@ -27,6 +27,8 @@ #include #include #include +#include +#include #include #include @@ -294,6 +296,16 @@ int read(int fd, void *buf, size_t nbytes) return blkfront_posix_read(fd, buf, nbytes); } #endif +#ifdef CONFIG_TPMFRONT + case FTYPE_TPMFRONT: { + return tpmfront_posix_read(fd, buf, nbytes); + } +#endif +#ifdef CONFIG_TPM_TIS + case FTYPE_TPM_TIS: { + return tpm_tis_posix_read(fd, buf, nbytes); + } +#endif default: break; } @@ -330,6 +342,14 @@ int write(int fd, const void *buf, size_t nbytes) case FTYPE_BLK: return blkfront_posix_write(fd, buf, nbytes); #endif +#ifdef CONFIG_TPMFRONT + case FTYPE_TPMFRONT: + return tpmfront_posix_write(fd, buf, nbytes); +#endif +#ifdef CONFIG_TPM_TIS + case FTYPE_TPM_TIS: + return tpm_tis_posix_write(fd, buf, nbytes); +#endif default: break; } @@ -341,8 +361,16 @@ int write(int fd, const void *buf, size_t nbytes) off_t lseek(int fd, off_t offset, int whence) { switch(files[fd].type) { +#if defined(CONFIG_BLKFRONT) || defined(CONFIG_TPMFRONT) || defined(CONFIG_TPM_TIS) #ifdef CONFIG_BLKFRONT case FTYPE_BLK: +#endif +#ifdef CONFIG_TPMFRNT + case FTYPE_TPMFRONT: +#endif +#ifdef CONFIG_TPM_TIS + case FTYPE_TPM_TIS: +#endif switch (whence) { case SEEK_SET: files[fd].file.offset = offset; @@ -420,6 +448,18 @@ int close(int fd) files[fd].type = FTYPE_NONE; return 0; #endif +#ifdef CONFIG_TPMFRONT + case FTYPE_TPMFRONT: + shutdown_tpmfront(files[fd].tpmfront.dev); + files[fd].type = FTYPE_NONE; + return 0; +#endif +#ifdef CONFIG_TPM_TIS + case FTYPE_TPM_TIS: + shutdown_tpm_tis(files[fd].tpm_tis.dev); + files[fd].type = FTYPE_NONE; + return 0; +#endif #ifdef CONFIG_KBDFRONT case FTYPE_KBD: shutdown_kbdfront(files[fd].kbd.dev); @@ -489,6 +529,14 @@ int fstat(int fd, struct stat *buf) case FTYPE_BLK: return blkfront_posix_fstat(fd, buf); #endif +#ifdef CONFIG_TPMFRONT + case FTYPE_TPMFRONT: + return tpmfront_posix_fstat(fd, buf); +#endif +#ifdef CONFIG_TPM_TIS + case FTYPE_TPM_TIS: + return tpm_tis_posix_fstat(fd, buf); +#endif default: break; } diff --git a/extras/mini-os/tpm_tis.c b/extras/mini-os/tpm_tis.c new file mode 100644 index 0000000..1d3bd80 --- /dev/null +++ b/extras/mini-os/tpm_tis.c @@ -0,0 +1,1345 @@ +/* + * Copyright (c) 2010-2012 United States Government, as represented by + * the Secretary of Defense. All rights reserved. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation, version 2 + * of the License + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + * + * Based upon the files: + * drivers/char/tpm/tpm_tis.c + * drivers/char/tpm/tpm.c + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#ifndef min + #define min( a, b ) ( ((a) < (b)) ? (a) : (b) ) +#endif + +#define TPM_HEADER_SIZE 10 + +#define TPM_BUFSIZE 2048 + +struct tpm_input_header { + uint16_t tag; + uint32_t length; + uint32_t ordinal; +}__attribute__((packed)); + +struct tpm_output_header { + uint16_t tag; + uint32_t length; + uint32_t return_code; +}__attribute__((packed)); + +struct stclear_flags_t { + uint16_t tag; + uint8_t deactivated; + uint8_t disableForceClear; + uint8_t physicalPresence; + uint8_t physicalPresenceLock; + uint8_t bGlobalLock; +}__attribute__((packed)); + +struct tpm_version_t { + uint8_t Major; + uint8_t Minor; + uint8_t revMajor; + uint8_t revMinor; +}__attribute__((packed)); + +struct tpm_version_1_2_t { + uint16_t tag; + uint8_t Major; + uint8_t Minor; + uint8_t revMajor; + uint8_t revMinor; +}__attribute__((packed)); + +struct timeout_t { + uint32_t a; + uint32_t b; + uint32_t c; + uint32_t d; +}__attribute__((packed)); + +struct duration_t { + uint32_t tpm_short; + uint32_t tpm_medium; + uint32_t tpm_long; +}__attribute__((packed)); + +struct permanent_flags_t { + uint16_t tag; + uint8_t disable; + uint8_t ownership; + uint8_t deactivated; + uint8_t readPubek; + uint8_t disableOwnerClear; + uint8_t allowMaintenance; + uint8_t physicalPresenceLifetimeLock; + uint8_t physicalPresenceHWEnable; + uint8_t physicalPresenceCMDEnable; + uint8_t CEKPUsed; + uint8_t TPMpost; + uint8_t TPMpostLock; + uint8_t FIPS; + uint8_t operator; + uint8_t enableRevokeEK; + uint8_t nvLocked; + uint8_t readSRKPub; + uint8_t tpmEstablished; + uint8_t maintenanceDone; + uint8_t disableFullDALogicInfo; +}__attribute__((packed)); + +typedef union { + struct permanent_flags_t perm_flags; + struct stclear_flags_t stclear_flags; + bool owned; + uint32_t num_pcrs; + struct tpm_version_t tpm_version; + struct tpm_version_1_2_t tpm_version_1_2; + uint32_t manufacturer_id; + struct timeout_t timeout; + struct duration_t duration; +} cap_t; + +struct tpm_getcap_params_in { + uint32_t cap; + uint32_t subcap_size; + uint32_t subcap; +}__attribute__((packed)); + +struct tpm_getcap_params_out { + uint32_t cap_size; + cap_t cap; +}__attribute__((packed)); + +struct tpm_readpubek_params_out { + uint8_t algorithm[4]; + uint8_t encscheme[2]; + uint8_t sigscheme[2]; + uint32_t paramsize; + uint8_t parameters[12]; /*assuming RSA*/ + uint32_t keysize; + uint8_t modulus[256]; + uint8_t checksum[20]; +}__attribute__((packed)); + +typedef union { + struct tpm_input_header in; + struct tpm_output_header out; +} tpm_cmd_header; + +#define TPM_DIGEST_SIZE 20 +struct tpm_pcrread_out { + uint8_t pcr_result[TPM_DIGEST_SIZE]; +}__attribute__((packed)); + +struct tpm_pcrread_in { + uint32_t pcr_idx; +}__attribute__((packed)); + +struct tpm_pcrextend_in { + uint32_t pcr_idx; + uint8_t hash[TPM_DIGEST_SIZE]; +}__attribute__((packed)); + +typedef union { + struct tpm_getcap_params_out getcap_out; + struct tpm_readpubek_params_out readpubek_out; + uint8_t readpubek_out_buffer[sizeof(struct tpm_readpubek_params_out)]; + struct tpm_getcap_params_in getcap_in; + struct tpm_pcrread_in pcrread_in; + struct tpm_pcrread_out pcrread_out; + struct tpm_pcrextend_in pcrextend_in; +} tpm_cmd_params; + +struct tpm_cmd_t { + tpm_cmd_header header; + tpm_cmd_params params; +}__attribute__((packed)); + + +enum tpm_duration { + TPM_SHORT = 0, + TPM_MEDIUM = 1, + TPM_LONG = 2, + TPM_UNDEFINED, +}; + +#define TPM_MAX_ORDINAL 243 +#define TPM_MAX_PROTECTED_ORDINAL 12 +#define TPM_PROTECTED_ORDINAL_MASK 0xFF + +extern const uint8_t tpm_protected_ordinal_duration[TPM_MAX_PROTECTED_ORDINAL]; +extern const uint8_t tpm_ordinal_duration[TPM_MAX_ORDINAL]; + +#define TPM_DIGEST_SIZE 20 +#define TPM_ERROR_SIZE 10 +#define TPM_RET_CODE_IDX 6 + +/* tpm_capabilities */ +#define TPM_CAP_FLAG cpu_to_be32(4) +#define TPM_CAP_PROP cpu_to_be32(5) +#define CAP_VERSION_1_1 cpu_to_be32(0x06) +#define CAP_VERSION_1_2 cpu_to_be32(0x1A) + +/* tpm_sub_capabilities */ +#define TPM_CAP_PROP_PCR cpu_to_be32(0x101) +#define TPM_CAP_PROP_MANUFACTURER cpu_to_be32(0x103) +#define TPM_CAP_FLAG_PERM cpu_to_be32(0x108) +#define TPM_CAP_FLAG_VOL cpu_to_be32(0x109) +#define TPM_CAP_PROP_OWNER cpu_to_be32(0x111) +#define TPM_CAP_PROP_TIS_TIMEOUT cpu_to_be32(0x115) +#define TPM_CAP_PROP_TIS_DURATION cpu_to_be32(0x120) + + +#define TPM_INTERNAL_RESULT_SIZE 200 +#define TPM_TAG_RQU_COMMAND cpu_to_be16(193) +#define TPM_ORD_GET_CAP cpu_to_be32(101) + +extern const struct tpm_input_header tpm_getcap_header; + + + +const uint8_t tpm_protected_ordinal_duration[TPM_MAX_PROTECTED_ORDINAL] = { + TPM_UNDEFINED, /* 0 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 5 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 10 */ + TPM_SHORT, +}; + +const uint8_t tpm_ordinal_duration[TPM_MAX_ORDINAL] = { + TPM_UNDEFINED, /* 0 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 5 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 10 */ + TPM_SHORT, + TPM_MEDIUM, + TPM_LONG, + TPM_LONG, + TPM_MEDIUM, /* 15 */ + TPM_SHORT, + TPM_SHORT, + TPM_MEDIUM, + TPM_LONG, + TPM_SHORT, /* 20 */ + TPM_SHORT, + TPM_MEDIUM, + TPM_MEDIUM, + TPM_MEDIUM, + TPM_SHORT, /* 25 */ + TPM_SHORT, + TPM_MEDIUM, + TPM_SHORT, + TPM_SHORT, + TPM_MEDIUM, /* 30 */ + TPM_LONG, + TPM_MEDIUM, + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, /* 35 */ + TPM_MEDIUM, + TPM_MEDIUM, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_MEDIUM, /* 40 */ + TPM_LONG, + TPM_MEDIUM, + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, /* 45 */ + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_LONG, + TPM_MEDIUM, /* 50 */ + TPM_MEDIUM, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 55 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_MEDIUM, /* 60 */ + TPM_MEDIUM, + TPM_MEDIUM, + TPM_SHORT, + TPM_SHORT, + TPM_MEDIUM, /* 65 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 70 */ + TPM_SHORT, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 75 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_LONG, /* 80 */ + TPM_UNDEFINED, + TPM_MEDIUM, + TPM_LONG, + TPM_SHORT, + TPM_UNDEFINED, /* 85 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 90 */ + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_UNDEFINED, /* 95 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_MEDIUM, /* 100 */ + TPM_SHORT, + TPM_SHORT, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 105 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 110 */ + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, /* 115 */ + TPM_SHORT, + TPM_SHORT, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_LONG, /* 120 */ + TPM_LONG, + TPM_MEDIUM, + TPM_UNDEFINED, + TPM_SHORT, + TPM_SHORT, /* 125 */ + TPM_SHORT, + TPM_LONG, + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, /* 130 */ + TPM_MEDIUM, + TPM_UNDEFINED, + TPM_SHORT, + TPM_MEDIUM, + TPM_UNDEFINED, /* 135 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 140 */ + TPM_SHORT, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 145 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 150 */ + TPM_MEDIUM, + TPM_MEDIUM, + TPM_SHORT, + TPM_SHORT, + TPM_UNDEFINED, /* 155 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 160 */ + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 165 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_LONG, /* 170 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 175 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_MEDIUM, /* 180 */ + TPM_SHORT, + TPM_MEDIUM, + TPM_MEDIUM, + TPM_MEDIUM, + TPM_MEDIUM, /* 185 */ + TPM_SHORT, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 190 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 195 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 200 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, + TPM_SHORT, /* 205 */ + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_MEDIUM, /* 210 */ + TPM_UNDEFINED, + TPM_MEDIUM, + TPM_MEDIUM, + TPM_MEDIUM, + TPM_UNDEFINED, /* 215 */ + TPM_MEDIUM, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, + TPM_SHORT, /* 220 */ + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_UNDEFINED, /* 225 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 230 */ + TPM_LONG, + TPM_MEDIUM, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 235 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 240 */ + TPM_UNDEFINED, + TPM_MEDIUM, +}; + +const struct tpm_input_header tpm_getcap_header = { + .tag = TPM_TAG_RQU_COMMAND, + .length = cpu_to_be32(22), + .ordinal = TPM_ORD_GET_CAP +}; + + +enum tis_access { + TPM_ACCESS_VALID = 0x80, + TPM_ACCESS_ACTIVE_LOCALITY = 0x20, /* (R) */ + TPM_ACCESS_RELINQUISH_LOCALITY = 0x20,/* (W) */ + TPM_ACCESS_REQUEST_PENDING = 0x04, /* (W) */ + TPM_ACCESS_REQUEST_USE = 0x02, /* (W) */ +}; + +enum tis_status { + TPM_STS_VALID = 0x80, /* (R) */ + TPM_STS_COMMAND_READY = 0x40, /* (R) */ + TPM_STS_DATA_AVAIL = 0x10, /* (R) */ + TPM_STS_DATA_EXPECT = 0x08, /* (R) */ + TPM_STS_GO = 0x20, /* (W) */ +}; + +enum tis_int_flags { + TPM_GLOBAL_INT_ENABLE = 0x80000000, + TPM_INTF_BURST_COUNT_STATIC = 0x100, + TPM_INTF_CMD_READY_INT = 0x080, + TPM_INTF_INT_EDGE_FALLING = 0x040, + TPM_INTF_INT_EDGE_RISING = 0x020, + TPM_INTF_INT_LEVEL_LOW = 0x010, + TPM_INTF_INT_LEVEL_HIGH = 0x008, + TPM_INTF_LOCALITY_CHANGE_INT = 0x004, + TPM_INTF_STS_VALID_INT = 0x002, + TPM_INTF_DATA_AVAIL_INT = 0x001, +}; + +enum tis_defaults { + TIS_MEM_BASE = 0xFED40000, + TIS_MEM_LEN = 0x5000, + TIS_SHORT_TIMEOUT = 750, /*ms*/ + TIS_LONG_TIMEOUT = 2000, /*2 sec */ +}; + +#define TPM_TIMEOUT 5 + +#define TPM_ACCESS(t, l) (((uint8_t*)t->pages[l]) + 0x0000) +#define TPM_INT_ENABLE(t, l) ((uint32_t*)(((uint8_t*)t->pages[l]) + 0x0008)) +#define TPM_INT_VECTOR(t, l) (((uint8_t*)t->pages[l]) + 0x000C) +#define TPM_INT_STATUS(t, l) (((uint8_t*)t->pages[l]) + 0x0010) +#define TPM_INTF_CAPS(t, l) ((uint32_t*)(((uint8_t*)t->pages[l]) + 0x0014)) +#define TPM_STS(t, l) ((uint8_t*)(((uint8_t*)t->pages[l]) + 0x0018)) +#define TPM_DATA_FIFO(t, l) (((uint8_t*)t->pages[l]) + 0x0024) + +#define TPM_DID_VID(t, l) ((uint32_t*)(((uint8_t*)t->pages[l]) + 0x0F00)) +#define TPM_RID(t, l) (((uint8_t*)t->pages[l]) + 0x0F04) + +struct tpm_chip { + int enabled_localities; + int locality; + unsigned long baseaddr; + uint8_t* pages[5]; + int did, vid, rid; + + uint8_t data_buffer[TPM_BUFSIZE]; + int data_len; + + s_time_t timeout_a, timeout_b, timeout_c, timeout_d; + s_time_t duration[3]; + +#ifdef HAVE_LIBC + int fd; +#endif + + unsigned int irq; + struct wait_queue_head read_queue; + struct wait_queue_head int_queue; +}; + + +static void __init_tpm_chip(struct tpm_chip* tpm) { + tpm->enabled_localities = TPM_TIS_EN_LOCLALL; + tpm->locality = -1; + tpm->baseaddr = 0; + tpm->pages[0] = tpm->pages[1] = tpm->pages[2] = tpm->pages[3] = tpm->pages[4] = NULL; + tpm->vid = 0; + tpm->did = 0; + tpm->irq = 0; + init_waitqueue_head(&tpm->read_queue); + init_waitqueue_head(&tpm->int_queue); + + tpm->data_len = -1; + +#ifdef HAVE_LIBC + tpm->fd = -1; +#endif +} + +/* + * Returns max number of nsecs to wait + */ +s_time_t tpm_calc_ordinal_duration(struct tpm_chip *chip, + uint32_t ordinal) +{ + int duration_idx = TPM_UNDEFINED; + s_time_t duration = 0; + + if (ordinal < TPM_MAX_ORDINAL) + duration_idx = tpm_ordinal_duration[ordinal]; + else if ((ordinal & TPM_PROTECTED_ORDINAL_MASK) < + TPM_MAX_PROTECTED_ORDINAL) + duration_idx = + tpm_protected_ordinal_duration[ordinal & + TPM_PROTECTED_ORDINAL_MASK]; + + if (duration_idx != TPM_UNDEFINED) { + duration = chip->duration[duration_idx]; + } + + if (duration <= 0) { + return SECONDS(120); + } + else + { + return duration; + } +} + + +static int locality_enabled(struct tpm_chip* tpm, int l) { + return tpm->enabled_localities & (1 << l); +} + +static int check_locality(struct tpm_chip* tpm, int l) { + if(locality_enabled(tpm, l) && (ioread8(TPM_ACCESS(tpm, l)) & + (TPM_ACCESS_ACTIVE_LOCALITY | TPM_ACCESS_VALID)) == + (TPM_ACCESS_ACTIVE_LOCALITY | TPM_ACCESS_VALID)) { + return l; + } + return -1; +} + +void release_locality(struct tpm_chip* tpm, int l, int force) +{ + if (locality_enabled(tpm, l) && (force || (ioread8(TPM_ACCESS(tpm, l)) & + (TPM_ACCESS_REQUEST_PENDING | TPM_ACCESS_VALID)) == + (TPM_ACCESS_REQUEST_PENDING | TPM_ACCESS_VALID))) { + iowrite8(TPM_ACCESS(tpm, l), TPM_ACCESS_RELINQUISH_LOCALITY); + } +} + +int tpm_tis_request_locality(struct tpm_chip* tpm, int l) { + + s_time_t stop; + /*Make sure locality is valid */ + if(!locality_enabled(tpm, l)) { + printk("tpm_tis_change_locality() Tried to change to locality %d, but it is disabled or invalid!\n", l); + return -1; + } + /* Check if we already have the current locality */ + if(check_locality(tpm, l) >= 0) { + return tpm->locality = l; + } + /* Set the new locality*/ + iowrite8(TPM_ACCESS(tpm, l), TPM_ACCESS_REQUEST_USE); + + if(tpm->irq) { + /* Wait for interrupt */ + wait_event_deadline(tpm->int_queue, (check_locality(tpm, l) >= 0), NOW() + tpm->timeout_a); + + /* FIXME: Handle timeout event, should return error in that case */ + return l; + } else { + /* Wait for burstcount */ + stop = NOW() + tpm->timeout_a; + do { + if(check_locality(tpm, l) >= 0) { + return tpm->locality = l; + } + msleep(TPM_TIMEOUT); + } while(NOW() < stop); + } + + printk("REQ LOCALITY FAILURE\n"); + return -1; +} + +static uint8_t tpm_tis_status(struct tpm_chip* tpm) { + return ioread8(TPM_STS(tpm, tpm->locality)); +} + +/* This causes the current command to be aborted */ +static void tpm_tis_ready(struct tpm_chip* tpm) { + iowrite8(TPM_STS(tpm, tpm->locality), TPM_STS_COMMAND_READY); +} +#define tpm_tis_cancel_cmd(v) tpm_tis_ready(v) + +static int get_burstcount(struct tpm_chip* tpm) { + s_time_t stop; + int burstcnt; + + stop = NOW() + tpm->timeout_d; + do { + burstcnt = ioread8((TPM_STS(tpm, tpm->locality) + 1)); + burstcnt += ioread8(TPM_STS(tpm, tpm->locality) + 2) << 8; + + if (burstcnt) { + return burstcnt; + } + msleep(TPM_TIMEOUT); + } while(NOW() < stop); + return -EBUSY; +} + +static int wait_for_stat(struct tpm_chip* tpm, uint8_t mask, + unsigned long timeout, struct wait_queue_head* queue) { + s_time_t stop; + uint8_t status; + + status = tpm_tis_status(tpm); + if((status & mask) == mask) { + return 0; + } + + if(tpm->irq) { + wait_event_deadline(*queue, ((tpm_tis_status(tpm) & mask) == mask), timeout); + /* FIXME: Check for timeout and return -ETIME */ + return 0; + } else { + stop = NOW() + timeout; + do { + msleep(TPM_TIMEOUT); + status = tpm_tis_status(tpm); + if((status & mask) == mask) + return 0; + } while( NOW() < stop); + } + return -ETIME; +} + +static int recv_data(struct tpm_chip* tpm, uint8_t* buf, size_t count) { + int size = 0; + int burstcnt; + while( size < count && + wait_for_stat(tpm, + TPM_STS_DATA_AVAIL | TPM_STS_VALID, + tpm->timeout_c, + &tpm->read_queue) + == 0) { + burstcnt = get_burstcount(tpm); + for(; burstcnt > 0 && size < count; --burstcnt) + { + buf[size++] = ioread8(TPM_DATA_FIFO(tpm, tpm->locality)); + } + } + return size; +} + +int tpm_tis_recv(struct tpm_chip* tpm, uint8_t* buf, size_t count) { + int size = 0; + int expected, status; + + if (count < TPM_HEADER_SIZE) { + size = -EIO; + goto out; + } + + /* read first 10 bytes, including tag, paramsize, and result */ + if((size = + recv_data(tpm, buf, TPM_HEADER_SIZE)) < TPM_HEADER_SIZE) { + printk("Error reading tpm cmd header\n"); + goto out; + } + + expected = be32_to_cpu(*((uint32_t*)(buf + 2))); + if(expected > count) { + size = -EIO; + goto out; + } + + if((size += recv_data(tpm, & buf[TPM_HEADER_SIZE], + expected - TPM_HEADER_SIZE)) < expected) { + printk("Unable to read rest of tpm command size=%d expected=%d\n", size, expected); + size = -ETIME; + goto out; + } + + wait_for_stat(tpm, TPM_STS_VALID, tpm->timeout_c, &tpm->int_queue); + status = tpm_tis_status(tpm); + if(status & TPM_STS_DATA_AVAIL) { + printk("Error: left over data\n"); + size = -EIO; + goto out; + } + +out: + tpm_tis_ready(tpm); + release_locality(tpm, tpm->locality, 0); + return size; +} +int tpm_tis_send(struct tpm_chip* tpm, uint8_t* buf, size_t len) { + int rc; + int status, burstcnt = 0; + int count = 0; + uint32_t ordinal; + + if(tpm_tis_request_locality(tpm, tpm->locality) < 0) { + return -EBUSY; + } + + status = tpm_tis_status(tpm); + if((status & TPM_STS_COMMAND_READY) == 0) { + tpm_tis_ready(tpm); + if(wait_for_stat(tpm, TPM_STS_COMMAND_READY, tpm->timeout_b, &tpm->int_queue) < 0) { + rc = -ETIME; + goto out_err; + } + } + + while(count < len - 1) { + burstcnt = get_burstcount(tpm); + for(;burstcnt > 0 && count < len -1; --burstcnt) { + iowrite8(TPM_DATA_FIFO(tpm, tpm->locality), buf[count++]); + } + + wait_for_stat(tpm, TPM_STS_VALID, tpm->timeout_c, &tpm->int_queue); + status = tpm_tis_status(tpm); + if((status & TPM_STS_DATA_EXPECT) == 0) { + rc = -EIO; + goto out_err; + } + } + + /*Write last byte*/ + iowrite8(TPM_DATA_FIFO(tpm, tpm->locality), buf[count]); + wait_for_stat(tpm, TPM_STS_VALID, tpm->timeout_c, &tpm->read_queue); + status = tpm_tis_status(tpm); + if((status & TPM_STS_DATA_EXPECT) != 0) { + rc = -EIO; + goto out_err; + } + + /*go and do it*/ + iowrite8(TPM_STS(tpm, tpm->locality), TPM_STS_GO); + + if(tpm->irq) { + /*Wait for interrupt */ + ordinal = be32_to_cpu(*(buf + 6)); + if(wait_for_stat(tpm, + TPM_STS_DATA_AVAIL | TPM_STS_VALID, + tpm_calc_ordinal_duration(tpm, ordinal), + &tpm->read_queue) < 0) { + rc = -ETIME; + goto out_err; + } + } +#ifdef HAVE_LIBC + if(tpm->fd >= 0) { + files[tpm->fd].read = 0; + files[tpm->fd].tpm_tis.respgot = 0; + files[tpm->fd].tpm_tis.offset = 0; + } +#endif + return len; + +out_err: + tpm_tis_ready(tpm); + release_locality(tpm, tpm->locality, 0); + return rc; +} + +static void tpm_tis_irq_handler(evtchn_port_t port, struct pt_regs *regs, void* data) +{ + struct tpm_chip* tpm = data; + uint32_t interrupt; + int i; + + interrupt = ioread32(TPM_INT_STATUS(tpm, tpm->locality)); + if(interrupt == 0) { + return; + } + + if(interrupt & TPM_INTF_DATA_AVAIL_INT) { + wake_up(&tpm->read_queue); + } + if(interrupt & TPM_INTF_LOCALITY_CHANGE_INT) { + for(i = 0; i < 5; ++i) { + if(check_locality(tpm, i) >= 0) { + break; + } + } + } + if(interrupt & (TPM_INTF_LOCALITY_CHANGE_INT | TPM_INTF_STS_VALID_INT | + TPM_INTF_CMD_READY_INT)) { + wake_up(&tpm->int_queue); + } + + /* Clear interrupts handled with TPM_EOI */ + iowrite32(TPM_INT_STATUS(tpm, tpm->locality), interrupt); + ioread32(TPM_INT_STATUS(tpm, tpm->locality)); + return; +} + +/* + * Internal kernel interface to transmit TPM commands + */ +static ssize_t tpm_transmit(struct tpm_chip *chip, const uint8_t *buf, + size_t bufsiz) +{ + ssize_t rc; + uint32_t count, ordinal; + s_time_t stop; + + count = be32_to_cpu(*((uint32_t *) (buf + 2))); + ordinal = be32_to_cpu(*((uint32_t *) (buf + 6))); + if (count == 0) + return -ENODATA; + if (count > bufsiz) { + printk("Error: invalid count value %x %zx \n", count, bufsiz); + return -E2BIG; + } + + //down(&chip->tpm_mutex); + + if ((rc = tpm_tis_send(chip, (uint8_t *) buf, count)) < 0) { + printk("tpm_transmit: tpm_send: error %zd\n", rc); + goto out; + } + + if (chip->irq) + goto out_recv; + + stop = NOW() + tpm_calc_ordinal_duration(chip, ordinal); + do { + uint8_t status = tpm_tis_status(chip); + if ((status & (TPM_STS_DATA_AVAIL | TPM_STS_VALID)) == + (TPM_STS_DATA_AVAIL | TPM_STS_VALID)) + goto out_recv; + + if ((status == TPM_STS_COMMAND_READY)) { + printk("TPM Error: Operation Canceled\n"); + rc = -ECANCELED; + goto out; + } + + msleep(TPM_TIMEOUT); /* CHECK */ + rmb(); + } while (NOW() < stop); + + /* Cancel the command */ + tpm_tis_cancel_cmd(chip); + printk("TPM Operation Timed out\n"); + rc = -ETIME; + goto out; + +out_recv: + if((rc = tpm_tis_recv(chip, (uint8_t *) buf, bufsiz)) < 0) { + printk("tpm_transmit: tpm_recv: error %d\n", rc); + } +out: + //up(&chip->tpm_mutex); + return rc; +} + +static ssize_t transmit_cmd(struct tpm_chip *chip, struct tpm_cmd_t *cmd, + int len, const char *desc) +{ + int err; + + len = tpm_transmit(chip,(uint8_t *) cmd, len); + if (len < 0) + return len; + if (len == TPM_ERROR_SIZE) { + err = be32_to_cpu(cmd->header.out.return_code); + printk("A TPM error (%d) occurred %s\n", err, desc); + return err; + } + return 0; +} + +void tpm_get_timeouts(struct tpm_chip *chip) +{ + struct tpm_cmd_t tpm_cmd; + struct timeout_t *timeout_cap; + struct duration_t *duration_cap; + ssize_t rc; + uint32_t timeout; + + tpm_cmd.header.in = tpm_getcap_header; + tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP; + tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4); + tpm_cmd.params.getcap_in.subcap = TPM_CAP_PROP_TIS_TIMEOUT; + + if((rc = transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE, + "attempting to determine the timeouts")) != 0) { + printk("transmit failed %d\n", rc); + goto duration; + } + + if (be32_to_cpu(tpm_cmd.params.getcap_out.cap_size) + != 4 * sizeof(uint32_t)) { + printk("Out len check failure %lu \n", be32_to_cpu(tpm_cmd.header.out.length)); + goto duration; + } + + timeout_cap = &tpm_cmd.params.getcap_out.cap.timeout; + /* Don't overwrite default if value is 0 */ + timeout = be32_to_cpu(timeout_cap->a); + if (timeout) + chip->timeout_a = MICROSECS(timeout); /*Convert to msec */ + timeout = be32_to_cpu(timeout_cap->b); + if (timeout) + chip->timeout_b = MICROSECS(timeout); /*Convert to msec */ + timeout = be32_to_cpu(timeout_cap->c); + if (timeout) + chip->timeout_c = MICROSECS(timeout); /*Convert to msec */ + timeout = be32_to_cpu(timeout_cap->d); + if (timeout) + chip->timeout_d = MICROSECS(timeout); /*Convert to msec */ + +duration: + tpm_cmd.header.in = tpm_getcap_header; + tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP; + tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4); + tpm_cmd.params.getcap_in.subcap = TPM_CAP_PROP_TIS_DURATION; + + if((rc = transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE, + "attempting to determine the durations")) < 0) { + return; + } + + if (be32_to_cpu(tpm_cmd.params.getcap_out.cap_size) + != 3 * sizeof(uint32_t)) { + return; + } + duration_cap = &tpm_cmd.params.getcap_out.cap.duration; + chip->duration[TPM_SHORT] = be32_to_cpu(duration_cap->tpm_short); + /* The Broadcom BCM0102 chipset in a Dell Latitude D820 gets the above + * value wrong and apparently reports msecs rather than usecs. So we + * fix up the resulting too-small TPM_SHORT value to make things work. + */ + if (chip->duration[TPM_SHORT] < 10) { + chip->duration[TPM_SHORT] = MILLISECS(chip->duration[TPM_SHORT]); + } else { + chip->duration[TPM_SHORT] = MICROSECS(chip->duration[TPM_SHORT]); + } + + chip->duration[TPM_MEDIUM] = MICROSECS(be32_to_cpu(duration_cap->tpm_medium)); + chip->duration[TPM_LONG] = MICROSECS(be32_to_cpu(duration_cap->tpm_long)); +} + + + +void tpm_continue_selftest(struct tpm_chip* chip) { + uint8_t data[] = { + 0, 193, /* TPM_TAG_RQU_COMMAND */ + 0, 0, 0, 10, /* length */ + 0, 0, 0, 83, /* TPM_ORD_GetCapability */ + }; + + tpm_transmit(chip, data, sizeof(data)); +} + +ssize_t tpm_getcap(struct tpm_chip *chip, uint32_t subcap_id, cap_t *cap, + const char *desc) +{ + struct tpm_cmd_t tpm_cmd; + int rc; + + tpm_cmd.header.in = tpm_getcap_header; + if (subcap_id == CAP_VERSION_1_1 || subcap_id == CAP_VERSION_1_2) { + tpm_cmd.params.getcap_in.cap = subcap_id; + /*subcap field not necessary */ + tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(0); + tpm_cmd.header.in.length -= cpu_to_be32(sizeof(uint32_t)); + } else { + if (subcap_id == TPM_CAP_FLAG_PERM || + subcap_id == TPM_CAP_FLAG_VOL) + tpm_cmd.params.getcap_in.cap = TPM_CAP_FLAG; + else + tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP; + tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4); + tpm_cmd.params.getcap_in.subcap = subcap_id; + } + rc = transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE, desc); + if (!rc) + *cap = tpm_cmd.params.getcap_out.cap; + return rc; +} + + +struct tpm_chip* init_tpm_tis(unsigned long baseaddr, int localities, unsigned int irq) +{ + int i; + unsigned long addr; + struct tpm_chip* tpm = NULL; + uint32_t didvid; + uint32_t intfcaps; + uint32_t intmask; + + printk("============= Init TPM TIS Driver ==============\n"); + + /*Sanity check the localities input */ + if(localities & ~TPM_TIS_EN_LOCLALL) { + printk("init_tpm_tis() Invalid locality specification! %X\n", localities); + goto abort_egress; + } + + printk("IOMEM Machine Base Address: %lX\n", baseaddr); + + /* Create the tpm data structure */ + tpm = malloc(sizeof(struct tpm_chip)); + __init_tpm_chip(tpm); + + /* Set the enabled localities - if 0 we leave default as all enabled */ + if(localities != 0) { + tpm->enabled_localities = localities; + } + printk("Enabled Localities: "); + for(i = 0; i < 5; ++i) { + if(locality_enabled(tpm, i)) { + printk("%d ", i); + } + } + printk("\n"); + + /* Set the base machine address */ + tpm->baseaddr = baseaddr; + + /* Set default timeouts */ + tpm->timeout_a = MILLISECS(TIS_SHORT_TIMEOUT); + tpm->timeout_b = MILLISECS(TIS_LONG_TIMEOUT); + tpm->timeout_c = MILLISECS(TIS_SHORT_TIMEOUT); + tpm->timeout_d = MILLISECS(TIS_SHORT_TIMEOUT); + + /*Map the mmio pages */ + addr = tpm->baseaddr; + for(i = 0; i < 5; ++i) { + if(locality_enabled(tpm, i)) { + /* Map the page in now */ + if((tpm->pages[i] = ioremap_nocache(addr, PAGE_SIZE)) == NULL) { + printk("Unable to map iomem page a address %p\n", addr); + goto abort_egress; + } + + /* Set default locality to the first enabled one */ + if (tpm->locality < 0) { + if(tpm_tis_request_locality(tpm, i) < 0) { + printk("Unable to request locality %d??\n", i); + goto abort_egress; + } + } + } + addr += PAGE_SIZE; + } + + + /* Get the vendor and device ids */ + didvid = ioread32(TPM_DID_VID(tpm, tpm->locality)); + tpm->did = didvid >> 16; + tpm->vid = didvid & 0xFFFF; + + + /* Get the revision id */ + tpm->rid = ioread8(TPM_RID(tpm, tpm->locality)); + + printk("1.2 TPM (device-id=0x%X vendor-id = %X rev-id = %X)\n", tpm->did, tpm->vid, tpm->rid); + + intfcaps = ioread32(TPM_INTF_CAPS(tpm, tpm->locality)); + printk("TPM interface capabilities (0x%x):\n", intfcaps); + if (intfcaps & TPM_INTF_BURST_COUNT_STATIC) + printk("\tBurst Count Static\n"); + if (intfcaps & TPM_INTF_CMD_READY_INT) + printk("\tCommand Ready Int Support\n"); + if (intfcaps & TPM_INTF_INT_EDGE_FALLING) + printk("\tInterrupt Edge Falling\n"); + if (intfcaps & TPM_INTF_INT_EDGE_RISING) + printk("\tInterrupt Edge Rising\n"); + if (intfcaps & TPM_INTF_INT_LEVEL_LOW) + printk("\tInterrupt Level Low\n"); + if (intfcaps & TPM_INTF_INT_LEVEL_HIGH) + printk("\tInterrupt Level High\n"); + if (intfcaps & TPM_INTF_LOCALITY_CHANGE_INT) + printk("\tLocality Change Int Support\n"); + if (intfcaps & TPM_INTF_STS_VALID_INT) + printk("\tSts Valid Int Support\n"); + if (intfcaps & TPM_INTF_DATA_AVAIL_INT) + printk("\tData Avail Int Support\n"); + + /*Interupt setup */ + intmask = ioread32(TPM_INT_ENABLE(tpm, tpm->locality)); + + intmask |= TPM_INTF_CMD_READY_INT + | TPM_INTF_LOCALITY_CHANGE_INT | TPM_INTF_DATA_AVAIL_INT + | TPM_INTF_STS_VALID_INT; + + iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), intmask); + + /*If interupts are enabled, handle it */ + if(irq) { + if(irq != TPM_PROBE_IRQ) { + tpm->irq = irq; + } else { + /*FIXME add irq probing feature later */ + printk("IRQ probing not implemented\n"); + } + } + + if(tpm->irq) { + iowrite8(TPM_INT_VECTOR(tpm, tpm->locality), tpm->irq); + + if(bind_pirq(tpm->irq, 1, tpm_tis_irq_handler, tpm) != 0) { + printk("Unabled to request irq: %u for use\n", tpm->irq); + printk("Will use polling mode\n"); + tpm->irq = 0; + } else { + /* Clear all existing */ + iowrite32(TPM_INT_STATUS(tpm, tpm->locality), ioread32(TPM_INT_STATUS(tpm, tpm->locality))); + + /* Turn on interrupts */ + iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), intmask | TPM_GLOBAL_INT_ENABLE); + } + } + + tpm_get_timeouts(tpm); + tpm_continue_selftest(tpm); + + + return tpm; +abort_egress: + if(tpm != NULL) { + shutdown_tpm_tis(tpm); + } + return NULL; +} + +void shutdown_tpm_tis(struct tpm_chip* tpm){ + int i; + + printk("Shutting down tpm_tis device\n"); + + iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), ~TPM_GLOBAL_INT_ENABLE); + + /*Unmap all of the mmio pages */ + for(i = 0; i < 5; ++i) { + if(tpm->pages[i] != NULL) { + iounmap(tpm->pages[i], PAGE_SIZE); + tpm->pages[i] = NULL; + } + } + free(tpm); + return; +} + + +int tpm_tis_cmd(struct tpm_chip* tpm, uint8_t* req, size_t reqlen, uint8_t** resp, size_t* resplen) +{ + if(tpm->locality < 0) { + printk("tpm_tis_cmd() failed! locality not set!\n"); + return -1; + } + if(reqlen > TPM_BUFSIZE) { + reqlen = TPM_BUFSIZE; + } + memcpy(tpm->data_buffer, req, reqlen); + *resplen = tpm_transmit(tpm, tpm->data_buffer, TPM_BUFSIZE); + + *resp = malloc(*resplen); + memcpy(*resp, tpm->data_buffer, *resplen); + return 0; +} + +#ifdef HAVE_LIBC +int tpm_tis_open(struct tpm_chip* tpm) +{ + /* Silently prevent multiple opens */ + if(tpm->fd != -1) { + return tpm->fd; + } + + tpm->fd = alloc_fd(FTYPE_TPM_TIS); + printk("tpm_tis_open() -> %d\n", tpm->fd); + files[tpm->fd].tpm_tis.dev = tpm; + files[tpm->fd].tpm_tis.offset = 0; + files[tpm->fd].tpm_tis.respgot = 0; + return tpm->fd; +} + +int tpm_tis_posix_write(int fd, const uint8_t* buf, size_t count) +{ + struct tpm_chip* tpm; + tpm = files[fd].tpm_tis.dev; + + if(tpm->locality < 0) { + printk("tpm_tis_posix_write() failed! locality not set!\n"); + errno = EINPROGRESS; + return -1; + } + if(count == 0) { + return 0; + } + + /* Return an error if we are already processing a command */ + if(count > TPM_BUFSIZE) { + count = TPM_BUFSIZE; + } + /* Send the command now */ + memcpy(tpm->data_buffer, buf, count); + if((tpm->data_len = tpm_transmit(tpm, tpm->data_buffer, TPM_BUFSIZE)) < 0) { + errno = EIO; + return -1; + } + return count; +} + +int tpm_tis_posix_read(int fd, uint8_t* buf, size_t count) +{ + int rc; + struct tpm_chip* tpm; + tpm = files[fd].tpm_tis.dev; + + if(count == 0) { + return 0; + } + + /* If there is no tpm resp to read, return EIO */ + if(tpm->data_len < 0) { + errno = EIO; + return -1; + } + + + /* Handle EOF case */ + if(files[fd].tpm_tis.offset >= tpm->data_len) { + rc = 0; + } else { + rc = min(tpm->data_len - files[fd].tpm_tis.offset, count); + memcpy(buf, tpm->data_buffer + files[fd].tpm_tis.offset, rc); + } + files[fd].tpm_tis.offset += rc; + /* Reset the data pending flag */ + return rc; +} +int tpm_tis_posix_fstat(int fd, struct stat* buf) +{ + struct tpm_chip* tpm; + tpm = files[fd].tpm_tis.dev; + + buf->st_mode = O_RDWR; + buf->st_uid = 0; + buf->st_gid = 0; + buf->st_size = be32_to_cpu(*((uint32_t*)(tpm->data_buffer + 2))); + buf->st_atime = buf->st_mtime = buf->st_ctime = time(NULL); + return 0; +} + + +#endif diff --git a/extras/mini-os/tpmback.c b/extras/mini-os/tpmback.c new file mode 100644 index 0000000..28d786a --- /dev/null +++ b/extras/mini-os/tpmback.c @@ -0,0 +1,1115 @@ +/* + * Copyright (c) 2010-2012 United States Government, as represented by + * the Secretary of Defense. All rights reserved. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation, version 2 + * of the License + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + * + * Based upon the files: + * drivers/xen/tpmbk.c + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + + +#ifndef HAVE_LIBC +#define strtoul simple_strtoul +#endif + +//#define TPMBACK_PRINT_DEBUG +#ifdef TPMBACK_PRINT_DEBUG +#define TPMBACK_DEBUG(fmt,...) printk("Tpmback:Debug("__FILE__":%d) " fmt, __LINE__, ##__VA_ARGS__) +#define TPMBACK_DEBUG_MORE(fmt,...) printk(fmt, ##__VA_ARGS__) +#else +#define TPMBACK_DEBUG(fmt,...) +#endif +#define TPMBACK_ERR(fmt,...) printk("Tpmback:Error " fmt, ##__VA_ARGS__) +#define TPMBACK_LOG(fmt,...) printk("Tpmback:Info " fmt, ##__VA_ARGS__) + +#define min(a,b) (((a) < (b)) ? (a) : (b)) + +/* Default size of the tpmif array at initialization */ +#define DEF_ARRAY_SIZE 1 + +/* tpmif and tpmdev flags */ +#define TPMIF_CLOSED 1 +#define TPMIF_REQ_READY 2 + +struct tpmif { + domid_t domid; + unsigned int handle; + + char* fe_path; + char* fe_state_path; + + /* Locally bound event channel*/ + evtchn_port_t evtchn; + + /* Shared page */ + tpmif_tx_interface_t* tx; + + /* pointer to TPMIF_RX_RING_SIZE pages */ + void** pages; + + enum xenbus_state state; + enum { DISCONNECTED, DISCONNECTING, CONNECTED } status; + + char* uuid; + + /* state flags */ + int flags; +}; +typedef struct tpmif tpmif_t; + +struct tpmback_dev { + + tpmif_t** tpmlist; + unsigned long num_tpms; + unsigned long num_alloc; + + struct gntmap map; + + /* True if at least one tpmif has a request to be handled */ + int flags; + + /* exclusive domains, see init_tpmback comment in tpmback.h */ + char** exclusive_uuids; + + xenbus_event_queue events; + + /* Callbacks */ + void (*open_callback)(domid_t, unsigned int); + void (*close_callback)(domid_t, unsigned int); + void (*suspend_callback)(domid_t, unsigned int); + void (*resume_callback)(domid_t, unsigned int); +}; +typedef struct tpmback_dev tpmback_dev_t; + +enum { EV_NONE, EV_NEWFE, EV_STCHNG } tpm_ev_enum; + +/* Global objects */ +static struct thread* eventthread = NULL; +static tpmback_dev_t gtpmdev = { + .tpmlist = NULL, + .num_tpms = 0, + .num_alloc = 0, + .flags = TPMIF_CLOSED, + .events = NULL, + .open_callback = NULL, + .close_callback = NULL, + .suspend_callback = NULL, + .resume_callback = NULL, +}; +struct wait_queue_head waitq; +int globalinit = 0; + +/************************************ + * TPMIF SORTED ARRAY FUNCTIONS + * tpmback_dev_t.tpmlist is a sorted array, sorted by domid and then handle number + * Duplicates are not allowed + * **********************************/ + +inline void tpmif_req_ready(tpmif_t* tpmif) { + tpmif->flags |= TPMIF_REQ_READY; + gtpmdev.flags |= TPMIF_REQ_READY; +} + +inline void tpmdev_check_req(void) { + int i; + int flags; + local_irq_save(flags); + for(i = 0; i < gtpmdev.num_tpms; ++i) { + if(gtpmdev.tpmlist[i]->flags & TPMIF_REQ_READY) { + gtpmdev.flags |= TPMIF_REQ_READY; + local_irq_restore(flags); + return; + } + } + gtpmdev.flags &= ~TPMIF_REQ_READY; + local_irq_restore(flags); +} + +inline void tpmif_req_finished(tpmif_t* tpmif) { + tpmif->flags &= ~TPMIF_REQ_READY; + tpmdev_check_req(); +} + +int __get_tpmif_index(int st, int n, domid_t domid, unsigned int handle) +{ + int i = st + n /2; + tpmif_t* tmp; + + if( n <= 0 ) + return -1; + + tmp = gtpmdev.tpmlist[i]; + if(domid == tmp->domid && tmp->handle == handle) { + return i; + } else if ( (domid < tmp->domid) || + (domid == tmp->domid && handle < tmp->handle)) { + return __get_tpmif_index(st, n/2, domid, handle); + } else { + return __get_tpmif_index(i + 1, n/2 - ((n +1) % 2), domid, handle); + } +} + +/* Returns the array index of the tpmif domid/handle. Returns -1 if no such tpmif exists */ +int get_tpmif_index(domid_t domid, unsigned int handle) +{ + int flags; + int index; + local_irq_save(flags); + index = __get_tpmif_index(0, gtpmdev.num_tpms, domid, handle); + local_irq_restore(flags); + return index; +} + +/* Returns the tpmif domid/handle or NULL if none exists */ +tpmif_t* get_tpmif(domid_t domid, unsigned int handle) +{ + int flags; + int i; + tpmif_t* ret; + local_irq_save(flags); + i = get_tpmif_index(domid, handle); + if (i < 0) { + ret = NULL; + } else { + ret = gtpmdev.tpmlist[i]; + } + local_irq_restore(flags); + return ret; +} + +/* Remove the given tpmif. Returns 0 if it was removed, -1 if it was not removed */ +int remove_tpmif(tpmif_t* tpmif) +{ + int i, j; + char* err; + int flags; + local_irq_save(flags); + + /* Find the index in the array if it exists */ + i = get_tpmif_index(tpmif->domid, tpmif->handle); + if (i < 0) { + goto error; + } + + /* Remove the interface from the list */ + for(j = i; j < gtpmdev.num_tpms - 1; ++j) { + gtpmdev.tpmlist[j] = gtpmdev.tpmlist[j+1]; + } + gtpmdev.tpmlist[j] = NULL; + --gtpmdev.num_tpms; + + /* If removed tpm was the only ready tpm, then we need to check and turn off the ready flag */ + tpmdev_check_req(); + + local_irq_restore(flags); + + /* Stop listening for events on this tpm interface */ + if((err = xenbus_unwatch_path_token(XBT_NIL, tpmif->fe_state_path, tpmif->fe_state_path))) { + TPMBACK_ERR("Unable to unwatch path token `%s' Error was %s Ignoring..\n", tpmif->fe_state_path, err); + free(err); + } + + return 0; +error: + local_irq_restore(flags); + return -1; +} + +/* Insert tpmif into dev->tpmlist. Returns 0 on success and non zero on error. + * It is an error to insert a tpmif with the same domid and handle + * number + * as something already in the list */ +int insert_tpmif(tpmif_t* tpmif) +{ + int flags; + unsigned int i, j; + tpmif_t* tmp; + char* err; + + local_irq_save(flags); + + /*Check if we need to allocate more space */ + if (gtpmdev.num_tpms == gtpmdev.num_alloc) { + gtpmdev.num_alloc *= 2; + gtpmdev.tpmlist = realloc(gtpmdev.tpmlist, gtpmdev.num_alloc); + } + + /*Find where to put the new interface */ + for(i = 0; i < gtpmdev.num_tpms; ++i) + { + tmp = gtpmdev.tpmlist[i]; + if(tpmif->domid == tmp->domid && tpmif->handle == tmp->handle) { + TPMBACK_ERR("Tried to insert duplicate tpm interface %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle); + goto error; + } + if((tpmif->domid < tmp->domid) || + (tpmif->domid == tmp->domid && tpmif->handle < tmp->handle)) { + break; + } + } + + /*Shift all the tpm pointers past i down one */ + for(j = gtpmdev.num_tpms; j > i; --j) { + gtpmdev.tpmlist[j] = gtpmdev.tpmlist[j-1]; + } + + /*Add the new interface */ + gtpmdev.tpmlist[i] = tpmif; + ++gtpmdev.num_tpms; + + /*Should not be needed, anything inserted with ready flag is probably an error */ + tpmdev_check_req(); + + local_irq_restore(flags); + + /*Listen for state changes on the new interface */ + if((err = xenbus_watch_path_token(XBT_NIL, tpmif->fe_state_path, tpmif->fe_state_path, >pmdev.events))) + { + /* if we got an error here we should carefully remove the interface and then return */ + TPMBACK_ERR("Unable to watch path token `%s' Error was %s\n", tpmif->fe_state_path, err); + free(err); + remove_tpmif(tpmif); + goto error_post_irq; + } + + return 0; +error: + local_irq_restore(flags); +error_post_irq: + return -1; +} + + +/***************** + * CHANGE BACKEND STATE + * *****************/ +/*Attempts to change the backend state in xenstore + * returns 0 on success and non-zero on error */ +int tpmif_change_state(tpmif_t* tpmif, enum xenbus_state state) +{ + char path[512]; + char *value; + char *err; + enum xenbus_state readst; + TPMBACK_DEBUG("Backend state change %u/%u from=%d to=%d\n", (unsigned int) tpmif->domid, tpmif->handle, tpmif->state, state); + if (tpmif->state == state) + return 0; + + snprintf(path, 512, "backend/vtpm/%u/%u/state", (unsigned int) tpmif->domid, tpmif->handle); + + if((err = xenbus_read(XBT_NIL, path, &value))) { + TPMBACK_ERR("Unable to read backend state %s, error was %s\n", path, err); + free(err); + return -1; + } + if(sscanf(value, "%d", &readst) != 1) { + TPMBACK_ERR("Non integer value (%s) in %s ??\n", value, path); + free(value); + return -1; + } + free(value); + + /* It's possible that the backend state got updated by hotplug or something else behind our back */ + if(readst != tpmif->state) { + TPMBACK_DEBUG("tpm interface state was %d but xenstore state was %d!\n", tpmif->state, readst); + tpmif->state = readst; + } + + /*If if the state isnt changing, then we dont update xenstore b/c we dont want to fire extraneous events */ + if(tpmif->state == state) { + return 0; + } + + /*update xenstore*/ + snprintf(path, 512, "backend/vtpm/%u/%u", (unsigned int) tpmif->domid, tpmif->handle); + if((err = xenbus_printf(XBT_NIL, path, "state", "%u", state))) { + TPMBACK_ERR("Error writing to xenstore %s, error was %s new state=%d\n", path, err, state); + free(err); + return -1; + } + + tpmif->state = state; + + return 0; +} +/********************************** + * TPMIF CREATION AND DELETION + * *******************************/ +inline tpmif_t* __init_tpmif(domid_t domid, unsigned int handle) +{ + tpmif_t* tpmif; + tpmif = malloc(sizeof(*tpmif)); + tpmif->domid = domid; + tpmif->handle = handle; + tpmif->fe_path = NULL; + tpmif->fe_state_path = NULL; + tpmif->state = XenbusStateInitialising; + tpmif->status = DISCONNECTED; + tpmif->tx = NULL; + tpmif->pages = NULL; + tpmif->flags = 0; + tpmif->uuid = NULL; + return tpmif; +} + +void __free_tpmif(tpmif_t* tpmif) +{ + if(tpmif->pages) { + free(tpmif->pages); + } + if(tpmif->fe_path) { + free(tpmif->fe_path); + } + if(tpmif->fe_state_path) { + free(tpmif->fe_state_path); + } + if(tpmif->uuid) { + free(tpmif->uuid); + } + free(tpmif); +} +/* Creates a new tpm interface, adds it to the sorted array and returns it. + * returns NULL on error + * If the tpm interface already exists, it is returned*/ +tpmif_t* new_tpmif(domid_t domid, unsigned int handle) +{ + tpmif_t* tpmif; + char* err; + char path[512]; + + /* Make sure we haven't already created this tpm + * Double events can occur */ + if((tpmif = get_tpmif(domid, handle)) != NULL) { + return tpmif; + } + + tpmif = __init_tpmif(domid, handle); + + /* Get the uuid from xenstore */ + snprintf(path, 512, "backend/vtpm/%u/%u/uuid", (unsigned int) domid, handle); + if((err = xenbus_read(XBT_NIL, path, &tpmif->uuid))) { + TPMBACK_ERR("Error reading %s, Error = %s\n", path, err); + free(err); + goto error; + } + + /* Do the exclusive uuid check now */ + if(gtpmdev.exclusive_uuids != NULL) { + char** ptr; + + /* Check that its in the whitelist */ + for(ptr = gtpmdev.exclusive_uuids; *ptr != NULL; ++ptr) { + if(!strcmp(tpmif->uuid, *ptr)) { + break; + } + } + /* If *ptr == NULL then we went through the whole list without a match, so close the connection */ + if(*ptr == NULL) { + tpmif_change_state(tpmif, XenbusStateClosed); + TPMBACK_ERR("Frontend %u/%u tried to connect with invalid uuid=%s\n", (unsigned int) domid, handle, tpmif->uuid); + goto error; + } + } + + /* allocate pages to be used for shared mapping */ + if((tpmif->pages = malloc(sizeof(void*) * TPMIF_TX_RING_SIZE)) == NULL) { + goto error; + } + memset(tpmif->pages, 0, sizeof(void*) * TPMIF_TX_RING_SIZE); + + if(tpmif_change_state(tpmif, XenbusStateInitWait)) { + goto error; + } + + snprintf(path, 512, "backend/vtpm/%u/%u/frontend", (unsigned int) domid, handle); + if((err = xenbus_read(XBT_NIL, path, &tpmif->fe_path))) { + TPMBACK_ERR("Error creating new tpm instance xenbus_read(%s), Error = %s", path, err); + free(err); + goto error; + } + + /*Set the state path */ + tpmif->fe_state_path = malloc(strlen(tpmif->fe_path) + 7); + strcpy(tpmif->fe_state_path, tpmif->fe_path); + strcat(tpmif->fe_state_path, "/state"); + + if(insert_tpmif(tpmif)) { + goto error; + } + TPMBACK_DEBUG("New tpmif %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle); + /* Do the callback now */ + if(gtpmdev.open_callback) { + gtpmdev.open_callback(tpmif->domid, tpmif->handle); + } + return tpmif; +error: + __free_tpmif(tpmif); + return NULL; + +} + +/* Removes tpmif from dev->tpmlist and frees it's memory usage */ +void free_tpmif(tpmif_t* tpmif) +{ + char* err; + char path[512]; + TPMBACK_DEBUG("Free tpmif %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle); + if(tpmif->flags & TPMIF_CLOSED) { + TPMBACK_ERR("Tried to free an instance twice! Theres a bug somewhere!\n"); + BUG(); + } + tpmif->flags = TPMIF_CLOSED; + + tpmif_change_state(tpmif, XenbusStateClosing); + + /* Unmap share page and unbind event channel */ + if(tpmif->status == CONNECTED) { + tpmif->status = DISCONNECTING; + mask_evtchn(tpmif->evtchn); + + if(gntmap_munmap(>pmdev.map, (unsigned long)tpmif->tx, 1)) { + TPMBACK_ERR("%u/%u Error occured while trying to unmap shared page\n", (unsigned int) tpmif->domid, tpmif->handle); + } + + unbind_evtchn(tpmif->evtchn); + } + tpmif->status = DISCONNECTED; + tpmif_change_state(tpmif, XenbusStateClosed); + + /* Do the callback now */ + if(gtpmdev.close_callback) { + gtpmdev.close_callback(tpmif->domid, tpmif->handle); + } + + /* remove from array */ + remove_tpmif(tpmif); + + /* Wake up anyone possibly waiting on this interface and let them exit */ + wake_up(&waitq); + schedule(); + + /* Remove the old xenbus entries */ + snprintf(path, 512, "backend/vtpm/%u/%u", (unsigned int) tpmif->domid, tpmif->handle); + if((err = xenbus_rm(XBT_NIL, path))) { + TPMBACK_ERR("Error cleaning up xenbus entries path=%s error=%s\n", path, err); + free(err); + } + + TPMBACK_LOG("Frontend %u/%u disconnected\n", (unsigned int) tpmif->domid, tpmif->handle); + + /* free memory */ + __free_tpmif(tpmif); + +} + +/********************** + * REMAINING TPMBACK FUNCTIONS + * ********************/ + +/*Event channel handler */ +void tpmback_handler(evtchn_port_t port, struct pt_regs *regs, void *data) +{ + tpmif_t* tpmif = (tpmif_t*) data; + tpmif_tx_request_t* tx = &tpmif->tx->ring[0].req; + /* Throw away 0 size events, these can trigger from event channel unmasking */ + if(tx->size == 0) + return; + + TPMBACK_DEBUG("EVENT CHANNEL FIRE %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle); + tpmif_req_ready(tpmif); + wake_up(&waitq); + +} + +/* Connect to frontend */ +int connect_fe(tpmif_t* tpmif) +{ + char path[512]; + char* err, *value; + uint32_t domid; + grant_ref_t ringref; + evtchn_port_t evtchn; + + /* If already connected then quit */ + if (tpmif->status == CONNECTED) { + TPMBACK_DEBUG("%u/%u tried to connect while it was already connected?\n", (unsigned int) tpmif->domid, tpmif->handle); + return 0; + } + + /* Fetch the grant reference */ + snprintf(path, 512, "%s/ring-ref", tpmif->fe_path); + if((err = xenbus_read(XBT_NIL, path, &value))) { + TPMBACK_ERR("Error creating new tpm instance xenbus_read(%s) Error = %s", path, err); + free(err); + return -1; + } + if(sscanf(value, "%d", &ringref) != 1) { + TPMBACK_ERR("Non integer value (%s) in %s ??\n", value, path); + free(value); + return -1; + } + free(value); + + + /* Fetch the event channel*/ + snprintf(path, 512, "%s/event-channel", tpmif->fe_path); + if((err = xenbus_read(XBT_NIL, path, &value))) { + TPMBACK_ERR("Error creating new tpm instance xenbus_read(%s) Error = %s", path, err); + free(err); + return -1; + } + if(sscanf(value, "%d", &evtchn) != 1) { + TPMBACK_ERR("Non integer value (%s) in %s ??\n", value, path); + free(value); + return -1; + } + free(value); + + domid = tpmif->domid; + if((tpmif->tx = gntmap_map_grant_refs(>pmdev.map, 1, &domid, 0, &ringref, PROT_READ | PROT_WRITE)) == NULL) { + TPMBACK_ERR("Failed to map grant reference %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle); + return -1; + } + memset(tpmif->tx, 0, PAGE_SIZE); + + /*Bind the event channel */ + if((evtchn_bind_interdomain(tpmif->domid, evtchn, tpmback_handler, tpmif, &tpmif->evtchn))) + { + TPMBACK_ERR("%u/%u Unable to bind to interdomain event channel!\n", (unsigned int) tpmif->domid, tpmif->handle); + goto error_post_map; + } + unmask_evtchn(tpmif->evtchn); + + /* Write the ready flag and change status to connected */ + snprintf(path, 512, "backend/vtpm/%u/%u", (unsigned int) tpmif->domid, tpmif->handle); + if((err = xenbus_printf(XBT_NIL, path, "ready", "%u", 1))) { + TPMBACK_ERR("%u/%u Unable to write ready flag on connect_fe()\n", (unsigned int) tpmif->domid, tpmif->handle); + free(err); + goto error_post_evtchn; + } + tpmif->status = CONNECTED; + if((tpmif_change_state(tpmif, XenbusStateConnected))){ + goto error_post_evtchn; + } + + TPMBACK_LOG("Frontend %u/%u connected\n", (unsigned int) tpmif->domid, tpmif->handle); + + return 0; +error_post_evtchn: + mask_evtchn(tpmif->evtchn); + unbind_evtchn(tpmif->evtchn); +error_post_map: + gntmap_munmap(>pmdev.map, (unsigned long)tpmif->tx, 1); + return -1; +} + +static int frontend_changed(tpmif_t* tpmif) +{ + int state = xenbus_read_integer(tpmif->fe_state_path); + if(state < 0) { + state = XenbusStateUnknown; + } + + TPMBACK_DEBUG("Frontend %u/%u state changed to %d\n", (unsigned int) tpmif->domid, tpmif->handle, state); + + switch (state) { + case XenbusStateInitialising: + case XenbusStateInitialised: + break; + + case XenbusStateConnected: + if(connect_fe(tpmif)) { + TPMBACK_ERR("Failed to connect to front end %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle); + tpmif_change_state(tpmif, XenbusStateClosed); + return -1; + } + break; + + case XenbusStateClosing: + tpmif_change_state(tpmif, XenbusStateClosing); + break; + + case XenbusStateUnknown: /* keep it here */ + case XenbusStateClosed: + free_tpmif(tpmif); + break; + + default: + TPMBACK_DEBUG("BAD STATE CHANGE %u/%u state = %d for tpmif\n", (unsigned int) tpmif->domid, tpmif->handle, state); + return -1; + } + return 0; +} + + +/* parses the string that comes out of xenbus_watch_wait_return. */ +static int parse_eventstr(const char* evstr, domid_t* domid, unsigned int* handle) +{ + int ret; + char cmd[40]; + char* err; + char* value; + unsigned int udomid = 0; + tpmif_t* tpmif; + /* First check for new frontends, this occurs when /backend/vtpm// gets created. Note we what the sscanf to fail on the last %s */ + if (sscanf(evstr, "backend/vtpm/%u/%u/%40s", &udomid, handle, cmd) == 2) { + *domid = udomid; + /* Make sure the entry exists, if this event triggers because the entry dissapeared then ignore it */ + if((err = xenbus_read(XBT_NIL, evstr, &value))) { + free(err); + return EV_NONE; + } + free(value); + /* Make sure the tpmif entry does not already exist, this should not happen */ + if((tpmif = get_tpmif(*domid, *handle)) != NULL) { + TPMBACK_DEBUG("Duplicate tpm entries! %u %u\n", tpmif->domid, tpmif->handle); + return EV_NONE; + } + return EV_NEWFE; + } else if((ret = sscanf(evstr, "/local/domain/%u/device/vtpm/%u/%40s", &udomid, handle, cmd)) == 3) { + *domid = udomid; + if (!strcmp(cmd, "state")) + return EV_STCHNG; + } + return EV_NONE; +} + +void handle_backend_event(char* evstr) { + tpmif_t* tpmif; + domid_t domid; + unsigned int handle; + int event; + + TPMBACK_DEBUG("Xenbus Event: %s\n", evstr); + + event = parse_eventstr(evstr, &domid, &handle); + + switch(event) { + case EV_NEWFE: + if(new_tpmif(domid, handle) == NULL) { + TPMBACK_ERR("Failed to create new tpm instance %u/%u\n", (unsigned int) domid, handle); + } + wake_up(&waitq); + break; + case EV_STCHNG: + if((tpmif = get_tpmif(domid, handle))) { + frontend_changed(tpmif); + } else { + TPMBACK_DEBUG("Event Received for non-existant tpm! instance=%u/%u xenbus_event=%s\n", (unsigned int) domid, handle, evstr); + } + break; + } +} + +/* Runs through the given path and creates events recursively + * for all of its children. + * @path - xenstore path to scan */ +static void generate_backend_events(const char* path) +{ + char* err; + int i, len; + char **dirs; + char *entry; + + if((err = xenbus_ls(XBT_NIL, path, &dirs)) != NULL) { + free(err); + return; + } + + for(i = 0; dirs[i] != NULL; ++i) { + len = strlen(path) + strlen(dirs[i]) + 2; + entry = malloc(len); + snprintf(entry, len, "%s/%s", path, dirs[i]); + + /* Generate and handle event for the entry itself */ + handle_backend_event(entry); + + /* Do children */ + generate_backend_events(entry); + + /* Cleanup */ + free(entry); + free(dirs[i]); + } + free(dirs); + return; +} + +char* tpmback_get_uuid(domid_t domid, unsigned int handle) +{ + tpmif_t* tpmif; + if((tpmif = get_tpmif(domid, handle)) == NULL) { + TPMBACK_DEBUG("get_uuid() failed, %u/%u is an invalid frontend\n", (unsigned int) domid, handle); + return NULL; + } + + return tpmif->uuid; +} + +void tpmback_set_open_callback(void (*cb)(domid_t, unsigned int)) +{ + gtpmdev.open_callback = cb; +} +void tpmback_set_close_callback(void (*cb)(domid_t, unsigned int)) +{ + gtpmdev.close_callback = cb; +} +void tpmback_set_suspend_callback(void (*cb)(domid_t, unsigned int)) +{ + gtpmdev.suspend_callback = cb; +} +void tpmback_set_resume_callback(void (*cb)(domid_t, unsigned int)) +{ + gtpmdev.resume_callback = cb; +} + +static void event_listener(void) +{ + const char* bepath = "backend/vtpm"; + char **path; + char* err; + + /* Setup the backend device watch */ + if((err = xenbus_watch_path_token(XBT_NIL, bepath, bepath, >pmdev.events)) != NULL) { + TPMBACK_ERR("xenbus_watch_path_token(%s) failed with error %s!\n", bepath, err); + free(err); + goto egress; + } + + /* Check for any frontends that connected before we set the watch. + * This is almost guaranteed to happen if both domains are started + * immediatly one after the other. + * We do this by manually generating events on everything in the backend + * path */ + generate_backend_events(bepath); + + /* Wait and listen for changes in frontend connections */ + while(1) { + path = xenbus_wait_for_watch_return(>pmdev.events); + + /*If quit flag was set then exit */ + if(gtpmdev.flags & TPMIF_CLOSED) { + TPMBACK_DEBUG("listener thread got quit event. Exiting..\n"); + free(path); + break; + } + handle_backend_event(*path); + free(path); + + } + + if((err = xenbus_unwatch_path_token(XBT_NIL, bepath, bepath)) != NULL) { + free(err); + } +egress: + return; +} + +void event_thread(void* p) { + event_listener(); +} + +void init_tpmback(char** exclusive_uuids) +{ + if(!globalinit) { + init_waitqueue_head(&waitq); + globalinit = 1; + } + printk("============= Init TPM BACK ================\n"); + gtpmdev.tpmlist = malloc(sizeof(tpmif_t*) * DEF_ARRAY_SIZE); + gtpmdev.num_alloc = DEF_ARRAY_SIZE; + gtpmdev.num_tpms = 0; + gtpmdev.flags = 0; + gtpmdev.exclusive_uuids = exclusive_uuids; + + gtpmdev.open_callback = gtpmdev.close_callback = NULL; + gtpmdev.suspend_callback = gtpmdev.resume_callback = NULL; + + eventthread = create_thread("tpmback-listener", event_thread, NULL); + +} + +void shutdown_tpmback(void) +{ + /* Disable callbacks */ + gtpmdev.open_callback = gtpmdev.close_callback = NULL; + gtpmdev.suspend_callback = gtpmdev.resume_callback = NULL; + + TPMBACK_LOG("Shutting down tpm backend\n"); + /* Set the quit flag */ + gtpmdev.flags = TPMIF_CLOSED; + + //printk("num tpms is %d\n", gtpmdev.num_tpms); + /*Free all backend instances */ + while(gtpmdev.num_tpms) { + free_tpmif(gtpmdev.tpmlist[0]); + } + free(gtpmdev.tpmlist); + gtpmdev.tpmlist = NULL; + gtpmdev.num_alloc = 0; + + /* Wake up anyone possibly waiting on the device and let them exit */ + wake_up(&waitq); + schedule(); +} + +inline void init_tpmcmd(tpmcmd_t* tpmcmd, domid_t domid, unsigned int handle, char* uuid) +{ + tpmcmd->domid = domid; + tpmcmd->handle = handle; + tpmcmd->uuid = uuid; + tpmcmd->req = NULL; + tpmcmd->req_len = 0; + tpmcmd->resp = NULL; + tpmcmd->resp_len = 0; +} + +tpmcmd_t* get_request(tpmif_t* tpmif) { + tpmcmd_t* cmd; + tpmif_tx_request_t* tx; + int offset; + int tocopy; + int i; + uint32_t domid; + int flags; + + local_irq_save(flags); + + /* Allocate the cmd object to hold the data */ + if((cmd = malloc(sizeof(*cmd))) == NULL) { + goto error; + } + init_tpmcmd(cmd, tpmif->domid, tpmif->handle, tpmif->uuid); + + tx = &tpmif->tx->ring[0].req; + cmd->req_len = tx->size; + /* Allocate the buffer */ + if(cmd->req_len) { + if((cmd->req = malloc(cmd->req_len)) == NULL) { + goto error; + } + } + /* Copy the bits from the shared pages */ + offset = 0; + for(i = 0; i < TPMIF_TX_RING_SIZE && offset < cmd->req_len; ++i) { + tx = &tpmif->tx->ring[i].req; + + /* Map the page with the data */ + domid = (uint32_t)tpmif->domid; + if((tpmif->pages[i] = gntmap_map_grant_refs(>pmdev.map, 1, &domid, 0, &tx->ref, PROT_READ)) == NULL) { + TPMBACK_ERR("%u/%u Unable to map shared page during read!\n", (unsigned int) tpmif->domid, tpmif->handle); + goto error; + } + + /* do the copy now */ + tocopy = min(cmd->req_len - offset, PAGE_SIZE); + memcpy(&cmd->req[offset], tpmif->pages[i], tocopy); + offset += tocopy; + + /* release the page */ + gntmap_munmap(>pmdev.map, (unsigned long)tpmif->pages[i], 1); + + } + +#ifdef TPMBACK_PRINT_DEBUG + TPMBACK_DEBUG("Received Tpm Command from %u/%u of size %u", (unsigned int) tpmif->domid, tpmif->handle, cmd->req_len); + for(i = 0; i < cmd->req_len; ++i) { + if (!(i % 30)) { + TPMBACK_DEBUG_MORE("\n"); + } + TPMBACK_DEBUG_MORE("%02hhX ", cmd->req[i]); + } + TPMBACK_DEBUG_MORE("\n\n"); +#endif + + local_irq_restore(flags); + return cmd; +error: + if(cmd != NULL) { + if (cmd->req != NULL) { + free(cmd->req); + cmd->req = NULL; + } + free(cmd); + cmd = NULL; + } + local_irq_restore(flags); + return NULL; + +} + +void send_response(tpmcmd_t* cmd, tpmif_t* tpmif) +{ + tpmif_tx_request_t* tx; + int offset; + int i; + uint32_t domid; + int tocopy; + int flags; + + local_irq_save(flags); + + tx = &tpmif->tx->ring[0].req; + tx->size = cmd->resp_len; + + offset = 0; + for(i = 0; i < TPMIF_TX_RING_SIZE && offset < cmd->resp_len; ++i) { + tx = &tpmif->tx->ring[i].req; + + /* Map the page with the data */ + domid = (uint32_t)tpmif->domid; + if((tpmif->pages[i] = gntmap_map_grant_refs(>pmdev.map, 1, &domid, 0, &tx->ref, PROT_WRITE)) == NULL) { + TPMBACK_ERR("%u/%u Unable to map shared page during write!\n", (unsigned int) tpmif->domid, tpmif->handle); + goto error; + } + + /* do the copy now */ + tocopy = min(cmd->resp_len - offset, PAGE_SIZE); + memcpy(tpmif->pages[i], &cmd->resp[offset], tocopy); + offset += tocopy; + + /* release the page */ + gntmap_munmap(>pmdev.map, (unsigned long)tpmif->pages[i], 1); + + } + +#ifdef TPMBACK_PRINT_DEBUG + TPMBACK_DEBUG("Sent response to %u/%u of size %u", (unsigned int) tpmif->domid, tpmif->handle, cmd->resp_len); + for(i = 0; i < cmd->resp_len; ++i) { + if (!(i % 30)) { + TPMBACK_DEBUG_MORE("\n"); + } + TPMBACK_DEBUG_MORE("%02hhX ", cmd->resp[i]); + } + TPMBACK_DEBUG_MORE("\n\n"); +#endif + /* clear the ready flag and send the event channel notice to the frontend */ + tpmif_req_finished(tpmif); + notify_remote_via_evtchn(tpmif->evtchn); +error: + local_irq_restore(flags); + return; +} + +tpmcmd_t* tpmback_req_any(void) +{ + int i; + /* Block until something has a request */ + wait_event(waitq, (gtpmdev.flags & (TPMIF_REQ_READY | TPMIF_CLOSED))); + + /* Check if were shutting down */ + if(gtpmdev.flags & TPMIF_CLOSED) { + /* if something was waiting for us to give up the queue so it can shutdown, let it finish */ + schedule(); + return NULL; + } + + for(i = 0; i < gtpmdev.num_tpms; ++i) { + if(gtpmdev.tpmlist[i]->flags & TPMIF_REQ_READY) { + return get_request(gtpmdev.tpmlist[i]); + } + } + + TPMBACK_ERR("backend request ready flag was set but no interfaces were actually ready\n"); + return NULL; +} + +tpmcmd_t* tpmback_req(domid_t domid, unsigned int handle) +{ + tpmif_t* tpmif; + tpmif = get_tpmif(domid, handle); + if(tpmif == NULL) { + return NULL; + } + + wait_event(waitq, (tpmif->flags & (TPMIF_REQ_READY | TPMIF_CLOSED) || gtpmdev.flags & TPMIF_CLOSED)); + + /* Check if were shutting down */ + if(tpmif->flags & TPMIF_CLOSED || gtpmdev.flags & TPMIF_CLOSED) { + /* if something was waiting for us to give up the queue so it can free this instance, let it finish */ + schedule(); + return NULL; + } + + return get_request(tpmif); +} + +void tpmback_resp(tpmcmd_t* tpmcmd) +{ + tpmif_t* tpmif; + + /* Get the associated interface, if it doesnt exist then just quit */ + tpmif = get_tpmif(tpmcmd->domid, tpmcmd->handle); + if(tpmif == NULL) { + TPMBACK_ERR("Tried to send a reponse to non existant frontend %u/%u\n", (unsigned int) tpmcmd->domid, tpmcmd->handle); + goto end; + } + + if(!(tpmif->flags & TPMIF_REQ_READY)) { + TPMBACK_ERR("Tried to send response to a frontend that was not waiting for one %u/%u\n", (unsigned int) tpmcmd->domid, tpmcmd->handle); + goto end; + } + + /* Send response to frontend */ + send_response(tpmcmd, tpmif); + +end: + if(tpmcmd->req != NULL) { + free(tpmcmd->req); + } + free(tpmcmd); + return; +} + +int tpmback_wait_for_frontend_connect(domid_t *domid, unsigned int *handle) +{ + tpmif_t* tpmif; + int flags; + wait_event(waitq, ((gtpmdev.num_tpms > 0) || gtpmdev.flags & TPMIF_CLOSED)); + if(gtpmdev.flags & TPMIF_CLOSED) { + return -1; + } + local_irq_save(flags); + tpmif = gtpmdev.tpmlist[0]; + *domid = tpmif->domid; + *handle = tpmif->handle; + local_irq_restore(flags); + + return 0; +} + +int tpmback_num_frontends(void) +{ + return gtpmdev.num_tpms; +} diff --git a/extras/mini-os/tpmfront.c b/extras/mini-os/tpmfront.c new file mode 100644 index 0000000..3f532d7 --- /dev/null +++ b/extras/mini-os/tpmfront.c @@ -0,0 +1,607 @@ +/* + * Copyright (c) 2010-2012 United States Government, as represented by + * the Secretary of Defense. All rights reserved. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation, version 2 + * of the License + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + * + * Based upon the files: + * drivers/char/tpm/tpm_vtpm.c + * drivers/char/tpm/tpm_xen.c + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +//#define TPMFRONT_PRINT_DEBUG +#ifdef TPMFRONT_PRINT_DEBUG +#define TPMFRONT_DEBUG(fmt,...) printk("Tpmfront:Debug("__FILE__":%d) " fmt, __LINE__, ##__VA_ARGS__) +#define TPMFRONT_DEBUG_MORE(fmt,...) printk(fmt, ##__VA_ARGS__) +#else +#define TPMFRONT_DEBUG(fmt,...) +#endif +#define TPMFRONT_ERR(fmt,...) printk("Tpmfront:Error " fmt, ##__VA_ARGS__) +#define TPMFRONT_LOG(fmt,...) printk("Tpmfront:Info " fmt, ##__VA_ARGS__) + +#define min(a,b) (((a) < (b)) ? (a) : (b)) + +void tpmfront_handler(evtchn_port_t port, struct pt_regs *regs, void *data) { + struct tpmfront_dev* dev = (struct tpmfront_dev*) data; + /*If we get a response when we didnt make a request, just ignore it */ + if(!dev->waiting) { + return; + } + + dev->waiting = 0; +#ifdef HAVE_LIBC + if(dev->fd >= 0) { + files[dev->fd].read = 1; + } +#endif + wake_up(&dev->waitq); +} + +static int publish_xenbus(struct tpmfront_dev* dev) { + xenbus_transaction_t xbt; + int retry; + char* err; + /* Write the grant reference and event channel to xenstore */ +again: + if((err = xenbus_transaction_start(&xbt))) { + TPMFRONT_ERR("Unable to start xenbus transaction, error was %s\n", err); + free(err); + return -1; + } + + if((err = xenbus_printf(xbt, dev->nodename, "ring-ref", "%u", (unsigned int) dev->ring_ref))) { + TPMFRONT_ERR("Unable to write %s/ring-ref, error was %s\n", dev->nodename, err); + free(err); + goto abort_transaction; + } + + if((err = xenbus_printf(xbt, dev->nodename, "event-channel", "%u", (unsigned int) dev->evtchn))) { + TPMFRONT_ERR("Unable to write %s/event-channel, error was %s\n", dev->nodename, err); + free(err); + goto abort_transaction; + } + + if((err = xenbus_transaction_end(xbt, 0, &retry))) { + TPMFRONT_ERR("Unable to complete xenbus transaction, error was %s\n", err); + free(err); + return -1; + } + if(retry) { + goto again; + } + + return 0; +abort_transaction: + if((err = xenbus_transaction_end(xbt, 1, &retry))) { + free(err); + } + return -1; +} + +static int wait_for_backend_connect(xenbus_event_queue* events, char* path) +{ + int state; + + TPMFRONT_LOG("Waiting for backend connection..\n"); + /* Wait for the backend to connect */ + while(1) { + state = xenbus_read_integer(path); + if ( state < 0) + state = XenbusStateUnknown; + switch(state) { + /* Bad states, we quit with error */ + case XenbusStateUnknown: + case XenbusStateClosing: + case XenbusStateClosed: + TPMFRONT_ERR("Unable to connect to backend\n"); + return -1; + /* If backend is connected then break out of loop */ + case XenbusStateConnected: + TPMFRONT_LOG("Backend Connected\n"); + return 0; + default: + xenbus_wait_for_watch(events); + } + } + +} + +static int wait_for_backend_closed(xenbus_event_queue* events, char* path) +{ + int state; + + TPMFRONT_LOG("Waiting for backend to close..\n"); + while(1) { + state = xenbus_read_integer(path); + if ( state < 0) + state = XenbusStateUnknown; + switch(state) { + case XenbusStateUnknown: + TPMFRONT_ERR("Backend Unknown state, forcing shutdown\n"); + return -1; + case XenbusStateClosed: + TPMFRONT_LOG("Backend Closed\n"); + return 0; + default: + xenbus_wait_for_watch(events); + } + } + +} + +static int wait_for_backend_state_changed(struct tpmfront_dev* dev, XenbusState state) { + char* err; + int ret = 0; + xenbus_event_queue events = NULL; + char path[512]; + + snprintf(path, 512, "%s/state", dev->bepath); + /*Setup the watch to wait for the backend */ + if((err = xenbus_watch_path_token(XBT_NIL, path, path, &events))) { + TPMFRONT_ERR("Could not set a watch on %s, error was %s\n", path, err); + free(err); + return -1; + } + + /* Do the actual wait loop now */ + switch(state) { + case XenbusStateConnected: + ret = wait_for_backend_connect(&events, path); + break; + case XenbusStateClosed: + ret = wait_for_backend_closed(&events, path); + break; + default: + break; + } + + if((err = xenbus_unwatch_path_token(XBT_NIL, path, path))) { + TPMFRONT_ERR("Unable to unwatch %s, error was %s, ignoring..\n", path, err); + free(err); + } + return ret; +} + +static int tpmfront_connect(struct tpmfront_dev* dev) +{ + char* err; + /* Create shared page */ + dev->tx = (tpmif_tx_interface_t*) alloc_page(); + if(dev->tx == NULL) { + TPMFRONT_ERR("Unable to allocate page for shared memory\n"); + goto error; + } + memset(dev->tx, 0, PAGE_SIZE); + dev->ring_ref = gnttab_grant_access(dev->bedomid, virt_to_mfn(dev->tx), 0); + TPMFRONT_DEBUG("grant ref is %lu\n", (unsigned long) dev->ring_ref); + + /*Create event channel */ + if(evtchn_alloc_unbound(dev->bedomid, tpmfront_handler, dev, &dev->evtchn)) { + TPMFRONT_ERR("Unable to allocate event channel\n"); + goto error_postmap; + } + unmask_evtchn(dev->evtchn); + TPMFRONT_DEBUG("event channel is %lu\n", (unsigned long) dev->evtchn); + + /* Write the entries to xenstore */ + if(publish_xenbus(dev)) { + goto error_postevtchn; + } + + /* Change state to connected */ + dev->state = XenbusStateConnected; + + /* Tell the backend that we are ready */ + if((err = xenbus_printf(XBT_NIL, dev->nodename, "state", "%u", dev->state))) { + TPMFRONT_ERR("Unable to write to xenstore %s/state, value=%u", dev->nodename, XenbusStateConnected); + free(err); + goto error; + } + + return 0; +error_postevtchn: + mask_evtchn(dev->evtchn); + unbind_evtchn(dev->evtchn); +error_postmap: + gnttab_end_access(dev->ring_ref); + free_page(dev->tx); +error: + return -1; +} + +struct tpmfront_dev* init_tpmfront(const char* _nodename) +{ + struct tpmfront_dev* dev; + const char* nodename; + char path[512]; + char* value, *err; + unsigned long long ival; + int i; + + printk("============= Init TPM Front ================\n"); + + dev = malloc(sizeof(struct tpmfront_dev)); + memset(dev, 0, sizeof(struct tpmfront_dev)); + +#ifdef HAVE_LIBC + dev->fd = -1; +#endif + + nodename = _nodename ? _nodename : "device/vtpm/0"; + dev->nodename = strdup(nodename); + + init_waitqueue_head(&dev->waitq); + + /* Get backend domid */ + snprintf(path, 512, "%s/backend-id", dev->nodename); + if((err = xenbus_read(XBT_NIL, path, &value))) { + TPMFRONT_ERR("Unable to read %s during tpmfront initialization! error = %s\n", path, err); + free(err); + goto error; + } + if(sscanf(value, "%llu", &ival) != 1) { + TPMFRONT_ERR("%s has non-integer value (%s)\n", path, value); + free(value); + goto error; + } + free(value); + dev->bedomid = ival; + + /* Get backend xenstore path */ + snprintf(path, 512, "%s/backend", dev->nodename); + if((err = xenbus_read(XBT_NIL, path, &dev->bepath))) { + TPMFRONT_ERR("Unable to read %s during tpmfront initialization! error = %s\n", path, err); + free(err); + goto error; + } + + /* Create and publish grant reference and event channel */ + if (tpmfront_connect(dev)) { + goto error; + } + + /* Wait for backend to connect */ + if( wait_for_backend_state_changed(dev, XenbusStateConnected)) { + goto error; + } + + /* Allocate pages that will contain the messages */ + dev->pages = malloc(sizeof(void*) * TPMIF_TX_RING_SIZE); + if(dev->pages == NULL) { + goto error; + } + memset(dev->pages, 0, sizeof(void*) * TPMIF_TX_RING_SIZE); + for(i = 0; i < TPMIF_TX_RING_SIZE; ++i) { + dev->pages[i] = (void*)alloc_page(); + if(dev->pages[i] == NULL) { + goto error; + } + } + + TPMFRONT_LOG("Initialization Completed successfully\n"); + + return dev; + +error: + shutdown_tpmfront(dev); + return NULL; +} +void shutdown_tpmfront(struct tpmfront_dev* dev) +{ + char* err; + char path[512]; + int i; + tpmif_tx_request_t* tx; + if(dev == NULL) { + return; + } + TPMFRONT_LOG("Shutting down tpmfront\n"); + /* disconnect */ + if(dev->state == XenbusStateConnected) { + dev->state = XenbusStateClosing; + //FIXME: Transaction for this? + /* Tell backend we are closing */ + if((err = xenbus_printf(XBT_NIL, dev->nodename, "state", "%u", (unsigned int) dev->state))) { + free(err); + } + + /* Clean up xenstore entries */ + snprintf(path, 512, "%s/event-channel", dev->nodename); + if((err = xenbus_rm(XBT_NIL, path))) { + free(err); + } + snprintf(path, 512, "%s/ring-ref", dev->nodename); + if((err = xenbus_rm(XBT_NIL, path))) { + free(err); + } + + /* Tell backend we are closed */ + dev->state = XenbusStateClosed; + if((err = xenbus_printf(XBT_NIL, dev->nodename, "state", "%u", (unsigned int) dev->state))) { + TPMFRONT_ERR("Unable to write to %s, error was %s", dev->nodename, err); + free(err); + } + + /* Wait for the backend to close and unmap shared pages, ignore any errors */ + wait_for_backend_state_changed(dev, XenbusStateClosed); + + /* Cleanup any shared pages */ + if(dev->pages) { + for(i = 0; i < TPMIF_TX_RING_SIZE; ++i) { + if(dev->pages[i]) { + tx = &dev->tx->ring[i].req; + if(tx->ref != 0) { + gnttab_end_access(tx->ref); + } + free_page(dev->pages[i]); + } + } + free(dev->pages); + } + + /* Close event channel and unmap shared page */ + mask_evtchn(dev->evtchn); + unbind_evtchn(dev->evtchn); + gnttab_end_access(dev->ring_ref); + + free_page(dev->tx); + + } + + /* Cleanup memory usage */ + if(dev->respbuf) { + free(dev->respbuf); + } + if(dev->bepath) { + free(dev->bepath); + } + if(dev->nodename) { + free(dev->nodename); + } + free(dev); +} + +int tpmfront_send(struct tpmfront_dev* dev, const uint8_t* msg, size_t length) +{ + int i; + tpmif_tx_request_t* tx = NULL; + /* Error Checking */ + if(dev == NULL || dev->state != XenbusStateConnected) { + TPMFRONT_ERR("Tried to send message through disconnected frontend\n"); + return -1; + } + +#ifdef TPMFRONT_PRINT_DEBUG + TPMFRONT_DEBUG("Sending Msg to backend size=%u", (unsigned int) length); + for(i = 0; i < length; ++i) { + if(!(i % 30)) { + TPMFRONT_DEBUG_MORE("\n"); + } + TPMFRONT_DEBUG_MORE("%02X ", msg[i]); + } + TPMFRONT_DEBUG_MORE("\n"); +#endif + + /* Copy to shared pages now */ + for(i = 0; length > 0 && i < TPMIF_TX_RING_SIZE; ++i) { + /* Share the page */ + tx = &dev->tx->ring[i].req; + tx->unused = 0; + tx->addr = virt_to_mach(dev->pages[i]); + tx->ref = gnttab_grant_access(dev->bedomid, virt_to_mfn(dev->pages[i]), 0); + /* Copy the bits to the page */ + tx->size = length > PAGE_SIZE ? PAGE_SIZE : length; + memcpy(dev->pages[i], &msg[i * PAGE_SIZE], tx->size); + + /* Update counters */ + length -= tx->size; + } + dev->waiting = 1; + dev->resplen = 0; +#ifdef HAVE_LIBC + if(dev->fd >= 0) { + files[dev->fd].read = 0; + files[dev->fd].tpmfront.respgot = 0; + files[dev->fd].tpmfront.offset = 0; + } +#endif + notify_remote_via_evtchn(dev->evtchn); + return 0; +} +int tpmfront_recv(struct tpmfront_dev* dev, uint8_t** msg, size_t *length) +{ + tpmif_tx_request_t* tx; + int i; + if(dev == NULL || dev->state != XenbusStateConnected) { + TPMFRONT_ERR("Tried to receive message from disconnected frontend\n"); + return -1; + } + /*Wait for the response */ + wait_event(dev->waitq, (!dev->waiting)); + + /* Initialize */ + *msg = NULL; + *length = 0; + + /* special case, just quit */ + tx = &dev->tx->ring[0].req; + if(tx->size == 0 ) { + goto quit; + } + /* Get the total size */ + tx = &dev->tx->ring[0].req; + for(i = 0; i < TPMIF_TX_RING_SIZE && tx->size > 0; ++i) { + tx = &dev->tx->ring[i].req; + *length += tx->size; + } + /* Alloc the buffer */ + if(dev->respbuf) { + free(dev->respbuf); + } + *msg = dev->respbuf = malloc(*length); + dev->resplen = *length; + /* Copy the bits */ + tx = &dev->tx->ring[0].req; + for(i = 0; i < TPMIF_TX_RING_SIZE && tx->size > 0; ++i) { + tx = &dev->tx->ring[i].req; + memcpy(&(*msg)[i * PAGE_SIZE], dev->pages[i], tx->size); + gnttab_end_access(tx->ref); + tx->ref = 0; + } +#ifdef TPMFRONT_PRINT_DEBUG + TPMFRONT_DEBUG("Received response from backend size=%u", (unsigned int) *length); + for(i = 0; i < *length; ++i) { + if(!(i % 30)) { + TPMFRONT_DEBUG_MORE("\n"); + } + TPMFRONT_DEBUG_MORE("%02X ", (*msg)[i]); + } + TPMFRONT_DEBUG_MORE("\n"); +#endif +#ifdef HAVE_LIBC + if(dev->fd >= 0) { + files[dev->fd].tpmfront.respgot = 1; + } +#endif +quit: + return 0; +} + +int tpmfront_cmd(struct tpmfront_dev* dev, uint8_t* req, size_t reqlen, uint8_t** resp, size_t* resplen) +{ + int rc; + if((rc = tpmfront_send(dev, req, reqlen))) { + return rc; + } + if((rc = tpmfront_recv(dev, resp, resplen))) { + return rc; + } + + return 0; +} + +#ifdef HAVE_LIBC +#include +int tpmfront_open(struct tpmfront_dev* dev) +{ + /* Silently prevent multiple opens */ + if(dev->fd != -1) { + return dev->fd; + } + + dev->fd = alloc_fd(FTYPE_TPMFRONT); + printk("tpmfront_open(%s) -> %d\n", dev->nodename, dev->fd); + files[dev->fd].tpmfront.dev = dev; + files[dev->fd].tpmfront.offset = 0; + files[dev->fd].tpmfront.respgot = 0; + return dev->fd; +} + +int tpmfront_posix_write(int fd, const uint8_t* buf, size_t count) +{ + int rc; + struct tpmfront_dev* dev; + dev = files[fd].tpmfront.dev; + + if(count == 0) { + return 0; + } + + /* Return an error if we are already processing a command */ + if(dev->waiting) { + errno = EINPROGRESS; + return -1; + } + /* Send the command now */ + if((rc = tpmfront_send(dev, buf, count)) != 0) { + errno = EIO; + return -1; + } + return count; +} + +int tpmfront_posix_read(int fd, uint8_t* buf, size_t count) +{ + int rc; + uint8_t* dummybuf; + size_t dummysz; + struct tpmfront_dev* dev; + + dev = files[fd].tpmfront.dev; + + if(count == 0) { + return 0; + } + + /* get the response if we haven't already */ + if(files[dev->fd].tpmfront.respgot == 0) { + if ((rc = tpmfront_recv(dev, &dummybuf, &dummysz)) != 0) { + errno = EIO; + return -1; + } + } + + /* handle EOF case */ + if(files[dev->fd].tpmfront.offset >= dev->resplen) { + return 0; + } + + /* Compute the number of bytes and do the copy operation */ + if((rc = min(count, dev->resplen - files[dev->fd].tpmfront.offset)) != 0) { + memcpy(buf, dev->respbuf + files[dev->fd].tpmfront.offset, rc); + files[dev->fd].tpmfront.offset += rc; + } + + return rc; +} + +int tpmfront_posix_fstat(int fd, struct stat* buf) +{ + uint8_t* dummybuf; + size_t dummysz; + int rc; + struct tpmfront_dev* dev = files[fd].tpmfront.dev; + + /* If we have a response waiting, then read it now from the backend + * so we can get its length*/ + if(dev->waiting || (files[dev->fd].read == 1 && !files[dev->fd].tpmfront.respgot)) { + if ((rc = tpmfront_recv(dev, &dummybuf, &dummysz)) != 0) { + errno = EIO; + return -1; + } + } + + buf->st_mode = O_RDWR; + buf->st_uid = 0; + buf->st_gid = 0; + buf->st_size = dev->resplen; + buf->st_atime = buf->st_mtime = buf->st_ctime = time(NULL); + + return 0; +} + + +#endif -- 1.7.4.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 16:20:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 16:20:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5D1-0005xs-7f; Tue, 02 Oct 2012 16:20:35 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5Cy-0005xc-Up for xen-devel@lists.xen.org; Tue, 02 Oct 2012 16:20:33 +0000 Received: from [85.158.139.211:3517] by server-15.bemta-5.messagelabs.com id 4C/05-19430-0541B605; Tue, 02 Oct 2012 16:20:32 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-13.tower-206.messagelabs.com!1349194825!16820148!1 X-Originating-IP: [128.244.251.37] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32144 invoked from network); 2 Oct 2012 16:20:26 -0000 Received: from piper.jhuapl.edu (HELO jhuapl.edu) (128.244.251.37) by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 16:20:26 -0000 Received: from ([128.244.207.97]) by piper.jhuapl.edu with ESMTP with TLS id 5Y8HCH1.145958854; Tue, 02 Oct 2012 12:19:57 -0400 From: Matthew Fioravante To: xen-devel@lists.xen.org, samuel.thibault@ens-lyon.org, Ian.Campbell@citrix.com Date: Tue, 2 Oct 2012 12:20:04 -0400 Message-Id: <1349194804-17973-1-git-send-email-matthew.fioravante@jhuapl.edu> X-Mailer: git-send-email 1.7.4.4 Cc: Matthew Fioravante Subject: [Xen-devel] [PATCH 08/12] add tpmfront, tpm_tis, and tpmback drivers to mini-os X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch adds 3 new drivers to mini-os. tpmfront - paravirtualized tpm frontend driver tpmback - paravirtualized tpm backend driver tpm_tis - hardware tpm driver Unfortunately these drivers were derived from GPL licensed linux kernel drivers so they must carry the GPL license. However, since mini-os now supports conditional compilation, hopefully these drivers can be included into the xen tree and conditionally removed from non-gpl projects. By default they are disabled in the makefile. Signed-off-by: Matthew Fioravante --- Changes since last version: * remove (or later version) clause from license diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile index 2422db3..2302a23 100644 --- a/extras/mini-os/Makefile +++ b/extras/mini-os/Makefile @@ -22,6 +22,9 @@ CONFIG_QEMU_XS_ARGS ?= n CONFIG_TEST ?= n CONFIG_PCIFRONT ?= n CONFIG_BLKFRONT ?= y +CONFIG_TPMFRONT ?= n +CONFIG_TPM_TIS ?= n +CONFIG_TPMBACK ?= n CONFIG_NETFRONT ?= y CONFIG_FBFRONT ?= y CONFIG_KBDFRONT ?= y @@ -36,6 +39,9 @@ flags-$(CONFIG_SPARSE_BSS) += -DCONFIG_SPARSE_BSS flags-$(CONFIG_QEMU_XS_ARGS) += -DCONFIG_QEMU_XS_ARGS flags-$(CONFIG_PCIFRONT) += -DCONFIG_PCIFRONT flags-$(CONFIG_BLKFRONT) += -DCONFIG_BLKFRONT +flags-$(CONFIG_TPMFRONT) += -DCONFIG_TPMFRONT +flags-$(CONFIG_TPM_TIS) += -DCONFIG_TPM_TIS +flags-$(CONFIG_TPMBACK) += -DCONFIG_TPMBACK flags-$(CONFIG_NETFRONT) += -DCONFIG_NETFRONT flags-$(CONFIG_KBDFRONT) += -DCONFIG_KBDFRONT flags-$(CONFIG_FBFRONT) += -DCONFIG_FBFRONT @@ -67,6 +73,9 @@ TARGET := mini-os SUBDIRS := lib xenbus console src-$(CONFIG_BLKFRONT) += blkfront.c +src-$(CONFIG_TPMFRONT) += tpmfront.c +src-$(CONFIG_TPM_TIS) += tpm_tis.c +src-$(CONFIG_TPMBACK) += tpmback.c src-y += daytime.c src-y += events.c src-$(CONFIG_FBFRONT) += fbfront.c diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h index d4641b6..935bede 100644 --- a/extras/mini-os/include/lib.h +++ b/extras/mini-os/include/lib.h @@ -142,6 +142,8 @@ enum fd_type { FTYPE_FB, FTYPE_MEM, FTYPE_SAVEFILE, + FTYPE_TPMFRONT, + FTYPE_TPM_TIS, }; LIST_HEAD(evtchn_port_list, evtchn_port_info); @@ -185,6 +187,20 @@ extern struct file { struct { struct consfront_dev *dev; } cons; +#ifdef CONFIG_TPMFRONT + struct { + struct tpmfront_dev *dev; + int respgot; + off_t offset; + } tpmfront; +#endif +#ifdef CONFIG_TPM_TIS + struct { + struct tpm_chip *dev; + int respgot; + off_t offset; + } tpm_tis; +#endif #ifdef CONFIG_XENBUS struct { /* To each xenbus FD is associated a queue of watch events for this diff --git a/extras/mini-os/include/tpm_tis.h b/extras/mini-os/include/tpm_tis.h new file mode 100644 index 0000000..c25f01c --- /dev/null +++ b/extras/mini-os/include/tpm_tis.h @@ -0,0 +1,64 @@ +/* + * Copyright (c) 2010-2012 United States Government, as represented by + * the Secretary of Defense. All rights reserved. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation, version 2 + * of the License + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + * + * Based upon the files: + * drivers/char/tpm/tpm_tis.c + * drivers/char/tpm/tpm.c + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation + */ +#ifndef TPM_TIS_H +#define TPM_TIS_H + +#include +#include + +#define TPM_TIS_EN_LOCL0 1 +#define TPM_TIS_EN_LOCL1 (1 << 1) +#define TPM_TIS_EN_LOCL2 (1 << 2) +#define TPM_TIS_EN_LOCL3 (1 << 3) +#define TPM_TIS_EN_LOCL4 (1 << 4) +#define TPM_TIS_EN_LOCLALL (TPM_TIS_EN_LOCL0 | TPM_TIS_EN_LOCL1 | TPM_TIS_EN_LOCL2 | TPM_TIS_EN_LOCL3 | TPM_TIS_EN_LOCL4) +#define TPM_TIS_LOCL_INT_TO_FLAG(x) (1 << x) +#define TPM_BASEADDR 0xFED40000 +#define TPM_PROBE_IRQ 0xFFFF + +struct tpm_chip; + +struct tpm_chip* init_tpm_tis(unsigned long baseaddr, int localities, unsigned int irq); +void shutdown_tpm_tis(struct tpm_chip* tpm); + +int tpm_tis_request_locality(struct tpm_chip* tpm, int locality); +int tpm_tis_cmd(struct tpm_chip* tpm, uint8_t* req, size_t reqlen, uint8_t** resp, size_t* resplen); + +#ifdef HAVE_LIBC +#include +#include +/* POSIX IO functions: + * use tpm_tis_open() to get a file descriptor to the tpm device + * use write() on the fd to send a command to the backend. You must + * include the entire command in a single call to write(). + * use read() on the fd to read the response. You can use + * fstat() to get the size of the response and lseek() to seek on it. + */ +int tpm_tis_open(struct tpm_chip* tpm); +int tpm_tis_posix_read(int fd, uint8_t* buf, size_t count); +int tpm_tis_posix_write(int fd, const uint8_t* buf, size_t count); +int tpm_tis_posix_fstat(int fd, struct stat* buf); +#endif + +#endif diff --git a/extras/mini-os/include/tpmback.h b/extras/mini-os/include/tpmback.h new file mode 100644 index 0000000..60e504e --- /dev/null +++ b/extras/mini-os/include/tpmback.h @@ -0,0 +1,96 @@ +/* + * Copyright (c) 2010-2012 United States Government, as represented by + * the Secretary of Defense. All rights reserved. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation, version 2 + * of the License + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + * + * Based upon the files: + * drivers/xen/tpmbk.c + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation + */ +#include +#include +#include +#include +#ifndef TPMBACK_H +#define TPMBACK_H + +struct tpmcmd { + domid_t domid; /* Domid of the frontend */ + unsigned int handle; /* Handle of the frontend */ + char* uuid; /* uuid of the tpm interface - allocated internally, dont free it */ + + unsigned int req_len; /* Size of the command in buf - set by tpmback driver */ + uint8_t* req; /* tpm command bits, allocated by driver, DON'T FREE IT */ + unsigned int resp_len; /* Size of the outgoing command, + you set this before passing the cmd object to tpmback_resp */ + uint8_t* resp; /* Buffer for response - YOU MUST ALLOCATE IT, YOU MUST ALSO FREE IT */ +}; +typedef struct tpmcmd tpmcmd_t; + +/* Initialize the tpm backend driver + * @exclusive_domname - This is NULL terminated list of vtpm uuid strings. If this list + * is non-empty, then only frontend domains with vtpm uuid's matching + * entries in this list will be allowed to connect. + * Other connections will be immediatly closed. + * Set this argument to NULL to allow any vtpm to connect. + */ +void init_tpmback(char** exclusive_uuids); +/* Shutdown tpm backend driver */ +void shutdown_tpmback(void); + +/* Blocks until a tpm command is sent from any front end. + * Returns a pointer to the tpm command to handle. + * Do not try to free this pointer or the req buffer + * This function will return NULL if the tpm backend driver + * is shutdown or any other error occurs */ +tpmcmd_t* tpmback_req_any(void); + +/* Blocks until a tpm command from the frontend at domid/handle + * is sent. + * Returns NULL if domid/handle is not connected, tpmback is + * shutdown or shutting down, or if there is an error + */ +tpmcmd_t* tpmback_req(domid_t domid, unsigned int handle); + +/* Send the response to the tpm command back to the frontend + * This function will free the tpmcmd object, but you must free the resp + * buffer yourself */ +void tpmback_resp(tpmcmd_t* tpmcmd); + +/* Waits for the first frontend to connect and then sets domid and handle appropriately. + * If one or more frontends are already connected, this will set domid and handle to one + * of them arbitrarily. The main use for this function is to wait until a single + * frontend connection has occured. + * returns 0 on success, non-zero on failure */ +int tpmback_wait_for_frontend_connect(domid_t *domid, unsigned int *handle); + +/* returns the number of frontends connected */ +int tpmback_num_frontends(void); + +/* Returns the uuid of the specified frontend, NULL on error */ +char* tpmback_get_uuid(domid_t domid, unsigned int handle); + +/* Specify a function to call when a new tpm device connects */ +void tpmback_set_open_callback(void (*cb)(domid_t, unsigned int)); + +/* Specify a function to call when a tpm device disconnects */ +void tpmback_set_close_callback(void (*cb)(domid_t, unsigned int)); + +//Not Implemented +void tpmback_set_suspend_callback(void (*cb)(domid_t, unsigned int)); +void tpmback_set_resume_callback(void (*cb)(domid_t, unsigned int)); + +#endif diff --git a/extras/mini-os/include/tpmfront.h b/extras/mini-os/include/tpmfront.h new file mode 100644 index 0000000..89b18fb --- /dev/null +++ b/extras/mini-os/include/tpmfront.h @@ -0,0 +1,97 @@ +/* + * Copyright (c) 2010-2012 United States Government, as represented by + * the Secretary of Defense. All rights reserved. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation, version 2 + * of the License + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + * + + * + * Based upon the files: + * drivers/char/tpm/tpm_vtpm.c + * drivers/char/tpm/tpm_xen.c + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation + */ +#ifndef TPMFRONT_H +#define TPMFRONT_H + +#include +#include +#include +#include +#include +#include +#include + +struct tpmfront_dev { + grant_ref_t ring_ref; + evtchn_port_t evtchn; + + tpmif_tx_interface_t* tx; + + void** pages; + + domid_t bedomid; + char* nodename; + char* bepath; + + XenbusState state; + + uint8_t waiting; + struct wait_queue_head waitq; + + uint8_t* respbuf; + size_t resplen; + +#ifdef HAVE_LIBC + int fd; +#endif + +}; + + +/*Initialize frontend */ +struct tpmfront_dev* init_tpmfront(const char* nodename); +/*Shutdown frontend */ +void shutdown_tpmfront(struct tpmfront_dev* dev); + +/* Send a tpm command to the backend and wait for the response + * + * @dev - frontend device + * @req - request buffer + * @reqlen - length of request buffer + * @resp - *resp will be set to internal response buffer, don't free it! Value is undefined on error + * @resplen - *resplen will be set to the length of the response. Value is undefined on error + * + * returns 0 on success, non zero on failure. + * */ +int tpmfront_cmd(struct tpmfront_dev* dev, uint8_t* req, size_t reqlen, uint8_t** resp, size_t* resplen); + +#ifdef HAVE_LIBC +#include +/* POSIX IO functions: + * use tpmfront_open() to get a file descriptor to the tpm device + * use write() on the fd to send a command to the backend. You must + * include the entire command in a single call to write(). + * use read() on the fd to read the response. You can use + * fstat() to get the size of the response and lseek() to seek on it. + */ +int tpmfront_open(struct tpmfront_dev* dev); +int tpmfront_posix_read(int fd, uint8_t* buf, size_t count); +int tpmfront_posix_write(int fd, const uint8_t* buf, size_t count); +int tpmfront_posix_fstat(int fd, struct stat* buf); +#endif + + +#endif diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c index 6cb97b1..d212969 100644 --- a/extras/mini-os/lib/sys.c +++ b/extras/mini-os/lib/sys.c @@ -27,6 +27,8 @@ #include #include #include +#include +#include #include #include @@ -294,6 +296,16 @@ int read(int fd, void *buf, size_t nbytes) return blkfront_posix_read(fd, buf, nbytes); } #endif +#ifdef CONFIG_TPMFRONT + case FTYPE_TPMFRONT: { + return tpmfront_posix_read(fd, buf, nbytes); + } +#endif +#ifdef CONFIG_TPM_TIS + case FTYPE_TPM_TIS: { + return tpm_tis_posix_read(fd, buf, nbytes); + } +#endif default: break; } @@ -330,6 +342,14 @@ int write(int fd, const void *buf, size_t nbytes) case FTYPE_BLK: return blkfront_posix_write(fd, buf, nbytes); #endif +#ifdef CONFIG_TPMFRONT + case FTYPE_TPMFRONT: + return tpmfront_posix_write(fd, buf, nbytes); +#endif +#ifdef CONFIG_TPM_TIS + case FTYPE_TPM_TIS: + return tpm_tis_posix_write(fd, buf, nbytes); +#endif default: break; } @@ -341,8 +361,16 @@ int write(int fd, const void *buf, size_t nbytes) off_t lseek(int fd, off_t offset, int whence) { switch(files[fd].type) { +#if defined(CONFIG_BLKFRONT) || defined(CONFIG_TPMFRONT) || defined(CONFIG_TPM_TIS) #ifdef CONFIG_BLKFRONT case FTYPE_BLK: +#endif +#ifdef CONFIG_TPMFRNT + case FTYPE_TPMFRONT: +#endif +#ifdef CONFIG_TPM_TIS + case FTYPE_TPM_TIS: +#endif switch (whence) { case SEEK_SET: files[fd].file.offset = offset; @@ -420,6 +448,18 @@ int close(int fd) files[fd].type = FTYPE_NONE; return 0; #endif +#ifdef CONFIG_TPMFRONT + case FTYPE_TPMFRONT: + shutdown_tpmfront(files[fd].tpmfront.dev); + files[fd].type = FTYPE_NONE; + return 0; +#endif +#ifdef CONFIG_TPM_TIS + case FTYPE_TPM_TIS: + shutdown_tpm_tis(files[fd].tpm_tis.dev); + files[fd].type = FTYPE_NONE; + return 0; +#endif #ifdef CONFIG_KBDFRONT case FTYPE_KBD: shutdown_kbdfront(files[fd].kbd.dev); @@ -489,6 +529,14 @@ int fstat(int fd, struct stat *buf) case FTYPE_BLK: return blkfront_posix_fstat(fd, buf); #endif +#ifdef CONFIG_TPMFRONT + case FTYPE_TPMFRONT: + return tpmfront_posix_fstat(fd, buf); +#endif +#ifdef CONFIG_TPM_TIS + case FTYPE_TPM_TIS: + return tpm_tis_posix_fstat(fd, buf); +#endif default: break; } diff --git a/extras/mini-os/tpm_tis.c b/extras/mini-os/tpm_tis.c new file mode 100644 index 0000000..1d3bd80 --- /dev/null +++ b/extras/mini-os/tpm_tis.c @@ -0,0 +1,1345 @@ +/* + * Copyright (c) 2010-2012 United States Government, as represented by + * the Secretary of Defense. All rights reserved. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation, version 2 + * of the License + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + * + * Based upon the files: + * drivers/char/tpm/tpm_tis.c + * drivers/char/tpm/tpm.c + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#ifndef min + #define min( a, b ) ( ((a) < (b)) ? (a) : (b) ) +#endif + +#define TPM_HEADER_SIZE 10 + +#define TPM_BUFSIZE 2048 + +struct tpm_input_header { + uint16_t tag; + uint32_t length; + uint32_t ordinal; +}__attribute__((packed)); + +struct tpm_output_header { + uint16_t tag; + uint32_t length; + uint32_t return_code; +}__attribute__((packed)); + +struct stclear_flags_t { + uint16_t tag; + uint8_t deactivated; + uint8_t disableForceClear; + uint8_t physicalPresence; + uint8_t physicalPresenceLock; + uint8_t bGlobalLock; +}__attribute__((packed)); + +struct tpm_version_t { + uint8_t Major; + uint8_t Minor; + uint8_t revMajor; + uint8_t revMinor; +}__attribute__((packed)); + +struct tpm_version_1_2_t { + uint16_t tag; + uint8_t Major; + uint8_t Minor; + uint8_t revMajor; + uint8_t revMinor; +}__attribute__((packed)); + +struct timeout_t { + uint32_t a; + uint32_t b; + uint32_t c; + uint32_t d; +}__attribute__((packed)); + +struct duration_t { + uint32_t tpm_short; + uint32_t tpm_medium; + uint32_t tpm_long; +}__attribute__((packed)); + +struct permanent_flags_t { + uint16_t tag; + uint8_t disable; + uint8_t ownership; + uint8_t deactivated; + uint8_t readPubek; + uint8_t disableOwnerClear; + uint8_t allowMaintenance; + uint8_t physicalPresenceLifetimeLock; + uint8_t physicalPresenceHWEnable; + uint8_t physicalPresenceCMDEnable; + uint8_t CEKPUsed; + uint8_t TPMpost; + uint8_t TPMpostLock; + uint8_t FIPS; + uint8_t operator; + uint8_t enableRevokeEK; + uint8_t nvLocked; + uint8_t readSRKPub; + uint8_t tpmEstablished; + uint8_t maintenanceDone; + uint8_t disableFullDALogicInfo; +}__attribute__((packed)); + +typedef union { + struct permanent_flags_t perm_flags; + struct stclear_flags_t stclear_flags; + bool owned; + uint32_t num_pcrs; + struct tpm_version_t tpm_version; + struct tpm_version_1_2_t tpm_version_1_2; + uint32_t manufacturer_id; + struct timeout_t timeout; + struct duration_t duration; +} cap_t; + +struct tpm_getcap_params_in { + uint32_t cap; + uint32_t subcap_size; + uint32_t subcap; +}__attribute__((packed)); + +struct tpm_getcap_params_out { + uint32_t cap_size; + cap_t cap; +}__attribute__((packed)); + +struct tpm_readpubek_params_out { + uint8_t algorithm[4]; + uint8_t encscheme[2]; + uint8_t sigscheme[2]; + uint32_t paramsize; + uint8_t parameters[12]; /*assuming RSA*/ + uint32_t keysize; + uint8_t modulus[256]; + uint8_t checksum[20]; +}__attribute__((packed)); + +typedef union { + struct tpm_input_header in; + struct tpm_output_header out; +} tpm_cmd_header; + +#define TPM_DIGEST_SIZE 20 +struct tpm_pcrread_out { + uint8_t pcr_result[TPM_DIGEST_SIZE]; +}__attribute__((packed)); + +struct tpm_pcrread_in { + uint32_t pcr_idx; +}__attribute__((packed)); + +struct tpm_pcrextend_in { + uint32_t pcr_idx; + uint8_t hash[TPM_DIGEST_SIZE]; +}__attribute__((packed)); + +typedef union { + struct tpm_getcap_params_out getcap_out; + struct tpm_readpubek_params_out readpubek_out; + uint8_t readpubek_out_buffer[sizeof(struct tpm_readpubek_params_out)]; + struct tpm_getcap_params_in getcap_in; + struct tpm_pcrread_in pcrread_in; + struct tpm_pcrread_out pcrread_out; + struct tpm_pcrextend_in pcrextend_in; +} tpm_cmd_params; + +struct tpm_cmd_t { + tpm_cmd_header header; + tpm_cmd_params params; +}__attribute__((packed)); + + +enum tpm_duration { + TPM_SHORT = 0, + TPM_MEDIUM = 1, + TPM_LONG = 2, + TPM_UNDEFINED, +}; + +#define TPM_MAX_ORDINAL 243 +#define TPM_MAX_PROTECTED_ORDINAL 12 +#define TPM_PROTECTED_ORDINAL_MASK 0xFF + +extern const uint8_t tpm_protected_ordinal_duration[TPM_MAX_PROTECTED_ORDINAL]; +extern const uint8_t tpm_ordinal_duration[TPM_MAX_ORDINAL]; + +#define TPM_DIGEST_SIZE 20 +#define TPM_ERROR_SIZE 10 +#define TPM_RET_CODE_IDX 6 + +/* tpm_capabilities */ +#define TPM_CAP_FLAG cpu_to_be32(4) +#define TPM_CAP_PROP cpu_to_be32(5) +#define CAP_VERSION_1_1 cpu_to_be32(0x06) +#define CAP_VERSION_1_2 cpu_to_be32(0x1A) + +/* tpm_sub_capabilities */ +#define TPM_CAP_PROP_PCR cpu_to_be32(0x101) +#define TPM_CAP_PROP_MANUFACTURER cpu_to_be32(0x103) +#define TPM_CAP_FLAG_PERM cpu_to_be32(0x108) +#define TPM_CAP_FLAG_VOL cpu_to_be32(0x109) +#define TPM_CAP_PROP_OWNER cpu_to_be32(0x111) +#define TPM_CAP_PROP_TIS_TIMEOUT cpu_to_be32(0x115) +#define TPM_CAP_PROP_TIS_DURATION cpu_to_be32(0x120) + + +#define TPM_INTERNAL_RESULT_SIZE 200 +#define TPM_TAG_RQU_COMMAND cpu_to_be16(193) +#define TPM_ORD_GET_CAP cpu_to_be32(101) + +extern const struct tpm_input_header tpm_getcap_header; + + + +const uint8_t tpm_protected_ordinal_duration[TPM_MAX_PROTECTED_ORDINAL] = { + TPM_UNDEFINED, /* 0 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 5 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 10 */ + TPM_SHORT, +}; + +const uint8_t tpm_ordinal_duration[TPM_MAX_ORDINAL] = { + TPM_UNDEFINED, /* 0 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 5 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 10 */ + TPM_SHORT, + TPM_MEDIUM, + TPM_LONG, + TPM_LONG, + TPM_MEDIUM, /* 15 */ + TPM_SHORT, + TPM_SHORT, + TPM_MEDIUM, + TPM_LONG, + TPM_SHORT, /* 20 */ + TPM_SHORT, + TPM_MEDIUM, + TPM_MEDIUM, + TPM_MEDIUM, + TPM_SHORT, /* 25 */ + TPM_SHORT, + TPM_MEDIUM, + TPM_SHORT, + TPM_SHORT, + TPM_MEDIUM, /* 30 */ + TPM_LONG, + TPM_MEDIUM, + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, /* 35 */ + TPM_MEDIUM, + TPM_MEDIUM, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_MEDIUM, /* 40 */ + TPM_LONG, + TPM_MEDIUM, + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, /* 45 */ + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_LONG, + TPM_MEDIUM, /* 50 */ + TPM_MEDIUM, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 55 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_MEDIUM, /* 60 */ + TPM_MEDIUM, + TPM_MEDIUM, + TPM_SHORT, + TPM_SHORT, + TPM_MEDIUM, /* 65 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 70 */ + TPM_SHORT, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 75 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_LONG, /* 80 */ + TPM_UNDEFINED, + TPM_MEDIUM, + TPM_LONG, + TPM_SHORT, + TPM_UNDEFINED, /* 85 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 90 */ + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_UNDEFINED, /* 95 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_MEDIUM, /* 100 */ + TPM_SHORT, + TPM_SHORT, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 105 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 110 */ + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, /* 115 */ + TPM_SHORT, + TPM_SHORT, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_LONG, /* 120 */ + TPM_LONG, + TPM_MEDIUM, + TPM_UNDEFINED, + TPM_SHORT, + TPM_SHORT, /* 125 */ + TPM_SHORT, + TPM_LONG, + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, /* 130 */ + TPM_MEDIUM, + TPM_UNDEFINED, + TPM_SHORT, + TPM_MEDIUM, + TPM_UNDEFINED, /* 135 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 140 */ + TPM_SHORT, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 145 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 150 */ + TPM_MEDIUM, + TPM_MEDIUM, + TPM_SHORT, + TPM_SHORT, + TPM_UNDEFINED, /* 155 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 160 */ + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 165 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_LONG, /* 170 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 175 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_MEDIUM, /* 180 */ + TPM_SHORT, + TPM_MEDIUM, + TPM_MEDIUM, + TPM_MEDIUM, + TPM_MEDIUM, /* 185 */ + TPM_SHORT, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 190 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 195 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 200 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, + TPM_SHORT, /* 205 */ + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_MEDIUM, /* 210 */ + TPM_UNDEFINED, + TPM_MEDIUM, + TPM_MEDIUM, + TPM_MEDIUM, + TPM_UNDEFINED, /* 215 */ + TPM_MEDIUM, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, + TPM_SHORT, /* 220 */ + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_UNDEFINED, /* 225 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 230 */ + TPM_LONG, + TPM_MEDIUM, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 235 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 240 */ + TPM_UNDEFINED, + TPM_MEDIUM, +}; + +const struct tpm_input_header tpm_getcap_header = { + .tag = TPM_TAG_RQU_COMMAND, + .length = cpu_to_be32(22), + .ordinal = TPM_ORD_GET_CAP +}; + + +enum tis_access { + TPM_ACCESS_VALID = 0x80, + TPM_ACCESS_ACTIVE_LOCALITY = 0x20, /* (R) */ + TPM_ACCESS_RELINQUISH_LOCALITY = 0x20,/* (W) */ + TPM_ACCESS_REQUEST_PENDING = 0x04, /* (W) */ + TPM_ACCESS_REQUEST_USE = 0x02, /* (W) */ +}; + +enum tis_status { + TPM_STS_VALID = 0x80, /* (R) */ + TPM_STS_COMMAND_READY = 0x40, /* (R) */ + TPM_STS_DATA_AVAIL = 0x10, /* (R) */ + TPM_STS_DATA_EXPECT = 0x08, /* (R) */ + TPM_STS_GO = 0x20, /* (W) */ +}; + +enum tis_int_flags { + TPM_GLOBAL_INT_ENABLE = 0x80000000, + TPM_INTF_BURST_COUNT_STATIC = 0x100, + TPM_INTF_CMD_READY_INT = 0x080, + TPM_INTF_INT_EDGE_FALLING = 0x040, + TPM_INTF_INT_EDGE_RISING = 0x020, + TPM_INTF_INT_LEVEL_LOW = 0x010, + TPM_INTF_INT_LEVEL_HIGH = 0x008, + TPM_INTF_LOCALITY_CHANGE_INT = 0x004, + TPM_INTF_STS_VALID_INT = 0x002, + TPM_INTF_DATA_AVAIL_INT = 0x001, +}; + +enum tis_defaults { + TIS_MEM_BASE = 0xFED40000, + TIS_MEM_LEN = 0x5000, + TIS_SHORT_TIMEOUT = 750, /*ms*/ + TIS_LONG_TIMEOUT = 2000, /*2 sec */ +}; + +#define TPM_TIMEOUT 5 + +#define TPM_ACCESS(t, l) (((uint8_t*)t->pages[l]) + 0x0000) +#define TPM_INT_ENABLE(t, l) ((uint32_t*)(((uint8_t*)t->pages[l]) + 0x0008)) +#define TPM_INT_VECTOR(t, l) (((uint8_t*)t->pages[l]) + 0x000C) +#define TPM_INT_STATUS(t, l) (((uint8_t*)t->pages[l]) + 0x0010) +#define TPM_INTF_CAPS(t, l) ((uint32_t*)(((uint8_t*)t->pages[l]) + 0x0014)) +#define TPM_STS(t, l) ((uint8_t*)(((uint8_t*)t->pages[l]) + 0x0018)) +#define TPM_DATA_FIFO(t, l) (((uint8_t*)t->pages[l]) + 0x0024) + +#define TPM_DID_VID(t, l) ((uint32_t*)(((uint8_t*)t->pages[l]) + 0x0F00)) +#define TPM_RID(t, l) (((uint8_t*)t->pages[l]) + 0x0F04) + +struct tpm_chip { + int enabled_localities; + int locality; + unsigned long baseaddr; + uint8_t* pages[5]; + int did, vid, rid; + + uint8_t data_buffer[TPM_BUFSIZE]; + int data_len; + + s_time_t timeout_a, timeout_b, timeout_c, timeout_d; + s_time_t duration[3]; + +#ifdef HAVE_LIBC + int fd; +#endif + + unsigned int irq; + struct wait_queue_head read_queue; + struct wait_queue_head int_queue; +}; + + +static void __init_tpm_chip(struct tpm_chip* tpm) { + tpm->enabled_localities = TPM_TIS_EN_LOCLALL; + tpm->locality = -1; + tpm->baseaddr = 0; + tpm->pages[0] = tpm->pages[1] = tpm->pages[2] = tpm->pages[3] = tpm->pages[4] = NULL; + tpm->vid = 0; + tpm->did = 0; + tpm->irq = 0; + init_waitqueue_head(&tpm->read_queue); + init_waitqueue_head(&tpm->int_queue); + + tpm->data_len = -1; + +#ifdef HAVE_LIBC + tpm->fd = -1; +#endif +} + +/* + * Returns max number of nsecs to wait + */ +s_time_t tpm_calc_ordinal_duration(struct tpm_chip *chip, + uint32_t ordinal) +{ + int duration_idx = TPM_UNDEFINED; + s_time_t duration = 0; + + if (ordinal < TPM_MAX_ORDINAL) + duration_idx = tpm_ordinal_duration[ordinal]; + else if ((ordinal & TPM_PROTECTED_ORDINAL_MASK) < + TPM_MAX_PROTECTED_ORDINAL) + duration_idx = + tpm_protected_ordinal_duration[ordinal & + TPM_PROTECTED_ORDINAL_MASK]; + + if (duration_idx != TPM_UNDEFINED) { + duration = chip->duration[duration_idx]; + } + + if (duration <= 0) { + return SECONDS(120); + } + else + { + return duration; + } +} + + +static int locality_enabled(struct tpm_chip* tpm, int l) { + return tpm->enabled_localities & (1 << l); +} + +static int check_locality(struct tpm_chip* tpm, int l) { + if(locality_enabled(tpm, l) && (ioread8(TPM_ACCESS(tpm, l)) & + (TPM_ACCESS_ACTIVE_LOCALITY | TPM_ACCESS_VALID)) == + (TPM_ACCESS_ACTIVE_LOCALITY | TPM_ACCESS_VALID)) { + return l; + } + return -1; +} + +void release_locality(struct tpm_chip* tpm, int l, int force) +{ + if (locality_enabled(tpm, l) && (force || (ioread8(TPM_ACCESS(tpm, l)) & + (TPM_ACCESS_REQUEST_PENDING | TPM_ACCESS_VALID)) == + (TPM_ACCESS_REQUEST_PENDING | TPM_ACCESS_VALID))) { + iowrite8(TPM_ACCESS(tpm, l), TPM_ACCESS_RELINQUISH_LOCALITY); + } +} + +int tpm_tis_request_locality(struct tpm_chip* tpm, int l) { + + s_time_t stop; + /*Make sure locality is valid */ + if(!locality_enabled(tpm, l)) { + printk("tpm_tis_change_locality() Tried to change to locality %d, but it is disabled or invalid!\n", l); + return -1; + } + /* Check if we already have the current locality */ + if(check_locality(tpm, l) >= 0) { + return tpm->locality = l; + } + /* Set the new locality*/ + iowrite8(TPM_ACCESS(tpm, l), TPM_ACCESS_REQUEST_USE); + + if(tpm->irq) { + /* Wait for interrupt */ + wait_event_deadline(tpm->int_queue, (check_locality(tpm, l) >= 0), NOW() + tpm->timeout_a); + + /* FIXME: Handle timeout event, should return error in that case */ + return l; + } else { + /* Wait for burstcount */ + stop = NOW() + tpm->timeout_a; + do { + if(check_locality(tpm, l) >= 0) { + return tpm->locality = l; + } + msleep(TPM_TIMEOUT); + } while(NOW() < stop); + } + + printk("REQ LOCALITY FAILURE\n"); + return -1; +} + +static uint8_t tpm_tis_status(struct tpm_chip* tpm) { + return ioread8(TPM_STS(tpm, tpm->locality)); +} + +/* This causes the current command to be aborted */ +static void tpm_tis_ready(struct tpm_chip* tpm) { + iowrite8(TPM_STS(tpm, tpm->locality), TPM_STS_COMMAND_READY); +} +#define tpm_tis_cancel_cmd(v) tpm_tis_ready(v) + +static int get_burstcount(struct tpm_chip* tpm) { + s_time_t stop; + int burstcnt; + + stop = NOW() + tpm->timeout_d; + do { + burstcnt = ioread8((TPM_STS(tpm, tpm->locality) + 1)); + burstcnt += ioread8(TPM_STS(tpm, tpm->locality) + 2) << 8; + + if (burstcnt) { + return burstcnt; + } + msleep(TPM_TIMEOUT); + } while(NOW() < stop); + return -EBUSY; +} + +static int wait_for_stat(struct tpm_chip* tpm, uint8_t mask, + unsigned long timeout, struct wait_queue_head* queue) { + s_time_t stop; + uint8_t status; + + status = tpm_tis_status(tpm); + if((status & mask) == mask) { + return 0; + } + + if(tpm->irq) { + wait_event_deadline(*queue, ((tpm_tis_status(tpm) & mask) == mask), timeout); + /* FIXME: Check for timeout and return -ETIME */ + return 0; + } else { + stop = NOW() + timeout; + do { + msleep(TPM_TIMEOUT); + status = tpm_tis_status(tpm); + if((status & mask) == mask) + return 0; + } while( NOW() < stop); + } + return -ETIME; +} + +static int recv_data(struct tpm_chip* tpm, uint8_t* buf, size_t count) { + int size = 0; + int burstcnt; + while( size < count && + wait_for_stat(tpm, + TPM_STS_DATA_AVAIL | TPM_STS_VALID, + tpm->timeout_c, + &tpm->read_queue) + == 0) { + burstcnt = get_burstcount(tpm); + for(; burstcnt > 0 && size < count; --burstcnt) + { + buf[size++] = ioread8(TPM_DATA_FIFO(tpm, tpm->locality)); + } + } + return size; +} + +int tpm_tis_recv(struct tpm_chip* tpm, uint8_t* buf, size_t count) { + int size = 0; + int expected, status; + + if (count < TPM_HEADER_SIZE) { + size = -EIO; + goto out; + } + + /* read first 10 bytes, including tag, paramsize, and result */ + if((size = + recv_data(tpm, buf, TPM_HEADER_SIZE)) < TPM_HEADER_SIZE) { + printk("Error reading tpm cmd header\n"); + goto out; + } + + expected = be32_to_cpu(*((uint32_t*)(buf + 2))); + if(expected > count) { + size = -EIO; + goto out; + } + + if((size += recv_data(tpm, & buf[TPM_HEADER_SIZE], + expected - TPM_HEADER_SIZE)) < expected) { + printk("Unable to read rest of tpm command size=%d expected=%d\n", size, expected); + size = -ETIME; + goto out; + } + + wait_for_stat(tpm, TPM_STS_VALID, tpm->timeout_c, &tpm->int_queue); + status = tpm_tis_status(tpm); + if(status & TPM_STS_DATA_AVAIL) { + printk("Error: left over data\n"); + size = -EIO; + goto out; + } + +out: + tpm_tis_ready(tpm); + release_locality(tpm, tpm->locality, 0); + return size; +} +int tpm_tis_send(struct tpm_chip* tpm, uint8_t* buf, size_t len) { + int rc; + int status, burstcnt = 0; + int count = 0; + uint32_t ordinal; + + if(tpm_tis_request_locality(tpm, tpm->locality) < 0) { + return -EBUSY; + } + + status = tpm_tis_status(tpm); + if((status & TPM_STS_COMMAND_READY) == 0) { + tpm_tis_ready(tpm); + if(wait_for_stat(tpm, TPM_STS_COMMAND_READY, tpm->timeout_b, &tpm->int_queue) < 0) { + rc = -ETIME; + goto out_err; + } + } + + while(count < len - 1) { + burstcnt = get_burstcount(tpm); + for(;burstcnt > 0 && count < len -1; --burstcnt) { + iowrite8(TPM_DATA_FIFO(tpm, tpm->locality), buf[count++]); + } + + wait_for_stat(tpm, TPM_STS_VALID, tpm->timeout_c, &tpm->int_queue); + status = tpm_tis_status(tpm); + if((status & TPM_STS_DATA_EXPECT) == 0) { + rc = -EIO; + goto out_err; + } + } + + /*Write last byte*/ + iowrite8(TPM_DATA_FIFO(tpm, tpm->locality), buf[count]); + wait_for_stat(tpm, TPM_STS_VALID, tpm->timeout_c, &tpm->read_queue); + status = tpm_tis_status(tpm); + if((status & TPM_STS_DATA_EXPECT) != 0) { + rc = -EIO; + goto out_err; + } + + /*go and do it*/ + iowrite8(TPM_STS(tpm, tpm->locality), TPM_STS_GO); + + if(tpm->irq) { + /*Wait for interrupt */ + ordinal = be32_to_cpu(*(buf + 6)); + if(wait_for_stat(tpm, + TPM_STS_DATA_AVAIL | TPM_STS_VALID, + tpm_calc_ordinal_duration(tpm, ordinal), + &tpm->read_queue) < 0) { + rc = -ETIME; + goto out_err; + } + } +#ifdef HAVE_LIBC + if(tpm->fd >= 0) { + files[tpm->fd].read = 0; + files[tpm->fd].tpm_tis.respgot = 0; + files[tpm->fd].tpm_tis.offset = 0; + } +#endif + return len; + +out_err: + tpm_tis_ready(tpm); + release_locality(tpm, tpm->locality, 0); + return rc; +} + +static void tpm_tis_irq_handler(evtchn_port_t port, struct pt_regs *regs, void* data) +{ + struct tpm_chip* tpm = data; + uint32_t interrupt; + int i; + + interrupt = ioread32(TPM_INT_STATUS(tpm, tpm->locality)); + if(interrupt == 0) { + return; + } + + if(interrupt & TPM_INTF_DATA_AVAIL_INT) { + wake_up(&tpm->read_queue); + } + if(interrupt & TPM_INTF_LOCALITY_CHANGE_INT) { + for(i = 0; i < 5; ++i) { + if(check_locality(tpm, i) >= 0) { + break; + } + } + } + if(interrupt & (TPM_INTF_LOCALITY_CHANGE_INT | TPM_INTF_STS_VALID_INT | + TPM_INTF_CMD_READY_INT)) { + wake_up(&tpm->int_queue); + } + + /* Clear interrupts handled with TPM_EOI */ + iowrite32(TPM_INT_STATUS(tpm, tpm->locality), interrupt); + ioread32(TPM_INT_STATUS(tpm, tpm->locality)); + return; +} + +/* + * Internal kernel interface to transmit TPM commands + */ +static ssize_t tpm_transmit(struct tpm_chip *chip, const uint8_t *buf, + size_t bufsiz) +{ + ssize_t rc; + uint32_t count, ordinal; + s_time_t stop; + + count = be32_to_cpu(*((uint32_t *) (buf + 2))); + ordinal = be32_to_cpu(*((uint32_t *) (buf + 6))); + if (count == 0) + return -ENODATA; + if (count > bufsiz) { + printk("Error: invalid count value %x %zx \n", count, bufsiz); + return -E2BIG; + } + + //down(&chip->tpm_mutex); + + if ((rc = tpm_tis_send(chip, (uint8_t *) buf, count)) < 0) { + printk("tpm_transmit: tpm_send: error %zd\n", rc); + goto out; + } + + if (chip->irq) + goto out_recv; + + stop = NOW() + tpm_calc_ordinal_duration(chip, ordinal); + do { + uint8_t status = tpm_tis_status(chip); + if ((status & (TPM_STS_DATA_AVAIL | TPM_STS_VALID)) == + (TPM_STS_DATA_AVAIL | TPM_STS_VALID)) + goto out_recv; + + if ((status == TPM_STS_COMMAND_READY)) { + printk("TPM Error: Operation Canceled\n"); + rc = -ECANCELED; + goto out; + } + + msleep(TPM_TIMEOUT); /* CHECK */ + rmb(); + } while (NOW() < stop); + + /* Cancel the command */ + tpm_tis_cancel_cmd(chip); + printk("TPM Operation Timed out\n"); + rc = -ETIME; + goto out; + +out_recv: + if((rc = tpm_tis_recv(chip, (uint8_t *) buf, bufsiz)) < 0) { + printk("tpm_transmit: tpm_recv: error %d\n", rc); + } +out: + //up(&chip->tpm_mutex); + return rc; +} + +static ssize_t transmit_cmd(struct tpm_chip *chip, struct tpm_cmd_t *cmd, + int len, const char *desc) +{ + int err; + + len = tpm_transmit(chip,(uint8_t *) cmd, len); + if (len < 0) + return len; + if (len == TPM_ERROR_SIZE) { + err = be32_to_cpu(cmd->header.out.return_code); + printk("A TPM error (%d) occurred %s\n", err, desc); + return err; + } + return 0; +} + +void tpm_get_timeouts(struct tpm_chip *chip) +{ + struct tpm_cmd_t tpm_cmd; + struct timeout_t *timeout_cap; + struct duration_t *duration_cap; + ssize_t rc; + uint32_t timeout; + + tpm_cmd.header.in = tpm_getcap_header; + tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP; + tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4); + tpm_cmd.params.getcap_in.subcap = TPM_CAP_PROP_TIS_TIMEOUT; + + if((rc = transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE, + "attempting to determine the timeouts")) != 0) { + printk("transmit failed %d\n", rc); + goto duration; + } + + if (be32_to_cpu(tpm_cmd.params.getcap_out.cap_size) + != 4 * sizeof(uint32_t)) { + printk("Out len check failure %lu \n", be32_to_cpu(tpm_cmd.header.out.length)); + goto duration; + } + + timeout_cap = &tpm_cmd.params.getcap_out.cap.timeout; + /* Don't overwrite default if value is 0 */ + timeout = be32_to_cpu(timeout_cap->a); + if (timeout) + chip->timeout_a = MICROSECS(timeout); /*Convert to msec */ + timeout = be32_to_cpu(timeout_cap->b); + if (timeout) + chip->timeout_b = MICROSECS(timeout); /*Convert to msec */ + timeout = be32_to_cpu(timeout_cap->c); + if (timeout) + chip->timeout_c = MICROSECS(timeout); /*Convert to msec */ + timeout = be32_to_cpu(timeout_cap->d); + if (timeout) + chip->timeout_d = MICROSECS(timeout); /*Convert to msec */ + +duration: + tpm_cmd.header.in = tpm_getcap_header; + tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP; + tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4); + tpm_cmd.params.getcap_in.subcap = TPM_CAP_PROP_TIS_DURATION; + + if((rc = transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE, + "attempting to determine the durations")) < 0) { + return; + } + + if (be32_to_cpu(tpm_cmd.params.getcap_out.cap_size) + != 3 * sizeof(uint32_t)) { + return; + } + duration_cap = &tpm_cmd.params.getcap_out.cap.duration; + chip->duration[TPM_SHORT] = be32_to_cpu(duration_cap->tpm_short); + /* The Broadcom BCM0102 chipset in a Dell Latitude D820 gets the above + * value wrong and apparently reports msecs rather than usecs. So we + * fix up the resulting too-small TPM_SHORT value to make things work. + */ + if (chip->duration[TPM_SHORT] < 10) { + chip->duration[TPM_SHORT] = MILLISECS(chip->duration[TPM_SHORT]); + } else { + chip->duration[TPM_SHORT] = MICROSECS(chip->duration[TPM_SHORT]); + } + + chip->duration[TPM_MEDIUM] = MICROSECS(be32_to_cpu(duration_cap->tpm_medium)); + chip->duration[TPM_LONG] = MICROSECS(be32_to_cpu(duration_cap->tpm_long)); +} + + + +void tpm_continue_selftest(struct tpm_chip* chip) { + uint8_t data[] = { + 0, 193, /* TPM_TAG_RQU_COMMAND */ + 0, 0, 0, 10, /* length */ + 0, 0, 0, 83, /* TPM_ORD_GetCapability */ + }; + + tpm_transmit(chip, data, sizeof(data)); +} + +ssize_t tpm_getcap(struct tpm_chip *chip, uint32_t subcap_id, cap_t *cap, + const char *desc) +{ + struct tpm_cmd_t tpm_cmd; + int rc; + + tpm_cmd.header.in = tpm_getcap_header; + if (subcap_id == CAP_VERSION_1_1 || subcap_id == CAP_VERSION_1_2) { + tpm_cmd.params.getcap_in.cap = subcap_id; + /*subcap field not necessary */ + tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(0); + tpm_cmd.header.in.length -= cpu_to_be32(sizeof(uint32_t)); + } else { + if (subcap_id == TPM_CAP_FLAG_PERM || + subcap_id == TPM_CAP_FLAG_VOL) + tpm_cmd.params.getcap_in.cap = TPM_CAP_FLAG; + else + tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP; + tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4); + tpm_cmd.params.getcap_in.subcap = subcap_id; + } + rc = transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE, desc); + if (!rc) + *cap = tpm_cmd.params.getcap_out.cap; + return rc; +} + + +struct tpm_chip* init_tpm_tis(unsigned long baseaddr, int localities, unsigned int irq) +{ + int i; + unsigned long addr; + struct tpm_chip* tpm = NULL; + uint32_t didvid; + uint32_t intfcaps; + uint32_t intmask; + + printk("============= Init TPM TIS Driver ==============\n"); + + /*Sanity check the localities input */ + if(localities & ~TPM_TIS_EN_LOCLALL) { + printk("init_tpm_tis() Invalid locality specification! %X\n", localities); + goto abort_egress; + } + + printk("IOMEM Machine Base Address: %lX\n", baseaddr); + + /* Create the tpm data structure */ + tpm = malloc(sizeof(struct tpm_chip)); + __init_tpm_chip(tpm); + + /* Set the enabled localities - if 0 we leave default as all enabled */ + if(localities != 0) { + tpm->enabled_localities = localities; + } + printk("Enabled Localities: "); + for(i = 0; i < 5; ++i) { + if(locality_enabled(tpm, i)) { + printk("%d ", i); + } + } + printk("\n"); + + /* Set the base machine address */ + tpm->baseaddr = baseaddr; + + /* Set default timeouts */ + tpm->timeout_a = MILLISECS(TIS_SHORT_TIMEOUT); + tpm->timeout_b = MILLISECS(TIS_LONG_TIMEOUT); + tpm->timeout_c = MILLISECS(TIS_SHORT_TIMEOUT); + tpm->timeout_d = MILLISECS(TIS_SHORT_TIMEOUT); + + /*Map the mmio pages */ + addr = tpm->baseaddr; + for(i = 0; i < 5; ++i) { + if(locality_enabled(tpm, i)) { + /* Map the page in now */ + if((tpm->pages[i] = ioremap_nocache(addr, PAGE_SIZE)) == NULL) { + printk("Unable to map iomem page a address %p\n", addr); + goto abort_egress; + } + + /* Set default locality to the first enabled one */ + if (tpm->locality < 0) { + if(tpm_tis_request_locality(tpm, i) < 0) { + printk("Unable to request locality %d??\n", i); + goto abort_egress; + } + } + } + addr += PAGE_SIZE; + } + + + /* Get the vendor and device ids */ + didvid = ioread32(TPM_DID_VID(tpm, tpm->locality)); + tpm->did = didvid >> 16; + tpm->vid = didvid & 0xFFFF; + + + /* Get the revision id */ + tpm->rid = ioread8(TPM_RID(tpm, tpm->locality)); + + printk("1.2 TPM (device-id=0x%X vendor-id = %X rev-id = %X)\n", tpm->did, tpm->vid, tpm->rid); + + intfcaps = ioread32(TPM_INTF_CAPS(tpm, tpm->locality)); + printk("TPM interface capabilities (0x%x):\n", intfcaps); + if (intfcaps & TPM_INTF_BURST_COUNT_STATIC) + printk("\tBurst Count Static\n"); + if (intfcaps & TPM_INTF_CMD_READY_INT) + printk("\tCommand Ready Int Support\n"); + if (intfcaps & TPM_INTF_INT_EDGE_FALLING) + printk("\tInterrupt Edge Falling\n"); + if (intfcaps & TPM_INTF_INT_EDGE_RISING) + printk("\tInterrupt Edge Rising\n"); + if (intfcaps & TPM_INTF_INT_LEVEL_LOW) + printk("\tInterrupt Level Low\n"); + if (intfcaps & TPM_INTF_INT_LEVEL_HIGH) + printk("\tInterrupt Level High\n"); + if (intfcaps & TPM_INTF_LOCALITY_CHANGE_INT) + printk("\tLocality Change Int Support\n"); + if (intfcaps & TPM_INTF_STS_VALID_INT) + printk("\tSts Valid Int Support\n"); + if (intfcaps & TPM_INTF_DATA_AVAIL_INT) + printk("\tData Avail Int Support\n"); + + /*Interupt setup */ + intmask = ioread32(TPM_INT_ENABLE(tpm, tpm->locality)); + + intmask |= TPM_INTF_CMD_READY_INT + | TPM_INTF_LOCALITY_CHANGE_INT | TPM_INTF_DATA_AVAIL_INT + | TPM_INTF_STS_VALID_INT; + + iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), intmask); + + /*If interupts are enabled, handle it */ + if(irq) { + if(irq != TPM_PROBE_IRQ) { + tpm->irq = irq; + } else { + /*FIXME add irq probing feature later */ + printk("IRQ probing not implemented\n"); + } + } + + if(tpm->irq) { + iowrite8(TPM_INT_VECTOR(tpm, tpm->locality), tpm->irq); + + if(bind_pirq(tpm->irq, 1, tpm_tis_irq_handler, tpm) != 0) { + printk("Unabled to request irq: %u for use\n", tpm->irq); + printk("Will use polling mode\n"); + tpm->irq = 0; + } else { + /* Clear all existing */ + iowrite32(TPM_INT_STATUS(tpm, tpm->locality), ioread32(TPM_INT_STATUS(tpm, tpm->locality))); + + /* Turn on interrupts */ + iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), intmask | TPM_GLOBAL_INT_ENABLE); + } + } + + tpm_get_timeouts(tpm); + tpm_continue_selftest(tpm); + + + return tpm; +abort_egress: + if(tpm != NULL) { + shutdown_tpm_tis(tpm); + } + return NULL; +} + +void shutdown_tpm_tis(struct tpm_chip* tpm){ + int i; + + printk("Shutting down tpm_tis device\n"); + + iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), ~TPM_GLOBAL_INT_ENABLE); + + /*Unmap all of the mmio pages */ + for(i = 0; i < 5; ++i) { + if(tpm->pages[i] != NULL) { + iounmap(tpm->pages[i], PAGE_SIZE); + tpm->pages[i] = NULL; + } + } + free(tpm); + return; +} + + +int tpm_tis_cmd(struct tpm_chip* tpm, uint8_t* req, size_t reqlen, uint8_t** resp, size_t* resplen) +{ + if(tpm->locality < 0) { + printk("tpm_tis_cmd() failed! locality not set!\n"); + return -1; + } + if(reqlen > TPM_BUFSIZE) { + reqlen = TPM_BUFSIZE; + } + memcpy(tpm->data_buffer, req, reqlen); + *resplen = tpm_transmit(tpm, tpm->data_buffer, TPM_BUFSIZE); + + *resp = malloc(*resplen); + memcpy(*resp, tpm->data_buffer, *resplen); + return 0; +} + +#ifdef HAVE_LIBC +int tpm_tis_open(struct tpm_chip* tpm) +{ + /* Silently prevent multiple opens */ + if(tpm->fd != -1) { + return tpm->fd; + } + + tpm->fd = alloc_fd(FTYPE_TPM_TIS); + printk("tpm_tis_open() -> %d\n", tpm->fd); + files[tpm->fd].tpm_tis.dev = tpm; + files[tpm->fd].tpm_tis.offset = 0; + files[tpm->fd].tpm_tis.respgot = 0; + return tpm->fd; +} + +int tpm_tis_posix_write(int fd, const uint8_t* buf, size_t count) +{ + struct tpm_chip* tpm; + tpm = files[fd].tpm_tis.dev; + + if(tpm->locality < 0) { + printk("tpm_tis_posix_write() failed! locality not set!\n"); + errno = EINPROGRESS; + return -1; + } + if(count == 0) { + return 0; + } + + /* Return an error if we are already processing a command */ + if(count > TPM_BUFSIZE) { + count = TPM_BUFSIZE; + } + /* Send the command now */ + memcpy(tpm->data_buffer, buf, count); + if((tpm->data_len = tpm_transmit(tpm, tpm->data_buffer, TPM_BUFSIZE)) < 0) { + errno = EIO; + return -1; + } + return count; +} + +int tpm_tis_posix_read(int fd, uint8_t* buf, size_t count) +{ + int rc; + struct tpm_chip* tpm; + tpm = files[fd].tpm_tis.dev; + + if(count == 0) { + return 0; + } + + /* If there is no tpm resp to read, return EIO */ + if(tpm->data_len < 0) { + errno = EIO; + return -1; + } + + + /* Handle EOF case */ + if(files[fd].tpm_tis.offset >= tpm->data_len) { + rc = 0; + } else { + rc = min(tpm->data_len - files[fd].tpm_tis.offset, count); + memcpy(buf, tpm->data_buffer + files[fd].tpm_tis.offset, rc); + } + files[fd].tpm_tis.offset += rc; + /* Reset the data pending flag */ + return rc; +} +int tpm_tis_posix_fstat(int fd, struct stat* buf) +{ + struct tpm_chip* tpm; + tpm = files[fd].tpm_tis.dev; + + buf->st_mode = O_RDWR; + buf->st_uid = 0; + buf->st_gid = 0; + buf->st_size = be32_to_cpu(*((uint32_t*)(tpm->data_buffer + 2))); + buf->st_atime = buf->st_mtime = buf->st_ctime = time(NULL); + return 0; +} + + +#endif diff --git a/extras/mini-os/tpmback.c b/extras/mini-os/tpmback.c new file mode 100644 index 0000000..28d786a --- /dev/null +++ b/extras/mini-os/tpmback.c @@ -0,0 +1,1115 @@ +/* + * Copyright (c) 2010-2012 United States Government, as represented by + * the Secretary of Defense. All rights reserved. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation, version 2 + * of the License + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + * + * Based upon the files: + * drivers/xen/tpmbk.c + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + + +#ifndef HAVE_LIBC +#define strtoul simple_strtoul +#endif + +//#define TPMBACK_PRINT_DEBUG +#ifdef TPMBACK_PRINT_DEBUG +#define TPMBACK_DEBUG(fmt,...) printk("Tpmback:Debug("__FILE__":%d) " fmt, __LINE__, ##__VA_ARGS__) +#define TPMBACK_DEBUG_MORE(fmt,...) printk(fmt, ##__VA_ARGS__) +#else +#define TPMBACK_DEBUG(fmt,...) +#endif +#define TPMBACK_ERR(fmt,...) printk("Tpmback:Error " fmt, ##__VA_ARGS__) +#define TPMBACK_LOG(fmt,...) printk("Tpmback:Info " fmt, ##__VA_ARGS__) + +#define min(a,b) (((a) < (b)) ? (a) : (b)) + +/* Default size of the tpmif array at initialization */ +#define DEF_ARRAY_SIZE 1 + +/* tpmif and tpmdev flags */ +#define TPMIF_CLOSED 1 +#define TPMIF_REQ_READY 2 + +struct tpmif { + domid_t domid; + unsigned int handle; + + char* fe_path; + char* fe_state_path; + + /* Locally bound event channel*/ + evtchn_port_t evtchn; + + /* Shared page */ + tpmif_tx_interface_t* tx; + + /* pointer to TPMIF_RX_RING_SIZE pages */ + void** pages; + + enum xenbus_state state; + enum { DISCONNECTED, DISCONNECTING, CONNECTED } status; + + char* uuid; + + /* state flags */ + int flags; +}; +typedef struct tpmif tpmif_t; + +struct tpmback_dev { + + tpmif_t** tpmlist; + unsigned long num_tpms; + unsigned long num_alloc; + + struct gntmap map; + + /* True if at least one tpmif has a request to be handled */ + int flags; + + /* exclusive domains, see init_tpmback comment in tpmback.h */ + char** exclusive_uuids; + + xenbus_event_queue events; + + /* Callbacks */ + void (*open_callback)(domid_t, unsigned int); + void (*close_callback)(domid_t, unsigned int); + void (*suspend_callback)(domid_t, unsigned int); + void (*resume_callback)(domid_t, unsigned int); +}; +typedef struct tpmback_dev tpmback_dev_t; + +enum { EV_NONE, EV_NEWFE, EV_STCHNG } tpm_ev_enum; + +/* Global objects */ +static struct thread* eventthread = NULL; +static tpmback_dev_t gtpmdev = { + .tpmlist = NULL, + .num_tpms = 0, + .num_alloc = 0, + .flags = TPMIF_CLOSED, + .events = NULL, + .open_callback = NULL, + .close_callback = NULL, + .suspend_callback = NULL, + .resume_callback = NULL, +}; +struct wait_queue_head waitq; +int globalinit = 0; + +/************************************ + * TPMIF SORTED ARRAY FUNCTIONS + * tpmback_dev_t.tpmlist is a sorted array, sorted by domid and then handle number + * Duplicates are not allowed + * **********************************/ + +inline void tpmif_req_ready(tpmif_t* tpmif) { + tpmif->flags |= TPMIF_REQ_READY; + gtpmdev.flags |= TPMIF_REQ_READY; +} + +inline void tpmdev_check_req(void) { + int i; + int flags; + local_irq_save(flags); + for(i = 0; i < gtpmdev.num_tpms; ++i) { + if(gtpmdev.tpmlist[i]->flags & TPMIF_REQ_READY) { + gtpmdev.flags |= TPMIF_REQ_READY; + local_irq_restore(flags); + return; + } + } + gtpmdev.flags &= ~TPMIF_REQ_READY; + local_irq_restore(flags); +} + +inline void tpmif_req_finished(tpmif_t* tpmif) { + tpmif->flags &= ~TPMIF_REQ_READY; + tpmdev_check_req(); +} + +int __get_tpmif_index(int st, int n, domid_t domid, unsigned int handle) +{ + int i = st + n /2; + tpmif_t* tmp; + + if( n <= 0 ) + return -1; + + tmp = gtpmdev.tpmlist[i]; + if(domid == tmp->domid && tmp->handle == handle) { + return i; + } else if ( (domid < tmp->domid) || + (domid == tmp->domid && handle < tmp->handle)) { + return __get_tpmif_index(st, n/2, domid, handle); + } else { + return __get_tpmif_index(i + 1, n/2 - ((n +1) % 2), domid, handle); + } +} + +/* Returns the array index of the tpmif domid/handle. Returns -1 if no such tpmif exists */ +int get_tpmif_index(domid_t domid, unsigned int handle) +{ + int flags; + int index; + local_irq_save(flags); + index = __get_tpmif_index(0, gtpmdev.num_tpms, domid, handle); + local_irq_restore(flags); + return index; +} + +/* Returns the tpmif domid/handle or NULL if none exists */ +tpmif_t* get_tpmif(domid_t domid, unsigned int handle) +{ + int flags; + int i; + tpmif_t* ret; + local_irq_save(flags); + i = get_tpmif_index(domid, handle); + if (i < 0) { + ret = NULL; + } else { + ret = gtpmdev.tpmlist[i]; + } + local_irq_restore(flags); + return ret; +} + +/* Remove the given tpmif. Returns 0 if it was removed, -1 if it was not removed */ +int remove_tpmif(tpmif_t* tpmif) +{ + int i, j; + char* err; + int flags; + local_irq_save(flags); + + /* Find the index in the array if it exists */ + i = get_tpmif_index(tpmif->domid, tpmif->handle); + if (i < 0) { + goto error; + } + + /* Remove the interface from the list */ + for(j = i; j < gtpmdev.num_tpms - 1; ++j) { + gtpmdev.tpmlist[j] = gtpmdev.tpmlist[j+1]; + } + gtpmdev.tpmlist[j] = NULL; + --gtpmdev.num_tpms; + + /* If removed tpm was the only ready tpm, then we need to check and turn off the ready flag */ + tpmdev_check_req(); + + local_irq_restore(flags); + + /* Stop listening for events on this tpm interface */ + if((err = xenbus_unwatch_path_token(XBT_NIL, tpmif->fe_state_path, tpmif->fe_state_path))) { + TPMBACK_ERR("Unable to unwatch path token `%s' Error was %s Ignoring..\n", tpmif->fe_state_path, err); + free(err); + } + + return 0; +error: + local_irq_restore(flags); + return -1; +} + +/* Insert tpmif into dev->tpmlist. Returns 0 on success and non zero on error. + * It is an error to insert a tpmif with the same domid and handle + * number + * as something already in the list */ +int insert_tpmif(tpmif_t* tpmif) +{ + int flags; + unsigned int i, j; + tpmif_t* tmp; + char* err; + + local_irq_save(flags); + + /*Check if we need to allocate more space */ + if (gtpmdev.num_tpms == gtpmdev.num_alloc) { + gtpmdev.num_alloc *= 2; + gtpmdev.tpmlist = realloc(gtpmdev.tpmlist, gtpmdev.num_alloc); + } + + /*Find where to put the new interface */ + for(i = 0; i < gtpmdev.num_tpms; ++i) + { + tmp = gtpmdev.tpmlist[i]; + if(tpmif->domid == tmp->domid && tpmif->handle == tmp->handle) { + TPMBACK_ERR("Tried to insert duplicate tpm interface %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle); + goto error; + } + if((tpmif->domid < tmp->domid) || + (tpmif->domid == tmp->domid && tpmif->handle < tmp->handle)) { + break; + } + } + + /*Shift all the tpm pointers past i down one */ + for(j = gtpmdev.num_tpms; j > i; --j) { + gtpmdev.tpmlist[j] = gtpmdev.tpmlist[j-1]; + } + + /*Add the new interface */ + gtpmdev.tpmlist[i] = tpmif; + ++gtpmdev.num_tpms; + + /*Should not be needed, anything inserted with ready flag is probably an error */ + tpmdev_check_req(); + + local_irq_restore(flags); + + /*Listen for state changes on the new interface */ + if((err = xenbus_watch_path_token(XBT_NIL, tpmif->fe_state_path, tpmif->fe_state_path, >pmdev.events))) + { + /* if we got an error here we should carefully remove the interface and then return */ + TPMBACK_ERR("Unable to watch path token `%s' Error was %s\n", tpmif->fe_state_path, err); + free(err); + remove_tpmif(tpmif); + goto error_post_irq; + } + + return 0; +error: + local_irq_restore(flags); +error_post_irq: + return -1; +} + + +/***************** + * CHANGE BACKEND STATE + * *****************/ +/*Attempts to change the backend state in xenstore + * returns 0 on success and non-zero on error */ +int tpmif_change_state(tpmif_t* tpmif, enum xenbus_state state) +{ + char path[512]; + char *value; + char *err; + enum xenbus_state readst; + TPMBACK_DEBUG("Backend state change %u/%u from=%d to=%d\n", (unsigned int) tpmif->domid, tpmif->handle, tpmif->state, state); + if (tpmif->state == state) + return 0; + + snprintf(path, 512, "backend/vtpm/%u/%u/state", (unsigned int) tpmif->domid, tpmif->handle); + + if((err = xenbus_read(XBT_NIL, path, &value))) { + TPMBACK_ERR("Unable to read backend state %s, error was %s\n", path, err); + free(err); + return -1; + } + if(sscanf(value, "%d", &readst) != 1) { + TPMBACK_ERR("Non integer value (%s) in %s ??\n", value, path); + free(value); + return -1; + } + free(value); + + /* It's possible that the backend state got updated by hotplug or something else behind our back */ + if(readst != tpmif->state) { + TPMBACK_DEBUG("tpm interface state was %d but xenstore state was %d!\n", tpmif->state, readst); + tpmif->state = readst; + } + + /*If if the state isnt changing, then we dont update xenstore b/c we dont want to fire extraneous events */ + if(tpmif->state == state) { + return 0; + } + + /*update xenstore*/ + snprintf(path, 512, "backend/vtpm/%u/%u", (unsigned int) tpmif->domid, tpmif->handle); + if((err = xenbus_printf(XBT_NIL, path, "state", "%u", state))) { + TPMBACK_ERR("Error writing to xenstore %s, error was %s new state=%d\n", path, err, state); + free(err); + return -1; + } + + tpmif->state = state; + + return 0; +} +/********************************** + * TPMIF CREATION AND DELETION + * *******************************/ +inline tpmif_t* __init_tpmif(domid_t domid, unsigned int handle) +{ + tpmif_t* tpmif; + tpmif = malloc(sizeof(*tpmif)); + tpmif->domid = domid; + tpmif->handle = handle; + tpmif->fe_path = NULL; + tpmif->fe_state_path = NULL; + tpmif->state = XenbusStateInitialising; + tpmif->status = DISCONNECTED; + tpmif->tx = NULL; + tpmif->pages = NULL; + tpmif->flags = 0; + tpmif->uuid = NULL; + return tpmif; +} + +void __free_tpmif(tpmif_t* tpmif) +{ + if(tpmif->pages) { + free(tpmif->pages); + } + if(tpmif->fe_path) { + free(tpmif->fe_path); + } + if(tpmif->fe_state_path) { + free(tpmif->fe_state_path); + } + if(tpmif->uuid) { + free(tpmif->uuid); + } + free(tpmif); +} +/* Creates a new tpm interface, adds it to the sorted array and returns it. + * returns NULL on error + * If the tpm interface already exists, it is returned*/ +tpmif_t* new_tpmif(domid_t domid, unsigned int handle) +{ + tpmif_t* tpmif; + char* err; + char path[512]; + + /* Make sure we haven't already created this tpm + * Double events can occur */ + if((tpmif = get_tpmif(domid, handle)) != NULL) { + return tpmif; + } + + tpmif = __init_tpmif(domid, handle); + + /* Get the uuid from xenstore */ + snprintf(path, 512, "backend/vtpm/%u/%u/uuid", (unsigned int) domid, handle); + if((err = xenbus_read(XBT_NIL, path, &tpmif->uuid))) { + TPMBACK_ERR("Error reading %s, Error = %s\n", path, err); + free(err); + goto error; + } + + /* Do the exclusive uuid check now */ + if(gtpmdev.exclusive_uuids != NULL) { + char** ptr; + + /* Check that its in the whitelist */ + for(ptr = gtpmdev.exclusive_uuids; *ptr != NULL; ++ptr) { + if(!strcmp(tpmif->uuid, *ptr)) { + break; + } + } + /* If *ptr == NULL then we went through the whole list without a match, so close the connection */ + if(*ptr == NULL) { + tpmif_change_state(tpmif, XenbusStateClosed); + TPMBACK_ERR("Frontend %u/%u tried to connect with invalid uuid=%s\n", (unsigned int) domid, handle, tpmif->uuid); + goto error; + } + } + + /* allocate pages to be used for shared mapping */ + if((tpmif->pages = malloc(sizeof(void*) * TPMIF_TX_RING_SIZE)) == NULL) { + goto error; + } + memset(tpmif->pages, 0, sizeof(void*) * TPMIF_TX_RING_SIZE); + + if(tpmif_change_state(tpmif, XenbusStateInitWait)) { + goto error; + } + + snprintf(path, 512, "backend/vtpm/%u/%u/frontend", (unsigned int) domid, handle); + if((err = xenbus_read(XBT_NIL, path, &tpmif->fe_path))) { + TPMBACK_ERR("Error creating new tpm instance xenbus_read(%s), Error = %s", path, err); + free(err); + goto error; + } + + /*Set the state path */ + tpmif->fe_state_path = malloc(strlen(tpmif->fe_path) + 7); + strcpy(tpmif->fe_state_path, tpmif->fe_path); + strcat(tpmif->fe_state_path, "/state"); + + if(insert_tpmif(tpmif)) { + goto error; + } + TPMBACK_DEBUG("New tpmif %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle); + /* Do the callback now */ + if(gtpmdev.open_callback) { + gtpmdev.open_callback(tpmif->domid, tpmif->handle); + } + return tpmif; +error: + __free_tpmif(tpmif); + return NULL; + +} + +/* Removes tpmif from dev->tpmlist and frees it's memory usage */ +void free_tpmif(tpmif_t* tpmif) +{ + char* err; + char path[512]; + TPMBACK_DEBUG("Free tpmif %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle); + if(tpmif->flags & TPMIF_CLOSED) { + TPMBACK_ERR("Tried to free an instance twice! Theres a bug somewhere!\n"); + BUG(); + } + tpmif->flags = TPMIF_CLOSED; + + tpmif_change_state(tpmif, XenbusStateClosing); + + /* Unmap share page and unbind event channel */ + if(tpmif->status == CONNECTED) { + tpmif->status = DISCONNECTING; + mask_evtchn(tpmif->evtchn); + + if(gntmap_munmap(>pmdev.map, (unsigned long)tpmif->tx, 1)) { + TPMBACK_ERR("%u/%u Error occured while trying to unmap shared page\n", (unsigned int) tpmif->domid, tpmif->handle); + } + + unbind_evtchn(tpmif->evtchn); + } + tpmif->status = DISCONNECTED; + tpmif_change_state(tpmif, XenbusStateClosed); + + /* Do the callback now */ + if(gtpmdev.close_callback) { + gtpmdev.close_callback(tpmif->domid, tpmif->handle); + } + + /* remove from array */ + remove_tpmif(tpmif); + + /* Wake up anyone possibly waiting on this interface and let them exit */ + wake_up(&waitq); + schedule(); + + /* Remove the old xenbus entries */ + snprintf(path, 512, "backend/vtpm/%u/%u", (unsigned int) tpmif->domid, tpmif->handle); + if((err = xenbus_rm(XBT_NIL, path))) { + TPMBACK_ERR("Error cleaning up xenbus entries path=%s error=%s\n", path, err); + free(err); + } + + TPMBACK_LOG("Frontend %u/%u disconnected\n", (unsigned int) tpmif->domid, tpmif->handle); + + /* free memory */ + __free_tpmif(tpmif); + +} + +/********************** + * REMAINING TPMBACK FUNCTIONS + * ********************/ + +/*Event channel handler */ +void tpmback_handler(evtchn_port_t port, struct pt_regs *regs, void *data) +{ + tpmif_t* tpmif = (tpmif_t*) data; + tpmif_tx_request_t* tx = &tpmif->tx->ring[0].req; + /* Throw away 0 size events, these can trigger from event channel unmasking */ + if(tx->size == 0) + return; + + TPMBACK_DEBUG("EVENT CHANNEL FIRE %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle); + tpmif_req_ready(tpmif); + wake_up(&waitq); + +} + +/* Connect to frontend */ +int connect_fe(tpmif_t* tpmif) +{ + char path[512]; + char* err, *value; + uint32_t domid; + grant_ref_t ringref; + evtchn_port_t evtchn; + + /* If already connected then quit */ + if (tpmif->status == CONNECTED) { + TPMBACK_DEBUG("%u/%u tried to connect while it was already connected?\n", (unsigned int) tpmif->domid, tpmif->handle); + return 0; + } + + /* Fetch the grant reference */ + snprintf(path, 512, "%s/ring-ref", tpmif->fe_path); + if((err = xenbus_read(XBT_NIL, path, &value))) { + TPMBACK_ERR("Error creating new tpm instance xenbus_read(%s) Error = %s", path, err); + free(err); + return -1; + } + if(sscanf(value, "%d", &ringref) != 1) { + TPMBACK_ERR("Non integer value (%s) in %s ??\n", value, path); + free(value); + return -1; + } + free(value); + + + /* Fetch the event channel*/ + snprintf(path, 512, "%s/event-channel", tpmif->fe_path); + if((err = xenbus_read(XBT_NIL, path, &value))) { + TPMBACK_ERR("Error creating new tpm instance xenbus_read(%s) Error = %s", path, err); + free(err); + return -1; + } + if(sscanf(value, "%d", &evtchn) != 1) { + TPMBACK_ERR("Non integer value (%s) in %s ??\n", value, path); + free(value); + return -1; + } + free(value); + + domid = tpmif->domid; + if((tpmif->tx = gntmap_map_grant_refs(>pmdev.map, 1, &domid, 0, &ringref, PROT_READ | PROT_WRITE)) == NULL) { + TPMBACK_ERR("Failed to map grant reference %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle); + return -1; + } + memset(tpmif->tx, 0, PAGE_SIZE); + + /*Bind the event channel */ + if((evtchn_bind_interdomain(tpmif->domid, evtchn, tpmback_handler, tpmif, &tpmif->evtchn))) + { + TPMBACK_ERR("%u/%u Unable to bind to interdomain event channel!\n", (unsigned int) tpmif->domid, tpmif->handle); + goto error_post_map; + } + unmask_evtchn(tpmif->evtchn); + + /* Write the ready flag and change status to connected */ + snprintf(path, 512, "backend/vtpm/%u/%u", (unsigned int) tpmif->domid, tpmif->handle); + if((err = xenbus_printf(XBT_NIL, path, "ready", "%u", 1))) { + TPMBACK_ERR("%u/%u Unable to write ready flag on connect_fe()\n", (unsigned int) tpmif->domid, tpmif->handle); + free(err); + goto error_post_evtchn; + } + tpmif->status = CONNECTED; + if((tpmif_change_state(tpmif, XenbusStateConnected))){ + goto error_post_evtchn; + } + + TPMBACK_LOG("Frontend %u/%u connected\n", (unsigned int) tpmif->domid, tpmif->handle); + + return 0; +error_post_evtchn: + mask_evtchn(tpmif->evtchn); + unbind_evtchn(tpmif->evtchn); +error_post_map: + gntmap_munmap(>pmdev.map, (unsigned long)tpmif->tx, 1); + return -1; +} + +static int frontend_changed(tpmif_t* tpmif) +{ + int state = xenbus_read_integer(tpmif->fe_state_path); + if(state < 0) { + state = XenbusStateUnknown; + } + + TPMBACK_DEBUG("Frontend %u/%u state changed to %d\n", (unsigned int) tpmif->domid, tpmif->handle, state); + + switch (state) { + case XenbusStateInitialising: + case XenbusStateInitialised: + break; + + case XenbusStateConnected: + if(connect_fe(tpmif)) { + TPMBACK_ERR("Failed to connect to front end %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle); + tpmif_change_state(tpmif, XenbusStateClosed); + return -1; + } + break; + + case XenbusStateClosing: + tpmif_change_state(tpmif, XenbusStateClosing); + break; + + case XenbusStateUnknown: /* keep it here */ + case XenbusStateClosed: + free_tpmif(tpmif); + break; + + default: + TPMBACK_DEBUG("BAD STATE CHANGE %u/%u state = %d for tpmif\n", (unsigned int) tpmif->domid, tpmif->handle, state); + return -1; + } + return 0; +} + + +/* parses the string that comes out of xenbus_watch_wait_return. */ +static int parse_eventstr(const char* evstr, domid_t* domid, unsigned int* handle) +{ + int ret; + char cmd[40]; + char* err; + char* value; + unsigned int udomid = 0; + tpmif_t* tpmif; + /* First check for new frontends, this occurs when /backend/vtpm// gets created. Note we what the sscanf to fail on the last %s */ + if (sscanf(evstr, "backend/vtpm/%u/%u/%40s", &udomid, handle, cmd) == 2) { + *domid = udomid; + /* Make sure the entry exists, if this event triggers because the entry dissapeared then ignore it */ + if((err = xenbus_read(XBT_NIL, evstr, &value))) { + free(err); + return EV_NONE; + } + free(value); + /* Make sure the tpmif entry does not already exist, this should not happen */ + if((tpmif = get_tpmif(*domid, *handle)) != NULL) { + TPMBACK_DEBUG("Duplicate tpm entries! %u %u\n", tpmif->domid, tpmif->handle); + return EV_NONE; + } + return EV_NEWFE; + } else if((ret = sscanf(evstr, "/local/domain/%u/device/vtpm/%u/%40s", &udomid, handle, cmd)) == 3) { + *domid = udomid; + if (!strcmp(cmd, "state")) + return EV_STCHNG; + } + return EV_NONE; +} + +void handle_backend_event(char* evstr) { + tpmif_t* tpmif; + domid_t domid; + unsigned int handle; + int event; + + TPMBACK_DEBUG("Xenbus Event: %s\n", evstr); + + event = parse_eventstr(evstr, &domid, &handle); + + switch(event) { + case EV_NEWFE: + if(new_tpmif(domid, handle) == NULL) { + TPMBACK_ERR("Failed to create new tpm instance %u/%u\n", (unsigned int) domid, handle); + } + wake_up(&waitq); + break; + case EV_STCHNG: + if((tpmif = get_tpmif(domid, handle))) { + frontend_changed(tpmif); + } else { + TPMBACK_DEBUG("Event Received for non-existant tpm! instance=%u/%u xenbus_event=%s\n", (unsigned int) domid, handle, evstr); + } + break; + } +} + +/* Runs through the given path and creates events recursively + * for all of its children. + * @path - xenstore path to scan */ +static void generate_backend_events(const char* path) +{ + char* err; + int i, len; + char **dirs; + char *entry; + + if((err = xenbus_ls(XBT_NIL, path, &dirs)) != NULL) { + free(err); + return; + } + + for(i = 0; dirs[i] != NULL; ++i) { + len = strlen(path) + strlen(dirs[i]) + 2; + entry = malloc(len); + snprintf(entry, len, "%s/%s", path, dirs[i]); + + /* Generate and handle event for the entry itself */ + handle_backend_event(entry); + + /* Do children */ + generate_backend_events(entry); + + /* Cleanup */ + free(entry); + free(dirs[i]); + } + free(dirs); + return; +} + +char* tpmback_get_uuid(domid_t domid, unsigned int handle) +{ + tpmif_t* tpmif; + if((tpmif = get_tpmif(domid, handle)) == NULL) { + TPMBACK_DEBUG("get_uuid() failed, %u/%u is an invalid frontend\n", (unsigned int) domid, handle); + return NULL; + } + + return tpmif->uuid; +} + +void tpmback_set_open_callback(void (*cb)(domid_t, unsigned int)) +{ + gtpmdev.open_callback = cb; +} +void tpmback_set_close_callback(void (*cb)(domid_t, unsigned int)) +{ + gtpmdev.close_callback = cb; +} +void tpmback_set_suspend_callback(void (*cb)(domid_t, unsigned int)) +{ + gtpmdev.suspend_callback = cb; +} +void tpmback_set_resume_callback(void (*cb)(domid_t, unsigned int)) +{ + gtpmdev.resume_callback = cb; +} + +static void event_listener(void) +{ + const char* bepath = "backend/vtpm"; + char **path; + char* err; + + /* Setup the backend device watch */ + if((err = xenbus_watch_path_token(XBT_NIL, bepath, bepath, >pmdev.events)) != NULL) { + TPMBACK_ERR("xenbus_watch_path_token(%s) failed with error %s!\n", bepath, err); + free(err); + goto egress; + } + + /* Check for any frontends that connected before we set the watch. + * This is almost guaranteed to happen if both domains are started + * immediatly one after the other. + * We do this by manually generating events on everything in the backend + * path */ + generate_backend_events(bepath); + + /* Wait and listen for changes in frontend connections */ + while(1) { + path = xenbus_wait_for_watch_return(>pmdev.events); + + /*If quit flag was set then exit */ + if(gtpmdev.flags & TPMIF_CLOSED) { + TPMBACK_DEBUG("listener thread got quit event. Exiting..\n"); + free(path); + break; + } + handle_backend_event(*path); + free(path); + + } + + if((err = xenbus_unwatch_path_token(XBT_NIL, bepath, bepath)) != NULL) { + free(err); + } +egress: + return; +} + +void event_thread(void* p) { + event_listener(); +} + +void init_tpmback(char** exclusive_uuids) +{ + if(!globalinit) { + init_waitqueue_head(&waitq); + globalinit = 1; + } + printk("============= Init TPM BACK ================\n"); + gtpmdev.tpmlist = malloc(sizeof(tpmif_t*) * DEF_ARRAY_SIZE); + gtpmdev.num_alloc = DEF_ARRAY_SIZE; + gtpmdev.num_tpms = 0; + gtpmdev.flags = 0; + gtpmdev.exclusive_uuids = exclusive_uuids; + + gtpmdev.open_callback = gtpmdev.close_callback = NULL; + gtpmdev.suspend_callback = gtpmdev.resume_callback = NULL; + + eventthread = create_thread("tpmback-listener", event_thread, NULL); + +} + +void shutdown_tpmback(void) +{ + /* Disable callbacks */ + gtpmdev.open_callback = gtpmdev.close_callback = NULL; + gtpmdev.suspend_callback = gtpmdev.resume_callback = NULL; + + TPMBACK_LOG("Shutting down tpm backend\n"); + /* Set the quit flag */ + gtpmdev.flags = TPMIF_CLOSED; + + //printk("num tpms is %d\n", gtpmdev.num_tpms); + /*Free all backend instances */ + while(gtpmdev.num_tpms) { + free_tpmif(gtpmdev.tpmlist[0]); + } + free(gtpmdev.tpmlist); + gtpmdev.tpmlist = NULL; + gtpmdev.num_alloc = 0; + + /* Wake up anyone possibly waiting on the device and let them exit */ + wake_up(&waitq); + schedule(); +} + +inline void init_tpmcmd(tpmcmd_t* tpmcmd, domid_t domid, unsigned int handle, char* uuid) +{ + tpmcmd->domid = domid; + tpmcmd->handle = handle; + tpmcmd->uuid = uuid; + tpmcmd->req = NULL; + tpmcmd->req_len = 0; + tpmcmd->resp = NULL; + tpmcmd->resp_len = 0; +} + +tpmcmd_t* get_request(tpmif_t* tpmif) { + tpmcmd_t* cmd; + tpmif_tx_request_t* tx; + int offset; + int tocopy; + int i; + uint32_t domid; + int flags; + + local_irq_save(flags); + + /* Allocate the cmd object to hold the data */ + if((cmd = malloc(sizeof(*cmd))) == NULL) { + goto error; + } + init_tpmcmd(cmd, tpmif->domid, tpmif->handle, tpmif->uuid); + + tx = &tpmif->tx->ring[0].req; + cmd->req_len = tx->size; + /* Allocate the buffer */ + if(cmd->req_len) { + if((cmd->req = malloc(cmd->req_len)) == NULL) { + goto error; + } + } + /* Copy the bits from the shared pages */ + offset = 0; + for(i = 0; i < TPMIF_TX_RING_SIZE && offset < cmd->req_len; ++i) { + tx = &tpmif->tx->ring[i].req; + + /* Map the page with the data */ + domid = (uint32_t)tpmif->domid; + if((tpmif->pages[i] = gntmap_map_grant_refs(>pmdev.map, 1, &domid, 0, &tx->ref, PROT_READ)) == NULL) { + TPMBACK_ERR("%u/%u Unable to map shared page during read!\n", (unsigned int) tpmif->domid, tpmif->handle); + goto error; + } + + /* do the copy now */ + tocopy = min(cmd->req_len - offset, PAGE_SIZE); + memcpy(&cmd->req[offset], tpmif->pages[i], tocopy); + offset += tocopy; + + /* release the page */ + gntmap_munmap(>pmdev.map, (unsigned long)tpmif->pages[i], 1); + + } + +#ifdef TPMBACK_PRINT_DEBUG + TPMBACK_DEBUG("Received Tpm Command from %u/%u of size %u", (unsigned int) tpmif->domid, tpmif->handle, cmd->req_len); + for(i = 0; i < cmd->req_len; ++i) { + if (!(i % 30)) { + TPMBACK_DEBUG_MORE("\n"); + } + TPMBACK_DEBUG_MORE("%02hhX ", cmd->req[i]); + } + TPMBACK_DEBUG_MORE("\n\n"); +#endif + + local_irq_restore(flags); + return cmd; +error: + if(cmd != NULL) { + if (cmd->req != NULL) { + free(cmd->req); + cmd->req = NULL; + } + free(cmd); + cmd = NULL; + } + local_irq_restore(flags); + return NULL; + +} + +void send_response(tpmcmd_t* cmd, tpmif_t* tpmif) +{ + tpmif_tx_request_t* tx; + int offset; + int i; + uint32_t domid; + int tocopy; + int flags; + + local_irq_save(flags); + + tx = &tpmif->tx->ring[0].req; + tx->size = cmd->resp_len; + + offset = 0; + for(i = 0; i < TPMIF_TX_RING_SIZE && offset < cmd->resp_len; ++i) { + tx = &tpmif->tx->ring[i].req; + + /* Map the page with the data */ + domid = (uint32_t)tpmif->domid; + if((tpmif->pages[i] = gntmap_map_grant_refs(>pmdev.map, 1, &domid, 0, &tx->ref, PROT_WRITE)) == NULL) { + TPMBACK_ERR("%u/%u Unable to map shared page during write!\n", (unsigned int) tpmif->domid, tpmif->handle); + goto error; + } + + /* do the copy now */ + tocopy = min(cmd->resp_len - offset, PAGE_SIZE); + memcpy(tpmif->pages[i], &cmd->resp[offset], tocopy); + offset += tocopy; + + /* release the page */ + gntmap_munmap(>pmdev.map, (unsigned long)tpmif->pages[i], 1); + + } + +#ifdef TPMBACK_PRINT_DEBUG + TPMBACK_DEBUG("Sent response to %u/%u of size %u", (unsigned int) tpmif->domid, tpmif->handle, cmd->resp_len); + for(i = 0; i < cmd->resp_len; ++i) { + if (!(i % 30)) { + TPMBACK_DEBUG_MORE("\n"); + } + TPMBACK_DEBUG_MORE("%02hhX ", cmd->resp[i]); + } + TPMBACK_DEBUG_MORE("\n\n"); +#endif + /* clear the ready flag and send the event channel notice to the frontend */ + tpmif_req_finished(tpmif); + notify_remote_via_evtchn(tpmif->evtchn); +error: + local_irq_restore(flags); + return; +} + +tpmcmd_t* tpmback_req_any(void) +{ + int i; + /* Block until something has a request */ + wait_event(waitq, (gtpmdev.flags & (TPMIF_REQ_READY | TPMIF_CLOSED))); + + /* Check if were shutting down */ + if(gtpmdev.flags & TPMIF_CLOSED) { + /* if something was waiting for us to give up the queue so it can shutdown, let it finish */ + schedule(); + return NULL; + } + + for(i = 0; i < gtpmdev.num_tpms; ++i) { + if(gtpmdev.tpmlist[i]->flags & TPMIF_REQ_READY) { + return get_request(gtpmdev.tpmlist[i]); + } + } + + TPMBACK_ERR("backend request ready flag was set but no interfaces were actually ready\n"); + return NULL; +} + +tpmcmd_t* tpmback_req(domid_t domid, unsigned int handle) +{ + tpmif_t* tpmif; + tpmif = get_tpmif(domid, handle); + if(tpmif == NULL) { + return NULL; + } + + wait_event(waitq, (tpmif->flags & (TPMIF_REQ_READY | TPMIF_CLOSED) || gtpmdev.flags & TPMIF_CLOSED)); + + /* Check if were shutting down */ + if(tpmif->flags & TPMIF_CLOSED || gtpmdev.flags & TPMIF_CLOSED) { + /* if something was waiting for us to give up the queue so it can free this instance, let it finish */ + schedule(); + return NULL; + } + + return get_request(tpmif); +} + +void tpmback_resp(tpmcmd_t* tpmcmd) +{ + tpmif_t* tpmif; + + /* Get the associated interface, if it doesnt exist then just quit */ + tpmif = get_tpmif(tpmcmd->domid, tpmcmd->handle); + if(tpmif == NULL) { + TPMBACK_ERR("Tried to send a reponse to non existant frontend %u/%u\n", (unsigned int) tpmcmd->domid, tpmcmd->handle); + goto end; + } + + if(!(tpmif->flags & TPMIF_REQ_READY)) { + TPMBACK_ERR("Tried to send response to a frontend that was not waiting for one %u/%u\n", (unsigned int) tpmcmd->domid, tpmcmd->handle); + goto end; + } + + /* Send response to frontend */ + send_response(tpmcmd, tpmif); + +end: + if(tpmcmd->req != NULL) { + free(tpmcmd->req); + } + free(tpmcmd); + return; +} + +int tpmback_wait_for_frontend_connect(domid_t *domid, unsigned int *handle) +{ + tpmif_t* tpmif; + int flags; + wait_event(waitq, ((gtpmdev.num_tpms > 0) || gtpmdev.flags & TPMIF_CLOSED)); + if(gtpmdev.flags & TPMIF_CLOSED) { + return -1; + } + local_irq_save(flags); + tpmif = gtpmdev.tpmlist[0]; + *domid = tpmif->domid; + *handle = tpmif->handle; + local_irq_restore(flags); + + return 0; +} + +int tpmback_num_frontends(void) +{ + return gtpmdev.num_tpms; +} diff --git a/extras/mini-os/tpmfront.c b/extras/mini-os/tpmfront.c new file mode 100644 index 0000000..3f532d7 --- /dev/null +++ b/extras/mini-os/tpmfront.c @@ -0,0 +1,607 @@ +/* + * Copyright (c) 2010-2012 United States Government, as represented by + * the Secretary of Defense. All rights reserved. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation, version 2 + * of the License + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + * + * Based upon the files: + * drivers/char/tpm/tpm_vtpm.c + * drivers/char/tpm/tpm_xen.c + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +//#define TPMFRONT_PRINT_DEBUG +#ifdef TPMFRONT_PRINT_DEBUG +#define TPMFRONT_DEBUG(fmt,...) printk("Tpmfront:Debug("__FILE__":%d) " fmt, __LINE__, ##__VA_ARGS__) +#define TPMFRONT_DEBUG_MORE(fmt,...) printk(fmt, ##__VA_ARGS__) +#else +#define TPMFRONT_DEBUG(fmt,...) +#endif +#define TPMFRONT_ERR(fmt,...) printk("Tpmfront:Error " fmt, ##__VA_ARGS__) +#define TPMFRONT_LOG(fmt,...) printk("Tpmfront:Info " fmt, ##__VA_ARGS__) + +#define min(a,b) (((a) < (b)) ? (a) : (b)) + +void tpmfront_handler(evtchn_port_t port, struct pt_regs *regs, void *data) { + struct tpmfront_dev* dev = (struct tpmfront_dev*) data; + /*If we get a response when we didnt make a request, just ignore it */ + if(!dev->waiting) { + return; + } + + dev->waiting = 0; +#ifdef HAVE_LIBC + if(dev->fd >= 0) { + files[dev->fd].read = 1; + } +#endif + wake_up(&dev->waitq); +} + +static int publish_xenbus(struct tpmfront_dev* dev) { + xenbus_transaction_t xbt; + int retry; + char* err; + /* Write the grant reference and event channel to xenstore */ +again: + if((err = xenbus_transaction_start(&xbt))) { + TPMFRONT_ERR("Unable to start xenbus transaction, error was %s\n", err); + free(err); + return -1; + } + + if((err = xenbus_printf(xbt, dev->nodename, "ring-ref", "%u", (unsigned int) dev->ring_ref))) { + TPMFRONT_ERR("Unable to write %s/ring-ref, error was %s\n", dev->nodename, err); + free(err); + goto abort_transaction; + } + + if((err = xenbus_printf(xbt, dev->nodename, "event-channel", "%u", (unsigned int) dev->evtchn))) { + TPMFRONT_ERR("Unable to write %s/event-channel, error was %s\n", dev->nodename, err); + free(err); + goto abort_transaction; + } + + if((err = xenbus_transaction_end(xbt, 0, &retry))) { + TPMFRONT_ERR("Unable to complete xenbus transaction, error was %s\n", err); + free(err); + return -1; + } + if(retry) { + goto again; + } + + return 0; +abort_transaction: + if((err = xenbus_transaction_end(xbt, 1, &retry))) { + free(err); + } + return -1; +} + +static int wait_for_backend_connect(xenbus_event_queue* events, char* path) +{ + int state; + + TPMFRONT_LOG("Waiting for backend connection..\n"); + /* Wait for the backend to connect */ + while(1) { + state = xenbus_read_integer(path); + if ( state < 0) + state = XenbusStateUnknown; + switch(state) { + /* Bad states, we quit with error */ + case XenbusStateUnknown: + case XenbusStateClosing: + case XenbusStateClosed: + TPMFRONT_ERR("Unable to connect to backend\n"); + return -1; + /* If backend is connected then break out of loop */ + case XenbusStateConnected: + TPMFRONT_LOG("Backend Connected\n"); + return 0; + default: + xenbus_wait_for_watch(events); + } + } + +} + +static int wait_for_backend_closed(xenbus_event_queue* events, char* path) +{ + int state; + + TPMFRONT_LOG("Waiting for backend to close..\n"); + while(1) { + state = xenbus_read_integer(path); + if ( state < 0) + state = XenbusStateUnknown; + switch(state) { + case XenbusStateUnknown: + TPMFRONT_ERR("Backend Unknown state, forcing shutdown\n"); + return -1; + case XenbusStateClosed: + TPMFRONT_LOG("Backend Closed\n"); + return 0; + default: + xenbus_wait_for_watch(events); + } + } + +} + +static int wait_for_backend_state_changed(struct tpmfront_dev* dev, XenbusState state) { + char* err; + int ret = 0; + xenbus_event_queue events = NULL; + char path[512]; + + snprintf(path, 512, "%s/state", dev->bepath); + /*Setup the watch to wait for the backend */ + if((err = xenbus_watch_path_token(XBT_NIL, path, path, &events))) { + TPMFRONT_ERR("Could not set a watch on %s, error was %s\n", path, err); + free(err); + return -1; + } + + /* Do the actual wait loop now */ + switch(state) { + case XenbusStateConnected: + ret = wait_for_backend_connect(&events, path); + break; + case XenbusStateClosed: + ret = wait_for_backend_closed(&events, path); + break; + default: + break; + } + + if((err = xenbus_unwatch_path_token(XBT_NIL, path, path))) { + TPMFRONT_ERR("Unable to unwatch %s, error was %s, ignoring..\n", path, err); + free(err); + } + return ret; +} + +static int tpmfront_connect(struct tpmfront_dev* dev) +{ + char* err; + /* Create shared page */ + dev->tx = (tpmif_tx_interface_t*) alloc_page(); + if(dev->tx == NULL) { + TPMFRONT_ERR("Unable to allocate page for shared memory\n"); + goto error; + } + memset(dev->tx, 0, PAGE_SIZE); + dev->ring_ref = gnttab_grant_access(dev->bedomid, virt_to_mfn(dev->tx), 0); + TPMFRONT_DEBUG("grant ref is %lu\n", (unsigned long) dev->ring_ref); + + /*Create event channel */ + if(evtchn_alloc_unbound(dev->bedomid, tpmfront_handler, dev, &dev->evtchn)) { + TPMFRONT_ERR("Unable to allocate event channel\n"); + goto error_postmap; + } + unmask_evtchn(dev->evtchn); + TPMFRONT_DEBUG("event channel is %lu\n", (unsigned long) dev->evtchn); + + /* Write the entries to xenstore */ + if(publish_xenbus(dev)) { + goto error_postevtchn; + } + + /* Change state to connected */ + dev->state = XenbusStateConnected; + + /* Tell the backend that we are ready */ + if((err = xenbus_printf(XBT_NIL, dev->nodename, "state", "%u", dev->state))) { + TPMFRONT_ERR("Unable to write to xenstore %s/state, value=%u", dev->nodename, XenbusStateConnected); + free(err); + goto error; + } + + return 0; +error_postevtchn: + mask_evtchn(dev->evtchn); + unbind_evtchn(dev->evtchn); +error_postmap: + gnttab_end_access(dev->ring_ref); + free_page(dev->tx); +error: + return -1; +} + +struct tpmfront_dev* init_tpmfront(const char* _nodename) +{ + struct tpmfront_dev* dev; + const char* nodename; + char path[512]; + char* value, *err; + unsigned long long ival; + int i; + + printk("============= Init TPM Front ================\n"); + + dev = malloc(sizeof(struct tpmfront_dev)); + memset(dev, 0, sizeof(struct tpmfront_dev)); + +#ifdef HAVE_LIBC + dev->fd = -1; +#endif + + nodename = _nodename ? _nodename : "device/vtpm/0"; + dev->nodename = strdup(nodename); + + init_waitqueue_head(&dev->waitq); + + /* Get backend domid */ + snprintf(path, 512, "%s/backend-id", dev->nodename); + if((err = xenbus_read(XBT_NIL, path, &value))) { + TPMFRONT_ERR("Unable to read %s during tpmfront initialization! error = %s\n", path, err); + free(err); + goto error; + } + if(sscanf(value, "%llu", &ival) != 1) { + TPMFRONT_ERR("%s has non-integer value (%s)\n", path, value); + free(value); + goto error; + } + free(value); + dev->bedomid = ival; + + /* Get backend xenstore path */ + snprintf(path, 512, "%s/backend", dev->nodename); + if((err = xenbus_read(XBT_NIL, path, &dev->bepath))) { + TPMFRONT_ERR("Unable to read %s during tpmfront initialization! error = %s\n", path, err); + free(err); + goto error; + } + + /* Create and publish grant reference and event channel */ + if (tpmfront_connect(dev)) { + goto error; + } + + /* Wait for backend to connect */ + if( wait_for_backend_state_changed(dev, XenbusStateConnected)) { + goto error; + } + + /* Allocate pages that will contain the messages */ + dev->pages = malloc(sizeof(void*) * TPMIF_TX_RING_SIZE); + if(dev->pages == NULL) { + goto error; + } + memset(dev->pages, 0, sizeof(void*) * TPMIF_TX_RING_SIZE); + for(i = 0; i < TPMIF_TX_RING_SIZE; ++i) { + dev->pages[i] = (void*)alloc_page(); + if(dev->pages[i] == NULL) { + goto error; + } + } + + TPMFRONT_LOG("Initialization Completed successfully\n"); + + return dev; + +error: + shutdown_tpmfront(dev); + return NULL; +} +void shutdown_tpmfront(struct tpmfront_dev* dev) +{ + char* err; + char path[512]; + int i; + tpmif_tx_request_t* tx; + if(dev == NULL) { + return; + } + TPMFRONT_LOG("Shutting down tpmfront\n"); + /* disconnect */ + if(dev->state == XenbusStateConnected) { + dev->state = XenbusStateClosing; + //FIXME: Transaction for this? + /* Tell backend we are closing */ + if((err = xenbus_printf(XBT_NIL, dev->nodename, "state", "%u", (unsigned int) dev->state))) { + free(err); + } + + /* Clean up xenstore entries */ + snprintf(path, 512, "%s/event-channel", dev->nodename); + if((err = xenbus_rm(XBT_NIL, path))) { + free(err); + } + snprintf(path, 512, "%s/ring-ref", dev->nodename); + if((err = xenbus_rm(XBT_NIL, path))) { + free(err); + } + + /* Tell backend we are closed */ + dev->state = XenbusStateClosed; + if((err = xenbus_printf(XBT_NIL, dev->nodename, "state", "%u", (unsigned int) dev->state))) { + TPMFRONT_ERR("Unable to write to %s, error was %s", dev->nodename, err); + free(err); + } + + /* Wait for the backend to close and unmap shared pages, ignore any errors */ + wait_for_backend_state_changed(dev, XenbusStateClosed); + + /* Cleanup any shared pages */ + if(dev->pages) { + for(i = 0; i < TPMIF_TX_RING_SIZE; ++i) { + if(dev->pages[i]) { + tx = &dev->tx->ring[i].req; + if(tx->ref != 0) { + gnttab_end_access(tx->ref); + } + free_page(dev->pages[i]); + } + } + free(dev->pages); + } + + /* Close event channel and unmap shared page */ + mask_evtchn(dev->evtchn); + unbind_evtchn(dev->evtchn); + gnttab_end_access(dev->ring_ref); + + free_page(dev->tx); + + } + + /* Cleanup memory usage */ + if(dev->respbuf) { + free(dev->respbuf); + } + if(dev->bepath) { + free(dev->bepath); + } + if(dev->nodename) { + free(dev->nodename); + } + free(dev); +} + +int tpmfront_send(struct tpmfront_dev* dev, const uint8_t* msg, size_t length) +{ + int i; + tpmif_tx_request_t* tx = NULL; + /* Error Checking */ + if(dev == NULL || dev->state != XenbusStateConnected) { + TPMFRONT_ERR("Tried to send message through disconnected frontend\n"); + return -1; + } + +#ifdef TPMFRONT_PRINT_DEBUG + TPMFRONT_DEBUG("Sending Msg to backend size=%u", (unsigned int) length); + for(i = 0; i < length; ++i) { + if(!(i % 30)) { + TPMFRONT_DEBUG_MORE("\n"); + } + TPMFRONT_DEBUG_MORE("%02X ", msg[i]); + } + TPMFRONT_DEBUG_MORE("\n"); +#endif + + /* Copy to shared pages now */ + for(i = 0; length > 0 && i < TPMIF_TX_RING_SIZE; ++i) { + /* Share the page */ + tx = &dev->tx->ring[i].req; + tx->unused = 0; + tx->addr = virt_to_mach(dev->pages[i]); + tx->ref = gnttab_grant_access(dev->bedomid, virt_to_mfn(dev->pages[i]), 0); + /* Copy the bits to the page */ + tx->size = length > PAGE_SIZE ? PAGE_SIZE : length; + memcpy(dev->pages[i], &msg[i * PAGE_SIZE], tx->size); + + /* Update counters */ + length -= tx->size; + } + dev->waiting = 1; + dev->resplen = 0; +#ifdef HAVE_LIBC + if(dev->fd >= 0) { + files[dev->fd].read = 0; + files[dev->fd].tpmfront.respgot = 0; + files[dev->fd].tpmfront.offset = 0; + } +#endif + notify_remote_via_evtchn(dev->evtchn); + return 0; +} +int tpmfront_recv(struct tpmfront_dev* dev, uint8_t** msg, size_t *length) +{ + tpmif_tx_request_t* tx; + int i; + if(dev == NULL || dev->state != XenbusStateConnected) { + TPMFRONT_ERR("Tried to receive message from disconnected frontend\n"); + return -1; + } + /*Wait for the response */ + wait_event(dev->waitq, (!dev->waiting)); + + /* Initialize */ + *msg = NULL; + *length = 0; + + /* special case, just quit */ + tx = &dev->tx->ring[0].req; + if(tx->size == 0 ) { + goto quit; + } + /* Get the total size */ + tx = &dev->tx->ring[0].req; + for(i = 0; i < TPMIF_TX_RING_SIZE && tx->size > 0; ++i) { + tx = &dev->tx->ring[i].req; + *length += tx->size; + } + /* Alloc the buffer */ + if(dev->respbuf) { + free(dev->respbuf); + } + *msg = dev->respbuf = malloc(*length); + dev->resplen = *length; + /* Copy the bits */ + tx = &dev->tx->ring[0].req; + for(i = 0; i < TPMIF_TX_RING_SIZE && tx->size > 0; ++i) { + tx = &dev->tx->ring[i].req; + memcpy(&(*msg)[i * PAGE_SIZE], dev->pages[i], tx->size); + gnttab_end_access(tx->ref); + tx->ref = 0; + } +#ifdef TPMFRONT_PRINT_DEBUG + TPMFRONT_DEBUG("Received response from backend size=%u", (unsigned int) *length); + for(i = 0; i < *length; ++i) { + if(!(i % 30)) { + TPMFRONT_DEBUG_MORE("\n"); + } + TPMFRONT_DEBUG_MORE("%02X ", (*msg)[i]); + } + TPMFRONT_DEBUG_MORE("\n"); +#endif +#ifdef HAVE_LIBC + if(dev->fd >= 0) { + files[dev->fd].tpmfront.respgot = 1; + } +#endif +quit: + return 0; +} + +int tpmfront_cmd(struct tpmfront_dev* dev, uint8_t* req, size_t reqlen, uint8_t** resp, size_t* resplen) +{ + int rc; + if((rc = tpmfront_send(dev, req, reqlen))) { + return rc; + } + if((rc = tpmfront_recv(dev, resp, resplen))) { + return rc; + } + + return 0; +} + +#ifdef HAVE_LIBC +#include +int tpmfront_open(struct tpmfront_dev* dev) +{ + /* Silently prevent multiple opens */ + if(dev->fd != -1) { + return dev->fd; + } + + dev->fd = alloc_fd(FTYPE_TPMFRONT); + printk("tpmfront_open(%s) -> %d\n", dev->nodename, dev->fd); + files[dev->fd].tpmfront.dev = dev; + files[dev->fd].tpmfront.offset = 0; + files[dev->fd].tpmfront.respgot = 0; + return dev->fd; +} + +int tpmfront_posix_write(int fd, const uint8_t* buf, size_t count) +{ + int rc; + struct tpmfront_dev* dev; + dev = files[fd].tpmfront.dev; + + if(count == 0) { + return 0; + } + + /* Return an error if we are already processing a command */ + if(dev->waiting) { + errno = EINPROGRESS; + return -1; + } + /* Send the command now */ + if((rc = tpmfront_send(dev, buf, count)) != 0) { + errno = EIO; + return -1; + } + return count; +} + +int tpmfront_posix_read(int fd, uint8_t* buf, size_t count) +{ + int rc; + uint8_t* dummybuf; + size_t dummysz; + struct tpmfront_dev* dev; + + dev = files[fd].tpmfront.dev; + + if(count == 0) { + return 0; + } + + /* get the response if we haven't already */ + if(files[dev->fd].tpmfront.respgot == 0) { + if ((rc = tpmfront_recv(dev, &dummybuf, &dummysz)) != 0) { + errno = EIO; + return -1; + } + } + + /* handle EOF case */ + if(files[dev->fd].tpmfront.offset >= dev->resplen) { + return 0; + } + + /* Compute the number of bytes and do the copy operation */ + if((rc = min(count, dev->resplen - files[dev->fd].tpmfront.offset)) != 0) { + memcpy(buf, dev->respbuf + files[dev->fd].tpmfront.offset, rc); + files[dev->fd].tpmfront.offset += rc; + } + + return rc; +} + +int tpmfront_posix_fstat(int fd, struct stat* buf) +{ + uint8_t* dummybuf; + size_t dummysz; + int rc; + struct tpmfront_dev* dev = files[fd].tpmfront.dev; + + /* If we have a response waiting, then read it now from the backend + * so we can get its length*/ + if(dev->waiting || (files[dev->fd].read == 1 && !files[dev->fd].tpmfront.respgot)) { + if ((rc = tpmfront_recv(dev, &dummybuf, &dummysz)) != 0) { + errno = EIO; + return -1; + } + } + + buf->st_mode = O_RDWR; + buf->st_uid = 0; + buf->st_gid = 0; + buf->st_size = dev->resplen; + buf->st_atime = buf->st_mtime = buf->st_ctime = time(NULL); + + return 0; +} + + +#endif -- 1.7.4.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 16:21:11 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 16:21:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5DL-00061M-VE; Tue, 02 Oct 2012 16:20:55 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5DK-00060w-PH for xen-devel@lists.xen.org; Tue, 02 Oct 2012 16:20:54 +0000 Received: from [85.158.137.99:42853] by server-5.bemta-3.messagelabs.com id 36/DB-00589-5641B605; Tue, 02 Oct 2012 16:20:53 +0000 X-Env-Sender: avi@redhat.com X-Msg-Ref: server-15.tower-217.messagelabs.com!1349194852!17626745!1 X-Originating-IP: [209.132.183.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTY4NTA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9082 invoked from network); 2 Oct 2012 16:20:53 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-15.tower-217.messagelabs.com with SMTP; 2 Oct 2012 16:20:53 -0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q92GKlHv027154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Oct 2012 12:20:47 -0400 Received: from balrog.usersys.tlv.redhat.com (dhcp-4-121.tlv.redhat.com [10.35.4.121]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q92GKjG6021980; Tue, 2 Oct 2012 12:20:45 -0400 Message-ID: <506B145D.4030505@redhat.com> Date: Tue, 02 Oct 2012 18:20:45 +0200 From: Avi Kivity User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: Anthony PERARD References: <1348744360-2989-1-git-send-email-anthony.perard@citrix.com> <1348744360-2989-5-git-send-email-anthony.perard@citrix.com> <506AC11F.1030402@redhat.com> <506B134B.20006@citrix.com> In-Reply-To: <506B134B.20006@citrix.com> X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 Cc: Xen Devel , QEMU-devel , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH V4 4/5] exec, memory: Call to xen_modified_memory. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 10/02/2012 06:16 PM, Anthony PERARD wrote: > >> Possibly the first bit too? > > But the call from invalidate_and_set_dirty, I can not remove it because > it does not work. The xen function must be called without condition as > xen and qemu does not maintained the same dirtymap. Right, in fact we added invalidate_and_set_dirty() in order to stick the xen call in it, I just forgot about it. So the first bit is okay. -- error compiling committee.c: too many arguments to function _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 16:21:11 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 16:21:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5DL-00061M-VE; Tue, 02 Oct 2012 16:20:55 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5DK-00060w-PH for xen-devel@lists.xen.org; Tue, 02 Oct 2012 16:20:54 +0000 Received: from [85.158.137.99:42853] by server-5.bemta-3.messagelabs.com id 36/DB-00589-5641B605; Tue, 02 Oct 2012 16:20:53 +0000 X-Env-Sender: avi@redhat.com X-Msg-Ref: server-15.tower-217.messagelabs.com!1349194852!17626745!1 X-Originating-IP: [209.132.183.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTY4NTA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9082 invoked from network); 2 Oct 2012 16:20:53 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-15.tower-217.messagelabs.com with SMTP; 2 Oct 2012 16:20:53 -0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q92GKlHv027154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Oct 2012 12:20:47 -0400 Received: from balrog.usersys.tlv.redhat.com (dhcp-4-121.tlv.redhat.com [10.35.4.121]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q92GKjG6021980; Tue, 2 Oct 2012 12:20:45 -0400 Message-ID: <506B145D.4030505@redhat.com> Date: Tue, 02 Oct 2012 18:20:45 +0200 From: Avi Kivity User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: Anthony PERARD References: <1348744360-2989-1-git-send-email-anthony.perard@citrix.com> <1348744360-2989-5-git-send-email-anthony.perard@citrix.com> <506AC11F.1030402@redhat.com> <506B134B.20006@citrix.com> In-Reply-To: <506B134B.20006@citrix.com> X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 Cc: Xen Devel , QEMU-devel , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH V4 4/5] exec, memory: Call to xen_modified_memory. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 10/02/2012 06:16 PM, Anthony PERARD wrote: > >> Possibly the first bit too? > > But the call from invalidate_and_set_dirty, I can not remove it because > it does not work. The xen function must be called without condition as > xen and qemu does not maintained the same dirtymap. Right, in fact we added invalidate_and_set_dirty() in order to stick the xen call in it, I just forgot about it. So the first bit is okay. -- error compiling committee.c: too many arguments to function _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 16:46:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 16:46:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5bv-0006uD-SN; Tue, 02 Oct 2012 16:46:19 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5bu-0006u8-S0 for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 16:46:19 +0000 Received: from [85.158.139.211:29052] by server-14.bemta-5.messagelabs.com id EB/FD-05772-A5A1B605; Tue, 02 Oct 2012 16:46:18 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-13.tower-206.messagelabs.com!1349196377!16822681!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28948 invoked from network); 2 Oct 2012 16:46:17 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 16:46:17 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="14899812" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 16:46:16 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 17:46:17 +0100 Date: Tue, 2 Oct 2012 17:45:17 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Konrad Rzeszutek Wilk Message-ID: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: "sfr@canb.auug.org.au" , "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , "JBeulich@suse.com" , Stefano Stabellini Subject: [Xen-devel] [PATCH v2] xen/Makefile: resolve merge conflict with 9fa5780beea1 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch is actually a merge conflict resolution between Konrad's Xen tree and the following commit: commit 9fa5780beea1274d498a224822397100022da7d4 Author: Jan Beulich Date: Tue Sep 18 12:23:02 2012 +0100 USB EHCI/Xen: propagate controller reset information to hypervisor Compile dbgp.o only if CONFIG_USB_SUPPORT is defined. After all xen_dbgp_op relies on hcd_to_bus. This patch should be applied on top of http://marc.info/?l=linux-kernel&m=134919011231980&w=2 Reported-by: Stephen Rothwell Suggested-by: Jan Beulich Signed-off-by: Stefano Stabellini diff --cc drivers/xen/Makefile index a4a3cab,275abfc..33711ad --- a/drivers/xen/Makefile +++ b/drivers/xen/Makefile @@@ -4,8 -8,11 +8,12 @@@ obj-y += xenbus nostackp := $(call cc-option, -fno-stack-protector) CFLAGS_features.o := $(nostackp) + dom0-$(CONFIG_PCI) += pci.o + dom0-$(CONFIG_ACPI) += acpi.o + dom0-$(CONFIG_X86) += pcpu.o ++dom0-$(CONFIG_USB_SUPPORT) += dbgp.o + obj-$(CONFIG_XEN_DOM0) += $(dom0-y) obj-$(CONFIG_BLOCK) += biomerge.o - obj-$(CONFIG_HOTPLUG_CPU) += cpu_hotplug.o obj-$(CONFIG_XEN_XENCOMM) += xencomm.o obj-$(CONFIG_XEN_BALLOON) += xen-balloon.o obj-$(CONFIG_XEN_SELFBALLOONING) += xen-selfballoon.o _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 16:46:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 16:46:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5bv-0006uD-SN; Tue, 02 Oct 2012 16:46:19 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5bu-0006u8-S0 for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 16:46:19 +0000 Received: from [85.158.139.211:29052] by server-14.bemta-5.messagelabs.com id EB/FD-05772-A5A1B605; Tue, 02 Oct 2012 16:46:18 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-13.tower-206.messagelabs.com!1349196377!16822681!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28948 invoked from network); 2 Oct 2012 16:46:17 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 16:46:17 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="14899812" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 16:46:16 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 17:46:17 +0100 Date: Tue, 2 Oct 2012 17:45:17 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Konrad Rzeszutek Wilk Message-ID: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: "sfr@canb.auug.org.au" , "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , "JBeulich@suse.com" , Stefano Stabellini Subject: [Xen-devel] [PATCH v2] xen/Makefile: resolve merge conflict with 9fa5780beea1 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch is actually a merge conflict resolution between Konrad's Xen tree and the following commit: commit 9fa5780beea1274d498a224822397100022da7d4 Author: Jan Beulich Date: Tue Sep 18 12:23:02 2012 +0100 USB EHCI/Xen: propagate controller reset information to hypervisor Compile dbgp.o only if CONFIG_USB_SUPPORT is defined. After all xen_dbgp_op relies on hcd_to_bus. This patch should be applied on top of http://marc.info/?l=linux-kernel&m=134919011231980&w=2 Reported-by: Stephen Rothwell Suggested-by: Jan Beulich Signed-off-by: Stefano Stabellini diff --cc drivers/xen/Makefile index a4a3cab,275abfc..33711ad --- a/drivers/xen/Makefile +++ b/drivers/xen/Makefile @@@ -4,8 -8,11 +8,12 @@@ obj-y += xenbus nostackp := $(call cc-option, -fno-stack-protector) CFLAGS_features.o := $(nostackp) + dom0-$(CONFIG_PCI) += pci.o + dom0-$(CONFIG_ACPI) += acpi.o + dom0-$(CONFIG_X86) += pcpu.o ++dom0-$(CONFIG_USB_SUPPORT) += dbgp.o + obj-$(CONFIG_XEN_DOM0) += $(dom0-y) obj-$(CONFIG_BLOCK) += biomerge.o - obj-$(CONFIG_HOTPLUG_CPU) += cpu_hotplug.o obj-$(CONFIG_XEN_XENCOMM) += xencomm.o obj-$(CONFIG_XEN_BALLOON) += xen-balloon.o obj-$(CONFIG_XEN_SELFBALLOONING) += xen-selfballoon.o _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 16:47:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 16:47:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5cd-0006wg-9Y; Tue, 02 Oct 2012 16:47:03 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5cc-0006wX-7Y for xen-devel@lists.xen.org; Tue, 02 Oct 2012 16:47:02 +0000 Received: from [85.158.143.99:50192] by server-1.bemta-4.messagelabs.com id 49/84-05684-48A1B605; Tue, 02 Oct 2012 16:47:00 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1349196419!24463428!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6344 invoked from network); 2 Oct 2012 16:47:00 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 16:47:00 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="14899823" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 16:46:59 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 17:46:59 +0100 Message-ID: <1349196417.650.115.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Giorgio Mossa Date: Tue, 2 Oct 2012 17:46:57 +0100 In-Reply-To: <20121002163136.GA5378@intersect> References: <20121002163136.GA5378@intersect> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-users@lists.xen.org" , Roger Pau Monne , Ian Jackson , xen-devel Subject: [Xen-devel] libutil.h moved to bsd/libutil.h (Was: Re: [Xen-users] Problem compiling Xen 4.2 from sources) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org (Adding some CCs) On Tue, 2012-10-02 at 17:31 +0100, Giorgio Mossa wrote: > Hello everyone, > I'm working on an Ubuntu 12.04 and I wanted to test > Xen 4.2 (official repository offer just version 4.1), > so I've downloaded the source tarball from the site, > followed the instruction in the readme but when compiling > I'm getting the following error: > > In file included from libxl_bootloader.c:21:0: > /usr/include/libutil.h:33:2: error: #warning "Deprecated header, use or libbsd-overlay.pc instead." [-Werror=cpp] > cc1: all warnings being treated as errors > make[3]: *** [libxl_bootloader.o] Error 1 > > could anyone explain how to solve this problem, without disabling the warning/errors compilation options? Looks like someone has decided to move this header from /usr/include to /usr/include/bsd and leave behind a #warning in the old location, which has broken the way we do things. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640895 seems to relate to the fallout from this. I'm not sure when the include of libutil is needed, it's not mentioned in the Linux man pages and on Linux neither of the functions we purport to need from it are actually present. Perhaps it's a BSD only thing? Probably we need to check for bsd/libutil.h in preference to libutil.h although the resolution of #640895 suggests that what we do now is correct now that the bug is fixed, in which case a bug against Ubuntu would be appropriate. Ian, Royer, What do you guys think? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 16:47:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 16:47:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5cd-0006wg-9Y; Tue, 02 Oct 2012 16:47:03 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5cc-0006wX-7Y for xen-devel@lists.xen.org; Tue, 02 Oct 2012 16:47:02 +0000 Received: from [85.158.143.99:50192] by server-1.bemta-4.messagelabs.com id 49/84-05684-48A1B605; Tue, 02 Oct 2012 16:47:00 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1349196419!24463428!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6344 invoked from network); 2 Oct 2012 16:47:00 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 16:47:00 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="14899823" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 16:46:59 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 17:46:59 +0100 Message-ID: <1349196417.650.115.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Giorgio Mossa Date: Tue, 2 Oct 2012 17:46:57 +0100 In-Reply-To: <20121002163136.GA5378@intersect> References: <20121002163136.GA5378@intersect> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-users@lists.xen.org" , Roger Pau Monne , Ian Jackson , xen-devel Subject: [Xen-devel] libutil.h moved to bsd/libutil.h (Was: Re: [Xen-users] Problem compiling Xen 4.2 from sources) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org (Adding some CCs) On Tue, 2012-10-02 at 17:31 +0100, Giorgio Mossa wrote: > Hello everyone, > I'm working on an Ubuntu 12.04 and I wanted to test > Xen 4.2 (official repository offer just version 4.1), > so I've downloaded the source tarball from the site, > followed the instruction in the readme but when compiling > I'm getting the following error: > > In file included from libxl_bootloader.c:21:0: > /usr/include/libutil.h:33:2: error: #warning "Deprecated header, use or libbsd-overlay.pc instead." [-Werror=cpp] > cc1: all warnings being treated as errors > make[3]: *** [libxl_bootloader.o] Error 1 > > could anyone explain how to solve this problem, without disabling the warning/errors compilation options? Looks like someone has decided to move this header from /usr/include to /usr/include/bsd and leave behind a #warning in the old location, which has broken the way we do things. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640895 seems to relate to the fallout from this. I'm not sure when the include of libutil is needed, it's not mentioned in the Linux man pages and on Linux neither of the functions we purport to need from it are actually present. Perhaps it's a BSD only thing? Probably we need to check for bsd/libutil.h in preference to libutil.h although the resolution of #640895 suggests that what we do now is correct now that the bug is fixed, in which case a bug against Ubuntu would be appropriate. Ian, Royer, What do you guys think? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 16:50:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 16:50:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5fc-0007Io-HS; Tue, 02 Oct 2012 16:50:08 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5fb-0007Ig-R6 for xen-devel@lists.xen.org; Tue, 02 Oct 2012 16:50:08 +0000 Received: from [85.158.137.99:40766] by server-5.bemta-3.messagelabs.com id A9/E0-00589-E3B1B605; Tue, 02 Oct 2012 16:50:06 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-2.tower-217.messagelabs.com!1349196605!19880246!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19272 invoked from network); 2 Oct 2012 16:50:06 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 16:50:06 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="14899863" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 16:50:05 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 17:50:05 +0100 Message-ID: <1349196603.650.116.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Giorgio Mossa Date: Tue, 2 Oct 2012 17:50:03 +0100 In-Reply-To: <1349196417.650.115.camel@zakaz.uk.xensource.com> References: <20121002163136.GA5378@intersect> <1349196417.650.115.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-users@lists.xen.org" , xen-devel , Ian Jackson , Roger Pau Monne Subject: Re: [Xen-devel] [Xen-users] libutil.h moved to bsd/libutil.h (Was: Re: Problem compiling Xen 4.2 from sources) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-10-02 at 17:46 +0100, Ian Campbell wrote: > (Adding some CCs) > On Tue, 2012-10-02 at 17:31 +0100, Giorgio Mossa wrote: > > Hello everyone, > > I'm working on an Ubuntu 12.04 and I wanted to test > > Xen 4.2 (official repository offer just version 4.1), > > so I've downloaded the source tarball from the site, > > followed the instruction in the readme but when compiling > > I'm getting the following error: > > > > In file included from libxl_bootloader.c:21:0: > > /usr/include/libutil.h:33:2: error: #warning "Deprecated header, use or libbsd-overlay.pc instead." [-Werror=cpp] > > cc1: all warnings being treated as errors > > make[3]: *** [libxl_bootloader.o] Error 1 > > > > could anyone explain how to solve this problem, without disabling > the warning/errors compilation options? Oh, BTW, I expect you could just purge libbsd-dev from your system and that would workaround the issue. Ian. > > Looks like someone has decided to move this header from /usr/include > to /usr/include/bsd and leave behind a #warning in the old location, > which has broken the way we do things. > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640895 seems to relate > to the fallout from this. > > I'm not sure when the include of libutil is needed, it's not mentioned > in the Linux man pages and on Linux neither of the functions we purport > to need from it are actually present. Perhaps it's a BSD only thing? > > Probably we need to check for bsd/libutil.h in preference to libutil.h > although the resolution of #640895 suggests that what we do now is > correct now that the bug is fixed, in which case a bug against Ubuntu > would be appropriate. > > Ian, Royer, What do you guys think? > > Ian. > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 16:50:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 16:50:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5fc-0007Io-HS; Tue, 02 Oct 2012 16:50:08 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5fb-0007Ig-R6 for xen-devel@lists.xen.org; Tue, 02 Oct 2012 16:50:08 +0000 Received: from [85.158.137.99:40766] by server-5.bemta-3.messagelabs.com id A9/E0-00589-E3B1B605; Tue, 02 Oct 2012 16:50:06 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-2.tower-217.messagelabs.com!1349196605!19880246!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19272 invoked from network); 2 Oct 2012 16:50:06 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 16:50:06 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="14899863" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 16:50:05 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 17:50:05 +0100 Message-ID: <1349196603.650.116.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Giorgio Mossa Date: Tue, 2 Oct 2012 17:50:03 +0100 In-Reply-To: <1349196417.650.115.camel@zakaz.uk.xensource.com> References: <20121002163136.GA5378@intersect> <1349196417.650.115.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-users@lists.xen.org" , xen-devel , Ian Jackson , Roger Pau Monne Subject: Re: [Xen-devel] [Xen-users] libutil.h moved to bsd/libutil.h (Was: Re: Problem compiling Xen 4.2 from sources) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-10-02 at 17:46 +0100, Ian Campbell wrote: > (Adding some CCs) > On Tue, 2012-10-02 at 17:31 +0100, Giorgio Mossa wrote: > > Hello everyone, > > I'm working on an Ubuntu 12.04 and I wanted to test > > Xen 4.2 (official repository offer just version 4.1), > > so I've downloaded the source tarball from the site, > > followed the instruction in the readme but when compiling > > I'm getting the following error: > > > > In file included from libxl_bootloader.c:21:0: > > /usr/include/libutil.h:33:2: error: #warning "Deprecated header, use or libbsd-overlay.pc instead." [-Werror=cpp] > > cc1: all warnings being treated as errors > > make[3]: *** [libxl_bootloader.o] Error 1 > > > > could anyone explain how to solve this problem, without disabling > the warning/errors compilation options? Oh, BTW, I expect you could just purge libbsd-dev from your system and that would workaround the issue. Ian. > > Looks like someone has decided to move this header from /usr/include > to /usr/include/bsd and leave behind a #warning in the old location, > which has broken the way we do things. > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640895 seems to relate > to the fallout from this. > > I'm not sure when the include of libutil is needed, it's not mentioned > in the Linux man pages and on Linux neither of the functions we purport > to need from it are actually present. Perhaps it's a BSD only thing? > > Probably we need to check for bsd/libutil.h in preference to libutil.h > although the resolution of #640895 suggests that what we do now is > correct now that the bug is fixed, in which case a bug against Ubuntu > would be appropriate. > > Ian, Royer, What do you guys think? > > Ian. > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 16:53:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 16:53:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5iC-0007g0-PP; Tue, 02 Oct 2012 16:52:48 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5iA-0007fL-K3 for xen-devel@lists.xen.org; Tue, 02 Oct 2012 16:52:46 +0000 Received: from [85.158.139.211:7863] by server-5.bemta-5.messagelabs.com id 11/66-21075-CDB1B605; Tue, 02 Oct 2012 16:52:44 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-15.tower-206.messagelabs.com!1349196762!20850064!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzkyODg=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16561 invoked from network); 2 Oct 2012 16:52:43 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 16:52:43 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="210045257" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 16:52:42 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 12:52:41 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJ5i5-0002u1-ER; Tue, 02 Oct 2012 17:52:41 +0100 From: Anthony PERARD To: QEMU-devel , Stefano Stabellini , Avi Kivity Date: Tue, 2 Oct 2012 17:52:27 +0100 Message-ID: <1349196747-30410-6-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1349196747-30410-1-git-send-email-anthony.perard@citrix.com> References: <1349196747-30410-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Cc: Anthony PERARD , Xen Devel Subject: [Xen-devel] [PATCH V5 5/5] xen: Set the vram dirty when an error occur. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on all the video ram. This case happens during migration. Signed-off-by: Anthony PERARD Acked-by: Stefano Stabellini --- xen-all.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/xen-all.c b/xen-all.c index b11542c..e6308be 100644 --- a/xen-all.c +++ b/xen-all.c @@ -507,7 +507,8 @@ static void xen_sync_dirty_bitmap(XenIOState *state, bitmap); if (rc < 0) { if (rc != -ENODATA) { - fprintf(stderr, "xen: track_dirty_vram failed (0x" TARGET_FMT_plx + memory_region_set_dirty(framebuffer, 0, size); + DPRINTF("xen: track_dirty_vram failed (0x" TARGET_FMT_plx ", 0x" TARGET_FMT_plx "): %s\n", start_addr, start_addr + size, strerror(-rc)); } -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 16:53:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 16:53:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5iC-0007g0-PP; Tue, 02 Oct 2012 16:52:48 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5iA-0007fL-K3 for xen-devel@lists.xen.org; Tue, 02 Oct 2012 16:52:46 +0000 Received: from [85.158.139.211:7863] by server-5.bemta-5.messagelabs.com id 11/66-21075-CDB1B605; Tue, 02 Oct 2012 16:52:44 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-15.tower-206.messagelabs.com!1349196762!20850064!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzkyODg=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16561 invoked from network); 2 Oct 2012 16:52:43 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 16:52:43 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="210045257" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 16:52:42 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 12:52:41 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJ5i5-0002u1-ER; Tue, 02 Oct 2012 17:52:41 +0100 From: Anthony PERARD To: QEMU-devel , Stefano Stabellini , Avi Kivity Date: Tue, 2 Oct 2012 17:52:27 +0100 Message-ID: <1349196747-30410-6-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1349196747-30410-1-git-send-email-anthony.perard@citrix.com> References: <1349196747-30410-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Cc: Anthony PERARD , Xen Devel Subject: [Xen-devel] [PATCH V5 5/5] xen: Set the vram dirty when an error occur. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on all the video ram. This case happens during migration. Signed-off-by: Anthony PERARD Acked-by: Stefano Stabellini --- xen-all.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/xen-all.c b/xen-all.c index b11542c..e6308be 100644 --- a/xen-all.c +++ b/xen-all.c @@ -507,7 +507,8 @@ static void xen_sync_dirty_bitmap(XenIOState *state, bitmap); if (rc < 0) { if (rc != -ENODATA) { - fprintf(stderr, "xen: track_dirty_vram failed (0x" TARGET_FMT_plx + memory_region_set_dirty(framebuffer, 0, size); + DPRINTF("xen: track_dirty_vram failed (0x" TARGET_FMT_plx ", 0x" TARGET_FMT_plx "): %s\n", start_addr, start_addr + size, strerror(-rc)); } -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 16:53:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 16:53:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5iF-0007hb-W1; Tue, 02 Oct 2012 16:52:51 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5iE-0007gV-CS for xen-devel@lists.xen.org; Tue, 02 Oct 2012 16:52:50 +0000 Received: from [85.158.139.211:12064] by server-11.bemta-5.messagelabs.com id 63/C9-13866-1EB1B605; Tue, 02 Oct 2012 16:52:49 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-12.tower-206.messagelabs.com!1349196762!19795793!4 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzMyODA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13188 invoked from network); 2 Oct 2012 16:52:48 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 16:52:48 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="39891643" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 16:52:41 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 12:52:41 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJ5i5-0002u1-Di; Tue, 02 Oct 2012 17:52:41 +0100 From: Anthony PERARD To: QEMU-devel , Stefano Stabellini , Avi Kivity Date: Tue, 2 Oct 2012 17:52:25 +0100 Message-ID: <1349196747-30410-4-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1349196747-30410-1-git-send-email-anthony.perard@citrix.com> References: <1349196747-30410-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Cc: Anthony PERARD , Xen Devel Subject: [Xen-devel] [PATCH V5 3/5] exec: Introduce helper to set dirty flags. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This new helper/hook is used in the next patch to add an extra call in a single place. Signed-off-by: Anthony PERARD Reviewed-by: Avi Kivity --- exec.c | 52 +++++++++++++++++----------------------------------- 1 file changed, 17 insertions(+), 35 deletions(-) diff --git a/exec.c b/exec.c index bb6aa4a..366684c 100644 --- a/exec.c +++ b/exec.c @@ -3417,6 +3417,18 @@ int cpu_memory_rw_debug(CPUArchState *env, target_ulong addr, } #else + +static void invalidate_and_set_dirty(target_phys_addr_t addr, + target_phys_addr_t length) +{ + if (!cpu_physical_memory_is_dirty(addr)) { + /* invalidate code */ + tb_invalidate_phys_page_range(addr, addr + length, 0); + /* set dirty bit */ + cpu_physical_memory_set_dirty_flags(addr, (0xff & ~CODE_DIRTY_FLAG)); + } +} + void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf, int len, int is_write) { @@ -3462,13 +3474,7 @@ void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf, /* RAM case */ ptr = qemu_get_ram_ptr(addr1); memcpy(ptr, buf, l); - if (!cpu_physical_memory_is_dirty(addr1)) { - /* invalidate code */ - tb_invalidate_phys_page_range(addr1, addr1 + l, 0); - /* set dirty bit */ - cpu_physical_memory_set_dirty_flags( - addr1, (0xff & ~CODE_DIRTY_FLAG)); - } + invalidate_and_set_dirty(addr1, l); qemu_put_ram_ptr(ptr); } } else { @@ -3534,13 +3540,7 @@ void cpu_physical_memory_write_rom(target_phys_addr_t addr, /* ROM/RAM case */ ptr = qemu_get_ram_ptr(addr1); memcpy(ptr, buf, l); - if (!cpu_physical_memory_is_dirty(addr1)) { - /* invalidate code */ - tb_invalidate_phys_page_range(addr1, addr1 + l, 0); - /* set dirty bit */ - cpu_physical_memory_set_dirty_flags( - addr1, (0xff & ~CODE_DIRTY_FLAG)); - } + invalidate_and_set_dirty(addr1, l); qemu_put_ram_ptr(ptr); } len -= l; @@ -3666,13 +3666,7 @@ void cpu_physical_memory_unmap(void *buffer, target_phys_addr_t len, l = TARGET_PAGE_SIZE; if (l > access_len) l = access_len; - if (!cpu_physical_memory_is_dirty(addr1)) { - /* invalidate code */ - tb_invalidate_phys_page_range(addr1, addr1 + l, 0); - /* set dirty bit */ - cpu_physical_memory_set_dirty_flags( - addr1, (0xff & ~CODE_DIRTY_FLAG)); - } + invalidate_and_set_dirty(addr1, l); addr1 += l; access_len -= l; } @@ -3978,13 +3972,7 @@ static inline void stl_phys_internal(target_phys_addr_t addr, uint32_t val, stl_p(ptr, val); break; } - if (!cpu_physical_memory_is_dirty(addr1)) { - /* invalidate code */ - tb_invalidate_phys_page_range(addr1, addr1 + 4, 0); - /* set dirty bit */ - cpu_physical_memory_set_dirty_flags(addr1, - (0xff & ~CODE_DIRTY_FLAG)); - } + invalidate_and_set_dirty(addr1, 4); } } @@ -4051,13 +4039,7 @@ static inline void stw_phys_internal(target_phys_addr_t addr, uint32_t val, stw_p(ptr, val); break; } - if (!cpu_physical_memory_is_dirty(addr1)) { - /* invalidate code */ - tb_invalidate_phys_page_range(addr1, addr1 + 2, 0); - /* set dirty bit */ - cpu_physical_memory_set_dirty_flags(addr1, - (0xff & ~CODE_DIRTY_FLAG)); - } + invalidate_and_set_dirty(addr1, 2); } } -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 16:53:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 16:53:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5iE-0007gc-K2; Tue, 02 Oct 2012 16:52:50 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5iC-0007fy-Vj for xen-devel@lists.xen.org; Tue, 02 Oct 2012 16:52:49 +0000 Received: from [85.158.139.211:57861] by server-13.bemta-5.messagelabs.com id AE/F8-16359-0EB1B605; Tue, 02 Oct 2012 16:52:48 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-12.tower-206.messagelabs.com!1349196762!19795793!2 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzMyODA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13156 invoked from network); 2 Oct 2012 16:52:47 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 16:52:47 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="39891640" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 16:52:41 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 12:52:41 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJ5i5-0002u1-DK; Tue, 02 Oct 2012 17:52:41 +0100 From: Anthony PERARD To: QEMU-devel , Stefano Stabellini , Avi Kivity Date: Tue, 2 Oct 2012 17:52:24 +0100 Message-ID: <1349196747-30410-3-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1349196747-30410-1-git-send-email-anthony.perard@citrix.com> References: <1349196747-30410-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Cc: Anthony PERARD , Xen Devel Subject: [Xen-devel] [PATCH V5 2/5] xen: Introduce xen_modified_memory. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This function is to be used during live migration. Every write access to the guest memory should call this funcion so the Xen tools knows which pages are dirty. Signed-off-by: Anthony PERARD Acked-by: Stefano Stabellini --- hw/xen.h | 1 + xen-all.c | 21 +++++++++++++++++++++ xen-stub.c | 4 ++++ 3 files changed, 26 insertions(+) diff --git a/hw/xen.h b/hw/xen.h index e5926b7..d14e92d 100644 --- a/hw/xen.h +++ b/hw/xen.h @@ -48,6 +48,7 @@ void xenstore_store_pv_console_info(int i, struct CharDriverState *chr); struct MemoryRegion; void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, struct MemoryRegion *mr); +void xen_modified_memory(ram_addr_t start, ram_addr_t length); #endif struct MemoryRegion; diff --git a/xen-all.c b/xen-all.c index f75ae9f..b11542c 100644 --- a/xen-all.c +++ b/xen-all.c @@ -1228,3 +1228,24 @@ void xen_shutdown_fatal_error(const char *fmt, ...) /* destroy the domain */ qemu_system_shutdown_request(); } + +void xen_modified_memory(ram_addr_t start, ram_addr_t length) +{ + if (unlikely(xen_in_migration)) { + int rc; + ram_addr_t start_pfn, nb_pages; + + if (length == 0) { + length = TARGET_PAGE_SIZE; + } + start_pfn = start >> TARGET_PAGE_BITS; + nb_pages = ((start + length + TARGET_PAGE_SIZE - 1) >> TARGET_PAGE_BITS) + - start_pfn; + rc = xc_hvm_modified_memory(xen_xc, xen_domid, start_pfn, nb_pages); + if (rc) { + fprintf(stderr, + "%s failed for "RAM_ADDR_FMT" ("RAM_ADDR_FMT"): %i, %s\n", + __func__, start, nb_pages, rc, strerror(-rc)); + } + } +} diff --git a/xen-stub.c b/xen-stub.c index 5e66ba8..9214392 100644 --- a/xen-stub.c +++ b/xen-stub.c @@ -59,3 +59,7 @@ void xen_register_framebuffer(MemoryRegion *mr) void qmp_xen_set_global_dirty_log(bool enable, Error **errp) { } + +void xen_modified_memory(ram_addr_t start, ram_addr_t length) +{ +} -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 16:53:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 16:53:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5iE-0007gc-K2; Tue, 02 Oct 2012 16:52:50 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5iC-0007fy-Vj for xen-devel@lists.xen.org; Tue, 02 Oct 2012 16:52:49 +0000 Received: from [85.158.139.211:57861] by server-13.bemta-5.messagelabs.com id AE/F8-16359-0EB1B605; Tue, 02 Oct 2012 16:52:48 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-12.tower-206.messagelabs.com!1349196762!19795793!2 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzMyODA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13156 invoked from network); 2 Oct 2012 16:52:47 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 16:52:47 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="39891640" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 16:52:41 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 12:52:41 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJ5i5-0002u1-DK; Tue, 02 Oct 2012 17:52:41 +0100 From: Anthony PERARD To: QEMU-devel , Stefano Stabellini , Avi Kivity Date: Tue, 2 Oct 2012 17:52:24 +0100 Message-ID: <1349196747-30410-3-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1349196747-30410-1-git-send-email-anthony.perard@citrix.com> References: <1349196747-30410-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Cc: Anthony PERARD , Xen Devel Subject: [Xen-devel] [PATCH V5 2/5] xen: Introduce xen_modified_memory. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This function is to be used during live migration. Every write access to the guest memory should call this funcion so the Xen tools knows which pages are dirty. Signed-off-by: Anthony PERARD Acked-by: Stefano Stabellini --- hw/xen.h | 1 + xen-all.c | 21 +++++++++++++++++++++ xen-stub.c | 4 ++++ 3 files changed, 26 insertions(+) diff --git a/hw/xen.h b/hw/xen.h index e5926b7..d14e92d 100644 --- a/hw/xen.h +++ b/hw/xen.h @@ -48,6 +48,7 @@ void xenstore_store_pv_console_info(int i, struct CharDriverState *chr); struct MemoryRegion; void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, struct MemoryRegion *mr); +void xen_modified_memory(ram_addr_t start, ram_addr_t length); #endif struct MemoryRegion; diff --git a/xen-all.c b/xen-all.c index f75ae9f..b11542c 100644 --- a/xen-all.c +++ b/xen-all.c @@ -1228,3 +1228,24 @@ void xen_shutdown_fatal_error(const char *fmt, ...) /* destroy the domain */ qemu_system_shutdown_request(); } + +void xen_modified_memory(ram_addr_t start, ram_addr_t length) +{ + if (unlikely(xen_in_migration)) { + int rc; + ram_addr_t start_pfn, nb_pages; + + if (length == 0) { + length = TARGET_PAGE_SIZE; + } + start_pfn = start >> TARGET_PAGE_BITS; + nb_pages = ((start + length + TARGET_PAGE_SIZE - 1) >> TARGET_PAGE_BITS) + - start_pfn; + rc = xc_hvm_modified_memory(xen_xc, xen_domid, start_pfn, nb_pages); + if (rc) { + fprintf(stderr, + "%s failed for "RAM_ADDR_FMT" ("RAM_ADDR_FMT"): %i, %s\n", + __func__, start, nb_pages, rc, strerror(-rc)); + } + } +} diff --git a/xen-stub.c b/xen-stub.c index 5e66ba8..9214392 100644 --- a/xen-stub.c +++ b/xen-stub.c @@ -59,3 +59,7 @@ void xen_register_framebuffer(MemoryRegion *mr) void qmp_xen_set_global_dirty_log(bool enable, Error **errp) { } + +void xen_modified_memory(ram_addr_t start, ram_addr_t length) +{ +} -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 16:53:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 16:53:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5iF-0007hb-W1; Tue, 02 Oct 2012 16:52:51 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5iE-0007gV-CS for xen-devel@lists.xen.org; Tue, 02 Oct 2012 16:52:50 +0000 Received: from [85.158.139.211:12064] by server-11.bemta-5.messagelabs.com id 63/C9-13866-1EB1B605; Tue, 02 Oct 2012 16:52:49 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-12.tower-206.messagelabs.com!1349196762!19795793!4 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzMyODA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13188 invoked from network); 2 Oct 2012 16:52:48 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 16:52:48 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="39891643" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 16:52:41 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 12:52:41 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJ5i5-0002u1-Di; Tue, 02 Oct 2012 17:52:41 +0100 From: Anthony PERARD To: QEMU-devel , Stefano Stabellini , Avi Kivity Date: Tue, 2 Oct 2012 17:52:25 +0100 Message-ID: <1349196747-30410-4-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1349196747-30410-1-git-send-email-anthony.perard@citrix.com> References: <1349196747-30410-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Cc: Anthony PERARD , Xen Devel Subject: [Xen-devel] [PATCH V5 3/5] exec: Introduce helper to set dirty flags. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This new helper/hook is used in the next patch to add an extra call in a single place. Signed-off-by: Anthony PERARD Reviewed-by: Avi Kivity --- exec.c | 52 +++++++++++++++++----------------------------------- 1 file changed, 17 insertions(+), 35 deletions(-) diff --git a/exec.c b/exec.c index bb6aa4a..366684c 100644 --- a/exec.c +++ b/exec.c @@ -3417,6 +3417,18 @@ int cpu_memory_rw_debug(CPUArchState *env, target_ulong addr, } #else + +static void invalidate_and_set_dirty(target_phys_addr_t addr, + target_phys_addr_t length) +{ + if (!cpu_physical_memory_is_dirty(addr)) { + /* invalidate code */ + tb_invalidate_phys_page_range(addr, addr + length, 0); + /* set dirty bit */ + cpu_physical_memory_set_dirty_flags(addr, (0xff & ~CODE_DIRTY_FLAG)); + } +} + void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf, int len, int is_write) { @@ -3462,13 +3474,7 @@ void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf, /* RAM case */ ptr = qemu_get_ram_ptr(addr1); memcpy(ptr, buf, l); - if (!cpu_physical_memory_is_dirty(addr1)) { - /* invalidate code */ - tb_invalidate_phys_page_range(addr1, addr1 + l, 0); - /* set dirty bit */ - cpu_physical_memory_set_dirty_flags( - addr1, (0xff & ~CODE_DIRTY_FLAG)); - } + invalidate_and_set_dirty(addr1, l); qemu_put_ram_ptr(ptr); } } else { @@ -3534,13 +3540,7 @@ void cpu_physical_memory_write_rom(target_phys_addr_t addr, /* ROM/RAM case */ ptr = qemu_get_ram_ptr(addr1); memcpy(ptr, buf, l); - if (!cpu_physical_memory_is_dirty(addr1)) { - /* invalidate code */ - tb_invalidate_phys_page_range(addr1, addr1 + l, 0); - /* set dirty bit */ - cpu_physical_memory_set_dirty_flags( - addr1, (0xff & ~CODE_DIRTY_FLAG)); - } + invalidate_and_set_dirty(addr1, l); qemu_put_ram_ptr(ptr); } len -= l; @@ -3666,13 +3666,7 @@ void cpu_physical_memory_unmap(void *buffer, target_phys_addr_t len, l = TARGET_PAGE_SIZE; if (l > access_len) l = access_len; - if (!cpu_physical_memory_is_dirty(addr1)) { - /* invalidate code */ - tb_invalidate_phys_page_range(addr1, addr1 + l, 0); - /* set dirty bit */ - cpu_physical_memory_set_dirty_flags( - addr1, (0xff & ~CODE_DIRTY_FLAG)); - } + invalidate_and_set_dirty(addr1, l); addr1 += l; access_len -= l; } @@ -3978,13 +3972,7 @@ static inline void stl_phys_internal(target_phys_addr_t addr, uint32_t val, stl_p(ptr, val); break; } - if (!cpu_physical_memory_is_dirty(addr1)) { - /* invalidate code */ - tb_invalidate_phys_page_range(addr1, addr1 + 4, 0); - /* set dirty bit */ - cpu_physical_memory_set_dirty_flags(addr1, - (0xff & ~CODE_DIRTY_FLAG)); - } + invalidate_and_set_dirty(addr1, 4); } } @@ -4051,13 +4039,7 @@ static inline void stw_phys_internal(target_phys_addr_t addr, uint32_t val, stw_p(ptr, val); break; } - if (!cpu_physical_memory_is_dirty(addr1)) { - /* invalidate code */ - tb_invalidate_phys_page_range(addr1, addr1 + 2, 0); - /* set dirty bit */ - cpu_physical_memory_set_dirty_flags(addr1, - (0xff & ~CODE_DIRTY_FLAG)); - } + invalidate_and_set_dirty(addr1, 2); } } -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 16:53:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 16:53:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5iF-0007gr-0e; Tue, 02 Oct 2012 16:52:51 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5iD-0007g6-GO for xen-devel@lists.xen.org; Tue, 02 Oct 2012 16:52:49 +0000 Received: from [85.158.139.211:57877] by server-12.bemta-5.messagelabs.com id 84/24-20729-0EB1B605; Tue, 02 Oct 2012 16:52:48 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-12.tower-206.messagelabs.com!1349196762!19795793!3 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzMyODA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13164 invoked from network); 2 Oct 2012 16:52:48 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 16:52:48 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="39891641" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 16:52:41 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 12:52:41 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJ5i5-0002u1-E5; Tue, 02 Oct 2012 17:52:41 +0100 From: Anthony PERARD To: QEMU-devel , Stefano Stabellini , Avi Kivity Date: Tue, 2 Oct 2012 17:52:26 +0100 Message-ID: <1349196747-30410-5-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1349196747-30410-1-git-send-email-anthony.perard@citrix.com> References: <1349196747-30410-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Cc: Anthony PERARD , Xen Devel Subject: [Xen-devel] [PATCH V5 4/5] exec, memory: Call to xen_modified_memory. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch add some calls to xen_modified_memory to notify Xen about dirtybits during migration. Signed-off-by: Anthony PERARD --- exec-obsolete.h | 2 ++ exec.c | 1 + 2 files changed, 3 insertions(+) diff --git a/exec-obsolete.h b/exec-obsolete.h index c099256..286e2f7 100644 --- a/exec-obsolete.h +++ b/exec-obsolete.h @@ -24,6 +24,7 @@ #endif #ifndef CONFIG_USER_ONLY +#include "hw/xen.h" ram_addr_t qemu_ram_alloc_from_ptr(ram_addr_t size, void *host, MemoryRegion *mr); @@ -111,6 +112,7 @@ static inline void cpu_physical_memory_set_dirty_range(ram_addr_t start, for (addr = start; addr < end; addr += TARGET_PAGE_SIZE) { cpu_physical_memory_set_dirty_flags(addr, dirty_flags); } + xen_modified_memory(addr, length); } static inline void cpu_physical_memory_mask_dirty_range(ram_addr_t start, diff --git a/exec.c b/exec.c index 366684c..1114a09 100644 --- a/exec.c +++ b/exec.c @@ -3427,6 +3427,7 @@ static void invalidate_and_set_dirty(target_phys_addr_t addr, /* set dirty bit */ cpu_physical_memory_set_dirty_flags(addr, (0xff & ~CODE_DIRTY_FLAG)); } + xen_modified_memory(addr, length); } void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf, -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 16:53:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 16:53:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5iF-0007gr-0e; Tue, 02 Oct 2012 16:52:51 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5iD-0007g6-GO for xen-devel@lists.xen.org; Tue, 02 Oct 2012 16:52:49 +0000 Received: from [85.158.139.211:57877] by server-12.bemta-5.messagelabs.com id 84/24-20729-0EB1B605; Tue, 02 Oct 2012 16:52:48 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-12.tower-206.messagelabs.com!1349196762!19795793!3 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzMyODA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13164 invoked from network); 2 Oct 2012 16:52:48 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 16:52:48 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="39891641" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 16:52:41 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 12:52:41 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJ5i5-0002u1-E5; Tue, 02 Oct 2012 17:52:41 +0100 From: Anthony PERARD To: QEMU-devel , Stefano Stabellini , Avi Kivity Date: Tue, 2 Oct 2012 17:52:26 +0100 Message-ID: <1349196747-30410-5-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1349196747-30410-1-git-send-email-anthony.perard@citrix.com> References: <1349196747-30410-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Cc: Anthony PERARD , Xen Devel Subject: [Xen-devel] [PATCH V5 4/5] exec, memory: Call to xen_modified_memory. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch add some calls to xen_modified_memory to notify Xen about dirtybits during migration. Signed-off-by: Anthony PERARD --- exec-obsolete.h | 2 ++ exec.c | 1 + 2 files changed, 3 insertions(+) diff --git a/exec-obsolete.h b/exec-obsolete.h index c099256..286e2f7 100644 --- a/exec-obsolete.h +++ b/exec-obsolete.h @@ -24,6 +24,7 @@ #endif #ifndef CONFIG_USER_ONLY +#include "hw/xen.h" ram_addr_t qemu_ram_alloc_from_ptr(ram_addr_t size, void *host, MemoryRegion *mr); @@ -111,6 +112,7 @@ static inline void cpu_physical_memory_set_dirty_range(ram_addr_t start, for (addr = start; addr < end; addr += TARGET_PAGE_SIZE) { cpu_physical_memory_set_dirty_flags(addr, dirty_flags); } + xen_modified_memory(addr, length); } static inline void cpu_physical_memory_mask_dirty_range(ram_addr_t start, diff --git a/exec.c b/exec.c index 366684c..1114a09 100644 --- a/exec.c +++ b/exec.c @@ -3427,6 +3427,7 @@ static void invalidate_and_set_dirty(target_phys_addr_t addr, /* set dirty bit */ cpu_physical_memory_set_dirty_flags(addr, (0xff & ~CODE_DIRTY_FLAG)); } + xen_modified_memory(addr, length); } void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf, -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 16:53:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 16:53:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5iD-0007g9-5h; Tue, 02 Oct 2012 16:52:49 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5iC-0007fl-40 for xen-devel@lists.xen.org; Tue, 02 Oct 2012 16:52:48 +0000 Received: from [85.158.139.211:11988] by server-8.bemta-5.messagelabs.com id 6B/D0-18073-FDB1B605; Tue, 02 Oct 2012 16:52:47 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-12.tower-206.messagelabs.com!1349196762!19795793!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzMyODA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13145 invoked from network); 2 Oct 2012 16:52:46 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 16:52:46 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="39891639" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 16:52:41 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 12:52:41 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJ5i5-0002u1-BE; Tue, 02 Oct 2012 17:52:41 +0100 From: Anthony PERARD To: QEMU-devel , Stefano Stabellini , Avi Kivity Date: Tue, 2 Oct 2012 17:52:22 +0100 Message-ID: <1349196747-30410-1-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 MIME-Version: 1.0 Cc: Anthony PERARD , Xen Devel Subject: [Xen-devel] [PATCH V5 0/5] Xen, introducing dirty log for migration. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hi, This patch set will fix live migration under Xen. For this I introduce a new QMP command to switch global-dirty log and few calls (in exec.c and memory.c) to xen set_dirty function. Change since v4: - call xen_modified_memory in cpu_physical_memory_set_dirty_range instead of calling it from memory_set_dirty. Change since v3: - Coding style of patch 2 - Reword last patch comment Change since v2: - renamed set_dirty_helper to invalidate_and_set_dirty. - in the last patch, set vram as dirty if the xen call fails, instead of only during migration. Change v1-v2: - New patch to set dirty if not, in exec.c => only one place to add the xen call in exec.c Anthony PERARD (5): QMP, Introduce xen-set-global-dirty-log command. xen: Introduce xen_modified_memory. exec: Introduce helper to set dirty flags. exec, memory: Call to xen_modified_memory. xen: Set the vram dirty when an error occur. exec-obsolete.h | 2 ++ exec.c | 53 ++++++++++++++++++----------------------------------- hw/xen.h | 1 + qapi-schema.json | 13 +++++++++++++ qmp-commands.hx | 24 ++++++++++++++++++++++++ xen-all.c | 39 ++++++++++++++++++++++++++++++++++++++- xen-stub.c | 9 +++++++++ 7 files changed, 105 insertions(+), 36 deletions(-) -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 16:53:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 16:53:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5iD-0007g9-5h; Tue, 02 Oct 2012 16:52:49 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5iC-0007fl-40 for xen-devel@lists.xen.org; Tue, 02 Oct 2012 16:52:48 +0000 Received: from [85.158.139.211:11988] by server-8.bemta-5.messagelabs.com id 6B/D0-18073-FDB1B605; Tue, 02 Oct 2012 16:52:47 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-12.tower-206.messagelabs.com!1349196762!19795793!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzMyODA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13145 invoked from network); 2 Oct 2012 16:52:46 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 16:52:46 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="39891639" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 16:52:41 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 12:52:41 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJ5i5-0002u1-BE; Tue, 02 Oct 2012 17:52:41 +0100 From: Anthony PERARD To: QEMU-devel , Stefano Stabellini , Avi Kivity Date: Tue, 2 Oct 2012 17:52:22 +0100 Message-ID: <1349196747-30410-1-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 MIME-Version: 1.0 Cc: Anthony PERARD , Xen Devel Subject: [Xen-devel] [PATCH V5 0/5] Xen, introducing dirty log for migration. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hi, This patch set will fix live migration under Xen. For this I introduce a new QMP command to switch global-dirty log and few calls (in exec.c and memory.c) to xen set_dirty function. Change since v4: - call xen_modified_memory in cpu_physical_memory_set_dirty_range instead of calling it from memory_set_dirty. Change since v3: - Coding style of patch 2 - Reword last patch comment Change since v2: - renamed set_dirty_helper to invalidate_and_set_dirty. - in the last patch, set vram as dirty if the xen call fails, instead of only during migration. Change v1-v2: - New patch to set dirty if not, in exec.c => only one place to add the xen call in exec.c Anthony PERARD (5): QMP, Introduce xen-set-global-dirty-log command. xen: Introduce xen_modified_memory. exec: Introduce helper to set dirty flags. exec, memory: Call to xen_modified_memory. xen: Set the vram dirty when an error occur. exec-obsolete.h | 2 ++ exec.c | 53 ++++++++++++++++++----------------------------------- hw/xen.h | 1 + qapi-schema.json | 13 +++++++++++++ qmp-commands.hx | 24 ++++++++++++++++++++++++ xen-all.c | 39 ++++++++++++++++++++++++++++++++++++++- xen-stub.c | 9 +++++++++ 7 files changed, 105 insertions(+), 36 deletions(-) -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 16:53:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 16:53:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5iF-0007hJ-JQ; Tue, 02 Oct 2012 16:52:51 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5iE-0007gN-3I for xen-devel@lists.xen.org; Tue, 02 Oct 2012 16:52:50 +0000 Received: from [85.158.139.211:12056] by server-14.bemta-5.messagelabs.com id 41/37-05772-1EB1B605; Tue, 02 Oct 2012 16:52:49 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-12.tower-206.messagelabs.com!1349196767!19795802!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzMyODA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13182 invoked from network); 2 Oct 2012 16:52:48 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 16:52:48 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="39891642" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 16:52:41 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 12:52:41 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJ5i5-0002u1-Bh; Tue, 02 Oct 2012 17:52:41 +0100 From: Anthony PERARD To: QEMU-devel , Stefano Stabellini , Avi Kivity Date: Tue, 2 Oct 2012 17:52:23 +0100 Message-ID: <1349196747-30410-2-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1349196747-30410-1-git-send-email-anthony.perard@citrix.com> References: <1349196747-30410-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Cc: Anthony PERARD , Xen Devel Subject: [Xen-devel] [PATCH V5 1/5] QMP, Introduce xen-set-global-dirty-log command. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This command is used during a migration of a guest under Xen. It calls memory_global_dirty_log_start or memory_global_dirty_log_stop according to the argument pass to the command. Signed-off-by: Anthony PERARD Reviewed-by: Luiz Capitulino --- qapi-schema.json | 13 +++++++++++++ qmp-commands.hx | 24 ++++++++++++++++++++++++ xen-all.c | 15 +++++++++++++++ xen-stub.c | 5 +++++ 4 files changed, 57 insertions(+) diff --git a/qapi-schema.json b/qapi-schema.json index 14e4419..696f45a 100644 --- a/qapi-schema.json +++ b/qapi-schema.json @@ -1956,6 +1956,19 @@ { 'command': 'xen-save-devices-state', 'data': {'filename': 'str'} } ## +# @xen-set-global-dirty-log +# +# Enable or disable the global dirty log mode. +# +# @enable: true to enable, false to disable. +# +# Returns: nothing +# +# Since: 1.2 +## +{ 'command': 'xen-set-global-dirty-log', 'data': { 'enable': 'bool' } } + +## # @device_del: # # Remove a device from a guest diff --git a/qmp-commands.hx b/qmp-commands.hx index 6e21ddb..662b7cf 100644 --- a/qmp-commands.hx +++ b/qmp-commands.hx @@ -493,6 +493,30 @@ Example: EQMP { + .name = "xen-set-global-dirty-log", + .args_type = "enable:b", + .mhandler.cmd_new = qmp_marshal_input_xen_set_global_dirty_log, + }, + +SQMP +xen-set-global-dirty-log +------- + +Enable or disable the global dirty log mode. + +Arguments: + +- "enable": Enable it or disable it. + +Example: + +-> { "execute": "xen-set-global-dirty-log", + "arguments": { "enable": true } } +<- { "return": {} } + +EQMP + + { .name = "migrate", .args_type = "detach:-d,blk:-b,inc:-i,uri:s", .mhandler.cmd_new = qmp_marshal_input_migrate, diff --git a/xen-all.c b/xen-all.c index f76b051..f75ae9f 100644 --- a/xen-all.c +++ b/xen-all.c @@ -14,6 +14,7 @@ #include "hw/pc.h" #include "hw/xen_common.h" #include "hw/xen_backend.h" +#include "qmp-commands.h" #include "range.h" #include "xen-mapcache.h" @@ -36,6 +37,7 @@ static MemoryRegion ram_memory, ram_640k, ram_lo, ram_hi; static MemoryRegion *framebuffer; +static bool xen_in_migration; /* Compatibility with older version */ #if __XEN_LATEST_INTERFACE_VERSION__ < 0x0003020a @@ -552,10 +554,14 @@ static void xen_log_sync(MemoryListener *listener, MemoryRegionSection *section) static void xen_log_global_start(MemoryListener *listener) { + if (xen_enabled()) { + xen_in_migration = true; + } } static void xen_log_global_stop(MemoryListener *listener) { + xen_in_migration = false; } static void xen_eventfd_add(MemoryListener *listener, @@ -588,6 +594,15 @@ static MemoryListener xen_memory_listener = { .priority = 10, }; +void qmp_xen_set_global_dirty_log(bool enable, Error **errp) +{ + if (enable) { + memory_global_dirty_log_start(); + } else { + memory_global_dirty_log_stop(); + } +} + /* VCPU Operations, MMIO, IO ring ... */ static void xen_reset_vcpu(void *opaque) diff --git a/xen-stub.c b/xen-stub.c index 8ff2b79..5e66ba8 100644 --- a/xen-stub.c +++ b/xen-stub.c @@ -11,6 +11,7 @@ #include "qemu-common.h" #include "hw/xen.h" #include "memory.h" +#include "qmp-commands.h" void xenstore_store_pv_console_info(int i, CharDriverState *chr) { @@ -54,3 +55,7 @@ int xen_init(void) void xen_register_framebuffer(MemoryRegion *mr) { } + +void qmp_xen_set_global_dirty_log(bool enable, Error **errp) +{ +} -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 16:53:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 16:53:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5iF-0007hJ-JQ; Tue, 02 Oct 2012 16:52:51 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5iE-0007gN-3I for xen-devel@lists.xen.org; Tue, 02 Oct 2012 16:52:50 +0000 Received: from [85.158.139.211:12056] by server-14.bemta-5.messagelabs.com id 41/37-05772-1EB1B605; Tue, 02 Oct 2012 16:52:49 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-12.tower-206.messagelabs.com!1349196767!19795802!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzMyODA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13182 invoked from network); 2 Oct 2012 16:52:48 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 16:52:48 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="39891642" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 16:52:41 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 12:52:41 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJ5i5-0002u1-Bh; Tue, 02 Oct 2012 17:52:41 +0100 From: Anthony PERARD To: QEMU-devel , Stefano Stabellini , Avi Kivity Date: Tue, 2 Oct 2012 17:52:23 +0100 Message-ID: <1349196747-30410-2-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1349196747-30410-1-git-send-email-anthony.perard@citrix.com> References: <1349196747-30410-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Cc: Anthony PERARD , Xen Devel Subject: [Xen-devel] [PATCH V5 1/5] QMP, Introduce xen-set-global-dirty-log command. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This command is used during a migration of a guest under Xen. It calls memory_global_dirty_log_start or memory_global_dirty_log_stop according to the argument pass to the command. Signed-off-by: Anthony PERARD Reviewed-by: Luiz Capitulino --- qapi-schema.json | 13 +++++++++++++ qmp-commands.hx | 24 ++++++++++++++++++++++++ xen-all.c | 15 +++++++++++++++ xen-stub.c | 5 +++++ 4 files changed, 57 insertions(+) diff --git a/qapi-schema.json b/qapi-schema.json index 14e4419..696f45a 100644 --- a/qapi-schema.json +++ b/qapi-schema.json @@ -1956,6 +1956,19 @@ { 'command': 'xen-save-devices-state', 'data': {'filename': 'str'} } ## +# @xen-set-global-dirty-log +# +# Enable or disable the global dirty log mode. +# +# @enable: true to enable, false to disable. +# +# Returns: nothing +# +# Since: 1.2 +## +{ 'command': 'xen-set-global-dirty-log', 'data': { 'enable': 'bool' } } + +## # @device_del: # # Remove a device from a guest diff --git a/qmp-commands.hx b/qmp-commands.hx index 6e21ddb..662b7cf 100644 --- a/qmp-commands.hx +++ b/qmp-commands.hx @@ -493,6 +493,30 @@ Example: EQMP { + .name = "xen-set-global-dirty-log", + .args_type = "enable:b", + .mhandler.cmd_new = qmp_marshal_input_xen_set_global_dirty_log, + }, + +SQMP +xen-set-global-dirty-log +------- + +Enable or disable the global dirty log mode. + +Arguments: + +- "enable": Enable it or disable it. + +Example: + +-> { "execute": "xen-set-global-dirty-log", + "arguments": { "enable": true } } +<- { "return": {} } + +EQMP + + { .name = "migrate", .args_type = "detach:-d,blk:-b,inc:-i,uri:s", .mhandler.cmd_new = qmp_marshal_input_migrate, diff --git a/xen-all.c b/xen-all.c index f76b051..f75ae9f 100644 --- a/xen-all.c +++ b/xen-all.c @@ -14,6 +14,7 @@ #include "hw/pc.h" #include "hw/xen_common.h" #include "hw/xen_backend.h" +#include "qmp-commands.h" #include "range.h" #include "xen-mapcache.h" @@ -36,6 +37,7 @@ static MemoryRegion ram_memory, ram_640k, ram_lo, ram_hi; static MemoryRegion *framebuffer; +static bool xen_in_migration; /* Compatibility with older version */ #if __XEN_LATEST_INTERFACE_VERSION__ < 0x0003020a @@ -552,10 +554,14 @@ static void xen_log_sync(MemoryListener *listener, MemoryRegionSection *section) static void xen_log_global_start(MemoryListener *listener) { + if (xen_enabled()) { + xen_in_migration = true; + } } static void xen_log_global_stop(MemoryListener *listener) { + xen_in_migration = false; } static void xen_eventfd_add(MemoryListener *listener, @@ -588,6 +594,15 @@ static MemoryListener xen_memory_listener = { .priority = 10, }; +void qmp_xen_set_global_dirty_log(bool enable, Error **errp) +{ + if (enable) { + memory_global_dirty_log_start(); + } else { + memory_global_dirty_log_stop(); + } +} + /* VCPU Operations, MMIO, IO ring ... */ static void xen_reset_vcpu(void *opaque) diff --git a/xen-stub.c b/xen-stub.c index 8ff2b79..5e66ba8 100644 --- a/xen-stub.c +++ b/xen-stub.c @@ -11,6 +11,7 @@ #include "qemu-common.h" #include "hw/xen.h" #include "memory.h" +#include "qmp-commands.h" void xenstore_store_pv_console_info(int i, CharDriverState *chr) { @@ -54,3 +55,7 @@ int xen_init(void) void xen_register_framebuffer(MemoryRegion *mr) { } + +void qmp_xen_set_global_dirty_log(bool enable, Error **errp) +{ +} -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 16:54:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 16:54:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5jL-0008A9-FS; Tue, 02 Oct 2012 16:53:59 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5jJ-00089Y-IN for xen-devel@lists.xen.org; Tue, 02 Oct 2012 16:53:57 +0000 Received: from [85.158.139.211:14419] by server-11.bemta-5.messagelabs.com id B8/4B-13866-42C1B605; Tue, 02 Oct 2012 16:53:56 +0000 X-Env-Sender: avi@redhat.com X-Msg-Ref: server-2.tower-206.messagelabs.com!1349196835!20787007!1 X-Originating-IP: [209.132.183.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTY4NTA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4992 invoked from network); 2 Oct 2012 16:53:56 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-2.tower-206.messagelabs.com with SMTP; 2 Oct 2012 16:53:56 -0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q92GrrYI012667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Oct 2012 12:53:53 -0400 Received: from balrog.usersys.tlv.redhat.com (dhcp-4-121.tlv.redhat.com [10.35.4.121]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q92Grpct021831; Tue, 2 Oct 2012 12:53:52 -0400 Message-ID: <506B1C1F.9060601@redhat.com> Date: Tue, 02 Oct 2012 18:53:51 +0200 From: Avi Kivity User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: Anthony PERARD References: <1349196747-30410-1-git-send-email-anthony.perard@citrix.com> <1349196747-30410-5-git-send-email-anthony.perard@citrix.com> In-Reply-To: <1349196747-30410-5-git-send-email-anthony.perard@citrix.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 Cc: Stefano Stabellini , QEMU-devel , Xen Devel Subject: Re: [Xen-devel] [PATCH V5 4/5] exec, memory: Call to xen_modified_memory. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 10/02/2012 06:52 PM, Anthony PERARD wrote: > This patch add some calls to xen_modified_memory to notify Xen about dirtybits > during migration. Reviewed-by: Avi Kivity -- error compiling committee.c: too many arguments to function _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 16:54:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 16:54:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5jL-0008A9-FS; Tue, 02 Oct 2012 16:53:59 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5jJ-00089Y-IN for xen-devel@lists.xen.org; Tue, 02 Oct 2012 16:53:57 +0000 Received: from [85.158.139.211:14419] by server-11.bemta-5.messagelabs.com id B8/4B-13866-42C1B605; Tue, 02 Oct 2012 16:53:56 +0000 X-Env-Sender: avi@redhat.com X-Msg-Ref: server-2.tower-206.messagelabs.com!1349196835!20787007!1 X-Originating-IP: [209.132.183.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTY4NTA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4992 invoked from network); 2 Oct 2012 16:53:56 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-2.tower-206.messagelabs.com with SMTP; 2 Oct 2012 16:53:56 -0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q92GrrYI012667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Oct 2012 12:53:53 -0400 Received: from balrog.usersys.tlv.redhat.com (dhcp-4-121.tlv.redhat.com [10.35.4.121]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q92Grpct021831; Tue, 2 Oct 2012 12:53:52 -0400 Message-ID: <506B1C1F.9060601@redhat.com> Date: Tue, 02 Oct 2012 18:53:51 +0200 From: Avi Kivity User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: Anthony PERARD References: <1349196747-30410-1-git-send-email-anthony.perard@citrix.com> <1349196747-30410-5-git-send-email-anthony.perard@citrix.com> In-Reply-To: <1349196747-30410-5-git-send-email-anthony.perard@citrix.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 Cc: Stefano Stabellini , QEMU-devel , Xen Devel Subject: Re: [Xen-devel] [PATCH V5 4/5] exec, memory: Call to xen_modified_memory. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 10/02/2012 06:52 PM, Anthony PERARD wrote: > This patch add some calls to xen_modified_memory to notify Xen about dirtybits > during migration. Reviewed-by: Avi Kivity -- error compiling committee.c: too many arguments to function _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 16:55:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 16:55:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5kY-0008QL-Ut; Tue, 02 Oct 2012 16:55:14 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5kX-0008Ps-Ev for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 16:55:13 +0000 Received: from [85.158.139.211:10829] by server-4.bemta-5.messagelabs.com id CD/0B-20767-07C1B605; Tue, 02 Oct 2012 16:55:12 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-6.tower-206.messagelabs.com!1349196910!20810146!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzc3NzIy\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21198 invoked from network); 2 Oct 2012 16:55:11 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 16:55:11 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q92Gsx06005741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Oct 2012 16:55:00 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q92Gsx8A025179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Oct 2012 16:54:59 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q92GswQg029500; Tue, 2 Oct 2012 11:54:58 -0500 Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 02 Oct 2012 09:54:58 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id C66B240357; Tue, 2 Oct 2012 12:43:33 -0400 (EDT) Date: Tue, 2 Oct 2012 12:43:33 -0400 From: Konrad Rzeszutek Wilk To: Stefano Stabellini Message-ID: <20121002164333.GA28626@phenom.dumpdata.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "sfr@canb.auug.org.au" , "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , "JBeulich@suse.com" Subject: Re: [Xen-devel] [PATCH v2] xen/Makefile: resolve merge conflict with 9fa5780beea1 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, Oct 02, 2012 at 05:45:17PM +0100, Stefano Stabellini wrote: > This patch is actually a merge conflict resolution between Konrad's Xen > tree and the following commit: > > commit 9fa5780beea1274d498a224822397100022da7d4 > Author: Jan Beulich > Date: Tue Sep 18 12:23:02 2012 +0100 > > USB EHCI/Xen: propagate controller reset information to hypervisor > > > Compile dbgp.o only if CONFIG_USB_SUPPORT is defined. > After all xen_dbgp_op relies on hcd_to_bus. > > This patch should be applied on top of > > http://marc.info/?l=linux-kernel&m=134919011231980&w=2 OK. I have that in my tree (along with the other patch you posted) so I think we are all set for this issue. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 16:55:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 16:55:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5kY-0008QL-Ut; Tue, 02 Oct 2012 16:55:14 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5kX-0008Ps-Ev for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 16:55:13 +0000 Received: from [85.158.139.211:10829] by server-4.bemta-5.messagelabs.com id CD/0B-20767-07C1B605; Tue, 02 Oct 2012 16:55:12 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-6.tower-206.messagelabs.com!1349196910!20810146!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzc3NzIy\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21198 invoked from network); 2 Oct 2012 16:55:11 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 16:55:11 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q92Gsx06005741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Oct 2012 16:55:00 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q92Gsx8A025179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Oct 2012 16:54:59 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q92GswQg029500; Tue, 2 Oct 2012 11:54:58 -0500 Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 02 Oct 2012 09:54:58 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id C66B240357; Tue, 2 Oct 2012 12:43:33 -0400 (EDT) Date: Tue, 2 Oct 2012 12:43:33 -0400 From: Konrad Rzeszutek Wilk To: Stefano Stabellini Message-ID: <20121002164333.GA28626@phenom.dumpdata.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "sfr@canb.auug.org.au" , "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , "JBeulich@suse.com" Subject: Re: [Xen-devel] [PATCH v2] xen/Makefile: resolve merge conflict with 9fa5780beea1 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, Oct 02, 2012 at 05:45:17PM +0100, Stefano Stabellini wrote: > This patch is actually a merge conflict resolution between Konrad's Xen > tree and the following commit: > > commit 9fa5780beea1274d498a224822397100022da7d4 > Author: Jan Beulich > Date: Tue Sep 18 12:23:02 2012 +0100 > > USB EHCI/Xen: propagate controller reset information to hypervisor > > > Compile dbgp.o only if CONFIG_USB_SUPPORT is defined. > After all xen_dbgp_op relies on hcd_to_bus. > > This patch should be applied on top of > > http://marc.info/?l=linux-kernel&m=134919011231980&w=2 OK. I have that in my tree (along with the other patch you posted) so I think we are all set for this issue. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 16:56:44 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 16:56:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5lu-0000Jg-Ev; Tue, 02 Oct 2012 16:56:38 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5lt-0000JL-2y for xen-devel@lists.xen.org; Tue, 02 Oct 2012 16:56:37 +0000 Received: from [85.158.143.35:41329] by server-3.bemta-4.messagelabs.com id 4A/4A-10986-4CC1B605; Tue, 02 Oct 2012 16:56:36 +0000 X-Env-Sender: eblake@redhat.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1349196994!19336805!1 X-Originating-IP: [209.132.183.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTY4NTA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20390 invoked from network); 2 Oct 2012 16:56:35 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-13.tower-21.messagelabs.com with SMTP; 2 Oct 2012 16:56:35 -0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q92GuWgp018347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Oct 2012 12:56:32 -0400 Received: from [10.3.113.52] (ovpn-113-52.phx2.redhat.com [10.3.113.52]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q92GuUU5002524; Tue, 2 Oct 2012 12:56:30 -0400 Message-ID: <506B1CBE.6050408@redhat.com> Date: Tue, 02 Oct 2012 10:56:30 -0600 From: Eric Blake Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: Anthony PERARD References: <1349196747-30410-1-git-send-email-anthony.perard@citrix.com> <1349196747-30410-2-git-send-email-anthony.perard@citrix.com> In-Reply-To: <1349196747-30410-2-git-send-email-anthony.perard@citrix.com> X-Enigmail-Version: 1.4.4 OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 Cc: Xen Devel , Stefano Stabellini , QEMU-devel , Avi Kivity Subject: Re: [Xen-devel] [Qemu-devel] [PATCH V5 1/5] QMP, Introduce xen-set-global-dirty-log command. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6782847573318800760==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============6782847573318800760== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigD65AA63E4078FED0395430A7" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD65AA63E4078FED0395430A7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/02/2012 10:52 AM, Anthony PERARD wrote: > This command is used during a migration of a guest under Xen. It calls > memory_global_dirty_log_start or memory_global_dirty_log_stop according= to the > argument pass to the command. >=20 > Signed-off-by: Anthony PERARD > Reviewed-by: Luiz Capitulino > --- > qapi-schema.json | 13 +++++++++++++ > qmp-commands.hx | 24 ++++++++++++++++++++++++ > xen-all.c | 15 +++++++++++++++ > xen-stub.c | 5 +++++ > 4 files changed, 57 insertions(+) >=20 > diff --git a/qapi-schema.json b/qapi-schema.json > index 14e4419..696f45a 100644 > --- a/qapi-schema.json > +++ b/qapi-schema.json > @@ -1956,6 +1956,19 @@ > { 'command': 'xen-save-devices-state', 'data': {'filename': 'str'} } > =20 > ## > +# @xen-set-global-dirty-log > +# > +# Enable or disable the global dirty log mode. > +# > +# @enable: true to enable, false to disable. > +# > +# Returns: nothing > +# > +# Since: 1.2 1.3 --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enigD65AA63E4078FED0395430A7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBCAAGBQJQaxy+AAoJEKeha0olJ0NqstIH/3gAZOLPhpFarDa4XaNWuvu8 SaFexqeidYOqjGO8fd8AM7SRoEIOeDvHPRsucDg9w/dOFoMBeLt6gn42gjkkhFJP ThYLu1jFzf0NHq609NvtbMR6xEXBBgl6MVroQk1/kVslJDovztjEIJp0K65tHEzM ffSudzV58hM9lWKb9EXXLwjuy8tyLVSRvr3WYJjc9q1scTtJImJ4VH26KWJUqzwW eRXEM/jvzPDKWhJXlv3PU+BLYIQbCMCV6z/uWBOC1uEVgVFYhNrkrIIdv/suN4cZ 2jOMFzLgGtwdXJPhpQtoCb5m+eb8e0Yc08LmLks4sa80YCE3JounjWyTePdrBZ8= =wbqC -----END PGP SIGNATURE----- --------------enigD65AA63E4078FED0395430A7-- --===============6782847573318800760== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6782847573318800760==-- From xen-devel-bounces@lists.xen.org Tue Oct 02 16:56:44 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 16:56:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5lu-0000Jg-Ev; Tue, 02 Oct 2012 16:56:38 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5lt-0000JL-2y for xen-devel@lists.xen.org; Tue, 02 Oct 2012 16:56:37 +0000 Received: from [85.158.143.35:41329] by server-3.bemta-4.messagelabs.com id 4A/4A-10986-4CC1B605; Tue, 02 Oct 2012 16:56:36 +0000 X-Env-Sender: eblake@redhat.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1349196994!19336805!1 X-Originating-IP: [209.132.183.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTY4NTA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20390 invoked from network); 2 Oct 2012 16:56:35 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-13.tower-21.messagelabs.com with SMTP; 2 Oct 2012 16:56:35 -0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q92GuWgp018347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Oct 2012 12:56:32 -0400 Received: from [10.3.113.52] (ovpn-113-52.phx2.redhat.com [10.3.113.52]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q92GuUU5002524; Tue, 2 Oct 2012 12:56:30 -0400 Message-ID: <506B1CBE.6050408@redhat.com> Date: Tue, 02 Oct 2012 10:56:30 -0600 From: Eric Blake Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: Anthony PERARD References: <1349196747-30410-1-git-send-email-anthony.perard@citrix.com> <1349196747-30410-2-git-send-email-anthony.perard@citrix.com> In-Reply-To: <1349196747-30410-2-git-send-email-anthony.perard@citrix.com> X-Enigmail-Version: 1.4.4 OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 Cc: Xen Devel , Stefano Stabellini , QEMU-devel , Avi Kivity Subject: Re: [Xen-devel] [Qemu-devel] [PATCH V5 1/5] QMP, Introduce xen-set-global-dirty-log command. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6782847573318800760==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============6782847573318800760== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigD65AA63E4078FED0395430A7" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD65AA63E4078FED0395430A7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/02/2012 10:52 AM, Anthony PERARD wrote: > This command is used during a migration of a guest under Xen. It calls > memory_global_dirty_log_start or memory_global_dirty_log_stop according= to the > argument pass to the command. >=20 > Signed-off-by: Anthony PERARD > Reviewed-by: Luiz Capitulino > --- > qapi-schema.json | 13 +++++++++++++ > qmp-commands.hx | 24 ++++++++++++++++++++++++ > xen-all.c | 15 +++++++++++++++ > xen-stub.c | 5 +++++ > 4 files changed, 57 insertions(+) >=20 > diff --git a/qapi-schema.json b/qapi-schema.json > index 14e4419..696f45a 100644 > --- a/qapi-schema.json > +++ b/qapi-schema.json > @@ -1956,6 +1956,19 @@ > { 'command': 'xen-save-devices-state', 'data': {'filename': 'str'} } > =20 > ## > +# @xen-set-global-dirty-log > +# > +# Enable or disable the global dirty log mode. > +# > +# @enable: true to enable, false to disable. > +# > +# Returns: nothing > +# > +# Since: 1.2 1.3 --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enigD65AA63E4078FED0395430A7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBCAAGBQJQaxy+AAoJEKeha0olJ0NqstIH/3gAZOLPhpFarDa4XaNWuvu8 SaFexqeidYOqjGO8fd8AM7SRoEIOeDvHPRsucDg9w/dOFoMBeLt6gn42gjkkhFJP ThYLu1jFzf0NHq609NvtbMR6xEXBBgl6MVroQk1/kVslJDovztjEIJp0K65tHEzM ffSudzV58hM9lWKb9EXXLwjuy8tyLVSRvr3WYJjc9q1scTtJImJ4VH26KWJUqzwW eRXEM/jvzPDKWhJXlv3PU+BLYIQbCMCV6z/uWBOC1uEVgVFYhNrkrIIdv/suN4cZ 2jOMFzLgGtwdXJPhpQtoCb5m+eb8e0Yc08LmLks4sa80YCE3JounjWyTePdrBZ8= =wbqC -----END PGP SIGNATURE----- --------------enigD65AA63E4078FED0395430A7-- --===============6782847573318800760== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6782847573318800760==-- From xen-devel-bounces@lists.xen.org Tue Oct 02 17:00:56 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 17:00:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5pq-0000kn-5H; Tue, 02 Oct 2012 17:00:42 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5po-0000ka-8y for xen-devel@lists.xen.org; Tue, 02 Oct 2012 17:00:40 +0000 Received: from [85.158.139.83:6563] by server-14.bemta-5.messagelabs.com id 7B/41-05772-7BD1B605; Tue, 02 Oct 2012 17:00:39 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1349197238!32559983!1 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13026 invoked from network); 2 Oct 2012 17:00:39 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 17:00:39 -0000 Received: by eekb47 with SMTP id b47so3457021eek.32 for ; Tue, 02 Oct 2012 10:00:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=1rmjf4yNS15mcA+3VqF6ucLPCGz4tLeEwyAjSiY8/NI=; b=MZwFpA16Lihsahw8czAPrClecNmxScm26wzHmhqO/CtLiD8lIMF6KeucyqA8J5FtYc Ssv9iAKpQVlwXN6F1FO1RKkgczD7+E9uorYHpzk/pX2sehOy9MX+qOtAIlMeKHq4gqVp a0zd+O29wLMJAMWDE/NI8+t7OdNA4DG4tJm0tR6+iTZG7b48fvmczWFpMFwUyE7KBeZk eYvzGm/0hA6eOBRq07bcsfjIkQAIh2YutoS6wQsWqtDZ4cgoSJKeoVEkomNp+C08JfvC QBTc1IBgqa0NOJwrTsowRH0epxHx2lhZCc854bMFcoJ6zq6dEUKaC8svFWFAZtn7Qgq/ /eDw== Received: by 10.14.204.72 with SMTP id g48mr23207287eeo.45.1349197238835; Tue, 02 Oct 2012 10:00:38 -0700 (PDT) Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com. [86.183.156.141]) by mx.google.com with ESMTPS id d44sm5092432eeo.10.2012.10.02.10.00.36 (version=SSLv3 cipher=OTHER); Tue, 02 Oct 2012 10:00:37 -0700 (PDT) User-Agent: Microsoft-Entourage/12.34.0.120813 Date: Tue, 02 Oct 2012 18:00:32 +0100 From: Keir Fraser To: Jan Beulich , xen-devel Message-ID: Thread-Topic: [Xen-devel] [PATCH] x86: get the MWAIT idle driver in sync with the ACPI one Thread-Index: Ac2gv26yPGLaNTjFEEagrxWIihJU0w== In-Reply-To: <506B1A69020000780009F20F@nat28.tlf.novell.com> Mime-version: 1.0 Subject: Re: [Xen-devel] [PATCH] x86: get the MWAIT idle driver in sync with the ACPI one X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 02/10/2012 15:46, "Jan Beulich" wrote: > .. with respect to behavior when there is no HPET broadcast support > (for using the PIT broadcast instead, it requires explicitly enabling > CPU idle management). > > Signed-off-by: Jan Beulich Acked-by: Keir Fraser > --- a/xen/arch/x86/cpu/mwait-idle.c > +++ b/xen/arch/x86/cpu/mwait-idle.c > @@ -501,11 +501,14 @@ int __init mwait_idle_init(struct notifi > return -ENODEV; > > err = mwait_idle_probe(); > - if (!err) { > - if (!boot_cpu_has(X86_FEATURE_ARAT)) > - hpet_broadcast_init(); > - if (!lapic_timer_init()) > + if (!err && !boot_cpu_has(X86_FEATURE_ARAT)) { > + hpet_broadcast_init(); > + if (xen_cpuidle < 0 && !hpet_broadcast_is_available()) > + err = -ENODEV; > + else if(!lapic_timer_init()) > err = -EINVAL; > + if (err) > + pr_debug(PREFIX "not used (%d)\n", err); > } > if (!err) { > nfb->notifier_call = mwait_idle_cpu_init; > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 17:00:56 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 17:00:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5pq-0000kn-5H; Tue, 02 Oct 2012 17:00:42 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5po-0000ka-8y for xen-devel@lists.xen.org; Tue, 02 Oct 2012 17:00:40 +0000 Received: from [85.158.139.83:6563] by server-14.bemta-5.messagelabs.com id 7B/41-05772-7BD1B605; Tue, 02 Oct 2012 17:00:39 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1349197238!32559983!1 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13026 invoked from network); 2 Oct 2012 17:00:39 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 17:00:39 -0000 Received: by eekb47 with SMTP id b47so3457021eek.32 for ; Tue, 02 Oct 2012 10:00:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=1rmjf4yNS15mcA+3VqF6ucLPCGz4tLeEwyAjSiY8/NI=; b=MZwFpA16Lihsahw8czAPrClecNmxScm26wzHmhqO/CtLiD8lIMF6KeucyqA8J5FtYc Ssv9iAKpQVlwXN6F1FO1RKkgczD7+E9uorYHpzk/pX2sehOy9MX+qOtAIlMeKHq4gqVp a0zd+O29wLMJAMWDE/NI8+t7OdNA4DG4tJm0tR6+iTZG7b48fvmczWFpMFwUyE7KBeZk eYvzGm/0hA6eOBRq07bcsfjIkQAIh2YutoS6wQsWqtDZ4cgoSJKeoVEkomNp+C08JfvC QBTc1IBgqa0NOJwrTsowRH0epxHx2lhZCc854bMFcoJ6zq6dEUKaC8svFWFAZtn7Qgq/ /eDw== Received: by 10.14.204.72 with SMTP id g48mr23207287eeo.45.1349197238835; Tue, 02 Oct 2012 10:00:38 -0700 (PDT) Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com. [86.183.156.141]) by mx.google.com with ESMTPS id d44sm5092432eeo.10.2012.10.02.10.00.36 (version=SSLv3 cipher=OTHER); Tue, 02 Oct 2012 10:00:37 -0700 (PDT) User-Agent: Microsoft-Entourage/12.34.0.120813 Date: Tue, 02 Oct 2012 18:00:32 +0100 From: Keir Fraser To: Jan Beulich , xen-devel Message-ID: Thread-Topic: [Xen-devel] [PATCH] x86: get the MWAIT idle driver in sync with the ACPI one Thread-Index: Ac2gv26yPGLaNTjFEEagrxWIihJU0w== In-Reply-To: <506B1A69020000780009F20F@nat28.tlf.novell.com> Mime-version: 1.0 Subject: Re: [Xen-devel] [PATCH] x86: get the MWAIT idle driver in sync with the ACPI one X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 02/10/2012 15:46, "Jan Beulich" wrote: > .. with respect to behavior when there is no HPET broadcast support > (for using the PIT broadcast instead, it requires explicitly enabling > CPU idle management). > > Signed-off-by: Jan Beulich Acked-by: Keir Fraser > --- a/xen/arch/x86/cpu/mwait-idle.c > +++ b/xen/arch/x86/cpu/mwait-idle.c > @@ -501,11 +501,14 @@ int __init mwait_idle_init(struct notifi > return -ENODEV; > > err = mwait_idle_probe(); > - if (!err) { > - if (!boot_cpu_has(X86_FEATURE_ARAT)) > - hpet_broadcast_init(); > - if (!lapic_timer_init()) > + if (!err && !boot_cpu_has(X86_FEATURE_ARAT)) { > + hpet_broadcast_init(); > + if (xen_cpuidle < 0 && !hpet_broadcast_is_available()) > + err = -ENODEV; > + else if(!lapic_timer_init()) > err = -EINVAL; > + if (err) > + pr_debug(PREFIX "not used (%d)\n", err); > } > if (!err) { > nfb->notifier_call = mwait_idle_cpu_init; > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 17:01:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 17:01:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5qA-0000n1-JZ; Tue, 02 Oct 2012 17:01:02 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5q8-0000mh-7m for xen-devel@lists.xen.org; Tue, 02 Oct 2012 17:01:00 +0000 Received: from [85.158.139.83:38399] by server-14.bemta-5.messagelabs.com id 47/B1-05772-BCD1B605; Tue, 02 Oct 2012 17:00:59 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1349197238!32559983!2 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13545 invoked from network); 2 Oct 2012 17:00:59 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 17:00:59 -0000 Received: by mail-ee0-f45.google.com with SMTP id b47so3457021eek.32 for ; Tue, 02 Oct 2012 10:00:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=dz5NzsQSfMF72+O38LIv63kOVyCAQq0RLZRmbTPl2SE=; b=NOlYn+rz+obDpCNoaX2B6R3UQm1D3xJMc7RwFoZ9m4d/rcYBu6bShzVaArVzkOPFHo y3oMY29RyIcp8DqixN1r9D4AwHBMGQksARvwsG4dFbhsVXikDlSengAiij1Vu8n/B+NA j6EVIjjrCDIr0xTpenFYSB8AtHTfbJs7T4piNUq+TUM659BQAnJNtsBd6Z6jjjRaW1Wt pA9VDwNFfUSZtAOPhHC49QLHoSypfXX1RhJD0CjSQaBKYD575sWvMORllL99b6KVCxbJ 61sXvMMZMkhJW6xSryiOilBPJcXFbVS2M7yb/59K/A9lwgKW3uhiG7zIW8FEfF8Yer/r TiTQ== Received: by 10.14.223.4 with SMTP id u4mr10207503eep.19.1349197259068; Tue, 02 Oct 2012 10:00:59 -0700 (PDT) Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com. [86.183.156.141]) by mx.google.com with ESMTPS id 9sm5084770eei.12.2012.10.02.10.00.57 (version=SSLv3 cipher=OTHER); Tue, 02 Oct 2012 10:00:58 -0700 (PDT) User-Agent: Microsoft-Entourage/12.34.0.120813 Date: Tue, 02 Oct 2012 18:00:55 +0100 From: Keir Fraser To: Jan Beulich , xen-devel Message-ID: Thread-Topic: [Xen-devel] [PATCH] VT-d: make remap_entry_to_msi_msg() return consistent message Thread-Index: Ac2gv3xn4qhANMkRbUWGNGXlPJM5SQ== In-Reply-To: <506B1C6E020000780009F221@nat28.tlf.novell.com> Mime-version: 1.0 Subject: Re: [Xen-devel] [PATCH] VT-d: make remap_entry_to_msi_msg() return consistent message X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 02/10/2012 15:55, "Jan Beulich" wrote: > During debugging of another problem I found that in x2APIC mode, the > destination field of the low address value wasn't passed back > correctly. While this is benign in most cases (as the value isn't being > used anywhere), it can be confusing (and misguiding) when printing the > value read or when comparing it to the one previously passed into the > inverse function. > > Signed-off-by: Jan Beulich Acked-by: Keir Fraser > --- a/xen/drivers/passthrough/vtd/intremap.c > +++ b/xen/drivers/passthrough/vtd/intremap.c > @@ -504,7 +504,11 @@ static int remap_entry_to_msi_msg( > MSI_ADDR_REDIRECTION_CPU: > MSI_ADDR_REDIRECTION_LOWPRI); > if ( x2apic_enabled ) > + { > msg->dest32 = iremap_entry->lo.dst; > + msg->address_lo |= > + (iremap_entry->lo.dst & 0xff) << MSI_ADDR_DEST_ID_SHIFT; > + } > else > msg->address_lo |= > ((iremap_entry->lo.dst >> 8) & 0xff ) << MSI_ADDR_DEST_ID_SHIFT; > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 17:01:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 17:01:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5qA-0000n1-JZ; Tue, 02 Oct 2012 17:01:02 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5q8-0000mh-7m for xen-devel@lists.xen.org; Tue, 02 Oct 2012 17:01:00 +0000 Received: from [85.158.139.83:38399] by server-14.bemta-5.messagelabs.com id 47/B1-05772-BCD1B605; Tue, 02 Oct 2012 17:00:59 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1349197238!32559983!2 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13545 invoked from network); 2 Oct 2012 17:00:59 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 17:00:59 -0000 Received: by mail-ee0-f45.google.com with SMTP id b47so3457021eek.32 for ; Tue, 02 Oct 2012 10:00:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=dz5NzsQSfMF72+O38LIv63kOVyCAQq0RLZRmbTPl2SE=; b=NOlYn+rz+obDpCNoaX2B6R3UQm1D3xJMc7RwFoZ9m4d/rcYBu6bShzVaArVzkOPFHo y3oMY29RyIcp8DqixN1r9D4AwHBMGQksARvwsG4dFbhsVXikDlSengAiij1Vu8n/B+NA j6EVIjjrCDIr0xTpenFYSB8AtHTfbJs7T4piNUq+TUM659BQAnJNtsBd6Z6jjjRaW1Wt pA9VDwNFfUSZtAOPhHC49QLHoSypfXX1RhJD0CjSQaBKYD575sWvMORllL99b6KVCxbJ 61sXvMMZMkhJW6xSryiOilBPJcXFbVS2M7yb/59K/A9lwgKW3uhiG7zIW8FEfF8Yer/r TiTQ== Received: by 10.14.223.4 with SMTP id u4mr10207503eep.19.1349197259068; Tue, 02 Oct 2012 10:00:59 -0700 (PDT) Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com. [86.183.156.141]) by mx.google.com with ESMTPS id 9sm5084770eei.12.2012.10.02.10.00.57 (version=SSLv3 cipher=OTHER); Tue, 02 Oct 2012 10:00:58 -0700 (PDT) User-Agent: Microsoft-Entourage/12.34.0.120813 Date: Tue, 02 Oct 2012 18:00:55 +0100 From: Keir Fraser To: Jan Beulich , xen-devel Message-ID: Thread-Topic: [Xen-devel] [PATCH] VT-d: make remap_entry_to_msi_msg() return consistent message Thread-Index: Ac2gv3xn4qhANMkRbUWGNGXlPJM5SQ== In-Reply-To: <506B1C6E020000780009F221@nat28.tlf.novell.com> Mime-version: 1.0 Subject: Re: [Xen-devel] [PATCH] VT-d: make remap_entry_to_msi_msg() return consistent message X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 02/10/2012 15:55, "Jan Beulich" wrote: > During debugging of another problem I found that in x2APIC mode, the > destination field of the low address value wasn't passed back > correctly. While this is benign in most cases (as the value isn't being > used anywhere), it can be confusing (and misguiding) when printing the > value read or when comparing it to the one previously passed into the > inverse function. > > Signed-off-by: Jan Beulich Acked-by: Keir Fraser > --- a/xen/drivers/passthrough/vtd/intremap.c > +++ b/xen/drivers/passthrough/vtd/intremap.c > @@ -504,7 +504,11 @@ static int remap_entry_to_msi_msg( > MSI_ADDR_REDIRECTION_CPU: > MSI_ADDR_REDIRECTION_LOWPRI); > if ( x2apic_enabled ) > + { > msg->dest32 = iremap_entry->lo.dst; > + msg->address_lo |= > + (iremap_entry->lo.dst & 0xff) << MSI_ADDR_DEST_ID_SHIFT; > + } > else > msg->address_lo |= > ((iremap_entry->lo.dst >> 8) & 0xff ) << MSI_ADDR_DEST_ID_SHIFT; > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 17:01:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 17:01:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5qr-0000v3-6i; Tue, 02 Oct 2012 17:01:45 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5qq-0000uj-Kj for xen-devel@lists.xen.org; Tue, 02 Oct 2012 17:01:44 +0000 Received: from [85.158.137.99:55158] by server-3.bemta-3.messagelabs.com id 3A/AE-25962-7FD1B605; Tue, 02 Oct 2012 17:01:43 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-10.tower-217.messagelabs.com!1349197303!19890856!1 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30513 invoked from network); 2 Oct 2012 17:01:43 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 17:01:43 -0000 Received: by eekb47 with SMTP id b47so3458002eek.32 for ; Tue, 02 Oct 2012 10:01:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=HLF5E1MpiZguOFyimgJYQjnddgYjEjsb6EauM8lJOpo=; b=FwV575Ivs3dgS1VugZINI3PQNf83onbu8kf96Ie3G3Z3uX/AItr78ZyQiAJi+Pu38s J75ZCaMhTrsmk65Y4CO7BRKZ4nI331hQHMiNbNss9XfhWu0IYvym7V8yttnTnNF8i65E VkRhx/XoF67TSpdebZQYT+ymL3v4GJoGlEtJ9/VX6+qqemxn4gehBCHoqpBm4vF2qXYx o5qjdypTez1Ha3EvVd/wBIj+DogsAj8wDvfeDPs0Lgr0v7A7GXwGlwOIIdwAR0T2Qtgl +yzZnD95LRhEHONOI2pFcPY9BS9OkhAPKGBKUf47lURp7TNkGLWgrFlMgVOCtgt80pnP wUmg== Received: by 10.14.203.73 with SMTP id e49mr23137318eeo.27.1349197303033; Tue, 02 Oct 2012 10:01:43 -0700 (PDT) Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com. [86.183.156.141]) by mx.google.com with ESMTPS id u47sm5104477eeo.9.2012.10.02.10.01.33 (version=SSLv3 cipher=OTHER); Tue, 02 Oct 2012 10:01:42 -0700 (PDT) User-Agent: Microsoft-Entourage/12.34.0.120813 Date: Tue, 02 Oct 2012 18:01:25 +0100 From: Keir Fraser To: Jan Beulich , xen-devel Message-ID: Thread-Topic: [Xen-devel] [PATCH 1/3] x86: use MOV instead of PUSH/POP when saving/restoring register state Thread-Index: Ac2gv45JEvACPRqi6UGi6YjsWSmKdA== In-Reply-To: <506B23BF020000780009F29A@nat28.tlf.novell.com> Mime-version: 1.0 Subject: Re: [Xen-devel] [PATCH 1/3] x86: use MOV instead of PUSH/POP when saving/restoring register state X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 02/10/2012 16:26, "Jan Beulich" wrote: > Signed-off-by: Jan Beulich Acked-by: Keir Fraser _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 17:01:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 17:01:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5qr-0000v3-6i; Tue, 02 Oct 2012 17:01:45 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5qq-0000uj-Kj for xen-devel@lists.xen.org; Tue, 02 Oct 2012 17:01:44 +0000 Received: from [85.158.137.99:55158] by server-3.bemta-3.messagelabs.com id 3A/AE-25962-7FD1B605; Tue, 02 Oct 2012 17:01:43 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-10.tower-217.messagelabs.com!1349197303!19890856!1 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30513 invoked from network); 2 Oct 2012 17:01:43 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 17:01:43 -0000 Received: by eekb47 with SMTP id b47so3458002eek.32 for ; Tue, 02 Oct 2012 10:01:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=HLF5E1MpiZguOFyimgJYQjnddgYjEjsb6EauM8lJOpo=; b=FwV575Ivs3dgS1VugZINI3PQNf83onbu8kf96Ie3G3Z3uX/AItr78ZyQiAJi+Pu38s J75ZCaMhTrsmk65Y4CO7BRKZ4nI331hQHMiNbNss9XfhWu0IYvym7V8yttnTnNF8i65E VkRhx/XoF67TSpdebZQYT+ymL3v4GJoGlEtJ9/VX6+qqemxn4gehBCHoqpBm4vF2qXYx o5qjdypTez1Ha3EvVd/wBIj+DogsAj8wDvfeDPs0Lgr0v7A7GXwGlwOIIdwAR0T2Qtgl +yzZnD95LRhEHONOI2pFcPY9BS9OkhAPKGBKUf47lURp7TNkGLWgrFlMgVOCtgt80pnP wUmg== Received: by 10.14.203.73 with SMTP id e49mr23137318eeo.27.1349197303033; Tue, 02 Oct 2012 10:01:43 -0700 (PDT) Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com. [86.183.156.141]) by mx.google.com with ESMTPS id u47sm5104477eeo.9.2012.10.02.10.01.33 (version=SSLv3 cipher=OTHER); Tue, 02 Oct 2012 10:01:42 -0700 (PDT) User-Agent: Microsoft-Entourage/12.34.0.120813 Date: Tue, 02 Oct 2012 18:01:25 +0100 From: Keir Fraser To: Jan Beulich , xen-devel Message-ID: Thread-Topic: [Xen-devel] [PATCH 1/3] x86: use MOV instead of PUSH/POP when saving/restoring register state Thread-Index: Ac2gv45JEvACPRqi6UGi6YjsWSmKdA== In-Reply-To: <506B23BF020000780009F29A@nat28.tlf.novell.com> Mime-version: 1.0 Subject: Re: [Xen-devel] [PATCH 1/3] x86: use MOV instead of PUSH/POP when saving/restoring register state X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 02/10/2012 16:26, "Jan Beulich" wrote: > Signed-off-by: Jan Beulich Acked-by: Keir Fraser _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 17:02:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 17:02:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5rA-0000z8-Ka; Tue, 02 Oct 2012 17:02:04 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5r9-0000yf-0P for xen-devel@lists.xen.org; Tue, 02 Oct 2012 17:02:03 +0000 Received: from [85.158.137.99:5292] by server-4.bemta-3.messagelabs.com id B0/56-14155-A0E1B605; Tue, 02 Oct 2012 17:02:02 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-10.tower-217.messagelabs.com!1349197303!19890856!2 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31706 invoked from network); 2 Oct 2012 17:02:01 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 17:02:01 -0000 Received: by mail-ee0-f45.google.com with SMTP id b47so3458002eek.32 for ; Tue, 02 Oct 2012 10:02:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=g5B9pjed4xceLiOPh1M4NjkTcE+W7kWF2+zoIPsiWFU=; b=xoAUpC+E96EWXSeYxmdZlf75yTaRP1U6FFmSlygM8B3kQqyZ0kHMUu5QJDbcQuFVEj U6xlCQLSs/7nuCgsAWB7W0cIj8zGWxtEsBMVD0q+Im4bQ6H8J7o/yZs75cF5CPiNhazD P6raLyD3mtsKMsBNe99CGjD9u1JLgmHYPK92hrJmOzcNzQQrO4oKgdC/4lNxDTgskEFk dXscoyh6z4OCck/4AACB6N/JSDcRAbSL9JRluJiKZNdjjTe1MkP7XOx6RheD8QEHKeQL OPqXSfBzSg/vepwyklYpESbK5MqKvSWxJKSzL3/t6IXdWVJZeh5WiZP8gs+EOZ+djGcq CZag== Received: by 10.14.184.133 with SMTP id s5mr23232961eem.31.1349197321723; Tue, 02 Oct 2012 10:02:01 -0700 (PDT) Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com. [86.183.156.141]) by mx.google.com with ESMTPS id x42sm2471540eel.11.2012.10.02.10.01.54 (version=SSLv3 cipher=OTHER); Tue, 02 Oct 2012 10:02:01 -0700 (PDT) User-Agent: Microsoft-Entourage/12.34.0.120813 Date: Tue, 02 Oct 2012 18:01:45 +0100 From: Keir Fraser To: Jan Beulich , xen-devel Message-ID: Thread-Topic: [Xen-devel] [PATCH 2/3] x86: consolidate frame state manipulation functions Thread-Index: Ac2gv5o1VdwPNzGcnEe2H5mhW45xgg== In-Reply-To: <506B23DF020000780009F29E@nat28.tlf.novell.com> Mime-version: 1.0 Subject: Re: [Xen-devel] [PATCH 2/3] x86: consolidate frame state manipulation functions X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 02/10/2012 16:26, "Jan Beulich" wrote: > Rather than doing this in multiple places, have a single central > function (decode_register()) to be used by all other code. > > Signed-off-by: Jan Beulich Acked-by: Keir Fraser _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 17:02:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 17:02:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5rA-0000z8-Ka; Tue, 02 Oct 2012 17:02:04 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5r9-0000yf-0P for xen-devel@lists.xen.org; Tue, 02 Oct 2012 17:02:03 +0000 Received: from [85.158.137.99:5292] by server-4.bemta-3.messagelabs.com id B0/56-14155-A0E1B605; Tue, 02 Oct 2012 17:02:02 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-10.tower-217.messagelabs.com!1349197303!19890856!2 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31706 invoked from network); 2 Oct 2012 17:02:01 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 17:02:01 -0000 Received: by mail-ee0-f45.google.com with SMTP id b47so3458002eek.32 for ; Tue, 02 Oct 2012 10:02:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=g5B9pjed4xceLiOPh1M4NjkTcE+W7kWF2+zoIPsiWFU=; b=xoAUpC+E96EWXSeYxmdZlf75yTaRP1U6FFmSlygM8B3kQqyZ0kHMUu5QJDbcQuFVEj U6xlCQLSs/7nuCgsAWB7W0cIj8zGWxtEsBMVD0q+Im4bQ6H8J7o/yZs75cF5CPiNhazD P6raLyD3mtsKMsBNe99CGjD9u1JLgmHYPK92hrJmOzcNzQQrO4oKgdC/4lNxDTgskEFk dXscoyh6z4OCck/4AACB6N/JSDcRAbSL9JRluJiKZNdjjTe1MkP7XOx6RheD8QEHKeQL OPqXSfBzSg/vepwyklYpESbK5MqKvSWxJKSzL3/t6IXdWVJZeh5WiZP8gs+EOZ+djGcq CZag== Received: by 10.14.184.133 with SMTP id s5mr23232961eem.31.1349197321723; Tue, 02 Oct 2012 10:02:01 -0700 (PDT) Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com. [86.183.156.141]) by mx.google.com with ESMTPS id x42sm2471540eel.11.2012.10.02.10.01.54 (version=SSLv3 cipher=OTHER); Tue, 02 Oct 2012 10:02:01 -0700 (PDT) User-Agent: Microsoft-Entourage/12.34.0.120813 Date: Tue, 02 Oct 2012 18:01:45 +0100 From: Keir Fraser To: Jan Beulich , xen-devel Message-ID: Thread-Topic: [Xen-devel] [PATCH 2/3] x86: consolidate frame state manipulation functions Thread-Index: Ac2gv5o1VdwPNzGcnEe2H5mhW45xgg== In-Reply-To: <506B23DF020000780009F29E@nat28.tlf.novell.com> Mime-version: 1.0 Subject: Re: [Xen-devel] [PATCH 2/3] x86: consolidate frame state manipulation functions X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 02/10/2012 16:26, "Jan Beulich" wrote: > Rather than doing this in multiple places, have a single central > function (decode_register()) to be used by all other code. > > Signed-off-by: Jan Beulich Acked-by: Keir Fraser _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 17:02:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 17:02:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5rm-00017i-1u; Tue, 02 Oct 2012 17:02:42 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5rk-000173-3W for xen-devel@lists.xen.org; Tue, 02 Oct 2012 17:02:40 +0000 Received: from [85.158.137.99:6720] by server-12.bemta-3.messagelabs.com id EE/A0-23730-F2E1B605; Tue, 02 Oct 2012 17:02:39 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-11.tower-217.messagelabs.com!1349197358!18798822!1 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20839 invoked from network); 2 Oct 2012 17:02:38 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 17:02:38 -0000 Received: by eekb47 with SMTP id b47so3458787eek.32 for ; Tue, 02 Oct 2012 10:02:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=aJk2O7gAhshy015OCT/rhiuTN0bq8L/54v1JL8gU1SE=; b=Vg5FDs9eKSH+nGCoHT3SIgK+w5+EcStsD8piiJUATs7SWuTP+T2/wVkQHXjdptxpRt 5P/jzUrGzqF3jgQhRf4oALwdDyaCVOxTi1IkJsbSb7ZkZ4Ezot+TVb/aK1i8n06+08NK u8MvfT6m4Bpgc2MBIxzFmmTo4VMPZd/KzQslk4R7Z6KeEXgjaE6znrR4g9OHFb3Q/Ex1 jemOnevIEThO8erslguldunZpIx0cv7VxdhzIHebkmlVsSv4B6gF9aWQUnPwJJeHUDPJ 9gjLcRDNyWJMTJXLCU4n9RWsVo5qDMm8aghXSYx7CHNaqx4OXigtLw8qUnEQPjuiZVVC rHVg== Received: by 10.14.200.134 with SMTP id z6mr21094197een.33.1349197358604; Tue, 02 Oct 2012 10:02:38 -0700 (PDT) Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com. [86.183.156.141]) by mx.google.com with ESMTPS id z3sm5081593eel.15.2012.10.02.10.02.36 (version=SSLv3 cipher=OTHER); Tue, 02 Oct 2012 10:02:38 -0700 (PDT) User-Agent: Microsoft-Entourage/12.34.0.120813 Date: Tue, 02 Oct 2012 18:02:31 +0100 From: Keir Fraser To: Jan Beulich , xen-devel Message-ID: Thread-Topic: [Xen-devel] [PATCH 3/3] x86: save/restore only partial register state where possible Thread-Index: Ac2gv7Wg1B8+k87pIkqlr4SJ15pQXw== In-Reply-To: <506B2410020000780009F2A3@nat28.tlf.novell.com> Mime-version: 1.0 Subject: Re: [Xen-devel] [PATCH 3/3] x86: save/restore only partial register state where possible X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 02/10/2012 16:27, "Jan Beulich" wrote: > ... and make restore conditional not only upon having saved the state, > but also upon whether saved state was actually modified (and register > values are known to have been preserved). > > Note that RBP is unconditionally considered a volatile register (i.e. > irrespective of CONFIG_FRAME_POINTER), since the RBP handling would > become overly complicated due to the need to save/restore it on the > compat mode hypercall path [6th argument]. > > Note further that for compat mode code paths, saving/restoring R8...R15 > is entirely unnecessary - we don't allow those guests to enter 64-bit > mode, and hence they have no way of seeing these registers' contents > (and there consequently also is no information leak, except if the > context saving domctl would be considered such). > > Finally, note that this may not properly deal with gdbstub's needs, yet > (but if so, I can't really suggest adjustments, as I don't know that > code). > > Signed-off-by: Jan Beulich Ugly. I'd prefer not to bother unless there really is a win we could care about here. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 17:02:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 17:02:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5rm-00017i-1u; Tue, 02 Oct 2012 17:02:42 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5rk-000173-3W for xen-devel@lists.xen.org; Tue, 02 Oct 2012 17:02:40 +0000 Received: from [85.158.137.99:6720] by server-12.bemta-3.messagelabs.com id EE/A0-23730-F2E1B605; Tue, 02 Oct 2012 17:02:39 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-11.tower-217.messagelabs.com!1349197358!18798822!1 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20839 invoked from network); 2 Oct 2012 17:02:38 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 17:02:38 -0000 Received: by eekb47 with SMTP id b47so3458787eek.32 for ; Tue, 02 Oct 2012 10:02:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=aJk2O7gAhshy015OCT/rhiuTN0bq8L/54v1JL8gU1SE=; b=Vg5FDs9eKSH+nGCoHT3SIgK+w5+EcStsD8piiJUATs7SWuTP+T2/wVkQHXjdptxpRt 5P/jzUrGzqF3jgQhRf4oALwdDyaCVOxTi1IkJsbSb7ZkZ4Ezot+TVb/aK1i8n06+08NK u8MvfT6m4Bpgc2MBIxzFmmTo4VMPZd/KzQslk4R7Z6KeEXgjaE6znrR4g9OHFb3Q/Ex1 jemOnevIEThO8erslguldunZpIx0cv7VxdhzIHebkmlVsSv4B6gF9aWQUnPwJJeHUDPJ 9gjLcRDNyWJMTJXLCU4n9RWsVo5qDMm8aghXSYx7CHNaqx4OXigtLw8qUnEQPjuiZVVC rHVg== Received: by 10.14.200.134 with SMTP id z6mr21094197een.33.1349197358604; Tue, 02 Oct 2012 10:02:38 -0700 (PDT) Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com. [86.183.156.141]) by mx.google.com with ESMTPS id z3sm5081593eel.15.2012.10.02.10.02.36 (version=SSLv3 cipher=OTHER); Tue, 02 Oct 2012 10:02:38 -0700 (PDT) User-Agent: Microsoft-Entourage/12.34.0.120813 Date: Tue, 02 Oct 2012 18:02:31 +0100 From: Keir Fraser To: Jan Beulich , xen-devel Message-ID: Thread-Topic: [Xen-devel] [PATCH 3/3] x86: save/restore only partial register state where possible Thread-Index: Ac2gv7Wg1B8+k87pIkqlr4SJ15pQXw== In-Reply-To: <506B2410020000780009F2A3@nat28.tlf.novell.com> Mime-version: 1.0 Subject: Re: [Xen-devel] [PATCH 3/3] x86: save/restore only partial register state where possible X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 02/10/2012 16:27, "Jan Beulich" wrote: > ... and make restore conditional not only upon having saved the state, > but also upon whether saved state was actually modified (and register > values are known to have been preserved). > > Note that RBP is unconditionally considered a volatile register (i.e. > irrespective of CONFIG_FRAME_POINTER), since the RBP handling would > become overly complicated due to the need to save/restore it on the > compat mode hypercall path [6th argument]. > > Note further that for compat mode code paths, saving/restoring R8...R15 > is entirely unnecessary - we don't allow those guests to enter 64-bit > mode, and hence they have no way of seeing these registers' contents > (and there consequently also is no information leak, except if the > context saving domctl would be considered such). > > Finally, note that this may not properly deal with gdbstub's needs, yet > (but if so, I can't really suggest adjustments, as I don't know that > code). > > Signed-off-by: Jan Beulich Ugly. I'd prefer not to bother unless there really is a win we could care about here. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 17:07:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 17:07:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5w0-0001dE-P3; Tue, 02 Oct 2012 17:07:04 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5vz-0001d6-2E for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 17:07:03 +0000 Received: from [85.158.137.99:28567] by server-2.bemta-3.messagelabs.com id AB/B0-16514-63F1B605; Tue, 02 Oct 2012 17:07:02 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-6.tower-217.messagelabs.com!1349197620!14865606!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzkyODg=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11087 invoked from network); 2 Oct 2012 17:07:01 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 17:07:01 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="210047159" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 17:06:45 +0000 Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 13:06:45 -0400 Message-ID: <506B1F23.105@citrix.com> Date: Tue, 2 Oct 2012 18:06:43 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120428 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: George Dunlap References: <1349113629-6338-1-git-send-email-david.vrabel@citrix.com> <1349113629-6338-3-git-send-email-david.vrabel@citrix.com> In-Reply-To: Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 2/3] trace: improve usefulness of hypercall trace record X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 02/10/12 17:09, George Dunlap wrote: > On Mon, Oct 1, 2012 at 6:47 PM, David Vrabel wrote: >> From: David Vrabel >> >> Trace hypercalls using a more useful trace record format. >> >> The EIP field is removed (it was always somewhere in the hypercall >> page) and include selected hypercall arguments (e.g., the number of >> calls in a multicall, and the number of PTE updates in an mmu_update >> etc.). 12 bits in the first extra word are used to indicate which >> arguments are present in the record and what size they are (32 or >> 64-bit). >> >> This is an incompatible record format so a new event ID is used so >> tools can distinguish between the two formats. >> >> Signed-off-by: David Vrabel >> Acked-by: George Dunlap > > Looking at it again, I do have one comment (see below) -- so I guess > that would be technically withdrawing the Ack until we sort it out. > >> diff --git a/xen/arch/x86/trace.c b/xen/arch/x86/trace.c >> index 27fe150..f2c75bc 100644 >> --- a/xen/arch/x86/trace.c >> +++ b/xen/arch/x86/trace.c >> @@ -9,33 +9,28 @@ >> void trace_hypercall(void) > > In most places, "trace_*" means "Call unconditionally; inside it will > check tb_init_done", while "__trace_*" means, "I have already checked > that tb_init_done is set, don't bother checking it." This isn't something that this patch changes but I'll add a new patch to change this since it's a trivial change. >> + switch ( op ) >> + { >> + case __HYPERVISOR_mmu_update: >> + APPEND_ARG32(1); /* count */ >> + break; >> + case __HYPERVISOR_multicall: >> + APPEND_ARG32(1); /* count */ >> + break; >> + case __HYPERVISOR_grant_table_op: >> + APPEND_ARG32(0); /* cmd */ >> + APPEND_ARG32(2); /* count */ >> + break; >> + case __HYPERVISOR_vcpu_op: >> + APPEND_ARG32(0); /* cmd */ >> + APPEND_ARG32(1); /* vcpuid */ >> + break; >> + case __HYPERVISOR_mmuext_op: >> + APPEND_ARG32(1); /* count */ >> + break; >> + case __HYPERVISOR_sched_op: >> + APPEND_ARG32(0); /* cmd */ >> + break; >> + } > > I may have commented on this before -- I wonder if doing some kind of > array might be better than a big switch statement. I think with only > a few hypercalls, a switch statement is probably acceptable; but as we > add more, the code is going to get bloated. I'll see what I can come up with. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 17:07:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 17:07:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5w0-0001dE-P3; Tue, 02 Oct 2012 17:07:04 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ5vz-0001d6-2E for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 17:07:03 +0000 Received: from [85.158.137.99:28567] by server-2.bemta-3.messagelabs.com id AB/B0-16514-63F1B605; Tue, 02 Oct 2012 17:07:02 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-6.tower-217.messagelabs.com!1349197620!14865606!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzkyODg=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11087 invoked from network); 2 Oct 2012 17:07:01 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 17:07:01 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="210047159" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 17:06:45 +0000 Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 13:06:45 -0400 Message-ID: <506B1F23.105@citrix.com> Date: Tue, 2 Oct 2012 18:06:43 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120428 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: George Dunlap References: <1349113629-6338-1-git-send-email-david.vrabel@citrix.com> <1349113629-6338-3-git-send-email-david.vrabel@citrix.com> In-Reply-To: Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 2/3] trace: improve usefulness of hypercall trace record X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 02/10/12 17:09, George Dunlap wrote: > On Mon, Oct 1, 2012 at 6:47 PM, David Vrabel wrote: >> From: David Vrabel >> >> Trace hypercalls using a more useful trace record format. >> >> The EIP field is removed (it was always somewhere in the hypercall >> page) and include selected hypercall arguments (e.g., the number of >> calls in a multicall, and the number of PTE updates in an mmu_update >> etc.). 12 bits in the first extra word are used to indicate which >> arguments are present in the record and what size they are (32 or >> 64-bit). >> >> This is an incompatible record format so a new event ID is used so >> tools can distinguish between the two formats. >> >> Signed-off-by: David Vrabel >> Acked-by: George Dunlap > > Looking at it again, I do have one comment (see below) -- so I guess > that would be technically withdrawing the Ack until we sort it out. > >> diff --git a/xen/arch/x86/trace.c b/xen/arch/x86/trace.c >> index 27fe150..f2c75bc 100644 >> --- a/xen/arch/x86/trace.c >> +++ b/xen/arch/x86/trace.c >> @@ -9,33 +9,28 @@ >> void trace_hypercall(void) > > In most places, "trace_*" means "Call unconditionally; inside it will > check tb_init_done", while "__trace_*" means, "I have already checked > that tb_init_done is set, don't bother checking it." This isn't something that this patch changes but I'll add a new patch to change this since it's a trivial change. >> + switch ( op ) >> + { >> + case __HYPERVISOR_mmu_update: >> + APPEND_ARG32(1); /* count */ >> + break; >> + case __HYPERVISOR_multicall: >> + APPEND_ARG32(1); /* count */ >> + break; >> + case __HYPERVISOR_grant_table_op: >> + APPEND_ARG32(0); /* cmd */ >> + APPEND_ARG32(2); /* count */ >> + break; >> + case __HYPERVISOR_vcpu_op: >> + APPEND_ARG32(0); /* cmd */ >> + APPEND_ARG32(1); /* vcpuid */ >> + break; >> + case __HYPERVISOR_mmuext_op: >> + APPEND_ARG32(1); /* count */ >> + break; >> + case __HYPERVISOR_sched_op: >> + APPEND_ARG32(0); /* cmd */ >> + break; >> + } > > I may have commented on this before -- I wonder if doing some kind of > array might be better than a big switch statement. I think with only > a few hypercalls, a switch statement is probably acceptable; but as we > add more, the code is going to get bloated. I'll see what I can come up with. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 17:31:24 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 17:31:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ6JF-0002E3-4d; Tue, 02 Oct 2012 17:31:05 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ6JD-0002Ds-QM for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 17:31:04 +0000 Received: from [85.158.143.35:63288] by server-2.bemta-4.messagelabs.com id 5F/DF-06610-7D42B605; Tue, 02 Oct 2012 17:31:03 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1349199061!17193571!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11818 invoked from network); 2 Oct 2012 17:31:02 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 17:31:02 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="14900514" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 17:30:31 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 18:30:31 +0100 Date: Tue, 2 Oct 2012 18:29:32 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Konrad Rzeszutek Wilk Message-ID: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: Stephen Rothwell , xen-devel@lists.xensource.com, Stefano Stabellini , linux-kernel@vger.kernel.org, linux-next@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: [Xen-devel] [PATCH] xen: resolve merge conflict with 617276307cd4cdb9a95c77efaa3063695af63aa7 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org The Xen tree tries to add a line to arch/arm/mach-vexpress/Makefile.boot that has been removed by the following commit in Linus' master: commit 617276307cd4cdb9a95c77efaa3063695af63aa7 Author: Rob Herring Date: Thu Sep 6 13:43:04 2012 -0500 ARM: vexpress: convert to multi-platform In fact the dts Makefile is now arch/arm/boot/dts/Makefile, as per commit 9cd11c0c47b8690b47e7573311ce5c483cb344ed. This is the merge resolution patch. Signed-off-by: Stefano Stabellini diff --cc arch/arm/boot/dts/Makefile index 43c084c,0000000..4745c1f mode 100644,000000..100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@@ -1,101 -1,0 +1,102 @@@ +ifeq ($(CONFIG_OF),y) + +dtb-$(CONFIG_ARCH_AT91) += aks-cdu.dtb \ + at91sam9263ek.dtb \ + at91sam9g20ek_2mmc.dtb \ + at91sam9g20ek.dtb \ + at91sam9g25ek.dtb \ + at91sam9m10g45ek.dtb \ + at91sam9n12ek.dtb \ + ethernut5.dtb \ + evk-pro3.dtb \ + kizbox.dtb \ + tny_a9260.dtb \ + tny_a9263.dtb \ + tny_a9g20.dtb \ + usb_a9260.dtb \ + usb_a9263.dtb \ + usb_a9g20.dtb +dtb-$(CONFIG_ARCH_BCM2835) += bcm2835-rpi-b.dtb +dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \ + exynos4210-smdkv310.dtb \ + exynos4210-trats.dtb \ + exynos5250-smdk5250.dtb +dtb-$(CONFIG_ARCH_HIGHBANK) += highbank.dtb +dtb-$(CONFIG_ARCH_IMX5) += imx51-babbage.dtb \ + imx53-ard.dtb \ + imx53-evk.dtb \ + imx53-qsb.dtb \ + imx53-smd.dtb +dtb-$(CONFIG_SOC_IMX6Q) += imx6q-arm2.dtb \ + imx6q-sabrelite.dtb \ + imx6q-sabresd.dtb +dtb-$(CONFIG_ARCH_LPC32XX) += ea3250.dtb phy3250.dtb +dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-dns320.dtb \ + kirkwood-dns325.dtb \ + kirkwood-dreamplug.dtb \ + kirkwood-goflexnet.dtb \ + kirkwood-ib62x0.dtb \ + kirkwood-iconnect.dtb \ + kirkwood-lschlv2.dtb \ + kirkwood-lsxhl.dtb \ + kirkwood-ts219-6281.dtb \ + kirkwood-ts219-6282.dtb +dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \ + msm8960-cdp.dtb +dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \ + armada-xp-db.dtb +dtb-$(CONFIG_ARCH_MXC) += imx51-babbage.dtb \ + imx53-ard.dtb \ + imx53-evk.dtb \ + imx53-qsb.dtb \ + imx53-smd.dtb \ + imx6q-arm2.dtb \ + imx6q-sabrelite.dtb \ + imx6q-sabresd.dtb +dtb-$(CONFIG_ARCH_MXS) += imx23-evk.dtb \ + imx23-olinuxino.dtb \ + imx23-stmp378x_devb.dtb \ + imx28-apx4devkit.dtb \ + imx28-cfa10036.dtb \ + imx28-cfa10049.dtb \ + imx28-evk.dtb \ + imx28-m28evk.dtb \ + imx28-tx28.dtb +dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \ + omap3-beagle-xm.dtb \ + omap3-evm.dtb \ + omap3-tobi.dtb \ + omap4-panda.dtb \ + omap4-pandaES.dtb \ + omap4-var_som.dtb \ + omap4-sdp.dtb \ + omap5-evm.dtb +dtb-$(CONFIG_ARCH_PRIMA2) += prima2-evb.dtb +dtb-$(CONFIG_ARCH_U8500) += snowball.dtb +dtb-$(CONFIG_ARCH_SHMOBILE) += emev2-kzm9d.dtb \ + r8a7740-armadillo800eva.dtb \ + sh73a0-kzm9g.dtb +dtb-$(CONFIG_ARCH_SPEAR13XX) += spear1310-evb.dtb \ + spear1340-evb.dtb +dtb-$(CONFIG_ARCH_SPEAR3XX)+= spear300-evb.dtb \ + spear310-evb.dtb \ + spear320-evb.dtb +dtb-$(CONFIG_ARCH_SPEAR6XX)+= spear600-evb.dtb +dtb-$(CONFIG_ARCH_TEGRA) += tegra20-harmony.dtb \ + tegra20-medcom-wide.dtb \ + tegra20-paz00.dtb \ + tegra20-plutux.dtb \ + tegra20-seaboard.dtb \ + tegra20-tec.dtb \ + tegra20-trimslice.dtb \ + tegra20-ventana.dtb \ + tegra20-whistler.dtb \ + tegra30-cardhu-a02.dtb \ + tegra30-cardhu-a04.dtb +dtb-$(CONFIG_ARCH_VEXPRESS) += vexpress-v2p-ca5s.dtb \ + vexpress-v2p-ca9.dtb \ + vexpress-v2p-ca15-tc1.dtb \ - vexpress-v2p-ca15_a7.dtb ++ vexpress-v2p-ca15_a7.dtb \ ++ xenvm-4.2.dtb + +endif _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 17:31:24 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 17:31:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ6JF-0002E3-4d; Tue, 02 Oct 2012 17:31:05 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ6JD-0002Ds-QM for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 17:31:04 +0000 Received: from [85.158.143.35:63288] by server-2.bemta-4.messagelabs.com id 5F/DF-06610-7D42B605; Tue, 02 Oct 2012 17:31:03 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1349199061!17193571!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11818 invoked from network); 2 Oct 2012 17:31:02 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 17:31:02 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="14900514" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 17:30:31 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 18:30:31 +0100 Date: Tue, 2 Oct 2012 18:29:32 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Konrad Rzeszutek Wilk Message-ID: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: Stephen Rothwell , xen-devel@lists.xensource.com, Stefano Stabellini , linux-kernel@vger.kernel.org, linux-next@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: [Xen-devel] [PATCH] xen: resolve merge conflict with 617276307cd4cdb9a95c77efaa3063695af63aa7 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org The Xen tree tries to add a line to arch/arm/mach-vexpress/Makefile.boot that has been removed by the following commit in Linus' master: commit 617276307cd4cdb9a95c77efaa3063695af63aa7 Author: Rob Herring Date: Thu Sep 6 13:43:04 2012 -0500 ARM: vexpress: convert to multi-platform In fact the dts Makefile is now arch/arm/boot/dts/Makefile, as per commit 9cd11c0c47b8690b47e7573311ce5c483cb344ed. This is the merge resolution patch. Signed-off-by: Stefano Stabellini diff --cc arch/arm/boot/dts/Makefile index 43c084c,0000000..4745c1f mode 100644,000000..100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@@ -1,101 -1,0 +1,102 @@@ +ifeq ($(CONFIG_OF),y) + +dtb-$(CONFIG_ARCH_AT91) += aks-cdu.dtb \ + at91sam9263ek.dtb \ + at91sam9g20ek_2mmc.dtb \ + at91sam9g20ek.dtb \ + at91sam9g25ek.dtb \ + at91sam9m10g45ek.dtb \ + at91sam9n12ek.dtb \ + ethernut5.dtb \ + evk-pro3.dtb \ + kizbox.dtb \ + tny_a9260.dtb \ + tny_a9263.dtb \ + tny_a9g20.dtb \ + usb_a9260.dtb \ + usb_a9263.dtb \ + usb_a9g20.dtb +dtb-$(CONFIG_ARCH_BCM2835) += bcm2835-rpi-b.dtb +dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \ + exynos4210-smdkv310.dtb \ + exynos4210-trats.dtb \ + exynos5250-smdk5250.dtb +dtb-$(CONFIG_ARCH_HIGHBANK) += highbank.dtb +dtb-$(CONFIG_ARCH_IMX5) += imx51-babbage.dtb \ + imx53-ard.dtb \ + imx53-evk.dtb \ + imx53-qsb.dtb \ + imx53-smd.dtb +dtb-$(CONFIG_SOC_IMX6Q) += imx6q-arm2.dtb \ + imx6q-sabrelite.dtb \ + imx6q-sabresd.dtb +dtb-$(CONFIG_ARCH_LPC32XX) += ea3250.dtb phy3250.dtb +dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-dns320.dtb \ + kirkwood-dns325.dtb \ + kirkwood-dreamplug.dtb \ + kirkwood-goflexnet.dtb \ + kirkwood-ib62x0.dtb \ + kirkwood-iconnect.dtb \ + kirkwood-lschlv2.dtb \ + kirkwood-lsxhl.dtb \ + kirkwood-ts219-6281.dtb \ + kirkwood-ts219-6282.dtb +dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \ + msm8960-cdp.dtb +dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \ + armada-xp-db.dtb +dtb-$(CONFIG_ARCH_MXC) += imx51-babbage.dtb \ + imx53-ard.dtb \ + imx53-evk.dtb \ + imx53-qsb.dtb \ + imx53-smd.dtb \ + imx6q-arm2.dtb \ + imx6q-sabrelite.dtb \ + imx6q-sabresd.dtb +dtb-$(CONFIG_ARCH_MXS) += imx23-evk.dtb \ + imx23-olinuxino.dtb \ + imx23-stmp378x_devb.dtb \ + imx28-apx4devkit.dtb \ + imx28-cfa10036.dtb \ + imx28-cfa10049.dtb \ + imx28-evk.dtb \ + imx28-m28evk.dtb \ + imx28-tx28.dtb +dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \ + omap3-beagle-xm.dtb \ + omap3-evm.dtb \ + omap3-tobi.dtb \ + omap4-panda.dtb \ + omap4-pandaES.dtb \ + omap4-var_som.dtb \ + omap4-sdp.dtb \ + omap5-evm.dtb +dtb-$(CONFIG_ARCH_PRIMA2) += prima2-evb.dtb +dtb-$(CONFIG_ARCH_U8500) += snowball.dtb +dtb-$(CONFIG_ARCH_SHMOBILE) += emev2-kzm9d.dtb \ + r8a7740-armadillo800eva.dtb \ + sh73a0-kzm9g.dtb +dtb-$(CONFIG_ARCH_SPEAR13XX) += spear1310-evb.dtb \ + spear1340-evb.dtb +dtb-$(CONFIG_ARCH_SPEAR3XX)+= spear300-evb.dtb \ + spear310-evb.dtb \ + spear320-evb.dtb +dtb-$(CONFIG_ARCH_SPEAR6XX)+= spear600-evb.dtb +dtb-$(CONFIG_ARCH_TEGRA) += tegra20-harmony.dtb \ + tegra20-medcom-wide.dtb \ + tegra20-paz00.dtb \ + tegra20-plutux.dtb \ + tegra20-seaboard.dtb \ + tegra20-tec.dtb \ + tegra20-trimslice.dtb \ + tegra20-ventana.dtb \ + tegra20-whistler.dtb \ + tegra30-cardhu-a02.dtb \ + tegra30-cardhu-a04.dtb +dtb-$(CONFIG_ARCH_VEXPRESS) += vexpress-v2p-ca5s.dtb \ + vexpress-v2p-ca9.dtb \ + vexpress-v2p-ca15-tc1.dtb \ - vexpress-v2p-ca15_a7.dtb ++ vexpress-v2p-ca15_a7.dtb \ ++ xenvm-4.2.dtb + +endif _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 17:34:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 17:34:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ6Mb-0002Zc-P0; Tue, 02 Oct 2012 17:34:33 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ6Ma-0002ZU-CF for xen-devel@lists.xen.org; Tue, 02 Oct 2012 17:34:32 +0000 Received: from [85.158.143.99:5217] by server-3.bemta-4.messagelabs.com id 51/B5-10986-7A52B605; Tue, 02 Oct 2012 17:34:31 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1349199269!26477531!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzc3NzIy\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8566 invoked from network); 2 Oct 2012 17:34:31 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 17:34:31 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q92HYMsS018877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Oct 2012 17:34:23 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q92HYLT6022349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Oct 2012 17:34:22 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q92HYLem028394; Tue, 2 Oct 2012 12:34:21 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 02 Oct 2012 10:34:21 -0700 Date: Tue, 2 Oct 2012 10:34:19 -0700 From: Mukesh Rathor To: George Dunlap Message-ID: <20121002103419.4e2db695@mantra.us.oracle.com> In-Reply-To: References: Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.3 development update X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2 Oct 2012 10:29:21 +0100 George Dunlap wrote: > On Mon, Oct 1, 2012 at 5:25 PM, George Dunlap > wrote: > > * PVH mode, domU (w/ Linux) > > owner: mukesh@oracle > > status: ? > > > > * PVH mode, dom0 (w/ Linux) > > owner: mukesh@oracle > > status: ? > > Mukesh, have the xen-side patches been posted yet? Any ETA on those? > > Thanks, > -George I had posted an informal patch few months ago. My xen tree is somewhat old now. So, as soon as I am done with linux patches, I'll refresh my xen tree, (I'm sure there'll be some debugging) test it out, and submit the patch ASAP. thanks, Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 17:34:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 17:34:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ6Mb-0002Zc-P0; Tue, 02 Oct 2012 17:34:33 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ6Ma-0002ZU-CF for xen-devel@lists.xen.org; Tue, 02 Oct 2012 17:34:32 +0000 Received: from [85.158.143.99:5217] by server-3.bemta-4.messagelabs.com id 51/B5-10986-7A52B605; Tue, 02 Oct 2012 17:34:31 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1349199269!26477531!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzc3NzIy\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8566 invoked from network); 2 Oct 2012 17:34:31 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 17:34:31 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q92HYMsS018877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Oct 2012 17:34:23 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q92HYLT6022349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Oct 2012 17:34:22 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q92HYLem028394; Tue, 2 Oct 2012 12:34:21 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 02 Oct 2012 10:34:21 -0700 Date: Tue, 2 Oct 2012 10:34:19 -0700 From: Mukesh Rathor To: George Dunlap Message-ID: <20121002103419.4e2db695@mantra.us.oracle.com> In-Reply-To: References: Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.3 development update X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2 Oct 2012 10:29:21 +0100 George Dunlap wrote: > On Mon, Oct 1, 2012 at 5:25 PM, George Dunlap > wrote: > > * PVH mode, domU (w/ Linux) > > owner: mukesh@oracle > > status: ? > > > > * PVH mode, dom0 (w/ Linux) > > owner: mukesh@oracle > > status: ? > > Mukesh, have the xen-side patches been posted yet? Any ETA on those? > > Thanks, > -George I had posted an informal patch few months ago. My xen tree is somewhat old now. So, as soon as I am done with linux patches, I'll refresh my xen tree, (I'm sure there'll be some debugging) test it out, and submit the patch ASAP. thanks, Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 18:09:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 18:09:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ6to-0003T7-Dj; Tue, 02 Oct 2012 18:08:52 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ6tl-0003Sz-SY for xen-devel@lists.xen.org; Tue, 02 Oct 2012 18:08:50 +0000 Received: from [85.158.138.51:25632] by server-14.bemta-3.messagelabs.com id AE/D5-25886-1BD2B605; Tue, 02 Oct 2012 18:08:49 +0000 X-Env-Sender: ketuzsezr@gmail.com X-Msg-Ref: server-16.tower-174.messagelabs.com!1349201326!32750310!1 X-Originating-IP: [209.85.216.173] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP,UPPERCASE_25_50 X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23500 invoked from network); 2 Oct 2012 18:08:47 -0000 Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com) (209.85.216.173) by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 18:08:47 -0000 Received: by qcab12 with SMTP id b12so6673862qca.32 for ; Tue, 02 Oct 2012 11:08:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=I5iWqKH3/kK5DIeObUh8M7DbFaRxti6nToYx0Qj+5/c=; b=WnMFt0kIePJCworzZe8V3tHhJk6dvsXvu366gRYpugwYhpQ8fg8iMwatfpgNw1n9YD JwwZJona7m8z3Cvh8k7jIj+0gQuIWKKU8m22NLwv3WfA/L+T6crko7VtN687WH7xD/xh fy6tCez+WP3O7MWXmRluooUbZxrgYO27L860HRMahM327kqMWQmnkSKfItuYAwWzzGuR q2OEg30rqmGJsj7qfXHKFf3EnA0KtCssF8zZAsBq0d+kriNAfAPdgcUWxzEz7oshcVGc Ig8pVQKscVOqEBDozZ4yjVO4p9coddvDq12SUotuxaBnd+G6E45j+sLjGKtZ9tCV2j7S 2/QA== Received: by 10.224.203.193 with SMTP id fj1mr3579878qab.13.1349201326458; Tue, 02 Oct 2012 11:08:46 -0700 (PDT) Received: from phenom.dumpdata.com (50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189]) by mx.google.com with ESMTPS id g18sm2036721qan.1.2012.10.02.11.08.45 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 02 Oct 2012 11:08:46 -0700 (PDT) Date: Tue, 2 Oct 2012 13:57:17 -0400 From: Konrad Rzeszutek Wilk To: Jan Beulich Message-ID: <20121002175716.GA30321@phenom.dumpdata.com> References: <506B2268020000780009F273@nat28.tlf.novell.com> <506B23BF020000780009F29A@nat28.tlf.novell.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <506B23BF020000780009F29A@nat28.tlf.novell.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: xen-devel Subject: Re: [Xen-devel] [PATCH 1/3] x86: use MOV instead of PUSH/POP when saving/restoring register state X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, Oct 02, 2012 at 04:26:23PM +0100, Jan Beulich wrote: > Signed-off-by: Jan Beulich What's the reasoning behind it? Just that mov's are faster than pop/push? > > --- a/xen/arch/x86/x86_64/compat/entry.S > +++ b/xen/arch/x86/x86_64/compat/entry.S > @@ -21,8 +21,7 @@ ENTRY(compat_hypercall) > UNLIKELY_START(ne, msi_check) > movl $HYPERCALL_VECTOR,%edi > call check_for_unexpected_msi > - RESTORE_ALL > - SAVE_ALL > + LOAD_C_CLOBBERED > UNLIKELY_END(msi_check) > > GET_CURRENT(%rbx) > @@ -173,8 +172,7 @@ compat_bad_hypercall: > /* %rbx: struct vcpu, interrupts disabled */ > compat_restore_all_guest: > ASSERT_INTERRUPTS_DISABLED > - RESTORE_ALL > - addq $8,%rsp > + RESTORE_ALL adj=8 > .Lft0: iretq > > .section .fixup,"ax" > --- a/xen/arch/x86/x86_64/entry.S > +++ b/xen/arch/x86/x86_64/entry.S > @@ -47,12 +47,10 @@ restore_all_guest: > cmpl $1,%ecx > ja .Lforce_iret > > - addq $8,%rsp > - popq %rcx # RIP > - popq %r11 # CS > - cmpw $FLAT_USER_CS32,%r11 > - popq %r11 # RFLAGS > - popq %rsp # RSP > + cmpw $FLAT_USER_CS32,16(%rsp)# CS > + movq 8(%rsp),%rcx # RIP > + movq 24(%rsp),%r11 # RFLAGS > + movq 32(%rsp),%rsp # RSP > je 1f > sysretq > 1: sysretl > @@ -101,8 +99,7 @@ failsafe_callback: > ALIGN > /* No special register assumptions. */ > restore_all_xen: > - RESTORE_ALL > - addq $8,%rsp > + RESTORE_ALL adj=8 > iretq > > /* > @@ -311,8 +308,7 @@ ENTRY(int80_direct_trap) > UNLIKELY_START(ne, msi_check) > movl $0x80,%edi > call check_for_unexpected_msi > - RESTORE_ALL > - SAVE_ALL > + LOAD_C_CLOBBERED > UNLIKELY_END(msi_check) > > GET_CURRENT(%rbx) > --- a/xen/include/asm-x86/x86_64/asm_defns.h > +++ b/xen/include/asm-x86/x86_64/asm_defns.h > @@ -5,11 +5,11 @@ > > #ifdef CONFIG_FRAME_POINTER > /* Indicate special exception stack frame by inverting the frame pointer. */ > -#define SETUP_EXCEPTION_FRAME_POINTER \ > - movq %rsp,%rbp; \ > +#define SETUP_EXCEPTION_FRAME_POINTER(offs) \ > + leaq offs(%rsp),%rbp; \ > notq %rbp > #else > -#define SETUP_EXCEPTION_FRAME_POINTER > +#define SETUP_EXCEPTION_FRAME_POINTER(off) > #endif > > #ifndef NDEBUG > @@ -27,40 +27,49 @@ > #define ASSERT_INTERRUPTS_DISABLED ASSERT_INTERRUPT_STATUS(z) > > #define SAVE_ALL \ > + addq $-(UREGS_error_code-UREGS_r15), %rsp; \ > cld; \ > - pushq %rdi; \ > - pushq %rsi; \ > - pushq %rdx; \ > - pushq %rcx; \ > - pushq %rax; \ > - pushq %r8; \ > - pushq %r9; \ > - pushq %r10; \ > - pushq %r11; \ > - pushq %rbx; \ > - pushq %rbp; \ > - SETUP_EXCEPTION_FRAME_POINTER; \ > - pushq %r12; \ > - pushq %r13; \ > - pushq %r14; \ > - pushq %r15; > - > -#define RESTORE_ALL \ > - popq %r15; \ > - popq %r14; \ > - popq %r13; \ > - popq %r12; \ > - popq %rbp; \ > - popq %rbx; \ > - popq %r11; \ > - popq %r10; \ > - popq %r9; \ > - popq %r8; \ > - popq %rax; \ > - popq %rcx; \ > - popq %rdx; \ > - popq %rsi; \ > - popq %rdi; > + movq %rdi,UREGS_rdi(%rsp); \ > + movq %rsi,UREGS_rsi(%rsp); \ > + movq %rdx,UREGS_rdx(%rsp); \ > + movq %rcx,UREGS_rcx(%rsp); \ > + movq %rax,UREGS_rax(%rsp); \ > + movq %r8,UREGS_r8(%rsp); \ > + movq %r9,UREGS_r9(%rsp); \ > + movq %r10,UREGS_r10(%rsp); \ > + movq %r11,UREGS_r11(%rsp); \ > + movq %rbx,UREGS_rbx(%rsp); \ > + movq %rbp,UREGS_rbp(%rsp); \ > + SETUP_EXCEPTION_FRAME_POINTER(UREGS_rbp); \ > + movq %r12,UREGS_r12(%rsp); \ > + movq %r13,UREGS_r13(%rsp); \ > + movq %r14,UREGS_r14(%rsp); \ > + movq %r15,UREGS_r15(%rsp); \ > + > +#ifdef __ASSEMBLY__ > +.macro LOAD_C_CLOBBERED > + movq UREGS_r11(%rsp),%r11 > + movq UREGS_r10(%rsp),%r10 > + movq UREGS_r9(%rsp),%r9 > + movq UREGS_r8(%rsp),%r8 > + movq UREGS_rax(%rsp),%rax > + movq UREGS_rcx(%rsp),%rcx > + movq UREGS_rdx(%rsp),%rdx > + movq UREGS_rsi(%rsp),%rsi > + movq UREGS_rdi(%rsp),%rdi > +.endm > + > +.macro RESTORE_ALL adj=0 > + movq UREGS_r15(%rsp),%r15 > + movq UREGS_r14(%rsp),%r14 > + movq UREGS_r13(%rsp),%r13 > + movq UREGS_r12(%rsp),%r12 > + movq UREGS_rbp(%rsp),%rbp > + movq UREGS_rbx(%rsp),%rbx > + LOAD_C_CLOBBERED > + subq $-(UREGS_error_code-UREGS_r15+\adj), %rsp > +.endm > +#endif > > #ifdef PERF_COUNTERS > #define PERFC_INCR(_name,_idx,_cur) \ > @@ -94,7 +103,7 @@ > __asm__( \ > "\n" __ALIGN_STR"\n" \ > "common_interrupt:\n\t" \ > - STR(SAVE_ALL) \ > + STR(SAVE_ALL) "\n\t" \ > "movq %rsp,%rdi\n\t" \ > "callq " STR(do_IRQ) "\n\t" \ > "jmp ret_from_intr\n"); > > > x86: use MOV instead of PUSH/POP when saving/restoring register state > > Signed-off-by: Jan Beulich > > --- a/xen/arch/x86/x86_64/compat/entry.S > +++ b/xen/arch/x86/x86_64/compat/entry.S > @@ -21,8 +21,7 @@ ENTRY(compat_hypercall) > UNLIKELY_START(ne, msi_check) > movl $HYPERCALL_VECTOR,%edi > call check_for_unexpected_msi > - RESTORE_ALL > - SAVE_ALL > + LOAD_C_CLOBBERED > UNLIKELY_END(msi_check) > > GET_CURRENT(%rbx) > @@ -173,8 +172,7 @@ compat_bad_hypercall: > /* %rbx: struct vcpu, interrupts disabled */ > compat_restore_all_guest: > ASSERT_INTERRUPTS_DISABLED > - RESTORE_ALL > - addq $8,%rsp > + RESTORE_ALL adj=8 > .Lft0: iretq > > .section .fixup,"ax" > --- a/xen/arch/x86/x86_64/entry.S > +++ b/xen/arch/x86/x86_64/entry.S > @@ -47,12 +47,10 @@ restore_all_guest: > cmpl $1,%ecx > ja .Lforce_iret > > - addq $8,%rsp > - popq %rcx # RIP > - popq %r11 # CS > - cmpw $FLAT_USER_CS32,%r11 > - popq %r11 # RFLAGS > - popq %rsp # RSP > + cmpw $FLAT_USER_CS32,16(%rsp)# CS > + movq 8(%rsp),%rcx # RIP > + movq 24(%rsp),%r11 # RFLAGS > + movq 32(%rsp),%rsp # RSP > je 1f > sysretq > 1: sysretl > @@ -101,8 +99,7 @@ failsafe_callback: > ALIGN > /* No special register assumptions. */ > restore_all_xen: > - RESTORE_ALL > - addq $8,%rsp > + RESTORE_ALL adj=8 > iretq > > /* > @@ -311,8 +308,7 @@ ENTRY(int80_direct_trap) > UNLIKELY_START(ne, msi_check) > movl $0x80,%edi > call check_for_unexpected_msi > - RESTORE_ALL > - SAVE_ALL > + LOAD_C_CLOBBERED > UNLIKELY_END(msi_check) > > GET_CURRENT(%rbx) > --- a/xen/include/asm-x86/x86_64/asm_defns.h > +++ b/xen/include/asm-x86/x86_64/asm_defns.h > @@ -5,11 +5,11 @@ > > #ifdef CONFIG_FRAME_POINTER > /* Indicate special exception stack frame by inverting the frame pointer. */ > -#define SETUP_EXCEPTION_FRAME_POINTER \ > - movq %rsp,%rbp; \ > +#define SETUP_EXCEPTION_FRAME_POINTER(offs) \ > + leaq offs(%rsp),%rbp; \ > notq %rbp > #else > -#define SETUP_EXCEPTION_FRAME_POINTER > +#define SETUP_EXCEPTION_FRAME_POINTER(off) > #endif > > #ifndef NDEBUG > @@ -27,40 +27,49 @@ > #define ASSERT_INTERRUPTS_DISABLED ASSERT_INTERRUPT_STATUS(z) > > #define SAVE_ALL \ > + addq $-(UREGS_error_code-UREGS_r15), %rsp; \ > cld; \ > - pushq %rdi; \ > - pushq %rsi; \ > - pushq %rdx; \ > - pushq %rcx; \ > - pushq %rax; \ > - pushq %r8; \ > - pushq %r9; \ > - pushq %r10; \ > - pushq %r11; \ > - pushq %rbx; \ > - pushq %rbp; \ > - SETUP_EXCEPTION_FRAME_POINTER; \ > - pushq %r12; \ > - pushq %r13; \ > - pushq %r14; \ > - pushq %r15; > - > -#define RESTORE_ALL \ > - popq %r15; \ > - popq %r14; \ > - popq %r13; \ > - popq %r12; \ > - popq %rbp; \ > - popq %rbx; \ > - popq %r11; \ > - popq %r10; \ > - popq %r9; \ > - popq %r8; \ > - popq %rax; \ > - popq %rcx; \ > - popq %rdx; \ > - popq %rsi; \ > - popq %rdi; > + movq %rdi,UREGS_rdi(%rsp); \ > + movq %rsi,UREGS_rsi(%rsp); \ > + movq %rdx,UREGS_rdx(%rsp); \ > + movq %rcx,UREGS_rcx(%rsp); \ > + movq %rax,UREGS_rax(%rsp); \ > + movq %r8,UREGS_r8(%rsp); \ > + movq %r9,UREGS_r9(%rsp); \ > + movq %r10,UREGS_r10(%rsp); \ > + movq %r11,UREGS_r11(%rsp); \ > + movq %rbx,UREGS_rbx(%rsp); \ > + movq %rbp,UREGS_rbp(%rsp); \ > + SETUP_EXCEPTION_FRAME_POINTER(UREGS_rbp); \ > + movq %r12,UREGS_r12(%rsp); \ > + movq %r13,UREGS_r13(%rsp); \ > + movq %r14,UREGS_r14(%rsp); \ > + movq %r15,UREGS_r15(%rsp); \ > + > +#ifdef __ASSEMBLY__ > +.macro LOAD_C_CLOBBERED > + movq UREGS_r11(%rsp),%r11 > + movq UREGS_r10(%rsp),%r10 > + movq UREGS_r9(%rsp),%r9 > + movq UREGS_r8(%rsp),%r8 > + movq UREGS_rax(%rsp),%rax > + movq UREGS_rcx(%rsp),%rcx > + movq UREGS_rdx(%rsp),%rdx > + movq UREGS_rsi(%rsp),%rsi > + movq UREGS_rdi(%rsp),%rdi > +.endm > + > +.macro RESTORE_ALL adj=0 > + movq UREGS_r15(%rsp),%r15 > + movq UREGS_r14(%rsp),%r14 > + movq UREGS_r13(%rsp),%r13 > + movq UREGS_r12(%rsp),%r12 > + movq UREGS_rbp(%rsp),%rbp > + movq UREGS_rbx(%rsp),%rbx > + LOAD_C_CLOBBERED > + subq $-(UREGS_error_code-UREGS_r15+\adj), %rsp > +.endm > +#endif > > #ifdef PERF_COUNTERS > #define PERFC_INCR(_name,_idx,_cur) \ > @@ -94,7 +103,7 @@ > __asm__( \ > "\n" __ALIGN_STR"\n" \ > "common_interrupt:\n\t" \ > - STR(SAVE_ALL) \ > + STR(SAVE_ALL) "\n\t" \ > "movq %rsp,%rdi\n\t" \ > "callq " STR(do_IRQ) "\n\t" \ > "jmp ret_from_intr\n"); > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 18:09:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 18:09:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ6to-0003T7-Dj; Tue, 02 Oct 2012 18:08:52 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ6tl-0003Sz-SY for xen-devel@lists.xen.org; Tue, 02 Oct 2012 18:08:50 +0000 Received: from [85.158.138.51:25632] by server-14.bemta-3.messagelabs.com id AE/D5-25886-1BD2B605; Tue, 02 Oct 2012 18:08:49 +0000 X-Env-Sender: ketuzsezr@gmail.com X-Msg-Ref: server-16.tower-174.messagelabs.com!1349201326!32750310!1 X-Originating-IP: [209.85.216.173] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP,UPPERCASE_25_50 X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23500 invoked from network); 2 Oct 2012 18:08:47 -0000 Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com) (209.85.216.173) by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 18:08:47 -0000 Received: by qcab12 with SMTP id b12so6673862qca.32 for ; Tue, 02 Oct 2012 11:08:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=I5iWqKH3/kK5DIeObUh8M7DbFaRxti6nToYx0Qj+5/c=; b=WnMFt0kIePJCworzZe8V3tHhJk6dvsXvu366gRYpugwYhpQ8fg8iMwatfpgNw1n9YD JwwZJona7m8z3Cvh8k7jIj+0gQuIWKKU8m22NLwv3WfA/L+T6crko7VtN687WH7xD/xh fy6tCez+WP3O7MWXmRluooUbZxrgYO27L860HRMahM327kqMWQmnkSKfItuYAwWzzGuR q2OEg30rqmGJsj7qfXHKFf3EnA0KtCssF8zZAsBq0d+kriNAfAPdgcUWxzEz7oshcVGc Ig8pVQKscVOqEBDozZ4yjVO4p9coddvDq12SUotuxaBnd+G6E45j+sLjGKtZ9tCV2j7S 2/QA== Received: by 10.224.203.193 with SMTP id fj1mr3579878qab.13.1349201326458; Tue, 02 Oct 2012 11:08:46 -0700 (PDT) Received: from phenom.dumpdata.com (50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189]) by mx.google.com with ESMTPS id g18sm2036721qan.1.2012.10.02.11.08.45 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 02 Oct 2012 11:08:46 -0700 (PDT) Date: Tue, 2 Oct 2012 13:57:17 -0400 From: Konrad Rzeszutek Wilk To: Jan Beulich Message-ID: <20121002175716.GA30321@phenom.dumpdata.com> References: <506B2268020000780009F273@nat28.tlf.novell.com> <506B23BF020000780009F29A@nat28.tlf.novell.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <506B23BF020000780009F29A@nat28.tlf.novell.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: xen-devel Subject: Re: [Xen-devel] [PATCH 1/3] x86: use MOV instead of PUSH/POP when saving/restoring register state X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, Oct 02, 2012 at 04:26:23PM +0100, Jan Beulich wrote: > Signed-off-by: Jan Beulich What's the reasoning behind it? Just that mov's are faster than pop/push? > > --- a/xen/arch/x86/x86_64/compat/entry.S > +++ b/xen/arch/x86/x86_64/compat/entry.S > @@ -21,8 +21,7 @@ ENTRY(compat_hypercall) > UNLIKELY_START(ne, msi_check) > movl $HYPERCALL_VECTOR,%edi > call check_for_unexpected_msi > - RESTORE_ALL > - SAVE_ALL > + LOAD_C_CLOBBERED > UNLIKELY_END(msi_check) > > GET_CURRENT(%rbx) > @@ -173,8 +172,7 @@ compat_bad_hypercall: > /* %rbx: struct vcpu, interrupts disabled */ > compat_restore_all_guest: > ASSERT_INTERRUPTS_DISABLED > - RESTORE_ALL > - addq $8,%rsp > + RESTORE_ALL adj=8 > .Lft0: iretq > > .section .fixup,"ax" > --- a/xen/arch/x86/x86_64/entry.S > +++ b/xen/arch/x86/x86_64/entry.S > @@ -47,12 +47,10 @@ restore_all_guest: > cmpl $1,%ecx > ja .Lforce_iret > > - addq $8,%rsp > - popq %rcx # RIP > - popq %r11 # CS > - cmpw $FLAT_USER_CS32,%r11 > - popq %r11 # RFLAGS > - popq %rsp # RSP > + cmpw $FLAT_USER_CS32,16(%rsp)# CS > + movq 8(%rsp),%rcx # RIP > + movq 24(%rsp),%r11 # RFLAGS > + movq 32(%rsp),%rsp # RSP > je 1f > sysretq > 1: sysretl > @@ -101,8 +99,7 @@ failsafe_callback: > ALIGN > /* No special register assumptions. */ > restore_all_xen: > - RESTORE_ALL > - addq $8,%rsp > + RESTORE_ALL adj=8 > iretq > > /* > @@ -311,8 +308,7 @@ ENTRY(int80_direct_trap) > UNLIKELY_START(ne, msi_check) > movl $0x80,%edi > call check_for_unexpected_msi > - RESTORE_ALL > - SAVE_ALL > + LOAD_C_CLOBBERED > UNLIKELY_END(msi_check) > > GET_CURRENT(%rbx) > --- a/xen/include/asm-x86/x86_64/asm_defns.h > +++ b/xen/include/asm-x86/x86_64/asm_defns.h > @@ -5,11 +5,11 @@ > > #ifdef CONFIG_FRAME_POINTER > /* Indicate special exception stack frame by inverting the frame pointer. */ > -#define SETUP_EXCEPTION_FRAME_POINTER \ > - movq %rsp,%rbp; \ > +#define SETUP_EXCEPTION_FRAME_POINTER(offs) \ > + leaq offs(%rsp),%rbp; \ > notq %rbp > #else > -#define SETUP_EXCEPTION_FRAME_POINTER > +#define SETUP_EXCEPTION_FRAME_POINTER(off) > #endif > > #ifndef NDEBUG > @@ -27,40 +27,49 @@ > #define ASSERT_INTERRUPTS_DISABLED ASSERT_INTERRUPT_STATUS(z) > > #define SAVE_ALL \ > + addq $-(UREGS_error_code-UREGS_r15), %rsp; \ > cld; \ > - pushq %rdi; \ > - pushq %rsi; \ > - pushq %rdx; \ > - pushq %rcx; \ > - pushq %rax; \ > - pushq %r8; \ > - pushq %r9; \ > - pushq %r10; \ > - pushq %r11; \ > - pushq %rbx; \ > - pushq %rbp; \ > - SETUP_EXCEPTION_FRAME_POINTER; \ > - pushq %r12; \ > - pushq %r13; \ > - pushq %r14; \ > - pushq %r15; > - > -#define RESTORE_ALL \ > - popq %r15; \ > - popq %r14; \ > - popq %r13; \ > - popq %r12; \ > - popq %rbp; \ > - popq %rbx; \ > - popq %r11; \ > - popq %r10; \ > - popq %r9; \ > - popq %r8; \ > - popq %rax; \ > - popq %rcx; \ > - popq %rdx; \ > - popq %rsi; \ > - popq %rdi; > + movq %rdi,UREGS_rdi(%rsp); \ > + movq %rsi,UREGS_rsi(%rsp); \ > + movq %rdx,UREGS_rdx(%rsp); \ > + movq %rcx,UREGS_rcx(%rsp); \ > + movq %rax,UREGS_rax(%rsp); \ > + movq %r8,UREGS_r8(%rsp); \ > + movq %r9,UREGS_r9(%rsp); \ > + movq %r10,UREGS_r10(%rsp); \ > + movq %r11,UREGS_r11(%rsp); \ > + movq %rbx,UREGS_rbx(%rsp); \ > + movq %rbp,UREGS_rbp(%rsp); \ > + SETUP_EXCEPTION_FRAME_POINTER(UREGS_rbp); \ > + movq %r12,UREGS_r12(%rsp); \ > + movq %r13,UREGS_r13(%rsp); \ > + movq %r14,UREGS_r14(%rsp); \ > + movq %r15,UREGS_r15(%rsp); \ > + > +#ifdef __ASSEMBLY__ > +.macro LOAD_C_CLOBBERED > + movq UREGS_r11(%rsp),%r11 > + movq UREGS_r10(%rsp),%r10 > + movq UREGS_r9(%rsp),%r9 > + movq UREGS_r8(%rsp),%r8 > + movq UREGS_rax(%rsp),%rax > + movq UREGS_rcx(%rsp),%rcx > + movq UREGS_rdx(%rsp),%rdx > + movq UREGS_rsi(%rsp),%rsi > + movq UREGS_rdi(%rsp),%rdi > +.endm > + > +.macro RESTORE_ALL adj=0 > + movq UREGS_r15(%rsp),%r15 > + movq UREGS_r14(%rsp),%r14 > + movq UREGS_r13(%rsp),%r13 > + movq UREGS_r12(%rsp),%r12 > + movq UREGS_rbp(%rsp),%rbp > + movq UREGS_rbx(%rsp),%rbx > + LOAD_C_CLOBBERED > + subq $-(UREGS_error_code-UREGS_r15+\adj), %rsp > +.endm > +#endif > > #ifdef PERF_COUNTERS > #define PERFC_INCR(_name,_idx,_cur) \ > @@ -94,7 +103,7 @@ > __asm__( \ > "\n" __ALIGN_STR"\n" \ > "common_interrupt:\n\t" \ > - STR(SAVE_ALL) \ > + STR(SAVE_ALL) "\n\t" \ > "movq %rsp,%rdi\n\t" \ > "callq " STR(do_IRQ) "\n\t" \ > "jmp ret_from_intr\n"); > > > x86: use MOV instead of PUSH/POP when saving/restoring register state > > Signed-off-by: Jan Beulich > > --- a/xen/arch/x86/x86_64/compat/entry.S > +++ b/xen/arch/x86/x86_64/compat/entry.S > @@ -21,8 +21,7 @@ ENTRY(compat_hypercall) > UNLIKELY_START(ne, msi_check) > movl $HYPERCALL_VECTOR,%edi > call check_for_unexpected_msi > - RESTORE_ALL > - SAVE_ALL > + LOAD_C_CLOBBERED > UNLIKELY_END(msi_check) > > GET_CURRENT(%rbx) > @@ -173,8 +172,7 @@ compat_bad_hypercall: > /* %rbx: struct vcpu, interrupts disabled */ > compat_restore_all_guest: > ASSERT_INTERRUPTS_DISABLED > - RESTORE_ALL > - addq $8,%rsp > + RESTORE_ALL adj=8 > .Lft0: iretq > > .section .fixup,"ax" > --- a/xen/arch/x86/x86_64/entry.S > +++ b/xen/arch/x86/x86_64/entry.S > @@ -47,12 +47,10 @@ restore_all_guest: > cmpl $1,%ecx > ja .Lforce_iret > > - addq $8,%rsp > - popq %rcx # RIP > - popq %r11 # CS > - cmpw $FLAT_USER_CS32,%r11 > - popq %r11 # RFLAGS > - popq %rsp # RSP > + cmpw $FLAT_USER_CS32,16(%rsp)# CS > + movq 8(%rsp),%rcx # RIP > + movq 24(%rsp),%r11 # RFLAGS > + movq 32(%rsp),%rsp # RSP > je 1f > sysretq > 1: sysretl > @@ -101,8 +99,7 @@ failsafe_callback: > ALIGN > /* No special register assumptions. */ > restore_all_xen: > - RESTORE_ALL > - addq $8,%rsp > + RESTORE_ALL adj=8 > iretq > > /* > @@ -311,8 +308,7 @@ ENTRY(int80_direct_trap) > UNLIKELY_START(ne, msi_check) > movl $0x80,%edi > call check_for_unexpected_msi > - RESTORE_ALL > - SAVE_ALL > + LOAD_C_CLOBBERED > UNLIKELY_END(msi_check) > > GET_CURRENT(%rbx) > --- a/xen/include/asm-x86/x86_64/asm_defns.h > +++ b/xen/include/asm-x86/x86_64/asm_defns.h > @@ -5,11 +5,11 @@ > > #ifdef CONFIG_FRAME_POINTER > /* Indicate special exception stack frame by inverting the frame pointer. */ > -#define SETUP_EXCEPTION_FRAME_POINTER \ > - movq %rsp,%rbp; \ > +#define SETUP_EXCEPTION_FRAME_POINTER(offs) \ > + leaq offs(%rsp),%rbp; \ > notq %rbp > #else > -#define SETUP_EXCEPTION_FRAME_POINTER > +#define SETUP_EXCEPTION_FRAME_POINTER(off) > #endif > > #ifndef NDEBUG > @@ -27,40 +27,49 @@ > #define ASSERT_INTERRUPTS_DISABLED ASSERT_INTERRUPT_STATUS(z) > > #define SAVE_ALL \ > + addq $-(UREGS_error_code-UREGS_r15), %rsp; \ > cld; \ > - pushq %rdi; \ > - pushq %rsi; \ > - pushq %rdx; \ > - pushq %rcx; \ > - pushq %rax; \ > - pushq %r8; \ > - pushq %r9; \ > - pushq %r10; \ > - pushq %r11; \ > - pushq %rbx; \ > - pushq %rbp; \ > - SETUP_EXCEPTION_FRAME_POINTER; \ > - pushq %r12; \ > - pushq %r13; \ > - pushq %r14; \ > - pushq %r15; > - > -#define RESTORE_ALL \ > - popq %r15; \ > - popq %r14; \ > - popq %r13; \ > - popq %r12; \ > - popq %rbp; \ > - popq %rbx; \ > - popq %r11; \ > - popq %r10; \ > - popq %r9; \ > - popq %r8; \ > - popq %rax; \ > - popq %rcx; \ > - popq %rdx; \ > - popq %rsi; \ > - popq %rdi; > + movq %rdi,UREGS_rdi(%rsp); \ > + movq %rsi,UREGS_rsi(%rsp); \ > + movq %rdx,UREGS_rdx(%rsp); \ > + movq %rcx,UREGS_rcx(%rsp); \ > + movq %rax,UREGS_rax(%rsp); \ > + movq %r8,UREGS_r8(%rsp); \ > + movq %r9,UREGS_r9(%rsp); \ > + movq %r10,UREGS_r10(%rsp); \ > + movq %r11,UREGS_r11(%rsp); \ > + movq %rbx,UREGS_rbx(%rsp); \ > + movq %rbp,UREGS_rbp(%rsp); \ > + SETUP_EXCEPTION_FRAME_POINTER(UREGS_rbp); \ > + movq %r12,UREGS_r12(%rsp); \ > + movq %r13,UREGS_r13(%rsp); \ > + movq %r14,UREGS_r14(%rsp); \ > + movq %r15,UREGS_r15(%rsp); \ > + > +#ifdef __ASSEMBLY__ > +.macro LOAD_C_CLOBBERED > + movq UREGS_r11(%rsp),%r11 > + movq UREGS_r10(%rsp),%r10 > + movq UREGS_r9(%rsp),%r9 > + movq UREGS_r8(%rsp),%r8 > + movq UREGS_rax(%rsp),%rax > + movq UREGS_rcx(%rsp),%rcx > + movq UREGS_rdx(%rsp),%rdx > + movq UREGS_rsi(%rsp),%rsi > + movq UREGS_rdi(%rsp),%rdi > +.endm > + > +.macro RESTORE_ALL adj=0 > + movq UREGS_r15(%rsp),%r15 > + movq UREGS_r14(%rsp),%r14 > + movq UREGS_r13(%rsp),%r13 > + movq UREGS_r12(%rsp),%r12 > + movq UREGS_rbp(%rsp),%rbp > + movq UREGS_rbx(%rsp),%rbx > + LOAD_C_CLOBBERED > + subq $-(UREGS_error_code-UREGS_r15+\adj), %rsp > +.endm > +#endif > > #ifdef PERF_COUNTERS > #define PERFC_INCR(_name,_idx,_cur) \ > @@ -94,7 +103,7 @@ > __asm__( \ > "\n" __ALIGN_STR"\n" \ > "common_interrupt:\n\t" \ > - STR(SAVE_ALL) \ > + STR(SAVE_ALL) "\n\t" \ > "movq %rsp,%rdi\n\t" \ > "callq " STR(do_IRQ) "\n\t" \ > "jmp ret_from_intr\n"); > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 18:09:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 18:09:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ6uB-0003Vn-Vm; Tue, 02 Oct 2012 18:09:15 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ6uA-0003VW-TD for xen-devel@lists.xen.org; Tue, 02 Oct 2012 18:09:14 +0000 Received: from [85.158.143.35:61362] by server-1.bemta-4.messagelabs.com id 1A/FC-05684-ACD2B605; Tue, 02 Oct 2012 18:09:14 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1349201352!12106097!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzkyODg=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6176 invoked from network); 2 Oct 2012 18:09:13 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 18:09:13 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="210056710" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 18:09:12 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 14:09:11 -0400 Received: from [10.80.3.61] by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJ6u7-00040j-9w; Tue, 02 Oct 2012 19:09:11 +0100 Message-ID: <506B2DC7.20500@citrix.com> Date: Tue, 2 Oct 2012 19:09:11 +0100 From: Anthony PERARD User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120910 Thunderbird/15.0.1 MIME-Version: 1.0 To: Eric Blake References: <1349196747-30410-1-git-send-email-anthony.perard@citrix.com> <1349196747-30410-2-git-send-email-anthony.perard@citrix.com> <506B1CBE.6050408@redhat.com> In-Reply-To: <506B1CBE.6050408@redhat.com> Cc: Avi Kivity , Xen Devel , QEMU-devel , Stefano Stabellini Subject: Re: [Xen-devel] [Qemu-devel] [PATCH V5 1/5] QMP, Introduce xen-set-global-dirty-log command. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 18:09:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 18:09:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ6uB-0003Vn-Vm; Tue, 02 Oct 2012 18:09:15 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ6uA-0003VW-TD for xen-devel@lists.xen.org; Tue, 02 Oct 2012 18:09:14 +0000 Received: from [85.158.143.35:61362] by server-1.bemta-4.messagelabs.com id 1A/FC-05684-ACD2B605; Tue, 02 Oct 2012 18:09:14 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1349201352!12106097!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzkyODg=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6176 invoked from network); 2 Oct 2012 18:09:13 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 18:09:13 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="210056710" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 18:09:12 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 14:09:11 -0400 Received: from [10.80.3.61] by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJ6u7-00040j-9w; Tue, 02 Oct 2012 19:09:11 +0100 Message-ID: <506B2DC7.20500@citrix.com> Date: Tue, 2 Oct 2012 19:09:11 +0100 From: Anthony PERARD User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120910 Thunderbird/15.0.1 MIME-Version: 1.0 To: Eric Blake References: <1349196747-30410-1-git-send-email-anthony.perard@citrix.com> <1349196747-30410-2-git-send-email-anthony.perard@citrix.com> <506B1CBE.6050408@redhat.com> In-Reply-To: <506B1CBE.6050408@redhat.com> Cc: Avi Kivity , Xen Devel , QEMU-devel , Stefano Stabellini Subject: Re: [Xen-devel] [Qemu-devel] [PATCH V5 1/5] QMP, Introduce xen-set-global-dirty-log command. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 18:18:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 18:18:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ72c-0003tN-0F; Tue, 02 Oct 2012 18:17:58 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ72a-0003tI-Oy for xen-devel@lists.xen.org; Tue, 02 Oct 2012 18:17:56 +0000 Received: from [85.158.139.211:27185] by server-14.bemta-5.messagelabs.com id 0A/06-05772-3DF2B605; Tue, 02 Oct 2012 18:17:55 +0000 X-Env-Sender: dan.magenheimer@oracle.com X-Msg-Ref: server-16.tower-206.messagelabs.com!1349201873!20846333!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzc3NzIy\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13502 invoked from network); 2 Oct 2012 18:17:55 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 18:17:55 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q92IHivx003850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Oct 2012 18:17:45 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q92IHiq7025775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Oct 2012 18:17:44 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q92IHh5j007502; Tue, 2 Oct 2012 13:17:43 -0500 MIME-Version: 1.0 Message-ID: <1bc0b089-fb3e-4fcb-88db-bdc188a887a8@default> Date: Tue, 2 Oct 2012 11:17:27 -0700 (PDT) From: Dan Magenheimer To: Dario Faggioli , George Shuklin References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <50646FBF.9000501@gmail.com> <1348848483.3153.23.camel@Abyss> In-Reply-To: <1348848483.3153.23.camel@Abyss> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7 (607090) [OL 12.0.6661.5003 (x86)] X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: Ian Jackson , xen-devel@lists.xen.org Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org (Rats, thought I sent this out yesterday...) > From: Dario Faggioli [mailto:raistlin@linux.it] > Sent: Friday, September 28, 2012 10:08 AM > To: George Shuklin > Cc: xen-devel@lists.xen.org > Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) > > On Thu, 2012-09-27 at 19:24 +0400, George Shuklin wrote: > > not sure about xl/xm, but xapi performs one start at time, so there is > > no race between domains for memory or other resources. Oops, sorry, I missed this part of the thread because I wasn't directly cc'ed and am behind on my xen-devel reading... > IIRC, xl has a vary coarse grain locking mechanism in place for domain > creation too. As a result of that, you shouldn't be able to create two > domains at the same time, which should be enough for preventing the > situation described in the original e-mail for occurring. > > Looking at acquire_lock() and release_lock() (and at where they are > called) in xl code should clarify whether or not that is enough to > actually avoid the race (which I think it is, but I might be wrong :-D). This sounds like a pretty serious limitation, especially if it applies to migration as well as creation (or a combination)... I hope it is not a regression from xm to xl. For example, suppose a data center is trying to do a planned downtime for machine X by force-migrating all guests to machine Y. It sounds like xl would serialize this? > That being said, there still is the room for races, although not wrt > domain creation, as, for instance, there isn't any synchronization > between creation and ballooning, which both manipulate memory. So, maybe > thinking about some kind of reservation-based/transactional mechanism at > some level might make actual sense. Which is mostly the reason I am interested ;-) though solving the superset of my problem is probably a good thing as well. Dan > Unfortunately, I've no idea about how xm works in that respect. > > Hope this at least help clarifying the situation a bit. :-) > > Thanks and Regards, > Dario > > -- > <> (Raistlin Majere) > ----------------------------------------------------------------- > Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli > Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 18:18:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 18:18:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ72c-0003tN-0F; Tue, 02 Oct 2012 18:17:58 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ72a-0003tI-Oy for xen-devel@lists.xen.org; Tue, 02 Oct 2012 18:17:56 +0000 Received: from [85.158.139.211:27185] by server-14.bemta-5.messagelabs.com id 0A/06-05772-3DF2B605; Tue, 02 Oct 2012 18:17:55 +0000 X-Env-Sender: dan.magenheimer@oracle.com X-Msg-Ref: server-16.tower-206.messagelabs.com!1349201873!20846333!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzc3NzIy\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13502 invoked from network); 2 Oct 2012 18:17:55 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 18:17:55 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q92IHivx003850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Oct 2012 18:17:45 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q92IHiq7025775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Oct 2012 18:17:44 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q92IHh5j007502; Tue, 2 Oct 2012 13:17:43 -0500 MIME-Version: 1.0 Message-ID: <1bc0b089-fb3e-4fcb-88db-bdc188a887a8@default> Date: Tue, 2 Oct 2012 11:17:27 -0700 (PDT) From: Dan Magenheimer To: Dario Faggioli , George Shuklin References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <50646FBF.9000501@gmail.com> <1348848483.3153.23.camel@Abyss> In-Reply-To: <1348848483.3153.23.camel@Abyss> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7 (607090) [OL 12.0.6661.5003 (x86)] X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: Ian Jackson , xen-devel@lists.xen.org Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org (Rats, thought I sent this out yesterday...) > From: Dario Faggioli [mailto:raistlin@linux.it] > Sent: Friday, September 28, 2012 10:08 AM > To: George Shuklin > Cc: xen-devel@lists.xen.org > Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) > > On Thu, 2012-09-27 at 19:24 +0400, George Shuklin wrote: > > not sure about xl/xm, but xapi performs one start at time, so there is > > no race between domains for memory or other resources. Oops, sorry, I missed this part of the thread because I wasn't directly cc'ed and am behind on my xen-devel reading... > IIRC, xl has a vary coarse grain locking mechanism in place for domain > creation too. As a result of that, you shouldn't be able to create two > domains at the same time, which should be enough for preventing the > situation described in the original e-mail for occurring. > > Looking at acquire_lock() and release_lock() (and at where they are > called) in xl code should clarify whether or not that is enough to > actually avoid the race (which I think it is, but I might be wrong :-D). This sounds like a pretty serious limitation, especially if it applies to migration as well as creation (or a combination)... I hope it is not a regression from xm to xl. For example, suppose a data center is trying to do a planned downtime for machine X by force-migrating all guests to machine Y. It sounds like xl would serialize this? > That being said, there still is the room for races, although not wrt > domain creation, as, for instance, there isn't any synchronization > between creation and ballooning, which both manipulate memory. So, maybe > thinking about some kind of reservation-based/transactional mechanism at > some level might make actual sense. Which is mostly the reason I am interested ;-) though solving the superset of my problem is probably a good thing as well. Dan > Unfortunately, I've no idea about how xm works in that respect. > > Hope this at least help clarifying the situation a bit. :-) > > Thanks and Regards, > Dario > > -- > <> (Raistlin Majere) > ----------------------------------------------------------------- > Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli > Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 18:21:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 18:21:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ765-00040z-Gy; Tue, 02 Oct 2012 18:21:33 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ764-00040a-As for xen-devel@lists.xen.org; Tue, 02 Oct 2012 18:21:32 +0000 Received: from [85.158.138.51:16109] by server-14.bemta-3.messagelabs.com id 38/EF-25886-BA03B605; Tue, 02 Oct 2012 18:21:31 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1349202087!23950553!3 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzkyODg=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27809 invoked from network); 2 Oct 2012 18:21:30 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 18:21:30 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="210058482" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 18:21:27 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 14:21:27 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJ75z-0004Bm-3z; Tue, 02 Oct 2012 19:21:27 +0100 From: Anthony PERARD To: QEMU-devel , Stefano Stabellini Date: Tue, 2 Oct 2012 19:21:23 +0100 Message-ID: <1349202085-26476-4-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1349202085-26476-1-git-send-email-anthony.perard@citrix.com> References: <1349202085-26476-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Cc: Anthony PERARD , Xen Devel Subject: [Xen-devel] [PATCH V5 3/5] exec: Introduce helper to set dirty flags. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This new helper/hook is used in the next patch to add an extra call in a single place. Signed-off-by: Anthony PERARD Reviewed-by: Avi Kivity --- exec.c | 52 +++++++++++++++++----------------------------------- 1 file changed, 17 insertions(+), 35 deletions(-) diff --git a/exec.c b/exec.c index bb6aa4a..366684c 100644 --- a/exec.c +++ b/exec.c @@ -3417,6 +3417,18 @@ int cpu_memory_rw_debug(CPUArchState *env, target_ulong addr, } #else + +static void invalidate_and_set_dirty(target_phys_addr_t addr, + target_phys_addr_t length) +{ + if (!cpu_physical_memory_is_dirty(addr)) { + /* invalidate code */ + tb_invalidate_phys_page_range(addr, addr + length, 0); + /* set dirty bit */ + cpu_physical_memory_set_dirty_flags(addr, (0xff & ~CODE_DIRTY_FLAG)); + } +} + void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf, int len, int is_write) { @@ -3462,13 +3474,7 @@ void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf, /* RAM case */ ptr = qemu_get_ram_ptr(addr1); memcpy(ptr, buf, l); - if (!cpu_physical_memory_is_dirty(addr1)) { - /* invalidate code */ - tb_invalidate_phys_page_range(addr1, addr1 + l, 0); - /* set dirty bit */ - cpu_physical_memory_set_dirty_flags( - addr1, (0xff & ~CODE_DIRTY_FLAG)); - } + invalidate_and_set_dirty(addr1, l); qemu_put_ram_ptr(ptr); } } else { @@ -3534,13 +3540,7 @@ void cpu_physical_memory_write_rom(target_phys_addr_t addr, /* ROM/RAM case */ ptr = qemu_get_ram_ptr(addr1); memcpy(ptr, buf, l); - if (!cpu_physical_memory_is_dirty(addr1)) { - /* invalidate code */ - tb_invalidate_phys_page_range(addr1, addr1 + l, 0); - /* set dirty bit */ - cpu_physical_memory_set_dirty_flags( - addr1, (0xff & ~CODE_DIRTY_FLAG)); - } + invalidate_and_set_dirty(addr1, l); qemu_put_ram_ptr(ptr); } len -= l; @@ -3666,13 +3666,7 @@ void cpu_physical_memory_unmap(void *buffer, target_phys_addr_t len, l = TARGET_PAGE_SIZE; if (l > access_len) l = access_len; - if (!cpu_physical_memory_is_dirty(addr1)) { - /* invalidate code */ - tb_invalidate_phys_page_range(addr1, addr1 + l, 0); - /* set dirty bit */ - cpu_physical_memory_set_dirty_flags( - addr1, (0xff & ~CODE_DIRTY_FLAG)); - } + invalidate_and_set_dirty(addr1, l); addr1 += l; access_len -= l; } @@ -3978,13 +3972,7 @@ static inline void stl_phys_internal(target_phys_addr_t addr, uint32_t val, stl_p(ptr, val); break; } - if (!cpu_physical_memory_is_dirty(addr1)) { - /* invalidate code */ - tb_invalidate_phys_page_range(addr1, addr1 + 4, 0); - /* set dirty bit */ - cpu_physical_memory_set_dirty_flags(addr1, - (0xff & ~CODE_DIRTY_FLAG)); - } + invalidate_and_set_dirty(addr1, 4); } } @@ -4051,13 +4039,7 @@ static inline void stw_phys_internal(target_phys_addr_t addr, uint32_t val, stw_p(ptr, val); break; } - if (!cpu_physical_memory_is_dirty(addr1)) { - /* invalidate code */ - tb_invalidate_phys_page_range(addr1, addr1 + 2, 0); - /* set dirty bit */ - cpu_physical_memory_set_dirty_flags(addr1, - (0xff & ~CODE_DIRTY_FLAG)); - } + invalidate_and_set_dirty(addr1, 2); } } -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 18:21:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 18:21:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ765-00040z-Gy; Tue, 02 Oct 2012 18:21:33 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ764-00040a-As for xen-devel@lists.xen.org; Tue, 02 Oct 2012 18:21:32 +0000 Received: from [85.158.138.51:16109] by server-14.bemta-3.messagelabs.com id 38/EF-25886-BA03B605; Tue, 02 Oct 2012 18:21:31 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1349202087!23950553!3 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzkyODg=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27809 invoked from network); 2 Oct 2012 18:21:30 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 18:21:30 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="210058482" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 18:21:27 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 14:21:27 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJ75z-0004Bm-3z; Tue, 02 Oct 2012 19:21:27 +0100 From: Anthony PERARD To: QEMU-devel , Stefano Stabellini Date: Tue, 2 Oct 2012 19:21:23 +0100 Message-ID: <1349202085-26476-4-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1349202085-26476-1-git-send-email-anthony.perard@citrix.com> References: <1349202085-26476-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Cc: Anthony PERARD , Xen Devel Subject: [Xen-devel] [PATCH V5 3/5] exec: Introduce helper to set dirty flags. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This new helper/hook is used in the next patch to add an extra call in a single place. Signed-off-by: Anthony PERARD Reviewed-by: Avi Kivity --- exec.c | 52 +++++++++++++++++----------------------------------- 1 file changed, 17 insertions(+), 35 deletions(-) diff --git a/exec.c b/exec.c index bb6aa4a..366684c 100644 --- a/exec.c +++ b/exec.c @@ -3417,6 +3417,18 @@ int cpu_memory_rw_debug(CPUArchState *env, target_ulong addr, } #else + +static void invalidate_and_set_dirty(target_phys_addr_t addr, + target_phys_addr_t length) +{ + if (!cpu_physical_memory_is_dirty(addr)) { + /* invalidate code */ + tb_invalidate_phys_page_range(addr, addr + length, 0); + /* set dirty bit */ + cpu_physical_memory_set_dirty_flags(addr, (0xff & ~CODE_DIRTY_FLAG)); + } +} + void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf, int len, int is_write) { @@ -3462,13 +3474,7 @@ void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf, /* RAM case */ ptr = qemu_get_ram_ptr(addr1); memcpy(ptr, buf, l); - if (!cpu_physical_memory_is_dirty(addr1)) { - /* invalidate code */ - tb_invalidate_phys_page_range(addr1, addr1 + l, 0); - /* set dirty bit */ - cpu_physical_memory_set_dirty_flags( - addr1, (0xff & ~CODE_DIRTY_FLAG)); - } + invalidate_and_set_dirty(addr1, l); qemu_put_ram_ptr(ptr); } } else { @@ -3534,13 +3540,7 @@ void cpu_physical_memory_write_rom(target_phys_addr_t addr, /* ROM/RAM case */ ptr = qemu_get_ram_ptr(addr1); memcpy(ptr, buf, l); - if (!cpu_physical_memory_is_dirty(addr1)) { - /* invalidate code */ - tb_invalidate_phys_page_range(addr1, addr1 + l, 0); - /* set dirty bit */ - cpu_physical_memory_set_dirty_flags( - addr1, (0xff & ~CODE_DIRTY_FLAG)); - } + invalidate_and_set_dirty(addr1, l); qemu_put_ram_ptr(ptr); } len -= l; @@ -3666,13 +3666,7 @@ void cpu_physical_memory_unmap(void *buffer, target_phys_addr_t len, l = TARGET_PAGE_SIZE; if (l > access_len) l = access_len; - if (!cpu_physical_memory_is_dirty(addr1)) { - /* invalidate code */ - tb_invalidate_phys_page_range(addr1, addr1 + l, 0); - /* set dirty bit */ - cpu_physical_memory_set_dirty_flags( - addr1, (0xff & ~CODE_DIRTY_FLAG)); - } + invalidate_and_set_dirty(addr1, l); addr1 += l; access_len -= l; } @@ -3978,13 +3972,7 @@ static inline void stl_phys_internal(target_phys_addr_t addr, uint32_t val, stl_p(ptr, val); break; } - if (!cpu_physical_memory_is_dirty(addr1)) { - /* invalidate code */ - tb_invalidate_phys_page_range(addr1, addr1 + 4, 0); - /* set dirty bit */ - cpu_physical_memory_set_dirty_flags(addr1, - (0xff & ~CODE_DIRTY_FLAG)); - } + invalidate_and_set_dirty(addr1, 4); } } @@ -4051,13 +4039,7 @@ static inline void stw_phys_internal(target_phys_addr_t addr, uint32_t val, stw_p(ptr, val); break; } - if (!cpu_physical_memory_is_dirty(addr1)) { - /* invalidate code */ - tb_invalidate_phys_page_range(addr1, addr1 + 2, 0); - /* set dirty bit */ - cpu_physical_memory_set_dirty_flags(addr1, - (0xff & ~CODE_DIRTY_FLAG)); - } + invalidate_and_set_dirty(addr1, 2); } } -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 18:21:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 18:21:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ765-00040s-55; Tue, 02 Oct 2012 18:21:33 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ763-00040R-CT for xen-devel@lists.xen.org; Tue, 02 Oct 2012 18:21:31 +0000 Received: from [85.158.138.51:16087] by server-7.bemta-3.messagelabs.com id 43/8C-15765-AA03B605; Tue, 02 Oct 2012 18:21:30 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1349202087!23950553!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzkyODg=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27777 invoked from network); 2 Oct 2012 18:21:29 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 18:21:29 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="210058481" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 18:21:27 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 14:21:27 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJ75z-0004Bm-4L; Tue, 02 Oct 2012 19:21:27 +0100 From: Anthony PERARD To: QEMU-devel , Stefano Stabellini Date: Tue, 2 Oct 2012 19:21:24 +0100 Message-ID: <1349202085-26476-5-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1349202085-26476-1-git-send-email-anthony.perard@citrix.com> References: <1349202085-26476-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Cc: Anthony PERARD , Xen Devel Subject: [Xen-devel] [PATCH V5 4/5] exec, memory: Call to xen_modified_memory. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch add some calls to xen_modified_memory to notify Xen about dirtybits during migration. Signed-off-by: Anthony PERARD Reviewed-by: Avi Kivity --- exec-obsolete.h | 2 ++ exec.c | 1 + 2 files changed, 3 insertions(+) diff --git a/exec-obsolete.h b/exec-obsolete.h index c099256..286e2f7 100644 --- a/exec-obsolete.h +++ b/exec-obsolete.h @@ -24,6 +24,7 @@ #endif #ifndef CONFIG_USER_ONLY +#include "hw/xen.h" ram_addr_t qemu_ram_alloc_from_ptr(ram_addr_t size, void *host, MemoryRegion *mr); @@ -111,6 +112,7 @@ static inline void cpu_physical_memory_set_dirty_range(ram_addr_t start, for (addr = start; addr < end; addr += TARGET_PAGE_SIZE) { cpu_physical_memory_set_dirty_flags(addr, dirty_flags); } + xen_modified_memory(addr, length); } static inline void cpu_physical_memory_mask_dirty_range(ram_addr_t start, diff --git a/exec.c b/exec.c index 366684c..1114a09 100644 --- a/exec.c +++ b/exec.c @@ -3427,6 +3427,7 @@ static void invalidate_and_set_dirty(target_phys_addr_t addr, /* set dirty bit */ cpu_physical_memory_set_dirty_flags(addr, (0xff & ~CODE_DIRTY_FLAG)); } + xen_modified_memory(addr, length); } void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf, -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 18:21:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 18:21:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ765-00040s-55; Tue, 02 Oct 2012 18:21:33 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ763-00040R-CT for xen-devel@lists.xen.org; Tue, 02 Oct 2012 18:21:31 +0000 Received: from [85.158.138.51:16087] by server-7.bemta-3.messagelabs.com id 43/8C-15765-AA03B605; Tue, 02 Oct 2012 18:21:30 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1349202087!23950553!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzkyODg=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27777 invoked from network); 2 Oct 2012 18:21:29 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 18:21:29 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="210058481" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 18:21:27 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 14:21:27 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJ75z-0004Bm-4L; Tue, 02 Oct 2012 19:21:27 +0100 From: Anthony PERARD To: QEMU-devel , Stefano Stabellini Date: Tue, 2 Oct 2012 19:21:24 +0100 Message-ID: <1349202085-26476-5-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1349202085-26476-1-git-send-email-anthony.perard@citrix.com> References: <1349202085-26476-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Cc: Anthony PERARD , Xen Devel Subject: [Xen-devel] [PATCH V5 4/5] exec, memory: Call to xen_modified_memory. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch add some calls to xen_modified_memory to notify Xen about dirtybits during migration. Signed-off-by: Anthony PERARD Reviewed-by: Avi Kivity --- exec-obsolete.h | 2 ++ exec.c | 1 + 2 files changed, 3 insertions(+) diff --git a/exec-obsolete.h b/exec-obsolete.h index c099256..286e2f7 100644 --- a/exec-obsolete.h +++ b/exec-obsolete.h @@ -24,6 +24,7 @@ #endif #ifndef CONFIG_USER_ONLY +#include "hw/xen.h" ram_addr_t qemu_ram_alloc_from_ptr(ram_addr_t size, void *host, MemoryRegion *mr); @@ -111,6 +112,7 @@ static inline void cpu_physical_memory_set_dirty_range(ram_addr_t start, for (addr = start; addr < end; addr += TARGET_PAGE_SIZE) { cpu_physical_memory_set_dirty_flags(addr, dirty_flags); } + xen_modified_memory(addr, length); } static inline void cpu_physical_memory_mask_dirty_range(ram_addr_t start, diff --git a/exec.c b/exec.c index 366684c..1114a09 100644 --- a/exec.c +++ b/exec.c @@ -3427,6 +3427,7 @@ static void invalidate_and_set_dirty(target_phys_addr_t addr, /* set dirty bit */ cpu_physical_memory_set_dirty_flags(addr, (0xff & ~CODE_DIRTY_FLAG)); } + xen_modified_memory(addr, length); } void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf, -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 18:21:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 18:21:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ764-00040h-Kn; Tue, 02 Oct 2012 18:21:32 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ762-00040P-JZ for xen-devel@lists.xen.org; Tue, 02 Oct 2012 18:21:30 +0000 Received: from [85.158.138.51:16062] by server-3.bemta-3.messagelabs.com id 5A/64-25962-9A03B605; Tue, 02 Oct 2012 18:21:29 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1349202087!23950553!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzkyODg=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27747 invoked from network); 2 Oct 2012 18:21:29 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 18:21:29 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="210058480" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 18:21:27 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 14:21:27 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJ75y-0004Bm-Ul; Tue, 02 Oct 2012 19:21:26 +0100 From: Anthony PERARD To: QEMU-devel , Stefano Stabellini Date: Tue, 2 Oct 2012 19:21:20 +0100 Message-ID: <1349202085-26476-1-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 MIME-Version: 1.0 Cc: Anthony PERARD , Xen Devel Subject: [Xen-devel] [PATCH V5 0/5] Xen, introducing dirty log for migration. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hi, This patch set will fix live migration under Xen. For this I introduce a new QMP command to switch global-dirty log and few calls (in exec.c and memory.c) to xen set_dirty function. Change since v5: - fix initial version number for the xen-set-global-dirty-log QMP command. Change since v4: - call xen_modified_memory in cpu_physical_memory_set_dirty_range instead of calling it from memory_set_dirty. Change since v3: - Coding style of patch 2 - Reword last patch comment Change since v2: - renamed set_dirty_helper to invalidate_and_set_dirty. - in the last patch, set vram as dirty if the xen call fails, instead of only during migration. Change v1-v2: - New patch to set dirty if not, in exec.c => only one place to add the xen call in exec.c Anthony PERARD (5): QMP, Introduce xen-set-global-dirty-log command. xen: Introduce xen_modified_memory. exec: Introduce helper to set dirty flags. exec, memory: Call to xen_modified_memory. xen: Set the vram dirty when an error occur. exec-obsolete.h | 2 ++ exec.c | 53 ++++++++++++++++++----------------------------------- hw/xen.h | 1 + qapi-schema.json | 13 +++++++++++++ qmp-commands.hx | 24 ++++++++++++++++++++++++ xen-all.c | 39 ++++++++++++++++++++++++++++++++++++++- xen-stub.c | 9 +++++++++ 7 files changed, 105 insertions(+), 36 deletions(-) -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 18:21:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 18:21:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ764-00040h-Kn; Tue, 02 Oct 2012 18:21:32 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ762-00040P-JZ for xen-devel@lists.xen.org; Tue, 02 Oct 2012 18:21:30 +0000 Received: from [85.158.138.51:16062] by server-3.bemta-3.messagelabs.com id 5A/64-25962-9A03B605; Tue, 02 Oct 2012 18:21:29 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1349202087!23950553!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzkyODg=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27747 invoked from network); 2 Oct 2012 18:21:29 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 18:21:29 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="210058480" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 18:21:27 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 14:21:27 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJ75y-0004Bm-Ul; Tue, 02 Oct 2012 19:21:26 +0100 From: Anthony PERARD To: QEMU-devel , Stefano Stabellini Date: Tue, 2 Oct 2012 19:21:20 +0100 Message-ID: <1349202085-26476-1-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 MIME-Version: 1.0 Cc: Anthony PERARD , Xen Devel Subject: [Xen-devel] [PATCH V5 0/5] Xen, introducing dirty log for migration. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hi, This patch set will fix live migration under Xen. For this I introduce a new QMP command to switch global-dirty log and few calls (in exec.c and memory.c) to xen set_dirty function. Change since v5: - fix initial version number for the xen-set-global-dirty-log QMP command. Change since v4: - call xen_modified_memory in cpu_physical_memory_set_dirty_range instead of calling it from memory_set_dirty. Change since v3: - Coding style of patch 2 - Reword last patch comment Change since v2: - renamed set_dirty_helper to invalidate_and_set_dirty. - in the last patch, set vram as dirty if the xen call fails, instead of only during migration. Change v1-v2: - New patch to set dirty if not, in exec.c => only one place to add the xen call in exec.c Anthony PERARD (5): QMP, Introduce xen-set-global-dirty-log command. xen: Introduce xen_modified_memory. exec: Introduce helper to set dirty flags. exec, memory: Call to xen_modified_memory. xen: Set the vram dirty when an error occur. exec-obsolete.h | 2 ++ exec.c | 53 ++++++++++++++++++----------------------------------- hw/xen.h | 1 + qapi-schema.json | 13 +++++++++++++ qmp-commands.hx | 24 ++++++++++++++++++++++++ xen-all.c | 39 ++++++++++++++++++++++++++++++++++++++- xen-stub.c | 9 +++++++++ 7 files changed, 105 insertions(+), 36 deletions(-) -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 18:21:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 18:21:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ766-00041E-Ti; Tue, 02 Oct 2012 18:21:34 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ764-00040b-Oe for xen-devel@lists.xen.org; Tue, 02 Oct 2012 18:21:32 +0000 Received: from [85.158.139.83:21174] by server-16.bemta-5.messagelabs.com id CB/A0-05998-CA03B605; Tue, 02 Oct 2012 18:21:32 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1349202090!28829309!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzkyODg=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7505 invoked from network); 2 Oct 2012 18:21:31 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 18:21:31 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="210058483" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 18:21:27 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 14:21:27 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJ75z-0004Bm-4h; Tue, 02 Oct 2012 19:21:27 +0100 From: Anthony PERARD To: QEMU-devel , Stefano Stabellini Date: Tue, 2 Oct 2012 19:21:25 +0100 Message-ID: <1349202085-26476-6-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1349202085-26476-1-git-send-email-anthony.perard@citrix.com> References: <1349202085-26476-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Cc: Anthony PERARD , Xen Devel Subject: [Xen-devel] [PATCH V5 5/5] xen: Set the vram dirty when an error occur. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on all the video ram. This case happens during migration. Signed-off-by: Anthony PERARD Acked-by: Stefano Stabellini --- xen-all.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/xen-all.c b/xen-all.c index b11542c..e6308be 100644 --- a/xen-all.c +++ b/xen-all.c @@ -507,7 +507,8 @@ static void xen_sync_dirty_bitmap(XenIOState *state, bitmap); if (rc < 0) { if (rc != -ENODATA) { - fprintf(stderr, "xen: track_dirty_vram failed (0x" TARGET_FMT_plx + memory_region_set_dirty(framebuffer, 0, size); + DPRINTF("xen: track_dirty_vram failed (0x" TARGET_FMT_plx ", 0x" TARGET_FMT_plx "): %s\n", start_addr, start_addr + size, strerror(-rc)); } -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 18:21:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 18:21:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ766-00041E-Ti; Tue, 02 Oct 2012 18:21:34 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ764-00040b-Oe for xen-devel@lists.xen.org; Tue, 02 Oct 2012 18:21:32 +0000 Received: from [85.158.139.83:21174] by server-16.bemta-5.messagelabs.com id CB/A0-05998-CA03B605; Tue, 02 Oct 2012 18:21:32 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1349202090!28829309!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzkyODg=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7505 invoked from network); 2 Oct 2012 18:21:31 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 18:21:31 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="210058483" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 18:21:27 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 14:21:27 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJ75z-0004Bm-4h; Tue, 02 Oct 2012 19:21:27 +0100 From: Anthony PERARD To: QEMU-devel , Stefano Stabellini Date: Tue, 2 Oct 2012 19:21:25 +0100 Message-ID: <1349202085-26476-6-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1349202085-26476-1-git-send-email-anthony.perard@citrix.com> References: <1349202085-26476-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Cc: Anthony PERARD , Xen Devel Subject: [Xen-devel] [PATCH V5 5/5] xen: Set the vram dirty when an error occur. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on all the video ram. This case happens during migration. Signed-off-by: Anthony PERARD Acked-by: Stefano Stabellini --- xen-all.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/xen-all.c b/xen-all.c index b11542c..e6308be 100644 --- a/xen-all.c +++ b/xen-all.c @@ -507,7 +507,8 @@ static void xen_sync_dirty_bitmap(XenIOState *state, bitmap); if (rc < 0) { if (rc != -ENODATA) { - fprintf(stderr, "xen: track_dirty_vram failed (0x" TARGET_FMT_plx + memory_region_set_dirty(framebuffer, 0, size); + DPRINTF("xen: track_dirty_vram failed (0x" TARGET_FMT_plx ", 0x" TARGET_FMT_plx "): %s\n", start_addr, start_addr + size, strerror(-rc)); } -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 18:21:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 18:21:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ76D-00042f-BE; Tue, 02 Oct 2012 18:21:41 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ76C-00042L-KR for xen-devel@lists.xen.org; Tue, 02 Oct 2012 18:21:40 +0000 Received: from [85.158.139.211:58097] by server-3.bemta-5.messagelabs.com id FF/60-16108-3B03B605; Tue, 02 Oct 2012 18:21:39 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-6.tower-206.messagelabs.com!1349202097!20817607!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzMyODA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13677 invoked from network); 2 Oct 2012 18:21:39 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 18:21:39 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="39903979" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 18:21:27 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 14:21:27 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJ75y-0004Bm-VH; Tue, 02 Oct 2012 19:21:27 +0100 From: Anthony PERARD To: QEMU-devel , Stefano Stabellini Date: Tue, 2 Oct 2012 19:21:21 +0100 Message-ID: <1349202085-26476-2-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1349202085-26476-1-git-send-email-anthony.perard@citrix.com> References: <1349202085-26476-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Cc: Anthony PERARD , Xen Devel Subject: [Xen-devel] [PATCH V5 1/5] QMP, Introduce xen-set-global-dirty-log command. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This command is used during a migration of a guest under Xen. It calls memory_global_dirty_log_start or memory_global_dirty_log_stop according to the argument pass to the command. Signed-off-by: Anthony PERARD Reviewed-by: Luiz Capitulino --- qapi-schema.json | 13 +++++++++++++ qmp-commands.hx | 24 ++++++++++++++++++++++++ xen-all.c | 15 +++++++++++++++ xen-stub.c | 5 +++++ 4 files changed, 57 insertions(+) diff --git a/qapi-schema.json b/qapi-schema.json index 14e4419..4a4a850 100644 --- a/qapi-schema.json +++ b/qapi-schema.json @@ -1956,6 +1956,19 @@ { 'command': 'xen-save-devices-state', 'data': {'filename': 'str'} } ## +# @xen-set-global-dirty-log +# +# Enable or disable the global dirty log mode. +# +# @enable: true to enable, false to disable. +# +# Returns: nothing +# +# Since: 1.3 +## +{ 'command': 'xen-set-global-dirty-log', 'data': { 'enable': 'bool' } } + +## # @device_del: # # Remove a device from a guest diff --git a/qmp-commands.hx b/qmp-commands.hx index 6e21ddb..662b7cf 100644 --- a/qmp-commands.hx +++ b/qmp-commands.hx @@ -493,6 +493,30 @@ Example: EQMP { + .name = "xen-set-global-dirty-log", + .args_type = "enable:b", + .mhandler.cmd_new = qmp_marshal_input_xen_set_global_dirty_log, + }, + +SQMP +xen-set-global-dirty-log +------- + +Enable or disable the global dirty log mode. + +Arguments: + +- "enable": Enable it or disable it. + +Example: + +-> { "execute": "xen-set-global-dirty-log", + "arguments": { "enable": true } } +<- { "return": {} } + +EQMP + + { .name = "migrate", .args_type = "detach:-d,blk:-b,inc:-i,uri:s", .mhandler.cmd_new = qmp_marshal_input_migrate, diff --git a/xen-all.c b/xen-all.c index f76b051..f75ae9f 100644 --- a/xen-all.c +++ b/xen-all.c @@ -14,6 +14,7 @@ #include "hw/pc.h" #include "hw/xen_common.h" #include "hw/xen_backend.h" +#include "qmp-commands.h" #include "range.h" #include "xen-mapcache.h" @@ -36,6 +37,7 @@ static MemoryRegion ram_memory, ram_640k, ram_lo, ram_hi; static MemoryRegion *framebuffer; +static bool xen_in_migration; /* Compatibility with older version */ #if __XEN_LATEST_INTERFACE_VERSION__ < 0x0003020a @@ -552,10 +554,14 @@ static void xen_log_sync(MemoryListener *listener, MemoryRegionSection *section) static void xen_log_global_start(MemoryListener *listener) { + if (xen_enabled()) { + xen_in_migration = true; + } } static void xen_log_global_stop(MemoryListener *listener) { + xen_in_migration = false; } static void xen_eventfd_add(MemoryListener *listener, @@ -588,6 +594,15 @@ static MemoryListener xen_memory_listener = { .priority = 10, }; +void qmp_xen_set_global_dirty_log(bool enable, Error **errp) +{ + if (enable) { + memory_global_dirty_log_start(); + } else { + memory_global_dirty_log_stop(); + } +} + /* VCPU Operations, MMIO, IO ring ... */ static void xen_reset_vcpu(void *opaque) diff --git a/xen-stub.c b/xen-stub.c index 8ff2b79..5e66ba8 100644 --- a/xen-stub.c +++ b/xen-stub.c @@ -11,6 +11,7 @@ #include "qemu-common.h" #include "hw/xen.h" #include "memory.h" +#include "qmp-commands.h" void xenstore_store_pv_console_info(int i, CharDriverState *chr) { @@ -54,3 +55,7 @@ int xen_init(void) void xen_register_framebuffer(MemoryRegion *mr) { } + +void qmp_xen_set_global_dirty_log(bool enable, Error **errp) +{ +} -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 18:21:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 18:21:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ76D-00042f-BE; Tue, 02 Oct 2012 18:21:41 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ76C-00042L-KR for xen-devel@lists.xen.org; Tue, 02 Oct 2012 18:21:40 +0000 Received: from [85.158.139.211:58097] by server-3.bemta-5.messagelabs.com id FF/60-16108-3B03B605; Tue, 02 Oct 2012 18:21:39 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-6.tower-206.messagelabs.com!1349202097!20817607!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzMyODA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13677 invoked from network); 2 Oct 2012 18:21:39 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 18:21:39 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="39903979" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 18:21:27 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 14:21:27 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJ75y-0004Bm-VH; Tue, 02 Oct 2012 19:21:27 +0100 From: Anthony PERARD To: QEMU-devel , Stefano Stabellini Date: Tue, 2 Oct 2012 19:21:21 +0100 Message-ID: <1349202085-26476-2-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1349202085-26476-1-git-send-email-anthony.perard@citrix.com> References: <1349202085-26476-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Cc: Anthony PERARD , Xen Devel Subject: [Xen-devel] [PATCH V5 1/5] QMP, Introduce xen-set-global-dirty-log command. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This command is used during a migration of a guest under Xen. It calls memory_global_dirty_log_start or memory_global_dirty_log_stop according to the argument pass to the command. Signed-off-by: Anthony PERARD Reviewed-by: Luiz Capitulino --- qapi-schema.json | 13 +++++++++++++ qmp-commands.hx | 24 ++++++++++++++++++++++++ xen-all.c | 15 +++++++++++++++ xen-stub.c | 5 +++++ 4 files changed, 57 insertions(+) diff --git a/qapi-schema.json b/qapi-schema.json index 14e4419..4a4a850 100644 --- a/qapi-schema.json +++ b/qapi-schema.json @@ -1956,6 +1956,19 @@ { 'command': 'xen-save-devices-state', 'data': {'filename': 'str'} } ## +# @xen-set-global-dirty-log +# +# Enable or disable the global dirty log mode. +# +# @enable: true to enable, false to disable. +# +# Returns: nothing +# +# Since: 1.3 +## +{ 'command': 'xen-set-global-dirty-log', 'data': { 'enable': 'bool' } } + +## # @device_del: # # Remove a device from a guest diff --git a/qmp-commands.hx b/qmp-commands.hx index 6e21ddb..662b7cf 100644 --- a/qmp-commands.hx +++ b/qmp-commands.hx @@ -493,6 +493,30 @@ Example: EQMP { + .name = "xen-set-global-dirty-log", + .args_type = "enable:b", + .mhandler.cmd_new = qmp_marshal_input_xen_set_global_dirty_log, + }, + +SQMP +xen-set-global-dirty-log +------- + +Enable or disable the global dirty log mode. + +Arguments: + +- "enable": Enable it or disable it. + +Example: + +-> { "execute": "xen-set-global-dirty-log", + "arguments": { "enable": true } } +<- { "return": {} } + +EQMP + + { .name = "migrate", .args_type = "detach:-d,blk:-b,inc:-i,uri:s", .mhandler.cmd_new = qmp_marshal_input_migrate, diff --git a/xen-all.c b/xen-all.c index f76b051..f75ae9f 100644 --- a/xen-all.c +++ b/xen-all.c @@ -14,6 +14,7 @@ #include "hw/pc.h" #include "hw/xen_common.h" #include "hw/xen_backend.h" +#include "qmp-commands.h" #include "range.h" #include "xen-mapcache.h" @@ -36,6 +37,7 @@ static MemoryRegion ram_memory, ram_640k, ram_lo, ram_hi; static MemoryRegion *framebuffer; +static bool xen_in_migration; /* Compatibility with older version */ #if __XEN_LATEST_INTERFACE_VERSION__ < 0x0003020a @@ -552,10 +554,14 @@ static void xen_log_sync(MemoryListener *listener, MemoryRegionSection *section) static void xen_log_global_start(MemoryListener *listener) { + if (xen_enabled()) { + xen_in_migration = true; + } } static void xen_log_global_stop(MemoryListener *listener) { + xen_in_migration = false; } static void xen_eventfd_add(MemoryListener *listener, @@ -588,6 +594,15 @@ static MemoryListener xen_memory_listener = { .priority = 10, }; +void qmp_xen_set_global_dirty_log(bool enable, Error **errp) +{ + if (enable) { + memory_global_dirty_log_start(); + } else { + memory_global_dirty_log_stop(); + } +} + /* VCPU Operations, MMIO, IO ring ... */ static void xen_reset_vcpu(void *opaque) diff --git a/xen-stub.c b/xen-stub.c index 8ff2b79..5e66ba8 100644 --- a/xen-stub.c +++ b/xen-stub.c @@ -11,6 +11,7 @@ #include "qemu-common.h" #include "hw/xen.h" #include "memory.h" +#include "qmp-commands.h" void xenstore_store_pv_console_info(int i, CharDriverState *chr) { @@ -54,3 +55,7 @@ int xen_init(void) void xen_register_framebuffer(MemoryRegion *mr) { } + +void qmp_xen_set_global_dirty_log(bool enable, Error **errp) +{ +} -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 18:21:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 18:21:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ76E-00043d-Tu; Tue, 02 Oct 2012 18:21:42 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ76D-00042V-9F for xen-devel@lists.xen.org; Tue, 02 Oct 2012 18:21:41 +0000 Received: from [85.158.139.211:6512] by server-4.bemta-5.messagelabs.com id 47/D3-20767-4B03B605; Tue, 02 Oct 2012 18:21:40 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-6.tower-206.messagelabs.com!1349202097!20817607!2 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzMyODA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13687 invoked from network); 2 Oct 2012 18:21:39 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 18:21:39 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="39903980" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 18:21:27 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 14:21:27 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJ75z-0004Bm-0n; Tue, 02 Oct 2012 19:21:27 +0100 From: Anthony PERARD To: QEMU-devel , Stefano Stabellini Date: Tue, 2 Oct 2012 19:21:22 +0100 Message-ID: <1349202085-26476-3-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1349202085-26476-1-git-send-email-anthony.perard@citrix.com> References: <1349202085-26476-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Cc: Anthony PERARD , Xen Devel Subject: [Xen-devel] [PATCH V5 2/5] xen: Introduce xen_modified_memory. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This function is to be used during live migration. Every write access to the guest memory should call this funcion so the Xen tools knows which pages are dirty. Signed-off-by: Anthony PERARD Acked-by: Stefano Stabellini --- hw/xen.h | 1 + xen-all.c | 21 +++++++++++++++++++++ xen-stub.c | 4 ++++ 3 files changed, 26 insertions(+) diff --git a/hw/xen.h b/hw/xen.h index e5926b7..d14e92d 100644 --- a/hw/xen.h +++ b/hw/xen.h @@ -48,6 +48,7 @@ void xenstore_store_pv_console_info(int i, struct CharDriverState *chr); struct MemoryRegion; void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, struct MemoryRegion *mr); +void xen_modified_memory(ram_addr_t start, ram_addr_t length); #endif struct MemoryRegion; diff --git a/xen-all.c b/xen-all.c index f75ae9f..b11542c 100644 --- a/xen-all.c +++ b/xen-all.c @@ -1228,3 +1228,24 @@ void xen_shutdown_fatal_error(const char *fmt, ...) /* destroy the domain */ qemu_system_shutdown_request(); } + +void xen_modified_memory(ram_addr_t start, ram_addr_t length) +{ + if (unlikely(xen_in_migration)) { + int rc; + ram_addr_t start_pfn, nb_pages; + + if (length == 0) { + length = TARGET_PAGE_SIZE; + } + start_pfn = start >> TARGET_PAGE_BITS; + nb_pages = ((start + length + TARGET_PAGE_SIZE - 1) >> TARGET_PAGE_BITS) + - start_pfn; + rc = xc_hvm_modified_memory(xen_xc, xen_domid, start_pfn, nb_pages); + if (rc) { + fprintf(stderr, + "%s failed for "RAM_ADDR_FMT" ("RAM_ADDR_FMT"): %i, %s\n", + __func__, start, nb_pages, rc, strerror(-rc)); + } + } +} diff --git a/xen-stub.c b/xen-stub.c index 5e66ba8..9214392 100644 --- a/xen-stub.c +++ b/xen-stub.c @@ -59,3 +59,7 @@ void xen_register_framebuffer(MemoryRegion *mr) void qmp_xen_set_global_dirty_log(bool enable, Error **errp) { } + +void xen_modified_memory(ram_addr_t start, ram_addr_t length) +{ +} -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 18:21:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 18:21:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ76E-00043d-Tu; Tue, 02 Oct 2012 18:21:42 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ76D-00042V-9F for xen-devel@lists.xen.org; Tue, 02 Oct 2012 18:21:41 +0000 Received: from [85.158.139.211:6512] by server-4.bemta-5.messagelabs.com id 47/D3-20767-4B03B605; Tue, 02 Oct 2012 18:21:40 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-6.tower-206.messagelabs.com!1349202097!20817607!2 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzMyODA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13687 invoked from network); 2 Oct 2012 18:21:39 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 18:21:39 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="39903980" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 18:21:27 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 14:21:27 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJ75z-0004Bm-0n; Tue, 02 Oct 2012 19:21:27 +0100 From: Anthony PERARD To: QEMU-devel , Stefano Stabellini Date: Tue, 2 Oct 2012 19:21:22 +0100 Message-ID: <1349202085-26476-3-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1349202085-26476-1-git-send-email-anthony.perard@citrix.com> References: <1349202085-26476-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Cc: Anthony PERARD , Xen Devel Subject: [Xen-devel] [PATCH V5 2/5] xen: Introduce xen_modified_memory. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This function is to be used during live migration. Every write access to the guest memory should call this funcion so the Xen tools knows which pages are dirty. Signed-off-by: Anthony PERARD Acked-by: Stefano Stabellini --- hw/xen.h | 1 + xen-all.c | 21 +++++++++++++++++++++ xen-stub.c | 4 ++++ 3 files changed, 26 insertions(+) diff --git a/hw/xen.h b/hw/xen.h index e5926b7..d14e92d 100644 --- a/hw/xen.h +++ b/hw/xen.h @@ -48,6 +48,7 @@ void xenstore_store_pv_console_info(int i, struct CharDriverState *chr); struct MemoryRegion; void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, struct MemoryRegion *mr); +void xen_modified_memory(ram_addr_t start, ram_addr_t length); #endif struct MemoryRegion; diff --git a/xen-all.c b/xen-all.c index f75ae9f..b11542c 100644 --- a/xen-all.c +++ b/xen-all.c @@ -1228,3 +1228,24 @@ void xen_shutdown_fatal_error(const char *fmt, ...) /* destroy the domain */ qemu_system_shutdown_request(); } + +void xen_modified_memory(ram_addr_t start, ram_addr_t length) +{ + if (unlikely(xen_in_migration)) { + int rc; + ram_addr_t start_pfn, nb_pages; + + if (length == 0) { + length = TARGET_PAGE_SIZE; + } + start_pfn = start >> TARGET_PAGE_BITS; + nb_pages = ((start + length + TARGET_PAGE_SIZE - 1) >> TARGET_PAGE_BITS) + - start_pfn; + rc = xc_hvm_modified_memory(xen_xc, xen_domid, start_pfn, nb_pages); + if (rc) { + fprintf(stderr, + "%s failed for "RAM_ADDR_FMT" ("RAM_ADDR_FMT"): %i, %s\n", + __func__, start, nb_pages, rc, strerror(-rc)); + } + } +} diff --git a/xen-stub.c b/xen-stub.c index 5e66ba8..9214392 100644 --- a/xen-stub.c +++ b/xen-stub.c @@ -59,3 +59,7 @@ void xen_register_framebuffer(MemoryRegion *mr) void qmp_xen_set_global_dirty_log(bool enable, Error **errp) { } + +void xen_modified_memory(ram_addr_t start, ram_addr_t length) +{ +} -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 18:22:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 18:22:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ76S-0004C4-AU; Tue, 02 Oct 2012 18:21:56 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ76R-0004BS-FF for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 18:21:55 +0000 Received: from [85.158.137.99:6404] by server-10.bemta-3.messagelabs.com id 46/0A-02525-2C03B605; Tue, 02 Oct 2012 18:21:54 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-11.tower-217.messagelabs.com!1349202113!18805868!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22173 invoked from network); 2 Oct 2012 18:21:54 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 18:21:54 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="14901185" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 18:21:53 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 19:21:53 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TJ76P-0003PY-5a; Tue, 02 Oct 2012 18:21:53 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1TJ76O-0005X9-FO; Tue, 02 Oct 2012 19:21:52 +0100 To: Message-ID: From: xen.org Date: Tue, 2 Oct 2012 19:21:52 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 13911: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 13911 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13911/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 5 xen-boot fail like 13909 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail like 13909 test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail like 13909 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail like 13909 Tests which did not succeed, but are not blocking: test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: xen 87bf99fad7a9 baseline version: xen 5fbdbf585f5f ------------------------------------------------------------ People who touched revisions under test: "Nakajima, Jun" Ian Jackson Jan Beulich Keir Fraser Paul Durrant ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-amd64-amd64-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable + revision=87bf99fad7a9 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 87bf99fad7a9 + branch=xen-unstable + revision=87bf99fad7a9 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + . cri-common ++ umask 002 + select_xenbranch + case "$branch" in + tree=xen + xenbranch=xen-unstable + '[' xxen = xlinux ']' + linuxbranch=linux + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg ++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.xen-unstable ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git ++ : daily-cron.xen-unstable + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git + info_linux_tree xen-unstable + case $1 in + return 1 + case "$branch" in + cd /export/home/osstest/repos/xen-unstable.hg + hg push -r 87bf99fad7a9 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 1 changesets with 3 changes to 3 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 18:22:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 18:22:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ76S-0004C4-AU; Tue, 02 Oct 2012 18:21:56 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ76R-0004BS-FF for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 18:21:55 +0000 Received: from [85.158.137.99:6404] by server-10.bemta-3.messagelabs.com id 46/0A-02525-2C03B605; Tue, 02 Oct 2012 18:21:54 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-11.tower-217.messagelabs.com!1349202113!18805868!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22173 invoked from network); 2 Oct 2012 18:21:54 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 18:21:54 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="14901185" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 18:21:53 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 19:21:53 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TJ76P-0003PY-5a; Tue, 02 Oct 2012 18:21:53 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1TJ76O-0005X9-FO; Tue, 02 Oct 2012 19:21:52 +0100 To: Message-ID: From: xen.org Date: Tue, 2 Oct 2012 19:21:52 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 13911: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 13911 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13911/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 5 xen-boot fail like 13909 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail like 13909 test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail like 13909 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail like 13909 Tests which did not succeed, but are not blocking: test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: xen 87bf99fad7a9 baseline version: xen 5fbdbf585f5f ------------------------------------------------------------ People who touched revisions under test: "Nakajima, Jun" Ian Jackson Jan Beulich Keir Fraser Paul Durrant ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-amd64-amd64-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable + revision=87bf99fad7a9 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 87bf99fad7a9 + branch=xen-unstable + revision=87bf99fad7a9 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + . cri-common ++ umask 002 + select_xenbranch + case "$branch" in + tree=xen + xenbranch=xen-unstable + '[' xxen = xlinux ']' + linuxbranch=linux + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg ++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.xen-unstable ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git ++ : daily-cron.xen-unstable + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git + info_linux_tree xen-unstable + case $1 in + return 1 + case "$branch" in + cd /export/home/osstest/repos/xen-unstable.hg + hg push -r 87bf99fad7a9 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 1 changesets with 3 changes to 3 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 18:51:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 18:51:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ7Yz-0005Eb-2h; Tue, 02 Oct 2012 18:51:25 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ7Yx-0005ET-DK for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 18:51:23 +0000 Received: from [85.158.137.99:25766] by server-15.bemta-3.messagelabs.com id 34/F2-18313-AA73B605; Tue, 02 Oct 2012 18:51:22 +0000 X-Env-Sender: ketuzsezr@gmail.com X-Msg-Ref: server-15.tower-217.messagelabs.com!1349203880!17640229!1 X-Originating-IP: [209.85.210.43] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30934 invoked from network); 2 Oct 2012 18:51:21 -0000 Received: from mail-da0-f43.google.com (HELO mail-da0-f43.google.com) (209.85.210.43) by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 18:51:21 -0000 Received: by daku36 with SMTP id u36so2716227dak.30 for ; Tue, 02 Oct 2012 11:51:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=BpMZVFnNy0RSARPh3Gr1yhflzjF93MWphj/toIZi9Qs=; b=FtLyIUTdepxttS/jtOJT1GCnNMnHw+ByGpb5PacBMFr3hXOeyk0/78hqutbo7w0JhY KuMObf2brSagT+JXtj1CJWoCfcjlyDQwf3fW99TDh9yG8uqwiqL0j8ui/QsGWi5pNNXf 9b+aQtCdxAabbT528VbvYM1jtQnOPmkOs03VNpqfdGVBpOpiQi/99dbcbBsHG9wGcrzJ WvdAQVy6sST/ls17BqpD+7ZS7UEV2KsReJlSKuU76cHc96HuNUUMBqenyphiRcdLdnPA PUu02HzEWlPvJ2sAkUhALHiwYHkg0Xk+bJ/9tpFwlqA92WC29y+I4b6TGxJ2VJfxdwxi BubA== MIME-Version: 1.0 Received: by 10.68.225.34 with SMTP id rh2mr6633599pbc.78.1349203879662; Tue, 02 Oct 2012 11:51:19 -0700 (PDT) Received: by 10.66.193.9 with HTTP; Tue, 2 Oct 2012 11:51:19 -0700 (PDT) In-Reply-To: References: Date: Tue, 2 Oct 2012 14:51:19 -0400 X-Google-Sender-Auth: H2o8dullfBLSkNXiLKMs9X_pMUE Message-ID: From: Konrad Rzeszutek Wilk To: Stefano Stabellini Cc: Stephen Rothwell , xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk , linux-kernel@vger.kernel.org, linux-next@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [Xen-devel] [PATCH] xen: resolve merge conflict with 617276307cd4cdb9a95c77efaa3063695af63aa7 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, Oct 2, 2012 at 1:29 PM, Stefano Stabellini wrote: > The Xen tree tries to add a line to > arch/arm/mach-vexpress/Makefile.boot that has been removed by the > following commit in Linus' master: > > commit 617276307cd4cdb9a95c77efaa3063695af63aa7 > Author: Rob Herring > Date: Thu Sep 6 13:43:04 2012 -0500 > > ARM: vexpress: convert to multi-platform > > In fact the dts Makefile is now arch/arm/boot/dts/Makefile, as per > commit 9cd11c0c47b8690b47e7573311ce5c483cb344ed. > > > This is the merge resolution patch. > > Signed-off-by: Stefano Stabellini Great. Thanks for posting it! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 18:51:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 18:51:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ7Yz-0005Eb-2h; Tue, 02 Oct 2012 18:51:25 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ7Yx-0005ET-DK for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 18:51:23 +0000 Received: from [85.158.137.99:25766] by server-15.bemta-3.messagelabs.com id 34/F2-18313-AA73B605; Tue, 02 Oct 2012 18:51:22 +0000 X-Env-Sender: ketuzsezr@gmail.com X-Msg-Ref: server-15.tower-217.messagelabs.com!1349203880!17640229!1 X-Originating-IP: [209.85.210.43] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30934 invoked from network); 2 Oct 2012 18:51:21 -0000 Received: from mail-da0-f43.google.com (HELO mail-da0-f43.google.com) (209.85.210.43) by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 18:51:21 -0000 Received: by daku36 with SMTP id u36so2716227dak.30 for ; Tue, 02 Oct 2012 11:51:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=BpMZVFnNy0RSARPh3Gr1yhflzjF93MWphj/toIZi9Qs=; b=FtLyIUTdepxttS/jtOJT1GCnNMnHw+ByGpb5PacBMFr3hXOeyk0/78hqutbo7w0JhY KuMObf2brSagT+JXtj1CJWoCfcjlyDQwf3fW99TDh9yG8uqwiqL0j8ui/QsGWi5pNNXf 9b+aQtCdxAabbT528VbvYM1jtQnOPmkOs03VNpqfdGVBpOpiQi/99dbcbBsHG9wGcrzJ WvdAQVy6sST/ls17BqpD+7ZS7UEV2KsReJlSKuU76cHc96HuNUUMBqenyphiRcdLdnPA PUu02HzEWlPvJ2sAkUhALHiwYHkg0Xk+bJ/9tpFwlqA92WC29y+I4b6TGxJ2VJfxdwxi BubA== MIME-Version: 1.0 Received: by 10.68.225.34 with SMTP id rh2mr6633599pbc.78.1349203879662; Tue, 02 Oct 2012 11:51:19 -0700 (PDT) Received: by 10.66.193.9 with HTTP; Tue, 2 Oct 2012 11:51:19 -0700 (PDT) In-Reply-To: References: Date: Tue, 2 Oct 2012 14:51:19 -0400 X-Google-Sender-Auth: H2o8dullfBLSkNXiLKMs9X_pMUE Message-ID: From: Konrad Rzeszutek Wilk To: Stefano Stabellini Cc: Stephen Rothwell , xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk , linux-kernel@vger.kernel.org, linux-next@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [Xen-devel] [PATCH] xen: resolve merge conflict with 617276307cd4cdb9a95c77efaa3063695af63aa7 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, Oct 2, 2012 at 1:29 PM, Stefano Stabellini wrote: > The Xen tree tries to add a line to > arch/arm/mach-vexpress/Makefile.boot that has been removed by the > following commit in Linus' master: > > commit 617276307cd4cdb9a95c77efaa3063695af63aa7 > Author: Rob Herring > Date: Thu Sep 6 13:43:04 2012 -0500 > > ARM: vexpress: convert to multi-platform > > In fact the dts Makefile is now arch/arm/boot/dts/Makefile, as per > commit 9cd11c0c47b8690b47e7573311ce5c483cb344ed. > > > This is the merge resolution patch. > > Signed-off-by: Stefano Stabellini Great. Thanks for posting it! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 18:56:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 18:56:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ7dU-0005MY-P7; Tue, 02 Oct 2012 18:56:04 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ7dT-0005MS-P4 for Xen-devel@lists.xensource.com; Tue, 02 Oct 2012 18:56:03 +0000 Received: from [85.158.138.51:16963] by server-16.bemta-3.messagelabs.com id 29/37-09129-3C83B605; Tue, 02 Oct 2012 18:56:03 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1349204160!24805909!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzc3NzIy\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13601 invoked from network); 2 Oct 2012 18:56:02 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 18:56:02 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q92IttAE009392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Oct 2012 18:55:56 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q92Itsh3024886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Oct 2012 18:55:55 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q92ItsCc026544; Tue, 2 Oct 2012 13:55:54 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 02 Oct 2012 11:55:54 -0700 Date: Tue, 2 Oct 2012 11:55:52 -0700 From: Mukesh Rathor To: Konrad Rzeszutek Wilk Message-ID: <20121002115552.3a5d5196@mantra.us.oracle.com> In-Reply-To: <20121002130911.GD9009@phenom.dumpdata.com> References: <20120921121202.3163c379@mantra.us.oracle.com> <1348581263.11229.21.camel@zakaz.uk.xensource.com> <20121001142826.1ebf7b0f@mantra.us.oracle.com> <20121002130911.GD9009@phenom.dumpdata.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "Xen-devel@lists.xensource.com" , Ian Campbell , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v1 0/8]: PVH (PV guest with extensions) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2 Oct 2012 09:09:11 -0400 Konrad Rzeszutek Wilk wrote: > On Mon, Oct 01, 2012 at 02:28:26PM -0700, Mukesh Rathor wrote: > > On Tue, 25 Sep 2012 14:54:23 +0100 > > Ian Campbell wrote: > > > > > On Fri, 2012-09-21 at 20:12 +0100, Mukesh Rathor wrote: > > > > Hi guys, > > > > > > > > Ok, I've made all the changes from prev RFC patch submission. > > > > > > Did I miss the patch with the changes to arch/x86/xen/xen-head.S > > > which declare the features which are used here as supported by > > > the kernel image? > > > > > > Ian. > > > > > > > Strange, adding following to head.S > > > > ELFNOTE(Xen, XEN_ELFNOTE_PADDR_OFFSET, _ASM_PTR 0) > > ELFNOTE(Xen, XEN_ELFNOTE_GUEST_PVH, .long 1) <-------- > > > > and xenstore won't start in dom0. What gives? > > What is XEN_ELFNOTE_GUEST_PVH number? You might be re-using a value > that is defined for a different purpose? Did you check the Xen > hypervisor header files? Ah, right. I was looking at linux header file, which is behind xen. Thanks konrad. Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 18:56:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 18:56:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ7dU-0005MY-P7; Tue, 02 Oct 2012 18:56:04 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ7dT-0005MS-P4 for Xen-devel@lists.xensource.com; Tue, 02 Oct 2012 18:56:03 +0000 Received: from [85.158.138.51:16963] by server-16.bemta-3.messagelabs.com id 29/37-09129-3C83B605; Tue, 02 Oct 2012 18:56:03 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1349204160!24805909!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzc3NzIy\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13601 invoked from network); 2 Oct 2012 18:56:02 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 18:56:02 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q92IttAE009392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Oct 2012 18:55:56 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q92Itsh3024886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Oct 2012 18:55:55 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q92ItsCc026544; Tue, 2 Oct 2012 13:55:54 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 02 Oct 2012 11:55:54 -0700 Date: Tue, 2 Oct 2012 11:55:52 -0700 From: Mukesh Rathor To: Konrad Rzeszutek Wilk Message-ID: <20121002115552.3a5d5196@mantra.us.oracle.com> In-Reply-To: <20121002130911.GD9009@phenom.dumpdata.com> References: <20120921121202.3163c379@mantra.us.oracle.com> <1348581263.11229.21.camel@zakaz.uk.xensource.com> <20121001142826.1ebf7b0f@mantra.us.oracle.com> <20121002130911.GD9009@phenom.dumpdata.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "Xen-devel@lists.xensource.com" , Ian Campbell , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v1 0/8]: PVH (PV guest with extensions) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2 Oct 2012 09:09:11 -0400 Konrad Rzeszutek Wilk wrote: > On Mon, Oct 01, 2012 at 02:28:26PM -0700, Mukesh Rathor wrote: > > On Tue, 25 Sep 2012 14:54:23 +0100 > > Ian Campbell wrote: > > > > > On Fri, 2012-09-21 at 20:12 +0100, Mukesh Rathor wrote: > > > > Hi guys, > > > > > > > > Ok, I've made all the changes from prev RFC patch submission. > > > > > > Did I miss the patch with the changes to arch/x86/xen/xen-head.S > > > which declare the features which are used here as supported by > > > the kernel image? > > > > > > Ian. > > > > > > > Strange, adding following to head.S > > > > ELFNOTE(Xen, XEN_ELFNOTE_PADDR_OFFSET, _ASM_PTR 0) > > ELFNOTE(Xen, XEN_ELFNOTE_GUEST_PVH, .long 1) <-------- > > > > and xenstore won't start in dom0. What gives? > > What is XEN_ELFNOTE_GUEST_PVH number? You might be re-using a value > that is defined for a different purpose? Did you check the Xen > hypervisor header files? Ah, right. I was looking at linux header file, which is behind xen. Thanks konrad. Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 18:57:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 18:57:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ7eR-0005RA-8e; Tue, 02 Oct 2012 18:57:03 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ7eO-0005Qy-VH for Xen-devel@lists.xen.org; Tue, 02 Oct 2012 18:57:01 +0000 Received: from [85.158.138.51:56619] by server-6.bemta-3.messagelabs.com id 9A/D8-11085-CF83B605; Tue, 02 Oct 2012 18:57:00 +0000 X-Env-Sender: ketuzsezr@gmail.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1349204216!25231333!1 X-Originating-IP: [209.85.210.45] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11616 invoked from network); 2 Oct 2012 18:56:58 -0000 Received: from mail-da0-f45.google.com (HELO mail-da0-f45.google.com) (209.85.210.45) by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 18:56:58 -0000 Received: by dadn15 with SMTP id n15so2072294dad.32 for ; Tue, 02 Oct 2012 11:56:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=9750DGJUu6Zh89LvzNU+zsoc+FBrzRE2UfWOxFcBuwQ=; b=SfYZOAB7Pyxk20NifxSPmu8/KPPG5Cipt3kwExl5NF6MuFV86h4JQHkzz/XyLDe+sr E+yKFel5sEmFxyY2zA2PVfItjq0VLh2qxfuLr0Ou+FsOE/c+82Tg4P/15X10XkMRGeXZ rH2U4nmJA5ZYT4MGDUDo4EGn2eJizWyenYybBqx7ovAy2VqSlhSRdJjpxKwhZLAZi1cH Gn/5713RX6IvyP3eX1GHiGm/XkDn26UsVkkOFj34vACBgClUBjYvrHM2zj95Mlw+4Gsz OxnyEbIJbfXqLd95l9wsyi27SZVETMk4dv9c5OIcuWBUlv8nHEMXADEt1hUqaZF5vmVv FY5g== MIME-Version: 1.0 Received: by 10.68.225.34 with SMTP id rh2mr6668116pbc.78.1349204215959; Tue, 02 Oct 2012 11:56:55 -0700 (PDT) Received: by 10.66.193.9 with HTTP; Tue, 2 Oct 2012 11:56:55 -0700 (PDT) In-Reply-To: References: <20121001164757.GF8912@reaktio.net> <20121001182437.GG8912@reaktio.net> <20121002121932.GL8912@reaktio.net> <20121002144251.GP8912@reaktio.net> Date: Tue, 2 Oct 2012 14:56:55 -0400 X-Google-Sender-Auth: DlzJzHJqn9JVjWmoGR9nLv6Kb7E Message-ID: From: Konrad Rzeszutek Wilk To: Valtteri Kiviniemi Cc: Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.0.4, kernel 3.5.0 HVM crash and kernel BUG X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, Oct 2, 2012 at 10:55 AM, Valtteri Kiviniemi wrote: > Hi, > > Yes, I understood for what the parameters were for. I'ts been a long time > since I last had major problems with Xen (maybe 3.1 or something, been using > Xen since version 2) and I had a shady recollection that Xen was required to > be build debugging enabled in order to get any usable debugging data. > > But anyway, I cant reproduce that kernel crash everytime, it just happens > sometimes. Major problem is the black screen on VNC and second problem seems > to be that everytime i try to run Linux in HVM mode it somehow breaks the > hotplug scripts. > So do you have all backends loaded? Is xen-netback and xen-blkback running? Do you also have tun loaded? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 18:57:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 18:57:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ7eR-0005RA-8e; Tue, 02 Oct 2012 18:57:03 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ7eO-0005Qy-VH for Xen-devel@lists.xen.org; Tue, 02 Oct 2012 18:57:01 +0000 Received: from [85.158.138.51:56619] by server-6.bemta-3.messagelabs.com id 9A/D8-11085-CF83B605; Tue, 02 Oct 2012 18:57:00 +0000 X-Env-Sender: ketuzsezr@gmail.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1349204216!25231333!1 X-Originating-IP: [209.85.210.45] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11616 invoked from network); 2 Oct 2012 18:56:58 -0000 Received: from mail-da0-f45.google.com (HELO mail-da0-f45.google.com) (209.85.210.45) by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 18:56:58 -0000 Received: by dadn15 with SMTP id n15so2072294dad.32 for ; Tue, 02 Oct 2012 11:56:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=9750DGJUu6Zh89LvzNU+zsoc+FBrzRE2UfWOxFcBuwQ=; b=SfYZOAB7Pyxk20NifxSPmu8/KPPG5Cipt3kwExl5NF6MuFV86h4JQHkzz/XyLDe+sr E+yKFel5sEmFxyY2zA2PVfItjq0VLh2qxfuLr0Ou+FsOE/c+82Tg4P/15X10XkMRGeXZ rH2U4nmJA5ZYT4MGDUDo4EGn2eJizWyenYybBqx7ovAy2VqSlhSRdJjpxKwhZLAZi1cH Gn/5713RX6IvyP3eX1GHiGm/XkDn26UsVkkOFj34vACBgClUBjYvrHM2zj95Mlw+4Gsz OxnyEbIJbfXqLd95l9wsyi27SZVETMk4dv9c5OIcuWBUlv8nHEMXADEt1hUqaZF5vmVv FY5g== MIME-Version: 1.0 Received: by 10.68.225.34 with SMTP id rh2mr6668116pbc.78.1349204215959; Tue, 02 Oct 2012 11:56:55 -0700 (PDT) Received: by 10.66.193.9 with HTTP; Tue, 2 Oct 2012 11:56:55 -0700 (PDT) In-Reply-To: References: <20121001164757.GF8912@reaktio.net> <20121001182437.GG8912@reaktio.net> <20121002121932.GL8912@reaktio.net> <20121002144251.GP8912@reaktio.net> Date: Tue, 2 Oct 2012 14:56:55 -0400 X-Google-Sender-Auth: DlzJzHJqn9JVjWmoGR9nLv6Kb7E Message-ID: From: Konrad Rzeszutek Wilk To: Valtteri Kiviniemi Cc: Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.0.4, kernel 3.5.0 HVM crash and kernel BUG X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, Oct 2, 2012 at 10:55 AM, Valtteri Kiviniemi wrote: > Hi, > > Yes, I understood for what the parameters were for. I'ts been a long time > since I last had major problems with Xen (maybe 3.1 or something, been using > Xen since version 2) and I had a shady recollection that Xen was required to > be build debugging enabled in order to get any usable debugging data. > > But anyway, I cant reproduce that kernel crash everytime, it just happens > sometimes. Major problem is the black screen on VNC and second problem seems > to be that everytime i try to run Linux in HVM mode it somehow breaks the > hotplug scripts. > So do you have all backends loaded? Is xen-netback and xen-blkback running? Do you also have tun loaded? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 19:08:59 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 19:08:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ7pk-00062G-5i; Tue, 02 Oct 2012 19:08:44 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ7pi-000627-TB for xen-devel@lists.xen.org; Tue, 02 Oct 2012 19:08:43 +0000 Received: from [85.158.139.211:65306] by server-15.bemta-5.messagelabs.com id 6B/23-19430-ABB3B605; Tue, 02 Oct 2012 19:08:42 +0000 X-Env-Sender: ketuzsezr@gmail.com X-Msg-Ref: server-16.tower-206.messagelabs.com!1349204919!20850618!1 X-Originating-IP: [209.85.160.45] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15093 invoked from network); 2 Oct 2012 19:08:41 -0000 Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com) (209.85.160.45) by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 19:08:41 -0000 Received: by pbbrp2 with SMTP id rp2so9363101pbb.32 for ; Tue, 02 Oct 2012 12:08:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=RoMSCeDrNka7YnSFFE35Imn5i/98BZXMqqPvRcyMqjE=; b=sWum8ZP8i0So8e5TCmj5iggn8XQdD6T+H9UrZAepWD5BfR8peleXDID7nRThPeXnjg N6abjv+jouXdxdyza7oKdfGkJYb8evVcVPUEA0Ms0UkUPK/A9zOZCp5Wmd/YumGUwxqA 1Ezz6runHka4e2FPqDgYCyNX00lNELhUp+Q0TqRYP6CVL3vKL5S2KTaliBl6zWxFEQAO A239bmY9jYypOX1aNCKOGCrseFkjerzufF21u5erb3dZBhE4yVM7/xkt/2eu8SRjjMqD //3qKQQyb6Ms6RvLJWtCCg61lqv1H8IP4miwowPo0h8BK2LCNDc0sQ+dhdhrRkJbZHM/ nrVQ== MIME-Version: 1.0 Received: by 10.66.74.65 with SMTP id r1mr2793486pav.75.1349204919522; Tue, 02 Oct 2012 12:08:39 -0700 (PDT) Received: by 10.66.193.9 with HTTP; Tue, 2 Oct 2012 12:08:39 -0700 (PDT) In-Reply-To: <3d2b4499921255b00c1844a133efeb93@imap.dingwall.me.uk> References: <20120930161345.GA31109@dingwall.me.uk> <3d2b4499921255b00c1844a133efeb93@imap.dingwall.me.uk> Date: Tue, 2 Oct 2012 15:08:39 -0400 X-Google-Sender-Auth: lPHBCHgPsiw2UyvBElTMYhN_CaY Message-ID: From: Konrad Rzeszutek Wilk To: James Dingwall Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [james-xen@dingwall.me.uk: [Xen-users] Xen 4.2.0 - CPU Frequency Scaling] X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >> >> What exactly are you trying to manage? As in what are you doing? > > What I was trying to achieve was 2 vcpus assigned and pinned to dom0 with > the remaining available for domUs. I wanted to set the scaling governor as > performance for the dom0 vcpus and ondemand for domUs. > > It was an obvious test to change dom0_max_vcpus and I should have done it > before. On removing the parameter so that all cpus were seen in dom0 I could > control the power state of them all independently. Reinstating the > parameter with value of n showed that cpu 1 - (n-1) could be controlled > independently while cpus 0 and n-11 were grouped together. And this behavior existed with the old kernel? Or was this something you were trying to do now? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 19:08:59 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 19:08:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ7pk-00062G-5i; Tue, 02 Oct 2012 19:08:44 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ7pi-000627-TB for xen-devel@lists.xen.org; Tue, 02 Oct 2012 19:08:43 +0000 Received: from [85.158.139.211:65306] by server-15.bemta-5.messagelabs.com id 6B/23-19430-ABB3B605; Tue, 02 Oct 2012 19:08:42 +0000 X-Env-Sender: ketuzsezr@gmail.com X-Msg-Ref: server-16.tower-206.messagelabs.com!1349204919!20850618!1 X-Originating-IP: [209.85.160.45] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15093 invoked from network); 2 Oct 2012 19:08:41 -0000 Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com) (209.85.160.45) by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 19:08:41 -0000 Received: by pbbrp2 with SMTP id rp2so9363101pbb.32 for ; Tue, 02 Oct 2012 12:08:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=RoMSCeDrNka7YnSFFE35Imn5i/98BZXMqqPvRcyMqjE=; b=sWum8ZP8i0So8e5TCmj5iggn8XQdD6T+H9UrZAepWD5BfR8peleXDID7nRThPeXnjg N6abjv+jouXdxdyza7oKdfGkJYb8evVcVPUEA0Ms0UkUPK/A9zOZCp5Wmd/YumGUwxqA 1Ezz6runHka4e2FPqDgYCyNX00lNELhUp+Q0TqRYP6CVL3vKL5S2KTaliBl6zWxFEQAO A239bmY9jYypOX1aNCKOGCrseFkjerzufF21u5erb3dZBhE4yVM7/xkt/2eu8SRjjMqD //3qKQQyb6Ms6RvLJWtCCg61lqv1H8IP4miwowPo0h8BK2LCNDc0sQ+dhdhrRkJbZHM/ nrVQ== MIME-Version: 1.0 Received: by 10.66.74.65 with SMTP id r1mr2793486pav.75.1349204919522; Tue, 02 Oct 2012 12:08:39 -0700 (PDT) Received: by 10.66.193.9 with HTTP; Tue, 2 Oct 2012 12:08:39 -0700 (PDT) In-Reply-To: <3d2b4499921255b00c1844a133efeb93@imap.dingwall.me.uk> References: <20120930161345.GA31109@dingwall.me.uk> <3d2b4499921255b00c1844a133efeb93@imap.dingwall.me.uk> Date: Tue, 2 Oct 2012 15:08:39 -0400 X-Google-Sender-Auth: lPHBCHgPsiw2UyvBElTMYhN_CaY Message-ID: From: Konrad Rzeszutek Wilk To: James Dingwall Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [james-xen@dingwall.me.uk: [Xen-users] Xen 4.2.0 - CPU Frequency Scaling] X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >> >> What exactly are you trying to manage? As in what are you doing? > > What I was trying to achieve was 2 vcpus assigned and pinned to dom0 with > the remaining available for domUs. I wanted to set the scaling governor as > performance for the dom0 vcpus and ondemand for domUs. > > It was an obvious test to change dom0_max_vcpus and I should have done it > before. On removing the parameter so that all cpus were seen in dom0 I could > control the power state of them all independently. Reinstating the > parameter with value of n showed that cpu 1 - (n-1) could be controlled > independently while cpus 0 and n-11 were grouped together. And this behavior existed with the old kernel? Or was this something you were trying to do now? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 19:34:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 19:34:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ8E2-0006db-2S; Tue, 02 Oct 2012 19:33:50 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ8E1-0006dW-2n for xen-devel@lists.xen.org; Tue, 02 Oct 2012 19:33:49 +0000 Received: from [85.158.143.99:59341] by server-2.bemta-4.messagelabs.com id 4D/B4-06610-C914B605; Tue, 02 Oct 2012 19:33:48 +0000 X-Env-Sender: dan.magenheimer@oracle.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1349206426!32640381!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc4Nzc1OQ==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1137 invoked from network); 2 Oct 2012 19:33:47 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 19:33:47 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q92JXX88011455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Oct 2012 19:33:34 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q92JXWxD029965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Oct 2012 19:33:32 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q92JXVlD020576; Tue, 2 Oct 2012 14:33:31 -0500 MIME-Version: 1.0 Message-ID: <66cc0085-1216-40f7-8059-eaf615202c12@default> Date: Tue, 2 Oct 2012 12:33:15 -0700 (PDT) From: Dan Magenheimer To: Tim Deegan References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> <20121002091017.GA95926@ocelot.phlegethon.org> In-Reply-To: <20121002091017.GA95926@ocelot.phlegethon.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7 (607090) [OL 12.0.6661.5003 (x86)] X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: Olaf Hering , Keir Fraser , Konrad Wilk , George Dunlap , Kurt Hackel , Ian Jackson , xen-devel@lists.xen.org, George Shuklin , Dario Faggioli , Andres Lagar-Cavilla Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > From: Tim Deegan [mailto:tim@xen.org] > Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) > > At 13:03 -0700 on 01 Oct (1349096617), Dan Magenheimer wrote: > > Bearing in mind that I know almost nothing about xl or > > the tools layer, and that, as a result, I tend to look > > for hypervisor solutions, I'm thinking it's not possible to > > solve this without direct participation of the hypervisor anyway, > > at least while ensuring the solution will successfully > > work with any memory technology that involves ballooning > > with the possibility of overcommit (i.e. tmem, page sharing > > and host-swapping, manual ballooning, PoD)... EVEN if the > > toolset is single threaded (i.e. only one domain may > > be created at a time, such as xapi). [1] > > TTBOMK, Xapi actually _has_ solved this problem, even with ballooning > and PoD. I don't know if they have any plans to support sharing, > swapping or tmem, though. Is this because PoD never independently increases the size of a domain's allocation? If so, then I agree Xapi has solved the problem because in all cases the toolstack knows when the amount of memory allocated to a domain is increasing. However, given that George's 4.3 plan contains: * Memory: Replace PoD with paging mechanism owner: george@citrix status: May need review xapi might want to (re)consider either the above 4.3 feature or see that this problem has been properly fixed prior to 4.3, because I am fairly sure that paging _will_ increase a domain's current allocation without knowledge of the toolstack. > Adding a 'reservation' of free pages that may only be allocated by a > given domain should be straightforward enough, but I'm not sure it helps It absolutely does help. With tmem (and I think with paging), the total allocation of a domain may be increased without knowledge by the toolset. > much. In the 'balloon-to-fit' model where all memory is already > allocated to some domain (or tmem), some part of the toolstack needs to > sort out freeing up the memory before allocating it to another VM. By balloon-to-fit, do you mean that all RAM is occupied? Tmem handles the "sort out freeing up the memory" entirely in the hypervisor, so the toolstack never knows. > Surely that component needs to handle the exclusion too - otherwise a > series of small VM creations could stall a large one indefinitely. Not sure I understand this, but it seems feasible. Dan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 19:34:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 19:34:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ8E2-0006db-2S; Tue, 02 Oct 2012 19:33:50 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ8E1-0006dW-2n for xen-devel@lists.xen.org; Tue, 02 Oct 2012 19:33:49 +0000 Received: from [85.158.143.99:59341] by server-2.bemta-4.messagelabs.com id 4D/B4-06610-C914B605; Tue, 02 Oct 2012 19:33:48 +0000 X-Env-Sender: dan.magenheimer@oracle.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1349206426!32640381!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc4Nzc1OQ==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1137 invoked from network); 2 Oct 2012 19:33:47 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 19:33:47 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q92JXX88011455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Oct 2012 19:33:34 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q92JXWxD029965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Oct 2012 19:33:32 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q92JXVlD020576; Tue, 2 Oct 2012 14:33:31 -0500 MIME-Version: 1.0 Message-ID: <66cc0085-1216-40f7-8059-eaf615202c12@default> Date: Tue, 2 Oct 2012 12:33:15 -0700 (PDT) From: Dan Magenheimer To: Tim Deegan References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> <20121002091017.GA95926@ocelot.phlegethon.org> In-Reply-To: <20121002091017.GA95926@ocelot.phlegethon.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7 (607090) [OL 12.0.6661.5003 (x86)] X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: Olaf Hering , Keir Fraser , Konrad Wilk , George Dunlap , Kurt Hackel , Ian Jackson , xen-devel@lists.xen.org, George Shuklin , Dario Faggioli , Andres Lagar-Cavilla Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > From: Tim Deegan [mailto:tim@xen.org] > Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) > > At 13:03 -0700 on 01 Oct (1349096617), Dan Magenheimer wrote: > > Bearing in mind that I know almost nothing about xl or > > the tools layer, and that, as a result, I tend to look > > for hypervisor solutions, I'm thinking it's not possible to > > solve this without direct participation of the hypervisor anyway, > > at least while ensuring the solution will successfully > > work with any memory technology that involves ballooning > > with the possibility of overcommit (i.e. tmem, page sharing > > and host-swapping, manual ballooning, PoD)... EVEN if the > > toolset is single threaded (i.e. only one domain may > > be created at a time, such as xapi). [1] > > TTBOMK, Xapi actually _has_ solved this problem, even with ballooning > and PoD. I don't know if they have any plans to support sharing, > swapping or tmem, though. Is this because PoD never independently increases the size of a domain's allocation? If so, then I agree Xapi has solved the problem because in all cases the toolstack knows when the amount of memory allocated to a domain is increasing. However, given that George's 4.3 plan contains: * Memory: Replace PoD with paging mechanism owner: george@citrix status: May need review xapi might want to (re)consider either the above 4.3 feature or see that this problem has been properly fixed prior to 4.3, because I am fairly sure that paging _will_ increase a domain's current allocation without knowledge of the toolstack. > Adding a 'reservation' of free pages that may only be allocated by a > given domain should be straightforward enough, but I'm not sure it helps It absolutely does help. With tmem (and I think with paging), the total allocation of a domain may be increased without knowledge by the toolset. > much. In the 'balloon-to-fit' model where all memory is already > allocated to some domain (or tmem), some part of the toolstack needs to > sort out freeing up the memory before allocating it to another VM. By balloon-to-fit, do you mean that all RAM is occupied? Tmem handles the "sort out freeing up the memory" entirely in the hypervisor, so the toolstack never knows. > Surely that component needs to handle the exclusion too - otherwise a > series of small VM creations could stall a large one indefinitely. Not sure I understand this, but it seems feasible. Dan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 20:14:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 20:14:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ8rM-0007r7-KJ; Tue, 02 Oct 2012 20:14:28 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ8rL-0007r2-Pd for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 20:14:27 +0000 Received: from [85.158.143.35:28644] by server-2.bemta-4.messagelabs.com id F0/E7-06610-32B4B605; Tue, 02 Oct 2012 20:14:27 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-2.tower-21.messagelabs.com!1349208864!9748184!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc4Nzc1OQ==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16029 invoked from network); 2 Oct 2012 20:14:26 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 20:14:26 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q92KEK8I016813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Oct 2012 20:14:21 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q92KEKm2027646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Oct 2012 20:14:20 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q92KEJLK023944; Tue, 2 Oct 2012 15:14:19 -0500 Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 02 Oct 2012 13:14:19 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 26F764032D; Tue, 2 Oct 2012 16:02:55 -0400 (EDT) Date: Tue, 2 Oct 2012 16:02:55 -0400 From: Konrad Rzeszutek Wilk To: David Vrabel Message-ID: <20121002200255.GA668@phenom.dumpdata.com> References: <1348243464-15903-1-git-send-email-david.vrabel@citrix.com> <1348243464-15903-3-git-send-email-david.vrabel@citrix.com> <5061EFB2.1080407@citrix.com> <5069D097.60606@citrix.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <5069D097.60606@citrix.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" Subject: Re: [Xen-devel] [PATCH 2/6] xen-blkfront: handle backend CLOSED without CLOSING X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, Oct 01, 2012 at 06:19:19PM +0100, David Vrabel wrote: > On 25/09/12 18:53, David Vrabel wrote: > > On 21/09/12 17:04, David Vrabel wrote: > >> From: David Vrabel > >> > >> Backend drivers shouldn't transistion to CLOSED unless the frontend is > >> CLOSED. If a backend does transition to CLOSED too soon then the > >> frontend may not see the CLOSING state and will not properly shutdown. > >> > >> So, treat an unexpected backend CLOSED state the same as CLOSING. > > > > Didn't handle the frontend block device being mounted. Updated patch here. > > Konrad, can you ack this updated patch if you're happy with it. Acked-by: Konrad Rzeszutek Wilk Or should I just carry it in my for-jens-3.7 bug-fixes queue and ask Jen to pull it once rc0 is out? > > Thanks. > > David > > > 8<--------------------------------- > > xen-blkfront: handle backend CLOSED without CLOSING > > > > Backend drivers shouldn't transistion to CLOSED unless the frontend is > > CLOSED. If a backend does transition to CLOSED too soon then the > > frontend may not see the CLOSING state and will not properly shutdown. > > > > So, treat an unexpected backend CLOSED state the same as CLOSING. > > > > If the backend is CLOSED then the frontend can't talk to it so go to > > CLOSED immediately without waiting for the block device to be closed > > or unmounted. > > > > Signed-off-by: David Vrabel > > --- > > drivers/block/xen-blkfront.c | 13 +++++++++---- > > 1 files changed, 9 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c > > index 2c2d2e5..c1f5f38 100644 > > --- a/drivers/block/xen-blkfront.c > > +++ b/drivers/block/xen-blkfront.c > > @@ -1143,7 +1143,8 @@ static int blkfront_resume(struct xenbus_device *dev) > > } > > > > static void > > -blkfront_closing(struct blkfront_info *info) > > +blkfront_closing(struct blkfront_info *info, > > + enum xenbus_state backend_state) > > { > > struct xenbus_device *xbdev = info->xbdev; > > struct block_device *bdev = NULL; > > @@ -1167,7 +1168,8 @@ blkfront_closing(struct blkfront_info *info) > > > > mutex_lock(&bdev->bd_mutex); > > > > - if (bdev->bd_openers) { > > + /* If the backend is already CLOSED, close now. */ > > + if (bdev->bd_openers && backend_state != XenbusStateClosed) { > > xenbus_dev_error(xbdev, -EBUSY, > > "Device in use; refusing to close"); > > xenbus_switch_state(xbdev, XenbusStateClosing); > > @@ -1340,15 +1342,18 @@ static void blkback_changed(struct xenbus_device *dev, > > case XenbusStateReconfiguring: > > case XenbusStateReconfigured: > > case XenbusStateUnknown: > > - case XenbusStateClosed: > > break; > > > > case XenbusStateConnected: > > blkfront_connect(info); > > break; > > > > + case XenbusStateClosed: > > + if (dev->state == XenbusStateClosed) > > + break; > > + /* Missed the backend's Closing state -- fallthrough */ > > case XenbusStateClosing: > > - blkfront_closing(info); > > + blkfront_closing(info, backend_state); > > break; > > } > > } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 20:14:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 20:14:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ8rM-0007r7-KJ; Tue, 02 Oct 2012 20:14:28 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ8rL-0007r2-Pd for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 20:14:27 +0000 Received: from [85.158.143.35:28644] by server-2.bemta-4.messagelabs.com id F0/E7-06610-32B4B605; Tue, 02 Oct 2012 20:14:27 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-2.tower-21.messagelabs.com!1349208864!9748184!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc4Nzc1OQ==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16029 invoked from network); 2 Oct 2012 20:14:26 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 20:14:26 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q92KEK8I016813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Oct 2012 20:14:21 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q92KEKm2027646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Oct 2012 20:14:20 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q92KEJLK023944; Tue, 2 Oct 2012 15:14:19 -0500 Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 02 Oct 2012 13:14:19 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 26F764032D; Tue, 2 Oct 2012 16:02:55 -0400 (EDT) Date: Tue, 2 Oct 2012 16:02:55 -0400 From: Konrad Rzeszutek Wilk To: David Vrabel Message-ID: <20121002200255.GA668@phenom.dumpdata.com> References: <1348243464-15903-1-git-send-email-david.vrabel@citrix.com> <1348243464-15903-3-git-send-email-david.vrabel@citrix.com> <5061EFB2.1080407@citrix.com> <5069D097.60606@citrix.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <5069D097.60606@citrix.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" Subject: Re: [Xen-devel] [PATCH 2/6] xen-blkfront: handle backend CLOSED without CLOSING X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, Oct 01, 2012 at 06:19:19PM +0100, David Vrabel wrote: > On 25/09/12 18:53, David Vrabel wrote: > > On 21/09/12 17:04, David Vrabel wrote: > >> From: David Vrabel > >> > >> Backend drivers shouldn't transistion to CLOSED unless the frontend is > >> CLOSED. If a backend does transition to CLOSED too soon then the > >> frontend may not see the CLOSING state and will not properly shutdown. > >> > >> So, treat an unexpected backend CLOSED state the same as CLOSING. > > > > Didn't handle the frontend block device being mounted. Updated patch here. > > Konrad, can you ack this updated patch if you're happy with it. Acked-by: Konrad Rzeszutek Wilk Or should I just carry it in my for-jens-3.7 bug-fixes queue and ask Jen to pull it once rc0 is out? > > Thanks. > > David > > > 8<--------------------------------- > > xen-blkfront: handle backend CLOSED without CLOSING > > > > Backend drivers shouldn't transistion to CLOSED unless the frontend is > > CLOSED. If a backend does transition to CLOSED too soon then the > > frontend may not see the CLOSING state and will not properly shutdown. > > > > So, treat an unexpected backend CLOSED state the same as CLOSING. > > > > If the backend is CLOSED then the frontend can't talk to it so go to > > CLOSED immediately without waiting for the block device to be closed > > or unmounted. > > > > Signed-off-by: David Vrabel > > --- > > drivers/block/xen-blkfront.c | 13 +++++++++---- > > 1 files changed, 9 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c > > index 2c2d2e5..c1f5f38 100644 > > --- a/drivers/block/xen-blkfront.c > > +++ b/drivers/block/xen-blkfront.c > > @@ -1143,7 +1143,8 @@ static int blkfront_resume(struct xenbus_device *dev) > > } > > > > static void > > -blkfront_closing(struct blkfront_info *info) > > +blkfront_closing(struct blkfront_info *info, > > + enum xenbus_state backend_state) > > { > > struct xenbus_device *xbdev = info->xbdev; > > struct block_device *bdev = NULL; > > @@ -1167,7 +1168,8 @@ blkfront_closing(struct blkfront_info *info) > > > > mutex_lock(&bdev->bd_mutex); > > > > - if (bdev->bd_openers) { > > + /* If the backend is already CLOSED, close now. */ > > + if (bdev->bd_openers && backend_state != XenbusStateClosed) { > > xenbus_dev_error(xbdev, -EBUSY, > > "Device in use; refusing to close"); > > xenbus_switch_state(xbdev, XenbusStateClosing); > > @@ -1340,15 +1342,18 @@ static void blkback_changed(struct xenbus_device *dev, > > case XenbusStateReconfiguring: > > case XenbusStateReconfigured: > > case XenbusStateUnknown: > > - case XenbusStateClosed: > > break; > > > > case XenbusStateConnected: > > blkfront_connect(info); > > break; > > > > + case XenbusStateClosed: > > + if (dev->state == XenbusStateClosed) > > + break; > > + /* Missed the backend's Closing state -- fallthrough */ > > case XenbusStateClosing: > > - blkfront_closing(info); > > + blkfront_closing(info, backend_state); > > break; > > } > > } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 20:16:58 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 20:16:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ8tR-00080Y-5J; Tue, 02 Oct 2012 20:16:37 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ8tQ-000806-5X for xen-devel@lists.xen.org; Tue, 02 Oct 2012 20:16:36 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-2.tower-27.messagelabs.com!1349208989!13190751!1 X-Originating-IP: [81.29.64.94] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25800 invoked from network); 2 Oct 2012 20:16:29 -0000 Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94) by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 20:16:29 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1TJ8tE-0000jK-9I; Tue, 02 Oct 2012 20:16:24 +0000 Date: Tue, 2 Oct 2012 21:16:24 +0100 From: Tim Deegan To: Dan Magenheimer Message-ID: <20121002201624.GA98445@ocelot.phlegethon.org> References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> <20121002091017.GA95926@ocelot.phlegethon.org> <66cc0085-1216-40f7-8059-eaf615202c12@default> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <66cc0085-1216-40f7-8059-eaf615202c12@default> User-Agent: Mutt/1.4.2.1i Cc: Olaf Hering , Keir Fraser , Konrad Wilk , George Dunlap , Kurt Hackel , Ian Jackson , xen-devel@lists.xen.org, George Shuklin , Dario Faggioli , Andres Lagar-Cavilla Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org At 12:33 -0700 on 02 Oct (1349181195), Dan Magenheimer wrote: > > From: Tim Deegan [mailto:tim@xen.org] > > Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) > > > > At 13:03 -0700 on 01 Oct (1349096617), Dan Magenheimer wrote: > > > Bearing in mind that I know almost nothing about xl or > > > the tools layer, and that, as a result, I tend to look > > > for hypervisor solutions, I'm thinking it's not possible to > > > solve this without direct participation of the hypervisor anyway, > > > at least while ensuring the solution will successfully > > > work with any memory technology that involves ballooning > > > with the possibility of overcommit (i.e. tmem, page sharing > > > and host-swapping, manual ballooning, PoD)... EVEN if the > > > toolset is single threaded (i.e. only one domain may > > > be created at a time, such as xapi). [1] > > > > TTBOMK, Xapi actually _has_ solved this problem, even with ballooning > > and PoD. I don't know if they have any plans to support sharing, > > swapping or tmem, though. > > Is this because PoD never independently increases the size of a domain's > allocation? AIUI xapi uses the domains' maximum allocations, centrally controlled, to place an upper bound on the amount of guest memory that can be in use. Within those limits there can be ballooning activity. But TBH I don't know the details. > > Adding a 'reservation' of free pages that may only be allocated by a > > given domain should be straightforward enough, but I'm not sure it helps > > It absolutely does help. With tmem (and I think with paging), the > total allocation of a domain may be increased without knowledge by > the toolset. But not past the domains' maximum allowance, right? That's not the case with paging, anyway. > > much. In the 'balloon-to-fit' model where all memory is already > > allocated to some domain (or tmem), some part of the toolstack needs to > > sort out freeing up the memory before allocating it to another VM. > > By balloon-to-fit, do you mean that all RAM is occupied? Tmem > handles the "sort out freeing up the memory" entirely in the > hypervisor, so the toolstack never knows. Does tmem replace ballooning/sharing/swapping entirely? I thought they could coexist. Or, if you jut mean that tmem owns all otherwise-free memory and will relinquish it on demand, then the same problems occur while the toolstack is moving memory from owned-by-guests to owned-by-tmem. > > Surely that component needs to handle the exclusion too - otherwise a > > series of small VM creations could stall a large one indefinitely. > > Not sure I understand this, but it seems feasible. If you ask for a large VM and a small VM to be started at about the same time, the small VM will always win (since you'll free enough memory for the small VM before you free enough for the big one). If you then ask for another small VM it will win again, and so forth, indefinitely postponing the large VM in the waiting-for-memory state, unless some agent explicitly enforces that VMs be started in order. If you have such an agent you probably don't need a hypervisor interlock as well. I think it would be better to back up a bit. Maybe you could sketch out how you think [lib]xl ought to be handling ballooning/swapping/sharing/tmem when it's starting VMs. I don't have a strong objection to accounting free memory to particular domains if it turns out to be useful, but as always I prefer not to have things happen in the hypervisor if they could happen in less privileged code. Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 20:16:58 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 20:16:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ8tR-00080Y-5J; Tue, 02 Oct 2012 20:16:37 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ8tQ-000806-5X for xen-devel@lists.xen.org; Tue, 02 Oct 2012 20:16:36 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-2.tower-27.messagelabs.com!1349208989!13190751!1 X-Originating-IP: [81.29.64.94] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25800 invoked from network); 2 Oct 2012 20:16:29 -0000 Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94) by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 20:16:29 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1TJ8tE-0000jK-9I; Tue, 02 Oct 2012 20:16:24 +0000 Date: Tue, 2 Oct 2012 21:16:24 +0100 From: Tim Deegan To: Dan Magenheimer Message-ID: <20121002201624.GA98445@ocelot.phlegethon.org> References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> <20121002091017.GA95926@ocelot.phlegethon.org> <66cc0085-1216-40f7-8059-eaf615202c12@default> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <66cc0085-1216-40f7-8059-eaf615202c12@default> User-Agent: Mutt/1.4.2.1i Cc: Olaf Hering , Keir Fraser , Konrad Wilk , George Dunlap , Kurt Hackel , Ian Jackson , xen-devel@lists.xen.org, George Shuklin , Dario Faggioli , Andres Lagar-Cavilla Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org At 12:33 -0700 on 02 Oct (1349181195), Dan Magenheimer wrote: > > From: Tim Deegan [mailto:tim@xen.org] > > Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) > > > > At 13:03 -0700 on 01 Oct (1349096617), Dan Magenheimer wrote: > > > Bearing in mind that I know almost nothing about xl or > > > the tools layer, and that, as a result, I tend to look > > > for hypervisor solutions, I'm thinking it's not possible to > > > solve this without direct participation of the hypervisor anyway, > > > at least while ensuring the solution will successfully > > > work with any memory technology that involves ballooning > > > with the possibility of overcommit (i.e. tmem, page sharing > > > and host-swapping, manual ballooning, PoD)... EVEN if the > > > toolset is single threaded (i.e. only one domain may > > > be created at a time, such as xapi). [1] > > > > TTBOMK, Xapi actually _has_ solved this problem, even with ballooning > > and PoD. I don't know if they have any plans to support sharing, > > swapping or tmem, though. > > Is this because PoD never independently increases the size of a domain's > allocation? AIUI xapi uses the domains' maximum allocations, centrally controlled, to place an upper bound on the amount of guest memory that can be in use. Within those limits there can be ballooning activity. But TBH I don't know the details. > > Adding a 'reservation' of free pages that may only be allocated by a > > given domain should be straightforward enough, but I'm not sure it helps > > It absolutely does help. With tmem (and I think with paging), the > total allocation of a domain may be increased without knowledge by > the toolset. But not past the domains' maximum allowance, right? That's not the case with paging, anyway. > > much. In the 'balloon-to-fit' model where all memory is already > > allocated to some domain (or tmem), some part of the toolstack needs to > > sort out freeing up the memory before allocating it to another VM. > > By balloon-to-fit, do you mean that all RAM is occupied? Tmem > handles the "sort out freeing up the memory" entirely in the > hypervisor, so the toolstack never knows. Does tmem replace ballooning/sharing/swapping entirely? I thought they could coexist. Or, if you jut mean that tmem owns all otherwise-free memory and will relinquish it on demand, then the same problems occur while the toolstack is moving memory from owned-by-guests to owned-by-tmem. > > Surely that component needs to handle the exclusion too - otherwise a > > series of small VM creations could stall a large one indefinitely. > > Not sure I understand this, but it seems feasible. If you ask for a large VM and a small VM to be started at about the same time, the small VM will always win (since you'll free enough memory for the small VM before you free enough for the big one). If you then ask for another small VM it will win again, and so forth, indefinitely postponing the large VM in the waiting-for-memory state, unless some agent explicitly enforces that VMs be started in order. If you have such an agent you probably don't need a hypervisor interlock as well. I think it would be better to back up a bit. Maybe you could sketch out how you think [lib]xl ought to be handling ballooning/swapping/sharing/tmem when it's starting VMs. I don't have a strong objection to accounting free memory to particular domains if it turns out to be useful, but as always I prefer not to have things happen in the hypervisor if they could happen in less privileged code. Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 20:20:42 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 20:20:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ8x6-0008FC-RF; Tue, 02 Oct 2012 20:20:24 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ8x5-0008F4-3O for xen-devel@lists.xen.org; Tue, 02 Oct 2012 20:20:23 +0000 Received: from [85.158.143.99:9151] by server-1.bemta-4.messagelabs.com id 97/CE-05684-68C4B605; Tue, 02 Oct 2012 20:20:22 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1349209220!24420530!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc4Nzc1OQ==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28221 invoked from network); 2 Oct 2012 20:20:21 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 20:20:21 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q92KK8CT022309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Oct 2012 20:20:09 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q92KK6bT016236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Oct 2012 20:20:06 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q92KK2JM021461; Tue, 2 Oct 2012 15:20:02 -0500 Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 02 Oct 2012 13:20:02 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 841E94032D; Tue, 2 Oct 2012 16:08:37 -0400 (EDT) Date: Tue, 2 Oct 2012 16:08:37 -0400 From: Konrad Rzeszutek Wilk To: Jeremy Fitzhardinge Message-ID: <20121002200837.GB668@phenom.dumpdata.com> References: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4B98@SJCPMAILBOX01.citrite.net> <40501859.20120902104331@eikelenboom.it> <5044849002000078000982EA@nat28.tlf.novell.com> <4610648186.20120904090841@eikelenboom.it> <5045CDF302000078000985FB@nat28.tlf.novell.com> <4710608674.20120904101330@eikelenboom.it> <505AEB2D020000780009C81F@nat28.tlf.novell.com> <50661622.5030302@goop.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <50661622.5030302@goop.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: ehabkost@redhat.com, "xen-devel@lists.xen.org" , "wei.wang2@amd.com" , Sander Eikelenboom , Jan Beulich , Keir Fraser , Santosh Jodh Subject: Re: [Xen-devel] Using debug-key 'o: Dump IOMMU p2m table, locks up machine X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, Sep 28, 2012 at 02:26:58PM -0700, Jeremy Fitzhardinge wrote: > On 09/20/2012 01:08 AM, Jan Beulich wrote: > > Ping? > > I've been meaning to work up a reply, but I haven't had time to swap in > all the context again. You would remember most of it. Perhaps that was what was saved at that point of time and we did not need to restore/save other registers? > > J > > > > >>>> On 04.09.12 at 11:26, Jan Beulich wrote: > >>>>> On 04.09.12 at 10:13, Sander Eikelenboom wrote: > >>> Hmm don't know how to get the file/line, only thing i have found is: > >>> > >>> serveerstertje:/boot# gdb xen-syms-4.2.0-rc4-pre > >>> GNU gdb (GDB) 7.0.1-debian > >>> Copyright (C) 2009 Free Software Foundation, Inc. > >>> License GPLv3+: GNU GPL version 3 or later > >>> This is free software: you are free to change and redistribute it. > >>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" > >>> and "show warranty" for details. > >>> This GDB was configured as "x86_64-linux-gnu". > >>> For bug reporting instructions, please see: > >>> ... > >>> Reading symbols from /boot/xen-syms-4.2.0-rc4-pre...done. > >>> (gdb) x/i 0xffff82c48015c9ee > >>> 0xffff82c48015c9ee : mov %edx,%gs > >>> (gdb) > >> I'm not really a gdb expert, so I don't know off the top of my > >> head either. I thought I said in a previous reply that people > >> generally appear to use the addr2line utility for that purpose. > >> > >> But the disassembly already tells us where precisely the > >> problem is: The selector value (0x0063) attempted to be put > >> into %gs is apparently wrong in the context of the current > >> GDT. Now, that's GDT_ENTRY_TLS_MIN on the Linux side, > >> and ought to be valid. I'm surprised the guest (and the current > >> process in it) survives this (as the failure here results in a failsafe > >> callback into the guest). > >> > >> Looking at the Linux side of things, this has been that way > >> forever, and I think has always been broken: On x86-64, it > >> should also clear %gs here (since 32-bit processes use it for > >> their TLS, and there's nothing wrong for a 64-bit process to put > >> something in there either), albeit not via loadsegment(), but > >> through xen_load_gs_index(). And I neither see why on 32-bit > >> it only clears %gs - %fs can as much hold a selector that might > >> get invalidated with the TLS descriptor updates. Eduardo, > >> Jeremy, Konrad? > >> > >> Jan > >> > > > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 20:20:42 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 20:20:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ8x6-0008FC-RF; Tue, 02 Oct 2012 20:20:24 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ8x5-0008F4-3O for xen-devel@lists.xen.org; Tue, 02 Oct 2012 20:20:23 +0000 Received: from [85.158.143.99:9151] by server-1.bemta-4.messagelabs.com id 97/CE-05684-68C4B605; Tue, 02 Oct 2012 20:20:22 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1349209220!24420530!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc4Nzc1OQ==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28221 invoked from network); 2 Oct 2012 20:20:21 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 20:20:21 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q92KK8CT022309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Oct 2012 20:20:09 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q92KK6bT016236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Oct 2012 20:20:06 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q92KK2JM021461; Tue, 2 Oct 2012 15:20:02 -0500 Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 02 Oct 2012 13:20:02 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 841E94032D; Tue, 2 Oct 2012 16:08:37 -0400 (EDT) Date: Tue, 2 Oct 2012 16:08:37 -0400 From: Konrad Rzeszutek Wilk To: Jeremy Fitzhardinge Message-ID: <20121002200837.GB668@phenom.dumpdata.com> References: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4B98@SJCPMAILBOX01.citrite.net> <40501859.20120902104331@eikelenboom.it> <5044849002000078000982EA@nat28.tlf.novell.com> <4610648186.20120904090841@eikelenboom.it> <5045CDF302000078000985FB@nat28.tlf.novell.com> <4710608674.20120904101330@eikelenboom.it> <505AEB2D020000780009C81F@nat28.tlf.novell.com> <50661622.5030302@goop.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <50661622.5030302@goop.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: ehabkost@redhat.com, "xen-devel@lists.xen.org" , "wei.wang2@amd.com" , Sander Eikelenboom , Jan Beulich , Keir Fraser , Santosh Jodh Subject: Re: [Xen-devel] Using debug-key 'o: Dump IOMMU p2m table, locks up machine X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, Sep 28, 2012 at 02:26:58PM -0700, Jeremy Fitzhardinge wrote: > On 09/20/2012 01:08 AM, Jan Beulich wrote: > > Ping? > > I've been meaning to work up a reply, but I haven't had time to swap in > all the context again. You would remember most of it. Perhaps that was what was saved at that point of time and we did not need to restore/save other registers? > > J > > > > >>>> On 04.09.12 at 11:26, Jan Beulich wrote: > >>>>> On 04.09.12 at 10:13, Sander Eikelenboom wrote: > >>> Hmm don't know how to get the file/line, only thing i have found is: > >>> > >>> serveerstertje:/boot# gdb xen-syms-4.2.0-rc4-pre > >>> GNU gdb (GDB) 7.0.1-debian > >>> Copyright (C) 2009 Free Software Foundation, Inc. > >>> License GPLv3+: GNU GPL version 3 or later > >>> This is free software: you are free to change and redistribute it. > >>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" > >>> and "show warranty" for details. > >>> This GDB was configured as "x86_64-linux-gnu". > >>> For bug reporting instructions, please see: > >>> ... > >>> Reading symbols from /boot/xen-syms-4.2.0-rc4-pre...done. > >>> (gdb) x/i 0xffff82c48015c9ee > >>> 0xffff82c48015c9ee : mov %edx,%gs > >>> (gdb) > >> I'm not really a gdb expert, so I don't know off the top of my > >> head either. I thought I said in a previous reply that people > >> generally appear to use the addr2line utility for that purpose. > >> > >> But the disassembly already tells us where precisely the > >> problem is: The selector value (0x0063) attempted to be put > >> into %gs is apparently wrong in the context of the current > >> GDT. Now, that's GDT_ENTRY_TLS_MIN on the Linux side, > >> and ought to be valid. I'm surprised the guest (and the current > >> process in it) survives this (as the failure here results in a failsafe > >> callback into the guest). > >> > >> Looking at the Linux side of things, this has been that way > >> forever, and I think has always been broken: On x86-64, it > >> should also clear %gs here (since 32-bit processes use it for > >> their TLS, and there's nothing wrong for a 64-bit process to put > >> something in there either), albeit not via loadsegment(), but > >> through xen_load_gs_index(). And I neither see why on 32-bit > >> it only clears %gs - %fs can as much hold a selector that might > >> get invalidated with the TLS descriptor updates. Eduardo, > >> Jeremy, Konrad? > >> > >> Jan > >> > > > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 20:21:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 20:21:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ8xS-0008HP-6y; Tue, 02 Oct 2012 20:20:46 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ8xQ-0008HA-Oj for xen-devel@lists.xen.org; Tue, 02 Oct 2012 20:20:45 +0000 Received: from [85.158.139.211:37572] by server-5.bemta-5.messagelabs.com id 34/C1-21075-C9C4B605; Tue, 02 Oct 2012 20:20:44 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-11.tower-206.messagelabs.com!1349209241!20823222!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc4Nzc1OQ==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21347 invoked from network); 2 Oct 2012 20:20:43 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 20:20:43 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q92KKY4Q022708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Oct 2012 20:20:35 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q92KKXJ2023249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Oct 2012 20:20:33 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q92KKW3l021868; Tue, 2 Oct 2012 15:20:32 -0500 Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 02 Oct 2012 13:20:32 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id CB6FF4032D; Tue, 2 Oct 2012 16:09:07 -0400 (EDT) Date: Tue, 2 Oct 2012 16:09:07 -0400 From: Konrad Rzeszutek Wilk To: Jan Beulich Message-ID: <20121002200907.GC668@phenom.dumpdata.com> References: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4B98@SJCPMAILBOX01.citrite.net> <40501859.20120902104331@eikelenboom.it> <5044849002000078000982EA@nat28.tlf.novell.com> <4610648186.20120904090841@eikelenboom.it> <5045CDF302000078000985FB@nat28.tlf.novell.com> <4710608674.20120904101330@eikelenboom.it> <5045E55A02000078000986E4@nat28.tlf.novell.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <5045E55A02000078000986E4@nat28.tlf.novell.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: Jeremy Fitzhardinge , ehabkost@redhat.com, "xen-devel@lists.xen.org" , "wei.wang2@amd.com" , Sander Eikelenboom , Keir Fraser , Santosh Jodh Subject: Re: [Xen-devel] Using debug-key 'o: Dump IOMMU p2m table, locks up machine X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, Sep 04, 2012 at 10:26:18AM +0100, Jan Beulich wrote: > >>> On 04.09.12 at 10:13, Sander Eikelenboom wrote: > > Hmm don't know how to get the file/line, only thing i have found is: > > > > serveerstertje:/boot# gdb xen-syms-4.2.0-rc4-pre > > GNU gdb (GDB) 7.0.1-debian > > Copyright (C) 2009 Free Software Foundation, Inc. > > License GPLv3+: GNU GPL version 3 or later > > This is free software: you are free to change and redistribute it. > > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > > and "show warranty" for details. > > This GDB was configured as "x86_64-linux-gnu". > > For bug reporting instructions, please see: > > ... > > Reading symbols from /boot/xen-syms-4.2.0-rc4-pre...done. > > (gdb) x/i 0xffff82c48015c9ee > > 0xffff82c48015c9ee : mov %edx,%gs > > (gdb) > > I'm not really a gdb expert, so I don't know off the top of my > head either. I thought I said in a previous reply that people > generally appear to use the addr2line utility for that purpose. > > But the disassembly already tells us where precisely the > problem is: The selector value (0x0063) attempted to be put > into %gs is apparently wrong in the context of the current > GDT. Now, that's GDT_ENTRY_TLS_MIN on the Linux side, > and ought to be valid. I'm surprised the guest (and the current > process in it) survives this (as the failure here results in a failsafe > callback into the guest). > > Looking at the Linux side of things, this has been that way > forever, and I think has always been broken: On x86-64, it > should also clear %gs here (since 32-bit processes use it for > their TLS, and there's nothing wrong for a 64-bit process to put > something in there either), albeit not via loadsegment(), but > through xen_load_gs_index(). And I neither see why on 32-bit > it only clears %gs - %fs can as much hold a selector that might > get invalidated with the TLS descriptor updates. Eduardo, > Jeremy, Konrad? How is it on the SLES side? Do you set/restore all of the segment registers? > > Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 20:21:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 20:21:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ8xS-0008HP-6y; Tue, 02 Oct 2012 20:20:46 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ8xQ-0008HA-Oj for xen-devel@lists.xen.org; Tue, 02 Oct 2012 20:20:45 +0000 Received: from [85.158.139.211:37572] by server-5.bemta-5.messagelabs.com id 34/C1-21075-C9C4B605; Tue, 02 Oct 2012 20:20:44 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-11.tower-206.messagelabs.com!1349209241!20823222!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc4Nzc1OQ==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21347 invoked from network); 2 Oct 2012 20:20:43 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 20:20:43 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q92KKY4Q022708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Oct 2012 20:20:35 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q92KKXJ2023249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Oct 2012 20:20:33 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q92KKW3l021868; Tue, 2 Oct 2012 15:20:32 -0500 Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 02 Oct 2012 13:20:32 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id CB6FF4032D; Tue, 2 Oct 2012 16:09:07 -0400 (EDT) Date: Tue, 2 Oct 2012 16:09:07 -0400 From: Konrad Rzeszutek Wilk To: Jan Beulich Message-ID: <20121002200907.GC668@phenom.dumpdata.com> References: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4B98@SJCPMAILBOX01.citrite.net> <40501859.20120902104331@eikelenboom.it> <5044849002000078000982EA@nat28.tlf.novell.com> <4610648186.20120904090841@eikelenboom.it> <5045CDF302000078000985FB@nat28.tlf.novell.com> <4710608674.20120904101330@eikelenboom.it> <5045E55A02000078000986E4@nat28.tlf.novell.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <5045E55A02000078000986E4@nat28.tlf.novell.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: Jeremy Fitzhardinge , ehabkost@redhat.com, "xen-devel@lists.xen.org" , "wei.wang2@amd.com" , Sander Eikelenboom , Keir Fraser , Santosh Jodh Subject: Re: [Xen-devel] Using debug-key 'o: Dump IOMMU p2m table, locks up machine X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, Sep 04, 2012 at 10:26:18AM +0100, Jan Beulich wrote: > >>> On 04.09.12 at 10:13, Sander Eikelenboom wrote: > > Hmm don't know how to get the file/line, only thing i have found is: > > > > serveerstertje:/boot# gdb xen-syms-4.2.0-rc4-pre > > GNU gdb (GDB) 7.0.1-debian > > Copyright (C) 2009 Free Software Foundation, Inc. > > License GPLv3+: GNU GPL version 3 or later > > This is free software: you are free to change and redistribute it. > > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > > and "show warranty" for details. > > This GDB was configured as "x86_64-linux-gnu". > > For bug reporting instructions, please see: > > ... > > Reading symbols from /boot/xen-syms-4.2.0-rc4-pre...done. > > (gdb) x/i 0xffff82c48015c9ee > > 0xffff82c48015c9ee : mov %edx,%gs > > (gdb) > > I'm not really a gdb expert, so I don't know off the top of my > head either. I thought I said in a previous reply that people > generally appear to use the addr2line utility for that purpose. > > But the disassembly already tells us where precisely the > problem is: The selector value (0x0063) attempted to be put > into %gs is apparently wrong in the context of the current > GDT. Now, that's GDT_ENTRY_TLS_MIN on the Linux side, > and ought to be valid. I'm surprised the guest (and the current > process in it) survives this (as the failure here results in a failsafe > callback into the guest). > > Looking at the Linux side of things, this has been that way > forever, and I think has always been broken: On x86-64, it > should also clear %gs here (since 32-bit processes use it for > their TLS, and there's nothing wrong for a 64-bit process to put > something in there either), albeit not via loadsegment(), but > through xen_load_gs_index(). And I neither see why on 32-bit > it only clears %gs - %fs can as much hold a selector that might > get invalidated with the TLS descriptor updates. Eduardo, > Jeremy, Konrad? How is it on the SLES side? Do you set/restore all of the segment registers? > > Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 20:24:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 20:24:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ90e-000065-RS; Tue, 02 Oct 2012 20:24:04 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ90d-00005u-My for Xen-devel@lists.xen.org; Tue, 02 Oct 2012 20:24:04 +0000 Received: from [85.158.138.51:3819] by server-3.bemta-3.messagelabs.com id 64/45-25962-26D4B605; Tue, 02 Oct 2012 20:24:02 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1349209440!31153934!1 X-Originating-IP: [209.85.213.173] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11597 invoked from network); 2 Oct 2012 20:24:01 -0000 Received: from mail-yx0-f173.google.com (HELO mail-yx0-f173.google.com) (209.85.213.173) by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 20:24:01 -0000 Received: by yenl3 with SMTP id l3so2046722yen.32 for ; Tue, 02 Oct 2012 13:24:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YAxBYofsvXyQwAT6L2hXGcciL5dHIZ7Kei5KY0V6nPE=; b=GOLJT5BmXOVdVO8HMWxPRi7no+RGLDpzeroG7HZsY4IbpXmZyGDZZXhxKuxdB7DVNC e9wbgmMcMRTE/X0VmZu/yuuKGmEBh1A9thrl75hqLUP1GH0HVzqUzSwoDwRKRa2OTrnj cPJPInOwHVEy7QW50fZyIzAPjZV3yF69WWqnvTY5JUApejEv4U5Bv7ETNF3VvMS5ARBn ceTdJGSBaBHN52ZSAoT71VQF21GHU9XNN/NXto4EHuvtSlzm14UwkLjCwb5TwRix1HY9 wljTiBNFor67yX+kl7WQtBUaevkstPBFeEvQffNQLR5ZA4GAbPnCYw3zVVGyWqcJZXrF kGkQ== MIME-Version: 1.0 Received: by 10.236.155.71 with SMTP id i47mr17165423yhk.72.1349209440052; Tue, 02 Oct 2012 13:24:00 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Tue, 2 Oct 2012 13:23:59 -0700 (PDT) In-Reply-To: References: <20121001164757.GF8912@reaktio.net> <20121001182437.GG8912@reaktio.net> <20121002121932.GL8912@reaktio.net> <20121002144251.GP8912@reaktio.net> Date: Tue, 2 Oct 2012 23:23:59 +0300 Message-ID: From: Valtteri Kiviniemi To: Konrad Rzeszutek Wilk Cc: Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.0.4, kernel 3.5.0 HVM crash and kernel BUG X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2406388433150503054==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============2406388433150503054== Content-Type: multipart/alternative; boundary=20cf303b426966e5d004cb194d53 --20cf303b426966e5d004cb194d53 Content-Type: text/plain; charset=ISO-8859-1 Hi, Yes, they are all loaded and I'm running Linux PV-virtuals at the same time with no problems. Only HVM is not working. I have single socket corei7 processor and NUMA enabled on dom0 kernel, so I will try tomorrow to compile dom0 kernel without NUMA, since its not needed and it could probably cause some kind of memory related problems. I will also try Debian squeezes package Xen and test if it is working with my hardware. - Valtteri 2012/10/2 Konrad Rzeszutek Wilk > On Tue, Oct 2, 2012 at 10:55 AM, Valtteri Kiviniemi > wrote: > > Hi, > > > > Yes, I understood for what the parameters were for. I'ts been a long time > > since I last had major problems with Xen (maybe 3.1 or something, been > using > > Xen since version 2) and I had a shady recollection that Xen was > required to > > be build debugging enabled in order to get any usable debugging data. > > > > But anyway, I cant reproduce that kernel crash everytime, it just happens > > sometimes. Major problem is the black screen on VNC and second problem > seems > > to be that everytime i try to run Linux in HVM mode it somehow breaks the > > hotplug scripts. > > > > So do you have all backends loaded? Is xen-netback and xen-blkback running? > Do you also have tun loaded? > --20cf303b426966e5d004cb194d53 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Yes, they are all loaded and I'm running Linux PV-virtuals a= t the same time with no problems. Only HVM is not working. I have single so= cket corei7 processor and NUMA enabled on dom0 kernel, so I will try tomorr= ow to compile dom0 kernel without NUMA, since its not needed and it could p= robably cause some kind of memory related problems.

I will also try Debian squeezes package Xen and test if it is working w= ith my hardware.

- Valtteri

2012/1= 0/2 Konrad Rzeszutek Wilk <konrad@kernel.org>
On Tue, Oct 2, 2012 at 10:= 55 AM, Valtteri Kiviniemi
<kiviniemi.valtteri@gmai= l.com> wrote:
> Hi,
>
> Yes, I understood for what the parameters were for. I'ts been a lo= ng time
> since I last had major problems with Xen (maybe 3.1 or something, been= using
> Xen since version 2) and I had a shady recollection that Xen was requi= red to
> be build debugging enabled in order to get any usable debugging data.<= br> >
> But anyway, I cant reproduce that kernel crash everytime, it just happ= ens
> sometimes. Major problem is the black screen on VNC and second problem= seems
> to be that everytime i try to run Linux in HVM mode it somehow breaks = the
> hotplug scripts.
>

So do you have all backends loaded? Is xen-netback and xen-blkback ru= nning?
Do you also have tun loaded?

--20cf303b426966e5d004cb194d53-- --===============2406388433150503054== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============2406388433150503054==-- From xen-devel-bounces@lists.xen.org Tue Oct 02 20:24:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 20:24:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ90e-000065-RS; Tue, 02 Oct 2012 20:24:04 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ90d-00005u-My for Xen-devel@lists.xen.org; Tue, 02 Oct 2012 20:24:04 +0000 Received: from [85.158.138.51:3819] by server-3.bemta-3.messagelabs.com id 64/45-25962-26D4B605; Tue, 02 Oct 2012 20:24:02 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1349209440!31153934!1 X-Originating-IP: [209.85.213.173] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11597 invoked from network); 2 Oct 2012 20:24:01 -0000 Received: from mail-yx0-f173.google.com (HELO mail-yx0-f173.google.com) (209.85.213.173) by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 20:24:01 -0000 Received: by yenl3 with SMTP id l3so2046722yen.32 for ; Tue, 02 Oct 2012 13:24:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YAxBYofsvXyQwAT6L2hXGcciL5dHIZ7Kei5KY0V6nPE=; b=GOLJT5BmXOVdVO8HMWxPRi7no+RGLDpzeroG7HZsY4IbpXmZyGDZZXhxKuxdB7DVNC e9wbgmMcMRTE/X0VmZu/yuuKGmEBh1A9thrl75hqLUP1GH0HVzqUzSwoDwRKRa2OTrnj cPJPInOwHVEy7QW50fZyIzAPjZV3yF69WWqnvTY5JUApejEv4U5Bv7ETNF3VvMS5ARBn ceTdJGSBaBHN52ZSAoT71VQF21GHU9XNN/NXto4EHuvtSlzm14UwkLjCwb5TwRix1HY9 wljTiBNFor67yX+kl7WQtBUaevkstPBFeEvQffNQLR5ZA4GAbPnCYw3zVVGyWqcJZXrF kGkQ== MIME-Version: 1.0 Received: by 10.236.155.71 with SMTP id i47mr17165423yhk.72.1349209440052; Tue, 02 Oct 2012 13:24:00 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Tue, 2 Oct 2012 13:23:59 -0700 (PDT) In-Reply-To: References: <20121001164757.GF8912@reaktio.net> <20121001182437.GG8912@reaktio.net> <20121002121932.GL8912@reaktio.net> <20121002144251.GP8912@reaktio.net> Date: Tue, 2 Oct 2012 23:23:59 +0300 Message-ID: From: Valtteri Kiviniemi To: Konrad Rzeszutek Wilk Cc: Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.0.4, kernel 3.5.0 HVM crash and kernel BUG X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2406388433150503054==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============2406388433150503054== Content-Type: multipart/alternative; boundary=20cf303b426966e5d004cb194d53 --20cf303b426966e5d004cb194d53 Content-Type: text/plain; charset=ISO-8859-1 Hi, Yes, they are all loaded and I'm running Linux PV-virtuals at the same time with no problems. Only HVM is not working. I have single socket corei7 processor and NUMA enabled on dom0 kernel, so I will try tomorrow to compile dom0 kernel without NUMA, since its not needed and it could probably cause some kind of memory related problems. I will also try Debian squeezes package Xen and test if it is working with my hardware. - Valtteri 2012/10/2 Konrad Rzeszutek Wilk > On Tue, Oct 2, 2012 at 10:55 AM, Valtteri Kiviniemi > wrote: > > Hi, > > > > Yes, I understood for what the parameters were for. I'ts been a long time > > since I last had major problems with Xen (maybe 3.1 or something, been > using > > Xen since version 2) and I had a shady recollection that Xen was > required to > > be build debugging enabled in order to get any usable debugging data. > > > > But anyway, I cant reproduce that kernel crash everytime, it just happens > > sometimes. Major problem is the black screen on VNC and second problem > seems > > to be that everytime i try to run Linux in HVM mode it somehow breaks the > > hotplug scripts. > > > > So do you have all backends loaded? Is xen-netback and xen-blkback running? > Do you also have tun loaded? > --20cf303b426966e5d004cb194d53 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Yes, they are all loaded and I'm running Linux PV-virtuals a= t the same time with no problems. Only HVM is not working. I have single so= cket corei7 processor and NUMA enabled on dom0 kernel, so I will try tomorr= ow to compile dom0 kernel without NUMA, since its not needed and it could p= robably cause some kind of memory related problems.

I will also try Debian squeezes package Xen and test if it is working w= ith my hardware.

- Valtteri

2012/1= 0/2 Konrad Rzeszutek Wilk <konrad@kernel.org>
On Tue, Oct 2, 2012 at 10:= 55 AM, Valtteri Kiviniemi
<kiviniemi.valtteri@gmai= l.com> wrote:
> Hi,
>
> Yes, I understood for what the parameters were for. I'ts been a lo= ng time
> since I last had major problems with Xen (maybe 3.1 or something, been= using
> Xen since version 2) and I had a shady recollection that Xen was requi= red to
> be build debugging enabled in order to get any usable debugging data.<= br> >
> But anyway, I cant reproduce that kernel crash everytime, it just happ= ens
> sometimes. Major problem is the black screen on VNC and second problem= seems
> to be that everytime i try to run Linux in HVM mode it somehow breaks = the
> hotplug scripts.
>

So do you have all backends loaded? Is xen-netback and xen-blkback ru= nning?
Do you also have tun loaded?

--20cf303b426966e5d004cb194d53-- --===============2406388433150503054== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============2406388433150503054==-- From xen-devel-bounces@lists.xen.org Tue Oct 02 20:52:11 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 20:52:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ9RW-0000Sv-Ef; Tue, 02 Oct 2012 20:51:50 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ9RU-0000So-8O for Xen-devel@lists.xen.org; Tue, 02 Oct 2012 20:51:48 +0000 Received: from [85.158.143.35:60389] by server-2.bemta-4.messagelabs.com id 3F/E9-06610-3E35B605; Tue, 02 Oct 2012 20:51:47 +0000 X-Env-Sender: xinxinjin89@gmail.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1349211105!6307284!1 X-Originating-IP: [209.85.216.173] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20776 invoked from network); 2 Oct 2012 20:51:47 -0000 Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com) (209.85.216.173) by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 20:51:47 -0000 Received: by qcab12 with SMTP id b12so6853770qca.32 for ; Tue, 02 Oct 2012 13:51:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=GbSmt5Q7jJur9kykXguZ5Ax8lk6b1k7p2Veh9Opluwg=; b=TSWffR3K5dM6Nmu3g65xAoq6LMvwfClHFO6ouUH2fUPHpuEmlGy3tcoPtiXLatxDRL lvKR0RmDWFW9n8QfCFuMju1dZWOdqgjISBJ2DRvzod00wbE3iNlH1YtLMXYQd/3577tE WSYwJ+/9zFwHgphzEycVFV3xVHidK3vcX7jVSMxm8blwwgdlLc2u3dAHLtD8voTWtd+s T0JAXKzvUYMmRwwkoP5ztPpEUC4hSV0vrkjRrpaP8wTl6guD0d/Tyd6r4I2QtI4KNckn bwmi9+lauEIXZi2slsSDJXQn/9T+5CU49EZZya9J+eAtO5u3RQxTShJl4sTNVimkjU/C 51sQ== MIME-Version: 1.0 Received: by 10.49.71.107 with SMTP id t11mr7774117qeu.13.1349211105715; Tue, 02 Oct 2012 13:51:45 -0700 (PDT) Received: by 10.229.176.85 with HTTP; Tue, 2 Oct 2012 13:51:45 -0700 (PDT) Date: Tue, 2 Oct 2012 13:51:45 -0700 Message-ID: From: Xinxin Jin To: Xen-devel@lists.xen.org Subject: [Xen-devel] The entry of Xen's exception handler X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8240598660083720638==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============8240598660083720638== Content-Type: multipart/alternative; boundary=047d7b6da4c6aee78204cb19b0fd --047d7b6da4c6aee78204cb19b0fd Content-Type: text/plain; charset=ISO-8859-1 Hi, I am trying to understand the exception handler of Xen. In xen/arch/x86/x86_64/entry.S, the entry of the page fault handler is : ENTRY(page_fault) movl $TRAP_page_fault,4(%rsp) jmp handle_exception Here I did not get why to put the exception vector ($TRAP_page_fault) to stack before calling handle_exception? Thanks, -- Xinxin --047d7b6da4c6aee78204cb19b0fd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, I am trying to understand the exception handler of Xen. In xen/arch/x86= /x86_64/entry.S, the entry of the page fault handler is :

ENTR= Y(page_fault)
=A0 =A0 =A0 =A0 movl =A0$TRAP_page_fault,4(%rsp)
=A0 =A0 =A0 =A0 jmp =A0 handle_exception

Here I did not get why to put the exception vector= ($TRAP_page_fault) to stack before calling handle_exception?
Thanks,

--
Xinxin

--047d7b6da4c6aee78204cb19b0fd-- --===============8240598660083720638== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8240598660083720638==-- From xen-devel-bounces@lists.xen.org Tue Oct 02 20:52:11 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 20:52:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ9RW-0000Sv-Ef; Tue, 02 Oct 2012 20:51:50 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ9RU-0000So-8O for Xen-devel@lists.xen.org; Tue, 02 Oct 2012 20:51:48 +0000 Received: from [85.158.143.35:60389] by server-2.bemta-4.messagelabs.com id 3F/E9-06610-3E35B605; Tue, 02 Oct 2012 20:51:47 +0000 X-Env-Sender: xinxinjin89@gmail.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1349211105!6307284!1 X-Originating-IP: [209.85.216.173] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20776 invoked from network); 2 Oct 2012 20:51:47 -0000 Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com) (209.85.216.173) by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 20:51:47 -0000 Received: by qcab12 with SMTP id b12so6853770qca.32 for ; Tue, 02 Oct 2012 13:51:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=GbSmt5Q7jJur9kykXguZ5Ax8lk6b1k7p2Veh9Opluwg=; b=TSWffR3K5dM6Nmu3g65xAoq6LMvwfClHFO6ouUH2fUPHpuEmlGy3tcoPtiXLatxDRL lvKR0RmDWFW9n8QfCFuMju1dZWOdqgjISBJ2DRvzod00wbE3iNlH1YtLMXYQd/3577tE WSYwJ+/9zFwHgphzEycVFV3xVHidK3vcX7jVSMxm8blwwgdlLc2u3dAHLtD8voTWtd+s T0JAXKzvUYMmRwwkoP5ztPpEUC4hSV0vrkjRrpaP8wTl6guD0d/Tyd6r4I2QtI4KNckn bwmi9+lauEIXZi2slsSDJXQn/9T+5CU49EZZya9J+eAtO5u3RQxTShJl4sTNVimkjU/C 51sQ== MIME-Version: 1.0 Received: by 10.49.71.107 with SMTP id t11mr7774117qeu.13.1349211105715; Tue, 02 Oct 2012 13:51:45 -0700 (PDT) Received: by 10.229.176.85 with HTTP; Tue, 2 Oct 2012 13:51:45 -0700 (PDT) Date: Tue, 2 Oct 2012 13:51:45 -0700 Message-ID: From: Xinxin Jin To: Xen-devel@lists.xen.org Subject: [Xen-devel] The entry of Xen's exception handler X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8240598660083720638==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============8240598660083720638== Content-Type: multipart/alternative; boundary=047d7b6da4c6aee78204cb19b0fd --047d7b6da4c6aee78204cb19b0fd Content-Type: text/plain; charset=ISO-8859-1 Hi, I am trying to understand the exception handler of Xen. In xen/arch/x86/x86_64/entry.S, the entry of the page fault handler is : ENTRY(page_fault) movl $TRAP_page_fault,4(%rsp) jmp handle_exception Here I did not get why to put the exception vector ($TRAP_page_fault) to stack before calling handle_exception? Thanks, -- Xinxin --047d7b6da4c6aee78204cb19b0fd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, I am trying to understand the exception handler of Xen. In xen/arch/x86= /x86_64/entry.S, the entry of the page fault handler is :

ENTR= Y(page_fault)
=A0 =A0 =A0 =A0 movl =A0$TRAP_page_fault,4(%rsp)
=A0 =A0 =A0 =A0 jmp =A0 handle_exception

Here I did not get why to put the exception vector= ($TRAP_page_fault) to stack before calling handle_exception?
Thanks,

--
Xinxin

--047d7b6da4c6aee78204cb19b0fd-- --===============8240598660083720638== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8240598660083720638==-- From xen-devel-bounces@lists.xen.org Tue Oct 02 20:55:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 20:55:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ9Uj-0000ZP-2B; Tue, 02 Oct 2012 20:55:09 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ9Ui-0000ZH-4x for xen-devel@lists.xen.org; Tue, 02 Oct 2012 20:55:08 +0000 Received: from [85.158.139.83:30607] by server-6.bemta-5.messagelabs.com id AA/12-14717-BA45B605; Tue, 02 Oct 2012 20:55:07 +0000 X-Env-Sender: msw@amazon.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1349211303!28842564!1 X-Originating-IP: [207.171.178.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjA3LjE3MS4xNzguMjUgPT4gNzMyODg=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18219 invoked from network); 2 Oct 2012 20:55:05 -0000 Received: from smtp-fw-31001.amazon.com (HELO smtp-fw-31001.amazon.com) (207.171.178.25) by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 20:55:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=msw@amazon.com; q=dns/txt; s=amazon201209; t=1349211306; x=1380747306; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=f+HhfuhiXyrMQShoQ7Dc5pn3Q9T4KF4kGjdv8r30jd0=; b=TIc0sx12MwXHFMy3DQRVfxgYljUc6AOxpPsL/1MCDeUqvRhFyjP2u0El YUz63CITVKTiUpD7sXFBreJFL7hZIJ8WPWs1CFcjxiJu+OTBOuIRWipNR mCMjXnUP0gVHsxbWsj+RJDxbKRcE0Pi7iCSTjTBdw2hvrFAUKf59RRUml 0=; X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="303029087" Received: from smtp-in-31001.sea31.amazon.com ([10.184.168.27]) by smtp-border-fw-out-31001.sea31.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Oct 2012 20:55:03 +0000 Received: from ex10-hub-9003.ant.amazon.com (ex10-hub-9003.ant.amazon.com [10.185.137.132]) by smtp-in-31001.sea31.amazon.com (8.13.8/8.13.8) with ESMTP id q92KsxEY028960 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Oct 2012 20:54:59 GMT Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.41) by ex10-hub-9003.ant.amazon.com (10.185.137.132) with Microsoft SMTP Server id 14.2.247.3; Tue, 2 Oct 2012 13:54:58 -0700 Received: by u002268147cd4502c336d.ant.amazon.com (sSMTP sendmail emulation); Tue, 02 Oct 2012 13:54:58 -0700 Date: Tue, 2 Oct 2012 13:54:58 -0700 From: Matt Wilson To: Jan Beulich Message-ID: <20121002205456.GA15862@u002268147cd4502c336d.ant.amazon.com> References: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4B98@SJCPMAILBOX01.citrite.net> <40501859.20120902104331@eikelenboom.it> <5044849002000078000982EA@nat28.tlf.novell.com> <4610648186.20120904090841@eikelenboom.it> <5045CDF302000078000985FB@nat28.tlf.novell.com> <4710608674.20120904101330@eikelenboom.it> <5045E55A02000078000986E4@nat28.tlf.novell.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <5045E55A02000078000986E4@nat28.tlf.novell.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Jeremy Fitzhardinge , ehabkost@redhat.com, Konrad Rzeszutek Wilk , "xen-devel@lists.xen.org" , "wei.wang2@amd.com" , Sander Eikelenboom , Keir Fraser , Santosh Jodh Subject: Re: [Xen-devel] Using debug-key 'o: Dump IOMMU p2m table, locks up machine X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, Sep 04, 2012 at 10:26:18AM +0100, Jan Beulich wrote: > >>> On 04.09.12 at 10:13, Sander Eikelenboom wrote: > > Hmm don't know how to get the file/line, only thing i have found is: > > > > serveerstertje:/boot# gdb xen-syms-4.2.0-rc4-pre > > GNU gdb (GDB) 7.0.1-debian > > Copyright (C) 2009 Free Software Foundation, Inc. > > License GPLv3+: GNU GPL version 3 or later > > This is free software: you are free to change and redistribute it. > > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > > and "show warranty" for details. > > This GDB was configured as "x86_64-linux-gnu". > > For bug reporting instructions, please see: > > ... > > Reading symbols from /boot/xen-syms-4.2.0-rc4-pre...done. > > (gdb) x/i 0xffff82c48015c9ee > > 0xffff82c48015c9ee : mov %edx,%gs > > (gdb) > > I'm not really a gdb expert, so I don't know off the top of my > head either. I thought I said in a previous reply that people > generally appear to use the addr2line utility for that purpose. addr2line works, but "l *0xffff82c48015c9ee" in gdb should as well. Matt _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 20:55:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 20:55:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ9Uj-0000ZP-2B; Tue, 02 Oct 2012 20:55:09 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ9Ui-0000ZH-4x for xen-devel@lists.xen.org; Tue, 02 Oct 2012 20:55:08 +0000 Received: from [85.158.139.83:30607] by server-6.bemta-5.messagelabs.com id AA/12-14717-BA45B605; Tue, 02 Oct 2012 20:55:07 +0000 X-Env-Sender: msw@amazon.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1349211303!28842564!1 X-Originating-IP: [207.171.178.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjA3LjE3MS4xNzguMjUgPT4gNzMyODg=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18219 invoked from network); 2 Oct 2012 20:55:05 -0000 Received: from smtp-fw-31001.amazon.com (HELO smtp-fw-31001.amazon.com) (207.171.178.25) by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 20:55:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=msw@amazon.com; q=dns/txt; s=amazon201209; t=1349211306; x=1380747306; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=f+HhfuhiXyrMQShoQ7Dc5pn3Q9T4KF4kGjdv8r30jd0=; b=TIc0sx12MwXHFMy3DQRVfxgYljUc6AOxpPsL/1MCDeUqvRhFyjP2u0El YUz63CITVKTiUpD7sXFBreJFL7hZIJ8WPWs1CFcjxiJu+OTBOuIRWipNR mCMjXnUP0gVHsxbWsj+RJDxbKRcE0Pi7iCSTjTBdw2hvrFAUKf59RRUml 0=; X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="303029087" Received: from smtp-in-31001.sea31.amazon.com ([10.184.168.27]) by smtp-border-fw-out-31001.sea31.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Oct 2012 20:55:03 +0000 Received: from ex10-hub-9003.ant.amazon.com (ex10-hub-9003.ant.amazon.com [10.185.137.132]) by smtp-in-31001.sea31.amazon.com (8.13.8/8.13.8) with ESMTP id q92KsxEY028960 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Oct 2012 20:54:59 GMT Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.41) by ex10-hub-9003.ant.amazon.com (10.185.137.132) with Microsoft SMTP Server id 14.2.247.3; Tue, 2 Oct 2012 13:54:58 -0700 Received: by u002268147cd4502c336d.ant.amazon.com (sSMTP sendmail emulation); Tue, 02 Oct 2012 13:54:58 -0700 Date: Tue, 2 Oct 2012 13:54:58 -0700 From: Matt Wilson To: Jan Beulich Message-ID: <20121002205456.GA15862@u002268147cd4502c336d.ant.amazon.com> References: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4B98@SJCPMAILBOX01.citrite.net> <40501859.20120902104331@eikelenboom.it> <5044849002000078000982EA@nat28.tlf.novell.com> <4610648186.20120904090841@eikelenboom.it> <5045CDF302000078000985FB@nat28.tlf.novell.com> <4710608674.20120904101330@eikelenboom.it> <5045E55A02000078000986E4@nat28.tlf.novell.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <5045E55A02000078000986E4@nat28.tlf.novell.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Jeremy Fitzhardinge , ehabkost@redhat.com, Konrad Rzeszutek Wilk , "xen-devel@lists.xen.org" , "wei.wang2@amd.com" , Sander Eikelenboom , Keir Fraser , Santosh Jodh Subject: Re: [Xen-devel] Using debug-key 'o: Dump IOMMU p2m table, locks up machine X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, Sep 04, 2012 at 10:26:18AM +0100, Jan Beulich wrote: > >>> On 04.09.12 at 10:13, Sander Eikelenboom wrote: > > Hmm don't know how to get the file/line, only thing i have found is: > > > > serveerstertje:/boot# gdb xen-syms-4.2.0-rc4-pre > > GNU gdb (GDB) 7.0.1-debian > > Copyright (C) 2009 Free Software Foundation, Inc. > > License GPLv3+: GNU GPL version 3 or later > > This is free software: you are free to change and redistribute it. > > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > > and "show warranty" for details. > > This GDB was configured as "x86_64-linux-gnu". > > For bug reporting instructions, please see: > > ... > > Reading symbols from /boot/xen-syms-4.2.0-rc4-pre...done. > > (gdb) x/i 0xffff82c48015c9ee > > 0xffff82c48015c9ee : mov %edx,%gs > > (gdb) > > I'm not really a gdb expert, so I don't know off the top of my > head either. I thought I said in a previous reply that people > generally appear to use the addr2line utility for that purpose. addr2line works, but "l *0xffff82c48015c9ee" in gdb should as well. Matt _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 21:23:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 21:23:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ9vq-0000tI-Gg; Tue, 02 Oct 2012 21:23:10 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ9vo-0000tA-Su for xen-devel@lists.xen.org; Tue, 02 Oct 2012 21:23:09 +0000 Received: from [85.158.138.51:57090] by server-7.bemta-3.messagelabs.com id 52/EE-15765-B3B5B605; Tue, 02 Oct 2012 21:23:07 +0000 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-5.tower-174.messagelabs.com!1349212987!32928900!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2543 invoked from network); 2 Oct 2012 21:23:07 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 21:23:07 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="14903227" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 21:23:06 +0000 Received: from [10.30.249.82] (10.30.249.82) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 22:23:06 +0100 Message-ID: <506B5B39.4010205@citrix.com> Date: Tue, 2 Oct 2012 22:23:05 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: References: In-Reply-To: Subject: Re: [Xen-devel] The entry of Xen's exception handler X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 02/10/2012 21:51, Xinxin Jin wrote: > Hi, I am trying to understand the exception handler of Xen. In > xen/arch/x86/x86_64/entry.S, the entry of the page fault handler is : > > ENTRY(page_fault) > movl $TRAP_page_fault,4(%rsp) > jmp handle_exception > > Here I did not get why to put the exception vector ($TRAP_page_fault) > to stack before calling handle_exception? This is so every single exception fills in its cpu_user_regs with the correct trap, so the C code an distinguish if its needs to. (See current.h for the structures which get filled in) ~Andrew > > Thanks, > > -- > Xinxin > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 21:23:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 21:23:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ9vq-0000tI-Gg; Tue, 02 Oct 2012 21:23:10 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ9vo-0000tA-Su for xen-devel@lists.xen.org; Tue, 02 Oct 2012 21:23:09 +0000 Received: from [85.158.138.51:57090] by server-7.bemta-3.messagelabs.com id 52/EE-15765-B3B5B605; Tue, 02 Oct 2012 21:23:07 +0000 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-5.tower-174.messagelabs.com!1349212987!32928900!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2543 invoked from network); 2 Oct 2012 21:23:07 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 21:23:07 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="14903227" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 21:23:06 +0000 Received: from [10.30.249.82] (10.30.249.82) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 22:23:06 +0100 Message-ID: <506B5B39.4010205@citrix.com> Date: Tue, 2 Oct 2012 22:23:05 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: References: In-Reply-To: Subject: Re: [Xen-devel] The entry of Xen's exception handler X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 02/10/2012 21:51, Xinxin Jin wrote: > Hi, I am trying to understand the exception handler of Xen. In > xen/arch/x86/x86_64/entry.S, the entry of the page fault handler is : > > ENTRY(page_fault) > movl $TRAP_page_fault,4(%rsp) > jmp handle_exception > > Here I did not get why to put the exception vector ($TRAP_page_fault) > to stack before calling handle_exception? This is so every single exception fills in its cpu_user_regs with the correct trap, so the C code an distinguish if its needs to. (See current.h for the structures which get filled in) ~Andrew > > Thanks, > > -- > Xinxin > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 21:31:15 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 21:31:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJA3M-00012U-Fk; Tue, 02 Oct 2012 21:30:56 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJA3L-00012P-0A for Xen-devel@lists.xen.org; Tue, 02 Oct 2012 21:30:55 +0000 Received: from [85.158.139.211:7364] by server-3.bemta-5.messagelabs.com id D3/8D-16108-E0D5B605; Tue, 02 Oct 2012 21:30:54 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-16.tower-206.messagelabs.com!1349213453!20861048!1 X-Originating-IP: [74.125.82.51] X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16022 invoked from network); 2 Oct 2012 21:30:53 -0000 Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com) (74.125.82.51) by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 21:30:53 -0000 Received: by wgbed3 with SMTP id ed3so3174589wgb.32 for ; Tue, 02 Oct 2012 14:30:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=QZ2zIlwe5xsKy+bzk+KVzKc+6Gw8J/6bOnDPR5iVIWw=; b=lX5q/PS2EtCCTakUDcZELaIk9+KSWB21bztGqnOk/Vy02u83sqtjPFs5ICs98jpejb vFnda9/FVeHEWR9ZletYXWFcj/S6mNacNoZJualE1AaS44+6HnDHqJnrbKXJNyCz/4R2 nH9RHiTlY9rBQzdAjBKnwMV/co+yiiAYJq5EhdVjv9K/ug7+B7mN5odTuMYaRaDCs6SD LcHXbTJBjxV5MRh/sssXGOxNwfMnXsjoZJ2j1jMXhxeT5dhECihMms2y/ZN9/divaqDk LD1FTDKTxN6ULPegmCtzZos2EtgnAOsylqrkLyy4sU3Mz/Y5SPdZio7IIRaN9BfrxUdA 6wDQ== Received: by 10.216.195.211 with SMTP id p61mr25841wen.94.1349213453483; Tue, 02 Oct 2012 14:30:53 -0700 (PDT) Received: from [192.168.1.69] (host86-183-156-141.range86-183.btcentralplus.com. [86.183.156.141]) by mx.google.com with ESMTPS id q7sm4521286wiy.11.2012.10.02.14.30.51 (version=SSLv3 cipher=OTHER); Tue, 02 Oct 2012 14:30:52 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Tue, 02 Oct 2012 22:30:49 +0100 From: Keir Fraser To: Xinxin Jin , Message-ID: Thread-Topic: [Xen-devel] The entry of Xen's exception handler Thread-Index: Ac2g5TDIEdAkF83j00Kkw177JsyWbw== In-Reply-To: Mime-version: 1.0 Subject: Re: [Xen-devel] The entry of Xen's exception handler X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 02/10/2012 21:51, "Xinxin Jin" wrote: > Hi, I am trying to understand the exception handler of Xen. In > xen/arch/x86/x86_64/entry.S, the entry of the page fault handler is : > = > ENTRY(page_fault) > =A0 =A0 =A0 =A0 movl =A0$TRAP_page_fault,4(%rsp) > =A0 =A0 =A0 =A0 jmp =A0 handle_exception > = > Here I did not get why to put the exception vector ($TRAP_page_fault) to = stack > before calling handle_exception? Otherwise handle_exception would not know which type of exception it was handling, would it. -- Keir > Thanks, _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 21:31:15 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 21:31:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJA3M-00012U-Fk; Tue, 02 Oct 2012 21:30:56 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJA3L-00012P-0A for Xen-devel@lists.xen.org; Tue, 02 Oct 2012 21:30:55 +0000 Received: from [85.158.139.211:7364] by server-3.bemta-5.messagelabs.com id D3/8D-16108-E0D5B605; Tue, 02 Oct 2012 21:30:54 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-16.tower-206.messagelabs.com!1349213453!20861048!1 X-Originating-IP: [74.125.82.51] X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16022 invoked from network); 2 Oct 2012 21:30:53 -0000 Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com) (74.125.82.51) by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 21:30:53 -0000 Received: by wgbed3 with SMTP id ed3so3174589wgb.32 for ; Tue, 02 Oct 2012 14:30:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=QZ2zIlwe5xsKy+bzk+KVzKc+6Gw8J/6bOnDPR5iVIWw=; b=lX5q/PS2EtCCTakUDcZELaIk9+KSWB21bztGqnOk/Vy02u83sqtjPFs5ICs98jpejb vFnda9/FVeHEWR9ZletYXWFcj/S6mNacNoZJualE1AaS44+6HnDHqJnrbKXJNyCz/4R2 nH9RHiTlY9rBQzdAjBKnwMV/co+yiiAYJq5EhdVjv9K/ug7+B7mN5odTuMYaRaDCs6SD LcHXbTJBjxV5MRh/sssXGOxNwfMnXsjoZJ2j1jMXhxeT5dhECihMms2y/ZN9/divaqDk LD1FTDKTxN6ULPegmCtzZos2EtgnAOsylqrkLyy4sU3Mz/Y5SPdZio7IIRaN9BfrxUdA 6wDQ== Received: by 10.216.195.211 with SMTP id p61mr25841wen.94.1349213453483; Tue, 02 Oct 2012 14:30:53 -0700 (PDT) Received: from [192.168.1.69] (host86-183-156-141.range86-183.btcentralplus.com. [86.183.156.141]) by mx.google.com with ESMTPS id q7sm4521286wiy.11.2012.10.02.14.30.51 (version=SSLv3 cipher=OTHER); Tue, 02 Oct 2012 14:30:52 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Tue, 02 Oct 2012 22:30:49 +0100 From: Keir Fraser To: Xinxin Jin , Message-ID: Thread-Topic: [Xen-devel] The entry of Xen's exception handler Thread-Index: Ac2g5TDIEdAkF83j00Kkw177JsyWbw== In-Reply-To: Mime-version: 1.0 Subject: Re: [Xen-devel] The entry of Xen's exception handler X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 02/10/2012 21:51, "Xinxin Jin" wrote: > Hi, I am trying to understand the exception handler of Xen. In > xen/arch/x86/x86_64/entry.S, the entry of the page fault handler is : > = > ENTRY(page_fault) > =A0 =A0 =A0 =A0 movl =A0$TRAP_page_fault,4(%rsp) > =A0 =A0 =A0 =A0 jmp =A0 handle_exception > = > Here I did not get why to put the exception vector ($TRAP_page_fault) to = stack > before calling handle_exception? Otherwise handle_exception would not know which type of exception it was handling, would it. -- Keir > Thanks, _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 21:58:03 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 21:58:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJATB-0001G1-VD; Tue, 02 Oct 2012 21:57:37 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJAT9-0001Fw-Kf for xen-devel@lists.xen.org; Tue, 02 Oct 2012 21:57:35 +0000 X-Env-Sender: dan.magenheimer@oracle.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1349215048!8598996!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc4ODkzOA==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32164 invoked from network); 2 Oct 2012 21:57:29 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 21:57:29 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q92LvFLx008463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Oct 2012 21:57:15 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q92LvEjR010740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Oct 2012 21:57:14 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q92LvDnt016892; Tue, 2 Oct 2012 16:57:13 -0500 MIME-Version: 1.0 Message-ID: Date: Tue, 2 Oct 2012 14:56:57 -0700 (PDT) From: Dan Magenheimer To: Tim Deegan References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> <20121002091017.GA95926@ocelot.phlegethon.org> <66cc0085-1216-40f7-8059-eaf615202c12@default> <20121002201624.GA98445@ocelot.phlegethon.org> In-Reply-To: <20121002201624.GA98445@ocelot.phlegethon.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7 (607090) [OL 12.0.6661.5003 (x86)] X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: Olaf Hering , Keir Fraser , Konrad Wilk , George Dunlap , Kurt Hackel , Ian Jackson , xen-devel@lists.xen.org, George Shuklin , Dario Faggioli , Andres Lagar-Cavilla Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > From: Tim Deegan [mailto:tim@xen.org] > Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) > > At 12:33 -0700 on 02 Oct (1349181195), Dan Magenheimer wrote: > > > From: Tim Deegan [mailto:tim@xen.org] > > > Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) > > > > > > At 13:03 -0700 on 01 Oct (1349096617), Dan Magenheimer wrote: > > > > Bearing in mind that I know almost nothing about xl or > > > > the tools layer, and that, as a result, I tend to look > > > > for hypervisor solutions, I'm thinking it's not possible to > > > > solve this without direct participation of the hypervisor anyway, > > > > at least while ensuring the solution will successfully > > > > work with any memory technology that involves ballooning > > > > with the possibility of overcommit (i.e. tmem, page sharing > > > > and host-swapping, manual ballooning, PoD)... EVEN if the > > > > toolset is single threaded (i.e. only one domain may > > > > be created at a time, such as xapi). [1] > > > > > > TTBOMK, Xapi actually _has_ solved this problem, even with ballooning > > > and PoD. I don't know if they have any plans to support sharing, > > > swapping or tmem, though. > > > > Is this because PoD never independently increases the size of a domain's > > allocation? > > AIUI xapi uses the domains' maximum allocations, centrally controlled, > to place an upper bound on the amount of guest memory that can be in > use. Within those limits there can be ballooning activity. But TBH I > don't know the details. Yes, that's the same as saying there is no memory-overcommit. The original problem occurs only if there are multiple threads of execution that can be simultaneously asking the hypervisor to allocate memory without the knowledge of a single centralized "controller". > > > Adding a 'reservation' of free pages that may only be allocated by a > > > given domain should be straightforward enough, but I'm not sure it helps > > > > It absolutely does help. With tmem (and I think with paging), the > > total allocation of a domain may be increased without knowledge by > > the toolset. > > But not past the domains' maximum allowance, right? That's not the case > with paging, anyway. Right. We can quibble about memory hot-add, depending on its design. > > > much. In the 'balloon-to-fit' model where all memory is already > > > allocated to some domain (or tmem), some part of the toolstack needs to > > > sort out freeing up the memory before allocating it to another VM. > > > > By balloon-to-fit, do you mean that all RAM is occupied? Tmem > > handles the "sort out freeing up the memory" entirely in the > > hypervisor, so the toolstack never knows. > > Does tmem replace ballooning/sharing/swapping entirely? I thought they > could coexist. Or, if you jut mean that tmem owns all otherwise-free > memory and will relinquish it on demand, then the same problems occur > while the toolstack is moving memory from owned-by-guests to > owned-by-tmem. Tmem replaces sharing/swapping entirely for guests that support it. Since kernel changes are required to support it, not all guests will ever support it. Now with full tmem support in the Linux kernel, it is possible that eventually all non-legacy Linux guests will support it. Tmem dynamically handles all the transfer of owned-by memory capacity in the hypervisor, essentially augmenting the page allocator, so the hypervisor is the "controller". Oh, and tmem doesn't replace ballooning at all... it works best with selfballooning (which is also now in the Linux kernel). Ballooning is still a useful mechanism for moving memory capacity between the guest and the hypervisor; tmem caches data and handles policy. > > > Surely that component needs to handle the exclusion too - otherwise a > > > series of small VM creations could stall a large one indefinitely. > > > > Not sure I understand this, but it seems feasible. > > If you ask for a large VM and a small VM to be started at about the same > time, the small VM will always win (since you'll free enough memory for > the small VM before you free enough for the big one). If you then ask > for another small VM it will win again, and so forth, indefinitely > postponing the large VM in the waiting-for-memory state, unless some > agent explicitly enforces that VMs be started in order. If you have > such an agent you probably don't need a hypervisor interlock as well. OK, I see, thanks. > I think it would be better to back up a bit. Maybe you could sketch out > how you think [lib]xl ought to be handling ballooning/swapping/sharing/tmem > when it's starting VMs. I don't have a strong objection to accounting > free memory to particular domains if it turns out to be useful, but as > always I prefer not to have things happen in the hypervisor if they > could happen in less privileged code. I sketched it out earlier in this thread, will attach again below. I agree with your last statement in general, but would modify it to "if they could happen efficiently and effectively in less privileged code". Obviously everything that Xen does can be done in less privileged code... in an emulator. Emulator's just don't do it fast enough. Tmem argues that doing "memory capacity transfers" at a page granularity can only be done efficiently in the hypervisor. This is true for page-sharing when it breaks a "share" also... it can't go ask the toolstack to approve allocation of a new page every time a write to a shared page occurs. Does that make sense? So the original problem must be solved if: 1) Domain creation is not serialized 2) Any domain's current memory allocation can be increased without approval of the toolstack. Problem (1) arose independently and my interest is that it gets solved in a way that (2) can also benefit. Dan (rough proposed design re-attached below) > From: Dan Magenheimer > Sent: Monday, October 01, 2012 2:04 PM > : > : > Back to design brainstorming: > > The way I am thinking about it, the tools need to be involved > to the extent that they would need to communicate to the > hypervisor the following facts (probably via new hypercall): > > X1) I am launching a domain X and it is eventually going to > consume up to a maximum of N MB. Please tell me if > there is sufficient RAM available AND, if so, reserve > it until I tell you I am done. ("AND" implies transactional > semantics) > X2) The launch of X is complete and I will not be requesting > the allocation of any more RAM for it. Please release > the reservation, whether or not I've requested a total > of N MB. > > The calls may be nested or partially ordered, i.e. > X1...Y1...Y2...X2 > X1...Y1...X2...Y2 > and the hypervisor must be able to deal with this. > > Then there would need to be two "versions" of "xm/xl free". > We can quibble about which should be the default, but > they would be: > > - "xl --reserved free" asks the hypervisor how much RAM > is available taking into account reservations > - "xm --raw free" asks the hypervisor for the instantaneous > amount of RAM unallocated, not counting reservations > > When the tools are not launching a domain (that is there > has been a matching X2 for all X1), the results of the > above "free" queries are always identical. > > So, IanJ, does this match up with the design you were thinking > about? > > Thanks, > Dan > > [1] I think the core culprits are (a) the hypervisor accounts for > memory allocation of pages strictly on a first-come-first-served > basis and (b) the tools don't have any form of need-this-much-memory > "transaction" model _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 21:58:03 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 21:58:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJATB-0001G1-VD; Tue, 02 Oct 2012 21:57:37 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJAT9-0001Fw-Kf for xen-devel@lists.xen.org; Tue, 02 Oct 2012 21:57:35 +0000 X-Env-Sender: dan.magenheimer@oracle.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1349215048!8598996!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc4ODkzOA==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32164 invoked from network); 2 Oct 2012 21:57:29 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 21:57:29 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q92LvFLx008463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Oct 2012 21:57:15 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q92LvEjR010740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Oct 2012 21:57:14 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q92LvDnt016892; Tue, 2 Oct 2012 16:57:13 -0500 MIME-Version: 1.0 Message-ID: Date: Tue, 2 Oct 2012 14:56:57 -0700 (PDT) From: Dan Magenheimer To: Tim Deegan References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> <20121002091017.GA95926@ocelot.phlegethon.org> <66cc0085-1216-40f7-8059-eaf615202c12@default> <20121002201624.GA98445@ocelot.phlegethon.org> In-Reply-To: <20121002201624.GA98445@ocelot.phlegethon.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7 (607090) [OL 12.0.6661.5003 (x86)] X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: Olaf Hering , Keir Fraser , Konrad Wilk , George Dunlap , Kurt Hackel , Ian Jackson , xen-devel@lists.xen.org, George Shuklin , Dario Faggioli , Andres Lagar-Cavilla Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > From: Tim Deegan [mailto:tim@xen.org] > Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) > > At 12:33 -0700 on 02 Oct (1349181195), Dan Magenheimer wrote: > > > From: Tim Deegan [mailto:tim@xen.org] > > > Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) > > > > > > At 13:03 -0700 on 01 Oct (1349096617), Dan Magenheimer wrote: > > > > Bearing in mind that I know almost nothing about xl or > > > > the tools layer, and that, as a result, I tend to look > > > > for hypervisor solutions, I'm thinking it's not possible to > > > > solve this without direct participation of the hypervisor anyway, > > > > at least while ensuring the solution will successfully > > > > work with any memory technology that involves ballooning > > > > with the possibility of overcommit (i.e. tmem, page sharing > > > > and host-swapping, manual ballooning, PoD)... EVEN if the > > > > toolset is single threaded (i.e. only one domain may > > > > be created at a time, such as xapi). [1] > > > > > > TTBOMK, Xapi actually _has_ solved this problem, even with ballooning > > > and PoD. I don't know if they have any plans to support sharing, > > > swapping or tmem, though. > > > > Is this because PoD never independently increases the size of a domain's > > allocation? > > AIUI xapi uses the domains' maximum allocations, centrally controlled, > to place an upper bound on the amount of guest memory that can be in > use. Within those limits there can be ballooning activity. But TBH I > don't know the details. Yes, that's the same as saying there is no memory-overcommit. The original problem occurs only if there are multiple threads of execution that can be simultaneously asking the hypervisor to allocate memory without the knowledge of a single centralized "controller". > > > Adding a 'reservation' of free pages that may only be allocated by a > > > given domain should be straightforward enough, but I'm not sure it helps > > > > It absolutely does help. With tmem (and I think with paging), the > > total allocation of a domain may be increased without knowledge by > > the toolset. > > But not past the domains' maximum allowance, right? That's not the case > with paging, anyway. Right. We can quibble about memory hot-add, depending on its design. > > > much. In the 'balloon-to-fit' model where all memory is already > > > allocated to some domain (or tmem), some part of the toolstack needs to > > > sort out freeing up the memory before allocating it to another VM. > > > > By balloon-to-fit, do you mean that all RAM is occupied? Tmem > > handles the "sort out freeing up the memory" entirely in the > > hypervisor, so the toolstack never knows. > > Does tmem replace ballooning/sharing/swapping entirely? I thought they > could coexist. Or, if you jut mean that tmem owns all otherwise-free > memory and will relinquish it on demand, then the same problems occur > while the toolstack is moving memory from owned-by-guests to > owned-by-tmem. Tmem replaces sharing/swapping entirely for guests that support it. Since kernel changes are required to support it, not all guests will ever support it. Now with full tmem support in the Linux kernel, it is possible that eventually all non-legacy Linux guests will support it. Tmem dynamically handles all the transfer of owned-by memory capacity in the hypervisor, essentially augmenting the page allocator, so the hypervisor is the "controller". Oh, and tmem doesn't replace ballooning at all... it works best with selfballooning (which is also now in the Linux kernel). Ballooning is still a useful mechanism for moving memory capacity between the guest and the hypervisor; tmem caches data and handles policy. > > > Surely that component needs to handle the exclusion too - otherwise a > > > series of small VM creations could stall a large one indefinitely. > > > > Not sure I understand this, but it seems feasible. > > If you ask for a large VM and a small VM to be started at about the same > time, the small VM will always win (since you'll free enough memory for > the small VM before you free enough for the big one). If you then ask > for another small VM it will win again, and so forth, indefinitely > postponing the large VM in the waiting-for-memory state, unless some > agent explicitly enforces that VMs be started in order. If you have > such an agent you probably don't need a hypervisor interlock as well. OK, I see, thanks. > I think it would be better to back up a bit. Maybe you could sketch out > how you think [lib]xl ought to be handling ballooning/swapping/sharing/tmem > when it's starting VMs. I don't have a strong objection to accounting > free memory to particular domains if it turns out to be useful, but as > always I prefer not to have things happen in the hypervisor if they > could happen in less privileged code. I sketched it out earlier in this thread, will attach again below. I agree with your last statement in general, but would modify it to "if they could happen efficiently and effectively in less privileged code". Obviously everything that Xen does can be done in less privileged code... in an emulator. Emulator's just don't do it fast enough. Tmem argues that doing "memory capacity transfers" at a page granularity can only be done efficiently in the hypervisor. This is true for page-sharing when it breaks a "share" also... it can't go ask the toolstack to approve allocation of a new page every time a write to a shared page occurs. Does that make sense? So the original problem must be solved if: 1) Domain creation is not serialized 2) Any domain's current memory allocation can be increased without approval of the toolstack. Problem (1) arose independently and my interest is that it gets solved in a way that (2) can also benefit. Dan (rough proposed design re-attached below) > From: Dan Magenheimer > Sent: Monday, October 01, 2012 2:04 PM > : > : > Back to design brainstorming: > > The way I am thinking about it, the tools need to be involved > to the extent that they would need to communicate to the > hypervisor the following facts (probably via new hypercall): > > X1) I am launching a domain X and it is eventually going to > consume up to a maximum of N MB. Please tell me if > there is sufficient RAM available AND, if so, reserve > it until I tell you I am done. ("AND" implies transactional > semantics) > X2) The launch of X is complete and I will not be requesting > the allocation of any more RAM for it. Please release > the reservation, whether or not I've requested a total > of N MB. > > The calls may be nested or partially ordered, i.e. > X1...Y1...Y2...X2 > X1...Y1...X2...Y2 > and the hypervisor must be able to deal with this. > > Then there would need to be two "versions" of "xm/xl free". > We can quibble about which should be the default, but > they would be: > > - "xl --reserved free" asks the hypervisor how much RAM > is available taking into account reservations > - "xm --raw free" asks the hypervisor for the instantaneous > amount of RAM unallocated, not counting reservations > > When the tools are not launching a domain (that is there > has been a matching X2 for all X1), the results of the > above "free" queries are always identical. > > So, IanJ, does this match up with the design you were thinking > about? > > Thanks, > Dan > > [1] I think the core culprits are (a) the hypervisor accounts for > memory allocation of pages strictly on a first-come-first-served > basis and (b) the tools don't have any form of need-this-much-memory > "transaction" model _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 22:05:06 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 22:05:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJAa3-0001SP-Rf; Tue, 02 Oct 2012 22:04:43 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJAa3-0001SJ-1h for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 22:04:43 +0000 Received: from [85.158.143.35:18531] by server-3.bemta-4.messagelabs.com id 99/61-10986-AF46B605; Tue, 02 Oct 2012 22:04:42 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-16.tower-21.messagelabs.com!1349215481!14569101!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9558 invoked from network); 2 Oct 2012 22:04:41 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 22:04:41 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="14903583" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 22:04:41 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 23:04:41 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TJAa0-0004iy-QZ; Tue, 02 Oct 2012 22:04:40 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1TJAa0-0003f2-G5; Tue, 02 Oct 2012 23:04:40 +0100 To: Message-ID: From: xen.org Date: Tue, 2 Oct 2012 23:04:40 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.2-testing test] 13912: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 13912 xen-4.2-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13912/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-i386-i386-xl-qemuu-winxpsp3 9 guest-localmigrate fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: xen ca3e8190a72c baseline version: xen 906b3a2fcd0a ------------------------------------------------------------ People who touched revisions under test: Andres Lagar-Cavilla Ian Campbell Ian Jackson ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-4.2-testing + revision=ca3e8190a72c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.2-testing ca3e8190a72c + branch=xen-4.2-testing + revision=ca3e8190a72c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + . cri-common ++ umask 002 + select_xenbranch + case "$branch" in + tree=xen + xenbranch=xen-4.2-testing + '[' xxen = xlinux ']' + linuxbranch=linux + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : http://xenbits.xen.org/hg/staging/xen-4.2-testing.hg ++ : git://xenbits.xen.org/staging/qemu-xen-4.2-testing.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.xen-4.2-testing ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-4.2-testing.git ++ : daily-cron.xen-4.2-testing + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.2-testing.git + info_linux_tree xen-4.2-testing + case $1 in + return 1 + case "$branch" in + cd /export/home/osstest/repos/xen-4.2-testing.hg + hg push -r ca3e8190a72c ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 1 changesets with 2 changes to 2 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 22:05:06 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 22:05:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJAa3-0001SP-Rf; Tue, 02 Oct 2012 22:04:43 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJAa3-0001SJ-1h for xen-devel@lists.xensource.com; Tue, 02 Oct 2012 22:04:43 +0000 Received: from [85.158.143.35:18531] by server-3.bemta-4.messagelabs.com id 99/61-10986-AF46B605; Tue, 02 Oct 2012 22:04:42 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-16.tower-21.messagelabs.com!1349215481!14569101!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI3Nzk=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9558 invoked from network); 2 Oct 2012 22:04:41 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2012 22:04:41 -0000 X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="14903583" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Oct 2012 22:04:41 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 23:04:41 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TJAa0-0004iy-QZ; Tue, 02 Oct 2012 22:04:40 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1TJAa0-0003f2-G5; Tue, 02 Oct 2012 23:04:40 +0100 To: Message-ID: From: xen.org Date: Tue, 2 Oct 2012 23:04:40 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.2-testing test] 13912: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 13912 xen-4.2-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13912/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-i386-i386-xl-qemuu-winxpsp3 9 guest-localmigrate fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: xen ca3e8190a72c baseline version: xen 906b3a2fcd0a ------------------------------------------------------------ People who touched revisions under test: Andres Lagar-Cavilla Ian Campbell Ian Jackson ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-4.2-testing + revision=ca3e8190a72c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.2-testing ca3e8190a72c + branch=xen-4.2-testing + revision=ca3e8190a72c + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + . cri-common ++ umask 002 + select_xenbranch + case "$branch" in + tree=xen + xenbranch=xen-4.2-testing + '[' xxen = xlinux ']' + linuxbranch=linux + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : http://xenbits.xen.org/hg/staging/xen-4.2-testing.hg ++ : git://xenbits.xen.org/staging/qemu-xen-4.2-testing.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.xen-4.2-testing ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-4.2-testing.git ++ : daily-cron.xen-4.2-testing + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.2-testing.git + info_linux_tree xen-4.2-testing + case $1 in + return 1 + case "$branch" in + cd /export/home/osstest/repos/xen-4.2-testing.hg + hg push -r ca3e8190a72c ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 1 changesets with 2 changes to 2 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 22:23:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 22:23:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJArV-0001ge-Tb; Tue, 02 Oct 2012 22:22:45 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJArU-0001gZ-43 for Xen-devel@lists.xensource.com; Tue, 02 Oct 2012 22:22:44 +0000 Received: from [85.158.143.35:56095] by server-2.bemta-4.messagelabs.com id F9/71-06610-3396B605; Tue, 02 Oct 2012 22:22:43 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1349216560!4808461!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzc4ODk3\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24338 invoked from network); 2 Oct 2012 22:22:41 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 22:22:41 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q92MMYHc002509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Oct 2012 22:22:35 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q92MMX07010978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Oct 2012 22:22:34 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q92MMXc6007008; Tue, 2 Oct 2012 17:22:33 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 02 Oct 2012 15:22:33 -0700 Date: Tue, 2 Oct 2012 15:22:31 -0700 From: Mukesh Rathor To: Stefano Stabellini Message-ID: <20121002152231.0c5d7b26@mantra.us.oracle.com> In-Reply-To: References: <20120921121556.1a0ea8af@mantra.us.oracle.com> <20121001143244.36b4c270@mantra.us.oracle.com> <20121001144455.3ba7e10b@mantra.us.oracle.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "Xen-devel@lists.xensource.com" , Ian Campbell , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2 Oct 2012 12:23:58 +0100 Stefano Stabellini wrote: > On Mon, 1 Oct 2012, Mukesh Rathor wrote: > > On Mon, 1 Oct 2012 14:32:44 -0700 > > Mukesh Rathor wrote: > > > > > > > > So, the mapcount must be not be getting set in "normal" case > > > properly it appears. Marking it special causes it so skip few > > > things. Debugging... > > > > Shall I just leave it special for now, and come back and revisit > > this later? > > special is going to create troubles if somebody starts using these > pages in unexpected ways (for example dma from hardware ot gupf). > > Also I fail to see how this case is any different from mapping pages > using gntdev (see gntdev_mmap) that works fine without special. > > Maybe we are not setting some vm_flags that we are supposed to set > (VM_RESERVED | VM_IO | VM_DONTCOPY)? > I see that we are setting them in privcmd_mmap but not in > privcmd_ioctl_mmap_batch... No, that is getting set. privcmd_mmap is hook for mmap(), so it gets called for both. If its not marked special, vm_normal_page() will not check for the VM_PFNMAP flag, which is what we want. It works for PV dom0 because remap_area_mfn_pte_fn() has also marked it special: static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr, void *data) { struct remap_data *rmd = data; pte_t pte = pte_mkspecial(pfn_pte(rmd->mfn++, rmd->prot)); thanks, Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Tue Oct 02 22:23:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Oct 2012 22:23:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJArV-0001ge-Tb; Tue, 02 Oct 2012 22:22:45 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJArU-0001gZ-43 for Xen-devel@lists.xensource.com; Tue, 02 Oct 2012 22:22:44 +0000 Received: from [85.158.143.35:56095] by server-2.bemta-4.messagelabs.com id F9/71-06610-3396B605; Tue, 02 Oct 2012 22:22:43 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1349216560!4808461!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzc4ODk3\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24338 invoked from network); 2 Oct 2012 22:22:41 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Oct 2012 22:22:41 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q92MMYHc002509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Oct 2012 22:22:35 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q92MMX07010978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Oct 2012 22:22:34 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q92MMXc6007008; Tue, 2 Oct 2012 17:22:33 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 02 Oct 2012 15:22:33 -0700 Date: Tue, 2 Oct 2012 15:22:31 -0700 From: Mukesh Rathor To: Stefano Stabellini Message-ID: <20121002152231.0c5d7b26@mantra.us.oracle.com> In-Reply-To: References: <20120921121556.1a0ea8af@mantra.us.oracle.com> <20121001143244.36b4c270@mantra.us.oracle.com> <20121001144455.3ba7e10b@mantra.us.oracle.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "Xen-devel@lists.xensource.com" , Ian Campbell , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2 Oct 2012 12:23:58 +0100 Stefano Stabellini wrote: > On Mon, 1 Oct 2012, Mukesh Rathor wrote: > > On Mon, 1 Oct 2012 14:32:44 -0700 > > Mukesh Rathor wrote: > > > > > > > > So, the mapcount must be not be getting set in "normal" case > > > properly it appears. Marking it special causes it so skip few > > > things. Debugging... > > > > Shall I just leave it special for now, and come back and revisit > > this later? > > special is going to create troubles if somebody starts using these > pages in unexpected ways (for example dma from hardware ot gupf). > > Also I fail to see how this case is any different from mapping pages > using gntdev (see gntdev_mmap) that works fine without special. > > Maybe we are not setting some vm_flags that we are supposed to set > (VM_RESERVED | VM_IO | VM_DONTCOPY)? > I see that we are setting them in privcmd_mmap but not in > privcmd_ioctl_mmap_batch... No, that is getting set. privcmd_mmap is hook for mmap(), so it gets called for both. If its not marked special, vm_normal_page() will not check for the VM_PFNMAP flag, which is what we want. It works for PV dom0 because remap_area_mfn_pte_fn() has also marked it special: static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr, void *data) { struct remap_data *rmd = data; pte_t pte = pte_mkspecial(pfn_pte(rmd->mfn++, rmd->prot)); thanks, Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 01:37:09 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 01:37:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJDt6-0006wX-Ge; Wed, 03 Oct 2012 01:36:36 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJDt4-0006wS-Pv for Xen-devel@lists.xensource.com; Wed, 03 Oct 2012 01:36:34 +0000 Received: from [85.158.143.35:29755] by server-2.bemta-4.messagelabs.com id 61/23-06610-2A69B605; Wed, 03 Oct 2012 01:36:34 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1349228191!6324914!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc4ODkzOA==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28636 invoked from network); 3 Oct 2012 01:36:33 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Oct 2012 01:36:33 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q931aN9Y018701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Oct 2012 01:36:24 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q931aMgc000869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Oct 2012 01:36:22 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q931aLph032741; Tue, 2 Oct 2012 20:36:21 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 02 Oct 2012 18:36:21 -0700 Date: Tue, 2 Oct 2012 18:36:19 -0700 From: Mukesh Rathor To: Stefano Stabellini Message-ID: <20121002183619.70734b7a@mantra.us.oracle.com> In-Reply-To: References: <20120921121659.5a723de9@mantra.us.oracle.com> <20120924154335.097d3fb9@mantra.us.oracle.com> <20120925180416.0137d61a@mantra.us.oracle.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "Xen-devel@lists.xensource.com" , Ian Campbell , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 3/8]: PVH startup changes (enlighten.c) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 26 Sep 2012 12:33:39 +0100 Stefano Stabellini wrote: > > Wish it was simple. But for PV and PVH, domU, it's already setup > > the shared page. All we need to do is __va(shared_info). But for > > HVM domUs and PVH dom0, we need to hcall with pfn to get it > > remapped. > > For PVH domU is already setup as a pfn only because in > tools/libxc/xc_dom_x86.c:alloc_magic_pages we have this code: > > if ( xc_dom_feature_translated(dom) ) > dom->shared_info_pfn = xc_dom_alloc_page(dom, "shared info"); > > and in tools/libxc/xc_dom_x86.c:start_info_x86_64 we have: > > xen_pfn_t shinfo = > xc_dom_feature_translated(dom) ? dom->shared_info_pfn : dom-> > shared_info_mfn; > > if we simply get rid of the two "if xc_dom_feature_translated(dom)" > wouldn't we get an mfn for PVH domU too? AFAICT all the other cases > would remain unmodified, but PVH domU would start getting an mfn for > shared_info. > > > Changing the > > tool to map pfn, would result in unnecessary hcall for all PV and > > PVH domUs. It's only two lines of code, so lets just leave it. I'll > > make the comment better. > > Yes, there would be one more unnecessary hypercall but we would get > rid of 4 "if". I think is a good trade off. Well, not really unfortunately! There are two fields in the library shared_info_mfn and shared_info_pfn in struct xc_dom_image. For xlated, pfn is set, otherwise, mfn is set. If I set mfn for auto xlated also, I end up changing/adding more code in the library where it tries to map the shared page. Moreover, it's better to stick with the library assumption that for auto xlated, pfn is set, otherwise, mfn is set. Hope that makes sense. I tried it, btw. thanks, Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 01:37:09 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 01:37:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJDt6-0006wX-Ge; Wed, 03 Oct 2012 01:36:36 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJDt4-0006wS-Pv for Xen-devel@lists.xensource.com; Wed, 03 Oct 2012 01:36:34 +0000 Received: from [85.158.143.35:29755] by server-2.bemta-4.messagelabs.com id 61/23-06610-2A69B605; Wed, 03 Oct 2012 01:36:34 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1349228191!6324914!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc4ODkzOA==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28636 invoked from network); 3 Oct 2012 01:36:33 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Oct 2012 01:36:33 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q931aN9Y018701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Oct 2012 01:36:24 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q931aMgc000869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Oct 2012 01:36:22 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q931aLph032741; Tue, 2 Oct 2012 20:36:21 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 02 Oct 2012 18:36:21 -0700 Date: Tue, 2 Oct 2012 18:36:19 -0700 From: Mukesh Rathor To: Stefano Stabellini Message-ID: <20121002183619.70734b7a@mantra.us.oracle.com> In-Reply-To: References: <20120921121659.5a723de9@mantra.us.oracle.com> <20120924154335.097d3fb9@mantra.us.oracle.com> <20120925180416.0137d61a@mantra.us.oracle.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "Xen-devel@lists.xensource.com" , Ian Campbell , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 3/8]: PVH startup changes (enlighten.c) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 26 Sep 2012 12:33:39 +0100 Stefano Stabellini wrote: > > Wish it was simple. But for PV and PVH, domU, it's already setup > > the shared page. All we need to do is __va(shared_info). But for > > HVM domUs and PVH dom0, we need to hcall with pfn to get it > > remapped. > > For PVH domU is already setup as a pfn only because in > tools/libxc/xc_dom_x86.c:alloc_magic_pages we have this code: > > if ( xc_dom_feature_translated(dom) ) > dom->shared_info_pfn = xc_dom_alloc_page(dom, "shared info"); > > and in tools/libxc/xc_dom_x86.c:start_info_x86_64 we have: > > xen_pfn_t shinfo = > xc_dom_feature_translated(dom) ? dom->shared_info_pfn : dom-> > shared_info_mfn; > > if we simply get rid of the two "if xc_dom_feature_translated(dom)" > wouldn't we get an mfn for PVH domU too? AFAICT all the other cases > would remain unmodified, but PVH domU would start getting an mfn for > shared_info. > > > Changing the > > tool to map pfn, would result in unnecessary hcall for all PV and > > PVH domUs. It's only two lines of code, so lets just leave it. I'll > > make the comment better. > > Yes, there would be one more unnecessary hypercall but we would get > rid of 4 "if". I think is a good trade off. Well, not really unfortunately! There are two fields in the library shared_info_mfn and shared_info_pfn in struct xc_dom_image. For xlated, pfn is set, otherwise, mfn is set. If I set mfn for auto xlated also, I end up changing/adding more code in the library where it tries to map the shared page. Moreover, it's better to stick with the library assumption that for auto xlated, pfn is set, otherwise, mfn is set. Hope that makes sense. I tried it, btw. thanks, Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 02:04:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 02:04:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJEJE-0007VK-RI; Wed, 03 Oct 2012 02:03:36 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJEJC-0007VF-Pi for Xen-devel@lists.xensource.com; Wed, 03 Oct 2012 02:03:34 +0000 Received: from [85.158.143.99:13157] by server-3.bemta-4.messagelabs.com id EA/C3-10986-5FC9B605; Wed, 03 Oct 2012 02:03:33 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1349229812!26192144!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc4ODkzOA==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6008 invoked from network); 3 Oct 2012 02:03:33 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Oct 2012 02:03:33 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q9323QLG001206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Oct 2012 02:03:27 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q9323PS0000835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Oct 2012 02:03:26 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q9323OF2012815; Tue, 2 Oct 2012 21:03:24 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 02 Oct 2012 19:03:24 -0700 Date: Tue, 2 Oct 2012 19:03:23 -0700 From: Mukesh Rathor To: Mukesh Rathor Message-ID: <20121002190323.2e16f6ff@mantra.us.oracle.com> In-Reply-To: <20121002183619.70734b7a@mantra.us.oracle.com> References: <20120921121659.5a723de9@mantra.us.oracle.com> <20120924154335.097d3fb9@mantra.us.oracle.com> <20120925180416.0137d61a@mantra.us.oracle.com> <20121002183619.70734b7a@mantra.us.oracle.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "Xen-devel@lists.xensource.com" , Ian Campbell , Konrad Rzeszutek Wilk , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v1 3/8]: PVH startup changes (enlighten.c) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2 Oct 2012 18:36:19 -0700 Mukesh Rathor wrote: > On Wed, 26 Sep 2012 12:33:39 +0100 > Stefano Stabellini wrote: > > > > Wish it was simple. But for PV and PVH, domU, it's already setup > > > the shared page. All we need to do is __va(shared_info). But for > > > HVM domUs and PVH dom0, we need to hcall with pfn to get it > > > remapped. > > > > For PVH domU is already setup as a pfn only because in > > tools/libxc/xc_dom_x86.c:alloc_magic_pages we have this code: > > > > if ( xc_dom_feature_translated(dom) ) > > dom->shared_info_pfn = xc_dom_alloc_page(dom, "shared > > info"); > > > > and in tools/libxc/xc_dom_x86.c:start_info_x86_64 we have: > > > > xen_pfn_t shinfo = > > xc_dom_feature_translated(dom) ? dom->shared_info_pfn : > > dom-> shared_info_mfn; > > > > if we simply get rid of the two "if xc_dom_feature_translated(dom)" > > wouldn't we get an mfn for PVH domU too? AFAICT all the other cases > > would remain unmodified, but PVH domU would start getting an mfn for > > shared_info. > > > > > Changing the > > > tool to map pfn, would result in unnecessary hcall for all PV and > > > PVH domUs. It's only two lines of code, so lets just leave it. > > > I'll make the comment better. > > > > Yes, there would be one more unnecessary hypercall but we would get > > rid of 4 "if". I think is a good trade off. > > Well, not really unfortunately! There are two fields in the library > shared_info_mfn and shared_info_pfn in struct xc_dom_image. For > xlated, pfn is set, otherwise, mfn is set. If I set mfn for auto > xlated also, I end up changing/adding more code in the library where > it tries to map the shared page. Moreover, it's better to stick with > the library assumption that for auto xlated, pfn is set, otherwise, > mfn is set. > > Hope that makes sense. I tried it, btw. > I'm not able to make a quick change to xen to just put pfn for dom0 also. get_gpfn_from_mfn() is crashing. So for now, how about, lets go with what I've got. I'll make a note, and when I do xen patch, I'll figure it out, and would be a very small linux patch. I want to get linux patch in soon before the window closes. thanks Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 02:04:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 02:04:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJEJE-0007VK-RI; Wed, 03 Oct 2012 02:03:36 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJEJC-0007VF-Pi for Xen-devel@lists.xensource.com; Wed, 03 Oct 2012 02:03:34 +0000 Received: from [85.158.143.99:13157] by server-3.bemta-4.messagelabs.com id EA/C3-10986-5FC9B605; Wed, 03 Oct 2012 02:03:33 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1349229812!26192144!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc4ODkzOA==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6008 invoked from network); 3 Oct 2012 02:03:33 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Oct 2012 02:03:33 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q9323QLG001206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Oct 2012 02:03:27 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q9323PS0000835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Oct 2012 02:03:26 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q9323OF2012815; Tue, 2 Oct 2012 21:03:24 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 02 Oct 2012 19:03:24 -0700 Date: Tue, 2 Oct 2012 19:03:23 -0700 From: Mukesh Rathor To: Mukesh Rathor Message-ID: <20121002190323.2e16f6ff@mantra.us.oracle.com> In-Reply-To: <20121002183619.70734b7a@mantra.us.oracle.com> References: <20120921121659.5a723de9@mantra.us.oracle.com> <20120924154335.097d3fb9@mantra.us.oracle.com> <20120925180416.0137d61a@mantra.us.oracle.com> <20121002183619.70734b7a@mantra.us.oracle.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "Xen-devel@lists.xensource.com" , Ian Campbell , Konrad Rzeszutek Wilk , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v1 3/8]: PVH startup changes (enlighten.c) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2 Oct 2012 18:36:19 -0700 Mukesh Rathor wrote: > On Wed, 26 Sep 2012 12:33:39 +0100 > Stefano Stabellini wrote: > > > > Wish it was simple. But for PV and PVH, domU, it's already setup > > > the shared page. All we need to do is __va(shared_info). But for > > > HVM domUs and PVH dom0, we need to hcall with pfn to get it > > > remapped. > > > > For PVH domU is already setup as a pfn only because in > > tools/libxc/xc_dom_x86.c:alloc_magic_pages we have this code: > > > > if ( xc_dom_feature_translated(dom) ) > > dom->shared_info_pfn = xc_dom_alloc_page(dom, "shared > > info"); > > > > and in tools/libxc/xc_dom_x86.c:start_info_x86_64 we have: > > > > xen_pfn_t shinfo = > > xc_dom_feature_translated(dom) ? dom->shared_info_pfn : > > dom-> shared_info_mfn; > > > > if we simply get rid of the two "if xc_dom_feature_translated(dom)" > > wouldn't we get an mfn for PVH domU too? AFAICT all the other cases > > would remain unmodified, but PVH domU would start getting an mfn for > > shared_info. > > > > > Changing the > > > tool to map pfn, would result in unnecessary hcall for all PV and > > > PVH domUs. It's only two lines of code, so lets just leave it. > > > I'll make the comment better. > > > > Yes, there would be one more unnecessary hypercall but we would get > > rid of 4 "if". I think is a good trade off. > > Well, not really unfortunately! There are two fields in the library > shared_info_mfn and shared_info_pfn in struct xc_dom_image. For > xlated, pfn is set, otherwise, mfn is set. If I set mfn for auto > xlated also, I end up changing/adding more code in the library where > it tries to map the shared page. Moreover, it's better to stick with > the library assumption that for auto xlated, pfn is set, otherwise, > mfn is set. > > Hope that makes sense. I tried it, btw. > I'm not able to make a quick change to xen to just put pfn for dom0 also. get_gpfn_from_mfn() is crashing. So for now, how about, lets go with what I've got. I'll make a note, and when I do xen patch, I'll figure it out, and would be a very small linux patch. I want to get linux patch in soon before the window closes. thanks Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 04:09:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 04:09:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJGGv-0008S4-EM; Wed, 03 Oct 2012 04:09:21 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJGGt-0008Rz-Gb for xen-devel@lists.xen.org; Wed, 03 Oct 2012 04:09:19 +0000 Received: from [85.158.143.99:59968] by server-2.bemta-4.messagelabs.com id 67/04-06610-E6ABB605; Wed, 03 Oct 2012 04:09:18 +0000 X-Env-Sender: nruslan_devel@yahoo.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1349237357!27353665!1 X-Originating-IP: [98.138.91.153] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_12, ML_RADAR_SPEW_LINKS_14,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2278 invoked from network); 3 Oct 2012 04:09:18 -0000 Received: from nm23-vm3.bullet.mail.ne1.yahoo.com (HELO nm23-vm3.bullet.mail.ne1.yahoo.com) (98.138.91.153) by server-4.tower-216.messagelabs.com with SMTP; 3 Oct 2012 04:09:18 -0000 Received: from [98.138.226.179] by nm23.bullet.mail.ne1.yahoo.com with NNFMP; 03 Oct 2012 04:09:17 -0000 Received: from [98.138.226.166] by tm14.bullet.mail.ne1.yahoo.com with NNFMP; 03 Oct 2012 04:09:17 -0000 Received: from [127.0.0.1] by omp1067.mail.ne1.yahoo.com with NNFMP; 03 Oct 2012 04:09:17 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 356952.31562.bm@omp1067.mail.ne1.yahoo.com Received: (qmail 11727 invoked by uid 60001); 3 Oct 2012 04:09:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1349237357; bh=o8TU3gDKgFQfnWdHz0u8OeifHKpB9vv8UzecklvKTTo=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=C8Qc/D/gYS6zW0qMg86aRtRN0wKB96jnZ5jkgSjfH62GzmVk0recNM7igTNCa59Ko75mSRlYfka+O52PD5zsxPBtLl0+SSRstUnKs+hG2RQiuQVZeUYGUALwVW9yJ41TmLnsaPXWalwiTtJZ1W4Uwc/ftsc0c+dOp/GGAADjIWs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=SYto1uBlHkI9QcROvzKn6/WEUNKEVor+BY1cYlU+9nUQmB5eXCMcllalHv6HBOeHIB70pbKl1venD3bdvRotDFvXw65HWehxe8EJhPsV4hqHXMs/9ClWAF/OidlNRuvCxppIKb4Pdb57bv5ibRPBaBvH/txHZU/RYJMSi1FI178=; X-YMail-OSG: NNQrMpUVM1m3rfytZaP9KEEizrCgbtHCGLg3UXykmfc93aI YAxVzAKQ3u092Atx6VMeA1hOr7vM2NWh._NoWEcPgi3l2Mf9.ltTg8dM.vA1 w4BilsAWtBTB4DN5HhSrlzMyXzw2l9CRQyVmsKpiBUYZ_SH3b0TSeLOapvJB 7Xs3G8xA4XKgr8BY6J2J3LR6X42AcF3vvUZjkfQ8Nzm0UzZb_sWfe1QpXEWR Frjw9p22q2HnI6pCKrzhQt_3yg4jLiF3QJhsISFzlZLeDhkYcqUPxyu8xTSN TpFP08XGO90ZIcpcds4FHKr5AW7RVyf4t4mUjZZEryb7Ghg9RwOOOrqcoML6 pGhgWMAGGMUSg92vc0muS_Vwp82BG3Cd1AHoI5Z_2HjLqUuqM6JNi4wD9Jgq v_bpil0TN4l1Gd6GU9J0Ug2S75xpZgKE3UBITlUJGAyoC1yQ86AdjZXYGPpU 6oGIqRrVYuBT1ZXGdi9L6wCGt3VYGUn.rWoGDg7sB1XNJZxECj2RK Received: from [71.62.157.55] by web124501.mail.ne1.yahoo.com via HTTP; Tue, 02 Oct 2012 21:09:17 PDT X-Mailer: YahooMailWebService/0.8.122.442 Message-ID: <1349237357.71534.YahooMailNeo@web124501.mail.ne1.yahoo.com> Date: Tue, 2 Oct 2012 21:09:17 -0700 (PDT) From: Ruslan Nikolaev To: "xen-devel@lists.xen.org" MIME-Version: 1.0 Subject: [Xen-devel] Emulation of cmpxchg in Xen 4.2 (also possible bug) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Ruslan Nikolaev List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hi While experimenting with a heavy testload which makes a lot of CMPXCHG in PVHVM domain (DomU) and Dom0, I noticed inconsistency (I am using official Xen 4.2 release): Dom0's cmpxchg succeeds (i.e. set ZF flag appropriately) changing Val1 to Val2 PVHVM DomU cmpxchg also succeeds changing Val1 to Val3 even though it was supposedly replaced (Val1 to Val2, Val1 != Val2) by Dom0 already I double checked my code and it seems to be fine. Moreover, the problem appears only on a high contention case (when both Dom0 and DomU are trying to change it). While investigating the issue, I noticed that Xen emulates cmpxchg for PV and HVM cases: 1. Why is it needed to emulate CMPXCHG at all? (What is it used for and can it be disabled? I am using Linux guests.) 2. Is it emulated only in HVM DomU domain or in Dom0 as well?3. Is it possible that emulation has some bug? Is it possible to somehow avoid emulation at all and replace it with something? (I want to avoid performance overhead for this instruction) What if I use CMPXCHG16B, does it still use emulation? Ruslan. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 04:09:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 04:09:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJGGv-0008S4-EM; Wed, 03 Oct 2012 04:09:21 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJGGt-0008Rz-Gb for xen-devel@lists.xen.org; Wed, 03 Oct 2012 04:09:19 +0000 Received: from [85.158.143.99:59968] by server-2.bemta-4.messagelabs.com id 67/04-06610-E6ABB605; Wed, 03 Oct 2012 04:09:18 +0000 X-Env-Sender: nruslan_devel@yahoo.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1349237357!27353665!1 X-Originating-IP: [98.138.91.153] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_12, ML_RADAR_SPEW_LINKS_14,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2278 invoked from network); 3 Oct 2012 04:09:18 -0000 Received: from nm23-vm3.bullet.mail.ne1.yahoo.com (HELO nm23-vm3.bullet.mail.ne1.yahoo.com) (98.138.91.153) by server-4.tower-216.messagelabs.com with SMTP; 3 Oct 2012 04:09:18 -0000 Received: from [98.138.226.179] by nm23.bullet.mail.ne1.yahoo.com with NNFMP; 03 Oct 2012 04:09:17 -0000 Received: from [98.138.226.166] by tm14.bullet.mail.ne1.yahoo.com with NNFMP; 03 Oct 2012 04:09:17 -0000 Received: from [127.0.0.1] by omp1067.mail.ne1.yahoo.com with NNFMP; 03 Oct 2012 04:09:17 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 356952.31562.bm@omp1067.mail.ne1.yahoo.com Received: (qmail 11727 invoked by uid 60001); 3 Oct 2012 04:09:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1349237357; bh=o8TU3gDKgFQfnWdHz0u8OeifHKpB9vv8UzecklvKTTo=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=C8Qc/D/gYS6zW0qMg86aRtRN0wKB96jnZ5jkgSjfH62GzmVk0recNM7igTNCa59Ko75mSRlYfka+O52PD5zsxPBtLl0+SSRstUnKs+hG2RQiuQVZeUYGUALwVW9yJ41TmLnsaPXWalwiTtJZ1W4Uwc/ftsc0c+dOp/GGAADjIWs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=SYto1uBlHkI9QcROvzKn6/WEUNKEVor+BY1cYlU+9nUQmB5eXCMcllalHv6HBOeHIB70pbKl1venD3bdvRotDFvXw65HWehxe8EJhPsV4hqHXMs/9ClWAF/OidlNRuvCxppIKb4Pdb57bv5ibRPBaBvH/txHZU/RYJMSi1FI178=; X-YMail-OSG: NNQrMpUVM1m3rfytZaP9KEEizrCgbtHCGLg3UXykmfc93aI YAxVzAKQ3u092Atx6VMeA1hOr7vM2NWh._NoWEcPgi3l2Mf9.ltTg8dM.vA1 w4BilsAWtBTB4DN5HhSrlzMyXzw2l9CRQyVmsKpiBUYZ_SH3b0TSeLOapvJB 7Xs3G8xA4XKgr8BY6J2J3LR6X42AcF3vvUZjkfQ8Nzm0UzZb_sWfe1QpXEWR Frjw9p22q2HnI6pCKrzhQt_3yg4jLiF3QJhsISFzlZLeDhkYcqUPxyu8xTSN TpFP08XGO90ZIcpcds4FHKr5AW7RVyf4t4mUjZZEryb7Ghg9RwOOOrqcoML6 pGhgWMAGGMUSg92vc0muS_Vwp82BG3Cd1AHoI5Z_2HjLqUuqM6JNi4wD9Jgq v_bpil0TN4l1Gd6GU9J0Ug2S75xpZgKE3UBITlUJGAyoC1yQ86AdjZXYGPpU 6oGIqRrVYuBT1ZXGdi9L6wCGt3VYGUn.rWoGDg7sB1XNJZxECj2RK Received: from [71.62.157.55] by web124501.mail.ne1.yahoo.com via HTTP; Tue, 02 Oct 2012 21:09:17 PDT X-Mailer: YahooMailWebService/0.8.122.442 Message-ID: <1349237357.71534.YahooMailNeo@web124501.mail.ne1.yahoo.com> Date: Tue, 2 Oct 2012 21:09:17 -0700 (PDT) From: Ruslan Nikolaev To: "xen-devel@lists.xen.org" MIME-Version: 1.0 Subject: [Xen-devel] Emulation of cmpxchg in Xen 4.2 (also possible bug) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Ruslan Nikolaev List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hi While experimenting with a heavy testload which makes a lot of CMPXCHG in PVHVM domain (DomU) and Dom0, I noticed inconsistency (I am using official Xen 4.2 release): Dom0's cmpxchg succeeds (i.e. set ZF flag appropriately) changing Val1 to Val2 PVHVM DomU cmpxchg also succeeds changing Val1 to Val3 even though it was supposedly replaced (Val1 to Val2, Val1 != Val2) by Dom0 already I double checked my code and it seems to be fine. Moreover, the problem appears only on a high contention case (when both Dom0 and DomU are trying to change it). While investigating the issue, I noticed that Xen emulates cmpxchg for PV and HVM cases: 1. Why is it needed to emulate CMPXCHG at all? (What is it used for and can it be disabled? I am using Linux guests.) 2. Is it emulated only in HVM DomU domain or in Dom0 as well?3. Is it possible that emulation has some bug? Is it possible to somehow avoid emulation at all and replace it with something? (I want to avoid performance overhead for this instruction) What if I use CMPXCHG16B, does it still use emulation? Ruslan. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 04:14:36 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 04:14:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJGLb-00008M-5P; Wed, 03 Oct 2012 04:14:11 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJGLZ-00008D-PH for xen-devel@lists.xen.org; Wed, 03 Oct 2012 04:14:09 +0000 Received: from [85.158.139.83:38497] by server-10.bemta-5.messagelabs.com id 54/11-16911-19BBB605; Wed, 03 Oct 2012 04:14:09 +0000 X-Env-Sender: nruslan_devel@yahoo.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1349237647!29266711!1 X-Originating-IP: [98.138.90.80] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_12, ML_RADAR_SPEW_LINKS_14,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 568 invoked from network); 3 Oct 2012 04:14:08 -0000 Received: from nm17.bullet.mail.ne1.yahoo.com (HELO nm17.bullet.mail.ne1.yahoo.com) (98.138.90.80) by server-6.tower-182.messagelabs.com with SMTP; 3 Oct 2012 04:14:08 -0000 Received: from [98.138.90.50] by nm17.bullet.mail.ne1.yahoo.com with NNFMP; 03 Oct 2012 04:14:07 -0000 Received: from [98.138.89.162] by tm3.bullet.mail.ne1.yahoo.com with NNFMP; 03 Oct 2012 04:14:07 -0000 Received: from [127.0.0.1] by omp1018.mail.ne1.yahoo.com with NNFMP; 03 Oct 2012 04:14:07 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 264841.6765.bm@omp1018.mail.ne1.yahoo.com Received: (qmail 7009 invoked by uid 60001); 3 Oct 2012 04:14:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1349237647; bh=VCDHDT2ekvo9+JfNFimhxclpN6XB4X5uo6+aquMEkmY=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=fsHTVJ2w1WSxebyy9XFQljdeVDNCk9r9QPs6kgPXlcuLVNXkjFsz3FFyIr73BJKOasXQ/1xvdzmKclo5c4+KfA7hDHaferSRLodL5tYIh60TyNSHsP4ebNvN5TfVwshgj1zqcQ54CmkoZbN7Y5M9BROxgWEeoKjW/MzL4y04Huo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=tjGHD4MN0slqxn56UJOqhQeY/uysRzUhI6yRtcgJ1jIelq9J6BLGQz6MIN7uHyP6A+lyIterLLVarUh/PQVOlCaRLXfTyQtNdTHLbj3SHP8SYSuB/uQMp6tbdkezQtGi3Fav2hxlC0KrdmIdxUMpKZEb2UL+serBtGJfP/rFx28=; X-YMail-OSG: CJcqiSQVM1kwx3Ns8RTrvDVIg97Ls4qV94PMvYK2ncyFZY8 4bmm.gxUPlt0D7lufuTSri0K7cbLmPJu6bc2oUf3RHVaJFDMeTfY2GCJxCS9 NOxIDD8o6p9lbxp.FRucErv49_nvbnzZAQx0tGPL415WnrgpLI0z0gFPZwzr mwpqhqOFGmvYruZUKJP5LG7tzRQFe_kdJUfuBpLgEEKExzLrK4gcapFaBSU8 6qcfpgAZHzAcvjb_SCC9RBvL8nKz0bhAWRbFsyfrQJwBa08Mn3MeWgP0FCRq ioYsXJr_f0AicZ0q4EaZM3CIna86oee.KL7OFwWYmIc_89zwO.AQqm7hk_Bm jICc8qEvrw87xightR1loVqqK6T2R2c34O.yfnUa2JCuqEYTj1Ocx6QWMFWk EeEZarJC8_CKdCgbw1fxAKDgllJXrSJ4AlmkSO_57MLS9Cav7Z9bRZv_UA7l rVWgrYC8wqJfov85tCiwB7krvkyzUZaXT_67xsl4A9r2OFPrkc39AH7NFUHC iM65sL.dURoI.8pE- Received: from [71.62.157.55] by web124505.mail.ne1.yahoo.com via HTTP; Tue, 02 Oct 2012 21:14:07 PDT X-Mailer: YahooMailWebService/0.8.122.442 References: <1349237357.71534.YahooMailNeo@web124501.mail.ne1.yahoo.com> Message-ID: <1349237647.75192.YahooMailNeo@web124505.mail.ne1.yahoo.com> Date: Tue, 2 Oct 2012 21:14:07 -0700 (PDT) From: Ruslan Nikolaev To: "xen-devel@lists.xen.org" In-Reply-To: <1349237357.71534.YahooMailNeo@web124501.mail.ne1.yahoo.com> MIME-Version: 1.0 Subject: Re: [Xen-devel] Emulation of cmpxchg in Xen 4.2 (also possible bug) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Ruslan Nikolaev List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Just one clarification to my message below: I am using a shared page between DomU HVM and Dom0. (This is used as a shared buffer and cmpxchg changes atomic variable there.) Ruslan ----- Original Message ----- From: Ruslan Nikolaev To: "xen-devel@lists.xen.org" Cc: Sent: Wednesday, October 3, 2012 12:09 AM Subject: Emulation of cmpxchg in Xen 4.2 (also possible bug) Hi While experimenting with a heavy testload which makes a lot of CMPXCHG in PVHVM domain (DomU) and Dom0, I noticed inconsistency (I am using official Xen 4.2 release): Dom0's cmpxchg succeeds (i.e. set ZF flag appropriately) changing Val1 to Val2 PVHVM DomU cmpxchg also succeeds changing Val1 to Val3 even though it was supposedly replaced (Val1 to Val2, Val1 != Val2) by Dom0 already I double checked my code and it seems to be fine. Moreover, the problem appears only on a high contention case (when both Dom0 and DomU are trying to change it). While investigating the issue, I noticed that Xen emulates cmpxchg for PV and HVM cases: 1. Why is it needed to emulate CMPXCHG at all? (What is it used for and can it be disabled? I am using Linux guests.) 2. Is it emulated only in HVM DomU domain or in Dom0 as well?3. Is it possible that emulation has some bug? Is it possible to somehow avoid emulation at all and replace it with something? (I want to avoid performance overhead for this instruction) What if I use CMPXCHG16B, does it still use emulation? Ruslan. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 04:14:36 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 04:14:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJGLb-00008M-5P; Wed, 03 Oct 2012 04:14:11 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJGLZ-00008D-PH for xen-devel@lists.xen.org; Wed, 03 Oct 2012 04:14:09 +0000 Received: from [85.158.139.83:38497] by server-10.bemta-5.messagelabs.com id 54/11-16911-19BBB605; Wed, 03 Oct 2012 04:14:09 +0000 X-Env-Sender: nruslan_devel@yahoo.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1349237647!29266711!1 X-Originating-IP: [98.138.90.80] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_12, ML_RADAR_SPEW_LINKS_14,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 568 invoked from network); 3 Oct 2012 04:14:08 -0000 Received: from nm17.bullet.mail.ne1.yahoo.com (HELO nm17.bullet.mail.ne1.yahoo.com) (98.138.90.80) by server-6.tower-182.messagelabs.com with SMTP; 3 Oct 2012 04:14:08 -0000 Received: from [98.138.90.50] by nm17.bullet.mail.ne1.yahoo.com with NNFMP; 03 Oct 2012 04:14:07 -0000 Received: from [98.138.89.162] by tm3.bullet.mail.ne1.yahoo.com with NNFMP; 03 Oct 2012 04:14:07 -0000 Received: from [127.0.0.1] by omp1018.mail.ne1.yahoo.com with NNFMP; 03 Oct 2012 04:14:07 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 264841.6765.bm@omp1018.mail.ne1.yahoo.com Received: (qmail 7009 invoked by uid 60001); 3 Oct 2012 04:14:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1349237647; bh=VCDHDT2ekvo9+JfNFimhxclpN6XB4X5uo6+aquMEkmY=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=fsHTVJ2w1WSxebyy9XFQljdeVDNCk9r9QPs6kgPXlcuLVNXkjFsz3FFyIr73BJKOasXQ/1xvdzmKclo5c4+KfA7hDHaferSRLodL5tYIh60TyNSHsP4ebNvN5TfVwshgj1zqcQ54CmkoZbN7Y5M9BROxgWEeoKjW/MzL4y04Huo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=tjGHD4MN0slqxn56UJOqhQeY/uysRzUhI6yRtcgJ1jIelq9J6BLGQz6MIN7uHyP6A+lyIterLLVarUh/PQVOlCaRLXfTyQtNdTHLbj3SHP8SYSuB/uQMp6tbdkezQtGi3Fav2hxlC0KrdmIdxUMpKZEb2UL+serBtGJfP/rFx28=; X-YMail-OSG: CJcqiSQVM1kwx3Ns8RTrvDVIg97Ls4qV94PMvYK2ncyFZY8 4bmm.gxUPlt0D7lufuTSri0K7cbLmPJu6bc2oUf3RHVaJFDMeTfY2GCJxCS9 NOxIDD8o6p9lbxp.FRucErv49_nvbnzZAQx0tGPL415WnrgpLI0z0gFPZwzr mwpqhqOFGmvYruZUKJP5LG7tzRQFe_kdJUfuBpLgEEKExzLrK4gcapFaBSU8 6qcfpgAZHzAcvjb_SCC9RBvL8nKz0bhAWRbFsyfrQJwBa08Mn3MeWgP0FCRq ioYsXJr_f0AicZ0q4EaZM3CIna86oee.KL7OFwWYmIc_89zwO.AQqm7hk_Bm jICc8qEvrw87xightR1loVqqK6T2R2c34O.yfnUa2JCuqEYTj1Ocx6QWMFWk EeEZarJC8_CKdCgbw1fxAKDgllJXrSJ4AlmkSO_57MLS9Cav7Z9bRZv_UA7l rVWgrYC8wqJfov85tCiwB7krvkyzUZaXT_67xsl4A9r2OFPrkc39AH7NFUHC iM65sL.dURoI.8pE- Received: from [71.62.157.55] by web124505.mail.ne1.yahoo.com via HTTP; Tue, 02 Oct 2012 21:14:07 PDT X-Mailer: YahooMailWebService/0.8.122.442 References: <1349237357.71534.YahooMailNeo@web124501.mail.ne1.yahoo.com> Message-ID: <1349237647.75192.YahooMailNeo@web124505.mail.ne1.yahoo.com> Date: Tue, 2 Oct 2012 21:14:07 -0700 (PDT) From: Ruslan Nikolaev To: "xen-devel@lists.xen.org" In-Reply-To: <1349237357.71534.YahooMailNeo@web124501.mail.ne1.yahoo.com> MIME-Version: 1.0 Subject: Re: [Xen-devel] Emulation of cmpxchg in Xen 4.2 (also possible bug) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Ruslan Nikolaev List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Just one clarification to my message below: I am using a shared page between DomU HVM and Dom0. (This is used as a shared buffer and cmpxchg changes atomic variable there.) Ruslan ----- Original Message ----- From: Ruslan Nikolaev To: "xen-devel@lists.xen.org" Cc: Sent: Wednesday, October 3, 2012 12:09 AM Subject: Emulation of cmpxchg in Xen 4.2 (also possible bug) Hi While experimenting with a heavy testload which makes a lot of CMPXCHG in PVHVM domain (DomU) and Dom0, I noticed inconsistency (I am using official Xen 4.2 release): Dom0's cmpxchg succeeds (i.e. set ZF flag appropriately) changing Val1 to Val2 PVHVM DomU cmpxchg also succeeds changing Val1 to Val3 even though it was supposedly replaced (Val1 to Val2, Val1 != Val2) by Dom0 already I double checked my code and it seems to be fine. Moreover, the problem appears only on a high contention case (when both Dom0 and DomU are trying to change it). While investigating the issue, I noticed that Xen emulates cmpxchg for PV and HVM cases: 1. Why is it needed to emulate CMPXCHG at all? (What is it used for and can it be disabled? I am using Linux guests.) 2. Is it emulated only in HVM DomU domain or in Dom0 as well?3. Is it possible that emulation has some bug? Is it possible to somehow avoid emulation at all and replace it with something? (I want to avoid performance overhead for this instruction) What if I use CMPXCHG16B, does it still use emulation? Ruslan. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 04:59:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 04:59:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJH2t-0000fT-GO; Wed, 03 Oct 2012 04:58:55 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJH2r-0000fO-6Z for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 04:58:53 +0000 Received: from [85.158.139.211:29220] by server-15.bemta-5.messagelabs.com id EC/60-19430-C06CB605; Wed, 03 Oct 2012 04:58:52 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-16.tower-206.messagelabs.com!1349240331!20887850!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI5OTg=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3607 invoked from network); 3 Oct 2012 04:58:52 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 04:58:52 -0000 X-IronPort-AV: E=Sophos;i="4.80,527,1344211200"; d="scan'208";a="14906047" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 04:58:51 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 05:58:51 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TJH2p-0006sL-BK; Wed, 03 Oct 2012 04:58:51 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1TJH2o-0007Ly-Rp; Wed, 03 Oct 2012 05:58:51 +0100 To: Message-ID: From: xen.org Date: Wed, 3 Oct 2012 05:58:50 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 13913: tolerable FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 13913 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13913/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 5 xen-boot fail like 13911 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail like 13911 test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail like 13911 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail like 13911 Tests which did not succeed, but are not blocking: test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: xen 87bf99fad7a9 baseline version: xen 87bf99fad7a9 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-amd64-amd64-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 04:59:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 04:59:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJH2t-0000fT-GO; Wed, 03 Oct 2012 04:58:55 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJH2r-0000fO-6Z for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 04:58:53 +0000 Received: from [85.158.139.211:29220] by server-15.bemta-5.messagelabs.com id EC/60-19430-C06CB605; Wed, 03 Oct 2012 04:58:52 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-16.tower-206.messagelabs.com!1349240331!20887850!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI5OTg=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3607 invoked from network); 3 Oct 2012 04:58:52 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 04:58:52 -0000 X-IronPort-AV: E=Sophos;i="4.80,527,1344211200"; d="scan'208";a="14906047" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 04:58:51 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 05:58:51 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TJH2p-0006sL-BK; Wed, 03 Oct 2012 04:58:51 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1TJH2o-0007Ly-Rp; Wed, 03 Oct 2012 05:58:51 +0100 To: Message-ID: From: xen.org Date: Wed, 3 Oct 2012 05:58:50 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 13913: tolerable FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 13913 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13913/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 5 xen-boot fail like 13911 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail like 13911 test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail like 13911 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail like 13911 Tests which did not succeed, but are not blocking: test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: xen 87bf99fad7a9 baseline version: xen 87bf99fad7a9 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-amd64-amd64-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 05:51:05 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 05:51:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJHqs-0001Hg-WB; Wed, 03 Oct 2012 05:50:34 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJHqr-0001Hb-PL for xen-devel@lists.xen.org; Wed, 03 Oct 2012 05:50:33 +0000 Received: from [85.158.137.99:23348] by server-11.bemta-3.messagelabs.com id CD/4B-21460-922DB605; Wed, 03 Oct 2012 05:50:33 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-4.tower-217.messagelabs.com!1349243432!20067780!1 X-Originating-IP: [209.85.212.173] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11783 invoked from network); 3 Oct 2012 05:50:32 -0000 Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com) (209.85.212.173) by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 05:50:32 -0000 Received: by mail-wi0-f173.google.com with SMTP id hm4so1567705wib.14 for ; Tue, 02 Oct 2012 22:50:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=4F7FlKJCb9aYZs+UDg5KqEqmyk2VOsrwJZUwLYRhA7I=; b=tLXxk2/vbUnSzQXYoMjGvxiYSstlqO3QoXWob/1s0GodFPJYJ4SKQg4QH6MVCMYeir X9s0OZnOXSxna4G6E/r6K4a+x2Tazb2fvtzflCdwoYZizSD1CFuoAkjKqFeOPqslmUym HbakFoGGkMV2v2JyJq+stheMvQPi6fpqHaiGEqF/lGQeFbIWzTE4YYzp6CvpZBFnk7d0 SJ/WqRjltVE7VXZ1abst0jYU2OD5Hk0YbPzq9fOU0spW322jIq/WCGuVjcZd2ZdajDRV SN+VtPTKnhHhoYQ5TSgrly2WUDhibdpcuyshRUlnJQ/h1ptLsFsRGbU25HO0brib3b82 7s7w== Received: by 10.216.141.14 with SMTP id f14mr567698wej.208.1349243432015; Tue, 02 Oct 2012 22:50:32 -0700 (PDT) Received: from [192.168.1.69] (host86-183-156-141.range86-183.btcentralplus.com. [86.183.156.141]) by mx.google.com with ESMTPS id q4sm25168387wix.9.2012.10.02.22.50.25 (version=SSLv3 cipher=OTHER); Tue, 02 Oct 2012 22:50:31 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 03 Oct 2012 06:50:22 +0100 From: Keir Fraser To: Ruslan Nikolaev , "xen-devel@lists.xen.org" Message-ID: Thread-Topic: [Xen-devel] Emulation of cmpxchg in Xen 4.2 (also possible bug) Thread-Index: Ac2hKvoVFUH1T9OrrkO5fqCYtQrjhw== In-Reply-To: <1349237647.75192.YahooMailNeo@web124505.mail.ne1.yahoo.com> Mime-version: 1.0 Subject: Re: [Xen-devel] Emulation of cmpxchg in Xen 4.2 (also possible bug) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Then CMPXCHG should not be being emulated. It is only emulated for things like access to device memory and to pagetables. If the shared page is mapped with write permission in both PV and HVM guests, no emulation should be occurring. -- Keir On 03/10/2012 05:14, "Ruslan Nikolaev" wrote: > Just one clarification to my message below: > > I am using a shared page between DomU HVM and Dom0. (This is used as a shared > buffer and cmpxchg changes atomic variable there.) > > Ruslan > > > > ----- Original Message ----- > From: Ruslan Nikolaev > To: "xen-devel@lists.xen.org" > Cc: > Sent: Wednesday, October 3, 2012 12:09 AM > Subject: Emulation of cmpxchg in Xen 4.2 (also possible bug) > > Hi > > While experimenting with a heavy testload which makes a lot of CMPXCHG in > PVHVM domain (DomU) and Dom0, I noticed inconsistency (I am using official Xen > 4.2 release): > > Dom0's cmpxchg succeeds (i.e. set ZF flag appropriately) changing Val1 to Val2 > > PVHVM DomU cmpxchg also succeeds changing Val1 to Val3 even though it was > supposedly replaced (Val1 to Val2, Val1 != Val2) by Dom0 already > > I double checked my code and it seems to be fine. Moreover, the problem > appears only on a high contention case (when both Dom0 and DomU are trying to > change it). > > While investigating the issue, I noticed that Xen emulates cmpxchg for PV and > HVM cases: > > 1. Why is it needed to emulate CMPXCHG at all? (What is it used for and can it > be disabled? I am using Linux guests.) > > 2. Is it emulated only in HVM DomU domain or in Dom0 as well?3. Is it possible > that emulation has some bug? Is it possible to somehow avoid emulation at all > and replace it with something? (I want to avoid performance overhead for this > instruction) What if I use CMPXCHG16B, does it still use emulation? > > Ruslan. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 05:51:05 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 05:51:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJHqs-0001Hg-WB; Wed, 03 Oct 2012 05:50:34 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJHqr-0001Hb-PL for xen-devel@lists.xen.org; Wed, 03 Oct 2012 05:50:33 +0000 Received: from [85.158.137.99:23348] by server-11.bemta-3.messagelabs.com id CD/4B-21460-922DB605; Wed, 03 Oct 2012 05:50:33 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-4.tower-217.messagelabs.com!1349243432!20067780!1 X-Originating-IP: [209.85.212.173] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11783 invoked from network); 3 Oct 2012 05:50:32 -0000 Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com) (209.85.212.173) by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 05:50:32 -0000 Received: by mail-wi0-f173.google.com with SMTP id hm4so1567705wib.14 for ; Tue, 02 Oct 2012 22:50:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=4F7FlKJCb9aYZs+UDg5KqEqmyk2VOsrwJZUwLYRhA7I=; b=tLXxk2/vbUnSzQXYoMjGvxiYSstlqO3QoXWob/1s0GodFPJYJ4SKQg4QH6MVCMYeir X9s0OZnOXSxna4G6E/r6K4a+x2Tazb2fvtzflCdwoYZizSD1CFuoAkjKqFeOPqslmUym HbakFoGGkMV2v2JyJq+stheMvQPi6fpqHaiGEqF/lGQeFbIWzTE4YYzp6CvpZBFnk7d0 SJ/WqRjltVE7VXZ1abst0jYU2OD5Hk0YbPzq9fOU0spW322jIq/WCGuVjcZd2ZdajDRV SN+VtPTKnhHhoYQ5TSgrly2WUDhibdpcuyshRUlnJQ/h1ptLsFsRGbU25HO0brib3b82 7s7w== Received: by 10.216.141.14 with SMTP id f14mr567698wej.208.1349243432015; Tue, 02 Oct 2012 22:50:32 -0700 (PDT) Received: from [192.168.1.69] (host86-183-156-141.range86-183.btcentralplus.com. [86.183.156.141]) by mx.google.com with ESMTPS id q4sm25168387wix.9.2012.10.02.22.50.25 (version=SSLv3 cipher=OTHER); Tue, 02 Oct 2012 22:50:31 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 03 Oct 2012 06:50:22 +0100 From: Keir Fraser To: Ruslan Nikolaev , "xen-devel@lists.xen.org" Message-ID: Thread-Topic: [Xen-devel] Emulation of cmpxchg in Xen 4.2 (also possible bug) Thread-Index: Ac2hKvoVFUH1T9OrrkO5fqCYtQrjhw== In-Reply-To: <1349237647.75192.YahooMailNeo@web124505.mail.ne1.yahoo.com> Mime-version: 1.0 Subject: Re: [Xen-devel] Emulation of cmpxchg in Xen 4.2 (also possible bug) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Then CMPXCHG should not be being emulated. It is only emulated for things like access to device memory and to pagetables. If the shared page is mapped with write permission in both PV and HVM guests, no emulation should be occurring. -- Keir On 03/10/2012 05:14, "Ruslan Nikolaev" wrote: > Just one clarification to my message below: > > I am using a shared page between DomU HVM and Dom0. (This is used as a shared > buffer and cmpxchg changes atomic variable there.) > > Ruslan > > > > ----- Original Message ----- > From: Ruslan Nikolaev > To: "xen-devel@lists.xen.org" > Cc: > Sent: Wednesday, October 3, 2012 12:09 AM > Subject: Emulation of cmpxchg in Xen 4.2 (also possible bug) > > Hi > > While experimenting with a heavy testload which makes a lot of CMPXCHG in > PVHVM domain (DomU) and Dom0, I noticed inconsistency (I am using official Xen > 4.2 release): > > Dom0's cmpxchg succeeds (i.e. set ZF flag appropriately) changing Val1 to Val2 > > PVHVM DomU cmpxchg also succeeds changing Val1 to Val3 even though it was > supposedly replaced (Val1 to Val2, Val1 != Val2) by Dom0 already > > I double checked my code and it seems to be fine. Moreover, the problem > appears only on a high contention case (when both Dom0 and DomU are trying to > change it). > > While investigating the issue, I noticed that Xen emulates cmpxchg for PV and > HVM cases: > > 1. Why is it needed to emulate CMPXCHG at all? (What is it used for and can it > be disabled? I am using Linux guests.) > > 2. Is it emulated only in HVM DomU domain or in Dom0 as well?3. Is it possible > that emulation has some bug? Is it possible to somehow avoid emulation at all > and replace it with something? (I want to avoid performance overhead for this > instruction) What if I use CMPXCHG16B, does it still use emulation? > > Ruslan. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 08:27:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 08:27:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJKI9-0002di-VA; Wed, 03 Oct 2012 08:26:53 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJKI8-0002dd-A0 for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 08:26:52 +0000 Received: from [85.158.138.51:3830] by server-10.bemta-3.messagelabs.com id 9B/D4-02525-AC6FB605; Wed, 03 Oct 2012 08:26:50 +0000 X-Env-Sender: fantonifabio@tiscali.it X-Msg-Ref: server-10.tower-174.messagelabs.com!1349252808!25292599!1 X-Originating-IP: [94.23.245.208] X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29130 invoked from network); 3 Oct 2012 08:26:48 -0000 Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208) by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Oct 2012 08:26:48 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by lnx3.fantu.it (Postfix) with ESMTP id CBC1E400FDE; Wed, 3 Oct 2012 10:26:47 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it Received: from lnx3.fantu.it ([127.0.0.1]) by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LUDudgUt4ej; Wed, 3 Oct 2012 10:26:46 +0200 (CEST) Received: from [192.168.178.50] (host51-78-dynamic.2-87-r.retail.telecomitalia.it [87.2.78.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: prova@fantu.it) by lnx3.fantu.it (Postfix) with ESMTPSA id 5180A4008EE; Wed, 3 Oct 2012 10:26:45 +0200 (CEST) Message-ID: <506BF6C0.8020104@tiscali.it> Date: Wed, 03 Oct 2012 10:26:40 +0200 From: Fabio Fantoni User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Lukas Laukamp References: <506AB70D.90908@tiscali.it> <506ABADC.5090400@laukamp.me> <506ABCA1.5010602@tiscali.it> <506AC344.7070704@laukamp.me> In-Reply-To: <506AC344.7070704@laukamp.me> Cc: xen-devel Subject: Re: [Xen-devel] Unable to install Precise domU PV on xen 4.2.0 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: fantonifabio@tiscali.it List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============9168024893931642666==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Questo è un messaggio firmato digitalmente in formato MIME. --===============9168024893931642666== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040202050100070305020205" Questo è un messaggio firmato digitalmente in formato MIME. --------------ms040202050100070305020205 Content-Type: multipart/alternative; boundary="------------030301030404030202080008" This is a multi-part message in MIME format. --------------030301030404030202080008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Il 02/10/2012 12:34, Lukas Laukamp ha scritto: > Am 02.10.2012 12:06, schrieb Fabio Fantoni: >> Il 02/10/2012 11:58, Lukas Laukamp ha scritto: >>> Am 02.10.2012 11:42, schrieb Fabio Fantoni: >>>> Dom0 is wheezy 64 bit, kernel 3.2.23-1 from debian repository, xen=20 >>>> 4.2.0 compiled from source >>>> >>>> When I try to install Precise domU PV with this xl configuration fil= e: >>>> -------------------------------------------- >>>> PRECISE.cfg >>>> ---------------- >>>> name=3D'PRECISE' >>>> memory=3D1024 >>>> vcpus=3D2 >>>> disk=3D['/mnt/vm/disks/PRECISE.disk1.xm,raw,xvda1,rw',=20 >>>> '/mnt/vm/disks/PRECISE.disk2.xm,raw,xvda2,rw'] >>>> #disk=3D['/mnt/vm/disks/PRECISE.disk1.xm,raw,xvda,rw'] >>>> vif=3D['bridge=3Dxenbr0'] >>>> vfb=3D['vnc=3D1,vncunused=3D1,vnclisten=3D0.0.0.0,keymap=3Dit'] >>>> xen_platform_pci=3D1 >>>> #bootloader=3D'pygrub' >>>> #kernel =3D "/usr/lib/xen/boot/pv-grub-x86_64.gz" >>>> #extra =3D "(hd0,0)/grub/grub.cfg" >>>> # Only for installation >>>> kernel=3D"/boot/domu/precise/vmlinuz" >>>> ramdisk=3D"/boot/domu/precise/initrd.gz" >>>> extra =3D "debian-installer/exit/always_halt=3Dtrue -- quiet console= =3Dhvc0" >>>> -------------------------------------------- >>>> >>>> The vmlinux and initrd take from here: >>>> http://archive.ubuntu.com/ubuntu/dists/precise-updates/main/installe= r-amd64/current/images/netboot/xen/=20 >>>> >>>> >>>> xl create /etc/xen/PRECISE.cfg >>>> Parsing config from /etc/xen/PRECISE.cfg >>>> libxl: error: libxl_device.c:858:device_backend_callback: unable to = >>>> disconnect device with path /local/domain/0/backend/vbd/2/51713 >>>> libxl: error: libxl_device.c:858:device_backend_callback: unable to = >>>> disconnect device with path /local/domain/0/backend/vbd/2/51714 >>>> libxl: error: libxl_create.c:933:domcreate_launch_dm: unable to add = >>>> disk devices >>>> libxl: error: libxl_device.c:858:device_backend_callback: unable to = >>>> disconnect device with path /local/domain/0/backend/vbd/2/51713 >>>> libxl: error: libxl_blktap2.c:73:libxl__device_destroy_tapdisk:=20 >>>> Unable to find type aio disk /mnt/vm/disks/PRECISE.disk1.xm: No=20 >>>> such file or directory >>>> libxl: error: libxl_device.c:858:device_backend_callback: unable to = >>>> disconnect device with path /local/domain/0/backend/vbd/2/51714 >>>> libxl: error: libxl.c:1465:devices_destroy_cb:=20 >>>> libxl__devices_destroy failed for 2 >>>> >>>> /mnt/vm/disks/PRECISE.disk1.xm exist, domU hvm with raw disks works >>>> >>>> Is xen bug, kernel bug or my error? >>>> Thanks for any reply >>>> >>>> >>>> >>>> _______________________________________________ >>>> Xen-devel mailing list >>>> Xen-devel@lists.xen.org >>>> http://lists.xen.org/xen-devel >>> >>> Hello, >>> >>> I think that the raw parameter isn't needed and is the reason for=20 >>> the device connecting error. Another way to install the guest would=20 >>> be to use debootstrap. This definitly works. >>> >>> Best Regards >>> >>> Nessun virus nel messaggio. >>> Controllato da AVG - www.avg.com >>> Versione: 2012.0.2221 / Database dei virus: 2441/5303 - Data di=20 >>> rilascio: 01/10/2012 >>> >> Format seem necessary or give this error: >> /etc/xen/PRECISE.cfg: config parsing error in disk specification:=20 >> unknown value for format: near `xvda1' in=20 >> `/mnt/vm/disks/PRECISE.disk1.xm,xvda1,rw' >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel > > Hello, > > do you also have tried to install the guest with debootstrap? > > Best Regards > > Nessun virus nel messaggio. > Controllato da AVG - www.avg.com > Versione: 2012.0.2221 / Database dei virus: 2441/5303 - Data di=20 > rilascio: 01/10/2012 > I tried with Wheezy PV and install working, after I retried with Precise = on new disk and working, seem was only filesystem problem for ext4 bug=20 or bad blocks. Now the problem is another one: I tried to start PV domUs but did not wor= k. On Wheezy domU I tried with pygrub, pv-grub and also with menu.lst with=20 minimal grub1 configuration. See below output and logs. -------------------------------------------------------------------------= ---------------------- xl -vvv create /etc/xen/WHEEZY -------------------------------------------------------------------------= ---------------------- WHEEZY.cfg WHEEZYHVM.cfg root@vfarm:~# xl -vvv create /etc/xen/WHEEZY.cfg Parsing config from /etc/xen/WHEEZY.cfg libxl: debug: libxl_create.c:1173:do_domain_create: ao 0x10700e0:=20 create: how=3D(nil) callback=3D(nil) poller=3D0x106fc10 libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk=20 vdev=3Dxvda spec.backend=3Dunknown libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=3Dxvda,=20 backend phy unsuitable as phys path not a block device libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk=20 vdev=3Dxvda, using backend tap libxl: debug: libxl_create.c:677:initiate_domain_create: running bootload= er libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk=20 vdev=3D(null) spec.backend=3Dtap libxl: debug: libxl.c:2310:libxl__device_disk_local_initiate_attach:=20 locally attaching tap disk /mnt/vm/disks/WHEEZYPV.disk1.xm directly (ie=20 without using blktap) libxl: debug: libxl_bootloader.c:409:bootloader_disk_attached_cb: Config = bootloader value: pygrub libxl: debug: libxl_bootloader.c:425:bootloader_disk_attached_cb:=20 Checking for bootloader in libexec path: /usr/lib/xen/bin/pygrub libxl: debug: libxl_create.c:1186:do_domain_create: ao 0x10700e0:=20 inprogress: poller=3D0x106fc10, flags=3Di libxl: debug: libxl_event.c:512:libxl__ev_xswatch_register: watch=20 w=3D0x1070510 wpath=3D/local/domain/9 token=3D3/0: register slotnum=3D3 libxl: debug: libxl_event.c:1667:libxl__ao_progress_report: ao=20 0x10700e0: progress report: ignored libxl: debug: libxl_bootloader.c:535:bootloader_gotptys: executing=20 bootloader: /usr/lib/xen/bin/pygrub libxl: debug: libxl_bootloader.c:539:bootloader_gotptys: bootloader arg: = /usr/lib/xen/bin/pygrub libxl: debug: libxl_bootloader.c:539:bootloader_gotptys: bootloader arg: = --output=3D/var/run/xen/bootloader.9.out libxl: debug: libxl_bootloader.c:539:bootloader_gotptys: bootloader arg: = --output-format=3Dsimple0 libxl: debug: libxl_bootloader.c:539:bootloader_gotptys: bootloader arg: = --output-directory=3D/var/run/xen/bootloader.9.d libxl: debug: libxl_bootloader.c:539:bootloader_gotptys: bootloader arg: = /mnt/vm/disks/WHEEZYPV.disk1.xm libxl: debug: libxl_event.c:457:watchfd_callback: watch w=3D0x1070510=20 wpath=3D/local/domain/9 token=3D3/0: event epath=3D/local/domain/9 libxl: error: libxl_bootloader.c:628:bootloader_finished: bootloader=20 failed - consult logfile /var/log/xen/bootloader.9.log libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: bootloader = [8800] exited with error status 1 libxl: debug: libxl_event.c:549:libxl__ev_xswatch_deregister: watch=20 w=3D0x1070510 wpath=3D/local/domain/9 token=3D3/0: deregister slotnum=3D3= libxl: error: libxl_create.c:901:domcreate_rebuild_done: cannot=20 (re-)build domain: -3 libxl: debug: libxl_event.c:1497:libxl__ao_complete: ao 0x10700e0:=20 complete, rc=3D-3 libxl: debug: libxl_event.c:1469:libxl__ao__destroy: ao 0x10700e0: destro= y xc: debug: hypercall buffer: total allocations:19 total releases:19 xc: debug: hypercall buffer: current allocations:0 maximum allocations:2 xc: debug: hypercall buffer: cache current size:2 xc: debug: hypercall buffer: cache hits:15 misses:2 toobig:2 -------------------------------------------------------------------------= ---------------------- -------------------------------------------------------------------------= ---------------------- /var/log/xen/bootloader.9.log -------------------------------------------------------------------------= ---------------------- Traceback (most recent call last): File "/usr/lib/xen/bin/pygrub", line 20, in import xen.lowlevel.xc ImportError: No module named xen.lowlevel.xc -------------------------------------------------------------------------= ---------------------- -------------------------------------------------------------------------= ---------------------- /etc/xen/WHEEZY.cfg -------------------------------------------------------------------------= ---------------------- name=3D'WHEEZY' memory=3D1024 vcpus=3D2 #disk=3D['/mnt/vm/disks/PRECISE.disk1.xm,raw,xvda1,rw',=20 '/mnt/vm/disks/PRECISE.disk2.xm,raw,xvda2,rw'] disk=3D['/mnt/vm/disks/WHEEZYPV.disk1.xm,raw,xvda,rw'] vif=3D['bridge=3Dxenbr0'] vfb=3D['vnc=3D1,vncunused=3D1,vnclisten=3D0.0.0.0,keymap=3Dit'] #xen_platform_pci=3D1 bootloader=3D'pygrub' #kernel =3D "/usr/lib/xen/boot/pv-grub-x86_64.gz" #extra =3D "(hd0,0)/grub/grub.cfg" # Only for installation #kernel=3D"/boot/domu/wheezy/vmlinuz" #ramdisk=3D"/boot/domu/wheezy/initrd.gz" #extra =3D "debian-installer/exit/always_halt=3Dtrue -- quiet console=3Dt= ty0" -------------------------------------------------------------------------= ---------------------- Before xen build I had do this change for python tools working: vi Config.mk PYTHON_PREFIX_ARG =3D Are there other check or modify I must do for have pygrub working on xen = 4.2? Thanks for any reply --------------030301030404030202080008 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Il 02/10/2012 12:34, Lukas Laukamp ha scritto:
Am 02.10.2012 12:06, schrieb Fabio Fantoni:
=
Il 02/10/2012 11:58, Lukas Laukamp= ha scritto:
Am 02.10.2012 11:42, schrieb Fabio Fantoni:
Dom0 is wheezy 64 bit, kernel 3.2.23-1 from debian repository, xen 4.2.0 compiled from source

When I try to install Precise domU PV with this xl configuration file:
--------------------------------------------
PRECISE.cfg
----------------
name=3D'PRECISE'
memory=3D1024
vcpus=3D2
disk=3D['/mnt/vm/disks/PRECISE.disk1.xm,raw,xvda1,rw', '/mnt/vm/disks/PRECISE.disk2.xm,raw,xvda2,rw']
#disk=3D['/mnt/vm/disks/PRECISE.disk1.xm,raw,xvda,rw']
vif=3D['bridge=3Dxenbr0']
vfb=3D['vnc=3D1,vncunused=3D1,vnclisten=3D0.0.0.0,keymap=3Dit= ']
xen_platform_pci=3D1
#bootloader=3D'pygrub'
#kernel =3D "/usr/lib/xen/boot/pv-grub-x86_64.gz"
#extra =3D "(hd0,0)/grub/grub.cfg"
# Only for installation
kernel=3D"/boot/domu/precise/vmlinuz"
ramdisk=3D"/boot/domu/precise/initrd.gz"
extra =3D "debian-installer/exit/always_halt=3Dtrue -- quiet console=3Dhvc0"
--------------------------------------------

The vmlinux and initrd take from here:
http://archive.ubuntu.com/ubuntu/= dists/precise-updates/main/installer-amd64/current/images/netboot/xen/

xl create /etc/xen/PRECISE.cfg
Parsing config from /etc/xen/PRECISE.cfg
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vbd/2/51713
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vbd/2/51714
libxl: error: libxl_create.c:933:domcreate_launch_dm: unable to add disk devices
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vbd/2/51713
libxl: error: libxl_blktap2.c:73:libxl__device_destroy_tapdisk: Unable to find type aio disk /mnt/vm/disks/PRECISE.disk1.xm: No such file or directory
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vbd/2/51714
libxl: error: libxl.c:1465:devices_destroy_cb: libxl__devices_destroy failed for 2

/mnt/vm/disks/PRECISE.disk1.xm exist, domU hvm with raw disks works

Is xen bug, kernel bug or my error?
Thanks for any reply 



______________________________________________=
_
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Hello,

I think that the raw parameter isn't needed and is the reason for the device connecting error. Another way to install the guest would be to use debootstrap. This definitly works.

Best Regards

N= essun virus nel messaggio.
Controllato da AVG - www.avg.com
Versione: 2012.0.2221 / Database dei virus: 2441/5303 - Data di rilascio: 01/10/2012

Format seem necessary or give this error:
/etc/xen/PRECISE.cfg: config parsing error in disk specification: unknown value for format: near `xvda1' in `/mnt/vm/disks/PRECISE.disk1.xm,xvda1,rw'


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Hello,

do you also have tried to install the guest with debootstrap?

Best Regards

Nessu= n virus nel messaggio.
Controllato da AVG - www.avg.com
Versione: 2012.0.2221 / Database dei virus: 2441/5303 - Data di rilascio: 01/10/2012

I tried with Wheezy PV and install working, after I retried with Precise on new disk and working, seem was only filesystem problem for ext4 bug or bad blocks.
Now the problem is another one: I tried to start PV domUs but did not work.
On Wheezy domU I tried with pygrub, pv-grub and also with menu.lst with minimal grub1 configuration.
See below output and logs.

-------------------------------------------------------------------------= ----------------------
xl -vvv create /etc/xen/WHEEZY
-------------------------------------------------------------------------= ----------------------
WHEEZY.cfg     WHEEZYHVM.cfg 
root@vfarm:~# xl -vvv create /etc/xen/WHEEZY.cfg
Parsing config from /etc/xen/WHEEZY.cfg
libxl: debug: libxl_create.c:1173:do_domain_create: ao 0x10700e0: create: how=3D(nil) callback=3D(nil) poller=3D0x106fc10
libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk vdev=3Dxvda spec.backend=3Dunknown
libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=3Dxvda, backend phy unsuitable as phys path not a block device
libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk vdev=3Dxvda, using backend tap
libxl: debug: libxl_create.c:677:initiate_domain_create: running bootloader
libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk vdev=3D(null) spec.backend=3Dtap
libxl: debug: libxl.c:2310:libxl__device_disk_local_initiate_attach: locally attaching tap disk /mnt/vm/disks/WHEEZYPV.disk1.xm directly (ie without using blktap)
libxl: debug: libxl_bootloader.c:409:bootloader_disk_attached_cb: Config bootloader value: pygrub
libxl: debug: libxl_bootloader.c:425:bootloader_disk_attached_cb: Checking for bootloader in libexec path: /usr/lib/xen/bin/pygrub
libxl: debug: libxl_create.c:1186:do_domain_create: ao 0x10700e0: inprogress: poller=3D0x106fc10, flags=3Di
libxl: debug: libxl_event.c:512:libxl__ev_xswatch_register: watch w=3D0x1070510 wpath=3D/local/domain/9 token=3D3/0: register slotnum=3D= 3
libxl: debug: libxl_event.c:1667:libxl__ao_progress_report: ao 0x10700e0: progress report: ignored
libxl: debug: libxl_bootloader.c:535:bootloader_gotptys: executing bootloader: /usr/lib/xen/bin/pygrub
libxl: debug: libxl_bootloader.c:539:bootloader_gotptys:   bootloader arg: /usr/lib/xen/bin/pygrub
libxl: debug: libxl_bootloader.c:539:bootloader_gotptys:   bootloader arg: --output=3D/var/run/xen/bootloader.9.out
libxl: debug: libxl_bootloader.c:539:bootloader_gotptys:   bootloader arg: --output-format=3Dsimple0
libxl: debug: libxl_bootloader.c:539:bootloader_gotptys:   bootloader arg: --output-directory=3D/var/run/xen/bootloader.9.d
libxl: debug: libxl_bootloader.c:539:bootloader_gotptys:   bootloader arg: /mnt/vm/disks/WHEEZYPV.disk1.xm
libxl: debug: libxl_event.c:457:watchfd_callback: watch w=3D0x1070510= wpath=3D/local/domain/9 token=3D3/0: event epath=3D/local/domain/9 libxl: error: libxl_bootloader.c:628:bootloader_finished: bootloader failed - consult logfile /var/log/xen/bootloader.9.log
libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: bootloader [8800] exited with error status 1
libxl: debug: libxl_event.c:549:libxl__ev_xswatch_deregister: watch w=3D0x1070510 wpath=3D/local/domain/9 token=3D3/0: deregister slotnum= =3D3
libxl: error: libxl_create.c:901:domcreate_rebuild_done: cannot (re-)build domain: -3
libxl: debug: libxl_event.c:1497:libxl__ao_complete: ao 0x10700e0: complete, rc=3D-3
libxl: debug: libxl_event.c:1469:libxl__ao__destroy: ao 0x10700e0: destroy
xc: debug: hypercall buffer: total allocations:19 total releases:19 xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
xc: debug: hypercall buffer: cache current size:2
xc: debug: hypercall buffer: cache hits:15 misses:2 toobig:2
-------------------------------------------------------------------------= ----------------------

-------------------------------------------------------------------------= ----------------------
/var/log/xen/bootloader.9.log
-------------------------------------------------------------------------= ----------------------
Traceback (most recent call last):
  File "/usr/lib/xen/bin/pygrub", line 20, in <module>
=     import xen.lowlevel.xc
ImportError: No module named xen.lowlevel.xc
-------------------------------------------------------------------------= ----------------------

-------------------------------------------------------------------------= ----------------------
/etc/xen/WHEEZY.cfg
-------------------------------------------------------------------------= ----------------------
name=3D'WHEEZY'
memory=3D1024
vcpus=3D2
#disk=3D['/mnt/vm/disks/PRECISE.disk1.xm,raw,xvda1,rw', '/mnt/vm/disks/PRECISE.disk2.xm,raw,xvda2,rw']
disk=3D['/mnt/vm/disks/WHEEZYPV.disk1.xm,raw,xvda,rw']
vif=3D['bridge=3Dxenbr0']
vfb=3D['vnc=3D1,vncunused=3D1,vnclisten=3D0.0.0.0,keymap=3Dit']
#xen_platform_pci=3D1
bootloader=3D'pygrub'
#kernel =3D "/usr/lib/xen/boot/pv-grub-x86_64.gz"
#extra =3D "(hd0,0)/grub/grub.cfg"
# Only for installation
#kernel=3D"/boot/domu/wheezy/vmlinuz"
#ramdisk=3D"/boot/domu/wheezy/initrd.gz"
#extra =3D "debian-installer/exit/always_halt=3Dtrue -- quiet console=3Dtty0"
-------------------------------------------------------------------------= ----------------------

Before xen build I had do this change for python tools working:
vi Config.mk
PYTHON_PREFIX_ARG =3D

Are there other check or modify I must do for have pygrub working on xen 4.2?
Thanks for any reply


--------------030301030404030202080008-- --------------ms040202050100070305020205 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: Firma crittografica S/MIME MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi 8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y 2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT +HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC 0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV 10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2 YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8 h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1 kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8 oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+ qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1 XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTEyMTAwMzA4MjY0MFowIwYJKoZIhvcNAQkEMRYEFF3ysAmsRGJvgLnlGGC13oyx KD1QMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAmDoXYXpdBCbBiXntgutiS3dS nu2Q1SRngeSRRn+ylihLmGbuCzbjCDKEwGfe/Wc3UfsxYQ44KUryvHRM9gtMzv/5wY3UhzKY 3a3VnCHJDaol3uFxw+pEEtYQSxKZlCj6ASVyCv14eolTOjj/8QY0NoxvKBIwPI3Be2hEVt9M gfPCmKdRKkouKTWxSuwRB2mNiFp1h4WV79X9uwWKRys/qeWHSp5f+paxHibC8wdEPwAXObRN FBcAwZSuHBfZXg3mMByDYkkDIedwWI72hMtcs1t4sCOs1RDYGQA59uh5k7VfjLyqJUGlRY7n oAv0GuYypKfJH3anntgEKt05AmCIAgAAAAAAAA== --------------ms040202050100070305020205-- --===============9168024893931642666== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============9168024893931642666==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 08:27:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 08:27:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJKI9-0002di-VA; Wed, 03 Oct 2012 08:26:53 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJKI8-0002dd-A0 for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 08:26:52 +0000 Received: from [85.158.138.51:3830] by server-10.bemta-3.messagelabs.com id 9B/D4-02525-AC6FB605; Wed, 03 Oct 2012 08:26:50 +0000 X-Env-Sender: fantonifabio@tiscali.it X-Msg-Ref: server-10.tower-174.messagelabs.com!1349252808!25292599!1 X-Originating-IP: [94.23.245.208] X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29130 invoked from network); 3 Oct 2012 08:26:48 -0000 Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208) by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Oct 2012 08:26:48 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by lnx3.fantu.it (Postfix) with ESMTP id CBC1E400FDE; Wed, 3 Oct 2012 10:26:47 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it Received: from lnx3.fantu.it ([127.0.0.1]) by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LUDudgUt4ej; Wed, 3 Oct 2012 10:26:46 +0200 (CEST) Received: from [192.168.178.50] (host51-78-dynamic.2-87-r.retail.telecomitalia.it [87.2.78.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: prova@fantu.it) by lnx3.fantu.it (Postfix) with ESMTPSA id 5180A4008EE; Wed, 3 Oct 2012 10:26:45 +0200 (CEST) Message-ID: <506BF6C0.8020104@tiscali.it> Date: Wed, 03 Oct 2012 10:26:40 +0200 From: Fabio Fantoni User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Lukas Laukamp References: <506AB70D.90908@tiscali.it> <506ABADC.5090400@laukamp.me> <506ABCA1.5010602@tiscali.it> <506AC344.7070704@laukamp.me> In-Reply-To: <506AC344.7070704@laukamp.me> Cc: xen-devel Subject: Re: [Xen-devel] Unable to install Precise domU PV on xen 4.2.0 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: fantonifabio@tiscali.it List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============9168024893931642666==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Questo è un messaggio firmato digitalmente in formato MIME. --===============9168024893931642666== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040202050100070305020205" Questo è un messaggio firmato digitalmente in formato MIME. --------------ms040202050100070305020205 Content-Type: multipart/alternative; boundary="------------030301030404030202080008" This is a multi-part message in MIME format. --------------030301030404030202080008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Il 02/10/2012 12:34, Lukas Laukamp ha scritto: > Am 02.10.2012 12:06, schrieb Fabio Fantoni: >> Il 02/10/2012 11:58, Lukas Laukamp ha scritto: >>> Am 02.10.2012 11:42, schrieb Fabio Fantoni: >>>> Dom0 is wheezy 64 bit, kernel 3.2.23-1 from debian repository, xen=20 >>>> 4.2.0 compiled from source >>>> >>>> When I try to install Precise domU PV with this xl configuration fil= e: >>>> -------------------------------------------- >>>> PRECISE.cfg >>>> ---------------- >>>> name=3D'PRECISE' >>>> memory=3D1024 >>>> vcpus=3D2 >>>> disk=3D['/mnt/vm/disks/PRECISE.disk1.xm,raw,xvda1,rw',=20 >>>> '/mnt/vm/disks/PRECISE.disk2.xm,raw,xvda2,rw'] >>>> #disk=3D['/mnt/vm/disks/PRECISE.disk1.xm,raw,xvda,rw'] >>>> vif=3D['bridge=3Dxenbr0'] >>>> vfb=3D['vnc=3D1,vncunused=3D1,vnclisten=3D0.0.0.0,keymap=3Dit'] >>>> xen_platform_pci=3D1 >>>> #bootloader=3D'pygrub' >>>> #kernel =3D "/usr/lib/xen/boot/pv-grub-x86_64.gz" >>>> #extra =3D "(hd0,0)/grub/grub.cfg" >>>> # Only for installation >>>> kernel=3D"/boot/domu/precise/vmlinuz" >>>> ramdisk=3D"/boot/domu/precise/initrd.gz" >>>> extra =3D "debian-installer/exit/always_halt=3Dtrue -- quiet console= =3Dhvc0" >>>> -------------------------------------------- >>>> >>>> The vmlinux and initrd take from here: >>>> http://archive.ubuntu.com/ubuntu/dists/precise-updates/main/installe= r-amd64/current/images/netboot/xen/=20 >>>> >>>> >>>> xl create /etc/xen/PRECISE.cfg >>>> Parsing config from /etc/xen/PRECISE.cfg >>>> libxl: error: libxl_device.c:858:device_backend_callback: unable to = >>>> disconnect device with path /local/domain/0/backend/vbd/2/51713 >>>> libxl: error: libxl_device.c:858:device_backend_callback: unable to = >>>> disconnect device with path /local/domain/0/backend/vbd/2/51714 >>>> libxl: error: libxl_create.c:933:domcreate_launch_dm: unable to add = >>>> disk devices >>>> libxl: error: libxl_device.c:858:device_backend_callback: unable to = >>>> disconnect device with path /local/domain/0/backend/vbd/2/51713 >>>> libxl: error: libxl_blktap2.c:73:libxl__device_destroy_tapdisk:=20 >>>> Unable to find type aio disk /mnt/vm/disks/PRECISE.disk1.xm: No=20 >>>> such file or directory >>>> libxl: error: libxl_device.c:858:device_backend_callback: unable to = >>>> disconnect device with path /local/domain/0/backend/vbd/2/51714 >>>> libxl: error: libxl.c:1465:devices_destroy_cb:=20 >>>> libxl__devices_destroy failed for 2 >>>> >>>> /mnt/vm/disks/PRECISE.disk1.xm exist, domU hvm with raw disks works >>>> >>>> Is xen bug, kernel bug or my error? >>>> Thanks for any reply >>>> >>>> >>>> >>>> _______________________________________________ >>>> Xen-devel mailing list >>>> Xen-devel@lists.xen.org >>>> http://lists.xen.org/xen-devel >>> >>> Hello, >>> >>> I think that the raw parameter isn't needed and is the reason for=20 >>> the device connecting error. Another way to install the guest would=20 >>> be to use debootstrap. This definitly works. >>> >>> Best Regards >>> >>> Nessun virus nel messaggio. >>> Controllato da AVG - www.avg.com >>> Versione: 2012.0.2221 / Database dei virus: 2441/5303 - Data di=20 >>> rilascio: 01/10/2012 >>> >> Format seem necessary or give this error: >> /etc/xen/PRECISE.cfg: config parsing error in disk specification:=20 >> unknown value for format: near `xvda1' in=20 >> `/mnt/vm/disks/PRECISE.disk1.xm,xvda1,rw' >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel > > Hello, > > do you also have tried to install the guest with debootstrap? > > Best Regards > > Nessun virus nel messaggio. > Controllato da AVG - www.avg.com > Versione: 2012.0.2221 / Database dei virus: 2441/5303 - Data di=20 > rilascio: 01/10/2012 > I tried with Wheezy PV and install working, after I retried with Precise = on new disk and working, seem was only filesystem problem for ext4 bug=20 or bad blocks. Now the problem is another one: I tried to start PV domUs but did not wor= k. On Wheezy domU I tried with pygrub, pv-grub and also with menu.lst with=20 minimal grub1 configuration. See below output and logs. -------------------------------------------------------------------------= ---------------------- xl -vvv create /etc/xen/WHEEZY -------------------------------------------------------------------------= ---------------------- WHEEZY.cfg WHEEZYHVM.cfg root@vfarm:~# xl -vvv create /etc/xen/WHEEZY.cfg Parsing config from /etc/xen/WHEEZY.cfg libxl: debug: libxl_create.c:1173:do_domain_create: ao 0x10700e0:=20 create: how=3D(nil) callback=3D(nil) poller=3D0x106fc10 libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk=20 vdev=3Dxvda spec.backend=3Dunknown libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=3Dxvda,=20 backend phy unsuitable as phys path not a block device libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk=20 vdev=3Dxvda, using backend tap libxl: debug: libxl_create.c:677:initiate_domain_create: running bootload= er libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk=20 vdev=3D(null) spec.backend=3Dtap libxl: debug: libxl.c:2310:libxl__device_disk_local_initiate_attach:=20 locally attaching tap disk /mnt/vm/disks/WHEEZYPV.disk1.xm directly (ie=20 without using blktap) libxl: debug: libxl_bootloader.c:409:bootloader_disk_attached_cb: Config = bootloader value: pygrub libxl: debug: libxl_bootloader.c:425:bootloader_disk_attached_cb:=20 Checking for bootloader in libexec path: /usr/lib/xen/bin/pygrub libxl: debug: libxl_create.c:1186:do_domain_create: ao 0x10700e0:=20 inprogress: poller=3D0x106fc10, flags=3Di libxl: debug: libxl_event.c:512:libxl__ev_xswatch_register: watch=20 w=3D0x1070510 wpath=3D/local/domain/9 token=3D3/0: register slotnum=3D3 libxl: debug: libxl_event.c:1667:libxl__ao_progress_report: ao=20 0x10700e0: progress report: ignored libxl: debug: libxl_bootloader.c:535:bootloader_gotptys: executing=20 bootloader: /usr/lib/xen/bin/pygrub libxl: debug: libxl_bootloader.c:539:bootloader_gotptys: bootloader arg: = /usr/lib/xen/bin/pygrub libxl: debug: libxl_bootloader.c:539:bootloader_gotptys: bootloader arg: = --output=3D/var/run/xen/bootloader.9.out libxl: debug: libxl_bootloader.c:539:bootloader_gotptys: bootloader arg: = --output-format=3Dsimple0 libxl: debug: libxl_bootloader.c:539:bootloader_gotptys: bootloader arg: = --output-directory=3D/var/run/xen/bootloader.9.d libxl: debug: libxl_bootloader.c:539:bootloader_gotptys: bootloader arg: = /mnt/vm/disks/WHEEZYPV.disk1.xm libxl: debug: libxl_event.c:457:watchfd_callback: watch w=3D0x1070510=20 wpath=3D/local/domain/9 token=3D3/0: event epath=3D/local/domain/9 libxl: error: libxl_bootloader.c:628:bootloader_finished: bootloader=20 failed - consult logfile /var/log/xen/bootloader.9.log libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: bootloader = [8800] exited with error status 1 libxl: debug: libxl_event.c:549:libxl__ev_xswatch_deregister: watch=20 w=3D0x1070510 wpath=3D/local/domain/9 token=3D3/0: deregister slotnum=3D3= libxl: error: libxl_create.c:901:domcreate_rebuild_done: cannot=20 (re-)build domain: -3 libxl: debug: libxl_event.c:1497:libxl__ao_complete: ao 0x10700e0:=20 complete, rc=3D-3 libxl: debug: libxl_event.c:1469:libxl__ao__destroy: ao 0x10700e0: destro= y xc: debug: hypercall buffer: total allocations:19 total releases:19 xc: debug: hypercall buffer: current allocations:0 maximum allocations:2 xc: debug: hypercall buffer: cache current size:2 xc: debug: hypercall buffer: cache hits:15 misses:2 toobig:2 -------------------------------------------------------------------------= ---------------------- -------------------------------------------------------------------------= ---------------------- /var/log/xen/bootloader.9.log -------------------------------------------------------------------------= ---------------------- Traceback (most recent call last): File "/usr/lib/xen/bin/pygrub", line 20, in import xen.lowlevel.xc ImportError: No module named xen.lowlevel.xc -------------------------------------------------------------------------= ---------------------- -------------------------------------------------------------------------= ---------------------- /etc/xen/WHEEZY.cfg -------------------------------------------------------------------------= ---------------------- name=3D'WHEEZY' memory=3D1024 vcpus=3D2 #disk=3D['/mnt/vm/disks/PRECISE.disk1.xm,raw,xvda1,rw',=20 '/mnt/vm/disks/PRECISE.disk2.xm,raw,xvda2,rw'] disk=3D['/mnt/vm/disks/WHEEZYPV.disk1.xm,raw,xvda,rw'] vif=3D['bridge=3Dxenbr0'] vfb=3D['vnc=3D1,vncunused=3D1,vnclisten=3D0.0.0.0,keymap=3Dit'] #xen_platform_pci=3D1 bootloader=3D'pygrub' #kernel =3D "/usr/lib/xen/boot/pv-grub-x86_64.gz" #extra =3D "(hd0,0)/grub/grub.cfg" # Only for installation #kernel=3D"/boot/domu/wheezy/vmlinuz" #ramdisk=3D"/boot/domu/wheezy/initrd.gz" #extra =3D "debian-installer/exit/always_halt=3Dtrue -- quiet console=3Dt= ty0" -------------------------------------------------------------------------= ---------------------- Before xen build I had do this change for python tools working: vi Config.mk PYTHON_PREFIX_ARG =3D Are there other check or modify I must do for have pygrub working on xen = 4.2? Thanks for any reply --------------030301030404030202080008 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Il 02/10/2012 12:34, Lukas Laukamp ha scritto:
Am 02.10.2012 12:06, schrieb Fabio Fantoni:
=
Il 02/10/2012 11:58, Lukas Laukamp= ha scritto:
Am 02.10.2012 11:42, schrieb Fabio Fantoni:
Dom0 is wheezy 64 bit, kernel 3.2.23-1 from debian repository, xen 4.2.0 compiled from source

When I try to install Precise domU PV with this xl configuration file:
--------------------------------------------
PRECISE.cfg
----------------
name=3D'PRECISE'
memory=3D1024
vcpus=3D2
disk=3D['/mnt/vm/disks/PRECISE.disk1.xm,raw,xvda1,rw', '/mnt/vm/disks/PRECISE.disk2.xm,raw,xvda2,rw']
#disk=3D['/mnt/vm/disks/PRECISE.disk1.xm,raw,xvda,rw']
vif=3D['bridge=3Dxenbr0']
vfb=3D['vnc=3D1,vncunused=3D1,vnclisten=3D0.0.0.0,keymap=3Dit= ']
xen_platform_pci=3D1
#bootloader=3D'pygrub'
#kernel =3D "/usr/lib/xen/boot/pv-grub-x86_64.gz"
#extra =3D "(hd0,0)/grub/grub.cfg"
# Only for installation
kernel=3D"/boot/domu/precise/vmlinuz"
ramdisk=3D"/boot/domu/precise/initrd.gz"
extra =3D "debian-installer/exit/always_halt=3Dtrue -- quiet console=3Dhvc0"
--------------------------------------------

The vmlinux and initrd take from here:
http://archive.ubuntu.com/ubuntu/= dists/precise-updates/main/installer-amd64/current/images/netboot/xen/

xl create /etc/xen/PRECISE.cfg
Parsing config from /etc/xen/PRECISE.cfg
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vbd/2/51713
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vbd/2/51714
libxl: error: libxl_create.c:933:domcreate_launch_dm: unable to add disk devices
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vbd/2/51713
libxl: error: libxl_blktap2.c:73:libxl__device_destroy_tapdisk: Unable to find type aio disk /mnt/vm/disks/PRECISE.disk1.xm: No such file or directory
libxl: error: libxl_device.c:858:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/vbd/2/51714
libxl: error: libxl.c:1465:devices_destroy_cb: libxl__devices_destroy failed for 2

/mnt/vm/disks/PRECISE.disk1.xm exist, domU hvm with raw disks works

Is xen bug, kernel bug or my error?
Thanks for any reply 



______________________________________________=
_
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Hello,

I think that the raw parameter isn't needed and is the reason for the device connecting error. Another way to install the guest would be to use debootstrap. This definitly works.

Best Regards

N= essun virus nel messaggio.
Controllato da AVG - www.avg.com
Versione: 2012.0.2221 / Database dei virus: 2441/5303 - Data di rilascio: 01/10/2012

Format seem necessary or give this error:
/etc/xen/PRECISE.cfg: config parsing error in disk specification: unknown value for format: near `xvda1' in `/mnt/vm/disks/PRECISE.disk1.xm,xvda1,rw'


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Hello,

do you also have tried to install the guest with debootstrap?

Best Regards

Nessu= n virus nel messaggio.
Controllato da AVG - www.avg.com
Versione: 2012.0.2221 / Database dei virus: 2441/5303 - Data di rilascio: 01/10/2012

I tried with Wheezy PV and install working, after I retried with Precise on new disk and working, seem was only filesystem problem for ext4 bug or bad blocks.
Now the problem is another one: I tried to start PV domUs but did not work.
On Wheezy domU I tried with pygrub, pv-grub and also with menu.lst with minimal grub1 configuration.
See below output and logs.

-------------------------------------------------------------------------= ----------------------
xl -vvv create /etc/xen/WHEEZY
-------------------------------------------------------------------------= ----------------------
WHEEZY.cfg     WHEEZYHVM.cfg 
root@vfarm:~# xl -vvv create /etc/xen/WHEEZY.cfg
Parsing config from /etc/xen/WHEEZY.cfg
libxl: debug: libxl_create.c:1173:do_domain_create: ao 0x10700e0: create: how=3D(nil) callback=3D(nil) poller=3D0x106fc10
libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk vdev=3Dxvda spec.backend=3Dunknown
libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=3Dxvda, backend phy unsuitable as phys path not a block device
libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk vdev=3Dxvda, using backend tap
libxl: debug: libxl_create.c:677:initiate_domain_create: running bootloader
libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk vdev=3D(null) spec.backend=3Dtap
libxl: debug: libxl.c:2310:libxl__device_disk_local_initiate_attach: locally attaching tap disk /mnt/vm/disks/WHEEZYPV.disk1.xm directly (ie without using blktap)
libxl: debug: libxl_bootloader.c:409:bootloader_disk_attached_cb: Config bootloader value: pygrub
libxl: debug: libxl_bootloader.c:425:bootloader_disk_attached_cb: Checking for bootloader in libexec path: /usr/lib/xen/bin/pygrub
libxl: debug: libxl_create.c:1186:do_domain_create: ao 0x10700e0: inprogress: poller=3D0x106fc10, flags=3Di
libxl: debug: libxl_event.c:512:libxl__ev_xswatch_register: watch w=3D0x1070510 wpath=3D/local/domain/9 token=3D3/0: register slotnum=3D= 3
libxl: debug: libxl_event.c:1667:libxl__ao_progress_report: ao 0x10700e0: progress report: ignored
libxl: debug: libxl_bootloader.c:535:bootloader_gotptys: executing bootloader: /usr/lib/xen/bin/pygrub
libxl: debug: libxl_bootloader.c:539:bootloader_gotptys:   bootloader arg: /usr/lib/xen/bin/pygrub
libxl: debug: libxl_bootloader.c:539:bootloader_gotptys:   bootloader arg: --output=3D/var/run/xen/bootloader.9.out
libxl: debug: libxl_bootloader.c:539:bootloader_gotptys:   bootloader arg: --output-format=3Dsimple0
libxl: debug: libxl_bootloader.c:539:bootloader_gotptys:   bootloader arg: --output-directory=3D/var/run/xen/bootloader.9.d
libxl: debug: libxl_bootloader.c:539:bootloader_gotptys:   bootloader arg: /mnt/vm/disks/WHEEZYPV.disk1.xm
libxl: debug: libxl_event.c:457:watchfd_callback: watch w=3D0x1070510= wpath=3D/local/domain/9 token=3D3/0: event epath=3D/local/domain/9 libxl: error: libxl_bootloader.c:628:bootloader_finished: bootloader failed - consult logfile /var/log/xen/bootloader.9.log
libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: bootloader [8800] exited with error status 1
libxl: debug: libxl_event.c:549:libxl__ev_xswatch_deregister: watch w=3D0x1070510 wpath=3D/local/domain/9 token=3D3/0: deregister slotnum= =3D3
libxl: error: libxl_create.c:901:domcreate_rebuild_done: cannot (re-)build domain: -3
libxl: debug: libxl_event.c:1497:libxl__ao_complete: ao 0x10700e0: complete, rc=3D-3
libxl: debug: libxl_event.c:1469:libxl__ao__destroy: ao 0x10700e0: destroy
xc: debug: hypercall buffer: total allocations:19 total releases:19 xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
xc: debug: hypercall buffer: cache current size:2
xc: debug: hypercall buffer: cache hits:15 misses:2 toobig:2
-------------------------------------------------------------------------= ----------------------

-------------------------------------------------------------------------= ----------------------
/var/log/xen/bootloader.9.log
-------------------------------------------------------------------------= ----------------------
Traceback (most recent call last):
  File "/usr/lib/xen/bin/pygrub", line 20, in <module>
=     import xen.lowlevel.xc
ImportError: No module named xen.lowlevel.xc
-------------------------------------------------------------------------= ----------------------

-------------------------------------------------------------------------= ----------------------
/etc/xen/WHEEZY.cfg
-------------------------------------------------------------------------= ----------------------
name=3D'WHEEZY'
memory=3D1024
vcpus=3D2
#disk=3D['/mnt/vm/disks/PRECISE.disk1.xm,raw,xvda1,rw', '/mnt/vm/disks/PRECISE.disk2.xm,raw,xvda2,rw']
disk=3D['/mnt/vm/disks/WHEEZYPV.disk1.xm,raw,xvda,rw']
vif=3D['bridge=3Dxenbr0']
vfb=3D['vnc=3D1,vncunused=3D1,vnclisten=3D0.0.0.0,keymap=3Dit']
#xen_platform_pci=3D1
bootloader=3D'pygrub'
#kernel =3D "/usr/lib/xen/boot/pv-grub-x86_64.gz"
#extra =3D "(hd0,0)/grub/grub.cfg"
# Only for installation
#kernel=3D"/boot/domu/wheezy/vmlinuz"
#ramdisk=3D"/boot/domu/wheezy/initrd.gz"
#extra =3D "debian-installer/exit/always_halt=3Dtrue -- quiet console=3Dtty0"
-------------------------------------------------------------------------= ----------------------

Before xen build I had do this change for python tools working:
vi Config.mk
PYTHON_PREFIX_ARG =3D

Are there other check or modify I must do for have pygrub working on xen 4.2?
Thanks for any reply


--------------030301030404030202080008-- --------------ms040202050100070305020205 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: Firma crittografica S/MIME MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi 8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y 2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT +HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC 0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV 10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2 YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8 h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1 kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8 oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+ qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1 XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTEyMTAwMzA4MjY0MFowIwYJKoZIhvcNAQkEMRYEFF3ysAmsRGJvgLnlGGC13oyx KD1QMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAmDoXYXpdBCbBiXntgutiS3dS nu2Q1SRngeSRRn+ylihLmGbuCzbjCDKEwGfe/Wc3UfsxYQ44KUryvHRM9gtMzv/5wY3UhzKY 3a3VnCHJDaol3uFxw+pEEtYQSxKZlCj6ASVyCv14eolTOjj/8QY0NoxvKBIwPI3Be2hEVt9M gfPCmKdRKkouKTWxSuwRB2mNiFp1h4WV79X9uwWKRys/qeWHSp5f+paxHibC8wdEPwAXObRN FBcAwZSuHBfZXg3mMByDYkkDIedwWI72hMtcs1t4sCOs1RDYGQA59uh5k7VfjLyqJUGlRY7n oAv0GuYypKfJH3anntgEKt05AmCIAgAAAAAAAA== --------------ms040202050100070305020205-- --===============9168024893931642666== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============9168024893931642666==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 08:32:27 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 08:32:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJKN7-0002nA-Vl; Wed, 03 Oct 2012 08:32:01 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJKN6-0002n0-4O for xen-devel@lists.xen.org; Wed, 03 Oct 2012 08:32:00 +0000 Received: from [85.158.139.211:29876] by server-4.bemta-5.messagelabs.com id 28/37-20767-FF7FB605; Wed, 03 Oct 2012 08:31:59 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-15.tower-206.messagelabs.com!1349253118!20923156!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI5OTg=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14822 invoked from network); 3 Oct 2012 08:31:58 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 08:31:58 -0000 X-IronPort-AV: E=Sophos;i="4.80,527,1344211200"; d="scan'208";a="14908657" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 08:31:58 +0000 Received: from [192.168.1.140] (10.31.3.235) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 09:31:58 +0100 Message-ID: <506BF7FD.4000707@citrix.com> Date: Wed, 3 Oct 2012 10:31:57 +0200 From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Ian Campbell References: <20121002163136.GA5378@intersect> <1349196417.650.115.camel@zakaz.uk.xensource.com> In-Reply-To: <1349196417.650.115.camel@zakaz.uk.xensource.com> Cc: "xen-users@lists.xen.org" , Ian Jackson , Giorgio Mossa , xen-devel Subject: Re: [Xen-devel] libutil.h moved to bsd/libutil.h (Was: Re: [Xen-users] Problem compiling Xen 4.2 from sources) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 02/10/12 18:46, Ian Campbell wrote: > (Adding some CCs) > On Tue, 2012-10-02 at 17:31 +0100, Giorgio Mossa wrote: >> Hello everyone, >> I'm working on an Ubuntu 12.04 and I wanted to test >> Xen 4.2 (official repository offer just version 4.1), >> so I've downloaded the source tarball from the site, >> followed the instruction in the readme but when compiling >> I'm getting the following error: >> >> In file included from libxl_bootloader.c:21:0: >> /usr/include/libutil.h:33:2: error: #warning "Deprecated header, use or libbsd-overlay.pc instead." [-Werror=cpp] >> cc1: all warnings being treated as errors >> make[3]: *** [libxl_bootloader.o] Error 1 >> >> could anyone explain how to solve this problem, without disabling the warning/errors compilation options? > > Looks like someone has decided to move this header from /usr/include > to /usr/include/bsd and leave behind a #warning in the old location, > which has broken the way we do things. > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640895 seems to relate > to the fallout from this. > > I'm not sure when the include of libutil is needed, it's not mentioned > in the Linux man pages and on Linux neither of the functions we purport > to need from it are actually present. Perhaps it's a BSD only thing? > > Probably we need to check for bsd/libutil.h in preference to libutil.h > although the resolution of #640895 suggests that what we do now is > correct now that the bug is fixed, in which case a bug against Ubuntu > would be appropriate. > > Ian, Royer, What do you guys think? According to the man pages is only needed on BSDs to be able to use openpty et al. Linux should not have this file, could you please try the following patch? It should prevent configure (and thus libxl) from including the bogus libutil.h header. --- >From 250c0d533bab3c9705ade8e4bffed54abcb53b1c Mon Sep 17 00:00:00 2001 From: Roger Pau Monne Date: Wed, 3 Oct 2012 10:22:21 +0200 Subject: [PATCH] autoconf: add -Werror to libutil.h header check libutil.h is only needed on BSDs, but not in Linux. Debian package libbsd-dev-0.3.0-1 installed a libutil.h overlay that contains a #warning, thus making libxl compilation broken due to -Werror. Perform the libutil.h check with -Werror, so we don't include this bogus header. Signed-off-by: Roger Pau Monne --- Please rerun autoconf after applying this patch --- tools/m4/ptyfuncs.m4 | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/tools/m4/ptyfuncs.m4 b/tools/m4/ptyfuncs.m4 index bfea3e1..3e37b5a 100644 --- a/tools/m4/ptyfuncs.m4 +++ b/tools/m4/ptyfuncs.m4 @@ -1,7 +1,14 @@ AC_DEFUN([AX_CHECK_PTYFUNCS], [ + dnl This is a workaround for a bug in Debian package + dnl libbsd-dev-0.3.0-1. Once we no longer support that + dnl package we can remove the addition of -Werror to + dnl CPPFLAGS. + AX_SAVEVAR_SAVE(CPPFLAGS) + CPPFLAGS="$CPPFLAGS -Werror" AC_CHECK_HEADER([libutil.h],[ AC_DEFINE([INCLUDE_LIBUTIL_H],[],[libutil header file name]) ]) + AX_SAVEVAR_RESTORE(CPPFLAGS) AC_CACHE_CHECK([for openpty et al], [ax_cv_ptyfuncs_libs], [ for ax_cv_ptyfuncs_libs in -lutil "" NOT_FOUND; do if test "x$ax_cv_ptyfuncs_libs" = "xNOT_FOUND"; then -- 1.7.7.5 (Apple Git-26) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 08:32:27 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 08:32:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJKN7-0002nA-Vl; Wed, 03 Oct 2012 08:32:01 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJKN6-0002n0-4O for xen-devel@lists.xen.org; Wed, 03 Oct 2012 08:32:00 +0000 Received: from [85.158.139.211:29876] by server-4.bemta-5.messagelabs.com id 28/37-20767-FF7FB605; Wed, 03 Oct 2012 08:31:59 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-15.tower-206.messagelabs.com!1349253118!20923156!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI5OTg=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14822 invoked from network); 3 Oct 2012 08:31:58 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 08:31:58 -0000 X-IronPort-AV: E=Sophos;i="4.80,527,1344211200"; d="scan'208";a="14908657" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 08:31:58 +0000 Received: from [192.168.1.140] (10.31.3.235) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 09:31:58 +0100 Message-ID: <506BF7FD.4000707@citrix.com> Date: Wed, 3 Oct 2012 10:31:57 +0200 From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Ian Campbell References: <20121002163136.GA5378@intersect> <1349196417.650.115.camel@zakaz.uk.xensource.com> In-Reply-To: <1349196417.650.115.camel@zakaz.uk.xensource.com> Cc: "xen-users@lists.xen.org" , Ian Jackson , Giorgio Mossa , xen-devel Subject: Re: [Xen-devel] libutil.h moved to bsd/libutil.h (Was: Re: [Xen-users] Problem compiling Xen 4.2 from sources) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 02/10/12 18:46, Ian Campbell wrote: > (Adding some CCs) > On Tue, 2012-10-02 at 17:31 +0100, Giorgio Mossa wrote: >> Hello everyone, >> I'm working on an Ubuntu 12.04 and I wanted to test >> Xen 4.2 (official repository offer just version 4.1), >> so I've downloaded the source tarball from the site, >> followed the instruction in the readme but when compiling >> I'm getting the following error: >> >> In file included from libxl_bootloader.c:21:0: >> /usr/include/libutil.h:33:2: error: #warning "Deprecated header, use or libbsd-overlay.pc instead." [-Werror=cpp] >> cc1: all warnings being treated as errors >> make[3]: *** [libxl_bootloader.o] Error 1 >> >> could anyone explain how to solve this problem, without disabling the warning/errors compilation options? > > Looks like someone has decided to move this header from /usr/include > to /usr/include/bsd and leave behind a #warning in the old location, > which has broken the way we do things. > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640895 seems to relate > to the fallout from this. > > I'm not sure when the include of libutil is needed, it's not mentioned > in the Linux man pages and on Linux neither of the functions we purport > to need from it are actually present. Perhaps it's a BSD only thing? > > Probably we need to check for bsd/libutil.h in preference to libutil.h > although the resolution of #640895 suggests that what we do now is > correct now that the bug is fixed, in which case a bug against Ubuntu > would be appropriate. > > Ian, Royer, What do you guys think? According to the man pages is only needed on BSDs to be able to use openpty et al. Linux should not have this file, could you please try the following patch? It should prevent configure (and thus libxl) from including the bogus libutil.h header. --- >From 250c0d533bab3c9705ade8e4bffed54abcb53b1c Mon Sep 17 00:00:00 2001 From: Roger Pau Monne Date: Wed, 3 Oct 2012 10:22:21 +0200 Subject: [PATCH] autoconf: add -Werror to libutil.h header check libutil.h is only needed on BSDs, but not in Linux. Debian package libbsd-dev-0.3.0-1 installed a libutil.h overlay that contains a #warning, thus making libxl compilation broken due to -Werror. Perform the libutil.h check with -Werror, so we don't include this bogus header. Signed-off-by: Roger Pau Monne --- Please rerun autoconf after applying this patch --- tools/m4/ptyfuncs.m4 | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/tools/m4/ptyfuncs.m4 b/tools/m4/ptyfuncs.m4 index bfea3e1..3e37b5a 100644 --- a/tools/m4/ptyfuncs.m4 +++ b/tools/m4/ptyfuncs.m4 @@ -1,7 +1,14 @@ AC_DEFUN([AX_CHECK_PTYFUNCS], [ + dnl This is a workaround for a bug in Debian package + dnl libbsd-dev-0.3.0-1. Once we no longer support that + dnl package we can remove the addition of -Werror to + dnl CPPFLAGS. + AX_SAVEVAR_SAVE(CPPFLAGS) + CPPFLAGS="$CPPFLAGS -Werror" AC_CHECK_HEADER([libutil.h],[ AC_DEFINE([INCLUDE_LIBUTIL_H],[],[libutil header file name]) ]) + AX_SAVEVAR_RESTORE(CPPFLAGS) AC_CACHE_CHECK([for openpty et al], [ax_cv_ptyfuncs_libs], [ for ax_cv_ptyfuncs_libs in -lutil "" NOT_FOUND; do if test "x$ax_cv_ptyfuncs_libs" = "xNOT_FOUND"; then -- 1.7.7.5 (Apple Git-26) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 09:04:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 09:04:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJKrh-0003Pa-K5; Wed, 03 Oct 2012 09:03:37 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJKrf-0003PV-9I for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 09:03:35 +0000 Received: from [85.158.143.99:15295] by server-3.bemta-4.messagelabs.com id CA/68-10986-66FFB605; Wed, 03 Oct 2012 09:03:34 +0000 X-Env-Sender: linux@eikelenboom.it X-Msg-Ref: server-6.tower-216.messagelabs.com!1349255013!25663778!1 X-Originating-IP: [188.40.164.121] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5620 invoked from network); 3 Oct 2012 09:03:33 -0000 Received: from static.121.164.40.188.clients.your-server.de (HELO smtp.eikelenboom.it) (188.40.164.121) by server-6.tower-216.messagelabs.com with AES256-SHA encrypted SMTP; 3 Oct 2012 09:03:33 -0000 Received: from 100-66-ftth.onsneteindhoven.nl ([88.159.66.100]:50752 helo=[172.16.1.20]) by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TJKsj-00042H-4J; Wed, 03 Oct 2012 11:04:41 +0200 Date: Wed, 3 Oct 2012 11:03:30 +0200 From: Sander Eikelenboom Organization: Eikelenboom IT services X-Priority: 3 (Normal) Message-ID: <205569501.20121003110330@eikelenboom.it> To: Ian Campbell In-Reply-To: <1349186538.650.69.camel@zakaz.uk.xensource.com> References: <1348565712.3452.141.camel@zakaz.uk.xensource.com> <15210025463.20120925171143@eikelenboom.it> <1348586949.12592.10.camel@zakaz.uk.xensource.com> <158082007.20120927221137@eikelenboom.it> <1349186538.650.69.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Ian Jackson Subject: Re: [Xen-devel] [PATCH 0 of 3] xl and hotplug: Introduce and use shutdown and reboot xm compatibility options X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org DQpUdWVzZGF5LCBPY3RvYmVyIDIsIDIwMTIsIDQ6MDI6MTggUE0sIHlvdSB3cm90ZToKCj4gT24g VGh1LCAyMDEyLTA5LTI3IGF0IDIxOjExICswMTAwLCBTYW5kZXIgRWlrZWxlbmJvb20gd3JvdGU6 Cj4+IFR1ZXNkYXksIFNlcHRlbWJlciAyNSwgMjAxMiwgNToyOTowOSBQTSwgeW91IHdyb3RlOgo+ PiAKPj4gPiBPbiBUdWUsIDIwMTItMDktMjUgYXQgMTY6MTEgKzAxMDAsIFNhbmRlciBFaWtlbGVu Ym9vbSB3cm90ZToKPj4gCj4+ID4+IFRoZSBvbmx5IHJlbGF0aXZlIHNpbXBsZSBpbXBsZW1lbnRh dGlvbiBpIHRob3VnaHQgb2Ygd2FzIGRpcmVjdAo+PiA+PiBzaHV0dGluZyBkb3duIGFsbCwgYW5k IHdoZW4gdGhlIC13IHBhcmFtZXRlciB3YXMgc2V0LCBqdXN0IGxvb3AgYW5kCj4+ID4+IHdhaXQg b24gZXZlbnRzIHVudGlsIHRoZSBvbmx5IHJ1bm5pbmcgZG9tYWluIGlzIGRvbWFpbi0wLgo+PiA+ PiBBbHRob3VnaCB0aGlzIGV4YWN0bHkgZG9lcyB3aGF0IGhhcyB0byBiZSBkb25lLCBpdCBzb21l aG93IHNvdW5kcyBhCj4+ID4+IGJpdCBkaXJ0eS4KPj4gCj4+ID4gSSB0aGluayB5b3UgY2FuIGFs bG9jYXRlIGFuIGFycmF5IG9mIGxpYnhsX2V2ZW5hYmxlX2RvbWFpbl9kZWF0aCosIG9mCj4+ID4g bnJfZG9tcyBpbiBzaXplIGFuZCB0aGVuIGFzIHlvdSBzaHV0ZG93biBlYWNoIGRvbWFpbiBjYWxs Cj4+ID4gbGlieGxfZXZlbmFibGVfZG9tYWluX2RlYXRoIGZvciBpdCB0b28uCj4+IAo+PiA+IFRo ZW4geW91IGxvb3Agd2FpdGluZyBmb3IgZGVzdHJveSBldmVudHMsIGNhbGxpbmcKPj4gPiBsaWJ4 bF9ldmRpc2FibGVfZG9tYWluX2RlYXRoIGFzIGVhY2ggZG9tYWluIGRpZXMsIHdoaWxlIGNvdW50 aW5nIGJhY2sKPj4gPiBmcm9tIG5yX2RvbXMgdW50aWwgMC4gV2hlbiBpdCByZWFjaGVzIDAgZXZl cnl0aGluZyB5b3UgYXNrZWQgZm9yIGhhcwo+PiA+IGJlZW4gc2h1dGRvd24uCj4+IAo+PiA+IE9y IHNvbWV0aGluZyBsaWtlIHRoYXQsIEkndmUgbm90IGFjdHVhbGx5IGltcGxlbWVudGVkIGl0IDst KQo+PiAKPj4gPiBJYW4uCj4+IAo+PiBJdCdzIHRpbWUgdG8gY2FsbCBkZWZlYXQsIHdpdGhvdXQg cHJvcGVyIEMgc2tpbGxzIGl0IHNlZW1zIGEgYml0IHRvbwo+PiBoYXJkIHRvIGZpZ3VyZSBpdCBv dXQuCgo+IFRoYXQncyBvaywgSSdsbCBhZGQgaXQgdG8gbXkgVE9ETyB0byBwaWNrdXAgd2hlcmUg eW91IGxlZnQgb2ZmICh1bmxlc3MKPiBzb21lb25lIGJlYXRzIG1lIHRvIGl0KS4KClRoeCAhCldv dWxkIGJlIG5pY2UgZm9yIDQuMi4xIHNpbmNlIHRoZSB4ZW5kb21haW5zIHN0b3Agc2NyaXB0IGRv ZXNuJ3QgZnVuY3Rpb24gcHJvcGVybHkgd2l0aCB4bCBhcyB0b29sc3RhY2ssIGFuZCBub3Qgc2h1 dHRpbmcgZG93biB0aGUgZG9tYWlucyBidXQganVzdCBwdWxscyB0aGUgcGx1Zy4KV291bGQgaXQg YmUgaGVscGZ1bCB0byB5b3UsIHRvIHNlbmQgdGhlIGRvYyBwYXRjaGVzIGFzIHdlbGwgPwoKCj4g VGhhbmtzIGZvciB0YWtpbmcgaXQgdGhpcyBmYXIhIEZXSVcgeW91IHNlZW1lZCB0byBiZSBwcmV0 dHkgY2xvc2UuCgo+PiBDYW4ndCBzZWVtIHRvIGdldCB0aGUgaGFuZyBvZiBob3cgdG8ga2VlcCBh IHJlZmVyZW5jZSB0bwo+PiBsaWJ4bF9ldmdlbl9kb21haW5fZGVhdGggYW5kIHVzZSBpdCB0byBj aGVjayBpZiB0aGUgZG9taWQgb2YgdGhlIGV2ZW50Cj4+IGlzIHRoZSBzYW1lIGFzIHRoYXQgZnJv bSBhIGRvbWFpbiB3ZSBhcmUgd2FpdGluZyB0byBzaHV0ZG93bi4KPj4gVGhlIHJlc3Qgb2YgdGhl IGNvZGUgZG9lc24ndCBnaXZlIG1lIG11Y2ggcG9pbnRlcnMgc2luY2UgYWxsIGNvbW1hbmRzCj4+ IHNlZW0gdG8gb3BlcmF0ZSBvbiBhIHNpbmdsZSBkb21pZCBhdCBvbmNlLgo+PiAKPj4gVGhlIGNv bmNvY3Rpb24gYmVsb3cgbGVhZHMgdG86Cj4+IHhsX2NtZGltcGwuYzogSW4gZnVuY3Rpb24gw6Jz aHV0ZG93bl9kb21haW7DojoKPj4geGxfY21kaW1wbC5jOjI3NjY6IGVycm9yOiBkZXJlZmVyZW5j aW5nIHBvaW50ZXIgdG8gaW5jb21wbGV0ZSB0eXBlCgo+IEluIGNhc2UgeW91IGFyZSBpbnRlcmVz dGVkIHRoaXMgaXMgYmVjYXVzZSB0aGUgbGlieGxfZXZnZW5fZG9tYWluX2RlYXRoCj4gdHlwZSBp cyBvcGFxdWUgdG8gdXNlcnMgb2YgbGlieGwgc28gY29uc3RydWN0cyBsaWtlCj4gZG9tYWluc193 YWl0X3NodXRkb3duW2ldLT5kb21pZCBhcmUgbm90IHBvc3NpYmxlLgoKPiBUaGUgYW5zd2VyIGlz IHRvIHVzZSB0aGUgM3JkIGFyZ3VtZW50IHRvIGxpYnhsX2V2ZW5hYmxlX2RvbWFpbl9kZWF0aAo+ ICh0aGUgb25lIG9mIHR5cGUgbGlieGxfZXZfdXNlcikgdG8gcGFzcyBhICJjbG9zdXJlIiwgdGhp cyB2YWx1ZSBpcwo+IHJldHVybmVkIGluIHRoZSBldmVudCdzICJmb3JfdXNlciIgZmllbGQuIFRo ZSBhcHBsaWNhdGlvbiBjYW4gdXNlIHRoaXMKPiB0byBzdG9yZSBkYXRhIHNwZWNpZmljIHRvIHRo aXMgcGFydGljdWxhciBldmVudCAtLSBpbiB0aGlzIGNhc2UgaXQgd291bGQKPiBwcm9iYWJseSBi ZSBzdWZmaWNpZW50IHRvIGp1c3QgcGFzcyB0aGUgZG9taWQgaGVyZSBidXQgaW4gcHJpbmNpcGFs IG9uZQo+IGNvdWxkIHBhc3MgYSBwb2ludGVyIHRvIGFueSBkYXRhc3RydWN0dXJlLgoKVGhhbmtz IGZvciB0aGUgZXhwbGFuYXRpb24sIGFsdGhvdWdoIGkgc3RpbGwgZG9uJ3Qgc2VlIGhvdyB0byBh Y3R1YWxseSBjaGFuZ2UgdGhlIGNvZGUgdGhlIHJpZ2h0IHdheS4KCgo+IFRoYW5rcyBhZ2FpbiwK PiBJYW4uCgoKCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDov L2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg== From xen-devel-bounces@lists.xen.org Wed Oct 03 09:04:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 09:04:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJKrh-0003Pa-K5; Wed, 03 Oct 2012 09:03:37 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJKrf-0003PV-9I for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 09:03:35 +0000 Received: from [85.158.143.99:15295] by server-3.bemta-4.messagelabs.com id CA/68-10986-66FFB605; Wed, 03 Oct 2012 09:03:34 +0000 X-Env-Sender: linux@eikelenboom.it X-Msg-Ref: server-6.tower-216.messagelabs.com!1349255013!25663778!1 X-Originating-IP: [188.40.164.121] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5620 invoked from network); 3 Oct 2012 09:03:33 -0000 Received: from static.121.164.40.188.clients.your-server.de (HELO smtp.eikelenboom.it) (188.40.164.121) by server-6.tower-216.messagelabs.com with AES256-SHA encrypted SMTP; 3 Oct 2012 09:03:33 -0000 Received: from 100-66-ftth.onsneteindhoven.nl ([88.159.66.100]:50752 helo=[172.16.1.20]) by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TJKsj-00042H-4J; Wed, 03 Oct 2012 11:04:41 +0200 Date: Wed, 3 Oct 2012 11:03:30 +0200 From: Sander Eikelenboom Organization: Eikelenboom IT services X-Priority: 3 (Normal) Message-ID: <205569501.20121003110330@eikelenboom.it> To: Ian Campbell In-Reply-To: <1349186538.650.69.camel@zakaz.uk.xensource.com> References: <1348565712.3452.141.camel@zakaz.uk.xensource.com> <15210025463.20120925171143@eikelenboom.it> <1348586949.12592.10.camel@zakaz.uk.xensource.com> <158082007.20120927221137@eikelenboom.it> <1349186538.650.69.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Ian Jackson Subject: Re: [Xen-devel] [PATCH 0 of 3] xl and hotplug: Introduce and use shutdown and reboot xm compatibility options X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org DQpUdWVzZGF5LCBPY3RvYmVyIDIsIDIwMTIsIDQ6MDI6MTggUE0sIHlvdSB3cm90ZToKCj4gT24g VGh1LCAyMDEyLTA5LTI3IGF0IDIxOjExICswMTAwLCBTYW5kZXIgRWlrZWxlbmJvb20gd3JvdGU6 Cj4+IFR1ZXNkYXksIFNlcHRlbWJlciAyNSwgMjAxMiwgNToyOTowOSBQTSwgeW91IHdyb3RlOgo+ PiAKPj4gPiBPbiBUdWUsIDIwMTItMDktMjUgYXQgMTY6MTEgKzAxMDAsIFNhbmRlciBFaWtlbGVu Ym9vbSB3cm90ZToKPj4gCj4+ID4+IFRoZSBvbmx5IHJlbGF0aXZlIHNpbXBsZSBpbXBsZW1lbnRh dGlvbiBpIHRob3VnaHQgb2Ygd2FzIGRpcmVjdAo+PiA+PiBzaHV0dGluZyBkb3duIGFsbCwgYW5k IHdoZW4gdGhlIC13IHBhcmFtZXRlciB3YXMgc2V0LCBqdXN0IGxvb3AgYW5kCj4+ID4+IHdhaXQg b24gZXZlbnRzIHVudGlsIHRoZSBvbmx5IHJ1bm5pbmcgZG9tYWluIGlzIGRvbWFpbi0wLgo+PiA+ PiBBbHRob3VnaCB0aGlzIGV4YWN0bHkgZG9lcyB3aGF0IGhhcyB0byBiZSBkb25lLCBpdCBzb21l aG93IHNvdW5kcyBhCj4+ID4+IGJpdCBkaXJ0eS4KPj4gCj4+ID4gSSB0aGluayB5b3UgY2FuIGFs bG9jYXRlIGFuIGFycmF5IG9mIGxpYnhsX2V2ZW5hYmxlX2RvbWFpbl9kZWF0aCosIG9mCj4+ID4g bnJfZG9tcyBpbiBzaXplIGFuZCB0aGVuIGFzIHlvdSBzaHV0ZG93biBlYWNoIGRvbWFpbiBjYWxs Cj4+ID4gbGlieGxfZXZlbmFibGVfZG9tYWluX2RlYXRoIGZvciBpdCB0b28uCj4+IAo+PiA+IFRo ZW4geW91IGxvb3Agd2FpdGluZyBmb3IgZGVzdHJveSBldmVudHMsIGNhbGxpbmcKPj4gPiBsaWJ4 bF9ldmRpc2FibGVfZG9tYWluX2RlYXRoIGFzIGVhY2ggZG9tYWluIGRpZXMsIHdoaWxlIGNvdW50 aW5nIGJhY2sKPj4gPiBmcm9tIG5yX2RvbXMgdW50aWwgMC4gV2hlbiBpdCByZWFjaGVzIDAgZXZl cnl0aGluZyB5b3UgYXNrZWQgZm9yIGhhcwo+PiA+IGJlZW4gc2h1dGRvd24uCj4+IAo+PiA+IE9y IHNvbWV0aGluZyBsaWtlIHRoYXQsIEkndmUgbm90IGFjdHVhbGx5IGltcGxlbWVudGVkIGl0IDst KQo+PiAKPj4gPiBJYW4uCj4+IAo+PiBJdCdzIHRpbWUgdG8gY2FsbCBkZWZlYXQsIHdpdGhvdXQg cHJvcGVyIEMgc2tpbGxzIGl0IHNlZW1zIGEgYml0IHRvbwo+PiBoYXJkIHRvIGZpZ3VyZSBpdCBv dXQuCgo+IFRoYXQncyBvaywgSSdsbCBhZGQgaXQgdG8gbXkgVE9ETyB0byBwaWNrdXAgd2hlcmUg eW91IGxlZnQgb2ZmICh1bmxlc3MKPiBzb21lb25lIGJlYXRzIG1lIHRvIGl0KS4KClRoeCAhCldv dWxkIGJlIG5pY2UgZm9yIDQuMi4xIHNpbmNlIHRoZSB4ZW5kb21haW5zIHN0b3Agc2NyaXB0IGRv ZXNuJ3QgZnVuY3Rpb24gcHJvcGVybHkgd2l0aCB4bCBhcyB0b29sc3RhY2ssIGFuZCBub3Qgc2h1 dHRpbmcgZG93biB0aGUgZG9tYWlucyBidXQganVzdCBwdWxscyB0aGUgcGx1Zy4KV291bGQgaXQg YmUgaGVscGZ1bCB0byB5b3UsIHRvIHNlbmQgdGhlIGRvYyBwYXRjaGVzIGFzIHdlbGwgPwoKCj4g VGhhbmtzIGZvciB0YWtpbmcgaXQgdGhpcyBmYXIhIEZXSVcgeW91IHNlZW1lZCB0byBiZSBwcmV0 dHkgY2xvc2UuCgo+PiBDYW4ndCBzZWVtIHRvIGdldCB0aGUgaGFuZyBvZiBob3cgdG8ga2VlcCBh IHJlZmVyZW5jZSB0bwo+PiBsaWJ4bF9ldmdlbl9kb21haW5fZGVhdGggYW5kIHVzZSBpdCB0byBj aGVjayBpZiB0aGUgZG9taWQgb2YgdGhlIGV2ZW50Cj4+IGlzIHRoZSBzYW1lIGFzIHRoYXQgZnJv bSBhIGRvbWFpbiB3ZSBhcmUgd2FpdGluZyB0byBzaHV0ZG93bi4KPj4gVGhlIHJlc3Qgb2YgdGhl IGNvZGUgZG9lc24ndCBnaXZlIG1lIG11Y2ggcG9pbnRlcnMgc2luY2UgYWxsIGNvbW1hbmRzCj4+ IHNlZW0gdG8gb3BlcmF0ZSBvbiBhIHNpbmdsZSBkb21pZCBhdCBvbmNlLgo+PiAKPj4gVGhlIGNv bmNvY3Rpb24gYmVsb3cgbGVhZHMgdG86Cj4+IHhsX2NtZGltcGwuYzogSW4gZnVuY3Rpb24gw6Jz aHV0ZG93bl9kb21haW7DojoKPj4geGxfY21kaW1wbC5jOjI3NjY6IGVycm9yOiBkZXJlZmVyZW5j aW5nIHBvaW50ZXIgdG8gaW5jb21wbGV0ZSB0eXBlCgo+IEluIGNhc2UgeW91IGFyZSBpbnRlcmVz dGVkIHRoaXMgaXMgYmVjYXVzZSB0aGUgbGlieGxfZXZnZW5fZG9tYWluX2RlYXRoCj4gdHlwZSBp cyBvcGFxdWUgdG8gdXNlcnMgb2YgbGlieGwgc28gY29uc3RydWN0cyBsaWtlCj4gZG9tYWluc193 YWl0X3NodXRkb3duW2ldLT5kb21pZCBhcmUgbm90IHBvc3NpYmxlLgoKPiBUaGUgYW5zd2VyIGlz IHRvIHVzZSB0aGUgM3JkIGFyZ3VtZW50IHRvIGxpYnhsX2V2ZW5hYmxlX2RvbWFpbl9kZWF0aAo+ ICh0aGUgb25lIG9mIHR5cGUgbGlieGxfZXZfdXNlcikgdG8gcGFzcyBhICJjbG9zdXJlIiwgdGhp cyB2YWx1ZSBpcwo+IHJldHVybmVkIGluIHRoZSBldmVudCdzICJmb3JfdXNlciIgZmllbGQuIFRo ZSBhcHBsaWNhdGlvbiBjYW4gdXNlIHRoaXMKPiB0byBzdG9yZSBkYXRhIHNwZWNpZmljIHRvIHRo aXMgcGFydGljdWxhciBldmVudCAtLSBpbiB0aGlzIGNhc2UgaXQgd291bGQKPiBwcm9iYWJseSBi ZSBzdWZmaWNpZW50IHRvIGp1c3QgcGFzcyB0aGUgZG9taWQgaGVyZSBidXQgaW4gcHJpbmNpcGFs IG9uZQo+IGNvdWxkIHBhc3MgYSBwb2ludGVyIHRvIGFueSBkYXRhc3RydWN0dXJlLgoKVGhhbmtz IGZvciB0aGUgZXhwbGFuYXRpb24sIGFsdGhvdWdoIGkgc3RpbGwgZG9uJ3Qgc2VlIGhvdyB0byBh Y3R1YWxseSBjaGFuZ2UgdGhlIGNvZGUgdGhlIHJpZ2h0IHdheS4KCgo+IFRoYW5rcyBhZ2FpbiwK PiBJYW4uCgoKCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDov L2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg== From xen-devel-bounces@lists.xen.org Wed Oct 03 09:17:27 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 09:17:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJL4h-0003dd-3K; Wed, 03 Oct 2012 09:17:03 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJL4f-0003dY-1P for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 09:17:01 +0000 Received: from [85.158.139.83:10212] by server-14.bemta-5.messagelabs.com id 7F/BA-05772-C820C605; Wed, 03 Oct 2012 09:17:00 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1349255818!32526348!1 X-Originating-IP: [209.85.160.173] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9440 invoked from network); 3 Oct 2012 09:16:59 -0000 Received: from mail-gh0-f173.google.com (HELO mail-gh0-f173.google.com) (209.85.160.173) by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 09:16:59 -0000 Received: by ghy16 with SMTP id 16so2171877ghy.32 for ; Wed, 03 Oct 2012 02:16:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=JLH0rKLJ1jvD+S+8Fg3c3Et69wk4e9XWcXZGNfkN60Y=; b=W+LSDeGWK2S5AfdrxYWJzO1+HZT42yyuAxT70gTQzi206iCYZ1OetUOhbWxII+oscM E/fOY8Hd5Fcvzs5cQgHtngDIZFL/YC7DwvUtUuVHpGzKePETp4Wnm6AfkMXubnJHhi+W vhoMt5r1feo7wOMOgiCBEpAOeOiDEoprBr4a3SgiLCpNuVPi1EZ70/5rZFuANQTp37mt NCW7QKW860u6RzbOQxiiPYzianEtGSW/5avjqpanlQ/DSeC8TDXj9eWNmNmBQp3RgW61 Us2ISTi51y4VPXqgnQ/58MIxfwt2hcgWtt872KuORKVWM/VYboKnNv+xLJ+rEBSjMupP NKag== MIME-Version: 1.0 Received: by 10.236.137.208 with SMTP id y56mr1237248yhi.58.1349255818262; Wed, 03 Oct 2012 02:16:58 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Wed, 3 Oct 2012 02:16:58 -0700 (PDT) Date: Wed, 3 Oct 2012 12:16:58 +0300 Message-ID: From: Valtteri Kiviniemi To: Xen-devel@lists.xen.org Subject: [Xen-devel] xlu_cfg_get_defbool error when trying to start domU X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5262262862353490702==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============5262262862353490702== Content-Type: multipart/alternative; boundary=20cf303a2eb5c2392104cb241998 --20cf303a2eb5c2392104cb241998 Content-Type: text/plain; charset=ISO-8859-1 Hi, I just upgraded from Xen 4.0.4 to Xen 4.2.0. When I'm trying to start domU using the new xl toolstack I get the following error message: Parsing config from /etc/xen/domu1.cfg xl: symbol lookup error: xl: undefined symbol: xlu_cfg_get_defbool When lauching xend and using xm create the domU starts up normally. - Valtteri --20cf303a2eb5c2392104cb241998 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I just upgraded from Xen 4.0.4 to Xen 4.2.0. When I'm trying= to start domU using the new xl toolstack I get the following error message= :

Parsing config from /etc/xen/domu1.cfg
xl: symbol lookup error:= xl: undefined symbol: xlu_cfg_get_defbool

When lauching xend and using xm create the domU starts up normally.
=
- Valtteri

--20cf303a2eb5c2392104cb241998-- --===============5262262862353490702== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============5262262862353490702==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 09:17:27 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 09:17:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJL4h-0003dd-3K; Wed, 03 Oct 2012 09:17:03 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJL4f-0003dY-1P for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 09:17:01 +0000 Received: from [85.158.139.83:10212] by server-14.bemta-5.messagelabs.com id 7F/BA-05772-C820C605; Wed, 03 Oct 2012 09:17:00 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1349255818!32526348!1 X-Originating-IP: [209.85.160.173] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9440 invoked from network); 3 Oct 2012 09:16:59 -0000 Received: from mail-gh0-f173.google.com (HELO mail-gh0-f173.google.com) (209.85.160.173) by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 09:16:59 -0000 Received: by ghy16 with SMTP id 16so2171877ghy.32 for ; Wed, 03 Oct 2012 02:16:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=JLH0rKLJ1jvD+S+8Fg3c3Et69wk4e9XWcXZGNfkN60Y=; b=W+LSDeGWK2S5AfdrxYWJzO1+HZT42yyuAxT70gTQzi206iCYZ1OetUOhbWxII+oscM E/fOY8Hd5Fcvzs5cQgHtngDIZFL/YC7DwvUtUuVHpGzKePETp4Wnm6AfkMXubnJHhi+W vhoMt5r1feo7wOMOgiCBEpAOeOiDEoprBr4a3SgiLCpNuVPi1EZ70/5rZFuANQTp37mt NCW7QKW860u6RzbOQxiiPYzianEtGSW/5avjqpanlQ/DSeC8TDXj9eWNmNmBQp3RgW61 Us2ISTi51y4VPXqgnQ/58MIxfwt2hcgWtt872KuORKVWM/VYboKnNv+xLJ+rEBSjMupP NKag== MIME-Version: 1.0 Received: by 10.236.137.208 with SMTP id y56mr1237248yhi.58.1349255818262; Wed, 03 Oct 2012 02:16:58 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Wed, 3 Oct 2012 02:16:58 -0700 (PDT) Date: Wed, 3 Oct 2012 12:16:58 +0300 Message-ID: From: Valtteri Kiviniemi To: Xen-devel@lists.xen.org Subject: [Xen-devel] xlu_cfg_get_defbool error when trying to start domU X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5262262862353490702==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============5262262862353490702== Content-Type: multipart/alternative; boundary=20cf303a2eb5c2392104cb241998 --20cf303a2eb5c2392104cb241998 Content-Type: text/plain; charset=ISO-8859-1 Hi, I just upgraded from Xen 4.0.4 to Xen 4.2.0. When I'm trying to start domU using the new xl toolstack I get the following error message: Parsing config from /etc/xen/domu1.cfg xl: symbol lookup error: xl: undefined symbol: xlu_cfg_get_defbool When lauching xend and using xm create the domU starts up normally. - Valtteri --20cf303a2eb5c2392104cb241998 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I just upgraded from Xen 4.0.4 to Xen 4.2.0. When I'm trying= to start domU using the new xl toolstack I get the following error message= :

Parsing config from /etc/xen/domu1.cfg
xl: symbol lookup error:= xl: undefined symbol: xlu_cfg_get_defbool

When lauching xend and using xm create the domU starts up normally.
=
- Valtteri

--20cf303a2eb5c2392104cb241998-- --===============5262262862353490702== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============5262262862353490702==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 09:22:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 09:22:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJL9M-0003lZ-Qa; Wed, 03 Oct 2012 09:21:52 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJL9L-0003lR-6U for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 09:21:51 +0000 Received: from [85.158.138.51:11232] by server-1.bemta-3.messagelabs.com id E8/0F-16425-EA30C605; Wed, 03 Oct 2012 09:21:50 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1349256108!24023834!1 X-Originating-IP: [209.85.161.173] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1201 invoked from network); 3 Oct 2012 09:21:49 -0000 Received: from mail-gg0-f173.google.com (HELO mail-gg0-f173.google.com) (209.85.161.173) by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 09:21:49 -0000 Received: by ggcs5 with SMTP id s5so587615ggc.32 for ; Wed, 03 Oct 2012 02:21:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4cQ+VSidvTahLc5gxhnUxKmlRHeubl6f/zTxIMky414=; b=Q6gy2LCKTnGxfjmXyz2Efj3LTXIMBA1+fGd95tYqV44So2TqBZ03J9+Em/NP6YkSNj +WbidM7Qc6sPR9R/KUn1FKh5uQbcLcVHZF0zSeHgUY42akKH/zmsSGiKDJu9rfUwtpeT sMD9G+qi9nBEBuiOw77hL0m+evw/hXb68H2idmAHA2a2ucSvKbA7UzWG0+DScCS79zJL s8XsoLTO4wOLlDTAy+/FgFluJTwm7bXKK9auSey9SdjBjqMCGLAOLpM13AMoZYSXIpd/ atl2ukrK1lGwwPtEEKwJxVMFmMWodeiiUyoVVsIGoZDOlLa8CLGNJEF9p9I5ytgQMHej 8MKA== MIME-Version: 1.0 Received: by 10.236.155.71 with SMTP id i47mr1261744yhk.72.1349256107764; Wed, 03 Oct 2012 02:21:47 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Wed, 3 Oct 2012 02:21:47 -0700 (PDT) In-Reply-To: References: <20121001164757.GF8912@reaktio.net> <20121001182437.GG8912@reaktio.net> <20121002121932.GL8912@reaktio.net> <20121002144251.GP8912@reaktio.net> Date: Wed, 3 Oct 2012 12:21:47 +0300 Message-ID: From: Valtteri Kiviniemi To: Konrad Rzeszutek Wilk Cc: Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.0.4, kernel 3.5.0 HVM crash and kernel BUG X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2507127068811690831==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============2507127068811690831== Content-Type: multipart/alternative; boundary=20cf303b426903acd604cb242bab --20cf303b426903acd604cb242bab Content-Type: text/plain; charset=ISO-8859-1 Hi, I disabled NUMA and upgraded to Xen 4.2.0. Windows domU starts now fine and I cant anymore reproduce the hotplug problems. VNC output is still just black screen and it actually crashes the the whole VNC client when after a few seconds. RealVNC just shuts itself down and tightvnc crashes. - Valtteri 2012/10/2 Valtteri Kiviniemi > Hi, > > Yes, they are all loaded and I'm running Linux PV-virtuals at the same > time with no problems. Only HVM is not working. I have single socket corei7 > processor and NUMA enabled on dom0 kernel, so I will try tomorrow to > compile dom0 kernel without NUMA, since its not needed and it could > probably cause some kind of memory related problems. > > I will also try Debian squeezes package Xen and test if it is working with > my hardware. > > - Valtteri > > > 2012/10/2 Konrad Rzeszutek Wilk > >> On Tue, Oct 2, 2012 at 10:55 AM, Valtteri Kiviniemi >> wrote: >> > Hi, >> > >> > Yes, I understood for what the parameters were for. I'ts been a long >> time >> > since I last had major problems with Xen (maybe 3.1 or something, been >> using >> > Xen since version 2) and I had a shady recollection that Xen was >> required to >> > be build debugging enabled in order to get any usable debugging data. >> > >> > But anyway, I cant reproduce that kernel crash everytime, it just >> happens >> > sometimes. Major problem is the black screen on VNC and second problem >> seems >> > to be that everytime i try to run Linux in HVM mode it somehow breaks >> the >> > hotplug scripts. >> > >> >> So do you have all backends loaded? Is xen-netback and xen-blkback >> running? >> Do you also have tun loaded? >> > > --20cf303b426903acd604cb242bab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I disabled NUMA and upgraded to Xen 4.2.0. Windows domU starts n= ow fine and I cant anymore reproduce the hotplug problems. VNC output is st= ill just black screen and it actually crashes the the whole VNC client when= after a few seconds. RealVNC just shuts itself down and tightvnc crashes.<= br>
- Valtteri


2012/10/2 Valtteri Kiv= iniemi <kiviniemi.valtteri@gmail.com>
Hi,

Yes, they are all loaded and I'm running Linux PV-virtuals a= t the same time with no problems. Only HVM is not working. I have single so= cket corei7 processor and NUMA enabled on dom0 kernel, so I will try tomorr= ow to compile dom0 kernel without NUMA, since its not needed and it could p= robably cause some kind of memory related problems.

I will also try Debian squeezes package Xen and test if it is working w= ith my hardware.

- Valtteri


2012/10/2 Konrad Rzeszutek Wilk <konrad@kernel.org>
On Tue, Oct 2, 2012 at 10:55 AM, Valtte= ri Kiviniemi
<kivin= iemi.valtteri@gmail.com> wrote:
> Hi,
>
> Yes, I understood for what the parameters were for. I'ts been a lo= ng time
> since I last had major problems with Xen (maybe 3.1 or something, been= using
> Xen since version 2) and I had a shady recollection that Xen was requi= red to
> be build debugging enabled in order to get any usable debugging data.<= br> >
> But anyway, I cant reproduce that kernel crash everytime, it just happ= ens
> sometimes. Major problem is the black screen on VNC and second problem= seems
> to be that everytime i try to run Linux in HVM mode it somehow breaks = the
> hotplug scripts.
>

So do you have all backends loaded? Is xen-netback and xen-blkback ru= nning?
Do you also have tun loaded?


--20cf303b426903acd604cb242bab-- --===============2507127068811690831== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============2507127068811690831==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 09:22:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 09:22:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJL9M-0003lZ-Qa; Wed, 03 Oct 2012 09:21:52 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJL9L-0003lR-6U for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 09:21:51 +0000 Received: from [85.158.138.51:11232] by server-1.bemta-3.messagelabs.com id E8/0F-16425-EA30C605; Wed, 03 Oct 2012 09:21:50 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1349256108!24023834!1 X-Originating-IP: [209.85.161.173] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1201 invoked from network); 3 Oct 2012 09:21:49 -0000 Received: from mail-gg0-f173.google.com (HELO mail-gg0-f173.google.com) (209.85.161.173) by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 09:21:49 -0000 Received: by ggcs5 with SMTP id s5so587615ggc.32 for ; Wed, 03 Oct 2012 02:21:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4cQ+VSidvTahLc5gxhnUxKmlRHeubl6f/zTxIMky414=; b=Q6gy2LCKTnGxfjmXyz2Efj3LTXIMBA1+fGd95tYqV44So2TqBZ03J9+Em/NP6YkSNj +WbidM7Qc6sPR9R/KUn1FKh5uQbcLcVHZF0zSeHgUY42akKH/zmsSGiKDJu9rfUwtpeT sMD9G+qi9nBEBuiOw77hL0m+evw/hXb68H2idmAHA2a2ucSvKbA7UzWG0+DScCS79zJL s8XsoLTO4wOLlDTAy+/FgFluJTwm7bXKK9auSey9SdjBjqMCGLAOLpM13AMoZYSXIpd/ atl2ukrK1lGwwPtEEKwJxVMFmMWodeiiUyoVVsIGoZDOlLa8CLGNJEF9p9I5ytgQMHej 8MKA== MIME-Version: 1.0 Received: by 10.236.155.71 with SMTP id i47mr1261744yhk.72.1349256107764; Wed, 03 Oct 2012 02:21:47 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Wed, 3 Oct 2012 02:21:47 -0700 (PDT) In-Reply-To: References: <20121001164757.GF8912@reaktio.net> <20121001182437.GG8912@reaktio.net> <20121002121932.GL8912@reaktio.net> <20121002144251.GP8912@reaktio.net> Date: Wed, 3 Oct 2012 12:21:47 +0300 Message-ID: From: Valtteri Kiviniemi To: Konrad Rzeszutek Wilk Cc: Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.0.4, kernel 3.5.0 HVM crash and kernel BUG X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2507127068811690831==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============2507127068811690831== Content-Type: multipart/alternative; boundary=20cf303b426903acd604cb242bab --20cf303b426903acd604cb242bab Content-Type: text/plain; charset=ISO-8859-1 Hi, I disabled NUMA and upgraded to Xen 4.2.0. Windows domU starts now fine and I cant anymore reproduce the hotplug problems. VNC output is still just black screen and it actually crashes the the whole VNC client when after a few seconds. RealVNC just shuts itself down and tightvnc crashes. - Valtteri 2012/10/2 Valtteri Kiviniemi > Hi, > > Yes, they are all loaded and I'm running Linux PV-virtuals at the same > time with no problems. Only HVM is not working. I have single socket corei7 > processor and NUMA enabled on dom0 kernel, so I will try tomorrow to > compile dom0 kernel without NUMA, since its not needed and it could > probably cause some kind of memory related problems. > > I will also try Debian squeezes package Xen and test if it is working with > my hardware. > > - Valtteri > > > 2012/10/2 Konrad Rzeszutek Wilk > >> On Tue, Oct 2, 2012 at 10:55 AM, Valtteri Kiviniemi >> wrote: >> > Hi, >> > >> > Yes, I understood for what the parameters were for. I'ts been a long >> time >> > since I last had major problems with Xen (maybe 3.1 or something, been >> using >> > Xen since version 2) and I had a shady recollection that Xen was >> required to >> > be build debugging enabled in order to get any usable debugging data. >> > >> > But anyway, I cant reproduce that kernel crash everytime, it just >> happens >> > sometimes. Major problem is the black screen on VNC and second problem >> seems >> > to be that everytime i try to run Linux in HVM mode it somehow breaks >> the >> > hotplug scripts. >> > >> >> So do you have all backends loaded? Is xen-netback and xen-blkback >> running? >> Do you also have tun loaded? >> > > --20cf303b426903acd604cb242bab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I disabled NUMA and upgraded to Xen 4.2.0. Windows domU starts n= ow fine and I cant anymore reproduce the hotplug problems. VNC output is st= ill just black screen and it actually crashes the the whole VNC client when= after a few seconds. RealVNC just shuts itself down and tightvnc crashes.<= br>
- Valtteri


2012/10/2 Valtteri Kiv= iniemi <kiviniemi.valtteri@gmail.com>
Hi,

Yes, they are all loaded and I'm running Linux PV-virtuals a= t the same time with no problems. Only HVM is not working. I have single so= cket corei7 processor and NUMA enabled on dom0 kernel, so I will try tomorr= ow to compile dom0 kernel without NUMA, since its not needed and it could p= robably cause some kind of memory related problems.

I will also try Debian squeezes package Xen and test if it is working w= ith my hardware.

- Valtteri


2012/10/2 Konrad Rzeszutek Wilk <konrad@kernel.org>
On Tue, Oct 2, 2012 at 10:55 AM, Valtte= ri Kiviniemi
<kivin= iemi.valtteri@gmail.com> wrote:
> Hi,
>
> Yes, I understood for what the parameters were for. I'ts been a lo= ng time
> since I last had major problems with Xen (maybe 3.1 or something, been= using
> Xen since version 2) and I had a shady recollection that Xen was requi= red to
> be build debugging enabled in order to get any usable debugging data.<= br> >
> But anyway, I cant reproduce that kernel crash everytime, it just happ= ens
> sometimes. Major problem is the black screen on VNC and second problem= seems
> to be that everytime i try to run Linux in HVM mode it somehow breaks = the
> hotplug scripts.
>

So do you have all backends loaded? Is xen-netback and xen-blkback ru= nning?
Do you also have tun loaded?


--20cf303b426903acd604cb242bab-- --===============2507127068811690831== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============2507127068811690831==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 09:30:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 09:30:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJLHQ-0003vx-St; Wed, 03 Oct 2012 09:30:12 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJLHO-0003vs-Sf for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 09:30:10 +0000 Received: from [85.158.139.83:20761] by server-14.bemta-5.messagelabs.com id 96/3A-05772-2A50C605; Wed, 03 Oct 2012 09:30:10 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-2.tower-182.messagelabs.com!1349256608!30350992!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI5OTg=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5435 invoked from network); 3 Oct 2012 09:30:09 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 09:30:09 -0000 X-IronPort-AV: E=Sophos;i="4.80,527,1344211200"; d="scan'208";a="14910205" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 09:30:08 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 10:30:08 +0100 Message-ID: <1349256606.650.120.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Valtteri Kiviniemi Date: Wed, 3 Oct 2012 10:30:06 +0100 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xen.org" Subject: Re: [Xen-devel] xlu_cfg_get_defbool error when trying to start domU X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-10-03 at 10:16 +0100, Valtteri Kiviniemi wrote: > Hi, > > I just upgraded from Xen 4.0.4 to Xen 4.2.0. When I'm trying to start > domU using the new xl toolstack I get the following error message: > > Parsing config from /etc/xen/domu1.cfg > xl: symbol lookup error: xl: undefined symbol: xlu_cfg_get_defbool This (usually) means that your libraries are somehow out of sync. Perhaps check /usr/lib and /usr/lib64 and the output of "ldd xl" and make sure the libraries it is picking up are the 4.2 versions. If you are picking up old versions from /usr/lib64 while the new versions are in lib64 then perhaps you need to pass --libdir to configure as described in http://wiki.xen.org/wiki/Xen_4.2_Release_Notes Ian. > When lauching xend and using xm create the domU starts up normally. > > - Valtteri > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 09:30:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 09:30:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJLHQ-0003vx-St; Wed, 03 Oct 2012 09:30:12 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJLHO-0003vs-Sf for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 09:30:10 +0000 Received: from [85.158.139.83:20761] by server-14.bemta-5.messagelabs.com id 96/3A-05772-2A50C605; Wed, 03 Oct 2012 09:30:10 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-2.tower-182.messagelabs.com!1349256608!30350992!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI5OTg=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5435 invoked from network); 3 Oct 2012 09:30:09 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 09:30:09 -0000 X-IronPort-AV: E=Sophos;i="4.80,527,1344211200"; d="scan'208";a="14910205" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 09:30:08 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 10:30:08 +0100 Message-ID: <1349256606.650.120.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Valtteri Kiviniemi Date: Wed, 3 Oct 2012 10:30:06 +0100 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xen.org" Subject: Re: [Xen-devel] xlu_cfg_get_defbool error when trying to start domU X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-10-03 at 10:16 +0100, Valtteri Kiviniemi wrote: > Hi, > > I just upgraded from Xen 4.0.4 to Xen 4.2.0. When I'm trying to start > domU using the new xl toolstack I get the following error message: > > Parsing config from /etc/xen/domu1.cfg > xl: symbol lookup error: xl: undefined symbol: xlu_cfg_get_defbool This (usually) means that your libraries are somehow out of sync. Perhaps check /usr/lib and /usr/lib64 and the output of "ldd xl" and make sure the libraries it is picking up are the 4.2 versions. If you are picking up old versions from /usr/lib64 while the new versions are in lib64 then perhaps you need to pass --libdir to configure as described in http://wiki.xen.org/wiki/Xen_4.2_Release_Notes Ian. > When lauching xend and using xm create the domU starts up normally. > > - Valtteri > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 09:33:14 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 09:33:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJLK0-00042T-Ef; Wed, 03 Oct 2012 09:32:52 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJLJz-00042O-7R for xen-devel@lists.xen.org; Wed, 03 Oct 2012 09:32:51 +0000 Received: from [85.158.139.83:23850] by server-4.bemta-5.messagelabs.com id C1/2B-20767-2460C605; Wed, 03 Oct 2012 09:32:50 +0000 X-Env-Sender: thanos.makatos@citrix.com X-Msg-Ref: server-2.tower-182.messagelabs.com!1349256769!30351629!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI5OTg=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27769 invoked from network); 3 Oct 2012 09:32:50 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 09:32:50 -0000 X-IronPort-AV: E=Sophos;i="4.80,527,1344211200"; d="scan'208";a="14910307" Received: from lonpmailmx02.citrite.net ([10.30.203.163]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 09:32:49 +0000 Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Wed, 3 Oct 2012 10:32:49 +0100 From: Thanos Makatos To: Keir Fraser , "xen-devel@lists.xen.org" Date: Wed, 3 Oct 2012 10:32:47 +0100 Thread-Topic: [ANNOUNCE] Switching to git for primary Xen repositories Thread-Index: Ac2OfIRH+w9gYspcZEaiRNVrDr+z/QSzW+vA Message-ID: <4B45B535F7F6BE4CB1C044ED5115CDDE011ADEB1EB11@LONPMAILBOX01.citrite.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [Xen-devel] [ANNOUNCE] Switching to git for primary Xen repositories X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org +1 -- Thanos Makatos > -----Original Message----- > From: xen-devel-bounces@lists.xen.org [mailto:xen-devel- > bounces@lists.xen.org] On Behalf Of Keir Fraser > Sent: 09 September 2012 12:16 > To: xen-devel@lists.xen.org > Subject: [Xen-devel] [ANNOUNCE] Switching to git for primary Xen > repositories > > Folks, > > The Xen project has used mercurial for the primary repositories for > many years. However, with external projects (including Linux and qemu) > using git, this has led to us using and supporting two revision-control > systems. Our plan therefore, with the 4.2.0 release soon out of the > way, is to switch to git for all of our primary repositories. We will > plan to mirror development activity into the old mercurial repositories > at least in the short term. > > We will make a further announcement nearer to the time of the > switchover. > > Regards, > Keir & The Xen Team > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 09:33:14 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 09:33:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJLK0-00042T-Ef; Wed, 03 Oct 2012 09:32:52 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJLJz-00042O-7R for xen-devel@lists.xen.org; Wed, 03 Oct 2012 09:32:51 +0000 Received: from [85.158.139.83:23850] by server-4.bemta-5.messagelabs.com id C1/2B-20767-2460C605; Wed, 03 Oct 2012 09:32:50 +0000 X-Env-Sender: thanos.makatos@citrix.com X-Msg-Ref: server-2.tower-182.messagelabs.com!1349256769!30351629!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI5OTg=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27769 invoked from network); 3 Oct 2012 09:32:50 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 09:32:50 -0000 X-IronPort-AV: E=Sophos;i="4.80,527,1344211200"; d="scan'208";a="14910307" Received: from lonpmailmx02.citrite.net ([10.30.203.163]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 09:32:49 +0000 Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Wed, 3 Oct 2012 10:32:49 +0100 From: Thanos Makatos To: Keir Fraser , "xen-devel@lists.xen.org" Date: Wed, 3 Oct 2012 10:32:47 +0100 Thread-Topic: [ANNOUNCE] Switching to git for primary Xen repositories Thread-Index: Ac2OfIRH+w9gYspcZEaiRNVrDr+z/QSzW+vA Message-ID: <4B45B535F7F6BE4CB1C044ED5115CDDE011ADEB1EB11@LONPMAILBOX01.citrite.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [Xen-devel] [ANNOUNCE] Switching to git for primary Xen repositories X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org +1 -- Thanos Makatos > -----Original Message----- > From: xen-devel-bounces@lists.xen.org [mailto:xen-devel- > bounces@lists.xen.org] On Behalf Of Keir Fraser > Sent: 09 September 2012 12:16 > To: xen-devel@lists.xen.org > Subject: [Xen-devel] [ANNOUNCE] Switching to git for primary Xen > repositories > > Folks, > > The Xen project has used mercurial for the primary repositories for > many years. However, with external projects (including Linux and qemu) > using git, this has led to us using and supporting two revision-control > systems. Our plan therefore, with the 4.2.0 release soon out of the > way, is to switch to git for all of our primary repositories. We will > plan to mirror development activity into the old mercurial repositories > at least in the short term. > > We will make a further announcement nearer to the time of the > switchover. > > Regards, > Keir & The Xen Team > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 09:46:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 09:46:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJLX0-0004H1-G0; Wed, 03 Oct 2012 09:46:18 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJA3h-00013i-7z for xen-devel@lists.xen.org; Tue, 02 Oct 2012 21:31:17 +0000 Received: from [85.158.137.99:3917] by server-4.bemta-3.messagelabs.com id 93/A1-14155-42D5B605; Tue, 02 Oct 2012 21:31:16 +0000 X-Env-Sender: james@dingwall.me.uk X-Msg-Ref: server-11.tower-217.messagelabs.com!1349213473!18819928!1 X-Originating-IP: [81.103.221.47] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 457 invoked from network); 2 Oct 2012 21:31:13 -0000 Received: from mtaout01-winn.ispmail.ntl.com (HELO mtaout01-winn.ispmail.ntl.com) (81.103.221.47) by server-11.tower-217.messagelabs.com with SMTP; 2 Oct 2012 21:31:13 -0000 Received: from know-smtpout-1.server.virginmedia.net ([62.254.123.3]) by mtaout01-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20121002213113.PTBI10247.mtaout01-winn.ispmail.ntl.com@know-smtpout-1.server.virginmedia.net> for ; Tue, 2 Oct 2012 22:31:13 +0100 Received: from [82.32.104.97] (helo=dingwall.me.uk) by know-smtpout-1.server.virginmedia.net with esmtp (Exim 4.63) (envelope-from ) id 1TJA3C-0002rY-E9 for xen-devel@lists.xen.org; Tue, 02 Oct 2012 22:30:46 +0100 Received: (qmail 17768 invoked from network); 2 Oct 2012 21:30:45 -0000 Received: from wraith.dingwall.me.uk (192.168.1.201) by mail0.xen.dingwall.me.uk with SMTP; 2 Oct 2012 21:30:45 -0000 Received: by wraith.dingwall.me.uk (Postfix, from userid 1000) id D13ABBDFDE0; Tue, 2 Oct 2012 22:30:45 +0100 (BST) Date: Tue, 2 Oct 2012 22:30:45 +0100 From: James Dingwall To: Konrad Rzeszutek Wilk Message-ID: <20121002213045.GA7918@dingwall.me.uk> References: <20120930161345.GA31109@dingwall.me.uk> <3d2b4499921255b00c1844a133efeb93@imap.dingwall.me.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Cloudmark-Analysis: v=1.1 cv=AUhbpHVS+xhHrj9wLCYAQoYnFLYUZdbP8UM0GmH2jwk= c=1 sm=0 a=wom5GMh1gUkA:10 a=QqoBXFW6jecA:10 a=kj9zAlcOel0A:10 a=lnEDH4eqbFdgrqs5T3QA:9 a=CjuIK1q_8ugA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 X-Mailman-Approved-At: Wed, 03 Oct 2012 09:46:16 +0000 Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [james-xen@dingwall.me.uk: [Xen-users] Xen 4.2.0 - CPU Frequency Scaling] X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, Oct 02, 2012 at 03:08:39PM -0400, Konrad Rzeszutek Wilk wrote: > >> > >> What exactly are you trying to manage? As in what are you doing? > > > > What I was trying to achieve was 2 vcpus assigned and pinned to dom0 with > > the remaining available for domUs. I wanted to set the scaling governor as > > performance for the dom0 vcpus and ondemand for domUs. > > > > It was an obvious test to change dom0_max_vcpus and I should have done it > > before. On removing the parameter so that all cpus were seen in dom0 I could > > control the power state of them all independently. Reinstating the > > parameter with value of n showed that cpu 1 - (n-1) could be controlled > > independently while cpus 0 and n-11 were grouped together. > > And this behavior existed with the old kernel? Or was this something > you were trying to do now? I seem to recall that with the old xen-sources kernel that this wasn't a problem as I had an init script which set the cpu frequency governors as I wanted them. However once mainline got dom0 pvops I jumped to that and made do without that particular feature. Once xen-acpi-processor was added then I noticed this behaviour. It is possible that during that time I added the dom0_max_vcpus parameter and so I'm not comparing exactly the same configuration. I'll poke around to see if I can find an old xen kernel which I can test with. Thanks, JAmes _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 09:46:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 09:46:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJLX0-0004H1-G0; Wed, 03 Oct 2012 09:46:18 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJA3h-00013i-7z for xen-devel@lists.xen.org; Tue, 02 Oct 2012 21:31:17 +0000 Received: from [85.158.137.99:3917] by server-4.bemta-3.messagelabs.com id 93/A1-14155-42D5B605; Tue, 02 Oct 2012 21:31:16 +0000 X-Env-Sender: james@dingwall.me.uk X-Msg-Ref: server-11.tower-217.messagelabs.com!1349213473!18819928!1 X-Originating-IP: [81.103.221.47] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 457 invoked from network); 2 Oct 2012 21:31:13 -0000 Received: from mtaout01-winn.ispmail.ntl.com (HELO mtaout01-winn.ispmail.ntl.com) (81.103.221.47) by server-11.tower-217.messagelabs.com with SMTP; 2 Oct 2012 21:31:13 -0000 Received: from know-smtpout-1.server.virginmedia.net ([62.254.123.3]) by mtaout01-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20121002213113.PTBI10247.mtaout01-winn.ispmail.ntl.com@know-smtpout-1.server.virginmedia.net> for ; Tue, 2 Oct 2012 22:31:13 +0100 Received: from [82.32.104.97] (helo=dingwall.me.uk) by know-smtpout-1.server.virginmedia.net with esmtp (Exim 4.63) (envelope-from ) id 1TJA3C-0002rY-E9 for xen-devel@lists.xen.org; Tue, 02 Oct 2012 22:30:46 +0100 Received: (qmail 17768 invoked from network); 2 Oct 2012 21:30:45 -0000 Received: from wraith.dingwall.me.uk (192.168.1.201) by mail0.xen.dingwall.me.uk with SMTP; 2 Oct 2012 21:30:45 -0000 Received: by wraith.dingwall.me.uk (Postfix, from userid 1000) id D13ABBDFDE0; Tue, 2 Oct 2012 22:30:45 +0100 (BST) Date: Tue, 2 Oct 2012 22:30:45 +0100 From: James Dingwall To: Konrad Rzeszutek Wilk Message-ID: <20121002213045.GA7918@dingwall.me.uk> References: <20120930161345.GA31109@dingwall.me.uk> <3d2b4499921255b00c1844a133efeb93@imap.dingwall.me.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Cloudmark-Analysis: v=1.1 cv=AUhbpHVS+xhHrj9wLCYAQoYnFLYUZdbP8UM0GmH2jwk= c=1 sm=0 a=wom5GMh1gUkA:10 a=QqoBXFW6jecA:10 a=kj9zAlcOel0A:10 a=lnEDH4eqbFdgrqs5T3QA:9 a=CjuIK1q_8ugA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 X-Mailman-Approved-At: Wed, 03 Oct 2012 09:46:16 +0000 Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [james-xen@dingwall.me.uk: [Xen-users] Xen 4.2.0 - CPU Frequency Scaling] X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, Oct 02, 2012 at 03:08:39PM -0400, Konrad Rzeszutek Wilk wrote: > >> > >> What exactly are you trying to manage? As in what are you doing? > > > > What I was trying to achieve was 2 vcpus assigned and pinned to dom0 with > > the remaining available for domUs. I wanted to set the scaling governor as > > performance for the dom0 vcpus and ondemand for domUs. > > > > It was an obvious test to change dom0_max_vcpus and I should have done it > > before. On removing the parameter so that all cpus were seen in dom0 I could > > control the power state of them all independently. Reinstating the > > parameter with value of n showed that cpu 1 - (n-1) could be controlled > > independently while cpus 0 and n-11 were grouped together. > > And this behavior existed with the old kernel? Or was this something > you were trying to do now? I seem to recall that with the old xen-sources kernel that this wasn't a problem as I had an init script which set the cpu frequency governors as I wanted them. However once mainline got dom0 pvops I jumped to that and made do without that particular feature. Once xen-acpi-processor was added then I noticed this behaviour. It is possible that during that time I added the dom0_max_vcpus parameter and so I'm not comparing exactly the same configuration. I'll poke around to see if I can find an old xen kernel which I can test with. Thanks, JAmes _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 09:46:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 09:46:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJLWz-0004Gn-P2; Wed, 03 Oct 2012 09:46:17 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with smtp (Exim 4.72) (envelope-from ) id 1TImcN-00060h-Pi for xen-devel@lists.xen.org; Mon, 01 Oct 2012 20:29:31 +0000 X-Env-Sender: james@dingwall.me.uk X-Msg-Ref: server-15.tower-27.messagelabs.com!1349123364!6088547!1 X-Originating-IP: [81.103.221.48] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5641 invoked from network); 1 Oct 2012 20:29:24 -0000 Received: from mtaout02-winn.ispmail.ntl.com (HELO mtaout02-winn.ispmail.ntl.com) (81.103.221.48) by server-15.tower-27.messagelabs.com with SMTP; 1 Oct 2012 20:29:24 -0000 Received: from know-smtpout-1.server.virginmedia.net ([62.254.123.4]) by mtaout02-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20121001202924.YQLG1732.mtaout02-winn.ispmail.ntl.com@know-smtpout-1.server.virginmedia.net> for ; Mon, 1 Oct 2012 21:29:24 +0100 Received: from [82.32.104.97] (helo=dingwall.me.uk) by know-smtpout-1.server.virginmedia.net with esmtp (Exim 4.63) (envelope-from ) id 1TImaA-0008LI-Pr for xen-devel@lists.xen.org; Mon, 01 Oct 2012 21:27:14 +0100 Received: (qmail 8622 invoked from network); 1 Oct 2012 20:27:14 -0000 Received: from apache0.xen.dingwall.me.uk (HELO webmail.private.dingwall.me.uk) (192.168.1.35) by mail0.xen.dingwall.me.uk with SMTP; 1 Oct 2012 20:27:14 -0000 MIME-Version: 1.0 Date: Mon, 01 Oct 2012 21:27:14 +0100 From: James Dingwall To: Konrad Rzeszutek Wilk In-Reply-To: References: <20120930161345.GA31109@dingwall.me.uk> Message-ID: <3d2b4499921255b00c1844a133efeb93@imap.dingwall.me.uk> X-Sender: james@dingwall.me.uk User-Agent: Roundcube Webmail/0.8.1 X-Cloudmark-Analysis: v=1.1 cv=GaEGOwq9FwezmTggA+b6yC6zDZF2HYaK6RN/tSqdnVA= c=1 sm=0 a=LJ0inPZW_QAA:10 a=QqoBXFW6jecA:10 a=IkcTkHD0fZMA:10 a=5IRWAbXhAAAA:8 a=MgKqO5HjBuqlksDnyjgA:9 a=QEXdDO2ut3YA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 X-Mailman-Approved-At: Wed, 03 Oct 2012 09:46:16 +0000 Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [james-xen@dingwall.me.uk: [Xen-users] Xen 4.2.0 - CPU Frequency Scaling] X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 2012-10-01 17:33, Konrad Rzeszutek Wilk wrote: > On Sun, Sep 30, 2012 at 12:13 PM, James Dingwall > wrote: >> Hi, >> >> I didn't get any response on xen-users for this issue but so I'm >> hoping >> -devel can help. > > Lets see if we can help you. Thank you:) >> I have had problems using cpu frequency scaling since the >> xen-acpi-processor code was added to the mainline kernel source. I >> wasn't sure if the problem I was seeing was related to the old >> version >> (4.1.2) of Xen that I was using but now I'm on 4.2.0 and it still >> exists >> I thought I would check if I have a misconfiguration or if I have >> discovered a problem. My system is a dual AMD Opteron(tm) Processor >> 2423 HE on kernel 3.4.8. >> >> The xen command line is: >> console=vga,com2 com2=115200,8n1 dom0_mem=max:2048M >> dom0_max_vcpus=2 >> dom0_vcpus_pin > > Do you nee the dom0_max_vcpus=2? If they are not present does the > problem persist? >> >> The CPU scaling information reported by xenpm is below. The problem >> is that only cpuid 1 can be managed separately, all the others are > > What exactly are you trying to manage? As in what are you doing? What I was trying to achieve was 2 vcpus assigned and pinned to dom0 with the remaining available for domUs. I wanted to set the scaling governor as performance for the dom0 vcpus and ondemand for domUs. It was an obvious test to change dom0_max_vcpus and I should have done it before. On removing the parameter so that all cpus were seen in dom0 I could control the power state of them all independently. Reinstating the parameter with value of n showed that cpu 1 - (n-1) could be controlled independently while cpus 0 and n-11 were grouped together. >> bundled together and cannot be handled independently which used to >> be >> possible with the old xen kernel. If further information would be >> useful please let me know. I did have a look at xen-acpi-processor.c but it is a bit beyond me and perhaps not even the right place to start. Thanks, James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 09:46:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 09:46:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJLWz-0004Gn-P2; Wed, 03 Oct 2012 09:46:17 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with smtp (Exim 4.72) (envelope-from ) id 1TImcN-00060h-Pi for xen-devel@lists.xen.org; Mon, 01 Oct 2012 20:29:31 +0000 X-Env-Sender: james@dingwall.me.uk X-Msg-Ref: server-15.tower-27.messagelabs.com!1349123364!6088547!1 X-Originating-IP: [81.103.221.48] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5641 invoked from network); 1 Oct 2012 20:29:24 -0000 Received: from mtaout02-winn.ispmail.ntl.com (HELO mtaout02-winn.ispmail.ntl.com) (81.103.221.48) by server-15.tower-27.messagelabs.com with SMTP; 1 Oct 2012 20:29:24 -0000 Received: from know-smtpout-1.server.virginmedia.net ([62.254.123.4]) by mtaout02-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20121001202924.YQLG1732.mtaout02-winn.ispmail.ntl.com@know-smtpout-1.server.virginmedia.net> for ; Mon, 1 Oct 2012 21:29:24 +0100 Received: from [82.32.104.97] (helo=dingwall.me.uk) by know-smtpout-1.server.virginmedia.net with esmtp (Exim 4.63) (envelope-from ) id 1TImaA-0008LI-Pr for xen-devel@lists.xen.org; Mon, 01 Oct 2012 21:27:14 +0100 Received: (qmail 8622 invoked from network); 1 Oct 2012 20:27:14 -0000 Received: from apache0.xen.dingwall.me.uk (HELO webmail.private.dingwall.me.uk) (192.168.1.35) by mail0.xen.dingwall.me.uk with SMTP; 1 Oct 2012 20:27:14 -0000 MIME-Version: 1.0 Date: Mon, 01 Oct 2012 21:27:14 +0100 From: James Dingwall To: Konrad Rzeszutek Wilk In-Reply-To: References: <20120930161345.GA31109@dingwall.me.uk> Message-ID: <3d2b4499921255b00c1844a133efeb93@imap.dingwall.me.uk> X-Sender: james@dingwall.me.uk User-Agent: Roundcube Webmail/0.8.1 X-Cloudmark-Analysis: v=1.1 cv=GaEGOwq9FwezmTggA+b6yC6zDZF2HYaK6RN/tSqdnVA= c=1 sm=0 a=LJ0inPZW_QAA:10 a=QqoBXFW6jecA:10 a=IkcTkHD0fZMA:10 a=5IRWAbXhAAAA:8 a=MgKqO5HjBuqlksDnyjgA:9 a=QEXdDO2ut3YA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 X-Mailman-Approved-At: Wed, 03 Oct 2012 09:46:16 +0000 Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [james-xen@dingwall.me.uk: [Xen-users] Xen 4.2.0 - CPU Frequency Scaling] X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 2012-10-01 17:33, Konrad Rzeszutek Wilk wrote: > On Sun, Sep 30, 2012 at 12:13 PM, James Dingwall > wrote: >> Hi, >> >> I didn't get any response on xen-users for this issue but so I'm >> hoping >> -devel can help. > > Lets see if we can help you. Thank you:) >> I have had problems using cpu frequency scaling since the >> xen-acpi-processor code was added to the mainline kernel source. I >> wasn't sure if the problem I was seeing was related to the old >> version >> (4.1.2) of Xen that I was using but now I'm on 4.2.0 and it still >> exists >> I thought I would check if I have a misconfiguration or if I have >> discovered a problem. My system is a dual AMD Opteron(tm) Processor >> 2423 HE on kernel 3.4.8. >> >> The xen command line is: >> console=vga,com2 com2=115200,8n1 dom0_mem=max:2048M >> dom0_max_vcpus=2 >> dom0_vcpus_pin > > Do you nee the dom0_max_vcpus=2? If they are not present does the > problem persist? >> >> The CPU scaling information reported by xenpm is below. The problem >> is that only cpuid 1 can be managed separately, all the others are > > What exactly are you trying to manage? As in what are you doing? What I was trying to achieve was 2 vcpus assigned and pinned to dom0 with the remaining available for domUs. I wanted to set the scaling governor as performance for the dom0 vcpus and ondemand for domUs. It was an obvious test to change dom0_max_vcpus and I should have done it before. On removing the parameter so that all cpus were seen in dom0 I could control the power state of them all independently. Reinstating the parameter with value of n showed that cpu 1 - (n-1) could be controlled independently while cpus 0 and n-11 were grouped together. >> bundled together and cannot be handled independently which used to >> be >> possible with the old xen kernel. If further information would be >> useful please let me know. I did have a look at xen-acpi-processor.c but it is a bit beyond me and perhaps not even the right place to start. Thanks, James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 09:46:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 09:46:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJLX0-0004Gu-4I; Wed, 03 Oct 2012 09:46:18 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ8Xg-000779-2M for xen-devel@lists.xen.org; Tue, 02 Oct 2012 19:54:08 +0000 Received: from [85.158.138.51:28059] by server-1.bemta-3.messagelabs.com id 00/FB-16425-F564B605; Tue, 02 Oct 2012 19:54:07 +0000 X-Env-Sender: mossa@poisson.phc.unipi.it X-Msg-Ref: server-16.tower-174.messagelabs.com!1349207646!32758302!1 X-Originating-IP: [131.114.10.30] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4669 invoked from network); 2 Oct 2012 19:54:06 -0000 Received: from poisson.phc.unipi.it (HELO poisson.phc.unipi.it) (131.114.10.30) by server-16.tower-174.messagelabs.com with SMTP; 2 Oct 2012 19:54:06 -0000 Received: from intersect (nat6.phc.unipi.it [131.114.10.70]) by poisson.phc.unipi.it (Postfix) with ESMTPS id 4A29415A001; Tue, 2 Oct 2012 21:54:06 +0200 (CEST) Received: by intersect (Postfix, from userid 1000) id 6A1C82C32; Tue, 2 Oct 2012 21:54:05 +0200 (CEST) Date: Tue, 2 Oct 2012 21:54:05 +0200 From: Giorgio Mossa To: Ian Campbell Message-ID: <20121002195405.GB28427@intersect> References: <20121002163136.GA5378@intersect> <1349196417.650.115.camel@zakaz.uk.xensource.com> <1349196603.650.116.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1349196603.650.116.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Wed, 03 Oct 2012 09:46:16 +0000 Cc: "xen-users@lists.xen.org" , xen-devel , Ian Jackson , Roger Pau Monne Subject: Re: [Xen-devel] [Xen-users] libutil.h moved to bsd/libutil.h (Was: Re: Problem compiling Xen 4.2 from sources) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, Oct 02, 2012 at 05:50:03PM +0100, Ian Campbell wrote: > On Tue, 2012-10-02 at 17:46 +0100, Ian Campbell wrote: > > Oh, BTW, I expect you could just purge libbsd-dev from your system and > that would workaround the issue. > > Ian. > Sadly I can't because I've other packages which depend on it...... _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 09:46:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 09:46:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJLX0-0004Gu-4I; Wed, 03 Oct 2012 09:46:18 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJ8Xg-000779-2M for xen-devel@lists.xen.org; Tue, 02 Oct 2012 19:54:08 +0000 Received: from [85.158.138.51:28059] by server-1.bemta-3.messagelabs.com id 00/FB-16425-F564B605; Tue, 02 Oct 2012 19:54:07 +0000 X-Env-Sender: mossa@poisson.phc.unipi.it X-Msg-Ref: server-16.tower-174.messagelabs.com!1349207646!32758302!1 X-Originating-IP: [131.114.10.30] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4669 invoked from network); 2 Oct 2012 19:54:06 -0000 Received: from poisson.phc.unipi.it (HELO poisson.phc.unipi.it) (131.114.10.30) by server-16.tower-174.messagelabs.com with SMTP; 2 Oct 2012 19:54:06 -0000 Received: from intersect (nat6.phc.unipi.it [131.114.10.70]) by poisson.phc.unipi.it (Postfix) with ESMTPS id 4A29415A001; Tue, 2 Oct 2012 21:54:06 +0200 (CEST) Received: by intersect (Postfix, from userid 1000) id 6A1C82C32; Tue, 2 Oct 2012 21:54:05 +0200 (CEST) Date: Tue, 2 Oct 2012 21:54:05 +0200 From: Giorgio Mossa To: Ian Campbell Message-ID: <20121002195405.GB28427@intersect> References: <20121002163136.GA5378@intersect> <1349196417.650.115.camel@zakaz.uk.xensource.com> <1349196603.650.116.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1349196603.650.116.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Wed, 03 Oct 2012 09:46:16 +0000 Cc: "xen-users@lists.xen.org" , xen-devel , Ian Jackson , Roger Pau Monne Subject: Re: [Xen-devel] [Xen-users] libutil.h moved to bsd/libutil.h (Was: Re: Problem compiling Xen 4.2 from sources) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, Oct 02, 2012 at 05:50:03PM +0100, Ian Campbell wrote: > On Tue, 2012-10-02 at 17:46 +0100, Ian Campbell wrote: > > Oh, BTW, I expect you could just purge libbsd-dev from your system and > that would workaround the issue. > > Ian. > Sadly I can't because I've other packages which depend on it...... _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 09:49:44 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 09:49:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJLa7-0004hW-I1; Wed, 03 Oct 2012 09:49:31 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJLa6-0004hG-EY for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 09:49:30 +0000 Received: from [85.158.139.83:37285] by server-15.bemta-5.messagelabs.com id 00/0D-19430-92A0C605; Wed, 03 Oct 2012 09:49:29 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1349257767!27586454!1 X-Originating-IP: [209.85.213.173] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5820 invoked from network); 3 Oct 2012 09:49:28 -0000 Received: from mail-yx0-f173.google.com (HELO mail-yx0-f173.google.com) (209.85.213.173) by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 09:49:28 -0000 Received: by yenl3 with SMTP id l3so2177106yen.32 for ; Wed, 03 Oct 2012 02:49:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rzgMrEICAp8hy6jmas7cKCrnqBVLsbVnJPIIJ3B59BA=; b=bRICp/IWat+FKL+CiDFQwcqYNsixQOeKMldWWRbbZ8VrUsKOGs+P66tEjXWzRalRaB iK40jqN0VBKdqMmD3Qd+XdMP1eA6FYpHKd0DOSH+TLpTL5XQsr8nfbq1hDt2D28JHBWo t3ndC0MpJj+HmE314jJb1wo68KVVynaQ+0WD6r96eoIEozMlzV/ZGHJ4thgQb1bqCNHT Q873Jjq3GeAzKMdXM4gGHQU4dMVr0mSu50sNBEd2E6eJD433w5Pu63YS/vwLBo0oqGc4 HoQ9OvilUMbH1tumqGUh/tPM0BJInYbMX7xnX3crc5Gj3HsBqLsl5P8e6u9Me5iM368M 9vXg== MIME-Version: 1.0 Received: by 10.236.151.99 with SMTP id a63mr1232491yhk.120.1349257767418; Wed, 03 Oct 2012 02:49:27 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Wed, 3 Oct 2012 02:49:27 -0700 (PDT) In-Reply-To: <1349256606.650.120.camel@zakaz.uk.xensource.com> References: <1349256606.650.120.camel@zakaz.uk.xensource.com> Date: Wed, 3 Oct 2012 12:49:27 +0300 Message-ID: From: Valtteri Kiviniemi To: Ian Campbell Cc: "Xen-devel@lists.xen.org" Subject: Re: [Xen-devel] xlu_cfg_get_defbool error when trying to start domU X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4841172087197753040==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============4841172087197753040== Content-Type: multipart/alternative; boundary=20cf303a2e35effcf904cb248d8a --20cf303a2e35effcf904cb248d8a Content-Type: text/plain; charset=ISO-8859-1 Hi, Ah, I missed that one, thanks! Its working now when using --libdir configure option. - Valtteri 2012/10/3 Ian Campbell > On Wed, 2012-10-03 at 10:16 +0100, Valtteri Kiviniemi wrote: > > Hi, > > > > I just upgraded from Xen 4.0.4 to Xen 4.2.0. When I'm trying to start > > domU using the new xl toolstack I get the following error message: > > > > Parsing config from /etc/xen/domu1.cfg > > xl: symbol lookup error: xl: undefined symbol: xlu_cfg_get_defbool > > This (usually) means that your libraries are somehow out of sync. > > Perhaps check /usr/lib and /usr/lib64 and the output of "ldd xl" and > make sure the libraries it is picking up are the 4.2 versions. > > If you are picking up old versions from /usr/lib64 while the new > versions are in lib64 then perhaps you need to pass --libdir to > configure as described in http://wiki.xen.org/wiki/Xen_4.2_Release_Notes > > Ian. > > > When lauching xend and using xm create the domU starts up normally. > > > > - Valtteri > > > > > --20cf303a2e35effcf904cb248d8a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Ah, I missed that one, thanks! Its working now when using --libd= ir configure option.

- Valtteri

20= 12/10/3 Ian Campbell <Ian.Campbell@citrix.com>
On Wed, 2012-10-03 at 10:1= 6 +0100, Valtteri Kiviniemi wrote:
> Hi,
>
> I just upgraded from Xen 4.0.4 to Xen 4.2.0. When I'm trying to st= art
> domU using the new xl toolstack I get the following error message:
>
> Parsing config from /etc/xen/domu1.cfg
> xl: symbol lookup error: xl: undefined symbol: xlu_cfg_get_defbool

This (usually) means that your libraries are somehow out of sync.

Perhaps check /usr/lib and /usr/lib64 and the output of "ldd xl" = and
make sure the libraries it is picking up are the 4.2 versions.

If you are picking up old versions from /usr/lib64 while the new
versions are in lib64 then perhaps you need to pass --libdir to
configure as described in http://wiki.xen.org/wiki/Xen_4.2_Release_Notes<= /a>

Ian.

> When lauching xend and using xm create the domU starts up normally. >
> - Valtteri
>



--20cf303a2e35effcf904cb248d8a-- --===============4841172087197753040== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============4841172087197753040==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 09:49:44 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 09:49:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJLa7-0004hW-I1; Wed, 03 Oct 2012 09:49:31 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJLa6-0004hG-EY for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 09:49:30 +0000 Received: from [85.158.139.83:37285] by server-15.bemta-5.messagelabs.com id 00/0D-19430-92A0C605; Wed, 03 Oct 2012 09:49:29 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1349257767!27586454!1 X-Originating-IP: [209.85.213.173] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5820 invoked from network); 3 Oct 2012 09:49:28 -0000 Received: from mail-yx0-f173.google.com (HELO mail-yx0-f173.google.com) (209.85.213.173) by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 09:49:28 -0000 Received: by yenl3 with SMTP id l3so2177106yen.32 for ; Wed, 03 Oct 2012 02:49:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rzgMrEICAp8hy6jmas7cKCrnqBVLsbVnJPIIJ3B59BA=; b=bRICp/IWat+FKL+CiDFQwcqYNsixQOeKMldWWRbbZ8VrUsKOGs+P66tEjXWzRalRaB iK40jqN0VBKdqMmD3Qd+XdMP1eA6FYpHKd0DOSH+TLpTL5XQsr8nfbq1hDt2D28JHBWo t3ndC0MpJj+HmE314jJb1wo68KVVynaQ+0WD6r96eoIEozMlzV/ZGHJ4thgQb1bqCNHT Q873Jjq3GeAzKMdXM4gGHQU4dMVr0mSu50sNBEd2E6eJD433w5Pu63YS/vwLBo0oqGc4 HoQ9OvilUMbH1tumqGUh/tPM0BJInYbMX7xnX3crc5Gj3HsBqLsl5P8e6u9Me5iM368M 9vXg== MIME-Version: 1.0 Received: by 10.236.151.99 with SMTP id a63mr1232491yhk.120.1349257767418; Wed, 03 Oct 2012 02:49:27 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Wed, 3 Oct 2012 02:49:27 -0700 (PDT) In-Reply-To: <1349256606.650.120.camel@zakaz.uk.xensource.com> References: <1349256606.650.120.camel@zakaz.uk.xensource.com> Date: Wed, 3 Oct 2012 12:49:27 +0300 Message-ID: From: Valtteri Kiviniemi To: Ian Campbell Cc: "Xen-devel@lists.xen.org" Subject: Re: [Xen-devel] xlu_cfg_get_defbool error when trying to start domU X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4841172087197753040==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============4841172087197753040== Content-Type: multipart/alternative; boundary=20cf303a2e35effcf904cb248d8a --20cf303a2e35effcf904cb248d8a Content-Type: text/plain; charset=ISO-8859-1 Hi, Ah, I missed that one, thanks! Its working now when using --libdir configure option. - Valtteri 2012/10/3 Ian Campbell > On Wed, 2012-10-03 at 10:16 +0100, Valtteri Kiviniemi wrote: > > Hi, > > > > I just upgraded from Xen 4.0.4 to Xen 4.2.0. When I'm trying to start > > domU using the new xl toolstack I get the following error message: > > > > Parsing config from /etc/xen/domu1.cfg > > xl: symbol lookup error: xl: undefined symbol: xlu_cfg_get_defbool > > This (usually) means that your libraries are somehow out of sync. > > Perhaps check /usr/lib and /usr/lib64 and the output of "ldd xl" and > make sure the libraries it is picking up are the 4.2 versions. > > If you are picking up old versions from /usr/lib64 while the new > versions are in lib64 then perhaps you need to pass --libdir to > configure as described in http://wiki.xen.org/wiki/Xen_4.2_Release_Notes > > Ian. > > > When lauching xend and using xm create the domU starts up normally. > > > > - Valtteri > > > > > --20cf303a2e35effcf904cb248d8a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Ah, I missed that one, thanks! Its working now when using --libd= ir configure option.

- Valtteri

20= 12/10/3 Ian Campbell <Ian.Campbell@citrix.com>
On Wed, 2012-10-03 at 10:1= 6 +0100, Valtteri Kiviniemi wrote:
> Hi,
>
> I just upgraded from Xen 4.0.4 to Xen 4.2.0. When I'm trying to st= art
> domU using the new xl toolstack I get the following error message:
>
> Parsing config from /etc/xen/domu1.cfg
> xl: symbol lookup error: xl: undefined symbol: xlu_cfg_get_defbool

This (usually) means that your libraries are somehow out of sync.

Perhaps check /usr/lib and /usr/lib64 and the output of "ldd xl" = and
make sure the libraries it is picking up are the 4.2 versions.

If you are picking up old versions from /usr/lib64 while the new
versions are in lib64 then perhaps you need to pass --libdir to
configure as described in http://wiki.xen.org/wiki/Xen_4.2_Release_Notes<= /a>

Ian.

> When lauching xend and using xm create the domU starts up normally. >
> - Valtteri
>



--20cf303a2e35effcf904cb248d8a-- --===============4841172087197753040== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============4841172087197753040==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 10:01:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 10:01:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJLli-00051A-QP; Wed, 03 Oct 2012 10:01:30 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJLlh-000515-AE for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 10:01:29 +0000 Received: from [85.158.139.211:18221] by server-13.bemta-5.messagelabs.com id 32/96-16359-8FC0C605; Wed, 03 Oct 2012 10:01:28 +0000 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-13.tower-206.messagelabs.com!1349258487!16911933!1 X-Originating-IP: [74.125.83.43] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1251 invoked from network); 3 Oct 2012 10:01:27 -0000 Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com) (74.125.83.43) by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 10:01:27 -0000 Received: by eekc13 with SMTP id c13so3907445eek.30 for ; Wed, 03 Oct 2012 03:01:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=26/0c6TvhvRxUBHG6GnV/pOHUscb2CrPBybC9ixCA0k=; b=Qfg7/pObozEcXNGRBp8taFzapnm6WFTfsgBaJpPcxSU6gDs08fzrD3A4iYmaeZac9I +GixISF1+uiPN69+YAUDB3G9WnYLnbAMDpBVsZdqK6fcKKac3l09wvPfRdA1pgrMFzzC VO/AQy2kKFgAhXoZrRNUZ42XkHIWkxsCgEHHOFttzIDxX/f6omOiA0CQO8JLXtI3sL57 tQG/IZP5kne+nJpKlD4K5kXy8D67qtWZsMKZoeqn3frB2TLOESfkQBsrQfQkGQUc5Ref mNmGWtCffx/2M7+NjgSfqJpXjw9JHr8MXv1i8UzLzgmVlkG4QYBx1wo1hThuoUaHvp6D j3vQ== MIME-Version: 1.0 Received: by 10.14.180.68 with SMTP id i44mr1883113eem.20.1349258487502; Wed, 03 Oct 2012 03:01:27 -0700 (PDT) Received: by 10.14.215.195 with HTTP; Wed, 3 Oct 2012 03:01:27 -0700 (PDT) In-Reply-To: <506B1F23.105@citrix.com> References: <1349113629-6338-1-git-send-email-david.vrabel@citrix.com> <1349113629-6338-3-git-send-email-david.vrabel@citrix.com> <506B1F23.105@citrix.com> Date: Wed, 3 Oct 2012 11:01:27 +0100 X-Google-Sender-Auth: VpEvDdfaPLEBVm-IZ2Mmq447Mv0 Message-ID: From: George Dunlap To: David Vrabel Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 2/3] trace: improve usefulness of hypercall trace record X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, Oct 2, 2012 at 6:06 PM, David Vrabel wrote: > On 02/10/12 17:09, George Dunlap wrote: >> On Mon, Oct 1, 2012 at 6:47 PM, David Vrabel wrote: >>> From: David Vrabel >>> >>> Trace hypercalls using a more useful trace record format. >>> >>> The EIP field is removed (it was always somewhere in the hypercall >>> page) and include selected hypercall arguments (e.g., the number of >>> calls in a multicall, and the number of PTE updates in an mmu_update >>> etc.). 12 bits in the first extra word are used to indicate which >>> arguments are present in the record and what size they are (32 or >>> 64-bit). >>> >>> This is an incompatible record format so a new event ID is used so >>> tools can distinguish between the two formats. >>> >>> Signed-off-by: David Vrabel >>> Acked-by: George Dunlap >> >> Looking at it again, I do have one comment (see below) -- so I guess >> that would be technically withdrawing the Ack until we sort it out. >> >>> diff --git a/xen/arch/x86/trace.c b/xen/arch/x86/trace.c >>> index 27fe150..f2c75bc 100644 >>> --- a/xen/arch/x86/trace.c >>> +++ b/xen/arch/x86/trace.c >>> @@ -9,33 +9,28 @@ >>> void trace_hypercall(void) >> >> In most places, "trace_*" means "Call unconditionally; inside it will >> check tb_init_done", while "__trace_*" means, "I have already checked >> that tb_init_done is set, don't bother checking it." > > This isn't something that this patch changes but I'll add a new patch to > change this since it's a trivial change. Great, thanks. -G > >>> + switch ( op ) >>> + { >>> + case __HYPERVISOR_mmu_update: >>> + APPEND_ARG32(1); /* count */ >>> + break; >>> + case __HYPERVISOR_multicall: >>> + APPEND_ARG32(1); /* count */ >>> + break; >>> + case __HYPERVISOR_grant_table_op: >>> + APPEND_ARG32(0); /* cmd */ >>> + APPEND_ARG32(2); /* count */ >>> + break; >>> + case __HYPERVISOR_vcpu_op: >>> + APPEND_ARG32(0); /* cmd */ >>> + APPEND_ARG32(1); /* vcpuid */ >>> + break; >>> + case __HYPERVISOR_mmuext_op: >>> + APPEND_ARG32(1); /* count */ >>> + break; >>> + case __HYPERVISOR_sched_op: >>> + APPEND_ARG32(0); /* cmd */ >>> + break; >>> + } >> >> I may have commented on this before -- I wonder if doing some kind of >> array might be better than a big switch statement. I think with only >> a few hypercalls, a switch statement is probably acceptable; but as we >> add more, the code is going to get bloated. > > I'll see what I can come up with. > > David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 10:01:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 10:01:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJLli-00051A-QP; Wed, 03 Oct 2012 10:01:30 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJLlh-000515-AE for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 10:01:29 +0000 Received: from [85.158.139.211:18221] by server-13.bemta-5.messagelabs.com id 32/96-16359-8FC0C605; Wed, 03 Oct 2012 10:01:28 +0000 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-13.tower-206.messagelabs.com!1349258487!16911933!1 X-Originating-IP: [74.125.83.43] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1251 invoked from network); 3 Oct 2012 10:01:27 -0000 Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com) (74.125.83.43) by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 10:01:27 -0000 Received: by eekc13 with SMTP id c13so3907445eek.30 for ; Wed, 03 Oct 2012 03:01:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=26/0c6TvhvRxUBHG6GnV/pOHUscb2CrPBybC9ixCA0k=; b=Qfg7/pObozEcXNGRBp8taFzapnm6WFTfsgBaJpPcxSU6gDs08fzrD3A4iYmaeZac9I +GixISF1+uiPN69+YAUDB3G9WnYLnbAMDpBVsZdqK6fcKKac3l09wvPfRdA1pgrMFzzC VO/AQy2kKFgAhXoZrRNUZ42XkHIWkxsCgEHHOFttzIDxX/f6omOiA0CQO8JLXtI3sL57 tQG/IZP5kne+nJpKlD4K5kXy8D67qtWZsMKZoeqn3frB2TLOESfkQBsrQfQkGQUc5Ref mNmGWtCffx/2M7+NjgSfqJpXjw9JHr8MXv1i8UzLzgmVlkG4QYBx1wo1hThuoUaHvp6D j3vQ== MIME-Version: 1.0 Received: by 10.14.180.68 with SMTP id i44mr1883113eem.20.1349258487502; Wed, 03 Oct 2012 03:01:27 -0700 (PDT) Received: by 10.14.215.195 with HTTP; Wed, 3 Oct 2012 03:01:27 -0700 (PDT) In-Reply-To: <506B1F23.105@citrix.com> References: <1349113629-6338-1-git-send-email-david.vrabel@citrix.com> <1349113629-6338-3-git-send-email-david.vrabel@citrix.com> <506B1F23.105@citrix.com> Date: Wed, 3 Oct 2012 11:01:27 +0100 X-Google-Sender-Auth: VpEvDdfaPLEBVm-IZ2Mmq447Mv0 Message-ID: From: George Dunlap To: David Vrabel Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 2/3] trace: improve usefulness of hypercall trace record X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, Oct 2, 2012 at 6:06 PM, David Vrabel wrote: > On 02/10/12 17:09, George Dunlap wrote: >> On Mon, Oct 1, 2012 at 6:47 PM, David Vrabel wrote: >>> From: David Vrabel >>> >>> Trace hypercalls using a more useful trace record format. >>> >>> The EIP field is removed (it was always somewhere in the hypercall >>> page) and include selected hypercall arguments (e.g., the number of >>> calls in a multicall, and the number of PTE updates in an mmu_update >>> etc.). 12 bits in the first extra word are used to indicate which >>> arguments are present in the record and what size they are (32 or >>> 64-bit). >>> >>> This is an incompatible record format so a new event ID is used so >>> tools can distinguish between the two formats. >>> >>> Signed-off-by: David Vrabel >>> Acked-by: George Dunlap >> >> Looking at it again, I do have one comment (see below) -- so I guess >> that would be technically withdrawing the Ack until we sort it out. >> >>> diff --git a/xen/arch/x86/trace.c b/xen/arch/x86/trace.c >>> index 27fe150..f2c75bc 100644 >>> --- a/xen/arch/x86/trace.c >>> +++ b/xen/arch/x86/trace.c >>> @@ -9,33 +9,28 @@ >>> void trace_hypercall(void) >> >> In most places, "trace_*" means "Call unconditionally; inside it will >> check tb_init_done", while "__trace_*" means, "I have already checked >> that tb_init_done is set, don't bother checking it." > > This isn't something that this patch changes but I'll add a new patch to > change this since it's a trivial change. Great, thanks. -G > >>> + switch ( op ) >>> + { >>> + case __HYPERVISOR_mmu_update: >>> + APPEND_ARG32(1); /* count */ >>> + break; >>> + case __HYPERVISOR_multicall: >>> + APPEND_ARG32(1); /* count */ >>> + break; >>> + case __HYPERVISOR_grant_table_op: >>> + APPEND_ARG32(0); /* cmd */ >>> + APPEND_ARG32(2); /* count */ >>> + break; >>> + case __HYPERVISOR_vcpu_op: >>> + APPEND_ARG32(0); /* cmd */ >>> + APPEND_ARG32(1); /* vcpuid */ >>> + break; >>> + case __HYPERVISOR_mmuext_op: >>> + APPEND_ARG32(1); /* count */ >>> + break; >>> + case __HYPERVISOR_sched_op: >>> + APPEND_ARG32(0); /* cmd */ >>> + break; >>> + } >> >> I may have commented on this before -- I wonder if doing some kind of >> array might be better than a big switch statement. I think with only >> a few hypercalls, a switch statement is probably acceptable; but as we >> add more, the code is going to get bloated. > > I'll see what I can come up with. > > David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 10:09:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 10:09:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJLtS-0005RF-Hc; Wed, 03 Oct 2012 10:09:30 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJLtR-0005R7-1X for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 10:09:29 +0000 Received: from [85.158.143.35:19757] by server-1.bemta-4.messagelabs.com id A7/CA-05684-8DE0C605; Wed, 03 Oct 2012 10:09:28 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1349258965!16130292!1 X-Originating-IP: [209.85.213.45] X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_00_10,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31233 invoked from network); 3 Oct 2012 10:09:27 -0000 Received: from mail-yh0-f45.google.com (HELO mail-yh0-f45.google.com) (209.85.213.45) by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 10:09:27 -0000 Received: by yhpp34 with SMTP id p34so700399yhp.32 for ; Wed, 03 Oct 2012 03:09:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=pLqlsh+62hhspGCxe9nEI4WKITisSvLbwxqnEUMV41o=; b=rSRuvIp1zreeA+ltcEZqGTxaWh8X77UeCJy7+Z2gVzFbt+Y/jrzKolUBagz3oAbEn0 yvLn2xv1MXtbpOgj1BSpuqp3ZRC59xoZprPMDNrcUuSgtkXbEKpyhHLzk7GYrOwmPuL/ JlKLJqYDKY/HxzSPS2VFHVLpGZW7AEZDghmLEJPIqqCC2/sC6+4HQ3YJmWnK9z6lCqyG YatczKgFBCtf8jIZIGffg2nG4igEGAPaMTGz/i3fU7ba+IdzRyqiucgkKj4aZQq/KdPL +bzFVsPLIB8MkYYOcC+WcmdU9eueq/6vNL+GWHHCWi4wTFwHB/1uUa79BVuxWLAA8MQL aAJQ== MIME-Version: 1.0 Received: by 10.236.155.71 with SMTP id i47mr1324512yhk.72.1349258965235; Wed, 03 Oct 2012 03:09:25 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Wed, 3 Oct 2012 03:09:25 -0700 (PDT) Date: Wed, 3 Oct 2012 13:09:25 +0300 Message-ID: From: Valtteri Kiviniemi To: Xen-devel@lists.xen.org Subject: [Xen-devel] Xen 4.2.0, xl toolstack cant launch older domUs X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1558911241681224206==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============1558911241681224206== Content-Type: multipart/alternative; boundary=20cf303b42695537b604cb24d520 --20cf303b42695537b604cb24d520 Content-Type: text/plain; charset=ISO-8859-1 Hi, I just upgraded to Xen 4.2.0 and after some problems I got everything working except my older legacy domU's. I still have some old domU's ported from Xen 3.0.4 which are running Debian etch and kernel 2.6.16.33-xen. When I try to launch them with xl create I get the following error messages: root@xen-2:/# xl create /etc/xen/lightning.cfg -c Daemon running with PID 5453 libxl: error: libxl_dom.c:34:libxl__domain_type: unable to get domain type for domid=10 Unable to attach console libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: console child [0] exited with error status 1 If I try to launch it without the -c parameter it seems to start but it actually goes into some kind of bootloop. /var/log/xen/xl-lightning.log is looping these error messages: root@xen-2:/var/log/xen# cat xl-lightning.log Waiting for domain lightning (domid 132) to die [pid 24083] Domain 132 has shut down, reason code 3 0x3 Action for shutdown reason code 3 is restart Domain 132 needs to be cleaned up: destroying the domain Done. Rebooting now Waiting for domain lightning (domid 134) to die [pid 24083] Domain 134 has shut down, reason code 3 0x3 Action for shutdown reason code 3 is restart Domain 134 needs to be cleaned up: destroying the domain Done. Rebooting now If I start xend and use xm create the domU will start up just fine with no problems. - Valtteri --20cf303b42695537b604cb24d520 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I just upgraded to Xen 4.2.0 and after some problems I got every= thing working except my older legacy domU's. I still have some old domU= 's ported from Xen 3.0.4 which are running Debian etch and kernel 2.6.1= 6.33-xen. When I try to launch them with xl create I get the following erro= r messages:

root@xen-2:/# xl create /etc/xen/lightning.cfg -c
Daemon running wit= h PID 5453
libxl: error: libxl_dom.c:34:libxl__domain_type: unable to ge= t domain type for domid=3D10
Unable to attach console
libxl: error: l= ibxl_exec.c:118:libxl_report_child_exitstatus: console child [0] exited wit= h error status 1

If I try to launch it without the -c parameter it seems to start but it= actually goes into some kind of bootloop. /var/log/xen/xl-lightning.log is= looping these error messages:

root@xen-2:/var/log/xen# cat xl-light= ning.log
Waiting for domain lightning (domid 132) to die [pid 24083]
Domain 132 h= as shut down, reason code 3 0x3
Action for shutdown reason code 3 is res= tart
Domain 132 needs to be cleaned up: destroying the domain
Done. R= ebooting now
Waiting for domain lightning (domid 134) to die [pid 24083]
Domain 134 h= as shut down, reason code 3 0x3
Action for shutdown reason code 3 is res= tart
Domain 134 needs to be cleaned up: destroying the domain
Done. R= ebooting now

If I start xend and use xm create the domU will start up just fine with= no problems.

- Valtteri


--20cf303b42695537b604cb24d520-- --===============1558911241681224206== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============1558911241681224206==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 10:09:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 10:09:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJLtS-0005RF-Hc; Wed, 03 Oct 2012 10:09:30 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJLtR-0005R7-1X for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 10:09:29 +0000 Received: from [85.158.143.35:19757] by server-1.bemta-4.messagelabs.com id A7/CA-05684-8DE0C605; Wed, 03 Oct 2012 10:09:28 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1349258965!16130292!1 X-Originating-IP: [209.85.213.45] X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_00_10,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31233 invoked from network); 3 Oct 2012 10:09:27 -0000 Received: from mail-yh0-f45.google.com (HELO mail-yh0-f45.google.com) (209.85.213.45) by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 10:09:27 -0000 Received: by yhpp34 with SMTP id p34so700399yhp.32 for ; Wed, 03 Oct 2012 03:09:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=pLqlsh+62hhspGCxe9nEI4WKITisSvLbwxqnEUMV41o=; b=rSRuvIp1zreeA+ltcEZqGTxaWh8X77UeCJy7+Z2gVzFbt+Y/jrzKolUBagz3oAbEn0 yvLn2xv1MXtbpOgj1BSpuqp3ZRC59xoZprPMDNrcUuSgtkXbEKpyhHLzk7GYrOwmPuL/ JlKLJqYDKY/HxzSPS2VFHVLpGZW7AEZDghmLEJPIqqCC2/sC6+4HQ3YJmWnK9z6lCqyG YatczKgFBCtf8jIZIGffg2nG4igEGAPaMTGz/i3fU7ba+IdzRyqiucgkKj4aZQq/KdPL +bzFVsPLIB8MkYYOcC+WcmdU9eueq/6vNL+GWHHCWi4wTFwHB/1uUa79BVuxWLAA8MQL aAJQ== MIME-Version: 1.0 Received: by 10.236.155.71 with SMTP id i47mr1324512yhk.72.1349258965235; Wed, 03 Oct 2012 03:09:25 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Wed, 3 Oct 2012 03:09:25 -0700 (PDT) Date: Wed, 3 Oct 2012 13:09:25 +0300 Message-ID: From: Valtteri Kiviniemi To: Xen-devel@lists.xen.org Subject: [Xen-devel] Xen 4.2.0, xl toolstack cant launch older domUs X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1558911241681224206==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============1558911241681224206== Content-Type: multipart/alternative; boundary=20cf303b42695537b604cb24d520 --20cf303b42695537b604cb24d520 Content-Type: text/plain; charset=ISO-8859-1 Hi, I just upgraded to Xen 4.2.0 and after some problems I got everything working except my older legacy domU's. I still have some old domU's ported from Xen 3.0.4 which are running Debian etch and kernel 2.6.16.33-xen. When I try to launch them with xl create I get the following error messages: root@xen-2:/# xl create /etc/xen/lightning.cfg -c Daemon running with PID 5453 libxl: error: libxl_dom.c:34:libxl__domain_type: unable to get domain type for domid=10 Unable to attach console libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: console child [0] exited with error status 1 If I try to launch it without the -c parameter it seems to start but it actually goes into some kind of bootloop. /var/log/xen/xl-lightning.log is looping these error messages: root@xen-2:/var/log/xen# cat xl-lightning.log Waiting for domain lightning (domid 132) to die [pid 24083] Domain 132 has shut down, reason code 3 0x3 Action for shutdown reason code 3 is restart Domain 132 needs to be cleaned up: destroying the domain Done. Rebooting now Waiting for domain lightning (domid 134) to die [pid 24083] Domain 134 has shut down, reason code 3 0x3 Action for shutdown reason code 3 is restart Domain 134 needs to be cleaned up: destroying the domain Done. Rebooting now If I start xend and use xm create the domU will start up just fine with no problems. - Valtteri --20cf303b42695537b604cb24d520 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I just upgraded to Xen 4.2.0 and after some problems I got every= thing working except my older legacy domU's. I still have some old domU= 's ported from Xen 3.0.4 which are running Debian etch and kernel 2.6.1= 6.33-xen. When I try to launch them with xl create I get the following erro= r messages:

root@xen-2:/# xl create /etc/xen/lightning.cfg -c
Daemon running wit= h PID 5453
libxl: error: libxl_dom.c:34:libxl__domain_type: unable to ge= t domain type for domid=3D10
Unable to attach console
libxl: error: l= ibxl_exec.c:118:libxl_report_child_exitstatus: console child [0] exited wit= h error status 1

If I try to launch it without the -c parameter it seems to start but it= actually goes into some kind of bootloop. /var/log/xen/xl-lightning.log is= looping these error messages:

root@xen-2:/var/log/xen# cat xl-light= ning.log
Waiting for domain lightning (domid 132) to die [pid 24083]
Domain 132 h= as shut down, reason code 3 0x3
Action for shutdown reason code 3 is res= tart
Domain 132 needs to be cleaned up: destroying the domain
Done. R= ebooting now
Waiting for domain lightning (domid 134) to die [pid 24083]
Domain 134 h= as shut down, reason code 3 0x3
Action for shutdown reason code 3 is res= tart
Domain 134 needs to be cleaned up: destroying the domain
Done. R= ebooting now

If I start xend and use xm create the domU will start up just fine with= no problems.

- Valtteri


--20cf303b42695537b604cb24d520-- --===============1558911241681224206== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============1558911241681224206==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 10:19:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 10:19:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJM2l-0005fX-Jw; Wed, 03 Oct 2012 10:19:07 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJM2j-0005fS-VB for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 10:19:06 +0000 Received: from [85.158.137.99:44844] by server-5.bemta-3.messagelabs.com id D0/7F-00589-9111C605; Wed, 03 Oct 2012 10:19:05 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-11.tower-217.messagelabs.com!1349259544!18889543!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24680 invoked from network); 3 Oct 2012 10:19:04 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 10:19:04 -0000 X-IronPort-AV: E=Sophos;i="4.80,527,1344211200"; d="scan'208";a="14911468" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 10:19:04 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 11:19:04 +0100 Message-ID: <1349259542.650.122.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Valtteri Kiviniemi Date: Wed, 3 Oct 2012 11:19:02 +0100 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Xen 4.2.0, xl toolstack cant launch older domUs X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-10-03 at 11:09 +0100, Valtteri Kiviniemi wrote: > root@xen-2:/var/log/xen# cat xl-lightning.log > Waiting for domain lightning (domid 132) to die [pid 24083] > Domain 132 has shut down, reason code 3 0x3 Reason code 3 is SHUTDOWN_crash. Please can you try to enable guest console logging as described at http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen#Guest_console_logs and see if the kernel prints anything at all. I'm not sure if such an old kernel has this option but you could also add "earlyprintk=xen" to the guest command line. Do you get any output in the hypervisor dmesg? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 10:19:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 10:19:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJM2l-0005fX-Jw; Wed, 03 Oct 2012 10:19:07 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJM2j-0005fS-VB for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 10:19:06 +0000 Received: from [85.158.137.99:44844] by server-5.bemta-3.messagelabs.com id D0/7F-00589-9111C605; Wed, 03 Oct 2012 10:19:05 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-11.tower-217.messagelabs.com!1349259544!18889543!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24680 invoked from network); 3 Oct 2012 10:19:04 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 10:19:04 -0000 X-IronPort-AV: E=Sophos;i="4.80,527,1344211200"; d="scan'208";a="14911468" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 10:19:04 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 11:19:04 +0100 Message-ID: <1349259542.650.122.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Valtteri Kiviniemi Date: Wed, 3 Oct 2012 11:19:02 +0100 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Xen 4.2.0, xl toolstack cant launch older domUs X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-10-03 at 11:09 +0100, Valtteri Kiviniemi wrote: > root@xen-2:/var/log/xen# cat xl-lightning.log > Waiting for domain lightning (domid 132) to die [pid 24083] > Domain 132 has shut down, reason code 3 0x3 Reason code 3 is SHUTDOWN_crash. Please can you try to enable guest console logging as described at http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen#Guest_console_logs and see if the kernel prints anything at all. I'm not sure if such an old kernel has this option but you could also add "earlyprintk=xen" to the guest command line. Do you get any output in the hypervisor dmesg? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 10:24:24 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 10:24:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJM7c-0005sJ-LS; Wed, 03 Oct 2012 10:24:08 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJM7b-0005sA-5i for Xen-devel@lists.xensource.com; Wed, 03 Oct 2012 10:24:07 +0000 Received: from [85.158.139.211:10409] by server-1.bemta-5.messagelabs.com id F1/40-09825-6421C605; Wed, 03 Oct 2012 10:24:06 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-10.tower-206.messagelabs.com!1349259845!20864244!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22169 invoked from network); 3 Oct 2012 10:24:06 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 10:24:06 -0000 X-IronPort-AV: E=Sophos;i="4.80,527,1344211200"; d="scan'208";a="14911551" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 10:24:05 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 11:24:05 +0100 Message-ID: <1349259844.650.123.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Mukesh Rathor Date: Wed, 3 Oct 2012 11:24:04 +0100 In-Reply-To: <20121002115552.3a5d5196@mantra.us.oracle.com> References: <20120921121202.3163c379@mantra.us.oracle.com> <1348581263.11229.21.camel@zakaz.uk.xensource.com> <20121001142826.1ebf7b0f@mantra.us.oracle.com> <20121002130911.GD9009@phenom.dumpdata.com> <20121002115552.3a5d5196@mantra.us.oracle.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 0/8]: PVH (PV guest with extensions) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-10-02 at 19:55 +0100, Mukesh Rathor wrote: > On Tue, 2 Oct 2012 09:09:11 -0400 > Konrad Rzeszutek Wilk wrote: > > > On Mon, Oct 01, 2012 at 02:28:26PM -0700, Mukesh Rathor wrote: > > > On Tue, 25 Sep 2012 14:54:23 +0100 > > > Ian Campbell wrote: > > > > > > > On Fri, 2012-09-21 at 20:12 +0100, Mukesh Rathor wrote: > > > > > Hi guys, > > > > > > > > > > Ok, I've made all the changes from prev RFC patch submission. > > > > > > > > Did I miss the patch with the changes to arch/x86/xen/xen-head.S > > > > which declare the features which are used here as supported by > > > > the kernel image? > > > > > > > > Ian. > > > > > > > > > > Strange, adding following to head.S > > > > > > ELFNOTE(Xen, XEN_ELFNOTE_PADDR_OFFSET, _ASM_PTR 0) > > > ELFNOTE(Xen, XEN_ELFNOTE_GUEST_PVH, .long 1) <-------- > > > > > > and xenstore won't start in dom0. What gives? > > > > What is XEN_ELFNOTE_GUEST_PVH number? You might be re-using a value > > that is defined for a different purpose? Did you check the Xen > > hypervisor header files? > > Ah, right. I was looking at linux header file, which is behind xen. Phew! You are going to add the other features which PVH uses too, right? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 10:24:24 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 10:24:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJM7c-0005sJ-LS; Wed, 03 Oct 2012 10:24:08 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJM7b-0005sA-5i for Xen-devel@lists.xensource.com; Wed, 03 Oct 2012 10:24:07 +0000 Received: from [85.158.139.211:10409] by server-1.bemta-5.messagelabs.com id F1/40-09825-6421C605; Wed, 03 Oct 2012 10:24:06 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-10.tower-206.messagelabs.com!1349259845!20864244!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22169 invoked from network); 3 Oct 2012 10:24:06 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 10:24:06 -0000 X-IronPort-AV: E=Sophos;i="4.80,527,1344211200"; d="scan'208";a="14911551" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 10:24:05 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 11:24:05 +0100 Message-ID: <1349259844.650.123.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Mukesh Rathor Date: Wed, 3 Oct 2012 11:24:04 +0100 In-Reply-To: <20121002115552.3a5d5196@mantra.us.oracle.com> References: <20120921121202.3163c379@mantra.us.oracle.com> <1348581263.11229.21.camel@zakaz.uk.xensource.com> <20121001142826.1ebf7b0f@mantra.us.oracle.com> <20121002130911.GD9009@phenom.dumpdata.com> <20121002115552.3a5d5196@mantra.us.oracle.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 0/8]: PVH (PV guest with extensions) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-10-02 at 19:55 +0100, Mukesh Rathor wrote: > On Tue, 2 Oct 2012 09:09:11 -0400 > Konrad Rzeszutek Wilk wrote: > > > On Mon, Oct 01, 2012 at 02:28:26PM -0700, Mukesh Rathor wrote: > > > On Tue, 25 Sep 2012 14:54:23 +0100 > > > Ian Campbell wrote: > > > > > > > On Fri, 2012-09-21 at 20:12 +0100, Mukesh Rathor wrote: > > > > > Hi guys, > > > > > > > > > > Ok, I've made all the changes from prev RFC patch submission. > > > > > > > > Did I miss the patch with the changes to arch/x86/xen/xen-head.S > > > > which declare the features which are used here as supported by > > > > the kernel image? > > > > > > > > Ian. > > > > > > > > > > Strange, adding following to head.S > > > > > > ELFNOTE(Xen, XEN_ELFNOTE_PADDR_OFFSET, _ASM_PTR 0) > > > ELFNOTE(Xen, XEN_ELFNOTE_GUEST_PVH, .long 1) <-------- > > > > > > and xenstore won't start in dom0. What gives? > > > > What is XEN_ELFNOTE_GUEST_PVH number? You might be re-using a value > > that is defined for a different purpose? Did you check the Xen > > hypervisor header files? > > Ah, right. I was looking at linux header file, which is behind xen. Phew! You are going to add the other features which PVH uses too, right? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 10:33:22 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 10:33:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJMGI-00066I-RH; Wed, 03 Oct 2012 10:33:06 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJMGG-00066B-R1 for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 10:33:05 +0000 Received: from [85.158.139.83:47540] by server-3.bemta-5.messagelabs.com id 21/6E-16108-0641C605; Wed, 03 Oct 2012 10:33:04 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1349260381!28928716!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6825 invoked from network); 3 Oct 2012 10:33:03 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 10:33:03 -0000 X-IronPort-AV: E=Sophos;i="4.80,527,1344211200"; d="scan'208";a="14911772" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 10:32:58 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 11:32:59 +0100 Message-ID: <1349260377.650.124.camel@zakaz.uk.xensource.com> From: Ian Campbell To: "xen-devel@lists.xensource.com" Date: Wed, 3 Oct 2012 11:32:57 +0100 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: Keir Fraser Subject: Re: [Xen-devel] [Xen-staging] [xen-unstable] MAINTAINERS: Matthew Fioravante now maintains VTPM X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-10-03 at 11:22 +0100, Xen patchbot-unstable wrote: > # HG changeset patch > # User Matthew Fioravante > # Date 1349259234 -3600 > # Node ID 59dc1c2e7c54315f6442cca48bb7b7486612e84e > # Parent 8bd7dbcb513db86de032ad0226a561eba9a05ab0 > MAINTAINERS: Matthew Fioravante now maintains VTPM > > Signed-off-by: Matthew Fioravante > Committed-by: Keir Fraser Looks like you missed v2 which put the entry in the right alphabetical location and added the trailing /'s to the directory entries. <1349186658-14536-1-git-send-email-matthew.fioravante@jhuapl.edu> Ian. > --- > > > diff -r 8bd7dbcb513d -r 59dc1c2e7c54 MAINTAINERS > --- a/MAINTAINERS Wed Oct 03 11:11:35 2012 +0100 > +++ b/MAINTAINERS Wed Oct 03 11:13:54 2012 +0100 > @@ -261,6 +261,21 @@ S: Supported > F: tools/xentrace/ > F: xen/common/trace.c > > +VTPM > +M: Matthew Fioravante > +S: Supported > +F: tools/vtpm > +F: tools/vtpm_manager > +F: extras/minios-os/tpmfront.c > +F: extras/minios-os/tpmback.c > +F: extras/minios-os/tpm-tis.c > +F: extras/minios-os/include/tpmfront.h > +F: extras/minios-os/include/tpmback.h > +F: extras/minios-os/include/tpm-tis.h > +F: stubdom/vtpm > +F: stubdom/vtpmmgr > +F: docs/misc/vtpm.txt > + > THE REST > M: Keir Fraser > L: xen-devel@lists.xen.org > > _______________________________________________ > Xen-staging mailing list > Xen-staging@lists.xen.org > http://lists.xensource.com/xen-staging _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 10:33:22 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 10:33:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJMGI-00066I-RH; Wed, 03 Oct 2012 10:33:06 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJMGG-00066B-R1 for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 10:33:05 +0000 Received: from [85.158.139.83:47540] by server-3.bemta-5.messagelabs.com id 21/6E-16108-0641C605; Wed, 03 Oct 2012 10:33:04 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1349260381!28928716!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6825 invoked from network); 3 Oct 2012 10:33:03 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 10:33:03 -0000 X-IronPort-AV: E=Sophos;i="4.80,527,1344211200"; d="scan'208";a="14911772" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 10:32:58 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 11:32:59 +0100 Message-ID: <1349260377.650.124.camel@zakaz.uk.xensource.com> From: Ian Campbell To: "xen-devel@lists.xensource.com" Date: Wed, 3 Oct 2012 11:32:57 +0100 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: Keir Fraser Subject: Re: [Xen-devel] [Xen-staging] [xen-unstable] MAINTAINERS: Matthew Fioravante now maintains VTPM X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-10-03 at 11:22 +0100, Xen patchbot-unstable wrote: > # HG changeset patch > # User Matthew Fioravante > # Date 1349259234 -3600 > # Node ID 59dc1c2e7c54315f6442cca48bb7b7486612e84e > # Parent 8bd7dbcb513db86de032ad0226a561eba9a05ab0 > MAINTAINERS: Matthew Fioravante now maintains VTPM > > Signed-off-by: Matthew Fioravante > Committed-by: Keir Fraser Looks like you missed v2 which put the entry in the right alphabetical location and added the trailing /'s to the directory entries. <1349186658-14536-1-git-send-email-matthew.fioravante@jhuapl.edu> Ian. > --- > > > diff -r 8bd7dbcb513d -r 59dc1c2e7c54 MAINTAINERS > --- a/MAINTAINERS Wed Oct 03 11:11:35 2012 +0100 > +++ b/MAINTAINERS Wed Oct 03 11:13:54 2012 +0100 > @@ -261,6 +261,21 @@ S: Supported > F: tools/xentrace/ > F: xen/common/trace.c > > +VTPM > +M: Matthew Fioravante > +S: Supported > +F: tools/vtpm > +F: tools/vtpm_manager > +F: extras/minios-os/tpmfront.c > +F: extras/minios-os/tpmback.c > +F: extras/minios-os/tpm-tis.c > +F: extras/minios-os/include/tpmfront.h > +F: extras/minios-os/include/tpmback.h > +F: extras/minios-os/include/tpm-tis.h > +F: stubdom/vtpm > +F: stubdom/vtpmmgr > +F: docs/misc/vtpm.txt > + > THE REST > M: Keir Fraser > L: xen-devel@lists.xen.org > > _______________________________________________ > Xen-staging mailing list > Xen-staging@lists.xen.org > http://lists.xensource.com/xen-staging _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 10:34:11 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 10:34:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJMH8-00069d-98; Wed, 03 Oct 2012 10:33:58 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJMH7-00069U-7c for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 10:33:57 +0000 Received: from [85.158.139.83:20400] by server-11.bemta-5.messagelabs.com id 2F/79-13866-4941C605; Wed, 03 Oct 2012 10:33:56 +0000 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1349260435!31008554!1 X-Originating-IP: [74.125.83.43] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5864 invoked from network); 3 Oct 2012 10:33:55 -0000 Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com) (74.125.83.43) by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 10:33:55 -0000 Received: by eekc13 with SMTP id c13so3937853eek.30 for ; Wed, 03 Oct 2012 03:33:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=FggUsjef0DfG/3nenL/8b3Qb3en6YIz8mcF3uyTZ8po=; b=ZDlIQu3i9WOviu1KuNKCfIXaeNQStIcYxcUk6OJ2O5v8rBTMjGN3EOW1jCrsCWd3ze 0Ufx+00Q7368AnX5Eeb4jyvB0v87tuuqQ9jH/8YdKbZ973e8fdpqo6fJ0ezwtmUccabn DpGqwifc0UJCt9jQMUza+sG987BuhBRrJjprKcvXIVQWR+Bne9gsVd7ql6mDWNN8awd0 o5ENQm5KX1o2yLoyEvczxE4dZu+DtpQO1wVjL9F5TdoIWxvQuSZRLgV6J/iv0Gi/8n/K 0GfnedXeRd+Fep+vVKo9cbMc803ntahDiNvMXTd5Sl/Dgh4OnjfkwGO69O0aDXwQlZEX rnhA== MIME-Version: 1.0 Received: by 10.14.4.201 with SMTP id 49mr2071783eej.0.1349260435611; Wed, 03 Oct 2012 03:33:55 -0700 (PDT) Received: by 10.14.215.195 with HTTP; Wed, 3 Oct 2012 03:33:55 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Oct 2012 11:33:55 +0100 X-Google-Sender-Auth: 8VHF4Oq4MUIwkkwM9YrWvy3bLTo Message-ID: From: George Dunlap To: David Vrabel Cc: xen-devel@lists.xensource.com, George Dunlap Subject: Re: [Xen-devel] [PATCH 1 of 2] xenalyze: decode PV_HYPERCALL_V2 records X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, Oct 1, 2012 at 6:52 PM, David Vrabel wrote: > Newer version of Xen produce TRC_PV_HYPERCALL_V2 records instead of > the older TRC_PV_HYPERCALL format. This updated format doesn't > included the IP but it does include select hypercall arguments. > > Signed-off-by: David Vrabel Thanks -- I did a bunch of optimization work on xenalyze late last year, so I'm afraid I'm going to be pretty picky about some things to avoid losing that effort. :-) > diff --git a/pv.h b/pv.h > new file mode 100644 > --- /dev/null > +++ b/pv.h > @@ -0,0 +1,41 @@ > +/* > + * PV event decoding. > + * > + * Copyright (C) 2012 Citrix Systems R&D Ltd. > + * > + * This program is free software; you can redistribute it and/or modify it > + * under the terms and conditions of the GNU General Public License, > + * version 2, as published by the Free Software Foundation. > + */ > +#ifndef __PV_H > + > +#include "analyze.h" > +#include "trace.h" > + > +#ifdef __cplusplus > +extern "C" { > +#endif > + > +#define ARG_MISSING 0x0 > +#define ARG_32BIT 0x1 > +#define ARG_64BIT 0x2 > + > +#define MMU_UPDATE_PREEMPTED (~(~0U>>1)) > + > +static inline uint32_t pv_hypercall_op(const struct record_info *ri) > +{ > + return ri->d[0] & ~TRC_PV_HYPERCALL_V2_ARG_MASK; > +} > + > +static inline int pv_hypercall_arg_present(const struct record_info *ri, int arg) > +{ > + return (ri->d[0] >> (20 + 2*arg)) & 0x3; > +} Try to avoid an integer multiply here; (arg<<1) or (arg+arg) please. > @@ -6523,6 +6537,168 @@ void pv_summary(struct pv_data *pv) { > } > } > > +uint64_t pv_hypercall_arg(const struct record_info *ri, int arg) > +{ > + int i, word; > + > + for (i = 0, word = 1; i < 6 && word < ri->extra_words; i++) { > + int present = pv_hypercall_arg_present(ri, i); > + > + /* Is this the argument we're looking for? */ > + if (i == arg) { > + switch (present) { > + case ARG_MISSING: > + return 0; > + case ARG_32BIT: > + return ri->d[word]; > + case ARG_64BIT: > + return ((uint64_t)ri->d[word + 1] << 32) | ri->d[word]; > + } > + } > + > + /* Skip over any words for this argument. */ > + word += present; > + } So at the moment, this is only called if you're in dump mode, which is fairly slow already; but it may at some point be called in summary mode, which I'd like to keep pretty fast. This little loop will basically be O(n^2) with the number of recorded arguments. Since we're expecting the hypercall arguments xenalyze asks for to match the arguments put into the trace, it seems like we should be able to do better. Would it make sense to do something like pass in an array of what arguments it expects to get, and then have the function double-check that they match properly, and then replaces the "expected argument number" with "traced value" (returning an error if they don't match)? Alternately, since pv_hypercall_arg() returns 0 for a non-existent arg anyway, couldn't you have an array, initialized to 0, and filled in as appropriate? > +static void pv_hypercall_print_args(const struct record_info *ri) > +{ > + int i, word; > + > + for (i = 0, word = 1; i < 6 && word < ri->extra_words; i++) { > + int present = pv_hypercall_arg_present(ri, i); > + > + switch (present) { > + case ARG_MISSING: > + printf(" ??"); > + break; > + case ARG_32BIT: > + printf(" %08x", ri->d[word]); > + break; > + case ARG_64BIT: > + printf(" %016"PRIu64"", ((uint64_t)ri->d[word + 1] << 32) | ri->d[word]); > + break; > + } > + > + word += present; > + } > +} > + > +static const char *grant_table_op_cmd_to_str(uint32_t cmd) > +{ > + const char *cmd_str[] = { > + "map_grant_ref", "unmap_grant_ref", "setup_table", "dump_table", > + "transfer", "copy", "query_size", "unmap_and_replace", > + "set_version", "get_status_frames", "get_version", "swap_grant_ref", > + }; > + static char buf[32]; > + > + if (cmd <= 11) > + return cmd_str[cmd]; > + > + snprintf(buf, sizeof(buf), "unknown (%d)", cmd); Just FYI, in my analysis, time spent in libc's vprintf() takes up the vast majority of the time of xenalyze's dump mode -- even just doing things like printing %s (which you would think would be more or less a strcpy). In this case (and the others in this patch) the sprintf() should be the uncommon case, so they're fine. But just a heads-up that I'll be picky about sprintfs() in hot paths. :-) Thanks, -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 10:34:11 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 10:34:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJMH8-00069d-98; Wed, 03 Oct 2012 10:33:58 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJMH7-00069U-7c for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 10:33:57 +0000 Received: from [85.158.139.83:20400] by server-11.bemta-5.messagelabs.com id 2F/79-13866-4941C605; Wed, 03 Oct 2012 10:33:56 +0000 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1349260435!31008554!1 X-Originating-IP: [74.125.83.43] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5864 invoked from network); 3 Oct 2012 10:33:55 -0000 Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com) (74.125.83.43) by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 10:33:55 -0000 Received: by eekc13 with SMTP id c13so3937853eek.30 for ; Wed, 03 Oct 2012 03:33:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=FggUsjef0DfG/3nenL/8b3Qb3en6YIz8mcF3uyTZ8po=; b=ZDlIQu3i9WOviu1KuNKCfIXaeNQStIcYxcUk6OJ2O5v8rBTMjGN3EOW1jCrsCWd3ze 0Ufx+00Q7368AnX5Eeb4jyvB0v87tuuqQ9jH/8YdKbZ973e8fdpqo6fJ0ezwtmUccabn DpGqwifc0UJCt9jQMUza+sG987BuhBRrJjprKcvXIVQWR+Bne9gsVd7ql6mDWNN8awd0 o5ENQm5KX1o2yLoyEvczxE4dZu+DtpQO1wVjL9F5TdoIWxvQuSZRLgV6J/iv0Gi/8n/K 0GfnedXeRd+Fep+vVKo9cbMc803ntahDiNvMXTd5Sl/Dgh4OnjfkwGO69O0aDXwQlZEX rnhA== MIME-Version: 1.0 Received: by 10.14.4.201 with SMTP id 49mr2071783eej.0.1349260435611; Wed, 03 Oct 2012 03:33:55 -0700 (PDT) Received: by 10.14.215.195 with HTTP; Wed, 3 Oct 2012 03:33:55 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Oct 2012 11:33:55 +0100 X-Google-Sender-Auth: 8VHF4Oq4MUIwkkwM9YrWvy3bLTo Message-ID: From: George Dunlap To: David Vrabel Cc: xen-devel@lists.xensource.com, George Dunlap Subject: Re: [Xen-devel] [PATCH 1 of 2] xenalyze: decode PV_HYPERCALL_V2 records X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, Oct 1, 2012 at 6:52 PM, David Vrabel wrote: > Newer version of Xen produce TRC_PV_HYPERCALL_V2 records instead of > the older TRC_PV_HYPERCALL format. This updated format doesn't > included the IP but it does include select hypercall arguments. > > Signed-off-by: David Vrabel Thanks -- I did a bunch of optimization work on xenalyze late last year, so I'm afraid I'm going to be pretty picky about some things to avoid losing that effort. :-) > diff --git a/pv.h b/pv.h > new file mode 100644 > --- /dev/null > +++ b/pv.h > @@ -0,0 +1,41 @@ > +/* > + * PV event decoding. > + * > + * Copyright (C) 2012 Citrix Systems R&D Ltd. > + * > + * This program is free software; you can redistribute it and/or modify it > + * under the terms and conditions of the GNU General Public License, > + * version 2, as published by the Free Software Foundation. > + */ > +#ifndef __PV_H > + > +#include "analyze.h" > +#include "trace.h" > + > +#ifdef __cplusplus > +extern "C" { > +#endif > + > +#define ARG_MISSING 0x0 > +#define ARG_32BIT 0x1 > +#define ARG_64BIT 0x2 > + > +#define MMU_UPDATE_PREEMPTED (~(~0U>>1)) > + > +static inline uint32_t pv_hypercall_op(const struct record_info *ri) > +{ > + return ri->d[0] & ~TRC_PV_HYPERCALL_V2_ARG_MASK; > +} > + > +static inline int pv_hypercall_arg_present(const struct record_info *ri, int arg) > +{ > + return (ri->d[0] >> (20 + 2*arg)) & 0x3; > +} Try to avoid an integer multiply here; (arg<<1) or (arg+arg) please. > @@ -6523,6 +6537,168 @@ void pv_summary(struct pv_data *pv) { > } > } > > +uint64_t pv_hypercall_arg(const struct record_info *ri, int arg) > +{ > + int i, word; > + > + for (i = 0, word = 1; i < 6 && word < ri->extra_words; i++) { > + int present = pv_hypercall_arg_present(ri, i); > + > + /* Is this the argument we're looking for? */ > + if (i == arg) { > + switch (present) { > + case ARG_MISSING: > + return 0; > + case ARG_32BIT: > + return ri->d[word]; > + case ARG_64BIT: > + return ((uint64_t)ri->d[word + 1] << 32) | ri->d[word]; > + } > + } > + > + /* Skip over any words for this argument. */ > + word += present; > + } So at the moment, this is only called if you're in dump mode, which is fairly slow already; but it may at some point be called in summary mode, which I'd like to keep pretty fast. This little loop will basically be O(n^2) with the number of recorded arguments. Since we're expecting the hypercall arguments xenalyze asks for to match the arguments put into the trace, it seems like we should be able to do better. Would it make sense to do something like pass in an array of what arguments it expects to get, and then have the function double-check that they match properly, and then replaces the "expected argument number" with "traced value" (returning an error if they don't match)? Alternately, since pv_hypercall_arg() returns 0 for a non-existent arg anyway, couldn't you have an array, initialized to 0, and filled in as appropriate? > +static void pv_hypercall_print_args(const struct record_info *ri) > +{ > + int i, word; > + > + for (i = 0, word = 1; i < 6 && word < ri->extra_words; i++) { > + int present = pv_hypercall_arg_present(ri, i); > + > + switch (present) { > + case ARG_MISSING: > + printf(" ??"); > + break; > + case ARG_32BIT: > + printf(" %08x", ri->d[word]); > + break; > + case ARG_64BIT: > + printf(" %016"PRIu64"", ((uint64_t)ri->d[word + 1] << 32) | ri->d[word]); > + break; > + } > + > + word += present; > + } > +} > + > +static const char *grant_table_op_cmd_to_str(uint32_t cmd) > +{ > + const char *cmd_str[] = { > + "map_grant_ref", "unmap_grant_ref", "setup_table", "dump_table", > + "transfer", "copy", "query_size", "unmap_and_replace", > + "set_version", "get_status_frames", "get_version", "swap_grant_ref", > + }; > + static char buf[32]; > + > + if (cmd <= 11) > + return cmd_str[cmd]; > + > + snprintf(buf, sizeof(buf), "unknown (%d)", cmd); Just FYI, in my analysis, time spent in libc's vprintf() takes up the vast majority of the time of xenalyze's dump mode -- even just doing things like printing %s (which you would think would be more or less a strcpy). In this case (and the others in this patch) the sprintf() should be the uncommon case, so they're fine. But just a heads-up that I'll be picky about sprintfs() in hot paths. :-) Thanks, -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 10:36:09 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 10:36:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJMJ2-0006ID-QG; Wed, 03 Oct 2012 10:35:56 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJMJ1-0006I0-S5 for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 10:35:56 +0000 Received: from [85.158.139.83:11656] by server-16.bemta-5.messagelabs.com id B6/21-05998-B051C605; Wed, 03 Oct 2012 10:35:55 +0000 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1349260554!29250035!1 X-Originating-IP: [74.125.83.43] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4561 invoked from network); 3 Oct 2012 10:35:54 -0000 Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com) (74.125.83.43) by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 10:35:54 -0000 Received: by eekc13 with SMTP id c13so3939839eek.30 for ; Wed, 03 Oct 2012 03:35:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=3tP3QFwbYDJuT+F0a9uLEBgoRfO/HGkpseWtA1c+RRk=; b=OL3ouzlRLPheSmP6TXLWzc9yENdzPEvv5Vt1nDnyx/16m2YvZ1Vwv+jCcQ/9bDoDKi mb6Af7pSQRufyS3uwhTto/TDrWLzZBKVNUlimTnDpPTESnPy4F+mY2o4PTXzJoYEBav3 Y3XhZKGFTpUH7fGBcupdJ7yKJnVzkmPDpY7x8huWeKCDeAb3YgTfvUWFmr7zp4+EkwD9 MOoN++c8xGD1AwwqLkC+ffOIB2SMgydwf5R4SoF8hd7ok/UkuOn8O6a8zE7Spwa9I1r3 bQ8qBVGulSrkj0fqeuK1I7NMv4eOmrr2R4+88LCv/U9qZREQvigefTq9vzGoMv4c714H rFkA== MIME-Version: 1.0 Received: by 10.14.209.129 with SMTP id s1mr2001371eeo.24.1349260554336; Wed, 03 Oct 2012 03:35:54 -0700 (PDT) Received: by 10.14.215.195 with HTTP; Wed, 3 Oct 2012 03:35:54 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Oct 2012 11:35:54 +0100 X-Google-Sender-Auth: QgvUO-QPPk5X7xMIBdC4Oj5ErGg Message-ID: From: George Dunlap To: David Vrabel Cc: xen-devel@lists.xensource.com, George Dunlap Subject: Re: [Xen-devel] [PATCH 2 of 2] xenalyze: decode PV_HYPERCALL_SUBCALL events X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, Oct 1, 2012 at 6:52 PM, David Vrabel wrote: > Decode the PV_HYPERCALL_SUBCALL events which are used for calls within > a multicall hypercall. They are indented so its easier to see which > multicall they were part of. > > Signed-off-by: David Vrabel Acked-by: George Dunlap > --- > > diff --git a/xenalyze.c b/xenalyze.c > --- a/xenalyze.c > +++ b/xenalyze.c > @@ -1487,6 +1487,7 @@ enum { > PV_PTWR_EMULATION, > PV_PTWR_EMULATION_PAE, > PV_HYPERCALL_V2 = 13, > + PV_HYPERCALL_SUBCALL = 14, > PV_MAX > }; > > @@ -6635,7 +6636,8 @@ static const char *sched_op_cmd_to_str(u > return buf; > } > > -void pv_hypercall_v2_process(struct record_info *ri, struct pv_data *pv) > +void pv_hypercall_v2_process(struct record_info *ri, struct pv_data *pv, > + const char *indent) > { > int op = pv_hypercall_op(ri); > > @@ -6646,11 +6648,11 @@ void pv_hypercall_v2_process(struct reco > > if(opt.dump_all) { > if(op < HYPERCALL_MAX) > - printf(" %s hypercall %2x (%s)", > - ri->dump_header, op, hypercall_name[op]); > + printf(" %s%s hypercall %2x (%s)", > + ri->dump_header, indent, op, hypercall_name[op]); > else > - printf(" %s hypercall %2x", > - ri->dump_header, op); > + printf(" %s%s hypercall %2x", > + ri->dump_header, indent, op); > switch(op) { > case HYPERCALL_mmu_update: > { > @@ -6732,7 +6734,10 @@ void pv_process(struct pcpu_info *p) > pv_ptwr_emulation_process(ri, pv); > break; > case PV_HYPERCALL_V2: > - pv_hypercall_v2_process(ri, pv); > + pv_hypercall_v2_process(ri, pv, ""); > + break; > + case PV_HYPERCALL_SUBCALL: > + pv_hypercall_v2_process(ri, pv, " "); > break; > default: > pv_generic_process(ri, pv); > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 10:36:09 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 10:36:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJMJ2-0006ID-QG; Wed, 03 Oct 2012 10:35:56 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJMJ1-0006I0-S5 for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 10:35:56 +0000 Received: from [85.158.139.83:11656] by server-16.bemta-5.messagelabs.com id B6/21-05998-B051C605; Wed, 03 Oct 2012 10:35:55 +0000 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1349260554!29250035!1 X-Originating-IP: [74.125.83.43] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4561 invoked from network); 3 Oct 2012 10:35:54 -0000 Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com) (74.125.83.43) by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 10:35:54 -0000 Received: by eekc13 with SMTP id c13so3939839eek.30 for ; Wed, 03 Oct 2012 03:35:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=3tP3QFwbYDJuT+F0a9uLEBgoRfO/HGkpseWtA1c+RRk=; b=OL3ouzlRLPheSmP6TXLWzc9yENdzPEvv5Vt1nDnyx/16m2YvZ1Vwv+jCcQ/9bDoDKi mb6Af7pSQRufyS3uwhTto/TDrWLzZBKVNUlimTnDpPTESnPy4F+mY2o4PTXzJoYEBav3 Y3XhZKGFTpUH7fGBcupdJ7yKJnVzkmPDpY7x8huWeKCDeAb3YgTfvUWFmr7zp4+EkwD9 MOoN++c8xGD1AwwqLkC+ffOIB2SMgydwf5R4SoF8hd7ok/UkuOn8O6a8zE7Spwa9I1r3 bQ8qBVGulSrkj0fqeuK1I7NMv4eOmrr2R4+88LCv/U9qZREQvigefTq9vzGoMv4c714H rFkA== MIME-Version: 1.0 Received: by 10.14.209.129 with SMTP id s1mr2001371eeo.24.1349260554336; Wed, 03 Oct 2012 03:35:54 -0700 (PDT) Received: by 10.14.215.195 with HTTP; Wed, 3 Oct 2012 03:35:54 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Oct 2012 11:35:54 +0100 X-Google-Sender-Auth: QgvUO-QPPk5X7xMIBdC4Oj5ErGg Message-ID: From: George Dunlap To: David Vrabel Cc: xen-devel@lists.xensource.com, George Dunlap Subject: Re: [Xen-devel] [PATCH 2 of 2] xenalyze: decode PV_HYPERCALL_SUBCALL events X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, Oct 1, 2012 at 6:52 PM, David Vrabel wrote: > Decode the PV_HYPERCALL_SUBCALL events which are used for calls within > a multicall hypercall. They are indented so its easier to see which > multicall they were part of. > > Signed-off-by: David Vrabel Acked-by: George Dunlap > --- > > diff --git a/xenalyze.c b/xenalyze.c > --- a/xenalyze.c > +++ b/xenalyze.c > @@ -1487,6 +1487,7 @@ enum { > PV_PTWR_EMULATION, > PV_PTWR_EMULATION_PAE, > PV_HYPERCALL_V2 = 13, > + PV_HYPERCALL_SUBCALL = 14, > PV_MAX > }; > > @@ -6635,7 +6636,8 @@ static const char *sched_op_cmd_to_str(u > return buf; > } > > -void pv_hypercall_v2_process(struct record_info *ri, struct pv_data *pv) > +void pv_hypercall_v2_process(struct record_info *ri, struct pv_data *pv, > + const char *indent) > { > int op = pv_hypercall_op(ri); > > @@ -6646,11 +6648,11 @@ void pv_hypercall_v2_process(struct reco > > if(opt.dump_all) { > if(op < HYPERCALL_MAX) > - printf(" %s hypercall %2x (%s)", > - ri->dump_header, op, hypercall_name[op]); > + printf(" %s%s hypercall %2x (%s)", > + ri->dump_header, indent, op, hypercall_name[op]); > else > - printf(" %s hypercall %2x", > - ri->dump_header, op); > + printf(" %s%s hypercall %2x", > + ri->dump_header, indent, op); > switch(op) { > case HYPERCALL_mmu_update: > { > @@ -6732,7 +6734,10 @@ void pv_process(struct pcpu_info *p) > pv_ptwr_emulation_process(ri, pv); > break; > case PV_HYPERCALL_V2: > - pv_hypercall_v2_process(ri, pv); > + pv_hypercall_v2_process(ri, pv, ""); > + break; > + case PV_HYPERCALL_SUBCALL: > + pv_hypercall_v2_process(ri, pv, " "); > break; > default: > pv_generic_process(ri, pv); > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 10:37:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 10:37:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJMK7-0006PK-8b; Wed, 03 Oct 2012 10:37:03 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJMK5-0006PC-Sl for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 10:37:02 +0000 Received: from [85.158.137.99:33102] by server-10.bemta-3.messagelabs.com id 2C/5F-02525-C451C605; Wed, 03 Oct 2012 10:37:00 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-5.tower-217.messagelabs.com!1349260618!15348242!1 X-Originating-IP: [209.85.161.173] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26553 invoked from network); 3 Oct 2012 10:36:59 -0000 Received: from mail-gg0-f173.google.com (HELO mail-gg0-f173.google.com) (209.85.161.173) by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 10:36:59 -0000 Received: by ggcs5 with SMTP id s5so596281ggc.32 for ; Wed, 03 Oct 2012 03:36:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=03BOeqxZ1JTsVUtWNmx3RRNI7QSHzMxeIn6PQOH3ZW8=; b=0sYe+RiSEuVgRCTziAG07j0UAG/FqHBfLSHk8rohzHYYWd4mbu+LrfQu0BOq44a2As Uze0D60x+bMHFGJDGbEebuLlV3L7hLBxuj+OrSfuAEkJJ8p+FgpkIyMa/JQBnejVci5a 28qdM1fnCAGemn/FTUNHPtAaZ84HrJAfYfNd2IIAGCST9As53COBlBRF3fyzN+g7J0dr cGMTxD3sT56qgsZ9hWnHZvyi2GoDTTsXOp6bRwANSu3UO/OWKglLzXuGS8rJ0EMiCtVo MEsrY/n0cPpcLctymt4Z6OETd9LQLFS72C1hSpBtebwXa62sfxRMxzBT2AmJD4yJkzwK aFfg== MIME-Version: 1.0 Received: by 10.236.155.71 with SMTP id i47mr1371292yhk.72.1349260618468; Wed, 03 Oct 2012 03:36:58 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Wed, 3 Oct 2012 03:36:58 -0700 (PDT) In-Reply-To: References: <20121001164757.GF8912@reaktio.net> <20121001182437.GG8912@reaktio.net> <20121002121932.GL8912@reaktio.net> <20121002144251.GP8912@reaktio.net> Date: Wed, 3 Oct 2012 13:36:58 +0300 Message-ID: From: Valtteri Kiviniemi To: Konrad Rzeszutek Wilk Cc: Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.0.4, kernel 3.5.0 HVM crash and kernel BUG X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2078183613774764552==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============2078183613774764552== Content-Type: multipart/alternative; boundary=20cf303b4269df8e0a04cb253740 --20cf303b4269df8e0a04cb253740 Content-Type: text/plain; charset=ISO-8859-1 Hi, I enabled debugging, no new information available. DomU starts, VNC has black screen. No crashes so far. - Valtteri 2012/10/3 Valtteri Kiviniemi > Hi, > > I disabled NUMA and upgraded to Xen 4.2.0. Windows domU starts now fine > and I cant anymore reproduce the hotplug problems. VNC output is still just > black screen and it actually crashes the the whole VNC client when after a > few seconds. RealVNC just shuts itself down and tightvnc crashes. > > - Valtteri > > > > 2012/10/2 Valtteri Kiviniemi > >> Hi, >> >> Yes, they are all loaded and I'm running Linux PV-virtuals at the same >> time with no problems. Only HVM is not working. I have single socket corei7 >> processor and NUMA enabled on dom0 kernel, so I will try tomorrow to >> compile dom0 kernel without NUMA, since its not needed and it could >> probably cause some kind of memory related problems. >> >> I will also try Debian squeezes package Xen and test if it is working >> with my hardware. >> >> - Valtteri >> >> >> 2012/10/2 Konrad Rzeszutek Wilk >> >>> On Tue, Oct 2, 2012 at 10:55 AM, Valtteri Kiviniemi >>> wrote: >>> > Hi, >>> > >>> > Yes, I understood for what the parameters were for. I'ts been a long >>> time >>> > since I last had major problems with Xen (maybe 3.1 or something, been >>> using >>> > Xen since version 2) and I had a shady recollection that Xen was >>> required to >>> > be build debugging enabled in order to get any usable debugging data. >>> > >>> > But anyway, I cant reproduce that kernel crash everytime, it just >>> happens >>> > sometimes. Major problem is the black screen on VNC and second problem >>> seems >>> > to be that everytime i try to run Linux in HVM mode it somehow breaks >>> the >>> > hotplug scripts. >>> > >>> >>> So do you have all backends loaded? Is xen-netback and xen-blkback >>> running? >>> Do you also have tun loaded? >>> >> >> > --20cf303b4269df8e0a04cb253740 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I enabled debugging, no new information available. DomU starts, = VNC has black screen. No crashes so far.

- Valtteri

2012/10/3 Valtteri Kiviniemi <kiviniemi.valtt= eri@gmail.com>
Hi,

I disabled NUMA and upgraded to X= en 4.2.0. Windows domU starts now fine and I cant anymore reproduce the hot= plug problems. VNC output is still just black screen and it actually crashe= s the the whole VNC client when after a few seconds. RealVNC just shuts its= elf down and tightvnc crashes.

- Valtteri


2012/10/2 Valtteri Kiviniemi <k= iviniemi.valtteri@gmail.com>
Hi,

Yes, they are all loaded and I'm running Linux PV-virtuals a= t the same time with no problems. Only HVM is not working. I have single so= cket corei7 processor and NUMA enabled on dom0 kernel, so I will try tomorr= ow to compile dom0 kernel without NUMA, since its not needed and it could p= robably cause some kind of memory related problems.

I will also try Debian squeezes package Xen and test if it is working w= ith my hardware.

- Valtteri


2012/10/2 Konrad Rzeszutek Wilk <konrad@kernel.org>
On Tue, Oct 2, 2012 at 10:55 AM, Valtte= ri Kiviniemi
<kivin= iemi.valtteri@gmail.com> wrote:
> Hi,
>
> Yes, I understood for what the parameters were for. I'ts been a lo= ng time
> since I last had major problems with Xen (maybe 3.1 or something, been= using
> Xen since version 2) and I had a shady recollection that Xen was requi= red to
> be build debugging enabled in order to get any usable debugging data.<= br> >
> But anyway, I cant reproduce that kernel crash everytime, it just happ= ens
> sometimes. Major problem is the black screen on VNC and second problem= seems
> to be that everytime i try to run Linux in HVM mode it somehow breaks = the
> hotplug scripts.
>

So do you have all backends loaded? Is xen-netback and xen-blkback ru= nning?
Do you also have tun loaded?



--20cf303b4269df8e0a04cb253740-- --===============2078183613774764552== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============2078183613774764552==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 10:37:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 10:37:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJMK7-0006PK-8b; Wed, 03 Oct 2012 10:37:03 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJMK5-0006PC-Sl for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 10:37:02 +0000 Received: from [85.158.137.99:33102] by server-10.bemta-3.messagelabs.com id 2C/5F-02525-C451C605; Wed, 03 Oct 2012 10:37:00 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-5.tower-217.messagelabs.com!1349260618!15348242!1 X-Originating-IP: [209.85.161.173] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26553 invoked from network); 3 Oct 2012 10:36:59 -0000 Received: from mail-gg0-f173.google.com (HELO mail-gg0-f173.google.com) (209.85.161.173) by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 10:36:59 -0000 Received: by ggcs5 with SMTP id s5so596281ggc.32 for ; Wed, 03 Oct 2012 03:36:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=03BOeqxZ1JTsVUtWNmx3RRNI7QSHzMxeIn6PQOH3ZW8=; b=0sYe+RiSEuVgRCTziAG07j0UAG/FqHBfLSHk8rohzHYYWd4mbu+LrfQu0BOq44a2As Uze0D60x+bMHFGJDGbEebuLlV3L7hLBxuj+OrSfuAEkJJ8p+FgpkIyMa/JQBnejVci5a 28qdM1fnCAGemn/FTUNHPtAaZ84HrJAfYfNd2IIAGCST9As53COBlBRF3fyzN+g7J0dr cGMTxD3sT56qgsZ9hWnHZvyi2GoDTTsXOp6bRwANSu3UO/OWKglLzXuGS8rJ0EMiCtVo MEsrY/n0cPpcLctymt4Z6OETd9LQLFS72C1hSpBtebwXa62sfxRMxzBT2AmJD4yJkzwK aFfg== MIME-Version: 1.0 Received: by 10.236.155.71 with SMTP id i47mr1371292yhk.72.1349260618468; Wed, 03 Oct 2012 03:36:58 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Wed, 3 Oct 2012 03:36:58 -0700 (PDT) In-Reply-To: References: <20121001164757.GF8912@reaktio.net> <20121001182437.GG8912@reaktio.net> <20121002121932.GL8912@reaktio.net> <20121002144251.GP8912@reaktio.net> Date: Wed, 3 Oct 2012 13:36:58 +0300 Message-ID: From: Valtteri Kiviniemi To: Konrad Rzeszutek Wilk Cc: Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.0.4, kernel 3.5.0 HVM crash and kernel BUG X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2078183613774764552==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============2078183613774764552== Content-Type: multipart/alternative; boundary=20cf303b4269df8e0a04cb253740 --20cf303b4269df8e0a04cb253740 Content-Type: text/plain; charset=ISO-8859-1 Hi, I enabled debugging, no new information available. DomU starts, VNC has black screen. No crashes so far. - Valtteri 2012/10/3 Valtteri Kiviniemi > Hi, > > I disabled NUMA and upgraded to Xen 4.2.0. Windows domU starts now fine > and I cant anymore reproduce the hotplug problems. VNC output is still just > black screen and it actually crashes the the whole VNC client when after a > few seconds. RealVNC just shuts itself down and tightvnc crashes. > > - Valtteri > > > > 2012/10/2 Valtteri Kiviniemi > >> Hi, >> >> Yes, they are all loaded and I'm running Linux PV-virtuals at the same >> time with no problems. Only HVM is not working. I have single socket corei7 >> processor and NUMA enabled on dom0 kernel, so I will try tomorrow to >> compile dom0 kernel without NUMA, since its not needed and it could >> probably cause some kind of memory related problems. >> >> I will also try Debian squeezes package Xen and test if it is working >> with my hardware. >> >> - Valtteri >> >> >> 2012/10/2 Konrad Rzeszutek Wilk >> >>> On Tue, Oct 2, 2012 at 10:55 AM, Valtteri Kiviniemi >>> wrote: >>> > Hi, >>> > >>> > Yes, I understood for what the parameters were for. I'ts been a long >>> time >>> > since I last had major problems with Xen (maybe 3.1 or something, been >>> using >>> > Xen since version 2) and I had a shady recollection that Xen was >>> required to >>> > be build debugging enabled in order to get any usable debugging data. >>> > >>> > But anyway, I cant reproduce that kernel crash everytime, it just >>> happens >>> > sometimes. Major problem is the black screen on VNC and second problem >>> seems >>> > to be that everytime i try to run Linux in HVM mode it somehow breaks >>> the >>> > hotplug scripts. >>> > >>> >>> So do you have all backends loaded? Is xen-netback and xen-blkback >>> running? >>> Do you also have tun loaded? >>> >> >> > --20cf303b4269df8e0a04cb253740 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I enabled debugging, no new information available. DomU starts, = VNC has black screen. No crashes so far.

- Valtteri

2012/10/3 Valtteri Kiviniemi <kiviniemi.valtt= eri@gmail.com>
Hi,

I disabled NUMA and upgraded to X= en 4.2.0. Windows domU starts now fine and I cant anymore reproduce the hot= plug problems. VNC output is still just black screen and it actually crashe= s the the whole VNC client when after a few seconds. RealVNC just shuts its= elf down and tightvnc crashes.

- Valtteri


2012/10/2 Valtteri Kiviniemi <k= iviniemi.valtteri@gmail.com>
Hi,

Yes, they are all loaded and I'm running Linux PV-virtuals a= t the same time with no problems. Only HVM is not working. I have single so= cket corei7 processor and NUMA enabled on dom0 kernel, so I will try tomorr= ow to compile dom0 kernel without NUMA, since its not needed and it could p= robably cause some kind of memory related problems.

I will also try Debian squeezes package Xen and test if it is working w= ith my hardware.

- Valtteri


2012/10/2 Konrad Rzeszutek Wilk <konrad@kernel.org>
On Tue, Oct 2, 2012 at 10:55 AM, Valtte= ri Kiviniemi
<kivin= iemi.valtteri@gmail.com> wrote:
> Hi,
>
> Yes, I understood for what the parameters were for. I'ts been a lo= ng time
> since I last had major problems with Xen (maybe 3.1 or something, been= using
> Xen since version 2) and I had a shady recollection that Xen was requi= red to
> be build debugging enabled in order to get any usable debugging data.<= br> >
> But anyway, I cant reproduce that kernel crash everytime, it just happ= ens
> sometimes. Major problem is the black screen on VNC and second problem= seems
> to be that everytime i try to run Linux in HVM mode it somehow breaks = the
> hotplug scripts.
>

So do you have all backends loaded? Is xen-netback and xen-blkback ru= nning?
Do you also have tun loaded?



--20cf303b4269df8e0a04cb253740-- --===============2078183613774764552== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============2078183613774764552==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 10:38:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 10:38:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJMKz-0006W6-Mx; Wed, 03 Oct 2012 10:37:57 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJMKy-0006Vv-UB for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 10:37:57 +0000 Received: from [85.158.139.211:40706] by server-5.bemta-5.messagelabs.com id 2E/EB-21075-4851C605; Wed, 03 Oct 2012 10:37:56 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-3.tower-206.messagelabs.com!1349260673!20880850!1 X-Originating-IP: [209.85.213.45] X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG, HTML_20_30, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22942 invoked from network); 3 Oct 2012 10:37:54 -0000 Received: from mail-yh0-f45.google.com (HELO mail-yh0-f45.google.com) (209.85.213.45) by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 10:37:54 -0000 Received: by yhpp34 with SMTP id p34so702578yhp.32 for ; Wed, 03 Oct 2012 03:37:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1+qUxOHCw5l2stpX6kS4Tdsjyl5JMRfPhcYpfEpVEeM=; b=QGAbDVNJPscC7KZiMVk8Ln9EYuN/k5XXVv2FNHUw63MQpyeBM+xXPJ0zcf1B1CoaAN ONSyKKTfEh+wG/fGaE/YzStvpQOwAguBXU6egXxsH+NATayiVRWErYJLVIsWubEzD19a 5XRYDQd4Burx4FEXvBBBnJmzwT/7ySJFrpo3urtGmlnYMjVH0KhIG7Vitq0M96R4TDUG IuMYbLVQTeimhtpo/bUukmGU5HbNmDLip7rZrlCce/aSozb3tEyvdwQI0hts1/eh6r+n d76Idp3s/k152iz/WJoadqEqFslfSYTeoOs0dWKGQxtKtarDXSMc2DmiMIt5KQK7SLFS LCUg== MIME-Version: 1.0 Received: by 10.236.9.36 with SMTP id 24mr1374794yhs.63.1349260672930; Wed, 03 Oct 2012 03:37:52 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Wed, 3 Oct 2012 03:37:52 -0700 (PDT) In-Reply-To: References: <1349256606.650.120.camel@zakaz.uk.xensource.com> Date: Wed, 3 Oct 2012 13:37:52 +0300 Message-ID: From: Valtteri Kiviniemi To: Ian Campbell Cc: "Xen-devel@lists.xen.org" Subject: Re: [Xen-devel] xlu_cfg_get_defbool error when trying to start domU X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1576298608499918973==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============1576298608499918973== Content-Type: multipart/alternative; boundary=20cf303dd2641e94a204cb253b0c --20cf303dd2641e94a204cb253b0c Content-Type: text/plain; charset=ISO-8859-1 Hi, I enabled debugging and console logging. This is where it crashes: Parsing config from /etc/xen/lightning.cfg Daemon running with PID 4952 Linux version 2.6.16.33-xen-domU-oldgame (root@lightning) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Fri Sep 28 14:56:14 EEST 2012 BIOS-provided physical RAM map: Xen: 0000000000000000 - 0000000080000000 (usable) 1320MB HIGHMEM available. 727MB LOWMEM available. NX (Execute Disable) protection: active early console enabled Built 1 zonelists Kernel command line: root=/dev/xvda1 ro console=xvc0 earlyprintk=xen Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 PID hash table entries: 4096 (order: 12, 65536 bytes) Xen reported: 3392.374 MHz processor. disabling early console Console: colour dummy device 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Software IO TLB disabled vmalloc area: ee000000-f51fe000, maxmem 2d7fe000 Memory: 2072132k/2097152k available (1917k kernel code, 23952k reserved, 537k data, 148k init, 1351688k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 6819.95 BogoMIPS (lpj=3409975) Mount-cache hash table entries: 512 CPU: L1 I cache: 32K, L1 D cache: 32K CPU: L2 cache: 256K CPU: L3 cache: 8192K Checking 'hlt' instruction... OK. Initializing CPU#1 Initializing CPU#2 Initializing CPU#3 Initializing CPU#4 Initializing CPU#5 Initializing CPU#6 Brought up 8 CPUs Initializing CPU#7 migration_cost=3 Grant table initialized NET: Registered protocol family 16 xen_mem: Initialising balloon driver. SCSI subsystem initialized highmem bounce pool size: 64 pages Installing knfsd (copyright (C) 1996 okir@monad.swb.de). Initializing Cryptographic API io scheduler noop registered io scheduler cfq registered (default) rtc: IRQ 8 is not free. i8042.c: No controller found. loop: loaded (max 8 devices) Xen virtual console successfully installed as tty1 Event-channel device installed. netfront: Initialising virtual ethernet driver. mice: PS/2 mouse device common for all mice Netfilter messages via NETLINK v0.30. NET: Registered protocol family 2 Registering block device major 202 blkfront: xvda1: barriers enabled netfront: device eth0 has copying receive path. IP route cache hash table entries: 32768 (order: 5, 131072 bytes) TCP established hash table entries: 131072 (order: 8, 1048576 bytes) TCP bind hash table entries: 65536 (order: 7, 524288 bytes) TCP: Hash tables configured (established 131072 bind 65536) TCP reno registered ip_conntrack version 2.4 (8192 buckets, 65536 max) - 232 bytes per conntrack ip_conntrack_pptp version 3.1 loaded ip_nat_pptp version 3.0 loaded ip_tables: (C) 2000-2006 Netfilter Core Team ipt_recent v0.3.1: Stephen Frost . http://snowman.net/projects/ipt_recent/ TCP bic registered NET: Registered protocol family 1 NET: Registered protocol family 17 NET: Registered protocol family 15 Bridge firewalling registered 802.1Q VLAN Support v1.8 Ben Greear All bugs added by David S. Miller Using IPI Shortcut mode end_request: I/O error, dev xvda1, sector 2 EXT3-fs: unable to read superblock Unable to handle kernel paging request at virtual address 05de1ce8 printing eip: c0231fdc 005c4000 -> *pde = 00000000:00000000 Oops: 0000 [#1] SMP CPU: 0 EIP: 0061:[] Not tainted VLI EFLAGS: 00010007 (2.6.16.33-xen-domU-oldgame #1) EIP is at blkif_int+0x7f/0x228 eax: 189c9c00 ebx: c04df900 ecx: ed418000 edx: 05de1c00 esi: 00000000 edi: ca010100 ebp: c043d0ac esp: c0367ec0 ds: 007b es: 007b ss: e021 Process swapper (pid: 0, threadinfo=c0366000 task=c030d7c0) Stack: <0>c200ce24 20539c5e 00000000 00000001 00000001 00000002 00000000 00000001 c04df900 00000000 00000000 c0367f6c c0133197 0000011a ed418000 c0367f6c 0000011a 00008d00 c035c100 0000011a c04df900 c013328f 0000011a 0000000a Call Trace: [] handle_IRQ_event+0x38/0xa9 [] __do_IRQ+0x87/0xf8 [] do_IRQ+0x1a/0x25 [] evtchn_do_upcall+0x95/0xa9 [] hypervisor_callback+0x3d/0x48 [] safe_halt+0x7a/0xb2 [] xen_idle+0x2b/0x4e [] cpu_idle+0x52/0x67 [] start_kernel+0x2b8/0x33c [] unknown_bootoption+0x0/0x27a Code: 83 ea 01 23 54 24 1c 8d 04 12 01 d0 8d 04 c0 8d 2c 85 40 00 00 00 03 69 28 8b 7d 00 8d 14 bf 89 d0 c1 e0 05 29 d0 01 f8 8d 14 08 <8b> 92 e8 00 00 00 89 54 24 0c 8d 74 08 7c 80 7e 01 00 74 29 31 <0>Kernel panic - not syncing: Fatal exception in interrupt Badness in smp_call_function at arch/i386/kernel/smp-xen.c:520 [] smp_call_function+0x146/0x14b [] printk+0x1b/0x1f [] do_unblank_screen+0xe/0x129 [] smp_send_stop+0x27/0x60 [] stop_this_cpu+0x0/0x3f [] panic+0x5e/0x155 [] die+0x231/0x23b [] do_page_fault+0x396/0xd30 [] getnstimeofday+0x14/0x37 [] do_page_fault+0x0/0xd30 [] error_code+0x2b/0x30 [] blkif_int+0x7f/0x228 [] handle_IRQ_event+0x38/0xa9 [] __do_IRQ+0x87/0xf8 [] do_IRQ+0x1a/0x25 [ 2012/10/3 Valtteri Kiviniemi > Hi, > > Ah, I missed that one, thanks! Its working now when using --libdir > configure option. > > - Valtteri > > > 2012/10/3 Ian Campbell > >> On Wed, 2012-10-03 at 10:16 +0100, Valtteri Kiviniemi wrote: >> > Hi, >> > >> > I just upgraded from Xen 4.0.4 to Xen 4.2.0. When I'm trying to start >> > domU using the new xl toolstack I get the following error message: >> > >> > Parsing config from /etc/xen/domu1.cfg >> > xl: symbol lookup error: xl: undefined symbol: xlu_cfg_get_defbool >> >> This (usually) means that your libraries are somehow out of sync. >> >> Perhaps check /usr/lib and /usr/lib64 and the output of "ldd xl" and >> make sure the libraries it is picking up are the 4.2 versions. >> >> If you are picking up old versions from /usr/lib64 while the new >> versions are in lib64 then perhaps you need to pass --libdir to >> configure as described in http://wiki.xen.org/wiki/Xen_4.2_Release_Notes >> >> Ian. >> >> > When lauching xend and using xm create the domU starts up normally. >> > >> > - Valtteri >> > >> >> >> > --20cf303dd2641e94a204cb253b0c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I enabled debugging and console logging. This is where it crashe= s:

Parsing config from /etc/xen/lightning.cfg
Daemon running with= PID 4952
Linux version 2.6.16.33-xen-domU-oldgame (root@lightning) (gcc= version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Fri Sep 28 1= 4:56:14 EEST 2012
BIOS-provided physical RAM map:
=A0Xen: 0000000000000000 - 0000000080000= 000 (usable)
1320MB HIGHMEM available.
727MB LOWMEM available.
NX = (Execute Disable) protection: active
early console enabled
Built 1 zo= nelists
Kernel command line: root=3D/dev/xvda1 ro console=3Dxvc0 earlyprintk=3Dxen<= br>Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FP= U exception support... done.
Initializing CPU#0
PID hash table entrie= s: 4096 (order: 12, 65536 bytes)
Xen reported: 3392.374 MHz processor.
disabling early console
Console= : colour dummy device 80x25
Dentry cache hash table entries: 131072 (ord= er: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 26= 2144 bytes)
Software IO TLB disabled
vmalloc area: ee000000-f51fe000, maxmem 2d7fe00= 0
Memory: 2072132k/2097152k available (1917k kernel code, 23952k reserve= d, 537k data, 148k init, 1351688k highmem)
Checking if this processor ho= nours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 6819.95 BogoMIPS (lpj=3D34= 09975)
Mount-cache hash table entries: 512
CPU: L1 I cache: 32K, L1 D= cache: 32K
CPU: L2 cache: 256K
CPU: L3 cache: 8192K
Checking '= ;hlt' instruction... OK.
Initializing CPU#1
Initializing CPU#2
Initializing CPU#3
Initializ= ing CPU#4
Initializing CPU#5
Initializing CPU#6
Brought up 8 CPUs<= br>Initializing CPU#7
migration_cost=3D3
Grant table initialized
NET: Registered protocol family 16
xen_mem: Initialising balloon driver.=
SCSI subsystem initialized
highmem bounce pool size: 64 pages
Ins= talling knfsd (copyright (C) 1996 okir= @monad.swb.de).
Initializing Cryptographic API
io scheduler noop registered
io schedu= ler cfq registered (default)
rtc: IRQ 8 is not free.
i8042.c: No cont= roller found.
loop: loaded (max 8 devices)
Xen virtual console succes= sfully installed as tty1
Event-channel device installed.
netfront: Initialising virtual ethernet = driver.
mice: PS/2 mouse device common for all mice
Netfilter message= s via NETLINK v0.30.
NET: Registered protocol family 2
Registering bl= ock device major 202
blkfront: xvda1: barriers enabled
netfront: device eth0 has copying rece= ive path.
IP route cache hash table entries: 32768 (order: 5, 131072 byt= es)
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)=
TCP bind hash table entries: 65536 (order: 7, 524288 bytes)
TCP: Hash ta= bles configured (established 131072 bind 65536)
TCP reno registered
i= p_conntrack version 2.4 (8192 buckets, 65536 max) - 232 bytes per conntrack=
ip_conntrack_pptp version 3.1 loaded
ip_nat_pptp version 3.0 loaded
i= p_tables: (C) 2000-2006 Netfilter Core Team
ipt_recent v0.3.1: Stephen F= rost <sfrost@snowman.net>.= =A0 http://snowman.net/= projects/ipt_recent/
TCP bic registered
NET: Registered protocol family 1
NET: Registered = protocol family 17
NET: Registered protocol family 15
Bridge firewall= ing registered
802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>
All bugs added by David S. Miller <d= avem@redhat.com>
Using IPI Shortcut mode
end_request: I/O erro= r, dev xvda1, sector 2
EXT3-fs: unable to read superblock
Unable to h= andle kernel paging request at virtual address 05de1ce8
=A0printing eip:
c0231fdc
005c4000 -> *pde =3D 00000000:00000000Oops: 0000 [#1]
SMP
CPU:=A0=A0=A0 0
EIP:=A0=A0=A0 0061:[<c023= 1fdc>]=A0=A0=A0 Not tainted VLI
EFLAGS: 00010007=A0=A0 (2.6.16.33-xen= -domU-oldgame #1)
EIP is at blkif_int+0x7f/0x228
eax: 189c9c00=A0=A0 ebx: c04df900=A0=A0 ecx: ed418000=A0=A0 edx: 05de1c00esi: 00000000=A0=A0 edi: ca010100=A0=A0 ebp: c043d0ac=A0=A0 esp: c0367ec0=
ds: 007b=A0=A0 es: 007b=A0=A0 ss: e021
Process swapper (pid: 0, thre= adinfo=3Dc0366000 task=3Dc030d7c0)
Stack: <0>c200ce24 20539c5e 00000000 00000001 00000001 00000002 00000= 000 00000001
=A0=A0=A0=A0=A0=A0 c04df900 00000000 00000000 c0367f6c c013= 3197 0000011a ed418000 c0367f6c
=A0=A0=A0=A0=A0=A0 0000011a 00008d00 c03= 5c100 0000011a c04df900 c013328f 0000011a 0000000a
Call Trace:
=A0[<c0133197>] handle_IRQ_event+0x38/0xa9
=A0[<= c013328f>] __do_IRQ+0x87/0xf8
=A0[<c0106782>] do_IRQ+0x1a/0x25<= br>=A0[<c0228d85>] evtchn_do_upcall+0x95/0xa9
=A0[<c010504d>= ] hypervisor_callback+0x3d/0x48
=A0[<c0107ecf>] safe_halt+0x7a/0xb2
=A0[<c0102efd>] xen_idle= +0x2b/0x4e
=A0[<c0103014>] cpu_idle+0x52/0x67
=A0[<c036871c&= gt;] start_kernel+0x2b8/0x33c
=A0[<c03681ea>] unknown_bootoption+0= x0/0x27a
Code: 83 ea 01 23 54 24 1c 8d 04 12 01 d0 8d 04 c0 8d 2c 85 40 00 00 00 03 = 69 28 8b 7d 00 8d 14 bf 89 d0 c1 e0 05 29 d0 01 f8 8d 14 08 <8b> 92 e= 8 00 00 00 89 54 24 0c 8d 74 08 7c 80 7e 01 00 74 29 31
=A0<0>Kern= el panic - not syncing: Fatal exception in interrupt
=A0Badness in smp_call_function at arch/i386/kernel/smp-xen.c:520
=A0[&l= t;c010c8fe>] smp_call_function+0x146/0x14b
=A0[<c011ac6e>] prin= tk+0x1b/0x1f
=A0[<c021a120>] do_unblank_screen+0xe/0x129
=A0[&l= t;c010c9a9>] smp_send_stop+0x27/0x60
=A0[<c010c943>] stop_this_cpu+0x0/0x3f
=A0[<c011a149>] panic= +0x5e/0x155
=A0[<c0105948>] die+0x231/0x23b
=A0[<c0110348>= ;] do_page_fault+0x396/0xd30
=A0[<c011eb6b>] getnstimeofday+0x14/0= x37
=A0[<c010ffb2>] do_page_fault+0x0/0xd30
=A0[<c010500b>] erro= r_code+0x2b/0x30
=A0[<c0231fdc>] blkif_int+0x7f/0x228
=A0[<c= 0133197>] handle_IRQ_event+0x38/0xa9
=A0[<c013328f>] __do_IRQ+0= x87/0xf8
=A0[<c0106782>] do_IRQ+0x1a/0x25
=A0[


2012/10/3 Valtteri Kiviniemi <kiviniemi.valtteri@gmai= l.com>
Hi,

Ah, I missed that one, thanks! It= s working now when using --libdir configure option.<= font color=3D"#888888">

- Valtteri

2012/10/3 Ian Campbell <Ian.Campbell@cit= rix.com>
On Wed, 2012-10-03 at 10:16 +0100, Valt= teri Kiviniemi wrote:
> Hi,
>
> I just upgraded from Xen 4.0.4 to Xen 4.2.0. When I'm trying to st= art
> domU using the new xl toolstack I get the following error message:
>
> Parsing config from /etc/xen/domu1.cfg
> xl: symbol lookup error: xl: undefined symbol: xlu_cfg_get_defbool

This (usually) means that your libraries are somehow out of sync.

Perhaps check /usr/lib and /usr/lib64 and the output of "ldd xl" = and
make sure the libraries it is picking up are the 4.2 versions.

If you are picking up old versions from /usr/lib64 while the new
versions are in lib64 then perhaps you need to pass --libdir to
configure as described in http://wiki.xen.org/wiki/Xen_4.2_Release_Notes<= /a>

Ian.

> When lauching xend and using xm create the domU starts up normally. >
> - Valtteri
>




--20cf303dd2641e94a204cb253b0c-- --===============1576298608499918973== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============1576298608499918973==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 10:38:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 10:38:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJMKz-0006W6-Mx; Wed, 03 Oct 2012 10:37:57 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJMKy-0006Vv-UB for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 10:37:57 +0000 Received: from [85.158.139.211:40706] by server-5.bemta-5.messagelabs.com id 2E/EB-21075-4851C605; Wed, 03 Oct 2012 10:37:56 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-3.tower-206.messagelabs.com!1349260673!20880850!1 X-Originating-IP: [209.85.213.45] X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG, HTML_20_30, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22942 invoked from network); 3 Oct 2012 10:37:54 -0000 Received: from mail-yh0-f45.google.com (HELO mail-yh0-f45.google.com) (209.85.213.45) by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 10:37:54 -0000 Received: by yhpp34 with SMTP id p34so702578yhp.32 for ; Wed, 03 Oct 2012 03:37:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1+qUxOHCw5l2stpX6kS4Tdsjyl5JMRfPhcYpfEpVEeM=; b=QGAbDVNJPscC7KZiMVk8Ln9EYuN/k5XXVv2FNHUw63MQpyeBM+xXPJ0zcf1B1CoaAN ONSyKKTfEh+wG/fGaE/YzStvpQOwAguBXU6egXxsH+NATayiVRWErYJLVIsWubEzD19a 5XRYDQd4Burx4FEXvBBBnJmzwT/7ySJFrpo3urtGmlnYMjVH0KhIG7Vitq0M96R4TDUG IuMYbLVQTeimhtpo/bUukmGU5HbNmDLip7rZrlCce/aSozb3tEyvdwQI0hts1/eh6r+n d76Idp3s/k152iz/WJoadqEqFslfSYTeoOs0dWKGQxtKtarDXSMc2DmiMIt5KQK7SLFS LCUg== MIME-Version: 1.0 Received: by 10.236.9.36 with SMTP id 24mr1374794yhs.63.1349260672930; Wed, 03 Oct 2012 03:37:52 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Wed, 3 Oct 2012 03:37:52 -0700 (PDT) In-Reply-To: References: <1349256606.650.120.camel@zakaz.uk.xensource.com> Date: Wed, 3 Oct 2012 13:37:52 +0300 Message-ID: From: Valtteri Kiviniemi To: Ian Campbell Cc: "Xen-devel@lists.xen.org" Subject: Re: [Xen-devel] xlu_cfg_get_defbool error when trying to start domU X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1576298608499918973==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============1576298608499918973== Content-Type: multipart/alternative; boundary=20cf303dd2641e94a204cb253b0c --20cf303dd2641e94a204cb253b0c Content-Type: text/plain; charset=ISO-8859-1 Hi, I enabled debugging and console logging. This is where it crashes: Parsing config from /etc/xen/lightning.cfg Daemon running with PID 4952 Linux version 2.6.16.33-xen-domU-oldgame (root@lightning) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Fri Sep 28 14:56:14 EEST 2012 BIOS-provided physical RAM map: Xen: 0000000000000000 - 0000000080000000 (usable) 1320MB HIGHMEM available. 727MB LOWMEM available. NX (Execute Disable) protection: active early console enabled Built 1 zonelists Kernel command line: root=/dev/xvda1 ro console=xvc0 earlyprintk=xen Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 PID hash table entries: 4096 (order: 12, 65536 bytes) Xen reported: 3392.374 MHz processor. disabling early console Console: colour dummy device 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Software IO TLB disabled vmalloc area: ee000000-f51fe000, maxmem 2d7fe000 Memory: 2072132k/2097152k available (1917k kernel code, 23952k reserved, 537k data, 148k init, 1351688k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 6819.95 BogoMIPS (lpj=3409975) Mount-cache hash table entries: 512 CPU: L1 I cache: 32K, L1 D cache: 32K CPU: L2 cache: 256K CPU: L3 cache: 8192K Checking 'hlt' instruction... OK. Initializing CPU#1 Initializing CPU#2 Initializing CPU#3 Initializing CPU#4 Initializing CPU#5 Initializing CPU#6 Brought up 8 CPUs Initializing CPU#7 migration_cost=3 Grant table initialized NET: Registered protocol family 16 xen_mem: Initialising balloon driver. SCSI subsystem initialized highmem bounce pool size: 64 pages Installing knfsd (copyright (C) 1996 okir@monad.swb.de). Initializing Cryptographic API io scheduler noop registered io scheduler cfq registered (default) rtc: IRQ 8 is not free. i8042.c: No controller found. loop: loaded (max 8 devices) Xen virtual console successfully installed as tty1 Event-channel device installed. netfront: Initialising virtual ethernet driver. mice: PS/2 mouse device common for all mice Netfilter messages via NETLINK v0.30. NET: Registered protocol family 2 Registering block device major 202 blkfront: xvda1: barriers enabled netfront: device eth0 has copying receive path. IP route cache hash table entries: 32768 (order: 5, 131072 bytes) TCP established hash table entries: 131072 (order: 8, 1048576 bytes) TCP bind hash table entries: 65536 (order: 7, 524288 bytes) TCP: Hash tables configured (established 131072 bind 65536) TCP reno registered ip_conntrack version 2.4 (8192 buckets, 65536 max) - 232 bytes per conntrack ip_conntrack_pptp version 3.1 loaded ip_nat_pptp version 3.0 loaded ip_tables: (C) 2000-2006 Netfilter Core Team ipt_recent v0.3.1: Stephen Frost . http://snowman.net/projects/ipt_recent/ TCP bic registered NET: Registered protocol family 1 NET: Registered protocol family 17 NET: Registered protocol family 15 Bridge firewalling registered 802.1Q VLAN Support v1.8 Ben Greear All bugs added by David S. Miller Using IPI Shortcut mode end_request: I/O error, dev xvda1, sector 2 EXT3-fs: unable to read superblock Unable to handle kernel paging request at virtual address 05de1ce8 printing eip: c0231fdc 005c4000 -> *pde = 00000000:00000000 Oops: 0000 [#1] SMP CPU: 0 EIP: 0061:[] Not tainted VLI EFLAGS: 00010007 (2.6.16.33-xen-domU-oldgame #1) EIP is at blkif_int+0x7f/0x228 eax: 189c9c00 ebx: c04df900 ecx: ed418000 edx: 05de1c00 esi: 00000000 edi: ca010100 ebp: c043d0ac esp: c0367ec0 ds: 007b es: 007b ss: e021 Process swapper (pid: 0, threadinfo=c0366000 task=c030d7c0) Stack: <0>c200ce24 20539c5e 00000000 00000001 00000001 00000002 00000000 00000001 c04df900 00000000 00000000 c0367f6c c0133197 0000011a ed418000 c0367f6c 0000011a 00008d00 c035c100 0000011a c04df900 c013328f 0000011a 0000000a Call Trace: [] handle_IRQ_event+0x38/0xa9 [] __do_IRQ+0x87/0xf8 [] do_IRQ+0x1a/0x25 [] evtchn_do_upcall+0x95/0xa9 [] hypervisor_callback+0x3d/0x48 [] safe_halt+0x7a/0xb2 [] xen_idle+0x2b/0x4e [] cpu_idle+0x52/0x67 [] start_kernel+0x2b8/0x33c [] unknown_bootoption+0x0/0x27a Code: 83 ea 01 23 54 24 1c 8d 04 12 01 d0 8d 04 c0 8d 2c 85 40 00 00 00 03 69 28 8b 7d 00 8d 14 bf 89 d0 c1 e0 05 29 d0 01 f8 8d 14 08 <8b> 92 e8 00 00 00 89 54 24 0c 8d 74 08 7c 80 7e 01 00 74 29 31 <0>Kernel panic - not syncing: Fatal exception in interrupt Badness in smp_call_function at arch/i386/kernel/smp-xen.c:520 [] smp_call_function+0x146/0x14b [] printk+0x1b/0x1f [] do_unblank_screen+0xe/0x129 [] smp_send_stop+0x27/0x60 [] stop_this_cpu+0x0/0x3f [] panic+0x5e/0x155 [] die+0x231/0x23b [] do_page_fault+0x396/0xd30 [] getnstimeofday+0x14/0x37 [] do_page_fault+0x0/0xd30 [] error_code+0x2b/0x30 [] blkif_int+0x7f/0x228 [] handle_IRQ_event+0x38/0xa9 [] __do_IRQ+0x87/0xf8 [] do_IRQ+0x1a/0x25 [ 2012/10/3 Valtteri Kiviniemi > Hi, > > Ah, I missed that one, thanks! Its working now when using --libdir > configure option. > > - Valtteri > > > 2012/10/3 Ian Campbell > >> On Wed, 2012-10-03 at 10:16 +0100, Valtteri Kiviniemi wrote: >> > Hi, >> > >> > I just upgraded from Xen 4.0.4 to Xen 4.2.0. When I'm trying to start >> > domU using the new xl toolstack I get the following error message: >> > >> > Parsing config from /etc/xen/domu1.cfg >> > xl: symbol lookup error: xl: undefined symbol: xlu_cfg_get_defbool >> >> This (usually) means that your libraries are somehow out of sync. >> >> Perhaps check /usr/lib and /usr/lib64 and the output of "ldd xl" and >> make sure the libraries it is picking up are the 4.2 versions. >> >> If you are picking up old versions from /usr/lib64 while the new >> versions are in lib64 then perhaps you need to pass --libdir to >> configure as described in http://wiki.xen.org/wiki/Xen_4.2_Release_Notes >> >> Ian. >> >> > When lauching xend and using xm create the domU starts up normally. >> > >> > - Valtteri >> > >> >> >> > --20cf303dd2641e94a204cb253b0c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I enabled debugging and console logging. This is where it crashe= s:

Parsing config from /etc/xen/lightning.cfg
Daemon running with= PID 4952
Linux version 2.6.16.33-xen-domU-oldgame (root@lightning) (gcc= version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Fri Sep 28 1= 4:56:14 EEST 2012
BIOS-provided physical RAM map:
=A0Xen: 0000000000000000 - 0000000080000= 000 (usable)
1320MB HIGHMEM available.
727MB LOWMEM available.
NX = (Execute Disable) protection: active
early console enabled
Built 1 zo= nelists
Kernel command line: root=3D/dev/xvda1 ro console=3Dxvc0 earlyprintk=3Dxen<= br>Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FP= U exception support... done.
Initializing CPU#0
PID hash table entrie= s: 4096 (order: 12, 65536 bytes)
Xen reported: 3392.374 MHz processor.
disabling early console
Console= : colour dummy device 80x25
Dentry cache hash table entries: 131072 (ord= er: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 26= 2144 bytes)
Software IO TLB disabled
vmalloc area: ee000000-f51fe000, maxmem 2d7fe00= 0
Memory: 2072132k/2097152k available (1917k kernel code, 23952k reserve= d, 537k data, 148k init, 1351688k highmem)
Checking if this processor ho= nours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 6819.95 BogoMIPS (lpj=3D34= 09975)
Mount-cache hash table entries: 512
CPU: L1 I cache: 32K, L1 D= cache: 32K
CPU: L2 cache: 256K
CPU: L3 cache: 8192K
Checking '= ;hlt' instruction... OK.
Initializing CPU#1
Initializing CPU#2
Initializing CPU#3
Initializ= ing CPU#4
Initializing CPU#5
Initializing CPU#6
Brought up 8 CPUs<= br>Initializing CPU#7
migration_cost=3D3
Grant table initialized
NET: Registered protocol family 16
xen_mem: Initialising balloon driver.=
SCSI subsystem initialized
highmem bounce pool size: 64 pages
Ins= talling knfsd (copyright (C) 1996 okir= @monad.swb.de).
Initializing Cryptographic API
io scheduler noop registered
io schedu= ler cfq registered (default)
rtc: IRQ 8 is not free.
i8042.c: No cont= roller found.
loop: loaded (max 8 devices)
Xen virtual console succes= sfully installed as tty1
Event-channel device installed.
netfront: Initialising virtual ethernet = driver.
mice: PS/2 mouse device common for all mice
Netfilter message= s via NETLINK v0.30.
NET: Registered protocol family 2
Registering bl= ock device major 202
blkfront: xvda1: barriers enabled
netfront: device eth0 has copying rece= ive path.
IP route cache hash table entries: 32768 (order: 5, 131072 byt= es)
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)=
TCP bind hash table entries: 65536 (order: 7, 524288 bytes)
TCP: Hash ta= bles configured (established 131072 bind 65536)
TCP reno registered
i= p_conntrack version 2.4 (8192 buckets, 65536 max) - 232 bytes per conntrack=
ip_conntrack_pptp version 3.1 loaded
ip_nat_pptp version 3.0 loaded
i= p_tables: (C) 2000-2006 Netfilter Core Team
ipt_recent v0.3.1: Stephen F= rost <sfrost@snowman.net>.= =A0 http://snowman.net/= projects/ipt_recent/
TCP bic registered
NET: Registered protocol family 1
NET: Registered = protocol family 17
NET: Registered protocol family 15
Bridge firewall= ing registered
802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>
All bugs added by David S. Miller <d= avem@redhat.com>
Using IPI Shortcut mode
end_request: I/O erro= r, dev xvda1, sector 2
EXT3-fs: unable to read superblock
Unable to h= andle kernel paging request at virtual address 05de1ce8
=A0printing eip:
c0231fdc
005c4000 -> *pde =3D 00000000:00000000Oops: 0000 [#1]
SMP
CPU:=A0=A0=A0 0
EIP:=A0=A0=A0 0061:[<c023= 1fdc>]=A0=A0=A0 Not tainted VLI
EFLAGS: 00010007=A0=A0 (2.6.16.33-xen= -domU-oldgame #1)
EIP is at blkif_int+0x7f/0x228
eax: 189c9c00=A0=A0 ebx: c04df900=A0=A0 ecx: ed418000=A0=A0 edx: 05de1c00esi: 00000000=A0=A0 edi: ca010100=A0=A0 ebp: c043d0ac=A0=A0 esp: c0367ec0=
ds: 007b=A0=A0 es: 007b=A0=A0 ss: e021
Process swapper (pid: 0, thre= adinfo=3Dc0366000 task=3Dc030d7c0)
Stack: <0>c200ce24 20539c5e 00000000 00000001 00000001 00000002 00000= 000 00000001
=A0=A0=A0=A0=A0=A0 c04df900 00000000 00000000 c0367f6c c013= 3197 0000011a ed418000 c0367f6c
=A0=A0=A0=A0=A0=A0 0000011a 00008d00 c03= 5c100 0000011a c04df900 c013328f 0000011a 0000000a
Call Trace:
=A0[<c0133197>] handle_IRQ_event+0x38/0xa9
=A0[<= c013328f>] __do_IRQ+0x87/0xf8
=A0[<c0106782>] do_IRQ+0x1a/0x25<= br>=A0[<c0228d85>] evtchn_do_upcall+0x95/0xa9
=A0[<c010504d>= ] hypervisor_callback+0x3d/0x48
=A0[<c0107ecf>] safe_halt+0x7a/0xb2
=A0[<c0102efd>] xen_idle= +0x2b/0x4e
=A0[<c0103014>] cpu_idle+0x52/0x67
=A0[<c036871c&= gt;] start_kernel+0x2b8/0x33c
=A0[<c03681ea>] unknown_bootoption+0= x0/0x27a
Code: 83 ea 01 23 54 24 1c 8d 04 12 01 d0 8d 04 c0 8d 2c 85 40 00 00 00 03 = 69 28 8b 7d 00 8d 14 bf 89 d0 c1 e0 05 29 d0 01 f8 8d 14 08 <8b> 92 e= 8 00 00 00 89 54 24 0c 8d 74 08 7c 80 7e 01 00 74 29 31
=A0<0>Kern= el panic - not syncing: Fatal exception in interrupt
=A0Badness in smp_call_function at arch/i386/kernel/smp-xen.c:520
=A0[&l= t;c010c8fe>] smp_call_function+0x146/0x14b
=A0[<c011ac6e>] prin= tk+0x1b/0x1f
=A0[<c021a120>] do_unblank_screen+0xe/0x129
=A0[&l= t;c010c9a9>] smp_send_stop+0x27/0x60
=A0[<c010c943>] stop_this_cpu+0x0/0x3f
=A0[<c011a149>] panic= +0x5e/0x155
=A0[<c0105948>] die+0x231/0x23b
=A0[<c0110348>= ;] do_page_fault+0x396/0xd30
=A0[<c011eb6b>] getnstimeofday+0x14/0= x37
=A0[<c010ffb2>] do_page_fault+0x0/0xd30
=A0[<c010500b>] erro= r_code+0x2b/0x30
=A0[<c0231fdc>] blkif_int+0x7f/0x228
=A0[<c= 0133197>] handle_IRQ_event+0x38/0xa9
=A0[<c013328f>] __do_IRQ+0= x87/0xf8
=A0[<c0106782>] do_IRQ+0x1a/0x25
=A0[


2012/10/3 Valtteri Kiviniemi <kiviniemi.valtteri@gmai= l.com>
Hi,

Ah, I missed that one, thanks! It= s working now when using --libdir configure option.<= font color=3D"#888888">

- Valtteri

2012/10/3 Ian Campbell <Ian.Campbell@cit= rix.com>
On Wed, 2012-10-03 at 10:16 +0100, Valt= teri Kiviniemi wrote:
> Hi,
>
> I just upgraded from Xen 4.0.4 to Xen 4.2.0. When I'm trying to st= art
> domU using the new xl toolstack I get the following error message:
>
> Parsing config from /etc/xen/domu1.cfg
> xl: symbol lookup error: xl: undefined symbol: xlu_cfg_get_defbool

This (usually) means that your libraries are somehow out of sync.

Perhaps check /usr/lib and /usr/lib64 and the output of "ldd xl" = and
make sure the libraries it is picking up are the 4.2 versions.

If you are picking up old versions from /usr/lib64 while the new
versions are in lib64 then perhaps you need to pass --libdir to
configure as described in http://wiki.xen.org/wiki/Xen_4.2_Release_Notes<= /a>

Ian.

> When lauching xend and using xm create the domU starts up normally. >
> - Valtteri
>




--20cf303dd2641e94a204cb253b0c-- --===============1576298608499918973== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============1576298608499918973==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 10:38:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 10:38:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJMLZ-0006ce-CV; Wed, 03 Oct 2012 10:38:33 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJMLY-0006cI-2E for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 10:38:32 +0000 Received: from [85.158.143.35:42499] by server-2.bemta-4.messagelabs.com id 9B/64-06610-7A51C605; Wed, 03 Oct 2012 10:38:31 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1349260705!4876828!1 X-Originating-IP: [209.85.160.173] X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG, HTML_10_20, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19461 invoked from network); 3 Oct 2012 10:38:26 -0000 Received: from mail-gh0-f173.google.com (HELO mail-gh0-f173.google.com) (209.85.160.173) by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 10:38:26 -0000 Received: by ghy16 with SMTP id 16so2180988ghy.32 for ; Wed, 03 Oct 2012 03:38:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=y3Mu+d0KBCOBOuAImhd4W3oi8g+UvNe/kdsRiDCkss0=; b=F7EN5T/54fv1ZzliKFzdFFW35wQ/W3QqZvQJhSYNq6cr28a276D1m+GjtSbobGP6kd oWj6wgmq7wdB0EYL5d0jBVAjW1/PpWbE6OM0+oWzKxc/IhblOL4l4JGUS/9pS4DnS2vw 84cEXR24aaImUVpzdHYju0p9FvrS/zfEv2y4MMYDUDZtjs1WhwYVbpAB60AcIXdKNEgK ++qKNSctIyQ8dFan4CPX3NJZYhw9iu2OJJI/6UrfVF97t9qykyyrpoOggJtawrG7WK1g KkkpxTs8GrcstZf12qVeCx7ZfsQcIO6oOhl5uSmP6lYEYWl0k4hhZGWEOkkYLiBHe/Qd BcMg== MIME-Version: 1.0 Received: by 10.100.81.5 with SMTP id e5mr387355anb.80.1349260704713; Wed, 03 Oct 2012 03:38:24 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Wed, 3 Oct 2012 03:38:24 -0700 (PDT) In-Reply-To: <1349259542.650.122.camel@zakaz.uk.xensource.com> References: <1349259542.650.122.camel@zakaz.uk.xensource.com> Date: Wed, 3 Oct 2012 13:38:24 +0300 Message-ID: From: Valtteri Kiviniemi To: Ian Campbell Cc: "Xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Xen 4.2.0, xl toolstack cant launch older domUs X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8757735128085940129==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============8757735128085940129== Content-Type: multipart/alternative; boundary=00504501762a038c7304cb253dc6 --00504501762a038c7304cb253dc6 Content-Type: text/plain; charset=ISO-8859-1 Hi, I enabled debugging and console logging. This is where it crashes: Parsing config from /etc/xen/lightning.cfg Daemon running with PID 4952 Linux version 2.6.16.33-xen-domU-oldgame (root@lightning) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Fri Sep 28 14:56:14 EEST 2012 BIOS-provided physical RAM map: Xen: 0000000000000000 - 0000000080000000 (usable) 1320MB HIGHMEM available. 727MB LOWMEM available. NX (Execute Disable) protection: active early console enabled Built 1 zonelists Kernel command line: root=/dev/xvda1 ro console=xvc0 earlyprintk=xen Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 PID hash table entries: 4096 (order: 12, 65536 bytes) Xen reported: 3392.374 MHz processor. disabling early console Console: colour dummy device 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Software IO TLB disabled vmalloc area: ee000000-f51fe000, maxmem 2d7fe000 Memory: 2072132k/2097152k available (1917k kernel code, 23952k reserved, 537k data, 148k init, 1351688k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 6819.95 BogoMIPS (lpj=3409975) Mount-cache hash table entries: 512 CPU: L1 I cache: 32K, L1 D cache: 32K CPU: L2 cache: 256K CPU: L3 cache: 8192K Checking 'hlt' instruction... OK. Initializing CPU#1 Initializing CPU#2 Initializing CPU#3 Initializing CPU#4 Initializing CPU#5 Initializing CPU#6 Brought up 8 CPUs Initializing CPU#7 migration_cost=3 Grant table initialized NET: Registered protocol family 16 xen_mem: Initialising balloon driver. SCSI subsystem initialized highmem bounce pool size: 64 pages Installing knfsd (copyright (C) 1996 okir@monad.swb.de). Initializing Cryptographic API io scheduler noop registered io scheduler cfq registered (default) rtc: IRQ 8 is not free. i8042.c: No controller found. loop: loaded (max 8 devices) Xen virtual console successfully installed as tty1 Event-channel device installed. netfront: Initialising virtual ethernet driver. mice: PS/2 mouse device common for all mice Netfilter messages via NETLINK v0.30. NET: Registered protocol family 2 Registering block device major 202 blkfront: xvda1: barriers enabled netfront: device eth0 has copying receive path. IP route cache hash table entries: 32768 (order: 5, 131072 bytes) TCP established hash table entries: 131072 (order: 8, 1048576 bytes) TCP bind hash table entries: 65536 (order: 7, 524288 bytes) TCP: Hash tables configured (established 131072 bind 65536) TCP reno registered ip_conntrack version 2.4 (8192 buckets, 65536 max) - 232 bytes per conntrack ip_conntrack_pptp version 3.1 loaded ip_nat_pptp version 3.0 loaded ip_tables: (C) 2000-2006 Netfilter Core Team ipt_recent v0.3.1: Stephen Frost . http://snowman.net/projects/ipt_recent/ TCP bic registered NET: Registered protocol family 1 NET: Registered protocol family 17 NET: Registered protocol family 15 Bridge firewalling registered 802.1Q VLAN Support v1.8 Ben Greear All bugs added by David S. Miller Using IPI Shortcut mode end_request: I/O error, dev xvda1, sector 2 EXT3-fs: unable to read superblock Unable to handle kernel paging request at virtual address 05de1ce8 printing eip: c0231fdc 005c4000 -> *pde = 00000000:00000000 Oops: 0000 [#1] SMP CPU: 0 EIP: 0061:[] Not tainted VLI EFLAGS: 00010007 (2.6.16.33-xen-domU-oldgame #1) EIP is at blkif_int+0x7f/0x228 eax: 189c9c00 ebx: c04df900 ecx: ed418000 edx: 05de1c00 esi: 00000000 edi: ca010100 ebp: c043d0ac esp: c0367ec0 ds: 007b es: 007b ss: e021 Process swapper (pid: 0, threadinfo=c0366000 task=c030d7c0) Stack: <0>c200ce24 20539c5e 00000000 00000001 00000001 00000002 00000000 00000001 c04df900 00000000 00000000 c0367f6c c0133197 0000011a ed418000 c0367f6c 0000011a 00008d00 c035c100 0000011a c04df900 c013328f 0000011a 0000000a Call Trace: [] handle_IRQ_event+0x38/0xa9 [] __do_IRQ+0x87/0xf8 [] do_IRQ+0x1a/0x25 [] evtchn_do_upcall+0x95/0xa9 [] hypervisor_callback+0x3d/0x48 [] safe_halt+0x7a/0xb2 [] xen_idle+0x2b/0x4e [] cpu_idle+0x52/0x67 [] start_kernel+0x2b8/0x33c [] unknown_bootoption+0x0/0x27a Code: 83 ea 01 23 54 24 1c 8d 04 12 01 d0 8d 04 c0 8d 2c 85 40 00 00 00 03 69 28 8b 7d 00 8d 14 bf 89 d0 c1 e0 05 29 d0 01 f8 8d 14 08 <8b> 92 e8 00 00 00 89 54 24 0c 8d 74 08 7c 80 7e 01 00 74 29 31 <0>Kernel panic - not syncing: Fatal exception in interrupt Badness in smp_call_function at arch/i386/kernel/smp-xen.c:520 [] smp_call_function+0x146/0x14b [] printk+0x1b/0x1f [] do_unblank_screen+0xe/0x129 [] smp_send_stop+0x27/0x60 [] stop_this_cpu+0x0/0x3f [] panic+0x5e/0x155 [] die+0x231/0x23b [] do_page_fault+0x396/0xd30 [] getnstimeofday+0x14/0x37 [] do_page_fault+0x0/0xd30 [] error_code+0x2b/0x30 [] blkif_int+0x7f/0x228 [] handle_IRQ_event+0x38/0xa9 [] __do_IRQ+0x87/0xf8 [] do_IRQ+0x1a/0x25 [ - Valtteri 2012/10/3 Ian Campbell > On Wed, 2012-10-03 at 11:09 +0100, Valtteri Kiviniemi wrote: > > root@xen-2:/var/log/xen# cat xl-lightning.log > > Waiting for domain lightning (domid 132) to die [pid 24083] > > Domain 132 has shut down, reason code 3 0x3 > > Reason code 3 is SHUTDOWN_crash. > > Please can you try to enable guest console logging as described at > http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen#Guest_console_logs > and see if the kernel prints anything at all. > > I'm not sure if such an old kernel has this option but you could also > add "earlyprintk=xen" to the guest command line. > > Do you get any output in the hypervisor dmesg? > > Ian. > > --00504501762a038c7304cb253dc6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I enabled debugging and console logging. This is where it crashe= s:

Parsing config from /etc/xen/lightning.cfg
Daemon running with= PID 4952
Linux version 2.6.16.33-xen-domU-oldgame (root@lightning) (gcc= version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Fri Sep 28 1= 4:56:14 EEST 2012
BIOS-provided physical RAM map:
=A0Xen: 0000000000000000 - 0000000080000= 000 (usable)
1320MB HIGHMEM available.
727MB LOWMEM available.
NX = (Execute Disable) protection: active
early console enabled
Built 1 zo= nelists
Kernel command line: root=3D/dev/xvda1 ro console=3Dxvc0 earlyprintk=3Dxen<= br>Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FP= U exception support... done.
Initializing CPU#0
PID hash table entrie= s: 4096 (order: 12, 65536 bytes)
Xen reported: 3392.374 MHz processor.
disabling early console
Console= : colour dummy device 80x25
Dentry cache hash table entries: 131072 (ord= er: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 26= 2144 bytes)
Software IO TLB disabled
vmalloc area: ee000000-f51fe000, maxmem 2d7fe00= 0
Memory: 2072132k/2097152k available (1917k kernel code, 23952k reserve= d, 537k data, 148k init, 1351688k highmem)
Checking if this processor ho= nours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 6819.95 BogoMIPS (lpj=3D34= 09975)
Mount-cache hash table entries: 512
CPU: L1 I cache: 32K, L1 D= cache: 32K
CPU: L2 cache: 256K
CPU: L3 cache: 8192K
Checking '= ;hlt' instruction... OK.
Initializing CPU#1
Initializing CPU#2
Initializing CPU#3
Initializ= ing CPU#4
Initializing CPU#5
Initializing CPU#6
Brought up 8 CPUs<= br>Initializing CPU#7
migration_cost=3D3
Grant table initialized
NET: Registered protocol family 16
xen_mem: Initialising balloon driver.=
SCSI subsystem initialized
highmem bounce pool size: 64 pages
Ins= talling knfsd (copyright (C) 1996 okir= @monad.swb.de).
Initializing Cryptographic API
io scheduler noop registered
io schedu= ler cfq registered (default)
rtc: IRQ 8 is not free.
i8042.c: No cont= roller found.
loop: loaded (max 8 devices)
Xen virtual console succes= sfully installed as tty1
Event-channel device installed.
netfront: Initialising virtual ethernet = driver.
mice: PS/2 mouse device common for all mice
Netfilter message= s via NETLINK v0.30.
NET: Registered protocol family 2
Registering bl= ock device major 202
blkfront: xvda1: barriers enabled
netfront: device eth0 has copying rece= ive path.
IP route cache hash table entries: 32768 (order: 5, 131072 byt= es)
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)=
TCP bind hash table entries: 65536 (order: 7, 524288 bytes)
TCP: Hash ta= bles configured (established 131072 bind 65536)
TCP reno registered
i= p_conntrack version 2.4 (8192 buckets, 65536 max) - 232 bytes per conntrack=
ip_conntrack_pptp version 3.1 loaded
ip_nat_pptp version 3.0 loaded
i= p_tables: (C) 2000-2006 Netfilter Core Team
ipt_recent v0.3.1: Stephen F= rost <sfrost@snowman.net>.= =A0 http://snowman.net/= projects/ipt_recent/
TCP bic registered
NET: Registered protocol family 1
NET: Registered = protocol family 17
NET: Registered protocol family 15
Bridge firewall= ing registered
802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>
All bugs added by David S. Miller <d= avem@redhat.com>
Using IPI Shortcut mode
end_request: I/O erro= r, dev xvda1, sector 2
EXT3-fs: unable to read superblock
Unable to h= andle kernel paging request at virtual address 05de1ce8
=A0printing eip:
c0231fdc
005c4000 -> *pde =3D 00000000:00000000Oops: 0000 [#1]
SMP
CPU:=A0=A0=A0 0
EIP:=A0=A0=A0 0061:[<c023= 1fdc>]=A0=A0=A0 Not tainted VLI
EFLAGS: 00010007=A0=A0 (2.6.16.33-xen= -domU-oldgame #1)
EIP is at blkif_int+0x7f/0x228
eax: 189c9c00=A0=A0 ebx: c04df900=A0=A0 ecx: ed418000=A0=A0 edx: 05de1c00esi: 00000000=A0=A0 edi: ca010100=A0=A0 ebp: c043d0ac=A0=A0 esp: c0367ec0=
ds: 007b=A0=A0 es: 007b=A0=A0 ss: e021
Process swapper (pid: 0, thre= adinfo=3Dc0366000 task=3Dc030d7c0)
Stack: <0>c200ce24 20539c5e 00000000 00000001 00000001 00000002 00000= 000 00000001
=A0=A0=A0=A0=A0=A0 c04df900 00000000 00000000 c0367f6c c013= 3197 0000011a ed418000 c0367f6c
=A0=A0=A0=A0=A0=A0 0000011a 00008d00 c03= 5c100 0000011a c04df900 c013328f 0000011a 0000000a
Call Trace:
=A0[<c0133197>] handle_IRQ_event+0x38/0xa9
=A0[<= c013328f>] __do_IRQ+0x87/0xf8
=A0[<c0106782>] do_IRQ+0x1a/0x25<= br>=A0[<c0228d85>] evtchn_do_upcall+0x95/0xa9
=A0[<c010504d>= ] hypervisor_callback+0x3d/0x48
=A0[<c0107ecf>] safe_halt+0x7a/0xb2
=A0[<c0102efd>] xen_idle= +0x2b/0x4e
=A0[<c0103014>] cpu_idle+0x52/0x67
=A0[<c036871c&= gt;] start_kernel+0x2b8/0x33c
=A0[<c03681ea>] unknown_bootoption+0= x0/0x27a
Code: 83 ea 01 23 54 24 1c 8d 04 12 01 d0 8d 04 c0 8d 2c 85 40 00 00 00 03 = 69 28 8b 7d 00 8d 14 bf 89 d0 c1 e0 05 29 d0 01 f8 8d 14 08 <8b> 92 e= 8 00 00 00 89 54 24 0c 8d 74 08 7c 80 7e 01 00 74 29 31
=A0<0>Kern= el panic - not syncing: Fatal exception in interrupt
=A0Badness in smp_call_function at arch/i386/kernel/smp-xen.c:520
=A0[&l= t;c010c8fe>] smp_call_function+0x146/0x14b
=A0[<c011ac6e>] prin= tk+0x1b/0x1f
=A0[<c021a120>] do_unblank_screen+0xe/0x129
=A0[&l= t;c010c9a9>] smp_send_stop+0x27/0x60
=A0[<c010c943>] stop_this_cpu+0x0/0x3f
=A0[<c011a149>] panic= +0x5e/0x155
=A0[<c0105948>] die+0x231/0x23b
=A0[<c0110348>= ;] do_page_fault+0x396/0xd30
=A0[<c011eb6b>] getnstimeofday+0x14/0= x37
=A0[<c010ffb2>] do_page_fault+0x0/0xd30
=A0[<c010500b>] erro= r_code+0x2b/0x30
=A0[<c0231fdc>] blkif_int+0x7f/0x228
=A0[<c= 0133197>] handle_IRQ_event+0x38/0xa9
=A0[<c013328f>] __do_IRQ+0= x87/0xf8
=A0[<c0106782>] do_IRQ+0x1a/0x25
=A0[

- Valtteri

2012/10/3 Ian Campbell <Ian.Campbell@citrix.= com>
On Wed, 2012-10-03 at 11:0= 9 +0100, Valtteri Kiviniemi wrote:
> root@xen-2:/var/log/xen# cat xl-lightning.log
> Waiting for domain lightning (domid 132) to die [pid 24083]
> Domain 132 has shut down, reason code 3 0x3

Reason code 3 is SHUTDOWN_crash.

Please can you try to enable guest console logging as described at
http://wiki.xen.org/wiki/Reporting_Bugs_against_X= en#Guest_console_logs
and see if the kernel prints anything at all.

I'm not sure if such an old kernel has this option but you could also add "earlyprintk=3Dxen" to the guest command line.

Do you get any output in the hypervisor dmesg?

Ian.


--00504501762a038c7304cb253dc6-- --===============8757735128085940129== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8757735128085940129==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 10:38:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 10:38:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJMLZ-0006ce-CV; Wed, 03 Oct 2012 10:38:33 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJMLY-0006cI-2E for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 10:38:32 +0000 Received: from [85.158.143.35:42499] by server-2.bemta-4.messagelabs.com id 9B/64-06610-7A51C605; Wed, 03 Oct 2012 10:38:31 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1349260705!4876828!1 X-Originating-IP: [209.85.160.173] X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG, HTML_10_20, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19461 invoked from network); 3 Oct 2012 10:38:26 -0000 Received: from mail-gh0-f173.google.com (HELO mail-gh0-f173.google.com) (209.85.160.173) by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 10:38:26 -0000 Received: by ghy16 with SMTP id 16so2180988ghy.32 for ; Wed, 03 Oct 2012 03:38:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=y3Mu+d0KBCOBOuAImhd4W3oi8g+UvNe/kdsRiDCkss0=; b=F7EN5T/54fv1ZzliKFzdFFW35wQ/W3QqZvQJhSYNq6cr28a276D1m+GjtSbobGP6kd oWj6wgmq7wdB0EYL5d0jBVAjW1/PpWbE6OM0+oWzKxc/IhblOL4l4JGUS/9pS4DnS2vw 84cEXR24aaImUVpzdHYju0p9FvrS/zfEv2y4MMYDUDZtjs1WhwYVbpAB60AcIXdKNEgK ++qKNSctIyQ8dFan4CPX3NJZYhw9iu2OJJI/6UrfVF97t9qykyyrpoOggJtawrG7WK1g KkkpxTs8GrcstZf12qVeCx7ZfsQcIO6oOhl5uSmP6lYEYWl0k4hhZGWEOkkYLiBHe/Qd BcMg== MIME-Version: 1.0 Received: by 10.100.81.5 with SMTP id e5mr387355anb.80.1349260704713; Wed, 03 Oct 2012 03:38:24 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Wed, 3 Oct 2012 03:38:24 -0700 (PDT) In-Reply-To: <1349259542.650.122.camel@zakaz.uk.xensource.com> References: <1349259542.650.122.camel@zakaz.uk.xensource.com> Date: Wed, 3 Oct 2012 13:38:24 +0300 Message-ID: From: Valtteri Kiviniemi To: Ian Campbell Cc: "Xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Xen 4.2.0, xl toolstack cant launch older domUs X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8757735128085940129==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============8757735128085940129== Content-Type: multipart/alternative; boundary=00504501762a038c7304cb253dc6 --00504501762a038c7304cb253dc6 Content-Type: text/plain; charset=ISO-8859-1 Hi, I enabled debugging and console logging. This is where it crashes: Parsing config from /etc/xen/lightning.cfg Daemon running with PID 4952 Linux version 2.6.16.33-xen-domU-oldgame (root@lightning) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Fri Sep 28 14:56:14 EEST 2012 BIOS-provided physical RAM map: Xen: 0000000000000000 - 0000000080000000 (usable) 1320MB HIGHMEM available. 727MB LOWMEM available. NX (Execute Disable) protection: active early console enabled Built 1 zonelists Kernel command line: root=/dev/xvda1 ro console=xvc0 earlyprintk=xen Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 PID hash table entries: 4096 (order: 12, 65536 bytes) Xen reported: 3392.374 MHz processor. disabling early console Console: colour dummy device 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Software IO TLB disabled vmalloc area: ee000000-f51fe000, maxmem 2d7fe000 Memory: 2072132k/2097152k available (1917k kernel code, 23952k reserved, 537k data, 148k init, 1351688k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 6819.95 BogoMIPS (lpj=3409975) Mount-cache hash table entries: 512 CPU: L1 I cache: 32K, L1 D cache: 32K CPU: L2 cache: 256K CPU: L3 cache: 8192K Checking 'hlt' instruction... OK. Initializing CPU#1 Initializing CPU#2 Initializing CPU#3 Initializing CPU#4 Initializing CPU#5 Initializing CPU#6 Brought up 8 CPUs Initializing CPU#7 migration_cost=3 Grant table initialized NET: Registered protocol family 16 xen_mem: Initialising balloon driver. SCSI subsystem initialized highmem bounce pool size: 64 pages Installing knfsd (copyright (C) 1996 okir@monad.swb.de). Initializing Cryptographic API io scheduler noop registered io scheduler cfq registered (default) rtc: IRQ 8 is not free. i8042.c: No controller found. loop: loaded (max 8 devices) Xen virtual console successfully installed as tty1 Event-channel device installed. netfront: Initialising virtual ethernet driver. mice: PS/2 mouse device common for all mice Netfilter messages via NETLINK v0.30. NET: Registered protocol family 2 Registering block device major 202 blkfront: xvda1: barriers enabled netfront: device eth0 has copying receive path. IP route cache hash table entries: 32768 (order: 5, 131072 bytes) TCP established hash table entries: 131072 (order: 8, 1048576 bytes) TCP bind hash table entries: 65536 (order: 7, 524288 bytes) TCP: Hash tables configured (established 131072 bind 65536) TCP reno registered ip_conntrack version 2.4 (8192 buckets, 65536 max) - 232 bytes per conntrack ip_conntrack_pptp version 3.1 loaded ip_nat_pptp version 3.0 loaded ip_tables: (C) 2000-2006 Netfilter Core Team ipt_recent v0.3.1: Stephen Frost . http://snowman.net/projects/ipt_recent/ TCP bic registered NET: Registered protocol family 1 NET: Registered protocol family 17 NET: Registered protocol family 15 Bridge firewalling registered 802.1Q VLAN Support v1.8 Ben Greear All bugs added by David S. Miller Using IPI Shortcut mode end_request: I/O error, dev xvda1, sector 2 EXT3-fs: unable to read superblock Unable to handle kernel paging request at virtual address 05de1ce8 printing eip: c0231fdc 005c4000 -> *pde = 00000000:00000000 Oops: 0000 [#1] SMP CPU: 0 EIP: 0061:[] Not tainted VLI EFLAGS: 00010007 (2.6.16.33-xen-domU-oldgame #1) EIP is at blkif_int+0x7f/0x228 eax: 189c9c00 ebx: c04df900 ecx: ed418000 edx: 05de1c00 esi: 00000000 edi: ca010100 ebp: c043d0ac esp: c0367ec0 ds: 007b es: 007b ss: e021 Process swapper (pid: 0, threadinfo=c0366000 task=c030d7c0) Stack: <0>c200ce24 20539c5e 00000000 00000001 00000001 00000002 00000000 00000001 c04df900 00000000 00000000 c0367f6c c0133197 0000011a ed418000 c0367f6c 0000011a 00008d00 c035c100 0000011a c04df900 c013328f 0000011a 0000000a Call Trace: [] handle_IRQ_event+0x38/0xa9 [] __do_IRQ+0x87/0xf8 [] do_IRQ+0x1a/0x25 [] evtchn_do_upcall+0x95/0xa9 [] hypervisor_callback+0x3d/0x48 [] safe_halt+0x7a/0xb2 [] xen_idle+0x2b/0x4e [] cpu_idle+0x52/0x67 [] start_kernel+0x2b8/0x33c [] unknown_bootoption+0x0/0x27a Code: 83 ea 01 23 54 24 1c 8d 04 12 01 d0 8d 04 c0 8d 2c 85 40 00 00 00 03 69 28 8b 7d 00 8d 14 bf 89 d0 c1 e0 05 29 d0 01 f8 8d 14 08 <8b> 92 e8 00 00 00 89 54 24 0c 8d 74 08 7c 80 7e 01 00 74 29 31 <0>Kernel panic - not syncing: Fatal exception in interrupt Badness in smp_call_function at arch/i386/kernel/smp-xen.c:520 [] smp_call_function+0x146/0x14b [] printk+0x1b/0x1f [] do_unblank_screen+0xe/0x129 [] smp_send_stop+0x27/0x60 [] stop_this_cpu+0x0/0x3f [] panic+0x5e/0x155 [] die+0x231/0x23b [] do_page_fault+0x396/0xd30 [] getnstimeofday+0x14/0x37 [] do_page_fault+0x0/0xd30 [] error_code+0x2b/0x30 [] blkif_int+0x7f/0x228 [] handle_IRQ_event+0x38/0xa9 [] __do_IRQ+0x87/0xf8 [] do_IRQ+0x1a/0x25 [ - Valtteri 2012/10/3 Ian Campbell > On Wed, 2012-10-03 at 11:09 +0100, Valtteri Kiviniemi wrote: > > root@xen-2:/var/log/xen# cat xl-lightning.log > > Waiting for domain lightning (domid 132) to die [pid 24083] > > Domain 132 has shut down, reason code 3 0x3 > > Reason code 3 is SHUTDOWN_crash. > > Please can you try to enable guest console logging as described at > http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen#Guest_console_logs > and see if the kernel prints anything at all. > > I'm not sure if such an old kernel has this option but you could also > add "earlyprintk=xen" to the guest command line. > > Do you get any output in the hypervisor dmesg? > > Ian. > > --00504501762a038c7304cb253dc6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I enabled debugging and console logging. This is where it crashe= s:

Parsing config from /etc/xen/lightning.cfg
Daemon running with= PID 4952
Linux version 2.6.16.33-xen-domU-oldgame (root@lightning) (gcc= version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Fri Sep 28 1= 4:56:14 EEST 2012
BIOS-provided physical RAM map:
=A0Xen: 0000000000000000 - 0000000080000= 000 (usable)
1320MB HIGHMEM available.
727MB LOWMEM available.
NX = (Execute Disable) protection: active
early console enabled
Built 1 zo= nelists
Kernel command line: root=3D/dev/xvda1 ro console=3Dxvc0 earlyprintk=3Dxen<= br>Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FP= U exception support... done.
Initializing CPU#0
PID hash table entrie= s: 4096 (order: 12, 65536 bytes)
Xen reported: 3392.374 MHz processor.
disabling early console
Console= : colour dummy device 80x25
Dentry cache hash table entries: 131072 (ord= er: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 26= 2144 bytes)
Software IO TLB disabled
vmalloc area: ee000000-f51fe000, maxmem 2d7fe00= 0
Memory: 2072132k/2097152k available (1917k kernel code, 23952k reserve= d, 537k data, 148k init, 1351688k highmem)
Checking if this processor ho= nours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 6819.95 BogoMIPS (lpj=3D34= 09975)
Mount-cache hash table entries: 512
CPU: L1 I cache: 32K, L1 D= cache: 32K
CPU: L2 cache: 256K
CPU: L3 cache: 8192K
Checking '= ;hlt' instruction... OK.
Initializing CPU#1
Initializing CPU#2
Initializing CPU#3
Initializ= ing CPU#4
Initializing CPU#5
Initializing CPU#6
Brought up 8 CPUs<= br>Initializing CPU#7
migration_cost=3D3
Grant table initialized
NET: Registered protocol family 16
xen_mem: Initialising balloon driver.=
SCSI subsystem initialized
highmem bounce pool size: 64 pages
Ins= talling knfsd (copyright (C) 1996 okir= @monad.swb.de).
Initializing Cryptographic API
io scheduler noop registered
io schedu= ler cfq registered (default)
rtc: IRQ 8 is not free.
i8042.c: No cont= roller found.
loop: loaded (max 8 devices)
Xen virtual console succes= sfully installed as tty1
Event-channel device installed.
netfront: Initialising virtual ethernet = driver.
mice: PS/2 mouse device common for all mice
Netfilter message= s via NETLINK v0.30.
NET: Registered protocol family 2
Registering bl= ock device major 202
blkfront: xvda1: barriers enabled
netfront: device eth0 has copying rece= ive path.
IP route cache hash table entries: 32768 (order: 5, 131072 byt= es)
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)=
TCP bind hash table entries: 65536 (order: 7, 524288 bytes)
TCP: Hash ta= bles configured (established 131072 bind 65536)
TCP reno registered
i= p_conntrack version 2.4 (8192 buckets, 65536 max) - 232 bytes per conntrack=
ip_conntrack_pptp version 3.1 loaded
ip_nat_pptp version 3.0 loaded
i= p_tables: (C) 2000-2006 Netfilter Core Team
ipt_recent v0.3.1: Stephen F= rost <sfrost@snowman.net>.= =A0 http://snowman.net/= projects/ipt_recent/
TCP bic registered
NET: Registered protocol family 1
NET: Registered = protocol family 17
NET: Registered protocol family 15
Bridge firewall= ing registered
802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>
All bugs added by David S. Miller <d= avem@redhat.com>
Using IPI Shortcut mode
end_request: I/O erro= r, dev xvda1, sector 2
EXT3-fs: unable to read superblock
Unable to h= andle kernel paging request at virtual address 05de1ce8
=A0printing eip:
c0231fdc
005c4000 -> *pde =3D 00000000:00000000Oops: 0000 [#1]
SMP
CPU:=A0=A0=A0 0
EIP:=A0=A0=A0 0061:[<c023= 1fdc>]=A0=A0=A0 Not tainted VLI
EFLAGS: 00010007=A0=A0 (2.6.16.33-xen= -domU-oldgame #1)
EIP is at blkif_int+0x7f/0x228
eax: 189c9c00=A0=A0 ebx: c04df900=A0=A0 ecx: ed418000=A0=A0 edx: 05de1c00esi: 00000000=A0=A0 edi: ca010100=A0=A0 ebp: c043d0ac=A0=A0 esp: c0367ec0=
ds: 007b=A0=A0 es: 007b=A0=A0 ss: e021
Process swapper (pid: 0, thre= adinfo=3Dc0366000 task=3Dc030d7c0)
Stack: <0>c200ce24 20539c5e 00000000 00000001 00000001 00000002 00000= 000 00000001
=A0=A0=A0=A0=A0=A0 c04df900 00000000 00000000 c0367f6c c013= 3197 0000011a ed418000 c0367f6c
=A0=A0=A0=A0=A0=A0 0000011a 00008d00 c03= 5c100 0000011a c04df900 c013328f 0000011a 0000000a
Call Trace:
=A0[<c0133197>] handle_IRQ_event+0x38/0xa9
=A0[<= c013328f>] __do_IRQ+0x87/0xf8
=A0[<c0106782>] do_IRQ+0x1a/0x25<= br>=A0[<c0228d85>] evtchn_do_upcall+0x95/0xa9
=A0[<c010504d>= ] hypervisor_callback+0x3d/0x48
=A0[<c0107ecf>] safe_halt+0x7a/0xb2
=A0[<c0102efd>] xen_idle= +0x2b/0x4e
=A0[<c0103014>] cpu_idle+0x52/0x67
=A0[<c036871c&= gt;] start_kernel+0x2b8/0x33c
=A0[<c03681ea>] unknown_bootoption+0= x0/0x27a
Code: 83 ea 01 23 54 24 1c 8d 04 12 01 d0 8d 04 c0 8d 2c 85 40 00 00 00 03 = 69 28 8b 7d 00 8d 14 bf 89 d0 c1 e0 05 29 d0 01 f8 8d 14 08 <8b> 92 e= 8 00 00 00 89 54 24 0c 8d 74 08 7c 80 7e 01 00 74 29 31
=A0<0>Kern= el panic - not syncing: Fatal exception in interrupt
=A0Badness in smp_call_function at arch/i386/kernel/smp-xen.c:520
=A0[&l= t;c010c8fe>] smp_call_function+0x146/0x14b
=A0[<c011ac6e>] prin= tk+0x1b/0x1f
=A0[<c021a120>] do_unblank_screen+0xe/0x129
=A0[&l= t;c010c9a9>] smp_send_stop+0x27/0x60
=A0[<c010c943>] stop_this_cpu+0x0/0x3f
=A0[<c011a149>] panic= +0x5e/0x155
=A0[<c0105948>] die+0x231/0x23b
=A0[<c0110348>= ;] do_page_fault+0x396/0xd30
=A0[<c011eb6b>] getnstimeofday+0x14/0= x37
=A0[<c010ffb2>] do_page_fault+0x0/0xd30
=A0[<c010500b>] erro= r_code+0x2b/0x30
=A0[<c0231fdc>] blkif_int+0x7f/0x228
=A0[<c= 0133197>] handle_IRQ_event+0x38/0xa9
=A0[<c013328f>] __do_IRQ+0= x87/0xf8
=A0[<c0106782>] do_IRQ+0x1a/0x25
=A0[

- Valtteri

2012/10/3 Ian Campbell <Ian.Campbell@citrix.= com>
On Wed, 2012-10-03 at 11:0= 9 +0100, Valtteri Kiviniemi wrote:
> root@xen-2:/var/log/xen# cat xl-lightning.log
> Waiting for domain lightning (domid 132) to die [pid 24083]
> Domain 132 has shut down, reason code 3 0x3

Reason code 3 is SHUTDOWN_crash.

Please can you try to enable guest console logging as described at
http://wiki.xen.org/wiki/Reporting_Bugs_against_X= en#Guest_console_logs
and see if the kernel prints anything at all.

I'm not sure if such an old kernel has this option but you could also add "earlyprintk=3Dxen" to the guest command line.

Do you get any output in the hypervisor dmesg?

Ian.


--00504501762a038c7304cb253dc6-- --===============8757735128085940129== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8757735128085940129==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 10:39:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 10:39:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJMLy-0006iW-R9; Wed, 03 Oct 2012 10:38:58 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJMLw-0006hx-FC for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 10:38:56 +0000 Received: from [85.158.137.99:27153] by server-13.bemta-3.messagelabs.com id 3C/94-11249-FB51C605; Wed, 03 Oct 2012 10:38:55 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-4.tower-217.messagelabs.com!1349260732!20109848!1 X-Originating-IP: [209.85.213.173] X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG, HTML_20_30, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4169 invoked from network); 3 Oct 2012 10:38:54 -0000 Received: from mail-yx0-f173.google.com (HELO mail-yx0-f173.google.com) (209.85.213.173) by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 10:38:54 -0000 Received: by yenl3 with SMTP id l3so2182746yen.32 for ; Wed, 03 Oct 2012 03:38:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HnlRY9qvIRhd3bJ7wivuCHKkWqXg+zx4y8Xq8hrok8E=; b=PeN7eRbvHRxkXyD8w7BQwzIGLAXmHSP0Q+AfGlsYpM/k0YeH0okcq+j3UGs/QSRtph 3s/njZ16AD7PX4Ss7cGj3MRQ+Dgr9d3z17tVVU8FDiKNE/iTHxoYS8mpfOYwsELqNkt/ InXLBmZYk7IQJtYYH31z96AER94UrEkSHo0BNsOeFKFHu3gf78QhMRSrYBQQJ8rAdKtW oAgA09C1WqL/Yu1qsw4Tuwq59wWTajF3Z/+qhZrhV1Dxqx4q9YtT/BHMT/jqCqBsL/PQ 7MWRByo+tLjJfuKzpe7PhMwAczZ+3BPU5S9C94edZiFXW5Nhd5xgPfe/Ppo+GERxI5UT fcCw== MIME-Version: 1.0 Received: by 10.236.77.7 with SMTP id c7mr1478827yhe.2.1349260732507; Wed, 03 Oct 2012 03:38:52 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Wed, 3 Oct 2012 03:38:52 -0700 (PDT) In-Reply-To: References: <1349256606.650.120.camel@zakaz.uk.xensource.com> Date: Wed, 3 Oct 2012 13:38:52 +0300 Message-ID: From: Valtteri Kiviniemi To: Ian Campbell Cc: "Xen-devel@lists.xen.org" Subject: Re: [Xen-devel] xlu_cfg_get_defbool error when trying to start domU X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4351700847196524765==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============4351700847196524765== Content-Type: multipart/alternative; boundary=20cf300514baaba75404cb253e6f --20cf300514baaba75404cb253e6f Content-Type: text/plain; charset=ISO-8859-1 Hi, Sorry. I accidently replied to wrong thread. Ignore this. - Valtteri 2012/10/3 Valtteri Kiviniemi > Hi, > > I enabled debugging and console logging. This is where it crashes: > > Parsing config from /etc/xen/lightning.cfg > Daemon running with PID 4952 > Linux version 2.6.16.33-xen-domU-oldgame (root@lightning) (gcc version > 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Fri Sep 28 14:56:14 > EEST 2012 > BIOS-provided physical RAM map: > Xen: 0000000000000000 - 0000000080000000 (usable) > 1320MB HIGHMEM available. > 727MB LOWMEM available. > NX (Execute Disable) protection: active > early console enabled > Built 1 zonelists > Kernel command line: root=/dev/xvda1 ro console=xvc0 earlyprintk=xen > Enabling fast FPU save and restore... done. > Enabling unmasked SIMD FPU exception support... done. > Initializing CPU#0 > PID hash table entries: 4096 (order: 12, 65536 bytes) > Xen reported: 3392.374 MHz processor. > disabling early console > Console: colour dummy device 80x25 > Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) > Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) > Software IO TLB disabled > vmalloc area: ee000000-f51fe000, maxmem 2d7fe000 > Memory: 2072132k/2097152k available (1917k kernel code, 23952k reserved, > 537k data, 148k init, 1351688k highmem) > Checking if this processor honours the WP bit even in supervisor mode... > Ok. > Calibrating delay using timer specific routine.. 6819.95 BogoMIPS > (lpj=3409975) > Mount-cache hash table entries: 512 > CPU: L1 I cache: 32K, L1 D cache: 32K > CPU: L2 cache: 256K > CPU: L3 cache: 8192K > Checking 'hlt' instruction... OK. > Initializing CPU#1 > Initializing CPU#2 > Initializing CPU#3 > Initializing CPU#4 > Initializing CPU#5 > Initializing CPU#6 > Brought up 8 CPUs > Initializing CPU#7 > migration_cost=3 > Grant table initialized > NET: Registered protocol family 16 > xen_mem: Initialising balloon driver. > SCSI subsystem initialized > highmem bounce pool size: 64 pages > Installing knfsd (copyright (C) 1996 okir@monad.swb.de). > Initializing Cryptographic API > io scheduler noop registered > io scheduler cfq registered (default) > rtc: IRQ 8 is not free. > i8042.c: No controller found. > loop: loaded (max 8 devices) > Xen virtual console successfully installed as tty1 > Event-channel device installed. > netfront: Initialising virtual ethernet driver. > mice: PS/2 mouse device common for all mice > Netfilter messages via NETLINK v0.30. > NET: Registered protocol family 2 > Registering block device major 202 > blkfront: xvda1: barriers enabled > netfront: device eth0 has copying receive path. > IP route cache hash table entries: 32768 (order: 5, 131072 bytes) > TCP established hash table entries: 131072 (order: 8, 1048576 bytes) > TCP bind hash table entries: 65536 (order: 7, 524288 bytes) > TCP: Hash tables configured (established 131072 bind 65536) > TCP reno registered > ip_conntrack version 2.4 (8192 buckets, 65536 max) - 232 bytes per > conntrack > ip_conntrack_pptp version 3.1 loaded > ip_nat_pptp version 3.0 loaded > ip_tables: (C) 2000-2006 Netfilter Core Team > ipt_recent v0.3.1: Stephen Frost . > http://snowman.net/projects/ipt_recent/ > TCP bic registered > NET: Registered protocol family 1 > NET: Registered protocol family 17 > NET: Registered protocol family 15 > Bridge firewalling registered > 802.1Q VLAN Support v1.8 Ben Greear > All bugs added by David S. Miller > Using IPI Shortcut mode > end_request: I/O error, dev xvda1, sector 2 > EXT3-fs: unable to read superblock > Unable to handle kernel paging request at virtual address 05de1ce8 > printing eip: > c0231fdc > 005c4000 -> *pde = 00000000:00000000 > Oops: 0000 [#1] > SMP > CPU: 0 > EIP: 0061:[] Not tainted VLI > EFLAGS: 00010007 (2.6.16.33-xen-domU-oldgame #1) > EIP is at blkif_int+0x7f/0x228 > eax: 189c9c00 ebx: c04df900 ecx: ed418000 edx: 05de1c00 > esi: 00000000 edi: ca010100 ebp: c043d0ac esp: c0367ec0 > ds: 007b es: 007b ss: e021 > Process swapper (pid: 0, threadinfo=c0366000 task=c030d7c0) > Stack: <0>c200ce24 20539c5e 00000000 00000001 00000001 00000002 00000000 > 00000001 > c04df900 00000000 00000000 c0367f6c c0133197 0000011a ed418000 > c0367f6c > 0000011a 00008d00 c035c100 0000011a c04df900 c013328f 0000011a > 0000000a > Call Trace: > [] handle_IRQ_event+0x38/0xa9 > [] __do_IRQ+0x87/0xf8 > [] do_IRQ+0x1a/0x25 > [] evtchn_do_upcall+0x95/0xa9 > [] hypervisor_callback+0x3d/0x48 > [] safe_halt+0x7a/0xb2 > [] xen_idle+0x2b/0x4e > [] cpu_idle+0x52/0x67 > [] start_kernel+0x2b8/0x33c > [] unknown_bootoption+0x0/0x27a > Code: 83 ea 01 23 54 24 1c 8d 04 12 01 d0 8d 04 c0 8d 2c 85 40 00 00 00 03 > 69 28 8b 7d 00 8d 14 bf 89 d0 c1 e0 05 29 d0 01 f8 8d 14 08 <8b> 92 e8 00 > 00 00 89 54 24 0c 8d 74 08 7c 80 7e 01 00 74 29 31 > <0>Kernel panic - not syncing: Fatal exception in interrupt > Badness in smp_call_function at arch/i386/kernel/smp-xen.c:520 > [] smp_call_function+0x146/0x14b > [] printk+0x1b/0x1f > [] do_unblank_screen+0xe/0x129 > [] smp_send_stop+0x27/0x60 > [] stop_this_cpu+0x0/0x3f > [] panic+0x5e/0x155 > [] die+0x231/0x23b > [] do_page_fault+0x396/0xd30 > [] getnstimeofday+0x14/0x37 > [] do_page_fault+0x0/0xd30 > [] error_code+0x2b/0x30 > [] blkif_int+0x7f/0x228 > [] handle_IRQ_event+0x38/0xa9 > [] __do_IRQ+0x87/0xf8 > [] do_IRQ+0x1a/0x25 > [ > > > > 2012/10/3 Valtteri Kiviniemi > >> Hi, >> >> Ah, I missed that one, thanks! Its working now when using --libdir >> configure option. >> >> - Valtteri >> >> >> 2012/10/3 Ian Campbell >> >>> On Wed, 2012-10-03 at 10:16 +0100, Valtteri Kiviniemi wrote: >>> > Hi, >>> > >>> > I just upgraded from Xen 4.0.4 to Xen 4.2.0. When I'm trying to start >>> > domU using the new xl toolstack I get the following error message: >>> > >>> > Parsing config from /etc/xen/domu1.cfg >>> > xl: symbol lookup error: xl: undefined symbol: xlu_cfg_get_defbool >>> >>> This (usually) means that your libraries are somehow out of sync. >>> >>> Perhaps check /usr/lib and /usr/lib64 and the output of "ldd xl" and >>> make sure the libraries it is picking up are the 4.2 versions. >>> >>> If you are picking up old versions from /usr/lib64 while the new >>> versions are in lib64 then perhaps you need to pass --libdir to >>> configure as described in http://wiki.xen.org/wiki/Xen_4.2_Release_Notes >>> >>> Ian. >>> >>> > When lauching xend and using xm create the domU starts up normally. >>> > >>> > - Valtteri >>> > >>> >>> >>> >> > --20cf300514baaba75404cb253e6f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Sorry. I accidently replied to wrong thread. Ignore this.
- Valtteri

2012/10/3 Valtteri Kiviniemi = <kiviniemi.valtteri@gmail.com>
Hi,

I enabled debugging and console l= ogging. This is where it crashes:

Parsing config from /etc/xen/light= ning.cfg
Daemon running with PID 4952
Linux version 2.6.16.33-xen-domU-oldgame (r= oot@lightning) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) = #1 SMP Fri Sep 28 14:56:14 EEST 2012
BIOS-provided physical RAM map:
=A0Xen: 0000000000000000 - 0000000080000= 000 (usable)
1320MB HIGHMEM available.
727MB LOWMEM available.
NX = (Execute Disable) protection: active
early console enabled
Built 1 zo= nelists
Kernel command line: root=3D/dev/xvda1 ro console=3Dxvc0 earlyprintk=3Dxen<= br>Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FP= U exception support... done.
Initializing CPU#0
PID hash table entrie= s: 4096 (order: 12, 65536 bytes)
Xen reported: 3392.374 MHz processor.
disabling early console
Console= : colour dummy device 80x25
Dentry cache hash table entries: 131072 (ord= er: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 26= 2144 bytes)
Software IO TLB disabled
vmalloc area: ee000000-f51fe000, maxmem 2d7fe00= 0
Memory: 2072132k/2097152k available (1917k kernel code, 23952k reserve= d, 537k data, 148k init, 1351688k highmem)
Checking if this processor ho= nours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 6819.95 BogoMIPS (lpj=3D34= 09975)
Mount-cache hash table entries: 512
CPU: L1 I cache: 32K, L1 D= cache: 32K
CPU: L2 cache: 256K
CPU: L3 cache: 8192K
Checking '= ;hlt' instruction... OK.
Initializing CPU#1
Initializing CPU#2
Initializing CPU#3
Initializ= ing CPU#4
Initializing CPU#5
Initializing CPU#6
Brought up 8 CPUs<= br>Initializing CPU#7
migration_cost=3D3
Grant table initialized
NET: Registered protocol family 16
xen_mem: Initialising balloon driver.=
SCSI subsystem initialized
highmem bounce pool size: 64 pages
Ins= talling knfsd (copyright (C) 1996 okir@monad.swb.de).
Initializing Cryptographic API
io scheduler noop registered
io schedu= ler cfq registered (default)
rtc: IRQ 8 is not free.
i8042.c: No cont= roller found.
loop: loaded (max 8 devices)
Xen virtual console succes= sfully installed as tty1
Event-channel device installed.
netfront: Initialising virtual ethernet = driver.
mice: PS/2 mouse device common for all mice
Netfilter message= s via NETLINK v0.30.
NET: Registered protocol family 2
Registering bl= ock device major 202
blkfront: xvda1: barriers enabled
netfront: device eth0 has copying rece= ive path.
IP route cache hash table entries: 32768 (order: 5, 131072 byt= es)
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)=
TCP bind hash table entries: 65536 (order: 7, 524288 bytes)
TCP: Hash ta= bles configured (established 131072 bind 65536)
TCP reno registered
i= p_conntrack version 2.4 (8192 buckets, 65536 max) - 232 bytes per conntrack=
ip_conntrack_pptp version 3.1 loaded
ip_nat_pptp version 3.0 loaded
i= p_tables: (C) 2000-2006 Netfilter Core Team
ipt_recent v0.3.1: Stephen F= rost <sfrost@sno= wman.net>.=A0 http://snowman.net/projects/ipt_recent/
TCP bic registered
NET: Registered protocol family 1
NET: Registered = protocol family 17
NET: Registered protocol family 15
Bridge firewall= ing registered
802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>=
All bugs added by David S. Miller <davem@redhat.com>
Using IPI Shortcut mode
end= _request: I/O error, dev xvda1, sector 2
EXT3-fs: unable to read superbl= ock
Unable to handle kernel paging request at virtual address 05de1ce8
=A0printing eip:
c0231fdc
005c4000 -> *pde =3D 00000000:00000000Oops: 0000 [#1]
SMP
CPU:=A0=A0=A0 0
EIP:=A0=A0=A0 0061:[<c023= 1fdc>]=A0=A0=A0 Not tainted VLI
EFLAGS: 00010007=A0=A0 (2.6.16.33-xen= -domU-oldgame #1)
EIP is at blkif_int+0x7f/0x228
eax: 189c9c00=A0=A0 ebx: c04df900=A0=A0 ecx: ed418000=A0=A0 edx: 05de1c00esi: 00000000=A0=A0 edi: ca010100=A0=A0 ebp: c043d0ac=A0=A0 esp: c0367ec0=
ds: 007b=A0=A0 es: 007b=A0=A0 ss: e021
Process swapper (pid: 0, thre= adinfo=3Dc0366000 task=3Dc030d7c0)
Stack: <0>c200ce24 20539c5e 00000000 00000001 00000001 00000002 00000= 000 00000001
=A0=A0=A0=A0=A0=A0 c04df900 00000000 00000000 c0367f6c c013= 3197 0000011a ed418000 c0367f6c
=A0=A0=A0=A0=A0=A0 0000011a 00008d00 c03= 5c100 0000011a c04df900 c013328f 0000011a 0000000a
Call Trace:
=A0[<c0133197>] handle_IRQ_event+0x38/0xa9
=A0[<= c013328f>] __do_IRQ+0x87/0xf8
=A0[<c0106782>] do_IRQ+0x1a/0x25<= br>=A0[<c0228d85>] evtchn_do_upcall+0x95/0xa9
=A0[<c010504d>= ] hypervisor_callback+0x3d/0x48
=A0[<c0107ecf>] safe_halt+0x7a/0xb2
=A0[<c0102efd>] xen_idle= +0x2b/0x4e
=A0[<c0103014>] cpu_idle+0x52/0x67
=A0[<c036871c&= gt;] start_kernel+0x2b8/0x33c
=A0[<c03681ea>] unknown_bootoption+0= x0/0x27a
Code: 83 ea 01 23 54 24 1c 8d 04 12 01 d0 8d 04 c0 8d 2c 85 40 00 00 00 03 = 69 28 8b 7d 00 8d 14 bf 89 d0 c1 e0 05 29 d0 01 f8 8d 14 08 <8b> 92 e= 8 00 00 00 89 54 24 0c 8d 74 08 7c 80 7e 01 00 74 29 31
=A0<0>Kern= el panic - not syncing: Fatal exception in interrupt
=A0Badness in smp_call_function at arch/i386/kernel/smp-xen.c:520
=A0[&l= t;c010c8fe>] smp_call_function+0x146/0x14b
=A0[<c011ac6e>] prin= tk+0x1b/0x1f
=A0[<c021a120>] do_unblank_screen+0xe/0x129
=A0[&l= t;c010c9a9>] smp_send_stop+0x27/0x60
=A0[<c010c943>] stop_this_cpu+0x0/0x3f
=A0[<c011a149>] panic= +0x5e/0x155
=A0[<c0105948>] die+0x231/0x23b
=A0[<c0110348>= ;] do_page_fault+0x396/0xd30
=A0[<c011eb6b>] getnstimeofday+0x14/0= x37
=A0[<c010ffb2>] do_page_fault+0x0/0xd30
=A0[<c010500b>] erro= r_code+0x2b/0x30
=A0[<c0231fdc>] blkif_int+0x7f/0x228
=A0[<c= 0133197>] handle_IRQ_event+0x38/0xa9
=A0[<c013328f>] __do_IRQ+0= x87/0xf8
=A0[<c0106782>] do_IRQ+0x1a/0x25
=A0[



2012/10/3 Valtteri Kivini= emi <kiviniemi.valtteri@gmail.com>
Hi,

Ah, I missed that one, thanks! It= s working now when using --libdir configure option.

- Valtteri


20= 12/10/3 Ian Campbell <Ian.Campbell@citrix.com>
On Wed, 2012-10-03 at 10:16 +0100, Valt= teri Kiviniemi wrote:
> Hi,
>
> I just upgraded from Xen 4.0.4 to Xen 4.2.0. When I'm trying to st= art
> domU using the new xl toolstack I get the following error message:
>
> Parsing config from /etc/xen/domu1.cfg
> xl: symbol lookup error: xl: undefined symbol: xlu_cfg_get_defbool

This (usually) means that your libraries are somehow out of sync.

Perhaps check /usr/lib and /usr/lib64 and the output of "ldd xl" = and
make sure the libraries it is picking up are the 4.2 versions.

If you are picking up old versions from /usr/lib64 while the new
versions are in lib64 then perhaps you need to pass --libdir to
configure as described in http://wiki.xen.org/wiki/Xen_4.2_Release_Notes<= /a>

Ian.

> When lauching xend and using xm create the domU starts up normally. >
> - Valtteri
>





--20cf300514baaba75404cb253e6f-- --===============4351700847196524765== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============4351700847196524765==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 10:39:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 10:39:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJMLy-0006iW-R9; Wed, 03 Oct 2012 10:38:58 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJMLw-0006hx-FC for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 10:38:56 +0000 Received: from [85.158.137.99:27153] by server-13.bemta-3.messagelabs.com id 3C/94-11249-FB51C605; Wed, 03 Oct 2012 10:38:55 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-4.tower-217.messagelabs.com!1349260732!20109848!1 X-Originating-IP: [209.85.213.173] X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG, HTML_20_30, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4169 invoked from network); 3 Oct 2012 10:38:54 -0000 Received: from mail-yx0-f173.google.com (HELO mail-yx0-f173.google.com) (209.85.213.173) by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 10:38:54 -0000 Received: by yenl3 with SMTP id l3so2182746yen.32 for ; Wed, 03 Oct 2012 03:38:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HnlRY9qvIRhd3bJ7wivuCHKkWqXg+zx4y8Xq8hrok8E=; b=PeN7eRbvHRxkXyD8w7BQwzIGLAXmHSP0Q+AfGlsYpM/k0YeH0okcq+j3UGs/QSRtph 3s/njZ16AD7PX4Ss7cGj3MRQ+Dgr9d3z17tVVU8FDiKNE/iTHxoYS8mpfOYwsELqNkt/ InXLBmZYk7IQJtYYH31z96AER94UrEkSHo0BNsOeFKFHu3gf78QhMRSrYBQQJ8rAdKtW oAgA09C1WqL/Yu1qsw4Tuwq59wWTajF3Z/+qhZrhV1Dxqx4q9YtT/BHMT/jqCqBsL/PQ 7MWRByo+tLjJfuKzpe7PhMwAczZ+3BPU5S9C94edZiFXW5Nhd5xgPfe/Ppo+GERxI5UT fcCw== MIME-Version: 1.0 Received: by 10.236.77.7 with SMTP id c7mr1478827yhe.2.1349260732507; Wed, 03 Oct 2012 03:38:52 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Wed, 3 Oct 2012 03:38:52 -0700 (PDT) In-Reply-To: References: <1349256606.650.120.camel@zakaz.uk.xensource.com> Date: Wed, 3 Oct 2012 13:38:52 +0300 Message-ID: From: Valtteri Kiviniemi To: Ian Campbell Cc: "Xen-devel@lists.xen.org" Subject: Re: [Xen-devel] xlu_cfg_get_defbool error when trying to start domU X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4351700847196524765==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============4351700847196524765== Content-Type: multipart/alternative; boundary=20cf300514baaba75404cb253e6f --20cf300514baaba75404cb253e6f Content-Type: text/plain; charset=ISO-8859-1 Hi, Sorry. I accidently replied to wrong thread. Ignore this. - Valtteri 2012/10/3 Valtteri Kiviniemi > Hi, > > I enabled debugging and console logging. This is where it crashes: > > Parsing config from /etc/xen/lightning.cfg > Daemon running with PID 4952 > Linux version 2.6.16.33-xen-domU-oldgame (root@lightning) (gcc version > 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Fri Sep 28 14:56:14 > EEST 2012 > BIOS-provided physical RAM map: > Xen: 0000000000000000 - 0000000080000000 (usable) > 1320MB HIGHMEM available. > 727MB LOWMEM available. > NX (Execute Disable) protection: active > early console enabled > Built 1 zonelists > Kernel command line: root=/dev/xvda1 ro console=xvc0 earlyprintk=xen > Enabling fast FPU save and restore... done. > Enabling unmasked SIMD FPU exception support... done. > Initializing CPU#0 > PID hash table entries: 4096 (order: 12, 65536 bytes) > Xen reported: 3392.374 MHz processor. > disabling early console > Console: colour dummy device 80x25 > Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) > Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) > Software IO TLB disabled > vmalloc area: ee000000-f51fe000, maxmem 2d7fe000 > Memory: 2072132k/2097152k available (1917k kernel code, 23952k reserved, > 537k data, 148k init, 1351688k highmem) > Checking if this processor honours the WP bit even in supervisor mode... > Ok. > Calibrating delay using timer specific routine.. 6819.95 BogoMIPS > (lpj=3409975) > Mount-cache hash table entries: 512 > CPU: L1 I cache: 32K, L1 D cache: 32K > CPU: L2 cache: 256K > CPU: L3 cache: 8192K > Checking 'hlt' instruction... OK. > Initializing CPU#1 > Initializing CPU#2 > Initializing CPU#3 > Initializing CPU#4 > Initializing CPU#5 > Initializing CPU#6 > Brought up 8 CPUs > Initializing CPU#7 > migration_cost=3 > Grant table initialized > NET: Registered protocol family 16 > xen_mem: Initialising balloon driver. > SCSI subsystem initialized > highmem bounce pool size: 64 pages > Installing knfsd (copyright (C) 1996 okir@monad.swb.de). > Initializing Cryptographic API > io scheduler noop registered > io scheduler cfq registered (default) > rtc: IRQ 8 is not free. > i8042.c: No controller found. > loop: loaded (max 8 devices) > Xen virtual console successfully installed as tty1 > Event-channel device installed. > netfront: Initialising virtual ethernet driver. > mice: PS/2 mouse device common for all mice > Netfilter messages via NETLINK v0.30. > NET: Registered protocol family 2 > Registering block device major 202 > blkfront: xvda1: barriers enabled > netfront: device eth0 has copying receive path. > IP route cache hash table entries: 32768 (order: 5, 131072 bytes) > TCP established hash table entries: 131072 (order: 8, 1048576 bytes) > TCP bind hash table entries: 65536 (order: 7, 524288 bytes) > TCP: Hash tables configured (established 131072 bind 65536) > TCP reno registered > ip_conntrack version 2.4 (8192 buckets, 65536 max) - 232 bytes per > conntrack > ip_conntrack_pptp version 3.1 loaded > ip_nat_pptp version 3.0 loaded > ip_tables: (C) 2000-2006 Netfilter Core Team > ipt_recent v0.3.1: Stephen Frost . > http://snowman.net/projects/ipt_recent/ > TCP bic registered > NET: Registered protocol family 1 > NET: Registered protocol family 17 > NET: Registered protocol family 15 > Bridge firewalling registered > 802.1Q VLAN Support v1.8 Ben Greear > All bugs added by David S. Miller > Using IPI Shortcut mode > end_request: I/O error, dev xvda1, sector 2 > EXT3-fs: unable to read superblock > Unable to handle kernel paging request at virtual address 05de1ce8 > printing eip: > c0231fdc > 005c4000 -> *pde = 00000000:00000000 > Oops: 0000 [#1] > SMP > CPU: 0 > EIP: 0061:[] Not tainted VLI > EFLAGS: 00010007 (2.6.16.33-xen-domU-oldgame #1) > EIP is at blkif_int+0x7f/0x228 > eax: 189c9c00 ebx: c04df900 ecx: ed418000 edx: 05de1c00 > esi: 00000000 edi: ca010100 ebp: c043d0ac esp: c0367ec0 > ds: 007b es: 007b ss: e021 > Process swapper (pid: 0, threadinfo=c0366000 task=c030d7c0) > Stack: <0>c200ce24 20539c5e 00000000 00000001 00000001 00000002 00000000 > 00000001 > c04df900 00000000 00000000 c0367f6c c0133197 0000011a ed418000 > c0367f6c > 0000011a 00008d00 c035c100 0000011a c04df900 c013328f 0000011a > 0000000a > Call Trace: > [] handle_IRQ_event+0x38/0xa9 > [] __do_IRQ+0x87/0xf8 > [] do_IRQ+0x1a/0x25 > [] evtchn_do_upcall+0x95/0xa9 > [] hypervisor_callback+0x3d/0x48 > [] safe_halt+0x7a/0xb2 > [] xen_idle+0x2b/0x4e > [] cpu_idle+0x52/0x67 > [] start_kernel+0x2b8/0x33c > [] unknown_bootoption+0x0/0x27a > Code: 83 ea 01 23 54 24 1c 8d 04 12 01 d0 8d 04 c0 8d 2c 85 40 00 00 00 03 > 69 28 8b 7d 00 8d 14 bf 89 d0 c1 e0 05 29 d0 01 f8 8d 14 08 <8b> 92 e8 00 > 00 00 89 54 24 0c 8d 74 08 7c 80 7e 01 00 74 29 31 > <0>Kernel panic - not syncing: Fatal exception in interrupt > Badness in smp_call_function at arch/i386/kernel/smp-xen.c:520 > [] smp_call_function+0x146/0x14b > [] printk+0x1b/0x1f > [] do_unblank_screen+0xe/0x129 > [] smp_send_stop+0x27/0x60 > [] stop_this_cpu+0x0/0x3f > [] panic+0x5e/0x155 > [] die+0x231/0x23b > [] do_page_fault+0x396/0xd30 > [] getnstimeofday+0x14/0x37 > [] do_page_fault+0x0/0xd30 > [] error_code+0x2b/0x30 > [] blkif_int+0x7f/0x228 > [] handle_IRQ_event+0x38/0xa9 > [] __do_IRQ+0x87/0xf8 > [] do_IRQ+0x1a/0x25 > [ > > > > 2012/10/3 Valtteri Kiviniemi > >> Hi, >> >> Ah, I missed that one, thanks! Its working now when using --libdir >> configure option. >> >> - Valtteri >> >> >> 2012/10/3 Ian Campbell >> >>> On Wed, 2012-10-03 at 10:16 +0100, Valtteri Kiviniemi wrote: >>> > Hi, >>> > >>> > I just upgraded from Xen 4.0.4 to Xen 4.2.0. When I'm trying to start >>> > domU using the new xl toolstack I get the following error message: >>> > >>> > Parsing config from /etc/xen/domu1.cfg >>> > xl: symbol lookup error: xl: undefined symbol: xlu_cfg_get_defbool >>> >>> This (usually) means that your libraries are somehow out of sync. >>> >>> Perhaps check /usr/lib and /usr/lib64 and the output of "ldd xl" and >>> make sure the libraries it is picking up are the 4.2 versions. >>> >>> If you are picking up old versions from /usr/lib64 while the new >>> versions are in lib64 then perhaps you need to pass --libdir to >>> configure as described in http://wiki.xen.org/wiki/Xen_4.2_Release_Notes >>> >>> Ian. >>> >>> > When lauching xend and using xm create the domU starts up normally. >>> > >>> > - Valtteri >>> > >>> >>> >>> >> > --20cf300514baaba75404cb253e6f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Sorry. I accidently replied to wrong thread. Ignore this.
- Valtteri

2012/10/3 Valtteri Kiviniemi = <kiviniemi.valtteri@gmail.com>
Hi,

I enabled debugging and console l= ogging. This is where it crashes:

Parsing config from /etc/xen/light= ning.cfg
Daemon running with PID 4952
Linux version 2.6.16.33-xen-domU-oldgame (r= oot@lightning) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) = #1 SMP Fri Sep 28 14:56:14 EEST 2012
BIOS-provided physical RAM map:
=A0Xen: 0000000000000000 - 0000000080000= 000 (usable)
1320MB HIGHMEM available.
727MB LOWMEM available.
NX = (Execute Disable) protection: active
early console enabled
Built 1 zo= nelists
Kernel command line: root=3D/dev/xvda1 ro console=3Dxvc0 earlyprintk=3Dxen<= br>Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FP= U exception support... done.
Initializing CPU#0
PID hash table entrie= s: 4096 (order: 12, 65536 bytes)
Xen reported: 3392.374 MHz processor.
disabling early console
Console= : colour dummy device 80x25
Dentry cache hash table entries: 131072 (ord= er: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 26= 2144 bytes)
Software IO TLB disabled
vmalloc area: ee000000-f51fe000, maxmem 2d7fe00= 0
Memory: 2072132k/2097152k available (1917k kernel code, 23952k reserve= d, 537k data, 148k init, 1351688k highmem)
Checking if this processor ho= nours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 6819.95 BogoMIPS (lpj=3D34= 09975)
Mount-cache hash table entries: 512
CPU: L1 I cache: 32K, L1 D= cache: 32K
CPU: L2 cache: 256K
CPU: L3 cache: 8192K
Checking '= ;hlt' instruction... OK.
Initializing CPU#1
Initializing CPU#2
Initializing CPU#3
Initializ= ing CPU#4
Initializing CPU#5
Initializing CPU#6
Brought up 8 CPUs<= br>Initializing CPU#7
migration_cost=3D3
Grant table initialized
NET: Registered protocol family 16
xen_mem: Initialising balloon driver.=
SCSI subsystem initialized
highmem bounce pool size: 64 pages
Ins= talling knfsd (copyright (C) 1996 okir@monad.swb.de).
Initializing Cryptographic API
io scheduler noop registered
io schedu= ler cfq registered (default)
rtc: IRQ 8 is not free.
i8042.c: No cont= roller found.
loop: loaded (max 8 devices)
Xen virtual console succes= sfully installed as tty1
Event-channel device installed.
netfront: Initialising virtual ethernet = driver.
mice: PS/2 mouse device common for all mice
Netfilter message= s via NETLINK v0.30.
NET: Registered protocol family 2
Registering bl= ock device major 202
blkfront: xvda1: barriers enabled
netfront: device eth0 has copying rece= ive path.
IP route cache hash table entries: 32768 (order: 5, 131072 byt= es)
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)=
TCP bind hash table entries: 65536 (order: 7, 524288 bytes)
TCP: Hash ta= bles configured (established 131072 bind 65536)
TCP reno registered
i= p_conntrack version 2.4 (8192 buckets, 65536 max) - 232 bytes per conntrack=
ip_conntrack_pptp version 3.1 loaded
ip_nat_pptp version 3.0 loaded
i= p_tables: (C) 2000-2006 Netfilter Core Team
ipt_recent v0.3.1: Stephen F= rost <sfrost@sno= wman.net>.=A0 http://snowman.net/projects/ipt_recent/
TCP bic registered
NET: Registered protocol family 1
NET: Registered = protocol family 17
NET: Registered protocol family 15
Bridge firewall= ing registered
802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>=
All bugs added by David S. Miller <davem@redhat.com>
Using IPI Shortcut mode
end= _request: I/O error, dev xvda1, sector 2
EXT3-fs: unable to read superbl= ock
Unable to handle kernel paging request at virtual address 05de1ce8
=A0printing eip:
c0231fdc
005c4000 -> *pde =3D 00000000:00000000Oops: 0000 [#1]
SMP
CPU:=A0=A0=A0 0
EIP:=A0=A0=A0 0061:[<c023= 1fdc>]=A0=A0=A0 Not tainted VLI
EFLAGS: 00010007=A0=A0 (2.6.16.33-xen= -domU-oldgame #1)
EIP is at blkif_int+0x7f/0x228
eax: 189c9c00=A0=A0 ebx: c04df900=A0=A0 ecx: ed418000=A0=A0 edx: 05de1c00esi: 00000000=A0=A0 edi: ca010100=A0=A0 ebp: c043d0ac=A0=A0 esp: c0367ec0=
ds: 007b=A0=A0 es: 007b=A0=A0 ss: e021
Process swapper (pid: 0, thre= adinfo=3Dc0366000 task=3Dc030d7c0)
Stack: <0>c200ce24 20539c5e 00000000 00000001 00000001 00000002 00000= 000 00000001
=A0=A0=A0=A0=A0=A0 c04df900 00000000 00000000 c0367f6c c013= 3197 0000011a ed418000 c0367f6c
=A0=A0=A0=A0=A0=A0 0000011a 00008d00 c03= 5c100 0000011a c04df900 c013328f 0000011a 0000000a
Call Trace:
=A0[<c0133197>] handle_IRQ_event+0x38/0xa9
=A0[<= c013328f>] __do_IRQ+0x87/0xf8
=A0[<c0106782>] do_IRQ+0x1a/0x25<= br>=A0[<c0228d85>] evtchn_do_upcall+0x95/0xa9
=A0[<c010504d>= ] hypervisor_callback+0x3d/0x48
=A0[<c0107ecf>] safe_halt+0x7a/0xb2
=A0[<c0102efd>] xen_idle= +0x2b/0x4e
=A0[<c0103014>] cpu_idle+0x52/0x67
=A0[<c036871c&= gt;] start_kernel+0x2b8/0x33c
=A0[<c03681ea>] unknown_bootoption+0= x0/0x27a
Code: 83 ea 01 23 54 24 1c 8d 04 12 01 d0 8d 04 c0 8d 2c 85 40 00 00 00 03 = 69 28 8b 7d 00 8d 14 bf 89 d0 c1 e0 05 29 d0 01 f8 8d 14 08 <8b> 92 e= 8 00 00 00 89 54 24 0c 8d 74 08 7c 80 7e 01 00 74 29 31
=A0<0>Kern= el panic - not syncing: Fatal exception in interrupt
=A0Badness in smp_call_function at arch/i386/kernel/smp-xen.c:520
=A0[&l= t;c010c8fe>] smp_call_function+0x146/0x14b
=A0[<c011ac6e>] prin= tk+0x1b/0x1f
=A0[<c021a120>] do_unblank_screen+0xe/0x129
=A0[&l= t;c010c9a9>] smp_send_stop+0x27/0x60
=A0[<c010c943>] stop_this_cpu+0x0/0x3f
=A0[<c011a149>] panic= +0x5e/0x155
=A0[<c0105948>] die+0x231/0x23b
=A0[<c0110348>= ;] do_page_fault+0x396/0xd30
=A0[<c011eb6b>] getnstimeofday+0x14/0= x37
=A0[<c010ffb2>] do_page_fault+0x0/0xd30
=A0[<c010500b>] erro= r_code+0x2b/0x30
=A0[<c0231fdc>] blkif_int+0x7f/0x228
=A0[<c= 0133197>] handle_IRQ_event+0x38/0xa9
=A0[<c013328f>] __do_IRQ+0= x87/0xf8
=A0[<c0106782>] do_IRQ+0x1a/0x25
=A0[



2012/10/3 Valtteri Kivini= emi <kiviniemi.valtteri@gmail.com>
Hi,

Ah, I missed that one, thanks! It= s working now when using --libdir configure option.

- Valtteri


20= 12/10/3 Ian Campbell <Ian.Campbell@citrix.com>
On Wed, 2012-10-03 at 10:16 +0100, Valt= teri Kiviniemi wrote:
> Hi,
>
> I just upgraded from Xen 4.0.4 to Xen 4.2.0. When I'm trying to st= art
> domU using the new xl toolstack I get the following error message:
>
> Parsing config from /etc/xen/domu1.cfg
> xl: symbol lookup error: xl: undefined symbol: xlu_cfg_get_defbool

This (usually) means that your libraries are somehow out of sync.

Perhaps check /usr/lib and /usr/lib64 and the output of "ldd xl" = and
make sure the libraries it is picking up are the 4.2 versions.

If you are picking up old versions from /usr/lib64 while the new
versions are in lib64 then perhaps you need to pass --libdir to
configure as described in http://wiki.xen.org/wiki/Xen_4.2_Release_Notes<= /a>

Ian.

> When lauching xend and using xm create the domU starts up normally. >
> - Valtteri
>





--20cf300514baaba75404cb253e6f-- --===============4351700847196524765== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============4351700847196524765==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 10:42:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 10:42:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJMPD-00076c-NN; Wed, 03 Oct 2012 10:42:19 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJMPB-00076S-VG for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 10:42:18 +0000 Received: from [85.158.139.211:25067] by server-12.bemta-5.messagelabs.com id 71/98-20729-9861C605; Wed, 03 Oct 2012 10:42:17 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-13.tower-206.messagelabs.com!1349260933!16918630!1 X-Originating-IP: [209.85.160.173] X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG, HTML_20_30, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5164 invoked from network); 3 Oct 2012 10:42:15 -0000 Received: from mail-gh0-f173.google.com (HELO mail-gh0-f173.google.com) (209.85.160.173) by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 10:42:15 -0000 Received: by ghy16 with SMTP id 16so2181676ghy.32 for ; Wed, 03 Oct 2012 03:42:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8ARgKGphMuwS1cmxczVtTJiXjFG4Y/gq484PV07Foe4=; b=c5ifH6S4H3h1ac8gUtqxLZdHILPYa6MLkSNmS+7JpyHHjF+5mzpRGCDegwc2r8WCYW 0jdstreKA+COW42ql4wE0JqVDDJVBEFuQutCpFZAneAbInjkmanSIQicB4WfgrgofId5 PMIAWjiMXdAKeyOD3VJrrnhiodijaK6qBUnjAYN7OyuCi6daJZVQfMdXUZ3fxy3vvW+o tmdUmv9UCRvB82Eu6hosHjBs8xKZ+7+e99VVaTegNkuvPAJ4P8nor7qYorfnR43ovX15 XdZYJpCiabuTS77jlNjApZvVM+9viiVrqY4jWnzbazAzdZw4eSl8t95MGJ+ulcJ4cEbW UxWQ== MIME-Version: 1.0 Received: by 10.236.9.36 with SMTP id 24mr1382063yhs.63.1349260933565; Wed, 03 Oct 2012 03:42:13 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Wed, 3 Oct 2012 03:42:13 -0700 (PDT) In-Reply-To: References: <1349259542.650.122.camel@zakaz.uk.xensource.com> Date: Wed, 3 Oct 2012 13:42:13 +0300 Message-ID: From: Valtteri Kiviniemi To: Ian Campbell Cc: "Xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Xen 4.2.0, xl toolstack cant launch older domUs X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4677007332287331407==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============4677007332287331407== Content-Type: multipart/alternative; boundary=20cf303dd264a78b0704cb254a1d --20cf303dd264a78b0704cb254a1d Content-Type: text/plain; charset=ISO-8859-1 Hi, I tried to lower vcpus to 1, and now it produces a different crash: Unable to handle kernel NULL pointer dereference at virtual address 00000024 printing eip: c0232139 005c4000 -> *pde = 00000000:00000000 Oops: 0000 [#1] SMP CPU: 0 EIP: 0061:[] Not tainted VLI EFLAGS: 00010097 (2.6.16.33-xen-domU-oldgame #1) EIP is at blkif_int+0x1dc/0x228 eax: 00000000 ebx: 00000001 ecx: c090e000 edx: 00000000 esi: d92d7c7c edi: ca010100 ebp: ed6ea0ac esp: c0367ec0 ds: 007b es: 007b ss: e021 Process swapper (pid: 0, threadinfo=c0366000 task=c030d7c0) Stack: <0>c200ce24 419c18e3 00000000 00000000 00000001 00000002 00000000 00000001 ed6ab7a0 00000000 00000000 c0367f6c c0133197 00000105 c090e000 c0367f6c 00000105 00008280 c035b680 00000105 ed6ab7a0 c013328f 00000105 0000000a Call Trace: [] handle_IRQ_event+0x38/0xa9 [] __do_IRQ+0x87/0xf8 [] do_IRQ+0x1a/0x25 [] evtchn_do_upcall+0x95/0xa9 [] hypervisor_callback+0x3d/0x48 [] safe_halt+0x7a/0xb2 [] xen_idle+0x2b/0x4e [] cpu_idle+0x52/0x67 [] start_kernel+0x2b8/0x33c [] unknown_bootoption+0x0/0x27a Code: c7 04 24 e0 17 30 c0 e8 39 8b ee ff 8b 44 24 38 c7 80 00 14 00 00 00 00 00 00 89 04 24 e8 75 03 00 00 bb a1 ff ff ff 8b 54 24 0c <8b> 42 24 89 44 24 08 89 5c 24 04 89 14 24 e8 3b eb fb ff 85 c0 <0>Kernel panic - not syncing: Fatal exception in interrupt 2012/10/3 Valtteri Kiviniemi > Hi, > > I enabled debugging and console logging. This is where it crashes: > > Parsing config from /etc/xen/lightning.cfg > Daemon running with PID 4952 > Linux version 2.6.16.33-xen-domU-oldgame (root@lightning) (gcc version > 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Fri Sep 28 14:56:14 > EEST 2012 > BIOS-provided physical RAM map: > Xen: 0000000000000000 - 0000000080000000 (usable) > 1320MB HIGHMEM available. > 727MB LOWMEM available. > NX (Execute Disable) protection: active > early console enabled > Built 1 zonelists > Kernel command line: root=/dev/xvda1 ro console=xvc0 earlyprintk=xen > Enabling fast FPU save and restore... done. > Enabling unmasked SIMD FPU exception support... done. > Initializing CPU#0 > PID hash table entries: 4096 (order: 12, 65536 bytes) > Xen reported: 3392.374 MHz processor. > disabling early console > Console: colour dummy device 80x25 > Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) > Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) > Software IO TLB disabled > vmalloc area: ee000000-f51fe000, maxmem 2d7fe000 > Memory: 2072132k/2097152k available (1917k kernel code, 23952k reserved, > 537k data, 148k init, 1351688k highmem) > Checking if this processor honours the WP bit even in supervisor mode... > Ok. > Calibrating delay using timer specific routine.. 6819.95 BogoMIPS > (lpj=3409975) > Mount-cache hash table entries: 512 > CPU: L1 I cache: 32K, L1 D cache: 32K > CPU: L2 cache: 256K > CPU: L3 cache: 8192K > Checking 'hlt' instruction... OK. > Initializing CPU#1 > Initializing CPU#2 > Initializing CPU#3 > Initializing CPU#4 > Initializing CPU#5 > Initializing CPU#6 > Brought up 8 CPUs > Initializing CPU#7 > migration_cost=3 > Grant table initialized > NET: Registered protocol family 16 > xen_mem: Initialising balloon driver. > SCSI subsystem initialized > highmem bounce pool size: 64 pages > Installing knfsd (copyright (C) 1996 okir@monad.swb.de). > Initializing Cryptographic API > io scheduler noop registered > io scheduler cfq registered (default) > rtc: IRQ 8 is not free. > i8042.c: No controller found. > loop: loaded (max 8 devices) > Xen virtual console successfully installed as tty1 > Event-channel device installed. > netfront: Initialising virtual ethernet driver. > mice: PS/2 mouse device common for all mice > Netfilter messages via NETLINK v0.30. > NET: Registered protocol family 2 > Registering block device major 202 > blkfront: xvda1: barriers enabled > netfront: device eth0 has copying receive path. > IP route cache hash table entries: 32768 (order: 5, 131072 bytes) > TCP established hash table entries: 131072 (order: 8, 1048576 bytes) > TCP bind hash table entries: 65536 (order: 7, 524288 bytes) > TCP: Hash tables configured (established 131072 bind 65536) > TCP reno registered > ip_conntrack version 2.4 (8192 buckets, 65536 max) - 232 bytes per > conntrack > ip_conntrack_pptp version 3.1 loaded > ip_nat_pptp version 3.0 loaded > ip_tables: (C) 2000-2006 Netfilter Core Team > ipt_recent v0.3.1: Stephen Frost . > http://snowman.net/projects/ipt_recent/ > TCP bic registered > NET: Registered protocol family 1 > NET: Registered protocol family 17 > NET: Registered protocol family 15 > Bridge firewalling registered > 802.1Q VLAN Support v1.8 Ben Greear > All bugs added by David S. Miller > Using IPI Shortcut mode > end_request: I/O error, dev xvda1, sector 2 > EXT3-fs: unable to read superblock > Unable to handle kernel paging request at virtual address 05de1ce8 > printing eip: > c0231fdc > 005c4000 -> *pde = 00000000:00000000 > Oops: 0000 [#1] > SMP > CPU: 0 > EIP: 0061:[] Not tainted VLI > EFLAGS: 00010007 (2.6.16.33-xen-domU-oldgame #1) > EIP is at blkif_int+0x7f/0x228 > eax: 189c9c00 ebx: c04df900 ecx: ed418000 edx: 05de1c00 > esi: 00000000 edi: ca010100 ebp: c043d0ac esp: c0367ec0 > ds: 007b es: 007b ss: e021 > Process swapper (pid: 0, threadinfo=c0366000 task=c030d7c0) > Stack: <0>c200ce24 20539c5e 00000000 00000001 00000001 00000002 00000000 > 00000001 > c04df900 00000000 00000000 c0367f6c c0133197 0000011a ed418000 > c0367f6c > 0000011a 00008d00 c035c100 0000011a c04df900 c013328f 0000011a > 0000000a > Call Trace: > [] handle_IRQ_event+0x38/0xa9 > [] __do_IRQ+0x87/0xf8 > [] do_IRQ+0x1a/0x25 > [] evtchn_do_upcall+0x95/0xa9 > [] hypervisor_callback+0x3d/0x48 > [] safe_halt+0x7a/0xb2 > [] xen_idle+0x2b/0x4e > [] cpu_idle+0x52/0x67 > [] start_kernel+0x2b8/0x33c > [] unknown_bootoption+0x0/0x27a > Code: 83 ea 01 23 54 24 1c 8d 04 12 01 d0 8d 04 c0 8d 2c 85 40 00 00 00 03 > 69 28 8b 7d 00 8d 14 bf 89 d0 c1 e0 05 29 d0 01 f8 8d 14 08 <8b> 92 e8 00 > 00 00 89 54 24 0c 8d 74 08 7c 80 7e 01 00 74 29 31 > <0>Kernel panic - not syncing: Fatal exception in interrupt > Badness in smp_call_function at arch/i386/kernel/smp-xen.c:520 > [] smp_call_function+0x146/0x14b > [] printk+0x1b/0x1f > [] do_unblank_screen+0xe/0x129 > [] smp_send_stop+0x27/0x60 > [] stop_this_cpu+0x0/0x3f > [] panic+0x5e/0x155 > [] die+0x231/0x23b > [] do_page_fault+0x396/0xd30 > [] getnstimeofday+0x14/0x37 > [] do_page_fault+0x0/0xd30 > [] error_code+0x2b/0x30 > [] blkif_int+0x7f/0x228 > [] handle_IRQ_event+0x38/0xa9 > [] __do_IRQ+0x87/0xf8 > [] do_IRQ+0x1a/0x25 > [ > > - Valtteri > > > 2012/10/3 Ian Campbell > >> On Wed, 2012-10-03 at 11:09 +0100, Valtteri Kiviniemi wrote: >> > root@xen-2:/var/log/xen# cat xl-lightning.log >> > Waiting for domain lightning (domid 132) to die [pid 24083] >> > Domain 132 has shut down, reason code 3 0x3 >> >> Reason code 3 is SHUTDOWN_crash. >> >> Please can you try to enable guest console logging as described at >> http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen#Guest_console_logs >> and see if the kernel prints anything at all. >> >> I'm not sure if such an old kernel has this option but you could also >> add "earlyprintk=xen" to the guest command line. >> >> Do you get any output in the hypervisor dmesg? >> >> Ian. >> >> > --20cf303dd264a78b0704cb254a1d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I tried to lower vcpus to 1, and now it produces a different cra= sh:

Unable to handle kernel NULL pointer dereference at virtual addr= ess 00000024
=A0printing eip:
c0232139
005c4000 -> *pde =3D 000= 00000:00000000
Oops: 0000 [#1]
SMP
CPU:=A0=A0=A0 0
EIP:=A0=A0=A0 0061:[<c02321= 39>]=A0=A0=A0 Not tainted VLI
EFLAGS: 00010097=A0=A0 (2.6.16.33-xen-d= omU-oldgame #1)
EIP is at blkif_int+0x1dc/0x228
eax: 00000000=A0=A0 e= bx: 00000001=A0=A0 ecx: c090e000=A0=A0 edx: 00000000
esi: d92d7c7c=A0=A0 edi: ca010100=A0=A0 ebp: ed6ea0ac=A0=A0 esp: c0367ec0ds: 007b=A0=A0 es: 007b=A0=A0 ss: e021
Process swapper (pid: 0, thread= info=3Dc0366000 task=3Dc030d7c0)
Stack: <0>c200ce24 419c18e3 00000= 000 00000000 00000001 00000002 00000000 00000001
=A0=A0=A0=A0=A0=A0 ed6ab7a0 00000000 00000000 c0367f6c c0133197 00000105 c0= 90e000 c0367f6c
=A0=A0=A0=A0=A0=A0 00000105 00008280 c035b680 00000105 e= d6ab7a0 c013328f 00000105 0000000a
Call Trace:
=A0[<c0133197>] = handle_IRQ_event+0x38/0xa9
=A0[<c013328f>] __do_IRQ+0x87/0xf8
=A0[<c0106782>] do_IRQ+0x= 1a/0x25
=A0[<c0228d85>] evtchn_do_upcall+0x95/0xa9
=A0[<c010= 504d>] hypervisor_callback+0x3d/0x48
=A0[<c0107ecf>] safe_halt+= 0x7a/0xb2
=A0[<c0102efd>] xen_idle+0x2b/0x4e
=A0[<c0103014>] cpu_idle+= 0x52/0x67
=A0[<c036871c>] start_kernel+0x2b8/0x33c
=A0[<c036= 81ea>] unknown_bootoption+0x0/0x27a
Code: c7 04 24 e0 17 30 c0 e8 39 = 8b ee ff 8b 44 24 38 c7 80 00 14 00 00 00 00 00 00 89 04 24 e8 75 03 00 00 = bb a1 ff ff ff 8b 54 24 0c <8b> 42 24 89 44 24 08 89 5c 24 04 89 14 2= 4 e8 3b eb fb ff 85 c0
=A0<0>Kernel panic - not syncing: Fatal exception in interrupt

2012/10/3 Valtteri Kiviniemi <k= iviniemi.valtteri@gmail.com>
Hi,

I enabled debugging and console l= ogging. This is where it crashes:

Parsing config from /etc/xen/light= ning.cfg
Daemon running with PID 4952
Linux version 2.6.16.33-xen-domU-oldgame (r= oot@lightning) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) = #1 SMP Fri Sep 28 14:56:14 EEST 2012
BIOS-provided physical RAM map:
=A0Xen: 0000000000000000 - 0000000080000= 000 (usable)
1320MB HIGHMEM available.
727MB LOWMEM available.
NX = (Execute Disable) protection: active
early console enabled
Built 1 zo= nelists
Kernel command line: root=3D/dev/xvda1 ro console=3Dxvc0 earlyprintk=3Dxen<= br>Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FP= U exception support... done.
Initializing CPU#0
PID hash table entrie= s: 4096 (order: 12, 65536 bytes)
Xen reported: 3392.374 MHz processor.
disabling early console
Console= : colour dummy device 80x25
Dentry cache hash table entries: 131072 (ord= er: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 26= 2144 bytes)
Software IO TLB disabled
vmalloc area: ee000000-f51fe000, maxmem 2d7fe00= 0
Memory: 2072132k/2097152k available (1917k kernel code, 23952k reserve= d, 537k data, 148k init, 1351688k highmem)
Checking if this processor ho= nours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 6819.95 BogoMIPS (lpj=3D34= 09975)
Mount-cache hash table entries: 512
CPU: L1 I cache: 32K, L1 D= cache: 32K
CPU: L2 cache: 256K
CPU: L3 cache: 8192K
Checking '= ;hlt' instruction... OK.
Initializing CPU#1
Initializing CPU#2
Initializing CPU#3
Initializ= ing CPU#4
Initializing CPU#5
Initializing CPU#6
Brought up 8 CPUs<= br>Initializing CPU#7
migration_cost=3D3
Grant table initialized
NET: Registered protocol family 16
xen_mem: Initialising balloon driver.=
SCSI subsystem initialized
highmem bounce pool size: 64 pages
Ins= talling knfsd (copyright (C) 1996 okir@monad.swb.de).
Initializing Cryptographic API
io scheduler noop registered
io schedu= ler cfq registered (default)
rtc: IRQ 8 is not free.
i8042.c: No cont= roller found.
loop: loaded (max 8 devices)
Xen virtual console succes= sfully installed as tty1
Event-channel device installed.
netfront: Initialising virtual ethernet = driver.
mice: PS/2 mouse device common for all mice
Netfilter message= s via NETLINK v0.30.
NET: Registered protocol family 2
Registering bl= ock device major 202
blkfront: xvda1: barriers enabled
netfront: device eth0 has copying rece= ive path.
IP route cache hash table entries: 32768 (order: 5, 131072 byt= es)
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)=
TCP bind hash table entries: 65536 (order: 7, 524288 bytes)
TCP: Hash ta= bles configured (established 131072 bind 65536)
TCP reno registered
i= p_conntrack version 2.4 (8192 buckets, 65536 max) - 232 bytes per conntrack=
ip_conntrack_pptp version 3.1 loaded
ip_nat_pptp version 3.0 loaded
i= p_tables: (C) 2000-2006 Netfilter Core Team
ipt_recent v0.3.1: Stephen F= rost <sfrost@sno= wman.net>.=A0 http://snowman.net/projects/ipt_recent/
TCP bic registered
NET: Registered protocol family 1
NET: Registered = protocol family 17
NET: Registered protocol family 15
Bridge firewall= ing registered
802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>=
All bugs added by David S. Miller <davem@redhat.com>
Using IPI Shortcut mode
end= _request: I/O error, dev xvda1, sector 2
EXT3-fs: unable to read superbl= ock
Unable to handle kernel paging request at virtual address 05de1ce8
=A0printing eip:
c0231fdc
005c4000 -> *pde =3D 00000000:00000000Oops: 0000 [#1]
SMP
CPU:=A0=A0=A0 0
EIP:=A0=A0=A0 0061:[<c023= 1fdc>]=A0=A0=A0 Not tainted VLI
EFLAGS: 00010007=A0=A0 (2.6.16.33-xen= -domU-oldgame #1)
EIP is at blkif_int+0x7f/0x228
eax: 189c9c00=A0=A0 ebx: c04df900=A0=A0 ecx: ed418000=A0=A0 edx: 05de1c00esi: 00000000=A0=A0 edi: ca010100=A0=A0 ebp: c043d0ac=A0=A0 esp: c0367ec0=
ds: 007b=A0=A0 es: 007b=A0=A0 ss: e021
Process swapper (pid: 0, thre= adinfo=3Dc0366000 task=3Dc030d7c0)
Stack: <0>c200ce24 20539c5e 00000000 00000001 00000001 00000002 00000= 000 00000001
=A0=A0=A0=A0=A0=A0 c04df900 00000000 00000000 c0367f6c c013= 3197 0000011a ed418000 c0367f6c
=A0=A0=A0=A0=A0=A0 0000011a 00008d00 c03= 5c100 0000011a c04df900 c013328f 0000011a 0000000a
Call Trace:
=A0[<c0133197>] handle_IRQ_event+0x38/0xa9
=A0[<= c013328f>] __do_IRQ+0x87/0xf8
=A0[<c0106782>] do_IRQ+0x1a/0x25<= br>=A0[<c0228d85>] evtchn_do_upcall+0x95/0xa9
=A0[<c010504d>= ] hypervisor_callback+0x3d/0x48
=A0[<c0107ecf>] safe_halt+0x7a/0xb2
=A0[<c0102efd>] xen_idle= +0x2b/0x4e
=A0[<c0103014>] cpu_idle+0x52/0x67
=A0[<c036871c&= gt;] start_kernel+0x2b8/0x33c
=A0[<c03681ea>] unknown_bootoption+0= x0/0x27a
Code: 83 ea 01 23 54 24 1c 8d 04 12 01 d0 8d 04 c0 8d 2c 85 40 00 00 00 03 = 69 28 8b 7d 00 8d 14 bf 89 d0 c1 e0 05 29 d0 01 f8 8d 14 08 <8b> 92 e= 8 00 00 00 89 54 24 0c 8d 74 08 7c 80 7e 01 00 74 29 31
=A0<0>Kern= el panic - not syncing: Fatal exception in interrupt
=A0Badness in smp_call_function at arch/i386/kernel/smp-xen.c:520
=A0[&l= t;c010c8fe>] smp_call_function+0x146/0x14b
=A0[<c011ac6e>] prin= tk+0x1b/0x1f
=A0[<c021a120>] do_unblank_screen+0xe/0x129
=A0[&l= t;c010c9a9>] smp_send_stop+0x27/0x60
=A0[<c010c943>] stop_this_cpu+0x0/0x3f
=A0[<c011a149>] panic= +0x5e/0x155
=A0[<c0105948>] die+0x231/0x23b
=A0[<c0110348>= ;] do_page_fault+0x396/0xd30
=A0[<c011eb6b>] getnstimeofday+0x14/0= x37
=A0[<c010ffb2>] do_page_fault+0x0/0xd30
=A0[<c010500b>] erro= r_code+0x2b/0x30
=A0[<c0231fdc>] blkif_int+0x7f/0x228
=A0[<c= 0133197>] handle_IRQ_event+0x38/0xa9
=A0[<c013328f>] __do_IRQ+0= x87/0xf8
=A0[<c0106782>] do_IRQ+0x1a/0x25
=A0[

- Valtteri


2012/10/3 Ian Campbell <Ian.Campbell@citrix.com>
On Wed, 2012-10-03 at 11:09 +0100, Valt= teri Kiviniemi wrote:
> root@xen-2:/var/log/xen# cat xl-lightning.log
> Waiting for domain lightning (domid 132) to die [pid 24083]
> Domain 132 has shut down, reason code 3 0x3

Reason code 3 is SHUTDOWN_crash.

Please can you try to enable guest console logging as described at
http://wiki.xen.org/wiki/Reporting_Bugs_against_X= en#Guest_console_logs
and see if the kernel prints anything at all.

I'm not sure if such an old kernel has this option but you could also add "earlyprintk=3Dxen" to the guest command line.

Do you get any output in the hypervisor dmesg?

Ian.



--20cf303dd264a78b0704cb254a1d-- --===============4677007332287331407== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============4677007332287331407==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 10:42:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 10:42:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJMPD-00076c-NN; Wed, 03 Oct 2012 10:42:19 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJMPB-00076S-VG for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 10:42:18 +0000 Received: from [85.158.139.211:25067] by server-12.bemta-5.messagelabs.com id 71/98-20729-9861C605; Wed, 03 Oct 2012 10:42:17 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-13.tower-206.messagelabs.com!1349260933!16918630!1 X-Originating-IP: [209.85.160.173] X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG, HTML_20_30, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5164 invoked from network); 3 Oct 2012 10:42:15 -0000 Received: from mail-gh0-f173.google.com (HELO mail-gh0-f173.google.com) (209.85.160.173) by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 10:42:15 -0000 Received: by ghy16 with SMTP id 16so2181676ghy.32 for ; Wed, 03 Oct 2012 03:42:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8ARgKGphMuwS1cmxczVtTJiXjFG4Y/gq484PV07Foe4=; b=c5ifH6S4H3h1ac8gUtqxLZdHILPYa6MLkSNmS+7JpyHHjF+5mzpRGCDegwc2r8WCYW 0jdstreKA+COW42ql4wE0JqVDDJVBEFuQutCpFZAneAbInjkmanSIQicB4WfgrgofId5 PMIAWjiMXdAKeyOD3VJrrnhiodijaK6qBUnjAYN7OyuCi6daJZVQfMdXUZ3fxy3vvW+o tmdUmv9UCRvB82Eu6hosHjBs8xKZ+7+e99VVaTegNkuvPAJ4P8nor7qYorfnR43ovX15 XdZYJpCiabuTS77jlNjApZvVM+9viiVrqY4jWnzbazAzdZw4eSl8t95MGJ+ulcJ4cEbW UxWQ== MIME-Version: 1.0 Received: by 10.236.9.36 with SMTP id 24mr1382063yhs.63.1349260933565; Wed, 03 Oct 2012 03:42:13 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Wed, 3 Oct 2012 03:42:13 -0700 (PDT) In-Reply-To: References: <1349259542.650.122.camel@zakaz.uk.xensource.com> Date: Wed, 3 Oct 2012 13:42:13 +0300 Message-ID: From: Valtteri Kiviniemi To: Ian Campbell Cc: "Xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Xen 4.2.0, xl toolstack cant launch older domUs X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4677007332287331407==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============4677007332287331407== Content-Type: multipart/alternative; boundary=20cf303dd264a78b0704cb254a1d --20cf303dd264a78b0704cb254a1d Content-Type: text/plain; charset=ISO-8859-1 Hi, I tried to lower vcpus to 1, and now it produces a different crash: Unable to handle kernel NULL pointer dereference at virtual address 00000024 printing eip: c0232139 005c4000 -> *pde = 00000000:00000000 Oops: 0000 [#1] SMP CPU: 0 EIP: 0061:[] Not tainted VLI EFLAGS: 00010097 (2.6.16.33-xen-domU-oldgame #1) EIP is at blkif_int+0x1dc/0x228 eax: 00000000 ebx: 00000001 ecx: c090e000 edx: 00000000 esi: d92d7c7c edi: ca010100 ebp: ed6ea0ac esp: c0367ec0 ds: 007b es: 007b ss: e021 Process swapper (pid: 0, threadinfo=c0366000 task=c030d7c0) Stack: <0>c200ce24 419c18e3 00000000 00000000 00000001 00000002 00000000 00000001 ed6ab7a0 00000000 00000000 c0367f6c c0133197 00000105 c090e000 c0367f6c 00000105 00008280 c035b680 00000105 ed6ab7a0 c013328f 00000105 0000000a Call Trace: [] handle_IRQ_event+0x38/0xa9 [] __do_IRQ+0x87/0xf8 [] do_IRQ+0x1a/0x25 [] evtchn_do_upcall+0x95/0xa9 [] hypervisor_callback+0x3d/0x48 [] safe_halt+0x7a/0xb2 [] xen_idle+0x2b/0x4e [] cpu_idle+0x52/0x67 [] start_kernel+0x2b8/0x33c [] unknown_bootoption+0x0/0x27a Code: c7 04 24 e0 17 30 c0 e8 39 8b ee ff 8b 44 24 38 c7 80 00 14 00 00 00 00 00 00 89 04 24 e8 75 03 00 00 bb a1 ff ff ff 8b 54 24 0c <8b> 42 24 89 44 24 08 89 5c 24 04 89 14 24 e8 3b eb fb ff 85 c0 <0>Kernel panic - not syncing: Fatal exception in interrupt 2012/10/3 Valtteri Kiviniemi > Hi, > > I enabled debugging and console logging. This is where it crashes: > > Parsing config from /etc/xen/lightning.cfg > Daemon running with PID 4952 > Linux version 2.6.16.33-xen-domU-oldgame (root@lightning) (gcc version > 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Fri Sep 28 14:56:14 > EEST 2012 > BIOS-provided physical RAM map: > Xen: 0000000000000000 - 0000000080000000 (usable) > 1320MB HIGHMEM available. > 727MB LOWMEM available. > NX (Execute Disable) protection: active > early console enabled > Built 1 zonelists > Kernel command line: root=/dev/xvda1 ro console=xvc0 earlyprintk=xen > Enabling fast FPU save and restore... done. > Enabling unmasked SIMD FPU exception support... done. > Initializing CPU#0 > PID hash table entries: 4096 (order: 12, 65536 bytes) > Xen reported: 3392.374 MHz processor. > disabling early console > Console: colour dummy device 80x25 > Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) > Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) > Software IO TLB disabled > vmalloc area: ee000000-f51fe000, maxmem 2d7fe000 > Memory: 2072132k/2097152k available (1917k kernel code, 23952k reserved, > 537k data, 148k init, 1351688k highmem) > Checking if this processor honours the WP bit even in supervisor mode... > Ok. > Calibrating delay using timer specific routine.. 6819.95 BogoMIPS > (lpj=3409975) > Mount-cache hash table entries: 512 > CPU: L1 I cache: 32K, L1 D cache: 32K > CPU: L2 cache: 256K > CPU: L3 cache: 8192K > Checking 'hlt' instruction... OK. > Initializing CPU#1 > Initializing CPU#2 > Initializing CPU#3 > Initializing CPU#4 > Initializing CPU#5 > Initializing CPU#6 > Brought up 8 CPUs > Initializing CPU#7 > migration_cost=3 > Grant table initialized > NET: Registered protocol family 16 > xen_mem: Initialising balloon driver. > SCSI subsystem initialized > highmem bounce pool size: 64 pages > Installing knfsd (copyright (C) 1996 okir@monad.swb.de). > Initializing Cryptographic API > io scheduler noop registered > io scheduler cfq registered (default) > rtc: IRQ 8 is not free. > i8042.c: No controller found. > loop: loaded (max 8 devices) > Xen virtual console successfully installed as tty1 > Event-channel device installed. > netfront: Initialising virtual ethernet driver. > mice: PS/2 mouse device common for all mice > Netfilter messages via NETLINK v0.30. > NET: Registered protocol family 2 > Registering block device major 202 > blkfront: xvda1: barriers enabled > netfront: device eth0 has copying receive path. > IP route cache hash table entries: 32768 (order: 5, 131072 bytes) > TCP established hash table entries: 131072 (order: 8, 1048576 bytes) > TCP bind hash table entries: 65536 (order: 7, 524288 bytes) > TCP: Hash tables configured (established 131072 bind 65536) > TCP reno registered > ip_conntrack version 2.4 (8192 buckets, 65536 max) - 232 bytes per > conntrack > ip_conntrack_pptp version 3.1 loaded > ip_nat_pptp version 3.0 loaded > ip_tables: (C) 2000-2006 Netfilter Core Team > ipt_recent v0.3.1: Stephen Frost . > http://snowman.net/projects/ipt_recent/ > TCP bic registered > NET: Registered protocol family 1 > NET: Registered protocol family 17 > NET: Registered protocol family 15 > Bridge firewalling registered > 802.1Q VLAN Support v1.8 Ben Greear > All bugs added by David S. Miller > Using IPI Shortcut mode > end_request: I/O error, dev xvda1, sector 2 > EXT3-fs: unable to read superblock > Unable to handle kernel paging request at virtual address 05de1ce8 > printing eip: > c0231fdc > 005c4000 -> *pde = 00000000:00000000 > Oops: 0000 [#1] > SMP > CPU: 0 > EIP: 0061:[] Not tainted VLI > EFLAGS: 00010007 (2.6.16.33-xen-domU-oldgame #1) > EIP is at blkif_int+0x7f/0x228 > eax: 189c9c00 ebx: c04df900 ecx: ed418000 edx: 05de1c00 > esi: 00000000 edi: ca010100 ebp: c043d0ac esp: c0367ec0 > ds: 007b es: 007b ss: e021 > Process swapper (pid: 0, threadinfo=c0366000 task=c030d7c0) > Stack: <0>c200ce24 20539c5e 00000000 00000001 00000001 00000002 00000000 > 00000001 > c04df900 00000000 00000000 c0367f6c c0133197 0000011a ed418000 > c0367f6c > 0000011a 00008d00 c035c100 0000011a c04df900 c013328f 0000011a > 0000000a > Call Trace: > [] handle_IRQ_event+0x38/0xa9 > [] __do_IRQ+0x87/0xf8 > [] do_IRQ+0x1a/0x25 > [] evtchn_do_upcall+0x95/0xa9 > [] hypervisor_callback+0x3d/0x48 > [] safe_halt+0x7a/0xb2 > [] xen_idle+0x2b/0x4e > [] cpu_idle+0x52/0x67 > [] start_kernel+0x2b8/0x33c > [] unknown_bootoption+0x0/0x27a > Code: 83 ea 01 23 54 24 1c 8d 04 12 01 d0 8d 04 c0 8d 2c 85 40 00 00 00 03 > 69 28 8b 7d 00 8d 14 bf 89 d0 c1 e0 05 29 d0 01 f8 8d 14 08 <8b> 92 e8 00 > 00 00 89 54 24 0c 8d 74 08 7c 80 7e 01 00 74 29 31 > <0>Kernel panic - not syncing: Fatal exception in interrupt > Badness in smp_call_function at arch/i386/kernel/smp-xen.c:520 > [] smp_call_function+0x146/0x14b > [] printk+0x1b/0x1f > [] do_unblank_screen+0xe/0x129 > [] smp_send_stop+0x27/0x60 > [] stop_this_cpu+0x0/0x3f > [] panic+0x5e/0x155 > [] die+0x231/0x23b > [] do_page_fault+0x396/0xd30 > [] getnstimeofday+0x14/0x37 > [] do_page_fault+0x0/0xd30 > [] error_code+0x2b/0x30 > [] blkif_int+0x7f/0x228 > [] handle_IRQ_event+0x38/0xa9 > [] __do_IRQ+0x87/0xf8 > [] do_IRQ+0x1a/0x25 > [ > > - Valtteri > > > 2012/10/3 Ian Campbell > >> On Wed, 2012-10-03 at 11:09 +0100, Valtteri Kiviniemi wrote: >> > root@xen-2:/var/log/xen# cat xl-lightning.log >> > Waiting for domain lightning (domid 132) to die [pid 24083] >> > Domain 132 has shut down, reason code 3 0x3 >> >> Reason code 3 is SHUTDOWN_crash. >> >> Please can you try to enable guest console logging as described at >> http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen#Guest_console_logs >> and see if the kernel prints anything at all. >> >> I'm not sure if such an old kernel has this option but you could also >> add "earlyprintk=xen" to the guest command line. >> >> Do you get any output in the hypervisor dmesg? >> >> Ian. >> >> > --20cf303dd264a78b0704cb254a1d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I tried to lower vcpus to 1, and now it produces a different cra= sh:

Unable to handle kernel NULL pointer dereference at virtual addr= ess 00000024
=A0printing eip:
c0232139
005c4000 -> *pde =3D 000= 00000:00000000
Oops: 0000 [#1]
SMP
CPU:=A0=A0=A0 0
EIP:=A0=A0=A0 0061:[<c02321= 39>]=A0=A0=A0 Not tainted VLI
EFLAGS: 00010097=A0=A0 (2.6.16.33-xen-d= omU-oldgame #1)
EIP is at blkif_int+0x1dc/0x228
eax: 00000000=A0=A0 e= bx: 00000001=A0=A0 ecx: c090e000=A0=A0 edx: 00000000
esi: d92d7c7c=A0=A0 edi: ca010100=A0=A0 ebp: ed6ea0ac=A0=A0 esp: c0367ec0ds: 007b=A0=A0 es: 007b=A0=A0 ss: e021
Process swapper (pid: 0, thread= info=3Dc0366000 task=3Dc030d7c0)
Stack: <0>c200ce24 419c18e3 00000= 000 00000000 00000001 00000002 00000000 00000001
=A0=A0=A0=A0=A0=A0 ed6ab7a0 00000000 00000000 c0367f6c c0133197 00000105 c0= 90e000 c0367f6c
=A0=A0=A0=A0=A0=A0 00000105 00008280 c035b680 00000105 e= d6ab7a0 c013328f 00000105 0000000a
Call Trace:
=A0[<c0133197>] = handle_IRQ_event+0x38/0xa9
=A0[<c013328f>] __do_IRQ+0x87/0xf8
=A0[<c0106782>] do_IRQ+0x= 1a/0x25
=A0[<c0228d85>] evtchn_do_upcall+0x95/0xa9
=A0[<c010= 504d>] hypervisor_callback+0x3d/0x48
=A0[<c0107ecf>] safe_halt+= 0x7a/0xb2
=A0[<c0102efd>] xen_idle+0x2b/0x4e
=A0[<c0103014>] cpu_idle+= 0x52/0x67
=A0[<c036871c>] start_kernel+0x2b8/0x33c
=A0[<c036= 81ea>] unknown_bootoption+0x0/0x27a
Code: c7 04 24 e0 17 30 c0 e8 39 = 8b ee ff 8b 44 24 38 c7 80 00 14 00 00 00 00 00 00 89 04 24 e8 75 03 00 00 = bb a1 ff ff ff 8b 54 24 0c <8b> 42 24 89 44 24 08 89 5c 24 04 89 14 2= 4 e8 3b eb fb ff 85 c0
=A0<0>Kernel panic - not syncing: Fatal exception in interrupt

2012/10/3 Valtteri Kiviniemi <k= iviniemi.valtteri@gmail.com>
Hi,

I enabled debugging and console l= ogging. This is where it crashes:

Parsing config from /etc/xen/light= ning.cfg
Daemon running with PID 4952
Linux version 2.6.16.33-xen-domU-oldgame (r= oot@lightning) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) = #1 SMP Fri Sep 28 14:56:14 EEST 2012
BIOS-provided physical RAM map:
=A0Xen: 0000000000000000 - 0000000080000= 000 (usable)
1320MB HIGHMEM available.
727MB LOWMEM available.
NX = (Execute Disable) protection: active
early console enabled
Built 1 zo= nelists
Kernel command line: root=3D/dev/xvda1 ro console=3Dxvc0 earlyprintk=3Dxen<= br>Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FP= U exception support... done.
Initializing CPU#0
PID hash table entrie= s: 4096 (order: 12, 65536 bytes)
Xen reported: 3392.374 MHz processor.
disabling early console
Console= : colour dummy device 80x25
Dentry cache hash table entries: 131072 (ord= er: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 26= 2144 bytes)
Software IO TLB disabled
vmalloc area: ee000000-f51fe000, maxmem 2d7fe00= 0
Memory: 2072132k/2097152k available (1917k kernel code, 23952k reserve= d, 537k data, 148k init, 1351688k highmem)
Checking if this processor ho= nours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 6819.95 BogoMIPS (lpj=3D34= 09975)
Mount-cache hash table entries: 512
CPU: L1 I cache: 32K, L1 D= cache: 32K
CPU: L2 cache: 256K
CPU: L3 cache: 8192K
Checking '= ;hlt' instruction... OK.
Initializing CPU#1
Initializing CPU#2
Initializing CPU#3
Initializ= ing CPU#4
Initializing CPU#5
Initializing CPU#6
Brought up 8 CPUs<= br>Initializing CPU#7
migration_cost=3D3
Grant table initialized
NET: Registered protocol family 16
xen_mem: Initialising balloon driver.=
SCSI subsystem initialized
highmem bounce pool size: 64 pages
Ins= talling knfsd (copyright (C) 1996 okir@monad.swb.de).
Initializing Cryptographic API
io scheduler noop registered
io schedu= ler cfq registered (default)
rtc: IRQ 8 is not free.
i8042.c: No cont= roller found.
loop: loaded (max 8 devices)
Xen virtual console succes= sfully installed as tty1
Event-channel device installed.
netfront: Initialising virtual ethernet = driver.
mice: PS/2 mouse device common for all mice
Netfilter message= s via NETLINK v0.30.
NET: Registered protocol family 2
Registering bl= ock device major 202
blkfront: xvda1: barriers enabled
netfront: device eth0 has copying rece= ive path.
IP route cache hash table entries: 32768 (order: 5, 131072 byt= es)
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)=
TCP bind hash table entries: 65536 (order: 7, 524288 bytes)
TCP: Hash ta= bles configured (established 131072 bind 65536)
TCP reno registered
i= p_conntrack version 2.4 (8192 buckets, 65536 max) - 232 bytes per conntrack=
ip_conntrack_pptp version 3.1 loaded
ip_nat_pptp version 3.0 loaded
i= p_tables: (C) 2000-2006 Netfilter Core Team
ipt_recent v0.3.1: Stephen F= rost <sfrost@sno= wman.net>.=A0 http://snowman.net/projects/ipt_recent/
TCP bic registered
NET: Registered protocol family 1
NET: Registered = protocol family 17
NET: Registered protocol family 15
Bridge firewall= ing registered
802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>=
All bugs added by David S. Miller <davem@redhat.com>
Using IPI Shortcut mode
end= _request: I/O error, dev xvda1, sector 2
EXT3-fs: unable to read superbl= ock
Unable to handle kernel paging request at virtual address 05de1ce8
=A0printing eip:
c0231fdc
005c4000 -> *pde =3D 00000000:00000000Oops: 0000 [#1]
SMP
CPU:=A0=A0=A0 0
EIP:=A0=A0=A0 0061:[<c023= 1fdc>]=A0=A0=A0 Not tainted VLI
EFLAGS: 00010007=A0=A0 (2.6.16.33-xen= -domU-oldgame #1)
EIP is at blkif_int+0x7f/0x228
eax: 189c9c00=A0=A0 ebx: c04df900=A0=A0 ecx: ed418000=A0=A0 edx: 05de1c00esi: 00000000=A0=A0 edi: ca010100=A0=A0 ebp: c043d0ac=A0=A0 esp: c0367ec0=
ds: 007b=A0=A0 es: 007b=A0=A0 ss: e021
Process swapper (pid: 0, thre= adinfo=3Dc0366000 task=3Dc030d7c0)
Stack: <0>c200ce24 20539c5e 00000000 00000001 00000001 00000002 00000= 000 00000001
=A0=A0=A0=A0=A0=A0 c04df900 00000000 00000000 c0367f6c c013= 3197 0000011a ed418000 c0367f6c
=A0=A0=A0=A0=A0=A0 0000011a 00008d00 c03= 5c100 0000011a c04df900 c013328f 0000011a 0000000a
Call Trace:
=A0[<c0133197>] handle_IRQ_event+0x38/0xa9
=A0[<= c013328f>] __do_IRQ+0x87/0xf8
=A0[<c0106782>] do_IRQ+0x1a/0x25<= br>=A0[<c0228d85>] evtchn_do_upcall+0x95/0xa9
=A0[<c010504d>= ] hypervisor_callback+0x3d/0x48
=A0[<c0107ecf>] safe_halt+0x7a/0xb2
=A0[<c0102efd>] xen_idle= +0x2b/0x4e
=A0[<c0103014>] cpu_idle+0x52/0x67
=A0[<c036871c&= gt;] start_kernel+0x2b8/0x33c
=A0[<c03681ea>] unknown_bootoption+0= x0/0x27a
Code: 83 ea 01 23 54 24 1c 8d 04 12 01 d0 8d 04 c0 8d 2c 85 40 00 00 00 03 = 69 28 8b 7d 00 8d 14 bf 89 d0 c1 e0 05 29 d0 01 f8 8d 14 08 <8b> 92 e= 8 00 00 00 89 54 24 0c 8d 74 08 7c 80 7e 01 00 74 29 31
=A0<0>Kern= el panic - not syncing: Fatal exception in interrupt
=A0Badness in smp_call_function at arch/i386/kernel/smp-xen.c:520
=A0[&l= t;c010c8fe>] smp_call_function+0x146/0x14b
=A0[<c011ac6e>] prin= tk+0x1b/0x1f
=A0[<c021a120>] do_unblank_screen+0xe/0x129
=A0[&l= t;c010c9a9>] smp_send_stop+0x27/0x60
=A0[<c010c943>] stop_this_cpu+0x0/0x3f
=A0[<c011a149>] panic= +0x5e/0x155
=A0[<c0105948>] die+0x231/0x23b
=A0[<c0110348>= ;] do_page_fault+0x396/0xd30
=A0[<c011eb6b>] getnstimeofday+0x14/0= x37
=A0[<c010ffb2>] do_page_fault+0x0/0xd30
=A0[<c010500b>] erro= r_code+0x2b/0x30
=A0[<c0231fdc>] blkif_int+0x7f/0x228
=A0[<c= 0133197>] handle_IRQ_event+0x38/0xa9
=A0[<c013328f>] __do_IRQ+0= x87/0xf8
=A0[<c0106782>] do_IRQ+0x1a/0x25
=A0[

- Valtteri


2012/10/3 Ian Campbell <Ian.Campbell@citrix.com>
On Wed, 2012-10-03 at 11:09 +0100, Valt= teri Kiviniemi wrote:
> root@xen-2:/var/log/xen# cat xl-lightning.log
> Waiting for domain lightning (domid 132) to die [pid 24083]
> Domain 132 has shut down, reason code 3 0x3

Reason code 3 is SHUTDOWN_crash.

Please can you try to enable guest console logging as described at
http://wiki.xen.org/wiki/Reporting_Bugs_against_X= en#Guest_console_logs
and see if the kernel prints anything at all.

I'm not sure if such an old kernel has this option but you could also add "earlyprintk=3Dxen" to the guest command line.

Do you get any output in the hypervisor dmesg?

Ian.



--20cf303dd264a78b0704cb254a1d-- --===============4677007332287331407== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============4677007332287331407==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 10:50:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 10:50:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJMWm-0007Jl-Rc; Wed, 03 Oct 2012 10:50:08 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJMWl-0007Jg-AW for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 10:50:07 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1349261400!8584747!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16872 invoked from network); 3 Oct 2012 10:50:01 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 10:50:01 -0000 X-IronPort-AV: E=Sophos;i="4.80,527,1344211200"; d="scan'208";a="14912136" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 10:49:59 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 11:49:59 +0100 Message-ID: <1349261397.650.130.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Valtteri Kiviniemi Date: Wed, 3 Oct 2012 11:49:57 +0100 In-Reply-To: References: <1349259542.650.122.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Xen 4.2.0, xl toolstack cant launch older domUs X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-10-03 at 11:42 +0100, Valtteri Kiviniemi wrote: > Hi, > > I tried to lower vcpus to 1, and now it produces a different crash: > > Unable to handle kernel NULL pointer dereference at virtual address > 00000024 > printing eip: > c0232139 > 005c4000 -> *pde = 00000000:00000000 > Oops: 0000 [#1] > SMP > CPU: 0 > EIP: 0061:[] Not tainted VLI > EFLAGS: 00010097 (2.6.16.33-xen-domU-oldgame #1) > EIP is at blkif_int+0x1dc/0x228 I don't suppose you have source / debug info for this kernel to resolve this into a location? You say this exact same config works with xend? If so then, since this appears to relate to the devices, one thing which might be worth trying is to set on_crash = "preserve" in your config and run under both xend and xl. You can then collect the content of xenstore (xenstore-ls -fp) in both cases (xend booted ok, xl preserved in the crashed state), and compare. There will be a bunch of differences relating to the xend one finishing its boot but something might stand out in the diff. Just posting both sets of output might be useful. If you run "xl -vvv create" you should also get a bunch of stuff relating to the domain builder and where it is placing things. Running under xend I think something similar is dumped under /var/log/xen (domain-build-ng.log?) What does your config file look like? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 10:50:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 10:50:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJMWm-0007Jl-Rc; Wed, 03 Oct 2012 10:50:08 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJMWl-0007Jg-AW for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 10:50:07 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1349261400!8584747!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16872 invoked from network); 3 Oct 2012 10:50:01 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 10:50:01 -0000 X-IronPort-AV: E=Sophos;i="4.80,527,1344211200"; d="scan'208";a="14912136" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 10:49:59 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 11:49:59 +0100 Message-ID: <1349261397.650.130.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Valtteri Kiviniemi Date: Wed, 3 Oct 2012 11:49:57 +0100 In-Reply-To: References: <1349259542.650.122.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Xen 4.2.0, xl toolstack cant launch older domUs X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-10-03 at 11:42 +0100, Valtteri Kiviniemi wrote: > Hi, > > I tried to lower vcpus to 1, and now it produces a different crash: > > Unable to handle kernel NULL pointer dereference at virtual address > 00000024 > printing eip: > c0232139 > 005c4000 -> *pde = 00000000:00000000 > Oops: 0000 [#1] > SMP > CPU: 0 > EIP: 0061:[] Not tainted VLI > EFLAGS: 00010097 (2.6.16.33-xen-domU-oldgame #1) > EIP is at blkif_int+0x1dc/0x228 I don't suppose you have source / debug info for this kernel to resolve this into a location? You say this exact same config works with xend? If so then, since this appears to relate to the devices, one thing which might be worth trying is to set on_crash = "preserve" in your config and run under both xend and xl. You can then collect the content of xenstore (xenstore-ls -fp) in both cases (xend booted ok, xl preserved in the crashed state), and compare. There will be a bunch of differences relating to the xend one finishing its boot but something might stand out in the diff. Just posting both sets of output might be useful. If you run "xl -vvv create" you should also get a bunch of stuff relating to the domain builder and where it is placing things. Running under xend I think something similar is dumped under /var/log/xen (domain-build-ng.log?) What does your config file look like? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 11:08:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 11:08:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJMnw-0007aX-EW; Wed, 03 Oct 2012 11:07:52 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJMnt-0007aS-Id for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 11:07:50 +0000 Received: from [85.158.138.51:7707] by server-9.bemta-3.messagelabs.com id FF/4A-20338-48C1C605; Wed, 03 Oct 2012 11:07:48 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1349262462!32427600!1 X-Originating-IP: [209.85.161.173] X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG, HTML_10_20, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23471 invoked from network); 3 Oct 2012 11:07:43 -0000 Received: from mail-gg0-f173.google.com (HELO mail-gg0-f173.google.com) (209.85.161.173) by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 11:07:43 -0000 Received: by ggcs5 with SMTP id s5so602080ggc.32 for ; Wed, 03 Oct 2012 04:07:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+dsJkve1dfTDhJhCPHQxEg9dI4wRQ+0U1Uf2Qdc7NEk=; b=TS2VhoXzQLk83UTZyYx8Rb6HVnpWodB1i4yq+Etxu+hnUe0WtlVUMV5r/UkFj9YUwO xOXZEsgBl+f7W09dSolYrFR2jwHRkLJDcPKpAmDjFi0gY5f5zewEXNFNWAM0FmIAVBDn tuv7CXqhKJ03tQTHochy4kJEatE1QghceAoouBgzsXMH0zWr19KBmrIDw4toei18Yelm XbaE1F/XqvZ4LHv5H61YIQ1tUfW9u6JhoPydKiM7h9ld+raR/3T0ikQkOX2cnCXxe0WJ 7gqacO09Vay9GB/GTTCp2Ti8FWET1IbshIb87cXAHYcA0jrC3s02BoC58PhRCpJTE5st aUtg== MIME-Version: 1.0 Received: by 10.101.166.35 with SMTP id t35mr419900ano.63.1349262462176; Wed, 03 Oct 2012 04:07:42 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Wed, 3 Oct 2012 04:07:42 -0700 (PDT) In-Reply-To: <1349261397.650.130.camel@zakaz.uk.xensource.com> References: <1349259542.650.122.camel@zakaz.uk.xensource.com> <1349261397.650.130.camel@zakaz.uk.xensource.com> Date: Wed, 3 Oct 2012 14:07:42 +0300 Message-ID: From: Valtteri Kiviniemi To: Ian Campbell Cc: "Xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Xen 4.2.0, xl toolstack cant launch older domUs X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8545444535638952119==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============8545444535638952119== Content-Type: multipart/alternative; boundary=001636ef09adc44f7f04cb25a56c --001636ef09adc44f7f04cb25a56c Content-Type: text/plain; charset=ISO-8859-1 Hi, I dont have the kernel sources for that 2.6.16.33 any more, this is a very old domU but it still in use since we run some applications there which require old glibc and wont run on newer machines. The domU works perfectly with xend, and has always worked (since xen 3.0.0 every xen upgrade). But now when I decided to move from xend to xl the problems started. Here are the info that you asked, its going to be a long post and hopefully I remembered everything that you asked for: config: kernel = "/boot/vmlinuz-2.6.16.33-xen-domU-oldgame" builder = "linux" memory = "2048" name = "lightning" vcpus = "8" cpus = [ "0", "1", "2", "3", "4", "5", "6", "7" ] vif = [ "mac=00:16:3e:1d:0d:91, bridge=xenbr0" ] disk = [ "phy:/dev/virtuals/lightning,xvda1,w" ] root = "/dev/xvda1 ro" extra = "xencons=tty1 earlyprintk=xen" on_poweroff = "destroy" on_reboot = "restart" on_crash = "preserve" xenstore-ls -fp when started with xend and working: /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2 = "" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/image = "(linux (kernel /boot/bzImage-domU-oldgame) (args 'root=/dev/xvda1 ro console=xvc0 earlyprintk=xen') (superpages 0) (videoram 4) (pci ()) (nomigrate 0) (tsc_mode 0) (notes (HV_START_LOW 411880652\..." (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/image/ostype = "linux" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/image/kernel = "/boot/bzImage-domU-oldgame" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/image/cmdline = "root=/dev/xvda1 ro console=xvc0 earlyprintk=xen" (n0,r11) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/image/ramdisk = "" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device = "" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/vbd = "" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/vbd/51713 = "" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/vbd/51713/frontend = "/local/domain/11/device/vbd/51713" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/vbd/51713/frontend-id = "11" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/vbd/51713/backend-id = "0" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/vbd/51713/backend = "/local/domain/0/backend/vbd/11/51713" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/vif = "" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/vif/0 = "" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/vif/0/frontend = "/local/domain/11/device/vif/0" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/vif/0/frontend-id = "11" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/vif/0/backend-id = "0" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/vif/0/backend = "/local/domain/0/backend/vif/11/0" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/console = "" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/console/0 = "" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/console/0/frontend = "/local/domain/11/device/console/0" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/console/0/frontend-id = "11" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/console/0/backend-id = "0" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/console/0/backend = "/local/domain/0/backend/console/11/0" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/on_xend_stop = "ignore" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/pool_name = "Pool-0" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/shadow_memory = "0" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/uuid = "54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2" (n0,r11) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/on_reboot = "restart" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/start_time = "1349262041.78" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/on_poweroff = "destroy" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/bootloader_args = "" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/on_xend_start = "ignore" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/on_crash = "preserve" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/xend = "" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/xend/restart_count = "0" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/vcpus = "1" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/vcpu_avail = "1" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/bootloader = "" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/name = "lightning" (n0) xenstore-ls -fp when started with xl and crashed (preserved): /vm = "" (n0) /vm/e2261517-a75b-4c02-b9db-da9c21a05130 = "" (n0,r1) /vm/e2261517-a75b-4c02-b9db-da9c21a05130/uuid = "e2261517-a75b-4c02-b9db-da9c21a05130" (n0,r1) /vm/e2261517-a75b-4c02-b9db-da9c21a05130/name = "lightning" (n0,r1) /vm/e2261517-a75b-4c02-b9db-da9c21a05130/image = "" (n0,r1) /vm/e2261517-a75b-4c02-b9db-da9c21a05130/image/ostype = "linux" (n0,r1) /vm/e2261517-a75b-4c02-b9db-da9c21a05130/image/kernel = "/boot/bzImage-domU-oldgame" (n0,r1) /vm/e2261517-a75b-4c02-b9db-da9c21a05130/image/cmdline = "root=/dev/xvda1 ro console=xvc0 earlyprintk=xen" (n0,r1) /vm/e2261517-a75b-4c02-b9db-da9c21a05130/start_time = "1349262365.43" (n0,r1) /libxl = "" (n0) /libxl/1 = "" (n0) /libxl/1/dm-version = "qemu_xen" (n0) domU starter with xl -vvv create: root@xen-2:~# xl -vvv create /etc/xen/lightning.cfg -c Parsing config from /etc/xen/lightning.cfg libxl: debug: libxl_create.c:1173:do_domain_create: ao 0x6243d0: create: how=(nil) callback=(nil) poller=0x623b80 libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk vdev=xvda1 spec.backend=unknown libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk vdev=xvda1, using backend phy libxl: debug: libxl_create.c:677:initiate_domain_create: running bootloader libxl: debug: libxl_bootloader.c:327:libxl__bootloader_run: no bootloader configured, using user supplied kernel libxl: debug: libxl_event.c:561:libxl__ev_xswatch_deregister: watch w=0x624750: deregister unregistered libxl: debug: libxl_numa.c:435:libxl__get_numa_candidate: New best NUMA placement candidate found: nr_nodes=1, nr_cpus=8, nr_vcpus=9, free_memkb=31043 libxl: detail: libxl_dom.c:192:numa_place_domain: NUMA placement candidate with 1 nodes, 8 cpus and 31043 KB free selected domainbuilder: detail: xc_dom_allocate: cmdline="root=/dev/xvda1 ro console=xvc0 earlyprintk=xen", features="(null)" libxl: debug: libxl_dom.c:380:libxl__build_pv: pv kernel mapped 0 path /boot/bzImage-domU-oldgame domainbuilder: detail: xc_dom_kernel_file: filename="/boot/bzImage-domU-oldgame" domainbuilder: detail: xc_dom_malloc_filemap : 1237 kB domainbuilder: detail: xc_dom_malloc : 2653 kB domainbuilder: detail: xc_dom_do_gunzip: unzip ok, 0x135462 -> 0x297540 domainbuilder: detail: xc_dom_boot_xen_init: ver 4.2, caps xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 domainbuilder: detail: xc_dom_parse_image: called domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary loader ... domainbuilder: detail: loader probe failed domainbuilder: detail: xc_dom_find_loader: trying Linux bzImage loader ... domainbuilder: detail: xc_dom_probe_bzimage_kernel: kernel is not a bzImage domainbuilder: detail: loader probe failed domainbuilder: detail: xc_dom_find_loader: trying ELF-generic loader ... domainbuilder: detail: loader probe OK xc: detail: elf_parse_binary: phdr: paddr=0xc0100000 memsz=0x20d500 xc: detail: elf_parse_binary: phdr: paddr=0xc030d500 memsz=0xb3308 xc: detail: elf_parse_binary: memory: 0xc0100000 -> 0xc03c0808 xc: detail: elf_xen_parse_note: GUEST_OS = "linux" xc: detail: elf_xen_parse_note: GUEST_VERSION = "2.6" xc: detail: elf_xen_parse_note: XEN_VERSION = "xen-3.0" xc: detail: elf_xen_parse_note: VIRT_BASE = 0xc0000000 xc: detail: elf_xen_parse_note: PADDR_OFFSET = 0xc0000000 xc: detail: elf_xen_parse_note: ENTRY = 0xc0100000 xc: detail: elf_xen_parse_note: HYPERCALL_PAGE = 0xc0101000 xc: detail: elf_xen_parse_note: HV_START_LOW = 0xf5800000 xc: detail: elf_xen_parse_note: FEATURES = "writable_page_tables|writable_descriptor_tables|auto_translated_physmap|pae_pgdir_above_4gb|supervisor_mode_kernel" xc: detail: elf_xen_parse_note: PAE_MODE = "yes" xc: detail: elf_xen_parse_note: LOADER = "generic" xc: detail: elf_xen_parse: using notes from SHT_NOTE section xc: detail: elf_xen_addr_calc_check: addresses: xc: detail: virt_base = 0xc0000000 xc: detail: elf_paddr_offset = 0xc0000000 xc: detail: virt_offset = 0x0 xc: detail: virt_kstart = 0xc0100000 xc: detail: virt_kend = 0xc03c0808 xc: detail: virt_entry = 0xc0100000 xc: detail: p2m_base = 0xffffffffffffffff domainbuilder: detail: xc_dom_parse_elf_kernel: xen-3.0-x86_32p: 0xc0100000 -> 0xc03c0808 domainbuilder: detail: xc_dom_mem_init: mem 2048 MB, pages 0x80000 pages, 4k each domainbuilder: detail: xc_dom_mem_init: 0x80000 pages domainbuilder: detail: xc_dom_boot_mem_init: called domainbuilder: detail: x86_compat: guest xen-3.0-x86_32p, address size 32 domainbuilder: detail: xc_dom_malloc : 4096 kB domainbuilder: detail: xc_dom_build_image: called domainbuilder: detail: xc_dom_alloc_segment: kernel : 0xc0100000 -> 0xc03c1000 (pfn 0x100 + 0x2c1 pages) domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x100+0x2c1 at 0x7fcba1b83000 xc: detail: elf_load_binary: phdr 0 at 0x0x7fcba1b83000 -> 0x0x7fcba1d90500 xc: detail: elf_load_binary: phdr 1 at 0x0x7fcba1d90500 -> 0x0x7fcba1e0f93c domainbuilder: detail: xc_dom_alloc_segment: phys2mach : 0xc03c1000 -> 0xc05c1000 (pfn 0x3c1 + 0x200 pages) domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x3c1+0x200 at 0x7fcba1983000 domainbuilder: detail: xc_dom_alloc_page : start info : 0xc05c1000 (pfn 0x5c1) domainbuilder: detail: xc_dom_alloc_page : xenstore : 0xc05c2000 (pfn 0x5c2) domainbuilder: detail: xc_dom_alloc_page : console : 0xc05c3000 (pfn 0x5c3) domainbuilder: detail: nr_page_tables: 0x00000000ffffffff/32: 0x0000000000000000 -> 0x00000000ffffffff, 1 table(s) domainbuilder: detail: nr_page_tables: 0x000000003fffffff/30: 0x00000000c0000000 -> 0x00000000ffffffff, 1 table(s) domainbuilder: detail: nr_page_tables: 0x00000000001fffff/21: 0x00000000c0000000 -> 0x00000000c07fffff, 4 table(s) domainbuilder: detail: xc_dom_alloc_segment: page tables : 0xc05c4000 -> 0xc05ca000 (pfn 0x5c4 + 0x6 pages) domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x5c4+0x6 at 0x7fcba197d000 domainbuilder: detail: xc_dom_alloc_page : boot stack : 0xc05ca000 (pfn 0x5ca) domainbuilder: detail: xc_dom_build_image : virt_alloc_end : 0xc05cb000 domainbuilder: detail: xc_dom_build_image : virt_pgtab_end : 0xc0800000 domainbuilder: detail: xc_dom_boot_image: called domainbuilder: detail: arch_setup_bootearly: doing nothing domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-x86_64 domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-x86_32p <= matches domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_32 domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_32p domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_64 domainbuilder: detail: xc_dom_update_guest_p2m: dst 32bit, pages 0x80000 domainbuilder: detail: clear_page: pfn 0x5c3, mfn 0x649f86 domainbuilder: detail: clear_page: pfn 0x5c2, mfn 0x649f87 domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x5c1+0x1 at 0x7fcba4599000 domainbuilder: detail: start_info_x86_32: called domainbuilder: detail: setup_hypercall_page: vaddr=0xc0101000 pfn=0x101 domainbuilder: detail: domain builder memory footprint domainbuilder: detail: allocated domainbuilder: detail: malloc : 6780 kB domainbuilder: detail: anon mmap : 0 bytes domainbuilder: detail: mapped domainbuilder: detail: file mmap : 1237 kB domainbuilder: detail: domU mmap : 4896 kB domainbuilder: detail: arch_setup_bootlate: shared_info: pfn 0x0, mfn 0xdbdf8 domainbuilder: detail: shared_info_x86_32: called domainbuilder: detail: vcpu_x86_32: called domainbuilder: detail: vcpu_x86_32: cr3: pfn 0x5c4 mfn 0x649f85 domainbuilder: detail: launch_vm: called, ctxt=0x7fff96435b40 domainbuilder: detail: xc_dom_release: called libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk vdev=xvda1 spec.backend=phy libxl: debug: libxl_event.c:512:libxl__ev_xswatch_register: watch w=0x625598 wpath=/local/domain/0/backend/vbd/2/51713/state token=3/0: register slotnum=3 libxl: debug: libxl_create.c:1186:do_domain_create: ao 0x6243d0: inprogress: poller=0x623b80, flags=i libxl: debug: libxl_event.c:457:watchfd_callback: watch w=0x625598 wpath=/local/domain/0/backend/vbd/2/51713/state token=3/0: event epath=/local/domain/0/backend/vbd/2/51713/state libxl: debug: libxl_event.c:596:devstate_watch_callback: backend /local/domain/0/backend/vbd/2/51713/state wanted state 2 ok libxl: debug: libxl_event.c:549:libxl__ev_xswatch_deregister: watch w=0x625598 wpath=/local/domain/0/backend/vbd/2/51713/state token=3/0: deregister slotnum=3 libxl: debug: libxl_event.c:561:libxl__ev_xswatch_deregister: watch w=0x625598: deregister unregistered libxl: debug: libxl_device.c:916:device_hotplug: calling hotplug script: /etc/xen/scripts/block add libxl: debug: libxl_event.c:426:watchfd_callback: watch epath=/local/domain/0/backend/vbd/2/51713/state token=3/0: empty slot libxl: debug: libxl_event.c:512:libxl__ev_xswatch_register: watch w=0x626f38 wpath=/local/domain/0/backend/vif/2/0/state token=3/1: register slotnum=3 libxl: debug: libxl_event.c:457:watchfd_callback: watch w=0x626f38 wpath=/local/domain/0/backend/vif/2/0/state token=3/1: event epath=/local/domain/0/backend/vif/2/0/state libxl: debug: libxl_event.c:596:devstate_watch_callback: backend /local/domain/0/backend/vif/2/0/state wanted state 2 ok libxl: debug: libxl_event.c:549:libxl__ev_xswatch_deregister: watch w=0x626f38 wpath=/local/domain/0/backend/vif/2/0/state token=3/1: deregister slotnum=3 libxl: debug: libxl_event.c:561:libxl__ev_xswatch_deregister: watch w=0x626f38: deregister unregistered libxl: debug: libxl_device.c:916:device_hotplug: calling hotplug script: /etc/xen/scripts/vif-bridge online libxl: debug: libxl_event.c:1677:libxl__ao_progress_report: ao 0x6243d0: progress report: callback queued aop=0x627700 libxl: debug: libxl_event.c:1497:libxl__ao_complete: ao 0x6243d0: complete, rc=0 libxl: debug: libxl_event.c:1090:egc_run_callbacks: ao 0x6243d0: progress report: callback aop=0x627700 libxl: debug: libxl_event.c:1469:libxl__ao__destroy: ao 0x6243d0: destroy Daemon running with PID 4881 Linux version 2.6.16.33-xen-domU-oldgame (root@lightning) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Fri Sep 28 14:56:14 EEST 2012 BIOS-provided physical RAM map: Xen: 0000000000000000 - 0000000080000000 (usable) 1320MB HIGHMEM available. 727MB LOWMEM available. NX (Execute Disable) protection: active early console enabled Built 1 zonelists Kernel command line: root=/dev/xvda1 ro console=xvc0 earlyprintk=xen Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 PID hash table entries: 4096 (order: 12, 65536 bytes) Xen reported: 3392.372 MHz processor. disabling early console Console: colour dummy device 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Software IO TLB disabled vmalloc area: ee000000-f51fe000, maxmem 2d7fe000 Memory: 2072132k/2097152k available (1917k kernel code, 23952k reserved, 537k data, 148k init, 1351688k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 6820.46 BogoMIPS (lpj=3410231) Mount-cache hash table entries: 512 CPU: L1 I cache: 32K, L1 D cache: 32K CPU: L2 cache: 256K CPU: L3 cache: 8192K Checking 'hlt' instruction... OK. Brought up 1 CPUs migration_cost=0 Grant table initialized NET: Registered protocol family 16 xen_mem: Initialising balloon driver. SCSI subsystem initialized highmem bounce pool size: 64 pages Installing knfsd (copyright (C) 1996 okir@monad.swb.de). Initializing Cryptographic API io scheduler noop registered io scheduler cfq registered (default) rtc: IRQ 8 is not free. i8042.c: No controller found. loop: loaded (max 8 devices) Xen virtual console successfully installed as tty1 Event-channel device installed. netfront: Initialising virtual ethernet driver. mice: PS/2 mouse device common for all mice Netfilter messages via NETLINK v0.30. NET: Registered protocol family 2 netfront: device eth0 has copying receive path. Registering block device major 202 blkfront: xvda1: barriers enabled IP route cache hash table entries: 32768 (order: 5, 131072 bytes) TCP established hash table entries: 131072 (order: 8, 1048576 bytes) TCP bind hash table entries: 65536 (order: 7, 524288 bytes) TCP: Hash tables configured (established 131072 bind 65536) TCP reno registered ip_conntrack version 2.4 (8192 buckets, 65536 max) - 232 bytes per conntrack ip_conntrack_pptp version 3.1 loaded ip_nat_pptp version 3.0 loaded ip_tables: (C) 2000-2006 Netfilter Core Team ipt_recent v0.3.1: Stephen Frost . http://snowman.net/projects/ipt_recent/ TCP bic registered NET: Registered protocol family 1 NET: Registered protocol family 17 NET: Registered protocol family 15 Bridge firewalling registered 802.1Q VLAN Support v1.8 Ben Greear All bugs added by David S. Miller Using IPI Shortcut mode end_request: I/O error, dev xvda1, sector 2 EXT3-fs: unable to read superblock Unable to handle kernel NULL pointer dereference at virtual address 00000024 printing eip: c0232139 005c4000 -> *pde = 00000000:00000000 Oops: 0000 [#1] SMP CPU: 0 EIP: 0061:[] Not tainted VLI EFLAGS: 00010097 (2.6.16.33-xen-domU-oldgame #1) EIP is at blkif_int+0x1dc/0x228 eax: 00000000 ebx: 00000001 ecx: c090e000 edx: 00000000 esi: d92d7c7c edi: ca010100 ebp: ed6ea0ac esp: c0367ec0 ds: 007b es: 007b ss: e021 Process swapper (pid: 0, threadinfo=c0366000 task=c030d7c0) Stack: <0>c200ce24 109c6373 00000000 00000000 00000001 00000002 00000000 00000001 ed6ab7a0 00000000 00000000 c0367f6c c0133197 00000105 c090e000 c0367f6c 00000105 00008280 c035b680 00000105 ed6ab7a0 c013328f 00000105 0000000a Call Trace: [] handle_IRQ_event+0x38/0xa9 [] __do_IRQ+0x87/0xf8 [] do_IRQ+0x1a/0x25 [] evtchn_do_upcall+0x95/0xa9 [] hypervisor_callback+0x3d/0x48 [] safe_halt+0x7a/0xb2 [] xen_idle+0x2b/0x4e [] cpu_idle+0x52/0x67 [] start_kernel+0x2b8/0x33c [] unknown_bootoption+0x0/0x27a Code: c7 04 24 e0 17 30 c0 e8 39 8b ee ff 8b 44 24 38 c7 80 00 14 00 00 00 00 00 00 89 04 24 e8 75 03 00 00 bb a1 ff ff ff 8b 54 24 0c <8b> 42 24 89 44 24 08 89 5c 24 04 89 14 24 e8 3b eb fb ff 85 c0 <0>Kernel panic - not syncing: Fatal exception in interrupt And finally the domain-builder-ng.log when started with xend and working: 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_allocate: cmdline="root=/dev/xvda1 ro console=xvc0 earlyprintk=xen", features="" 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_kernel_file: filename="/boot/bzImage-domU-oldgame" 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_malloc_filemap : 1237 kB 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_malloc : 2653 kB 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_do_gunzip: unzip ok, 0x135462 -> 0x297540 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_parse_image: called 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary loader ... 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: loader probe failed 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_find_loader: trying Linux bzImage loader ... 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_probe_bzimage_kernel: kernel is not a bzImage 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: loader probe failed 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_find_loader: trying ELF-generic loader ... 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: loader probe OK 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_parse_binary: phdr: paddr=0xc0100000 memsz=0x20d500 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_parse_binary: phdr: paddr=0xc030d500 memsz=0xb3308 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_parse_binary: memory: 0xc0100000 -> 0xc03c0808 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: GUEST_OS = "linux" 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: GUEST_VERSION = "2.6" 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: XEN_VERSION = "xen-3.0" 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: VIRT_BASE = 0xc0000000 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: PADDR_OFFSET = 0xc0000000 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: ENTRY = 0xc0100000 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: HYPERCALL_PAGE = 0xc0101000 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: HV_START_LOW = 0xf5800000 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: FEATURES = "writable_page_tables|writable_descriptor_tables|auto_translated_physmap|pae_pgdir_above_4gb|supervisor_mode_kernel" 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: PAE_MODE = "yes" 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: LOADER = "generic" 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse: using notes from SHT_NOTE section 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_addr_calc_check: addresses: 2012-10-03 14:00:41 EEST [3773] xc: detail: virt_base = 0xc0000000 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_paddr_offset = 0xc0000000 2012-10-03 14:00:41 EEST [3773] xc: detail: virt_offset = 0x0 2012-10-03 14:00:41 EEST [3773] xc: detail: virt_kstart = 0xc0100000 2012-10-03 14:00:41 EEST [3773] xc: detail: virt_kend = 0xc03c0808 2012-10-03 14:00:41 EEST [3773] xc: detail: virt_entry = 0xc0100000 2012-10-03 14:00:41 EEST [3773] xc: detail: p2m_base = 0xffffffffffffffff 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_parse_elf_kernel: xen-3.0-x86_32p: 0xc0100000 -> 0xc03c0808 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_release: called 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_allocate: cmdline="root=/dev/xvda1 ro console=xvc0 earlyprintk=xen", features="" 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_kernel_file: filename="/boot/bzImage-domU-oldgame" 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_malloc_filemap : 1237 kB 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_malloc : 2653 kB 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_do_gunzip: unzip ok, 0x135462 -> 0x297540 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_boot_xen_init: ver 4.2, caps xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_parse_image: called 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary loader ... 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: loader probe failed 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_find_loader: trying Linux bzImage loader ... 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_probe_bzimage_kernel: kernel is not a bzImage 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: loader probe failed 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_find_loader: trying ELF-generic loader ... 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: loader probe OK 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_parse_binary: phdr: paddr=0xc0100000 memsz=0x20d500 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_parse_binary: phdr: paddr=0xc030d500 memsz=0xb3308 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_parse_binary: memory: 0xc0100000 -> 0xc03c0808 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: GUEST_OS = "linux" 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: GUEST_VERSION = "2.6" 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: XEN_VERSION = "xen-3.0" 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: VIRT_BASE = 0xc0000000 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: PADDR_OFFSET = 0xc0000000 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: ENTRY = 0xc0100000 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: HYPERCALL_PAGE = 0xc0101000 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: HV_START_LOW = 0xf5800000 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: FEATURES = "writable_page_tables|writable_descriptor_tables|auto_translated_physmap|pae_pgdir_above_4gb|supervisor_mode_kernel" 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: PAE_MODE = "yes" 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: LOADER = "generic" 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse: using notes from SHT_NOTE section 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_addr_calc_check: addresses: 2012-10-03 14:00:41 EEST [3773] xc: detail: virt_base = 0xc0000000 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_paddr_offset = 0xc0000000 2012-10-03 14:00:41 EEST [3773] xc: detail: virt_offset = 0x0 2012-10-03 14:00:41 EEST [3773] xc: detail: virt_kstart = 0xc0100000 2012-10-03 14:00:41 EEST [3773] xc: detail: virt_kend = 0xc03c0808 2012-10-03 14:00:41 EEST [3773] xc: detail: virt_entry = 0xc0100000 2012-10-03 14:00:41 EEST [3773] xc: detail: p2m_base = 0xffffffffffffffff 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_parse_elf_kernel: xen-3.0-x86_32p: 0xc0100000 -> 0xc03c0808 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_mem_init: mem 2048 MB, pages 0x80000 pages, 4k each 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_mem_init: 0x80000 pages 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_boot_mem_init: called 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: x86_compat: guest xen-3.0-x86_32p, address size 32 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_malloc : 4096 kB 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_build_image: called 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_alloc_segment: kernel : 0xc0100000 -> 0xc03c1000 (pfn 0x100 + 0x2c1 pages) 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x100+0x2c1 at 0x7fdebe53c000 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_load_binary: phdr 0 at 0x0x7fdebe53c000 -> 0x0x7fdebe749500 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_load_binary: phdr 1 at 0x0x7fdebe749500 -> 0x0x7fdebe7c893c 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_alloc_segment: phys2mach : 0xc03c1000 -> 0xc05c1000 (pfn 0x3c1 + 0x200 pages) 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x3c1+0x200 at 0x7fdebe33c000 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_alloc_page : start info : 0xc05c1000 (pfn 0x5c1) 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_alloc_page : xenstore : 0xc05c2000 (pfn 0x5c2) 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_alloc_page : console : 0xc05c3000 (pfn 0x5c3) 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: nr_page_tables: 0x00000000ffffffff/32: 0x0000000000000000 -> 0x00000000ffffffff, 1 table(s) 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: nr_page_tables: 0x000000003fffffff/30: 0x00000000c0000000 -> 0x00000000ffffffff, 1 table(s) 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: nr_page_tables: 0x00000000001fffff/21: 0x00000000c0000000 -> 0x00000000c07fffff, 4 table(s) 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_alloc_segment: page tables : 0xc05c4000 -> 0xc05ca000 (pfn 0x5c4 + 0x6 pages) 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x5c4+0x6 at 0x7fdeca12d000 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_alloc_page : boot stack : 0xc05ca000 (pfn 0x5ca) 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_build_image : virt_alloc_end : 0xc05cb000 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_build_image : virt_pgtab_end : 0xc0800000 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_boot_image: called 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: arch_setup_bootearly: doing nothing 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-x86_64 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-x86_32p <= matches 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_32 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_32p 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_64 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_update_guest_p2m: dst 32bit, pages 0x80000 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: clear_page: pfn 0x5c3, mfn 0x697ee5 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: clear_page: pfn 0x5c2, mfn 0x697ee6 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x5c1+0x1 at 0x7fdeca12a000 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: start_info_x86_32: called 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: setup_hypercall_page: vaddr=0xc0101000 pfn=0x101 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: domain builder memory footprint 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: allocated 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: malloc : 6780 kB 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: anon mmap : 0 bytes 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: mapped 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: file mmap : 1237 kB 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: domU mmap : 4896 kB 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: arch_setup_bootlate: shared_info: pfn 0x0, mfn 0xdbdf8 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: shared_info_x86_32: called 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: vcpu_x86_32: called 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: vcpu_x86_32: cr3: pfn 0x5c4 mfn 0x697ee4 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: launch_vm: called, ctxt=0x7fdebf7fa650 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_release: called - Valtteri 2012/10/3 Ian Campbell > On Wed, 2012-10-03 at 11:42 +0100, Valtteri Kiviniemi wrote: > > Hi, > > > > I tried to lower vcpus to 1, and now it produces a different crash: > > > > Unable to handle kernel NULL pointer dereference at virtual address > > 00000024 > > printing eip: > > c0232139 > > 005c4000 -> *pde = 00000000:00000000 > > Oops: 0000 [#1] > > SMP > > CPU: 0 > > EIP: 0061:[] Not tainted VLI > > EFLAGS: 00010097 (2.6.16.33-xen-domU-oldgame #1) > > EIP is at blkif_int+0x1dc/0x228 > > I don't suppose you have source / debug info for this kernel to resolve > this into a location? > > You say this exact same config works with xend? > > If so then, since this appears to relate to the devices, one thing which > might be worth trying is to set on_crash = "preserve" in your config and > run under both xend and xl. You can then collect the content of xenstore > (xenstore-ls -fp) in both cases (xend booted ok, xl preserved in the > crashed state), and compare. > > There will be a bunch of differences relating to the xend one finishing > its boot but something might stand out in the diff. Just posting both > sets of output might be useful. > > If you run "xl -vvv create" you should also get a bunch of stuff > relating to the domain builder and where it is placing things. Running > under xend I think something similar is dumped under /var/log/xen > (domain-build-ng.log?) > > What does your config file look like? > > Ian. > > > --001636ef09adc44f7f04cb25a56c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I dont have the kernel sources for that 2.6.16.33 any more, this= is a very old domU but it still in use since we run some applications ther= e which require old glibc and wont run on newer machines. The domU works pe= rfectly with xend, and has always worked (since xen 3.0.0 every xen upgrade= ). But now when I decided to move from xend to xl the problems started. Her= e are the info that you asked, its going to be a long post and hopefully I = remembered everything that you asked for:

config:

kernel =3D "/boot/vmlinuz-2.6.16.33-xen-domU-oldgam= e"
builder =3D "linux"
memory =3D "2048"
= name =3D "lightning"
vcpus =3D "8"
cpus =3D [ &qu= ot;0", "1", "2", "3", "4", &qu= ot;5", "6", "7" ]
vif =3D [ "mac=3D00:16:3e:1d:0d:91, bridge=3Dxenbr0" ]
disk = =3D [ "phy:/dev/virtuals/lightning,xvda1,w" ]
root =3D "/= dev/xvda1 ro"
extra =3D "xencons=3Dtty1 earlyprintk=3Dxen"= ;
on_poweroff =3D "destroy"
on_reboot =3D "restart"
on_crash =3D "preserve"
<= br>xenstore-ls -fp when started with xend and working:

/vm/54fd0bf5-= 0cc8-802a-880e-f5f9dc0e4ec2 =3D ""=A0=A0 (n0)
/vm/54fd0bf5-0cc= 8-802a-880e-f5f9dc0e4ec2/image =3D "(linux (kernel /boot/bzImage-domU-= oldgame) (args 'root=3D/dev/xvda1 ro console=3Dxvc0 earlyprintk=3Dxen&#= 39;) (superpages 0) (videoram 4) (pci ()) (nomigrate 0) (tsc_mode 0) (notes= (HV_START_LOW 411880652\..."=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/image/ostype =3D "linux"= =A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/image/kernel =3D &q= uot;/boot/bzImage-domU-oldgame"=A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-8= 80e-f5f9dc0e4ec2/image/cmdline =3D "root=3D/dev/xvda1 ro console=3Dxvc= 0 earlyprintk=3Dxen"=A0=A0 (n0,r11)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/image/ramdisk =3D ""=A0= =A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device =3D ""= ;=A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/vbd =3D &qu= ot;"=A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/vbd/51713 =3D ""= =A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/vbd/51713/fr= ontend =3D "/local/domain/11/device/vbd/51713"=A0=A0 (n0)
/vm/= 54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/vbd/51713/frontend-id =3D "= ;11"=A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/vbd/51713/backend-id =3D &q= uot;0"=A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/v= bd/51713/backend =3D "/local/domain/0/backend/vbd/11/51713"=A0=A0= (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/vif =3D ""=A0=A0 = (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/vif/0 =3D "&qu= ot;=A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/vif/0/fro= ntend =3D "/local/domain/11/device/vif/0"=A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/vif/0/frontend-id =3D "= ;11"=A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/vif= /0/backend-id =3D "0"=A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f= 5f9dc0e4ec2/device/vif/0/backend =3D "/local/domain/0/backend/vif/11/0= "=A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/console =3D ""=A0= =A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/console/0 =3D &= quot;"=A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/c= onsole/0/frontend =3D "/local/domain/11/device/console/0"=A0=A0 (= n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/console/0/frontend-id =3D &= quot;11"=A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device= /console/0/backend-id =3D "0"=A0=A0 (n0)
/vm/54fd0bf5-0cc8-802= a-880e-f5f9dc0e4ec2/device/console/0/backend =3D "/local/domain/0/back= end/console/11/0"=A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/on_xend_stop =3D "ignore"= ;=A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/pool_name =3D &quo= t;Pool-0"=A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/shado= w_memory =3D "0"=A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/uuid =3D "54fd0bf5-0cc8-802a-= 880e-f5f9dc0e4ec2"=A0=A0 (n0,r11)
/vm/54fd0bf5-0cc8-802a-880e-f5f9d= c0e4ec2/on_reboot =3D "restart"=A0=A0 (n0)
/vm/54fd0bf5-0cc8-8= 02a-880e-f5f9dc0e4ec2/start_time =3D "1349262041.78"=A0=A0 (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/on_poweroff =3D "destroy"= ;=A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/bootloader_args = =3D ""=A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/on_= xend_start =3D "ignore"=A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/on_crash =3D "preserve"= =A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/xend =3D "&quo= t;=A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/xend/restart_coun= t =3D "0"=A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/vcpus =3D "1"=A0=A0 (n0)=
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/vcpu_avail =3D "1"= =A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/bootloader =3D &quo= t;"=A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/name =3D "lightning"=A0= =A0 (n0)

xenstore-ls -fp when started with xl and crashed (preserved= ):

/vm =3D ""=A0=A0 (n0)
/vm/e2261517-a75b-4c02-b9db-da= 9c21a05130 =3D ""=A0=A0 (n0,r1)
/vm/e2261517-a75b-4c02-b9db-da9c21a05130/uuid =3D "e2261517-a75b-4c02-= b9db-da9c21a05130"=A0=A0 (n0,r1)
/vm/e2261517-a75b-4c02-b9db-da9c21= a05130/name =3D "lightning"=A0=A0 (n0,r1)
/vm/e2261517-a75b-4c= 02-b9db-da9c21a05130/image =3D ""=A0=A0 (n0,r1)
/vm/e2261517-a75b-4c02-b9db-da9c21a05130/image/ostype =3D "linux"= =A0=A0 (n0,r1)
/vm/e2261517-a75b-4c02-b9db-da9c21a05130/image/kernel =3D= "/boot/bzImage-domU-oldgame"=A0=A0 (n0,r1)
/vm/e2261517-a75b-= 4c02-b9db-da9c21a05130/image/cmdline =3D "root=3D/dev/xvda1 ro console= =3Dxvc0 earlyprintk=3Dxen"=A0=A0 (n0,r1)
/vm/e2261517-a75b-4c02-b9db-da9c21a05130/start_time =3D "1349262365.43= "=A0=A0 (n0,r1)
/libxl =3D ""=A0=A0 (n0)
/libxl/1 =3D = ""=A0=A0 (n0)
/libxl/1/dm-version =3D "qemu_xen"=A0= =A0 (n0)

domU starter with xl -vvv create:

root@xen-2:~# xl -vvv create /etc/xen/lightning.cfg -c
Parsing confi= g from /etc/xen/lightning.cfg
libxl: debug: libxl_create.c:1173:do_domai= n_create: ao 0x6243d0: create: how=3D(nil) callback=3D(nil) poller=3D0x623b= 80
libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk vdev= =3Dxvda1 spec.backend=3Dunknown
libxl: debug: libxl_device.c:265:libxl__= device_disk_set_backend: Disk vdev=3Dxvda1, using backend phy
libxl: deb= ug: libxl_create.c:677:initiate_domain_create: running bootloader
libxl: debug: libxl_bootloader.c:327:libxl__bootloader_run: no bootloader c= onfigured, using user supplied kernel
libxl: debug: libxl_event.c:561:li= bxl__ev_xswatch_deregister: watch w=3D0x624750: deregister unregistered
libxl: debug: libxl_numa.c:435:libxl__get_numa_candidate: New best NUMA pla= cement candidate found: nr_nodes=3D1, nr_cpus=3D8, nr_vcpus=3D9, free_memkb= =3D31043
libxl: detail: libxl_dom.c:192:numa_place_domain: NUMA placemen= t candidate with 1 nodes, 8 cpus and 31043 KB free selected
domainbuilder: detail: xc_dom_allocate: cmdline=3D"root=3D/dev/xvda1 r= o console=3Dxvc0 earlyprintk=3Dxen", features=3D"(null)"
= libxl: debug: libxl_dom.c:380:libxl__build_pv: pv kernel mapped 0 path /boo= t/bzImage-domU-oldgame

domainbuilder: detail: xc_dom_kernel_file: filename=3D"/boot/bzIma= ge-domU-oldgame"
domainbuilder: detail: xc_dom_malloc_filemap=A0=A0= =A0 : 1237 kB
domainbuilder: detail: xc_dom_malloc=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 : 2653 kB
domainbuilder: detail: xc_dom_do_gunzip: unzip ok= , 0x135462 -> 0x297540
domainbuilder: detail: xc_dom_boot_xen_init: ver 4.2, caps xen-3.0-x86_64 x= en-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64
domainbuild= er: detail: xc_dom_parse_image: called
domainbuilder: detail: xc_dom_fin= d_loader: trying multiboot-binary loader ...
domainbuilder: detail: loader probe failed
domainbuilder: detail: xc_dom= _find_loader: trying Linux bzImage loader ...
domainbuilder: detail: xc_= dom_probe_bzimage_kernel: kernel is not a bzImage
domainbuilder: detail:= loader probe failed
domainbuilder: detail: xc_dom_find_loader: trying ELF-generic loader ...domainbuilder: detail: loader probe OK
xc: detail: elf_parse_binary: ph= dr: paddr=3D0xc0100000 memsz=3D0x20d500
xc: detail: elf_parse_binary: ph= dr: paddr=3D0xc030d500 memsz=3D0xb3308
xc: detail: elf_parse_binary: memory: 0xc0100000 -> 0xc03c0808
xc: de= tail: elf_xen_parse_note: GUEST_OS =3D "linux"
xc: detail: elf= _xen_parse_note: GUEST_VERSION =3D "2.6"
xc: detail: elf_xen_p= arse_note: XEN_VERSION =3D "xen-3.0"
xc: detail: elf_xen_parse_note: VIRT_BASE =3D 0xc0000000
xc: detail: elf= _xen_parse_note: PADDR_OFFSET =3D 0xc0000000
xc: detail: elf_xen_parse_n= ote: ENTRY =3D 0xc0100000
xc: detail: elf_xen_parse_note: HYPERCALL_PAGE= =3D 0xc0101000
xc: detail: elf_xen_parse_note: HV_START_LOW =3D 0xf5800000
xc: detail: = elf_xen_parse_note: FEATURES =3D "writable_page_tables|writable_descri= ptor_tables|auto_translated_physmap|pae_pgdir_above_4gb|supervisor_mode_ker= nel"
xc: detail: elf_xen_parse_note: PAE_MODE =3D "yes"
xc: detail:= elf_xen_parse_note: LOADER =3D "generic"
xc: detail: elf_xen_= parse: using notes from SHT_NOTE section
xc: detail: elf_xen_addr_calc_c= heck: addresses:
xc: detail:=A0=A0=A0=A0 virt_base=A0=A0=A0=A0=A0=A0=A0 =3D 0xc0000000
xc= : detail:=A0=A0=A0=A0 elf_paddr_offset =3D 0xc0000000
xc: detail:=A0=A0= =A0=A0 virt_offset=A0=A0=A0=A0=A0 =3D 0x0
xc: detail:=A0=A0=A0=A0 virt_k= start=A0=A0=A0=A0=A0 =3D 0xc0100000
xc: detail:=A0=A0=A0=A0 virt_kend=A0= =A0=A0=A0=A0=A0=A0 =3D 0xc03c0808
xc: detail:=A0=A0=A0=A0 virt_entry=A0=A0=A0=A0=A0=A0 =3D 0xc0100000
xc: = detail:=A0=A0=A0=A0 p2m_base=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0xffffffffffffffff=
domainbuilder: detail: xc_dom_parse_elf_kernel: xen-3.0-x86_32p: 0xc010= 0000 -> 0xc03c0808
domainbuilder: detail: xc_dom_mem_init: mem 2048 M= B, pages 0x80000 pages, 4k each
domainbuilder: detail: xc_dom_mem_init: 0x80000 pages
domainbuilder: det= ail: xc_dom_boot_mem_init: called
domainbuilder: detail: x86_compat: gue= st xen-3.0-x86_32p, address size 32
domainbuilder: detail: xc_dom_malloc= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 4096 kB
domainbuilder: detail: xc_dom_build_image: called
domainbuilder: detail:= xc_dom_alloc_segment:=A0=A0 kernel=A0=A0=A0=A0=A0=A0 : 0xc0100000 -> 0x= c03c1000=A0 (pfn 0x100 + 0x2c1 pages)
domainbuilder: detail: xc_dom_pfn_= to_ptr: domU mapping: pfn 0x100+0x2c1 at 0x7fcba1b83000
xc: detail: elf_load_binary: phdr 0 at 0x0x7fcba1b83000 -> 0x0x7fcba1d90= 500
xc: detail: elf_load_binary: phdr 1 at 0x0x7fcba1d90500 -> 0x0x7f= cba1e0f93c
domainbuilder: detail: xc_dom_alloc_segment:=A0=A0 phys2mach= =A0=A0=A0 : 0xc03c1000 -> 0xc05c1000=A0 (pfn 0x3c1 + 0x200 pages)
domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x3c1+0x200 at = 0x7fcba1983000
domainbuilder: detail: xc_dom_alloc_page=A0=A0 :=A0=A0 st= art info=A0=A0 : 0xc05c1000 (pfn 0x5c1)
domainbuilder: detail: xc_dom_al= loc_page=A0=A0 :=A0=A0 xenstore=A0=A0=A0=A0 : 0xc05c2000 (pfn 0x5c2)
domainbuilder: detail: xc_dom_alloc_page=A0=A0 :=A0=A0 console=A0=A0=A0=A0= =A0 : 0xc05c3000 (pfn 0x5c3)
domainbuilder: detail: nr_page_tables: 0x00= 000000ffffffff/32: 0x0000000000000000 -> 0x00000000ffffffff, 1 table(s)<= br>domainbuilder: detail: nr_page_tables: 0x000000003fffffff/30: 0x00000000= c0000000 -> 0x00000000ffffffff, 1 table(s)
domainbuilder: detail: nr_page_tables: 0x00000000001fffff/21: 0x00000000c00= 00000 -> 0x00000000c07fffff, 4 table(s)
domainbuilder: detail: xc_dom= _alloc_segment:=A0=A0 page tables=A0 : 0xc05c4000 -> 0xc05ca000=A0 (pfn = 0x5c4 + 0x6 pages)
domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x5c4+0x6 at 0x= 7fcba197d000
domainbuilder: detail: xc_dom_alloc_page=A0=A0 :=A0=A0 boot= stack=A0=A0 : 0xc05ca000 (pfn 0x5ca)
domainbuilder: detail: xc_dom_buil= d_image=A0 : virt_alloc_end : 0xc05cb000
domainbuilder: detail: xc_dom_build_image=A0 : virt_pgtab_end : 0xc0800000<= br>domainbuilder: detail: xc_dom_boot_image: called
domainbuilder: detai= l: arch_setup_bootearly: doing nothing
domainbuilder: detail: xc_dom_com= pat_check: supported guest type: xen-3.0-x86_64
domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-x= 86_32p <=3D matches
domainbuilder: detail: xc_dom_compat_check: suppo= rted guest type: hvm-3.0-x86_32
domainbuilder: detail: xc_dom_compat_che= ck: supported guest type: hvm-3.0-x86_32p
domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x= 86_64
domainbuilder: detail: xc_dom_update_guest_p2m: dst 32bit, pages 0= x80000
domainbuilder: detail: clear_page: pfn 0x5c3, mfn 0x649f86
domainbuilder: detail: clear_page: pfn 0x5c2, mfn 0x649f87
domainbuilder= : detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x5c1+0x1 at 0x7fcba4599000<= br>domainbuilder: detail: start_info_x86_32: called
domainbuilder: detai= l: setup_hypercall_page: vaddr=3D0xc0101000 pfn=3D0x101
domainbuilder: detail: domain builder memory footprint
domainbuilder: de= tail:=A0=A0=A0 allocated
domainbuilder: detail:=A0=A0=A0=A0=A0=A0 malloc= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 6780 kB
domainbuilder: detail:=A0= =A0=A0=A0=A0=A0 anon mmap=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 0 bytes
domainbui= lder: detail:=A0=A0=A0 mapped
domainbuilder: detail:=A0=A0=A0=A0=A0=A0 file mmap=A0=A0=A0=A0=A0=A0=A0=A0= =A0 : 1237 kB
domainbuilder: detail:=A0=A0=A0=A0=A0=A0 domU mmap=A0=A0= =A0=A0=A0=A0=A0=A0=A0 : 4896 kB
domainbuilder: detail: arch_setup_bootla= te: shared_info: pfn 0x0, mfn 0xdbdf8
domainbuilder: detail: shared_info= _x86_32: called
domainbuilder: detail: vcpu_x86_32: called
domainbuilder: detail: vcpu_x= 86_32: cr3: pfn 0x5c4 mfn 0x649f85
domainbuilder: detail: launch_vm: cal= led, ctxt=3D0x7fff96435b40
domainbuilder: detail: xc_dom_release: called=
libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk vdev= =3Dxvda1 spec.backend=3Dphy
libxl: debug: libxl_event.c:512:libxl__ev_xs= watch_register: watch w=3D0x625598 wpath=3D/local/domain/0/backend/vbd/2/51= 713/state token=3D3/0: register slotnum=3D3
libxl: debug: libxl_create.c:1186:do_domain_create: ao 0x6243d0: inprogress= : poller=3D0x623b80, flags=3Di
libxl: debug: libxl_event.c:457:watchfd_c= allback: watch w=3D0x625598 wpath=3D/local/domain/0/backend/vbd/2/51713/sta= te token=3D3/0: event epath=3D/local/domain/0/backend/vbd/2/51713/state
libxl: debug: libxl_event.c:596:devstate_watch_callback: backend /local/dom= ain/0/backend/vbd/2/51713/state wanted state 2 ok
libxl: debug: libxl_ev= ent.c:549:libxl__ev_xswatch_deregister: watch w=3D0x625598 wpath=3D/local/d= omain/0/backend/vbd/2/51713/state token=3D3/0: deregister slotnum=3D3
libxl: debug: libxl_event.c:561:libxl__ev_xswatch_deregister: watch w=3D0x6= 25598: deregister unregistered
libxl: debug: libxl_device.c:916:device_h= otplug: calling hotplug script: /etc/xen/scripts/block add
libxl: debug:= libxl_event.c:426:watchfd_callback: watch epath=3D/local/domain/0/backend/= vbd/2/51713/state token=3D3/0: empty slot
libxl: debug: libxl_event.c:512:libxl__ev_xswatch_register: watch w=3D0x626= f38 wpath=3D/local/domain/0/backend/vif/2/0/state token=3D3/1: register slo= tnum=3D3
libxl: debug: libxl_event.c:457:watchfd_callback: watch w=3D0x6= 26f38 wpath=3D/local/domain/0/backend/vif/2/0/state token=3D3/1: event epat= h=3D/local/domain/0/backend/vif/2/0/state
libxl: debug: libxl_event.c:596:devstate_watch_callback: backend /local/dom= ain/0/backend/vif/2/0/state wanted state 2 ok
libxl: debug: libxl_event.= c:549:libxl__ev_xswatch_deregister: watch w=3D0x626f38 wpath=3D/local/domai= n/0/backend/vif/2/0/state token=3D3/1: deregister slotnum=3D3
libxl: debug: libxl_event.c:561:libxl__ev_xswatch_deregister: watch w=3D0x6= 26f38: deregister unregistered
libxl: debug: libxl_device.c:916:device_h= otplug: calling hotplug script: /etc/xen/scripts/vif-bridge online
libxl= : debug: libxl_event.c:1677:libxl__ao_progress_report: ao 0x6243d0: progres= s report: callback queued aop=3D0x627700
libxl: debug: libxl_event.c:1497:libxl__ao_complete: ao 0x6243d0: complete,= rc=3D0
libxl: debug: libxl_event.c:1090:egc_run_callbacks: ao 0x6243d0:= progress report: callback aop=3D0x627700
libxl: debug: libxl_event.c:14= 69:libxl__ao__destroy: ao 0x6243d0: destroy
Daemon running with PID 4881
Linux version 2.6.16.33-xen-domU-oldgame (r= oot@lightning) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) = #1 SMP Fri Sep 28 14:56:14 EEST 2012
BIOS-provided physical RAM map:
=A0Xen: 0000000000000000 - 0000000080000000 (usable)
1320MB HIGHMEM avai= lable.
727MB LOWMEM available.
NX (Execute Disable) protection: activ= e
early console enabled
Built 1 zonelists
Kernel command line: roo= t=3D/dev/xvda1 ro console=3Dxvc0 earlyprintk=3Dxen
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU e= xception support... done.
Initializing CPU#0
PID hash table entries: = 4096 (order: 12, 65536 bytes)
Xen reported: 3392.372 MHz processor.
disabling early console
Console: colour dummy device 80x25
Dentry cac= he hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash = table entries: 65536 (order: 6, 262144 bytes)
Software IO TLB disabled vmalloc area: ee000000-f51fe000, maxmem 2d7fe000
Memory: 2072132k/209715= 2k available (1917k kernel code, 23952k reserved, 537k data, 148k init, 135= 1688k highmem)
Checking if this processor honours the WP bit even in sup= ervisor mode... Ok.
Calibrating delay using timer specific routine.. 6820.46 BogoMIPS (lpj=3D34= 10231)
Mount-cache hash table entries: 512
CPU: L1 I cache: 32K, L1 D= cache: 32K
CPU: L2 cache: 256K
CPU: L3 cache: 8192K
Checking '= ;hlt' instruction... OK.
Brought up 1 CPUs
migration_cost=3D0
Grant table initialized
NET: = Registered protocol family 16
xen_mem: Initialising balloon driver.
S= CSI subsystem initialized
highmem bounce pool size: 64 pages
Installi= ng knfsd (copyright (C) 1996 okir@mona= d.swb.de).
Initializing Cryptographic API
io scheduler noop registered
io schedu= ler cfq registered (default)
rtc: IRQ 8 is not free.
i8042.c: No cont= roller found.
loop: loaded (max 8 devices)
Xen virtual console succes= sfully installed as tty1
Event-channel device installed.
netfront: Initialising virtual ethernet = driver.
mice: PS/2 mouse device common for all mice
Netfilter message= s via NETLINK v0.30.
NET: Registered protocol family 2
netfront: devi= ce eth0 has copying receive path.
Registering block device major 202
blkfront: xvda1: barriers enabled
= IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP es= tablished hash table entries: 131072 (order: 8, 1048576 bytes)
TCP bind = hash table entries: 65536 (order: 7, 524288 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno reg= istered
ip_conntrack version 2.4 (8192 buckets, 65536 max) - 232 bytes p= er conntrack
ip_conntrack_pptp version 3.1 loaded
ip_nat_pptp version= 3.0 loaded
ip_tables: (C) 2000-2006 Netfilter Core Team
ipt_recent v0.3.1: Stephen = Frost <sfrost@snowman.net>.= =A0 http://snowman.net/= projects/ipt_recent/
TCP bic registered
NET: Registered protocol family 1
NET: Registered = protocol family 17
NET: Registered protocol family 15
Bridge firewall= ing registered
802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>
All bugs added by David S. Miller <d= avem@redhat.com>
Using IPI Shortcut mode
end_request: I/O erro= r, dev xvda1, sector 2
EXT3-fs: unable to read superblock
Unable to h= andle kernel NULL pointer dereference at virtual address 00000024
=A0printing eip:
c0232139
005c4000 -> *pde =3D 00000000:00000000Oops: 0000 [#1]
SMP
CPU:=A0=A0=A0 0
EIP:=A0=A0=A0 0061:[<c023= 2139>]=A0=A0=A0 Not tainted VLI
EFLAGS: 00010097=A0=A0 (2.6.16.33-xen= -domU-oldgame #1)
EIP is at blkif_int+0x1dc/0x228
eax: 00000000=A0=A0 ebx: 00000001=A0=A0 ecx: c090e000=A0=A0 edx: 00000000esi: d92d7c7c=A0=A0 edi: ca010100=A0=A0 ebp: ed6ea0ac=A0=A0 esp: c0367ec0=
ds: 007b=A0=A0 es: 007b=A0=A0 ss: e021
Process swapper (pid: 0, thre= adinfo=3Dc0366000 task=3Dc030d7c0)
Stack: <0>c200ce24 109c6373 00000000 00000000 00000001 00000002 00000= 000 00000001
=A0=A0=A0=A0=A0=A0 ed6ab7a0 00000000 00000000 c0367f6c c013= 3197 00000105 c090e000 c0367f6c
=A0=A0=A0=A0=A0=A0 00000105 00008280 c03= 5b680 00000105 ed6ab7a0 c013328f 00000105 0000000a
Call Trace:
=A0[<c0133197>] handle_IRQ_event+0x38/0xa9
=A0[<= c013328f>] __do_IRQ+0x87/0xf8
=A0[<c0106782>] do_IRQ+0x1a/0x25<= br>=A0[<c0228d85>] evtchn_do_upcall+0x95/0xa9
=A0[<c010504d>= ] hypervisor_callback+0x3d/0x48
=A0[<c0107ecf>] safe_halt+0x7a/0xb2
=A0[<c0102efd>] xen_idle= +0x2b/0x4e
=A0[<c0103014>] cpu_idle+0x52/0x67
=A0[<c036871c&= gt;] start_kernel+0x2b8/0x33c
=A0[<c03681ea>] unknown_bootoption+0= x0/0x27a
Code: c7 04 24 e0 17 30 c0 e8 39 8b ee ff 8b 44 24 38 c7 80 00 14 00 00 00 = 00 00 00 89 04 24 e8 75 03 00 00 bb a1 ff ff ff 8b 54 24 0c <8b> 42 2= 4 89 44 24 08 89 5c 24 04 89 14 24 e8 3b eb fb ff 85 c0
=A0<0>Kern= el panic - not syncing: Fatal exception in interrupt

And finally the domain-builder-ng.log when started with xend and workin= g:

2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_all= ocate: cmdline=3D"root=3D/dev/xvda1 ro console=3Dxvc0 earlyprintk=3Dxe= n", features=3D""
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_kernel_file: = filename=3D"/boot/bzImage-domU-oldgame"
2012-10-03 14:00:41 EE= ST [3773] domainbuilder: detail: xc_dom_malloc_filemap=A0=A0=A0 : 1237 kB2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_malloc=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 2653 kB
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_do_gunzip: un= zip ok, 0x135462 -> 0x297540
2012-10-03 14:00:41 EEST [3773] domainbu= ilder: detail: xc_dom_parse_image: called
2012-10-03 14:00:41 EEST [3773= ] domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary loader= ...
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: loader probe failed<= br>2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_find_loade= r: trying Linux bzImage loader ...
2012-10-03 14:00:41 EEST [3773] doma= inbuilder: detail: xc_dom_probe_bzimage_kernel: kernel is not a bzImage
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: loader probe failed<= br>2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_find_loade= r: trying ELF-generic loader ...
2012-10-03 14:00:41 EEST [3773] domain= builder: detail: loader probe OK
2012-10-03 14:00:41 EEST [3773] xc: detail: elf_parse_binary: phdr: paddr= =3D0xc0100000 memsz=3D0x20d500
2012-10-03 14:00:41 EEST [3773] xc: detai= l: elf_parse_binary: phdr: paddr=3D0xc030d500 memsz=3D0xb3308
2012-10-03= 14:00:41 EEST [3773] xc: detail: elf_parse_binary: memory: 0xc0100000 ->= ; 0xc03c0808
2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: GUEST_OS = =3D "linux"
2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xe= n_parse_note: GUEST_VERSION =3D "2.6"
2012-10-03 14:00:41 EEST= [3773] xc: detail: elf_xen_parse_note: XEN_VERSION =3D "xen-3.0"=
2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: VIRT_BASE = =3D 0xc0000000
2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse= _note: PADDR_OFFSET =3D 0xc0000000
2012-10-03 14:00:41 EEST [3773] xc: d= etail: elf_xen_parse_note: ENTRY =3D 0xc0100000
2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: HYPERCALL_P= AGE =3D 0xc0101000
2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_p= arse_note: HV_START_LOW =3D 0xf5800000
2012-10-03 14:00:41 EEST [3773] x= c: detail: elf_xen_parse_note: FEATURES =3D "writable_page_tables|writ= able_descriptor_tables|auto_translated_physmap|pae_pgdir_above_4gb|supervis= or_mode_kernel"
2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: PAE_MODE = =3D "yes"
2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_= parse_note: LOADER =3D "generic"
2012-10-03 14:00:41 EEST [377= 3] xc: detail: elf_xen_parse: using notes from SHT_NOTE section
2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_addr_calc_check: addres= ses:
2012-10-03 14:00:41 EEST [3773] xc: detail:=A0=A0=A0=A0 virt_base= =A0=A0=A0=A0=A0=A0=A0 =3D 0xc0000000
2012-10-03 14:00:41 EEST [3773] xc:= detail:=A0=A0=A0=A0 elf_paddr_offset =3D 0xc0000000
2012-10-03 14:00:41 EEST [3773] xc: detail:=A0=A0=A0=A0 virt_offset=A0=A0= =A0=A0=A0 =3D 0x0
2012-10-03 14:00:41 EEST [3773] xc: detail:=A0=A0=A0= =A0 virt_kstart=A0=A0=A0=A0=A0 =3D 0xc0100000
2012-10-03 14:00:41 EEST [= 3773] xc: detail:=A0=A0=A0=A0 virt_kend=A0=A0=A0=A0=A0=A0=A0 =3D 0xc03c0808=
2012-10-03 14:00:41 EEST [3773] xc: detail:=A0=A0=A0=A0 virt_entry=A0=A0=A0= =A0=A0=A0 =3D 0xc0100000
2012-10-03 14:00:41 EEST [3773] xc: detail:=A0= =A0=A0=A0 p2m_base=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0xffffffffffffffff
2012-1= 0-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_parse_elf_kernel: x= en-3.0-x86_32p: 0xc0100000 -> 0xc03c0808
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_release: call= ed
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_allocat= e: cmdline=3D"root=3D/dev/xvda1 ro console=3Dxvc0 earlyprintk=3Dxen&qu= ot;, features=3D""
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_kernel_file: = filename=3D"/boot/bzImage-domU-oldgame"
2012-10-03 14:00:41 EE= ST [3773] domainbuilder: detail: xc_dom_malloc_filemap=A0=A0=A0 : 1237 kB2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_malloc=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 2653 kB
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_do_gunzip: un= zip ok, 0x135462 -> 0x297540
2012-10-03 14:00:41 EEST [3773] domainbu= ilder: detail: xc_dom_boot_xen_init: ver 4.2, caps xen-3.0-x86_64 xen-3.0-x= 86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_parse_image: = called
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_fin= d_loader: trying multiboot-binary loader ...
2012-10-03 14:00:41 EEST [= 3773] domainbuilder: detail: loader probe failed
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_find_loader: = trying Linux bzImage loader ...
2012-10-03 14:00:41 EEST [3773] domainb= uilder: detail: xc_dom_probe_bzimage_kernel: kernel is not a bzImage
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: loader probe failed<= br>2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_find_loade= r: trying ELF-generic loader ...
2012-10-03 14:00:41 EEST [3773] domain= builder: detail: loader probe OK
2012-10-03 14:00:41 EEST [3773] xc: detail: elf_parse_binary: phdr: paddr= =3D0xc0100000 memsz=3D0x20d500
2012-10-03 14:00:41 EEST [3773] xc: detai= l: elf_parse_binary: phdr: paddr=3D0xc030d500 memsz=3D0xb3308
2012-10-03= 14:00:41 EEST [3773] xc: detail: elf_parse_binary: memory: 0xc0100000 ->= ; 0xc03c0808
2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: GUEST_OS = =3D "linux"
2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xe= n_parse_note: GUEST_VERSION =3D "2.6"
2012-10-03 14:00:41 EEST= [3773] xc: detail: elf_xen_parse_note: XEN_VERSION =3D "xen-3.0"=
2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: VIRT_BASE = =3D 0xc0000000
2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse= _note: PADDR_OFFSET =3D 0xc0000000
2012-10-03 14:00:41 EEST [3773] xc: d= etail: elf_xen_parse_note: ENTRY =3D 0xc0100000
2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: HYPERCALL_P= AGE =3D 0xc0101000
2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_p= arse_note: HV_START_LOW =3D 0xf5800000
2012-10-03 14:00:41 EEST [3773] x= c: detail: elf_xen_parse_note: FEATURES =3D "writable_page_tables|writ= able_descriptor_tables|auto_translated_physmap|pae_pgdir_above_4gb|supervis= or_mode_kernel"
2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: PAE_MODE = =3D "yes"
2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_= parse_note: LOADER =3D "generic"
2012-10-03 14:00:41 EEST [377= 3] xc: detail: elf_xen_parse: using notes from SHT_NOTE section
2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_addr_calc_check: addres= ses:
2012-10-03 14:00:41 EEST [3773] xc: detail:=A0=A0=A0=A0 virt_base= =A0=A0=A0=A0=A0=A0=A0 =3D 0xc0000000
2012-10-03 14:00:41 EEST [3773] xc:= detail:=A0=A0=A0=A0 elf_paddr_offset =3D 0xc0000000
2012-10-03 14:00:41 EEST [3773] xc: detail:=A0=A0=A0=A0 virt_offset=A0=A0= =A0=A0=A0 =3D 0x0
2012-10-03 14:00:41 EEST [3773] xc: detail:=A0=A0=A0= =A0 virt_kstart=A0=A0=A0=A0=A0 =3D 0xc0100000
2012-10-03 14:00:41 EEST [= 3773] xc: detail:=A0=A0=A0=A0 virt_kend=A0=A0=A0=A0=A0=A0=A0 =3D 0xc03c0808=
2012-10-03 14:00:41 EEST [3773] xc: detail:=A0=A0=A0=A0 virt_entry=A0=A0=A0= =A0=A0=A0 =3D 0xc0100000
2012-10-03 14:00:41 EEST [3773] xc: detail:=A0= =A0=A0=A0 p2m_base=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0xffffffffffffffff
2012-1= 0-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_parse_elf_kernel: x= en-3.0-x86_32p: 0xc0100000 -> 0xc03c0808
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_mem_init: mem= 2048 MB, pages 0x80000 pages, 4k each
2012-10-03 14:00:41 EEST [3773] d= omainbuilder: detail: xc_dom_mem_init: 0x80000 pages
2012-10-03 14:00:41= EEST [3773] domainbuilder: detail: xc_dom_boot_mem_init: called
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: x86_compat: guest xe= n-3.0-x86_32p, address size 32
2012-10-03 14:00:41 EEST [3773] domainbui= lder: detail: xc_dom_malloc=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 4096 kB
2= 012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_build_image: c= alled
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_alloc_segment= :=A0=A0 kernel=A0=A0=A0=A0=A0=A0 : 0xc0100000 -> 0xc03c1000=A0 (pfn 0x10= 0 + 0x2c1 pages)
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: = xc_dom_pfn_to_ptr: domU mapping: pfn 0x100+0x2c1 at 0x7fdebe53c000
2012-10-03 14:00:41 EEST [3773] xc: detail: elf_load_binary: phdr 0 at 0x0x= 7fdebe53c000 -> 0x0x7fdebe749500
2012-10-03 14:00:41 EEST [3773] xc: = detail: elf_load_binary: phdr 1 at 0x0x7fdebe749500 -> 0x0x7fdebe7c893c<= br> 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_alloc_segment= :=A0=A0 phys2mach=A0=A0=A0 : 0xc03c1000 -> 0xc05c1000=A0 (pfn 0x3c1 + 0x= 200 pages)
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom= _pfn_to_ptr: domU mapping: pfn 0x3c1+0x200 at 0x7fdebe33c000
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_alloc_page=A0= =A0 :=A0=A0 start info=A0=A0 : 0xc05c1000 (pfn 0x5c1)
2012-10-03 14:00:4= 1 EEST [3773] domainbuilder: detail: xc_dom_alloc_page=A0=A0 :=A0=A0 xensto= re=A0=A0=A0=A0 : 0xc05c2000 (pfn 0x5c2)
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_alloc_page=A0= =A0 :=A0=A0 console=A0=A0=A0=A0=A0 : 0xc05c3000 (pfn 0x5c3)
2012-10-03 1= 4:00:41 EEST [3773] domainbuilder: detail: nr_page_tables: 0x00000000ffffff= ff/32: 0x0000000000000000 -> 0x00000000ffffffff, 1 table(s)
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: nr_page_tables: 0x00= 0000003fffffff/30: 0x00000000c0000000 -> 0x00000000ffffffff, 1 table(s)<= br>2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: nr_page_tables: 0= x00000000001fffff/21: 0x00000000c0000000 -> 0x00000000c07fffff, 4 table(= s)
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_alloc_segment= :=A0=A0 page tables=A0 : 0xc05c4000 -> 0xc05ca000=A0 (pfn 0x5c4 + 0x6 pa= ges)
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_pfn_t= o_ptr: domU mapping: pfn 0x5c4+0x6 at 0x7fdeca12d000
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_alloc_page=A0= =A0 :=A0=A0 boot stack=A0=A0 : 0xc05ca000 (pfn 0x5ca)
2012-10-03 14:00:4= 1 EEST [3773] domainbuilder: detail: xc_dom_build_image=A0 : virt_alloc_end= : 0xc05cb000
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_build_image= =A0 : virt_pgtab_end : 0xc0800000
2012-10-03 14:00:41 EEST [3773] domain= builder: detail: xc_dom_boot_image: called
2012-10-03 14:00:41 EEST [377= 3] domainbuilder: detail: arch_setup_bootearly: doing nothing
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_compat_check:= supported guest type: xen-3.0-x86_64
2012-10-03 14:00:41 EEST [3773] do= mainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-x86= _32p <=3D matches
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_compat_check:= supported guest type: hvm-3.0-x86_32
2012-10-03 14:00:41 EEST [3773] do= mainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86= _32p
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_compat_check:= supported guest type: hvm-3.0-x86_64
2012-10-03 14:00:41 EEST [3773] do= mainbuilder: detail: xc_dom_update_guest_p2m: dst 32bit, pages 0x80000
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: clear_page: pfn 0x5c= 3, mfn 0x697ee5
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: c= lear_page: pfn 0x5c2, mfn 0x697ee6
2012-10-03 14:00:41 EEST [3773] domai= nbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x5c1+0x1 at 0x7fdec= a12a000
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: start_info_x86_32: c= alled
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: setup_hyper= call_page: vaddr=3D0xc0101000 pfn=3D0x101
2012-10-03 14:00:41 EEST [3773= ] domainbuilder: detail: domain builder memory footprint
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail:=A0=A0=A0 allocated2012-10-03 14:00:41 EEST [3773] domainbuilder: detail:=A0=A0=A0=A0=A0=A0 = malloc=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 6780 kB
2012-10-03 14:00:41= EEST [3773] domainbuilder: detail:=A0=A0=A0=A0=A0=A0 anon mmap=A0=A0=A0=A0= =A0=A0=A0=A0=A0 : 0 bytes
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail:=A0=A0=A0 mapped
2= 012-10-03 14:00:41 EEST [3773] domainbuilder: detail:=A0=A0=A0=A0=A0=A0 fil= e mmap=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 1237 kB
2012-10-03 14:00:41 EEST [37= 73] domainbuilder: detail:=A0=A0=A0=A0=A0=A0 domU mmap=A0=A0=A0=A0=A0=A0=A0= =A0=A0 : 4896 kB
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: arch_setup_bootlate:= shared_info: pfn 0x0, mfn 0xdbdf8
2012-10-03 14:00:41 EEST [3773] domai= nbuilder: detail: shared_info_x86_32: called
2012-10-03 14:00:41 EEST [3= 773] domainbuilder: detail: vcpu_x86_32: called
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: vcpu_x86_32: cr3: pf= n 0x5c4 mfn 0x697ee4
2012-10-03 14:00:41 EEST [3773] domainbuilder: deta= il: launch_vm: called, ctxt=3D0x7fdebf7fa650
2012-10-03 14:00:41 EEST [3= 773] domainbuilder: detail: xc_dom_release: called

- Valtteri

2012/10/3 Ian Campbell <Ian.Campbell@citrix.com>
On Wed, 2012-10-03 at 11:42 +0100, Valtteri Kiviniemi wro= te:
> Hi,
>
> I tried to lower vcpus to 1, and now it produces a different crash: >
> Unable to handle kernel NULL pointer dereference at virtual address > 00000024
> =A0printing eip:
> c0232139
> 005c4000 -> *pde =3D 00000000:00000000
> Oops: 0000 [#1]
> SMP
> CPU: =A0 =A00
> EIP: =A0 =A00061:[<c0232139>] =A0 =A0Not tainted VLI
> EFLAGS: 00010097 =A0 (2.6.16.33-xen-domU-oldgame #1)
> EIP is at blkif_int+0x1dc/0x228

I don't suppose you have source / debug info for this kernel to r= esolve
this into a location?

You say this exact same config works with xend?

If so then, since this appears to relate to the devices, one thing which might be worth trying is to set on_crash =3D "preserve" in your c= onfig and
run under both xend and xl. You can then collect the content of xenstore (xenstore-ls -fp) in both cases (xend booted ok, xl preserved in the
crashed state), and compare.

There will be a bunch of differences relating to the xend one finishing
its boot but something might stand out in the diff. Just posting both
sets of output might be useful.

If you run "xl -vvv create" you should also get a bunch of stuff<= br> relating to the domain builder and where it is placing things. Running
under xend I think something similar is dumped under /var/log/xen
(domain-build-ng.log?)

What does your config file look like?

Ian.



--001636ef09adc44f7f04cb25a56c-- --===============8545444535638952119== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8545444535638952119==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 11:08:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 11:08:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJMnw-0007aX-EW; Wed, 03 Oct 2012 11:07:52 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJMnt-0007aS-Id for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 11:07:50 +0000 Received: from [85.158.138.51:7707] by server-9.bemta-3.messagelabs.com id FF/4A-20338-48C1C605; Wed, 03 Oct 2012 11:07:48 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1349262462!32427600!1 X-Originating-IP: [209.85.161.173] X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG, HTML_10_20, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23471 invoked from network); 3 Oct 2012 11:07:43 -0000 Received: from mail-gg0-f173.google.com (HELO mail-gg0-f173.google.com) (209.85.161.173) by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 11:07:43 -0000 Received: by ggcs5 with SMTP id s5so602080ggc.32 for ; Wed, 03 Oct 2012 04:07:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+dsJkve1dfTDhJhCPHQxEg9dI4wRQ+0U1Uf2Qdc7NEk=; b=TS2VhoXzQLk83UTZyYx8Rb6HVnpWodB1i4yq+Etxu+hnUe0WtlVUMV5r/UkFj9YUwO xOXZEsgBl+f7W09dSolYrFR2jwHRkLJDcPKpAmDjFi0gY5f5zewEXNFNWAM0FmIAVBDn tuv7CXqhKJ03tQTHochy4kJEatE1QghceAoouBgzsXMH0zWr19KBmrIDw4toei18Yelm XbaE1F/XqvZ4LHv5H61YIQ1tUfW9u6JhoPydKiM7h9ld+raR/3T0ikQkOX2cnCXxe0WJ 7gqacO09Vay9GB/GTTCp2Ti8FWET1IbshIb87cXAHYcA0jrC3s02BoC58PhRCpJTE5st aUtg== MIME-Version: 1.0 Received: by 10.101.166.35 with SMTP id t35mr419900ano.63.1349262462176; Wed, 03 Oct 2012 04:07:42 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Wed, 3 Oct 2012 04:07:42 -0700 (PDT) In-Reply-To: <1349261397.650.130.camel@zakaz.uk.xensource.com> References: <1349259542.650.122.camel@zakaz.uk.xensource.com> <1349261397.650.130.camel@zakaz.uk.xensource.com> Date: Wed, 3 Oct 2012 14:07:42 +0300 Message-ID: From: Valtteri Kiviniemi To: Ian Campbell Cc: "Xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Xen 4.2.0, xl toolstack cant launch older domUs X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8545444535638952119==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============8545444535638952119== Content-Type: multipart/alternative; boundary=001636ef09adc44f7f04cb25a56c --001636ef09adc44f7f04cb25a56c Content-Type: text/plain; charset=ISO-8859-1 Hi, I dont have the kernel sources for that 2.6.16.33 any more, this is a very old domU but it still in use since we run some applications there which require old glibc and wont run on newer machines. The domU works perfectly with xend, and has always worked (since xen 3.0.0 every xen upgrade). But now when I decided to move from xend to xl the problems started. Here are the info that you asked, its going to be a long post and hopefully I remembered everything that you asked for: config: kernel = "/boot/vmlinuz-2.6.16.33-xen-domU-oldgame" builder = "linux" memory = "2048" name = "lightning" vcpus = "8" cpus = [ "0", "1", "2", "3", "4", "5", "6", "7" ] vif = [ "mac=00:16:3e:1d:0d:91, bridge=xenbr0" ] disk = [ "phy:/dev/virtuals/lightning,xvda1,w" ] root = "/dev/xvda1 ro" extra = "xencons=tty1 earlyprintk=xen" on_poweroff = "destroy" on_reboot = "restart" on_crash = "preserve" xenstore-ls -fp when started with xend and working: /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2 = "" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/image = "(linux (kernel /boot/bzImage-domU-oldgame) (args 'root=/dev/xvda1 ro console=xvc0 earlyprintk=xen') (superpages 0) (videoram 4) (pci ()) (nomigrate 0) (tsc_mode 0) (notes (HV_START_LOW 411880652\..." (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/image/ostype = "linux" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/image/kernel = "/boot/bzImage-domU-oldgame" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/image/cmdline = "root=/dev/xvda1 ro console=xvc0 earlyprintk=xen" (n0,r11) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/image/ramdisk = "" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device = "" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/vbd = "" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/vbd/51713 = "" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/vbd/51713/frontend = "/local/domain/11/device/vbd/51713" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/vbd/51713/frontend-id = "11" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/vbd/51713/backend-id = "0" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/vbd/51713/backend = "/local/domain/0/backend/vbd/11/51713" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/vif = "" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/vif/0 = "" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/vif/0/frontend = "/local/domain/11/device/vif/0" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/vif/0/frontend-id = "11" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/vif/0/backend-id = "0" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/vif/0/backend = "/local/domain/0/backend/vif/11/0" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/console = "" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/console/0 = "" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/console/0/frontend = "/local/domain/11/device/console/0" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/console/0/frontend-id = "11" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/console/0/backend-id = "0" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/console/0/backend = "/local/domain/0/backend/console/11/0" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/on_xend_stop = "ignore" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/pool_name = "Pool-0" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/shadow_memory = "0" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/uuid = "54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2" (n0,r11) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/on_reboot = "restart" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/start_time = "1349262041.78" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/on_poweroff = "destroy" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/bootloader_args = "" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/on_xend_start = "ignore" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/on_crash = "preserve" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/xend = "" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/xend/restart_count = "0" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/vcpus = "1" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/vcpu_avail = "1" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/bootloader = "" (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/name = "lightning" (n0) xenstore-ls -fp when started with xl and crashed (preserved): /vm = "" (n0) /vm/e2261517-a75b-4c02-b9db-da9c21a05130 = "" (n0,r1) /vm/e2261517-a75b-4c02-b9db-da9c21a05130/uuid = "e2261517-a75b-4c02-b9db-da9c21a05130" (n0,r1) /vm/e2261517-a75b-4c02-b9db-da9c21a05130/name = "lightning" (n0,r1) /vm/e2261517-a75b-4c02-b9db-da9c21a05130/image = "" (n0,r1) /vm/e2261517-a75b-4c02-b9db-da9c21a05130/image/ostype = "linux" (n0,r1) /vm/e2261517-a75b-4c02-b9db-da9c21a05130/image/kernel = "/boot/bzImage-domU-oldgame" (n0,r1) /vm/e2261517-a75b-4c02-b9db-da9c21a05130/image/cmdline = "root=/dev/xvda1 ro console=xvc0 earlyprintk=xen" (n0,r1) /vm/e2261517-a75b-4c02-b9db-da9c21a05130/start_time = "1349262365.43" (n0,r1) /libxl = "" (n0) /libxl/1 = "" (n0) /libxl/1/dm-version = "qemu_xen" (n0) domU starter with xl -vvv create: root@xen-2:~# xl -vvv create /etc/xen/lightning.cfg -c Parsing config from /etc/xen/lightning.cfg libxl: debug: libxl_create.c:1173:do_domain_create: ao 0x6243d0: create: how=(nil) callback=(nil) poller=0x623b80 libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk vdev=xvda1 spec.backend=unknown libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk vdev=xvda1, using backend phy libxl: debug: libxl_create.c:677:initiate_domain_create: running bootloader libxl: debug: libxl_bootloader.c:327:libxl__bootloader_run: no bootloader configured, using user supplied kernel libxl: debug: libxl_event.c:561:libxl__ev_xswatch_deregister: watch w=0x624750: deregister unregistered libxl: debug: libxl_numa.c:435:libxl__get_numa_candidate: New best NUMA placement candidate found: nr_nodes=1, nr_cpus=8, nr_vcpus=9, free_memkb=31043 libxl: detail: libxl_dom.c:192:numa_place_domain: NUMA placement candidate with 1 nodes, 8 cpus and 31043 KB free selected domainbuilder: detail: xc_dom_allocate: cmdline="root=/dev/xvda1 ro console=xvc0 earlyprintk=xen", features="(null)" libxl: debug: libxl_dom.c:380:libxl__build_pv: pv kernel mapped 0 path /boot/bzImage-domU-oldgame domainbuilder: detail: xc_dom_kernel_file: filename="/boot/bzImage-domU-oldgame" domainbuilder: detail: xc_dom_malloc_filemap : 1237 kB domainbuilder: detail: xc_dom_malloc : 2653 kB domainbuilder: detail: xc_dom_do_gunzip: unzip ok, 0x135462 -> 0x297540 domainbuilder: detail: xc_dom_boot_xen_init: ver 4.2, caps xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 domainbuilder: detail: xc_dom_parse_image: called domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary loader ... domainbuilder: detail: loader probe failed domainbuilder: detail: xc_dom_find_loader: trying Linux bzImage loader ... domainbuilder: detail: xc_dom_probe_bzimage_kernel: kernel is not a bzImage domainbuilder: detail: loader probe failed domainbuilder: detail: xc_dom_find_loader: trying ELF-generic loader ... domainbuilder: detail: loader probe OK xc: detail: elf_parse_binary: phdr: paddr=0xc0100000 memsz=0x20d500 xc: detail: elf_parse_binary: phdr: paddr=0xc030d500 memsz=0xb3308 xc: detail: elf_parse_binary: memory: 0xc0100000 -> 0xc03c0808 xc: detail: elf_xen_parse_note: GUEST_OS = "linux" xc: detail: elf_xen_parse_note: GUEST_VERSION = "2.6" xc: detail: elf_xen_parse_note: XEN_VERSION = "xen-3.0" xc: detail: elf_xen_parse_note: VIRT_BASE = 0xc0000000 xc: detail: elf_xen_parse_note: PADDR_OFFSET = 0xc0000000 xc: detail: elf_xen_parse_note: ENTRY = 0xc0100000 xc: detail: elf_xen_parse_note: HYPERCALL_PAGE = 0xc0101000 xc: detail: elf_xen_parse_note: HV_START_LOW = 0xf5800000 xc: detail: elf_xen_parse_note: FEATURES = "writable_page_tables|writable_descriptor_tables|auto_translated_physmap|pae_pgdir_above_4gb|supervisor_mode_kernel" xc: detail: elf_xen_parse_note: PAE_MODE = "yes" xc: detail: elf_xen_parse_note: LOADER = "generic" xc: detail: elf_xen_parse: using notes from SHT_NOTE section xc: detail: elf_xen_addr_calc_check: addresses: xc: detail: virt_base = 0xc0000000 xc: detail: elf_paddr_offset = 0xc0000000 xc: detail: virt_offset = 0x0 xc: detail: virt_kstart = 0xc0100000 xc: detail: virt_kend = 0xc03c0808 xc: detail: virt_entry = 0xc0100000 xc: detail: p2m_base = 0xffffffffffffffff domainbuilder: detail: xc_dom_parse_elf_kernel: xen-3.0-x86_32p: 0xc0100000 -> 0xc03c0808 domainbuilder: detail: xc_dom_mem_init: mem 2048 MB, pages 0x80000 pages, 4k each domainbuilder: detail: xc_dom_mem_init: 0x80000 pages domainbuilder: detail: xc_dom_boot_mem_init: called domainbuilder: detail: x86_compat: guest xen-3.0-x86_32p, address size 32 domainbuilder: detail: xc_dom_malloc : 4096 kB domainbuilder: detail: xc_dom_build_image: called domainbuilder: detail: xc_dom_alloc_segment: kernel : 0xc0100000 -> 0xc03c1000 (pfn 0x100 + 0x2c1 pages) domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x100+0x2c1 at 0x7fcba1b83000 xc: detail: elf_load_binary: phdr 0 at 0x0x7fcba1b83000 -> 0x0x7fcba1d90500 xc: detail: elf_load_binary: phdr 1 at 0x0x7fcba1d90500 -> 0x0x7fcba1e0f93c domainbuilder: detail: xc_dom_alloc_segment: phys2mach : 0xc03c1000 -> 0xc05c1000 (pfn 0x3c1 + 0x200 pages) domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x3c1+0x200 at 0x7fcba1983000 domainbuilder: detail: xc_dom_alloc_page : start info : 0xc05c1000 (pfn 0x5c1) domainbuilder: detail: xc_dom_alloc_page : xenstore : 0xc05c2000 (pfn 0x5c2) domainbuilder: detail: xc_dom_alloc_page : console : 0xc05c3000 (pfn 0x5c3) domainbuilder: detail: nr_page_tables: 0x00000000ffffffff/32: 0x0000000000000000 -> 0x00000000ffffffff, 1 table(s) domainbuilder: detail: nr_page_tables: 0x000000003fffffff/30: 0x00000000c0000000 -> 0x00000000ffffffff, 1 table(s) domainbuilder: detail: nr_page_tables: 0x00000000001fffff/21: 0x00000000c0000000 -> 0x00000000c07fffff, 4 table(s) domainbuilder: detail: xc_dom_alloc_segment: page tables : 0xc05c4000 -> 0xc05ca000 (pfn 0x5c4 + 0x6 pages) domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x5c4+0x6 at 0x7fcba197d000 domainbuilder: detail: xc_dom_alloc_page : boot stack : 0xc05ca000 (pfn 0x5ca) domainbuilder: detail: xc_dom_build_image : virt_alloc_end : 0xc05cb000 domainbuilder: detail: xc_dom_build_image : virt_pgtab_end : 0xc0800000 domainbuilder: detail: xc_dom_boot_image: called domainbuilder: detail: arch_setup_bootearly: doing nothing domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-x86_64 domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-x86_32p <= matches domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_32 domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_32p domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_64 domainbuilder: detail: xc_dom_update_guest_p2m: dst 32bit, pages 0x80000 domainbuilder: detail: clear_page: pfn 0x5c3, mfn 0x649f86 domainbuilder: detail: clear_page: pfn 0x5c2, mfn 0x649f87 domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x5c1+0x1 at 0x7fcba4599000 domainbuilder: detail: start_info_x86_32: called domainbuilder: detail: setup_hypercall_page: vaddr=0xc0101000 pfn=0x101 domainbuilder: detail: domain builder memory footprint domainbuilder: detail: allocated domainbuilder: detail: malloc : 6780 kB domainbuilder: detail: anon mmap : 0 bytes domainbuilder: detail: mapped domainbuilder: detail: file mmap : 1237 kB domainbuilder: detail: domU mmap : 4896 kB domainbuilder: detail: arch_setup_bootlate: shared_info: pfn 0x0, mfn 0xdbdf8 domainbuilder: detail: shared_info_x86_32: called domainbuilder: detail: vcpu_x86_32: called domainbuilder: detail: vcpu_x86_32: cr3: pfn 0x5c4 mfn 0x649f85 domainbuilder: detail: launch_vm: called, ctxt=0x7fff96435b40 domainbuilder: detail: xc_dom_release: called libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk vdev=xvda1 spec.backend=phy libxl: debug: libxl_event.c:512:libxl__ev_xswatch_register: watch w=0x625598 wpath=/local/domain/0/backend/vbd/2/51713/state token=3/0: register slotnum=3 libxl: debug: libxl_create.c:1186:do_domain_create: ao 0x6243d0: inprogress: poller=0x623b80, flags=i libxl: debug: libxl_event.c:457:watchfd_callback: watch w=0x625598 wpath=/local/domain/0/backend/vbd/2/51713/state token=3/0: event epath=/local/domain/0/backend/vbd/2/51713/state libxl: debug: libxl_event.c:596:devstate_watch_callback: backend /local/domain/0/backend/vbd/2/51713/state wanted state 2 ok libxl: debug: libxl_event.c:549:libxl__ev_xswatch_deregister: watch w=0x625598 wpath=/local/domain/0/backend/vbd/2/51713/state token=3/0: deregister slotnum=3 libxl: debug: libxl_event.c:561:libxl__ev_xswatch_deregister: watch w=0x625598: deregister unregistered libxl: debug: libxl_device.c:916:device_hotplug: calling hotplug script: /etc/xen/scripts/block add libxl: debug: libxl_event.c:426:watchfd_callback: watch epath=/local/domain/0/backend/vbd/2/51713/state token=3/0: empty slot libxl: debug: libxl_event.c:512:libxl__ev_xswatch_register: watch w=0x626f38 wpath=/local/domain/0/backend/vif/2/0/state token=3/1: register slotnum=3 libxl: debug: libxl_event.c:457:watchfd_callback: watch w=0x626f38 wpath=/local/domain/0/backend/vif/2/0/state token=3/1: event epath=/local/domain/0/backend/vif/2/0/state libxl: debug: libxl_event.c:596:devstate_watch_callback: backend /local/domain/0/backend/vif/2/0/state wanted state 2 ok libxl: debug: libxl_event.c:549:libxl__ev_xswatch_deregister: watch w=0x626f38 wpath=/local/domain/0/backend/vif/2/0/state token=3/1: deregister slotnum=3 libxl: debug: libxl_event.c:561:libxl__ev_xswatch_deregister: watch w=0x626f38: deregister unregistered libxl: debug: libxl_device.c:916:device_hotplug: calling hotplug script: /etc/xen/scripts/vif-bridge online libxl: debug: libxl_event.c:1677:libxl__ao_progress_report: ao 0x6243d0: progress report: callback queued aop=0x627700 libxl: debug: libxl_event.c:1497:libxl__ao_complete: ao 0x6243d0: complete, rc=0 libxl: debug: libxl_event.c:1090:egc_run_callbacks: ao 0x6243d0: progress report: callback aop=0x627700 libxl: debug: libxl_event.c:1469:libxl__ao__destroy: ao 0x6243d0: destroy Daemon running with PID 4881 Linux version 2.6.16.33-xen-domU-oldgame (root@lightning) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Fri Sep 28 14:56:14 EEST 2012 BIOS-provided physical RAM map: Xen: 0000000000000000 - 0000000080000000 (usable) 1320MB HIGHMEM available. 727MB LOWMEM available. NX (Execute Disable) protection: active early console enabled Built 1 zonelists Kernel command line: root=/dev/xvda1 ro console=xvc0 earlyprintk=xen Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 PID hash table entries: 4096 (order: 12, 65536 bytes) Xen reported: 3392.372 MHz processor. disabling early console Console: colour dummy device 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Software IO TLB disabled vmalloc area: ee000000-f51fe000, maxmem 2d7fe000 Memory: 2072132k/2097152k available (1917k kernel code, 23952k reserved, 537k data, 148k init, 1351688k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 6820.46 BogoMIPS (lpj=3410231) Mount-cache hash table entries: 512 CPU: L1 I cache: 32K, L1 D cache: 32K CPU: L2 cache: 256K CPU: L3 cache: 8192K Checking 'hlt' instruction... OK. Brought up 1 CPUs migration_cost=0 Grant table initialized NET: Registered protocol family 16 xen_mem: Initialising balloon driver. SCSI subsystem initialized highmem bounce pool size: 64 pages Installing knfsd (copyright (C) 1996 okir@monad.swb.de). Initializing Cryptographic API io scheduler noop registered io scheduler cfq registered (default) rtc: IRQ 8 is not free. i8042.c: No controller found. loop: loaded (max 8 devices) Xen virtual console successfully installed as tty1 Event-channel device installed. netfront: Initialising virtual ethernet driver. mice: PS/2 mouse device common for all mice Netfilter messages via NETLINK v0.30. NET: Registered protocol family 2 netfront: device eth0 has copying receive path. Registering block device major 202 blkfront: xvda1: barriers enabled IP route cache hash table entries: 32768 (order: 5, 131072 bytes) TCP established hash table entries: 131072 (order: 8, 1048576 bytes) TCP bind hash table entries: 65536 (order: 7, 524288 bytes) TCP: Hash tables configured (established 131072 bind 65536) TCP reno registered ip_conntrack version 2.4 (8192 buckets, 65536 max) - 232 bytes per conntrack ip_conntrack_pptp version 3.1 loaded ip_nat_pptp version 3.0 loaded ip_tables: (C) 2000-2006 Netfilter Core Team ipt_recent v0.3.1: Stephen Frost . http://snowman.net/projects/ipt_recent/ TCP bic registered NET: Registered protocol family 1 NET: Registered protocol family 17 NET: Registered protocol family 15 Bridge firewalling registered 802.1Q VLAN Support v1.8 Ben Greear All bugs added by David S. Miller Using IPI Shortcut mode end_request: I/O error, dev xvda1, sector 2 EXT3-fs: unable to read superblock Unable to handle kernel NULL pointer dereference at virtual address 00000024 printing eip: c0232139 005c4000 -> *pde = 00000000:00000000 Oops: 0000 [#1] SMP CPU: 0 EIP: 0061:[] Not tainted VLI EFLAGS: 00010097 (2.6.16.33-xen-domU-oldgame #1) EIP is at blkif_int+0x1dc/0x228 eax: 00000000 ebx: 00000001 ecx: c090e000 edx: 00000000 esi: d92d7c7c edi: ca010100 ebp: ed6ea0ac esp: c0367ec0 ds: 007b es: 007b ss: e021 Process swapper (pid: 0, threadinfo=c0366000 task=c030d7c0) Stack: <0>c200ce24 109c6373 00000000 00000000 00000001 00000002 00000000 00000001 ed6ab7a0 00000000 00000000 c0367f6c c0133197 00000105 c090e000 c0367f6c 00000105 00008280 c035b680 00000105 ed6ab7a0 c013328f 00000105 0000000a Call Trace: [] handle_IRQ_event+0x38/0xa9 [] __do_IRQ+0x87/0xf8 [] do_IRQ+0x1a/0x25 [] evtchn_do_upcall+0x95/0xa9 [] hypervisor_callback+0x3d/0x48 [] safe_halt+0x7a/0xb2 [] xen_idle+0x2b/0x4e [] cpu_idle+0x52/0x67 [] start_kernel+0x2b8/0x33c [] unknown_bootoption+0x0/0x27a Code: c7 04 24 e0 17 30 c0 e8 39 8b ee ff 8b 44 24 38 c7 80 00 14 00 00 00 00 00 00 89 04 24 e8 75 03 00 00 bb a1 ff ff ff 8b 54 24 0c <8b> 42 24 89 44 24 08 89 5c 24 04 89 14 24 e8 3b eb fb ff 85 c0 <0>Kernel panic - not syncing: Fatal exception in interrupt And finally the domain-builder-ng.log when started with xend and working: 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_allocate: cmdline="root=/dev/xvda1 ro console=xvc0 earlyprintk=xen", features="" 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_kernel_file: filename="/boot/bzImage-domU-oldgame" 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_malloc_filemap : 1237 kB 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_malloc : 2653 kB 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_do_gunzip: unzip ok, 0x135462 -> 0x297540 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_parse_image: called 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary loader ... 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: loader probe failed 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_find_loader: trying Linux bzImage loader ... 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_probe_bzimage_kernel: kernel is not a bzImage 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: loader probe failed 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_find_loader: trying ELF-generic loader ... 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: loader probe OK 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_parse_binary: phdr: paddr=0xc0100000 memsz=0x20d500 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_parse_binary: phdr: paddr=0xc030d500 memsz=0xb3308 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_parse_binary: memory: 0xc0100000 -> 0xc03c0808 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: GUEST_OS = "linux" 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: GUEST_VERSION = "2.6" 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: XEN_VERSION = "xen-3.0" 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: VIRT_BASE = 0xc0000000 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: PADDR_OFFSET = 0xc0000000 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: ENTRY = 0xc0100000 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: HYPERCALL_PAGE = 0xc0101000 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: HV_START_LOW = 0xf5800000 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: FEATURES = "writable_page_tables|writable_descriptor_tables|auto_translated_physmap|pae_pgdir_above_4gb|supervisor_mode_kernel" 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: PAE_MODE = "yes" 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: LOADER = "generic" 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse: using notes from SHT_NOTE section 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_addr_calc_check: addresses: 2012-10-03 14:00:41 EEST [3773] xc: detail: virt_base = 0xc0000000 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_paddr_offset = 0xc0000000 2012-10-03 14:00:41 EEST [3773] xc: detail: virt_offset = 0x0 2012-10-03 14:00:41 EEST [3773] xc: detail: virt_kstart = 0xc0100000 2012-10-03 14:00:41 EEST [3773] xc: detail: virt_kend = 0xc03c0808 2012-10-03 14:00:41 EEST [3773] xc: detail: virt_entry = 0xc0100000 2012-10-03 14:00:41 EEST [3773] xc: detail: p2m_base = 0xffffffffffffffff 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_parse_elf_kernel: xen-3.0-x86_32p: 0xc0100000 -> 0xc03c0808 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_release: called 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_allocate: cmdline="root=/dev/xvda1 ro console=xvc0 earlyprintk=xen", features="" 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_kernel_file: filename="/boot/bzImage-domU-oldgame" 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_malloc_filemap : 1237 kB 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_malloc : 2653 kB 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_do_gunzip: unzip ok, 0x135462 -> 0x297540 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_boot_xen_init: ver 4.2, caps xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_parse_image: called 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary loader ... 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: loader probe failed 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_find_loader: trying Linux bzImage loader ... 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_probe_bzimage_kernel: kernel is not a bzImage 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: loader probe failed 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_find_loader: trying ELF-generic loader ... 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: loader probe OK 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_parse_binary: phdr: paddr=0xc0100000 memsz=0x20d500 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_parse_binary: phdr: paddr=0xc030d500 memsz=0xb3308 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_parse_binary: memory: 0xc0100000 -> 0xc03c0808 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: GUEST_OS = "linux" 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: GUEST_VERSION = "2.6" 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: XEN_VERSION = "xen-3.0" 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: VIRT_BASE = 0xc0000000 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: PADDR_OFFSET = 0xc0000000 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: ENTRY = 0xc0100000 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: HYPERCALL_PAGE = 0xc0101000 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: HV_START_LOW = 0xf5800000 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: FEATURES = "writable_page_tables|writable_descriptor_tables|auto_translated_physmap|pae_pgdir_above_4gb|supervisor_mode_kernel" 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: PAE_MODE = "yes" 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: LOADER = "generic" 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse: using notes from SHT_NOTE section 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_addr_calc_check: addresses: 2012-10-03 14:00:41 EEST [3773] xc: detail: virt_base = 0xc0000000 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_paddr_offset = 0xc0000000 2012-10-03 14:00:41 EEST [3773] xc: detail: virt_offset = 0x0 2012-10-03 14:00:41 EEST [3773] xc: detail: virt_kstart = 0xc0100000 2012-10-03 14:00:41 EEST [3773] xc: detail: virt_kend = 0xc03c0808 2012-10-03 14:00:41 EEST [3773] xc: detail: virt_entry = 0xc0100000 2012-10-03 14:00:41 EEST [3773] xc: detail: p2m_base = 0xffffffffffffffff 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_parse_elf_kernel: xen-3.0-x86_32p: 0xc0100000 -> 0xc03c0808 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_mem_init: mem 2048 MB, pages 0x80000 pages, 4k each 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_mem_init: 0x80000 pages 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_boot_mem_init: called 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: x86_compat: guest xen-3.0-x86_32p, address size 32 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_malloc : 4096 kB 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_build_image: called 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_alloc_segment: kernel : 0xc0100000 -> 0xc03c1000 (pfn 0x100 + 0x2c1 pages) 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x100+0x2c1 at 0x7fdebe53c000 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_load_binary: phdr 0 at 0x0x7fdebe53c000 -> 0x0x7fdebe749500 2012-10-03 14:00:41 EEST [3773] xc: detail: elf_load_binary: phdr 1 at 0x0x7fdebe749500 -> 0x0x7fdebe7c893c 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_alloc_segment: phys2mach : 0xc03c1000 -> 0xc05c1000 (pfn 0x3c1 + 0x200 pages) 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x3c1+0x200 at 0x7fdebe33c000 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_alloc_page : start info : 0xc05c1000 (pfn 0x5c1) 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_alloc_page : xenstore : 0xc05c2000 (pfn 0x5c2) 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_alloc_page : console : 0xc05c3000 (pfn 0x5c3) 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: nr_page_tables: 0x00000000ffffffff/32: 0x0000000000000000 -> 0x00000000ffffffff, 1 table(s) 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: nr_page_tables: 0x000000003fffffff/30: 0x00000000c0000000 -> 0x00000000ffffffff, 1 table(s) 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: nr_page_tables: 0x00000000001fffff/21: 0x00000000c0000000 -> 0x00000000c07fffff, 4 table(s) 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_alloc_segment: page tables : 0xc05c4000 -> 0xc05ca000 (pfn 0x5c4 + 0x6 pages) 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x5c4+0x6 at 0x7fdeca12d000 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_alloc_page : boot stack : 0xc05ca000 (pfn 0x5ca) 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_build_image : virt_alloc_end : 0xc05cb000 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_build_image : virt_pgtab_end : 0xc0800000 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_boot_image: called 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: arch_setup_bootearly: doing nothing 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-x86_64 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-x86_32p <= matches 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_32 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_32p 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_64 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_update_guest_p2m: dst 32bit, pages 0x80000 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: clear_page: pfn 0x5c3, mfn 0x697ee5 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: clear_page: pfn 0x5c2, mfn 0x697ee6 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x5c1+0x1 at 0x7fdeca12a000 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: start_info_x86_32: called 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: setup_hypercall_page: vaddr=0xc0101000 pfn=0x101 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: domain builder memory footprint 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: allocated 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: malloc : 6780 kB 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: anon mmap : 0 bytes 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: mapped 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: file mmap : 1237 kB 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: domU mmap : 4896 kB 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: arch_setup_bootlate: shared_info: pfn 0x0, mfn 0xdbdf8 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: shared_info_x86_32: called 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: vcpu_x86_32: called 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: vcpu_x86_32: cr3: pfn 0x5c4 mfn 0x697ee4 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: launch_vm: called, ctxt=0x7fdebf7fa650 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_release: called - Valtteri 2012/10/3 Ian Campbell > On Wed, 2012-10-03 at 11:42 +0100, Valtteri Kiviniemi wrote: > > Hi, > > > > I tried to lower vcpus to 1, and now it produces a different crash: > > > > Unable to handle kernel NULL pointer dereference at virtual address > > 00000024 > > printing eip: > > c0232139 > > 005c4000 -> *pde = 00000000:00000000 > > Oops: 0000 [#1] > > SMP > > CPU: 0 > > EIP: 0061:[] Not tainted VLI > > EFLAGS: 00010097 (2.6.16.33-xen-domU-oldgame #1) > > EIP is at blkif_int+0x1dc/0x228 > > I don't suppose you have source / debug info for this kernel to resolve > this into a location? > > You say this exact same config works with xend? > > If so then, since this appears to relate to the devices, one thing which > might be worth trying is to set on_crash = "preserve" in your config and > run under both xend and xl. You can then collect the content of xenstore > (xenstore-ls -fp) in both cases (xend booted ok, xl preserved in the > crashed state), and compare. > > There will be a bunch of differences relating to the xend one finishing > its boot but something might stand out in the diff. Just posting both > sets of output might be useful. > > If you run "xl -vvv create" you should also get a bunch of stuff > relating to the domain builder and where it is placing things. Running > under xend I think something similar is dumped under /var/log/xen > (domain-build-ng.log?) > > What does your config file look like? > > Ian. > > > --001636ef09adc44f7f04cb25a56c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I dont have the kernel sources for that 2.6.16.33 any more, this= is a very old domU but it still in use since we run some applications ther= e which require old glibc and wont run on newer machines. The domU works pe= rfectly with xend, and has always worked (since xen 3.0.0 every xen upgrade= ). But now when I decided to move from xend to xl the problems started. Her= e are the info that you asked, its going to be a long post and hopefully I = remembered everything that you asked for:

config:

kernel =3D "/boot/vmlinuz-2.6.16.33-xen-domU-oldgam= e"
builder =3D "linux"
memory =3D "2048"
= name =3D "lightning"
vcpus =3D "8"
cpus =3D [ &qu= ot;0", "1", "2", "3", "4", &qu= ot;5", "6", "7" ]
vif =3D [ "mac=3D00:16:3e:1d:0d:91, bridge=3Dxenbr0" ]
disk = =3D [ "phy:/dev/virtuals/lightning,xvda1,w" ]
root =3D "/= dev/xvda1 ro"
extra =3D "xencons=3Dtty1 earlyprintk=3Dxen"= ;
on_poweroff =3D "destroy"
on_reboot =3D "restart"
on_crash =3D "preserve"
<= br>xenstore-ls -fp when started with xend and working:

/vm/54fd0bf5-= 0cc8-802a-880e-f5f9dc0e4ec2 =3D ""=A0=A0 (n0)
/vm/54fd0bf5-0cc= 8-802a-880e-f5f9dc0e4ec2/image =3D "(linux (kernel /boot/bzImage-domU-= oldgame) (args 'root=3D/dev/xvda1 ro console=3Dxvc0 earlyprintk=3Dxen&#= 39;) (superpages 0) (videoram 4) (pci ()) (nomigrate 0) (tsc_mode 0) (notes= (HV_START_LOW 411880652\..."=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/image/ostype =3D "linux"= =A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/image/kernel =3D &q= uot;/boot/bzImage-domU-oldgame"=A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-8= 80e-f5f9dc0e4ec2/image/cmdline =3D "root=3D/dev/xvda1 ro console=3Dxvc= 0 earlyprintk=3Dxen"=A0=A0 (n0,r11)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/image/ramdisk =3D ""=A0= =A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device =3D ""= ;=A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/vbd =3D &qu= ot;"=A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/vbd/51713 =3D ""= =A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/vbd/51713/fr= ontend =3D "/local/domain/11/device/vbd/51713"=A0=A0 (n0)
/vm/= 54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/vbd/51713/frontend-id =3D "= ;11"=A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/vbd/51713/backend-id =3D &q= uot;0"=A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/v= bd/51713/backend =3D "/local/domain/0/backend/vbd/11/51713"=A0=A0= (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/vif =3D ""=A0=A0 = (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/vif/0 =3D "&qu= ot;=A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/vif/0/fro= ntend =3D "/local/domain/11/device/vif/0"=A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/vif/0/frontend-id =3D "= ;11"=A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/vif= /0/backend-id =3D "0"=A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f= 5f9dc0e4ec2/device/vif/0/backend =3D "/local/domain/0/backend/vif/11/0= "=A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/console =3D ""=A0= =A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/console/0 =3D &= quot;"=A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/c= onsole/0/frontend =3D "/local/domain/11/device/console/0"=A0=A0 (= n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device/console/0/frontend-id =3D &= quot;11"=A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/device= /console/0/backend-id =3D "0"=A0=A0 (n0)
/vm/54fd0bf5-0cc8-802= a-880e-f5f9dc0e4ec2/device/console/0/backend =3D "/local/domain/0/back= end/console/11/0"=A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/on_xend_stop =3D "ignore"= ;=A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/pool_name =3D &quo= t;Pool-0"=A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/shado= w_memory =3D "0"=A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/uuid =3D "54fd0bf5-0cc8-802a-= 880e-f5f9dc0e4ec2"=A0=A0 (n0,r11)
/vm/54fd0bf5-0cc8-802a-880e-f5f9d= c0e4ec2/on_reboot =3D "restart"=A0=A0 (n0)
/vm/54fd0bf5-0cc8-8= 02a-880e-f5f9dc0e4ec2/start_time =3D "1349262041.78"=A0=A0 (n0) /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/on_poweroff =3D "destroy"= ;=A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/bootloader_args = =3D ""=A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/on_= xend_start =3D "ignore"=A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/on_crash =3D "preserve"= =A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/xend =3D "&quo= t;=A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/xend/restart_coun= t =3D "0"=A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/vcpus =3D "1"=A0=A0 (n0)=
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/vcpu_avail =3D "1"= =A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/bootloader =3D &quo= t;"=A0=A0 (n0)
/vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2/name =3D "lightning"=A0= =A0 (n0)

xenstore-ls -fp when started with xl and crashed (preserved= ):

/vm =3D ""=A0=A0 (n0)
/vm/e2261517-a75b-4c02-b9db-da= 9c21a05130 =3D ""=A0=A0 (n0,r1)
/vm/e2261517-a75b-4c02-b9db-da9c21a05130/uuid =3D "e2261517-a75b-4c02-= b9db-da9c21a05130"=A0=A0 (n0,r1)
/vm/e2261517-a75b-4c02-b9db-da9c21= a05130/name =3D "lightning"=A0=A0 (n0,r1)
/vm/e2261517-a75b-4c= 02-b9db-da9c21a05130/image =3D ""=A0=A0 (n0,r1)
/vm/e2261517-a75b-4c02-b9db-da9c21a05130/image/ostype =3D "linux"= =A0=A0 (n0,r1)
/vm/e2261517-a75b-4c02-b9db-da9c21a05130/image/kernel =3D= "/boot/bzImage-domU-oldgame"=A0=A0 (n0,r1)
/vm/e2261517-a75b-= 4c02-b9db-da9c21a05130/image/cmdline =3D "root=3D/dev/xvda1 ro console= =3Dxvc0 earlyprintk=3Dxen"=A0=A0 (n0,r1)
/vm/e2261517-a75b-4c02-b9db-da9c21a05130/start_time =3D "1349262365.43= "=A0=A0 (n0,r1)
/libxl =3D ""=A0=A0 (n0)
/libxl/1 =3D = ""=A0=A0 (n0)
/libxl/1/dm-version =3D "qemu_xen"=A0= =A0 (n0)

domU starter with xl -vvv create:

root@xen-2:~# xl -vvv create /etc/xen/lightning.cfg -c
Parsing confi= g from /etc/xen/lightning.cfg
libxl: debug: libxl_create.c:1173:do_domai= n_create: ao 0x6243d0: create: how=3D(nil) callback=3D(nil) poller=3D0x623b= 80
libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk vdev= =3Dxvda1 spec.backend=3Dunknown
libxl: debug: libxl_device.c:265:libxl__= device_disk_set_backend: Disk vdev=3Dxvda1, using backend phy
libxl: deb= ug: libxl_create.c:677:initiate_domain_create: running bootloader
libxl: debug: libxl_bootloader.c:327:libxl__bootloader_run: no bootloader c= onfigured, using user supplied kernel
libxl: debug: libxl_event.c:561:li= bxl__ev_xswatch_deregister: watch w=3D0x624750: deregister unregistered
libxl: debug: libxl_numa.c:435:libxl__get_numa_candidate: New best NUMA pla= cement candidate found: nr_nodes=3D1, nr_cpus=3D8, nr_vcpus=3D9, free_memkb= =3D31043
libxl: detail: libxl_dom.c:192:numa_place_domain: NUMA placemen= t candidate with 1 nodes, 8 cpus and 31043 KB free selected
domainbuilder: detail: xc_dom_allocate: cmdline=3D"root=3D/dev/xvda1 r= o console=3Dxvc0 earlyprintk=3Dxen", features=3D"(null)"
= libxl: debug: libxl_dom.c:380:libxl__build_pv: pv kernel mapped 0 path /boo= t/bzImage-domU-oldgame

domainbuilder: detail: xc_dom_kernel_file: filename=3D"/boot/bzIma= ge-domU-oldgame"
domainbuilder: detail: xc_dom_malloc_filemap=A0=A0= =A0 : 1237 kB
domainbuilder: detail: xc_dom_malloc=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 : 2653 kB
domainbuilder: detail: xc_dom_do_gunzip: unzip ok= , 0x135462 -> 0x297540
domainbuilder: detail: xc_dom_boot_xen_init: ver 4.2, caps xen-3.0-x86_64 x= en-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64
domainbuild= er: detail: xc_dom_parse_image: called
domainbuilder: detail: xc_dom_fin= d_loader: trying multiboot-binary loader ...
domainbuilder: detail: loader probe failed
domainbuilder: detail: xc_dom= _find_loader: trying Linux bzImage loader ...
domainbuilder: detail: xc_= dom_probe_bzimage_kernel: kernel is not a bzImage
domainbuilder: detail:= loader probe failed
domainbuilder: detail: xc_dom_find_loader: trying ELF-generic loader ...domainbuilder: detail: loader probe OK
xc: detail: elf_parse_binary: ph= dr: paddr=3D0xc0100000 memsz=3D0x20d500
xc: detail: elf_parse_binary: ph= dr: paddr=3D0xc030d500 memsz=3D0xb3308
xc: detail: elf_parse_binary: memory: 0xc0100000 -> 0xc03c0808
xc: de= tail: elf_xen_parse_note: GUEST_OS =3D "linux"
xc: detail: elf= _xen_parse_note: GUEST_VERSION =3D "2.6"
xc: detail: elf_xen_p= arse_note: XEN_VERSION =3D "xen-3.0"
xc: detail: elf_xen_parse_note: VIRT_BASE =3D 0xc0000000
xc: detail: elf= _xen_parse_note: PADDR_OFFSET =3D 0xc0000000
xc: detail: elf_xen_parse_n= ote: ENTRY =3D 0xc0100000
xc: detail: elf_xen_parse_note: HYPERCALL_PAGE= =3D 0xc0101000
xc: detail: elf_xen_parse_note: HV_START_LOW =3D 0xf5800000
xc: detail: = elf_xen_parse_note: FEATURES =3D "writable_page_tables|writable_descri= ptor_tables|auto_translated_physmap|pae_pgdir_above_4gb|supervisor_mode_ker= nel"
xc: detail: elf_xen_parse_note: PAE_MODE =3D "yes"
xc: detail:= elf_xen_parse_note: LOADER =3D "generic"
xc: detail: elf_xen_= parse: using notes from SHT_NOTE section
xc: detail: elf_xen_addr_calc_c= heck: addresses:
xc: detail:=A0=A0=A0=A0 virt_base=A0=A0=A0=A0=A0=A0=A0 =3D 0xc0000000
xc= : detail:=A0=A0=A0=A0 elf_paddr_offset =3D 0xc0000000
xc: detail:=A0=A0= =A0=A0 virt_offset=A0=A0=A0=A0=A0 =3D 0x0
xc: detail:=A0=A0=A0=A0 virt_k= start=A0=A0=A0=A0=A0 =3D 0xc0100000
xc: detail:=A0=A0=A0=A0 virt_kend=A0= =A0=A0=A0=A0=A0=A0 =3D 0xc03c0808
xc: detail:=A0=A0=A0=A0 virt_entry=A0=A0=A0=A0=A0=A0 =3D 0xc0100000
xc: = detail:=A0=A0=A0=A0 p2m_base=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0xffffffffffffffff=
domainbuilder: detail: xc_dom_parse_elf_kernel: xen-3.0-x86_32p: 0xc010= 0000 -> 0xc03c0808
domainbuilder: detail: xc_dom_mem_init: mem 2048 M= B, pages 0x80000 pages, 4k each
domainbuilder: detail: xc_dom_mem_init: 0x80000 pages
domainbuilder: det= ail: xc_dom_boot_mem_init: called
domainbuilder: detail: x86_compat: gue= st xen-3.0-x86_32p, address size 32
domainbuilder: detail: xc_dom_malloc= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 4096 kB
domainbuilder: detail: xc_dom_build_image: called
domainbuilder: detail:= xc_dom_alloc_segment:=A0=A0 kernel=A0=A0=A0=A0=A0=A0 : 0xc0100000 -> 0x= c03c1000=A0 (pfn 0x100 + 0x2c1 pages)
domainbuilder: detail: xc_dom_pfn_= to_ptr: domU mapping: pfn 0x100+0x2c1 at 0x7fcba1b83000
xc: detail: elf_load_binary: phdr 0 at 0x0x7fcba1b83000 -> 0x0x7fcba1d90= 500
xc: detail: elf_load_binary: phdr 1 at 0x0x7fcba1d90500 -> 0x0x7f= cba1e0f93c
domainbuilder: detail: xc_dom_alloc_segment:=A0=A0 phys2mach= =A0=A0=A0 : 0xc03c1000 -> 0xc05c1000=A0 (pfn 0x3c1 + 0x200 pages)
domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x3c1+0x200 at = 0x7fcba1983000
domainbuilder: detail: xc_dom_alloc_page=A0=A0 :=A0=A0 st= art info=A0=A0 : 0xc05c1000 (pfn 0x5c1)
domainbuilder: detail: xc_dom_al= loc_page=A0=A0 :=A0=A0 xenstore=A0=A0=A0=A0 : 0xc05c2000 (pfn 0x5c2)
domainbuilder: detail: xc_dom_alloc_page=A0=A0 :=A0=A0 console=A0=A0=A0=A0= =A0 : 0xc05c3000 (pfn 0x5c3)
domainbuilder: detail: nr_page_tables: 0x00= 000000ffffffff/32: 0x0000000000000000 -> 0x00000000ffffffff, 1 table(s)<= br>domainbuilder: detail: nr_page_tables: 0x000000003fffffff/30: 0x00000000= c0000000 -> 0x00000000ffffffff, 1 table(s)
domainbuilder: detail: nr_page_tables: 0x00000000001fffff/21: 0x00000000c00= 00000 -> 0x00000000c07fffff, 4 table(s)
domainbuilder: detail: xc_dom= _alloc_segment:=A0=A0 page tables=A0 : 0xc05c4000 -> 0xc05ca000=A0 (pfn = 0x5c4 + 0x6 pages)
domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x5c4+0x6 at 0x= 7fcba197d000
domainbuilder: detail: xc_dom_alloc_page=A0=A0 :=A0=A0 boot= stack=A0=A0 : 0xc05ca000 (pfn 0x5ca)
domainbuilder: detail: xc_dom_buil= d_image=A0 : virt_alloc_end : 0xc05cb000
domainbuilder: detail: xc_dom_build_image=A0 : virt_pgtab_end : 0xc0800000<= br>domainbuilder: detail: xc_dom_boot_image: called
domainbuilder: detai= l: arch_setup_bootearly: doing nothing
domainbuilder: detail: xc_dom_com= pat_check: supported guest type: xen-3.0-x86_64
domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-x= 86_32p <=3D matches
domainbuilder: detail: xc_dom_compat_check: suppo= rted guest type: hvm-3.0-x86_32
domainbuilder: detail: xc_dom_compat_che= ck: supported guest type: hvm-3.0-x86_32p
domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x= 86_64
domainbuilder: detail: xc_dom_update_guest_p2m: dst 32bit, pages 0= x80000
domainbuilder: detail: clear_page: pfn 0x5c3, mfn 0x649f86
domainbuilder: detail: clear_page: pfn 0x5c2, mfn 0x649f87
domainbuilder= : detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x5c1+0x1 at 0x7fcba4599000<= br>domainbuilder: detail: start_info_x86_32: called
domainbuilder: detai= l: setup_hypercall_page: vaddr=3D0xc0101000 pfn=3D0x101
domainbuilder: detail: domain builder memory footprint
domainbuilder: de= tail:=A0=A0=A0 allocated
domainbuilder: detail:=A0=A0=A0=A0=A0=A0 malloc= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 6780 kB
domainbuilder: detail:=A0= =A0=A0=A0=A0=A0 anon mmap=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 0 bytes
domainbui= lder: detail:=A0=A0=A0 mapped
domainbuilder: detail:=A0=A0=A0=A0=A0=A0 file mmap=A0=A0=A0=A0=A0=A0=A0=A0= =A0 : 1237 kB
domainbuilder: detail:=A0=A0=A0=A0=A0=A0 domU mmap=A0=A0= =A0=A0=A0=A0=A0=A0=A0 : 4896 kB
domainbuilder: detail: arch_setup_bootla= te: shared_info: pfn 0x0, mfn 0xdbdf8
domainbuilder: detail: shared_info= _x86_32: called
domainbuilder: detail: vcpu_x86_32: called
domainbuilder: detail: vcpu_x= 86_32: cr3: pfn 0x5c4 mfn 0x649f85
domainbuilder: detail: launch_vm: cal= led, ctxt=3D0x7fff96435b40
domainbuilder: detail: xc_dom_release: called=
libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk vdev= =3Dxvda1 spec.backend=3Dphy
libxl: debug: libxl_event.c:512:libxl__ev_xs= watch_register: watch w=3D0x625598 wpath=3D/local/domain/0/backend/vbd/2/51= 713/state token=3D3/0: register slotnum=3D3
libxl: debug: libxl_create.c:1186:do_domain_create: ao 0x6243d0: inprogress= : poller=3D0x623b80, flags=3Di
libxl: debug: libxl_event.c:457:watchfd_c= allback: watch w=3D0x625598 wpath=3D/local/domain/0/backend/vbd/2/51713/sta= te token=3D3/0: event epath=3D/local/domain/0/backend/vbd/2/51713/state
libxl: debug: libxl_event.c:596:devstate_watch_callback: backend /local/dom= ain/0/backend/vbd/2/51713/state wanted state 2 ok
libxl: debug: libxl_ev= ent.c:549:libxl__ev_xswatch_deregister: watch w=3D0x625598 wpath=3D/local/d= omain/0/backend/vbd/2/51713/state token=3D3/0: deregister slotnum=3D3
libxl: debug: libxl_event.c:561:libxl__ev_xswatch_deregister: watch w=3D0x6= 25598: deregister unregistered
libxl: debug: libxl_device.c:916:device_h= otplug: calling hotplug script: /etc/xen/scripts/block add
libxl: debug:= libxl_event.c:426:watchfd_callback: watch epath=3D/local/domain/0/backend/= vbd/2/51713/state token=3D3/0: empty slot
libxl: debug: libxl_event.c:512:libxl__ev_xswatch_register: watch w=3D0x626= f38 wpath=3D/local/domain/0/backend/vif/2/0/state token=3D3/1: register slo= tnum=3D3
libxl: debug: libxl_event.c:457:watchfd_callback: watch w=3D0x6= 26f38 wpath=3D/local/domain/0/backend/vif/2/0/state token=3D3/1: event epat= h=3D/local/domain/0/backend/vif/2/0/state
libxl: debug: libxl_event.c:596:devstate_watch_callback: backend /local/dom= ain/0/backend/vif/2/0/state wanted state 2 ok
libxl: debug: libxl_event.= c:549:libxl__ev_xswatch_deregister: watch w=3D0x626f38 wpath=3D/local/domai= n/0/backend/vif/2/0/state token=3D3/1: deregister slotnum=3D3
libxl: debug: libxl_event.c:561:libxl__ev_xswatch_deregister: watch w=3D0x6= 26f38: deregister unregistered
libxl: debug: libxl_device.c:916:device_h= otplug: calling hotplug script: /etc/xen/scripts/vif-bridge online
libxl= : debug: libxl_event.c:1677:libxl__ao_progress_report: ao 0x6243d0: progres= s report: callback queued aop=3D0x627700
libxl: debug: libxl_event.c:1497:libxl__ao_complete: ao 0x6243d0: complete,= rc=3D0
libxl: debug: libxl_event.c:1090:egc_run_callbacks: ao 0x6243d0:= progress report: callback aop=3D0x627700
libxl: debug: libxl_event.c:14= 69:libxl__ao__destroy: ao 0x6243d0: destroy
Daemon running with PID 4881
Linux version 2.6.16.33-xen-domU-oldgame (r= oot@lightning) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) = #1 SMP Fri Sep 28 14:56:14 EEST 2012
BIOS-provided physical RAM map:
=A0Xen: 0000000000000000 - 0000000080000000 (usable)
1320MB HIGHMEM avai= lable.
727MB LOWMEM available.
NX (Execute Disable) protection: activ= e
early console enabled
Built 1 zonelists
Kernel command line: roo= t=3D/dev/xvda1 ro console=3Dxvc0 earlyprintk=3Dxen
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU e= xception support... done.
Initializing CPU#0
PID hash table entries: = 4096 (order: 12, 65536 bytes)
Xen reported: 3392.372 MHz processor.
disabling early console
Console: colour dummy device 80x25
Dentry cac= he hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash = table entries: 65536 (order: 6, 262144 bytes)
Software IO TLB disabled vmalloc area: ee000000-f51fe000, maxmem 2d7fe000
Memory: 2072132k/209715= 2k available (1917k kernel code, 23952k reserved, 537k data, 148k init, 135= 1688k highmem)
Checking if this processor honours the WP bit even in sup= ervisor mode... Ok.
Calibrating delay using timer specific routine.. 6820.46 BogoMIPS (lpj=3D34= 10231)
Mount-cache hash table entries: 512
CPU: L1 I cache: 32K, L1 D= cache: 32K
CPU: L2 cache: 256K
CPU: L3 cache: 8192K
Checking '= ;hlt' instruction... OK.
Brought up 1 CPUs
migration_cost=3D0
Grant table initialized
NET: = Registered protocol family 16
xen_mem: Initialising balloon driver.
S= CSI subsystem initialized
highmem bounce pool size: 64 pages
Installi= ng knfsd (copyright (C) 1996 okir@mona= d.swb.de).
Initializing Cryptographic API
io scheduler noop registered
io schedu= ler cfq registered (default)
rtc: IRQ 8 is not free.
i8042.c: No cont= roller found.
loop: loaded (max 8 devices)
Xen virtual console succes= sfully installed as tty1
Event-channel device installed.
netfront: Initialising virtual ethernet = driver.
mice: PS/2 mouse device common for all mice
Netfilter message= s via NETLINK v0.30.
NET: Registered protocol family 2
netfront: devi= ce eth0 has copying receive path.
Registering block device major 202
blkfront: xvda1: barriers enabled
= IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP es= tablished hash table entries: 131072 (order: 8, 1048576 bytes)
TCP bind = hash table entries: 65536 (order: 7, 524288 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno reg= istered
ip_conntrack version 2.4 (8192 buckets, 65536 max) - 232 bytes p= er conntrack
ip_conntrack_pptp version 3.1 loaded
ip_nat_pptp version= 3.0 loaded
ip_tables: (C) 2000-2006 Netfilter Core Team
ipt_recent v0.3.1: Stephen = Frost <sfrost@snowman.net>.= =A0 http://snowman.net/= projects/ipt_recent/
TCP bic registered
NET: Registered protocol family 1
NET: Registered = protocol family 17
NET: Registered protocol family 15
Bridge firewall= ing registered
802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>
All bugs added by David S. Miller <d= avem@redhat.com>
Using IPI Shortcut mode
end_request: I/O erro= r, dev xvda1, sector 2
EXT3-fs: unable to read superblock
Unable to h= andle kernel NULL pointer dereference at virtual address 00000024
=A0printing eip:
c0232139
005c4000 -> *pde =3D 00000000:00000000Oops: 0000 [#1]
SMP
CPU:=A0=A0=A0 0
EIP:=A0=A0=A0 0061:[<c023= 2139>]=A0=A0=A0 Not tainted VLI
EFLAGS: 00010097=A0=A0 (2.6.16.33-xen= -domU-oldgame #1)
EIP is at blkif_int+0x1dc/0x228
eax: 00000000=A0=A0 ebx: 00000001=A0=A0 ecx: c090e000=A0=A0 edx: 00000000esi: d92d7c7c=A0=A0 edi: ca010100=A0=A0 ebp: ed6ea0ac=A0=A0 esp: c0367ec0=
ds: 007b=A0=A0 es: 007b=A0=A0 ss: e021
Process swapper (pid: 0, thre= adinfo=3Dc0366000 task=3Dc030d7c0)
Stack: <0>c200ce24 109c6373 00000000 00000000 00000001 00000002 00000= 000 00000001
=A0=A0=A0=A0=A0=A0 ed6ab7a0 00000000 00000000 c0367f6c c013= 3197 00000105 c090e000 c0367f6c
=A0=A0=A0=A0=A0=A0 00000105 00008280 c03= 5b680 00000105 ed6ab7a0 c013328f 00000105 0000000a
Call Trace:
=A0[<c0133197>] handle_IRQ_event+0x38/0xa9
=A0[<= c013328f>] __do_IRQ+0x87/0xf8
=A0[<c0106782>] do_IRQ+0x1a/0x25<= br>=A0[<c0228d85>] evtchn_do_upcall+0x95/0xa9
=A0[<c010504d>= ] hypervisor_callback+0x3d/0x48
=A0[<c0107ecf>] safe_halt+0x7a/0xb2
=A0[<c0102efd>] xen_idle= +0x2b/0x4e
=A0[<c0103014>] cpu_idle+0x52/0x67
=A0[<c036871c&= gt;] start_kernel+0x2b8/0x33c
=A0[<c03681ea>] unknown_bootoption+0= x0/0x27a
Code: c7 04 24 e0 17 30 c0 e8 39 8b ee ff 8b 44 24 38 c7 80 00 14 00 00 00 = 00 00 00 89 04 24 e8 75 03 00 00 bb a1 ff ff ff 8b 54 24 0c <8b> 42 2= 4 89 44 24 08 89 5c 24 04 89 14 24 e8 3b eb fb ff 85 c0
=A0<0>Kern= el panic - not syncing: Fatal exception in interrupt

And finally the domain-builder-ng.log when started with xend and workin= g:

2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_all= ocate: cmdline=3D"root=3D/dev/xvda1 ro console=3Dxvc0 earlyprintk=3Dxe= n", features=3D""
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_kernel_file: = filename=3D"/boot/bzImage-domU-oldgame"
2012-10-03 14:00:41 EE= ST [3773] domainbuilder: detail: xc_dom_malloc_filemap=A0=A0=A0 : 1237 kB2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_malloc=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 2653 kB
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_do_gunzip: un= zip ok, 0x135462 -> 0x297540
2012-10-03 14:00:41 EEST [3773] domainbu= ilder: detail: xc_dom_parse_image: called
2012-10-03 14:00:41 EEST [3773= ] domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary loader= ...
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: loader probe failed<= br>2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_find_loade= r: trying Linux bzImage loader ...
2012-10-03 14:00:41 EEST [3773] doma= inbuilder: detail: xc_dom_probe_bzimage_kernel: kernel is not a bzImage
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: loader probe failed<= br>2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_find_loade= r: trying ELF-generic loader ...
2012-10-03 14:00:41 EEST [3773] domain= builder: detail: loader probe OK
2012-10-03 14:00:41 EEST [3773] xc: detail: elf_parse_binary: phdr: paddr= =3D0xc0100000 memsz=3D0x20d500
2012-10-03 14:00:41 EEST [3773] xc: detai= l: elf_parse_binary: phdr: paddr=3D0xc030d500 memsz=3D0xb3308
2012-10-03= 14:00:41 EEST [3773] xc: detail: elf_parse_binary: memory: 0xc0100000 ->= ; 0xc03c0808
2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: GUEST_OS = =3D "linux"
2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xe= n_parse_note: GUEST_VERSION =3D "2.6"
2012-10-03 14:00:41 EEST= [3773] xc: detail: elf_xen_parse_note: XEN_VERSION =3D "xen-3.0"=
2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: VIRT_BASE = =3D 0xc0000000
2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse= _note: PADDR_OFFSET =3D 0xc0000000
2012-10-03 14:00:41 EEST [3773] xc: d= etail: elf_xen_parse_note: ENTRY =3D 0xc0100000
2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: HYPERCALL_P= AGE =3D 0xc0101000
2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_p= arse_note: HV_START_LOW =3D 0xf5800000
2012-10-03 14:00:41 EEST [3773] x= c: detail: elf_xen_parse_note: FEATURES =3D "writable_page_tables|writ= able_descriptor_tables|auto_translated_physmap|pae_pgdir_above_4gb|supervis= or_mode_kernel"
2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: PAE_MODE = =3D "yes"
2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_= parse_note: LOADER =3D "generic"
2012-10-03 14:00:41 EEST [377= 3] xc: detail: elf_xen_parse: using notes from SHT_NOTE section
2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_addr_calc_check: addres= ses:
2012-10-03 14:00:41 EEST [3773] xc: detail:=A0=A0=A0=A0 virt_base= =A0=A0=A0=A0=A0=A0=A0 =3D 0xc0000000
2012-10-03 14:00:41 EEST [3773] xc:= detail:=A0=A0=A0=A0 elf_paddr_offset =3D 0xc0000000
2012-10-03 14:00:41 EEST [3773] xc: detail:=A0=A0=A0=A0 virt_offset=A0=A0= =A0=A0=A0 =3D 0x0
2012-10-03 14:00:41 EEST [3773] xc: detail:=A0=A0=A0= =A0 virt_kstart=A0=A0=A0=A0=A0 =3D 0xc0100000
2012-10-03 14:00:41 EEST [= 3773] xc: detail:=A0=A0=A0=A0 virt_kend=A0=A0=A0=A0=A0=A0=A0 =3D 0xc03c0808=
2012-10-03 14:00:41 EEST [3773] xc: detail:=A0=A0=A0=A0 virt_entry=A0=A0=A0= =A0=A0=A0 =3D 0xc0100000
2012-10-03 14:00:41 EEST [3773] xc: detail:=A0= =A0=A0=A0 p2m_base=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0xffffffffffffffff
2012-1= 0-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_parse_elf_kernel: x= en-3.0-x86_32p: 0xc0100000 -> 0xc03c0808
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_release: call= ed
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_allocat= e: cmdline=3D"root=3D/dev/xvda1 ro console=3Dxvc0 earlyprintk=3Dxen&qu= ot;, features=3D""
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_kernel_file: = filename=3D"/boot/bzImage-domU-oldgame"
2012-10-03 14:00:41 EE= ST [3773] domainbuilder: detail: xc_dom_malloc_filemap=A0=A0=A0 : 1237 kB2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_malloc=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 2653 kB
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_do_gunzip: un= zip ok, 0x135462 -> 0x297540
2012-10-03 14:00:41 EEST [3773] domainbu= ilder: detail: xc_dom_boot_xen_init: ver 4.2, caps xen-3.0-x86_64 xen-3.0-x= 86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_parse_image: = called
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_fin= d_loader: trying multiboot-binary loader ...
2012-10-03 14:00:41 EEST [= 3773] domainbuilder: detail: loader probe failed
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_find_loader: = trying Linux bzImage loader ...
2012-10-03 14:00:41 EEST [3773] domainb= uilder: detail: xc_dom_probe_bzimage_kernel: kernel is not a bzImage
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: loader probe failed<= br>2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_find_loade= r: trying ELF-generic loader ...
2012-10-03 14:00:41 EEST [3773] domain= builder: detail: loader probe OK
2012-10-03 14:00:41 EEST [3773] xc: detail: elf_parse_binary: phdr: paddr= =3D0xc0100000 memsz=3D0x20d500
2012-10-03 14:00:41 EEST [3773] xc: detai= l: elf_parse_binary: phdr: paddr=3D0xc030d500 memsz=3D0xb3308
2012-10-03= 14:00:41 EEST [3773] xc: detail: elf_parse_binary: memory: 0xc0100000 ->= ; 0xc03c0808
2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: GUEST_OS = =3D "linux"
2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xe= n_parse_note: GUEST_VERSION =3D "2.6"
2012-10-03 14:00:41 EEST= [3773] xc: detail: elf_xen_parse_note: XEN_VERSION =3D "xen-3.0"=
2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: VIRT_BASE = =3D 0xc0000000
2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse= _note: PADDR_OFFSET =3D 0xc0000000
2012-10-03 14:00:41 EEST [3773] xc: d= etail: elf_xen_parse_note: ENTRY =3D 0xc0100000
2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: HYPERCALL_P= AGE =3D 0xc0101000
2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_p= arse_note: HV_START_LOW =3D 0xf5800000
2012-10-03 14:00:41 EEST [3773] x= c: detail: elf_xen_parse_note: FEATURES =3D "writable_page_tables|writ= able_descriptor_tables|auto_translated_physmap|pae_pgdir_above_4gb|supervis= or_mode_kernel"
2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_parse_note: PAE_MODE = =3D "yes"
2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_= parse_note: LOADER =3D "generic"
2012-10-03 14:00:41 EEST [377= 3] xc: detail: elf_xen_parse: using notes from SHT_NOTE section
2012-10-03 14:00:41 EEST [3773] xc: detail: elf_xen_addr_calc_check: addres= ses:
2012-10-03 14:00:41 EEST [3773] xc: detail:=A0=A0=A0=A0 virt_base= =A0=A0=A0=A0=A0=A0=A0 =3D 0xc0000000
2012-10-03 14:00:41 EEST [3773] xc:= detail:=A0=A0=A0=A0 elf_paddr_offset =3D 0xc0000000
2012-10-03 14:00:41 EEST [3773] xc: detail:=A0=A0=A0=A0 virt_offset=A0=A0= =A0=A0=A0 =3D 0x0
2012-10-03 14:00:41 EEST [3773] xc: detail:=A0=A0=A0= =A0 virt_kstart=A0=A0=A0=A0=A0 =3D 0xc0100000
2012-10-03 14:00:41 EEST [= 3773] xc: detail:=A0=A0=A0=A0 virt_kend=A0=A0=A0=A0=A0=A0=A0 =3D 0xc03c0808=
2012-10-03 14:00:41 EEST [3773] xc: detail:=A0=A0=A0=A0 virt_entry=A0=A0=A0= =A0=A0=A0 =3D 0xc0100000
2012-10-03 14:00:41 EEST [3773] xc: detail:=A0= =A0=A0=A0 p2m_base=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0xffffffffffffffff
2012-1= 0-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_parse_elf_kernel: x= en-3.0-x86_32p: 0xc0100000 -> 0xc03c0808
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_mem_init: mem= 2048 MB, pages 0x80000 pages, 4k each
2012-10-03 14:00:41 EEST [3773] d= omainbuilder: detail: xc_dom_mem_init: 0x80000 pages
2012-10-03 14:00:41= EEST [3773] domainbuilder: detail: xc_dom_boot_mem_init: called
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: x86_compat: guest xe= n-3.0-x86_32p, address size 32
2012-10-03 14:00:41 EEST [3773] domainbui= lder: detail: xc_dom_malloc=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 4096 kB
2= 012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_build_image: c= alled
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_alloc_segment= :=A0=A0 kernel=A0=A0=A0=A0=A0=A0 : 0xc0100000 -> 0xc03c1000=A0 (pfn 0x10= 0 + 0x2c1 pages)
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: = xc_dom_pfn_to_ptr: domU mapping: pfn 0x100+0x2c1 at 0x7fdebe53c000
2012-10-03 14:00:41 EEST [3773] xc: detail: elf_load_binary: phdr 0 at 0x0x= 7fdebe53c000 -> 0x0x7fdebe749500
2012-10-03 14:00:41 EEST [3773] xc: = detail: elf_load_binary: phdr 1 at 0x0x7fdebe749500 -> 0x0x7fdebe7c893c<= br> 2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_alloc_segment= :=A0=A0 phys2mach=A0=A0=A0 : 0xc03c1000 -> 0xc05c1000=A0 (pfn 0x3c1 + 0x= 200 pages)
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom= _pfn_to_ptr: domU mapping: pfn 0x3c1+0x200 at 0x7fdebe33c000
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_alloc_page=A0= =A0 :=A0=A0 start info=A0=A0 : 0xc05c1000 (pfn 0x5c1)
2012-10-03 14:00:4= 1 EEST [3773] domainbuilder: detail: xc_dom_alloc_page=A0=A0 :=A0=A0 xensto= re=A0=A0=A0=A0 : 0xc05c2000 (pfn 0x5c2)
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_alloc_page=A0= =A0 :=A0=A0 console=A0=A0=A0=A0=A0 : 0xc05c3000 (pfn 0x5c3)
2012-10-03 1= 4:00:41 EEST [3773] domainbuilder: detail: nr_page_tables: 0x00000000ffffff= ff/32: 0x0000000000000000 -> 0x00000000ffffffff, 1 table(s)
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: nr_page_tables: 0x00= 0000003fffffff/30: 0x00000000c0000000 -> 0x00000000ffffffff, 1 table(s)<= br>2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: nr_page_tables: 0= x00000000001fffff/21: 0x00000000c0000000 -> 0x00000000c07fffff, 4 table(= s)
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_alloc_segment= :=A0=A0 page tables=A0 : 0xc05c4000 -> 0xc05ca000=A0 (pfn 0x5c4 + 0x6 pa= ges)
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_pfn_t= o_ptr: domU mapping: pfn 0x5c4+0x6 at 0x7fdeca12d000
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_alloc_page=A0= =A0 :=A0=A0 boot stack=A0=A0 : 0xc05ca000 (pfn 0x5ca)
2012-10-03 14:00:4= 1 EEST [3773] domainbuilder: detail: xc_dom_build_image=A0 : virt_alloc_end= : 0xc05cb000
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_build_image= =A0 : virt_pgtab_end : 0xc0800000
2012-10-03 14:00:41 EEST [3773] domain= builder: detail: xc_dom_boot_image: called
2012-10-03 14:00:41 EEST [377= 3] domainbuilder: detail: arch_setup_bootearly: doing nothing
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_compat_check:= supported guest type: xen-3.0-x86_64
2012-10-03 14:00:41 EEST [3773] do= mainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-x86= _32p <=3D matches
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_compat_check:= supported guest type: hvm-3.0-x86_32
2012-10-03 14:00:41 EEST [3773] do= mainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86= _32p
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: xc_dom_compat_check:= supported guest type: hvm-3.0-x86_64
2012-10-03 14:00:41 EEST [3773] do= mainbuilder: detail: xc_dom_update_guest_p2m: dst 32bit, pages 0x80000
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: clear_page: pfn 0x5c= 3, mfn 0x697ee5
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: c= lear_page: pfn 0x5c2, mfn 0x697ee6
2012-10-03 14:00:41 EEST [3773] domai= nbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x5c1+0x1 at 0x7fdec= a12a000
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: start_info_x86_32: c= alled
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: setup_hyper= call_page: vaddr=3D0xc0101000 pfn=3D0x101
2012-10-03 14:00:41 EEST [3773= ] domainbuilder: detail: domain builder memory footprint
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail:=A0=A0=A0 allocated2012-10-03 14:00:41 EEST [3773] domainbuilder: detail:=A0=A0=A0=A0=A0=A0 = malloc=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 6780 kB
2012-10-03 14:00:41= EEST [3773] domainbuilder: detail:=A0=A0=A0=A0=A0=A0 anon mmap=A0=A0=A0=A0= =A0=A0=A0=A0=A0 : 0 bytes
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail:=A0=A0=A0 mapped
2= 012-10-03 14:00:41 EEST [3773] domainbuilder: detail:=A0=A0=A0=A0=A0=A0 fil= e mmap=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 1237 kB
2012-10-03 14:00:41 EEST [37= 73] domainbuilder: detail:=A0=A0=A0=A0=A0=A0 domU mmap=A0=A0=A0=A0=A0=A0=A0= =A0=A0 : 4896 kB
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: arch_setup_bootlate:= shared_info: pfn 0x0, mfn 0xdbdf8
2012-10-03 14:00:41 EEST [3773] domai= nbuilder: detail: shared_info_x86_32: called
2012-10-03 14:00:41 EEST [3= 773] domainbuilder: detail: vcpu_x86_32: called
2012-10-03 14:00:41 EEST [3773] domainbuilder: detail: vcpu_x86_32: cr3: pf= n 0x5c4 mfn 0x697ee4
2012-10-03 14:00:41 EEST [3773] domainbuilder: deta= il: launch_vm: called, ctxt=3D0x7fdebf7fa650
2012-10-03 14:00:41 EEST [3= 773] domainbuilder: detail: xc_dom_release: called

- Valtteri

2012/10/3 Ian Campbell <Ian.Campbell@citrix.com>
On Wed, 2012-10-03 at 11:42 +0100, Valtteri Kiviniemi wro= te:
> Hi,
>
> I tried to lower vcpus to 1, and now it produces a different crash: >
> Unable to handle kernel NULL pointer dereference at virtual address > 00000024
> =A0printing eip:
> c0232139
> 005c4000 -> *pde =3D 00000000:00000000
> Oops: 0000 [#1]
> SMP
> CPU: =A0 =A00
> EIP: =A0 =A00061:[<c0232139>] =A0 =A0Not tainted VLI
> EFLAGS: 00010097 =A0 (2.6.16.33-xen-domU-oldgame #1)
> EIP is at blkif_int+0x1dc/0x228

I don't suppose you have source / debug info for this kernel to r= esolve
this into a location?

You say this exact same config works with xend?

If so then, since this appears to relate to the devices, one thing which might be worth trying is to set on_crash =3D "preserve" in your c= onfig and
run under both xend and xl. You can then collect the content of xenstore (xenstore-ls -fp) in both cases (xend booted ok, xl preserved in the
crashed state), and compare.

There will be a bunch of differences relating to the xend one finishing
its boot but something might stand out in the diff. Just posting both
sets of output might be useful.

If you run "xl -vvv create" you should also get a bunch of stuff<= br> relating to the domain builder and where it is placing things. Running
under xend I think something similar is dumped under /var/log/xen
(domain-build-ng.log?)

What does your config file look like?

Ian.



--001636ef09adc44f7f04cb25a56c-- --===============8545444535638952119== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8545444535638952119==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 11:12:15 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 11:12:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJMrt-0007j8-C5; Wed, 03 Oct 2012 11:11:57 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJMrr-0007ix-Qm for xen-devel@lists.xen.org; Wed, 03 Oct 2012 11:11:56 +0000 Received: from [85.158.138.51:39804] by server-5.bemta-3.messagelabs.com id D4/85-00589-A7D1C605; Wed, 03 Oct 2012 11:11:54 +0000 X-Env-Sender: jefranca@gmail.com X-Msg-Ref: server-14.tower-174.messagelabs.com!1349262713!26597847!1 X-Originating-IP: [209.85.220.173] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11129 invoked from network); 3 Oct 2012 11:11:54 -0000 Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com) (209.85.220.173) by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 11:11:54 -0000 Received: by vcbfl15 with SMTP id fl15so10056103vcb.32 for ; Wed, 03 Oct 2012 04:11:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wNCWU6kivhG0fwdysixK4pT0P13fhJBsvSaOBQekQ9w=; b=LJJsKzthhB8+QcLG8p9aT8rDlZf39Se6q8lraB65WKmtyzcy6bobPBeqH7XVWoxQUC GAcenx1RLoqcXDogPsL11qz2fzT/7QK/VUMOIfQY45usSWPxLowQVt5UXGaKlAQUA5oU P7m6a83JMGz+64ILJuUDNB2v/GZFNPQdOkmXVmX7BtebdTtK1j/m5pbCdQR03U+XR7na vK6ImNtOdj7Pyy1grBTcrShq2PS6rENu5KJ1UlslcysVpKCf9mc+r07WZqlLuwUUEGPx +1U8TcU0OzsWQxtw2ZylDKQfKwvn/NOgvYHEGp+CH9KJbZynsIAGxxKNLTO4BPvuvz0/ G+vw== MIME-Version: 1.0 Received: by 10.59.0.41 with SMTP id av9mr960044ved.32.1349262712716; Wed, 03 Oct 2012 04:11:52 -0700 (PDT) Received: by 10.58.64.9 with HTTP; Wed, 3 Oct 2012 04:11:52 -0700 (PDT) In-Reply-To: <75A1D5EB-12C7-4829-A3F7-4D77B2405FBB@gmail.com> References: <75A1D5EB-12C7-4829-A3F7-4D77B2405FBB@gmail.com> Date: Wed, 3 Oct 2012 08:11:52 -0300 Message-ID: From: =?ISO-8859-1?Q?Jos=E9_Eduardo_Fran=E7a?= To: lmingcsce Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] How to get the checkpoint size in remus code? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6338884314865778798==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============6338884314865778798== Content-Type: multipart/alternative; boundary=047d7bdc992cb33ca304cb25b444 --047d7bdc992cb33ca304cb25b444 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I thought remus used xc_domain_save. Is this function used from live migration? Futhermore I have two doubts if really Remus takes the last iteration of live migration 1. What's the function? 2. And how to get de I/O disk size on each period? Thanks 2012/10/1 lmingcsce > Remus takes advantage of the last iteration of live migration to get dirt= y > memory and transfer to the backup machine. So you can get the dirty memor= y > size from live migration's dirty bitmap. > > On Oct 1, 2012, at 10:48 AM, Jos=E9 Eduardo Fran=E7a wrote: > > Hi, > > I'm doing my master research and I need to adapt remus code. Now... I > wanna get the checkpoint size (memory + disk) on each period. Does someon= e > know what function does this? I think some *fd *object's function in > remus code could just get the memory size. > > Does someone help me? > > Thanks > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel > > > --047d7bdc992cb33ca304cb25b444 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I thought remus used xc_domain_save. Is this function used from live migrat= ion?

Futhermore I have two doubts if really Remus takes the last ite= ration of live migration
  1. What's the function?
  2. And how to= get de I/O disk size on each period?
Thanks

2012/10/1 lmingcsce <lming= csce@gmail.com>
Remus takes advantage of the last itera= tion of live migration to get dirty memory and transfer to the backup machi= ne. So you can get the dirty memory size from live migration's dirty bi= tmap.=A0

On Oct 1, 2012, at 10:48 AM, Jos=E9 Ed= uardo Fran=E7a wrote:

<= div class=3D"h5">Hi,

I'm doing my master research and I need to = adapt remus code. Now... I wanna get the checkpoint size (memory + disk) on= each period. Does someone know what function does this? I think some fd= object's function in remus code could just get the memory size.
Does someone help me?

Thanks
_______________________________________________
Xen-devel mailing listXen-devel@li= sts.xen.org
http://lists.xen.org/xen-devel


--047d7bdc992cb33ca304cb25b444-- --===============6338884314865778798== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6338884314865778798==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 11:12:15 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 11:12:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJMrt-0007j8-C5; Wed, 03 Oct 2012 11:11:57 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJMrr-0007ix-Qm for xen-devel@lists.xen.org; Wed, 03 Oct 2012 11:11:56 +0000 Received: from [85.158.138.51:39804] by server-5.bemta-3.messagelabs.com id D4/85-00589-A7D1C605; Wed, 03 Oct 2012 11:11:54 +0000 X-Env-Sender: jefranca@gmail.com X-Msg-Ref: server-14.tower-174.messagelabs.com!1349262713!26597847!1 X-Originating-IP: [209.85.220.173] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11129 invoked from network); 3 Oct 2012 11:11:54 -0000 Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com) (209.85.220.173) by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 11:11:54 -0000 Received: by vcbfl15 with SMTP id fl15so10056103vcb.32 for ; Wed, 03 Oct 2012 04:11:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wNCWU6kivhG0fwdysixK4pT0P13fhJBsvSaOBQekQ9w=; b=LJJsKzthhB8+QcLG8p9aT8rDlZf39Se6q8lraB65WKmtyzcy6bobPBeqH7XVWoxQUC GAcenx1RLoqcXDogPsL11qz2fzT/7QK/VUMOIfQY45usSWPxLowQVt5UXGaKlAQUA5oU P7m6a83JMGz+64ILJuUDNB2v/GZFNPQdOkmXVmX7BtebdTtK1j/m5pbCdQR03U+XR7na vK6ImNtOdj7Pyy1grBTcrShq2PS6rENu5KJ1UlslcysVpKCf9mc+r07WZqlLuwUUEGPx +1U8TcU0OzsWQxtw2ZylDKQfKwvn/NOgvYHEGp+CH9KJbZynsIAGxxKNLTO4BPvuvz0/ G+vw== MIME-Version: 1.0 Received: by 10.59.0.41 with SMTP id av9mr960044ved.32.1349262712716; Wed, 03 Oct 2012 04:11:52 -0700 (PDT) Received: by 10.58.64.9 with HTTP; Wed, 3 Oct 2012 04:11:52 -0700 (PDT) In-Reply-To: <75A1D5EB-12C7-4829-A3F7-4D77B2405FBB@gmail.com> References: <75A1D5EB-12C7-4829-A3F7-4D77B2405FBB@gmail.com> Date: Wed, 3 Oct 2012 08:11:52 -0300 Message-ID: From: =?ISO-8859-1?Q?Jos=E9_Eduardo_Fran=E7a?= To: lmingcsce Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] How to get the checkpoint size in remus code? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6338884314865778798==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============6338884314865778798== Content-Type: multipart/alternative; boundary=047d7bdc992cb33ca304cb25b444 --047d7bdc992cb33ca304cb25b444 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I thought remus used xc_domain_save. Is this function used from live migration? Futhermore I have two doubts if really Remus takes the last iteration of live migration 1. What's the function? 2. And how to get de I/O disk size on each period? Thanks 2012/10/1 lmingcsce > Remus takes advantage of the last iteration of live migration to get dirt= y > memory and transfer to the backup machine. So you can get the dirty memor= y > size from live migration's dirty bitmap. > > On Oct 1, 2012, at 10:48 AM, Jos=E9 Eduardo Fran=E7a wrote: > > Hi, > > I'm doing my master research and I need to adapt remus code. Now... I > wanna get the checkpoint size (memory + disk) on each period. Does someon= e > know what function does this? I think some *fd *object's function in > remus code could just get the memory size. > > Does someone help me? > > Thanks > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel > > > --047d7bdc992cb33ca304cb25b444 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I thought remus used xc_domain_save. Is this function used from live migrat= ion?

Futhermore I have two doubts if really Remus takes the last ite= ration of live migration
  1. What's the function?
  2. And how to= get de I/O disk size on each period?
Thanks

2012/10/1 lmingcsce <lming= csce@gmail.com>
Remus takes advantage of the last itera= tion of live migration to get dirty memory and transfer to the backup machi= ne. So you can get the dirty memory size from live migration's dirty bi= tmap.=A0

On Oct 1, 2012, at 10:48 AM, Jos=E9 Ed= uardo Fran=E7a wrote:

<= div class=3D"h5">Hi,

I'm doing my master research and I need to = adapt remus code. Now... I wanna get the checkpoint size (memory + disk) on= each period. Does someone know what function does this? I think some fd= object's function in remus code could just get the memory size.
Does someone help me?

Thanks
_______________________________________________
Xen-devel mailing listXen-devel@li= sts.xen.org
http://lists.xen.org/xen-devel


--047d7bdc992cb33ca304cb25b444-- --===============6338884314865778798== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6338884314865778798==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 11:28:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 11:28:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJN7L-0007w6-7x; Wed, 03 Oct 2012 11:27:55 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJN7K-0007w1-49 for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 11:27:54 +0000 Received: from [85.158.139.83:19345] by server-1.bemta-5.messagelabs.com id BA/C1-09825-9312C605; Wed, 03 Oct 2012 11:27:53 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1349263672!19136739!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23951 invoked from network); 3 Oct 2012 11:27:52 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 11:27:52 -0000 X-IronPort-AV: E=Sophos;i="4.80,527,1344211200"; d="scan'208";a="14912957" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 11:27:51 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 12:27:51 +0100 Message-ID: <1349263669.650.131.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Valtteri Kiviniemi Date: Wed, 3 Oct 2012 12:27:49 +0100 In-Reply-To: References: <1349259542.650.122.camel@zakaz.uk.xensource.com> <1349261397.650.130.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Xen 4.2.0, xl toolstack cant launch older domUs X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-10-03 at 12:07 +0100, Valtteri Kiviniemi wrote: > > /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2 = "" (n0) The interesting stuff will be under /local/domain/0 and /local/domain/ rather than under /vm. The builder logs were the same modulo some insignificant changes. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 11:28:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 11:28:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJN7L-0007w6-7x; Wed, 03 Oct 2012 11:27:55 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJN7K-0007w1-49 for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 11:27:54 +0000 Received: from [85.158.139.83:19345] by server-1.bemta-5.messagelabs.com id BA/C1-09825-9312C605; Wed, 03 Oct 2012 11:27:53 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1349263672!19136739!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23951 invoked from network); 3 Oct 2012 11:27:52 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 11:27:52 -0000 X-IronPort-AV: E=Sophos;i="4.80,527,1344211200"; d="scan'208";a="14912957" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 11:27:51 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 12:27:51 +0100 Message-ID: <1349263669.650.131.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Valtteri Kiviniemi Date: Wed, 3 Oct 2012 12:27:49 +0100 In-Reply-To: References: <1349259542.650.122.camel@zakaz.uk.xensource.com> <1349261397.650.130.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Xen 4.2.0, xl toolstack cant launch older domUs X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-10-03 at 12:07 +0100, Valtteri Kiviniemi wrote: > > /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2 = "" (n0) The interesting stuff will be under /local/domain/0 and /local/domain/ rather than under /vm. The builder logs were the same modulo some insignificant changes. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 11:45:22 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 11:45:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJNNk-00089z-Rw; Wed, 03 Oct 2012 11:44:52 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJNNj-00089u-EY for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 11:44:52 +0000 Received: from [85.158.137.99:13628] by server-11.bemta-3.messagelabs.com id F4/7F-21460-1352C605; Wed, 03 Oct 2012 11:44:49 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-3.tower-217.messagelabs.com!1349264685!15042781!1 X-Originating-IP: [209.85.213.173] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28448 invoked from network); 3 Oct 2012 11:44:46 -0000 Received: from mail-yx0-f173.google.com (HELO mail-yx0-f173.google.com) (209.85.213.173) by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 11:44:46 -0000 Received: by yenl3 with SMTP id l3so2195695yen.32 for ; Wed, 03 Oct 2012 04:44:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EBaMR2gFY4ZDMbVxvZ9PYUEjD61O/h0GK3S7JHAQ5PU=; b=HOeUEgvel4LX7RUWY1JYV7QPTS73WxYbF4FO0cKDMkOWtsIDufA5yZXqXPiQw0Cggh k3bGU8XSCevNlrWevx7rJkE++1NJmFxvadNtGG3SGjvmJJzQ8u2GJ7BhDnrfhEjUgL8t I5QVQpQpwt3ZFkgoTeiF3B6Mhhn6rCGybv9OkzpPTtvHcPW6vUz+UxaS9AE7gtytNmSV 0IzDdeERpsB4jDJeEV0Er9rx6XC6kSMfUIF7V0VbOt8WGtV5gP4z1Ry23yGvMveehBdU SA24fnChUYZyRnHs8uJzUWIcUpCNA2Jz1XNJwlWUacN1ws23LV3j2ZiRj0PYBPykxko+ HVMw== MIME-Version: 1.0 Received: by 10.236.151.99 with SMTP id a63mr1443385yhk.120.1349264684786; Wed, 03 Oct 2012 04:44:44 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Wed, 3 Oct 2012 04:44:44 -0700 (PDT) In-Reply-To: <1349263669.650.131.camel@zakaz.uk.xensource.com> References: <1349259542.650.122.camel@zakaz.uk.xensource.com> <1349261397.650.130.camel@zakaz.uk.xensource.com> <1349263669.650.131.camel@zakaz.uk.xensource.com> Date: Wed, 3 Oct 2012 14:44:44 +0300 Message-ID: From: Valtteri Kiviniemi To: Ian Campbell Cc: "Xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Xen 4.2.0, xl toolstack cant launch older domUs X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2788042825860687498==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============2788042825860687498== Content-Type: multipart/alternative; boundary=20cf303a2e353ea44104cb262a29 --20cf303a2e353ea44104cb262a29 Content-Type: text/plain; charset=ISO-8859-1 Hi, Ok, well lets do it thisway. Hopefully I got this right this time. Here is the ALL of the output available from xenstore-ls -fp when I'm only running dom0 and that problematic domU, and when it is launched with Xend and fully working: root@xen-2:~# xenstore-ls -fp /tool = "" (n0) /tool/xenstored = "" (n0) /local = "" (n0) /local/domain = "" (n0) /local/domain/0 = "" (r0) /local/domain/0/vm = "/vm/00000000-0000-0000-0000-000000000000" (r0) /local/domain/0/device = "" (n0) /local/domain/0/control = "" (n0) /local/domain/0/control/platform-feature-multiprocessor-suspend = "1" (n0) /local/domain/0/control/platform-feature-xs_reset_watches = "1" (n0) /local/domain/0/error = "" (n0) /local/domain/0/memory = "" (n0) /local/domain/0/memory/target = "1310720" (n0) /local/domain/0/guest = "" (n0) /local/domain/0/hvmpv = "" (n0) /local/domain/0/data = "" (n0) /local/domain/0/cpu = "" (r0) /local/domain/0/cpu/1 = "" (r0) /local/domain/0/cpu/1/availability = "online" (r0) /local/domain/0/cpu/3 = "" (r0) /local/domain/0/cpu/3/availability = "online" (r0) /local/domain/0/cpu/2 = "" (r0) /local/domain/0/cpu/2/availability = "online" (r0) /local/domain/0/cpu/4 = "" (r0) /local/domain/0/cpu/4/availability = "online" (r0) /local/domain/0/cpu/7 = "" (r0) /local/domain/0/cpu/7/availability = "online" (r0) /local/domain/0/cpu/0 = "" (r0) /local/domain/0/cpu/0/availability = "online" (r0) /local/domain/0/cpu/5 = "" (r0) /local/domain/0/cpu/5/availability = "online" (r0) /local/domain/0/cpu/6 = "" (r0) /local/domain/0/cpu/6/availability = "online" (r0) /local/domain/0/description = "" (r0) /local/domain/0/console = "" (r0) /local/domain/0/console/limit = "1048576" (r0) /local/domain/0/console/type = "xenconsoled" (r0) /local/domain/0/domid = "0" (r0) /local/domain/0/name = "Domain-0" (r0) /local/domain/0/backend = "" (r0) /local/domain/0/backend/vbd = "" (r0) /local/domain/0/backend/vbd/9 = "" (r0) /local/domain/0/backend/vbd/9/51713 = "" (n0,r9) /local/domain/0/backend/vbd/9/51713/domain = "lightning" (n0,r9) /local/domain/0/backend/vbd/9/51713/frontend = "/local/domain/9/device/vbd/51713" (n0,r9) /local/domain/0/backend/vbd/9/51713/uuid = "07c30250-23d0-45dc-a7fd-27c4705ab946" (n0,r9) /local/domain/0/backend/vbd/9/51713/bootable = "1" (n0,r9) /local/domain/0/backend/vbd/9/51713/dev = "xvda1" (n0,r9) /local/domain/0/backend/vbd/9/51713/state = "4" (n0,r9) /local/domain/0/backend/vbd/9/51713/params = "/dev/virtuals/lightning" (n0,r9) /local/domain/0/backend/vbd/9/51713/mode = "w" (n0,r9) /local/domain/0/backend/vbd/9/51713/online = "1" (n0,r9) /local/domain/0/backend/vbd/9/51713/frontend-id = "9" (n0,r9) /local/domain/0/backend/vbd/9/51713/type = "phy" (n0,r9) /local/domain/0/backend/vbd/9/51713/physical-device = "fd:7" (n0,r9) /local/domain/0/backend/vbd/9/51713/hotplug-status = "connected" (n0,r9) /local/domain/0/backend/vbd/9/51713/feature-flush-cache = "1" (n0,r9) /local/domain/0/backend/vbd/9/51713/feature-discard = "0" (n0,r9) /local/domain/0/backend/vbd/9/51713/feature-barrier = "1" (n0,r9) /local/domain/0/backend/vbd/9/51713/sectors = "104857600" (n0,r9) /local/domain/0/backend/vbd/9/51713/info = "0" (n0,r9) /local/domain/0/backend/vbd/9/51713/sector-size = "512" (n0,r9) /local/domain/0/backend/vif = "" (r0) /local/domain/0/backend/vif/9 = "" (r0) /local/domain/0/backend/vif/9/0 = "" (n0,r9) /local/domain/0/backend/vif/9/0/bridge = "xenbr0" (n0,r9) /local/domain/0/backend/vif/9/0/domain = "lightning" (n0,r9) /local/domain/0/backend/vif/9/0/handle = "0" (n0,r9) /local/domain/0/backend/vif/9/0/uuid = "07ba2113-4679-843f-f4d8-eadaec462af0" (n0,r9) /local/domain/0/backend/vif/9/0/script = "/etc/xen/scripts/vif-bridge" (n0,r9) /local/domain/0/backend/vif/9/0/state = "4" (n0,r9) /local/domain/0/backend/vif/9/0/frontend = "/local/domain/9/device/vif/0" (n0,r9) /local/domain/0/backend/vif/9/0/mac = "00:16:3e:1d:0d:91" (n0,r9) /local/domain/0/backend/vif/9/0/online = "1" (n0,r9) /local/domain/0/backend/vif/9/0/frontend-id = "9" (n0,r9) /local/domain/0/backend/vif/9/0/feature-sg = "1" (n0,r9) /local/domain/0/backend/vif/9/0/feature-gso-tcpv4 = "1" (n0,r9) /local/domain/0/backend/vif/9/0/feature-rx-copy = "1" (n0,r9) /local/domain/0/backend/vif/9/0/feature-rx-flip = "0" (n0,r9) /local/domain/0/backend/vif/9/0/hotplug-status = "connected" (n0,r9) /local/domain/0/backend/console = "" (r0) /local/domain/0/backend/console/9 = "" (r0) /local/domain/0/backend/console/9/0 = "" (n0,r9) /local/domain/0/backend/console/9/0/domain = "lightning" (n0,r9) /local/domain/0/backend/console/9/0/protocol = "vt100" (n0,r9) /local/domain/0/backend/console/9/0/uuid = "c17b2697-71ba-011d-9958-2094cf39a7e4" (n0,r9) /local/domain/0/backend/console/9/0/frontend = "/local/domain/9/device/console/0" (n0,r9) /local/domain/0/backend/console/9/0/state = "1" (n0,r9) /local/domain/0/backend/console/9/0/location = "2" (n0,r9) /local/domain/0/backend/console/9/0/online = "1" (n0,r9) /local/domain/0/backend/console/9/0/frontend-id = "9" (n0,r9) /local/domain/9 = "" (n0,r9) /local/domain/9/vm = "/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df" (n0,r9) /local/domain/9/device = "" (n9) /local/domain/9/device/vbd = "" (n9) /local/domain/9/device/vbd/51713 = "" (n9,r0) /local/domain/9/device/vbd/51713/virtual-device = "51713" (n9,r0) /local/domain/9/device/vbd/51713/device-type = "disk" (n9,r0) /local/domain/9/device/vbd/51713/protocol = "x86_32-abi" (n9,r0) /local/domain/9/device/vbd/51713/backend-id = "0" (n9,r0) /local/domain/9/device/vbd/51713/state = "4" (n9,r0) /local/domain/9/device/vbd/51713/backend = "/local/domain/0/backend/vbd/9/51713" (n9,r0) /local/domain/9/device/vbd/51713/ring-ref = "8" (n9,r0) /local/domain/9/device/vbd/51713/event-channel = "6" (n9,r0) /local/domain/9/device/vif = "" (n9) /local/domain/9/device/vif/0 = "" (n9,r0) /local/domain/9/device/vif/0/mac = "00:16:3e:1d:0d:91" (n9,r0) /local/domain/9/device/vif/0/handle = "0" (n9,r0) /local/domain/9/device/vif/0/protocol = "x86_32-abi" (n9,r0) /local/domain/9/device/vif/0/backend-id = "0" (n9,r0) /local/domain/9/device/vif/0/state = "4" (n9,r0) /local/domain/9/device/vif/0/backend = "/local/domain/0/backend/vif/9/0" (n9,r0) /local/domain/9/device/vif/0/tx-ring-ref = "521" (n9,r0) /local/domain/9/device/vif/0/rx-ring-ref = "522" (n9,r0) /local/domain/9/device/vif/0/event-channel = "7" (n9,r0) /local/domain/9/device/vif/0/request-rx-copy = "1" (n9,r0) /local/domain/9/device/vif/0/feature-rx-notify = "1" (n9,r0) /local/domain/9/device/vif/0/feature-sg = "1" (n9,r0) /local/domain/9/device/vif/0/feature-gso-tcpv4 = "1" (n9,r0) /local/domain/9/device/console = "" (n9) /local/domain/9/device/console/0 = "" (n9,r0) /local/domain/9/device/console/0/protocol = "x86_32-abi" (n9,r0) /local/domain/9/device/console/0/state = "1" (n9,r0) /local/domain/9/device/console/0/backend-id = "0" (n9,r0) /local/domain/9/device/console/0/backend = "/local/domain/0/backend/console/9/0" (n9,r0) /local/domain/9/control = "" (n9) /local/domain/9/control/platform-feature-multiprocessor-suspend = "1" (n9) /local/domain/9/control/platform-feature-xs_reset_watches = "1" (n9) /local/domain/9/control/feature-reboot = "1" (n9) /local/domain/9/control/feature-sysrq = "1" (n9) /local/domain/9/error = "" (n9) /local/domain/9/memory = "" (n9) /local/domain/9/memory/target = "2097152" (n9) /local/domain/9/guest = "" (n9) /local/domain/9/hvmpv = "" (n9) /local/domain/9/data = "" (n9) /local/domain/9/device-misc = "" (n0,r9) /local/domain/9/device-misc/vif = "" (n0,r9) /local/domain/9/device-misc/vif/nextDeviceID = "1" (n0,r9) /local/domain/9/device-misc/console = "" (n0,r9) /local/domain/9/device-misc/console/nextDeviceID = "1" (n0,r9) /local/domain/9/console = "" (n0,r9) /local/domain/9/console/ring-ref = "7027814" (n0,r9) /local/domain/9/console/port = "2" (n0,r9) /local/domain/9/console/limit = "1048576" (n0,r9) /local/domain/9/console/type = "xenconsoled" (n0,r9) /local/domain/9/console/tty = "/dev/pts/2" (n0,r9) /local/domain/9/image = "" (n0,r9) /local/domain/9/image/entry = "3222274048" (n0,r9) /local/domain/9/image/loader = "generic" (n0,r9) /local/domain/9/image/hv-start-low = "4118806528" (n0,r9) /local/domain/9/image/guest-os = "linux" (n0,r9) /local/domain/9/image/features = "" (n0,r9) /local/domain/9/image/features/writable-descriptor-tables = "1" (n0,r9) /local/domain/9/image/features/supervisor-mode-kernel = "1" (n0,r9) /local/domain/9/image/features/pae-pgdir-above-4gb = "1" (n0,r9) /local/domain/9/image/features/writable-page-tables = "1" (n0,r9) /local/domain/9/image/features/auto-translated-physmap = "1" (n0,r9) /local/domain/9/image/hypercall-page = "3222278144" (n0,r9) /local/domain/9/image/guest-version = "2.6" (n0,r9) /local/domain/9/image/pae-mode = "yes" (n0,r9) /local/domain/9/image/paddr-offset = "3221225472" (n0,r9) /local/domain/9/image/virt-base = "3221225472" (n0,r9) /local/domain/9/image/xen-version = "xen-3.0" (n0,r9) /local/domain/9/store = "" (n0,r9) /local/domain/9/store/ring-ref = "7027815" (n0,r9) /local/domain/9/store/port = "1" (n0,r9) /local/domain/9/description = "" (n0,r9) /local/domain/9/cpu = "" (n0,r9) /local/domain/9/cpu/0 = "" (n0,r9) /local/domain/9/cpu/0/availability = "online" (n0,r9) /local/domain/9/name = "lightning" (n0,r9) /local/domain/9/domid = "9" (n0,r9) /local/pool = "" (n0) /local/pool/0 = "" (n0) /local/pool/0/other_config = "" (n0) /local/pool/0/description = "Pool-0" (n0) /local/pool/0/uuid = "caa85392-7062-bd40-53ee-fd3a7c1a1a6f" (n0) /local/pool/0/name = "Pool-0" (n0) /vm = "" (n0) /vm/00000000-0000-0000-0000-000000000000 = "" (n0) /vm/00000000-0000-0000-0000-000000000000/on_xend_stop = "ignore" (n0) /vm/00000000-0000-0000-0000-000000000000/pool_name = "Pool-0" (n0) /vm/00000000-0000-0000-0000-000000000000/shadow_memory = "0" (n0) /vm/00000000-0000-0000-0000-000000000000/uuid = "00000000-0000-0000-0000-000000000000" (r0) /vm/00000000-0000-0000-0000-000000000000/on_reboot = "restart" (n0) /vm/00000000-0000-0000-0000-000000000000/image = "(linux (kernel '') (superpages 0) (nomigrate 0) (tsc_mode 0))" (n0) /vm/00000000-0000-0000-0000-000000000000/image/ostype = "linux" (n0) /vm/00000000-0000-0000-0000-000000000000/image/kernel = "" (n0) /vm/00000000-0000-0000-0000-000000000000/image/cmdline = "" (r0) /vm/00000000-0000-0000-0000-000000000000/image/ramdisk = "" (n0) /vm/00000000-0000-0000-0000-000000000000/on_poweroff = "destroy" (n0) /vm/00000000-0000-0000-0000-000000000000/bootloader_args = "" (n0) /vm/00000000-0000-0000-0000-000000000000/on_xend_start = "ignore" (n0) /vm/00000000-0000-0000-0000-000000000000/on_crash = "restart" (n0) /vm/00000000-0000-0000-0000-000000000000/xend = "" (n0) /vm/00000000-0000-0000-0000-000000000000/xend/restart_count = "0" (n0) /vm/00000000-0000-0000-0000-000000000000/vcpus = "8" (n0) /vm/00000000-0000-0000-0000-000000000000/vcpu_avail = "255" (n0) /vm/00000000-0000-0000-0000-000000000000/bootloader = "" (n0) /vm/00000000-0000-0000-0000-000000000000/name = "Domain-0" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df = "" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/image = "(linux (kernel /boot/bzImage-domU-oldgame) (args 'root=/dev/xvda1 ro console=xvc0 earlyprintk=xen') (superpages 0) (videoram 4) (pci ()) (nomigrate 0) (tsc_mode 0) (notes (HV_START_LOW 411880652\..." (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/image/ostype = "linux" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/image/kernel = "/boot/bzImage-domU-oldgame" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/image/cmdline = "root=/dev/xvda1 ro console=xvc0 earlyprintk=xen" (n0,r9) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/image/ramdisk = "" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device = "" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/vbd = "" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/vbd/51713 = "" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/vbd/51713/frontend = "/local/domain/9/device/vbd/51713" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/vbd/51713/frontend-id = "9" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/vbd/51713/backend-id = "0" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/vbd/51713/backend = "/local/domain/0/backend/vbd/9/51713" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/vif = "" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/vif/0 = "" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/vif/0/frontend = "/local/domain/9/device/vif/0" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/vif/0/frontend-id = "9" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/vif/0/backend-id = "0" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/vif/0/backend = "/local/domain/0/backend/vif/9/0" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/console = "" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/console/0 = "" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/console/0/frontend = "/local/domain/9/device/console/0" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/console/0/frontend-id = "9" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/console/0/backend-id = "0" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/console/0/backend = "/local/domain/0/backend/console/9/0" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/on_xend_stop = "ignore" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/pool_name = "Pool-0" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/shadow_memory = "0" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/uuid = "f73e32ee-c0ee-2d58-98df-d7f2f6e062df" (n0,r9) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/on_reboot = "restart" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/start_time = "1349264227.39" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/on_poweroff = "destroy" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/bootloader_args = "" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/on_xend_start = "ignore" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/on_crash = "preserve" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/xend = "" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/xend/restart_count = "0" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/vcpus = "1" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/vcpu_avail = "1" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/bootloader = "" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/name = "lightning" (n0) ...And Here is the ALL of the output available from xenstore-ls -fp when I'm only running dom0 and that problematic domU and when it is launched with xl and crashed (preserved): root@xen-2:~# xenstore-ls -fp /tool = "" (n0) /tool/xenstored = "" (n0) /local = "" (n0) /local/domain = "" (n0) /local/domain/0 = "" (n0) /local/domain/0/name = "Domain-0" (n0) /local/domain/0/device-model = "" (n0) /local/domain/0/device-model/0 = "" (n0) /local/domain/0/device-model/0/state = "running" (n0) /local/domain/0/libxl = "" (n0) /local/domain/0/libxl/disable_udev = "1" (n0) /local/domain/0/backend = "" (n0) /local/domain/0/backend/vbd = "" (n0) /local/domain/0/backend/vbd/1 = "" (n0) /local/domain/0/backend/vbd/1/51713 = "" (n0,r1) /local/domain/0/backend/vbd/1/51713/frontend = "/local/domain/1/device/vbd/51713" (n0,r1) /local/domain/0/backend/vbd/1/51713/params = "/dev/virtuals/lightning" (n0,r1) /local/domain/0/backend/vbd/1/51713/script = "/etc/xen/scripts/block" (n0,r1) /local/domain/0/backend/vbd/1/51713/physical-device = "fd:7" (n0,r1) /local/domain/0/backend/vbd/1/51713/frontend-id = "1" (n0,r1) /local/domain/0/backend/vbd/1/51713/online = "1" (n0,r1) /local/domain/0/backend/vbd/1/51713/removable = "0" (n0,r1) /local/domain/0/backend/vbd/1/51713/bootable = "1" (n0,r1) /local/domain/0/backend/vbd/1/51713/state = "4" (n0,r1) /local/domain/0/backend/vbd/1/51713/dev = "xvda1" (n0,r1) /local/domain/0/backend/vbd/1/51713/type = "phy" (n0,r1) /local/domain/0/backend/vbd/1/51713/mode = "w" (n0,r1) /local/domain/0/backend/vbd/1/51713/device-type = "disk" (n0,r1) /local/domain/0/backend/vbd/1/51713/feature-flush-cache = "1" (n0,r1) /local/domain/0/backend/vbd/1/51713/feature-discard = "0" (n0,r1) /local/domain/0/backend/vbd/1/51713/feature-barrier = "1" (n0,r1) /local/domain/0/backend/vbd/1/51713/sectors = "104857600" (n0,r1) /local/domain/0/backend/vbd/1/51713/info = "0" (n0,r1) /local/domain/0/backend/vbd/1/51713/sector-size = "512" (n0,r1) /local/domain/0/backend/console = "" (n0) /local/domain/0/backend/console/1 = "" (n0) /local/domain/0/backend/console/1/0 = "" (n0,r1) /local/domain/0/backend/console/1/0/frontend = "/local/domain/1/console" (n0,r1) /local/domain/0/backend/console/1/0/frontend-id = "1" (n0,r1) /local/domain/0/backend/console/1/0/online = "1" (n0,r1) /local/domain/0/backend/console/1/0/state = "1" (n0,r1) /local/domain/0/backend/console/1/0/domain = "lightning" (n0,r1) /local/domain/0/backend/console/1/0/protocol = "vt100" (n0,r1) /local/domain/0/backend/vif = "" (n0) /local/domain/0/backend/vif/1 = "" (n0) /local/domain/0/backend/vif/1/0 = "" (n0,r1) /local/domain/0/backend/vif/1/0/frontend = "/local/domain/1/device/vif/0" (n0,r1) /local/domain/0/backend/vif/1/0/frontend-id = "1" (n0,r1) /local/domain/0/backend/vif/1/0/online = "1" (n0,r1) /local/domain/0/backend/vif/1/0/state = "4" (n0,r1) /local/domain/0/backend/vif/1/0/script = "/etc/xen/scripts/vif-bridge" (n0,r1) /local/domain/0/backend/vif/1/0/mac = "00:16:3e:1d:0d:91" (n0,r1) /local/domain/0/backend/vif/1/0/bridge = "xenbr0" (n0,r1) /local/domain/0/backend/vif/1/0/handle = "0" (n0,r1) /local/domain/0/backend/vif/1/0/type = "vif" (n0,r1) /local/domain/0/backend/vif/1/0/feature-sg = "1" (n0,r1) /local/domain/0/backend/vif/1/0/feature-gso-tcpv4 = "1" (n0,r1) /local/domain/0/backend/vif/1/0/feature-rx-copy = "1" (n0,r1) /local/domain/0/backend/vif/1/0/feature-rx-flip = "0" (n0,r1) /local/domain/0/backend/vif/1/0/hotplug-status = "connected" (n0,r1) /local/domain/1 = "" (n0,r1) /local/domain/1/vm = "/vm/55f79877-0895-400a-97ce-da869599a1ce" (n0,r1) /local/domain/1/name = "lightning" (n0,r1) /local/domain/1/cpu = "" (n0,r1) /local/domain/1/cpu/0 = "" (n0,r1) /local/domain/1/cpu/0/availability = "online" (n0,r1) /local/domain/1/memory = "" (n0,r1) /local/domain/1/memory/static-max = "2097152" (n0,r1) /local/domain/1/memory/target = "2097153" (n0,r1) /local/domain/1/memory/videoram = "-1" (n0,r1) /local/domain/1/device = "" (n0,r1) /local/domain/1/device/suspend = "" (n0,r1) /local/domain/1/device/suspend/event-channel = "" (n1) /local/domain/1/device/vbd = "" (n0,r1) /local/domain/1/device/vbd/51713 = "" (n1,r0) /local/domain/1/device/vbd/51713/backend = "/local/domain/0/backend/vbd/1/51713" (n1,r0) /local/domain/1/device/vbd/51713/backend-id = "0" (n1,r0) /local/domain/1/device/vbd/51713/state = "4" (n1,r0) /local/domain/1/device/vbd/51713/virtual-device = "51713" (n1,r0) /local/domain/1/device/vbd/51713/device-type = "disk" (n1,r0) /local/domain/1/device/vbd/51713/ring-ref = "8" (n1,r0) /local/domain/1/device/vbd/51713/event-channel = "6" (n1,r0) /local/domain/1/device/vif = "" (n0,r1) /local/domain/1/device/vif/0 = "" (n1,r0) /local/domain/1/device/vif/0/backend = "/local/domain/0/backend/vif/1/0" (n1,r0) /local/domain/1/device/vif/0/backend-id = "0" (n1,r0) /local/domain/1/device/vif/0/state = "4" (n1,r0) /local/domain/1/device/vif/0/handle = "0" (n1,r0) /local/domain/1/device/vif/0/mac = "00:16:3e:1d:0d:91" (n1,r0) /local/domain/1/device/vif/0/tx-ring-ref = "521" (n1,r0) /local/domain/1/device/vif/0/rx-ring-ref = "522" (n1,r0) /local/domain/1/device/vif/0/event-channel = "7" (n1,r0) /local/domain/1/device/vif/0/request-rx-copy = "1" (n1,r0) /local/domain/1/device/vif/0/feature-rx-notify = "1" (n1,r0) /local/domain/1/device/vif/0/feature-sg = "1" (n1,r0) /local/domain/1/device/vif/0/feature-gso-tcpv4 = "1" (n1,r0) /local/domain/1/control = "" (n0,r1) /local/domain/1/control/shutdown = "" (n1) /local/domain/1/control/platform-feature-multiprocessor-suspend = "1" (n0,r1) /local/domain/1/control/platform-feature-xs_reset_watches = "1" (n0,r1) /local/domain/1/data = "" (n1) /local/domain/1/domid = "1" (n0,r1) /local/domain/1/store = "" (n0,r1) /local/domain/1/store/port = "1" (n0,r1) /local/domain/1/store/ring-ref = "6594439" (n0,r1) /local/domain/1/console = "" (n1,r0) /local/domain/1/console/backend = "/local/domain/0/backend/console/1/0" (n1,r0) /local/domain/1/console/backend-id = "0" (n1,r0) /local/domain/1/console/limit = "1048576" (n1,r0) /local/domain/1/console/type = "xenconsoled" (n1,r0) /local/domain/1/console/output = "pty" (n1,r0) /local/domain/1/console/port = "2" (n1,r0) /local/domain/1/console/ring-ref = "6594438" (n1,r0) /local/domain/1/console/tty = "/dev/pts/3" (n1,r0) /vm = "" (n0) /vm/55f79877-0895-400a-97ce-da869599a1ce = "" (n0,r1) /vm/55f79877-0895-400a-97ce-da869599a1ce/uuid = "55f79877-0895-400a-97ce-da869599a1ce" (n0,r1) /vm/55f79877-0895-400a-97ce-da869599a1ce/name = "lightning" (n0,r1) /vm/55f79877-0895-400a-97ce-da869599a1ce/image = "" (n0,r1) /vm/55f79877-0895-400a-97ce-da869599a1ce/image/ostype = "linux" (n0,r1) /vm/55f79877-0895-400a-97ce-da869599a1ce/image/kernel = "/boot/bzImage-domU-oldgame" (n0,r1) /vm/55f79877-0895-400a-97ce-da869599a1ce/image/cmdline = "root=/dev/xvda1 ro console=xvc0 earlyprintk=xen" (n0,r1) /vm/55f79877-0895-400a-97ce-da869599a1ce/start_time = "1349264651.94" (n0,r1) /libxl = "" (n0) /libxl/1 = "" (n0) /libxl/1/dm-version = "qemu_xen" (n0) - Valtteri 2012/10/3 Ian Campbell > On Wed, 2012-10-03 at 12:07 +0100, Valtteri Kiviniemi wrote: > > > > /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2 = "" (n0) > > The interesting stuff will be under /local/domain/0 > and /local/domain/ rather than under /vm. > > The builder logs were the same modulo some insignificant changes. > > Ian. > > --20cf303a2e353ea44104cb262a29 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Ok, well lets do it thisway. Hopefully I got this right this tim= e.

Here is the ALL of the output available from xenstore-ls -fp whe= n I'm only=20 running dom0 and that problematic domU, and when it is launched with Xend a= nd fully working:

root@xen-2:~# xenstore-ls -fp
/tool =3D "&= quot;=A0=A0 (n0)
/tool/xenstored =3D ""=A0=A0 (n0)
/local = =3D ""=A0=A0 (n0)
/local/domain =3D ""=A0=A0 (n0)
/local/domain/0 =3D "&quo= t;=A0=A0 (r0)
/local/domain/0/vm =3D "/vm/00000000-0000-0000-0000-0= 00000000000"=A0=A0 (r0)
/local/domain/0/device =3D ""=A0= =A0 (n0)
/local/domain/0/control =3D ""=A0=A0 (n0)
/local/domain/0/control/platform-feature-multiprocessor-suspend =3D "1= "=A0=A0 (n0)
/local/domain/0/control/platform-feature-xs_reset_watc= hes =3D "1"=A0=A0 (n0)
/local/domain/0/error =3D ""= =A0=A0 (n0)
/local/domain/0/memory =3D ""=A0=A0 (n0)
/local/domain/0/memor= y/target =3D "1310720"=A0=A0 (n0)
/local/domain/0/guest =3D &q= uot;"=A0=A0 (n0)
/local/domain/0/hvmpv =3D ""=A0=A0 (n0)<= br>/local/domain/0/data =3D ""=A0=A0 (n0)
/local/domain/0/cpu =3D ""=A0=A0 (r0)
/local/domain/0/cpu/1 = =3D ""=A0=A0 (r0)
/local/domain/0/cpu/1/availability =3D "= ;online"=A0=A0 (r0)
/local/domain/0/cpu/3 =3D ""=A0=A0 (r= 0)
/local/domain/0/cpu/3/availability =3D "online"=A0=A0 (r0)<= br> /local/domain/0/cpu/2 =3D ""=A0=A0 (r0)
/local/domain/0/cpu/2/= availability =3D "online"=A0=A0 (r0)
/local/domain/0/cpu/4 =3D= ""=A0=A0 (r0)
/local/domain/0/cpu/4/availability =3D "on= line"=A0=A0 (r0)
/local/domain/0/cpu/7 =3D ""=A0=A0 (r0)
/local/domain/0/cpu/7/= availability =3D "online"=A0=A0 (r0)
/local/domain/0/cpu/0 =3D= ""=A0=A0 (r0)
/local/domain/0/cpu/0/availability =3D "on= line"=A0=A0 (r0)
/local/domain/0/cpu/5 =3D ""=A0=A0 (r0)
/local/domain/0/cpu/5/= availability =3D "online"=A0=A0 (r0)
/local/domain/0/cpu/6 =3D= ""=A0=A0 (r0)
/local/domain/0/cpu/6/availability =3D "on= line"=A0=A0 (r0)
/local/domain/0/description =3D ""=A0=A0 (r0)
/local/domain/0/= console =3D ""=A0=A0 (r0)
/local/domain/0/console/limit =3D &q= uot;1048576"=A0=A0 (r0)
/local/domain/0/console/type =3D "xenc= onsoled"=A0=A0 (r0)
/local/domain/0/domid =3D "0"=A0=A0 (r0)
/local/domain/0/name = =3D "Domain-0"=A0=A0 (r0)
/local/domain/0/backend =3D "&q= uot;=A0=A0 (r0)
/local/domain/0/backend/vbd =3D ""=A0=A0 (r0)<= br>/local/domain/0/backend/vbd/9 =3D ""=A0=A0 (r0)
/local/domain/0/backend/vbd/9/51713 =3D ""=A0=A0 (n0,r9)
/loca= l/domain/0/backend/vbd/9/51713/domain =3D "lightning"=A0=A0 (n0,r= 9)
/local/domain/0/backend/vbd/9/51713/frontend =3D "/local/domain/= 9/device/vbd/51713"=A0=A0 (n0,r9)
/local/domain/0/backend/vbd/9/51713/uuid =3D "07c30250-23d0-45dc-a7fd-= 27c4705ab946"=A0=A0 (n0,r9)
/local/domain/0/backend/vbd/9/51713/boo= table =3D "1"=A0=A0 (n0,r9)
/local/domain/0/backend/vbd/9/5171= 3/dev =3D "xvda1"=A0=A0 (n0,r9)
/local/domain/0/backend/vbd/9/51713/state =3D "4"=A0=A0 (n0,r9)/local/domain/0/backend/vbd/9/51713/params =3D "/dev/virtuals/lightn= ing"=A0=A0 (n0,r9)
/local/domain/0/backend/vbd/9/51713/mode =3D &qu= ot;w"=A0=A0 (n0,r9)
/local/domain/0/backend/vbd/9/51713/online =3D "1"=A0=A0 (n0,r9)<= br>/local/domain/0/backend/vbd/9/51713/frontend-id =3D "9"=A0=A0 = (n0,r9)
/local/domain/0/backend/vbd/9/51713/type =3D "phy"=A0= =A0 (n0,r9)
/local/domain/0/backend/vbd/9/51713/physical-device =3D "fd:7"=A0= =A0 (n0,r9)
/local/domain/0/backend/vbd/9/51713/hotplug-status =3D "= ;connected"=A0=A0 (n0,r9)
/local/domain/0/backend/vbd/9/51713/featu= re-flush-cache =3D "1"=A0=A0 (n0,r9)
/local/domain/0/backend/vbd/9/51713/feature-discard =3D "0"=A0=A0= (n0,r9)
/local/domain/0/backend/vbd/9/51713/feature-barrier =3D "1= "=A0=A0 (n0,r9)
/local/domain/0/backend/vbd/9/51713/sectors =3D &qu= ot;104857600"=A0=A0 (n0,r9)
/local/domain/0/backend/vbd/9/51713/info =3D "0"=A0=A0 (n0,r9)/local/domain/0/backend/vbd/9/51713/sector-size =3D "512"=A0=A0 = (n0,r9)
/local/domain/0/backend/vif =3D ""=A0=A0 (r0)
/loca= l/domain/0/backend/vif/9 =3D ""=A0=A0 (r0)
/local/domain/0/backend/vif/9/0 =3D ""=A0=A0 (n0,r9)
/local/do= main/0/backend/vif/9/0/bridge =3D "xenbr0"=A0=A0 (n0,r9)
/loca= l/domain/0/backend/vif/9/0/domain =3D "lightning"=A0=A0 (n0,r9)/local/domain/0/backend/vif/9/0/handle =3D "0"=A0=A0 (n0,r9) /local/domain/0/backend/vif/9/0/uuid =3D "07ba2113-4679-843f-f4d8-eada= ec462af0"=A0=A0 (n0,r9)
/local/domain/0/backend/vif/9/0/script =3D = "/etc/xen/scripts/vif-bridge"=A0=A0 (n0,r9)
/local/domain/0/ba= ckend/vif/9/0/state =3D "4"=A0=A0 (n0,r9)
/local/domain/0/backend/vif/9/0/frontend =3D "/local/domain/9/device/v= if/0"=A0=A0 (n0,r9)
/local/domain/0/backend/vif/9/0/mac =3D "0= 0:16:3e:1d:0d:91"=A0=A0 (n0,r9)
/local/domain/0/backend/vif/9/0/onl= ine =3D "1"=A0=A0 (n0,r9)
/local/domain/0/backend/vif/9/0/frontend-id =3D "9"=A0=A0 (n0,r9)=
/local/domain/0/backend/vif/9/0/feature-sg =3D "1"=A0=A0 (n0,= r9)
/local/domain/0/backend/vif/9/0/feature-gso-tcpv4 =3D "1"= =A0=A0 (n0,r9)
/local/domain/0/backend/vif/9/0/feature-rx-copy =3D "1"=A0=A0 (n0= ,r9)
/local/domain/0/backend/vif/9/0/feature-rx-flip =3D "0"= =A0=A0 (n0,r9)
/local/domain/0/backend/vif/9/0/hotplug-status =3D "= connected"=A0=A0 (n0,r9)
/local/domain/0/backend/console =3D ""=A0=A0 (r0)
/local/domai= n/0/backend/console/9 =3D ""=A0=A0 (r0)
/local/domain/0/backen= d/console/9/0 =3D ""=A0=A0 (n0,r9)
/local/domain/0/backend/con= sole/9/0/domain =3D "lightning"=A0=A0 (n0,r9)
/local/domain/0/backend/console/9/0/protocol =3D "vt100"=A0=A0 (n= 0,r9)
/local/domain/0/backend/console/9/0/uuid =3D "c17b2697-71ba-0= 11d-9958-2094cf39a7e4"=A0=A0 (n0,r9)
/local/domain/0/backend/consol= e/9/0/frontend =3D "/local/domain/9/device/console/0"=A0=A0 (n0,r= 9)
/local/domain/0/backend/console/9/0/state =3D "1"=A0=A0 (n0,r9)/local/domain/0/backend/console/9/0/location =3D "2"=A0=A0 (n0,= r9)
/local/domain/0/backend/console/9/0/online =3D "1"=A0=A0 (= n0,r9)
/local/domain/0/backend/console/9/0/frontend-id =3D "9"= =A0=A0 (n0,r9)
/local/domain/9 =3D ""=A0=A0 (n0,r9)
/local/domain/9/vm =3D &q= uot;/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df"=A0=A0 (n0,r9)
/local/= domain/9/device =3D ""=A0=A0 (n9)
/local/domain/9/device/vbd = =3D ""=A0=A0 (n9)
/local/domain/9/device/vbd/51713 =3D ""=A0=A0 (n9,r0)
/local/d= omain/9/device/vbd/51713/virtual-device =3D "51713"=A0=A0 (n9,r0)=
/local/domain/9/device/vbd/51713/device-type =3D "disk"=A0=A0= (n9,r0)
/local/domain/9/device/vbd/51713/protocol =3D "x86_32-abi&= quot;=A0=A0 (n9,r0)
/local/domain/9/device/vbd/51713/backend-id =3D "0"=A0=A0 (n9,r0)=
/local/domain/9/device/vbd/51713/state =3D "4"=A0=A0 (n9,r0)<= br>/local/domain/9/device/vbd/51713/backend =3D "/local/domain/0/backe= nd/vbd/9/51713"=A0=A0 (n9,r0)
/local/domain/9/device/vbd/51713/ring-ref =3D "8"=A0=A0 (n9,r0)/local/domain/9/device/vbd/51713/event-channel =3D "6"=A0=A0 (n= 9,r0)
/local/domain/9/device/vif =3D ""=A0=A0 (n9)
/local/d= omain/9/device/vif/0 =3D ""=A0=A0 (n9,r0)
/local/domain/9/device/vif/0/mac =3D "00:16:3e:1d:0d:91"=A0=A0 (n= 9,r0)
/local/domain/9/device/vif/0/handle =3D "0"=A0=A0 (n9,r0= )
/local/domain/9/device/vif/0/protocol =3D "x86_32-abi"=A0=A0= (n9,r0)
/local/domain/9/device/vif/0/backend-id =3D "0"=A0=A0= (n9,r0)
/local/domain/9/device/vif/0/state =3D "4"=A0=A0 (n9,r0)
/loca= l/domain/9/device/vif/0/backend =3D "/local/domain/0/backend/vif/9/0&q= uot;=A0=A0 (n9,r0)
/local/domain/9/device/vif/0/tx-ring-ref =3D "52= 1"=A0=A0 (n9,r0)
/local/domain/9/device/vif/0/rx-ring-ref =3D "522"=A0=A0 (n9,r0)<= br>/local/domain/9/device/vif/0/event-channel =3D "7"=A0=A0 (n9,r= 0)
/local/domain/9/device/vif/0/request-rx-copy =3D "1"=A0=A0 = (n9,r0)
/local/domain/9/device/vif/0/feature-rx-notify =3D "1"= =A0=A0 (n9,r0)
/local/domain/9/device/vif/0/feature-sg =3D "1"=A0=A0 (n9,r0)
= /local/domain/9/device/vif/0/feature-gso-tcpv4 =3D "1"=A0=A0 (n9,= r0)
/local/domain/9/device/console =3D ""=A0=A0 (n9)
/local= /domain/9/device/console/0 =3D ""=A0=A0 (n9,r0)
/local/domain/9/device/console/0/protocol =3D "x86_32-abi"=A0=A0 = (n9,r0)
/local/domain/9/device/console/0/state =3D "1"=A0=A0 (= n9,r0)
/local/domain/9/device/console/0/backend-id =3D "0"=A0= =A0 (n9,r0)
/local/domain/9/device/console/0/backend =3D "/local/domain/0/backend/= console/9/0"=A0=A0 (n9,r0)
/local/domain/9/control =3D ""= =A0=A0 (n9)
/local/domain/9/control/platform-feature-multiprocessor-susp= end =3D "1"=A0=A0 (n9)
/local/domain/9/control/platform-feature-xs_reset_watches =3D "1"= =A0=A0 (n9)
/local/domain/9/control/feature-reboot =3D "1"=A0= =A0 (n9)
/local/domain/9/control/feature-sysrq =3D "1"=A0=A0 (= n9)
/local/domain/9/error =3D ""=A0=A0 (n9)
/local/domain/9/memory =3D ""=A0=A0 (n9)
/local/domain/9/memor= y/target =3D "2097152"=A0=A0 (n9)
/local/domain/9/guest =3D &q= uot;"=A0=A0 (n9)
/local/domain/9/hvmpv =3D ""=A0=A0 (n9)<= br>/local/domain/9/data =3D ""=A0=A0 (n9)
/local/domain/9/device-misc =3D ""=A0=A0 (n0,r9)
/local/domain= /9/device-misc/vif =3D ""=A0=A0 (n0,r9)
/local/domain/9/device= -misc/vif/nextDeviceID =3D "1"=A0=A0 (n0,r9)
/local/domain/9/d= evice-misc/console =3D ""=A0=A0 (n0,r9)
/local/domain/9/device-misc/console/nextDeviceID =3D "1"=A0=A0 (n= 0,r9)
/local/domain/9/console =3D ""=A0=A0 (n0,r9)
/local/d= omain/9/console/ring-ref =3D "7027814"=A0=A0 (n0,r9)
/local/do= main/9/console/port =3D "2"=A0=A0 (n0,r9)
/local/domain/9/console/limit =3D "1048576"=A0=A0 (n0,r9)
/loc= al/domain/9/console/type =3D "xenconsoled"=A0=A0 (n0,r9)
/loca= l/domain/9/console/tty =3D "/dev/pts/2"=A0=A0 (n0,r9)
/local/d= omain/9/image =3D ""=A0=A0 (n0,r9)
/local/domain/9/image/entry =3D "3222274048"=A0=A0 (n0,r9)
/lo= cal/domain/9/image/loader =3D "generic"=A0=A0 (n0,r9)
/local/d= omain/9/image/hv-start-low =3D "4118806528"=A0=A0 (n0,r9)
/loc= al/domain/9/image/guest-os =3D "linux"=A0=A0 (n0,r9)
/local/domain/9/image/features =3D ""=A0=A0 (n0,r9)
/local/dom= ain/9/image/features/writable-descriptor-tables =3D "1"=A0=A0 (n0= ,r9)
/local/domain/9/image/features/supervisor-mode-kernel =3D "1&q= uot;=A0=A0 (n0,r9)
/local/domain/9/image/features/pae-pgdir-above-4gb =3D "1"=A0=A0 = (n0,r9)
/local/domain/9/image/features/writable-page-tables =3D "1&= quot;=A0=A0 (n0,r9)
/local/domain/9/image/features/auto-translated-physm= ap =3D "1"=A0=A0 (n0,r9)
/local/domain/9/image/hypercall-page =3D "3222278144"=A0=A0 (n0,r= 9)
/local/domain/9/image/guest-version =3D "2.6"=A0=A0 (n0,r9)=
/local/domain/9/image/pae-mode =3D "yes"=A0=A0 (n0,r9)
/lo= cal/domain/9/image/paddr-offset =3D "3221225472"=A0=A0 (n0,r9) /local/domain/9/image/virt-base =3D "3221225472"=A0=A0 (n0,r9)/local/domain/9/image/xen-version =3D "xen-3.0"=A0=A0 (n0,r9)/local/domain/9/store =3D ""=A0=A0 (n0,r9)
/local/domain/9/st= ore/ring-ref =3D "7027815"=A0=A0 (n0,r9)
/local/domain/9/store/port =3D "1"=A0=A0 (n0,r9)
/local/domain= /9/description =3D ""=A0=A0 (n0,r9)
/local/domain/9/cpu =3D &q= uot;"=A0=A0 (n0,r9)
/local/domain/9/cpu/0 =3D ""=A0=A0 (n= 0,r9)
/local/domain/9/cpu/0/availability =3D "online"=A0=A0 (n= 0,r9)
/local/domain/9/name =3D "lightning"=A0=A0 (n0,r9)
/local/doma= in/9/domid =3D "9"=A0=A0 (n0,r9)
/local/pool =3D ""= =A0=A0 (n0)
/local/pool/0 =3D ""=A0=A0 (n0)
/local/pool/0/o= ther_config =3D ""=A0=A0 (n0)
/local/pool/0/description =3D "Pool-0"=A0=A0 (n0)
/local/pool/= 0/uuid =3D "caa85392-7062-bd40-53ee-fd3a7c1a1a6f"=A0=A0 (n0)
/= local/pool/0/name =3D "Pool-0"=A0=A0 (n0)
/vm =3D ""= =A0=A0 (n0)
/vm/00000000-0000-0000-0000-000000000000 =3D ""=A0= =A0 (n0)
/vm/00000000-0000-0000-0000-000000000000/on_xend_stop =3D "ignore"= ;=A0=A0 (n0)
/vm/00000000-0000-0000-0000-000000000000/pool_name =3D &quo= t;Pool-0"=A0=A0 (n0)
/vm/00000000-0000-0000-0000-000000000000/shado= w_memory =3D "0"=A0=A0 (n0)
/vm/00000000-0000-0000-0000-000000000000/uuid =3D "00000000-0000-0000-= 0000-000000000000"=A0=A0 (r0)
/vm/00000000-0000-0000-0000-000000000= 000/on_reboot =3D "restart"=A0=A0 (n0)
/vm/00000000-0000-0000-= 0000-000000000000/image =3D "(linux (kernel '') (superpages 0)= (nomigrate 0) (tsc_mode 0))"=A0=A0 (n0)
/vm/00000000-0000-0000-0000-000000000000/image/ostype =3D "linux"= =A0=A0 (n0)
/vm/00000000-0000-0000-0000-000000000000/image/kernel =3D &q= uot;"=A0=A0 (n0)
/vm/00000000-0000-0000-0000-000000000000/image/cmd= line =3D ""=A0=A0 (r0)
/vm/00000000-0000-0000-0000-000000000000/image/ramdisk =3D ""=A0= =A0 (n0)
/vm/00000000-0000-0000-0000-000000000000/on_poweroff =3D "= destroy"=A0=A0 (n0)
/vm/00000000-0000-0000-0000-000000000000/bootlo= ader_args =3D ""=A0=A0 (n0)
/vm/00000000-0000-0000-0000-000000000000/on_xend_start =3D "ignore&quo= t;=A0=A0 (n0)
/vm/00000000-0000-0000-0000-000000000000/on_crash =3D &quo= t;restart"=A0=A0 (n0)
/vm/00000000-0000-0000-0000-000000000000/xend= =3D ""=A0=A0 (n0)
/vm/00000000-0000-0000-0000-000000000000/xend/restart_count =3D "0&quo= t;=A0=A0 (n0)
/vm/00000000-0000-0000-0000-000000000000/vcpus =3D "8= "=A0=A0 (n0)
/vm/00000000-0000-0000-0000-000000000000/vcpu_avail = =3D "255"=A0=A0 (n0)
/vm/00000000-0000-0000-0000-000000000000/bootloader =3D ""=A0=A0 = (n0)
/vm/00000000-0000-0000-0000-000000000000/name =3D "Domain-0&qu= ot;=A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df =3D ""= =A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/image =3D "(linux (kernel /bo= ot/bzImage-domU-oldgame) (args 'root=3D/dev/xvda1 ro console=3Dxvc0 ear= lyprintk=3Dxen') (superpages 0) (videoram 4) (pci ()) (nomigrate 0) (ts= c_mode 0) (notes (HV_START_LOW 411880652\..."=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/image/ostype =3D "linux"= =A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/image/kernel =3D &q= uot;/boot/bzImage-domU-oldgame"=A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-9= 8df-d7f2f6e062df/image/cmdline =3D "root=3D/dev/xvda1 ro console=3Dxvc= 0 earlyprintk=3Dxen"=A0=A0 (n0,r9)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/image/ramdisk =3D ""=A0= =A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device =3D ""= ;=A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/vbd =3D &qu= ot;"=A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/vbd/51713 =3D ""= =A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/vbd/51713/fr= ontend =3D "/local/domain/9/device/vbd/51713"=A0=A0 (n0)
/vm/f= 73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/vbd/51713/frontend-id =3D "= 9"=A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/vbd/51713/backend-id =3D &q= uot;0"=A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/v= bd/51713/backend =3D "/local/domain/0/backend/vbd/9/51713"=A0=A0 = (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/vif =3D ""=A0=A0 = (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/vif/0 =3D "&qu= ot;=A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/vif/0/fro= ntend =3D "/local/domain/9/device/vif/0"=A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/vif/0/frontend-id =3D "= ;9"=A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/vif/= 0/backend-id =3D "0"=A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7= f2f6e062df/device/vif/0/backend =3D "/local/domain/0/backend/vif/9/0&q= uot;=A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/console =3D ""=A0= =A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/console/0 =3D &= quot;"=A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/c= onsole/0/frontend =3D "/local/domain/9/device/console/0"=A0=A0 (n= 0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/console/0/frontend-id =3D &= quot;9"=A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/= console/0/backend-id =3D "0"=A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58= -98df-d7f2f6e062df/device/console/0/backend =3D "/local/domain/0/backe= nd/console/9/0"=A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/on_xend_stop =3D "ignore"= ;=A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/pool_name =3D &quo= t;Pool-0"=A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/shado= w_memory =3D "0"=A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/uuid =3D "f73e32ee-c0ee-2d58-= 98df-d7f2f6e062df"=A0=A0 (n0,r9)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6= e062df/on_reboot =3D "restart"=A0=A0 (n0)
/vm/f73e32ee-c0ee-2d= 58-98df-d7f2f6e062df/start_time =3D "1349264227.39"=A0=A0 (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/on_poweroff =3D "destroy"= ;=A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/bootloader_args = =3D ""=A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/on_= xend_start =3D "ignore"=A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/on_crash =3D "preserve"= =A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/xend =3D "&quo= t;=A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/xend/restart_coun= t =3D "0"=A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/vcpus =3D "1"=A0=A0 (n0)=
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/vcpu_avail =3D "1"= =A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/bootloader =3D &quo= t;"=A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/name =3D "lightning"=A0= =A0 (n0)

...And Here is the ALL of the output available from xenstor= e-ls -fp when I'm only=20 running dom0 and that problematic domU and when it is launched with xl and = crashed (preserved):

root@xen-2:~# xenstore-ls -fp
/tool =3D &quo= t;"=A0=A0 (n0)
/tool/xenstored =3D ""=A0=A0 (n0)
/loca= l =3D ""=A0=A0 (n0)
/local/domain =3D ""=A0=A0 (n0)
/local/domain/0 =3D "&quo= t;=A0=A0 (n0)
/local/domain/0/name =3D "Domain-0"=A0=A0 (n0)/local/domain/0/device-model =3D ""=A0=A0 (n0)
/local/domain= /0/device-model/0 =3D ""=A0=A0 (n0)
/local/domain/0/device-model/0/state =3D "running"=A0=A0 (n0)
= /local/domain/0/libxl =3D ""=A0=A0 (n0)
/local/domain/0/libxl/= disable_udev =3D "1"=A0=A0 (n0)
/local/domain/0/backend =3D &q= uot;"=A0=A0 (n0)
/local/domain/0/backend/vbd =3D ""=A0=A0 (n0)
/local/domain/0/= backend/vbd/1 =3D ""=A0=A0 (n0)
/local/domain/0/backend/vbd/1/= 51713 =3D ""=A0=A0 (n0,r1)
/local/domain/0/backend/vbd/1/51713= /frontend =3D "/local/domain/1/device/vbd/51713"=A0=A0 (n0,r1) /local/domain/0/backend/vbd/1/51713/params =3D "/dev/virtuals/lightnin= g"=A0=A0 (n0,r1)
/local/domain/0/backend/vbd/1/51713/script =3D &qu= ot;/etc/xen/scripts/block"=A0=A0 (n0,r1)
/local/domain/0/backend/vb= d/1/51713/physical-device =3D "fd:7"=A0=A0 (n0,r1)
/local/domain/0/backend/vbd/1/51713/frontend-id =3D "1"=A0=A0 (n0= ,r1)
/local/domain/0/backend/vbd/1/51713/online =3D "1"=A0=A0 = (n0,r1)
/local/domain/0/backend/vbd/1/51713/removable =3D "0"= =A0=A0 (n0,r1)
/local/domain/0/backend/vbd/1/51713/bootable =3D "1"=A0=A0 (n0,r1= )
/local/domain/0/backend/vbd/1/51713/state =3D "4"=A0=A0 (n0,= r1)
/local/domain/0/backend/vbd/1/51713/dev =3D "xvda1"=A0=A0 = (n0,r1)
/local/domain/0/backend/vbd/1/51713/type =3D "phy"=A0= =A0 (n0,r1)
/local/domain/0/backend/vbd/1/51713/mode =3D "w"=A0=A0 (n0,r1)/local/domain/0/backend/vbd/1/51713/device-type =3D "disk"=A0=A0= (n0,r1)
/local/domain/0/backend/vbd/1/51713/feature-flush-cache =3D &qu= ot;1"=A0=A0 (n0,r1)
/local/domain/0/backend/vbd/1/51713/feature-discard =3D "0"=A0=A0= (n0,r1)
/local/domain/0/backend/vbd/1/51713/feature-barrier =3D "1= "=A0=A0 (n0,r1)
/local/domain/0/backend/vbd/1/51713/sectors =3D &qu= ot;104857600"=A0=A0 (n0,r1)
/local/domain/0/backend/vbd/1/51713/info =3D "0"=A0=A0 (n0,r1)/local/domain/0/backend/vbd/1/51713/sector-size =3D "512"=A0=A0 = (n0,r1)
/local/domain/0/backend/console =3D ""=A0=A0 (n0)
/= local/domain/0/backend/console/1 =3D ""=A0=A0 (n0)
/local/domain/0/backend/console/1/0 =3D ""=A0=A0 (n0,r1)
/loca= l/domain/0/backend/console/1/0/frontend =3D "/local/domain/1/console&q= uot;=A0=A0 (n0,r1)
/local/domain/0/backend/console/1/0/frontend-id =3D &= quot;1"=A0=A0 (n0,r1)
/local/domain/0/backend/console/1/0/online =3D "1"=A0=A0 (n0,r1)<= br>/local/domain/0/backend/console/1/0/state =3D "1"=A0=A0 (n0,r1= )
/local/domain/0/backend/console/1/0/domain =3D "lightning"= =A0=A0 (n0,r1)
/local/domain/0/backend/console/1/0/protocol =3D "vt100"=A0=A0 (n= 0,r1)
/local/domain/0/backend/vif =3D ""=A0=A0 (n0)
/local/= domain/0/backend/vif/1 =3D ""=A0=A0 (n0)
/local/domain/0/backe= nd/vif/1/0 =3D ""=A0=A0 (n0,r1)
/local/domain/0/backend/vif/1/0/frontend =3D "/local/domain/1/device/v= if/0"=A0=A0 (n0,r1)
/local/domain/0/backend/vif/1/0/frontend-id =3D= "1"=A0=A0 (n0,r1)
/local/domain/0/backend/vif/1/0/online =3D = "1"=A0=A0 (n0,r1)
/local/domain/0/backend/vif/1/0/state =3D "4"=A0=A0 (n0,r1)
/l= ocal/domain/0/backend/vif/1/0/script =3D "/etc/xen/scripts/vif-bridge&= quot;=A0=A0 (n0,r1)
/local/domain/0/backend/vif/1/0/mac =3D "00:16:= 3e:1d:0d:91"=A0=A0 (n0,r1)
/local/domain/0/backend/vif/1/0/bridge =3D "xenbr0"=A0=A0 (n0,r1)=
/local/domain/0/backend/vif/1/0/handle =3D "0"=A0=A0 (n0,r1)<= br>/local/domain/0/backend/vif/1/0/type =3D "vif"=A0=A0 (n0,r1)/local/domain/0/backend/vif/1/0/feature-sg =3D "1"=A0=A0 (n0,r1= )
/local/domain/0/backend/vif/1/0/feature-gso-tcpv4 =3D "1"=A0=A0 (= n0,r1)
/local/domain/0/backend/vif/1/0/feature-rx-copy =3D "1"= =A0=A0 (n0,r1)
/local/domain/0/backend/vif/1/0/feature-rx-flip =3D "= ;0"=A0=A0 (n0,r1)
/local/domain/0/backend/vif/1/0/hotplug-status =3D "connected"=A0= =A0 (n0,r1)
/local/domain/1 =3D ""=A0=A0 (n0,r1)
/local/dom= ain/1/vm =3D "/vm/55f79877-0895-400a-97ce-da869599a1ce"=A0=A0 (n0= ,r1)
/local/domain/1/name =3D "lightning"=A0=A0 (n0,r1)
/local/domain/1/cpu =3D ""=A0=A0 (n0,r1)
/local/domain/1/cpu/0= =3D ""=A0=A0 (n0,r1)
/local/domain/1/cpu/0/availability =3D &= quot;online"=A0=A0 (n0,r1)
/local/domain/1/memory =3D ""= =A0=A0 (n0,r1)
/local/domain/1/memory/static-max =3D "2097152"= =A0=A0 (n0,r1)
/local/domain/1/memory/target =3D "2097153"=A0=A0 (n0,r1)
/loc= al/domain/1/memory/videoram =3D "-1"=A0=A0 (n0,r1)
/local/doma= in/1/device =3D ""=A0=A0 (n0,r1)
/local/domain/1/device/suspen= d =3D ""=A0=A0 (n0,r1)
/local/domain/1/device/suspend/event-channel =3D ""=A0=A0 (n1)/local/domain/1/device/vbd =3D ""=A0=A0 (n0,r1)
/local/domain= /1/device/vbd/51713 =3D ""=A0=A0 (n1,r0)
/local/domain/1/devic= e/vbd/51713/backend =3D "/local/domain/0/backend/vbd/1/51713"=A0= =A0 (n1,r0)
/local/domain/1/device/vbd/51713/backend-id =3D "0"=A0=A0 (n1,r0)=
/local/domain/1/device/vbd/51713/state =3D "4"=A0=A0 (n1,r0)<= br>/local/domain/1/device/vbd/51713/virtual-device =3D "51713"=A0= =A0 (n1,r0)
/local/domain/1/device/vbd/51713/device-type =3D "disk"=A0=A0 (n1= ,r0)
/local/domain/1/device/vbd/51713/ring-ref =3D "8"=A0=A0 (= n1,r0)
/local/domain/1/device/vbd/51713/event-channel =3D "6"= =A0=A0 (n1,r0)
/local/domain/1/device/vif =3D ""=A0=A0 (n0,r1)
/local/domain/= 1/device/vif/0 =3D ""=A0=A0 (n1,r0)
/local/domain/1/device/vif= /0/backend =3D "/local/domain/0/backend/vif/1/0"=A0=A0 (n1,r0)/local/domain/1/device/vif/0/backend-id =3D "0"=A0=A0 (n1,r0) /local/domain/1/device/vif/0/state =3D "4"=A0=A0 (n1,r0)
/loca= l/domain/1/device/vif/0/handle =3D "0"=A0=A0 (n1,r0)
/local/do= main/1/device/vif/0/mac =3D "00:16:3e:1d:0d:91"=A0=A0 (n1,r0)
= /local/domain/1/device/vif/0/tx-ring-ref =3D "521"=A0=A0 (n1,r0)<= br> /local/domain/1/device/vif/0/rx-ring-ref =3D "522"=A0=A0 (n1,r0)<= br>/local/domain/1/device/vif/0/event-channel =3D "7"=A0=A0 (n1,r= 0)
/local/domain/1/device/vif/0/request-rx-copy =3D "1"=A0=A0 = (n1,r0)
/local/domain/1/device/vif/0/feature-rx-notify =3D "1"= =A0=A0 (n1,r0)
/local/domain/1/device/vif/0/feature-sg =3D "1"=A0=A0 (n1,r0)
= /local/domain/1/device/vif/0/feature-gso-tcpv4 =3D "1"=A0=A0 (n1,= r0)
/local/domain/1/control =3D ""=A0=A0 (n0,r1)
/local/dom= ain/1/control/shutdown =3D ""=A0=A0 (n1)
/local/domain/1/control/platform-feature-multiprocessor-suspend =3D "1= "=A0=A0 (n0,r1)
/local/domain/1/control/platform-feature-xs_reset_w= atches =3D "1"=A0=A0 (n0,r1)
/local/domain/1/data =3D "&q= uot;=A0=A0 (n1)
/local/domain/1/domid =3D "1"=A0=A0 (n0,r1)
/local/domain/1/st= ore =3D ""=A0=A0 (n0,r1)
/local/domain/1/store/port =3D "= 1"=A0=A0 (n0,r1)
/local/domain/1/store/ring-ref =3D "6594439&q= uot;=A0=A0 (n0,r1)
/local/domain/1/console =3D ""=A0=A0 (n1,r0)
/local/domain/1/c= onsole/backend =3D "/local/domain/0/backend/console/1/0"=A0=A0 (n= 1,r0)
/local/domain/1/console/backend-id =3D "0"=A0=A0 (n1,r0)=
/local/domain/1/console/limit =3D "1048576"=A0=A0 (n1,r0)
/local/domain/1/console/type =3D "xenconsoled"=A0=A0 (n1,r0)
/= local/domain/1/console/output =3D "pty"=A0=A0 (n1,r0)
/local/d= omain/1/console/port =3D "2"=A0=A0 (n1,r0)
/local/domain/1/con= sole/ring-ref =3D "6594438"=A0=A0 (n1,r0)
/local/domain/1/console/tty =3D "/dev/pts/3"=A0=A0 (n1,r0)
/vm= =3D ""=A0=A0 (n0)
/vm/55f79877-0895-400a-97ce-da869599a1ce = =3D ""=A0=A0 (n0,r1)
/vm/55f79877-0895-400a-97ce-da869599a1ce/= uuid =3D "55f79877-0895-400a-97ce-da869599a1ce"=A0=A0 (n0,r1)
/vm/55f79877-0895-400a-97ce-da869599a1ce/name =3D "lightning"=A0= =A0 (n0,r1)
/vm/55f79877-0895-400a-97ce-da869599a1ce/image =3D "&qu= ot;=A0=A0 (n0,r1)
/vm/55f79877-0895-400a-97ce-da869599a1ce/image/ostype = =3D "linux"=A0=A0 (n0,r1)
/vm/55f79877-0895-400a-97ce-da869599a1ce/image/kernel =3D "/boot/bzIma= ge-domU-oldgame"=A0=A0 (n0,r1)
/vm/55f79877-0895-400a-97ce-da869599= a1ce/image/cmdline =3D "root=3D/dev/xvda1 ro console=3Dxvc0 earlyprint= k=3Dxen"=A0=A0 (n0,r1)
/vm/55f79877-0895-400a-97ce-da869599a1ce/start_time =3D "1349264651.94= "=A0=A0 (n0,r1)
/libxl =3D ""=A0=A0 (n0)
/libxl/1 =3D = ""=A0=A0 (n0)
/libxl/1/dm-version =3D "qemu_xen"=A0= =A0 (n0)

- Valtteri

2012/10/3 Ian Campbell <= ;Ian.Campbell@= citrix.com>
On Wed, 2012-10-03 at 12:07 +0100, Valtteri Kiviniemi wrote:
>
> /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2 =3D "" =A0 (n0)

The interesting stuff will be under /local/domain/0
and /local/domain/<domU> rather than under /vm.

The builder logs were the same modulo some insignificant changes.

Ian.


--20cf303a2e353ea44104cb262a29-- --===============2788042825860687498== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============2788042825860687498==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 11:45:22 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 11:45:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJNNk-00089z-Rw; Wed, 03 Oct 2012 11:44:52 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJNNj-00089u-EY for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 11:44:52 +0000 Received: from [85.158.137.99:13628] by server-11.bemta-3.messagelabs.com id F4/7F-21460-1352C605; Wed, 03 Oct 2012 11:44:49 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-3.tower-217.messagelabs.com!1349264685!15042781!1 X-Originating-IP: [209.85.213.173] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28448 invoked from network); 3 Oct 2012 11:44:46 -0000 Received: from mail-yx0-f173.google.com (HELO mail-yx0-f173.google.com) (209.85.213.173) by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 11:44:46 -0000 Received: by yenl3 with SMTP id l3so2195695yen.32 for ; Wed, 03 Oct 2012 04:44:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EBaMR2gFY4ZDMbVxvZ9PYUEjD61O/h0GK3S7JHAQ5PU=; b=HOeUEgvel4LX7RUWY1JYV7QPTS73WxYbF4FO0cKDMkOWtsIDufA5yZXqXPiQw0Cggh k3bGU8XSCevNlrWevx7rJkE++1NJmFxvadNtGG3SGjvmJJzQ8u2GJ7BhDnrfhEjUgL8t I5QVQpQpwt3ZFkgoTeiF3B6Mhhn6rCGybv9OkzpPTtvHcPW6vUz+UxaS9AE7gtytNmSV 0IzDdeERpsB4jDJeEV0Er9rx6XC6kSMfUIF7V0VbOt8WGtV5gP4z1Ry23yGvMveehBdU SA24fnChUYZyRnHs8uJzUWIcUpCNA2Jz1XNJwlWUacN1ws23LV3j2ZiRj0PYBPykxko+ HVMw== MIME-Version: 1.0 Received: by 10.236.151.99 with SMTP id a63mr1443385yhk.120.1349264684786; Wed, 03 Oct 2012 04:44:44 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Wed, 3 Oct 2012 04:44:44 -0700 (PDT) In-Reply-To: <1349263669.650.131.camel@zakaz.uk.xensource.com> References: <1349259542.650.122.camel@zakaz.uk.xensource.com> <1349261397.650.130.camel@zakaz.uk.xensource.com> <1349263669.650.131.camel@zakaz.uk.xensource.com> Date: Wed, 3 Oct 2012 14:44:44 +0300 Message-ID: From: Valtteri Kiviniemi To: Ian Campbell Cc: "Xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Xen 4.2.0, xl toolstack cant launch older domUs X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2788042825860687498==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============2788042825860687498== Content-Type: multipart/alternative; boundary=20cf303a2e353ea44104cb262a29 --20cf303a2e353ea44104cb262a29 Content-Type: text/plain; charset=ISO-8859-1 Hi, Ok, well lets do it thisway. Hopefully I got this right this time. Here is the ALL of the output available from xenstore-ls -fp when I'm only running dom0 and that problematic domU, and when it is launched with Xend and fully working: root@xen-2:~# xenstore-ls -fp /tool = "" (n0) /tool/xenstored = "" (n0) /local = "" (n0) /local/domain = "" (n0) /local/domain/0 = "" (r0) /local/domain/0/vm = "/vm/00000000-0000-0000-0000-000000000000" (r0) /local/domain/0/device = "" (n0) /local/domain/0/control = "" (n0) /local/domain/0/control/platform-feature-multiprocessor-suspend = "1" (n0) /local/domain/0/control/platform-feature-xs_reset_watches = "1" (n0) /local/domain/0/error = "" (n0) /local/domain/0/memory = "" (n0) /local/domain/0/memory/target = "1310720" (n0) /local/domain/0/guest = "" (n0) /local/domain/0/hvmpv = "" (n0) /local/domain/0/data = "" (n0) /local/domain/0/cpu = "" (r0) /local/domain/0/cpu/1 = "" (r0) /local/domain/0/cpu/1/availability = "online" (r0) /local/domain/0/cpu/3 = "" (r0) /local/domain/0/cpu/3/availability = "online" (r0) /local/domain/0/cpu/2 = "" (r0) /local/domain/0/cpu/2/availability = "online" (r0) /local/domain/0/cpu/4 = "" (r0) /local/domain/0/cpu/4/availability = "online" (r0) /local/domain/0/cpu/7 = "" (r0) /local/domain/0/cpu/7/availability = "online" (r0) /local/domain/0/cpu/0 = "" (r0) /local/domain/0/cpu/0/availability = "online" (r0) /local/domain/0/cpu/5 = "" (r0) /local/domain/0/cpu/5/availability = "online" (r0) /local/domain/0/cpu/6 = "" (r0) /local/domain/0/cpu/6/availability = "online" (r0) /local/domain/0/description = "" (r0) /local/domain/0/console = "" (r0) /local/domain/0/console/limit = "1048576" (r0) /local/domain/0/console/type = "xenconsoled" (r0) /local/domain/0/domid = "0" (r0) /local/domain/0/name = "Domain-0" (r0) /local/domain/0/backend = "" (r0) /local/domain/0/backend/vbd = "" (r0) /local/domain/0/backend/vbd/9 = "" (r0) /local/domain/0/backend/vbd/9/51713 = "" (n0,r9) /local/domain/0/backend/vbd/9/51713/domain = "lightning" (n0,r9) /local/domain/0/backend/vbd/9/51713/frontend = "/local/domain/9/device/vbd/51713" (n0,r9) /local/domain/0/backend/vbd/9/51713/uuid = "07c30250-23d0-45dc-a7fd-27c4705ab946" (n0,r9) /local/domain/0/backend/vbd/9/51713/bootable = "1" (n0,r9) /local/domain/0/backend/vbd/9/51713/dev = "xvda1" (n0,r9) /local/domain/0/backend/vbd/9/51713/state = "4" (n0,r9) /local/domain/0/backend/vbd/9/51713/params = "/dev/virtuals/lightning" (n0,r9) /local/domain/0/backend/vbd/9/51713/mode = "w" (n0,r9) /local/domain/0/backend/vbd/9/51713/online = "1" (n0,r9) /local/domain/0/backend/vbd/9/51713/frontend-id = "9" (n0,r9) /local/domain/0/backend/vbd/9/51713/type = "phy" (n0,r9) /local/domain/0/backend/vbd/9/51713/physical-device = "fd:7" (n0,r9) /local/domain/0/backend/vbd/9/51713/hotplug-status = "connected" (n0,r9) /local/domain/0/backend/vbd/9/51713/feature-flush-cache = "1" (n0,r9) /local/domain/0/backend/vbd/9/51713/feature-discard = "0" (n0,r9) /local/domain/0/backend/vbd/9/51713/feature-barrier = "1" (n0,r9) /local/domain/0/backend/vbd/9/51713/sectors = "104857600" (n0,r9) /local/domain/0/backend/vbd/9/51713/info = "0" (n0,r9) /local/domain/0/backend/vbd/9/51713/sector-size = "512" (n0,r9) /local/domain/0/backend/vif = "" (r0) /local/domain/0/backend/vif/9 = "" (r0) /local/domain/0/backend/vif/9/0 = "" (n0,r9) /local/domain/0/backend/vif/9/0/bridge = "xenbr0" (n0,r9) /local/domain/0/backend/vif/9/0/domain = "lightning" (n0,r9) /local/domain/0/backend/vif/9/0/handle = "0" (n0,r9) /local/domain/0/backend/vif/9/0/uuid = "07ba2113-4679-843f-f4d8-eadaec462af0" (n0,r9) /local/domain/0/backend/vif/9/0/script = "/etc/xen/scripts/vif-bridge" (n0,r9) /local/domain/0/backend/vif/9/0/state = "4" (n0,r9) /local/domain/0/backend/vif/9/0/frontend = "/local/domain/9/device/vif/0" (n0,r9) /local/domain/0/backend/vif/9/0/mac = "00:16:3e:1d:0d:91" (n0,r9) /local/domain/0/backend/vif/9/0/online = "1" (n0,r9) /local/domain/0/backend/vif/9/0/frontend-id = "9" (n0,r9) /local/domain/0/backend/vif/9/0/feature-sg = "1" (n0,r9) /local/domain/0/backend/vif/9/0/feature-gso-tcpv4 = "1" (n0,r9) /local/domain/0/backend/vif/9/0/feature-rx-copy = "1" (n0,r9) /local/domain/0/backend/vif/9/0/feature-rx-flip = "0" (n0,r9) /local/domain/0/backend/vif/9/0/hotplug-status = "connected" (n0,r9) /local/domain/0/backend/console = "" (r0) /local/domain/0/backend/console/9 = "" (r0) /local/domain/0/backend/console/9/0 = "" (n0,r9) /local/domain/0/backend/console/9/0/domain = "lightning" (n0,r9) /local/domain/0/backend/console/9/0/protocol = "vt100" (n0,r9) /local/domain/0/backend/console/9/0/uuid = "c17b2697-71ba-011d-9958-2094cf39a7e4" (n0,r9) /local/domain/0/backend/console/9/0/frontend = "/local/domain/9/device/console/0" (n0,r9) /local/domain/0/backend/console/9/0/state = "1" (n0,r9) /local/domain/0/backend/console/9/0/location = "2" (n0,r9) /local/domain/0/backend/console/9/0/online = "1" (n0,r9) /local/domain/0/backend/console/9/0/frontend-id = "9" (n0,r9) /local/domain/9 = "" (n0,r9) /local/domain/9/vm = "/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df" (n0,r9) /local/domain/9/device = "" (n9) /local/domain/9/device/vbd = "" (n9) /local/domain/9/device/vbd/51713 = "" (n9,r0) /local/domain/9/device/vbd/51713/virtual-device = "51713" (n9,r0) /local/domain/9/device/vbd/51713/device-type = "disk" (n9,r0) /local/domain/9/device/vbd/51713/protocol = "x86_32-abi" (n9,r0) /local/domain/9/device/vbd/51713/backend-id = "0" (n9,r0) /local/domain/9/device/vbd/51713/state = "4" (n9,r0) /local/domain/9/device/vbd/51713/backend = "/local/domain/0/backend/vbd/9/51713" (n9,r0) /local/domain/9/device/vbd/51713/ring-ref = "8" (n9,r0) /local/domain/9/device/vbd/51713/event-channel = "6" (n9,r0) /local/domain/9/device/vif = "" (n9) /local/domain/9/device/vif/0 = "" (n9,r0) /local/domain/9/device/vif/0/mac = "00:16:3e:1d:0d:91" (n9,r0) /local/domain/9/device/vif/0/handle = "0" (n9,r0) /local/domain/9/device/vif/0/protocol = "x86_32-abi" (n9,r0) /local/domain/9/device/vif/0/backend-id = "0" (n9,r0) /local/domain/9/device/vif/0/state = "4" (n9,r0) /local/domain/9/device/vif/0/backend = "/local/domain/0/backend/vif/9/0" (n9,r0) /local/domain/9/device/vif/0/tx-ring-ref = "521" (n9,r0) /local/domain/9/device/vif/0/rx-ring-ref = "522" (n9,r0) /local/domain/9/device/vif/0/event-channel = "7" (n9,r0) /local/domain/9/device/vif/0/request-rx-copy = "1" (n9,r0) /local/domain/9/device/vif/0/feature-rx-notify = "1" (n9,r0) /local/domain/9/device/vif/0/feature-sg = "1" (n9,r0) /local/domain/9/device/vif/0/feature-gso-tcpv4 = "1" (n9,r0) /local/domain/9/device/console = "" (n9) /local/domain/9/device/console/0 = "" (n9,r0) /local/domain/9/device/console/0/protocol = "x86_32-abi" (n9,r0) /local/domain/9/device/console/0/state = "1" (n9,r0) /local/domain/9/device/console/0/backend-id = "0" (n9,r0) /local/domain/9/device/console/0/backend = "/local/domain/0/backend/console/9/0" (n9,r0) /local/domain/9/control = "" (n9) /local/domain/9/control/platform-feature-multiprocessor-suspend = "1" (n9) /local/domain/9/control/platform-feature-xs_reset_watches = "1" (n9) /local/domain/9/control/feature-reboot = "1" (n9) /local/domain/9/control/feature-sysrq = "1" (n9) /local/domain/9/error = "" (n9) /local/domain/9/memory = "" (n9) /local/domain/9/memory/target = "2097152" (n9) /local/domain/9/guest = "" (n9) /local/domain/9/hvmpv = "" (n9) /local/domain/9/data = "" (n9) /local/domain/9/device-misc = "" (n0,r9) /local/domain/9/device-misc/vif = "" (n0,r9) /local/domain/9/device-misc/vif/nextDeviceID = "1" (n0,r9) /local/domain/9/device-misc/console = "" (n0,r9) /local/domain/9/device-misc/console/nextDeviceID = "1" (n0,r9) /local/domain/9/console = "" (n0,r9) /local/domain/9/console/ring-ref = "7027814" (n0,r9) /local/domain/9/console/port = "2" (n0,r9) /local/domain/9/console/limit = "1048576" (n0,r9) /local/domain/9/console/type = "xenconsoled" (n0,r9) /local/domain/9/console/tty = "/dev/pts/2" (n0,r9) /local/domain/9/image = "" (n0,r9) /local/domain/9/image/entry = "3222274048" (n0,r9) /local/domain/9/image/loader = "generic" (n0,r9) /local/domain/9/image/hv-start-low = "4118806528" (n0,r9) /local/domain/9/image/guest-os = "linux" (n0,r9) /local/domain/9/image/features = "" (n0,r9) /local/domain/9/image/features/writable-descriptor-tables = "1" (n0,r9) /local/domain/9/image/features/supervisor-mode-kernel = "1" (n0,r9) /local/domain/9/image/features/pae-pgdir-above-4gb = "1" (n0,r9) /local/domain/9/image/features/writable-page-tables = "1" (n0,r9) /local/domain/9/image/features/auto-translated-physmap = "1" (n0,r9) /local/domain/9/image/hypercall-page = "3222278144" (n0,r9) /local/domain/9/image/guest-version = "2.6" (n0,r9) /local/domain/9/image/pae-mode = "yes" (n0,r9) /local/domain/9/image/paddr-offset = "3221225472" (n0,r9) /local/domain/9/image/virt-base = "3221225472" (n0,r9) /local/domain/9/image/xen-version = "xen-3.0" (n0,r9) /local/domain/9/store = "" (n0,r9) /local/domain/9/store/ring-ref = "7027815" (n0,r9) /local/domain/9/store/port = "1" (n0,r9) /local/domain/9/description = "" (n0,r9) /local/domain/9/cpu = "" (n0,r9) /local/domain/9/cpu/0 = "" (n0,r9) /local/domain/9/cpu/0/availability = "online" (n0,r9) /local/domain/9/name = "lightning" (n0,r9) /local/domain/9/domid = "9" (n0,r9) /local/pool = "" (n0) /local/pool/0 = "" (n0) /local/pool/0/other_config = "" (n0) /local/pool/0/description = "Pool-0" (n0) /local/pool/0/uuid = "caa85392-7062-bd40-53ee-fd3a7c1a1a6f" (n0) /local/pool/0/name = "Pool-0" (n0) /vm = "" (n0) /vm/00000000-0000-0000-0000-000000000000 = "" (n0) /vm/00000000-0000-0000-0000-000000000000/on_xend_stop = "ignore" (n0) /vm/00000000-0000-0000-0000-000000000000/pool_name = "Pool-0" (n0) /vm/00000000-0000-0000-0000-000000000000/shadow_memory = "0" (n0) /vm/00000000-0000-0000-0000-000000000000/uuid = "00000000-0000-0000-0000-000000000000" (r0) /vm/00000000-0000-0000-0000-000000000000/on_reboot = "restart" (n0) /vm/00000000-0000-0000-0000-000000000000/image = "(linux (kernel '') (superpages 0) (nomigrate 0) (tsc_mode 0))" (n0) /vm/00000000-0000-0000-0000-000000000000/image/ostype = "linux" (n0) /vm/00000000-0000-0000-0000-000000000000/image/kernel = "" (n0) /vm/00000000-0000-0000-0000-000000000000/image/cmdline = "" (r0) /vm/00000000-0000-0000-0000-000000000000/image/ramdisk = "" (n0) /vm/00000000-0000-0000-0000-000000000000/on_poweroff = "destroy" (n0) /vm/00000000-0000-0000-0000-000000000000/bootloader_args = "" (n0) /vm/00000000-0000-0000-0000-000000000000/on_xend_start = "ignore" (n0) /vm/00000000-0000-0000-0000-000000000000/on_crash = "restart" (n0) /vm/00000000-0000-0000-0000-000000000000/xend = "" (n0) /vm/00000000-0000-0000-0000-000000000000/xend/restart_count = "0" (n0) /vm/00000000-0000-0000-0000-000000000000/vcpus = "8" (n0) /vm/00000000-0000-0000-0000-000000000000/vcpu_avail = "255" (n0) /vm/00000000-0000-0000-0000-000000000000/bootloader = "" (n0) /vm/00000000-0000-0000-0000-000000000000/name = "Domain-0" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df = "" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/image = "(linux (kernel /boot/bzImage-domU-oldgame) (args 'root=/dev/xvda1 ro console=xvc0 earlyprintk=xen') (superpages 0) (videoram 4) (pci ()) (nomigrate 0) (tsc_mode 0) (notes (HV_START_LOW 411880652\..." (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/image/ostype = "linux" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/image/kernel = "/boot/bzImage-domU-oldgame" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/image/cmdline = "root=/dev/xvda1 ro console=xvc0 earlyprintk=xen" (n0,r9) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/image/ramdisk = "" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device = "" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/vbd = "" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/vbd/51713 = "" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/vbd/51713/frontend = "/local/domain/9/device/vbd/51713" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/vbd/51713/frontend-id = "9" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/vbd/51713/backend-id = "0" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/vbd/51713/backend = "/local/domain/0/backend/vbd/9/51713" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/vif = "" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/vif/0 = "" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/vif/0/frontend = "/local/domain/9/device/vif/0" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/vif/0/frontend-id = "9" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/vif/0/backend-id = "0" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/vif/0/backend = "/local/domain/0/backend/vif/9/0" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/console = "" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/console/0 = "" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/console/0/frontend = "/local/domain/9/device/console/0" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/console/0/frontend-id = "9" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/console/0/backend-id = "0" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/console/0/backend = "/local/domain/0/backend/console/9/0" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/on_xend_stop = "ignore" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/pool_name = "Pool-0" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/shadow_memory = "0" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/uuid = "f73e32ee-c0ee-2d58-98df-d7f2f6e062df" (n0,r9) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/on_reboot = "restart" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/start_time = "1349264227.39" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/on_poweroff = "destroy" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/bootloader_args = "" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/on_xend_start = "ignore" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/on_crash = "preserve" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/xend = "" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/xend/restart_count = "0" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/vcpus = "1" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/vcpu_avail = "1" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/bootloader = "" (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/name = "lightning" (n0) ...And Here is the ALL of the output available from xenstore-ls -fp when I'm only running dom0 and that problematic domU and when it is launched with xl and crashed (preserved): root@xen-2:~# xenstore-ls -fp /tool = "" (n0) /tool/xenstored = "" (n0) /local = "" (n0) /local/domain = "" (n0) /local/domain/0 = "" (n0) /local/domain/0/name = "Domain-0" (n0) /local/domain/0/device-model = "" (n0) /local/domain/0/device-model/0 = "" (n0) /local/domain/0/device-model/0/state = "running" (n0) /local/domain/0/libxl = "" (n0) /local/domain/0/libxl/disable_udev = "1" (n0) /local/domain/0/backend = "" (n0) /local/domain/0/backend/vbd = "" (n0) /local/domain/0/backend/vbd/1 = "" (n0) /local/domain/0/backend/vbd/1/51713 = "" (n0,r1) /local/domain/0/backend/vbd/1/51713/frontend = "/local/domain/1/device/vbd/51713" (n0,r1) /local/domain/0/backend/vbd/1/51713/params = "/dev/virtuals/lightning" (n0,r1) /local/domain/0/backend/vbd/1/51713/script = "/etc/xen/scripts/block" (n0,r1) /local/domain/0/backend/vbd/1/51713/physical-device = "fd:7" (n0,r1) /local/domain/0/backend/vbd/1/51713/frontend-id = "1" (n0,r1) /local/domain/0/backend/vbd/1/51713/online = "1" (n0,r1) /local/domain/0/backend/vbd/1/51713/removable = "0" (n0,r1) /local/domain/0/backend/vbd/1/51713/bootable = "1" (n0,r1) /local/domain/0/backend/vbd/1/51713/state = "4" (n0,r1) /local/domain/0/backend/vbd/1/51713/dev = "xvda1" (n0,r1) /local/domain/0/backend/vbd/1/51713/type = "phy" (n0,r1) /local/domain/0/backend/vbd/1/51713/mode = "w" (n0,r1) /local/domain/0/backend/vbd/1/51713/device-type = "disk" (n0,r1) /local/domain/0/backend/vbd/1/51713/feature-flush-cache = "1" (n0,r1) /local/domain/0/backend/vbd/1/51713/feature-discard = "0" (n0,r1) /local/domain/0/backend/vbd/1/51713/feature-barrier = "1" (n0,r1) /local/domain/0/backend/vbd/1/51713/sectors = "104857600" (n0,r1) /local/domain/0/backend/vbd/1/51713/info = "0" (n0,r1) /local/domain/0/backend/vbd/1/51713/sector-size = "512" (n0,r1) /local/domain/0/backend/console = "" (n0) /local/domain/0/backend/console/1 = "" (n0) /local/domain/0/backend/console/1/0 = "" (n0,r1) /local/domain/0/backend/console/1/0/frontend = "/local/domain/1/console" (n0,r1) /local/domain/0/backend/console/1/0/frontend-id = "1" (n0,r1) /local/domain/0/backend/console/1/0/online = "1" (n0,r1) /local/domain/0/backend/console/1/0/state = "1" (n0,r1) /local/domain/0/backend/console/1/0/domain = "lightning" (n0,r1) /local/domain/0/backend/console/1/0/protocol = "vt100" (n0,r1) /local/domain/0/backend/vif = "" (n0) /local/domain/0/backend/vif/1 = "" (n0) /local/domain/0/backend/vif/1/0 = "" (n0,r1) /local/domain/0/backend/vif/1/0/frontend = "/local/domain/1/device/vif/0" (n0,r1) /local/domain/0/backend/vif/1/0/frontend-id = "1" (n0,r1) /local/domain/0/backend/vif/1/0/online = "1" (n0,r1) /local/domain/0/backend/vif/1/0/state = "4" (n0,r1) /local/domain/0/backend/vif/1/0/script = "/etc/xen/scripts/vif-bridge" (n0,r1) /local/domain/0/backend/vif/1/0/mac = "00:16:3e:1d:0d:91" (n0,r1) /local/domain/0/backend/vif/1/0/bridge = "xenbr0" (n0,r1) /local/domain/0/backend/vif/1/0/handle = "0" (n0,r1) /local/domain/0/backend/vif/1/0/type = "vif" (n0,r1) /local/domain/0/backend/vif/1/0/feature-sg = "1" (n0,r1) /local/domain/0/backend/vif/1/0/feature-gso-tcpv4 = "1" (n0,r1) /local/domain/0/backend/vif/1/0/feature-rx-copy = "1" (n0,r1) /local/domain/0/backend/vif/1/0/feature-rx-flip = "0" (n0,r1) /local/domain/0/backend/vif/1/0/hotplug-status = "connected" (n0,r1) /local/domain/1 = "" (n0,r1) /local/domain/1/vm = "/vm/55f79877-0895-400a-97ce-da869599a1ce" (n0,r1) /local/domain/1/name = "lightning" (n0,r1) /local/domain/1/cpu = "" (n0,r1) /local/domain/1/cpu/0 = "" (n0,r1) /local/domain/1/cpu/0/availability = "online" (n0,r1) /local/domain/1/memory = "" (n0,r1) /local/domain/1/memory/static-max = "2097152" (n0,r1) /local/domain/1/memory/target = "2097153" (n0,r1) /local/domain/1/memory/videoram = "-1" (n0,r1) /local/domain/1/device = "" (n0,r1) /local/domain/1/device/suspend = "" (n0,r1) /local/domain/1/device/suspend/event-channel = "" (n1) /local/domain/1/device/vbd = "" (n0,r1) /local/domain/1/device/vbd/51713 = "" (n1,r0) /local/domain/1/device/vbd/51713/backend = "/local/domain/0/backend/vbd/1/51713" (n1,r0) /local/domain/1/device/vbd/51713/backend-id = "0" (n1,r0) /local/domain/1/device/vbd/51713/state = "4" (n1,r0) /local/domain/1/device/vbd/51713/virtual-device = "51713" (n1,r0) /local/domain/1/device/vbd/51713/device-type = "disk" (n1,r0) /local/domain/1/device/vbd/51713/ring-ref = "8" (n1,r0) /local/domain/1/device/vbd/51713/event-channel = "6" (n1,r0) /local/domain/1/device/vif = "" (n0,r1) /local/domain/1/device/vif/0 = "" (n1,r0) /local/domain/1/device/vif/0/backend = "/local/domain/0/backend/vif/1/0" (n1,r0) /local/domain/1/device/vif/0/backend-id = "0" (n1,r0) /local/domain/1/device/vif/0/state = "4" (n1,r0) /local/domain/1/device/vif/0/handle = "0" (n1,r0) /local/domain/1/device/vif/0/mac = "00:16:3e:1d:0d:91" (n1,r0) /local/domain/1/device/vif/0/tx-ring-ref = "521" (n1,r0) /local/domain/1/device/vif/0/rx-ring-ref = "522" (n1,r0) /local/domain/1/device/vif/0/event-channel = "7" (n1,r0) /local/domain/1/device/vif/0/request-rx-copy = "1" (n1,r0) /local/domain/1/device/vif/0/feature-rx-notify = "1" (n1,r0) /local/domain/1/device/vif/0/feature-sg = "1" (n1,r0) /local/domain/1/device/vif/0/feature-gso-tcpv4 = "1" (n1,r0) /local/domain/1/control = "" (n0,r1) /local/domain/1/control/shutdown = "" (n1) /local/domain/1/control/platform-feature-multiprocessor-suspend = "1" (n0,r1) /local/domain/1/control/platform-feature-xs_reset_watches = "1" (n0,r1) /local/domain/1/data = "" (n1) /local/domain/1/domid = "1" (n0,r1) /local/domain/1/store = "" (n0,r1) /local/domain/1/store/port = "1" (n0,r1) /local/domain/1/store/ring-ref = "6594439" (n0,r1) /local/domain/1/console = "" (n1,r0) /local/domain/1/console/backend = "/local/domain/0/backend/console/1/0" (n1,r0) /local/domain/1/console/backend-id = "0" (n1,r0) /local/domain/1/console/limit = "1048576" (n1,r0) /local/domain/1/console/type = "xenconsoled" (n1,r0) /local/domain/1/console/output = "pty" (n1,r0) /local/domain/1/console/port = "2" (n1,r0) /local/domain/1/console/ring-ref = "6594438" (n1,r0) /local/domain/1/console/tty = "/dev/pts/3" (n1,r0) /vm = "" (n0) /vm/55f79877-0895-400a-97ce-da869599a1ce = "" (n0,r1) /vm/55f79877-0895-400a-97ce-da869599a1ce/uuid = "55f79877-0895-400a-97ce-da869599a1ce" (n0,r1) /vm/55f79877-0895-400a-97ce-da869599a1ce/name = "lightning" (n0,r1) /vm/55f79877-0895-400a-97ce-da869599a1ce/image = "" (n0,r1) /vm/55f79877-0895-400a-97ce-da869599a1ce/image/ostype = "linux" (n0,r1) /vm/55f79877-0895-400a-97ce-da869599a1ce/image/kernel = "/boot/bzImage-domU-oldgame" (n0,r1) /vm/55f79877-0895-400a-97ce-da869599a1ce/image/cmdline = "root=/dev/xvda1 ro console=xvc0 earlyprintk=xen" (n0,r1) /vm/55f79877-0895-400a-97ce-da869599a1ce/start_time = "1349264651.94" (n0,r1) /libxl = "" (n0) /libxl/1 = "" (n0) /libxl/1/dm-version = "qemu_xen" (n0) - Valtteri 2012/10/3 Ian Campbell > On Wed, 2012-10-03 at 12:07 +0100, Valtteri Kiviniemi wrote: > > > > /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2 = "" (n0) > > The interesting stuff will be under /local/domain/0 > and /local/domain/ rather than under /vm. > > The builder logs were the same modulo some insignificant changes. > > Ian. > > --20cf303a2e353ea44104cb262a29 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Ok, well lets do it thisway. Hopefully I got this right this tim= e.

Here is the ALL of the output available from xenstore-ls -fp whe= n I'm only=20 running dom0 and that problematic domU, and when it is launched with Xend a= nd fully working:

root@xen-2:~# xenstore-ls -fp
/tool =3D "&= quot;=A0=A0 (n0)
/tool/xenstored =3D ""=A0=A0 (n0)
/local = =3D ""=A0=A0 (n0)
/local/domain =3D ""=A0=A0 (n0)
/local/domain/0 =3D "&quo= t;=A0=A0 (r0)
/local/domain/0/vm =3D "/vm/00000000-0000-0000-0000-0= 00000000000"=A0=A0 (r0)
/local/domain/0/device =3D ""=A0= =A0 (n0)
/local/domain/0/control =3D ""=A0=A0 (n0)
/local/domain/0/control/platform-feature-multiprocessor-suspend =3D "1= "=A0=A0 (n0)
/local/domain/0/control/platform-feature-xs_reset_watc= hes =3D "1"=A0=A0 (n0)
/local/domain/0/error =3D ""= =A0=A0 (n0)
/local/domain/0/memory =3D ""=A0=A0 (n0)
/local/domain/0/memor= y/target =3D "1310720"=A0=A0 (n0)
/local/domain/0/guest =3D &q= uot;"=A0=A0 (n0)
/local/domain/0/hvmpv =3D ""=A0=A0 (n0)<= br>/local/domain/0/data =3D ""=A0=A0 (n0)
/local/domain/0/cpu =3D ""=A0=A0 (r0)
/local/domain/0/cpu/1 = =3D ""=A0=A0 (r0)
/local/domain/0/cpu/1/availability =3D "= ;online"=A0=A0 (r0)
/local/domain/0/cpu/3 =3D ""=A0=A0 (r= 0)
/local/domain/0/cpu/3/availability =3D "online"=A0=A0 (r0)<= br> /local/domain/0/cpu/2 =3D ""=A0=A0 (r0)
/local/domain/0/cpu/2/= availability =3D "online"=A0=A0 (r0)
/local/domain/0/cpu/4 =3D= ""=A0=A0 (r0)
/local/domain/0/cpu/4/availability =3D "on= line"=A0=A0 (r0)
/local/domain/0/cpu/7 =3D ""=A0=A0 (r0)
/local/domain/0/cpu/7/= availability =3D "online"=A0=A0 (r0)
/local/domain/0/cpu/0 =3D= ""=A0=A0 (r0)
/local/domain/0/cpu/0/availability =3D "on= line"=A0=A0 (r0)
/local/domain/0/cpu/5 =3D ""=A0=A0 (r0)
/local/domain/0/cpu/5/= availability =3D "online"=A0=A0 (r0)
/local/domain/0/cpu/6 =3D= ""=A0=A0 (r0)
/local/domain/0/cpu/6/availability =3D "on= line"=A0=A0 (r0)
/local/domain/0/description =3D ""=A0=A0 (r0)
/local/domain/0/= console =3D ""=A0=A0 (r0)
/local/domain/0/console/limit =3D &q= uot;1048576"=A0=A0 (r0)
/local/domain/0/console/type =3D "xenc= onsoled"=A0=A0 (r0)
/local/domain/0/domid =3D "0"=A0=A0 (r0)
/local/domain/0/name = =3D "Domain-0"=A0=A0 (r0)
/local/domain/0/backend =3D "&q= uot;=A0=A0 (r0)
/local/domain/0/backend/vbd =3D ""=A0=A0 (r0)<= br>/local/domain/0/backend/vbd/9 =3D ""=A0=A0 (r0)
/local/domain/0/backend/vbd/9/51713 =3D ""=A0=A0 (n0,r9)
/loca= l/domain/0/backend/vbd/9/51713/domain =3D "lightning"=A0=A0 (n0,r= 9)
/local/domain/0/backend/vbd/9/51713/frontend =3D "/local/domain/= 9/device/vbd/51713"=A0=A0 (n0,r9)
/local/domain/0/backend/vbd/9/51713/uuid =3D "07c30250-23d0-45dc-a7fd-= 27c4705ab946"=A0=A0 (n0,r9)
/local/domain/0/backend/vbd/9/51713/boo= table =3D "1"=A0=A0 (n0,r9)
/local/domain/0/backend/vbd/9/5171= 3/dev =3D "xvda1"=A0=A0 (n0,r9)
/local/domain/0/backend/vbd/9/51713/state =3D "4"=A0=A0 (n0,r9)/local/domain/0/backend/vbd/9/51713/params =3D "/dev/virtuals/lightn= ing"=A0=A0 (n0,r9)
/local/domain/0/backend/vbd/9/51713/mode =3D &qu= ot;w"=A0=A0 (n0,r9)
/local/domain/0/backend/vbd/9/51713/online =3D "1"=A0=A0 (n0,r9)<= br>/local/domain/0/backend/vbd/9/51713/frontend-id =3D "9"=A0=A0 = (n0,r9)
/local/domain/0/backend/vbd/9/51713/type =3D "phy"=A0= =A0 (n0,r9)
/local/domain/0/backend/vbd/9/51713/physical-device =3D "fd:7"=A0= =A0 (n0,r9)
/local/domain/0/backend/vbd/9/51713/hotplug-status =3D "= ;connected"=A0=A0 (n0,r9)
/local/domain/0/backend/vbd/9/51713/featu= re-flush-cache =3D "1"=A0=A0 (n0,r9)
/local/domain/0/backend/vbd/9/51713/feature-discard =3D "0"=A0=A0= (n0,r9)
/local/domain/0/backend/vbd/9/51713/feature-barrier =3D "1= "=A0=A0 (n0,r9)
/local/domain/0/backend/vbd/9/51713/sectors =3D &qu= ot;104857600"=A0=A0 (n0,r9)
/local/domain/0/backend/vbd/9/51713/info =3D "0"=A0=A0 (n0,r9)/local/domain/0/backend/vbd/9/51713/sector-size =3D "512"=A0=A0 = (n0,r9)
/local/domain/0/backend/vif =3D ""=A0=A0 (r0)
/loca= l/domain/0/backend/vif/9 =3D ""=A0=A0 (r0)
/local/domain/0/backend/vif/9/0 =3D ""=A0=A0 (n0,r9)
/local/do= main/0/backend/vif/9/0/bridge =3D "xenbr0"=A0=A0 (n0,r9)
/loca= l/domain/0/backend/vif/9/0/domain =3D "lightning"=A0=A0 (n0,r9)/local/domain/0/backend/vif/9/0/handle =3D "0"=A0=A0 (n0,r9) /local/domain/0/backend/vif/9/0/uuid =3D "07ba2113-4679-843f-f4d8-eada= ec462af0"=A0=A0 (n0,r9)
/local/domain/0/backend/vif/9/0/script =3D = "/etc/xen/scripts/vif-bridge"=A0=A0 (n0,r9)
/local/domain/0/ba= ckend/vif/9/0/state =3D "4"=A0=A0 (n0,r9)
/local/domain/0/backend/vif/9/0/frontend =3D "/local/domain/9/device/v= if/0"=A0=A0 (n0,r9)
/local/domain/0/backend/vif/9/0/mac =3D "0= 0:16:3e:1d:0d:91"=A0=A0 (n0,r9)
/local/domain/0/backend/vif/9/0/onl= ine =3D "1"=A0=A0 (n0,r9)
/local/domain/0/backend/vif/9/0/frontend-id =3D "9"=A0=A0 (n0,r9)=
/local/domain/0/backend/vif/9/0/feature-sg =3D "1"=A0=A0 (n0,= r9)
/local/domain/0/backend/vif/9/0/feature-gso-tcpv4 =3D "1"= =A0=A0 (n0,r9)
/local/domain/0/backend/vif/9/0/feature-rx-copy =3D "1"=A0=A0 (n0= ,r9)
/local/domain/0/backend/vif/9/0/feature-rx-flip =3D "0"= =A0=A0 (n0,r9)
/local/domain/0/backend/vif/9/0/hotplug-status =3D "= connected"=A0=A0 (n0,r9)
/local/domain/0/backend/console =3D ""=A0=A0 (r0)
/local/domai= n/0/backend/console/9 =3D ""=A0=A0 (r0)
/local/domain/0/backen= d/console/9/0 =3D ""=A0=A0 (n0,r9)
/local/domain/0/backend/con= sole/9/0/domain =3D "lightning"=A0=A0 (n0,r9)
/local/domain/0/backend/console/9/0/protocol =3D "vt100"=A0=A0 (n= 0,r9)
/local/domain/0/backend/console/9/0/uuid =3D "c17b2697-71ba-0= 11d-9958-2094cf39a7e4"=A0=A0 (n0,r9)
/local/domain/0/backend/consol= e/9/0/frontend =3D "/local/domain/9/device/console/0"=A0=A0 (n0,r= 9)
/local/domain/0/backend/console/9/0/state =3D "1"=A0=A0 (n0,r9)/local/domain/0/backend/console/9/0/location =3D "2"=A0=A0 (n0,= r9)
/local/domain/0/backend/console/9/0/online =3D "1"=A0=A0 (= n0,r9)
/local/domain/0/backend/console/9/0/frontend-id =3D "9"= =A0=A0 (n0,r9)
/local/domain/9 =3D ""=A0=A0 (n0,r9)
/local/domain/9/vm =3D &q= uot;/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df"=A0=A0 (n0,r9)
/local/= domain/9/device =3D ""=A0=A0 (n9)
/local/domain/9/device/vbd = =3D ""=A0=A0 (n9)
/local/domain/9/device/vbd/51713 =3D ""=A0=A0 (n9,r0)
/local/d= omain/9/device/vbd/51713/virtual-device =3D "51713"=A0=A0 (n9,r0)=
/local/domain/9/device/vbd/51713/device-type =3D "disk"=A0=A0= (n9,r0)
/local/domain/9/device/vbd/51713/protocol =3D "x86_32-abi&= quot;=A0=A0 (n9,r0)
/local/domain/9/device/vbd/51713/backend-id =3D "0"=A0=A0 (n9,r0)=
/local/domain/9/device/vbd/51713/state =3D "4"=A0=A0 (n9,r0)<= br>/local/domain/9/device/vbd/51713/backend =3D "/local/domain/0/backe= nd/vbd/9/51713"=A0=A0 (n9,r0)
/local/domain/9/device/vbd/51713/ring-ref =3D "8"=A0=A0 (n9,r0)/local/domain/9/device/vbd/51713/event-channel =3D "6"=A0=A0 (n= 9,r0)
/local/domain/9/device/vif =3D ""=A0=A0 (n9)
/local/d= omain/9/device/vif/0 =3D ""=A0=A0 (n9,r0)
/local/domain/9/device/vif/0/mac =3D "00:16:3e:1d:0d:91"=A0=A0 (n= 9,r0)
/local/domain/9/device/vif/0/handle =3D "0"=A0=A0 (n9,r0= )
/local/domain/9/device/vif/0/protocol =3D "x86_32-abi"=A0=A0= (n9,r0)
/local/domain/9/device/vif/0/backend-id =3D "0"=A0=A0= (n9,r0)
/local/domain/9/device/vif/0/state =3D "4"=A0=A0 (n9,r0)
/loca= l/domain/9/device/vif/0/backend =3D "/local/domain/0/backend/vif/9/0&q= uot;=A0=A0 (n9,r0)
/local/domain/9/device/vif/0/tx-ring-ref =3D "52= 1"=A0=A0 (n9,r0)
/local/domain/9/device/vif/0/rx-ring-ref =3D "522"=A0=A0 (n9,r0)<= br>/local/domain/9/device/vif/0/event-channel =3D "7"=A0=A0 (n9,r= 0)
/local/domain/9/device/vif/0/request-rx-copy =3D "1"=A0=A0 = (n9,r0)
/local/domain/9/device/vif/0/feature-rx-notify =3D "1"= =A0=A0 (n9,r0)
/local/domain/9/device/vif/0/feature-sg =3D "1"=A0=A0 (n9,r0)
= /local/domain/9/device/vif/0/feature-gso-tcpv4 =3D "1"=A0=A0 (n9,= r0)
/local/domain/9/device/console =3D ""=A0=A0 (n9)
/local= /domain/9/device/console/0 =3D ""=A0=A0 (n9,r0)
/local/domain/9/device/console/0/protocol =3D "x86_32-abi"=A0=A0 = (n9,r0)
/local/domain/9/device/console/0/state =3D "1"=A0=A0 (= n9,r0)
/local/domain/9/device/console/0/backend-id =3D "0"=A0= =A0 (n9,r0)
/local/domain/9/device/console/0/backend =3D "/local/domain/0/backend/= console/9/0"=A0=A0 (n9,r0)
/local/domain/9/control =3D ""= =A0=A0 (n9)
/local/domain/9/control/platform-feature-multiprocessor-susp= end =3D "1"=A0=A0 (n9)
/local/domain/9/control/platform-feature-xs_reset_watches =3D "1"= =A0=A0 (n9)
/local/domain/9/control/feature-reboot =3D "1"=A0= =A0 (n9)
/local/domain/9/control/feature-sysrq =3D "1"=A0=A0 (= n9)
/local/domain/9/error =3D ""=A0=A0 (n9)
/local/domain/9/memory =3D ""=A0=A0 (n9)
/local/domain/9/memor= y/target =3D "2097152"=A0=A0 (n9)
/local/domain/9/guest =3D &q= uot;"=A0=A0 (n9)
/local/domain/9/hvmpv =3D ""=A0=A0 (n9)<= br>/local/domain/9/data =3D ""=A0=A0 (n9)
/local/domain/9/device-misc =3D ""=A0=A0 (n0,r9)
/local/domain= /9/device-misc/vif =3D ""=A0=A0 (n0,r9)
/local/domain/9/device= -misc/vif/nextDeviceID =3D "1"=A0=A0 (n0,r9)
/local/domain/9/d= evice-misc/console =3D ""=A0=A0 (n0,r9)
/local/domain/9/device-misc/console/nextDeviceID =3D "1"=A0=A0 (n= 0,r9)
/local/domain/9/console =3D ""=A0=A0 (n0,r9)
/local/d= omain/9/console/ring-ref =3D "7027814"=A0=A0 (n0,r9)
/local/do= main/9/console/port =3D "2"=A0=A0 (n0,r9)
/local/domain/9/console/limit =3D "1048576"=A0=A0 (n0,r9)
/loc= al/domain/9/console/type =3D "xenconsoled"=A0=A0 (n0,r9)
/loca= l/domain/9/console/tty =3D "/dev/pts/2"=A0=A0 (n0,r9)
/local/d= omain/9/image =3D ""=A0=A0 (n0,r9)
/local/domain/9/image/entry =3D "3222274048"=A0=A0 (n0,r9)
/lo= cal/domain/9/image/loader =3D "generic"=A0=A0 (n0,r9)
/local/d= omain/9/image/hv-start-low =3D "4118806528"=A0=A0 (n0,r9)
/loc= al/domain/9/image/guest-os =3D "linux"=A0=A0 (n0,r9)
/local/domain/9/image/features =3D ""=A0=A0 (n0,r9)
/local/dom= ain/9/image/features/writable-descriptor-tables =3D "1"=A0=A0 (n0= ,r9)
/local/domain/9/image/features/supervisor-mode-kernel =3D "1&q= uot;=A0=A0 (n0,r9)
/local/domain/9/image/features/pae-pgdir-above-4gb =3D "1"=A0=A0 = (n0,r9)
/local/domain/9/image/features/writable-page-tables =3D "1&= quot;=A0=A0 (n0,r9)
/local/domain/9/image/features/auto-translated-physm= ap =3D "1"=A0=A0 (n0,r9)
/local/domain/9/image/hypercall-page =3D "3222278144"=A0=A0 (n0,r= 9)
/local/domain/9/image/guest-version =3D "2.6"=A0=A0 (n0,r9)=
/local/domain/9/image/pae-mode =3D "yes"=A0=A0 (n0,r9)
/lo= cal/domain/9/image/paddr-offset =3D "3221225472"=A0=A0 (n0,r9) /local/domain/9/image/virt-base =3D "3221225472"=A0=A0 (n0,r9)/local/domain/9/image/xen-version =3D "xen-3.0"=A0=A0 (n0,r9)/local/domain/9/store =3D ""=A0=A0 (n0,r9)
/local/domain/9/st= ore/ring-ref =3D "7027815"=A0=A0 (n0,r9)
/local/domain/9/store/port =3D "1"=A0=A0 (n0,r9)
/local/domain= /9/description =3D ""=A0=A0 (n0,r9)
/local/domain/9/cpu =3D &q= uot;"=A0=A0 (n0,r9)
/local/domain/9/cpu/0 =3D ""=A0=A0 (n= 0,r9)
/local/domain/9/cpu/0/availability =3D "online"=A0=A0 (n= 0,r9)
/local/domain/9/name =3D "lightning"=A0=A0 (n0,r9)
/local/doma= in/9/domid =3D "9"=A0=A0 (n0,r9)
/local/pool =3D ""= =A0=A0 (n0)
/local/pool/0 =3D ""=A0=A0 (n0)
/local/pool/0/o= ther_config =3D ""=A0=A0 (n0)
/local/pool/0/description =3D "Pool-0"=A0=A0 (n0)
/local/pool/= 0/uuid =3D "caa85392-7062-bd40-53ee-fd3a7c1a1a6f"=A0=A0 (n0)
/= local/pool/0/name =3D "Pool-0"=A0=A0 (n0)
/vm =3D ""= =A0=A0 (n0)
/vm/00000000-0000-0000-0000-000000000000 =3D ""=A0= =A0 (n0)
/vm/00000000-0000-0000-0000-000000000000/on_xend_stop =3D "ignore"= ;=A0=A0 (n0)
/vm/00000000-0000-0000-0000-000000000000/pool_name =3D &quo= t;Pool-0"=A0=A0 (n0)
/vm/00000000-0000-0000-0000-000000000000/shado= w_memory =3D "0"=A0=A0 (n0)
/vm/00000000-0000-0000-0000-000000000000/uuid =3D "00000000-0000-0000-= 0000-000000000000"=A0=A0 (r0)
/vm/00000000-0000-0000-0000-000000000= 000/on_reboot =3D "restart"=A0=A0 (n0)
/vm/00000000-0000-0000-= 0000-000000000000/image =3D "(linux (kernel '') (superpages 0)= (nomigrate 0) (tsc_mode 0))"=A0=A0 (n0)
/vm/00000000-0000-0000-0000-000000000000/image/ostype =3D "linux"= =A0=A0 (n0)
/vm/00000000-0000-0000-0000-000000000000/image/kernel =3D &q= uot;"=A0=A0 (n0)
/vm/00000000-0000-0000-0000-000000000000/image/cmd= line =3D ""=A0=A0 (r0)
/vm/00000000-0000-0000-0000-000000000000/image/ramdisk =3D ""=A0= =A0 (n0)
/vm/00000000-0000-0000-0000-000000000000/on_poweroff =3D "= destroy"=A0=A0 (n0)
/vm/00000000-0000-0000-0000-000000000000/bootlo= ader_args =3D ""=A0=A0 (n0)
/vm/00000000-0000-0000-0000-000000000000/on_xend_start =3D "ignore&quo= t;=A0=A0 (n0)
/vm/00000000-0000-0000-0000-000000000000/on_crash =3D &quo= t;restart"=A0=A0 (n0)
/vm/00000000-0000-0000-0000-000000000000/xend= =3D ""=A0=A0 (n0)
/vm/00000000-0000-0000-0000-000000000000/xend/restart_count =3D "0&quo= t;=A0=A0 (n0)
/vm/00000000-0000-0000-0000-000000000000/vcpus =3D "8= "=A0=A0 (n0)
/vm/00000000-0000-0000-0000-000000000000/vcpu_avail = =3D "255"=A0=A0 (n0)
/vm/00000000-0000-0000-0000-000000000000/bootloader =3D ""=A0=A0 = (n0)
/vm/00000000-0000-0000-0000-000000000000/name =3D "Domain-0&qu= ot;=A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df =3D ""= =A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/image =3D "(linux (kernel /bo= ot/bzImage-domU-oldgame) (args 'root=3D/dev/xvda1 ro console=3Dxvc0 ear= lyprintk=3Dxen') (superpages 0) (videoram 4) (pci ()) (nomigrate 0) (ts= c_mode 0) (notes (HV_START_LOW 411880652\..."=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/image/ostype =3D "linux"= =A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/image/kernel =3D &q= uot;/boot/bzImage-domU-oldgame"=A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-9= 8df-d7f2f6e062df/image/cmdline =3D "root=3D/dev/xvda1 ro console=3Dxvc= 0 earlyprintk=3Dxen"=A0=A0 (n0,r9)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/image/ramdisk =3D ""=A0= =A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device =3D ""= ;=A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/vbd =3D &qu= ot;"=A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/vbd/51713 =3D ""= =A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/vbd/51713/fr= ontend =3D "/local/domain/9/device/vbd/51713"=A0=A0 (n0)
/vm/f= 73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/vbd/51713/frontend-id =3D "= 9"=A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/vbd/51713/backend-id =3D &q= uot;0"=A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/v= bd/51713/backend =3D "/local/domain/0/backend/vbd/9/51713"=A0=A0 = (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/vif =3D ""=A0=A0 = (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/vif/0 =3D "&qu= ot;=A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/vif/0/fro= ntend =3D "/local/domain/9/device/vif/0"=A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/vif/0/frontend-id =3D "= ;9"=A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/vif/= 0/backend-id =3D "0"=A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7= f2f6e062df/device/vif/0/backend =3D "/local/domain/0/backend/vif/9/0&q= uot;=A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/console =3D ""=A0= =A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/console/0 =3D &= quot;"=A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/c= onsole/0/frontend =3D "/local/domain/9/device/console/0"=A0=A0 (n= 0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/console/0/frontend-id =3D &= quot;9"=A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/device/= console/0/backend-id =3D "0"=A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58= -98df-d7f2f6e062df/device/console/0/backend =3D "/local/domain/0/backe= nd/console/9/0"=A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/on_xend_stop =3D "ignore"= ;=A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/pool_name =3D &quo= t;Pool-0"=A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/shado= w_memory =3D "0"=A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/uuid =3D "f73e32ee-c0ee-2d58-= 98df-d7f2f6e062df"=A0=A0 (n0,r9)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6= e062df/on_reboot =3D "restart"=A0=A0 (n0)
/vm/f73e32ee-c0ee-2d= 58-98df-d7f2f6e062df/start_time =3D "1349264227.39"=A0=A0 (n0) /vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/on_poweroff =3D "destroy"= ;=A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/bootloader_args = =3D ""=A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/on_= xend_start =3D "ignore"=A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/on_crash =3D "preserve"= =A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/xend =3D "&quo= t;=A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/xend/restart_coun= t =3D "0"=A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/vcpus =3D "1"=A0=A0 (n0)=
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/vcpu_avail =3D "1"= =A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/bootloader =3D &quo= t;"=A0=A0 (n0)
/vm/f73e32ee-c0ee-2d58-98df-d7f2f6e062df/name =3D "lightning"=A0= =A0 (n0)

...And Here is the ALL of the output available from xenstor= e-ls -fp when I'm only=20 running dom0 and that problematic domU and when it is launched with xl and = crashed (preserved):

root@xen-2:~# xenstore-ls -fp
/tool =3D &quo= t;"=A0=A0 (n0)
/tool/xenstored =3D ""=A0=A0 (n0)
/loca= l =3D ""=A0=A0 (n0)
/local/domain =3D ""=A0=A0 (n0)
/local/domain/0 =3D "&quo= t;=A0=A0 (n0)
/local/domain/0/name =3D "Domain-0"=A0=A0 (n0)/local/domain/0/device-model =3D ""=A0=A0 (n0)
/local/domain= /0/device-model/0 =3D ""=A0=A0 (n0)
/local/domain/0/device-model/0/state =3D "running"=A0=A0 (n0)
= /local/domain/0/libxl =3D ""=A0=A0 (n0)
/local/domain/0/libxl/= disable_udev =3D "1"=A0=A0 (n0)
/local/domain/0/backend =3D &q= uot;"=A0=A0 (n0)
/local/domain/0/backend/vbd =3D ""=A0=A0 (n0)
/local/domain/0/= backend/vbd/1 =3D ""=A0=A0 (n0)
/local/domain/0/backend/vbd/1/= 51713 =3D ""=A0=A0 (n0,r1)
/local/domain/0/backend/vbd/1/51713= /frontend =3D "/local/domain/1/device/vbd/51713"=A0=A0 (n0,r1) /local/domain/0/backend/vbd/1/51713/params =3D "/dev/virtuals/lightnin= g"=A0=A0 (n0,r1)
/local/domain/0/backend/vbd/1/51713/script =3D &qu= ot;/etc/xen/scripts/block"=A0=A0 (n0,r1)
/local/domain/0/backend/vb= d/1/51713/physical-device =3D "fd:7"=A0=A0 (n0,r1)
/local/domain/0/backend/vbd/1/51713/frontend-id =3D "1"=A0=A0 (n0= ,r1)
/local/domain/0/backend/vbd/1/51713/online =3D "1"=A0=A0 = (n0,r1)
/local/domain/0/backend/vbd/1/51713/removable =3D "0"= =A0=A0 (n0,r1)
/local/domain/0/backend/vbd/1/51713/bootable =3D "1"=A0=A0 (n0,r1= )
/local/domain/0/backend/vbd/1/51713/state =3D "4"=A0=A0 (n0,= r1)
/local/domain/0/backend/vbd/1/51713/dev =3D "xvda1"=A0=A0 = (n0,r1)
/local/domain/0/backend/vbd/1/51713/type =3D "phy"=A0= =A0 (n0,r1)
/local/domain/0/backend/vbd/1/51713/mode =3D "w"=A0=A0 (n0,r1)/local/domain/0/backend/vbd/1/51713/device-type =3D "disk"=A0=A0= (n0,r1)
/local/domain/0/backend/vbd/1/51713/feature-flush-cache =3D &qu= ot;1"=A0=A0 (n0,r1)
/local/domain/0/backend/vbd/1/51713/feature-discard =3D "0"=A0=A0= (n0,r1)
/local/domain/0/backend/vbd/1/51713/feature-barrier =3D "1= "=A0=A0 (n0,r1)
/local/domain/0/backend/vbd/1/51713/sectors =3D &qu= ot;104857600"=A0=A0 (n0,r1)
/local/domain/0/backend/vbd/1/51713/info =3D "0"=A0=A0 (n0,r1)/local/domain/0/backend/vbd/1/51713/sector-size =3D "512"=A0=A0 = (n0,r1)
/local/domain/0/backend/console =3D ""=A0=A0 (n0)
/= local/domain/0/backend/console/1 =3D ""=A0=A0 (n0)
/local/domain/0/backend/console/1/0 =3D ""=A0=A0 (n0,r1)
/loca= l/domain/0/backend/console/1/0/frontend =3D "/local/domain/1/console&q= uot;=A0=A0 (n0,r1)
/local/domain/0/backend/console/1/0/frontend-id =3D &= quot;1"=A0=A0 (n0,r1)
/local/domain/0/backend/console/1/0/online =3D "1"=A0=A0 (n0,r1)<= br>/local/domain/0/backend/console/1/0/state =3D "1"=A0=A0 (n0,r1= )
/local/domain/0/backend/console/1/0/domain =3D "lightning"= =A0=A0 (n0,r1)
/local/domain/0/backend/console/1/0/protocol =3D "vt100"=A0=A0 (n= 0,r1)
/local/domain/0/backend/vif =3D ""=A0=A0 (n0)
/local/= domain/0/backend/vif/1 =3D ""=A0=A0 (n0)
/local/domain/0/backe= nd/vif/1/0 =3D ""=A0=A0 (n0,r1)
/local/domain/0/backend/vif/1/0/frontend =3D "/local/domain/1/device/v= if/0"=A0=A0 (n0,r1)
/local/domain/0/backend/vif/1/0/frontend-id =3D= "1"=A0=A0 (n0,r1)
/local/domain/0/backend/vif/1/0/online =3D = "1"=A0=A0 (n0,r1)
/local/domain/0/backend/vif/1/0/state =3D "4"=A0=A0 (n0,r1)
/l= ocal/domain/0/backend/vif/1/0/script =3D "/etc/xen/scripts/vif-bridge&= quot;=A0=A0 (n0,r1)
/local/domain/0/backend/vif/1/0/mac =3D "00:16:= 3e:1d:0d:91"=A0=A0 (n0,r1)
/local/domain/0/backend/vif/1/0/bridge =3D "xenbr0"=A0=A0 (n0,r1)=
/local/domain/0/backend/vif/1/0/handle =3D "0"=A0=A0 (n0,r1)<= br>/local/domain/0/backend/vif/1/0/type =3D "vif"=A0=A0 (n0,r1)/local/domain/0/backend/vif/1/0/feature-sg =3D "1"=A0=A0 (n0,r1= )
/local/domain/0/backend/vif/1/0/feature-gso-tcpv4 =3D "1"=A0=A0 (= n0,r1)
/local/domain/0/backend/vif/1/0/feature-rx-copy =3D "1"= =A0=A0 (n0,r1)
/local/domain/0/backend/vif/1/0/feature-rx-flip =3D "= ;0"=A0=A0 (n0,r1)
/local/domain/0/backend/vif/1/0/hotplug-status =3D "connected"=A0= =A0 (n0,r1)
/local/domain/1 =3D ""=A0=A0 (n0,r1)
/local/dom= ain/1/vm =3D "/vm/55f79877-0895-400a-97ce-da869599a1ce"=A0=A0 (n0= ,r1)
/local/domain/1/name =3D "lightning"=A0=A0 (n0,r1)
/local/domain/1/cpu =3D ""=A0=A0 (n0,r1)
/local/domain/1/cpu/0= =3D ""=A0=A0 (n0,r1)
/local/domain/1/cpu/0/availability =3D &= quot;online"=A0=A0 (n0,r1)
/local/domain/1/memory =3D ""= =A0=A0 (n0,r1)
/local/domain/1/memory/static-max =3D "2097152"= =A0=A0 (n0,r1)
/local/domain/1/memory/target =3D "2097153"=A0=A0 (n0,r1)
/loc= al/domain/1/memory/videoram =3D "-1"=A0=A0 (n0,r1)
/local/doma= in/1/device =3D ""=A0=A0 (n0,r1)
/local/domain/1/device/suspen= d =3D ""=A0=A0 (n0,r1)
/local/domain/1/device/suspend/event-channel =3D ""=A0=A0 (n1)/local/domain/1/device/vbd =3D ""=A0=A0 (n0,r1)
/local/domain= /1/device/vbd/51713 =3D ""=A0=A0 (n1,r0)
/local/domain/1/devic= e/vbd/51713/backend =3D "/local/domain/0/backend/vbd/1/51713"=A0= =A0 (n1,r0)
/local/domain/1/device/vbd/51713/backend-id =3D "0"=A0=A0 (n1,r0)=
/local/domain/1/device/vbd/51713/state =3D "4"=A0=A0 (n1,r0)<= br>/local/domain/1/device/vbd/51713/virtual-device =3D "51713"=A0= =A0 (n1,r0)
/local/domain/1/device/vbd/51713/device-type =3D "disk"=A0=A0 (n1= ,r0)
/local/domain/1/device/vbd/51713/ring-ref =3D "8"=A0=A0 (= n1,r0)
/local/domain/1/device/vbd/51713/event-channel =3D "6"= =A0=A0 (n1,r0)
/local/domain/1/device/vif =3D ""=A0=A0 (n0,r1)
/local/domain/= 1/device/vif/0 =3D ""=A0=A0 (n1,r0)
/local/domain/1/device/vif= /0/backend =3D "/local/domain/0/backend/vif/1/0"=A0=A0 (n1,r0)/local/domain/1/device/vif/0/backend-id =3D "0"=A0=A0 (n1,r0) /local/domain/1/device/vif/0/state =3D "4"=A0=A0 (n1,r0)
/loca= l/domain/1/device/vif/0/handle =3D "0"=A0=A0 (n1,r0)
/local/do= main/1/device/vif/0/mac =3D "00:16:3e:1d:0d:91"=A0=A0 (n1,r0)
= /local/domain/1/device/vif/0/tx-ring-ref =3D "521"=A0=A0 (n1,r0)<= br> /local/domain/1/device/vif/0/rx-ring-ref =3D "522"=A0=A0 (n1,r0)<= br>/local/domain/1/device/vif/0/event-channel =3D "7"=A0=A0 (n1,r= 0)
/local/domain/1/device/vif/0/request-rx-copy =3D "1"=A0=A0 = (n1,r0)
/local/domain/1/device/vif/0/feature-rx-notify =3D "1"= =A0=A0 (n1,r0)
/local/domain/1/device/vif/0/feature-sg =3D "1"=A0=A0 (n1,r0)
= /local/domain/1/device/vif/0/feature-gso-tcpv4 =3D "1"=A0=A0 (n1,= r0)
/local/domain/1/control =3D ""=A0=A0 (n0,r1)
/local/dom= ain/1/control/shutdown =3D ""=A0=A0 (n1)
/local/domain/1/control/platform-feature-multiprocessor-suspend =3D "1= "=A0=A0 (n0,r1)
/local/domain/1/control/platform-feature-xs_reset_w= atches =3D "1"=A0=A0 (n0,r1)
/local/domain/1/data =3D "&q= uot;=A0=A0 (n1)
/local/domain/1/domid =3D "1"=A0=A0 (n0,r1)
/local/domain/1/st= ore =3D ""=A0=A0 (n0,r1)
/local/domain/1/store/port =3D "= 1"=A0=A0 (n0,r1)
/local/domain/1/store/ring-ref =3D "6594439&q= uot;=A0=A0 (n0,r1)
/local/domain/1/console =3D ""=A0=A0 (n1,r0)
/local/domain/1/c= onsole/backend =3D "/local/domain/0/backend/console/1/0"=A0=A0 (n= 1,r0)
/local/domain/1/console/backend-id =3D "0"=A0=A0 (n1,r0)=
/local/domain/1/console/limit =3D "1048576"=A0=A0 (n1,r0)
/local/domain/1/console/type =3D "xenconsoled"=A0=A0 (n1,r0)
/= local/domain/1/console/output =3D "pty"=A0=A0 (n1,r0)
/local/d= omain/1/console/port =3D "2"=A0=A0 (n1,r0)
/local/domain/1/con= sole/ring-ref =3D "6594438"=A0=A0 (n1,r0)
/local/domain/1/console/tty =3D "/dev/pts/3"=A0=A0 (n1,r0)
/vm= =3D ""=A0=A0 (n0)
/vm/55f79877-0895-400a-97ce-da869599a1ce = =3D ""=A0=A0 (n0,r1)
/vm/55f79877-0895-400a-97ce-da869599a1ce/= uuid =3D "55f79877-0895-400a-97ce-da869599a1ce"=A0=A0 (n0,r1)
/vm/55f79877-0895-400a-97ce-da869599a1ce/name =3D "lightning"=A0= =A0 (n0,r1)
/vm/55f79877-0895-400a-97ce-da869599a1ce/image =3D "&qu= ot;=A0=A0 (n0,r1)
/vm/55f79877-0895-400a-97ce-da869599a1ce/image/ostype = =3D "linux"=A0=A0 (n0,r1)
/vm/55f79877-0895-400a-97ce-da869599a1ce/image/kernel =3D "/boot/bzIma= ge-domU-oldgame"=A0=A0 (n0,r1)
/vm/55f79877-0895-400a-97ce-da869599= a1ce/image/cmdline =3D "root=3D/dev/xvda1 ro console=3Dxvc0 earlyprint= k=3Dxen"=A0=A0 (n0,r1)
/vm/55f79877-0895-400a-97ce-da869599a1ce/start_time =3D "1349264651.94= "=A0=A0 (n0,r1)
/libxl =3D ""=A0=A0 (n0)
/libxl/1 =3D = ""=A0=A0 (n0)
/libxl/1/dm-version =3D "qemu_xen"=A0= =A0 (n0)

- Valtteri

2012/10/3 Ian Campbell <= ;Ian.Campbell@= citrix.com>
On Wed, 2012-10-03 at 12:07 +0100, Valtteri Kiviniemi wrote:
>
> /vm/54fd0bf5-0cc8-802a-880e-f5f9dc0e4ec2 =3D "" =A0 (n0)

The interesting stuff will be under /local/domain/0
and /local/domain/<domU> rather than under /vm.

The builder logs were the same modulo some insignificant changes.

Ian.


--20cf303a2e353ea44104cb262a29-- --===============2788042825860687498== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============2788042825860687498==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 11:46:14 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 11:46:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJNOn-0008EB-Hy; Wed, 03 Oct 2012 11:45:57 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJNOl-0008E3-FH for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 11:45:55 +0000 Received: from [85.158.138.51:50495] by server-13.bemta-3.messagelabs.com id F3/F0-11249-2752C605; Wed, 03 Oct 2012 11:45:54 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-13.tower-174.messagelabs.com!1349264753!14241852!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MjUwMjc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22815 invoked from network); 3 Oct 2012 11:45:54 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Oct 2012 11:45:54 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id B5B681E7C; Wed, 3 Oct 2012 14:45:52 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id A1D7620058; Wed, 3 Oct 2012 14:45:52 +0300 (EEST) Date: Wed, 3 Oct 2012 14:45:52 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Valtteri Kiviniemi Message-ID: <20121003114552.GS8912@reaktio.net> References: <20121002121932.GL8912@reaktio.net> <20121002144251.GP8912@reaktio.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Konrad Rzeszutek Wilk , Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.0.4, kernel 3.5.0 HVM crash and kernel BUG X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, Oct 03, 2012 at 12:21:47PM +0300, Valtteri Kiviniemi wrote: > Hi, > > I disabled NUMA and upgraded to Xen 4.2.0. Windows domU starts now fine > and I cant anymore reproduce the hotplug problems. VNC output is still > just black screen and it actually crashes the the whole VNC client when > after a few seconds. RealVNC just shuts itself down and tightvnc crashes. > Valtteri: Can you actually paste the names of the .config options you disabled and got the dom0 kernel working without crashes? Maybe Konrad can comment if the current upstream dom0 kernel is supposed to work with NUMA support enabled / compiled in? -- Pasi > - Valtteri > > 2012/10/2 Valtteri Kiviniemi <[1]kiviniemi.valtteri@gmail.com> > > Hi, > > Yes, they are all loaded and I'm running Linux PV-virtuals at the same > time with no problems. Only HVM is not working. I have single socket > corei7 processor and NUMA enabled on dom0 kernel, so I will try tomorrow > to compile dom0 kernel without NUMA, since its not needed and it could > probably cause some kind of memory related problems. > > I will also try Debian squeezes package Xen and test if it is working > with my hardware. > > - Valtteri > > 2012/10/2 Konrad Rzeszutek Wilk <[2]konrad@kernel.org> > > On Tue, Oct 2, 2012 at 10:55 AM, Valtteri Kiviniemi > <[3]kiviniemi.valtteri@gmail.com> wrote: > > Hi, > > > > Yes, I understood for what the parameters were for. I'ts been a long > time > > since I last had major problems with Xen (maybe 3.1 or something, > been using > > Xen since version 2) and I had a shady recollection that Xen was > required to > > be build debugging enabled in order to get any usable debugging > data. > > > > But anyway, I cant reproduce that kernel crash everytime, it just > happens > > sometimes. Major problem is the black screen on VNC and second > problem seems > > to be that everytime i try to run Linux in HVM mode it somehow > breaks the > > hotplug scripts. > > > > So do you have all backends loaded? Is xen-netback and xen-blkback > running? > Do you also have tun loaded? > > References > > Visible links > 1. mailto:kiviniemi.valtteri@gmail.com > 2. mailto:konrad@kernel.org > 3. mailto:kiviniemi.valtteri@gmail.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 11:46:14 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 11:46:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJNOn-0008EB-Hy; Wed, 03 Oct 2012 11:45:57 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJNOl-0008E3-FH for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 11:45:55 +0000 Received: from [85.158.138.51:50495] by server-13.bemta-3.messagelabs.com id F3/F0-11249-2752C605; Wed, 03 Oct 2012 11:45:54 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-13.tower-174.messagelabs.com!1349264753!14241852!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MjUwMjc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22815 invoked from network); 3 Oct 2012 11:45:54 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Oct 2012 11:45:54 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id B5B681E7C; Wed, 3 Oct 2012 14:45:52 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id A1D7620058; Wed, 3 Oct 2012 14:45:52 +0300 (EEST) Date: Wed, 3 Oct 2012 14:45:52 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Valtteri Kiviniemi Message-ID: <20121003114552.GS8912@reaktio.net> References: <20121002121932.GL8912@reaktio.net> <20121002144251.GP8912@reaktio.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Konrad Rzeszutek Wilk , Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.0.4, kernel 3.5.0 HVM crash and kernel BUG X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, Oct 03, 2012 at 12:21:47PM +0300, Valtteri Kiviniemi wrote: > Hi, > > I disabled NUMA and upgraded to Xen 4.2.0. Windows domU starts now fine > and I cant anymore reproduce the hotplug problems. VNC output is still > just black screen and it actually crashes the the whole VNC client when > after a few seconds. RealVNC just shuts itself down and tightvnc crashes. > Valtteri: Can you actually paste the names of the .config options you disabled and got the dom0 kernel working without crashes? Maybe Konrad can comment if the current upstream dom0 kernel is supposed to work with NUMA support enabled / compiled in? -- Pasi > - Valtteri > > 2012/10/2 Valtteri Kiviniemi <[1]kiviniemi.valtteri@gmail.com> > > Hi, > > Yes, they are all loaded and I'm running Linux PV-virtuals at the same > time with no problems. Only HVM is not working. I have single socket > corei7 processor and NUMA enabled on dom0 kernel, so I will try tomorrow > to compile dom0 kernel without NUMA, since its not needed and it could > probably cause some kind of memory related problems. > > I will also try Debian squeezes package Xen and test if it is working > with my hardware. > > - Valtteri > > 2012/10/2 Konrad Rzeszutek Wilk <[2]konrad@kernel.org> > > On Tue, Oct 2, 2012 at 10:55 AM, Valtteri Kiviniemi > <[3]kiviniemi.valtteri@gmail.com> wrote: > > Hi, > > > > Yes, I understood for what the parameters were for. I'ts been a long > time > > since I last had major problems with Xen (maybe 3.1 or something, > been using > > Xen since version 2) and I had a shady recollection that Xen was > required to > > be build debugging enabled in order to get any usable debugging > data. > > > > But anyway, I cant reproduce that kernel crash everytime, it just > happens > > sometimes. Major problem is the black screen on VNC and second > problem seems > > to be that everytime i try to run Linux in HVM mode it somehow > breaks the > > hotplug scripts. > > > > So do you have all backends loaded? Is xen-netback and xen-blkback > running? > Do you also have tun loaded? > > References > > Visible links > 1. mailto:kiviniemi.valtteri@gmail.com > 2. mailto:konrad@kernel.org > 3. mailto:kiviniemi.valtteri@gmail.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 11:59:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 11:59:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJNbq-0000ac-6e; Wed, 03 Oct 2012 11:59:26 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJNbp-0000aT-1B for Xen-devel@lists.xensource.com; Wed, 03 Oct 2012 11:59:25 +0000 Received: from [85.158.138.51:14234] by server-7.bemta-3.messagelabs.com id 26/DA-15765-C982C605; Wed, 03 Oct 2012 11:59:24 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-3.tower-174.messagelabs.com!1349265563!24857654!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26166 invoked from network); 3 Oct 2012 11:59:23 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 11:59:23 -0000 X-IronPort-AV: E=Sophos;i="4.80,527,1344211200"; d="scan'208";a="14913570" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 11:59:22 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 12:59:22 +0100 Date: Wed, 3 Oct 2012 12:58:22 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Mukesh Rathor In-Reply-To: <20121002190323.2e16f6ff@mantra.us.oracle.com> Message-ID: References: <20120921121659.5a723de9@mantra.us.oracle.com> <20120924154335.097d3fb9@mantra.us.oracle.com> <20120925180416.0137d61a@mantra.us.oracle.com> <20121002183619.70734b7a@mantra.us.oracle.com> <20121002190323.2e16f6ff@mantra.us.oracle.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Ian Campbell , Konrad Rzeszutek Wilk , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v1 3/8]: PVH startup changes (enlighten.c) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 3 Oct 2012, Mukesh Rathor wrote: > On Tue, 2 Oct 2012 18:36:19 -0700 > Mukesh Rathor wrote: > > > On Wed, 26 Sep 2012 12:33:39 +0100 > > Stefano Stabellini wrote: > > > > > > Wish it was simple. But for PV and PVH, domU, it's already setup > > > > the shared page. All we need to do is __va(shared_info). But for > > > > HVM domUs and PVH dom0, we need to hcall with pfn to get it > > > > remapped. > > > > > > For PVH domU is already setup as a pfn only because in > > > tools/libxc/xc_dom_x86.c:alloc_magic_pages we have this code: > > > > > > if ( xc_dom_feature_translated(dom) ) > > > dom->shared_info_pfn = xc_dom_alloc_page(dom, "shared > > > info"); > > > > > > and in tools/libxc/xc_dom_x86.c:start_info_x86_64 we have: > > > > > > xen_pfn_t shinfo = > > > xc_dom_feature_translated(dom) ? dom->shared_info_pfn : > > > dom-> shared_info_mfn; > > > > > > if we simply get rid of the two "if xc_dom_feature_translated(dom)" > > > wouldn't we get an mfn for PVH domU too? AFAICT all the other cases > > > would remain unmodified, but PVH domU would start getting an mfn for > > > shared_info. > > > > > > > Changing the > > > > tool to map pfn, would result in unnecessary hcall for all PV and > > > > PVH domUs. It's only two lines of code, so lets just leave it. > > > > I'll make the comment better. > > > > > > Yes, there would be one more unnecessary hypercall but we would get > > > rid of 4 "if". I think is a good trade off. > > > > Well, not really unfortunately! There are two fields in the library > > shared_info_mfn and shared_info_pfn in struct xc_dom_image. For > > xlated, pfn is set, otherwise, mfn is set. If I set mfn for auto > > xlated also, I end up changing/adding more code in the library where > > it tries to map the shared page. Moreover, it's better to stick with > > the library assumption that for auto xlated, pfn is set, otherwise, > > mfn is set. > > > > Hope that makes sense. I tried it, btw. > > > > I'm not able to make a quick change to xen to just put pfn for dom0 > also. get_gpfn_from_mfn() is crashing. Did you add the newly allocated shared_info page to dom0's p2m? If not, the page doesn't actually belong to the domain (from the p2m POV), so get_gpfn_from_mfn might not behave correctly. > So for now, how about, lets go > with what I've got. I'll make a note, and when I do xen patch, I'll > figure it out, and would be a very small linux patch. I want to get > linux patch in soon before the window closes. We can leave page special as it is for now with very little consequences, because it is not part of the interface with Xen. However this is part of the interface, so whatever we choose here is going to be hard to change later on. I think it would be good if we could either make dom0 use a pfn or domU use mfn, whatever is easier for you. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 11:59:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 11:59:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJNbq-0000ac-6e; Wed, 03 Oct 2012 11:59:26 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJNbp-0000aT-1B for Xen-devel@lists.xensource.com; Wed, 03 Oct 2012 11:59:25 +0000 Received: from [85.158.138.51:14234] by server-7.bemta-3.messagelabs.com id 26/DA-15765-C982C605; Wed, 03 Oct 2012 11:59:24 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-3.tower-174.messagelabs.com!1349265563!24857654!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26166 invoked from network); 3 Oct 2012 11:59:23 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 11:59:23 -0000 X-IronPort-AV: E=Sophos;i="4.80,527,1344211200"; d="scan'208";a="14913570" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 11:59:22 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 12:59:22 +0100 Date: Wed, 3 Oct 2012 12:58:22 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Mukesh Rathor In-Reply-To: <20121002190323.2e16f6ff@mantra.us.oracle.com> Message-ID: References: <20120921121659.5a723de9@mantra.us.oracle.com> <20120924154335.097d3fb9@mantra.us.oracle.com> <20120925180416.0137d61a@mantra.us.oracle.com> <20121002183619.70734b7a@mantra.us.oracle.com> <20121002190323.2e16f6ff@mantra.us.oracle.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Ian Campbell , Konrad Rzeszutek Wilk , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v1 3/8]: PVH startup changes (enlighten.c) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 3 Oct 2012, Mukesh Rathor wrote: > On Tue, 2 Oct 2012 18:36:19 -0700 > Mukesh Rathor wrote: > > > On Wed, 26 Sep 2012 12:33:39 +0100 > > Stefano Stabellini wrote: > > > > > > Wish it was simple. But for PV and PVH, domU, it's already setup > > > > the shared page. All we need to do is __va(shared_info). But for > > > > HVM domUs and PVH dom0, we need to hcall with pfn to get it > > > > remapped. > > > > > > For PVH domU is already setup as a pfn only because in > > > tools/libxc/xc_dom_x86.c:alloc_magic_pages we have this code: > > > > > > if ( xc_dom_feature_translated(dom) ) > > > dom->shared_info_pfn = xc_dom_alloc_page(dom, "shared > > > info"); > > > > > > and in tools/libxc/xc_dom_x86.c:start_info_x86_64 we have: > > > > > > xen_pfn_t shinfo = > > > xc_dom_feature_translated(dom) ? dom->shared_info_pfn : > > > dom-> shared_info_mfn; > > > > > > if we simply get rid of the two "if xc_dom_feature_translated(dom)" > > > wouldn't we get an mfn for PVH domU too? AFAICT all the other cases > > > would remain unmodified, but PVH domU would start getting an mfn for > > > shared_info. > > > > > > > Changing the > > > > tool to map pfn, would result in unnecessary hcall for all PV and > > > > PVH domUs. It's only two lines of code, so lets just leave it. > > > > I'll make the comment better. > > > > > > Yes, there would be one more unnecessary hypercall but we would get > > > rid of 4 "if". I think is a good trade off. > > > > Well, not really unfortunately! There are two fields in the library > > shared_info_mfn and shared_info_pfn in struct xc_dom_image. For > > xlated, pfn is set, otherwise, mfn is set. If I set mfn for auto > > xlated also, I end up changing/adding more code in the library where > > it tries to map the shared page. Moreover, it's better to stick with > > the library assumption that for auto xlated, pfn is set, otherwise, > > mfn is set. > > > > Hope that makes sense. I tried it, btw. > > > > I'm not able to make a quick change to xen to just put pfn for dom0 > also. get_gpfn_from_mfn() is crashing. Did you add the newly allocated shared_info page to dom0's p2m? If not, the page doesn't actually belong to the domain (from the p2m POV), so get_gpfn_from_mfn might not behave correctly. > So for now, how about, lets go > with what I've got. I'll make a note, and when I do xen patch, I'll > figure it out, and would be a very small linux patch. I want to get > linux patch in soon before the window closes. We can leave page special as it is for now with very little consequences, because it is not part of the interface with Xen. However this is part of the interface, so whatever we choose here is going to be hard to change later on. I think it would be good if we could either make dom0 use a pfn or domU use mfn, whatever is easier for you. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 12:05:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 12:05:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJNhW-0001GC-NR; Wed, 03 Oct 2012 12:05:18 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJNhV-0001Fy-0V for Xen-devel@lists.xensource.com; Wed, 03 Oct 2012 12:05:17 +0000 Received: from [85.158.138.51:13262] by server-13.bemta-3.messagelabs.com id 96/83-11249-CF92C605; Wed, 03 Oct 2012 12:05:16 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1349265915!25010227!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4412 invoked from network); 3 Oct 2012 12:05:15 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 12:05:15 -0000 X-IronPort-AV: E=Sophos;i="4.80,527,1344211200"; d="scan'208";a="14913720" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 12:05:15 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 13:05:15 +0100 Message-ID: <1349265914.650.136.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Wed, 3 Oct 2012 13:05:14 +0100 In-Reply-To: References: <20120921121659.5a723de9@mantra.us.oracle.com> <20120924154335.097d3fb9@mantra.us.oracle.com> <20120925180416.0137d61a@mantra.us.oracle.com> <20121002183619.70734b7a@mantra.us.oracle.com> <20121002190323.2e16f6ff@mantra.us.oracle.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 3/8]: PVH startup changes (enlighten.c) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-10-03 at 12:58 +0100, Stefano Stabellini wrote: > > So for now, how about, lets go > > with what I've got. I'll make a note, and when I do xen patch, I'll > > figure it out, and would be a very small linux patch. I want to get > > linux patch in soon before the window closes. > > We can leave page special as it is for now with very little > consequences, because it is not part of the interface with Xen. However > this is part of the interface, so whatever we choose here is going to be > hard to change later on. I suggested that until we have seen and reviewed the hypervisor side patches this guest side functionality all needs to be under an option which has CONFIG_EXPERIMENTAL as a dependency and a comment explaining that the ABI is not fixed yet, similar to what we did for the ARM port. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 12:05:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 12:05:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJNhW-0001GC-NR; Wed, 03 Oct 2012 12:05:18 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJNhV-0001Fy-0V for Xen-devel@lists.xensource.com; Wed, 03 Oct 2012 12:05:17 +0000 Received: from [85.158.138.51:13262] by server-13.bemta-3.messagelabs.com id 96/83-11249-CF92C605; Wed, 03 Oct 2012 12:05:16 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1349265915!25010227!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4412 invoked from network); 3 Oct 2012 12:05:15 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 12:05:15 -0000 X-IronPort-AV: E=Sophos;i="4.80,527,1344211200"; d="scan'208";a="14913720" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 12:05:15 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 13:05:15 +0100 Message-ID: <1349265914.650.136.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Wed, 3 Oct 2012 13:05:14 +0100 In-Reply-To: References: <20120921121659.5a723de9@mantra.us.oracle.com> <20120924154335.097d3fb9@mantra.us.oracle.com> <20120925180416.0137d61a@mantra.us.oracle.com> <20121002183619.70734b7a@mantra.us.oracle.com> <20121002190323.2e16f6ff@mantra.us.oracle.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 3/8]: PVH startup changes (enlighten.c) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-10-03 at 12:58 +0100, Stefano Stabellini wrote: > > So for now, how about, lets go > > with what I've got. I'll make a note, and when I do xen patch, I'll > > figure it out, and would be a very small linux patch. I want to get > > linux patch in soon before the window closes. > > We can leave page special as it is for now with very little > consequences, because it is not part of the interface with Xen. However > this is part of the interface, so whatever we choose here is going to be > hard to change later on. I suggested that until we have seen and reviewed the hypervisor side patches this guest side functionality all needs to be under an option which has CONFIG_EXPERIMENTAL as a dependency and a comment explaining that the ABI is not fixed yet, similar to what we did for the ARM port. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 12:09:31 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 12:09:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJNlN-0001UO-CY; Wed, 03 Oct 2012 12:09:17 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJNlL-0001U9-Tn for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 12:09:16 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1349266148!8597049!1 X-Originating-IP: [209.85.213.173] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13934 invoked from network); 3 Oct 2012 12:09:09 -0000 Received: from mail-yx0-f173.google.com (HELO mail-yx0-f173.google.com) (209.85.213.173) by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 12:09:09 -0000 Received: by yenl3 with SMTP id l3so2201556yen.32 for ; Wed, 03 Oct 2012 05:09:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bonPAvhYJEbGAdS1Su2Kfn5fOhsUDaajdVxNKrSutrE=; b=P5UGi+t2RbFUedRH/JFuZftY7bLikbv4GEEUAAXkhc52uZ/veMX+OmWv2RcNU6i3US d8dIuMSx5TuY1JRmH18kbdOXuQZMoGEpY6mZbQe7KDKfJPAyv27FujmckFBdfqy3QSs6 O3y2PLsQlMNPMS/7oasJOwOroli3pj448RKZiU10ePMuTTEaMPpdpWYA+Oik6tIIrUgK RcutOL0xcnxPhqa8fUTIMsPOzJ5XfifconA67IiqYtvotVBpQqL+acsjpw9+94SOOegc mtWGYIQDjTyb9gZMod38EK6dSRrMuJG7lw6SWdhQIMMFm+0ledz1912VS2D5HvDtJBqZ E3RA== MIME-Version: 1.0 Received: by 10.236.137.208 with SMTP id y56mr1536174yhi.58.1349266147826; Wed, 03 Oct 2012 05:09:07 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Wed, 3 Oct 2012 05:09:07 -0700 (PDT) In-Reply-To: <20121003114552.GS8912@reaktio.net> References: <20121002121932.GL8912@reaktio.net> <20121002144251.GP8912@reaktio.net> <20121003114552.GS8912@reaktio.net> Date: Wed, 3 Oct 2012 15:09:07 +0300 Message-ID: From: Valtteri Kiviniemi To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= Cc: Konrad Rzeszutek Wilk , Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.0.4, kernel 3.5.0 HVM crash and kernel BUG X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8386396748652710073==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============8386396748652710073== Content-Type: multipart/alternative; boundary=20cf303a2eb572dd5d04cb268168 --20cf303a2eb572dd5d04cb268168 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Yes, of course. I disabled these options: Processor type and features: [*] Numa Memory Allocation and Scheduler Support [*] ACPI NUMA detection Power management and ACPI options ---> ACPI (Advanced Configuration and Power Interface) Support -*- NUMA support Any Ideas howto debug the VNC problem any further? - Valtteri 2012/10/3 Pasi K=E4rkk=E4inen > On Wed, Oct 03, 2012 at 12:21:47PM +0300, Valtteri Kiviniemi wrote: > > Hi, > > > > I disabled NUMA and upgraded to Xen 4.2.0. Windows domU starts now > fine > > and I cant anymore reproduce the hotplug problems. VNC output is sti= ll > > just black screen and it actually crashes the the whole VNC client > when > > after a few seconds. RealVNC just shuts itself down and tightvnc > crashes. > > > > > Valtteri: Can you actually paste the names of the .config options you > disabled > and got the dom0 kernel working without crashes? > > Maybe Konrad can comment if the current upstream dom0 kernel is supposed > to work > with NUMA support enabled / compiled in? > > -- Pasi > > > - Valtteri > > > > 2012/10/2 Valtteri Kiviniemi <[1]kiviniemi.valtteri@gmail.com> > > > > Hi, > > > > Yes, they are all loaded and I'm running Linux PV-virtuals at the > same > > time with no problems. Only HVM is not working. I have single sock= et > > corei7 processor and NUMA enabled on dom0 kernel, so I will try > tomorrow > > to compile dom0 kernel without NUMA, since its not needed and it > could > > probably cause some kind of memory related problems. > > > > I will also try Debian squeezes package Xen and test if it is > working > > with my hardware. > > > > - Valtteri > > > > 2012/10/2 Konrad Rzeszutek Wilk <[2]konrad@kernel.org> > > > > On Tue, Oct 2, 2012 at 10:55 AM, Valtteri Kiviniemi > > <[3]kiviniemi.valtteri@gmail.com> wrote: > > > Hi, > > > > > > Yes, I understood for what the parameters were for. I'ts been = a > long > > time > > > since I last had major problems with Xen (maybe 3.1 or > something, > > been using > > > Xen since version 2) and I had a shady recollection that Xen w= as > > required to > > > be build debugging enabled in order to get any usable debuggin= g > > data. > > > > > > But anyway, I cant reproduce that kernel crash everytime, it > just > > happens > > > sometimes. Major problem is the black screen on VNC and second > > problem seems > > > to be that everytime i try to run Linux in HVM mode it somehow > > breaks the > > > hotplug scripts. > > > > > > > So do you have all backends loaded? Is xen-netback and xen-blkba= ck > > running? > > Do you also have tun loaded? > > > > References > > > > Visible links > > 1. mailto:kiviniemi.valtteri@gmail.com > > 2. mailto:konrad@kernel.org > > 3. mailto:kiviniemi.valtteri@gmail.com > --20cf303a2eb572dd5d04cb268168 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Yes, of course. I disabled these options:

Processor type = and features:
[*] Numa Memory Allocation and Scheduler Support
[*] AC= PI NUMA detection

Power management and ACPI options=A0 --->
AC= PI (Advanced Configuration and Power Interface) Support
-*-=A0=A0 NUMA support

Any Ideas howto debug the VNC problem any fur= ther?

- Valtteri

2012/10/3 Pasi K= =E4rkk=E4inen <pasik@iki.fi>
On Wed, Oct 03, 2012 at 12= :21:47PM +0300, Valtteri Kiviniemi wrote:
> =A0 =A0Hi,
>
> =A0 =A0I disabled NUMA and upgraded to Xen 4.2.0. Windows domU starts = now fine
> =A0 =A0and I cant anymore reproduce the hotplug problems. VNC output i= s still
> =A0 =A0just black screen and it actually crashes the the whole VNC cli= ent when
> =A0 =A0after a few seconds. RealVNC just shuts itself down and tightvn= c crashes.
>


Valtteri: Can you actually paste the names of the .config options you= disabled
and got the dom0 kernel working without crashes?

Maybe Konrad can comment if the current upstream dom0 kernel is supposed to= work
with NUMA support enabled / compiled in?

-- Pasi

> =A0 =A0- Valtteri
>
> =A0 =A02012/10/2 Valtteri Kiviniemi <[1]kiviniemi.valtteri@gmail.com>
>
> =A0 =A0 =A0Hi,
>
> =A0 =A0 =A0Yes, they are all loaded and I'm running Linux PV-virtu= als at the same
> =A0 =A0 =A0time with no problems. Only HVM is not working. I have sing= le socket
> =A0 =A0 =A0corei7 processor and NUMA enabled on dom0 kernel, so I will= try tomorrow
> =A0 =A0 =A0to compile dom0 kernel without NUMA, since its not needed a= nd it could
> =A0 =A0 =A0probably cause some kind of memory related problems.
>
> =A0 =A0 =A0I will also try Debian squeezes package Xen and test if it = is working
> =A0 =A0 =A0with my hardware.
>
> =A0 =A0 =A0- Valtteri
>
> =A0 =A0 =A02012/10/2 Konrad Rzeszutek Wilk <[2]konrad@kernel.org>
>
> =A0 =A0 =A0 =A0On Tue, Oct 2, 2012 at 10:55 AM, Valtteri Kiviniemi
> =A0 =A0 =A0 =A0<[3]kiviniemi.valtteri@gmail.com> wrote:
> =A0 =A0 =A0 =A0> Hi,
> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> Yes, I understood for what the parameters were for= . I'ts been a long
> =A0 =A0 =A0 =A0time
> =A0 =A0 =A0 =A0> since I last had major problems with Xen (maybe 3.= 1 or something,
> =A0 =A0 =A0 =A0been using
> =A0 =A0 =A0 =A0> Xen since version 2) and I had a shady recollectio= n that Xen was
> =A0 =A0 =A0 =A0required to
> =A0 =A0 =A0 =A0> be build debugging enabled in order to get any usa= ble debugging
> =A0 =A0 =A0 =A0data.
> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> But anyway, I cant reproduce that kernel crash eve= rytime, it just
> =A0 =A0 =A0 =A0happens
> =A0 =A0 =A0 =A0> sometimes. Major problem is the black screen on VN= C and second
> =A0 =A0 =A0 =A0problem seems
> =A0 =A0 =A0 =A0> to be that everytime i try to run Linux in HVM mod= e it somehow
> =A0 =A0 =A0 =A0breaks the
> =A0 =A0 =A0 =A0> hotplug scripts.
> =A0 =A0 =A0 =A0>
>
> =A0 =A0 =A0 =A0So do you have all backends loaded? Is xen-netback and = xen-blkback
> =A0 =A0 =A0 =A0running?
> =A0 =A0 =A0 =A0Do you also have tun loaded?
>
> References
>
> =A0 =A0Visible links
> =A0 =A01. mailto:kivin= iemi.valtteri@gmail.com
> =A0 =A02. mailto:konrad@kernel.or= g
> =A0 =A03. mailto:kivin= iemi.valtteri@gmail.com

--20cf303a2eb572dd5d04cb268168-- --===============8386396748652710073== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8386396748652710073==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 12:09:31 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 12:09:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJNlN-0001UO-CY; Wed, 03 Oct 2012 12:09:17 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJNlL-0001U9-Tn for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 12:09:16 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1349266148!8597049!1 X-Originating-IP: [209.85.213.173] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13934 invoked from network); 3 Oct 2012 12:09:09 -0000 Received: from mail-yx0-f173.google.com (HELO mail-yx0-f173.google.com) (209.85.213.173) by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 12:09:09 -0000 Received: by yenl3 with SMTP id l3so2201556yen.32 for ; Wed, 03 Oct 2012 05:09:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bonPAvhYJEbGAdS1Su2Kfn5fOhsUDaajdVxNKrSutrE=; b=P5UGi+t2RbFUedRH/JFuZftY7bLikbv4GEEUAAXkhc52uZ/veMX+OmWv2RcNU6i3US d8dIuMSx5TuY1JRmH18kbdOXuQZMoGEpY6mZbQe7KDKfJPAyv27FujmckFBdfqy3QSs6 O3y2PLsQlMNPMS/7oasJOwOroli3pj448RKZiU10ePMuTTEaMPpdpWYA+Oik6tIIrUgK RcutOL0xcnxPhqa8fUTIMsPOzJ5XfifconA67IiqYtvotVBpQqL+acsjpw9+94SOOegc mtWGYIQDjTyb9gZMod38EK6dSRrMuJG7lw6SWdhQIMMFm+0ledz1912VS2D5HvDtJBqZ E3RA== MIME-Version: 1.0 Received: by 10.236.137.208 with SMTP id y56mr1536174yhi.58.1349266147826; Wed, 03 Oct 2012 05:09:07 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Wed, 3 Oct 2012 05:09:07 -0700 (PDT) In-Reply-To: <20121003114552.GS8912@reaktio.net> References: <20121002121932.GL8912@reaktio.net> <20121002144251.GP8912@reaktio.net> <20121003114552.GS8912@reaktio.net> Date: Wed, 3 Oct 2012 15:09:07 +0300 Message-ID: From: Valtteri Kiviniemi To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= Cc: Konrad Rzeszutek Wilk , Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.0.4, kernel 3.5.0 HVM crash and kernel BUG X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8386396748652710073==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============8386396748652710073== Content-Type: multipart/alternative; boundary=20cf303a2eb572dd5d04cb268168 --20cf303a2eb572dd5d04cb268168 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Yes, of course. I disabled these options: Processor type and features: [*] Numa Memory Allocation and Scheduler Support [*] ACPI NUMA detection Power management and ACPI options ---> ACPI (Advanced Configuration and Power Interface) Support -*- NUMA support Any Ideas howto debug the VNC problem any further? - Valtteri 2012/10/3 Pasi K=E4rkk=E4inen > On Wed, Oct 03, 2012 at 12:21:47PM +0300, Valtteri Kiviniemi wrote: > > Hi, > > > > I disabled NUMA and upgraded to Xen 4.2.0. Windows domU starts now > fine > > and I cant anymore reproduce the hotplug problems. VNC output is sti= ll > > just black screen and it actually crashes the the whole VNC client > when > > after a few seconds. RealVNC just shuts itself down and tightvnc > crashes. > > > > > Valtteri: Can you actually paste the names of the .config options you > disabled > and got the dom0 kernel working without crashes? > > Maybe Konrad can comment if the current upstream dom0 kernel is supposed > to work > with NUMA support enabled / compiled in? > > -- Pasi > > > - Valtteri > > > > 2012/10/2 Valtteri Kiviniemi <[1]kiviniemi.valtteri@gmail.com> > > > > Hi, > > > > Yes, they are all loaded and I'm running Linux PV-virtuals at the > same > > time with no problems. Only HVM is not working. I have single sock= et > > corei7 processor and NUMA enabled on dom0 kernel, so I will try > tomorrow > > to compile dom0 kernel without NUMA, since its not needed and it > could > > probably cause some kind of memory related problems. > > > > I will also try Debian squeezes package Xen and test if it is > working > > with my hardware. > > > > - Valtteri > > > > 2012/10/2 Konrad Rzeszutek Wilk <[2]konrad@kernel.org> > > > > On Tue, Oct 2, 2012 at 10:55 AM, Valtteri Kiviniemi > > <[3]kiviniemi.valtteri@gmail.com> wrote: > > > Hi, > > > > > > Yes, I understood for what the parameters were for. I'ts been = a > long > > time > > > since I last had major problems with Xen (maybe 3.1 or > something, > > been using > > > Xen since version 2) and I had a shady recollection that Xen w= as > > required to > > > be build debugging enabled in order to get any usable debuggin= g > > data. > > > > > > But anyway, I cant reproduce that kernel crash everytime, it > just > > happens > > > sometimes. Major problem is the black screen on VNC and second > > problem seems > > > to be that everytime i try to run Linux in HVM mode it somehow > > breaks the > > > hotplug scripts. > > > > > > > So do you have all backends loaded? Is xen-netback and xen-blkba= ck > > running? > > Do you also have tun loaded? > > > > References > > > > Visible links > > 1. mailto:kiviniemi.valtteri@gmail.com > > 2. mailto:konrad@kernel.org > > 3. mailto:kiviniemi.valtteri@gmail.com > --20cf303a2eb572dd5d04cb268168 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Yes, of course. I disabled these options:

Processor type = and features:
[*] Numa Memory Allocation and Scheduler Support
[*] AC= PI NUMA detection

Power management and ACPI options=A0 --->
AC= PI (Advanced Configuration and Power Interface) Support
-*-=A0=A0 NUMA support

Any Ideas howto debug the VNC problem any fur= ther?

- Valtteri

2012/10/3 Pasi K= =E4rkk=E4inen <pasik@iki.fi>
On Wed, Oct 03, 2012 at 12= :21:47PM +0300, Valtteri Kiviniemi wrote:
> =A0 =A0Hi,
>
> =A0 =A0I disabled NUMA and upgraded to Xen 4.2.0. Windows domU starts = now fine
> =A0 =A0and I cant anymore reproduce the hotplug problems. VNC output i= s still
> =A0 =A0just black screen and it actually crashes the the whole VNC cli= ent when
> =A0 =A0after a few seconds. RealVNC just shuts itself down and tightvn= c crashes.
>


Valtteri: Can you actually paste the names of the .config options you= disabled
and got the dom0 kernel working without crashes?

Maybe Konrad can comment if the current upstream dom0 kernel is supposed to= work
with NUMA support enabled / compiled in?

-- Pasi

> =A0 =A0- Valtteri
>
> =A0 =A02012/10/2 Valtteri Kiviniemi <[1]kiviniemi.valtteri@gmail.com>
>
> =A0 =A0 =A0Hi,
>
> =A0 =A0 =A0Yes, they are all loaded and I'm running Linux PV-virtu= als at the same
> =A0 =A0 =A0time with no problems. Only HVM is not working. I have sing= le socket
> =A0 =A0 =A0corei7 processor and NUMA enabled on dom0 kernel, so I will= try tomorrow
> =A0 =A0 =A0to compile dom0 kernel without NUMA, since its not needed a= nd it could
> =A0 =A0 =A0probably cause some kind of memory related problems.
>
> =A0 =A0 =A0I will also try Debian squeezes package Xen and test if it = is working
> =A0 =A0 =A0with my hardware.
>
> =A0 =A0 =A0- Valtteri
>
> =A0 =A0 =A02012/10/2 Konrad Rzeszutek Wilk <[2]konrad@kernel.org>
>
> =A0 =A0 =A0 =A0On Tue, Oct 2, 2012 at 10:55 AM, Valtteri Kiviniemi
> =A0 =A0 =A0 =A0<[3]kiviniemi.valtteri@gmail.com> wrote:
> =A0 =A0 =A0 =A0> Hi,
> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> Yes, I understood for what the parameters were for= . I'ts been a long
> =A0 =A0 =A0 =A0time
> =A0 =A0 =A0 =A0> since I last had major problems with Xen (maybe 3.= 1 or something,
> =A0 =A0 =A0 =A0been using
> =A0 =A0 =A0 =A0> Xen since version 2) and I had a shady recollectio= n that Xen was
> =A0 =A0 =A0 =A0required to
> =A0 =A0 =A0 =A0> be build debugging enabled in order to get any usa= ble debugging
> =A0 =A0 =A0 =A0data.
> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0 =A0> But anyway, I cant reproduce that kernel crash eve= rytime, it just
> =A0 =A0 =A0 =A0happens
> =A0 =A0 =A0 =A0> sometimes. Major problem is the black screen on VN= C and second
> =A0 =A0 =A0 =A0problem seems
> =A0 =A0 =A0 =A0> to be that everytime i try to run Linux in HVM mod= e it somehow
> =A0 =A0 =A0 =A0breaks the
> =A0 =A0 =A0 =A0> hotplug scripts.
> =A0 =A0 =A0 =A0>
>
> =A0 =A0 =A0 =A0So do you have all backends loaded? Is xen-netback and = xen-blkback
> =A0 =A0 =A0 =A0running?
> =A0 =A0 =A0 =A0Do you also have tun loaded?
>
> References
>
> =A0 =A0Visible links
> =A0 =A01. mailto:kivin= iemi.valtteri@gmail.com
> =A0 =A02. mailto:konrad@kernel.or= g
> =A0 =A03. mailto:kivin= iemi.valtteri@gmail.com

--20cf303a2eb572dd5d04cb268168-- --===============8386396748652710073== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8386396748652710073==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 12:10:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 12:10:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJNmF-0001ZG-Re; Wed, 03 Oct 2012 12:10:11 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJNmE-0001Z0-Ks for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 12:10:10 +0000 Received: from [85.158.139.211:7568] by server-10.bemta-5.messagelabs.com id E4/B6-16911-12B2C605; Wed, 03 Oct 2012 12:10:09 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-206.messagelabs.com!1349266208!20918138!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18652 invoked from network); 3 Oct 2012 12:10:09 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 12:10:09 -0000 X-IronPort-AV: E=Sophos;i="4.80,527,1344211200"; d="scan'208";a="14913849" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 12:10:08 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 13:10:08 +0100 Message-ID: <1349266207.650.137.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Valtteri Kiviniemi Date: Wed, 3 Oct 2012 13:10:07 +0100 In-Reply-To: References: <1349259542.650.122.camel@zakaz.uk.xensource.com> <1349261397.650.130.camel@zakaz.uk.xensource.com> <1349263669.650.131.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Xen 4.2.0, xl toolstack cant launch older domUs X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-10-03 at 12:44 +0100, Valtteri Kiviniemi wrote: > Hi, > > Ok, well lets do it thisway. Hopefully I got this right this time. You did, thanks. (aside, can you not top-post please) A bit of a shot in the dark but what is the address size (i.e. 64 bit or 32 bit) for each of your hypervisor, dom0 and domU kernels? Does this change anything: xl cr -p lightning.cfg xenstore-write /local/domain/$(xl domid lightning)/device/vbd/51713/protocol x86_32-abi xl unpause lightning (this assumes the domains cfg is lightning.cfg and name is lightning) Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 12:10:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 12:10:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJNmF-0001ZG-Re; Wed, 03 Oct 2012 12:10:11 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJNmE-0001Z0-Ks for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 12:10:10 +0000 Received: from [85.158.139.211:7568] by server-10.bemta-5.messagelabs.com id E4/B6-16911-12B2C605; Wed, 03 Oct 2012 12:10:09 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-206.messagelabs.com!1349266208!20918138!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18652 invoked from network); 3 Oct 2012 12:10:09 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 12:10:09 -0000 X-IronPort-AV: E=Sophos;i="4.80,527,1344211200"; d="scan'208";a="14913849" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 12:10:08 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 13:10:08 +0100 Message-ID: <1349266207.650.137.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Valtteri Kiviniemi Date: Wed, 3 Oct 2012 13:10:07 +0100 In-Reply-To: References: <1349259542.650.122.camel@zakaz.uk.xensource.com> <1349261397.650.130.camel@zakaz.uk.xensource.com> <1349263669.650.131.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Xen 4.2.0, xl toolstack cant launch older domUs X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-10-03 at 12:44 +0100, Valtteri Kiviniemi wrote: > Hi, > > Ok, well lets do it thisway. Hopefully I got this right this time. You did, thanks. (aside, can you not top-post please) A bit of a shot in the dark but what is the address size (i.e. 64 bit or 32 bit) for each of your hypervisor, dom0 and domU kernels? Does this change anything: xl cr -p lightning.cfg xenstore-write /local/domain/$(xl domid lightning)/device/vbd/51713/protocol x86_32-abi xl unpause lightning (this assumes the domains cfg is lightning.cfg and name is lightning) Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 12:19:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 12:19:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJNv2-0001r1-T1; Wed, 03 Oct 2012 12:19:16 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJNv1-0001qw-9b for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 12:19:15 +0000 Received: from [85.158.143.99:34769] by server-3.bemta-4.messagelabs.com id A6/60-10986-24D2C605; Wed, 03 Oct 2012 12:19:14 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1349266752!24575366!1 X-Originating-IP: [209.85.161.173] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31877 invoked from network); 3 Oct 2012 12:19:13 -0000 Received: from mail-gg0-f173.google.com (HELO mail-gg0-f173.google.com) (209.85.161.173) by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 12:19:13 -0000 Received: by ggcs5 with SMTP id s5so617979ggc.32 for ; Wed, 03 Oct 2012 05:19:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ofdOi81/bn0aObIK70c0rrTH6qVtmhVfMguxsNpXWJM=; b=FFb4EEaMZ4DSj0AARpZvrQ+i3Gnp+Jzhl1XH7pTVSr2T7J3kJyOpUd0YRFDhhyCcRR vyVtftXd93JNUz6kxqFffUTS2DgV5NIMnhNQyuMDfkxON6vwj5/lCykKrjgJBuRnwMAt tRQFeMzEl2EWrGAxpZfFYIcYIQ/Fo85VIz1GRUnIDHNdSRn0gJIxWB67t5VSfSGQxNUf rcGns5Uomk29tkkE37klXuLziqIm8de/QM4V47cltEV6PhDoTxKfa3KFtPrMvNnWLV8b GOOLuGm1fgScyXiWgC6NlD1rYVXcmOyMYHpHQRYat+dUWK7IVnGF6hPBs6U1aFClhuFK xhJg== MIME-Version: 1.0 Received: by 10.101.3.13 with SMTP id f13mr485630ani.32.1349266752371; Wed, 03 Oct 2012 05:19:12 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Wed, 3 Oct 2012 05:19:12 -0700 (PDT) In-Reply-To: <1349266207.650.137.camel@zakaz.uk.xensource.com> References: <1349259542.650.122.camel@zakaz.uk.xensource.com> <1349261397.650.130.camel@zakaz.uk.xensource.com> <1349263669.650.131.camel@zakaz.uk.xensource.com> <1349266207.650.137.camel@zakaz.uk.xensource.com> Date: Wed, 3 Oct 2012 15:19:12 +0300 Message-ID: From: Valtteri Kiviniemi To: Ian Campbell Cc: "Xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Xen 4.2.0, xl toolstack cant launch older domUs X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1981248489624487695==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============1981248489624487695== Content-Type: multipart/alternative; boundary=0016369fa3a27b7b0d04cb26a550 --0016369fa3a27b7b0d04cb26a550 Content-Type: text/plain; charset=ISO-8859-1 2012/10/3 Ian Campbell > On Wed, 2012-10-03 at 12:44 +0100, Valtteri Kiviniemi wrote: > > Hi, > > > > Ok, well lets do it thisway. Hopefully I got this right this time. > > You did, thanks. (aside, can you not top-post please) > > A bit of a shot in the dark but what is the address size (i.e. 64 bit or > 32 bit) for each of your hypervisor, dom0 and domU kernels? > > Does this change anything: > xl cr -p lightning.cfg > xenstore-write /local/domain/$(xl domid > lightning)/device/vbd/51713/protocol x86_32-abi > xl unpause lightning > > (this assumes the domains cfg is lightning.cfg and name is lightning) > > Ian. > > Hi, Sorry for the top posting, I'm at work at the moment and using different mail client which is is configured for top posting and I was too lazy to change it. But that did do the trick, the domU is now fillu booting and working! - Valtteri --0016369fa3a27b7b0d04cb26a550 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
2012/10/3 Ian Campbell <Ian.Campbell@citrix.com>
On Wed, 2012-10-03 at 12:44 +0100, Valtteri Kiviniemi wro= te:
> Hi,
>
> Ok, well lets do it thisway. Hopefully I got this right this time.

You did, thanks. (aside, can you not top-post please)

A bit of a shot in the dark but what is the address size (i.e. 64 bit or 32 bit) for each of your hypervisor, dom0 and domU kernels?

Does this change anything:
=A0 =A0 =A0 =A0 xl cr -p lightning.cfg
=A0 =A0 =A0 =A0 xenstore-write /local/domain/$(xl domid lightning)/device/v= bd/51713/protocol x86_32-abi
=A0 =A0 =A0 =A0 xl unpause lightning

(this assumes the domains cfg is lightning.cfg and name is lightning)

Ian.


Hi,

Sorry for the top postin= g, I'm at work at the moment and using different mail client which is i= s configured for top posting and I was too lazy to change it.

But th= at did do the trick, the domU is now fillu booting and working!

- Valtteri

--0016369fa3a27b7b0d04cb26a550-- --===============1981248489624487695== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============1981248489624487695==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 12:19:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 12:19:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJNv2-0001r1-T1; Wed, 03 Oct 2012 12:19:16 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJNv1-0001qw-9b for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 12:19:15 +0000 Received: from [85.158.143.99:34769] by server-3.bemta-4.messagelabs.com id A6/60-10986-24D2C605; Wed, 03 Oct 2012 12:19:14 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1349266752!24575366!1 X-Originating-IP: [209.85.161.173] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31877 invoked from network); 3 Oct 2012 12:19:13 -0000 Received: from mail-gg0-f173.google.com (HELO mail-gg0-f173.google.com) (209.85.161.173) by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 12:19:13 -0000 Received: by ggcs5 with SMTP id s5so617979ggc.32 for ; Wed, 03 Oct 2012 05:19:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ofdOi81/bn0aObIK70c0rrTH6qVtmhVfMguxsNpXWJM=; b=FFb4EEaMZ4DSj0AARpZvrQ+i3Gnp+Jzhl1XH7pTVSr2T7J3kJyOpUd0YRFDhhyCcRR vyVtftXd93JNUz6kxqFffUTS2DgV5NIMnhNQyuMDfkxON6vwj5/lCykKrjgJBuRnwMAt tRQFeMzEl2EWrGAxpZfFYIcYIQ/Fo85VIz1GRUnIDHNdSRn0gJIxWB67t5VSfSGQxNUf rcGns5Uomk29tkkE37klXuLziqIm8de/QM4V47cltEV6PhDoTxKfa3KFtPrMvNnWLV8b GOOLuGm1fgScyXiWgC6NlD1rYVXcmOyMYHpHQRYat+dUWK7IVnGF6hPBs6U1aFClhuFK xhJg== MIME-Version: 1.0 Received: by 10.101.3.13 with SMTP id f13mr485630ani.32.1349266752371; Wed, 03 Oct 2012 05:19:12 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Wed, 3 Oct 2012 05:19:12 -0700 (PDT) In-Reply-To: <1349266207.650.137.camel@zakaz.uk.xensource.com> References: <1349259542.650.122.camel@zakaz.uk.xensource.com> <1349261397.650.130.camel@zakaz.uk.xensource.com> <1349263669.650.131.camel@zakaz.uk.xensource.com> <1349266207.650.137.camel@zakaz.uk.xensource.com> Date: Wed, 3 Oct 2012 15:19:12 +0300 Message-ID: From: Valtteri Kiviniemi To: Ian Campbell Cc: "Xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Xen 4.2.0, xl toolstack cant launch older domUs X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1981248489624487695==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============1981248489624487695== Content-Type: multipart/alternative; boundary=0016369fa3a27b7b0d04cb26a550 --0016369fa3a27b7b0d04cb26a550 Content-Type: text/plain; charset=ISO-8859-1 2012/10/3 Ian Campbell > On Wed, 2012-10-03 at 12:44 +0100, Valtteri Kiviniemi wrote: > > Hi, > > > > Ok, well lets do it thisway. Hopefully I got this right this time. > > You did, thanks. (aside, can you not top-post please) > > A bit of a shot in the dark but what is the address size (i.e. 64 bit or > 32 bit) for each of your hypervisor, dom0 and domU kernels? > > Does this change anything: > xl cr -p lightning.cfg > xenstore-write /local/domain/$(xl domid > lightning)/device/vbd/51713/protocol x86_32-abi > xl unpause lightning > > (this assumes the domains cfg is lightning.cfg and name is lightning) > > Ian. > > Hi, Sorry for the top posting, I'm at work at the moment and using different mail client which is is configured for top posting and I was too lazy to change it. But that did do the trick, the domU is now fillu booting and working! - Valtteri --0016369fa3a27b7b0d04cb26a550 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
2012/10/3 Ian Campbell <Ian.Campbell@citrix.com>
On Wed, 2012-10-03 at 12:44 +0100, Valtteri Kiviniemi wro= te:
> Hi,
>
> Ok, well lets do it thisway. Hopefully I got this right this time.

You did, thanks. (aside, can you not top-post please)

A bit of a shot in the dark but what is the address size (i.e. 64 bit or 32 bit) for each of your hypervisor, dom0 and domU kernels?

Does this change anything:
=A0 =A0 =A0 =A0 xl cr -p lightning.cfg
=A0 =A0 =A0 =A0 xenstore-write /local/domain/$(xl domid lightning)/device/v= bd/51713/protocol x86_32-abi
=A0 =A0 =A0 =A0 xl unpause lightning

(this assumes the domains cfg is lightning.cfg and name is lightning)

Ian.


Hi,

Sorry for the top postin= g, I'm at work at the moment and using different mail client which is i= s configured for top posting and I was too lazy to change it.

But th= at did do the trick, the domU is now fillu booting and working!

- Valtteri

--0016369fa3a27b7b0d04cb26a550-- --===============1981248489624487695== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============1981248489624487695==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 12:26:14 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 12:26:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJO1X-00020s-Og; Wed, 03 Oct 2012 12:25:59 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJO1W-00020n-63 for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 12:25:58 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1349267149!9987261!1 X-Originating-IP: [209.85.213.173] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16804 invoked from network); 3 Oct 2012 12:25:50 -0000 Received: from mail-yx0-f173.google.com (HELO mail-yx0-f173.google.com) (209.85.213.173) by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 12:25:50 -0000 Received: by yenl3 with SMTP id l3so2206022yen.32 for ; Wed, 03 Oct 2012 05:25:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=stttbJszztUwLlJBuv37BAc54jryytLE+SGPp7KX9B4=; b=MG5swVHo96VLPUUjWcEO8+joEtgAI+ut7ierGtz0LdjNyFXW0DJvEjOn7fOaBi+itk yuJ9ELI2322WFrDmNl7P0I8bjIZ5MwTOj9l9kCgpsLveLMIIkaWBGxvQJvhzjnzDXkFB S0ixkVO+lpIq+hV1QjAOKo2dokWyOQca8pdigx+rJv+3DzMhoNDeaLlsjefvxyo0oDZv 02cJj2GTABxOJO3jEK6yUACj3IRZFB00QZLtLZMlaDdeMiDGNmY023WFO8zlQvP+gGhB TXuQtBMCrKPjEjHi9lGH7my/9NWYkJoMzUxyGXqsx8Aw2e0cpPVu4pViWp3s8S6giW/D 2y0A== MIME-Version: 1.0 Received: by 10.236.193.105 with SMTP id j69mr1676457yhn.21.1349267149246; Wed, 03 Oct 2012 05:25:49 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Wed, 3 Oct 2012 05:25:49 -0700 (PDT) In-Reply-To: References: <1349259542.650.122.camel@zakaz.uk.xensource.com> <1349261397.650.130.camel@zakaz.uk.xensource.com> <1349263669.650.131.camel@zakaz.uk.xensource.com> <1349266207.650.137.camel@zakaz.uk.xensource.com> Date: Wed, 3 Oct 2012 15:25:49 +0300 Message-ID: From: Valtteri Kiviniemi To: Ian Campbell Cc: "Xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Xen 4.2.0, xl toolstack cant launch older domUs X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8818456853090995276==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============8818456853090995276== Content-Type: multipart/alternative; boundary=20cf30563c0d2351de04cb26bdee --20cf30563c0d2351de04cb26bdee Content-Type: text/plain; charset=ISO-8859-1 2012/10/3 Valtteri Kiviniemi > > 2012/10/3 Ian Campbell > >> On Wed, 2012-10-03 at 12:44 +0100, Valtteri Kiviniemi wrote: >> > Hi, >> > >> > Ok, well lets do it thisway. Hopefully I got this right this time. >> >> You did, thanks. (aside, can you not top-post please) >> >> A bit of a shot in the dark but what is the address size (i.e. 64 bit or >> 32 bit) for each of your hypervisor, dom0 and domU kernels? >> >> Does this change anything: >> xl cr -p lightning.cfg >> xenstore-write /local/domain/$(xl domid >> lightning)/device/vbd/51713/protocol x86_32-abi >> xl unpause lightning >> >> (this assumes the domains cfg is lightning.cfg and name is lightning) >> >> Ian. >> >> > Hi, > > Sorry for the top posting, I'm at work at the moment and using different > mail client which is is configured for top posting and I was too lazy to > change it. > > But that did do the trick, the domU is now fillu booting and working! > > - Valtteri > > Hi, dom0 is 64bit, hypervisor is 64bit and that domU (lightning) is 32bit. - Valtteri --20cf30563c0d2351de04cb26bdee Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/10/3 Valtteri Kiviniemi <kiviniemi.valtteri@gmail.com>

2012/10/3 Ian Campbell <Ian.Campbell@citrix.com>
On Wed, 2012-10-03 at 12:44 +0100, Valtteri Kiviniemi wrote:
> Hi,
>
> Ok, well lets do it thisway. Hopefully I got this right this time.

You did, thanks. (aside, can you not top-post please)

A bit of a shot in the dark but what is the address size (i.e. 64 bit or 32 bit) for each of your hypervisor, dom0 and domU kernels?

Does this change anything:
=A0 =A0 =A0 =A0 xl cr -p lightning.cfg
=A0 =A0 =A0 =A0 xenstore-write /local/domain/$(xl domid lightning)/device/v= bd/51713/protocol x86_32-abi
=A0 =A0 =A0 =A0 xl unpause lightning

(this assumes the domains cfg is lightning.cfg and name is lightning)

Ian.


Hi,

Sorry for th= e top posting, I'm at work at the moment and using different mail clien= t which is is configured for top posting and I was too lazy to change it.
But that did do the trick, the domU is now fillu booting and working!

- Valtteri


Hi,

dom0 is 64bit, hypervisor is 64bit and th= at domU (lightning) is 32bit.

- Valtteri
--20cf30563c0d2351de04cb26bdee-- --===============8818456853090995276== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8818456853090995276==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 12:26:14 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 12:26:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJO1X-00020s-Og; Wed, 03 Oct 2012 12:25:59 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJO1W-00020n-63 for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 12:25:58 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1349267149!9987261!1 X-Originating-IP: [209.85.213.173] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16804 invoked from network); 3 Oct 2012 12:25:50 -0000 Received: from mail-yx0-f173.google.com (HELO mail-yx0-f173.google.com) (209.85.213.173) by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 12:25:50 -0000 Received: by yenl3 with SMTP id l3so2206022yen.32 for ; Wed, 03 Oct 2012 05:25:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=stttbJszztUwLlJBuv37BAc54jryytLE+SGPp7KX9B4=; b=MG5swVHo96VLPUUjWcEO8+joEtgAI+ut7ierGtz0LdjNyFXW0DJvEjOn7fOaBi+itk yuJ9ELI2322WFrDmNl7P0I8bjIZ5MwTOj9l9kCgpsLveLMIIkaWBGxvQJvhzjnzDXkFB S0ixkVO+lpIq+hV1QjAOKo2dokWyOQca8pdigx+rJv+3DzMhoNDeaLlsjefvxyo0oDZv 02cJj2GTABxOJO3jEK6yUACj3IRZFB00QZLtLZMlaDdeMiDGNmY023WFO8zlQvP+gGhB TXuQtBMCrKPjEjHi9lGH7my/9NWYkJoMzUxyGXqsx8Aw2e0cpPVu4pViWp3s8S6giW/D 2y0A== MIME-Version: 1.0 Received: by 10.236.193.105 with SMTP id j69mr1676457yhn.21.1349267149246; Wed, 03 Oct 2012 05:25:49 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Wed, 3 Oct 2012 05:25:49 -0700 (PDT) In-Reply-To: References: <1349259542.650.122.camel@zakaz.uk.xensource.com> <1349261397.650.130.camel@zakaz.uk.xensource.com> <1349263669.650.131.camel@zakaz.uk.xensource.com> <1349266207.650.137.camel@zakaz.uk.xensource.com> Date: Wed, 3 Oct 2012 15:25:49 +0300 Message-ID: From: Valtteri Kiviniemi To: Ian Campbell Cc: "Xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Xen 4.2.0, xl toolstack cant launch older domUs X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8818456853090995276==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============8818456853090995276== Content-Type: multipart/alternative; boundary=20cf30563c0d2351de04cb26bdee --20cf30563c0d2351de04cb26bdee Content-Type: text/plain; charset=ISO-8859-1 2012/10/3 Valtteri Kiviniemi > > 2012/10/3 Ian Campbell > >> On Wed, 2012-10-03 at 12:44 +0100, Valtteri Kiviniemi wrote: >> > Hi, >> > >> > Ok, well lets do it thisway. Hopefully I got this right this time. >> >> You did, thanks. (aside, can you not top-post please) >> >> A bit of a shot in the dark but what is the address size (i.e. 64 bit or >> 32 bit) for each of your hypervisor, dom0 and domU kernels? >> >> Does this change anything: >> xl cr -p lightning.cfg >> xenstore-write /local/domain/$(xl domid >> lightning)/device/vbd/51713/protocol x86_32-abi >> xl unpause lightning >> >> (this assumes the domains cfg is lightning.cfg and name is lightning) >> >> Ian. >> >> > Hi, > > Sorry for the top posting, I'm at work at the moment and using different > mail client which is is configured for top posting and I was too lazy to > change it. > > But that did do the trick, the domU is now fillu booting and working! > > - Valtteri > > Hi, dom0 is 64bit, hypervisor is 64bit and that domU (lightning) is 32bit. - Valtteri --20cf30563c0d2351de04cb26bdee Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/10/3 Valtteri Kiviniemi <kiviniemi.valtteri@gmail.com>

2012/10/3 Ian Campbell <Ian.Campbell@citrix.com>
On Wed, 2012-10-03 at 12:44 +0100, Valtteri Kiviniemi wrote:
> Hi,
>
> Ok, well lets do it thisway. Hopefully I got this right this time.

You did, thanks. (aside, can you not top-post please)

A bit of a shot in the dark but what is the address size (i.e. 64 bit or 32 bit) for each of your hypervisor, dom0 and domU kernels?

Does this change anything:
=A0 =A0 =A0 =A0 xl cr -p lightning.cfg
=A0 =A0 =A0 =A0 xenstore-write /local/domain/$(xl domid lightning)/device/v= bd/51713/protocol x86_32-abi
=A0 =A0 =A0 =A0 xl unpause lightning

(this assumes the domains cfg is lightning.cfg and name is lightning)

Ian.


Hi,

Sorry for th= e top posting, I'm at work at the moment and using different mail clien= t which is is configured for top posting and I was too lazy to change it.
But that did do the trick, the domU is now fillu booting and working!

- Valtteri


Hi,

dom0 is 64bit, hypervisor is 64bit and th= at domU (lightning) is 32bit.

- Valtteri
--20cf30563c0d2351de04cb26bdee-- --===============8818456853090995276== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8818456853090995276==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 12:36:11 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 12:36:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOB7-0002CI-09; Wed, 03 Oct 2012 12:35:53 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOB5-0002CC-7S for xen-devel@lists.xen.org; Wed, 03 Oct 2012 12:35:51 +0000 Received: from [85.158.138.51:41923] by server-11.bemta-3.messagelabs.com id FE/19-21460-6213C605; Wed, 03 Oct 2012 12:35:50 +0000 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1349267748!24056525!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzk2MzY=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20614 invoked from network); 3 Oct 2012 12:35:49 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 12:35:49 -0000 X-IronPort-AV: E=Sophos;i="4.80,527,1344211200"; d="scan'208";a="210144048" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 12:35:47 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 08:35:47 -0400 Received: from andrewcoop.uk.xensource.com ([10.80.2.18]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJOB1-0003ln-9b; Wed, 03 Oct 2012 13:35:47 +0100 Message-ID: <506C3123.5050700@citrix.com> Date: Wed, 3 Oct 2012 13:35:47 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: "xen-devel@lists.xen.org" , Dario Faggioli , Keir Fraser , Jan Beulich X-Enigmail-Version: 1.4.4 Content-Type: multipart/mixed; boundary="------------070906060006040201060901" Subject: [Xen-devel] sedf/build: Fix build when using -fno-inline X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --------------070906060006040201060901 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit I found this issue while trying to debug on a separate issue. It certainly affects unstable thru 4.1, and probably earlier, so should be take for backport. -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com --------------070906060006040201060901 Content-Type: text/x-patch; name="fix-no-inline-build.patch" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="fix-no-inline-build.patch" # HG changeset patch # Parent 5fbdbf585f5f2ee9a3e3c75a8a9f9f2cc6eda65c build: Fix build when using -fno-inline struct task_slice.migrated is not initialised by this function, and subsequently returned by value, leading to the error: sched_sedf.c: In function ‘sedf_do_extra_schedule’: sched_sedf.c:711: error: ‘ret.migrated’ may be used uninitialised in this function for both gcc 4.1.2 and 4.4.3 (which are the two I have easily to hand) when combined with the -fno-inline compile option. Signed-off-by Andrew Cooper -- This is compile tested only, but given that the sole caller of sedf_do_extra_schedule() unconditionally sets migrated to 0, I am fairly confident of the correctness of the fix. diff -r 5fbdbf585f5f xen/common/sched_sedf.c --- a/xen/common/sched_sedf.c +++ b/xen/common/sched_sedf.c @@ -667,7 +667,7 @@ static void desched_extra_dom(s_time_t n static struct task_slice sedf_do_extra_schedule( s_time_t now, s_time_t end_xt, struct list_head *extraq[], int cpu) { - struct task_slice ret; + struct task_slice ret = { 0 }; struct sedf_vcpu_info *runinf; ASSERT(end_xt > now); --------------070906060006040201060901 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --------------070906060006040201060901-- From xen-devel-bounces@lists.xen.org Wed Oct 03 12:36:11 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 12:36:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOB7-0002CI-09; Wed, 03 Oct 2012 12:35:53 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOB5-0002CC-7S for xen-devel@lists.xen.org; Wed, 03 Oct 2012 12:35:51 +0000 Received: from [85.158.138.51:41923] by server-11.bemta-3.messagelabs.com id FE/19-21460-6213C605; Wed, 03 Oct 2012 12:35:50 +0000 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1349267748!24056525!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzk2MzY=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20614 invoked from network); 3 Oct 2012 12:35:49 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 12:35:49 -0000 X-IronPort-AV: E=Sophos;i="4.80,527,1344211200"; d="scan'208";a="210144048" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 12:35:47 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 08:35:47 -0400 Received: from andrewcoop.uk.xensource.com ([10.80.2.18]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJOB1-0003ln-9b; Wed, 03 Oct 2012 13:35:47 +0100 Message-ID: <506C3123.5050700@citrix.com> Date: Wed, 3 Oct 2012 13:35:47 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: "xen-devel@lists.xen.org" , Dario Faggioli , Keir Fraser , Jan Beulich X-Enigmail-Version: 1.4.4 Content-Type: multipart/mixed; boundary="------------070906060006040201060901" Subject: [Xen-devel] sedf/build: Fix build when using -fno-inline X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --------------070906060006040201060901 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit I found this issue while trying to debug on a separate issue. It certainly affects unstable thru 4.1, and probably earlier, so should be take for backport. -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com --------------070906060006040201060901 Content-Type: text/x-patch; name="fix-no-inline-build.patch" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="fix-no-inline-build.patch" # HG changeset patch # Parent 5fbdbf585f5f2ee9a3e3c75a8a9f9f2cc6eda65c build: Fix build when using -fno-inline struct task_slice.migrated is not initialised by this function, and subsequently returned by value, leading to the error: sched_sedf.c: In function ‘sedf_do_extra_schedule’: sched_sedf.c:711: error: ‘ret.migrated’ may be used uninitialised in this function for both gcc 4.1.2 and 4.4.3 (which are the two I have easily to hand) when combined with the -fno-inline compile option. Signed-off-by Andrew Cooper -- This is compile tested only, but given that the sole caller of sedf_do_extra_schedule() unconditionally sets migrated to 0, I am fairly confident of the correctness of the fix. diff -r 5fbdbf585f5f xen/common/sched_sedf.c --- a/xen/common/sched_sedf.c +++ b/xen/common/sched_sedf.c @@ -667,7 +667,7 @@ static void desched_extra_dom(s_time_t n static struct task_slice sedf_do_extra_schedule( s_time_t now, s_time_t end_xt, struct list_head *extraq[], int cpu) { - struct task_slice ret; + struct task_slice ret = { 0 }; struct sedf_vcpu_info *runinf; ASSERT(end_xt > now); --------------070906060006040201060901 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --------------070906060006040201060901-- From xen-devel-bounces@lists.xen.org Wed Oct 03 12:38:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 12:38:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJODB-0002HY-HI; Wed, 03 Oct 2012 12:38:01 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOD9-0002HR-Ef for Xen-devel@lists.xensource.com; Wed, 03 Oct 2012 12:37:59 +0000 Received: from [85.158.138.51:55102] by server-14.bemta-3.messagelabs.com id 74/B0-25886-6A13C605; Wed, 03 Oct 2012 12:37:58 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1349267877!32924204!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4592 invoked from network); 3 Oct 2012 12:37:58 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 12:37:58 -0000 X-IronPort-AV: E=Sophos;i="4.80,527,1344211200"; d="scan'208";a="14914854" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 12:37:50 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 13:37:50 +0100 Date: Wed, 3 Oct 2012 13:36:50 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Ian Campbell In-Reply-To: <1349265914.650.136.camel@zakaz.uk.xensource.com> Message-ID: References: <20120921121659.5a723de9@mantra.us.oracle.com> <20120924154335.097d3fb9@mantra.us.oracle.com> <20120925180416.0137d61a@mantra.us.oracle.com> <20121002183619.70734b7a@mantra.us.oracle.com> <20121002190323.2e16f6ff@mantra.us.oracle.com> <1349265914.650.136.camel@zakaz.uk.xensource.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v1 3/8]: PVH startup changes (enlighten.c) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 3 Oct 2012, Ian Campbell wrote: > On Wed, 2012-10-03 at 12:58 +0100, Stefano Stabellini wrote: > > > So for now, how about, lets go > > > with what I've got. I'll make a note, and when I do xen patch, I'll > > > figure it out, and would be a very small linux patch. I want to get > > > linux patch in soon before the window closes. > > > > We can leave page special as it is for now with very little > > consequences, because it is not part of the interface with Xen. However > > this is part of the interface, so whatever we choose here is going to be > > hard to change later on. > > I suggested that until we have seen and reviewed the hypervisor side > patches this guest side functionality all needs to be under an option > which has CONFIG_EXPERIMENTAL as a dependency and a comment explaining > that the ABI is not fixed yet, similar to what we did for the ARM port. OK. In that case we can also keep the pfn/mfn issue as it is and change it later. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 12:38:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 12:38:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJODB-0002HY-HI; Wed, 03 Oct 2012 12:38:01 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOD9-0002HR-Ef for Xen-devel@lists.xensource.com; Wed, 03 Oct 2012 12:37:59 +0000 Received: from [85.158.138.51:55102] by server-14.bemta-3.messagelabs.com id 74/B0-25886-6A13C605; Wed, 03 Oct 2012 12:37:58 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1349267877!32924204!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4592 invoked from network); 3 Oct 2012 12:37:58 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 12:37:58 -0000 X-IronPort-AV: E=Sophos;i="4.80,527,1344211200"; d="scan'208";a="14914854" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 12:37:50 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 13:37:50 +0100 Date: Wed, 3 Oct 2012 13:36:50 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Ian Campbell In-Reply-To: <1349265914.650.136.camel@zakaz.uk.xensource.com> Message-ID: References: <20120921121659.5a723de9@mantra.us.oracle.com> <20120924154335.097d3fb9@mantra.us.oracle.com> <20120925180416.0137d61a@mantra.us.oracle.com> <20121002183619.70734b7a@mantra.us.oracle.com> <20121002190323.2e16f6ff@mantra.us.oracle.com> <1349265914.650.136.camel@zakaz.uk.xensource.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v1 3/8]: PVH startup changes (enlighten.c) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 3 Oct 2012, Ian Campbell wrote: > On Wed, 2012-10-03 at 12:58 +0100, Stefano Stabellini wrote: > > > So for now, how about, lets go > > > with what I've got. I'll make a note, and when I do xen patch, I'll > > > figure it out, and would be a very small linux patch. I want to get > > > linux patch in soon before the window closes. > > > > We can leave page special as it is for now with very little > > consequences, because it is not part of the interface with Xen. However > > this is part of the interface, so whatever we choose here is going to be > > hard to change later on. > > I suggested that until we have seen and reviewed the hypervisor side > patches this guest side functionality all needs to be under an option > which has CONFIG_EXPERIMENTAL as a dependency and a comment explaining > that the ABI is not fixed yet, similar to what we did for the ARM port. OK. In that case we can also keep the pfn/mfn issue as it is and change it later. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 12:39:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 12:39:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJODx-0002MS-V2; Wed, 03 Oct 2012 12:38:49 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJODw-0002MH-An for xen-devel@lists.xen.org; Wed, 03 Oct 2012 12:38:48 +0000 Received: from [85.158.138.51:60977] by server-2.bemta-3.messagelabs.com id A4/90-16514-7D13C605; Wed, 03 Oct 2012 12:38:47 +0000 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1349267922!32880721!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzM2MzM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14169 invoked from network); 3 Oct 2012 12:38:46 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 12:38:46 -0000 X-IronPort-AV: E=Sophos;i="4.80,527,1344211200"; d="scan'208";a="39985867" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 12:38:41 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 08:38:41 -0400 Received: from andrewcoop.uk.xensource.com ([10.80.2.18]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJODo-0003oO-Pk; Wed, 03 Oct 2012 13:38:40 +0100 Message-ID: <506C31D0.4060702@citrix.com> Date: Wed, 3 Oct 2012 13:38:40 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: "xen-devel@lists.xen.org" , Dario Faggioli , "Keir (Xen.org)" , Jan Beulich References: <506C3123.5050700@citrix.com> In-Reply-To: <506C3123.5050700@citrix.com> X-Enigmail-Version: 1.4.4 Content-Type: multipart/mixed; boundary="------------030701010504020102080609" Subject: Re: [Xen-devel] [Xen-devel V2] sedf/build: Fix build when using -fno-inline X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --------------030701010504020102080609 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 03/10/12 13:35, Andrew Cooper wrote: > I found this issue while trying to debug on a separate issue. It > certainly affects unstable thru 4.1, and probably earlier, so should be > take for backport. > Apologies - try this patch which has less Unicode in the commit message. -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com --------------030701010504020102080609 Content-Type: text/x-patch; name="fix-no-inline-build.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="fix-no-inline-build.patch" # HG changeset patch # Parent 5fbdbf585f5f2ee9a3e3c75a8a9f9f2cc6eda65c sedf/build: Fix build when using -fno-inline struct task_slice.migrated is not initialised by this function, and subsequently returned by value, leading to the error: sched_sedf.c: In function 'sedf_do_extra_schedule': sched_sedf.c:711: error: 'ret.migrated' may be used uninitialised in this function for both gcc 4.1.2 and 4.4.3 (which are the two I have easily to hand) when combined with the -fno-inline compile option. Signed-off-by Andrew Cooper -- This is compile tested only, but given that the sole caller of sedf_do_extra_schedule() unconditionally sets migrated to 0, I am fairly confident of the correctness of the fix. Changes since v1: - Fix unicode issue in comment. diff -r 5fbdbf585f5f xen/common/sched_sedf.c --- a/xen/common/sched_sedf.c +++ b/xen/common/sched_sedf.c @@ -667,7 +667,7 @@ static void desched_extra_dom(s_time_t n static struct task_slice sedf_do_extra_schedule( s_time_t now, s_time_t end_xt, struct list_head *extraq[], int cpu) { - struct task_slice ret; + struct task_slice ret = { 0 }; struct sedf_vcpu_info *runinf; ASSERT(end_xt > now); --------------030701010504020102080609 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --------------030701010504020102080609-- From xen-devel-bounces@lists.xen.org Wed Oct 03 12:39:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 12:39:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJODx-0002MS-V2; Wed, 03 Oct 2012 12:38:49 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJODw-0002MH-An for xen-devel@lists.xen.org; Wed, 03 Oct 2012 12:38:48 +0000 Received: from [85.158.138.51:60977] by server-2.bemta-3.messagelabs.com id A4/90-16514-7D13C605; Wed, 03 Oct 2012 12:38:47 +0000 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1349267922!32880721!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzM2MzM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14169 invoked from network); 3 Oct 2012 12:38:46 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 12:38:46 -0000 X-IronPort-AV: E=Sophos;i="4.80,527,1344211200"; d="scan'208";a="39985867" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 12:38:41 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 08:38:41 -0400 Received: from andrewcoop.uk.xensource.com ([10.80.2.18]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJODo-0003oO-Pk; Wed, 03 Oct 2012 13:38:40 +0100 Message-ID: <506C31D0.4060702@citrix.com> Date: Wed, 3 Oct 2012 13:38:40 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: "xen-devel@lists.xen.org" , Dario Faggioli , "Keir (Xen.org)" , Jan Beulich References: <506C3123.5050700@citrix.com> In-Reply-To: <506C3123.5050700@citrix.com> X-Enigmail-Version: 1.4.4 Content-Type: multipart/mixed; boundary="------------030701010504020102080609" Subject: Re: [Xen-devel] [Xen-devel V2] sedf/build: Fix build when using -fno-inline X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --------------030701010504020102080609 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 03/10/12 13:35, Andrew Cooper wrote: > I found this issue while trying to debug on a separate issue. It > certainly affects unstable thru 4.1, and probably earlier, so should be > take for backport. > Apologies - try this patch which has less Unicode in the commit message. -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com --------------030701010504020102080609 Content-Type: text/x-patch; name="fix-no-inline-build.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="fix-no-inline-build.patch" # HG changeset patch # Parent 5fbdbf585f5f2ee9a3e3c75a8a9f9f2cc6eda65c sedf/build: Fix build when using -fno-inline struct task_slice.migrated is not initialised by this function, and subsequently returned by value, leading to the error: sched_sedf.c: In function 'sedf_do_extra_schedule': sched_sedf.c:711: error: 'ret.migrated' may be used uninitialised in this function for both gcc 4.1.2 and 4.4.3 (which are the two I have easily to hand) when combined with the -fno-inline compile option. Signed-off-by Andrew Cooper -- This is compile tested only, but given that the sole caller of sedf_do_extra_schedule() unconditionally sets migrated to 0, I am fairly confident of the correctness of the fix. Changes since v1: - Fix unicode issue in comment. diff -r 5fbdbf585f5f xen/common/sched_sedf.c --- a/xen/common/sched_sedf.c +++ b/xen/common/sched_sedf.c @@ -667,7 +667,7 @@ static void desched_extra_dom(s_time_t n static struct task_slice sedf_do_extra_schedule( s_time_t now, s_time_t end_xt, struct list_head *extraq[], int cpu) { - struct task_slice ret; + struct task_slice ret = { 0 }; struct sedf_vcpu_info *runinf; ASSERT(end_xt > now); --------------030701010504020102080609 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --------------030701010504020102080609-- From xen-devel-bounces@lists.xen.org Wed Oct 03 12:45:55 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 12:45:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOKa-0002fN-RE; Wed, 03 Oct 2012 12:45:40 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOKZ-0002fI-F2 for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 12:45:39 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1349268331!7208581!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzgwMzQw\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21431 invoked from network); 3 Oct 2012 12:45:33 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Oct 2012 12:45:33 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q93CjSHT023081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Oct 2012 12:45:29 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q93CjR06014470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Oct 2012 12:45:28 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q93CjR0o030621; Wed, 3 Oct 2012 07:45:27 -0500 Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 03 Oct 2012 05:45:27 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 1B0714032D; Wed, 3 Oct 2012 08:34:03 -0400 (EDT) Date: Wed, 3 Oct 2012 08:34:03 -0400 From: Konrad Rzeszutek Wilk To: Peter Zotov Message-ID: <20121003123402.GA30715@phenom.dumpdata.com> References: <8524b2c001d3ed8e2cdf71e1734a8e5e@whitequark.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <8524b2c001d3ed8e2cdf71e1734a8e5e@whitequark.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Xen ACPI S3 for Dom0 patch X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, Oct 03, 2012 at 03:15:25PM +0400, Peter Zotov wrote: > Hello. > > I have discovered your patch which fixes ACPI S3 for Xen Dom0 at LKML, > namely this one: > http://lkml.indiana.edu/hypermail/linux/kernel/1112.2/00450.html > > I've built the corresponding branch in your kernel.org repo > (devel/acpi-s3.v10), I am not sure what you are saying. Did you cherry-pick the patches or did you built from that branch? > but it seems that the bug is still there: the machine hangs at any > suspend > attempt. Unfortunately I don't have builtin serial ports and thus > cannot provide > Xen or kernel debug messages. There was a Xen hypervisor issue. > > It also doesn't seem like the patch was merged to the mainline. Correct. > > What's the current status of the issue? Well, there was a lot of talk on xen-devel about Xen hypervisor having issues with resume. Did you look at that? Did you look at the whole thread? Also CC-ing xen-devel here. > > -- > WBR, Peter Zotov. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 12:45:55 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 12:45:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOKa-0002fN-RE; Wed, 03 Oct 2012 12:45:40 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOKZ-0002fI-F2 for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 12:45:39 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1349268331!7208581!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzgwMzQw\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21431 invoked from network); 3 Oct 2012 12:45:33 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Oct 2012 12:45:33 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q93CjSHT023081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Oct 2012 12:45:29 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q93CjR06014470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Oct 2012 12:45:28 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q93CjR0o030621; Wed, 3 Oct 2012 07:45:27 -0500 Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 03 Oct 2012 05:45:27 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 1B0714032D; Wed, 3 Oct 2012 08:34:03 -0400 (EDT) Date: Wed, 3 Oct 2012 08:34:03 -0400 From: Konrad Rzeszutek Wilk To: Peter Zotov Message-ID: <20121003123402.GA30715@phenom.dumpdata.com> References: <8524b2c001d3ed8e2cdf71e1734a8e5e@whitequark.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <8524b2c001d3ed8e2cdf71e1734a8e5e@whitequark.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Xen ACPI S3 for Dom0 patch X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, Oct 03, 2012 at 03:15:25PM +0400, Peter Zotov wrote: > Hello. > > I have discovered your patch which fixes ACPI S3 for Xen Dom0 at LKML, > namely this one: > http://lkml.indiana.edu/hypermail/linux/kernel/1112.2/00450.html > > I've built the corresponding branch in your kernel.org repo > (devel/acpi-s3.v10), I am not sure what you are saying. Did you cherry-pick the patches or did you built from that branch? > but it seems that the bug is still there: the machine hangs at any > suspend > attempt. Unfortunately I don't have builtin serial ports and thus > cannot provide > Xen or kernel debug messages. There was a Xen hypervisor issue. > > It also doesn't seem like the patch was merged to the mainline. Correct. > > What's the current status of the issue? Well, there was a lot of talk on xen-devel about Xen hypervisor having issues with resume. Did you look at that? Did you look at the whole thread? Also CC-ing xen-devel here. > > -- > WBR, Peter Zotov. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 12:48:42 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 12:48:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJONG-0002mm-Rg; Wed, 03 Oct 2012 12:48:26 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJONF-0002mV-Ch for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 12:48:25 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-9.tower-27.messagelabs.com!1349268499!9582614!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MjUwMjc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24268 invoked from network); 3 Oct 2012 12:48:19 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Oct 2012 12:48:19 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id 4E88C153C; Wed, 3 Oct 2012 15:48:18 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id E444020058; Wed, 3 Oct 2012 15:48:17 +0300 (EEST) Date: Wed, 3 Oct 2012 15:48:17 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Valtteri Kiviniemi Message-ID: <20121003124817.GU8912@reaktio.net> References: <20121002144251.GP8912@reaktio.net> <20121003114552.GS8912@reaktio.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Konrad Rzeszutek Wilk , Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.0.4, kernel 3.5.0 HVM crash and kernel BUG X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, Oct 03, 2012 at 03:09:07PM +0300, Valtteri Kiviniemi wrote: > Hi, > = > Yes, of course. I disabled these options: > = > Processor type and features: > [*] Numa Memory Allocation and Scheduler Support > [*] ACPI NUMA detection > = > Power management and ACPI options ---> > ACPI (Advanced Configuration and Power Interface) Support > -*- NUMA support > = Ok. Good to know. > Any Ideas howto debug the VNC problem any further? > Maybe start a new thread about the VNC problem.. it seems to be a separate = issue. -- Pasi = > - Valtteri > = > 2012/10/3 Pasi K=E4rkk=E4inen <[1]pasik@iki.fi> > = > On Wed, Oct 03, 2012 at 12:21:47PM +0300, Valtteri Kiviniemi wrote: > > Hi, > > > > I disabled NUMA and upgraded to Xen 4.2.0. Windows domU starts = now > fine > > and I cant anymore reproduce the hotplug problems. VNC output is > still > > just black screen and it actually crashes the the whole VNC cli= ent > when > > after a few seconds. RealVNC just shuts itself down and tightvnc > crashes. > > > = > Valtteri: Can you actually paste the names of the .config options you > disabled > and got the dom0 kernel working without crashes? > = > Maybe Konrad can comment if the current upstream dom0 kernel is supp= osed > to work > with NUMA support enabled / compiled in? > = > -- Pasi > = > > - Valtteri > > > > 2012/10/2 Valtteri Kiviniemi <[1][2]kiviniemi.valtteri@gmail.co= m> > > > > Hi, > > > > Yes, they are all loaded and I'm running Linux PV-virtuals at= the > same > > time with no problems. Only HVM is not working. I have single > socket > > corei7 processor and NUMA enabled on dom0 kernel, so I will t= ry > tomorrow > > to compile dom0 kernel without NUMA, since its not needed and= it > could > > probably cause some kind of memory related problems. > > > > I will also try Debian squeezes package Xen and test if it is > working > > with my hardware. > > > > - Valtteri > > > > 2012/10/2 Konrad Rzeszutek Wilk <[2][3]konrad@kernel.org> > > > > On Tue, Oct 2, 2012 at 10:55 AM, Valtteri Kiviniemi > > <[3][4]kiviniemi.valtteri@gmail.com> wrote: > > > Hi, > > > > > > Yes, I understood for what the parameters were for. I'ts = been > a long > > time > > > since I last had major problems with Xen (maybe 3.1 or > something, > > been using > > > Xen since version 2) and I had a shady recollection that = Xen > was > > required to > > > be build debugging enabled in order to get any usable > debugging > > data. > > > > > > But anyway, I cant reproduce that kernel crash everytime,= it > just > > happens > > > sometimes. Major problem is the black screen on VNC and > second > > problem seems > > > to be that everytime i try to run Linux in HVM mode it > somehow > > breaks the > > > hotplug scripts. > > > > > > > So do you have all backends loaded? Is xen-netback and > xen-blkback > > running? > > Do you also have tun loaded? > > > > References > > > > Visible links > > 1. mailto:[5]kiviniemi.valtteri@gmail.com > > 2. mailto:[6]konrad@kernel.org > > 3. mailto:[7]kiviniemi.valtteri@gmail.com > = > References > = > Visible links > 1. mailto:pasik@iki.fi > 2. mailto:kiviniemi.valtteri@gmail.com > 3. mailto:konrad@kernel.org > 4. mailto:kiviniemi.valtteri@gmail.com > 5. mailto:kiviniemi.valtteri@gmail.com > 6. mailto:konrad@kernel.org > 7. mailto:kiviniemi.valtteri@gmail.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 12:48:42 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 12:48:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJONG-0002mm-Rg; Wed, 03 Oct 2012 12:48:26 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJONF-0002mV-Ch for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 12:48:25 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-9.tower-27.messagelabs.com!1349268499!9582614!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MjUwMjc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24268 invoked from network); 3 Oct 2012 12:48:19 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Oct 2012 12:48:19 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id 4E88C153C; Wed, 3 Oct 2012 15:48:18 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id E444020058; Wed, 3 Oct 2012 15:48:17 +0300 (EEST) Date: Wed, 3 Oct 2012 15:48:17 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Valtteri Kiviniemi Message-ID: <20121003124817.GU8912@reaktio.net> References: <20121002144251.GP8912@reaktio.net> <20121003114552.GS8912@reaktio.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Konrad Rzeszutek Wilk , Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.0.4, kernel 3.5.0 HVM crash and kernel BUG X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, Oct 03, 2012 at 03:09:07PM +0300, Valtteri Kiviniemi wrote: > Hi, > = > Yes, of course. I disabled these options: > = > Processor type and features: > [*] Numa Memory Allocation and Scheduler Support > [*] ACPI NUMA detection > = > Power management and ACPI options ---> > ACPI (Advanced Configuration and Power Interface) Support > -*- NUMA support > = Ok. Good to know. > Any Ideas howto debug the VNC problem any further? > Maybe start a new thread about the VNC problem.. it seems to be a separate = issue. -- Pasi = > - Valtteri > = > 2012/10/3 Pasi K=E4rkk=E4inen <[1]pasik@iki.fi> > = > On Wed, Oct 03, 2012 at 12:21:47PM +0300, Valtteri Kiviniemi wrote: > > Hi, > > > > I disabled NUMA and upgraded to Xen 4.2.0. Windows domU starts = now > fine > > and I cant anymore reproduce the hotplug problems. VNC output is > still > > just black screen and it actually crashes the the whole VNC cli= ent > when > > after a few seconds. RealVNC just shuts itself down and tightvnc > crashes. > > > = > Valtteri: Can you actually paste the names of the .config options you > disabled > and got the dom0 kernel working without crashes? > = > Maybe Konrad can comment if the current upstream dom0 kernel is supp= osed > to work > with NUMA support enabled / compiled in? > = > -- Pasi > = > > - Valtteri > > > > 2012/10/2 Valtteri Kiviniemi <[1][2]kiviniemi.valtteri@gmail.co= m> > > > > Hi, > > > > Yes, they are all loaded and I'm running Linux PV-virtuals at= the > same > > time with no problems. Only HVM is not working. I have single > socket > > corei7 processor and NUMA enabled on dom0 kernel, so I will t= ry > tomorrow > > to compile dom0 kernel without NUMA, since its not needed and= it > could > > probably cause some kind of memory related problems. > > > > I will also try Debian squeezes package Xen and test if it is > working > > with my hardware. > > > > - Valtteri > > > > 2012/10/2 Konrad Rzeszutek Wilk <[2][3]konrad@kernel.org> > > > > On Tue, Oct 2, 2012 at 10:55 AM, Valtteri Kiviniemi > > <[3][4]kiviniemi.valtteri@gmail.com> wrote: > > > Hi, > > > > > > Yes, I understood for what the parameters were for. I'ts = been > a long > > time > > > since I last had major problems with Xen (maybe 3.1 or > something, > > been using > > > Xen since version 2) and I had a shady recollection that = Xen > was > > required to > > > be build debugging enabled in order to get any usable > debugging > > data. > > > > > > But anyway, I cant reproduce that kernel crash everytime,= it > just > > happens > > > sometimes. Major problem is the black screen on VNC and > second > > problem seems > > > to be that everytime i try to run Linux in HVM mode it > somehow > > breaks the > > > hotplug scripts. > > > > > > > So do you have all backends loaded? Is xen-netback and > xen-blkback > > running? > > Do you also have tun loaded? > > > > References > > > > Visible links > > 1. mailto:[5]kiviniemi.valtteri@gmail.com > > 2. mailto:[6]konrad@kernel.org > > 3. mailto:[7]kiviniemi.valtteri@gmail.com > = > References > = > Visible links > 1. mailto:pasik@iki.fi > 2. mailto:kiviniemi.valtteri@gmail.com > 3. mailto:konrad@kernel.org > 4. mailto:kiviniemi.valtteri@gmail.com > 5. mailto:kiviniemi.valtteri@gmail.com > 6. mailto:konrad@kernel.org > 7. mailto:kiviniemi.valtteri@gmail.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 12:49:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 12:49:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOOK-0002to-Bd; Wed, 03 Oct 2012 12:49:32 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOOJ-0002tc-37 for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 12:49:31 +0000 Received: from [85.158.137.99:61072] by server-3.bemta-3.messagelabs.com id 59/80-25962-A543C605; Wed, 03 Oct 2012 12:49:30 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-16.tower-217.messagelabs.com!1349268567!20103051!1 X-Originating-IP: [209.85.213.173] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7630 invoked from network); 3 Oct 2012 12:49:29 -0000 Received: from mail-yx0-f173.google.com (HELO mail-yx0-f173.google.com) (209.85.213.173) by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 12:49:29 -0000 Received: by yenl3 with SMTP id l3so2212831yen.32 for ; Wed, 03 Oct 2012 05:49:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=StxejibPRoQvHdg9iI+caP4xVDTOfeprWKS8mnhcaxc=; b=XeD3vdp4DP0ptkmYSlGnekZGbEQea69bf+uvslE43hFxMzm7JwpUwpLBleVgU6I5nS y28/gpPUXQC8eTmVbwFJEhNXSmokl09t6SoUSHhEtQhgPHGM6ejcsOBlDgDfnOgPNxOc foJhN20WjeJ03UhPZ1bivjEhojD1SJeEe6ULukY3DR7SGYHdhUhk5IDZJV8x8Kb3CEO5 kxV1EuAzD/xdR1MZj1V2cfyi2jZ2r0UGjILzvGyftr1gJfpmZpZlwPxpHSK5uEyEQ2Bx 7QYoPLRJRYgnbpjdzKQI13CfUFAe3vS2reTjJ4CfWHZjXlPNoRWtfFg+gIHGBUxnhmf1 svgg== MIME-Version: 1.0 Received: by 10.236.77.7 with SMTP id c7mr1772632yhe.2.1349268567646; Wed, 03 Oct 2012 05:49:27 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Wed, 3 Oct 2012 05:49:27 -0700 (PDT) In-Reply-To: <20121003124817.GU8912@reaktio.net> References: <20121002144251.GP8912@reaktio.net> <20121003114552.GS8912@reaktio.net> <20121003124817.GU8912@reaktio.net> Date: Wed, 3 Oct 2012 15:49:27 +0300 Message-ID: From: Valtteri Kiviniemi To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= Cc: Konrad Rzeszutek Wilk , Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.0.4, kernel 3.5.0 HVM crash and kernel BUG X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0314606806011464577==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============0314606806011464577== Content-Type: multipart/alternative; boundary=20cf300514baae623e04cb2711c1 --20cf300514baae623e04cb2711c1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Ok, will do that. thanks. - Valtteri 2012/10/3 Pasi K=E4rkk=E4inen > On Wed, Oct 03, 2012 at 03:09:07PM +0300, Valtteri Kiviniemi wrote: > > Hi, > > > > Yes, of course. I disabled these options: > > > > Processor type and features: > > [*] Numa Memory Allocation and Scheduler Support > > [*] ACPI NUMA detection > > > > Power management and ACPI options ---> > > ACPI (Advanced Configuration and Power Interface) Support > > -*- NUMA support > > > > Ok. Good to know. > > > Any Ideas howto debug the VNC problem any further? > > > > Maybe start a new thread about the VNC problem.. it seems to be a separat= e > issue. > > -- Pasi > > > - Valtteri > > > > 2012/10/3 Pasi K=E4rkk=E4inen <[1]pasik@iki.fi> > > > > On Wed, Oct 03, 2012 at 12:21:47PM +0300, Valtteri Kiviniemi wrote= : > > > Hi, > > > > > > I disabled NUMA and upgraded to Xen 4.2.0. Windows domU start= s > now > > fine > > > and I cant anymore reproduce the hotplug problems. VNC output > is > > still > > > just black screen and it actually crashes the the whole VNC > client > > when > > > after a few seconds. RealVNC just shuts itself down and > tightvnc > > crashes. > > > > > > > Valtteri: Can you actually paste the names of the .config options > you > > disabled > > and got the dom0 kernel working without crashes? > > > > Maybe Konrad can comment if the current upstream dom0 kernel is > supposed > > to work > > with NUMA support enabled / compiled in? > > > > -- Pasi > > > > > - Valtteri > > > > > > 2012/10/2 Valtteri Kiviniemi <[1][2] > kiviniemi.valtteri@gmail.com> > > > > > > Hi, > > > > > > Yes, they are all loaded and I'm running Linux PV-virtuals > at the > > same > > > time with no problems. Only HVM is not working. I have sing= le > > socket > > > corei7 processor and NUMA enabled on dom0 kernel, so I will > try > > tomorrow > > > to compile dom0 kernel without NUMA, since its not needed > and it > > could > > > probably cause some kind of memory related problems. > > > > > > I will also try Debian squeezes package Xen and test if it = is > > working > > > with my hardware. > > > > > > - Valtteri > > > > > > 2012/10/2 Konrad Rzeszutek Wilk <[2][3]konrad@kernel.org> > > > > > > On Tue, Oct 2, 2012 at 10:55 AM, Valtteri Kiviniemi > > > <[3][4]kiviniemi.valtteri@gmail.com> wrote: > > > > Hi, > > > > > > > > Yes, I understood for what the parameters were for. I't= s > been > > a long > > > time > > > > since I last had major problems with Xen (maybe 3.1 or > > something, > > > been using > > > > Xen since version 2) and I had a shady recollection tha= t > Xen > > was > > > required to > > > > be build debugging enabled in order to get any usable > > debugging > > > data. > > > > > > > > But anyway, I cant reproduce that kernel crash > everytime, it > > just > > > happens > > > > sometimes. Major problem is the black screen on VNC and > > second > > > problem seems > > > > to be that everytime i try to run Linux in HVM mode it > > somehow > > > breaks the > > > > hotplug scripts. > > > > > > > > > > So do you have all backends loaded? Is xen-netback and > > xen-blkback > > > running? > > > Do you also have tun loaded? > > > > > > References > > > > > > Visible links > > > 1. mailto:[5]kiviniemi.valtteri@gmail.com > > > 2. mailto:[6]konrad@kernel.org > > > 3. mailto:[7]kiviniemi.valtteri@gmail.com > > > > References > > > > Visible links > > 1. mailto:pasik@iki.fi > > 2. mailto:kiviniemi.valtteri@gmail.com > > 3. mailto:konrad@kernel.org > > 4. mailto:kiviniemi.valtteri@gmail.com > > 5. mailto:kiviniemi.valtteri@gmail.com > > 6. mailto:konrad@kernel.org > > 7. mailto:kiviniemi.valtteri@gmail.com > --20cf300514baae623e04cb2711c1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Ok, will do that. thanks.

- Valtteri

2012/10/3 Pasi K=E4rkk=E4inen <pasik@iki.fi>
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
On Wed, Oct 03, 2012 at 03:09:07PM +0300, Valtteri Kivini= emi wrote:
> =A0 =A0Hi,
>
> =A0 =A0Yes, of course. I disabled these option= s:
>
> =A0 =A0Processor type and features:
> =A0 =A0[*] Numa Memory Allocation and Scheduler Support
> =A0 =A0[*] ACPI NUMA detection
>
> =A0 =A0Power management and ACPI options =A0--->
> =A0 =A0ACPI (Advanced Configuration and Power Interface) Support
> =A0 =A0-*- =A0 NUMA support
>

Ok. Good to know.

> =A0 =A0Any Ideas howto debug the VNC problem any further?
>

Maybe start a new thread about the VNC problem.. it seems to be a sep= arate issue.

-- Pasi

> =A0 =A0- Valtteri
>
> =A0 =A02012/10/3 Pasi K=E4rkk=E4inen <[1]pasik@iki.fi>
>
> =A0 =A0 =A0On Wed, Oct 03, 2012 at 12:21:47PM +0300, Valtteri Kiviniem= i wrote:
> =A0 =A0 =A0> =A0 =A0Hi,
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0I disabled NUMA and upgraded to Xen 4.2.0. Wind= ows domU starts now
> =A0 =A0 =A0fine
> =A0 =A0 =A0> =A0 =A0and I cant anymore reproduce the hotplug proble= ms. VNC output is
> =A0 =A0 =A0still
> =A0 =A0 =A0> =A0 =A0just black screen and it actually crashes the t= he whole VNC client
> =A0 =A0 =A0when
> =A0 =A0 =A0> =A0 =A0after a few seconds. RealVNC just shuts itself = down and tightvnc
> =A0 =A0 =A0crashes.
> =A0 =A0 =A0>
>
> =A0 =A0 =A0Valtteri: Can you actually paste the names of the .config o= ptions you
> =A0 =A0 =A0disabled
> =A0 =A0 =A0and got the dom0 kernel working without crashes?
>
> =A0 =A0 =A0Maybe Konrad can comment if the current upstream dom0 kerne= l is supposed
> =A0 =A0 =A0to work
> =A0 =A0 =A0with NUMA support enabled / compiled in?
>
> =A0 =A0 =A0-- Pasi
>
> =A0 =A0 =A0> =A0 =A0- Valtteri
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A02012/10/2 Valtteri Kiviniemi <[1][2]kiviniemi.valtteri@gmail.com<= /a>>
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0Hi,
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0Yes, they are all loaded and I'm runnin= g Linux PV-virtuals at the
> =A0 =A0 =A0same
> =A0 =A0 =A0> =A0 =A0 =A0time with no problems. Only HVM is not work= ing. I have single
> =A0 =A0 =A0socket
> =A0 =A0 =A0> =A0 =A0 =A0corei7 processor and NUMA enabled on dom0 k= ernel, so I will try
> =A0 =A0 =A0tomorrow
> =A0 =A0 =A0> =A0 =A0 =A0to compile dom0 kernel without NUMA, since = its not needed and it
> =A0 =A0 =A0could
> =A0 =A0 =A0> =A0 =A0 =A0probably cause some kind of memory related = problems.
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0I will also try Debian squeezes package Xen= and test if it is
> =A0 =A0 =A0working
> =A0 =A0 =A0> =A0 =A0 =A0with my hardware.
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0- Valtteri
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A02012/10/2 Konrad Rzeszutek Wilk <[= 2][3]konrad@kernel.org>
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0On Tue, Oct 2, 2012 at 10:55 AM, Valtte= ri Kiviniemi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0<[3][4]= kiviniemi.valtteri@gmail.co= m> wrote:
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> Hi,
> =A0 =A0 =A0> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> Yes, I understood for what the par= ameters were for. I'ts been
> =A0 =A0 =A0a long
> =A0 =A0 =A0> =A0 =A0 =A0 =A0time
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> since I last had major problems wi= th Xen (maybe 3.1 or
> =A0 =A0 =A0something,
> =A0 =A0 =A0> =A0 =A0 =A0 =A0been using
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> Xen since version 2) and I had a s= hady recollection that Xen
> =A0 =A0 =A0was
> =A0 =A0 =A0> =A0 =A0 =A0 =A0required to
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> be build debugging enabled in orde= r to get any usable
> =A0 =A0 =A0debugging
> =A0 =A0 =A0> =A0 =A0 =A0 =A0data.
> =A0 =A0 =A0> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> But anyway, I cant reproduce that = kernel crash everytime, it
> =A0 =A0 =A0just
> =A0 =A0 =A0> =A0 =A0 =A0 =A0happens
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> sometimes. Major problem is the bl= ack screen on VNC and
> =A0 =A0 =A0second
> =A0 =A0 =A0> =A0 =A0 =A0 =A0problem seems
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> to be that everytime i try to run = Linux in HVM mode it
> =A0 =A0 =A0somehow
> =A0 =A0 =A0> =A0 =A0 =A0 =A0breaks the
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> hotplug scripts.
> =A0 =A0 =A0> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0So do you have all backends loaded? Is = xen-netback and
> =A0 =A0 =A0xen-blkback
> =A0 =A0 =A0> =A0 =A0 =A0 =A0running?
> =A0 =A0 =A0> =A0 =A0 =A0 =A0Do you also have tun loaded?
> =A0 =A0 =A0>
> =A0 =A0 =A0> References
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0Visible links
> =A0 =A0 =A0> =A0 =A01. mailto:[5]kiviniemi.valtteri@gmail.com
> =A0 =A0 =A0> =A0 =A02. mailto:[6]konrad@kernel.org
> =A0 =A0 =A0> =A0 =A03. mailto:[7]kiviniemi.valtteri@gmail.com
>
> References
>
> =A0 =A0Visible links
> =A0 =A01. mailto:pasik@iki.fi
> =A0 =A02. mailto:kivin= iemi.valtteri@gmail.com
> =A0 =A03. mailto:konrad@kernel.or= g
> =A0 =A04. mailto:kivin= iemi.valtteri@gmail.com
> =A0 =A05. mailto:kivin= iemi.valtteri@gmail.com
> =A0 =A06. mailto:konrad@kernel.or= g
> =A0 =A07. mailto:kivin= iemi.valtteri@gmail.com

--20cf300514baae623e04cb2711c1-- --===============0314606806011464577== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============0314606806011464577==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 12:49:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 12:49:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOOK-0002to-Bd; Wed, 03 Oct 2012 12:49:32 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOOJ-0002tc-37 for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 12:49:31 +0000 Received: from [85.158.137.99:61072] by server-3.bemta-3.messagelabs.com id 59/80-25962-A543C605; Wed, 03 Oct 2012 12:49:30 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-16.tower-217.messagelabs.com!1349268567!20103051!1 X-Originating-IP: [209.85.213.173] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7630 invoked from network); 3 Oct 2012 12:49:29 -0000 Received: from mail-yx0-f173.google.com (HELO mail-yx0-f173.google.com) (209.85.213.173) by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 12:49:29 -0000 Received: by yenl3 with SMTP id l3so2212831yen.32 for ; Wed, 03 Oct 2012 05:49:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=StxejibPRoQvHdg9iI+caP4xVDTOfeprWKS8mnhcaxc=; b=XeD3vdp4DP0ptkmYSlGnekZGbEQea69bf+uvslE43hFxMzm7JwpUwpLBleVgU6I5nS y28/gpPUXQC8eTmVbwFJEhNXSmokl09t6SoUSHhEtQhgPHGM6ejcsOBlDgDfnOgPNxOc foJhN20WjeJ03UhPZ1bivjEhojD1SJeEe6ULukY3DR7SGYHdhUhk5IDZJV8x8Kb3CEO5 kxV1EuAzD/xdR1MZj1V2cfyi2jZ2r0UGjILzvGyftr1gJfpmZpZlwPxpHSK5uEyEQ2Bx 7QYoPLRJRYgnbpjdzKQI13CfUFAe3vS2reTjJ4CfWHZjXlPNoRWtfFg+gIHGBUxnhmf1 svgg== MIME-Version: 1.0 Received: by 10.236.77.7 with SMTP id c7mr1772632yhe.2.1349268567646; Wed, 03 Oct 2012 05:49:27 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Wed, 3 Oct 2012 05:49:27 -0700 (PDT) In-Reply-To: <20121003124817.GU8912@reaktio.net> References: <20121002144251.GP8912@reaktio.net> <20121003114552.GS8912@reaktio.net> <20121003124817.GU8912@reaktio.net> Date: Wed, 3 Oct 2012 15:49:27 +0300 Message-ID: From: Valtteri Kiviniemi To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= Cc: Konrad Rzeszutek Wilk , Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.0.4, kernel 3.5.0 HVM crash and kernel BUG X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0314606806011464577==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============0314606806011464577== Content-Type: multipart/alternative; boundary=20cf300514baae623e04cb2711c1 --20cf300514baae623e04cb2711c1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Ok, will do that. thanks. - Valtteri 2012/10/3 Pasi K=E4rkk=E4inen > On Wed, Oct 03, 2012 at 03:09:07PM +0300, Valtteri Kiviniemi wrote: > > Hi, > > > > Yes, of course. I disabled these options: > > > > Processor type and features: > > [*] Numa Memory Allocation and Scheduler Support > > [*] ACPI NUMA detection > > > > Power management and ACPI options ---> > > ACPI (Advanced Configuration and Power Interface) Support > > -*- NUMA support > > > > Ok. Good to know. > > > Any Ideas howto debug the VNC problem any further? > > > > Maybe start a new thread about the VNC problem.. it seems to be a separat= e > issue. > > -- Pasi > > > - Valtteri > > > > 2012/10/3 Pasi K=E4rkk=E4inen <[1]pasik@iki.fi> > > > > On Wed, Oct 03, 2012 at 12:21:47PM +0300, Valtteri Kiviniemi wrote= : > > > Hi, > > > > > > I disabled NUMA and upgraded to Xen 4.2.0. Windows domU start= s > now > > fine > > > and I cant anymore reproduce the hotplug problems. VNC output > is > > still > > > just black screen and it actually crashes the the whole VNC > client > > when > > > after a few seconds. RealVNC just shuts itself down and > tightvnc > > crashes. > > > > > > > Valtteri: Can you actually paste the names of the .config options > you > > disabled > > and got the dom0 kernel working without crashes? > > > > Maybe Konrad can comment if the current upstream dom0 kernel is > supposed > > to work > > with NUMA support enabled / compiled in? > > > > -- Pasi > > > > > - Valtteri > > > > > > 2012/10/2 Valtteri Kiviniemi <[1][2] > kiviniemi.valtteri@gmail.com> > > > > > > Hi, > > > > > > Yes, they are all loaded and I'm running Linux PV-virtuals > at the > > same > > > time with no problems. Only HVM is not working. I have sing= le > > socket > > > corei7 processor and NUMA enabled on dom0 kernel, so I will > try > > tomorrow > > > to compile dom0 kernel without NUMA, since its not needed > and it > > could > > > probably cause some kind of memory related problems. > > > > > > I will also try Debian squeezes package Xen and test if it = is > > working > > > with my hardware. > > > > > > - Valtteri > > > > > > 2012/10/2 Konrad Rzeszutek Wilk <[2][3]konrad@kernel.org> > > > > > > On Tue, Oct 2, 2012 at 10:55 AM, Valtteri Kiviniemi > > > <[3][4]kiviniemi.valtteri@gmail.com> wrote: > > > > Hi, > > > > > > > > Yes, I understood for what the parameters were for. I't= s > been > > a long > > > time > > > > since I last had major problems with Xen (maybe 3.1 or > > something, > > > been using > > > > Xen since version 2) and I had a shady recollection tha= t > Xen > > was > > > required to > > > > be build debugging enabled in order to get any usable > > debugging > > > data. > > > > > > > > But anyway, I cant reproduce that kernel crash > everytime, it > > just > > > happens > > > > sometimes. Major problem is the black screen on VNC and > > second > > > problem seems > > > > to be that everytime i try to run Linux in HVM mode it > > somehow > > > breaks the > > > > hotplug scripts. > > > > > > > > > > So do you have all backends loaded? Is xen-netback and > > xen-blkback > > > running? > > > Do you also have tun loaded? > > > > > > References > > > > > > Visible links > > > 1. mailto:[5]kiviniemi.valtteri@gmail.com > > > 2. mailto:[6]konrad@kernel.org > > > 3. mailto:[7]kiviniemi.valtteri@gmail.com > > > > References > > > > Visible links > > 1. mailto:pasik@iki.fi > > 2. mailto:kiviniemi.valtteri@gmail.com > > 3. mailto:konrad@kernel.org > > 4. mailto:kiviniemi.valtteri@gmail.com > > 5. mailto:kiviniemi.valtteri@gmail.com > > 6. mailto:konrad@kernel.org > > 7. mailto:kiviniemi.valtteri@gmail.com > --20cf300514baae623e04cb2711c1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Ok, will do that. thanks.

- Valtteri

2012/10/3 Pasi K=E4rkk=E4inen <pasik@iki.fi>
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
On Wed, Oct 03, 2012 at 03:09:07PM +0300, Valtteri Kivini= emi wrote:
> =A0 =A0Hi,
>
> =A0 =A0Yes, of course. I disabled these option= s:
>
> =A0 =A0Processor type and features:
> =A0 =A0[*] Numa Memory Allocation and Scheduler Support
> =A0 =A0[*] ACPI NUMA detection
>
> =A0 =A0Power management and ACPI options =A0--->
> =A0 =A0ACPI (Advanced Configuration and Power Interface) Support
> =A0 =A0-*- =A0 NUMA support
>

Ok. Good to know.

> =A0 =A0Any Ideas howto debug the VNC problem any further?
>

Maybe start a new thread about the VNC problem.. it seems to be a sep= arate issue.

-- Pasi

> =A0 =A0- Valtteri
>
> =A0 =A02012/10/3 Pasi K=E4rkk=E4inen <[1]pasik@iki.fi>
>
> =A0 =A0 =A0On Wed, Oct 03, 2012 at 12:21:47PM +0300, Valtteri Kiviniem= i wrote:
> =A0 =A0 =A0> =A0 =A0Hi,
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0I disabled NUMA and upgraded to Xen 4.2.0. Wind= ows domU starts now
> =A0 =A0 =A0fine
> =A0 =A0 =A0> =A0 =A0and I cant anymore reproduce the hotplug proble= ms. VNC output is
> =A0 =A0 =A0still
> =A0 =A0 =A0> =A0 =A0just black screen and it actually crashes the t= he whole VNC client
> =A0 =A0 =A0when
> =A0 =A0 =A0> =A0 =A0after a few seconds. RealVNC just shuts itself = down and tightvnc
> =A0 =A0 =A0crashes.
> =A0 =A0 =A0>
>
> =A0 =A0 =A0Valtteri: Can you actually paste the names of the .config o= ptions you
> =A0 =A0 =A0disabled
> =A0 =A0 =A0and got the dom0 kernel working without crashes?
>
> =A0 =A0 =A0Maybe Konrad can comment if the current upstream dom0 kerne= l is supposed
> =A0 =A0 =A0to work
> =A0 =A0 =A0with NUMA support enabled / compiled in?
>
> =A0 =A0 =A0-- Pasi
>
> =A0 =A0 =A0> =A0 =A0- Valtteri
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A02012/10/2 Valtteri Kiviniemi <[1][2]kiviniemi.valtteri@gmail.com<= /a>>
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0Hi,
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0Yes, they are all loaded and I'm runnin= g Linux PV-virtuals at the
> =A0 =A0 =A0same
> =A0 =A0 =A0> =A0 =A0 =A0time with no problems. Only HVM is not work= ing. I have single
> =A0 =A0 =A0socket
> =A0 =A0 =A0> =A0 =A0 =A0corei7 processor and NUMA enabled on dom0 k= ernel, so I will try
> =A0 =A0 =A0tomorrow
> =A0 =A0 =A0> =A0 =A0 =A0to compile dom0 kernel without NUMA, since = its not needed and it
> =A0 =A0 =A0could
> =A0 =A0 =A0> =A0 =A0 =A0probably cause some kind of memory related = problems.
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0I will also try Debian squeezes package Xen= and test if it is
> =A0 =A0 =A0working
> =A0 =A0 =A0> =A0 =A0 =A0with my hardware.
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0- Valtteri
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A02012/10/2 Konrad Rzeszutek Wilk <[= 2][3]konrad@kernel.org>
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0On Tue, Oct 2, 2012 at 10:55 AM, Valtte= ri Kiviniemi
> =A0 =A0 =A0> =A0 =A0 =A0 =A0<[3][4]= kiviniemi.valtteri@gmail.co= m> wrote:
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> Hi,
> =A0 =A0 =A0> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> Yes, I understood for what the par= ameters were for. I'ts been
> =A0 =A0 =A0a long
> =A0 =A0 =A0> =A0 =A0 =A0 =A0time
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> since I last had major problems wi= th Xen (maybe 3.1 or
> =A0 =A0 =A0something,
> =A0 =A0 =A0> =A0 =A0 =A0 =A0been using
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> Xen since version 2) and I had a s= hady recollection that Xen
> =A0 =A0 =A0was
> =A0 =A0 =A0> =A0 =A0 =A0 =A0required to
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> be build debugging enabled in orde= r to get any usable
> =A0 =A0 =A0debugging
> =A0 =A0 =A0> =A0 =A0 =A0 =A0data.
> =A0 =A0 =A0> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> But anyway, I cant reproduce that = kernel crash everytime, it
> =A0 =A0 =A0just
> =A0 =A0 =A0> =A0 =A0 =A0 =A0happens
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> sometimes. Major problem is the bl= ack screen on VNC and
> =A0 =A0 =A0second
> =A0 =A0 =A0> =A0 =A0 =A0 =A0problem seems
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> to be that everytime i try to run = Linux in HVM mode it
> =A0 =A0 =A0somehow
> =A0 =A0 =A0> =A0 =A0 =A0 =A0breaks the
> =A0 =A0 =A0> =A0 =A0 =A0 =A0> hotplug scripts.
> =A0 =A0 =A0> =A0 =A0 =A0 =A0>
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0 =A0So do you have all backends loaded? Is = xen-netback and
> =A0 =A0 =A0xen-blkback
> =A0 =A0 =A0> =A0 =A0 =A0 =A0running?
> =A0 =A0 =A0> =A0 =A0 =A0 =A0Do you also have tun loaded?
> =A0 =A0 =A0>
> =A0 =A0 =A0> References
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0Visible links
> =A0 =A0 =A0> =A0 =A01. mailto:[5]kiviniemi.valtteri@gmail.com
> =A0 =A0 =A0> =A0 =A02. mailto:[6]konrad@kernel.org
> =A0 =A0 =A0> =A0 =A03. mailto:[7]kiviniemi.valtteri@gmail.com
>
> References
>
> =A0 =A0Visible links
> =A0 =A01. mailto:pasik@iki.fi
> =A0 =A02. mailto:kivin= iemi.valtteri@gmail.com
> =A0 =A03. mailto:konrad@kernel.or= g
> =A0 =A04. mailto:kivin= iemi.valtteri@gmail.com
> =A0 =A05. mailto:kivin= iemi.valtteri@gmail.com
> =A0 =A06. mailto:konrad@kernel.or= g
> =A0 =A07. mailto:kivin= iemi.valtteri@gmail.com

--20cf300514baae623e04cb2711c1-- --===============0314606806011464577== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============0314606806011464577==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 12:58:42 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 12:58:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOWx-0003AK-HF; Wed, 03 Oct 2012 12:58:27 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOWw-0003AF-8W for xen-devel@lists.xen.org; Wed, 03 Oct 2012 12:58:26 +0000 Received: from [85.158.139.83:49371] by server-4.bemta-5.messagelabs.com id FB/3B-20767-1763C605; Wed, 03 Oct 2012 12:58:25 +0000 X-Env-Sender: jbeulich@suse.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1349269104!33055682!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31181 invoked from network); 3 Oct 2012 12:58:24 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-12.tower-182.messagelabs.com with SMTP; 3 Oct 2012 12:58:24 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 03 Oct 2012 13:58:23 +0100 Message-Id: <506C447D020000780008D001@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Wed, 03 Oct 2012 13:58:21 +0100 From: "Jan Beulich" To: References: <506B1C6E020000780009F221@nat28.tlf.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH] VT-d: make remap_entry_to_msi_msg() return consistent message X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> Keir Fraser 10/02/12 7:01 PM >>> >On 02/10/2012 15:55, "Jan Beulich" wrote: > >> During debugging of another problem I found that in x2APIC mode, the >> destination field of the low address value wasn't passed back >> correctly. While this is benign in most cases (as the value isn't being >> used anywhere), it can be confusing (and misguiding) when printing the >> value read or when comparing it to the one previously passed into the >> inverse function. >> >> Signed-off-by: Jan Beulich > >Acked-by: Keir Fraser Actually on my way home yesterday I realized that this is not consistent, i.e. fails to cover symmetrically the !x2apic case. Therefore, I'd like to adjust this to pull out the msg->dest32 assignment from the conditional. Will that be okay to commit without re-submission? Jan > --- a/xen/drivers/passthrough/vtd/intremap.c > +++ b/xen/drivers/passthrough/vtd/intremap.c > @@ -504,7 +504,11 @@ static int remap_entry_to_msi_msg( > MSI_ADDR_REDIRECTION_CPU: > MSI_ADDR_REDIRECTION_LOWPRI); > if ( x2apic_enabled ) > + { > msg->dest32 = iremap_entry->lo.dst; > + msg->address_lo |= > + (iremap_entry->lo.dst & 0xff) << MSI_ADDR_DEST_ID_SHIFT; > + } > else > msg->address_lo |= > ((iremap_entry->lo.dst >> 8) & 0xff ) << MSI_ADDR_DEST_ID_SHIFT; > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 12:58:42 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 12:58:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOWx-0003AK-HF; Wed, 03 Oct 2012 12:58:27 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOWw-0003AF-8W for xen-devel@lists.xen.org; Wed, 03 Oct 2012 12:58:26 +0000 Received: from [85.158.139.83:49371] by server-4.bemta-5.messagelabs.com id FB/3B-20767-1763C605; Wed, 03 Oct 2012 12:58:25 +0000 X-Env-Sender: jbeulich@suse.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1349269104!33055682!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31181 invoked from network); 3 Oct 2012 12:58:24 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-12.tower-182.messagelabs.com with SMTP; 3 Oct 2012 12:58:24 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 03 Oct 2012 13:58:23 +0100 Message-Id: <506C447D020000780008D001@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Wed, 03 Oct 2012 13:58:21 +0100 From: "Jan Beulich" To: References: <506B1C6E020000780009F221@nat28.tlf.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH] VT-d: make remap_entry_to_msi_msg() return consistent message X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> Keir Fraser 10/02/12 7:01 PM >>> >On 02/10/2012 15:55, "Jan Beulich" wrote: > >> During debugging of another problem I found that in x2APIC mode, the >> destination field of the low address value wasn't passed back >> correctly. While this is benign in most cases (as the value isn't being >> used anywhere), it can be confusing (and misguiding) when printing the >> value read or when comparing it to the one previously passed into the >> inverse function. >> >> Signed-off-by: Jan Beulich > >Acked-by: Keir Fraser Actually on my way home yesterday I realized that this is not consistent, i.e. fails to cover symmetrically the !x2apic case. Therefore, I'd like to adjust this to pull out the msg->dest32 assignment from the conditional. Will that be okay to commit without re-submission? Jan > --- a/xen/drivers/passthrough/vtd/intremap.c > +++ b/xen/drivers/passthrough/vtd/intremap.c > @@ -504,7 +504,11 @@ static int remap_entry_to_msi_msg( > MSI_ADDR_REDIRECTION_CPU: > MSI_ADDR_REDIRECTION_LOWPRI); > if ( x2apic_enabled ) > + { > msg->dest32 = iremap_entry->lo.dst; > + msg->address_lo |= > + (iremap_entry->lo.dst & 0xff) << MSI_ADDR_DEST_ID_SHIFT; > + } > else > msg->address_lo |= > ((iremap_entry->lo.dst >> 8) & 0xff ) << MSI_ADDR_DEST_ID_SHIFT; > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 13:00:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 13:00:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOYg-0003H3-0p; Wed, 03 Oct 2012 13:00:14 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJLm0-00052Q-RW for xen-devel@lists.xen.org; Wed, 03 Oct 2012 10:01:49 +0000 Received: from [85.158.139.83:9259] by server-5.bemta-5.messagelabs.com id 4D/A8-21075-C0D0C605; Wed, 03 Oct 2012 10:01:48 +0000 X-Env-Sender: mossa@poisson.phc.unipi.it X-Msg-Ref: server-11.tower-182.messagelabs.com!1349258507!25981744!1 X-Originating-IP: [131.114.10.30] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1492 invoked from network); 3 Oct 2012 10:01:47 -0000 Received: from poisson.phc.unipi.it (HELO poisson.phc.unipi.it) (131.114.10.30) by server-11.tower-182.messagelabs.com with SMTP; 3 Oct 2012 10:01:47 -0000 Received: from intersect (nat10.phc.unipi.it [131.114.10.74]) by poisson.phc.unipi.it (Postfix) with ESMTPS id 86D9915E01A; Wed, 3 Oct 2012 12:01:46 +0200 (CEST) Received: by intersect (Postfix, from userid 1000) id AEFD92622; Wed, 3 Oct 2012 12:01:45 +0200 (CEST) Date: Wed, 3 Oct 2012 12:01:45 +0200 From: Giorgio Mossa To: Roger Pau =?iso-8859-1?Q?Monn=E9?= Message-ID: <20121003100145.GA2700@intersect> References: <20121002163136.GA5378@intersect> <1349196417.650.115.camel@zakaz.uk.xensource.com> <506BF7FD.4000707@citrix.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <506BF7FD.4000707@citrix.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Wed, 03 Oct 2012 13:00:12 +0000 Cc: "xen-users@lists.xen.org" , Ian Jackson , Ian Campbell , xen-devel Subject: Re: [Xen-devel] libutil.h moved to bsd/libutil.h (Was: Re: [Xen-users] Problem compiling Xen 4.2 from sources) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org It seems the patch worked, thank you very much!!! On Wed, Oct 03, 2012 at 10:31:57AM +0200, Roger Pau Monn=E9 wrote: > = > According to the man pages is only needed on BSDs to be able > to use openpty et al. Linux should not have this file, could you please > try the following patch? It should prevent configure (and thus libxl) > from including the bogus libutil.h header. > = > --- > >From 250c0d533bab3c9705ade8e4bffed54abcb53b1c Mon Sep 17 00:00:00 2001 > From: Roger Pau Monne > Date: Wed, 3 Oct 2012 10:22:21 +0200 > Subject: [PATCH] autoconf: add -Werror to libutil.h header check > = > libutil.h is only needed on BSDs, but not in Linux. Debian package > libbsd-dev-0.3.0-1 installed a libutil.h overlay that contains a > #warning, thus making libxl compilation broken due to -Werror. > = > Perform the libutil.h check with -Werror, so we don't include this > bogus header. > = > Signed-off-by: Roger Pau Monne > --- > Please rerun autoconf after applying this patch > --- > tools/m4/ptyfuncs.m4 | 7 +++++++ > 1 files changed, 7 insertions(+), 0 deletions(-) > = > diff --git a/tools/m4/ptyfuncs.m4 b/tools/m4/ptyfuncs.m4 > index bfea3e1..3e37b5a 100644 > --- a/tools/m4/ptyfuncs.m4 > +++ b/tools/m4/ptyfuncs.m4 > @@ -1,7 +1,14 @@ > AC_DEFUN([AX_CHECK_PTYFUNCS], [ > + dnl This is a workaround for a bug in Debian package > + dnl libbsd-dev-0.3.0-1. Once we no longer support that > + dnl package we can remove the addition of -Werror to > + dnl CPPFLAGS. > + AX_SAVEVAR_SAVE(CPPFLAGS) > + CPPFLAGS=3D"$CPPFLAGS -Werror" > AC_CHECK_HEADER([libutil.h],[ > AC_DEFINE([INCLUDE_LIBUTIL_H],[],[libutil header file n= ame]) > ]) > + AX_SAVEVAR_RESTORE(CPPFLAGS) > AC_CACHE_CHECK([for openpty et al], [ax_cv_ptyfuncs_libs], [ > for ax_cv_ptyfuncs_libs in -lutil "" NOT_FOUND; do > if test "x$ax_cv_ptyfuncs_libs" =3D "xNOT_FOUND"; then > -- = > 1.7.7.5 (Apple Git-26) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 13:00:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 13:00:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOYg-0003H3-0p; Wed, 03 Oct 2012 13:00:14 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJLm0-00052Q-RW for xen-devel@lists.xen.org; Wed, 03 Oct 2012 10:01:49 +0000 Received: from [85.158.139.83:9259] by server-5.bemta-5.messagelabs.com id 4D/A8-21075-C0D0C605; Wed, 03 Oct 2012 10:01:48 +0000 X-Env-Sender: mossa@poisson.phc.unipi.it X-Msg-Ref: server-11.tower-182.messagelabs.com!1349258507!25981744!1 X-Originating-IP: [131.114.10.30] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1492 invoked from network); 3 Oct 2012 10:01:47 -0000 Received: from poisson.phc.unipi.it (HELO poisson.phc.unipi.it) (131.114.10.30) by server-11.tower-182.messagelabs.com with SMTP; 3 Oct 2012 10:01:47 -0000 Received: from intersect (nat10.phc.unipi.it [131.114.10.74]) by poisson.phc.unipi.it (Postfix) with ESMTPS id 86D9915E01A; Wed, 3 Oct 2012 12:01:46 +0200 (CEST) Received: by intersect (Postfix, from userid 1000) id AEFD92622; Wed, 3 Oct 2012 12:01:45 +0200 (CEST) Date: Wed, 3 Oct 2012 12:01:45 +0200 From: Giorgio Mossa To: Roger Pau =?iso-8859-1?Q?Monn=E9?= Message-ID: <20121003100145.GA2700@intersect> References: <20121002163136.GA5378@intersect> <1349196417.650.115.camel@zakaz.uk.xensource.com> <506BF7FD.4000707@citrix.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <506BF7FD.4000707@citrix.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Wed, 03 Oct 2012 13:00:12 +0000 Cc: "xen-users@lists.xen.org" , Ian Jackson , Ian Campbell , xen-devel Subject: Re: [Xen-devel] libutil.h moved to bsd/libutil.h (Was: Re: [Xen-users] Problem compiling Xen 4.2 from sources) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org It seems the patch worked, thank you very much!!! On Wed, Oct 03, 2012 at 10:31:57AM +0200, Roger Pau Monn=E9 wrote: > = > According to the man pages is only needed on BSDs to be able > to use openpty et al. Linux should not have this file, could you please > try the following patch? It should prevent configure (and thus libxl) > from including the bogus libutil.h header. > = > --- > >From 250c0d533bab3c9705ade8e4bffed54abcb53b1c Mon Sep 17 00:00:00 2001 > From: Roger Pau Monne > Date: Wed, 3 Oct 2012 10:22:21 +0200 > Subject: [PATCH] autoconf: add -Werror to libutil.h header check > = > libutil.h is only needed on BSDs, but not in Linux. Debian package > libbsd-dev-0.3.0-1 installed a libutil.h overlay that contains a > #warning, thus making libxl compilation broken due to -Werror. > = > Perform the libutil.h check with -Werror, so we don't include this > bogus header. > = > Signed-off-by: Roger Pau Monne > --- > Please rerun autoconf after applying this patch > --- > tools/m4/ptyfuncs.m4 | 7 +++++++ > 1 files changed, 7 insertions(+), 0 deletions(-) > = > diff --git a/tools/m4/ptyfuncs.m4 b/tools/m4/ptyfuncs.m4 > index bfea3e1..3e37b5a 100644 > --- a/tools/m4/ptyfuncs.m4 > +++ b/tools/m4/ptyfuncs.m4 > @@ -1,7 +1,14 @@ > AC_DEFUN([AX_CHECK_PTYFUNCS], [ > + dnl This is a workaround for a bug in Debian package > + dnl libbsd-dev-0.3.0-1. Once we no longer support that > + dnl package we can remove the addition of -Werror to > + dnl CPPFLAGS. > + AX_SAVEVAR_SAVE(CPPFLAGS) > + CPPFLAGS=3D"$CPPFLAGS -Werror" > AC_CHECK_HEADER([libutil.h],[ > AC_DEFINE([INCLUDE_LIBUTIL_H],[],[libutil header file n= ame]) > ]) > + AX_SAVEVAR_RESTORE(CPPFLAGS) > AC_CACHE_CHECK([for openpty et al], [ax_cv_ptyfuncs_libs], [ > for ax_cv_ptyfuncs_libs in -lutil "" NOT_FOUND; do > if test "x$ax_cv_ptyfuncs_libs" =3D "xNOT_FOUND"; then > -- = > 1.7.7.5 (Apple Git-26) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 13:02:03 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 13:02:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOaF-0003OM-Gq; Wed, 03 Oct 2012 13:01:51 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOaE-0003O9-D7 for xen-devel@lists.xen.org; Wed, 03 Oct 2012 13:01:50 +0000 Received: from [85.158.139.211:53923] by server-15.bemta-5.messagelabs.com id 49/B6-19430-D373C605; Wed, 03 Oct 2012 13:01:49 +0000 X-Env-Sender: jbeulich@suse.com X-Msg-Ref: server-16.tower-206.messagelabs.com!1349269309!20955230!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7591 invoked from network); 3 Oct 2012 13:01:49 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-16.tower-206.messagelabs.com with SMTP; 3 Oct 2012 13:01:49 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 03 Oct 2012 14:01:49 +0100 Message-Id: <506C454B020000780008D008@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Wed, 03 Oct 2012 14:01:47 +0100 From: "Jan Beulich" To: References: <506B2268020000780009F273@nat28.tlf.novell.com> <506B23BF020000780009F29A@nat28.tlf.novell.com> <20121002175716.GA30321@phenom.dumpdata.com> In-Reply-To: <20121002175716.GA30321@phenom.dumpdata.com> Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH 1/3] x86: use MOV instead of PUSH/POP when saving/restoring register state X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> Konrad Rzeszutek Wilk 10/02/12 8:09 PM >>> >On Tue, Oct 02, 2012 at 04:26:23PM +0100, Jan Beulich wrote: >> Signed-off-by: Jan Beulich >What's the reasoning behind it? Just that mov's are faster than >pop/push? No (that's not actually true anymore these days). The main reason is that with MOV, part of the frame generation and register restoration can be more easily skipped than when using PUSH/POP (would require extra stack pointer adjustments on the alternative paths) - see patch 3. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 13:02:03 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 13:02:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOaF-0003OM-Gq; Wed, 03 Oct 2012 13:01:51 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOaE-0003O9-D7 for xen-devel@lists.xen.org; Wed, 03 Oct 2012 13:01:50 +0000 Received: from [85.158.139.211:53923] by server-15.bemta-5.messagelabs.com id 49/B6-19430-D373C605; Wed, 03 Oct 2012 13:01:49 +0000 X-Env-Sender: jbeulich@suse.com X-Msg-Ref: server-16.tower-206.messagelabs.com!1349269309!20955230!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7591 invoked from network); 3 Oct 2012 13:01:49 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-16.tower-206.messagelabs.com with SMTP; 3 Oct 2012 13:01:49 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 03 Oct 2012 14:01:49 +0100 Message-Id: <506C454B020000780008D008@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Wed, 03 Oct 2012 14:01:47 +0100 From: "Jan Beulich" To: References: <506B2268020000780009F273@nat28.tlf.novell.com> <506B23BF020000780009F29A@nat28.tlf.novell.com> <20121002175716.GA30321@phenom.dumpdata.com> In-Reply-To: <20121002175716.GA30321@phenom.dumpdata.com> Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH 1/3] x86: use MOV instead of PUSH/POP when saving/restoring register state X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> Konrad Rzeszutek Wilk 10/02/12 8:09 PM >>> >On Tue, Oct 02, 2012 at 04:26:23PM +0100, Jan Beulich wrote: >> Signed-off-by: Jan Beulich >What's the reasoning behind it? Just that mov's are faster than >pop/push? No (that's not actually true anymore these days). The main reason is that with MOV, part of the frame generation and register restoration can be more easily skipped than when using PUSH/POP (would require extra stack pointer adjustments on the alternative paths) - see patch 3. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 13:07:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 13:07:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOf3-0003iD-LC; Wed, 03 Oct 2012 13:06:49 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with smtp (Exim 4.72) (envelope-from ) id 1TJOf2-0003hl-6g for xen-devel@lists.xen.org; Wed, 03 Oct 2012 13:06:48 +0000 X-Env-Sender: jbeulich@suse.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1349269521!8672259!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13644 invoked from network); 3 Oct 2012 13:05:21 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-4.tower-27.messagelabs.com with SMTP; 3 Oct 2012 13:05:21 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 03 Oct 2012 14:05:20 +0100 Message-Id: <506C461E020000780008D00F@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Wed, 03 Oct 2012 14:05:18 +0100 From: "Jan Beulich" To: References: <506B2410020000780009F2A3@nat28.tlf.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH 3/3] x86: save/restore only partial register state where possible X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> Keir Fraser 10/02/12 7:02 PM >>> >On 02/10/2012 16:27, "Jan Beulich" wrote: > >> ... and make restore conditional not only upon having saved the state, >> but also upon whether saved state was actually modified (and register >> values are known to have been preserved). >> >> Note that RBP is unconditionally considered a volatile register (i.e. >> irrespective of CONFIG_FRAME_POINTER), since the RBP handling would >> become overly complicated due to the need to save/restore it on the >> compat mode hypercall path [6th argument]. >> >> Note further that for compat mode code paths, saving/restoring R8...R15 >> is entirely unnecessary - we don't allow those guests to enter 64-bit >> mode, and hence they have no way of seeing these registers' contents >> (and there consequently also is no information leak, except if the >> context saving domctl would be considered such). >> >> Finally, note that this may not properly deal with gdbstub's needs, yet >> (but if so, I can't really suggest adjustments, as I don't know that >> code). >> >> Signed-off-by: Jan Beulich > >Ugly. I'd prefer not to bother unless there really is a win we could care >about here. Without this patch, patch 1 doesn't make a lot of sense either (and patch 2 then is merely cleanup). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 13:07:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 13:07:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOf3-0003iD-LC; Wed, 03 Oct 2012 13:06:49 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with smtp (Exim 4.72) (envelope-from ) id 1TJOf2-0003hl-6g for xen-devel@lists.xen.org; Wed, 03 Oct 2012 13:06:48 +0000 X-Env-Sender: jbeulich@suse.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1349269521!8672259!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13644 invoked from network); 3 Oct 2012 13:05:21 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-4.tower-27.messagelabs.com with SMTP; 3 Oct 2012 13:05:21 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 03 Oct 2012 14:05:20 +0100 Message-Id: <506C461E020000780008D00F@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Wed, 03 Oct 2012 14:05:18 +0100 From: "Jan Beulich" To: References: <506B2410020000780009F2A3@nat28.tlf.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH 3/3] x86: save/restore only partial register state where possible X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> Keir Fraser 10/02/12 7:02 PM >>> >On 02/10/2012 16:27, "Jan Beulich" wrote: > >> ... and make restore conditional not only upon having saved the state, >> but also upon whether saved state was actually modified (and register >> values are known to have been preserved). >> >> Note that RBP is unconditionally considered a volatile register (i.e. >> irrespective of CONFIG_FRAME_POINTER), since the RBP handling would >> become overly complicated due to the need to save/restore it on the >> compat mode hypercall path [6th argument]. >> >> Note further that for compat mode code paths, saving/restoring R8...R15 >> is entirely unnecessary - we don't allow those guests to enter 64-bit >> mode, and hence they have no way of seeing these registers' contents >> (and there consequently also is no information leak, except if the >> context saving domctl would be considered such). >> >> Finally, note that this may not properly deal with gdbstub's needs, yet >> (but if so, I can't really suggest adjustments, as I don't know that >> code). >> >> Signed-off-by: Jan Beulich > >Ugly. I'd prefer not to bother unless there really is a win we could care >about here. Without this patch, patch 1 doesn't make a lot of sense either (and patch 2 then is merely cleanup). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 13:07:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 13:07:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOf2-0003hy-7z; Wed, 03 Oct 2012 13:06:48 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOf0-0003hi-SG for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 13:06:47 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1349269551!9993043!1 X-Originating-IP: [209.85.213.173] X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_00_10,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28457 invoked from network); 3 Oct 2012 13:05:52 -0000 Received: from mail-yx0-f173.google.com (HELO mail-yx0-f173.google.com) (209.85.213.173) by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 13:05:52 -0000 Received: by yenl3 with SMTP id l3so2218040yen.32 for ; Wed, 03 Oct 2012 06:05:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=L4+OC6t9n/mp2OgosG1531A4pdBf+NrCXwCes5x9T6s=; b=KU4DIHfZuq8rpARn8uMZJKhVTV1XReNN+SJ3CymnxYk24PseP2ROJbQgqD+g5cpSqZ Ns8HI/XclD6mmyCBrZn/ZEnOWlgQB6AtZCmPOKiDClfVvm/C0MGLbxZfLu9BvPnga82s HH6x15Wh/3Kp+Rili3K7wPTDAT8aqyogkps4AsFliCa6CHpg0v7Aqk/PFQyt7IGpdnlV tqcVpDaRRhur0aEcx314ELmuPkoQmnjJyVzpKOJztrPQKIjdSjG6NLwnkuiTS7sGW0xg nznVDQEl3uQeZxsbb3y5F/Rctylsdc5puKQ0IKVX+2NGyTky+oxfQLaT02EI/U/H+OoG e0Pg== MIME-Version: 1.0 Received: by 10.236.9.36 with SMTP id 24mr1717726yhs.63.1349269550803; Wed, 03 Oct 2012 06:05:50 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Wed, 3 Oct 2012 06:05:50 -0700 (PDT) Date: Wed, 3 Oct 2012 16:05:50 +0300 Message-ID: From: Valtteri Kiviniemi To: Xen-devel@lists.xen.org Subject: [Xen-devel] Xen 4.2.0, VNC connection to Windows domU causes black screen on VNC X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6373454665948106797==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============6373454665948106797== Content-Type: multipart/alternative; boundary=20cf303dd26448299704cb274c1f --20cf303dd26448299704cb274c1f Content-Type: text/plain; charset=ISO-8859-1 Hi, I am trying to get Windows Server 2008 R2 HVM domU working in Xen 4.2.0. The domU will start and I can see the boot output to the point when the .iso-image starts loading and I get the "Windows is loading files" loading bar in VNC. After the Windows installer has finished loading the necessary files and starts the installer the resolution will change on the VNC screen and it goes black. However despite that, I think that the Windows installer is still starting fine and it probably is responding to keyboard input, I just cant see anything but black. Qemu-dm log file does not contain any error messages. I'm using the same config file on different server and it is working there, and when comparing the qemu-dm log files on this server and the other server where the windows is working they are pretty much consistent. I have tried playing with different settings on domU config, but nothing makes any difference, the outcome is always the same. Installer starts, resolution changes and then only black. I'am using rather new hardware, CPU is the new Intel Ivy-Bridge Core i7-3770 with integrated GPU and motherboard is Intel DQ77MK with latest bios installed. dom0 kernel is 3.6.0 64bit, hypervisor is 64bit and Windows is 64bit. The same kernel config and domU config is working on my older server which is running mid 2008 CPU Intel Q9950 and motherboard Intel DQ45CB, so I would suspect that this might be some kind of hardware incompatibility problem? Any ideas of how to debug this problem? I have enabled all the debuggint options for Xen and dom0 kernel but I'm not getting any error messages. It seems that the domU is working as intented but only graphics are missing. - Valtteri --20cf303dd26448299704cb274c1f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I am trying to get Windows Server 2008 R2 HVM domU working in Xe= n 4.2.0. The domU will start and I can see the boot output to the point whe= n the .iso-image starts loading and I get the "Windows is loading file= s" loading bar in VNC. After the Windows installer has finished loadin= g the necessary files and starts the installer the resolution will change o= n the VNC screen and it goes black. However despite that, I think that the = Windows installer is still starting fine and it probably is responding to k= eyboard input, I just cant see anything but black. Qemu-dm log file does no= t contain any error messages. I'm using the same config file on differe= nt server and it is working there, and when comparing the qemu-dm log files= on this server and the other server where the windows is working they are = pretty much consistent.

I have tried playing with different settings on domU config, but nothin= g makes any difference, the outcome is always the same. Installer starts, r= esolution changes and then only black. I'am using rather new hardware, = CPU is the new Intel Ivy-Bridge Core i7-3770 with integrated GPU and mother= board is Intel DQ77MK with latest bios installed. dom0 kernel is 3.6.0 64bi= t, hypervisor is 64bit and Windows is 64bit. The same kernel config and dom= U config is working on my older server which is running mid 2008 CPU Intel = Q9950 and motherboard Intel DQ45CB, so I would suspect that this might be s= ome kind of hardware incompatibility problem?

Any ideas of how to debug this problem? I have enabled all the debuggin= t options for Xen and dom0 kernel but I'm not getting any error message= s. It seems that the domU is working as intented but only graphics are miss= ing.

- Valtteri
--20cf303dd26448299704cb274c1f-- --===============6373454665948106797== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6373454665948106797==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 13:07:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 13:07:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOf2-0003hy-7z; Wed, 03 Oct 2012 13:06:48 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOf0-0003hi-SG for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 13:06:47 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1349269551!9993043!1 X-Originating-IP: [209.85.213.173] X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_00_10,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28457 invoked from network); 3 Oct 2012 13:05:52 -0000 Received: from mail-yx0-f173.google.com (HELO mail-yx0-f173.google.com) (209.85.213.173) by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 13:05:52 -0000 Received: by yenl3 with SMTP id l3so2218040yen.32 for ; Wed, 03 Oct 2012 06:05:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=L4+OC6t9n/mp2OgosG1531A4pdBf+NrCXwCes5x9T6s=; b=KU4DIHfZuq8rpARn8uMZJKhVTV1XReNN+SJ3CymnxYk24PseP2ROJbQgqD+g5cpSqZ Ns8HI/XclD6mmyCBrZn/ZEnOWlgQB6AtZCmPOKiDClfVvm/C0MGLbxZfLu9BvPnga82s HH6x15Wh/3Kp+Rili3K7wPTDAT8aqyogkps4AsFliCa6CHpg0v7Aqk/PFQyt7IGpdnlV tqcVpDaRRhur0aEcx314ELmuPkoQmnjJyVzpKOJztrPQKIjdSjG6NLwnkuiTS7sGW0xg nznVDQEl3uQeZxsbb3y5F/Rctylsdc5puKQ0IKVX+2NGyTky+oxfQLaT02EI/U/H+OoG e0Pg== MIME-Version: 1.0 Received: by 10.236.9.36 with SMTP id 24mr1717726yhs.63.1349269550803; Wed, 03 Oct 2012 06:05:50 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Wed, 3 Oct 2012 06:05:50 -0700 (PDT) Date: Wed, 3 Oct 2012 16:05:50 +0300 Message-ID: From: Valtteri Kiviniemi To: Xen-devel@lists.xen.org Subject: [Xen-devel] Xen 4.2.0, VNC connection to Windows domU causes black screen on VNC X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6373454665948106797==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============6373454665948106797== Content-Type: multipart/alternative; boundary=20cf303dd26448299704cb274c1f --20cf303dd26448299704cb274c1f Content-Type: text/plain; charset=ISO-8859-1 Hi, I am trying to get Windows Server 2008 R2 HVM domU working in Xen 4.2.0. The domU will start and I can see the boot output to the point when the .iso-image starts loading and I get the "Windows is loading files" loading bar in VNC. After the Windows installer has finished loading the necessary files and starts the installer the resolution will change on the VNC screen and it goes black. However despite that, I think that the Windows installer is still starting fine and it probably is responding to keyboard input, I just cant see anything but black. Qemu-dm log file does not contain any error messages. I'm using the same config file on different server and it is working there, and when comparing the qemu-dm log files on this server and the other server where the windows is working they are pretty much consistent. I have tried playing with different settings on domU config, but nothing makes any difference, the outcome is always the same. Installer starts, resolution changes and then only black. I'am using rather new hardware, CPU is the new Intel Ivy-Bridge Core i7-3770 with integrated GPU and motherboard is Intel DQ77MK with latest bios installed. dom0 kernel is 3.6.0 64bit, hypervisor is 64bit and Windows is 64bit. The same kernel config and domU config is working on my older server which is running mid 2008 CPU Intel Q9950 and motherboard Intel DQ45CB, so I would suspect that this might be some kind of hardware incompatibility problem? Any ideas of how to debug this problem? I have enabled all the debuggint options for Xen and dom0 kernel but I'm not getting any error messages. It seems that the domU is working as intented but only graphics are missing. - Valtteri --20cf303dd26448299704cb274c1f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I am trying to get Windows Server 2008 R2 HVM domU working in Xe= n 4.2.0. The domU will start and I can see the boot output to the point whe= n the .iso-image starts loading and I get the "Windows is loading file= s" loading bar in VNC. After the Windows installer has finished loadin= g the necessary files and starts the installer the resolution will change o= n the VNC screen and it goes black. However despite that, I think that the = Windows installer is still starting fine and it probably is responding to k= eyboard input, I just cant see anything but black. Qemu-dm log file does no= t contain any error messages. I'm using the same config file on differe= nt server and it is working there, and when comparing the qemu-dm log files= on this server and the other server where the windows is working they are = pretty much consistent.

I have tried playing with different settings on domU config, but nothin= g makes any difference, the outcome is always the same. Installer starts, r= esolution changes and then only black. I'am using rather new hardware, = CPU is the new Intel Ivy-Bridge Core i7-3770 with integrated GPU and mother= board is Intel DQ77MK with latest bios installed. dom0 kernel is 3.6.0 64bi= t, hypervisor is 64bit and Windows is 64bit. The same kernel config and dom= U config is working on my older server which is running mid 2008 CPU Intel = Q9950 and motherboard Intel DQ45CB, so I would suspect that this might be s= ome kind of hardware incompatibility problem?

Any ideas of how to debug this problem? I have enabled all the debuggin= t options for Xen and dom0 kernel but I'm not getting any error message= s. It seems that the domU is working as intented but only graphics are miss= ing.

- Valtteri
--20cf303dd26448299704cb274c1f-- --===============6373454665948106797== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6373454665948106797==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 13:12:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 13:12:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOkb-0003zs-EL; Wed, 03 Oct 2012 13:12:33 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with smtp (Exim 4.72) (envelope-from ) id 1TJOka-0003zm-3V for xen-devel@lists.xen.org; Wed, 03 Oct 2012 13:12:32 +0000 X-Env-Sender: jbeulich@suse.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1349269935!8605637!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16291 invoked from network); 3 Oct 2012 13:12:19 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-13.tower-27.messagelabs.com with SMTP; 3 Oct 2012 13:12:19 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 03 Oct 2012 14:12:15 +0100 Message-Id: <506C47BD020000780008D01A@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Wed, 03 Oct 2012 14:12:13 +0100 From: "Jan Beulich" To: References: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4B98@SJCPMAILBOX01.citrite.net> <40501859.20120902104331@eikelenboom.it> <5044849002000078000982EA@nat28.tlf.novell.com> <4610648186.20120904090841@eikelenboom.it> <5045CDF302000078000985FB@nat28.tlf.novell.com> <4710608674.20120904101330@eikelenboom.it> <5045E55A02000078000986E4@nat28.tlf.novell.com> <20121002200907.GC668@phenom.dumpdata.com> In-Reply-To: <20121002200907.GC668@phenom.dumpdata.com> Mime-Version: 1.0 Content-Disposition: inline Cc: jeremy@goop.org, ehabkost@redhat.com, xen-devel@lists.xen.org, wei.wang2@amd.com, linux@eikelenboom.it, keir.xen@gmail.com, Santosh.Jodh@citrix.com Subject: Re: [Xen-devel] Using debug-key 'o: Dump IOMMU p2m table, locks up machine X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> Konrad Rzeszutek Wilk 10/02/12 10:21 PM >>> >On Tue, Sep 04, 2012 at 10:26:18AM +0100, Jan Beulich wrote: >> But the disassembly already tells us where precisely the >> problem is: The selector value (0x0063) attempted to be put >> into %gs is apparently wrong in the context of the current >> GDT. Now, that's GDT_ENTRY_TLS_MIN on the Linux side, >> and ought to be valid. I'm surprised the guest (and the current >> process in it) survives this (as the failure here results in a failsafe >> callback into the guest). >> >> Looking at the Linux side of things, this has been that way >> forever, and I think has always been broken: On x86-64, it >> should also clear %gs here (since 32-bit processes use it for >> their TLS, and there's nothing wrong for a 64-bit process to put >> something in there either), albeit not via loadsegment(), but >> through xen_load_gs_index(). And I neither see why on 32-bit >> it only clears %gs - %fs can as much hold a selector that might >> get invalidated with the TLS descriptor updates. Eduardo, >> Jeremy, Konrad? > >How is it on the SLES side? Do you set/restore all of the segment >registers? I think so (don't have the sources around at home to check), but that's not the point. What absolutely has to happen is the _clearing_ of the selector registers before switching descriptor tables (even if done via multicall, as the hypervisor may restore guest state between any two pieces of a multicall set). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 13:12:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 13:12:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOkb-0003zs-EL; Wed, 03 Oct 2012 13:12:33 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with smtp (Exim 4.72) (envelope-from ) id 1TJOka-0003zm-3V for xen-devel@lists.xen.org; Wed, 03 Oct 2012 13:12:32 +0000 X-Env-Sender: jbeulich@suse.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1349269935!8605637!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16291 invoked from network); 3 Oct 2012 13:12:19 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-13.tower-27.messagelabs.com with SMTP; 3 Oct 2012 13:12:19 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 03 Oct 2012 14:12:15 +0100 Message-Id: <506C47BD020000780008D01A@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Wed, 03 Oct 2012 14:12:13 +0100 From: "Jan Beulich" To: References: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4B98@SJCPMAILBOX01.citrite.net> <40501859.20120902104331@eikelenboom.it> <5044849002000078000982EA@nat28.tlf.novell.com> <4610648186.20120904090841@eikelenboom.it> <5045CDF302000078000985FB@nat28.tlf.novell.com> <4710608674.20120904101330@eikelenboom.it> <5045E55A02000078000986E4@nat28.tlf.novell.com> <20121002200907.GC668@phenom.dumpdata.com> In-Reply-To: <20121002200907.GC668@phenom.dumpdata.com> Mime-Version: 1.0 Content-Disposition: inline Cc: jeremy@goop.org, ehabkost@redhat.com, xen-devel@lists.xen.org, wei.wang2@amd.com, linux@eikelenboom.it, keir.xen@gmail.com, Santosh.Jodh@citrix.com Subject: Re: [Xen-devel] Using debug-key 'o: Dump IOMMU p2m table, locks up machine X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> Konrad Rzeszutek Wilk 10/02/12 10:21 PM >>> >On Tue, Sep 04, 2012 at 10:26:18AM +0100, Jan Beulich wrote: >> But the disassembly already tells us where precisely the >> problem is: The selector value (0x0063) attempted to be put >> into %gs is apparently wrong in the context of the current >> GDT. Now, that's GDT_ENTRY_TLS_MIN on the Linux side, >> and ought to be valid. I'm surprised the guest (and the current >> process in it) survives this (as the failure here results in a failsafe >> callback into the guest). >> >> Looking at the Linux side of things, this has been that way >> forever, and I think has always been broken: On x86-64, it >> should also clear %gs here (since 32-bit processes use it for >> their TLS, and there's nothing wrong for a 64-bit process to put >> something in there either), albeit not via loadsegment(), but >> through xen_load_gs_index(). And I neither see why on 32-bit >> it only clears %gs - %fs can as much hold a selector that might >> get invalidated with the TLS descriptor updates. Eduardo, >> Jeremy, Konrad? > >How is it on the SLES side? Do you set/restore all of the segment >registers? I think so (don't have the sources around at home to check), but that's not the point. What absolutely has to happen is the _clearing_ of the selector registers before switching descriptor tables (even if done via multicall, as the hypervisor may restore guest state between any two pieces of a multicall set). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 13:17:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 13:17:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOos-00047u-4y; Wed, 03 Oct 2012 13:16:58 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOoq-00047n-6R for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 13:16:56 +0000 Received: from [85.158.143.99:16435] by server-2.bemta-4.messagelabs.com id 0C/B6-06610-7CA3C605; Wed, 03 Oct 2012 13:16:55 +0000 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1349270214!32107018!1 X-Originating-IP: [74.125.83.43] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23004 invoked from network); 3 Oct 2012 13:16:54 -0000 Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com) (74.125.83.43) by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 13:16:54 -0000 Received: by eekc13 with SMTP id c13so4093163eek.30 for ; Wed, 03 Oct 2012 06:16:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=pPlYY6HokkS9MQI1bXWlz/aHpt2x+1ZyKxHy/INF54A=; b=lG/MwEKxfGzsb8WAZd4+W/wX6x1LE/5HBspkD1/sIm9m/gD03CEmd4riOdSueHKZ3A cnsoKXC/XHZnjL7OmtF34g6sLZY3Ej5s5ThM/A6Nncj7cVg+Ix6Iirexf8ASc81Twm/r eaDcqASLOiwY4xaETiEMcmYWHW0KI9iHmAZONAhbPPm/3IF+McA2LQRkRgYOMMNfLWbB Tu3639E05w07k3K9MN21F3rtWS6VmFxuxyXNHzWdyWgJuddDLl5L7yYm0tKJSUJ28L9O JgPg0g4hVfr066J+OCWx+R85NkPRu8jVvSNQC3RHFuz2U/FdoyupEBpyL5NzOSuS0DdG 8RSw== MIME-Version: 1.0 Received: by 10.14.200.134 with SMTP id z6mr2579501een.33.1349270214008; Wed, 03 Oct 2012 06:16:54 -0700 (PDT) Received: by 10.14.215.195 with HTTP; Wed, 3 Oct 2012 06:16:53 -0700 (PDT) In-Reply-To: <506BF6C0.8020104@tiscali.it> References: <506AB70D.90908@tiscali.it> <506ABADC.5090400@laukamp.me> <506ABCA1.5010602@tiscali.it> <506AC344.7070704@laukamp.me> <506BF6C0.8020104@tiscali.it> Date: Wed, 3 Oct 2012 14:16:53 +0100 X-Google-Sender-Auth: 9L9P0c7fznJ3cLo8kjFGSJIxqqo Message-ID: From: George Dunlap To: fantonifabio@tiscali.it Content-Type: multipart/mixed; boundary=047d7b343a72cfe13604cb277348 Cc: xen-devel , Lukas Laukamp Subject: Re: [Xen-devel] Unable to install Precise domU PV on xen 4.2.0 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --047d7b343a72cfe13604cb277348 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 3, 2012 at 9:26 AM, Fabio Fantoni wrote: > ----------------------------------------------------------------------------------------------- > /var/log/xen/bootloader.9.log > ----------------------------------------------------------------------------------------------- > Traceback (most recent call last): > File "/usr/lib/xen/bin/pygrub", line 20, in > import xen.lowlevel.xc > ImportError: No module named xen.lowlevel.xc > ----------------------------------------------------------------------------------------------- I haven't looked at the rest of this thread in detail; but this kind of error is typically because of a bug with how debian's python installer places binaries if it's given a "--prefix" argument. But it seems like if the bootloader was failing, it should have a different set of error messages. Can you try the attached patch to see if it changes anything? -George --047d7b343a72cfe13604cb277348 Content-Type: application/octet-stream; name="xend-python2.6" Content-Disposition: attachment; filename="xend-python2.6" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h7ughahz1 IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKIyBVc2VyIElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNp dHJpeC5jb20+CiMgRGF0ZSAxMzMwNTMzMDM0IDAKIyBOb2RlIElEIDNiNmQyYWU3MDY5NWRlM2Mw YmQ3YmE3MjEzZmU5Y2E5ODdjNzJhMzYKIyBQYXJlbnQgIDU1MWJhNTk5ZThiYjEwOTU4MWZlN2M1 ODA3MTRiYmYwMzI5NDZmYWIKaW1wb3J0ZWQgcGF0Y2ggeGVuZC1weXRob24yLjYKCmRpZmYgLXIg NTUxYmE1OTllOGJiIC1yIDNiNmQyYWU3MDY5NSBDb25maWcubWsKLS0tIGEvQ29uZmlnLm1rCVdl ZCBGZWIgMjkgMTY6MzA6MzQgMjAxMiArMDAwMAorKysgYi9Db25maWcubWsJV2VkIEZlYiAyOSAx NjozMDozNCAyMDEyICswMDAwCkBAIC03MSw3ICs3MSw3IEBAIEVYVFJBX0xJQiArPSAkKEVYVFJB X1BSRUZJWCkvJChMSUJMRUFGREkKIGVuZGlmCiAKIFBZVEhPTiAgICAgID89IHB5dGhvbgotUFlU SE9OX1BSRUZJWF9BUkcgPz0gLS1wcmVmaXg9IiQoUFJFRklYKSIKK1BZVEhPTl9QUkVGSVhfQVJH ID89IC0taW5zdGFsbC1sYXlvdXQ9ZGViCiAjIFRoZSBhYm92ZSByZXF1aXJlcyB0aGF0IFBSRUZJ WCBjb250YWlucyAqbm8gc3BhY2VzKi4gVGhpcyB2YXJpYWJsZSBpcyBoZXJlCiAjIHRvIHBlcm1p dCB0aGUgdXNlciB0byBzZXQgUFlUSE9OX1BSRUZJWF9BUkcgdG8gJycgdG8gd29ya2Fyb3VuZCB0 aGlzIGJ1ZzoKICMgIGh0dHBzOi8vYnVncy5sYXVuY2hwYWQubmV0L3VidW50dS8rYnVnLzM2MjU3 MAo= --047d7b343a72cfe13604cb277348 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --047d7b343a72cfe13604cb277348-- From xen-devel-bounces@lists.xen.org Wed Oct 03 13:17:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 13:17:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOos-00047u-4y; Wed, 03 Oct 2012 13:16:58 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOoq-00047n-6R for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 13:16:56 +0000 Received: from [85.158.143.99:16435] by server-2.bemta-4.messagelabs.com id 0C/B6-06610-7CA3C605; Wed, 03 Oct 2012 13:16:55 +0000 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1349270214!32107018!1 X-Originating-IP: [74.125.83.43] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23004 invoked from network); 3 Oct 2012 13:16:54 -0000 Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com) (74.125.83.43) by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 13:16:54 -0000 Received: by eekc13 with SMTP id c13so4093163eek.30 for ; Wed, 03 Oct 2012 06:16:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=pPlYY6HokkS9MQI1bXWlz/aHpt2x+1ZyKxHy/INF54A=; b=lG/MwEKxfGzsb8WAZd4+W/wX6x1LE/5HBspkD1/sIm9m/gD03CEmd4riOdSueHKZ3A cnsoKXC/XHZnjL7OmtF34g6sLZY3Ej5s5ThM/A6Nncj7cVg+Ix6Iirexf8ASc81Twm/r eaDcqASLOiwY4xaETiEMcmYWHW0KI9iHmAZONAhbPPm/3IF+McA2LQRkRgYOMMNfLWbB Tu3639E05w07k3K9MN21F3rtWS6VmFxuxyXNHzWdyWgJuddDLl5L7yYm0tKJSUJ28L9O JgPg0g4hVfr066J+OCWx+R85NkPRu8jVvSNQC3RHFuz2U/FdoyupEBpyL5NzOSuS0DdG 8RSw== MIME-Version: 1.0 Received: by 10.14.200.134 with SMTP id z6mr2579501een.33.1349270214008; Wed, 03 Oct 2012 06:16:54 -0700 (PDT) Received: by 10.14.215.195 with HTTP; Wed, 3 Oct 2012 06:16:53 -0700 (PDT) In-Reply-To: <506BF6C0.8020104@tiscali.it> References: <506AB70D.90908@tiscali.it> <506ABADC.5090400@laukamp.me> <506ABCA1.5010602@tiscali.it> <506AC344.7070704@laukamp.me> <506BF6C0.8020104@tiscali.it> Date: Wed, 3 Oct 2012 14:16:53 +0100 X-Google-Sender-Auth: 9L9P0c7fznJ3cLo8kjFGSJIxqqo Message-ID: From: George Dunlap To: fantonifabio@tiscali.it Content-Type: multipart/mixed; boundary=047d7b343a72cfe13604cb277348 Cc: xen-devel , Lukas Laukamp Subject: Re: [Xen-devel] Unable to install Precise domU PV on xen 4.2.0 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --047d7b343a72cfe13604cb277348 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 3, 2012 at 9:26 AM, Fabio Fantoni wrote: > ----------------------------------------------------------------------------------------------- > /var/log/xen/bootloader.9.log > ----------------------------------------------------------------------------------------------- > Traceback (most recent call last): > File "/usr/lib/xen/bin/pygrub", line 20, in > import xen.lowlevel.xc > ImportError: No module named xen.lowlevel.xc > ----------------------------------------------------------------------------------------------- I haven't looked at the rest of this thread in detail; but this kind of error is typically because of a bug with how debian's python installer places binaries if it's given a "--prefix" argument. But it seems like if the bootloader was failing, it should have a different set of error messages. Can you try the attached patch to see if it changes anything? -George --047d7b343a72cfe13604cb277348 Content-Type: application/octet-stream; name="xend-python2.6" Content-Disposition: attachment; filename="xend-python2.6" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h7ughahz1 IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKIyBVc2VyIElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNp dHJpeC5jb20+CiMgRGF0ZSAxMzMwNTMzMDM0IDAKIyBOb2RlIElEIDNiNmQyYWU3MDY5NWRlM2Mw YmQ3YmE3MjEzZmU5Y2E5ODdjNzJhMzYKIyBQYXJlbnQgIDU1MWJhNTk5ZThiYjEwOTU4MWZlN2M1 ODA3MTRiYmYwMzI5NDZmYWIKaW1wb3J0ZWQgcGF0Y2ggeGVuZC1weXRob24yLjYKCmRpZmYgLXIg NTUxYmE1OTllOGJiIC1yIDNiNmQyYWU3MDY5NSBDb25maWcubWsKLS0tIGEvQ29uZmlnLm1rCVdl ZCBGZWIgMjkgMTY6MzA6MzQgMjAxMiArMDAwMAorKysgYi9Db25maWcubWsJV2VkIEZlYiAyOSAx NjozMDozNCAyMDEyICswMDAwCkBAIC03MSw3ICs3MSw3IEBAIEVYVFJBX0xJQiArPSAkKEVYVFJB X1BSRUZJWCkvJChMSUJMRUFGREkKIGVuZGlmCiAKIFBZVEhPTiAgICAgID89IHB5dGhvbgotUFlU SE9OX1BSRUZJWF9BUkcgPz0gLS1wcmVmaXg9IiQoUFJFRklYKSIKK1BZVEhPTl9QUkVGSVhfQVJH ID89IC0taW5zdGFsbC1sYXlvdXQ9ZGViCiAjIFRoZSBhYm92ZSByZXF1aXJlcyB0aGF0IFBSRUZJ WCBjb250YWlucyAqbm8gc3BhY2VzKi4gVGhpcyB2YXJpYWJsZSBpcyBoZXJlCiAjIHRvIHBlcm1p dCB0aGUgdXNlciB0byBzZXQgUFlUSE9OX1BSRUZJWF9BUkcgdG8gJycgdG8gd29ya2Fyb3VuZCB0 aGlzIGJ1ZzoKICMgIGh0dHBzOi8vYnVncy5sYXVuY2hwYWQubmV0L3VidW50dS8rYnVnLzM2MjU3 MAo= --047d7b343a72cfe13604cb277348 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --047d7b343a72cfe13604cb277348-- From xen-devel-bounces@lists.xen.org Wed Oct 03 13:22:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 13:22:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOtb-0004HO-Sv; Wed, 03 Oct 2012 13:21:51 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOtb-0004HI-6h for Xen-devel@lists.xensource.com; Wed, 03 Oct 2012 13:21:51 +0000 Received: from [85.158.143.99:32758] by server-1.bemta-4.messagelabs.com id 1C/31-05684-EEB3C605; Wed, 03 Oct 2012 13:21:50 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1349270497!26270591!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6974 invoked from network); 3 Oct 2012 13:21:39 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 13:21:39 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="14916100" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 13:21:37 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 14:21:37 +0100 Message-ID: <1349270495.650.144.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Mukesh Rathor Date: Wed, 3 Oct 2012 14:21:35 +0100 In-Reply-To: <20120921122123.33489ce1@mantra.us.oracle.com> References: <20120921122123.33489ce1@mantra.us.oracle.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 7/8]: PVH privcmd changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-09-21 at 20:21 +0100, Mukesh Rathor wrote: > +static int pvh_privcmd_resv_pfns(struct vm_area_struct *vma, int numpgs) ... > + pvhp->pi_num_pgs = numpgs; > + BUG_ON(vma->vm_private_data != (void *)1); > + vma->vm_private_data = pvhp; How does this interact with: static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma) { return (xchg(&vma->vm_private_data, (void *)1) == NULL); } If someone tries to map a second time then won't this correct the pvhp in vm_private_data by resetting it to 1? Then when the original mapping is torn down things all fall apart? Perhaps we need a cmpxchg here? Or to rework the callers a little bit perhaps. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 13:22:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 13:22:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOtb-0004HO-Sv; Wed, 03 Oct 2012 13:21:51 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOtb-0004HI-6h for Xen-devel@lists.xensource.com; Wed, 03 Oct 2012 13:21:51 +0000 Received: from [85.158.143.99:32758] by server-1.bemta-4.messagelabs.com id 1C/31-05684-EEB3C605; Wed, 03 Oct 2012 13:21:50 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1349270497!26270591!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6974 invoked from network); 3 Oct 2012 13:21:39 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 13:21:39 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="14916100" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 13:21:37 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 14:21:37 +0100 Message-ID: <1349270495.650.144.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Mukesh Rathor Date: Wed, 3 Oct 2012 14:21:35 +0100 In-Reply-To: <20120921122123.33489ce1@mantra.us.oracle.com> References: <20120921122123.33489ce1@mantra.us.oracle.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 7/8]: PVH privcmd changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-09-21 at 20:21 +0100, Mukesh Rathor wrote: > +static int pvh_privcmd_resv_pfns(struct vm_area_struct *vma, int numpgs) ... > + pvhp->pi_num_pgs = numpgs; > + BUG_ON(vma->vm_private_data != (void *)1); > + vma->vm_private_data = pvhp; How does this interact with: static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma) { return (xchg(&vma->vm_private_data, (void *)1) == NULL); } If someone tries to map a second time then won't this correct the pvhp in vm_private_data by resetting it to 1? Then when the original mapping is torn down things all fall apart? Perhaps we need a cmpxchg here? Or to rework the callers a little bit perhaps. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 13:22:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 13:22:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOuH-0004Kx-Fo; Wed, 03 Oct 2012 13:22:33 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOuF-0004Km-LQ for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 13:22:31 +0000 Received: from [85.158.143.99:39487] by server-3.bemta-4.messagelabs.com id 6F/43-10986-61C3C605; Wed, 03 Oct 2012 13:22:30 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1349270548!23098808!1 X-Originating-IP: [209.85.161.173] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8342 invoked from network); 3 Oct 2012 13:22:30 -0000 Received: from mail-gg0-f173.google.com (HELO mail-gg0-f173.google.com) (209.85.161.173) by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 13:22:30 -0000 Received: by ggcs5 with SMTP id s5so637532ggc.32 for ; Wed, 03 Oct 2012 06:22:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=R4rMzrm27mRreETV/Nd+Vi3/fe/ZMIFwPIX0v+YApdY=; b=C3S/vrBurAj+n6X1di/E0TgCi5f9QM1wLu9cyI95kDPIE4NulkgRNIZWJloretJfk9 NImRBADQtx3yZhanppetnW0PxsVRFY7AQhJ39CSfNFCDiKaRPvVobIHfT74E5YsDzKRi iHPvbaPuOUQ+Jt88Of7bqMHiUFtN7d2UWH1bMmhFZyLWFW6wsqEwVXZDFTIIPMBSVzfW Oe9koX2VcsdKlyYWaBxNih06FNRZbUvcqppMyla2gtUSIwbc0qh95tSYM3woKY2No6LP uLfTyQNp7974yS9quaH6a+9Byo8WhNi6/UnzODjZa5AbHEk60ygS1yWK6XKneNXpBTE9 axoA== MIME-Version: 1.0 Received: by 10.236.137.70 with SMTP id x46mr1873575yhi.12.1349270548611; Wed, 03 Oct 2012 06:22:28 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Wed, 3 Oct 2012 06:22:28 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Oct 2012 16:22:28 +0300 Message-ID: From: Valtteri Kiviniemi To: chris Cc: Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.2.0, VNC connection to Windows domU causes black screen on VNC X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7549355610410302325==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============7549355610410302325== Content-Type: multipart/alternative; boundary=20cf303ea8cec1820b04cb2787d4 --20cf303ea8cec1820b04cb2787d4 Content-Type: text/plain; charset=ISO-8859-1 Hi, Tested with realvnc and tightvnc. Realvnc just closes itself when the resolution changes and tightvnc just stays open with the black screen. - Valtteri 2012/10/3 chris > What vnc client I've seen this on os x > On Oct 3, 2012 9:08 AM, "Valtteri Kiviniemi" > wrote: > >> Hi, >> >> I am trying to get Windows Server 2008 R2 HVM domU working in Xen 4.2.0. >> The domU will start and I can see the boot output to the point when the >> .iso-image starts loading and I get the "Windows is loading files" loading >> bar in VNC. After the Windows installer has finished loading the necessary >> files and starts the installer the resolution will change on the VNC screen >> and it goes black. However despite that, I think that the Windows installer >> is still starting fine and it probably is responding to keyboard input, I >> just cant see anything but black. Qemu-dm log file does not contain any >> error messages. I'm using the same config file on different server and it >> is working there, and when comparing the qemu-dm log files on this server >> and the other server where the windows is working they are pretty much >> consistent. >> >> I have tried playing with different settings on domU config, but nothing >> makes any difference, the outcome is always the same. Installer starts, >> resolution changes and then only black. I'am using rather new hardware, CPU >> is the new Intel Ivy-Bridge Core i7-3770 with integrated GPU and >> motherboard is Intel DQ77MK with latest bios installed. dom0 kernel is >> 3.6.0 64bit, hypervisor is 64bit and Windows is 64bit. The same kernel >> config and domU config is working on my older server which is running mid >> 2008 CPU Intel Q9950 and motherboard Intel DQ45CB, so I would suspect that >> this might be some kind of hardware incompatibility problem? >> >> Any ideas of how to debug this problem? I have enabled all the debuggint >> options for Xen and dom0 kernel but I'm not getting any error messages. It >> seems that the domU is working as intented but only graphics are missing. >> >> - Valtteri >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel >> >> --20cf303ea8cec1820b04cb2787d4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Tested with realvnc and tightvnc. Realvnc just closes itself whe= n the resolution changes and tightvnc just stays open with the black screen= .

- Valtteri

2012/10/3 chris <tk= nchris@gmail.com>

What vnc client I've seen= this on os x

On Oct 3, 2012 9:08 AM, &= quot;Valtteri Kiviniemi" <kiviniemi.valtteri@gmail.com> wrote:
Hi,

I am trying to get Windows Server 2008 R2 HVM domU working in Xe= n 4.2.0. The domU will start and I can see the boot output to the point whe= n the .iso-image starts loading and I get the "Windows is loading file= s" loading bar in VNC. After the Windows installer has finished loadin= g the necessary files and starts the installer the resolution will change o= n the VNC screen and it goes black. However despite that, I think that the = Windows installer is still starting fine and it probably is responding to k= eyboard input, I just cant see anything but black. Qemu-dm log file does no= t contain any error messages. I'm using the same config file on differe= nt server and it is working there, and when comparing the qemu-dm log files= on this server and the other server where the windows is working they are = pretty much consistent.

I have tried playing with different settings on domU config, but nothin= g makes any difference, the outcome is always the same. Installer starts, r= esolution changes and then only black. I'am using rather new hardware, = CPU is the new Intel Ivy-Bridge Core i7-3770 with integrated GPU and mother= board is Intel DQ77MK with latest bios installed. dom0 kernel is 3.6.0 64bi= t, hypervisor is 64bit and Windows is 64bit. The same kernel config and dom= U config is working on my older server which is running mid 2008 CPU Intel = Q9950 and motherboard Intel DQ45CB, so I would suspect that this might be s= ome kind of hardware incompatibility problem?

Any ideas of how to debug this problem? I have enabled all the debuggin= t options for Xen and dom0 kernel but I'm not getting any error message= s. It seems that the domU is working as intented but only graphics are miss= ing.

- Valtteri

_______________________________________________
Xen-devel mailing list
Xen-devel@list= s.xen.org
http://lists.x= en.org/xen-devel


--20cf303ea8cec1820b04cb2787d4-- --===============7549355610410302325== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============7549355610410302325==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 13:22:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 13:22:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOuH-0004Kx-Fo; Wed, 03 Oct 2012 13:22:33 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOuF-0004Km-LQ for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 13:22:31 +0000 Received: from [85.158.143.99:39487] by server-3.bemta-4.messagelabs.com id 6F/43-10986-61C3C605; Wed, 03 Oct 2012 13:22:30 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1349270548!23098808!1 X-Originating-IP: [209.85.161.173] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8342 invoked from network); 3 Oct 2012 13:22:30 -0000 Received: from mail-gg0-f173.google.com (HELO mail-gg0-f173.google.com) (209.85.161.173) by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 13:22:30 -0000 Received: by ggcs5 with SMTP id s5so637532ggc.32 for ; Wed, 03 Oct 2012 06:22:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=R4rMzrm27mRreETV/Nd+Vi3/fe/ZMIFwPIX0v+YApdY=; b=C3S/vrBurAj+n6X1di/E0TgCi5f9QM1wLu9cyI95kDPIE4NulkgRNIZWJloretJfk9 NImRBADQtx3yZhanppetnW0PxsVRFY7AQhJ39CSfNFCDiKaRPvVobIHfT74E5YsDzKRi iHPvbaPuOUQ+Jt88Of7bqMHiUFtN7d2UWH1bMmhFZyLWFW6wsqEwVXZDFTIIPMBSVzfW Oe9koX2VcsdKlyYWaBxNih06FNRZbUvcqppMyla2gtUSIwbc0qh95tSYM3woKY2No6LP uLfTyQNp7974yS9quaH6a+9Byo8WhNi6/UnzODjZa5AbHEk60ygS1yWK6XKneNXpBTE9 axoA== MIME-Version: 1.0 Received: by 10.236.137.70 with SMTP id x46mr1873575yhi.12.1349270548611; Wed, 03 Oct 2012 06:22:28 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Wed, 3 Oct 2012 06:22:28 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Oct 2012 16:22:28 +0300 Message-ID: From: Valtteri Kiviniemi To: chris Cc: Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.2.0, VNC connection to Windows domU causes black screen on VNC X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7549355610410302325==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============7549355610410302325== Content-Type: multipart/alternative; boundary=20cf303ea8cec1820b04cb2787d4 --20cf303ea8cec1820b04cb2787d4 Content-Type: text/plain; charset=ISO-8859-1 Hi, Tested with realvnc and tightvnc. Realvnc just closes itself when the resolution changes and tightvnc just stays open with the black screen. - Valtteri 2012/10/3 chris > What vnc client I've seen this on os x > On Oct 3, 2012 9:08 AM, "Valtteri Kiviniemi" > wrote: > >> Hi, >> >> I am trying to get Windows Server 2008 R2 HVM domU working in Xen 4.2.0. >> The domU will start and I can see the boot output to the point when the >> .iso-image starts loading and I get the "Windows is loading files" loading >> bar in VNC. After the Windows installer has finished loading the necessary >> files and starts the installer the resolution will change on the VNC screen >> and it goes black. However despite that, I think that the Windows installer >> is still starting fine and it probably is responding to keyboard input, I >> just cant see anything but black. Qemu-dm log file does not contain any >> error messages. I'm using the same config file on different server and it >> is working there, and when comparing the qemu-dm log files on this server >> and the other server where the windows is working they are pretty much >> consistent. >> >> I have tried playing with different settings on domU config, but nothing >> makes any difference, the outcome is always the same. Installer starts, >> resolution changes and then only black. I'am using rather new hardware, CPU >> is the new Intel Ivy-Bridge Core i7-3770 with integrated GPU and >> motherboard is Intel DQ77MK with latest bios installed. dom0 kernel is >> 3.6.0 64bit, hypervisor is 64bit and Windows is 64bit. The same kernel >> config and domU config is working on my older server which is running mid >> 2008 CPU Intel Q9950 and motherboard Intel DQ45CB, so I would suspect that >> this might be some kind of hardware incompatibility problem? >> >> Any ideas of how to debug this problem? I have enabled all the debuggint >> options for Xen and dom0 kernel but I'm not getting any error messages. It >> seems that the domU is working as intented but only graphics are missing. >> >> - Valtteri >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel >> >> --20cf303ea8cec1820b04cb2787d4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Tested with realvnc and tightvnc. Realvnc just closes itself whe= n the resolution changes and tightvnc just stays open with the black screen= .

- Valtteri

2012/10/3 chris <tk= nchris@gmail.com>

What vnc client I've seen= this on os x

On Oct 3, 2012 9:08 AM, &= quot;Valtteri Kiviniemi" <kiviniemi.valtteri@gmail.com> wrote:
Hi,

I am trying to get Windows Server 2008 R2 HVM domU working in Xe= n 4.2.0. The domU will start and I can see the boot output to the point whe= n the .iso-image starts loading and I get the "Windows is loading file= s" loading bar in VNC. After the Windows installer has finished loadin= g the necessary files and starts the installer the resolution will change o= n the VNC screen and it goes black. However despite that, I think that the = Windows installer is still starting fine and it probably is responding to k= eyboard input, I just cant see anything but black. Qemu-dm log file does no= t contain any error messages. I'm using the same config file on differe= nt server and it is working there, and when comparing the qemu-dm log files= on this server and the other server where the windows is working they are = pretty much consistent.

I have tried playing with different settings on domU config, but nothin= g makes any difference, the outcome is always the same. Installer starts, r= esolution changes and then only black. I'am using rather new hardware, = CPU is the new Intel Ivy-Bridge Core i7-3770 with integrated GPU and mother= board is Intel DQ77MK with latest bios installed. dom0 kernel is 3.6.0 64bi= t, hypervisor is 64bit and Windows is 64bit. The same kernel config and dom= U config is working on my older server which is running mid 2008 CPU Intel = Q9950 and motherboard Intel DQ45CB, so I would suspect that this might be s= ome kind of hardware incompatibility problem?

Any ideas of how to debug this problem? I have enabled all the debuggin= t options for Xen and dom0 kernel but I'm not getting any error message= s. It seems that the domU is working as intented but only graphics are miss= ing.

- Valtteri

_______________________________________________
Xen-devel mailing list
Xen-devel@list= s.xen.org
http://lists.x= en.org/xen-devel


--20cf303ea8cec1820b04cb2787d4-- --===============7549355610410302325== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============7549355610410302325==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 13:22:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 13:22:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOuK-0004LV-T5; Wed, 03 Oct 2012 13:22:36 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with smtp (Exim 4.72) (envelope-from ) id 1TJOuJ-0004Kk-5n for xen-devel@lists.xen.org; Wed, 03 Oct 2012 13:22:35 +0000 X-Env-Sender: jbeulich@suse.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1349270548!3516444!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6248 invoked from network); 3 Oct 2012 13:22:28 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-10.tower-27.messagelabs.com with SMTP; 3 Oct 2012 13:22:28 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 03 Oct 2012 14:22:28 +0100 Message-Id: <506C4A23020000780008D033@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Wed, 03 Oct 2012 14:22:27 +0100 From: "Jan Beulich" To: References: <506C3123.5050700@citrix.com> <506C31D0.4060702@citrix.com> In-Reply-To: <506C31D0.4060702@citrix.com> Mime-Version: 1.0 Content-Disposition: inline Cc: dario.faggioli@citrix.com, keir@xen.org, xen-devel@lists.xen.org Subject: Re: [Xen-devel] [Xen-devel V2] sedf/build: Fix build when using -fno-inline X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> Andrew Cooper 10/03/12 2:38 PM >>> >On 03/10/12 13:35, Andrew Cooper wrote: >> I found this issue while trying to debug on a separate issue. It >> certainly affects unstable thru 4.1, and probably earlier, so should be >> take for backport. >> > >Apologies - try this patch which has less Unicode in the commit message. I certainly agree to the change for -unstable, but what's the rationale for the backport request (given that there's no -fno-inline anywhere in the tree)? Is this actively causing problems in any non-debugging environment? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 13:22:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 13:22:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOuK-0004LV-T5; Wed, 03 Oct 2012 13:22:36 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with smtp (Exim 4.72) (envelope-from ) id 1TJOuJ-0004Kk-5n for xen-devel@lists.xen.org; Wed, 03 Oct 2012 13:22:35 +0000 X-Env-Sender: jbeulich@suse.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1349270548!3516444!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6248 invoked from network); 3 Oct 2012 13:22:28 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-10.tower-27.messagelabs.com with SMTP; 3 Oct 2012 13:22:28 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 03 Oct 2012 14:22:28 +0100 Message-Id: <506C4A23020000780008D033@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Wed, 03 Oct 2012 14:22:27 +0100 From: "Jan Beulich" To: References: <506C3123.5050700@citrix.com> <506C31D0.4060702@citrix.com> In-Reply-To: <506C31D0.4060702@citrix.com> Mime-Version: 1.0 Content-Disposition: inline Cc: dario.faggioli@citrix.com, keir@xen.org, xen-devel@lists.xen.org Subject: Re: [Xen-devel] [Xen-devel V2] sedf/build: Fix build when using -fno-inline X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> Andrew Cooper 10/03/12 2:38 PM >>> >On 03/10/12 13:35, Andrew Cooper wrote: >> I found this issue while trying to debug on a separate issue. It >> certainly affects unstable thru 4.1, and probably earlier, so should be >> take for backport. >> > >Apologies - try this patch which has less Unicode in the commit message. I certainly agree to the change for -unstable, but what's the rationale for the backport request (given that there's no -fno-inline anywhere in the tree)? Is this actively causing problems in any non-debugging environment? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 13:25:36 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 13:25:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOx5-0004dV-G4; Wed, 03 Oct 2012 13:25:27 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOx3-0004dH-Us for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 13:25:26 +0000 Received: from [85.158.139.83:41275] by server-9.bemta-5.messagelabs.com id 93/C9-14846-4CC3C605; Wed, 03 Oct 2012 13:25:24 +0000 X-Env-Sender: ketuzsezr@gmail.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1349270720!28706857!1 X-Originating-IP: [209.85.220.45] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27798 invoked from network); 3 Oct 2012 13:25:22 -0000 Received: from mail-pa0-f45.google.com (HELO mail-pa0-f45.google.com) (209.85.220.45) by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 13:25:22 -0000 Received: by padfb10 with SMTP id fb10so6517396pad.32 for ; Wed, 03 Oct 2012 06:25:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yigF6CqMJ9qxBhIe5LVztVKE6cMXMwoyy0HeCFkMtU8=; b=S7AdiaOGj2sbJIjyyrTlBSFiXric9Pu8Nu+Md77+I9BwpZvZrttDb224Edwuf477HX f2x73nnP5v6YeoTbiaxjQvwiNfEyt+Rcs7qyGvUaXCOGg0oxiqKxdlYHwhmqE40WsV6a 0ehh5he09M3Ro4BpPUnwKtAZV1Y4pa4WuBEyNjTpsCScSsIYQO8kSK2kcKxlH0e48MOR 8Bb4ea4TdrIi1bG0F1M+jum+mMlZOmbQH+/gofUXtMXXF6nUeF6vH3L1GyqCAswPlvsu k2uzi23pE4Wzb1kjrOPZrYPY5izHsTzVmAcCq9V8Q8Q5koJldJqiYscfUvc9MirQGYsx iCrQ== MIME-Version: 1.0 Received: by 10.68.131.35 with SMTP id oj3mr3431415pbb.128.1349270719876; Wed, 03 Oct 2012 06:25:19 -0700 (PDT) Received: by 10.66.193.9 with HTTP; Wed, 3 Oct 2012 06:25:19 -0700 (PDT) In-Reply-To: <20121003114552.GS8912@reaktio.net> References: <20121002121932.GL8912@reaktio.net> <20121002144251.GP8912@reaktio.net> <20121003114552.GS8912@reaktio.net> Date: Wed, 3 Oct 2012 09:25:19 -0400 X-Google-Sender-Auth: vmGDJKtaAMSHd1ErYkKSt5yZHRU Message-ID: From: Konrad Rzeszutek Wilk To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= Cc: Valtteri Kiviniemi , Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.0.4, kernel 3.5.0 HVM crash and kernel BUG X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, Oct 3, 2012 at 7:45 AM, Pasi K=E4rkk=E4inen wrote: > On Wed, Oct 03, 2012 at 12:21:47PM +0300, Valtteri Kiviniemi wrote: >> Hi, >> >> I disabled NUMA and upgraded to Xen 4.2.0. Windows domU starts now fi= ne >> and I cant anymore reproduce the hotplug problems. VNC output is still >> just black screen and it actually crashes the the whole VNC client wh= en >> after a few seconds. RealVNC just shuts itself down and tightvnc cras= hes. >> > > > Valtteri: Can you actually paste the names of the .config options you dis= abled > and got the dom0 kernel working without crashes? > > Maybe Konrad can comment if the current upstream dom0 kernel is supposed = to work > with NUMA support enabled / compiled in? There is a patch to actually disable it since we do not provide any NUMA information to the guest. And the dom0 has access to extra information (ACPI, Northbridge, etc) so it might think to create a NUMA topology and get it wrong. But his dmesg did not have anything obvious related to NUMA, so I am perplexed that turning that off would have made such a difference. Valterri - if you just pass 'numa=3Doff' on the Linux command line with the old kernel (the one that had the NUMA enabled) does that make it the iput issue go awa= y? You VNC issue .. does it work if you launch PV guests? Or is it only for HVM guests? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 13:25:36 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 13:25:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOx5-0004dV-G4; Wed, 03 Oct 2012 13:25:27 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOx3-0004dH-Us for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 13:25:26 +0000 Received: from [85.158.139.83:41275] by server-9.bemta-5.messagelabs.com id 93/C9-14846-4CC3C605; Wed, 03 Oct 2012 13:25:24 +0000 X-Env-Sender: ketuzsezr@gmail.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1349270720!28706857!1 X-Originating-IP: [209.85.220.45] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27798 invoked from network); 3 Oct 2012 13:25:22 -0000 Received: from mail-pa0-f45.google.com (HELO mail-pa0-f45.google.com) (209.85.220.45) by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 13:25:22 -0000 Received: by padfb10 with SMTP id fb10so6517396pad.32 for ; Wed, 03 Oct 2012 06:25:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yigF6CqMJ9qxBhIe5LVztVKE6cMXMwoyy0HeCFkMtU8=; b=S7AdiaOGj2sbJIjyyrTlBSFiXric9Pu8Nu+Md77+I9BwpZvZrttDb224Edwuf477HX f2x73nnP5v6YeoTbiaxjQvwiNfEyt+Rcs7qyGvUaXCOGg0oxiqKxdlYHwhmqE40WsV6a 0ehh5he09M3Ro4BpPUnwKtAZV1Y4pa4WuBEyNjTpsCScSsIYQO8kSK2kcKxlH0e48MOR 8Bb4ea4TdrIi1bG0F1M+jum+mMlZOmbQH+/gofUXtMXXF6nUeF6vH3L1GyqCAswPlvsu k2uzi23pE4Wzb1kjrOPZrYPY5izHsTzVmAcCq9V8Q8Q5koJldJqiYscfUvc9MirQGYsx iCrQ== MIME-Version: 1.0 Received: by 10.68.131.35 with SMTP id oj3mr3431415pbb.128.1349270719876; Wed, 03 Oct 2012 06:25:19 -0700 (PDT) Received: by 10.66.193.9 with HTTP; Wed, 3 Oct 2012 06:25:19 -0700 (PDT) In-Reply-To: <20121003114552.GS8912@reaktio.net> References: <20121002121932.GL8912@reaktio.net> <20121002144251.GP8912@reaktio.net> <20121003114552.GS8912@reaktio.net> Date: Wed, 3 Oct 2012 09:25:19 -0400 X-Google-Sender-Auth: vmGDJKtaAMSHd1ErYkKSt5yZHRU Message-ID: From: Konrad Rzeszutek Wilk To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= Cc: Valtteri Kiviniemi , Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.0.4, kernel 3.5.0 HVM crash and kernel BUG X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, Oct 3, 2012 at 7:45 AM, Pasi K=E4rkk=E4inen wrote: > On Wed, Oct 03, 2012 at 12:21:47PM +0300, Valtteri Kiviniemi wrote: >> Hi, >> >> I disabled NUMA and upgraded to Xen 4.2.0. Windows domU starts now fi= ne >> and I cant anymore reproduce the hotplug problems. VNC output is still >> just black screen and it actually crashes the the whole VNC client wh= en >> after a few seconds. RealVNC just shuts itself down and tightvnc cras= hes. >> > > > Valtteri: Can you actually paste the names of the .config options you dis= abled > and got the dom0 kernel working without crashes? > > Maybe Konrad can comment if the current upstream dom0 kernel is supposed = to work > with NUMA support enabled / compiled in? There is a patch to actually disable it since we do not provide any NUMA information to the guest. And the dom0 has access to extra information (ACPI, Northbridge, etc) so it might think to create a NUMA topology and get it wrong. But his dmesg did not have anything obvious related to NUMA, so I am perplexed that turning that off would have made such a difference. Valterri - if you just pass 'numa=3Doff' on the Linux command line with the old kernel (the one that had the NUMA enabled) does that make it the iput issue go awa= y? You VNC issue .. does it work if you launch PV guests? Or is it only for HVM guests? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 13:28:22 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 13:28:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOzk-0004pf-25; Wed, 03 Oct 2012 13:28:12 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOzi-0004pZ-UX for xen-devel@lists.xen.org; Wed, 03 Oct 2012 13:28:11 +0000 Received: from [85.158.137.99:36031] by server-8.bemta-3.messagelabs.com id 25/9A-16337-96D3C605; Wed, 03 Oct 2012 13:28:09 +0000 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-7.tower-217.messagelabs.com!1349270886!15333792!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzk2MzY=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23995 invoked from network); 3 Oct 2012 13:28:08 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 13:28:08 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="210151961" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 13:28:06 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 09:28:06 -0400 Received: from andrewcoop.uk.xensource.com ([10.80.2.18]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJOzd-0004Zx-Nn; Wed, 03 Oct 2012 14:28:05 +0100 Message-ID: <506C3D65.2080706@citrix.com> Date: Wed, 3 Oct 2012 14:28:05 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Jan Beulich References: <506C3123.5050700@citrix.com> <506C31D0.4060702@citrix.com> <506C4A23020000780008D033@nat28.tlf.novell.com> In-Reply-To: <506C4A23020000780008D033@nat28.tlf.novell.com> X-Enigmail-Version: 1.4.4 Cc: Dario Faggioli , "Keir \(Xen.org\)" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [Xen-devel V2] sedf/build: Fix build when using -fno-inline X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 03/10/12 14:22, Jan Beulich wrote: >>>> Andrew Cooper 10/03/12 2:38 PM >>> >> On 03/10/12 13:35, Andrew Cooper wrote: >>> I found this issue while trying to debug on a separate issue. It >>> certainly affects unstable thru 4.1, and probably earlier, so should be >>> take for backport. >>> >> Apologies - try this patch which has less Unicode in the commit message. > I certainly agree to the change for -unstable, but what's the rationale for > the backport request (given that there's no -fno-inline anywhere in the tree)? > Is this actively causing problems in any non-debugging environment? > > Jan > Not as far as I am aware. Backporting it will make no difference to the older trees in general, but will prevent people who are debugging older trees from needing to fix the build every time they actually need to invoke -fno-inline. (I have been working on this issue for 4 straight days now, debugging on 4.1 and was quite taken aback when the build broke). I would argue that the benefits (for developers) do outweigh the bascially-0 cost, even if it isn't strictly a functional bugfix. -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 13:28:22 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 13:28:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOzk-0004pf-25; Wed, 03 Oct 2012 13:28:12 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJOzi-0004pZ-UX for xen-devel@lists.xen.org; Wed, 03 Oct 2012 13:28:11 +0000 Received: from [85.158.137.99:36031] by server-8.bemta-3.messagelabs.com id 25/9A-16337-96D3C605; Wed, 03 Oct 2012 13:28:09 +0000 X-Env-Sender: Andrew.Cooper3@citrix.com X-Msg-Ref: server-7.tower-217.messagelabs.com!1349270886!15333792!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzk2MzY=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23995 invoked from network); 3 Oct 2012 13:28:08 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 13:28:08 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="210151961" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 13:28:06 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 09:28:06 -0400 Received: from andrewcoop.uk.xensource.com ([10.80.2.18]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJOzd-0004Zx-Nn; Wed, 03 Oct 2012 14:28:05 +0100 Message-ID: <506C3D65.2080706@citrix.com> Date: Wed, 3 Oct 2012 14:28:05 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Jan Beulich References: <506C3123.5050700@citrix.com> <506C31D0.4060702@citrix.com> <506C4A23020000780008D033@nat28.tlf.novell.com> In-Reply-To: <506C4A23020000780008D033@nat28.tlf.novell.com> X-Enigmail-Version: 1.4.4 Cc: Dario Faggioli , "Keir \(Xen.org\)" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [Xen-devel V2] sedf/build: Fix build when using -fno-inline X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 03/10/12 14:22, Jan Beulich wrote: >>>> Andrew Cooper 10/03/12 2:38 PM >>> >> On 03/10/12 13:35, Andrew Cooper wrote: >>> I found this issue while trying to debug on a separate issue. It >>> certainly affects unstable thru 4.1, and probably earlier, so should be >>> take for backport. >>> >> Apologies - try this patch which has less Unicode in the commit message. > I certainly agree to the change for -unstable, but what's the rationale for > the backport request (given that there's no -fno-inline anywhere in the tree)? > Is this actively causing problems in any non-debugging environment? > > Jan > Not as far as I am aware. Backporting it will make no difference to the older trees in general, but will prevent people who are debugging older trees from needing to fix the build every time they actually need to invoke -fno-inline. (I have been working on this issue for 4 straight days now, debugging on 4.1 and was quite taken aback when the build broke). I would argue that the benefits (for developers) do outweigh the bascially-0 cost, even if it isn't strictly a functional bugfix. -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 13:34:14 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 13:34:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJP5P-00051K-0o; Wed, 03 Oct 2012 13:34:03 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJP5N-00051D-Ce for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 13:34:01 +0000 X-Env-Sender: ketuzsezr@gmail.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1349271233!7763758!1 X-Originating-IP: [209.85.220.45] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14320 invoked from network); 3 Oct 2012 13:33:54 -0000 Received: from mail-pa0-f45.google.com (HELO mail-pa0-f45.google.com) (209.85.220.45) by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 13:33:54 -0000 Received: by padfb10 with SMTP id fb10so6526381pad.32 for ; Wed, 03 Oct 2012 06:33:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=7vS6f4/cAnJfNe63sWlTwkCtvSH1W5mGw/5Vfe88e+E=; b=jTblen1qTsO0Xa4eJ9jcW8m/r1Fn1V1BkXvUGE5u+2zrl+ot27radK5kK6a1kVBo6k eDrND8yuEmQTrRscfd6sSjnzy7P8knSs8CdnyIr8MfzhJMCNGzgxE7JGjx+qNxdEzdLG dY2GmE8GdCQI789car0z4S++nUR0vcN/WVOOOTL9bI+J6fgyQ7E0Z4EfiXlhFD7JJeKD VfjrFdri+GaXIXx26Vh5yDx5z4ehxNxoL5NbTlN8EXCQZDzDSTZZz1feXzJV7OQsUGqM Oti7VifU36107WK1H1SBk7kSVDMI4AhSs8KGa78hcmfZIk27p6h/998KteiyO4kj9aAP 9MWQ== MIME-Version: 1.0 Received: by 10.68.242.231 with SMTP id wt7mr12896230pbc.99.1349271232502; Wed, 03 Oct 2012 06:33:52 -0700 (PDT) Received: by 10.66.193.9 with HTTP; Wed, 3 Oct 2012 06:33:52 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Oct 2012 09:33:52 -0400 X-Google-Sender-Auth: 8Wt-GzrBrRac3O3bo5ZDGZPOjLo Message-ID: From: Konrad Rzeszutek Wilk To: Valtteri Kiviniemi Cc: chris , Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.2.0, VNC connection to Windows domU causes black screen on VNC X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, Oct 3, 2012 at 9:22 AM, Valtteri Kiviniemi wrote: > Hi, > > Tested with realvnc and tightvnc. Realvnc just closes itself when the > resolution changes and tightvnc just stays open with the black screen. > Lets first see if this is a problem with Windows 2008 expecting certain registers in the VGA emulation and falling flat on its face. If you launch (with the same guest config - but obviously replace the ISO), with an Fedora or Ubuntu LiveCD - does it boot? Do you see the VNC screen changing resolution and all that? > - Valtteri > > 2012/10/3 chris >> >> What vnc client I've seen this on os x >> >> On Oct 3, 2012 9:08 AM, "Valtteri Kiviniemi" >> wrote: >>> >>> Hi, >>> >>> I am trying to get Windows Server 2008 R2 HVM domU working in Xen 4.2.0. >>> The domU will start and I can see the boot output to the point when the >>> .iso-image starts loading and I get the "Windows is loading files" loading >>> bar in VNC. After the Windows installer has finished loading the necessary >>> files and starts the installer the resolution will change on the VNC screen >>> and it goes black. However despite that, I think that the Windows installer >>> is still starting fine and it probably is responding to keyboard input, I >>> just cant see anything but black. Qemu-dm log file does not contain any >>> error messages. I'm using the same config file on different server and it is >>> working there, and when comparing the qemu-dm log files on this server and >>> the other server where the windows is working they are pretty much >>> consistent. >>> >>> I have tried playing with different settings on domU config, but nothing >>> makes any difference, the outcome is always the same. Installer starts, >>> resolution changes and then only black. I'am using rather new hardware, CPU >>> is the new Intel Ivy-Bridge Core i7-3770 with integrated GPU and motherboard >>> is Intel DQ77MK with latest bios installed. dom0 kernel is 3.6.0 64bit, >>> hypervisor is 64bit and Windows is 64bit. The same kernel config and domU >>> config is working on my older server which is running mid 2008 CPU Intel >>> Q9950 and motherboard Intel DQ45CB, so I would suspect that this might be >>> some kind of hardware incompatibility problem? >>> >>> Any ideas of how to debug this problem? I have enabled all the debuggint >>> options for Xen and dom0 kernel but I'm not getting any error messages. It >>> seems that the domU is working as intented but only graphics are missing. >>> >>> - Valtteri >>> >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xen.org >>> http://lists.xen.org/xen-devel >>> > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 13:34:14 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 13:34:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJP5P-00051K-0o; Wed, 03 Oct 2012 13:34:03 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJP5N-00051D-Ce for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 13:34:01 +0000 X-Env-Sender: ketuzsezr@gmail.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1349271233!7763758!1 X-Originating-IP: [209.85.220.45] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14320 invoked from network); 3 Oct 2012 13:33:54 -0000 Received: from mail-pa0-f45.google.com (HELO mail-pa0-f45.google.com) (209.85.220.45) by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 13:33:54 -0000 Received: by padfb10 with SMTP id fb10so6526381pad.32 for ; Wed, 03 Oct 2012 06:33:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=7vS6f4/cAnJfNe63sWlTwkCtvSH1W5mGw/5Vfe88e+E=; b=jTblen1qTsO0Xa4eJ9jcW8m/r1Fn1V1BkXvUGE5u+2zrl+ot27radK5kK6a1kVBo6k eDrND8yuEmQTrRscfd6sSjnzy7P8knSs8CdnyIr8MfzhJMCNGzgxE7JGjx+qNxdEzdLG dY2GmE8GdCQI789car0z4S++nUR0vcN/WVOOOTL9bI+J6fgyQ7E0Z4EfiXlhFD7JJeKD VfjrFdri+GaXIXx26Vh5yDx5z4ehxNxoL5NbTlN8EXCQZDzDSTZZz1feXzJV7OQsUGqM Oti7VifU36107WK1H1SBk7kSVDMI4AhSs8KGa78hcmfZIk27p6h/998KteiyO4kj9aAP 9MWQ== MIME-Version: 1.0 Received: by 10.68.242.231 with SMTP id wt7mr12896230pbc.99.1349271232502; Wed, 03 Oct 2012 06:33:52 -0700 (PDT) Received: by 10.66.193.9 with HTTP; Wed, 3 Oct 2012 06:33:52 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Oct 2012 09:33:52 -0400 X-Google-Sender-Auth: 8Wt-GzrBrRac3O3bo5ZDGZPOjLo Message-ID: From: Konrad Rzeszutek Wilk To: Valtteri Kiviniemi Cc: chris , Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.2.0, VNC connection to Windows domU causes black screen on VNC X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, Oct 3, 2012 at 9:22 AM, Valtteri Kiviniemi wrote: > Hi, > > Tested with realvnc and tightvnc. Realvnc just closes itself when the > resolution changes and tightvnc just stays open with the black screen. > Lets first see if this is a problem with Windows 2008 expecting certain registers in the VGA emulation and falling flat on its face. If you launch (with the same guest config - but obviously replace the ISO), with an Fedora or Ubuntu LiveCD - does it boot? Do you see the VNC screen changing resolution and all that? > - Valtteri > > 2012/10/3 chris >> >> What vnc client I've seen this on os x >> >> On Oct 3, 2012 9:08 AM, "Valtteri Kiviniemi" >> wrote: >>> >>> Hi, >>> >>> I am trying to get Windows Server 2008 R2 HVM domU working in Xen 4.2.0. >>> The domU will start and I can see the boot output to the point when the >>> .iso-image starts loading and I get the "Windows is loading files" loading >>> bar in VNC. After the Windows installer has finished loading the necessary >>> files and starts the installer the resolution will change on the VNC screen >>> and it goes black. However despite that, I think that the Windows installer >>> is still starting fine and it probably is responding to keyboard input, I >>> just cant see anything but black. Qemu-dm log file does not contain any >>> error messages. I'm using the same config file on different server and it is >>> working there, and when comparing the qemu-dm log files on this server and >>> the other server where the windows is working they are pretty much >>> consistent. >>> >>> I have tried playing with different settings on domU config, but nothing >>> makes any difference, the outcome is always the same. Installer starts, >>> resolution changes and then only black. I'am using rather new hardware, CPU >>> is the new Intel Ivy-Bridge Core i7-3770 with integrated GPU and motherboard >>> is Intel DQ77MK with latest bios installed. dom0 kernel is 3.6.0 64bit, >>> hypervisor is 64bit and Windows is 64bit. The same kernel config and domU >>> config is working on my older server which is running mid 2008 CPU Intel >>> Q9950 and motherboard Intel DQ45CB, so I would suspect that this might be >>> some kind of hardware incompatibility problem? >>> >>> Any ideas of how to debug this problem? I have enabled all the debuggint >>> options for Xen and dom0 kernel but I'm not getting any error messages. It >>> seems that the domU is working as intented but only graphics are missing. >>> >>> - Valtteri >>> >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xen.org >>> http://lists.xen.org/xen-devel >>> > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 13:35:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 13:35:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJP6m-00059n-GF; Wed, 03 Oct 2012 13:35:28 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJP6l-00059P-Jv for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 13:35:27 +0000 Received: from [85.158.143.99:32730] by server-1.bemta-4.messagelabs.com id 43/C7-05684-E1F3C605; Wed, 03 Oct 2012 13:35:26 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-11.tower-216.messagelabs.com!1349271325!25185286!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6862 invoked from network); 3 Oct 2012 13:35:25 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 13:35:25 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="14916454" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 13:35:25 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 14:35:25 +0100 Message-ID: <1349271323.650.148.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Wed, 3 Oct 2012 14:35:23 +0100 In-Reply-To: <1345633688-31684-4-git-send-email-stefano.stabellini@eu.citrix.com> References: <1345633688-31684-4-git-send-email-stefano.stabellini@eu.citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , "Tim \(Xen.org\)" Subject: Re: [Xen-devel] [PATCH v4 4/6] xen: introduce XEN_GUEST_HANDLE_PARAM X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-08-22 at 12:08 +0100, Stefano Stabellini wrote: > +#define set_xen_guest_handle_raw(hnd, val) \ > + do { \ > + typeof(&(hnd)) t = &(hnd); \ > + _t->q = 0; \ > + _t->p = val; \ You have a mix of t and _t here... Since this macro is used in the tools it would be useful to avoid any potentially clashing names (e.g. so -Wshadow doesn't moan). _sxghr_tmp? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 13:35:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 13:35:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJP6m-00059n-GF; Wed, 03 Oct 2012 13:35:28 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJP6l-00059P-Jv for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 13:35:27 +0000 Received: from [85.158.143.99:32730] by server-1.bemta-4.messagelabs.com id 43/C7-05684-E1F3C605; Wed, 03 Oct 2012 13:35:26 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-11.tower-216.messagelabs.com!1349271325!25185286!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6862 invoked from network); 3 Oct 2012 13:35:25 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 13:35:25 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="14916454" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 13:35:25 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 14:35:25 +0100 Message-ID: <1349271323.650.148.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Wed, 3 Oct 2012 14:35:23 +0100 In-Reply-To: <1345633688-31684-4-git-send-email-stefano.stabellini@eu.citrix.com> References: <1345633688-31684-4-git-send-email-stefano.stabellini@eu.citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , "Tim \(Xen.org\)" Subject: Re: [Xen-devel] [PATCH v4 4/6] xen: introduce XEN_GUEST_HANDLE_PARAM X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-08-22 at 12:08 +0100, Stefano Stabellini wrote: > +#define set_xen_guest_handle_raw(hnd, val) \ > + do { \ > + typeof(&(hnd)) t = &(hnd); \ > + _t->q = 0; \ > + _t->p = val; \ You have a mix of t and _t here... Since this macro is used in the tools it would be useful to avoid any potentially clashing names (e.g. so -Wshadow doesn't moan). _sxghr_tmp? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 13:39:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 13:39:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPAZ-0005QL-54; Wed, 03 Oct 2012 13:39:23 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPAX-0005QB-Kp for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 13:39:21 +0000 Received: from [85.158.143.99:5045] by server-1.bemta-4.messagelabs.com id EC/5E-05684-9004C605; Wed, 03 Oct 2012 13:39:21 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1349271560!23101827!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16225 invoked from network); 3 Oct 2012 13:39:20 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 13:39:20 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="14916519" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 13:38:53 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 14:38:53 +0100 Date: Wed, 3 Oct 2012 14:37:53 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Konrad Rzeszutek Wilk Message-ID: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, Stefano Stabellini Subject: [Xen-devel] [PATCH] xen: point xen_start_info to a dummy struct for PV on HVM guests X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org PV on HVM guests don't have a start_info page mapped by Xen, so xen_start_info is just NULL for them. That is problem because other parts of the code expect xen_start_info to point to something valid, for example xen_initial_domain() is defined as follow: #define xen_initial_domain() (xen_domain() && \ xen_start_info->flags & SIF_INITDOMAIN) Allocate a dummy start_info struct and point xen_start_info to it, as we do on ARM. This is not going to change things for PV guests because xen_start_info is set by arch/x86/xen/xen-head.S:startup_xen. Signed-off-by: Stefano Stabellini diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index bf788d3..5f242cb 100644 --- a/arch/x86/xen/enlighten.c +++ b/arch/x86/xen/enlighten.c @@ -96,7 +96,8 @@ EXPORT_SYMBOL(machine_to_phys_mapping); unsigned long machine_to_phys_nr; EXPORT_SYMBOL(machine_to_phys_nr); -struct start_info *xen_start_info; +static struct start_info _xen_start_info; +struct start_info *xen_start_info = &_xen_start_info; EXPORT_SYMBOL_GPL(xen_start_info); struct shared_info xen_dummy_shared_info; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 13:39:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 13:39:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPAZ-0005QL-54; Wed, 03 Oct 2012 13:39:23 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPAX-0005QB-Kp for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 13:39:21 +0000 Received: from [85.158.143.99:5045] by server-1.bemta-4.messagelabs.com id EC/5E-05684-9004C605; Wed, 03 Oct 2012 13:39:21 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1349271560!23101827!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16225 invoked from network); 3 Oct 2012 13:39:20 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 13:39:20 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="14916519" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 13:38:53 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 14:38:53 +0100 Date: Wed, 3 Oct 2012 14:37:53 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Konrad Rzeszutek Wilk Message-ID: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, Stefano Stabellini Subject: [Xen-devel] [PATCH] xen: point xen_start_info to a dummy struct for PV on HVM guests X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org PV on HVM guests don't have a start_info page mapped by Xen, so xen_start_info is just NULL for them. That is problem because other parts of the code expect xen_start_info to point to something valid, for example xen_initial_domain() is defined as follow: #define xen_initial_domain() (xen_domain() && \ xen_start_info->flags & SIF_INITDOMAIN) Allocate a dummy start_info struct and point xen_start_info to it, as we do on ARM. This is not going to change things for PV guests because xen_start_info is set by arch/x86/xen/xen-head.S:startup_xen. Signed-off-by: Stefano Stabellini diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index bf788d3..5f242cb 100644 --- a/arch/x86/xen/enlighten.c +++ b/arch/x86/xen/enlighten.c @@ -96,7 +96,8 @@ EXPORT_SYMBOL(machine_to_phys_mapping); unsigned long machine_to_phys_nr; EXPORT_SYMBOL(machine_to_phys_nr); -struct start_info *xen_start_info; +static struct start_info _xen_start_info; +struct start_info *xen_start_info = &_xen_start_info; EXPORT_SYMBOL_GPL(xen_start_info); struct shared_info xen_dummy_shared_info; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 13:41:36 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 13:41:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPCV-0005YL-Qv; Wed, 03 Oct 2012 13:41:23 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPCT-0005Y6-I2 for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 13:41:21 +0000 Received: from [85.158.137.99:50865] by server-12.bemta-3.messagelabs.com id C3/2E-23730-0804C605; Wed, 03 Oct 2012 13:41:20 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-14.tower-217.messagelabs.com!1349271678!20092773!1 X-Originating-IP: [209.85.161.173] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24861 invoked from network); 3 Oct 2012 13:41:19 -0000 Received: from mail-gg0-f173.google.com (HELO mail-gg0-f173.google.com) (209.85.161.173) by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 13:41:19 -0000 Received: by ggcs5 with SMTP id s5so644456ggc.32 for ; Wed, 03 Oct 2012 06:41:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LlHt8h4KSMEUhh/8gCbCDH/tqkCHNCSeBSZltSstV6c=; b=1IkrMG/ryC3vOKeU8cSEI+jQkrfPwJHz8BAiJtuAwOBFoBaZpALARrrT58GOang8W/ 8xk9H/17yEUO7GbX1EVRV//vD1vLbPg5e8Fxx7g6+WoQAAVM1DFq6hk0qt+pZ0nUWIlL UEyb0ChFV82MwL8hUE7f4phqyfJbjSs0sr5OCwkFGfhnOD2FZMla1fX6tEuQNe+y6tFD scZ+Oh1BXdm0/f8HQM2fNjOuz8JlNn3154M6zJX/jbcqcBwbQITmR7Ehe66xgcG6BHsA YR1VkA5ol/glPhdo6DL+KeTKfYK2OtAbDdExdaflvqjEOUYJZ++B79KYoFZQbxGxtzZy QkvA== MIME-Version: 1.0 Received: by 10.236.9.36 with SMTP id 24mr1830228yhs.63.1349271678253; Wed, 03 Oct 2012 06:41:18 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Wed, 3 Oct 2012 06:41:18 -0700 (PDT) In-Reply-To: References: <20121002121932.GL8912@reaktio.net> <20121002144251.GP8912@reaktio.net> <20121003114552.GS8912@reaktio.net> Date: Wed, 3 Oct 2012 16:41:18 +0300 Message-ID: From: Valtteri Kiviniemi To: Konrad Rzeszutek Wilk Cc: Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.0.4, kernel 3.5.0 HVM crash and kernel BUG X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8371304058582249252==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============8371304058582249252== Content-Type: multipart/alternative; boundary=20cf303dd264167cd904cb27cba7 --20cf303dd264167cd904cb27cba7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/10/3 Konrad Rzeszutek Wilk > On Wed, Oct 3, 2012 at 7:45 AM, Pasi K=E4rkk=E4inen wrote: > > On Wed, Oct 03, 2012 at 12:21:47PM +0300, Valtteri Kiviniemi wrote: > >> Hi, > >> > >> I disabled NUMA and upgraded to Xen 4.2.0. Windows domU starts now > fine > >> and I cant anymore reproduce the hotplug problems. VNC output is > still > >> just black screen and it actually crashes the the whole VNC client > when > >> after a few seconds. RealVNC just shuts itself down and tightvnc > crashes. > >> > > > > > > Valtteri: Can you actually paste the names of the .config options you > disabled > > and got the dom0 kernel working without crashes? > > > > Maybe Konrad can comment if the current upstream dom0 kernel is suppose= d > to work > > with NUMA support enabled / compiled in? > > There is a patch to actually disable it since we do not provide any > NUMA information > to the guest. And the dom0 has access to extra information (ACPI, > Northbridge, etc) > so it might think to create a NUMA topology and get it wrong. > > But his dmesg did not have anything obvious related to NUMA, so I am > perplexed that > turning that off would have made such a difference. > > Valterri - if you just pass 'numa=3Doff' on the Linux command line with > the old kernel > (the one that had the NUMA enabled) does that make it the iput issue go > away? > > > You VNC issue .. does it work if you launch PV guests? Or is it only > for HVM guests? > Hi, Well it might be that disabling NUMA did not fix the problem since the crash is sometimes hard to reproduce. Sometimes it will crash everytime and sometimes I have to restart the domU 30 times before it causes that crash. But I have been testing this whole day and I have not been able to reproduce the crash anymore. I also upgraded from Xen 4.0.4 to Xen 4.2.0 so that combined for the NUMA disabling might have also affect, but I did also get the same crash on Xen 4.2.0 previously, so it probably does not affect. At the moment I cannot test enabling the NUMA since now when I got it working (at least it think that it works now) I want to figure out the VNC problem, since the VNC problem is very critical to me. I'm probably ordering another computer with the same hardware later this month and then I can use it as my primary test/dev server and try to test the NUMA again. At the moment I dont have any PV guests that I could test the VNC with. But maybe I could try installing one. I also started a new thread about the VNC problem, so I think that we should continue the VNC discussion on that thread. - Valtteri --20cf303dd264167cd904cb27cba7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/10/3 Konrad Rzeszutek Wilk <konrad= @kernel.org>
On Wed, Oct 3, 2012 at 7:45 AM, Pasi K=E4rkk=E4inen <<= a href=3D"mailto:pasik@iki.fi">pasik@iki.fi> wrote:
> On Wed, Oct 03, 2012 at 12:21:47PM +0300, Valtteri Kiviniemi wrote: >> =A0 =A0Hi,
>>
>> =A0 =A0I disabled NUMA and upgraded to Xen 4.2.0. Windows domU sta= rts now fine
>> =A0 =A0and I cant anymore reproduce the hotplug problems. VNC outp= ut is still
>> =A0 =A0just black screen and it actually crashes the the whole VNC= client when
>> =A0 =A0after a few seconds. RealVNC just shuts itself down and tig= htvnc crashes.
>>
>
>
> Valtteri: Can you actually paste the names of the .config options you = disabled
> and got the dom0 kernel working without crashes?
>
> Maybe Konrad can comment if the current upstream dom0 kernel is suppos= ed to work
> with NUMA support enabled / compiled in?

There is a patch to actually disable it since we do not provide any NUMA information
to the guest. And the dom0 has access to extra information (ACPI,
Northbridge, etc)
so it might think to create a NUMA topology and get it wrong.

But his dmesg did not have anything obvious related to NUMA, so =A0I am
perplexed that
turning that off would have made such a difference.

Valterri - if you just pass 'numa=3Doff' on the Linux command line = with
the old kernel
(the one that had the NUMA enabled) does that make it the iput issue go awa= y?


You VNC issue .. does it work if you launch PV guests? Or is it only
for HVM guests?

Hi,

Well it might be that disabling NUMA did = not fix the problem since the crash is sometimes hard to reproduce. Sometim= es it will crash everytime and sometimes I have to restart the domU 30 time= s before it causes that crash. But I have been testing this whole day and I= have not been able to reproduce the crash anymore. I also upgraded from Xe= n 4.0.4 to Xen 4.2.0 so that combined for the NUMA disabling might have als= o affect, but I did also get the same crash on Xen 4.2.0 previously, so it = probably does not affect. At the moment I cannot test enabling the NUMA sin= ce now when I got it working (at least it think that it works now) I want t= o figure out the VNC problem, since the VNC problem is very critical to me.= I'm probably ordering another computer with the same hardware later th= is month and then I can use it as my primary test/dev server and try to tes= t the NUMA again.

At the moment I dont have any PV guests that I could test the VNC with.= But maybe I could try installing one. I also started a new thread about th= e VNC problem, so I think that we should continue the VNC discussion on tha= t thread.

- Valtteri






--20cf303dd264167cd904cb27cba7-- --===============8371304058582249252== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8371304058582249252==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 13:41:36 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 13:41:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPCV-0005YL-Qv; Wed, 03 Oct 2012 13:41:23 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPCT-0005Y6-I2 for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 13:41:21 +0000 Received: from [85.158.137.99:50865] by server-12.bemta-3.messagelabs.com id C3/2E-23730-0804C605; Wed, 03 Oct 2012 13:41:20 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-14.tower-217.messagelabs.com!1349271678!20092773!1 X-Originating-IP: [209.85.161.173] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24861 invoked from network); 3 Oct 2012 13:41:19 -0000 Received: from mail-gg0-f173.google.com (HELO mail-gg0-f173.google.com) (209.85.161.173) by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 13:41:19 -0000 Received: by ggcs5 with SMTP id s5so644456ggc.32 for ; Wed, 03 Oct 2012 06:41:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LlHt8h4KSMEUhh/8gCbCDH/tqkCHNCSeBSZltSstV6c=; b=1IkrMG/ryC3vOKeU8cSEI+jQkrfPwJHz8BAiJtuAwOBFoBaZpALARrrT58GOang8W/ 8xk9H/17yEUO7GbX1EVRV//vD1vLbPg5e8Fxx7g6+WoQAAVM1DFq6hk0qt+pZ0nUWIlL UEyb0ChFV82MwL8hUE7f4phqyfJbjSs0sr5OCwkFGfhnOD2FZMla1fX6tEuQNe+y6tFD scZ+Oh1BXdm0/f8HQM2fNjOuz8JlNn3154M6zJX/jbcqcBwbQITmR7Ehe66xgcG6BHsA YR1VkA5ol/glPhdo6DL+KeTKfYK2OtAbDdExdaflvqjEOUYJZ++B79KYoFZQbxGxtzZy QkvA== MIME-Version: 1.0 Received: by 10.236.9.36 with SMTP id 24mr1830228yhs.63.1349271678253; Wed, 03 Oct 2012 06:41:18 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Wed, 3 Oct 2012 06:41:18 -0700 (PDT) In-Reply-To: References: <20121002121932.GL8912@reaktio.net> <20121002144251.GP8912@reaktio.net> <20121003114552.GS8912@reaktio.net> Date: Wed, 3 Oct 2012 16:41:18 +0300 Message-ID: From: Valtteri Kiviniemi To: Konrad Rzeszutek Wilk Cc: Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.0.4, kernel 3.5.0 HVM crash and kernel BUG X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8371304058582249252==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============8371304058582249252== Content-Type: multipart/alternative; boundary=20cf303dd264167cd904cb27cba7 --20cf303dd264167cd904cb27cba7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/10/3 Konrad Rzeszutek Wilk > On Wed, Oct 3, 2012 at 7:45 AM, Pasi K=E4rkk=E4inen wrote: > > On Wed, Oct 03, 2012 at 12:21:47PM +0300, Valtteri Kiviniemi wrote: > >> Hi, > >> > >> I disabled NUMA and upgraded to Xen 4.2.0. Windows domU starts now > fine > >> and I cant anymore reproduce the hotplug problems. VNC output is > still > >> just black screen and it actually crashes the the whole VNC client > when > >> after a few seconds. RealVNC just shuts itself down and tightvnc > crashes. > >> > > > > > > Valtteri: Can you actually paste the names of the .config options you > disabled > > and got the dom0 kernel working without crashes? > > > > Maybe Konrad can comment if the current upstream dom0 kernel is suppose= d > to work > > with NUMA support enabled / compiled in? > > There is a patch to actually disable it since we do not provide any > NUMA information > to the guest. And the dom0 has access to extra information (ACPI, > Northbridge, etc) > so it might think to create a NUMA topology and get it wrong. > > But his dmesg did not have anything obvious related to NUMA, so I am > perplexed that > turning that off would have made such a difference. > > Valterri - if you just pass 'numa=3Doff' on the Linux command line with > the old kernel > (the one that had the NUMA enabled) does that make it the iput issue go > away? > > > You VNC issue .. does it work if you launch PV guests? Or is it only > for HVM guests? > Hi, Well it might be that disabling NUMA did not fix the problem since the crash is sometimes hard to reproduce. Sometimes it will crash everytime and sometimes I have to restart the domU 30 times before it causes that crash. But I have been testing this whole day and I have not been able to reproduce the crash anymore. I also upgraded from Xen 4.0.4 to Xen 4.2.0 so that combined for the NUMA disabling might have also affect, but I did also get the same crash on Xen 4.2.0 previously, so it probably does not affect. At the moment I cannot test enabling the NUMA since now when I got it working (at least it think that it works now) I want to figure out the VNC problem, since the VNC problem is very critical to me. I'm probably ordering another computer with the same hardware later this month and then I can use it as my primary test/dev server and try to test the NUMA again. At the moment I dont have any PV guests that I could test the VNC with. But maybe I could try installing one. I also started a new thread about the VNC problem, so I think that we should continue the VNC discussion on that thread. - Valtteri --20cf303dd264167cd904cb27cba7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/10/3 Konrad Rzeszutek Wilk <konrad= @kernel.org>
On Wed, Oct 3, 2012 at 7:45 AM, Pasi K=E4rkk=E4inen <<= a href=3D"mailto:pasik@iki.fi">pasik@iki.fi> wrote:
> On Wed, Oct 03, 2012 at 12:21:47PM +0300, Valtteri Kiviniemi wrote: >> =A0 =A0Hi,
>>
>> =A0 =A0I disabled NUMA and upgraded to Xen 4.2.0. Windows domU sta= rts now fine
>> =A0 =A0and I cant anymore reproduce the hotplug problems. VNC outp= ut is still
>> =A0 =A0just black screen and it actually crashes the the whole VNC= client when
>> =A0 =A0after a few seconds. RealVNC just shuts itself down and tig= htvnc crashes.
>>
>
>
> Valtteri: Can you actually paste the names of the .config options you = disabled
> and got the dom0 kernel working without crashes?
>
> Maybe Konrad can comment if the current upstream dom0 kernel is suppos= ed to work
> with NUMA support enabled / compiled in?

There is a patch to actually disable it since we do not provide any NUMA information
to the guest. And the dom0 has access to extra information (ACPI,
Northbridge, etc)
so it might think to create a NUMA topology and get it wrong.

But his dmesg did not have anything obvious related to NUMA, so =A0I am
perplexed that
turning that off would have made such a difference.

Valterri - if you just pass 'numa=3Doff' on the Linux command line = with
the old kernel
(the one that had the NUMA enabled) does that make it the iput issue go awa= y?


You VNC issue .. does it work if you launch PV guests? Or is it only
for HVM guests?

Hi,

Well it might be that disabling NUMA did = not fix the problem since the crash is sometimes hard to reproduce. Sometim= es it will crash everytime and sometimes I have to restart the domU 30 time= s before it causes that crash. But I have been testing this whole day and I= have not been able to reproduce the crash anymore. I also upgraded from Xe= n 4.0.4 to Xen 4.2.0 so that combined for the NUMA disabling might have als= o affect, but I did also get the same crash on Xen 4.2.0 previously, so it = probably does not affect. At the moment I cannot test enabling the NUMA sin= ce now when I got it working (at least it think that it works now) I want t= o figure out the VNC problem, since the VNC problem is very critical to me.= I'm probably ordering another computer with the same hardware later th= is month and then I can use it as my primary test/dev server and try to tes= t the NUMA again.

At the moment I dont have any PV guests that I could test the VNC with.= But maybe I could try installing one. I also started a new thread about th= e VNC problem, so I think that we should continue the VNC discussion on tha= t thread.

- Valtteri






--20cf303dd264167cd904cb27cba7-- --===============8371304058582249252== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8371304058582249252==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 13:41:42 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 13:41:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPCh-0005ZZ-8E; Wed, 03 Oct 2012 13:41:35 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPCf-0005Yo-Gm for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 13:41:33 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1349271681!3519447!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc5MDM1NA==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9407 invoked from network); 3 Oct 2012 13:41:23 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Oct 2012 13:41:23 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q93DfH6C025302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Oct 2012 13:41:18 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q93DfGXr010615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Oct 2012 13:41:17 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q93DfGYg008095; Wed, 3 Oct 2012 08:41:16 -0500 Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 03 Oct 2012 06:41:16 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 6D4F64032D; Wed, 3 Oct 2012 09:29:52 -0400 (EDT) Date: Wed, 3 Oct 2012 09:29:52 -0400 From: Konrad Rzeszutek Wilk To: "Liu, Jinsong" , Daniel Kiper Message-ID: <20121003132952.GA31173@phenom.dumpdata.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "xen-devel@lists.xensource.com" , "jeremy.fitzhardinge@citrix.com" , "Jiang, Yunhong" Subject: Re: [Xen-devel] [PATCH 06/10] Xen: Add memory hotadd to pvops dom0 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, Dec 22, 2011 at 10:06:56AM +0000, Liu, Jinsong wrote: > >From a5d21e2a01049eef6aa64406e71f6574e7a371c1 Mon Sep 17 00:00:00 2001 > From: Liu Jinsong > Date: Sun, 11 Dec 2011 21:51:28 +0800 > Subject: [PATCH 06/10] Xen: Add memory hotadd to pvops dom0 > > This patch rebased from Jeremy's pvops commit > fe3cb1ebf78399fd5176ff6aa1c9ab498f2d8bd7 > > When memory hotadd event happen, a Xen hook will be called, to notify > hypervisor of the new added memory. I recall posting a review asking whether it would make sense to use the generic memory hotplug mechanism but never got any feedback. Is there no interest in this anymore? > > Because xen hypervisor will use the new memory to setup frametable/m2p > table, so dom0 will always return success to acpi bios, and notify xen > hypervisor later. > > It add a hook in driver/acpi/acpi_memhotplug.c, but that change is > quite small, not sure if it is acceptable. Other method is to provide > a xen specific acpi_memory_device_driver, but I'm not sure if it worth > to add so much changes, to simply avoid two hooks. > > Signed-off-by: Liu, Jinsong > Signed-off-by: Jiang, Yunhong > Signed-off-by: Jeremy Fitzhardinge > --- > drivers/acpi/acpi_memhotplug.c | 4 + > drivers/xen/Makefile | 1 + > drivers/xen/xen_acpi_memhotplug.c | 209 +++++++++++++++++++++++++++++++++++++ > include/xen/acpi.h | 5 + > include/xen/interface/platform.h | 9 ++ > 5 files changed, 228 insertions(+), 0 deletions(-) > create mode 100644 drivers/xen/xen_acpi_memhotplug.c > > diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c > index e28e64d..2f2169e 100644 > --- a/drivers/acpi/acpi_memhotplug.c > +++ b/drivers/acpi/acpi_memhotplug.c > @@ -32,6 +32,7 @@ > #include > #include > #include > +#include > > #define ACPI_MEMORY_DEVICE_CLASS "memory" > #define ACPI_MEMORY_DEVICE_HID "PNP0C80" > @@ -214,6 +215,9 @@ static int acpi_memory_enable_device(struct acpi_memory_device *mem_device) > return result; > } > > + if (xen_initial_domain()) > + return xen_hotadd_memory(mem_device); > + > node = acpi_get_node(mem_device->device->handle); > /* > * Tell the VM there is more memory here... > diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile > index aedaf48..7dc3c0b 100644 > --- a/drivers/xen/Makefile > +++ b/drivers/xen/Makefile > @@ -20,6 +20,7 @@ obj-$(CONFIG_XEN_TMEM) += tmem.o > obj-$(CONFIG_SWIOTLB_XEN) += swiotlb-xen.o > obj-$(CONFIG_XEN_DOM0) += pci.o acpi.o > obj-$(CONFIG_XEN_PCIDEV_BACKEND) += xen-pciback/ > +obj-$(CONFIG_ACPI_HOTPLUG_MEMORY) += xen_acpi_memhotplug.o > ifdef CONFIG_ACPI_PROCESSOR_XEN > obj-$(CONFIG_ACPI_PROCESSOR) += acpi_processor.o > endif > diff --git a/drivers/xen/xen_acpi_memhotplug.c b/drivers/xen/xen_acpi_memhotplug.c > new file mode 100644 > index 0000000..0c4af99 > --- /dev/null > +++ b/drivers/xen/xen_acpi_memhotplug.c > @@ -0,0 +1,209 @@ > +/* > + * xen_acpi_memhotplug.c - interface to notify Xen on memory device hotadd > + * > + * Copyright (C) 2008, Intel corporation > + * > + * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; either version 2 of the License, or (at > + * your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, but > + * WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License along > + * with this program; if not, write to the Free Software Foundation, Inc., > + * 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. > + * > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +struct xen_hotmem_entry { > + struct list_head hotmem_list; > + uint64_t start; > + uint64_t end; > + uint32_t flags; > + uint32_t pxm; > +}; > + > +struct xen_hotmem_list { > + struct list_head list; > + int entry_nr; > +} xen_hotmem; > + > +DEFINE_SPINLOCK(xen_hotmem_lock); > + > +static int xen_hyper_addmem(struct xen_hotmem_entry *entry) > +{ > + int ret; > + > + xen_platform_op_t op = { > + .cmd = XENPF_mem_hotadd, > + .interface_version = XENPF_INTERFACE_VERSION, > + }; > + op.u.mem_add.spfn = entry->start >> PAGE_SHIFT; > + op.u.mem_add.epfn = entry->end >> PAGE_SHIFT; > + op.u.mem_add.flags = entry->flags; > + op.u.mem_add.pxm = entry->pxm; > + > + ret = HYPERVISOR_dom0_op(&op); > + return ret; > +} > + > +static int add_hotmem_entry(int pxm, uint64_t start, > + uint64_t length, uint32_t flags) > +{ > + struct xen_hotmem_entry *entry; > + > + if (pxm < 0 || !length) > + return -EINVAL; > + > + entry = kzalloc(sizeof(struct xen_hotmem_entry), GFP_ATOMIC); > + if (!entry) > + return -ENOMEM; > + > + INIT_LIST_HEAD(&entry->hotmem_list); > + entry->start = start; > + entry->end = start + length; > + entry->flags = flags; > + entry->pxm = pxm; > + > + spin_lock(&xen_hotmem_lock); > + > + list_add_tail(&entry->hotmem_list, &xen_hotmem.list); > + xen_hotmem.entry_nr++; > + > + spin_unlock(&xen_hotmem_lock); > + > + return 0; > +} > + > +static int free_hotmem_entry(struct xen_hotmem_entry *entry) > +{ > + list_del(&entry->hotmem_list); > + kfree(entry); > + > + return 0; > +} > + > +static void xen_hotadd_mem_dpc(struct work_struct *work) > +{ > + struct list_head *elem, *tmp; > + struct xen_hotmem_entry *entry; > + unsigned long flags; > + int ret; > + > + spin_lock_irqsave(&xen_hotmem_lock, flags); > + list_for_each_safe(elem, tmp, &xen_hotmem.list) { > + entry = list_entry(elem, struct xen_hotmem_entry, hotmem_list); > + ret = xen_hyper_addmem(entry); > + if (ret) > + printk(KERN_WARNING "xen addmem failed with %x\n", ret); > + free_hotmem_entry(entry); > + xen_hotmem.entry_nr--; > + } > + spin_unlock_irqrestore(&xen_hotmem_lock, flags); > +} > + > +static DECLARE_WORK(xen_hotadd_mem_work, xen_hotadd_mem_dpc); > + > +static int xen_acpi_get_pxm(acpi_handle h) > +{ > + unsigned long long pxm; > + acpi_status status; > + acpi_handle handle; > + acpi_handle phandle = h; > + > + do { > + handle = phandle; > + status = acpi_evaluate_integer(handle, "_PXM", NULL, &pxm); > + if (ACPI_SUCCESS(status)) > + return pxm; > + status = acpi_get_parent(handle, &phandle); > + } while (ACPI_SUCCESS(status)); > + > + return -1; > +} > + > +int xen_hotadd_memory(struct acpi_memory_device *mem_device) > +{ > + int pxm, result; > + int num_enabled = 0; > + struct acpi_memory_info *info; > + > + if (!mem_device) > + return -EINVAL; > + > + pxm = xen_acpi_get_pxm(mem_device->device->handle); > + > + if (pxm < 0) > + return -EINVAL; > + > + /* > + * Always return success to ACPI driver, and notify hypervisor later > + * because hypervisor will utilize the memory in memory hotadd hypercall > + */ > + list_for_each_entry(info, &mem_device->res_list, list) { > + if (info->enabled) { /* just sanity check...*/ > + num_enabled++; > + continue; > + } > + /* > + * If the memory block size is zero, please ignore it. > + * Don't try to do the following memory hotplug flowchart. > + */ > + if (!info->length) > + continue; > + > + result = add_hotmem_entry(pxm, info->start_addr, > + info->length, 0); > + if (result) > + continue; > + info->enabled = 1; > + num_enabled++; > + } > + > + if (!num_enabled) > + return -EINVAL; > + > + schedule_work(&xen_hotadd_mem_work); > + > + return 0; > +} > +EXPORT_SYMBOL(xen_hotadd_memory); > + > +static int xen_hotadd_mem_init(void) > +{ > + if (!xen_initial_domain()) > + return -ENODEV; > + > + INIT_LIST_HEAD(&xen_hotmem.list); > + xen_hotmem.entry_nr = 0; > + > + return 0; > +} > + > +static void xen_hotadd_mem_exit(void) > +{ > + flush_scheduled_work(); > +} > + > +module_init(xen_hotadd_mem_init); > +module_exit(xen_hotadd_mem_exit); > +MODULE_LICENSE("GPL"); > diff --git a/include/xen/acpi.h b/include/xen/acpi.h > index 7aa282d..8b3462e 100644 > --- a/include/xen/acpi.h > +++ b/include/xen/acpi.h > @@ -107,6 +107,11 @@ static inline int xen_acpi_processor_get_performance(struct acpi_processor *pr) > } > #endif > > +#if defined(CONFIG_ACPI_HOTPLUG_MEMORY) || \ > +defined(CONFIG_ACPI_HOTPLUG_MEMORY_MODULE) > +int xen_hotadd_memory(struct acpi_memory_device *mem_device); > +#endif > + > #if defined(CONFIG_ACPI_PROCESSOR_XEN) || \ > defined(CONFIG_ACPI_PROCESSOR_XEN_MODULE) > > diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h > index 9fd6b07..0787c68 100644 > --- a/include/xen/interface/platform.h > +++ b/include/xen/interface/platform.h > @@ -329,6 +329,14 @@ struct xenpf_cpu_hotadd { > uint32_t pxm; > }; > > +#define XENPF_mem_hotadd 59 > +struct xenpf_mem_hotadd { > + uint64_t spfn; > + uint64_t epfn; > + uint32_t pxm; > + uint32_t flags; > +}; > + > struct xen_platform_op { > uint32_t cmd; > uint32_t interface_version; /* XENPF_INTERFACE_VERSION */ > @@ -347,6 +355,7 @@ struct xen_platform_op { > struct xenpf_pcpuinfo pcpu_info; > struct xenpf_cpu_ol cpu_ol; > struct xenpf_cpu_hotadd cpu_add; > + struct xenpf_mem_hotadd mem_add; > uint8_t pad[128]; > } u; > }; > -- > 1.6.5.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 13:41:42 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 13:41:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPCh-0005ZZ-8E; Wed, 03 Oct 2012 13:41:35 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPCf-0005Yo-Gm for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 13:41:33 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1349271681!3519447!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc5MDM1NA==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9407 invoked from network); 3 Oct 2012 13:41:23 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Oct 2012 13:41:23 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q93DfH6C025302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Oct 2012 13:41:18 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q93DfGXr010615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Oct 2012 13:41:17 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q93DfGYg008095; Wed, 3 Oct 2012 08:41:16 -0500 Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 03 Oct 2012 06:41:16 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 6D4F64032D; Wed, 3 Oct 2012 09:29:52 -0400 (EDT) Date: Wed, 3 Oct 2012 09:29:52 -0400 From: Konrad Rzeszutek Wilk To: "Liu, Jinsong" , Daniel Kiper Message-ID: <20121003132952.GA31173@phenom.dumpdata.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "xen-devel@lists.xensource.com" , "jeremy.fitzhardinge@citrix.com" , "Jiang, Yunhong" Subject: Re: [Xen-devel] [PATCH 06/10] Xen: Add memory hotadd to pvops dom0 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, Dec 22, 2011 at 10:06:56AM +0000, Liu, Jinsong wrote: > >From a5d21e2a01049eef6aa64406e71f6574e7a371c1 Mon Sep 17 00:00:00 2001 > From: Liu Jinsong > Date: Sun, 11 Dec 2011 21:51:28 +0800 > Subject: [PATCH 06/10] Xen: Add memory hotadd to pvops dom0 > > This patch rebased from Jeremy's pvops commit > fe3cb1ebf78399fd5176ff6aa1c9ab498f2d8bd7 > > When memory hotadd event happen, a Xen hook will be called, to notify > hypervisor of the new added memory. I recall posting a review asking whether it would make sense to use the generic memory hotplug mechanism but never got any feedback. Is there no interest in this anymore? > > Because xen hypervisor will use the new memory to setup frametable/m2p > table, so dom0 will always return success to acpi bios, and notify xen > hypervisor later. > > It add a hook in driver/acpi/acpi_memhotplug.c, but that change is > quite small, not sure if it is acceptable. Other method is to provide > a xen specific acpi_memory_device_driver, but I'm not sure if it worth > to add so much changes, to simply avoid two hooks. > > Signed-off-by: Liu, Jinsong > Signed-off-by: Jiang, Yunhong > Signed-off-by: Jeremy Fitzhardinge > --- > drivers/acpi/acpi_memhotplug.c | 4 + > drivers/xen/Makefile | 1 + > drivers/xen/xen_acpi_memhotplug.c | 209 +++++++++++++++++++++++++++++++++++++ > include/xen/acpi.h | 5 + > include/xen/interface/platform.h | 9 ++ > 5 files changed, 228 insertions(+), 0 deletions(-) > create mode 100644 drivers/xen/xen_acpi_memhotplug.c > > diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c > index e28e64d..2f2169e 100644 > --- a/drivers/acpi/acpi_memhotplug.c > +++ b/drivers/acpi/acpi_memhotplug.c > @@ -32,6 +32,7 @@ > #include > #include > #include > +#include > > #define ACPI_MEMORY_DEVICE_CLASS "memory" > #define ACPI_MEMORY_DEVICE_HID "PNP0C80" > @@ -214,6 +215,9 @@ static int acpi_memory_enable_device(struct acpi_memory_device *mem_device) > return result; > } > > + if (xen_initial_domain()) > + return xen_hotadd_memory(mem_device); > + > node = acpi_get_node(mem_device->device->handle); > /* > * Tell the VM there is more memory here... > diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile > index aedaf48..7dc3c0b 100644 > --- a/drivers/xen/Makefile > +++ b/drivers/xen/Makefile > @@ -20,6 +20,7 @@ obj-$(CONFIG_XEN_TMEM) += tmem.o > obj-$(CONFIG_SWIOTLB_XEN) += swiotlb-xen.o > obj-$(CONFIG_XEN_DOM0) += pci.o acpi.o > obj-$(CONFIG_XEN_PCIDEV_BACKEND) += xen-pciback/ > +obj-$(CONFIG_ACPI_HOTPLUG_MEMORY) += xen_acpi_memhotplug.o > ifdef CONFIG_ACPI_PROCESSOR_XEN > obj-$(CONFIG_ACPI_PROCESSOR) += acpi_processor.o > endif > diff --git a/drivers/xen/xen_acpi_memhotplug.c b/drivers/xen/xen_acpi_memhotplug.c > new file mode 100644 > index 0000000..0c4af99 > --- /dev/null > +++ b/drivers/xen/xen_acpi_memhotplug.c > @@ -0,0 +1,209 @@ > +/* > + * xen_acpi_memhotplug.c - interface to notify Xen on memory device hotadd > + * > + * Copyright (C) 2008, Intel corporation > + * > + * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; either version 2 of the License, or (at > + * your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, but > + * WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License along > + * with this program; if not, write to the Free Software Foundation, Inc., > + * 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. > + * > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +struct xen_hotmem_entry { > + struct list_head hotmem_list; > + uint64_t start; > + uint64_t end; > + uint32_t flags; > + uint32_t pxm; > +}; > + > +struct xen_hotmem_list { > + struct list_head list; > + int entry_nr; > +} xen_hotmem; > + > +DEFINE_SPINLOCK(xen_hotmem_lock); > + > +static int xen_hyper_addmem(struct xen_hotmem_entry *entry) > +{ > + int ret; > + > + xen_platform_op_t op = { > + .cmd = XENPF_mem_hotadd, > + .interface_version = XENPF_INTERFACE_VERSION, > + }; > + op.u.mem_add.spfn = entry->start >> PAGE_SHIFT; > + op.u.mem_add.epfn = entry->end >> PAGE_SHIFT; > + op.u.mem_add.flags = entry->flags; > + op.u.mem_add.pxm = entry->pxm; > + > + ret = HYPERVISOR_dom0_op(&op); > + return ret; > +} > + > +static int add_hotmem_entry(int pxm, uint64_t start, > + uint64_t length, uint32_t flags) > +{ > + struct xen_hotmem_entry *entry; > + > + if (pxm < 0 || !length) > + return -EINVAL; > + > + entry = kzalloc(sizeof(struct xen_hotmem_entry), GFP_ATOMIC); > + if (!entry) > + return -ENOMEM; > + > + INIT_LIST_HEAD(&entry->hotmem_list); > + entry->start = start; > + entry->end = start + length; > + entry->flags = flags; > + entry->pxm = pxm; > + > + spin_lock(&xen_hotmem_lock); > + > + list_add_tail(&entry->hotmem_list, &xen_hotmem.list); > + xen_hotmem.entry_nr++; > + > + spin_unlock(&xen_hotmem_lock); > + > + return 0; > +} > + > +static int free_hotmem_entry(struct xen_hotmem_entry *entry) > +{ > + list_del(&entry->hotmem_list); > + kfree(entry); > + > + return 0; > +} > + > +static void xen_hotadd_mem_dpc(struct work_struct *work) > +{ > + struct list_head *elem, *tmp; > + struct xen_hotmem_entry *entry; > + unsigned long flags; > + int ret; > + > + spin_lock_irqsave(&xen_hotmem_lock, flags); > + list_for_each_safe(elem, tmp, &xen_hotmem.list) { > + entry = list_entry(elem, struct xen_hotmem_entry, hotmem_list); > + ret = xen_hyper_addmem(entry); > + if (ret) > + printk(KERN_WARNING "xen addmem failed with %x\n", ret); > + free_hotmem_entry(entry); > + xen_hotmem.entry_nr--; > + } > + spin_unlock_irqrestore(&xen_hotmem_lock, flags); > +} > + > +static DECLARE_WORK(xen_hotadd_mem_work, xen_hotadd_mem_dpc); > + > +static int xen_acpi_get_pxm(acpi_handle h) > +{ > + unsigned long long pxm; > + acpi_status status; > + acpi_handle handle; > + acpi_handle phandle = h; > + > + do { > + handle = phandle; > + status = acpi_evaluate_integer(handle, "_PXM", NULL, &pxm); > + if (ACPI_SUCCESS(status)) > + return pxm; > + status = acpi_get_parent(handle, &phandle); > + } while (ACPI_SUCCESS(status)); > + > + return -1; > +} > + > +int xen_hotadd_memory(struct acpi_memory_device *mem_device) > +{ > + int pxm, result; > + int num_enabled = 0; > + struct acpi_memory_info *info; > + > + if (!mem_device) > + return -EINVAL; > + > + pxm = xen_acpi_get_pxm(mem_device->device->handle); > + > + if (pxm < 0) > + return -EINVAL; > + > + /* > + * Always return success to ACPI driver, and notify hypervisor later > + * because hypervisor will utilize the memory in memory hotadd hypercall > + */ > + list_for_each_entry(info, &mem_device->res_list, list) { > + if (info->enabled) { /* just sanity check...*/ > + num_enabled++; > + continue; > + } > + /* > + * If the memory block size is zero, please ignore it. > + * Don't try to do the following memory hotplug flowchart. > + */ > + if (!info->length) > + continue; > + > + result = add_hotmem_entry(pxm, info->start_addr, > + info->length, 0); > + if (result) > + continue; > + info->enabled = 1; > + num_enabled++; > + } > + > + if (!num_enabled) > + return -EINVAL; > + > + schedule_work(&xen_hotadd_mem_work); > + > + return 0; > +} > +EXPORT_SYMBOL(xen_hotadd_memory); > + > +static int xen_hotadd_mem_init(void) > +{ > + if (!xen_initial_domain()) > + return -ENODEV; > + > + INIT_LIST_HEAD(&xen_hotmem.list); > + xen_hotmem.entry_nr = 0; > + > + return 0; > +} > + > +static void xen_hotadd_mem_exit(void) > +{ > + flush_scheduled_work(); > +} > + > +module_init(xen_hotadd_mem_init); > +module_exit(xen_hotadd_mem_exit); > +MODULE_LICENSE("GPL"); > diff --git a/include/xen/acpi.h b/include/xen/acpi.h > index 7aa282d..8b3462e 100644 > --- a/include/xen/acpi.h > +++ b/include/xen/acpi.h > @@ -107,6 +107,11 @@ static inline int xen_acpi_processor_get_performance(struct acpi_processor *pr) > } > #endif > > +#if defined(CONFIG_ACPI_HOTPLUG_MEMORY) || \ > +defined(CONFIG_ACPI_HOTPLUG_MEMORY_MODULE) > +int xen_hotadd_memory(struct acpi_memory_device *mem_device); > +#endif > + > #if defined(CONFIG_ACPI_PROCESSOR_XEN) || \ > defined(CONFIG_ACPI_PROCESSOR_XEN_MODULE) > > diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h > index 9fd6b07..0787c68 100644 > --- a/include/xen/interface/platform.h > +++ b/include/xen/interface/platform.h > @@ -329,6 +329,14 @@ struct xenpf_cpu_hotadd { > uint32_t pxm; > }; > > +#define XENPF_mem_hotadd 59 > +struct xenpf_mem_hotadd { > + uint64_t spfn; > + uint64_t epfn; > + uint32_t pxm; > + uint32_t flags; > +}; > + > struct xen_platform_op { > uint32_t cmd; > uint32_t interface_version; /* XENPF_INTERFACE_VERSION */ > @@ -347,6 +355,7 @@ struct xen_platform_op { > struct xenpf_pcpuinfo pcpu_info; > struct xenpf_cpu_ol cpu_ol; > struct xenpf_cpu_hotadd cpu_add; > + struct xenpf_mem_hotadd mem_add; > uint8_t pad[128]; > } u; > }; > -- > 1.6.5.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 13:43:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 13:43:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPEX-0005l7-Pf; Wed, 03 Oct 2012 13:43:29 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPEW-0005ky-9Z for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 13:43:28 +0000 Received: from [85.158.138.51:64759] by server-8.bemta-3.messagelabs.com id B3/A2-16337-FF04C605; Wed, 03 Oct 2012 13:43:27 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1349271804!14259602!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzgwMzQw\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3753 invoked from network); 3 Oct 2012 13:43:26 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Oct 2012 13:43:26 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q93DhLhG026933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Oct 2012 13:43:22 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q93DhKFW003915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Oct 2012 13:43:21 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q93DhKJh009526; Wed, 3 Oct 2012 08:43:20 -0500 Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 03 Oct 2012 06:43:20 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 6A6A04032D; Wed, 3 Oct 2012 09:31:56 -0400 (EDT) Date: Wed, 3 Oct 2012 09:31:56 -0400 From: Konrad Rzeszutek Wilk To: "Liu, Jinsong" Message-ID: <20121003133156.GB31173@phenom.dumpdata.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "xen-devel@lists.xensource.com" , "jeremy.fitzhardinge@citrix.com" , "Jiang, Yunhong" Subject: Re: [Xen-devel] [PATCH 08/10] xen/acpi: add cpu hotadd support X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, Dec 22, 2011 at 10:08:34AM +0000, Liu, Jinsong wrote: > >From 282958be3a33b2f2b888e1ed3ac022bf8a199ec9 Mon Sep 17 00:00:00 2001 > From: Liu Jinsong > Date: Wed, 14 Dec 2011 11:38:11 +0800 > Subject: [PATCH 08/10] xen/acpi: add cpu hotadd support > > This patch add cpu hotadd support. > It keep similar cpu hotadd logic as native, w/ some changes according > to xen requirement, hypercalling hypervisor related logic to hotadd cpu. Is this needed anymore? Or is the existing code in the upstream kernel sufficient enough for this? Or do we need a hotplug CPU notifier in the xen-acpi-processor? > > Signed-off-by: Liu, Jinsong > Signed-off-by: Jiang, Yunhong > --- > drivers/acpi/processor_driver.c | 4 +- > drivers/acpi/processor_xen.c | 242 ++++++++++++++++++++++++++++++++++++++- > include/acpi/processor.h | 2 + > include/xen/pcpu.h | 2 + > 4 files changed, 246 insertions(+), 4 deletions(-) > > diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c > index 8a367d7..d473fd5 100644 > --- a/drivers/acpi/processor_driver.c > +++ b/drivers/acpi/processor_driver.c > @@ -221,7 +221,7 @@ static int acpi_processor_errata_piix4(struct pci_dev *dev) > return 0; > } > > -static int acpi_processor_errata(struct acpi_processor *pr) > +int acpi_processor_errata(struct acpi_processor *pr) > { > int result = 0; > struct pci_dev *dev = NULL; > @@ -378,7 +378,7 @@ static int acpi_processor_get_info(struct acpi_device *device) > return 0; > } > > -static DEFINE_PER_CPU(void *, processor_device_array); > +DEFINE_PER_CPU(void *, processor_device_array); > > void acpi_processor_notify(struct acpi_device *device, u32 event) > { > diff --git a/drivers/acpi/processor_xen.c b/drivers/acpi/processor_xen.c > index 38a1c05..3af1f73 100644 > --- a/drivers/acpi/processor_xen.c > +++ b/drivers/acpi/processor_xen.c > @@ -24,6 +24,7 @@ > #define PREFIX "ACPI: " > > #define ACPI_PROCESSOR_CLASS "processor" > +#define ACPI_PROCESSOR_DEVICE_NAME "Processor" > #define ACPI_PROCESSOR_NOTIFY_PERFORMANCE 0x80 > #define ACPI_PROCESSOR_NOTIFY_POWER 0x81 > #define ACPI_PROCESSOR_NOTIFY_THROTTLING 0x82 > @@ -88,6 +89,8 @@ xen_acpi_processor_hotadd_init(struct acpi_processor *pr, int *p_cpu) > PROCESSOR_HOTPLUG, HOTPLUG_TYPE_ADD)) > return AE_ERROR; > > + *p_cpu = xen_pcpu_index(pr->acpi_id, 1); > + > return AE_OK; > } > > @@ -149,13 +152,248 @@ err_out: > } > #endif /* CONFIG_CPU_FREQ */ > > +static int xen_acpi_processor_get_info(struct acpi_device *device) > +{ > + acpi_status status = 0; > + union acpi_object object = { 0 }; > + struct acpi_buffer buffer = { sizeof(union acpi_object), &object }; > + struct acpi_processor *pr; > + int cpu_index, device_declaration = 0; > + static int cpu0_initialized; > + > + pr = acpi_driver_data(device); > + if (!pr) > + return -EINVAL; > + > + if (num_online_cpus() > 1) > + errata.smp = TRUE; > + > + acpi_processor_errata(pr); > + > + /* > + * Check to see if we have bus mastering arbitration control. This > + * is required for proper C3 usage (to maintain cache coherency). > + */ > + if (acpi_gbl_FADT.pm2_control_block && acpi_gbl_FADT.pm2_control_length) { > + pr->flags.bm_control = 1; > + ACPI_DEBUG_PRINT((ACPI_DB_INFO, > + "Bus mastering arbitration control present\n")); > + } else > + ACPI_DEBUG_PRINT((ACPI_DB_INFO, > + "No bus mastering arbitration control\n")); > + > + if (!strcmp(acpi_device_hid(device), ACPI_PROCESSOR_OBJECT_HID)) { > + /* Declared with "Processor" statement; match ProcessorID */ > + status = acpi_evaluate_object(pr->handle, NULL, NULL, &buffer); > + if (ACPI_FAILURE(status)) { > + printk(KERN_ERR PREFIX "Evaluating processor object\n"); > + return -ENODEV; > + } > + > + /* > + * TBD: Synch processor ID (via LAPIC/LSAPIC structures) on SMP. > + * >>> 'acpi_get_processor_id(acpi_id, &id)' in > + * arch/xxx/acpi.c > + */ > + pr->acpi_id = object.processor.proc_id; > + } else { > + /* > + * Declared with "Device" statement; match _UID. > + * Note that we don't handle string _UIDs yet. > + */ > + unsigned long long value; > + status = acpi_evaluate_integer(pr->handle, METHOD_NAME__UID, > + NULL, &value); > + if (ACPI_FAILURE(status)) { > + printk(KERN_ERR PREFIX > + "Evaluating processor _UID [%#x]\n", status); > + return -ENODEV; > + } > + device_declaration = 1; > + pr->acpi_id = value; > + } > + > + cpu_index = xen_pcpu_index(pr->acpi_id, 1); > + > + /* Handle UP system running SMP kernel, with no LAPIC in MADT */ > + if (!cpu0_initialized && (cpu_index == -1) && > + (num_online_cpus() == 1)) { > + cpu_index = 0; > + } > + > + cpu0_initialized = 1; > + > + pr->id = cpu_index; > + > + /* > + * Extra Processor objects may be enumerated on MP systems with > + * less than the max # of CPUs. They should be ignored _iff > + * they are physically not present. > + */ > + if (pr->id == -1) { > + if (ACPI_FAILURE > + (xen_acpi_processor_hotadd_init(pr, &pr->id))) { > + return -ENODEV; > + } > + } > + /* > + * On some boxes several processors use the same processor bus id. > + * But they are located in different scope. For example: > + * \_SB.SCK0.CPU0 > + * \_SB.SCK1.CPU0 > + * Rename the processor device bus id. And the new bus id will be > + * generated as the following format: > + * CPU+CPU ID. > + */ > + sprintf(acpi_device_bid(device), "CPU%X", pr->id); > + ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Processor [%d:%d]\n", pr->id, > + pr->acpi_id)); > + > + if (!object.processor.pblk_address) > + ACPI_DEBUG_PRINT((ACPI_DB_INFO, "No PBLK (NULL address)\n")); > + else if (object.processor.pblk_length != 6) > + printk(KERN_ERR PREFIX "Invalid PBLK length [%d]\n", > + object.processor.pblk_length); > + else { > + pr->throttling.address = object.processor.pblk_address; > + pr->throttling.duty_offset = acpi_gbl_FADT.duty_offset; > + pr->throttling.duty_width = acpi_gbl_FADT.duty_width; > + > + pr->pblk = object.processor.pblk_address; > + > + /* > + * We don't care about error returns - we just try to mark > + * these reserved so that nobody else is confused into thinking > + * that this region might be unused.. > + * > + * (In particular, allocating the IO range for Cardbus) > + */ > + request_region(pr->throttling.address, 6, "ACPI CPU throttle"); > + } > + > + /* > + * If ACPI describes a slot number for this CPU, we can use it > + * ensure we get the right value in the "physical id" field > + * of /proc/cpuinfo > + */ > + status = acpi_evaluate_object(pr->handle, "_SUN", NULL, &buffer); > + if (ACPI_SUCCESS(status)) > + arch_fix_phys_package_id(pr->id, object.integer.value); > + > + return 0; > +} > + > +static int __cpuinit __xen_acpi_processor_add(struct acpi_device *device) > +{ > + struct acpi_processor *pr = NULL; > + int result = 0; > + struct sys_device *sysdev; > + > + pr = kzalloc(sizeof(struct acpi_processor), GFP_KERNEL); > + if (!pr) > + return -ENOMEM; > + > + if (!zalloc_cpumask_var(&pr->throttling.shared_cpu_map, GFP_KERNEL)) { > + kfree(pr); > + return -ENOMEM; > + } > + > + pr->handle = device->handle; > + strcpy(acpi_device_name(device), ACPI_PROCESSOR_DEVICE_NAME); > + strcpy(acpi_device_class(device), ACPI_PROCESSOR_CLASS); > + device->driver_data = pr; > + > + result = xen_acpi_processor_get_info(device); > + if (result) { > + /* Processor is physically not present */ > + return 0; > + } > + > +#ifdef CONFIG_SMP > + if (pr->id >= setup_max_cpus && pr->id != 0) > + return 0; > +#endif > + > + BUG_ON((pr->id >= nr_cpu_ids) || (pr->id < 0)); > + > + /* > + * Buggy BIOS check > + * ACPI id of processors can be reported wrongly by the BIOS. > + * Don't trust it blindly > + */ > + if (per_cpu(processor_device_array, pr->id) != NULL && > + per_cpu(processor_device_array, pr->id) != device) { > + printk(KERN_WARNING "BIOS reported wrong ACPI id " > + "for the processor\n"); > + result = -ENODEV; > + goto err_free_cpumask; > + } > + per_cpu(processor_device_array, pr->id) = device; > + > + per_cpu(processors, pr->id) = pr; > + > + sysdev = get_cpu_sysdev(pr->id); > + if (sysfs_create_link(&device->dev.kobj, &sysdev->kobj, "sysdev")) { > + result = -EFAULT; > + goto err_free_cpumask; > + } > + > +#ifdef CONFIG_CPU_FREQ > + acpi_processor_ppc_has_changed(pr, 0); > +#endif > + acpi_processor_get_throttling_info(pr); > + acpi_processor_get_limit_info(pr); > + > + > + if (cpuidle_get_driver() == &acpi_idle_driver) > + acpi_processor_power_init(pr, device); > + > + pr->cdev = thermal_cooling_device_register("Processor", device, > + &processor_cooling_ops); > + if (IS_ERR(pr->cdev)) { > + result = PTR_ERR(pr->cdev); > + goto err_power_exit; > + } > + > + dev_dbg(&device->dev, "registered as cooling_device%d\n", > + pr->cdev->id); > + > + result = sysfs_create_link(&device->dev.kobj, > + &pr->cdev->device.kobj, > + "thermal_cooling"); > + if (result) { > + printk(KERN_ERR PREFIX "Create sysfs link\n"); > + goto err_thermal_unregister; > + } > + result = sysfs_create_link(&pr->cdev->device.kobj, > + &device->dev.kobj, > + "device"); > + if (result) { > + printk(KERN_ERR PREFIX "Create sysfs link\n"); > + goto err_remove_sysfs; > + } > + > + return 0; > + > +err_remove_sysfs: > + sysfs_remove_link(&device->dev.kobj, "thermal_cooling"); > +err_thermal_unregister: > + thermal_cooling_device_unregister(pr->cdev); > +err_power_exit: > + acpi_processor_power_exit(pr, device); > +err_free_cpumask: > + free_cpumask_var(pr->throttling.shared_cpu_map); > + > + return result; > +} > + > static int __cpuinit xen_acpi_processor_add(struct acpi_device *device) > { > struct acpi_processor *pr = NULL; > int result = 0; > > - result = acpi_processor_add(device); > - if (result < 0) > + result = __xen_acpi_processor_add(device); > + if (result) > return result; > > pr = acpi_driver_data(device); > diff --git a/include/acpi/processor.h b/include/acpi/processor.h > index c48e2f9..3a1ee01 100644 > --- a/include/acpi/processor.h > +++ b/include/acpi/processor.h > @@ -225,6 +225,8 @@ struct acpi_processor_errata { > } piix4; > }; > > +extern int acpi_processor_errata(struct acpi_processor *pr); > + > extern int acpi_processor_preregister_performance(struct > acpi_processor_performance > __percpu *performance); > diff --git a/include/xen/pcpu.h b/include/xen/pcpu.h > index 7e8f9d1..3e99db9 100644 > --- a/include/xen/pcpu.h > +++ b/include/xen/pcpu.h > @@ -4,6 +4,8 @@ > #include > #include > > +extern DEFINE_PER_CPU(void *, processor_device_array); > + > extern int xen_pcpu_hotplug(int type, uint32_t apic_id); > #define XEN_PCPU_ONLINE 0x01 > #define XEN_PCPU_OFFLINE 0x02 > -- > 1.6.5.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 13:43:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 13:43:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPEX-0005l7-Pf; Wed, 03 Oct 2012 13:43:29 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPEW-0005ky-9Z for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 13:43:28 +0000 Received: from [85.158.138.51:64759] by server-8.bemta-3.messagelabs.com id B3/A2-16337-FF04C605; Wed, 03 Oct 2012 13:43:27 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1349271804!14259602!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzgwMzQw\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3753 invoked from network); 3 Oct 2012 13:43:26 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Oct 2012 13:43:26 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q93DhLhG026933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Oct 2012 13:43:22 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q93DhKFW003915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Oct 2012 13:43:21 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q93DhKJh009526; Wed, 3 Oct 2012 08:43:20 -0500 Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 03 Oct 2012 06:43:20 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 6A6A04032D; Wed, 3 Oct 2012 09:31:56 -0400 (EDT) Date: Wed, 3 Oct 2012 09:31:56 -0400 From: Konrad Rzeszutek Wilk To: "Liu, Jinsong" Message-ID: <20121003133156.GB31173@phenom.dumpdata.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "xen-devel@lists.xensource.com" , "jeremy.fitzhardinge@citrix.com" , "Jiang, Yunhong" Subject: Re: [Xen-devel] [PATCH 08/10] xen/acpi: add cpu hotadd support X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, Dec 22, 2011 at 10:08:34AM +0000, Liu, Jinsong wrote: > >From 282958be3a33b2f2b888e1ed3ac022bf8a199ec9 Mon Sep 17 00:00:00 2001 > From: Liu Jinsong > Date: Wed, 14 Dec 2011 11:38:11 +0800 > Subject: [PATCH 08/10] xen/acpi: add cpu hotadd support > > This patch add cpu hotadd support. > It keep similar cpu hotadd logic as native, w/ some changes according > to xen requirement, hypercalling hypervisor related logic to hotadd cpu. Is this needed anymore? Or is the existing code in the upstream kernel sufficient enough for this? Or do we need a hotplug CPU notifier in the xen-acpi-processor? > > Signed-off-by: Liu, Jinsong > Signed-off-by: Jiang, Yunhong > --- > drivers/acpi/processor_driver.c | 4 +- > drivers/acpi/processor_xen.c | 242 ++++++++++++++++++++++++++++++++++++++- > include/acpi/processor.h | 2 + > include/xen/pcpu.h | 2 + > 4 files changed, 246 insertions(+), 4 deletions(-) > > diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c > index 8a367d7..d473fd5 100644 > --- a/drivers/acpi/processor_driver.c > +++ b/drivers/acpi/processor_driver.c > @@ -221,7 +221,7 @@ static int acpi_processor_errata_piix4(struct pci_dev *dev) > return 0; > } > > -static int acpi_processor_errata(struct acpi_processor *pr) > +int acpi_processor_errata(struct acpi_processor *pr) > { > int result = 0; > struct pci_dev *dev = NULL; > @@ -378,7 +378,7 @@ static int acpi_processor_get_info(struct acpi_device *device) > return 0; > } > > -static DEFINE_PER_CPU(void *, processor_device_array); > +DEFINE_PER_CPU(void *, processor_device_array); > > void acpi_processor_notify(struct acpi_device *device, u32 event) > { > diff --git a/drivers/acpi/processor_xen.c b/drivers/acpi/processor_xen.c > index 38a1c05..3af1f73 100644 > --- a/drivers/acpi/processor_xen.c > +++ b/drivers/acpi/processor_xen.c > @@ -24,6 +24,7 @@ > #define PREFIX "ACPI: " > > #define ACPI_PROCESSOR_CLASS "processor" > +#define ACPI_PROCESSOR_DEVICE_NAME "Processor" > #define ACPI_PROCESSOR_NOTIFY_PERFORMANCE 0x80 > #define ACPI_PROCESSOR_NOTIFY_POWER 0x81 > #define ACPI_PROCESSOR_NOTIFY_THROTTLING 0x82 > @@ -88,6 +89,8 @@ xen_acpi_processor_hotadd_init(struct acpi_processor *pr, int *p_cpu) > PROCESSOR_HOTPLUG, HOTPLUG_TYPE_ADD)) > return AE_ERROR; > > + *p_cpu = xen_pcpu_index(pr->acpi_id, 1); > + > return AE_OK; > } > > @@ -149,13 +152,248 @@ err_out: > } > #endif /* CONFIG_CPU_FREQ */ > > +static int xen_acpi_processor_get_info(struct acpi_device *device) > +{ > + acpi_status status = 0; > + union acpi_object object = { 0 }; > + struct acpi_buffer buffer = { sizeof(union acpi_object), &object }; > + struct acpi_processor *pr; > + int cpu_index, device_declaration = 0; > + static int cpu0_initialized; > + > + pr = acpi_driver_data(device); > + if (!pr) > + return -EINVAL; > + > + if (num_online_cpus() > 1) > + errata.smp = TRUE; > + > + acpi_processor_errata(pr); > + > + /* > + * Check to see if we have bus mastering arbitration control. This > + * is required for proper C3 usage (to maintain cache coherency). > + */ > + if (acpi_gbl_FADT.pm2_control_block && acpi_gbl_FADT.pm2_control_length) { > + pr->flags.bm_control = 1; > + ACPI_DEBUG_PRINT((ACPI_DB_INFO, > + "Bus mastering arbitration control present\n")); > + } else > + ACPI_DEBUG_PRINT((ACPI_DB_INFO, > + "No bus mastering arbitration control\n")); > + > + if (!strcmp(acpi_device_hid(device), ACPI_PROCESSOR_OBJECT_HID)) { > + /* Declared with "Processor" statement; match ProcessorID */ > + status = acpi_evaluate_object(pr->handle, NULL, NULL, &buffer); > + if (ACPI_FAILURE(status)) { > + printk(KERN_ERR PREFIX "Evaluating processor object\n"); > + return -ENODEV; > + } > + > + /* > + * TBD: Synch processor ID (via LAPIC/LSAPIC structures) on SMP. > + * >>> 'acpi_get_processor_id(acpi_id, &id)' in > + * arch/xxx/acpi.c > + */ > + pr->acpi_id = object.processor.proc_id; > + } else { > + /* > + * Declared with "Device" statement; match _UID. > + * Note that we don't handle string _UIDs yet. > + */ > + unsigned long long value; > + status = acpi_evaluate_integer(pr->handle, METHOD_NAME__UID, > + NULL, &value); > + if (ACPI_FAILURE(status)) { > + printk(KERN_ERR PREFIX > + "Evaluating processor _UID [%#x]\n", status); > + return -ENODEV; > + } > + device_declaration = 1; > + pr->acpi_id = value; > + } > + > + cpu_index = xen_pcpu_index(pr->acpi_id, 1); > + > + /* Handle UP system running SMP kernel, with no LAPIC in MADT */ > + if (!cpu0_initialized && (cpu_index == -1) && > + (num_online_cpus() == 1)) { > + cpu_index = 0; > + } > + > + cpu0_initialized = 1; > + > + pr->id = cpu_index; > + > + /* > + * Extra Processor objects may be enumerated on MP systems with > + * less than the max # of CPUs. They should be ignored _iff > + * they are physically not present. > + */ > + if (pr->id == -1) { > + if (ACPI_FAILURE > + (xen_acpi_processor_hotadd_init(pr, &pr->id))) { > + return -ENODEV; > + } > + } > + /* > + * On some boxes several processors use the same processor bus id. > + * But they are located in different scope. For example: > + * \_SB.SCK0.CPU0 > + * \_SB.SCK1.CPU0 > + * Rename the processor device bus id. And the new bus id will be > + * generated as the following format: > + * CPU+CPU ID. > + */ > + sprintf(acpi_device_bid(device), "CPU%X", pr->id); > + ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Processor [%d:%d]\n", pr->id, > + pr->acpi_id)); > + > + if (!object.processor.pblk_address) > + ACPI_DEBUG_PRINT((ACPI_DB_INFO, "No PBLK (NULL address)\n")); > + else if (object.processor.pblk_length != 6) > + printk(KERN_ERR PREFIX "Invalid PBLK length [%d]\n", > + object.processor.pblk_length); > + else { > + pr->throttling.address = object.processor.pblk_address; > + pr->throttling.duty_offset = acpi_gbl_FADT.duty_offset; > + pr->throttling.duty_width = acpi_gbl_FADT.duty_width; > + > + pr->pblk = object.processor.pblk_address; > + > + /* > + * We don't care about error returns - we just try to mark > + * these reserved so that nobody else is confused into thinking > + * that this region might be unused.. > + * > + * (In particular, allocating the IO range for Cardbus) > + */ > + request_region(pr->throttling.address, 6, "ACPI CPU throttle"); > + } > + > + /* > + * If ACPI describes a slot number for this CPU, we can use it > + * ensure we get the right value in the "physical id" field > + * of /proc/cpuinfo > + */ > + status = acpi_evaluate_object(pr->handle, "_SUN", NULL, &buffer); > + if (ACPI_SUCCESS(status)) > + arch_fix_phys_package_id(pr->id, object.integer.value); > + > + return 0; > +} > + > +static int __cpuinit __xen_acpi_processor_add(struct acpi_device *device) > +{ > + struct acpi_processor *pr = NULL; > + int result = 0; > + struct sys_device *sysdev; > + > + pr = kzalloc(sizeof(struct acpi_processor), GFP_KERNEL); > + if (!pr) > + return -ENOMEM; > + > + if (!zalloc_cpumask_var(&pr->throttling.shared_cpu_map, GFP_KERNEL)) { > + kfree(pr); > + return -ENOMEM; > + } > + > + pr->handle = device->handle; > + strcpy(acpi_device_name(device), ACPI_PROCESSOR_DEVICE_NAME); > + strcpy(acpi_device_class(device), ACPI_PROCESSOR_CLASS); > + device->driver_data = pr; > + > + result = xen_acpi_processor_get_info(device); > + if (result) { > + /* Processor is physically not present */ > + return 0; > + } > + > +#ifdef CONFIG_SMP > + if (pr->id >= setup_max_cpus && pr->id != 0) > + return 0; > +#endif > + > + BUG_ON((pr->id >= nr_cpu_ids) || (pr->id < 0)); > + > + /* > + * Buggy BIOS check > + * ACPI id of processors can be reported wrongly by the BIOS. > + * Don't trust it blindly > + */ > + if (per_cpu(processor_device_array, pr->id) != NULL && > + per_cpu(processor_device_array, pr->id) != device) { > + printk(KERN_WARNING "BIOS reported wrong ACPI id " > + "for the processor\n"); > + result = -ENODEV; > + goto err_free_cpumask; > + } > + per_cpu(processor_device_array, pr->id) = device; > + > + per_cpu(processors, pr->id) = pr; > + > + sysdev = get_cpu_sysdev(pr->id); > + if (sysfs_create_link(&device->dev.kobj, &sysdev->kobj, "sysdev")) { > + result = -EFAULT; > + goto err_free_cpumask; > + } > + > +#ifdef CONFIG_CPU_FREQ > + acpi_processor_ppc_has_changed(pr, 0); > +#endif > + acpi_processor_get_throttling_info(pr); > + acpi_processor_get_limit_info(pr); > + > + > + if (cpuidle_get_driver() == &acpi_idle_driver) > + acpi_processor_power_init(pr, device); > + > + pr->cdev = thermal_cooling_device_register("Processor", device, > + &processor_cooling_ops); > + if (IS_ERR(pr->cdev)) { > + result = PTR_ERR(pr->cdev); > + goto err_power_exit; > + } > + > + dev_dbg(&device->dev, "registered as cooling_device%d\n", > + pr->cdev->id); > + > + result = sysfs_create_link(&device->dev.kobj, > + &pr->cdev->device.kobj, > + "thermal_cooling"); > + if (result) { > + printk(KERN_ERR PREFIX "Create sysfs link\n"); > + goto err_thermal_unregister; > + } > + result = sysfs_create_link(&pr->cdev->device.kobj, > + &device->dev.kobj, > + "device"); > + if (result) { > + printk(KERN_ERR PREFIX "Create sysfs link\n"); > + goto err_remove_sysfs; > + } > + > + return 0; > + > +err_remove_sysfs: > + sysfs_remove_link(&device->dev.kobj, "thermal_cooling"); > +err_thermal_unregister: > + thermal_cooling_device_unregister(pr->cdev); > +err_power_exit: > + acpi_processor_power_exit(pr, device); > +err_free_cpumask: > + free_cpumask_var(pr->throttling.shared_cpu_map); > + > + return result; > +} > + > static int __cpuinit xen_acpi_processor_add(struct acpi_device *device) > { > struct acpi_processor *pr = NULL; > int result = 0; > > - result = acpi_processor_add(device); > - if (result < 0) > + result = __xen_acpi_processor_add(device); > + if (result) > return result; > > pr = acpi_driver_data(device); > diff --git a/include/acpi/processor.h b/include/acpi/processor.h > index c48e2f9..3a1ee01 100644 > --- a/include/acpi/processor.h > +++ b/include/acpi/processor.h > @@ -225,6 +225,8 @@ struct acpi_processor_errata { > } piix4; > }; > > +extern int acpi_processor_errata(struct acpi_processor *pr); > + > extern int acpi_processor_preregister_performance(struct > acpi_processor_performance > __percpu *performance); > diff --git a/include/xen/pcpu.h b/include/xen/pcpu.h > index 7e8f9d1..3e99db9 100644 > --- a/include/xen/pcpu.h > +++ b/include/xen/pcpu.h > @@ -4,6 +4,8 @@ > #include > #include > > +extern DEFINE_PER_CPU(void *, processor_device_array); > + > extern int xen_pcpu_hotplug(int type, uint32_t apic_id); > #define XEN_PCPU_ONLINE 0x01 > #define XEN_PCPU_OFFLINE 0x02 > -- > 1.6.5.6 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 13:48:48 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 13:48:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPJW-00063f-N6; Wed, 03 Oct 2012 13:48:38 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPJU-00063F-CB for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 13:48:36 +0000 Received: from [85.158.139.211:33106] by server-2.bemta-5.messagelabs.com id A3/26-28944-3324C605; Wed, 03 Oct 2012 13:48:35 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-4.tower-206.messagelabs.com!1349272113!20941716!1 X-Originating-IP: [209.85.161.173] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31346 invoked from network); 3 Oct 2012 13:48:34 -0000 Received: from mail-gg0-f173.google.com (HELO mail-gg0-f173.google.com) (209.85.161.173) by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 13:48:34 -0000 Received: by ggcs5 with SMTP id s5so647238ggc.32 for ; Wed, 03 Oct 2012 06:48:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zM4QMTYCfgRH/y2hyAbWBT0z3/x/TWkQ7df7jbwaltU=; b=gjjkhGoomfutYXKF9oK577+VYGTv8hQX0c3Ef8H830ieyEAcb0a37/doDxBlzi94SP rscKBMklBsdiGL6ZPHQCoqr7Xwt9jnuJPS8845apokT5ISpqFHusRrscnmt3hZGZh+gC D35Ne7ga/f0uuLKuUriqNsh32bDPrzCTwSIcbr8DUR4Y1khLGc+x8s+MnSa2EBI5txeh RaCyYk1RN14GHMPFzkSaUyvEbuv47uQH+gJQhcPkKg5USnwCsY8R/MkOU3iUvfT/sVNx zhDpDnBUWD25ys8vnRx8vLfhI48aUmnjx6SNnJNUW7R18SAKn7M7Cl8ySaKoubzAM1Y+ W2vQ== MIME-Version: 1.0 Received: by 10.236.137.208 with SMTP id y56mr1817318yhi.58.1349272113282; Wed, 03 Oct 2012 06:48:33 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Wed, 3 Oct 2012 06:48:33 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Oct 2012 16:48:33 +0300 Message-ID: From: Valtteri Kiviniemi To: Konrad Rzeszutek Wilk Cc: chris , Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.2.0, VNC connection to Windows domU causes black screen on VNC X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3007866389807026977==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============3007866389807026977== Content-Type: multipart/alternative; boundary=20cf303a2eb5047dce04cb27e545 --20cf303a2eb5047dce04cb27e545 Content-Type: text/plain; charset=ISO-8859-1 2012/10/3 Konrad Rzeszutek Wilk > On Wed, Oct 3, 2012 at 9:22 AM, Valtteri Kiviniemi > wrote: > > Hi, > > > > Tested with realvnc and tightvnc. Realvnc just closes itself when the > > resolution changes and tightvnc just stays open with the black screen. > > > > Lets first see if this is a problem with Windows 2008 expecting > certain registers in the VGA > emulation and falling flat on its face. > > If you launch (with the same guest config - but obviously replace the > ISO), with an > Fedora or Ubuntu LiveCD - does it boot? Do you see the VNC screen > changing resolution > and all that? > > Hi, Same problem with Fedora-17-x86_64-Live-Desktop.iso. I after the resolution changed the screen goes black. If I change stdvga to 1 I will see a bit further but then the VNC client crashes and says something about unsupported features (dont know even if it should work). - Valtteri --20cf303a2eb5047dce04cb27e545 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/10/3 Konrad Rzeszutek Wilk <konrad= @kernel.org>
On Wed, Oct 3, 2012 at 9:22 AM, Valtteri Kiviniemi
<kiviniemi.valtteri@gmai= l.com> wrote:
> Hi,
>
> Tested with realvnc and tightvnc. Realvnc just close= s itself when the
> resolution changes and tightvnc just stays open with the black screen.=
>

Lets first see if this is a problem with Windows 2008 expecting
certain registers in the VGA
emulation and falling flat on its face.

If you launch (with the same guest config - but obviously replace the
ISO), with an
Fedora or Ubuntu LiveCD - does it boot? Do you see the VNC screen
changing resolution
and all that?

=
Hi,

Same problem with Fedora-17-x86_64-Live-Desktop.iso. I after= the resolution changed the screen goes black. If I change stdvga to 1 I wi= ll see a bit further but then the VNC client crashes and says something abo= ut unsupported features (dont know even if it should work).

- Valtteri
--20cf303a2eb5047dce04cb27e545-- --===============3007866389807026977== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============3007866389807026977==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 13:48:48 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 13:48:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPJW-00063f-N6; Wed, 03 Oct 2012 13:48:38 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPJU-00063F-CB for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 13:48:36 +0000 Received: from [85.158.139.211:33106] by server-2.bemta-5.messagelabs.com id A3/26-28944-3324C605; Wed, 03 Oct 2012 13:48:35 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-4.tower-206.messagelabs.com!1349272113!20941716!1 X-Originating-IP: [209.85.161.173] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31346 invoked from network); 3 Oct 2012 13:48:34 -0000 Received: from mail-gg0-f173.google.com (HELO mail-gg0-f173.google.com) (209.85.161.173) by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 13:48:34 -0000 Received: by ggcs5 with SMTP id s5so647238ggc.32 for ; Wed, 03 Oct 2012 06:48:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zM4QMTYCfgRH/y2hyAbWBT0z3/x/TWkQ7df7jbwaltU=; b=gjjkhGoomfutYXKF9oK577+VYGTv8hQX0c3Ef8H830ieyEAcb0a37/doDxBlzi94SP rscKBMklBsdiGL6ZPHQCoqr7Xwt9jnuJPS8845apokT5ISpqFHusRrscnmt3hZGZh+gC D35Ne7ga/f0uuLKuUriqNsh32bDPrzCTwSIcbr8DUR4Y1khLGc+x8s+MnSa2EBI5txeh RaCyYk1RN14GHMPFzkSaUyvEbuv47uQH+gJQhcPkKg5USnwCsY8R/MkOU3iUvfT/sVNx zhDpDnBUWD25ys8vnRx8vLfhI48aUmnjx6SNnJNUW7R18SAKn7M7Cl8ySaKoubzAM1Y+ W2vQ== MIME-Version: 1.0 Received: by 10.236.137.208 with SMTP id y56mr1817318yhi.58.1349272113282; Wed, 03 Oct 2012 06:48:33 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Wed, 3 Oct 2012 06:48:33 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Oct 2012 16:48:33 +0300 Message-ID: From: Valtteri Kiviniemi To: Konrad Rzeszutek Wilk Cc: chris , Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.2.0, VNC connection to Windows domU causes black screen on VNC X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3007866389807026977==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============3007866389807026977== Content-Type: multipart/alternative; boundary=20cf303a2eb5047dce04cb27e545 --20cf303a2eb5047dce04cb27e545 Content-Type: text/plain; charset=ISO-8859-1 2012/10/3 Konrad Rzeszutek Wilk > On Wed, Oct 3, 2012 at 9:22 AM, Valtteri Kiviniemi > wrote: > > Hi, > > > > Tested with realvnc and tightvnc. Realvnc just closes itself when the > > resolution changes and tightvnc just stays open with the black screen. > > > > Lets first see if this is a problem with Windows 2008 expecting > certain registers in the VGA > emulation and falling flat on its face. > > If you launch (with the same guest config - but obviously replace the > ISO), with an > Fedora or Ubuntu LiveCD - does it boot? Do you see the VNC screen > changing resolution > and all that? > > Hi, Same problem with Fedora-17-x86_64-Live-Desktop.iso. I after the resolution changed the screen goes black. If I change stdvga to 1 I will see a bit further but then the VNC client crashes and says something about unsupported features (dont know even if it should work). - Valtteri --20cf303a2eb5047dce04cb27e545 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/10/3 Konrad Rzeszutek Wilk <konrad= @kernel.org>
On Wed, Oct 3, 2012 at 9:22 AM, Valtteri Kiviniemi
<kiviniemi.valtteri@gmai= l.com> wrote:
> Hi,
>
> Tested with realvnc and tightvnc. Realvnc just close= s itself when the
> resolution changes and tightvnc just stays open with the black screen.=
>

Lets first see if this is a problem with Windows 2008 expecting
certain registers in the VGA
emulation and falling flat on its face.

If you launch (with the same guest config - but obviously replace the
ISO), with an
Fedora or Ubuntu LiveCD - does it boot? Do you see the VNC screen
changing resolution
and all that?

=
Hi,

Same problem with Fedora-17-x86_64-Live-Desktop.iso. I after= the resolution changed the screen goes black. If I change stdvga to 1 I wi= ll see a bit further but then the VNC client crashes and says something abo= ut unsupported features (dont know even if it should work).

- Valtteri
--20cf303a2eb5047dce04cb27e545-- --===============3007866389807026977== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============3007866389807026977==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 13:49:59 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 13:49:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPKe-0006Ab-5Y; Wed, 03 Oct 2012 13:49:48 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPKc-0006AR-Us for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 13:49:47 +0000 Received: from [85.158.138.51:52635] by server-6.bemta-3.messagelabs.com id BD/F8-11085-A724C605; Wed, 03 Oct 2012 13:49:46 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1349272185!24920221!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 939 invoked from network); 3 Oct 2012 13:49:45 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 13:49:45 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="14916789" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 13:49:44 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 14:49:44 +0100 Message-ID: <1349272182.650.150.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Wed, 3 Oct 2012 14:49:42 +0100 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH] xen: point xen_start_info to a dummy struct for PV on HVM guests X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-10-03 at 14:37 +0100, Stefano Stabellini wrote: > PV on HVM guests don't have a start_info page mapped by Xen, so > xen_start_info is just NULL for them. > That is problem because other parts of the code expect xen_start_info to > point to something valid, for example xen_initial_domain() is defined as > follow: > > #define xen_initial_domain() (xen_domain() && \ > xen_start_info->flags & SIF_INITDOMAIN) But anyone who calls this before xen_start_info is setup is going to get a bogus result, specifically in this case they will think they are domU when in reality they are dom0 -- wouldn't it be better to fix those callsites? Perhaps turn this into a static inline with a BUG_ON(!xen_start_info) to make catching these cases easier? > > > Allocate a dummy start_info struct and point xen_start_info to it, as we > do on ARM. > This is not going to change things for PV guests because > xen_start_info is set by arch/x86/xen/xen-head.S:startup_xen. > > Signed-off-by: Stefano Stabellini > > diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c > index bf788d3..5f242cb 100644 > --- a/arch/x86/xen/enlighten.c > +++ b/arch/x86/xen/enlighten.c > @@ -96,7 +96,8 @@ EXPORT_SYMBOL(machine_to_phys_mapping); > unsigned long machine_to_phys_nr; > EXPORT_SYMBOL(machine_to_phys_nr); > > -struct start_info *xen_start_info; > +static struct start_info _xen_start_info; > +struct start_info *xen_start_info = &_xen_start_info; > EXPORT_SYMBOL_GPL(xen_start_info); > > struct shared_info xen_dummy_shared_info; > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 13:49:59 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 13:49:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPKe-0006Ab-5Y; Wed, 03 Oct 2012 13:49:48 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPKc-0006AR-Us for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 13:49:47 +0000 Received: from [85.158.138.51:52635] by server-6.bemta-3.messagelabs.com id BD/F8-11085-A724C605; Wed, 03 Oct 2012 13:49:46 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1349272185!24920221!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 939 invoked from network); 3 Oct 2012 13:49:45 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 13:49:45 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="14916789" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 13:49:44 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 14:49:44 +0100 Message-ID: <1349272182.650.150.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Wed, 3 Oct 2012 14:49:42 +0100 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH] xen: point xen_start_info to a dummy struct for PV on HVM guests X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-10-03 at 14:37 +0100, Stefano Stabellini wrote: > PV on HVM guests don't have a start_info page mapped by Xen, so > xen_start_info is just NULL for them. > That is problem because other parts of the code expect xen_start_info to > point to something valid, for example xen_initial_domain() is defined as > follow: > > #define xen_initial_domain() (xen_domain() && \ > xen_start_info->flags & SIF_INITDOMAIN) But anyone who calls this before xen_start_info is setup is going to get a bogus result, specifically in this case they will think they are domU when in reality they are dom0 -- wouldn't it be better to fix those callsites? Perhaps turn this into a static inline with a BUG_ON(!xen_start_info) to make catching these cases easier? > > > Allocate a dummy start_info struct and point xen_start_info to it, as we > do on ARM. > This is not going to change things for PV guests because > xen_start_info is set by arch/x86/xen/xen-head.S:startup_xen. > > Signed-off-by: Stefano Stabellini > > diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c > index bf788d3..5f242cb 100644 > --- a/arch/x86/xen/enlighten.c > +++ b/arch/x86/xen/enlighten.c > @@ -96,7 +96,8 @@ EXPORT_SYMBOL(machine_to_phys_mapping); > unsigned long machine_to_phys_nr; > EXPORT_SYMBOL(machine_to_phys_nr); > > -struct start_info *xen_start_info; > +static struct start_info _xen_start_info; > +struct start_info *xen_start_info = &_xen_start_info; > EXPORT_SYMBOL_GPL(xen_start_info); > > struct shared_info xen_dummy_shared_info; > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 13:53:36 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 13:53:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPO8-0006NU-PP; Wed, 03 Oct 2012 13:53:24 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPO7-0006NG-4I for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 13:53:23 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1349272380!8611597!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17149 invoked from network); 3 Oct 2012 13:53:02 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 13:53:02 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="14916885" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 13:52:59 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 14:52:59 +0100 Date: Wed, 3 Oct 2012 14:51:59 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Ian Campbell In-Reply-To: <1349272182.650.150.camel@zakaz.uk.xensource.com> Message-ID: References: <1349272182.650.150.camel@zakaz.uk.xensource.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: "linux-kernel@vger.kernel.org" , Konrad Rzeszutek Wilk , "xen-devel@lists.xensource.com" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH] xen: point xen_start_info to a dummy struct for PV on HVM guests X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 3 Oct 2012, Ian Campbell wrote: > On Wed, 2012-10-03 at 14:37 +0100, Stefano Stabellini wrote: > > PV on HVM guests don't have a start_info page mapped by Xen, so > > xen_start_info is just NULL for them. > > That is problem because other parts of the code expect xen_start_info to > > point to something valid, for example xen_initial_domain() is defined as > > follow: > > > > #define xen_initial_domain() (xen_domain() && \ > > xen_start_info->flags & SIF_INITDOMAIN) > > But anyone who calls this before xen_start_info is setup is going to get > a bogus result, specifically in this case they will think they are domU > when in reality they are dom0 -- wouldn't it be better to fix those > callsites? That cannot be the case because setting up xen_start_info is the very first thing that is done, before even calling to C. > Perhaps turn this into a static inline with a BUG_ON(!xen_start_info) to > make catching these cases easier? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 13:53:36 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 13:53:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPO8-0006NU-PP; Wed, 03 Oct 2012 13:53:24 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPO7-0006NG-4I for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 13:53:23 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1349272380!8611597!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17149 invoked from network); 3 Oct 2012 13:53:02 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 13:53:02 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="14916885" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 13:52:59 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 14:52:59 +0100 Date: Wed, 3 Oct 2012 14:51:59 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Ian Campbell In-Reply-To: <1349272182.650.150.camel@zakaz.uk.xensource.com> Message-ID: References: <1349272182.650.150.camel@zakaz.uk.xensource.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: "linux-kernel@vger.kernel.org" , Konrad Rzeszutek Wilk , "xen-devel@lists.xensource.com" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH] xen: point xen_start_info to a dummy struct for PV on HVM guests X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 3 Oct 2012, Ian Campbell wrote: > On Wed, 2012-10-03 at 14:37 +0100, Stefano Stabellini wrote: > > PV on HVM guests don't have a start_info page mapped by Xen, so > > xen_start_info is just NULL for them. > > That is problem because other parts of the code expect xen_start_info to > > point to something valid, for example xen_initial_domain() is defined as > > follow: > > > > #define xen_initial_domain() (xen_domain() && \ > > xen_start_info->flags & SIF_INITDOMAIN) > > But anyone who calls this before xen_start_info is setup is going to get > a bogus result, specifically in this case they will think they are domU > when in reality they are dom0 -- wouldn't it be better to fix those > callsites? That cannot be the case because setting up xen_start_info is the very first thing that is done, before even calling to C. > Perhaps turn this into a static inline with a BUG_ON(!xen_start_info) to > make catching these cases easier? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 13:54:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 13:54:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPPS-0006TZ-8K; Wed, 03 Oct 2012 13:54:46 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPPQ-0006TQ-Uj for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 13:54:45 +0000 Received: from [85.158.143.35:48003] by server-3.bemta-4.messagelabs.com id 52/5C-10986-4A34C605; Wed, 03 Oct 2012 13:54:44 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1349272483!12886826!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21244 invoked from network); 3 Oct 2012 13:54:43 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 13:54:43 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="14916920" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 13:54:43 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 14:54:43 +0100 Message-ID: <1349272482.650.151.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Wed, 3 Oct 2012 14:54:42 +0100 In-Reply-To: References: <1349272182.650.150.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH] xen: point xen_start_info to a dummy struct for PV on HVM guests X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-10-03 at 14:51 +0100, Stefano Stabellini wrote: > On Wed, 3 Oct 2012, Ian Campbell wrote: > > On Wed, 2012-10-03 at 14:37 +0100, Stefano Stabellini wrote: > > > PV on HVM guests don't have a start_info page mapped by Xen, so > > > xen_start_info is just NULL for them. > > > That is problem because other parts of the code expect xen_start_info to > > > point to something valid, for example xen_initial_domain() is defined as > > > follow: > > > > > > #define xen_initial_domain() (xen_domain() && \ > > > xen_start_info->flags & SIF_INITDOMAIN) > > > > But anyone who calls this before xen_start_info is setup is going to get > > a bogus result, specifically in this case they will think they are domU > > when in reality they are dom0 -- wouldn't it be better to fix those > > callsites? > > That cannot be the case because setting up xen_start_info is the very > first thing that is done, before even calling to C. On PV, yes, but you are trying to fix PVHVM here, no? Otherwise if this is always set before calling into C then what is the purpose of this patch? > > > > Perhaps turn this into a static inline with a BUG_ON(!xen_start_info) to > > make catching these cases easier? > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 13:54:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 13:54:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPPS-0006TZ-8K; Wed, 03 Oct 2012 13:54:46 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPPQ-0006TQ-Uj for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 13:54:45 +0000 Received: from [85.158.143.35:48003] by server-3.bemta-4.messagelabs.com id 52/5C-10986-4A34C605; Wed, 03 Oct 2012 13:54:44 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1349272483!12886826!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21244 invoked from network); 3 Oct 2012 13:54:43 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 13:54:43 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="14916920" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 13:54:43 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 14:54:43 +0100 Message-ID: <1349272482.650.151.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Wed, 3 Oct 2012 14:54:42 +0100 In-Reply-To: References: <1349272182.650.150.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH] xen: point xen_start_info to a dummy struct for PV on HVM guests X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-10-03 at 14:51 +0100, Stefano Stabellini wrote: > On Wed, 3 Oct 2012, Ian Campbell wrote: > > On Wed, 2012-10-03 at 14:37 +0100, Stefano Stabellini wrote: > > > PV on HVM guests don't have a start_info page mapped by Xen, so > > > xen_start_info is just NULL for them. > > > That is problem because other parts of the code expect xen_start_info to > > > point to something valid, for example xen_initial_domain() is defined as > > > follow: > > > > > > #define xen_initial_domain() (xen_domain() && \ > > > xen_start_info->flags & SIF_INITDOMAIN) > > > > But anyone who calls this before xen_start_info is setup is going to get > > a bogus result, specifically in this case they will think they are domU > > when in reality they are dom0 -- wouldn't it be better to fix those > > callsites? > > That cannot be the case because setting up xen_start_info is the very > first thing that is done, before even calling to C. On PV, yes, but you are trying to fix PVHVM here, no? Otherwise if this is always set before calling into C then what is the purpose of this patch? > > > > Perhaps turn this into a static inline with a BUG_ON(!xen_start_info) to > > make catching these cases easier? > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 13:55:15 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 13:55:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPPk-0006Vq-Ky; Wed, 03 Oct 2012 13:55:04 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPPj-0006V3-Ae for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 13:55:03 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1349272495!8611806!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzgwMzQw\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22500 invoked from network); 3 Oct 2012 13:54:56 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Oct 2012 13:54:56 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q93DsnGQ008811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Oct 2012 13:54:50 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q93DslZC014775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Oct 2012 13:54:49 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q93DslDw012835; Wed, 3 Oct 2012 08:54:47 -0500 Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 03 Oct 2012 06:54:47 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 938B04032D; Wed, 3 Oct 2012 09:43:23 -0400 (EDT) Date: Wed, 3 Oct 2012 09:43:23 -0400 From: Konrad Rzeszutek Wilk To: Stefano Stabellini Message-ID: <20121003134323.GA31270@phenom.dumpdata.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org Subject: Re: [Xen-devel] [PATCH] xen: point xen_start_info to a dummy struct for PV on HVM guests X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, Oct 03, 2012 at 02:37:53PM +0100, Stefano Stabellini wrote: > PV on HVM guests don't have a start_info page mapped by Xen, so > xen_start_info is just NULL for them. > That is problem because other parts of the code expect xen_start_info to > point to something valid, for example xen_initial_domain() is defined as > follow: > > #define xen_initial_domain() (xen_domain() && \ > xen_start_info->flags & SIF_INITDOMAIN) > .. introduced by commit 4c071ee5268f7234c3d084b6093bebccc28cdcba ("arm: initial Xen support) > > Allocate a dummy start_info struct and point xen_start_info to it, as we > do on ARM. > This is not going to change things for PV guests because > xen_start_info is set by arch/x86/xen/xen-head.S:startup_xen. > > Signed-off-by: Stefano Stabellini Reported-by: Konrad Rzeszutek Wilk > > diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c > index bf788d3..5f242cb 100644 > --- a/arch/x86/xen/enlighten.c > +++ b/arch/x86/xen/enlighten.c > @@ -96,7 +96,8 @@ EXPORT_SYMBOL(machine_to_phys_mapping); > unsigned long machine_to_phys_nr; > EXPORT_SYMBOL(machine_to_phys_nr); > > -struct start_info *xen_start_info; > +static struct start_info _xen_start_info; And lets change that to 'xen_dummy_start_info' to keep in sync with the other dummy one. And also add a commnt: /* * Since 'xen_initial_domain' dereferences the xen_start_info we need * a dummy structure filled with zeros (for PVHVM guests which initialize * this late). For PV guests we do not have to worry about this as the first * few instructions (startup_xen) set it properly. */ > +struct start_info *xen_start_info = &_xen_start_info; > EXPORT_SYMBOL_GPL(xen_start_info); > > struct shared_info xen_dummy_shared_info; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 13:55:15 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 13:55:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPPk-0006Vq-Ky; Wed, 03 Oct 2012 13:55:04 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPPj-0006V3-Ae for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 13:55:03 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1349272495!8611806!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzgwMzQw\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22500 invoked from network); 3 Oct 2012 13:54:56 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Oct 2012 13:54:56 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q93DsnGQ008811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Oct 2012 13:54:50 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q93DslZC014775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Oct 2012 13:54:49 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q93DslDw012835; Wed, 3 Oct 2012 08:54:47 -0500 Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 03 Oct 2012 06:54:47 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 938B04032D; Wed, 3 Oct 2012 09:43:23 -0400 (EDT) Date: Wed, 3 Oct 2012 09:43:23 -0400 From: Konrad Rzeszutek Wilk To: Stefano Stabellini Message-ID: <20121003134323.GA31270@phenom.dumpdata.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org Subject: Re: [Xen-devel] [PATCH] xen: point xen_start_info to a dummy struct for PV on HVM guests X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, Oct 03, 2012 at 02:37:53PM +0100, Stefano Stabellini wrote: > PV on HVM guests don't have a start_info page mapped by Xen, so > xen_start_info is just NULL for them. > That is problem because other parts of the code expect xen_start_info to > point to something valid, for example xen_initial_domain() is defined as > follow: > > #define xen_initial_domain() (xen_domain() && \ > xen_start_info->flags & SIF_INITDOMAIN) > .. introduced by commit 4c071ee5268f7234c3d084b6093bebccc28cdcba ("arm: initial Xen support) > > Allocate a dummy start_info struct and point xen_start_info to it, as we > do on ARM. > This is not going to change things for PV guests because > xen_start_info is set by arch/x86/xen/xen-head.S:startup_xen. > > Signed-off-by: Stefano Stabellini Reported-by: Konrad Rzeszutek Wilk > > diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c > index bf788d3..5f242cb 100644 > --- a/arch/x86/xen/enlighten.c > +++ b/arch/x86/xen/enlighten.c > @@ -96,7 +96,8 @@ EXPORT_SYMBOL(machine_to_phys_mapping); > unsigned long machine_to_phys_nr; > EXPORT_SYMBOL(machine_to_phys_nr); > > -struct start_info *xen_start_info; > +static struct start_info _xen_start_info; And lets change that to 'xen_dummy_start_info' to keep in sync with the other dummy one. And also add a commnt: /* * Since 'xen_initial_domain' dereferences the xen_start_info we need * a dummy structure filled with zeros (for PVHVM guests which initialize * this late). For PV guests we do not have to worry about this as the first * few instructions (startup_xen) set it properly. */ > +struct start_info *xen_start_info = &_xen_start_info; > EXPORT_SYMBOL_GPL(xen_start_info); > > struct shared_info xen_dummy_shared_info; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 13:57:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 13:57:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPSE-0006jp-6z; Wed, 03 Oct 2012 13:57:38 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPSC-0006jZ-NR for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 13:57:36 +0000 Received: from [85.158.137.99:55422] by server-9.bemta-3.messagelabs.com id 5B/6F-20338-F444C605; Wed, 03 Oct 2012 13:57:35 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-3.tower-217.messagelabs.com!1349272655!15063866!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MjUwMjc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8775 invoked from network); 3 Oct 2012 13:57:35 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-3.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Oct 2012 13:57:35 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id 700302D06; Wed, 3 Oct 2012 16:57:34 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 21DB220058; Wed, 3 Oct 2012 16:57:34 +0300 (EEST) Date: Wed, 3 Oct 2012 16:57:34 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Valtteri Kiviniemi Message-ID: <20121003135734.GV8912@reaktio.net> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Konrad Rzeszutek Wilk , chris , Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.2.0, VNC connection to Windows domU causes black screen on VNC X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, Oct 03, 2012 at 04:48:33PM +0300, Valtteri Kiviniemi wrote: > 2012/10/3 Konrad Rzeszutek Wilk <[1]konrad@kernel.org> > > On Wed, Oct 3, 2012 at 9:22 AM, Valtteri Kiviniemi > <[2]kiviniemi.valtteri@gmail.com> wrote: > > Hi, > > > > Tested with realvnc and tightvnc. Realvnc just closes itself when the > > resolution changes and tightvnc just stays open with the black screen. > > > > Lets first see if this is a problem with Windows 2008 expecting > certain registers in the VGA > emulation and falling flat on its face. > > If you launch (with the same guest config - but obviously replace the > ISO), with an > Fedora or Ubuntu LiveCD - does it boot? Do you see the VNC screen > changing resolution > and all that? > > Hi, > > Same problem with Fedora-17-x86_64-Live-Desktop.iso. I after the > resolution changed the screen goes black. If I change stdvga to 1 I will > see a bit further but then the VNC client crashes and says something about > unsupported features (dont know even if it should work). > Did you try xvnc4viewer? or normal vncviewer? or virt-viewer? I usually use virt-viewer without problems.. -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 13:57:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 13:57:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPSE-0006jp-6z; Wed, 03 Oct 2012 13:57:38 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPSC-0006jZ-NR for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 13:57:36 +0000 Received: from [85.158.137.99:55422] by server-9.bemta-3.messagelabs.com id 5B/6F-20338-F444C605; Wed, 03 Oct 2012 13:57:35 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-3.tower-217.messagelabs.com!1349272655!15063866!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MjUwMjc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8775 invoked from network); 3 Oct 2012 13:57:35 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-3.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Oct 2012 13:57:35 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id 700302D06; Wed, 3 Oct 2012 16:57:34 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 21DB220058; Wed, 3 Oct 2012 16:57:34 +0300 (EEST) Date: Wed, 3 Oct 2012 16:57:34 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Valtteri Kiviniemi Message-ID: <20121003135734.GV8912@reaktio.net> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Konrad Rzeszutek Wilk , chris , Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.2.0, VNC connection to Windows domU causes black screen on VNC X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, Oct 03, 2012 at 04:48:33PM +0300, Valtteri Kiviniemi wrote: > 2012/10/3 Konrad Rzeszutek Wilk <[1]konrad@kernel.org> > > On Wed, Oct 3, 2012 at 9:22 AM, Valtteri Kiviniemi > <[2]kiviniemi.valtteri@gmail.com> wrote: > > Hi, > > > > Tested with realvnc and tightvnc. Realvnc just closes itself when the > > resolution changes and tightvnc just stays open with the black screen. > > > > Lets first see if this is a problem with Windows 2008 expecting > certain registers in the VGA > emulation and falling flat on its face. > > If you launch (with the same guest config - but obviously replace the > ISO), with an > Fedora or Ubuntu LiveCD - does it boot? Do you see the VNC screen > changing resolution > and all that? > > Hi, > > Same problem with Fedora-17-x86_64-Live-Desktop.iso. I after the > resolution changed the screen goes black. If I change stdvga to 1 I will > see a bit further but then the VNC client crashes and says something about > unsupported features (dont know even if it should work). > Did you try xvnc4viewer? or normal vncviewer? or virt-viewer? I usually use virt-viewer without problems.. -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 14:02:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 14:02:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPWN-000719-TF; Wed, 03 Oct 2012 14:01:55 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPWM-00070y-P6 for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 14:01:54 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1349272907!8696527!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23797 invoked from network); 3 Oct 2012 14:01:48 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 14:01:48 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="14917150" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 14:01:46 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 15:01:46 +0100 Date: Wed, 3 Oct 2012 15:00:46 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Anthony Liguori Message-ID: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: Anthony.Perard@citrix.com, xen-devel@lists.xensource.com, Xudong Hao , qemu-devel@nongnu.org, Stefano Stabellini Subject: [Xen-devel] [PULL] Xen tree 2012-10-03 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hi Anthony, please pull from the following tree based on e744c06fca438dc08271e626034e632a270c91c8: git://xenbits.xen.org/people/sstabellini/qemu-dm.git xen-2012-10-03 Anthony PERARD (6): xen: Fix, no unplug of pt device by platform device. QMP, Introduce xen-set-global-dirty-log command. xen: Introduce xen_modified_memory. exec: Introduce helper to set dirty flags. exec, memory: Call to xen_modified_memory. xen: Set the vram dirty when an error occur. Xudong Hao (1): qemu/xen: Add 64 bits big bar support on qemu exec-obsolete.h | 2 + exec.c | 53 ++++++++++++++++------------------------------- hw/xen.h | 1 + hw/xen_platform.c | 8 +++++- hw/xen_pt.c | 7 ++++- hw/xen_pt_config_init.c | 39 +++++++++++++++++++++++----------- qapi-schema.json | 13 +++++++++++ qmp-commands.hx | 24 +++++++++++++++++++++ xen-all.c | 39 +++++++++++++++++++++++++++++++++- xen-stub.c | 9 ++++++++ 10 files changed, 142 insertions(+), 53 deletions(-) Cheers, Stefano _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 14:02:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 14:02:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPWN-000719-TF; Wed, 03 Oct 2012 14:01:55 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPWM-00070y-P6 for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 14:01:54 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1349272907!8696527!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23797 invoked from network); 3 Oct 2012 14:01:48 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 14:01:48 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="14917150" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 14:01:46 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 15:01:46 +0100 Date: Wed, 3 Oct 2012 15:00:46 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Anthony Liguori Message-ID: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: Anthony.Perard@citrix.com, xen-devel@lists.xensource.com, Xudong Hao , qemu-devel@nongnu.org, Stefano Stabellini Subject: [Xen-devel] [PULL] Xen tree 2012-10-03 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hi Anthony, please pull from the following tree based on e744c06fca438dc08271e626034e632a270c91c8: git://xenbits.xen.org/people/sstabellini/qemu-dm.git xen-2012-10-03 Anthony PERARD (6): xen: Fix, no unplug of pt device by platform device. QMP, Introduce xen-set-global-dirty-log command. xen: Introduce xen_modified_memory. exec: Introduce helper to set dirty flags. exec, memory: Call to xen_modified_memory. xen: Set the vram dirty when an error occur. Xudong Hao (1): qemu/xen: Add 64 bits big bar support on qemu exec-obsolete.h | 2 + exec.c | 53 ++++++++++++++++------------------------------- hw/xen.h | 1 + hw/xen_platform.c | 8 +++++- hw/xen_pt.c | 7 ++++- hw/xen_pt_config_init.c | 39 +++++++++++++++++++++++----------- qapi-schema.json | 13 +++++++++++ qmp-commands.hx | 24 +++++++++++++++++++++ xen-all.c | 39 +++++++++++++++++++++++++++++++++- xen-stub.c | 9 ++++++++ 10 files changed, 142 insertions(+), 53 deletions(-) Cheers, Stefano _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 14:04:14 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 14:04:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPYT-0007AK-Dj; Wed, 03 Oct 2012 14:04:05 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPYR-0007AF-BT for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 14:04:03 +0000 Received: from [85.158.143.35:20159] by server-1.bemta-4.messagelabs.com id 6C/B7-05684-2D54C605; Wed, 03 Oct 2012 14:04:02 +0000 X-Env-Sender: fantonifabio@tiscali.it X-Msg-Ref: server-15.tower-21.messagelabs.com!1349273041!16168252!1 X-Originating-IP: [94.23.245.208] X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 607 invoked from network); 3 Oct 2012 14:04:01 -0000 Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208) by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Oct 2012 14:04:01 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by lnx3.fantu.it (Postfix) with ESMTP id EDCC84012DE; Wed, 3 Oct 2012 16:04:00 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it Received: from lnx3.fantu.it ([127.0.0.1]) by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id geRxQv3H-X1h; Wed, 3 Oct 2012 16:04:00 +0200 (CEST) Received: from [192.168.178.50] (host51-78-dynamic.2-87-r.retail.telecomitalia.it [87.2.78.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: prova@fantu.it) by lnx3.fantu.it (Postfix) with ESMTPSA id 902A04012B5; Wed, 3 Oct 2012 16:03:59 +0200 (CEST) Message-ID: <506C45CA.30909@tiscali.it> Date: Wed, 03 Oct 2012 16:03:54 +0200 From: Fabio Fantoni User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: George Dunlap References: <506AB70D.90908@tiscali.it> <506ABADC.5090400@laukamp.me> <506ABCA1.5010602@tiscali.it> <506AC344.7070704@laukamp.me> <506BF6C0.8020104@tiscali.it> In-Reply-To: Cc: xen-devel , Lukas Laukamp Subject: Re: [Xen-devel] Unable to install Precise domU PV on xen 4.2.0 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: fantonifabio@tiscali.it List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6758306968124962251==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Questo è un messaggio firmato digitalmente in formato MIME. --===============6758306968124962251== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000601070807000409060600" Questo è un messaggio firmato digitalmente in formato MIME. --------------ms000601070807000409060600 Content-Type: multipart/alternative; boundary="------------010809060407020606030108" This is a multi-part message in MIME format. --------------010809060407020606030108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Il 03/10/2012 15:16, George Dunlap ha scritto: > On Wed, Oct 3, 2012 at 9:26 AM, Fabio Fantoni = wrote: > >> ----------------------------------------------------------------------= ------------------------- >> /var/log/xen/bootloader.9.log >> ----------------------------------------------------------------------= ------------------------- >> Traceback (most recent call last): >> File "/usr/lib/xen/bin/pygrub", line 20, in >> import xen.lowlevel.xc >> ImportError: No module named xen.lowlevel.xc >> ----------------------------------------------------------------------= ------------------------- > I haven't looked at the rest of this thread in detail; but this kind > of error is typically because of a bug with how debian's python > installer places binaries if it's given a "--prefix" argument. But it > seems like if the bootloader was failing, it should have a different > set of error messages. > > Can you try the attached patch to see if it changes anything? > > -George > > > ----- > Nessun virus nel messaggio. > Controllato da AVG - www.avg.com > Versione: 2012.0.2221 / Database dei virus: 2441/5306 - Data di rilasc= io: 02/10/2012 Before read this mail I found this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D588811 I applied the patch from debian package: tools-pygrub-remove-static-solaris-support And now PV domUs start correctly with pygrub I have seen that there are lot of patches on xen debian package,=20 probably some of these are useful to apply in upstream, for example I=20 see some bugfix and improvement on init scripts about xl, json, output=20 of failed save/restore ecc... What do you think about that? --------------010809060407020606030108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Il 03/10/2012 15:16, George Dunlap ha scritto:
On Wed, Oct 3, 2012 at 9:26 AM, Fabio Fantoni <=
fantonifabio@tiscali.it> wrote:


--------------------------------------------------=
---------------------------------------------
/var/log/xen/bootloader.9.log
-------------------------------------------------------------------------=
----------------------
Traceback (most recent call last):
  File "/usr/lib/xen/bin/pygrub", line 20, in <module>
    import xen.lowlevel.xc
ImportError: No module named xen.lowlevel.xc
-------------------------------------------------------------------------=
----------------------

I haven't looked at the rest of this thread in detail; but this kind
of error is typically because of a bug with how debian's python
installer places binaries if it's given a "--prefix" argument.  But it
seems like if the bootloader was failing, it should have a different
set of error messages.

Can you try the attached patch to see if it changes anything?

 -George



-----
Nessun virus nel messaggio.
Controllato da AVG - www.avg.com
Versione: 2012.0.2221 / Database dei virus: 2441/5306 -  Data di rilascio=
: 02/10/2012
Before read this mail I found this:
http://bugs.debian.org/cgi-bin/bugreport= =2Ecgi?bug=3D588811
I applied the patch from debian package:
tools-pygrub-remove-static-solaris-support
And now PV domUs start correctly with pygrub
I have seen that there are lot of patches on xen debian package, probably some of these are useful to apply in upstream, for example I see some bugfix and improvement on init scripts about xl, json, output of failed save/restore ecc...
What do you think about that?
--------------010809060407020606030108-- --------------ms000601070807000409060600 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: Firma crittografica S/MIME MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi 8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y 2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT +HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC 0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV 10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2 YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8 h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1 kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8 oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+ qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1 XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTEyMTAwMzE0MDM1NFowIwYJKoZIhvcNAQkEMRYEFIDRjbSCb+f3bz44ibrq9iGT GFsxMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAHR6W8vIhkwrPQnGU/n/7yYMC RpP79Cuoh6Xsy1x8O30Y6cIIx+dg/aMjwFJ39lZyKsu5/kdhFzqzBT/Upf1GtHZ1DmNEauUN jPQMu7BWVdJJIs2/v4gDRPOZK0K8k5GsBVN7paYevBW8AxCfQPIfdgcfltHAdrf2+MBPgmWo 1dYhtzw+zHE2D6qMbxaXkRdpfoGDkOFpUbdkYKjXB3ZK7eX7+qfp/j6JmG82UHrkvwtpPlH0 qsyjd65GQ6v8yHTQpsSTLnSqmdYcXeZ1q3ABzvkTuKXV/O4+cwz34i2GGwgtCJeHxaWGmXi7 0Abe8yiE/uQT/lpTEm1CDaQCHyF6uQAAAAAAAA== --------------ms000601070807000409060600-- --===============6758306968124962251== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6758306968124962251==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 14:04:14 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 14:04:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPYT-0007AK-Dj; Wed, 03 Oct 2012 14:04:05 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPYR-0007AF-BT for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 14:04:03 +0000 Received: from [85.158.143.35:20159] by server-1.bemta-4.messagelabs.com id 6C/B7-05684-2D54C605; Wed, 03 Oct 2012 14:04:02 +0000 X-Env-Sender: fantonifabio@tiscali.it X-Msg-Ref: server-15.tower-21.messagelabs.com!1349273041!16168252!1 X-Originating-IP: [94.23.245.208] X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 607 invoked from network); 3 Oct 2012 14:04:01 -0000 Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208) by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Oct 2012 14:04:01 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by lnx3.fantu.it (Postfix) with ESMTP id EDCC84012DE; Wed, 3 Oct 2012 16:04:00 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it Received: from lnx3.fantu.it ([127.0.0.1]) by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id geRxQv3H-X1h; Wed, 3 Oct 2012 16:04:00 +0200 (CEST) Received: from [192.168.178.50] (host51-78-dynamic.2-87-r.retail.telecomitalia.it [87.2.78.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: prova@fantu.it) by lnx3.fantu.it (Postfix) with ESMTPSA id 902A04012B5; Wed, 3 Oct 2012 16:03:59 +0200 (CEST) Message-ID: <506C45CA.30909@tiscali.it> Date: Wed, 03 Oct 2012 16:03:54 +0200 From: Fabio Fantoni User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: George Dunlap References: <506AB70D.90908@tiscali.it> <506ABADC.5090400@laukamp.me> <506ABCA1.5010602@tiscali.it> <506AC344.7070704@laukamp.me> <506BF6C0.8020104@tiscali.it> In-Reply-To: Cc: xen-devel , Lukas Laukamp Subject: Re: [Xen-devel] Unable to install Precise domU PV on xen 4.2.0 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: fantonifabio@tiscali.it List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6758306968124962251==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Questo è un messaggio firmato digitalmente in formato MIME. --===============6758306968124962251== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000601070807000409060600" Questo è un messaggio firmato digitalmente in formato MIME. --------------ms000601070807000409060600 Content-Type: multipart/alternative; boundary="------------010809060407020606030108" This is a multi-part message in MIME format. --------------010809060407020606030108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Il 03/10/2012 15:16, George Dunlap ha scritto: > On Wed, Oct 3, 2012 at 9:26 AM, Fabio Fantoni = wrote: > >> ----------------------------------------------------------------------= ------------------------- >> /var/log/xen/bootloader.9.log >> ----------------------------------------------------------------------= ------------------------- >> Traceback (most recent call last): >> File "/usr/lib/xen/bin/pygrub", line 20, in >> import xen.lowlevel.xc >> ImportError: No module named xen.lowlevel.xc >> ----------------------------------------------------------------------= ------------------------- > I haven't looked at the rest of this thread in detail; but this kind > of error is typically because of a bug with how debian's python > installer places binaries if it's given a "--prefix" argument. But it > seems like if the bootloader was failing, it should have a different > set of error messages. > > Can you try the attached patch to see if it changes anything? > > -George > > > ----- > Nessun virus nel messaggio. > Controllato da AVG - www.avg.com > Versione: 2012.0.2221 / Database dei virus: 2441/5306 - Data di rilasc= io: 02/10/2012 Before read this mail I found this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D588811 I applied the patch from debian package: tools-pygrub-remove-static-solaris-support And now PV domUs start correctly with pygrub I have seen that there are lot of patches on xen debian package,=20 probably some of these are useful to apply in upstream, for example I=20 see some bugfix and improvement on init scripts about xl, json, output=20 of failed save/restore ecc... What do you think about that? --------------010809060407020606030108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Il 03/10/2012 15:16, George Dunlap ha scritto:
On Wed, Oct 3, 2012 at 9:26 AM, Fabio Fantoni <=
fantonifabio@tiscali.it> wrote:


--------------------------------------------------=
---------------------------------------------
/var/log/xen/bootloader.9.log
-------------------------------------------------------------------------=
----------------------
Traceback (most recent call last):
  File "/usr/lib/xen/bin/pygrub", line 20, in <module>
    import xen.lowlevel.xc
ImportError: No module named xen.lowlevel.xc
-------------------------------------------------------------------------=
----------------------

I haven't looked at the rest of this thread in detail; but this kind
of error is typically because of a bug with how debian's python
installer places binaries if it's given a "--prefix" argument.  But it
seems like if the bootloader was failing, it should have a different
set of error messages.

Can you try the attached patch to see if it changes anything?

 -George



-----
Nessun virus nel messaggio.
Controllato da AVG - www.avg.com
Versione: 2012.0.2221 / Database dei virus: 2441/5306 -  Data di rilascio=
: 02/10/2012
Before read this mail I found this:
http://bugs.debian.org/cgi-bin/bugreport= =2Ecgi?bug=3D588811
I applied the patch from debian package:
tools-pygrub-remove-static-solaris-support
And now PV domUs start correctly with pygrub
I have seen that there are lot of patches on xen debian package, probably some of these are useful to apply in upstream, for example I see some bugfix and improvement on init scripts about xl, json, output of failed save/restore ecc...
What do you think about that?
--------------010809060407020606030108-- --------------ms000601070807000409060600 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: Firma crittografica S/MIME MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi 8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y 2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT +HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC 0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV 10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2 YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8 h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1 kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8 oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+ qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1 XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTEyMTAwMzE0MDM1NFowIwYJKoZIhvcNAQkEMRYEFIDRjbSCb+f3bz44ibrq9iGT GFsxMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAHR6W8vIhkwrPQnGU/n/7yYMC RpP79Cuoh6Xsy1x8O30Y6cIIx+dg/aMjwFJ39lZyKsu5/kdhFzqzBT/Upf1GtHZ1DmNEauUN jPQMu7BWVdJJIs2/v4gDRPOZK0K8k5GsBVN7paYevBW8AxCfQPIfdgcfltHAdrf2+MBPgmWo 1dYhtzw+zHE2D6qMbxaXkRdpfoGDkOFpUbdkYKjXB3ZK7eX7+qfp/j6JmG82UHrkvwtpPlH0 qsyjd65GQ6v8yHTQpsSTLnSqmdYcXeZ1q3ABzvkTuKXV/O4+cwz34i2GGwgtCJeHxaWGmXi7 0Abe8yiE/uQT/lpTEm1CDaQCHyF6uQAAAAAAAA== --------------ms000601070807000409060600-- --===============6758306968124962251== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6758306968124962251==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 14:11:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 14:11:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPfe-0007Xd-4y; Wed, 03 Oct 2012 14:11:30 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPfc-0007XO-Fu for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 14:11:28 +0000 Received: from [85.158.143.99:7459] by server-2.bemta-4.messagelabs.com id F9/7E-06610-F874C605; Wed, 03 Oct 2012 14:11:27 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1349273485!27432279!1 X-Originating-IP: [209.85.160.173] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2549 invoked from network); 3 Oct 2012 14:11:26 -0000 Received: from mail-gh0-f173.google.com (HELO mail-gh0-f173.google.com) (209.85.160.173) by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 14:11:26 -0000 Received: by ghy16 with SMTP id 16so2241196ghy.32 for ; Wed, 03 Oct 2012 07:11:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a3shOPqAHtQ298HLUaUEbldGW+Ekf2ZiunoUmJ08jp8=; b=eQnhgz4zgfx1uAvvUdz1J3mUz6PtKP4sfUlFwN+/r8P6msADqJlZXXd7INEkXvateN d56Low605S3gZcmbk4w7pQonI4GjAoUWOP+0ZYdcJLerXODtSXsuwWkd9F5qYqcnOLul KsYvKxvRJtdZP5FFlG9nD/0F5gnzTQKVUH0mqSj6dc+UHPrn3dCndQa6VYAahsFgYZiy 0+e26/jZKG7lZaexAoP1Zqu3/1RS8EAqhivyJuVbPZjn6L1V056sriJ5tJENLGa66wwJ fZSSC+oEdVxEVPQZHwVPwQUW+RFEWoZyLsKqq/UFDnAkOQmgiBxqKMxefzQEoOpfkhDL 4g2A== MIME-Version: 1.0 Received: by 10.236.77.7 with SMTP id c7mr2034033yhe.2.1349273485103; Wed, 03 Oct 2012 07:11:25 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Wed, 3 Oct 2012 07:11:25 -0700 (PDT) In-Reply-To: <20121003135734.GV8912@reaktio.net> References: <20121003135734.GV8912@reaktio.net> Date: Wed, 3 Oct 2012 17:11:25 +0300 Message-ID: From: Valtteri Kiviniemi To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= Cc: Konrad Rzeszutek Wilk , chris , Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.2.0, VNC connection to Windows domU causes black screen on VNC X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8964677685598377072==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============8964677685598377072== Content-Type: multipart/alternative; boundary=20cf300514bac8d13504cb2836ac --20cf300514bac8d13504cb2836ac Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/10/3 Pasi K=E4rkk=E4inen > On Wed, Oct 03, 2012 at 04:48:33PM +0300, Valtteri Kiviniemi wrote: > > 2012/10/3 Konrad Rzeszutek Wilk <[1]konrad@kernel.org> > > > > On Wed, Oct 3, 2012 at 9:22 AM, Valtteri Kiviniemi > > <[2]kiviniemi.valtteri@gmail.com> wrote: > > > Hi, > > > > > > Tested with realvnc and tightvnc. Realvnc just closes itself whe= n > the > > > resolution changes and tightvnc just stays open with the black > screen. > > > > > > > Lets first see if this is a problem with Windows 2008 expecting > > certain registers in the VGA > > emulation and falling flat on its face. > > > > If you launch (with the same guest config - but obviously replace > the > > ISO), with an > > Fedora or Ubuntu LiveCD - does it boot? Do you see the VNC screen > > changing resolution > > and all that? > > > > Hi, > > > > Same problem with Fedora-17-x86_64-Live-Desktop.iso. I after the > > resolution changed the screen goes black. If I change stdvga to 1 I > will > > see a bit further but then the VNC client crashes and says something > about > > unsupported features (dont know even if it should work). > > > > Did you try xvnc4viewer? or normal vncviewer? or virt-viewer? > I usually use virt-viewer without problems.. > > -- Pasi > > Hi, I'm using Windows 7 in my desktop-computer, so I have not tested any other vnc clients than ultravnc or tightvnc. I can of course test others too if there is windows binary available. - Valtteri --20cf300514bac8d13504cb2836ac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/10/3 Pasi K=E4rkk=E4inen <pasik@iki.fi= >
On Wed, Oct 03, 2012 at 04:48:33PM +0300, Valtteri Kiviniemi wrote:
> =A0 =A02012/10/3 Konrad Rzeszutek Wilk <[1]konrad@kernel.org>
>
> =A0 =A0 =A0On Wed, Oct 3, 2012 at 9:22 AM, Valtteri Kiviniemi
> =A0 =A0 =A0<[2]kiviniemi.valtteri@gmail.com> wrote:
> =A0 =A0 =A0> Hi,
> =A0 =A0 =A0>
> =A0 =A0 =A0> Tested with realvnc and tightvnc. Realvnc just closes = itself when the
> =A0 =A0 =A0> resolution changes and tightvnc just stays open with t= he black screen.
> =A0 =A0 =A0>
>
> =A0 =A0 =A0Lets first see if this is a problem with Windows 2008 expec= ting
> =A0 =A0 =A0certain registers in the VGA
> =A0 =A0 =A0emulation and falling flat on its face.
>
> =A0 =A0 =A0If you launch (with the same guest config - but obviously r= eplace the
> =A0 =A0 =A0ISO), with an
> =A0 =A0 =A0Fedora or Ubuntu LiveCD - does it boot? Do you see the VNC = screen
> =A0 =A0 =A0changing resolution
> =A0 =A0 =A0and all that?
>
> =A0 =A0Hi,
>
> =A0 =A0Same problem with Fedora-17-x86_64-Live-Desktop.iso. I after th= e
> =A0 =A0resolution changed the screen goes black. If I change stdvga to= 1 I will
> =A0 =A0see a bit further but then the VNC client crashes and says some= thing about
> =A0 =A0unsupported features (dont know even if it should work).
>

Did you try xvnc4viewer? or normal vncviewer? or virt-viewer?
I usually use virt-viewer without problems..

-- Pasi


Hi,

I'm using Windows 7 = in my desktop-computer, so I have not tested any other vnc clients than ult= ravnc or tightvnc. I can of course test others too if there is windows bina= ry available.

- Valtteri
--20cf300514bac8d13504cb2836ac-- --===============8964677685598377072== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8964677685598377072==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 14:11:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 14:11:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPfe-0007Xd-4y; Wed, 03 Oct 2012 14:11:30 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPfc-0007XO-Fu for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 14:11:28 +0000 Received: from [85.158.143.99:7459] by server-2.bemta-4.messagelabs.com id F9/7E-06610-F874C605; Wed, 03 Oct 2012 14:11:27 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1349273485!27432279!1 X-Originating-IP: [209.85.160.173] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2549 invoked from network); 3 Oct 2012 14:11:26 -0000 Received: from mail-gh0-f173.google.com (HELO mail-gh0-f173.google.com) (209.85.160.173) by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 14:11:26 -0000 Received: by ghy16 with SMTP id 16so2241196ghy.32 for ; Wed, 03 Oct 2012 07:11:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a3shOPqAHtQ298HLUaUEbldGW+Ekf2ZiunoUmJ08jp8=; b=eQnhgz4zgfx1uAvvUdz1J3mUz6PtKP4sfUlFwN+/r8P6msADqJlZXXd7INEkXvateN d56Low605S3gZcmbk4w7pQonI4GjAoUWOP+0ZYdcJLerXODtSXsuwWkd9F5qYqcnOLul KsYvKxvRJtdZP5FFlG9nD/0F5gnzTQKVUH0mqSj6dc+UHPrn3dCndQa6VYAahsFgYZiy 0+e26/jZKG7lZaexAoP1Zqu3/1RS8EAqhivyJuVbPZjn6L1V056sriJ5tJENLGa66wwJ fZSSC+oEdVxEVPQZHwVPwQUW+RFEWoZyLsKqq/UFDnAkOQmgiBxqKMxefzQEoOpfkhDL 4g2A== MIME-Version: 1.0 Received: by 10.236.77.7 with SMTP id c7mr2034033yhe.2.1349273485103; Wed, 03 Oct 2012 07:11:25 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Wed, 3 Oct 2012 07:11:25 -0700 (PDT) In-Reply-To: <20121003135734.GV8912@reaktio.net> References: <20121003135734.GV8912@reaktio.net> Date: Wed, 3 Oct 2012 17:11:25 +0300 Message-ID: From: Valtteri Kiviniemi To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= Cc: Konrad Rzeszutek Wilk , chris , Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.2.0, VNC connection to Windows domU causes black screen on VNC X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8964677685598377072==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============8964677685598377072== Content-Type: multipart/alternative; boundary=20cf300514bac8d13504cb2836ac --20cf300514bac8d13504cb2836ac Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/10/3 Pasi K=E4rkk=E4inen > On Wed, Oct 03, 2012 at 04:48:33PM +0300, Valtteri Kiviniemi wrote: > > 2012/10/3 Konrad Rzeszutek Wilk <[1]konrad@kernel.org> > > > > On Wed, Oct 3, 2012 at 9:22 AM, Valtteri Kiviniemi > > <[2]kiviniemi.valtteri@gmail.com> wrote: > > > Hi, > > > > > > Tested with realvnc and tightvnc. Realvnc just closes itself whe= n > the > > > resolution changes and tightvnc just stays open with the black > screen. > > > > > > > Lets first see if this is a problem with Windows 2008 expecting > > certain registers in the VGA > > emulation and falling flat on its face. > > > > If you launch (with the same guest config - but obviously replace > the > > ISO), with an > > Fedora or Ubuntu LiveCD - does it boot? Do you see the VNC screen > > changing resolution > > and all that? > > > > Hi, > > > > Same problem with Fedora-17-x86_64-Live-Desktop.iso. I after the > > resolution changed the screen goes black. If I change stdvga to 1 I > will > > see a bit further but then the VNC client crashes and says something > about > > unsupported features (dont know even if it should work). > > > > Did you try xvnc4viewer? or normal vncviewer? or virt-viewer? > I usually use virt-viewer without problems.. > > -- Pasi > > Hi, I'm using Windows 7 in my desktop-computer, so I have not tested any other vnc clients than ultravnc or tightvnc. I can of course test others too if there is windows binary available. - Valtteri --20cf300514bac8d13504cb2836ac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/10/3 Pasi K=E4rkk=E4inen <pasik@iki.fi= >
On Wed, Oct 03, 2012 at 04:48:33PM +0300, Valtteri Kiviniemi wrote:
> =A0 =A02012/10/3 Konrad Rzeszutek Wilk <[1]konrad@kernel.org>
>
> =A0 =A0 =A0On Wed, Oct 3, 2012 at 9:22 AM, Valtteri Kiviniemi
> =A0 =A0 =A0<[2]kiviniemi.valtteri@gmail.com> wrote:
> =A0 =A0 =A0> Hi,
> =A0 =A0 =A0>
> =A0 =A0 =A0> Tested with realvnc and tightvnc. Realvnc just closes = itself when the
> =A0 =A0 =A0> resolution changes and tightvnc just stays open with t= he black screen.
> =A0 =A0 =A0>
>
> =A0 =A0 =A0Lets first see if this is a problem with Windows 2008 expec= ting
> =A0 =A0 =A0certain registers in the VGA
> =A0 =A0 =A0emulation and falling flat on its face.
>
> =A0 =A0 =A0If you launch (with the same guest config - but obviously r= eplace the
> =A0 =A0 =A0ISO), with an
> =A0 =A0 =A0Fedora or Ubuntu LiveCD - does it boot? Do you see the VNC = screen
> =A0 =A0 =A0changing resolution
> =A0 =A0 =A0and all that?
>
> =A0 =A0Hi,
>
> =A0 =A0Same problem with Fedora-17-x86_64-Live-Desktop.iso. I after th= e
> =A0 =A0resolution changed the screen goes black. If I change stdvga to= 1 I will
> =A0 =A0see a bit further but then the VNC client crashes and says some= thing about
> =A0 =A0unsupported features (dont know even if it should work).
>

Did you try xvnc4viewer? or normal vncviewer? or virt-viewer?
I usually use virt-viewer without problems..

-- Pasi


Hi,

I'm using Windows 7 = in my desktop-computer, so I have not tested any other vnc clients than ult= ravnc or tightvnc. I can of course test others too if there is windows bina= ry available.

- Valtteri
--20cf300514bac8d13504cb2836ac-- --===============8964677685598377072== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8964677685598377072==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 14:19:23 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 14:19:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPmz-0007q0-36; Wed, 03 Oct 2012 14:19:05 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPmx-0007ps-UG for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 14:19:04 +0000 Received: from [85.158.138.51:45981] by server-16.bemta-3.messagelabs.com id 06/D1-09129-7594C605; Wed, 03 Oct 2012 14:19:03 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1349273940!25351073!1 X-Originating-IP: [209.85.213.173] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10062 invoked from network); 3 Oct 2012 14:19:01 -0000 Received: from mail-yx0-f173.google.com (HELO mail-yx0-f173.google.com) (209.85.213.173) by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 14:19:01 -0000 Received: by yenl3 with SMTP id l3so2245970yen.32 for ; Wed, 03 Oct 2012 07:19:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZvqvSmlOcZ4XIbDkykJQgls6+gZNF9zQ2GeM7SX499M=; b=NK2unImJEiKu+ikMLxZUYhoZ9Mqu8et12lskqQMrEaJ0Ivp+kIwqgdFwjCMVOA89x8 vILFQfOuMHhbHJKHyLAzgancsLPnz9B9Zeg+GdRU/0eSm6Fl1gK3ofKshKElrrEaVeEf wS8t3tk+iKnnzmocfi9pX+xr/f6SJg6YKZD41MLNiLhoE7NUrIq3KGHsBOURzbplGVwP z38rpKDz7i7EvvLMB6A906u/dOmXWZp8krPHAydXaRPMDDuD94PeHxwrmUh/gWYpFhoA STw9WWWRGGjfRN7YYIAp1qFsHRzdz3DGqGAYja/4NAXn94aBKFxetQPWRNjEli5o5OEb rQtA== MIME-Version: 1.0 Received: by 10.236.193.105 with SMTP id j69mr2025986yhn.21.1349273940452; Wed, 03 Oct 2012 07:19:00 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Wed, 3 Oct 2012 07:19:00 -0700 (PDT) In-Reply-To: References: <20121003135734.GV8912@reaktio.net> Date: Wed, 3 Oct 2012 17:19:00 +0300 Message-ID: From: Valtteri Kiviniemi To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= Cc: Konrad Rzeszutek Wilk , chris , Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.2.0, VNC connection to Windows domU causes black screen on VNC X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2668418657308039017==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============2668418657308039017== Content-Type: multipart/alternative; boundary=20cf30563c0dece79e04cb2851e3 --20cf30563c0dece79e04cb2851e3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/10/3 Valtteri Kiviniemi > > > 2012/10/3 Pasi K=E4rkk=E4inen > >> On Wed, Oct 03, 2012 at 04:48:33PM +0300, Valtteri Kiviniemi wrote: >> > 2012/10/3 Konrad Rzeszutek Wilk <[1]konrad@kernel.org> >> > >> > On Wed, Oct 3, 2012 at 9:22 AM, Valtteri Kiviniemi >> > <[2]kiviniemi.valtteri@gmail.com> wrote: >> > > Hi, >> > > >> > > Tested with realvnc and tightvnc. Realvnc just closes itself >> when the >> > > resolution changes and tightvnc just stays open with the black >> screen. >> > > >> > >> > Lets first see if this is a problem with Windows 2008 expecting >> > certain registers in the VGA >> > emulation and falling flat on its face. >> > >> > If you launch (with the same guest config - but obviously replace >> the >> > ISO), with an >> > Fedora or Ubuntu LiveCD - does it boot? Do you see the VNC screen >> > changing resolution >> > and all that? >> > >> > Hi, >> > >> > Same problem with Fedora-17-x86_64-Live-Desktop.iso. I after the >> > resolution changed the screen goes black. If I change stdvga to 1 I >> will >> > see a bit further but then the VNC client crashes and says somethin= g >> about >> > unsupported features (dont know even if it should work). >> > >> >> Did you try xvnc4viewer? or normal vncviewer? or virt-viewer? >> I usually use virt-viewer without problems.. >> >> -- Pasi >> >> > Hi, > > I'm using Windows 7 in my desktop-computer, so I have not tested any othe= r > vnc clients than ultravnc or tightvnc. I can of course test others too if > there is windows binary available. > > - Valtteri > Hi, Good news, I got it working. It seems that for some reason the encoding has to be RAW and stdvga has to be enabled. This is strange since this same config and setup is working on different hardware. But now I'm able to see the VNC output. - Valtteri --20cf30563c0dece79e04cb2851e3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/10/3 Valtteri Kiviniemi <kiviniemi.valtteri@gmail.com>


2012/10/3 Pasi K= =E4rkk=E4inen <pasik@iki.fi>
On Wed, Oct 03, 2012 at 04:48:33PM +0300, Valtteri Kiviniemi wrote:
> =A0 =A02012/10/3 Konrad Rzeszutek Wilk <[1]konrad@kernel.org>
>
> =A0 =A0 =A0On Wed, Oct 3, 2012 at 9:22 AM, Valtteri Kiviniemi
> =A0 =A0 =A0<[2]kiviniemi.valtteri@gmail.com> wrote:
> =A0 =A0 =A0> Hi,
> =A0 =A0 =A0>
> =A0 =A0 =A0> Tested with realvnc and tightvnc. Realvnc just closes = itself when the
> =A0 =A0 =A0> resolution changes and tightvnc just stays open with t= he black screen.
> =A0 =A0 =A0>
>
> =A0 =A0 =A0Lets first see if this is a problem with Windows 2008 expec= ting
> =A0 =A0 =A0certain registers in the VGA
> =A0 =A0 =A0emulation and falling flat on its face.
>
> =A0 =A0 =A0If you launch (with the same guest config - but obviously r= eplace the
> =A0 =A0 =A0ISO), with an
> =A0 =A0 =A0Fedora or Ubuntu LiveCD - does it boot? Do you see the VNC = screen
> =A0 =A0 =A0changing resolution
> =A0 =A0 =A0and all that?
>
> =A0 =A0Hi,
>
> =A0 =A0Same problem with Fedora-17-x86_64-Live-Desktop.iso. I after th= e
> =A0 =A0resolution changed the screen goes black. If I change stdvga to= 1 I will
> =A0 =A0see a bit further but then the VNC client crashes and says some= thing about
> =A0 =A0unsupported features (dont know even if it should work).
>

Did you try xvnc4viewer? or normal vncviewer? or virt-viewer?
I usually use virt-viewer without problems..

-- Pasi


Hi,

I'm usin= g Windows 7 in my desktop-computer, so I have not tested any other vnc clie= nts than ultravnc or tightvnc. I can of course test others too if there is = windows binary available.
- Valtteri

Hi,
<= br>Good news, I got it working. It seems that for some reason the encoding = has to be RAW and stdvga has to be enabled. This is strange since this same= config and setup is working on different hardware. But now I'm able to= see the VNC output.

- Valtteri

--20cf30563c0dece79e04cb2851e3-- --===============2668418657308039017== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============2668418657308039017==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 14:19:23 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 14:19:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPmz-0007q0-36; Wed, 03 Oct 2012 14:19:05 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPmx-0007ps-UG for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 14:19:04 +0000 Received: from [85.158.138.51:45981] by server-16.bemta-3.messagelabs.com id 06/D1-09129-7594C605; Wed, 03 Oct 2012 14:19:03 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1349273940!25351073!1 X-Originating-IP: [209.85.213.173] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10062 invoked from network); 3 Oct 2012 14:19:01 -0000 Received: from mail-yx0-f173.google.com (HELO mail-yx0-f173.google.com) (209.85.213.173) by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 14:19:01 -0000 Received: by yenl3 with SMTP id l3so2245970yen.32 for ; Wed, 03 Oct 2012 07:19:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZvqvSmlOcZ4XIbDkykJQgls6+gZNF9zQ2GeM7SX499M=; b=NK2unImJEiKu+ikMLxZUYhoZ9Mqu8et12lskqQMrEaJ0Ivp+kIwqgdFwjCMVOA89x8 vILFQfOuMHhbHJKHyLAzgancsLPnz9B9Zeg+GdRU/0eSm6Fl1gK3ofKshKElrrEaVeEf wS8t3tk+iKnnzmocfi9pX+xr/f6SJg6YKZD41MLNiLhoE7NUrIq3KGHsBOURzbplGVwP z38rpKDz7i7EvvLMB6A906u/dOmXWZp8krPHAydXaRPMDDuD94PeHxwrmUh/gWYpFhoA STw9WWWRGGjfRN7YYIAp1qFsHRzdz3DGqGAYja/4NAXn94aBKFxetQPWRNjEli5o5OEb rQtA== MIME-Version: 1.0 Received: by 10.236.193.105 with SMTP id j69mr2025986yhn.21.1349273940452; Wed, 03 Oct 2012 07:19:00 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Wed, 3 Oct 2012 07:19:00 -0700 (PDT) In-Reply-To: References: <20121003135734.GV8912@reaktio.net> Date: Wed, 3 Oct 2012 17:19:00 +0300 Message-ID: From: Valtteri Kiviniemi To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= Cc: Konrad Rzeszutek Wilk , chris , Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.2.0, VNC connection to Windows domU causes black screen on VNC X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2668418657308039017==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============2668418657308039017== Content-Type: multipart/alternative; boundary=20cf30563c0dece79e04cb2851e3 --20cf30563c0dece79e04cb2851e3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/10/3 Valtteri Kiviniemi > > > 2012/10/3 Pasi K=E4rkk=E4inen > >> On Wed, Oct 03, 2012 at 04:48:33PM +0300, Valtteri Kiviniemi wrote: >> > 2012/10/3 Konrad Rzeszutek Wilk <[1]konrad@kernel.org> >> > >> > On Wed, Oct 3, 2012 at 9:22 AM, Valtteri Kiviniemi >> > <[2]kiviniemi.valtteri@gmail.com> wrote: >> > > Hi, >> > > >> > > Tested with realvnc and tightvnc. Realvnc just closes itself >> when the >> > > resolution changes and tightvnc just stays open with the black >> screen. >> > > >> > >> > Lets first see if this is a problem with Windows 2008 expecting >> > certain registers in the VGA >> > emulation and falling flat on its face. >> > >> > If you launch (with the same guest config - but obviously replace >> the >> > ISO), with an >> > Fedora or Ubuntu LiveCD - does it boot? Do you see the VNC screen >> > changing resolution >> > and all that? >> > >> > Hi, >> > >> > Same problem with Fedora-17-x86_64-Live-Desktop.iso. I after the >> > resolution changed the screen goes black. If I change stdvga to 1 I >> will >> > see a bit further but then the VNC client crashes and says somethin= g >> about >> > unsupported features (dont know even if it should work). >> > >> >> Did you try xvnc4viewer? or normal vncviewer? or virt-viewer? >> I usually use virt-viewer without problems.. >> >> -- Pasi >> >> > Hi, > > I'm using Windows 7 in my desktop-computer, so I have not tested any othe= r > vnc clients than ultravnc or tightvnc. I can of course test others too if > there is windows binary available. > > - Valtteri > Hi, Good news, I got it working. It seems that for some reason the encoding has to be RAW and stdvga has to be enabled. This is strange since this same config and setup is working on different hardware. But now I'm able to see the VNC output. - Valtteri --20cf30563c0dece79e04cb2851e3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/10/3 Valtteri Kiviniemi <kiviniemi.valtteri@gmail.com>


2012/10/3 Pasi K= =E4rkk=E4inen <pasik@iki.fi>
On Wed, Oct 03, 2012 at 04:48:33PM +0300, Valtteri Kiviniemi wrote:
> =A0 =A02012/10/3 Konrad Rzeszutek Wilk <[1]konrad@kernel.org>
>
> =A0 =A0 =A0On Wed, Oct 3, 2012 at 9:22 AM, Valtteri Kiviniemi
> =A0 =A0 =A0<[2]kiviniemi.valtteri@gmail.com> wrote:
> =A0 =A0 =A0> Hi,
> =A0 =A0 =A0>
> =A0 =A0 =A0> Tested with realvnc and tightvnc. Realvnc just closes = itself when the
> =A0 =A0 =A0> resolution changes and tightvnc just stays open with t= he black screen.
> =A0 =A0 =A0>
>
> =A0 =A0 =A0Lets first see if this is a problem with Windows 2008 expec= ting
> =A0 =A0 =A0certain registers in the VGA
> =A0 =A0 =A0emulation and falling flat on its face.
>
> =A0 =A0 =A0If you launch (with the same guest config - but obviously r= eplace the
> =A0 =A0 =A0ISO), with an
> =A0 =A0 =A0Fedora or Ubuntu LiveCD - does it boot? Do you see the VNC = screen
> =A0 =A0 =A0changing resolution
> =A0 =A0 =A0and all that?
>
> =A0 =A0Hi,
>
> =A0 =A0Same problem with Fedora-17-x86_64-Live-Desktop.iso. I after th= e
> =A0 =A0resolution changed the screen goes black. If I change stdvga to= 1 I will
> =A0 =A0see a bit further but then the VNC client crashes and says some= thing about
> =A0 =A0unsupported features (dont know even if it should work).
>

Did you try xvnc4viewer? or normal vncviewer? or virt-viewer?
I usually use virt-viewer without problems..

-- Pasi


Hi,

I'm usin= g Windows 7 in my desktop-computer, so I have not tested any other vnc clie= nts than ultravnc or tightvnc. I can of course test others too if there is = windows binary available.
- Valtteri

Hi,
<= br>Good news, I got it working. It seems that for some reason the encoding = has to be RAW and stdvga has to be enabled. This is strange since this same= config and setup is working on different hardware. But now I'm able to= see the VNC output.

- Valtteri

--20cf30563c0dece79e04cb2851e3-- --===============2668418657308039017== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============2668418657308039017==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 14:21:22 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 14:21:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPp0-0007x4-Kq; Wed, 03 Oct 2012 14:21:10 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPoz-0007wt-9n for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 14:21:09 +0000 Received: from [85.158.139.83:50837] by server-5.bemta-5.messagelabs.com id A3/A7-21075-4D94C605; Wed, 03 Oct 2012 14:21:08 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-16.tower-182.messagelabs.com!1349274065!25911645!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MjUwMjc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10126 invoked from network); 3 Oct 2012 14:21:06 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Oct 2012 14:21:06 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id D4DFE24C4; Wed, 3 Oct 2012 17:21:04 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id B8E0720058; Wed, 3 Oct 2012 17:21:04 +0300 (EEST) Date: Wed, 3 Oct 2012 17:21:04 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Valtteri Kiviniemi Message-ID: <20121003142104.GW8912@reaktio.net> References: <20121003135734.GV8912@reaktio.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Konrad Rzeszutek Wilk , chris , Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.2.0, VNC connection to Windows domU causes black screen on VNC X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, Oct 03, 2012 at 05:11:25PM +0300, Valtteri Kiviniemi wrote: > 2012/10/3 Pasi K=E4rkk=E4inen <[1]pasik@iki.fi> > = > On Wed, Oct 03, 2012 at 04:48:33PM +0300, Valtteri Kiviniemi wrote: > > 2012/10/3 Konrad Rzeszutek Wilk <[1][2]konrad@kernel.org> > > > > On Wed, Oct 3, 2012 at 9:22 AM, Valtteri Kiviniemi > > <[2][3]kiviniemi.valtteri@gmail.com> wrote: > > > Hi, > > > > > > Tested with realvnc and tightvnc. Realvnc just closes itself > when the > > > resolution changes and tightvnc just stays open with the bl= ack > screen. > > > > > > > Lets first see if this is a problem with Windows 2008 expecti= ng > > certain registers in the VGA > > emulation and falling flat on its face. > > > > If you launch (with the same guest config - but obviously rep= lace > the > > ISO), with an > > Fedora or Ubuntu LiveCD - does it boot? Do you see the VNC sc= reen > > changing resolution > > and all that? > > > > Hi, > > > > Same problem with Fedora-17-x86_64-Live-Desktop.iso. I after the > > resolution changed the screen goes black. If I change stdvga to= 1 I > will > > see a bit further but then the VNC client crashes and says > something about > > unsupported features (dont know even if it should work). > > > = > Did you try xvnc4viewer? or normal vncviewer? or virt-viewer? > I usually use virt-viewer without problems.. > -- Pasi > = > Hi, > = > I'm using Windows 7 in my desktop-computer, so I have not tested any o= ther > vnc clients than ultravnc or tightvnc. I can of course test others too= if > there is windows binary available. > = I don't think I've ever tried using from Windows :) = How about installing Xming to your Windows box, and then use putty ssh X11 = forwarding to dom0, and execute vncviewer/virt-viewer in dom0? You'll get the vnc GUI displayed= on your Windows. -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 14:21:22 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 14:21:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPp0-0007x4-Kq; Wed, 03 Oct 2012 14:21:10 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPoz-0007wt-9n for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 14:21:09 +0000 Received: from [85.158.139.83:50837] by server-5.bemta-5.messagelabs.com id A3/A7-21075-4D94C605; Wed, 03 Oct 2012 14:21:08 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-16.tower-182.messagelabs.com!1349274065!25911645!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MjUwMjc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10126 invoked from network); 3 Oct 2012 14:21:06 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Oct 2012 14:21:06 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id D4DFE24C4; Wed, 3 Oct 2012 17:21:04 +0300 (EEST) Received: by ydin.reaktio.net (Postfix, from userid 1001) id B8E0720058; Wed, 3 Oct 2012 17:21:04 +0300 (EEST) Date: Wed, 3 Oct 2012 17:21:04 +0300 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: Valtteri Kiviniemi Message-ID: <20121003142104.GW8912@reaktio.net> References: <20121003135734.GV8912@reaktio.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Konrad Rzeszutek Wilk , chris , Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.2.0, VNC connection to Windows domU causes black screen on VNC X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, Oct 03, 2012 at 05:11:25PM +0300, Valtteri Kiviniemi wrote: > 2012/10/3 Pasi K=E4rkk=E4inen <[1]pasik@iki.fi> > = > On Wed, Oct 03, 2012 at 04:48:33PM +0300, Valtteri Kiviniemi wrote: > > 2012/10/3 Konrad Rzeszutek Wilk <[1][2]konrad@kernel.org> > > > > On Wed, Oct 3, 2012 at 9:22 AM, Valtteri Kiviniemi > > <[2][3]kiviniemi.valtteri@gmail.com> wrote: > > > Hi, > > > > > > Tested with realvnc and tightvnc. Realvnc just closes itself > when the > > > resolution changes and tightvnc just stays open with the bl= ack > screen. > > > > > > > Lets first see if this is a problem with Windows 2008 expecti= ng > > certain registers in the VGA > > emulation and falling flat on its face. > > > > If you launch (with the same guest config - but obviously rep= lace > the > > ISO), with an > > Fedora or Ubuntu LiveCD - does it boot? Do you see the VNC sc= reen > > changing resolution > > and all that? > > > > Hi, > > > > Same problem with Fedora-17-x86_64-Live-Desktop.iso. I after the > > resolution changed the screen goes black. If I change stdvga to= 1 I > will > > see a bit further but then the VNC client crashes and says > something about > > unsupported features (dont know even if it should work). > > > = > Did you try xvnc4viewer? or normal vncviewer? or virt-viewer? > I usually use virt-viewer without problems.. > -- Pasi > = > Hi, > = > I'm using Windows 7 in my desktop-computer, so I have not tested any o= ther > vnc clients than ultravnc or tightvnc. I can of course test others too= if > there is windows binary available. > = I don't think I've ever tried using from Windows :) = How about installing Xming to your Windows box, and then use putty ssh X11 = forwarding to dom0, and execute vncviewer/virt-viewer in dom0? You'll get the vnc GUI displayed= on your Windows. -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 14:23:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 14:23:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPqg-00085X-59; Wed, 03 Oct 2012 14:22:54 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPqe-00085J-F0 for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 14:22:52 +0000 Received: from [85.158.137.99:36603] by server-14.bemta-3.messagelabs.com id 55/B7-25886-B3A4C605; Wed, 03 Oct 2012 14:22:51 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-5.tower-217.messagelabs.com!1349274169!15385461!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc5MDM1NA==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13556 invoked from network); 3 Oct 2012 14:22:50 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-5.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Oct 2012 14:22:50 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q93EMgP1012393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Oct 2012 14:22:43 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q93EMf31028208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Oct 2012 14:22:42 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q93EMf6h009371; Wed, 3 Oct 2012 09:22:41 -0500 Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 03 Oct 2012 07:22:41 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 05FCA4032D; Wed, 3 Oct 2012 10:11:17 -0400 (EDT) Date: Wed, 3 Oct 2012 10:11:16 -0400 From: Konrad Rzeszutek Wilk To: Ian Campbell Message-ID: <20121003141116.GA10633@phenom.dumpdata.com> References: <1349272182.650.150.camel@zakaz.uk.xensource.com> <1349272482.650.151.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1349272482.650.151.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH] xen: point xen_start_info to a dummy struct for PV on HVM guests X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, Oct 03, 2012 at 02:54:42PM +0100, Ian Campbell wrote: > On Wed, 2012-10-03 at 14:51 +0100, Stefano Stabellini wrote: > > On Wed, 3 Oct 2012, Ian Campbell wrote: > > > On Wed, 2012-10-03 at 14:37 +0100, Stefano Stabellini wrote: > > > > PV on HVM guests don't have a start_info page mapped by Xen, so > > > > xen_start_info is just NULL for them. > > > > That is problem because other parts of the code expect xen_start_info to > > > > point to something valid, for example xen_initial_domain() is defined as > > > > follow: > > > > > > > > #define xen_initial_domain() (xen_domain() && \ > > > > xen_start_info->flags & SIF_INITDOMAIN) > > > > > > But anyone who calls this before xen_start_info is setup is going to get > > > a bogus result, specifically in this case they will think they are domU > > > when in reality they are dom0 -- wouldn't it be better to fix those > > > callsites? > > > > That cannot be the case because setting up xen_start_info is the very > > first thing that is done, before even calling to C. > > On PV, yes, but you are trying to fix PVHVM here, no? > > Otherwise if this is always set before calling into C then what is the > purpose of this patch? to fix this - as PVHVM has it set to NULL and we end up de-referencing the xen_start_info and crashing. As so:: Decompressing Linux... Parsing ELF... done. Booting the kernel. [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Linux version 3.6.0upstream-04121-g0313983 (konrad@build.dumpdata.com) (gcc version 4.4.4 20100503 (Red Hat 4.4.4-2) (GCC) ) #1 SMP Tue Oct 2 16:31:21 EDT 2012 [ 0.000000] Command line: initrd=initramf.gz console=ttyS0,115200 test=net nofb earlyprintk=serial,ttyS0,115200 BOOT_IMAGE=vmlinuz [ 0.000000] e820: BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009dfff] usable [ 0.000000] BIOS-e820: [mem 0x000000000009e000-0x000000000009ffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000007fffffff] usable [ 0.000000] BIOS-e820: [mem 0x00000000fc000000-0x00000000ffffffff] reserved [ 0.000000] bootconsole [earlyser0] enabled [ 0.000000] NX (Execute Disable) protection: active [ 0.000000] DMI 2.4 present. [ 0.000000] Hypervisor detected: Xen HVM [ 0.000000] Xen version 4.1. [ 0.000000] Netfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated NICs. [ 0.000000] Blkfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated disks. [ 0.000000] You might have to change the root device [ 0.000000] from /dev/hd[a-d] to /dev/xvd[a-d] [ 0.000000] in your root= kernel command line option [ 0.000000] No AGP bridge found [ 0.000000] e820: last_pfn = 0x80000 max_arch_pfn = 0x400000000 [ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [ 0.000000] found SMP MP-table at [mem 0x000fbc90-0x000fbc9f] mapped at [ffff8800000fbc90] [ 0.000000] init_memory_mapping: [mem 0x00000000-0x7fffffff] [ 0.000000] RAMDISK: [mem 0x7abeb000-0x7ffdefff] [ 0.000000] ACPI: RSDP 00000000000ea020 00024 (v02 Xen) [ 0.000000] ACPI: XSDT 00000000fc00f2b0 00034 (v01 Xen HVM 00000000 HVML 00000000) [ 0.000000] ACPI: FACP 00000000fc00f0d0 000F4 (v04 Xen HVM 00000000 HVML 00000000) [ 0.000000] ACPI: DSDT 00000000fc003440 0BC09 (v02 Xen HVM 00000000 INTL 20100528) [ 0.000000] ACPI: FACS 00000000fc003400 00040 [ 0.000000] ACPI: APIC 00000000fc00f1d0 000D8 (v02 Xen HVM 00000000 HVML 00000000) [ 0.000000] No NUMA configuration found [ 0.000000] Faking a node at [mem 0x0000000000000000-0x000000007fffffff] [ 0.000000] Initmem setup node 0 [mem 0x00000000-0x7fffffff] [ 0.000000] NODE_DATA [mem 0x7fffc000-0x7fffffff] [ 0.000000] Zone ranges: [ 0.000000] DMA [mem 0x00010000-0x00ffffff] [ 0.000000] DMA32 [mem 0x01000000-0xffffffff] [ 0.000000] Normal empty [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x00010000-0x0009dfff] [ 0.000000] node 0: [mem 0x00100000-0x7fffffff] [ 0.000000] ACPI: PM-Timer IO Port: 0xb008 [ 0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x08] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x0a] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x0c] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x0e] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x10] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x12] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x14] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x16] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x18] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x1a] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x1c] disabled) [ 0.000000] ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0]) [ 0.000000] IOAPIC[0]: apic_id 1, version 17, address 0xfec00000, GSI 0-47 [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 low level) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 low level) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 low level) [ 0.000000] Using ACPI (MADT) for SMP configuration information [ 0.000000] smpboot: Allowing 15 CPUs, 13 hotplug CPUs [ 0.000000] PM: Registered nosave memory: 000000000009e000 - 00000000000a0000 [ 0.000000] PM: Registered nosave memory: 00000000000a0000 - 00000000000e0000 [ 0.000000] PM: Registered nosave memory: 00000000000e0000 - 0000000000100000 [ 0.000000] e820: [mem 0x80000000-0xfbffffff] available for PCI devices [ 0.000000] Booting paravirtualized kernel on Xen HVM [ 0.000000] setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:15 nr_node_ids:1 [ 0.000000] PERCPU: Embedded 28 pages/cpu @ffff88007a800000 s84352 r8192 d22144 u131072 [ 0.000000] Built 1 zonelists in Node order, mobility grouping on. Total pages: 517000 [ 0.000000] Policy zone: DMA32 [ 0.000000] Kernel command line: initrd=initramf.gz console=ttyS0,115200 test=net nofb earlyprintk=serial,ttyS0,115200 BOOT_IMAGE=vmlinuz [ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes) [ 0.000000] __ex_table already sorted, skipping sort [ 0.000000] Checking aperture... [ 0.000000] No AGP bridge found [ 0.000000] Memory: 1967336k/2097152k available (6368k kernel code, 456k absent, 129360k reserved, 4525k data, 752k init) [ 0.000000] Hierarchical RCU implementation. [ 0.000000] RCU restricting CPUs from NR_CPUS=512 to nr_cpu_ids=15. [ 0.000000] NR_IRQS:33024 nr_irqs:1208 16 [ 0.000000] Xen HVM callback vector for event delivery is enabled [ 0.000000] Console: colour VGA+ 80x25 [ 0.000000] BUG: unable to handle kernel NULL pointer dereference at 0000000000000030 [ 0.000000] IP: [] xen_cons_init+0x1e/0x60 [ 0.000000] PGD 0 [ 0.000000] Oops: 0000 [#1] SMP [ 0.000000] Modules linked in: [ 0.000000] CPU 0 [ 0.000000] Pid: 0, comm: swapper/0 Not tainted 3.6.0upstream-04121-g0313983 #1 Xen HVM domU [ 0.000000] RIP: 0010:[] [] xen_cons_init+0x1e/0x60 [ 0.000000] RSP: 0000:ffffffff81a01ef8 EFLAGS: 00010202 [ 0.000000] RAX: 0000000000000000 RBX: ffffffff81b3be60 RCX: 0000000000000002 [ 0.000000] RDX: ffffffff81a59c40 RSI: ffffffff81a59b01 RDI: ffffffff81ba7e81 [ 0.000000] RBP: ffffffff81a01ef8 R08: 00000000000003fd R09: 0000000000000020 [ 0.000000] R10: 0000000000000000 R11: 000000000000000d R12: ffffffff81b008e0 [ 0.000000] R13: ffffffff81b092e0 R14: 0000000000000000 R15: 0000000000026bf0 [ 0.000000] FS: 0000000000000000(0000) GS:ffff88007a800000(0000) knlGS:0000000000000000 [ 0.000000] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 0.000000] CR2: 0000000000000030 CR3: 0000000001a0b000 CR4: 00000000000006b0 [ 0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 0.000000] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 0.000000] Process swapper/0 (pid: 0, threadinfo ffffffff81a00000, task ffffffff81a13420) [ 0.000000] Stack: [ 0.000000] ffffffff81a01f18 ffffffff81aeb9fb ffffffff81b008e0 ffffffffffffffff [ 0.000000] ffffffff81a01f68 ffffffff81abac39 ffffffff81aba80d 0000000000026bf0 [ 0.000000] ffffffff81a01f58 ffffffff81b092e0 0000000001000000 0000000001c72000 [ 0.000000] Call Trace: [ 0.000000] [] console_init+0x19/0x2a [ 0.000000] [] start_kernel+0x24a/0x3a3 [ 0.000000] [] ? kernel_init+0x1e8/0x1e8 [ 0.000000] [] x86_64_start_reservations+0x131/0x136 [ 0.000000] [] x86_64_start_kernel+0x103/0x112 [ 0.000000] Code: 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 8b 0d 5a 2e 7c 00 55 31 c0 48 89 e5 85 c9 74 37 48 8b 05 51 2e 7c 00 48 c7 c2 40 9c a5 81 40 30 02 75 15 83 f9 02 74 27 e8 52 fc ff ff 85 c0 78 15 48 [ 0.000000] RIP [] xen_cons_init+0x1e/0x60 [ 0.000000] RSP [ 0.000000] CR2: 0000000000000030 [ 0.000000] ---[ end trace 5cb378039a20e088 ]--- [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task! > > > > > > > > Perhaps turn this into a static inline with a BUG_ON(!xen_start_info) to > > > make catching these cases easier? > > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 14:23:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 14:23:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPqg-00085X-59; Wed, 03 Oct 2012 14:22:54 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPqe-00085J-F0 for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 14:22:52 +0000 Received: from [85.158.137.99:36603] by server-14.bemta-3.messagelabs.com id 55/B7-25886-B3A4C605; Wed, 03 Oct 2012 14:22:51 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-5.tower-217.messagelabs.com!1349274169!15385461!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc5MDM1NA==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13556 invoked from network); 3 Oct 2012 14:22:50 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-5.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Oct 2012 14:22:50 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q93EMgP1012393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Oct 2012 14:22:43 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q93EMf31028208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Oct 2012 14:22:42 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q93EMf6h009371; Wed, 3 Oct 2012 09:22:41 -0500 Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 03 Oct 2012 07:22:41 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 05FCA4032D; Wed, 3 Oct 2012 10:11:17 -0400 (EDT) Date: Wed, 3 Oct 2012 10:11:16 -0400 From: Konrad Rzeszutek Wilk To: Ian Campbell Message-ID: <20121003141116.GA10633@phenom.dumpdata.com> References: <1349272182.650.150.camel@zakaz.uk.xensource.com> <1349272482.650.151.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1349272482.650.151.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH] xen: point xen_start_info to a dummy struct for PV on HVM guests X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, Oct 03, 2012 at 02:54:42PM +0100, Ian Campbell wrote: > On Wed, 2012-10-03 at 14:51 +0100, Stefano Stabellini wrote: > > On Wed, 3 Oct 2012, Ian Campbell wrote: > > > On Wed, 2012-10-03 at 14:37 +0100, Stefano Stabellini wrote: > > > > PV on HVM guests don't have a start_info page mapped by Xen, so > > > > xen_start_info is just NULL for them. > > > > That is problem because other parts of the code expect xen_start_info to > > > > point to something valid, for example xen_initial_domain() is defined as > > > > follow: > > > > > > > > #define xen_initial_domain() (xen_domain() && \ > > > > xen_start_info->flags & SIF_INITDOMAIN) > > > > > > But anyone who calls this before xen_start_info is setup is going to get > > > a bogus result, specifically in this case they will think they are domU > > > when in reality they are dom0 -- wouldn't it be better to fix those > > > callsites? > > > > That cannot be the case because setting up xen_start_info is the very > > first thing that is done, before even calling to C. > > On PV, yes, but you are trying to fix PVHVM here, no? > > Otherwise if this is always set before calling into C then what is the > purpose of this patch? to fix this - as PVHVM has it set to NULL and we end up de-referencing the xen_start_info and crashing. As so:: Decompressing Linux... Parsing ELF... done. Booting the kernel. [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Linux version 3.6.0upstream-04121-g0313983 (konrad@build.dumpdata.com) (gcc version 4.4.4 20100503 (Red Hat 4.4.4-2) (GCC) ) #1 SMP Tue Oct 2 16:31:21 EDT 2012 [ 0.000000] Command line: initrd=initramf.gz console=ttyS0,115200 test=net nofb earlyprintk=serial,ttyS0,115200 BOOT_IMAGE=vmlinuz [ 0.000000] e820: BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009dfff] usable [ 0.000000] BIOS-e820: [mem 0x000000000009e000-0x000000000009ffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000007fffffff] usable [ 0.000000] BIOS-e820: [mem 0x00000000fc000000-0x00000000ffffffff] reserved [ 0.000000] bootconsole [earlyser0] enabled [ 0.000000] NX (Execute Disable) protection: active [ 0.000000] DMI 2.4 present. [ 0.000000] Hypervisor detected: Xen HVM [ 0.000000] Xen version 4.1. [ 0.000000] Netfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated NICs. [ 0.000000] Blkfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated disks. [ 0.000000] You might have to change the root device [ 0.000000] from /dev/hd[a-d] to /dev/xvd[a-d] [ 0.000000] in your root= kernel command line option [ 0.000000] No AGP bridge found [ 0.000000] e820: last_pfn = 0x80000 max_arch_pfn = 0x400000000 [ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [ 0.000000] found SMP MP-table at [mem 0x000fbc90-0x000fbc9f] mapped at [ffff8800000fbc90] [ 0.000000] init_memory_mapping: [mem 0x00000000-0x7fffffff] [ 0.000000] RAMDISK: [mem 0x7abeb000-0x7ffdefff] [ 0.000000] ACPI: RSDP 00000000000ea020 00024 (v02 Xen) [ 0.000000] ACPI: XSDT 00000000fc00f2b0 00034 (v01 Xen HVM 00000000 HVML 00000000) [ 0.000000] ACPI: FACP 00000000fc00f0d0 000F4 (v04 Xen HVM 00000000 HVML 00000000) [ 0.000000] ACPI: DSDT 00000000fc003440 0BC09 (v02 Xen HVM 00000000 INTL 20100528) [ 0.000000] ACPI: FACS 00000000fc003400 00040 [ 0.000000] ACPI: APIC 00000000fc00f1d0 000D8 (v02 Xen HVM 00000000 HVML 00000000) [ 0.000000] No NUMA configuration found [ 0.000000] Faking a node at [mem 0x0000000000000000-0x000000007fffffff] [ 0.000000] Initmem setup node 0 [mem 0x00000000-0x7fffffff] [ 0.000000] NODE_DATA [mem 0x7fffc000-0x7fffffff] [ 0.000000] Zone ranges: [ 0.000000] DMA [mem 0x00010000-0x00ffffff] [ 0.000000] DMA32 [mem 0x01000000-0xffffffff] [ 0.000000] Normal empty [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x00010000-0x0009dfff] [ 0.000000] node 0: [mem 0x00100000-0x7fffffff] [ 0.000000] ACPI: PM-Timer IO Port: 0xb008 [ 0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x08] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x0a] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x0c] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x0e] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x10] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x12] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x14] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x16] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x18] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x1a] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x1c] disabled) [ 0.000000] ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0]) [ 0.000000] IOAPIC[0]: apic_id 1, version 17, address 0xfec00000, GSI 0-47 [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 low level) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 low level) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 low level) [ 0.000000] Using ACPI (MADT) for SMP configuration information [ 0.000000] smpboot: Allowing 15 CPUs, 13 hotplug CPUs [ 0.000000] PM: Registered nosave memory: 000000000009e000 - 00000000000a0000 [ 0.000000] PM: Registered nosave memory: 00000000000a0000 - 00000000000e0000 [ 0.000000] PM: Registered nosave memory: 00000000000e0000 - 0000000000100000 [ 0.000000] e820: [mem 0x80000000-0xfbffffff] available for PCI devices [ 0.000000] Booting paravirtualized kernel on Xen HVM [ 0.000000] setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:15 nr_node_ids:1 [ 0.000000] PERCPU: Embedded 28 pages/cpu @ffff88007a800000 s84352 r8192 d22144 u131072 [ 0.000000] Built 1 zonelists in Node order, mobility grouping on. Total pages: 517000 [ 0.000000] Policy zone: DMA32 [ 0.000000] Kernel command line: initrd=initramf.gz console=ttyS0,115200 test=net nofb earlyprintk=serial,ttyS0,115200 BOOT_IMAGE=vmlinuz [ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes) [ 0.000000] __ex_table already sorted, skipping sort [ 0.000000] Checking aperture... [ 0.000000] No AGP bridge found [ 0.000000] Memory: 1967336k/2097152k available (6368k kernel code, 456k absent, 129360k reserved, 4525k data, 752k init) [ 0.000000] Hierarchical RCU implementation. [ 0.000000] RCU restricting CPUs from NR_CPUS=512 to nr_cpu_ids=15. [ 0.000000] NR_IRQS:33024 nr_irqs:1208 16 [ 0.000000] Xen HVM callback vector for event delivery is enabled [ 0.000000] Console: colour VGA+ 80x25 [ 0.000000] BUG: unable to handle kernel NULL pointer dereference at 0000000000000030 [ 0.000000] IP: [] xen_cons_init+0x1e/0x60 [ 0.000000] PGD 0 [ 0.000000] Oops: 0000 [#1] SMP [ 0.000000] Modules linked in: [ 0.000000] CPU 0 [ 0.000000] Pid: 0, comm: swapper/0 Not tainted 3.6.0upstream-04121-g0313983 #1 Xen HVM domU [ 0.000000] RIP: 0010:[] [] xen_cons_init+0x1e/0x60 [ 0.000000] RSP: 0000:ffffffff81a01ef8 EFLAGS: 00010202 [ 0.000000] RAX: 0000000000000000 RBX: ffffffff81b3be60 RCX: 0000000000000002 [ 0.000000] RDX: ffffffff81a59c40 RSI: ffffffff81a59b01 RDI: ffffffff81ba7e81 [ 0.000000] RBP: ffffffff81a01ef8 R08: 00000000000003fd R09: 0000000000000020 [ 0.000000] R10: 0000000000000000 R11: 000000000000000d R12: ffffffff81b008e0 [ 0.000000] R13: ffffffff81b092e0 R14: 0000000000000000 R15: 0000000000026bf0 [ 0.000000] FS: 0000000000000000(0000) GS:ffff88007a800000(0000) knlGS:0000000000000000 [ 0.000000] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 0.000000] CR2: 0000000000000030 CR3: 0000000001a0b000 CR4: 00000000000006b0 [ 0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 0.000000] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 0.000000] Process swapper/0 (pid: 0, threadinfo ffffffff81a00000, task ffffffff81a13420) [ 0.000000] Stack: [ 0.000000] ffffffff81a01f18 ffffffff81aeb9fb ffffffff81b008e0 ffffffffffffffff [ 0.000000] ffffffff81a01f68 ffffffff81abac39 ffffffff81aba80d 0000000000026bf0 [ 0.000000] ffffffff81a01f58 ffffffff81b092e0 0000000001000000 0000000001c72000 [ 0.000000] Call Trace: [ 0.000000] [] console_init+0x19/0x2a [ 0.000000] [] start_kernel+0x24a/0x3a3 [ 0.000000] [] ? kernel_init+0x1e8/0x1e8 [ 0.000000] [] x86_64_start_reservations+0x131/0x136 [ 0.000000] [] x86_64_start_kernel+0x103/0x112 [ 0.000000] Code: 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 8b 0d 5a 2e 7c 00 55 31 c0 48 89 e5 85 c9 74 37 48 8b 05 51 2e 7c 00 48 c7 c2 40 9c a5 81 40 30 02 75 15 83 f9 02 74 27 e8 52 fc ff ff 85 c0 78 15 48 [ 0.000000] RIP [] xen_cons_init+0x1e/0x60 [ 0.000000] RSP [ 0.000000] CR2: 0000000000000030 [ 0.000000] ---[ end trace 5cb378039a20e088 ]--- [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task! > > > > > > > > Perhaps turn this into a static inline with a BUG_ON(!xen_start_info) to > > > make catching these cases easier? > > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 14:30:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 14:30:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPxR-0008Lf-71; Wed, 03 Oct 2012 14:29:53 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPxQ-0008La-5M for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 14:29:52 +0000 Received: from [85.158.139.83:63808] by server-4.bemta-5.messagelabs.com id 5E/83-20767-FDB4C605; Wed, 03 Oct 2012 14:29:51 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1349274589!27640198!1 X-Originating-IP: [209.85.213.45] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4227 invoked from network); 3 Oct 2012 14:29:50 -0000 Received: from mail-yh0-f45.google.com (HELO mail-yh0-f45.google.com) (209.85.213.45) by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 14:29:50 -0000 Received: by yhpp34 with SMTP id p34so742912yhp.32 for ; Wed, 03 Oct 2012 07:29:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fpDM3O3Xsz2SkG1nP77KsQoWk/uxw6Yd18XbVLgs1V4=; b=RbNL5pROJxdV+2dzAAF19jJREhZDfKZn7zNWAphQ34SE7dttpT2cmv4La4OsJnBPcE e7gZXe57GTCNlDtPI9Opj6ByxRYuhQu563e0R7xEz+UhSath3ntgQc3H4URr36OgAvWj bHZD7uQEjR32ep9IXIK704v41FkqwwWW84ZkpPw8fZ8tvQNz6QpYvLPTMHQm71p/JJQT XnXkN8SAgHw6ojBz5UqZDF/cdUKUebKV0eEb6ZI1ro+V4VVTzK0WM+4wWTbkeOlhdbVg 6SinBEdn/igpEz8ZlgoFFgSE6aVJpb5MKlo5TgrrHKQjHL75ZzSvy5S5S9zAHLloL8bB 2Jsw== MIME-Version: 1.0 Received: by 10.236.137.208 with SMTP id y56mr1946874yhi.58.1349274589104; Wed, 03 Oct 2012 07:29:49 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Wed, 3 Oct 2012 07:29:49 -0700 (PDT) In-Reply-To: <20121003142104.GW8912@reaktio.net> References: <20121003135734.GV8912@reaktio.net> <20121003142104.GW8912@reaktio.net> Date: Wed, 3 Oct 2012 17:29:49 +0300 Message-ID: From: Valtteri Kiviniemi To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= Cc: Konrad Rzeszutek Wilk , chris , Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.2.0, VNC connection to Windows domU causes black screen on VNC X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8922757452124009891==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============8922757452124009891== Content-Type: multipart/alternative; boundary=20cf303a2eb596892504cb287830 --20cf303a2eb596892504cb287830 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/10/3 Pasi K=E4rkk=E4inen > On Wed, Oct 03, 2012 at 05:11:25PM +0300, Valtteri Kiviniemi wrote: > > 2012/10/3 Pasi K=E4rkk=E4inen <[1]pasik@iki.fi> > > > > On Wed, Oct 03, 2012 at 04:48:33PM +0300, Valtteri Kiviniemi wrote= : > > > 2012/10/3 Konrad Rzeszutek Wilk <[1][2]konrad@kernel.org> > > > > > > On Wed, Oct 3, 2012 at 9:22 AM, Valtteri Kiviniemi > > > <[2][3]kiviniemi.valtteri@gmail.com> wrote: > > > > Hi, > > > > > > > > Tested with realvnc and tightvnc. Realvnc just closes > itself > > when the > > > > resolution changes and tightvnc just stays open with the > black > > screen. > > > > > > > > > > Lets first see if this is a problem with Windows 2008 > expecting > > > certain registers in the VGA > > > emulation and falling flat on its face. > > > > > > If you launch (with the same guest config - but obviously > replace > > the > > > ISO), with an > > > Fedora or Ubuntu LiveCD - does it boot? Do you see the VNC > screen > > > changing resolution > > > and all that? > > > > > > Hi, > > > > > > Same problem with Fedora-17-x86_64-Live-Desktop.iso. I after > the > > > resolution changed the screen goes black. If I change stdvga > to 1 I > > will > > > see a bit further but then the VNC client crashes and says > > something about > > > unsupported features (dont know even if it should work). > > > > > > > Did you try xvnc4viewer? or normal vncviewer? or virt-viewer? > > I usually use virt-viewer without problems.. > > -- Pasi > > > > Hi, > > > > I'm using Windows 7 in my desktop-computer, so I have not tested any > other > > vnc clients than ultravnc or tightvnc. I can of course test others > too if > > there is windows binary available. > > > > I don't think I've ever tried using from Windows :) > > How about installing Xming to your Windows box, and then use putty ssh X1= 1 > forwarding to dom0, > and execute vncviewer/virt-viewer in dom0? You'll get the vnc GUI > displayed on your Windows. > > -- Pasi > > Hi, No need anymore, since I got it working (see my earlier post). Somone should add this to the xen wiki/common problems. In my case stdvga needs to be enabled and then VNC connection type must be RAW. So in case someone has these kind of problems in the future, it would be good to mention this in wiki :) --20cf303a2eb596892504cb287830 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/10/3 Pasi K=E4rkk=E4inen <pasik@iki.fi= >
On Wed, Oct 03, 2012 at 05:11:25PM +0300, Valtteri Kiviniemi wrote:
> =A0 =A02012/10/3 Pasi K=E4rkk=E4inen <[1]pasik@iki.fi>
>
> =A0 =A0 =A0On Wed, Oct 03, 2012 at 04:48:33PM +0300, Valtteri Kiviniem= i wrote:
> =A0 =A0 =A0> =A0 =A02012/10/3 Konrad Rzeszutek Wilk <[1][2= ]konrad@kernel.org>
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0On Wed, Oct 3, 2012 at 9:22 AM, Valtteri Ki= viniemi
> =A0 =A0 =A0> =A0 =A0 =A0<[2][3]kiviniemi.valtteri@gmail.com> wrote:
> =A0 =A0 =A0> =A0 =A0 =A0> Hi,
> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> Tested with realvnc and tightvnc. Real= vnc just closes itself
> =A0 =A0 =A0when the
> =A0 =A0 =A0> =A0 =A0 =A0> resolution changes and tightvnc just s= tays open with the black
> =A0 =A0 =A0screen.
> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0Lets first see if this is a problem with Wi= ndows 2008 expecting
> =A0 =A0 =A0> =A0 =A0 =A0certain registers in the VGA
> =A0 =A0 =A0> =A0 =A0 =A0emulation and falling flat on its face.
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0If you launch (with the same guest config -= but obviously replace
> =A0 =A0 =A0the
> =A0 =A0 =A0> =A0 =A0 =A0ISO), with an
> =A0 =A0 =A0> =A0 =A0 =A0Fedora or Ubuntu LiveCD - does it boot? Do = you see the VNC screen
> =A0 =A0 =A0> =A0 =A0 =A0changing resolution
> =A0 =A0 =A0> =A0 =A0 =A0and all that?
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0Hi,
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0Same problem with Fedora-17-x86_64-Live-Desktop= .iso. I after the
> =A0 =A0 =A0> =A0 =A0resolution changed the screen goes black. If I = change stdvga to 1 I
> =A0 =A0 =A0will
> =A0 =A0 =A0> =A0 =A0see a bit further but then the VNC client crash= es and says
> =A0 =A0 =A0something about
> =A0 =A0 =A0> =A0 =A0unsupported features (dont know even if it shou= ld work).
> =A0 =A0 =A0>
>
> =A0 =A0 =A0Did you try xvnc4viewer? or normal vncviewer? or virt-viewe= r?
> =A0 =A0 =A0I usually use virt-viewer without problems..
> =A0 =A0 =A0-- Pasi
>
> =A0 =A0Hi,
>
> =A0 =A0I'm using Windows 7 in my desktop-computer, so I have not t= ested any other
> =A0 =A0vnc clients than ultravnc or tightvnc. I can of course test oth= ers too if
> =A0 =A0there is windows binary available.
>

I don't think I've ever tried using from Windows :)

How about installing Xming to your Windows box, and then use putty ssh X11 = forwarding to dom0,
and execute vncviewer/virt-viewer in dom0? You'll get the vnc GUI displ= ayed on your Windows.

-- Pasi


Hi,

No need anymore, since I go= t it working (see my earlier post). Somone should add this to the xen wiki/= common problems. In my case stdvga needs to be enabled and then VNC connect= ion type must be RAW. So in case someone has these kind of problems in the = future, it would be good to mention this in wiki :)
--20cf303a2eb596892504cb287830-- --===============8922757452124009891== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8922757452124009891==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 14:30:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 14:30:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPxR-0008Lf-71; Wed, 03 Oct 2012 14:29:53 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJPxQ-0008La-5M for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 14:29:52 +0000 Received: from [85.158.139.83:63808] by server-4.bemta-5.messagelabs.com id 5E/83-20767-FDB4C605; Wed, 03 Oct 2012 14:29:51 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1349274589!27640198!1 X-Originating-IP: [209.85.213.45] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4227 invoked from network); 3 Oct 2012 14:29:50 -0000 Received: from mail-yh0-f45.google.com (HELO mail-yh0-f45.google.com) (209.85.213.45) by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 14:29:50 -0000 Received: by yhpp34 with SMTP id p34so742912yhp.32 for ; Wed, 03 Oct 2012 07:29:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fpDM3O3Xsz2SkG1nP77KsQoWk/uxw6Yd18XbVLgs1V4=; b=RbNL5pROJxdV+2dzAAF19jJREhZDfKZn7zNWAphQ34SE7dttpT2cmv4La4OsJnBPcE e7gZXe57GTCNlDtPI9Opj6ByxRYuhQu563e0R7xEz+UhSath3ntgQc3H4URr36OgAvWj bHZD7uQEjR32ep9IXIK704v41FkqwwWW84ZkpPw8fZ8tvQNz6QpYvLPTMHQm71p/JJQT XnXkN8SAgHw6ojBz5UqZDF/cdUKUebKV0eEb6ZI1ro+V4VVTzK0WM+4wWTbkeOlhdbVg 6SinBEdn/igpEz8ZlgoFFgSE6aVJpb5MKlo5TgrrHKQjHL75ZzSvy5S5S9zAHLloL8bB 2Jsw== MIME-Version: 1.0 Received: by 10.236.137.208 with SMTP id y56mr1946874yhi.58.1349274589104; Wed, 03 Oct 2012 07:29:49 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Wed, 3 Oct 2012 07:29:49 -0700 (PDT) In-Reply-To: <20121003142104.GW8912@reaktio.net> References: <20121003135734.GV8912@reaktio.net> <20121003142104.GW8912@reaktio.net> Date: Wed, 3 Oct 2012 17:29:49 +0300 Message-ID: From: Valtteri Kiviniemi To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= Cc: Konrad Rzeszutek Wilk , chris , Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.2.0, VNC connection to Windows domU causes black screen on VNC X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8922757452124009891==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============8922757452124009891== Content-Type: multipart/alternative; boundary=20cf303a2eb596892504cb287830 --20cf303a2eb596892504cb287830 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/10/3 Pasi K=E4rkk=E4inen > On Wed, Oct 03, 2012 at 05:11:25PM +0300, Valtteri Kiviniemi wrote: > > 2012/10/3 Pasi K=E4rkk=E4inen <[1]pasik@iki.fi> > > > > On Wed, Oct 03, 2012 at 04:48:33PM +0300, Valtteri Kiviniemi wrote= : > > > 2012/10/3 Konrad Rzeszutek Wilk <[1][2]konrad@kernel.org> > > > > > > On Wed, Oct 3, 2012 at 9:22 AM, Valtteri Kiviniemi > > > <[2][3]kiviniemi.valtteri@gmail.com> wrote: > > > > Hi, > > > > > > > > Tested with realvnc and tightvnc. Realvnc just closes > itself > > when the > > > > resolution changes and tightvnc just stays open with the > black > > screen. > > > > > > > > > > Lets first see if this is a problem with Windows 2008 > expecting > > > certain registers in the VGA > > > emulation and falling flat on its face. > > > > > > If you launch (with the same guest config - but obviously > replace > > the > > > ISO), with an > > > Fedora or Ubuntu LiveCD - does it boot? Do you see the VNC > screen > > > changing resolution > > > and all that? > > > > > > Hi, > > > > > > Same problem with Fedora-17-x86_64-Live-Desktop.iso. I after > the > > > resolution changed the screen goes black. If I change stdvga > to 1 I > > will > > > see a bit further but then the VNC client crashes and says > > something about > > > unsupported features (dont know even if it should work). > > > > > > > Did you try xvnc4viewer? or normal vncviewer? or virt-viewer? > > I usually use virt-viewer without problems.. > > -- Pasi > > > > Hi, > > > > I'm using Windows 7 in my desktop-computer, so I have not tested any > other > > vnc clients than ultravnc or tightvnc. I can of course test others > too if > > there is windows binary available. > > > > I don't think I've ever tried using from Windows :) > > How about installing Xming to your Windows box, and then use putty ssh X1= 1 > forwarding to dom0, > and execute vncviewer/virt-viewer in dom0? You'll get the vnc GUI > displayed on your Windows. > > -- Pasi > > Hi, No need anymore, since I got it working (see my earlier post). Somone should add this to the xen wiki/common problems. In my case stdvga needs to be enabled and then VNC connection type must be RAW. So in case someone has these kind of problems in the future, it would be good to mention this in wiki :) --20cf303a2eb596892504cb287830 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/10/3 Pasi K=E4rkk=E4inen <pasik@iki.fi= >
On Wed, Oct 03, 2012 at 05:11:25PM +0300, Valtteri Kiviniemi wrote:
> =A0 =A02012/10/3 Pasi K=E4rkk=E4inen <[1]pasik@iki.fi>
>
> =A0 =A0 =A0On Wed, Oct 03, 2012 at 04:48:33PM +0300, Valtteri Kiviniem= i wrote:
> =A0 =A0 =A0> =A0 =A02012/10/3 Konrad Rzeszutek Wilk <[1][2= ]konrad@kernel.org>
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0On Wed, Oct 3, 2012 at 9:22 AM, Valtteri Ki= viniemi
> =A0 =A0 =A0> =A0 =A0 =A0<[2][3]kiviniemi.valtteri@gmail.com> wrote:
> =A0 =A0 =A0> =A0 =A0 =A0> Hi,
> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0> Tested with realvnc and tightvnc. Real= vnc just closes itself
> =A0 =A0 =A0when the
> =A0 =A0 =A0> =A0 =A0 =A0> resolution changes and tightvnc just s= tays open with the black
> =A0 =A0 =A0screen.
> =A0 =A0 =A0> =A0 =A0 =A0>
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0Lets first see if this is a problem with Wi= ndows 2008 expecting
> =A0 =A0 =A0> =A0 =A0 =A0certain registers in the VGA
> =A0 =A0 =A0> =A0 =A0 =A0emulation and falling flat on its face.
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0 =A0If you launch (with the same guest config -= but obviously replace
> =A0 =A0 =A0the
> =A0 =A0 =A0> =A0 =A0 =A0ISO), with an
> =A0 =A0 =A0> =A0 =A0 =A0Fedora or Ubuntu LiveCD - does it boot? Do = you see the VNC screen
> =A0 =A0 =A0> =A0 =A0 =A0changing resolution
> =A0 =A0 =A0> =A0 =A0 =A0and all that?
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0Hi,
> =A0 =A0 =A0>
> =A0 =A0 =A0> =A0 =A0Same problem with Fedora-17-x86_64-Live-Desktop= .iso. I after the
> =A0 =A0 =A0> =A0 =A0resolution changed the screen goes black. If I = change stdvga to 1 I
> =A0 =A0 =A0will
> =A0 =A0 =A0> =A0 =A0see a bit further but then the VNC client crash= es and says
> =A0 =A0 =A0something about
> =A0 =A0 =A0> =A0 =A0unsupported features (dont know even if it shou= ld work).
> =A0 =A0 =A0>
>
> =A0 =A0 =A0Did you try xvnc4viewer? or normal vncviewer? or virt-viewe= r?
> =A0 =A0 =A0I usually use virt-viewer without problems..
> =A0 =A0 =A0-- Pasi
>
> =A0 =A0Hi,
>
> =A0 =A0I'm using Windows 7 in my desktop-computer, so I have not t= ested any other
> =A0 =A0vnc clients than ultravnc or tightvnc. I can of course test oth= ers too if
> =A0 =A0there is windows binary available.
>

I don't think I've ever tried using from Windows :)

How about installing Xming to your Windows box, and then use putty ssh X11 = forwarding to dom0,
and execute vncviewer/virt-viewer in dom0? You'll get the vnc GUI displ= ayed on your Windows.

-- Pasi


Hi,

No need anymore, since I go= t it working (see my earlier post). Somone should add this to the xen wiki/= common problems. In my case stdvga needs to be enabled and then VNC connect= ion type must be RAW. So in case someone has these kind of problems in the = future, it would be good to mention this in wiki :)
--20cf303a2eb596892504cb287830-- --===============8922757452124009891== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8922757452124009891==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 14:33:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 14:33:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJQ13-0008Vl-Rf; Wed, 03 Oct 2012 14:33:37 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJQ12-0008VX-8F for xen-devel@lists.xen.org; Wed, 03 Oct 2012 14:33:36 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1349274808!5637511!1 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10066 invoked from network); 3 Oct 2012 14:33:29 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 14:33:29 -0000 Received: by eekb47 with SMTP id b47so4319467eek.32 for ; Wed, 03 Oct 2012 07:33:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=MjfXJxNxCpjLR/godY1SU9MHKQZGh/4j4lhNsljq+tk=; b=JDeLCLMZOHOb0N5Q3H6l66llAuy3BekM3yY4Z6X/6862kRjC5IrC3bYBTwzqLxH5Hw FBh74Zx6NgXmeQY+77a3RcGHEDG/M+NOT2K2Kl7OwBEF4nWwwPsOMKDV5SFATuzqKOgC z7YOQnU9Nl6kU0vFeBSZHV0Q96kzRJ+UUfmuRPp25FlJBsjPx9zpckibZ+Gvf9Qgcp9V wQ9UcNBdorMPaR/TqxnzYNHQvnjGK766QdKyEaQZuQEHVKfO0CKmMOG8slUeFtb7uGfe 0zBt5sw2QfMpKQe96kv8WOe+zhKzz9I/1vxTW8ToKo4xcpCm7z1ZJlXrJbRzLYSV33// /hUg== Received: by 10.14.204.72 with SMTP id g48mr2978677eeo.45.1349274808861; Wed, 03 Oct 2012 07:33:28 -0700 (PDT) Received: from [192.168.1.69] (host86-183-156-141.range86-183.btcentralplus.com. [86.183.156.141]) by mx.google.com with ESMTPS id 42sm10130268eee.0.2012.10.03.07.33.26 (version=SSLv3 cipher=OTHER); Wed, 03 Oct 2012 07:33:28 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 03 Oct 2012 15:33:23 +0100 From: Keir Fraser To: Jan Beulich Message-ID: Thread-Topic: [Xen-devel] [PATCH] VT-d: make remap_entry_to_msi_msg() return consistent message Thread-Index: Ac2hdAqdZqxvk+zzlU2H13WEuwuTrw== In-Reply-To: <506C447D020000780008D001@nat28.tlf.novell.com> Mime-version: 1.0 Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH] VT-d: make remap_entry_to_msi_msg() return consistent message X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 03/10/2012 13:58, "Jan Beulich" wrote: >>>> Keir Fraser 10/02/12 7:01 PM >>> >> On 02/10/2012 15:55, "Jan Beulich" wrote: >> >>> During debugging of another problem I found that in x2APIC mode, the >>> destination field of the low address value wasn't passed back >>> correctly. While this is benign in most cases (as the value isn't being >>> used anywhere), it can be confusing (and misguiding) when printing the >>> value read or when comparing it to the one previously passed into the >>> inverse function. >>> >>> Signed-off-by: Jan Beulich >> >> Acked-by: Keir Fraser > > Actually on my way home yesterday I realized that this is not consistent, i.e. > fails to cover symmetrically the !x2apic case. Therefore, I'd like to adjust > this > to pull out the msg->dest32 assignment from the conditional. Will that be okay > to commit without re-submission? Yes, that's fine by me. -- Keir > Jan > >> --- a/xen/drivers/passthrough/vtd/intremap.c >> +++ b/xen/drivers/passthrough/vtd/intremap.c >> @@ -504,7 +504,11 @@ static int remap_entry_to_msi_msg( >> MSI_ADDR_REDIRECTION_CPU: >> MSI_ADDR_REDIRECTION_LOWPRI); >> if ( x2apic_enabled ) >> + { >> msg->dest32 = iremap_entry->lo.dst; >> + msg->address_lo |= >> + (iremap_entry->lo.dst & 0xff) << MSI_ADDR_DEST_ID_SHIFT; >> + } >> else >> msg->address_lo |= >> ((iremap_entry->lo.dst >> 8) & 0xff ) << MSI_ADDR_DEST_ID_SHIFT; >> >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel > > > > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 14:33:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 14:33:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJQ13-0008Vl-Rf; Wed, 03 Oct 2012 14:33:37 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJQ12-0008VX-8F for xen-devel@lists.xen.org; Wed, 03 Oct 2012 14:33:36 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1349274808!5637511!1 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10066 invoked from network); 3 Oct 2012 14:33:29 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 14:33:29 -0000 Received: by eekb47 with SMTP id b47so4319467eek.32 for ; Wed, 03 Oct 2012 07:33:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=MjfXJxNxCpjLR/godY1SU9MHKQZGh/4j4lhNsljq+tk=; b=JDeLCLMZOHOb0N5Q3H6l66llAuy3BekM3yY4Z6X/6862kRjC5IrC3bYBTwzqLxH5Hw FBh74Zx6NgXmeQY+77a3RcGHEDG/M+NOT2K2Kl7OwBEF4nWwwPsOMKDV5SFATuzqKOgC z7YOQnU9Nl6kU0vFeBSZHV0Q96kzRJ+UUfmuRPp25FlJBsjPx9zpckibZ+Gvf9Qgcp9V wQ9UcNBdorMPaR/TqxnzYNHQvnjGK766QdKyEaQZuQEHVKfO0CKmMOG8slUeFtb7uGfe 0zBt5sw2QfMpKQe96kv8WOe+zhKzz9I/1vxTW8ToKo4xcpCm7z1ZJlXrJbRzLYSV33// /hUg== Received: by 10.14.204.72 with SMTP id g48mr2978677eeo.45.1349274808861; Wed, 03 Oct 2012 07:33:28 -0700 (PDT) Received: from [192.168.1.69] (host86-183-156-141.range86-183.btcentralplus.com. [86.183.156.141]) by mx.google.com with ESMTPS id 42sm10130268eee.0.2012.10.03.07.33.26 (version=SSLv3 cipher=OTHER); Wed, 03 Oct 2012 07:33:28 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 03 Oct 2012 15:33:23 +0100 From: Keir Fraser To: Jan Beulich Message-ID: Thread-Topic: [Xen-devel] [PATCH] VT-d: make remap_entry_to_msi_msg() return consistent message Thread-Index: Ac2hdAqdZqxvk+zzlU2H13WEuwuTrw== In-Reply-To: <506C447D020000780008D001@nat28.tlf.novell.com> Mime-version: 1.0 Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH] VT-d: make remap_entry_to_msi_msg() return consistent message X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 03/10/2012 13:58, "Jan Beulich" wrote: >>>> Keir Fraser 10/02/12 7:01 PM >>> >> On 02/10/2012 15:55, "Jan Beulich" wrote: >> >>> During debugging of another problem I found that in x2APIC mode, the >>> destination field of the low address value wasn't passed back >>> correctly. While this is benign in most cases (as the value isn't being >>> used anywhere), it can be confusing (and misguiding) when printing the >>> value read or when comparing it to the one previously passed into the >>> inverse function. >>> >>> Signed-off-by: Jan Beulich >> >> Acked-by: Keir Fraser > > Actually on my way home yesterday I realized that this is not consistent, i.e. > fails to cover symmetrically the !x2apic case. Therefore, I'd like to adjust > this > to pull out the msg->dest32 assignment from the conditional. Will that be okay > to commit without re-submission? Yes, that's fine by me. -- Keir > Jan > >> --- a/xen/drivers/passthrough/vtd/intremap.c >> +++ b/xen/drivers/passthrough/vtd/intremap.c >> @@ -504,7 +504,11 @@ static int remap_entry_to_msi_msg( >> MSI_ADDR_REDIRECTION_CPU: >> MSI_ADDR_REDIRECTION_LOWPRI); >> if ( x2apic_enabled ) >> + { >> msg->dest32 = iremap_entry->lo.dst; >> + msg->address_lo |= >> + (iremap_entry->lo.dst & 0xff) << MSI_ADDR_DEST_ID_SHIFT; >> + } >> else >> msg->address_lo |= >> ((iremap_entry->lo.dst >> 8) & 0xff ) << MSI_ADDR_DEST_ID_SHIFT; >> >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel > > > > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 14:35:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 14:35:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJQ2x-0000F2-CD; Wed, 03 Oct 2012 14:35:35 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJQ2w-0000Ev-2v for xen-devel@lists.xen.org; Wed, 03 Oct 2012 14:35:34 +0000 Received: from [85.158.143.35:32528] by server-3.bemta-4.messagelabs.com id DF/DB-10986-53D4C605; Wed, 03 Oct 2012 14:35:33 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1349274931!12893419!1 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7755 invoked from network); 3 Oct 2012 14:35:32 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 14:35:32 -0000 Received: by eekb47 with SMTP id b47so4321556eek.32 for ; Wed, 03 Oct 2012 07:35:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=2TTFY7yKbVo9n+V3Z00RYf9HfNvwvlMf+IJDbFR1PbQ=; b=kpRPKdN07uoZh5ODP8joL9OEjlO0qO4nAg24683ldOEL03AQ3Ly2d/3GebtmHI56fL zGlC1W+4zhWGfjxO5ucYXTqygLaKTRRaDmBgcxZMADkxxyuGFXSqdqsrRpdLRqbbF/dL +eo7n/tu7kOacE+eUv4vV71r6LFj5DFY8/boV0xrvbPUpkd1BCfBWX1VXZ5bzmvqA2jx XAmwj5ZRCl8e84pV6scUZdOZOevysRm7aJ52gCspZnhWzvWWzDjQ401RR6VAGAWW8zdn k38SqMAkUkPE4p1Hgu4Rn9BQJSfYuqD30/yIu32wPN3e8pEyFfevnjMrc1hp/kZLv6p0 wcIQ== Received: by 10.14.184.133 with SMTP id s5mr3012222eem.31.1349274931191; Wed, 03 Oct 2012 07:35:31 -0700 (PDT) Received: from [192.168.1.69] (host86-183-156-141.range86-183.btcentralplus.com. [86.183.156.141]) by mx.google.com with ESMTPS id i41sm10109190eem.7.2012.10.03.07.35.29 (version=SSLv3 cipher=OTHER); Wed, 03 Oct 2012 07:35:30 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 03 Oct 2012 15:35:27 +0100 From: Keir Fraser To: Jan Beulich Message-ID: Thread-Topic: [Xen-devel] [PATCH 3/3] x86: save/restore only partial register state where possible Thread-Index: Ac2hdFSG1j75QiymQECiXZbJUV578Q== In-Reply-To: <506C461E020000780008D00F@nat28.tlf.novell.com> Mime-version: 1.0 Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH 3/3] x86: save/restore only partial register state where possible X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 03/10/2012 14:05, "Jan Beulich" wrote: >>>> Keir Fraser 10/02/12 7:02 PM >>> >> On 02/10/2012 16:27, "Jan Beulich" wrote: >> >>> ... and make restore conditional not only upon having saved the state, >>> but also upon whether saved state was actually modified (and register >>> values are known to have been preserved). >>> >>> Note that RBP is unconditionally considered a volatile register (i.e. >>> irrespective of CONFIG_FRAME_POINTER), since the RBP handling would >>> become overly complicated due to the need to save/restore it on the >>> compat mode hypercall path [6th argument]. >>> >>> Note further that for compat mode code paths, saving/restoring R8...R15 >>> is entirely unnecessary - we don't allow those guests to enter 64-bit >>> mode, and hence they have no way of seeing these registers' contents >>> (and there consequently also is no information leak, except if the >>> context saving domctl would be considered such). >>> >>> Finally, note that this may not properly deal with gdbstub's needs, yet >>> (but if so, I can't really suggest adjustments, as I don't know that >>> code). >>> >>> Signed-off-by: Jan Beulich >> >> Ugly. I'd prefer not to bother unless there really is a win we could care >> about here. > > Without this patch, patch 1 doesn't make a lot of sense either (and patch 2 > then is merely cleanup). Okay, can you re-submit with some comments around what the new TRAP flag values mean and how they should be used? Maybe some comments for the save/restore macros, and their new arguments, would be nice too. And are you confident that this approach is maintainable/non-fragile (i.e., we're not going to be continually finding rare cases where registers are being dirtied but not saved/restored)? -- Keir > Jan > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 14:35:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 14:35:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJQ2x-0000F2-CD; Wed, 03 Oct 2012 14:35:35 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJQ2w-0000Ev-2v for xen-devel@lists.xen.org; Wed, 03 Oct 2012 14:35:34 +0000 Received: from [85.158.143.35:32528] by server-3.bemta-4.messagelabs.com id DF/DB-10986-53D4C605; Wed, 03 Oct 2012 14:35:33 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1349274931!12893419!1 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7755 invoked from network); 3 Oct 2012 14:35:32 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 14:35:32 -0000 Received: by eekb47 with SMTP id b47so4321556eek.32 for ; Wed, 03 Oct 2012 07:35:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=2TTFY7yKbVo9n+V3Z00RYf9HfNvwvlMf+IJDbFR1PbQ=; b=kpRPKdN07uoZh5ODP8joL9OEjlO0qO4nAg24683ldOEL03AQ3Ly2d/3GebtmHI56fL zGlC1W+4zhWGfjxO5ucYXTqygLaKTRRaDmBgcxZMADkxxyuGFXSqdqsrRpdLRqbbF/dL +eo7n/tu7kOacE+eUv4vV71r6LFj5DFY8/boV0xrvbPUpkd1BCfBWX1VXZ5bzmvqA2jx XAmwj5ZRCl8e84pV6scUZdOZOevysRm7aJ52gCspZnhWzvWWzDjQ401RR6VAGAWW8zdn k38SqMAkUkPE4p1Hgu4Rn9BQJSfYuqD30/yIu32wPN3e8pEyFfevnjMrc1hp/kZLv6p0 wcIQ== Received: by 10.14.184.133 with SMTP id s5mr3012222eem.31.1349274931191; Wed, 03 Oct 2012 07:35:31 -0700 (PDT) Received: from [192.168.1.69] (host86-183-156-141.range86-183.btcentralplus.com. [86.183.156.141]) by mx.google.com with ESMTPS id i41sm10109190eem.7.2012.10.03.07.35.29 (version=SSLv3 cipher=OTHER); Wed, 03 Oct 2012 07:35:30 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 03 Oct 2012 15:35:27 +0100 From: Keir Fraser To: Jan Beulich Message-ID: Thread-Topic: [Xen-devel] [PATCH 3/3] x86: save/restore only partial register state where possible Thread-Index: Ac2hdFSG1j75QiymQECiXZbJUV578Q== In-Reply-To: <506C461E020000780008D00F@nat28.tlf.novell.com> Mime-version: 1.0 Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH 3/3] x86: save/restore only partial register state where possible X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 03/10/2012 14:05, "Jan Beulich" wrote: >>>> Keir Fraser 10/02/12 7:02 PM >>> >> On 02/10/2012 16:27, "Jan Beulich" wrote: >> >>> ... and make restore conditional not only upon having saved the state, >>> but also upon whether saved state was actually modified (and register >>> values are known to have been preserved). >>> >>> Note that RBP is unconditionally considered a volatile register (i.e. >>> irrespective of CONFIG_FRAME_POINTER), since the RBP handling would >>> become overly complicated due to the need to save/restore it on the >>> compat mode hypercall path [6th argument]. >>> >>> Note further that for compat mode code paths, saving/restoring R8...R15 >>> is entirely unnecessary - we don't allow those guests to enter 64-bit >>> mode, and hence they have no way of seeing these registers' contents >>> (and there consequently also is no information leak, except if the >>> context saving domctl would be considered such). >>> >>> Finally, note that this may not properly deal with gdbstub's needs, yet >>> (but if so, I can't really suggest adjustments, as I don't know that >>> code). >>> >>> Signed-off-by: Jan Beulich >> >> Ugly. I'd prefer not to bother unless there really is a win we could care >> about here. > > Without this patch, patch 1 doesn't make a lot of sense either (and patch 2 > then is merely cleanup). Okay, can you re-submit with some comments around what the new TRAP flag values mean and how they should be used? Maybe some comments for the save/restore macros, and their new arguments, would be nice too. And are you confident that this approach is maintainable/non-fragile (i.e., we're not going to be continually finding rare cases where registers are being dirtied but not saved/restored)? -- Keir > Jan > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 15:00:57 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 15:00:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJQRD-0000Vv-FL; Wed, 03 Oct 2012 15:00:39 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJQRB-0000Vq-6D for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 15:00:37 +0000 Received: from [85.158.143.99:59816] by server-2.bemta-4.messagelabs.com id 17/24-06610-4135C605; Wed, 03 Oct 2012 15:00:36 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1349276433!26607899!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18114 invoked from network); 3 Oct 2012 15:00:34 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 15:00:34 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="14918687" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 15:00:33 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 16:00:33 +0100 Message-ID: <1349276431.650.156.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Konrad Rzeszutek Wilk Date: Wed, 3 Oct 2012 16:00:31 +0100 In-Reply-To: <20121003141116.GA10633@phenom.dumpdata.com> References: <1349272182.650.150.camel@zakaz.uk.xensource.com> <1349272482.650.151.camel@zakaz.uk.xensource.com> <20121003141116.GA10633@phenom.dumpdata.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH] xen: point xen_start_info to a dummy struct for PV on HVM guests X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-10-03 at 15:11 +0100, Konrad Rzeszutek Wilk wrote: > On Wed, Oct 03, 2012 at 02:54:42PM +0100, Ian Campbell wrote: > > On Wed, 2012-10-03 at 14:51 +0100, Stefano Stabellini wrote: > > > On Wed, 3 Oct 2012, Ian Campbell wrote: > > > > On Wed, 2012-10-03 at 14:37 +0100, Stefano Stabellini wrote: > > > > > PV on HVM guests don't have a start_info page mapped by Xen, so > > > > > xen_start_info is just NULL for them. > > > > > That is problem because other parts of the code expect xen_start_info to > > > > > point to something valid, for example xen_initial_domain() is defined as > > > > > follow: > > > > > > > > > > #define xen_initial_domain() (xen_domain() && \ > > > > > xen_start_info->flags & SIF_INITDOMAIN) > > > > > > > > But anyone who calls this before xen_start_info is setup is going to get > > > > a bogus result, specifically in this case they will think they are domU > > > > when in reality they are dom0 -- wouldn't it be better to fix those > > > > callsites? > > > > > > That cannot be the case because setting up xen_start_info is the very > > > first thing that is done, before even calling to C. > > > > On PV, yes, but you are trying to fix PVHVM here, no? > > > > Otherwise if this is always set before calling into C then what is the > > purpose of this patch? > > to fix this - as PVHVM has it set to NULL and we end up de-referencing > the xen_start_info and crashing. As so:: > Right, so returning to my original point: The caller here is calling xen_initial_domain() *before* start info is setup. This is bogus and is your actual bug, all this patch does is hide that real issue. With this "fix" the caller of xen_initial_domain shown in this trace now gets a rubbish result based on the content of a dummy shared info instead of the real answer from that actual shared info. The right fix is to fix the caller to not call xen_initial_domain() until after the shared info has been setup. Maybe that means moving shinfo setup earlier, or maybe it means deferring this call until later in the PVHVM case. > > Decompressing Linux... Parsing ELF... done. > Booting the kernel. > [ 0.000000] Initializing cgroup subsys cpuset > [ 0.000000] Initializing cgroup subsys cpu > [ 0.000000] Linux version 3.6.0upstream-04121-g0313983 (konrad@build.dumpdata.com) (gcc version 4.4.4 20100503 (Red Hat 4.4.4-2) (GCC) ) #1 SMP Tue Oct 2 16:31:21 EDT 2012 > [ 0.000000] Command line: initrd=initramf.gz console=ttyS0,115200 test=net nofb earlyprintk=serial,ttyS0,115200 BOOT_IMAGE=vmlinuz > [ 0.000000] e820: BIOS-provided physical RAM map: > [ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009dfff] usable > [ 0.000000] BIOS-e820: [mem 0x000000000009e000-0x000000000009ffff] reserved > [ 0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved > [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000007fffffff] usable > [ 0.000000] BIOS-e820: [mem 0x00000000fc000000-0x00000000ffffffff] reserved > [ 0.000000] bootconsole [earlyser0] enabled > [ 0.000000] NX (Execute Disable) protection: active > [ 0.000000] DMI 2.4 present. > [ 0.000000] Hypervisor detected: Xen HVM > [ 0.000000] Xen version 4.1. > [ 0.000000] Netfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated NICs. > [ 0.000000] Blkfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated disks. > [ 0.000000] You might have to change the root device > [ 0.000000] from /dev/hd[a-d] to /dev/xvd[a-d] > [ 0.000000] in your root= kernel command line option > [ 0.000000] No AGP bridge found > [ 0.000000] e820: last_pfn = 0x80000 max_arch_pfn = 0x400000000 > [ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 > [ 0.000000] found SMP MP-table at [mem 0x000fbc90-0x000fbc9f] mapped at [ffff8800000fbc90] > [ 0.000000] init_memory_mapping: [mem 0x00000000-0x7fffffff] > [ 0.000000] RAMDISK: [mem 0x7abeb000-0x7ffdefff] > [ 0.000000] ACPI: RSDP 00000000000ea020 00024 (v02 Xen) > [ 0.000000] ACPI: XSDT 00000000fc00f2b0 00034 (v01 Xen HVM 00000000 HVML 00000000) > [ 0.000000] ACPI: FACP 00000000fc00f0d0 000F4 (v04 Xen HVM 00000000 HVML 00000000) > [ 0.000000] ACPI: DSDT 00000000fc003440 0BC09 (v02 Xen HVM 00000000 INTL 20100528) > [ 0.000000] ACPI: FACS 00000000fc003400 00040 > [ 0.000000] ACPI: APIC 00000000fc00f1d0 000D8 (v02 Xen HVM 00000000 HVML 00000000) > [ 0.000000] No NUMA configuration found > [ 0.000000] Faking a node at [mem 0x0000000000000000-0x000000007fffffff] > [ 0.000000] Initmem setup node 0 [mem 0x00000000-0x7fffffff] > [ 0.000000] NODE_DATA [mem 0x7fffc000-0x7fffffff] > [ 0.000000] Zone ranges: > [ 0.000000] DMA [mem 0x00010000-0x00ffffff] > [ 0.000000] DMA32 [mem 0x01000000-0xffffffff] > [ 0.000000] Normal empty > [ 0.000000] Movable zone start for each node > [ 0.000000] Early memory node ranges > [ 0.000000] node 0: [mem 0x00010000-0x0009dfff] > [ 0.000000] node 0: [mem 0x00100000-0x7fffffff] > [ 0.000000] ACPI: PM-Timer IO Port: 0xb008 > [ 0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) > [ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled) > [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] disabled) > [ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] disabled) > [ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x08] disabled) > [ 0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x0a] disabled) > [ 0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x0c] disabled) > [ 0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x0e] disabled) > [ 0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x10] disabled) > [ 0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x12] disabled) > [ 0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x14] disabled) > [ 0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x16] disabled) > [ 0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x18] disabled) > [ 0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x1a] disabled) > [ 0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x1c] disabled) > [ 0.000000] ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0]) > [ 0.000000] IOAPIC[0]: apic_id 1, version 17, address 0xfec00000, GSI 0-47 > [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) > [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 low level) > [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 low level) > [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 low level) > [ 0.000000] Using ACPI (MADT) for SMP configuration information > [ 0.000000] smpboot: Allowing 15 CPUs, 13 hotplug CPUs > [ 0.000000] PM: Registered nosave memory: 000000000009e000 - 00000000000a0000 > [ 0.000000] PM: Registered nosave memory: 00000000000a0000 - 00000000000e0000 > [ 0.000000] PM: Registered nosave memory: 00000000000e0000 - 0000000000100000 > [ 0.000000] e820: [mem 0x80000000-0xfbffffff] available for PCI devices > [ 0.000000] Booting paravirtualized kernel on Xen HVM > [ 0.000000] setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:15 nr_node_ids:1 > [ 0.000000] PERCPU: Embedded 28 pages/cpu @ffff88007a800000 s84352 r8192 d22144 u131072 > [ 0.000000] Built 1 zonelists in Node order, mobility grouping on. Total pages: 517000 > [ 0.000000] Policy zone: DMA32 > [ 0.000000] Kernel command line: initrd=initramf.gz console=ttyS0,115200 test=net nofb earlyprintk=serial,ttyS0,115200 BOOT_IMAGE=vmlinuz > [ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes) > [ 0.000000] __ex_table already sorted, skipping sort > [ 0.000000] Checking aperture... > [ 0.000000] No AGP bridge found > [ 0.000000] Memory: 1967336k/2097152k available (6368k kernel code, 456k absent, 129360k reserved, 4525k data, 752k init) > [ 0.000000] Hierarchical RCU implementation. > [ 0.000000] RCU restricting CPUs from NR_CPUS=512 to nr_cpu_ids=15. > [ 0.000000] NR_IRQS:33024 nr_irqs:1208 16 > [ 0.000000] Xen HVM callback vector for event delivery is enabled > [ 0.000000] Console: colour VGA+ 80x25 > [ 0.000000] BUG: unable to handle kernel NULL pointer dereference at 0000000000000030 > [ 0.000000] IP: [] xen_cons_init+0x1e/0x60 > [ 0.000000] PGD 0 > [ 0.000000] Oops: 0000 [#1] SMP > [ 0.000000] Modules linked in: > [ 0.000000] CPU 0 > [ 0.000000] Pid: 0, comm: swapper/0 Not tainted 3.6.0upstream-04121-g0313983 #1 Xen HVM domU > [ 0.000000] RIP: 0010:[] [] xen_cons_init+0x1e/0x60 > [ 0.000000] RSP: 0000:ffffffff81a01ef8 EFLAGS: 00010202 > [ 0.000000] RAX: 0000000000000000 RBX: ffffffff81b3be60 RCX: 0000000000000002 > [ 0.000000] RDX: ffffffff81a59c40 RSI: ffffffff81a59b01 RDI: ffffffff81ba7e81 > [ 0.000000] RBP: ffffffff81a01ef8 R08: 00000000000003fd R09: 0000000000000020 > [ 0.000000] R10: 0000000000000000 R11: 000000000000000d R12: ffffffff81b008e0 > [ 0.000000] R13: ffffffff81b092e0 R14: 0000000000000000 R15: 0000000000026bf0 > [ 0.000000] FS: 0000000000000000(0000) GS:ffff88007a800000(0000) knlGS:0000000000000000 > [ 0.000000] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > [ 0.000000] CR2: 0000000000000030 CR3: 0000000001a0b000 CR4: 00000000000006b0 > [ 0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > [ 0.000000] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > [ 0.000000] Process swapper/0 (pid: 0, threadinfo ffffffff81a00000, task ffffffff81a13420) > [ 0.000000] Stack: > [ 0.000000] ffffffff81a01f18 ffffffff81aeb9fb ffffffff81b008e0 ffffffffffffffff > [ 0.000000] ffffffff81a01f68 ffffffff81abac39 ffffffff81aba80d 0000000000026bf0 > [ 0.000000] ffffffff81a01f58 ffffffff81b092e0 0000000001000000 0000000001c72000 > [ 0.000000] Call Trace: > [ 0.000000] [] console_init+0x19/0x2a > [ 0.000000] [] start_kernel+0x24a/0x3a3 > [ 0.000000] [] ? kernel_init+0x1e8/0x1e8 > [ 0.000000] [] x86_64_start_reservations+0x131/0x136 > [ 0.000000] [] x86_64_start_kernel+0x103/0x112 > [ 0.000000] Code: 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 8b 0d 5a 2e 7c 00 55 31 c0 48 89 e5 85 c9 74 37 48 8b 05 51 2e 7c 00 48 c7 c2 40 9c a5 81 40 30 02 75 15 83 f9 02 74 27 e8 52 fc ff ff 85 c0 78 15 48 > [ 0.000000] RIP [] xen_cons_init+0x1e/0x60 > [ 0.000000] RSP > [ 0.000000] CR2: 0000000000000030 > [ 0.000000] ---[ end trace 5cb378039a20e088 ]--- > [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task! > > > > > > > > > > > > Perhaps turn this into a static inline with a BUG_ON(!xen_start_info) to > > > > make catching these cases easier? > > > > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 15:00:57 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 15:00:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJQRD-0000Vv-FL; Wed, 03 Oct 2012 15:00:39 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJQRB-0000Vq-6D for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 15:00:37 +0000 Received: from [85.158.143.99:59816] by server-2.bemta-4.messagelabs.com id 17/24-06610-4135C605; Wed, 03 Oct 2012 15:00:36 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1349276433!26607899!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18114 invoked from network); 3 Oct 2012 15:00:34 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 15:00:34 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="14918687" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 15:00:33 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 16:00:33 +0100 Message-ID: <1349276431.650.156.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Konrad Rzeszutek Wilk Date: Wed, 3 Oct 2012 16:00:31 +0100 In-Reply-To: <20121003141116.GA10633@phenom.dumpdata.com> References: <1349272182.650.150.camel@zakaz.uk.xensource.com> <1349272482.650.151.camel@zakaz.uk.xensource.com> <20121003141116.GA10633@phenom.dumpdata.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH] xen: point xen_start_info to a dummy struct for PV on HVM guests X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-10-03 at 15:11 +0100, Konrad Rzeszutek Wilk wrote: > On Wed, Oct 03, 2012 at 02:54:42PM +0100, Ian Campbell wrote: > > On Wed, 2012-10-03 at 14:51 +0100, Stefano Stabellini wrote: > > > On Wed, 3 Oct 2012, Ian Campbell wrote: > > > > On Wed, 2012-10-03 at 14:37 +0100, Stefano Stabellini wrote: > > > > > PV on HVM guests don't have a start_info page mapped by Xen, so > > > > > xen_start_info is just NULL for them. > > > > > That is problem because other parts of the code expect xen_start_info to > > > > > point to something valid, for example xen_initial_domain() is defined as > > > > > follow: > > > > > > > > > > #define xen_initial_domain() (xen_domain() && \ > > > > > xen_start_info->flags & SIF_INITDOMAIN) > > > > > > > > But anyone who calls this before xen_start_info is setup is going to get > > > > a bogus result, specifically in this case they will think they are domU > > > > when in reality they are dom0 -- wouldn't it be better to fix those > > > > callsites? > > > > > > That cannot be the case because setting up xen_start_info is the very > > > first thing that is done, before even calling to C. > > > > On PV, yes, but you are trying to fix PVHVM here, no? > > > > Otherwise if this is always set before calling into C then what is the > > purpose of this patch? > > to fix this - as PVHVM has it set to NULL and we end up de-referencing > the xen_start_info and crashing. As so:: > Right, so returning to my original point: The caller here is calling xen_initial_domain() *before* start info is setup. This is bogus and is your actual bug, all this patch does is hide that real issue. With this "fix" the caller of xen_initial_domain shown in this trace now gets a rubbish result based on the content of a dummy shared info instead of the real answer from that actual shared info. The right fix is to fix the caller to not call xen_initial_domain() until after the shared info has been setup. Maybe that means moving shinfo setup earlier, or maybe it means deferring this call until later in the PVHVM case. > > Decompressing Linux... Parsing ELF... done. > Booting the kernel. > [ 0.000000] Initializing cgroup subsys cpuset > [ 0.000000] Initializing cgroup subsys cpu > [ 0.000000] Linux version 3.6.0upstream-04121-g0313983 (konrad@build.dumpdata.com) (gcc version 4.4.4 20100503 (Red Hat 4.4.4-2) (GCC) ) #1 SMP Tue Oct 2 16:31:21 EDT 2012 > [ 0.000000] Command line: initrd=initramf.gz console=ttyS0,115200 test=net nofb earlyprintk=serial,ttyS0,115200 BOOT_IMAGE=vmlinuz > [ 0.000000] e820: BIOS-provided physical RAM map: > [ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009dfff] usable > [ 0.000000] BIOS-e820: [mem 0x000000000009e000-0x000000000009ffff] reserved > [ 0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved > [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000007fffffff] usable > [ 0.000000] BIOS-e820: [mem 0x00000000fc000000-0x00000000ffffffff] reserved > [ 0.000000] bootconsole [earlyser0] enabled > [ 0.000000] NX (Execute Disable) protection: active > [ 0.000000] DMI 2.4 present. > [ 0.000000] Hypervisor detected: Xen HVM > [ 0.000000] Xen version 4.1. > [ 0.000000] Netfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated NICs. > [ 0.000000] Blkfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated disks. > [ 0.000000] You might have to change the root device > [ 0.000000] from /dev/hd[a-d] to /dev/xvd[a-d] > [ 0.000000] in your root= kernel command line option > [ 0.000000] No AGP bridge found > [ 0.000000] e820: last_pfn = 0x80000 max_arch_pfn = 0x400000000 > [ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 > [ 0.000000] found SMP MP-table at [mem 0x000fbc90-0x000fbc9f] mapped at [ffff8800000fbc90] > [ 0.000000] init_memory_mapping: [mem 0x00000000-0x7fffffff] > [ 0.000000] RAMDISK: [mem 0x7abeb000-0x7ffdefff] > [ 0.000000] ACPI: RSDP 00000000000ea020 00024 (v02 Xen) > [ 0.000000] ACPI: XSDT 00000000fc00f2b0 00034 (v01 Xen HVM 00000000 HVML 00000000) > [ 0.000000] ACPI: FACP 00000000fc00f0d0 000F4 (v04 Xen HVM 00000000 HVML 00000000) > [ 0.000000] ACPI: DSDT 00000000fc003440 0BC09 (v02 Xen HVM 00000000 INTL 20100528) > [ 0.000000] ACPI: FACS 00000000fc003400 00040 > [ 0.000000] ACPI: APIC 00000000fc00f1d0 000D8 (v02 Xen HVM 00000000 HVML 00000000) > [ 0.000000] No NUMA configuration found > [ 0.000000] Faking a node at [mem 0x0000000000000000-0x000000007fffffff] > [ 0.000000] Initmem setup node 0 [mem 0x00000000-0x7fffffff] > [ 0.000000] NODE_DATA [mem 0x7fffc000-0x7fffffff] > [ 0.000000] Zone ranges: > [ 0.000000] DMA [mem 0x00010000-0x00ffffff] > [ 0.000000] DMA32 [mem 0x01000000-0xffffffff] > [ 0.000000] Normal empty > [ 0.000000] Movable zone start for each node > [ 0.000000] Early memory node ranges > [ 0.000000] node 0: [mem 0x00010000-0x0009dfff] > [ 0.000000] node 0: [mem 0x00100000-0x7fffffff] > [ 0.000000] ACPI: PM-Timer IO Port: 0xb008 > [ 0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) > [ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled) > [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] disabled) > [ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] disabled) > [ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x08] disabled) > [ 0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x0a] disabled) > [ 0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x0c] disabled) > [ 0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x0e] disabled) > [ 0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x10] disabled) > [ 0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x12] disabled) > [ 0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x14] disabled) > [ 0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x16] disabled) > [ 0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x18] disabled) > [ 0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x1a] disabled) > [ 0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x1c] disabled) > [ 0.000000] ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0]) > [ 0.000000] IOAPIC[0]: apic_id 1, version 17, address 0xfec00000, GSI 0-47 > [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) > [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 low level) > [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 low level) > [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 low level) > [ 0.000000] Using ACPI (MADT) for SMP configuration information > [ 0.000000] smpboot: Allowing 15 CPUs, 13 hotplug CPUs > [ 0.000000] PM: Registered nosave memory: 000000000009e000 - 00000000000a0000 > [ 0.000000] PM: Registered nosave memory: 00000000000a0000 - 00000000000e0000 > [ 0.000000] PM: Registered nosave memory: 00000000000e0000 - 0000000000100000 > [ 0.000000] e820: [mem 0x80000000-0xfbffffff] available for PCI devices > [ 0.000000] Booting paravirtualized kernel on Xen HVM > [ 0.000000] setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:15 nr_node_ids:1 > [ 0.000000] PERCPU: Embedded 28 pages/cpu @ffff88007a800000 s84352 r8192 d22144 u131072 > [ 0.000000] Built 1 zonelists in Node order, mobility grouping on. Total pages: 517000 > [ 0.000000] Policy zone: DMA32 > [ 0.000000] Kernel command line: initrd=initramf.gz console=ttyS0,115200 test=net nofb earlyprintk=serial,ttyS0,115200 BOOT_IMAGE=vmlinuz > [ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes) > [ 0.000000] __ex_table already sorted, skipping sort > [ 0.000000] Checking aperture... > [ 0.000000] No AGP bridge found > [ 0.000000] Memory: 1967336k/2097152k available (6368k kernel code, 456k absent, 129360k reserved, 4525k data, 752k init) > [ 0.000000] Hierarchical RCU implementation. > [ 0.000000] RCU restricting CPUs from NR_CPUS=512 to nr_cpu_ids=15. > [ 0.000000] NR_IRQS:33024 nr_irqs:1208 16 > [ 0.000000] Xen HVM callback vector for event delivery is enabled > [ 0.000000] Console: colour VGA+ 80x25 > [ 0.000000] BUG: unable to handle kernel NULL pointer dereference at 0000000000000030 > [ 0.000000] IP: [] xen_cons_init+0x1e/0x60 > [ 0.000000] PGD 0 > [ 0.000000] Oops: 0000 [#1] SMP > [ 0.000000] Modules linked in: > [ 0.000000] CPU 0 > [ 0.000000] Pid: 0, comm: swapper/0 Not tainted 3.6.0upstream-04121-g0313983 #1 Xen HVM domU > [ 0.000000] RIP: 0010:[] [] xen_cons_init+0x1e/0x60 > [ 0.000000] RSP: 0000:ffffffff81a01ef8 EFLAGS: 00010202 > [ 0.000000] RAX: 0000000000000000 RBX: ffffffff81b3be60 RCX: 0000000000000002 > [ 0.000000] RDX: ffffffff81a59c40 RSI: ffffffff81a59b01 RDI: ffffffff81ba7e81 > [ 0.000000] RBP: ffffffff81a01ef8 R08: 00000000000003fd R09: 0000000000000020 > [ 0.000000] R10: 0000000000000000 R11: 000000000000000d R12: ffffffff81b008e0 > [ 0.000000] R13: ffffffff81b092e0 R14: 0000000000000000 R15: 0000000000026bf0 > [ 0.000000] FS: 0000000000000000(0000) GS:ffff88007a800000(0000) knlGS:0000000000000000 > [ 0.000000] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > [ 0.000000] CR2: 0000000000000030 CR3: 0000000001a0b000 CR4: 00000000000006b0 > [ 0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > [ 0.000000] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > [ 0.000000] Process swapper/0 (pid: 0, threadinfo ffffffff81a00000, task ffffffff81a13420) > [ 0.000000] Stack: > [ 0.000000] ffffffff81a01f18 ffffffff81aeb9fb ffffffff81b008e0 ffffffffffffffff > [ 0.000000] ffffffff81a01f68 ffffffff81abac39 ffffffff81aba80d 0000000000026bf0 > [ 0.000000] ffffffff81a01f58 ffffffff81b092e0 0000000001000000 0000000001c72000 > [ 0.000000] Call Trace: > [ 0.000000] [] console_init+0x19/0x2a > [ 0.000000] [] start_kernel+0x24a/0x3a3 > [ 0.000000] [] ? kernel_init+0x1e8/0x1e8 > [ 0.000000] [] x86_64_start_reservations+0x131/0x136 > [ 0.000000] [] x86_64_start_kernel+0x103/0x112 > [ 0.000000] Code: 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 8b 0d 5a 2e 7c 00 55 31 c0 48 89 e5 85 c9 74 37 48 8b 05 51 2e 7c 00 48 c7 c2 40 9c a5 81 40 30 02 75 15 83 f9 02 74 27 e8 52 fc ff ff 85 c0 78 15 48 > [ 0.000000] RIP [] xen_cons_init+0x1e/0x60 > [ 0.000000] RSP > [ 0.000000] CR2: 0000000000000030 > [ 0.000000] ---[ end trace 5cb378039a20e088 ]--- > [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task! > > > > > > > > > > > > Perhaps turn this into a static inline with a BUG_ON(!xen_start_info) to > > > > make catching these cases easier? > > > > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 15:29:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 15:29:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJQt2-0000th-7o; Wed, 03 Oct 2012 15:29:24 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJQt0-0000tc-KE for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 15:29:22 +0000 Received: from [85.158.137.99:12292] by server-11.bemta-3.messagelabs.com id C2/0F-21460-1D95C605; Wed, 03 Oct 2012 15:29:21 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-9.tower-217.messagelabs.com!1349278159!16984915!1 X-Originating-IP: [209.85.213.45] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13119 invoked from network); 3 Oct 2012 15:29:20 -0000 Received: from mail-yh0-f45.google.com (HELO mail-yh0-f45.google.com) (209.85.213.45) by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 15:29:20 -0000 Received: by yhpp34 with SMTP id p34so756892yhp.32 for ; Wed, 03 Oct 2012 08:29:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8TI7W8KihvV+iaOL7nib9NntrE+m1kojtg/eYGSqtYc=; b=asaCDE2roYzRpjgE4Z56kEyhItKHr4uUVVxH7mqhyW8a2MgjfE8D5JB8G7fXdN9vd2 dg7Fev8pYyTHf7OzTuFFxkoCjpIDU2GT7yoDsjbMgrPtmNDaS55DIEomMf9Spwoq2RBm JwRDcxNV56DoVMv0YDiM9PhyCKd/qSKVolYHgX+RJxxlzrUgu0UD3U1mECKXDtbFKcOt tee2CNxMv3YQLmRrJJqVr25ygRqUZv5w+/TnSZaK3Sz/00Sivccr7sRlGLbnzz52e9Zv PyFAJnMP8skOYEc6eDQ7nC8ct7GWnpLN/X3GgDGQBpZStXL08j8EOE8tkr5aBlY1V9QL xNYA== MIME-Version: 1.0 Received: by 10.236.151.99 with SMTP id a63mr2109574yhk.120.1349278159069; Wed, 03 Oct 2012 08:29:19 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Wed, 3 Oct 2012 08:29:19 -0700 (PDT) In-Reply-To: References: <1349259542.650.122.camel@zakaz.uk.xensource.com> <1349261397.650.130.camel@zakaz.uk.xensource.com> <1349263669.650.131.camel@zakaz.uk.xensource.com> <1349266207.650.137.camel@zakaz.uk.xensource.com> Date: Wed, 3 Oct 2012 18:29:19 +0300 Message-ID: From: Valtteri Kiviniemi To: Ian Campbell Cc: "Xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Xen 4.2.0, xl toolstack cant launch older domUs X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6199295396303063519==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============6199295396303063519== Content-Type: multipart/alternative; boundary=20cf303a2e355fe26204cb294dc4 --20cf303a2e355fe26204cb294dc4 Content-Type: text/plain; charset=ISO-8859-1 2012/10/3 Valtteri Kiviniemi > > > 2012/10/3 Valtteri Kiviniemi > >> >> 2012/10/3 Ian Campbell >> >>> On Wed, 2012-10-03 at 12:44 +0100, Valtteri Kiviniemi wrote: >>> > Hi, >>> > >>> > Ok, well lets do it thisway. Hopefully I got this right this time. >>> >>> You did, thanks. (aside, can you not top-post please) >>> >>> A bit of a shot in the dark but what is the address size (i.e. 64 bit or >>> 32 bit) for each of your hypervisor, dom0 and domU kernels? >>> >>> Does this change anything: >>> xl cr -p lightning.cfg >>> xenstore-write /local/domain/$(xl domid >>> lightning)/device/vbd/51713/protocol x86_32-abi >>> xl unpause lightning >>> >>> (this assumes the domains cfg is lightning.cfg and name is lightning) >>> >>> Ian. >>> >>> >> Hi, >> >> Sorry for the top posting, I'm at work at the moment and using different >> mail client which is is configured for top posting and I was too lazy to >> change it. >> >> But that did do the trick, the domU is now fillu booting and working! >> >> - Valtteri >> >> > Hi, > > dom0 is 64bit, hypervisor is 64bit and that domU (lightning) is 32bit. > > - Valtteri > Hi, I have now made a startup script that starts the domU first by pausing it, then writes that thingy in xenstore and then unpauses it. Its working now fine. I assume that this is some kind of bug that will be fixed on later Xen versions, or is this caused by something in my end? Do I have to do something else to get the domU to startup normally? - Valtteri --20cf303a2e355fe26204cb294dc4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/10/3 Valtteri Kiviniemi <kiviniemi.valtteri@gmail.com>


= 2012/10/3 Valtteri Kiviniemi <kiviniemi.valtteri@gmail.com&= gt;

2012/10/3 Ian Campbell <Ian.Campbell@citrix.com>
On Wed, 2012-10-03 at 12:44 +0100, Valtteri Kiviniemi wrote:
> Hi,
>
> Ok, well lets do it thisway. Hopefully I got this right this time.

You did, thanks. (aside, can you not top-post please)

A bit of a shot in the dark but what is the address size (i.e. 64 bit or 32 bit) for each of your hypervisor, dom0 and domU kernels?

Does this change anything:
=A0 =A0 =A0 =A0 xl cr -p lightning.cfg
=A0 =A0 =A0 =A0 xenstore-write /local/domain/$(xl domid lightning)/device/v= bd/51713/protocol x86_32-abi
=A0 =A0 =A0 =A0 xl unpause lightning

(this assumes the domains cfg is lightning.cfg and name is lightning)

Ian.


Hi,

Sorry for th= e top posting, I'm at work at the moment and using different mail clien= t which is is configured for top posting and I was too lazy to change it.
But that did do the trick, the domU is now fillu booting and working!

- Valtteri


Hi,

dom0 is 64bit, hypervisor is = 64bit and that domU (lightning) is 32bit.

- Valtteri

Hi,

I have now made a startup s= cript that starts the domU first by pausing it, then writes that thingy in = xenstore and then unpauses it. Its working now fine. I assume that this is = some kind of bug that will be fixed on later Xen versions, or is this cause= d by something in my end? Do I have to do something else to get the domU to= startup normally?

- Valtteri
--20cf303a2e355fe26204cb294dc4-- --===============6199295396303063519== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6199295396303063519==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 15:29:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 15:29:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJQt2-0000th-7o; Wed, 03 Oct 2012 15:29:24 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJQt0-0000tc-KE for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 15:29:22 +0000 Received: from [85.158.137.99:12292] by server-11.bemta-3.messagelabs.com id C2/0F-21460-1D95C605; Wed, 03 Oct 2012 15:29:21 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-9.tower-217.messagelabs.com!1349278159!16984915!1 X-Originating-IP: [209.85.213.45] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13119 invoked from network); 3 Oct 2012 15:29:20 -0000 Received: from mail-yh0-f45.google.com (HELO mail-yh0-f45.google.com) (209.85.213.45) by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 15:29:20 -0000 Received: by yhpp34 with SMTP id p34so756892yhp.32 for ; Wed, 03 Oct 2012 08:29:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8TI7W8KihvV+iaOL7nib9NntrE+m1kojtg/eYGSqtYc=; b=asaCDE2roYzRpjgE4Z56kEyhItKHr4uUVVxH7mqhyW8a2MgjfE8D5JB8G7fXdN9vd2 dg7Fev8pYyTHf7OzTuFFxkoCjpIDU2GT7yoDsjbMgrPtmNDaS55DIEomMf9Spwoq2RBm JwRDcxNV56DoVMv0YDiM9PhyCKd/qSKVolYHgX+RJxxlzrUgu0UD3U1mECKXDtbFKcOt tee2CNxMv3YQLmRrJJqVr25ygRqUZv5w+/TnSZaK3Sz/00Sivccr7sRlGLbnzz52e9Zv PyFAJnMP8skOYEc6eDQ7nC8ct7GWnpLN/X3GgDGQBpZStXL08j8EOE8tkr5aBlY1V9QL xNYA== MIME-Version: 1.0 Received: by 10.236.151.99 with SMTP id a63mr2109574yhk.120.1349278159069; Wed, 03 Oct 2012 08:29:19 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Wed, 3 Oct 2012 08:29:19 -0700 (PDT) In-Reply-To: References: <1349259542.650.122.camel@zakaz.uk.xensource.com> <1349261397.650.130.camel@zakaz.uk.xensource.com> <1349263669.650.131.camel@zakaz.uk.xensource.com> <1349266207.650.137.camel@zakaz.uk.xensource.com> Date: Wed, 3 Oct 2012 18:29:19 +0300 Message-ID: From: Valtteri Kiviniemi To: Ian Campbell Cc: "Xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Xen 4.2.0, xl toolstack cant launch older domUs X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6199295396303063519==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============6199295396303063519== Content-Type: multipart/alternative; boundary=20cf303a2e355fe26204cb294dc4 --20cf303a2e355fe26204cb294dc4 Content-Type: text/plain; charset=ISO-8859-1 2012/10/3 Valtteri Kiviniemi > > > 2012/10/3 Valtteri Kiviniemi > >> >> 2012/10/3 Ian Campbell >> >>> On Wed, 2012-10-03 at 12:44 +0100, Valtteri Kiviniemi wrote: >>> > Hi, >>> > >>> > Ok, well lets do it thisway. Hopefully I got this right this time. >>> >>> You did, thanks. (aside, can you not top-post please) >>> >>> A bit of a shot in the dark but what is the address size (i.e. 64 bit or >>> 32 bit) for each of your hypervisor, dom0 and domU kernels? >>> >>> Does this change anything: >>> xl cr -p lightning.cfg >>> xenstore-write /local/domain/$(xl domid >>> lightning)/device/vbd/51713/protocol x86_32-abi >>> xl unpause lightning >>> >>> (this assumes the domains cfg is lightning.cfg and name is lightning) >>> >>> Ian. >>> >>> >> Hi, >> >> Sorry for the top posting, I'm at work at the moment and using different >> mail client which is is configured for top posting and I was too lazy to >> change it. >> >> But that did do the trick, the domU is now fillu booting and working! >> >> - Valtteri >> >> > Hi, > > dom0 is 64bit, hypervisor is 64bit and that domU (lightning) is 32bit. > > - Valtteri > Hi, I have now made a startup script that starts the domU first by pausing it, then writes that thingy in xenstore and then unpauses it. Its working now fine. I assume that this is some kind of bug that will be fixed on later Xen versions, or is this caused by something in my end? Do I have to do something else to get the domU to startup normally? - Valtteri --20cf303a2e355fe26204cb294dc4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/10/3 Valtteri Kiviniemi <kiviniemi.valtteri@gmail.com>


= 2012/10/3 Valtteri Kiviniemi <kiviniemi.valtteri@gmail.com&= gt;

2012/10/3 Ian Campbell <Ian.Campbell@citrix.com>
On Wed, 2012-10-03 at 12:44 +0100, Valtteri Kiviniemi wrote:
> Hi,
>
> Ok, well lets do it thisway. Hopefully I got this right this time.

You did, thanks. (aside, can you not top-post please)

A bit of a shot in the dark but what is the address size (i.e. 64 bit or 32 bit) for each of your hypervisor, dom0 and domU kernels?

Does this change anything:
=A0 =A0 =A0 =A0 xl cr -p lightning.cfg
=A0 =A0 =A0 =A0 xenstore-write /local/domain/$(xl domid lightning)/device/v= bd/51713/protocol x86_32-abi
=A0 =A0 =A0 =A0 xl unpause lightning

(this assumes the domains cfg is lightning.cfg and name is lightning)

Ian.


Hi,

Sorry for th= e top posting, I'm at work at the moment and using different mail clien= t which is is configured for top posting and I was too lazy to change it.
But that did do the trick, the domU is now fillu booting and working!

- Valtteri


Hi,

dom0 is 64bit, hypervisor is = 64bit and that domU (lightning) is 32bit.

- Valtteri

Hi,

I have now made a startup s= cript that starts the domU first by pausing it, then writes that thingy in = xenstore and then unpauses it. Its working now fine. I assume that this is = some kind of bug that will be fixed on later Xen versions, or is this cause= d by something in my end? Do I have to do something else to get the domU to= startup normally?

- Valtteri
--20cf303a2e355fe26204cb294dc4-- --===============6199295396303063519== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6199295396303063519==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 15:31:17 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 15:31:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJQuW-0000yO-NX; Wed, 03 Oct 2012 15:30:56 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJQuU-0000xw-Rn for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 15:30:55 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1349278247!3536402!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12950 invoked from network); 3 Oct 2012 15:30:48 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 15:30:48 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="14919621" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 15:30:47 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 16:30:47 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TJQuN-0005Ar-7p; Wed, 03 Oct 2012 15:30:47 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1TJQuM-0006H1-GL; Wed, 03 Oct 2012 16:30:46 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Wed, 3 Oct 2012 16:30:46 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 13914: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 13914 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13914/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 5 xen-boot fail like 13913 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail like 13913 test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail like 13913 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail like 13913 Tests which did not succeed, but are not blocking: test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: xen 59dc1c2e7c54 baseline version: xen 87bf99fad7a9 ------------------------------------------------------------ People who touched revisions under test: "Nakajima, Jun" David Vrabel Frediano Ziglio George Dunlap Jan Beulich Keir Fraser Matthew Fioravante ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-amd64-amd64-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable + revision=59dc1c2e7c54 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 59dc1c2e7c54 + branch=xen-unstable + revision=59dc1c2e7c54 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + . cri-common ++ umask 002 + select_xenbranch + case "$branch" in + tree=xen + xenbranch=xen-unstable + '[' xxen = xlinux ']' + linuxbranch=linux + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg ++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.xen-unstable ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git ++ : daily-cron.xen-unstable + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git + info_linux_tree xen-unstable + case $1 in + return 1 + case "$branch" in + cd /export/home/osstest/repos/xen-unstable.hg + hg push -r 59dc1c2e7c54 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 4 changesets with 17 changes to 9 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 15:31:17 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 15:31:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJQuW-0000yO-NX; Wed, 03 Oct 2012 15:30:56 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJQuU-0000xw-Rn for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 15:30:55 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1349278247!3536402!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12950 invoked from network); 3 Oct 2012 15:30:48 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 15:30:48 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="14919621" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 15:30:47 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 16:30:47 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TJQuN-0005Ar-7p; Wed, 03 Oct 2012 15:30:47 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1TJQuM-0006H1-GL; Wed, 03 Oct 2012 16:30:46 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Wed, 3 Oct 2012 16:30:46 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 13914: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 13914 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13914/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 5 xen-boot fail like 13913 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail like 13913 test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail like 13913 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail like 13913 Tests which did not succeed, but are not blocking: test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: xen 59dc1c2e7c54 baseline version: xen 87bf99fad7a9 ------------------------------------------------------------ People who touched revisions under test: "Nakajima, Jun" David Vrabel Frediano Ziglio George Dunlap Jan Beulich Keir Fraser Matthew Fioravante ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-amd64-amd64-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable + revision=59dc1c2e7c54 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 59dc1c2e7c54 + branch=xen-unstable + revision=59dc1c2e7c54 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + . cri-common ++ umask 002 + select_xenbranch + case "$branch" in + tree=xen + xenbranch=xen-unstable + '[' xxen = xlinux ']' + linuxbranch=linux + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg ++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.xen-unstable ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git ++ : daily-cron.xen-unstable + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git + info_linux_tree xen-unstable + case $1 in + return 1 + case "$branch" in + cd /export/home/osstest/repos/xen-unstable.hg + hg push -r 59dc1c2e7c54 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 4 changesets with 17 changes to 9 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 15:37:11 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 15:37:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJR0C-0001NL-Tn; Wed, 03 Oct 2012 15:36:48 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJR0B-0001ND-G1 for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 15:36:47 +0000 Received: from [85.158.143.99:36261] by server-1.bemta-4.messagelabs.com id 70/46-05684-E8B5C605; Wed, 03 Oct 2012 15:36:46 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1349278606!26479426!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16501 invoked from network); 3 Oct 2012 15:36:46 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 15:36:46 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="14919740" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 15:36:45 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 16:36:45 +0100 Message-ID: <1349278604.650.162.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Valtteri Kiviniemi Date: Wed, 3 Oct 2012 16:36:44 +0100 In-Reply-To: References: <1349259542.650.122.camel@zakaz.uk.xensource.com> <1349261397.650.130.camel@zakaz.uk.xensource.com> <1349263669.650.131.camel@zakaz.uk.xensource.com> <1349266207.650.137.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Xen 4.2.0, xl toolstack cant launch older domUs X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-10-03 at 16:29 +0100, Valtteri Kiviniemi wrote: > > > 2012/10/3 Valtteri Kiviniemi > > > 2012/10/3 Valtteri Kiviniemi > > 2012/10/3 Ian Campbell > On Wed, 2012-10-03 at 12:44 +0100, Valtteri > Kiviniemi wrote: > > Hi, > > > > Ok, well lets do it thisway. Hopefully I got > this right this time. > > > You did, thanks. (aside, can you not top-post > please) > > A bit of a shot in the dark but what is the > address size (i.e. 64 bit or > 32 bit) for each of your hypervisor, dom0 and > domU kernels? > > Does this change anything: > xl cr -p lightning.cfg > xenstore-write /local/domain/$(xl > domid lightning)/device/vbd/51713/protocol > x86_32-abi > xl unpause lightning > > (this assumes the domains cfg is lightning.cfg > and name is lightning) > > Ian. > > > Hi, > > Sorry for the top posting, I'm at work at the moment > and using different mail client which is is configured > for top posting and I was too lazy to change it. > > But that did do the trick, the domU is now fillu > booting and working! > > - Valtteri > > > > > Hi, > > dom0 is 64bit, hypervisor is 64bit and that domU (lightning) > is 32bit. > > - Valtteri > > Hi, > > I have now made a startup script that starts the domU first by pausing > it, then writes that thingy in xenstore and then unpauses it. Its > working now fine. I assume that this is some kind of bug that will be > fixed on later Xen versions, or is this caused by something in my end? > Do I have to do something else to get the domU to startup normally? I'm undecided at the moment whether this represents a bug in the old domU kernel, or something wrong with the toolstack. Can you tell me what flavour (i.e. address width, 32 or 64) of hypervisor, dom0 kernel and domU kernel you are using is? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 15:37:11 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 15:37:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJR0C-0001NL-Tn; Wed, 03 Oct 2012 15:36:48 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJR0B-0001ND-G1 for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 15:36:47 +0000 Received: from [85.158.143.99:36261] by server-1.bemta-4.messagelabs.com id 70/46-05684-E8B5C605; Wed, 03 Oct 2012 15:36:46 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1349278606!26479426!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16501 invoked from network); 3 Oct 2012 15:36:46 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 15:36:46 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="14919740" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 15:36:45 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 16:36:45 +0100 Message-ID: <1349278604.650.162.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Valtteri Kiviniemi Date: Wed, 3 Oct 2012 16:36:44 +0100 In-Reply-To: References: <1349259542.650.122.camel@zakaz.uk.xensource.com> <1349261397.650.130.camel@zakaz.uk.xensource.com> <1349263669.650.131.camel@zakaz.uk.xensource.com> <1349266207.650.137.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Xen 4.2.0, xl toolstack cant launch older domUs X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-10-03 at 16:29 +0100, Valtteri Kiviniemi wrote: > > > 2012/10/3 Valtteri Kiviniemi > > > 2012/10/3 Valtteri Kiviniemi > > 2012/10/3 Ian Campbell > On Wed, 2012-10-03 at 12:44 +0100, Valtteri > Kiviniemi wrote: > > Hi, > > > > Ok, well lets do it thisway. Hopefully I got > this right this time. > > > You did, thanks. (aside, can you not top-post > please) > > A bit of a shot in the dark but what is the > address size (i.e. 64 bit or > 32 bit) for each of your hypervisor, dom0 and > domU kernels? > > Does this change anything: > xl cr -p lightning.cfg > xenstore-write /local/domain/$(xl > domid lightning)/device/vbd/51713/protocol > x86_32-abi > xl unpause lightning > > (this assumes the domains cfg is lightning.cfg > and name is lightning) > > Ian. > > > Hi, > > Sorry for the top posting, I'm at work at the moment > and using different mail client which is is configured > for top posting and I was too lazy to change it. > > But that did do the trick, the domU is now fillu > booting and working! > > - Valtteri > > > > > Hi, > > dom0 is 64bit, hypervisor is 64bit and that domU (lightning) > is 32bit. > > - Valtteri > > Hi, > > I have now made a startup script that starts the domU first by pausing > it, then writes that thingy in xenstore and then unpauses it. Its > working now fine. I assume that this is some kind of bug that will be > fixed on later Xen versions, or is this caused by something in my end? > Do I have to do something else to get the domU to startup normally? I'm undecided at the moment whether this represents a bug in the old domU kernel, or something wrong with the toolstack. Can you tell me what flavour (i.e. address width, 32 or 64) of hypervisor, dom0 kernel and domU kernel you are using is? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 15:40:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 15:40:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJR3J-0001UR-Ga; Wed, 03 Oct 2012 15:40:01 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJR3H-0001UB-R7 for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 15:40:00 +0000 Received: from [85.158.137.99:35795] by server-2.bemta-3.messagelabs.com id CB/54-16514-F4C5C605; Wed, 03 Oct 2012 15:39:59 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-9.tower-217.messagelabs.com!1349278796!16986440!1 X-Originating-IP: [209.85.161.173] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8240 invoked from network); 3 Oct 2012 15:39:58 -0000 Received: from mail-gg0-f173.google.com (HELO mail-gg0-f173.google.com) (209.85.161.173) by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 15:39:58 -0000 Received: by ggcs5 with SMTP id s5so690105ggc.32 for ; Wed, 03 Oct 2012 08:39:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Z5uh08f0Xrh4FJf4eaDHvUBKtbQIZlTquMVO3zeHPd4=; b=uGpWZFjMXCghUhuJD8Q+CsKk2Jao1Zbn/YSlPN4j69i2S5n1oWrximg0W48/yvyjrY 8+yeIePO+FTwwEPuvjiFSqK/o+Y4aUOaBeoQePC3wA5cRPT6lEesiNz8B+k54bqczf+O idESs/uosl/QZTGV3gCdS7SmD4mu9qVMeio+a9Af3jFRgN3Ml4aJ1gp2qjO7s7d4M6gs rUTG8P5fwM2RSJWwMx5QPxwmJOfP2nGGgnK0mNW6DNNqUrFn+BYrN6CmV+mFMd4eMfMy E/wl/vi7cWiYVhcMq73y4VCpn8/m1r++85/tY31E8C42X7q3YvYWWBslBqRq6s4fS5R0 aGWg== MIME-Version: 1.0 Received: by 10.236.137.70 with SMTP id x46mr2309111yhi.12.1349278796586; Wed, 03 Oct 2012 08:39:56 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Wed, 3 Oct 2012 08:39:56 -0700 (PDT) In-Reply-To: <1349278604.650.162.camel@zakaz.uk.xensource.com> References: <1349259542.650.122.camel@zakaz.uk.xensource.com> <1349261397.650.130.camel@zakaz.uk.xensource.com> <1349263669.650.131.camel@zakaz.uk.xensource.com> <1349266207.650.137.camel@zakaz.uk.xensource.com> <1349278604.650.162.camel@zakaz.uk.xensource.com> Date: Wed, 3 Oct 2012 18:39:56 +0300 Message-ID: From: Valtteri Kiviniemi To: Ian Campbell Cc: "Xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Xen 4.2.0, xl toolstack cant launch older domUs X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============9175924764614365842==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============9175924764614365842== Content-Type: multipart/alternative; boundary=20cf303ea8ce5f9cbd04cb29739e --20cf303ea8ce5f9cbd04cb29739e Content-Type: text/plain; charset=ISO-8859-1 2012/10/3 Ian Campbell > On Wed, 2012-10-03 at 16:29 +0100, Valtteri Kiviniemi wrote: > > > > > > 2012/10/3 Valtteri Kiviniemi > > > > > > 2012/10/3 Valtteri Kiviniemi > > > > 2012/10/3 Ian Campbell > > On Wed, 2012-10-03 at 12:44 +0100, Valtteri > > Kiviniemi wrote: > > > Hi, > > > > > > Ok, well lets do it thisway. Hopefully I got > > this right this time. > > > > > > You did, thanks. (aside, can you not top-post > > please) > > > > A bit of a shot in the dark but what is the > > address size (i.e. 64 bit or > > 32 bit) for each of your hypervisor, dom0 and > > domU kernels? > > > > Does this change anything: > > xl cr -p lightning.cfg > > xenstore-write /local/domain/$(xl > > domid lightning)/device/vbd/51713/protocol > > x86_32-abi > > xl unpause lightning > > > > (this assumes the domains cfg is lightning.cfg > > and name is lightning) > > > > Ian. > > > > > > Hi, > > > > Sorry for the top posting, I'm at work at the moment > > and using different mail client which is is configured > > for top posting and I was too lazy to change it. > > > > But that did do the trick, the domU is now fillu > > booting and working! > > > > - Valtteri > > > > > > > > > > Hi, > > > > dom0 is 64bit, hypervisor is 64bit and that domU (lightning) > > is 32bit. > > > > - Valtteri > > > > Hi, > > > > I have now made a startup script that starts the domU first by pausing > > it, then writes that thingy in xenstore and then unpauses it. Its > > working now fine. I assume that this is some kind of bug that will be > > fixed on later Xen versions, or is this caused by something in my end? > > Do I have to do something else to get the domU to startup normally? > > I'm undecided at the moment whether this represents a bug in the old > domU kernel, or something wrong with the toolstack. > > Can you tell me what flavour (i.e. address width, 32 or 64) of > hypervisor, dom0 kernel and domU kernel you are using is? > > Ian. > > Hi, Hypervisor is 64bit, dom0 is 64bit but the domU is 32bit. If this is what you meant? - Valtteri --20cf303ea8ce5f9cbd04cb29739e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/10/3 Ian Campbell <Ian.Campb= ell@citrix.com>
On Wed, 2012-10-03 at 16:29 +0100, = Valtteri Kiviniemi wrote:
>
>
> 2012/10/3 Valtteri Kiviniemi <kiviniemi.valtteri@gmail.com>
>
>
> =A0 =A0 =A0 =A0 2012/10/3 Valtteri Kiviniemi <kiviniemi.valtteri@gmail.com>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2012/10/3 Ian Campbell <Ian.Campbell@citrix.com>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 On Wed, 2012-10-03 at = 12:44 +0100, Valtteri
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Kiviniemi wrote:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > Hi,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > Ok, well lets do = it thisway. Hopefully I got
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 this right this time.<= br> >
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 You did, thanks. (asid= e, can you not top-post
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 please)
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 A bit of a shot in the= dark but what is the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 address size (i.e. 64 = bit or
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 32 bit) for each of yo= ur hypervisor, dom0 and
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 domU kernels?
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Does this change anyth= ing:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 xl cr = -p lightning.cfg
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 xensto= re-write /local/domain/$(xl
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 domid lightning)/devic= e/vbd/51713/protocol
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 x86_32-abi
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 xl unp= ause lightning
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (this assumes the doma= ins cfg is lightning.cfg
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 and name is lightning)=
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ian.
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Hi,
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Sorry for the top posting, I'm at = work at the moment
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 and using different mail client which = is is configured
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 for top posting and I was too lazy to = change it.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 But that did do the trick, the domU is= now fillu
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 booting and working!
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - Valtteri
>
>
>
>
> =A0 =A0 =A0 =A0 Hi,
>
> =A0 =A0 =A0 =A0 dom0 is 64bit, hypervisor is 64bit and that domU (ligh= tning)
> =A0 =A0 =A0 =A0 is 32bit.
>
> =A0 =A0 =A0 =A0 - Valtteri
>
> Hi,
>
> I have now made a startup script that starts the domU first by pausing=
> it, then writes that thingy in xenstore and then unpauses it. Its
> working now fine. I assume that this is some kind of bug that will be<= br> > fixed on later Xen versions, or is this caused by something in my end?=
> Do I have to do something else to get the domU to startup normally?
I'm undecided at the moment whether this represents a bug i= n the old
domU kernel, or something wrong with the toolstack.

Can you tell me what flavour (i.e. address width, 32 or 64) of
hypervisor, dom0 kernel and domU kernel you are using is?

Ian.


Hi,

Hypervisor is 64bit, dom0 i= s 64bit but the domU is 32bit. If this is what you meant?

- Valtteri=
--20cf303ea8ce5f9cbd04cb29739e-- --===============9175924764614365842== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============9175924764614365842==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 15:40:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 15:40:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJR3J-0001UR-Ga; Wed, 03 Oct 2012 15:40:01 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJR3H-0001UB-R7 for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 15:40:00 +0000 Received: from [85.158.137.99:35795] by server-2.bemta-3.messagelabs.com id CB/54-16514-F4C5C605; Wed, 03 Oct 2012 15:39:59 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-9.tower-217.messagelabs.com!1349278796!16986440!1 X-Originating-IP: [209.85.161.173] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8240 invoked from network); 3 Oct 2012 15:39:58 -0000 Received: from mail-gg0-f173.google.com (HELO mail-gg0-f173.google.com) (209.85.161.173) by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 15:39:58 -0000 Received: by ggcs5 with SMTP id s5so690105ggc.32 for ; Wed, 03 Oct 2012 08:39:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Z5uh08f0Xrh4FJf4eaDHvUBKtbQIZlTquMVO3zeHPd4=; b=uGpWZFjMXCghUhuJD8Q+CsKk2Jao1Zbn/YSlPN4j69i2S5n1oWrximg0W48/yvyjrY 8+yeIePO+FTwwEPuvjiFSqK/o+Y4aUOaBeoQePC3wA5cRPT6lEesiNz8B+k54bqczf+O idESs/uosl/QZTGV3gCdS7SmD4mu9qVMeio+a9Af3jFRgN3Ml4aJ1gp2qjO7s7d4M6gs rUTG8P5fwM2RSJWwMx5QPxwmJOfP2nGGgnK0mNW6DNNqUrFn+BYrN6CmV+mFMd4eMfMy E/wl/vi7cWiYVhcMq73y4VCpn8/m1r++85/tY31E8C42X7q3YvYWWBslBqRq6s4fS5R0 aGWg== MIME-Version: 1.0 Received: by 10.236.137.70 with SMTP id x46mr2309111yhi.12.1349278796586; Wed, 03 Oct 2012 08:39:56 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Wed, 3 Oct 2012 08:39:56 -0700 (PDT) In-Reply-To: <1349278604.650.162.camel@zakaz.uk.xensource.com> References: <1349259542.650.122.camel@zakaz.uk.xensource.com> <1349261397.650.130.camel@zakaz.uk.xensource.com> <1349263669.650.131.camel@zakaz.uk.xensource.com> <1349266207.650.137.camel@zakaz.uk.xensource.com> <1349278604.650.162.camel@zakaz.uk.xensource.com> Date: Wed, 3 Oct 2012 18:39:56 +0300 Message-ID: From: Valtteri Kiviniemi To: Ian Campbell Cc: "Xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Xen 4.2.0, xl toolstack cant launch older domUs X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============9175924764614365842==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============9175924764614365842== Content-Type: multipart/alternative; boundary=20cf303ea8ce5f9cbd04cb29739e --20cf303ea8ce5f9cbd04cb29739e Content-Type: text/plain; charset=ISO-8859-1 2012/10/3 Ian Campbell > On Wed, 2012-10-03 at 16:29 +0100, Valtteri Kiviniemi wrote: > > > > > > 2012/10/3 Valtteri Kiviniemi > > > > > > 2012/10/3 Valtteri Kiviniemi > > > > 2012/10/3 Ian Campbell > > On Wed, 2012-10-03 at 12:44 +0100, Valtteri > > Kiviniemi wrote: > > > Hi, > > > > > > Ok, well lets do it thisway. Hopefully I got > > this right this time. > > > > > > You did, thanks. (aside, can you not top-post > > please) > > > > A bit of a shot in the dark but what is the > > address size (i.e. 64 bit or > > 32 bit) for each of your hypervisor, dom0 and > > domU kernels? > > > > Does this change anything: > > xl cr -p lightning.cfg > > xenstore-write /local/domain/$(xl > > domid lightning)/device/vbd/51713/protocol > > x86_32-abi > > xl unpause lightning > > > > (this assumes the domains cfg is lightning.cfg > > and name is lightning) > > > > Ian. > > > > > > Hi, > > > > Sorry for the top posting, I'm at work at the moment > > and using different mail client which is is configured > > for top posting and I was too lazy to change it. > > > > But that did do the trick, the domU is now fillu > > booting and working! > > > > - Valtteri > > > > > > > > > > Hi, > > > > dom0 is 64bit, hypervisor is 64bit and that domU (lightning) > > is 32bit. > > > > - Valtteri > > > > Hi, > > > > I have now made a startup script that starts the domU first by pausing > > it, then writes that thingy in xenstore and then unpauses it. Its > > working now fine. I assume that this is some kind of bug that will be > > fixed on later Xen versions, or is this caused by something in my end? > > Do I have to do something else to get the domU to startup normally? > > I'm undecided at the moment whether this represents a bug in the old > domU kernel, or something wrong with the toolstack. > > Can you tell me what flavour (i.e. address width, 32 or 64) of > hypervisor, dom0 kernel and domU kernel you are using is? > > Ian. > > Hi, Hypervisor is 64bit, dom0 is 64bit but the domU is 32bit. If this is what you meant? - Valtteri --20cf303ea8ce5f9cbd04cb29739e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/10/3 Ian Campbell <Ian.Campb= ell@citrix.com>
On Wed, 2012-10-03 at 16:29 +0100, = Valtteri Kiviniemi wrote:
>
>
> 2012/10/3 Valtteri Kiviniemi <kiviniemi.valtteri@gmail.com>
>
>
> =A0 =A0 =A0 =A0 2012/10/3 Valtteri Kiviniemi <kiviniemi.valtteri@gmail.com>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2012/10/3 Ian Campbell <Ian.Campbell@citrix.com>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 On Wed, 2012-10-03 at = 12:44 +0100, Valtteri
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Kiviniemi wrote:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > Hi,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > Ok, well lets do = it thisway. Hopefully I got
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 this right this time.<= br> >
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 You did, thanks. (asid= e, can you not top-post
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 please)
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 A bit of a shot in the= dark but what is the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 address size (i.e. 64 = bit or
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 32 bit) for each of yo= ur hypervisor, dom0 and
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 domU kernels?
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Does this change anyth= ing:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 xl cr = -p lightning.cfg
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 xensto= re-write /local/domain/$(xl
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 domid lightning)/devic= e/vbd/51713/protocol
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 x86_32-abi
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 xl unp= ause lightning
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (this assumes the doma= ins cfg is lightning.cfg
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 and name is lightning)=
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ian.
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Hi,
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Sorry for the top posting, I'm at = work at the moment
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 and using different mail client which = is is configured
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 for top posting and I was too lazy to = change it.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 But that did do the trick, the domU is= now fillu
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 booting and working!
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - Valtteri
>
>
>
>
> =A0 =A0 =A0 =A0 Hi,
>
> =A0 =A0 =A0 =A0 dom0 is 64bit, hypervisor is 64bit and that domU (ligh= tning)
> =A0 =A0 =A0 =A0 is 32bit.
>
> =A0 =A0 =A0 =A0 - Valtteri
>
> Hi,
>
> I have now made a startup script that starts the domU first by pausing=
> it, then writes that thingy in xenstore and then unpauses it. Its
> working now fine. I assume that this is some kind of bug that will be<= br> > fixed on later Xen versions, or is this caused by something in my end?=
> Do I have to do something else to get the domU to startup normally?
I'm undecided at the moment whether this represents a bug i= n the old
domU kernel, or something wrong with the toolstack.

Can you tell me what flavour (i.e. address width, 32 or 64) of
hypervisor, dom0 kernel and domU kernel you are using is?

Ian.


Hi,

Hypervisor is 64bit, dom0 i= s 64bit but the domU is 32bit. If this is what you meant?

- Valtteri=
--20cf303ea8ce5f9cbd04cb29739e-- --===============9175924764614365842== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============9175924764614365842==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 15:43:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 15:43:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJR60-0001dy-7W; Wed, 03 Oct 2012 15:42:48 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJR5y-0001dk-Tx for Xen-devel@lists.xensource.com; Wed, 03 Oct 2012 15:42:47 +0000 Received: from [85.158.139.211:48006] by server-14.bemta-5.messagelabs.com id E4/E5-05772-6FC5C605; Wed, 03 Oct 2012 15:42:46 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-206.messagelabs.com!1349278965!19435931!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5559 invoked from network); 3 Oct 2012 15:42:45 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 15:42:45 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="14919879" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 15:42:44 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 16:42:44 +0100 Message-ID: <1349278963.650.164.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Mukesh Rathor Date: Wed, 3 Oct 2012 16:42:43 +0100 In-Reply-To: <20120921121556.1a0ea8af@mantra.us.oracle.com> References: <20120921121556.1a0ea8af@mantra.us.oracle.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h > index 6a198e4..6c5ad83 100644 > --- a/include/xen/xen-ops.h > +++ b/include/xen/xen-ops.h > @@ -24,9 +24,19 @@ int xen_create_contiguous_region(unsigned long vstart, unsigned int order, > void xen_destroy_contiguous_region(unsigned long vstart, unsigned int order); > > struct vm_area_struct; > +struct xen_pvh_pfn_info; If you move the struct def'n up you don't need this forward decl. > int xen_remap_domain_mfn_range(struct vm_area_struct *vma, > unsigned long addr, > unsigned long mfn, int nr, > - pgprot_t prot, unsigned domid); > + pgprot_t prot, unsigned domid, > + struct xen_pvh_pfn_info *pvhp); > +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma, > + struct xen_pvh_pfn_info *pvhp); > + > +struct xen_pvh_pfn_info { Can we call this xen_remap_mfn_info or something? PVH is x86 specific while this struct is also useful on ARM. > + struct page **pi_paga; /* pfn info page array */ can we just call this "pages"? paga is pretty meaningless. > + int pi_num_pgs; > + int pi_next_todo; I don't think we need the pi_ prefix for any of these. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 15:43:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 15:43:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJR60-0001dy-7W; Wed, 03 Oct 2012 15:42:48 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJR5y-0001dk-Tx for Xen-devel@lists.xensource.com; Wed, 03 Oct 2012 15:42:47 +0000 Received: from [85.158.139.211:48006] by server-14.bemta-5.messagelabs.com id E4/E5-05772-6FC5C605; Wed, 03 Oct 2012 15:42:46 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-206.messagelabs.com!1349278965!19435931!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5559 invoked from network); 3 Oct 2012 15:42:45 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 15:42:45 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="14919879" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 15:42:44 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 16:42:44 +0100 Message-ID: <1349278963.650.164.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Mukesh Rathor Date: Wed, 3 Oct 2012 16:42:43 +0100 In-Reply-To: <20120921121556.1a0ea8af@mantra.us.oracle.com> References: <20120921121556.1a0ea8af@mantra.us.oracle.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h > index 6a198e4..6c5ad83 100644 > --- a/include/xen/xen-ops.h > +++ b/include/xen/xen-ops.h > @@ -24,9 +24,19 @@ int xen_create_contiguous_region(unsigned long vstart, unsigned int order, > void xen_destroy_contiguous_region(unsigned long vstart, unsigned int order); > > struct vm_area_struct; > +struct xen_pvh_pfn_info; If you move the struct def'n up you don't need this forward decl. > int xen_remap_domain_mfn_range(struct vm_area_struct *vma, > unsigned long addr, > unsigned long mfn, int nr, > - pgprot_t prot, unsigned domid); > + pgprot_t prot, unsigned domid, > + struct xen_pvh_pfn_info *pvhp); > +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma, > + struct xen_pvh_pfn_info *pvhp); > + > +struct xen_pvh_pfn_info { Can we call this xen_remap_mfn_info or something? PVH is x86 specific while this struct is also useful on ARM. > + struct page **pi_paga; /* pfn info page array */ can we just call this "pages"? paga is pretty meaningless. > + int pi_num_pgs; > + int pi_next_todo; I don't think we need the pi_ prefix for any of these. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 15:49:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 15:49:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJRC4-0001qB-4h; Wed, 03 Oct 2012 15:49:04 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJRC2-0001q6-H7 for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 15:49:02 +0000 Received: from [85.158.139.211:12712] by server-16.bemta-5.messagelabs.com id 5E/BF-05998-D6E5C605; Wed, 03 Oct 2012 15:49:01 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-14.tower-206.messagelabs.com!1349279341!20884515!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16396 invoked from network); 3 Oct 2012 15:49:01 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 15:49:01 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="14920034" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 15:49:00 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 16:49:00 +0100 Date: Wed, 3 Oct 2012 16:48:00 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Ian Campbell In-Reply-To: <1349276431.650.156.camel@zakaz.uk.xensource.com> Message-ID: References: <1349272182.650.150.camel@zakaz.uk.xensource.com> <1349272482.650.151.camel@zakaz.uk.xensource.com> <20121003141116.GA10633@phenom.dumpdata.com> <1349276431.650.156.camel@zakaz.uk.xensource.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: "linux-kernel@vger.kernel.org" , Stefano Stabellini , "xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH] xen: point xen_start_info to a dummy struct for PV on HVM guests X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 3 Oct 2012, Ian Campbell wrote: > On Wed, 2012-10-03 at 15:11 +0100, Konrad Rzeszutek Wilk wrote: > > On Wed, Oct 03, 2012 at 02:54:42PM +0100, Ian Campbell wrote: > > > On Wed, 2012-10-03 at 14:51 +0100, Stefano Stabellini wrote: > > > > On Wed, 3 Oct 2012, Ian Campbell wrote: > > > > > On Wed, 2012-10-03 at 14:37 +0100, Stefano Stabellini wrote: > > > > > > PV on HVM guests don't have a start_info page mapped by Xen, so > > > > > > xen_start_info is just NULL for them. > > > > > > That is problem because other parts of the code expect xen_start_info to > > > > > > point to something valid, for example xen_initial_domain() is defined as > > > > > > follow: > > > > > > > > > > > > #define xen_initial_domain() (xen_domain() && \ > > > > > > xen_start_info->flags & SIF_INITDOMAIN) > > > > > > > > > > But anyone who calls this before xen_start_info is setup is going to get > > > > > a bogus result, specifically in this case they will think they are domU > > > > > when in reality they are dom0 -- wouldn't it be better to fix those > > > > > callsites? > > > > > > > > That cannot be the case because setting up xen_start_info is the very > > > > first thing that is done, before even calling to C. > > > > > > On PV, yes, but you are trying to fix PVHVM here, no? > > > > > > Otherwise if this is always set before calling into C then what is the > > > purpose of this patch? > > > > to fix this - as PVHVM has it set to NULL and we end up de-referencing > > the xen_start_info and crashing. As so:: > > > > Right, so returning to my original point: The caller here is calling > xen_initial_domain() *before* start info is setup. This is bogus and is > your actual bug, all this patch does is hide that real issue. That is because xen_start_info wasn't setup at all for PV on HVM guests. The real reason is that PV on HVM guests don't have one, but that is another matter. Until we get rid of all the references to xen_start_info outside of PV specific code, we should just assume that there is one, and that is already setup. One day not too far from now, we might refactor the code to never reference xen_start_info directly, but I don't think that now is the time for that. Also consider that this is the same thing we do on ARM. > With this "fix" the caller of xen_initial_domain shown in this trace now > gets a rubbish result based on the content of a dummy shared info > instead of the real answer from that actual shared info. That is not true. The caller gets a zero result, that is completely appropriate in this case, given that a PV on HVM guest doesn't have a start_info. > The right fix is to fix the caller to not call xen_initial_domain() > until after the shared info has been setup. Maybe that means moving > shinfo setup earlier, or maybe it means deferring this call until later > in the PVHVM case. I don't think so, we should be able to call xen_initial_domain() at any point in the code. The best course of action is taking this fix now (making PVHVM x86 guests behave the same way as ARM guests) and refactor all the callers to xen_start_info later. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 15:49:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 15:49:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJRC4-0001qB-4h; Wed, 03 Oct 2012 15:49:04 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJRC2-0001q6-H7 for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 15:49:02 +0000 Received: from [85.158.139.211:12712] by server-16.bemta-5.messagelabs.com id 5E/BF-05998-D6E5C605; Wed, 03 Oct 2012 15:49:01 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-14.tower-206.messagelabs.com!1349279341!20884515!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16396 invoked from network); 3 Oct 2012 15:49:01 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 15:49:01 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="14920034" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 15:49:00 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 16:49:00 +0100 Date: Wed, 3 Oct 2012 16:48:00 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Ian Campbell In-Reply-To: <1349276431.650.156.camel@zakaz.uk.xensource.com> Message-ID: References: <1349272182.650.150.camel@zakaz.uk.xensource.com> <1349272482.650.151.camel@zakaz.uk.xensource.com> <20121003141116.GA10633@phenom.dumpdata.com> <1349276431.650.156.camel@zakaz.uk.xensource.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: "linux-kernel@vger.kernel.org" , Stefano Stabellini , "xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH] xen: point xen_start_info to a dummy struct for PV on HVM guests X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 3 Oct 2012, Ian Campbell wrote: > On Wed, 2012-10-03 at 15:11 +0100, Konrad Rzeszutek Wilk wrote: > > On Wed, Oct 03, 2012 at 02:54:42PM +0100, Ian Campbell wrote: > > > On Wed, 2012-10-03 at 14:51 +0100, Stefano Stabellini wrote: > > > > On Wed, 3 Oct 2012, Ian Campbell wrote: > > > > > On Wed, 2012-10-03 at 14:37 +0100, Stefano Stabellini wrote: > > > > > > PV on HVM guests don't have a start_info page mapped by Xen, so > > > > > > xen_start_info is just NULL for them. > > > > > > That is problem because other parts of the code expect xen_start_info to > > > > > > point to something valid, for example xen_initial_domain() is defined as > > > > > > follow: > > > > > > > > > > > > #define xen_initial_domain() (xen_domain() && \ > > > > > > xen_start_info->flags & SIF_INITDOMAIN) > > > > > > > > > > But anyone who calls this before xen_start_info is setup is going to get > > > > > a bogus result, specifically in this case they will think they are domU > > > > > when in reality they are dom0 -- wouldn't it be better to fix those > > > > > callsites? > > > > > > > > That cannot be the case because setting up xen_start_info is the very > > > > first thing that is done, before even calling to C. > > > > > > On PV, yes, but you are trying to fix PVHVM here, no? > > > > > > Otherwise if this is always set before calling into C then what is the > > > purpose of this patch? > > > > to fix this - as PVHVM has it set to NULL and we end up de-referencing > > the xen_start_info and crashing. As so:: > > > > Right, so returning to my original point: The caller here is calling > xen_initial_domain() *before* start info is setup. This is bogus and is > your actual bug, all this patch does is hide that real issue. That is because xen_start_info wasn't setup at all for PV on HVM guests. The real reason is that PV on HVM guests don't have one, but that is another matter. Until we get rid of all the references to xen_start_info outside of PV specific code, we should just assume that there is one, and that is already setup. One day not too far from now, we might refactor the code to never reference xen_start_info directly, but I don't think that now is the time for that. Also consider that this is the same thing we do on ARM. > With this "fix" the caller of xen_initial_domain shown in this trace now > gets a rubbish result based on the content of a dummy shared info > instead of the real answer from that actual shared info. That is not true. The caller gets a zero result, that is completely appropriate in this case, given that a PV on HVM guest doesn't have a start_info. > The right fix is to fix the caller to not call xen_initial_domain() > until after the shared info has been setup. Maybe that means moving > shinfo setup earlier, or maybe it means deferring this call until later > in the PVHVM case. I don't think so, we should be able to call xen_initial_domain() at any point in the code. The best course of action is taking this fix now (making PVHVM x86 guests behave the same way as ARM guests) and refactor all the callers to xen_start_info later. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 15:50:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 15:50:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJRCy-0001tY-Ij; Wed, 03 Oct 2012 15:50:00 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJRCx-0001tN-D9 for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 15:49:59 +0000 Received: from [85.158.143.99:26360] by server-3.bemta-4.messagelabs.com id 80/4F-10986-6AE5C605; Wed, 03 Oct 2012 15:49:58 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1349279397!32130207!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20249 invoked from network); 3 Oct 2012 15:49:58 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 15:49:58 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="14920059" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 15:49:57 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 16:49:57 +0100 Date: Wed, 3 Oct 2012 16:48:57 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Konrad Rzeszutek Wilk In-Reply-To: <20121003134323.GA31270@phenom.dumpdata.com> Message-ID: References: <20121003134323.GA31270@phenom.dumpdata.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH] xen: point xen_start_info to a dummy struct for PV on HVM guests X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 3 Oct 2012, Konrad Rzeszutek Wilk wrote: > On Wed, Oct 03, 2012 at 02:37:53PM +0100, Stefano Stabellini wrote: > > PV on HVM guests don't have a start_info page mapped by Xen, so > > xen_start_info is just NULL for them. > > That is problem because other parts of the code expect xen_start_info to > > point to something valid, for example xen_initial_domain() is defined as > > follow: > > > > #define xen_initial_domain() (xen_domain() && \ > > xen_start_info->flags & SIF_INITDOMAIN) > > > > .. introduced by commit 4c071ee5268f7234c3d084b6093bebccc28cdcba > ("arm: initial Xen support) > > > > > Allocate a dummy start_info struct and point xen_start_info to it, as we > > do on ARM. > > This is not going to change things for PV guests because > > xen_start_info is set by arch/x86/xen/xen-head.S:startup_xen. > > > > Signed-off-by: Stefano Stabellini > > Reported-by: Konrad Rzeszutek Wilk > > > > diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c > > index bf788d3..5f242cb 100644 > > --- a/arch/x86/xen/enlighten.c > > +++ b/arch/x86/xen/enlighten.c > > @@ -96,7 +96,8 @@ EXPORT_SYMBOL(machine_to_phys_mapping); > > unsigned long machine_to_phys_nr; > > EXPORT_SYMBOL(machine_to_phys_nr); > > > > -struct start_info *xen_start_info; > > +static struct start_info _xen_start_info; > > And lets change that to > 'xen_dummy_start_info' to keep in sync with the other dummy one. > > And also add a commnt: > > /* > * Since 'xen_initial_domain' dereferences the xen_start_info we need > * a dummy structure filled with zeros (for PVHVM guests which initialize > * this late). For PV guests we do not have to worry about this as the first > * few instructions (startup_xen) set it properly. > */ I agree with all the changes, I'll repost soon > > +struct start_info *xen_start_info = &_xen_start_info; > > EXPORT_SYMBOL_GPL(xen_start_info); > > > > struct shared_info xen_dummy_shared_info; > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 15:50:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 15:50:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJRCy-0001tY-Ij; Wed, 03 Oct 2012 15:50:00 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJRCx-0001tN-D9 for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 15:49:59 +0000 Received: from [85.158.143.99:26360] by server-3.bemta-4.messagelabs.com id 80/4F-10986-6AE5C605; Wed, 03 Oct 2012 15:49:58 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1349279397!32130207!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20249 invoked from network); 3 Oct 2012 15:49:58 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 15:49:58 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="14920059" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 15:49:57 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 16:49:57 +0100 Date: Wed, 3 Oct 2012 16:48:57 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Konrad Rzeszutek Wilk In-Reply-To: <20121003134323.GA31270@phenom.dumpdata.com> Message-ID: References: <20121003134323.GA31270@phenom.dumpdata.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH] xen: point xen_start_info to a dummy struct for PV on HVM guests X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 3 Oct 2012, Konrad Rzeszutek Wilk wrote: > On Wed, Oct 03, 2012 at 02:37:53PM +0100, Stefano Stabellini wrote: > > PV on HVM guests don't have a start_info page mapped by Xen, so > > xen_start_info is just NULL for them. > > That is problem because other parts of the code expect xen_start_info to > > point to something valid, for example xen_initial_domain() is defined as > > follow: > > > > #define xen_initial_domain() (xen_domain() && \ > > xen_start_info->flags & SIF_INITDOMAIN) > > > > .. introduced by commit 4c071ee5268f7234c3d084b6093bebccc28cdcba > ("arm: initial Xen support) > > > > > Allocate a dummy start_info struct and point xen_start_info to it, as we > > do on ARM. > > This is not going to change things for PV guests because > > xen_start_info is set by arch/x86/xen/xen-head.S:startup_xen. > > > > Signed-off-by: Stefano Stabellini > > Reported-by: Konrad Rzeszutek Wilk > > > > diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c > > index bf788d3..5f242cb 100644 > > --- a/arch/x86/xen/enlighten.c > > +++ b/arch/x86/xen/enlighten.c > > @@ -96,7 +96,8 @@ EXPORT_SYMBOL(machine_to_phys_mapping); > > unsigned long machine_to_phys_nr; > > EXPORT_SYMBOL(machine_to_phys_nr); > > > > -struct start_info *xen_start_info; > > +static struct start_info _xen_start_info; > > And lets change that to > 'xen_dummy_start_info' to keep in sync with the other dummy one. > > And also add a commnt: > > /* > * Since 'xen_initial_domain' dereferences the xen_start_info we need > * a dummy structure filled with zeros (for PVHVM guests which initialize > * this late). For PV guests we do not have to worry about this as the first > * few instructions (startup_xen) set it properly. > */ I agree with all the changes, I'll repost soon > > +struct start_info *xen_start_info = &_xen_start_info; > > EXPORT_SYMBOL_GPL(xen_start_info); > > > > struct shared_info xen_dummy_shared_info; > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 15:56:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 15:56:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJRIc-00028X-It; Wed, 03 Oct 2012 15:55:50 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJRIa-00028R-AT for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 15:55:48 +0000 Received: from [85.158.143.35:6093] by server-3.bemta-4.messagelabs.com id DC/E5-10986-2006C605; Wed, 03 Oct 2012 15:55:46 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-16.tower-21.messagelabs.com!1349279744!14692921!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13784 invoked from network); 3 Oct 2012 15:55:44 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 15:55:44 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="14920189" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 15:55:44 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 16:55:44 +0100 Date: Wed, 3 Oct 2012 16:54:44 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Konrad Rzeszutek Wilk Message-ID: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , Stefano Stabellini Subject: [Xen-devel] [PATCH v2] xen: point xen_start_info to a dummy struct for PV on HVM guests X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org PV on HVM guests don't have a start_info page mapped by Xen, so xen_start_info is just NULL for them. That is problem because other parts of the code expect xen_start_info to point to something valid, for example xen_initial_domain() is defined as follow since commit 4c071ee5268f7234c3d084b6093bebccc28cdcba ("arm: initial Xen support"): #define xen_initial_domain() (xen_domain() && \ xen_start_info->flags & SIF_INITDOMAIN) Allocate a dummy start_info struct and point xen_start_info to it, as we do on ARM. This is not going to change things for PV guests because xen_start_info is set by arch/x86/xen/xen-head.S:startup_xen. Signed-off-by: Stefano Stabellini Reported-by: Konrad Rzeszutek Wilk diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index bf788d3..b73e6ed 100644 --- a/arch/x86/xen/enlighten.c +++ b/arch/x86/xen/enlighten.c @@ -96,7 +96,14 @@ EXPORT_SYMBOL(machine_to_phys_mapping); unsigned long machine_to_phys_nr; EXPORT_SYMBOL(machine_to_phys_nr); -struct start_info *xen_start_info; +/* + * Since 'xen_initial_domain' dereferences xen_start_info we need + * a dummy structure filled with zeros (for PVHVM guests which don't + * have one). For PV guests we do not have to worry about this as the first + * few instructions (startup_xen) set it properly. + */ +static struct start_info xen_dummy_start_info; +struct start_info *xen_start_info = &xen_dummy_start_info; EXPORT_SYMBOL_GPL(xen_start_info); struct shared_info xen_dummy_shared_info; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 15:56:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 15:56:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJRIc-00028X-It; Wed, 03 Oct 2012 15:55:50 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJRIa-00028R-AT for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 15:55:48 +0000 Received: from [85.158.143.35:6093] by server-3.bemta-4.messagelabs.com id DC/E5-10986-2006C605; Wed, 03 Oct 2012 15:55:46 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-16.tower-21.messagelabs.com!1349279744!14692921!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13784 invoked from network); 3 Oct 2012 15:55:44 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 15:55:44 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="14920189" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 15:55:44 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 16:55:44 +0100 Date: Wed, 3 Oct 2012 16:54:44 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Konrad Rzeszutek Wilk Message-ID: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , Stefano Stabellini Subject: [Xen-devel] [PATCH v2] xen: point xen_start_info to a dummy struct for PV on HVM guests X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org PV on HVM guests don't have a start_info page mapped by Xen, so xen_start_info is just NULL for them. That is problem because other parts of the code expect xen_start_info to point to something valid, for example xen_initial_domain() is defined as follow since commit 4c071ee5268f7234c3d084b6093bebccc28cdcba ("arm: initial Xen support"): #define xen_initial_domain() (xen_domain() && \ xen_start_info->flags & SIF_INITDOMAIN) Allocate a dummy start_info struct and point xen_start_info to it, as we do on ARM. This is not going to change things for PV guests because xen_start_info is set by arch/x86/xen/xen-head.S:startup_xen. Signed-off-by: Stefano Stabellini Reported-by: Konrad Rzeszutek Wilk diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index bf788d3..b73e6ed 100644 --- a/arch/x86/xen/enlighten.c +++ b/arch/x86/xen/enlighten.c @@ -96,7 +96,14 @@ EXPORT_SYMBOL(machine_to_phys_mapping); unsigned long machine_to_phys_nr; EXPORT_SYMBOL(machine_to_phys_nr); -struct start_info *xen_start_info; +/* + * Since 'xen_initial_domain' dereferences xen_start_info we need + * a dummy structure filled with zeros (for PVHVM guests which don't + * have one). For PV guests we do not have to worry about this as the first + * few instructions (startup_xen) set it properly. + */ +static struct start_info xen_dummy_start_info; +struct start_info *xen_start_info = &xen_dummy_start_info; EXPORT_SYMBOL_GPL(xen_start_info); struct shared_info xen_dummy_shared_info; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 15:58:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 15:58:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJRKU-0002Dz-6b; Wed, 03 Oct 2012 15:57:46 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJRKT-0002Dt-OB for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 15:57:45 +0000 Received: from [85.158.143.99:9023] by server-2.bemta-4.messagelabs.com id 35/1C-06610-9706C605; Wed, 03 Oct 2012 15:57:45 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1349279864!26482067!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24545 invoked from network); 3 Oct 2012 15:57:44 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 15:57:44 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="14920233" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 15:57:44 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 16:57:44 +0100 Message-ID: <1349279862.650.171.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Wed, 3 Oct 2012 16:57:42 +0100 In-Reply-To: References: <1349272182.650.150.camel@zakaz.uk.xensource.com> <1349272482.650.151.camel@zakaz.uk.xensource.com> <20121003141116.GA10633@phenom.dumpdata.com> <1349276431.650.156.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH] xen: point xen_start_info to a dummy struct for PV on HVM guests X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-10-03 at 16:48 +0100, Stefano Stabellini wrote: > On Wed, 3 Oct 2012, Ian Campbell wrote: > > On Wed, 2012-10-03 at 15:11 +0100, Konrad Rzeszutek Wilk wrote: > > > On Wed, Oct 03, 2012 at 02:54:42PM +0100, Ian Campbell wrote: > > > > On Wed, 2012-10-03 at 14:51 +0100, Stefano Stabellini wrote: > > > > > On Wed, 3 Oct 2012, Ian Campbell wrote: > > > > > > On Wed, 2012-10-03 at 14:37 +0100, Stefano Stabellini wrote: > > > > > > > PV on HVM guests don't have a start_info page mapped by Xen, so > > > > > > > xen_start_info is just NULL for them. > > > > > > > That is problem because other parts of the code expect xen_start_info to > > > > > > > point to something valid, for example xen_initial_domain() is defined as > > > > > > > follow: > > > > > > > > > > > > > > #define xen_initial_domain() (xen_domain() && \ > > > > > > > xen_start_info->flags & SIF_INITDOMAIN) > > > > > > > > > > > > But anyone who calls this before xen_start_info is setup is going to get > > > > > > a bogus result, specifically in this case they will think they are domU > > > > > > when in reality they are dom0 -- wouldn't it be better to fix those > > > > > > callsites? > > > > > > > > > > That cannot be the case because setting up xen_start_info is the very > > > > > first thing that is done, before even calling to C. > > > > > > > > On PV, yes, but you are trying to fix PVHVM here, no? > > > > > > > > Otherwise if this is always set before calling into C then what is the > > > > purpose of this patch? > > > > > > to fix this - as PVHVM has it set to NULL and we end up de-referencing > > > the xen_start_info and crashing. As so:: > > > > > > > Right, so returning to my original point: The caller here is calling > > xen_initial_domain() *before* start info is setup. This is bogus and is > > your actual bug, all this patch does is hide that real issue. > > That is because xen_start_info wasn't setup at all for PV on HVM guests. > > The real reason is that PV on HVM guests don't have one, but that is > another matter. Until we get rid of all the references to xen_start_info > outside of PV specific code, we should just assume that there is one, > and that is already setup. > > One day not too far from now, we might refactor the code to never > reference xen_start_info directly, but I don't think that now is the > time for that. Also consider that this is the same thing we do on ARM. We actual fill in the dummy start info with valid information on ARM though, we don't just leave it full of zeroes. If we do start out with start_info pointing to an uninitialised start_info on ARM too then I would argue that this is also a mistake. We should leave the NULL pointer in place until we setup the content of the dummy start info -- exactly because the resulting crash indicates to us that someone has accessed the si before we've initialised it. > > With this "fix" the caller of xen_initial_domain shown in this trace now > > gets a rubbish result based on the content of a dummy shared info > > instead of the real answer from that actual shared info. > > That is not true. The caller gets a zero result, that is completely > appropriate in this case, given that a PV on HVM guest doesn't have a > start_info. It's just a side effect of Linux zeroing its bss though and zero happening to be the right answer for a PVHVM guest in this case. Is it true that zero is an appropriate result for all uses of fields in start_info on PVHVM? > > The right fix is to fix the caller to not call xen_initial_domain() > > until after the shared info has been setup. Maybe that means moving > > shinfo setup earlier, or maybe it means deferring this call until later > > in the PVHVM case. > > I don't think so, we should be able to call xen_initial_domain() at any > point in the code. > > The best course of action is taking this fix now (making PVHVM x86 > guests behave the same way as ARM guests) and refactor all the callers to > xen_start_info later. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 15:58:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 15:58:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJRKU-0002Dz-6b; Wed, 03 Oct 2012 15:57:46 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJRKT-0002Dt-OB for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 15:57:45 +0000 Received: from [85.158.143.99:9023] by server-2.bemta-4.messagelabs.com id 35/1C-06610-9706C605; Wed, 03 Oct 2012 15:57:45 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1349279864!26482067!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24545 invoked from network); 3 Oct 2012 15:57:44 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 15:57:44 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="14920233" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 15:57:44 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 16:57:44 +0100 Message-ID: <1349279862.650.171.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Wed, 3 Oct 2012 16:57:42 +0100 In-Reply-To: References: <1349272182.650.150.camel@zakaz.uk.xensource.com> <1349272482.650.151.camel@zakaz.uk.xensource.com> <20121003141116.GA10633@phenom.dumpdata.com> <1349276431.650.156.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH] xen: point xen_start_info to a dummy struct for PV on HVM guests X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-10-03 at 16:48 +0100, Stefano Stabellini wrote: > On Wed, 3 Oct 2012, Ian Campbell wrote: > > On Wed, 2012-10-03 at 15:11 +0100, Konrad Rzeszutek Wilk wrote: > > > On Wed, Oct 03, 2012 at 02:54:42PM +0100, Ian Campbell wrote: > > > > On Wed, 2012-10-03 at 14:51 +0100, Stefano Stabellini wrote: > > > > > On Wed, 3 Oct 2012, Ian Campbell wrote: > > > > > > On Wed, 2012-10-03 at 14:37 +0100, Stefano Stabellini wrote: > > > > > > > PV on HVM guests don't have a start_info page mapped by Xen, so > > > > > > > xen_start_info is just NULL for them. > > > > > > > That is problem because other parts of the code expect xen_start_info to > > > > > > > point to something valid, for example xen_initial_domain() is defined as > > > > > > > follow: > > > > > > > > > > > > > > #define xen_initial_domain() (xen_domain() && \ > > > > > > > xen_start_info->flags & SIF_INITDOMAIN) > > > > > > > > > > > > But anyone who calls this before xen_start_info is setup is going to get > > > > > > a bogus result, specifically in this case they will think they are domU > > > > > > when in reality they are dom0 -- wouldn't it be better to fix those > > > > > > callsites? > > > > > > > > > > That cannot be the case because setting up xen_start_info is the very > > > > > first thing that is done, before even calling to C. > > > > > > > > On PV, yes, but you are trying to fix PVHVM here, no? > > > > > > > > Otherwise if this is always set before calling into C then what is the > > > > purpose of this patch? > > > > > > to fix this - as PVHVM has it set to NULL and we end up de-referencing > > > the xen_start_info and crashing. As so:: > > > > > > > Right, so returning to my original point: The caller here is calling > > xen_initial_domain() *before* start info is setup. This is bogus and is > > your actual bug, all this patch does is hide that real issue. > > That is because xen_start_info wasn't setup at all for PV on HVM guests. > > The real reason is that PV on HVM guests don't have one, but that is > another matter. Until we get rid of all the references to xen_start_info > outside of PV specific code, we should just assume that there is one, > and that is already setup. > > One day not too far from now, we might refactor the code to never > reference xen_start_info directly, but I don't think that now is the > time for that. Also consider that this is the same thing we do on ARM. We actual fill in the dummy start info with valid information on ARM though, we don't just leave it full of zeroes. If we do start out with start_info pointing to an uninitialised start_info on ARM too then I would argue that this is also a mistake. We should leave the NULL pointer in place until we setup the content of the dummy start info -- exactly because the resulting crash indicates to us that someone has accessed the si before we've initialised it. > > With this "fix" the caller of xen_initial_domain shown in this trace now > > gets a rubbish result based on the content of a dummy shared info > > instead of the real answer from that actual shared info. > > That is not true. The caller gets a zero result, that is completely > appropriate in this case, given that a PV on HVM guest doesn't have a > start_info. It's just a side effect of Linux zeroing its bss though and zero happening to be the right answer for a PVHVM guest in this case. Is it true that zero is an appropriate result for all uses of fields in start_info on PVHVM? > > The right fix is to fix the caller to not call xen_initial_domain() > > until after the shared info has been setup. Maybe that means moving > > shinfo setup earlier, or maybe it means deferring this call until later > > in the PVHVM case. > > I don't think so, we should be able to call xen_initial_domain() at any > point in the code. > > The best course of action is taking this fix now (making PVHVM x86 > guests behave the same way as ARM guests) and refactor all the callers to > xen_start_info later. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 16:07:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 16:07:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJRTJ-00035m-9O; Wed, 03 Oct 2012 16:06:53 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJRTH-00035a-QK for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 16:06:52 +0000 Received: from [85.158.143.99:9121] by server-3.bemta-4.messagelabs.com id 23/04-10986-B926C605; Wed, 03 Oct 2012 16:06:51 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1349280409!25728796!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28948 invoked from network); 3 Oct 2012 16:06:50 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 16:06:50 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="14920536" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 16:06:47 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 17:06:47 +0100 Date: Wed, 3 Oct 2012 17:05:47 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Ian Campbell In-Reply-To: <1349279862.650.171.camel@zakaz.uk.xensource.com> Message-ID: References: <1349272182.650.150.camel@zakaz.uk.xensource.com> <1349272482.650.151.camel@zakaz.uk.xensource.com> <20121003141116.GA10633@phenom.dumpdata.com> <1349276431.650.156.camel@zakaz.uk.xensource.com> <1349279862.650.171.camel@zakaz.uk.xensource.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: "linux-kernel@vger.kernel.org" , Konrad Rzeszutek Wilk , "xen-devel@lists.xensource.com" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH] xen: point xen_start_info to a dummy struct for PV on HVM guests X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 3 Oct 2012, Ian Campbell wrote: > On Wed, 2012-10-03 at 16:48 +0100, Stefano Stabellini wrote: > > On Wed, 3 Oct 2012, Ian Campbell wrote: > > > On Wed, 2012-10-03 at 15:11 +0100, Konrad Rzeszutek Wilk wrote: > > > > On Wed, Oct 03, 2012 at 02:54:42PM +0100, Ian Campbell wrote: > > > > > On Wed, 2012-10-03 at 14:51 +0100, Stefano Stabellini wrote: > > > > > > On Wed, 3 Oct 2012, Ian Campbell wrote: > > > > > > > On Wed, 2012-10-03 at 14:37 +0100, Stefano Stabellini wrote: > > > > > > > > PV on HVM guests don't have a start_info page mapped by Xen, so > > > > > > > > xen_start_info is just NULL for them. > > > > > > > > That is problem because other parts of the code expect xen_start_info to > > > > > > > > point to something valid, for example xen_initial_domain() is defined as > > > > > > > > follow: > > > > > > > > > > > > > > > > #define xen_initial_domain() (xen_domain() && \ > > > > > > > > xen_start_info->flags & SIF_INITDOMAIN) > > > > > > > > > > > > > > But anyone who calls this before xen_start_info is setup is going to get > > > > > > > a bogus result, specifically in this case they will think they are domU > > > > > > > when in reality they are dom0 -- wouldn't it be better to fix those > > > > > > > callsites? > > > > > > > > > > > > That cannot be the case because setting up xen_start_info is the very > > > > > > first thing that is done, before even calling to C. > > > > > > > > > > On PV, yes, but you are trying to fix PVHVM here, no? > > > > > > > > > > Otherwise if this is always set before calling into C then what is the > > > > > purpose of this patch? > > > > > > > > to fix this - as PVHVM has it set to NULL and we end up de-referencing > > > > the xen_start_info and crashing. As so:: > > > > > > > > > > Right, so returning to my original point: The caller here is calling > > > xen_initial_domain() *before* start info is setup. This is bogus and is > > > your actual bug, all this patch does is hide that real issue. > > > > That is because xen_start_info wasn't setup at all for PV on HVM guests. > > > > The real reason is that PV on HVM guests don't have one, but that is > > another matter. Until we get rid of all the references to xen_start_info > > outside of PV specific code, we should just assume that there is one, > > and that is already setup. > > > > One day not too far from now, we might refactor the code to never > > reference xen_start_info directly, but I don't think that now is the > > time for that. Also consider that this is the same thing we do on ARM. > > We actual fill in the dummy start info with valid information on ARM > though, we don't just leave it full of zeroes. > > If we do start out with start_info pointing to an uninitialised > start_info on ARM too then I would argue that this is also a mistake. Yes, we do point xen_start_info to an uninitialised start_info on ARM too (I don't think is a mistake). Then when and if we have more information we write them to start_info. > We > should leave the NULL pointer in place until we setup the content of the > dummy start info -- exactly because the resulting crash indicates to us > that someone has accessed the si before we've initialised it. I don't think so. It is initialized to zero, that is the right thing to do. > > > With this "fix" the caller of xen_initial_domain shown in this trace now > > > gets a rubbish result based on the content of a dummy shared info > > > instead of the real answer from that actual shared info. > > > > That is not true. The caller gets a zero result, that is completely > > appropriate in this case, given that a PV on HVM guest doesn't have a > > start_info. > > It's just a side effect of Linux zeroing its bss though and zero > happening to be the right answer for a PVHVM guest in this case. well, I would call that "by design" ;-) > Is it true that zero is an appropriate result for all uses of fields in > start_info on PVHVM? I think so. In fact, if we wanted to, we could have the dummy struct initialized to something different, but I don't think that we should. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 16:07:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 16:07:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJRTJ-00035m-9O; Wed, 03 Oct 2012 16:06:53 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJRTH-00035a-QK for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 16:06:52 +0000 Received: from [85.158.143.99:9121] by server-3.bemta-4.messagelabs.com id 23/04-10986-B926C605; Wed, 03 Oct 2012 16:06:51 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1349280409!25728796!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28948 invoked from network); 3 Oct 2012 16:06:50 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 16:06:50 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="14920536" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 16:06:47 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 17:06:47 +0100 Date: Wed, 3 Oct 2012 17:05:47 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Ian Campbell In-Reply-To: <1349279862.650.171.camel@zakaz.uk.xensource.com> Message-ID: References: <1349272182.650.150.camel@zakaz.uk.xensource.com> <1349272482.650.151.camel@zakaz.uk.xensource.com> <20121003141116.GA10633@phenom.dumpdata.com> <1349276431.650.156.camel@zakaz.uk.xensource.com> <1349279862.650.171.camel@zakaz.uk.xensource.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: "linux-kernel@vger.kernel.org" , Konrad Rzeszutek Wilk , "xen-devel@lists.xensource.com" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH] xen: point xen_start_info to a dummy struct for PV on HVM guests X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 3 Oct 2012, Ian Campbell wrote: > On Wed, 2012-10-03 at 16:48 +0100, Stefano Stabellini wrote: > > On Wed, 3 Oct 2012, Ian Campbell wrote: > > > On Wed, 2012-10-03 at 15:11 +0100, Konrad Rzeszutek Wilk wrote: > > > > On Wed, Oct 03, 2012 at 02:54:42PM +0100, Ian Campbell wrote: > > > > > On Wed, 2012-10-03 at 14:51 +0100, Stefano Stabellini wrote: > > > > > > On Wed, 3 Oct 2012, Ian Campbell wrote: > > > > > > > On Wed, 2012-10-03 at 14:37 +0100, Stefano Stabellini wrote: > > > > > > > > PV on HVM guests don't have a start_info page mapped by Xen, so > > > > > > > > xen_start_info is just NULL for them. > > > > > > > > That is problem because other parts of the code expect xen_start_info to > > > > > > > > point to something valid, for example xen_initial_domain() is defined as > > > > > > > > follow: > > > > > > > > > > > > > > > > #define xen_initial_domain() (xen_domain() && \ > > > > > > > > xen_start_info->flags & SIF_INITDOMAIN) > > > > > > > > > > > > > > But anyone who calls this before xen_start_info is setup is going to get > > > > > > > a bogus result, specifically in this case they will think they are domU > > > > > > > when in reality they are dom0 -- wouldn't it be better to fix those > > > > > > > callsites? > > > > > > > > > > > > That cannot be the case because setting up xen_start_info is the very > > > > > > first thing that is done, before even calling to C. > > > > > > > > > > On PV, yes, but you are trying to fix PVHVM here, no? > > > > > > > > > > Otherwise if this is always set before calling into C then what is the > > > > > purpose of this patch? > > > > > > > > to fix this - as PVHVM has it set to NULL and we end up de-referencing > > > > the xen_start_info and crashing. As so:: > > > > > > > > > > Right, so returning to my original point: The caller here is calling > > > xen_initial_domain() *before* start info is setup. This is bogus and is > > > your actual bug, all this patch does is hide that real issue. > > > > That is because xen_start_info wasn't setup at all for PV on HVM guests. > > > > The real reason is that PV on HVM guests don't have one, but that is > > another matter. Until we get rid of all the references to xen_start_info > > outside of PV specific code, we should just assume that there is one, > > and that is already setup. > > > > One day not too far from now, we might refactor the code to never > > reference xen_start_info directly, but I don't think that now is the > > time for that. Also consider that this is the same thing we do on ARM. > > We actual fill in the dummy start info with valid information on ARM > though, we don't just leave it full of zeroes. > > If we do start out with start_info pointing to an uninitialised > start_info on ARM too then I would argue that this is also a mistake. Yes, we do point xen_start_info to an uninitialised start_info on ARM too (I don't think is a mistake). Then when and if we have more information we write them to start_info. > We > should leave the NULL pointer in place until we setup the content of the > dummy start info -- exactly because the resulting crash indicates to us > that someone has accessed the si before we've initialised it. I don't think so. It is initialized to zero, that is the right thing to do. > > > With this "fix" the caller of xen_initial_domain shown in this trace now > > > gets a rubbish result based on the content of a dummy shared info > > > instead of the real answer from that actual shared info. > > > > That is not true. The caller gets a zero result, that is completely > > appropriate in this case, given that a PV on HVM guest doesn't have a > > start_info. > > It's just a side effect of Linux zeroing its bss though and zero > happening to be the right answer for a PVHVM guest in this case. well, I would call that "by design" ;-) > Is it true that zero is an appropriate result for all uses of fields in > start_info on PVHVM? I think so. In fact, if we wanted to, we could have the dummy struct initialized to something different, but I don't think that we should. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 16:16:09 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 16:16:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJRc4-0003eW-58; Wed, 03 Oct 2012 16:15:56 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJRc1-0003eJ-Rb for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 16:15:54 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1349280942!4037133!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1156 invoked from network); 3 Oct 2012 16:15:42 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 16:15:42 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="14920864" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 16:13:35 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 17:13:35 +0100 Message-ID: <1349280814.650.178.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Wed, 3 Oct 2012 17:13:34 +0100 In-Reply-To: References: <1349272182.650.150.camel@zakaz.uk.xensource.com> <1349272482.650.151.camel@zakaz.uk.xensource.com> <20121003141116.GA10633@phenom.dumpdata.com> <1349276431.650.156.camel@zakaz.uk.xensource.com> <1349279862.650.171.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH] xen: point xen_start_info to a dummy struct for PV on HVM guests X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-10-03 at 17:05 +0100, Stefano Stabellini wrote: > On Wed, 3 Oct 2012, Ian Campbell wrote: > > On Wed, 2012-10-03 at 16:48 +0100, Stefano Stabellini wrote: > > > On Wed, 3 Oct 2012, Ian Campbell wrote: > > > > On Wed, 2012-10-03 at 15:11 +0100, Konrad Rzeszutek Wilk wrote: > > > > > On Wed, Oct 03, 2012 at 02:54:42PM +0100, Ian Campbell wrote: > > > > > > On Wed, 2012-10-03 at 14:51 +0100, Stefano Stabellini wrote: > > > > > > > On Wed, 3 Oct 2012, Ian Campbell wrote: > > > > > > > > On Wed, 2012-10-03 at 14:37 +0100, Stefano Stabellini wrote: > > > > > > > > > PV on HVM guests don't have a start_info page mapped by Xen, so > > > > > > > > > xen_start_info is just NULL for them. > > > > > > > > > That is problem because other parts of the code expect xen_start_info to > > > > > > > > > point to something valid, for example xen_initial_domain() is defined as > > > > > > > > > follow: > > > > > > > > > > > > > > > > > > #define xen_initial_domain() (xen_domain() && \ > > > > > > > > > xen_start_info->flags & SIF_INITDOMAIN) > > > > > > > > > > > > > > > > But anyone who calls this before xen_start_info is setup is going to get > > > > > > > > a bogus result, specifically in this case they will think they are domU > > > > > > > > when in reality they are dom0 -- wouldn't it be better to fix those > > > > > > > > callsites? > > > > > > > > > > > > > > That cannot be the case because setting up xen_start_info is the very > > > > > > > first thing that is done, before even calling to C. > > > > > > > > > > > > On PV, yes, but you are trying to fix PVHVM here, no? > > > > > > > > > > > > Otherwise if this is always set before calling into C then what is the > > > > > > purpose of this patch? > > > > > > > > > > to fix this - as PVHVM has it set to NULL and we end up de-referencing > > > > > the xen_start_info and crashing. As so:: > > > > > > > > > > > > > Right, so returning to my original point: The caller here is calling > > > > xen_initial_domain() *before* start info is setup. This is bogus and is > > > > your actual bug, all this patch does is hide that real issue. > > > > > > That is because xen_start_info wasn't setup at all for PV on HVM guests. > > > > > > The real reason is that PV on HVM guests don't have one, but that is > > > another matter. Until we get rid of all the references to xen_start_info > > > outside of PV specific code, we should just assume that there is one, > > > and that is already setup. > > > > > > One day not too far from now, we might refactor the code to never > > > reference xen_start_info directly, but I don't think that now is the > > > time for that. Also consider that this is the same thing we do on ARM. > > > > We actual fill in the dummy start info with valid information on ARM > > though, we don't just leave it full of zeroes. > > > > If we do start out with start_info pointing to an uninitialised > > start_info on ARM too then I would argue that this is also a mistake. > > Yes, we do point xen_start_info to an uninitialised start_info on ARM > too (I don't think is a mistake). Then when and if we have more > information we write them to start_info. So callers of xen_initial_domain in dom0 before xen_guest_init is called get the wrong result? That sounds like a mistake to me. > > We > > should leave the NULL pointer in place until we setup the content of the > > dummy start info -- exactly because the resulting crash indicates to us > > that someone has accessed the si before we've initialised it. > > I don't think so. It is initialized to zero, that is the right thing to > do. Except it isn't in the dom0 case... > > > > With this "fix" the caller of xen_initial_domain shown in this trace now > > > > gets a rubbish result based on the content of a dummy shared info > > > > instead of the real answer from that actual shared info. > > > > > > That is not true. The caller gets a zero result, that is completely > > > appropriate in this case, given that a PV on HVM guest doesn't have a > > > start_info. > > > > It's just a side effect of Linux zeroing its bss though and zero > > happening to be the right answer for a PVHVM guest in this case. > > well, I would call that "by design" ;-) Well, in that case it should be documented not just implicit! > > Is it true that zero is an appropriate result for all uses of fields in > > start_info on PVHVM? > > I think so. In fact, if we wanted to, we could have the dummy struct > initialized to something different, but I don't think that we should. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 16:16:09 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 16:16:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJRc4-0003eW-58; Wed, 03 Oct 2012 16:15:56 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJRc1-0003eJ-Rb for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 16:15:54 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1349280942!4037133!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1156 invoked from network); 3 Oct 2012 16:15:42 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 16:15:42 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="14920864" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 16:13:35 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 17:13:35 +0100 Message-ID: <1349280814.650.178.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Wed, 3 Oct 2012 17:13:34 +0100 In-Reply-To: References: <1349272182.650.150.camel@zakaz.uk.xensource.com> <1349272482.650.151.camel@zakaz.uk.xensource.com> <20121003141116.GA10633@phenom.dumpdata.com> <1349276431.650.156.camel@zakaz.uk.xensource.com> <1349279862.650.171.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH] xen: point xen_start_info to a dummy struct for PV on HVM guests X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-10-03 at 17:05 +0100, Stefano Stabellini wrote: > On Wed, 3 Oct 2012, Ian Campbell wrote: > > On Wed, 2012-10-03 at 16:48 +0100, Stefano Stabellini wrote: > > > On Wed, 3 Oct 2012, Ian Campbell wrote: > > > > On Wed, 2012-10-03 at 15:11 +0100, Konrad Rzeszutek Wilk wrote: > > > > > On Wed, Oct 03, 2012 at 02:54:42PM +0100, Ian Campbell wrote: > > > > > > On Wed, 2012-10-03 at 14:51 +0100, Stefano Stabellini wrote: > > > > > > > On Wed, 3 Oct 2012, Ian Campbell wrote: > > > > > > > > On Wed, 2012-10-03 at 14:37 +0100, Stefano Stabellini wrote: > > > > > > > > > PV on HVM guests don't have a start_info page mapped by Xen, so > > > > > > > > > xen_start_info is just NULL for them. > > > > > > > > > That is problem because other parts of the code expect xen_start_info to > > > > > > > > > point to something valid, for example xen_initial_domain() is defined as > > > > > > > > > follow: > > > > > > > > > > > > > > > > > > #define xen_initial_domain() (xen_domain() && \ > > > > > > > > > xen_start_info->flags & SIF_INITDOMAIN) > > > > > > > > > > > > > > > > But anyone who calls this before xen_start_info is setup is going to get > > > > > > > > a bogus result, specifically in this case they will think they are domU > > > > > > > > when in reality they are dom0 -- wouldn't it be better to fix those > > > > > > > > callsites? > > > > > > > > > > > > > > That cannot be the case because setting up xen_start_info is the very > > > > > > > first thing that is done, before even calling to C. > > > > > > > > > > > > On PV, yes, but you are trying to fix PVHVM here, no? > > > > > > > > > > > > Otherwise if this is always set before calling into C then what is the > > > > > > purpose of this patch? > > > > > > > > > > to fix this - as PVHVM has it set to NULL and we end up de-referencing > > > > > the xen_start_info and crashing. As so:: > > > > > > > > > > > > > Right, so returning to my original point: The caller here is calling > > > > xen_initial_domain() *before* start info is setup. This is bogus and is > > > > your actual bug, all this patch does is hide that real issue. > > > > > > That is because xen_start_info wasn't setup at all for PV on HVM guests. > > > > > > The real reason is that PV on HVM guests don't have one, but that is > > > another matter. Until we get rid of all the references to xen_start_info > > > outside of PV specific code, we should just assume that there is one, > > > and that is already setup. > > > > > > One day not too far from now, we might refactor the code to never > > > reference xen_start_info directly, but I don't think that now is the > > > time for that. Also consider that this is the same thing we do on ARM. > > > > We actual fill in the dummy start info with valid information on ARM > > though, we don't just leave it full of zeroes. > > > > If we do start out with start_info pointing to an uninitialised > > start_info on ARM too then I would argue that this is also a mistake. > > Yes, we do point xen_start_info to an uninitialised start_info on ARM > too (I don't think is a mistake). Then when and if we have more > information we write them to start_info. So callers of xen_initial_domain in dom0 before xen_guest_init is called get the wrong result? That sounds like a mistake to me. > > We > > should leave the NULL pointer in place until we setup the content of the > > dummy start info -- exactly because the resulting crash indicates to us > > that someone has accessed the si before we've initialised it. > > I don't think so. It is initialized to zero, that is the right thing to > do. Except it isn't in the dom0 case... > > > > With this "fix" the caller of xen_initial_domain shown in this trace now > > > > gets a rubbish result based on the content of a dummy shared info > > > > instead of the real answer from that actual shared info. > > > > > > That is not true. The caller gets a zero result, that is completely > > > appropriate in this case, given that a PV on HVM guest doesn't have a > > > start_info. > > > > It's just a side effect of Linux zeroing its bss though and zero > > happening to be the right answer for a PVHVM guest in this case. > > well, I would call that "by design" ;-) Well, in that case it should be documented not just implicit! > > Is it true that zero is an appropriate result for all uses of fields in > > start_info on PVHVM? > > I think so. In fact, if we wanted to, we could have the dummy struct > initialized to something different, but I don't think that we should. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 16:23:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 16:23:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJRjB-0003xB-2C; Wed, 03 Oct 2012 16:23:17 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJRj9-0003x6-AE for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 16:23:15 +0000 Received: from [85.158.138.51:24468] by server-6.bemta-3.messagelabs.com id E0/1F-11085-2766C605; Wed, 03 Oct 2012 16:23:14 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1349281392!24091634!1 X-Originating-IP: [209.85.213.173] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29820 invoked from network); 3 Oct 2012 16:23:13 -0000 Received: from mail-yx0-f173.google.com (HELO mail-yx0-f173.google.com) (209.85.213.173) by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 16:23:13 -0000 Received: by yenl3 with SMTP id l3so2293378yen.32 for ; Wed, 03 Oct 2012 09:23:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DzCk0pZfeVuE38ABxbOMpCeqfz6dgE0CeaRlhNhm3nY=; b=vwKua2z5wM/4baqhDl2HNaDeTpCpdg04F/GkjCN1HqK3x1Fgr+c6koV0+7BY61mLcI sHAIHlXbIkiDh60/fsqBxwTt2pwpaLK/X5AtSXUZrBrNa5bPSxDbVQRGULjR7OVr8Cdr yVtj0/OzsZpSut+5I4o0QHyyosHmqqXETWgmCBaRAWKSQHPfOwJJzq9+aojd/7Z3HTKX jZFEc1g2cGuXaYJgnRA/797BzA0Wi7SkBTSDlImDg6Izj1362sShPNEzYc4c3jIMde6b 6NfqGIXfh3RIorIcWiU1KHk1ofSCOnQU6vReuT/lgS+p+3FoAPywpRoOHoC9ftjR3+2p GH0A== MIME-Version: 1.0 Received: by 10.236.155.71 with SMTP id i47mr2347943yhk.72.1349281391807; Wed, 03 Oct 2012 09:23:11 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Wed, 3 Oct 2012 09:23:11 -0700 (PDT) In-Reply-To: References: <1349259542.650.122.camel@zakaz.uk.xensource.com> <1349261397.650.130.camel@zakaz.uk.xensource.com> <1349263669.650.131.camel@zakaz.uk.xensource.com> <1349266207.650.137.camel@zakaz.uk.xensource.com> <1349278604.650.162.camel@zakaz.uk.xensource.com> Date: Wed, 3 Oct 2012 19:23:11 +0300 Message-ID: From: Valtteri Kiviniemi To: Ian Campbell Cc: "Xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Xen 4.2.0, xl toolstack cant launch older domUs X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5117830919068431524==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============5117830919068431524== Content-Type: multipart/alternative; boundary=20cf303b42690f8e6c04cb2a0edb --20cf303b42690f8e6c04cb2a0edb Content-Type: text/plain; charset=ISO-8859-1 2012/10/3 Valtteri Kiviniemi > > > 2012/10/3 Ian Campbell > >> On Wed, 2012-10-03 at 16:29 +0100, Valtteri Kiviniemi wrote: >> > >> > >> > 2012/10/3 Valtteri Kiviniemi >> > >> > >> > 2012/10/3 Valtteri Kiviniemi >> > >> > 2012/10/3 Ian Campbell >> > On Wed, 2012-10-03 at 12:44 +0100, Valtteri >> > Kiviniemi wrote: >> > > Hi, >> > > >> > > Ok, well lets do it thisway. Hopefully I got >> > this right this time. >> > >> > >> > You did, thanks. (aside, can you not top-post >> > please) >> > >> > A bit of a shot in the dark but what is the >> > address size (i.e. 64 bit or >> > 32 bit) for each of your hypervisor, dom0 and >> > domU kernels? >> > >> > Does this change anything: >> > xl cr -p lightning.cfg >> > xenstore-write /local/domain/$(xl >> > domid lightning)/device/vbd/51713/protocol >> > x86_32-abi >> > xl unpause lightning >> > >> > (this assumes the domains cfg is lightning.cfg >> > and name is lightning) >> > >> > Ian. >> > >> > >> > Hi, >> > >> > Sorry for the top posting, I'm at work at the moment >> > and using different mail client which is is configured >> > for top posting and I was too lazy to change it. >> > >> > But that did do the trick, the domU is now fillu >> > booting and working! >> > >> > - Valtteri >> > >> > >> > >> > >> > Hi, >> > >> > dom0 is 64bit, hypervisor is 64bit and that domU (lightning) >> > is 32bit. >> > >> > - Valtteri >> > >> > Hi, >> > >> > I have now made a startup script that starts the domU first by pausing >> > it, then writes that thingy in xenstore and then unpauses it. Its >> > working now fine. I assume that this is some kind of bug that will be >> > fixed on later Xen versions, or is this caused by something in my end? >> > Do I have to do something else to get the domU to startup normally? >> >> I'm undecided at the moment whether this represents a bug in the old >> domU kernel, or something wrong with the toolstack. >> >> Can you tell me what flavour (i.e. address width, 32 or 64) of >> hypervisor, dom0 kernel and domU kernel you are using is? >> >> Ian. >> >> > Hi, > > Hypervisor is 64bit, dom0 is 64bit but the domU is 32bit. If this is what > you meant? > > - Valtteri > Hi, I managed to find the sources for my domU kernel, so if you are interested about this problem I can send you a link for the sources and the domU kernel config that I'm using. Maybe you can then figure out if the bug is in the old domU kernel or in the toolstack. - Valtteri --20cf303b42690f8e6c04cb2a0edb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/10/3 Valtteri Kiviniemi <kiviniemi.valtteri@gmail.com>


= 2012/10/3 Ian Campbell <Ian.Campbell@citrix.com>
On Wed, 2012-10-03 at 16:29 +0100, Valtteri Kiviniemi wrote:
>
>
> 2012/10/3 Valtteri Kiviniemi <kiviniemi.valtteri@gmail.com>
>
>
> =A0 =A0 =A0 =A0 2012/10/3 Valtteri Kiviniemi <kiviniemi.valtteri@gmail.com>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2012/10/3 Ian Campbell <Ian.Campbell@citrix.com>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 On Wed, 2012-10-03 at = 12:44 +0100, Valtteri
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Kiviniemi wrote:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > Hi,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > Ok, well lets do = it thisway. Hopefully I got
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 this right this time.<= br> >
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 You did, thanks. (asid= e, can you not top-post
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 please)
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 A bit of a shot in the= dark but what is the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 address size (i.e. 64 = bit or
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 32 bit) for each of yo= ur hypervisor, dom0 and
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 domU kernels?
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Does this change anyth= ing:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 xl cr = -p lightning.cfg
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 xensto= re-write /local/domain/$(xl
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 domid lightning)/devic= e/vbd/51713/protocol
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 x86_32-abi
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 xl unp= ause lightning
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (this assumes the doma= ins cfg is lightning.cfg
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 and name is lightning)=
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ian.
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Hi,
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Sorry for the top posting, I'm at = work at the moment
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 and using different mail client which = is is configured
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 for top posting and I was too lazy to = change it.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 But that did do the trick, the domU is= now fillu
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 booting and working!
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - Valtteri
>
>
>
>
> =A0 =A0 =A0 =A0 Hi,
>
> =A0 =A0 =A0 =A0 dom0 is 64bit, hypervisor is 64bit and that domU (ligh= tning)
> =A0 =A0 =A0 =A0 is 32bit.
>
> =A0 =A0 =A0 =A0 - Valtteri
>
> Hi,
>
> I have now made a startup script that starts the domU first by pausing=
> it, then writes that thingy in xenstore and then unpauses it. Its
> working now fine. I assume that this is some kind of bug that will be<= br> > fixed on later Xen versions, or is this caused by something in my end?=
> Do I have to do something else to get the domU to startup normally?
I'm undecided at the moment whether this represents a bug i= n the old
domU kernel, or something wrong with the toolstack.

Can you tell me what flavour (i.e. address width, 32 or 64) of
hypervisor, dom0 kernel and domU kernel you are using is?

Ian.


Hi,

Hypervisor is 6= 4bit, dom0 is 64bit but the domU is 32bit. If this is what you meant?

- Valtteri

Hi,

I managed to find the sourc= es for my domU kernel, so if you are interested about this problem I can se= nd you a link for the sources and the domU kernel config that I'm using= . Maybe you can then figure out if the bug is in the old domU kernel or in = the toolstack.

- Valtteri
--20cf303b42690f8e6c04cb2a0edb-- --===============5117830919068431524== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============5117830919068431524==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 16:23:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 16:23:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJRjB-0003xB-2C; Wed, 03 Oct 2012 16:23:17 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJRj9-0003x6-AE for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 16:23:15 +0000 Received: from [85.158.138.51:24468] by server-6.bemta-3.messagelabs.com id E0/1F-11085-2766C605; Wed, 03 Oct 2012 16:23:14 +0000 X-Env-Sender: kiviniemi.valtteri@gmail.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1349281392!24091634!1 X-Originating-IP: [209.85.213.173] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29820 invoked from network); 3 Oct 2012 16:23:13 -0000 Received: from mail-yx0-f173.google.com (HELO mail-yx0-f173.google.com) (209.85.213.173) by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 16:23:13 -0000 Received: by yenl3 with SMTP id l3so2293378yen.32 for ; Wed, 03 Oct 2012 09:23:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DzCk0pZfeVuE38ABxbOMpCeqfz6dgE0CeaRlhNhm3nY=; b=vwKua2z5wM/4baqhDl2HNaDeTpCpdg04F/GkjCN1HqK3x1Fgr+c6koV0+7BY61mLcI sHAIHlXbIkiDh60/fsqBxwTt2pwpaLK/X5AtSXUZrBrNa5bPSxDbVQRGULjR7OVr8Cdr yVtj0/OzsZpSut+5I4o0QHyyosHmqqXETWgmCBaRAWKSQHPfOwJJzq9+aojd/7Z3HTKX jZFEc1g2cGuXaYJgnRA/797BzA0Wi7SkBTSDlImDg6Izj1362sShPNEzYc4c3jIMde6b 6NfqGIXfh3RIorIcWiU1KHk1ofSCOnQU6vReuT/lgS+p+3FoAPywpRoOHoC9ftjR3+2p GH0A== MIME-Version: 1.0 Received: by 10.236.155.71 with SMTP id i47mr2347943yhk.72.1349281391807; Wed, 03 Oct 2012 09:23:11 -0700 (PDT) Received: by 10.147.129.8 with HTTP; Wed, 3 Oct 2012 09:23:11 -0700 (PDT) In-Reply-To: References: <1349259542.650.122.camel@zakaz.uk.xensource.com> <1349261397.650.130.camel@zakaz.uk.xensource.com> <1349263669.650.131.camel@zakaz.uk.xensource.com> <1349266207.650.137.camel@zakaz.uk.xensource.com> <1349278604.650.162.camel@zakaz.uk.xensource.com> Date: Wed, 3 Oct 2012 19:23:11 +0300 Message-ID: From: Valtteri Kiviniemi To: Ian Campbell Cc: "Xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Xen 4.2.0, xl toolstack cant launch older domUs X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5117830919068431524==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============5117830919068431524== Content-Type: multipart/alternative; boundary=20cf303b42690f8e6c04cb2a0edb --20cf303b42690f8e6c04cb2a0edb Content-Type: text/plain; charset=ISO-8859-1 2012/10/3 Valtteri Kiviniemi > > > 2012/10/3 Ian Campbell > >> On Wed, 2012-10-03 at 16:29 +0100, Valtteri Kiviniemi wrote: >> > >> > >> > 2012/10/3 Valtteri Kiviniemi >> > >> > >> > 2012/10/3 Valtteri Kiviniemi >> > >> > 2012/10/3 Ian Campbell >> > On Wed, 2012-10-03 at 12:44 +0100, Valtteri >> > Kiviniemi wrote: >> > > Hi, >> > > >> > > Ok, well lets do it thisway. Hopefully I got >> > this right this time. >> > >> > >> > You did, thanks. (aside, can you not top-post >> > please) >> > >> > A bit of a shot in the dark but what is the >> > address size (i.e. 64 bit or >> > 32 bit) for each of your hypervisor, dom0 and >> > domU kernels? >> > >> > Does this change anything: >> > xl cr -p lightning.cfg >> > xenstore-write /local/domain/$(xl >> > domid lightning)/device/vbd/51713/protocol >> > x86_32-abi >> > xl unpause lightning >> > >> > (this assumes the domains cfg is lightning.cfg >> > and name is lightning) >> > >> > Ian. >> > >> > >> > Hi, >> > >> > Sorry for the top posting, I'm at work at the moment >> > and using different mail client which is is configured >> > for top posting and I was too lazy to change it. >> > >> > But that did do the trick, the domU is now fillu >> > booting and working! >> > >> > - Valtteri >> > >> > >> > >> > >> > Hi, >> > >> > dom0 is 64bit, hypervisor is 64bit and that domU (lightning) >> > is 32bit. >> > >> > - Valtteri >> > >> > Hi, >> > >> > I have now made a startup script that starts the domU first by pausing >> > it, then writes that thingy in xenstore and then unpauses it. Its >> > working now fine. I assume that this is some kind of bug that will be >> > fixed on later Xen versions, or is this caused by something in my end? >> > Do I have to do something else to get the domU to startup normally? >> >> I'm undecided at the moment whether this represents a bug in the old >> domU kernel, or something wrong with the toolstack. >> >> Can you tell me what flavour (i.e. address width, 32 or 64) of >> hypervisor, dom0 kernel and domU kernel you are using is? >> >> Ian. >> >> > Hi, > > Hypervisor is 64bit, dom0 is 64bit but the domU is 32bit. If this is what > you meant? > > - Valtteri > Hi, I managed to find the sources for my domU kernel, so if you are interested about this problem I can send you a link for the sources and the domU kernel config that I'm using. Maybe you can then figure out if the bug is in the old domU kernel or in the toolstack. - Valtteri --20cf303b42690f8e6c04cb2a0edb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/10/3 Valtteri Kiviniemi <kiviniemi.valtteri@gmail.com>


= 2012/10/3 Ian Campbell <Ian.Campbell@citrix.com>
On Wed, 2012-10-03 at 16:29 +0100, Valtteri Kiviniemi wrote:
>
>
> 2012/10/3 Valtteri Kiviniemi <kiviniemi.valtteri@gmail.com>
>
>
> =A0 =A0 =A0 =A0 2012/10/3 Valtteri Kiviniemi <kiviniemi.valtteri@gmail.com>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2012/10/3 Ian Campbell <Ian.Campbell@citrix.com>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 On Wed, 2012-10-03 at = 12:44 +0100, Valtteri
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Kiviniemi wrote:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > Hi,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > Ok, well lets do = it thisway. Hopefully I got
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 this right this time.<= br> >
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 You did, thanks. (asid= e, can you not top-post
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 please)
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 A bit of a shot in the= dark but what is the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 address size (i.e. 64 = bit or
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 32 bit) for each of yo= ur hypervisor, dom0 and
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 domU kernels?
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Does this change anyth= ing:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 xl cr = -p lightning.cfg
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 xensto= re-write /local/domain/$(xl
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 domid lightning)/devic= e/vbd/51713/protocol
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 x86_32-abi
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 xl unp= ause lightning
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (this assumes the doma= ins cfg is lightning.cfg
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 and name is lightning)=
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ian.
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Hi,
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Sorry for the top posting, I'm at = work at the moment
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 and using different mail client which = is is configured
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 for top posting and I was too lazy to = change it.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 But that did do the trick, the domU is= now fillu
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 booting and working!
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - Valtteri
>
>
>
>
> =A0 =A0 =A0 =A0 Hi,
>
> =A0 =A0 =A0 =A0 dom0 is 64bit, hypervisor is 64bit and that domU (ligh= tning)
> =A0 =A0 =A0 =A0 is 32bit.
>
> =A0 =A0 =A0 =A0 - Valtteri
>
> Hi,
>
> I have now made a startup script that starts the domU first by pausing=
> it, then writes that thingy in xenstore and then unpauses it. Its
> working now fine. I assume that this is some kind of bug that will be<= br> > fixed on later Xen versions, or is this caused by something in my end?=
> Do I have to do something else to get the domU to startup normally?
I'm undecided at the moment whether this represents a bug i= n the old
domU kernel, or something wrong with the toolstack.

Can you tell me what flavour (i.e. address width, 32 or 64) of
hypervisor, dom0 kernel and domU kernel you are using is?

Ian.


Hi,

Hypervisor is 6= 4bit, dom0 is 64bit but the domU is 32bit. If this is what you meant?

- Valtteri

Hi,

I managed to find the sourc= es for my domU kernel, so if you are interested about this problem I can se= nd you a link for the sources and the domU kernel config that I'm using= . Maybe you can then figure out if the bug is in the old domU kernel or in = the toolstack.

- Valtteri
--20cf303b42690f8e6c04cb2a0edb-- --===============5117830919068431524== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============5117830919068431524==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 16:36:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 16:36:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJRvW-0004CT-CB; Wed, 03 Oct 2012 16:36:02 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJRvU-0004CO-VK for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 16:36:01 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1349282152!10021253!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4251 invoked from network); 3 Oct 2012 16:35:53 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 16:35:53 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="14921239" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 16:35:51 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 17:35:51 +0100 Message-ID: <1349282150.650.181.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Valtteri Kiviniemi Date: Wed, 3 Oct 2012 17:35:50 +0100 In-Reply-To: References: <1349259542.650.122.camel@zakaz.uk.xensource.com> <1349261397.650.130.camel@zakaz.uk.xensource.com> <1349263669.650.131.camel@zakaz.uk.xensource.com> <1349266207.650.137.camel@zakaz.uk.xensource.com> <1349278604.650.162.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Xen 4.2.0, xl toolstack cant launch older domUs X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-10-03 at 16:39 +0100, Valtteri Kiviniemi wrote: > Hypervisor is 64bit, dom0 is 64bit but the domU is 32bit. If this is > what you meant? It is. I think the underlying bug here is that your 32bit domU kernel predates the ability to run 32 bit guests on 64 bit hypervisors. Guest kernels are supposed to write that protocol node themselves. It appears that xend includes some sort of workaround for this which xl does not. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 16:36:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 16:36:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJRvW-0004CT-CB; Wed, 03 Oct 2012 16:36:02 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJRvU-0004CO-VK for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 16:36:01 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1349282152!10021253!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4251 invoked from network); 3 Oct 2012 16:35:53 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 16:35:53 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="14921239" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 16:35:51 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 17:35:51 +0100 Message-ID: <1349282150.650.181.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Valtteri Kiviniemi Date: Wed, 3 Oct 2012 17:35:50 +0100 In-Reply-To: References: <1349259542.650.122.camel@zakaz.uk.xensource.com> <1349261397.650.130.camel@zakaz.uk.xensource.com> <1349263669.650.131.camel@zakaz.uk.xensource.com> <1349266207.650.137.camel@zakaz.uk.xensource.com> <1349278604.650.162.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Xen 4.2.0, xl toolstack cant launch older domUs X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-10-03 at 16:39 +0100, Valtteri Kiviniemi wrote: > Hypervisor is 64bit, dom0 is 64bit but the domU is 32bit. If this is > what you meant? It is. I think the underlying bug here is that your 32bit domU kernel predates the ability to run 32 bit guests on 64 bit hypervisors. Guest kernels are supposed to write that protocol node themselves. It appears that xend includes some sort of workaround for this which xl does not. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 16:41:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 16:41:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJS0u-0004Li-8x; Wed, 03 Oct 2012 16:41:36 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJS0t-0004Lc-M6 for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 16:41:35 +0000 Received: from [85.158.137.99:54798] by server-1.bemta-3.messagelabs.com id F0/09-16425-EBA6C605; Wed, 03 Oct 2012 16:41:34 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-12.tower-217.messagelabs.com!1349282493!17025320!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11601 invoked from network); 3 Oct 2012 16:41:34 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 16:41:34 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="14921334" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 16:41:33 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 17:41:33 +0100 Message-ID: <1349282492.650.185.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Wed, 3 Oct 2012 17:41:32 +0100 In-Reply-To: <1349280814.650.178.camel@zakaz.uk.xensource.com> References: <1349272182.650.150.camel@zakaz.uk.xensource.com> <1349272482.650.151.camel@zakaz.uk.xensource.com> <20121003141116.GA10633@phenom.dumpdata.com> <1349276431.650.156.camel@zakaz.uk.xensource.com> <1349279862.650.171.camel@zakaz.uk.xensource.com> <1349280814.650.178.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH] xen: point xen_start_info to a dummy struct for PV on HVM guests X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-10-03 at 17:13 +0100, Ian Campbell wrote: > On Wed, 2012-10-03 at 17:05 +0100, Stefano Stabellini wrote: > > On Wed, 3 Oct 2012, Ian Campbell wrote: > > > On Wed, 2012-10-03 at 16:48 +0100, Stefano Stabellini wrote: > > > > On Wed, 3 Oct 2012, Ian Campbell wrote: > > > > > On Wed, 2012-10-03 at 15:11 +0100, Konrad Rzeszutek Wilk wrote: > > > > > > On Wed, Oct 03, 2012 at 02:54:42PM +0100, Ian Campbell wrote: > > > > > > > On Wed, 2012-10-03 at 14:51 +0100, Stefano Stabellini wrote: > > > > > > > > On Wed, 3 Oct 2012, Ian Campbell wrote: > > > > > > > > > On Wed, 2012-10-03 at 14:37 +0100, Stefano Stabellini wrote: > > > > > > > > > > PV on HVM guests don't have a start_info page mapped by Xen, so > > > > > > > > > > xen_start_info is just NULL for them. > > > > > > > > > > That is problem because other parts of the code expect xen_start_info to > > > > > > > > > > point to something valid, for example xen_initial_domain() is defined as > > > > > > > > > > follow: > > > > > > > > > > > > > > > > > > > > #define xen_initial_domain() (xen_domain() && \ > > > > > > > > > > xen_start_info->flags & SIF_INITDOMAIN) > > > > > > > > > > > > > > > > > > But anyone who calls this before xen_start_info is setup is going to get > > > > > > > > > a bogus result, specifically in this case they will think they are domU > > > > > > > > > when in reality they are dom0 -- wouldn't it be better to fix those > > > > > > > > > callsites? > > > > > > > > > > > > > > > > That cannot be the case because setting up xen_start_info is the very > > > > > > > > first thing that is done, before even calling to C. > > > > > > > > > > > > > > On PV, yes, but you are trying to fix PVHVM here, no? > > > > > > > > > > > > > > Otherwise if this is always set before calling into C then what is the > > > > > > > purpose of this patch? > > > > > > > > > > > > to fix this - as PVHVM has it set to NULL and we end up de-referencing > > > > > > the xen_start_info and crashing. As so:: > > > > > > > > > > > > > > > > Right, so returning to my original point: The caller here is calling > > > > > xen_initial_domain() *before* start info is setup. This is bogus and is > > > > > your actual bug, all this patch does is hide that real issue. > > > > > > > > That is because xen_start_info wasn't setup at all for PV on HVM guests. > > > > > > > > The real reason is that PV on HVM guests don't have one, but that is > > > > another matter. Until we get rid of all the references to xen_start_info > > > > outside of PV specific code, we should just assume that there is one, > > > > and that is already setup. > > > > > > > > One day not too far from now, we might refactor the code to never > > > > reference xen_start_info directly, but I don't think that now is the > > > > time for that. Also consider that this is the same thing we do on ARM. > > > > > > We actual fill in the dummy start info with valid information on ARM > > > though, we don't just leave it full of zeroes. > > > > > > If we do start out with start_info pointing to an uninitialised > > > start_info on ARM too then I would argue that this is also a mistake. > > > > Yes, we do point xen_start_info to an uninitialised start_info on ARM > > too (I don't think is a mistake). Then when and if we have more > > information we write them to start_info. > > So callers of xen_initial_domain in dom0 before xen_guest_init is called > get the wrong result? > > That sounds like a mistake to me. How about (modulo my not having looked up the actual names of the constants etc): #define xen_initial_domain() (xen_domain() && arch_is_initial_domain()) on x86: int arch_is_initial_domain(void) { /* The initial domain is always PV and * therefore start_info is always set for it. */ return start_info && start_info->flags & SIF_INITDOMAIN; } on ARM: int arch_is_initial_domain(void) { static is_initial = -1; if (is_initial == -1) is_initial = HVM_param_get(HVMPARAM_DOM0) return is_initial; } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 16:41:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 16:41:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJS0u-0004Li-8x; Wed, 03 Oct 2012 16:41:36 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJS0t-0004Lc-M6 for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 16:41:35 +0000 Received: from [85.158.137.99:54798] by server-1.bemta-3.messagelabs.com id F0/09-16425-EBA6C605; Wed, 03 Oct 2012 16:41:34 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-12.tower-217.messagelabs.com!1349282493!17025320!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11601 invoked from network); 3 Oct 2012 16:41:34 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 16:41:34 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="14921334" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 16:41:33 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 17:41:33 +0100 Message-ID: <1349282492.650.185.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Wed, 3 Oct 2012 17:41:32 +0100 In-Reply-To: <1349280814.650.178.camel@zakaz.uk.xensource.com> References: <1349272182.650.150.camel@zakaz.uk.xensource.com> <1349272482.650.151.camel@zakaz.uk.xensource.com> <20121003141116.GA10633@phenom.dumpdata.com> <1349276431.650.156.camel@zakaz.uk.xensource.com> <1349279862.650.171.camel@zakaz.uk.xensource.com> <1349280814.650.178.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH] xen: point xen_start_info to a dummy struct for PV on HVM guests X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-10-03 at 17:13 +0100, Ian Campbell wrote: > On Wed, 2012-10-03 at 17:05 +0100, Stefano Stabellini wrote: > > On Wed, 3 Oct 2012, Ian Campbell wrote: > > > On Wed, 2012-10-03 at 16:48 +0100, Stefano Stabellini wrote: > > > > On Wed, 3 Oct 2012, Ian Campbell wrote: > > > > > On Wed, 2012-10-03 at 15:11 +0100, Konrad Rzeszutek Wilk wrote: > > > > > > On Wed, Oct 03, 2012 at 02:54:42PM +0100, Ian Campbell wrote: > > > > > > > On Wed, 2012-10-03 at 14:51 +0100, Stefano Stabellini wrote: > > > > > > > > On Wed, 3 Oct 2012, Ian Campbell wrote: > > > > > > > > > On Wed, 2012-10-03 at 14:37 +0100, Stefano Stabellini wrote: > > > > > > > > > > PV on HVM guests don't have a start_info page mapped by Xen, so > > > > > > > > > > xen_start_info is just NULL for them. > > > > > > > > > > That is problem because other parts of the code expect xen_start_info to > > > > > > > > > > point to something valid, for example xen_initial_domain() is defined as > > > > > > > > > > follow: > > > > > > > > > > > > > > > > > > > > #define xen_initial_domain() (xen_domain() && \ > > > > > > > > > > xen_start_info->flags & SIF_INITDOMAIN) > > > > > > > > > > > > > > > > > > But anyone who calls this before xen_start_info is setup is going to get > > > > > > > > > a bogus result, specifically in this case they will think they are domU > > > > > > > > > when in reality they are dom0 -- wouldn't it be better to fix those > > > > > > > > > callsites? > > > > > > > > > > > > > > > > That cannot be the case because setting up xen_start_info is the very > > > > > > > > first thing that is done, before even calling to C. > > > > > > > > > > > > > > On PV, yes, but you are trying to fix PVHVM here, no? > > > > > > > > > > > > > > Otherwise if this is always set before calling into C then what is the > > > > > > > purpose of this patch? > > > > > > > > > > > > to fix this - as PVHVM has it set to NULL and we end up de-referencing > > > > > > the xen_start_info and crashing. As so:: > > > > > > > > > > > > > > > > Right, so returning to my original point: The caller here is calling > > > > > xen_initial_domain() *before* start info is setup. This is bogus and is > > > > > your actual bug, all this patch does is hide that real issue. > > > > > > > > That is because xen_start_info wasn't setup at all for PV on HVM guests. > > > > > > > > The real reason is that PV on HVM guests don't have one, but that is > > > > another matter. Until we get rid of all the references to xen_start_info > > > > outside of PV specific code, we should just assume that there is one, > > > > and that is already setup. > > > > > > > > One day not too far from now, we might refactor the code to never > > > > reference xen_start_info directly, but I don't think that now is the > > > > time for that. Also consider that this is the same thing we do on ARM. > > > > > > We actual fill in the dummy start info with valid information on ARM > > > though, we don't just leave it full of zeroes. > > > > > > If we do start out with start_info pointing to an uninitialised > > > start_info on ARM too then I would argue that this is also a mistake. > > > > Yes, we do point xen_start_info to an uninitialised start_info on ARM > > too (I don't think is a mistake). Then when and if we have more > > information we write them to start_info. > > So callers of xen_initial_domain in dom0 before xen_guest_init is called > get the wrong result? > > That sounds like a mistake to me. How about (modulo my not having looked up the actual names of the constants etc): #define xen_initial_domain() (xen_domain() && arch_is_initial_domain()) on x86: int arch_is_initial_domain(void) { /* The initial domain is always PV and * therefore start_info is always set for it. */ return start_info && start_info->flags & SIF_INITDOMAIN; } on ARM: int arch_is_initial_domain(void) { static is_initial = -1; if (is_initial == -1) is_initial = HVM_param_get(HVMPARAM_DOM0) return is_initial; } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 16:46:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 16:46:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJS5e-0004Vq-5h; Wed, 03 Oct 2012 16:46:30 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJS5c-0004Vl-NE for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 16:46:29 +0000 Received: from [85.158.139.211:36959] by server-11.bemta-5.messagelabs.com id 88/4C-13866-4EB6C605; Wed, 03 Oct 2012 16:46:28 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-13.tower-206.messagelabs.com!1349282787!16973779!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12727 invoked from network); 3 Oct 2012 16:46:27 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 16:46:27 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="14921397" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 16:46:27 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 17:46:27 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TJS5a-00068t-RN; Wed, 03 Oct 2012 16:46:26 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1TJS5a-0006w1-Kb; Wed, 03 Oct 2012 17:46:26 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Wed, 3 Oct 2012 17:46:26 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [linux-3.0 test] 13915: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 13915 linux-3.0 real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13915/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail like 13777 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail like 13777 test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail like 13777 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 8 debian-fixup fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass version targeted for testing: linux b9a7985a8d9ca00d8ce977756fde1306c9ab1e41 baseline version: linux 3d2e7b3b3e876fae210e55c872df8f6750ab0fa3 ------------------------------------------------------------ People who touched revisions under test: ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-amd64-amd64-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=linux-3.0 + revision=b9a7985a8d9ca00d8ce977756fde1306c9ab1e41 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push linux-3.0 b9a7985a8d9ca00d8ce977756fde1306c9ab1e41 + branch=linux-3.0 + revision=b9a7985a8d9ca00d8ce977756fde1306c9ab1e41 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + . cri-common ++ umask 002 + select_xenbranch + case "$branch" in + tree=linux + xenbranch=xen-unstable + '[' xlinux = xlinux ']' + linuxbranch=linux-3.0 + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg ++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.linux-3.0 ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git ++ : daily-cron.linux-3.0 + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git + info_linux_tree linux-3.0 + case $1 in + : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git + : linux-3.0.y + : linux-3.0.y + : git + : git + : git://xenbits.xen.org/linux-pvops.git + : xen@xenbits.xensource.com:git/linux-pvops.git + : tested/linux-3.0 + : tested/linux-3.0 + return 0 + cd /export/home/osstest/repos/linux + git push xen@xenbits.xensource.com:git/linux-pvops.git b9a7985a8d9ca00d8ce977756fde1306c9ab1e41:tested/linux-3.0 Counting objects: 1 Counting objects: 24 Counting objects: 630 Counting objects: 995, done. Compressing objects: 0% (1/129) Compressing objects: 1% (2/129) Compressing objects: 2% (3/129) Compressing objects: 3% (4/129) Compressing objects: 4% (6/129) Compressing objects: 5% (7/129) Compressing objects: 6% (8/129) Compressing objects: 7% (10/129) Compressing objects: 8% (11/129) Compressing objects: 9% (12/129) Compressing objects: 10% (13/129) Compressing objects: 11% (15/129) Compressing objects: 12% (16/129) Compressing objects: 13% (17/129) Compressing objects: 14% (19/129) Compressing objects: 15% (20/129) Compressing objects: 16% (21/129) Compressing objects: 17% (22/129) Compressing objects: 18% (24/129) Compressing objects: 19% (25/129) Compressing objects: 20% (26/129) Compressing objects: 21% (28/129) Compressing objects: 22% (29/129) Compressing objects: 23% (30/129) Compressing objects: 24% (31/129) Compressing objects: 25% (33/129) Compressing objects: 26% (34/129) Compressing objects: 27% (35/129) Compressing objects: 28% (37/129) Compressing objects: 29% (38/129) Compressing objects: 30% (39/129) Compressing objects: 31% (40/129) Compressing objects: 32% (42/129) Compressing objects: 33% (43/129) Compressing objects: 34% (44/129) Compressing objects: 35% (46/129) Compressing objects: 36% (47/129) Compressing objects: 37% (48/129) Compressing objects: 38% (50/129) Compressing objects: 39% (51/129) Compressing objects: 40% (52/129) Compressing objects: 41% (53/129) Compressing objects: 42% (55/129) Compressing objects: 43% (56/129) Compressing objects: 44% (57/129) Compressing objects: 45% (59/129) Compressing objects: 46% (60/129) Compressing objects: 47% (61/129) Compressing objects: 48% (62/129) Compressing objects: 49% (64/129) Compressing objects: 50% (65/129) Compressing objects: 51% (66/129) Compressing objects: 52% (68/129) Compressing objects: 53% (69/129) Compressing objects: 54% (70/129) Compressing objects: 55% (71/129) Compressing objects: 56% (73/129) Compressing objects: 57% (74/129) Compressing objects: 58% (75/129) Compressing objects: 59% (77/129) Compressing objects: 60% (78/129) Compressing objects: 61% (79/129) Compressing objects: 62% (80/129) Compressing objects: 63% (82/129) Compressing objects: 64% (83/129) Compressing objects: 65% (84/129) Compressing objects: 66% (86/129) Compressing objects: 67% (87/129) Compressing objects: 68% (88/129) Compressing objects: 69% (90/129) Compressing objects: 70% (91/129) Compressing objects: 71% (92/129) Compressing objects: 72% (93/129) Compressing objects: 73% (95/129) Compressing objects: 74% (96/129) Compressing objects: 75% (97/129) Compressing objects: 76% (99/129) Compressing objects: 77% (100/129) Compressing objects: 78% (101/129) Compressing objects: 79% (102/129) Compressing objects: 80% (104/129) Compressing objects: 81% (105/129) Compressing objects: 82% (106/129) Compressing objects: 83% (108/129) Compressing objects: 84% (109/129) Compressing objects: 85% (110/129) Compressing objects: 86% (111/129) Compressing objects: 87% (113/129) Compressing objects: 88% (114/129) Compressing objects: 89% (115/129) Compressing objects: 90% (117/129) Compressing objects: 91% (118/129) Compressing objects: 92% (119/129) Compressing objects: 93% (120/129) Compressing objects: 94% (122/129) Compressing objects: 95% (123/129) Compressing objects: 96% (124/129) Compressing objects: 97% (126/129) Compressing objects: 98% (127/129) Compressing objects: 99% (128/129) Compressing objects: 100% (129/129) Compressing objects: 100% (129/129), done. Writing objects: 0% (1/746) Writing objects: 1% (8/746) Writing objects: 2% (15/746) Writing objects: 3% (23/746) Writing objects: 4% (30/746) Writing objects: 5% (38/746) Writing objects: 6% (45/746) Writing objects: 7% (53/746) Writing objects: 8% (60/746) Writing objects: 9% (68/746) Writing objects: 10% (75/746) Writing objects: 11% (83/746) Writing objects: 12% (90/746) Writing objects: 13% (97/746) Writing objects: 14% (105/746) Writing objects: 15% (112/746) Writing objects: 16% (120/746) Writing objects: 17% (127/746) Writing objects: 18% (135/746) Writing objects: 19% (142/746) Writing objects: 20% (150/746) Writing objects: 21% (157/746) Writing objects: 22% (165/746) Writing objects: 23% (172/746) Writing objects: 24% (180/746) Writing objects: 25% (187/746) Writing objects: 26% (194/746) Writing objects: 27% (202/746) Writing objects: 28% (209/746) Writing objects: 29% (217/746) Writing objects: 30% (224/746) Writing objects: 31% (232/746) Writing objects: 32% (239/746) Writing objects: 33% (247/746) Writing objects: 34% (254/746) Writing objects: 35% (262/746) Writing objects: 36% (269/746) Writing objects: 37% (277/746) Writing objects: 38% (284/746) Writing objects: 39% (291/746) Writing objects: 40% (299/746) Writing objects: 41% (306/746) Writing objects: 42% (314/746) Writing objects: 43% (321/746) Writing objects: 44% (329/746) Writing objects: 45% (336/746) Writing objects: 46% (344/746) Writing objects: 47% (351/746) Writing objects: 48% (359/746) Writing objects: 49% (366/746) Writing objects: 50% (373/746) Writing objects: 51% (381/746) Writing objects: 52% (388/746) Writing objects: 53% (396/746) Writing objects: 54% (403/746) Writing objects: 55% (411/746) Writing objects: 56% (418/746) Writing objects: 57% (426/746) Writing objects: 58% (433/746) Writing objects: 59% (441/746) Writing objects: 60% (448/746) Writing objects: 61% (456/746) Writing objects: 62% (463/746) Writing objects: 63% (470/746) Writing objects: 64% (478/746) Writing objects: 65% (485/746) Writing objects: 66% (493/746) Writing objects: 67% (500/746) Writing objects: 68% (508/746) Writing objects: 69% (515/746) Writing objects: 70% (523/746) Writing objects: 71% (530/746) Writing objects: 72% (538/746) Writing objects: 73% (545/746) Writing objects: 74% (553/746) Writing objects: 75% (560/746) Writing objects: 76% (567/746) Writing objects: 77% (575/746) Writing objects: 78% (582/746) Writing objects: 79% (590/746) Writing objects: 80% (597/746) Writing objects: 81% (605/746) Writing objects: 82% (612/746) Writing objects: 83% (620/746) Writing objects: 84% (627/746) Writing objects: 85% (635/746) Writing objects: 86% (642/746) Writing objects: 87% (650/746) Writing objects: 88% (657/746) Writing objects: 89% (664/746) Writing objects: 90% (672/746) Writing objects: 91% (679/746) Writing objects: 92% (687/746) Writing objects: 93% (694/746) Writing objects: 94% (702/746) Writing objects: 95% (709/746) Writing objects: 96% (717/746) Writing objects: 97% (724/746) Writing objects: 98% (732/746) Writing objects: 99% (739/746) Writing objects: 100% (746/746) Writing objects: 100% (746/746), 139.75 KiB, done. Total 746 (delta 615), reused 746 (delta 615) To xen@xenbits.xensource.com:git/linux-pvops.git Auto packing the repository for optimum performance. 3d2e7b3..b9a7985 b9a7985a8d9ca00d8ce977756fde1306c9ab1e41 -> tested/linux-3.0 + exit 0 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 16:46:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 16:46:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJS5e-0004Vq-5h; Wed, 03 Oct 2012 16:46:30 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJS5c-0004Vl-NE for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 16:46:29 +0000 Received: from [85.158.139.211:36959] by server-11.bemta-5.messagelabs.com id 88/4C-13866-4EB6C605; Wed, 03 Oct 2012 16:46:28 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-13.tower-206.messagelabs.com!1349282787!16973779!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12727 invoked from network); 3 Oct 2012 16:46:27 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 16:46:27 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="14921397" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 16:46:27 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 17:46:27 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TJS5a-00068t-RN; Wed, 03 Oct 2012 16:46:26 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1TJS5a-0006w1-Kb; Wed, 03 Oct 2012 17:46:26 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Wed, 3 Oct 2012 17:46:26 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [linux-3.0 test] 13915: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 13915 linux-3.0 real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13915/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail like 13777 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail like 13777 test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail like 13777 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 8 debian-fixup fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass version targeted for testing: linux b9a7985a8d9ca00d8ce977756fde1306c9ab1e41 baseline version: linux 3d2e7b3b3e876fae210e55c872df8f6750ab0fa3 ------------------------------------------------------------ People who touched revisions under test: ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-amd64-amd64-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=linux-3.0 + revision=b9a7985a8d9ca00d8ce977756fde1306c9ab1e41 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push linux-3.0 b9a7985a8d9ca00d8ce977756fde1306c9ab1e41 + branch=linux-3.0 + revision=b9a7985a8d9ca00d8ce977756fde1306c9ab1e41 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + . cri-common ++ umask 002 + select_xenbranch + case "$branch" in + tree=linux + xenbranch=xen-unstable + '[' xlinux = xlinux ']' + linuxbranch=linux-3.0 + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg ++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.linux-3.0 ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git ++ : daily-cron.linux-3.0 + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git + info_linux_tree linux-3.0 + case $1 in + : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git + : linux-3.0.y + : linux-3.0.y + : git + : git + : git://xenbits.xen.org/linux-pvops.git + : xen@xenbits.xensource.com:git/linux-pvops.git + : tested/linux-3.0 + : tested/linux-3.0 + return 0 + cd /export/home/osstest/repos/linux + git push xen@xenbits.xensource.com:git/linux-pvops.git b9a7985a8d9ca00d8ce977756fde1306c9ab1e41:tested/linux-3.0 Counting objects: 1 Counting objects: 24 Counting objects: 630 Counting objects: 995, done. Compressing objects: 0% (1/129) Compressing objects: 1% (2/129) Compressing objects: 2% (3/129) Compressing objects: 3% (4/129) Compressing objects: 4% (6/129) Compressing objects: 5% (7/129) Compressing objects: 6% (8/129) Compressing objects: 7% (10/129) Compressing objects: 8% (11/129) Compressing objects: 9% (12/129) Compressing objects: 10% (13/129) Compressing objects: 11% (15/129) Compressing objects: 12% (16/129) Compressing objects: 13% (17/129) Compressing objects: 14% (19/129) Compressing objects: 15% (20/129) Compressing objects: 16% (21/129) Compressing objects: 17% (22/129) Compressing objects: 18% (24/129) Compressing objects: 19% (25/129) Compressing objects: 20% (26/129) Compressing objects: 21% (28/129) Compressing objects: 22% (29/129) Compressing objects: 23% (30/129) Compressing objects: 24% (31/129) Compressing objects: 25% (33/129) Compressing objects: 26% (34/129) Compressing objects: 27% (35/129) Compressing objects: 28% (37/129) Compressing objects: 29% (38/129) Compressing objects: 30% (39/129) Compressing objects: 31% (40/129) Compressing objects: 32% (42/129) Compressing objects: 33% (43/129) Compressing objects: 34% (44/129) Compressing objects: 35% (46/129) Compressing objects: 36% (47/129) Compressing objects: 37% (48/129) Compressing objects: 38% (50/129) Compressing objects: 39% (51/129) Compressing objects: 40% (52/129) Compressing objects: 41% (53/129) Compressing objects: 42% (55/129) Compressing objects: 43% (56/129) Compressing objects: 44% (57/129) Compressing objects: 45% (59/129) Compressing objects: 46% (60/129) Compressing objects: 47% (61/129) Compressing objects: 48% (62/129) Compressing objects: 49% (64/129) Compressing objects: 50% (65/129) Compressing objects: 51% (66/129) Compressing objects: 52% (68/129) Compressing objects: 53% (69/129) Compressing objects: 54% (70/129) Compressing objects: 55% (71/129) Compressing objects: 56% (73/129) Compressing objects: 57% (74/129) Compressing objects: 58% (75/129) Compressing objects: 59% (77/129) Compressing objects: 60% (78/129) Compressing objects: 61% (79/129) Compressing objects: 62% (80/129) Compressing objects: 63% (82/129) Compressing objects: 64% (83/129) Compressing objects: 65% (84/129) Compressing objects: 66% (86/129) Compressing objects: 67% (87/129) Compressing objects: 68% (88/129) Compressing objects: 69% (90/129) Compressing objects: 70% (91/129) Compressing objects: 71% (92/129) Compressing objects: 72% (93/129) Compressing objects: 73% (95/129) Compressing objects: 74% (96/129) Compressing objects: 75% (97/129) Compressing objects: 76% (99/129) Compressing objects: 77% (100/129) Compressing objects: 78% (101/129) Compressing objects: 79% (102/129) Compressing objects: 80% (104/129) Compressing objects: 81% (105/129) Compressing objects: 82% (106/129) Compressing objects: 83% (108/129) Compressing objects: 84% (109/129) Compressing objects: 85% (110/129) Compressing objects: 86% (111/129) Compressing objects: 87% (113/129) Compressing objects: 88% (114/129) Compressing objects: 89% (115/129) Compressing objects: 90% (117/129) Compressing objects: 91% (118/129) Compressing objects: 92% (119/129) Compressing objects: 93% (120/129) Compressing objects: 94% (122/129) Compressing objects: 95% (123/129) Compressing objects: 96% (124/129) Compressing objects: 97% (126/129) Compressing objects: 98% (127/129) Compressing objects: 99% (128/129) Compressing objects: 100% (129/129) Compressing objects: 100% (129/129), done. Writing objects: 0% (1/746) Writing objects: 1% (8/746) Writing objects: 2% (15/746) Writing objects: 3% (23/746) Writing objects: 4% (30/746) Writing objects: 5% (38/746) Writing objects: 6% (45/746) Writing objects: 7% (53/746) Writing objects: 8% (60/746) Writing objects: 9% (68/746) Writing objects: 10% (75/746) Writing objects: 11% (83/746) Writing objects: 12% (90/746) Writing objects: 13% (97/746) Writing objects: 14% (105/746) Writing objects: 15% (112/746) Writing objects: 16% (120/746) Writing objects: 17% (127/746) Writing objects: 18% (135/746) Writing objects: 19% (142/746) Writing objects: 20% (150/746) Writing objects: 21% (157/746) Writing objects: 22% (165/746) Writing objects: 23% (172/746) Writing objects: 24% (180/746) Writing objects: 25% (187/746) Writing objects: 26% (194/746) Writing objects: 27% (202/746) Writing objects: 28% (209/746) Writing objects: 29% (217/746) Writing objects: 30% (224/746) Writing objects: 31% (232/746) Writing objects: 32% (239/746) Writing objects: 33% (247/746) Writing objects: 34% (254/746) Writing objects: 35% (262/746) Writing objects: 36% (269/746) Writing objects: 37% (277/746) Writing objects: 38% (284/746) Writing objects: 39% (291/746) Writing objects: 40% (299/746) Writing objects: 41% (306/746) Writing objects: 42% (314/746) Writing objects: 43% (321/746) Writing objects: 44% (329/746) Writing objects: 45% (336/746) Writing objects: 46% (344/746) Writing objects: 47% (351/746) Writing objects: 48% (359/746) Writing objects: 49% (366/746) Writing objects: 50% (373/746) Writing objects: 51% (381/746) Writing objects: 52% (388/746) Writing objects: 53% (396/746) Writing objects: 54% (403/746) Writing objects: 55% (411/746) Writing objects: 56% (418/746) Writing objects: 57% (426/746) Writing objects: 58% (433/746) Writing objects: 59% (441/746) Writing objects: 60% (448/746) Writing objects: 61% (456/746) Writing objects: 62% (463/746) Writing objects: 63% (470/746) Writing objects: 64% (478/746) Writing objects: 65% (485/746) Writing objects: 66% (493/746) Writing objects: 67% (500/746) Writing objects: 68% (508/746) Writing objects: 69% (515/746) Writing objects: 70% (523/746) Writing objects: 71% (530/746) Writing objects: 72% (538/746) Writing objects: 73% (545/746) Writing objects: 74% (553/746) Writing objects: 75% (560/746) Writing objects: 76% (567/746) Writing objects: 77% (575/746) Writing objects: 78% (582/746) Writing objects: 79% (590/746) Writing objects: 80% (597/746) Writing objects: 81% (605/746) Writing objects: 82% (612/746) Writing objects: 83% (620/746) Writing objects: 84% (627/746) Writing objects: 85% (635/746) Writing objects: 86% (642/746) Writing objects: 87% (650/746) Writing objects: 88% (657/746) Writing objects: 89% (664/746) Writing objects: 90% (672/746) Writing objects: 91% (679/746) Writing objects: 92% (687/746) Writing objects: 93% (694/746) Writing objects: 94% (702/746) Writing objects: 95% (709/746) Writing objects: 96% (717/746) Writing objects: 97% (724/746) Writing objects: 98% (732/746) Writing objects: 99% (739/746) Writing objects: 100% (746/746) Writing objects: 100% (746/746), 139.75 KiB, done. Total 746 (delta 615), reused 746 (delta 615) To xen@xenbits.xensource.com:git/linux-pvops.git Auto packing the repository for optimum performance. 3d2e7b3..b9a7985 b9a7985a8d9ca00d8ce977756fde1306c9ab1e41 -> tested/linux-3.0 + exit 0 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 17:03:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 17:03:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJSLu-0004jZ-Pc; Wed, 03 Oct 2012 17:03:18 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJSLs-0004jU-KJ for xen-devel@lists.xen.org; Wed, 03 Oct 2012 17:03:16 +0000 Received: from [85.158.139.211:21480] by server-6.bemta-5.messagelabs.com id 0B/66-14717-3DF6C605; Wed, 03 Oct 2012 17:03:15 +0000 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-15.tower-206.messagelabs.com!1349283794!21000979!1 X-Originating-IP: [209.85.160.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25094 invoked from network); 3 Oct 2012 17:03:15 -0000 Received: from mail-gh0-f173.google.com (HELO mail-gh0-f173.google.com) (209.85.160.173) by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 17:03:15 -0000 Received: by ghy16 with SMTP id 16so2304992ghy.32 for ; Wed, 03 Oct 2012 10:03:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=oU5Gl+4bHtoI+3TJmoRJBiIJvfd2JXB+fbf4Fv40y9o=; b=p+DaQz5PbQwOywhNKRZx8fVpzp4dFQa2Vq7jQ4C9S40wNs5ZaSaMQhTHdaZrPS454+ RruF/Z4CH3ExTsvLumIinpULFrR2mYQH2edNs7MBBRFkklhKk1n2zHCPk+IhyXf9+pDl AEgTKcI++U2ej4GdHa/eUJxPMiOlwyZeFD2fgRGGoacOr1F8BGnRzuXlngGL8tzB0RHv QQQpi5mC2sch7zFlhIMbrufE7f+4tDnw33pxj7wjkiJmL+2KwPOIX/WWidQAua4wYPh2 ZmAWwurQt3kDFvidMsj5pWkxnJuMqSqi7MLGYOv/bDzjLKE1YMqfpxrDKG3OPFN4ajxz Femg== Received: by 10.101.166.38 with SMTP id t38mr761696ano.23.1349283793829; Wed, 03 Oct 2012 10:03:13 -0700 (PDT) Received: from [172.16.25.10] (firewall.ctxuk.citrix.com. [62.200.22.2]) by mx.google.com with ESMTPS id t46sm6449887yhi.3.2012.10.03.10.03.10 (version=SSLv3 cipher=OTHER); Wed, 03 Oct 2012 10:03:11 -0700 (PDT) Message-ID: <506C6FCB.9070906@xen.org> Date: Wed, 03 Oct 2012 18:03:07 +0100 From: Lars Kurth User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Ian Jackson References: <20448.49637.38489.246434@mariner.uk.xensource.com> <1345718230.12501.79.camel@zakaz.uk.xensource.com> <50604343.1090506@xen.org> <20585.50923.886126.938976@mariner.uk.xensource.com> In-Reply-To: <20585.50923.886126.938976@mariner.uk.xensource.com> Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] Security vulnerability process, and CVE-2012-0217 [vote?] X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: lars.kurth@xen.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Agreed. I will apply and ACK when done Lars On 01/10/2012 17:38, Ian Jackson wrote: > Lars Kurth writes ("Re: [Xen-devel] Security vulnerability process, and CVE-2012-0217 [vote?]"): >> Does anybody have any objections to Ian's changes in this patch series? >> None of these appear significant changes. In line with the decision >> making process, I would be happy to apply. But, I am also happy to run >> this through a vote. > They all seem uncontroversial to me and no-one has objected. You > should go ahead and make the changes, I think. > > Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 17:03:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 17:03:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJSLu-0004jZ-Pc; Wed, 03 Oct 2012 17:03:18 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJSLs-0004jU-KJ for xen-devel@lists.xen.org; Wed, 03 Oct 2012 17:03:16 +0000 Received: from [85.158.139.211:21480] by server-6.bemta-5.messagelabs.com id 0B/66-14717-3DF6C605; Wed, 03 Oct 2012 17:03:15 +0000 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-15.tower-206.messagelabs.com!1349283794!21000979!1 X-Originating-IP: [209.85.160.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25094 invoked from network); 3 Oct 2012 17:03:15 -0000 Received: from mail-gh0-f173.google.com (HELO mail-gh0-f173.google.com) (209.85.160.173) by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 17:03:15 -0000 Received: by ghy16 with SMTP id 16so2304992ghy.32 for ; Wed, 03 Oct 2012 10:03:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=oU5Gl+4bHtoI+3TJmoRJBiIJvfd2JXB+fbf4Fv40y9o=; b=p+DaQz5PbQwOywhNKRZx8fVpzp4dFQa2Vq7jQ4C9S40wNs5ZaSaMQhTHdaZrPS454+ RruF/Z4CH3ExTsvLumIinpULFrR2mYQH2edNs7MBBRFkklhKk1n2zHCPk+IhyXf9+pDl AEgTKcI++U2ej4GdHa/eUJxPMiOlwyZeFD2fgRGGoacOr1F8BGnRzuXlngGL8tzB0RHv QQQpi5mC2sch7zFlhIMbrufE7f+4tDnw33pxj7wjkiJmL+2KwPOIX/WWidQAua4wYPh2 ZmAWwurQt3kDFvidMsj5pWkxnJuMqSqi7MLGYOv/bDzjLKE1YMqfpxrDKG3OPFN4ajxz Femg== Received: by 10.101.166.38 with SMTP id t38mr761696ano.23.1349283793829; Wed, 03 Oct 2012 10:03:13 -0700 (PDT) Received: from [172.16.25.10] (firewall.ctxuk.citrix.com. [62.200.22.2]) by mx.google.com with ESMTPS id t46sm6449887yhi.3.2012.10.03.10.03.10 (version=SSLv3 cipher=OTHER); Wed, 03 Oct 2012 10:03:11 -0700 (PDT) Message-ID: <506C6FCB.9070906@xen.org> Date: Wed, 03 Oct 2012 18:03:07 +0100 From: Lars Kurth User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Ian Jackson References: <20448.49637.38489.246434@mariner.uk.xensource.com> <1345718230.12501.79.camel@zakaz.uk.xensource.com> <50604343.1090506@xen.org> <20585.50923.886126.938976@mariner.uk.xensource.com> In-Reply-To: <20585.50923.886126.938976@mariner.uk.xensource.com> Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] Security vulnerability process, and CVE-2012-0217 [vote?] X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: lars.kurth@xen.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Agreed. I will apply and ACK when done Lars On 01/10/2012 17:38, Ian Jackson wrote: > Lars Kurth writes ("Re: [Xen-devel] Security vulnerability process, and CVE-2012-0217 [vote?]"): >> Does anybody have any objections to Ian's changes in this patch series? >> None of these appear significant changes. In line with the decision >> making process, I would be happy to apply. But, I am also happy to run >> this through a vote. > They all seem uncontroversial to me and no-one has objected. You > should go ahead and make the changes, I think. > > Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 17:04:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 17:04:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJSMn-0004nN-6Y; Wed, 03 Oct 2012 17:04:13 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJSMk-0004mR-N4 for xen-devel@lists.xen.org; Wed, 03 Oct 2012 17:04:11 +0000 Received: from [85.158.137.99:40318] by server-7.bemta-3.messagelabs.com id B8/8B-15765-9007C605; Wed, 03 Oct 2012 17:04:09 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-8.tower-217.messagelabs.com!1349283846!14794548!3 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzk2MzY=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27995 invoked from network); 3 Oct 2012 17:04:09 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 17:04:09 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="210185669" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 16:46:15 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 12:46:15 -0400 Received: from qabil.uk.xensource.com ([10.80.2.76]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJRs6-0007Eo-OO; Wed, 03 Oct 2012 17:32:30 +0100 From: David Vrabel To: xen-devel@lists.xen.org Date: Wed, 3 Oct 2012 17:32:25 +0100 Message-ID: <1349281947-5009-3-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1349281947-5009-1-git-send-email-david.vrabel@citrix.com> References: <1349281947-5009-1-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Cc: Frediano Ziglio , David Vrabel , George Dunlap Subject: [Xen-devel] [PATCH 2/4] trace: allow for different sub-classes of TRC_PV_* tracepoints X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: David Vrabel We want to add additional sub-classes for TRC_PV tracepoints and to be able to only capture these new sub-classes. This cannot currently be done as the existing tracepoints all use a sub-class of 0xf. So, redefine the PV events to use a new sub-class. All the current tracepoints are tracing entry points to the hypervisor so the sub-class is named TRC_PV_ENTRY. This change does not affect xenalyze as that only looks at the main class and the event number and does not use the sub-class field. Signed-off-by: Frediano Ziglio Signed-off-by: David Vrabel Acked-by: George Dunlap --- tools/xentrace/formats | 44 ++++++++++++++++++++++---------------------- xen/include/public/trace.h | 35 +++++++++++++++++++++-------------- 2 files changed, 43 insertions(+), 36 deletions(-) diff --git a/tools/xentrace/formats b/tools/xentrace/formats index 04e54d5..71220c0 100644 --- a/tools/xentrace/formats +++ b/tools/xentrace/formats @@ -82,28 +82,28 @@ 0x0010f002 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) page_grant_unmap [ domid = %(1)d ] 0x0010f003 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) page_grant_transfer [ domid = %(1)d ] -0x0020f001 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) hypercall [ eip = 0x%(1)08x, eax = 0x%(2)08x ] -0x0020f101 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) hypercall [ rip = 0x%(2)08x%(1)08x, eax = 0x%(3)08x ] -0x0020f003 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) trap [ eip = 0x%(1)08x, trapnr:error = 0x%(2)08x ] -0x0020f103 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) trap [ rip = 0x%(2)08x%(1)08x, trapnr:error = 0x%(3)08x ] -0x0020f004 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) page_fault [ eip = 0x%(1)08x, addr = 0x%(2)08x, error = 0x%(3)08x ] -0x0020f104 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) page_fault [ rip = 0x%(2)08x%(1)08x, addr = 0x%(4)08x%(3)08x, error = 0x%(5)08x ] -0x0020f005 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) forced_invalid_op [ eip = 0x%(1)08x ] -0x0020f105 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) forced_invalid_op [ rip = 0x%(2)08x%(1)08x ] -0x0020f006 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) emulate_privop [ eip = 0x%(1)08x ] -0x0020f106 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) emulate_privop [ rip = 0x%(2)08x%(1)08x ] -0x0020f007 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) emulate_4G [ eip = 0x%(1)08x ] -0x0020f107 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) emulate_4G [ rip = 0x%(2)08x%(1)08x ] -0x0020f008 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) math_state_restore -0x0020f108 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) math_state_restore -0x0020f009 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) paging_fixup [ eip = 0x%(1)08x, addr = 0x%(2)08x ] -0x0020f109 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) paging_fixup [ rip = 0x%(2)08x%(1)08x, addr = 0x%(4)08x%(3)08x ] -0x0020f00a CPU%(cpu)d %(tsc)d (+%(reltsc)8d) gdt_ldt_mapping_fault [ eip = 0x%(1)08x, offset = 0x%(2)08x ] -0x0020f10a CPU%(cpu)d %(tsc)d (+%(reltsc)8d) gdt_ldt_mapping_fault [ rip = 0x%(2)08x%(1)08x, offset = 0x%(4)08x%(3)08x ] -0x0020f00b CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation [ addr = 0x%(3)08x, eip = 0x%(4)08x, npte = 0x%(2)08x%(1)08x ] -0x0020f10b CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation [ addr = 0x%(4)08x%(3)08x, rip = 0x%(6)08x%(5)08x, npte = 0x%(2)08x%(1)08x ] -0x0020f00c CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation_pae [ addr = 0x%(3)08x, eip = 0x%(4)08x, npte = 0x%(2)08x%(1)08x ] -0x0020f10c CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation_pae [ addr = 0x%(4)08x%(3)08x, rip = 0x%(6)08x%(5)08x, npte = 0x%(2)08x%(1)08x ] +0x00201001 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) hypercall [ eip = 0x%(1)08x, eax = 0x%(2)08x ] +0x00201101 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) hypercall [ rip = 0x%(2)08x%(1)08x, eax = 0x%(3)08x ] +0x00201003 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) trap [ eip = 0x%(1)08x, trapnr:error = 0x%(2)08x ] +0x00201103 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) trap [ rip = 0x%(2)08x%(1)08x, trapnr:error = 0x%(3)08x ] +0x00201004 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) page_fault [ eip = 0x%(1)08x, addr = 0x%(2)08x, error = 0x%(3)08x ] +0x00201104 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) page_fault [ rip = 0x%(2)08x%(1)08x, addr = 0x%(4)08x%(3)08x, error = 0x%(5)08x ] +0x00201005 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) forced_invalid_op [ eip = 0x%(1)08x ] +0x00201105 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) forced_invalid_op [ rip = 0x%(2)08x%(1)08x ] +0x00201006 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) emulate_privop [ eip = 0x%(1)08x ] +0x00201106 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) emulate_privop [ rip = 0x%(2)08x%(1)08x ] +0x00201007 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) emulate_4G [ eip = 0x%(1)08x ] +0x00201107 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) emulate_4G [ rip = 0x%(2)08x%(1)08x ] +0x00201008 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) math_state_restore +0x00201108 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) math_state_restore +0x00201009 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) paging_fixup [ eip = 0x%(1)08x, addr = 0x%(2)08x ] +0x00201109 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) paging_fixup [ rip = 0x%(2)08x%(1)08x, addr = 0x%(4)08x%(3)08x ] +0x0020100a CPU%(cpu)d %(tsc)d (+%(reltsc)8d) gdt_ldt_mapping_fault [ eip = 0x%(1)08x, offset = 0x%(2)08x ] +0x0020110a CPU%(cpu)d %(tsc)d (+%(reltsc)8d) gdt_ldt_mapping_fault [ rip = 0x%(2)08x%(1)08x, offset = 0x%(4)08x%(3)08x ] +0x0020100b CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation [ addr = 0x%(3)08x, eip = 0x%(4)08x, npte = 0x%(2)08x%(1)08x ] +0x0020110b CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation [ addr = 0x%(4)08x%(3)08x, rip = 0x%(6)08x%(5)08x, npte = 0x%(2)08x%(1)08x ] +0x0020100c CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation_pae [ addr = 0x%(3)08x, eip = 0x%(4)08x, npte = 0x%(2)08x%(1)08x ] +0x0020110c CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation_pae [ addr = 0x%(4)08x%(3)08x, rip = 0x%(6)08x%(5)08x, npte = 0x%(2)08x%(1)08x ] 0x0040f001 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) shadow_not_shadow [ gl1e = 0x%(2)08x%(1)08x, va = 0x%(3)08x, flags = 0x%(4)08x ] 0x0040f101 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) shadow_not_shadow [ gl1e = 0x%(2)08x%(1)08x, va = 0x%(4)08x%(3)08x, flags = 0x%(5)08x ] diff --git a/xen/include/public/trace.h b/xen/include/public/trace.h index 0dfabe9..1f154bb 100644 --- a/xen/include/public/trace.h +++ b/xen/include/public/trace.h @@ -94,20 +94,19 @@ #define TRC_MEM_POD_ZERO_RECLAIM (TRC_MEM + 17) #define TRC_MEM_POD_SUPERPAGE_SPLINTER (TRC_MEM + 18) - -#define TRC_PV_HYPERCALL (TRC_PV + 1) -#define TRC_PV_TRAP (TRC_PV + 3) -#define TRC_PV_PAGE_FAULT (TRC_PV + 4) -#define TRC_PV_FORCED_INVALID_OP (TRC_PV + 5) -#define TRC_PV_EMULATE_PRIVOP (TRC_PV + 6) -#define TRC_PV_EMULATE_4GB (TRC_PV + 7) -#define TRC_PV_MATH_STATE_RESTORE (TRC_PV + 8) -#define TRC_PV_PAGING_FIXUP (TRC_PV + 9) -#define TRC_PV_GDT_LDT_MAPPING_FAULT (TRC_PV + 10) -#define TRC_PV_PTWR_EMULATION (TRC_PV + 11) -#define TRC_PV_PTWR_EMULATION_PAE (TRC_PV + 12) - /* Indicates that addresses in trace record are 64 bits */ -#define TRC_64_FLAG (0x100) +#define TRC_PV_ENTRY 0x00201000 /* Hypervisor entry points for PV guests. */ + +#define TRC_PV_HYPERCALL (TRC_PV_ENTRY + 1) +#define TRC_PV_TRAP (TRC_PV_ENTRY + 3) +#define TRC_PV_PAGE_FAULT (TRC_PV_ENTRY + 4) +#define TRC_PV_FORCED_INVALID_OP (TRC_PV_ENTRY + 5) +#define TRC_PV_EMULATE_PRIVOP (TRC_PV_ENTRY + 6) +#define TRC_PV_EMULATE_4GB (TRC_PV_ENTRY + 7) +#define TRC_PV_MATH_STATE_RESTORE (TRC_PV_ENTRY + 8) +#define TRC_PV_PAGING_FIXUP (TRC_PV_ENTRY + 9) +#define TRC_PV_GDT_LDT_MAPPING_FAULT (TRC_PV_ENTRY + 10) +#define TRC_PV_PTWR_EMULATION (TRC_PV_ENTRY + 11) +#define TRC_PV_PTWR_EMULATION_PAE (TRC_PV_ENTRY + 12) #define TRC_SHADOW_NOT_SHADOW (TRC_SHADOW + 1) #define TRC_SHADOW_FAST_PROPAGATE (TRC_SHADOW + 2) @@ -187,6 +186,14 @@ #define TRC_HW_IRQ_UNMAPPED_VECTOR (TRC_HW_IRQ + 0x7) #define TRC_HW_IRQ_HANDLED (TRC_HW_IRQ + 0x8) +/* + * Event Flags + * + * Some events (e.g, TRC_PV_TRAP and TRC_HVM_IOMEM_READ) have multiple + * record formats. These event flags distinguish between the + * different formats. + */ +#define TRC_64_FLAG 0x100 /* Addresses are 64 bits (instead of 32 bits) */ /* This structure represents a single trace buffer record. */ struct t_rec { -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 17:04:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 17:04:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJSMn-0004nN-6Y; Wed, 03 Oct 2012 17:04:13 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJSMk-0004mR-N4 for xen-devel@lists.xen.org; Wed, 03 Oct 2012 17:04:11 +0000 Received: from [85.158.137.99:40318] by server-7.bemta-3.messagelabs.com id B8/8B-15765-9007C605; Wed, 03 Oct 2012 17:04:09 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-8.tower-217.messagelabs.com!1349283846!14794548!3 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzk2MzY=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27995 invoked from network); 3 Oct 2012 17:04:09 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 17:04:09 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="210185669" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 16:46:15 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 12:46:15 -0400 Received: from qabil.uk.xensource.com ([10.80.2.76]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJRs6-0007Eo-OO; Wed, 03 Oct 2012 17:32:30 +0100 From: David Vrabel To: xen-devel@lists.xen.org Date: Wed, 3 Oct 2012 17:32:25 +0100 Message-ID: <1349281947-5009-3-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1349281947-5009-1-git-send-email-david.vrabel@citrix.com> References: <1349281947-5009-1-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Cc: Frediano Ziglio , David Vrabel , George Dunlap Subject: [Xen-devel] [PATCH 2/4] trace: allow for different sub-classes of TRC_PV_* tracepoints X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: David Vrabel We want to add additional sub-classes for TRC_PV tracepoints and to be able to only capture these new sub-classes. This cannot currently be done as the existing tracepoints all use a sub-class of 0xf. So, redefine the PV events to use a new sub-class. All the current tracepoints are tracing entry points to the hypervisor so the sub-class is named TRC_PV_ENTRY. This change does not affect xenalyze as that only looks at the main class and the event number and does not use the sub-class field. Signed-off-by: Frediano Ziglio Signed-off-by: David Vrabel Acked-by: George Dunlap --- tools/xentrace/formats | 44 ++++++++++++++++++++++---------------------- xen/include/public/trace.h | 35 +++++++++++++++++++++-------------- 2 files changed, 43 insertions(+), 36 deletions(-) diff --git a/tools/xentrace/formats b/tools/xentrace/formats index 04e54d5..71220c0 100644 --- a/tools/xentrace/formats +++ b/tools/xentrace/formats @@ -82,28 +82,28 @@ 0x0010f002 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) page_grant_unmap [ domid = %(1)d ] 0x0010f003 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) page_grant_transfer [ domid = %(1)d ] -0x0020f001 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) hypercall [ eip = 0x%(1)08x, eax = 0x%(2)08x ] -0x0020f101 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) hypercall [ rip = 0x%(2)08x%(1)08x, eax = 0x%(3)08x ] -0x0020f003 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) trap [ eip = 0x%(1)08x, trapnr:error = 0x%(2)08x ] -0x0020f103 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) trap [ rip = 0x%(2)08x%(1)08x, trapnr:error = 0x%(3)08x ] -0x0020f004 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) page_fault [ eip = 0x%(1)08x, addr = 0x%(2)08x, error = 0x%(3)08x ] -0x0020f104 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) page_fault [ rip = 0x%(2)08x%(1)08x, addr = 0x%(4)08x%(3)08x, error = 0x%(5)08x ] -0x0020f005 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) forced_invalid_op [ eip = 0x%(1)08x ] -0x0020f105 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) forced_invalid_op [ rip = 0x%(2)08x%(1)08x ] -0x0020f006 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) emulate_privop [ eip = 0x%(1)08x ] -0x0020f106 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) emulate_privop [ rip = 0x%(2)08x%(1)08x ] -0x0020f007 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) emulate_4G [ eip = 0x%(1)08x ] -0x0020f107 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) emulate_4G [ rip = 0x%(2)08x%(1)08x ] -0x0020f008 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) math_state_restore -0x0020f108 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) math_state_restore -0x0020f009 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) paging_fixup [ eip = 0x%(1)08x, addr = 0x%(2)08x ] -0x0020f109 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) paging_fixup [ rip = 0x%(2)08x%(1)08x, addr = 0x%(4)08x%(3)08x ] -0x0020f00a CPU%(cpu)d %(tsc)d (+%(reltsc)8d) gdt_ldt_mapping_fault [ eip = 0x%(1)08x, offset = 0x%(2)08x ] -0x0020f10a CPU%(cpu)d %(tsc)d (+%(reltsc)8d) gdt_ldt_mapping_fault [ rip = 0x%(2)08x%(1)08x, offset = 0x%(4)08x%(3)08x ] -0x0020f00b CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation [ addr = 0x%(3)08x, eip = 0x%(4)08x, npte = 0x%(2)08x%(1)08x ] -0x0020f10b CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation [ addr = 0x%(4)08x%(3)08x, rip = 0x%(6)08x%(5)08x, npte = 0x%(2)08x%(1)08x ] -0x0020f00c CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation_pae [ addr = 0x%(3)08x, eip = 0x%(4)08x, npte = 0x%(2)08x%(1)08x ] -0x0020f10c CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation_pae [ addr = 0x%(4)08x%(3)08x, rip = 0x%(6)08x%(5)08x, npte = 0x%(2)08x%(1)08x ] +0x00201001 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) hypercall [ eip = 0x%(1)08x, eax = 0x%(2)08x ] +0x00201101 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) hypercall [ rip = 0x%(2)08x%(1)08x, eax = 0x%(3)08x ] +0x00201003 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) trap [ eip = 0x%(1)08x, trapnr:error = 0x%(2)08x ] +0x00201103 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) trap [ rip = 0x%(2)08x%(1)08x, trapnr:error = 0x%(3)08x ] +0x00201004 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) page_fault [ eip = 0x%(1)08x, addr = 0x%(2)08x, error = 0x%(3)08x ] +0x00201104 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) page_fault [ rip = 0x%(2)08x%(1)08x, addr = 0x%(4)08x%(3)08x, error = 0x%(5)08x ] +0x00201005 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) forced_invalid_op [ eip = 0x%(1)08x ] +0x00201105 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) forced_invalid_op [ rip = 0x%(2)08x%(1)08x ] +0x00201006 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) emulate_privop [ eip = 0x%(1)08x ] +0x00201106 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) emulate_privop [ rip = 0x%(2)08x%(1)08x ] +0x00201007 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) emulate_4G [ eip = 0x%(1)08x ] +0x00201107 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) emulate_4G [ rip = 0x%(2)08x%(1)08x ] +0x00201008 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) math_state_restore +0x00201108 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) math_state_restore +0x00201009 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) paging_fixup [ eip = 0x%(1)08x, addr = 0x%(2)08x ] +0x00201109 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) paging_fixup [ rip = 0x%(2)08x%(1)08x, addr = 0x%(4)08x%(3)08x ] +0x0020100a CPU%(cpu)d %(tsc)d (+%(reltsc)8d) gdt_ldt_mapping_fault [ eip = 0x%(1)08x, offset = 0x%(2)08x ] +0x0020110a CPU%(cpu)d %(tsc)d (+%(reltsc)8d) gdt_ldt_mapping_fault [ rip = 0x%(2)08x%(1)08x, offset = 0x%(4)08x%(3)08x ] +0x0020100b CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation [ addr = 0x%(3)08x, eip = 0x%(4)08x, npte = 0x%(2)08x%(1)08x ] +0x0020110b CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation [ addr = 0x%(4)08x%(3)08x, rip = 0x%(6)08x%(5)08x, npte = 0x%(2)08x%(1)08x ] +0x0020100c CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation_pae [ addr = 0x%(3)08x, eip = 0x%(4)08x, npte = 0x%(2)08x%(1)08x ] +0x0020110c CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation_pae [ addr = 0x%(4)08x%(3)08x, rip = 0x%(6)08x%(5)08x, npte = 0x%(2)08x%(1)08x ] 0x0040f001 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) shadow_not_shadow [ gl1e = 0x%(2)08x%(1)08x, va = 0x%(3)08x, flags = 0x%(4)08x ] 0x0040f101 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) shadow_not_shadow [ gl1e = 0x%(2)08x%(1)08x, va = 0x%(4)08x%(3)08x, flags = 0x%(5)08x ] diff --git a/xen/include/public/trace.h b/xen/include/public/trace.h index 0dfabe9..1f154bb 100644 --- a/xen/include/public/trace.h +++ b/xen/include/public/trace.h @@ -94,20 +94,19 @@ #define TRC_MEM_POD_ZERO_RECLAIM (TRC_MEM + 17) #define TRC_MEM_POD_SUPERPAGE_SPLINTER (TRC_MEM + 18) - -#define TRC_PV_HYPERCALL (TRC_PV + 1) -#define TRC_PV_TRAP (TRC_PV + 3) -#define TRC_PV_PAGE_FAULT (TRC_PV + 4) -#define TRC_PV_FORCED_INVALID_OP (TRC_PV + 5) -#define TRC_PV_EMULATE_PRIVOP (TRC_PV + 6) -#define TRC_PV_EMULATE_4GB (TRC_PV + 7) -#define TRC_PV_MATH_STATE_RESTORE (TRC_PV + 8) -#define TRC_PV_PAGING_FIXUP (TRC_PV + 9) -#define TRC_PV_GDT_LDT_MAPPING_FAULT (TRC_PV + 10) -#define TRC_PV_PTWR_EMULATION (TRC_PV + 11) -#define TRC_PV_PTWR_EMULATION_PAE (TRC_PV + 12) - /* Indicates that addresses in trace record are 64 bits */ -#define TRC_64_FLAG (0x100) +#define TRC_PV_ENTRY 0x00201000 /* Hypervisor entry points for PV guests. */ + +#define TRC_PV_HYPERCALL (TRC_PV_ENTRY + 1) +#define TRC_PV_TRAP (TRC_PV_ENTRY + 3) +#define TRC_PV_PAGE_FAULT (TRC_PV_ENTRY + 4) +#define TRC_PV_FORCED_INVALID_OP (TRC_PV_ENTRY + 5) +#define TRC_PV_EMULATE_PRIVOP (TRC_PV_ENTRY + 6) +#define TRC_PV_EMULATE_4GB (TRC_PV_ENTRY + 7) +#define TRC_PV_MATH_STATE_RESTORE (TRC_PV_ENTRY + 8) +#define TRC_PV_PAGING_FIXUP (TRC_PV_ENTRY + 9) +#define TRC_PV_GDT_LDT_MAPPING_FAULT (TRC_PV_ENTRY + 10) +#define TRC_PV_PTWR_EMULATION (TRC_PV_ENTRY + 11) +#define TRC_PV_PTWR_EMULATION_PAE (TRC_PV_ENTRY + 12) #define TRC_SHADOW_NOT_SHADOW (TRC_SHADOW + 1) #define TRC_SHADOW_FAST_PROPAGATE (TRC_SHADOW + 2) @@ -187,6 +186,14 @@ #define TRC_HW_IRQ_UNMAPPED_VECTOR (TRC_HW_IRQ + 0x7) #define TRC_HW_IRQ_HANDLED (TRC_HW_IRQ + 0x8) +/* + * Event Flags + * + * Some events (e.g, TRC_PV_TRAP and TRC_HVM_IOMEM_READ) have multiple + * record formats. These event flags distinguish between the + * different formats. + */ +#define TRC_64_FLAG 0x100 /* Addresses are 64 bits (instead of 32 bits) */ /* This structure represents a single trace buffer record. */ struct t_rec { -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 17:04:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 17:04:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJSMk-0004mT-7s; Wed, 03 Oct 2012 17:04:10 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJSMi-0004mK-VD for xen-devel@lists.xen.org; Wed, 03 Oct 2012 17:04:09 +0000 Received: from [85.158.137.99:18309] by server-9.bemta-3.messagelabs.com id 69/A6-20338-8007C605; Wed, 03 Oct 2012 17:04:08 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-8.tower-217.messagelabs.com!1349283846!14794548!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzk2MzY=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27888 invoked from network); 3 Oct 2012 17:04:07 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 17:04:07 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="210185670" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 16:46:16 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 12:46:16 -0400 Received: from qabil.uk.xensource.com ([10.80.2.76]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJRs6-0007Eo-M6; Wed, 03 Oct 2012 17:32:30 +0100 From: David Vrabel To: xen-devel@lists.xen.org Date: Wed, 3 Oct 2012 17:32:23 +0100 Message-ID: <1349281947-5009-1-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 hypercalls: some hypercall arguments are added the trace record and MIME-Version: 1.0 Cc: David Vrabel , George Dunlap Subject: [Xen-devel] [PATCHv5 0/4] trace: improve hypercall tracing X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org xenalyze requires some patches to decode the new trace record format, these patches will be posted shortly. Changes since v4: - Rename trace_hypercall() to __trace_hypercall_entry(). - Use an array for the arguments to include in the hypercall trace record. Changes since v3: - Trace arguments for a few more hypercalls (vcpu_op and sched_op). Changes since v2: - Changed all PV events to use a different subclass. - Put multicall subcalls into their own subclass (so they can be filtered out). - Use 12 bits to report which arguments are present in the PV_HYPERCALL_V2 trace record. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 17:04:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 17:04:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJSMk-0004mT-7s; Wed, 03 Oct 2012 17:04:10 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJSMi-0004mK-VD for xen-devel@lists.xen.org; Wed, 03 Oct 2012 17:04:09 +0000 Received: from [85.158.137.99:18309] by server-9.bemta-3.messagelabs.com id 69/A6-20338-8007C605; Wed, 03 Oct 2012 17:04:08 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-8.tower-217.messagelabs.com!1349283846!14794548!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzk2MzY=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27888 invoked from network); 3 Oct 2012 17:04:07 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 17:04:07 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="210185670" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 16:46:16 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 12:46:16 -0400 Received: from qabil.uk.xensource.com ([10.80.2.76]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJRs6-0007Eo-M6; Wed, 03 Oct 2012 17:32:30 +0100 From: David Vrabel To: xen-devel@lists.xen.org Date: Wed, 3 Oct 2012 17:32:23 +0100 Message-ID: <1349281947-5009-1-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 hypercalls: some hypercall arguments are added the trace record and MIME-Version: 1.0 Cc: David Vrabel , George Dunlap Subject: [Xen-devel] [PATCHv5 0/4] trace: improve hypercall tracing X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org xenalyze requires some patches to decode the new trace record format, these patches will be posted shortly. Changes since v4: - Rename trace_hypercall() to __trace_hypercall_entry(). - Use an array for the arguments to include in the hypercall trace record. Changes since v3: - Trace arguments for a few more hypercalls (vcpu_op and sched_op). Changes since v2: - Changed all PV events to use a different subclass. - Put multicall subcalls into their own subclass (so they can be filtered out). - Use 12 bits to report which arguments are present in the PV_HYPERCALL_V2 trace record. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 17:04:30 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 17:04:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJSMl-0004mr-KD; Wed, 03 Oct 2012 17:04:11 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJSMj-0004mP-SB for xen-devel@lists.xen.org; Wed, 03 Oct 2012 17:04:10 +0000 Received: from [85.158.137.99:40290] by server-3.bemta-3.messagelabs.com id 25/74-25962-9007C605; Wed, 03 Oct 2012 17:04:09 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-8.tower-217.messagelabs.com!1349283846!14794548!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzk2MzY=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27963 invoked from network); 3 Oct 2012 17:04:08 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 17:04:08 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="210185663" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 16:46:14 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 12:46:14 -0400 Received: from qabil.uk.xensource.com ([10.80.2.76]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJRs6-0007Eo-Qo; Wed, 03 Oct 2012 17:32:30 +0100 From: David Vrabel To: xen-devel@lists.xen.org Date: Wed, 3 Oct 2012 17:32:27 +0100 Message-ID: <1349281947-5009-5-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1349281947-5009-1-git-send-email-david.vrabel@citrix.com> References: <1349281947-5009-1-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Cc: David Vrabel , George Dunlap Subject: [Xen-devel] [PATCH 4/4] trace: trace hypercalls inside a multicall X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: David Vrabel Add a trace record for every hypercall inside a multicall. These use a new event ID (with a different sub-class ) so they may be filtered out if only the calls into hypervisor are of interest. Signed-off-by: David Vrabel Acked-by: George Dunlap --- tools/xentrace/formats | 1 + tools/xentrace/xentrace_format | 3 ++- xen/arch/x86/trace.c | 2 +- xen/common/compat/multicall.c | 12 ++++++++++++ xen/common/multicall.c | 16 ++++++++++++++++ xen/common/trace.c | 6 +++--- xen/include/public/trace.h | 4 +++- xen/include/xen/trace.h | 3 ++- 8 files changed, 40 insertions(+), 7 deletions(-) diff --git a/tools/xentrace/formats b/tools/xentrace/formats index fa935c8..928e1d7 100644 --- a/tools/xentrace/formats +++ b/tools/xentrace/formats @@ -105,6 +105,7 @@ 0x0020100c CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation_pae [ addr = 0x%(3)08x, eip = 0x%(4)08x, npte = 0x%(2)08x%(1)08x ] 0x0020110c CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation_pae [ addr = 0x%(4)08x%(3)08x, rip = 0x%(6)08x%(5)08x, npte = 0x%(2)08x%(1)08x ] 0x0020100d CPU%(cpu)d %(tsc)d (+%(reltsc)8d) hypercall [ op = 0x%(1)08x ] +0x0020200e CPU%(cpu)d %(tsc)d (+%(reltsc)8d) hypercall [ op = 0x%(1)08x ] 0x0040f001 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) shadow_not_shadow [ gl1e = 0x%(2)08x%(1)08x, va = 0x%(3)08x, flags = 0x%(4)08x ] 0x0040f101 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) shadow_not_shadow [ gl1e = 0x%(2)08x%(1)08x, va = 0x%(4)08x%(3)08x, flags = 0x%(5)08x ] diff --git a/tools/xentrace/xentrace_format b/tools/xentrace/xentrace_format index bdcab09..5ff85ae 100644 --- a/tools/xentrace/xentrace_format +++ b/tools/xentrace/xentrace_format @@ -112,6 +112,7 @@ last_tsc = [0] TRC_TRACE_IRQ = 0x1f004 TRC_PV_HYPERCALL_V2 = 0x20100d +TRC_PV_HYPERCALL_SUBCALL = 0x20100e NR_VECTORS = 256 irq_measure = [{'count':0, 'tot_cycles':0, 'max_cycles':0}] * NR_VECTORS @@ -199,7 +200,7 @@ while not interrupted: d3 = irq_measure[d1]['tot_cycles'] d4 = irq_measure[d1]['max_cycles'] - if event == TRC_PV_HYPERCALL_V2: + if event == TRC_PV_HYPERCALL_V2 or event == TRC_PV_HYPERCALL_SUBCALL: # Mask off the argument present bits. d1 &= 0x000fffff diff --git a/xen/arch/x86/trace.c b/xen/arch/x86/trace.c index 9c43f17..b1804a4 100644 --- a/xen/arch/x86/trace.c +++ b/xen/arch/x86/trace.c @@ -30,7 +30,7 @@ void __trace_hypercall_entry(void) args[5] = regs->r9; } - __trace_hypercall(regs->eax, args); + __trace_hypercall(TRC_PV_HYPERCALL_V2, regs->eax, args); } void __trace_pv_trap(int trapnr, unsigned long eip, diff --git a/xen/common/compat/multicall.c b/xen/common/compat/multicall.c index 0eb1212..e7e2a40 100644 --- a/xen/common/compat/multicall.c +++ b/xen/common/compat/multicall.c @@ -5,6 +5,7 @@ #include #include #include +#include #define COMPAT typedef int ret_t; @@ -25,6 +26,17 @@ DEFINE_XEN_GUEST_HANDLE(multicall_entry_compat_t); #define do_multicall(l, n) compat_multicall(_##l, n) #define _XEN_GUEST_HANDLE(t) XEN_GUEST_HANDLE(t) +static void __trace_multicall_call(multicall_entry_t *call) +{ + unsigned long args[6]; + int i; + + for ( i = 0; i < ARRAY_SIZE(args); i++ ) + args[i] = call->args[i]; + + __trace_hypercall(TRC_PV_HYPERCALL_SUBCALL, call->op, args); +} + #include "../multicall.c" /* diff --git a/xen/common/multicall.c b/xen/common/multicall.c index 6c1a9d7..ca1839d 100644 --- a/xen/common/multicall.c +++ b/xen/common/multicall.c @@ -11,14 +11,28 @@ #include #include #include +#include #include #include #ifndef COMPAT typedef long ret_t; #define xlat_multicall_entry(mcs) + +static void __trace_multicall_call(multicall_entry_t *call) +{ + __trace_hypercall(TRC_PV_HYPERCALL_SUBCALL, call->op, call->args); +} #endif +static void trace_multicall_call(multicall_entry_t *call) +{ + if ( !tb_init_done ) + return; + + __trace_multicall_call(call); +} + ret_t do_multicall( XEN_GUEST_HANDLE(multicall_entry_t) call_list, unsigned int nr_calls) @@ -47,6 +61,8 @@ do_multicall( break; } + trace_multicall_call(&mcs->call); + do_multicall_call(&mcs->call); #ifndef NDEBUG diff --git a/xen/common/trace.c b/xen/common/trace.c index 059020d..097a4f0 100644 --- a/xen/common/trace.c +++ b/xen/common/trace.c @@ -844,7 +844,8 @@ static struct trace_hypercall trace_hypercall_table[] = { #undef ARG32 #undef ARG64 -void __trace_hypercall(unsigned long op, const unsigned long *args) +void __trace_hypercall(uint32_t event, unsigned long op, + const unsigned long *args) { struct { uint32_t op; @@ -882,8 +883,7 @@ void __trace_hypercall(unsigned long op, const unsigned long *args) } } - __trace_var(TRC_PV_HYPERCALL_V2, 1, - sizeof(uint32_t) * (1 + (a - d.args)), &d); + __trace_var(event, 1, sizeof(uint32_t) * (1 + (a - d.args)), &d); } /* diff --git a/xen/include/public/trace.h b/xen/include/public/trace.h index ef43b23..3c93805 100644 --- a/xen/include/public/trace.h +++ b/xen/include/public/trace.h @@ -94,7 +94,8 @@ #define TRC_MEM_POD_ZERO_RECLAIM (TRC_MEM + 17) #define TRC_MEM_POD_SUPERPAGE_SPLINTER (TRC_MEM + 18) -#define TRC_PV_ENTRY 0x00201000 /* Hypervisor entry points for PV guests. */ +#define TRC_PV_ENTRY 0x00201000 /* Hypervisor entry points for PV guests. */ +#define TRC_PV_SUBCALL 0x00202000 /* Sub-call in a multicall hypercall */ #define TRC_PV_HYPERCALL (TRC_PV_ENTRY + 1) #define TRC_PV_TRAP (TRC_PV_ENTRY + 3) @@ -108,6 +109,7 @@ #define TRC_PV_PTWR_EMULATION (TRC_PV_ENTRY + 11) #define TRC_PV_PTWR_EMULATION_PAE (TRC_PV_ENTRY + 12) #define TRC_PV_HYPERCALL_V2 (TRC_PV_ENTRY + 13) +#define TRC_PV_HYPERCALL_SUBCALL (TRC_PV_SUBCALL + 14) /* * TRC_PV_HYPERCALL_V2 format diff --git a/xen/include/xen/trace.h b/xen/include/xen/trace.h index f601aeb..3b8a7b3 100644 --- a/xen/include/xen/trace.h +++ b/xen/include/xen/trace.h @@ -44,7 +44,8 @@ static inline void trace_var(u32 event, int cycles, int extra, __trace_var(event, cycles, extra, extra_data); } -void __trace_hypercall(unsigned long call, const unsigned long *args); +void __trace_hypercall(uint32_t event, unsigned long op, + const unsigned long *args); /* Convenience macros for calling the trace function. */ #define TRACE_0D(_e) \ -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 17:04:30 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 17:04:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJSMl-0004mr-KD; Wed, 03 Oct 2012 17:04:11 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJSMj-0004mP-SB for xen-devel@lists.xen.org; Wed, 03 Oct 2012 17:04:10 +0000 Received: from [85.158.137.99:40290] by server-3.bemta-3.messagelabs.com id 25/74-25962-9007C605; Wed, 03 Oct 2012 17:04:09 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-8.tower-217.messagelabs.com!1349283846!14794548!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzk2MzY=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27963 invoked from network); 3 Oct 2012 17:04:08 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 17:04:08 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="210185663" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 16:46:14 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 12:46:14 -0400 Received: from qabil.uk.xensource.com ([10.80.2.76]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJRs6-0007Eo-Qo; Wed, 03 Oct 2012 17:32:30 +0100 From: David Vrabel To: xen-devel@lists.xen.org Date: Wed, 3 Oct 2012 17:32:27 +0100 Message-ID: <1349281947-5009-5-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1349281947-5009-1-git-send-email-david.vrabel@citrix.com> References: <1349281947-5009-1-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Cc: David Vrabel , George Dunlap Subject: [Xen-devel] [PATCH 4/4] trace: trace hypercalls inside a multicall X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: David Vrabel Add a trace record for every hypercall inside a multicall. These use a new event ID (with a different sub-class ) so they may be filtered out if only the calls into hypervisor are of interest. Signed-off-by: David Vrabel Acked-by: George Dunlap --- tools/xentrace/formats | 1 + tools/xentrace/xentrace_format | 3 ++- xen/arch/x86/trace.c | 2 +- xen/common/compat/multicall.c | 12 ++++++++++++ xen/common/multicall.c | 16 ++++++++++++++++ xen/common/trace.c | 6 +++--- xen/include/public/trace.h | 4 +++- xen/include/xen/trace.h | 3 ++- 8 files changed, 40 insertions(+), 7 deletions(-) diff --git a/tools/xentrace/formats b/tools/xentrace/formats index fa935c8..928e1d7 100644 --- a/tools/xentrace/formats +++ b/tools/xentrace/formats @@ -105,6 +105,7 @@ 0x0020100c CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation_pae [ addr = 0x%(3)08x, eip = 0x%(4)08x, npte = 0x%(2)08x%(1)08x ] 0x0020110c CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation_pae [ addr = 0x%(4)08x%(3)08x, rip = 0x%(6)08x%(5)08x, npte = 0x%(2)08x%(1)08x ] 0x0020100d CPU%(cpu)d %(tsc)d (+%(reltsc)8d) hypercall [ op = 0x%(1)08x ] +0x0020200e CPU%(cpu)d %(tsc)d (+%(reltsc)8d) hypercall [ op = 0x%(1)08x ] 0x0040f001 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) shadow_not_shadow [ gl1e = 0x%(2)08x%(1)08x, va = 0x%(3)08x, flags = 0x%(4)08x ] 0x0040f101 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) shadow_not_shadow [ gl1e = 0x%(2)08x%(1)08x, va = 0x%(4)08x%(3)08x, flags = 0x%(5)08x ] diff --git a/tools/xentrace/xentrace_format b/tools/xentrace/xentrace_format index bdcab09..5ff85ae 100644 --- a/tools/xentrace/xentrace_format +++ b/tools/xentrace/xentrace_format @@ -112,6 +112,7 @@ last_tsc = [0] TRC_TRACE_IRQ = 0x1f004 TRC_PV_HYPERCALL_V2 = 0x20100d +TRC_PV_HYPERCALL_SUBCALL = 0x20100e NR_VECTORS = 256 irq_measure = [{'count':0, 'tot_cycles':0, 'max_cycles':0}] * NR_VECTORS @@ -199,7 +200,7 @@ while not interrupted: d3 = irq_measure[d1]['tot_cycles'] d4 = irq_measure[d1]['max_cycles'] - if event == TRC_PV_HYPERCALL_V2: + if event == TRC_PV_HYPERCALL_V2 or event == TRC_PV_HYPERCALL_SUBCALL: # Mask off the argument present bits. d1 &= 0x000fffff diff --git a/xen/arch/x86/trace.c b/xen/arch/x86/trace.c index 9c43f17..b1804a4 100644 --- a/xen/arch/x86/trace.c +++ b/xen/arch/x86/trace.c @@ -30,7 +30,7 @@ void __trace_hypercall_entry(void) args[5] = regs->r9; } - __trace_hypercall(regs->eax, args); + __trace_hypercall(TRC_PV_HYPERCALL_V2, regs->eax, args); } void __trace_pv_trap(int trapnr, unsigned long eip, diff --git a/xen/common/compat/multicall.c b/xen/common/compat/multicall.c index 0eb1212..e7e2a40 100644 --- a/xen/common/compat/multicall.c +++ b/xen/common/compat/multicall.c @@ -5,6 +5,7 @@ #include #include #include +#include #define COMPAT typedef int ret_t; @@ -25,6 +26,17 @@ DEFINE_XEN_GUEST_HANDLE(multicall_entry_compat_t); #define do_multicall(l, n) compat_multicall(_##l, n) #define _XEN_GUEST_HANDLE(t) XEN_GUEST_HANDLE(t) +static void __trace_multicall_call(multicall_entry_t *call) +{ + unsigned long args[6]; + int i; + + for ( i = 0; i < ARRAY_SIZE(args); i++ ) + args[i] = call->args[i]; + + __trace_hypercall(TRC_PV_HYPERCALL_SUBCALL, call->op, args); +} + #include "../multicall.c" /* diff --git a/xen/common/multicall.c b/xen/common/multicall.c index 6c1a9d7..ca1839d 100644 --- a/xen/common/multicall.c +++ b/xen/common/multicall.c @@ -11,14 +11,28 @@ #include #include #include +#include #include #include #ifndef COMPAT typedef long ret_t; #define xlat_multicall_entry(mcs) + +static void __trace_multicall_call(multicall_entry_t *call) +{ + __trace_hypercall(TRC_PV_HYPERCALL_SUBCALL, call->op, call->args); +} #endif +static void trace_multicall_call(multicall_entry_t *call) +{ + if ( !tb_init_done ) + return; + + __trace_multicall_call(call); +} + ret_t do_multicall( XEN_GUEST_HANDLE(multicall_entry_t) call_list, unsigned int nr_calls) @@ -47,6 +61,8 @@ do_multicall( break; } + trace_multicall_call(&mcs->call); + do_multicall_call(&mcs->call); #ifndef NDEBUG diff --git a/xen/common/trace.c b/xen/common/trace.c index 059020d..097a4f0 100644 --- a/xen/common/trace.c +++ b/xen/common/trace.c @@ -844,7 +844,8 @@ static struct trace_hypercall trace_hypercall_table[] = { #undef ARG32 #undef ARG64 -void __trace_hypercall(unsigned long op, const unsigned long *args) +void __trace_hypercall(uint32_t event, unsigned long op, + const unsigned long *args) { struct { uint32_t op; @@ -882,8 +883,7 @@ void __trace_hypercall(unsigned long op, const unsigned long *args) } } - __trace_var(TRC_PV_HYPERCALL_V2, 1, - sizeof(uint32_t) * (1 + (a - d.args)), &d); + __trace_var(event, 1, sizeof(uint32_t) * (1 + (a - d.args)), &d); } /* diff --git a/xen/include/public/trace.h b/xen/include/public/trace.h index ef43b23..3c93805 100644 --- a/xen/include/public/trace.h +++ b/xen/include/public/trace.h @@ -94,7 +94,8 @@ #define TRC_MEM_POD_ZERO_RECLAIM (TRC_MEM + 17) #define TRC_MEM_POD_SUPERPAGE_SPLINTER (TRC_MEM + 18) -#define TRC_PV_ENTRY 0x00201000 /* Hypervisor entry points for PV guests. */ +#define TRC_PV_ENTRY 0x00201000 /* Hypervisor entry points for PV guests. */ +#define TRC_PV_SUBCALL 0x00202000 /* Sub-call in a multicall hypercall */ #define TRC_PV_HYPERCALL (TRC_PV_ENTRY + 1) #define TRC_PV_TRAP (TRC_PV_ENTRY + 3) @@ -108,6 +109,7 @@ #define TRC_PV_PTWR_EMULATION (TRC_PV_ENTRY + 11) #define TRC_PV_PTWR_EMULATION_PAE (TRC_PV_ENTRY + 12) #define TRC_PV_HYPERCALL_V2 (TRC_PV_ENTRY + 13) +#define TRC_PV_HYPERCALL_SUBCALL (TRC_PV_SUBCALL + 14) /* * TRC_PV_HYPERCALL_V2 format diff --git a/xen/include/xen/trace.h b/xen/include/xen/trace.h index f601aeb..3b8a7b3 100644 --- a/xen/include/xen/trace.h +++ b/xen/include/xen/trace.h @@ -44,7 +44,8 @@ static inline void trace_var(u32 event, int cycles, int extra, __trace_var(event, cycles, extra, extra_data); } -void __trace_hypercall(unsigned long call, const unsigned long *args); +void __trace_hypercall(uint32_t event, unsigned long op, + const unsigned long *args); /* Convenience macros for calling the trace function. */ #define TRACE_0D(_e) \ -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 17:08:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 17:08:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJSQR-0005Ec-RK; Wed, 03 Oct 2012 17:07:59 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJSQQ-0005EU-V3 for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 17:07:59 +0000 Received: from [85.158.139.211:50729] by server-3.bemta-5.messagelabs.com id 44/DF-16108-EE07C605; Wed, 03 Oct 2012 17:07:58 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-3.tower-206.messagelabs.com!1349284077!20935670!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20152 invoked from network); 3 Oct 2012 17:07:57 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 17:07:57 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="14921858" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 17:07:56 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 18:07:56 +0100 Date: Wed, 3 Oct 2012 18:06:56 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Ian Campbell In-Reply-To: <1349282492.650.185.camel@zakaz.uk.xensource.com> Message-ID: References: <1349272182.650.150.camel@zakaz.uk.xensource.com> <1349272482.650.151.camel@zakaz.uk.xensource.com> <20121003141116.GA10633@phenom.dumpdata.com> <1349276431.650.156.camel@zakaz.uk.xensource.com> <1349279862.650.171.camel@zakaz.uk.xensource.com> <1349280814.650.178.camel@zakaz.uk.xensource.com> <1349282492.650.185.camel@zakaz.uk.xensource.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , Konrad Rzeszutek Wilk , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH] xen: point xen_start_info to a dummy struct for PV on HVM guests X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 3 Oct 2012, Ian Campbell wrote: > On Wed, 2012-10-03 at 17:13 +0100, Ian Campbell wrote: > > On Wed, 2012-10-03 at 17:05 +0100, Stefano Stabellini wrote: > > > On Wed, 3 Oct 2012, Ian Campbell wrote: > > > > On Wed, 2012-10-03 at 16:48 +0100, Stefano Stabellini wrote: > > > > > On Wed, 3 Oct 2012, Ian Campbell wrote: > > > > > > On Wed, 2012-10-03 at 15:11 +0100, Konrad Rzeszutek Wilk wrote: > > > > > > > On Wed, Oct 03, 2012 at 02:54:42PM +0100, Ian Campbell wrote: > > > > > > > > On Wed, 2012-10-03 at 14:51 +0100, Stefano Stabellini wrote: > > > > > > > > > On Wed, 3 Oct 2012, Ian Campbell wrote: > > > > > > > > > > On Wed, 2012-10-03 at 14:37 +0100, Stefano Stabellini wrote: > > > > > > > > > > > PV on HVM guests don't have a start_info page mapped by Xen, so > > > > > > > > > > > xen_start_info is just NULL for them. > > > > > > > > > > > That is problem because other parts of the code expect xen_start_info to > > > > > > > > > > > point to something valid, for example xen_initial_domain() is defined as > > > > > > > > > > > follow: > > > > > > > > > > > > > > > > > > > > > > #define xen_initial_domain() (xen_domain() && \ > > > > > > > > > > > xen_start_info->flags & SIF_INITDOMAIN) > > > > > > > > > > > > > > > > > > > > But anyone who calls this before xen_start_info is setup is going to get > > > > > > > > > > a bogus result, specifically in this case they will think they are domU > > > > > > > > > > when in reality they are dom0 -- wouldn't it be better to fix those > > > > > > > > > > callsites? > > > > > > > > > > > > > > > > > > That cannot be the case because setting up xen_start_info is the very > > > > > > > > > first thing that is done, before even calling to C. > > > > > > > > > > > > > > > > On PV, yes, but you are trying to fix PVHVM here, no? > > > > > > > > > > > > > > > > Otherwise if this is always set before calling into C then what is the > > > > > > > > purpose of this patch? > > > > > > > > > > > > > > to fix this - as PVHVM has it set to NULL and we end up de-referencing > > > > > > > the xen_start_info and crashing. As so:: > > > > > > > > > > > > > > > > > > > Right, so returning to my original point: The caller here is calling > > > > > > xen_initial_domain() *before* start info is setup. This is bogus and is > > > > > > your actual bug, all this patch does is hide that real issue. > > > > > > > > > > That is because xen_start_info wasn't setup at all for PV on HVM guests. > > > > > > > > > > The real reason is that PV on HVM guests don't have one, but that is > > > > > another matter. Until we get rid of all the references to xen_start_info > > > > > outside of PV specific code, we should just assume that there is one, > > > > > and that is already setup. > > > > > > > > > > One day not too far from now, we might refactor the code to never > > > > > reference xen_start_info directly, but I don't think that now is the > > > > > time for that. Also consider that this is the same thing we do on ARM. > > > > > > > > We actual fill in the dummy start info with valid information on ARM > > > > though, we don't just leave it full of zeroes. > > > > > > > > If we do start out with start_info pointing to an uninitialised > > > > start_info on ARM too then I would argue that this is also a mistake. > > > > > > Yes, we do point xen_start_info to an uninitialised start_info on ARM > > > too (I don't think is a mistake). Then when and if we have more > > > information we write them to start_info. > > > > So callers of xen_initial_domain in dom0 before xen_guest_init is called > > get the wrong result? > > > > That sounds like a mistake to me. > > How about (modulo my not having looked up the actual names of the > constants etc): > > #define xen_initial_domain() (xen_domain() && arch_is_initial_domain()) > > on x86: > int arch_is_initial_domain(void) > { > /* The initial domain is always PV and > * therefore start_info is always set for it. > */ > return start_info && start_info->flags & SIF_INITDOMAIN; > } > on ARM: > int arch_is_initial_domain(void) > { > static is_initial = -1; > if (is_initial == -1) > is_initial = HVM_param_get(HVMPARAM_DOM0) > return is_initial; > } What about the appended patch as a fix for the moment, then we can do the refactoring that you are suggesting, that is very similar to what I had in mind when I said that we shouldn't access xen_start_info directly. --- xen/xen_initial_domain: check that xen_start_info is initialized Since commit commit 4c071ee5268f7234c3d084b6093bebccc28cdcba ("arm: initial Xen support") PV on HVM guests can be xen_initial_domain. However PV on HVM guests might have an unitialized xen_start_info, so check before accessing its fields. Signed-off-by: Stefano Stabellini Reported-by: Konrad Rzeszutek Wilk diff --git a/include/xen/xen.h b/include/xen/xen.h index 9a39ca5..e7101bb 100644 --- a/include/xen/xen.h +++ b/include/xen/xen.h @@ -28,7 +28,7 @@ extern enum xen_domain_type xen_domain_type; #include #define xen_initial_domain() (xen_domain() && \ - xen_start_info->flags & SIF_INITDOMAIN) + xen_start_info && xen_start_info->flags & SIF_INITDOMAIN) #else /* !CONFIG_XEN_DOM0 */ #define xen_initial_domain() (0) #endif /* CONFIG_XEN_DOM0 */ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 17:08:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 17:08:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJSQR-0005Ec-RK; Wed, 03 Oct 2012 17:07:59 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJSQQ-0005EU-V3 for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 17:07:59 +0000 Received: from [85.158.139.211:50729] by server-3.bemta-5.messagelabs.com id 44/DF-16108-EE07C605; Wed, 03 Oct 2012 17:07:58 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-3.tower-206.messagelabs.com!1349284077!20935670!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20152 invoked from network); 3 Oct 2012 17:07:57 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 17:07:57 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="14921858" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 17:07:56 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 18:07:56 +0100 Date: Wed, 3 Oct 2012 18:06:56 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Ian Campbell In-Reply-To: <1349282492.650.185.camel@zakaz.uk.xensource.com> Message-ID: References: <1349272182.650.150.camel@zakaz.uk.xensource.com> <1349272482.650.151.camel@zakaz.uk.xensource.com> <20121003141116.GA10633@phenom.dumpdata.com> <1349276431.650.156.camel@zakaz.uk.xensource.com> <1349279862.650.171.camel@zakaz.uk.xensource.com> <1349280814.650.178.camel@zakaz.uk.xensource.com> <1349282492.650.185.camel@zakaz.uk.xensource.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , Konrad Rzeszutek Wilk , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH] xen: point xen_start_info to a dummy struct for PV on HVM guests X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 3 Oct 2012, Ian Campbell wrote: > On Wed, 2012-10-03 at 17:13 +0100, Ian Campbell wrote: > > On Wed, 2012-10-03 at 17:05 +0100, Stefano Stabellini wrote: > > > On Wed, 3 Oct 2012, Ian Campbell wrote: > > > > On Wed, 2012-10-03 at 16:48 +0100, Stefano Stabellini wrote: > > > > > On Wed, 3 Oct 2012, Ian Campbell wrote: > > > > > > On Wed, 2012-10-03 at 15:11 +0100, Konrad Rzeszutek Wilk wrote: > > > > > > > On Wed, Oct 03, 2012 at 02:54:42PM +0100, Ian Campbell wrote: > > > > > > > > On Wed, 2012-10-03 at 14:51 +0100, Stefano Stabellini wrote: > > > > > > > > > On Wed, 3 Oct 2012, Ian Campbell wrote: > > > > > > > > > > On Wed, 2012-10-03 at 14:37 +0100, Stefano Stabellini wrote: > > > > > > > > > > > PV on HVM guests don't have a start_info page mapped by Xen, so > > > > > > > > > > > xen_start_info is just NULL for them. > > > > > > > > > > > That is problem because other parts of the code expect xen_start_info to > > > > > > > > > > > point to something valid, for example xen_initial_domain() is defined as > > > > > > > > > > > follow: > > > > > > > > > > > > > > > > > > > > > > #define xen_initial_domain() (xen_domain() && \ > > > > > > > > > > > xen_start_info->flags & SIF_INITDOMAIN) > > > > > > > > > > > > > > > > > > > > But anyone who calls this before xen_start_info is setup is going to get > > > > > > > > > > a bogus result, specifically in this case they will think they are domU > > > > > > > > > > when in reality they are dom0 -- wouldn't it be better to fix those > > > > > > > > > > callsites? > > > > > > > > > > > > > > > > > > That cannot be the case because setting up xen_start_info is the very > > > > > > > > > first thing that is done, before even calling to C. > > > > > > > > > > > > > > > > On PV, yes, but you are trying to fix PVHVM here, no? > > > > > > > > > > > > > > > > Otherwise if this is always set before calling into C then what is the > > > > > > > > purpose of this patch? > > > > > > > > > > > > > > to fix this - as PVHVM has it set to NULL and we end up de-referencing > > > > > > > the xen_start_info and crashing. As so:: > > > > > > > > > > > > > > > > > > > Right, so returning to my original point: The caller here is calling > > > > > > xen_initial_domain() *before* start info is setup. This is bogus and is > > > > > > your actual bug, all this patch does is hide that real issue. > > > > > > > > > > That is because xen_start_info wasn't setup at all for PV on HVM guests. > > > > > > > > > > The real reason is that PV on HVM guests don't have one, but that is > > > > > another matter. Until we get rid of all the references to xen_start_info > > > > > outside of PV specific code, we should just assume that there is one, > > > > > and that is already setup. > > > > > > > > > > One day not too far from now, we might refactor the code to never > > > > > reference xen_start_info directly, but I don't think that now is the > > > > > time for that. Also consider that this is the same thing we do on ARM. > > > > > > > > We actual fill in the dummy start info with valid information on ARM > > > > though, we don't just leave it full of zeroes. > > > > > > > > If we do start out with start_info pointing to an uninitialised > > > > start_info on ARM too then I would argue that this is also a mistake. > > > > > > Yes, we do point xen_start_info to an uninitialised start_info on ARM > > > too (I don't think is a mistake). Then when and if we have more > > > information we write them to start_info. > > > > So callers of xen_initial_domain in dom0 before xen_guest_init is called > > get the wrong result? > > > > That sounds like a mistake to me. > > How about (modulo my not having looked up the actual names of the > constants etc): > > #define xen_initial_domain() (xen_domain() && arch_is_initial_domain()) > > on x86: > int arch_is_initial_domain(void) > { > /* The initial domain is always PV and > * therefore start_info is always set for it. > */ > return start_info && start_info->flags & SIF_INITDOMAIN; > } > on ARM: > int arch_is_initial_domain(void) > { > static is_initial = -1; > if (is_initial == -1) > is_initial = HVM_param_get(HVMPARAM_DOM0) > return is_initial; > } What about the appended patch as a fix for the moment, then we can do the refactoring that you are suggesting, that is very similar to what I had in mind when I said that we shouldn't access xen_start_info directly. --- xen/xen_initial_domain: check that xen_start_info is initialized Since commit commit 4c071ee5268f7234c3d084b6093bebccc28cdcba ("arm: initial Xen support") PV on HVM guests can be xen_initial_domain. However PV on HVM guests might have an unitialized xen_start_info, so check before accessing its fields. Signed-off-by: Stefano Stabellini Reported-by: Konrad Rzeszutek Wilk diff --git a/include/xen/xen.h b/include/xen/xen.h index 9a39ca5..e7101bb 100644 --- a/include/xen/xen.h +++ b/include/xen/xen.h @@ -28,7 +28,7 @@ extern enum xen_domain_type xen_domain_type; #include #define xen_initial_domain() (xen_domain() && \ - xen_start_info->flags & SIF_INITDOMAIN) + xen_start_info && xen_start_info->flags & SIF_INITDOMAIN) #else /* !CONFIG_XEN_DOM0 */ #define xen_initial_domain() (0) #endif /* CONFIG_XEN_DOM0 */ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 17:09:37 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 17:09:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJSRp-0005SF-Lq; Wed, 03 Oct 2012 17:09:25 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJSRo-0005Re-Bd for xen-devel@lists.xen.org; Wed, 03 Oct 2012 17:09:24 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1349284156!11371802!2 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzM2MzM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18109 invoked from network); 3 Oct 2012 17:09:18 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 17:09:18 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="40028525" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 16:46:16 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 12:46:15 -0400 Received: from qabil.uk.xensource.com ([10.80.2.76]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJRs6-0007Eo-Nn; Wed, 03 Oct 2012 17:32:30 +0100 From: David Vrabel To: xen-devel@lists.xen.org Date: Wed, 3 Oct 2012 17:32:24 +0100 Message-ID: <1349281947-5009-2-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1349281947-5009-1-git-send-email-david.vrabel@citrix.com> References: <1349281947-5009-1-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Cc: David Vrabel , George Dunlap Subject: [Xen-devel] [PATCH 1/4] trace: rename trace_hypercall() to __trace_hypercall_entry() X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: David Vrabel Tracing functions that don't check tb_init_done are (by convention) prefixed with __. Signed-off-by: David Vrabel --- xen/arch/x86/trace.c | 2 +- xen/arch/x86/x86_64/compat/entry.S | 4 ++-- xen/arch/x86/x86_64/entry.S | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/xen/arch/x86/trace.c b/xen/arch/x86/trace.c index 27fe150..da4e974 100644 --- a/xen/arch/x86/trace.c +++ b/xen/arch/x86/trace.c @@ -6,7 +6,7 @@ #include #include -void trace_hypercall(void) +void __trace_hypercall_entry(void) { struct cpu_user_regs *regs = guest_cpu_user_regs(); diff --git a/xen/arch/x86/x86_64/compat/entry.S b/xen/arch/x86/x86_64/compat/entry.S index 2f606ab..e6b52f3 100644 --- a/xen/arch/x86/x86_64/compat/entry.S +++ b/xen/arch/x86/x86_64/compat/entry.S @@ -59,8 +59,8 @@ UNLIKELY_END(msi_check) #endif cmpb $0,tb_init_done(%rip) UNLIKELY_START(ne, compat_trace) - call trace_hypercall - /* Now restore all the registers that trace_hypercall clobbered */ + call __trace_hypercall_entry + /* Restore the registers that __trace_hypercall_entry clobbered. */ movl UREGS_rax+SHADOW_BYTES(%rsp),%eax /* Hypercall # */ movl UREGS_rbx+SHADOW_BYTES(%rsp),%edi /* Arg 1 */ movl UREGS_rcx+SHADOW_BYTES(%rsp),%esi /* Arg 2 */ diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S index 74a4075..ffb9314 100644 --- a/xen/arch/x86/x86_64/entry.S +++ b/xen/arch/x86/x86_64/entry.S @@ -159,8 +159,8 @@ ENTRY(syscall_enter) #endif cmpb $0,tb_init_done(%rip) UNLIKELY_START(ne, trace) - call trace_hypercall - /* Now restore all the registers that trace_hypercall clobbered */ + call __trace_hypercall_entry + /* Restore the registers that __trace_hypercall_entry clobbered. */ movq UREGS_rax+SHADOW_BYTES(%rsp),%rax /* Hypercall # */ movq UREGS_rdi+SHADOW_BYTES(%rsp),%rdi /* Arg 1 */ movq UREGS_rsi+SHADOW_BYTES(%rsp),%rsi /* Arg 2 */ -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 17:09:37 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 17:09:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJSRp-0005SF-Lq; Wed, 03 Oct 2012 17:09:25 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJSRo-0005Re-Bd for xen-devel@lists.xen.org; Wed, 03 Oct 2012 17:09:24 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1349284156!11371802!2 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzM2MzM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18109 invoked from network); 3 Oct 2012 17:09:18 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 17:09:18 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="40028525" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 16:46:16 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 12:46:15 -0400 Received: from qabil.uk.xensource.com ([10.80.2.76]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJRs6-0007Eo-Nn; Wed, 03 Oct 2012 17:32:30 +0100 From: David Vrabel To: xen-devel@lists.xen.org Date: Wed, 3 Oct 2012 17:32:24 +0100 Message-ID: <1349281947-5009-2-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1349281947-5009-1-git-send-email-david.vrabel@citrix.com> References: <1349281947-5009-1-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Cc: David Vrabel , George Dunlap Subject: [Xen-devel] [PATCH 1/4] trace: rename trace_hypercall() to __trace_hypercall_entry() X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: David Vrabel Tracing functions that don't check tb_init_done are (by convention) prefixed with __. Signed-off-by: David Vrabel --- xen/arch/x86/trace.c | 2 +- xen/arch/x86/x86_64/compat/entry.S | 4 ++-- xen/arch/x86/x86_64/entry.S | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/xen/arch/x86/trace.c b/xen/arch/x86/trace.c index 27fe150..da4e974 100644 --- a/xen/arch/x86/trace.c +++ b/xen/arch/x86/trace.c @@ -6,7 +6,7 @@ #include #include -void trace_hypercall(void) +void __trace_hypercall_entry(void) { struct cpu_user_regs *regs = guest_cpu_user_regs(); diff --git a/xen/arch/x86/x86_64/compat/entry.S b/xen/arch/x86/x86_64/compat/entry.S index 2f606ab..e6b52f3 100644 --- a/xen/arch/x86/x86_64/compat/entry.S +++ b/xen/arch/x86/x86_64/compat/entry.S @@ -59,8 +59,8 @@ UNLIKELY_END(msi_check) #endif cmpb $0,tb_init_done(%rip) UNLIKELY_START(ne, compat_trace) - call trace_hypercall - /* Now restore all the registers that trace_hypercall clobbered */ + call __trace_hypercall_entry + /* Restore the registers that __trace_hypercall_entry clobbered. */ movl UREGS_rax+SHADOW_BYTES(%rsp),%eax /* Hypercall # */ movl UREGS_rbx+SHADOW_BYTES(%rsp),%edi /* Arg 1 */ movl UREGS_rcx+SHADOW_BYTES(%rsp),%esi /* Arg 2 */ diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S index 74a4075..ffb9314 100644 --- a/xen/arch/x86/x86_64/entry.S +++ b/xen/arch/x86/x86_64/entry.S @@ -159,8 +159,8 @@ ENTRY(syscall_enter) #endif cmpb $0,tb_init_done(%rip) UNLIKELY_START(ne, trace) - call trace_hypercall - /* Now restore all the registers that trace_hypercall clobbered */ + call __trace_hypercall_entry + /* Restore the registers that __trace_hypercall_entry clobbered. */ movq UREGS_rax+SHADOW_BYTES(%rsp),%rax /* Hypercall # */ movq UREGS_rdi+SHADOW_BYTES(%rsp),%rdi /* Arg 1 */ movq UREGS_rsi+SHADOW_BYTES(%rsp),%rsi /* Arg 2 */ -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 17:09:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 17:09:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJSRp-0005S7-AS; Wed, 03 Oct 2012 17:09:25 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJSRn-0005Rc-LS for xen-devel@lists.xen.org; Wed, 03 Oct 2012 17:09:23 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1349284156!11371802!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzM2MzM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18095 invoked from network); 3 Oct 2012 17:09:17 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 17:09:17 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="40028524" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 16:46:15 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 12:46:14 -0400 Received: from qabil.uk.xensource.com ([10.80.2.76]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJRs6-0007Eo-Ox; Wed, 03 Oct 2012 17:32:30 +0100 From: David Vrabel To: xen-devel@lists.xen.org Date: Wed, 3 Oct 2012 17:32:26 +0100 Message-ID: <1349281947-5009-4-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1349281947-5009-1-git-send-email-david.vrabel@citrix.com> References: <1349281947-5009-1-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Cc: David Vrabel , George Dunlap Subject: [Xen-devel] [PATCH 3/4] trace: improve usefulness of hypercall trace record X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: David Vrabel Trace hypercalls using a more useful trace record format. The EIP field is removed (it was always somewhere in the hypercall page) and include selected hypercall arguments (e.g., the number of calls in a multicall, and the number of PTE updates in an mmu_update etc.). 12 bits in the first extra word are used to indicate which arguments are present in the record and what size they are (32 or 64-bit). This is an incompatible record format so a new event ID is used so tools can distinguish between the two formats. Signed-off-by: David Vrabel --- tools/xentrace/formats | 1 + tools/xentrace/xentrace_format | 6 +++ xen/arch/x86/trace.c | 35 ++++++++----------- xen/common/trace.c | 70 ++++++++++++++++++++++++++++++++++++++++ xen/include/public/trace.h | 30 +++++++++++++++++ xen/include/xen/trace.h | 2 + 6 files changed, 124 insertions(+), 20 deletions(-) diff --git a/tools/xentrace/formats b/tools/xentrace/formats index 71220c0..fa935c8 100644 --- a/tools/xentrace/formats +++ b/tools/xentrace/formats @@ -104,6 +104,7 @@ 0x0020110b CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation [ addr = 0x%(4)08x%(3)08x, rip = 0x%(6)08x%(5)08x, npte = 0x%(2)08x%(1)08x ] 0x0020100c CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation_pae [ addr = 0x%(3)08x, eip = 0x%(4)08x, npte = 0x%(2)08x%(1)08x ] 0x0020110c CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation_pae [ addr = 0x%(4)08x%(3)08x, rip = 0x%(6)08x%(5)08x, npte = 0x%(2)08x%(1)08x ] +0x0020100d CPU%(cpu)d %(tsc)d (+%(reltsc)8d) hypercall [ op = 0x%(1)08x ] 0x0040f001 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) shadow_not_shadow [ gl1e = 0x%(2)08x%(1)08x, va = 0x%(3)08x, flags = 0x%(4)08x ] 0x0040f101 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) shadow_not_shadow [ gl1e = 0x%(2)08x%(1)08x, va = 0x%(4)08x%(3)08x, flags = 0x%(5)08x ] diff --git a/tools/xentrace/xentrace_format b/tools/xentrace/xentrace_format index e13b05b..bdcab09 100644 --- a/tools/xentrace/xentrace_format +++ b/tools/xentrace/xentrace_format @@ -111,6 +111,8 @@ D7REC = "IIIIIII" last_tsc = [0] TRC_TRACE_IRQ = 0x1f004 +TRC_PV_HYPERCALL_V2 = 0x20100d + NR_VECTORS = 256 irq_measure = [{'count':0, 'tot_cycles':0, 'max_cycles':0}] * NR_VECTORS @@ -197,6 +199,10 @@ while not interrupted: d3 = irq_measure[d1]['tot_cycles'] d4 = irq_measure[d1]['max_cycles'] + if event == TRC_PV_HYPERCALL_V2: + # Mask off the argument present bits. + d1 &= 0x000fffff + #tsc = (tscH<<32) | tscL #print i, tsc diff --git a/xen/arch/x86/trace.c b/xen/arch/x86/trace.c index da4e974..9c43f17 100644 --- a/xen/arch/x86/trace.c +++ b/xen/arch/x86/trace.c @@ -9,33 +9,28 @@ void __trace_hypercall_entry(void) { struct cpu_user_regs *regs = guest_cpu_user_regs(); + unsigned long args[6]; if ( is_pv_32on64_vcpu(current) ) { - struct { - u32 eip,eax; - } __attribute__((packed)) d; - - d.eip = regs->eip; - d.eax = regs->eax; - - __trace_var(TRC_PV_HYPERCALL, 1, sizeof(d), &d); + args[0] = regs->ebx; + args[1] = regs->ecx; + args[2] = regs->edx; + args[3] = regs->esi; + args[4] = regs->edi; + args[5] = regs->ebp; } else { - struct { - unsigned long eip; - u32 eax; - } __attribute__((packed)) d; - u32 event; - - event = TRC_PV_HYPERCALL; - event |= TRC_64_FLAG; - d.eip = regs->eip; - d.eax = regs->eax; - - __trace_var(event, 1/*tsc*/, sizeof(d), &d); + args[0] = regs->rdi; + args[1] = regs->rsi; + args[2] = regs->rdx; + args[3] = regs->r10; + args[4] = regs->r8; + args[5] = regs->r9; } + + __trace_hypercall(regs->eax, args); } void __trace_pv_trap(int trapnr, unsigned long eip, diff --git a/xen/common/trace.c b/xen/common/trace.c index cacaeb2..059020d 100644 --- a/xen/common/trace.c +++ b/xen/common/trace.c @@ -816,6 +816,76 @@ unlock: tasklet_schedule(&trace_notify_dom0_tasklet); } +struct trace_hypercall { + struct trace_arg { + uint8_t words; + uint8_t idx; + } args[6]; +}; + +#define ARG32(i) { .words = 1, .idx = (i) } +#define ARG64(i) { .words = 2, .idx = (i) } + +/* + * Table of hypercall arguments to be added to the PV_HYPERCALL_V2 + * trace record. + * + * Guest pointers are usually omitted. + */ +static struct trace_hypercall trace_hypercall_table[] = { + [__HYPERVISOR_mmu_update] = {{ ARG32(1) }}, /* count */ + [__HYPERVISOR_multicall] = {{ ARG32(1) }}, /* count */ + [__HYPERVISOR_grant_table_op] = {{ ARG32(0), ARG32(2) }}, /* cmd, count */ + [__HYPERVISOR_vcpu_op] = {{ ARG32(0), ARG32(1) }}, /* cmd, vcpuid */ + [__HYPERVISOR_mmuext_op] = {{ ARG32(1) }}, /* count */ + [__HYPERVISOR_sched_op] = {{ ARG32(0) }}, /* cmd */ +}; + +#undef ARG32 +#undef ARG64 + +void __trace_hypercall(unsigned long op, const unsigned long *args) +{ + struct { + uint32_t op; + uint32_t args[6]; + } __attribute__((packed)) d; + uint32_t *a = d.args; + + /* + * This shouldn't happen as @op should be small enough but just in + * case, warn if the argument bits in the trace record would + * clobber the hypercall op. + */ + WARN_ON(op & TRC_PV_HYPERCALL_V2_ARG_MASK); + + d.op = op; + + if ( op < ARRAY_SIZE(trace_hypercall_table) ) + { + struct trace_arg *i; + + for ( i = trace_hypercall_table[op].args; i->words; i++ ) + { + switch (i->words) + { + case 1: + *a++ = args[i->idx]; + d.op |= TRC_PV_HYPERCALL_V2_ARG_32(i->idx); + break; + case 2: + *a++ = args[i->idx]; + *a++ = args[i->idx] >> 32; + d.op |= TRC_PV_HYPERCALL_V2_ARG_64(i->idx); + break; + } + } + } + + __trace_var(TRC_PV_HYPERCALL_V2, 1, + sizeof(uint32_t) * (1 + (a - d.args)), &d); +} + /* * Local variables: * mode: C diff --git a/xen/include/public/trace.h b/xen/include/public/trace.h index 1f154bb..ef43b23 100644 --- a/xen/include/public/trace.h +++ b/xen/include/public/trace.h @@ -107,6 +107,36 @@ #define TRC_PV_GDT_LDT_MAPPING_FAULT (TRC_PV_ENTRY + 10) #define TRC_PV_PTWR_EMULATION (TRC_PV_ENTRY + 11) #define TRC_PV_PTWR_EMULATION_PAE (TRC_PV_ENTRY + 12) +#define TRC_PV_HYPERCALL_V2 (TRC_PV_ENTRY + 13) + +/* + * TRC_PV_HYPERCALL_V2 format + * + * Only some of the hypercall argument are recorded. Bit fields A0 to + * A5 in the first extra word are set if the argument is present and + * the arguments themselves are packed sequentially in the following + * words. + * + * The TRC_64_FLAG bit is not set for these events (even if there are + * 64-bit arguments in the record). + * + * Word + * 0 bit 31 30|29 28|27 26|25 24|23 22|21 20|19 ... 0 + * A5 |A4 |A3 |A2 |A1 |A0 |Hypercall op + * 1 First 32 bit (or low word of first 64 bit) arg in record + * 2 Second 32 bit (or high word of first 64 bit) arg in record + * ... + * + * A0-A5 bitfield values: + * + * 00b Argument not present + * 01b 32-bit argument present + * 10b 64-bit argument present + * 11b Reserved + */ +#define TRC_PV_HYPERCALL_V2_ARG_32(i) (0x1 << (20 + 2*(i))) +#define TRC_PV_HYPERCALL_V2_ARG_64(i) (0x2 << (20 + 2*(i))) +#define TRC_PV_HYPERCALL_V2_ARG_MASK (0xfff00000) #define TRC_SHADOW_NOT_SHADOW (TRC_SHADOW + 1) #define TRC_SHADOW_FAST_PROPAGATE (TRC_SHADOW + 2) diff --git a/xen/include/xen/trace.h b/xen/include/xen/trace.h index b32f6c5..f601aeb 100644 --- a/xen/include/xen/trace.h +++ b/xen/include/xen/trace.h @@ -44,6 +44,8 @@ static inline void trace_var(u32 event, int cycles, int extra, __trace_var(event, cycles, extra, extra_data); } +void __trace_hypercall(unsigned long call, const unsigned long *args); + /* Convenience macros for calling the trace function. */ #define TRACE_0D(_e) \ do { \ -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 17:09:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 17:09:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJSRp-0005S7-AS; Wed, 03 Oct 2012 17:09:25 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJSRn-0005Rc-LS for xen-devel@lists.xen.org; Wed, 03 Oct 2012 17:09:23 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1349284156!11371802!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzM2MzM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18095 invoked from network); 3 Oct 2012 17:09:17 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 17:09:17 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="40028524" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 16:46:15 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 12:46:14 -0400 Received: from qabil.uk.xensource.com ([10.80.2.76]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJRs6-0007Eo-Ox; Wed, 03 Oct 2012 17:32:30 +0100 From: David Vrabel To: xen-devel@lists.xen.org Date: Wed, 3 Oct 2012 17:32:26 +0100 Message-ID: <1349281947-5009-4-git-send-email-david.vrabel@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1349281947-5009-1-git-send-email-david.vrabel@citrix.com> References: <1349281947-5009-1-git-send-email-david.vrabel@citrix.com> MIME-Version: 1.0 Cc: David Vrabel , George Dunlap Subject: [Xen-devel] [PATCH 3/4] trace: improve usefulness of hypercall trace record X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: David Vrabel Trace hypercalls using a more useful trace record format. The EIP field is removed (it was always somewhere in the hypercall page) and include selected hypercall arguments (e.g., the number of calls in a multicall, and the number of PTE updates in an mmu_update etc.). 12 bits in the first extra word are used to indicate which arguments are present in the record and what size they are (32 or 64-bit). This is an incompatible record format so a new event ID is used so tools can distinguish between the two formats. Signed-off-by: David Vrabel --- tools/xentrace/formats | 1 + tools/xentrace/xentrace_format | 6 +++ xen/arch/x86/trace.c | 35 ++++++++----------- xen/common/trace.c | 70 ++++++++++++++++++++++++++++++++++++++++ xen/include/public/trace.h | 30 +++++++++++++++++ xen/include/xen/trace.h | 2 + 6 files changed, 124 insertions(+), 20 deletions(-) diff --git a/tools/xentrace/formats b/tools/xentrace/formats index 71220c0..fa935c8 100644 --- a/tools/xentrace/formats +++ b/tools/xentrace/formats @@ -104,6 +104,7 @@ 0x0020110b CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation [ addr = 0x%(4)08x%(3)08x, rip = 0x%(6)08x%(5)08x, npte = 0x%(2)08x%(1)08x ] 0x0020100c CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation_pae [ addr = 0x%(3)08x, eip = 0x%(4)08x, npte = 0x%(2)08x%(1)08x ] 0x0020110c CPU%(cpu)d %(tsc)d (+%(reltsc)8d) ptwr_emulation_pae [ addr = 0x%(4)08x%(3)08x, rip = 0x%(6)08x%(5)08x, npte = 0x%(2)08x%(1)08x ] +0x0020100d CPU%(cpu)d %(tsc)d (+%(reltsc)8d) hypercall [ op = 0x%(1)08x ] 0x0040f001 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) shadow_not_shadow [ gl1e = 0x%(2)08x%(1)08x, va = 0x%(3)08x, flags = 0x%(4)08x ] 0x0040f101 CPU%(cpu)d %(tsc)d (+%(reltsc)8d) shadow_not_shadow [ gl1e = 0x%(2)08x%(1)08x, va = 0x%(4)08x%(3)08x, flags = 0x%(5)08x ] diff --git a/tools/xentrace/xentrace_format b/tools/xentrace/xentrace_format index e13b05b..bdcab09 100644 --- a/tools/xentrace/xentrace_format +++ b/tools/xentrace/xentrace_format @@ -111,6 +111,8 @@ D7REC = "IIIIIII" last_tsc = [0] TRC_TRACE_IRQ = 0x1f004 +TRC_PV_HYPERCALL_V2 = 0x20100d + NR_VECTORS = 256 irq_measure = [{'count':0, 'tot_cycles':0, 'max_cycles':0}] * NR_VECTORS @@ -197,6 +199,10 @@ while not interrupted: d3 = irq_measure[d1]['tot_cycles'] d4 = irq_measure[d1]['max_cycles'] + if event == TRC_PV_HYPERCALL_V2: + # Mask off the argument present bits. + d1 &= 0x000fffff + #tsc = (tscH<<32) | tscL #print i, tsc diff --git a/xen/arch/x86/trace.c b/xen/arch/x86/trace.c index da4e974..9c43f17 100644 --- a/xen/arch/x86/trace.c +++ b/xen/arch/x86/trace.c @@ -9,33 +9,28 @@ void __trace_hypercall_entry(void) { struct cpu_user_regs *regs = guest_cpu_user_regs(); + unsigned long args[6]; if ( is_pv_32on64_vcpu(current) ) { - struct { - u32 eip,eax; - } __attribute__((packed)) d; - - d.eip = regs->eip; - d.eax = regs->eax; - - __trace_var(TRC_PV_HYPERCALL, 1, sizeof(d), &d); + args[0] = regs->ebx; + args[1] = regs->ecx; + args[2] = regs->edx; + args[3] = regs->esi; + args[4] = regs->edi; + args[5] = regs->ebp; } else { - struct { - unsigned long eip; - u32 eax; - } __attribute__((packed)) d; - u32 event; - - event = TRC_PV_HYPERCALL; - event |= TRC_64_FLAG; - d.eip = regs->eip; - d.eax = regs->eax; - - __trace_var(event, 1/*tsc*/, sizeof(d), &d); + args[0] = regs->rdi; + args[1] = regs->rsi; + args[2] = regs->rdx; + args[3] = regs->r10; + args[4] = regs->r8; + args[5] = regs->r9; } + + __trace_hypercall(regs->eax, args); } void __trace_pv_trap(int trapnr, unsigned long eip, diff --git a/xen/common/trace.c b/xen/common/trace.c index cacaeb2..059020d 100644 --- a/xen/common/trace.c +++ b/xen/common/trace.c @@ -816,6 +816,76 @@ unlock: tasklet_schedule(&trace_notify_dom0_tasklet); } +struct trace_hypercall { + struct trace_arg { + uint8_t words; + uint8_t idx; + } args[6]; +}; + +#define ARG32(i) { .words = 1, .idx = (i) } +#define ARG64(i) { .words = 2, .idx = (i) } + +/* + * Table of hypercall arguments to be added to the PV_HYPERCALL_V2 + * trace record. + * + * Guest pointers are usually omitted. + */ +static struct trace_hypercall trace_hypercall_table[] = { + [__HYPERVISOR_mmu_update] = {{ ARG32(1) }}, /* count */ + [__HYPERVISOR_multicall] = {{ ARG32(1) }}, /* count */ + [__HYPERVISOR_grant_table_op] = {{ ARG32(0), ARG32(2) }}, /* cmd, count */ + [__HYPERVISOR_vcpu_op] = {{ ARG32(0), ARG32(1) }}, /* cmd, vcpuid */ + [__HYPERVISOR_mmuext_op] = {{ ARG32(1) }}, /* count */ + [__HYPERVISOR_sched_op] = {{ ARG32(0) }}, /* cmd */ +}; + +#undef ARG32 +#undef ARG64 + +void __trace_hypercall(unsigned long op, const unsigned long *args) +{ + struct { + uint32_t op; + uint32_t args[6]; + } __attribute__((packed)) d; + uint32_t *a = d.args; + + /* + * This shouldn't happen as @op should be small enough but just in + * case, warn if the argument bits in the trace record would + * clobber the hypercall op. + */ + WARN_ON(op & TRC_PV_HYPERCALL_V2_ARG_MASK); + + d.op = op; + + if ( op < ARRAY_SIZE(trace_hypercall_table) ) + { + struct trace_arg *i; + + for ( i = trace_hypercall_table[op].args; i->words; i++ ) + { + switch (i->words) + { + case 1: + *a++ = args[i->idx]; + d.op |= TRC_PV_HYPERCALL_V2_ARG_32(i->idx); + break; + case 2: + *a++ = args[i->idx]; + *a++ = args[i->idx] >> 32; + d.op |= TRC_PV_HYPERCALL_V2_ARG_64(i->idx); + break; + } + } + } + + __trace_var(TRC_PV_HYPERCALL_V2, 1, + sizeof(uint32_t) * (1 + (a - d.args)), &d); +} + /* * Local variables: * mode: C diff --git a/xen/include/public/trace.h b/xen/include/public/trace.h index 1f154bb..ef43b23 100644 --- a/xen/include/public/trace.h +++ b/xen/include/public/trace.h @@ -107,6 +107,36 @@ #define TRC_PV_GDT_LDT_MAPPING_FAULT (TRC_PV_ENTRY + 10) #define TRC_PV_PTWR_EMULATION (TRC_PV_ENTRY + 11) #define TRC_PV_PTWR_EMULATION_PAE (TRC_PV_ENTRY + 12) +#define TRC_PV_HYPERCALL_V2 (TRC_PV_ENTRY + 13) + +/* + * TRC_PV_HYPERCALL_V2 format + * + * Only some of the hypercall argument are recorded. Bit fields A0 to + * A5 in the first extra word are set if the argument is present and + * the arguments themselves are packed sequentially in the following + * words. + * + * The TRC_64_FLAG bit is not set for these events (even if there are + * 64-bit arguments in the record). + * + * Word + * 0 bit 31 30|29 28|27 26|25 24|23 22|21 20|19 ... 0 + * A5 |A4 |A3 |A2 |A1 |A0 |Hypercall op + * 1 First 32 bit (or low word of first 64 bit) arg in record + * 2 Second 32 bit (or high word of first 64 bit) arg in record + * ... + * + * A0-A5 bitfield values: + * + * 00b Argument not present + * 01b 32-bit argument present + * 10b 64-bit argument present + * 11b Reserved + */ +#define TRC_PV_HYPERCALL_V2_ARG_32(i) (0x1 << (20 + 2*(i))) +#define TRC_PV_HYPERCALL_V2_ARG_64(i) (0x2 << (20 + 2*(i))) +#define TRC_PV_HYPERCALL_V2_ARG_MASK (0xfff00000) #define TRC_SHADOW_NOT_SHADOW (TRC_SHADOW + 1) #define TRC_SHADOW_FAST_PROPAGATE (TRC_SHADOW + 2) diff --git a/xen/include/xen/trace.h b/xen/include/xen/trace.h index b32f6c5..f601aeb 100644 --- a/xen/include/xen/trace.h +++ b/xen/include/xen/trace.h @@ -44,6 +44,8 @@ static inline void trace_var(u32 event, int cycles, int extra, __trace_var(event, cycles, extra, extra_data); } +void __trace_hypercall(unsigned long call, const unsigned long *args); + /* Convenience macros for calling the trace function. */ #define TRACE_0D(_e) \ do { \ -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 17:10:05 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 17:10:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJSSK-0005Yo-9b; Wed, 03 Oct 2012 17:09:56 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJSSI-0005YN-J2 for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 17:09:54 +0000 Received: from [85.158.143.99:52891] by server-2.bemta-4.messagelabs.com id A8/FB-06610-1617C605; Wed, 03 Oct 2012 17:09:53 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1349284193!23130410!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8805 invoked from network); 3 Oct 2012 17:09:53 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 17:09:53 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="14921893" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 17:09:52 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 18:09:52 +0100 Date: Wed, 3 Oct 2012 18:08:52 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Ian Campbell In-Reply-To: <1349282492.650.185.camel@zakaz.uk.xensource.com> Message-ID: References: <1349272182.650.150.camel@zakaz.uk.xensource.com> <1349272482.650.151.camel@zakaz.uk.xensource.com> <20121003141116.GA10633@phenom.dumpdata.com> <1349276431.650.156.camel@zakaz.uk.xensource.com> <1349279862.650.171.camel@zakaz.uk.xensource.com> <1349280814.650.178.camel@zakaz.uk.xensource.com> <1349282492.650.185.camel@zakaz.uk.xensource.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , Konrad Rzeszutek Wilk , Stefano Stabellini Subject: [Xen-devel] [PATCH] xen/xen_initial_domain: check that xen_start_info is initialized X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Since commit commit 4c071ee5268f7234c3d084b6093bebccc28cdcba ("arm: initial Xen support") PV on HVM guests can be xen_initial_domain. However PV on HVM guests might have an unitialized xen_start_info, so check before accessing its fields. Signed-off-by: Stefano Stabellini Acked-by: Ian Campbell Reported-by: Konrad Rzeszutek Wilk diff --git a/include/xen/xen.h b/include/xen/xen.h index 9a39ca5..e7101bb 100644 --- a/include/xen/xen.h +++ b/include/xen/xen.h @@ -28,7 +28,7 @@ extern enum xen_domain_type xen_domain_type; #include #define xen_initial_domain() (xen_domain() && \ - xen_start_info->flags & SIF_INITDOMAIN) + xen_start_info && xen_start_info->flags & SIF_INITDOMAIN) #else /* !CONFIG_XEN_DOM0 */ #define xen_initial_domain() (0) #endif /* CONFIG_XEN_DOM0 */ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 17:10:05 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 17:10:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJSSK-0005Yo-9b; Wed, 03 Oct 2012 17:09:56 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJSSI-0005YN-J2 for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 17:09:54 +0000 Received: from [85.158.143.99:52891] by server-2.bemta-4.messagelabs.com id A8/FB-06610-1617C605; Wed, 03 Oct 2012 17:09:53 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1349284193!23130410!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8805 invoked from network); 3 Oct 2012 17:09:53 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 17:09:53 -0000 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="14921893" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 17:09:52 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 18:09:52 +0100 Date: Wed, 3 Oct 2012 18:08:52 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Ian Campbell In-Reply-To: <1349282492.650.185.camel@zakaz.uk.xensource.com> Message-ID: References: <1349272182.650.150.camel@zakaz.uk.xensource.com> <1349272482.650.151.camel@zakaz.uk.xensource.com> <20121003141116.GA10633@phenom.dumpdata.com> <1349276431.650.156.camel@zakaz.uk.xensource.com> <1349279862.650.171.camel@zakaz.uk.xensource.com> <1349280814.650.178.camel@zakaz.uk.xensource.com> <1349282492.650.185.camel@zakaz.uk.xensource.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , Konrad Rzeszutek Wilk , Stefano Stabellini Subject: [Xen-devel] [PATCH] xen/xen_initial_domain: check that xen_start_info is initialized X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Since commit commit 4c071ee5268f7234c3d084b6093bebccc28cdcba ("arm: initial Xen support") PV on HVM guests can be xen_initial_domain. However PV on HVM guests might have an unitialized xen_start_info, so check before accessing its fields. Signed-off-by: Stefano Stabellini Acked-by: Ian Campbell Reported-by: Konrad Rzeszutek Wilk diff --git a/include/xen/xen.h b/include/xen/xen.h index 9a39ca5..e7101bb 100644 --- a/include/xen/xen.h +++ b/include/xen/xen.h @@ -28,7 +28,7 @@ extern enum xen_domain_type xen_domain_type; #include #define xen_initial_domain() (xen_domain() && \ - xen_start_info->flags & SIF_INITDOMAIN) + xen_start_info && xen_start_info->flags & SIF_INITDOMAIN) #else /* !CONFIG_XEN_DOM0 */ #define xen_initial_domain() (0) #endif /* CONFIG_XEN_DOM0 */ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 17:19:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 17:19:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJSbg-0005yq-Bq; Wed, 03 Oct 2012 17:19:36 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJSbe-0005yl-KB for xen-devel@lists.xen.org; Wed, 03 Oct 2012 17:19:34 +0000 Received: from [85.158.137.99:13708] by server-2.bemta-3.messagelabs.com id 8D/66-16514-5A37C605; Wed, 03 Oct 2012 17:19:33 +0000 X-Env-Sender: peter.maloney@brockmann-consult.de X-Msg-Ref: server-2.tower-217.messagelabs.com!1349284773!20036212!1 X-Originating-IP: [212.227.17.10] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjEyLjIyNy4xNy4xMCA9PiA4NDA5NQ==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28932 invoked from network); 3 Oct 2012 17:19:33 -0000 Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de) (212.227.17.10) by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 17:19:33 -0000 Received: from [192.168.179.201] (hmbg-4d06dfd3.pool.mediaWays.net [77.6.223.211]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0MJEQE-1THoiM2LiU-002Phf; Wed, 03 Oct 2012 19:19:32 +0200 Message-ID: <506C73A3.2030605@brockmann-consult.de> Date: Wed, 03 Oct 2012 19:19:31 +0200 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120825 Thunderbird/15.0 MIME-Version: 1.0 To: xen-devel@lists.xen.org References: <501F98A1.4070806@brockmann-consult.de> <501FB9060200007800092D4E@nat28.tlf.novell.com> <5020C2DE.304@brockmann-consult.de> <50294D4B.9050405@brockmann-consult.de> <50296AC2.80600@brockmann-consult.de> In-Reply-To: <50296AC2.80600@brockmann-consult.de> X-Provags-ID: V02:K0:itU0gD6z+T7fGPymm3Bp4IUBxCuj2mh7c6nQ6XjorEs cE/JJefp3+QUmU4/gy9oElK6gw7LN4FrPLjmtoVnHOwZLZf/18 U7Mh3ODtWltPKMCpqJW8uUJg0rGGAPPRM14zJRnTPZOnUSgSr+ i0PkRHVWE3+AL+NS0fOh6cQeogxcJwkIp545Ad0CFWFyF2Db6N UaX3Wpa1NKzB/A1o1pCtmeBWNy5+EKt6lqByXHt6mjKcPo8Wab ZCR9Ipdd0cg+nBkDCCIBL1zF7QVXCr8Je9QMWdbnXHV7W505nC uSPV9D0dTxVjitePrY7RXejo8EKXXLeOGlJRKTIEndICqTFgRx jHzpX0bHD/10Bymeb+HaJuzd1zH0C8DsCgbPP7yYt/7seV9r94 P/1S10tHaZYhw== Subject: Re: [Xen-devel] 4.1.2 very slow without upstream patches, but fast with them, also 4.2 very slow X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org I ran some new tests... 4.1.2 with different patches, and 4.3-unstable.Some details are below. At some point in the future, I will try some builds between 4.1 and 4.2 (but at the moment am not sure how with mercurial or what options I have). 4.1.2 short version: dom0 works fine; domu ran only in a few builds and works fine long version: I tested 4.1.2 again, with a few selections of patches (first n patches where n was; 0, 23, 46, 93, 186, 279; there are 373 patches in total). All of them ran fast in dom0, unlike when I first started this mailing list thread, and the builds that would run my windows domu ran it fast. So probably there was something strange with the kernel I had before, which was probably 3.4.4; now I'm using something like 3.5.x (cmason's linux-btrfs repository, for-linus branch) 4.3-unstable short version: dom0 works fine; domu always runs terribly slow (which leads me to wanting to test what changed between 4.1 and 4.2) long version: I pulled the latest source, built it, and dom0 is fast just like with 4.2, but windows hvm domu is still terribly slow, and (with 7 vcpus), it consumes between 500-650% while booting and a few minutes afterwards. With 4 CPUs, I would expect between 350-550% from observations with 4.2 but didn't test other cpu counts with 4.3. (another side note, with 4.1.3 which is normally fast, it will run slow like 4.2 and 4.3 if I set cpus="2,4,6,8" instead of cpus=4) xentop - 11:32:44 Xen 4.3-unstable 2 domains: 2 running, 0 blocked, 0 paused, 0 crashed, 0 dying, 0 shutdown Mem: 16757972k total, 16739788k used, 18184k free CPUs: 8 @ 4499MHz NAME STATE CPU(sec) CPU(%) MEM(k) MEM(%) MAXMEM(k) MAXMEM(%) VCPUS NETS NETTX(k) NETRX(k) VBDS VBD_OO VBD_RD VBD_WR VBD_RSECT VBD_WSECT SSID Domain-0 -----r 784 27.2 12314624 73.5 12582912 75.1 8 0 0 0 0 0 0 0 0 0 0 windowsxp2 -----r 3244 637.1 4197220 25.0 4198400 25.1 7 1 344 56 2 0 14381 6054 651283 122280 0 And then after idling for 10 minutes, it is under 200% xentop - 11:35:29 Xen 4.3-unstable 2 domains: 1 running, 1 blocked, 0 paused, 0 crashed, 0 dying, 0 shutdown Mem: 16757972k total, 16739788k used, 18184k free CPUs: 8 @ 4499MHz NAME STATE CPU(sec) CPU(%) MEM(k) MEM(%) MAXMEM(k) MAXMEM(%) VCPUS NETS NETTX(k) NETRX(k) VBDS VBD_OO VBD_RD VBD_WR VBD_RSECT VBD_WSECT SSID Domain-0 -----r 839 42.4 12314624 73.5 12582912 75.1 8 0 0 0 0 0 0 0 0 0 0 windowsxp2 --b--- 3583 114.1 4197220 25.0 4198400 25.1 7 1 426 66 2 0 14408 7501 651853 180372 0 And then when it is in use (just loading a youtube page), it is up high again. xentop - 11:37:17 Xen 4.3-unstable 2 domains: 2 running, 0 blocked, 0 paused, 0 crashed, 0 dying, 0 shutdown Mem: 16757972k total, 16739788k used, 18184k free CPUs: 8 @ 4499MHz NAME STATE CPU(sec) CPU(%) MEM(k) MEM(%) MAXMEM(k) MAXMEM(%) VCPUS NETS NETTX(k) NETRX(k) VBDS VBD_OO VBD_RD VBD_WR VBD_RSECT VBD_WSECT SSID Domain-0 -----r 875 37.8 12314624 73.5 12582912 75.1 8 0 0 0 0 0 0 0 0 0 0 windowsxp2 -----r 3945 529.7 4197220 25.0 4198400 25.1 7 1 4885 201 2 0 17096 8168 788573 198458 0 And also if I shut down the vm while it is at 600% cpu, it takes something like 10-15 minutes to shut down. and CPU temperature is only 45 degrees during the high cpu usage, and 26-32 degrees when it's 0%, so whatever CPU waste it's doing is not generating much heat. With 4.1.3, while a game is open, it reports 200% cpu, and the temperature is around 50 degrees. I have a huge CPU cooler; it's overclocked; and normally it runs about 55-70 degrees using 8 cores depending on the task. I tested with apic=0 and apic=1 (apic=1 will run windows very slow in 4.1.x, so I have been using apic=0 normally) On 08/13/2012 10:59 PM, Peter Maloney wrote: > I also tested 4.1.3, which is fast, and both USB and graphics > passthrough work, but "xl create" gave this message the first time I > started the vm (but not the second): > > libxl: error: libxl_pci.c:750:libxl_device_pci_reset The kernel doesn't > support reset from sysfs for PCI device 0000:00:12.0 > > > 0000:00:12.0 is a USB device, which works in the VM. > > peter:/opt # lspci -v | grep 00:12.0 > 00:12.0 USB Controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB OHCI0 > Controller (prog-if 10 [OHCI]) > > > On 08/13/2012 08:54 PM, Peter Maloney wrote: >> So... did my 4.2-unstable test, using a fresh pull from yesterday; dom0 >> is normal fast (unlike previous tests), and domU is ultra slow, but >> actually boots, and graphics card passthrough works without any patches, >> and so does the USB keyboard, but USB mouse passthrough doesn't work. >> >> >> On 08/07/2012 09:25 AM, Peter Maloney wrote: >>>> That still won't tell us which patches you did apply. >>> I applied no patches and tested, and the result was slow. And then >>> applied all patches, and it was fast. I didn't try figuring out which >>> one it was. >>> >>> >>> So I guess I'll try: >>> - the latest unstable 4.2 >>> - the 4.1.3-rc (Which includes the patch Malcolm suggested) >>> - and my rpm source with half patches, 3/4 of them, etc. binary search >>> style to see which patch(es) changed the performance. But this means I >>> won't be able to narrow it down to a single patch, but only the point in >>> the long list where the most dramatic change happens, possibly depending >>> on many previous patches. >>> >>> Thanks so far, guys. >>> >>> >>> On 08/06/2012 12:31 PM, Jan Beulich wrote: >>>>>>> On 06.08.12 at 12:12, Peter Maloney wrote: >>>>> my AMD FX-8150 system with vanilla source code is super slow, both the >>>>> dom0 and domUs. However, after I merge the upstream patches I found in >>>>> the openSUSE rpm, it runs normally. >>>> I'd be very surprised if you really just took the upstream patches, >>>> and the result was better than 4.2-rc1. After all, what upstream >>>> means is that they were taken from -unstable. >>>> >>>>> I tried 4.2-unstable and it was the same. There was no rc1 when I tested >>>>> it about 1.5 weeks ago. And 4.2 has the same horrible performance, and >>>>> obviously those patches won't work any more since the 4.2 code looks >>>>> completely reorganized, so I'm stuck with 4.1.2 >>>> Obviously the upstream patches can't be applied to something >>>> that already has all those changes. Other patches, of which we >>>> unfortunately have quite a few, would be a different story. >>>> >>>>> Here is the rpm I was using at the time: >>>>> http://download.opensuse.org/update/12.1/src/xen-4.1.2_16-1.7.1.src.rpm >>>>> >>>>> To see the list of the patches and what order to apply them, see the >>>>> spec file. >>>> That still won't tell us which patches you did apply. >>>> >>>>> Please make sure this performance issue is fixed for the 4.2 release. >>>>> And I would be happy to test whatever files you send me. >>>> The sort of report you're doing isn't that helpful. What would >>>> help is if you could narrow down which patch(es) it is that >>>> make things so much better. Giving 4.1.3-rc a try might also >>>> be worthwhile, albeit I would hope we don't have a regression >>>> in 4.2.0-rc compared to 4.1.3-rc... >>>> >>>> Jan >>>> >>>> >>>> _______________________________________________ >>>> Xen-devel mailing list >>>> Xen-devel@lists.xen.org >>>> http://lists.xen.org/xen-devel >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 17:19:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 17:19:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJSbg-0005yq-Bq; Wed, 03 Oct 2012 17:19:36 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJSbe-0005yl-KB for xen-devel@lists.xen.org; Wed, 03 Oct 2012 17:19:34 +0000 Received: from [85.158.137.99:13708] by server-2.bemta-3.messagelabs.com id 8D/66-16514-5A37C605; Wed, 03 Oct 2012 17:19:33 +0000 X-Env-Sender: peter.maloney@brockmann-consult.de X-Msg-Ref: server-2.tower-217.messagelabs.com!1349284773!20036212!1 X-Originating-IP: [212.227.17.10] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjEyLjIyNy4xNy4xMCA9PiA4NDA5NQ==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28932 invoked from network); 3 Oct 2012 17:19:33 -0000 Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de) (212.227.17.10) by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 17:19:33 -0000 Received: from [192.168.179.201] (hmbg-4d06dfd3.pool.mediaWays.net [77.6.223.211]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0MJEQE-1THoiM2LiU-002Phf; Wed, 03 Oct 2012 19:19:32 +0200 Message-ID: <506C73A3.2030605@brockmann-consult.de> Date: Wed, 03 Oct 2012 19:19:31 +0200 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120825 Thunderbird/15.0 MIME-Version: 1.0 To: xen-devel@lists.xen.org References: <501F98A1.4070806@brockmann-consult.de> <501FB9060200007800092D4E@nat28.tlf.novell.com> <5020C2DE.304@brockmann-consult.de> <50294D4B.9050405@brockmann-consult.de> <50296AC2.80600@brockmann-consult.de> In-Reply-To: <50296AC2.80600@brockmann-consult.de> X-Provags-ID: V02:K0:itU0gD6z+T7fGPymm3Bp4IUBxCuj2mh7c6nQ6XjorEs cE/JJefp3+QUmU4/gy9oElK6gw7LN4FrPLjmtoVnHOwZLZf/18 U7Mh3ODtWltPKMCpqJW8uUJg0rGGAPPRM14zJRnTPZOnUSgSr+ i0PkRHVWE3+AL+NS0fOh6cQeogxcJwkIp545Ad0CFWFyF2Db6N UaX3Wpa1NKzB/A1o1pCtmeBWNy5+EKt6lqByXHt6mjKcPo8Wab ZCR9Ipdd0cg+nBkDCCIBL1zF7QVXCr8Je9QMWdbnXHV7W505nC uSPV9D0dTxVjitePrY7RXejo8EKXXLeOGlJRKTIEndICqTFgRx jHzpX0bHD/10Bymeb+HaJuzd1zH0C8DsCgbPP7yYt/7seV9r94 P/1S10tHaZYhw== Subject: Re: [Xen-devel] 4.1.2 very slow without upstream patches, but fast with them, also 4.2 very slow X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org I ran some new tests... 4.1.2 with different patches, and 4.3-unstable.Some details are below. At some point in the future, I will try some builds between 4.1 and 4.2 (but at the moment am not sure how with mercurial or what options I have). 4.1.2 short version: dom0 works fine; domu ran only in a few builds and works fine long version: I tested 4.1.2 again, with a few selections of patches (first n patches where n was; 0, 23, 46, 93, 186, 279; there are 373 patches in total). All of them ran fast in dom0, unlike when I first started this mailing list thread, and the builds that would run my windows domu ran it fast. So probably there was something strange with the kernel I had before, which was probably 3.4.4; now I'm using something like 3.5.x (cmason's linux-btrfs repository, for-linus branch) 4.3-unstable short version: dom0 works fine; domu always runs terribly slow (which leads me to wanting to test what changed between 4.1 and 4.2) long version: I pulled the latest source, built it, and dom0 is fast just like with 4.2, but windows hvm domu is still terribly slow, and (with 7 vcpus), it consumes between 500-650% while booting and a few minutes afterwards. With 4 CPUs, I would expect between 350-550% from observations with 4.2 but didn't test other cpu counts with 4.3. (another side note, with 4.1.3 which is normally fast, it will run slow like 4.2 and 4.3 if I set cpus="2,4,6,8" instead of cpus=4) xentop - 11:32:44 Xen 4.3-unstable 2 domains: 2 running, 0 blocked, 0 paused, 0 crashed, 0 dying, 0 shutdown Mem: 16757972k total, 16739788k used, 18184k free CPUs: 8 @ 4499MHz NAME STATE CPU(sec) CPU(%) MEM(k) MEM(%) MAXMEM(k) MAXMEM(%) VCPUS NETS NETTX(k) NETRX(k) VBDS VBD_OO VBD_RD VBD_WR VBD_RSECT VBD_WSECT SSID Domain-0 -----r 784 27.2 12314624 73.5 12582912 75.1 8 0 0 0 0 0 0 0 0 0 0 windowsxp2 -----r 3244 637.1 4197220 25.0 4198400 25.1 7 1 344 56 2 0 14381 6054 651283 122280 0 And then after idling for 10 minutes, it is under 200% xentop - 11:35:29 Xen 4.3-unstable 2 domains: 1 running, 1 blocked, 0 paused, 0 crashed, 0 dying, 0 shutdown Mem: 16757972k total, 16739788k used, 18184k free CPUs: 8 @ 4499MHz NAME STATE CPU(sec) CPU(%) MEM(k) MEM(%) MAXMEM(k) MAXMEM(%) VCPUS NETS NETTX(k) NETRX(k) VBDS VBD_OO VBD_RD VBD_WR VBD_RSECT VBD_WSECT SSID Domain-0 -----r 839 42.4 12314624 73.5 12582912 75.1 8 0 0 0 0 0 0 0 0 0 0 windowsxp2 --b--- 3583 114.1 4197220 25.0 4198400 25.1 7 1 426 66 2 0 14408 7501 651853 180372 0 And then when it is in use (just loading a youtube page), it is up high again. xentop - 11:37:17 Xen 4.3-unstable 2 domains: 2 running, 0 blocked, 0 paused, 0 crashed, 0 dying, 0 shutdown Mem: 16757972k total, 16739788k used, 18184k free CPUs: 8 @ 4499MHz NAME STATE CPU(sec) CPU(%) MEM(k) MEM(%) MAXMEM(k) MAXMEM(%) VCPUS NETS NETTX(k) NETRX(k) VBDS VBD_OO VBD_RD VBD_WR VBD_RSECT VBD_WSECT SSID Domain-0 -----r 875 37.8 12314624 73.5 12582912 75.1 8 0 0 0 0 0 0 0 0 0 0 windowsxp2 -----r 3945 529.7 4197220 25.0 4198400 25.1 7 1 4885 201 2 0 17096 8168 788573 198458 0 And also if I shut down the vm while it is at 600% cpu, it takes something like 10-15 minutes to shut down. and CPU temperature is only 45 degrees during the high cpu usage, and 26-32 degrees when it's 0%, so whatever CPU waste it's doing is not generating much heat. With 4.1.3, while a game is open, it reports 200% cpu, and the temperature is around 50 degrees. I have a huge CPU cooler; it's overclocked; and normally it runs about 55-70 degrees using 8 cores depending on the task. I tested with apic=0 and apic=1 (apic=1 will run windows very slow in 4.1.x, so I have been using apic=0 normally) On 08/13/2012 10:59 PM, Peter Maloney wrote: > I also tested 4.1.3, which is fast, and both USB and graphics > passthrough work, but "xl create" gave this message the first time I > started the vm (but not the second): > > libxl: error: libxl_pci.c:750:libxl_device_pci_reset The kernel doesn't > support reset from sysfs for PCI device 0000:00:12.0 > > > 0000:00:12.0 is a USB device, which works in the VM. > > peter:/opt # lspci -v | grep 00:12.0 > 00:12.0 USB Controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB OHCI0 > Controller (prog-if 10 [OHCI]) > > > On 08/13/2012 08:54 PM, Peter Maloney wrote: >> So... did my 4.2-unstable test, using a fresh pull from yesterday; dom0 >> is normal fast (unlike previous tests), and domU is ultra slow, but >> actually boots, and graphics card passthrough works without any patches, >> and so does the USB keyboard, but USB mouse passthrough doesn't work. >> >> >> On 08/07/2012 09:25 AM, Peter Maloney wrote: >>>> That still won't tell us which patches you did apply. >>> I applied no patches and tested, and the result was slow. And then >>> applied all patches, and it was fast. I didn't try figuring out which >>> one it was. >>> >>> >>> So I guess I'll try: >>> - the latest unstable 4.2 >>> - the 4.1.3-rc (Which includes the patch Malcolm suggested) >>> - and my rpm source with half patches, 3/4 of them, etc. binary search >>> style to see which patch(es) changed the performance. But this means I >>> won't be able to narrow it down to a single patch, but only the point in >>> the long list where the most dramatic change happens, possibly depending >>> on many previous patches. >>> >>> Thanks so far, guys. >>> >>> >>> On 08/06/2012 12:31 PM, Jan Beulich wrote: >>>>>>> On 06.08.12 at 12:12, Peter Maloney wrote: >>>>> my AMD FX-8150 system with vanilla source code is super slow, both the >>>>> dom0 and domUs. However, after I merge the upstream patches I found in >>>>> the openSUSE rpm, it runs normally. >>>> I'd be very surprised if you really just took the upstream patches, >>>> and the result was better than 4.2-rc1. After all, what upstream >>>> means is that they were taken from -unstable. >>>> >>>>> I tried 4.2-unstable and it was the same. There was no rc1 when I tested >>>>> it about 1.5 weeks ago. And 4.2 has the same horrible performance, and >>>>> obviously those patches won't work any more since the 4.2 code looks >>>>> completely reorganized, so I'm stuck with 4.1.2 >>>> Obviously the upstream patches can't be applied to something >>>> that already has all those changes. Other patches, of which we >>>> unfortunately have quite a few, would be a different story. >>>> >>>>> Here is the rpm I was using at the time: >>>>> http://download.opensuse.org/update/12.1/src/xen-4.1.2_16-1.7.1.src.rpm >>>>> >>>>> To see the list of the patches and what order to apply them, see the >>>>> spec file. >>>> That still won't tell us which patches you did apply. >>>> >>>>> Please make sure this performance issue is fixed for the 4.2 release. >>>>> And I would be happy to test whatever files you send me. >>>> The sort of report you're doing isn't that helpful. What would >>>> help is if you could narrow down which patch(es) it is that >>>> make things so much better. Giving 4.1.3-rc a try might also >>>> be worthwhile, albeit I would hope we don't have a regression >>>> in 4.2.0-rc compared to 4.1.3-rc... >>>> >>>> Jan >>>> >>>> >>>> _______________________________________________ >>>> Xen-devel mailing list >>>> Xen-devel@lists.xen.org >>>> http://lists.xen.org/xen-devel >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 18:27:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 18:27:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJTf9-0006aj-Pg; Wed, 03 Oct 2012 18:27:15 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJTf8-0006ae-2M for Xen-devel@lists.xensource.com; Wed, 03 Oct 2012 18:27:14 +0000 Received: from [85.158.137.99:52424] by server-11.bemta-3.messagelabs.com id 1A/10-21460-1838C605; Wed, 03 Oct 2012 18:27:13 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-16.tower-217.messagelabs.com!1349288831!20146327!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc5MDM1NA==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3709 invoked from network); 3 Oct 2012 18:27:12 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-16.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Oct 2012 18:27:12 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q93IR5PW019935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Oct 2012 18:27:05 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q93IR406003839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Oct 2012 18:27:05 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q93IR48g003322; Wed, 3 Oct 2012 13:27:04 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 03 Oct 2012 11:27:03 -0700 Date: Wed, 3 Oct 2012 11:27:02 -0700 From: Mukesh Rathor To: Stefano Stabellini Message-ID: <20121003112702.03845930@mantra.us.oracle.com> In-Reply-To: References: <20120921121556.1a0ea8af@mantra.us.oracle.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "Xen-devel@lists.xensource.com" , Ian Campbell , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, 24 Sep 2012 12:55:31 +0100 Stefano Stabellini wrote: > There are few code style issues on this patch, I suggest you run it > through scripts/checkpatch.pl, it should be able to catch all these > errors. Oh, my bad. I was running them thru cleanpatch and not checkpatch. It's my first linux submission, so please bear with me. I'll run them all thru checkpatch this time. Thanks Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 18:27:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 18:27:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJTf9-0006aj-Pg; Wed, 03 Oct 2012 18:27:15 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJTf8-0006ae-2M for Xen-devel@lists.xensource.com; Wed, 03 Oct 2012 18:27:14 +0000 Received: from [85.158.137.99:52424] by server-11.bemta-3.messagelabs.com id 1A/10-21460-1838C605; Wed, 03 Oct 2012 18:27:13 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-16.tower-217.messagelabs.com!1349288831!20146327!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc5MDM1NA==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3709 invoked from network); 3 Oct 2012 18:27:12 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-16.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Oct 2012 18:27:12 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q93IR5PW019935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Oct 2012 18:27:05 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q93IR406003839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Oct 2012 18:27:05 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q93IR48g003322; Wed, 3 Oct 2012 13:27:04 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 03 Oct 2012 11:27:03 -0700 Date: Wed, 3 Oct 2012 11:27:02 -0700 From: Mukesh Rathor To: Stefano Stabellini Message-ID: <20121003112702.03845930@mantra.us.oracle.com> In-Reply-To: References: <20120921121556.1a0ea8af@mantra.us.oracle.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "Xen-devel@lists.xensource.com" , Ian Campbell , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, 24 Sep 2012 12:55:31 +0100 Stefano Stabellini wrote: > There are few code style issues on this patch, I suggest you run it > through scripts/checkpatch.pl, it should be able to catch all these > errors. Oh, my bad. I was running them thru cleanpatch and not checkpatch. It's my first linux submission, so please bear with me. I'll run them all thru checkpatch this time. Thanks Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 19:12:07 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 19:12:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJUM7-00070y-Ej; Wed, 03 Oct 2012 19:11:39 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJUM5-00070t-1d for Xen-devel@lists.xensource.com; Wed, 03 Oct 2012 19:11:37 +0000 Received: from [85.158.143.35:17107] by server-3.bemta-4.messagelabs.com id F4/D6-10986-7ED8C605; Wed, 03 Oct 2012 19:11:35 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1349291493!17355657!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc5MDM1NA==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11953 invoked from network); 3 Oct 2012 19:11:34 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Oct 2012 19:11:34 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q93JBRBZ001167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Oct 2012 19:11:28 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q93JBQOe005875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Oct 2012 19:11:27 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q93JBQgO002224; Wed, 3 Oct 2012 14:11:26 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 03 Oct 2012 12:11:26 -0700 Date: Wed, 3 Oct 2012 12:11:22 -0700 From: Mukesh Rathor To: Ian Campbell Message-ID: <20121003121122.0f20d5ed@mantra.us.oracle.com> In-Reply-To: <1349170528.650.18.camel@zakaz.uk.xensource.com> References: <20120921121202.3163c379@mantra.us.oracle.com> <1348581263.11229.21.camel@zakaz.uk.xensource.com> <20121001142826.1ebf7b0f@mantra.us.oracle.com> <1349170528.650.18.camel@zakaz.uk.xensource.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 0/8]: PVH (PV guest with extensions) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2 Oct 2012 10:35:28 +0100 Ian Campbell wrote: > On Mon, 2012-10-01 at 22:28 +0100, Mukesh Rathor wrote: > > On Tue, 25 Sep 2012 14:54:23 +0100 > > Ian Campbell wrote: > > > > > On Fri, 2012-09-21 at 20:12 +0100, Mukesh Rathor wrote: > > > > Hi guys, > > > > > > > > Ok, I've made all the changes from prev RFC patch submission. > > > > > > Did I miss the patch with the changes to arch/x86/xen/xen-head.S > > > which declare the features which are used here as supported by > > > the kernel image? > > > > > > Ian. > > > > > > > Strange, adding following to head.S > > > > ELFNOTE(Xen, XEN_ELFNOTE_PADDR_OFFSET, _ASM_PTR 0) > > ELFNOTE(Xen, XEN_ELFNOTE_GUEST_PVH, .long 1) <-------- > > > > and xenstore won't start in dom0. What gives? > > I have no idea, I can't think of any way that xenstored would be able > to even see the notes given in the dom0 kernel image. > > Are you sure you only that one exact change? You Ok with XEN_ELFNOTE_GUEST_PVH, or should I call it XEN_ELFNOTE_PV_EXTENSIONS. Please LMK. tanks Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 19:12:07 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 19:12:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJUM7-00070y-Ej; Wed, 03 Oct 2012 19:11:39 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJUM5-00070t-1d for Xen-devel@lists.xensource.com; Wed, 03 Oct 2012 19:11:37 +0000 Received: from [85.158.143.35:17107] by server-3.bemta-4.messagelabs.com id F4/D6-10986-7ED8C605; Wed, 03 Oct 2012 19:11:35 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1349291493!17355657!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc5MDM1NA==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11953 invoked from network); 3 Oct 2012 19:11:34 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Oct 2012 19:11:34 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q93JBRBZ001167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Oct 2012 19:11:28 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q93JBQOe005875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Oct 2012 19:11:27 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q93JBQgO002224; Wed, 3 Oct 2012 14:11:26 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 03 Oct 2012 12:11:26 -0700 Date: Wed, 3 Oct 2012 12:11:22 -0700 From: Mukesh Rathor To: Ian Campbell Message-ID: <20121003121122.0f20d5ed@mantra.us.oracle.com> In-Reply-To: <1349170528.650.18.camel@zakaz.uk.xensource.com> References: <20120921121202.3163c379@mantra.us.oracle.com> <1348581263.11229.21.camel@zakaz.uk.xensource.com> <20121001142826.1ebf7b0f@mantra.us.oracle.com> <1349170528.650.18.camel@zakaz.uk.xensource.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 0/8]: PVH (PV guest with extensions) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2 Oct 2012 10:35:28 +0100 Ian Campbell wrote: > On Mon, 2012-10-01 at 22:28 +0100, Mukesh Rathor wrote: > > On Tue, 25 Sep 2012 14:54:23 +0100 > > Ian Campbell wrote: > > > > > On Fri, 2012-09-21 at 20:12 +0100, Mukesh Rathor wrote: > > > > Hi guys, > > > > > > > > Ok, I've made all the changes from prev RFC patch submission. > > > > > > Did I miss the patch with the changes to arch/x86/xen/xen-head.S > > > which declare the features which are used here as supported by > > > the kernel image? > > > > > > Ian. > > > > > > > Strange, adding following to head.S > > > > ELFNOTE(Xen, XEN_ELFNOTE_PADDR_OFFSET, _ASM_PTR 0) > > ELFNOTE(Xen, XEN_ELFNOTE_GUEST_PVH, .long 1) <-------- > > > > and xenstore won't start in dom0. What gives? > > I have no idea, I can't think of any way that xenstored would be able > to even see the notes given in the dom0 kernel image. > > Are you sure you only that one exact change? You Ok with XEN_ELFNOTE_GUEST_PVH, or should I call it XEN_ELFNOTE_PV_EXTENSIONS. Please LMK. tanks Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 20:06:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 20:06:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJVCE-0007Va-QH; Wed, 03 Oct 2012 20:05:30 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJVCD-0007VV-I2 for xen-devel@lists.xen.org; Wed, 03 Oct 2012 20:05:29 +0000 Received: from [85.158.143.35:43783] by server-3.bemta-4.messagelabs.com id 67/7A-10986-88A9C605; Wed, 03 Oct 2012 20:05:28 +0000 X-Env-Sender: peter.maloney@brockmann-consult.de X-Msg-Ref: server-3.tower-21.messagelabs.com!1349294726!13225184!1 X-Originating-IP: [212.227.17.9] X-SpamReason: No, hits=1.4 required=7.0 tests=sa_preprocessor: QmFkIElQOiAyMTIuMjI3LjE3LjkgPT4gODI0NTA=\n,sa_preprocessor: QmFkIElQOiAyMTIuMjI3LjE3LjkgPT4gODI0NTA=\n, BODY_RANDOM_LONG, HTML_20_30, HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8144 invoked from network); 3 Oct 2012 20:05:26 -0000 Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de) (212.227.17.9) by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 20:05:26 -0000 Received: from [192.168.179.201] (hmbg-4d06dfd3.pool.mediaWays.net [77.6.223.211]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0M2XRt-1TaDEO1dLR-00sjNx; Wed, 03 Oct 2012 22:05:25 +0200 Message-ID: <506C9A84.5040408@brockmann-consult.de> Date: Wed, 03 Oct 2012 22:05:24 +0200 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120825 Thunderbird/15.0 MIME-Version: 1.0 To: xen-devel@lists.xen.org References: <501F98A1.4070806@brockmann-consult.de> <501FB9060200007800092D4E@nat28.tlf.novell.com> <5020C2DE.304@brockmann-consult.de> <50294D4B.9050405@brockmann-consult.de> <50296AC2.80600@brockmann-consult.de> <506C73A3.2030605@brockmann-consult.de> In-Reply-To: <506C73A3.2030605@brockmann-consult.de> X-Provags-ID: V02:K0:ixb58iqva4+8FH7YLoKC/dMfb1FVpm0R28PfvABkp3R kHLoN22TwCRs1vxvpHqXNGbXvuXvjrqYBzUyqY6lubC/89Rp5q M5UwNJmnTG8BuwoWBEzrnAqsh+VjEV675HeGnWv0z/ZWYoVSZ0 dGTs1zujea39ckl+rE0RG+MPA8RYPulS5i+fkSw/Zi5n9AgG4X CsU5so6wiETLr+COvMEQz5DE7kVOANi0dBjvCzaGFBLRhlAY85 oYMCp3y4JyP4o5oSXOJPB+z0v1JQcFHOiqRtln+VdRghmpqi9D Z7CmYmLg+Q4ewz0ImdpKMU3DazlGBebcDazujrx/AYHzHBJumr 4XaQshFcjs5heK7pmACyxsIQUlggpQ0XZCOvMduTAY65fwLKaH H99vx2XXDTDIA== Subject: Re: [Xen-devel] 4.1.2 very slow without upstream patches, but fast with them, also 4.2 very slow X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7936935401473163584==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a multi-part message in MIME format. --===============7936935401473163584== Content-Type: multipart/alternative; boundary="------------080202040004090906000301" This is a multi-part message in MIME format. --------------080202040004090906000301 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I also tested: modprobe xen-acpi-processor as suggeted by pasik on freenode. This didn't help (tested with xen 4.3-unstable) And then also with 4.3-unstable, I tested 64 bit *windows8* preview, *which seemed to run fast. * So I guess this issue is specific to windows xp, or 32 bit domu in a 64 bit machine. On 10/03/2012 07:19 PM, Peter Maloney wrote: > I ran some new tests... 4.1.2 with different patches, and > 4.3-unstable.Some details are below. > > At some point in the future, I will try some builds between 4.1 and 4.2 > (but at the moment am not sure how with mercurial or what options I have). > > > > 4.1.2 > > short version: dom0 works fine; domu ran only in a few builds and works fine > > long version: > I tested 4.1.2 again, with a few selections of patches (first n patches > where n was; 0, 23, 46, 93, 186, 279; there are 373 patches in total). > All of them ran fast in dom0, unlike when I first started this mailing > list thread, and the builds that would run my windows domu ran it fast. > So probably there was something strange with the kernel I had before, > which was probably 3.4.4; now I'm using something like 3.5.x (cmason's > linux-btrfs repository, for-linus branch) > > > > 4.3-unstable > > short version: dom0 works fine; domu always runs terribly slow (which > leads me to wanting to test what changed between 4.1 and 4.2) > > > long version: > I pulled the latest source, built it, and dom0 is fast just like with > 4.2, but windows hvm domu is still terribly slow, and (with 7 vcpus), it > consumes between 500-650% while booting and a few minutes afterwards. > With 4 CPUs, I would expect between 350-550% from observations with 4.2 > but didn't test other cpu counts with 4.3. (another side note, with > 4.1.3 which is normally fast, it will run slow like 4.2 and 4.3 if I set > cpus="2,4,6,8" instead of cpus=4) > > xentop - 11:32:44 Xen 4.3-unstable > 2 domains: 2 running, 0 blocked, 0 paused, 0 crashed, 0 dying, 0 shutdown > Mem: 16757972k total, 16739788k used, 18184k free CPUs: 8 @ 4499MHz > NAME STATE CPU(sec) CPU(%) MEM(k) MEM(%) MAXMEM(k) > MAXMEM(%) VCPUS NETS NETTX(k) NETRX(k) VBDS VBD_OO VBD_RD VBD_WR > VBD_RSECT VBD_WSECT SSID > Domain-0 -----r 784 27.2 12314624 73.5 12582912 > 75.1 8 0 0 0 0 0 0 > 0 0 0 0 > windowsxp2 -----r 3244 637.1 4197220 25.0 4198400 > 25.1 7 1 344 56 2 0 14381 6054 > 651283 122280 0 > > And then after idling for 10 minutes, it is under 200% > > xentop - 11:35:29 Xen 4.3-unstable > 2 domains: 1 running, 1 blocked, 0 paused, 0 crashed, 0 dying, 0 shutdown > Mem: 16757972k total, 16739788k used, 18184k free CPUs: 8 @ 4499MHz > NAME STATE CPU(sec) CPU(%) MEM(k) MEM(%) MAXMEM(k) > MAXMEM(%) VCPUS NETS NETTX(k) NETRX(k) VBDS VBD_OO VBD_RD VBD_WR > VBD_RSECT VBD_WSECT SSID > Domain-0 -----r 839 42.4 12314624 73.5 12582912 > 75.1 8 0 0 0 0 0 0 > 0 0 0 0 > windowsxp2 --b--- 3583 114.1 4197220 25.0 4198400 > 25.1 7 1 426 66 2 0 14408 7501 > 651853 180372 0 > > > And then when it is in use (just loading a youtube page), it is up high > again. > > xentop - 11:37:17 Xen 4.3-unstable > 2 domains: 2 running, 0 blocked, 0 paused, 0 crashed, 0 dying, 0 shutdown > Mem: 16757972k total, 16739788k used, 18184k free CPUs: 8 @ 4499MHz > NAME STATE CPU(sec) CPU(%) MEM(k) MEM(%) MAXMEM(k) > MAXMEM(%) VCPUS NETS NETTX(k) NETRX(k) VBDS VBD_OO VBD_RD VBD_WR > VBD_RSECT VBD_WSECT SSID > Domain-0 -----r 875 37.8 12314624 73.5 12582912 > 75.1 8 0 0 0 0 0 0 > 0 0 0 0 > windowsxp2 -----r 3945 529.7 4197220 25.0 4198400 > 25.1 7 1 4885 201 2 0 17096 8168 > 788573 198458 0 > > > And also if I shut down the vm while it is at 600% cpu, it takes > something like 10-15 minutes to shut down. > > and CPU temperature is only 45 degrees during the high cpu usage, and > 26-32 degrees when it's 0%, so whatever CPU waste it's doing is not > generating much heat. With 4.1.3, while a game is open, it reports 200% > cpu, and the temperature is around 50 degrees. I have a huge CPU cooler; > it's overclocked; and normally it runs about 55-70 degrees using 8 cores > depending on the task. > > I tested with apic=0 and apic=1 (apic=1 will run windows very slow in > 4.1.x, so I have been using apic=0 normally) > > > > > > > > On 08/13/2012 10:59 PM, Peter Maloney wrote: >> I also tested 4.1.3, which is fast, and both USB and graphics >> passthrough work, but "xl create" gave this message the first time I >> started the vm (but not the second): >> >> libxl: error: libxl_pci.c:750:libxl_device_pci_reset The kernel doesn't >> support reset from sysfs for PCI device 0000:00:12.0 >> >> >> 0000:00:12.0 is a USB device, which works in the VM. >> >> peter:/opt # lspci -v | grep 00:12.0 >> 00:12.0 USB Controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB OHCI0 >> Controller (prog-if 10 [OHCI]) >> >> >> On 08/13/2012 08:54 PM, Peter Maloney wrote: >>> So... did my 4.2-unstable test, using a fresh pull from yesterday; dom0 >>> is normal fast (unlike previous tests), and domU is ultra slow, but >>> actually boots, and graphics card passthrough works without any patches, >>> and so does the USB keyboard, but USB mouse passthrough doesn't work. >>> >>> >>> On 08/07/2012 09:25 AM, Peter Maloney wrote: >>>>> That still won't tell us which patches you did apply. >>>> I applied no patches and tested, and the result was slow. And then >>>> applied all patches, and it was fast. I didn't try figuring out which >>>> one it was. >>>> >>>> >>>> So I guess I'll try: >>>> - the latest unstable 4.2 >>>> - the 4.1.3-rc (Which includes the patch Malcolm suggested) >>>> - and my rpm source with half patches, 3/4 of them, etc. binary search >>>> style to see which patch(es) changed the performance. But this means I >>>> won't be able to narrow it down to a single patch, but only the point in >>>> the long list where the most dramatic change happens, possibly depending >>>> on many previous patches. >>>> >>>> Thanks so far, guys. >>>> >>>> >>>> On 08/06/2012 12:31 PM, Jan Beulich wrote: >>>>>>>> On 06.08.12 at 12:12, Peter Maloney wrote: >>>>>> my AMD FX-8150 system with vanilla source code is super slow, both the >>>>>> dom0 and domUs. However, after I merge the upstream patches I found in >>>>>> the openSUSE rpm, it runs normally. >>>>> I'd be very surprised if you really just took the upstream patches, >>>>> and the result was better than 4.2-rc1. After all, what upstream >>>>> means is that they were taken from -unstable. >>>>> >>>>>> I tried 4.2-unstable and it was the same. There was no rc1 when I tested >>>>>> it about 1.5 weeks ago. And 4.2 has the same horrible performance, and >>>>>> obviously those patches won't work any more since the 4.2 code looks >>>>>> completely reorganized, so I'm stuck with 4.1.2 >>>>> Obviously the upstream patches can't be applied to something >>>>> that already has all those changes. Other patches, of which we >>>>> unfortunately have quite a few, would be a different story. >>>>> >>>>>> Here is the rpm I was using at the time: >>>>>> http://download.opensuse.org/update/12.1/src/xen-4.1.2_16-1.7.1.src.rpm >>>>>> >>>>>> To see the list of the patches and what order to apply them, see the >>>>>> spec file. >>>>> That still won't tell us which patches you did apply. >>>>> >>>>>> Please make sure this performance issue is fixed for the 4.2 release. >>>>>> And I would be happy to test whatever files you send me. >>>>> The sort of report you're doing isn't that helpful. What would >>>>> help is if you could narrow down which patch(es) it is that >>>>> make things so much better. Giving 4.1.3-rc a try might also >>>>> be worthwhile, albeit I would hope we don't have a regression >>>>> in 4.2.0-rc compared to 4.1.3-rc... >>>>> >>>>> Jan >>>>> >>>>> >>>>> _______________________________________________ >>>>> Xen-devel mailing list >>>>> Xen-devel@lists.xen.org >>>>> http://lists.xen.org/xen-devel >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xen.org >>> http://lists.xen.org/xen-devel >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel --------------080202040004090906000301 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
I also tested:
modprobe xen-acpi-processor

as suggeted by pasik on freenode. This didn't help (tested with xen 4.3-unstable)

And then also with 4.3-unstable, I tested 64 bit windows8 preview, which seemed to run fast.

So I guess this issue is specific to windows xp, or 32 bit domu in a 64 bit machine.


On 10/03/2012 07:19 PM, Peter Maloney wrote:
I ran some new tests... 4.1.2 with different patches, and
4.3-unstable.Some details are below.

At some point in the future, I will try some builds between 4.1 and 4.2
(but at the moment am not sure how with mercurial or what options I have).



4.1.2

short version: dom0 works fine; domu ran only in a few builds and works fine

long version:
I tested 4.1.2 again, with a few selections of patches (first n patches
where n was; 0, 23, 46, 93, 186, 279; there are 373 patches in total).
All of them ran fast in dom0, unlike when I first started this mailing
list thread, and the builds that would run my windows domu ran it fast.
So probably there was something strange with the kernel I had before,
which was probably 3.4.4; now I'm using something like 3.5.x (cmason's
linux-btrfs repository, for-linus branch)



4.3-unstable

short version: dom0 works fine; domu always runs terribly slow (which
leads me to wanting to test what changed between 4.1 and 4.2)


long version:
I pulled the latest source, built it, and dom0 is fast just like with
4.2, but windows hvm domu is still terribly slow, and (with 7 vcpus), it
consumes between 500-650% while booting and a few minutes afterwards.
With 4 CPUs, I would expect between 350-550% from observations with 4.2
but didn't test other cpu counts with 4.3. (another side note,  with
4.1.3 which is normally fast, it will run slow like 4.2 and 4.3 if I set
cpus="2,4,6,8" instead of cpus=4)

xentop - 11:32:44   Xen 4.3-unstable
2 domains: 2 running, 0 blocked, 0 paused, 0 crashed, 0 dying, 0 shutdown
Mem: 16757972k total, 16739788k used, 18184k free    CPUs: 8 @ 4499MHz
      NAME  STATE   CPU(sec) CPU(%)     MEM(k) MEM(%)  MAXMEM(k)
MAXMEM(%) VCPUS NETS NETTX(k) NETRX(k) VBDS   VBD_OO   VBD_RD   VBD_WR 
VBD_RSECT  VBD_WSECT SSID
  Domain-0 -----r        784   27.2   12314624   73.5   12582912     
75.1     8    0        0        0    0        0        0       
0          0          0    0
windowsxp2 -----r       3244  637.1    4197220   25.0    4198400     
25.1     7    1      344       56    2        0    14381     6054    
651283     122280    0

And then after idling for 10 minutes, it is under 200%

xentop - 11:35:29   Xen 4.3-unstable
2 domains: 1 running, 1 blocked, 0 paused, 0 crashed, 0 dying, 0 shutdown
Mem: 16757972k total, 16739788k used, 18184k free    CPUs: 8 @ 4499MHz
      NAME  STATE   CPU(sec) CPU(%)     MEM(k) MEM(%)  MAXMEM(k)
MAXMEM(%) VCPUS NETS NETTX(k) NETRX(k) VBDS   VBD_OO   VBD_RD   VBD_WR 
VBD_RSECT  VBD_WSECT SSID
  Domain-0 -----r        839   42.4   12314624   73.5   12582912     
75.1     8    0        0        0    0        0        0       
0          0          0    0
windowsxp2 --b---       3583  114.1    4197220   25.0    4198400     
25.1     7    1      426       66    2        0    14408     7501    
651853     180372    0


And then when it is in use (just loading a youtube page), it is up high
again.

xentop - 11:37:17   Xen 4.3-unstable
2 domains: 2 running, 0 blocked, 0 paused, 0 crashed, 0 dying, 0 shutdown
Mem: 16757972k total, 16739788k used, 18184k free    CPUs: 8 @ 4499MHz
      NAME  STATE   CPU(sec) CPU(%)     MEM(k) MEM(%)  MAXMEM(k)
MAXMEM(%) VCPUS NETS NETTX(k) NETRX(k) VBDS   VBD_OO   VBD_RD   VBD_WR 
VBD_RSECT  VBD_WSECT SSID
  Domain-0 -----r        875   37.8   12314624   73.5   12582912     
75.1     8    0        0        0    0        0        0       
0          0          0    0
windowsxp2 -----r       3945  529.7    4197220   25.0    4198400     
25.1     7    1     4885      201    2        0    17096     8168    
788573     198458    0


And also if I shut down the vm while it is at 600% cpu, it takes
something like 10-15 minutes to shut down.

and CPU temperature is only 45 degrees during the high cpu usage, and
26-32 degrees when it's 0%, so whatever CPU waste it's doing is not
generating much heat. With 4.1.3, while a game is open, it reports 200%
cpu, and the temperature is around 50 degrees. I have a huge CPU cooler;
it's overclocked; and normally it runs about 55-70 degrees using 8 cores
depending on the task.

I tested with apic=0 and apic=1 (apic=1 will run windows very slow in
4.1.x, so I have been using apic=0 normally)







On 08/13/2012 10:59 PM, Peter Maloney wrote:

I also tested 4.1.3, which is fast, and both USB and graphics
passthrough work, but "xl create" gave this message the first time I
started the vm (but not the second):

libxl: error: libxl_pci.c:750:libxl_device_pci_reset The kernel doesn't
support reset from sysfs for PCI device 0000:00:12.0


0000:00:12.0 is a USB device, which works in the VM.

peter:/opt # lspci -v | grep 00:12.0
00:12.0 USB Controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB OHCI0
Controller (prog-if 10 [OHCI])


On 08/13/2012 08:54 PM, Peter Maloney wrote:

So... did my 4.2-unstable test, using a fresh pull from yesterday; dom0
is normal fast (unlike previous tests), and domU is ultra slow, but
actually boots, and graphics card passthrough works without any patches,
and so does the USB keyboard, but USB mouse passthrough doesn't work.


On 08/07/2012 09:25 AM, Peter Maloney wrote:

That still won't tell us which patches you did apply.

I applied no patches and tested, and the result was slow. And then
applied all patches, and it was fast. I didn't try figuring out which
one it was.


So I guess I'll try:
- the latest unstable 4.2
- the 4.1.3-rc (Which includes the patch Malcolm suggested)
- and my rpm source with half patches, 3/4 of them, etc. binary search
style to see which patch(es) changed the performance. But this means I
won't be able to narrow it down to a single patch, but only the point in
the long list where the most dramatic change happens, possibly depending
on many previous patches.

Thanks so far, guys.


On 08/06/2012 12:31 PM, Jan Beulich wrote:

On 06.08.12 at 12:12, Peter Maloney <peter.maloney@brockmann-consult.de> wrote:

my AMD FX-8150 system with vanilla source code is super slow, both the
dom0 and domUs. However, after I merge the upstream patches I found in
the openSUSE rpm, it runs normally.

I'd be very surprised if you really just took the upstream patches,
and the result was better than 4.2-rc1. After all, what upstream
means is that they were taken from -unstable.


I tried 4.2-unstable and it was the same. There was no rc1 when I tested
it about 1.5 weeks ago. And 4.2 has the same horrible performance, and
obviously those patches won't work any more since the 4.2 code looks
completely reorganized, so I'm stuck with 4.1.2

Obviously the upstream patches can't be applied to something
that already has all those changes. Other patches, of which we
unfortunately have quite a few, would be a different story.


Here is the rpm I was using at the time:
http://download.opensuse.org/update/12.1/src/xen-4.1.2_16-1.7.1.src.rpm 

To see the list of the patches and what order to apply them, see the
spec file.

That still won't tell us which patches you did apply.


Please make sure this performance issue is fixed for the 4.2 release.
And I would be happy to test whatever files you send me.

The sort of report you're doing isn't that helpful. What would
help is if you could narrow down which patch(es) it is that
make things so much better. Giving 4.1.3-rc a try might also
be worthwhile, albeit I would hope we don't have a regression
in 4.2.0-rc compared to 4.1.3-rc...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------080202040004090906000301-- --===============7936935401473163584== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============7936935401473163584==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 20:06:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 20:06:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJVCE-0007Va-QH; Wed, 03 Oct 2012 20:05:30 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJVCD-0007VV-I2 for xen-devel@lists.xen.org; Wed, 03 Oct 2012 20:05:29 +0000 Received: from [85.158.143.35:43783] by server-3.bemta-4.messagelabs.com id 67/7A-10986-88A9C605; Wed, 03 Oct 2012 20:05:28 +0000 X-Env-Sender: peter.maloney@brockmann-consult.de X-Msg-Ref: server-3.tower-21.messagelabs.com!1349294726!13225184!1 X-Originating-IP: [212.227.17.9] X-SpamReason: No, hits=1.4 required=7.0 tests=sa_preprocessor: QmFkIElQOiAyMTIuMjI3LjE3LjkgPT4gODI0NTA=\n,sa_preprocessor: QmFkIElQOiAyMTIuMjI3LjE3LjkgPT4gODI0NTA=\n, BODY_RANDOM_LONG, HTML_20_30, HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8144 invoked from network); 3 Oct 2012 20:05:26 -0000 Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de) (212.227.17.9) by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 20:05:26 -0000 Received: from [192.168.179.201] (hmbg-4d06dfd3.pool.mediaWays.net [77.6.223.211]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0M2XRt-1TaDEO1dLR-00sjNx; Wed, 03 Oct 2012 22:05:25 +0200 Message-ID: <506C9A84.5040408@brockmann-consult.de> Date: Wed, 03 Oct 2012 22:05:24 +0200 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120825 Thunderbird/15.0 MIME-Version: 1.0 To: xen-devel@lists.xen.org References: <501F98A1.4070806@brockmann-consult.de> <501FB9060200007800092D4E@nat28.tlf.novell.com> <5020C2DE.304@brockmann-consult.de> <50294D4B.9050405@brockmann-consult.de> <50296AC2.80600@brockmann-consult.de> <506C73A3.2030605@brockmann-consult.de> In-Reply-To: <506C73A3.2030605@brockmann-consult.de> X-Provags-ID: V02:K0:ixb58iqva4+8FH7YLoKC/dMfb1FVpm0R28PfvABkp3R kHLoN22TwCRs1vxvpHqXNGbXvuXvjrqYBzUyqY6lubC/89Rp5q M5UwNJmnTG8BuwoWBEzrnAqsh+VjEV675HeGnWv0z/ZWYoVSZ0 dGTs1zujea39ckl+rE0RG+MPA8RYPulS5i+fkSw/Zi5n9AgG4X CsU5so6wiETLr+COvMEQz5DE7kVOANi0dBjvCzaGFBLRhlAY85 oYMCp3y4JyP4o5oSXOJPB+z0v1JQcFHOiqRtln+VdRghmpqi9D Z7CmYmLg+Q4ewz0ImdpKMU3DazlGBebcDazujrx/AYHzHBJumr 4XaQshFcjs5heK7pmACyxsIQUlggpQ0XZCOvMduTAY65fwLKaH H99vx2XXDTDIA== Subject: Re: [Xen-devel] 4.1.2 very slow without upstream patches, but fast with them, also 4.2 very slow X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7936935401473163584==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a multi-part message in MIME format. --===============7936935401473163584== Content-Type: multipart/alternative; boundary="------------080202040004090906000301" This is a multi-part message in MIME format. --------------080202040004090906000301 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I also tested: modprobe xen-acpi-processor as suggeted by pasik on freenode. This didn't help (tested with xen 4.3-unstable) And then also with 4.3-unstable, I tested 64 bit *windows8* preview, *which seemed to run fast. * So I guess this issue is specific to windows xp, or 32 bit domu in a 64 bit machine. On 10/03/2012 07:19 PM, Peter Maloney wrote: > I ran some new tests... 4.1.2 with different patches, and > 4.3-unstable.Some details are below. > > At some point in the future, I will try some builds between 4.1 and 4.2 > (but at the moment am not sure how with mercurial or what options I have). > > > > 4.1.2 > > short version: dom0 works fine; domu ran only in a few builds and works fine > > long version: > I tested 4.1.2 again, with a few selections of patches (first n patches > where n was; 0, 23, 46, 93, 186, 279; there are 373 patches in total). > All of them ran fast in dom0, unlike when I first started this mailing > list thread, and the builds that would run my windows domu ran it fast. > So probably there was something strange with the kernel I had before, > which was probably 3.4.4; now I'm using something like 3.5.x (cmason's > linux-btrfs repository, for-linus branch) > > > > 4.3-unstable > > short version: dom0 works fine; domu always runs terribly slow (which > leads me to wanting to test what changed between 4.1 and 4.2) > > > long version: > I pulled the latest source, built it, and dom0 is fast just like with > 4.2, but windows hvm domu is still terribly slow, and (with 7 vcpus), it > consumes between 500-650% while booting and a few minutes afterwards. > With 4 CPUs, I would expect between 350-550% from observations with 4.2 > but didn't test other cpu counts with 4.3. (another side note, with > 4.1.3 which is normally fast, it will run slow like 4.2 and 4.3 if I set > cpus="2,4,6,8" instead of cpus=4) > > xentop - 11:32:44 Xen 4.3-unstable > 2 domains: 2 running, 0 blocked, 0 paused, 0 crashed, 0 dying, 0 shutdown > Mem: 16757972k total, 16739788k used, 18184k free CPUs: 8 @ 4499MHz > NAME STATE CPU(sec) CPU(%) MEM(k) MEM(%) MAXMEM(k) > MAXMEM(%) VCPUS NETS NETTX(k) NETRX(k) VBDS VBD_OO VBD_RD VBD_WR > VBD_RSECT VBD_WSECT SSID > Domain-0 -----r 784 27.2 12314624 73.5 12582912 > 75.1 8 0 0 0 0 0 0 > 0 0 0 0 > windowsxp2 -----r 3244 637.1 4197220 25.0 4198400 > 25.1 7 1 344 56 2 0 14381 6054 > 651283 122280 0 > > And then after idling for 10 minutes, it is under 200% > > xentop - 11:35:29 Xen 4.3-unstable > 2 domains: 1 running, 1 blocked, 0 paused, 0 crashed, 0 dying, 0 shutdown > Mem: 16757972k total, 16739788k used, 18184k free CPUs: 8 @ 4499MHz > NAME STATE CPU(sec) CPU(%) MEM(k) MEM(%) MAXMEM(k) > MAXMEM(%) VCPUS NETS NETTX(k) NETRX(k) VBDS VBD_OO VBD_RD VBD_WR > VBD_RSECT VBD_WSECT SSID > Domain-0 -----r 839 42.4 12314624 73.5 12582912 > 75.1 8 0 0 0 0 0 0 > 0 0 0 0 > windowsxp2 --b--- 3583 114.1 4197220 25.0 4198400 > 25.1 7 1 426 66 2 0 14408 7501 > 651853 180372 0 > > > And then when it is in use (just loading a youtube page), it is up high > again. > > xentop - 11:37:17 Xen 4.3-unstable > 2 domains: 2 running, 0 blocked, 0 paused, 0 crashed, 0 dying, 0 shutdown > Mem: 16757972k total, 16739788k used, 18184k free CPUs: 8 @ 4499MHz > NAME STATE CPU(sec) CPU(%) MEM(k) MEM(%) MAXMEM(k) > MAXMEM(%) VCPUS NETS NETTX(k) NETRX(k) VBDS VBD_OO VBD_RD VBD_WR > VBD_RSECT VBD_WSECT SSID > Domain-0 -----r 875 37.8 12314624 73.5 12582912 > 75.1 8 0 0 0 0 0 0 > 0 0 0 0 > windowsxp2 -----r 3945 529.7 4197220 25.0 4198400 > 25.1 7 1 4885 201 2 0 17096 8168 > 788573 198458 0 > > > And also if I shut down the vm while it is at 600% cpu, it takes > something like 10-15 minutes to shut down. > > and CPU temperature is only 45 degrees during the high cpu usage, and > 26-32 degrees when it's 0%, so whatever CPU waste it's doing is not > generating much heat. With 4.1.3, while a game is open, it reports 200% > cpu, and the temperature is around 50 degrees. I have a huge CPU cooler; > it's overclocked; and normally it runs about 55-70 degrees using 8 cores > depending on the task. > > I tested with apic=0 and apic=1 (apic=1 will run windows very slow in > 4.1.x, so I have been using apic=0 normally) > > > > > > > > On 08/13/2012 10:59 PM, Peter Maloney wrote: >> I also tested 4.1.3, which is fast, and both USB and graphics >> passthrough work, but "xl create" gave this message the first time I >> started the vm (but not the second): >> >> libxl: error: libxl_pci.c:750:libxl_device_pci_reset The kernel doesn't >> support reset from sysfs for PCI device 0000:00:12.0 >> >> >> 0000:00:12.0 is a USB device, which works in the VM. >> >> peter:/opt # lspci -v | grep 00:12.0 >> 00:12.0 USB Controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB OHCI0 >> Controller (prog-if 10 [OHCI]) >> >> >> On 08/13/2012 08:54 PM, Peter Maloney wrote: >>> So... did my 4.2-unstable test, using a fresh pull from yesterday; dom0 >>> is normal fast (unlike previous tests), and domU is ultra slow, but >>> actually boots, and graphics card passthrough works without any patches, >>> and so does the USB keyboard, but USB mouse passthrough doesn't work. >>> >>> >>> On 08/07/2012 09:25 AM, Peter Maloney wrote: >>>>> That still won't tell us which patches you did apply. >>>> I applied no patches and tested, and the result was slow. And then >>>> applied all patches, and it was fast. I didn't try figuring out which >>>> one it was. >>>> >>>> >>>> So I guess I'll try: >>>> - the latest unstable 4.2 >>>> - the 4.1.3-rc (Which includes the patch Malcolm suggested) >>>> - and my rpm source with half patches, 3/4 of them, etc. binary search >>>> style to see which patch(es) changed the performance. But this means I >>>> won't be able to narrow it down to a single patch, but only the point in >>>> the long list where the most dramatic change happens, possibly depending >>>> on many previous patches. >>>> >>>> Thanks so far, guys. >>>> >>>> >>>> On 08/06/2012 12:31 PM, Jan Beulich wrote: >>>>>>>> On 06.08.12 at 12:12, Peter Maloney wrote: >>>>>> my AMD FX-8150 system with vanilla source code is super slow, both the >>>>>> dom0 and domUs. However, after I merge the upstream patches I found in >>>>>> the openSUSE rpm, it runs normally. >>>>> I'd be very surprised if you really just took the upstream patches, >>>>> and the result was better than 4.2-rc1. After all, what upstream >>>>> means is that they were taken from -unstable. >>>>> >>>>>> I tried 4.2-unstable and it was the same. There was no rc1 when I tested >>>>>> it about 1.5 weeks ago. And 4.2 has the same horrible performance, and >>>>>> obviously those patches won't work any more since the 4.2 code looks >>>>>> completely reorganized, so I'm stuck with 4.1.2 >>>>> Obviously the upstream patches can't be applied to something >>>>> that already has all those changes. Other patches, of which we >>>>> unfortunately have quite a few, would be a different story. >>>>> >>>>>> Here is the rpm I was using at the time: >>>>>> http://download.opensuse.org/update/12.1/src/xen-4.1.2_16-1.7.1.src.rpm >>>>>> >>>>>> To see the list of the patches and what order to apply them, see the >>>>>> spec file. >>>>> That still won't tell us which patches you did apply. >>>>> >>>>>> Please make sure this performance issue is fixed for the 4.2 release. >>>>>> And I would be happy to test whatever files you send me. >>>>> The sort of report you're doing isn't that helpful. What would >>>>> help is if you could narrow down which patch(es) it is that >>>>> make things so much better. Giving 4.1.3-rc a try might also >>>>> be worthwhile, albeit I would hope we don't have a regression >>>>> in 4.2.0-rc compared to 4.1.3-rc... >>>>> >>>>> Jan >>>>> >>>>> >>>>> _______________________________________________ >>>>> Xen-devel mailing list >>>>> Xen-devel@lists.xen.org >>>>> http://lists.xen.org/xen-devel >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xen.org >>> http://lists.xen.org/xen-devel >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel --------------080202040004090906000301 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
I also tested:
modprobe xen-acpi-processor

as suggeted by pasik on freenode. This didn't help (tested with xen 4.3-unstable)

And then also with 4.3-unstable, I tested 64 bit windows8 preview, which seemed to run fast.

So I guess this issue is specific to windows xp, or 32 bit domu in a 64 bit machine.


On 10/03/2012 07:19 PM, Peter Maloney wrote:
I ran some new tests... 4.1.2 with different patches, and
4.3-unstable.Some details are below.

At some point in the future, I will try some builds between 4.1 and 4.2
(but at the moment am not sure how with mercurial or what options I have).



4.1.2

short version: dom0 works fine; domu ran only in a few builds and works fine

long version:
I tested 4.1.2 again, with a few selections of patches (first n patches
where n was; 0, 23, 46, 93, 186, 279; there are 373 patches in total).
All of them ran fast in dom0, unlike when I first started this mailing
list thread, and the builds that would run my windows domu ran it fast.
So probably there was something strange with the kernel I had before,
which was probably 3.4.4; now I'm using something like 3.5.x (cmason's
linux-btrfs repository, for-linus branch)



4.3-unstable

short version: dom0 works fine; domu always runs terribly slow (which
leads me to wanting to test what changed between 4.1 and 4.2)


long version:
I pulled the latest source, built it, and dom0 is fast just like with
4.2, but windows hvm domu is still terribly slow, and (with 7 vcpus), it
consumes between 500-650% while booting and a few minutes afterwards.
With 4 CPUs, I would expect between 350-550% from observations with 4.2
but didn't test other cpu counts with 4.3. (another side note,  with
4.1.3 which is normally fast, it will run slow like 4.2 and 4.3 if I set
cpus="2,4,6,8" instead of cpus=4)

xentop - 11:32:44   Xen 4.3-unstable
2 domains: 2 running, 0 blocked, 0 paused, 0 crashed, 0 dying, 0 shutdown
Mem: 16757972k total, 16739788k used, 18184k free    CPUs: 8 @ 4499MHz
      NAME  STATE   CPU(sec) CPU(%)     MEM(k) MEM(%)  MAXMEM(k)
MAXMEM(%) VCPUS NETS NETTX(k) NETRX(k) VBDS   VBD_OO   VBD_RD   VBD_WR 
VBD_RSECT  VBD_WSECT SSID
  Domain-0 -----r        784   27.2   12314624   73.5   12582912     
75.1     8    0        0        0    0        0        0       
0          0          0    0
windowsxp2 -----r       3244  637.1    4197220   25.0    4198400     
25.1     7    1      344       56    2        0    14381     6054    
651283     122280    0

And then after idling for 10 minutes, it is under 200%

xentop - 11:35:29   Xen 4.3-unstable
2 domains: 1 running, 1 blocked, 0 paused, 0 crashed, 0 dying, 0 shutdown
Mem: 16757972k total, 16739788k used, 18184k free    CPUs: 8 @ 4499MHz
      NAME  STATE   CPU(sec) CPU(%)     MEM(k) MEM(%)  MAXMEM(k)
MAXMEM(%) VCPUS NETS NETTX(k) NETRX(k) VBDS   VBD_OO   VBD_RD   VBD_WR 
VBD_RSECT  VBD_WSECT SSID
  Domain-0 -----r        839   42.4   12314624   73.5   12582912     
75.1     8    0        0        0    0        0        0       
0          0          0    0
windowsxp2 --b---       3583  114.1    4197220   25.0    4198400     
25.1     7    1      426       66    2        0    14408     7501    
651853     180372    0


And then when it is in use (just loading a youtube page), it is up high
again.

xentop - 11:37:17   Xen 4.3-unstable
2 domains: 2 running, 0 blocked, 0 paused, 0 crashed, 0 dying, 0 shutdown
Mem: 16757972k total, 16739788k used, 18184k free    CPUs: 8 @ 4499MHz
      NAME  STATE   CPU(sec) CPU(%)     MEM(k) MEM(%)  MAXMEM(k)
MAXMEM(%) VCPUS NETS NETTX(k) NETRX(k) VBDS   VBD_OO   VBD_RD   VBD_WR 
VBD_RSECT  VBD_WSECT SSID
  Domain-0 -----r        875   37.8   12314624   73.5   12582912     
75.1     8    0        0        0    0        0        0       
0          0          0    0
windowsxp2 -----r       3945  529.7    4197220   25.0    4198400     
25.1     7    1     4885      201    2        0    17096     8168    
788573     198458    0


And also if I shut down the vm while it is at 600% cpu, it takes
something like 10-15 minutes to shut down.

and CPU temperature is only 45 degrees during the high cpu usage, and
26-32 degrees when it's 0%, so whatever CPU waste it's doing is not
generating much heat. With 4.1.3, while a game is open, it reports 200%
cpu, and the temperature is around 50 degrees. I have a huge CPU cooler;
it's overclocked; and normally it runs about 55-70 degrees using 8 cores
depending on the task.

I tested with apic=0 and apic=1 (apic=1 will run windows very slow in
4.1.x, so I have been using apic=0 normally)







On 08/13/2012 10:59 PM, Peter Maloney wrote:

I also tested 4.1.3, which is fast, and both USB and graphics
passthrough work, but "xl create" gave this message the first time I
started the vm (but not the second):

libxl: error: libxl_pci.c:750:libxl_device_pci_reset The kernel doesn't
support reset from sysfs for PCI device 0000:00:12.0


0000:00:12.0 is a USB device, which works in the VM.

peter:/opt # lspci -v | grep 00:12.0
00:12.0 USB Controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB OHCI0
Controller (prog-if 10 [OHCI])


On 08/13/2012 08:54 PM, Peter Maloney wrote:

So... did my 4.2-unstable test, using a fresh pull from yesterday; dom0
is normal fast (unlike previous tests), and domU is ultra slow, but
actually boots, and graphics card passthrough works without any patches,
and so does the USB keyboard, but USB mouse passthrough doesn't work.


On 08/07/2012 09:25 AM, Peter Maloney wrote:

That still won't tell us which patches you did apply.

I applied no patches and tested, and the result was slow. And then
applied all patches, and it was fast. I didn't try figuring out which
one it was.


So I guess I'll try:
- the latest unstable 4.2
- the 4.1.3-rc (Which includes the patch Malcolm suggested)
- and my rpm source with half patches, 3/4 of them, etc. binary search
style to see which patch(es) changed the performance. But this means I
won't be able to narrow it down to a single patch, but only the point in
the long list where the most dramatic change happens, possibly depending
on many previous patches.

Thanks so far, guys.


On 08/06/2012 12:31 PM, Jan Beulich wrote:

On 06.08.12 at 12:12, Peter Maloney <peter.maloney@brockmann-consult.de> wrote:

my AMD FX-8150 system with vanilla source code is super slow, both the
dom0 and domUs. However, after I merge the upstream patches I found in
the openSUSE rpm, it runs normally.

I'd be very surprised if you really just took the upstream patches,
and the result was better than 4.2-rc1. After all, what upstream
means is that they were taken from -unstable.


I tried 4.2-unstable and it was the same. There was no rc1 when I tested
it about 1.5 weeks ago. And 4.2 has the same horrible performance, and
obviously those patches won't work any more since the 4.2 code looks
completely reorganized, so I'm stuck with 4.1.2

Obviously the upstream patches can't be applied to something
that already has all those changes. Other patches, of which we
unfortunately have quite a few, would be a different story.


Here is the rpm I was using at the time:
http://download.opensuse.org/update/12.1/src/xen-4.1.2_16-1.7.1.src.rpm 

To see the list of the patches and what order to apply them, see the
spec file.

That still won't tell us which patches you did apply.


Please make sure this performance issue is fixed for the 4.2 release.
And I would be happy to test whatever files you send me.

The sort of report you're doing isn't that helpful. What would
help is if you could narrow down which patch(es) it is that
make things so much better. Giving 4.1.3-rc a try might also
be worthwhile, albeit I would hope we don't have a regression
in 4.2.0-rc compared to 4.1.3-rc...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------080202040004090906000301-- --===============7936935401473163584== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============7936935401473163584==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 20:29:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 20:29:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJVYW-0007ii-2p; Wed, 03 Oct 2012 20:28:32 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJVYU-0007id-6D for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 20:28:30 +0000 Received: from [85.158.139.83:29086] by server-13.bemta-5.messagelabs.com id 65/38-16359-DEF9C605; Wed, 03 Oct 2012 20:28:29 +0000 X-Env-Sender: xinxinjin89@gmail.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1349296107!26074201!1 X-Originating-IP: [209.85.216.173] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21609 invoked from network); 3 Oct 2012 20:28:28 -0000 Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com) (209.85.216.173) by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 20:28:28 -0000 Received: by qcab12 with SMTP id b12so8082632qca.32 for ; Wed, 03 Oct 2012 13:28:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=bzoMAjwFG5XUE0t6EeluxJ1b2Es8yEgwivP/ybZp4e0=; b=OxQjk3CLMfQuN4+2Uxlbpmi4P/C5xMbN9I2Q9SHsgTu4+uri7Qv5KgasTgHGqNouG4 LN78eN1cK5NCJPcmnBa8vudut3CUWkUcbq7VatqFv0JbOy4kh25aczHnJsyACYOynzvd 9XAZinJE1a/0ECMNDqvSA+3yfKhEJSPYgrzHqgX2Xi8xlhk8e4RkbNODYcn/DW8ybfNa YC/E/jKLzYIbPnTdhDUJY2YrD26wmsEsx+DC8uYQvr/KRKCnwvmKk6K6axZF+cpZO0m2 2QS/ZPqcjiDmI4Q5Ab0HDysBMak/pH+AEZuKTT2h6Y7BZLtP6d0LgIT2Xq6QHZZ0w68b HfmQ== MIME-Version: 1.0 Received: by 10.49.82.199 with SMTP id k7mr14619197qey.52.1349296107501; Wed, 03 Oct 2012 13:28:27 -0700 (PDT) Received: by 10.229.176.85 with HTTP; Wed, 3 Oct 2012 13:28:27 -0700 (PDT) Date: Wed, 3 Oct 2012 13:28:27 -0700 Message-ID: From: Xinxin Jin To: Xen-devel@lists.xen.org Subject: [Xen-devel] How does Xen implement writable page table ? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7801415133589242885==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============7801415133589242885== Content-Type: multipart/alternative; boundary=047d7b6d89b22f37cf04cb2d7bf7 --047d7b6d89b22f37cf04cb2d7bf7 Content-Type: text/plain; charset=ISO-8859-1 Hi everyone, If I follow the source code correctly, fixup_page_fault() -> ptwr_do_page_fault handles the write attempts to a page table. In my understanding, guests update page table through two ways: 1) Issue hypercall update_va_mapping to update PDT; 2) Modify writable bottom-level ptes and then trap to Xen's ptwr_do_page_fualt Here is my confusion: Why Xen supports two page table updating mechanisms? Why cannot apply writable page table to PDT entries? Thanks a lot !! -- Xinxin --047d7b6d89b22f37cf04cb2d7bf7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi everyone,
If I follow the source code correctly, =A0fixup_page_fault() -&= gt; ptwr_do_page_fault handles the write attempts to a page table. In my un= derstanding, guests update page table through two ways:
= 1) Issue hypercall update_va_mapping to update PDT;=A0
2) Modif= y writable bottom-level ptes and then trap to Xen's ptwr_do_page_fualt= =A0
Here is my confusion: Why Xen supports two page table updati= ng mechanisms? =A0Why cannot apply writable page table to PDT entries?
Thanks a lot !!
--
Xinxin

--047d7b6d89b22f37cf04cb2d7bf7-- --===============7801415133589242885== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============7801415133589242885==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 20:29:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 20:29:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJVYW-0007ii-2p; Wed, 03 Oct 2012 20:28:32 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJVYU-0007id-6D for Xen-devel@lists.xen.org; Wed, 03 Oct 2012 20:28:30 +0000 Received: from [85.158.139.83:29086] by server-13.bemta-5.messagelabs.com id 65/38-16359-DEF9C605; Wed, 03 Oct 2012 20:28:29 +0000 X-Env-Sender: xinxinjin89@gmail.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1349296107!26074201!1 X-Originating-IP: [209.85.216.173] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21609 invoked from network); 3 Oct 2012 20:28:28 -0000 Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com) (209.85.216.173) by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 20:28:28 -0000 Received: by qcab12 with SMTP id b12so8082632qca.32 for ; Wed, 03 Oct 2012 13:28:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=bzoMAjwFG5XUE0t6EeluxJ1b2Es8yEgwivP/ybZp4e0=; b=OxQjk3CLMfQuN4+2Uxlbpmi4P/C5xMbN9I2Q9SHsgTu4+uri7Qv5KgasTgHGqNouG4 LN78eN1cK5NCJPcmnBa8vudut3CUWkUcbq7VatqFv0JbOy4kh25aczHnJsyACYOynzvd 9XAZinJE1a/0ECMNDqvSA+3yfKhEJSPYgrzHqgX2Xi8xlhk8e4RkbNODYcn/DW8ybfNa YC/E/jKLzYIbPnTdhDUJY2YrD26wmsEsx+DC8uYQvr/KRKCnwvmKk6K6axZF+cpZO0m2 2QS/ZPqcjiDmI4Q5Ab0HDysBMak/pH+AEZuKTT2h6Y7BZLtP6d0LgIT2Xq6QHZZ0w68b HfmQ== MIME-Version: 1.0 Received: by 10.49.82.199 with SMTP id k7mr14619197qey.52.1349296107501; Wed, 03 Oct 2012 13:28:27 -0700 (PDT) Received: by 10.229.176.85 with HTTP; Wed, 3 Oct 2012 13:28:27 -0700 (PDT) Date: Wed, 3 Oct 2012 13:28:27 -0700 Message-ID: From: Xinxin Jin To: Xen-devel@lists.xen.org Subject: [Xen-devel] How does Xen implement writable page table ? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7801415133589242885==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============7801415133589242885== Content-Type: multipart/alternative; boundary=047d7b6d89b22f37cf04cb2d7bf7 --047d7b6d89b22f37cf04cb2d7bf7 Content-Type: text/plain; charset=ISO-8859-1 Hi everyone, If I follow the source code correctly, fixup_page_fault() -> ptwr_do_page_fault handles the write attempts to a page table. In my understanding, guests update page table through two ways: 1) Issue hypercall update_va_mapping to update PDT; 2) Modify writable bottom-level ptes and then trap to Xen's ptwr_do_page_fualt Here is my confusion: Why Xen supports two page table updating mechanisms? Why cannot apply writable page table to PDT entries? Thanks a lot !! -- Xinxin --047d7b6d89b22f37cf04cb2d7bf7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi everyone,
If I follow the source code correctly, =A0fixup_page_fault() -&= gt; ptwr_do_page_fault handles the write attempts to a page table. In my un= derstanding, guests update page table through two ways:
= 1) Issue hypercall update_va_mapping to update PDT;=A0
2) Modif= y writable bottom-level ptes and then trap to Xen's ptwr_do_page_fualt= =A0
Here is my confusion: Why Xen supports two page table updati= ng mechanisms? =A0Why cannot apply writable page table to PDT entries?
Thanks a lot !!
--
Xinxin

--047d7b6d89b22f37cf04cb2d7bf7-- --===============7801415133589242885== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============7801415133589242885==-- From xen-devel-bounces@lists.xen.org Wed Oct 03 20:49:48 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 20:49:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJVsc-0007zj-Vu; Wed, 03 Oct 2012 20:49:18 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJVsc-0007ze-5Z for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 20:49:18 +0000 Received: from [85.158.139.83:44575] by server-9.bemta-5.messagelabs.com id 4E/01-14846-DC4AC605; Wed, 03 Oct 2012 20:49:17 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-2.tower-182.messagelabs.com!1349297356!30451606!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19316 invoked from network); 3 Oct 2012 20:49:16 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 20:49:16 -0000 X-IronPort-AV: E=Sophos;i="4.80,529,1344211200"; d="scan'208";a="14925442" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 20:49:15 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 21:49:15 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TJVsZ-00006u-IO; Wed, 03 Oct 2012 20:49:15 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1TJVsY-0003fN-LJ; Wed, 03 Oct 2012 21:49:14 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Wed, 3 Oct 2012 21:49:14 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 13916: trouble: broken/fail/pass X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 13916 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13916/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-pair 4 host-install/dst_host(4) broken REGR. vs. 13914 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 5 xen-boot fail like 13914 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail like 13914 test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail like 13914 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail like 13914 Tests which did not succeed, but are not blocking: test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: xen 572821a5682b baseline version: xen 59dc1c2e7c54 ------------------------------------------------------------ People who touched revisions under test: Keir Fraser Matthew Fioravante ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair broken test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-amd64-amd64-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 25980:572821a5682b tag: tip user: Keir Fraser date: Wed Oct 03 12:59:30 2012 +0100 MAINTAINERS: Move and fix up VTPM entry Signed-off-by: Keir Fraser changeset: 25979:59dc1c2e7c54 user: Matthew Fioravante date: Wed Oct 03 11:13:54 2012 +0100 MAINTAINERS: Matthew Fioravante now maintains VTPM Signed-off-by: Matthew Fioravante Committed-by: Keir Fraser (qemu changes not included) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 20:49:48 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 20:49:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJVsc-0007zj-Vu; Wed, 03 Oct 2012 20:49:18 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJVsc-0007ze-5Z for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 20:49:18 +0000 Received: from [85.158.139.83:44575] by server-9.bemta-5.messagelabs.com id 4E/01-14846-DC4AC605; Wed, 03 Oct 2012 20:49:17 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-2.tower-182.messagelabs.com!1349297356!30451606!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxMDE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19316 invoked from network); 3 Oct 2012 20:49:16 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 3 Oct 2012 20:49:16 -0000 X-IronPort-AV: E=Sophos;i="4.80,529,1344211200"; d="scan'208";a="14925442" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 03 Oct 2012 20:49:15 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Oct 2012 21:49:15 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TJVsZ-00006u-IO; Wed, 03 Oct 2012 20:49:15 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1TJVsY-0003fN-LJ; Wed, 03 Oct 2012 21:49:14 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Wed, 3 Oct 2012 21:49:14 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 13916: trouble: broken/fail/pass X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 13916 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13916/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-pair 4 host-install/dst_host(4) broken REGR. vs. 13914 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 5 xen-boot fail like 13914 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail like 13914 test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail like 13914 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail like 13914 Tests which did not succeed, but are not blocking: test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: xen 572821a5682b baseline version: xen 59dc1c2e7c54 ------------------------------------------------------------ People who touched revisions under test: Keir Fraser Matthew Fioravante ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair broken test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-amd64-amd64-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 25980:572821a5682b tag: tip user: Keir Fraser date: Wed Oct 03 12:59:30 2012 +0100 MAINTAINERS: Move and fix up VTPM entry Signed-off-by: Keir Fraser changeset: 25979:59dc1c2e7c54 user: Matthew Fioravante date: Wed Oct 03 11:13:54 2012 +0100 MAINTAINERS: Matthew Fioravante now maintains VTPM Signed-off-by: Matthew Fioravante Committed-by: Keir Fraser (qemu changes not included) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 20:53:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 20:53:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJVwN-000872-L3; Wed, 03 Oct 2012 20:53:11 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJVwL-00086u-Sq for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 20:53:10 +0000 Received: from [85.158.137.99:63594] by server-16.bemta-3.messagelabs.com id ED/26-09129-5B5AC605; Wed, 03 Oct 2012 20:53:09 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-10.tower-217.messagelabs.com!1349297586!20062115!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzgwMzQw\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22185 invoked from network); 3 Oct 2012 20:53:08 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-10.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Oct 2012 20:53:08 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q93Kr0vm008934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Oct 2012 20:53:01 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q93Kqxxw015611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Oct 2012 20:53:00 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q93Kqx4r011734; Wed, 3 Oct 2012 15:52:59 -0500 Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 03 Oct 2012 13:51:20 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 42335402E4; Wed, 3 Oct 2012 16:39:56 -0400 (EDT) USER-AGENT: Mutt/1.5.21 (2010-09-15) MIME-Version: 1.0 Message-ID: <20121003203956.GA7526@phenom.dumpdata.com> Date: Wed, 3 Oct 2012 13:39:56 -0700 (PDT) From: Konrad Rzeszutek Wilk To: Mukesh Rathor References: <20120921121202.3163c379@mantra.us.oracle.com> <1348581263.11229.21.camel@zakaz.uk.xensource.com> <20121001142826.1ebf7b0f@mantra.us.oracle.com> <1349170528.650.18.camel@zakaz.uk.xensource.com> <20121003121122.0f20d5ed@mantra.us.oracle.com> In-Reply-To: <20121003121122.0f20d5ed@mantra.us.oracle.com> X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "Xen-devel@lists.xensource.com" , Ian Campbell , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v1 0/8]: PVH (PV guest with extensions) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, Oct 03, 2012 at 12:11:22PM -0700, Mukesh Rathor wrote: > On Tue, 2 Oct 2012 10:35:28 +0100 > Ian Campbell wrote: > > > On Mon, 2012-10-01 at 22:28 +0100, Mukesh Rathor wrote: > > > On Tue, 25 Sep 2012 14:54:23 +0100 > > > Ian Campbell wrote: > > > > > > > On Fri, 2012-09-21 at 20:12 +0100, Mukesh Rathor wrote: > > > > > Hi guys, > > > > > > > > > > Ok, I've made all the changes from prev RFC patch submission. > > > > > > > > Did I miss the patch with the changes to arch/x86/xen/xen-head.S > > > > which declare the features which are used here as supported by > > > > the kernel image? > > > > > > > > Ian. > > > > > > > > > > Strange, adding following to head.S > > > > > > ELFNOTE(Xen, XEN_ELFNOTE_PADDR_OFFSET, _ASM_PTR 0) > > > ELFNOTE(Xen, XEN_ELFNOTE_GUEST_PVH, .long 1) <-------- > > > > > > and xenstore won't start in dom0. What gives? > > > > I have no idea, I can't think of any way that xenstored would be able > > to even see the notes given in the dom0 kernel image. > > > > Are you sure you only that one exact change? > > You Ok with XEN_ELFNOTE_GUEST_PVH, or should I call it > XEN_ELFNOTE_PV_EXTENSIONS. Please LMK. XEN_ELFNOTE_PVH_FEATURES ? That way you can fill it with different 'features' flags if need to. Say 1<<1 is basic, etc. > > tanks > Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 20:53:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 20:53:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJVwN-000872-L3; Wed, 03 Oct 2012 20:53:11 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJVwL-00086u-Sq for xen-devel@lists.xensource.com; Wed, 03 Oct 2012 20:53:10 +0000 Received: from [85.158.137.99:63594] by server-16.bemta-3.messagelabs.com id ED/26-09129-5B5AC605; Wed, 03 Oct 2012 20:53:09 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-10.tower-217.messagelabs.com!1349297586!20062115!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzgwMzQw\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22185 invoked from network); 3 Oct 2012 20:53:08 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-10.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Oct 2012 20:53:08 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q93Kr0vm008934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Oct 2012 20:53:01 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q93Kqxxw015611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Oct 2012 20:53:00 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q93Kqx4r011734; Wed, 3 Oct 2012 15:52:59 -0500 Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 03 Oct 2012 13:51:20 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 42335402E4; Wed, 3 Oct 2012 16:39:56 -0400 (EDT) USER-AGENT: Mutt/1.5.21 (2010-09-15) MIME-Version: 1.0 Message-ID: <20121003203956.GA7526@phenom.dumpdata.com> Date: Wed, 3 Oct 2012 13:39:56 -0700 (PDT) From: Konrad Rzeszutek Wilk To: Mukesh Rathor References: <20120921121202.3163c379@mantra.us.oracle.com> <1348581263.11229.21.camel@zakaz.uk.xensource.com> <20121001142826.1ebf7b0f@mantra.us.oracle.com> <1349170528.650.18.camel@zakaz.uk.xensource.com> <20121003121122.0f20d5ed@mantra.us.oracle.com> In-Reply-To: <20121003121122.0f20d5ed@mantra.us.oracle.com> X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "Xen-devel@lists.xensource.com" , Ian Campbell , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v1 0/8]: PVH (PV guest with extensions) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, Oct 03, 2012 at 12:11:22PM -0700, Mukesh Rathor wrote: > On Tue, 2 Oct 2012 10:35:28 +0100 > Ian Campbell wrote: > > > On Mon, 2012-10-01 at 22:28 +0100, Mukesh Rathor wrote: > > > On Tue, 25 Sep 2012 14:54:23 +0100 > > > Ian Campbell wrote: > > > > > > > On Fri, 2012-09-21 at 20:12 +0100, Mukesh Rathor wrote: > > > > > Hi guys, > > > > > > > > > > Ok, I've made all the changes from prev RFC patch submission. > > > > > > > > Did I miss the patch with the changes to arch/x86/xen/xen-head.S > > > > which declare the features which are used here as supported by > > > > the kernel image? > > > > > > > > Ian. > > > > > > > > > > Strange, adding following to head.S > > > > > > ELFNOTE(Xen, XEN_ELFNOTE_PADDR_OFFSET, _ASM_PTR 0) > > > ELFNOTE(Xen, XEN_ELFNOTE_GUEST_PVH, .long 1) <-------- > > > > > > and xenstore won't start in dom0. What gives? > > > > I have no idea, I can't think of any way that xenstored would be able > > to even see the notes given in the dom0 kernel image. > > > > Are you sure you only that one exact change? > > You Ok with XEN_ELFNOTE_GUEST_PVH, or should I call it > XEN_ELFNOTE_PV_EXTENSIONS. Please LMK. XEN_ELFNOTE_PVH_FEATURES ? That way you can fill it with different 'features' flags if need to. Say 1<<1 is basic, etc. > > tanks > Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 22:26:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 22:26:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJXOR-0000mc-AG; Wed, 03 Oct 2012 22:26:15 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJXOP-0000mW-AI for Xen-devel@lists.xensource.com; Wed, 03 Oct 2012 22:26:13 +0000 Received: from [85.158.139.211:47215] by server-1.bemta-5.messagelabs.com id 36/11-09825-48BBC605; Wed, 03 Oct 2012 22:26:12 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-14.tower-206.messagelabs.com!1349303170!20916089!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzgwMzQw\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19475 invoked from network); 3 Oct 2012 22:26:11 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Oct 2012 22:26:11 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q93MQ3pr003554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Oct 2012 22:26:04 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q93MQ231010783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Oct 2012 22:26:03 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q93MQ2Er029280; Wed, 3 Oct 2012 17:26:02 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 03 Oct 2012 15:26:02 -0700 Date: Wed, 3 Oct 2012 15:26:00 -0700 From: Mukesh Rathor To: Ian Campbell Message-ID: <20121003152600.1a9e2034@mantra.us.oracle.com> In-Reply-To: <1349259844.650.123.camel@zakaz.uk.xensource.com> References: <20120921121202.3163c379@mantra.us.oracle.com> <1348581263.11229.21.camel@zakaz.uk.xensource.com> <20121001142826.1ebf7b0f@mantra.us.oracle.com> <20121002130911.GD9009@phenom.dumpdata.com> <20121002115552.3a5d5196@mantra.us.oracle.com> <1349259844.650.123.camel@zakaz.uk.xensource.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 0/8]: PVH (PV guest with extensions) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 3 Oct 2012 11:24:04 +0100 Ian Campbell wrote: > On Tue, 2012-10-02 at 19:55 +0100, Mukesh Rathor wrote: > > On Tue, 2 Oct 2012 09:09:11 -0400 > > Konrad Rzeszutek Wilk wrote: > > > > > > > > Strange, adding following to head.S > > > > > > > > ELFNOTE(Xen, XEN_ELFNOTE_PADDR_OFFSET, _ASM_PTR 0) > > > > ELFNOTE(Xen, XEN_ELFNOTE_GUEST_PVH, .long 1) <-------- > > > > > > > > and xenstore won't start in dom0. What gives? > > > > > > What is XEN_ELFNOTE_GUEST_PVH number? You might be re-using a > > > value that is defined for a different purpose? Did you check the > > > Xen hypervisor header files? > > > > Ah, right. I was looking at linux header file, which is behind xen. > > Phew! > > You are going to add the other features which PVH uses too, right? > > Ian. > Sorry, confused. Not very familiar with this. You mean, something like: ELFNOTE(Xen, XEN_ELFNOTE_GUEST_PVH, .long 1) ELFNOTE(Xen, XEN_ELFNOTE_PVH_FEATURES, .asciz "writable_page_tables|auto_translated_physmap|supervisor_mode_kernel|hvm_callback_vector") Something like this? thanks Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 22:26:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 22:26:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJXOR-0000mc-AG; Wed, 03 Oct 2012 22:26:15 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJXOP-0000mW-AI for Xen-devel@lists.xensource.com; Wed, 03 Oct 2012 22:26:13 +0000 Received: from [85.158.139.211:47215] by server-1.bemta-5.messagelabs.com id 36/11-09825-48BBC605; Wed, 03 Oct 2012 22:26:12 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-14.tower-206.messagelabs.com!1349303170!20916089!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzgwMzQw\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19475 invoked from network); 3 Oct 2012 22:26:11 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Oct 2012 22:26:11 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q93MQ3pr003554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Oct 2012 22:26:04 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q93MQ231010783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Oct 2012 22:26:03 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q93MQ2Er029280; Wed, 3 Oct 2012 17:26:02 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 03 Oct 2012 15:26:02 -0700 Date: Wed, 3 Oct 2012 15:26:00 -0700 From: Mukesh Rathor To: Ian Campbell Message-ID: <20121003152600.1a9e2034@mantra.us.oracle.com> In-Reply-To: <1349259844.650.123.camel@zakaz.uk.xensource.com> References: <20120921121202.3163c379@mantra.us.oracle.com> <1348581263.11229.21.camel@zakaz.uk.xensource.com> <20121001142826.1ebf7b0f@mantra.us.oracle.com> <20121002130911.GD9009@phenom.dumpdata.com> <20121002115552.3a5d5196@mantra.us.oracle.com> <1349259844.650.123.camel@zakaz.uk.xensource.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 0/8]: PVH (PV guest with extensions) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 3 Oct 2012 11:24:04 +0100 Ian Campbell wrote: > On Tue, 2012-10-02 at 19:55 +0100, Mukesh Rathor wrote: > > On Tue, 2 Oct 2012 09:09:11 -0400 > > Konrad Rzeszutek Wilk wrote: > > > > > > > > Strange, adding following to head.S > > > > > > > > ELFNOTE(Xen, XEN_ELFNOTE_PADDR_OFFSET, _ASM_PTR 0) > > > > ELFNOTE(Xen, XEN_ELFNOTE_GUEST_PVH, .long 1) <-------- > > > > > > > > and xenstore won't start in dom0. What gives? > > > > > > What is XEN_ELFNOTE_GUEST_PVH number? You might be re-using a > > > value that is defined for a different purpose? Did you check the > > > Xen hypervisor header files? > > > > Ah, right. I was looking at linux header file, which is behind xen. > > Phew! > > You are going to add the other features which PVH uses too, right? > > Ian. > Sorry, confused. Not very familiar with this. You mean, something like: ELFNOTE(Xen, XEN_ELFNOTE_GUEST_PVH, .long 1) ELFNOTE(Xen, XEN_ELFNOTE_PVH_FEATURES, .asciz "writable_page_tables|auto_translated_physmap|supervisor_mode_kernel|hvm_callback_vector") Something like this? thanks Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 22:29:58 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 22:29:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJXRf-0000sw-Tz; Wed, 03 Oct 2012 22:29:35 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJXRf-0000sq-90 for Xen-devel@lists.xensource.com; Wed, 03 Oct 2012 22:29:35 +0000 Received: from [85.158.138.51:8214] by server-7.bemta-3.messagelabs.com id 69/AD-15765-E4CBC605; Wed, 03 Oct 2012 22:29:34 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1349303371!32955446!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzgxNzI4\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6919 invoked from network); 3 Oct 2012 22:29:33 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Oct 2012 22:29:33 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q93MTSX4005790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Oct 2012 22:29:29 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q93MTR3K024365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Oct 2012 22:29:28 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q93MTRUx030883; Wed, 3 Oct 2012 17:29:27 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 03 Oct 2012 15:29:27 -0700 Date: Wed, 3 Oct 2012 15:29:25 -0700 From: Mukesh Rathor To: Ian Campbell Message-ID: <20121003152925.5af3a658@mantra.us.oracle.com> In-Reply-To: <1349278963.650.164.camel@zakaz.uk.xensource.com> References: <20120921121556.1a0ea8af@mantra.us.oracle.com> <1349278963.650.164.camel@zakaz.uk.xensource.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 3 Oct 2012 16:42:43 +0100 Ian Campbell wrote: > > > diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h > > index 6a198e4..6c5ad83 100644 > > --- a/include/xen/xen-ops.h > > +++ b/include/xen/xen-ops.h > > @@ -24,9 +24,19 @@ int xen_create_contiguous_region(unsigned long > > vstart, unsigned int order, void > > xen_destroy_contiguous_region(unsigned long vstart, unsigned int > > order); struct vm_area_struct; > > +struct xen_pvh_pfn_info; > > If you move the struct def'n up you don't need this forward decl. > > > int xen_remap_domain_mfn_range(struct vm_area_struct *vma, > > unsigned long addr, > > unsigned long mfn, int nr, > > - pgprot_t prot, unsigned domid); > > + pgprot_t prot, unsigned domid, > > + struct xen_pvh_pfn_info *pvhp); > > +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma, > > + struct xen_pvh_pfn_info *pvhp); > > + > > +struct xen_pvh_pfn_info { > > Can we call this xen_remap_mfn_info or something? PVH is x86 specific > while this struct is also useful on ARM. I already renamed it to: xen_xlat_pfn_info. > > + struct page **pi_paga; /* pfn info page > > array */ > > can we just call this "pages"? paga is pretty meaningless. page array! i can rename page_array or page_a. > > + int pi_num_pgs; > > + int pi_next_todo; > > I don't think we need the pi_ prefix for any of these. The prefix for fields in struct make it easy to find via cscope or grep, otherwise, it's a nightmare to find common field names like pages when reading code. I really get frustrated. I prefer prefixing all field names. thanks Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 22:29:58 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 22:29:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJXRf-0000sw-Tz; Wed, 03 Oct 2012 22:29:35 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJXRf-0000sq-90 for Xen-devel@lists.xensource.com; Wed, 03 Oct 2012 22:29:35 +0000 Received: from [85.158.138.51:8214] by server-7.bemta-3.messagelabs.com id 69/AD-15765-E4CBC605; Wed, 03 Oct 2012 22:29:34 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1349303371!32955446!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzgxNzI4\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6919 invoked from network); 3 Oct 2012 22:29:33 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Oct 2012 22:29:33 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q93MTSX4005790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Oct 2012 22:29:29 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q93MTR3K024365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Oct 2012 22:29:28 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q93MTRUx030883; Wed, 3 Oct 2012 17:29:27 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 03 Oct 2012 15:29:27 -0700 Date: Wed, 3 Oct 2012 15:29:25 -0700 From: Mukesh Rathor To: Ian Campbell Message-ID: <20121003152925.5af3a658@mantra.us.oracle.com> In-Reply-To: <1349278963.650.164.camel@zakaz.uk.xensource.com> References: <20120921121556.1a0ea8af@mantra.us.oracle.com> <1349278963.650.164.camel@zakaz.uk.xensource.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 3 Oct 2012 16:42:43 +0100 Ian Campbell wrote: > > > diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h > > index 6a198e4..6c5ad83 100644 > > --- a/include/xen/xen-ops.h > > +++ b/include/xen/xen-ops.h > > @@ -24,9 +24,19 @@ int xen_create_contiguous_region(unsigned long > > vstart, unsigned int order, void > > xen_destroy_contiguous_region(unsigned long vstart, unsigned int > > order); struct vm_area_struct; > > +struct xen_pvh_pfn_info; > > If you move the struct def'n up you don't need this forward decl. > > > int xen_remap_domain_mfn_range(struct vm_area_struct *vma, > > unsigned long addr, > > unsigned long mfn, int nr, > > - pgprot_t prot, unsigned domid); > > + pgprot_t prot, unsigned domid, > > + struct xen_pvh_pfn_info *pvhp); > > +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma, > > + struct xen_pvh_pfn_info *pvhp); > > + > > +struct xen_pvh_pfn_info { > > Can we call this xen_remap_mfn_info or something? PVH is x86 specific > while this struct is also useful on ARM. I already renamed it to: xen_xlat_pfn_info. > > + struct page **pi_paga; /* pfn info page > > array */ > > can we just call this "pages"? paga is pretty meaningless. page array! i can rename page_array or page_a. > > + int pi_num_pgs; > > + int pi_next_todo; > > I don't think we need the pi_ prefix for any of these. The prefix for fields in struct make it easy to find via cscope or grep, otherwise, it's a nightmare to find common field names like pages when reading code. I really get frustrated. I prefer prefixing all field names. thanks Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 22:31:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 22:31:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJXTK-0000yu-Dg; Wed, 03 Oct 2012 22:31:18 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJXTI-0000yo-P5 for Xen-devel@lists.xensource.com; Wed, 03 Oct 2012 22:31:16 +0000 Received: from [85.158.143.35:52006] by server-1.bemta-4.messagelabs.com id 16/56-05684-4BCBC605; Wed, 03 Oct 2012 22:31:16 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-16.tower-21.messagelabs.com!1349303474!14727035!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc5MDM1NA==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14209 invoked from network); 3 Oct 2012 22:31:15 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Oct 2012 22:31:15 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q93MV8P0006113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Oct 2012 22:31:08 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q93MV7Jj017288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Oct 2012 22:31:08 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q93MV78o005418; Wed, 3 Oct 2012 17:31:07 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 03 Oct 2012 15:31:07 -0700 Date: Wed, 3 Oct 2012 15:31:06 -0700 From: Mukesh Rathor To: Ian Campbell Message-ID: <20121003153106.65237f07@mantra.us.oracle.com> In-Reply-To: <1349270495.650.144.camel@zakaz.uk.xensource.com> References: <20120921122123.33489ce1@mantra.us.oracle.com> <1349270495.650.144.camel@zakaz.uk.xensource.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 7/8]: PVH privcmd changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 3 Oct 2012 14:21:35 +0100 Ian Campbell wrote: > On Fri, 2012-09-21 at 20:21 +0100, Mukesh Rathor wrote: > > +static int pvh_privcmd_resv_pfns(struct vm_area_struct *vma, int > > numpgs) > ... > > + pvhp->pi_num_pgs = numpgs; > > + BUG_ON(vma->vm_private_data != (void *)1); > > + vma->vm_private_data = pvhp; > > How does this interact with: > > static int privcmd_enforce_singleshot_mapping(struct vm_area_struct > *vma) { > return (xchg(&vma->vm_private_data, (void *)1) == NULL); > } > > If someone tries to map a second time then won't this correct the pvhp > in vm_private_data by resetting it to 1? Then when the original > mapping is torn down things all fall apart? > > Perhaps we need a cmpxchg here? Or to rework the callers a little bit > perhaps. Right, that's why I had it originally checking for auto xlated and doing something different. I think that is better than to change this and change again. I'll change it back to just putting the ptr here. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 22:31:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 22:31:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJXTK-0000yu-Dg; Wed, 03 Oct 2012 22:31:18 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJXTI-0000yo-P5 for Xen-devel@lists.xensource.com; Wed, 03 Oct 2012 22:31:16 +0000 Received: from [85.158.143.35:52006] by server-1.bemta-4.messagelabs.com id 16/56-05684-4BCBC605; Wed, 03 Oct 2012 22:31:16 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-16.tower-21.messagelabs.com!1349303474!14727035!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc5MDM1NA==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14209 invoked from network); 3 Oct 2012 22:31:15 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Oct 2012 22:31:15 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q93MV8P0006113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Oct 2012 22:31:08 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q93MV7Jj017288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Oct 2012 22:31:08 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q93MV78o005418; Wed, 3 Oct 2012 17:31:07 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 03 Oct 2012 15:31:07 -0700 Date: Wed, 3 Oct 2012 15:31:06 -0700 From: Mukesh Rathor To: Ian Campbell Message-ID: <20121003153106.65237f07@mantra.us.oracle.com> In-Reply-To: <1349270495.650.144.camel@zakaz.uk.xensource.com> References: <20120921122123.33489ce1@mantra.us.oracle.com> <1349270495.650.144.camel@zakaz.uk.xensource.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 7/8]: PVH privcmd changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 3 Oct 2012 14:21:35 +0100 Ian Campbell wrote: > On Fri, 2012-09-21 at 20:21 +0100, Mukesh Rathor wrote: > > +static int pvh_privcmd_resv_pfns(struct vm_area_struct *vma, int > > numpgs) > ... > > + pvhp->pi_num_pgs = numpgs; > > + BUG_ON(vma->vm_private_data != (void *)1); > > + vma->vm_private_data = pvhp; > > How does this interact with: > > static int privcmd_enforce_singleshot_mapping(struct vm_area_struct > *vma) { > return (xchg(&vma->vm_private_data, (void *)1) == NULL); > } > > If someone tries to map a second time then won't this correct the pvhp > in vm_private_data by resetting it to 1? Then when the original > mapping is torn down things all fall apart? > > Perhaps we need a cmpxchg here? Or to rework the callers a little bit > perhaps. Right, that's why I had it originally checking for auto xlated and doing something different. I think that is better than to change this and change again. I'll change it back to just putting the ptr here. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 22:37:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 22:37:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJXZF-0001Hs-ES; Wed, 03 Oct 2012 22:37:25 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJXZD-0001Hk-Oy for Xen-devel@lists.xensource.com; Wed, 03 Oct 2012 22:37:23 +0000 Received: from [85.158.137.99:8934] by server-3.bemta-3.messagelabs.com id 5C/9A-25962-22EBC605; Wed, 03 Oct 2012 22:37:22 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-3.tower-217.messagelabs.com!1349303840!15113432!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc5MDM1NA==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16983 invoked from network); 3 Oct 2012 22:37:22 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-3.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Oct 2012 22:37:22 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q93MbGPH014255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Oct 2012 22:37:17 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q93MbFEe028921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Oct 2012 22:37:16 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q93MbFPL003678; Wed, 3 Oct 2012 17:37:15 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 03 Oct 2012 15:37:15 -0700 Date: Wed, 3 Oct 2012 15:37:14 -0700 From: Mukesh Rathor To: Stefano Stabellini Message-ID: <20121003153714.4656b7e9@mantra.us.oracle.com> In-Reply-To: References: <20120921121659.5a723de9@mantra.us.oracle.com> <20120924154335.097d3fb9@mantra.us.oracle.com> <20120925180416.0137d61a@mantra.us.oracle.com> <20121002183619.70734b7a@mantra.us.oracle.com> <20121002190323.2e16f6ff@mantra.us.oracle.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "Xen-devel@lists.xensource.com" , Ian Campbell , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 3/8]: PVH startup changes (enlighten.c) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 3 Oct 2012 12:58:22 +0100 Stefano Stabellini wrote: > On Wed, 3 Oct 2012, Mukesh Rathor wrote: > > On Tue, 2 Oct 2012 18:36:19 -0700 > > Mukesh Rathor wrote: > > > > > On Wed, 26 Sep 2012 12:33:39 +0100 > > > > So for now, how about, lets go > > with what I've got. I'll make a note, and when I do xen patch, I'll > > figure it out, and would be a very small linux patch. I want to get > > linux patch in soon before the window closes. > > We can leave page special as it is for now with very little > consequences, because it is not part of the interface with Xen. > However this is part of the interface, so whatever we choose here is > going to be hard to change later on. > > I think it would be good if we could either make dom0 use a pfn or > domU use mfn, whatever is easier for you. Ok, finally, focussing on this, the issue with pfn in dom0 is that I need pfn allocated in construct_dom0() and be mapped so that the guest can just do : HYPERVISOR_shared_info=(struct shared_info *)__va(xen_start_info->shared_info); How about following I am experimenting with right now: in construct_dom0(): vstartinfo_end = (vstartinfo_start + sizeof(struct start_info) + sizeof(struct dom0_vga_console_info)); if ( is_hybrid_domain(d) ) { start_info_pfn_addr = round_pgup(vstartinfo_end) - v_start; vstartinfo_end += PAGE_SIZE; } I can then put (PFN: start_info_pfn_addr)->(MFN: virt_to_maddr(d->shared_info)) in the p2m, and dom0 just has to do __va(), like domU does now. I wont' need to special case dom0 then. Do you foresee any problems with this approach? thanks Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Wed Oct 03 22:37:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Oct 2012 22:37:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJXZF-0001Hs-ES; Wed, 03 Oct 2012 22:37:25 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJXZD-0001Hk-Oy for Xen-devel@lists.xensource.com; Wed, 03 Oct 2012 22:37:23 +0000 Received: from [85.158.137.99:8934] by server-3.bemta-3.messagelabs.com id 5C/9A-25962-22EBC605; Wed, 03 Oct 2012 22:37:22 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-3.tower-217.messagelabs.com!1349303840!15113432!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc5MDM1NA==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16983 invoked from network); 3 Oct 2012 22:37:22 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-3.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Oct 2012 22:37:22 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q93MbGPH014255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Oct 2012 22:37:17 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q93MbFEe028921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Oct 2012 22:37:16 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q93MbFPL003678; Wed, 3 Oct 2012 17:37:15 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 03 Oct 2012 15:37:15 -0700 Date: Wed, 3 Oct 2012 15:37:14 -0700 From: Mukesh Rathor To: Stefano Stabellini Message-ID: <20121003153714.4656b7e9@mantra.us.oracle.com> In-Reply-To: References: <20120921121659.5a723de9@mantra.us.oracle.com> <20120924154335.097d3fb9@mantra.us.oracle.com> <20120925180416.0137d61a@mantra.us.oracle.com> <20121002183619.70734b7a@mantra.us.oracle.com> <20121002190323.2e16f6ff@mantra.us.oracle.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "Xen-devel@lists.xensource.com" , Ian Campbell , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 3/8]: PVH startup changes (enlighten.c) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 3 Oct 2012 12:58:22 +0100 Stefano Stabellini wrote: > On Wed, 3 Oct 2012, Mukesh Rathor wrote: > > On Tue, 2 Oct 2012 18:36:19 -0700 > > Mukesh Rathor wrote: > > > > > On Wed, 26 Sep 2012 12:33:39 +0100 > > > > So for now, how about, lets go > > with what I've got. I'll make a note, and when I do xen patch, I'll > > figure it out, and would be a very small linux patch. I want to get > > linux patch in soon before the window closes. > > We can leave page special as it is for now with very little > consequences, because it is not part of the interface with Xen. > However this is part of the interface, so whatever we choose here is > going to be hard to change later on. > > I think it would be good if we could either make dom0 use a pfn or > domU use mfn, whatever is easier for you. Ok, finally, focussing on this, the issue with pfn in dom0 is that I need pfn allocated in construct_dom0() and be mapped so that the guest can just do : HYPERVISOR_shared_info=(struct shared_info *)__va(xen_start_info->shared_info); How about following I am experimenting with right now: in construct_dom0(): vstartinfo_end = (vstartinfo_start + sizeof(struct start_info) + sizeof(struct dom0_vga_console_info)); if ( is_hybrid_domain(d) ) { start_info_pfn_addr = round_pgup(vstartinfo_end) - v_start; vstartinfo_end += PAGE_SIZE; } I can then put (PFN: start_info_pfn_addr)->(MFN: virt_to_maddr(d->shared_info)) in the p2m, and dom0 just has to do __va(), like domU does now. I wont' need to special case dom0 then. Do you foresee any problems with this approach? thanks Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 00:56:03 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 00:56:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJZiv-0002L3-UU; Thu, 04 Oct 2012 00:55:33 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJZiu-0002Kw-3i for xen-devel@lists.xensource.com; Thu, 04 Oct 2012 00:55:32 +0000 Received: from [85.158.143.35:17027] by server-1.bemta-4.messagelabs.com id 6F/32-05684-38EDC605; Thu, 04 Oct 2012 00:55:31 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1349312130!13805563!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMwMTc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7146 invoked from network); 4 Oct 2012 00:55:30 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 00:55:30 -0000 X-IronPort-AV: E=Sophos;i="4.80,530,1344211200"; d="scan'208";a="14927668" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 00:55:29 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 01:55:29 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TJZir-00024h-5P; Thu, 04 Oct 2012 00:55:29 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1TJZiq-0007zi-Ki; Thu, 04 Oct 2012 01:55:28 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Thu, 4 Oct 2012 01:55:28 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 13917: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 13917 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13917/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 5 xen-boot fail like 13914 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail like 13914 test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail like 13914 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail like 13914 Tests which did not succeed, but are not blocking: test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: xen 572821a5682b baseline version: xen 59dc1c2e7c54 ------------------------------------------------------------ People who touched revisions under test: Keir Fraser Matthew Fioravante ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-amd64-amd64-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable + revision=572821a5682b + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 572821a5682b + branch=xen-unstable + revision=572821a5682b + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + . cri-common ++ umask 002 + select_xenbranch + case "$branch" in + tree=xen + xenbranch=xen-unstable + '[' xxen = xlinux ']' + linuxbranch=linux + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg ++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.xen-unstable ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git ++ : daily-cron.xen-unstable + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git + info_linux_tree xen-unstable + case $1 in + return 1 + case "$branch" in + cd /export/home/osstest/repos/xen-unstable.hg + hg push -r 572821a5682b ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 1 changesets with 1 changes to 1 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 00:56:03 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 00:56:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJZiv-0002L3-UU; Thu, 04 Oct 2012 00:55:33 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJZiu-0002Kw-3i for xen-devel@lists.xensource.com; Thu, 04 Oct 2012 00:55:32 +0000 Received: from [85.158.143.35:17027] by server-1.bemta-4.messagelabs.com id 6F/32-05684-38EDC605; Thu, 04 Oct 2012 00:55:31 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1349312130!13805563!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMwMTc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7146 invoked from network); 4 Oct 2012 00:55:30 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 00:55:30 -0000 X-IronPort-AV: E=Sophos;i="4.80,530,1344211200"; d="scan'208";a="14927668" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 00:55:29 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 01:55:29 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TJZir-00024h-5P; Thu, 04 Oct 2012 00:55:29 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1TJZiq-0007zi-Ki; Thu, 04 Oct 2012 01:55:28 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Thu, 4 Oct 2012 01:55:28 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 13917: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 13917 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13917/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 5 xen-boot fail like 13914 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail like 13914 test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail like 13914 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail like 13914 Tests which did not succeed, but are not blocking: test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: xen 572821a5682b baseline version: xen 59dc1c2e7c54 ------------------------------------------------------------ People who touched revisions under test: Keir Fraser Matthew Fioravante ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-amd64-amd64-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable + revision=572821a5682b + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 572821a5682b + branch=xen-unstable + revision=572821a5682b + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + . cri-common ++ umask 002 + select_xenbranch + case "$branch" in + tree=xen + xenbranch=xen-unstable + '[' xxen = xlinux ']' + linuxbranch=linux + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg ++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.xen-unstable ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git ++ : daily-cron.xen-unstable + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git + info_linux_tree xen-unstable + case $1 in + return 1 + case "$branch" in + cd /export/home/osstest/repos/xen-unstable.hg + hg push -r 572821a5682b ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 1 changesets with 1 changes to 1 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 05:03:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 05:03:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJdah-0000Sw-6N; Thu, 04 Oct 2012 05:03:19 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJdaf-0000Sr-Hp for xen-devel@lists.xensource.com; Thu, 04 Oct 2012 05:03:17 +0000 Received: from [85.158.137.99:33933] by server-4.bemta-3.messagelabs.com id FD/A9-14155-4981D605; Thu, 04 Oct 2012 05:03:16 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-15.tower-217.messagelabs.com!1349326996!17829540!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMwMTc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1842 invoked from network); 4 Oct 2012 05:03:16 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 05:03:16 -0000 X-IronPort-AV: E=Sophos;i="4.80,531,1344211200"; d="scan'208";a="14929650" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 05:03:15 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 06:03:15 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TJdac-0005FW-LR; Thu, 04 Oct 2012 05:03:14 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1TJdac-00071T-5h; Thu, 04 Oct 2012 06:03:14 +0100 To: Message-ID: From: xen.org Date: Thu, 4 Oct 2012 06:03:14 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 13918: tolerable FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 13918 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13918/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 5 xen-boot fail like 13917 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail like 13917 test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail like 13917 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail like 13917 Tests which did not succeed, but are not blocking: test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: xen 572821a5682b baseline version: xen 572821a5682b jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-amd64-amd64-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 05:03:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 05:03:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJdah-0000Sw-6N; Thu, 04 Oct 2012 05:03:19 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJdaf-0000Sr-Hp for xen-devel@lists.xensource.com; Thu, 04 Oct 2012 05:03:17 +0000 Received: from [85.158.137.99:33933] by server-4.bemta-3.messagelabs.com id FD/A9-14155-4981D605; Thu, 04 Oct 2012 05:03:16 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-15.tower-217.messagelabs.com!1349326996!17829540!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMwMTc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1842 invoked from network); 4 Oct 2012 05:03:16 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 05:03:16 -0000 X-IronPort-AV: E=Sophos;i="4.80,531,1344211200"; d="scan'208";a="14929650" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 05:03:15 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 06:03:15 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TJdac-0005FW-LR; Thu, 04 Oct 2012 05:03:14 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1TJdac-00071T-5h; Thu, 04 Oct 2012 06:03:14 +0100 To: Message-ID: From: xen.org Date: Thu, 4 Oct 2012 06:03:14 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 13918: tolerable FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 13918 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13918/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 5 xen-boot fail like 13917 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail like 13917 test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail like 13917 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail like 13917 Tests which did not succeed, but are not blocking: test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: xen 572821a5682b baseline version: xen 572821a5682b jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-amd64-amd64-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 07:44:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 07:44:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJg69-0001dD-09; Thu, 04 Oct 2012 07:43:57 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with smtp (Exim 4.72) (envelope-from ) id 1TJg67-0001d8-K3 for xen-devel@lists.xensource.com; Thu, 04 Oct 2012 07:43:55 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1349336629!5714747!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25409 invoked from network); 4 Oct 2012 07:43:49 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-7.tower-27.messagelabs.com with SMTP; 4 Oct 2012 07:43:49 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 04 Oct 2012 08:43:48 +0100 Message-Id: <506D5A53020000780009F8B7@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Thu, 04 Oct 2012 08:43:47 +0100 From: "Jan Beulich" To: "Stefano Stabellini" References: <1349272182.650.150.camel@zakaz.uk.xensource.com> <1349272482.650.151.camel@zakaz.uk.xensource.com> <20121003141116.GA10633@phenom.dumpdata.com> <1349276431.650.156.camel@zakaz.uk.xensource.com> <1349279862.650.171.camel@zakaz.uk.xensource.com> <1349280814.650.178.camel@zakaz.uk.xensource.com> <1349282492.650.185.camel@zakaz.uk.xensource.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: "linux-kernel@vger.kernel.org" , "xen-devel@lists.xensource.com" , Ian Campbell , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH] xen/xen_initial_domain: check that xen_start_info is initialized X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 03.10.12 at 19:08, Stefano Stabellini wrote: > Since commit commit 4c071ee5268f7234c3d084b6093bebccc28cdcba ("arm: > initial Xen support") PV on HVM guests can be xen_initial_domain. > However PV on HVM guests might have an unitialized xen_start_info, so > check before accessing its fields. > > Signed-off-by: Stefano Stabellini > Acked-by: Ian Campbell > Reported-by: Konrad Rzeszutek Wilk > > diff --git a/include/xen/xen.h b/include/xen/xen.h > index 9a39ca5..e7101bb 100644 > --- a/include/xen/xen.h > +++ b/include/xen/xen.h > @@ -28,7 +28,7 @@ extern enum xen_domain_type xen_domain_type; > #include > > #define xen_initial_domain() (xen_domain() && \ > - xen_start_info->flags & SIF_INITDOMAIN) > + xen_start_info && xen_start_info->flags & SIF_INITDOMAIN) > #else /* !CONFIG_XEN_DOM0 */ > #define xen_initial_domain() (0) > #endif /* CONFIG_XEN_DOM0 */ Didn't your other patch statically initialize it? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 07:44:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 07:44:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJg69-0001dD-09; Thu, 04 Oct 2012 07:43:57 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with smtp (Exim 4.72) (envelope-from ) id 1TJg67-0001d8-K3 for xen-devel@lists.xensource.com; Thu, 04 Oct 2012 07:43:55 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1349336629!5714747!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25409 invoked from network); 4 Oct 2012 07:43:49 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-7.tower-27.messagelabs.com with SMTP; 4 Oct 2012 07:43:49 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 04 Oct 2012 08:43:48 +0100 Message-Id: <506D5A53020000780009F8B7@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Thu, 04 Oct 2012 08:43:47 +0100 From: "Jan Beulich" To: "Stefano Stabellini" References: <1349272182.650.150.camel@zakaz.uk.xensource.com> <1349272482.650.151.camel@zakaz.uk.xensource.com> <20121003141116.GA10633@phenom.dumpdata.com> <1349276431.650.156.camel@zakaz.uk.xensource.com> <1349279862.650.171.camel@zakaz.uk.xensource.com> <1349280814.650.178.camel@zakaz.uk.xensource.com> <1349282492.650.185.camel@zakaz.uk.xensource.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: "linux-kernel@vger.kernel.org" , "xen-devel@lists.xensource.com" , Ian Campbell , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH] xen/xen_initial_domain: check that xen_start_info is initialized X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 03.10.12 at 19:08, Stefano Stabellini wrote: > Since commit commit 4c071ee5268f7234c3d084b6093bebccc28cdcba ("arm: > initial Xen support") PV on HVM guests can be xen_initial_domain. > However PV on HVM guests might have an unitialized xen_start_info, so > check before accessing its fields. > > Signed-off-by: Stefano Stabellini > Acked-by: Ian Campbell > Reported-by: Konrad Rzeszutek Wilk > > diff --git a/include/xen/xen.h b/include/xen/xen.h > index 9a39ca5..e7101bb 100644 > --- a/include/xen/xen.h > +++ b/include/xen/xen.h > @@ -28,7 +28,7 @@ extern enum xen_domain_type xen_domain_type; > #include > > #define xen_initial_domain() (xen_domain() && \ > - xen_start_info->flags & SIF_INITDOMAIN) > + xen_start_info && xen_start_info->flags & SIF_INITDOMAIN) > #else /* !CONFIG_XEN_DOM0 */ > #define xen_initial_domain() (0) > #endif /* CONFIG_XEN_DOM0 */ Didn't your other patch statically initialize it? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 07:50:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 07:50:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJgBg-0001sm-Jm; Thu, 04 Oct 2012 07:49:40 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with smtp (Exim 4.72) (envelope-from ) id 1TJgBe-0001s5-Pu for Xen-devel@lists.xen.org; Thu, 04 Oct 2012 07:49:39 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1349336969!7303749!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.3 required=7.0 tests=MAILTO_TO_SPAM_ADDR X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23054 invoked from network); 4 Oct 2012 07:49:30 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-5.tower-27.messagelabs.com with SMTP; 4 Oct 2012 07:49:30 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 04 Oct 2012 08:49:29 +0100 Message-Id: <506D5BA8020000780009F8C6@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Thu, 04 Oct 2012 08:49:28 +0100 From: "Jan Beulich" To: "Xinxin Jin" References: In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: Xen-devel@lists.xen.org Subject: Re: [Xen-devel] How does Xen implement writable page table ? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 03.10.12 at 22:28, Xinxin Jin wrote: > Hi everyone, > If I follow the source code correctly, fixup_page_fault() -> > ptwr_do_page_fault handles the write attempts to a page table. In my > understanding, guests update page table through two ways: > 1) Issue hypercall update_va_mapping to update PDT; > 2) Modify writable bottom-level ptes and then trap to Xen's > ptwr_do_page_fualt > Here is my confusion: Why Xen supports two page table updating mechanisms? This allows balancing between the amount of changes in the guest side code - basic functionality would only require higher level page table updates to a para-virtualized, while performance considerations would call for all of the updates to avoid emulation. (You also didn't mention the third method through the mmu_update hypercall.) > Why cannot apply writable page table to PDT entries? It would at least be troublesome in the hypervisor. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 07:50:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 07:50:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJgBg-0001sm-Jm; Thu, 04 Oct 2012 07:49:40 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with smtp (Exim 4.72) (envelope-from ) id 1TJgBe-0001s5-Pu for Xen-devel@lists.xen.org; Thu, 04 Oct 2012 07:49:39 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1349336969!7303749!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.3 required=7.0 tests=MAILTO_TO_SPAM_ADDR X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23054 invoked from network); 4 Oct 2012 07:49:30 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-5.tower-27.messagelabs.com with SMTP; 4 Oct 2012 07:49:30 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 04 Oct 2012 08:49:29 +0100 Message-Id: <506D5BA8020000780009F8C6@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Thu, 04 Oct 2012 08:49:28 +0100 From: "Jan Beulich" To: "Xinxin Jin" References: In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: Xen-devel@lists.xen.org Subject: Re: [Xen-devel] How does Xen implement writable page table ? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 03.10.12 at 22:28, Xinxin Jin wrote: > Hi everyone, > If I follow the source code correctly, fixup_page_fault() -> > ptwr_do_page_fault handles the write attempts to a page table. In my > understanding, guests update page table through two ways: > 1) Issue hypercall update_va_mapping to update PDT; > 2) Modify writable bottom-level ptes and then trap to Xen's > ptwr_do_page_fualt > Here is my confusion: Why Xen supports two page table updating mechanisms? This allows balancing between the amount of changes in the guest side code - basic functionality would only require higher level page table updates to a para-virtualized, while performance considerations would call for all of the updates to avoid emulation. (You also didn't mention the third method through the mmu_update hypercall.) > Why cannot apply writable page table to PDT entries? It would at least be troublesome in the hypervisor. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 08:16:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 08:16:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJgav-0003I2-Ih; Thu, 04 Oct 2012 08:15:45 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJgau-0003Hv-IZ for Xen-devel@lists.xensource.com; Thu, 04 Oct 2012 08:15:44 +0000 Received: from [85.158.143.99:24803] by server-3.bemta-4.messagelabs.com id A1/6E-10986-FA54D605; Thu, 04 Oct 2012 08:15:43 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1349338530!26556112!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMwMTc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28929 invoked from network); 4 Oct 2012 08:15:30 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 08:15:30 -0000 X-IronPort-AV: E=Sophos;i="4.80,533,1344211200"; d="scan'208";a="14932548" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 08:15:30 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 09:15:30 +0100 Message-ID: <1349338526.650.204.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Konrad Rzeszutek Wilk Date: Thu, 4 Oct 2012 09:15:26 +0100 In-Reply-To: <20121003203956.GA7526@phenom.dumpdata.com> References: <20120921121202.3163c379@mantra.us.oracle.com> <1348581263.11229.21.camel@zakaz.uk.xensource.com> <20121001142826.1ebf7b0f@mantra.us.oracle.com> <1349170528.650.18.camel@zakaz.uk.xensource.com> <20121003121122.0f20d5ed@mantra.us.oracle.com> <20121003203956.GA7526@phenom.dumpdata.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v1 0/8]: PVH (PV guest with extensions) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-10-03 at 21:39 +0100, Konrad Rzeszutek Wilk wrote: > > You Ok with XEN_ELFNOTE_GUEST_PVH, or should I call it > > XEN_ELFNOTE_PV_EXTENSIONS. Please LMK. My intention was that you add XENFEAT_supervisor_mode_kernel et al. to the existing XEN_ELFNOTE_FEATURES note rather than adding a whole new note. I some how missed that this is what you were doing above. e.g. what I meant was: in Kconfig: config XEN_X86_PVH bool "Support for running as a PVH guest (EXPERIMENTAL)" depends X86_64 && <..etc..> && EXPERIMENTAL help This option enables support for running as a PVH guest (PV guest using hardware extensions) under a suitably capable hypervisor. This option is EXPERIMETNAL because the hypervisor interfaces which it uses are not yet considered stable therefore backwards and forwards compatibility is not yet guaranteed. If unsure, say N. Adjust the depends to suit reality. I thought we had that second paragraph for ARM too, but it seems like I was wrong, we should probably add it. then in xen-head.S (adjusted for features actually used by PVH): #ifdef CONFIG_XEN_X86_PVH #define FEATURES_PVH "XENFEAT_writable_descriptor_tables|" \ "XENFEAT_auto_translated_physmap|" \ "XENFEAT_supervisor_mode_kernel" \ "XENFEAT_hvm_callback_vector" #else #define FEATURES_PVH /* Not supported */ #endif ... ELFNOTE(Xen, XEN_ELFNOTE_FEATURES, .asciz "!writable_page_tables|pae_pgdir_above_4gb"FEATURES_PVH) ... I don't think we need to define a XENFEAT_pvh (or whatever it might be called) since don't need it in the code so there's no need to define/use it here. If/when we need something like that we can add it, or preferably some more specific thing for the use case which crops up. > XEN_ELFNOTE_PVH_FEATURES ? > > That way you can fill it with different 'features' flags > if need to. Say 1<<1 is basic, etc. I don't think we need a PVH specific ELF note which just replicates the XENFEAT infrastructure at this stage, if we do come to that then it would be better to give PVH its own leaf in the existing feature space (e.g. starting at 1*32+0). Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 08:16:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 08:16:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJgav-0003I2-Ih; Thu, 04 Oct 2012 08:15:45 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJgau-0003Hv-IZ for Xen-devel@lists.xensource.com; Thu, 04 Oct 2012 08:15:44 +0000 Received: from [85.158.143.99:24803] by server-3.bemta-4.messagelabs.com id A1/6E-10986-FA54D605; Thu, 04 Oct 2012 08:15:43 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1349338530!26556112!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMwMTc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28929 invoked from network); 4 Oct 2012 08:15:30 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 08:15:30 -0000 X-IronPort-AV: E=Sophos;i="4.80,533,1344211200"; d="scan'208";a="14932548" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 08:15:30 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 09:15:30 +0100 Message-ID: <1349338526.650.204.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Konrad Rzeszutek Wilk Date: Thu, 4 Oct 2012 09:15:26 +0100 In-Reply-To: <20121003203956.GA7526@phenom.dumpdata.com> References: <20120921121202.3163c379@mantra.us.oracle.com> <1348581263.11229.21.camel@zakaz.uk.xensource.com> <20121001142826.1ebf7b0f@mantra.us.oracle.com> <1349170528.650.18.camel@zakaz.uk.xensource.com> <20121003121122.0f20d5ed@mantra.us.oracle.com> <20121003203956.GA7526@phenom.dumpdata.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v1 0/8]: PVH (PV guest with extensions) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-10-03 at 21:39 +0100, Konrad Rzeszutek Wilk wrote: > > You Ok with XEN_ELFNOTE_GUEST_PVH, or should I call it > > XEN_ELFNOTE_PV_EXTENSIONS. Please LMK. My intention was that you add XENFEAT_supervisor_mode_kernel et al. to the existing XEN_ELFNOTE_FEATURES note rather than adding a whole new note. I some how missed that this is what you were doing above. e.g. what I meant was: in Kconfig: config XEN_X86_PVH bool "Support for running as a PVH guest (EXPERIMENTAL)" depends X86_64 && <..etc..> && EXPERIMENTAL help This option enables support for running as a PVH guest (PV guest using hardware extensions) under a suitably capable hypervisor. This option is EXPERIMETNAL because the hypervisor interfaces which it uses are not yet considered stable therefore backwards and forwards compatibility is not yet guaranteed. If unsure, say N. Adjust the depends to suit reality. I thought we had that second paragraph for ARM too, but it seems like I was wrong, we should probably add it. then in xen-head.S (adjusted for features actually used by PVH): #ifdef CONFIG_XEN_X86_PVH #define FEATURES_PVH "XENFEAT_writable_descriptor_tables|" \ "XENFEAT_auto_translated_physmap|" \ "XENFEAT_supervisor_mode_kernel" \ "XENFEAT_hvm_callback_vector" #else #define FEATURES_PVH /* Not supported */ #endif ... ELFNOTE(Xen, XEN_ELFNOTE_FEATURES, .asciz "!writable_page_tables|pae_pgdir_above_4gb"FEATURES_PVH) ... I don't think we need to define a XENFEAT_pvh (or whatever it might be called) since don't need it in the code so there's no need to define/use it here. If/when we need something like that we can add it, or preferably some more specific thing for the use case which crops up. > XEN_ELFNOTE_PVH_FEATURES ? > > That way you can fill it with different 'features' flags > if need to. Say 1<<1 is basic, etc. I don't think we need a PVH specific ELF note which just replicates the XENFEAT infrastructure at this stage, if we do come to that then it would be better to give PVH its own leaf in the existing feature space (e.g. starting at 1*32+0). Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 08:18:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 08:18:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJgd7-0003SB-P7; Thu, 04 Oct 2012 08:18:01 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJgd6-0003S4-8Z for Xen-devel@lists.xensource.com; Thu, 04 Oct 2012 08:18:00 +0000 Received: from [85.158.143.99:36220] by server-3.bemta-4.messagelabs.com id AA/12-10986-7364D605; Thu, 04 Oct 2012 08:17:59 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1349338679!32796556!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMwMTc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28940 invoked from network); 4 Oct 2012 08:17:59 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 08:17:59 -0000 X-IronPort-AV: E=Sophos;i="4.80,533,1344211200"; d="scan'208";a="14932616" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 08:17:22 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 09:17:22 +0100 Message-ID: <1349338640.650.206.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Mukesh Rathor Date: Thu, 4 Oct 2012 09:17:20 +0100 In-Reply-To: <20121003152600.1a9e2034@mantra.us.oracle.com> References: <20120921121202.3163c379@mantra.us.oracle.com> <1348581263.11229.21.camel@zakaz.uk.xensource.com> <20121001142826.1ebf7b0f@mantra.us.oracle.com> <20121002130911.GD9009@phenom.dumpdata.com> <20121002115552.3a5d5196@mantra.us.oracle.com> <1349259844.650.123.camel@zakaz.uk.xensource.com> <20121003152600.1a9e2034@mantra.us.oracle.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 0/8]: PVH (PV guest with extensions) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-10-03 at 23:26 +0100, Mukesh Rathor wrote: > On Wed, 3 Oct 2012 11:24:04 +0100 > Ian Campbell wrote: > > > On Tue, 2012-10-02 at 19:55 +0100, Mukesh Rathor wrote: > > > On Tue, 2 Oct 2012 09:09:11 -0400 > > > Konrad Rzeszutek Wilk wrote: > > > > > > > > > > > Strange, adding following to head.S > > > > > > > > > > ELFNOTE(Xen, XEN_ELFNOTE_PADDR_OFFSET, _ASM_PTR 0) > > > > > ELFNOTE(Xen, XEN_ELFNOTE_GUEST_PVH, .long 1) <-------- > > > > > > > > > > and xenstore won't start in dom0. What gives? > > > > > > > > What is XEN_ELFNOTE_GUEST_PVH number? You might be re-using a > > > > value that is defined for a different purpose? Did you check the > > > > Xen hypervisor header files? > > > > > > Ah, right. I was looking at linux header file, which is behind xen. > > > > Phew! > > > > You are going to add the other features which PVH uses too, right? > > > > Ian. > > > > Sorry, confused. Not very familiar with this. You mean, something like: > > ELFNOTE(Xen, XEN_ELFNOTE_GUEST_PVH, .long 1) > ELFNOTE(Xen, XEN_ELFNOTE_PVH_FEATURES, .asciz "writable_page_tables|auto_translated_physmap|supervisor_mode_kernel|hvm_callback_vector") > > Something like this? Nearly, I meant to add them to the existing features note. I just replied to the previous mail with some more detail. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 08:18:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 08:18:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJgd7-0003SB-P7; Thu, 04 Oct 2012 08:18:01 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJgd6-0003S4-8Z for Xen-devel@lists.xensource.com; Thu, 04 Oct 2012 08:18:00 +0000 Received: from [85.158.143.99:36220] by server-3.bemta-4.messagelabs.com id AA/12-10986-7364D605; Thu, 04 Oct 2012 08:17:59 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1349338679!32796556!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMwMTc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28940 invoked from network); 4 Oct 2012 08:17:59 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 08:17:59 -0000 X-IronPort-AV: E=Sophos;i="4.80,533,1344211200"; d="scan'208";a="14932616" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 08:17:22 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 09:17:22 +0100 Message-ID: <1349338640.650.206.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Mukesh Rathor Date: Thu, 4 Oct 2012 09:17:20 +0100 In-Reply-To: <20121003152600.1a9e2034@mantra.us.oracle.com> References: <20120921121202.3163c379@mantra.us.oracle.com> <1348581263.11229.21.camel@zakaz.uk.xensource.com> <20121001142826.1ebf7b0f@mantra.us.oracle.com> <20121002130911.GD9009@phenom.dumpdata.com> <20121002115552.3a5d5196@mantra.us.oracle.com> <1349259844.650.123.camel@zakaz.uk.xensource.com> <20121003152600.1a9e2034@mantra.us.oracle.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 0/8]: PVH (PV guest with extensions) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-10-03 at 23:26 +0100, Mukesh Rathor wrote: > On Wed, 3 Oct 2012 11:24:04 +0100 > Ian Campbell wrote: > > > On Tue, 2012-10-02 at 19:55 +0100, Mukesh Rathor wrote: > > > On Tue, 2 Oct 2012 09:09:11 -0400 > > > Konrad Rzeszutek Wilk wrote: > > > > > > > > > > > Strange, adding following to head.S > > > > > > > > > > ELFNOTE(Xen, XEN_ELFNOTE_PADDR_OFFSET, _ASM_PTR 0) > > > > > ELFNOTE(Xen, XEN_ELFNOTE_GUEST_PVH, .long 1) <-------- > > > > > > > > > > and xenstore won't start in dom0. What gives? > > > > > > > > What is XEN_ELFNOTE_GUEST_PVH number? You might be re-using a > > > > value that is defined for a different purpose? Did you check the > > > > Xen hypervisor header files? > > > > > > Ah, right. I was looking at linux header file, which is behind xen. > > > > Phew! > > > > You are going to add the other features which PVH uses too, right? > > > > Ian. > > > > Sorry, confused. Not very familiar with this. You mean, something like: > > ELFNOTE(Xen, XEN_ELFNOTE_GUEST_PVH, .long 1) > ELFNOTE(Xen, XEN_ELFNOTE_PVH_FEATURES, .asciz "writable_page_tables|auto_translated_physmap|supervisor_mode_kernel|hvm_callback_vector") > > Something like this? Nearly, I meant to add them to the existing features note. I just replied to the previous mail with some more detail. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 08:19:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 08:19:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJge6-0003Xv-8e; Thu, 04 Oct 2012 08:19:02 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJge4-0003Xl-T7 for Xen-devel@lists.xensource.com; Thu, 04 Oct 2012 08:19:00 +0000 Received: from [85.158.139.211:45524] by server-13.bemta-5.messagelabs.com id 14/92-16359-4764D605; Thu, 04 Oct 2012 08:19:00 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-13.tower-206.messagelabs.com!1349338739!17042038!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMwMTc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25031 invoked from network); 4 Oct 2012 08:18:59 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 08:18:59 -0000 X-IronPort-AV: E=Sophos;i="4.80,533,1344211200"; d="scan'208";a="14932660" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 08:18:59 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 09:18:59 +0100 Message-ID: <1349338737.650.207.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Mukesh Rathor Date: Thu, 4 Oct 2012 09:18:57 +0100 In-Reply-To: <20121003112702.03845930@mantra.us.oracle.com> References: <20120921121556.1a0ea8af@mantra.us.oracle.com> <20121003112702.03845930@mantra.us.oracle.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: Konrad Rzeszutek Wilk , "Xen-devel@lists.xensource.com" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-10-03 at 19:27 +0100, Mukesh Rathor wrote: > On Mon, 24 Sep 2012 12:55:31 +0100 > Stefano Stabellini wrote: > > > There are few code style issues on this patch, I suggest you run it > > through scripts/checkpatch.pl, it should be able to catch all these > > errors. > > Oh, my bad. I was running them thru cleanpatch and not checkpatch. It's > my first linux submission, so please bear with me. I'll run them all > thru checkpatch this time. I'd never heard of cleanpatch before, looks like it is pretty obsolete (not updated since 2007 and still requires 79 char lines). Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 08:19:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 08:19:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJge6-0003Xv-8e; Thu, 04 Oct 2012 08:19:02 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJge4-0003Xl-T7 for Xen-devel@lists.xensource.com; Thu, 04 Oct 2012 08:19:00 +0000 Received: from [85.158.139.211:45524] by server-13.bemta-5.messagelabs.com id 14/92-16359-4764D605; Thu, 04 Oct 2012 08:19:00 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-13.tower-206.messagelabs.com!1349338739!17042038!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMwMTc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25031 invoked from network); 4 Oct 2012 08:18:59 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 08:18:59 -0000 X-IronPort-AV: E=Sophos;i="4.80,533,1344211200"; d="scan'208";a="14932660" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 08:18:59 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 09:18:59 +0100 Message-ID: <1349338737.650.207.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Mukesh Rathor Date: Thu, 4 Oct 2012 09:18:57 +0100 In-Reply-To: <20121003112702.03845930@mantra.us.oracle.com> References: <20120921121556.1a0ea8af@mantra.us.oracle.com> <20121003112702.03845930@mantra.us.oracle.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: Konrad Rzeszutek Wilk , "Xen-devel@lists.xensource.com" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-10-03 at 19:27 +0100, Mukesh Rathor wrote: > On Mon, 24 Sep 2012 12:55:31 +0100 > Stefano Stabellini wrote: > > > There are few code style issues on this patch, I suggest you run it > > through scripts/checkpatch.pl, it should be able to catch all these > > errors. > > Oh, my bad. I was running them thru cleanpatch and not checkpatch. It's > my first linux submission, so please bear with me. I'll run them all > thru checkpatch this time. I'd never heard of cleanpatch before, looks like it is pretty obsolete (not updated since 2007 and still requires 79 char lines). Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 08:24:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 08:24:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJgjN-0003ro-8V; Thu, 04 Oct 2012 08:24:29 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with smtp (Exim 4.72) (envelope-from ) id 1TJfw9-0001ab-UB for xen-devel@lists.xen.org; Thu, 04 Oct 2012 07:33:38 +0000 X-Env-Sender: kristoffer@itoc.dk X-Msg-Ref: server-12.tower-27.messagelabs.com!1349336010!8777395!1 X-Originating-IP: [77.66.16.14] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30890 invoked from network); 4 Oct 2012 07:33:30 -0000 Received: from mail01.itoc.dk (HELO hosting01.itoc.dk) (77.66.16.14) by server-12.tower-27.messagelabs.com with SMTP; 4 Oct 2012 07:33:30 -0000 Received: from localhost (hosting01.ultraslice.com [127.0.0.1]) by hosting01.itoc.dk (Postfix) with ESMTP id 9CBD43C3C0A0B for ; Thu, 4 Oct 2012 09:33:29 +0200 (CEST) Received: from hosting01.itoc.dk ([127.0.0.1]) by localhost (hosting01.itoc.dk [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 20983-09 for ; Thu, 4 Oct 2012 09:33:28 +0200 (CEST) Received: from [10.0.1.52] (0x573fe6e2.cpe.ge-1-1-0-1104.vbrnqu1.customer.tele.dk [87.63.230.226]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: kristoffer@itoc.dk) by hosting01.itoc.dk (Postfix) with ESMTPSA id BAAE73C3C0A09 for ; Thu, 4 Oct 2012 09:33:28 +0200 (CEST) From: Kristoffer Egefelt Message-Id: <1672AF40-A2FD-4D58-93B2-1B8C506A799A@itoc.dk> Date: Thu, 4 Oct 2012 09:33:30 +0200 To: Xen-devel@lists.xen.org Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) X-Mailer: Apple Mail (2.1486) X-Virus-Scanned: Maia Mailguard 1.0.2 X-Mailman-Approved-At: Thu, 04 Oct 2012 08:24:27 +0000 Subject: [Xen-devel] Blktap userspace utils X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hi, I'd like to use the blktap utils from https://github.com/xen-org/blktap because of the mirror feature, as the blktap utils comming with xen does not support this. Could anybody explain why there are two different blktap utils (one in git and one comming with xen source) and how to compile the one from git so that it works with libxl ? Any pointers greatly appreciated ;-) Thanks Regards Kristoffer _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 08:24:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 08:24:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJgjN-0003ro-8V; Thu, 04 Oct 2012 08:24:29 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with smtp (Exim 4.72) (envelope-from ) id 1TJfw9-0001ab-UB for xen-devel@lists.xen.org; Thu, 04 Oct 2012 07:33:38 +0000 X-Env-Sender: kristoffer@itoc.dk X-Msg-Ref: server-12.tower-27.messagelabs.com!1349336010!8777395!1 X-Originating-IP: [77.66.16.14] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30890 invoked from network); 4 Oct 2012 07:33:30 -0000 Received: from mail01.itoc.dk (HELO hosting01.itoc.dk) (77.66.16.14) by server-12.tower-27.messagelabs.com with SMTP; 4 Oct 2012 07:33:30 -0000 Received: from localhost (hosting01.ultraslice.com [127.0.0.1]) by hosting01.itoc.dk (Postfix) with ESMTP id 9CBD43C3C0A0B for ; Thu, 4 Oct 2012 09:33:29 +0200 (CEST) Received: from hosting01.itoc.dk ([127.0.0.1]) by localhost (hosting01.itoc.dk [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 20983-09 for ; Thu, 4 Oct 2012 09:33:28 +0200 (CEST) Received: from [10.0.1.52] (0x573fe6e2.cpe.ge-1-1-0-1104.vbrnqu1.customer.tele.dk [87.63.230.226]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: kristoffer@itoc.dk) by hosting01.itoc.dk (Postfix) with ESMTPSA id BAAE73C3C0A09 for ; Thu, 4 Oct 2012 09:33:28 +0200 (CEST) From: Kristoffer Egefelt Message-Id: <1672AF40-A2FD-4D58-93B2-1B8C506A799A@itoc.dk> Date: Thu, 4 Oct 2012 09:33:30 +0200 To: Xen-devel@lists.xen.org Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) X-Mailer: Apple Mail (2.1486) X-Virus-Scanned: Maia Mailguard 1.0.2 X-Mailman-Approved-At: Thu, 04 Oct 2012 08:24:27 +0000 Subject: [Xen-devel] Blktap userspace utils X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hi, I'd like to use the blktap utils from https://github.com/xen-org/blktap because of the mirror feature, as the blktap utils comming with xen does not support this. Could anybody explain why there are two different blktap utils (one in git and one comming with xen source) and how to compile the one from git so that it works with libxl ? Any pointers greatly appreciated ;-) Thanks Regards Kristoffer _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 08:28:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 08:28:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJgmq-0003yi-Sv; Thu, 04 Oct 2012 08:28:04 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJgmp-0003yb-AB for Xen-devel@lists.xensource.com; Thu, 04 Oct 2012 08:28:03 +0000 Received: from [85.158.137.99:54002] by server-7.bemta-3.messagelabs.com id FB/D3-15765-2984D605; Thu, 04 Oct 2012 08:28:02 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-217.messagelabs.com!1349339281!14866619!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMwMTc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18752 invoked from network); 4 Oct 2012 08:28:01 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 08:28:01 -0000 X-IronPort-AV: E=Sophos;i="4.80,533,1344211200"; d="scan'208";a="14932851" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 08:28:01 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 09:28:01 +0100 Message-ID: <1349339279.650.214.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Mukesh Rathor Date: Thu, 4 Oct 2012 09:27:59 +0100 In-Reply-To: <20121003152925.5af3a658@mantra.us.oracle.com> References: <20120921121556.1a0ea8af@mantra.us.oracle.com> <1349278963.650.164.camel@zakaz.uk.xensource.com> <20121003152925.5af3a658@mantra.us.oracle.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-10-03 at 23:29 +0100, Mukesh Rathor wrote: > On Wed, 3 Oct 2012 16:42:43 +0100 > Ian Campbell wrote: > > > > > > diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h > > > index 6a198e4..6c5ad83 100644 > > > --- a/include/xen/xen-ops.h > > > +++ b/include/xen/xen-ops.h > > > @@ -24,9 +24,19 @@ int xen_create_contiguous_region(unsigned long > > > vstart, unsigned int order, void > > > xen_destroy_contiguous_region(unsigned long vstart, unsigned int > > > order); struct vm_area_struct; > > > +struct xen_pvh_pfn_info; > > > > If you move the struct def'n up you don't need this forward decl. > > > > > int xen_remap_domain_mfn_range(struct vm_area_struct *vma, > > > unsigned long addr, > > > unsigned long mfn, int nr, > > > - pgprot_t prot, unsigned domid); > > > + pgprot_t prot, unsigned domid, > > > + struct xen_pvh_pfn_info *pvhp); > > > +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma, > > > + struct xen_pvh_pfn_info *pvhp); > > > + > > > +struct xen_pvh_pfn_info { > > > > Can we call this xen_remap_mfn_info or something? PVH is x86 specific > > while this struct is also useful on ARM. > > I already renamed it to: xen_xlat_pfn_info. What does xlat refer to here? I don't think we translate anything with this struct. > > > + struct page **pi_paga; /* pfn info page > > > array */ > > > > can we just call this "pages"? paga is pretty meaningless. > > page array! i can rename page_array or page_a. What's wrong with pages? It's short (some of the lines using this stuff are necessarily pretty long) and obvious. > > > + int pi_num_pgs; > > > + int pi_next_todo; > > > > I don't think we need the pi_ prefix for any of these. > > The prefix for fields in struct make it easy to find via cscope or > grep, otherwise, it's a nightmare to find common field names like > pages when reading code. I really get frustrated. I prefer prefixing > all field names. It's not common practice in Linux to do so but fair enough. While implementing the ARM version of this interface it occurred to me that the num_pgs and next_todo fields here are not really needed across the arch interface e.g. you already get pi_num_pgs from the nr argument to xen_remap_domain_mfn_range and pi_next_todo is really state which fits in struct pvh_remap_data. That would mean that remap_foo could take a struct page * directly and I think you would save an allocation. I may look into implementing that change as I code up the ARM side. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 08:28:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 08:28:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJgmq-0003yi-Sv; Thu, 04 Oct 2012 08:28:04 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJgmp-0003yb-AB for Xen-devel@lists.xensource.com; Thu, 04 Oct 2012 08:28:03 +0000 Received: from [85.158.137.99:54002] by server-7.bemta-3.messagelabs.com id FB/D3-15765-2984D605; Thu, 04 Oct 2012 08:28:02 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-217.messagelabs.com!1349339281!14866619!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMwMTc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18752 invoked from network); 4 Oct 2012 08:28:01 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 08:28:01 -0000 X-IronPort-AV: E=Sophos;i="4.80,533,1344211200"; d="scan'208";a="14932851" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 08:28:01 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 09:28:01 +0100 Message-ID: <1349339279.650.214.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Mukesh Rathor Date: Thu, 4 Oct 2012 09:27:59 +0100 In-Reply-To: <20121003152925.5af3a658@mantra.us.oracle.com> References: <20120921121556.1a0ea8af@mantra.us.oracle.com> <1349278963.650.164.camel@zakaz.uk.xensource.com> <20121003152925.5af3a658@mantra.us.oracle.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-10-03 at 23:29 +0100, Mukesh Rathor wrote: > On Wed, 3 Oct 2012 16:42:43 +0100 > Ian Campbell wrote: > > > > > > diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h > > > index 6a198e4..6c5ad83 100644 > > > --- a/include/xen/xen-ops.h > > > +++ b/include/xen/xen-ops.h > > > @@ -24,9 +24,19 @@ int xen_create_contiguous_region(unsigned long > > > vstart, unsigned int order, void > > > xen_destroy_contiguous_region(unsigned long vstart, unsigned int > > > order); struct vm_area_struct; > > > +struct xen_pvh_pfn_info; > > > > If you move the struct def'n up you don't need this forward decl. > > > > > int xen_remap_domain_mfn_range(struct vm_area_struct *vma, > > > unsigned long addr, > > > unsigned long mfn, int nr, > > > - pgprot_t prot, unsigned domid); > > > + pgprot_t prot, unsigned domid, > > > + struct xen_pvh_pfn_info *pvhp); > > > +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma, > > > + struct xen_pvh_pfn_info *pvhp); > > > + > > > +struct xen_pvh_pfn_info { > > > > Can we call this xen_remap_mfn_info or something? PVH is x86 specific > > while this struct is also useful on ARM. > > I already renamed it to: xen_xlat_pfn_info. What does xlat refer to here? I don't think we translate anything with this struct. > > > + struct page **pi_paga; /* pfn info page > > > array */ > > > > can we just call this "pages"? paga is pretty meaningless. > > page array! i can rename page_array or page_a. What's wrong with pages? It's short (some of the lines using this stuff are necessarily pretty long) and obvious. > > > + int pi_num_pgs; > > > + int pi_next_todo; > > > > I don't think we need the pi_ prefix for any of these. > > The prefix for fields in struct make it easy to find via cscope or > grep, otherwise, it's a nightmare to find common field names like > pages when reading code. I really get frustrated. I prefer prefixing > all field names. It's not common practice in Linux to do so but fair enough. While implementing the ARM version of this interface it occurred to me that the num_pgs and next_todo fields here are not really needed across the arch interface e.g. you already get pi_num_pgs from the nr argument to xen_remap_domain_mfn_range and pi_next_todo is really state which fits in struct pvh_remap_data. That would mean that remap_foo could take a struct page * directly and I think you would save an allocation. I may look into implementing that change as I code up the ARM side. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 08:31:57 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 08:31:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJgqL-00047e-HH; Thu, 04 Oct 2012 08:31:41 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJgqK-00047W-6R for Xen-devel@lists.xensource.com; Thu, 04 Oct 2012 08:31:40 +0000 Received: from [85.158.137.99:37252] by server-3.bemta-3.messagelabs.com id EE/30-25962-B694D605; Thu, 04 Oct 2012 08:31:39 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-7.tower-217.messagelabs.com!1349339498!15434553!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMwMTc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27532 invoked from network); 4 Oct 2012 08:31:38 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 08:31:38 -0000 X-IronPort-AV: E=Sophos;i="4.80,533,1344211200"; d="scan'208";a="14932932" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 08:31:38 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 09:31:38 +0100 Message-ID: <1349339496.650.216.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Mukesh Rathor Date: Thu, 4 Oct 2012 09:31:36 +0100 In-Reply-To: <20121003152925.5af3a658@mantra.us.oracle.com> References: <20120921121556.1a0ea8af@mantra.us.oracle.com> <1349278963.650.164.camel@zakaz.uk.xensource.com> <20121003152925.5af3a658@mantra.us.oracle.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-10-03 at 23:29 +0100, Mukesh Rathor wrote: > On Wed, 3 Oct 2012 16:42:43 +0100 > Ian Campbell wrote: > > > > > > diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h > > > index 6a198e4..6c5ad83 100644 > > > --- a/include/xen/xen-ops.h > > > +++ b/include/xen/xen-ops.h > > > @@ -24,9 +24,19 @@ int xen_create_contiguous_region(unsigned long > > > vstart, unsigned int order, void > > > xen_destroy_contiguous_region(unsigned long vstart, unsigned int > > > order); struct vm_area_struct; > > > +struct xen_pvh_pfn_info; > > > > If you move the struct def'n up you don't need this forward decl. > > > > > int xen_remap_domain_mfn_range(struct vm_area_struct *vma, > > > unsigned long addr, > > > unsigned long mfn, int nr, > > > - pgprot_t prot, unsigned domid); > > > + pgprot_t prot, unsigned domid, > > > + struct xen_pvh_pfn_info *pvhp); > > > +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma, > > > + struct xen_pvh_pfn_info *pvhp); > > > + > > > +struct xen_pvh_pfn_info { > > > > Can we call this xen_remap_mfn_info or something? PVH is x86 specific > > while this struct is also useful on ARM. > > I already renamed it to: xen_xlat_pfn_info. BTW, where can I find you latest patches? I've just noticed that you've not been CCing LKML with this series -- was that deliberate? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 08:31:57 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 08:31:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJgqL-00047e-HH; Thu, 04 Oct 2012 08:31:41 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJgqK-00047W-6R for Xen-devel@lists.xensource.com; Thu, 04 Oct 2012 08:31:40 +0000 Received: from [85.158.137.99:37252] by server-3.bemta-3.messagelabs.com id EE/30-25962-B694D605; Thu, 04 Oct 2012 08:31:39 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-7.tower-217.messagelabs.com!1349339498!15434553!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMwMTc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27532 invoked from network); 4 Oct 2012 08:31:38 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 08:31:38 -0000 X-IronPort-AV: E=Sophos;i="4.80,533,1344211200"; d="scan'208";a="14932932" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 08:31:38 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 09:31:38 +0100 Message-ID: <1349339496.650.216.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Mukesh Rathor Date: Thu, 4 Oct 2012 09:31:36 +0100 In-Reply-To: <20121003152925.5af3a658@mantra.us.oracle.com> References: <20120921121556.1a0ea8af@mantra.us.oracle.com> <1349278963.650.164.camel@zakaz.uk.xensource.com> <20121003152925.5af3a658@mantra.us.oracle.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-10-03 at 23:29 +0100, Mukesh Rathor wrote: > On Wed, 3 Oct 2012 16:42:43 +0100 > Ian Campbell wrote: > > > > > > diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h > > > index 6a198e4..6c5ad83 100644 > > > --- a/include/xen/xen-ops.h > > > +++ b/include/xen/xen-ops.h > > > @@ -24,9 +24,19 @@ int xen_create_contiguous_region(unsigned long > > > vstart, unsigned int order, void > > > xen_destroy_contiguous_region(unsigned long vstart, unsigned int > > > order); struct vm_area_struct; > > > +struct xen_pvh_pfn_info; > > > > If you move the struct def'n up you don't need this forward decl. > > > > > int xen_remap_domain_mfn_range(struct vm_area_struct *vma, > > > unsigned long addr, > > > unsigned long mfn, int nr, > > > - pgprot_t prot, unsigned domid); > > > + pgprot_t prot, unsigned domid, > > > + struct xen_pvh_pfn_info *pvhp); > > > +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma, > > > + struct xen_pvh_pfn_info *pvhp); > > > + > > > +struct xen_pvh_pfn_info { > > > > Can we call this xen_remap_mfn_info or something? PVH is x86 specific > > while this struct is also useful on ARM. > > I already renamed it to: xen_xlat_pfn_info. BTW, where can I find you latest patches? I've just noticed that you've not been CCing LKML with this series -- was that deliberate? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 08:34:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 08:34:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJgsk-0004Fi-3T; Thu, 04 Oct 2012 08:34:10 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJgsi-0004Fd-8A for xen-devel@lists.xen.org; Thu, 04 Oct 2012 08:34:08 +0000 Received: from [85.158.143.99:59249] by server-1.bemta-4.messagelabs.com id 22/5F-05684-FF94D605; Thu, 04 Oct 2012 08:34:07 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1349339646!23200251!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMwMTc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15615 invoked from network); 4 Oct 2012 08:34:06 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 08:34:06 -0000 X-IronPort-AV: E=Sophos;i="4.80,533,1344211200"; d="scan'208";a="14933002" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 08:34:06 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 09:34:06 +0100 Message-ID: <1349339644.650.217.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Jim Fehlig Date: Thu, 4 Oct 2012 09:34:04 +0100 In-Reply-To: <50626355.7080402@suse.com> References: <201209191918.35305.hahn@univention.de> <201209201340.52218.hahn@univention.de> <505B88A1.1070701@suse.com> <505C4A82.2040305@eu.citrix.com> <50626355.7080402@suse.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: George Dunlap , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Xen 4.3 development update X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-09-26 at 03:07 +0100, Jim Fehlig wrote: > George Dunlap wrote: > > On 20/09/12 22:20, Jim Fehlig wrote: > >> Chun Yan Liu was working on a patch to implement migration in the > >> libvirt libxl > >> driver, but she wasn't able to finish tidying the patch before > >> departing on > >> maternity leave. She recently returned to work and I'd expect a > >> refreshed patch > >> soon - after working through her backlog. > >> > >> But why is libvirt integration listed as a Xen 4.3 feature? AFAIK, > >> all of this > >> work is in libvirt and really doesn't have much to do with the > >> release of 4.3. > > For one, as Ian said, we want xl/libxl to be the default toolstack in > > 4.3; as soon as possible we want to remove xend. > > Good :). > > > > > But from a broader perspective, the idea is for the Xen.org community > > to be thinking strategically about the success of the Xen project as a > > whole. Things like distro support and libvirt integration are > > absolutely critical to Xen's success in the open-source ecosystem. So > > while we don't have to do everything ourselves, we want to think about > > what things need to be done, track them to make sure that *someone* > > does them; and be prepared to pick them up ourselves if necessary. > > And it just makes more sense to track everything on one list. > > > > Does that make sense? > > Yes, it does. I'm actually quite happy to hear this statement of > support for the broader ecosystem! BTW, I've been meaning to ask, and it's kind of the flipside of this so I'll mention it here -- would it be possible for you (or whoever is sending patches) to CC xen-devel with Xen related patches to libvirt? Partly just to raise the visibility of the libvirt integration on the Xen side but also at least I am interested to see how libxl is being used outside of xl and what sorts of issues etc you guys are having. I suppose there would also be other benefits to review from libxl folks of patches which consume the APIs. Thanks, Ian. > > WRT libvirt support for libxl in Xen >= 4.2, SUSE will be contributing > some work. Just today I had to disable the driver in our Factory > libvirt builds where we now have Xen 4.2. This hack can't last for long. > > Regards, > Jim > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 08:34:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 08:34:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJgsk-0004Fi-3T; Thu, 04 Oct 2012 08:34:10 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJgsi-0004Fd-8A for xen-devel@lists.xen.org; Thu, 04 Oct 2012 08:34:08 +0000 Received: from [85.158.143.99:59249] by server-1.bemta-4.messagelabs.com id 22/5F-05684-FF94D605; Thu, 04 Oct 2012 08:34:07 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1349339646!23200251!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMwMTc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15615 invoked from network); 4 Oct 2012 08:34:06 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 08:34:06 -0000 X-IronPort-AV: E=Sophos;i="4.80,533,1344211200"; d="scan'208";a="14933002" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 08:34:06 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 09:34:06 +0100 Message-ID: <1349339644.650.217.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Jim Fehlig Date: Thu, 4 Oct 2012 09:34:04 +0100 In-Reply-To: <50626355.7080402@suse.com> References: <201209191918.35305.hahn@univention.de> <201209201340.52218.hahn@univention.de> <505B88A1.1070701@suse.com> <505C4A82.2040305@eu.citrix.com> <50626355.7080402@suse.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: George Dunlap , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Xen 4.3 development update X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-09-26 at 03:07 +0100, Jim Fehlig wrote: > George Dunlap wrote: > > On 20/09/12 22:20, Jim Fehlig wrote: > >> Chun Yan Liu was working on a patch to implement migration in the > >> libvirt libxl > >> driver, but she wasn't able to finish tidying the patch before > >> departing on > >> maternity leave. She recently returned to work and I'd expect a > >> refreshed patch > >> soon - after working through her backlog. > >> > >> But why is libvirt integration listed as a Xen 4.3 feature? AFAIK, > >> all of this > >> work is in libvirt and really doesn't have much to do with the > >> release of 4.3. > > For one, as Ian said, we want xl/libxl to be the default toolstack in > > 4.3; as soon as possible we want to remove xend. > > Good :). > > > > > But from a broader perspective, the idea is for the Xen.org community > > to be thinking strategically about the success of the Xen project as a > > whole. Things like distro support and libvirt integration are > > absolutely critical to Xen's success in the open-source ecosystem. So > > while we don't have to do everything ourselves, we want to think about > > what things need to be done, track them to make sure that *someone* > > does them; and be prepared to pick them up ourselves if necessary. > > And it just makes more sense to track everything on one list. > > > > Does that make sense? > > Yes, it does. I'm actually quite happy to hear this statement of > support for the broader ecosystem! BTW, I've been meaning to ask, and it's kind of the flipside of this so I'll mention it here -- would it be possible for you (or whoever is sending patches) to CC xen-devel with Xen related patches to libvirt? Partly just to raise the visibility of the libvirt integration on the Xen side but also at least I am interested to see how libxl is being used outside of xl and what sorts of issues etc you guys are having. I suppose there would also be other benefits to review from libxl folks of patches which consume the APIs. Thanks, Ian. > > WRT libvirt support for libxl in Xen >= 4.2, SUSE will be contributing > some work. Just today I had to disable the driver in our Factory > libvirt builds where we now have Xen 4.2. This hack can't last for long. > > Regards, > Jim > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 08:35:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 08:35:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJgu1-0004Lv-Is; Thu, 04 Oct 2012 08:35:29 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJgtz-0004Ln-TQ for xen-devel@lists.xen.org; Thu, 04 Oct 2012 08:35:28 +0000 Received: from [85.158.143.99:61712] by server-3.bemta-4.messagelabs.com id 2E/7E-10986-F4A4D605; Thu, 04 Oct 2012 08:35:27 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1349339725!24628160!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMwMTc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31693 invoked from network); 4 Oct 2012 08:35:26 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 08:35:26 -0000 X-IronPort-AV: E=Sophos;i="4.80,533,1344211200"; d="scan'208";a="14933037" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 08:35:25 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 09:35:25 +0100 Message-ID: <1349339723.650.218.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Matthew Fioravante Date: Thu, 4 Oct 2012 09:35:23 +0100 In-Reply-To: <1349194804-17973-1-git-send-email-matthew.fioravante@jhuapl.edu> References: <1349194804-17973-1-git-send-email-matthew.fioravante@jhuapl.edu> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "samuel.thibault@ens-lyon.org" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 08/12] add tpmfront, tpm_tis, and tpmback drivers to mini-os X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-10-02 at 17:20 +0100, Matthew Fioravante wrote: > This patch adds 3 new drivers to mini-os. > > tpmfront - paravirtualized tpm frontend driver > tpmback - paravirtualized tpm backend driver > tpm_tis - hardware tpm driver > > Unfortunately these drivers were derived from GPL > licensed linux kernel drivers so they must carry > the GPL license. However, since mini-os now > supports conditional compilation, hopefully these > drivers can be included into the xen tree and > conditionally removed from non-gpl projects. > By default they are disabled in the makefile. > > Signed-off-by: Matthew Fioravante > --- > Changes since last version: > * remove (or later version) clause from license Sorry, but this was only one of the things I mentioned in my last mail. But more generally I think rather than just reacting to review in this case you need to you need to take a step back and proactively (re)audit all of these files and consider for each file whether the header accurately reflects the copyright and licensing status of the files from which they are derived. IOW I'm afraid you are going to have to think about each of these files one by one. Sorry, but it is important to get copyright and licensing stuff correct. Also, please can you start adding [PATCH vN xx/yy] to your subjects so we can tell which is the latest posting. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 08:35:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 08:35:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJgu1-0004Lv-Is; Thu, 04 Oct 2012 08:35:29 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJgtz-0004Ln-TQ for xen-devel@lists.xen.org; Thu, 04 Oct 2012 08:35:28 +0000 Received: from [85.158.143.99:61712] by server-3.bemta-4.messagelabs.com id 2E/7E-10986-F4A4D605; Thu, 04 Oct 2012 08:35:27 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1349339725!24628160!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMwMTc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31693 invoked from network); 4 Oct 2012 08:35:26 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 08:35:26 -0000 X-IronPort-AV: E=Sophos;i="4.80,533,1344211200"; d="scan'208";a="14933037" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 08:35:25 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 09:35:25 +0100 Message-ID: <1349339723.650.218.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Matthew Fioravante Date: Thu, 4 Oct 2012 09:35:23 +0100 In-Reply-To: <1349194804-17973-1-git-send-email-matthew.fioravante@jhuapl.edu> References: <1349194804-17973-1-git-send-email-matthew.fioravante@jhuapl.edu> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "samuel.thibault@ens-lyon.org" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 08/12] add tpmfront, tpm_tis, and tpmback drivers to mini-os X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-10-02 at 17:20 +0100, Matthew Fioravante wrote: > This patch adds 3 new drivers to mini-os. > > tpmfront - paravirtualized tpm frontend driver > tpmback - paravirtualized tpm backend driver > tpm_tis - hardware tpm driver > > Unfortunately these drivers were derived from GPL > licensed linux kernel drivers so they must carry > the GPL license. However, since mini-os now > supports conditional compilation, hopefully these > drivers can be included into the xen tree and > conditionally removed from non-gpl projects. > By default they are disabled in the makefile. > > Signed-off-by: Matthew Fioravante > --- > Changes since last version: > * remove (or later version) clause from license Sorry, but this was only one of the things I mentioned in my last mail. But more generally I think rather than just reacting to review in this case you need to you need to take a step back and proactively (re)audit all of these files and consider for each file whether the header accurately reflects the copyright and licensing status of the files from which they are derived. IOW I'm afraid you are going to have to think about each of these files one by one. Sorry, but it is important to get copyright and licensing stuff correct. Also, please can you start adding [PATCH vN xx/yy] to your subjects so we can tell which is the latest posting. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 08:36:09 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 08:36:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJguU-0004PM-WA; Thu, 04 Oct 2012 08:35:58 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJguT-0004OU-Hz for xen-devel@lists.xensource.com; Thu, 04 Oct 2012 08:35:57 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1349339750!7859826!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMwMTc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 639 invoked from network); 4 Oct 2012 08:35:51 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 08:35:51 -0000 X-IronPort-AV: E=Sophos;i="4.80,533,1344211200"; d="scan'208";a="14933046" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 08:35:50 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 09:35:50 +0100 Message-ID: <1349339749.650.219.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Sander Eikelenboom Date: Thu, 4 Oct 2012 09:35:49 +0100 In-Reply-To: <205569501.20121003110330@eikelenboom.it> References: <1348565712.3452.141.camel@zakaz.uk.xensource.com> <15210025463.20120925171143@eikelenboom.it> <1348586949.12592.10.camel@zakaz.uk.xensource.com> <158082007.20120927221137@eikelenboom.it> <1349186538.650.69.camel@zakaz.uk.xensource.com> <205569501.20121003110330@eikelenboom.it> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Ian Jackson Subject: Re: [Xen-devel] [PATCH 0 of 3] xl and hotplug: Introduce and use shutdown and reboot xm compatibility options X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org T24gV2VkLCAyMDEyLTEwLTAzIGF0IDEwOjAzICswMTAwLCBTYW5kZXIgRWlrZWxlbmJvb20gd3Jv dGU6Cj4gVHVlc2RheSwgT2N0b2JlciAyLCAyMDEyLCA0OjAyOjE4IFBNLCB5b3Ugd3JvdGU6Cj4g Cj4gPiBPbiBUaHUsIDIwMTItMDktMjcgYXQgMjE6MTEgKzAxMDAsIFNhbmRlciBFaWtlbGVuYm9v bSB3cm90ZToKPiA+PiBUdWVzZGF5LCBTZXB0ZW1iZXIgMjUsIDIwMTIsIDU6Mjk6MDkgUE0sIHlv dSB3cm90ZToKPiA+PiAKPiA+PiA+IE9uIFR1ZSwgMjAxMi0wOS0yNSBhdCAxNjoxMSArMDEwMCwg U2FuZGVyIEVpa2VsZW5ib29tIHdyb3RlOgo+ID4+IAo+ID4+ID4+IFRoZSBvbmx5IHJlbGF0aXZl IHNpbXBsZSBpbXBsZW1lbnRhdGlvbiBpIHRob3VnaHQgb2Ygd2FzIGRpcmVjdAo+ID4+ID4+IHNo dXR0aW5nIGRvd24gYWxsLCBhbmQgd2hlbiB0aGUgLXcgcGFyYW1ldGVyIHdhcyBzZXQsIGp1c3Qg bG9vcCBhbmQKPiA+PiA+PiB3YWl0IG9uIGV2ZW50cyB1bnRpbCB0aGUgb25seSBydW5uaW5nIGRv bWFpbiBpcyBkb21haW4tMC4KPiA+PiA+PiBBbHRob3VnaCB0aGlzIGV4YWN0bHkgZG9lcyB3aGF0 IGhhcyB0byBiZSBkb25lLCBpdCBzb21laG93IHNvdW5kcyBhCj4gPj4gPj4gYml0IGRpcnR5Lgo+ ID4+IAo+ID4+ID4gSSB0aGluayB5b3UgY2FuIGFsbG9jYXRlIGFuIGFycmF5IG9mIGxpYnhsX2V2 ZW5hYmxlX2RvbWFpbl9kZWF0aCosIG9mCj4gPj4gPiBucl9kb21zIGluIHNpemUgYW5kIHRoZW4g YXMgeW91IHNodXRkb3duIGVhY2ggZG9tYWluIGNhbGwKPiA+PiA+IGxpYnhsX2V2ZW5hYmxlX2Rv bWFpbl9kZWF0aCBmb3IgaXQgdG9vLgo+ID4+IAo+ID4+ID4gVGhlbiB5b3UgbG9vcCB3YWl0aW5n IGZvciBkZXN0cm95IGV2ZW50cywgY2FsbGluZwo+ID4+ID4gbGlieGxfZXZkaXNhYmxlX2RvbWFp bl9kZWF0aCBhcyBlYWNoIGRvbWFpbiBkaWVzLCB3aGlsZSBjb3VudGluZyBiYWNrCj4gPj4gPiBm cm9tIG5yX2RvbXMgdW50aWwgMC4gV2hlbiBpdCByZWFjaGVzIDAgZXZlcnl0aGluZyB5b3UgYXNr ZWQgZm9yIGhhcwo+ID4+ID4gYmVlbiBzaHV0ZG93bi4KPiA+PiAKPiA+PiA+IE9yIHNvbWV0aGlu ZyBsaWtlIHRoYXQsIEkndmUgbm90IGFjdHVhbGx5IGltcGxlbWVudGVkIGl0IDstKQo+ID4+IAo+ ID4+ID4gSWFuLgo+ID4+IAo+ID4+IEl0J3MgdGltZSB0byBjYWxsIGRlZmVhdCwgd2l0aG91dCBw cm9wZXIgQyBza2lsbHMgaXQgc2VlbXMgYSBiaXQgdG9vCj4gPj4gaGFyZCB0byBmaWd1cmUgaXQg b3V0Lgo+IAo+ID4gVGhhdCdzIG9rLCBJJ2xsIGFkZCBpdCB0byBteSBUT0RPIHRvIHBpY2t1cCB3 aGVyZSB5b3UgbGVmdCBvZmYgKHVubGVzcwo+ID4gc29tZW9uZSBiZWF0cyBtZSB0byBpdCkuCj4g Cj4gVGh4ICEKPiBXb3VsZCBiZSBuaWNlIGZvciA0LjIuMSBzaW5jZSB0aGUgeGVuZG9tYWlucyBz dG9wIHNjcmlwdCBkb2Vzbid0Cj4gZnVuY3Rpb24gcHJvcGVybHkgd2l0aCB4bCBhcyB0b29sc3Rh Y2ssIGFuZCBub3Qgc2h1dHRpbmcgZG93biB0aGUKPiBkb21haW5zIGJ1dCBqdXN0IHB1bGxzIHRo ZSBwbHVnLgoKQWdyZWVkLgoKPiBXb3VsZCBpdCBiZSBoZWxwZnVsIHRvIHlvdSwgdG8gc2VuZCB0 aGUgZG9jIHBhdGNoZXMgYXMgd2VsbCA/CgpBYnNvbHV0ZWx5IQoKPiAKPiAKPiA+IFRoYW5rcyBm b3IgdGFraW5nIGl0IHRoaXMgZmFyISBGV0lXIHlvdSBzZWVtZWQgdG8gYmUgcHJldHR5IGNsb3Nl Lgo+IAo+ID4+IENhbid0IHNlZW0gdG8gZ2V0IHRoZSBoYW5nIG9mIGhvdyB0byBrZWVwIGEgcmVm ZXJlbmNlIHRvCj4gPj4gbGlieGxfZXZnZW5fZG9tYWluX2RlYXRoIGFuZCB1c2UgaXQgdG8gY2hl Y2sgaWYgdGhlIGRvbWlkIG9mIHRoZSBldmVudAo+ID4+IGlzIHRoZSBzYW1lIGFzIHRoYXQgZnJv bSBhIGRvbWFpbiB3ZSBhcmUgd2FpdGluZyB0byBzaHV0ZG93bi4KPiA+PiBUaGUgcmVzdCBvZiB0 aGUgY29kZSBkb2Vzbid0IGdpdmUgbWUgbXVjaCBwb2ludGVycyBzaW5jZSBhbGwgY29tbWFuZHMK PiA+PiBzZWVtIHRvIG9wZXJhdGUgb24gYSBzaW5nbGUgZG9taWQgYXQgb25jZS4KPiA+PiAKPiA+ PiBUaGUgY29uY29jdGlvbiBiZWxvdyBsZWFkcyB0bzoKPiA+PiB4bF9jbWRpbXBsLmM6IEluIGZ1 bmN0aW9uIMOic2h1dGRvd25fZG9tYWluw6I6Cj4gPj4geGxfY21kaW1wbC5jOjI3NjY6IGVycm9y OiBkZXJlZmVyZW5jaW5nIHBvaW50ZXIgdG8gaW5jb21wbGV0ZSB0eXBlCj4gCj4gPiBJbiBjYXNl IHlvdSBhcmUgaW50ZXJlc3RlZCB0aGlzIGlzIGJlY2F1c2UgdGhlIGxpYnhsX2V2Z2VuX2RvbWFp bl9kZWF0aAo+ID4gdHlwZSBpcyBvcGFxdWUgdG8gdXNlcnMgb2YgbGlieGwgc28gY29uc3RydWN0 cyBsaWtlCj4gPiBkb21haW5zX3dhaXRfc2h1dGRvd25baV0tPmRvbWlkIGFyZSBub3QgcG9zc2li bGUuCj4gCj4gPiBUaGUgYW5zd2VyIGlzIHRvIHVzZSB0aGUgM3JkIGFyZ3VtZW50IHRvIGxpYnhs X2V2ZW5hYmxlX2RvbWFpbl9kZWF0aAo+ID4gKHRoZSBvbmUgb2YgdHlwZSBsaWJ4bF9ldl91c2Vy KSB0byBwYXNzIGEgImNsb3N1cmUiLCB0aGlzIHZhbHVlIGlzCj4gPiByZXR1cm5lZCBpbiB0aGUg ZXZlbnQncyAiZm9yX3VzZXIiIGZpZWxkLiBUaGUgYXBwbGljYXRpb24gY2FuIHVzZSB0aGlzCj4g PiB0byBzdG9yZSBkYXRhIHNwZWNpZmljIHRvIHRoaXMgcGFydGljdWxhciBldmVudCAtLSBpbiB0 aGlzIGNhc2UgaXQgd291bGQKPiA+IHByb2JhYmx5IGJlIHN1ZmZpY2llbnQgdG8ganVzdCBwYXNz IHRoZSBkb21pZCBoZXJlIGJ1dCBpbiBwcmluY2lwYWwgb25lCj4gPiBjb3VsZCBwYXNzIGEgcG9p bnRlciB0byBhbnkgZGF0YXN0cnVjdHVyZS4KPiAKPiBUaGFua3MgZm9yIHRoZSBleHBsYW5hdGlv biwgYWx0aG91Z2ggaSBzdGlsbCBkb24ndCBzZWUgaG93IHRvIGFjdHVhbGx5IGNoYW5nZSB0aGUg Y29kZSB0aGUgcmlnaHQgd2F5Lgo+IAo+IAo+ID4gVGhhbmtzIGFnYWluLAo+ID4gSWFuLgo+IAo+ IAo+IAo+IAo+IAoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6 Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo= From xen-devel-bounces@lists.xen.org Thu Oct 04 08:36:09 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 08:36:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJguU-0004PM-WA; Thu, 04 Oct 2012 08:35:58 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJguT-0004OU-Hz for xen-devel@lists.xensource.com; Thu, 04 Oct 2012 08:35:57 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1349339750!7859826!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMwMTc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 639 invoked from network); 4 Oct 2012 08:35:51 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 08:35:51 -0000 X-IronPort-AV: E=Sophos;i="4.80,533,1344211200"; d="scan'208";a="14933046" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 08:35:50 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 09:35:50 +0100 Message-ID: <1349339749.650.219.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Sander Eikelenboom Date: Thu, 4 Oct 2012 09:35:49 +0100 In-Reply-To: <205569501.20121003110330@eikelenboom.it> References: <1348565712.3452.141.camel@zakaz.uk.xensource.com> <15210025463.20120925171143@eikelenboom.it> <1348586949.12592.10.camel@zakaz.uk.xensource.com> <158082007.20120927221137@eikelenboom.it> <1349186538.650.69.camel@zakaz.uk.xensource.com> <205569501.20121003110330@eikelenboom.it> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Ian Jackson Subject: Re: [Xen-devel] [PATCH 0 of 3] xl and hotplug: Introduce and use shutdown and reboot xm compatibility options X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org T24gV2VkLCAyMDEyLTEwLTAzIGF0IDEwOjAzICswMTAwLCBTYW5kZXIgRWlrZWxlbmJvb20gd3Jv dGU6Cj4gVHVlc2RheSwgT2N0b2JlciAyLCAyMDEyLCA0OjAyOjE4IFBNLCB5b3Ugd3JvdGU6Cj4g Cj4gPiBPbiBUaHUsIDIwMTItMDktMjcgYXQgMjE6MTEgKzAxMDAsIFNhbmRlciBFaWtlbGVuYm9v bSB3cm90ZToKPiA+PiBUdWVzZGF5LCBTZXB0ZW1iZXIgMjUsIDIwMTIsIDU6Mjk6MDkgUE0sIHlv dSB3cm90ZToKPiA+PiAKPiA+PiA+IE9uIFR1ZSwgMjAxMi0wOS0yNSBhdCAxNjoxMSArMDEwMCwg U2FuZGVyIEVpa2VsZW5ib29tIHdyb3RlOgo+ID4+IAo+ID4+ID4+IFRoZSBvbmx5IHJlbGF0aXZl IHNpbXBsZSBpbXBsZW1lbnRhdGlvbiBpIHRob3VnaHQgb2Ygd2FzIGRpcmVjdAo+ID4+ID4+IHNo dXR0aW5nIGRvd24gYWxsLCBhbmQgd2hlbiB0aGUgLXcgcGFyYW1ldGVyIHdhcyBzZXQsIGp1c3Qg bG9vcCBhbmQKPiA+PiA+PiB3YWl0IG9uIGV2ZW50cyB1bnRpbCB0aGUgb25seSBydW5uaW5nIGRv bWFpbiBpcyBkb21haW4tMC4KPiA+PiA+PiBBbHRob3VnaCB0aGlzIGV4YWN0bHkgZG9lcyB3aGF0 IGhhcyB0byBiZSBkb25lLCBpdCBzb21laG93IHNvdW5kcyBhCj4gPj4gPj4gYml0IGRpcnR5Lgo+ ID4+IAo+ID4+ID4gSSB0aGluayB5b3UgY2FuIGFsbG9jYXRlIGFuIGFycmF5IG9mIGxpYnhsX2V2 ZW5hYmxlX2RvbWFpbl9kZWF0aCosIG9mCj4gPj4gPiBucl9kb21zIGluIHNpemUgYW5kIHRoZW4g YXMgeW91IHNodXRkb3duIGVhY2ggZG9tYWluIGNhbGwKPiA+PiA+IGxpYnhsX2V2ZW5hYmxlX2Rv bWFpbl9kZWF0aCBmb3IgaXQgdG9vLgo+ID4+IAo+ID4+ID4gVGhlbiB5b3UgbG9vcCB3YWl0aW5n IGZvciBkZXN0cm95IGV2ZW50cywgY2FsbGluZwo+ID4+ID4gbGlieGxfZXZkaXNhYmxlX2RvbWFp bl9kZWF0aCBhcyBlYWNoIGRvbWFpbiBkaWVzLCB3aGlsZSBjb3VudGluZyBiYWNrCj4gPj4gPiBm cm9tIG5yX2RvbXMgdW50aWwgMC4gV2hlbiBpdCByZWFjaGVzIDAgZXZlcnl0aGluZyB5b3UgYXNr ZWQgZm9yIGhhcwo+ID4+ID4gYmVlbiBzaHV0ZG93bi4KPiA+PiAKPiA+PiA+IE9yIHNvbWV0aGlu ZyBsaWtlIHRoYXQsIEkndmUgbm90IGFjdHVhbGx5IGltcGxlbWVudGVkIGl0IDstKQo+ID4+IAo+ ID4+ID4gSWFuLgo+ID4+IAo+ID4+IEl0J3MgdGltZSB0byBjYWxsIGRlZmVhdCwgd2l0aG91dCBw cm9wZXIgQyBza2lsbHMgaXQgc2VlbXMgYSBiaXQgdG9vCj4gPj4gaGFyZCB0byBmaWd1cmUgaXQg b3V0Lgo+IAo+ID4gVGhhdCdzIG9rLCBJJ2xsIGFkZCBpdCB0byBteSBUT0RPIHRvIHBpY2t1cCB3 aGVyZSB5b3UgbGVmdCBvZmYgKHVubGVzcwo+ID4gc29tZW9uZSBiZWF0cyBtZSB0byBpdCkuCj4g Cj4gVGh4ICEKPiBXb3VsZCBiZSBuaWNlIGZvciA0LjIuMSBzaW5jZSB0aGUgeGVuZG9tYWlucyBz dG9wIHNjcmlwdCBkb2Vzbid0Cj4gZnVuY3Rpb24gcHJvcGVybHkgd2l0aCB4bCBhcyB0b29sc3Rh Y2ssIGFuZCBub3Qgc2h1dHRpbmcgZG93biB0aGUKPiBkb21haW5zIGJ1dCBqdXN0IHB1bGxzIHRo ZSBwbHVnLgoKQWdyZWVkLgoKPiBXb3VsZCBpdCBiZSBoZWxwZnVsIHRvIHlvdSwgdG8gc2VuZCB0 aGUgZG9jIHBhdGNoZXMgYXMgd2VsbCA/CgpBYnNvbHV0ZWx5IQoKPiAKPiAKPiA+IFRoYW5rcyBm b3IgdGFraW5nIGl0IHRoaXMgZmFyISBGV0lXIHlvdSBzZWVtZWQgdG8gYmUgcHJldHR5IGNsb3Nl Lgo+IAo+ID4+IENhbid0IHNlZW0gdG8gZ2V0IHRoZSBoYW5nIG9mIGhvdyB0byBrZWVwIGEgcmVm ZXJlbmNlIHRvCj4gPj4gbGlieGxfZXZnZW5fZG9tYWluX2RlYXRoIGFuZCB1c2UgaXQgdG8gY2hl Y2sgaWYgdGhlIGRvbWlkIG9mIHRoZSBldmVudAo+ID4+IGlzIHRoZSBzYW1lIGFzIHRoYXQgZnJv bSBhIGRvbWFpbiB3ZSBhcmUgd2FpdGluZyB0byBzaHV0ZG93bi4KPiA+PiBUaGUgcmVzdCBvZiB0 aGUgY29kZSBkb2Vzbid0IGdpdmUgbWUgbXVjaCBwb2ludGVycyBzaW5jZSBhbGwgY29tbWFuZHMK PiA+PiBzZWVtIHRvIG9wZXJhdGUgb24gYSBzaW5nbGUgZG9taWQgYXQgb25jZS4KPiA+PiAKPiA+ PiBUaGUgY29uY29jdGlvbiBiZWxvdyBsZWFkcyB0bzoKPiA+PiB4bF9jbWRpbXBsLmM6IEluIGZ1 bmN0aW9uIMOic2h1dGRvd25fZG9tYWluw6I6Cj4gPj4geGxfY21kaW1wbC5jOjI3NjY6IGVycm9y OiBkZXJlZmVyZW5jaW5nIHBvaW50ZXIgdG8gaW5jb21wbGV0ZSB0eXBlCj4gCj4gPiBJbiBjYXNl IHlvdSBhcmUgaW50ZXJlc3RlZCB0aGlzIGlzIGJlY2F1c2UgdGhlIGxpYnhsX2V2Z2VuX2RvbWFp bl9kZWF0aAo+ID4gdHlwZSBpcyBvcGFxdWUgdG8gdXNlcnMgb2YgbGlieGwgc28gY29uc3RydWN0 cyBsaWtlCj4gPiBkb21haW5zX3dhaXRfc2h1dGRvd25baV0tPmRvbWlkIGFyZSBub3QgcG9zc2li bGUuCj4gCj4gPiBUaGUgYW5zd2VyIGlzIHRvIHVzZSB0aGUgM3JkIGFyZ3VtZW50IHRvIGxpYnhs X2V2ZW5hYmxlX2RvbWFpbl9kZWF0aAo+ID4gKHRoZSBvbmUgb2YgdHlwZSBsaWJ4bF9ldl91c2Vy KSB0byBwYXNzIGEgImNsb3N1cmUiLCB0aGlzIHZhbHVlIGlzCj4gPiByZXR1cm5lZCBpbiB0aGUg ZXZlbnQncyAiZm9yX3VzZXIiIGZpZWxkLiBUaGUgYXBwbGljYXRpb24gY2FuIHVzZSB0aGlzCj4g PiB0byBzdG9yZSBkYXRhIHNwZWNpZmljIHRvIHRoaXMgcGFydGljdWxhciBldmVudCAtLSBpbiB0 aGlzIGNhc2UgaXQgd291bGQKPiA+IHByb2JhYmx5IGJlIHN1ZmZpY2llbnQgdG8ganVzdCBwYXNz IHRoZSBkb21pZCBoZXJlIGJ1dCBpbiBwcmluY2lwYWwgb25lCj4gPiBjb3VsZCBwYXNzIGEgcG9p bnRlciB0byBhbnkgZGF0YXN0cnVjdHVyZS4KPiAKPiBUaGFua3MgZm9yIHRoZSBleHBsYW5hdGlv biwgYWx0aG91Z2ggaSBzdGlsbCBkb24ndCBzZWUgaG93IHRvIGFjdHVhbGx5IGNoYW5nZSB0aGUg Y29kZSB0aGUgcmlnaHQgd2F5Lgo+IAo+IAo+ID4gVGhhbmtzIGFnYWluLAo+ID4gSWFuLgo+IAo+ IAo+IAo+IAo+IAoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6 Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo= From xen-devel-bounces@lists.xen.org Thu Oct 04 08:38:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 08:38:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJgxB-0004gX-1W; Thu, 04 Oct 2012 08:38:45 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJgx9-0004gB-BK for Xen-devel@lists.xensource.com; Thu, 04 Oct 2012 08:38:43 +0000 Received: from [85.158.143.99:23012] by server-2.bemta-4.messagelabs.com id A6/64-06610-21B4D605; Thu, 04 Oct 2012 08:38:42 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1349339921!32207196!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMwMTc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2473 invoked from network); 4 Oct 2012 08:38:42 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 08:38:42 -0000 X-IronPort-AV: E=Sophos;i="4.80,533,1344211200"; d="scan'208";a="14933105" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 08:38:41 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 09:38:41 +0100 Message-ID: <1349339920.650.220.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Mukesh Rathor Date: Thu, 4 Oct 2012 09:38:40 +0100 In-Reply-To: <20121003153714.4656b7e9@mantra.us.oracle.com> References: <20120921121659.5a723de9@mantra.us.oracle.com> <20120924154335.097d3fb9@mantra.us.oracle.com> <20120925180416.0137d61a@mantra.us.oracle.com> <20121002183619.70734b7a@mantra.us.oracle.com> <20121002190323.2e16f6ff@mantra.us.oracle.com> <20121003153714.4656b7e9@mantra.us.oracle.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v1 3/8]: PVH startup changes (enlighten.c) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-10-03 at 23:37 +0100, Mukesh Rathor wrote: > On Wed, 3 Oct 2012 12:58:22 +0100 > Stefano Stabellini wrote: > > > On Wed, 3 Oct 2012, Mukesh Rathor wrote: > > > On Tue, 2 Oct 2012 18:36:19 -0700 > > > Mukesh Rathor wrote: > > > > > > > On Wed, 26 Sep 2012 12:33:39 +0100 > > > > > > > So for now, how about, lets go > > > with what I've got. I'll make a note, and when I do xen patch, I'll > > > figure it out, and would be a very small linux patch. I want to get > > > linux patch in soon before the window closes. > > > > We can leave page special as it is for now with very little > > consequences, because it is not part of the interface with Xen. > > However this is part of the interface, so whatever we choose here is > > going to be hard to change later on. > > > > I think it would be good if we could either make dom0 use a pfn or > > domU use mfn, whatever is easier for you. > > Ok, finally, focussing on this, the issue with pfn in dom0 is that > I need pfn allocated in construct_dom0() and be mapped so that the > guest can just do : > > HYPERVISOR_shared_info=(struct shared_info *)__va(xen_start_info->shared_info); > > How about following I am experimenting with right now: > > in construct_dom0(): > > vstartinfo_end = (vstartinfo_start + > sizeof(struct start_info) + > sizeof(struct dom0_vga_console_info)); > > if ( is_hybrid_domain(d) ) { > start_info_pfn_addr = round_pgup(vstartinfo_end) - v_start; > vstartinfo_end += PAGE_SIZE; > } > > I can then put (PFN: start_info_pfn_addr)->(MFN: virt_to_maddr(d->shared_info)) > in the p2m, and dom0 just has to do __va(), like domU does now. I wont' need > to special case dom0 then. > > Do you foresee any problems with this approach? Hard to say without all the surrounding context but it seems plausible to me. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 08:38:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 08:38:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJgxB-0004gX-1W; Thu, 04 Oct 2012 08:38:45 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJgx9-0004gB-BK for Xen-devel@lists.xensource.com; Thu, 04 Oct 2012 08:38:43 +0000 Received: from [85.158.143.99:23012] by server-2.bemta-4.messagelabs.com id A6/64-06610-21B4D605; Thu, 04 Oct 2012 08:38:42 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1349339921!32207196!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMwMTc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2473 invoked from network); 4 Oct 2012 08:38:42 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 08:38:42 -0000 X-IronPort-AV: E=Sophos;i="4.80,533,1344211200"; d="scan'208";a="14933105" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 08:38:41 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 09:38:41 +0100 Message-ID: <1349339920.650.220.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Mukesh Rathor Date: Thu, 4 Oct 2012 09:38:40 +0100 In-Reply-To: <20121003153714.4656b7e9@mantra.us.oracle.com> References: <20120921121659.5a723de9@mantra.us.oracle.com> <20120924154335.097d3fb9@mantra.us.oracle.com> <20120925180416.0137d61a@mantra.us.oracle.com> <20121002183619.70734b7a@mantra.us.oracle.com> <20121002190323.2e16f6ff@mantra.us.oracle.com> <20121003153714.4656b7e9@mantra.us.oracle.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v1 3/8]: PVH startup changes (enlighten.c) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-10-03 at 23:37 +0100, Mukesh Rathor wrote: > On Wed, 3 Oct 2012 12:58:22 +0100 > Stefano Stabellini wrote: > > > On Wed, 3 Oct 2012, Mukesh Rathor wrote: > > > On Tue, 2 Oct 2012 18:36:19 -0700 > > > Mukesh Rathor wrote: > > > > > > > On Wed, 26 Sep 2012 12:33:39 +0100 > > > > > > > So for now, how about, lets go > > > with what I've got. I'll make a note, and when I do xen patch, I'll > > > figure it out, and would be a very small linux patch. I want to get > > > linux patch in soon before the window closes. > > > > We can leave page special as it is for now with very little > > consequences, because it is not part of the interface with Xen. > > However this is part of the interface, so whatever we choose here is > > going to be hard to change later on. > > > > I think it would be good if we could either make dom0 use a pfn or > > domU use mfn, whatever is easier for you. > > Ok, finally, focussing on this, the issue with pfn in dom0 is that > I need pfn allocated in construct_dom0() and be mapped so that the > guest can just do : > > HYPERVISOR_shared_info=(struct shared_info *)__va(xen_start_info->shared_info); > > How about following I am experimenting with right now: > > in construct_dom0(): > > vstartinfo_end = (vstartinfo_start + > sizeof(struct start_info) + > sizeof(struct dom0_vga_console_info)); > > if ( is_hybrid_domain(d) ) { > start_info_pfn_addr = round_pgup(vstartinfo_end) - v_start; > vstartinfo_end += PAGE_SIZE; > } > > I can then put (PFN: start_info_pfn_addr)->(MFN: virt_to_maddr(d->shared_info)) > in the p2m, and dom0 just has to do __va(), like domU does now. I wont' need > to special case dom0 then. > > Do you foresee any problems with this approach? Hard to say without all the surrounding context but it seems plausible to me. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 08:39:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 08:39:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJgy4-0004nC-Fm; Thu, 04 Oct 2012 08:39:40 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJgy2-0004mx-UB for xen-devel@lists.xen.org; Thu, 04 Oct 2012 08:39:39 +0000 Received: from [85.158.139.211:63306] by server-4.bemta-5.messagelabs.com id D6/EC-20767-A4B4D605; Thu, 04 Oct 2012 08:39:38 +0000 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-9.tower-206.messagelabs.com!1349339977!19516746!1 X-Originating-IP: [209.85.214.45] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13830 invoked from network); 4 Oct 2012 08:39:37 -0000 Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com) (209.85.214.45) by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 08:39:37 -0000 Received: by mail-bk0-f45.google.com with SMTP id jf3so123605bkc.32 for ; Thu, 04 Oct 2012 01:39:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=pDS103CfGV8/Mva6Qz9m2FwhlTdvI86y47FdWAn4gx4=; b=zcCBf3TRorM4ROFQZ6NxqMCUEmWDBQlkwM+qHgRVcyxkG/yWdYBKHvzO0XaCuLdmN8 kaUj2ybv1xNQwA4f61wSamLVmscLCD9FgoPBIejxuOjxkBEOdSMS4n33di17B4srGxlw f2bmuKBQ8F874MzYbJVLyE1FNVywq/1Sk6NJExt2PWsRnejW5GSfnwITj0Vk6FUeaJzw x6ejkOYvnaXr/AktwCNT2yZbvu+zUkwDh2H6isJ90QsUGx/aAQPaQw6hBBft1Q9T1H5W 3zxXYlOS3QKm2LWg+xgI3vVU5Gyb2Or8T78C6pJnexORFVknDa5SelEALU+CH2crGwC1 Tc3g== Received: by 10.204.150.201 with SMTP id z9mr1258533bkv.104.1349339977295; Thu, 04 Oct 2012 01:39:37 -0700 (PDT) Received: from [172.16.26.11] (b0fb1d54.bb.sky.com. [176.251.29.84]) by mx.google.com with ESMTPS id o17sm4923900bkw.9.2012.10.04.01.39.34 (version=SSLv3 cipher=OTHER); Thu, 04 Oct 2012 01:39:36 -0700 (PDT) Message-ID: <506D4B46.8080205@xen.org> Date: Thu, 04 Oct 2012 09:39:34 +0100 From: Lars Kurth User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Ian Jackson References: <20448.49637.38489.246434@mariner.uk.xensource.com> <1345718230.12501.79.camel@zakaz.uk.xensource.com> <50604343.1090506@xen.org> <20585.50923.886126.938976@mariner.uk.xensource.com> In-Reply-To: <20585.50923.886126.938976@mariner.uk.xensource.com> Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] Security vulnerability process, and CVE-2012-0217 [vote?] X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: lars.kurth@xen.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 01/10/2012 17:38, Ian Jackson wrote: > They all seem uncontroversial to me and no-one has objected. You > should go ahead and make the changes, I think. Ian. All published at http://www.xen.org/projects/security_vulnerability_process.html Lars _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 08:39:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 08:39:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJgy4-0004nC-Fm; Thu, 04 Oct 2012 08:39:40 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJgy2-0004mx-UB for xen-devel@lists.xen.org; Thu, 04 Oct 2012 08:39:39 +0000 Received: from [85.158.139.211:63306] by server-4.bemta-5.messagelabs.com id D6/EC-20767-A4B4D605; Thu, 04 Oct 2012 08:39:38 +0000 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-9.tower-206.messagelabs.com!1349339977!19516746!1 X-Originating-IP: [209.85.214.45] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13830 invoked from network); 4 Oct 2012 08:39:37 -0000 Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com) (209.85.214.45) by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 08:39:37 -0000 Received: by mail-bk0-f45.google.com with SMTP id jf3so123605bkc.32 for ; Thu, 04 Oct 2012 01:39:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=pDS103CfGV8/Mva6Qz9m2FwhlTdvI86y47FdWAn4gx4=; b=zcCBf3TRorM4ROFQZ6NxqMCUEmWDBQlkwM+qHgRVcyxkG/yWdYBKHvzO0XaCuLdmN8 kaUj2ybv1xNQwA4f61wSamLVmscLCD9FgoPBIejxuOjxkBEOdSMS4n33di17B4srGxlw f2bmuKBQ8F874MzYbJVLyE1FNVywq/1Sk6NJExt2PWsRnejW5GSfnwITj0Vk6FUeaJzw x6ejkOYvnaXr/AktwCNT2yZbvu+zUkwDh2H6isJ90QsUGx/aAQPaQw6hBBft1Q9T1H5W 3zxXYlOS3QKm2LWg+xgI3vVU5Gyb2Or8T78C6pJnexORFVknDa5SelEALU+CH2crGwC1 Tc3g== Received: by 10.204.150.201 with SMTP id z9mr1258533bkv.104.1349339977295; Thu, 04 Oct 2012 01:39:37 -0700 (PDT) Received: from [172.16.26.11] (b0fb1d54.bb.sky.com. [176.251.29.84]) by mx.google.com with ESMTPS id o17sm4923900bkw.9.2012.10.04.01.39.34 (version=SSLv3 cipher=OTHER); Thu, 04 Oct 2012 01:39:36 -0700 (PDT) Message-ID: <506D4B46.8080205@xen.org> Date: Thu, 04 Oct 2012 09:39:34 +0100 From: Lars Kurth User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Ian Jackson References: <20448.49637.38489.246434@mariner.uk.xensource.com> <1345718230.12501.79.camel@zakaz.uk.xensource.com> <50604343.1090506@xen.org> <20585.50923.886126.938976@mariner.uk.xensource.com> In-Reply-To: <20585.50923.886126.938976@mariner.uk.xensource.com> Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] Security vulnerability process, and CVE-2012-0217 [vote?] X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: lars.kurth@xen.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 01/10/2012 17:38, Ian Jackson wrote: > They all seem uncontroversial to me and no-one has objected. You > should go ahead and make the changes, I think. Ian. All published at http://www.xen.org/projects/security_vulnerability_process.html Lars _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 08:51:15 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 08:51:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJh91-00053G-Ps; Thu, 04 Oct 2012 08:50:59 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJh90-00053B-TQ for Xen-devel@lists.xensource.com; Thu, 04 Oct 2012 08:50:59 +0000 Received: from [85.158.143.35:35648] by server-3.bemta-4.messagelabs.com id 0B/F6-10986-2FD4D605; Thu, 04 Oct 2012 08:50:58 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1349340644!5010527!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMwMTc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28985 invoked from network); 4 Oct 2012 08:50:44 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 08:50:44 -0000 X-IronPort-AV: E=Sophos;i="4.80,533,1344211200"; d="scan'208";a="14933383" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 08:50:43 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 09:50:43 +0100 Message-ID: <1349340642.650.227.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Mukesh Rathor Date: Thu, 4 Oct 2012 09:50:42 +0100 In-Reply-To: <20121003153106.65237f07@mantra.us.oracle.com> References: <20120921122123.33489ce1@mantra.us.oracle.com> <1349270495.650.144.camel@zakaz.uk.xensource.com> <20121003153106.65237f07@mantra.us.oracle.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 7/8]: PVH privcmd changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-10-03 at 23:31 +0100, Mukesh Rathor wrote: > On Wed, 3 Oct 2012 14:21:35 +0100 > Ian Campbell wrote: > > > On Fri, 2012-09-21 at 20:21 +0100, Mukesh Rathor wrote: > > > +static int pvh_privcmd_resv_pfns(struct vm_area_struct *vma, int > > > numpgs) > > ... > > > + pvhp->pi_num_pgs = numpgs; > > > + BUG_ON(vma->vm_private_data != (void *)1); > > > + vma->vm_private_data = pvhp; > > > > How does this interact with: > > > > static int privcmd_enforce_singleshot_mapping(struct vm_area_struct > > *vma) { > > return (xchg(&vma->vm_private_data, (void *)1) == NULL); > > } > > > > If someone tries to map a second time then won't this correct the pvhp > > in vm_private_data by resetting it to 1? Then when the original > > mapping is torn down things all fall apart? > > > > Perhaps we need a cmpxchg here? Or to rework the callers a little bit > > perhaps. > > Right, that's why I had it originally checking for auto xlated and > doing something different. I think that is better than to change this > and change again. I'll change it back to just putting the ptr here. Won't that break because on the second call you will pass in the freshly allocated pointer and overwrite the exiting (useful) one with it? I think at a minimum you need a cmpxchg or some higher level locking strategy. None of the existing VM_* flags look suitable for this interlock, but I wonder if the idea of forcing a singleton mapping is generic enough to be worth such a flag? There's no lock in the struct vm_area_struct, unless one is available via vm_file or something? I've no idea what the locking hierarchy looks like around this stuff sadly. Perhaps the right answer is to allocate the struct in privcmd_mmap for all modes and include the mapped flag in that? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 08:51:15 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 08:51:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJh91-00053G-Ps; Thu, 04 Oct 2012 08:50:59 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJh90-00053B-TQ for Xen-devel@lists.xensource.com; Thu, 04 Oct 2012 08:50:59 +0000 Received: from [85.158.143.35:35648] by server-3.bemta-4.messagelabs.com id 0B/F6-10986-2FD4D605; Thu, 04 Oct 2012 08:50:58 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-21.messagelabs.com!1349340644!5010527!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMwMTc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28985 invoked from network); 4 Oct 2012 08:50:44 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 08:50:44 -0000 X-IronPort-AV: E=Sophos;i="4.80,533,1344211200"; d="scan'208";a="14933383" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 08:50:43 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 09:50:43 +0100 Message-ID: <1349340642.650.227.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Mukesh Rathor Date: Thu, 4 Oct 2012 09:50:42 +0100 In-Reply-To: <20121003153106.65237f07@mantra.us.oracle.com> References: <20120921122123.33489ce1@mantra.us.oracle.com> <1349270495.650.144.camel@zakaz.uk.xensource.com> <20121003153106.65237f07@mantra.us.oracle.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 7/8]: PVH privcmd changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-10-03 at 23:31 +0100, Mukesh Rathor wrote: > On Wed, 3 Oct 2012 14:21:35 +0100 > Ian Campbell wrote: > > > On Fri, 2012-09-21 at 20:21 +0100, Mukesh Rathor wrote: > > > +static int pvh_privcmd_resv_pfns(struct vm_area_struct *vma, int > > > numpgs) > > ... > > > + pvhp->pi_num_pgs = numpgs; > > > + BUG_ON(vma->vm_private_data != (void *)1); > > > + vma->vm_private_data = pvhp; > > > > How does this interact with: > > > > static int privcmd_enforce_singleshot_mapping(struct vm_area_struct > > *vma) { > > return (xchg(&vma->vm_private_data, (void *)1) == NULL); > > } > > > > If someone tries to map a second time then won't this correct the pvhp > > in vm_private_data by resetting it to 1? Then when the original > > mapping is torn down things all fall apart? > > > > Perhaps we need a cmpxchg here? Or to rework the callers a little bit > > perhaps. > > Right, that's why I had it originally checking for auto xlated and > doing something different. I think that is better than to change this > and change again. I'll change it back to just putting the ptr here. Won't that break because on the second call you will pass in the freshly allocated pointer and overwrite the exiting (useful) one with it? I think at a minimum you need a cmpxchg or some higher level locking strategy. None of the existing VM_* flags look suitable for this interlock, but I wonder if the idea of forcing a singleton mapping is generic enough to be worth such a flag? There's no lock in the struct vm_area_struct, unless one is available via vm_file or something? I've no idea what the locking hierarchy looks like around this stuff sadly. Perhaps the right answer is to allocate the struct in privcmd_mmap for all modes and include the mapped flag in that? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 09:56:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 09:56:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJi9z-0006Yd-V5; Thu, 04 Oct 2012 09:56:03 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJi9y-0006YV-No for xen-devel@lists.xen.org; Thu, 04 Oct 2012 09:56:02 +0000 Received: from [85.158.139.211:35657] by server-13.bemta-5.messagelabs.com id 76/8F-16359-23D5D605; Thu, 04 Oct 2012 09:56:02 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-2.tower-206.messagelabs.com!1349344561!21024049!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19482 invoked from network); 4 Oct 2012 09:56:01 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 09:56:01 -0000 X-IronPort-AV: E=Sophos;i="4.80,533,1344211200"; d="scan'208";a="14935535" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 09:56:01 +0000 Received: from Roger-2.local (10.31.3.235) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 10:56:01 +0100 Message-ID: <506D5D30.5050600@citrix.com> Date: Thu, 4 Oct 2012 11:56:00 +0200 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: George Dunlap References: In-Reply-To: Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Xen 4.3 development update X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 19/09/12 18:58, George Dunlap wrote: > = Timeline = > > We are planning on a 9-month release cycle. Based on that, below are > our estimated dates: > * Feature Freeze: 1 March, 2013 > * First RC: 15 April 2013 > * Release: 1 June 2013 > > The RCs and release will of course depend on stability and bugs, and > will therefore be fairly unpredictable. The feature freeze may be > slipped for especially important features which are near completion. > > = Feature tracking = > > Below is a list of features we're tracking for this release. Please > respond to this mail with any updates to the status. If the status > is "?", as most of them are, please respond with the status! Example > statuses include "not started", "in progress", "initial implementation > submitted for review", "patches submitted". > > There are a number of items whose owners are marked as "?". If you > are working on this, or know who is working on it, please respond and > let me know. Alternately, if you would *like* to work on it, please > let me know as well. > > And if there is something you're working on you'd like tracked, please > respond, and I will add it to the list. > > > * PVH mode, domU (w/ Linux) > owner: mukesh@oracle > status: ? > > * PVH mode, dom0 (w/ Linux) > owner: mukesh@oracle > status: ? > > * Event channel scalability > owner: attilio@citrix > status: ? > Increase limit on event channels (currently 1024 for 32-bit guests, > 4096 for 64-bit guests) > > * ARM server port > owner: ijc@citrix > status: Core hypervisor patches accepted; Linux paches pending > > * NUMA scheduler affinity > critical > owner: dario@citrix > status: ? > > * NUMA Memory migration > owner: dario@citrix > status: ? > > * blktap3 > owner: thanos@citrix > status: ? > > * Default to QEMU upstream > - qemu-based stubdom (Linux or BSD libc) > owner: anthony@citrix > status: ? > qemu-upstream needs a more fully-featured libc than exists in > minios. Either work on a minimalist linux-based stubdom with > glibc, or port one of the BSD libcs to minios. > > - pci pass-thru > owner: anthony@citrix > status: ? > > * Persistent grants > owner: @citrix > status: ? I'm taking Oliver's patch, so: owner: roger.pau@citrix status: in progress > > * Multi-page blk rings > - blkback in kernel (konrad@oracle, ?@intel) > - qemu blkback > status: ? > > * Multi-page net protocol > owner: ? > status: ? > expand the network ring protocol to allow multiple pages for > increased throughput > > * Scalability: 16TiB of RAM > owner: jan@suse > status: ? > > * libvirt integration > owner: ? > status: ? > To begin with, we need someone to go and make some lists: > - Features available in libvirt/KVM not available in libvirt/Xen > - Features available in xl/Xen but not available in libvirt/Xen > > * xl vm-{export,import} > owner: ? > status: ? > Allow xl to import and export VMs to other formats; particularly > ovf, perhaps the XenServer format, or more. > > > * xl USB pass-through for PV guests > owner: ? > status: ? > - Port the xend PV pass-through functionality to xl. > - Make sure qemu-based USB with qemu-upstream works > - Upstream the Linux frontend/backend drivers > > * openvswitch toostack integration > owner: roger@citrix > status: Sample script posted by Bastian ("[RFC] openvswitch support script") > > * Rationalized backend scripts (incl. driver domains) > owner: roger@citrix > status: ? > > * Linux console improvements > owner: jan@suse > -EHCI debug port (done, to be submitted) > -xHCI debug port > -Firewire > > * CPUID-based idle (don't rely on ACPI info f/ dom0) > owner: jan@suse > status: done, to be submitted > > * Remove hardcoded mobprobe's in xencommons > owner: ? > status: ? > > * Make storage migration possible > owner: ? > status: ? > There needs to be a way, either via command-line or via some hooks, > that someone can build a "storage migration" feature on top of libxl > or xl. > > * Full-VM snapshotting > owner: ? > status: ? > Have a way of coordinating the taking and restoring of VM memory and > disk snapshots. This would involve some investigation into the best > way to accomplish this. > > * VM Cloning > owner: ? > status: May need review > Again, a way of coordinating the memory and disk aspects. Research > into the best way to do this would probably go along with the > snapshotting feature. > > * Memory: Replace PoD with paging mechanism > owner: george@citrix > status: May need review > > * PV audio (audio for stubdom qemu) > owner: stefano.panella@citrix > status: ? > > * Managed domains? > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 09:56:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 09:56:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJi9z-0006Yd-V5; Thu, 04 Oct 2012 09:56:03 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJi9y-0006YV-No for xen-devel@lists.xen.org; Thu, 04 Oct 2012 09:56:02 +0000 Received: from [85.158.139.211:35657] by server-13.bemta-5.messagelabs.com id 76/8F-16359-23D5D605; Thu, 04 Oct 2012 09:56:02 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-2.tower-206.messagelabs.com!1349344561!21024049!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19482 invoked from network); 4 Oct 2012 09:56:01 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 09:56:01 -0000 X-IronPort-AV: E=Sophos;i="4.80,533,1344211200"; d="scan'208";a="14935535" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 09:56:01 +0000 Received: from Roger-2.local (10.31.3.235) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 10:56:01 +0100 Message-ID: <506D5D30.5050600@citrix.com> Date: Thu, 4 Oct 2012 11:56:00 +0200 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: George Dunlap References: In-Reply-To: Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Xen 4.3 development update X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 19/09/12 18:58, George Dunlap wrote: > = Timeline = > > We are planning on a 9-month release cycle. Based on that, below are > our estimated dates: > * Feature Freeze: 1 March, 2013 > * First RC: 15 April 2013 > * Release: 1 June 2013 > > The RCs and release will of course depend on stability and bugs, and > will therefore be fairly unpredictable. The feature freeze may be > slipped for especially important features which are near completion. > > = Feature tracking = > > Below is a list of features we're tracking for this release. Please > respond to this mail with any updates to the status. If the status > is "?", as most of them are, please respond with the status! Example > statuses include "not started", "in progress", "initial implementation > submitted for review", "patches submitted". > > There are a number of items whose owners are marked as "?". If you > are working on this, or know who is working on it, please respond and > let me know. Alternately, if you would *like* to work on it, please > let me know as well. > > And if there is something you're working on you'd like tracked, please > respond, and I will add it to the list. > > > * PVH mode, domU (w/ Linux) > owner: mukesh@oracle > status: ? > > * PVH mode, dom0 (w/ Linux) > owner: mukesh@oracle > status: ? > > * Event channel scalability > owner: attilio@citrix > status: ? > Increase limit on event channels (currently 1024 for 32-bit guests, > 4096 for 64-bit guests) > > * ARM server port > owner: ijc@citrix > status: Core hypervisor patches accepted; Linux paches pending > > * NUMA scheduler affinity > critical > owner: dario@citrix > status: ? > > * NUMA Memory migration > owner: dario@citrix > status: ? > > * blktap3 > owner: thanos@citrix > status: ? > > * Default to QEMU upstream > - qemu-based stubdom (Linux or BSD libc) > owner: anthony@citrix > status: ? > qemu-upstream needs a more fully-featured libc than exists in > minios. Either work on a minimalist linux-based stubdom with > glibc, or port one of the BSD libcs to minios. > > - pci pass-thru > owner: anthony@citrix > status: ? > > * Persistent grants > owner: @citrix > status: ? I'm taking Oliver's patch, so: owner: roger.pau@citrix status: in progress > > * Multi-page blk rings > - blkback in kernel (konrad@oracle, ?@intel) > - qemu blkback > status: ? > > * Multi-page net protocol > owner: ? > status: ? > expand the network ring protocol to allow multiple pages for > increased throughput > > * Scalability: 16TiB of RAM > owner: jan@suse > status: ? > > * libvirt integration > owner: ? > status: ? > To begin with, we need someone to go and make some lists: > - Features available in libvirt/KVM not available in libvirt/Xen > - Features available in xl/Xen but not available in libvirt/Xen > > * xl vm-{export,import} > owner: ? > status: ? > Allow xl to import and export VMs to other formats; particularly > ovf, perhaps the XenServer format, or more. > > > * xl USB pass-through for PV guests > owner: ? > status: ? > - Port the xend PV pass-through functionality to xl. > - Make sure qemu-based USB with qemu-upstream works > - Upstream the Linux frontend/backend drivers > > * openvswitch toostack integration > owner: roger@citrix > status: Sample script posted by Bastian ("[RFC] openvswitch support script") > > * Rationalized backend scripts (incl. driver domains) > owner: roger@citrix > status: ? > > * Linux console improvements > owner: jan@suse > -EHCI debug port (done, to be submitted) > -xHCI debug port > -Firewire > > * CPUID-based idle (don't rely on ACPI info f/ dom0) > owner: jan@suse > status: done, to be submitted > > * Remove hardcoded mobprobe's in xencommons > owner: ? > status: ? > > * Make storage migration possible > owner: ? > status: ? > There needs to be a way, either via command-line or via some hooks, > that someone can build a "storage migration" feature on top of libxl > or xl. > > * Full-VM snapshotting > owner: ? > status: ? > Have a way of coordinating the taking and restoring of VM memory and > disk snapshots. This would involve some investigation into the best > way to accomplish this. > > * VM Cloning > owner: ? > status: May need review > Again, a way of coordinating the memory and disk aspects. Research > into the best way to do this would probably go along with the > snapshotting feature. > > * Memory: Replace PoD with paging mechanism > owner: george@citrix > status: May need review > > * PV audio (audio for stubdom qemu) > owner: stefano.panella@citrix > status: ? > > * Managed domains? > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 10:01:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 10:01:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJiEZ-0006pg-ME; Thu, 04 Oct 2012 10:00:47 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJiEY-0006pb-1b for Xen-devel@lists.xensource.com; Thu, 04 Oct 2012 10:00:46 +0000 Received: from [85.158.143.99:62763] by server-2.bemta-4.messagelabs.com id FD/6C-06610-D4E5D605; Thu, 04 Oct 2012 10:00:45 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1349344842!26574055!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7352 invoked from network); 4 Oct 2012 10:00:43 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 10:00:43 -0000 X-IronPort-AV: E=Sophos;i="4.80,533,1344211200"; d="scan'208";a="14935708" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 10:00:42 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 11:00:42 +0100 Message-ID: <1349344840.650.239.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Mukesh Rathor Date: Thu, 4 Oct 2012 11:00:40 +0100 In-Reply-To: <20120921121511.30001c08@mantra.us.oracle.com> References: <20120921121511.30001c08@mantra.us.oracle.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 1/8]: PVH basic and hader file changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-09-21 at 20:15 +0100, Mukesh Rathor wrote: > @@ -234,4 +245,20 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_memory_map); > * during a driver critical region. > */ > extern spinlock_t xen_reservation_lock; > + > +/* > + * Unmaps the page appearing at a particular GPFN from the specified > guest's > + * pseudophysical address space. > + * arg == addr of xen_remove_from_physmap_t. > + */ > +#define XENMEM_remove_from_physmap 15 > +struct xen_remove_from_physmap { > + /* Which domain to change the mapping for. */ > + domid_t domid; > + > + /* GPFN of the current mapping of the page. */ > + unsigned long gpfn; > +}; > +DEFINE_GUEST_HANDLE_STRUCT(xen_remove_from_physmap); I needed this fixup in a tree with both the ARM and PVH stuff: 8<------------------------------------ >From d56a302734180171855e0ee07571ac0cee69b3e5 Mon Sep 17 00:00:00 2001 From: Ian Campbell Date: Thu, 4 Oct 2012 10:45:52 +0100 Subject: [PATCH] xen: use xen_pft_t in struct xen_remove_from_physmap 4a6c2b4 "PVH basic and hader file changes" and bd3f79b "xen: Introduce xen_pfn_t for pfn and mfn types" passed like ships in the night. Signed-off-by: Ian Campbell --- include/xen/interface/memory.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h index 6d74c47..d38bdc1 100644 --- a/include/xen/interface/memory.h +++ b/include/xen/interface/memory.h @@ -258,7 +258,7 @@ struct xen_remove_from_physmap { domid_t domid; /* GPFN of the current mapping of the page. */ - unsigned long gpfn; + xen_pfn_t gpfn; }; DEFINE_GUEST_HANDLE_STRUCT(xen_remove_from_physmap); -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 10:01:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 10:01:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJiEZ-0006pg-ME; Thu, 04 Oct 2012 10:00:47 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJiEY-0006pb-1b for Xen-devel@lists.xensource.com; Thu, 04 Oct 2012 10:00:46 +0000 Received: from [85.158.143.99:62763] by server-2.bemta-4.messagelabs.com id FD/6C-06610-D4E5D605; Thu, 04 Oct 2012 10:00:45 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1349344842!26574055!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7352 invoked from network); 4 Oct 2012 10:00:43 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 10:00:43 -0000 X-IronPort-AV: E=Sophos;i="4.80,533,1344211200"; d="scan'208";a="14935708" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 10:00:42 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 11:00:42 +0100 Message-ID: <1349344840.650.239.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Mukesh Rathor Date: Thu, 4 Oct 2012 11:00:40 +0100 In-Reply-To: <20120921121511.30001c08@mantra.us.oracle.com> References: <20120921121511.30001c08@mantra.us.oracle.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 1/8]: PVH basic and hader file changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-09-21 at 20:15 +0100, Mukesh Rathor wrote: > @@ -234,4 +245,20 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_memory_map); > * during a driver critical region. > */ > extern spinlock_t xen_reservation_lock; > + > +/* > + * Unmaps the page appearing at a particular GPFN from the specified > guest's > + * pseudophysical address space. > + * arg == addr of xen_remove_from_physmap_t. > + */ > +#define XENMEM_remove_from_physmap 15 > +struct xen_remove_from_physmap { > + /* Which domain to change the mapping for. */ > + domid_t domid; > + > + /* GPFN of the current mapping of the page. */ > + unsigned long gpfn; > +}; > +DEFINE_GUEST_HANDLE_STRUCT(xen_remove_from_physmap); I needed this fixup in a tree with both the ARM and PVH stuff: 8<------------------------------------ >From d56a302734180171855e0ee07571ac0cee69b3e5 Mon Sep 17 00:00:00 2001 From: Ian Campbell Date: Thu, 4 Oct 2012 10:45:52 +0100 Subject: [PATCH] xen: use xen_pft_t in struct xen_remove_from_physmap 4a6c2b4 "PVH basic and hader file changes" and bd3f79b "xen: Introduce xen_pfn_t for pfn and mfn types" passed like ships in the night. Signed-off-by: Ian Campbell --- include/xen/interface/memory.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h index 6d74c47..d38bdc1 100644 --- a/include/xen/interface/memory.h +++ b/include/xen/interface/memory.h @@ -258,7 +258,7 @@ struct xen_remove_from_physmap { domid_t domid; /* GPFN of the current mapping of the page. */ - unsigned long gpfn; + xen_pfn_t gpfn; }; DEFINE_GUEST_HANDLE_STRUCT(xen_remove_from_physmap); -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 10:07:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 10:07:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJiKT-00076K-G5; Thu, 04 Oct 2012 10:06:53 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJiKQ-00076B-Rw for xen-devel@lists.xen.org; Thu, 04 Oct 2012 10:06:51 +0000 Received: from [85.158.143.35:41583] by server-1.bemta-4.messagelabs.com id 17/5A-05684-ABF5D605; Thu, 04 Oct 2012 10:06:50 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-3.tower-21.messagelabs.com!1349345208!13300913!1 X-Originating-IP: [81.29.64.94] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21496 invoked from network); 4 Oct 2012 10:06:49 -0000 Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94) by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Oct 2012 10:06:49 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1TJiKL-000A5n-Un; Thu, 04 Oct 2012 10:06:45 +0000 Date: Thu, 4 Oct 2012 11:06:45 +0100 From: Tim Deegan To: Dan Magenheimer Message-ID: <20121004100645.GC38243@ocelot.phlegethon.org> References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> <20121002091017.GA95926@ocelot.phlegethon.org> <66cc0085-1216-40f7-8059-eaf615202c12@default> <20121002201624.GA98445@ocelot.phlegethon.org> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: Olaf Hering , Keir Fraser , Konrad Wilk , George Dunlap , Kurt Hackel , Ian Jackson , xen-devel@lists.xen.org, George Shuklin , Dario Faggioli , Andres Lagar-Cavilla Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org At 14:56 -0700 on 02 Oct (1349189817), Dan Magenheimer wrote: > > AIUI xapi uses the domains' maximum allocations, centrally controlled, > > to place an upper bound on the amount of guest memory that can be in > > use. Within those limits there can be ballooning activity. But TBH I > > don't know the details. > > Yes, that's the same as saying there is no memory-overcommit. I'd say there is - but it's all done by ballooning, and it's centrally enforced by lowering each domain's maxmem to its balloon target, so a badly behaved guest can't balloon up and confuse things. > The original problem occurs only if there are multiple threads > of execution that can be simultaneously asking the hypervisor > to allocate memory without the knowledge of a single centralized > "controller". Absolutely. > Tmem argues that doing "memory capacity transfers" at a page granularity > can only be done efficiently in the hypervisor. This is true for > page-sharing when it breaks a "share" also... it can't go ask the > toolstack to approve allocation of a new page every time a write to a shared > page occurs. > > Does that make sense? Yes. The page-sharing version can be handled by having a pool of dedicated memory for breaking shares, and the toolstack asynchronously replenish that, rather than allowing CoW to use up all memory in the system. > (rough proposed design re-attached below) Thanks for that. It describes a sensible-looking hypervisor interface, but my question was really: what should xl do, in the presence of ballooning, sharing, paging and tmem, to - decide whether a VM can be started at all; - control those four systems to shuffle memory around; and - resolve races sensibly to avoid small VMs deferring large ones. (AIUI, xl already has some logic to handle the case of balloon-to-fit.) The second of those three is the interesting one. It seems to me that if the tools can't force all other actors to give up memory (and not immediately take it back) then they can't guarantee to be able to start a new VM, even with the new reservation hypercalls. Cheers, Tim. > > From: Dan Magenheimer > > Sent: Monday, October 01, 2012 2:04 PM > > : > > : > > Back to design brainstorming: > > > > The way I am thinking about it, the tools need to be involved > > to the extent that they would need to communicate to the > > hypervisor the following facts (probably via new hypercall): > > > > X1) I am launching a domain X and it is eventually going to > > consume up to a maximum of N MB. Please tell me if > > there is sufficient RAM available AND, if so, reserve > > it until I tell you I am done. ("AND" implies transactional > > semantics) > > X2) The launch of X is complete and I will not be requesting > > the allocation of any more RAM for it. Please release > > the reservation, whether or not I've requested a total > > of N MB. > > > > The calls may be nested or partially ordered, i.e. > > X1...Y1...Y2...X2 > > X1...Y1...X2...Y2 > > and the hypervisor must be able to deal with this. > > > > Then there would need to be two "versions" of "xm/xl free". > > We can quibble about which should be the default, but > > they would be: > > > > - "xl --reserved free" asks the hypervisor how much RAM > > is available taking into account reservations > > - "xm --raw free" asks the hypervisor for the instantaneous > > amount of RAM unallocated, not counting reservations > > > > When the tools are not launching a domain (that is there > > has been a matching X2 for all X1), the results of the > > above "free" queries are always identical. > > > > So, IanJ, does this match up with the design you were thinking > > about? > > > > Thanks, > > Dan > > > > [1] I think the core culprits are (a) the hypervisor accounts for > > memory allocation of pages strictly on a first-come-first-served > > basis and (b) the tools don't have any form of need-this-much-memory > > "transaction" model _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 10:07:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 10:07:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJiKT-00076K-G5; Thu, 04 Oct 2012 10:06:53 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJiKQ-00076B-Rw for xen-devel@lists.xen.org; Thu, 04 Oct 2012 10:06:51 +0000 Received: from [85.158.143.35:41583] by server-1.bemta-4.messagelabs.com id 17/5A-05684-ABF5D605; Thu, 04 Oct 2012 10:06:50 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-3.tower-21.messagelabs.com!1349345208!13300913!1 X-Originating-IP: [81.29.64.94] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21496 invoked from network); 4 Oct 2012 10:06:49 -0000 Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94) by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Oct 2012 10:06:49 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1TJiKL-000A5n-Un; Thu, 04 Oct 2012 10:06:45 +0000 Date: Thu, 4 Oct 2012 11:06:45 +0100 From: Tim Deegan To: Dan Magenheimer Message-ID: <20121004100645.GC38243@ocelot.phlegethon.org> References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> <20121002091017.GA95926@ocelot.phlegethon.org> <66cc0085-1216-40f7-8059-eaf615202c12@default> <20121002201624.GA98445@ocelot.phlegethon.org> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: Olaf Hering , Keir Fraser , Konrad Wilk , George Dunlap , Kurt Hackel , Ian Jackson , xen-devel@lists.xen.org, George Shuklin , Dario Faggioli , Andres Lagar-Cavilla Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org At 14:56 -0700 on 02 Oct (1349189817), Dan Magenheimer wrote: > > AIUI xapi uses the domains' maximum allocations, centrally controlled, > > to place an upper bound on the amount of guest memory that can be in > > use. Within those limits there can be ballooning activity. But TBH I > > don't know the details. > > Yes, that's the same as saying there is no memory-overcommit. I'd say there is - but it's all done by ballooning, and it's centrally enforced by lowering each domain's maxmem to its balloon target, so a badly behaved guest can't balloon up and confuse things. > The original problem occurs only if there are multiple threads > of execution that can be simultaneously asking the hypervisor > to allocate memory without the knowledge of a single centralized > "controller". Absolutely. > Tmem argues that doing "memory capacity transfers" at a page granularity > can only be done efficiently in the hypervisor. This is true for > page-sharing when it breaks a "share" also... it can't go ask the > toolstack to approve allocation of a new page every time a write to a shared > page occurs. > > Does that make sense? Yes. The page-sharing version can be handled by having a pool of dedicated memory for breaking shares, and the toolstack asynchronously replenish that, rather than allowing CoW to use up all memory in the system. > (rough proposed design re-attached below) Thanks for that. It describes a sensible-looking hypervisor interface, but my question was really: what should xl do, in the presence of ballooning, sharing, paging and tmem, to - decide whether a VM can be started at all; - control those four systems to shuffle memory around; and - resolve races sensibly to avoid small VMs deferring large ones. (AIUI, xl already has some logic to handle the case of balloon-to-fit.) The second of those three is the interesting one. It seems to me that if the tools can't force all other actors to give up memory (and not immediately take it back) then they can't guarantee to be able to start a new VM, even with the new reservation hypercalls. Cheers, Tim. > > From: Dan Magenheimer > > Sent: Monday, October 01, 2012 2:04 PM > > : > > : > > Back to design brainstorming: > > > > The way I am thinking about it, the tools need to be involved > > to the extent that they would need to communicate to the > > hypervisor the following facts (probably via new hypercall): > > > > X1) I am launching a domain X and it is eventually going to > > consume up to a maximum of N MB. Please tell me if > > there is sufficient RAM available AND, if so, reserve > > it until I tell you I am done. ("AND" implies transactional > > semantics) > > X2) The launch of X is complete and I will not be requesting > > the allocation of any more RAM for it. Please release > > the reservation, whether or not I've requested a total > > of N MB. > > > > The calls may be nested or partially ordered, i.e. > > X1...Y1...Y2...X2 > > X1...Y1...X2...Y2 > > and the hypervisor must be able to deal with this. > > > > Then there would need to be two "versions" of "xm/xl free". > > We can quibble about which should be the default, but > > they would be: > > > > - "xl --reserved free" asks the hypervisor how much RAM > > is available taking into account reservations > > - "xm --raw free" asks the hypervisor for the instantaneous > > amount of RAM unallocated, not counting reservations > > > > When the tools are not launching a domain (that is there > > has been a matching X2 for all X1), the results of the > > above "free" queries are always identical. > > > > So, IanJ, does this match up with the design you were thinking > > about? > > > > Thanks, > > Dan > > > > [1] I think the core culprits are (a) the hypervisor accounts for > > memory allocation of pages strictly on a first-come-first-served > > basis and (b) the tools don't have any form of need-this-much-memory > > "transaction" model _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 10:09:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 10:09:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJiMW-0007Et-5U; Thu, 04 Oct 2012 10:09:00 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJiMU-0007Eh-Ko for xen-devel@lists.xensource.com; Thu, 04 Oct 2012 10:08:58 +0000 Received: from [85.158.138.51:36941] by server-4.bemta-3.messagelabs.com id 0A/5E-14155-9306D605; Thu, 04 Oct 2012 10:08:57 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1349345337!25138935!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20623 invoked from network); 4 Oct 2012 10:08:57 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 10:08:57 -0000 X-IronPort-AV: E=Sophos;i="4.80,533,1344211200"; d="scan'208";a="14935981" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 10:08:46 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 11:08:46 +0100 Date: Thu, 4 Oct 2012 11:07:46 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Jan Beulich In-Reply-To: <506D5A53020000780009F8B7@nat28.tlf.novell.com> Message-ID: References: <1349272182.650.150.camel@zakaz.uk.xensource.com> <1349272482.650.151.camel@zakaz.uk.xensource.com> <20121003141116.GA10633@phenom.dumpdata.com> <1349276431.650.156.camel@zakaz.uk.xensource.com> <1349279862.650.171.camel@zakaz.uk.xensource.com> <1349280814.650.178.camel@zakaz.uk.xensource.com> <1349282492.650.185.camel@zakaz.uk.xensource.com> <506D5A53020000780009F8B7@nat28.tlf.novell.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: "linux-kernel@vger.kernel.org" , "xen-devel@lists.xensource.com" , Ian Campbell , Konrad Rzeszutek Wilk , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH] xen/xen_initial_domain: check that xen_start_info is initialized X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 4 Oct 2012, Jan Beulich wrote: > >>> On 03.10.12 at 19:08, Stefano Stabellini > wrote: > > Since commit commit 4c071ee5268f7234c3d084b6093bebccc28cdcba ("arm: > > initial Xen support") PV on HVM guests can be xen_initial_domain. > > However PV on HVM guests might have an unitialized xen_start_info, so > > check before accessing its fields. > > > > Signed-off-by: Stefano Stabellini > > Acked-by: Ian Campbell > > Reported-by: Konrad Rzeszutek Wilk > > > > diff --git a/include/xen/xen.h b/include/xen/xen.h > > index 9a39ca5..e7101bb 100644 > > --- a/include/xen/xen.h > > +++ b/include/xen/xen.h > > @@ -28,7 +28,7 @@ extern enum xen_domain_type xen_domain_type; > > #include > > > > #define xen_initial_domain() (xen_domain() && \ > > - xen_start_info->flags & SIF_INITDOMAIN) > > + xen_start_info && xen_start_info->flags & SIF_INITDOMAIN) > > #else /* !CONFIG_XEN_DOM0 */ > > #define xen_initial_domain() (0) > > #endif /* CONFIG_XEN_DOM0 */ > > Didn't your other patch statically initialize it? Yes. Even though both patches can safely coexist, I wrote this one as an alternative solution. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 10:09:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 10:09:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJiMW-0007Et-5U; Thu, 04 Oct 2012 10:09:00 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJiMU-0007Eh-Ko for xen-devel@lists.xensource.com; Thu, 04 Oct 2012 10:08:58 +0000 Received: from [85.158.138.51:36941] by server-4.bemta-3.messagelabs.com id 0A/5E-14155-9306D605; Thu, 04 Oct 2012 10:08:57 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1349345337!25138935!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20623 invoked from network); 4 Oct 2012 10:08:57 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 10:08:57 -0000 X-IronPort-AV: E=Sophos;i="4.80,533,1344211200"; d="scan'208";a="14935981" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 10:08:46 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 11:08:46 +0100 Date: Thu, 4 Oct 2012 11:07:46 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Jan Beulich In-Reply-To: <506D5A53020000780009F8B7@nat28.tlf.novell.com> Message-ID: References: <1349272182.650.150.camel@zakaz.uk.xensource.com> <1349272482.650.151.camel@zakaz.uk.xensource.com> <20121003141116.GA10633@phenom.dumpdata.com> <1349276431.650.156.camel@zakaz.uk.xensource.com> <1349279862.650.171.camel@zakaz.uk.xensource.com> <1349280814.650.178.camel@zakaz.uk.xensource.com> <1349282492.650.185.camel@zakaz.uk.xensource.com> <506D5A53020000780009F8B7@nat28.tlf.novell.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: "linux-kernel@vger.kernel.org" , "xen-devel@lists.xensource.com" , Ian Campbell , Konrad Rzeszutek Wilk , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH] xen/xen_initial_domain: check that xen_start_info is initialized X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 4 Oct 2012, Jan Beulich wrote: > >>> On 03.10.12 at 19:08, Stefano Stabellini > wrote: > > Since commit commit 4c071ee5268f7234c3d084b6093bebccc28cdcba ("arm: > > initial Xen support") PV on HVM guests can be xen_initial_domain. > > However PV on HVM guests might have an unitialized xen_start_info, so > > check before accessing its fields. > > > > Signed-off-by: Stefano Stabellini > > Acked-by: Ian Campbell > > Reported-by: Konrad Rzeszutek Wilk > > > > diff --git a/include/xen/xen.h b/include/xen/xen.h > > index 9a39ca5..e7101bb 100644 > > --- a/include/xen/xen.h > > +++ b/include/xen/xen.h > > @@ -28,7 +28,7 @@ extern enum xen_domain_type xen_domain_type; > > #include > > > > #define xen_initial_domain() (xen_domain() && \ > > - xen_start_info->flags & SIF_INITDOMAIN) > > + xen_start_info && xen_start_info->flags & SIF_INITDOMAIN) > > #else /* !CONFIG_XEN_DOM0 */ > > #define xen_initial_domain() (0) > > #endif /* CONFIG_XEN_DOM0 */ > > Didn't your other patch statically initialize it? Yes. Even though both patches can safely coexist, I wrote this one as an alternative solution. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 10:14:36 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 10:14:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJiRi-0007Sb-UR; Thu, 04 Oct 2012 10:14:22 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJiRh-0007SW-7k for xen-devel@lists.xensource.com; Thu, 04 Oct 2012 10:14:21 +0000 Received: from [85.158.139.211:64323] by server-7.bemta-5.messagelabs.com id 19/D9-00431-C716D605; Thu, 04 Oct 2012 10:14:20 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-14.tower-206.messagelabs.com!1349345659!20980692!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1747 invoked from network); 4 Oct 2012 10:14:19 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-14.tower-206.messagelabs.com with SMTP; 4 Oct 2012 10:14:19 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 04 Oct 2012 11:14:19 +0100 Message-Id: <506D7D9A020000780009F9C8@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Thu, 04 Oct 2012 11:14:18 +0100 From: "Jan Beulich" To: "David Vrabel" References: <1348243464-15903-1-git-send-email-david.vrabel@citrix.com> <1348243464-15903-3-git-send-email-david.vrabel@citrix.com> <5061EFB2.1080407@citrix.com> In-Reply-To: <5061EFB2.1080407@citrix.com> Mime-Version: 1.0 Content-Disposition: inline Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 2/6] xen-blkfront: handle backend CLOSED without CLOSING X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 25.09.12 at 19:53, David Vrabel wrote: > @@ -1167,7 +1168,8 @@ blkfront_closing(struct blkfront_info *info) > > mutex_lock(&bdev->bd_mutex); > > - if (bdev->bd_openers) { > + /* If the backend is already CLOSED, close now. */ > + if (bdev->bd_openers && backend_state != XenbusStateClosed) { > xenbus_dev_error(xbdev, -EBUSY, > "Device in use; refusing to close"); > xenbus_switch_state(xbdev, XenbusStateClosing); This looks wrong to me on a second glance: As long as there are users of the device, I don't think we want to go into Closed ourselves, irrespective of the backend state. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 10:14:36 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 10:14:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJiRi-0007Sb-UR; Thu, 04 Oct 2012 10:14:22 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJiRh-0007SW-7k for xen-devel@lists.xensource.com; Thu, 04 Oct 2012 10:14:21 +0000 Received: from [85.158.139.211:64323] by server-7.bemta-5.messagelabs.com id 19/D9-00431-C716D605; Thu, 04 Oct 2012 10:14:20 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-14.tower-206.messagelabs.com!1349345659!20980692!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1747 invoked from network); 4 Oct 2012 10:14:19 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-14.tower-206.messagelabs.com with SMTP; 4 Oct 2012 10:14:19 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 04 Oct 2012 11:14:19 +0100 Message-Id: <506D7D9A020000780009F9C8@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Thu, 04 Oct 2012 11:14:18 +0100 From: "Jan Beulich" To: "David Vrabel" References: <1348243464-15903-1-git-send-email-david.vrabel@citrix.com> <1348243464-15903-3-git-send-email-david.vrabel@citrix.com> <5061EFB2.1080407@citrix.com> In-Reply-To: <5061EFB2.1080407@citrix.com> Mime-Version: 1.0 Content-Disposition: inline Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 2/6] xen-blkfront: handle backend CLOSED without CLOSING X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 25.09.12 at 19:53, David Vrabel wrote: > @@ -1167,7 +1168,8 @@ blkfront_closing(struct blkfront_info *info) > > mutex_lock(&bdev->bd_mutex); > > - if (bdev->bd_openers) { > + /* If the backend is already CLOSED, close now. */ > + if (bdev->bd_openers && backend_state != XenbusStateClosed) { > xenbus_dev_error(xbdev, -EBUSY, > "Device in use; refusing to close"); > xenbus_switch_state(xbdev, XenbusStateClosing); This looks wrong to me on a second glance: As long as there are users of the device, I don't think we want to go into Closed ourselves, irrespective of the backend state. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 10:19:14 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 10:19:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJiW8-0007kx-KI; Thu, 04 Oct 2012 10:18:56 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJiW6-0007kk-OO for xen-devel@lists.xen.org; Thu, 04 Oct 2012 10:18:54 +0000 Received: from [85.158.143.35:45871] by server-1.bemta-4.messagelabs.com id E9/FD-05684-E826D605; Thu, 04 Oct 2012 10:18:54 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1349345924!3916392!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8157 invoked from network); 4 Oct 2012 10:18:44 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 10:18:44 -0000 X-IronPort-AV: E=Sophos;i="4.80,533,1344211200"; d="scan'208";a="14936320" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 10:17:46 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 11:17:46 +0100 Message-ID: <1349345864.650.247.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Tim Deegan Date: Thu, 4 Oct 2012 11:17:44 +0100 In-Reply-To: <20121004100645.GC38243@ocelot.phlegethon.org> References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> <20121002091017.GA95926@ocelot.phlegethon.org> <66cc0085-1216-40f7-8059-eaf615202c12@default> <20121002201624.GA98445@ocelot.phlegethon.org> <20121004100645.GC38243@ocelot.phlegethon.org> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: Dan Magenheimer , "Keir \(Xen.org\)" , Konrad Wilk , George Dunlap , Kurt Hackel , Ian Jackson , Olaf Hering , "xen-devel@lists.xen.org" , George Shuklin , Dario Faggioli , Andres Lagar-Cavilla Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-10-04 at 11:06 +0100, Tim Deegan wrote: > but my question was really: what should xl do, in the presence of > ballooning, sharing, paging and tmem, to > - decide whether a VM can be started at all; > - control those four systems to shuffle memory around; and > - resolve races sensibly to avoid small VMs deferring large ones. > (AIUI, xl already has some logic to handle the case of balloon-to-fit.) > > The second of those three is the interesting one. It seems to me that > if the tools can't force all other actors to give up memory (and not > immediately take it back) then they can't guarantee to be able to start > a new VM, even with the new reservation hypercalls. There was a bit of discussion in the spring about this sort of thing (well, three of the four), which seems to have fallen a bit by the wayside^W^W^W^W^W^Wbeen deferred until 4.3 (ahem) e.g. http://lists.xen.org/archives/html/xen-devel/2012-03/msg01181.html I'm sure there was earlier discussion which led to that, but I can't seem to see it in the archives right now, perhaps I'm not looking for the right Subject. Olaf might have been intending to look into this (I can't quite remember where we left it) Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 10:19:14 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 10:19:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJiW8-0007kx-KI; Thu, 04 Oct 2012 10:18:56 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJiW6-0007kk-OO for xen-devel@lists.xen.org; Thu, 04 Oct 2012 10:18:54 +0000 Received: from [85.158.143.35:45871] by server-1.bemta-4.messagelabs.com id E9/FD-05684-E826D605; Thu, 04 Oct 2012 10:18:54 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1349345924!3916392!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8157 invoked from network); 4 Oct 2012 10:18:44 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 10:18:44 -0000 X-IronPort-AV: E=Sophos;i="4.80,533,1344211200"; d="scan'208";a="14936320" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 10:17:46 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 11:17:46 +0100 Message-ID: <1349345864.650.247.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Tim Deegan Date: Thu, 4 Oct 2012 11:17:44 +0100 In-Reply-To: <20121004100645.GC38243@ocelot.phlegethon.org> References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> <20121002091017.GA95926@ocelot.phlegethon.org> <66cc0085-1216-40f7-8059-eaf615202c12@default> <20121002201624.GA98445@ocelot.phlegethon.org> <20121004100645.GC38243@ocelot.phlegethon.org> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: Dan Magenheimer , "Keir \(Xen.org\)" , Konrad Wilk , George Dunlap , Kurt Hackel , Ian Jackson , Olaf Hering , "xen-devel@lists.xen.org" , George Shuklin , Dario Faggioli , Andres Lagar-Cavilla Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-10-04 at 11:06 +0100, Tim Deegan wrote: > but my question was really: what should xl do, in the presence of > ballooning, sharing, paging and tmem, to > - decide whether a VM can be started at all; > - control those four systems to shuffle memory around; and > - resolve races sensibly to avoid small VMs deferring large ones. > (AIUI, xl already has some logic to handle the case of balloon-to-fit.) > > The second of those three is the interesting one. It seems to me that > if the tools can't force all other actors to give up memory (and not > immediately take it back) then they can't guarantee to be able to start > a new VM, even with the new reservation hypercalls. There was a bit of discussion in the spring about this sort of thing (well, three of the four), which seems to have fallen a bit by the wayside^W^W^W^W^W^Wbeen deferred until 4.3 (ahem) e.g. http://lists.xen.org/archives/html/xen-devel/2012-03/msg01181.html I'm sure there was earlier discussion which led to that, but I can't seem to see it in the archives right now, perhaps I'm not looking for the right Subject. Olaf might have been intending to look into this (I can't quite remember where we left it) Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 10:31:57 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 10:31:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJiiU-000893-2D; Thu, 04 Oct 2012 10:31:42 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJiiR-00088w-V9 for xen-devel@lists.xensource.com; Thu, 04 Oct 2012 10:31:40 +0000 Received: from [85.158.143.35:51945] by server-1.bemta-4.messagelabs.com id 1A/E1-05684-B856D605; Thu, 04 Oct 2012 10:31:39 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1349346697!12345903!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODAxODI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13900 invoked from network); 4 Oct 2012 10:31:38 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 10:31:38 -0000 X-IronPort-AV: E=Sophos;i="4.80,533,1344211200"; d="scan'208";a="210269354" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 10:31:36 +0000 Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 06:31:36 -0400 Message-ID: <506D6587.7010100@citrix.com> Date: Thu, 4 Oct 2012 11:31:35 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120428 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: Jan Beulich References: <1348243464-15903-1-git-send-email-david.vrabel@citrix.com> <1348243464-15903-3-git-send-email-david.vrabel@citrix.com> <5061EFB2.1080407@citrix.com> <506D7D9A020000780009F9C8@nat28.tlf.novell.com> In-Reply-To: <506D7D9A020000780009F9C8@nat28.tlf.novell.com> Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 2/6] xen-blkfront: handle backend CLOSED without CLOSING X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 04/10/12 11:14, Jan Beulich wrote: >>>> On 25.09.12 at 19:53, David Vrabel wrote: >> @@ -1167,7 +1168,8 @@ blkfront_closing(struct blkfront_info *info) >> >> mutex_lock(&bdev->bd_mutex); >> >> - if (bdev->bd_openers) { >> + /* If the backend is already CLOSED, close now. */ >> + if (bdev->bd_openers && backend_state != XenbusStateClosed) { >> xenbus_dev_error(xbdev, -EBUSY, >> "Device in use; refusing to close"); >> xenbus_switch_state(xbdev, XenbusStateClosing); > > This looks wrong to me on a second glance: As long as there > are users of the device, I don't think we want to go into Closed > ourselves, irrespective of the backend state. Any users of the frontend device are screwed either way, as the backend is gone. It seems sensible to handle this case the same as (e.g.,) a physical unplug of a USB storage device. Removing the device and forcing all outstanding I/O to fail immediately rather than lingering in the rings, going nowhere. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 10:31:57 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 10:31:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJiiU-000893-2D; Thu, 04 Oct 2012 10:31:42 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJiiR-00088w-V9 for xen-devel@lists.xensource.com; Thu, 04 Oct 2012 10:31:40 +0000 Received: from [85.158.143.35:51945] by server-1.bemta-4.messagelabs.com id 1A/E1-05684-B856D605; Thu, 04 Oct 2012 10:31:39 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1349346697!12345903!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODAxODI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13900 invoked from network); 4 Oct 2012 10:31:38 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 10:31:38 -0000 X-IronPort-AV: E=Sophos;i="4.80,533,1344211200"; d="scan'208";a="210269354" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 10:31:36 +0000 Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 06:31:36 -0400 Message-ID: <506D6587.7010100@citrix.com> Date: Thu, 4 Oct 2012 11:31:35 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120428 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: Jan Beulich References: <1348243464-15903-1-git-send-email-david.vrabel@citrix.com> <1348243464-15903-3-git-send-email-david.vrabel@citrix.com> <5061EFB2.1080407@citrix.com> <506D7D9A020000780009F9C8@nat28.tlf.novell.com> In-Reply-To: <506D7D9A020000780009F9C8@nat28.tlf.novell.com> Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 2/6] xen-blkfront: handle backend CLOSED without CLOSING X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 04/10/12 11:14, Jan Beulich wrote: >>>> On 25.09.12 at 19:53, David Vrabel wrote: >> @@ -1167,7 +1168,8 @@ blkfront_closing(struct blkfront_info *info) >> >> mutex_lock(&bdev->bd_mutex); >> >> - if (bdev->bd_openers) { >> + /* If the backend is already CLOSED, close now. */ >> + if (bdev->bd_openers && backend_state != XenbusStateClosed) { >> xenbus_dev_error(xbdev, -EBUSY, >> "Device in use; refusing to close"); >> xenbus_switch_state(xbdev, XenbusStateClosing); > > This looks wrong to me on a second glance: As long as there > are users of the device, I don't think we want to go into Closed > ourselves, irrespective of the backend state. Any users of the frontend device are screwed either way, as the backend is gone. It seems sensible to handle this case the same as (e.g.,) a physical unplug of a USB storage device. Removing the device and forcing all outstanding I/O to fail immediately rather than lingering in the rings, going nowhere. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 10:37:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 10:37:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJinm-0008L2-UW; Thu, 04 Oct 2012 10:37:10 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJinl-0008Ku-MY for xen-devel@lists.xen.org; Thu, 04 Oct 2012 10:37:09 +0000 Received: from [85.158.143.35:19812] by server-2.bemta-4.messagelabs.com id 75/18-06610-5D66D605; Thu, 04 Oct 2012 10:37:09 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-6.tower-21.messagelabs.com!1349347028!21004882!1 X-Originating-IP: [81.29.64.94] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14963 invoked from network); 4 Oct 2012 10:37:08 -0000 Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94) by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Oct 2012 10:37:08 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1TJinj-000ABE-1G; Thu, 04 Oct 2012 10:37:07 +0000 Date: Thu, 4 Oct 2012 11:37:06 +0100 From: Tim Deegan To: Christoph Egger Message-ID: <20121004103706.GD38243@ocelot.phlegethon.org> References: <505C733B.50205@amd.com> <20120927145356.GG8831@ocelot.phlegethon.org> <50699FA6.6070805@amd.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <50699FA6.6070805@amd.com> User-Agent: Mutt/1.4.2.1i Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] nestedsvm: fix paging mode X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org At 15:50 +0200 on 01 Oct (1349106630), Christoph Egger wrote: > On 09/27/12 16:53, Tim Deegan wrote: > > > At 16:01 +0200 on 21 Sep (1348243291), Christoph Egger wrote: > >> > >> On VMRUN and VMEXIT emulation update the paging mode > >> for Shadow-on-Nested. This allows Xen to walk the > >> l1 hypervisors shadow page table correctly. > >> Problem found with 64bit Win7 and 32bit XPMode where > >> Win7 switches forth and back between long mode and > >> PAE legacy pagetables. > >> > >> Signed-off-by: Christoph Egger > > > > Don't you have to do this in other cases as well? I think that > > shadow-on-shadow might need it, at least. > > It is needed for all cases where the l1 guest does shadow paging. > This includes: Shadow-on-Nested and Shadow-on-Shadow. I've looked more closely at this and now I'm more confused. :) Hap-on-hap seems to be OK without it because the special case in paging_gva_to_gfn() does the right thing, using the nestedmode's pt walker. Why is that not good enough for shadow-on-hap? Is there another path that does unguarded pt walks? If so: - why is that path not a problem for hap-on-hap; and - shouldn't that be handled the same way, i.e. either handle everything at lookup time, like paging_gva_to_gfn() does, or handle everything by switching modes at VMRUN/EXIT? Shadow-on-shadow could potentially be handled the same way as the other configurations, by extending the special case in paging_gva_to_gfn(), but I suspect that a mode switch on VMRUN/EXIT is more likely to Just Work there. Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 10:37:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 10:37:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJinm-0008L2-UW; Thu, 04 Oct 2012 10:37:10 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJinl-0008Ku-MY for xen-devel@lists.xen.org; Thu, 04 Oct 2012 10:37:09 +0000 Received: from [85.158.143.35:19812] by server-2.bemta-4.messagelabs.com id 75/18-06610-5D66D605; Thu, 04 Oct 2012 10:37:09 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-6.tower-21.messagelabs.com!1349347028!21004882!1 X-Originating-IP: [81.29.64.94] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14963 invoked from network); 4 Oct 2012 10:37:08 -0000 Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94) by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Oct 2012 10:37:08 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1TJinj-000ABE-1G; Thu, 04 Oct 2012 10:37:07 +0000 Date: Thu, 4 Oct 2012 11:37:06 +0100 From: Tim Deegan To: Christoph Egger Message-ID: <20121004103706.GD38243@ocelot.phlegethon.org> References: <505C733B.50205@amd.com> <20120927145356.GG8831@ocelot.phlegethon.org> <50699FA6.6070805@amd.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <50699FA6.6070805@amd.com> User-Agent: Mutt/1.4.2.1i Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] nestedsvm: fix paging mode X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org At 15:50 +0200 on 01 Oct (1349106630), Christoph Egger wrote: > On 09/27/12 16:53, Tim Deegan wrote: > > > At 16:01 +0200 on 21 Sep (1348243291), Christoph Egger wrote: > >> > >> On VMRUN and VMEXIT emulation update the paging mode > >> for Shadow-on-Nested. This allows Xen to walk the > >> l1 hypervisors shadow page table correctly. > >> Problem found with 64bit Win7 and 32bit XPMode where > >> Win7 switches forth and back between long mode and > >> PAE legacy pagetables. > >> > >> Signed-off-by: Christoph Egger > > > > Don't you have to do this in other cases as well? I think that > > shadow-on-shadow might need it, at least. > > It is needed for all cases where the l1 guest does shadow paging. > This includes: Shadow-on-Nested and Shadow-on-Shadow. I've looked more closely at this and now I'm more confused. :) Hap-on-hap seems to be OK without it because the special case in paging_gva_to_gfn() does the right thing, using the nestedmode's pt walker. Why is that not good enough for shadow-on-hap? Is there another path that does unguarded pt walks? If so: - why is that path not a problem for hap-on-hap; and - shouldn't that be handled the same way, i.e. either handle everything at lookup time, like paging_gva_to_gfn() does, or handle everything by switching modes at VMRUN/EXIT? Shadow-on-shadow could potentially be handled the same way as the other configurations, by extending the special case in paging_gva_to_gfn(), but I suspect that a mode switch on VMRUN/EXIT is more likely to Just Work there. Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 11:32:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 11:32:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJjeZ-0000db-Ks; Thu, 04 Oct 2012 11:31:43 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJjeY-0000dK-AF for Xen-devel@lists.xen.org; Thu, 04 Oct 2012 11:31:42 +0000 X-Env-Sender: thanos.makatos@citrix.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1349350296!7338717!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3470 invoked from network); 4 Oct 2012 11:31:36 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 11:31:36 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="14938485" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 11:31:36 +0000 Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Thu, 4 Oct 2012 12:31:36 +0100 From: Thanos Makatos To: Kristoffer Egefelt , "Xen-devel@lists.xen.org" Date: Thu, 4 Oct 2012 12:31:34 +0100 Thread-Topic: [Xen-devel] Blktap userspace utils Thread-Index: Ac2iCefhC0ROFx/JQOqUxttrVoIQDgAGYPBg Message-ID: <4B45B535F7F6BE4CB1C044ED5115CDDE011ADEB1ED77@LONPMAILBOX01.citrite.net> References: <1672AF40-A2FD-4D58-93B2-1B8C506A799A@itoc.dk> In-Reply-To: <1672AF40-A2FD-4D58-93B2-1B8C506A799A@itoc.dk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [Xen-devel] Blktap userspace utils X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Just to let you know, I'm planning to import all of the github blktap2 functionality into blktap3 (blktap3 is based on a relatively recent github blktap2 version), once blktap3 makes it into the tree. Cheers -- Thanos Makatos > -----Original Message----- > From: xen-devel-bounces@lists.xen.org [mailto:xen-devel- > bounces@lists.xen.org] On Behalf Of Kristoffer Egefelt > Sent: 04 October 2012 08:34 > To: Xen-devel@lists.xen.org > Subject: [Xen-devel] Blktap userspace utils > > Hi, > > I'd like to use the blktap utils from https://github.com/xen-org/blktap > because of the mirror feature, as the blktap utils comming with xen > does not support this. > > Could anybody explain why there are two different blktap utils (one in > git and one comming with xen source) and how to compile the one from > git so that it works with libxl ? > > Any pointers greatly appreciated ;-) > > Thanks > > Regards > Kristoffer > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 11:32:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 11:32:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJjeZ-0000db-Ks; Thu, 04 Oct 2012 11:31:43 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJjeY-0000dK-AF for Xen-devel@lists.xen.org; Thu, 04 Oct 2012 11:31:42 +0000 X-Env-Sender: thanos.makatos@citrix.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1349350296!7338717!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3470 invoked from network); 4 Oct 2012 11:31:36 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 11:31:36 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="14938485" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 11:31:36 +0000 Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Thu, 4 Oct 2012 12:31:36 +0100 From: Thanos Makatos To: Kristoffer Egefelt , "Xen-devel@lists.xen.org" Date: Thu, 4 Oct 2012 12:31:34 +0100 Thread-Topic: [Xen-devel] Blktap userspace utils Thread-Index: Ac2iCefhC0ROFx/JQOqUxttrVoIQDgAGYPBg Message-ID: <4B45B535F7F6BE4CB1C044ED5115CDDE011ADEB1ED77@LONPMAILBOX01.citrite.net> References: <1672AF40-A2FD-4D58-93B2-1B8C506A799A@itoc.dk> In-Reply-To: <1672AF40-A2FD-4D58-93B2-1B8C506A799A@itoc.dk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [Xen-devel] Blktap userspace utils X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Just to let you know, I'm planning to import all of the github blktap2 functionality into blktap3 (blktap3 is based on a relatively recent github blktap2 version), once blktap3 makes it into the tree. Cheers -- Thanos Makatos > -----Original Message----- > From: xen-devel-bounces@lists.xen.org [mailto:xen-devel- > bounces@lists.xen.org] On Behalf Of Kristoffer Egefelt > Sent: 04 October 2012 08:34 > To: Xen-devel@lists.xen.org > Subject: [Xen-devel] Blktap userspace utils > > Hi, > > I'd like to use the blktap utils from https://github.com/xen-org/blktap > because of the mirror feature, as the blktap utils comming with xen > does not support this. > > Could anybody explain why there are two different blktap utils (one in > git and one comming with xen source) and how to compile the one from > git so that it works with libxl ? > > Any pointers greatly appreciated ;-) > > Thanks > > Regards > Kristoffer > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 11:39:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 11:39:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJjlS-0000tx-HK; Thu, 04 Oct 2012 11:38:50 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJjlQ-0000tp-OY for Xen-devel@lists.xen.org; Thu, 04 Oct 2012 11:38:48 +0000 Received: from [85.158.139.83:57488] by server-2.bemta-5.messagelabs.com id C5/58-28944-7457D605; Thu, 04 Oct 2012 11:38:47 +0000 X-Env-Sender: thanos.makatos@citrix.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1349350726!29434161!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17509 invoked from network); 4 Oct 2012 11:38:47 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 11:38:47 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="14938680" Received: from lonpmailmx02.citrite.net ([10.30.203.163]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 11:38:46 +0000 Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Thu, 4 Oct 2012 12:38:46 +0100 From: Thanos Makatos To: Thanos Makatos , Kristoffer Egefelt , "Xen-devel@lists.xen.org" Date: Thu, 4 Oct 2012 12:38:44 +0100 Thread-Topic: [Xen-devel] Blktap userspace utils Thread-Index: Ac2iCefhC0ROFx/JQOqUxttrVoIQDgAGYPBgAAAzVYA= Message-ID: <4B45B535F7F6BE4CB1C044ED5115CDDE011ADEB1ED80@LONPMAILBOX01.citrite.net> References: <1672AF40-A2FD-4D58-93B2-1B8C506A799A@itoc.dk> <4B45B535F7F6BE4CB1C044ED5115CDDE011ADEB1ED77@LONPMAILBOX01.citrite.net> In-Reply-To: <4B45B535F7F6BE4CB1C044ED5115CDDE011ADEB1ED77@LONPMAILBOX01.citrite.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [Xen-devel] Blktap userspace utils X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Of course you're welcome to do this if you want! :-) I'm planning to re-send a fairly cleaned-up version of blktap3 in the next few days. -- Thanos Makatos > -----Original Message----- > From: xen-devel-bounces@lists.xen.org [mailto:xen-devel- > bounces@lists.xen.org] On Behalf Of Thanos Makatos > Sent: 04 October 2012 12:32 > To: Kristoffer Egefelt; Xen-devel@lists.xen.org > Subject: Re: [Xen-devel] Blktap userspace utils > > Just to let you know, I'm planning to import all of the github blktap2 > functionality into blktap3 (blktap3 is based on a relatively recent > github blktap2 version), once blktap3 makes it into the tree. > > Cheers > > -- > Thanos Makatos > > > > -----Original Message----- > > From: xen-devel-bounces@lists.xen.org [mailto:xen-devel- > > bounces@lists.xen.org] On Behalf Of Kristoffer Egefelt > > Sent: 04 October 2012 08:34 > > To: Xen-devel@lists.xen.org > > Subject: [Xen-devel] Blktap userspace utils > > > > Hi, > > > > I'd like to use the blktap utils from > > https://github.com/xen-org/blktap because of the mirror feature, as > > the blktap utils comming with xen does not support this. > > > > Could anybody explain why there are two different blktap utils (one > in > > git and one comming with xen source) and how to compile the one from > > git so that it works with libxl ? > > > > Any pointers greatly appreciated ;-) > > > > Thanks > > > > Regards > > Kristoffer > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xen.org > > http://lists.xen.org/xen-devel > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 11:39:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 11:39:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJjlS-0000tx-HK; Thu, 04 Oct 2012 11:38:50 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJjlQ-0000tp-OY for Xen-devel@lists.xen.org; Thu, 04 Oct 2012 11:38:48 +0000 Received: from [85.158.139.83:57488] by server-2.bemta-5.messagelabs.com id C5/58-28944-7457D605; Thu, 04 Oct 2012 11:38:47 +0000 X-Env-Sender: thanos.makatos@citrix.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1349350726!29434161!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17509 invoked from network); 4 Oct 2012 11:38:47 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 11:38:47 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="14938680" Received: from lonpmailmx02.citrite.net ([10.30.203.163]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 11:38:46 +0000 Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Thu, 4 Oct 2012 12:38:46 +0100 From: Thanos Makatos To: Thanos Makatos , Kristoffer Egefelt , "Xen-devel@lists.xen.org" Date: Thu, 4 Oct 2012 12:38:44 +0100 Thread-Topic: [Xen-devel] Blktap userspace utils Thread-Index: Ac2iCefhC0ROFx/JQOqUxttrVoIQDgAGYPBgAAAzVYA= Message-ID: <4B45B535F7F6BE4CB1C044ED5115CDDE011ADEB1ED80@LONPMAILBOX01.citrite.net> References: <1672AF40-A2FD-4D58-93B2-1B8C506A799A@itoc.dk> <4B45B535F7F6BE4CB1C044ED5115CDDE011ADEB1ED77@LONPMAILBOX01.citrite.net> In-Reply-To: <4B45B535F7F6BE4CB1C044ED5115CDDE011ADEB1ED77@LONPMAILBOX01.citrite.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [Xen-devel] Blktap userspace utils X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Of course you're welcome to do this if you want! :-) I'm planning to re-send a fairly cleaned-up version of blktap3 in the next few days. -- Thanos Makatos > -----Original Message----- > From: xen-devel-bounces@lists.xen.org [mailto:xen-devel- > bounces@lists.xen.org] On Behalf Of Thanos Makatos > Sent: 04 October 2012 12:32 > To: Kristoffer Egefelt; Xen-devel@lists.xen.org > Subject: Re: [Xen-devel] Blktap userspace utils > > Just to let you know, I'm planning to import all of the github blktap2 > functionality into blktap3 (blktap3 is based on a relatively recent > github blktap2 version), once blktap3 makes it into the tree. > > Cheers > > -- > Thanos Makatos > > > > -----Original Message----- > > From: xen-devel-bounces@lists.xen.org [mailto:xen-devel- > > bounces@lists.xen.org] On Behalf Of Kristoffer Egefelt > > Sent: 04 October 2012 08:34 > > To: Xen-devel@lists.xen.org > > Subject: [Xen-devel] Blktap userspace utils > > > > Hi, > > > > I'd like to use the blktap utils from > > https://github.com/xen-org/blktap because of the mirror feature, as > > the blktap utils comming with xen does not support this. > > > > Could anybody explain why there are two different blktap utils (one > in > > git and one comming with xen source) and how to compile the one from > > git so that it works with libxl ? > > > > Any pointers greatly appreciated ;-) > > > > Thanks > > > > Regards > > Kristoffer > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xen.org > > http://lists.xen.org/xen-devel > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 11:53:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 11:53:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJjzI-0001mq-KC; Thu, 04 Oct 2012 11:53:08 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJjzH-0001mf-0i for xen-devel@lists.xen.org; Thu, 04 Oct 2012 11:53:07 +0000 Received: from [85.158.143.99:57174] by server-3.bemta-4.messagelabs.com id 40/53-10986-2A87D605; Thu, 04 Oct 2012 11:53:06 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1349351585!32881849!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19167 invoked from network); 4 Oct 2012 11:53:05 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 11:53:05 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="14939097" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 11:53:05 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 12:53:05 +0100 Message-ID: <1349351583.866.10.camel@zakaz.uk.xensource.com> From: Ian Campbell To: xen-devel Date: Thu, 4 Oct 2012 12:53:03 +0100 Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: Keir Fraser , Stefano Stabellini , Jan Beulich Subject: [Xen-devel] [PATCH] xen: arm: implement XENMEM_add_to_physmap_range X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is an implementation of XENMEM_add_to_physmap_range as previously discussed. This applies on top of git://xenbits.xen.org/people/ianc/xen-unstable.git arm-for-4.3 + Stefano's "ARM hypercall ABI: 64 bit ready" series. I think this should replace "HACK: arm: initial XENMAPSPACE_gmfn_foreign" (from the branch) and "xen: improve changes to xen_add_to_physmap" (from Stefano's series) and we should make it invalid to call XENMEM_add_to_physmap with XENMAPSPACE_gmfn_foreign (i.e. get rid of the union etc). I intend to do this as as I rebase the arm-for-4.3 branch to post for inclusion in mainline. i.e. drop the original HACK in favour of this patch. What is the status of Stefano's "ARM hypercall ABI: 64 bit ready"? It touches common and arch/x86 code/interfaces so it'll need pretty wide ranging ack's I think. 8<------------------------------------------------------- >From 1e889407a8e93fdbaf591c74fb3f2fe01f9016ac Mon Sep 17 00:00:00 2001 From: Ian Campbell Date: Thu, 4 Oct 2012 11:25:18 +0000 Subject: [PATCH] xen: arm: implement XENMEM_add_to_physmap_range This allows for foreign mappings as well as batching, fitting all that into XENMEM_add_to_physmap wasn't possible. Signed-off-by: Ian Campbell --- xen/arch/arm/mm.c | 103 ++++++++++++++++++++++++++++++++++++------- xen/include/public/memory.h | 41 +++++++++++++---- xen/include/public/xen.h | 1 + 3 files changed, 119 insertions(+), 26 deletions(-) diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c index 3e8b6cc..9e7d2d2 100644 --- a/xen/arch/arm/mm.c +++ b/xen/arch/arm/mm.c @@ -26,6 +26,8 @@ #include #include #include +#include +#include #include #include #include @@ -462,14 +464,17 @@ void share_xen_page_with_guest(struct page_info *page, spin_unlock(&d->page_alloc_lock); } -static int xenmem_add_to_physmap_once( +static int xenmem_add_to_physmap_one( struct domain *d, - const struct xen_add_to_physmap *xatp) + uint16_t space, + domid_t foreign_domid, + unsigned long idx, + xen_pfn_t gpfn) { - unsigned long mfn = 0, idx = 0; + unsigned long mfn = 0; int rc; - switch ( xatp->space ) + switch ( space ) { case XENMAPSPACE_grant_table: spin_lock(&d->grant_table->lock); @@ -477,9 +482,8 @@ static int xenmem_add_to_physmap_once( if ( d->grant_table->gt_version == 0 ) d->grant_table->gt_version = 1; - idx = xatp->idx; if ( d->grant_table->gt_version == 2 && - (xatp->idx & XENMAPIDX_grant_table_status) ) + (idx & XENMAPIDX_grant_table_status) ) { idx &= ~XENMAPIDX_grant_table_status; if ( idx < nr_status_frames(d->grant_table) ) @@ -498,29 +502,31 @@ static int xenmem_add_to_physmap_once( spin_unlock(&d->grant_table->lock); break; case XENMAPSPACE_shared_info: - if ( xatp->idx == 0 ) + if ( idx == 0 ) mfn = virt_to_mfn(d->shared_info); break; case XENMAPSPACE_gmfn_foreign: { paddr_t maddr; struct domain *od; - - rc = rcu_lock_target_domain_by_id(xatp->u.foreign_domid, &od); + rc = rcu_lock_target_domain_by_id(foreign_domid, &od); if ( rc < 0 ) return rc; - maddr = p2m_lookup(od, xatp->idx << PAGE_SHIFT); + + maddr = p2m_lookup(od, idx << PAGE_SHIFT); if ( maddr == INVALID_PADDR ) { - printk("bad p2m lookup\n"); - dump_p2m_lookup(od, xatp->idx << PAGE_SHIFT); + dump_p2m_lookup(od, idx << PAGE_SHIFT); rcu_unlock_domain(od); return -EINVAL; } + mfn = maddr >> PAGE_SHIFT; + rcu_unlock_domain(od); break; } + default: return -ENOSYS; } @@ -528,17 +534,51 @@ static int xenmem_add_to_physmap_once( domain_lock(d); /* Map at new location. */ - rc = guest_physmap_add_page(d, xatp->gpfn, mfn, 0); + rc = guest_physmap_add_page(d, gpfn, mfn, 0); domain_unlock(d); return rc; } -static int xenmem_add_to_physmap(struct domain *d, - struct xen_add_to_physmap *xatp) +static int xenmem_add_to_physmap_range(struct domain *d, + struct xen_add_to_physmap_range *xatpr) { - return xenmem_add_to_physmap_once(d, xatp); + int rc; + + /* Process entries in reverse order to allow continuations */ + while ( xatpr->size > 0 ) + { + xen_ulong_t idx; + xen_pfn_t gpfn; + + rc = copy_from_guest_offset(&idx, xatpr->idxs, xatpr->size-1, 1); + if ( rc < 0 ) + goto out; + + rc = copy_from_guest_offset(&gpfn, xatpr->gpfns, xatpr->size-1, 1); + if ( rc < 0 ) + goto out; + + rc = xenmem_add_to_physmap_one(d, xatpr->space, + xatpr->foreign_domid, + idx, gpfn); + + xatpr->size--; + + /* Check for continuation if it's not the last interation */ + if ( xatpr->size > 0 && hypercall_preempt_check() ) + { + rc = -EAGAIN; + goto out; + } + } + + rc = 0; + +out: + return rc; + } long arch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg) @@ -559,13 +599,42 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg) if ( rc != 0 ) return rc; - rc = xenmem_add_to_physmap(d, &xatp); + rc = xenmem_add_to_physmap_one(d, xatp.space, + xatp.space == XENMAPSPACE_gmfn_foreign ? + xatp.u.foreign_domid : DOMID_INVALID, + xatp.idx, xatp.gpfn); rcu_unlock_domain(d); return rc; } + case XENMEM_add_to_physmap_range: + { + struct xen_add_to_physmap_range xatpr; + struct domain *d; + + if ( copy_from_guest(&xatpr, arg, 1) ) + return -EFAULT; + + rc = rcu_lock_target_domain_by_id(xatpr.domid, &d); + if ( rc != 0 ) + return rc; + + rc = xenmem_add_to_physmap_range(d, &xatpr); + + rcu_unlock_domain(d); + + if ( rc && copy_to_guest(arg, &xatpr, 1) ) + rc = -EFAULT; + + if ( rc == -EAGAIN ) + rc = hypercall_create_continuation( + __HYPERVISOR_memory_op, "ih", op, arg); + + return rc; + } + default: return -ENOSYS; } diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h index 7d4ee26..29d0b94 100644 --- a/xen/include/public/memory.h +++ b/xen/include/public/memory.h @@ -198,6 +198,15 @@ struct xen_machphys_mapping { typedef struct xen_machphys_mapping xen_machphys_mapping_t; DEFINE_XEN_GUEST_HANDLE(xen_machphys_mapping_t); +/* Source mapping space. */ +/* ` enum phys_map_space { */ +#define XENMAPSPACE_shared_info 0 /* shared info page */ +#define XENMAPSPACE_grant_table 1 /* grant table page */ +#define XENMAPSPACE_gmfn 2 /* GMFN */ +#define XENMAPSPACE_gmfn_range 3 /* GMFN range */ +#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another dom */ +/* ` } */ + /* * Sets the GPFN at which a particular page appears in the specified guest's * pseudophysical address space. @@ -215,25 +224,39 @@ struct xen_add_to_physmap { domid_t foreign_domid; } u; - /* Source mapping space. */ -#define XENMAPSPACE_shared_info 0 /* shared info page */ -#define XENMAPSPACE_grant_table 1 /* grant table page */ -#define XENMAPSPACE_gmfn 2 /* GMFN */ -#define XENMAPSPACE_gmfn_range 3 /* GMFN range */ -#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */ - unsigned int space; + unsigned int space; /* => enum phys_map_space */ #define XENMAPIDX_grant_table_status 0x80000000 - /* Index into source mapping space. */ + /* Index into space being mapped. */ xen_ulong_t idx; - /* GPFN where the source mapping page should appear. */ + /* GPFN in domid where the source mapping page should appear. */ xen_pfn_t gpfn; }; typedef struct xen_add_to_physmap xen_add_to_physmap_t; DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_t); +/* A batched version of add_to_physmap. */ +#define XENMEM_add_to_physmap_range 23 +struct xen_add_to_physmap_range { + /* Which domain to change the mapping for. */ + domid_t domid; + uint16_t space; /* => enum phys_map_space */ + + /* Number of pages to go through */ + uint16_t size; + domid_t foreign_domid; /* IFF gmfn_foreign */ + + /* Indexes into space being mapped. */ + XEN_GUEST_HANDLE(xen_ulong_t) idxs; + + /* GPFN in domdwhere the source mapping page should appear. */ + XEN_GUEST_HANDLE(xen_pfn_t) gpfns; +}; +typedef struct xen_add_to_physmap_range xen_add_to_physmap_range_t; +DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_range_t); + /* * Unmaps the page appearing at a particular GPFN from the specified guest's * pseudophysical address space. diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h index b2f6c50..9425520 100644 --- a/xen/include/public/xen.h +++ b/xen/include/public/xen.h @@ -51,6 +51,7 @@ DEFINE_XEN_GUEST_HANDLE(void); DEFINE_XEN_GUEST_HANDLE(uint64_t); DEFINE_XEN_GUEST_HANDLE(xen_pfn_t); +DEFINE_XEN_GUEST_HANDLE(xen_ulong_t); #endif /* -- 1.7.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 11:53:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 11:53:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJjzI-0001mq-KC; Thu, 04 Oct 2012 11:53:08 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJjzH-0001mf-0i for xen-devel@lists.xen.org; Thu, 04 Oct 2012 11:53:07 +0000 Received: from [85.158.143.99:57174] by server-3.bemta-4.messagelabs.com id 40/53-10986-2A87D605; Thu, 04 Oct 2012 11:53:06 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1349351585!32881849!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19167 invoked from network); 4 Oct 2012 11:53:05 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 11:53:05 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="14939097" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 11:53:05 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 12:53:05 +0100 Message-ID: <1349351583.866.10.camel@zakaz.uk.xensource.com> From: Ian Campbell To: xen-devel Date: Thu, 4 Oct 2012 12:53:03 +0100 Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: Keir Fraser , Stefano Stabellini , Jan Beulich Subject: [Xen-devel] [PATCH] xen: arm: implement XENMEM_add_to_physmap_range X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is an implementation of XENMEM_add_to_physmap_range as previously discussed. This applies on top of git://xenbits.xen.org/people/ianc/xen-unstable.git arm-for-4.3 + Stefano's "ARM hypercall ABI: 64 bit ready" series. I think this should replace "HACK: arm: initial XENMAPSPACE_gmfn_foreign" (from the branch) and "xen: improve changes to xen_add_to_physmap" (from Stefano's series) and we should make it invalid to call XENMEM_add_to_physmap with XENMAPSPACE_gmfn_foreign (i.e. get rid of the union etc). I intend to do this as as I rebase the arm-for-4.3 branch to post for inclusion in mainline. i.e. drop the original HACK in favour of this patch. What is the status of Stefano's "ARM hypercall ABI: 64 bit ready"? It touches common and arch/x86 code/interfaces so it'll need pretty wide ranging ack's I think. 8<------------------------------------------------------- >From 1e889407a8e93fdbaf591c74fb3f2fe01f9016ac Mon Sep 17 00:00:00 2001 From: Ian Campbell Date: Thu, 4 Oct 2012 11:25:18 +0000 Subject: [PATCH] xen: arm: implement XENMEM_add_to_physmap_range This allows for foreign mappings as well as batching, fitting all that into XENMEM_add_to_physmap wasn't possible. Signed-off-by: Ian Campbell --- xen/arch/arm/mm.c | 103 ++++++++++++++++++++++++++++++++++++------- xen/include/public/memory.h | 41 +++++++++++++---- xen/include/public/xen.h | 1 + 3 files changed, 119 insertions(+), 26 deletions(-) diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c index 3e8b6cc..9e7d2d2 100644 --- a/xen/arch/arm/mm.c +++ b/xen/arch/arm/mm.c @@ -26,6 +26,8 @@ #include #include #include +#include +#include #include #include #include @@ -462,14 +464,17 @@ void share_xen_page_with_guest(struct page_info *page, spin_unlock(&d->page_alloc_lock); } -static int xenmem_add_to_physmap_once( +static int xenmem_add_to_physmap_one( struct domain *d, - const struct xen_add_to_physmap *xatp) + uint16_t space, + domid_t foreign_domid, + unsigned long idx, + xen_pfn_t gpfn) { - unsigned long mfn = 0, idx = 0; + unsigned long mfn = 0; int rc; - switch ( xatp->space ) + switch ( space ) { case XENMAPSPACE_grant_table: spin_lock(&d->grant_table->lock); @@ -477,9 +482,8 @@ static int xenmem_add_to_physmap_once( if ( d->grant_table->gt_version == 0 ) d->grant_table->gt_version = 1; - idx = xatp->idx; if ( d->grant_table->gt_version == 2 && - (xatp->idx & XENMAPIDX_grant_table_status) ) + (idx & XENMAPIDX_grant_table_status) ) { idx &= ~XENMAPIDX_grant_table_status; if ( idx < nr_status_frames(d->grant_table) ) @@ -498,29 +502,31 @@ static int xenmem_add_to_physmap_once( spin_unlock(&d->grant_table->lock); break; case XENMAPSPACE_shared_info: - if ( xatp->idx == 0 ) + if ( idx == 0 ) mfn = virt_to_mfn(d->shared_info); break; case XENMAPSPACE_gmfn_foreign: { paddr_t maddr; struct domain *od; - - rc = rcu_lock_target_domain_by_id(xatp->u.foreign_domid, &od); + rc = rcu_lock_target_domain_by_id(foreign_domid, &od); if ( rc < 0 ) return rc; - maddr = p2m_lookup(od, xatp->idx << PAGE_SHIFT); + + maddr = p2m_lookup(od, idx << PAGE_SHIFT); if ( maddr == INVALID_PADDR ) { - printk("bad p2m lookup\n"); - dump_p2m_lookup(od, xatp->idx << PAGE_SHIFT); + dump_p2m_lookup(od, idx << PAGE_SHIFT); rcu_unlock_domain(od); return -EINVAL; } + mfn = maddr >> PAGE_SHIFT; + rcu_unlock_domain(od); break; } + default: return -ENOSYS; } @@ -528,17 +534,51 @@ static int xenmem_add_to_physmap_once( domain_lock(d); /* Map at new location. */ - rc = guest_physmap_add_page(d, xatp->gpfn, mfn, 0); + rc = guest_physmap_add_page(d, gpfn, mfn, 0); domain_unlock(d); return rc; } -static int xenmem_add_to_physmap(struct domain *d, - struct xen_add_to_physmap *xatp) +static int xenmem_add_to_physmap_range(struct domain *d, + struct xen_add_to_physmap_range *xatpr) { - return xenmem_add_to_physmap_once(d, xatp); + int rc; + + /* Process entries in reverse order to allow continuations */ + while ( xatpr->size > 0 ) + { + xen_ulong_t idx; + xen_pfn_t gpfn; + + rc = copy_from_guest_offset(&idx, xatpr->idxs, xatpr->size-1, 1); + if ( rc < 0 ) + goto out; + + rc = copy_from_guest_offset(&gpfn, xatpr->gpfns, xatpr->size-1, 1); + if ( rc < 0 ) + goto out; + + rc = xenmem_add_to_physmap_one(d, xatpr->space, + xatpr->foreign_domid, + idx, gpfn); + + xatpr->size--; + + /* Check for continuation if it's not the last interation */ + if ( xatpr->size > 0 && hypercall_preempt_check() ) + { + rc = -EAGAIN; + goto out; + } + } + + rc = 0; + +out: + return rc; + } long arch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg) @@ -559,13 +599,42 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg) if ( rc != 0 ) return rc; - rc = xenmem_add_to_physmap(d, &xatp); + rc = xenmem_add_to_physmap_one(d, xatp.space, + xatp.space == XENMAPSPACE_gmfn_foreign ? + xatp.u.foreign_domid : DOMID_INVALID, + xatp.idx, xatp.gpfn); rcu_unlock_domain(d); return rc; } + case XENMEM_add_to_physmap_range: + { + struct xen_add_to_physmap_range xatpr; + struct domain *d; + + if ( copy_from_guest(&xatpr, arg, 1) ) + return -EFAULT; + + rc = rcu_lock_target_domain_by_id(xatpr.domid, &d); + if ( rc != 0 ) + return rc; + + rc = xenmem_add_to_physmap_range(d, &xatpr); + + rcu_unlock_domain(d); + + if ( rc && copy_to_guest(arg, &xatpr, 1) ) + rc = -EFAULT; + + if ( rc == -EAGAIN ) + rc = hypercall_create_continuation( + __HYPERVISOR_memory_op, "ih", op, arg); + + return rc; + } + default: return -ENOSYS; } diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h index 7d4ee26..29d0b94 100644 --- a/xen/include/public/memory.h +++ b/xen/include/public/memory.h @@ -198,6 +198,15 @@ struct xen_machphys_mapping { typedef struct xen_machphys_mapping xen_machphys_mapping_t; DEFINE_XEN_GUEST_HANDLE(xen_machphys_mapping_t); +/* Source mapping space. */ +/* ` enum phys_map_space { */ +#define XENMAPSPACE_shared_info 0 /* shared info page */ +#define XENMAPSPACE_grant_table 1 /* grant table page */ +#define XENMAPSPACE_gmfn 2 /* GMFN */ +#define XENMAPSPACE_gmfn_range 3 /* GMFN range */ +#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another dom */ +/* ` } */ + /* * Sets the GPFN at which a particular page appears in the specified guest's * pseudophysical address space. @@ -215,25 +224,39 @@ struct xen_add_to_physmap { domid_t foreign_domid; } u; - /* Source mapping space. */ -#define XENMAPSPACE_shared_info 0 /* shared info page */ -#define XENMAPSPACE_grant_table 1 /* grant table page */ -#define XENMAPSPACE_gmfn 2 /* GMFN */ -#define XENMAPSPACE_gmfn_range 3 /* GMFN range */ -#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */ - unsigned int space; + unsigned int space; /* => enum phys_map_space */ #define XENMAPIDX_grant_table_status 0x80000000 - /* Index into source mapping space. */ + /* Index into space being mapped. */ xen_ulong_t idx; - /* GPFN where the source mapping page should appear. */ + /* GPFN in domid where the source mapping page should appear. */ xen_pfn_t gpfn; }; typedef struct xen_add_to_physmap xen_add_to_physmap_t; DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_t); +/* A batched version of add_to_physmap. */ +#define XENMEM_add_to_physmap_range 23 +struct xen_add_to_physmap_range { + /* Which domain to change the mapping for. */ + domid_t domid; + uint16_t space; /* => enum phys_map_space */ + + /* Number of pages to go through */ + uint16_t size; + domid_t foreign_domid; /* IFF gmfn_foreign */ + + /* Indexes into space being mapped. */ + XEN_GUEST_HANDLE(xen_ulong_t) idxs; + + /* GPFN in domdwhere the source mapping page should appear. */ + XEN_GUEST_HANDLE(xen_pfn_t) gpfns; +}; +typedef struct xen_add_to_physmap_range xen_add_to_physmap_range_t; +DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_range_t); + /* * Unmaps the page appearing at a particular GPFN from the specified guest's * pseudophysical address space. diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h index b2f6c50..9425520 100644 --- a/xen/include/public/xen.h +++ b/xen/include/public/xen.h @@ -51,6 +51,7 @@ DEFINE_XEN_GUEST_HANDLE(void); DEFINE_XEN_GUEST_HANDLE(uint64_t); DEFINE_XEN_GUEST_HANDLE(xen_pfn_t); +DEFINE_XEN_GUEST_HANDLE(xen_ulong_t); #endif /* -- 1.7.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 12:03:57 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 12:03:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJk9U-0002Nv-BF; Thu, 04 Oct 2012 12:03:40 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJk9S-0002No-LI for xen-devel@lists.xen.org; Thu, 04 Oct 2012 12:03:39 +0000 Received: from [85.158.137.99:62226] by server-11.bemta-3.messagelabs.com id D2/86-21460-91B7D605; Thu, 04 Oct 2012 12:03:37 +0000 X-Env-Sender: jean.guyader@gmail.com X-Msg-Ref: server-5.tower-217.messagelabs.com!1349352215!15517556!1 X-Originating-IP: [209.85.220.173] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17106 invoked from network); 4 Oct 2012 12:03:36 -0000 Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com) (209.85.220.173) by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 12:03:36 -0000 Received: by mail-vc0-f173.google.com with SMTP id fl15so567798vcb.32 for ; Thu, 04 Oct 2012 05:03:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=imrkF7jJktBa4RA+ZpMpCWasGJXSmPh5o5uxOzCcOpY=; b=Vk4Z9wIWO7SOb2TOg6zaxYc9XXC3UzbGfmFRxKMl54WxY14e1WKqhfKxGkYCd7QBnB DU31fKEQJ4/tCq5LsIH+DXkiovc+Hr7XPSUfmu7URi7gSD7ttBRyDdDwivuo8WAw80vJ euEK2AdTH3i7wdZ52/wQM4MvlwZ1xAcbrggXrqFUdIjvhXlgyjOEaPHwoYmeCdpYwJS4 5nC+MKrjes1599fXjlVVh98Po5mODfP50cvcoRqtPhyHa02LFEHh3NELDeAddErJ+i/h 6yJbrLAx2U8rhD+EGSeiZxrN7mloXzYRC6H2mNm+iL1sqZwqh5XAVMmkDJTgOkabNlEs yVYQ== Received: by 10.220.225.138 with SMTP id is10mr2998849vcb.24.1349352215473; Thu, 04 Oct 2012 05:03:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.234.5 with HTTP; Thu, 4 Oct 2012 05:03:15 -0700 (PDT) In-Reply-To: <505B2636020000780009CAA6@nat28.tlf.novell.com> References: <1348141322-28657-1-git-send-email-jean.guyader@citrix.com> <1348141322-28657-5-git-send-email-jean.guyader@citrix.com> <505B2636020000780009CAA6@nat28.tlf.novell.com> From: Jean Guyader Date: Thu, 4 Oct 2012 13:03:15 +0100 Message-ID: To: Jan Beulich Cc: tim@xen.org, Jean Guyader , xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH 4/4] xen: Add V4V implementation X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 20 September 2012 13:20, Jan Beulich wrote: >>>> On 20.09.12 at 13:42, Jean Guyader wrote: >>+ case V4VOP_register_ring: >>+ { >>+ XEN_GUEST_HANDLE(v4v_ring_t) ring_hnd = >>+ guest_handle_cast(arg1, v4v_ring_t); >>+ XEN_GUEST_HANDLE(xen_pfn_t) pfn_hnd = >>+ guest_handle_cast(arg2, xen_pfn_t); >>+ uint32_t npage = arg3; >>+ if ( unlikely(!guest_handle_okay(ring_hnd, 1)) ) >>+ goto out; >>+ if ( unlikely(!guest_handle_okay(pfn_hnd, npage)) ) >>+ goto out; > > Here and below - this isn't sufficient for compat guests, or else > you give them a way to point into the compat m2p table. > I'll probably switch to uint64_t for the v4v mfn list instead of using xen_pfn_t which are unsigned long. That way I can save the need for a compat wrapper. >>+ if ( unlikely(!guest_handle_okay(addr_hnd, 1)) ) >>+ goto out; >>+ if ( copy_from_guest(&addr, addr_hnd, 1) ) >>+ goto out; > > The former is redundant with the latter. Also, if you already > used guest_handle_okay() on an array, you then can (and > should) use the cheaper __copy_{to,from}_guest() functions. > While looking at this, I also spotted at least on guest access > without error checking. Plus many guest accesses happen > with some sort of lock held - that'll cause problems when the > guest memory you're trying to access was paged out (quite > likely you would be able to point out other such cases, but > those likely predate paging, and hence are an oversight of > whoever introduced the paging code). > There are plenty of other place in Xen where we copy data from a guest with some sort of lock held. I understand that the new code should do it's best to make sure it works correctly with the Xen paging code. The best way to solve this might not be try to to avoid copying from guest memory under a lock. I've discussed this with Tim and maybe we could introduce a new copy_from_guest which is aware of the paging and returns a specific error, and then we could cleanly unlock everything and issue a continuation that will fixup the memory. >>+struct v4v_ring_message_header >>+{ >>+ uint32_t len; >>+ uint32_t pad0; > > Why? v4v_addr_t is 4-byte aligned. > >>+ v4v_addr_t source; >>+ uint32_t message_type; >>+ uint32_t pad1; > > And again, why? > >>+#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L >>+ uint8_t data[]; >>+#elif defined(__GNUC__) >>+ uint8_t data[0]; >>+#endif >>+}; > ... >>+/* >>+ * V4VOP_register_ring >>+ * >>+ * Registers a ring with Xen. If a ring with the same v4v_ring_id exists, >>+ * the hypercall will return -EEXIST. >>+ * >>+ * do_v4v_op(V4VOP_unregister_ring, >>+ * XEN_GUEST_HANDLE(v4v_ring_t), XEN_GUEST_HANDLE(xen_pfn_t), >>+ * npage, 0) >>+ */ >>+#define V4VOP_register_ring 1 > > "register" or "unregister"? > > Also, note the use of v4v_ring_t here, but ... > >>+/* >>+ * V4VOP_unregister_ring >>+ * >>+ * Unregister a ring. >>+ * >>+ * do_v4v_op(V4VOP_unregister_ring, >>+ * XEN_GUEST_HANDLE(v4v_ring), >>+ * NULL, 0, 0) >>+ */ >>+#define V4VOP_unregister_ring 2 > > ... not here. Please be consistent, even if this is just comments. > (Again at least for V4VOP_sendv.) > >>+/* >>+ * V4VOP_viptables_list >>+ * >>+ * Delete a filtering rules at a position or the rule > > Delete? Also, here and above, make clear whether you talk > about a single or multiple rules. > >>+ * that matches "rule". >>+ * >>+ * do_v4v_op(V4VOP_viptables_list, >>+ * XEN_GUEST_HANDLE(v4v_vitpables_list_t) list, >>+ * NULL, 0, 0) >>+ */ >>+#define V4VOP_viptables_list 8 > > Also, with all of the padding fields and unused arguments (for > certain sub-ops) - if you see the slightest chance of them ever > getting used for some extension, you will want to make sure > they got zero-filled by the guest. > Thanks for the review, Jean _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 12:03:57 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 12:03:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJk9U-0002Nv-BF; Thu, 04 Oct 2012 12:03:40 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJk9S-0002No-LI for xen-devel@lists.xen.org; Thu, 04 Oct 2012 12:03:39 +0000 Received: from [85.158.137.99:62226] by server-11.bemta-3.messagelabs.com id D2/86-21460-91B7D605; Thu, 04 Oct 2012 12:03:37 +0000 X-Env-Sender: jean.guyader@gmail.com X-Msg-Ref: server-5.tower-217.messagelabs.com!1349352215!15517556!1 X-Originating-IP: [209.85.220.173] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17106 invoked from network); 4 Oct 2012 12:03:36 -0000 Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com) (209.85.220.173) by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 12:03:36 -0000 Received: by mail-vc0-f173.google.com with SMTP id fl15so567798vcb.32 for ; Thu, 04 Oct 2012 05:03:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=imrkF7jJktBa4RA+ZpMpCWasGJXSmPh5o5uxOzCcOpY=; b=Vk4Z9wIWO7SOb2TOg6zaxYc9XXC3UzbGfmFRxKMl54WxY14e1WKqhfKxGkYCd7QBnB DU31fKEQJ4/tCq5LsIH+DXkiovc+Hr7XPSUfmu7URi7gSD7ttBRyDdDwivuo8WAw80vJ euEK2AdTH3i7wdZ52/wQM4MvlwZ1xAcbrggXrqFUdIjvhXlgyjOEaPHwoYmeCdpYwJS4 5nC+MKrjes1599fXjlVVh98Po5mODfP50cvcoRqtPhyHa02LFEHh3NELDeAddErJ+i/h 6yJbrLAx2U8rhD+EGSeiZxrN7mloXzYRC6H2mNm+iL1sqZwqh5XAVMmkDJTgOkabNlEs yVYQ== Received: by 10.220.225.138 with SMTP id is10mr2998849vcb.24.1349352215473; Thu, 04 Oct 2012 05:03:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.234.5 with HTTP; Thu, 4 Oct 2012 05:03:15 -0700 (PDT) In-Reply-To: <505B2636020000780009CAA6@nat28.tlf.novell.com> References: <1348141322-28657-1-git-send-email-jean.guyader@citrix.com> <1348141322-28657-5-git-send-email-jean.guyader@citrix.com> <505B2636020000780009CAA6@nat28.tlf.novell.com> From: Jean Guyader Date: Thu, 4 Oct 2012 13:03:15 +0100 Message-ID: To: Jan Beulich Cc: tim@xen.org, Jean Guyader , xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH 4/4] xen: Add V4V implementation X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 20 September 2012 13:20, Jan Beulich wrote: >>>> On 20.09.12 at 13:42, Jean Guyader wrote: >>+ case V4VOP_register_ring: >>+ { >>+ XEN_GUEST_HANDLE(v4v_ring_t) ring_hnd = >>+ guest_handle_cast(arg1, v4v_ring_t); >>+ XEN_GUEST_HANDLE(xen_pfn_t) pfn_hnd = >>+ guest_handle_cast(arg2, xen_pfn_t); >>+ uint32_t npage = arg3; >>+ if ( unlikely(!guest_handle_okay(ring_hnd, 1)) ) >>+ goto out; >>+ if ( unlikely(!guest_handle_okay(pfn_hnd, npage)) ) >>+ goto out; > > Here and below - this isn't sufficient for compat guests, or else > you give them a way to point into the compat m2p table. > I'll probably switch to uint64_t for the v4v mfn list instead of using xen_pfn_t which are unsigned long. That way I can save the need for a compat wrapper. >>+ if ( unlikely(!guest_handle_okay(addr_hnd, 1)) ) >>+ goto out; >>+ if ( copy_from_guest(&addr, addr_hnd, 1) ) >>+ goto out; > > The former is redundant with the latter. Also, if you already > used guest_handle_okay() on an array, you then can (and > should) use the cheaper __copy_{to,from}_guest() functions. > While looking at this, I also spotted at least on guest access > without error checking. Plus many guest accesses happen > with some sort of lock held - that'll cause problems when the > guest memory you're trying to access was paged out (quite > likely you would be able to point out other such cases, but > those likely predate paging, and hence are an oversight of > whoever introduced the paging code). > There are plenty of other place in Xen where we copy data from a guest with some sort of lock held. I understand that the new code should do it's best to make sure it works correctly with the Xen paging code. The best way to solve this might not be try to to avoid copying from guest memory under a lock. I've discussed this with Tim and maybe we could introduce a new copy_from_guest which is aware of the paging and returns a specific error, and then we could cleanly unlock everything and issue a continuation that will fixup the memory. >>+struct v4v_ring_message_header >>+{ >>+ uint32_t len; >>+ uint32_t pad0; > > Why? v4v_addr_t is 4-byte aligned. > >>+ v4v_addr_t source; >>+ uint32_t message_type; >>+ uint32_t pad1; > > And again, why? > >>+#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L >>+ uint8_t data[]; >>+#elif defined(__GNUC__) >>+ uint8_t data[0]; >>+#endif >>+}; > ... >>+/* >>+ * V4VOP_register_ring >>+ * >>+ * Registers a ring with Xen. If a ring with the same v4v_ring_id exists, >>+ * the hypercall will return -EEXIST. >>+ * >>+ * do_v4v_op(V4VOP_unregister_ring, >>+ * XEN_GUEST_HANDLE(v4v_ring_t), XEN_GUEST_HANDLE(xen_pfn_t), >>+ * npage, 0) >>+ */ >>+#define V4VOP_register_ring 1 > > "register" or "unregister"? > > Also, note the use of v4v_ring_t here, but ... > >>+/* >>+ * V4VOP_unregister_ring >>+ * >>+ * Unregister a ring. >>+ * >>+ * do_v4v_op(V4VOP_unregister_ring, >>+ * XEN_GUEST_HANDLE(v4v_ring), >>+ * NULL, 0, 0) >>+ */ >>+#define V4VOP_unregister_ring 2 > > ... not here. Please be consistent, even if this is just comments. > (Again at least for V4VOP_sendv.) > >>+/* >>+ * V4VOP_viptables_list >>+ * >>+ * Delete a filtering rules at a position or the rule > > Delete? Also, here and above, make clear whether you talk > about a single or multiple rules. > >>+ * that matches "rule". >>+ * >>+ * do_v4v_op(V4VOP_viptables_list, >>+ * XEN_GUEST_HANDLE(v4v_vitpables_list_t) list, >>+ * NULL, 0, 0) >>+ */ >>+#define V4VOP_viptables_list 8 > > Also, with all of the padding fields and unused arguments (for > certain sub-ops) - if you see the slightest chance of them ever > getting used for some extension, you will want to make sure > they got zero-filled by the guest. > Thanks for the review, Jean _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 12:11:30 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 12:11:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJkGn-0002qT-Ls; Thu, 04 Oct 2012 12:11:13 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJkGl-0002qI-L6 for xen-devel@lists.xen.org; Thu, 04 Oct 2012 12:11:11 +0000 Received: from [85.158.143.99:23306] by server-1.bemta-4.messagelabs.com id 0D/6B-05684-EDC7D605; Thu, 04 Oct 2012 12:11:10 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1349352670!32508504!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24888 invoked from network); 4 Oct 2012 12:11:10 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-5.tower-216.messagelabs.com with SMTP; 4 Oct 2012 12:11:10 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 04 Oct 2012 13:11:10 +0100 Message-Id: <506D98FE020000780009FA23@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Thu, 04 Oct 2012 13:11:10 +0100 From: "Jan Beulich" To: "Jean Guyader" References: <1348141322-28657-1-git-send-email-jean.guyader@citrix.com> <1348141322-28657-5-git-send-email-jean.guyader@citrix.com> <505B2636020000780009CAA6@nat28.tlf.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: tim@xen.org, Jean Guyader , xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH 4/4] xen: Add V4V implementation X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 04.10.12 at 14:03, Jean Guyader wrote: > On 20 September 2012 13:20, Jan Beulich wrote: >>>>> On 20.09.12 at 13:42, Jean Guyader wrote: >>>+ case V4VOP_register_ring: >>>+ { >>>+ XEN_GUEST_HANDLE(v4v_ring_t) ring_hnd = >>>+ guest_handle_cast(arg1, v4v_ring_t); >>>+ XEN_GUEST_HANDLE(xen_pfn_t) pfn_hnd = >>>+ guest_handle_cast(arg2, xen_pfn_t); >>>+ uint32_t npage = arg3; >>>+ if ( unlikely(!guest_handle_okay(ring_hnd, 1)) ) >>>+ goto out; >>>+ if ( unlikely(!guest_handle_okay(pfn_hnd, npage)) ) >>>+ goto out; >> >> Here and below - this isn't sufficient for compat guests, or else >> you give them a way to point into the compat m2p table. >> > > I'll probably switch to uint64_t for the v4v mfn list instead of using > xen_pfn_t which > are unsigned long. That way I can save the need for a compat wrapper. But that comment of yours doesn't address the problem I pointed out. >>>+ if ( unlikely(!guest_handle_okay(addr_hnd, 1)) ) >>>+ goto out; >>>+ if ( copy_from_guest(&addr, addr_hnd, 1) ) >>>+ goto out; >> >> The former is redundant with the latter. Also, if you already >> used guest_handle_okay() on an array, you then can (and >> should) use the cheaper __copy_{to,from}_guest() functions. >> While looking at this, I also spotted at least on guest access >> without error checking. Plus many guest accesses happen >> with some sort of lock held - that'll cause problems when the >> guest memory you're trying to access was paged out (quite >> likely you would be able to point out other such cases, but >> those likely predate paging, and hence are an oversight of >> whoever introduced the paging code). >> > > There are plenty of other place in Xen where we copy data from > a guest with some sort of lock held. > > I understand that the new code should do it's best to make sure > it works correctly with the Xen paging code. > > The best way to solve this might not be try to to avoid copying from > guest memory under a lock. I've discussed this with Tim and maybe > we could introduce a new copy_from_guest which is aware of the paging > and returns a specific error, and then we could cleanly unlock everything > and issue a continuation that will fixup the memory. That's certainly an alternative. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 12:11:30 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 12:11:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJkGn-0002qT-Ls; Thu, 04 Oct 2012 12:11:13 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJkGl-0002qI-L6 for xen-devel@lists.xen.org; Thu, 04 Oct 2012 12:11:11 +0000 Received: from [85.158.143.99:23306] by server-1.bemta-4.messagelabs.com id 0D/6B-05684-EDC7D605; Thu, 04 Oct 2012 12:11:10 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1349352670!32508504!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24888 invoked from network); 4 Oct 2012 12:11:10 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-5.tower-216.messagelabs.com with SMTP; 4 Oct 2012 12:11:10 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 04 Oct 2012 13:11:10 +0100 Message-Id: <506D98FE020000780009FA23@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Thu, 04 Oct 2012 13:11:10 +0100 From: "Jan Beulich" To: "Jean Guyader" References: <1348141322-28657-1-git-send-email-jean.guyader@citrix.com> <1348141322-28657-5-git-send-email-jean.guyader@citrix.com> <505B2636020000780009CAA6@nat28.tlf.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: tim@xen.org, Jean Guyader , xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH 4/4] xen: Add V4V implementation X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 04.10.12 at 14:03, Jean Guyader wrote: > On 20 September 2012 13:20, Jan Beulich wrote: >>>>> On 20.09.12 at 13:42, Jean Guyader wrote: >>>+ case V4VOP_register_ring: >>>+ { >>>+ XEN_GUEST_HANDLE(v4v_ring_t) ring_hnd = >>>+ guest_handle_cast(arg1, v4v_ring_t); >>>+ XEN_GUEST_HANDLE(xen_pfn_t) pfn_hnd = >>>+ guest_handle_cast(arg2, xen_pfn_t); >>>+ uint32_t npage = arg3; >>>+ if ( unlikely(!guest_handle_okay(ring_hnd, 1)) ) >>>+ goto out; >>>+ if ( unlikely(!guest_handle_okay(pfn_hnd, npage)) ) >>>+ goto out; >> >> Here and below - this isn't sufficient for compat guests, or else >> you give them a way to point into the compat m2p table. >> > > I'll probably switch to uint64_t for the v4v mfn list instead of using > xen_pfn_t which > are unsigned long. That way I can save the need for a compat wrapper. But that comment of yours doesn't address the problem I pointed out. >>>+ if ( unlikely(!guest_handle_okay(addr_hnd, 1)) ) >>>+ goto out; >>>+ if ( copy_from_guest(&addr, addr_hnd, 1) ) >>>+ goto out; >> >> The former is redundant with the latter. Also, if you already >> used guest_handle_okay() on an array, you then can (and >> should) use the cheaper __copy_{to,from}_guest() functions. >> While looking at this, I also spotted at least on guest access >> without error checking. Plus many guest accesses happen >> with some sort of lock held - that'll cause problems when the >> guest memory you're trying to access was paged out (quite >> likely you would be able to point out other such cases, but >> those likely predate paging, and hence are an oversight of >> whoever introduced the paging code). >> > > There are plenty of other place in Xen where we copy data from > a guest with some sort of lock held. > > I understand that the new code should do it's best to make sure > it works correctly with the Xen paging code. > > The best way to solve this might not be try to to avoid copying from > guest memory under a lock. I've discussed this with Tim and maybe > we could introduce a new copy_from_guest which is aware of the paging > and returns a specific error, and then we could cleanly unlock everything > and issue a continuation that will fixup the memory. That's certainly an alternative. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 12:15:24 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 12:15:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJkKV-0003FM-VL; Thu, 04 Oct 2012 12:15:03 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJkKU-0003FA-20 for xen-devel@lists.xen.org; Thu, 04 Oct 2012 12:15:02 +0000 Received: from [85.158.143.35:9707] by server-2.bemta-4.messagelabs.com id 6C/05-06610-5CD7D605; Thu, 04 Oct 2012 12:15:01 +0000 X-Env-Sender: Christoph.Egger@amd.com X-Msg-Ref: server-2.tower-21.messagelabs.com!1349352899!9995708!1 X-Originating-IP: [216.32.181.186] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20099 invoked from network); 4 Oct 2012 12:15:00 -0000 Received: from ch1ehsobe006.messaging.microsoft.com (HELO ch1outboundpool.messaging.microsoft.com) (216.32.181.186) by server-2.tower-21.messagelabs.com with AES128-SHA encrypted SMTP; 4 Oct 2012 12:15:00 -0000 Received: from mail232-ch1-R.bigfish.com (10.43.68.239) by CH1EHSOBE002.bigfish.com (10.43.70.52) with Microsoft SMTP Server id 14.1.225.23; Thu, 4 Oct 2012 12:14:58 +0000 Received: from mail232-ch1 (localhost [127.0.0.1]) by mail232-ch1-R.bigfish.com (Postfix) with ESMTP id CE2A43E00ED; Thu, 4 Oct 2012 12:14:58 +0000 (UTC) X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null); IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI X-SpamScore: -4 X-BigFish: VPS-4(zzbb2dI98dI1432I1418Izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh137ah13b6h1441h1155h) Received: from mail232-ch1 (localhost.localdomain [127.0.0.1]) by mail232-ch1 (MessageSwitch) id 1349352897779941_874; Thu, 4 Oct 2012 12:14:57 +0000 (UTC) Received: from CH1EHSMHS004.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.229]) by mail232-ch1.bigfish.com (Postfix) with ESMTP id BD250A80048; Thu, 4 Oct 2012 12:14:57 +0000 (UTC) Received: from ausb3twp01.amd.com (163.181.249.108) by CH1EHSMHS004.bigfish.com (10.43.70.4) with Microsoft SMTP Server id 14.1.225.23; Thu, 4 Oct 2012 12:14:55 +0000 X-WSS-ID: 0MBDBCT-01-8GT-02 X-M-MSG: Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com [163.181.249.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ausb3twp01.amd.com (Axway MailGate 3.8.1) with ESMTP id 241B2102803C; Thu, 4 Oct 2012 07:14:53 -0500 (CDT) Received: from SAUSEXDAG06.amd.com (163.181.55.7) by sausexedgep02.amd.com (163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1; Thu, 4 Oct 2012 07:15:09 -0500 Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag06.amd.com (163.181.55.7) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 4 Oct 2012 07:14:53 -0500 Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp01.amd.com (172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Thu, 4 Oct 2012 08:14:52 -0400 Message-ID: <506D7DBB.7000900@amd.com> Date: Thu, 4 Oct 2012 14:14:51 +0200 From: Christoph Egger User-Agent: Mozilla/5.0 (X11; NetBSD amd64; rv:11.0) Gecko/20120404 Thunderbird/11.0 MIME-Version: 1.0 To: Tim Deegan References: <505C733B.50205@amd.com> <20120927145356.GG8831@ocelot.phlegethon.org> <50699FA6.6070805@amd.com> <20121004103706.GD38243@ocelot.phlegethon.org> In-Reply-To: <20121004103706.GD38243@ocelot.phlegethon.org> X-OriginatorOrg: amd.com Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] nestedsvm: fix paging mode X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 10/04/12 12:37, Tim Deegan wrote: > At 15:50 +0200 on 01 Oct (1349106630), Christoph Egger wrote: >> On 09/27/12 16:53, Tim Deegan wrote: >> >>> At 16:01 +0200 on 21 Sep (1348243291), Christoph Egger wrote: >>>> >>>> On VMRUN and VMEXIT emulation update the paging mode >>>> for Shadow-on-Nested. This allows Xen to walk the >>>> l1 hypervisors shadow page table correctly. >>>> Problem found with 64bit Win7 and 32bit XPMode where >>>> Win7 switches forth and back between long mode and >>>> PAE legacy pagetables. >>>> >>>> Signed-off-by: Christoph Egger >>> >>> Don't you have to do this in other cases as well? I think that >>> shadow-on-shadow might need it, at least. >> >> It is needed for all cases where the l1 guest does shadow paging. >> This includes: Shadow-on-Nested and Shadow-on-Shadow. > > I've looked more closely at this and now I'm more confused. :) > > Hap-on-hap seems to be OK without it because the special case in > paging_gva_to_gfn() does the right thing, using the nestedmode's pt > walker. > > Why is that not good enough for shadow-on-hap? Is there another path > that does unguarded pt walks? If so: > - why is that path not a problem for hap-on-hap; and > - shouldn't that be handled the same way, i.e. either handle everything > at lookup time, like paging_gva_to_gfn() does, or handle everything > by switching modes at VMRUN/EXIT? If the l1 guest does not do nested paging then Xen doesn't use the nestedmode's pt walker. Christoph > Shadow-on-shadow could potentially be handled the same way as the other > configurations, by extending the special case in paging_gva_to_gfn(), > but I suspect that a mode switch on VMRUN/EXIT is more likely to Just > Work there. > > Tim. > -- ---to satisfy European Law for business letters: Advanced Micro Devices GmbH Einsteinring 24, 85689 Dornach b. Muenchen Geschaeftsfuehrer: Alberto Bozzo Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 12:15:24 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 12:15:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJkKV-0003FM-VL; Thu, 04 Oct 2012 12:15:03 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJkKU-0003FA-20 for xen-devel@lists.xen.org; Thu, 04 Oct 2012 12:15:02 +0000 Received: from [85.158.143.35:9707] by server-2.bemta-4.messagelabs.com id 6C/05-06610-5CD7D605; Thu, 04 Oct 2012 12:15:01 +0000 X-Env-Sender: Christoph.Egger@amd.com X-Msg-Ref: server-2.tower-21.messagelabs.com!1349352899!9995708!1 X-Originating-IP: [216.32.181.186] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20099 invoked from network); 4 Oct 2012 12:15:00 -0000 Received: from ch1ehsobe006.messaging.microsoft.com (HELO ch1outboundpool.messaging.microsoft.com) (216.32.181.186) by server-2.tower-21.messagelabs.com with AES128-SHA encrypted SMTP; 4 Oct 2012 12:15:00 -0000 Received: from mail232-ch1-R.bigfish.com (10.43.68.239) by CH1EHSOBE002.bigfish.com (10.43.70.52) with Microsoft SMTP Server id 14.1.225.23; Thu, 4 Oct 2012 12:14:58 +0000 Received: from mail232-ch1 (localhost [127.0.0.1]) by mail232-ch1-R.bigfish.com (Postfix) with ESMTP id CE2A43E00ED; Thu, 4 Oct 2012 12:14:58 +0000 (UTC) X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null); IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI X-SpamScore: -4 X-BigFish: VPS-4(zzbb2dI98dI1432I1418Izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh137ah13b6h1441h1155h) Received: from mail232-ch1 (localhost.localdomain [127.0.0.1]) by mail232-ch1 (MessageSwitch) id 1349352897779941_874; Thu, 4 Oct 2012 12:14:57 +0000 (UTC) Received: from CH1EHSMHS004.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.229]) by mail232-ch1.bigfish.com (Postfix) with ESMTP id BD250A80048; Thu, 4 Oct 2012 12:14:57 +0000 (UTC) Received: from ausb3twp01.amd.com (163.181.249.108) by CH1EHSMHS004.bigfish.com (10.43.70.4) with Microsoft SMTP Server id 14.1.225.23; Thu, 4 Oct 2012 12:14:55 +0000 X-WSS-ID: 0MBDBCT-01-8GT-02 X-M-MSG: Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com [163.181.249.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ausb3twp01.amd.com (Axway MailGate 3.8.1) with ESMTP id 241B2102803C; Thu, 4 Oct 2012 07:14:53 -0500 (CDT) Received: from SAUSEXDAG06.amd.com (163.181.55.7) by sausexedgep02.amd.com (163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1; Thu, 4 Oct 2012 07:15:09 -0500 Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag06.amd.com (163.181.55.7) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 4 Oct 2012 07:14:53 -0500 Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp01.amd.com (172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Thu, 4 Oct 2012 08:14:52 -0400 Message-ID: <506D7DBB.7000900@amd.com> Date: Thu, 4 Oct 2012 14:14:51 +0200 From: Christoph Egger User-Agent: Mozilla/5.0 (X11; NetBSD amd64; rv:11.0) Gecko/20120404 Thunderbird/11.0 MIME-Version: 1.0 To: Tim Deegan References: <505C733B.50205@amd.com> <20120927145356.GG8831@ocelot.phlegethon.org> <50699FA6.6070805@amd.com> <20121004103706.GD38243@ocelot.phlegethon.org> In-Reply-To: <20121004103706.GD38243@ocelot.phlegethon.org> X-OriginatorOrg: amd.com Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] nestedsvm: fix paging mode X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 10/04/12 12:37, Tim Deegan wrote: > At 15:50 +0200 on 01 Oct (1349106630), Christoph Egger wrote: >> On 09/27/12 16:53, Tim Deegan wrote: >> >>> At 16:01 +0200 on 21 Sep (1348243291), Christoph Egger wrote: >>>> >>>> On VMRUN and VMEXIT emulation update the paging mode >>>> for Shadow-on-Nested. This allows Xen to walk the >>>> l1 hypervisors shadow page table correctly. >>>> Problem found with 64bit Win7 and 32bit XPMode where >>>> Win7 switches forth and back between long mode and >>>> PAE legacy pagetables. >>>> >>>> Signed-off-by: Christoph Egger >>> >>> Don't you have to do this in other cases as well? I think that >>> shadow-on-shadow might need it, at least. >> >> It is needed for all cases where the l1 guest does shadow paging. >> This includes: Shadow-on-Nested and Shadow-on-Shadow. > > I've looked more closely at this and now I'm more confused. :) > > Hap-on-hap seems to be OK without it because the special case in > paging_gva_to_gfn() does the right thing, using the nestedmode's pt > walker. > > Why is that not good enough for shadow-on-hap? Is there another path > that does unguarded pt walks? If so: > - why is that path not a problem for hap-on-hap; and > - shouldn't that be handled the same way, i.e. either handle everything > at lookup time, like paging_gva_to_gfn() does, or handle everything > by switching modes at VMRUN/EXIT? If the l1 guest does not do nested paging then Xen doesn't use the nestedmode's pt walker. Christoph > Shadow-on-shadow could potentially be handled the same way as the other > configurations, by extending the special case in paging_gva_to_gfn(), > but I suspect that a mode switch on VMRUN/EXIT is more likely to Just > Work there. > > Tim. > -- ---to satisfy European Law for business letters: Advanced Micro Devices GmbH Einsteinring 24, 85689 Dornach b. Muenchen Geschaeftsfuehrer: Alberto Bozzo Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 12:19:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 12:19:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJkOs-0003WI-LG; Thu, 04 Oct 2012 12:19:34 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJkOr-0003W2-23 for xen-devel@lists.xensource.com; Thu, 04 Oct 2012 12:19:33 +0000 Received: from [85.158.139.83:3231] by server-16.bemta-5.messagelabs.com id 1E/14-05998-4DE7D605; Thu, 04 Oct 2012 12:19:32 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1349353170!28868283!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODAxODI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21198 invoked from network); 4 Oct 2012 12:19:31 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 12:19:31 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="210277969" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 12:19:12 +0000 Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 08:19:11 -0400 Message-ID: <506D7EBF.9000908@citrix.com> Date: Thu, 4 Oct 2012 13:19:11 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120428 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: George Dunlap References: In-Reply-To: Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 1 of 2] xenalyze: decode PV_HYPERCALL_V2 records X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 03/10/12 11:33, George Dunlap wrote: > On Mon, Oct 1, 2012 at 6:52 PM, David Vrabel wrote: >> Newer version of Xen produce TRC_PV_HYPERCALL_V2 records instead of >> the older TRC_PV_HYPERCALL format. This updated format doesn't >> included the IP but it does include select hypercall arguments. >> >> Signed-off-by: David Vrabel > > Thanks -- I did a bunch of optimization work on xenalyze late last > year, so I'm afraid I'm going to be pretty picky about some things to > avoid losing that effort. :-) >> +static inline int pv_hypercall_arg_present(const struct record_info *ri, int arg) >> +{ >> + return (ri->d[0] >> (20 + 2*arg)) & 0x3; >> +} > > Try to avoid an integer multiply here; (arg<<1) or (arg+arg) please. The compiler does this for me. >> @@ -6523,6 +6537,168 @@ void pv_summary(struct pv_data *pv) { >> } >> } >> >> +uint64_t pv_hypercall_arg(const struct record_info *ri, int arg) >> +{ >> + int i, word; >> + >> + for (i = 0, word = 1; i < 6 && word < ri->extra_words; i++) { >> + int present = pv_hypercall_arg_present(ri, i); >> + >> + /* Is this the argument we're looking for? */ >> + if (i == arg) { >> + switch (present) { >> + case ARG_MISSING: >> + return 0; >> + case ARG_32BIT: >> + return ri->d[word]; >> + case ARG_64BIT: >> + return ((uint64_t)ri->d[word + 1] << 32) | ri->d[word]; >> + } >> + } >> + >> + /* Skip over any words for this argument. */ >> + word += present; >> + } > > > Alternately, since pv_hypercall_arg() returns 0 for a non-existent arg > anyway, couldn't you have an array, initialized to 0, and filled in as > appropriate? I've done this. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 12:19:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 12:19:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJkOs-0003WI-LG; Thu, 04 Oct 2012 12:19:34 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJkOr-0003W2-23 for xen-devel@lists.xensource.com; Thu, 04 Oct 2012 12:19:33 +0000 Received: from [85.158.139.83:3231] by server-16.bemta-5.messagelabs.com id 1E/14-05998-4DE7D605; Thu, 04 Oct 2012 12:19:32 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1349353170!28868283!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODAxODI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21198 invoked from network); 4 Oct 2012 12:19:31 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 12:19:31 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="210277969" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 12:19:12 +0000 Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 08:19:11 -0400 Message-ID: <506D7EBF.9000908@citrix.com> Date: Thu, 4 Oct 2012 13:19:11 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120428 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: George Dunlap References: In-Reply-To: Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [PATCH 1 of 2] xenalyze: decode PV_HYPERCALL_V2 records X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 03/10/12 11:33, George Dunlap wrote: > On Mon, Oct 1, 2012 at 6:52 PM, David Vrabel wrote: >> Newer version of Xen produce TRC_PV_HYPERCALL_V2 records instead of >> the older TRC_PV_HYPERCALL format. This updated format doesn't >> included the IP but it does include select hypercall arguments. >> >> Signed-off-by: David Vrabel > > Thanks -- I did a bunch of optimization work on xenalyze late last > year, so I'm afraid I'm going to be pretty picky about some things to > avoid losing that effort. :-) >> +static inline int pv_hypercall_arg_present(const struct record_info *ri, int arg) >> +{ >> + return (ri->d[0] >> (20 + 2*arg)) & 0x3; >> +} > > Try to avoid an integer multiply here; (arg<<1) or (arg+arg) please. The compiler does this for me. >> @@ -6523,6 +6537,168 @@ void pv_summary(struct pv_data *pv) { >> } >> } >> >> +uint64_t pv_hypercall_arg(const struct record_info *ri, int arg) >> +{ >> + int i, word; >> + >> + for (i = 0, word = 1; i < 6 && word < ri->extra_words; i++) { >> + int present = pv_hypercall_arg_present(ri, i); >> + >> + /* Is this the argument we're looking for? */ >> + if (i == arg) { >> + switch (present) { >> + case ARG_MISSING: >> + return 0; >> + case ARG_32BIT: >> + return ri->d[word]; >> + case ARG_64BIT: >> + return ((uint64_t)ri->d[word + 1] << 32) | ri->d[word]; >> + } >> + } >> + >> + /* Skip over any words for this argument. */ >> + word += present; >> + } > > > Alternately, since pv_hypercall_arg() returns 0 for a non-existent arg > anyway, couldn't you have an array, initialized to 0, and filled in as > appropriate? I've done this. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 12:30:44 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 12:30:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJkZT-0003nG-MT; Thu, 04 Oct 2012 12:30:31 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJkZR-0003mZ-J3 for xen-devel@lists.xen.org; Thu, 04 Oct 2012 12:30:29 +0000 Received: from [85.158.139.211:7876] by server-13.bemta-5.messagelabs.com id D1/DD-16359-5618D605; Thu, 04 Oct 2012 12:30:29 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-2.tower-206.messagelabs.com!1349353823!21048466!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQyMDg=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28375 invoked from network); 4 Oct 2012 12:30:25 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 12:30:25 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="40124777" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 12:30:22 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 08:30:21 -0400 Received: from qabil.uk.xensource.com ([10.80.2.76]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJkZJ-000843-Pa; Thu, 04 Oct 2012 13:30:21 +0100 MIME-Version: 1.0 X-Mercurial-Node: b595d8dacf35c84765fff11c97cacfcd1b07afb1 Message-ID: In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Thu, 4 Oct 2012 13:28:41 +0100 From: David Vrabel To: xen-devel@lists.xen.org Cc: David Vrabel , George Dunlap Subject: [Xen-devel] [PATCH 1 of 2] xenalyze: decode PV_HYPERCALL_V2 records X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Newer version of Xen produce TRC_PV_HYPERCALL_V2 records instead of the older TRC_PV_HYPERCALL format. This updated format doesn't included the IP but it does include select hypercall arguments. Signed-off-by: David Vrabel diff --git a/analyze.h b/analyze.h --- a/analyze.h +++ b/analyze.h @@ -3,6 +3,8 @@ #include +#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0])) + #define TRC_GEN_MAIN 0 #define TRC_SCHED_MAIN 1 #define TRC_DOM0OP_MAIN 2 diff --git a/pv.h b/pv.h new file mode 100644 --- /dev/null +++ b/pv.h @@ -0,0 +1,41 @@ +/* + * PV event decoding. + * + * Copyright (C) 2012 Citrix Systems R&D Ltd. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms and conditions of the GNU General Public License, + * version 2, as published by the Free Software Foundation. + */ +#ifndef __PV_H + +#include "analyze.h" +#include "trace.h" + +#ifdef __cplusplus +extern "C" { +#endif + +#define ARG_MISSING 0x0 +#define ARG_32BIT 0x1 +#define ARG_64BIT 0x2 + +#define MMU_UPDATE_PREEMPTED (~(~0U>>1)) + +static inline uint32_t pv_hypercall_op(const struct record_info *ri) +{ + return ri->d[0] & ~TRC_PV_HYPERCALL_V2_ARG_MASK; +} + +static inline int pv_hypercall_arg_present(const struct record_info *ri, int arg) +{ + return (ri->d[0] >> (20 + 2*arg)) & 0x3; +} + +void pv_hypercall_gather_args(const struct record_info *ri, uint64_t *args); + +#ifdef __cplusplus +} /* extern "C" */ +#endif + +#endif diff --git a/xenalyze.c b/xenalyze.c --- a/xenalyze.c +++ b/xenalyze.c @@ -32,6 +32,7 @@ #include "trace.h" #include "analyze.h" #include "mread.h" +#include "pv.h" #include #include #include @@ -1485,6 +1486,7 @@ enum { PV_GDT_LDT_MAPPING_FAULT, PV_PTWR_EMULATION, PV_PTWR_EMULATION_PAE, + PV_HYPERCALL_V2 = 13, PV_MAX }; @@ -1499,7 +1501,9 @@ char *pv_name[PV_MAX] = { [PV_PAGING_FIXUP]="paging fixup", [PV_GDT_LDT_MAPPING_FAULT]="gdt/ldt mapping fault", [PV_PTWR_EMULATION]="ptwr", - [PV_PTWR_EMULATION_PAE]="ptwr(pae)" + [PV_PTWR_EMULATION_PAE]="ptwr(pae)", + [PV_HYPERCALL_V2]="hypercall", + [PV_HYPERCALL_SUBCALL]="hypercall (subcall)", }; #define PV_HYPERCALL_MAX 56 @@ -6500,10 +6504,20 @@ void pv_summary(struct pv_data *pv) { printf("PV events:\n"); for(i=0; icount[i]) - printf(" %s %d\n", pv_name[i], pv->count[i]); + int count; + + count = pv->count[i]; + if (i == PV_HYPERCALL_V2) + count += pv->count[PV_HYPERCALL_SUBCALL]; + + if (count == 0) + continue; + + printf(" %s %d\n", pv_name[i], count); + switch(i) { case PV_HYPERCALL: + case PV_HYPERCALL_V2: for(j=0; jhypercall_count[j]) printf(" %-29s[%2d]: %6d\n", @@ -6523,6 +6537,145 @@ void pv_summary(struct pv_data *pv) { } } +static const char *grant_table_op_str[] = { + "map_grant_ref", "unmap_grant_ref", "setup_table", "dump_table", + "transfer", "copy", "query_size", "unmap_and_replace", + "set_version", "get_status_frames", "get_version", "swap_grant_ref", +}; + +static const char *vcpu_op_str[] = { + "initialise", "up", "down", "is_up", "get_runstate_info", + "register_runstate_memory_area", "set_periodic_timer", + "stop_periodic_timer", "set_singleshot_timer", "stop_singleshot_timer", + "register_vcpu_info", "send_nmi", "get_physid", + "register_vcpu_time_memory_area", +}; + +static const char *sched_op_str[] = { + "yield", "block", "shutdown", "poll", "remote_shutdown", "shutdown_code", + "watchdog", +}; + +static const char *cmd_to_str(const char *strings[], size_t n, uint32_t cmd) +{ + static char buf[32]; + + if (cmd < n) + return strings[cmd]; + + snprintf(buf, sizeof(buf), "unknown (%d)", cmd); + return buf; +} + +#define CMD_TO_STR(op) \ + static const char * op ## _to_str(uint32_t cmd) { \ + return cmd_to_str(op ## _str, ARRAY_SIZE(op ## _str), cmd); \ + } + +CMD_TO_STR(grant_table_op); +CMD_TO_STR(vcpu_op); +CMD_TO_STR(sched_op); + +void pv_hypercall_gather_args(const struct record_info *ri, uint64_t *args) +{ + int i, word; + + /* Missing arguments are zeroed. */ + memset(args, 0, 6 * sizeof(uint64_t)); + + for (i = 0, word = 1; i < 6 && word < ri->extra_words; i++) { + int present = pv_hypercall_arg_present(ri, i); + + switch (present) { + case ARG_32BIT: + args[i] = ri->d[word]; + break; + case ARG_64BIT: + args[i] = ((uint64_t)ri->d[word + 1] << 32) | ri->d[word]; + break; + } + + /* Skip over any words for this argument. */ + word += present; + } +} + +static void pv_hypercall_print_args(const struct record_info *ri) +{ + int i, word; + + for (i = 0, word = 1; i < 6 && word < ri->extra_words; i++) { + int present = pv_hypercall_arg_present(ri, i); + + switch (present) { + case ARG_MISSING: + printf(" ??"); + break; + case ARG_32BIT: + printf(" %08x", ri->d[word]); + break; + case ARG_64BIT: + printf(" %016"PRIu64"", ((uint64_t)ri->d[word + 1] << 32) | ri->d[word]); + break; + } + + word += present; + } +} + +void pv_hypercall_v2_process(struct record_info *ri, struct pv_data *pv) +{ + int op = pv_hypercall_op(ri); + + if(opt.summary_info) { + if(op < PV_HYPERCALL_MAX) + pv->hypercall_count[op]++; + } + + if(opt.dump_all) { + uint64_t args[6]; + + if(op < HYPERCALL_MAX) + printf(" %s hypercall %2x (%s)", + ri->dump_header, op, hypercall_name[op]); + else + printf(" %s hypercall %2x", + ri->dump_header, op); + + switch(op) { + case HYPERCALL_mmu_update: + pv_hypercall_gather_args(ri, args); + printf(" %d updates%s", (uint32_t)args[1] & ~MMU_UPDATE_PREEMPTED, + (args[1] & MMU_UPDATE_PREEMPTED) ? " (preempted)" : ""); + break; + case HYPERCALL_multicall: + pv_hypercall_gather_args(ri, args); + printf(" %d calls", (uint32_t)args[1]); + break; + case HYPERCALL_grant_table_op: + pv_hypercall_gather_args(ri, args); + printf(" %s %d ops", grant_table_op_to_str(args[0]), (uint32_t)args[2]); + break; + case HYPERCALL_vcpu_op: + pv_hypercall_gather_args(ri, args); + printf(" %s vcpu %d", vcpu_op_to_str(args[0]), (uint32_t)args[1]); + break; + case HYPERCALL_mmuext_op: + pv_hypercall_gather_args(ri, args); + printf(" %d ops", (uint32_t)args[1]); + break; + case HYPERCALL_sched_op: + pv_hypercall_gather_args(ri, args); + printf(" %s", sched_op_to_str(args[0])); + break; + default: + pv_hypercall_print_args(ri); + break; + } + printf("\n"); + } +} + void pv_process(struct pcpu_info *p) { struct record_info *ri = &p->ri; @@ -6555,9 +6708,9 @@ void pv_process(struct pcpu_info *p) case PV_PTWR_EMULATION_PAE: pv_ptwr_emulation_process(ri, pv); break; - case PV_PAGE_FAULT: - //pv_pf_process(ri, pv); - //break; + case PV_HYPERCALL_V2: + pv_hypercall_v2_process(ri, pv); + break; default: pv_generic_process(ri, pv); break; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 12:30:44 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 12:30:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJkZT-0003nG-MT; Thu, 04 Oct 2012 12:30:31 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJkZR-0003mZ-J3 for xen-devel@lists.xen.org; Thu, 04 Oct 2012 12:30:29 +0000 Received: from [85.158.139.211:7876] by server-13.bemta-5.messagelabs.com id D1/DD-16359-5618D605; Thu, 04 Oct 2012 12:30:29 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-2.tower-206.messagelabs.com!1349353823!21048466!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQyMDg=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28375 invoked from network); 4 Oct 2012 12:30:25 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 12:30:25 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="40124777" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 12:30:22 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 08:30:21 -0400 Received: from qabil.uk.xensource.com ([10.80.2.76]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJkZJ-000843-Pa; Thu, 04 Oct 2012 13:30:21 +0100 MIME-Version: 1.0 X-Mercurial-Node: b595d8dacf35c84765fff11c97cacfcd1b07afb1 Message-ID: In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Thu, 4 Oct 2012 13:28:41 +0100 From: David Vrabel To: xen-devel@lists.xen.org Cc: David Vrabel , George Dunlap Subject: [Xen-devel] [PATCH 1 of 2] xenalyze: decode PV_HYPERCALL_V2 records X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Newer version of Xen produce TRC_PV_HYPERCALL_V2 records instead of the older TRC_PV_HYPERCALL format. This updated format doesn't included the IP but it does include select hypercall arguments. Signed-off-by: David Vrabel diff --git a/analyze.h b/analyze.h --- a/analyze.h +++ b/analyze.h @@ -3,6 +3,8 @@ #include +#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0])) + #define TRC_GEN_MAIN 0 #define TRC_SCHED_MAIN 1 #define TRC_DOM0OP_MAIN 2 diff --git a/pv.h b/pv.h new file mode 100644 --- /dev/null +++ b/pv.h @@ -0,0 +1,41 @@ +/* + * PV event decoding. + * + * Copyright (C) 2012 Citrix Systems R&D Ltd. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms and conditions of the GNU General Public License, + * version 2, as published by the Free Software Foundation. + */ +#ifndef __PV_H + +#include "analyze.h" +#include "trace.h" + +#ifdef __cplusplus +extern "C" { +#endif + +#define ARG_MISSING 0x0 +#define ARG_32BIT 0x1 +#define ARG_64BIT 0x2 + +#define MMU_UPDATE_PREEMPTED (~(~0U>>1)) + +static inline uint32_t pv_hypercall_op(const struct record_info *ri) +{ + return ri->d[0] & ~TRC_PV_HYPERCALL_V2_ARG_MASK; +} + +static inline int pv_hypercall_arg_present(const struct record_info *ri, int arg) +{ + return (ri->d[0] >> (20 + 2*arg)) & 0x3; +} + +void pv_hypercall_gather_args(const struct record_info *ri, uint64_t *args); + +#ifdef __cplusplus +} /* extern "C" */ +#endif + +#endif diff --git a/xenalyze.c b/xenalyze.c --- a/xenalyze.c +++ b/xenalyze.c @@ -32,6 +32,7 @@ #include "trace.h" #include "analyze.h" #include "mread.h" +#include "pv.h" #include #include #include @@ -1485,6 +1486,7 @@ enum { PV_GDT_LDT_MAPPING_FAULT, PV_PTWR_EMULATION, PV_PTWR_EMULATION_PAE, + PV_HYPERCALL_V2 = 13, PV_MAX }; @@ -1499,7 +1501,9 @@ char *pv_name[PV_MAX] = { [PV_PAGING_FIXUP]="paging fixup", [PV_GDT_LDT_MAPPING_FAULT]="gdt/ldt mapping fault", [PV_PTWR_EMULATION]="ptwr", - [PV_PTWR_EMULATION_PAE]="ptwr(pae)" + [PV_PTWR_EMULATION_PAE]="ptwr(pae)", + [PV_HYPERCALL_V2]="hypercall", + [PV_HYPERCALL_SUBCALL]="hypercall (subcall)", }; #define PV_HYPERCALL_MAX 56 @@ -6500,10 +6504,20 @@ void pv_summary(struct pv_data *pv) { printf("PV events:\n"); for(i=0; icount[i]) - printf(" %s %d\n", pv_name[i], pv->count[i]); + int count; + + count = pv->count[i]; + if (i == PV_HYPERCALL_V2) + count += pv->count[PV_HYPERCALL_SUBCALL]; + + if (count == 0) + continue; + + printf(" %s %d\n", pv_name[i], count); + switch(i) { case PV_HYPERCALL: + case PV_HYPERCALL_V2: for(j=0; jhypercall_count[j]) printf(" %-29s[%2d]: %6d\n", @@ -6523,6 +6537,145 @@ void pv_summary(struct pv_data *pv) { } } +static const char *grant_table_op_str[] = { + "map_grant_ref", "unmap_grant_ref", "setup_table", "dump_table", + "transfer", "copy", "query_size", "unmap_and_replace", + "set_version", "get_status_frames", "get_version", "swap_grant_ref", +}; + +static const char *vcpu_op_str[] = { + "initialise", "up", "down", "is_up", "get_runstate_info", + "register_runstate_memory_area", "set_periodic_timer", + "stop_periodic_timer", "set_singleshot_timer", "stop_singleshot_timer", + "register_vcpu_info", "send_nmi", "get_physid", + "register_vcpu_time_memory_area", +}; + +static const char *sched_op_str[] = { + "yield", "block", "shutdown", "poll", "remote_shutdown", "shutdown_code", + "watchdog", +}; + +static const char *cmd_to_str(const char *strings[], size_t n, uint32_t cmd) +{ + static char buf[32]; + + if (cmd < n) + return strings[cmd]; + + snprintf(buf, sizeof(buf), "unknown (%d)", cmd); + return buf; +} + +#define CMD_TO_STR(op) \ + static const char * op ## _to_str(uint32_t cmd) { \ + return cmd_to_str(op ## _str, ARRAY_SIZE(op ## _str), cmd); \ + } + +CMD_TO_STR(grant_table_op); +CMD_TO_STR(vcpu_op); +CMD_TO_STR(sched_op); + +void pv_hypercall_gather_args(const struct record_info *ri, uint64_t *args) +{ + int i, word; + + /* Missing arguments are zeroed. */ + memset(args, 0, 6 * sizeof(uint64_t)); + + for (i = 0, word = 1; i < 6 && word < ri->extra_words; i++) { + int present = pv_hypercall_arg_present(ri, i); + + switch (present) { + case ARG_32BIT: + args[i] = ri->d[word]; + break; + case ARG_64BIT: + args[i] = ((uint64_t)ri->d[word + 1] << 32) | ri->d[word]; + break; + } + + /* Skip over any words for this argument. */ + word += present; + } +} + +static void pv_hypercall_print_args(const struct record_info *ri) +{ + int i, word; + + for (i = 0, word = 1; i < 6 && word < ri->extra_words; i++) { + int present = pv_hypercall_arg_present(ri, i); + + switch (present) { + case ARG_MISSING: + printf(" ??"); + break; + case ARG_32BIT: + printf(" %08x", ri->d[word]); + break; + case ARG_64BIT: + printf(" %016"PRIu64"", ((uint64_t)ri->d[word + 1] << 32) | ri->d[word]); + break; + } + + word += present; + } +} + +void pv_hypercall_v2_process(struct record_info *ri, struct pv_data *pv) +{ + int op = pv_hypercall_op(ri); + + if(opt.summary_info) { + if(op < PV_HYPERCALL_MAX) + pv->hypercall_count[op]++; + } + + if(opt.dump_all) { + uint64_t args[6]; + + if(op < HYPERCALL_MAX) + printf(" %s hypercall %2x (%s)", + ri->dump_header, op, hypercall_name[op]); + else + printf(" %s hypercall %2x", + ri->dump_header, op); + + switch(op) { + case HYPERCALL_mmu_update: + pv_hypercall_gather_args(ri, args); + printf(" %d updates%s", (uint32_t)args[1] & ~MMU_UPDATE_PREEMPTED, + (args[1] & MMU_UPDATE_PREEMPTED) ? " (preempted)" : ""); + break; + case HYPERCALL_multicall: + pv_hypercall_gather_args(ri, args); + printf(" %d calls", (uint32_t)args[1]); + break; + case HYPERCALL_grant_table_op: + pv_hypercall_gather_args(ri, args); + printf(" %s %d ops", grant_table_op_to_str(args[0]), (uint32_t)args[2]); + break; + case HYPERCALL_vcpu_op: + pv_hypercall_gather_args(ri, args); + printf(" %s vcpu %d", vcpu_op_to_str(args[0]), (uint32_t)args[1]); + break; + case HYPERCALL_mmuext_op: + pv_hypercall_gather_args(ri, args); + printf(" %d ops", (uint32_t)args[1]); + break; + case HYPERCALL_sched_op: + pv_hypercall_gather_args(ri, args); + printf(" %s", sched_op_to_str(args[0])); + break; + default: + pv_hypercall_print_args(ri); + break; + } + printf("\n"); + } +} + void pv_process(struct pcpu_info *p) { struct record_info *ri = &p->ri; @@ -6555,9 +6708,9 @@ void pv_process(struct pcpu_info *p) case PV_PTWR_EMULATION_PAE: pv_ptwr_emulation_process(ri, pv); break; - case PV_PAGE_FAULT: - //pv_pf_process(ri, pv); - //break; + case PV_HYPERCALL_V2: + pv_hypercall_v2_process(ri, pv); + break; default: pv_generic_process(ri, pv); break; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 12:30:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 12:30:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJkZQ-0003ml-9b; Thu, 04 Oct 2012 12:30:28 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJkZO-0003mZ-HU for xen-devel@lists.xen.org; Thu, 04 Oct 2012 12:30:26 +0000 Received: from [85.158.139.83:58921] by server-13.bemta-5.messagelabs.com id BA/AD-16359-1618D605; Thu, 04 Oct 2012 12:30:25 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1349353822!31199717!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODAxODI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22866 invoked from network); 4 Oct 2012 12:30:24 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 12:30:24 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="210279030" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 12:30:22 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 08:30:21 -0400 Received: from qabil.uk.xensource.com ([10.80.2.76]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJkZJ-000843-Py; Thu, 04 Oct 2012 13:30:21 +0100 MIME-Version: 1.0 X-Mercurial-Node: 22e9d99d70441ff3ec92360b6539300a9e2fb0b4 Message-ID: <22e9d99d70441ff3ec92.1349353722@qabil.uk.xensource.com> In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Thu, 4 Oct 2012 13:28:42 +0100 From: David Vrabel To: xen-devel@lists.xen.org Cc: David Vrabel , George Dunlap Subject: [Xen-devel] [PATCH 2 of 2] xenalyze: decode PV_HYPERCALL_SUBCALL events X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Decode the PV_HYPERCALL_SUBCALL events which are used for calls within a multicall hypercall. They are indented so its easier to see which multicall they were part of. Signed-off-by: David Vrabel Acked-by: George Dunlap diff --git a/xenalyze.c b/xenalyze.c --- a/xenalyze.c +++ b/xenalyze.c @@ -1487,6 +1487,7 @@ enum { PV_PTWR_EMULATION, PV_PTWR_EMULATION_PAE, PV_HYPERCALL_V2 = 13, + PV_HYPERCALL_SUBCALL = 14, PV_MAX }; @@ -6623,7 +6624,8 @@ static void pv_hypercall_print_args(cons } } -void pv_hypercall_v2_process(struct record_info *ri, struct pv_data *pv) +void pv_hypercall_v2_process(struct record_info *ri, struct pv_data *pv, + const char *indent) { int op = pv_hypercall_op(ri); @@ -6636,11 +6638,11 @@ void pv_hypercall_v2_process(struct reco uint64_t args[6]; if(op < HYPERCALL_MAX) - printf(" %s hypercall %2x (%s)", - ri->dump_header, op, hypercall_name[op]); + printf(" %s%s hypercall %2x (%s)", + ri->dump_header, indent, op, hypercall_name[op]); else - printf(" %s hypercall %2x", - ri->dump_header, op); + printf(" %s%s hypercall %2x", + ri->dump_header, indent, op); switch(op) { case HYPERCALL_mmu_update: @@ -6709,7 +6711,10 @@ void pv_process(struct pcpu_info *p) pv_ptwr_emulation_process(ri, pv); break; case PV_HYPERCALL_V2: - pv_hypercall_v2_process(ri, pv); + pv_hypercall_v2_process(ri, pv, ""); + break; + case PV_HYPERCALL_SUBCALL: + pv_hypercall_v2_process(ri, pv, " "); break; default: pv_generic_process(ri, pv); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 12:30:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 12:30:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJkZQ-0003ml-9b; Thu, 04 Oct 2012 12:30:28 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJkZO-0003mZ-HU for xen-devel@lists.xen.org; Thu, 04 Oct 2012 12:30:26 +0000 Received: from [85.158.139.83:58921] by server-13.bemta-5.messagelabs.com id BA/AD-16359-1618D605; Thu, 04 Oct 2012 12:30:25 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1349353822!31199717!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODAxODI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22866 invoked from network); 4 Oct 2012 12:30:24 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 12:30:24 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="210279030" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 12:30:22 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 08:30:21 -0400 Received: from qabil.uk.xensource.com ([10.80.2.76]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJkZJ-000843-Py; Thu, 04 Oct 2012 13:30:21 +0100 MIME-Version: 1.0 X-Mercurial-Node: 22e9d99d70441ff3ec92360b6539300a9e2fb0b4 Message-ID: <22e9d99d70441ff3ec92.1349353722@qabil.uk.xensource.com> In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.6.4 Date: Thu, 4 Oct 2012 13:28:42 +0100 From: David Vrabel To: xen-devel@lists.xen.org Cc: David Vrabel , George Dunlap Subject: [Xen-devel] [PATCH 2 of 2] xenalyze: decode PV_HYPERCALL_SUBCALL events X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Decode the PV_HYPERCALL_SUBCALL events which are used for calls within a multicall hypercall. They are indented so its easier to see which multicall they were part of. Signed-off-by: David Vrabel Acked-by: George Dunlap diff --git a/xenalyze.c b/xenalyze.c --- a/xenalyze.c +++ b/xenalyze.c @@ -1487,6 +1487,7 @@ enum { PV_PTWR_EMULATION, PV_PTWR_EMULATION_PAE, PV_HYPERCALL_V2 = 13, + PV_HYPERCALL_SUBCALL = 14, PV_MAX }; @@ -6623,7 +6624,8 @@ static void pv_hypercall_print_args(cons } } -void pv_hypercall_v2_process(struct record_info *ri, struct pv_data *pv) +void pv_hypercall_v2_process(struct record_info *ri, struct pv_data *pv, + const char *indent) { int op = pv_hypercall_op(ri); @@ -6636,11 +6638,11 @@ void pv_hypercall_v2_process(struct reco uint64_t args[6]; if(op < HYPERCALL_MAX) - printf(" %s hypercall %2x (%s)", - ri->dump_header, op, hypercall_name[op]); + printf(" %s%s hypercall %2x (%s)", + ri->dump_header, indent, op, hypercall_name[op]); else - printf(" %s hypercall %2x", - ri->dump_header, op); + printf(" %s%s hypercall %2x", + ri->dump_header, indent, op); switch(op) { case HYPERCALL_mmu_update: @@ -6709,7 +6711,10 @@ void pv_process(struct pcpu_info *p) pv_ptwr_emulation_process(ri, pv); break; case PV_HYPERCALL_V2: - pv_hypercall_v2_process(ri, pv); + pv_hypercall_v2_process(ri, pv, ""); + break; + case PV_HYPERCALL_SUBCALL: + pv_hypercall_v2_process(ri, pv, " "); break; default: pv_generic_process(ri, pv); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 12:30:48 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 12:30:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJkZO-0003me-Tf; Thu, 04 Oct 2012 12:30:26 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJkZN-0003mU-Kf for xen-devel@lists.xen.org; Thu, 04 Oct 2012 12:30:25 +0000 Received: from [85.158.139.83:58833] by server-10.bemta-5.messagelabs.com id 59/59-16911-0618D605; Thu, 04 Oct 2012 12:30:24 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1349353822!31199717!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODAxODI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22817 invoked from network); 4 Oct 2012 12:30:24 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 12:30:24 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="210279029" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 12:30:22 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 08:30:21 -0400 Received: from qabil.uk.xensource.com ([10.80.2.76]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJkZJ-000843-PA; Thu, 04 Oct 2012 13:30:21 +0100 MIME-Version: 1.0 Message-ID: User-Agent: Mercurial-patchbomb/1.6.4 Date: Thu, 4 Oct 2012 13:28:40 +0100 From: David Vrabel To: xen-devel@lists.xen.org Cc: David Vrabel , George Dunlap Subject: [Xen-devel] [PATCH 0 of 2] xenalyze: decode new hypercall trace records (v2) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This series allows xenalyze to decode the new PV_HYPERCALL_V2 and PV_HYPERCALL_SUBCALL trace records being proposed for Xen 4.3. Changes since v1: - pv_hypercall_gather_args() instead of pv_hypercall_arg(). - Refactor *_cmd_to_str. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 12:30:48 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 12:30:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJkZO-0003me-Tf; Thu, 04 Oct 2012 12:30:26 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJkZN-0003mU-Kf for xen-devel@lists.xen.org; Thu, 04 Oct 2012 12:30:25 +0000 Received: from [85.158.139.83:58833] by server-10.bemta-5.messagelabs.com id 59/59-16911-0618D605; Thu, 04 Oct 2012 12:30:24 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1349353822!31199717!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODAxODI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22817 invoked from network); 4 Oct 2012 12:30:24 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 12:30:24 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="210279029" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 12:30:22 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 08:30:21 -0400 Received: from qabil.uk.xensource.com ([10.80.2.76]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJkZJ-000843-PA; Thu, 04 Oct 2012 13:30:21 +0100 MIME-Version: 1.0 Message-ID: User-Agent: Mercurial-patchbomb/1.6.4 Date: Thu, 4 Oct 2012 13:28:40 +0100 From: David Vrabel To: xen-devel@lists.xen.org Cc: David Vrabel , George Dunlap Subject: [Xen-devel] [PATCH 0 of 2] xenalyze: decode new hypercall trace records (v2) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This series allows xenalyze to decode the new PV_HYPERCALL_V2 and PV_HYPERCALL_SUBCALL trace records being proposed for Xen 4.3. Changes since v1: - pv_hypercall_gather_args() instead of pv_hypercall_arg(). - Refactor *_cmd_to_str. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 12:42:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 12:42:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJkkq-0004IF-2u; Thu, 04 Oct 2012 12:42:16 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJkko-0004IA-EX for xen-devel@lists.xen.org; Thu, 04 Oct 2012 12:42:14 +0000 Received: from [85.158.143.99:12468] by server-2.bemta-4.messagelabs.com id A6/41-06610-5248D605; Thu, 04 Oct 2012 12:42:13 +0000 X-Env-Sender: jean.guyader@gmail.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1349354530!32890428!1 X-Originating-IP: [209.85.220.173] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27535 invoked from network); 4 Oct 2012 12:42:11 -0000 Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com) (209.85.220.173) by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 12:42:11 -0000 Received: by mail-vc0-f173.google.com with SMTP id fl15so623049vcb.32 for ; Thu, 04 Oct 2012 05:42:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Q+gdI4NdGFCGf/qCIEAQNsCJYfwzOWWosrAoK/N+G0s=; b=wNdMNEOhji9kydQ8YpfhcHWXdQJVm+F+FEog/0hLkaAPem7okNDFBvIrjuq+tczRr7 IaKcaBO8qiASmIZn4tnnbFTsF5+6ykUMRlSeRZQWKHSIPiA9r4FKwHCoApkQeAcUOMeL Nuckc08pl5kiPOSJ2riaBwY5wOu3q1RzrrsfgEpSQxYl5dcSc+3o7KqdjpmSLJUmWei8 ZYVeJC9T5XgFZ4zBetORfaPL3Q2MoijOSElYP5TDN+0b5P41xB7R4rdI1+lnJJrgVRn/ dmnx0P2K5/fyMQJuMKvw0g/X+VsS8go+ON8+21yYiOe973hFpt7zSnhrwmf7vhY62Xll fPwg== Received: by 10.58.89.168 with SMTP id bp8mr3220228veb.20.1349354530330; Thu, 04 Oct 2012 05:42:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.234.5 with HTTP; Thu, 4 Oct 2012 05:41:50 -0700 (PDT) In-Reply-To: <506D98FE020000780009FA23@nat28.tlf.novell.com> References: <1348141322-28657-1-git-send-email-jean.guyader@citrix.com> <1348141322-28657-5-git-send-email-jean.guyader@citrix.com> <505B2636020000780009CAA6@nat28.tlf.novell.com> <506D98FE020000780009FA23@nat28.tlf.novell.com> From: Jean Guyader Date: Thu, 4 Oct 2012 13:41:50 +0100 Message-ID: To: Jan Beulich Cc: tim@xen.org, Jean Guyader , xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH 4/4] xen: Add V4V implementation X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 4 October 2012 13:11, Jan Beulich wrote: >>>> On 04.10.12 at 14:03, Jean Guyader wrote: >> On 20 September 2012 13:20, Jan Beulich wrote: >>>>>> On 20.09.12 at 13:42, Jean Guyader wrote: >>>>+ case V4VOP_register_ring: >>>>+ { >>>>+ XEN_GUEST_HANDLE(v4v_ring_t) ring_hnd = >>>>+ guest_handle_cast(arg1, v4v_ring_t); >>>>+ XEN_GUEST_HANDLE(xen_pfn_t) pfn_hnd = >>>>+ guest_handle_cast(arg2, xen_pfn_t); >>>>+ uint32_t npage = arg3; >>>>+ if ( unlikely(!guest_handle_okay(ring_hnd, 1)) ) >>>>+ goto out; >>>>+ if ( unlikely(!guest_handle_okay(pfn_hnd, npage)) ) >>>>+ goto out; >>> >>> Here and below - this isn't sufficient for compat guests, or else >>> you give them a way to point into the compat m2p table. >>> >> >> I'll probably switch to uint64_t for the v4v mfn list instead of using >> xen_pfn_t which >> are unsigned long. That way I can save the need for a compat wrapper. > > But that comment of yours doesn't address the problem I pointed > out. > >>>>+ if ( unlikely(!guest_handle_okay(addr_hnd, 1)) ) >>>>+ goto out; >>>>+ if ( copy_from_guest(&addr, addr_hnd, 1) ) >>>>+ goto out; >>> >>> The former is redundant with the latter. Also, if you already >>> used guest_handle_okay() on an array, you then can (and >>> should) use the cheaper __copy_{to,from}_guest() functions. >>> While looking at this, I also spotted at least on guest access >>> without error checking. Plus many guest accesses happen >>> with some sort of lock held - that'll cause problems when the >>> guest memory you're trying to access was paged out (quite >>> likely you would be able to point out other such cases, but >>> those likely predate paging, and hence are an oversight of >>> whoever introduced the paging code). >>> >> >> There are plenty of other place in Xen where we copy data from >> a guest with some sort of lock held. >> >> I understand that the new code should do it's best to make sure >> it works correctly with the Xen paging code. >> >> The best way to solve this might not be try to to avoid copying from >> guest memory under a lock. I've discussed this with Tim and maybe >> we could introduce a new copy_from_guest which is aware of the paging >> and returns a specific error, and then we could cleanly unlock everything >> and issue a continuation that will fixup the memory. > > That's certainly an alternative. > Another way (probably a easier way) would be to add a "mlock" mechanism. Some of the pages could be lock which mean that we know before hand that a copy_from_guest won't raise a paging error. In my case it would be ideal. I can comment it out in the register/unregister ring code, so when we have such mechanism in place the v4v code could be updated. Jean _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 12:42:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 12:42:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJkkq-0004IF-2u; Thu, 04 Oct 2012 12:42:16 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJkko-0004IA-EX for xen-devel@lists.xen.org; Thu, 04 Oct 2012 12:42:14 +0000 Received: from [85.158.143.99:12468] by server-2.bemta-4.messagelabs.com id A6/41-06610-5248D605; Thu, 04 Oct 2012 12:42:13 +0000 X-Env-Sender: jean.guyader@gmail.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1349354530!32890428!1 X-Originating-IP: [209.85.220.173] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27535 invoked from network); 4 Oct 2012 12:42:11 -0000 Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com) (209.85.220.173) by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 12:42:11 -0000 Received: by mail-vc0-f173.google.com with SMTP id fl15so623049vcb.32 for ; Thu, 04 Oct 2012 05:42:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Q+gdI4NdGFCGf/qCIEAQNsCJYfwzOWWosrAoK/N+G0s=; b=wNdMNEOhji9kydQ8YpfhcHWXdQJVm+F+FEog/0hLkaAPem7okNDFBvIrjuq+tczRr7 IaKcaBO8qiASmIZn4tnnbFTsF5+6ykUMRlSeRZQWKHSIPiA9r4FKwHCoApkQeAcUOMeL Nuckc08pl5kiPOSJ2riaBwY5wOu3q1RzrrsfgEpSQxYl5dcSc+3o7KqdjpmSLJUmWei8 ZYVeJC9T5XgFZ4zBetORfaPL3Q2MoijOSElYP5TDN+0b5P41xB7R4rdI1+lnJJrgVRn/ dmnx0P2K5/fyMQJuMKvw0g/X+VsS8go+ON8+21yYiOe973hFpt7zSnhrwmf7vhY62Xll fPwg== Received: by 10.58.89.168 with SMTP id bp8mr3220228veb.20.1349354530330; Thu, 04 Oct 2012 05:42:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.234.5 with HTTP; Thu, 4 Oct 2012 05:41:50 -0700 (PDT) In-Reply-To: <506D98FE020000780009FA23@nat28.tlf.novell.com> References: <1348141322-28657-1-git-send-email-jean.guyader@citrix.com> <1348141322-28657-5-git-send-email-jean.guyader@citrix.com> <505B2636020000780009CAA6@nat28.tlf.novell.com> <506D98FE020000780009FA23@nat28.tlf.novell.com> From: Jean Guyader Date: Thu, 4 Oct 2012 13:41:50 +0100 Message-ID: To: Jan Beulich Cc: tim@xen.org, Jean Guyader , xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH 4/4] xen: Add V4V implementation X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 4 October 2012 13:11, Jan Beulich wrote: >>>> On 04.10.12 at 14:03, Jean Guyader wrote: >> On 20 September 2012 13:20, Jan Beulich wrote: >>>>>> On 20.09.12 at 13:42, Jean Guyader wrote: >>>>+ case V4VOP_register_ring: >>>>+ { >>>>+ XEN_GUEST_HANDLE(v4v_ring_t) ring_hnd = >>>>+ guest_handle_cast(arg1, v4v_ring_t); >>>>+ XEN_GUEST_HANDLE(xen_pfn_t) pfn_hnd = >>>>+ guest_handle_cast(arg2, xen_pfn_t); >>>>+ uint32_t npage = arg3; >>>>+ if ( unlikely(!guest_handle_okay(ring_hnd, 1)) ) >>>>+ goto out; >>>>+ if ( unlikely(!guest_handle_okay(pfn_hnd, npage)) ) >>>>+ goto out; >>> >>> Here and below - this isn't sufficient for compat guests, or else >>> you give them a way to point into the compat m2p table. >>> >> >> I'll probably switch to uint64_t for the v4v mfn list instead of using >> xen_pfn_t which >> are unsigned long. That way I can save the need for a compat wrapper. > > But that comment of yours doesn't address the problem I pointed > out. > >>>>+ if ( unlikely(!guest_handle_okay(addr_hnd, 1)) ) >>>>+ goto out; >>>>+ if ( copy_from_guest(&addr, addr_hnd, 1) ) >>>>+ goto out; >>> >>> The former is redundant with the latter. Also, if you already >>> used guest_handle_okay() on an array, you then can (and >>> should) use the cheaper __copy_{to,from}_guest() functions. >>> While looking at this, I also spotted at least on guest access >>> without error checking. Plus many guest accesses happen >>> with some sort of lock held - that'll cause problems when the >>> guest memory you're trying to access was paged out (quite >>> likely you would be able to point out other such cases, but >>> those likely predate paging, and hence are an oversight of >>> whoever introduced the paging code). >>> >> >> There are plenty of other place in Xen where we copy data from >> a guest with some sort of lock held. >> >> I understand that the new code should do it's best to make sure >> it works correctly with the Xen paging code. >> >> The best way to solve this might not be try to to avoid copying from >> guest memory under a lock. I've discussed this with Tim and maybe >> we could introduce a new copy_from_guest which is aware of the paging >> and returns a specific error, and then we could cleanly unlock everything >> and issue a continuation that will fixup the memory. > > That's certainly an alternative. > Another way (probably a easier way) would be to add a "mlock" mechanism. Some of the pages could be lock which mean that we know before hand that a copy_from_guest won't raise a paging error. In my case it would be ideal. I can comment it out in the register/unregister ring code, so when we have such mechanism in place the v4v code could be updated. Jean _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 12:44:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 12:44:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJkmm-0004Ut-Ju; Thu, 04 Oct 2012 12:44:16 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJkml-0004UH-2f for Xen-devel@lists.xensource.com; Thu, 04 Oct 2012 12:44:15 +0000 Received: from [85.158.137.99:26577] by server-10.bemta-3.messagelabs.com id 0A/D6-02525-E948D605; Thu, 04 Oct 2012 12:44:14 +0000 X-Env-Sender: ketuzsezr@gmail.com X-Msg-Ref: server-2.tower-217.messagelabs.com!1349354651!20150828!1 X-Originating-IP: [209.85.160.43] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20775 invoked from network); 4 Oct 2012 12:44:13 -0000 Received: from mail-pb0-f43.google.com (HELO mail-pb0-f43.google.com) (209.85.160.43) by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 12:44:13 -0000 Received: by mail-pb0-f43.google.com with SMTP id jt11so650272pbb.30 for ; Thu, 04 Oct 2012 05:44:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=oF0NJOkoed0g1BaAv9zmGChzlIGpFASlHw+ks8kxEy8=; b=Io1Ig9Hwrn5KMp6mUrJYBRges4Wzw6jdtdmXOC9u4GeHWP9IW+7pcs7vh0Qm4fH30g t3DHddR2TPccwscJmUrIyZPXpuSmFsDRjKI7Jhh+qBHEqutocj7Pf/c3aglyc41Qzwhi mgC89+OZJ9kbYyIDd0ovcYLmHtOlAbzL3VZAO4PBocS4oI/VPemA77EgijfOD/zFp7JU unnzxZtf0fUvCT3N+7U22idzEN6QEqWZ3nsxu5K+t9iHBJK8Ew0GAV5tdjEyPLDeQasd dEoFVhpCGXOh4GIESK3PQs8o3L652HU1DNV3lzczSyD/1l7jMIXqg+Q8kNQGa4groi42 mTMA== MIME-Version: 1.0 Received: by 10.68.211.99 with SMTP id nb3mr21940285pbc.16.1349354650760; Thu, 04 Oct 2012 05:44:10 -0700 (PDT) Received: by 10.66.193.9 with HTTP; Thu, 4 Oct 2012 05:44:10 -0700 (PDT) In-Reply-To: <1349344840.650.239.camel@zakaz.uk.xensource.com> References: <20120921121511.30001c08@mantra.us.oracle.com> <1349344840.650.239.camel@zakaz.uk.xensource.com> Date: Thu, 4 Oct 2012 08:44:10 -0400 X-Google-Sender-Auth: bg3kgcELikOgxZHgFcC5VGLX18Y Message-ID: From: Konrad Rzeszutek Wilk To: Ian Campbell Cc: "Xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v1 1/8]: PVH basic and hader file changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, Oct 4, 2012 at 6:00 AM, Ian Campbell wrote: > On Fri, 2012-09-21 at 20:15 +0100, Mukesh Rathor wrote: >> @@ -234,4 +245,20 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_memory_map); >> * during a driver critical region. >> */ >> extern spinlock_t xen_reservation_lock; >> + >> +/* >> + * Unmaps the page appearing at a particular GPFN from the specified >> guest's >> + * pseudophysical address space. >> + * arg == addr of xen_remove_from_physmap_t. >> + */ >> +#define XENMEM_remove_from_physmap 15 >> +struct xen_remove_from_physmap { >> + /* Which domain to change the mapping for. */ >> + domid_t domid; >> + >> + /* GPFN of the current mapping of the page. */ >> + unsigned long gpfn; >> +}; >> +DEFINE_GUEST_HANDLE_STRUCT(xen_remove_from_physmap); > > I needed this fixup in a tree with both the ARM and PVH stuff: > > 8<------------------------------------ > > >From d56a302734180171855e0ee07571ac0cee69b3e5 Mon Sep 17 00:00:00 2001 > From: Ian Campbell > Date: Thu, 4 Oct 2012 10:45:52 +0100 > Subject: [PATCH] xen: use xen_pft_t in struct xen_remove_from_physmap > > 4a6c2b4 "PVH basic and hader file changes" and bd3f79b "xen: Introduce > xen_pfn_t for pfn and mfn types" passed like ships in the night. .. and at least they did not collide with each other :-) > > Signed-off-by: Ian Campbell > --- > include/xen/interface/memory.h | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h > index 6d74c47..d38bdc1 100644 > --- a/include/xen/interface/memory.h > +++ b/include/xen/interface/memory.h > @@ -258,7 +258,7 @@ struct xen_remove_from_physmap { > domid_t domid; > > /* GPFN of the current mapping of the page. */ > - unsigned long gpfn; > + xen_pfn_t gpfn; > }; > DEFINE_GUEST_HANDLE_STRUCT(xen_remove_from_physmap); > > -- > 1.7.2.5 > > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 12:44:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 12:44:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJkmm-0004Ut-Ju; Thu, 04 Oct 2012 12:44:16 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJkml-0004UH-2f for Xen-devel@lists.xensource.com; Thu, 04 Oct 2012 12:44:15 +0000 Received: from [85.158.137.99:26577] by server-10.bemta-3.messagelabs.com id 0A/D6-02525-E948D605; Thu, 04 Oct 2012 12:44:14 +0000 X-Env-Sender: ketuzsezr@gmail.com X-Msg-Ref: server-2.tower-217.messagelabs.com!1349354651!20150828!1 X-Originating-IP: [209.85.160.43] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20775 invoked from network); 4 Oct 2012 12:44:13 -0000 Received: from mail-pb0-f43.google.com (HELO mail-pb0-f43.google.com) (209.85.160.43) by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 12:44:13 -0000 Received: by mail-pb0-f43.google.com with SMTP id jt11so650272pbb.30 for ; Thu, 04 Oct 2012 05:44:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=oF0NJOkoed0g1BaAv9zmGChzlIGpFASlHw+ks8kxEy8=; b=Io1Ig9Hwrn5KMp6mUrJYBRges4Wzw6jdtdmXOC9u4GeHWP9IW+7pcs7vh0Qm4fH30g t3DHddR2TPccwscJmUrIyZPXpuSmFsDRjKI7Jhh+qBHEqutocj7Pf/c3aglyc41Qzwhi mgC89+OZJ9kbYyIDd0ovcYLmHtOlAbzL3VZAO4PBocS4oI/VPemA77EgijfOD/zFp7JU unnzxZtf0fUvCT3N+7U22idzEN6QEqWZ3nsxu5K+t9iHBJK8Ew0GAV5tdjEyPLDeQasd dEoFVhpCGXOh4GIESK3PQs8o3L652HU1DNV3lzczSyD/1l7jMIXqg+Q8kNQGa4groi42 mTMA== MIME-Version: 1.0 Received: by 10.68.211.99 with SMTP id nb3mr21940285pbc.16.1349354650760; Thu, 04 Oct 2012 05:44:10 -0700 (PDT) Received: by 10.66.193.9 with HTTP; Thu, 4 Oct 2012 05:44:10 -0700 (PDT) In-Reply-To: <1349344840.650.239.camel@zakaz.uk.xensource.com> References: <20120921121511.30001c08@mantra.us.oracle.com> <1349344840.650.239.camel@zakaz.uk.xensource.com> Date: Thu, 4 Oct 2012 08:44:10 -0400 X-Google-Sender-Auth: bg3kgcELikOgxZHgFcC5VGLX18Y Message-ID: From: Konrad Rzeszutek Wilk To: Ian Campbell Cc: "Xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v1 1/8]: PVH basic and hader file changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, Oct 4, 2012 at 6:00 AM, Ian Campbell wrote: > On Fri, 2012-09-21 at 20:15 +0100, Mukesh Rathor wrote: >> @@ -234,4 +245,20 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_memory_map); >> * during a driver critical region. >> */ >> extern spinlock_t xen_reservation_lock; >> + >> +/* >> + * Unmaps the page appearing at a particular GPFN from the specified >> guest's >> + * pseudophysical address space. >> + * arg == addr of xen_remove_from_physmap_t. >> + */ >> +#define XENMEM_remove_from_physmap 15 >> +struct xen_remove_from_physmap { >> + /* Which domain to change the mapping for. */ >> + domid_t domid; >> + >> + /* GPFN of the current mapping of the page. */ >> + unsigned long gpfn; >> +}; >> +DEFINE_GUEST_HANDLE_STRUCT(xen_remove_from_physmap); > > I needed this fixup in a tree with both the ARM and PVH stuff: > > 8<------------------------------------ > > >From d56a302734180171855e0ee07571ac0cee69b3e5 Mon Sep 17 00:00:00 2001 > From: Ian Campbell > Date: Thu, 4 Oct 2012 10:45:52 +0100 > Subject: [PATCH] xen: use xen_pft_t in struct xen_remove_from_physmap > > 4a6c2b4 "PVH basic and hader file changes" and bd3f79b "xen: Introduce > xen_pfn_t for pfn and mfn types" passed like ships in the night. .. and at least they did not collide with each other :-) > > Signed-off-by: Ian Campbell > --- > include/xen/interface/memory.h | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h > index 6d74c47..d38bdc1 100644 > --- a/include/xen/interface/memory.h > +++ b/include/xen/interface/memory.h > @@ -258,7 +258,7 @@ struct xen_remove_from_physmap { > domid_t domid; > > /* GPFN of the current mapping of the page. */ > - unsigned long gpfn; > + xen_pfn_t gpfn; > }; > DEFINE_GUEST_HANDLE_STRUCT(xen_remove_from_physmap); > > -- > 1.7.2.5 > > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 12:52:39 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 12:52:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJkue-0004jt-JH; Thu, 04 Oct 2012 12:52:24 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJkuc-0004jo-Th for Xen-devel@lists.xensource.com; Thu, 04 Oct 2012 12:52:23 +0000 X-Env-Sender: ketuzsezr@gmail.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1349355133!9724177!1 X-Originating-IP: [209.85.220.43] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27943 invoked from network); 4 Oct 2012 12:52:14 -0000 Received: from mail-pa0-f43.google.com (HELO mail-pa0-f43.google.com) (209.85.220.43) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 12:52:14 -0000 Received: by mail-pa0-f43.google.com with SMTP id fb1so556441pad.30 for ; Thu, 04 Oct 2012 05:52:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=VtL4RTsVIIx0ntieHtzvol4n1RxKaZK+6FKLjrQln4Y=; b=FU16uYaeH9rUYnf0UyKE8conJyqO/Mh+RIDWpAyFZLPEAAeHC5rfARWCU8yTojedb3 JzSy6Lc6RDRxguggFQH/UuhzeuhyyfHCu/Ljzx7zz49vKbIolwgwPR9MzXRTPpRc9+Wo tZ2arTzoE8G1u8Z1Sj7AJgO2qDLGjijbhdGNcdaoGNOfqiptJr9RApNg6komn1rv0UBd rGQ4X+PXTBResZy6KUykRYk7FWk/NO0MQzHhK2CSj9omHk2fohp64LewV9gG4p95Cyvz 4HH/WxdMiSkWHGHkZ1TlRhmJGobsDIVcvZRH+P3mH486QRsCcIT9pWQqTfF5vkUXZKuE JeVA== MIME-Version: 1.0 Received: by 10.68.200.72 with SMTP id jq8mr21583831pbc.38.1349355132823; Thu, 04 Oct 2012 05:52:12 -0700 (PDT) Received: by 10.66.193.9 with HTTP; Thu, 4 Oct 2012 05:52:12 -0700 (PDT) In-Reply-To: <1349338526.650.204.camel@zakaz.uk.xensource.com> References: <20120921121202.3163c379@mantra.us.oracle.com> <1348581263.11229.21.camel@zakaz.uk.xensource.com> <20121001142826.1ebf7b0f@mantra.us.oracle.com> <1349170528.650.18.camel@zakaz.uk.xensource.com> <20121003121122.0f20d5ed@mantra.us.oracle.com> <20121003203956.GA7526@phenom.dumpdata.com> <1349338526.650.204.camel@zakaz.uk.xensource.com> Date: Thu, 4 Oct 2012 08:52:12 -0400 X-Google-Sender-Auth: jQc4nmTlaLtBR0ki3X9rNJtZ3E0 Message-ID: From: Konrad Rzeszutek Wilk To: Ian Campbell Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 0/8]: PVH (PV guest with extensions) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, Oct 4, 2012 at 4:15 AM, Ian Campbell wrote: > On Wed, 2012-10-03 at 21:39 +0100, Konrad Rzeszutek Wilk wrote: >> > You Ok with XEN_ELFNOTE_GUEST_PVH, or should I call it >> > XEN_ELFNOTE_PV_EXTENSIONS. Please LMK. > > My intention was that you add XENFEAT_supervisor_mode_kernel et al. to > the existing XEN_ELFNOTE_FEATURES note rather than adding a whole new > note. I some how missed that this is what you were doing above. e.g. > what I meant was: > > in Kconfig: > config XEN_X86_PVH > bool "Support for running as a PVH guest (EXPERIMENTAL)" > depends X86_64 && <..etc..> && EXPERIMENTAL > help > This option enables support for running as a PVH > guest (PV guest using hardware extensions) under > a suitably capable hypervisor. > > This option is EXPERIMETNAL because the > hypervisor interfaces which it uses are not yet > considered stable therefore backwards and > forwards compatibility is not yet guaranteed. > > If unsure, say N. > > Adjust the depends to suit reality. > > I thought we had that second paragraph for ARM too, but it seems like I > was wrong, we should probably add it. > > then in xen-head.S (adjusted for features actually used by PVH): > #ifdef CONFIG_XEN_X86_PVH > #define FEATURES_PVH "XENFEAT_writable_descriptor_tables|" \ > "XENFEAT_auto_translated_physmap|" \ > "XENFEAT_supervisor_mode_kernel" \ > "XENFEAT_hvm_callback_vector" > #else > #define FEATURES_PVH /* Not supported */ > #endif > ... > ELFNOTE(Xen, XEN_ELFNOTE_FEATURES, .asciz "!writable_page_tables|pae_pgdir_above_4gb"FEATURES_PVH) As long as those new fields exists with the older hypervisors - that is OK. If you define new ones the old hypervisors (say Xen 4.1) will refuse booting the kernel. > ... > > I don't think we need to define a XENFEAT_pvh (or whatever it might be > called) since don't need it in the code so there's no need to define/use > it here. If/when we need something like that we can add it, or > preferably some more specific thing for the use case which crops up. > >> XEN_ELFNOTE_PVH_FEATURES ? >> >> That way you can fill it with different 'features' flags >> if need to. Say 1<<1 is basic, etc. > > I don't think we need a PVH specific ELF note which just replicates the > XENFEAT infrastructure at this stage, if we do come to that then it > would be better to give PVH its own leaf in the existing feature space > (e.g. starting at 1*32+0). > > Ian. > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 12:52:39 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 12:52:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJkue-0004jt-JH; Thu, 04 Oct 2012 12:52:24 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJkuc-0004jo-Th for Xen-devel@lists.xensource.com; Thu, 04 Oct 2012 12:52:23 +0000 X-Env-Sender: ketuzsezr@gmail.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1349355133!9724177!1 X-Originating-IP: [209.85.220.43] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27943 invoked from network); 4 Oct 2012 12:52:14 -0000 Received: from mail-pa0-f43.google.com (HELO mail-pa0-f43.google.com) (209.85.220.43) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 12:52:14 -0000 Received: by mail-pa0-f43.google.com with SMTP id fb1so556441pad.30 for ; Thu, 04 Oct 2012 05:52:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=VtL4RTsVIIx0ntieHtzvol4n1RxKaZK+6FKLjrQln4Y=; b=FU16uYaeH9rUYnf0UyKE8conJyqO/Mh+RIDWpAyFZLPEAAeHC5rfARWCU8yTojedb3 JzSy6Lc6RDRxguggFQH/UuhzeuhyyfHCu/Ljzx7zz49vKbIolwgwPR9MzXRTPpRc9+Wo tZ2arTzoE8G1u8Z1Sj7AJgO2qDLGjijbhdGNcdaoGNOfqiptJr9RApNg6komn1rv0UBd rGQ4X+PXTBResZy6KUykRYk7FWk/NO0MQzHhK2CSj9omHk2fohp64LewV9gG4p95Cyvz 4HH/WxdMiSkWHGHkZ1TlRhmJGobsDIVcvZRH+P3mH486QRsCcIT9pWQqTfF5vkUXZKuE JeVA== MIME-Version: 1.0 Received: by 10.68.200.72 with SMTP id jq8mr21583831pbc.38.1349355132823; Thu, 04 Oct 2012 05:52:12 -0700 (PDT) Received: by 10.66.193.9 with HTTP; Thu, 4 Oct 2012 05:52:12 -0700 (PDT) In-Reply-To: <1349338526.650.204.camel@zakaz.uk.xensource.com> References: <20120921121202.3163c379@mantra.us.oracle.com> <1348581263.11229.21.camel@zakaz.uk.xensource.com> <20121001142826.1ebf7b0f@mantra.us.oracle.com> <1349170528.650.18.camel@zakaz.uk.xensource.com> <20121003121122.0f20d5ed@mantra.us.oracle.com> <20121003203956.GA7526@phenom.dumpdata.com> <1349338526.650.204.camel@zakaz.uk.xensource.com> Date: Thu, 4 Oct 2012 08:52:12 -0400 X-Google-Sender-Auth: jQc4nmTlaLtBR0ki3X9rNJtZ3E0 Message-ID: From: Konrad Rzeszutek Wilk To: Ian Campbell Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 0/8]: PVH (PV guest with extensions) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, Oct 4, 2012 at 4:15 AM, Ian Campbell wrote: > On Wed, 2012-10-03 at 21:39 +0100, Konrad Rzeszutek Wilk wrote: >> > You Ok with XEN_ELFNOTE_GUEST_PVH, or should I call it >> > XEN_ELFNOTE_PV_EXTENSIONS. Please LMK. > > My intention was that you add XENFEAT_supervisor_mode_kernel et al. to > the existing XEN_ELFNOTE_FEATURES note rather than adding a whole new > note. I some how missed that this is what you were doing above. e.g. > what I meant was: > > in Kconfig: > config XEN_X86_PVH > bool "Support for running as a PVH guest (EXPERIMENTAL)" > depends X86_64 && <..etc..> && EXPERIMENTAL > help > This option enables support for running as a PVH > guest (PV guest using hardware extensions) under > a suitably capable hypervisor. > > This option is EXPERIMETNAL because the > hypervisor interfaces which it uses are not yet > considered stable therefore backwards and > forwards compatibility is not yet guaranteed. > > If unsure, say N. > > Adjust the depends to suit reality. > > I thought we had that second paragraph for ARM too, but it seems like I > was wrong, we should probably add it. > > then in xen-head.S (adjusted for features actually used by PVH): > #ifdef CONFIG_XEN_X86_PVH > #define FEATURES_PVH "XENFEAT_writable_descriptor_tables|" \ > "XENFEAT_auto_translated_physmap|" \ > "XENFEAT_supervisor_mode_kernel" \ > "XENFEAT_hvm_callback_vector" > #else > #define FEATURES_PVH /* Not supported */ > #endif > ... > ELFNOTE(Xen, XEN_ELFNOTE_FEATURES, .asciz "!writable_page_tables|pae_pgdir_above_4gb"FEATURES_PVH) As long as those new fields exists with the older hypervisors - that is OK. If you define new ones the old hypervisors (say Xen 4.1) will refuse booting the kernel. > ... > > I don't think we need to define a XENFEAT_pvh (or whatever it might be > called) since don't need it in the code so there's no need to define/use > it here. If/when we need something like that we can add it, or > preferably some more specific thing for the use case which crops up. > >> XEN_ELFNOTE_PVH_FEATURES ? >> >> That way you can fill it with different 'features' flags >> if need to. Say 1<<1 is basic, etc. > > I don't think we need a PVH specific ELF note which just replicates the > XENFEAT infrastructure at this stage, if we do come to that then it > would be better to give PVH its own leaf in the existing feature space > (e.g. starting at 1*32+0). > > Ian. > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 13:12:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 13:12:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJlDp-0005H6-W2; Thu, 04 Oct 2012 13:12:13 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJlDo-0005H0-QB for Xen-devel@lists.xensource.com; Thu, 04 Oct 2012 13:12:13 +0000 Received: from [85.158.138.51:44556] by server-15.bemta-3.messagelabs.com id 13/5A-18313-B2B8D605; Thu, 04 Oct 2012 13:12:11 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1349356331!25063444!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2714 invoked from network); 4 Oct 2012 13:12:11 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 13:12:11 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="14941664" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 13:12:08 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 14:12:08 +0100 Message-ID: <1349356326.866.23.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Konrad Rzeszutek Wilk Date: Thu, 4 Oct 2012 14:12:06 +0100 In-Reply-To: References: <20120921121202.3163c379@mantra.us.oracle.com> <1348581263.11229.21.camel@zakaz.uk.xensource.com> <20121001142826.1ebf7b0f@mantra.us.oracle.com> <1349170528.650.18.camel@zakaz.uk.xensource.com> <20121003121122.0f20d5ed@mantra.us.oracle.com> <20121003203956.GA7526@phenom.dumpdata.com> <1349338526.650.204.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 0/8]: PVH (PV guest with extensions) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-10-04 at 13:52 +0100, Konrad Rzeszutek Wilk wrote: > On Thu, Oct 4, 2012 at 4:15 AM, Ian Campbell wrote: > > On Wed, 2012-10-03 at 21:39 +0100, Konrad Rzeszutek Wilk wrote: > >> > You Ok with XEN_ELFNOTE_GUEST_PVH, or should I call it > >> > XEN_ELFNOTE_PV_EXTENSIONS. Please LMK. > > > > My intention was that you add XENFEAT_supervisor_mode_kernel et al. to > > the existing XEN_ELFNOTE_FEATURES note rather than adding a whole new > > note. I some how missed that this is what you were doing above. e.g. > > what I meant was: > > > > in Kconfig: > > config XEN_X86_PVH > > bool "Support for running as a PVH guest (EXPERIMENTAL)" > > depends X86_64 && <..etc..> && EXPERIMENTAL > > help > > This option enables support for running as a PVH > > guest (PV guest using hardware extensions) under > > a suitably capable hypervisor. > > > > This option is EXPERIMETNAL because the > > hypervisor interfaces which it uses are not yet > > considered stable therefore backwards and > > forwards compatibility is not yet guaranteed. > > > > If unsure, say N. > > > > Adjust the depends to suit reality. > > > > I thought we had that second paragraph for ARM too, but it seems like I > > was wrong, we should probably add it. > > > > then in xen-head.S (adjusted for features actually used by PVH): > > #ifdef CONFIG_XEN_X86_PVH > > #define FEATURES_PVH "XENFEAT_writable_descriptor_tables|" \ > > "XENFEAT_auto_translated_physmap|" \ > > "XENFEAT_supervisor_mode_kernel" \ > > "XENFEAT_hvm_callback_vector" > > #else > > #define FEATURES_PVH /* Not supported */ > > #endif > > ... > > ELFNOTE(Xen, XEN_ELFNOTE_FEATURES, .asciz "!writable_page_tables|pae_pgdir_above_4gb"FEATURES_PVH) > > As long as those new fields exists with the older hypervisors - that > is OK. If you define new > ones the old hypervisors (say Xen 4.1) will refuse booting the kernel. The note declares features which can be supported by this kernel but they are not mandatory unless you prefix them with a "!" so assuming you don't put a ! in an older hypervisor will boot the kernel just fine. It just won't enable PVH, which is what we want. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 13:12:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 13:12:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJlDp-0005H6-W2; Thu, 04 Oct 2012 13:12:13 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJlDo-0005H0-QB for Xen-devel@lists.xensource.com; Thu, 04 Oct 2012 13:12:13 +0000 Received: from [85.158.138.51:44556] by server-15.bemta-3.messagelabs.com id 13/5A-18313-B2B8D605; Thu, 04 Oct 2012 13:12:11 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1349356331!25063444!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2714 invoked from network); 4 Oct 2012 13:12:11 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 13:12:11 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="14941664" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 13:12:08 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 14:12:08 +0100 Message-ID: <1349356326.866.23.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Konrad Rzeszutek Wilk Date: Thu, 4 Oct 2012 14:12:06 +0100 In-Reply-To: References: <20120921121202.3163c379@mantra.us.oracle.com> <1348581263.11229.21.camel@zakaz.uk.xensource.com> <20121001142826.1ebf7b0f@mantra.us.oracle.com> <1349170528.650.18.camel@zakaz.uk.xensource.com> <20121003121122.0f20d5ed@mantra.us.oracle.com> <20121003203956.GA7526@phenom.dumpdata.com> <1349338526.650.204.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 0/8]: PVH (PV guest with extensions) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-10-04 at 13:52 +0100, Konrad Rzeszutek Wilk wrote: > On Thu, Oct 4, 2012 at 4:15 AM, Ian Campbell wrote: > > On Wed, 2012-10-03 at 21:39 +0100, Konrad Rzeszutek Wilk wrote: > >> > You Ok with XEN_ELFNOTE_GUEST_PVH, or should I call it > >> > XEN_ELFNOTE_PV_EXTENSIONS. Please LMK. > > > > My intention was that you add XENFEAT_supervisor_mode_kernel et al. to > > the existing XEN_ELFNOTE_FEATURES note rather than adding a whole new > > note. I some how missed that this is what you were doing above. e.g. > > what I meant was: > > > > in Kconfig: > > config XEN_X86_PVH > > bool "Support for running as a PVH guest (EXPERIMENTAL)" > > depends X86_64 && <..etc..> && EXPERIMENTAL > > help > > This option enables support for running as a PVH > > guest (PV guest using hardware extensions) under > > a suitably capable hypervisor. > > > > This option is EXPERIMETNAL because the > > hypervisor interfaces which it uses are not yet > > considered stable therefore backwards and > > forwards compatibility is not yet guaranteed. > > > > If unsure, say N. > > > > Adjust the depends to suit reality. > > > > I thought we had that second paragraph for ARM too, but it seems like I > > was wrong, we should probably add it. > > > > then in xen-head.S (adjusted for features actually used by PVH): > > #ifdef CONFIG_XEN_X86_PVH > > #define FEATURES_PVH "XENFEAT_writable_descriptor_tables|" \ > > "XENFEAT_auto_translated_physmap|" \ > > "XENFEAT_supervisor_mode_kernel" \ > > "XENFEAT_hvm_callback_vector" > > #else > > #define FEATURES_PVH /* Not supported */ > > #endif > > ... > > ELFNOTE(Xen, XEN_ELFNOTE_FEATURES, .asciz "!writable_page_tables|pae_pgdir_above_4gb"FEATURES_PVH) > > As long as those new fields exists with the older hypervisors - that > is OK. If you define new > ones the old hypervisors (say Xen 4.1) will refuse booting the kernel. The note declares features which can be supported by this kernel but they are not mandatory unless you prefix them with a "!" so assuming you don't put a ! in an older hypervisor will boot the kernel just fine. It just won't enable PVH, which is what we want. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 13:23:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 13:23:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJlOQ-0005Zl-C7; Thu, 04 Oct 2012 13:23:10 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJlOP-0005Za-0n for xen-devel@lists.xen.org; Thu, 04 Oct 2012 13:23:09 +0000 Received: from [85.158.143.35:44406] by server-3.bemta-4.messagelabs.com id 45/50-10986-CBD8D605; Thu, 04 Oct 2012 13:23:08 +0000 X-Env-Sender: andreslc@gridcentric.ca X-Msg-Ref: server-6.tower-21.messagelabs.com!1349356863!21031401!1 X-Originating-IP: [209.85.223.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28018 invoked from network); 4 Oct 2012 13:21:04 -0000 Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com) (209.85.223.173) by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 13:21:04 -0000 Received: by mail-ie0-f173.google.com with SMTP id 17so1207760iea.32 for ; Thu, 04 Oct 2012 06:21:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=ZyWix0fmRGJJ2Tx3Fc5kB0unubZos3qbjOrEXQg/rz8=; b=DVI9z39/iHz6UqO8ECt55WnOoTvRzCq/6m/TbqMZ8p8dmOjvmGQRjeqgoZelkSN9c6 sSTLj8LS18yAig812sDMXO/cd2bRElmiK9Ji3/r3ADy/1bqj7XowGpxOCiQqGZKueKPg Ozs6P1Ihy6/whZbJd5T4yxfkWewm2Zj1Z0BH2Eq0M30kCBcLrKme4fwC5zm8ZR1Z07dA pJVmCvEh0dNFEEdAo9XifjtJig7n6RJUEUJYlOnQ3ZjFLOpjLAikCS2+NqosDlvXyFnJ rJNO0aKW0tcZV1LnfoVjaOtwkdvskCf6OdxTb1+lDAayowx3fLigvK/vhevpc39j42wd VrsQ== Received: by 10.50.193.201 with SMTP id hq9mr5193968igc.51.1349356862934; Thu, 04 Oct 2012 06:21:02 -0700 (PDT) Received: from [192.168.3.238] ([206.223.182.18]) by mx.google.com with ESMTPS id i2sm13434399igl.8.2012.10.04.06.21.00 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Oct 2012 06:21:01 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) From: Andres Lagar-Cavilla In-Reply-To: <1349345864.650.247.camel@zakaz.uk.xensource.com> Date: Thu, 4 Oct 2012 09:20:58 -0400 Message-Id: <239799F4-AF29-494F-86D2-ADF45ACA8792@gridcentric.ca> References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> <20121002091017.GA95926@ocelot.phlegethon.org> <66cc0085-1216-40f7-8059-eaf615202c12@default> <20121002201624.GA98445@ocelot.phlegethon.org> <20121004100645.GC38243@ocelot.phlegethon.org> <1349345864.650.247.camel@zakaz.uk.xensource.com> To: Ian Campbell X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQlEVFdHLZOrpAiJczx8rjC9KUwdWae/Sn+6UE5mcstuTV57DKPdnGVCX/kRZT6JddZVIuLk Cc: Dan Magenheimer , "Keir \(Xen.org\)" , Konrad Wilk , George Dunlap , Kurt Hackel , Tim Deegan , Olaf Hering , "xen-devel@lists.xen.org" , George Shuklin , Dario Faggioli , Ian Jackson Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Oct 4, 2012, at 6:17 AM, Ian Campbell wrote: > On Thu, 2012-10-04 at 11:06 +0100, Tim Deegan wrote: >> but my question was really: what should xl do, in the presence of >> ballooning, sharing, paging and tmem, to >> - decide whether a VM can be started at all; >> - control those four systems to shuffle memory around; and Are we talking about a per-VM control, with one or more of those sub-systems colluding concurrently? Or are we talking about a global view, and how chunks of host memory get sub-allocated? Hopefully the latter... >> - resolve races sensibly to avoid small VMs deferring large ones. >> (AIUI, xl already has some logic to handle the case of balloon-to-fit.) >> >> The second of those three is the interesting one. It seems to me that >> if the tools can't force all other actors to give up memory (and not >> immediately take it back) then they can't guarantee to be able to start >> a new VM, even with the new reservation hypercalls. > > There was a bit of discussion in the spring about this sort of thing > (well, three of the four), which seems to have fallen a bit by the > wayside^W^W^W^W^W^Wbeen deferred until 4.3 (ahem) e.g. > http://lists.xen.org/archives/html/xen-devel/2012-03/msg01181.html > > I'm sure there was earlier discussion which led to that, but I can't > seem to see it in the archives right now, perhaps I'm not looking for > the right Subject. IIRC, we had a bit of that conversation during the Santa Clara hackathon. The idea was to devise a scheme so that libxl can be told who the "actor" will be for memory management, and then hand-off appropriately. Add xl bindings, suitable defaults, and an implementation of the "balloon actor" by libxl, and the end result is the ability to start domains with a memory target suitably managed by balloon, xenpaging, tmem, foo, according to the user's wish. With no need to know obscure knobs. To the extent that might be possible. Andres > > Olaf might have been intending to look into this (I can't quite remember > where we left it) > > Ian. > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 13:23:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 13:23:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJlOQ-0005Zl-C7; Thu, 04 Oct 2012 13:23:10 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJlOP-0005Za-0n for xen-devel@lists.xen.org; Thu, 04 Oct 2012 13:23:09 +0000 Received: from [85.158.143.35:44406] by server-3.bemta-4.messagelabs.com id 45/50-10986-CBD8D605; Thu, 04 Oct 2012 13:23:08 +0000 X-Env-Sender: andreslc@gridcentric.ca X-Msg-Ref: server-6.tower-21.messagelabs.com!1349356863!21031401!1 X-Originating-IP: [209.85.223.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28018 invoked from network); 4 Oct 2012 13:21:04 -0000 Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com) (209.85.223.173) by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 13:21:04 -0000 Received: by mail-ie0-f173.google.com with SMTP id 17so1207760iea.32 for ; Thu, 04 Oct 2012 06:21:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=ZyWix0fmRGJJ2Tx3Fc5kB0unubZos3qbjOrEXQg/rz8=; b=DVI9z39/iHz6UqO8ECt55WnOoTvRzCq/6m/TbqMZ8p8dmOjvmGQRjeqgoZelkSN9c6 sSTLj8LS18yAig812sDMXO/cd2bRElmiK9Ji3/r3ADy/1bqj7XowGpxOCiQqGZKueKPg Ozs6P1Ihy6/whZbJd5T4yxfkWewm2Zj1Z0BH2Eq0M30kCBcLrKme4fwC5zm8ZR1Z07dA pJVmCvEh0dNFEEdAo9XifjtJig7n6RJUEUJYlOnQ3ZjFLOpjLAikCS2+NqosDlvXyFnJ rJNO0aKW0tcZV1LnfoVjaOtwkdvskCf6OdxTb1+lDAayowx3fLigvK/vhevpc39j42wd VrsQ== Received: by 10.50.193.201 with SMTP id hq9mr5193968igc.51.1349356862934; Thu, 04 Oct 2012 06:21:02 -0700 (PDT) Received: from [192.168.3.238] ([206.223.182.18]) by mx.google.com with ESMTPS id i2sm13434399igl.8.2012.10.04.06.21.00 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Oct 2012 06:21:01 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) From: Andres Lagar-Cavilla In-Reply-To: <1349345864.650.247.camel@zakaz.uk.xensource.com> Date: Thu, 4 Oct 2012 09:20:58 -0400 Message-Id: <239799F4-AF29-494F-86D2-ADF45ACA8792@gridcentric.ca> References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> <20121002091017.GA95926@ocelot.phlegethon.org> <66cc0085-1216-40f7-8059-eaf615202c12@default> <20121002201624.GA98445@ocelot.phlegethon.org> <20121004100645.GC38243@ocelot.phlegethon.org> <1349345864.650.247.camel@zakaz.uk.xensource.com> To: Ian Campbell X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQlEVFdHLZOrpAiJczx8rjC9KUwdWae/Sn+6UE5mcstuTV57DKPdnGVCX/kRZT6JddZVIuLk Cc: Dan Magenheimer , "Keir \(Xen.org\)" , Konrad Wilk , George Dunlap , Kurt Hackel , Tim Deegan , Olaf Hering , "xen-devel@lists.xen.org" , George Shuklin , Dario Faggioli , Ian Jackson Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Oct 4, 2012, at 6:17 AM, Ian Campbell wrote: > On Thu, 2012-10-04 at 11:06 +0100, Tim Deegan wrote: >> but my question was really: what should xl do, in the presence of >> ballooning, sharing, paging and tmem, to >> - decide whether a VM can be started at all; >> - control those four systems to shuffle memory around; and Are we talking about a per-VM control, with one or more of those sub-systems colluding concurrently? Or are we talking about a global view, and how chunks of host memory get sub-allocated? Hopefully the latter... >> - resolve races sensibly to avoid small VMs deferring large ones. >> (AIUI, xl already has some logic to handle the case of balloon-to-fit.) >> >> The second of those three is the interesting one. It seems to me that >> if the tools can't force all other actors to give up memory (and not >> immediately take it back) then they can't guarantee to be able to start >> a new VM, even with the new reservation hypercalls. > > There was a bit of discussion in the spring about this sort of thing > (well, three of the four), which seems to have fallen a bit by the > wayside^W^W^W^W^W^Wbeen deferred until 4.3 (ahem) e.g. > http://lists.xen.org/archives/html/xen-devel/2012-03/msg01181.html > > I'm sure there was earlier discussion which led to that, but I can't > seem to see it in the archives right now, perhaps I'm not looking for > the right Subject. IIRC, we had a bit of that conversation during the Santa Clara hackathon. The idea was to devise a scheme so that libxl can be told who the "actor" will be for memory management, and then hand-off appropriately. Add xl bindings, suitable defaults, and an implementation of the "balloon actor" by libxl, and the end result is the ability to start domains with a memory target suitably managed by balloon, xenpaging, tmem, foo, according to the user's wish. With no need to know obscure knobs. To the extent that might be possible. Andres > > Olaf might have been intending to look into this (I can't quite remember > where we left it) > > Ian. > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 13:24:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 13:24:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJlPC-0005dN-Q2; Thu, 04 Oct 2012 13:23:58 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJlPB-0005d6-Li for xen-devel@lists.xen.org; Thu, 04 Oct 2012 13:23:57 +0000 Received: from [85.158.143.35:12754] by server-1.bemta-4.messagelabs.com id FA/12-05684-DED8D605; Thu, 04 Oct 2012 13:23:57 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-8.tower-21.messagelabs.com!1349357036!13895564!1 X-Originating-IP: [81.29.64.94] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32145 invoked from network); 4 Oct 2012 13:23:56 -0000 Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94) by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Oct 2012 13:23:56 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1TJlP9-000AZJ-3S; Thu, 04 Oct 2012 13:23:55 +0000 Date: Thu, 4 Oct 2012 14:23:55 +0100 From: Tim Deegan To: Christoph Egger Message-ID: <20121004132355.GF38243@ocelot.phlegethon.org> References: <505C733B.50205@amd.com> <20120927145356.GG8831@ocelot.phlegethon.org> <50699FA6.6070805@amd.com> <20121004103706.GD38243@ocelot.phlegethon.org> <506D7DBB.7000900@amd.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <506D7DBB.7000900@amd.com> User-Agent: Mutt/1.4.2.1i Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH] nestedsvm: fix paging mode X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org At 14:14 +0200 on 04 Oct (1349360091), Christoph Egger wrote: > On 10/04/12 12:37, Tim Deegan wrote: > > > At 15:50 +0200 on 01 Oct (1349106630), Christoph Egger wrote: > >> On 09/27/12 16:53, Tim Deegan wrote: > >> > >>> At 16:01 +0200 on 21 Sep (1348243291), Christoph Egger wrote: > >>>> > >>>> On VMRUN and VMEXIT emulation update the paging mode > >>>> for Shadow-on-Nested. This allows Xen to walk the > >>>> l1 hypervisors shadow page table correctly. > >>>> Problem found with 64bit Win7 and 32bit XPMode where > >>>> Win7 switches forth and back between long mode and > >>>> PAE legacy pagetables. > >>>> > >>>> Signed-off-by: Christoph Egger > >>> > >>> Don't you have to do this in other cases as well? I think that > >>> shadow-on-shadow might need it, at least. > >> > >> It is needed for all cases where the l1 guest does shadow paging. > >> This includes: Shadow-on-Nested and Shadow-on-Shadow. > > > > I've looked more closely at this and now I'm more confused. :) > > > > Hap-on-hap seems to be OK without it because the special case in > > paging_gva_to_gfn() does the right thing, using the nestedmode's pt > > walker. > > > > Why is that not good enough for shadow-on-hap? Is there another path > > that does unguarded pt walks? If so: > > - why is that path not a problem for hap-on-hap; and > > - shouldn't that be handled the same way, i.e. either handle everything > > at lookup time, like paging_gva_to_gfn() does, or handle everything > > by switching modes at VMRUN/EXIT? > > > If the l1 guest does not do nested paging then Xen doesn't use the > nestedmode's pt walker. Ah, I was led astray by the nestedhvm_is_n2() check. It turns out that: nestedhvm_is_n2() returns 0 for guests that are in n2 but aren't hap-on-hap. That's pretty confusing, and I encourage you to change it. Anyway, I've checked in a modified version of your patch, as http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/a9c84069c248 Please check that it still does what you wanted. :) Cheers, Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 13:24:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 13:24:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJlPC-0005dN-Q2; Thu, 04 Oct 2012 13:23:58 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJlPB-0005d6-Li for xen-devel@lists.xen.org; Thu, 04 Oct 2012 13:23:57 +0000 Received: from [85.158.143.35:12754] by server-1.bemta-4.messagelabs.com id FA/12-05684-DED8D605; Thu, 04 Oct 2012 13:23:57 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-8.tower-21.messagelabs.com!1349357036!13895564!1 X-Originating-IP: [81.29.64.94] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32145 invoked from network); 4 Oct 2012 13:23:56 -0000 Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94) by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Oct 2012 13:23:56 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1TJlP9-000AZJ-3S; Thu, 04 Oct 2012 13:23:55 +0000 Date: Thu, 4 Oct 2012 14:23:55 +0100 From: Tim Deegan To: Christoph Egger Message-ID: <20121004132355.GF38243@ocelot.phlegethon.org> References: <505C733B.50205@amd.com> <20120927145356.GG8831@ocelot.phlegethon.org> <50699FA6.6070805@amd.com> <20121004103706.GD38243@ocelot.phlegethon.org> <506D7DBB.7000900@amd.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <506D7DBB.7000900@amd.com> User-Agent: Mutt/1.4.2.1i Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH] nestedsvm: fix paging mode X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org At 14:14 +0200 on 04 Oct (1349360091), Christoph Egger wrote: > On 10/04/12 12:37, Tim Deegan wrote: > > > At 15:50 +0200 on 01 Oct (1349106630), Christoph Egger wrote: > >> On 09/27/12 16:53, Tim Deegan wrote: > >> > >>> At 16:01 +0200 on 21 Sep (1348243291), Christoph Egger wrote: > >>>> > >>>> On VMRUN and VMEXIT emulation update the paging mode > >>>> for Shadow-on-Nested. This allows Xen to walk the > >>>> l1 hypervisors shadow page table correctly. > >>>> Problem found with 64bit Win7 and 32bit XPMode where > >>>> Win7 switches forth and back between long mode and > >>>> PAE legacy pagetables. > >>>> > >>>> Signed-off-by: Christoph Egger > >>> > >>> Don't you have to do this in other cases as well? I think that > >>> shadow-on-shadow might need it, at least. > >> > >> It is needed for all cases where the l1 guest does shadow paging. > >> This includes: Shadow-on-Nested and Shadow-on-Shadow. > > > > I've looked more closely at this and now I'm more confused. :) > > > > Hap-on-hap seems to be OK without it because the special case in > > paging_gva_to_gfn() does the right thing, using the nestedmode's pt > > walker. > > > > Why is that not good enough for shadow-on-hap? Is there another path > > that does unguarded pt walks? If so: > > - why is that path not a problem for hap-on-hap; and > > - shouldn't that be handled the same way, i.e. either handle everything > > at lookup time, like paging_gva_to_gfn() does, or handle everything > > by switching modes at VMRUN/EXIT? > > > If the l1 guest does not do nested paging then Xen doesn't use the > nestedmode's pt walker. Ah, I was led astray by the nestedhvm_is_n2() check. It turns out that: nestedhvm_is_n2() returns 0 for guests that are in n2 but aren't hap-on-hap. That's pretty confusing, and I encourage you to change it. Anyway, I've checked in a modified version of your patch, as http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/a9c84069c248 Please check that it still does what you wanted. :) Cheers, Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 13:25:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 13:25:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJlQJ-0005kr-Dp; Thu, 04 Oct 2012 13:25:07 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJlQH-0005kc-OC for xen-devel@lists.xen.org; Thu, 04 Oct 2012 13:25:05 +0000 Received: from [85.158.139.83:34797] by server-3.bemta-5.messagelabs.com id BE/83-16108-03E8D605; Thu, 04 Oct 2012 13:25:04 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1349357103!32746065!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 889 invoked from network); 4 Oct 2012 13:25:04 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 13:25:04 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="14942033" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 13:25:03 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 14:25:03 +0100 Message-ID: <1349357102.866.32.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Andres Lagar-Cavilla Date: Thu, 4 Oct 2012 14:25:02 +0100 In-Reply-To: <239799F4-AF29-494F-86D2-ADF45ACA8792@gridcentric.ca> References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> <20121002091017.GA95926@ocelot.phlegethon.org> <66cc0085-1216-40f7-8059-eaf615202c12@default> <20121002201624.GA98445@ocelot.phlegethon.org> <20121004100645.GC38243@ocelot.phlegethon.org> <1349345864.650.247.camel@zakaz.uk.xensource.com> <239799F4-AF29-494F-86D2-ADF45ACA8792@gridcentric.ca> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: Dan Magenheimer , "Keir \(Xen.org\)" , Konrad Wilk , George Dunlap , Kurt Hackel , "Tim \(Xen.org\)" , Olaf Hering , "xen-devel@lists.xen.org" , George Shuklin , Dario Faggioli , Ian Jackson Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-10-04 at 14:20 +0100, Andres Lagar-Cavilla wrote: > On Oct 4, 2012, at 6:17 AM, Ian Campbell wrote: > > > On Thu, 2012-10-04 at 11:06 +0100, Tim Deegan wrote: > >> but my question was really: what should xl do, in the presence of > >> ballooning, sharing, paging and tmem, to > >> - decide whether a VM can be started at all; > >> - control those four systems to shuffle memory around; and > > Are we talking about a per-VM control, with one or more of those sub-systems colluding concurrently? Or are we talking about a global view, and how chunks of host memory get sub-allocated? Hopefully the latter... > > >> - resolve races sensibly to avoid small VMs deferring large ones. > >> (AIUI, xl already has some logic to handle the case of balloon-to-fit.) > >> > >> The second of those three is the interesting one. It seems to me that > >> if the tools can't force all other actors to give up memory (and not > >> immediately take it back) then they can't guarantee to be able to start > >> a new VM, even with the new reservation hypercalls. > > > > There was a bit of discussion in the spring about this sort of thing > > (well, three of the four), which seems to have fallen a bit by the > > wayside^W^W^W^W^W^Wbeen deferred until 4.3 (ahem) e.g. > > http://lists.xen.org/archives/html/xen-devel/2012-03/msg01181.html > > > > I'm sure there was earlier discussion which led to that, but I can't > > seem to see it in the archives right now, perhaps I'm not looking for > > the right Subject. > > IIRC, we had a bit of that conversation during the Santa Clara > hackathon. The idea was to devise a scheme so that libxl can be told > who the "actor" will be for memory management, and then hand-off > appropriately. Add xl bindings, suitable defaults, and an > implementation of the "balloon actor" by libxl, and the end result is > the ability to start domains with a memory target suitably managed by > balloon, xenpaging, tmem, foo, according to the user's wish. With no > need to know obscure knobs. To the extent that might be possible. That's right, I'd forgotten about that conversation. Yet some how the mail I referenced seems to be a result of that conversation -- which is a nice coincidence ;-) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 13:25:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 13:25:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJlQJ-0005kr-Dp; Thu, 04 Oct 2012 13:25:07 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJlQH-0005kc-OC for xen-devel@lists.xen.org; Thu, 04 Oct 2012 13:25:05 +0000 Received: from [85.158.139.83:34797] by server-3.bemta-5.messagelabs.com id BE/83-16108-03E8D605; Thu, 04 Oct 2012 13:25:04 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1349357103!32746065!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 889 invoked from network); 4 Oct 2012 13:25:04 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 13:25:04 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="14942033" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 13:25:03 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 14:25:03 +0100 Message-ID: <1349357102.866.32.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Andres Lagar-Cavilla Date: Thu, 4 Oct 2012 14:25:02 +0100 In-Reply-To: <239799F4-AF29-494F-86D2-ADF45ACA8792@gridcentric.ca> References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> <20121002091017.GA95926@ocelot.phlegethon.org> <66cc0085-1216-40f7-8059-eaf615202c12@default> <20121002201624.GA98445@ocelot.phlegethon.org> <20121004100645.GC38243@ocelot.phlegethon.org> <1349345864.650.247.camel@zakaz.uk.xensource.com> <239799F4-AF29-494F-86D2-ADF45ACA8792@gridcentric.ca> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: Dan Magenheimer , "Keir \(Xen.org\)" , Konrad Wilk , George Dunlap , Kurt Hackel , "Tim \(Xen.org\)" , Olaf Hering , "xen-devel@lists.xen.org" , George Shuklin , Dario Faggioli , Ian Jackson Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-10-04 at 14:20 +0100, Andres Lagar-Cavilla wrote: > On Oct 4, 2012, at 6:17 AM, Ian Campbell wrote: > > > On Thu, 2012-10-04 at 11:06 +0100, Tim Deegan wrote: > >> but my question was really: what should xl do, in the presence of > >> ballooning, sharing, paging and tmem, to > >> - decide whether a VM can be started at all; > >> - control those four systems to shuffle memory around; and > > Are we talking about a per-VM control, with one or more of those sub-systems colluding concurrently? Or are we talking about a global view, and how chunks of host memory get sub-allocated? Hopefully the latter... > > >> - resolve races sensibly to avoid small VMs deferring large ones. > >> (AIUI, xl already has some logic to handle the case of balloon-to-fit.) > >> > >> The second of those three is the interesting one. It seems to me that > >> if the tools can't force all other actors to give up memory (and not > >> immediately take it back) then they can't guarantee to be able to start > >> a new VM, even with the new reservation hypercalls. > > > > There was a bit of discussion in the spring about this sort of thing > > (well, three of the four), which seems to have fallen a bit by the > > wayside^W^W^W^W^W^Wbeen deferred until 4.3 (ahem) e.g. > > http://lists.xen.org/archives/html/xen-devel/2012-03/msg01181.html > > > > I'm sure there was earlier discussion which led to that, but I can't > > seem to see it in the archives right now, perhaps I'm not looking for > > the right Subject. > > IIRC, we had a bit of that conversation during the Santa Clara > hackathon. The idea was to devise a scheme so that libxl can be told > who the "actor" will be for memory management, and then hand-off > appropriately. Add xl bindings, suitable defaults, and an > implementation of the "balloon actor" by libxl, and the end result is > the ability to start domains with a memory target suitably managed by > balloon, xenpaging, tmem, foo, according to the user's wish. With no > need to know obscure knobs. To the extent that might be possible. That's right, I'd forgotten about that conversation. Yet some how the mail I referenced seems to be a result of that conversation -- which is a nice coincidence ;-) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 13:34:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 13:34:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJlYg-00065A-Ej; Thu, 04 Oct 2012 13:33:46 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJlYe-000655-SG for xen-devel@lists.xen.org; Thu, 04 Oct 2012 13:33:45 +0000 Received: from [85.158.138.51:54236] by server-16.bemta-3.messagelabs.com id 48/01-09129-8309D605; Thu, 04 Oct 2012 13:33:44 +0000 X-Env-Sender: andreslc@gridcentric.ca X-Msg-Ref: server-12.tower-174.messagelabs.com!1349357621!25172584!1 X-Originating-IP: [209.85.223.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15936 invoked from network); 4 Oct 2012 13:33:43 -0000 Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com) (209.85.223.173) by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 13:33:43 -0000 Received: by mail-ie0-f173.google.com with SMTP id 17so1246897iea.32 for ; Thu, 04 Oct 2012 06:33:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=i3mlBeZduzT+M5sdFoJW6buW5So34NgFRnnsnqMjBNw=; b=YngWywf1BYJTuR+O1CqbfRlqlgh+EUaRXks3XwKGmXs1QuB4+wDtYV5HNvpaK1PxQd fUOq8XvMNlguKua0vt6xDiD72B0TRGwj9rp1TgmwDgZz3+n9cSIWmcUgnSUUr91TJSEX i8ncu69wqWnGEYmc4wwiWhGF28TWB5gDjJv363FGvZLV09T97k9Wr201gQWAOQGrUVXP qgN7IsYTSw6DihreKLIz6C9ffNSdwUSx5r45ABz5Y7ZhRhAKABA1Eithp/l/o5GzarpY bpmiO7yvjX0mExAGXj5sZihWQmYZ+lMMNGG9M7igovI9K1F4mbK2pHAwaDhLVGwiL7vF htyA== Received: by 10.50.106.133 with SMTP id gu5mr5330692igb.18.1349357621414; Thu, 04 Oct 2012 06:33:41 -0700 (PDT) Received: from [192.168.3.238] ([206.223.182.18]) by mx.google.com with ESMTPS id yf6sm5807916igb.0.2012.10.04.06.33.39 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Oct 2012 06:33:40 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) From: Andres Lagar-Cavilla In-Reply-To: <20121004100645.GC38243@ocelot.phlegethon.org> Date: Thu, 4 Oct 2012 09:33:38 -0400 Message-Id: <51CA094C-870A-4772-A22E-4CB151E854F2@gridcentric.ca> References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> <20121002091017.GA95926@ocelot.phlegethon.org> <66cc0085-1216-40f7-8059-eaf615202c12@default> <20121002201624.GA98445@ocelot.phlegethon.org> <20121004100645.GC38243@ocelot.phlegethon.org> To: Tim Deegan X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQkTnl2waoR6rrFwstrj+p+bsZPwK7f5GXeb22xe3/VL+xW5Y/i9u+KITwd6/hl2GpgnP101 Cc: Dan Magenheimer , Keir Fraser , Konrad Wilk , George Dunlap , Kurt Hackel , Ian Jackson , Olaf Hering , xen-devel@lists.xen.org, George Shuklin , Dario Faggioli Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Oct 4, 2012, at 6:06 AM, Tim Deegan wrote: > At 14:56 -0700 on 02 Oct (1349189817), Dan Magenheimer wrote: >>> AIUI xapi uses the domains' maximum allocations, centrally controlled, >>> to place an upper bound on the amount of guest memory that can be in >>> use. Within those limits there can be ballooning activity. But TBH I >>> don't know the details. >> >> Yes, that's the same as saying there is no memory-overcommit. > > I'd say there is - but it's all done by ballooning, and it's centrally > enforced by lowering each domain's maxmem to its balloon target, so a > badly behaved guest can't balloon up and confuse things. > >> The original problem occurs only if there are multiple threads >> of execution that can be simultaneously asking the hypervisor >> to allocate memory without the knowledge of a single centralized >> "controller". > > Absolutely. > >> Tmem argues that doing "memory capacity transfers" at a page granularity >> can only be done efficiently in the hypervisor. This is true for >> page-sharing when it breaks a "share" also... it can't go ask the >> toolstack to approve allocation of a new page every time a write to a shared >> page occurs. >> >> Does that make sense? > > Yes. The page-sharing version can be handled by having a pool of > dedicated memory for breaking shares, and the toolstack asynchronously > replenish that, rather than allowing CoW to use up all memory in the > system. That is doable. One benefit is that it would minimize the chance of a VM hitting a CoW ENOMEM. I don't see how it would altogether avoid it. If the objective is trying to put a cap to the unpredictable growth of memory allocations via CoW unsharing, two observations: (1) will never grow past nominal VM footprint (2) One can put a cap today by tweaking d->max_pages -- CoW will fail, faulting vcpu will sleep, and things can be kicked back into action at a later point. > >> (rough proposed design re-attached below) > > Thanks for that. It describes a sensible-looking hypervisor interface, > but my question was really: what should xl do, in the presence of > ballooning, sharing, paging and tmem, to > - decide whether a VM can be started at all; > - control those four systems to shuffle memory around; and > - resolve races sensibly to avoid small VMs deferring large ones. > (AIUI, xl already has some logic to handle the case of balloon-to-fit.) > > The second of those three is the interesting one. It seems to me that > if the tools can't force all other actors to give up memory (and not > immediately take it back) then they can't guarantee to be able to start > a new VM, even with the new reservation hypercalls. > > Cheers, > > Tim. > >>> From: Dan Magenheimer >>> Sent: Monday, October 01, 2012 2:04 PM >>> : >>> : >>> Back to design brainstorming: >>> >>> The way I am thinking about it, the tools need to be involved >>> to the extent that they would need to communicate to the >>> hypervisor the following facts (probably via new hypercall): >>> >>> X1) I am launching a domain X and it is eventually going to >>> consume up to a maximum of N MB. Please tell me if >>> there is sufficient RAM available AND, if so, reserve >>> it until I tell you I am done. ("AND" implies transactional >>> semantics) X1 does not need hypervisor support. We already coexist with a global daemon that is a single point of failure. I'm not arguing for xenstore to hold onto these reservations, but a daemon can. Xapi does it that way. Andres >>> X2) The launch of X is complete and I will not be requesting >>> the allocation of any more RAM for it. Please release >>> the reservation, whether or not I've requested a total >>> of N MB. >>> >>> The calls may be nested or partially ordered, i.e. >>> X1...Y1...Y2...X2 >>> X1...Y1...X2...Y2 >>> and the hypervisor must be able to deal with this. >>> >>> Then there would need to be two "versions" of "xm/xl free". >>> We can quibble about which should be the default, but >>> they would be: >>> >>> - "xl --reserved free" asks the hypervisor how much RAM >>> is available taking into account reservations >>> - "xm --raw free" asks the hypervisor for the instantaneous >>> amount of RAM unallocated, not counting reservations >>> >>> When the tools are not launching a domain (that is there >>> has been a matching X2 for all X1), the results of the >>> above "free" queries are always identical. >>> >>> So, IanJ, does this match up with the design you were thinking >>> about? >>> >>> Thanks, >>> Dan >>> >>> [1] I think the core culprits are (a) the hypervisor accounts for >>> memory allocation of pages strictly on a first-come-first-served >>> basis and (b) the tools don't have any form of need-this-much-memory >>> "transaction" model _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 13:34:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 13:34:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJlYg-00065A-Ej; Thu, 04 Oct 2012 13:33:46 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJlYe-000655-SG for xen-devel@lists.xen.org; Thu, 04 Oct 2012 13:33:45 +0000 Received: from [85.158.138.51:54236] by server-16.bemta-3.messagelabs.com id 48/01-09129-8309D605; Thu, 04 Oct 2012 13:33:44 +0000 X-Env-Sender: andreslc@gridcentric.ca X-Msg-Ref: server-12.tower-174.messagelabs.com!1349357621!25172584!1 X-Originating-IP: [209.85.223.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15936 invoked from network); 4 Oct 2012 13:33:43 -0000 Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com) (209.85.223.173) by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 13:33:43 -0000 Received: by mail-ie0-f173.google.com with SMTP id 17so1246897iea.32 for ; Thu, 04 Oct 2012 06:33:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=i3mlBeZduzT+M5sdFoJW6buW5So34NgFRnnsnqMjBNw=; b=YngWywf1BYJTuR+O1CqbfRlqlgh+EUaRXks3XwKGmXs1QuB4+wDtYV5HNvpaK1PxQd fUOq8XvMNlguKua0vt6xDiD72B0TRGwj9rp1TgmwDgZz3+n9cSIWmcUgnSUUr91TJSEX i8ncu69wqWnGEYmc4wwiWhGF28TWB5gDjJv363FGvZLV09T97k9Wr201gQWAOQGrUVXP qgN7IsYTSw6DihreKLIz6C9ffNSdwUSx5r45ABz5Y7ZhRhAKABA1Eithp/l/o5GzarpY bpmiO7yvjX0mExAGXj5sZihWQmYZ+lMMNGG9M7igovI9K1F4mbK2pHAwaDhLVGwiL7vF htyA== Received: by 10.50.106.133 with SMTP id gu5mr5330692igb.18.1349357621414; Thu, 04 Oct 2012 06:33:41 -0700 (PDT) Received: from [192.168.3.238] ([206.223.182.18]) by mx.google.com with ESMTPS id yf6sm5807916igb.0.2012.10.04.06.33.39 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Oct 2012 06:33:40 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) From: Andres Lagar-Cavilla In-Reply-To: <20121004100645.GC38243@ocelot.phlegethon.org> Date: Thu, 4 Oct 2012 09:33:38 -0400 Message-Id: <51CA094C-870A-4772-A22E-4CB151E854F2@gridcentric.ca> References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> <20121002091017.GA95926@ocelot.phlegethon.org> <66cc0085-1216-40f7-8059-eaf615202c12@default> <20121002201624.GA98445@ocelot.phlegethon.org> <20121004100645.GC38243@ocelot.phlegethon.org> To: Tim Deegan X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQkTnl2waoR6rrFwstrj+p+bsZPwK7f5GXeb22xe3/VL+xW5Y/i9u+KITwd6/hl2GpgnP101 Cc: Dan Magenheimer , Keir Fraser , Konrad Wilk , George Dunlap , Kurt Hackel , Ian Jackson , Olaf Hering , xen-devel@lists.xen.org, George Shuklin , Dario Faggioli Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Oct 4, 2012, at 6:06 AM, Tim Deegan wrote: > At 14:56 -0700 on 02 Oct (1349189817), Dan Magenheimer wrote: >>> AIUI xapi uses the domains' maximum allocations, centrally controlled, >>> to place an upper bound on the amount of guest memory that can be in >>> use. Within those limits there can be ballooning activity. But TBH I >>> don't know the details. >> >> Yes, that's the same as saying there is no memory-overcommit. > > I'd say there is - but it's all done by ballooning, and it's centrally > enforced by lowering each domain's maxmem to its balloon target, so a > badly behaved guest can't balloon up and confuse things. > >> The original problem occurs only if there are multiple threads >> of execution that can be simultaneously asking the hypervisor >> to allocate memory without the knowledge of a single centralized >> "controller". > > Absolutely. > >> Tmem argues that doing "memory capacity transfers" at a page granularity >> can only be done efficiently in the hypervisor. This is true for >> page-sharing when it breaks a "share" also... it can't go ask the >> toolstack to approve allocation of a new page every time a write to a shared >> page occurs. >> >> Does that make sense? > > Yes. The page-sharing version can be handled by having a pool of > dedicated memory for breaking shares, and the toolstack asynchronously > replenish that, rather than allowing CoW to use up all memory in the > system. That is doable. One benefit is that it would minimize the chance of a VM hitting a CoW ENOMEM. I don't see how it would altogether avoid it. If the objective is trying to put a cap to the unpredictable growth of memory allocations via CoW unsharing, two observations: (1) will never grow past nominal VM footprint (2) One can put a cap today by tweaking d->max_pages -- CoW will fail, faulting vcpu will sleep, and things can be kicked back into action at a later point. > >> (rough proposed design re-attached below) > > Thanks for that. It describes a sensible-looking hypervisor interface, > but my question was really: what should xl do, in the presence of > ballooning, sharing, paging and tmem, to > - decide whether a VM can be started at all; > - control those four systems to shuffle memory around; and > - resolve races sensibly to avoid small VMs deferring large ones. > (AIUI, xl already has some logic to handle the case of balloon-to-fit.) > > The second of those three is the interesting one. It seems to me that > if the tools can't force all other actors to give up memory (and not > immediately take it back) then they can't guarantee to be able to start > a new VM, even with the new reservation hypercalls. > > Cheers, > > Tim. > >>> From: Dan Magenheimer >>> Sent: Monday, October 01, 2012 2:04 PM >>> : >>> : >>> Back to design brainstorming: >>> >>> The way I am thinking about it, the tools need to be involved >>> to the extent that they would need to communicate to the >>> hypervisor the following facts (probably via new hypercall): >>> >>> X1) I am launching a domain X and it is eventually going to >>> consume up to a maximum of N MB. Please tell me if >>> there is sufficient RAM available AND, if so, reserve >>> it until I tell you I am done. ("AND" implies transactional >>> semantics) X1 does not need hypervisor support. We already coexist with a global daemon that is a single point of failure. I'm not arguing for xenstore to hold onto these reservations, but a daemon can. Xapi does it that way. Andres >>> X2) The launch of X is complete and I will not be requesting >>> the allocation of any more RAM for it. Please release >>> the reservation, whether or not I've requested a total >>> of N MB. >>> >>> The calls may be nested or partially ordered, i.e. >>> X1...Y1...Y2...X2 >>> X1...Y1...X2...Y2 >>> and the hypervisor must be able to deal with this. >>> >>> Then there would need to be two "versions" of "xm/xl free". >>> We can quibble about which should be the default, but >>> they would be: >>> >>> - "xl --reserved free" asks the hypervisor how much RAM >>> is available taking into account reservations >>> - "xm --raw free" asks the hypervisor for the instantaneous >>> amount of RAM unallocated, not counting reservations >>> >>> When the tools are not launching a domain (that is there >>> has been a matching X2 for all X1), the results of the >>> above "free" queries are always identical. >>> >>> So, IanJ, does this match up with the design you were thinking >>> about? >>> >>> Thanks, >>> Dan >>> >>> [1] I think the core culprits are (a) the hypervisor accounts for >>> memory allocation of pages strictly on a first-come-first-served >>> basis and (b) the tools don't have any form of need-this-much-memory >>> "transaction" model _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 13:37:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 13:37:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJlcH-0006Gy-3f; Thu, 04 Oct 2012 13:37:29 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJlcF-0006Gs-Od for xen-devel@lists.xen.org; Thu, 04 Oct 2012 13:37:27 +0000 Received: from [85.158.143.99:18086] by server-3.bemta-4.messagelabs.com id 90/52-10986-7119D605; Thu, 04 Oct 2012 13:37:27 +0000 X-Env-Sender: dario.faggioli@citrix.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1349357846!24736988!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15166 invoked from network); 4 Oct 2012 13:37:26 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 13:37:26 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="asc'?scan'208";a="14942358" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 13:37:26 +0000 Received: from [IPv6:::1] (10.80.16.67) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 14:37:26 +0100 Message-ID: <1349357836.26047.1.camel@Abyss> From: Dario Faggioli To: Andrew Cooper Date: Thu, 4 Oct 2012 15:37:16 +0200 In-Reply-To: <506C31D0.4060702@citrix.com> References: <506C3123.5050700@citrix.com> <506C31D0.4060702@citrix.com> X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) MIME-Version: 1.0 Cc: "Keir \(Xen.org\)" , Jan Beulich , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [Xen-devel V2] sedf/build: Fix build when using -fno-inline X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5514455596270412557==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============5514455596270412557== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-gBXs1jJjY8P4VoO/m64V" --=-gBXs1jJjY8P4VoO/m64V Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2012-10-03 at 13:38 +0100, Andrew Cooper wrote: > # HG changeset patch > # Parent 5fbdbf585f5f2ee9a3e3c75a8a9f9f2cc6eda65c > sedf/build: Fix build when using -fno-inline >=20 > struct task_slice.migrated is not initialised by this function, and > subsequently returned by value, leading to the error: >=20 > sched_sedf.c: In function 'sedf_do_extra_schedule': > sched_sedf.c:711: error: 'ret.migrated' may be used uninitialised in > this function >=20 > for both gcc 4.1.2 and 4.4.3 (which are the two I have easily to hand) > when combined with the -fno-inline compile option. >=20 > Signed-off-by Andrew Cooper >=20 Acked-by: Dario Faggioli > -- > This is compile tested only, but given that the sole caller of > sedf_do_extra_schedule() unconditionally sets migrated to 0, I am > fairly > confident of the correctness of the fix. >=20 Agreed, sedf does not include any task migration mechanism, so 0 is all you can have there. :-) Thanks and Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-gBXs1jJjY8P4VoO/m64V Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAlBtkQwACgkQk4XaBE3IOsRH8QCfW1VK2JURAjjhG9dB9kfv+p6X lbwAmQEJNA3F90MJNR1SIp/RtSsgCaan =cFWe -----END PGP SIGNATURE----- --=-gBXs1jJjY8P4VoO/m64V-- --===============5514455596270412557== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============5514455596270412557==-- From xen-devel-bounces@lists.xen.org Thu Oct 04 13:37:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 13:37:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJlcH-0006Gy-3f; Thu, 04 Oct 2012 13:37:29 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJlcF-0006Gs-Od for xen-devel@lists.xen.org; Thu, 04 Oct 2012 13:37:27 +0000 Received: from [85.158.143.99:18086] by server-3.bemta-4.messagelabs.com id 90/52-10986-7119D605; Thu, 04 Oct 2012 13:37:27 +0000 X-Env-Sender: dario.faggioli@citrix.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1349357846!24736988!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15166 invoked from network); 4 Oct 2012 13:37:26 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 13:37:26 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="asc'?scan'208";a="14942358" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 13:37:26 +0000 Received: from [IPv6:::1] (10.80.16.67) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 14:37:26 +0100 Message-ID: <1349357836.26047.1.camel@Abyss> From: Dario Faggioli To: Andrew Cooper Date: Thu, 4 Oct 2012 15:37:16 +0200 In-Reply-To: <506C31D0.4060702@citrix.com> References: <506C3123.5050700@citrix.com> <506C31D0.4060702@citrix.com> X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) MIME-Version: 1.0 Cc: "Keir \(Xen.org\)" , Jan Beulich , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [Xen-devel V2] sedf/build: Fix build when using -fno-inline X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5514455596270412557==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============5514455596270412557== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-gBXs1jJjY8P4VoO/m64V" --=-gBXs1jJjY8P4VoO/m64V Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2012-10-03 at 13:38 +0100, Andrew Cooper wrote: > # HG changeset patch > # Parent 5fbdbf585f5f2ee9a3e3c75a8a9f9f2cc6eda65c > sedf/build: Fix build when using -fno-inline >=20 > struct task_slice.migrated is not initialised by this function, and > subsequently returned by value, leading to the error: >=20 > sched_sedf.c: In function 'sedf_do_extra_schedule': > sched_sedf.c:711: error: 'ret.migrated' may be used uninitialised in > this function >=20 > for both gcc 4.1.2 and 4.4.3 (which are the two I have easily to hand) > when combined with the -fno-inline compile option. >=20 > Signed-off-by Andrew Cooper >=20 Acked-by: Dario Faggioli > -- > This is compile tested only, but given that the sole caller of > sedf_do_extra_schedule() unconditionally sets migrated to 0, I am > fairly > confident of the correctness of the fix. >=20 Agreed, sedf does not include any task migration mechanism, so 0 is all you can have there. :-) Thanks and Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-gBXs1jJjY8P4VoO/m64V Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAlBtkQwACgkQk4XaBE3IOsRH8QCfW1VK2JURAjjhG9dB9kfv+p6X lbwAmQEJNA3F90MJNR1SIp/RtSsgCaan =cFWe -----END PGP SIGNATURE----- --=-gBXs1jJjY8P4VoO/m64V-- --===============5514455596270412557== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============5514455596270412557==-- From xen-devel-bounces@lists.xen.org Thu Oct 04 13:54:07 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 13:54:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJls6-0006Sz-MZ; Thu, 04 Oct 2012 13:53:50 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJls5-0006Su-13 for xen-devel@lists.xen.org; Thu, 04 Oct 2012 13:53:49 +0000 Received: from [85.158.137.99:12307] by server-2.bemta-3.messagelabs.com id 59/6B-16514-CE49D605; Thu, 04 Oct 2012 13:53:48 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-16.tower-217.messagelabs.com!1349358827!20267797!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4121 invoked from network); 4 Oct 2012 13:53:47 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-16.tower-217.messagelabs.com with SMTP; 4 Oct 2012 13:53:47 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 04 Oct 2012 14:53:47 +0100 Message-Id: <506DB10A020000780009FA9F@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Thu, 04 Oct 2012 14:53:46 +0100 From: "Jan Beulich" To: "xen-devel" Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part3B0A0BFA.1__=" Cc: Jinsong Liu Subject: [Xen-devel] [PATCH] fix inclusion style in public/domctl.h X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part3B0A0BFA.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Public headers should include one another only via self-relative include directives (violated by 25955:07d0d5b3a005). Signed-off-by: Jan Beulich --- a/xen/include/public/domctl.h +++ b/xen/include/public/domctl.h @@ -32,9 +32,9 @@ #error "domctl operations are intended for use by node control tools = only" #endif =20 -#include #include "xen.h" #include "grant_table.h" +#include "hvm/save.h" =20 #define XEN_DOMCTL_INTERFACE_VERSION 0x00000008 =20 --=__Part3B0A0BFA.1__= Content-Type: text/plain; name="domctl-include-hvm-save.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="domctl-include-hvm-save.patch" fix inclusion style in public/domctl.h=0A=0APublic headers should include = one another only via self-relative=0Ainclude directives (violated by = 25955:07d0d5b3a005).=0A=0ASigned-off-by: Jan Beulich =0A= =0A--- a/xen/include/public/domctl.h=0A+++ b/xen/include/public/domctl.h=0A= @@ -32,9 +32,9 @@=0A #error "domctl operations are intended for use by = node control tools only"=0A #endif=0A =0A-#include =0A = #include "xen.h"=0A #include "grant_table.h"=0A+#include "hvm/save.h"=0A = =0A #define XEN_DOMCTL_INTERFACE_VERSION 0x00000008=0A =0A --=__Part3B0A0BFA.1__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --=__Part3B0A0BFA.1__=-- From xen-devel-bounces@lists.xen.org Thu Oct 04 13:54:07 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 13:54:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJls6-0006Sz-MZ; Thu, 04 Oct 2012 13:53:50 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJls5-0006Su-13 for xen-devel@lists.xen.org; Thu, 04 Oct 2012 13:53:49 +0000 Received: from [85.158.137.99:12307] by server-2.bemta-3.messagelabs.com id 59/6B-16514-CE49D605; Thu, 04 Oct 2012 13:53:48 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-16.tower-217.messagelabs.com!1349358827!20267797!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4121 invoked from network); 4 Oct 2012 13:53:47 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-16.tower-217.messagelabs.com with SMTP; 4 Oct 2012 13:53:47 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 04 Oct 2012 14:53:47 +0100 Message-Id: <506DB10A020000780009FA9F@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Thu, 04 Oct 2012 14:53:46 +0100 From: "Jan Beulich" To: "xen-devel" Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part3B0A0BFA.1__=" Cc: Jinsong Liu Subject: [Xen-devel] [PATCH] fix inclusion style in public/domctl.h X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part3B0A0BFA.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Public headers should include one another only via self-relative include directives (violated by 25955:07d0d5b3a005). Signed-off-by: Jan Beulich --- a/xen/include/public/domctl.h +++ b/xen/include/public/domctl.h @@ -32,9 +32,9 @@ #error "domctl operations are intended for use by node control tools = only" #endif =20 -#include #include "xen.h" #include "grant_table.h" +#include "hvm/save.h" =20 #define XEN_DOMCTL_INTERFACE_VERSION 0x00000008 =20 --=__Part3B0A0BFA.1__= Content-Type: text/plain; name="domctl-include-hvm-save.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="domctl-include-hvm-save.patch" fix inclusion style in public/domctl.h=0A=0APublic headers should include = one another only via self-relative=0Ainclude directives (violated by = 25955:07d0d5b3a005).=0A=0ASigned-off-by: Jan Beulich =0A= =0A--- a/xen/include/public/domctl.h=0A+++ b/xen/include/public/domctl.h=0A= @@ -32,9 +32,9 @@=0A #error "domctl operations are intended for use by = node control tools only"=0A #endif=0A =0A-#include =0A = #include "xen.h"=0A #include "grant_table.h"=0A+#include "hvm/save.h"=0A = =0A #define XEN_DOMCTL_INTERFACE_VERSION 0x00000008=0A =0A --=__Part3B0A0BFA.1__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --=__Part3B0A0BFA.1__=-- From xen-devel-bounces@lists.xen.org Thu Oct 04 13:55:09 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 13:55:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJlt6-0006Vh-4y; Thu, 04 Oct 2012 13:54:52 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJlt4-0006Va-Hd for Xen-devel@lists.xensource.com; Thu, 04 Oct 2012 13:54:50 +0000 Received: from [85.158.139.83:34747] by server-12.bemta-5.messagelabs.com id E4/62-20729-9259D605; Thu, 04 Oct 2012 13:54:49 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1349358888!19340335!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13450 invoked from network); 4 Oct 2012 13:54:49 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 13:54:49 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="14942849" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 13:54:48 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 14:54:49 +0100 Message-ID: <1349358887.866.40.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Mukesh Rathor Date: Thu, 4 Oct 2012 14:54:47 +0100 In-Reply-To: <20120921121556.1a0ea8af@mantra.us.oracle.com> References: <20120921121556.1a0ea8af@mantra.us.oracle.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Tim Deegan , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-09-21 at 20:15 +0100, Mukesh Rathor wrote: > > +int pvh_rem_xen_p2m(unsigned long spfn, int count) > +{ > + struct xen_remove_from_physmap xrp; > + int i, rc; > + > + for (i=0; i < count; i++) { > + xrp.domid = DOMID_SELF; > + xrp.gpfn = spfn+i; > + rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, &xrp); It seems that the current implementation of this hypercall in the h/v doesn't handle unmapping of foreign pages, since it requires that the page be owned by the domain whose P2M it is manipulating. How did you fix this on the hypervisor side? I'd like to make sure I do things consistently on the ARM side. Talking with Tim it seems like having foreign mappings in a p2m is a bit tricky and needs a bit of careful thought WRT reference counting etc. Ian. > + if (rc) { > + pr_warn("Failed to unmap pfn:%lx rc:%d done:%d\n", > + spfn+i, rc, i); > + return 1; > + } > + } > + return 0; > +} > +EXPORT_SYMBOL_GPL(pvh_rem_xen_p2m); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 13:55:09 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 13:55:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJlt6-0006Vh-4y; Thu, 04 Oct 2012 13:54:52 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJlt4-0006Va-Hd for Xen-devel@lists.xensource.com; Thu, 04 Oct 2012 13:54:50 +0000 Received: from [85.158.139.83:34747] by server-12.bemta-5.messagelabs.com id E4/62-20729-9259D605; Thu, 04 Oct 2012 13:54:49 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1349358888!19340335!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13450 invoked from network); 4 Oct 2012 13:54:49 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 13:54:49 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="14942849" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 13:54:48 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 14:54:49 +0100 Message-ID: <1349358887.866.40.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Mukesh Rathor Date: Thu, 4 Oct 2012 14:54:47 +0100 In-Reply-To: <20120921121556.1a0ea8af@mantra.us.oracle.com> References: <20120921121556.1a0ea8af@mantra.us.oracle.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Tim Deegan , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-09-21 at 20:15 +0100, Mukesh Rathor wrote: > > +int pvh_rem_xen_p2m(unsigned long spfn, int count) > +{ > + struct xen_remove_from_physmap xrp; > + int i, rc; > + > + for (i=0; i < count; i++) { > + xrp.domid = DOMID_SELF; > + xrp.gpfn = spfn+i; > + rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, &xrp); It seems that the current implementation of this hypercall in the h/v doesn't handle unmapping of foreign pages, since it requires that the page be owned by the domain whose P2M it is manipulating. How did you fix this on the hypervisor side? I'd like to make sure I do things consistently on the ARM side. Talking with Tim it seems like having foreign mappings in a p2m is a bit tricky and needs a bit of careful thought WRT reference counting etc. Ian. > + if (rc) { > + pr_warn("Failed to unmap pfn:%lx rc:%d done:%d\n", > + spfn+i, rc, i); > + return 1; > + } > + } > + return 0; > +} > +EXPORT_SYMBOL_GPL(pvh_rem_xen_p2m); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 14:10:48 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 14:10:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJm8C-0006s1-Ou; Thu, 04 Oct 2012 14:10:28 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJkOv-0003WW-I3 for xen-devel@lists.xen.org; Thu, 04 Oct 2012 12:19:37 +0000 Received: from [85.158.143.35:56118] by server-3.bemta-4.messagelabs.com id BB/0D-10986-8DE7D605; Thu, 04 Oct 2012 12:19:36 +0000 X-Env-Sender: kristoffer@itoc.dk X-Msg-Ref: server-13.tower-21.messagelabs.com!1349353176!14538998!1 X-Originating-IP: [77.66.16.14] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30394 invoked from network); 4 Oct 2012 12:19:36 -0000 Received: from mail01.itoc.dk (HELO hosting01.itoc.dk) (77.66.16.14) by server-13.tower-21.messagelabs.com with SMTP; 4 Oct 2012 12:19:36 -0000 Received: from localhost (hosting01.ultraslice.com [127.0.0.1]) by hosting01.itoc.dk (Postfix) with ESMTP id 0FCBB3C3C0A0F; Thu, 4 Oct 2012 14:19:36 +0200 (CEST) Received: from hosting01.itoc.dk ([127.0.0.1]) by localhost (hosting01.itoc.dk [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 18179-02; Thu, 4 Oct 2012 14:19:34 +0200 (CEST) Received: from [10.0.1.52] (0x573fe6e2.cpe.ge-1-1-0-1104.vbrnqu1.customer.tele.dk [87.63.230.226]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: kristoffer@itoc.dk) by hosting01.itoc.dk (Postfix) with ESMTPSA id DD2BC3C3C0A09; Thu, 4 Oct 2012 14:19:34 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Kristoffer Egefelt In-Reply-To: <4B45B535F7F6BE4CB1C044ED5115CDDE011ADEB1ED80@LONPMAILBOX01.citrite.net> Date: Thu, 4 Oct 2012 14:19:34 +0200 Message-Id: <7162B2B4-EF0E-48B4-8112-274AA918D6A7@itoc.dk> References: <1672AF40-A2FD-4D58-93B2-1B8C506A799A@itoc.dk> <4B45B535F7F6BE4CB1C044ED5115CDDE011ADEB1ED77@LONPMAILBOX01.citrite.net> <4B45B535F7F6BE4CB1C044ED5115CDDE011ADEB1ED80@LONPMAILBOX01.citrite.net> To: Thanos Makatos X-Mailer: Apple Mail (2.1486) X-Virus-Scanned: Maia Mailguard 1.0.2 X-Mailman-Approved-At: Thu, 04 Oct 2012 14:10:27 +0000 Cc: "Xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Blktap userspace utils X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org I doubt my coding skills will satisfy the blktap3 - but I'm looking much forward to testing and smaller-scale patching ;-) > Of course you're welcome to do this if you want! :-) > I'm planning to re-send a fairly cleaned-up version of blktap3 in the next few days. > > -- > Thanos Makatos > > >> -----Original Message----- >> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel- >> bounces@lists.xen.org] On Behalf Of Thanos Makatos >> Sent: 04 October 2012 12:32 >> To: Kristoffer Egefelt; Xen-devel@lists.xen.org >> Subject: Re: [Xen-devel] Blktap userspace utils >> >> Just to let you know, I'm planning to import all of the github blktap2 >> functionality into blktap3 (blktap3 is based on a relatively recent >> github blktap2 version), once blktap3 makes it into the tree. >> >> Cheers >> >> -- >> Thanos Makatos >> >> >>> -----Original Message----- >>> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel- >>> bounces@lists.xen.org] On Behalf Of Kristoffer Egefelt >>> Sent: 04 October 2012 08:34 >>> To: Xen-devel@lists.xen.org >>> Subject: [Xen-devel] Blktap userspace utils >>> >>> Hi, >>> >>> I'd like to use the blktap utils from >>> https://github.com/xen-org/blktap because of the mirror feature, as >>> the blktap utils comming with xen does not support this. >>> >>> Could anybody explain why there are two different blktap utils (one >> in >>> git and one comming with xen source) and how to compile the one from >>> git so that it works with libxl ? >>> >>> Any pointers greatly appreciated ;-) >>> >>> Thanks >>> >>> Regards >>> Kristoffer >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xen.org >>> http://lists.xen.org/xen-devel >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 14:10:48 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 14:10:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJm8C-0006s1-Ou; Thu, 04 Oct 2012 14:10:28 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJkOv-0003WW-I3 for xen-devel@lists.xen.org; Thu, 04 Oct 2012 12:19:37 +0000 Received: from [85.158.143.35:56118] by server-3.bemta-4.messagelabs.com id BB/0D-10986-8DE7D605; Thu, 04 Oct 2012 12:19:36 +0000 X-Env-Sender: kristoffer@itoc.dk X-Msg-Ref: server-13.tower-21.messagelabs.com!1349353176!14538998!1 X-Originating-IP: [77.66.16.14] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30394 invoked from network); 4 Oct 2012 12:19:36 -0000 Received: from mail01.itoc.dk (HELO hosting01.itoc.dk) (77.66.16.14) by server-13.tower-21.messagelabs.com with SMTP; 4 Oct 2012 12:19:36 -0000 Received: from localhost (hosting01.ultraslice.com [127.0.0.1]) by hosting01.itoc.dk (Postfix) with ESMTP id 0FCBB3C3C0A0F; Thu, 4 Oct 2012 14:19:36 +0200 (CEST) Received: from hosting01.itoc.dk ([127.0.0.1]) by localhost (hosting01.itoc.dk [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 18179-02; Thu, 4 Oct 2012 14:19:34 +0200 (CEST) Received: from [10.0.1.52] (0x573fe6e2.cpe.ge-1-1-0-1104.vbrnqu1.customer.tele.dk [87.63.230.226]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: kristoffer@itoc.dk) by hosting01.itoc.dk (Postfix) with ESMTPSA id DD2BC3C3C0A09; Thu, 4 Oct 2012 14:19:34 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Kristoffer Egefelt In-Reply-To: <4B45B535F7F6BE4CB1C044ED5115CDDE011ADEB1ED80@LONPMAILBOX01.citrite.net> Date: Thu, 4 Oct 2012 14:19:34 +0200 Message-Id: <7162B2B4-EF0E-48B4-8112-274AA918D6A7@itoc.dk> References: <1672AF40-A2FD-4D58-93B2-1B8C506A799A@itoc.dk> <4B45B535F7F6BE4CB1C044ED5115CDDE011ADEB1ED77@LONPMAILBOX01.citrite.net> <4B45B535F7F6BE4CB1C044ED5115CDDE011ADEB1ED80@LONPMAILBOX01.citrite.net> To: Thanos Makatos X-Mailer: Apple Mail (2.1486) X-Virus-Scanned: Maia Mailguard 1.0.2 X-Mailman-Approved-At: Thu, 04 Oct 2012 14:10:27 +0000 Cc: "Xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Blktap userspace utils X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org I doubt my coding skills will satisfy the blktap3 - but I'm looking much forward to testing and smaller-scale patching ;-) > Of course you're welcome to do this if you want! :-) > I'm planning to re-send a fairly cleaned-up version of blktap3 in the next few days. > > -- > Thanos Makatos > > >> -----Original Message----- >> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel- >> bounces@lists.xen.org] On Behalf Of Thanos Makatos >> Sent: 04 October 2012 12:32 >> To: Kristoffer Egefelt; Xen-devel@lists.xen.org >> Subject: Re: [Xen-devel] Blktap userspace utils >> >> Just to let you know, I'm planning to import all of the github blktap2 >> functionality into blktap3 (blktap3 is based on a relatively recent >> github blktap2 version), once blktap3 makes it into the tree. >> >> Cheers >> >> -- >> Thanos Makatos >> >> >>> -----Original Message----- >>> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel- >>> bounces@lists.xen.org] On Behalf Of Kristoffer Egefelt >>> Sent: 04 October 2012 08:34 >>> To: Xen-devel@lists.xen.org >>> Subject: [Xen-devel] Blktap userspace utils >>> >>> Hi, >>> >>> I'd like to use the blktap utils from >>> https://github.com/xen-org/blktap because of the mirror feature, as >>> the blktap utils comming with xen does not support this. >>> >>> Could anybody explain why there are two different blktap utils (one >> in >>> git and one comming with xen source) and how to compile the one from >>> git so that it works with libxl ? >>> >>> Any pointers greatly appreciated ;-) >>> >>> Thanks >>> >>> Regards >>> Kristoffer >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xen.org >>> http://lists.xen.org/xen-devel >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 14:32:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 14:32:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJmSu-000793-TF; Thu, 04 Oct 2012 14:31:52 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJmSu-00078y-4C for xen-devel@lists.xen.org; Thu, 04 Oct 2012 14:31:52 +0000 Received: from [85.158.143.99:54925] by server-1.bemta-4.messagelabs.com id CA/E8-05684-7DD9D605; Thu, 04 Oct 2012 14:31:51 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1349361110!26753527!1 X-Originating-IP: [209.85.214.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10688 invoked from network); 4 Oct 2012 14:31:50 -0000 Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com) (209.85.214.45) by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 14:31:50 -0000 Received: by mail-bk0-f45.google.com with SMTP id jf3so355241bkc.32 for ; Thu, 04 Oct 2012 07:31:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=MoX2ibmPT+YhFrE5oVlhgvgsGV16agB1/MtV3YX9CJM=; b=uo20N1MvtNT9my/UBTsnbu8rHCyHnh4l3qzPFUYzhatoHugyeX2Cz0Q+SKrSIL4Qwu /OLDgCW4RA6cfHWizT8Zd2YEH86G4ts9PtyDvr55gCRm88t/N+Aq4SzRstaQtUgcPwop PqPutlNgfHD06cWzzZzbAF2Yto+qE3UL2bEAlNjB8n5mPzTviQR8fezgAoWODLw1QyZw SAjguQTvozDgj7zCVNN3jKwPEPGc/eKCe+Mvqgh9M0L/EZwcMMdRoBPJW4TUYIzM/VGr 20qBpxEyA1O3KD+NsIIgVX/i+Rb+9/gGcsCVVCnEmcqvDOFc9K0BfV77uGJUtUZTMcvA GF1Q== Received: by 10.204.11.194 with SMTP id u2mr1712579bku.41.1349361110416; Thu, 04 Oct 2012 07:31:50 -0700 (PDT) Received: from [192.168.1.69] (host86-183-156-141.range86-183.btcentralplus.com. [86.183.156.141]) by mx.google.com with ESMTPS id j24sm5838777bkv.0.2012.10.04.07.31.47 (version=SSLv3 cipher=OTHER); Thu, 04 Oct 2012 07:31:49 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Thu, 04 Oct 2012 15:31:46 +0100 From: Keir Fraser To: Jan Beulich , xen-devel Message-ID: Thread-Topic: [Xen-devel] [PATCH] fix inclusion style in public/domctl.h Thread-Index: Ac2iPPs2199AwoyXzEq/1ymP+jUtFg== In-Reply-To: <506DB10A020000780009FA9F@nat28.tlf.novell.com> Mime-version: 1.0 Cc: Jinsong Liu Subject: Re: [Xen-devel] [PATCH] fix inclusion style in public/domctl.h X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 04/10/2012 14:53, "Jan Beulich" wrote: > Public headers should include one another only via self-relative > include directives (violated by 25955:07d0d5b3a005). > > Signed-off-by: Jan Beulich Acked-by: Keir Fraser > --- a/xen/include/public/domctl.h > +++ b/xen/include/public/domctl.h > @@ -32,9 +32,9 @@ > #error "domctl operations are intended for use by node control tools only" > #endif > > -#include > #include "xen.h" > #include "grant_table.h" > +#include "hvm/save.h" > > #define XEN_DOMCTL_INTERFACE_VERSION 0x00000008 > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 14:32:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 14:32:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJmSu-000793-TF; Thu, 04 Oct 2012 14:31:52 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJmSu-00078y-4C for xen-devel@lists.xen.org; Thu, 04 Oct 2012 14:31:52 +0000 Received: from [85.158.143.99:54925] by server-1.bemta-4.messagelabs.com id CA/E8-05684-7DD9D605; Thu, 04 Oct 2012 14:31:51 +0000 X-Env-Sender: keir.xen@gmail.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1349361110!26753527!1 X-Originating-IP: [209.85.214.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10688 invoked from network); 4 Oct 2012 14:31:50 -0000 Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com) (209.85.214.45) by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 14:31:50 -0000 Received: by mail-bk0-f45.google.com with SMTP id jf3so355241bkc.32 for ; Thu, 04 Oct 2012 07:31:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=MoX2ibmPT+YhFrE5oVlhgvgsGV16agB1/MtV3YX9CJM=; b=uo20N1MvtNT9my/UBTsnbu8rHCyHnh4l3qzPFUYzhatoHugyeX2Cz0Q+SKrSIL4Qwu /OLDgCW4RA6cfHWizT8Zd2YEH86G4ts9PtyDvr55gCRm88t/N+Aq4SzRstaQtUgcPwop PqPutlNgfHD06cWzzZzbAF2Yto+qE3UL2bEAlNjB8n5mPzTviQR8fezgAoWODLw1QyZw SAjguQTvozDgj7zCVNN3jKwPEPGc/eKCe+Mvqgh9M0L/EZwcMMdRoBPJW4TUYIzM/VGr 20qBpxEyA1O3KD+NsIIgVX/i+Rb+9/gGcsCVVCnEmcqvDOFc9K0BfV77uGJUtUZTMcvA GF1Q== Received: by 10.204.11.194 with SMTP id u2mr1712579bku.41.1349361110416; Thu, 04 Oct 2012 07:31:50 -0700 (PDT) Received: from [192.168.1.69] (host86-183-156-141.range86-183.btcentralplus.com. [86.183.156.141]) by mx.google.com with ESMTPS id j24sm5838777bkv.0.2012.10.04.07.31.47 (version=SSLv3 cipher=OTHER); Thu, 04 Oct 2012 07:31:49 -0700 (PDT) User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Thu, 04 Oct 2012 15:31:46 +0100 From: Keir Fraser To: Jan Beulich , xen-devel Message-ID: Thread-Topic: [Xen-devel] [PATCH] fix inclusion style in public/domctl.h Thread-Index: Ac2iPPs2199AwoyXzEq/1ymP+jUtFg== In-Reply-To: <506DB10A020000780009FA9F@nat28.tlf.novell.com> Mime-version: 1.0 Cc: Jinsong Liu Subject: Re: [Xen-devel] [PATCH] fix inclusion style in public/domctl.h X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 04/10/2012 14:53, "Jan Beulich" wrote: > Public headers should include one another only via self-relative > include directives (violated by 25955:07d0d5b3a005). > > Signed-off-by: Jan Beulich Acked-by: Keir Fraser > --- a/xen/include/public/domctl.h > +++ b/xen/include/public/domctl.h > @@ -32,9 +32,9 @@ > #error "domctl operations are intended for use by node control tools only" > #endif > > -#include > #include "xen.h" > #include "grant_table.h" > +#include "hvm/save.h" > > #define XEN_DOMCTL_INTERFACE_VERSION 0x00000008 > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 14:37:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 14:37:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJmY0-0007Ho-LW; Thu, 04 Oct 2012 14:37:08 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJmXy-0007Hj-NT for xen-devel@lists.xen.org; Thu, 04 Oct 2012 14:37:06 +0000 Received: from [85.158.139.83:34243] by server-11.bemta-5.messagelabs.com id C7/49-13866-11F9D605; Thu, 04 Oct 2012 14:37:05 +0000 X-Env-Sender: ketuzsezr@gmail.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1349361424!33253299!1 X-Originating-IP: [209.85.212.45] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 683 invoked from network); 4 Oct 2012 14:37:05 -0000 Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com) (209.85.212.45) by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 14:37:05 -0000 Received: by mail-vb0-f45.google.com with SMTP id p1so779707vbi.32 for ; Thu, 04 Oct 2012 07:37:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=q38t81iIFIa4EccVtFl21hkyHUfN0DNoRM2zUpAXPTQ=; b=tR/kKePKRw7ZaqpahDE3u1IzrhzFzK7NE88Hvu7hNbBaMJiadsavvZr/0+yjOCCFFR UJQr0hDiuw/Clu1C44IzoWm8riu7yBC9DlcG4noT+NVcivwfdJN8iow5/SUiz0EFXTps +FBKCo7Si5YVlTsE1qmobgR5f5c4kOluqJuKUva9g/CVJYkbUjlHc7h2k6y81RmXDgEQ E1CyOaeeM7qu21SZ93s5IK1L53iuiSCDhNeonAffms42qKXM0OnYg8LMLnybobexRPuG LRHgrkQi6yXhaYejyhsNpSFylXTkLdffQMj+rK1mnj6DqpN75AtfaJwuIsTYB7TiWeBI b/xw== Received: by 10.220.38.73 with SMTP id a9mr1278942vce.72.1349361424003; Thu, 04 Oct 2012 07:37:04 -0700 (PDT) Received: from phenom.dumpdata.com (50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189]) by mx.google.com with ESMTPS id g19sm865501vdh.17.2012.10.04.07.37.02 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Oct 2012 07:37:03 -0700 (PDT) Date: Thu, 4 Oct 2012 10:25:38 -0400 From: Konrad Rzeszutek Wilk To: Peter Maloney Message-ID: <20121004142538.GA9979@phenom.dumpdata.com> References: <501F98A1.4070806@brockmann-consult.de> <501FB9060200007800092D4E@nat28.tlf.novell.com> <5020C2DE.304@brockmann-consult.de> <50294D4B.9050405@brockmann-consult.de> <50296AC2.80600@brockmann-consult.de> <506C73A3.2030605@brockmann-consult.de> <506C9A84.5040408@brockmann-consult.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <506C9A84.5040408@brockmann-consult.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] 4.1.2 very slow without upstream patches, but fast with them, also 4.2 very slow X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, Oct 03, 2012 at 10:05:24PM +0200, Peter Maloney wrote: > I also tested: > modprobe xen-acpi-processor You didn't say what kind of CPU you have. Nor if you compiled your kernel or if you used a distros' kernel. One thing (just to eliminate this being a power management issue), is to do this on the Linux command line: xen-acpi-processor.off=1 It would also help if you provided the .config you are using. There are some options you should not have one (like XEN_DEBUGFS.. something). _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 14:37:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 14:37:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJmY0-0007Ho-LW; Thu, 04 Oct 2012 14:37:08 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJmXy-0007Hj-NT for xen-devel@lists.xen.org; Thu, 04 Oct 2012 14:37:06 +0000 Received: from [85.158.139.83:34243] by server-11.bemta-5.messagelabs.com id C7/49-13866-11F9D605; Thu, 04 Oct 2012 14:37:05 +0000 X-Env-Sender: ketuzsezr@gmail.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1349361424!33253299!1 X-Originating-IP: [209.85.212.45] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 683 invoked from network); 4 Oct 2012 14:37:05 -0000 Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com) (209.85.212.45) by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 14:37:05 -0000 Received: by mail-vb0-f45.google.com with SMTP id p1so779707vbi.32 for ; Thu, 04 Oct 2012 07:37:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=q38t81iIFIa4EccVtFl21hkyHUfN0DNoRM2zUpAXPTQ=; b=tR/kKePKRw7ZaqpahDE3u1IzrhzFzK7NE88Hvu7hNbBaMJiadsavvZr/0+yjOCCFFR UJQr0hDiuw/Clu1C44IzoWm8riu7yBC9DlcG4noT+NVcivwfdJN8iow5/SUiz0EFXTps +FBKCo7Si5YVlTsE1qmobgR5f5c4kOluqJuKUva9g/CVJYkbUjlHc7h2k6y81RmXDgEQ E1CyOaeeM7qu21SZ93s5IK1L53iuiSCDhNeonAffms42qKXM0OnYg8LMLnybobexRPuG LRHgrkQi6yXhaYejyhsNpSFylXTkLdffQMj+rK1mnj6DqpN75AtfaJwuIsTYB7TiWeBI b/xw== Received: by 10.220.38.73 with SMTP id a9mr1278942vce.72.1349361424003; Thu, 04 Oct 2012 07:37:04 -0700 (PDT) Received: from phenom.dumpdata.com (50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189]) by mx.google.com with ESMTPS id g19sm865501vdh.17.2012.10.04.07.37.02 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Oct 2012 07:37:03 -0700 (PDT) Date: Thu, 4 Oct 2012 10:25:38 -0400 From: Konrad Rzeszutek Wilk To: Peter Maloney Message-ID: <20121004142538.GA9979@phenom.dumpdata.com> References: <501F98A1.4070806@brockmann-consult.de> <501FB9060200007800092D4E@nat28.tlf.novell.com> <5020C2DE.304@brockmann-consult.de> <50294D4B.9050405@brockmann-consult.de> <50296AC2.80600@brockmann-consult.de> <506C73A3.2030605@brockmann-consult.de> <506C9A84.5040408@brockmann-consult.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <506C9A84.5040408@brockmann-consult.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] 4.1.2 very slow without upstream patches, but fast with them, also 4.2 very slow X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, Oct 03, 2012 at 10:05:24PM +0200, Peter Maloney wrote: > I also tested: > modprobe xen-acpi-processor You didn't say what kind of CPU you have. Nor if you compiled your kernel or if you used a distros' kernel. One thing (just to eliminate this being a power management issue), is to do this on the Linux command line: xen-acpi-processor.off=1 It would also help if you provided the .config you are using. There are some options you should not have one (like XEN_DEBUGFS.. something). _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 15:04:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 15:04:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJmxb-0007f0-TZ; Thu, 04 Oct 2012 15:03:35 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJmxZ-0007eb-JB for xen-devel@lists.xen.org; Thu, 04 Oct 2012 15:03:33 +0000 Received: from [85.158.138.51:53939] by server-2.bemta-3.messagelabs.com id BA/BE-16514-345AD605; Thu, 04 Oct 2012 15:03:31 +0000 X-Env-Sender: jean.guyader@gmail.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1349363009!25187459!1 X-Originating-IP: [209.85.212.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30162 invoked from network); 4 Oct 2012 15:03:30 -0000 Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com) (209.85.212.45) by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 15:03:30 -0000 Received: by mail-vb0-f45.google.com with SMTP id p1so824929vbi.32 for ; Thu, 04 Oct 2012 08:03:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=XH6oBrn5AmWbNXQSBuI7/BGEKNWNa+bpmHN3LufcxDQ=; b=uwN6mAu0TU+ck5QQlJBfenAVnfNJ/KwSgDkXacriYER38uPD/bjYipWGklZAFMlosv t95ui6VB2YfZrL5Hd2HDItY8IlM9UF3vTwGQtYaCdteEAIXzHjyzG0WwSkftytE+VxDx pekQNMIAZS5edgcrnkn1n4VH2C3rbwQb5iw17v9y+2YtVecWrC4FM6NFjJxvAMXC6yuk fbwdB8AQQPGCurPC56mdikvaUFuVJxfmSOqTXo/FSS1EAgm1d4bTmLFsXia6FrJpeyTt kzUtyRyCu0xjiJlbBJig5JB8vEAeK6A/HsA7Er2U1mq1qxrzZq78+XUMEPTNmJsq+W5+ tOGg== Received: by 10.220.204.197 with SMTP id fn5mr3237153vcb.71.1349363009219; Thu, 04 Oct 2012 08:03:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.234.5 with HTTP; Thu, 4 Oct 2012 08:03:09 -0700 (PDT) In-Reply-To: <506D98FE020000780009FA23@nat28.tlf.novell.com> References: <1348141322-28657-1-git-send-email-jean.guyader@citrix.com> <1348141322-28657-5-git-send-email-jean.guyader@citrix.com> <505B2636020000780009CAA6@nat28.tlf.novell.com> <506D98FE020000780009FA23@nat28.tlf.novell.com> From: Jean Guyader Date: Thu, 4 Oct 2012 16:03:09 +0100 Message-ID: To: Jan Beulich Cc: tim@xen.org, Jean Guyader , xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH 4/4] xen: Add V4V implementation X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 4 October 2012 13:11, Jan Beulich wrote: >>>> On 04.10.12 at 14:03, Jean Guyader wrote: >> On 20 September 2012 13:20, Jan Beulich wrote: >>>>>> On 20.09.12 at 13:42, Jean Guyader wrote: >>>>+ case V4VOP_register_ring: >>>>+ { >>>>+ XEN_GUEST_HANDLE(v4v_ring_t) ring_hnd = >>>>+ guest_handle_cast(arg1, v4v_ring_t); >>>>+ XEN_GUEST_HANDLE(xen_pfn_t) pfn_hnd = >>>>+ guest_handle_cast(arg2, xen_pfn_t); >>>>+ uint32_t npage = arg3; >>>>+ if ( unlikely(!guest_handle_okay(ring_hnd, 1)) ) >>>>+ goto out; >>>>+ if ( unlikely(!guest_handle_okay(pfn_hnd, npage)) ) >>>>+ goto out; >>> >>> Here and below - this isn't sufficient for compat guests, or else >>> you give them a way to point into the compat m2p table. >>> >> >> I'll probably switch to uint64_t for the v4v mfn list instead of using >> xen_pfn_t which >> are unsigned long. That way I can save the need for a compat wrapper. > > But that comment of yours doesn't address the problem I pointed > out. > [Resent, CCing everyone this time] I'm sorry, I don't really get what you mean them. I've tried to get all my struct layout such as all the offset for the field are the same for 64b and 32b, this way I thought I could get away with doing a compat wrapper. Thanks, Jean _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 15:04:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 15:04:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJmxb-0007f0-TZ; Thu, 04 Oct 2012 15:03:35 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJmxZ-0007eb-JB for xen-devel@lists.xen.org; Thu, 04 Oct 2012 15:03:33 +0000 Received: from [85.158.138.51:53939] by server-2.bemta-3.messagelabs.com id BA/BE-16514-345AD605; Thu, 04 Oct 2012 15:03:31 +0000 X-Env-Sender: jean.guyader@gmail.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1349363009!25187459!1 X-Originating-IP: [209.85.212.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30162 invoked from network); 4 Oct 2012 15:03:30 -0000 Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com) (209.85.212.45) by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 15:03:30 -0000 Received: by mail-vb0-f45.google.com with SMTP id p1so824929vbi.32 for ; Thu, 04 Oct 2012 08:03:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=XH6oBrn5AmWbNXQSBuI7/BGEKNWNa+bpmHN3LufcxDQ=; b=uwN6mAu0TU+ck5QQlJBfenAVnfNJ/KwSgDkXacriYER38uPD/bjYipWGklZAFMlosv t95ui6VB2YfZrL5Hd2HDItY8IlM9UF3vTwGQtYaCdteEAIXzHjyzG0WwSkftytE+VxDx pekQNMIAZS5edgcrnkn1n4VH2C3rbwQb5iw17v9y+2YtVecWrC4FM6NFjJxvAMXC6yuk fbwdB8AQQPGCurPC56mdikvaUFuVJxfmSOqTXo/FSS1EAgm1d4bTmLFsXia6FrJpeyTt kzUtyRyCu0xjiJlbBJig5JB8vEAeK6A/HsA7Er2U1mq1qxrzZq78+XUMEPTNmJsq+W5+ tOGg== Received: by 10.220.204.197 with SMTP id fn5mr3237153vcb.71.1349363009219; Thu, 04 Oct 2012 08:03:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.234.5 with HTTP; Thu, 4 Oct 2012 08:03:09 -0700 (PDT) In-Reply-To: <506D98FE020000780009FA23@nat28.tlf.novell.com> References: <1348141322-28657-1-git-send-email-jean.guyader@citrix.com> <1348141322-28657-5-git-send-email-jean.guyader@citrix.com> <505B2636020000780009CAA6@nat28.tlf.novell.com> <506D98FE020000780009FA23@nat28.tlf.novell.com> From: Jean Guyader Date: Thu, 4 Oct 2012 16:03:09 +0100 Message-ID: To: Jan Beulich Cc: tim@xen.org, Jean Guyader , xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH 4/4] xen: Add V4V implementation X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 4 October 2012 13:11, Jan Beulich wrote: >>>> On 04.10.12 at 14:03, Jean Guyader wrote: >> On 20 September 2012 13:20, Jan Beulich wrote: >>>>>> On 20.09.12 at 13:42, Jean Guyader wrote: >>>>+ case V4VOP_register_ring: >>>>+ { >>>>+ XEN_GUEST_HANDLE(v4v_ring_t) ring_hnd = >>>>+ guest_handle_cast(arg1, v4v_ring_t); >>>>+ XEN_GUEST_HANDLE(xen_pfn_t) pfn_hnd = >>>>+ guest_handle_cast(arg2, xen_pfn_t); >>>>+ uint32_t npage = arg3; >>>>+ if ( unlikely(!guest_handle_okay(ring_hnd, 1)) ) >>>>+ goto out; >>>>+ if ( unlikely(!guest_handle_okay(pfn_hnd, npage)) ) >>>>+ goto out; >>> >>> Here and below - this isn't sufficient for compat guests, or else >>> you give them a way to point into the compat m2p table. >>> >> >> I'll probably switch to uint64_t for the v4v mfn list instead of using >> xen_pfn_t which >> are unsigned long. That way I can save the need for a compat wrapper. > > But that comment of yours doesn't address the problem I pointed > out. > [Resent, CCing everyone this time] I'm sorry, I don't really get what you mean them. I've tried to get all my struct layout such as all the offset for the field are the same for 64b and 32b, this way I thought I could get away with doing a compat wrapper. Thanks, Jean _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 15:08:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 15:08:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn1k-0007mD-K3; Thu, 04 Oct 2012 15:07:52 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn1i-0007m6-R7 for xen-devel@lists.xen.org; Thu, 04 Oct 2012 15:07:51 +0000 Received: from [85.158.143.35:52488] by server-1.bemta-4.messagelabs.com id 90/62-05684-646AD605; Thu, 04 Oct 2012 15:07:50 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1349363269!14568906!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4999 invoked from network); 4 Oct 2012 15:07:49 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-13.tower-21.messagelabs.com with SMTP; 4 Oct 2012 15:07:49 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 04 Oct 2012 16:07:49 +0100 Message-Id: <506DC265020000780009FAE1@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Thu, 04 Oct 2012 16:07:49 +0100 From: "Jan Beulich" To: "Jean Guyader" References: <1348141322-28657-1-git-send-email-jean.guyader@citrix.com> <1348141322-28657-5-git-send-email-jean.guyader@citrix.com> <505B2636020000780009CAA6@nat28.tlf.novell.com> <506D98FE020000780009FA23@nat28.tlf.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel Subject: Re: [Xen-devel] [PATCH 4/4] xen: Add V4V implementation X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 04.10.12 at 17:02, Jean Guyader wrote: > On 4 October 2012 13:11, Jan Beulich wrote: >>>>> On 04.10.12 at 14:03, Jean Guyader wrote: >>> On 20 September 2012 13:20, Jan Beulich wrote: >>>>>>> On 20.09.12 at 13:42, Jean Guyader wrote: >>>>>+ case V4VOP_register_ring: >>>>>+ { >>>>>+ XEN_GUEST_HANDLE(v4v_ring_t) ring_hnd = >>>>>+ guest_handle_cast(arg1, v4v_ring_t); >>>>>+ XEN_GUEST_HANDLE(xen_pfn_t) pfn_hnd = >>>>>+ guest_handle_cast(arg2, xen_pfn_t); >>>>>+ uint32_t npage = arg3; >>>>>+ if ( unlikely(!guest_handle_okay(ring_hnd, 1)) ) >>>>>+ goto out; >>>>>+ if ( unlikely(!guest_handle_okay(pfn_hnd, npage)) ) >>>>>+ goto out; >>>> >>>> Here and below - this isn't sufficient for compat guests, or else >>>> you give them a way to point into the compat m2p table. >>>> >>> >>> I'll probably switch to uint64_t for the v4v mfn list instead of using >>> xen_pfn_t which >>> are unsigned long. That way I can save the need for a compat wrapper. >> >> But that comment of yours doesn't address the problem I pointed >> out. >> > > I'm sorry, I don't really get what you mean them. I've tried to get > all my struct > layout such as all the offset for the field are the same for 64b and 32b, > this > way I thought I could get away with doing a compat wrapper. guest_handle_okay() simply isn't suitable for checking compat mode pointers - compat_handle_okay() needs to be used for them instead. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 15:08:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 15:08:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn1k-0007mD-K3; Thu, 04 Oct 2012 15:07:52 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn1i-0007m6-R7 for xen-devel@lists.xen.org; Thu, 04 Oct 2012 15:07:51 +0000 Received: from [85.158.143.35:52488] by server-1.bemta-4.messagelabs.com id 90/62-05684-646AD605; Thu, 04 Oct 2012 15:07:50 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1349363269!14568906!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4999 invoked from network); 4 Oct 2012 15:07:49 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-13.tower-21.messagelabs.com with SMTP; 4 Oct 2012 15:07:49 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Thu, 04 Oct 2012 16:07:49 +0100 Message-Id: <506DC265020000780009FAE1@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Thu, 04 Oct 2012 16:07:49 +0100 From: "Jan Beulich" To: "Jean Guyader" References: <1348141322-28657-1-git-send-email-jean.guyader@citrix.com> <1348141322-28657-5-git-send-email-jean.guyader@citrix.com> <505B2636020000780009CAA6@nat28.tlf.novell.com> <506D98FE020000780009FA23@nat28.tlf.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel Subject: Re: [Xen-devel] [PATCH 4/4] xen: Add V4V implementation X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 04.10.12 at 17:02, Jean Guyader wrote: > On 4 October 2012 13:11, Jan Beulich wrote: >>>>> On 04.10.12 at 14:03, Jean Guyader wrote: >>> On 20 September 2012 13:20, Jan Beulich wrote: >>>>>>> On 20.09.12 at 13:42, Jean Guyader wrote: >>>>>+ case V4VOP_register_ring: >>>>>+ { >>>>>+ XEN_GUEST_HANDLE(v4v_ring_t) ring_hnd = >>>>>+ guest_handle_cast(arg1, v4v_ring_t); >>>>>+ XEN_GUEST_HANDLE(xen_pfn_t) pfn_hnd = >>>>>+ guest_handle_cast(arg2, xen_pfn_t); >>>>>+ uint32_t npage = arg3; >>>>>+ if ( unlikely(!guest_handle_okay(ring_hnd, 1)) ) >>>>>+ goto out; >>>>>+ if ( unlikely(!guest_handle_okay(pfn_hnd, npage)) ) >>>>>+ goto out; >>>> >>>> Here and below - this isn't sufficient for compat guests, or else >>>> you give them a way to point into the compat m2p table. >>>> >>> >>> I'll probably switch to uint64_t for the v4v mfn list instead of using >>> xen_pfn_t which >>> are unsigned long. That way I can save the need for a compat wrapper. >> >> But that comment of yours doesn't address the problem I pointed >> out. >> > > I'm sorry, I don't really get what you mean them. I've tried to get > all my struct > layout such as all the offset for the field are the same for 64b and 32b, > this > way I thought I could get away with doing a compat wrapper. guest_handle_okay() simply isn't suitable for checking compat mode pointers - compat_handle_okay() needs to be used for them instead. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 15:12:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 15:12:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn5R-0007ut-8K; Thu, 04 Oct 2012 15:11:41 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn5P-0007um-Iz for xen-devel@lists.xen.org; Thu, 04 Oct 2012 15:11:39 +0000 Received: from [85.158.143.99:30628] by server-3.bemta-4.messagelabs.com id E0/76-10986-A27AD605; Thu, 04 Oct 2012 15:11:38 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1349363498!27589072!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24308 invoked from network); 4 Oct 2012 15:11:38 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 15:11:38 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="14945005" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 15:11:37 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 16:11:37 +0100 Message-ID: <1349363496.866.49.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Konrad Rzeszutek Wilk , Mukesh Rathor , Stefano Stabellini Date: Thu, 4 Oct 2012 16:11:36 +0100 Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: xen-devel Subject: [Xen-devel] [RFC 00/14] arm: implement ballooning and privcmd foreign mappings based on x86 PVH X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This series implements ballooning for Xen on ARM and builds and Mukesh's PVH privcmd stuff to implement foreign page mapping on ARM, replacing the old "HACK: initial (very hacky) XENMAPSPACE_gmfn_foreign" patch. The baseline is a bit complex, it is basically Stefano's xenarm-forlinus branch (commit bbd6eb29214e) merged with Konrad's linux-next-pvh branch (commit 7e6e6f589de8). I suspect I might need to rebase it shortly. I know there's a bunch of stuff in here which Mukesh has also changed, but which I haven't seen yet, I'll deal with that when I rebase (RFC mainly for that reason only). This lets me start a guest without any of those nasty patches with "HACK" in the title ;-0 Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 15:12:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 15:12:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn5R-0007ut-8K; Thu, 04 Oct 2012 15:11:41 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn5P-0007um-Iz for xen-devel@lists.xen.org; Thu, 04 Oct 2012 15:11:39 +0000 Received: from [85.158.143.99:30628] by server-3.bemta-4.messagelabs.com id E0/76-10986-A27AD605; Thu, 04 Oct 2012 15:11:38 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1349363498!27589072!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24308 invoked from network); 4 Oct 2012 15:11:38 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 15:11:38 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="14945005" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 15:11:37 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 16:11:37 +0100 Message-ID: <1349363496.866.49.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Konrad Rzeszutek Wilk , Mukesh Rathor , Stefano Stabellini Date: Thu, 4 Oct 2012 16:11:36 +0100 Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: xen-devel Subject: [Xen-devel] [RFC 00/14] arm: implement ballooning and privcmd foreign mappings based on x86 PVH X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This series implements ballooning for Xen on ARM and builds and Mukesh's PVH privcmd stuff to implement foreign page mapping on ARM, replacing the old "HACK: initial (very hacky) XENMAPSPACE_gmfn_foreign" patch. The baseline is a bit complex, it is basically Stefano's xenarm-forlinus branch (commit bbd6eb29214e) merged with Konrad's linux-next-pvh branch (commit 7e6e6f589de8). I suspect I might need to rebase it shortly. I know there's a bunch of stuff in here which Mukesh has also changed, but which I haven't seen yet, I'll deal with that when I rebase (RFC mainly for that reason only). This lets me start a guest without any of those nasty patches with "HACK" in the title ;-0 Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 15:12:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 15:12:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn5p-0007xm-VB; Thu, 04 Oct 2012 15:12:05 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn5n-0007wi-Mb for xen-devel@lists.xen.org; Thu, 04 Oct 2012 15:12:03 +0000 Received: from [85.158.139.211:34357] by server-7.bemta-5.messagelabs.com id 61/DF-00431-247AD605; Thu, 04 Oct 2012 15:12:02 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-206.messagelabs.com!1349363519!21075191!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODAxODI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25395 invoked from network); 4 Oct 2012 15:12:02 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 15:12:02 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="210303840" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 15:11:56 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 11:11:55 -0400 Received: from drall.uk.xensource.com ([10.80.227.107]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJn5f-0002L6-Je; Thu, 04 Oct 2012 16:11:55 +0100 From: Ian Campbell To: Konrad Rzeszutek Wilk , Stefano Stabellini , Mukesh Rathor Date: Thu, 4 Oct 2012 16:11:47 +0100 Message-ID: <1349363515-26190-6-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1349363496.866.49.camel@zakaz.uk.xensource.com> References: <1349363496.866.49.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Ian Campbell , xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH 06/14] arm: make p2m operations NOPs X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This makes common code less ifdef-y and is consistent with PVHVM on x86. Also note that phys_to_machine_mapping_valid should take a pfn argument and make it do so. Add __set_phys_to_machine, make set_phys_to_machine a simple wrapper (on systems with non-nop implementations the outer one can allocate new p2m pages). Make __set_phys_to_machine check for identity mapping or invalid only. Signed-off-by: Ian Campbell --- arch/arm/include/asm/xen/page.h | 13 ++++++++++--- drivers/xen/balloon.c | 2 +- 2 files changed, 11 insertions(+), 4 deletions(-) diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h index 1742023..c6b9096 100644 --- a/arch/arm/include/asm/xen/page.h +++ b/arch/arm/include/asm/xen/page.h @@ -10,7 +10,7 @@ #include #define pfn_to_mfn(pfn) (pfn) -#define phys_to_machine_mapping_valid (1) +#define phys_to_machine_mapping_valid(pfn) (1) #define mfn_to_pfn(mfn) (mfn) #define mfn_to_virt(m) (__va(mfn_to_pfn(m) << PAGE_SHIFT)) @@ -30,6 +30,8 @@ typedef struct xpaddr { #define XMADDR(x) ((xmaddr_t) { .maddr = (x) }) #define XPADDR(x) ((xpaddr_t) { .paddr = (x) }) +#define INVALID_P2M_ENTRY (~0UL) + static inline xmaddr_t phys_to_machine(xpaddr_t phys) { unsigned offset = phys.paddr & ~PAGE_MASK; @@ -74,9 +76,14 @@ static inline int m2p_remove_override(struct page *page, bool clear_pte) return 0; } +static inline bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn) +{ + BUG_ON(pfn != mfn && mfn != INVALID_P2M_ENTRY); + return true; +} + static inline bool set_phys_to_machine(unsigned long pfn, unsigned long mfn) { - BUG(); - return false; + return __set_phys_to_machine(pfn, mfn); } #endif /* _ASM_ARM_XEN_PAGE_H */ diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c index 4625560..7885a19 100644 --- a/drivers/xen/balloon.c +++ b/drivers/xen/balloon.c @@ -452,7 +452,7 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp) /* No more mappings: invalidate P2M and add to balloon. */ for (i = 0; i < nr_pages; i++) { pfn = mfn_to_pfn(frame_list[i]); - /* PVH note: following will noop for auto translated */ + /* The following is a noop for auto translated */ __set_phys_to_machine(pfn, INVALID_P2M_ENTRY); balloon_append(pfn_to_page(pfn)); } -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 15:12:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 15:12:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn5p-0007xm-VB; Thu, 04 Oct 2012 15:12:05 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn5n-0007wi-Mb for xen-devel@lists.xen.org; Thu, 04 Oct 2012 15:12:03 +0000 Received: from [85.158.139.211:34357] by server-7.bemta-5.messagelabs.com id 61/DF-00431-247AD605; Thu, 04 Oct 2012 15:12:02 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-206.messagelabs.com!1349363519!21075191!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODAxODI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25395 invoked from network); 4 Oct 2012 15:12:02 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 15:12:02 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="210303840" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 15:11:56 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 11:11:55 -0400 Received: from drall.uk.xensource.com ([10.80.227.107]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJn5f-0002L6-Je; Thu, 04 Oct 2012 16:11:55 +0100 From: Ian Campbell To: Konrad Rzeszutek Wilk , Stefano Stabellini , Mukesh Rathor Date: Thu, 4 Oct 2012 16:11:47 +0100 Message-ID: <1349363515-26190-6-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1349363496.866.49.camel@zakaz.uk.xensource.com> References: <1349363496.866.49.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Ian Campbell , xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH 06/14] arm: make p2m operations NOPs X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This makes common code less ifdef-y and is consistent with PVHVM on x86. Also note that phys_to_machine_mapping_valid should take a pfn argument and make it do so. Add __set_phys_to_machine, make set_phys_to_machine a simple wrapper (on systems with non-nop implementations the outer one can allocate new p2m pages). Make __set_phys_to_machine check for identity mapping or invalid only. Signed-off-by: Ian Campbell --- arch/arm/include/asm/xen/page.h | 13 ++++++++++--- drivers/xen/balloon.c | 2 +- 2 files changed, 11 insertions(+), 4 deletions(-) diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h index 1742023..c6b9096 100644 --- a/arch/arm/include/asm/xen/page.h +++ b/arch/arm/include/asm/xen/page.h @@ -10,7 +10,7 @@ #include #define pfn_to_mfn(pfn) (pfn) -#define phys_to_machine_mapping_valid (1) +#define phys_to_machine_mapping_valid(pfn) (1) #define mfn_to_pfn(mfn) (mfn) #define mfn_to_virt(m) (__va(mfn_to_pfn(m) << PAGE_SHIFT)) @@ -30,6 +30,8 @@ typedef struct xpaddr { #define XMADDR(x) ((xmaddr_t) { .maddr = (x) }) #define XPADDR(x) ((xpaddr_t) { .paddr = (x) }) +#define INVALID_P2M_ENTRY (~0UL) + static inline xmaddr_t phys_to_machine(xpaddr_t phys) { unsigned offset = phys.paddr & ~PAGE_MASK; @@ -74,9 +76,14 @@ static inline int m2p_remove_override(struct page *page, bool clear_pte) return 0; } +static inline bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn) +{ + BUG_ON(pfn != mfn && mfn != INVALID_P2M_ENTRY); + return true; +} + static inline bool set_phys_to_machine(unsigned long pfn, unsigned long mfn) { - BUG(); - return false; + return __set_phys_to_machine(pfn, mfn); } #endif /* _ASM_ARM_XEN_PAGE_H */ diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c index 4625560..7885a19 100644 --- a/drivers/xen/balloon.c +++ b/drivers/xen/balloon.c @@ -452,7 +452,7 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp) /* No more mappings: invalidate P2M and add to balloon. */ for (i = 0; i < nr_pages; i++) { pfn = mfn_to_pfn(frame_list[i]); - /* PVH note: following will noop for auto translated */ + /* The following is a noop for auto translated */ __set_phys_to_machine(pfn, INVALID_P2M_ENTRY); balloon_append(pfn_to_page(pfn)); } -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 15:12:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 15:12:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn5u-00080H-Bq; Thu, 04 Oct 2012 15:12:10 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn5t-0007wo-0E for xen-devel@lists.xen.org; Thu, 04 Oct 2012 15:12:09 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1349363516!9745618!5 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODAxODI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 469 invoked from network); 4 Oct 2012 15:12:02 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 15:12:02 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="210303841" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 15:11:56 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 11:11:55 -0400 Received: from drall.uk.xensource.com ([10.80.227.107]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJn5f-0002L6-Ht; Thu, 04 Oct 2012 16:11:55 +0100 From: Ian Campbell To: Konrad Rzeszutek Wilk , Stefano Stabellini , Mukesh Rathor Date: Thu, 4 Oct 2012 16:11:46 +0100 Message-ID: <1349363515-26190-5-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1349363496.866.49.camel@zakaz.uk.xensource.com> References: <1349363496.866.49.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Ian Campbell , xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH 05/14] xen: balloon: use correct type for frame_list X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is now a xen_pfn_t. Signed-off-by: Ian Campbell --- drivers/xen/balloon.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c index 85ef7e7..4625560 100644 --- a/drivers/xen/balloon.c +++ b/drivers/xen/balloon.c @@ -87,7 +87,7 @@ struct balloon_stats balloon_stats; EXPORT_SYMBOL_GPL(balloon_stats); /* We increase/decrease in batches which fit in a page */ -static unsigned long frame_list[PAGE_SIZE / sizeof(unsigned long)]; +static xen_pfn_t frame_list[PAGE_SIZE / sizeof(unsigned long)]; #ifdef CONFIG_HIGHMEM #define inc_totalhigh_pages() (totalhigh_pages++) -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 15:12:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 15:12:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn5t-0007zw-W4; Thu, 04 Oct 2012 15:12:09 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn5s-0007we-64 for xen-devel@lists.xen.org; Thu, 04 Oct 2012 15:12:08 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1349363516!9745618!4 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODAxODI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 363 invoked from network); 4 Oct 2012 15:12:01 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 15:12:01 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="210303839" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 15:11:56 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 11:11:55 -0400 Received: from drall.uk.xensource.com ([10.80.227.107]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJn5f-0002L6-LO; Thu, 04 Oct 2012 16:11:55 +0100 From: Ian Campbell To: Konrad Rzeszutek Wilk , Stefano Stabellini , Mukesh Rathor Date: Thu, 4 Oct 2012 16:11:48 +0100 Message-ID: <1349363515-26190-7-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1349363496.866.49.camel@zakaz.uk.xensource.com> References: <1349363496.866.49.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Ian Campbell , xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH 07/14] xen: balloon: do not update stage 1 pagetable for autotranslated guests X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is unnecessary (since the page will be removed from the p2m) and can be tricky if the page is in the middle of a superpage, as it is on ARM. Signed-off-by: Ian Campbell --- Also effects PVH but in a benign way I think. --- drivers/xen/balloon.c | 23 +++-------------------- 1 files changed, 3 insertions(+), 20 deletions(-) diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c index 7885a19..1b56ae0 100644 --- a/drivers/xen/balloon.c +++ b/drivers/xen/balloon.c @@ -357,15 +357,7 @@ static enum bp_state increase_reservation(unsigned long nr_pages) BUG_ON(!xen_feature(XENFEAT_auto_translated_physmap) && phys_to_machine_mapping_valid(pfn)); - if (xen_pv_domain() && - xen_feature(XENFEAT_auto_translated_physmap)) { - /* PVH: we just need to update native page table */ - pte_t *ptep; - unsigned int level; - void *addr = __va(pfn << PAGE_SHIFT); - ptep = lookup_address((unsigned long)addr, &level); - set_pte(ptep, pfn_pte(pfn, PAGE_KERNEL)); - } else + if (!xen_feature(XENFEAT_auto_translated_physmap)) set_phys_to_machine(pfn, frame_list[i]); /* Link back into the page tables if not highmem. */ @@ -427,21 +419,12 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp) scrub_page(page); - if (xen_pv_domain() && !PageHighMem(page)) { - if (xen_feature(XENFEAT_auto_translated_physmap)) { - unsigned int level; - pte_t *ptep; - void *addr = __va(pfn << PAGE_SHIFT); - ptep = lookup_address((unsigned long)addr, - &level); - set_pte(ptep, __pte(0)); - - } else { + if (xen_pv_domain() && !PageHighMem(page) && + !xen_feature(XENFEAT_auto_translated_physmap)) { ret = HYPERVISOR_update_va_mapping( (unsigned long)__va(pfn << PAGE_SHIFT), __pte_ma(0), 0); BUG_ON(ret); - } } } -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 15:12:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 15:12:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn5u-00080H-Bq; Thu, 04 Oct 2012 15:12:10 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn5t-0007wo-0E for xen-devel@lists.xen.org; Thu, 04 Oct 2012 15:12:09 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1349363516!9745618!5 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODAxODI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 469 invoked from network); 4 Oct 2012 15:12:02 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 15:12:02 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="210303841" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 15:11:56 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 11:11:55 -0400 Received: from drall.uk.xensource.com ([10.80.227.107]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJn5f-0002L6-Ht; Thu, 04 Oct 2012 16:11:55 +0100 From: Ian Campbell To: Konrad Rzeszutek Wilk , Stefano Stabellini , Mukesh Rathor Date: Thu, 4 Oct 2012 16:11:46 +0100 Message-ID: <1349363515-26190-5-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1349363496.866.49.camel@zakaz.uk.xensource.com> References: <1349363496.866.49.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Ian Campbell , xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH 05/14] xen: balloon: use correct type for frame_list X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is now a xen_pfn_t. Signed-off-by: Ian Campbell --- drivers/xen/balloon.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c index 85ef7e7..4625560 100644 --- a/drivers/xen/balloon.c +++ b/drivers/xen/balloon.c @@ -87,7 +87,7 @@ struct balloon_stats balloon_stats; EXPORT_SYMBOL_GPL(balloon_stats); /* We increase/decrease in batches which fit in a page */ -static unsigned long frame_list[PAGE_SIZE / sizeof(unsigned long)]; +static xen_pfn_t frame_list[PAGE_SIZE / sizeof(unsigned long)]; #ifdef CONFIG_HIGHMEM #define inc_totalhigh_pages() (totalhigh_pages++) -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 15:12:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 15:12:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn5t-0007zw-W4; Thu, 04 Oct 2012 15:12:09 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn5s-0007we-64 for xen-devel@lists.xen.org; Thu, 04 Oct 2012 15:12:08 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1349363516!9745618!4 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODAxODI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 363 invoked from network); 4 Oct 2012 15:12:01 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 15:12:01 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="210303839" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 15:11:56 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 11:11:55 -0400 Received: from drall.uk.xensource.com ([10.80.227.107]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJn5f-0002L6-LO; Thu, 04 Oct 2012 16:11:55 +0100 From: Ian Campbell To: Konrad Rzeszutek Wilk , Stefano Stabellini , Mukesh Rathor Date: Thu, 4 Oct 2012 16:11:48 +0100 Message-ID: <1349363515-26190-7-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1349363496.866.49.camel@zakaz.uk.xensource.com> References: <1349363496.866.49.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Ian Campbell , xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH 07/14] xen: balloon: do not update stage 1 pagetable for autotranslated guests X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is unnecessary (since the page will be removed from the p2m) and can be tricky if the page is in the middle of a superpage, as it is on ARM. Signed-off-by: Ian Campbell --- Also effects PVH but in a benign way I think. --- drivers/xen/balloon.c | 23 +++-------------------- 1 files changed, 3 insertions(+), 20 deletions(-) diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c index 7885a19..1b56ae0 100644 --- a/drivers/xen/balloon.c +++ b/drivers/xen/balloon.c @@ -357,15 +357,7 @@ static enum bp_state increase_reservation(unsigned long nr_pages) BUG_ON(!xen_feature(XENFEAT_auto_translated_physmap) && phys_to_machine_mapping_valid(pfn)); - if (xen_pv_domain() && - xen_feature(XENFEAT_auto_translated_physmap)) { - /* PVH: we just need to update native page table */ - pte_t *ptep; - unsigned int level; - void *addr = __va(pfn << PAGE_SHIFT); - ptep = lookup_address((unsigned long)addr, &level); - set_pte(ptep, pfn_pte(pfn, PAGE_KERNEL)); - } else + if (!xen_feature(XENFEAT_auto_translated_physmap)) set_phys_to_machine(pfn, frame_list[i]); /* Link back into the page tables if not highmem. */ @@ -427,21 +419,12 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp) scrub_page(page); - if (xen_pv_domain() && !PageHighMem(page)) { - if (xen_feature(XENFEAT_auto_translated_physmap)) { - unsigned int level; - pte_t *ptep; - void *addr = __va(pfn << PAGE_SHIFT); - ptep = lookup_address((unsigned long)addr, - &level); - set_pte(ptep, __pte(0)); - - } else { + if (xen_pv_domain() && !PageHighMem(page) && + !xen_feature(XENFEAT_auto_translated_physmap)) { ret = HYPERVISOR_update_va_mapping( (unsigned long)__va(pfn << PAGE_SHIFT), __pte_ma(0), 0); BUG_ON(ret); - } } } -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 15:12:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 15:12:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn5o-0007x2-LO; Thu, 04 Oct 2012 15:12:04 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn5m-0007wR-CV for xen-devel@lists.xen.org; Thu, 04 Oct 2012 15:12:02 +0000 Received: from [85.158.137.99:61670] by server-15.bemta-3.messagelabs.com id 7F/9A-11584-147AD605; Thu, 04 Oct 2012 15:12:01 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-217.messagelabs.com!1349363517!17137968!2 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQyMDg=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31930 invoked from network); 4 Oct 2012 15:12:00 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 15:12:00 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="40152203" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 15:11:56 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 11:11:56 -0400 Received: from drall.uk.xensource.com ([10.80.227.107]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJn5f-0002L6-Ls; Thu, 04 Oct 2012 16:11:55 +0100 From: Ian Campbell To: Konrad Rzeszutek Wilk , Stefano Stabellini , Mukesh Rathor Date: Thu, 4 Oct 2012 16:11:49 +0100 Message-ID: <1349363515-26190-8-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1349363496.866.49.camel@zakaz.uk.xensource.com> References: <1349363496.866.49.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Ian Campbell , xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH 08/14] xen: balloon: allow PVMMU interfaces to be compiled out X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org The ARM platform has no concept of PVMMU and therefor no HYPERVISOR_update_va_mapping et al. Allow this code to be compiled out when not required. Signed-off-by: Ian Campbell --- arch/x86/xen/Kconfig | 1 + drivers/xen/Kconfig | 3 +++ drivers/xen/balloon.c | 4 ++++ 3 files changed, 8 insertions(+), 0 deletions(-) diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig index fdce49c..c31ee77 100644 --- a/arch/x86/xen/Kconfig +++ b/arch/x86/xen/Kconfig @@ -6,6 +6,7 @@ config XEN bool "Xen guest support" select PARAVIRT select PARAVIRT_CLOCK + select XEN_HAVE_PVMMU depends on X86_64 || (X86_32 && X86_PAE && !X86_VISWS) depends on X86_CMPXCHG && X86_TSC help diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig index d4dffcd..9c00652 100644 --- a/drivers/xen/Kconfig +++ b/drivers/xen/Kconfig @@ -204,4 +204,7 @@ config XEN_MCE_LOG Allow kernel fetching MCE error from Xen platform and converting it into Linux mcelog format for mcelog tools +config XEN_HAVE_PVMMU + bool + endmenu diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c index 1b56ae0..cfe47dae 100644 --- a/drivers/xen/balloon.c +++ b/drivers/xen/balloon.c @@ -360,6 +360,7 @@ static enum bp_state increase_reservation(unsigned long nr_pages) if (!xen_feature(XENFEAT_auto_translated_physmap)) set_phys_to_machine(pfn, frame_list[i]); +#ifdef CONFIG_XEN_HAVE_PVMMU /* Link back into the page tables if not highmem. */ if (xen_pv_domain() && !PageHighMem(page) && !xen_feature(XENFEAT_auto_translated_physmap)) { @@ -371,6 +372,7 @@ static enum bp_state increase_reservation(unsigned long nr_pages) 0); BUG_ON(ret); } +#endif /* Relinquish the page back to the allocator. */ ClearPageReserved(page); @@ -419,6 +421,7 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp) scrub_page(page); +#ifdef CONFIG_XEN_HAVE_PVMMU if (xen_pv_domain() && !PageHighMem(page) && !xen_feature(XENFEAT_auto_translated_physmap)) { ret = HYPERVISOR_update_va_mapping( @@ -426,6 +429,7 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp) __pte_ma(0), 0); BUG_ON(ret); } +#endif } /* Ensure that ballooned highmem pages don't have kmaps. */ -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 15:12:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 15:12:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn5o-0007x2-LO; Thu, 04 Oct 2012 15:12:04 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn5m-0007wR-CV for xen-devel@lists.xen.org; Thu, 04 Oct 2012 15:12:02 +0000 Received: from [85.158.137.99:61670] by server-15.bemta-3.messagelabs.com id 7F/9A-11584-147AD605; Thu, 04 Oct 2012 15:12:01 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-217.messagelabs.com!1349363517!17137968!2 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQyMDg=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31930 invoked from network); 4 Oct 2012 15:12:00 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 15:12:00 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="40152203" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 15:11:56 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 11:11:56 -0400 Received: from drall.uk.xensource.com ([10.80.227.107]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJn5f-0002L6-Ls; Thu, 04 Oct 2012 16:11:55 +0100 From: Ian Campbell To: Konrad Rzeszutek Wilk , Stefano Stabellini , Mukesh Rathor Date: Thu, 4 Oct 2012 16:11:49 +0100 Message-ID: <1349363515-26190-8-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1349363496.866.49.camel@zakaz.uk.xensource.com> References: <1349363496.866.49.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Ian Campbell , xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH 08/14] xen: balloon: allow PVMMU interfaces to be compiled out X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org The ARM platform has no concept of PVMMU and therefor no HYPERVISOR_update_va_mapping et al. Allow this code to be compiled out when not required. Signed-off-by: Ian Campbell --- arch/x86/xen/Kconfig | 1 + drivers/xen/Kconfig | 3 +++ drivers/xen/balloon.c | 4 ++++ 3 files changed, 8 insertions(+), 0 deletions(-) diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig index fdce49c..c31ee77 100644 --- a/arch/x86/xen/Kconfig +++ b/arch/x86/xen/Kconfig @@ -6,6 +6,7 @@ config XEN bool "Xen guest support" select PARAVIRT select PARAVIRT_CLOCK + select XEN_HAVE_PVMMU depends on X86_64 || (X86_32 && X86_PAE && !X86_VISWS) depends on X86_CMPXCHG && X86_TSC help diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig index d4dffcd..9c00652 100644 --- a/drivers/xen/Kconfig +++ b/drivers/xen/Kconfig @@ -204,4 +204,7 @@ config XEN_MCE_LOG Allow kernel fetching MCE error from Xen platform and converting it into Linux mcelog format for mcelog tools +config XEN_HAVE_PVMMU + bool + endmenu diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c index 1b56ae0..cfe47dae 100644 --- a/drivers/xen/balloon.c +++ b/drivers/xen/balloon.c @@ -360,6 +360,7 @@ static enum bp_state increase_reservation(unsigned long nr_pages) if (!xen_feature(XENFEAT_auto_translated_physmap)) set_phys_to_machine(pfn, frame_list[i]); +#ifdef CONFIG_XEN_HAVE_PVMMU /* Link back into the page tables if not highmem. */ if (xen_pv_domain() && !PageHighMem(page) && !xen_feature(XENFEAT_auto_translated_physmap)) { @@ -371,6 +372,7 @@ static enum bp_state increase_reservation(unsigned long nr_pages) 0); BUG_ON(ret); } +#endif /* Relinquish the page back to the allocator. */ ClearPageReserved(page); @@ -419,6 +421,7 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp) scrub_page(page); +#ifdef CONFIG_XEN_HAVE_PVMMU if (xen_pv_domain() && !PageHighMem(page) && !xen_feature(XENFEAT_auto_translated_physmap)) { ret = HYPERVISOR_update_va_mapping( @@ -426,6 +429,7 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp) __pte_ma(0), 0); BUG_ON(ret); } +#endif } /* Ensure that ballooned highmem pages don't have kmaps. */ -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 15:12:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 15:12:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn5p-0007xJ-E9; Thu, 04 Oct 2012 15:12:05 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn5m-0007wU-Rx for xen-devel@lists.xen.org; Thu, 04 Oct 2012 15:12:03 +0000 Received: from [85.158.139.211:56918] by server-12.bemta-5.messagelabs.com id CF/B9-03829-247AD605; Thu, 04 Oct 2012 15:12:02 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-206.messagelabs.com!1349363519!21075191!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODAxODI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25304 invoked from network); 4 Oct 2012 15:12:01 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 15:12:01 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="210303838" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 15:11:56 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 11:11:55 -0400 Received: from drall.uk.xensource.com ([10.80.227.107]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJn5f-0002L6-FW; Thu, 04 Oct 2012 16:11:55 +0100 From: Ian Campbell To: Konrad Rzeszutek Wilk , Stefano Stabellini , Mukesh Rathor Date: Thu, 4 Oct 2012 16:11:44 +0100 Message-ID: <1349363515-26190-3-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1349363496.866.49.camel@zakaz.uk.xensource.com> References: <1349363496.866.49.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Ian Campbell , xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH 03/14] xen events: xen_callback_vector is x86 specific X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Ian Campbell --- Should instead move somewhere arch specific? --- drivers/xen/events.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/xen/events.c b/drivers/xen/events.c index 6f55ef2..2508981 100644 --- a/drivers/xen/events.c +++ b/drivers/xen/events.c @@ -1775,6 +1775,7 @@ int xen_set_callback_via(uint64_t via) EXPORT_SYMBOL_GPL(xen_set_callback_via); +#ifdef CONFIG_X86 /* Vector callbacks are better than PCI interrupts to receive event * channel notifications because we can receive vector callbacks on any * vcpu and we don't need PCI support or APIC interactions. */ @@ -1798,6 +1799,9 @@ void xen_callback_vector(void) alloc_intr_gate(XEN_HVM_EVTCHN_CALLBACK, xen_hvm_callback_vector); } } +#else +void xen_callback_vector(void) {} +#endif void xen_init_IRQ(void) { -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 15:12:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 15:12:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn5p-0007xB-1C; Thu, 04 Oct 2012 15:12:05 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn5m-0007wP-CO for xen-devel@lists.xen.org; Thu, 04 Oct 2012 15:12:02 +0000 Received: from [85.158.137.99:42621] by server-6.bemta-3.messagelabs.com id 54/14-11085-047AD605; Thu, 04 Oct 2012 15:12:00 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-217.messagelabs.com!1349363517!17137968!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQyMDg=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31796 invoked from network); 4 Oct 2012 15:11:59 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 15:11:59 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="40152204" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 15:11:56 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 11:11:56 -0400 Received: from drall.uk.xensource.com ([10.80.227.107]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJn5f-0002L6-Ng; Thu, 04 Oct 2012 16:11:55 +0100 From: Ian Campbell To: Konrad Rzeszutek Wilk , Stefano Stabellini , Mukesh Rathor Date: Thu, 4 Oct 2012 16:11:50 +0100 Message-ID: <1349363515-26190-9-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1349363496.866.49.camel@zakaz.uk.xensource.com> References: <1349363496.866.49.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Ian Campbell , xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH 09/14] xen: arm: enable balloon driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Drop the *_xenballloned_pages duplicates since these are now supplied by the balloon code. Signed-off-by: Ian Campbell --- arch/arm/xen/enlighten.c | 23 +++++------------------ drivers/xen/Makefile | 4 ++-- drivers/xen/privcmd.c | 9 ++++----- 3 files changed, 11 insertions(+), 25 deletions(-) diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c index 59bcb96..ba5cc13 100644 --- a/arch/arm/xen/enlighten.c +++ b/arch/arm/xen/enlighten.c @@ -8,6 +8,7 @@ #include #include #include +#include #include #include #include @@ -29,6 +30,10 @@ struct shared_info *HYPERVISOR_shared_info = (void *)&xen_dummy_shared_info; DEFINE_PER_CPU(struct vcpu_info *, xen_vcpu); +/* These are unused until we support booting "pre-ballooned" */ +unsigned long xen_released_pages; +struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata; + /* TODO: to be removed */ __read_mostly int xen_have_vector_callback; EXPORT_SYMBOL_GPL(xen_have_vector_callback); @@ -148,21 +153,3 @@ static int __init xen_init_events(void) return 0; } postcore_initcall(xen_init_events); - -/* XXX: only until balloon is properly working */ -int alloc_xenballooned_pages(int nr_pages, struct page **pages, bool highmem) -{ - *pages = alloc_pages(highmem ? GFP_HIGHUSER : GFP_KERNEL, - get_order(nr_pages)); - if (*pages == NULL) - return -ENOMEM; - return 0; -} -EXPORT_SYMBOL_GPL(alloc_xenballooned_pages); - -void free_xenballooned_pages(int nr_pages, struct page **pages) -{ - kfree(*pages); - *pages = NULL; -} -EXPORT_SYMBOL_GPL(free_xenballooned_pages); diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile index 275abfc..9a7896f 100644 --- a/drivers/xen/Makefile +++ b/drivers/xen/Makefile @@ -1,8 +1,8 @@ ifneq ($(CONFIG_ARM),y) -obj-y += manage.o balloon.o +obj-y += manage.o obj-$(CONFIG_HOTPLUG_CPU) += cpu_hotplug.o endif -obj-y += grant-table.o features.o events.o +obj-y += grant-table.o features.o events.o balloon.o obj-y += xenbus/ nostackp := $(call cc-option, -fno-stack-protector) diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c index 1010bf7..bf4d62a 100644 --- a/drivers/xen/privcmd.c +++ b/drivers/xen/privcmd.c @@ -200,8 +200,8 @@ static long privcmd_ioctl_mmap(void __user *udata) if (!xen_initial_domain()) return -EPERM; - /* PVH: TBD/FIXME. For now we only support privcmd_ioctl_mmap_batch */ - if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap)) + /* We only support privcmd_ioctl_mmap_batch for auto translated. */ + if (xen_feature(XENFEAT_auto_translated_physmap)) return -ENOSYS; if (copy_from_user(&mmapcmd, udata, sizeof(mmapcmd))) @@ -413,7 +413,7 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version) up_write(&mm->mmap_sem); goto out; } - if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap)) { + if (xen_feature(XENFEAT_auto_translated_physmap)) { if ((ret = pvh_privcmd_resv_pfns(vma, m.num))) { up_write(&mm->mmap_sem); goto out; @@ -492,8 +492,7 @@ static void privcmd_close(struct vm_area_struct *vma) int count; struct xen_pvh_pfn_info *pvhp = vma ? vma->vm_private_data : NULL; - if (!xen_pv_domain() || !pvhp || - !xen_feature(XENFEAT_auto_translated_physmap)) + if (!pvhp || !xen_feature(XENFEAT_auto_translated_physmap)) return; count = xen_unmap_domain_mfn_range(vma, pvhp); -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 15:12:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 15:12:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn5q-0007xy-CR; Thu, 04 Oct 2012 15:12:06 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn5o-0007wU-59 for xen-devel@lists.xen.org; Thu, 04 Oct 2012 15:12:04 +0000 Received: from [85.158.139.211:4864] by server-12.bemta-5.messagelabs.com id 66/D9-03829-347AD605; Thu, 04 Oct 2012 15:12:03 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-206.messagelabs.com!1349363519!21075191!3 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODAxODI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25454 invoked from network); 4 Oct 2012 15:12:02 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 15:12:02 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="210303842" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 15:11:56 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 11:11:56 -0400 Received: from drall.uk.xensource.com ([10.80.227.107]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJn5f-0002L6-OE; Thu, 04 Oct 2012 16:11:55 +0100 From: Ian Campbell To: Konrad Rzeszutek Wilk , Stefano Stabellini , Mukesh Rathor Date: Thu, 4 Oct 2012 16:11:51 +0100 Message-ID: <1349363515-26190-10-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1349363496.866.49.camel@zakaz.uk.xensource.com> References: <1349363496.866.49.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Ian Campbell , xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH 10/14] privcmd: refer to autotranslate not PVH in arch interfaces / comments. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org PVH is X86 specific while this functionality is also used on ARM. Signed-off-by: Ian Campbell --- arch/x86/xen/mmu.c | 10 +++++----- drivers/xen/privcmd.c | 46 ++++++++++++++++++++++------------------------ include/xen/xen-ops.h | 8 ++++---- 3 files changed, 31 insertions(+), 33 deletions(-) diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c index 26097cb..3e781f9 100644 --- a/arch/x86/xen/mmu.c +++ b/arch/x86/xen/mmu.c @@ -2506,7 +2506,7 @@ struct pvh_remap_data { unsigned long fgmfn; /* foreign domain's gmfn */ pgprot_t prot; domid_t domid; - struct xen_pvh_pfn_info *pvhinfop; + struct xen_remap_mfn_info *pvhinfop; }; static int pvh_map_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr, @@ -2514,7 +2514,7 @@ static int pvh_map_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr, { int rc; struct pvh_remap_data *remapp = data; - struct xen_pvh_pfn_info *pvhp = remapp->pvhinfop; + struct xen_remap_mfn_info *pvhp = remapp->pvhinfop; unsigned long pfn = page_to_pfn(pvhp->pi_paga[pvhp->pi_next_todo++]); pte_t pteval = pte_mkspecial(pfn_pte(pfn, remapp->prot)); @@ -2531,7 +2531,7 @@ static int pvh_map_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr, static int pvh_remap_gmfn_range(struct vm_area_struct *vma, unsigned long addr, unsigned long mfn, int nr, pgprot_t prot, unsigned domid, - struct xen_pvh_pfn_info *pvhp) + struct xen_remap_mfn_info *pvhp) { int err; struct pvh_remap_data pvhdata; @@ -2574,7 +2574,7 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma, unsigned long addr, unsigned long mfn, int nr, pgprot_t prot, unsigned domid, - struct xen_pvh_pfn_info *pvhp) + struct xen_remap_mfn_info *pvhp) { struct remap_data rmd; @@ -2629,7 +2629,7 @@ EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range); /* Returns: Number of pages unmapped */ int xen_unmap_domain_mfn_range(struct vm_area_struct *vma, - struct xen_pvh_pfn_info *pvhp) + struct xen_remap_mfn_info *pvhp) { int count = 0; diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c index bf4d62a..ebf3c8d 100644 --- a/drivers/xen/privcmd.c +++ b/drivers/xen/privcmd.c @@ -265,18 +265,16 @@ struct mmap_batch_state { xen_pfn_t __user *user_mfn; }; -/* PVH dom0 fyi: if domU being created is PV, then mfn is mfn(addr on bus). If - * it's PVH then mfn is pfn (input to HAP). */ static int mmap_batch_fn(void *data, void *state) { xen_pfn_t *mfnp = data; struct mmap_batch_state *st = state; struct vm_area_struct *vma = st->vma; - struct xen_pvh_pfn_info *pvhp = vma ? vma->vm_private_data : NULL; + struct xen_remap_mfn_info *info = vma ? vma->vm_private_data : NULL; int ret; ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1, - st->vma->vm_page_prot, st->domain, pvhp); + st->vma->vm_page_prot, st->domain, info); /* Store error code for second pass. */ *(st->err++) = ret; @@ -315,33 +313,33 @@ static int mmap_return_errors_v1(void *data, void *state) /* Allocate pfns that are then mapped with gmfns from foreign domid. Update * the vma with the page info to use later. * Returns: 0 if success, otherwise -errno - */ -static int pvh_privcmd_resv_pfns(struct vm_area_struct *vma, int numpgs) + */ +static int alloc_empty_pages(struct vm_area_struct *vma, int numpgs) { int rc; - struct xen_pvh_pfn_info *pvhp; + struct xen_remap_mfn_info *info; - pvhp = kzalloc(sizeof(struct xen_pvh_pfn_info), GFP_KERNEL); - if (pvhp == NULL) + info = kzalloc(sizeof(struct xen_remap_mfn_info), GFP_KERNEL); + if (info == NULL) return -ENOMEM; - pvhp->pi_paga = kcalloc(numpgs, sizeof(pvhp->pi_paga[0]), GFP_KERNEL); - if (pvhp->pi_paga == NULL) { - kfree(pvhp); + info->pi_paga = kcalloc(numpgs, sizeof(info->pi_paga[0]), GFP_KERNEL); + if (info->pi_paga == NULL) { + kfree(info); return -ENOMEM; } - rc = alloc_xenballooned_pages(numpgs, pvhp->pi_paga, 0); + rc = alloc_xenballooned_pages(numpgs, info->pi_paga, 0); if (rc != 0) { pr_warn("%s Could not alloc %d pfns rc:%d\n", __FUNCTION__, numpgs, rc); - kfree(pvhp->pi_paga); - kfree(pvhp); + kfree(info->pi_paga); + kfree(info); return -ENOMEM; } - pvhp->pi_num_pgs = numpgs; + info->pi_num_pgs = numpgs; BUG_ON(vma->vm_private_data != (void *)1); - vma->vm_private_data = pvhp; + vma->vm_private_data = info; return 0; } @@ -414,7 +412,7 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version) goto out; } if (xen_feature(XENFEAT_auto_translated_physmap)) { - if ((ret = pvh_privcmd_resv_pfns(vma, m.num))) { + if ((ret = alloc_empty_pages(vma, m.num))) { up_write(&mm->mmap_sem); goto out; } @@ -490,16 +488,16 @@ static long privcmd_ioctl(struct file *file, static void privcmd_close(struct vm_area_struct *vma) { int count; - struct xen_pvh_pfn_info *pvhp = vma ? vma->vm_private_data : NULL; + struct xen_remap_mfn_info *info = vma ? vma->vm_private_data : NULL; - if (!pvhp || !xen_feature(XENFEAT_auto_translated_physmap)) + if (!info || !xen_feature(XENFEAT_auto_translated_physmap)) return; - count = xen_unmap_domain_mfn_range(vma, pvhp); + count = xen_unmap_domain_mfn_range(vma, info); while (count--) - free_xenballooned_pages(1, &pvhp->pi_paga[count]); - kfree(pvhp->pi_paga); - kfree(pvhp); + free_xenballooned_pages(1, &info->pi_paga[count]); + kfree(info->pi_paga); + kfree(info); } static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf) diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h index 6c5ad83..2f3cb06 100644 --- a/include/xen/xen-ops.h +++ b/include/xen/xen-ops.h @@ -24,16 +24,16 @@ int xen_create_contiguous_region(unsigned long vstart, unsigned int order, void xen_destroy_contiguous_region(unsigned long vstart, unsigned int order); struct vm_area_struct; -struct xen_pvh_pfn_info; +struct xen_remap_mfn_info; int xen_remap_domain_mfn_range(struct vm_area_struct *vma, unsigned long addr, unsigned long mfn, int nr, pgprot_t prot, unsigned domid, - struct xen_pvh_pfn_info *pvhp); + struct xen_remap_mfn_info *pvhp); int xen_unmap_domain_mfn_range(struct vm_area_struct *vma, - struct xen_pvh_pfn_info *pvhp); + struct xen_remap_mfn_info *pvhp); -struct xen_pvh_pfn_info { +struct xen_remap_mfn_info { struct page **pi_paga; /* pfn info page array */ int pi_num_pgs; int pi_next_todo; -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 15:12:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 15:12:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn5q-0007xy-CR; Thu, 04 Oct 2012 15:12:06 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn5o-0007wU-59 for xen-devel@lists.xen.org; Thu, 04 Oct 2012 15:12:04 +0000 Received: from [85.158.139.211:4864] by server-12.bemta-5.messagelabs.com id 66/D9-03829-347AD605; Thu, 04 Oct 2012 15:12:03 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-206.messagelabs.com!1349363519!21075191!3 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODAxODI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25454 invoked from network); 4 Oct 2012 15:12:02 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 15:12:02 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="210303842" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 15:11:56 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 11:11:56 -0400 Received: from drall.uk.xensource.com ([10.80.227.107]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJn5f-0002L6-OE; Thu, 04 Oct 2012 16:11:55 +0100 From: Ian Campbell To: Konrad Rzeszutek Wilk , Stefano Stabellini , Mukesh Rathor Date: Thu, 4 Oct 2012 16:11:51 +0100 Message-ID: <1349363515-26190-10-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1349363496.866.49.camel@zakaz.uk.xensource.com> References: <1349363496.866.49.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Ian Campbell , xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH 10/14] privcmd: refer to autotranslate not PVH in arch interfaces / comments. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org PVH is X86 specific while this functionality is also used on ARM. Signed-off-by: Ian Campbell --- arch/x86/xen/mmu.c | 10 +++++----- drivers/xen/privcmd.c | 46 ++++++++++++++++++++++------------------------ include/xen/xen-ops.h | 8 ++++---- 3 files changed, 31 insertions(+), 33 deletions(-) diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c index 26097cb..3e781f9 100644 --- a/arch/x86/xen/mmu.c +++ b/arch/x86/xen/mmu.c @@ -2506,7 +2506,7 @@ struct pvh_remap_data { unsigned long fgmfn; /* foreign domain's gmfn */ pgprot_t prot; domid_t domid; - struct xen_pvh_pfn_info *pvhinfop; + struct xen_remap_mfn_info *pvhinfop; }; static int pvh_map_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr, @@ -2514,7 +2514,7 @@ static int pvh_map_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr, { int rc; struct pvh_remap_data *remapp = data; - struct xen_pvh_pfn_info *pvhp = remapp->pvhinfop; + struct xen_remap_mfn_info *pvhp = remapp->pvhinfop; unsigned long pfn = page_to_pfn(pvhp->pi_paga[pvhp->pi_next_todo++]); pte_t pteval = pte_mkspecial(pfn_pte(pfn, remapp->prot)); @@ -2531,7 +2531,7 @@ static int pvh_map_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr, static int pvh_remap_gmfn_range(struct vm_area_struct *vma, unsigned long addr, unsigned long mfn, int nr, pgprot_t prot, unsigned domid, - struct xen_pvh_pfn_info *pvhp) + struct xen_remap_mfn_info *pvhp) { int err; struct pvh_remap_data pvhdata; @@ -2574,7 +2574,7 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma, unsigned long addr, unsigned long mfn, int nr, pgprot_t prot, unsigned domid, - struct xen_pvh_pfn_info *pvhp) + struct xen_remap_mfn_info *pvhp) { struct remap_data rmd; @@ -2629,7 +2629,7 @@ EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range); /* Returns: Number of pages unmapped */ int xen_unmap_domain_mfn_range(struct vm_area_struct *vma, - struct xen_pvh_pfn_info *pvhp) + struct xen_remap_mfn_info *pvhp) { int count = 0; diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c index bf4d62a..ebf3c8d 100644 --- a/drivers/xen/privcmd.c +++ b/drivers/xen/privcmd.c @@ -265,18 +265,16 @@ struct mmap_batch_state { xen_pfn_t __user *user_mfn; }; -/* PVH dom0 fyi: if domU being created is PV, then mfn is mfn(addr on bus). If - * it's PVH then mfn is pfn (input to HAP). */ static int mmap_batch_fn(void *data, void *state) { xen_pfn_t *mfnp = data; struct mmap_batch_state *st = state; struct vm_area_struct *vma = st->vma; - struct xen_pvh_pfn_info *pvhp = vma ? vma->vm_private_data : NULL; + struct xen_remap_mfn_info *info = vma ? vma->vm_private_data : NULL; int ret; ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1, - st->vma->vm_page_prot, st->domain, pvhp); + st->vma->vm_page_prot, st->domain, info); /* Store error code for second pass. */ *(st->err++) = ret; @@ -315,33 +313,33 @@ static int mmap_return_errors_v1(void *data, void *state) /* Allocate pfns that are then mapped with gmfns from foreign domid. Update * the vma with the page info to use later. * Returns: 0 if success, otherwise -errno - */ -static int pvh_privcmd_resv_pfns(struct vm_area_struct *vma, int numpgs) + */ +static int alloc_empty_pages(struct vm_area_struct *vma, int numpgs) { int rc; - struct xen_pvh_pfn_info *pvhp; + struct xen_remap_mfn_info *info; - pvhp = kzalloc(sizeof(struct xen_pvh_pfn_info), GFP_KERNEL); - if (pvhp == NULL) + info = kzalloc(sizeof(struct xen_remap_mfn_info), GFP_KERNEL); + if (info == NULL) return -ENOMEM; - pvhp->pi_paga = kcalloc(numpgs, sizeof(pvhp->pi_paga[0]), GFP_KERNEL); - if (pvhp->pi_paga == NULL) { - kfree(pvhp); + info->pi_paga = kcalloc(numpgs, sizeof(info->pi_paga[0]), GFP_KERNEL); + if (info->pi_paga == NULL) { + kfree(info); return -ENOMEM; } - rc = alloc_xenballooned_pages(numpgs, pvhp->pi_paga, 0); + rc = alloc_xenballooned_pages(numpgs, info->pi_paga, 0); if (rc != 0) { pr_warn("%s Could not alloc %d pfns rc:%d\n", __FUNCTION__, numpgs, rc); - kfree(pvhp->pi_paga); - kfree(pvhp); + kfree(info->pi_paga); + kfree(info); return -ENOMEM; } - pvhp->pi_num_pgs = numpgs; + info->pi_num_pgs = numpgs; BUG_ON(vma->vm_private_data != (void *)1); - vma->vm_private_data = pvhp; + vma->vm_private_data = info; return 0; } @@ -414,7 +412,7 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version) goto out; } if (xen_feature(XENFEAT_auto_translated_physmap)) { - if ((ret = pvh_privcmd_resv_pfns(vma, m.num))) { + if ((ret = alloc_empty_pages(vma, m.num))) { up_write(&mm->mmap_sem); goto out; } @@ -490,16 +488,16 @@ static long privcmd_ioctl(struct file *file, static void privcmd_close(struct vm_area_struct *vma) { int count; - struct xen_pvh_pfn_info *pvhp = vma ? vma->vm_private_data : NULL; + struct xen_remap_mfn_info *info = vma ? vma->vm_private_data : NULL; - if (!pvhp || !xen_feature(XENFEAT_auto_translated_physmap)) + if (!info || !xen_feature(XENFEAT_auto_translated_physmap)) return; - count = xen_unmap_domain_mfn_range(vma, pvhp); + count = xen_unmap_domain_mfn_range(vma, info); while (count--) - free_xenballooned_pages(1, &pvhp->pi_paga[count]); - kfree(pvhp->pi_paga); - kfree(pvhp); + free_xenballooned_pages(1, &info->pi_paga[count]); + kfree(info->pi_paga); + kfree(info); } static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf) diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h index 6c5ad83..2f3cb06 100644 --- a/include/xen/xen-ops.h +++ b/include/xen/xen-ops.h @@ -24,16 +24,16 @@ int xen_create_contiguous_region(unsigned long vstart, unsigned int order, void xen_destroy_contiguous_region(unsigned long vstart, unsigned int order); struct vm_area_struct; -struct xen_pvh_pfn_info; +struct xen_remap_mfn_info; int xen_remap_domain_mfn_range(struct vm_area_struct *vma, unsigned long addr, unsigned long mfn, int nr, pgprot_t prot, unsigned domid, - struct xen_pvh_pfn_info *pvhp); + struct xen_remap_mfn_info *pvhp); int xen_unmap_domain_mfn_range(struct vm_area_struct *vma, - struct xen_pvh_pfn_info *pvhp); + struct xen_remap_mfn_info *pvhp); -struct xen_pvh_pfn_info { +struct xen_remap_mfn_info { struct page **pi_paga; /* pfn info page array */ int pi_num_pgs; int pi_next_todo; -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 15:12:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 15:12:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn5p-0007xJ-E9; Thu, 04 Oct 2012 15:12:05 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn5m-0007wU-Rx for xen-devel@lists.xen.org; Thu, 04 Oct 2012 15:12:03 +0000 Received: from [85.158.139.211:56918] by server-12.bemta-5.messagelabs.com id CF/B9-03829-247AD605; Thu, 04 Oct 2012 15:12:02 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-206.messagelabs.com!1349363519!21075191!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODAxODI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25304 invoked from network); 4 Oct 2012 15:12:01 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 15:12:01 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="210303838" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 15:11:56 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 11:11:55 -0400 Received: from drall.uk.xensource.com ([10.80.227.107]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJn5f-0002L6-FW; Thu, 04 Oct 2012 16:11:55 +0100 From: Ian Campbell To: Konrad Rzeszutek Wilk , Stefano Stabellini , Mukesh Rathor Date: Thu, 4 Oct 2012 16:11:44 +0100 Message-ID: <1349363515-26190-3-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1349363496.866.49.camel@zakaz.uk.xensource.com> References: <1349363496.866.49.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Ian Campbell , xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH 03/14] xen events: xen_callback_vector is x86 specific X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Ian Campbell --- Should instead move somewhere arch specific? --- drivers/xen/events.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/xen/events.c b/drivers/xen/events.c index 6f55ef2..2508981 100644 --- a/drivers/xen/events.c +++ b/drivers/xen/events.c @@ -1775,6 +1775,7 @@ int xen_set_callback_via(uint64_t via) EXPORT_SYMBOL_GPL(xen_set_callback_via); +#ifdef CONFIG_X86 /* Vector callbacks are better than PCI interrupts to receive event * channel notifications because we can receive vector callbacks on any * vcpu and we don't need PCI support or APIC interactions. */ @@ -1798,6 +1799,9 @@ void xen_callback_vector(void) alloc_intr_gate(XEN_HVM_EVTCHN_CALLBACK, xen_hvm_callback_vector); } } +#else +void xen_callback_vector(void) {} +#endif void xen_init_IRQ(void) { -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 15:12:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 15:12:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn5p-0007xB-1C; Thu, 04 Oct 2012 15:12:05 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn5m-0007wP-CO for xen-devel@lists.xen.org; Thu, 04 Oct 2012 15:12:02 +0000 Received: from [85.158.137.99:42621] by server-6.bemta-3.messagelabs.com id 54/14-11085-047AD605; Thu, 04 Oct 2012 15:12:00 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-217.messagelabs.com!1349363517!17137968!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQyMDg=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31796 invoked from network); 4 Oct 2012 15:11:59 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 15:11:59 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="40152204" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 15:11:56 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 11:11:56 -0400 Received: from drall.uk.xensource.com ([10.80.227.107]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJn5f-0002L6-Ng; Thu, 04 Oct 2012 16:11:55 +0100 From: Ian Campbell To: Konrad Rzeszutek Wilk , Stefano Stabellini , Mukesh Rathor Date: Thu, 4 Oct 2012 16:11:50 +0100 Message-ID: <1349363515-26190-9-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1349363496.866.49.camel@zakaz.uk.xensource.com> References: <1349363496.866.49.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Ian Campbell , xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH 09/14] xen: arm: enable balloon driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Drop the *_xenballloned_pages duplicates since these are now supplied by the balloon code. Signed-off-by: Ian Campbell --- arch/arm/xen/enlighten.c | 23 +++++------------------ drivers/xen/Makefile | 4 ++-- drivers/xen/privcmd.c | 9 ++++----- 3 files changed, 11 insertions(+), 25 deletions(-) diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c index 59bcb96..ba5cc13 100644 --- a/arch/arm/xen/enlighten.c +++ b/arch/arm/xen/enlighten.c @@ -8,6 +8,7 @@ #include #include #include +#include #include #include #include @@ -29,6 +30,10 @@ struct shared_info *HYPERVISOR_shared_info = (void *)&xen_dummy_shared_info; DEFINE_PER_CPU(struct vcpu_info *, xen_vcpu); +/* These are unused until we support booting "pre-ballooned" */ +unsigned long xen_released_pages; +struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata; + /* TODO: to be removed */ __read_mostly int xen_have_vector_callback; EXPORT_SYMBOL_GPL(xen_have_vector_callback); @@ -148,21 +153,3 @@ static int __init xen_init_events(void) return 0; } postcore_initcall(xen_init_events); - -/* XXX: only until balloon is properly working */ -int alloc_xenballooned_pages(int nr_pages, struct page **pages, bool highmem) -{ - *pages = alloc_pages(highmem ? GFP_HIGHUSER : GFP_KERNEL, - get_order(nr_pages)); - if (*pages == NULL) - return -ENOMEM; - return 0; -} -EXPORT_SYMBOL_GPL(alloc_xenballooned_pages); - -void free_xenballooned_pages(int nr_pages, struct page **pages) -{ - kfree(*pages); - *pages = NULL; -} -EXPORT_SYMBOL_GPL(free_xenballooned_pages); diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile index 275abfc..9a7896f 100644 --- a/drivers/xen/Makefile +++ b/drivers/xen/Makefile @@ -1,8 +1,8 @@ ifneq ($(CONFIG_ARM),y) -obj-y += manage.o balloon.o +obj-y += manage.o obj-$(CONFIG_HOTPLUG_CPU) += cpu_hotplug.o endif -obj-y += grant-table.o features.o events.o +obj-y += grant-table.o features.o events.o balloon.o obj-y += xenbus/ nostackp := $(call cc-option, -fno-stack-protector) diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c index 1010bf7..bf4d62a 100644 --- a/drivers/xen/privcmd.c +++ b/drivers/xen/privcmd.c @@ -200,8 +200,8 @@ static long privcmd_ioctl_mmap(void __user *udata) if (!xen_initial_domain()) return -EPERM; - /* PVH: TBD/FIXME. For now we only support privcmd_ioctl_mmap_batch */ - if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap)) + /* We only support privcmd_ioctl_mmap_batch for auto translated. */ + if (xen_feature(XENFEAT_auto_translated_physmap)) return -ENOSYS; if (copy_from_user(&mmapcmd, udata, sizeof(mmapcmd))) @@ -413,7 +413,7 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version) up_write(&mm->mmap_sem); goto out; } - if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap)) { + if (xen_feature(XENFEAT_auto_translated_physmap)) { if ((ret = pvh_privcmd_resv_pfns(vma, m.num))) { up_write(&mm->mmap_sem); goto out; @@ -492,8 +492,7 @@ static void privcmd_close(struct vm_area_struct *vma) int count; struct xen_pvh_pfn_info *pvhp = vma ? vma->vm_private_data : NULL; - if (!xen_pv_domain() || !pvhp || - !xen_feature(XENFEAT_auto_translated_physmap)) + if (!pvhp || !xen_feature(XENFEAT_auto_translated_physmap)) return; count = xen_unmap_domain_mfn_range(vma, pvhp); -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 15:12:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 15:12:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn5s-0007ys-5d; Thu, 04 Oct 2012 15:12:08 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn5q-0007wI-3d for xen-devel@lists.xen.org; Thu, 04 Oct 2012 15:12:06 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1349363516!9745618!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODAxODI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32709 invoked from network); 4 Oct 2012 15:11:59 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 15:11:59 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="210303836" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 15:11:56 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 11:11:55 -0400 Received: from drall.uk.xensource.com ([10.80.227.107]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJn5f-0002L6-EU; Thu, 04 Oct 2012 16:11:55 +0100 From: Ian Campbell To: Konrad Rzeszutek Wilk , Stefano Stabellini , Mukesh Rathor Date: Thu, 4 Oct 2012 16:11:42 +0100 Message-ID: <1349363515-26190-1-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1349363496.866.49.camel@zakaz.uk.xensource.com> References: <1349363496.866.49.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Ian Campbell , xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH 01/14] Build fixes which I beleive others have already fixed properly elsewhere X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Do not apply, you have better versions of all these somewhere else! --- drivers/xen/Makefile | 2 +- include/xen/interface/memory.h | 4 +--- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile index cd28aae..275abfc 100644 --- a/drivers/xen/Makefile +++ b/drivers/xen/Makefile @@ -8,10 +8,10 @@ obj-y += xenbus/ nostackp := $(call cc-option, -fno-stack-protector) CFLAGS_features.o := $(nostackp) -obj-$(CONFIG_XEN_DOM0) += $(dom0-y) dom0-$(CONFIG_PCI) += pci.o dom0-$(CONFIG_ACPI) += acpi.o dom0-$(CONFIG_X86) += pcpu.o +obj-$(CONFIG_XEN_DOM0) += $(dom0-y) obj-$(CONFIG_BLOCK) += biomerge.o obj-$(CONFIG_XEN_XENCOMM) += xencomm.o obj-$(CONFIG_XEN_BALLOON) += xen-balloon.o diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h index 9953914..6d74c47 100644 --- a/include/xen/interface/memory.h +++ b/include/xen/interface/memory.h @@ -163,15 +163,13 @@ struct xen_add_to_physmap { /* Which domain to change the mapping for. */ domid_t domid; - /* Number of pages to go through for gmfn_range */ - uint16_t size; - union { /* Number of pages to go through for gmfn_range */ uint16_t size; /* IFF XENMAPSPACE_gmfn_foreign */ domid_t foreign_domid; } u; + /* Source mapping space. */ #define XENMAPSPACE_shared_info 0 /* shared info page */ #define XENMAPSPACE_grant_table 1 /* grant table page */ -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 15:12:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 15:12:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn5s-0007ys-5d; Thu, 04 Oct 2012 15:12:08 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn5q-0007wI-3d for xen-devel@lists.xen.org; Thu, 04 Oct 2012 15:12:06 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1349363516!9745618!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODAxODI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32709 invoked from network); 4 Oct 2012 15:11:59 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 15:11:59 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="210303836" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 15:11:56 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 11:11:55 -0400 Received: from drall.uk.xensource.com ([10.80.227.107]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJn5f-0002L6-EU; Thu, 04 Oct 2012 16:11:55 +0100 From: Ian Campbell To: Konrad Rzeszutek Wilk , Stefano Stabellini , Mukesh Rathor Date: Thu, 4 Oct 2012 16:11:42 +0100 Message-ID: <1349363515-26190-1-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1349363496.866.49.camel@zakaz.uk.xensource.com> References: <1349363496.866.49.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Ian Campbell , xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH 01/14] Build fixes which I beleive others have already fixed properly elsewhere X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Do not apply, you have better versions of all these somewhere else! --- drivers/xen/Makefile | 2 +- include/xen/interface/memory.h | 4 +--- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile index cd28aae..275abfc 100644 --- a/drivers/xen/Makefile +++ b/drivers/xen/Makefile @@ -8,10 +8,10 @@ obj-y += xenbus/ nostackp := $(call cc-option, -fno-stack-protector) CFLAGS_features.o := $(nostackp) -obj-$(CONFIG_XEN_DOM0) += $(dom0-y) dom0-$(CONFIG_PCI) += pci.o dom0-$(CONFIG_ACPI) += acpi.o dom0-$(CONFIG_X86) += pcpu.o +obj-$(CONFIG_XEN_DOM0) += $(dom0-y) obj-$(CONFIG_BLOCK) += biomerge.o obj-$(CONFIG_XEN_XENCOMM) += xencomm.o obj-$(CONFIG_XEN_BALLOON) += xen-balloon.o diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h index 9953914..6d74c47 100644 --- a/include/xen/interface/memory.h +++ b/include/xen/interface/memory.h @@ -163,15 +163,13 @@ struct xen_add_to_physmap { /* Which domain to change the mapping for. */ domid_t domid; - /* Number of pages to go through for gmfn_range */ - uint16_t size; - union { /* Number of pages to go through for gmfn_range */ uint16_t size; /* IFF XENMAPSPACE_gmfn_foreign */ domid_t foreign_domid; } u; + /* Source mapping space. */ #define XENMAPSPACE_shared_info 0 /* shared info page */ #define XENMAPSPACE_grant_table 1 /* grant table page */ -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 15:12:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 15:12:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn5s-0007zC-Ie; Thu, 04 Oct 2012 15:12:08 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn5r-0007wM-9I for xen-devel@lists.xen.org; Thu, 04 Oct 2012 15:12:07 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1349363516!9745618!3 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODAxODI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32764 invoked from network); 4 Oct 2012 15:12:00 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 15:12:00 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="210303837" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 15:11:56 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 11:11:55 -0400 Received: from drall.uk.xensource.com ([10.80.227.107]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJn5f-0002L6-G5; Thu, 04 Oct 2012 16:11:55 +0100 From: Ian Campbell To: Konrad Rzeszutek Wilk , Stefano Stabellini , Mukesh Rathor Date: Thu, 4 Oct 2012 16:11:45 +0100 Message-ID: <1349363515-26190-4-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1349363496.866.49.camel@zakaz.uk.xensource.com> References: <1349363496.866.49.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Ian Campbell , xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH 04/14] xen: balloon: don't include e820.h X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This breaks on !X86 and AFAICT is not required on X86 either. Signed-off-by: Ian Campbell --- drivers/xen/balloon.c | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c index 85a6917..85ef7e7 100644 --- a/drivers/xen/balloon.c +++ b/drivers/xen/balloon.c @@ -55,7 +55,6 @@ #include #include #include -#include #include #include -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 15:12:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 15:12:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn5q-0007yI-On; Thu, 04 Oct 2012 15:12:06 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn5p-0007vz-D4 for xen-devel@lists.xen.org; Thu, 04 Oct 2012 15:12:05 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1349363516!9745618!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODAxODI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32375 invoked from network); 4 Oct 2012 15:11:58 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 15:11:58 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="210303835" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 15:11:56 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 11:11:55 -0400 Received: from drall.uk.xensource.com ([10.80.227.107]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJn5f-0002L6-F3; Thu, 04 Oct 2012 16:11:55 +0100 From: Ian Campbell To: Konrad Rzeszutek Wilk , Stefano Stabellini , Mukesh Rathor Date: Thu, 4 Oct 2012 16:11:43 +0100 Message-ID: <1349363515-26190-2-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1349363496.866.49.camel@zakaz.uk.xensource.com> References: <1349363496.866.49.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Ian Campbell , xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH 02/14] xenbus: include features header. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Fixes: drivers/xen/xenbus/xenbus_probe.c: In function 'xenbus_init': drivers/xen/xenbus/xenbus_probe.c:760:3: error: implicit declaration of function 'xen_feature' [-Werror=implicit-function-declaration] drivers/xen/xenbus/xenbus_probe.c:760:19: error: 'XENFEAT_auto_translated_physmap' undeclared (first use in this function) drivers/xen/xenbus/xenbus_probe.c:760:19: note: each undeclared identifier is reported only once for each function it appears in cc1: some warnings being treated as errors Signed-off-by: Ian Campbell --- drivers/xen/xenbus/xenbus_probe.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c index b92c024..974bea0 100644 --- a/drivers/xen/xenbus/xenbus_probe.c +++ b/drivers/xen/xenbus/xenbus_probe.c @@ -56,6 +56,7 @@ #include #include #include +#include #include -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 15:12:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 15:12:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn5s-0007zC-Ie; Thu, 04 Oct 2012 15:12:08 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn5r-0007wM-9I for xen-devel@lists.xen.org; Thu, 04 Oct 2012 15:12:07 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1349363516!9745618!3 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODAxODI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32764 invoked from network); 4 Oct 2012 15:12:00 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 15:12:00 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="210303837" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 15:11:56 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 11:11:55 -0400 Received: from drall.uk.xensource.com ([10.80.227.107]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJn5f-0002L6-G5; Thu, 04 Oct 2012 16:11:55 +0100 From: Ian Campbell To: Konrad Rzeszutek Wilk , Stefano Stabellini , Mukesh Rathor Date: Thu, 4 Oct 2012 16:11:45 +0100 Message-ID: <1349363515-26190-4-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1349363496.866.49.camel@zakaz.uk.xensource.com> References: <1349363496.866.49.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Ian Campbell , xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH 04/14] xen: balloon: don't include e820.h X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This breaks on !X86 and AFAICT is not required on X86 either. Signed-off-by: Ian Campbell --- drivers/xen/balloon.c | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c index 85a6917..85ef7e7 100644 --- a/drivers/xen/balloon.c +++ b/drivers/xen/balloon.c @@ -55,7 +55,6 @@ #include #include #include -#include #include #include -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 15:12:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 15:12:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn5q-0007yI-On; Thu, 04 Oct 2012 15:12:06 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn5p-0007vz-D4 for xen-devel@lists.xen.org; Thu, 04 Oct 2012 15:12:05 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1349363516!9745618!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODAxODI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32375 invoked from network); 4 Oct 2012 15:11:58 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 15:11:58 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="210303835" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 15:11:56 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 11:11:55 -0400 Received: from drall.uk.xensource.com ([10.80.227.107]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJn5f-0002L6-F3; Thu, 04 Oct 2012 16:11:55 +0100 From: Ian Campbell To: Konrad Rzeszutek Wilk , Stefano Stabellini , Mukesh Rathor Date: Thu, 4 Oct 2012 16:11:43 +0100 Message-ID: <1349363515-26190-2-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1349363496.866.49.camel@zakaz.uk.xensource.com> References: <1349363496.866.49.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Ian Campbell , xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH 02/14] xenbus: include features header. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Fixes: drivers/xen/xenbus/xenbus_probe.c: In function 'xenbus_init': drivers/xen/xenbus/xenbus_probe.c:760:3: error: implicit declaration of function 'xen_feature' [-Werror=implicit-function-declaration] drivers/xen/xenbus/xenbus_probe.c:760:19: error: 'XENFEAT_auto_translated_physmap' undeclared (first use in this function) drivers/xen/xenbus/xenbus_probe.c:760:19: note: each undeclared identifier is reported only once for each function it appears in cc1: some warnings being treated as errors Signed-off-by: Ian Campbell --- drivers/xen/xenbus/xenbus_probe.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c index b92c024..974bea0 100644 --- a/drivers/xen/xenbus/xenbus_probe.c +++ b/drivers/xen/xenbus/xenbus_probe.c @@ -56,6 +56,7 @@ #include #include #include +#include #include -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 15:12:27 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 15:12:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn66-0008CH-VP; Thu, 04 Oct 2012 15:12:22 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn66-0008BJ-1S for xen-devel@lists.xen.org; Thu, 04 Oct 2012 15:12:22 +0000 Received: from [85.158.139.211:41733] by server-10.bemta-5.messagelabs.com id C8/51-16911-557AD605; Thu, 04 Oct 2012 15:12:21 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-12.tower-206.messagelabs.com!1349363539!20082712!1 X-Originating-IP: [81.29.64.94] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20377 invoked from network); 4 Oct 2012 15:12:19 -0000 Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94) by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Oct 2012 15:12:19 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1TJn5y-000ApT-4U; Thu, 04 Oct 2012 15:12:14 +0000 Date: Thu, 4 Oct 2012 16:12:14 +0100 From: Tim Deegan To: Jean Guyader Message-ID: <20121004151214.GG38243@ocelot.phlegethon.org> References: <1348141322-28657-1-git-send-email-jean.guyader@citrix.com> <1348141322-28657-5-git-send-email-jean.guyader@citrix.com> <505B2636020000780009CAA6@nat28.tlf.novell.com> <506D98FE020000780009FA23@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: Jean Guyader , Jan Beulich , xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH 4/4] xen: Add V4V implementation X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org At 16:03 +0100 on 04 Oct (1349366589), Jean Guyader wrote: > On 4 October 2012 13:11, Jan Beulich wrote: > >>>> On 04.10.12 at 14:03, Jean Guyader wrote: > >> On 20 September 2012 13:20, Jan Beulich wrote: > >>>>>> On 20.09.12 at 13:42, Jean Guyader wrote: > >>>>+ case V4VOP_register_ring: > >>>>+ { > >>>>+ XEN_GUEST_HANDLE(v4v_ring_t) ring_hnd = > >>>>+ guest_handle_cast(arg1, v4v_ring_t); > >>>>+ XEN_GUEST_HANDLE(xen_pfn_t) pfn_hnd = > >>>>+ guest_handle_cast(arg2, xen_pfn_t); > >>>>+ uint32_t npage = arg3; > >>>>+ if ( unlikely(!guest_handle_okay(ring_hnd, 1)) ) > >>>>+ goto out; > >>>>+ if ( unlikely(!guest_handle_okay(pfn_hnd, npage)) ) > >>>>+ goto out; > >>> > >>> Here and below - this isn't sufficient for compat guests, or else > >>> you give them a way to point into the compat m2p table. > >>> > >> > >> I'll probably switch to uint64_t for the v4v mfn list instead of using > >> xen_pfn_t which > >> are unsigned long. That way I can save the need for a compat wrapper. > > > > But that comment of yours doesn't address the problem I pointed > > out. > > > > [Resent, CCing everyone this time] > > I'm sorry, I don't really get what you mean them. I've tried to get > all my struct > layout such as all the offset for the field are the same for 64b and 32b, this > way I thought I could get away with doing a compat wrapper. Even if the args don't need translation, compat-mode guests have different VA layouts and need different range checks (though I'm not sure why these aren't automatically adjusted based on current). AIUI you need to use compat_handle_okay() instead of guest_handle_okay() to check the handles if is_pv_32on64_domain(current). Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 15:12:27 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 15:12:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn66-0008CH-VP; Thu, 04 Oct 2012 15:12:22 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJn66-0008BJ-1S for xen-devel@lists.xen.org; Thu, 04 Oct 2012 15:12:22 +0000 Received: from [85.158.139.211:41733] by server-10.bemta-5.messagelabs.com id C8/51-16911-557AD605; Thu, 04 Oct 2012 15:12:21 +0000 X-Env-Sender: tim@xen.org X-Msg-Ref: server-12.tower-206.messagelabs.com!1349363539!20082712!1 X-Originating-IP: [81.29.64.94] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20377 invoked from network); 4 Oct 2012 15:12:19 -0000 Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94) by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Oct 2012 15:12:19 -0000 Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1TJn5y-000ApT-4U; Thu, 04 Oct 2012 15:12:14 +0000 Date: Thu, 4 Oct 2012 16:12:14 +0100 From: Tim Deegan To: Jean Guyader Message-ID: <20121004151214.GG38243@ocelot.phlegethon.org> References: <1348141322-28657-1-git-send-email-jean.guyader@citrix.com> <1348141322-28657-5-git-send-email-jean.guyader@citrix.com> <505B2636020000780009CAA6@nat28.tlf.novell.com> <506D98FE020000780009FA23@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: Jean Guyader , Jan Beulich , xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH 4/4] xen: Add V4V implementation X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org At 16:03 +0100 on 04 Oct (1349366589), Jean Guyader wrote: > On 4 October 2012 13:11, Jan Beulich wrote: > >>>> On 04.10.12 at 14:03, Jean Guyader wrote: > >> On 20 September 2012 13:20, Jan Beulich wrote: > >>>>>> On 20.09.12 at 13:42, Jean Guyader wrote: > >>>>+ case V4VOP_register_ring: > >>>>+ { > >>>>+ XEN_GUEST_HANDLE(v4v_ring_t) ring_hnd = > >>>>+ guest_handle_cast(arg1, v4v_ring_t); > >>>>+ XEN_GUEST_HANDLE(xen_pfn_t) pfn_hnd = > >>>>+ guest_handle_cast(arg2, xen_pfn_t); > >>>>+ uint32_t npage = arg3; > >>>>+ if ( unlikely(!guest_handle_okay(ring_hnd, 1)) ) > >>>>+ goto out; > >>>>+ if ( unlikely(!guest_handle_okay(pfn_hnd, npage)) ) > >>>>+ goto out; > >>> > >>> Here and below - this isn't sufficient for compat guests, or else > >>> you give them a way to point into the compat m2p table. > >>> > >> > >> I'll probably switch to uint64_t for the v4v mfn list instead of using > >> xen_pfn_t which > >> are unsigned long. That way I can save the need for a compat wrapper. > > > > But that comment of yours doesn't address the problem I pointed > > out. > > > > [Resent, CCing everyone this time] > > I'm sorry, I don't really get what you mean them. I've tried to get > all my struct > layout such as all the offset for the field are the same for 64b and 32b, this > way I thought I could get away with doing a compat wrapper. Even if the args don't need translation, compat-mode guests have different VA layouts and need different range checks (though I'm not sure why these aren't automatically adjusted based on current). AIUI you need to use compat_handle_okay() instead of guest_handle_okay() to check the handles if is_pv_32on64_domain(current). Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 15:22:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 15:22:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJnFk-0001D4-8A; Thu, 04 Oct 2012 15:22:20 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJnFi-0001Cz-Nl for xen-devel@lists.xen.org; Thu, 04 Oct 2012 15:22:18 +0000 Received: from [85.158.137.99:22088] by server-12.bemta-3.messagelabs.com id 5B/8D-23730-9A9AD605; Thu, 04 Oct 2012 15:22:17 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-217.messagelabs.com!1349364135!14937173!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQyMDg=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4578 invoked from network); 4 Oct 2012 15:22:16 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 15:22:16 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="40154757" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 15:22:15 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 11:22:14 -0400 Received: from drall.uk.xensource.com ([10.80.227.107]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJn5f-0002L6-SV; Thu, 04 Oct 2012 16:11:55 +0100 From: Ian Campbell To: Konrad Rzeszutek Wilk , Stefano Stabellini , Mukesh Rathor Date: Thu, 4 Oct 2012 16:11:55 +0100 Message-ID: <1349363515-26190-14-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1349363496.866.49.camel@zakaz.uk.xensource.com> References: <1349363496.866.49.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Ian Campbell , xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH 14/14] arm: implement foreign mapping using XENMEM_add_to_physmap_range X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This interface is prefered for foreign mappings. Signed-off-by: Ian Campbell --- arch/arm/xen/enlighten.c | 14 +++++++++----- include/xen/interface/memory.h | 18 ++++++++++++++++++ 2 files changed, 27 insertions(+), 5 deletions(-) diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c index 9956af5..a9946aa 100644 --- a/arch/arm/xen/enlighten.c +++ b/arch/arm/xen/enlighten.c @@ -51,15 +51,19 @@ static int map_foreign_page(unsigned long lpfn, unsigned long fgmfn, unsigned int domid) { int rc; - struct xen_add_to_physmap xatp = { + struct xen_add_to_physmap_range xatp = { .domid = DOMID_SELF, - .u.foreign_domid = domid, + .foreign_domid = domid, + .size = 1, .space = XENMAPSPACE_gmfn_foreign, - .idx = fgmfn, - .gpfn = lpfn, }; + unsigned long idx = fgmfn; + xen_pfn_t gpfn = lpfn; - rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp); + set_xen_guest_handle(xatp.idxs, &idx); + set_xen_guest_handle(xatp.gpfns, &gpfn); + + rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap_range, &xatp); if (rc) { pr_warn("Failed to map pfn to mfn rc:%d pfn:%lx mfn:%lx\n", rc, lpfn, fgmfn); diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h index d38bdc1..e5675bc 100644 --- a/include/xen/interface/memory.h +++ b/include/xen/interface/memory.h @@ -188,6 +188,24 @@ struct xen_add_to_physmap { }; DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_physmap); +#define XENMEM_add_to_physmap_range 23 +struct xen_add_to_physmap_range { + /* Which domain to change the mapping for. */ + domid_t domid; + uint16_t space; /* => enum phys_map_space */ + + /* Number of pages to go through */ + uint16_t size; + domid_t foreign_domid; /* IFF gmfn_foreign */ + + /* Indexes into space being mapped. */ + GUEST_HANDLE(ulong) idxs; + + /* GPFN in domid where the source mapping page should appear. */ + GUEST_HANDLE(xen_pfn_t) gpfns; +}; +DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_physmap_range); + /* * Translates a list of domain-specific GPFNs into MFNs. Returns a -ve error * code on failure. This call only works for auto-translated guests. -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 15:22:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 15:22:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJnFn-0001Dy-G3; Thu, 04 Oct 2012 15:22:23 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJnFl-0001DK-SG for xen-devel@lists.xen.org; Thu, 04 Oct 2012 15:22:22 +0000 Received: from [85.158.137.99:19745] by server-10.bemta-3.messagelabs.com id E8/89-02525-DA9AD605; Thu, 04 Oct 2012 15:22:21 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-217.messagelabs.com!1349364138!15160393!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODAxODI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13481 invoked from network); 4 Oct 2012 15:22:20 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 15:22:20 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="210306092" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 15:22:14 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 11:22:14 -0400 Received: from drall.uk.xensource.com ([10.80.227.107]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJn5f-0002L6-Oi; Thu, 04 Oct 2012 16:11:55 +0100 From: Ian Campbell To: Konrad Rzeszutek Wilk , Stefano Stabellini , Mukesh Rathor Date: Thu, 4 Oct 2012 16:11:52 +0100 Message-ID: <1349363515-26190-11-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1349363496.866.49.camel@zakaz.uk.xensource.com> References: <1349363496.866.49.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Ian Campbell , xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH 11/14] arm: implement remap interfaces needed for privcmd mappings. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Ian Campbell --- arch/arm/xen/enlighten.c | 94 +++++++++++++++++++++++++++++++++++++++++++++- 1 files changed, 92 insertions(+), 2 deletions(-) diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c index ba5cc13..9956af5 100644 --- a/arch/arm/xen/enlighten.c +++ b/arch/arm/xen/enlighten.c @@ -9,6 +9,7 @@ #include #include #include +#include #include #include #include @@ -18,6 +19,8 @@ #include #include +#include + struct start_info _xen_start_info; struct start_info *xen_start_info = &_xen_start_info; EXPORT_SYMBOL_GPL(xen_start_info); @@ -43,15 +46,102 @@ EXPORT_SYMBOL_GPL(xen_platform_pci_unplug); static __read_mostly int xen_events_irq = -1; +/* map fgmfn of domid to lpfn in the current domain */ +static int map_foreign_page(unsigned long lpfn, unsigned long fgmfn, + unsigned int domid) +{ + int rc; + struct xen_add_to_physmap xatp = { + .domid = DOMID_SELF, + .u.foreign_domid = domid, + .space = XENMAPSPACE_gmfn_foreign, + .idx = fgmfn, + .gpfn = lpfn, + }; + + rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp); + if (rc) { + pr_warn("Failed to map pfn to mfn rc:%d pfn:%lx mfn:%lx\n", + rc, lpfn, fgmfn); + return 1; + } + return 0; +} + +struct remap_data { + unsigned long fgmfn; /* foreign domain's gmfn */ + pgprot_t prot; + domid_t domid; + struct vm_area_struct *vma; + struct xen_remap_mfn_info *info; +}; + +static int remap_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr, + void *data) +{ + struct remap_data *info = data; + struct xen_remap_mfn_info *savp = info->info; + struct page *page = savp->pi_paga[savp->pi_next_todo++]; + unsigned long pfn = page_to_pfn(page); + pte_t pte = pfn_pte(pfn, info->prot); + + if (map_foreign_page(pfn, info->fgmfn, info->domid)) + return -EFAULT; + set_pte_at(info->vma->vm_mm, addr, ptep, pte); + + return 0; +} + int xen_remap_domain_mfn_range(struct vm_area_struct *vma, unsigned long addr, unsigned long mfn, int nr, - pgprot_t prot, unsigned domid) + pgprot_t prot, unsigned domid, + struct xen_remap_mfn_info *info) { - return -ENOSYS; + int err; + struct remap_data data; + + /* TBD: Batching, current sole caller only does page at a time */ + if (nr > 1) + return -EINVAL; + + data.fgmfn = mfn; + data.prot = prot; + data.domid = domid; + data.vma = vma; + data.info = info; + err = apply_to_page_range(vma->vm_mm, addr, nr << PAGE_SHIFT, + remap_pte_fn, &data); + return err; } EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range); +/* Returns: Number of pages unmapped */ +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma, + struct xen_remap_mfn_info *info) +{ + int count = 0; + + while (info->pi_next_todo--) { + struct xen_remove_from_physmap xrp; + unsigned long rc, pfn; + + pfn = page_to_pfn(info->pi_paga[info->pi_next_todo]); + + xrp.domid = DOMID_SELF; + xrp.gpfn = pfn; + rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, &xrp); + if (rc) { + pr_warn("Failed to unmap pfn:%lx rc:%ld\n", + pfn, rc); + return count; + } + count++; + } + return count; +} +EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range); + /* * see Documentation/devicetree/bindings/arm/xen.txt for the * documentation of the Xen Device Tree format. -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 15:22:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 15:22:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJnFk-0001D4-8A; Thu, 04 Oct 2012 15:22:20 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJnFi-0001Cz-Nl for xen-devel@lists.xen.org; Thu, 04 Oct 2012 15:22:18 +0000 Received: from [85.158.137.99:22088] by server-12.bemta-3.messagelabs.com id 5B/8D-23730-9A9AD605; Thu, 04 Oct 2012 15:22:17 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-217.messagelabs.com!1349364135!14937173!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQyMDg=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4578 invoked from network); 4 Oct 2012 15:22:16 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 15:22:16 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="40154757" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 15:22:15 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 11:22:14 -0400 Received: from drall.uk.xensource.com ([10.80.227.107]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJn5f-0002L6-SV; Thu, 04 Oct 2012 16:11:55 +0100 From: Ian Campbell To: Konrad Rzeszutek Wilk , Stefano Stabellini , Mukesh Rathor Date: Thu, 4 Oct 2012 16:11:55 +0100 Message-ID: <1349363515-26190-14-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1349363496.866.49.camel@zakaz.uk.xensource.com> References: <1349363496.866.49.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Ian Campbell , xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH 14/14] arm: implement foreign mapping using XENMEM_add_to_physmap_range X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This interface is prefered for foreign mappings. Signed-off-by: Ian Campbell --- arch/arm/xen/enlighten.c | 14 +++++++++----- include/xen/interface/memory.h | 18 ++++++++++++++++++ 2 files changed, 27 insertions(+), 5 deletions(-) diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c index 9956af5..a9946aa 100644 --- a/arch/arm/xen/enlighten.c +++ b/arch/arm/xen/enlighten.c @@ -51,15 +51,19 @@ static int map_foreign_page(unsigned long lpfn, unsigned long fgmfn, unsigned int domid) { int rc; - struct xen_add_to_physmap xatp = { + struct xen_add_to_physmap_range xatp = { .domid = DOMID_SELF, - .u.foreign_domid = domid, + .foreign_domid = domid, + .size = 1, .space = XENMAPSPACE_gmfn_foreign, - .idx = fgmfn, - .gpfn = lpfn, }; + unsigned long idx = fgmfn; + xen_pfn_t gpfn = lpfn; - rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp); + set_xen_guest_handle(xatp.idxs, &idx); + set_xen_guest_handle(xatp.gpfns, &gpfn); + + rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap_range, &xatp); if (rc) { pr_warn("Failed to map pfn to mfn rc:%d pfn:%lx mfn:%lx\n", rc, lpfn, fgmfn); diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h index d38bdc1..e5675bc 100644 --- a/include/xen/interface/memory.h +++ b/include/xen/interface/memory.h @@ -188,6 +188,24 @@ struct xen_add_to_physmap { }; DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_physmap); +#define XENMEM_add_to_physmap_range 23 +struct xen_add_to_physmap_range { + /* Which domain to change the mapping for. */ + domid_t domid; + uint16_t space; /* => enum phys_map_space */ + + /* Number of pages to go through */ + uint16_t size; + domid_t foreign_domid; /* IFF gmfn_foreign */ + + /* Indexes into space being mapped. */ + GUEST_HANDLE(ulong) idxs; + + /* GPFN in domid where the source mapping page should appear. */ + GUEST_HANDLE(xen_pfn_t) gpfns; +}; +DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_physmap_range); + /* * Translates a list of domain-specific GPFNs into MFNs. Returns a -ve error * code on failure. This call only works for auto-translated guests. -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 15:22:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 15:22:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJnFn-0001Dy-G3; Thu, 04 Oct 2012 15:22:23 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJnFl-0001DK-SG for xen-devel@lists.xen.org; Thu, 04 Oct 2012 15:22:22 +0000 Received: from [85.158.137.99:19745] by server-10.bemta-3.messagelabs.com id E8/89-02525-DA9AD605; Thu, 04 Oct 2012 15:22:21 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-217.messagelabs.com!1349364138!15160393!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODAxODI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13481 invoked from network); 4 Oct 2012 15:22:20 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 15:22:20 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="210306092" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 15:22:14 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 11:22:14 -0400 Received: from drall.uk.xensource.com ([10.80.227.107]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJn5f-0002L6-Oi; Thu, 04 Oct 2012 16:11:55 +0100 From: Ian Campbell To: Konrad Rzeszutek Wilk , Stefano Stabellini , Mukesh Rathor Date: Thu, 4 Oct 2012 16:11:52 +0100 Message-ID: <1349363515-26190-11-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1349363496.866.49.camel@zakaz.uk.xensource.com> References: <1349363496.866.49.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Ian Campbell , xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH 11/14] arm: implement remap interfaces needed for privcmd mappings. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Ian Campbell --- arch/arm/xen/enlighten.c | 94 +++++++++++++++++++++++++++++++++++++++++++++- 1 files changed, 92 insertions(+), 2 deletions(-) diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c index ba5cc13..9956af5 100644 --- a/arch/arm/xen/enlighten.c +++ b/arch/arm/xen/enlighten.c @@ -9,6 +9,7 @@ #include #include #include +#include #include #include #include @@ -18,6 +19,8 @@ #include #include +#include + struct start_info _xen_start_info; struct start_info *xen_start_info = &_xen_start_info; EXPORT_SYMBOL_GPL(xen_start_info); @@ -43,15 +46,102 @@ EXPORT_SYMBOL_GPL(xen_platform_pci_unplug); static __read_mostly int xen_events_irq = -1; +/* map fgmfn of domid to lpfn in the current domain */ +static int map_foreign_page(unsigned long lpfn, unsigned long fgmfn, + unsigned int domid) +{ + int rc; + struct xen_add_to_physmap xatp = { + .domid = DOMID_SELF, + .u.foreign_domid = domid, + .space = XENMAPSPACE_gmfn_foreign, + .idx = fgmfn, + .gpfn = lpfn, + }; + + rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp); + if (rc) { + pr_warn("Failed to map pfn to mfn rc:%d pfn:%lx mfn:%lx\n", + rc, lpfn, fgmfn); + return 1; + } + return 0; +} + +struct remap_data { + unsigned long fgmfn; /* foreign domain's gmfn */ + pgprot_t prot; + domid_t domid; + struct vm_area_struct *vma; + struct xen_remap_mfn_info *info; +}; + +static int remap_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr, + void *data) +{ + struct remap_data *info = data; + struct xen_remap_mfn_info *savp = info->info; + struct page *page = savp->pi_paga[savp->pi_next_todo++]; + unsigned long pfn = page_to_pfn(page); + pte_t pte = pfn_pte(pfn, info->prot); + + if (map_foreign_page(pfn, info->fgmfn, info->domid)) + return -EFAULT; + set_pte_at(info->vma->vm_mm, addr, ptep, pte); + + return 0; +} + int xen_remap_domain_mfn_range(struct vm_area_struct *vma, unsigned long addr, unsigned long mfn, int nr, - pgprot_t prot, unsigned domid) + pgprot_t prot, unsigned domid, + struct xen_remap_mfn_info *info) { - return -ENOSYS; + int err; + struct remap_data data; + + /* TBD: Batching, current sole caller only does page at a time */ + if (nr > 1) + return -EINVAL; + + data.fgmfn = mfn; + data.prot = prot; + data.domid = domid; + data.vma = vma; + data.info = info; + err = apply_to_page_range(vma->vm_mm, addr, nr << PAGE_SHIFT, + remap_pte_fn, &data); + return err; } EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range); +/* Returns: Number of pages unmapped */ +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma, + struct xen_remap_mfn_info *info) +{ + int count = 0; + + while (info->pi_next_todo--) { + struct xen_remove_from_physmap xrp; + unsigned long rc, pfn; + + pfn = page_to_pfn(info->pi_paga[info->pi_next_todo]); + + xrp.domid = DOMID_SELF; + xrp.gpfn = pfn; + rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, &xrp); + if (rc) { + pr_warn("Failed to unmap pfn:%lx rc:%ld\n", + pfn, rc); + return count; + } + count++; + } + return count; +} +EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range); + /* * see Documentation/devicetree/bindings/arm/xen.txt for the * documentation of the Xen Device Tree format. -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 15:22:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 15:22:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJnFm-0001Dg-LF; Thu, 04 Oct 2012 15:22:22 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJnFl-0001DC-69 for xen-devel@lists.xen.org; Thu, 04 Oct 2012 15:22:21 +0000 Received: from [85.158.143.35:60580] by server-1.bemta-4.messagelabs.com id F4/47-05684-CA9AD605; Thu, 04 Oct 2012 15:22:20 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1349364134!17487056!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQyMDg=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32130 invoked from network); 4 Oct 2012 15:22:16 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 15:22:16 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="40154748" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 15:22:13 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 11:22:13 -0400 Received: from drall.uk.xensource.com ([10.80.227.107]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJn5f-0002L6-PB; Thu, 04 Oct 2012 16:11:55 +0100 From: Ian Campbell To: Konrad Rzeszutek Wilk , Stefano Stabellini , Mukesh Rathor Date: Thu, 4 Oct 2012 16:11:53 +0100 Message-ID: <1349363515-26190-12-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1349363496.866.49.camel@zakaz.uk.xensource.com> References: <1349363496.866.49.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Ian Campbell , xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH 12/14] arm: xen: explain the EXPERIMENTAL dependency in the Kconfig help X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Ian Campbell --- arch/arm/Kconfig | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 3361466..b171c46 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1907,6 +1907,14 @@ config XEN help Say Y if you want to run Linux in a Virtual Machine on Xen on ARM. + + This option is EXPERIMETNAL because the hypervisor + interfaces which it uses are not yet considered stable + therefore backwards and forwards compatibility is not yet + guaranteed. + + If unsure, say N. + endmenu menu "Boot options" -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 15:22:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 15:22:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJnFm-0001Dg-LF; Thu, 04 Oct 2012 15:22:22 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJnFl-0001DC-69 for xen-devel@lists.xen.org; Thu, 04 Oct 2012 15:22:21 +0000 Received: from [85.158.143.35:60580] by server-1.bemta-4.messagelabs.com id F4/47-05684-CA9AD605; Thu, 04 Oct 2012 15:22:20 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1349364134!17487056!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQyMDg=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32130 invoked from network); 4 Oct 2012 15:22:16 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 15:22:16 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="40154748" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 15:22:13 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 11:22:13 -0400 Received: from drall.uk.xensource.com ([10.80.227.107]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJn5f-0002L6-PB; Thu, 04 Oct 2012 16:11:55 +0100 From: Ian Campbell To: Konrad Rzeszutek Wilk , Stefano Stabellini , Mukesh Rathor Date: Thu, 4 Oct 2012 16:11:53 +0100 Message-ID: <1349363515-26190-12-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1349363496.866.49.camel@zakaz.uk.xensource.com> References: <1349363496.866.49.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Ian Campbell , xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH 12/14] arm: xen: explain the EXPERIMENTAL dependency in the Kconfig help X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Ian Campbell --- arch/arm/Kconfig | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 3361466..b171c46 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1907,6 +1907,14 @@ config XEN help Say Y if you want to run Linux in a Virtual Machine on Xen on ARM. + + This option is EXPERIMETNAL because the hypervisor + interfaces which it uses are not yet considered stable + therefore backwards and forwards compatibility is not yet + guaranteed. + + If unsure, say N. + endmenu menu "Boot options" -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 15:22:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 15:22:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJnFn-0001Dp-1F; Thu, 04 Oct 2012 15:22:23 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJnFl-0001DB-8R for xen-devel@lists.xen.org; Thu, 04 Oct 2012 15:22:21 +0000 Received: from [85.158.137.99:65410] by server-1.bemta-3.messagelabs.com id 9A/40-16425-CA9AD605; Thu, 04 Oct 2012 15:22:20 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-217.messagelabs.com!1349364138!15160393!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODAxODI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13410 invoked from network); 4 Oct 2012 15:22:19 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 15:22:19 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="210306086" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 15:22:12 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 11:22:12 -0400 Received: from drall.uk.xensource.com ([10.80.227.107]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJn5f-0002L6-Qp; Thu, 04 Oct 2012 16:11:55 +0100 From: Ian Campbell To: Konrad Rzeszutek Wilk , Stefano Stabellini , Mukesh Rathor Date: Thu, 4 Oct 2012 16:11:54 +0100 Message-ID: <1349363515-26190-13-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1349363496.866.49.camel@zakaz.uk.xensource.com> References: <1349363496.866.49.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Ian Campbell , xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH 13/14] xen: use xen_pft_t in struct xen_remove_from_physmap X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org 4a6c2b4 "PVH basic and hader file changes" and bd3f79b "xen: Introduce xen_pfn_t for pfn and mfn types" passed like ships in the night. Signed-off-by: Ian Campbell --- include/xen/interface/memory.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h index 6d74c47..d38bdc1 100644 --- a/include/xen/interface/memory.h +++ b/include/xen/interface/memory.h @@ -258,7 +258,7 @@ struct xen_remove_from_physmap { domid_t domid; /* GPFN of the current mapping of the page. */ - unsigned long gpfn; + xen_pfn_t gpfn; }; DEFINE_GUEST_HANDLE_STRUCT(xen_remove_from_physmap); -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 15:22:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 15:22:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJnFn-0001Dp-1F; Thu, 04 Oct 2012 15:22:23 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJnFl-0001DB-8R for xen-devel@lists.xen.org; Thu, 04 Oct 2012 15:22:21 +0000 Received: from [85.158.137.99:65410] by server-1.bemta-3.messagelabs.com id 9A/40-16425-CA9AD605; Thu, 04 Oct 2012 15:22:20 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-217.messagelabs.com!1349364138!15160393!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODAxODI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13410 invoked from network); 4 Oct 2012 15:22:19 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 15:22:19 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="210306086" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 15:22:12 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 11:22:12 -0400 Received: from drall.uk.xensource.com ([10.80.227.107]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJn5f-0002L6-Qp; Thu, 04 Oct 2012 16:11:55 +0100 From: Ian Campbell To: Konrad Rzeszutek Wilk , Stefano Stabellini , Mukesh Rathor Date: Thu, 4 Oct 2012 16:11:54 +0100 Message-ID: <1349363515-26190-13-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.2.5 In-Reply-To: <1349363496.866.49.camel@zakaz.uk.xensource.com> References: <1349363496.866.49.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Ian Campbell , xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH 13/14] xen: use xen_pft_t in struct xen_remove_from_physmap X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org 4a6c2b4 "PVH basic and hader file changes" and bd3f79b "xen: Introduce xen_pfn_t for pfn and mfn types" passed like ships in the night. Signed-off-by: Ian Campbell --- include/xen/interface/memory.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h index 6d74c47..d38bdc1 100644 --- a/include/xen/interface/memory.h +++ b/include/xen/interface/memory.h @@ -258,7 +258,7 @@ struct xen_remove_from_physmap { domid_t domid; /* GPFN of the current mapping of the page. */ - unsigned long gpfn; + xen_pfn_t gpfn; }; DEFINE_GUEST_HANDLE_STRUCT(xen_remove_from_physmap); -- 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 15:24:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 15:24:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJnHS-0001WJ-1w; Thu, 04 Oct 2012 15:24:06 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJnHQ-0001W5-G8 for xen-devel@lists.xensource.com; Thu, 04 Oct 2012 15:24:04 +0000 Received: from [85.158.138.51:16804] by server-7.bemta-3.messagelabs.com id 53/85-15765-31AAD605; Thu, 04 Oct 2012 15:24:03 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1349364241!31336520!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzgzMjE1\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 732 invoked from network); 4 Oct 2012 15:24:02 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Oct 2012 15:24:02 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q94FNw2i026637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Oct 2012 15:23:59 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q94FNvr6011339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Oct 2012 15:23:58 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q94FNvPq031888; Thu, 4 Oct 2012 10:23:58 -0500 Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 04 Oct 2012 08:23:57 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 0137D4035E; Thu, 4 Oct 2012 11:12:33 -0400 (EDT) Date: Thu, 4 Oct 2012 11:12:33 -0400 From: Konrad Rzeszutek Wilk To: Linus Torvalds , linux-kernel@vger.kernel.org Message-ID: <20121004151233.GA11426@phenom.dumpdata.com> MIME-Version: 1.0 User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: xen-devel@lists.xensource.com Subject: [Xen-devel] [GIT PULL] (xen) stable/for-linus-3.7-arm-tag X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7391756136024676947==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============7391756136024676947== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XsQoSWH+UP9D9v3l" Content-Disposition: inline --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hey Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-linus-3.7-arm-tag which has the initial support for booting a Linux Xen guest under the ARM (specifically ARMv7 with virtualized extensions). The details of how to use/what it provides/etc are in the next paragraph. There are going to be two merge conflicts. The first is in the drivers/xen/Makefile and the resolution is to make dbgp.o be built on dom0-$(CONFIG_USB_SUPPORT) += dbpg.o option. The second is that the arch/arm/mach-vexpress/Makefile.boot has been squashed in arch/arm/boot/dts/Makefile, so the addition of xenvm-4.2.dtb should be done in the newfile. For your convenience, I've created a branch titled 'linux-next-resolution' where you can see how I resolved it. http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=commitdiff;h=a7d7e57e1a0cae65f600306fe2fdf03b17582c22 The Xen-unstable hypervisor (so will be 4.3 in a ~6 months), supports ARMv7 platforms. The goal in implementing this architecture is to exploit the hardware as much as possible. That means use as little as possible of PV operations (so no PV MMU) - and use existing PV drivers for I/Os (network, block, console, etc). This is similar to how PVHVM guests operate in X86 platform nowadays - except that on ARM there is no need for QEMU. The end result is that we share a lot of the generic Xen drivers and infrastructure. Details on how to compile/boot/etc are available at this Wiki: http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions and this blog has links to a technical discussion/presentations on the overall architecture: http://blog.xen.org/index.php/2012/09/21/xensummit-sessions-new-pvh-virtualisation-mode-for-arm-cortex-a15arm-servers-and-x86/ Documentation/devicetree/bindings/arm/xen.txt | 25 ++++ MAINTAINERS | 7 + arch/arm/Kconfig | 10 ++ arch/arm/Makefile | 1 + arch/arm/boot/dts/Makefile | 3 +- arch/arm/boot/dts/xenvm-4.2.dts | 68 ++++++++++ arch/arm/include/asm/hypervisor.h | 6 + arch/arm/include/asm/sync_bitops.h | 27 ++++ arch/arm/include/asm/xen/events.h | 18 +++ arch/arm/include/asm/xen/hypercall.h | 69 ++++++++++ arch/arm/include/asm/xen/hypervisor.h | 19 +++ arch/arm/include/asm/xen/interface.h | 73 +++++++++++ arch/arm/include/asm/xen/page.h | 82 ++++++++++++ arch/arm/mach-vexpress/v2m.c | 1 + arch/arm/xen/Makefile | 1 + arch/arm/xen/enlighten.c | 168 +++++++++++++++++++++++++ arch/arm/xen/grant-table.c | 53 ++++++++ arch/arm/xen/hypercall.S | 106 ++++++++++++++++ arch/ia64/include/asm/xen/interface.h | 1 + arch/x86/include/asm/xen/interface.h | 1 + arch/x86/xen/enlighten.c | 1 + arch/x86/xen/irq.c | 1 + arch/x86/xen/xen-ops.h | 1 - drivers/block/xen-blkback/blkback.c | 1 + drivers/net/xen-netback/netback.c | 1 + drivers/net/xen-netfront.c | 1 + drivers/xen/Makefile | 14 ++- drivers/xen/events.c | 14 ++- include/xen/events.h | 2 + include/xen/interface/features.h | 3 + include/xen/interface/io/protocols.h | 3 + include/xen/interface/memory.h | 12 +- include/xen/interface/physdev.h | 2 +- include/xen/interface/version.h | 2 +- include/xen/xen.h | 4 +- 35 files changed, 783 insertions(+), 18 deletions(-) Stefano Stabellini (21): arm: initial Xen support xen/arm: hypercalls xen/arm: page.h definitions xen/arm: sync_bitops xen/arm: empty implementation of grant_table arch specific functions docs: Xen ARM DT bindings xen/arm: Xen detection and shared_info page mapping xen/arm: Introduce xen_ulong_t for unsigned long xen: do not compile manage, balloon, pci, acpi, pcpu and cpu_hotplug on ARM xen/arm: introduce CONFIG_XEN on ARM xen/arm: get privilege status xen/arm: initialize grant_table on ARM xen/arm: receive Xen events on ARM xen/arm: implement alloc/free_xenballooned_pages with alloc_pages/kfree xen/arm: compile blkfront and blkback xen/arm: compile netback MAINTAINERS: add myself as Xen ARM maintainer arm: introduce a DTS for Xen unprivileged virtual machines xen/Makefile: fix dom-y build xen: mark xen_init_IRQ __init xen/xen_initial_domain: check that xen_start_info is initialized --XsQoSWH+UP9D9v3l Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJQbadcAAoJEFjIrFwIi8fJ6PEH/35SFdRP7xX9ZECDhfLOIETy 268/+J8/reJde+gWnGfetpCpiTF7LwkXkNDJeFTzj9h6d5uHaZA6OY4Er6Q9eRU5 BMUxE1ZM4TkRKTDe7H//Ua/cpZdH8O6140kOrfzG0H+HDjqpcRBetCw4r7U2gnuL hLZ+YNkbqoj5z38ooeN6vtQfUE3YutUcnEWKyG0k1yzhNrJQ7XaKO7pMNX8Ze/BC DzcmQZda6bScyJVxddXlieqOMmrVO8QFtvQXNiFiFOBB082G72t5Vtdvg5xnVE48 jPf/nyxHTwnGxrX1Lzom6NqobSH88FeaGhj/V+eHd8zQ9sEWZHtQoZTufoAb6As= =zrWt -----END PGP SIGNATURE----- --XsQoSWH+UP9D9v3l-- --===============7391756136024676947== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============7391756136024676947==-- From xen-devel-bounces@lists.xen.org Thu Oct 04 15:24:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 15:24:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJnHS-0001WJ-1w; Thu, 04 Oct 2012 15:24:06 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJnHQ-0001W5-G8 for xen-devel@lists.xensource.com; Thu, 04 Oct 2012 15:24:04 +0000 Received: from [85.158.138.51:16804] by server-7.bemta-3.messagelabs.com id 53/85-15765-31AAD605; Thu, 04 Oct 2012 15:24:03 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1349364241!31336520!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzgzMjE1\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 732 invoked from network); 4 Oct 2012 15:24:02 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Oct 2012 15:24:02 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q94FNw2i026637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Oct 2012 15:23:59 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q94FNvr6011339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Oct 2012 15:23:58 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q94FNvPq031888; Thu, 4 Oct 2012 10:23:58 -0500 Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 04 Oct 2012 08:23:57 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 0137D4035E; Thu, 4 Oct 2012 11:12:33 -0400 (EDT) Date: Thu, 4 Oct 2012 11:12:33 -0400 From: Konrad Rzeszutek Wilk To: Linus Torvalds , linux-kernel@vger.kernel.org Message-ID: <20121004151233.GA11426@phenom.dumpdata.com> MIME-Version: 1.0 User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: xen-devel@lists.xensource.com Subject: [Xen-devel] [GIT PULL] (xen) stable/for-linus-3.7-arm-tag X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7391756136024676947==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============7391756136024676947== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XsQoSWH+UP9D9v3l" Content-Disposition: inline --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hey Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-linus-3.7-arm-tag which has the initial support for booting a Linux Xen guest under the ARM (specifically ARMv7 with virtualized extensions). The details of how to use/what it provides/etc are in the next paragraph. There are going to be two merge conflicts. The first is in the drivers/xen/Makefile and the resolution is to make dbgp.o be built on dom0-$(CONFIG_USB_SUPPORT) += dbpg.o option. The second is that the arch/arm/mach-vexpress/Makefile.boot has been squashed in arch/arm/boot/dts/Makefile, so the addition of xenvm-4.2.dtb should be done in the newfile. For your convenience, I've created a branch titled 'linux-next-resolution' where you can see how I resolved it. http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=commitdiff;h=a7d7e57e1a0cae65f600306fe2fdf03b17582c22 The Xen-unstable hypervisor (so will be 4.3 in a ~6 months), supports ARMv7 platforms. The goal in implementing this architecture is to exploit the hardware as much as possible. That means use as little as possible of PV operations (so no PV MMU) - and use existing PV drivers for I/Os (network, block, console, etc). This is similar to how PVHVM guests operate in X86 platform nowadays - except that on ARM there is no need for QEMU. The end result is that we share a lot of the generic Xen drivers and infrastructure. Details on how to compile/boot/etc are available at this Wiki: http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions and this blog has links to a technical discussion/presentations on the overall architecture: http://blog.xen.org/index.php/2012/09/21/xensummit-sessions-new-pvh-virtualisation-mode-for-arm-cortex-a15arm-servers-and-x86/ Documentation/devicetree/bindings/arm/xen.txt | 25 ++++ MAINTAINERS | 7 + arch/arm/Kconfig | 10 ++ arch/arm/Makefile | 1 + arch/arm/boot/dts/Makefile | 3 +- arch/arm/boot/dts/xenvm-4.2.dts | 68 ++++++++++ arch/arm/include/asm/hypervisor.h | 6 + arch/arm/include/asm/sync_bitops.h | 27 ++++ arch/arm/include/asm/xen/events.h | 18 +++ arch/arm/include/asm/xen/hypercall.h | 69 ++++++++++ arch/arm/include/asm/xen/hypervisor.h | 19 +++ arch/arm/include/asm/xen/interface.h | 73 +++++++++++ arch/arm/include/asm/xen/page.h | 82 ++++++++++++ arch/arm/mach-vexpress/v2m.c | 1 + arch/arm/xen/Makefile | 1 + arch/arm/xen/enlighten.c | 168 +++++++++++++++++++++++++ arch/arm/xen/grant-table.c | 53 ++++++++ arch/arm/xen/hypercall.S | 106 ++++++++++++++++ arch/ia64/include/asm/xen/interface.h | 1 + arch/x86/include/asm/xen/interface.h | 1 + arch/x86/xen/enlighten.c | 1 + arch/x86/xen/irq.c | 1 + arch/x86/xen/xen-ops.h | 1 - drivers/block/xen-blkback/blkback.c | 1 + drivers/net/xen-netback/netback.c | 1 + drivers/net/xen-netfront.c | 1 + drivers/xen/Makefile | 14 ++- drivers/xen/events.c | 14 ++- include/xen/events.h | 2 + include/xen/interface/features.h | 3 + include/xen/interface/io/protocols.h | 3 + include/xen/interface/memory.h | 12 +- include/xen/interface/physdev.h | 2 +- include/xen/interface/version.h | 2 +- include/xen/xen.h | 4 +- 35 files changed, 783 insertions(+), 18 deletions(-) Stefano Stabellini (21): arm: initial Xen support xen/arm: hypercalls xen/arm: page.h definitions xen/arm: sync_bitops xen/arm: empty implementation of grant_table arch specific functions docs: Xen ARM DT bindings xen/arm: Xen detection and shared_info page mapping xen/arm: Introduce xen_ulong_t for unsigned long xen: do not compile manage, balloon, pci, acpi, pcpu and cpu_hotplug on ARM xen/arm: introduce CONFIG_XEN on ARM xen/arm: get privilege status xen/arm: initialize grant_table on ARM xen/arm: receive Xen events on ARM xen/arm: implement alloc/free_xenballooned_pages with alloc_pages/kfree xen/arm: compile blkfront and blkback xen/arm: compile netback MAINTAINERS: add myself as Xen ARM maintainer arm: introduce a DTS for Xen unprivileged virtual machines xen/Makefile: fix dom-y build xen: mark xen_init_IRQ __init xen/xen_initial_domain: check that xen_start_info is initialized --XsQoSWH+UP9D9v3l Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJQbadcAAoJEFjIrFwIi8fJ6PEH/35SFdRP7xX9ZECDhfLOIETy 268/+J8/reJde+gWnGfetpCpiTF7LwkXkNDJeFTzj9h6d5uHaZA6OY4Er6Q9eRU5 BMUxE1ZM4TkRKTDe7H//Ua/cpZdH8O6140kOrfzG0H+HDjqpcRBetCw4r7U2gnuL hLZ+YNkbqoj5z38ooeN6vtQfUE3YutUcnEWKyG0k1yzhNrJQ7XaKO7pMNX8Ze/BC DzcmQZda6bScyJVxddXlieqOMmrVO8QFtvQXNiFiFOBB082G72t5Vtdvg5xnVE48 jPf/nyxHTwnGxrX1Lzom6NqobSH88FeaGhj/V+eHd8zQ9sEWZHtQoZTufoAb6As= =zrWt -----END PGP SIGNATURE----- --XsQoSWH+UP9D9v3l-- --===============7391756136024676947== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============7391756136024676947==-- From xen-devel-bounces@lists.xen.org Thu Oct 04 15:27:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 15:27:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJnKM-0001sd-Us; Thu, 04 Oct 2012 15:27:06 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJnKK-0001sM-Ui for xen-devel@lists.xen.org; Thu, 04 Oct 2012 15:27:05 +0000 Received: from [85.158.139.211:52287] by server-3.bemta-5.messagelabs.com id D2/42-16108-8CAAD605; Thu, 04 Oct 2012 15:27:04 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-6.tower-206.messagelabs.com!1349364422!21096988!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc5MzIzNg==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28814 invoked from network); 4 Oct 2012 15:27:03 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Oct 2012 15:27:03 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q94FQx9T003439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Oct 2012 15:26:59 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q94FQwOf017112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Oct 2012 15:26:59 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q94FQwBN031520; Thu, 4 Oct 2012 10:26:58 -0500 Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 04 Oct 2012 08:26:58 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 60DD44035E; Thu, 4 Oct 2012 11:15:35 -0400 (EDT) Date: Thu, 4 Oct 2012 11:15:35 -0400 From: Konrad Rzeszutek Wilk To: Ian Campbell Message-ID: <20121004151535.GB11426@phenom.dumpdata.com> References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-1-git-send-email-ian.campbell@citrix.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1349363515-26190-1-git-send-email-ian.campbell@citrix.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: Stefano Stabellini , xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH 01/14] Build fixes which I beleive others have already fixed properly elsewhere X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, Oct 04, 2012 at 04:11:42PM +0100, Ian Campbell wrote: > Do not apply, you have better versions of all these somewhere else! . > --- > drivers/xen/Makefile | 2 +- > include/xen/interface/memory.h | 4 +--- > 2 files changed, 2 insertions(+), 4 deletions(-) > > diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile > index cd28aae..275abfc 100644 > --- a/drivers/xen/Makefile > +++ b/drivers/xen/Makefile > @@ -8,10 +8,10 @@ obj-y += xenbus/ > nostackp := $(call cc-option, -fno-stack-protector) > CFLAGS_features.o := $(nostackp) > > -obj-$(CONFIG_XEN_DOM0) += $(dom0-y) > dom0-$(CONFIG_PCI) += pci.o > dom0-$(CONFIG_ACPI) += acpi.o > dom0-$(CONFIG_X86) += pcpu.o > +obj-$(CONFIG_XEN_DOM0) += $(dom0-y) > obj-$(CONFIG_BLOCK) += biomerge.o > obj-$(CONFIG_XEN_XENCOMM) += xencomm.o > obj-$(CONFIG_XEN_BALLOON) += xen-balloon.o > diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h > index 9953914..6d74c47 100644 > --- a/include/xen/interface/memory.h > +++ b/include/xen/interface/memory.h > @@ -163,15 +163,13 @@ struct xen_add_to_physmap { > /* Which domain to change the mapping for. */ > domid_t domid; > > - /* Number of pages to go through for gmfn_range */ > - uint16_t size; > - > union { > /* Number of pages to go through for gmfn_range */ > uint16_t size; > /* IFF XENMAPSPACE_gmfn_foreign */ > domid_t foreign_domid; > } u; > + > /* Source mapping space. */ > #define XENMAPSPACE_shared_info 0 /* shared info page */ > #define XENMAPSPACE_grant_table 1 /* grant table page */ > -- > 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 15:27:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 15:27:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJnKM-0001sd-Us; Thu, 04 Oct 2012 15:27:06 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJnKK-0001sM-Ui for xen-devel@lists.xen.org; Thu, 04 Oct 2012 15:27:05 +0000 Received: from [85.158.139.211:52287] by server-3.bemta-5.messagelabs.com id D2/42-16108-8CAAD605; Thu, 04 Oct 2012 15:27:04 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-6.tower-206.messagelabs.com!1349364422!21096988!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc5MzIzNg==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28814 invoked from network); 4 Oct 2012 15:27:03 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Oct 2012 15:27:03 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q94FQx9T003439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Oct 2012 15:26:59 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q94FQwOf017112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Oct 2012 15:26:59 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q94FQwBN031520; Thu, 4 Oct 2012 10:26:58 -0500 Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 04 Oct 2012 08:26:58 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 60DD44035E; Thu, 4 Oct 2012 11:15:35 -0400 (EDT) Date: Thu, 4 Oct 2012 11:15:35 -0400 From: Konrad Rzeszutek Wilk To: Ian Campbell Message-ID: <20121004151535.GB11426@phenom.dumpdata.com> References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-1-git-send-email-ian.campbell@citrix.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1349363515-26190-1-git-send-email-ian.campbell@citrix.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: Stefano Stabellini , xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH 01/14] Build fixes which I beleive others have already fixed properly elsewhere X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, Oct 04, 2012 at 04:11:42PM +0100, Ian Campbell wrote: > Do not apply, you have better versions of all these somewhere else! . > --- > drivers/xen/Makefile | 2 +- > include/xen/interface/memory.h | 4 +--- > 2 files changed, 2 insertions(+), 4 deletions(-) > > diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile > index cd28aae..275abfc 100644 > --- a/drivers/xen/Makefile > +++ b/drivers/xen/Makefile > @@ -8,10 +8,10 @@ obj-y += xenbus/ > nostackp := $(call cc-option, -fno-stack-protector) > CFLAGS_features.o := $(nostackp) > > -obj-$(CONFIG_XEN_DOM0) += $(dom0-y) > dom0-$(CONFIG_PCI) += pci.o > dom0-$(CONFIG_ACPI) += acpi.o > dom0-$(CONFIG_X86) += pcpu.o > +obj-$(CONFIG_XEN_DOM0) += $(dom0-y) > obj-$(CONFIG_BLOCK) += biomerge.o > obj-$(CONFIG_XEN_XENCOMM) += xencomm.o > obj-$(CONFIG_XEN_BALLOON) += xen-balloon.o > diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h > index 9953914..6d74c47 100644 > --- a/include/xen/interface/memory.h > +++ b/include/xen/interface/memory.h > @@ -163,15 +163,13 @@ struct xen_add_to_physmap { > /* Which domain to change the mapping for. */ > domid_t domid; > > - /* Number of pages to go through for gmfn_range */ > - uint16_t size; > - > union { > /* Number of pages to go through for gmfn_range */ > uint16_t size; > /* IFF XENMAPSPACE_gmfn_foreign */ > domid_t foreign_domid; > } u; > + > /* Source mapping space. */ > #define XENMAPSPACE_shared_info 0 /* shared info page */ > #define XENMAPSPACE_grant_table 1 /* grant table page */ > -- > 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 15:36:44 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 15:36:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJnTV-00026Q-5z; Thu, 04 Oct 2012 15:36:33 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJnTS-00026H-UZ for xen-devel@lists.xen.org; Thu, 04 Oct 2012 15:36:31 +0000 Received: from [85.158.137.99:55322] by server-9.bemta-3.messagelabs.com id 25/49-20338-EFCAD605; Thu, 04 Oct 2012 15:36:30 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-10.tower-217.messagelabs.com!1349364987!20189295!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzgzMjE1\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18712 invoked from network); 4 Oct 2012 15:36:29 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-10.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Oct 2012 15:36:29 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q94FaOgg021983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Oct 2012 15:36:25 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q94FaOD6023753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Oct 2012 15:36:24 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q94FaNna010185; Thu, 4 Oct 2012 10:36:23 -0500 Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 04 Oct 2012 08:36:23 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id B12374035E; Thu, 4 Oct 2012 11:24:59 -0400 (EDT) Date: Thu, 4 Oct 2012 11:24:59 -0400 From: Konrad Rzeszutek Wilk To: Ian Campbell Message-ID: <20121004152459.GC11426@phenom.dumpdata.com> References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-11-git-send-email-ian.campbell@citrix.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1349363515-26190-11-git-send-email-ian.campbell@citrix.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: Stefano Stabellini , xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH 11/14] arm: implement remap interfaces needed for privcmd mappings. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, Oct 04, 2012 at 04:11:52PM +0100, Ian Campbell wrote: > Signed-off-by: Ian Campbell > --- > arch/arm/xen/enlighten.c | 94 +++++++++++++++++++++++++++++++++++++++++++++- > 1 files changed, 92 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c > index ba5cc13..9956af5 100644 > --- a/arch/arm/xen/enlighten.c > +++ b/arch/arm/xen/enlighten.c > @@ -9,6 +9,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -18,6 +19,8 @@ > #include > #include > > +#include > + > struct start_info _xen_start_info; > struct start_info *xen_start_info = &_xen_start_info; > EXPORT_SYMBOL_GPL(xen_start_info); > @@ -43,15 +46,102 @@ EXPORT_SYMBOL_GPL(xen_platform_pci_unplug); > > static __read_mostly int xen_events_irq = -1; > > +/* map fgmfn of domid to lpfn in the current domain */ Say that really fast a couple of times :-) Any way we can explain it a bit more of what each acronym means? > +static int map_foreign_page(unsigned long lpfn, unsigned long fgmfn, > + unsigned int domid) > +{ > + int rc; > + struct xen_add_to_physmap xatp = { > + .domid = DOMID_SELF, > + .u.foreign_domid = domid, > + .space = XENMAPSPACE_gmfn_foreign, > + .idx = fgmfn, > + .gpfn = lpfn, > + }; > + > + rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp); > + if (rc) { > + pr_warn("Failed to map pfn to mfn rc:%d pfn:%lx mfn:%lx\n", How about 'Failed to map pfn (0x%lx) to mfn (0x%lx), rc: %d\n" ? > + rc, lpfn, fgmfn); > + return 1; > + } > + return 0; > +} > + > +struct remap_data { > + unsigned long fgmfn; /* foreign domain's gmfn */ Shouldn't this be called now 'xen_pfn_t' or something. > + pgprot_t prot; > + domid_t domid; > + struct vm_area_struct *vma; > + struct xen_remap_mfn_info *info; > +}; > + > +static int remap_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr, > + void *data) > +{ > + struct remap_data *info = data; > + struct xen_remap_mfn_info *savp = info->info; > + struct page *page = savp->pi_paga[savp->pi_next_todo++]; > + unsigned long pfn = page_to_pfn(page); > + pte_t pte = pfn_pte(pfn, info->prot); > + > + if (map_foreign_page(pfn, info->fgmfn, info->domid)) > + return -EFAULT; > + set_pte_at(info->vma->vm_mm, addr, ptep, pte); > + > + return 0; > +} > + > int xen_remap_domain_mfn_range(struct vm_area_struct *vma, > unsigned long addr, > unsigned long mfn, int nr, > - pgprot_t prot, unsigned domid) > + pgprot_t prot, unsigned domid, > + struct xen_remap_mfn_info *info) > { > - return -ENOSYS; > + int err; > + struct remap_data data; > + > + /* TBD: Batching, current sole caller only does page at a time */ > + if (nr > 1) Lets also wrap it with WARN_ON? > + return -EINVAL; > + > + data.fgmfn = mfn; > + data.prot = prot; > + data.domid = domid; > + data.vma = vma; > + data.info = info; > + err = apply_to_page_range(vma->vm_mm, addr, nr << PAGE_SHIFT, > + remap_pte_fn, &data); > + return err; > } > EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range); > > +/* Returns: Number of pages unmapped */ > +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma, > + struct xen_remap_mfn_info *info) > +{ > + int count = 0; > + > + while (info->pi_next_todo--) { > + struct xen_remove_from_physmap xrp; > + unsigned long rc, pfn; > + > + pfn = page_to_pfn(info->pi_paga[info->pi_next_todo]); Won't this miss the first pi_next_todo? You did the 'pi_next_todo--' so will the compiler decrement it here in this operation or will it do when it gets to the 'do' logic of the loop? > + > + xrp.domid = DOMID_SELF; > + xrp.gpfn = pfn; > + rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, &xrp); 'rc' is 'unsigned long'. Is that right? You don't want it to be 'int'? > + if (rc) { > + pr_warn("Failed to unmap pfn:%lx rc:%ld\n", > + pfn, rc); > + return count; > + } > + count++; > + } > + return count; > +} > +EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range); > + > /* > * see Documentation/devicetree/bindings/arm/xen.txt for the > * documentation of the Xen Device Tree format. > -- > 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 15:36:44 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 15:36:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJnTV-00026Q-5z; Thu, 04 Oct 2012 15:36:33 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJnTS-00026H-UZ for xen-devel@lists.xen.org; Thu, 04 Oct 2012 15:36:31 +0000 Received: from [85.158.137.99:55322] by server-9.bemta-3.messagelabs.com id 25/49-20338-EFCAD605; Thu, 04 Oct 2012 15:36:30 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-10.tower-217.messagelabs.com!1349364987!20189295!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzgzMjE1\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18712 invoked from network); 4 Oct 2012 15:36:29 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-10.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Oct 2012 15:36:29 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q94FaOgg021983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Oct 2012 15:36:25 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q94FaOD6023753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Oct 2012 15:36:24 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q94FaNna010185; Thu, 4 Oct 2012 10:36:23 -0500 Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 04 Oct 2012 08:36:23 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id B12374035E; Thu, 4 Oct 2012 11:24:59 -0400 (EDT) Date: Thu, 4 Oct 2012 11:24:59 -0400 From: Konrad Rzeszutek Wilk To: Ian Campbell Message-ID: <20121004152459.GC11426@phenom.dumpdata.com> References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-11-git-send-email-ian.campbell@citrix.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1349363515-26190-11-git-send-email-ian.campbell@citrix.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: Stefano Stabellini , xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH 11/14] arm: implement remap interfaces needed for privcmd mappings. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, Oct 04, 2012 at 04:11:52PM +0100, Ian Campbell wrote: > Signed-off-by: Ian Campbell > --- > arch/arm/xen/enlighten.c | 94 +++++++++++++++++++++++++++++++++++++++++++++- > 1 files changed, 92 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c > index ba5cc13..9956af5 100644 > --- a/arch/arm/xen/enlighten.c > +++ b/arch/arm/xen/enlighten.c > @@ -9,6 +9,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -18,6 +19,8 @@ > #include > #include > > +#include > + > struct start_info _xen_start_info; > struct start_info *xen_start_info = &_xen_start_info; > EXPORT_SYMBOL_GPL(xen_start_info); > @@ -43,15 +46,102 @@ EXPORT_SYMBOL_GPL(xen_platform_pci_unplug); > > static __read_mostly int xen_events_irq = -1; > > +/* map fgmfn of domid to lpfn in the current domain */ Say that really fast a couple of times :-) Any way we can explain it a bit more of what each acronym means? > +static int map_foreign_page(unsigned long lpfn, unsigned long fgmfn, > + unsigned int domid) > +{ > + int rc; > + struct xen_add_to_physmap xatp = { > + .domid = DOMID_SELF, > + .u.foreign_domid = domid, > + .space = XENMAPSPACE_gmfn_foreign, > + .idx = fgmfn, > + .gpfn = lpfn, > + }; > + > + rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp); > + if (rc) { > + pr_warn("Failed to map pfn to mfn rc:%d pfn:%lx mfn:%lx\n", How about 'Failed to map pfn (0x%lx) to mfn (0x%lx), rc: %d\n" ? > + rc, lpfn, fgmfn); > + return 1; > + } > + return 0; > +} > + > +struct remap_data { > + unsigned long fgmfn; /* foreign domain's gmfn */ Shouldn't this be called now 'xen_pfn_t' or something. > + pgprot_t prot; > + domid_t domid; > + struct vm_area_struct *vma; > + struct xen_remap_mfn_info *info; > +}; > + > +static int remap_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr, > + void *data) > +{ > + struct remap_data *info = data; > + struct xen_remap_mfn_info *savp = info->info; > + struct page *page = savp->pi_paga[savp->pi_next_todo++]; > + unsigned long pfn = page_to_pfn(page); > + pte_t pte = pfn_pte(pfn, info->prot); > + > + if (map_foreign_page(pfn, info->fgmfn, info->domid)) > + return -EFAULT; > + set_pte_at(info->vma->vm_mm, addr, ptep, pte); > + > + return 0; > +} > + > int xen_remap_domain_mfn_range(struct vm_area_struct *vma, > unsigned long addr, > unsigned long mfn, int nr, > - pgprot_t prot, unsigned domid) > + pgprot_t prot, unsigned domid, > + struct xen_remap_mfn_info *info) > { > - return -ENOSYS; > + int err; > + struct remap_data data; > + > + /* TBD: Batching, current sole caller only does page at a time */ > + if (nr > 1) Lets also wrap it with WARN_ON? > + return -EINVAL; > + > + data.fgmfn = mfn; > + data.prot = prot; > + data.domid = domid; > + data.vma = vma; > + data.info = info; > + err = apply_to_page_range(vma->vm_mm, addr, nr << PAGE_SHIFT, > + remap_pte_fn, &data); > + return err; > } > EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range); > > +/* Returns: Number of pages unmapped */ > +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma, > + struct xen_remap_mfn_info *info) > +{ > + int count = 0; > + > + while (info->pi_next_todo--) { > + struct xen_remove_from_physmap xrp; > + unsigned long rc, pfn; > + > + pfn = page_to_pfn(info->pi_paga[info->pi_next_todo]); Won't this miss the first pi_next_todo? You did the 'pi_next_todo--' so will the compiler decrement it here in this operation or will it do when it gets to the 'do' logic of the loop? > + > + xrp.domid = DOMID_SELF; > + xrp.gpfn = pfn; > + rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, &xrp); 'rc' is 'unsigned long'. Is that right? You don't want it to be 'int'? > + if (rc) { > + pr_warn("Failed to unmap pfn:%lx rc:%ld\n", > + pfn, rc); > + return count; > + } > + count++; > + } > + return count; > +} > +EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range); > + > /* > * see Documentation/devicetree/bindings/arm/xen.txt for the > * documentation of the Xen Device Tree format. > -- > 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 15:39:22 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 15:39:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJnVz-0002GQ-Om; Thu, 04 Oct 2012 15:39:07 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJnVz-0002GA-2H for xen-devel@lists.xen.org; Thu, 04 Oct 2012 15:39:07 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1349365139!9749354!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc5MzIzNg==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31964 invoked from network); 4 Oct 2012 15:39:00 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Oct 2012 15:39:00 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q94FctY4029286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Oct 2012 15:38:56 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q94FctTx016665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Oct 2012 15:38:55 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q94FctJH012196; Thu, 4 Oct 2012 10:38:55 -0500 Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 04 Oct 2012 08:38:54 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id BE4474035E; Thu, 4 Oct 2012 11:27:31 -0400 (EDT) Date: Thu, 4 Oct 2012 11:27:31 -0400 From: Konrad Rzeszutek Wilk To: Ian Campbell Message-ID: <20121004152731.GD11426@phenom.dumpdata.com> References: <1349363496.866.49.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1349363496.866.49.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: Stefano Stabellini , xen-devel Subject: Re: [Xen-devel] [RFC 00/14] arm: implement ballooning and privcmd foreign mappings based on x86 PVH X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, Oct 04, 2012 at 04:11:36PM +0100, Ian Campbell wrote: > This series implements ballooning for Xen on ARM and builds and Mukesh's > PVH privcmd stuff to implement foreign page mapping on ARM, replacing > the old "HACK: initial (very hacky) XENMAPSPACE_gmfn_foreign" patch. Great. Thanks for doing it. > > The baseline is a bit complex, it is basically Stefano's xenarm-forlinus > branch (commit bbd6eb29214e) merged with Konrad's linux-next-pvh branch > (commit 7e6e6f589de8). I suspect I might need to rebase it shortly. I Yes. I am hoping that on Monday Mukesh will have had sent out his revised patch and I can rebase the whole thing on Linus's tree (which by that time should have the Xen ARM's pulled in). > know there's a bunch of stuff in here which Mukesh has also changed, but > which I haven't seen yet, I'll deal with that when I rebase (RFC mainly > for that reason only). They look good to me. I've provided some feedback on some of them. > > This lets me start a guest without any of those nasty patches with > "HACK" in the title ;-0 > > Ian. > > > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 15:39:22 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 15:39:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJnVz-0002GQ-Om; Thu, 04 Oct 2012 15:39:07 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJnVz-0002GA-2H for xen-devel@lists.xen.org; Thu, 04 Oct 2012 15:39:07 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1349365139!9749354!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc5MzIzNg==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31964 invoked from network); 4 Oct 2012 15:39:00 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Oct 2012 15:39:00 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q94FctY4029286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Oct 2012 15:38:56 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q94FctTx016665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Oct 2012 15:38:55 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q94FctJH012196; Thu, 4 Oct 2012 10:38:55 -0500 Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 04 Oct 2012 08:38:54 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id BE4474035E; Thu, 4 Oct 2012 11:27:31 -0400 (EDT) Date: Thu, 4 Oct 2012 11:27:31 -0400 From: Konrad Rzeszutek Wilk To: Ian Campbell Message-ID: <20121004152731.GD11426@phenom.dumpdata.com> References: <1349363496.866.49.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1349363496.866.49.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: Stefano Stabellini , xen-devel Subject: Re: [Xen-devel] [RFC 00/14] arm: implement ballooning and privcmd foreign mappings based on x86 PVH X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, Oct 04, 2012 at 04:11:36PM +0100, Ian Campbell wrote: > This series implements ballooning for Xen on ARM and builds and Mukesh's > PVH privcmd stuff to implement foreign page mapping on ARM, replacing > the old "HACK: initial (very hacky) XENMAPSPACE_gmfn_foreign" patch. Great. Thanks for doing it. > > The baseline is a bit complex, it is basically Stefano's xenarm-forlinus > branch (commit bbd6eb29214e) merged with Konrad's linux-next-pvh branch > (commit 7e6e6f589de8). I suspect I might need to rebase it shortly. I Yes. I am hoping that on Monday Mukesh will have had sent out his revised patch and I can rebase the whole thing on Linus's tree (which by that time should have the Xen ARM's pulled in). > know there's a bunch of stuff in here which Mukesh has also changed, but > which I haven't seen yet, I'll deal with that when I rebase (RFC mainly > for that reason only). They look good to me. I've provided some feedback on some of them. > > This lets me start a guest without any of those nasty patches with > "HACK" in the title ;-0 > > Ian. > > > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 15:49:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 15:49:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJnfo-0002WM-U7; Thu, 04 Oct 2012 15:49:16 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJnfn-0002WH-IQ for xen-devel@lists.xen.org; Thu, 04 Oct 2012 15:49:15 +0000 Received: from [85.158.143.99:4496] by server-2.bemta-4.messagelabs.com id F2/B3-06610-AFFAD605; Thu, 04 Oct 2012 15:49:14 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1349365754!25877864!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4052 invoked from network); 4 Oct 2012 15:49:14 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 15:49:14 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="14945955" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 15:48:39 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 16:48:39 +0100 Message-ID: <1349365718.866.63.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Konrad Rzeszutek Wilk Date: Thu, 4 Oct 2012 16:48:38 +0100 In-Reply-To: <20121004152459.GC11426@phenom.dumpdata.com> References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-11-git-send-email-ian.campbell@citrix.com> <20121004152459.GC11426@phenom.dumpdata.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH 11/14] arm: implement remap interfaces needed for privcmd mappings. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-10-04 at 16:24 +0100, Konrad Rzeszutek Wilk wrote: > On Thu, Oct 04, 2012 at 04:11:52PM +0100, Ian Campbell wrote: > > Signed-off-by: Ian Campbell > > --- > > arch/arm/xen/enlighten.c | 94 +++++++++++++++++++++++++++++++++++++++++++++- > > 1 files changed, 92 insertions(+), 2 deletions(-) > > > > diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c > > index ba5cc13..9956af5 100644 > > --- a/arch/arm/xen/enlighten.c > > +++ b/arch/arm/xen/enlighten.c > > @@ -9,6 +9,7 @@ > > #include > > #include > > #include > > +#include > > #include > > #include > > #include > > @@ -18,6 +19,8 @@ > > #include > > #include > > > > +#include > > + > > struct start_info _xen_start_info; > > struct start_info *xen_start_info = &_xen_start_info; > > EXPORT_SYMBOL_GPL(xen_start_info); > > @@ -43,15 +46,102 @@ EXPORT_SYMBOL_GPL(xen_platform_pci_unplug); > > > > static __read_mostly int xen_events_irq = -1; > > > > +/* map fgmfn of domid to lpfn in the current domain */ > > Say that really fast a couple of times :-) > > Any way we can explain it a bit more of what each acronym means? The names come from the x86 PVH version, which has the comment: /* Map foreign gmfn, fgmfn, to local pfn, lpfn. This for the user space * creating new guest on PVH dom0 and needs to map domU pages. */ Is that preferable? (modulo removing the PVH bit) > > > +static int map_foreign_page(unsigned long lpfn, unsigned long fgmfn, > > + unsigned int domid) > > +{ > > + int rc; > > + struct xen_add_to_physmap xatp = { > > + .domid = DOMID_SELF, > > + .u.foreign_domid = domid, > > + .space = XENMAPSPACE_gmfn_foreign, > > + .idx = fgmfn, > > + .gpfn = lpfn, > > + }; > > + > > + rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp); > > + if (rc) { > > + pr_warn("Failed to map pfn to mfn rc:%d pfn:%lx mfn:%lx\n", > > How about 'Failed to map pfn (0x%lx) to mfn (0x%lx), rc: %d\n" ? Sure, need to slip foreign domid in there somewhere now I look at it. x86 PVH has basically the same print BTW. > > > + rc, lpfn, fgmfn); > > + return 1; > > + } > > + return 0; > > +} > > + > > +struct remap_data { > > + unsigned long fgmfn; /* foreign domain's gmfn */ > > Shouldn't this be called now 'xen_pfn_t' or something. xen_pfn_t is needed at the hypervisor interface layer, I'm not so sure about kernel internal use. I guess it can't hurt? > > > + pgprot_t prot; > > + domid_t domid; > > + struct vm_area_struct *vma; > > + struct xen_remap_mfn_info *info; > > +}; > > + > > +static int remap_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr, > > + void *data) > > +{ > > + struct remap_data *info = data; > > + struct xen_remap_mfn_info *savp = info->info; > > + struct page *page = savp->pi_paga[savp->pi_next_todo++]; > > + unsigned long pfn = page_to_pfn(page); > > + pte_t pte = pfn_pte(pfn, info->prot); > > + > > + if (map_foreign_page(pfn, info->fgmfn, info->domid)) > > + return -EFAULT; > > + set_pte_at(info->vma->vm_mm, addr, ptep, pte); > > + > > + return 0; > > +} > > + > > int xen_remap_domain_mfn_range(struct vm_area_struct *vma, > > unsigned long addr, > > unsigned long mfn, int nr, > > - pgprot_t prot, unsigned domid) > > + pgprot_t prot, unsigned domid, > > + struct xen_remap_mfn_info *info) > > { > > - return -ENOSYS; > > + int err; > > + struct remap_data data; > > + > > + /* TBD: Batching, current sole caller only does page at a time */ > > + if (nr > 1) > > Lets also wrap it with WARN_ON? ACK, needs doing on x86 PVH too then. > > > + return -EINVAL; > > + > > + data.fgmfn = mfn; > > + data.prot = prot; > > + data.domid = domid; > > + data.vma = vma; > > + data.info = info; > > + err = apply_to_page_range(vma->vm_mm, addr, nr << PAGE_SHIFT, > > + remap_pte_fn, &data); > > + return err; > > } > > EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range); > > > > +/* Returns: Number of pages unmapped */ > > +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma, > > + struct xen_remap_mfn_info *info) > > +{ > > + int count = 0; > > + > > + while (info->pi_next_todo--) { > > + struct xen_remove_from_physmap xrp; > > + unsigned long rc, pfn; > > + > > + pfn = page_to_pfn(info->pi_paga[info->pi_next_todo]); > > Won't this miss the first pi_next_todo? You did the 'pi_next_todo--' so > will the compiler decrement it here in this operation or will it do > when it gets to the 'do' logic of the loop? It's a post decrement so if pi_next_todo == 1 then the expression in the while will see 1 (true) but inside the loop we see zero. So we end up processing elements N-1..0 of the array which is correct. This is the same as on x86 PVH, so if I'm wrong then that is too. I mentioned in the PVH thread this morning that I think this interface should drop pi_next_todo and have a simple for loop based on the number of pages between vm_start...vm_end here. > > > + > > + xrp.domid = DOMID_SELF; > > + xrp.gpfn = pfn; > > + rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, &xrp); > > 'rc' is 'unsigned long'. Is that right? You don't want it to be 'int'? Hypercalls return unsigned long these days, I think it was considered a mistake that some didn't. See <25744:47080c965937> in the hypervisor tree. Oh, wait, we are both wrong -- it's a long. I'll fix that... > > > + if (rc) { > > + pr_warn("Failed to unmap pfn:%lx rc:%ld\n", > > + pfn, rc); > > + return count; > > + } > > + count++; > > + } > > + return count; > > +} > > +EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range); > > + > > /* > > * see Documentation/devicetree/bindings/arm/xen.txt for the > > * documentation of the Xen Device Tree format. > > -- > > 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 15:49:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 15:49:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJnfo-0002WM-U7; Thu, 04 Oct 2012 15:49:16 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJnfn-0002WH-IQ for xen-devel@lists.xen.org; Thu, 04 Oct 2012 15:49:15 +0000 Received: from [85.158.143.99:4496] by server-2.bemta-4.messagelabs.com id F2/B3-06610-AFFAD605; Thu, 04 Oct 2012 15:49:14 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1349365754!25877864!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4052 invoked from network); 4 Oct 2012 15:49:14 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 15:49:14 -0000 X-IronPort-AV: E=Sophos;i="4.80,535,1344211200"; d="scan'208";a="14945955" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 15:48:39 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 16:48:39 +0100 Message-ID: <1349365718.866.63.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Konrad Rzeszutek Wilk Date: Thu, 4 Oct 2012 16:48:38 +0100 In-Reply-To: <20121004152459.GC11426@phenom.dumpdata.com> References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-11-git-send-email-ian.campbell@citrix.com> <20121004152459.GC11426@phenom.dumpdata.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH 11/14] arm: implement remap interfaces needed for privcmd mappings. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-10-04 at 16:24 +0100, Konrad Rzeszutek Wilk wrote: > On Thu, Oct 04, 2012 at 04:11:52PM +0100, Ian Campbell wrote: > > Signed-off-by: Ian Campbell > > --- > > arch/arm/xen/enlighten.c | 94 +++++++++++++++++++++++++++++++++++++++++++++- > > 1 files changed, 92 insertions(+), 2 deletions(-) > > > > diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c > > index ba5cc13..9956af5 100644 > > --- a/arch/arm/xen/enlighten.c > > +++ b/arch/arm/xen/enlighten.c > > @@ -9,6 +9,7 @@ > > #include > > #include > > #include > > +#include > > #include > > #include > > #include > > @@ -18,6 +19,8 @@ > > #include > > #include > > > > +#include > > + > > struct start_info _xen_start_info; > > struct start_info *xen_start_info = &_xen_start_info; > > EXPORT_SYMBOL_GPL(xen_start_info); > > @@ -43,15 +46,102 @@ EXPORT_SYMBOL_GPL(xen_platform_pci_unplug); > > > > static __read_mostly int xen_events_irq = -1; > > > > +/* map fgmfn of domid to lpfn in the current domain */ > > Say that really fast a couple of times :-) > > Any way we can explain it a bit more of what each acronym means? The names come from the x86 PVH version, which has the comment: /* Map foreign gmfn, fgmfn, to local pfn, lpfn. This for the user space * creating new guest on PVH dom0 and needs to map domU pages. */ Is that preferable? (modulo removing the PVH bit) > > > +static int map_foreign_page(unsigned long lpfn, unsigned long fgmfn, > > + unsigned int domid) > > +{ > > + int rc; > > + struct xen_add_to_physmap xatp = { > > + .domid = DOMID_SELF, > > + .u.foreign_domid = domid, > > + .space = XENMAPSPACE_gmfn_foreign, > > + .idx = fgmfn, > > + .gpfn = lpfn, > > + }; > > + > > + rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp); > > + if (rc) { > > + pr_warn("Failed to map pfn to mfn rc:%d pfn:%lx mfn:%lx\n", > > How about 'Failed to map pfn (0x%lx) to mfn (0x%lx), rc: %d\n" ? Sure, need to slip foreign domid in there somewhere now I look at it. x86 PVH has basically the same print BTW. > > > + rc, lpfn, fgmfn); > > + return 1; > > + } > > + return 0; > > +} > > + > > +struct remap_data { > > + unsigned long fgmfn; /* foreign domain's gmfn */ > > Shouldn't this be called now 'xen_pfn_t' or something. xen_pfn_t is needed at the hypervisor interface layer, I'm not so sure about kernel internal use. I guess it can't hurt? > > > + pgprot_t prot; > > + domid_t domid; > > + struct vm_area_struct *vma; > > + struct xen_remap_mfn_info *info; > > +}; > > + > > +static int remap_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr, > > + void *data) > > +{ > > + struct remap_data *info = data; > > + struct xen_remap_mfn_info *savp = info->info; > > + struct page *page = savp->pi_paga[savp->pi_next_todo++]; > > + unsigned long pfn = page_to_pfn(page); > > + pte_t pte = pfn_pte(pfn, info->prot); > > + > > + if (map_foreign_page(pfn, info->fgmfn, info->domid)) > > + return -EFAULT; > > + set_pte_at(info->vma->vm_mm, addr, ptep, pte); > > + > > + return 0; > > +} > > + > > int xen_remap_domain_mfn_range(struct vm_area_struct *vma, > > unsigned long addr, > > unsigned long mfn, int nr, > > - pgprot_t prot, unsigned domid) > > + pgprot_t prot, unsigned domid, > > + struct xen_remap_mfn_info *info) > > { > > - return -ENOSYS; > > + int err; > > + struct remap_data data; > > + > > + /* TBD: Batching, current sole caller only does page at a time */ > > + if (nr > 1) > > Lets also wrap it with WARN_ON? ACK, needs doing on x86 PVH too then. > > > + return -EINVAL; > > + > > + data.fgmfn = mfn; > > + data.prot = prot; > > + data.domid = domid; > > + data.vma = vma; > > + data.info = info; > > + err = apply_to_page_range(vma->vm_mm, addr, nr << PAGE_SHIFT, > > + remap_pte_fn, &data); > > + return err; > > } > > EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range); > > > > +/* Returns: Number of pages unmapped */ > > +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma, > > + struct xen_remap_mfn_info *info) > > +{ > > + int count = 0; > > + > > + while (info->pi_next_todo--) { > > + struct xen_remove_from_physmap xrp; > > + unsigned long rc, pfn; > > + > > + pfn = page_to_pfn(info->pi_paga[info->pi_next_todo]); > > Won't this miss the first pi_next_todo? You did the 'pi_next_todo--' so > will the compiler decrement it here in this operation or will it do > when it gets to the 'do' logic of the loop? It's a post decrement so if pi_next_todo == 1 then the expression in the while will see 1 (true) but inside the loop we see zero. So we end up processing elements N-1..0 of the array which is correct. This is the same as on x86 PVH, so if I'm wrong then that is too. I mentioned in the PVH thread this morning that I think this interface should drop pi_next_todo and have a simple for loop based on the number of pages between vm_start...vm_end here. > > > + > > + xrp.domid = DOMID_SELF; > > + xrp.gpfn = pfn; > > + rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, &xrp); > > 'rc' is 'unsigned long'. Is that right? You don't want it to be 'int'? Hypercalls return unsigned long these days, I think it was considered a mistake that some didn't. See <25744:47080c965937> in the hypervisor tree. Oh, wait, we are both wrong -- it's a long. I'll fix that... > > > + if (rc) { > > + pr_warn("Failed to unmap pfn:%lx rc:%ld\n", > > + pfn, rc); > > + return count; > > + } > > + count++; > > + } > > + return count; > > +} > > +EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range); > > + > > /* > > * see Documentation/devicetree/bindings/arm/xen.txt for the > > * documentation of the Xen Device Tree format. > > -- > > 1.7.2.5 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 16:05:57 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 16:05:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJnvg-0003Eq-FS; Thu, 04 Oct 2012 16:05:40 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJnve-0003El-3k for xen-devel@lists.xen.org; Thu, 04 Oct 2012 16:05:38 +0000 Received: from [85.158.143.35:15792] by server-1.bemta-4.messagelabs.com id 6B/07-05684-1D3BD605; Thu, 04 Oct 2012 16:05:37 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1349366734!14577990!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzgzMjE1\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20690 invoked from network); 4 Oct 2012 16:05:36 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Oct 2012 16:05:36 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q94G5Pf1001133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Oct 2012 16:05:25 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q94G5OV1026686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Oct 2012 16:05:24 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q94G5Nak030279; Thu, 4 Oct 2012 11:05:23 -0500 Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 04 Oct 2012 09:05:23 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 2456F4035E; Thu, 4 Oct 2012 11:54:00 -0400 (EDT) Date: Thu, 4 Oct 2012 11:54:00 -0400 From: Konrad Rzeszutek Wilk To: Ian Campbell Message-ID: <20121004155400.GA12128@phenom.dumpdata.com> References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-11-git-send-email-ian.campbell@citrix.com> <20121004152459.GC11426@phenom.dumpdata.com> <1349365718.866.63.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1349365718.866.63.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "xen-devel@lists.xen.org" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH 11/14] arm: implement remap interfaces needed for privcmd mappings. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, Oct 04, 2012 at 04:48:38PM +0100, Ian Campbell wrote: > On Thu, 2012-10-04 at 16:24 +0100, Konrad Rzeszutek Wilk wrote: > > On Thu, Oct 04, 2012 at 04:11:52PM +0100, Ian Campbell wrote: > > > Signed-off-by: Ian Campbell > > > --- > > > arch/arm/xen/enlighten.c | 94 +++++++++++++++++++++++++++++++++++++++++++++- > > > 1 files changed, 92 insertions(+), 2 deletions(-) > > > > > > diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c > > > index ba5cc13..9956af5 100644 > > > --- a/arch/arm/xen/enlighten.c > > > +++ b/arch/arm/xen/enlighten.c > > > @@ -9,6 +9,7 @@ > > > #include > > > #include > > > #include > > > +#include > > > #include > > > #include > > > #include > > > @@ -18,6 +19,8 @@ > > > #include > > > #include > > > > > > +#include > > > + > > > struct start_info _xen_start_info; > > > struct start_info *xen_start_info = &_xen_start_info; > > > EXPORT_SYMBOL_GPL(xen_start_info); > > > @@ -43,15 +46,102 @@ EXPORT_SYMBOL_GPL(xen_platform_pci_unplug); > > > > > > static __read_mostly int xen_events_irq = -1; > > > > > > +/* map fgmfn of domid to lpfn in the current domain */ > > > > Say that really fast a couple of times :-) > > > > Any way we can explain it a bit more of what each acronym means? > > The names come from the x86 PVH version, which has the comment: > /* Map foreign gmfn, fgmfn, to local pfn, lpfn. This for the user space > * creating new guest on PVH dom0 and needs to map domU pages. > */ > Is that preferable? (modulo removing the PVH bit) > > > > > > +static int map_foreign_page(unsigned long lpfn, unsigned long fgmfn, > > > + unsigned int domid) > > > +{ > > > + int rc; > > > + struct xen_add_to_physmap xatp = { > > > + .domid = DOMID_SELF, > > > + .u.foreign_domid = domid, > > > + .space = XENMAPSPACE_gmfn_foreign, > > > + .idx = fgmfn, > > > + .gpfn = lpfn, > > > + }; > > > + > > > + rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp); > > > + if (rc) { > > > + pr_warn("Failed to map pfn to mfn rc:%d pfn:%lx mfn:%lx\n", > > > > How about 'Failed to map pfn (0x%lx) to mfn (0x%lx), rc: %d\n" ? > > Sure, need to slip foreign domid in there somewhere now I look at it. > > x86 PVH has basically the same print BTW. OK, lets address that as well in the next review of the patchset. > > > > > > + rc, lpfn, fgmfn); > > > + return 1; > > > + } > > > + return 0; > > > +} > > > + > > > +struct remap_data { > > > + unsigned long fgmfn; /* foreign domain's gmfn */ > > > > Shouldn't this be called now 'xen_pfn_t' or something. > > xen_pfn_t is needed at the hypervisor interface layer, I'm not so sure > about kernel internal use. I guess it can't hurt? My thoughts.. as somebody might be wondering why here is unsigned long but other places it is not. > > > > > > + pgprot_t prot; > > > + domid_t domid; > > > + struct vm_area_struct *vma; > > > + struct xen_remap_mfn_info *info; > > > +}; > > > + > > > +static int remap_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr, > > > + void *data) > > > +{ > > > + struct remap_data *info = data; > > > + struct xen_remap_mfn_info *savp = info->info; > > > + struct page *page = savp->pi_paga[savp->pi_next_todo++]; > > > + unsigned long pfn = page_to_pfn(page); > > > + pte_t pte = pfn_pte(pfn, info->prot); > > > + > > > + if (map_foreign_page(pfn, info->fgmfn, info->domid)) > > > + return -EFAULT; > > > + set_pte_at(info->vma->vm_mm, addr, ptep, pte); > > > + > > > + return 0; > > > +} > > > + > > > int xen_remap_domain_mfn_range(struct vm_area_struct *vma, > > > unsigned long addr, > > > unsigned long mfn, int nr, > > > - pgprot_t prot, unsigned domid) > > > + pgprot_t prot, unsigned domid, > > > + struct xen_remap_mfn_info *info) > > > { > > > - return -ENOSYS; > > > + int err; > > > + struct remap_data data; > > > + > > > + /* TBD: Batching, current sole caller only does page at a time */ > > > + if (nr > 1) > > > > Lets also wrap it with WARN_ON? > > ACK, needs doing on x86 PVH too then. > > > > > > + return -EINVAL; > > > + > > > + data.fgmfn = mfn; > > > + data.prot = prot; > > > + data.domid = domid; > > > + data.vma = vma; > > > + data.info = info; > > > + err = apply_to_page_range(vma->vm_mm, addr, nr << PAGE_SHIFT, > > > + remap_pte_fn, &data); > > > + return err; > > > } > > > EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range); > > > > > > +/* Returns: Number of pages unmapped */ > > > +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma, > > > + struct xen_remap_mfn_info *info) > > > +{ > > > + int count = 0; > > > + > > > + while (info->pi_next_todo--) { > > > + struct xen_remove_from_physmap xrp; > > > + unsigned long rc, pfn; > > > + > > > + pfn = page_to_pfn(info->pi_paga[info->pi_next_todo]); > > > > Won't this miss the first pi_next_todo? You did the 'pi_next_todo--' so > > will the compiler decrement it here in this operation or will it do > > when it gets to the 'do' logic of the loop? > > It's a post decrement so if pi_next_todo == 1 then the expression in the > while will see 1 (true) but inside the loop we see zero. So we end up > processing elements N-1..0 of the array which is correct. OK. That is what I wanted to make sure about. > > This is the same as on x86 PVH, so if I'm wrong then that is too. > > I mentioned in the PVH thread this morning that I think this interface > should drop pi_next_todo and have a simple for loop based on the number > of pages between vm_start...vm_end here. Yeah, I think we need to do that. I understand Mukesh's desire to have an easy searchable name for variables, but that 'pi' just makes me think of bathroom, then of 3.1415, and then I have to actually recall really hard why it is called 'pi' .. and I still can't remember why. > > > > > > + > > > + xrp.domid = DOMID_SELF; > > > + xrp.gpfn = pfn; > > > + rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, &xrp); > > > > 'rc' is 'unsigned long'. Is that right? You don't want it to be 'int'? > > Hypercalls return unsigned long these days, I think it was considered a > mistake that some didn't. See <25744:47080c965937> in the hypervisor > tree. > > Oh, wait, we are both wrong -- it's a long. I'll fix that... > > > > > > + if (rc) { > > > + pr_warn("Failed to unmap pfn:%lx rc:%ld\n", > > > + pfn, rc); > > > + return count; > > > + } > > > + count++; > > > + } > > > + return count; > > > +} > > > +EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range); > > > + > > > /* > > > * see Documentation/devicetree/bindings/arm/xen.txt for the > > > * documentation of the Xen Device Tree format. > > > -- > > > 1.7.2.5 > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 16:05:57 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 16:05:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJnvg-0003Eq-FS; Thu, 04 Oct 2012 16:05:40 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJnve-0003El-3k for xen-devel@lists.xen.org; Thu, 04 Oct 2012 16:05:38 +0000 Received: from [85.158.143.35:15792] by server-1.bemta-4.messagelabs.com id 6B/07-05684-1D3BD605; Thu, 04 Oct 2012 16:05:37 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1349366734!14577990!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzgzMjE1\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20690 invoked from network); 4 Oct 2012 16:05:36 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Oct 2012 16:05:36 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q94G5Pf1001133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Oct 2012 16:05:25 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q94G5OV1026686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Oct 2012 16:05:24 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q94G5Nak030279; Thu, 4 Oct 2012 11:05:23 -0500 Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 04 Oct 2012 09:05:23 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 2456F4035E; Thu, 4 Oct 2012 11:54:00 -0400 (EDT) Date: Thu, 4 Oct 2012 11:54:00 -0400 From: Konrad Rzeszutek Wilk To: Ian Campbell Message-ID: <20121004155400.GA12128@phenom.dumpdata.com> References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-11-git-send-email-ian.campbell@citrix.com> <20121004152459.GC11426@phenom.dumpdata.com> <1349365718.866.63.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1349365718.866.63.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "xen-devel@lists.xen.org" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH 11/14] arm: implement remap interfaces needed for privcmd mappings. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, Oct 04, 2012 at 04:48:38PM +0100, Ian Campbell wrote: > On Thu, 2012-10-04 at 16:24 +0100, Konrad Rzeszutek Wilk wrote: > > On Thu, Oct 04, 2012 at 04:11:52PM +0100, Ian Campbell wrote: > > > Signed-off-by: Ian Campbell > > > --- > > > arch/arm/xen/enlighten.c | 94 +++++++++++++++++++++++++++++++++++++++++++++- > > > 1 files changed, 92 insertions(+), 2 deletions(-) > > > > > > diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c > > > index ba5cc13..9956af5 100644 > > > --- a/arch/arm/xen/enlighten.c > > > +++ b/arch/arm/xen/enlighten.c > > > @@ -9,6 +9,7 @@ > > > #include > > > #include > > > #include > > > +#include > > > #include > > > #include > > > #include > > > @@ -18,6 +19,8 @@ > > > #include > > > #include > > > > > > +#include > > > + > > > struct start_info _xen_start_info; > > > struct start_info *xen_start_info = &_xen_start_info; > > > EXPORT_SYMBOL_GPL(xen_start_info); > > > @@ -43,15 +46,102 @@ EXPORT_SYMBOL_GPL(xen_platform_pci_unplug); > > > > > > static __read_mostly int xen_events_irq = -1; > > > > > > +/* map fgmfn of domid to lpfn in the current domain */ > > > > Say that really fast a couple of times :-) > > > > Any way we can explain it a bit more of what each acronym means? > > The names come from the x86 PVH version, which has the comment: > /* Map foreign gmfn, fgmfn, to local pfn, lpfn. This for the user space > * creating new guest on PVH dom0 and needs to map domU pages. > */ > Is that preferable? (modulo removing the PVH bit) > > > > > > +static int map_foreign_page(unsigned long lpfn, unsigned long fgmfn, > > > + unsigned int domid) > > > +{ > > > + int rc; > > > + struct xen_add_to_physmap xatp = { > > > + .domid = DOMID_SELF, > > > + .u.foreign_domid = domid, > > > + .space = XENMAPSPACE_gmfn_foreign, > > > + .idx = fgmfn, > > > + .gpfn = lpfn, > > > + }; > > > + > > > + rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp); > > > + if (rc) { > > > + pr_warn("Failed to map pfn to mfn rc:%d pfn:%lx mfn:%lx\n", > > > > How about 'Failed to map pfn (0x%lx) to mfn (0x%lx), rc: %d\n" ? > > Sure, need to slip foreign domid in there somewhere now I look at it. > > x86 PVH has basically the same print BTW. OK, lets address that as well in the next review of the patchset. > > > > > > + rc, lpfn, fgmfn); > > > + return 1; > > > + } > > > + return 0; > > > +} > > > + > > > +struct remap_data { > > > + unsigned long fgmfn; /* foreign domain's gmfn */ > > > > Shouldn't this be called now 'xen_pfn_t' or something. > > xen_pfn_t is needed at the hypervisor interface layer, I'm not so sure > about kernel internal use. I guess it can't hurt? My thoughts.. as somebody might be wondering why here is unsigned long but other places it is not. > > > > > > + pgprot_t prot; > > > + domid_t domid; > > > + struct vm_area_struct *vma; > > > + struct xen_remap_mfn_info *info; > > > +}; > > > + > > > +static int remap_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr, > > > + void *data) > > > +{ > > > + struct remap_data *info = data; > > > + struct xen_remap_mfn_info *savp = info->info; > > > + struct page *page = savp->pi_paga[savp->pi_next_todo++]; > > > + unsigned long pfn = page_to_pfn(page); > > > + pte_t pte = pfn_pte(pfn, info->prot); > > > + > > > + if (map_foreign_page(pfn, info->fgmfn, info->domid)) > > > + return -EFAULT; > > > + set_pte_at(info->vma->vm_mm, addr, ptep, pte); > > > + > > > + return 0; > > > +} > > > + > > > int xen_remap_domain_mfn_range(struct vm_area_struct *vma, > > > unsigned long addr, > > > unsigned long mfn, int nr, > > > - pgprot_t prot, unsigned domid) > > > + pgprot_t prot, unsigned domid, > > > + struct xen_remap_mfn_info *info) > > > { > > > - return -ENOSYS; > > > + int err; > > > + struct remap_data data; > > > + > > > + /* TBD: Batching, current sole caller only does page at a time */ > > > + if (nr > 1) > > > > Lets also wrap it with WARN_ON? > > ACK, needs doing on x86 PVH too then. > > > > > > + return -EINVAL; > > > + > > > + data.fgmfn = mfn; > > > + data.prot = prot; > > > + data.domid = domid; > > > + data.vma = vma; > > > + data.info = info; > > > + err = apply_to_page_range(vma->vm_mm, addr, nr << PAGE_SHIFT, > > > + remap_pte_fn, &data); > > > + return err; > > > } > > > EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range); > > > > > > +/* Returns: Number of pages unmapped */ > > > +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma, > > > + struct xen_remap_mfn_info *info) > > > +{ > > > + int count = 0; > > > + > > > + while (info->pi_next_todo--) { > > > + struct xen_remove_from_physmap xrp; > > > + unsigned long rc, pfn; > > > + > > > + pfn = page_to_pfn(info->pi_paga[info->pi_next_todo]); > > > > Won't this miss the first pi_next_todo? You did the 'pi_next_todo--' so > > will the compiler decrement it here in this operation or will it do > > when it gets to the 'do' logic of the loop? > > It's a post decrement so if pi_next_todo == 1 then the expression in the > while will see 1 (true) but inside the loop we see zero. So we end up > processing elements N-1..0 of the array which is correct. OK. That is what I wanted to make sure about. > > This is the same as on x86 PVH, so if I'm wrong then that is too. > > I mentioned in the PVH thread this morning that I think this interface > should drop pi_next_todo and have a simple for loop based on the number > of pages between vm_start...vm_end here. Yeah, I think we need to do that. I understand Mukesh's desire to have an easy searchable name for variables, but that 'pi' just makes me think of bathroom, then of 3.1415, and then I have to actually recall really hard why it is called 'pi' .. and I still can't remember why. > > > > > > + > > > + xrp.domid = DOMID_SELF; > > > + xrp.gpfn = pfn; > > > + rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, &xrp); > > > > 'rc' is 'unsigned long'. Is that right? You don't want it to be 'int'? > > Hypercalls return unsigned long these days, I think it was considered a > mistake that some didn't. See <25744:47080c965937> in the hypervisor > tree. > > Oh, wait, we are both wrong -- it's a long. I'll fix that... > > > > > > + if (rc) { > > > + pr_warn("Failed to unmap pfn:%lx rc:%ld\n", > > > + pfn, rc); > > > + return count; > > > + } > > > + count++; > > > + } > > > + return count; > > > +} > > > +EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range); > > > + > > > /* > > > * see Documentation/devicetree/bindings/arm/xen.txt for the > > > * documentation of the Xen Device Tree format. > > > -- > > > 1.7.2.5 > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 16:11:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 16:11:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJo0l-0003QU-CR; Thu, 04 Oct 2012 16:10:55 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJo0k-0003QP-Ia for xen-devel@lists.xensource.com; Thu, 04 Oct 2012 16:10:54 +0000 Received: from [85.158.143.35:62773] by server-1.bemta-4.messagelabs.com id 7C/C3-05684-D05BD605; Thu, 04 Oct 2012 16:10:53 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-16.tower-21.messagelabs.com!1349367051!14851140!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30745 invoked from network); 4 Oct 2012 16:10:52 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 16:10:52 -0000 X-IronPort-AV: E=Sophos;i="4.80,537,1344211200"; d="scan'208";a="14946410" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 16:10:51 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 17:10:51 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TJo0h-0004ig-BB; Thu, 04 Oct 2012 16:10:51 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1TJo0g-0007p2-UP; Thu, 04 Oct 2012 17:10:51 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Thu, 4 Oct 2012 17:10:51 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.1-testing test] 13919: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 13919 xen-4.1-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13919/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-pcipt-intel 8 debian-fixup fail like 13867 test-amd64-amd64-xl-sedf 5 xen-boot fail like 13867 Tests which did not succeed, but are not blocking: test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check fail never pass test-amd64-i386-rhel6hvm-amd 11 leak-check/check fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop fail never pass version targeted for testing: xen a15596a619ed baseline version: xen fb0561ba7d9e ------------------------------------------------------------ People who touched revisions under test: Dan Magenheimer Daniel De Graaf Ian Jackson Jan Beulich Keir Fraser Zhenzhong Duan ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-4.1-testing + revision=a15596a619ed + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.1-testing a15596a619ed + branch=xen-4.1-testing + revision=a15596a619ed + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + . cri-common ++ umask 002 + select_xenbranch + case "$branch" in + tree=xen + xenbranch=xen-4.1-testing + '[' xxen = xlinux ']' + linuxbranch=linux + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : http://xenbits.xen.org/hg/staging/xen-4.1-testing.hg ++ : git://xenbits.xen.org/staging/qemu-xen-4.1-testing.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.xen-4.1-testing ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-4.1-testing.git ++ : daily-cron.xen-4.1-testing + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.1-testing.git + info_linux_tree xen-4.1-testing + case $1 in + return 1 + case "$branch" in + cd /export/home/osstest/repos/xen-4.1-testing.hg + hg push -r a15596a619ed ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 7 changesets with 20 changes to 18 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 16:11:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 16:11:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJo0l-0003QU-CR; Thu, 04 Oct 2012 16:10:55 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJo0k-0003QP-Ia for xen-devel@lists.xensource.com; Thu, 04 Oct 2012 16:10:54 +0000 Received: from [85.158.143.35:62773] by server-1.bemta-4.messagelabs.com id 7C/C3-05684-D05BD605; Thu, 04 Oct 2012 16:10:53 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-16.tower-21.messagelabs.com!1349367051!14851140!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30745 invoked from network); 4 Oct 2012 16:10:52 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 16:10:52 -0000 X-IronPort-AV: E=Sophos;i="4.80,537,1344211200"; d="scan'208";a="14946410" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 16:10:51 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 17:10:51 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TJo0h-0004ig-BB; Thu, 04 Oct 2012 16:10:51 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1TJo0g-0007p2-UP; Thu, 04 Oct 2012 17:10:51 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Thu, 4 Oct 2012 17:10:51 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.1-testing test] 13919: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 13919 xen-4.1-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13919/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-pcipt-intel 8 debian-fixup fail like 13867 test-amd64-amd64-xl-sedf 5 xen-boot fail like 13867 Tests which did not succeed, but are not blocking: test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check fail never pass test-amd64-i386-rhel6hvm-amd 11 leak-check/check fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop fail never pass version targeted for testing: xen a15596a619ed baseline version: xen fb0561ba7d9e ------------------------------------------------------------ People who touched revisions under test: Dan Magenheimer Daniel De Graaf Ian Jackson Jan Beulich Keir Fraser Zhenzhong Duan ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-4.1-testing + revision=a15596a619ed + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.1-testing a15596a619ed + branch=xen-4.1-testing + revision=a15596a619ed + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + . cri-common ++ umask 002 + select_xenbranch + case "$branch" in + tree=xen + xenbranch=xen-4.1-testing + '[' xxen = xlinux ']' + linuxbranch=linux + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : http://xenbits.xen.org/hg/staging/xen-4.1-testing.hg ++ : git://xenbits.xen.org/staging/qemu-xen-4.1-testing.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.xen-4.1-testing ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-4.1-testing.git ++ : daily-cron.xen-4.1-testing + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.1-testing.git + info_linux_tree xen-4.1-testing + case $1 in + return 1 + case "$branch" in + cd /export/home/osstest/repos/xen-4.1-testing.hg + hg push -r a15596a619ed ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 7 changesets with 20 changes to 18 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 16:19:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 16:19:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJo8R-0003nj-Oc; Thu, 04 Oct 2012 16:18:51 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJo8Q-0003nM-DJ for xen-devel@lists.xen.org; Thu, 04 Oct 2012 16:18:50 +0000 Received: from [85.158.139.83:6493] by server-11.bemta-5.messagelabs.com id EC/99-13866-9E6BD605; Thu, 04 Oct 2012 16:18:49 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1349367525!29560697!3 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQyMDg=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8568 invoked from network); 4 Oct 2012 16:18:48 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 16:18:48 -0000 X-IronPort-AV: E=Sophos;i="4.80,537,1344211200"; d="scan'208";a="40164142" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 16:18:45 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 12:18:44 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJo8K-0003cd-H1; Thu, 04 Oct 2012 17:18:44 +0100 From: Anthony PERARD To: Xen Devel Date: Thu, 4 Oct 2012 17:18:41 +0100 Message-ID: <1349367522-16695-2-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1349367522-16695-1-git-send-email-anthony.perard@citrix.com> References: <1349367522-16695-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Cc: Anthony PERARD , Ian Jackson , Ian Campbell Subject: [Xen-devel] [PATCH V2 1/2] libxl: Have flexarray using the GC X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch makes the flexarray function libxl__gc aware. It also updates every function that use a flexarray to pass the gc and removes every memory allocation check and free. Signed-off-by: Anthony PERARD --- tools/libxl/flexarray.c | 48 ++++++++++++++--------- tools/libxl/flexarray.h | 7 +++- tools/libxl/libxl.c | 99 ++++++++++-------------------------------------- tools/libxl/libxl_dm.c | 15 ++------ tools/libxl/libxl_json.c | 8 +--- tools/libxl/libxl_pci.c | 18 ++------- tools/libxl/libxl_qmp.c | 28 ++------------ 7 files changed, 65 insertions(+), 158 deletions(-) diff --git a/tools/libxl/flexarray.c b/tools/libxl/flexarray.c index edf616c..ab74c51 100644 --- a/tools/libxl/flexarray.c +++ b/tools/libxl/flexarray.c @@ -16,36 +16,48 @@ #include "libxl_internal.h" #include -flexarray_t *flexarray_make(int size, int autogrow) +/* + * It is safe to store gc in the struct because: + * - If it an actual gc, then the flexarray should not be used after the gc + * have been freed. + * - If it is a NOGC, then this point to a structure embedded in libxl_ctx, + * therefore will survive across several libxl calls. + */ + +flexarray_t *flexarray_make(libxl__gc *gc, int size, int autogrow) { - flexarray_t *array = malloc(sizeof(struct flexarray)); - if (array) { - array->size = size; - array->autogrow = autogrow; - array->count = 0; - array->data = calloc(size, sizeof(void *)); - } + flexarray_t *array; + + GCNEW(array); + array->size = size; + array->autogrow = autogrow; + array->count = 0; + array->gc = gc; + GCNEW_ARRAY(array->data, size); + return array; } +static int gc_is_real(const libxl__gc *gc) +{ + return gc->alloc_maxsize >= 0; +} + void flexarray_free(flexarray_t *array) { + assert(!gc_is_real(array->gc)); free(array->data); free(array); } -int flexarray_grow(flexarray_t *array, int extents) +void flexarray_grow(flexarray_t *array, int extents) { - void **data; int newsize; + libxl__gc *gc = array->gc; newsize = array->size + extents; - data = realloc(array->data, sizeof(void *) * newsize); - if (!data) - return 1; + GCREALLOC_ARRAY(array->data, newsize); array->size += extents; - array->data = data; - return 0; } int flexarray_set(flexarray_t *array, unsigned int idx, void *ptr) @@ -55,8 +67,7 @@ int flexarray_set(flexarray_t *array, unsigned int idx, void *ptr) if (!array->autogrow) return 1; newsize = (array->size * 2 < idx) ? idx + 1 : array->size * 2; - if (flexarray_grow(array, newsize - array->size)) - return 2; + flexarray_grow(array, newsize - array->size); } if ( idx + 1 > array->count ) array->count = idx + 1; @@ -104,7 +115,8 @@ void **flexarray_contents(flexarray_t *array) { void **data; data = array->data; - free(array); + if (!gc_is_real(array->gc)) + free(array); return data; } diff --git a/tools/libxl/flexarray.h b/tools/libxl/flexarray.h index ae17f3b..aade417 100644 --- a/tools/libxl/flexarray.h +++ b/tools/libxl/flexarray.h @@ -16,16 +16,19 @@ #ifndef FLEXARRAY_H #define FLEXARRAY_H +struct libxl__gc; + typedef struct flexarray { int size; int autogrow; unsigned int count; void **data; /* array of pointer */ + struct libxl__gc *gc; } flexarray_t; -_hidden flexarray_t *flexarray_make(int size, int autogrow); +_hidden flexarray_t *flexarray_make(struct libxl__gc *gc, int size, int autogrow); _hidden void flexarray_free(flexarray_t *array); -_hidden int flexarray_grow(flexarray_t *array, int extents); +_hidden void flexarray_grow(flexarray_t *array, int extents); _hidden int flexarray_set(flexarray_t *array, unsigned int index, void *ptr); _hidden int flexarray_append(flexarray_t *array, void *ptr); _hidden int flexarray_append_pair(flexarray_t *array, void *ptr1, void *ptr2); diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c index 1606eb1..af3682f 100644 --- a/tools/libxl/libxl.c +++ b/tools/libxl/libxl.c @@ -1820,27 +1820,15 @@ static void device_disk_add(libxl__egc *egc, uint32_t domid, rc = libxl__device_disk_setdefault(gc, disk); if (rc) goto out; - if (front) - flexarray_free(front); - front = flexarray_make(16, 1); - if (!front) { - rc = ERROR_NOMEM; - goto out; - } - if (back) - flexarray_free(back); - back = flexarray_make(16, 1); - if (!back) { - rc = ERROR_NOMEM; - goto out_free; - } + front = flexarray_make(gc, 16, 1); + back = flexarray_make(gc, 16, 1); GCNEW(device); rc = libxl__device_from_disk(gc, domid, disk, device); if (rc != 0) { LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported" " virtual disk identifier %s", disk->vdev); - goto out_free; + goto out; } switch (disk->backend) { @@ -1878,7 +1866,7 @@ static void device_disk_add(libxl__egc *egc, uint32_t domid, LOG(ERROR, "failed to get blktap devpath for %p\n", disk->pdev_path); rc = ERROR_FAIL; - goto out_free; + goto out; } flexarray_append(back, "tapdisk-params"); flexarray_append(back, libxl__sprintf(gc, "%s:%s", @@ -1900,7 +1888,7 @@ static void device_disk_add(libxl__egc *egc, uint32_t domid, default: LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n", disk->backend); rc = ERROR_INVAL; - goto out_free; + goto out; } flexarray_append(back, "frontend-id"); @@ -1937,7 +1925,7 @@ static void device_disk_add(libxl__egc *egc, uint32_t domid, rc = libxl__xs_transaction_commit(gc, &t); if (!rc) break; - if (rc < 0) goto out_free; + if (rc < 0) goto out; } aodev->dev = device; @@ -1946,9 +1934,6 @@ static void device_disk_add(libxl__egc *egc, uint32_t domid, rc = 0; -out_free: - flexarray_free(back); - flexarray_free(front); out: libxl__xs_transaction_abort(gc, &t); aodev->rc = rc; @@ -2204,7 +2189,7 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk, if (rc) goto out; path = libxl__device_backend_path(gc, &device); - insert = flexarray_make(4, 1); + insert = flexarray_make(gc, 4, 1); flexarray_append_pair(insert, "type", libxl__device_disk_string_of_backend(disk->backend)); @@ -2230,8 +2215,6 @@ out: libxl_device_disk_dispose(&disks[i]); free(disks); - if (insert) flexarray_free(insert); - if (rc) return AO_ABORT(rc); return AO_INPROGRESS; } @@ -2567,21 +2550,13 @@ void libxl__device_nic_add(libxl__egc *egc, uint32_t domid, rc = libxl__device_nic_setdefault(gc, nic, domid); if (rc) goto out; - front = flexarray_make(16, 1); - if (!front) { - rc = ERROR_NOMEM; - goto out; - } - back = flexarray_make(16, 1); - if (!back) { - rc = ERROR_NOMEM; - goto out_free; - } + front = flexarray_make(gc, 16, 1); + back = flexarray_make(gc, 16, 1); if (nic->devid == -1) { if (!(dompath = libxl__xs_get_dompath(gc, domid))) { rc = ERROR_FAIL; - goto out_free; + goto out; } if (!(l = libxl__xs_directory(gc, XBT_NULL, libxl__sprintf(gc, "%s/device/vif", dompath), &nb))) { @@ -2593,7 +2568,7 @@ void libxl__device_nic_add(libxl__egc *egc, uint32_t domid, GCNEW(device); rc = libxl__device_from_nic(gc, domid, nic, device); - if ( rc != 0 ) goto out_free; + if ( rc != 0 ) goto out; flexarray_append(back, "frontend-id"); flexarray_append(back, libxl__sprintf(gc, "%d", domid)); @@ -2652,9 +2627,6 @@ void libxl__device_nic_add(libxl__egc *egc, uint32_t domid, libxl__wait_device_connection(egc, aodev); rc = 0; -out_free: - flexarray_free(back); - flexarray_free(front); out: aodev->rc = rc; if (rc) aodev->callback(egc, aodev); @@ -2851,16 +2823,8 @@ int libxl__device_console_add(libxl__gc *gc, uint32_t domid, goto out; } - front = flexarray_make(16, 1); - if (!front) { - rc = ERROR_NOMEM; - goto out; - } - back = flexarray_make(16, 1); - if (!back) { - rc = ERROR_NOMEM; - goto out_free; - } + front = flexarray_make(gc, 16, 1); + back = flexarray_make(gc, 16, 1); device.backend_devid = console->devid; device.backend_domid = console->backend_domid; @@ -2908,9 +2872,6 @@ int libxl__device_console_add(libxl__gc *gc, uint32_t domid, libxl__xs_kvs_of_flexarray(gc, back, back->count), libxl__xs_kvs_of_flexarray(gc, front, front->count)); rc = 0; -out_free: - flexarray_free(back); - flexarray_free(front); out: return rc; } @@ -2964,19 +2925,11 @@ int libxl__device_vkb_add(libxl__gc *gc, uint32_t domid, rc = libxl__device_vkb_setdefault(gc, vkb); if (rc) goto out; - front = flexarray_make(16, 1); - if (!front) { - rc = ERROR_NOMEM; - goto out; - } - back = flexarray_make(16, 1); - if (!back) { - rc = ERROR_NOMEM; - goto out_free; - } + front = flexarray_make(gc, 16, 1); + back = flexarray_make(gc, 16, 1); rc = libxl__device_from_vkb(gc, domid, vkb, &device); - if (rc != 0) goto out_free; + if (rc != 0) goto out; flexarray_append(back, "frontend-id"); flexarray_append(back, libxl__sprintf(gc, "%d", domid)); @@ -2996,9 +2949,6 @@ int libxl__device_vkb_add(libxl__gc *gc, uint32_t domid, libxl__xs_kvs_of_flexarray(gc, back, back->count), libxl__xs_kvs_of_flexarray(gc, front, front->count)); rc = 0; -out_free: - flexarray_free(back); - flexarray_free(front); out: return rc; } @@ -3063,19 +3013,11 @@ int libxl__device_vfb_add(libxl__gc *gc, uint32_t domid, libxl_device_vfb *vfb) rc = libxl__device_vfb_setdefault(gc, vfb); if (rc) goto out; - front = flexarray_make(16, 1); - if (!front) { - rc = ERROR_NOMEM; - goto out; - } - back = flexarray_make(16, 1); - if (!back) { - rc = ERROR_NOMEM; - goto out_free; - } + front = flexarray_make(gc, 16, 1); + back = flexarray_make(gc, 16, 1); rc = libxl__device_from_vfb(gc, domid, vfb, &device); - if (rc != 0) goto out_free; + if (rc != 0) goto out; flexarray_append_pair(back, "frontend-id", libxl__sprintf(gc, "%d", domid)); flexarray_append_pair(back, "online", "1"); @@ -3108,9 +3050,6 @@ int libxl__device_vfb_add(libxl__gc *gc, uint32_t domid, libxl_device_vfb *vfb) libxl__xs_kvs_of_flexarray(gc, back, back->count), libxl__xs_kvs_of_flexarray(gc, front, front->count)); rc = 0; -out_free: - flexarray_free(front); - flexarray_free(back); out: return rc; } diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c index 3be7bad..82d2009 100644 --- a/tools/libxl/libxl_dm.c +++ b/tools/libxl/libxl_dm.c @@ -109,10 +109,7 @@ static char ** libxl__build_device_model_args_old(libxl__gc *gc, const char *keymap = dm_keymap(guest_config); int i; flexarray_t *dm_args; - dm_args = flexarray_make(16, 1); - - if (!dm_args) - return NULL; + dm_args = flexarray_make(gc, 16, 1); flexarray_vappend(dm_args, dm, "-d", libxl__sprintf(gc, "%d", domid), NULL); @@ -340,9 +337,7 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc, int i; uint64_t ram_size; - dm_args = flexarray_make(16, 1); - if (!dm_args) - return NULL; + dm_args = flexarray_make(gc, 16, 1); flexarray_vappend(dm_args, dm, "-xen-domid", @@ -837,7 +832,7 @@ void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state *sdss) "setting target domain %d -> %d", dm_domid, guest_domid); ret = ERROR_FAIL; - goto out_free; + goto out; } xs_set_target(ctx->xsh, dm_domid, guest_domid); @@ -861,11 +856,8 @@ retry_transaction: libxl__add_disks(egc, ao, dm_domid, dm_config, &sdss->multidev); libxl__multidev_prepared(egc, &sdss->multidev, 0); - free(args); return; -out_free: - free(args); out: assert(ret); spawn_stubdom_pvqemu_cb(egc, &sdss->pvqemu, ret); @@ -1165,7 +1157,6 @@ retry_transaction: out_close: close(null); close(logfile_w); - free(args); out: if (rc) device_model_spawn_outcome(egc, dmss, rc); diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c index 8e17842..2e6322b 100644 --- a/tools/libxl/libxl_json.c +++ b/tools/libxl/libxl_json.c @@ -220,13 +220,7 @@ static libxl__json_object *json_object_alloc(libxl__gc *gc, obj->type = type; if (type == JSON_MAP || type == JSON_ARRAY) { - flexarray_t *array = flexarray_make(1, 1); - if (array == NULL) { - LIBXL__LOG_ERRNO(libxl__gc_owner(gc), LIBXL__LOG_ERROR, - "Failed to allocate a flexarray"); - free(obj); - return NULL; - } + flexarray_t *array = flexarray_make(NOGC, 1, 1); if (type == JSON_MAP) obj->u.map = array; else diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c index ff447e7..eac35c1 100644 --- a/tools/libxl/libxl_pci.c +++ b/tools/libxl/libxl_pci.c @@ -73,12 +73,8 @@ int libxl__create_pci_backend(libxl__gc *gc, uint32_t domid, libxl__device device; int ret = ERROR_NOMEM, i; - front = flexarray_make(16, 1); - if (!front) - goto out; - back = flexarray_make(16, 1); - if (!back) - goto out; + front = flexarray_make(gc, 16, 1); + back = flexarray_make(gc, 16, 1); ret = 0; @@ -108,11 +104,6 @@ int libxl__create_pci_backend(libxl__gc *gc, uint32_t domid, libxl__xs_kvs_of_flexarray(gc, back, back->count), libxl__xs_kvs_of_flexarray(gc, front, front->count)); -out: - if (back) - flexarray_free(back); - if (front) - flexarray_free(front); return 0; } @@ -138,9 +129,7 @@ static int libxl__device_pci_add_xenstore(libxl__gc *gc, uint32_t domid, libxl_d return ERROR_FAIL; } - back = flexarray_make(16, 1); - if (!back) - return ERROR_NOMEM; + back = flexarray_make(gc, 16, 1); LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Adding new pci device to xenstore"); num = atoi(num_devs); @@ -157,7 +146,6 @@ retry_transaction: if (errno == EAGAIN) goto retry_transaction; - flexarray_free(back); return 0; } diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c index 2c4d269..6bdf924 100644 --- a/tools/libxl/libxl_qmp.c +++ b/tools/libxl/libxl_qmp.c @@ -763,7 +763,7 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev) if (!hostaddr) return -1; - parameters = flexarray_make(6, 1); + parameters = flexarray_make(gc, 6, 1); flexarray_append_pair(parameters, "driver", "xen-pci-passthrough"); flexarray_append_pair(parameters, "id", libxl__sprintf(gc, PCI_PT_QDEV_ID, @@ -777,8 +777,6 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev) PCI_FUNC(pcidev->vdevfn))); } args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count); - if (!args) - return -1; rc = qmp_synchronous_send(qmp, "device_add", &args, NULL, NULL, qmp->timeout); @@ -787,7 +785,6 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev) pci_add_callback, pcidev, qmp->timeout); } - flexarray_free(parameters); libxl__qmp_close(qmp); return rc; } @@ -803,16 +800,13 @@ static int qmp_device_del(libxl__gc *gc, int domid, char *id) if (!qmp) return ERROR_FAIL; - parameters = flexarray_make(2, 1); + parameters = flexarray_make(gc, 2, 1); flexarray_append_pair(parameters, "id", id); args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count); - if (!args) - return ERROR_NOMEM; rc = qmp_synchronous_send(qmp, "device_del", &args, NULL, NULL, qmp->timeout); - flexarray_free(parameters); libxl__qmp_close(qmp); return rc; } @@ -838,24 +832,13 @@ int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename) if (!qmp) return ERROR_FAIL; - parameters = flexarray_make(2, 1); - if (!parameters) { - rc = ERROR_NOMEM; - goto out; - } + parameters = flexarray_make(gc, 2, 1); flexarray_append_pair(parameters, "filename", (char *)filename); args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count); - if (!args) { - rc = ERROR_NOMEM; - goto out2; - } rc = qmp_synchronous_send(qmp, "xen-save-devices-state", &args, NULL, NULL, qmp->timeout); -out2: - flexarray_free(parameters); -out: libxl__qmp_close(qmp); return rc; } @@ -867,19 +850,16 @@ static int qmp_change(libxl__gc *gc, libxl__qmp_handler *qmp, libxl_key_value_list args = NULL; int rc = 0; - parameters = flexarray_make(6, 1); + parameters = flexarray_make(gc, 6, 1); flexarray_append_pair(parameters, "device", device); flexarray_append_pair(parameters, "target", target); if (arg) flexarray_append_pair(parameters, "arg", arg); args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count); - if (!args) - return ERROR_NOMEM; rc = qmp_synchronous_send(qmp, "change", &args, NULL, NULL, qmp->timeout); - flexarray_free(parameters); return rc; } -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 16:19:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 16:19:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJo8R-0003nj-Oc; Thu, 04 Oct 2012 16:18:51 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJo8Q-0003nM-DJ for xen-devel@lists.xen.org; Thu, 04 Oct 2012 16:18:50 +0000 Received: from [85.158.139.83:6493] by server-11.bemta-5.messagelabs.com id EC/99-13866-9E6BD605; Thu, 04 Oct 2012 16:18:49 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1349367525!29560697!3 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQyMDg=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8568 invoked from network); 4 Oct 2012 16:18:48 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 16:18:48 -0000 X-IronPort-AV: E=Sophos;i="4.80,537,1344211200"; d="scan'208";a="40164142" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 16:18:45 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 12:18:44 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJo8K-0003cd-H1; Thu, 04 Oct 2012 17:18:44 +0100 From: Anthony PERARD To: Xen Devel Date: Thu, 4 Oct 2012 17:18:41 +0100 Message-ID: <1349367522-16695-2-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1349367522-16695-1-git-send-email-anthony.perard@citrix.com> References: <1349367522-16695-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Cc: Anthony PERARD , Ian Jackson , Ian Campbell Subject: [Xen-devel] [PATCH V2 1/2] libxl: Have flexarray using the GC X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch makes the flexarray function libxl__gc aware. It also updates every function that use a flexarray to pass the gc and removes every memory allocation check and free. Signed-off-by: Anthony PERARD --- tools/libxl/flexarray.c | 48 ++++++++++++++--------- tools/libxl/flexarray.h | 7 +++- tools/libxl/libxl.c | 99 ++++++++++-------------------------------------- tools/libxl/libxl_dm.c | 15 ++------ tools/libxl/libxl_json.c | 8 +--- tools/libxl/libxl_pci.c | 18 ++------- tools/libxl/libxl_qmp.c | 28 ++------------ 7 files changed, 65 insertions(+), 158 deletions(-) diff --git a/tools/libxl/flexarray.c b/tools/libxl/flexarray.c index edf616c..ab74c51 100644 --- a/tools/libxl/flexarray.c +++ b/tools/libxl/flexarray.c @@ -16,36 +16,48 @@ #include "libxl_internal.h" #include -flexarray_t *flexarray_make(int size, int autogrow) +/* + * It is safe to store gc in the struct because: + * - If it an actual gc, then the flexarray should not be used after the gc + * have been freed. + * - If it is a NOGC, then this point to a structure embedded in libxl_ctx, + * therefore will survive across several libxl calls. + */ + +flexarray_t *flexarray_make(libxl__gc *gc, int size, int autogrow) { - flexarray_t *array = malloc(sizeof(struct flexarray)); - if (array) { - array->size = size; - array->autogrow = autogrow; - array->count = 0; - array->data = calloc(size, sizeof(void *)); - } + flexarray_t *array; + + GCNEW(array); + array->size = size; + array->autogrow = autogrow; + array->count = 0; + array->gc = gc; + GCNEW_ARRAY(array->data, size); + return array; } +static int gc_is_real(const libxl__gc *gc) +{ + return gc->alloc_maxsize >= 0; +} + void flexarray_free(flexarray_t *array) { + assert(!gc_is_real(array->gc)); free(array->data); free(array); } -int flexarray_grow(flexarray_t *array, int extents) +void flexarray_grow(flexarray_t *array, int extents) { - void **data; int newsize; + libxl__gc *gc = array->gc; newsize = array->size + extents; - data = realloc(array->data, sizeof(void *) * newsize); - if (!data) - return 1; + GCREALLOC_ARRAY(array->data, newsize); array->size += extents; - array->data = data; - return 0; } int flexarray_set(flexarray_t *array, unsigned int idx, void *ptr) @@ -55,8 +67,7 @@ int flexarray_set(flexarray_t *array, unsigned int idx, void *ptr) if (!array->autogrow) return 1; newsize = (array->size * 2 < idx) ? idx + 1 : array->size * 2; - if (flexarray_grow(array, newsize - array->size)) - return 2; + flexarray_grow(array, newsize - array->size); } if ( idx + 1 > array->count ) array->count = idx + 1; @@ -104,7 +115,8 @@ void **flexarray_contents(flexarray_t *array) { void **data; data = array->data; - free(array); + if (!gc_is_real(array->gc)) + free(array); return data; } diff --git a/tools/libxl/flexarray.h b/tools/libxl/flexarray.h index ae17f3b..aade417 100644 --- a/tools/libxl/flexarray.h +++ b/tools/libxl/flexarray.h @@ -16,16 +16,19 @@ #ifndef FLEXARRAY_H #define FLEXARRAY_H +struct libxl__gc; + typedef struct flexarray { int size; int autogrow; unsigned int count; void **data; /* array of pointer */ + struct libxl__gc *gc; } flexarray_t; -_hidden flexarray_t *flexarray_make(int size, int autogrow); +_hidden flexarray_t *flexarray_make(struct libxl__gc *gc, int size, int autogrow); _hidden void flexarray_free(flexarray_t *array); -_hidden int flexarray_grow(flexarray_t *array, int extents); +_hidden void flexarray_grow(flexarray_t *array, int extents); _hidden int flexarray_set(flexarray_t *array, unsigned int index, void *ptr); _hidden int flexarray_append(flexarray_t *array, void *ptr); _hidden int flexarray_append_pair(flexarray_t *array, void *ptr1, void *ptr2); diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c index 1606eb1..af3682f 100644 --- a/tools/libxl/libxl.c +++ b/tools/libxl/libxl.c @@ -1820,27 +1820,15 @@ static void device_disk_add(libxl__egc *egc, uint32_t domid, rc = libxl__device_disk_setdefault(gc, disk); if (rc) goto out; - if (front) - flexarray_free(front); - front = flexarray_make(16, 1); - if (!front) { - rc = ERROR_NOMEM; - goto out; - } - if (back) - flexarray_free(back); - back = flexarray_make(16, 1); - if (!back) { - rc = ERROR_NOMEM; - goto out_free; - } + front = flexarray_make(gc, 16, 1); + back = flexarray_make(gc, 16, 1); GCNEW(device); rc = libxl__device_from_disk(gc, domid, disk, device); if (rc != 0) { LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported" " virtual disk identifier %s", disk->vdev); - goto out_free; + goto out; } switch (disk->backend) { @@ -1878,7 +1866,7 @@ static void device_disk_add(libxl__egc *egc, uint32_t domid, LOG(ERROR, "failed to get blktap devpath for %p\n", disk->pdev_path); rc = ERROR_FAIL; - goto out_free; + goto out; } flexarray_append(back, "tapdisk-params"); flexarray_append(back, libxl__sprintf(gc, "%s:%s", @@ -1900,7 +1888,7 @@ static void device_disk_add(libxl__egc *egc, uint32_t domid, default: LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n", disk->backend); rc = ERROR_INVAL; - goto out_free; + goto out; } flexarray_append(back, "frontend-id"); @@ -1937,7 +1925,7 @@ static void device_disk_add(libxl__egc *egc, uint32_t domid, rc = libxl__xs_transaction_commit(gc, &t); if (!rc) break; - if (rc < 0) goto out_free; + if (rc < 0) goto out; } aodev->dev = device; @@ -1946,9 +1934,6 @@ static void device_disk_add(libxl__egc *egc, uint32_t domid, rc = 0; -out_free: - flexarray_free(back); - flexarray_free(front); out: libxl__xs_transaction_abort(gc, &t); aodev->rc = rc; @@ -2204,7 +2189,7 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk, if (rc) goto out; path = libxl__device_backend_path(gc, &device); - insert = flexarray_make(4, 1); + insert = flexarray_make(gc, 4, 1); flexarray_append_pair(insert, "type", libxl__device_disk_string_of_backend(disk->backend)); @@ -2230,8 +2215,6 @@ out: libxl_device_disk_dispose(&disks[i]); free(disks); - if (insert) flexarray_free(insert); - if (rc) return AO_ABORT(rc); return AO_INPROGRESS; } @@ -2567,21 +2550,13 @@ void libxl__device_nic_add(libxl__egc *egc, uint32_t domid, rc = libxl__device_nic_setdefault(gc, nic, domid); if (rc) goto out; - front = flexarray_make(16, 1); - if (!front) { - rc = ERROR_NOMEM; - goto out; - } - back = flexarray_make(16, 1); - if (!back) { - rc = ERROR_NOMEM; - goto out_free; - } + front = flexarray_make(gc, 16, 1); + back = flexarray_make(gc, 16, 1); if (nic->devid == -1) { if (!(dompath = libxl__xs_get_dompath(gc, domid))) { rc = ERROR_FAIL; - goto out_free; + goto out; } if (!(l = libxl__xs_directory(gc, XBT_NULL, libxl__sprintf(gc, "%s/device/vif", dompath), &nb))) { @@ -2593,7 +2568,7 @@ void libxl__device_nic_add(libxl__egc *egc, uint32_t domid, GCNEW(device); rc = libxl__device_from_nic(gc, domid, nic, device); - if ( rc != 0 ) goto out_free; + if ( rc != 0 ) goto out; flexarray_append(back, "frontend-id"); flexarray_append(back, libxl__sprintf(gc, "%d", domid)); @@ -2652,9 +2627,6 @@ void libxl__device_nic_add(libxl__egc *egc, uint32_t domid, libxl__wait_device_connection(egc, aodev); rc = 0; -out_free: - flexarray_free(back); - flexarray_free(front); out: aodev->rc = rc; if (rc) aodev->callback(egc, aodev); @@ -2851,16 +2823,8 @@ int libxl__device_console_add(libxl__gc *gc, uint32_t domid, goto out; } - front = flexarray_make(16, 1); - if (!front) { - rc = ERROR_NOMEM; - goto out; - } - back = flexarray_make(16, 1); - if (!back) { - rc = ERROR_NOMEM; - goto out_free; - } + front = flexarray_make(gc, 16, 1); + back = flexarray_make(gc, 16, 1); device.backend_devid = console->devid; device.backend_domid = console->backend_domid; @@ -2908,9 +2872,6 @@ int libxl__device_console_add(libxl__gc *gc, uint32_t domid, libxl__xs_kvs_of_flexarray(gc, back, back->count), libxl__xs_kvs_of_flexarray(gc, front, front->count)); rc = 0; -out_free: - flexarray_free(back); - flexarray_free(front); out: return rc; } @@ -2964,19 +2925,11 @@ int libxl__device_vkb_add(libxl__gc *gc, uint32_t domid, rc = libxl__device_vkb_setdefault(gc, vkb); if (rc) goto out; - front = flexarray_make(16, 1); - if (!front) { - rc = ERROR_NOMEM; - goto out; - } - back = flexarray_make(16, 1); - if (!back) { - rc = ERROR_NOMEM; - goto out_free; - } + front = flexarray_make(gc, 16, 1); + back = flexarray_make(gc, 16, 1); rc = libxl__device_from_vkb(gc, domid, vkb, &device); - if (rc != 0) goto out_free; + if (rc != 0) goto out; flexarray_append(back, "frontend-id"); flexarray_append(back, libxl__sprintf(gc, "%d", domid)); @@ -2996,9 +2949,6 @@ int libxl__device_vkb_add(libxl__gc *gc, uint32_t domid, libxl__xs_kvs_of_flexarray(gc, back, back->count), libxl__xs_kvs_of_flexarray(gc, front, front->count)); rc = 0; -out_free: - flexarray_free(back); - flexarray_free(front); out: return rc; } @@ -3063,19 +3013,11 @@ int libxl__device_vfb_add(libxl__gc *gc, uint32_t domid, libxl_device_vfb *vfb) rc = libxl__device_vfb_setdefault(gc, vfb); if (rc) goto out; - front = flexarray_make(16, 1); - if (!front) { - rc = ERROR_NOMEM; - goto out; - } - back = flexarray_make(16, 1); - if (!back) { - rc = ERROR_NOMEM; - goto out_free; - } + front = flexarray_make(gc, 16, 1); + back = flexarray_make(gc, 16, 1); rc = libxl__device_from_vfb(gc, domid, vfb, &device); - if (rc != 0) goto out_free; + if (rc != 0) goto out; flexarray_append_pair(back, "frontend-id", libxl__sprintf(gc, "%d", domid)); flexarray_append_pair(back, "online", "1"); @@ -3108,9 +3050,6 @@ int libxl__device_vfb_add(libxl__gc *gc, uint32_t domid, libxl_device_vfb *vfb) libxl__xs_kvs_of_flexarray(gc, back, back->count), libxl__xs_kvs_of_flexarray(gc, front, front->count)); rc = 0; -out_free: - flexarray_free(front); - flexarray_free(back); out: return rc; } diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c index 3be7bad..82d2009 100644 --- a/tools/libxl/libxl_dm.c +++ b/tools/libxl/libxl_dm.c @@ -109,10 +109,7 @@ static char ** libxl__build_device_model_args_old(libxl__gc *gc, const char *keymap = dm_keymap(guest_config); int i; flexarray_t *dm_args; - dm_args = flexarray_make(16, 1); - - if (!dm_args) - return NULL; + dm_args = flexarray_make(gc, 16, 1); flexarray_vappend(dm_args, dm, "-d", libxl__sprintf(gc, "%d", domid), NULL); @@ -340,9 +337,7 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc, int i; uint64_t ram_size; - dm_args = flexarray_make(16, 1); - if (!dm_args) - return NULL; + dm_args = flexarray_make(gc, 16, 1); flexarray_vappend(dm_args, dm, "-xen-domid", @@ -837,7 +832,7 @@ void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state *sdss) "setting target domain %d -> %d", dm_domid, guest_domid); ret = ERROR_FAIL; - goto out_free; + goto out; } xs_set_target(ctx->xsh, dm_domid, guest_domid); @@ -861,11 +856,8 @@ retry_transaction: libxl__add_disks(egc, ao, dm_domid, dm_config, &sdss->multidev); libxl__multidev_prepared(egc, &sdss->multidev, 0); - free(args); return; -out_free: - free(args); out: assert(ret); spawn_stubdom_pvqemu_cb(egc, &sdss->pvqemu, ret); @@ -1165,7 +1157,6 @@ retry_transaction: out_close: close(null); close(logfile_w); - free(args); out: if (rc) device_model_spawn_outcome(egc, dmss, rc); diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c index 8e17842..2e6322b 100644 --- a/tools/libxl/libxl_json.c +++ b/tools/libxl/libxl_json.c @@ -220,13 +220,7 @@ static libxl__json_object *json_object_alloc(libxl__gc *gc, obj->type = type; if (type == JSON_MAP || type == JSON_ARRAY) { - flexarray_t *array = flexarray_make(1, 1); - if (array == NULL) { - LIBXL__LOG_ERRNO(libxl__gc_owner(gc), LIBXL__LOG_ERROR, - "Failed to allocate a flexarray"); - free(obj); - return NULL; - } + flexarray_t *array = flexarray_make(NOGC, 1, 1); if (type == JSON_MAP) obj->u.map = array; else diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c index ff447e7..eac35c1 100644 --- a/tools/libxl/libxl_pci.c +++ b/tools/libxl/libxl_pci.c @@ -73,12 +73,8 @@ int libxl__create_pci_backend(libxl__gc *gc, uint32_t domid, libxl__device device; int ret = ERROR_NOMEM, i; - front = flexarray_make(16, 1); - if (!front) - goto out; - back = flexarray_make(16, 1); - if (!back) - goto out; + front = flexarray_make(gc, 16, 1); + back = flexarray_make(gc, 16, 1); ret = 0; @@ -108,11 +104,6 @@ int libxl__create_pci_backend(libxl__gc *gc, uint32_t domid, libxl__xs_kvs_of_flexarray(gc, back, back->count), libxl__xs_kvs_of_flexarray(gc, front, front->count)); -out: - if (back) - flexarray_free(back); - if (front) - flexarray_free(front); return 0; } @@ -138,9 +129,7 @@ static int libxl__device_pci_add_xenstore(libxl__gc *gc, uint32_t domid, libxl_d return ERROR_FAIL; } - back = flexarray_make(16, 1); - if (!back) - return ERROR_NOMEM; + back = flexarray_make(gc, 16, 1); LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Adding new pci device to xenstore"); num = atoi(num_devs); @@ -157,7 +146,6 @@ retry_transaction: if (errno == EAGAIN) goto retry_transaction; - flexarray_free(back); return 0; } diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c index 2c4d269..6bdf924 100644 --- a/tools/libxl/libxl_qmp.c +++ b/tools/libxl/libxl_qmp.c @@ -763,7 +763,7 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev) if (!hostaddr) return -1; - parameters = flexarray_make(6, 1); + parameters = flexarray_make(gc, 6, 1); flexarray_append_pair(parameters, "driver", "xen-pci-passthrough"); flexarray_append_pair(parameters, "id", libxl__sprintf(gc, PCI_PT_QDEV_ID, @@ -777,8 +777,6 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev) PCI_FUNC(pcidev->vdevfn))); } args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count); - if (!args) - return -1; rc = qmp_synchronous_send(qmp, "device_add", &args, NULL, NULL, qmp->timeout); @@ -787,7 +785,6 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev) pci_add_callback, pcidev, qmp->timeout); } - flexarray_free(parameters); libxl__qmp_close(qmp); return rc; } @@ -803,16 +800,13 @@ static int qmp_device_del(libxl__gc *gc, int domid, char *id) if (!qmp) return ERROR_FAIL; - parameters = flexarray_make(2, 1); + parameters = flexarray_make(gc, 2, 1); flexarray_append_pair(parameters, "id", id); args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count); - if (!args) - return ERROR_NOMEM; rc = qmp_synchronous_send(qmp, "device_del", &args, NULL, NULL, qmp->timeout); - flexarray_free(parameters); libxl__qmp_close(qmp); return rc; } @@ -838,24 +832,13 @@ int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename) if (!qmp) return ERROR_FAIL; - parameters = flexarray_make(2, 1); - if (!parameters) { - rc = ERROR_NOMEM; - goto out; - } + parameters = flexarray_make(gc, 2, 1); flexarray_append_pair(parameters, "filename", (char *)filename); args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count); - if (!args) { - rc = ERROR_NOMEM; - goto out2; - } rc = qmp_synchronous_send(qmp, "xen-save-devices-state", &args, NULL, NULL, qmp->timeout); -out2: - flexarray_free(parameters); -out: libxl__qmp_close(qmp); return rc; } @@ -867,19 +850,16 @@ static int qmp_change(libxl__gc *gc, libxl__qmp_handler *qmp, libxl_key_value_list args = NULL; int rc = 0; - parameters = flexarray_make(6, 1); + parameters = flexarray_make(gc, 6, 1); flexarray_append_pair(parameters, "device", device); flexarray_append_pair(parameters, "target", target); if (arg) flexarray_append_pair(parameters, "arg", arg); args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count); - if (!args) - return ERROR_NOMEM; rc = qmp_synchronous_send(qmp, "change", &args, NULL, NULL, qmp->timeout); - flexarray_free(parameters); return rc; } -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 16:19:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 16:19:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJo8Q-0003nN-03; Thu, 04 Oct 2012 16:18:50 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJo8O-0003nC-KP for xen-devel@lists.xen.org; Thu, 04 Oct 2012 16:18:48 +0000 Received: from [85.158.139.83:55600] by server-4.bemta-5.messagelabs.com id 88/2F-20767-7E6BD605; Thu, 04 Oct 2012 16:18:47 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1349367525!29560697!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQyMDg=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8523 invoked from network); 4 Oct 2012 16:18:47 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 16:18:47 -0000 X-IronPort-AV: E=Sophos;i="4.80,537,1344211200"; d="scan'208";a="40164139" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 16:18:45 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 12:18:44 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJo8K-0003cd-GZ; Thu, 04 Oct 2012 17:18:44 +0100 From: Anthony PERARD To: Xen Devel Date: Thu, 4 Oct 2012 17:18:40 +0100 Message-ID: <1349367522-16695-1-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 MIME-Version: 1.0 Cc: Anthony PERARD , Ian Jackson , Ian Campbell Subject: [Xen-devel] [PATCH V2 0/2] Cleanup: flexarray taking gc. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This two patches do a bit of cleanup in the memomy managment in libxl, regarding the use of flexarray. The first one modify flexarray_make to take gc as argument and update every user in libxl to pass gc and to not call flexarray_free anymore. The second one does some cleanup only in libxl_json to make it use the gc. Change since v1: - Change order of the two patch to not end up with leaks. - Add a comment on the first patch to tell why it OK to store the gc in the flexarray struct. - Keep the _free functions (libxl__json_object_free and flexarray_free, as they can be used if gc in NOGC. Anthony PERARD (2): libxl: Have flexarray using the GC libxl_json: Use libxl alloc function. tools/libxl/flexarray.c | 48 ++++++++++++++--------- tools/libxl/flexarray.h | 7 +++- tools/libxl/libxl.c | 99 ++++++++++-------------------------------------- tools/libxl/libxl_dm.c | 15 ++------ tools/libxl/libxl_json.c | 93 ++++++++++----------------------------------- tools/libxl/libxl_pci.c | 18 ++------- tools/libxl/libxl_qmp.c | 29 ++------------ 7 files changed, 83 insertions(+), 226 deletions(-) -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 16:19:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 16:19:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJo8Q-0003nN-03; Thu, 04 Oct 2012 16:18:50 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJo8O-0003nC-KP for xen-devel@lists.xen.org; Thu, 04 Oct 2012 16:18:48 +0000 Received: from [85.158.139.83:55600] by server-4.bemta-5.messagelabs.com id 88/2F-20767-7E6BD605; Thu, 04 Oct 2012 16:18:47 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1349367525!29560697!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQyMDg=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8523 invoked from network); 4 Oct 2012 16:18:47 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 16:18:47 -0000 X-IronPort-AV: E=Sophos;i="4.80,537,1344211200"; d="scan'208";a="40164139" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 16:18:45 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 12:18:44 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJo8K-0003cd-GZ; Thu, 04 Oct 2012 17:18:44 +0100 From: Anthony PERARD To: Xen Devel Date: Thu, 4 Oct 2012 17:18:40 +0100 Message-ID: <1349367522-16695-1-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 MIME-Version: 1.0 Cc: Anthony PERARD , Ian Jackson , Ian Campbell Subject: [Xen-devel] [PATCH V2 0/2] Cleanup: flexarray taking gc. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This two patches do a bit of cleanup in the memomy managment in libxl, regarding the use of flexarray. The first one modify flexarray_make to take gc as argument and update every user in libxl to pass gc and to not call flexarray_free anymore. The second one does some cleanup only in libxl_json to make it use the gc. Change since v1: - Change order of the two patch to not end up with leaks. - Add a comment on the first patch to tell why it OK to store the gc in the flexarray struct. - Keep the _free functions (libxl__json_object_free and flexarray_free, as they can be used if gc in NOGC. Anthony PERARD (2): libxl: Have flexarray using the GC libxl_json: Use libxl alloc function. tools/libxl/flexarray.c | 48 ++++++++++++++--------- tools/libxl/flexarray.h | 7 +++- tools/libxl/libxl.c | 99 ++++++++++-------------------------------------- tools/libxl/libxl_dm.c | 15 ++------ tools/libxl/libxl_json.c | 93 ++++++++++----------------------------------- tools/libxl/libxl_pci.c | 18 ++------- tools/libxl/libxl_qmp.c | 29 ++------------ 7 files changed, 83 insertions(+), 226 deletions(-) -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 16:19:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 16:19:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJo8Q-0003nU-C5; Thu, 04 Oct 2012 16:18:50 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJo8P-0003nE-Ay for xen-devel@lists.xen.org; Thu, 04 Oct 2012 16:18:49 +0000 Received: from [85.158.139.83:6447] by server-13.bemta-5.messagelabs.com id CC/78-06496-8E6BD605; Thu, 04 Oct 2012 16:18:48 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1349367525!29560697!2 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQyMDg=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8550 invoked from network); 4 Oct 2012 16:18:47 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 16:18:47 -0000 X-IronPort-AV: E=Sophos;i="4.80,537,1344211200"; d="scan'208";a="40164140" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 16:18:45 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 12:18:44 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJo8K-0003cd-HQ; Thu, 04 Oct 2012 17:18:44 +0100 From: Anthony PERARD To: Xen Devel Date: Thu, 4 Oct 2012 17:18:42 +0100 Message-ID: <1349367522-16695-3-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1349367522-16695-1-git-send-email-anthony.perard@citrix.com> References: <1349367522-16695-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Cc: Anthony PERARD , Ian Jackson , Ian Campbell Subject: [Xen-devel] [PATCH V2 2/2] libxl_json: Use libxl alloc function. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch makes use of the libxl allocation API and the GC and removes the check for allocation failure. Signed-off-by: Anthony PERARD --- tools/libxl/libxl_json.c | 87 +++++++++++------------------------------------- tools/libxl/libxl_qmp.c | 1 - 2 files changed, 19 insertions(+), 69 deletions(-) diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c index 2e6322b..3cba48f 100644 --- a/tools/libxl/libxl_json.c +++ b/tools/libxl/libxl_json.c @@ -210,17 +210,12 @@ static libxl__json_object *json_object_alloc(libxl__gc *gc, { libxl__json_object *obj; - obj = calloc(1, sizeof (libxl__json_object)); - if (obj == NULL) { - LIBXL__LOG_ERRNO(libxl__gc_owner(gc), LIBXL__LOG_ERROR, - "Failed to allocate a libxl__json_object"); - return NULL; - } + obj = libxl__zalloc(gc, sizeof(*obj)); obj->type = type; if (type == JSON_MAP || type == JSON_ARRAY) { - flexarray_t *array = flexarray_make(NOGC, 1, 1); + flexarray_t *array = flexarray_make(gc, 1, 1); if (type == JSON_MAP) obj->u.map = array; else @@ -250,11 +245,7 @@ static int json_object_append_to(libxl__gc *gc, break; } case JSON_ARRAY: - if (flexarray_append(dst->u.array, obj) == 2) { - LIBXL__LOG_ERRNO(libxl__gc_owner(gc), LIBXL__LOG_ERROR, - "Failed to grow a flexarray"); - return -1; - } + flexarray_append(dst->u.array, obj); break; default: LIBXL__LOG(libxl__gc_owner(gc), LIBXL__LOG_ERROR, @@ -387,11 +378,9 @@ static int json_callback_null(void *opaque) DEBUG_GEN(ctx, null); - if ((obj = json_object_alloc(ctx->gc, JSON_NULL)) == NULL) - return 0; + obj = json_object_alloc(ctx->gc, JSON_NULL); if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { - libxl__json_object_free(ctx->gc, obj); return 0; } @@ -405,12 +394,10 @@ static int json_callback_boolean(void *opaque, int boolean) DEBUG_GEN_VALUE(ctx, bool, boolean); - if ((obj = json_object_alloc(ctx->gc, - boolean ? JSON_TRUE : JSON_FALSE)) == NULL) - return 0; + obj = json_object_alloc(ctx->gc, + boolean ? JSON_TRUE : JSON_FALSE); if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { - libxl__json_object_free(ctx->gc, obj); return 0; } @@ -442,8 +429,7 @@ static int json_callback_number(void *opaque, const char *s, libxl_yajl_length l goto error; } - if ((obj = json_object_alloc(ctx->gc, JSON_DOUBLE)) == NULL) - return 0; + obj = json_object_alloc(ctx->gc, JSON_DOUBLE); obj->u.d = d; } else { long long i = strtoll(s, NULL, 10); @@ -452,23 +438,16 @@ static int json_callback_number(void *opaque, const char *s, libxl_yajl_length l goto error; } - if ((obj = json_object_alloc(ctx->gc, JSON_INTEGER)) == NULL) - return 0; + obj = json_object_alloc(ctx->gc, JSON_INTEGER); obj->u.i = i; } goto out; error: /* If the conversion fail, we just store the original string. */ - if ((obj = json_object_alloc(ctx->gc, JSON_NUMBER)) == NULL) - return 0; + obj = json_object_alloc(ctx->gc, JSON_NUMBER); - t = malloc(len + 1); - if (t == NULL) { - LIBXL__LOG_ERRNO(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR, - "Failed to allocate"); - return 0; - } + t = libxl__zalloc(ctx->gc, len + 1); strncpy(t, s, len); t[len] = 0; @@ -476,7 +455,6 @@ error: out: if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { - libxl__json_object_free(ctx->gc, obj); return 0; } @@ -490,26 +468,17 @@ static int json_callback_string(void *opaque, const unsigned char *str, char *t = NULL; libxl__json_object *obj = NULL; - t = malloc(len + 1); - if (t == NULL) { - LIBXL__LOG_ERRNO(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR, - "Failed to allocate"); - return 0; - } + t = libxl__zalloc(ctx->gc, len + 1); DEBUG_GEN_STRING(ctx, str, len); strncpy(t, (const char *) str, len); t[len] = 0; - if ((obj = json_object_alloc(ctx->gc, JSON_STRING)) == NULL) { - free(t); - return 0; - } + obj = json_object_alloc(ctx->gc, JSON_STRING); obj->u.string = t; if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { - libxl__json_object_free(ctx->gc, obj); return 0; } @@ -522,13 +491,9 @@ static int json_callback_map_key(void *opaque, const unsigned char *str, libxl__yajl_ctx *ctx = opaque; char *t = NULL; libxl__json_object *obj = ctx->current; + libxl__gc *gc = ctx->gc; - t = malloc(len + 1); - if (t == NULL) { - LIBXL__LOG_ERRNO(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR, - "Failed to allocate"); - return 0; - } + t = libxl__zalloc(gc, len + 1); DEBUG_GEN_STRING(ctx, str, len); @@ -536,21 +501,13 @@ static int json_callback_map_key(void *opaque, const unsigned char *str, t[len] = 0; if (libxl__json_object_is_map(obj)) { - libxl__json_map_node *node = malloc(sizeof (libxl__json_map_node)); - if (node == NULL) { - LIBXL__LOG_ERRNO(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR, - "Failed to allocate"); - return 0; - } + libxl__json_map_node *node; + GCNEW(node); node->map_key = t; node->obj = NULL; - if (flexarray_append(obj->u.map, node) == 2) { - LIBXL__LOG_ERRNO(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR, - "Failed to grow a flexarray"); - return 0; - } + flexarray_append(obj->u.map, node); } else { LIBXL__LOG(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR, "Current json object is not a map"); @@ -567,12 +524,10 @@ static int json_callback_start_map(void *opaque) DEBUG_GEN(ctx, map_open); - if ((obj = json_object_alloc(ctx->gc, JSON_MAP)) == NULL) - return 0; + obj = json_object_alloc(ctx->gc, JSON_MAP); if (ctx->current) { if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { - libxl__json_object_free(ctx->gc, obj); return 0; } } @@ -609,12 +564,10 @@ static int json_callback_start_array(void *opaque) DEBUG_GEN(ctx, array_open); - if ((obj = json_object_alloc(ctx->gc, JSON_ARRAY)) == NULL) - return 0; + obj = json_object_alloc(ctx->gc, JSON_ARRAY); if (ctx->current) { if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { - libxl__json_object_free(ctx->gc, obj); return 0; } } @@ -704,8 +657,6 @@ out: LIBXL__LOG(libxl__gc_owner(gc), LIBXL__LOG_ERROR, "yajl error: %s", str); yajl_free_error(yajl_ctx.hand, str); - - libxl__json_object_free(gc, yajl_ctx.head); yajl_ctx_free(&yajl_ctx); return NULL; } diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c index 6bdf924..15550e7 100644 --- a/tools/libxl/libxl_qmp.c +++ b/tools/libxl/libxl_qmp.c @@ -484,7 +484,6 @@ static int qmp_next(libxl__gc *gc, libxl__qmp_handler *qmp) if (o) { rc = qmp_handle_response(qmp, o); - libxl__json_object_free(gc, o); } else { LIBXL__LOG(qmp->ctx, LIBXL__LOG_ERROR, "Parse error of : %s\n", s); -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 16:19:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 16:19:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJo8Q-0003nU-C5; Thu, 04 Oct 2012 16:18:50 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJo8P-0003nE-Ay for xen-devel@lists.xen.org; Thu, 04 Oct 2012 16:18:49 +0000 Received: from [85.158.139.83:6447] by server-13.bemta-5.messagelabs.com id CC/78-06496-8E6BD605; Thu, 04 Oct 2012 16:18:48 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1349367525!29560697!2 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQyMDg=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8550 invoked from network); 4 Oct 2012 16:18:47 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 16:18:47 -0000 X-IronPort-AV: E=Sophos;i="4.80,537,1344211200"; d="scan'208";a="40164140" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 16:18:45 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 12:18:44 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TJo8K-0003cd-HQ; Thu, 04 Oct 2012 17:18:44 +0100 From: Anthony PERARD To: Xen Devel Date: Thu, 4 Oct 2012 17:18:42 +0100 Message-ID: <1349367522-16695-3-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1349367522-16695-1-git-send-email-anthony.perard@citrix.com> References: <1349367522-16695-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Cc: Anthony PERARD , Ian Jackson , Ian Campbell Subject: [Xen-devel] [PATCH V2 2/2] libxl_json: Use libxl alloc function. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch makes use of the libxl allocation API and the GC and removes the check for allocation failure. Signed-off-by: Anthony PERARD --- tools/libxl/libxl_json.c | 87 +++++++++++------------------------------------- tools/libxl/libxl_qmp.c | 1 - 2 files changed, 19 insertions(+), 69 deletions(-) diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c index 2e6322b..3cba48f 100644 --- a/tools/libxl/libxl_json.c +++ b/tools/libxl/libxl_json.c @@ -210,17 +210,12 @@ static libxl__json_object *json_object_alloc(libxl__gc *gc, { libxl__json_object *obj; - obj = calloc(1, sizeof (libxl__json_object)); - if (obj == NULL) { - LIBXL__LOG_ERRNO(libxl__gc_owner(gc), LIBXL__LOG_ERROR, - "Failed to allocate a libxl__json_object"); - return NULL; - } + obj = libxl__zalloc(gc, sizeof(*obj)); obj->type = type; if (type == JSON_MAP || type == JSON_ARRAY) { - flexarray_t *array = flexarray_make(NOGC, 1, 1); + flexarray_t *array = flexarray_make(gc, 1, 1); if (type == JSON_MAP) obj->u.map = array; else @@ -250,11 +245,7 @@ static int json_object_append_to(libxl__gc *gc, break; } case JSON_ARRAY: - if (flexarray_append(dst->u.array, obj) == 2) { - LIBXL__LOG_ERRNO(libxl__gc_owner(gc), LIBXL__LOG_ERROR, - "Failed to grow a flexarray"); - return -1; - } + flexarray_append(dst->u.array, obj); break; default: LIBXL__LOG(libxl__gc_owner(gc), LIBXL__LOG_ERROR, @@ -387,11 +378,9 @@ static int json_callback_null(void *opaque) DEBUG_GEN(ctx, null); - if ((obj = json_object_alloc(ctx->gc, JSON_NULL)) == NULL) - return 0; + obj = json_object_alloc(ctx->gc, JSON_NULL); if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { - libxl__json_object_free(ctx->gc, obj); return 0; } @@ -405,12 +394,10 @@ static int json_callback_boolean(void *opaque, int boolean) DEBUG_GEN_VALUE(ctx, bool, boolean); - if ((obj = json_object_alloc(ctx->gc, - boolean ? JSON_TRUE : JSON_FALSE)) == NULL) - return 0; + obj = json_object_alloc(ctx->gc, + boolean ? JSON_TRUE : JSON_FALSE); if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { - libxl__json_object_free(ctx->gc, obj); return 0; } @@ -442,8 +429,7 @@ static int json_callback_number(void *opaque, const char *s, libxl_yajl_length l goto error; } - if ((obj = json_object_alloc(ctx->gc, JSON_DOUBLE)) == NULL) - return 0; + obj = json_object_alloc(ctx->gc, JSON_DOUBLE); obj->u.d = d; } else { long long i = strtoll(s, NULL, 10); @@ -452,23 +438,16 @@ static int json_callback_number(void *opaque, const char *s, libxl_yajl_length l goto error; } - if ((obj = json_object_alloc(ctx->gc, JSON_INTEGER)) == NULL) - return 0; + obj = json_object_alloc(ctx->gc, JSON_INTEGER); obj->u.i = i; } goto out; error: /* If the conversion fail, we just store the original string. */ - if ((obj = json_object_alloc(ctx->gc, JSON_NUMBER)) == NULL) - return 0; + obj = json_object_alloc(ctx->gc, JSON_NUMBER); - t = malloc(len + 1); - if (t == NULL) { - LIBXL__LOG_ERRNO(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR, - "Failed to allocate"); - return 0; - } + t = libxl__zalloc(ctx->gc, len + 1); strncpy(t, s, len); t[len] = 0; @@ -476,7 +455,6 @@ error: out: if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { - libxl__json_object_free(ctx->gc, obj); return 0; } @@ -490,26 +468,17 @@ static int json_callback_string(void *opaque, const unsigned char *str, char *t = NULL; libxl__json_object *obj = NULL; - t = malloc(len + 1); - if (t == NULL) { - LIBXL__LOG_ERRNO(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR, - "Failed to allocate"); - return 0; - } + t = libxl__zalloc(ctx->gc, len + 1); DEBUG_GEN_STRING(ctx, str, len); strncpy(t, (const char *) str, len); t[len] = 0; - if ((obj = json_object_alloc(ctx->gc, JSON_STRING)) == NULL) { - free(t); - return 0; - } + obj = json_object_alloc(ctx->gc, JSON_STRING); obj->u.string = t; if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { - libxl__json_object_free(ctx->gc, obj); return 0; } @@ -522,13 +491,9 @@ static int json_callback_map_key(void *opaque, const unsigned char *str, libxl__yajl_ctx *ctx = opaque; char *t = NULL; libxl__json_object *obj = ctx->current; + libxl__gc *gc = ctx->gc; - t = malloc(len + 1); - if (t == NULL) { - LIBXL__LOG_ERRNO(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR, - "Failed to allocate"); - return 0; - } + t = libxl__zalloc(gc, len + 1); DEBUG_GEN_STRING(ctx, str, len); @@ -536,21 +501,13 @@ static int json_callback_map_key(void *opaque, const unsigned char *str, t[len] = 0; if (libxl__json_object_is_map(obj)) { - libxl__json_map_node *node = malloc(sizeof (libxl__json_map_node)); - if (node == NULL) { - LIBXL__LOG_ERRNO(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR, - "Failed to allocate"); - return 0; - } + libxl__json_map_node *node; + GCNEW(node); node->map_key = t; node->obj = NULL; - if (flexarray_append(obj->u.map, node) == 2) { - LIBXL__LOG_ERRNO(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR, - "Failed to grow a flexarray"); - return 0; - } + flexarray_append(obj->u.map, node); } else { LIBXL__LOG(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR, "Current json object is not a map"); @@ -567,12 +524,10 @@ static int json_callback_start_map(void *opaque) DEBUG_GEN(ctx, map_open); - if ((obj = json_object_alloc(ctx->gc, JSON_MAP)) == NULL) - return 0; + obj = json_object_alloc(ctx->gc, JSON_MAP); if (ctx->current) { if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { - libxl__json_object_free(ctx->gc, obj); return 0; } } @@ -609,12 +564,10 @@ static int json_callback_start_array(void *opaque) DEBUG_GEN(ctx, array_open); - if ((obj = json_object_alloc(ctx->gc, JSON_ARRAY)) == NULL) - return 0; + obj = json_object_alloc(ctx->gc, JSON_ARRAY); if (ctx->current) { if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { - libxl__json_object_free(ctx->gc, obj); return 0; } } @@ -704,8 +657,6 @@ out: LIBXL__LOG(libxl__gc_owner(gc), LIBXL__LOG_ERROR, "yajl error: %s", str); yajl_free_error(yajl_ctx.hand, str); - - libxl__json_object_free(gc, yajl_ctx.head); yajl_ctx_free(&yajl_ctx); return NULL; } diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c index 6bdf924..15550e7 100644 --- a/tools/libxl/libxl_qmp.c +++ b/tools/libxl/libxl_qmp.c @@ -484,7 +484,6 @@ static int qmp_next(libxl__gc *gc, libxl__qmp_handler *qmp) if (o) { rc = qmp_handle_response(qmp, o); - libxl__json_object_free(gc, o); } else { LIBXL__LOG(qmp->ctx, LIBXL__LOG_ERROR, "Parse error of : %s\n", s); -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 16:37:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 16:37:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJoPu-0004dd-Bj; Thu, 04 Oct 2012 16:36:54 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJoPs-0004dU-6X for xen-devel@lists.xen.org; Thu, 04 Oct 2012 16:36:52 +0000 Received: from [85.158.139.83:38271] by server-15.bemta-5.messagelabs.com id 0D/AB-06905-32BBD605; Thu, 04 Oct 2012 16:36:51 +0000 X-Env-Sender: dan.magenheimer@oracle.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1349368607!26228946!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzgzMjE1\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25813 invoked from network); 4 Oct 2012 16:36:49 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Oct 2012 16:36:49 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q94GaZSO014257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Oct 2012 16:36:35 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q94GaWB7011713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Oct 2012 16:36:33 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q94GaVRc026278; Thu, 4 Oct 2012 11:36:31 -0500 MIME-Version: 1.0 Message-ID: <4f829294-c5a5-405d-becb-bd4e6989cde3@default> Date: Thu, 4 Oct 2012 09:36:25 -0700 (PDT) From: Dan Magenheimer To: Tim Deegan References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> <20121002091017.GA95926@ocelot.phlegethon.org> <66cc0085-1216-40f7-8059-eaf615202c12@default> <20121002201624.GA98445@ocelot.phlegethon.org> <20121004100645.GC38243@ocelot.phlegethon.org> In-Reply-To: <20121004100645.GC38243@ocelot.phlegethon.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7 (607090) [OL 12.0.6661.5003 (x86)] X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: Olaf Hering , Keir Fraser , Konrad Wilk , George Dunlap , Kurt Hackel , Ian Jackson , xen-devel@lists.xen.org, George Shuklin , Dario Faggioli , Andres Lagar-Cavilla Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > From: Tim Deegan [mailto:tim@xen.org] > Sent: Thursday, October 04, 2012 4:07 AM > To: Dan Magenheimer > Cc: Olaf Hering; Keir Fraser; Konrad Wilk; George Dunlap; Kurt Hackel; Ian Jackson; xen- > devel@lists.xen.org; George Shuklin; Dario Faggioli; Andres Lagar-Cavilla > Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) Hi Tim -- Good discussion! > At 14:56 -0700 on 02 Oct (1349189817), Dan Magenheimer wrote: > > > AIUI xapi uses the domains' maximum allocations, centrally controlled, > > > to place an upper bound on the amount of guest memory that can be in > > > use. Within those limits there can be ballooning activity. But TBH I > > > don't know the details. > > > > Yes, that's the same as saying there is no memory-overcommit. > > I'd say there is - but it's all done by ballooning, and it's centrally > enforced by lowering each domain's maxmem to its balloon target, so a > badly behaved guest can't balloon up and confuse things. While I agree this conceivably is a form of memory overcommit, I discarded it as a workable overcommit solution in 2008. The short reason is: EVERY guest is badly behaved in that they all want to suck up as much memory as possible and they all need it _now_. This observation actually is what led to tmem. > > The original problem occurs only if there are multiple threads > > of execution that can be simultaneously asking the hypervisor > > to allocate memory without the knowledge of a single centralized > > "controller". > > Absolutely. > > > Tmem argues that doing "memory capacity transfers" at a page granularity > > can only be done efficiently in the hypervisor. This is true for > > page-sharing when it breaks a "share" also... it can't go ask the > > toolstack to approve allocation of a new page every time a write to a shared > > page occurs. > > > > Does that make sense? > > Yes. The page-sharing version can be handled by having a pool of > dedicated memory for breaking shares, and the toolstack asynchronously > replenish that, rather than allowing CoW to use up all memory in the > system. This is really just overcommit-by-undercommit. IMHO, any attempt to set aside a chunk of memory for a specific purpose just increases memory pressure on all the other memory users. Nobody has any clue a priori what the size of that dedicated memory pool should be; if it is too big, you are simply wasting memory and if it is too small, you haven't solved the real problem. Workloads vary too dramatically, instantaneously, and unpredictably across time in their need for memory. Sharing makes it even more complex. > > (rough proposed design re-attached below) > > Thanks for that. It describes a sensible-looking hypervisor interface, > but my question was really: what should xl do, in the presence of > ballooning, sharing, paging and tmem, to > - decide whether a VM can be started at all; > - control those four systems to shuffle memory around; and > - resolve races sensibly to avoid small VMs deferring large ones. > (AIUI, xl already has some logic to handle the case of balloon-to-fit.) > > The second of those three is the interesting one. It seems to me that > if the tools can't force all other actors to give up memory (and not > immediately take it back) then they can't guarantee to be able to start > a new VM, even with the new reservation hypercalls. I agree the second one is interesting but the only real solution is for the controller to be an oracle for all the guests. That makes it less interesting to me, so balloon-to-fit is less interesting to me (even if it is the only overcommit option for legacy guests). IMHO, the problem is the same as for guest OS's that compute pi in the kernel when there are no runnable tasks, i.e. a virtualization environment is sometimes forced to partition resources, not virtualize those guests. IOW, don't overcommit "unenlightened" legacy guests. [1] So I don't think the design I wrote up solves the second one, nor do I think it makes it any worse. The design I wrote up is intended to solve the first and third. I _think_ the reservation-transaction model described (X1 and X2) should work for libxl, in the presence of ballooning, sharing, paging, and tmem. And it neither helps nor hurts balloon-to-fit. Given that, can you shoot holes in the design? Or are there parts that aren't clear? Or (admitting that I am a libxl idiot) is it unworkable for xl/libxl? Thanks, Dan [1] By "unenlightened" here, I mean guests that are still under the notion that they "own" all of a fixed amount of RAM. A balloon driver makes them "semi-enlightened" :-) > > > From: Dan Magenheimer > > > Sent: Monday, October 01, 2012 2:04 PM > > > : > > > : > > > Back to design brainstorming: > > > > > > The way I am thinking about it, the tools need to be involved > > > to the extent that they would need to communicate to the > > > hypervisor the following facts (probably via new hypercall): > > > > > > X1) I am launching a domain X and it is eventually going to > > > consume up to a maximum of N MB. Please tell me if > > > there is sufficient RAM available AND, if so, reserve > > > it until I tell you I am done. ("AND" implies transactional > > > semantics) > > > X2) The launch of X is complete and I will not be requesting > > > the allocation of any more RAM for it. Please release > > > the reservation, whether or not I've requested a total > > > of N MB. > > > > > > The calls may be nested or partially ordered, i.e. > > > X1...Y1...Y2...X2 > > > X1...Y1...X2...Y2 > > > and the hypervisor must be able to deal with this. > > > > > > Then there would need to be two "versions" of "xm/xl free". > > > We can quibble about which should be the default, but > > > they would be: > > > > > > - "xl --reserved free" asks the hypervisor how much RAM > > > is available taking into account reservations > > > - "xm --raw free" asks the hypervisor for the instantaneous > > > amount of RAM unallocated, not counting reservations > > > > > > When the tools are not launching a domain (that is there > > > has been a matching X2 for all X1), the results of the > > > above "free" queries are always identical. > > > > > > So, IanJ, does this match up with the design you were thinking > > > about? > > > > > > Thanks, > > > Dan > > > > > > [1] I think the core culprits are (a) the hypervisor accounts for > > > memory allocation of pages strictly on a first-come-first-served > > > basis and (b) the tools don't have any form of need-this-much-memory > > > "transaction" model _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 16:37:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 16:37:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJoPu-0004dd-Bj; Thu, 04 Oct 2012 16:36:54 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJoPs-0004dU-6X for xen-devel@lists.xen.org; Thu, 04 Oct 2012 16:36:52 +0000 Received: from [85.158.139.83:38271] by server-15.bemta-5.messagelabs.com id 0D/AB-06905-32BBD605; Thu, 04 Oct 2012 16:36:51 +0000 X-Env-Sender: dan.magenheimer@oracle.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1349368607!26228946!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzgzMjE1\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25813 invoked from network); 4 Oct 2012 16:36:49 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Oct 2012 16:36:49 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q94GaZSO014257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Oct 2012 16:36:35 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q94GaWB7011713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Oct 2012 16:36:33 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q94GaVRc026278; Thu, 4 Oct 2012 11:36:31 -0500 MIME-Version: 1.0 Message-ID: <4f829294-c5a5-405d-becb-bd4e6989cde3@default> Date: Thu, 4 Oct 2012 09:36:25 -0700 (PDT) From: Dan Magenheimer To: Tim Deegan References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> <20121002091017.GA95926@ocelot.phlegethon.org> <66cc0085-1216-40f7-8059-eaf615202c12@default> <20121002201624.GA98445@ocelot.phlegethon.org> <20121004100645.GC38243@ocelot.phlegethon.org> In-Reply-To: <20121004100645.GC38243@ocelot.phlegethon.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7 (607090) [OL 12.0.6661.5003 (x86)] X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: Olaf Hering , Keir Fraser , Konrad Wilk , George Dunlap , Kurt Hackel , Ian Jackson , xen-devel@lists.xen.org, George Shuklin , Dario Faggioli , Andres Lagar-Cavilla Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > From: Tim Deegan [mailto:tim@xen.org] > Sent: Thursday, October 04, 2012 4:07 AM > To: Dan Magenheimer > Cc: Olaf Hering; Keir Fraser; Konrad Wilk; George Dunlap; Kurt Hackel; Ian Jackson; xen- > devel@lists.xen.org; George Shuklin; Dario Faggioli; Andres Lagar-Cavilla > Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) Hi Tim -- Good discussion! > At 14:56 -0700 on 02 Oct (1349189817), Dan Magenheimer wrote: > > > AIUI xapi uses the domains' maximum allocations, centrally controlled, > > > to place an upper bound on the amount of guest memory that can be in > > > use. Within those limits there can be ballooning activity. But TBH I > > > don't know the details. > > > > Yes, that's the same as saying there is no memory-overcommit. > > I'd say there is - but it's all done by ballooning, and it's centrally > enforced by lowering each domain's maxmem to its balloon target, so a > badly behaved guest can't balloon up and confuse things. While I agree this conceivably is a form of memory overcommit, I discarded it as a workable overcommit solution in 2008. The short reason is: EVERY guest is badly behaved in that they all want to suck up as much memory as possible and they all need it _now_. This observation actually is what led to tmem. > > The original problem occurs only if there are multiple threads > > of execution that can be simultaneously asking the hypervisor > > to allocate memory without the knowledge of a single centralized > > "controller". > > Absolutely. > > > Tmem argues that doing "memory capacity transfers" at a page granularity > > can only be done efficiently in the hypervisor. This is true for > > page-sharing when it breaks a "share" also... it can't go ask the > > toolstack to approve allocation of a new page every time a write to a shared > > page occurs. > > > > Does that make sense? > > Yes. The page-sharing version can be handled by having a pool of > dedicated memory for breaking shares, and the toolstack asynchronously > replenish that, rather than allowing CoW to use up all memory in the > system. This is really just overcommit-by-undercommit. IMHO, any attempt to set aside a chunk of memory for a specific purpose just increases memory pressure on all the other memory users. Nobody has any clue a priori what the size of that dedicated memory pool should be; if it is too big, you are simply wasting memory and if it is too small, you haven't solved the real problem. Workloads vary too dramatically, instantaneously, and unpredictably across time in their need for memory. Sharing makes it even more complex. > > (rough proposed design re-attached below) > > Thanks for that. It describes a sensible-looking hypervisor interface, > but my question was really: what should xl do, in the presence of > ballooning, sharing, paging and tmem, to > - decide whether a VM can be started at all; > - control those four systems to shuffle memory around; and > - resolve races sensibly to avoid small VMs deferring large ones. > (AIUI, xl already has some logic to handle the case of balloon-to-fit.) > > The second of those three is the interesting one. It seems to me that > if the tools can't force all other actors to give up memory (and not > immediately take it back) then they can't guarantee to be able to start > a new VM, even with the new reservation hypercalls. I agree the second one is interesting but the only real solution is for the controller to be an oracle for all the guests. That makes it less interesting to me, so balloon-to-fit is less interesting to me (even if it is the only overcommit option for legacy guests). IMHO, the problem is the same as for guest OS's that compute pi in the kernel when there are no runnable tasks, i.e. a virtualization environment is sometimes forced to partition resources, not virtualize those guests. IOW, don't overcommit "unenlightened" legacy guests. [1] So I don't think the design I wrote up solves the second one, nor do I think it makes it any worse. The design I wrote up is intended to solve the first and third. I _think_ the reservation-transaction model described (X1 and X2) should work for libxl, in the presence of ballooning, sharing, paging, and tmem. And it neither helps nor hurts balloon-to-fit. Given that, can you shoot holes in the design? Or are there parts that aren't clear? Or (admitting that I am a libxl idiot) is it unworkable for xl/libxl? Thanks, Dan [1] By "unenlightened" here, I mean guests that are still under the notion that they "own" all of a fixed amount of RAM. A balloon driver makes them "semi-enlightened" :-) > > > From: Dan Magenheimer > > > Sent: Monday, October 01, 2012 2:04 PM > > > : > > > : > > > Back to design brainstorming: > > > > > > The way I am thinking about it, the tools need to be involved > > > to the extent that they would need to communicate to the > > > hypervisor the following facts (probably via new hypercall): > > > > > > X1) I am launching a domain X and it is eventually going to > > > consume up to a maximum of N MB. Please tell me if > > > there is sufficient RAM available AND, if so, reserve > > > it until I tell you I am done. ("AND" implies transactional > > > semantics) > > > X2) The launch of X is complete and I will not be requesting > > > the allocation of any more RAM for it. Please release > > > the reservation, whether or not I've requested a total > > > of N MB. > > > > > > The calls may be nested or partially ordered, i.e. > > > X1...Y1...Y2...X2 > > > X1...Y1...X2...Y2 > > > and the hypervisor must be able to deal with this. > > > > > > Then there would need to be two "versions" of "xm/xl free". > > > We can quibble about which should be the default, but > > > they would be: > > > > > > - "xl --reserved free" asks the hypervisor how much RAM > > > is available taking into account reservations > > > - "xm --raw free" asks the hypervisor for the instantaneous > > > amount of RAM unallocated, not counting reservations > > > > > > When the tools are not launching a domain (that is there > > > has been a matching X2 for all X1), the results of the > > > above "free" queries are always identical. > > > > > > So, IanJ, does this match up with the design you were thinking > > > about? > > > > > > Thanks, > > > Dan > > > > > > [1] I think the core culprits are (a) the hypervisor accounts for > > > memory allocation of pages strictly on a first-come-first-served > > > basis and (b) the tools don't have any form of need-this-much-memory > > > "transaction" model _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 16:54:48 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 16:54:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJogy-0004ui-0t; Thu, 04 Oct 2012 16:54:32 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJogw-0004ud-A2 for xen-devel@lists.xen.org; Thu, 04 Oct 2012 16:54:30 +0000 Received: from [85.158.143.35:9685] by server-1.bemta-4.messagelabs.com id 08/05-05684-54FBD605; Thu, 04 Oct 2012 16:54:29 +0000 X-Env-Sender: dan.magenheimer@oracle.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1349369667!17498621!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzgzMjE1\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18440 invoked from network); 4 Oct 2012 16:54:28 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Oct 2012 16:54:28 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q94GsE0b002977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Oct 2012 16:54:15 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q94GsB5C003786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Oct 2012 16:54:11 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q94GsAqT003932; Thu, 4 Oct 2012 11:54:10 -0500 MIME-Version: 1.0 Message-ID: <3e5cf0ba-4241-4f00-bef6-aaff2cc23419@default> Date: Thu, 4 Oct 2012 09:54:04 -0700 (PDT) From: Dan Magenheimer To: Andres Lagar-Cavilla , Ian Campbell References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> <20121002091017.GA95926@ocelot.phlegethon.org> <66cc0085-1216-40f7-8059-eaf615202c12@default> <20121002201624.GA98445@ocelot.phlegethon.org> <20121004100645.GC38243@ocelot.phlegethon.org> <1349345864.650.247.camel@zakaz.uk.xensource.com> <239799F4-AF29-494F-86D2-ADF45ACA8792@gridcentric.ca> In-Reply-To: <239799F4-AF29-494F-86D2-ADF45ACA8792@gridcentric.ca> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7 (607090) [OL 12.0.6661.5003 (x86)] X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: Olaf Hering , "Keir \(Xen.org\)" , Konrad Wilk , George Dunlap , Kurt Hackel , Tim Deegan , xen-devel@lists.xen.org, George Shuklin , Dario Faggioli , Ian Jackson Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > From: Andres Lagar-Cavilla [mailto:andreslc@gridcentric.ca] > Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) > > > On Oct 4, 2012, at 6:17 AM, Ian Campbell wrote: > > > On Thu, 2012-10-04 at 11:06 +0100, Tim Deegan wrote: > >> but my question was really: what should xl do, in the presence of > >> ballooning, sharing, paging and tmem, to > >> - decide whether a VM can be started at all; > >> - control those four systems to shuffle memory around; and > > Are we talking about a per-VM control, with one or more of those sub-systems colluding concurrently? > Or are we talking about a global view, and how chunks of host memory get sub-allocated? Hopefully the > latter... > > >> - resolve races sensibly to avoid small VMs deferring large ones. > >> (AIUI, xl already has some logic to handle the case of balloon-to-fit.) > >> > >> The second of those three is the interesting one. It seems to me that > >> if the tools can't force all other actors to give up memory (and not > >> immediately take it back) then they can't guarantee to be able to start > >> a new VM, even with the new reservation hypercalls. > > > > There was a bit of discussion in the spring about this sort of thing > > (well, three of the four), which seems to have fallen a bit by the > > wayside^W^W^W^W^W^Wbeen deferred until 4.3 (ahem) e.g. > > http://lists.xen.org/archives/html/xen-devel/2012-03/msg01181.html > > > > I'm sure there was earlier discussion which led to that, but I can't > > seem to see it in the archives right now, perhaps I'm not looking for > > the right Subject. > > IIRC, we had a bit of that conversation during the Santa Clara hackathon. The idea was to devise a > scheme so that libxl can be told who the "actor" will be for memory management, and then hand-off > appropriately. Add xl bindings, suitable defaults, and an implementation of the "balloon actor" by Scanning through the archived message I am under the impression that the focus is on a single server... i.e. "punt if actor is not xl", i.e. it addressed "balloon-to-fit" and only tries to avoid stepping on other memory overcommit technologies. That makes it almost orthogonal, I think, to the problem I originally raised. But a bigger concern is that its focus on a single machine ignores the "cloud", where Xen seems to hold an advantage. In the cloud, the actor is "controlling" _many_ machines. In the problem I originally raised, this actor (a centralized management console) is simply looking for a server that has sufficient memory to house a new domain, and it (or the automation/sysadmin running it) gets unhappy if (xl running on) the server says "yes there is enough memory" but then later says, "oops, I guess there wasn't enough after all". > libxl, and the end result is the ability to start domains with a memory target suitably managed by > balloon, xenpaging, tmem, foo, according to the user's wish. With no need to know obscure knobs. To > the extent that might be possible. Am I detecting s[k|c]epticism? If so, I too am s[k|c]eptical. Dan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 16:54:48 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 16:54:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJogy-0004ui-0t; Thu, 04 Oct 2012 16:54:32 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJogw-0004ud-A2 for xen-devel@lists.xen.org; Thu, 04 Oct 2012 16:54:30 +0000 Received: from [85.158.143.35:9685] by server-1.bemta-4.messagelabs.com id 08/05-05684-54FBD605; Thu, 04 Oct 2012 16:54:29 +0000 X-Env-Sender: dan.magenheimer@oracle.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1349369667!17498621!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzgzMjE1\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18440 invoked from network); 4 Oct 2012 16:54:28 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Oct 2012 16:54:28 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q94GsE0b002977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Oct 2012 16:54:15 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q94GsB5C003786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Oct 2012 16:54:11 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q94GsAqT003932; Thu, 4 Oct 2012 11:54:10 -0500 MIME-Version: 1.0 Message-ID: <3e5cf0ba-4241-4f00-bef6-aaff2cc23419@default> Date: Thu, 4 Oct 2012 09:54:04 -0700 (PDT) From: Dan Magenheimer To: Andres Lagar-Cavilla , Ian Campbell References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> <20121002091017.GA95926@ocelot.phlegethon.org> <66cc0085-1216-40f7-8059-eaf615202c12@default> <20121002201624.GA98445@ocelot.phlegethon.org> <20121004100645.GC38243@ocelot.phlegethon.org> <1349345864.650.247.camel@zakaz.uk.xensource.com> <239799F4-AF29-494F-86D2-ADF45ACA8792@gridcentric.ca> In-Reply-To: <239799F4-AF29-494F-86D2-ADF45ACA8792@gridcentric.ca> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7 (607090) [OL 12.0.6661.5003 (x86)] X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: Olaf Hering , "Keir \(Xen.org\)" , Konrad Wilk , George Dunlap , Kurt Hackel , Tim Deegan , xen-devel@lists.xen.org, George Shuklin , Dario Faggioli , Ian Jackson Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > From: Andres Lagar-Cavilla [mailto:andreslc@gridcentric.ca] > Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) > > > On Oct 4, 2012, at 6:17 AM, Ian Campbell wrote: > > > On Thu, 2012-10-04 at 11:06 +0100, Tim Deegan wrote: > >> but my question was really: what should xl do, in the presence of > >> ballooning, sharing, paging and tmem, to > >> - decide whether a VM can be started at all; > >> - control those four systems to shuffle memory around; and > > Are we talking about a per-VM control, with one or more of those sub-systems colluding concurrently? > Or are we talking about a global view, and how chunks of host memory get sub-allocated? Hopefully the > latter... > > >> - resolve races sensibly to avoid small VMs deferring large ones. > >> (AIUI, xl already has some logic to handle the case of balloon-to-fit.) > >> > >> The second of those three is the interesting one. It seems to me that > >> if the tools can't force all other actors to give up memory (and not > >> immediately take it back) then they can't guarantee to be able to start > >> a new VM, even with the new reservation hypercalls. > > > > There was a bit of discussion in the spring about this sort of thing > > (well, three of the four), which seems to have fallen a bit by the > > wayside^W^W^W^W^W^Wbeen deferred until 4.3 (ahem) e.g. > > http://lists.xen.org/archives/html/xen-devel/2012-03/msg01181.html > > > > I'm sure there was earlier discussion which led to that, but I can't > > seem to see it in the archives right now, perhaps I'm not looking for > > the right Subject. > > IIRC, we had a bit of that conversation during the Santa Clara hackathon. The idea was to devise a > scheme so that libxl can be told who the "actor" will be for memory management, and then hand-off > appropriately. Add xl bindings, suitable defaults, and an implementation of the "balloon actor" by Scanning through the archived message I am under the impression that the focus is on a single server... i.e. "punt if actor is not xl", i.e. it addressed "balloon-to-fit" and only tries to avoid stepping on other memory overcommit technologies. That makes it almost orthogonal, I think, to the problem I originally raised. But a bigger concern is that its focus on a single machine ignores the "cloud", where Xen seems to hold an advantage. In the cloud, the actor is "controlling" _many_ machines. In the problem I originally raised, this actor (a centralized management console) is simply looking for a server that has sufficient memory to house a new domain, and it (or the automation/sysadmin running it) gets unhappy if (xl running on) the server says "yes there is enough memory" but then later says, "oops, I guess there wasn't enough after all". > libxl, and the end result is the ability to start domains with a memory target suitably managed by > balloon, xenpaging, tmem, foo, according to the user's wish. With no need to know obscure knobs. To > the extent that might be possible. Am I detecting s[k|c]epticism? If so, I too am s[k|c]eptical. Dan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 17:00:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 17:00:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJolx-00053O-O6; Thu, 04 Oct 2012 16:59:41 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJolw-00053J-O9 for xen-devel@lists.xen.org; Thu, 04 Oct 2012 16:59:40 +0000 Received: from [85.158.139.83:45709] by server-7.bemta-5.messagelabs.com id 03/D1-00431-B70CD605; Thu, 04 Oct 2012 16:59:39 +0000 X-Env-Sender: dan.magenheimer@oracle.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1349369978!31249717!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzgzMjE1\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10532 invoked from network); 4 Oct 2012 16:59:39 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Oct 2012 16:59:39 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q94GxTCq010155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Oct 2012 16:59:30 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q94GxSHl029182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Oct 2012 16:59:28 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q94GxSdh010675; Thu, 4 Oct 2012 11:59:28 -0500 MIME-Version: 1.0 Message-ID: <48a08581-faa9-40a0-8afd-dc334ab82e43@default> Date: Thu, 4 Oct 2012 09:59:22 -0700 (PDT) From: Dan Magenheimer To: Andres Lagar-Cavilla , Tim Deegan References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> <20121002091017.GA95926@ocelot.phlegethon.org> <66cc0085-1216-40f7-8059-eaf615202c12@default> <20121002201624.GA98445@ocelot.phlegethon.org> <20121004100645.GC38243@ocelot.phlegethon.org> <51CA094C-870A-4772-A22E-4CB151E854F2@gridcentric.ca> In-Reply-To: <51CA094C-870A-4772-A22E-4CB151E854F2@gridcentric.ca> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7 (607090) [OL 12.0.6661.5003 (x86)] X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: Olaf Hering , Keir Fraser , Konrad Wilk , George Dunlap , Kurt Hackel , Ian Jackson , xen-devel@lists.xen.org, George Shuklin , Dario Faggioli Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > From: Andres Lagar-Cavilla [mailto:andreslc@gridcentric.ca] > Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) > > On Oct 4, 2012, at 6:06 AM, Tim Deegan wrote: > > > At 14:56 -0700 on 02 Oct (1349189817), Dan Magenheimer wrote: > >> Tmem argues that doing "memory capacity transfers" at a page granularity > >> can only be done efficiently in the hypervisor. This is true for > >> page-sharing when it breaks a "share" also... it can't go ask the > >> toolstack to approve allocation of a new page every time a write to a shared > >> page occurs. > >> > >> Does that make sense? > > > > Yes. The page-sharing version can be handled by having a pool of > > dedicated memory for breaking shares, and the toolstack asynchronously > > replenish that, rather than allowing CoW to use up all memory in the > > system. > > That is doable. One benefit is that it would minimize the chance of a VM hitting a CoW ENOMEM. I don't > see how it would altogether avoid it. Agreed, so it doesn't really solve the problem. (See longer reply to Tim.) > If the objective is trying to put a cap to the unpredictable growth of memory allocations via CoW > unsharing, two observations: (1) will never grow past nominal VM footprint (2) One can put a cap today > by tweaking d->max_pages -- CoW will fail, faulting vcpu will sleep, and things can be kicked back > into action at a later point. But IIRC isn't it (2) that has given VMware memory overcommit a bad name? Any significant memory pressure due to overcommit leads to double-swapping, which leads to horrible performance? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 17:00:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 17:00:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJolx-00053O-O6; Thu, 04 Oct 2012 16:59:41 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJolw-00053J-O9 for xen-devel@lists.xen.org; Thu, 04 Oct 2012 16:59:40 +0000 Received: from [85.158.139.83:45709] by server-7.bemta-5.messagelabs.com id 03/D1-00431-B70CD605; Thu, 04 Oct 2012 16:59:39 +0000 X-Env-Sender: dan.magenheimer@oracle.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1349369978!31249717!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzgzMjE1\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10532 invoked from network); 4 Oct 2012 16:59:39 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Oct 2012 16:59:39 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q94GxTCq010155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Oct 2012 16:59:30 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q94GxSHl029182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Oct 2012 16:59:28 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q94GxSdh010675; Thu, 4 Oct 2012 11:59:28 -0500 MIME-Version: 1.0 Message-ID: <48a08581-faa9-40a0-8afd-dc334ab82e43@default> Date: Thu, 4 Oct 2012 09:59:22 -0700 (PDT) From: Dan Magenheimer To: Andres Lagar-Cavilla , Tim Deegan References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> <20121002091017.GA95926@ocelot.phlegethon.org> <66cc0085-1216-40f7-8059-eaf615202c12@default> <20121002201624.GA98445@ocelot.phlegethon.org> <20121004100645.GC38243@ocelot.phlegethon.org> <51CA094C-870A-4772-A22E-4CB151E854F2@gridcentric.ca> In-Reply-To: <51CA094C-870A-4772-A22E-4CB151E854F2@gridcentric.ca> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7 (607090) [OL 12.0.6661.5003 (x86)] X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: Olaf Hering , Keir Fraser , Konrad Wilk , George Dunlap , Kurt Hackel , Ian Jackson , xen-devel@lists.xen.org, George Shuklin , Dario Faggioli Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > From: Andres Lagar-Cavilla [mailto:andreslc@gridcentric.ca] > Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) > > On Oct 4, 2012, at 6:06 AM, Tim Deegan wrote: > > > At 14:56 -0700 on 02 Oct (1349189817), Dan Magenheimer wrote: > >> Tmem argues that doing "memory capacity transfers" at a page granularity > >> can only be done efficiently in the hypervisor. This is true for > >> page-sharing when it breaks a "share" also... it can't go ask the > >> toolstack to approve allocation of a new page every time a write to a shared > >> page occurs. > >> > >> Does that make sense? > > > > Yes. The page-sharing version can be handled by having a pool of > > dedicated memory for breaking shares, and the toolstack asynchronously > > replenish that, rather than allowing CoW to use up all memory in the > > system. > > That is doable. One benefit is that it would minimize the chance of a VM hitting a CoW ENOMEM. I don't > see how it would altogether avoid it. Agreed, so it doesn't really solve the problem. (See longer reply to Tim.) > If the objective is trying to put a cap to the unpredictable growth of memory allocations via CoW > unsharing, two observations: (1) will never grow past nominal VM footprint (2) One can put a cap today > by tweaking d->max_pages -- CoW will fail, faulting vcpu will sleep, and things can be kicked back > into action at a later point. But IIRC isn't it (2) that has given VMware memory overcommit a bad name? Any significant memory pressure due to overcommit leads to double-swapping, which leads to horrible performance? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 17:00:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 17:00:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJomq-00058w-69; Thu, 04 Oct 2012 17:00:36 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJomo-00058g-8I for xen-devel@lists.xen.org; Thu, 04 Oct 2012 17:00:34 +0000 Received: from [85.158.137.99:21843] by server-2.bemta-3.messagelabs.com id 9E/DB-16514-1B0CD605; Thu, 04 Oct 2012 17:00:33 +0000 X-Env-Sender: andreslc@gridcentric.ca X-Msg-Ref: server-9.tower-217.messagelabs.com!1349370031!17152781!1 X-Originating-IP: [209.85.223.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20586 invoked from network); 4 Oct 2012 17:00:32 -0000 Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com) (209.85.223.173) by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 17:00:32 -0000 Received: by mail-ie0-f173.google.com with SMTP id 17so1923334iea.32 for ; Thu, 04 Oct 2012 10:00:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:x-priority:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=q5eGafwDEnNUpJpI1INZsG7PexBwy5zy0AtJmPp/1JY=; b=XJXP45k5NFQjUHrfANtfA/E1LgKd2R2kwFgXc3ngo/kcIUldpP+jO3eZIWn13+6eqs mTw3iIm2n3gDTwAMAq74tNNVp2Ak74P4IT8AHUSmoaY6tAmmn2gDMP2+uggiN3IhgE/r 3BCV7MHBp5TWkXD194U3ySJ8+iR8Pdq3Gx0bAspcDnwxG8+20g5DOrv85rZ6hFGFkM7w lPeDflaOmXmdUiyNZy0kLSAOP3j+dyQJ62qYqoGYXZHPR9Ft7s70CMuEWqnRuECH88JP sbZ/QphTXTowrKMZ0EgcgYK3kYQzyfhF/bFvI7yPTSxx7JCgFyG9arJVzAz7ZutGJTm1 CXjw== Received: by 10.42.84.69 with SMTP id k5mr5038763icl.5.1349370030571; Thu, 04 Oct 2012 10:00:30 -0700 (PDT) Received: from [192.168.3.238] ([206.223.182.18]) by mx.google.com with ESMTPS id az6sm1956154igb.11.2012.10.04.10.00.28 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Oct 2012 10:00:30 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) From: Andres Lagar-Cavilla X-Priority: 3 In-Reply-To: <3e5cf0ba-4241-4f00-bef6-aaff2cc23419@default> Date: Thu, 4 Oct 2012 13:00:28 -0400 Message-Id: <55FB3955-E79D-4488-830B-A46F6F102AE0@gridcentric.ca> References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> <20121002091017.GA95926@ocelot.phlegethon.org> <66cc0085-1216-40f7-8059-eaf615202c12@default> <20121002201624.GA98445@ocelot.phlegethon.org> <20121004100645.GC38243@ocelot.phlegethon.org> <1349345864.650.247.camel@zakaz.uk.xensource.com> <239799F4-AF29-494F-86D2-ADF45ACA8792@gridcentric.ca> <3e5cf0ba-4241-4f00-bef6-aaff2cc23419@default> To: Dan Magenheimer X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQljtCPJ2IYdAXHxTN7yfDPhyOi2azNGFDqJDUNbOklLTu+mLOwQPpK8tdgeec8cbW4hdtK7 Cc: Olaf Hering , "Keir \(Xen.org\)" , Ian Campbell , Konrad Wilk , George Dunlap , Kurt Hackel , Tim Deegan , xen-devel@lists.xen.org, George Shuklin , Dario Faggioli , Ian Jackson Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Oct 4, 2012, at 12:54 PM, Dan Magenheimer wrote: >> From: Andres Lagar-Cavilla [mailto:andreslc@gridcentric.ca] >> Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) >> >> >> On Oct 4, 2012, at 6:17 AM, Ian Campbell wrote: >> >>> On Thu, 2012-10-04 at 11:06 +0100, Tim Deegan wrote: >>>> but my question was really: what should xl do, in the presence of >>>> ballooning, sharing, paging and tmem, to >>>> - decide whether a VM can be started at all; >>>> - control those four systems to shuffle memory around; and >> >> Are we talking about a per-VM control, with one or more of those sub-systems colluding concurrently? >> Or are we talking about a global view, and how chunks of host memory get sub-allocated? Hopefully the >> latter... >> >>>> - resolve races sensibly to avoid small VMs deferring large ones. >>>> (AIUI, xl already has some logic to handle the case of balloon-to-fit.) >>>> >>>> The second of those three is the interesting one. It seems to me that >>>> if the tools can't force all other actors to give up memory (and not >>>> immediately take it back) then they can't guarantee to be able to start >>>> a new VM, even with the new reservation hypercalls. >>> >>> There was a bit of discussion in the spring about this sort of thing >>> (well, three of the four), which seems to have fallen a bit by the >>> wayside^W^W^W^W^W^Wbeen deferred until 4.3 (ahem) e.g. >>> http://lists.xen.org/archives/html/xen-devel/2012-03/msg01181.html >>> >>> I'm sure there was earlier discussion which led to that, but I can't >>> seem to see it in the archives right now, perhaps I'm not looking for >>> the right Subject. >> >> IIRC, we had a bit of that conversation during the Santa Clara hackathon. The idea was to devise a >> scheme so that libxl can be told who the "actor" will be for memory management, and then hand-off >> appropriately. Add xl bindings, suitable defaults, and an implementation of the "balloon actor" by > > Scanning through the archived message I am under the impression > that the focus is on a single server... i.e. "punt if actor is > not xl", i.e. it addressed "balloon-to-fit" and only tries to avoid > stepping on other memory overcommit technologies. That makes it > almost orthogonal, I think, to the problem I originally raised. Yeah, fairly orthogonal. > > But a bigger concern is that its focus on a single machine ignores > the "cloud", where Xen seems to hold an advantage. In the cloud, > the actor is "controlling" _many_ machines. In the problem I > originally raised, this actor (a centralized management console) > is simply looking for a server that has sufficient memory to house > a new domain, and it (or the automation/sysadmin running it) gets > unhappy if (xl running on) the server says "yes there is enough > memory" but then later says, "oops, I guess there wasn't enough > after all". Big problem in itself, but not one for xen.org (yet, cart before horse). Have you had a look at the Openstack FilterScheduler? Plenty of room for contribution. > >> libxl, and the end result is the ability to start domains with a memory target suitably managed by >> balloon, xenpaging, tmem, foo, according to the user's wish. With no need to know obscure knobs. To >> the extent that might be possible. > > Am I detecting s[k|c]epticism? > > If so, I too am s[k|c]eptical. Well, not really. Things have to coexist cleanly, to the extent feasible. Devising a libxl protocol to perform clean hand off if required, and to expose minimum complexity to the average joe, is a great idea imho. Andres > > Dan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 17:00:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 17:00:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJomq-00058w-69; Thu, 04 Oct 2012 17:00:36 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJomo-00058g-8I for xen-devel@lists.xen.org; Thu, 04 Oct 2012 17:00:34 +0000 Received: from [85.158.137.99:21843] by server-2.bemta-3.messagelabs.com id 9E/DB-16514-1B0CD605; Thu, 04 Oct 2012 17:00:33 +0000 X-Env-Sender: andreslc@gridcentric.ca X-Msg-Ref: server-9.tower-217.messagelabs.com!1349370031!17152781!1 X-Originating-IP: [209.85.223.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20586 invoked from network); 4 Oct 2012 17:00:32 -0000 Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com) (209.85.223.173) by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 17:00:32 -0000 Received: by mail-ie0-f173.google.com with SMTP id 17so1923334iea.32 for ; Thu, 04 Oct 2012 10:00:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:x-priority:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=q5eGafwDEnNUpJpI1INZsG7PexBwy5zy0AtJmPp/1JY=; b=XJXP45k5NFQjUHrfANtfA/E1LgKd2R2kwFgXc3ngo/kcIUldpP+jO3eZIWn13+6eqs mTw3iIm2n3gDTwAMAq74tNNVp2Ak74P4IT8AHUSmoaY6tAmmn2gDMP2+uggiN3IhgE/r 3BCV7MHBp5TWkXD194U3ySJ8+iR8Pdq3Gx0bAspcDnwxG8+20g5DOrv85rZ6hFGFkM7w lPeDflaOmXmdUiyNZy0kLSAOP3j+dyQJ62qYqoGYXZHPR9Ft7s70CMuEWqnRuECH88JP sbZ/QphTXTowrKMZ0EgcgYK3kYQzyfhF/bFvI7yPTSxx7JCgFyG9arJVzAz7ZutGJTm1 CXjw== Received: by 10.42.84.69 with SMTP id k5mr5038763icl.5.1349370030571; Thu, 04 Oct 2012 10:00:30 -0700 (PDT) Received: from [192.168.3.238] ([206.223.182.18]) by mx.google.com with ESMTPS id az6sm1956154igb.11.2012.10.04.10.00.28 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Oct 2012 10:00:30 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) From: Andres Lagar-Cavilla X-Priority: 3 In-Reply-To: <3e5cf0ba-4241-4f00-bef6-aaff2cc23419@default> Date: Thu, 4 Oct 2012 13:00:28 -0400 Message-Id: <55FB3955-E79D-4488-830B-A46F6F102AE0@gridcentric.ca> References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> <20121002091017.GA95926@ocelot.phlegethon.org> <66cc0085-1216-40f7-8059-eaf615202c12@default> <20121002201624.GA98445@ocelot.phlegethon.org> <20121004100645.GC38243@ocelot.phlegethon.org> <1349345864.650.247.camel@zakaz.uk.xensource.com> <239799F4-AF29-494F-86D2-ADF45ACA8792@gridcentric.ca> <3e5cf0ba-4241-4f00-bef6-aaff2cc23419@default> To: Dan Magenheimer X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQljtCPJ2IYdAXHxTN7yfDPhyOi2azNGFDqJDUNbOklLTu+mLOwQPpK8tdgeec8cbW4hdtK7 Cc: Olaf Hering , "Keir \(Xen.org\)" , Ian Campbell , Konrad Wilk , George Dunlap , Kurt Hackel , Tim Deegan , xen-devel@lists.xen.org, George Shuklin , Dario Faggioli , Ian Jackson Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Oct 4, 2012, at 12:54 PM, Dan Magenheimer wrote: >> From: Andres Lagar-Cavilla [mailto:andreslc@gridcentric.ca] >> Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) >> >> >> On Oct 4, 2012, at 6:17 AM, Ian Campbell wrote: >> >>> On Thu, 2012-10-04 at 11:06 +0100, Tim Deegan wrote: >>>> but my question was really: what should xl do, in the presence of >>>> ballooning, sharing, paging and tmem, to >>>> - decide whether a VM can be started at all; >>>> - control those four systems to shuffle memory around; and >> >> Are we talking about a per-VM control, with one or more of those sub-systems colluding concurrently? >> Or are we talking about a global view, and how chunks of host memory get sub-allocated? Hopefully the >> latter... >> >>>> - resolve races sensibly to avoid small VMs deferring large ones. >>>> (AIUI, xl already has some logic to handle the case of balloon-to-fit.) >>>> >>>> The second of those three is the interesting one. It seems to me that >>>> if the tools can't force all other actors to give up memory (and not >>>> immediately take it back) then they can't guarantee to be able to start >>>> a new VM, even with the new reservation hypercalls. >>> >>> There was a bit of discussion in the spring about this sort of thing >>> (well, three of the four), which seems to have fallen a bit by the >>> wayside^W^W^W^W^W^Wbeen deferred until 4.3 (ahem) e.g. >>> http://lists.xen.org/archives/html/xen-devel/2012-03/msg01181.html >>> >>> I'm sure there was earlier discussion which led to that, but I can't >>> seem to see it in the archives right now, perhaps I'm not looking for >>> the right Subject. >> >> IIRC, we had a bit of that conversation during the Santa Clara hackathon. The idea was to devise a >> scheme so that libxl can be told who the "actor" will be for memory management, and then hand-off >> appropriately. Add xl bindings, suitable defaults, and an implementation of the "balloon actor" by > > Scanning through the archived message I am under the impression > that the focus is on a single server... i.e. "punt if actor is > not xl", i.e. it addressed "balloon-to-fit" and only tries to avoid > stepping on other memory overcommit technologies. That makes it > almost orthogonal, I think, to the problem I originally raised. Yeah, fairly orthogonal. > > But a bigger concern is that its focus on a single machine ignores > the "cloud", where Xen seems to hold an advantage. In the cloud, > the actor is "controlling" _many_ machines. In the problem I > originally raised, this actor (a centralized management console) > is simply looking for a server that has sufficient memory to house > a new domain, and it (or the automation/sysadmin running it) gets > unhappy if (xl running on) the server says "yes there is enough > memory" but then later says, "oops, I guess there wasn't enough > after all". Big problem in itself, but not one for xen.org (yet, cart before horse). Have you had a look at the Openstack FilterScheduler? Plenty of room for contribution. > >> libxl, and the end result is the ability to start domains with a memory target suitably managed by >> balloon, xenpaging, tmem, foo, according to the user's wish. With no need to know obscure knobs. To >> the extent that might be possible. > > Am I detecting s[k|c]epticism? > > If so, I too am s[k|c]eptical. Well, not really. Things have to coexist cleanly, to the extent feasible. Devising a libxl protocol to perform clean hand off if required, and to expose minimum complexity to the average joe, is a great idea imho. Andres > > Dan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 17:01:07 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 17:01:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJon8-0005BX-JW; Thu, 04 Oct 2012 17:00:54 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJon7-0005BD-87 for xen-devel@lists.xen.org; Thu, 04 Oct 2012 17:00:53 +0000 Received: from [85.158.143.35:56472] by server-1.bemta-4.messagelabs.com id 48/6A-05684-4C0CD605; Thu, 04 Oct 2012 17:00:52 +0000 X-Env-Sender: jean.guyader@gmail.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1349370049!12406943!1 X-Originating-IP: [209.85.212.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4129 invoked from network); 4 Oct 2012 17:00:50 -0000 Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com) (209.85.212.45) by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 17:00:50 -0000 Received: by mail-vb0-f45.google.com with SMTP id p1so1008299vbi.32 for ; Thu, 04 Oct 2012 10:00:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=tPq6oJuVK489PNSAMqKRic8BvTnB5mGOyLZ5wutVwN4=; b=nc1ICwfrfmShrvh0aOAEsoSw+KMh0yEuTT3Nt4sFAkF6kAtPSqxB2yMOt593I96161 C277cZMPgLs6KROgkGbNQYIdS/eAWCd+zONfbnl8DAhHfpLPGvhuuMIGXOFmqRDlY1c8 28D/Kst1whvqhj8cPcghn8xlvYYG/HxI/q0CM/xhS5yWzHwli6gYaN6iH4AkyicE2cai mq4kMuOaW1bhldfJWvOP9W5hSf6kC3Rtvgao4iYIDcZPiXHvVYDJI5QWfhE+ee+NsCiH EN0g4xAbFZkoUTYPMQLl6bBqieZARkggsfFqtXjOLi7V2TyH/qvrzq6oP0imvOgKvTkV 03TQ== Received: by 10.52.92.11 with SMTP id ci11mr2857424vdb.7.1349370048421; Thu, 04 Oct 2012 10:00:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.234.5 with HTTP; Thu, 4 Oct 2012 10:00:26 -0700 (PDT) In-Reply-To: <20121004151214.GG38243@ocelot.phlegethon.org> References: <1348141322-28657-1-git-send-email-jean.guyader@citrix.com> <1348141322-28657-5-git-send-email-jean.guyader@citrix.com> <505B2636020000780009CAA6@nat28.tlf.novell.com> <506D98FE020000780009FA23@nat28.tlf.novell.com> <20121004151214.GG38243@ocelot.phlegethon.org> From: Jean Guyader Date: Thu, 4 Oct 2012 18:00:26 +0100 Message-ID: To: Tim Deegan Content-Type: multipart/mixed; boundary=20cf3071ce0a68203804cb3eb2e2 Cc: Jean Guyader , Jan Beulich , xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH 4/4] xen: Add V4V implementation X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --20cf3071ce0a68203804cb3eb2e2 Content-Type: text/plain; charset=ISO-8859-1 On 4 October 2012 16:12, Tim Deegan wrote: > At 16:03 +0100 on 04 Oct (1349366589), Jean Guyader wrote: >> On 4 October 2012 13:11, Jan Beulich wrote: >> >>>> On 04.10.12 at 14:03, Jean Guyader wrote: >> >> On 20 September 2012 13:20, Jan Beulich wrote: >> >>>>>> On 20.09.12 at 13:42, Jean Guyader wrote: >> >>>>+ case V4VOP_register_ring: >> >>>>+ { >> >>>>+ XEN_GUEST_HANDLE(v4v_ring_t) ring_hnd = >> >>>>+ guest_handle_cast(arg1, v4v_ring_t); >> >>>>+ XEN_GUEST_HANDLE(xen_pfn_t) pfn_hnd = >> >>>>+ guest_handle_cast(arg2, xen_pfn_t); >> >>>>+ uint32_t npage = arg3; >> >>>>+ if ( unlikely(!guest_handle_okay(ring_hnd, 1)) ) >> >>>>+ goto out; >> >>>>+ if ( unlikely(!guest_handle_okay(pfn_hnd, npage)) ) >> >>>>+ goto out; >> >>> >> >>> Here and below - this isn't sufficient for compat guests, or else >> >>> you give them a way to point into the compat m2p table. >> >>> >> >> >> >> I'll probably switch to uint64_t for the v4v mfn list instead of using >> >> xen_pfn_t which >> >> are unsigned long. That way I can save the need for a compat wrapper. >> > >> > But that comment of yours doesn't address the problem I pointed >> > out. >> > >> >> [Resent, CCing everyone this time] >> >> I'm sorry, I don't really get what you mean them. I've tried to get >> all my struct >> layout such as all the offset for the field are the same for 64b and 32b, this >> way I thought I could get away with doing a compat wrapper. > > Even if the args don't need translation, compat-mode guests have > different VA layouts and need different range checks (though I'm not > sure why these aren't automatically adjusted based on current). > > AIUI you need to use compat_handle_okay() instead of guest_handle_okay() > to check the handles if is_pv_32on64_domain(current). > How about something like that? Jean --20cf3071ce0a68203804cb3eb2e2 Content-Type: application/octet-stream; name="guest_handle_okay_maybe_compat.patch" Content-Disposition: attachment; filename="guest_handle_okay_maybe_compat.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h7w45v4p0 ZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL2FzbS14ODYvZ3Vlc3RfYWNjZXNzLmggYi94ZW4vaW5j bHVkZS9hc20teDg2L2d1ZXN0X2FjY2Vzcy5oCmluZGV4IGUzYWMxZDYuLjU5NmQ4YTAgMTAwNjQ0 Ci0tLSBhL3hlbi9pbmNsdWRlL2FzbS14ODYvZ3Vlc3RfYWNjZXNzLmgKKysrIGIveGVuL2luY2x1 ZGUvYXNtLXg4Ni9ndWVzdF9hY2Nlc3MuaApAQCAtMTA0LDkgKzEwNCwxMiBAQAogICogUHJlLXZh bGlkYXRlIGEgZ3Vlc3QgaGFuZGxlLgogICogQWxsb3dzIHVzZSBvZiBmYXN0ZXIgX19jb3B5Xyog ZnVuY3Rpb25zLgogICovCi0jZGVmaW5lIGd1ZXN0X2hhbmRsZV9va2F5KGhuZCwgbnIpICAgICAg ICAgICAgICAgICAgICAgIFwKLSAgICAocGFnaW5nX21vZGVfZXh0ZXJuYWwoY3VycmVudC0+ZG9t YWluKSB8fCAgICAgICAgICAgXAotICAgICBhcnJheV9hY2Nlc3Nfb2soKGhuZCkucCwgKG5yKSwg c2l6ZW9mKCooaG5kKS5wKSkpCisjZGVmaW5lIGd1ZXN0X2hhbmRsZV9va2F5KGhuZCwgbnIpICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgKGlzX3B2XzMyb242NF9k b21haW4oY3VycmVudC0+ZG9tYWluKSAmJiAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisg ICAgIGNvbXBhdF9hcnJheV9hY2Nlc3Nfb2soKGhuZCkucCwgKG5yKSwgc2l6ZW9mKCooaG5kKS5w KSkpIHx8ICAgICAgICBcCisgICAgKCFpc19wdl8zMm9uNjRfZG9tYWluKGN1cnJlbnQtPmRvbWFp bikgJiYgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgIChwYWdpbmdfbW9kZV9leHRl cm5hbChjdXJyZW50LT5kb21haW4pIHx8ICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAg ICBhcnJheV9hY2Nlc3Nfb2soKGhuZCkucCwgKG5yKSwgc2l6ZW9mKCooaG5kKS5wKSkpKQogI2Rl ZmluZSBndWVzdF9oYW5kbGVfc3VicmFuZ2Vfb2theShobmQsIGZpcnN0LCBsYXN0KSAgICBcCiAg ICAgKHBhZ2luZ19tb2RlX2V4dGVybmFsKGN1cnJlbnQtPmRvbWFpbikgfHwgICAgICAgICAgIFwK ICAgICAgYXJyYXlfYWNjZXNzX29rKChobmQpLnAgKyAoZmlyc3QpLCAgICAgICAgICAgICAgICAg XAo= --20cf3071ce0a68203804cb3eb2e2 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --20cf3071ce0a68203804cb3eb2e2-- From xen-devel-bounces@lists.xen.org Thu Oct 04 17:01:07 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 17:01:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJon8-0005BX-JW; Thu, 04 Oct 2012 17:00:54 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJon7-0005BD-87 for xen-devel@lists.xen.org; Thu, 04 Oct 2012 17:00:53 +0000 Received: from [85.158.143.35:56472] by server-1.bemta-4.messagelabs.com id 48/6A-05684-4C0CD605; Thu, 04 Oct 2012 17:00:52 +0000 X-Env-Sender: jean.guyader@gmail.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1349370049!12406943!1 X-Originating-IP: [209.85.212.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4129 invoked from network); 4 Oct 2012 17:00:50 -0000 Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com) (209.85.212.45) by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 17:00:50 -0000 Received: by mail-vb0-f45.google.com with SMTP id p1so1008299vbi.32 for ; Thu, 04 Oct 2012 10:00:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=tPq6oJuVK489PNSAMqKRic8BvTnB5mGOyLZ5wutVwN4=; b=nc1ICwfrfmShrvh0aOAEsoSw+KMh0yEuTT3Nt4sFAkF6kAtPSqxB2yMOt593I96161 C277cZMPgLs6KROgkGbNQYIdS/eAWCd+zONfbnl8DAhHfpLPGvhuuMIGXOFmqRDlY1c8 28D/Kst1whvqhj8cPcghn8xlvYYG/HxI/q0CM/xhS5yWzHwli6gYaN6iH4AkyicE2cai mq4kMuOaW1bhldfJWvOP9W5hSf6kC3Rtvgao4iYIDcZPiXHvVYDJI5QWfhE+ee+NsCiH EN0g4xAbFZkoUTYPMQLl6bBqieZARkggsfFqtXjOLi7V2TyH/qvrzq6oP0imvOgKvTkV 03TQ== Received: by 10.52.92.11 with SMTP id ci11mr2857424vdb.7.1349370048421; Thu, 04 Oct 2012 10:00:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.234.5 with HTTP; Thu, 4 Oct 2012 10:00:26 -0700 (PDT) In-Reply-To: <20121004151214.GG38243@ocelot.phlegethon.org> References: <1348141322-28657-1-git-send-email-jean.guyader@citrix.com> <1348141322-28657-5-git-send-email-jean.guyader@citrix.com> <505B2636020000780009CAA6@nat28.tlf.novell.com> <506D98FE020000780009FA23@nat28.tlf.novell.com> <20121004151214.GG38243@ocelot.phlegethon.org> From: Jean Guyader Date: Thu, 4 Oct 2012 18:00:26 +0100 Message-ID: To: Tim Deegan Content-Type: multipart/mixed; boundary=20cf3071ce0a68203804cb3eb2e2 Cc: Jean Guyader , Jan Beulich , xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH 4/4] xen: Add V4V implementation X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --20cf3071ce0a68203804cb3eb2e2 Content-Type: text/plain; charset=ISO-8859-1 On 4 October 2012 16:12, Tim Deegan wrote: > At 16:03 +0100 on 04 Oct (1349366589), Jean Guyader wrote: >> On 4 October 2012 13:11, Jan Beulich wrote: >> >>>> On 04.10.12 at 14:03, Jean Guyader wrote: >> >> On 20 September 2012 13:20, Jan Beulich wrote: >> >>>>>> On 20.09.12 at 13:42, Jean Guyader wrote: >> >>>>+ case V4VOP_register_ring: >> >>>>+ { >> >>>>+ XEN_GUEST_HANDLE(v4v_ring_t) ring_hnd = >> >>>>+ guest_handle_cast(arg1, v4v_ring_t); >> >>>>+ XEN_GUEST_HANDLE(xen_pfn_t) pfn_hnd = >> >>>>+ guest_handle_cast(arg2, xen_pfn_t); >> >>>>+ uint32_t npage = arg3; >> >>>>+ if ( unlikely(!guest_handle_okay(ring_hnd, 1)) ) >> >>>>+ goto out; >> >>>>+ if ( unlikely(!guest_handle_okay(pfn_hnd, npage)) ) >> >>>>+ goto out; >> >>> >> >>> Here and below - this isn't sufficient for compat guests, or else >> >>> you give them a way to point into the compat m2p table. >> >>> >> >> >> >> I'll probably switch to uint64_t for the v4v mfn list instead of using >> >> xen_pfn_t which >> >> are unsigned long. That way I can save the need for a compat wrapper. >> > >> > But that comment of yours doesn't address the problem I pointed >> > out. >> > >> >> [Resent, CCing everyone this time] >> >> I'm sorry, I don't really get what you mean them. I've tried to get >> all my struct >> layout such as all the offset for the field are the same for 64b and 32b, this >> way I thought I could get away with doing a compat wrapper. > > Even if the args don't need translation, compat-mode guests have > different VA layouts and need different range checks (though I'm not > sure why these aren't automatically adjusted based on current). > > AIUI you need to use compat_handle_okay() instead of guest_handle_okay() > to check the handles if is_pv_32on64_domain(current). > How about something like that? Jean --20cf3071ce0a68203804cb3eb2e2 Content-Type: application/octet-stream; name="guest_handle_okay_maybe_compat.patch" Content-Disposition: attachment; filename="guest_handle_okay_maybe_compat.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h7w45v4p0 ZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL2FzbS14ODYvZ3Vlc3RfYWNjZXNzLmggYi94ZW4vaW5j bHVkZS9hc20teDg2L2d1ZXN0X2FjY2Vzcy5oCmluZGV4IGUzYWMxZDYuLjU5NmQ4YTAgMTAwNjQ0 Ci0tLSBhL3hlbi9pbmNsdWRlL2FzbS14ODYvZ3Vlc3RfYWNjZXNzLmgKKysrIGIveGVuL2luY2x1 ZGUvYXNtLXg4Ni9ndWVzdF9hY2Nlc3MuaApAQCAtMTA0LDkgKzEwNCwxMiBAQAogICogUHJlLXZh bGlkYXRlIGEgZ3Vlc3QgaGFuZGxlLgogICogQWxsb3dzIHVzZSBvZiBmYXN0ZXIgX19jb3B5Xyog ZnVuY3Rpb25zLgogICovCi0jZGVmaW5lIGd1ZXN0X2hhbmRsZV9va2F5KGhuZCwgbnIpICAgICAg ICAgICAgICAgICAgICAgIFwKLSAgICAocGFnaW5nX21vZGVfZXh0ZXJuYWwoY3VycmVudC0+ZG9t YWluKSB8fCAgICAgICAgICAgXAotICAgICBhcnJheV9hY2Nlc3Nfb2soKGhuZCkucCwgKG5yKSwg c2l6ZW9mKCooaG5kKS5wKSkpCisjZGVmaW5lIGd1ZXN0X2hhbmRsZV9va2F5KGhuZCwgbnIpICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgKGlzX3B2XzMyb242NF9k b21haW4oY3VycmVudC0+ZG9tYWluKSAmJiAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisg ICAgIGNvbXBhdF9hcnJheV9hY2Nlc3Nfb2soKGhuZCkucCwgKG5yKSwgc2l6ZW9mKCooaG5kKS5w KSkpIHx8ICAgICAgICBcCisgICAgKCFpc19wdl8zMm9uNjRfZG9tYWluKGN1cnJlbnQtPmRvbWFp bikgJiYgICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAgIChwYWdpbmdfbW9kZV9leHRl cm5hbChjdXJyZW50LT5kb21haW4pIHx8ICAgICAgICAgICAgICAgICAgICAgICAgICBcCisgICAg ICBhcnJheV9hY2Nlc3Nfb2soKGhuZCkucCwgKG5yKSwgc2l6ZW9mKCooaG5kKS5wKSkpKQogI2Rl ZmluZSBndWVzdF9oYW5kbGVfc3VicmFuZ2Vfb2theShobmQsIGZpcnN0LCBsYXN0KSAgICBcCiAg ICAgKHBhZ2luZ19tb2RlX2V4dGVybmFsKGN1cnJlbnQtPmRvbWFpbikgfHwgICAgICAgICAgIFwK ICAgICAgYXJyYXlfYWNjZXNzX29rKChobmQpLnAgKyAoZmlyc3QpLCAgICAgICAgICAgICAgICAg XAo= --20cf3071ce0a68203804cb3eb2e2 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --20cf3071ce0a68203804cb3eb2e2-- From xen-devel-bounces@lists.xen.org Thu Oct 04 17:08:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 17:08:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJouR-0005eX-NO; Thu, 04 Oct 2012 17:08:27 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJouQ-0005eS-30 for xen-devel@lists.xen.org; Thu, 04 Oct 2012 17:08:26 +0000 Received: from [85.158.143.99:51914] by server-1.bemta-4.messagelabs.com id 2F/01-05684-882CD605; Thu, 04 Oct 2012 17:08:24 +0000 X-Env-Sender: andreslc@gridcentric.ca X-Msg-Ref: server-15.tower-216.messagelabs.com!1349370502!32877633!1 X-Originating-IP: [209.85.210.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8552 invoked from network); 4 Oct 2012 17:08:23 -0000 Received: from mail-ia0-f173.google.com (HELO mail-ia0-f173.google.com) (209.85.210.173) by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 17:08:23 -0000 Received: by mail-ia0-f173.google.com with SMTP id m10so379847iam.32 for ; Thu, 04 Oct 2012 10:08:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:x-priority:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=3Lun1Z/sZN++Iap6Er/U1YU2vl75dsJ6ziKmVkfv2KU=; b=NlsBrL14JKhAhSGdaeJ9+Dz0oe/XQtem3alz5t27lg9Uc7mShnMlG4QmvdBN98IYTh GBboherpnFgeD+k6RAzZZedYZGGqdtd5Cv9coF17iDVnb1c+YYi9zo17OhFBGWTKUnyt 2PuYlkToHGkMk9/700Dt6Sbov64fy4S24wirdS0h65EDuYfhvP9yoXTMrvDBnBUqF6ZG 6VQ0KeT7BQPPQj954xN/USre5i7VZEekZITLIE6rq9cjNJuQzJ7LtTmmxNbjE719+Bru yupkih9lB3rHyGTUouWD53XEI05dBIl7Lk9tjc/4gmgYgGTxXeypy+4P1F55gcHf7fFi 6V1A== Received: by 10.50.46.199 with SMTP id x7mr2983280igm.19.1349370501773; Thu, 04 Oct 2012 10:08:21 -0700 (PDT) Received: from [192.168.3.238] ([206.223.182.18]) by mx.google.com with ESMTPS id uq6sm13825010igb.14.2012.10.04.10.08.20 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Oct 2012 10:08:21 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) From: Andres Lagar-Cavilla X-Priority: 3 In-Reply-To: <48a08581-faa9-40a0-8afd-dc334ab82e43@default> Date: Thu, 4 Oct 2012 13:08:19 -0400 Message-Id: <91C20B33-83CF-4B7A-A5AC-E61421B00536@gridcentric.ca> References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> <20121002091017.GA95926@ocelot.phlegethon.org> <66cc0085-1216-40f7-8059-eaf615202c12@default> <20121002201624.GA98445@ocelot.phlegethon.org> <20121004100645.GC38243@ocelot.phlegethon.org> <51CA094C-870A-4772-A22E-4CB151E854F2@gridcentric.ca> <48a08581-faa9-40a0-8afd-dc334ab82e43@default> To: Dan Magenheimer X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQmkMb0sBibBFFC6/cCM7+5Q+/ANQRU37E6/devzqWVZR0ZDgkSEQ8T8ogV4vlHvfo8eNf1y Cc: Olaf Hering , Keir Fraser , Konrad Wilk , George Dunlap , Kurt Hackel , Tim Deegan , xen-devel@lists.xen.org, George Shuklin , Dario Faggioli , Ian Jackson Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Oct 4, 2012, at 12:59 PM, Dan Magenheimer wrote: >> From: Andres Lagar-Cavilla [mailto:andreslc@gridcentric.ca] >> Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) >> >> On Oct 4, 2012, at 6:06 AM, Tim Deegan wrote: >> >>> At 14:56 -0700 on 02 Oct (1349189817), Dan Magenheimer wrote: >>>> Tmem argues that doing "memory capacity transfers" at a page granularity >>>> can only be done efficiently in the hypervisor. This is true for >>>> page-sharing when it breaks a "share" also... it can't go ask the >>>> toolstack to approve allocation of a new page every time a write to a shared >>>> page occurs. >>>> >>>> Does that make sense? >>> >>> Yes. The page-sharing version can be handled by having a pool of >>> dedicated memory for breaking shares, and the toolstack asynchronously >>> replenish that, rather than allowing CoW to use up all memory in the >>> system. >> >> That is doable. One benefit is that it would minimize the chance of a VM hitting a CoW ENOMEM. I don't >> see how it would altogether avoid it. > > Agreed, so it doesn't really solve the problem. (See longer reply > to Tim.) > >> If the objective is trying to put a cap to the unpredictable growth of memory allocations via CoW >> unsharing, two observations: (1) will never grow past nominal VM footprint (2) One can put a cap today >> by tweaking d->max_pages -- CoW will fail, faulting vcpu will sleep, and things can be kicked back >> into action at a later point. > > But IIRC isn't it (2) that has given VMware memory overcommit a bad name? > Any significant memory pressure due to overcommit leads to double-swapping, > which leads to horrible performance? The little that I've been able to read from their published results is that a "lot" of CPU is consumed scanning memory and fingerprinting, which leads to a massive assault on micro-architectural caches. I don't know if that equates to a "bad name", but I don't think that is a productive discussion either. (2) doesn't mean swapping. Note that d->max_pages can be set artificially low by an admin, raised again. etc. It's just a mechanism to keep a VM at bay while corrective measures of any kind are taken. It's really up to a higher level controller whether you accept allocations and later reach a point of thrashing. I understand this is partly where your discussion is headed, but certainly fixing the primary issue of nominal vanilla allocations preempting each other looks fairly critical to begin with. Andres _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 17:08:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 17:08:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJouR-0005eX-NO; Thu, 04 Oct 2012 17:08:27 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJouQ-0005eS-30 for xen-devel@lists.xen.org; Thu, 04 Oct 2012 17:08:26 +0000 Received: from [85.158.143.99:51914] by server-1.bemta-4.messagelabs.com id 2F/01-05684-882CD605; Thu, 04 Oct 2012 17:08:24 +0000 X-Env-Sender: andreslc@gridcentric.ca X-Msg-Ref: server-15.tower-216.messagelabs.com!1349370502!32877633!1 X-Originating-IP: [209.85.210.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8552 invoked from network); 4 Oct 2012 17:08:23 -0000 Received: from mail-ia0-f173.google.com (HELO mail-ia0-f173.google.com) (209.85.210.173) by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 17:08:23 -0000 Received: by mail-ia0-f173.google.com with SMTP id m10so379847iam.32 for ; Thu, 04 Oct 2012 10:08:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:x-priority:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=3Lun1Z/sZN++Iap6Er/U1YU2vl75dsJ6ziKmVkfv2KU=; b=NlsBrL14JKhAhSGdaeJ9+Dz0oe/XQtem3alz5t27lg9Uc7mShnMlG4QmvdBN98IYTh GBboherpnFgeD+k6RAzZZedYZGGqdtd5Cv9coF17iDVnb1c+YYi9zo17OhFBGWTKUnyt 2PuYlkToHGkMk9/700Dt6Sbov64fy4S24wirdS0h65EDuYfhvP9yoXTMrvDBnBUqF6ZG 6VQ0KeT7BQPPQj954xN/USre5i7VZEekZITLIE6rq9cjNJuQzJ7LtTmmxNbjE719+Bru yupkih9lB3rHyGTUouWD53XEI05dBIl7Lk9tjc/4gmgYgGTxXeypy+4P1F55gcHf7fFi 6V1A== Received: by 10.50.46.199 with SMTP id x7mr2983280igm.19.1349370501773; Thu, 04 Oct 2012 10:08:21 -0700 (PDT) Received: from [192.168.3.238] ([206.223.182.18]) by mx.google.com with ESMTPS id uq6sm13825010igb.14.2012.10.04.10.08.20 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Oct 2012 10:08:21 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) From: Andres Lagar-Cavilla X-Priority: 3 In-Reply-To: <48a08581-faa9-40a0-8afd-dc334ab82e43@default> Date: Thu, 4 Oct 2012 13:08:19 -0400 Message-Id: <91C20B33-83CF-4B7A-A5AC-E61421B00536@gridcentric.ca> References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> <20121002091017.GA95926@ocelot.phlegethon.org> <66cc0085-1216-40f7-8059-eaf615202c12@default> <20121002201624.GA98445@ocelot.phlegethon.org> <20121004100645.GC38243@ocelot.phlegethon.org> <51CA094C-870A-4772-A22E-4CB151E854F2@gridcentric.ca> <48a08581-faa9-40a0-8afd-dc334ab82e43@default> To: Dan Magenheimer X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQmkMb0sBibBFFC6/cCM7+5Q+/ANQRU37E6/devzqWVZR0ZDgkSEQ8T8ogV4vlHvfo8eNf1y Cc: Olaf Hering , Keir Fraser , Konrad Wilk , George Dunlap , Kurt Hackel , Tim Deegan , xen-devel@lists.xen.org, George Shuklin , Dario Faggioli , Ian Jackson Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Oct 4, 2012, at 12:59 PM, Dan Magenheimer wrote: >> From: Andres Lagar-Cavilla [mailto:andreslc@gridcentric.ca] >> Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) >> >> On Oct 4, 2012, at 6:06 AM, Tim Deegan wrote: >> >>> At 14:56 -0700 on 02 Oct (1349189817), Dan Magenheimer wrote: >>>> Tmem argues that doing "memory capacity transfers" at a page granularity >>>> can only be done efficiently in the hypervisor. This is true for >>>> page-sharing when it breaks a "share" also... it can't go ask the >>>> toolstack to approve allocation of a new page every time a write to a shared >>>> page occurs. >>>> >>>> Does that make sense? >>> >>> Yes. The page-sharing version can be handled by having a pool of >>> dedicated memory for breaking shares, and the toolstack asynchronously >>> replenish that, rather than allowing CoW to use up all memory in the >>> system. >> >> That is doable. One benefit is that it would minimize the chance of a VM hitting a CoW ENOMEM. I don't >> see how it would altogether avoid it. > > Agreed, so it doesn't really solve the problem. (See longer reply > to Tim.) > >> If the objective is trying to put a cap to the unpredictable growth of memory allocations via CoW >> unsharing, two observations: (1) will never grow past nominal VM footprint (2) One can put a cap today >> by tweaking d->max_pages -- CoW will fail, faulting vcpu will sleep, and things can be kicked back >> into action at a later point. > > But IIRC isn't it (2) that has given VMware memory overcommit a bad name? > Any significant memory pressure due to overcommit leads to double-swapping, > which leads to horrible performance? The little that I've been able to read from their published results is that a "lot" of CPU is consumed scanning memory and fingerprinting, which leads to a massive assault on micro-architectural caches. I don't know if that equates to a "bad name", but I don't think that is a productive discussion either. (2) doesn't mean swapping. Note that d->max_pages can be set artificially low by an admin, raised again. etc. It's just a mechanism to keep a VM at bay while corrective measures of any kind are taken. It's really up to a higher level controller whether you accept allocations and later reach a point of thrashing. I understand this is partly where your discussion is headed, but certainly fixing the primary issue of nominal vanilla allocations preempting each other looks fairly critical to begin with. Andres _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 17:19:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 17:19:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJp4Y-0005oT-Rx; Thu, 04 Oct 2012 17:18:54 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJp4W-0005oO-Tm for xen-devel@lists.xen.org; Thu, 04 Oct 2012 17:18:53 +0000 Received: from [85.158.137.99:37963] by server-14.bemta-3.messagelabs.com id 90/39-19528-CF4CD605; Thu, 04 Oct 2012 17:18:52 +0000 X-Env-Sender: dan.magenheimer@oracle.com X-Msg-Ref: server-16.tower-217.messagelabs.com!1349371130!20297048!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc5MzIzNg==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19936 invoked from network); 4 Oct 2012 17:18:51 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-16.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Oct 2012 17:18:51 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q94HIcxp006679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Oct 2012 17:18:39 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q94HIZWF005864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Oct 2012 17:18:36 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q94HIZbP025244; Thu, 4 Oct 2012 12:18:35 -0500 MIME-Version: 1.0 Message-ID: <16aa5326-5fd9-4f9c-b0fe-6196c6379991@default> Date: Thu, 4 Oct 2012 10:18:29 -0700 (PDT) From: Dan Magenheimer To: Andres Lagar-Cavilla References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> <20121002091017.GA95926@ocelot.phlegethon.org> <66cc0085-1216-40f7-8059-eaf615202c12@default> <20121002201624.GA98445@ocelot.phlegethon.org> <20121004100645.GC38243@ocelot.phlegethon.org> <51CA094C-870A-4772-A22E-4CB151E854F2@gridcentric.ca> <48a08581-faa9-40a0-8afd-dc334ab82e43@default> <91C20B33-83CF-4B7A-A5AC-E61421B00536@gridcentric.ca> In-Reply-To: <91C20B33-83CF-4B7A-A5AC-E61421B00536@gridcentric.ca> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7 (607090) [OL 12.0.6661.5003 (x86)] X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: Olaf Hering , Keir Fraser , Konrad Wilk , George Dunlap , Kurt Hackel , Tim Deegan , xen-devel@lists.xen.org, George Shuklin , Dario Faggioli , Ian Jackson Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > From: Andres Lagar-Cavilla [mailto:andreslc@gridcentric.ca] > Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) > > > On Oct 4, 2012, at 12:59 PM, Dan Magenheimer wrote: > > >> From: Andres Lagar-Cavilla [mailto:andreslc@gridcentric.ca] > >> Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) > >> > >> On Oct 4, 2012, at 6:06 AM, Tim Deegan wrote: > >> > >>> At 14:56 -0700 on 02 Oct (1349189817), Dan Magenheimer wrote: > >>>> Tmem argues that doing "memory capacity transfers" at a page granularity > >>>> can only be done efficiently in the hypervisor. This is true for > >>>> page-sharing when it breaks a "share" also... it can't go ask the > >>>> toolstack to approve allocation of a new page every time a write to a shared > >>>> page occurs. > >>>> > >>>> Does that make sense? > >>> > >>> Yes. The page-sharing version can be handled by having a pool of > >>> dedicated memory for breaking shares, and the toolstack asynchronously > >>> replenish that, rather than allowing CoW to use up all memory in the > >>> system. > >> > >> That is doable. One benefit is that it would minimize the chance of a VM hitting a CoW ENOMEM. I > don't > >> see how it would altogether avoid it. > > > > Agreed, so it doesn't really solve the problem. (See longer reply > > to Tim.) > > > >> If the objective is trying to put a cap to the unpredictable growth of memory allocations via CoW > >> unsharing, two observations: (1) will never grow past nominal VM footprint (2) One can put a cap > today > >> by tweaking d->max_pages -- CoW will fail, faulting vcpu will sleep, and things can be kicked back > >> into action at a later point. > > > > But IIRC isn't it (2) that has given VMware memory overcommit a bad name? > > Any significant memory pressure due to overcommit leads to double-swapping, > > which leads to horrible performance? > > The little that I've been able to read from their published results is that a "lot" of CPU is consumed > scanning memory and fingerprinting, which leads to a massive assault on micro-architectural caches. > > I don't know if that equates to a "bad name", but I don't think that is a productive discussion > either. Sorry, I wasn't intending that to be snarky, but on re-read I guess it did sound snarky. What I meant is: Is this just a manual version of what VMware does automatically? Or is there something I am misunderstanding? (I think you answered that below.) > (2) doesn't mean swapping. Note that d->max_pages can be set artificially low by an admin, raised > again. etc. It's just a mechanism to keep a VM at bay while corrective measures of any kind are taken. > It's really up to a higher level controller whether you accept allocations and later reach a point of > thrashing. > > I understand this is partly where your discussion is headed, but certainly fixing the primary issue of > nominal vanilla allocations preempting each other looks fairly critical to begin with. OK. I _think_ the design I proposed helps in systems that are using page-sharing/host-swapping as well... I assume share-breaking just calls the normal hypervisor allocator interface to allocate a new page (if available)? If you could review and comment on the design from a page-sharing/host-swapping perspective, I would appreciate it. Thanks, Dan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 17:19:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 17:19:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJp4Y-0005oT-Rx; Thu, 04 Oct 2012 17:18:54 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJp4W-0005oO-Tm for xen-devel@lists.xen.org; Thu, 04 Oct 2012 17:18:53 +0000 Received: from [85.158.137.99:37963] by server-14.bemta-3.messagelabs.com id 90/39-19528-CF4CD605; Thu, 04 Oct 2012 17:18:52 +0000 X-Env-Sender: dan.magenheimer@oracle.com X-Msg-Ref: server-16.tower-217.messagelabs.com!1349371130!20297048!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc5MzIzNg==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19936 invoked from network); 4 Oct 2012 17:18:51 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-16.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Oct 2012 17:18:51 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q94HIcxp006679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Oct 2012 17:18:39 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q94HIZWF005864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Oct 2012 17:18:36 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q94HIZbP025244; Thu, 4 Oct 2012 12:18:35 -0500 MIME-Version: 1.0 Message-ID: <16aa5326-5fd9-4f9c-b0fe-6196c6379991@default> Date: Thu, 4 Oct 2012 10:18:29 -0700 (PDT) From: Dan Magenheimer To: Andres Lagar-Cavilla References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> <20121002091017.GA95926@ocelot.phlegethon.org> <66cc0085-1216-40f7-8059-eaf615202c12@default> <20121002201624.GA98445@ocelot.phlegethon.org> <20121004100645.GC38243@ocelot.phlegethon.org> <51CA094C-870A-4772-A22E-4CB151E854F2@gridcentric.ca> <48a08581-faa9-40a0-8afd-dc334ab82e43@default> <91C20B33-83CF-4B7A-A5AC-E61421B00536@gridcentric.ca> In-Reply-To: <91C20B33-83CF-4B7A-A5AC-E61421B00536@gridcentric.ca> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7 (607090) [OL 12.0.6661.5003 (x86)] X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: Olaf Hering , Keir Fraser , Konrad Wilk , George Dunlap , Kurt Hackel , Tim Deegan , xen-devel@lists.xen.org, George Shuklin , Dario Faggioli , Ian Jackson Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > From: Andres Lagar-Cavilla [mailto:andreslc@gridcentric.ca] > Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) > > > On Oct 4, 2012, at 12:59 PM, Dan Magenheimer wrote: > > >> From: Andres Lagar-Cavilla [mailto:andreslc@gridcentric.ca] > >> Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) > >> > >> On Oct 4, 2012, at 6:06 AM, Tim Deegan wrote: > >> > >>> At 14:56 -0700 on 02 Oct (1349189817), Dan Magenheimer wrote: > >>>> Tmem argues that doing "memory capacity transfers" at a page granularity > >>>> can only be done efficiently in the hypervisor. This is true for > >>>> page-sharing when it breaks a "share" also... it can't go ask the > >>>> toolstack to approve allocation of a new page every time a write to a shared > >>>> page occurs. > >>>> > >>>> Does that make sense? > >>> > >>> Yes. The page-sharing version can be handled by having a pool of > >>> dedicated memory for breaking shares, and the toolstack asynchronously > >>> replenish that, rather than allowing CoW to use up all memory in the > >>> system. > >> > >> That is doable. One benefit is that it would minimize the chance of a VM hitting a CoW ENOMEM. I > don't > >> see how it would altogether avoid it. > > > > Agreed, so it doesn't really solve the problem. (See longer reply > > to Tim.) > > > >> If the objective is trying to put a cap to the unpredictable growth of memory allocations via CoW > >> unsharing, two observations: (1) will never grow past nominal VM footprint (2) One can put a cap > today > >> by tweaking d->max_pages -- CoW will fail, faulting vcpu will sleep, and things can be kicked back > >> into action at a later point. > > > > But IIRC isn't it (2) that has given VMware memory overcommit a bad name? > > Any significant memory pressure due to overcommit leads to double-swapping, > > which leads to horrible performance? > > The little that I've been able to read from their published results is that a "lot" of CPU is consumed > scanning memory and fingerprinting, which leads to a massive assault on micro-architectural caches. > > I don't know if that equates to a "bad name", but I don't think that is a productive discussion > either. Sorry, I wasn't intending that to be snarky, but on re-read I guess it did sound snarky. What I meant is: Is this just a manual version of what VMware does automatically? Or is there something I am misunderstanding? (I think you answered that below.) > (2) doesn't mean swapping. Note that d->max_pages can be set artificially low by an admin, raised > again. etc. It's just a mechanism to keep a VM at bay while corrective measures of any kind are taken. > It's really up to a higher level controller whether you accept allocations and later reach a point of > thrashing. > > I understand this is partly where your discussion is headed, but certainly fixing the primary issue of > nominal vanilla allocations preempting each other looks fairly critical to begin with. OK. I _think_ the design I proposed helps in systems that are using page-sharing/host-swapping as well... I assume share-breaking just calls the normal hypervisor allocator interface to allocate a new page (if available)? If you could review and comment on the design from a page-sharing/host-swapping perspective, I would appreciate it. Thanks, Dan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 17:31:14 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 17:31:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJpGG-0005yR-3R; Thu, 04 Oct 2012 17:31:00 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJpGE-0005yM-FB for xen-devel@lists.xen.org; Thu, 04 Oct 2012 17:30:58 +0000 Received: from [85.158.139.211:51273] by server-3.bemta-5.messagelabs.com id EB/DF-16108-1D7CD605; Thu, 04 Oct 2012 17:30:57 +0000 X-Env-Sender: andreslc@gridcentric.ca X-Msg-Ref: server-15.tower-206.messagelabs.com!1349371855!21155176!1 X-Originating-IP: [209.85.223.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6074 invoked from network); 4 Oct 2012 17:30:56 -0000 Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com) (209.85.223.173) by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 17:30:56 -0000 Received: by mail-ie0-f173.google.com with SMTP id 17so2009361iea.32 for ; Thu, 04 Oct 2012 10:30:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:x-priority:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=FCmU2EDum3rT8leMQp2t9waJycqqm7Ky6KUE83kLwLk=; b=jNxPZmHWyb16H+jP1rJNRRuIFSXsWUlkhrSdkuxOhBqWC5DzUOjIJvHsR6gcT5z4GG 47vQBblFEU9LOwOAza3SHgPhd/54CXLqIITj4TNLgkutJ6zVe9Fncn/o+4uEbqrcAHCN MNnkt9gPJUHk3tSFBQAhDwsaX0MoJzNW2WXZwy545F1zUoRMHW5msM3r0/dr2RgvMX+/ ngGhwg+wmdJdAtKX606ktzwDeM5vGzLKwkZeMvl5OBtM3juH6GBKzZVaornwmAf5z+KS 0ktpNBwazai/Q18nyck5Vdaqyc46LINXbBNu2npyS95W0JIEsqtlqr39BFdqXp4kbMIP HNBQ== Received: by 10.50.183.202 with SMTP id eo10mr6132274igc.38.1349371855104; Thu, 04 Oct 2012 10:30:55 -0700 (PDT) Received: from [192.168.3.238] ([206.223.182.18]) by mx.google.com with ESMTPS id 7sm15601161igh.0.2012.10.04.10.30.53 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Oct 2012 10:30:54 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) From: Andres Lagar-Cavilla X-Priority: 3 In-Reply-To: <16aa5326-5fd9-4f9c-b0fe-6196c6379991@default> Date: Thu, 4 Oct 2012 13:30:52 -0400 Message-Id: <1C4CD35F-94F0-44CF-97EA-137DF20E9669@gridcentric.ca> References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> <20121002091017.GA95926@ocelot.phlegethon.org> <66cc0085-1216-40f7-8059-eaf615202c12@default> <20121002201624.GA98445@ocelot.phlegethon.org> <20121004100645.GC38243@ocelot.phlegethon.org> <51CA094C-870A-4772-A22E-4CB151E854F2@gridcentric.ca> <48a08581-faa9-40a0-8afd-dc334ab82e43@default> <91C20B33-83CF-4B7A-A5AC-E61421B00536@gridcentric.ca> <16aa5326-5fd9-4f9c-b0fe-6196c6379991@default> To: Dan Magenheimer X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQn3qaN/yloLIJ/fN99cNVxrP2GGxRJaYj+db+QRMswR62TEinRqv3V+i/cOc85xzWJZYxOk Cc: Olaf Hering , Keir Fraser , Konrad Wilk , George Dunlap , Kurt Hackel , Tim Deegan , xen-devel@lists.xen.org, George Shuklin , Dario Faggioli , Ian Jackson Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Oct 4, 2012, at 1:18 PM, Dan Magenheimer wrote: >> From: Andres Lagar-Cavilla [mailto:andreslc@gridcentric.ca] >> Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) >> >> >> On Oct 4, 2012, at 12:59 PM, Dan Magenheimer wrote: >> >>>> From: Andres Lagar-Cavilla [mailto:andreslc@gridcentric.ca] >>>> Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) >>>> >>>> On Oct 4, 2012, at 6:06 AM, Tim Deegan wrote: >>>> >>>>> At 14:56 -0700 on 02 Oct (1349189817), Dan Magenheimer wrote: >>>>>> Tmem argues that doing "memory capacity transfers" at a page granularity >>>>>> can only be done efficiently in the hypervisor. This is true for >>>>>> page-sharing when it breaks a "share" also... it can't go ask the >>>>>> toolstack to approve allocation of a new page every time a write to a shared >>>>>> page occurs. >>>>>> >>>>>> Does that make sense? >>>>> >>>>> Yes. The page-sharing version can be handled by having a pool of >>>>> dedicated memory for breaking shares, and the toolstack asynchronously >>>>> replenish that, rather than allowing CoW to use up all memory in the >>>>> system. >>>> >>>> That is doable. One benefit is that it would minimize the chance of a VM hitting a CoW ENOMEM. I >> don't >>>> see how it would altogether avoid it. >>> >>> Agreed, so it doesn't really solve the problem. (See longer reply >>> to Tim.) >>> >>>> If the objective is trying to put a cap to the unpredictable growth of memory allocations via CoW >>>> unsharing, two observations: (1) will never grow past nominal VM footprint (2) One can put a cap >> today >>>> by tweaking d->max_pages -- CoW will fail, faulting vcpu will sleep, and things can be kicked back >>>> into action at a later point. >>> >>> But IIRC isn't it (2) that has given VMware memory overcommit a bad name? >>> Any significant memory pressure due to overcommit leads to double-swapping, >>> which leads to horrible performance? >> >> The little that I've been able to read from their published results is that a "lot" of CPU is consumed >> scanning memory and fingerprinting, which leads to a massive assault on micro-architectural caches. >> >> I don't know if that equates to a "bad name", but I don't think that is a productive discussion >> either. > > Sorry, I wasn't intending that to be snarky, but on re-read I guess it > did sound snarky. What I meant is: Is this just a manual version of what > VMware does automatically? Or is there something I am misunderstanding? > (I think you answered that below.) > >> (2) doesn't mean swapping. Note that d->max_pages can be set artificially low by an admin, raised >> again. etc. It's just a mechanism to keep a VM at bay while corrective measures of any kind are taken. >> It's really up to a higher level controller whether you accept allocations and later reach a point of >> thrashing. >> >> I understand this is partly where your discussion is headed, but certainly fixing the primary issue of >> nominal vanilla allocations preempting each other looks fairly critical to begin with. > > OK. I _think_ the design I proposed helps in systems that are using > page-sharing/host-swapping as well... I assume share-breaking just > calls the normal hypervisor allocator interface to allocate a > new page (if available)? If you could review and comment on > the design from a page-sharing/host-swapping perspective, I would > appreciate it. I think you will need to refine your notion of reservation. If you have nominal RAM N, and current RAM C, N >= C, it makes no sense to reserve N so the VM later has room to occupy by swapping-in, unsharing or whatever -- then you are not over-committing memory. To the extent that you want to facilitate VM creation, it does make sense to reserve C and guarantee that. Then it gets mm-specific. PoD has one way of dealing with the allocation growth. xenpaging tries to stick to the watermark -- if something swaps in something else swaps out. And uncooperative balloons are be stymied by xapi using d->max_pages. This is why I believe you need to solve the problem of initial reservation, and the problem of handing off to the right actor. And then xl need not care any further. Andres > > Thanks, > Dan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 17:31:14 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 17:31:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJpGG-0005yR-3R; Thu, 04 Oct 2012 17:31:00 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJpGE-0005yM-FB for xen-devel@lists.xen.org; Thu, 04 Oct 2012 17:30:58 +0000 Received: from [85.158.139.211:51273] by server-3.bemta-5.messagelabs.com id EB/DF-16108-1D7CD605; Thu, 04 Oct 2012 17:30:57 +0000 X-Env-Sender: andreslc@gridcentric.ca X-Msg-Ref: server-15.tower-206.messagelabs.com!1349371855!21155176!1 X-Originating-IP: [209.85.223.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6074 invoked from network); 4 Oct 2012 17:30:56 -0000 Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com) (209.85.223.173) by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 17:30:56 -0000 Received: by mail-ie0-f173.google.com with SMTP id 17so2009361iea.32 for ; Thu, 04 Oct 2012 10:30:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:x-priority:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=FCmU2EDum3rT8leMQp2t9waJycqqm7Ky6KUE83kLwLk=; b=jNxPZmHWyb16H+jP1rJNRRuIFSXsWUlkhrSdkuxOhBqWC5DzUOjIJvHsR6gcT5z4GG 47vQBblFEU9LOwOAza3SHgPhd/54CXLqIITj4TNLgkutJ6zVe9Fncn/o+4uEbqrcAHCN MNnkt9gPJUHk3tSFBQAhDwsaX0MoJzNW2WXZwy545F1zUoRMHW5msM3r0/dr2RgvMX+/ ngGhwg+wmdJdAtKX606ktzwDeM5vGzLKwkZeMvl5OBtM3juH6GBKzZVaornwmAf5z+KS 0ktpNBwazai/Q18nyck5Vdaqyc46LINXbBNu2npyS95W0JIEsqtlqr39BFdqXp4kbMIP HNBQ== Received: by 10.50.183.202 with SMTP id eo10mr6132274igc.38.1349371855104; Thu, 04 Oct 2012 10:30:55 -0700 (PDT) Received: from [192.168.3.238] ([206.223.182.18]) by mx.google.com with ESMTPS id 7sm15601161igh.0.2012.10.04.10.30.53 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Oct 2012 10:30:54 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) From: Andres Lagar-Cavilla X-Priority: 3 In-Reply-To: <16aa5326-5fd9-4f9c-b0fe-6196c6379991@default> Date: Thu, 4 Oct 2012 13:30:52 -0400 Message-Id: <1C4CD35F-94F0-44CF-97EA-137DF20E9669@gridcentric.ca> References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> <20121002091017.GA95926@ocelot.phlegethon.org> <66cc0085-1216-40f7-8059-eaf615202c12@default> <20121002201624.GA98445@ocelot.phlegethon.org> <20121004100645.GC38243@ocelot.phlegethon.org> <51CA094C-870A-4772-A22E-4CB151E854F2@gridcentric.ca> <48a08581-faa9-40a0-8afd-dc334ab82e43@default> <91C20B33-83CF-4B7A-A5AC-E61421B00536@gridcentric.ca> <16aa5326-5fd9-4f9c-b0fe-6196c6379991@default> To: Dan Magenheimer X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQn3qaN/yloLIJ/fN99cNVxrP2GGxRJaYj+db+QRMswR62TEinRqv3V+i/cOc85xzWJZYxOk Cc: Olaf Hering , Keir Fraser , Konrad Wilk , George Dunlap , Kurt Hackel , Tim Deegan , xen-devel@lists.xen.org, George Shuklin , Dario Faggioli , Ian Jackson Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Oct 4, 2012, at 1:18 PM, Dan Magenheimer wrote: >> From: Andres Lagar-Cavilla [mailto:andreslc@gridcentric.ca] >> Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) >> >> >> On Oct 4, 2012, at 12:59 PM, Dan Magenheimer wrote: >> >>>> From: Andres Lagar-Cavilla [mailto:andreslc@gridcentric.ca] >>>> Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) >>>> >>>> On Oct 4, 2012, at 6:06 AM, Tim Deegan wrote: >>>> >>>>> At 14:56 -0700 on 02 Oct (1349189817), Dan Magenheimer wrote: >>>>>> Tmem argues that doing "memory capacity transfers" at a page granularity >>>>>> can only be done efficiently in the hypervisor. This is true for >>>>>> page-sharing when it breaks a "share" also... it can't go ask the >>>>>> toolstack to approve allocation of a new page every time a write to a shared >>>>>> page occurs. >>>>>> >>>>>> Does that make sense? >>>>> >>>>> Yes. The page-sharing version can be handled by having a pool of >>>>> dedicated memory for breaking shares, and the toolstack asynchronously >>>>> replenish that, rather than allowing CoW to use up all memory in the >>>>> system. >>>> >>>> That is doable. One benefit is that it would minimize the chance of a VM hitting a CoW ENOMEM. I >> don't >>>> see how it would altogether avoid it. >>> >>> Agreed, so it doesn't really solve the problem. (See longer reply >>> to Tim.) >>> >>>> If the objective is trying to put a cap to the unpredictable growth of memory allocations via CoW >>>> unsharing, two observations: (1) will never grow past nominal VM footprint (2) One can put a cap >> today >>>> by tweaking d->max_pages -- CoW will fail, faulting vcpu will sleep, and things can be kicked back >>>> into action at a later point. >>> >>> But IIRC isn't it (2) that has given VMware memory overcommit a bad name? >>> Any significant memory pressure due to overcommit leads to double-swapping, >>> which leads to horrible performance? >> >> The little that I've been able to read from their published results is that a "lot" of CPU is consumed >> scanning memory and fingerprinting, which leads to a massive assault on micro-architectural caches. >> >> I don't know if that equates to a "bad name", but I don't think that is a productive discussion >> either. > > Sorry, I wasn't intending that to be snarky, but on re-read I guess it > did sound snarky. What I meant is: Is this just a manual version of what > VMware does automatically? Or is there something I am misunderstanding? > (I think you answered that below.) > >> (2) doesn't mean swapping. Note that d->max_pages can be set artificially low by an admin, raised >> again. etc. It's just a mechanism to keep a VM at bay while corrective measures of any kind are taken. >> It's really up to a higher level controller whether you accept allocations and later reach a point of >> thrashing. >> >> I understand this is partly where your discussion is headed, but certainly fixing the primary issue of >> nominal vanilla allocations preempting each other looks fairly critical to begin with. > > OK. I _think_ the design I proposed helps in systems that are using > page-sharing/host-swapping as well... I assume share-breaking just > calls the normal hypervisor allocator interface to allocate a > new page (if available)? If you could review and comment on > the design from a page-sharing/host-swapping perspective, I would > appreciate it. I think you will need to refine your notion of reservation. If you have nominal RAM N, and current RAM C, N >= C, it makes no sense to reserve N so the VM later has room to occupy by swapping-in, unsharing or whatever -- then you are not over-committing memory. To the extent that you want to facilitate VM creation, it does make sense to reserve C and guarantee that. Then it gets mm-specific. PoD has one way of dealing with the allocation growth. xenpaging tries to stick to the watermark -- if something swaps in something else swaps out. And uncooperative balloons are be stymied by xapi using d->max_pages. This is why I believe you need to solve the problem of initial reservation, and the problem of handing off to the right actor. And then xl need not care any further. Andres > > Thanks, > Dan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 17:31:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 17:31:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJpGh-000603-Gr; Thu, 04 Oct 2012 17:31:27 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJpGg-0005zm-Gs for xen-devel@lists.xen.org; Thu, 04 Oct 2012 17:31:26 +0000 Received: from [85.158.138.51:14975] by server-6.bemta-3.messagelabs.com id 09/4E-11085-CE7CD605; Thu, 04 Oct 2012 17:31:24 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1349371882!31448259!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16213 invoked from network); 4 Oct 2012 17:31:22 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 17:31:22 -0000 X-IronPort-AV: E=Sophos;i="4.80,537,1344211200"; d="scan'208";a="14947919" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 17:31:22 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 18:31:22 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TJpGb-000628-QD; Thu, 04 Oct 2012 17:31:21 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TJpGb-00089g-Kr; Thu, 04 Oct 2012 18:31:21 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20589.51177.530142.664975@mariner.uk.xensource.com> Date: Thu, 4 Oct 2012 18:31:21 +0100 To: Anthony PERARD In-Reply-To: <1349367522-16695-2-git-send-email-anthony.perard@citrix.com> References: <1349367522-16695-1-git-send-email-anthony.perard@citrix.com> <1349367522-16695-2-git-send-email-anthony.perard@citrix.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Ian Campbell , Xen Devel Subject: Re: [Xen-devel] [PATCH V2 1/2] libxl: Have flexarray using the GC X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Anthony PERARD writes ("[PATCH V2 1/2] libxl: Have flexarray using the GC"): > This patch makes the flexarray function libxl__gc aware. > +/* > + * It is safe to store gc in the struct because: > + * - If it an actual gc, then the flexarray should not be used after the gc > + * have been freed. > + * - If it is a NOGC, then this point to a structure embedded in libxl_ctx, > + * therefore will survive across several libxl calls. > + */ Thanks, I think this explanation is correct. > +static int gc_is_real(const libxl__gc *gc) > +{ > + return gc->alloc_maxsize >= 0; > +} You have cloned-and-hacked this from libxl_internal.c ! Instead, either declare it in libxl_internal.h, or move it there and make it "static inline". > @@ -104,7 +115,8 @@ void **flexarray_contents(flexarray_t *array) > { > void **data; > data = array->data; > - free(array); > + if (!gc_is_real(array->gc)) > + free(array); > return data; What an odd function. However, your patch to it seems right to me. > diff --git a/tools/libxl/flexarray.h b/tools/libxl/flexarray.h > index ae17f3b..aade417 100644 And the rest of the patch is mostly an impressive number of deletions. I won't check the semantics of each one but the style seems plausible. Thanks! Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 17:31:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 17:31:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJpGh-000603-Gr; Thu, 04 Oct 2012 17:31:27 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJpGg-0005zm-Gs for xen-devel@lists.xen.org; Thu, 04 Oct 2012 17:31:26 +0000 Received: from [85.158.138.51:14975] by server-6.bemta-3.messagelabs.com id 09/4E-11085-CE7CD605; Thu, 04 Oct 2012 17:31:24 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1349371882!31448259!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16213 invoked from network); 4 Oct 2012 17:31:22 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 17:31:22 -0000 X-IronPort-AV: E=Sophos;i="4.80,537,1344211200"; d="scan'208";a="14947919" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 17:31:22 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 18:31:22 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TJpGb-000628-QD; Thu, 04 Oct 2012 17:31:21 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TJpGb-00089g-Kr; Thu, 04 Oct 2012 18:31:21 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20589.51177.530142.664975@mariner.uk.xensource.com> Date: Thu, 4 Oct 2012 18:31:21 +0100 To: Anthony PERARD In-Reply-To: <1349367522-16695-2-git-send-email-anthony.perard@citrix.com> References: <1349367522-16695-1-git-send-email-anthony.perard@citrix.com> <1349367522-16695-2-git-send-email-anthony.perard@citrix.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Ian Campbell , Xen Devel Subject: Re: [Xen-devel] [PATCH V2 1/2] libxl: Have flexarray using the GC X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Anthony PERARD writes ("[PATCH V2 1/2] libxl: Have flexarray using the GC"): > This patch makes the flexarray function libxl__gc aware. > +/* > + * It is safe to store gc in the struct because: > + * - If it an actual gc, then the flexarray should not be used after the gc > + * have been freed. > + * - If it is a NOGC, then this point to a structure embedded in libxl_ctx, > + * therefore will survive across several libxl calls. > + */ Thanks, I think this explanation is correct. > +static int gc_is_real(const libxl__gc *gc) > +{ > + return gc->alloc_maxsize >= 0; > +} You have cloned-and-hacked this from libxl_internal.c ! Instead, either declare it in libxl_internal.h, or move it there and make it "static inline". > @@ -104,7 +115,8 @@ void **flexarray_contents(flexarray_t *array) > { > void **data; > data = array->data; > - free(array); > + if (!gc_is_real(array->gc)) > + free(array); > return data; What an odd function. However, your patch to it seems right to me. > diff --git a/tools/libxl/flexarray.h b/tools/libxl/flexarray.h > index ae17f3b..aade417 100644 And the rest of the patch is mostly an impressive number of deletions. I won't check the semantics of each one but the style seems plausible. Thanks! Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 17:32:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 17:32:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJpHg-00067S-VU; Thu, 04 Oct 2012 17:32:28 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJpHf-00067F-Rs for xen-devel@lists.xen.org; Thu, 04 Oct 2012 17:32:28 +0000 Received: from [85.158.143.99:57780] by server-3.bemta-4.messagelabs.com id 7A/EE-10986-B28CD605; Thu, 04 Oct 2012 17:32:27 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1349371946!26641509!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13866 invoked from network); 4 Oct 2012 17:32:26 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 17:32:26 -0000 X-IronPort-AV: E=Sophos;i="4.80,537,1344211200"; d="scan'208";a="14947932" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 17:32:09 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 18:32:09 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TJpHM-00062P-Tp; Thu, 04 Oct 2012 17:32:08 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TJpHM-00089o-QX; Thu, 04 Oct 2012 18:32:08 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20589.51224.562593.761653@mariner.uk.xensource.com> Date: Thu, 4 Oct 2012 18:32:08 +0100 To: Anthony PERARD In-Reply-To: <1349367522-16695-3-git-send-email-anthony.perard@citrix.com> References: <1349367522-16695-1-git-send-email-anthony.perard@citrix.com> <1349367522-16695-3-git-send-email-anthony.perard@citrix.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Ian Campbell , Xen Devel Subject: Re: [Xen-devel] [PATCH V2 2/2] libxl_json: Use libxl alloc function. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Anthony PERARD writes ("[PATCH V2 2/2] libxl_json: Use libxl alloc function."): > This patch makes use of the libxl allocation API and the GC and removes the > check for allocation failure. I haven't checked this line-by-line but it looks plausible. Acked-by: Ian Jackson Thanks, Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 17:32:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 17:32:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJpHg-00067S-VU; Thu, 04 Oct 2012 17:32:28 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJpHf-00067F-Rs for xen-devel@lists.xen.org; Thu, 04 Oct 2012 17:32:28 +0000 Received: from [85.158.143.99:57780] by server-3.bemta-4.messagelabs.com id 7A/EE-10986-B28CD605; Thu, 04 Oct 2012 17:32:27 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1349371946!26641509!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13866 invoked from network); 4 Oct 2012 17:32:26 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 17:32:26 -0000 X-IronPort-AV: E=Sophos;i="4.80,537,1344211200"; d="scan'208";a="14947932" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 17:32:09 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 18:32:09 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TJpHM-00062P-Tp; Thu, 04 Oct 2012 17:32:08 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TJpHM-00089o-QX; Thu, 04 Oct 2012 18:32:08 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20589.51224.562593.761653@mariner.uk.xensource.com> Date: Thu, 4 Oct 2012 18:32:08 +0100 To: Anthony PERARD In-Reply-To: <1349367522-16695-3-git-send-email-anthony.perard@citrix.com> References: <1349367522-16695-1-git-send-email-anthony.perard@citrix.com> <1349367522-16695-3-git-send-email-anthony.perard@citrix.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Ian Campbell , Xen Devel Subject: Re: [Xen-devel] [PATCH V2 2/2] libxl_json: Use libxl alloc function. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Anthony PERARD writes ("[PATCH V2 2/2] libxl_json: Use libxl alloc function."): > This patch makes use of the libxl allocation API and the GC and removes the > check for allocation failure. I haven't checked this line-by-line but it looks plausible. Acked-by: Ian Jackson Thanks, Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 17:56:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 17:56:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJpeB-0006YD-2M; Thu, 04 Oct 2012 17:55:43 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJpe9-0006Y8-OM for xen-devel@lists.xen.org; Thu, 04 Oct 2012 17:55:41 +0000 X-Env-Sender: dan.magenheimer@oracle.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1349373333!7940256!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzgzMjE1\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23458 invoked from network); 4 Oct 2012 17:55:35 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Oct 2012 17:55:35 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q94HtLSe012119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Oct 2012 17:55:22 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q94HtKpS006724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Oct 2012 17:55:21 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q94HtKn0019473; Thu, 4 Oct 2012 12:55:20 -0500 MIME-Version: 1.0 Message-ID: <52e8fc33-59b3-4d28-82a7-b648e3e28cf5@default> Date: Thu, 4 Oct 2012 10:55:13 -0700 (PDT) From: Dan Magenheimer To: Andres Lagar-Cavilla References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> <20121002091017.GA95926@ocelot.phlegethon.org> <66cc0085-1216-40f7-8059-eaf615202c12@default> <20121002201624.GA98445@ocelot.phlegethon.org> <20121004100645.GC38243@ocelot.phlegethon.org> <51CA094C-870A-4772-A22E-4CB151E854F2@gridcentric.ca> <48a08581-faa9-40a0-8afd-dc334ab82e43@default> <91C20B33-83CF-4B7A-A5AC-E61421B00536@gridcentric.ca> <16aa5326-5fd9-4f9c-b0fe-6196c6379991@default> <1C4CD35F-94F0-44CF-97EA-137DF20E9669@gridcentric.ca> In-Reply-To: <1C4CD35F-94F0-44CF-97EA-137DF20E9669@gridcentric.ca> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7 (607090) [OL 12.0.6661.5003 (x86)] X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: Olaf Hering , Keir Fraser , Konrad Wilk , George Dunlap , Kurt Hackel , Tim Deegan , xen-devel@lists.xen.org, George Shuklin , Dario Faggioli , Ian Jackson Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > From: Andres Lagar-Cavilla [mailto:andreslc@gridcentric.ca] > Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) > > > On Oct 4, 2012, at 1:18 PM, Dan Magenheimer wrote: > > >> From: Andres Lagar-Cavilla [mailto:andreslc@gridcentric.ca] > >> Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) > >> > >> > >> On Oct 4, 2012, at 12:59 PM, Dan Magenheimer wrote: > >> > > OK. I _think_ the design I proposed helps in systems that are using > > page-sharing/host-swapping as well... I assume share-breaking just > > calls the normal hypervisor allocator interface to allocate a > > new page (if available)? If you could review and comment on > > the design from a page-sharing/host-swapping perspective, I would > > appreciate it. > > I think you will need to refine your notion of reservation. If you have nominal RAM N, and current RAM > C, N >= C, it makes no sense to reserve N so the VM later has room to occupy by swapping-in, unsharing > or whatever -- then you are not over-committing memory. > > To the extent that you want to facilitate VM creation, it does make sense to reserve C and guarantee > that. > > Then it gets mm-specific. PoD has one way of dealing with the allocation growth. xenpaging tries to > stick to the watermark -- if something swaps in something else swaps out. And uncooperative balloons > are be stymied by xapi using d->max_pages. > > This is why I believe you need to solve the problem of initial reservation, and the problem of handing > off to the right actor. And then xl need not care any further. > > Andres I think we may be saying the same thing, at least in the context of the issue I am trying to solve (which, admittedly, may be a smaller part of a bigger issue, and we should attempt to ensure that the solution to the smaller part is at least a step in the right direction for the bigger issue). And I am trying to solve the mechanism problem only, not the policy which, I agree is mm-specific. The core problem, as I see it, is that there are multiple consumers of memory, some of which may be visible to xl and some of which are not. Ultimately, the hypervisor is asked to provide memory and will return failure if it can't, so the hypervisor is the final arbiter. When a domain is created, we'd like to ensure there is enough memory for it to "not fail". But when the toolstack asks for memory to create a domain, it asks for it "piecemeal". I'll assume that the toolstack knows how much memory it needs to allocate to ensure the launch doesn't fail... my solution is that it asks for that entire amount of memory at once as a "reservation". If the hypervisor has that much memory available, it returns success and must behave as if the memory has been already allocated. Then, later, when the toolstack is happy that the domain did successfully launch, it says "remember that reservation? any memory reserved that has not yet been allocated, need no longer be reserved, you can unreserve it" In other words, between reservation and unreserve, there is no memory overcommit for that domain. Once the toolstack does the unreserve, its memory is available for overcommit mechanisms. Not sure if that part was clear: it's my intent that unreserve occur soon after the domain is launched, _not_, for example, when the domain is shut down. What I don't know is if there is a suitable point in the launch when the toolstack knows it can do the "release"... that may be the sticking point and may be mm-specific. Thanks, Dan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 17:56:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 17:56:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJpeB-0006YD-2M; Thu, 04 Oct 2012 17:55:43 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJpe9-0006Y8-OM for xen-devel@lists.xen.org; Thu, 04 Oct 2012 17:55:41 +0000 X-Env-Sender: dan.magenheimer@oracle.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1349373333!7940256!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzgzMjE1\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23458 invoked from network); 4 Oct 2012 17:55:35 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Oct 2012 17:55:35 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q94HtLSe012119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Oct 2012 17:55:22 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q94HtKpS006724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Oct 2012 17:55:21 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q94HtKn0019473; Thu, 4 Oct 2012 12:55:20 -0500 MIME-Version: 1.0 Message-ID: <52e8fc33-59b3-4d28-82a7-b648e3e28cf5@default> Date: Thu, 4 Oct 2012 10:55:13 -0700 (PDT) From: Dan Magenheimer To: Andres Lagar-Cavilla References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> <20121002091017.GA95926@ocelot.phlegethon.org> <66cc0085-1216-40f7-8059-eaf615202c12@default> <20121002201624.GA98445@ocelot.phlegethon.org> <20121004100645.GC38243@ocelot.phlegethon.org> <51CA094C-870A-4772-A22E-4CB151E854F2@gridcentric.ca> <48a08581-faa9-40a0-8afd-dc334ab82e43@default> <91C20B33-83CF-4B7A-A5AC-E61421B00536@gridcentric.ca> <16aa5326-5fd9-4f9c-b0fe-6196c6379991@default> <1C4CD35F-94F0-44CF-97EA-137DF20E9669@gridcentric.ca> In-Reply-To: <1C4CD35F-94F0-44CF-97EA-137DF20E9669@gridcentric.ca> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7 (607090) [OL 12.0.6661.5003 (x86)] X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: Olaf Hering , Keir Fraser , Konrad Wilk , George Dunlap , Kurt Hackel , Tim Deegan , xen-devel@lists.xen.org, George Shuklin , Dario Faggioli , Ian Jackson Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > From: Andres Lagar-Cavilla [mailto:andreslc@gridcentric.ca] > Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) > > > On Oct 4, 2012, at 1:18 PM, Dan Magenheimer wrote: > > >> From: Andres Lagar-Cavilla [mailto:andreslc@gridcentric.ca] > >> Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) > >> > >> > >> On Oct 4, 2012, at 12:59 PM, Dan Magenheimer wrote: > >> > > OK. I _think_ the design I proposed helps in systems that are using > > page-sharing/host-swapping as well... I assume share-breaking just > > calls the normal hypervisor allocator interface to allocate a > > new page (if available)? If you could review and comment on > > the design from a page-sharing/host-swapping perspective, I would > > appreciate it. > > I think you will need to refine your notion of reservation. If you have nominal RAM N, and current RAM > C, N >= C, it makes no sense to reserve N so the VM later has room to occupy by swapping-in, unsharing > or whatever -- then you are not over-committing memory. > > To the extent that you want to facilitate VM creation, it does make sense to reserve C and guarantee > that. > > Then it gets mm-specific. PoD has one way of dealing with the allocation growth. xenpaging tries to > stick to the watermark -- if something swaps in something else swaps out. And uncooperative balloons > are be stymied by xapi using d->max_pages. > > This is why I believe you need to solve the problem of initial reservation, and the problem of handing > off to the right actor. And then xl need not care any further. > > Andres I think we may be saying the same thing, at least in the context of the issue I am trying to solve (which, admittedly, may be a smaller part of a bigger issue, and we should attempt to ensure that the solution to the smaller part is at least a step in the right direction for the bigger issue). And I am trying to solve the mechanism problem only, not the policy which, I agree is mm-specific. The core problem, as I see it, is that there are multiple consumers of memory, some of which may be visible to xl and some of which are not. Ultimately, the hypervisor is asked to provide memory and will return failure if it can't, so the hypervisor is the final arbiter. When a domain is created, we'd like to ensure there is enough memory for it to "not fail". But when the toolstack asks for memory to create a domain, it asks for it "piecemeal". I'll assume that the toolstack knows how much memory it needs to allocate to ensure the launch doesn't fail... my solution is that it asks for that entire amount of memory at once as a "reservation". If the hypervisor has that much memory available, it returns success and must behave as if the memory has been already allocated. Then, later, when the toolstack is happy that the domain did successfully launch, it says "remember that reservation? any memory reserved that has not yet been allocated, need no longer be reserved, you can unreserve it" In other words, between reservation and unreserve, there is no memory overcommit for that domain. Once the toolstack does the unreserve, its memory is available for overcommit mechanisms. Not sure if that part was clear: it's my intent that unreserve occur soon after the domain is launched, _not_, for example, when the domain is shut down. What I don't know is if there is a suitable point in the launch when the toolstack knows it can do the "release"... that may be the sticking point and may be mm-specific. Thanks, Dan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 18:08:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 18:08:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJpqN-0006u6-G2; Thu, 04 Oct 2012 18:08:19 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJpqL-0006u1-TW for Xen-devel@lists.xen.org; Thu, 04 Oct 2012 18:08:18 +0000 Received: from [85.158.143.99:31411] by server-2.bemta-4.messagelabs.com id AC/B5-06610-190DD605; Thu, 04 Oct 2012 18:08:17 +0000 X-Env-Sender: xinxinjin89@gmail.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1349374095!32559227!1 X-Originating-IP: [209.85.216.173] X-SpamReason: No, hits=0.7 required=7.0 tests=HTML_30_40,HTML_MESSAGE, MAILTO_TO_SPAM_ADDR,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16894 invoked from network); 4 Oct 2012 18:08:16 -0000 Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com) (209.85.216.173) by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 18:08:16 -0000 Received: by mail-qc0-f173.google.com with SMTP id b12so797632qca.32 for ; Thu, 04 Oct 2012 11:08:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=O/rTI0vI5zE6hmpsN7pW8HEDUPb9wgAUpLaDphq+aHo=; b=eYSwK9w9P27uozswsw4iGZ77zGDrhv43wK8bPhUY55HzA7vuBsYejYHMsxbMqEmFoN /CXewmOjZtr5JdEiXDbTZliGdOArumfZ6lQodAtLN9zjVSqYgcYpkig6MyAtZwCKZdm5 RwjS8UqoeB2z1EmzQS99kzUImz8Sbu/s1WyDxBhSqHy/ThfLHYZO+PtrnNwLUcKLKSOp IeHq4zamWAm2sEgb8BH6UIQsnTIZuz+M2pPVINEQptSO7h4hq6acv+iNBcscEae8+/1W VBG4Tw2+OTh1iCo06BEf8GXILSJ4vvEQIhLNoSAu6wCEEtITab65yN6yGxP4lpke+8al GTew== MIME-Version: 1.0 Received: by 10.224.58.134 with SMTP id g6mr13680965qah.40.1349374095004; Thu, 04 Oct 2012 11:08:15 -0700 (PDT) Received: by 10.229.176.85 with HTTP; Thu, 4 Oct 2012 11:08:14 -0700 (PDT) In-Reply-To: <506D5BA8020000780009F8C6@nat28.tlf.novell.com> References: <506D5BA8020000780009F8C6@nat28.tlf.novell.com> Date: Thu, 4 Oct 2012 11:08:14 -0700 Message-ID: From: Xinxin Jin To: Jan Beulich Cc: Xen-devel@lists.xen.org Subject: Re: [Xen-devel] How does Xen implement writable page table ? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3942344714911884895==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============3942344714911884895== Content-Type: multipart/alternative; boundary=20cf306f74729a149304cb3fa31d --20cf306f74729a149304cb3fa31d Content-Type: text/plain; charset=ISO-8859-1 Thanks, Jan! On Thu, Oct 4, 2012 at 12:49 AM, Jan Beulich wrote: > >>> On 03.10.12 at 22:28, Xinxin Jin wrote: > > Hi everyone, > > If I follow the source code correctly, fixup_page_fault() -> > > ptwr_do_page_fault handles the write attempts to a page table. In my > > understanding, guests update page table through two ways: > > 1) Issue hypercall update_va_mapping to update PDT; > > 2) Modify writable bottom-level ptes and then trap to Xen's > > ptwr_do_page_fualt > > Here is my confusion: Why Xen supports two page table updating > mechanisms? > > This allows balancing between the amount of changes in the guest > side code - basic functionality would only require higher level page > table updates to a para-virtualized, while performance considerations > would call for all of the updates to avoid emulation. > > (You also didn't mention the third method through the > mmu_update hypercall.) > > > Why cannot apply writable page table to PDT entries? > > It would at least be troublesome in the hypervisor. > > Jan > > -- Xinxin --20cf306f74729a149304cb3fa31d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks, Jan!

On Thu, Oct 4, 2012 at 12:49= AM, Jan Beulich <JBeulich@suse.com> wrote:
>>> On 03.10.12 at 22:28, Xinxin Jin <xinxinjin89@gmail.com> wrote:
> Hi everyone,
> If I follow the source code correctly, =A0fixup_page_fault() ->
> ptwr_do_page_fault handles the write attempts to a page table. In my > understanding, guests update page table through two ways:
> 1) Issue hypercall update_va_mapping to update PDT;
> 2) Modify writable bottom-level ptes and then trap to Xen's
> ptwr_do_page_fualt
> Here is my confusion: Why Xen supports two page table updating mechani= sms?

This allows balancing between the amount of changes in the guest
side code - basic functionality would only require higher level page
table updates to a para-virtualized, while performance considerations
would call for all of the updates to avoid emulation.

(You also didn't mention the third method through the
mmu_update hypercall.)

> =A0Why cannot apply writable page table to PDT entries?

It would at least be troublesome in the hypervisor.

Jan




-- Xinxin
--20cf306f74729a149304cb3fa31d-- --===============3942344714911884895== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============3942344714911884895==-- From xen-devel-bounces@lists.xen.org Thu Oct 04 18:08:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 18:08:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJpqN-0006u6-G2; Thu, 04 Oct 2012 18:08:19 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJpqL-0006u1-TW for Xen-devel@lists.xen.org; Thu, 04 Oct 2012 18:08:18 +0000 Received: from [85.158.143.99:31411] by server-2.bemta-4.messagelabs.com id AC/B5-06610-190DD605; Thu, 04 Oct 2012 18:08:17 +0000 X-Env-Sender: xinxinjin89@gmail.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1349374095!32559227!1 X-Originating-IP: [209.85.216.173] X-SpamReason: No, hits=0.7 required=7.0 tests=HTML_30_40,HTML_MESSAGE, MAILTO_TO_SPAM_ADDR,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16894 invoked from network); 4 Oct 2012 18:08:16 -0000 Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com) (209.85.216.173) by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 18:08:16 -0000 Received: by mail-qc0-f173.google.com with SMTP id b12so797632qca.32 for ; Thu, 04 Oct 2012 11:08:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=O/rTI0vI5zE6hmpsN7pW8HEDUPb9wgAUpLaDphq+aHo=; b=eYSwK9w9P27uozswsw4iGZ77zGDrhv43wK8bPhUY55HzA7vuBsYejYHMsxbMqEmFoN /CXewmOjZtr5JdEiXDbTZliGdOArumfZ6lQodAtLN9zjVSqYgcYpkig6MyAtZwCKZdm5 RwjS8UqoeB2z1EmzQS99kzUImz8Sbu/s1WyDxBhSqHy/ThfLHYZO+PtrnNwLUcKLKSOp IeHq4zamWAm2sEgb8BH6UIQsnTIZuz+M2pPVINEQptSO7h4hq6acv+iNBcscEae8+/1W VBG4Tw2+OTh1iCo06BEf8GXILSJ4vvEQIhLNoSAu6wCEEtITab65yN6yGxP4lpke+8al GTew== MIME-Version: 1.0 Received: by 10.224.58.134 with SMTP id g6mr13680965qah.40.1349374095004; Thu, 04 Oct 2012 11:08:15 -0700 (PDT) Received: by 10.229.176.85 with HTTP; Thu, 4 Oct 2012 11:08:14 -0700 (PDT) In-Reply-To: <506D5BA8020000780009F8C6@nat28.tlf.novell.com> References: <506D5BA8020000780009F8C6@nat28.tlf.novell.com> Date: Thu, 4 Oct 2012 11:08:14 -0700 Message-ID: From: Xinxin Jin To: Jan Beulich Cc: Xen-devel@lists.xen.org Subject: Re: [Xen-devel] How does Xen implement writable page table ? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3942344714911884895==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============3942344714911884895== Content-Type: multipart/alternative; boundary=20cf306f74729a149304cb3fa31d --20cf306f74729a149304cb3fa31d Content-Type: text/plain; charset=ISO-8859-1 Thanks, Jan! On Thu, Oct 4, 2012 at 12:49 AM, Jan Beulich wrote: > >>> On 03.10.12 at 22:28, Xinxin Jin wrote: > > Hi everyone, > > If I follow the source code correctly, fixup_page_fault() -> > > ptwr_do_page_fault handles the write attempts to a page table. In my > > understanding, guests update page table through two ways: > > 1) Issue hypercall update_va_mapping to update PDT; > > 2) Modify writable bottom-level ptes and then trap to Xen's > > ptwr_do_page_fualt > > Here is my confusion: Why Xen supports two page table updating > mechanisms? > > This allows balancing between the amount of changes in the guest > side code - basic functionality would only require higher level page > table updates to a para-virtualized, while performance considerations > would call for all of the updates to avoid emulation. > > (You also didn't mention the third method through the > mmu_update hypercall.) > > > Why cannot apply writable page table to PDT entries? > > It would at least be troublesome in the hypervisor. > > Jan > > -- Xinxin --20cf306f74729a149304cb3fa31d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks, Jan!

On Thu, Oct 4, 2012 at 12:49= AM, Jan Beulich <JBeulich@suse.com> wrote:
>>> On 03.10.12 at 22:28, Xinxin Jin <xinxinjin89@gmail.com> wrote:
> Hi everyone,
> If I follow the source code correctly, =A0fixup_page_fault() ->
> ptwr_do_page_fault handles the write attempts to a page table. In my > understanding, guests update page table through two ways:
> 1) Issue hypercall update_va_mapping to update PDT;
> 2) Modify writable bottom-level ptes and then trap to Xen's
> ptwr_do_page_fualt
> Here is my confusion: Why Xen supports two page table updating mechani= sms?

This allows balancing between the amount of changes in the guest
side code - basic functionality would only require higher level page
table updates to a para-virtualized, while performance considerations
would call for all of the updates to avoid emulation.

(You also didn't mention the third method through the
mmu_update hypercall.)

> =A0Why cannot apply writable page table to PDT entries?

It would at least be troublesome in the hypervisor.

Jan




-- Xinxin
--20cf306f74729a149304cb3fa31d-- --===============3942344714911884895== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============3942344714911884895==-- From xen-devel-bounces@lists.xen.org Thu Oct 04 18:21:22 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 18:21:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJq2g-0007EO-Gk; Thu, 04 Oct 2012 18:21:02 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJq2e-0007ED-E7 for Xen-devel@lists.xensource.com; Thu, 04 Oct 2012 18:21:00 +0000 Received: from [85.158.139.83:18031] by server-16.bemta-5.messagelabs.com id 5C/AD-21637-B83DD605; Thu, 04 Oct 2012 18:20:59 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1349374857!33444710!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc5MzIzNg==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6964 invoked from network); 4 Oct 2012 18:20:59 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Oct 2012 18:20:59 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q94IKp2w012172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Oct 2012 18:20:52 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q94IKoiD016428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Oct 2012 18:20:51 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q94IKowd032616; Thu, 4 Oct 2012 13:20:50 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 04 Oct 2012 11:20:50 -0700 Date: Thu, 4 Oct 2012 11:20:48 -0700 From: Mukesh Rathor To: Ian Campbell Message-ID: <20121004112048.53767720@mantra.us.oracle.com> In-Reply-To: <1349340642.650.227.camel@zakaz.uk.xensource.com> References: <20120921122123.33489ce1@mantra.us.oracle.com> <1349270495.650.144.camel@zakaz.uk.xensource.com> <20121003153106.65237f07@mantra.us.oracle.com> <1349340642.650.227.camel@zakaz.uk.xensource.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 7/8]: PVH privcmd changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 4 Oct 2012 09:50:42 +0100 Ian Campbell wrote: > On Wed, 2012-10-03 at 23:31 +0100, Mukesh Rathor wrote: > > On Wed, 3 Oct 2012 14:21:35 +0100 > > Ian Campbell wrote: > > > > > On Fri, 2012-09-21 at 20:21 +0100, Mukesh Rathor wrote: > > > > +static int pvh_privcmd_resv_pfns(struct vm_area_struct *vma, > > > > int numpgs) > > > ... > > > > + pvhp->pi_num_pgs = numpgs; > > > > + BUG_ON(vma->vm_private_data != (void *)1); > > > > + vma->vm_private_data = pvhp; > > > > > > How does this interact with: > > > > > > static int privcmd_enforce_singleshot_mapping(struct > > > vm_area_struct *vma) { > > > return (xchg(&vma->vm_private_data, (void *)1) == NULL); > > > } > > > > > > If someone tries to map a second time then won't this correct the > > > pvhp in vm_private_data by resetting it to 1? Then when the > > > original mapping is torn down things all fall apart? > > > > > > Perhaps we need a cmpxchg here? Or to rework the callers a little > > > bit perhaps. > > > > Right, that's why I had it originally checking for auto xlated and > > doing something different. I think that is better than to change > > this and change again. I'll change it back to just putting the ptr > > here. > > Won't that break because on the second call you will pass in the > freshly allocated pointer and overwrite the exiting (useful) one with > it? No, for xlate, I just check for NULL. I didn't think it was big deal to special case xlate in this case. We got so many if xlate cases already thru the code. It leaves the semantics easy to understand: NULL == avail. 1 == locked PV. PTR == Locked PVH. I'll add a comment this time :). thanks, Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 18:21:22 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 18:21:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJq2g-0007EO-Gk; Thu, 04 Oct 2012 18:21:02 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJq2e-0007ED-E7 for Xen-devel@lists.xensource.com; Thu, 04 Oct 2012 18:21:00 +0000 Received: from [85.158.139.83:18031] by server-16.bemta-5.messagelabs.com id 5C/AD-21637-B83DD605; Thu, 04 Oct 2012 18:20:59 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1349374857!33444710!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc5MzIzNg==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6964 invoked from network); 4 Oct 2012 18:20:59 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Oct 2012 18:20:59 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q94IKp2w012172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Oct 2012 18:20:52 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q94IKoiD016428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Oct 2012 18:20:51 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q94IKowd032616; Thu, 4 Oct 2012 13:20:50 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 04 Oct 2012 11:20:50 -0700 Date: Thu, 4 Oct 2012 11:20:48 -0700 From: Mukesh Rathor To: Ian Campbell Message-ID: <20121004112048.53767720@mantra.us.oracle.com> In-Reply-To: <1349340642.650.227.camel@zakaz.uk.xensource.com> References: <20120921122123.33489ce1@mantra.us.oracle.com> <1349270495.650.144.camel@zakaz.uk.xensource.com> <20121003153106.65237f07@mantra.us.oracle.com> <1349340642.650.227.camel@zakaz.uk.xensource.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 7/8]: PVH privcmd changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 4 Oct 2012 09:50:42 +0100 Ian Campbell wrote: > On Wed, 2012-10-03 at 23:31 +0100, Mukesh Rathor wrote: > > On Wed, 3 Oct 2012 14:21:35 +0100 > > Ian Campbell wrote: > > > > > On Fri, 2012-09-21 at 20:21 +0100, Mukesh Rathor wrote: > > > > +static int pvh_privcmd_resv_pfns(struct vm_area_struct *vma, > > > > int numpgs) > > > ... > > > > + pvhp->pi_num_pgs = numpgs; > > > > + BUG_ON(vma->vm_private_data != (void *)1); > > > > + vma->vm_private_data = pvhp; > > > > > > How does this interact with: > > > > > > static int privcmd_enforce_singleshot_mapping(struct > > > vm_area_struct *vma) { > > > return (xchg(&vma->vm_private_data, (void *)1) == NULL); > > > } > > > > > > If someone tries to map a second time then won't this correct the > > > pvhp in vm_private_data by resetting it to 1? Then when the > > > original mapping is torn down things all fall apart? > > > > > > Perhaps we need a cmpxchg here? Or to rework the callers a little > > > bit perhaps. > > > > Right, that's why I had it originally checking for auto xlated and > > doing something different. I think that is better than to change > > this and change again. I'll change it back to just putting the ptr > > here. > > Won't that break because on the second call you will pass in the > freshly allocated pointer and overwrite the exiting (useful) one with > it? No, for xlate, I just check for NULL. I didn't think it was big deal to special case xlate in this case. We got so many if xlate cases already thru the code. It leaves the semantics easy to understand: NULL == avail. 1 == locked PV. PTR == Locked PVH. I'll add a comment this time :). thanks, Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 18:23:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 18:23:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJq58-0007NF-29; Thu, 04 Oct 2012 18:23:34 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJq57-0007NA-6K for Xen-devel@lists.xensource.com; Thu, 04 Oct 2012 18:23:33 +0000 Received: from [85.158.138.51:62983] by server-1.bemta-3.messagelabs.com id 64/FE-16425-424DD605; Thu, 04 Oct 2012 18:23:32 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1349375010!33122206!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzgzMjE1\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25280 invoked from network); 4 Oct 2012 18:23:31 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Oct 2012 18:23:31 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q94INPi5010194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Oct 2012 18:23:26 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q94INOuo020538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Oct 2012 18:23:25 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q94INOXv004966; Thu, 4 Oct 2012 13:23:24 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 04 Oct 2012 11:23:24 -0700 Date: Thu, 4 Oct 2012 11:23:23 -0700 From: Mukesh Rathor To: Ian Campbell Message-ID: <20121004112323.611c7fdc@mantra.us.oracle.com> In-Reply-To: <1349338526.650.204.camel@zakaz.uk.xensource.com> References: <20120921121202.3163c379@mantra.us.oracle.com> <1348581263.11229.21.camel@zakaz.uk.xensource.com> <20121001142826.1ebf7b0f@mantra.us.oracle.com> <1349170528.650.18.camel@zakaz.uk.xensource.com> <20121003121122.0f20d5ed@mantra.us.oracle.com> <20121003203956.GA7526@phenom.dumpdata.com> <1349338526.650.204.camel@zakaz.uk.xensource.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 0/8]: PVH (PV guest with extensions) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 4 Oct 2012 09:15:26 +0100 Ian Campbell wrote: > On Wed, 2012-10-03 at 21:39 +0100, Konrad Rzeszutek Wilk wrote: > > > You Ok with XEN_ELFNOTE_GUEST_PVH, or should I call it > > > XEN_ELFNOTE_PV_EXTENSIONS. Please LMK. > > > > XEN_ELFNOTE_PVH_FEATURES ? > > > > That way you can fill it with different 'features' flags > > if need to. Say 1<<1 is basic, etc. > > I don't think we need a PVH specific ELF note which just replicates > the XENFEAT infrastructure at this stage, if we do come to that then > it would be better to give PVH its own leaf in the existing feature > space (e.g. starting at 1*32+0). > > Ian. Got it, thanks for the nice detailed note. I'll change it as above. Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 18:23:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 18:23:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJq58-0007NF-29; Thu, 04 Oct 2012 18:23:34 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJq57-0007NA-6K for Xen-devel@lists.xensource.com; Thu, 04 Oct 2012 18:23:33 +0000 Received: from [85.158.138.51:62983] by server-1.bemta-3.messagelabs.com id 64/FE-16425-424DD605; Thu, 04 Oct 2012 18:23:32 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1349375010!33122206!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzgzMjE1\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25280 invoked from network); 4 Oct 2012 18:23:31 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Oct 2012 18:23:31 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q94INPi5010194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Oct 2012 18:23:26 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q94INOuo020538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Oct 2012 18:23:25 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q94INOXv004966; Thu, 4 Oct 2012 13:23:24 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 04 Oct 2012 11:23:24 -0700 Date: Thu, 4 Oct 2012 11:23:23 -0700 From: Mukesh Rathor To: Ian Campbell Message-ID: <20121004112323.611c7fdc@mantra.us.oracle.com> In-Reply-To: <1349338526.650.204.camel@zakaz.uk.xensource.com> References: <20120921121202.3163c379@mantra.us.oracle.com> <1348581263.11229.21.camel@zakaz.uk.xensource.com> <20121001142826.1ebf7b0f@mantra.us.oracle.com> <1349170528.650.18.camel@zakaz.uk.xensource.com> <20121003121122.0f20d5ed@mantra.us.oracle.com> <20121003203956.GA7526@phenom.dumpdata.com> <1349338526.650.204.camel@zakaz.uk.xensource.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 0/8]: PVH (PV guest with extensions) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 4 Oct 2012 09:15:26 +0100 Ian Campbell wrote: > On Wed, 2012-10-03 at 21:39 +0100, Konrad Rzeszutek Wilk wrote: > > > You Ok with XEN_ELFNOTE_GUEST_PVH, or should I call it > > > XEN_ELFNOTE_PV_EXTENSIONS. Please LMK. > > > > XEN_ELFNOTE_PVH_FEATURES ? > > > > That way you can fill it with different 'features' flags > > if need to. Say 1<<1 is basic, etc. > > I don't think we need a PVH specific ELF note which just replicates > the XENFEAT infrastructure at this stage, if we do come to that then > it would be better to give PVH its own leaf in the existing feature > space (e.g. starting at 1*32+0). > > Ian. Got it, thanks for the nice detailed note. I'll change it as above. Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 18:26:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 18:26:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJq7u-0007YH-Kq; Thu, 04 Oct 2012 18:26:26 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJq7t-0007Y8-9z for xen-devel@lists.xen.org; Thu, 04 Oct 2012 18:26:25 +0000 Received: from [85.158.143.99:27578] by server-2.bemta-4.messagelabs.com id C2/E1-06610-0D4DD605; Thu, 04 Oct 2012 18:26:24 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-7.tower-216.messagelabs.com!1349375183!26782201!1 X-Originating-IP: [81.169.146.160] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MzM0NzY=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MzM0NzY=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18230 invoked from network); 4 Oct 2012 18:26:24 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160) by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Oct 2012 18:26:24 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll3c7ofw== X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-084-057-084-003.pools.arcor-ip.net [84.57.84.3]) by smtp.strato.de (jored mo5) (RZmta 30.20 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id Y063ebo94GcWND ; Thu, 4 Oct 2012 20:26:14 +0200 (CEST) Received: by probook.site (Postfix, from userid 1000) id B82121863E; Thu, 4 Oct 2012 20:26:13 +0200 (CEST) Date: Thu, 4 Oct 2012 20:26:13 +0200 From: Olaf Hering To: Dan Magenheimer Message-ID: <20121004182613.GA9244@aepfle.de> References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> User-Agent: Mutt/1.5.21.rev5555 (2012-07-20) Cc: Keir Fraser , Konrad Wilk , George Dunlap , Kurt Hackel , tim@xen.org, xen-devel@lists.xen.org, George Shuklin , Dario Faggioli , Andres Lagar-Cavilla , Ian Jackson Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, Oct 01, Dan Magenheimer wrote: > > From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com] > > Sent: Friday, September 28, 2012 11:12 AM > > To: Dan Magenheimer > > Cc: xen-devel@lists.xen.org; Kurt Hackel; Konrad Wilk > > Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) > > > > Dan Magenheimer writes ("[Xen-devel] domain creation vs querying free memory (xend and xl)"): > > > But the second domain launch fails, possibly after > > > several minutes because, actually, there isn't enough > > > physical RAM for both. > > > > This is a real problem. The solution is not easy, and may not make it > > for 4.3. It would involve a rework of the memory handling code in > > libxl. > > [broadening cc to "Xen memory technology people", please forward/add > if I missed someone] Dan, I'm sure there has been already alot of thought and discussion about this issue, So here are my thoughts: In my opinion the code which is about to start a domain has to take all currently created/starting/running/dying domains, and their individual "allocation behaviour", into account before it can finally launch the domain. All of this needs math, not locking. A domain (domU or dom0) has a couple of constraints: - current nr_pages vs. target_nr_pages vs. max_pages - current PoD allocation vs. max_PoD - current paged_pages vs. target_nr_pages vs. max_paged_pages - some shared_pages - some tmem - maybe grant_pages - ... Depending on the state (starting and working towards a target number, running, dying) the "current" numbers above will increase or shrink. So the algorithm which turns the parameters above for each domain into a total number of allocated (or soon to be allocated) host memory has to work with "target numbers" instead of what is currently allocated. Some examples that come to mind: - a PoD domain will most likely use all of the pages configured with memory=, so that number should be used - the number shared pages is eventually not predictable. If so, this number could be handled as "allocated to the guest". Maybe a knob to say "running domains will have amount N shared" can exist? Dont know much about how sharing looks in practice. - ballooning may not reach the configured target, and the guest admin can just balloon up to the limit without notifying the toolstack - a new paging target will take some time until its reached, there is always some jitter during page-in/page-out, mapping guest pages will cause nomination failures. - tmem does something, I dont know. - no idea if grant pages are needed in the math Since the central management of xend is gone each libxl process is likely on its own, so two "xl create" can race when doing the math. Maybe a libxl process dies and leaves a mess behind. So that could make it difficult to get a good snapshot of the memory situation on the host. Maybe each domain could get some metadata to record the individual current/target/max numbers. Or if xenstore is good enough, something can cleanup zombie numbers. As IanJ said, the memory handling code in libxl needs such a feature to do the math right. The proposed handling of sharing/paging/ballooning/PoD/tmem/... in libxl is just a small part of it. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 18:26:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 18:26:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJq7u-0007YH-Kq; Thu, 04 Oct 2012 18:26:26 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJq7t-0007Y8-9z for xen-devel@lists.xen.org; Thu, 04 Oct 2012 18:26:25 +0000 Received: from [85.158.143.99:27578] by server-2.bemta-4.messagelabs.com id C2/E1-06610-0D4DD605; Thu, 04 Oct 2012 18:26:24 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-7.tower-216.messagelabs.com!1349375183!26782201!1 X-Originating-IP: [81.169.146.160] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MzM0NzY=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MzM0NzY=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18230 invoked from network); 4 Oct 2012 18:26:24 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160) by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Oct 2012 18:26:24 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll3c7ofw== X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-084-057-084-003.pools.arcor-ip.net [84.57.84.3]) by smtp.strato.de (jored mo5) (RZmta 30.20 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id Y063ebo94GcWND ; Thu, 4 Oct 2012 20:26:14 +0200 (CEST) Received: by probook.site (Postfix, from userid 1000) id B82121863E; Thu, 4 Oct 2012 20:26:13 +0200 (CEST) Date: Thu, 4 Oct 2012 20:26:13 +0200 From: Olaf Hering To: Dan Magenheimer Message-ID: <20121004182613.GA9244@aepfle.de> References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> User-Agent: Mutt/1.5.21.rev5555 (2012-07-20) Cc: Keir Fraser , Konrad Wilk , George Dunlap , Kurt Hackel , tim@xen.org, xen-devel@lists.xen.org, George Shuklin , Dario Faggioli , Andres Lagar-Cavilla , Ian Jackson Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, Oct 01, Dan Magenheimer wrote: > > From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com] > > Sent: Friday, September 28, 2012 11:12 AM > > To: Dan Magenheimer > > Cc: xen-devel@lists.xen.org; Kurt Hackel; Konrad Wilk > > Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) > > > > Dan Magenheimer writes ("[Xen-devel] domain creation vs querying free memory (xend and xl)"): > > > But the second domain launch fails, possibly after > > > several minutes because, actually, there isn't enough > > > physical RAM for both. > > > > This is a real problem. The solution is not easy, and may not make it > > for 4.3. It would involve a rework of the memory handling code in > > libxl. > > [broadening cc to "Xen memory technology people", please forward/add > if I missed someone] Dan, I'm sure there has been already alot of thought and discussion about this issue, So here are my thoughts: In my opinion the code which is about to start a domain has to take all currently created/starting/running/dying domains, and their individual "allocation behaviour", into account before it can finally launch the domain. All of this needs math, not locking. A domain (domU or dom0) has a couple of constraints: - current nr_pages vs. target_nr_pages vs. max_pages - current PoD allocation vs. max_PoD - current paged_pages vs. target_nr_pages vs. max_paged_pages - some shared_pages - some tmem - maybe grant_pages - ... Depending on the state (starting and working towards a target number, running, dying) the "current" numbers above will increase or shrink. So the algorithm which turns the parameters above for each domain into a total number of allocated (or soon to be allocated) host memory has to work with "target numbers" instead of what is currently allocated. Some examples that come to mind: - a PoD domain will most likely use all of the pages configured with memory=, so that number should be used - the number shared pages is eventually not predictable. If so, this number could be handled as "allocated to the guest". Maybe a knob to say "running domains will have amount N shared" can exist? Dont know much about how sharing looks in practice. - ballooning may not reach the configured target, and the guest admin can just balloon up to the limit without notifying the toolstack - a new paging target will take some time until its reached, there is always some jitter during page-in/page-out, mapping guest pages will cause nomination failures. - tmem does something, I dont know. - no idea if grant pages are needed in the math Since the central management of xend is gone each libxl process is likely on its own, so two "xl create" can race when doing the math. Maybe a libxl process dies and leaves a mess behind. So that could make it difficult to get a good snapshot of the memory situation on the host. Maybe each domain could get some metadata to record the individual current/target/max numbers. Or if xenstore is good enough, something can cleanup zombie numbers. As IanJ said, the memory handling code in libxl needs such a feature to do the math right. The proposed handling of sharing/paging/ballooning/PoD/tmem/... in libxl is just a small part of it. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 18:28:09 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 18:28:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJq9J-0007fo-4K; Thu, 04 Oct 2012 18:27:53 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJq9H-0007fH-Ea for Xen-devel@lists.xensource.com; Thu, 04 Oct 2012 18:27:51 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-16.tower-27.messagelabs.com!1349375262!12080005!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc5MzIzNg==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22509 invoked from network); 4 Oct 2012 18:27:45 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Oct 2012 18:27:45 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q94IRbhL019460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Oct 2012 18:27:38 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q94IRa33027574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Oct 2012 18:27:37 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q94IRaWU010625; Thu, 4 Oct 2012 13:27:36 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 04 Oct 2012 11:27:36 -0700 Date: Thu, 4 Oct 2012 11:27:34 -0700 From: Mukesh Rathor To: Ian Campbell Message-ID: <20121004112734.4f003584@mantra.us.oracle.com> In-Reply-To: <1349339279.650.214.camel@zakaz.uk.xensource.com> References: <20120921121556.1a0ea8af@mantra.us.oracle.com> <1349278963.650.164.camel@zakaz.uk.xensource.com> <20121003152925.5af3a658@mantra.us.oracle.com> <1349339279.650.214.camel@zakaz.uk.xensource.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 4 Oct 2012 09:27:59 +0100 Ian Campbell wrote: > On Wed, 2012-10-03 at 23:29 +0100, Mukesh Rathor wrote: > > On Wed, 3 Oct 2012 16:42:43 +0100 > > Ian Campbell wrote: > > > > > > > > > int xen_remap_domain_mfn_range(struct vm_area_struct *vma, > > > > unsigned long addr, > > > > unsigned long mfn, int nr, > > > > - pgprot_t prot, unsigned domid); > > > > + pgprot_t prot, unsigned domid, > > > > + struct xen_pvh_pfn_info *pvhp); > > > > +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma, > > > > + struct xen_pvh_pfn_info *pvhp); > > > > + > > > > +struct xen_pvh_pfn_info { > > > > > > Can we call this xen_remap_mfn_info or something? PVH is x86 > > > specific while this struct is also useful on ARM. > > > > I already renamed it to: xen_xlat_pfn_info. > > What does xlat refer to here? I don't think we translate anything with > this struct. paging mode xlate! See stefanno's prev email where he suggested changing name to this. > > > > + struct page **pi_paga; /* pfn info page > > > > array */ > > > > > > can we just call this "pages"? paga is pretty meaningless. > > > > page array! i can rename page_array or page_a. > > What's wrong with pages? It's short (some of the lines using this > stuff are necessarily pretty long) and obvious. grep'ing pages would give thousands results. I can prefix with something and use pages. > > > > + int pi_num_pgs; > > > > + int pi_next_todo; > > > > > > I don't think we need the pi_ prefix for any of these. > > > > The prefix for fields in struct make it easy to find via cscope or > > grep, otherwise, it's a nightmare to find common field names like > > pages when reading code. I really get frustrated. I prefer prefixing > > all field names. > > It's not common practice in Linux to do so but fair enough. > > While implementing the ARM version of this interface it occurred to me > that the num_pgs and next_todo fields here are not really needed > across the arch interface e.g. you already get pi_num_pgs from the nr > argument to xen_remap_domain_mfn_range and pi_next_todo is really > state which fits in struct pvh_remap_data. That would mean that > remap_foo could take a struct page * directly and I think you would > save an allocation. Ok, let me explore this. thanks Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 18:28:09 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 18:28:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJq9J-0007fo-4K; Thu, 04 Oct 2012 18:27:53 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJq9H-0007fH-Ea for Xen-devel@lists.xensource.com; Thu, 04 Oct 2012 18:27:51 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-16.tower-27.messagelabs.com!1349375262!12080005!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc5MzIzNg==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22509 invoked from network); 4 Oct 2012 18:27:45 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Oct 2012 18:27:45 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q94IRbhL019460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Oct 2012 18:27:38 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q94IRa33027574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Oct 2012 18:27:37 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q94IRaWU010625; Thu, 4 Oct 2012 13:27:36 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 04 Oct 2012 11:27:36 -0700 Date: Thu, 4 Oct 2012 11:27:34 -0700 From: Mukesh Rathor To: Ian Campbell Message-ID: <20121004112734.4f003584@mantra.us.oracle.com> In-Reply-To: <1349339279.650.214.camel@zakaz.uk.xensource.com> References: <20120921121556.1a0ea8af@mantra.us.oracle.com> <1349278963.650.164.camel@zakaz.uk.xensource.com> <20121003152925.5af3a658@mantra.us.oracle.com> <1349339279.650.214.camel@zakaz.uk.xensource.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 4 Oct 2012 09:27:59 +0100 Ian Campbell wrote: > On Wed, 2012-10-03 at 23:29 +0100, Mukesh Rathor wrote: > > On Wed, 3 Oct 2012 16:42:43 +0100 > > Ian Campbell wrote: > > > > > > > > > int xen_remap_domain_mfn_range(struct vm_area_struct *vma, > > > > unsigned long addr, > > > > unsigned long mfn, int nr, > > > > - pgprot_t prot, unsigned domid); > > > > + pgprot_t prot, unsigned domid, > > > > + struct xen_pvh_pfn_info *pvhp); > > > > +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma, > > > > + struct xen_pvh_pfn_info *pvhp); > > > > + > > > > +struct xen_pvh_pfn_info { > > > > > > Can we call this xen_remap_mfn_info or something? PVH is x86 > > > specific while this struct is also useful on ARM. > > > > I already renamed it to: xen_xlat_pfn_info. > > What does xlat refer to here? I don't think we translate anything with > this struct. paging mode xlate! See stefanno's prev email where he suggested changing name to this. > > > > + struct page **pi_paga; /* pfn info page > > > > array */ > > > > > > can we just call this "pages"? paga is pretty meaningless. > > > > page array! i can rename page_array or page_a. > > What's wrong with pages? It's short (some of the lines using this > stuff are necessarily pretty long) and obvious. grep'ing pages would give thousands results. I can prefix with something and use pages. > > > > + int pi_num_pgs; > > > > + int pi_next_todo; > > > > > > I don't think we need the pi_ prefix for any of these. > > > > The prefix for fields in struct make it easy to find via cscope or > > grep, otherwise, it's a nightmare to find common field names like > > pages when reading code. I really get frustrated. I prefer prefixing > > all field names. > > It's not common practice in Linux to do so but fair enough. > > While implementing the ARM version of this interface it occurred to me > that the num_pgs and next_todo fields here are not really needed > across the arch interface e.g. you already get pi_num_pgs from the nr > argument to xen_remap_domain_mfn_range and pi_next_todo is really > state which fits in struct pvh_remap_data. That would mean that > remap_foo could take a struct page * directly and I think you would > save an allocation. Ok, let me explore this. thanks Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 18:54:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 18:54:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJqZ2-0008Pl-48; Thu, 04 Oct 2012 18:54:28 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJqZ0-0008Pg-U7 for Xen-devel@lists.xensource.com; Thu, 04 Oct 2012 18:54:27 +0000 Received: from [85.158.143.35:2554] by server-3.bemta-4.messagelabs.com id 43/F5-10986-26BDD605; Thu, 04 Oct 2012 18:54:26 +0000 X-Env-Sender: ketuzsezr@gmail.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1349376864!12418208!1 X-Originating-IP: [209.85.212.43] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10603 invoked from network); 4 Oct 2012 18:54:25 -0000 Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com) (209.85.212.43) by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 18:54:25 -0000 Received: by mail-vb0-f43.google.com with SMTP id fq11so1168906vbb.30 for ; Thu, 04 Oct 2012 11:54:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=gFdjnXVnqlEi+4E0jmE8EJwfsLJcdF7C3hqimdpokKM=; b=TLjykgaEOORta6KCEjfLnmL1U8eeAkVQrxQlIkDigeQ5/tXFcuW1OFORhoFV6lizN3 zefJESJBoJyRKsDH84IKI2NF+WkzsGbZwTybmN30I5kFdAnqnGnVeXCICIYKltrEMeGr jfqhOs4bWrLqfHTNOy051kAXeVN02kBr9G9iREfpLquWqGvtG1zzPGcld0cAyD8v91aZ 5gwkXSewXtv2OkWPrEKpc3FPVeC4FEDXcb/bPoxwUT75B9M7lqa9ACBj7pq3u7LNX7Vh ADiXN5qsuDlvnMZAaDCWSEmmT1lnjiwSfE56UoHRJ5RMNWbxN9kd48z/W9HetyY/GlO6 Ny2Q== Received: by 10.220.38.196 with SMTP id c4mr3724439vce.41.1349376860967; Thu, 04 Oct 2012 11:54:20 -0700 (PDT) Received: from phenom.dumpdata.com (50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189]) by mx.google.com with ESMTPS id b7sm1019673vdv.2.2012.10.04.11.54.19 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Oct 2012 11:54:20 -0700 (PDT) Date: Thu, 4 Oct 2012 14:42:55 -0400 From: Konrad Rzeszutek Wilk To: Mukesh Rathor Message-ID: <20121004184254.GA28198@phenom.dumpdata.com> References: <20120921121556.1a0ea8af@mantra.us.oracle.com> <1349278963.650.164.camel@zakaz.uk.xensource.com> <20121003152925.5af3a658@mantra.us.oracle.com> <1349339279.650.214.camel@zakaz.uk.xensource.com> <20121004112734.4f003584@mantra.us.oracle.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20121004112734.4f003584@mantra.us.oracle.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Xen-devel@lists.xensource.com" , Ian Campbell , Konrad Rzeszutek Wilk , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > > > > > + struct page **pi_paga; /* pfn info page > > > > > array */ > > > > > > > > can we just call this "pages"? paga is pretty meaningless. > > > > > > page array! i can rename page_array or page_a. > > > > What's wrong with pages? It's short (some of the lines using this > > stuff are necessarily pretty long) and obvious. > > grep'ing pages would give thousands results. I can prefix with something > and use pages. Please don't prefix it. 'pages' is good. > > > > > > > + int pi_num_pgs; > > > > > + int pi_next_todo; > > > > > > > > I don't think we need the pi_ prefix for any of these. > > > > > > The prefix for fields in struct make it easy to find via cscope or > > > grep, otherwise, it's a nightmare to find common field names like > > > pages when reading code. I really get frustrated. I prefer prefixing > > > all field names. > > > > It's not common practice in Linux to do so but fair enough. Please remove the 'pi_' field. Everytime I see it I think of bathroom and then 3.1415... I've no idea what it actually stands for and I am not sure if there is a need to know what it stands for? If the 'pi_' is very important - it should be part of the structure's name. And then probably unrolled. If you are searching for a field in a structure - why? Why not search for the structure itself? Making the structure name unique should be enough right to find in cscope/ctags? Both ctags and cscope are good at helping you (once you have the structure or code name) at finding the definitions of the fields if you need to. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 18:54:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 18:54:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJqZ2-0008Pl-48; Thu, 04 Oct 2012 18:54:28 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJqZ0-0008Pg-U7 for Xen-devel@lists.xensource.com; Thu, 04 Oct 2012 18:54:27 +0000 Received: from [85.158.143.35:2554] by server-3.bemta-4.messagelabs.com id 43/F5-10986-26BDD605; Thu, 04 Oct 2012 18:54:26 +0000 X-Env-Sender: ketuzsezr@gmail.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1349376864!12418208!1 X-Originating-IP: [209.85.212.43] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10603 invoked from network); 4 Oct 2012 18:54:25 -0000 Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com) (209.85.212.43) by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 18:54:25 -0000 Received: by mail-vb0-f43.google.com with SMTP id fq11so1168906vbb.30 for ; Thu, 04 Oct 2012 11:54:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=gFdjnXVnqlEi+4E0jmE8EJwfsLJcdF7C3hqimdpokKM=; b=TLjykgaEOORta6KCEjfLnmL1U8eeAkVQrxQlIkDigeQ5/tXFcuW1OFORhoFV6lizN3 zefJESJBoJyRKsDH84IKI2NF+WkzsGbZwTybmN30I5kFdAnqnGnVeXCICIYKltrEMeGr jfqhOs4bWrLqfHTNOy051kAXeVN02kBr9G9iREfpLquWqGvtG1zzPGcld0cAyD8v91aZ 5gwkXSewXtv2OkWPrEKpc3FPVeC4FEDXcb/bPoxwUT75B9M7lqa9ACBj7pq3u7LNX7Vh ADiXN5qsuDlvnMZAaDCWSEmmT1lnjiwSfE56UoHRJ5RMNWbxN9kd48z/W9HetyY/GlO6 Ny2Q== Received: by 10.220.38.196 with SMTP id c4mr3724439vce.41.1349376860967; Thu, 04 Oct 2012 11:54:20 -0700 (PDT) Received: from phenom.dumpdata.com (50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189]) by mx.google.com with ESMTPS id b7sm1019673vdv.2.2012.10.04.11.54.19 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Oct 2012 11:54:20 -0700 (PDT) Date: Thu, 4 Oct 2012 14:42:55 -0400 From: Konrad Rzeszutek Wilk To: Mukesh Rathor Message-ID: <20121004184254.GA28198@phenom.dumpdata.com> References: <20120921121556.1a0ea8af@mantra.us.oracle.com> <1349278963.650.164.camel@zakaz.uk.xensource.com> <20121003152925.5af3a658@mantra.us.oracle.com> <1349339279.650.214.camel@zakaz.uk.xensource.com> <20121004112734.4f003584@mantra.us.oracle.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20121004112734.4f003584@mantra.us.oracle.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Xen-devel@lists.xensource.com" , Ian Campbell , Konrad Rzeszutek Wilk , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > > > > > + struct page **pi_paga; /* pfn info page > > > > > array */ > > > > > > > > can we just call this "pages"? paga is pretty meaningless. > > > > > > page array! i can rename page_array or page_a. > > > > What's wrong with pages? It's short (some of the lines using this > > stuff are necessarily pretty long) and obvious. > > grep'ing pages would give thousands results. I can prefix with something > and use pages. Please don't prefix it. 'pages' is good. > > > > > > > + int pi_num_pgs; > > > > > + int pi_next_todo; > > > > > > > > I don't think we need the pi_ prefix for any of these. > > > > > > The prefix for fields in struct make it easy to find via cscope or > > > grep, otherwise, it's a nightmare to find common field names like > > > pages when reading code. I really get frustrated. I prefer prefixing > > > all field names. > > > > It's not common practice in Linux to do so but fair enough. Please remove the 'pi_' field. Everytime I see it I think of bathroom and then 3.1415... I've no idea what it actually stands for and I am not sure if there is a need to know what it stands for? If the 'pi_' is very important - it should be part of the structure's name. And then probably unrolled. If you are searching for a field in a structure - why? Why not search for the structure itself? Making the structure name unique should be enough right to find in cscope/ctags? Both ctags and cscope are good at helping you (once you have the structure or code name) at finding the definitions of the fields if you need to. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 19:04:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 19:04:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJqiQ-0000HV-BT; Thu, 04 Oct 2012 19:04:10 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJqiO-0000H7-7f for xen-devel@lists.xensource.com; Thu, 04 Oct 2012 19:04:08 +0000 Received: from [85.158.139.83:25363] by server-15.bemta-5.messagelabs.com id 31/03-06905-7ADDD605; Thu, 04 Oct 2012 19:04:07 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-16.tower-182.messagelabs.com!1349377446!26129116!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28788 invoked from network); 4 Oct 2012 19:04:06 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 19:04:06 -0000 X-IronPort-AV: E=Sophos;i="4.80,537,1344211200"; d="scan'208";a="14949250" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 19:04:05 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 20:04:05 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TJqiL-0006yy-HD; Thu, 04 Oct 2012 19:04:05 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1TJqiK-0005f6-TX; Thu, 04 Oct 2012 20:04:05 +0100 To: Message-ID: From: xen.org Date: Thu, 4 Oct 2012 20:04:04 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.2-testing test] 13920: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 13920 xen-4.2-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13920/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-pv 9 guest-start fail REGR. vs. 13912 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-i386-i386-xl-qemuu-winxpsp3 9 guest-localmigrate fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: xen a69c8e5c4afc baseline version: xen ca3e8190a72c ------------------------------------------------------------ People who touched revisions under test: Ben Guthro Daniel De Graaf Ian Campbell Ian Jackson Jan Beulich Keir Fraser ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv fail test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 25871:a69c8e5c4afc tag: tip user: Jan Beulich date: Thu Oct 04 10:16:20 2012 +0200 x86/ucode: fix Intel case of resume handling on boot CPU Checking the stored version doesn't tell us anything about the need to apply the update (during resume, what is stored doesn't necessarily match what is loaded). Note that the check can be removed altogether because once switched to use what was read from the CPU (uci->cpu_sig.rev, as used in the subsequent pr_debug()), it would become redundant with the checks that lead to microcode_update_match() returning the indication that an update should be applied. Note further that this was not an issue on APs since they start with uci->mc.mc_intel being NULL. Signed-off-by: Jan Beulich Tested-by: Ben Guthro Acked-by: Keir Fraser xen-unstable changeset: 25965:4496d56c68a0 xen-unstable date: Fri Sep 28 07:28:11 UTC 2012 changeset: 25870:648c99c230ff user: Jan Beulich date: Thu Oct 04 10:15:16 2012 +0200 x86/IRQ: fix valid-old-vector checks in __assign_irq_vector() There are two greater-than-zero checks for the old vector retrieved, which don't work when a negative value got stashed into the respective arch_irq_desc field. The effect of this was that for interrupts that are intended to get their affinity adjusted the first time before the first interrupt occurs, the affinity change would fail, because the original vector assignment would have caused the move_in_progress flag to get set (which causes subsequent re-assignments to fail until it gets cleared, which only happens from the ->ack() actor, i.e. when an interrupt actually occurred). This addresses a problem introduced in c/s 23816:7f357e1ef60a (by changing IRQ_VECTOR_UNASSIGNED from 0 to -1). Signed-off-by: Jan Beulich Acked-by: Keir Fraser xen-unstable changeset: 25962:41f523f1b5e5 xen-unstable date: Fri Sep 28 07:23:34 UTC 2012 changeset: 25869:051661b76ade user: Jan Beulich date: Thu Oct 04 10:14:44 2012 +0200 x86/HPET: don't disable interrupt delivery right after setting it up We shouldn't clear HPET_TN_FSB right after we (indirectly, via request_irq()) enabled it for the channels we intend to use for broadcasts. This fixes a regression introduced by c/s 25103:0b0e42dc4f0a. Signed-off-by: Jan Beulich Acked-by: Keir Fraser xen-unstable changeset: 25961:6a5812129094 xen-unstable date: Fri Sep 28 07:22:14 UTC 2012 changeset: 25868:b4bda6995bc1 user: Daniel De Graaf date: Thu Oct 04 10:13:55 2012 +0200 x86: check remote MMIO remap permissions When a domain is mapping pages from a different pg_owner domain, the iomem_access checks are currently only applied to the pg_owner domain, potentially allowing a domain with a more restrictive iomem_access policy to have the pages mapped into its page tables. To catch this, also check the owner of the page tables. The current domain does not need to be checked because the ability to manipulate a domain's page tables implies full access to the target domain, so checking that domain's permission is sufficient. Signed-off-by: Daniel De Graaf Acked-by: Jan Beulich xen-unstable changeset: 25952:8278d7d8fa48 xen-unstable date: Wed Sep 26 09:56:07 UTC 2012 changeset: 25867:b0aed9cadf10 user: Ben Guthro date: Thu Oct 04 10:12:43 2012 +0200 x86/S3: add cache flush on secondary CPUs before going to sleep Secondary CPUs, between doing their final memory writes (particularly updating cpu_initialized) and getting a subsequent INIT, may not write back all modified data. The INIT itself then causes those modifications to be lost, so in the cpu_initialized case the CPU would find itself already initialized, (intentionally) entering an infinite loop instead of actually coming online. Signed-off-by: Ben Guthro Make acpi_dead_idle() call default_dead_idle() rather than duplicating the logic there. Signed-off-by: Jan Beulich Acked-by: Keir Fraser xen-unstable changeset: 25940:c8d65d91a6f2 xen-unstable date: Tue Sep 25 06:38:14 UTC 2012 changeset: 25866:ffabc1ebd913 user: Jan Beulich date: Thu Oct 04 10:11:11 2012 +0200 x86: tighten checks in XEN_DOMCTL_memory_mapping handler Properly checking the MFN implies knowing the physical address width supported by the platform, so to obtain this consistently the respective code gets moved out of the MTRR subdir. Btw., the model specific workaround in that code is likely unnecessary - I believe those CPU models don't support 64-bit mode. But I wasn't able to formally verify this, so I preferred to retain that code for now. But domctl code here also was lacking other error checks (as was, looking at it again from that angle) the XEN_DOMCTL_ioport_mapping one. Besides adding the missing checks, printing is also added for the case where revoking access permissions didn't work (as that may have implications for the host operator, e.g. wanting to not pass through affected devices to another guest until the one previously using them did actually die). Signed-off-by: Jan Beulich Acked-by: Keir Fraser xen-unstable changeset: 25931:149805919569 xen-unstable date: Thu Sep 20 07:21:53 UTC 2012 changeset: 25865:63823a6785fc user: Jan Beulich date: Thu Oct 04 10:10:23 2012 +0200 x86: properly check XEN_DOMCTL_ioport_mapping arguments for invalid range In particular, the case of "np" being a very large value wasn't handled correctly. The range start checks also were off by one (except that in practice, when "np" is properly range checked, this would still have been caught by the range end checks). Also, is a GFN wrap in XEN_DOMCTL_memory_mapping really okay? Signed-off-by: Jan Beulich Acked-by: Keir Fraser xen-unstable changeset: 25927:3e3959413b2f xen-unstable date: Wed Sep 19 07:27:55 UTC 2012 changeset: 25864:ca3e8190a72c user: Ian Campbell date: Tue Oct 02 16:02:10 2012 +0100 tools: bump SONAMEs for changes during 4.2 development cycle. We mostly did this as we went along, only a couple of minor number bumps were missed http://marc.info/?l=xen-devel&m=134366054929255&w=2: - Bumped libxl from 1.0.0 -> 1.0.1 - Bumped libxenstore from 3.0.1 -> 3.0.2 Signed-off-by: Ian Campbell Acked-by: Ian Jackson Committed-by: Ian Campbell xen-unstable changeset: 25943:0a64f1a3f72c Backport-requested-by: Ian Campbell Committed-by: Ian Jackson (qemu changes not included) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 19:04:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 19:04:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJqiQ-0000HV-BT; Thu, 04 Oct 2012 19:04:10 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJqiO-0000H7-7f for xen-devel@lists.xensource.com; Thu, 04 Oct 2012 19:04:08 +0000 Received: from [85.158.139.83:25363] by server-15.bemta-5.messagelabs.com id 31/03-06905-7ADDD605; Thu, 04 Oct 2012 19:04:07 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-16.tower-182.messagelabs.com!1349377446!26129116!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28788 invoked from network); 4 Oct 2012 19:04:06 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 19:04:06 -0000 X-IronPort-AV: E=Sophos;i="4.80,537,1344211200"; d="scan'208";a="14949250" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 19:04:05 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 20:04:05 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TJqiL-0006yy-HD; Thu, 04 Oct 2012 19:04:05 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1TJqiK-0005f6-TX; Thu, 04 Oct 2012 20:04:05 +0100 To: Message-ID: From: xen.org Date: Thu, 4 Oct 2012 20:04:04 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.2-testing test] 13920: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 13920 xen-4.2-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13920/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-pv 9 guest-start fail REGR. vs. 13912 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-i386-i386-xl-qemuu-winxpsp3 9 guest-localmigrate fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: xen a69c8e5c4afc baseline version: xen ca3e8190a72c ------------------------------------------------------------ People who touched revisions under test: Ben Guthro Daniel De Graaf Ian Campbell Ian Jackson Jan Beulich Keir Fraser ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv fail test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 25871:a69c8e5c4afc tag: tip user: Jan Beulich date: Thu Oct 04 10:16:20 2012 +0200 x86/ucode: fix Intel case of resume handling on boot CPU Checking the stored version doesn't tell us anything about the need to apply the update (during resume, what is stored doesn't necessarily match what is loaded). Note that the check can be removed altogether because once switched to use what was read from the CPU (uci->cpu_sig.rev, as used in the subsequent pr_debug()), it would become redundant with the checks that lead to microcode_update_match() returning the indication that an update should be applied. Note further that this was not an issue on APs since they start with uci->mc.mc_intel being NULL. Signed-off-by: Jan Beulich Tested-by: Ben Guthro Acked-by: Keir Fraser xen-unstable changeset: 25965:4496d56c68a0 xen-unstable date: Fri Sep 28 07:28:11 UTC 2012 changeset: 25870:648c99c230ff user: Jan Beulich date: Thu Oct 04 10:15:16 2012 +0200 x86/IRQ: fix valid-old-vector checks in __assign_irq_vector() There are two greater-than-zero checks for the old vector retrieved, which don't work when a negative value got stashed into the respective arch_irq_desc field. The effect of this was that for interrupts that are intended to get their affinity adjusted the first time before the first interrupt occurs, the affinity change would fail, because the original vector assignment would have caused the move_in_progress flag to get set (which causes subsequent re-assignments to fail until it gets cleared, which only happens from the ->ack() actor, i.e. when an interrupt actually occurred). This addresses a problem introduced in c/s 23816:7f357e1ef60a (by changing IRQ_VECTOR_UNASSIGNED from 0 to -1). Signed-off-by: Jan Beulich Acked-by: Keir Fraser xen-unstable changeset: 25962:41f523f1b5e5 xen-unstable date: Fri Sep 28 07:23:34 UTC 2012 changeset: 25869:051661b76ade user: Jan Beulich date: Thu Oct 04 10:14:44 2012 +0200 x86/HPET: don't disable interrupt delivery right after setting it up We shouldn't clear HPET_TN_FSB right after we (indirectly, via request_irq()) enabled it for the channels we intend to use for broadcasts. This fixes a regression introduced by c/s 25103:0b0e42dc4f0a. Signed-off-by: Jan Beulich Acked-by: Keir Fraser xen-unstable changeset: 25961:6a5812129094 xen-unstable date: Fri Sep 28 07:22:14 UTC 2012 changeset: 25868:b4bda6995bc1 user: Daniel De Graaf date: Thu Oct 04 10:13:55 2012 +0200 x86: check remote MMIO remap permissions When a domain is mapping pages from a different pg_owner domain, the iomem_access checks are currently only applied to the pg_owner domain, potentially allowing a domain with a more restrictive iomem_access policy to have the pages mapped into its page tables. To catch this, also check the owner of the page tables. The current domain does not need to be checked because the ability to manipulate a domain's page tables implies full access to the target domain, so checking that domain's permission is sufficient. Signed-off-by: Daniel De Graaf Acked-by: Jan Beulich xen-unstable changeset: 25952:8278d7d8fa48 xen-unstable date: Wed Sep 26 09:56:07 UTC 2012 changeset: 25867:b0aed9cadf10 user: Ben Guthro date: Thu Oct 04 10:12:43 2012 +0200 x86/S3: add cache flush on secondary CPUs before going to sleep Secondary CPUs, between doing their final memory writes (particularly updating cpu_initialized) and getting a subsequent INIT, may not write back all modified data. The INIT itself then causes those modifications to be lost, so in the cpu_initialized case the CPU would find itself already initialized, (intentionally) entering an infinite loop instead of actually coming online. Signed-off-by: Ben Guthro Make acpi_dead_idle() call default_dead_idle() rather than duplicating the logic there. Signed-off-by: Jan Beulich Acked-by: Keir Fraser xen-unstable changeset: 25940:c8d65d91a6f2 xen-unstable date: Tue Sep 25 06:38:14 UTC 2012 changeset: 25866:ffabc1ebd913 user: Jan Beulich date: Thu Oct 04 10:11:11 2012 +0200 x86: tighten checks in XEN_DOMCTL_memory_mapping handler Properly checking the MFN implies knowing the physical address width supported by the platform, so to obtain this consistently the respective code gets moved out of the MTRR subdir. Btw., the model specific workaround in that code is likely unnecessary - I believe those CPU models don't support 64-bit mode. But I wasn't able to formally verify this, so I preferred to retain that code for now. But domctl code here also was lacking other error checks (as was, looking at it again from that angle) the XEN_DOMCTL_ioport_mapping one. Besides adding the missing checks, printing is also added for the case where revoking access permissions didn't work (as that may have implications for the host operator, e.g. wanting to not pass through affected devices to another guest until the one previously using them did actually die). Signed-off-by: Jan Beulich Acked-by: Keir Fraser xen-unstable changeset: 25931:149805919569 xen-unstable date: Thu Sep 20 07:21:53 UTC 2012 changeset: 25865:63823a6785fc user: Jan Beulich date: Thu Oct 04 10:10:23 2012 +0200 x86: properly check XEN_DOMCTL_ioport_mapping arguments for invalid range In particular, the case of "np" being a very large value wasn't handled correctly. The range start checks also were off by one (except that in practice, when "np" is properly range checked, this would still have been caught by the range end checks). Also, is a GFN wrap in XEN_DOMCTL_memory_mapping really okay? Signed-off-by: Jan Beulich Acked-by: Keir Fraser xen-unstable changeset: 25927:3e3959413b2f xen-unstable date: Wed Sep 19 07:27:55 UTC 2012 changeset: 25864:ca3e8190a72c user: Ian Campbell date: Tue Oct 02 16:02:10 2012 +0100 tools: bump SONAMEs for changes during 4.2 development cycle. We mostly did this as we went along, only a couple of minor number bumps were missed http://marc.info/?l=xen-devel&m=134366054929255&w=2: - Bumped libxl from 1.0.0 -> 1.0.1 - Bumped libxenstore from 3.0.1 -> 3.0.2 Signed-off-by: Ian Campbell Acked-by: Ian Jackson Committed-by: Ian Campbell xen-unstable changeset: 25943:0a64f1a3f72c Backport-requested-by: Ian Campbell Committed-by: Ian Jackson (qemu changes not included) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 19:39:14 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 19:39:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJrFy-0000cN-IH; Thu, 04 Oct 2012 19:38:50 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJrFx-0000cI-Rb for xen-devel@lists.xen.org; Thu, 04 Oct 2012 19:38:50 +0000 Received: from [85.158.139.211:34777] by server-12.bemta-5.messagelabs.com id 05/25-19095-9C5ED605; Thu, 04 Oct 2012 19:38:49 +0000 X-Env-Sender: dan.magenheimer@oracle.com X-Msg-Ref: server-4.tower-206.messagelabs.com!1349379527!21134282!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzgzMjE1\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3485 invoked from network); 4 Oct 2012 19:38:48 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-4.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Oct 2012 19:38:48 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q94JcYnZ025163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Oct 2012 19:38:35 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q94JcXxP029284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Oct 2012 19:38:34 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q94JcW0L022508; Thu, 4 Oct 2012 14:38:32 -0500 MIME-Version: 1.0 Message-ID: <18147469-adb0-4a86-b36f-231cb412d112@default> Date: Thu, 4 Oct 2012 12:38:26 -0700 (PDT) From: Dan Magenheimer To: Olaf Hering References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> <20121004182613.GA9244@aepfle.de> In-Reply-To: <20121004182613.GA9244@aepfle.de> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7 (607090) [OL 12.0.6661.5003 (x86)] X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: Keir Fraser , Konrad Wilk , George Dunlap , Kurt Hackel , tim@xen.org, xen-devel@lists.xen.org, George Shuklin , Dario Faggioli , Andres Lagar-Cavilla , Ian Jackson Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > From: Olaf Hering [mailto:olaf@aepfle.de] > Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) > > On Mon, Oct 01, Dan Magenheimer wrote: > Hi Olaf -- Thanks for the reply. > domain. All of this needs math, not locking. > : > As IanJ said, the memory handling code in libxl needs such a feature to > do the math right. The proposed handling of > sharing/paging/ballooning/PoD/tmem/... in libxl is just a small part of > it. Unfortunately, as you observe in some of the cases earlier in your reply, it is more than a math problem for libxl... it is a crystal ball problem. If xl launches a domain D at time T and it takes N seconds before it has completed asking the hypervisor for all of the memory M that D will require to successfully launch, then xl must determine at time T the maximum memory allocated across all running domains for the future time period between T and T+N. In other words, xl must predict the future. Clearly this is impossible especially when page-sharing is not communicating its dynamic allocations (e.g. due to page-splitting) to libxl, and tmem is not communicating allocations resulting from multiple domains simultaenously making tmem hypercalls to libxl, and PoD is not communicating its allocations to libxl, and in-guest-kernel selfballooning is not communicating allocations to libxl. Only the hypervisor is aware of every dynamic allocation request. So all libxl can do is guess about the future because races are going to occur. Multiple threads are simultaneously trying to access a limited resource (pages of memory) and only the hypervisor knows whether there is enough to deliver memory for all requests. To me, the solution to racing for a shared resource is locking. Naturally, you want the critical path to be as short as possible. And you don't want to lock all instances of the resource (i.e. every page in memory) if you can avoid it. And you need to ensure that the lock is honored for all requests to allocate the shared resource, meaning in this case that it has to be done in the hypervisor. I think that's what the proposed design does: It provides a mechanism to ask the hypervisor to reserve a fixed amount of memory M, some or all of which will eventually turn into an allocation request; and a mechanism to ask the hypervisor to no longer honor that reservation ("unreserve") whether or not all of M has been allocated. It essentially locks that M amount of memory between reserve and unreserve so that other dynamic allocations (page-sharing, tmem, PoD, OR another libxl thread trying to create another domain) cannot sneak in and claim memory capacity that has been reserved. Does that make sense? Thanks, Dan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 19:39:14 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 19:39:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJrFy-0000cN-IH; Thu, 04 Oct 2012 19:38:50 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJrFx-0000cI-Rb for xen-devel@lists.xen.org; Thu, 04 Oct 2012 19:38:50 +0000 Received: from [85.158.139.211:34777] by server-12.bemta-5.messagelabs.com id 05/25-19095-9C5ED605; Thu, 04 Oct 2012 19:38:49 +0000 X-Env-Sender: dan.magenheimer@oracle.com X-Msg-Ref: server-4.tower-206.messagelabs.com!1349379527!21134282!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzgzMjE1\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3485 invoked from network); 4 Oct 2012 19:38:48 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-4.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Oct 2012 19:38:48 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q94JcYnZ025163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Oct 2012 19:38:35 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q94JcXxP029284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Oct 2012 19:38:34 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q94JcW0L022508; Thu, 4 Oct 2012 14:38:32 -0500 MIME-Version: 1.0 Message-ID: <18147469-adb0-4a86-b36f-231cb412d112@default> Date: Thu, 4 Oct 2012 12:38:26 -0700 (PDT) From: Dan Magenheimer To: Olaf Hering References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> <20121004182613.GA9244@aepfle.de> In-Reply-To: <20121004182613.GA9244@aepfle.de> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7 (607090) [OL 12.0.6661.5003 (x86)] X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: Keir Fraser , Konrad Wilk , George Dunlap , Kurt Hackel , tim@xen.org, xen-devel@lists.xen.org, George Shuklin , Dario Faggioli , Andres Lagar-Cavilla , Ian Jackson Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > From: Olaf Hering [mailto:olaf@aepfle.de] > Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) > > On Mon, Oct 01, Dan Magenheimer wrote: > Hi Olaf -- Thanks for the reply. > domain. All of this needs math, not locking. > : > As IanJ said, the memory handling code in libxl needs such a feature to > do the math right. The proposed handling of > sharing/paging/ballooning/PoD/tmem/... in libxl is just a small part of > it. Unfortunately, as you observe in some of the cases earlier in your reply, it is more than a math problem for libxl... it is a crystal ball problem. If xl launches a domain D at time T and it takes N seconds before it has completed asking the hypervisor for all of the memory M that D will require to successfully launch, then xl must determine at time T the maximum memory allocated across all running domains for the future time period between T and T+N. In other words, xl must predict the future. Clearly this is impossible especially when page-sharing is not communicating its dynamic allocations (e.g. due to page-splitting) to libxl, and tmem is not communicating allocations resulting from multiple domains simultaenously making tmem hypercalls to libxl, and PoD is not communicating its allocations to libxl, and in-guest-kernel selfballooning is not communicating allocations to libxl. Only the hypervisor is aware of every dynamic allocation request. So all libxl can do is guess about the future because races are going to occur. Multiple threads are simultaneously trying to access a limited resource (pages of memory) and only the hypervisor knows whether there is enough to deliver memory for all requests. To me, the solution to racing for a shared resource is locking. Naturally, you want the critical path to be as short as possible. And you don't want to lock all instances of the resource (i.e. every page in memory) if you can avoid it. And you need to ensure that the lock is honored for all requests to allocate the shared resource, meaning in this case that it has to be done in the hypervisor. I think that's what the proposed design does: It provides a mechanism to ask the hypervisor to reserve a fixed amount of memory M, some or all of which will eventually turn into an allocation request; and a mechanism to ask the hypervisor to no longer honor that reservation ("unreserve") whether or not all of M has been allocated. It essentially locks that M amount of memory between reserve and unreserve so that other dynamic allocations (page-sharing, tmem, PoD, OR another libxl thread trying to create another domain) cannot sneak in and claim memory capacity that has been reserved. Does that make sense? Thanks, Dan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 20:00:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 20:00:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJrat-0000sZ-3B; Thu, 04 Oct 2012 20:00:27 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJrar-0000sL-9S for xen-devel@lists.xen.org; Thu, 04 Oct 2012 20:00:25 +0000 Received: from [85.158.139.83:27756] by server-7.bemta-5.messagelabs.com id FC/93-00431-8DAED605; Thu, 04 Oct 2012 20:00:24 +0000 X-Env-Sender: anthony.perard@gmail.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1349380822!29514547!1 X-Originating-IP: [209.85.223.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13324 invoked from network); 4 Oct 2012 20:00:23 -0000 Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com) (209.85.223.173) by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 20:00:23 -0000 Received: by mail-ie0-f173.google.com with SMTP id 17so2450640iea.32 for ; Thu, 04 Oct 2012 13:00:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=u8XPZerdpDXVy4+F45kvbfa6svrcP3MB8RnJl0ADa1w=; b=UqHbnky3yKOzn7mcSxt2Grw2xyYWmPKELQurVtUceWisorJV+4VS/vkidmcN6Cyt5c 1eBkBo3knIpnZy4Hewh2KY0q799V08q7w6RN7SwsmkavVwMaSHl5NLILmuT8PgzvmkWM p8+ChN9CZUrhfensSqBr+v8TG9tfPx3k82TRD/rMD2H6t2eweI2N6PF7D8tmSodwHOjX 06+r8Io1s6k5vTt62puucUQ/vo/TOFf79EQqdRAl+QRDa99SD5p9UjzrnC+JoV3mh1Rm rDM+Dcr7ElRJIC7kMQoymocn0XZPU1nA9DgiRvHtKDKrNK9dixYLPYtrMw7fipWQ7NtF Xwcw== Received: by 10.50.157.201 with SMTP id wo9mr6468992igb.57.1349380822234; Thu, 04 Oct 2012 13:00:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.97.164 with HTTP; Thu, 4 Oct 2012 12:59:52 -0700 (PDT) In-Reply-To: <20589.51177.530142.664975@mariner.uk.xensource.com> References: <1349367522-16695-1-git-send-email-anthony.perard@citrix.com> <1349367522-16695-2-git-send-email-anthony.perard@citrix.com> <20589.51177.530142.664975@mariner.uk.xensource.com> From: Anthony PERARD Date: Thu, 4 Oct 2012 20:59:52 +0100 X-Google-Sender-Auth: KanQge7PEs_CA33jBiYgYtUnj-w Message-ID: To: Ian Jackson Cc: Ian Campbell , Xen Devel Subject: Re: [Xen-devel] [PATCH V2 1/2] libxl: Have flexarray using the GC X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, Oct 4, 2012 at 6:31 PM, Ian Jackson wrote: > >> +static int gc_is_real(const libxl__gc *gc) >> +{ >> + return gc->alloc_maxsize >= 0; >> +} > > You have cloned-and-hacked this from libxl_internal.c ! Instead, > either declare it in libxl_internal.h, or move it there and make it > "static inline". OK, I'll "static inline" it. >> @@ -104,7 +115,8 @@ void **flexarray_contents(flexarray_t *array) >> { >> void **data; >> data = array->data; >> - free(array); >> + if (!gc_is_real(array->gc)) >> + free(array); >> return data; > > What an odd function. However, your patch to it seems right to me. It was maybe a workaround the missing ability to be GC'ed of flexarray. Thanks, -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 20:00:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 20:00:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJrat-0000sZ-3B; Thu, 04 Oct 2012 20:00:27 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJrar-0000sL-9S for xen-devel@lists.xen.org; Thu, 04 Oct 2012 20:00:25 +0000 Received: from [85.158.139.83:27756] by server-7.bemta-5.messagelabs.com id FC/93-00431-8DAED605; Thu, 04 Oct 2012 20:00:24 +0000 X-Env-Sender: anthony.perard@gmail.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1349380822!29514547!1 X-Originating-IP: [209.85.223.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13324 invoked from network); 4 Oct 2012 20:00:23 -0000 Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com) (209.85.223.173) by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 20:00:23 -0000 Received: by mail-ie0-f173.google.com with SMTP id 17so2450640iea.32 for ; Thu, 04 Oct 2012 13:00:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=u8XPZerdpDXVy4+F45kvbfa6svrcP3MB8RnJl0ADa1w=; b=UqHbnky3yKOzn7mcSxt2Grw2xyYWmPKELQurVtUceWisorJV+4VS/vkidmcN6Cyt5c 1eBkBo3knIpnZy4Hewh2KY0q799V08q7w6RN7SwsmkavVwMaSHl5NLILmuT8PgzvmkWM p8+ChN9CZUrhfensSqBr+v8TG9tfPx3k82TRD/rMD2H6t2eweI2N6PF7D8tmSodwHOjX 06+r8Io1s6k5vTt62puucUQ/vo/TOFf79EQqdRAl+QRDa99SD5p9UjzrnC+JoV3mh1Rm rDM+Dcr7ElRJIC7kMQoymocn0XZPU1nA9DgiRvHtKDKrNK9dixYLPYtrMw7fipWQ7NtF Xwcw== Received: by 10.50.157.201 with SMTP id wo9mr6468992igb.57.1349380822234; Thu, 04 Oct 2012 13:00:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.97.164 with HTTP; Thu, 4 Oct 2012 12:59:52 -0700 (PDT) In-Reply-To: <20589.51177.530142.664975@mariner.uk.xensource.com> References: <1349367522-16695-1-git-send-email-anthony.perard@citrix.com> <1349367522-16695-2-git-send-email-anthony.perard@citrix.com> <20589.51177.530142.664975@mariner.uk.xensource.com> From: Anthony PERARD Date: Thu, 4 Oct 2012 20:59:52 +0100 X-Google-Sender-Auth: KanQge7PEs_CA33jBiYgYtUnj-w Message-ID: To: Ian Jackson Cc: Ian Campbell , Xen Devel Subject: Re: [Xen-devel] [PATCH V2 1/2] libxl: Have flexarray using the GC X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, Oct 4, 2012 at 6:31 PM, Ian Jackson wrote: > >> +static int gc_is_real(const libxl__gc *gc) >> +{ >> + return gc->alloc_maxsize >= 0; >> +} > > You have cloned-and-hacked this from libxl_internal.c ! Instead, > either declare it in libxl_internal.h, or move it there and make it > "static inline". OK, I'll "static inline" it. >> @@ -104,7 +115,8 @@ void **flexarray_contents(flexarray_t *array) >> { >> void **data; >> data = array->data; >> - free(array); >> + if (!gc_is_real(array->gc)) >> + free(array); >> return data; > > What an odd function. However, your patch to it seems right to me. It was maybe a workaround the missing ability to be GC'ed of flexarray. Thanks, -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 20:19:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 20:19:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJrss-0001R0-QG; Thu, 04 Oct 2012 20:19:02 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJrsq-0001Qv-Ut for xen-devel@lists.xen.org; Thu, 04 Oct 2012 20:19:01 +0000 Received: from [85.158.143.35:11695] by server-1.bemta-4.messagelabs.com id 11/EC-05684-43FED605; Thu, 04 Oct 2012 20:19:00 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-6.tower-21.messagelabs.com!1349381939!21085164!1 X-Originating-IP: [81.169.146.160] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MzM0NzY=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MzM0NzY=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9369 invoked from network); 4 Oct 2012 20:18:59 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160) by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Oct 2012 20:18:59 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll3c7ofw== X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-084-057-084-003.pools.arcor-ip.net [84.57.84.3]) by smtp.strato.de (joses mo26) (RZmta 30.20 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id t06d38o94JlAjg ; Thu, 4 Oct 2012 22:18:49 +0200 (CEST) Received: by probook.site (Postfix, from userid 1000) id 245E91863E; Thu, 4 Oct 2012 22:18:49 +0200 (CEST) Date: Thu, 4 Oct 2012 22:18:49 +0200 From: Olaf Hering To: Dan Magenheimer Message-ID: <20121004201848.GA26455@aepfle.de> References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> <20121004182613.GA9244@aepfle.de> <18147469-adb0-4a86-b36f-231cb412d112@default> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <18147469-adb0-4a86-b36f-231cb412d112@default> User-Agent: Mutt/1.5.21.rev5555 (2012-07-20) Cc: Keir Fraser , Konrad Wilk , George Dunlap , Kurt Hackel , tim@xen.org, xen-devel@lists.xen.org, George Shuklin , Dario Faggioli , Andres Lagar-Cavilla , Ian Jackson Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, Oct 04, Dan Magenheimer wrote: > > From: Olaf Hering [mailto:olaf@aepfle.de] > > Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) > > > > On Mon, Oct 01, Dan Magenheimer wrote: > > > > Hi Olaf -- > > Thanks for the reply. > > > domain. All of this needs math, not locking. > > : > > As IanJ said, the memory handling code in libxl needs such a feature to > > do the math right. The proposed handling of > > sharing/paging/ballooning/PoD/tmem/... in libxl is just a small part of > > it. > > Unfortunately, as you observe in some of the cases earlier in your reply, > it is more than a math problem for libxl... it is a crystal ball problem. > If xl launches a domain D at time T and it takes N seconds before it has > completed asking the hypervisor for all of the memory M that D will require > to successfully launch, then xl must determine at time T the maximum memory > allocated across all running domains for the future time period between > T and T+N. In other words, xl must predict the future. I think xl can predict it, if it takes the target of all domains into account. Certainly not down to a handful pages, it would be good enough to know if the calculated estimate of free memory is good for the new guest and its specific memory targets. > Clearly this is impossible especially when page-sharing is not communicating > its dynamic allocations (e.g. due to page-splitting) to libxl, and tmem > is not communicating allocations resulting from multiple domains > simultaenously making tmem hypercalls to libxl, and PoD is not communicating > its allocations to libxl, and in-guest-kernel selfballooning is not communicating > allocations to libxl. Only the hypervisor is aware of every dynamic allocation > request. The hypervisor can not predict the future either, and it has even less info about the individual targets of each domain. > Does that make sense? It does, but: If xl reserves the memory in its own "virtual allocator", or if Xen gets such functionality, does not really matter, as long as its known how much exactly needs to be allocated. I think that part is missing. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 20:19:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 20:19:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJrss-0001R0-QG; Thu, 04 Oct 2012 20:19:02 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJrsq-0001Qv-Ut for xen-devel@lists.xen.org; Thu, 04 Oct 2012 20:19:01 +0000 Received: from [85.158.143.35:11695] by server-1.bemta-4.messagelabs.com id 11/EC-05684-43FED605; Thu, 04 Oct 2012 20:19:00 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-6.tower-21.messagelabs.com!1349381939!21085164!1 X-Originating-IP: [81.169.146.160] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MzM0NzY=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MzM0NzY=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9369 invoked from network); 4 Oct 2012 20:18:59 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160) by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Oct 2012 20:18:59 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll3c7ofw== X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-084-057-084-003.pools.arcor-ip.net [84.57.84.3]) by smtp.strato.de (joses mo26) (RZmta 30.20 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id t06d38o94JlAjg ; Thu, 4 Oct 2012 22:18:49 +0200 (CEST) Received: by probook.site (Postfix, from userid 1000) id 245E91863E; Thu, 4 Oct 2012 22:18:49 +0200 (CEST) Date: Thu, 4 Oct 2012 22:18:49 +0200 From: Olaf Hering To: Dan Magenheimer Message-ID: <20121004201848.GA26455@aepfle.de> References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> <20121004182613.GA9244@aepfle.de> <18147469-adb0-4a86-b36f-231cb412d112@default> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <18147469-adb0-4a86-b36f-231cb412d112@default> User-Agent: Mutt/1.5.21.rev5555 (2012-07-20) Cc: Keir Fraser , Konrad Wilk , George Dunlap , Kurt Hackel , tim@xen.org, xen-devel@lists.xen.org, George Shuklin , Dario Faggioli , Andres Lagar-Cavilla , Ian Jackson Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, Oct 04, Dan Magenheimer wrote: > > From: Olaf Hering [mailto:olaf@aepfle.de] > > Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) > > > > On Mon, Oct 01, Dan Magenheimer wrote: > > > > Hi Olaf -- > > Thanks for the reply. > > > domain. All of this needs math, not locking. > > : > > As IanJ said, the memory handling code in libxl needs such a feature to > > do the math right. The proposed handling of > > sharing/paging/ballooning/PoD/tmem/... in libxl is just a small part of > > it. > > Unfortunately, as you observe in some of the cases earlier in your reply, > it is more than a math problem for libxl... it is a crystal ball problem. > If xl launches a domain D at time T and it takes N seconds before it has > completed asking the hypervisor for all of the memory M that D will require > to successfully launch, then xl must determine at time T the maximum memory > allocated across all running domains for the future time period between > T and T+N. In other words, xl must predict the future. I think xl can predict it, if it takes the target of all domains into account. Certainly not down to a handful pages, it would be good enough to know if the calculated estimate of free memory is good for the new guest and its specific memory targets. > Clearly this is impossible especially when page-sharing is not communicating > its dynamic allocations (e.g. due to page-splitting) to libxl, and tmem > is not communicating allocations resulting from multiple domains > simultaenously making tmem hypercalls to libxl, and PoD is not communicating > its allocations to libxl, and in-guest-kernel selfballooning is not communicating > allocations to libxl. Only the hypervisor is aware of every dynamic allocation > request. The hypervisor can not predict the future either, and it has even less info about the individual targets of each domain. > Does that make sense? It does, but: If xl reserves the memory in its own "virtual allocator", or if Xen gets such functionality, does not really matter, as long as its known how much exactly needs to be allocated. I think that part is missing. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 20:36:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 20:36:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJs9b-0001fP-RZ; Thu, 04 Oct 2012 20:36:19 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJs9a-0001fK-OB for xen-devel@lists.xen.org; Thu, 04 Oct 2012 20:36:18 +0000 Received: from [85.158.143.99:52828] by server-2.bemta-4.messagelabs.com id 6A/37-06610-243FD605; Thu, 04 Oct 2012 20:36:18 +0000 X-Env-Sender: dan.magenheimer@oracle.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1349382976!26473662!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzgzMjE1\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29973 invoked from network); 4 Oct 2012 20:36:17 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Oct 2012 20:36:17 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q94Ka1YA017353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Oct 2012 20:36:02 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q94Ka0Ic012091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Oct 2012 20:36:00 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q94KZxKM003683; Thu, 4 Oct 2012 15:35:59 -0500 MIME-Version: 1.0 Message-ID: Date: Thu, 4 Oct 2012 13:35:53 -0700 (PDT) From: Dan Magenheimer To: Olaf Hering References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> <20121004182613.GA9244@aepfle.de> <18147469-adb0-4a86-b36f-231cb412d112@default> <20121004201848.GA26455@aepfle.de> In-Reply-To: <20121004201848.GA26455@aepfle.de> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7 (607090) [OL 12.0.6661.5003 (x86)] X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: Keir Fraser , Konrad Wilk , George Dunlap , Kurt Hackel , tim@xen.org, xen-devel@lists.xen.org, George Shuklin , Dario Faggioli , Andres Lagar-Cavilla , Ian Jackson Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > From: Olaf Hering [mailto:olaf@aepfle.de] > Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) > > On Thu, Oct 04, Dan Magenheimer wrote: > > > > From: Olaf Hering [mailto:olaf@aepfle.de] > > > Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) > > > > > > On Mon, Oct 01, Dan Magenheimer wrote: > > > > > > > Hi Olaf -- > > > > Thanks for the reply. > > > > > domain. All of this needs math, not locking. > > > : > > > As IanJ said, the memory handling code in libxl needs such a feature to > > > do the math right. The proposed handling of > > > sharing/paging/ballooning/PoD/tmem/... in libxl is just a small part of > > > it. > > > > Unfortunately, as you observe in some of the cases earlier in your reply, > > it is more than a math problem for libxl... it is a crystal ball problem. > > If xl launches a domain D at time T and it takes N seconds before it has > > completed asking the hypervisor for all of the memory M that D will require > > to successfully launch, then xl must determine at time T the maximum memory > > allocated across all running domains for the future time period between > > T and T+N. In other words, xl must predict the future. > > I think xl can predict it, if it takes the target of all domains into > account. Certainly not down to a handful pages, it would be good enough > to know if the calculated estimate of free memory is good for the new > guest and its specific memory targets. Well I don't know enough about the page-sharing implementation but it's not hard with tmem to synthesize a workload where the amount of free memory is half of RAM at time T and there is no RAM left at all at time T+(N/2) and three quarters of RAM is free at time T+N. That would be very hard for xl to predict. I expect that dramatic changes like this might be harder with page-sharing but not impossible. > > Clearly this is impossible especially when page-sharing is not communicating > > its dynamic allocations (e.g. due to page-splitting) to libxl, and tmem > > is not communicating allocations resulting from multiple domains > > simultaenously making tmem hypercalls to libxl, and PoD is not communicating > > its allocations to libxl, and in-guest-kernel selfballooning is not communicating > > allocations to libxl. Only the hypervisor is aware of every dynamic allocation > > request. > > The hypervisor can not predict the future either, and it has even less > info about the individual targets of each domain. The point is the hypervisor doesn't need to predict the future and doesn't need to know the individual targets. It just acts on allocation requests and, with the proposed design, on reservation requests. > > Does that make sense? > > It does, but: > If xl reserves the memory in its own "virtual allocator", or if Xen gets > such functionality, does not really matter, as long as its known how much > exactly needs to be allocated. I think that part is missing. I agree, though I think the only constraint is that the domain must be capable of booting. So if xl always requests a reservation of "mem=", I would think that should always work. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 20:36:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 20:36:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJs9b-0001fP-RZ; Thu, 04 Oct 2012 20:36:19 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJs9a-0001fK-OB for xen-devel@lists.xen.org; Thu, 04 Oct 2012 20:36:18 +0000 Received: from [85.158.143.99:52828] by server-2.bemta-4.messagelabs.com id 6A/37-06610-243FD605; Thu, 04 Oct 2012 20:36:18 +0000 X-Env-Sender: dan.magenheimer@oracle.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1349382976!26473662!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzgzMjE1\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29973 invoked from network); 4 Oct 2012 20:36:17 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Oct 2012 20:36:17 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q94Ka1YA017353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Oct 2012 20:36:02 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q94Ka0Ic012091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Oct 2012 20:36:00 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q94KZxKM003683; Thu, 4 Oct 2012 15:35:59 -0500 MIME-Version: 1.0 Message-ID: Date: Thu, 4 Oct 2012 13:35:53 -0700 (PDT) From: Dan Magenheimer To: Olaf Hering References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> <20121004182613.GA9244@aepfle.de> <18147469-adb0-4a86-b36f-231cb412d112@default> <20121004201848.GA26455@aepfle.de> In-Reply-To: <20121004201848.GA26455@aepfle.de> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7 (607090) [OL 12.0.6661.5003 (x86)] X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: Keir Fraser , Konrad Wilk , George Dunlap , Kurt Hackel , tim@xen.org, xen-devel@lists.xen.org, George Shuklin , Dario Faggioli , Andres Lagar-Cavilla , Ian Jackson Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > From: Olaf Hering [mailto:olaf@aepfle.de] > Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) > > On Thu, Oct 04, Dan Magenheimer wrote: > > > > From: Olaf Hering [mailto:olaf@aepfle.de] > > > Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) > > > > > > On Mon, Oct 01, Dan Magenheimer wrote: > > > > > > > Hi Olaf -- > > > > Thanks for the reply. > > > > > domain. All of this needs math, not locking. > > > : > > > As IanJ said, the memory handling code in libxl needs such a feature to > > > do the math right. The proposed handling of > > > sharing/paging/ballooning/PoD/tmem/... in libxl is just a small part of > > > it. > > > > Unfortunately, as you observe in some of the cases earlier in your reply, > > it is more than a math problem for libxl... it is a crystal ball problem. > > If xl launches a domain D at time T and it takes N seconds before it has > > completed asking the hypervisor for all of the memory M that D will require > > to successfully launch, then xl must determine at time T the maximum memory > > allocated across all running domains for the future time period between > > T and T+N. In other words, xl must predict the future. > > I think xl can predict it, if it takes the target of all domains into > account. Certainly not down to a handful pages, it would be good enough > to know if the calculated estimate of free memory is good for the new > guest and its specific memory targets. Well I don't know enough about the page-sharing implementation but it's not hard with tmem to synthesize a workload where the amount of free memory is half of RAM at time T and there is no RAM left at all at time T+(N/2) and three quarters of RAM is free at time T+N. That would be very hard for xl to predict. I expect that dramatic changes like this might be harder with page-sharing but not impossible. > > Clearly this is impossible especially when page-sharing is not communicating > > its dynamic allocations (e.g. due to page-splitting) to libxl, and tmem > > is not communicating allocations resulting from multiple domains > > simultaenously making tmem hypercalls to libxl, and PoD is not communicating > > its allocations to libxl, and in-guest-kernel selfballooning is not communicating > > allocations to libxl. Only the hypervisor is aware of every dynamic allocation > > request. > > The hypervisor can not predict the future either, and it has even less > info about the individual targets of each domain. The point is the hypervisor doesn't need to predict the future and doesn't need to know the individual targets. It just acts on allocation requests and, with the proposed design, on reservation requests. > > Does that make sense? > > It does, but: > If xl reserves the memory in its own "virtual allocator", or if Xen gets > such functionality, does not really matter, as long as its known how much > exactly needs to be allocated. I think that part is missing. I agree, though I think the only constraint is that the domain must be capable of booting. So if xl always requests a reservation of "mem=", I would think that should always work. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 21:06:39 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 21:06:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJscG-0002I8-Vr; Thu, 04 Oct 2012 21:05:56 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJscF-0002I3-K4 for xen-devel@lists.xensource.com; Thu, 04 Oct 2012 21:05:55 +0000 Received: from [85.158.143.35:46033] by server-3.bemta-4.messagelabs.com id 6A/75-10986-23AFD605; Thu, 04 Oct 2012 21:05:54 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1349384753!4001806!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13374 invoked from network); 4 Oct 2012 21:05:53 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 21:05:53 -0000 X-IronPort-AV: E=Sophos;i="4.80,537,1344211200"; d="scan'208";a="14950645" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 21:05:47 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 22:05:47 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TJsc6-0000TY-RA; Thu, 04 Oct 2012 21:05:46 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1TJsc6-0007Xo-6U; Thu, 04 Oct 2012 22:05:46 +0100 To: Message-ID: From: xen.org Date: Thu, 4 Oct 2012 22:05:46 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 13921: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 13921 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13921/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 5 xen-boot fail like 13918 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail like 13918 test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail like 13918 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail like 13918 Tests which did not succeed, but are not blocking: test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: xen 72d89cc43c72 baseline version: xen 572821a5682b ------------------------------------------------------------ People who touched revisions under test: Jan Beulich Keir Fraser ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-amd64-amd64-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable + revision=72d89cc43c72 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 72d89cc43c72 + branch=xen-unstable + revision=72d89cc43c72 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + . cri-common ++ umask 002 + select_xenbranch + case "$branch" in + tree=xen + xenbranch=xen-unstable + '[' xxen = xlinux ']' + linuxbranch=linux + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg ++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.xen-unstable ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git ++ : daily-cron.xen-unstable + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git + info_linux_tree xen-unstable + case $1 in + return 1 + case "$branch" in + cd /export/home/osstest/repos/xen-unstable.hg + hg push -r 72d89cc43c72 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 3 changesets with 6 changes to 6 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 21:06:39 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 21:06:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJscG-0002I8-Vr; Thu, 04 Oct 2012 21:05:56 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJscF-0002I3-K4 for xen-devel@lists.xensource.com; Thu, 04 Oct 2012 21:05:55 +0000 Received: from [85.158.143.35:46033] by server-3.bemta-4.messagelabs.com id 6A/75-10986-23AFD605; Thu, 04 Oct 2012 21:05:54 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1349384753!4001806!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13374 invoked from network); 4 Oct 2012 21:05:53 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2012 21:05:53 -0000 X-IronPort-AV: E=Sophos;i="4.80,537,1344211200"; d="scan'208";a="14950645" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Oct 2012 21:05:47 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Oct 2012 22:05:47 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TJsc6-0000TY-RA; Thu, 04 Oct 2012 21:05:46 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1TJsc6-0007Xo-6U; Thu, 04 Oct 2012 22:05:46 +0100 To: Message-ID: From: xen.org Date: Thu, 4 Oct 2012 22:05:46 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 13921: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 13921 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13921/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 5 xen-boot fail like 13918 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail like 13918 test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail like 13918 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail like 13918 Tests which did not succeed, but are not blocking: test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: xen 72d89cc43c72 baseline version: xen 572821a5682b ------------------------------------------------------------ People who touched revisions under test: Jan Beulich Keir Fraser ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-amd64-amd64-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable + revision=72d89cc43c72 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 72d89cc43c72 + branch=xen-unstable + revision=72d89cc43c72 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + . cri-common ++ umask 002 + select_xenbranch + case "$branch" in + tree=xen + xenbranch=xen-unstable + '[' xxen = xlinux ']' + linuxbranch=linux + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg ++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.xen-unstable ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git ++ : daily-cron.xen-unstable + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git + info_linux_tree xen-unstable + case $1 in + return 1 + case "$branch" in + cd /export/home/osstest/repos/xen-unstable.hg + hg push -r 72d89cc43c72 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 3 changesets with 6 changes to 6 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 22:30:37 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 22:30:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJtvi-0003dW-Dd; Thu, 04 Oct 2012 22:30:06 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJtvh-0003dR-71 for xen-devel@lists.xen.org; Thu, 04 Oct 2012 22:30:05 +0000 Received: from [85.158.138.51:26549] by server-15.bemta-3.messagelabs.com id 19/B1-11584-CED0E605; Thu, 04 Oct 2012 22:30:04 +0000 X-Env-Sender: jfehlig@suse.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1349389801!24270814!1 X-Originating-IP: [137.65.248.97] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1734 invoked from network); 4 Oct 2012 22:30:03 -0000 Received: from novprvoes0314.provo.novell.com (HELO mail.novell.com) (137.65.248.97) by server-7.tower-174.messagelabs.com with SMTP; 4 Oct 2012 22:30:03 -0000 Received: from [137.65.223.23] ([::ffff:137.65.223.23]) by mail.novell.com with ESMTP; Thu, 04 Oct 2012 16:29:54 -0600 Message-ID: <506E0DE1.7@suse.com> Date: Thu, 04 Oct 2012 16:29:53 -0600 From: Jim Fehlig User-Agent: Thunderbird 2.0.0.18 (X11/20081112) MIME-Version: 1.0 To: Ian Campbell References: <201209191918.35305.hahn@univention.de> <201209201340.52218.hahn@univention.de> <505B88A1.1070701@suse.com> <505C4A82.2040305@eu.citrix.com> <50626355.7080402@suse.com> <1349339644.650.217.camel@zakaz.uk.xensource.com> In-Reply-To: <1349339644.650.217.camel@zakaz.uk.xensource.com> Cc: George Dunlap , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Xen 4.3 development update X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Campbell wrote: > BTW, I've been meaning to ask, and it's kind of the flipside of this so > I'll mention it here -- would it be possible for you (or whoever is > sending patches) to CC xen-devel with Xen related patches to libvirt? > Sure. > Partly just to raise the visibility of the libvirt integration on the > Xen side but also at least I am interested to see how libxl is being > used outside of xl and what sorts of issues etc you guys are having. I > suppose there would also be other benefits to review from libxl folks of > patches which consume the APIs. > Agreed. You could set us straight on any misuse of the API :). Regards, Jim _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Thu Oct 04 22:30:37 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Oct 2012 22:30:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJtvi-0003dW-Dd; Thu, 04 Oct 2012 22:30:06 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJtvh-0003dR-71 for xen-devel@lists.xen.org; Thu, 04 Oct 2012 22:30:05 +0000 Received: from [85.158.138.51:26549] by server-15.bemta-3.messagelabs.com id 19/B1-11584-CED0E605; Thu, 04 Oct 2012 22:30:04 +0000 X-Env-Sender: jfehlig@suse.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1349389801!24270814!1 X-Originating-IP: [137.65.248.97] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1734 invoked from network); 4 Oct 2012 22:30:03 -0000 Received: from novprvoes0314.provo.novell.com (HELO mail.novell.com) (137.65.248.97) by server-7.tower-174.messagelabs.com with SMTP; 4 Oct 2012 22:30:03 -0000 Received: from [137.65.223.23] ([::ffff:137.65.223.23]) by mail.novell.com with ESMTP; Thu, 04 Oct 2012 16:29:54 -0600 Message-ID: <506E0DE1.7@suse.com> Date: Thu, 04 Oct 2012 16:29:53 -0600 From: Jim Fehlig User-Agent: Thunderbird 2.0.0.18 (X11/20081112) MIME-Version: 1.0 To: Ian Campbell References: <201209191918.35305.hahn@univention.de> <201209201340.52218.hahn@univention.de> <505B88A1.1070701@suse.com> <505C4A82.2040305@eu.citrix.com> <50626355.7080402@suse.com> <1349339644.650.217.camel@zakaz.uk.xensource.com> In-Reply-To: <1349339644.650.217.camel@zakaz.uk.xensource.com> Cc: George Dunlap , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Xen 4.3 development update X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Campbell wrote: > BTW, I've been meaning to ask, and it's kind of the flipside of this so > I'll mention it here -- would it be possible for you (or whoever is > sending patches) to CC xen-devel with Xen related patches to libvirt? > Sure. > Partly just to raise the visibility of the libvirt integration on the > Xen side but also at least I am interested to see how libxl is being > used outside of xl and what sorts of issues etc you guys are having. I > suppose there would also be other benefits to review from libxl folks of > patches which consume the APIs. > Agreed. You could set us straight on any misuse of the API :). Regards, Jim _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 00:51:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 00:51:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJw7b-000516-0E; Fri, 05 Oct 2012 00:50:31 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJw7Y-000511-Sr for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 00:50:29 +0000 Received: from [85.158.143.99:56982] by server-2.bemta-4.messagelabs.com id EC/DD-06610-4DE2E605; Fri, 05 Oct 2012 00:50:28 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1349398220!26673511!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5805 invoked from network); 5 Oct 2012 00:50:26 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 00:50:26 -0000 X-IronPort-AV: E=Sophos;i="4.80,537,1344211200"; d="scan'208";a="14952608" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 00:49:54 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 01:49:54 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TJw6z-0002iB-Vt; Fri, 05 Oct 2012 00:49:54 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1TJw6z-0002JY-JH; Fri, 05 Oct 2012 01:49:53 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Fri, 5 Oct 2012 01:49:53 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.2-testing test] 13922: tolerable trouble: broken/fail/pass - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 13922 xen-4.2-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13922/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-i386-i386-xl-win 3 host-install(3) broken pass in 13920 test-amd64-amd64-pv 9 guest-start fail in 13920 pass in 13922 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-i386-i386-xl-qemuu-winxpsp3 9 guest-localmigrate fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail in 13920 never pass version targeted for testing: xen a69c8e5c4afc baseline version: xen ca3e8190a72c ------------------------------------------------------------ People who touched revisions under test: Ben Guthro Daniel De Graaf Ian Campbell Ian Jackson Jan Beulich Keir Fraser ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win broken test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-4.2-testing + revision=a69c8e5c4afc + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.2-testing a69c8e5c4afc + branch=xen-4.2-testing + revision=a69c8e5c4afc + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + . cri-common ++ umask 002 + select_xenbranch + case "$branch" in + tree=xen + xenbranch=xen-4.2-testing + '[' xxen = xlinux ']' + linuxbranch=linux + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : http://xenbits.xen.org/hg/staging/xen-4.2-testing.hg ++ : git://xenbits.xen.org/staging/qemu-xen-4.2-testing.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.xen-4.2-testing ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-4.2-testing.git ++ : daily-cron.xen-4.2-testing + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.2-testing.git + info_linux_tree xen-4.2-testing + case $1 in + return 1 + case "$branch" in + cd /export/home/osstest/repos/xen-4.2-testing.hg + hg push -r a69c8e5c4afc ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 7 changesets with 13 changes to 12 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 00:51:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 00:51:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJw7b-000516-0E; Fri, 05 Oct 2012 00:50:31 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJw7Y-000511-Sr for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 00:50:29 +0000 Received: from [85.158.143.99:56982] by server-2.bemta-4.messagelabs.com id EC/DD-06610-4DE2E605; Fri, 05 Oct 2012 00:50:28 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1349398220!26673511!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNjA=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5805 invoked from network); 5 Oct 2012 00:50:26 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 00:50:26 -0000 X-IronPort-AV: E=Sophos;i="4.80,537,1344211200"; d="scan'208";a="14952608" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 00:49:54 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 01:49:54 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TJw6z-0002iB-Vt; Fri, 05 Oct 2012 00:49:54 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1TJw6z-0002JY-JH; Fri, 05 Oct 2012 01:49:53 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Fri, 5 Oct 2012 01:49:53 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.2-testing test] 13922: tolerable trouble: broken/fail/pass - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 13922 xen-4.2-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13922/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-i386-i386-xl-win 3 host-install(3) broken pass in 13920 test-amd64-amd64-pv 9 guest-start fail in 13920 pass in 13922 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-i386-i386-xl-qemuu-winxpsp3 9 guest-localmigrate fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail in 13920 never pass version targeted for testing: xen a69c8e5c4afc baseline version: xen ca3e8190a72c ------------------------------------------------------------ People who touched revisions under test: Ben Guthro Daniel De Graaf Ian Campbell Ian Jackson Jan Beulich Keir Fraser ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win broken test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-4.2-testing + revision=a69c8e5c4afc + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.2-testing a69c8e5c4afc + branch=xen-4.2-testing + revision=a69c8e5c4afc + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + . cri-common ++ umask 002 + select_xenbranch + case "$branch" in + tree=xen + xenbranch=xen-4.2-testing + '[' xxen = xlinux ']' + linuxbranch=linux + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : http://xenbits.xen.org/hg/staging/xen-4.2-testing.hg ++ : git://xenbits.xen.org/staging/qemu-xen-4.2-testing.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.xen-4.2-testing ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-4.2-testing.git ++ : daily-cron.xen-4.2-testing + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.2-testing.git + info_linux_tree xen-4.2-testing + case $1 in + return 1 + case "$branch" in + cd /export/home/osstest/repos/xen-4.2-testing.hg + hg push -r a69c8e5c4afc ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 7 changesets with 13 changes to 12 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 01:17:57 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 01:17:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJwXg-0000uM-HX; Fri, 05 Oct 2012 01:17:28 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJwXe-0000uH-3c for Xen-devel@lists.xensource.com; Fri, 05 Oct 2012 01:17:26 +0000 Received: from [85.158.139.83:42531] by server-14.bemta-5.messagelabs.com id 6C/CC-31065-5253E605; Fri, 05 Oct 2012 01:17:25 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1349399842!32824339!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzgzMjE1\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29064 invoked from network); 5 Oct 2012 01:17:24 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 01:17:24 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q951HFsg020347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Oct 2012 01:17:16 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q951HEgP009186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Oct 2012 01:17:15 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q951HEDr026150; Thu, 4 Oct 2012 20:17:14 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 04 Oct 2012 18:17:14 -0700 Date: Thu, 4 Oct 2012 18:17:12 -0700 From: Mukesh Rathor To: Ian Campbell Message-ID: <20121004181712.604bcf3e@mantra.us.oracle.com> In-Reply-To: <1349339496.650.216.camel@zakaz.uk.xensource.com> References: <20120921121556.1a0ea8af@mantra.us.oracle.com> <1349278963.650.164.camel@zakaz.uk.xensource.com> <20121003152925.5af3a658@mantra.us.oracle.com> <1349339496.650.216.camel@zakaz.uk.xensource.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 4 Oct 2012 09:31:36 +0100 Ian Campbell wrote: > On Wed, 2012-10-03 at 23:29 +0100, Mukesh Rathor wrote: > > On Wed, 3 Oct 2012 16:42:43 +0100 > > Ian Campbell wrote: > > > > > > > > > diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h > > > > index 6a198e4..6c5ad83 100644 > > > > --- a/include/xen/xen-ops.h > > > > +++ b/include/xen/xen-ops.h > > > > @@ -24,9 +24,19 @@ int xen_create_contiguous_region(unsigned > > > > long vstart, unsigned int order, void > > > > xen_destroy_contiguous_region(unsigned long vstart, unsigned int > > > > order); struct vm_area_struct; > > > > +struct xen_pvh_pfn_info; > > > > > > If you move the struct def'n up you don't need this forward decl. > > > > > > > int xen_remap_domain_mfn_range(struct vm_area_struct *vma, > > > > unsigned long addr, > > > > unsigned long mfn, int nr, > > > > - pgprot_t prot, unsigned domid); > > > > + pgprot_t prot, unsigned domid, > > > > + struct xen_pvh_pfn_info *pvhp); > > > > +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma, > > > > + struct xen_pvh_pfn_info *pvhp); > > > > + > > > > +struct xen_pvh_pfn_info { > > > > > > Can we call this xen_remap_mfn_info or something? PVH is x86 > > > specific while this struct is also useful on ARM. > > > > I already renamed it to: xen_xlat_pfn_info. > > BTW, where can I find you latest patches? In my local tree here. Will be submitting v3 soon. > I've just noticed that you've not been CCing LKML with this series -- > was that deliberate? I was told I didn't need to since there is no common code change. thanks Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 01:17:57 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 01:17:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJwXg-0000uM-HX; Fri, 05 Oct 2012 01:17:28 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJwXe-0000uH-3c for Xen-devel@lists.xensource.com; Fri, 05 Oct 2012 01:17:26 +0000 Received: from [85.158.139.83:42531] by server-14.bemta-5.messagelabs.com id 6C/CC-31065-5253E605; Fri, 05 Oct 2012 01:17:25 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1349399842!32824339!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzgzMjE1\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29064 invoked from network); 5 Oct 2012 01:17:24 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 01:17:24 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q951HFsg020347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Oct 2012 01:17:16 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q951HEgP009186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Oct 2012 01:17:15 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q951HEDr026150; Thu, 4 Oct 2012 20:17:14 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 04 Oct 2012 18:17:14 -0700 Date: Thu, 4 Oct 2012 18:17:12 -0700 From: Mukesh Rathor To: Ian Campbell Message-ID: <20121004181712.604bcf3e@mantra.us.oracle.com> In-Reply-To: <1349339496.650.216.camel@zakaz.uk.xensource.com> References: <20120921121556.1a0ea8af@mantra.us.oracle.com> <1349278963.650.164.camel@zakaz.uk.xensource.com> <20121003152925.5af3a658@mantra.us.oracle.com> <1349339496.650.216.camel@zakaz.uk.xensource.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 4 Oct 2012 09:31:36 +0100 Ian Campbell wrote: > On Wed, 2012-10-03 at 23:29 +0100, Mukesh Rathor wrote: > > On Wed, 3 Oct 2012 16:42:43 +0100 > > Ian Campbell wrote: > > > > > > > > > diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h > > > > index 6a198e4..6c5ad83 100644 > > > > --- a/include/xen/xen-ops.h > > > > +++ b/include/xen/xen-ops.h > > > > @@ -24,9 +24,19 @@ int xen_create_contiguous_region(unsigned > > > > long vstart, unsigned int order, void > > > > xen_destroy_contiguous_region(unsigned long vstart, unsigned int > > > > order); struct vm_area_struct; > > > > +struct xen_pvh_pfn_info; > > > > > > If you move the struct def'n up you don't need this forward decl. > > > > > > > int xen_remap_domain_mfn_range(struct vm_area_struct *vma, > > > > unsigned long addr, > > > > unsigned long mfn, int nr, > > > > - pgprot_t prot, unsigned domid); > > > > + pgprot_t prot, unsigned domid, > > > > + struct xen_pvh_pfn_info *pvhp); > > > > +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma, > > > > + struct xen_pvh_pfn_info *pvhp); > > > > + > > > > +struct xen_pvh_pfn_info { > > > > > > Can we call this xen_remap_mfn_info or something? PVH is x86 > > > specific while this struct is also useful on ARM. > > > > I already renamed it to: xen_xlat_pfn_info. > > BTW, where can I find you latest patches? In my local tree here. Will be submitting v3 soon. > I've just noticed that you've not been CCing LKML with this series -- > was that deliberate? I was told I didn't need to since there is no common code change. thanks Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 01:25:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 01:25:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJwfT-000154-1D; Fri, 05 Oct 2012 01:25:31 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJwfR-00014z-FS for Xen-devel@lists.xensource.com; Fri, 05 Oct 2012 01:25:29 +0000 Received: from [85.158.143.99:31871] by server-2.bemta-4.messagelabs.com id 2C/CA-06610-8073E605; Fri, 05 Oct 2012 01:25:28 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1349400326!32914384!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzg0NjMy\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20902 invoked from network); 5 Oct 2012 01:25:28 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 01:25:28 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q951PLHI024848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Oct 2012 01:25:21 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q951PKkA028197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Oct 2012 01:25:20 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q951PJVX027650; Thu, 4 Oct 2012 20:25:20 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 04 Oct 2012 18:25:19 -0700 Date: Thu, 4 Oct 2012 18:25:18 -0700 From: Mukesh Rathor To: Ian Campbell Message-ID: <20121004182518.76e9624a@mantra.us.oracle.com> In-Reply-To: <1349339920.650.220.camel@zakaz.uk.xensource.com> References: <20120921121659.5a723de9@mantra.us.oracle.com> <20120924154335.097d3fb9@mantra.us.oracle.com> <20120925180416.0137d61a@mantra.us.oracle.com> <20121002183619.70734b7a@mantra.us.oracle.com> <20121002190323.2e16f6ff@mantra.us.oracle.com> <20121003153714.4656b7e9@mantra.us.oracle.com> <1349339920.650.220.camel@zakaz.uk.xensource.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "Xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v1 3/8]: PVH startup changes (enlighten.c) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 4 Oct 2012 09:38:40 +0100 Ian Campbell wrote: > On Wed, 2012-10-03 at 23:37 +0100, Mukesh Rathor wrote: > > On Wed, 3 Oct 2012 12:58:22 +0100 > > Ok, finally, focussing on this, the issue with pfn in dom0 is that > > I need pfn allocated in construct_dom0() and be mapped so that the > > guest can just do : > > > > HYPERVISOR_shared_info=(struct shared_info > > *)__va(xen_start_info->shared_info); > > > > How about following I am experimenting with right now: > > > > in construct_dom0(): > > > > vstartinfo_end = (vstartinfo_start + > > sizeof(struct start_info) + > > sizeof(struct dom0_vga_console_info)); > > > > if ( is_hybrid_domain(d) ) { > > start_info_pfn_addr = round_pgup(vstartinfo_end) - v_start; > > vstartinfo_end += PAGE_SIZE; > > } > > > > I can then put (PFN: start_info_pfn_addr)->(MFN: > > virt_to_maddr(d->shared_info)) in the p2m, and dom0 just has to do > > __va(), like domU does now. I wont' need to special case dom0 then. > > > > Do you foresee any problems with this approach? > > Hard to say without all the surrounding context but it seems plausible > to me. Ok, above works. So no dom0 special case in linux now to map shared_page. thanks Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 01:25:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 01:25:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJwfT-000154-1D; Fri, 05 Oct 2012 01:25:31 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJwfR-00014z-FS for Xen-devel@lists.xensource.com; Fri, 05 Oct 2012 01:25:29 +0000 Received: from [85.158.143.99:31871] by server-2.bemta-4.messagelabs.com id 2C/CA-06610-8073E605; Fri, 05 Oct 2012 01:25:28 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1349400326!32914384!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzg0NjMy\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20902 invoked from network); 5 Oct 2012 01:25:28 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 01:25:28 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q951PLHI024848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Oct 2012 01:25:21 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q951PKkA028197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Oct 2012 01:25:20 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q951PJVX027650; Thu, 4 Oct 2012 20:25:20 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 04 Oct 2012 18:25:19 -0700 Date: Thu, 4 Oct 2012 18:25:18 -0700 From: Mukesh Rathor To: Ian Campbell Message-ID: <20121004182518.76e9624a@mantra.us.oracle.com> In-Reply-To: <1349339920.650.220.camel@zakaz.uk.xensource.com> References: <20120921121659.5a723de9@mantra.us.oracle.com> <20120924154335.097d3fb9@mantra.us.oracle.com> <20120925180416.0137d61a@mantra.us.oracle.com> <20121002183619.70734b7a@mantra.us.oracle.com> <20121002190323.2e16f6ff@mantra.us.oracle.com> <20121003153714.4656b7e9@mantra.us.oracle.com> <1349339920.650.220.camel@zakaz.uk.xensource.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "Xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v1 3/8]: PVH startup changes (enlighten.c) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 4 Oct 2012 09:38:40 +0100 Ian Campbell wrote: > On Wed, 2012-10-03 at 23:37 +0100, Mukesh Rathor wrote: > > On Wed, 3 Oct 2012 12:58:22 +0100 > > Ok, finally, focussing on this, the issue with pfn in dom0 is that > > I need pfn allocated in construct_dom0() and be mapped so that the > > guest can just do : > > > > HYPERVISOR_shared_info=(struct shared_info > > *)__va(xen_start_info->shared_info); > > > > How about following I am experimenting with right now: > > > > in construct_dom0(): > > > > vstartinfo_end = (vstartinfo_start + > > sizeof(struct start_info) + > > sizeof(struct dom0_vga_console_info)); > > > > if ( is_hybrid_domain(d) ) { > > start_info_pfn_addr = round_pgup(vstartinfo_end) - v_start; > > vstartinfo_end += PAGE_SIZE; > > } > > > > I can then put (PFN: start_info_pfn_addr)->(MFN: > > virt_to_maddr(d->shared_info)) in the p2m, and dom0 just has to do > > __va(), like domU does now. I wont' need to special case dom0 then. > > > > Do you foresee any problems with this approach? > > Hard to say without all the surrounding context but it seems plausible > to me. Ok, above works. So no dom0 special case in linux now to map shared_page. thanks Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 01:36:03 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 01:36:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJwpJ-0001LQ-4R; Fri, 05 Oct 2012 01:35:41 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJwpH-0001LL-Hs for Xen-devel@lists.xensource.com; Fri, 05 Oct 2012 01:35:39 +0000 Received: from [85.158.137.99:51381] by server-2.bemta-3.messagelabs.com id 60/35-16514-A693E605; Fri, 05 Oct 2012 01:35:38 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-4.tower-217.messagelabs.com!1349400936!20357396!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc5NDYyMA==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31567 invoked from network); 5 Oct 2012 01:35:37 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-4.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 01:35:37 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q951ZUJ3001776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Oct 2012 01:35:31 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q951ZT0O017380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Oct 2012 01:35:30 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q951ZT5c001620; Thu, 4 Oct 2012 20:35:29 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 04 Oct 2012 18:35:29 -0700 Date: Thu, 4 Oct 2012 18:35:28 -0700 From: Mukesh Rathor To: Ian Campbell Message-ID: <20121004183528.060416a0@mantra.us.oracle.com> In-Reply-To: <1349265914.650.136.camel@zakaz.uk.xensource.com> References: <20120921121659.5a723de9@mantra.us.oracle.com> <20120924154335.097d3fb9@mantra.us.oracle.com> <20120925180416.0137d61a@mantra.us.oracle.com> <20121002183619.70734b7a@mantra.us.oracle.com> <20121002190323.2e16f6ff@mantra.us.oracle.com> <1349265914.650.136.camel@zakaz.uk.xensource.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "Xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v1 3/8]: PVH startup changes (enlighten.c) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 3 Oct 2012 13:05:14 +0100 Ian Campbell wrote: > On Wed, 2012-10-03 at 12:58 +0100, Stefano Stabellini wrote: > > > So for now, how about, lets go > > > with what I've got. I'll make a note, and when I do xen patch, > > > I'll figure it out, and would be a very small linux patch. I want > > > to get linux patch in soon before the window closes. > > > > We can leave page special as it is for now with very little > > consequences, because it is not part of the interface with Xen. > > However this is part of the interface, so whatever we choose here > > is going to be hard to change later on. > > I suggested that until we have seen and reviewed the hypervisor side > patches this guest side functionality all needs to be under an option > which has CONFIG_EXPERIMENTAL as a dependency and a comment explaining > that the ABI is not fixed yet, similar to what we did for the ARM > port. Konrad is going to keep the changes in his tree and not upstream for couple months while we go thru the xen patches. This would be a big help for me as I won't have to constantly refresh linux tree. I hope we can get some baseline in linux and xen soon. thanks Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 01:36:03 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 01:36:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJwpJ-0001LQ-4R; Fri, 05 Oct 2012 01:35:41 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJwpH-0001LL-Hs for Xen-devel@lists.xensource.com; Fri, 05 Oct 2012 01:35:39 +0000 Received: from [85.158.137.99:51381] by server-2.bemta-3.messagelabs.com id 60/35-16514-A693E605; Fri, 05 Oct 2012 01:35:38 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-4.tower-217.messagelabs.com!1349400936!20357396!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc5NDYyMA==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31567 invoked from network); 5 Oct 2012 01:35:37 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-4.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 01:35:37 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q951ZUJ3001776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Oct 2012 01:35:31 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q951ZT0O017380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Oct 2012 01:35:30 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q951ZT5c001620; Thu, 4 Oct 2012 20:35:29 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 04 Oct 2012 18:35:29 -0700 Date: Thu, 4 Oct 2012 18:35:28 -0700 From: Mukesh Rathor To: Ian Campbell Message-ID: <20121004183528.060416a0@mantra.us.oracle.com> In-Reply-To: <1349265914.650.136.camel@zakaz.uk.xensource.com> References: <20120921121659.5a723de9@mantra.us.oracle.com> <20120924154335.097d3fb9@mantra.us.oracle.com> <20120925180416.0137d61a@mantra.us.oracle.com> <20121002183619.70734b7a@mantra.us.oracle.com> <20121002190323.2e16f6ff@mantra.us.oracle.com> <1349265914.650.136.camel@zakaz.uk.xensource.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "Xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v1 3/8]: PVH startup changes (enlighten.c) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 3 Oct 2012 13:05:14 +0100 Ian Campbell wrote: > On Wed, 2012-10-03 at 12:58 +0100, Stefano Stabellini wrote: > > > So for now, how about, lets go > > > with what I've got. I'll make a note, and when I do xen patch, > > > I'll figure it out, and would be a very small linux patch. I want > > > to get linux patch in soon before the window closes. > > > > We can leave page special as it is for now with very little > > consequences, because it is not part of the interface with Xen. > > However this is part of the interface, so whatever we choose here > > is going to be hard to change later on. > > I suggested that until we have seen and reviewed the hypervisor side > patches this guest side functionality all needs to be under an option > which has CONFIG_EXPERIMENTAL as a dependency and a comment explaining > that the ABI is not fixed yet, similar to what we did for the ARM > port. Konrad is going to keep the changes in his tree and not upstream for couple months while we go thru the xen patches. This would be a big help for me as I won't have to constantly refresh linux tree. I hope we can get some baseline in linux and xen soon. thanks Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 01:51:48 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 01:51:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJx4X-0001Vj-LC; Fri, 05 Oct 2012 01:51:25 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJx4W-0001Ve-Js for Xen-devel@lists.xensource.com; Fri, 05 Oct 2012 01:51:24 +0000 Received: from [85.158.139.211:41434] by server-2.bemta-5.messagelabs.com id 19/4F-28944-A1D3E605; Fri, 05 Oct 2012 01:51:22 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-7.tower-206.messagelabs.com!1349401880!20687014!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc5NDYyMA==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27073 invoked from network); 5 Oct 2012 01:51:21 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 01:51:21 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q951pEp1010710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Oct 2012 01:51:14 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q951pD0r000682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Oct 2012 01:51:13 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q951pDQ9006720; Thu, 4 Oct 2012 20:51:13 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 04 Oct 2012 18:51:12 -0700 Date: Thu, 4 Oct 2012 18:51:11 -0700 From: Mukesh Rathor To: Ian Campbell Message-ID: <20121004185111.2742dd65@mantra.us.oracle.com> In-Reply-To: <1349358887.866.40.camel@zakaz.uk.xensource.com> References: <20120921121556.1a0ea8af@mantra.us.oracle.com> <1349358887.866.40.camel@zakaz.uk.xensource.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "Xen-devel@lists.xensource.com" , Tim Deegan , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 4 Oct 2012 14:54:47 +0100 Ian Campbell wrote: > On Fri, 2012-09-21 at 20:15 +0100, Mukesh Rathor wrote: > > > > +int pvh_rem_xen_p2m(unsigned long spfn, int count) > > +{ > > + struct xen_remove_from_physmap xrp; > > + int i, rc; > > + > > + for (i=0; i < count; i++) { > > + xrp.domid = DOMID_SELF; > > + xrp.gpfn = spfn+i; > > + rc = > > HYPERVISOR_memory_op(XENMEM_remove_from_physmap, &xrp); > > It seems that the current implementation of this hypercall in the h/v > doesn't handle unmapping of foreign pages, since it requires that the > page be owned by the domain whose P2M it is manipulating. > > How did you fix this on the hypervisor side? I'd like to make sure I > do things consistently on the ARM side. > > Talking with Tim it seems like having foreign mappings in a p2m is a > bit tricky and needs a bit of careful thought WRT reference counting > etc. Hey Ian, This is what I've (don't worry about "hybrid" word for now, i'll fix it): casee XENMEM_remove_from_physmap: { struct xen_remove_from_physmap xrfp; struct page_info *page; struct domain *d; p2m_type_t p2mt; if ( copy_from_guest(&xrfp, arg, 1) ) return -EFAULT; rc = rcu_lock_target_domain_by_id(xrfp.domid, &d); if ( rc != 0 ) return rc; if ( xsm_remove_from_physmap(current->domain, d) ) { rcu_unlock_domain(d); return -EPERM; } domain_lock(d); page = get_page_from_gfn(d, xrfp.gpfn, &p2mt, P2M_ALLOC); if ( page || (is_hybrid_vcpu(current) && (p2m_is_mmio(p2mt) || p2m_is_foreign(p2mt))) ) { unsigned long argmfn = page ? page_to_mfn(page) : INVALID_MFN; guest_physmap_remove_page(d, xrfp.gpfn, argmfn, 0); if (page) put_page(page); } else { if ( is_hybrid_vcpu(current) ) gdprintk(XENLOG_WARNING, "%s: Domain:%u gmfn:%lx invalid\n", __FUNCTION__, current->domain->domain_id, xrfp.gpfn); rc = -ENOENT; } domain_unlock(d); rcu_unlock_domain(d); break; } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 01:51:48 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 01:51:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJx4X-0001Vj-LC; Fri, 05 Oct 2012 01:51:25 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJx4W-0001Ve-Js for Xen-devel@lists.xensource.com; Fri, 05 Oct 2012 01:51:24 +0000 Received: from [85.158.139.211:41434] by server-2.bemta-5.messagelabs.com id 19/4F-28944-A1D3E605; Fri, 05 Oct 2012 01:51:22 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-7.tower-206.messagelabs.com!1349401880!20687014!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc5NDYyMA==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27073 invoked from network); 5 Oct 2012 01:51:21 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 01:51:21 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q951pEp1010710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Oct 2012 01:51:14 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q951pD0r000682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Oct 2012 01:51:13 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q951pDQ9006720; Thu, 4 Oct 2012 20:51:13 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 04 Oct 2012 18:51:12 -0700 Date: Thu, 4 Oct 2012 18:51:11 -0700 From: Mukesh Rathor To: Ian Campbell Message-ID: <20121004185111.2742dd65@mantra.us.oracle.com> In-Reply-To: <1349358887.866.40.camel@zakaz.uk.xensource.com> References: <20120921121556.1a0ea8af@mantra.us.oracle.com> <1349358887.866.40.camel@zakaz.uk.xensource.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "Xen-devel@lists.xensource.com" , Tim Deegan , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 4 Oct 2012 14:54:47 +0100 Ian Campbell wrote: > On Fri, 2012-09-21 at 20:15 +0100, Mukesh Rathor wrote: > > > > +int pvh_rem_xen_p2m(unsigned long spfn, int count) > > +{ > > + struct xen_remove_from_physmap xrp; > > + int i, rc; > > + > > + for (i=0; i < count; i++) { > > + xrp.domid = DOMID_SELF; > > + xrp.gpfn = spfn+i; > > + rc = > > HYPERVISOR_memory_op(XENMEM_remove_from_physmap, &xrp); > > It seems that the current implementation of this hypercall in the h/v > doesn't handle unmapping of foreign pages, since it requires that the > page be owned by the domain whose P2M it is manipulating. > > How did you fix this on the hypervisor side? I'd like to make sure I > do things consistently on the ARM side. > > Talking with Tim it seems like having foreign mappings in a p2m is a > bit tricky and needs a bit of careful thought WRT reference counting > etc. Hey Ian, This is what I've (don't worry about "hybrid" word for now, i'll fix it): casee XENMEM_remove_from_physmap: { struct xen_remove_from_physmap xrfp; struct page_info *page; struct domain *d; p2m_type_t p2mt; if ( copy_from_guest(&xrfp, arg, 1) ) return -EFAULT; rc = rcu_lock_target_domain_by_id(xrfp.domid, &d); if ( rc != 0 ) return rc; if ( xsm_remove_from_physmap(current->domain, d) ) { rcu_unlock_domain(d); return -EPERM; } domain_lock(d); page = get_page_from_gfn(d, xrfp.gpfn, &p2mt, P2M_ALLOC); if ( page || (is_hybrid_vcpu(current) && (p2m_is_mmio(p2mt) || p2m_is_foreign(p2mt))) ) { unsigned long argmfn = page ? page_to_mfn(page) : INVALID_MFN; guest_physmap_remove_page(d, xrfp.gpfn, argmfn, 0); if (page) put_page(page); } else { if ( is_hybrid_vcpu(current) ) gdprintk(XENLOG_WARNING, "%s: Domain:%u gmfn:%lx invalid\n", __FUNCTION__, current->domain->domain_id, xrfp.gpfn); rc = -ENOENT; } domain_unlock(d); rcu_unlock_domain(d); break; } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 02:11:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 02:11:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJxNx-000282-GG; Fri, 05 Oct 2012 02:11:29 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJxNw-00027x-0R for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 02:11:28 +0000 Received: from [85.158.143.99:26032] by server-1.bemta-4.messagelabs.com id 7B/0A-05684-FC14E605; Fri, 05 Oct 2012 02:11:27 +0000 X-Env-Sender: anthony@codemonkey.ws X-Msg-Ref: server-6.tower-216.messagelabs.com!1349403085!25926932!1 X-Originating-IP: [209.85.219.43] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8343 invoked from network); 5 Oct 2012 02:11:26 -0000 Received: from mail-oa0-f43.google.com (HELO mail-oa0-f43.google.com) (209.85.219.43) by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 02:11:26 -0000 Received: by mail-oa0-f43.google.com with SMTP id k1so1763334oag.30 for ; Thu, 04 Oct 2012 19:11:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version:content-type:x-gm-message-state; bh=s4S+jLcV0/WMoNM7B6fBdfQOO58nTZ/Jyq/hPvO5TO4=; b=o6mk5lJle3zWnRTrO+TDcj1ds/oth/8D9RCRK0AM0vFCH4eyWH+rtm/mF9qKbJ2yhR 4RKhCDB+LbcJobLjVjpzYDTtVD8lO5r/J6aZL2yOKR48odDL516atg6Gmqdby2pF63yR wf5dnOq5D8Di9l8MJa2Yv96ZRpE+yfwWLwazxAiCYXAD6TH/aCQY/5kPy2AjklCSG053 0TGl6vt4Zr3xS7lfX+SlvofayDBrJ8P9sgFpkZrhZepIYbdlvmEUkhFMd+37cqNUFHll HMwSA83PDYG69o8sOPaCuJ/jKiqL59jmJ/CW110YL7TMuYVP8gSiJiJO7VJa6oX4Qf2A en4g== Received: by 10.60.172.199 with SMTP id be7mr5866479oec.93.1349403084590; Thu, 04 Oct 2012 19:11:24 -0700 (PDT) Received: from titi.smtp.gmail.com (cpe-70-123-130-163.austin.res.rr.com. [70.123.130.163]) by mx.google.com with ESMTPS id n8sm6441923oec.5.2012.10.04.19.11.22 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Oct 2012 19:11:23 -0700 (PDT) From: Anthony Liguori To: Stefano Stabellini In-Reply-To: References: User-Agent: Notmuch/0.13.2+93~ged93d79 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu) Date: Thu, 04 Oct 2012 21:11:21 -0500 Message-ID: <87391thdme.fsf@codemonkey.ws> MIME-Version: 1.0 X-Gm-Message-State: ALoCoQl2NN2idiwMXP+yLu0LF3nSa3AsUYxzZ0fiLq4kp+DpDSgMTDvwKtzcFRyjRTH36lgUAwap Cc: Anthony.Perard@citrix.com, xen-devel@lists.xensource.com, Xudong Hao , qemu-devel@nongnu.org, Stefano Stabellini Subject: Re: [Xen-devel] [PULL] Xen tree 2012-10-03 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Stefano Stabellini writes: > Hi Anthony, > please pull from the following tree based on > e744c06fca438dc08271e626034e632a270c91c8: > > git://xenbits.xen.org/people/sstabellini/qemu-dm.git xen-2012-10-03 Pulled. Thanks. Regards, Anthony Liguori > > > Anthony PERARD (6): > xen: Fix, no unplug of pt device by platform device. > QMP, Introduce xen-set-global-dirty-log command. > xen: Introduce xen_modified_memory. > exec: Introduce helper to set dirty flags. > exec, memory: Call to xen_modified_memory. > xen: Set the vram dirty when an error occur. > > Xudong Hao (1): > qemu/xen: Add 64 bits big bar support on qemu > > > exec-obsolete.h | 2 + > exec.c | 53 ++++++++++++++++------------------------------- > hw/xen.h | 1 + > hw/xen_platform.c | 8 +++++- > hw/xen_pt.c | 7 ++++- > hw/xen_pt_config_init.c | 39 +++++++++++++++++++++++----------- > qapi-schema.json | 13 +++++++++++ > qmp-commands.hx | 24 +++++++++++++++++++++ > xen-all.c | 39 +++++++++++++++++++++++++++++++++- > xen-stub.c | 9 ++++++++ > 10 files changed, 142 insertions(+), 53 deletions(-) > > Cheers, > > Stefano _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 02:11:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 02:11:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJxNx-000282-GG; Fri, 05 Oct 2012 02:11:29 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJxNw-00027x-0R for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 02:11:28 +0000 Received: from [85.158.143.99:26032] by server-1.bemta-4.messagelabs.com id 7B/0A-05684-FC14E605; Fri, 05 Oct 2012 02:11:27 +0000 X-Env-Sender: anthony@codemonkey.ws X-Msg-Ref: server-6.tower-216.messagelabs.com!1349403085!25926932!1 X-Originating-IP: [209.85.219.43] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8343 invoked from network); 5 Oct 2012 02:11:26 -0000 Received: from mail-oa0-f43.google.com (HELO mail-oa0-f43.google.com) (209.85.219.43) by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 02:11:26 -0000 Received: by mail-oa0-f43.google.com with SMTP id k1so1763334oag.30 for ; Thu, 04 Oct 2012 19:11:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version:content-type:x-gm-message-state; bh=s4S+jLcV0/WMoNM7B6fBdfQOO58nTZ/Jyq/hPvO5TO4=; b=o6mk5lJle3zWnRTrO+TDcj1ds/oth/8D9RCRK0AM0vFCH4eyWH+rtm/mF9qKbJ2yhR 4RKhCDB+LbcJobLjVjpzYDTtVD8lO5r/J6aZL2yOKR48odDL516atg6Gmqdby2pF63yR wf5dnOq5D8Di9l8MJa2Yv96ZRpE+yfwWLwazxAiCYXAD6TH/aCQY/5kPy2AjklCSG053 0TGl6vt4Zr3xS7lfX+SlvofayDBrJ8P9sgFpkZrhZepIYbdlvmEUkhFMd+37cqNUFHll HMwSA83PDYG69o8sOPaCuJ/jKiqL59jmJ/CW110YL7TMuYVP8gSiJiJO7VJa6oX4Qf2A en4g== Received: by 10.60.172.199 with SMTP id be7mr5866479oec.93.1349403084590; Thu, 04 Oct 2012 19:11:24 -0700 (PDT) Received: from titi.smtp.gmail.com (cpe-70-123-130-163.austin.res.rr.com. [70.123.130.163]) by mx.google.com with ESMTPS id n8sm6441923oec.5.2012.10.04.19.11.22 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Oct 2012 19:11:23 -0700 (PDT) From: Anthony Liguori To: Stefano Stabellini In-Reply-To: References: User-Agent: Notmuch/0.13.2+93~ged93d79 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu) Date: Thu, 04 Oct 2012 21:11:21 -0500 Message-ID: <87391thdme.fsf@codemonkey.ws> MIME-Version: 1.0 X-Gm-Message-State: ALoCoQl2NN2idiwMXP+yLu0LF3nSa3AsUYxzZ0fiLq4kp+DpDSgMTDvwKtzcFRyjRTH36lgUAwap Cc: Anthony.Perard@citrix.com, xen-devel@lists.xensource.com, Xudong Hao , qemu-devel@nongnu.org, Stefano Stabellini Subject: Re: [Xen-devel] [PULL] Xen tree 2012-10-03 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Stefano Stabellini writes: > Hi Anthony, > please pull from the following tree based on > e744c06fca438dc08271e626034e632a270c91c8: > > git://xenbits.xen.org/people/sstabellini/qemu-dm.git xen-2012-10-03 Pulled. Thanks. Regards, Anthony Liguori > > > Anthony PERARD (6): > xen: Fix, no unplug of pt device by platform device. > QMP, Introduce xen-set-global-dirty-log command. > xen: Introduce xen_modified_memory. > exec: Introduce helper to set dirty flags. > exec, memory: Call to xen_modified_memory. > xen: Set the vram dirty when an error occur. > > Xudong Hao (1): > qemu/xen: Add 64 bits big bar support on qemu > > > exec-obsolete.h | 2 + > exec.c | 53 ++++++++++++++++------------------------------- > hw/xen.h | 1 + > hw/xen_platform.c | 8 +++++- > hw/xen_pt.c | 7 ++++- > hw/xen_pt_config_init.c | 39 +++++++++++++++++++++++----------- > qapi-schema.json | 13 +++++++++++ > qmp-commands.hx | 24 +++++++++++++++++++++ > xen-all.c | 39 +++++++++++++++++++++++++++++++++- > xen-stub.c | 9 ++++++++ > 10 files changed, 142 insertions(+), 53 deletions(-) > > Cheers, > > Stefano _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 02:51:24 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 02:51:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJy0B-0002V8-EE; Fri, 05 Oct 2012 02:50:59 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJy09-0002Ux-QW for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 02:50:58 +0000 Received: from [85.158.139.211:17590] by server-4.bemta-5.messagelabs.com id B4/7E-20767-11B4E605; Fri, 05 Oct 2012 02:50:57 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-8.tower-206.messagelabs.com!1349405456!21129190!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMwNjM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25635 invoked from network); 5 Oct 2012 02:50:56 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 02:50:56 -0000 X-IronPort-AV: E=Sophos;i="4.80,538,1344211200"; d="scan'208";a="14953000" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 02:50:43 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 03:50:43 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TJxzu-0003Vi-SB; Fri, 05 Oct 2012 02:50:42 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1TJxzu-0001Vg-Mq; Fri, 05 Oct 2012 03:50:42 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Fri, 5 Oct 2012 03:50:42 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 13923: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 13923 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13923/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 5 xen-boot fail like 13921 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail like 13921 test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail like 13921 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail like 13921 Tests which did not succeed, but are not blocking: test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: xen 032de7030d20 baseline version: xen 72d89cc43c72 ------------------------------------------------------------ People who touched revisions under test: Christoph Egger Jan Beulich Keir Fraser Tim Deegan ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-amd64-amd64-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable + revision=032de7030d20 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 032de7030d20 + branch=xen-unstable + revision=032de7030d20 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + . cri-common ++ umask 002 + select_xenbranch + case "$branch" in + tree=xen + xenbranch=xen-unstable + '[' xxen = xlinux ']' + linuxbranch=linux + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg ++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.xen-unstable ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git ++ : daily-cron.xen-unstable + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git + info_linux_tree xen-unstable + case $1 in + return 1 + case "$branch" in + cd /export/home/osstest/repos/xen-unstable.hg + hg push -r 032de7030d20 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 2 changesets with 2 changes to 2 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 02:51:24 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 02:51:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJy0B-0002V8-EE; Fri, 05 Oct 2012 02:50:59 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TJy09-0002Ux-QW for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 02:50:58 +0000 Received: from [85.158.139.211:17590] by server-4.bemta-5.messagelabs.com id B4/7E-20767-11B4E605; Fri, 05 Oct 2012 02:50:57 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-8.tower-206.messagelabs.com!1349405456!21129190!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMwNjM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25635 invoked from network); 5 Oct 2012 02:50:56 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 02:50:56 -0000 X-IronPort-AV: E=Sophos;i="4.80,538,1344211200"; d="scan'208";a="14953000" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 02:50:43 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 03:50:43 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TJxzu-0003Vi-SB; Fri, 05 Oct 2012 02:50:42 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1TJxzu-0001Vg-Mq; Fri, 05 Oct 2012 03:50:42 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Fri, 5 Oct 2012 03:50:42 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 13923: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 13923 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13923/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 5 xen-boot fail like 13921 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail like 13921 test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail like 13921 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail like 13921 Tests which did not succeed, but are not blocking: test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: xen 032de7030d20 baseline version: xen 72d89cc43c72 ------------------------------------------------------------ People who touched revisions under test: Christoph Egger Jan Beulich Keir Fraser Tim Deegan ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-amd64-amd64-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable + revision=032de7030d20 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 032de7030d20 + branch=xen-unstable + revision=032de7030d20 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + . cri-common ++ umask 002 + select_xenbranch + case "$branch" in + tree=xen + xenbranch=xen-unstable + '[' xxen = xlinux ']' + linuxbranch=linux + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg ++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.xen-unstable ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git ++ : daily-cron.xen-unstable + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git + info_linux_tree xen-unstable + case $1 in + return 1 + case "$branch" in + cd /export/home/osstest/repos/xen-unstable.hg + hg push -r 032de7030d20 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 2 changesets with 2 changes to 2 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 06:36:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 06:36:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK1VR-00052d-B6; Fri, 05 Oct 2012 06:35:29 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK1VP-00052Y-3t for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 06:35:27 +0000 Received: from [85.158.143.99:49521] by server-1.bemta-4.messagelabs.com id E7/58-05684-EAF7E605; Fri, 05 Oct 2012 06:35:26 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-11.tower-216.messagelabs.com!1349418925!25422076!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMwNjM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15516 invoked from network); 5 Oct 2012 06:35:25 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 06:35:25 -0000 X-IronPort-AV: E=Sophos;i="4.80,538,1344211200"; d="scan'208";a="14954640" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 06:35:16 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 07:35:16 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TK1VD-0004pN-Qd; Fri, 05 Oct 2012 06:35:15 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1TK1VD-0001K9-8Y; Fri, 05 Oct 2012 07:35:15 +0100 To: Message-ID: From: xen.org Date: Fri, 5 Oct 2012 07:35:15 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 13924: tolerable FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 13924 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13924/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 5 xen-boot fail like 13923 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail like 13923 test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail like 13923 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail like 13923 Tests which did not succeed, but are not blocking: test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: xen 032de7030d20 baseline version: xen 032de7030d20 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-amd64-amd64-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 06:36:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 06:36:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK1VR-00052d-B6; Fri, 05 Oct 2012 06:35:29 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK1VP-00052Y-3t for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 06:35:27 +0000 Received: from [85.158.143.99:49521] by server-1.bemta-4.messagelabs.com id E7/58-05684-EAF7E605; Fri, 05 Oct 2012 06:35:26 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-11.tower-216.messagelabs.com!1349418925!25422076!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMwNjM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15516 invoked from network); 5 Oct 2012 06:35:25 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 06:35:25 -0000 X-IronPort-AV: E=Sophos;i="4.80,538,1344211200"; d="scan'208";a="14954640" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 06:35:16 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 07:35:16 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TK1VD-0004pN-Qd; Fri, 05 Oct 2012 06:35:15 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1TK1VD-0001K9-8Y; Fri, 05 Oct 2012 07:35:15 +0100 To: Message-ID: From: xen.org Date: Fri, 5 Oct 2012 07:35:15 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 13924: tolerable FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 13924 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13924/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 5 xen-boot fail like 13923 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail like 13923 test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail like 13923 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail like 13923 Tests which did not succeed, but are not blocking: test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: xen 032de7030d20 baseline version: xen 032de7030d20 jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-amd64-amd64-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 07:18:27 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 07:18:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK2AV-0005Tv-Dd; Fri, 05 Oct 2012 07:17:55 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK2AT-0005Tq-CI for xen-devel@lists.xen.org; Fri, 05 Oct 2012 07:17:53 +0000 X-Env-Sender: singapore.mr.teo.en.ming@gmail.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1349421463!8834712!1 X-Originating-IP: [209.85.220.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28750 invoked from network); 5 Oct 2012 07:17:45 -0000 Received: from mail-pa0-f45.google.com (HELO mail-pa0-f45.google.com) (209.85.220.45) by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 07:17:45 -0000 Received: by mail-pa0-f45.google.com with SMTP id fb10so1408711pad.32 for ; Fri, 05 Oct 2012 00:17:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:cc:subject:content-type; bh=LzV56c3F3QQOdlG4ZORJGOC2X29D8c2bEny8JLdq70A=; b=OmmumPmfliKMvseQnYsqoJR9XhtEWCPVflH2ybE2BAo2P9y0DoyXWgX9/p5x4CHRin 5OGL/B4uJ6Yl/1n0G+aHomHkeV+n42174fZcCoe4hw3xREIR8ssVUv7PK6JIq67bcVQm MNmZSMCRoCmV4Ggrn7o7xtKe7vqKvMXTGpP+KfTHc6PlLpg0ccvo2tne6lEXPf8iaXK5 t3l+ukhcenJB8FMyW1/JUkHj3hAwH6s/oA/KJHQlCPcT6BbaHdAZu5pwYaeXVL4sRefp IwUCF4VRsF5n8JjhL8xIPcp3amOrWL/UedHqu9cn5LTr1c3OyHxP1NlUIk3nz7BVqlRe 6h+w== Received: by 10.68.204.132 with SMTP id ky4mr28060424pbc.164.1349421463374; Fri, 05 Oct 2012 00:17:43 -0700 (PDT) Received: from [192.168.1.2] (cm152.gamma205.maxonline.com.sg. [202.156.205.152]) by mx.google.com with ESMTPS id bj7sm5580807pab.24.2012.10.05.00.17.40 (version=SSLv3 cipher=OTHER); Fri, 05 Oct 2012 00:17:42 -0700 (PDT) Message-ID: <506E8993.7090201@gmail.com> Date: Fri, 05 Oct 2012 15:17:39 +0800 From: "Teo En Ming (Zhang Enming)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: "xen-devel@lists.xen.org" Content-Type: multipart/mixed; boundary="------------000307070306040005030607" Cc: "Teo En Ming \(Zhang Enming\)" , Frank Lyon , Dariusz Krempa Subject: [Xen-devel] Help Needed from Xen Developers: Nasty Yellow Triangle with Exclamation Mark and Error Code 43 in Device Manager in Windows 8 HVM domU X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a multi-part message in MIME format. --------------000307070306040005030607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear Xen developers, I have been able to get 100% success in Xen VGA Passthrough with Frank Lyon's NVIDIA Quadro 6000 (there is NO nasty yellow triangle with exclamation mark and error code 43 in device manager in Windows 8 HVM domU). But I have not been able to get 100% success (partial success) in Xen VGA Passthrough with my own display cards. I have recently upgraded my display card from NVIDIA Geforce 8400 GS to NVIDIA Geforce GTX 560 but there is always the nasty yellow triangle with exclamation mark and error code 43 associated with my display card in device manager in Windows 8 HVM domU. I have attached troubleshooting logs and configuration files. Please help me to troubleshoot and get rid of the nasty yellow triangle with exclamation mark and error code 43. I am using Xen 4.2-unstable changeset 25099 and Linux kernel 3.5.4 / 3.6.0-rc7. In both Frank Lyon's and my case, I have followed the installation instructions from my own Xen VGA Passthrough tutorial at http://wiki.xen.org/wiki/Xen_VGA_Passthrough_to_Windows_8_with_Xen_4.2-unstable I was able to get Frank Lyon's Xen VGA Passthrough to work 100% but not mine (partial success) with the same Xen VGA Passthrough tutorial. Thank you very much for your kind assistance. -- Yours sincerely, Mr. Teo En Ming (Zhang Enming) Singapore --------------000307070306040005030607 Content-Type: text/x-log; name="qemu-dm-Windows8.log" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="qemu-dm-Windows8.log" domid: 1 Strip off blktap sub-type prefix to /etc/xen/images/windows8.img (drv 'aio') Using file /etc/xen/images/windows8.img in read-write mode Strip off blktap sub-type prefix to /home/teo-en-ming/Windows8-ReleasePreview-64bit-English.iso (drv 'aio') Using file /home/teo-en-ming/Windows8-ReleasePreview-64bit-English.iso in read-only mode Watching /local/domain/0/device-model/1/logdirty/cmd Watching /local/domain/0/device-model/1/command Watching /local/domain/1/cpu qemu_map_cache_init nr_buckets = 10000 size 4194304 shared page at pfn feffd buffered io page at pfn feffb Guest uuid = 9e771120-b3f6-4cd1-9d15-d39fab0d6489 Register xen platform. Done register platform. platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw state. xs_read(/local/domain/0/device-model/1/xen_extended_power_mgmt): read error medium change watch on `hdc' (index: 1): aio:/home/teo-en-ming/Windows8-ReleasePreview-64bit-English.iso I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 Log-dirty: no command yet. I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 vcpu-set: watch node error. xs_read(/local/domain/1/log-throttling): read error qemu: ignoring not-understood drive `/local/domain/1/log-throttling' medium change watch on `/local/domain/1/log-throttling' - unknown device, ignored dm-command: hot insert pass-through pci dev register_real_device: Assigning real physical device 01:00.0 ... pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x1:0x0.0x0 pt_register_regions: IO region registered (size=0x02000000 base_addr=0xdc000000) pt_register_regions: IO region registered (size=0x08000000 base_addr=0xd000000c) pt_register_regions: IO region registered (size=0x04000000 base_addr=0xd800000c) pt_register_regions: IO region registered (size=0x00000080 base_addr=0x0000d001) pt_register_regions: Expansion ROM registered (size=0x00080000 base_addr=0xde000002) setup_vga_pt: vga bios checksum is adjusted! pt_msi_setup: msi mapped with pirq 37 pci_intx: intx=1 register_real_device: Real physical device 01:00.0 registered successfuly! IRQ type = MSI-INTx dm-command: hot insert pass-through pci dev register_real_device: Assigning real physical device 00:1b.0 ... pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x0:0x1b.0x0 pt_register_regions: IO region registered (size=0x00004000 base_addr=0xde220004) pt_msi_setup: msi mapped with pirq 36 pci_intx: intx=1 register_real_device: Real physical device 00:1b.0 registered successfuly! IRQ type = MSI-INTx dm-command: hot insert pass-through pci dev register_real_device: Assigning real physical device 00:1a.0 ... pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x0:0x1a.0x0 pt_register_regions: IO region registered (size=0x00000020 base_addr=0x0000e0c1) pci_intx: intx=1 register_real_device: Real physical device 00:1a.0 registered successfuly! IRQ type = INTx dm-command: hot insert pass-through pci dev register_real_device: Assigning real physical device 00:1a.1 ... pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x0:0x1a.0x1 pt_register_regions: IO region registered (size=0x00000020 base_addr=0x0000e0a1) pci_intx: intx=2 register_real_device: Real physical device 00:1a.1 registered successfuly! IRQ type = INTx dm-command: hot insert pass-through pci dev register_real_device: Assigning real physical device 00:1a.2 ... pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x0:0x1a.0x2 pt_register_regions: IO region registered (size=0x00000020 base_addr=0x0000e081) pci_intx: intx=3 register_real_device: Real physical device 00:1a.2 registered successfuly! IRQ type = INTx dm-command: hot insert pass-through pci dev register_real_device: Assigning real physical device 00:1a.7 ... pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x0:0x1a.0x7 pt_register_regions: IO region registered (size=0x00000400 base_addr=0xde226000) pci_intx: intx=3 register_real_device: Real physical device 00:1a.7 registered successfuly! IRQ type = INTx dm-command: hot insert pass-through pci dev register_real_device: Assigning real physical device 00:1d.0 ... pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x0:0x1d.0x0 pt_register_regions: IO region registered (size=0x00000020 base_addr=0x0000e061) pci_intx: intx=1 register_real_device: Real physical device 00:1d.0 registered successfuly! IRQ type = INTx dm-command: hot insert pass-through pci dev register_real_device: Assigning real physical device 00:1d.1 ... pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x0:0x1d.0x1 pt_register_regions: IO region registered (size=0x00000020 base_addr=0x0000e041) pci_intx: intx=2 register_real_device: Real physical device 00:1d.1 registered successfuly! IRQ type = INTx dm-command: hot insert pass-through pci dev register_real_device: Assigning real physical device 00:1d.2 ... pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x0:0x1d.0x2 pt_register_regions: IO region registered (size=0x00000020 base_addr=0x0000e021) pci_intx: intx=3 register_real_device: Real physical device 00:1d.2 registered successfuly! IRQ type = INTx dm-command: hot insert pass-through pci dev register_real_device: Assigning real physical device 00:1d.7 ... pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x0:0x1d.0x7 pt_register_regions: IO region registered (size=0x00000400 base_addr=0xde225000) pci_intx: intx=1 register_real_device: Real physical device 00:1d.7 registered successfuly! IRQ type = INTx pt_bar_reg_read: first read BARs of gfx pt_iomem_map: e_phys=dc000000 maddr=dc000000 type=0 len=33554432 index=0 first_map=1 pt_bar_reg_read: first read BARs of gfx pt_iomem_map: e_phys=d0000000 maddr=d0000000 type=8 len=134217728 index=1 first_map=1 pt_bar_reg_read: first read BARs of gfx pt_bar_reg_read: first read BARs of gfx pt_iomem_map: e_phys=d8000000 maddr=d8000000 type=8 len=67108864 index=3 first_map=1 pt_bar_reg_read: first read BARs of gfx pt_bar_reg_read: first read BARs of gfx pt_ioport_map: e_phys=d000 pio_base=d000 len=128 index=5 first_map=1 pt_iomem_map: e_phys=f1000000 maddr=de220000 type=0 len=16384 index=0 first_map=1 pt_iomem_map: e_phys=f1004000 maddr=de226000 type=0 len=4096 index=0 first_map=1 pt_iomem_map: e_phys=f1005000 maddr=de225000 type=0 len=4096 index=0 first_map=1 pt_ioport_map: e_phys=c120 pio_base=e0c0 len=32 index=4 first_map=1 pt_ioport_map: e_phys=c140 pio_base=e0a0 len=32 index=4 first_map=1 pt_ioport_map: e_phys=c160 pio_base=e080 len=32 index=4 first_map=1 pt_ioport_map: e_phys=c180 pio_base=e060 len=32 index=4 first_map=1 pt_ioport_map: e_phys=c1a0 pio_base=e040 len=32 index=4 first_map=1 pt_ioport_map: e_phys=c1c0 pio_base=e020 len=32 index=4 first_map=1 platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw state. platform_fixed_ioport: changed ro/rw state of ROM memory area. now is ro state. pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:06:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:06:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:06:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:06:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:06:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:06:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:06:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:0a:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:0a:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:0a:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:0a:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:0a:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:0a:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:0a:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_iomem_map: e_phys=ffffffff maddr=dc000000 type=0 len=33554432 index=0 first_map=0 pt_iomem_map: e_phys=ffffffff maddr=d0000000 type=8 len=134217728 index=1 first_map=0 pt_iomem_map: e_phys=ffffffff maddr=d8000000 type=8 len=67108864 index=3 first_map=0 pt_ioport_map: e_phys=ffff pio_base=d000 len=128 index=5 first_map=0 pt_iomem_map: e_phys=dc000000 maddr=dc000000 type=0 len=33554432 index=0 first_map=0 pt_iomem_map: e_phys=d0000000 maddr=d0000000 type=8 len=134217728 index=1 first_map=0 pt_iomem_map: e_phys=d8000000 maddr=d8000000 type=8 len=67108864 index=3 first_map=0 pt_ioport_map: e_phys=d000 pio_base=d000 len=128 index=5 first_map=0 pt_iomem_map: e_phys=ffffffff maddr=de220000 type=0 len=16384 index=0 first_map=0 pt_iomem_map: e_phys=f1000000 maddr=de220000 type=0 len=16384 index=0 first_map=0 pt_ioport_map: e_phys=ffff pio_base=e0c0 len=32 index=4 first_map=0 pt_ioport_map: e_phys=c120 pio_base=e0c0 len=32 index=4 first_map=0 pt_ioport_map: e_phys=ffff pio_base=e0a0 len=32 index=4 first_map=0 pt_ioport_map: e_phys=c140 pio_base=e0a0 len=32 index=4 first_map=0 pt_ioport_map: e_phys=ffff pio_base=e080 len=32 index=4 first_map=0 pt_ioport_map: e_phys=c160 pio_base=e080 len=32 index=4 first_map=0 pt_iomem_map: e_phys=ffffffff maddr=de226000 type=0 len=4096 index=0 first_map=0 pt_iomem_map: e_phys=f1004000 maddr=de226000 type=0 len=4096 index=0 first_map=0 pt_ioport_map: e_phys=ffff pio_base=e060 len=32 index=4 first_map=0 pt_ioport_map: e_phys=c180 pio_base=e060 len=32 index=4 first_map=0 pt_ioport_map: e_phys=ffff pio_base=e040 len=32 index=4 first_map=0 pt_ioport_map: e_phys=c1a0 pio_base=e040 len=32 index=4 first_map=0 pt_ioport_map: e_phys=ffff pio_base=e020 len=32 index=4 first_map=0 pt_ioport_map: e_phys=c1c0 pio_base=e020 len=32 index=4 first_map=0 pt_iomem_map: e_phys=ffffffff maddr=de225000 type=0 len=4096 index=0 first_map=0 pt_iomem_map: e_phys=f1005000 maddr=de225000 type=0 len=4096 index=0 first_map=0 pt_iomem_map: e_phys=ffffffff maddr=dc000000 type=0 len=33554432 index=0 first_map=0 pt_iomem_map: e_phys=ffffffff maddr=d0000000 type=8 len=134217728 index=1 first_map=0 pt_iomem_map: e_phys=ffffffff maddr=d8000000 type=8 len=67108864 index=3 first_map=0 pt_ioport_map: e_phys=ffff pio_base=d000 len=128 index=5 first_map=0 pt_iomem_map: e_phys=dc000000 maddr=dc000000 type=0 len=33554432 index=0 first_map=0 pt_iomem_map: e_phys=d0000000 maddr=d0000000 type=8 len=134217728 index=1 first_map=0 pt_iomem_map: e_phys=d8000000 maddr=d8000000 type=8 len=67108864 index=3 first_map=0 pt_ioport_map: e_phys=d000 pio_base=d000 len=128 index=5 first_map=0 pt_ioport_map: e_phys=ffff pio_base=e0c0 len=32 index=4 first_map=0 pt_ioport_map: e_phys=c120 pio_base=e0c0 len=32 index=4 first_map=0 pt_iomem_map: e_phys=ffffffff maddr=de220000 type=0 len=16384 index=0 first_map=0 pt_iomem_map: e_phys=f1000000 maddr=de220000 type=0 len=16384 index=0 first_map=0 pt_ioport_map: e_phys=ffff pio_base=e0a0 len=32 index=4 first_map=0 pt_ioport_map: e_phys=c140 pio_base=e0a0 len=32 index=4 first_map=0 pt_ioport_map: e_phys=ffff pio_base=e080 len=32 index=4 first_map=0 pt_ioport_map: e_phys=c160 pio_base=e080 len=32 index=4 first_map=0 pt_iomem_map: e_phys=ffffffff maddr=de226000 type=0 len=4096 index=0 first_map=0 pt_iomem_map: e_phys=f1004000 maddr=de226000 type=0 len=4096 index=0 first_map=0 pt_ioport_map: e_phys=ffff pio_base=e060 len=32 index=4 first_map=0 pt_ioport_map: e_phys=c180 pio_base=e060 len=32 index=4 first_map=0 pt_ioport_map: e_phys=ffff pio_base=e040 len=32 index=4 first_map=0 pt_ioport_map: e_phys=c1a0 pio_base=e040 len=32 index=4 first_map=0 pt_ioport_map: e_phys=ffff pio_base=e020 len=32 index=4 first_map=0 pt_ioport_map: e_phys=c1c0 pio_base=e020 len=32 index=4 first_map=0 pt_iomem_map: e_phys=ffffffff maddr=de225000 type=0 len=4096 index=0 first_map=0 pt_iomem_map: e_phys=f1005000 maddr=de225000 type=0 len=4096 index=0 first_map=0 pt_iomem_map: e_phys=ffffffff maddr=de220000 type=0 len=16384 index=0 first_map=0 pt_iomem_map: e_phys=ffffffff maddr=de225000 type=0 len=4096 index=0 first_map=0 pt_ioport_map: e_phys=ffff pio_base=e040 len=32 index=4 first_map=0 pt_ioport_map: e_phys=ffff pio_base=e020 len=32 index=4 first_map=0 pt_ioport_map: e_phys=ffff pio_base=e0c0 len=32 index=4 first_map=0 pt_ioport_map: e_phys=ffff pio_base=e080 len=32 index=4 first_map=0 pt_ioport_map: e_phys=ffff pio_base=e060 len=32 index=4 first_map=0 pt_ioport_map: e_phys=ffff pio_base=e0a0 len=32 index=4 first_map=0 pt_iomem_map: e_phys=ffffffff maddr=de226000 type=0 len=4096 index=0 first_map=0 --------------000307070306040005030607 Content-Type: text/plain; charset=UTF-8; name="xl create info" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="xl create info" + sudo xl -vvv create /etc/xen/windows8 Parsing config file /etc/xen/windows8 libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk vdev=hda spec.backend=unknown libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=hda, backend phy unsuitable as phys path not a block device libxl: debug: libxl_device.c:144:disk_try_backend: Disk vdev=hda, backend tap unsuitable because blktap not available libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk vdev=hda, using backend qdisk libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk vdev=hdc spec.backend=unknown libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=hdc, backend phy unsuitable as phys path not a block device libxl: debug: libxl_device.c:144:disk_try_backend: Disk vdev=hdc, backend tap unsuitable because blktap not available libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk vdev=hdc, using backend qdisk xc: detail: elf_parse_binary: phdr: paddr=0x100000 memsz=0xad72c xc: detail: elf_parse_binary: memory: 0x100000 -> 0x1ad72c xc: info: VIRTUAL MEMORY ARRANGEMENT: Loader: 0000000000100000->00000000001ad72c TOTAL: 0000000000000000->000000007f800000 ENTRY ADDRESS: 0000000000100000 xc: info: PHYSICAL MEMORY ALLOCATION: 4KB PAGES: 0x0000000000000200 2MB PAGES: 0x00000000000003fb 1GB PAGES: 0x0000000000000000 xc: detail: elf_load_binary: phdr 0 at 0x0x7f3d8d0ec000 -> 0x0x7f3d8d1905bb libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk vdev=hda spec.backend=qdisk libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk vdev=hdc spec.backend=qdisk libxl: error: libxl_pci.c:761:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:01:00.0 libxl: error: libxl_pci.c:761:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:00:1a.0 libxl: error: libxl_pci.c:761:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:00:1a.1 libxl: error: libxl_pci.c:761:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:00:1a.2 libxl: error: libxl_pci.c:756:libxl__device_pci_reset: write to /sys/bus/pci/devices/0000:00:1a.7/reset returned -1: Invalid argument libxl: error: libxl_pci.c:761:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:00:1d.0 libxl: error: libxl_pci.c:761:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:00:1d.1 libxl: error: libxl_pci.c:761:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:00:1d.2 libxl: error: libxl_pci.c:756:libxl__device_pci_reset: write to /sys/bus/pci/devices/0000:00:1d.7/reset returned -1: Invalid argument libxl: debug: libxl_pci.c:223:libxl__create_pci_backend: Creating pci backend Daemon running with PID 2736 xc: debug: hypercall buffer: total allocations:986 total releases:986 xc: debug: hypercall buffer: current allocations:0 maximum allocations:2 xc: debug: hypercall buffer: cache current size:2 xc: debug: hypercall buffer: cache hits:983 misses:2 toobig:1 --------------000307070306040005030607 Content-Type: text/x-log; name="xl-Windows8.log" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="xl-Windows8.log" Waiting for domain Windows8 (domid 1) to die [pid 2737] libxl: debug: libxl_event.c:406:watchfd_callback: watch event: epath=@releaseDomain token=3/0 wpath=@releaseDomain w=0x204c188 libxl: debug: libxl.c:786:domain_death_xswatch_callback: [evg=0x204c8b0:1] from domid=1 nentries=1 rc=1 libxl: debug: libxl.c:797:domain_death_xswatch_callback: [evg=0x204c8b0:1] got=domaininfos[0] got->domain=1 libxl: debug: libxl.c:824:domain_death_xswatch_callback: exists shutdown_reported=0 dominf.flags=ffff0002 libxl: debug: libxl.c:790:domain_death_xswatch_callback: [evg=0] all reported libxl: debug: libxl.c:854:domain_death_xswatch_callback: domain death search done libxl: debug: libxl_event.c:406:watchfd_callback: watch event: epath=/local/domain/1/device/vbd/5632/eject token=2/1 wpath=/local/domain/1/device/vbd/5632/eject w=0x204ee30 --------------000307070306040005030607 Content-Type: text/plain; charset=UTF-8; name="windows8" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="windows8" # XL domain configuration file for Windows 8 Consumer Preview 64-bit English HVM domU # Please refer to "man xl.cfg" for further explanations. # See also docs/misc/xl-network-configuration.markdown and # docs/misc/xl-disk-configuration.txt # Written by Teo En Ming (Zhang Enming) # Email: teo.en.ming@gmail.com # Mobile Phone: +65-8369-2618 # Country: Singapore # Date: 18 Mar 2012 Sun name="Windows8" # Product Key: DNJXJ-7XBW8-2378T-X22TX-BKG7J builder="hvm" vcpus=2 memory=2048 on_poweroff="destroy" on_reboot="restart" on_crash="destroy" disk=[ 'format=raw, vdev=hda, access=rw, target=/etc/xen/images/windows8.img', 'format=raw, vdev=hdc, access=ro, devtype=cdrom, target=/home/teo-en-ming/Windows8-ReleasePreview-64bit-English.iso' ] #vif=[ 'bridge=virbr0,type=ioemu,model=e1000' ] #boot=[c|d|n] #Selects the emulated virtual device to boot from. Options are hard disk (c), cd-rom (d) or network/PXE (n). #Multiple options can be given and will be attempted in the order they are given. e.g. to boot from cd-rom #but fallback to the hard disk you can give dc. The default is cd. boot="dc" acpi=1 xen_platform_pci=1 viridian=1 #stdvga=1 vnc=1 vnclisten="192.168.1.2" vncdisplay=0 vncunused=1 vncpasswd="" sdl=0 usb=1 usbdevice="tablet" # Enable Xen VGA Passthrough gfx_passthru=1 # VGA Passthrough Gigabyte Geforce GTX 560 1 GB GDDR5. pci = [ '01:00.0','00:1b.0','00:1a.0','00:1a.1','00:1a.2','00:1a.7','00:1d.0','00:1d.1','00:1d.2','00:1d.7' ] # PCI Passthrough Intel HD Audio Controller. #pci = [ '00:1b.0' ] # PCI Passthrough all the USB Controllers. # pci = [ '00:1a.0','00:1a.1','00:1a.2','00:1a.7','00:1d.0','00:1d.1','00:1d.2','00:1d.7' ] apic=1 xen_extended_power_mgmt=1 pae=1 arch='x86_64' hpet = 1 hap = 1 monitor=1 pci_power_mgmt = 1 acpi_s3 = 1 acpi_s4 = 1 --------------000307070306040005030607 Content-Type: text/plain; charset=UTF-8; name="start-windows" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="start-windows" #!/bin/sh set -x # # Starts Shorewall Firewall sudo service shorewall restart # # Loads pci-stub kernel module sudo modprobe pci-stub # # Passthrough Gigabyte Geforce GTX 560 1 GB GDDR5 # echo "Passthrough Gigabyte Geforce GTX 560 1 GB GDDR5" sudo chmod o+w /sys/bus/pci/drivers/pci-stub/new_id sudo chmod o+w /sys/bus/pci/devices/0000:01:00.0/driver/unbind sudo chmod o+w /sys/bus/pci/drivers/pci-stub/bind echo "10de 1201" > /sys/bus/pci/drivers/pci-stub/new_id echo "0000:01:00.0" > /sys/bus/pci/devices/0000:01:00.0/driver/unbind echo "0000:01:00.0" > /sys/bus/pci/drivers/pci-stub/bind # # Passthrough Intel HD Audio Controller # echo "Passthrough Intel HD Audio Controller." sudo chmod o+w /sys/bus/pci/drivers/pci-stub/new_id sudo chmod o+w /sys/bus/pci/devices/0000:00:1b.0/driver/unbind sudo chmod o+w /sys/bus/pci/drivers/pci-stub/bind echo "8086 3a6e" > /sys/bus/pci/drivers/pci-stub/new_id echo "0000:00:1b.0" > /sys/bus/pci/devices/0000:00:1b.0/driver/unbind echo "0000:00:1b.0" > /sys/bus/pci/drivers/pci-stub/bind # # Sleep for 10 secs # sleep 10 # # Passthrough USB Controller #1 # echo "Passthrough USB Controller #1." sudo chmod o+w /sys/bus/pci/drivers/pci-stub/new_id sudo chmod o+w /sys/bus/pci/devices/0000:00:1a.0/driver/unbind sudo chmod o+w /sys/bus/pci/drivers/pci-stub/bind echo "8086 3a67" > /sys/bus/pci/drivers/pci-stub/new_id echo "0000:00:1a.0" > /sys/bus/pci/devices/0000:00:1a.0/driver/unbind echo "0000:00:1a.0" > /sys/bus/pci/drivers/pci-stub/bind # # Passthrough USB Controller #2 # echo "Passthrough USB Controller #2." sudo chmod o+w /sys/bus/pci/drivers/pci-stub/new_id sudo chmod o+w /sys/bus/pci/devices/0000:00:1a.1/driver/unbind sudo chmod o+w /sys/bus/pci/drivers/pci-stub/bind echo "8086 3a68" > /sys/bus/pci/drivers/pci-stub/new_id echo "0000:00:1a.1" > /sys/bus/pci/devices/0000:00:1a.1/driver/unbind echo "0000:00:1a.1" > /sys/bus/pci/drivers/pci-stub/bind # # Passthrough USB Controller #3 # echo "Passthrough USB Controller #3." sudo chmod o+w /sys/bus/pci/drivers/pci-stub/new_id sudo chmod o+w /sys/bus/pci/devices/0000:00:1a.2/driver/unbind sudo chmod o+w /sys/bus/pci/drivers/pci-stub/bind echo "8086 3a69" > /sys/bus/pci/drivers/pci-stub/new_id echo "0000:00:1a.2" > /sys/bus/pci/devices/0000:00:1a.2/driver/unbind echo "0000:00:1a.2" > /sys/bus/pci/drivers/pci-stub/bind # # Passthrough USB Controller #4 # echo "Passthrough USB Controller #4." sudo chmod o+w /sys/bus/pci/drivers/pci-stub/new_id sudo chmod o+w /sys/bus/pci/devices/0000:00:1a.7/driver/unbind sudo chmod o+w /sys/bus/pci/drivers/pci-stub/bind echo "8086 3a6c" > /sys/bus/pci/drivers/pci-stub/new_id echo "0000:00:1a.7" > /sys/bus/pci/devices/0000:00:1a.7/driver/unbind echo "0000:00:1a.7" > /sys/bus/pci/drivers/pci-stub/bind # # Passthrough USB Controller #5 # echo "Passthrough USB Controller #5." sudo chmod o+w /sys/bus/pci/drivers/pci-stub/new_id sudo chmod o+w /sys/bus/pci/devices/0000:00:1d.0/driver/unbind sudo chmod o+w /sys/bus/pci/drivers/pci-stub/bind echo "8086 3a64" > /sys/bus/pci/drivers/pci-stub/new_id echo "0000:00:1d.0" > /sys/bus/pci/devices/0000:00:1d.0/driver/unbind echo "0000:00:1d.0" > /sys/bus/pci/drivers/pci-stub/bind # # Passthrough USB Controller #6 # echo "Passthrough USB Controller #6." sudo chmod o+w /sys/bus/pci/drivers/pci-stub/new_id sudo chmod o+w /sys/bus/pci/devices/0000:00:1d.1/driver/unbind sudo chmod o+w /sys/bus/pci/drivers/pci-stub/bind echo "8086 3a65" > /sys/bus/pci/drivers/pci-stub/new_id echo "0000:00:1d.1" > /sys/bus/pci/devices/0000:00:1d.1/driver/unbind echo "0000:00:1d.1" > /sys/bus/pci/drivers/pci-stub/bind # # Passthrough USB Controller #7 # echo "Passthrough USB Controller #7." sudo chmod o+w /sys/bus/pci/drivers/pci-stub/new_id sudo chmod o+w /sys/bus/pci/devices/0000:00:1d.2/driver/unbind sudo chmod o+w /sys/bus/pci/drivers/pci-stub/bind echo "8086 3a66" > /sys/bus/pci/drivers/pci-stub/new_id echo "0000:00:1d.2" > /sys/bus/pci/devices/0000:00:1d.2/driver/unbind echo "0000:00:1d.2" > /sys/bus/pci/drivers/pci-stub/bind # # Passthrough USB Controller #8 # echo "Passthrough USB Controller #8." sudo chmod o+w /sys/bus/pci/drivers/pci-stub/new_id sudo chmod o+w /sys/bus/pci/devices/0000:00:1d.7/driver/unbind sudo chmod o+w /sys/bus/pci/drivers/pci-stub/bind echo "8086 3a6a" > /sys/bus/pci/drivers/pci-stub/new_id echo "0000:00:1d.7" > /sys/bus/pci/devices/0000:00:1d.7/driver/unbind echo "0000:00:1d.7" > /sys/bus/pci/drivers/pci-stub/bind # # Wait for 10 seconds # sleep 10 # # Start Windows HVM domU with VGA Passthrough # #sudo xl create /etc/xen/WindowsXPHomeEditionSP3 sudo xl -vvv create /etc/xen/windows8 --------------000307070306040005030607 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --------------000307070306040005030607-- From xen-devel-bounces@lists.xen.org Fri Oct 05 07:18:27 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 07:18:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK2AV-0005Tv-Dd; Fri, 05 Oct 2012 07:17:55 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK2AT-0005Tq-CI for xen-devel@lists.xen.org; Fri, 05 Oct 2012 07:17:53 +0000 X-Env-Sender: singapore.mr.teo.en.ming@gmail.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1349421463!8834712!1 X-Originating-IP: [209.85.220.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28750 invoked from network); 5 Oct 2012 07:17:45 -0000 Received: from mail-pa0-f45.google.com (HELO mail-pa0-f45.google.com) (209.85.220.45) by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 07:17:45 -0000 Received: by mail-pa0-f45.google.com with SMTP id fb10so1408711pad.32 for ; Fri, 05 Oct 2012 00:17:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:cc:subject:content-type; bh=LzV56c3F3QQOdlG4ZORJGOC2X29D8c2bEny8JLdq70A=; b=OmmumPmfliKMvseQnYsqoJR9XhtEWCPVflH2ybE2BAo2P9y0DoyXWgX9/p5x4CHRin 5OGL/B4uJ6Yl/1n0G+aHomHkeV+n42174fZcCoe4hw3xREIR8ssVUv7PK6JIq67bcVQm MNmZSMCRoCmV4Ggrn7o7xtKe7vqKvMXTGpP+KfTHc6PlLpg0ccvo2tne6lEXPf8iaXK5 t3l+ukhcenJB8FMyW1/JUkHj3hAwH6s/oA/KJHQlCPcT6BbaHdAZu5pwYaeXVL4sRefp IwUCF4VRsF5n8JjhL8xIPcp3amOrWL/UedHqu9cn5LTr1c3OyHxP1NlUIk3nz7BVqlRe 6h+w== Received: by 10.68.204.132 with SMTP id ky4mr28060424pbc.164.1349421463374; Fri, 05 Oct 2012 00:17:43 -0700 (PDT) Received: from [192.168.1.2] (cm152.gamma205.maxonline.com.sg. [202.156.205.152]) by mx.google.com with ESMTPS id bj7sm5580807pab.24.2012.10.05.00.17.40 (version=SSLv3 cipher=OTHER); Fri, 05 Oct 2012 00:17:42 -0700 (PDT) Message-ID: <506E8993.7090201@gmail.com> Date: Fri, 05 Oct 2012 15:17:39 +0800 From: "Teo En Ming (Zhang Enming)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: "xen-devel@lists.xen.org" Content-Type: multipart/mixed; boundary="------------000307070306040005030607" Cc: "Teo En Ming \(Zhang Enming\)" , Frank Lyon , Dariusz Krempa Subject: [Xen-devel] Help Needed from Xen Developers: Nasty Yellow Triangle with Exclamation Mark and Error Code 43 in Device Manager in Windows 8 HVM domU X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a multi-part message in MIME format. --------------000307070306040005030607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear Xen developers, I have been able to get 100% success in Xen VGA Passthrough with Frank Lyon's NVIDIA Quadro 6000 (there is NO nasty yellow triangle with exclamation mark and error code 43 in device manager in Windows 8 HVM domU). But I have not been able to get 100% success (partial success) in Xen VGA Passthrough with my own display cards. I have recently upgraded my display card from NVIDIA Geforce 8400 GS to NVIDIA Geforce GTX 560 but there is always the nasty yellow triangle with exclamation mark and error code 43 associated with my display card in device manager in Windows 8 HVM domU. I have attached troubleshooting logs and configuration files. Please help me to troubleshoot and get rid of the nasty yellow triangle with exclamation mark and error code 43. I am using Xen 4.2-unstable changeset 25099 and Linux kernel 3.5.4 / 3.6.0-rc7. In both Frank Lyon's and my case, I have followed the installation instructions from my own Xen VGA Passthrough tutorial at http://wiki.xen.org/wiki/Xen_VGA_Passthrough_to_Windows_8_with_Xen_4.2-unstable I was able to get Frank Lyon's Xen VGA Passthrough to work 100% but not mine (partial success) with the same Xen VGA Passthrough tutorial. Thank you very much for your kind assistance. -- Yours sincerely, Mr. Teo En Ming (Zhang Enming) Singapore --------------000307070306040005030607 Content-Type: text/x-log; name="qemu-dm-Windows8.log" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="qemu-dm-Windows8.log" domid: 1 Strip off blktap sub-type prefix to /etc/xen/images/windows8.img (drv 'aio') Using file /etc/xen/images/windows8.img in read-write mode Strip off blktap sub-type prefix to /home/teo-en-ming/Windows8-ReleasePreview-64bit-English.iso (drv 'aio') Using file /home/teo-en-ming/Windows8-ReleasePreview-64bit-English.iso in read-only mode Watching /local/domain/0/device-model/1/logdirty/cmd Watching /local/domain/0/device-model/1/command Watching /local/domain/1/cpu qemu_map_cache_init nr_buckets = 10000 size 4194304 shared page at pfn feffd buffered io page at pfn feffb Guest uuid = 9e771120-b3f6-4cd1-9d15-d39fab0d6489 Register xen platform. Done register platform. platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw state. xs_read(/local/domain/0/device-model/1/xen_extended_power_mgmt): read error medium change watch on `hdc' (index: 1): aio:/home/teo-en-ming/Windows8-ReleasePreview-64bit-English.iso I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 Log-dirty: no command yet. I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 vcpu-set: watch node error. xs_read(/local/domain/1/log-throttling): read error qemu: ignoring not-understood drive `/local/domain/1/log-throttling' medium change watch on `/local/domain/1/log-throttling' - unknown device, ignored dm-command: hot insert pass-through pci dev register_real_device: Assigning real physical device 01:00.0 ... pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x1:0x0.0x0 pt_register_regions: IO region registered (size=0x02000000 base_addr=0xdc000000) pt_register_regions: IO region registered (size=0x08000000 base_addr=0xd000000c) pt_register_regions: IO region registered (size=0x04000000 base_addr=0xd800000c) pt_register_regions: IO region registered (size=0x00000080 base_addr=0x0000d001) pt_register_regions: Expansion ROM registered (size=0x00080000 base_addr=0xde000002) setup_vga_pt: vga bios checksum is adjusted! pt_msi_setup: msi mapped with pirq 37 pci_intx: intx=1 register_real_device: Real physical device 01:00.0 registered successfuly! IRQ type = MSI-INTx dm-command: hot insert pass-through pci dev register_real_device: Assigning real physical device 00:1b.0 ... pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x0:0x1b.0x0 pt_register_regions: IO region registered (size=0x00004000 base_addr=0xde220004) pt_msi_setup: msi mapped with pirq 36 pci_intx: intx=1 register_real_device: Real physical device 00:1b.0 registered successfuly! IRQ type = MSI-INTx dm-command: hot insert pass-through pci dev register_real_device: Assigning real physical device 00:1a.0 ... pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x0:0x1a.0x0 pt_register_regions: IO region registered (size=0x00000020 base_addr=0x0000e0c1) pci_intx: intx=1 register_real_device: Real physical device 00:1a.0 registered successfuly! IRQ type = INTx dm-command: hot insert pass-through pci dev register_real_device: Assigning real physical device 00:1a.1 ... pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x0:0x1a.0x1 pt_register_regions: IO region registered (size=0x00000020 base_addr=0x0000e0a1) pci_intx: intx=2 register_real_device: Real physical device 00:1a.1 registered successfuly! IRQ type = INTx dm-command: hot insert pass-through pci dev register_real_device: Assigning real physical device 00:1a.2 ... pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x0:0x1a.0x2 pt_register_regions: IO region registered (size=0x00000020 base_addr=0x0000e081) pci_intx: intx=3 register_real_device: Real physical device 00:1a.2 registered successfuly! IRQ type = INTx dm-command: hot insert pass-through pci dev register_real_device: Assigning real physical device 00:1a.7 ... pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x0:0x1a.0x7 pt_register_regions: IO region registered (size=0x00000400 base_addr=0xde226000) pci_intx: intx=3 register_real_device: Real physical device 00:1a.7 registered successfuly! IRQ type = INTx dm-command: hot insert pass-through pci dev register_real_device: Assigning real physical device 00:1d.0 ... pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x0:0x1d.0x0 pt_register_regions: IO region registered (size=0x00000020 base_addr=0x0000e061) pci_intx: intx=1 register_real_device: Real physical device 00:1d.0 registered successfuly! IRQ type = INTx dm-command: hot insert pass-through pci dev register_real_device: Assigning real physical device 00:1d.1 ... pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x0:0x1d.0x1 pt_register_regions: IO region registered (size=0x00000020 base_addr=0x0000e041) pci_intx: intx=2 register_real_device: Real physical device 00:1d.1 registered successfuly! IRQ type = INTx dm-command: hot insert pass-through pci dev register_real_device: Assigning real physical device 00:1d.2 ... pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x0:0x1d.0x2 pt_register_regions: IO region registered (size=0x00000020 base_addr=0x0000e021) pci_intx: intx=3 register_real_device: Real physical device 00:1d.2 registered successfuly! IRQ type = INTx dm-command: hot insert pass-through pci dev register_real_device: Assigning real physical device 00:1d.7 ... pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x0:0x1d.0x7 pt_register_regions: IO region registered (size=0x00000400 base_addr=0xde225000) pci_intx: intx=1 register_real_device: Real physical device 00:1d.7 registered successfuly! IRQ type = INTx pt_bar_reg_read: first read BARs of gfx pt_iomem_map: e_phys=dc000000 maddr=dc000000 type=0 len=33554432 index=0 first_map=1 pt_bar_reg_read: first read BARs of gfx pt_iomem_map: e_phys=d0000000 maddr=d0000000 type=8 len=134217728 index=1 first_map=1 pt_bar_reg_read: first read BARs of gfx pt_bar_reg_read: first read BARs of gfx pt_iomem_map: e_phys=d8000000 maddr=d8000000 type=8 len=67108864 index=3 first_map=1 pt_bar_reg_read: first read BARs of gfx pt_bar_reg_read: first read BARs of gfx pt_ioport_map: e_phys=d000 pio_base=d000 len=128 index=5 first_map=1 pt_iomem_map: e_phys=f1000000 maddr=de220000 type=0 len=16384 index=0 first_map=1 pt_iomem_map: e_phys=f1004000 maddr=de226000 type=0 len=4096 index=0 first_map=1 pt_iomem_map: e_phys=f1005000 maddr=de225000 type=0 len=4096 index=0 first_map=1 pt_ioport_map: e_phys=c120 pio_base=e0c0 len=32 index=4 first_map=1 pt_ioport_map: e_phys=c140 pio_base=e0a0 len=32 index=4 first_map=1 pt_ioport_map: e_phys=c160 pio_base=e080 len=32 index=4 first_map=1 pt_ioport_map: e_phys=c180 pio_base=e060 len=32 index=4 first_map=1 pt_ioport_map: e_phys=c1a0 pio_base=e040 len=32 index=4 first_map=1 pt_ioport_map: e_phys=c1c0 pio_base=e020 len=32 index=4 first_map=1 platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw state. platform_fixed_ioport: changed ro/rw state of ROM memory area. now is ro state. pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:06:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:06:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:06:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:06:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:06:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:06:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:06:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:0a:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:0a:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:0a:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:0a:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:0a:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:0a:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:0a:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_iomem_map: e_phys=ffffffff maddr=dc000000 type=0 len=33554432 index=0 first_map=0 pt_iomem_map: e_phys=ffffffff maddr=d0000000 type=8 len=134217728 index=1 first_map=0 pt_iomem_map: e_phys=ffffffff maddr=d8000000 type=8 len=67108864 index=3 first_map=0 pt_ioport_map: e_phys=ffff pio_base=d000 len=128 index=5 first_map=0 pt_iomem_map: e_phys=dc000000 maddr=dc000000 type=0 len=33554432 index=0 first_map=0 pt_iomem_map: e_phys=d0000000 maddr=d0000000 type=8 len=134217728 index=1 first_map=0 pt_iomem_map: e_phys=d8000000 maddr=d8000000 type=8 len=67108864 index=3 first_map=0 pt_ioport_map: e_phys=d000 pio_base=d000 len=128 index=5 first_map=0 pt_iomem_map: e_phys=ffffffff maddr=de220000 type=0 len=16384 index=0 first_map=0 pt_iomem_map: e_phys=f1000000 maddr=de220000 type=0 len=16384 index=0 first_map=0 pt_ioport_map: e_phys=ffff pio_base=e0c0 len=32 index=4 first_map=0 pt_ioport_map: e_phys=c120 pio_base=e0c0 len=32 index=4 first_map=0 pt_ioport_map: e_phys=ffff pio_base=e0a0 len=32 index=4 first_map=0 pt_ioport_map: e_phys=c140 pio_base=e0a0 len=32 index=4 first_map=0 pt_ioport_map: e_phys=ffff pio_base=e080 len=32 index=4 first_map=0 pt_ioport_map: e_phys=c160 pio_base=e080 len=32 index=4 first_map=0 pt_iomem_map: e_phys=ffffffff maddr=de226000 type=0 len=4096 index=0 first_map=0 pt_iomem_map: e_phys=f1004000 maddr=de226000 type=0 len=4096 index=0 first_map=0 pt_ioport_map: e_phys=ffff pio_base=e060 len=32 index=4 first_map=0 pt_ioport_map: e_phys=c180 pio_base=e060 len=32 index=4 first_map=0 pt_ioport_map: e_phys=ffff pio_base=e040 len=32 index=4 first_map=0 pt_ioport_map: e_phys=c1a0 pio_base=e040 len=32 index=4 first_map=0 pt_ioport_map: e_phys=ffff pio_base=e020 len=32 index=4 first_map=0 pt_ioport_map: e_phys=c1c0 pio_base=e020 len=32 index=4 first_map=0 pt_iomem_map: e_phys=ffffffff maddr=de225000 type=0 len=4096 index=0 first_map=0 pt_iomem_map: e_phys=f1005000 maddr=de225000 type=0 len=4096 index=0 first_map=0 pt_iomem_map: e_phys=ffffffff maddr=dc000000 type=0 len=33554432 index=0 first_map=0 pt_iomem_map: e_phys=ffffffff maddr=d0000000 type=8 len=134217728 index=1 first_map=0 pt_iomem_map: e_phys=ffffffff maddr=d8000000 type=8 len=67108864 index=3 first_map=0 pt_ioport_map: e_phys=ffff pio_base=d000 len=128 index=5 first_map=0 pt_iomem_map: e_phys=dc000000 maddr=dc000000 type=0 len=33554432 index=0 first_map=0 pt_iomem_map: e_phys=d0000000 maddr=d0000000 type=8 len=134217728 index=1 first_map=0 pt_iomem_map: e_phys=d8000000 maddr=d8000000 type=8 len=67108864 index=3 first_map=0 pt_ioport_map: e_phys=d000 pio_base=d000 len=128 index=5 first_map=0 pt_ioport_map: e_phys=ffff pio_base=e0c0 len=32 index=4 first_map=0 pt_ioport_map: e_phys=c120 pio_base=e0c0 len=32 index=4 first_map=0 pt_iomem_map: e_phys=ffffffff maddr=de220000 type=0 len=16384 index=0 first_map=0 pt_iomem_map: e_phys=f1000000 maddr=de220000 type=0 len=16384 index=0 first_map=0 pt_ioport_map: e_phys=ffff pio_base=e0a0 len=32 index=4 first_map=0 pt_ioport_map: e_phys=c140 pio_base=e0a0 len=32 index=4 first_map=0 pt_ioport_map: e_phys=ffff pio_base=e080 len=32 index=4 first_map=0 pt_ioport_map: e_phys=c160 pio_base=e080 len=32 index=4 first_map=0 pt_iomem_map: e_phys=ffffffff maddr=de226000 type=0 len=4096 index=0 first_map=0 pt_iomem_map: e_phys=f1004000 maddr=de226000 type=0 len=4096 index=0 first_map=0 pt_ioport_map: e_phys=ffff pio_base=e060 len=32 index=4 first_map=0 pt_ioport_map: e_phys=c180 pio_base=e060 len=32 index=4 first_map=0 pt_ioport_map: e_phys=ffff pio_base=e040 len=32 index=4 first_map=0 pt_ioport_map: e_phys=c1a0 pio_base=e040 len=32 index=4 first_map=0 pt_ioport_map: e_phys=ffff pio_base=e020 len=32 index=4 first_map=0 pt_ioport_map: e_phys=c1c0 pio_base=e020 len=32 index=4 first_map=0 pt_iomem_map: e_phys=ffffffff maddr=de225000 type=0 len=4096 index=0 first_map=0 pt_iomem_map: e_phys=f1005000 maddr=de225000 type=0 len=4096 index=0 first_map=0 pt_iomem_map: e_phys=ffffffff maddr=de220000 type=0 len=16384 index=0 first_map=0 pt_iomem_map: e_phys=ffffffff maddr=de225000 type=0 len=4096 index=0 first_map=0 pt_ioport_map: e_phys=ffff pio_base=e040 len=32 index=4 first_map=0 pt_ioport_map: e_phys=ffff pio_base=e020 len=32 index=4 first_map=0 pt_ioport_map: e_phys=ffff pio_base=e0c0 len=32 index=4 first_map=0 pt_ioport_map: e_phys=ffff pio_base=e080 len=32 index=4 first_map=0 pt_ioport_map: e_phys=ffff pio_base=e060 len=32 index=4 first_map=0 pt_ioport_map: e_phys=ffff pio_base=e0a0 len=32 index=4 first_map=0 pt_iomem_map: e_phys=ffffffff maddr=de226000 type=0 len=4096 index=0 first_map=0 --------------000307070306040005030607 Content-Type: text/plain; charset=UTF-8; name="xl create info" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="xl create info" + sudo xl -vvv create /etc/xen/windows8 Parsing config file /etc/xen/windows8 libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk vdev=hda spec.backend=unknown libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=hda, backend phy unsuitable as phys path not a block device libxl: debug: libxl_device.c:144:disk_try_backend: Disk vdev=hda, backend tap unsuitable because blktap not available libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk vdev=hda, using backend qdisk libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk vdev=hdc spec.backend=unknown libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=hdc, backend phy unsuitable as phys path not a block device libxl: debug: libxl_device.c:144:disk_try_backend: Disk vdev=hdc, backend tap unsuitable because blktap not available libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk vdev=hdc, using backend qdisk xc: detail: elf_parse_binary: phdr: paddr=0x100000 memsz=0xad72c xc: detail: elf_parse_binary: memory: 0x100000 -> 0x1ad72c xc: info: VIRTUAL MEMORY ARRANGEMENT: Loader: 0000000000100000->00000000001ad72c TOTAL: 0000000000000000->000000007f800000 ENTRY ADDRESS: 0000000000100000 xc: info: PHYSICAL MEMORY ALLOCATION: 4KB PAGES: 0x0000000000000200 2MB PAGES: 0x00000000000003fb 1GB PAGES: 0x0000000000000000 xc: detail: elf_load_binary: phdr 0 at 0x0x7f3d8d0ec000 -> 0x0x7f3d8d1905bb libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk vdev=hda spec.backend=qdisk libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk vdev=hdc spec.backend=qdisk libxl: error: libxl_pci.c:761:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:01:00.0 libxl: error: libxl_pci.c:761:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:00:1a.0 libxl: error: libxl_pci.c:761:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:00:1a.1 libxl: error: libxl_pci.c:761:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:00:1a.2 libxl: error: libxl_pci.c:756:libxl__device_pci_reset: write to /sys/bus/pci/devices/0000:00:1a.7/reset returned -1: Invalid argument libxl: error: libxl_pci.c:761:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:00:1d.0 libxl: error: libxl_pci.c:761:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:00:1d.1 libxl: error: libxl_pci.c:761:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:00:1d.2 libxl: error: libxl_pci.c:756:libxl__device_pci_reset: write to /sys/bus/pci/devices/0000:00:1d.7/reset returned -1: Invalid argument libxl: debug: libxl_pci.c:223:libxl__create_pci_backend: Creating pci backend Daemon running with PID 2736 xc: debug: hypercall buffer: total allocations:986 total releases:986 xc: debug: hypercall buffer: current allocations:0 maximum allocations:2 xc: debug: hypercall buffer: cache current size:2 xc: debug: hypercall buffer: cache hits:983 misses:2 toobig:1 --------------000307070306040005030607 Content-Type: text/x-log; name="xl-Windows8.log" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="xl-Windows8.log" Waiting for domain Windows8 (domid 1) to die [pid 2737] libxl: debug: libxl_event.c:406:watchfd_callback: watch event: epath=@releaseDomain token=3/0 wpath=@releaseDomain w=0x204c188 libxl: debug: libxl.c:786:domain_death_xswatch_callback: [evg=0x204c8b0:1] from domid=1 nentries=1 rc=1 libxl: debug: libxl.c:797:domain_death_xswatch_callback: [evg=0x204c8b0:1] got=domaininfos[0] got->domain=1 libxl: debug: libxl.c:824:domain_death_xswatch_callback: exists shutdown_reported=0 dominf.flags=ffff0002 libxl: debug: libxl.c:790:domain_death_xswatch_callback: [evg=0] all reported libxl: debug: libxl.c:854:domain_death_xswatch_callback: domain death search done libxl: debug: libxl_event.c:406:watchfd_callback: watch event: epath=/local/domain/1/device/vbd/5632/eject token=2/1 wpath=/local/domain/1/device/vbd/5632/eject w=0x204ee30 --------------000307070306040005030607 Content-Type: text/plain; charset=UTF-8; name="windows8" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="windows8" # XL domain configuration file for Windows 8 Consumer Preview 64-bit English HVM domU # Please refer to "man xl.cfg" for further explanations. # See also docs/misc/xl-network-configuration.markdown and # docs/misc/xl-disk-configuration.txt # Written by Teo En Ming (Zhang Enming) # Email: teo.en.ming@gmail.com # Mobile Phone: +65-8369-2618 # Country: Singapore # Date: 18 Mar 2012 Sun name="Windows8" # Product Key: DNJXJ-7XBW8-2378T-X22TX-BKG7J builder="hvm" vcpus=2 memory=2048 on_poweroff="destroy" on_reboot="restart" on_crash="destroy" disk=[ 'format=raw, vdev=hda, access=rw, target=/etc/xen/images/windows8.img', 'format=raw, vdev=hdc, access=ro, devtype=cdrom, target=/home/teo-en-ming/Windows8-ReleasePreview-64bit-English.iso' ] #vif=[ 'bridge=virbr0,type=ioemu,model=e1000' ] #boot=[c|d|n] #Selects the emulated virtual device to boot from. Options are hard disk (c), cd-rom (d) or network/PXE (n). #Multiple options can be given and will be attempted in the order they are given. e.g. to boot from cd-rom #but fallback to the hard disk you can give dc. The default is cd. boot="dc" acpi=1 xen_platform_pci=1 viridian=1 #stdvga=1 vnc=1 vnclisten="192.168.1.2" vncdisplay=0 vncunused=1 vncpasswd="" sdl=0 usb=1 usbdevice="tablet" # Enable Xen VGA Passthrough gfx_passthru=1 # VGA Passthrough Gigabyte Geforce GTX 560 1 GB GDDR5. pci = [ '01:00.0','00:1b.0','00:1a.0','00:1a.1','00:1a.2','00:1a.7','00:1d.0','00:1d.1','00:1d.2','00:1d.7' ] # PCI Passthrough Intel HD Audio Controller. #pci = [ '00:1b.0' ] # PCI Passthrough all the USB Controllers. # pci = [ '00:1a.0','00:1a.1','00:1a.2','00:1a.7','00:1d.0','00:1d.1','00:1d.2','00:1d.7' ] apic=1 xen_extended_power_mgmt=1 pae=1 arch='x86_64' hpet = 1 hap = 1 monitor=1 pci_power_mgmt = 1 acpi_s3 = 1 acpi_s4 = 1 --------------000307070306040005030607 Content-Type: text/plain; charset=UTF-8; name="start-windows" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="start-windows" #!/bin/sh set -x # # Starts Shorewall Firewall sudo service shorewall restart # # Loads pci-stub kernel module sudo modprobe pci-stub # # Passthrough Gigabyte Geforce GTX 560 1 GB GDDR5 # echo "Passthrough Gigabyte Geforce GTX 560 1 GB GDDR5" sudo chmod o+w /sys/bus/pci/drivers/pci-stub/new_id sudo chmod o+w /sys/bus/pci/devices/0000:01:00.0/driver/unbind sudo chmod o+w /sys/bus/pci/drivers/pci-stub/bind echo "10de 1201" > /sys/bus/pci/drivers/pci-stub/new_id echo "0000:01:00.0" > /sys/bus/pci/devices/0000:01:00.0/driver/unbind echo "0000:01:00.0" > /sys/bus/pci/drivers/pci-stub/bind # # Passthrough Intel HD Audio Controller # echo "Passthrough Intel HD Audio Controller." sudo chmod o+w /sys/bus/pci/drivers/pci-stub/new_id sudo chmod o+w /sys/bus/pci/devices/0000:00:1b.0/driver/unbind sudo chmod o+w /sys/bus/pci/drivers/pci-stub/bind echo "8086 3a6e" > /sys/bus/pci/drivers/pci-stub/new_id echo "0000:00:1b.0" > /sys/bus/pci/devices/0000:00:1b.0/driver/unbind echo "0000:00:1b.0" > /sys/bus/pci/drivers/pci-stub/bind # # Sleep for 10 secs # sleep 10 # # Passthrough USB Controller #1 # echo "Passthrough USB Controller #1." sudo chmod o+w /sys/bus/pci/drivers/pci-stub/new_id sudo chmod o+w /sys/bus/pci/devices/0000:00:1a.0/driver/unbind sudo chmod o+w /sys/bus/pci/drivers/pci-stub/bind echo "8086 3a67" > /sys/bus/pci/drivers/pci-stub/new_id echo "0000:00:1a.0" > /sys/bus/pci/devices/0000:00:1a.0/driver/unbind echo "0000:00:1a.0" > /sys/bus/pci/drivers/pci-stub/bind # # Passthrough USB Controller #2 # echo "Passthrough USB Controller #2." sudo chmod o+w /sys/bus/pci/drivers/pci-stub/new_id sudo chmod o+w /sys/bus/pci/devices/0000:00:1a.1/driver/unbind sudo chmod o+w /sys/bus/pci/drivers/pci-stub/bind echo "8086 3a68" > /sys/bus/pci/drivers/pci-stub/new_id echo "0000:00:1a.1" > /sys/bus/pci/devices/0000:00:1a.1/driver/unbind echo "0000:00:1a.1" > /sys/bus/pci/drivers/pci-stub/bind # # Passthrough USB Controller #3 # echo "Passthrough USB Controller #3." sudo chmod o+w /sys/bus/pci/drivers/pci-stub/new_id sudo chmod o+w /sys/bus/pci/devices/0000:00:1a.2/driver/unbind sudo chmod o+w /sys/bus/pci/drivers/pci-stub/bind echo "8086 3a69" > /sys/bus/pci/drivers/pci-stub/new_id echo "0000:00:1a.2" > /sys/bus/pci/devices/0000:00:1a.2/driver/unbind echo "0000:00:1a.2" > /sys/bus/pci/drivers/pci-stub/bind # # Passthrough USB Controller #4 # echo "Passthrough USB Controller #4." sudo chmod o+w /sys/bus/pci/drivers/pci-stub/new_id sudo chmod o+w /sys/bus/pci/devices/0000:00:1a.7/driver/unbind sudo chmod o+w /sys/bus/pci/drivers/pci-stub/bind echo "8086 3a6c" > /sys/bus/pci/drivers/pci-stub/new_id echo "0000:00:1a.7" > /sys/bus/pci/devices/0000:00:1a.7/driver/unbind echo "0000:00:1a.7" > /sys/bus/pci/drivers/pci-stub/bind # # Passthrough USB Controller #5 # echo "Passthrough USB Controller #5." sudo chmod o+w /sys/bus/pci/drivers/pci-stub/new_id sudo chmod o+w /sys/bus/pci/devices/0000:00:1d.0/driver/unbind sudo chmod o+w /sys/bus/pci/drivers/pci-stub/bind echo "8086 3a64" > /sys/bus/pci/drivers/pci-stub/new_id echo "0000:00:1d.0" > /sys/bus/pci/devices/0000:00:1d.0/driver/unbind echo "0000:00:1d.0" > /sys/bus/pci/drivers/pci-stub/bind # # Passthrough USB Controller #6 # echo "Passthrough USB Controller #6." sudo chmod o+w /sys/bus/pci/drivers/pci-stub/new_id sudo chmod o+w /sys/bus/pci/devices/0000:00:1d.1/driver/unbind sudo chmod o+w /sys/bus/pci/drivers/pci-stub/bind echo "8086 3a65" > /sys/bus/pci/drivers/pci-stub/new_id echo "0000:00:1d.1" > /sys/bus/pci/devices/0000:00:1d.1/driver/unbind echo "0000:00:1d.1" > /sys/bus/pci/drivers/pci-stub/bind # # Passthrough USB Controller #7 # echo "Passthrough USB Controller #7." sudo chmod o+w /sys/bus/pci/drivers/pci-stub/new_id sudo chmod o+w /sys/bus/pci/devices/0000:00:1d.2/driver/unbind sudo chmod o+w /sys/bus/pci/drivers/pci-stub/bind echo "8086 3a66" > /sys/bus/pci/drivers/pci-stub/new_id echo "0000:00:1d.2" > /sys/bus/pci/devices/0000:00:1d.2/driver/unbind echo "0000:00:1d.2" > /sys/bus/pci/drivers/pci-stub/bind # # Passthrough USB Controller #8 # echo "Passthrough USB Controller #8." sudo chmod o+w /sys/bus/pci/drivers/pci-stub/new_id sudo chmod o+w /sys/bus/pci/devices/0000:00:1d.7/driver/unbind sudo chmod o+w /sys/bus/pci/drivers/pci-stub/bind echo "8086 3a6a" > /sys/bus/pci/drivers/pci-stub/new_id echo "0000:00:1d.7" > /sys/bus/pci/devices/0000:00:1d.7/driver/unbind echo "0000:00:1d.7" > /sys/bus/pci/drivers/pci-stub/bind # # Wait for 10 seconds # sleep 10 # # Start Windows HVM domU with VGA Passthrough # #sudo xl create /etc/xen/WindowsXPHomeEditionSP3 sudo xl -vvv create /etc/xen/windows8 --------------000307070306040005030607 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --------------000307070306040005030607-- From xen-devel-bounces@lists.xen.org Fri Oct 05 08:32:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 08:32:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK3KH-0006hL-IU; Fri, 05 Oct 2012 08:32:05 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK3KG-0006hG-4E for xen-devel@lists.xen.org; Fri, 05 Oct 2012 08:32:04 +0000 Received: from [85.158.139.83:9631] by server-3.bemta-5.messagelabs.com id 3B/1A-16108-30B9E605; Fri, 05 Oct 2012 08:32:03 +0000 X-Env-Sender: muehlenhoff@univention.de X-Msg-Ref: server-6.tower-182.messagelabs.com!1349425918!29644742!1 X-Originating-IP: [82.198.197.8] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7215 invoked from network); 5 Oct 2012 08:31:59 -0000 Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8) by server-6.tower-182.messagelabs.com with SMTP; 5 Oct 2012 08:31:59 -0000 Received: from localhost (localhost [127.0.0.1]) by slugis.knut.univention.de (Postfix) with ESMTP id 3F578E5B105 for ; Fri, 5 Oct 2012 10:31:59 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by slugis.knut.univention.de (Postfix) with ESMTP id 33F0FE5B101 for ; Fri, 5 Oct 2012 10:31:59 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.6.1 (20080629) (Debian) at knut.univention.de Received: from mail.univention.de ([127.0.0.1]) by localhost (slugis.knut.univention.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Of9mZqjsAtiG for ; Fri, 5 Oct 2012 10:31:58 +0200 (CEST) Received: from vurm.localnet (mail.univention.de [82.198.197.8]) by slugis.knut.univention.de (Postfix) with ESMTPSA id 6BFE0E5B105 for ; Fri, 5 Oct 2012 10:31:58 +0200 (CEST) From: Moritz =?iso-8859-1?q?M=FChlenhoff?= Organization: Univention GmbH To: "xen-devel@lists.xen.org" Date: Fri, 5 Oct 2012 10:31:13 +0200 User-Agent: KMail/1.13.7 (Linux/3.2.0-3-amd64; KDE/4.8.4; x86_64; ; ) MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_RrpbQHKCt+klFsv" Message-Id: <201210051031.13377.muehlenhoff@univention.de> Subject: [Xen-devel] Compilation fixes for blktap kernel patch X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --Boundary-00=_RrpbQHKCt+klFsv Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I hope this is the correct mailing list for the blktap patches available at ftp://ftp.enjellic.com/pub/xen/ ? When integrating the patch into Linux 3.2.30 I noticed two compile errors=20 related to a missing include of module.h: /var/build/temp/tmp.TujmUayDmG/3.1-0-0/linux/linux-3.2.30/drivers/block/blk= tap/ring.c:536:=20 error: 'THIS_MODULE' undeclared here (not in a function) I'm attaching patches against the=20 ftp://ftp.enjellic.com/pub/xen/blktap2-3.2.patch patch Cheers, Moritz =2D-=20 Moritz M=FChlenhoff Open Source Software Engineer Univention GmbH be open. Mary-Somerville-Str.1 28359 Bremen Tel. : +49 421 22232-0 [.....] =46ax : +49 421 22232-99 muehlenhoff@univention.de http://www.univention.de Gesch=E4ftsf=FChrer: Peter H. Ganten HRB 20755 Amtsgericht Bremen Steuer-Nr.: 71-597-02876=20 --Boundary-00=_RrpbQHKCt+klFsv Content-Type: text/x-patch; charset="UTF-8"; name="fix-blktap-patch1.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="fix-blktap-patch1.diff" =46rom: Moritz M=C3=BChlenhoff ring.c uses THIS_MODULE, so it needs to include Signed-off-by Moritz M=C3=BChlenhoff =2D-- 30-add-blktap-driver.patch.orig 2012-10-04 11:19:26.784050570 +0200 +++ 30-add-blktap-driver.patch 2012-10-04 11:18:51.244048852 +0200 @@ -1571,13 +1571,14 @@ diff -urNp v3.2/linux-3.2/drivers/block/blktap/ring.c linux-3.2/drivers/bl= ock/blktap/ring.c --- v3.2/linux-3.2/drivers/block/blktap/ring.c Wed Dec 31 18:00:00 1969 +++ linux-3.2/drivers/block/blktap/ring.c Mon Apr 9 14:48:24 2012 =2D@@ -0,0 +1,645 @@ +@@ -0,0 +1,646 @@ + +#include +#include +#include +#include +#include ++#include + +#include "blktap.h" + --Boundary-00=_RrpbQHKCt+klFsv Content-Type: text/x-patch; charset="UTF-8"; name="fix-blktap-patch2.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="fix-blktap-patch2.diff" =46rom: Moritz M=C3=BChlenhoff device.c uses THIS_MODULE, so it needs to include Signed-off-by Moritz M=C3=BChlenhoff =2D-- 30-add-blktap-driver.patch.orig 2012-10-04 11:18:51.244048852 +0200 +++ 30-add-blktap-driver.patch 2012-10-04 11:56:19.812157693 +0200 @@ -526,12 +526,13 @@ diff -urNp v3.2/linux-3.2/drivers/block/blktap/device.c linux-3.2/drivers/= block/blktap/device.c --- v3.2/linux-3.2/drivers/block/blktap/device.c Wed Dec 31 18:00:00 1969 +++ linux-3.2/drivers/block/blktap/device.c Mon Apr 9 14:48:24 2012 =2D@@ -0,0 +1,618 @@ +@@ -0,0 +1,619 @@ +#include +#include +#include +#include +#include ++#include +#include +#include + --Boundary-00=_RrpbQHKCt+klFsv Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --Boundary-00=_RrpbQHKCt+klFsv-- From xen-devel-bounces@lists.xen.org Fri Oct 05 08:32:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 08:32:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK3KH-0006hL-IU; Fri, 05 Oct 2012 08:32:05 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK3KG-0006hG-4E for xen-devel@lists.xen.org; Fri, 05 Oct 2012 08:32:04 +0000 Received: from [85.158.139.83:9631] by server-3.bemta-5.messagelabs.com id 3B/1A-16108-30B9E605; Fri, 05 Oct 2012 08:32:03 +0000 X-Env-Sender: muehlenhoff@univention.de X-Msg-Ref: server-6.tower-182.messagelabs.com!1349425918!29644742!1 X-Originating-IP: [82.198.197.8] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7215 invoked from network); 5 Oct 2012 08:31:59 -0000 Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8) by server-6.tower-182.messagelabs.com with SMTP; 5 Oct 2012 08:31:59 -0000 Received: from localhost (localhost [127.0.0.1]) by slugis.knut.univention.de (Postfix) with ESMTP id 3F578E5B105 for ; Fri, 5 Oct 2012 10:31:59 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by slugis.knut.univention.de (Postfix) with ESMTP id 33F0FE5B101 for ; Fri, 5 Oct 2012 10:31:59 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.6.1 (20080629) (Debian) at knut.univention.de Received: from mail.univention.de ([127.0.0.1]) by localhost (slugis.knut.univention.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Of9mZqjsAtiG for ; Fri, 5 Oct 2012 10:31:58 +0200 (CEST) Received: from vurm.localnet (mail.univention.de [82.198.197.8]) by slugis.knut.univention.de (Postfix) with ESMTPSA id 6BFE0E5B105 for ; Fri, 5 Oct 2012 10:31:58 +0200 (CEST) From: Moritz =?iso-8859-1?q?M=FChlenhoff?= Organization: Univention GmbH To: "xen-devel@lists.xen.org" Date: Fri, 5 Oct 2012 10:31:13 +0200 User-Agent: KMail/1.13.7 (Linux/3.2.0-3-amd64; KDE/4.8.4; x86_64; ; ) MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_RrpbQHKCt+klFsv" Message-Id: <201210051031.13377.muehlenhoff@univention.de> Subject: [Xen-devel] Compilation fixes for blktap kernel patch X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --Boundary-00=_RrpbQHKCt+klFsv Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I hope this is the correct mailing list for the blktap patches available at ftp://ftp.enjellic.com/pub/xen/ ? When integrating the patch into Linux 3.2.30 I noticed two compile errors=20 related to a missing include of module.h: /var/build/temp/tmp.TujmUayDmG/3.1-0-0/linux/linux-3.2.30/drivers/block/blk= tap/ring.c:536:=20 error: 'THIS_MODULE' undeclared here (not in a function) I'm attaching patches against the=20 ftp://ftp.enjellic.com/pub/xen/blktap2-3.2.patch patch Cheers, Moritz =2D-=20 Moritz M=FChlenhoff Open Source Software Engineer Univention GmbH be open. Mary-Somerville-Str.1 28359 Bremen Tel. : +49 421 22232-0 [.....] =46ax : +49 421 22232-99 muehlenhoff@univention.de http://www.univention.de Gesch=E4ftsf=FChrer: Peter H. Ganten HRB 20755 Amtsgericht Bremen Steuer-Nr.: 71-597-02876=20 --Boundary-00=_RrpbQHKCt+klFsv Content-Type: text/x-patch; charset="UTF-8"; name="fix-blktap-patch1.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="fix-blktap-patch1.diff" =46rom: Moritz M=C3=BChlenhoff ring.c uses THIS_MODULE, so it needs to include Signed-off-by Moritz M=C3=BChlenhoff =2D-- 30-add-blktap-driver.patch.orig 2012-10-04 11:19:26.784050570 +0200 +++ 30-add-blktap-driver.patch 2012-10-04 11:18:51.244048852 +0200 @@ -1571,13 +1571,14 @@ diff -urNp v3.2/linux-3.2/drivers/block/blktap/ring.c linux-3.2/drivers/bl= ock/blktap/ring.c --- v3.2/linux-3.2/drivers/block/blktap/ring.c Wed Dec 31 18:00:00 1969 +++ linux-3.2/drivers/block/blktap/ring.c Mon Apr 9 14:48:24 2012 =2D@@ -0,0 +1,645 @@ +@@ -0,0 +1,646 @@ + +#include +#include +#include +#include +#include ++#include + +#include "blktap.h" + --Boundary-00=_RrpbQHKCt+klFsv Content-Type: text/x-patch; charset="UTF-8"; name="fix-blktap-patch2.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="fix-blktap-patch2.diff" =46rom: Moritz M=C3=BChlenhoff device.c uses THIS_MODULE, so it needs to include Signed-off-by Moritz M=C3=BChlenhoff =2D-- 30-add-blktap-driver.patch.orig 2012-10-04 11:18:51.244048852 +0200 +++ 30-add-blktap-driver.patch 2012-10-04 11:56:19.812157693 +0200 @@ -526,12 +526,13 @@ diff -urNp v3.2/linux-3.2/drivers/block/blktap/device.c linux-3.2/drivers/= block/blktap/device.c --- v3.2/linux-3.2/drivers/block/blktap/device.c Wed Dec 31 18:00:00 1969 +++ linux-3.2/drivers/block/blktap/device.c Mon Apr 9 14:48:24 2012 =2D@@ -0,0 +1,618 @@ +@@ -0,0 +1,619 @@ +#include +#include +#include +#include +#include ++#include +#include +#include + --Boundary-00=_RrpbQHKCt+klFsv Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --Boundary-00=_RrpbQHKCt+klFsv-- From xen-devel-bounces@lists.xen.org Fri Oct 05 08:47:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 08:47:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK3Ys-0006uQ-3g; Fri, 05 Oct 2012 08:47:10 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK3Yq-0006uL-6S for Xen-devel@lists.xen.org; Fri, 05 Oct 2012 08:47:08 +0000 X-Env-Sender: xinxinjin89@gmail.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1349426821!10235752!1 X-Originating-IP: [209.85.216.52] X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_00_10,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28123 invoked from network); 5 Oct 2012 08:47:02 -0000 Received: from mail-qa0-f52.google.com (HELO mail-qa0-f52.google.com) (209.85.216.52) by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 08:47:02 -0000 Received: by mail-qa0-f52.google.com with SMTP id g24so74170qab.11 for ; Fri, 05 Oct 2012 01:47:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=8uAXmPJP/l/4a0yyFqeLyd2Onm95HJN4Ov4JBdrTeeM=; b=Sr2dkpalAIu0xk9J5Q2RDZNm6+4zHfi4Nri/wAEZdr4qy7cGlvtB40aL3zP41vbj5+ l5LOfCjQlO5QPNcUueoF+V9S6l+cslh2kxZbMOAaWXChfyrmyoMsyHU7WEu3ltCxtW9X tCpRKEF8PWFP9IchdtGTm1TjVTkuwV+nHs/R2hvueVuJF2VyDTJlEPy4/aMbZ4R3lRz4 S6hmCUHAx7WvfnG1n2SXeq1J7ctVKE6xzuG9olBB1DY2ZtDO7pTp+QXJJBxHkcW9kmvk ADOSKT+I0DPA9etp/2OOxqhUGkEu3m0bKwoUiN8aAp8P027bMqGQbA9ZO6/3ywug9uVF YdcA== MIME-Version: 1.0 Received: by 10.49.82.199 with SMTP id k7mr23857543qey.52.1349426820557; Fri, 05 Oct 2012 01:47:00 -0700 (PDT) Received: by 10.229.176.85 with HTTP; Fri, 5 Oct 2012 01:47:00 -0700 (PDT) Date: Fri, 5 Oct 2012 01:47:00 -0700 Message-ID: From: Xinxin Jin To: Xen-devel@lists.xen.org Subject: [Xen-devel] Access domU's virtual address from Xen running on a different CPU X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1926390825447613203==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============1926390825447613203== Content-Type: multipart/alternative; boundary=047d7b6d89b24a295404cb4bea23 --047d7b6d89b24a295404cb4bea23 Content-Type: text/plain; charset=ISO-8859-1 Hi, I met a problem in an academic project and hope somebody can help me. Briefly speaking, I run dom1 and dom2 separately on CPU1 and CPU2. I wrote a program that triggers dom1 to trap into Xen hypervisor. At this point, Xen need to access a dom2's virtual address. So is there any way to map dom2's virtual address to CPU1? Or is it possible to make Xen running on CPU1 to walk dom2's page table? A lot of appreciation!! -- Xinxin --047d7b6d89b24a295404cb4bea23 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, I met a problem in an=A0academic project and hope somebody can hel= p me. Briefly speaking, I run dom1 and dom2 separately on CPU1 and CPU2. I = wrote a program that triggers dom1 to trap into Xen=A0hypervisor. At this p= oint, Xen need to access a dom2's virtual address. So is there any way = to map dom2's virtual address to CPU1? Or is it possible to make Xen ru= nning on CPU1 to walk dom2's page table?=A0
A lot of appreciation!!
--
Xinxin

--047d7b6d89b24a295404cb4bea23-- --===============1926390825447613203== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============1926390825447613203==-- From xen-devel-bounces@lists.xen.org Fri Oct 05 08:47:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 08:47:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK3Ys-0006uQ-3g; Fri, 05 Oct 2012 08:47:10 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK3Yq-0006uL-6S for Xen-devel@lists.xen.org; Fri, 05 Oct 2012 08:47:08 +0000 X-Env-Sender: xinxinjin89@gmail.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1349426821!10235752!1 X-Originating-IP: [209.85.216.52] X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_00_10,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28123 invoked from network); 5 Oct 2012 08:47:02 -0000 Received: from mail-qa0-f52.google.com (HELO mail-qa0-f52.google.com) (209.85.216.52) by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 08:47:02 -0000 Received: by mail-qa0-f52.google.com with SMTP id g24so74170qab.11 for ; Fri, 05 Oct 2012 01:47:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=8uAXmPJP/l/4a0yyFqeLyd2Onm95HJN4Ov4JBdrTeeM=; b=Sr2dkpalAIu0xk9J5Q2RDZNm6+4zHfi4Nri/wAEZdr4qy7cGlvtB40aL3zP41vbj5+ l5LOfCjQlO5QPNcUueoF+V9S6l+cslh2kxZbMOAaWXChfyrmyoMsyHU7WEu3ltCxtW9X tCpRKEF8PWFP9IchdtGTm1TjVTkuwV+nHs/R2hvueVuJF2VyDTJlEPy4/aMbZ4R3lRz4 S6hmCUHAx7WvfnG1n2SXeq1J7ctVKE6xzuG9olBB1DY2ZtDO7pTp+QXJJBxHkcW9kmvk ADOSKT+I0DPA9etp/2OOxqhUGkEu3m0bKwoUiN8aAp8P027bMqGQbA9ZO6/3ywug9uVF YdcA== MIME-Version: 1.0 Received: by 10.49.82.199 with SMTP id k7mr23857543qey.52.1349426820557; Fri, 05 Oct 2012 01:47:00 -0700 (PDT) Received: by 10.229.176.85 with HTTP; Fri, 5 Oct 2012 01:47:00 -0700 (PDT) Date: Fri, 5 Oct 2012 01:47:00 -0700 Message-ID: From: Xinxin Jin To: Xen-devel@lists.xen.org Subject: [Xen-devel] Access domU's virtual address from Xen running on a different CPU X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1926390825447613203==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============1926390825447613203== Content-Type: multipart/alternative; boundary=047d7b6d89b24a295404cb4bea23 --047d7b6d89b24a295404cb4bea23 Content-Type: text/plain; charset=ISO-8859-1 Hi, I met a problem in an academic project and hope somebody can help me. Briefly speaking, I run dom1 and dom2 separately on CPU1 and CPU2. I wrote a program that triggers dom1 to trap into Xen hypervisor. At this point, Xen need to access a dom2's virtual address. So is there any way to map dom2's virtual address to CPU1? Or is it possible to make Xen running on CPU1 to walk dom2's page table? A lot of appreciation!! -- Xinxin --047d7b6d89b24a295404cb4bea23 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, I met a problem in an=A0academic project and hope somebody can hel= p me. Briefly speaking, I run dom1 and dom2 separately on CPU1 and CPU2. I = wrote a program that triggers dom1 to trap into Xen=A0hypervisor. At this p= oint, Xen need to access a dom2's virtual address. So is there any way = to map dom2's virtual address to CPU1? Or is it possible to make Xen ru= nning on CPU1 to walk dom2's page table?=A0
A lot of appreciation!!
--
Xinxin

--047d7b6d89b24a295404cb4bea23-- --===============1926390825447613203== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============1926390825447613203==-- From xen-devel-bounces@lists.xen.org Fri Oct 05 08:52:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 08:52:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK3dj-00072J-Qx; Fri, 05 Oct 2012 08:52:11 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK3di-00072A-KD for xen-devel@lists.xen.org; Fri, 05 Oct 2012 08:52:10 +0000 Received: from [85.158.138.51:27733] by server-16.bemta-3.messagelabs.com id 06/00-04167-9BF9E605; Fri, 05 Oct 2012 08:52:09 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-5.tower-174.messagelabs.com!1349427128!33280017!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13172 invoked from network); 5 Oct 2012 08:52:08 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-5.tower-174.messagelabs.com with SMTP; 5 Oct 2012 08:52:08 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 05 Oct 2012 09:52:07 +0100 Message-Id: <506EBBD7020000780009FD84@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 05 Oct 2012 09:52:07 +0100 From: "Jan Beulich" To: "Jean Guyader" References: <1348141322-28657-1-git-send-email-jean.guyader@citrix.com> <1348141322-28657-5-git-send-email-jean.guyader@citrix.com> <505B2636020000780009CAA6@nat28.tlf.novell.com> <506D98FE020000780009FA23@nat28.tlf.novell.com> <20121004151214.GG38243@ocelot.phlegethon.org> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: Tim Deegan , Jean Guyader , xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH 4/4] xen: Add V4V implementation X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 04.10.12 at 19:00, Jean Guyader wrote: > On 4 October 2012 16:12, Tim Deegan wrote: >> AIUI you need to use compat_handle_okay() instead of guest_handle_okay() >> to check the handles if is_pv_32on64_domain(current). >> > > How about something like that? Could be done, but not by modifying guest_handle_okay() (which penalizes all its users), nor by (incorrectly) open-coding compat_handle_okay(). And neither should any such implementation use is_pv_32on64_domain() twice - use the conditional operator instead (that way you also avoid evaluating arguments twice). So you could either introduce e.g. any_guest_handle_okay(), or switch all current users of guest_handle_okay() to, say, native_handle_okay() (perhaps with the exception of those where the compat mode wrapper source files #define guest_handle_okay() to compat_handle_okay(), which could then be dropped). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 08:52:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 08:52:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK3dj-00072J-Qx; Fri, 05 Oct 2012 08:52:11 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK3di-00072A-KD for xen-devel@lists.xen.org; Fri, 05 Oct 2012 08:52:10 +0000 Received: from [85.158.138.51:27733] by server-16.bemta-3.messagelabs.com id 06/00-04167-9BF9E605; Fri, 05 Oct 2012 08:52:09 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-5.tower-174.messagelabs.com!1349427128!33280017!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13172 invoked from network); 5 Oct 2012 08:52:08 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-5.tower-174.messagelabs.com with SMTP; 5 Oct 2012 08:52:08 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 05 Oct 2012 09:52:07 +0100 Message-Id: <506EBBD7020000780009FD84@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 05 Oct 2012 09:52:07 +0100 From: "Jan Beulich" To: "Jean Guyader" References: <1348141322-28657-1-git-send-email-jean.guyader@citrix.com> <1348141322-28657-5-git-send-email-jean.guyader@citrix.com> <505B2636020000780009CAA6@nat28.tlf.novell.com> <506D98FE020000780009FA23@nat28.tlf.novell.com> <20121004151214.GG38243@ocelot.phlegethon.org> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: Tim Deegan , Jean Guyader , xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH 4/4] xen: Add V4V implementation X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 04.10.12 at 19:00, Jean Guyader wrote: > On 4 October 2012 16:12, Tim Deegan wrote: >> AIUI you need to use compat_handle_okay() instead of guest_handle_okay() >> to check the handles if is_pv_32on64_domain(current). >> > > How about something like that? Could be done, but not by modifying guest_handle_okay() (which penalizes all its users), nor by (incorrectly) open-coding compat_handle_okay(). And neither should any such implementation use is_pv_32on64_domain() twice - use the conditional operator instead (that way you also avoid evaluating arguments twice). So you could either introduce e.g. any_guest_handle_okay(), or switch all current users of guest_handle_okay() to, say, native_handle_okay() (perhaps with the exception of those where the compat mode wrapper source files #define guest_handle_okay() to compat_handle_okay(), which could then be dropped). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 09:05:05 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 09:05:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK3pr-0007Gs-Am; Fri, 05 Oct 2012 09:04:43 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK3pp-0007Gi-I1 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 09:04:41 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1349427874!8849042!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODA1MjM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21487 invoked from network); 5 Oct 2012 09:04:35 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 09:04:35 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="210390256" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 09:04:33 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 05:04:33 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK3pg-000257-Qy; Fri, 05 Oct 2012 10:04:32 +0100 From: Anthony PERARD To: Xen Devel Date: Fri, 5 Oct 2012 10:04:28 +0100 Message-ID: <1349427871-31195-1-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 MIME-Version: 1.0 Cc: Anthony PERARD , Ian Jackson , Ian Campbell Subject: [Xen-devel] [PATCH V3 0/3] Cleanup: flexarray taking gc. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This two patches do a bit of cleanup in the memomy managment in libxl, regarding the use of flexarray. The first one modify flexarray_make to take gc as argument and update every user in libxl to pass gc and to not call flexarray_free anymore. The second one does some cleanup only in libxl_json to make it use the gc. Change since v2: - New patch to expose gc_is_real to libxl. Change since v1: - Change order of the two patch to not end up with leaks. - Add a comment on the first patch to tell why it OK to store the gc in the flexarray struct. - Keep the _free functions (libxl__json_object_free and flexarray_free, as they can be used if gc in NOGC. Anthony PERARD (3): libxl: Move gc_is_real to libxl_internal.h. libxl: Have flexarray using the GC libxl_json: Use libxl alloc function. tools/libxl/flexarray.c | 43 +++++++++++-------- tools/libxl/flexarray.h | 7 +++- tools/libxl/libxl.c | 99 +++++++++----------------------------------- tools/libxl/libxl_dm.c | 15 ++----- tools/libxl/libxl_internal.c | 11 ++--- tools/libxl/libxl_internal.h | 5 +++ tools/libxl/libxl_json.c | 93 +++++++++-------------------------------- tools/libxl/libxl_pci.c | 18 ++------ tools/libxl/libxl_qmp.c | 29 ++----------- 9 files changed, 86 insertions(+), 234 deletions(-) -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 09:05:05 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 09:05:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK3pr-0007Gs-Am; Fri, 05 Oct 2012 09:04:43 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK3pp-0007Gi-I1 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 09:04:41 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1349427874!8849042!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODA1MjM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21487 invoked from network); 5 Oct 2012 09:04:35 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 09:04:35 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="210390256" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 09:04:33 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 05:04:33 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK3pg-000257-Qy; Fri, 05 Oct 2012 10:04:32 +0100 From: Anthony PERARD To: Xen Devel Date: Fri, 5 Oct 2012 10:04:28 +0100 Message-ID: <1349427871-31195-1-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 MIME-Version: 1.0 Cc: Anthony PERARD , Ian Jackson , Ian Campbell Subject: [Xen-devel] [PATCH V3 0/3] Cleanup: flexarray taking gc. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This two patches do a bit of cleanup in the memomy managment in libxl, regarding the use of flexarray. The first one modify flexarray_make to take gc as argument and update every user in libxl to pass gc and to not call flexarray_free anymore. The second one does some cleanup only in libxl_json to make it use the gc. Change since v2: - New patch to expose gc_is_real to libxl. Change since v1: - Change order of the two patch to not end up with leaks. - Add a comment on the first patch to tell why it OK to store the gc in the flexarray struct. - Keep the _free functions (libxl__json_object_free and flexarray_free, as they can be used if gc in NOGC. Anthony PERARD (3): libxl: Move gc_is_real to libxl_internal.h. libxl: Have flexarray using the GC libxl_json: Use libxl alloc function. tools/libxl/flexarray.c | 43 +++++++++++-------- tools/libxl/flexarray.h | 7 +++- tools/libxl/libxl.c | 99 +++++++++----------------------------------- tools/libxl/libxl_dm.c | 15 ++----- tools/libxl/libxl_internal.c | 11 ++--- tools/libxl/libxl_internal.h | 5 +++ tools/libxl/libxl_json.c | 93 +++++++++-------------------------------- tools/libxl/libxl_pci.c | 18 ++------ tools/libxl/libxl_qmp.c | 29 ++----------- 9 files changed, 86 insertions(+), 234 deletions(-) -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 09:05:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 09:05:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK3ps-0007Gz-Me; Fri, 05 Oct 2012 09:04:44 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK3pr-0007Gj-0Q for xen-devel@lists.xen.org; Fri, 05 Oct 2012 09:04:43 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1349427874!8849042!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODA1MjM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21573 invoked from network); 5 Oct 2012 09:04:36 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 09:04:36 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="210390257" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 09:04:33 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 05:04:33 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK3pg-000257-RO; Fri, 05 Oct 2012 10:04:32 +0100 From: Anthony PERARD To: Xen Devel Date: Fri, 5 Oct 2012 10:04:29 +0100 Message-ID: <1349427871-31195-2-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1349427871-31195-1-git-send-email-anthony.perard@citrix.com> References: <1349427871-31195-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Cc: Anthony PERARD , Ian Jackson , Ian Campbell Subject: [Xen-devel] [PATCH V3 1/3] libxl: Move gc_is_real to libxl_internal.h. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Anthony PERARD --- tools/libxl/libxl_internal.c | 11 +++-------- tools/libxl/libxl_internal.h | 5 +++++ 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c index 211c8f5..5a8cd38 100644 --- a/tools/libxl/libxl_internal.c +++ b/tools/libxl/libxl_internal.c @@ -30,16 +30,11 @@ void libxl__alloc_failed(libxl_ctx *ctx, const char *func, #undef L } -static int gc_is_real(const libxl__gc *gc) -{ - return gc->alloc_maxsize >= 0; -} - void libxl__ptr_add(libxl__gc *gc, void *ptr) { int i; - if (!gc_is_real(gc)) + if (!libxl__gc_is_real(gc)) return; if (!ptr) @@ -71,7 +66,7 @@ void libxl__free_all(libxl__gc *gc) void *ptr; int i; - assert(gc_is_real(gc)); + assert(libxl__gc_is_real(gc)); for (i = 0; i < gc->alloc_maxsize; i++) { ptr = gc->alloc_ptrs[i]; @@ -111,7 +106,7 @@ void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size) if (ptr == NULL) { libxl__ptr_add(gc, new_ptr); - } else if (new_ptr != ptr && gc_is_real(gc)) { + } else if (new_ptr != ptr && libxl__gc_is_real(gc)) { for (i = 0; i < gc->alloc_maxsize; i++) { if (gc->alloc_ptrs[i] == ptr) { gc->alloc_ptrs[i] = new_ptr; diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index b6f54ba..c0e879d 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -446,6 +446,11 @@ static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc) return gc->owner; } +static inline int libxl__gc_is_real(const libxl__gc *gc) +{ + return gc->alloc_maxsize >= 0; +} + /* * Memory allocation tracking/helpers * -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 09:05:12 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 09:05:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK3ps-0007Gz-Me; Fri, 05 Oct 2012 09:04:44 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK3pr-0007Gj-0Q for xen-devel@lists.xen.org; Fri, 05 Oct 2012 09:04:43 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1349427874!8849042!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODA1MjM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21573 invoked from network); 5 Oct 2012 09:04:36 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 09:04:36 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="210390257" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 09:04:33 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 05:04:33 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK3pg-000257-RO; Fri, 05 Oct 2012 10:04:32 +0100 From: Anthony PERARD To: Xen Devel Date: Fri, 5 Oct 2012 10:04:29 +0100 Message-ID: <1349427871-31195-2-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1349427871-31195-1-git-send-email-anthony.perard@citrix.com> References: <1349427871-31195-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Cc: Anthony PERARD , Ian Jackson , Ian Campbell Subject: [Xen-devel] [PATCH V3 1/3] libxl: Move gc_is_real to libxl_internal.h. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Anthony PERARD --- tools/libxl/libxl_internal.c | 11 +++-------- tools/libxl/libxl_internal.h | 5 +++++ 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c index 211c8f5..5a8cd38 100644 --- a/tools/libxl/libxl_internal.c +++ b/tools/libxl/libxl_internal.c @@ -30,16 +30,11 @@ void libxl__alloc_failed(libxl_ctx *ctx, const char *func, #undef L } -static int gc_is_real(const libxl__gc *gc) -{ - return gc->alloc_maxsize >= 0; -} - void libxl__ptr_add(libxl__gc *gc, void *ptr) { int i; - if (!gc_is_real(gc)) + if (!libxl__gc_is_real(gc)) return; if (!ptr) @@ -71,7 +66,7 @@ void libxl__free_all(libxl__gc *gc) void *ptr; int i; - assert(gc_is_real(gc)); + assert(libxl__gc_is_real(gc)); for (i = 0; i < gc->alloc_maxsize; i++) { ptr = gc->alloc_ptrs[i]; @@ -111,7 +106,7 @@ void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size) if (ptr == NULL) { libxl__ptr_add(gc, new_ptr); - } else if (new_ptr != ptr && gc_is_real(gc)) { + } else if (new_ptr != ptr && libxl__gc_is_real(gc)) { for (i = 0; i < gc->alloc_maxsize; i++) { if (gc->alloc_ptrs[i] == ptr) { gc->alloc_ptrs[i] = new_ptr; diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index b6f54ba..c0e879d 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -446,6 +446,11 @@ static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc) return gc->owner; } +static inline int libxl__gc_is_real(const libxl__gc *gc) +{ + return gc->alloc_maxsize >= 0; +} + /* * Memory allocation tracking/helpers * -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 09:05:22 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 09:05:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK3qE-0007JR-Gr; Fri, 05 Oct 2012 09:05:06 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK3qD-0007IM-A7 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 09:05:05 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1349427896!1709726!2 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQzOTY=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9768 invoked from network); 5 Oct 2012 09:04:58 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 09:04:58 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="40242086" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 09:04:33 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 05:04:33 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK3pg-000257-Rj; Fri, 05 Oct 2012 10:04:32 +0100 From: Anthony PERARD To: Xen Devel Date: Fri, 5 Oct 2012 10:04:30 +0100 Message-ID: <1349427871-31195-3-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1349427871-31195-1-git-send-email-anthony.perard@citrix.com> References: <1349427871-31195-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Cc: Anthony PERARD , Ian Jackson , Ian Campbell Subject: [Xen-devel] [PATCH V3 2/3] libxl: Have flexarray using the GC X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch makes the flexarray function libxl__gc aware. It also updates every function that use a flexarray to pass the gc and removes every memory allocation check and free. Signed-off-by: Anthony PERARD --- tools/libxl/flexarray.c | 43 ++++++++++++--------- tools/libxl/flexarray.h | 7 +++- tools/libxl/libxl.c | 99 ++++++++++-------------------------------------- tools/libxl/libxl_dm.c | 15 ++------ tools/libxl/libxl_json.c | 8 +--- tools/libxl/libxl_pci.c | 18 ++------- tools/libxl/libxl_qmp.c | 28 ++------------ 7 files changed, 60 insertions(+), 158 deletions(-) diff --git a/tools/libxl/flexarray.c b/tools/libxl/flexarray.c index edf616c..fe40e76 100644 --- a/tools/libxl/flexarray.c +++ b/tools/libxl/flexarray.c @@ -16,36 +16,43 @@ #include "libxl_internal.h" #include -flexarray_t *flexarray_make(int size, int autogrow) +/* + * It is safe to store gc in the struct because: + * - If it an actual gc, then the flexarray should not be used after the gc + * have been freed. + * - If it is a NOGC, then this point to a structure embedded in libxl_ctx, + * therefore will survive across several libxl calls. + */ + +flexarray_t *flexarray_make(libxl__gc *gc, int size, int autogrow) { - flexarray_t *array = malloc(sizeof(struct flexarray)); - if (array) { - array->size = size; - array->autogrow = autogrow; - array->count = 0; - array->data = calloc(size, sizeof(void *)); - } + flexarray_t *array; + + GCNEW(array); + array->size = size; + array->autogrow = autogrow; + array->count = 0; + array->gc = gc; + GCNEW_ARRAY(array->data, size); + return array; } void flexarray_free(flexarray_t *array) { + assert(!libxl__gc_is_real(array->gc)); free(array->data); free(array); } -int flexarray_grow(flexarray_t *array, int extents) +void flexarray_grow(flexarray_t *array, int extents) { - void **data; int newsize; + libxl__gc *gc = array->gc; newsize = array->size + extents; - data = realloc(array->data, sizeof(void *) * newsize); - if (!data) - return 1; + GCREALLOC_ARRAY(array->data, newsize); array->size += extents; - array->data = data; - return 0; } int flexarray_set(flexarray_t *array, unsigned int idx, void *ptr) @@ -55,8 +62,7 @@ int flexarray_set(flexarray_t *array, unsigned int idx, void *ptr) if (!array->autogrow) return 1; newsize = (array->size * 2 < idx) ? idx + 1 : array->size * 2; - if (flexarray_grow(array, newsize - array->size)) - return 2; + flexarray_grow(array, newsize - array->size); } if ( idx + 1 > array->count ) array->count = idx + 1; @@ -104,7 +110,8 @@ void **flexarray_contents(flexarray_t *array) { void **data; data = array->data; - free(array); + if (!libxl__gc_is_real(array->gc)) + free(array); return data; } diff --git a/tools/libxl/flexarray.h b/tools/libxl/flexarray.h index ae17f3b..aade417 100644 --- a/tools/libxl/flexarray.h +++ b/tools/libxl/flexarray.h @@ -16,16 +16,19 @@ #ifndef FLEXARRAY_H #define FLEXARRAY_H +struct libxl__gc; + typedef struct flexarray { int size; int autogrow; unsigned int count; void **data; /* array of pointer */ + struct libxl__gc *gc; } flexarray_t; -_hidden flexarray_t *flexarray_make(int size, int autogrow); +_hidden flexarray_t *flexarray_make(struct libxl__gc *gc, int size, int autogrow); _hidden void flexarray_free(flexarray_t *array); -_hidden int flexarray_grow(flexarray_t *array, int extents); +_hidden void flexarray_grow(flexarray_t *array, int extents); _hidden int flexarray_set(flexarray_t *array, unsigned int index, void *ptr); _hidden int flexarray_append(flexarray_t *array, void *ptr); _hidden int flexarray_append_pair(flexarray_t *array, void *ptr1, void *ptr2); diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c index 1606eb1..af3682f 100644 --- a/tools/libxl/libxl.c +++ b/tools/libxl/libxl.c @@ -1820,27 +1820,15 @@ static void device_disk_add(libxl__egc *egc, uint32_t domid, rc = libxl__device_disk_setdefault(gc, disk); if (rc) goto out; - if (front) - flexarray_free(front); - front = flexarray_make(16, 1); - if (!front) { - rc = ERROR_NOMEM; - goto out; - } - if (back) - flexarray_free(back); - back = flexarray_make(16, 1); - if (!back) { - rc = ERROR_NOMEM; - goto out_free; - } + front = flexarray_make(gc, 16, 1); + back = flexarray_make(gc, 16, 1); GCNEW(device); rc = libxl__device_from_disk(gc, domid, disk, device); if (rc != 0) { LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported" " virtual disk identifier %s", disk->vdev); - goto out_free; + goto out; } switch (disk->backend) { @@ -1878,7 +1866,7 @@ static void device_disk_add(libxl__egc *egc, uint32_t domid, LOG(ERROR, "failed to get blktap devpath for %p\n", disk->pdev_path); rc = ERROR_FAIL; - goto out_free; + goto out; } flexarray_append(back, "tapdisk-params"); flexarray_append(back, libxl__sprintf(gc, "%s:%s", @@ -1900,7 +1888,7 @@ static void device_disk_add(libxl__egc *egc, uint32_t domid, default: LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n", disk->backend); rc = ERROR_INVAL; - goto out_free; + goto out; } flexarray_append(back, "frontend-id"); @@ -1937,7 +1925,7 @@ static void device_disk_add(libxl__egc *egc, uint32_t domid, rc = libxl__xs_transaction_commit(gc, &t); if (!rc) break; - if (rc < 0) goto out_free; + if (rc < 0) goto out; } aodev->dev = device; @@ -1946,9 +1934,6 @@ static void device_disk_add(libxl__egc *egc, uint32_t domid, rc = 0; -out_free: - flexarray_free(back); - flexarray_free(front); out: libxl__xs_transaction_abort(gc, &t); aodev->rc = rc; @@ -2204,7 +2189,7 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk, if (rc) goto out; path = libxl__device_backend_path(gc, &device); - insert = flexarray_make(4, 1); + insert = flexarray_make(gc, 4, 1); flexarray_append_pair(insert, "type", libxl__device_disk_string_of_backend(disk->backend)); @@ -2230,8 +2215,6 @@ out: libxl_device_disk_dispose(&disks[i]); free(disks); - if (insert) flexarray_free(insert); - if (rc) return AO_ABORT(rc); return AO_INPROGRESS; } @@ -2567,21 +2550,13 @@ void libxl__device_nic_add(libxl__egc *egc, uint32_t domid, rc = libxl__device_nic_setdefault(gc, nic, domid); if (rc) goto out; - front = flexarray_make(16, 1); - if (!front) { - rc = ERROR_NOMEM; - goto out; - } - back = flexarray_make(16, 1); - if (!back) { - rc = ERROR_NOMEM; - goto out_free; - } + front = flexarray_make(gc, 16, 1); + back = flexarray_make(gc, 16, 1); if (nic->devid == -1) { if (!(dompath = libxl__xs_get_dompath(gc, domid))) { rc = ERROR_FAIL; - goto out_free; + goto out; } if (!(l = libxl__xs_directory(gc, XBT_NULL, libxl__sprintf(gc, "%s/device/vif", dompath), &nb))) { @@ -2593,7 +2568,7 @@ void libxl__device_nic_add(libxl__egc *egc, uint32_t domid, GCNEW(device); rc = libxl__device_from_nic(gc, domid, nic, device); - if ( rc != 0 ) goto out_free; + if ( rc != 0 ) goto out; flexarray_append(back, "frontend-id"); flexarray_append(back, libxl__sprintf(gc, "%d", domid)); @@ -2652,9 +2627,6 @@ void libxl__device_nic_add(libxl__egc *egc, uint32_t domid, libxl__wait_device_connection(egc, aodev); rc = 0; -out_free: - flexarray_free(back); - flexarray_free(front); out: aodev->rc = rc; if (rc) aodev->callback(egc, aodev); @@ -2851,16 +2823,8 @@ int libxl__device_console_add(libxl__gc *gc, uint32_t domid, goto out; } - front = flexarray_make(16, 1); - if (!front) { - rc = ERROR_NOMEM; - goto out; - } - back = flexarray_make(16, 1); - if (!back) { - rc = ERROR_NOMEM; - goto out_free; - } + front = flexarray_make(gc, 16, 1); + back = flexarray_make(gc, 16, 1); device.backend_devid = console->devid; device.backend_domid = console->backend_domid; @@ -2908,9 +2872,6 @@ int libxl__device_console_add(libxl__gc *gc, uint32_t domid, libxl__xs_kvs_of_flexarray(gc, back, back->count), libxl__xs_kvs_of_flexarray(gc, front, front->count)); rc = 0; -out_free: - flexarray_free(back); - flexarray_free(front); out: return rc; } @@ -2964,19 +2925,11 @@ int libxl__device_vkb_add(libxl__gc *gc, uint32_t domid, rc = libxl__device_vkb_setdefault(gc, vkb); if (rc) goto out; - front = flexarray_make(16, 1); - if (!front) { - rc = ERROR_NOMEM; - goto out; - } - back = flexarray_make(16, 1); - if (!back) { - rc = ERROR_NOMEM; - goto out_free; - } + front = flexarray_make(gc, 16, 1); + back = flexarray_make(gc, 16, 1); rc = libxl__device_from_vkb(gc, domid, vkb, &device); - if (rc != 0) goto out_free; + if (rc != 0) goto out; flexarray_append(back, "frontend-id"); flexarray_append(back, libxl__sprintf(gc, "%d", domid)); @@ -2996,9 +2949,6 @@ int libxl__device_vkb_add(libxl__gc *gc, uint32_t domid, libxl__xs_kvs_of_flexarray(gc, back, back->count), libxl__xs_kvs_of_flexarray(gc, front, front->count)); rc = 0; -out_free: - flexarray_free(back); - flexarray_free(front); out: return rc; } @@ -3063,19 +3013,11 @@ int libxl__device_vfb_add(libxl__gc *gc, uint32_t domid, libxl_device_vfb *vfb) rc = libxl__device_vfb_setdefault(gc, vfb); if (rc) goto out; - front = flexarray_make(16, 1); - if (!front) { - rc = ERROR_NOMEM; - goto out; - } - back = flexarray_make(16, 1); - if (!back) { - rc = ERROR_NOMEM; - goto out_free; - } + front = flexarray_make(gc, 16, 1); + back = flexarray_make(gc, 16, 1); rc = libxl__device_from_vfb(gc, domid, vfb, &device); - if (rc != 0) goto out_free; + if (rc != 0) goto out; flexarray_append_pair(back, "frontend-id", libxl__sprintf(gc, "%d", domid)); flexarray_append_pair(back, "online", "1"); @@ -3108,9 +3050,6 @@ int libxl__device_vfb_add(libxl__gc *gc, uint32_t domid, libxl_device_vfb *vfb) libxl__xs_kvs_of_flexarray(gc, back, back->count), libxl__xs_kvs_of_flexarray(gc, front, front->count)); rc = 0; -out_free: - flexarray_free(front); - flexarray_free(back); out: return rc; } diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c index 3be7bad..82d2009 100644 --- a/tools/libxl/libxl_dm.c +++ b/tools/libxl/libxl_dm.c @@ -109,10 +109,7 @@ static char ** libxl__build_device_model_args_old(libxl__gc *gc, const char *keymap = dm_keymap(guest_config); int i; flexarray_t *dm_args; - dm_args = flexarray_make(16, 1); - - if (!dm_args) - return NULL; + dm_args = flexarray_make(gc, 16, 1); flexarray_vappend(dm_args, dm, "-d", libxl__sprintf(gc, "%d", domid), NULL); @@ -340,9 +337,7 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc, int i; uint64_t ram_size; - dm_args = flexarray_make(16, 1); - if (!dm_args) - return NULL; + dm_args = flexarray_make(gc, 16, 1); flexarray_vappend(dm_args, dm, "-xen-domid", @@ -837,7 +832,7 @@ void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state *sdss) "setting target domain %d -> %d", dm_domid, guest_domid); ret = ERROR_FAIL; - goto out_free; + goto out; } xs_set_target(ctx->xsh, dm_domid, guest_domid); @@ -861,11 +856,8 @@ retry_transaction: libxl__add_disks(egc, ao, dm_domid, dm_config, &sdss->multidev); libxl__multidev_prepared(egc, &sdss->multidev, 0); - free(args); return; -out_free: - free(args); out: assert(ret); spawn_stubdom_pvqemu_cb(egc, &sdss->pvqemu, ret); @@ -1165,7 +1157,6 @@ retry_transaction: out_close: close(null); close(logfile_w); - free(args); out: if (rc) device_model_spawn_outcome(egc, dmss, rc); diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c index 8e17842..2e6322b 100644 --- a/tools/libxl/libxl_json.c +++ b/tools/libxl/libxl_json.c @@ -220,13 +220,7 @@ static libxl__json_object *json_object_alloc(libxl__gc *gc, obj->type = type; if (type == JSON_MAP || type == JSON_ARRAY) { - flexarray_t *array = flexarray_make(1, 1); - if (array == NULL) { - LIBXL__LOG_ERRNO(libxl__gc_owner(gc), LIBXL__LOG_ERROR, - "Failed to allocate a flexarray"); - free(obj); - return NULL; - } + flexarray_t *array = flexarray_make(NOGC, 1, 1); if (type == JSON_MAP) obj->u.map = array; else diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c index ff447e7..eac35c1 100644 --- a/tools/libxl/libxl_pci.c +++ b/tools/libxl/libxl_pci.c @@ -73,12 +73,8 @@ int libxl__create_pci_backend(libxl__gc *gc, uint32_t domid, libxl__device device; int ret = ERROR_NOMEM, i; - front = flexarray_make(16, 1); - if (!front) - goto out; - back = flexarray_make(16, 1); - if (!back) - goto out; + front = flexarray_make(gc, 16, 1); + back = flexarray_make(gc, 16, 1); ret = 0; @@ -108,11 +104,6 @@ int libxl__create_pci_backend(libxl__gc *gc, uint32_t domid, libxl__xs_kvs_of_flexarray(gc, back, back->count), libxl__xs_kvs_of_flexarray(gc, front, front->count)); -out: - if (back) - flexarray_free(back); - if (front) - flexarray_free(front); return 0; } @@ -138,9 +129,7 @@ static int libxl__device_pci_add_xenstore(libxl__gc *gc, uint32_t domid, libxl_d return ERROR_FAIL; } - back = flexarray_make(16, 1); - if (!back) - return ERROR_NOMEM; + back = flexarray_make(gc, 16, 1); LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Adding new pci device to xenstore"); num = atoi(num_devs); @@ -157,7 +146,6 @@ retry_transaction: if (errno == EAGAIN) goto retry_transaction; - flexarray_free(back); return 0; } diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c index 2c4d269..6bdf924 100644 --- a/tools/libxl/libxl_qmp.c +++ b/tools/libxl/libxl_qmp.c @@ -763,7 +763,7 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev) if (!hostaddr) return -1; - parameters = flexarray_make(6, 1); + parameters = flexarray_make(gc, 6, 1); flexarray_append_pair(parameters, "driver", "xen-pci-passthrough"); flexarray_append_pair(parameters, "id", libxl__sprintf(gc, PCI_PT_QDEV_ID, @@ -777,8 +777,6 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev) PCI_FUNC(pcidev->vdevfn))); } args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count); - if (!args) - return -1; rc = qmp_synchronous_send(qmp, "device_add", &args, NULL, NULL, qmp->timeout); @@ -787,7 +785,6 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev) pci_add_callback, pcidev, qmp->timeout); } - flexarray_free(parameters); libxl__qmp_close(qmp); return rc; } @@ -803,16 +800,13 @@ static int qmp_device_del(libxl__gc *gc, int domid, char *id) if (!qmp) return ERROR_FAIL; - parameters = flexarray_make(2, 1); + parameters = flexarray_make(gc, 2, 1); flexarray_append_pair(parameters, "id", id); args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count); - if (!args) - return ERROR_NOMEM; rc = qmp_synchronous_send(qmp, "device_del", &args, NULL, NULL, qmp->timeout); - flexarray_free(parameters); libxl__qmp_close(qmp); return rc; } @@ -838,24 +832,13 @@ int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename) if (!qmp) return ERROR_FAIL; - parameters = flexarray_make(2, 1); - if (!parameters) { - rc = ERROR_NOMEM; - goto out; - } + parameters = flexarray_make(gc, 2, 1); flexarray_append_pair(parameters, "filename", (char *)filename); args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count); - if (!args) { - rc = ERROR_NOMEM; - goto out2; - } rc = qmp_synchronous_send(qmp, "xen-save-devices-state", &args, NULL, NULL, qmp->timeout); -out2: - flexarray_free(parameters); -out: libxl__qmp_close(qmp); return rc; } @@ -867,19 +850,16 @@ static int qmp_change(libxl__gc *gc, libxl__qmp_handler *qmp, libxl_key_value_list args = NULL; int rc = 0; - parameters = flexarray_make(6, 1); + parameters = flexarray_make(gc, 6, 1); flexarray_append_pair(parameters, "device", device); flexarray_append_pair(parameters, "target", target); if (arg) flexarray_append_pair(parameters, "arg", arg); args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count); - if (!args) - return ERROR_NOMEM; rc = qmp_synchronous_send(qmp, "change", &args, NULL, NULL, qmp->timeout); - flexarray_free(parameters); return rc; } -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 09:05:22 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 09:05:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK3qE-0007JR-Gr; Fri, 05 Oct 2012 09:05:06 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK3qD-0007IM-A7 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 09:05:05 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1349427896!1709726!2 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQzOTY=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9768 invoked from network); 5 Oct 2012 09:04:58 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 09:04:58 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="40242086" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 09:04:33 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 05:04:33 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK3pg-000257-Rj; Fri, 05 Oct 2012 10:04:32 +0100 From: Anthony PERARD To: Xen Devel Date: Fri, 5 Oct 2012 10:04:30 +0100 Message-ID: <1349427871-31195-3-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1349427871-31195-1-git-send-email-anthony.perard@citrix.com> References: <1349427871-31195-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Cc: Anthony PERARD , Ian Jackson , Ian Campbell Subject: [Xen-devel] [PATCH V3 2/3] libxl: Have flexarray using the GC X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch makes the flexarray function libxl__gc aware. It also updates every function that use a flexarray to pass the gc and removes every memory allocation check and free. Signed-off-by: Anthony PERARD --- tools/libxl/flexarray.c | 43 ++++++++++++--------- tools/libxl/flexarray.h | 7 +++- tools/libxl/libxl.c | 99 ++++++++++-------------------------------------- tools/libxl/libxl_dm.c | 15 ++------ tools/libxl/libxl_json.c | 8 +--- tools/libxl/libxl_pci.c | 18 ++------- tools/libxl/libxl_qmp.c | 28 ++------------ 7 files changed, 60 insertions(+), 158 deletions(-) diff --git a/tools/libxl/flexarray.c b/tools/libxl/flexarray.c index edf616c..fe40e76 100644 --- a/tools/libxl/flexarray.c +++ b/tools/libxl/flexarray.c @@ -16,36 +16,43 @@ #include "libxl_internal.h" #include -flexarray_t *flexarray_make(int size, int autogrow) +/* + * It is safe to store gc in the struct because: + * - If it an actual gc, then the flexarray should not be used after the gc + * have been freed. + * - If it is a NOGC, then this point to a structure embedded in libxl_ctx, + * therefore will survive across several libxl calls. + */ + +flexarray_t *flexarray_make(libxl__gc *gc, int size, int autogrow) { - flexarray_t *array = malloc(sizeof(struct flexarray)); - if (array) { - array->size = size; - array->autogrow = autogrow; - array->count = 0; - array->data = calloc(size, sizeof(void *)); - } + flexarray_t *array; + + GCNEW(array); + array->size = size; + array->autogrow = autogrow; + array->count = 0; + array->gc = gc; + GCNEW_ARRAY(array->data, size); + return array; } void flexarray_free(flexarray_t *array) { + assert(!libxl__gc_is_real(array->gc)); free(array->data); free(array); } -int flexarray_grow(flexarray_t *array, int extents) +void flexarray_grow(flexarray_t *array, int extents) { - void **data; int newsize; + libxl__gc *gc = array->gc; newsize = array->size + extents; - data = realloc(array->data, sizeof(void *) * newsize); - if (!data) - return 1; + GCREALLOC_ARRAY(array->data, newsize); array->size += extents; - array->data = data; - return 0; } int flexarray_set(flexarray_t *array, unsigned int idx, void *ptr) @@ -55,8 +62,7 @@ int flexarray_set(flexarray_t *array, unsigned int idx, void *ptr) if (!array->autogrow) return 1; newsize = (array->size * 2 < idx) ? idx + 1 : array->size * 2; - if (flexarray_grow(array, newsize - array->size)) - return 2; + flexarray_grow(array, newsize - array->size); } if ( idx + 1 > array->count ) array->count = idx + 1; @@ -104,7 +110,8 @@ void **flexarray_contents(flexarray_t *array) { void **data; data = array->data; - free(array); + if (!libxl__gc_is_real(array->gc)) + free(array); return data; } diff --git a/tools/libxl/flexarray.h b/tools/libxl/flexarray.h index ae17f3b..aade417 100644 --- a/tools/libxl/flexarray.h +++ b/tools/libxl/flexarray.h @@ -16,16 +16,19 @@ #ifndef FLEXARRAY_H #define FLEXARRAY_H +struct libxl__gc; + typedef struct flexarray { int size; int autogrow; unsigned int count; void **data; /* array of pointer */ + struct libxl__gc *gc; } flexarray_t; -_hidden flexarray_t *flexarray_make(int size, int autogrow); +_hidden flexarray_t *flexarray_make(struct libxl__gc *gc, int size, int autogrow); _hidden void flexarray_free(flexarray_t *array); -_hidden int flexarray_grow(flexarray_t *array, int extents); +_hidden void flexarray_grow(flexarray_t *array, int extents); _hidden int flexarray_set(flexarray_t *array, unsigned int index, void *ptr); _hidden int flexarray_append(flexarray_t *array, void *ptr); _hidden int flexarray_append_pair(flexarray_t *array, void *ptr1, void *ptr2); diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c index 1606eb1..af3682f 100644 --- a/tools/libxl/libxl.c +++ b/tools/libxl/libxl.c @@ -1820,27 +1820,15 @@ static void device_disk_add(libxl__egc *egc, uint32_t domid, rc = libxl__device_disk_setdefault(gc, disk); if (rc) goto out; - if (front) - flexarray_free(front); - front = flexarray_make(16, 1); - if (!front) { - rc = ERROR_NOMEM; - goto out; - } - if (back) - flexarray_free(back); - back = flexarray_make(16, 1); - if (!back) { - rc = ERROR_NOMEM; - goto out_free; - } + front = flexarray_make(gc, 16, 1); + back = flexarray_make(gc, 16, 1); GCNEW(device); rc = libxl__device_from_disk(gc, domid, disk, device); if (rc != 0) { LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Invalid or unsupported" " virtual disk identifier %s", disk->vdev); - goto out_free; + goto out; } switch (disk->backend) { @@ -1878,7 +1866,7 @@ static void device_disk_add(libxl__egc *egc, uint32_t domid, LOG(ERROR, "failed to get blktap devpath for %p\n", disk->pdev_path); rc = ERROR_FAIL; - goto out_free; + goto out; } flexarray_append(back, "tapdisk-params"); flexarray_append(back, libxl__sprintf(gc, "%s:%s", @@ -1900,7 +1888,7 @@ static void device_disk_add(libxl__egc *egc, uint32_t domid, default: LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n", disk->backend); rc = ERROR_INVAL; - goto out_free; + goto out; } flexarray_append(back, "frontend-id"); @@ -1937,7 +1925,7 @@ static void device_disk_add(libxl__egc *egc, uint32_t domid, rc = libxl__xs_transaction_commit(gc, &t); if (!rc) break; - if (rc < 0) goto out_free; + if (rc < 0) goto out; } aodev->dev = device; @@ -1946,9 +1934,6 @@ static void device_disk_add(libxl__egc *egc, uint32_t domid, rc = 0; -out_free: - flexarray_free(back); - flexarray_free(front); out: libxl__xs_transaction_abort(gc, &t); aodev->rc = rc; @@ -2204,7 +2189,7 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk, if (rc) goto out; path = libxl__device_backend_path(gc, &device); - insert = flexarray_make(4, 1); + insert = flexarray_make(gc, 4, 1); flexarray_append_pair(insert, "type", libxl__device_disk_string_of_backend(disk->backend)); @@ -2230,8 +2215,6 @@ out: libxl_device_disk_dispose(&disks[i]); free(disks); - if (insert) flexarray_free(insert); - if (rc) return AO_ABORT(rc); return AO_INPROGRESS; } @@ -2567,21 +2550,13 @@ void libxl__device_nic_add(libxl__egc *egc, uint32_t domid, rc = libxl__device_nic_setdefault(gc, nic, domid); if (rc) goto out; - front = flexarray_make(16, 1); - if (!front) { - rc = ERROR_NOMEM; - goto out; - } - back = flexarray_make(16, 1); - if (!back) { - rc = ERROR_NOMEM; - goto out_free; - } + front = flexarray_make(gc, 16, 1); + back = flexarray_make(gc, 16, 1); if (nic->devid == -1) { if (!(dompath = libxl__xs_get_dompath(gc, domid))) { rc = ERROR_FAIL; - goto out_free; + goto out; } if (!(l = libxl__xs_directory(gc, XBT_NULL, libxl__sprintf(gc, "%s/device/vif", dompath), &nb))) { @@ -2593,7 +2568,7 @@ void libxl__device_nic_add(libxl__egc *egc, uint32_t domid, GCNEW(device); rc = libxl__device_from_nic(gc, domid, nic, device); - if ( rc != 0 ) goto out_free; + if ( rc != 0 ) goto out; flexarray_append(back, "frontend-id"); flexarray_append(back, libxl__sprintf(gc, "%d", domid)); @@ -2652,9 +2627,6 @@ void libxl__device_nic_add(libxl__egc *egc, uint32_t domid, libxl__wait_device_connection(egc, aodev); rc = 0; -out_free: - flexarray_free(back); - flexarray_free(front); out: aodev->rc = rc; if (rc) aodev->callback(egc, aodev); @@ -2851,16 +2823,8 @@ int libxl__device_console_add(libxl__gc *gc, uint32_t domid, goto out; } - front = flexarray_make(16, 1); - if (!front) { - rc = ERROR_NOMEM; - goto out; - } - back = flexarray_make(16, 1); - if (!back) { - rc = ERROR_NOMEM; - goto out_free; - } + front = flexarray_make(gc, 16, 1); + back = flexarray_make(gc, 16, 1); device.backend_devid = console->devid; device.backend_domid = console->backend_domid; @@ -2908,9 +2872,6 @@ int libxl__device_console_add(libxl__gc *gc, uint32_t domid, libxl__xs_kvs_of_flexarray(gc, back, back->count), libxl__xs_kvs_of_flexarray(gc, front, front->count)); rc = 0; -out_free: - flexarray_free(back); - flexarray_free(front); out: return rc; } @@ -2964,19 +2925,11 @@ int libxl__device_vkb_add(libxl__gc *gc, uint32_t domid, rc = libxl__device_vkb_setdefault(gc, vkb); if (rc) goto out; - front = flexarray_make(16, 1); - if (!front) { - rc = ERROR_NOMEM; - goto out; - } - back = flexarray_make(16, 1); - if (!back) { - rc = ERROR_NOMEM; - goto out_free; - } + front = flexarray_make(gc, 16, 1); + back = flexarray_make(gc, 16, 1); rc = libxl__device_from_vkb(gc, domid, vkb, &device); - if (rc != 0) goto out_free; + if (rc != 0) goto out; flexarray_append(back, "frontend-id"); flexarray_append(back, libxl__sprintf(gc, "%d", domid)); @@ -2996,9 +2949,6 @@ int libxl__device_vkb_add(libxl__gc *gc, uint32_t domid, libxl__xs_kvs_of_flexarray(gc, back, back->count), libxl__xs_kvs_of_flexarray(gc, front, front->count)); rc = 0; -out_free: - flexarray_free(back); - flexarray_free(front); out: return rc; } @@ -3063,19 +3013,11 @@ int libxl__device_vfb_add(libxl__gc *gc, uint32_t domid, libxl_device_vfb *vfb) rc = libxl__device_vfb_setdefault(gc, vfb); if (rc) goto out; - front = flexarray_make(16, 1); - if (!front) { - rc = ERROR_NOMEM; - goto out; - } - back = flexarray_make(16, 1); - if (!back) { - rc = ERROR_NOMEM; - goto out_free; - } + front = flexarray_make(gc, 16, 1); + back = flexarray_make(gc, 16, 1); rc = libxl__device_from_vfb(gc, domid, vfb, &device); - if (rc != 0) goto out_free; + if (rc != 0) goto out; flexarray_append_pair(back, "frontend-id", libxl__sprintf(gc, "%d", domid)); flexarray_append_pair(back, "online", "1"); @@ -3108,9 +3050,6 @@ int libxl__device_vfb_add(libxl__gc *gc, uint32_t domid, libxl_device_vfb *vfb) libxl__xs_kvs_of_flexarray(gc, back, back->count), libxl__xs_kvs_of_flexarray(gc, front, front->count)); rc = 0; -out_free: - flexarray_free(front); - flexarray_free(back); out: return rc; } diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c index 3be7bad..82d2009 100644 --- a/tools/libxl/libxl_dm.c +++ b/tools/libxl/libxl_dm.c @@ -109,10 +109,7 @@ static char ** libxl__build_device_model_args_old(libxl__gc *gc, const char *keymap = dm_keymap(guest_config); int i; flexarray_t *dm_args; - dm_args = flexarray_make(16, 1); - - if (!dm_args) - return NULL; + dm_args = flexarray_make(gc, 16, 1); flexarray_vappend(dm_args, dm, "-d", libxl__sprintf(gc, "%d", domid), NULL); @@ -340,9 +337,7 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc, int i; uint64_t ram_size; - dm_args = flexarray_make(16, 1); - if (!dm_args) - return NULL; + dm_args = flexarray_make(gc, 16, 1); flexarray_vappend(dm_args, dm, "-xen-domid", @@ -837,7 +832,7 @@ void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state *sdss) "setting target domain %d -> %d", dm_domid, guest_domid); ret = ERROR_FAIL; - goto out_free; + goto out; } xs_set_target(ctx->xsh, dm_domid, guest_domid); @@ -861,11 +856,8 @@ retry_transaction: libxl__add_disks(egc, ao, dm_domid, dm_config, &sdss->multidev); libxl__multidev_prepared(egc, &sdss->multidev, 0); - free(args); return; -out_free: - free(args); out: assert(ret); spawn_stubdom_pvqemu_cb(egc, &sdss->pvqemu, ret); @@ -1165,7 +1157,6 @@ retry_transaction: out_close: close(null); close(logfile_w); - free(args); out: if (rc) device_model_spawn_outcome(egc, dmss, rc); diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c index 8e17842..2e6322b 100644 --- a/tools/libxl/libxl_json.c +++ b/tools/libxl/libxl_json.c @@ -220,13 +220,7 @@ static libxl__json_object *json_object_alloc(libxl__gc *gc, obj->type = type; if (type == JSON_MAP || type == JSON_ARRAY) { - flexarray_t *array = flexarray_make(1, 1); - if (array == NULL) { - LIBXL__LOG_ERRNO(libxl__gc_owner(gc), LIBXL__LOG_ERROR, - "Failed to allocate a flexarray"); - free(obj); - return NULL; - } + flexarray_t *array = flexarray_make(NOGC, 1, 1); if (type == JSON_MAP) obj->u.map = array; else diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c index ff447e7..eac35c1 100644 --- a/tools/libxl/libxl_pci.c +++ b/tools/libxl/libxl_pci.c @@ -73,12 +73,8 @@ int libxl__create_pci_backend(libxl__gc *gc, uint32_t domid, libxl__device device; int ret = ERROR_NOMEM, i; - front = flexarray_make(16, 1); - if (!front) - goto out; - back = flexarray_make(16, 1); - if (!back) - goto out; + front = flexarray_make(gc, 16, 1); + back = flexarray_make(gc, 16, 1); ret = 0; @@ -108,11 +104,6 @@ int libxl__create_pci_backend(libxl__gc *gc, uint32_t domid, libxl__xs_kvs_of_flexarray(gc, back, back->count), libxl__xs_kvs_of_flexarray(gc, front, front->count)); -out: - if (back) - flexarray_free(back); - if (front) - flexarray_free(front); return 0; } @@ -138,9 +129,7 @@ static int libxl__device_pci_add_xenstore(libxl__gc *gc, uint32_t domid, libxl_d return ERROR_FAIL; } - back = flexarray_make(16, 1); - if (!back) - return ERROR_NOMEM; + back = flexarray_make(gc, 16, 1); LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Adding new pci device to xenstore"); num = atoi(num_devs); @@ -157,7 +146,6 @@ retry_transaction: if (errno == EAGAIN) goto retry_transaction; - flexarray_free(back); return 0; } diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c index 2c4d269..6bdf924 100644 --- a/tools/libxl/libxl_qmp.c +++ b/tools/libxl/libxl_qmp.c @@ -763,7 +763,7 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev) if (!hostaddr) return -1; - parameters = flexarray_make(6, 1); + parameters = flexarray_make(gc, 6, 1); flexarray_append_pair(parameters, "driver", "xen-pci-passthrough"); flexarray_append_pair(parameters, "id", libxl__sprintf(gc, PCI_PT_QDEV_ID, @@ -777,8 +777,6 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev) PCI_FUNC(pcidev->vdevfn))); } args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count); - if (!args) - return -1; rc = qmp_synchronous_send(qmp, "device_add", &args, NULL, NULL, qmp->timeout); @@ -787,7 +785,6 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev) pci_add_callback, pcidev, qmp->timeout); } - flexarray_free(parameters); libxl__qmp_close(qmp); return rc; } @@ -803,16 +800,13 @@ static int qmp_device_del(libxl__gc *gc, int domid, char *id) if (!qmp) return ERROR_FAIL; - parameters = flexarray_make(2, 1); + parameters = flexarray_make(gc, 2, 1); flexarray_append_pair(parameters, "id", id); args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count); - if (!args) - return ERROR_NOMEM; rc = qmp_synchronous_send(qmp, "device_del", &args, NULL, NULL, qmp->timeout); - flexarray_free(parameters); libxl__qmp_close(qmp); return rc; } @@ -838,24 +832,13 @@ int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename) if (!qmp) return ERROR_FAIL; - parameters = flexarray_make(2, 1); - if (!parameters) { - rc = ERROR_NOMEM; - goto out; - } + parameters = flexarray_make(gc, 2, 1); flexarray_append_pair(parameters, "filename", (char *)filename); args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count); - if (!args) { - rc = ERROR_NOMEM; - goto out2; - } rc = qmp_synchronous_send(qmp, "xen-save-devices-state", &args, NULL, NULL, qmp->timeout); -out2: - flexarray_free(parameters); -out: libxl__qmp_close(qmp); return rc; } @@ -867,19 +850,16 @@ static int qmp_change(libxl__gc *gc, libxl__qmp_handler *qmp, libxl_key_value_list args = NULL; int rc = 0; - parameters = flexarray_make(6, 1); + parameters = flexarray_make(gc, 6, 1); flexarray_append_pair(parameters, "device", device); flexarray_append_pair(parameters, "target", target); if (arg) flexarray_append_pair(parameters, "arg", arg); args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count); - if (!args) - return ERROR_NOMEM; rc = qmp_synchronous_send(qmp, "change", &args, NULL, NULL, qmp->timeout); - flexarray_free(parameters); return rc; } -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 09:05:24 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 09:05:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK3qD-0007Is-3r; Fri, 05 Oct 2012 09:05:05 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK3qC-0007I9-4v for xen-devel@lists.xen.org; Fri, 05 Oct 2012 09:05:04 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1349427896!1709726!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQzOTY=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9711 invoked from network); 5 Oct 2012 09:04:57 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 09:04:57 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="40242085" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 09:04:33 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 05:04:33 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK3pg-000257-S8; Fri, 05 Oct 2012 10:04:32 +0100 From: Anthony PERARD To: Xen Devel Date: Fri, 5 Oct 2012 10:04:31 +0100 Message-ID: <1349427871-31195-4-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1349427871-31195-1-git-send-email-anthony.perard@citrix.com> References: <1349427871-31195-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Cc: Anthony PERARD , Ian Jackson , Ian Campbell Subject: [Xen-devel] [PATCH V3 3/3] libxl_json: Use libxl alloc function. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch makes use of the libxl allocation API and the GC and removes the check for allocation failure. Signed-off-by: Anthony PERARD Acked-by: Ian Jackson --- tools/libxl/libxl_json.c | 87 +++++++++++------------------------------------- tools/libxl/libxl_qmp.c | 1 - 2 files changed, 19 insertions(+), 69 deletions(-) diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c index 2e6322b..3cba48f 100644 --- a/tools/libxl/libxl_json.c +++ b/tools/libxl/libxl_json.c @@ -210,17 +210,12 @@ static libxl__json_object *json_object_alloc(libxl__gc *gc, { libxl__json_object *obj; - obj = calloc(1, sizeof (libxl__json_object)); - if (obj == NULL) { - LIBXL__LOG_ERRNO(libxl__gc_owner(gc), LIBXL__LOG_ERROR, - "Failed to allocate a libxl__json_object"); - return NULL; - } + obj = libxl__zalloc(gc, sizeof(*obj)); obj->type = type; if (type == JSON_MAP || type == JSON_ARRAY) { - flexarray_t *array = flexarray_make(NOGC, 1, 1); + flexarray_t *array = flexarray_make(gc, 1, 1); if (type == JSON_MAP) obj->u.map = array; else @@ -250,11 +245,7 @@ static int json_object_append_to(libxl__gc *gc, break; } case JSON_ARRAY: - if (flexarray_append(dst->u.array, obj) == 2) { - LIBXL__LOG_ERRNO(libxl__gc_owner(gc), LIBXL__LOG_ERROR, - "Failed to grow a flexarray"); - return -1; - } + flexarray_append(dst->u.array, obj); break; default: LIBXL__LOG(libxl__gc_owner(gc), LIBXL__LOG_ERROR, @@ -387,11 +378,9 @@ static int json_callback_null(void *opaque) DEBUG_GEN(ctx, null); - if ((obj = json_object_alloc(ctx->gc, JSON_NULL)) == NULL) - return 0; + obj = json_object_alloc(ctx->gc, JSON_NULL); if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { - libxl__json_object_free(ctx->gc, obj); return 0; } @@ -405,12 +394,10 @@ static int json_callback_boolean(void *opaque, int boolean) DEBUG_GEN_VALUE(ctx, bool, boolean); - if ((obj = json_object_alloc(ctx->gc, - boolean ? JSON_TRUE : JSON_FALSE)) == NULL) - return 0; + obj = json_object_alloc(ctx->gc, + boolean ? JSON_TRUE : JSON_FALSE); if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { - libxl__json_object_free(ctx->gc, obj); return 0; } @@ -442,8 +429,7 @@ static int json_callback_number(void *opaque, const char *s, libxl_yajl_length l goto error; } - if ((obj = json_object_alloc(ctx->gc, JSON_DOUBLE)) == NULL) - return 0; + obj = json_object_alloc(ctx->gc, JSON_DOUBLE); obj->u.d = d; } else { long long i = strtoll(s, NULL, 10); @@ -452,23 +438,16 @@ static int json_callback_number(void *opaque, const char *s, libxl_yajl_length l goto error; } - if ((obj = json_object_alloc(ctx->gc, JSON_INTEGER)) == NULL) - return 0; + obj = json_object_alloc(ctx->gc, JSON_INTEGER); obj->u.i = i; } goto out; error: /* If the conversion fail, we just store the original string. */ - if ((obj = json_object_alloc(ctx->gc, JSON_NUMBER)) == NULL) - return 0; + obj = json_object_alloc(ctx->gc, JSON_NUMBER); - t = malloc(len + 1); - if (t == NULL) { - LIBXL__LOG_ERRNO(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR, - "Failed to allocate"); - return 0; - } + t = libxl__zalloc(ctx->gc, len + 1); strncpy(t, s, len); t[len] = 0; @@ -476,7 +455,6 @@ error: out: if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { - libxl__json_object_free(ctx->gc, obj); return 0; } @@ -490,26 +468,17 @@ static int json_callback_string(void *opaque, const unsigned char *str, char *t = NULL; libxl__json_object *obj = NULL; - t = malloc(len + 1); - if (t == NULL) { - LIBXL__LOG_ERRNO(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR, - "Failed to allocate"); - return 0; - } + t = libxl__zalloc(ctx->gc, len + 1); DEBUG_GEN_STRING(ctx, str, len); strncpy(t, (const char *) str, len); t[len] = 0; - if ((obj = json_object_alloc(ctx->gc, JSON_STRING)) == NULL) { - free(t); - return 0; - } + obj = json_object_alloc(ctx->gc, JSON_STRING); obj->u.string = t; if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { - libxl__json_object_free(ctx->gc, obj); return 0; } @@ -522,13 +491,9 @@ static int json_callback_map_key(void *opaque, const unsigned char *str, libxl__yajl_ctx *ctx = opaque; char *t = NULL; libxl__json_object *obj = ctx->current; + libxl__gc *gc = ctx->gc; - t = malloc(len + 1); - if (t == NULL) { - LIBXL__LOG_ERRNO(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR, - "Failed to allocate"); - return 0; - } + t = libxl__zalloc(gc, len + 1); DEBUG_GEN_STRING(ctx, str, len); @@ -536,21 +501,13 @@ static int json_callback_map_key(void *opaque, const unsigned char *str, t[len] = 0; if (libxl__json_object_is_map(obj)) { - libxl__json_map_node *node = malloc(sizeof (libxl__json_map_node)); - if (node == NULL) { - LIBXL__LOG_ERRNO(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR, - "Failed to allocate"); - return 0; - } + libxl__json_map_node *node; + GCNEW(node); node->map_key = t; node->obj = NULL; - if (flexarray_append(obj->u.map, node) == 2) { - LIBXL__LOG_ERRNO(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR, - "Failed to grow a flexarray"); - return 0; - } + flexarray_append(obj->u.map, node); } else { LIBXL__LOG(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR, "Current json object is not a map"); @@ -567,12 +524,10 @@ static int json_callback_start_map(void *opaque) DEBUG_GEN(ctx, map_open); - if ((obj = json_object_alloc(ctx->gc, JSON_MAP)) == NULL) - return 0; + obj = json_object_alloc(ctx->gc, JSON_MAP); if (ctx->current) { if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { - libxl__json_object_free(ctx->gc, obj); return 0; } } @@ -609,12 +564,10 @@ static int json_callback_start_array(void *opaque) DEBUG_GEN(ctx, array_open); - if ((obj = json_object_alloc(ctx->gc, JSON_ARRAY)) == NULL) - return 0; + obj = json_object_alloc(ctx->gc, JSON_ARRAY); if (ctx->current) { if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { - libxl__json_object_free(ctx->gc, obj); return 0; } } @@ -704,8 +657,6 @@ out: LIBXL__LOG(libxl__gc_owner(gc), LIBXL__LOG_ERROR, "yajl error: %s", str); yajl_free_error(yajl_ctx.hand, str); - - libxl__json_object_free(gc, yajl_ctx.head); yajl_ctx_free(&yajl_ctx); return NULL; } diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c index 6bdf924..15550e7 100644 --- a/tools/libxl/libxl_qmp.c +++ b/tools/libxl/libxl_qmp.c @@ -484,7 +484,6 @@ static int qmp_next(libxl__gc *gc, libxl__qmp_handler *qmp) if (o) { rc = qmp_handle_response(qmp, o); - libxl__json_object_free(gc, o); } else { LIBXL__LOG(qmp->ctx, LIBXL__LOG_ERROR, "Parse error of : %s\n", s); -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 09:05:24 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 09:05:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK3qD-0007Is-3r; Fri, 05 Oct 2012 09:05:05 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK3qC-0007I9-4v for xen-devel@lists.xen.org; Fri, 05 Oct 2012 09:05:04 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1349427896!1709726!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQzOTY=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9711 invoked from network); 5 Oct 2012 09:04:57 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 09:04:57 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="40242085" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 09:04:33 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 05:04:33 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK3pg-000257-S8; Fri, 05 Oct 2012 10:04:32 +0100 From: Anthony PERARD To: Xen Devel Date: Fri, 5 Oct 2012 10:04:31 +0100 Message-ID: <1349427871-31195-4-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1349427871-31195-1-git-send-email-anthony.perard@citrix.com> References: <1349427871-31195-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Cc: Anthony PERARD , Ian Jackson , Ian Campbell Subject: [Xen-devel] [PATCH V3 3/3] libxl_json: Use libxl alloc function. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch makes use of the libxl allocation API and the GC and removes the check for allocation failure. Signed-off-by: Anthony PERARD Acked-by: Ian Jackson --- tools/libxl/libxl_json.c | 87 +++++++++++------------------------------------- tools/libxl/libxl_qmp.c | 1 - 2 files changed, 19 insertions(+), 69 deletions(-) diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c index 2e6322b..3cba48f 100644 --- a/tools/libxl/libxl_json.c +++ b/tools/libxl/libxl_json.c @@ -210,17 +210,12 @@ static libxl__json_object *json_object_alloc(libxl__gc *gc, { libxl__json_object *obj; - obj = calloc(1, sizeof (libxl__json_object)); - if (obj == NULL) { - LIBXL__LOG_ERRNO(libxl__gc_owner(gc), LIBXL__LOG_ERROR, - "Failed to allocate a libxl__json_object"); - return NULL; - } + obj = libxl__zalloc(gc, sizeof(*obj)); obj->type = type; if (type == JSON_MAP || type == JSON_ARRAY) { - flexarray_t *array = flexarray_make(NOGC, 1, 1); + flexarray_t *array = flexarray_make(gc, 1, 1); if (type == JSON_MAP) obj->u.map = array; else @@ -250,11 +245,7 @@ static int json_object_append_to(libxl__gc *gc, break; } case JSON_ARRAY: - if (flexarray_append(dst->u.array, obj) == 2) { - LIBXL__LOG_ERRNO(libxl__gc_owner(gc), LIBXL__LOG_ERROR, - "Failed to grow a flexarray"); - return -1; - } + flexarray_append(dst->u.array, obj); break; default: LIBXL__LOG(libxl__gc_owner(gc), LIBXL__LOG_ERROR, @@ -387,11 +378,9 @@ static int json_callback_null(void *opaque) DEBUG_GEN(ctx, null); - if ((obj = json_object_alloc(ctx->gc, JSON_NULL)) == NULL) - return 0; + obj = json_object_alloc(ctx->gc, JSON_NULL); if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { - libxl__json_object_free(ctx->gc, obj); return 0; } @@ -405,12 +394,10 @@ static int json_callback_boolean(void *opaque, int boolean) DEBUG_GEN_VALUE(ctx, bool, boolean); - if ((obj = json_object_alloc(ctx->gc, - boolean ? JSON_TRUE : JSON_FALSE)) == NULL) - return 0; + obj = json_object_alloc(ctx->gc, + boolean ? JSON_TRUE : JSON_FALSE); if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { - libxl__json_object_free(ctx->gc, obj); return 0; } @@ -442,8 +429,7 @@ static int json_callback_number(void *opaque, const char *s, libxl_yajl_length l goto error; } - if ((obj = json_object_alloc(ctx->gc, JSON_DOUBLE)) == NULL) - return 0; + obj = json_object_alloc(ctx->gc, JSON_DOUBLE); obj->u.d = d; } else { long long i = strtoll(s, NULL, 10); @@ -452,23 +438,16 @@ static int json_callback_number(void *opaque, const char *s, libxl_yajl_length l goto error; } - if ((obj = json_object_alloc(ctx->gc, JSON_INTEGER)) == NULL) - return 0; + obj = json_object_alloc(ctx->gc, JSON_INTEGER); obj->u.i = i; } goto out; error: /* If the conversion fail, we just store the original string. */ - if ((obj = json_object_alloc(ctx->gc, JSON_NUMBER)) == NULL) - return 0; + obj = json_object_alloc(ctx->gc, JSON_NUMBER); - t = malloc(len + 1); - if (t == NULL) { - LIBXL__LOG_ERRNO(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR, - "Failed to allocate"); - return 0; - } + t = libxl__zalloc(ctx->gc, len + 1); strncpy(t, s, len); t[len] = 0; @@ -476,7 +455,6 @@ error: out: if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { - libxl__json_object_free(ctx->gc, obj); return 0; } @@ -490,26 +468,17 @@ static int json_callback_string(void *opaque, const unsigned char *str, char *t = NULL; libxl__json_object *obj = NULL; - t = malloc(len + 1); - if (t == NULL) { - LIBXL__LOG_ERRNO(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR, - "Failed to allocate"); - return 0; - } + t = libxl__zalloc(ctx->gc, len + 1); DEBUG_GEN_STRING(ctx, str, len); strncpy(t, (const char *) str, len); t[len] = 0; - if ((obj = json_object_alloc(ctx->gc, JSON_STRING)) == NULL) { - free(t); - return 0; - } + obj = json_object_alloc(ctx->gc, JSON_STRING); obj->u.string = t; if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { - libxl__json_object_free(ctx->gc, obj); return 0; } @@ -522,13 +491,9 @@ static int json_callback_map_key(void *opaque, const unsigned char *str, libxl__yajl_ctx *ctx = opaque; char *t = NULL; libxl__json_object *obj = ctx->current; + libxl__gc *gc = ctx->gc; - t = malloc(len + 1); - if (t == NULL) { - LIBXL__LOG_ERRNO(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR, - "Failed to allocate"); - return 0; - } + t = libxl__zalloc(gc, len + 1); DEBUG_GEN_STRING(ctx, str, len); @@ -536,21 +501,13 @@ static int json_callback_map_key(void *opaque, const unsigned char *str, t[len] = 0; if (libxl__json_object_is_map(obj)) { - libxl__json_map_node *node = malloc(sizeof (libxl__json_map_node)); - if (node == NULL) { - LIBXL__LOG_ERRNO(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR, - "Failed to allocate"); - return 0; - } + libxl__json_map_node *node; + GCNEW(node); node->map_key = t; node->obj = NULL; - if (flexarray_append(obj->u.map, node) == 2) { - LIBXL__LOG_ERRNO(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR, - "Failed to grow a flexarray"); - return 0; - } + flexarray_append(obj->u.map, node); } else { LIBXL__LOG(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR, "Current json object is not a map"); @@ -567,12 +524,10 @@ static int json_callback_start_map(void *opaque) DEBUG_GEN(ctx, map_open); - if ((obj = json_object_alloc(ctx->gc, JSON_MAP)) == NULL) - return 0; + obj = json_object_alloc(ctx->gc, JSON_MAP); if (ctx->current) { if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { - libxl__json_object_free(ctx->gc, obj); return 0; } } @@ -609,12 +564,10 @@ static int json_callback_start_array(void *opaque) DEBUG_GEN(ctx, array_open); - if ((obj = json_object_alloc(ctx->gc, JSON_ARRAY)) == NULL) - return 0; + obj = json_object_alloc(ctx->gc, JSON_ARRAY); if (ctx->current) { if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { - libxl__json_object_free(ctx->gc, obj); return 0; } } @@ -704,8 +657,6 @@ out: LIBXL__LOG(libxl__gc_owner(gc), LIBXL__LOG_ERROR, "yajl error: %s", str); yajl_free_error(yajl_ctx.hand, str); - - libxl__json_object_free(gc, yajl_ctx.head); yajl_ctx_free(&yajl_ctx); return NULL; } diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c index 6bdf924..15550e7 100644 --- a/tools/libxl/libxl_qmp.c +++ b/tools/libxl/libxl_qmp.c @@ -484,7 +484,6 @@ static int qmp_next(libxl__gc *gc, libxl__qmp_handler *qmp) if (o) { rc = qmp_handle_response(qmp, o); - libxl__json_object_free(gc, o); } else { LIBXL__LOG(qmp->ctx, LIBXL__LOG_ERROR, "Parse error of : %s\n", s); -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 09:07:39 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 09:07:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK3sV-0007eN-92; Fri, 05 Oct 2012 09:07:27 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK3sT-0007e4-3B for xen-devel@lists.xen.org; Fri, 05 Oct 2012 09:07:25 +0000 Received: from [85.158.139.83:62454] by server-14.bemta-5.messagelabs.com id 69/34-31065-C43AE605; Fri, 05 Oct 2012 09:07:24 +0000 X-Env-Sender: Christoph.Egger@amd.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1349428041!29255198!1 X-Originating-IP: [216.32.180.185] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 606 invoked from network); 5 Oct 2012 09:07:23 -0000 Received: from co1ehsobe002.messaging.microsoft.com (HELO co1outboundpool.messaging.microsoft.com) (216.32.180.185) by server-14.tower-182.messagelabs.com with AES128-SHA encrypted SMTP; 5 Oct 2012 09:07:23 -0000 Received: from mail23-co1-R.bigfish.com (10.243.78.228) by CO1EHSOBE006.bigfish.com (10.243.66.69) with Microsoft SMTP Server id 14.1.225.23; Fri, 5 Oct 2012 09:07:21 +0000 Received: from mail23-co1 (localhost [127.0.0.1]) by mail23-co1-R.bigfish.com (Postfix) with ESMTP id 0A4485C0125; Fri, 5 Oct 2012 09:07:21 +0000 (UTC) X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null); IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI X-SpamScore: -5 X-BigFish: VPS-5(zzbb2dI98dI146fI1432I1418Izz1202h1d1ah1d2ahzz17326ah8275bh8275dhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh137ah13b6h1441h1155h) Received: from mail23-co1 (localhost.localdomain [127.0.0.1]) by mail23-co1 (MessageSwitch) id 13494280398321_28090; Fri, 5 Oct 2012 09:07:19 +0000 (UTC) Received: from CO1EHSMHS021.bigfish.com (unknown [10.243.78.243]) by mail23-co1.bigfish.com (Postfix) with ESMTP id E90357C0054; Fri, 5 Oct 2012 09:07:18 +0000 (UTC) Received: from ausb3twp02.amd.com (163.181.249.109) by CO1EHSMHS021.bigfish.com (10.243.66.31) with Microsoft SMTP Server id 14.1.225.23; Fri, 5 Oct 2012 09:07:17 +0000 X-WSS-ID: 0MBEXC1-02-1NY-02 X-M-MSG: Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com [163.181.249.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ausb3twp02.amd.com (Axway MailGate 3.8.1) with ESMTP id 2ECCEC8079; Fri, 5 Oct 2012 04:07:12 -0500 (CDT) Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep02.amd.com (163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1; Fri, 5 Oct 2012 04:07:34 -0500 Received: from storexhtp02.amd.com (172.24.4.4) by sausexhtp02.amd.com (163.181.3.152) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 5 Oct 2012 04:07:14 -0500 Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com (172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 5 Oct 2012 05:07:13 -0400 Message-ID: <506EA340.9060108@amd.com> Date: Fri, 5 Oct 2012 11:07:12 +0200 From: Christoph Egger User-Agent: Mozilla/5.0 (X11; NetBSD amd64; rv:11.0) Gecko/20120404 Thunderbird/11.0 MIME-Version: 1.0 To: Tim Deegan References: <505C733B.50205@amd.com> <20120927145356.GG8831@ocelot.phlegethon.org> <50699FA6.6070805@amd.com> <20121004103706.GD38243@ocelot.phlegethon.org> <506D7DBB.7000900@amd.com> <20121004132355.GF38243@ocelot.phlegethon.org> In-Reply-To: <20121004132355.GF38243@ocelot.phlegethon.org> X-OriginatorOrg: amd.com Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH] nestedsvm: fix paging mode X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 10/04/12 15:23, Tim Deegan wrote: > At 14:14 +0200 on 04 Oct (1349360091), Christoph Egger wrote: >> On 10/04/12 12:37, Tim Deegan wrote: >> >>> At 15:50 +0200 on 01 Oct (1349106630), Christoph Egger wrote: >>>> On 09/27/12 16:53, Tim Deegan wrote: >>>> >>>>> At 16:01 +0200 on 21 Sep (1348243291), Christoph Egger wrote: >>>>>> >>>>>> On VMRUN and VMEXIT emulation update the paging mode >>>>>> for Shadow-on-Nested. This allows Xen to walk the >>>>>> l1 hypervisors shadow page table correctly. >>>>>> Problem found with 64bit Win7 and 32bit XPMode where >>>>>> Win7 switches forth and back between long mode and >>>>>> PAE legacy pagetables. >>>>>> >>>>>> Signed-off-by: Christoph Egger >>>>> >>>>> Don't you have to do this in other cases as well? I think that >>>>> shadow-on-shadow might need it, at least. >>>> >>>> It is needed for all cases where the l1 guest does shadow paging. >>>> This includes: Shadow-on-Nested and Shadow-on-Shadow. >>> >>> I've looked more closely at this and now I'm more confused. :) >>> >>> Hap-on-hap seems to be OK without it because the special case in >>> paging_gva_to_gfn() does the right thing, using the nestedmode's pt >>> walker. >>> >>> Why is that not good enough for shadow-on-hap? Is there another path >>> that does unguarded pt walks? If so: >>> - why is that path not a problem for hap-on-hap; and >>> - shouldn't that be handled the same way, i.e. either handle everything >>> at lookup time, like paging_gva_to_gfn() does, or handle everything >>> by switching modes at VMRUN/EXIT? >> >> >> If the l1 guest does not do nested paging then Xen doesn't use the >> nestedmode's pt walker. > > Ah, I was led astray by the nestedhvm_is_n2() check. It turns out that: > nestedhvm_is_n2() returns 0 for guests that are in n2 but aren't > hap-on-hap. That's pretty confusing, and I encourage you to change it. > > Anyway, I've checked in a modified version of your patch, as > http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/a9c84069c248 > Please check that it still does what you wanted. :) Yes, it does. Thanks. Please apply it to xen-4.2-testing as well. Christoph -- ---to satisfy European Law for business letters: Advanced Micro Devices GmbH Einsteinring 24, 85689 Dornach b. Muenchen Geschaeftsfuehrer: Alberto Bozzo Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 09:07:39 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 09:07:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK3sV-0007eN-92; Fri, 05 Oct 2012 09:07:27 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK3sT-0007e4-3B for xen-devel@lists.xen.org; Fri, 05 Oct 2012 09:07:25 +0000 Received: from [85.158.139.83:62454] by server-14.bemta-5.messagelabs.com id 69/34-31065-C43AE605; Fri, 05 Oct 2012 09:07:24 +0000 X-Env-Sender: Christoph.Egger@amd.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1349428041!29255198!1 X-Originating-IP: [216.32.180.185] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 606 invoked from network); 5 Oct 2012 09:07:23 -0000 Received: from co1ehsobe002.messaging.microsoft.com (HELO co1outboundpool.messaging.microsoft.com) (216.32.180.185) by server-14.tower-182.messagelabs.com with AES128-SHA encrypted SMTP; 5 Oct 2012 09:07:23 -0000 Received: from mail23-co1-R.bigfish.com (10.243.78.228) by CO1EHSOBE006.bigfish.com (10.243.66.69) with Microsoft SMTP Server id 14.1.225.23; Fri, 5 Oct 2012 09:07:21 +0000 Received: from mail23-co1 (localhost [127.0.0.1]) by mail23-co1-R.bigfish.com (Postfix) with ESMTP id 0A4485C0125; Fri, 5 Oct 2012 09:07:21 +0000 (UTC) X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null); IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI X-SpamScore: -5 X-BigFish: VPS-5(zzbb2dI98dI146fI1432I1418Izz1202h1d1ah1d2ahzz17326ah8275bh8275dhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh137ah13b6h1441h1155h) Received: from mail23-co1 (localhost.localdomain [127.0.0.1]) by mail23-co1 (MessageSwitch) id 13494280398321_28090; Fri, 5 Oct 2012 09:07:19 +0000 (UTC) Received: from CO1EHSMHS021.bigfish.com (unknown [10.243.78.243]) by mail23-co1.bigfish.com (Postfix) with ESMTP id E90357C0054; Fri, 5 Oct 2012 09:07:18 +0000 (UTC) Received: from ausb3twp02.amd.com (163.181.249.109) by CO1EHSMHS021.bigfish.com (10.243.66.31) with Microsoft SMTP Server id 14.1.225.23; Fri, 5 Oct 2012 09:07:17 +0000 X-WSS-ID: 0MBEXC1-02-1NY-02 X-M-MSG: Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com [163.181.249.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ausb3twp02.amd.com (Axway MailGate 3.8.1) with ESMTP id 2ECCEC8079; Fri, 5 Oct 2012 04:07:12 -0500 (CDT) Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep02.amd.com (163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1; Fri, 5 Oct 2012 04:07:34 -0500 Received: from storexhtp02.amd.com (172.24.4.4) by sausexhtp02.amd.com (163.181.3.152) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 5 Oct 2012 04:07:14 -0500 Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com (172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 5 Oct 2012 05:07:13 -0400 Message-ID: <506EA340.9060108@amd.com> Date: Fri, 5 Oct 2012 11:07:12 +0200 From: Christoph Egger User-Agent: Mozilla/5.0 (X11; NetBSD amd64; rv:11.0) Gecko/20120404 Thunderbird/11.0 MIME-Version: 1.0 To: Tim Deegan References: <505C733B.50205@amd.com> <20120927145356.GG8831@ocelot.phlegethon.org> <50699FA6.6070805@amd.com> <20121004103706.GD38243@ocelot.phlegethon.org> <506D7DBB.7000900@amd.com> <20121004132355.GF38243@ocelot.phlegethon.org> In-Reply-To: <20121004132355.GF38243@ocelot.phlegethon.org> X-OriginatorOrg: amd.com Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH] nestedsvm: fix paging mode X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 10/04/12 15:23, Tim Deegan wrote: > At 14:14 +0200 on 04 Oct (1349360091), Christoph Egger wrote: >> On 10/04/12 12:37, Tim Deegan wrote: >> >>> At 15:50 +0200 on 01 Oct (1349106630), Christoph Egger wrote: >>>> On 09/27/12 16:53, Tim Deegan wrote: >>>> >>>>> At 16:01 +0200 on 21 Sep (1348243291), Christoph Egger wrote: >>>>>> >>>>>> On VMRUN and VMEXIT emulation update the paging mode >>>>>> for Shadow-on-Nested. This allows Xen to walk the >>>>>> l1 hypervisors shadow page table correctly. >>>>>> Problem found with 64bit Win7 and 32bit XPMode where >>>>>> Win7 switches forth and back between long mode and >>>>>> PAE legacy pagetables. >>>>>> >>>>>> Signed-off-by: Christoph Egger >>>>> >>>>> Don't you have to do this in other cases as well? I think that >>>>> shadow-on-shadow might need it, at least. >>>> >>>> It is needed for all cases where the l1 guest does shadow paging. >>>> This includes: Shadow-on-Nested and Shadow-on-Shadow. >>> >>> I've looked more closely at this and now I'm more confused. :) >>> >>> Hap-on-hap seems to be OK without it because the special case in >>> paging_gva_to_gfn() does the right thing, using the nestedmode's pt >>> walker. >>> >>> Why is that not good enough for shadow-on-hap? Is there another path >>> that does unguarded pt walks? If so: >>> - why is that path not a problem for hap-on-hap; and >>> - shouldn't that be handled the same way, i.e. either handle everything >>> at lookup time, like paging_gva_to_gfn() does, or handle everything >>> by switching modes at VMRUN/EXIT? >> >> >> If the l1 guest does not do nested paging then Xen doesn't use the >> nestedmode's pt walker. > > Ah, I was led astray by the nestedhvm_is_n2() check. It turns out that: > nestedhvm_is_n2() returns 0 for guests that are in n2 but aren't > hap-on-hap. That's pretty confusing, and I encourage you to change it. > > Anyway, I've checked in a modified version of your patch, as > http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/a9c84069c248 > Please check that it still does what you wanted. :) Yes, it does. Thanks. Please apply it to xen-4.2-testing as well. Christoph -- ---to satisfy European Law for business letters: Advanced Micro Devices GmbH Einsteinring 24, 85689 Dornach b. Muenchen Geschaeftsfuehrer: Alberto Bozzo Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 09:09:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 09:09:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK3uB-0007qq-Ql; Fri, 05 Oct 2012 09:09:11 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK3uB-0007qg-5O for xen-devel@lists.xen.org; Fri, 05 Oct 2012 09:09:11 +0000 Received: from [85.158.143.35:21859] by server-3.bemta-4.messagelabs.com id 83/D5-10986-6B3AE605; Fri, 05 Oct 2012 09:09:10 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1349428101!13450338!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17134 invoked from network); 5 Oct 2012 09:08:21 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-3.tower-21.messagelabs.com with SMTP; 5 Oct 2012 09:08:21 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 05 Oct 2012 10:07:21 +0100 Message-Id: <506EBF67020000780009FD94@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 05 Oct 2012 10:07:19 +0100 From: "Jan Beulich" To: "Jean Guyader" References: <1348141322-28657-1-git-send-email-jean.guyader@citrix.com> <1348141322-28657-5-git-send-email-jean.guyader@citrix.com> <505B2636020000780009CAA6@nat28.tlf.novell.com> <506D98FE020000780009FA23@nat28.tlf.novell.com> <20121004151214.GG38243@ocelot.phlegethon.org> <506EBBD7020000780009FD84@nat28.tlf.novell.com> In-Reply-To: <506EBBD7020000780009FD84@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Disposition: inline Cc: Tim Deegan , Jean Guyader , xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH 4/4] xen: Add V4V implementation X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 05.10.12 at 10:52, "Jan Beulich" wrote: >>>> On 04.10.12 at 19:00, Jean Guyader wrote: >> On 4 October 2012 16:12, Tim Deegan wrote: >>> AIUI you need to use compat_handle_okay() instead of guest_handle_okay() >>> to check the handles if is_pv_32on64_domain(current). >>> >> >> How about something like that? > > Could be done, but not by modifying guest_handle_okay() (which > penalizes all its users), nor by (incorrectly) open-coding > compat_handle_okay(). And neither should any such implementation > use is_pv_32on64_domain() twice - use the conditional operator > instead (that way you also avoid evaluating arguments twice). > > So you could either introduce e.g. any_guest_handle_okay(), or > switch all current users of guest_handle_okay() to, say, > native_handle_okay() (perhaps with the exception of those where > the compat mode wrapper source files #define guest_handle_okay() > to compat_handle_okay(), which could then be dropped). Actually, after some more recalling of how all this was put together, you can use the existing guest_handle_okay() on anything that legitimately is a XEN_GUEST_HANDLE(). In particular, direct hypercall arguments can be expressed that way since they get properly zero-extended from 32 to 64 bits on the hypercall entry path. The things needing extra consideration are only handles embedded in structures - you need to either translate these handles, or validate that their upper halves are zero. That's also one of the reasons why I didn't make the guest memory accessor/validation macros transparently handle both cases. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 09:09:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 09:09:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK3uB-0007qq-Ql; Fri, 05 Oct 2012 09:09:11 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK3uB-0007qg-5O for xen-devel@lists.xen.org; Fri, 05 Oct 2012 09:09:11 +0000 Received: from [85.158.143.35:21859] by server-3.bemta-4.messagelabs.com id 83/D5-10986-6B3AE605; Fri, 05 Oct 2012 09:09:10 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1349428101!13450338!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17134 invoked from network); 5 Oct 2012 09:08:21 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-3.tower-21.messagelabs.com with SMTP; 5 Oct 2012 09:08:21 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 05 Oct 2012 10:07:21 +0100 Message-Id: <506EBF67020000780009FD94@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 05 Oct 2012 10:07:19 +0100 From: "Jan Beulich" To: "Jean Guyader" References: <1348141322-28657-1-git-send-email-jean.guyader@citrix.com> <1348141322-28657-5-git-send-email-jean.guyader@citrix.com> <505B2636020000780009CAA6@nat28.tlf.novell.com> <506D98FE020000780009FA23@nat28.tlf.novell.com> <20121004151214.GG38243@ocelot.phlegethon.org> <506EBBD7020000780009FD84@nat28.tlf.novell.com> In-Reply-To: <506EBBD7020000780009FD84@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Disposition: inline Cc: Tim Deegan , Jean Guyader , xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH 4/4] xen: Add V4V implementation X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 05.10.12 at 10:52, "Jan Beulich" wrote: >>>> On 04.10.12 at 19:00, Jean Guyader wrote: >> On 4 October 2012 16:12, Tim Deegan wrote: >>> AIUI you need to use compat_handle_okay() instead of guest_handle_okay() >>> to check the handles if is_pv_32on64_domain(current). >>> >> >> How about something like that? > > Could be done, but not by modifying guest_handle_okay() (which > penalizes all its users), nor by (incorrectly) open-coding > compat_handle_okay(). And neither should any such implementation > use is_pv_32on64_domain() twice - use the conditional operator > instead (that way you also avoid evaluating arguments twice). > > So you could either introduce e.g. any_guest_handle_okay(), or > switch all current users of guest_handle_okay() to, say, > native_handle_okay() (perhaps with the exception of those where > the compat mode wrapper source files #define guest_handle_okay() > to compat_handle_okay(), which could then be dropped). Actually, after some more recalling of how all this was put together, you can use the existing guest_handle_okay() on anything that legitimately is a XEN_GUEST_HANDLE(). In particular, direct hypercall arguments can be expressed that way since they get properly zero-extended from 32 to 64 bits on the hypercall entry path. The things needing extra consideration are only handles embedded in structures - you need to either translate these handles, or validate that their upper halves are zero. That's also one of the reasons why I didn't make the guest memory accessor/validation macros transparently handle both cases. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 09:13:23 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 09:13:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK3y3-00087C-Fd; Fri, 05 Oct 2012 09:13:11 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK3y2-000877-Dr for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 09:13:10 +0000 Received: from [85.158.143.35:33122] by server-3.bemta-4.messagelabs.com id 27/4C-10986-5A4AE605; Fri, 05 Oct 2012 09:13:09 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1349428388!17579550!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23120 invoked from network); 5 Oct 2012 09:13:08 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 09:13:08 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14957628" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 09:13:08 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 10:13:08 +0100 Message-ID: <1349428386.20946.15.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Fri, 5 Oct 2012 10:13:06 +0100 In-Reply-To: <1345633688-31684-4-git-send-email-stefano.stabellini@eu.citrix.com> References: <1345633688-31684-4-git-send-email-stefano.stabellini@eu.citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , "Tim \(Xen.org\)" Subject: Re: [Xen-devel] [PATCH v4 4/6] xen: introduce XEN_GUEST_HANDLE_PARAM X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org T24gV2VkLCAyMDEyLTA4LTIyIGF0IDEyOjA4ICswMTAwLCBTdGVmYW5vIFN0YWJlbGxpbmkgd3Jv dGU6Cj4gZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL2FzbS1hcm0vZ3Vlc3RfYWNjZXNzLmggYi94 ZW4vaW5jbHVkZS9hc20tYXJtL2d1ZXN0X2FjY2Vzcy5oCj4gaW5kZXggMGZjZWFlNi4uNTY4NjIx NyAxMDA2NDQKPiAtLS0gYS94ZW4vaW5jbHVkZS9hc20tYXJtL2d1ZXN0X2FjY2Vzcy5oCj4gKysr IGIveGVuL2luY2x1ZGUvYXNtLWFybS9ndWVzdF9hY2Nlc3MuaAo+IEBAIC0yNywxNiArMjcsNDAg QEAgdW5zaWduZWQgbG9uZyByYXdfY2xlYXJfZ3Vlc3Qodm9pZCAqdG8sIHVuc2lnbmVkIGxlbik7 Cj4gICNkZWZpbmUgZ3Vlc3RfaGFuZGxlX2FkZF9vZmZzZXQoaG5kLCBucikgKChobmQpLnAgKz0g KG5yKSkKPiAgI2RlZmluZSBndWVzdF9oYW5kbGVfc3VidHJhY3Rfb2Zmc2V0KGhuZCwgbnIpICgo aG5kKS5wIC09IChucikpCj4gIAo+IC0vKiBDYXN0IGEgZ3Vlc3QgaGFuZGxlIHRvIHRoZSBzcGVj aWZpZWQgdHlwZSBvZiBoYW5kbGUuICovCj4gKy8qIENhc3QgYSBndWVzdCBoYW5kbGUgKGVpdGhl ciBYRU5fR1VFU1RfSEFORExFIG9yIFhFTl9HVUVTVF9IQU5ETEVfUEFSQU0pCj4gKyAqIHRvIHRo ZSBzcGVjaWZpZWQgdHlwZSBvZiBYRU5fR1VFU1RfSEFORExFX1BBUkFNLiAqLwo+ICAjZGVmaW5l IGd1ZXN0X2hhbmRsZV9jYXN0KGhuZCwgdHlwZSkgKHsgICAgICAgICBcCj4gICAgICB0eXBlICpf eCA9IChobmQpLnA7ICAgICAgICAgICAgICAgICAgICAgICAgIFwKPiAtICAgIChYRU5fR1VFU1Rf SEFORExFKHR5cGUpKSB7IF94IH07ICAgICAgICAgICAgXAo+ICsgICAgKFhFTl9HVUVTVF9IQU5E TEVfUEFSQU0odHlwZSkpIHsgX3ggfTsgICAgICAgICAgICBcClsuLi5dCj4gICNkZWZpbmUgZ3Vl c3RfaGFuZGxlX2Zyb21fcHRyKHB0ciwgdHlwZSkgICAgICAgIFwKPiAtICAgICgoWEVOX0dVRVNU X0hBTkRMRSh0eXBlKSkgeyAodHlwZSAqKXB0ciB9KQo+ICsgICAgKChYRU5fR1VFU1RfSEFORExF X1BBUkFNKHR5cGUpKSB7ICh0eXBlICopcHRyIH0pCj4gICNkZWZpbmUgY29uc3RfZ3Vlc3RfaGFu ZGxlX2Zyb21fcHRyKHB0ciwgdHlwZSkgIFwKPiAtICAgICgoWEVOX0dVRVNUX0hBTkRMRShjb25z dF8jI3R5cGUpKSB7IChjb25zdCB0eXBlICopcHRyIH0pCj4gKyAgICAoKFhFTl9HVUVTVF9IQU5E TEVfUEFSQU0oY29uc3RfIyN0eXBlKSkgeyAoY29uc3QgdHlwZSAqKXB0ciB9KQoKVGhlc2UgbGl0 dGxlIGJpdHMgY2F1c2UgYnVpbGQgYnJlYWthZ2UgaWYgeW91IG9ubHkgYXBwbHkgdG8gdGhpcyBw b2ludAppbiB0aGUgc2VyaWVzIChpLmUuIGJyZWFrcyBiaXNlY3RhYmlsaXR5KToKICAgICAgICBn cmFudF90YWJsZS5jOiBJbiBmdW5jdGlvbiDigJhkb19ncmFudF90YWJsZV9vcOKAmToKICAgICAg ICBncmFudF90YWJsZS5jOjI0NDk6MTM6IGVycm9yOiBpbnZhbGlkIGluaXRpYWxpemVyCiAgICAg ICAgZ3JhbnRfdGFibGUuYzoyNDU2OjE3OiBlcnJvcjogaW5jb21wYXRpYmxlIHR5cGVzIHdoZW4g YXNzaWduaW5nIHRvIHR5cGUg4oCYX19ndWVzdF9oYW5kbGVfNjRfdm9pZOKAmSBmcm9tIHR5cGUg 4oCYX19ndWVzdF9oYW5kbGVfdm9pZOKAmQogICAgICAgIFtsb3RzIG1vcmUgb2YgdGhlIHNhbWVd CgpJIHRoaW5rIHRoaXMgaXMgYmVjYXVzZSB5b3UgaGF2ZSBjaGFuZ2VkIGd1ZXN0X2hhbmRsZV9j YXN0IGJ1dCB5b3UKaGF2ZW4ndCB5ZXQgY2hhbmdlZCB0aGUgdHlwZSBvZiB0aGUgcGFyYW1ldGVy LgoKSSBoYXZlbid0IHRyaWVkIHg4NiBidXQgSSBjYW4ndCBzZWUgd2h5IHRoZSBzYW1lIHByb2Js ZW0gd291bGRuJ3QgZXhpc3QKdGhlcmUgYWxzby4KClRoZSBvYnZpb3VzIGFuc3dlciBpcyB0byBt b3ZlIHRoZXNlIGh1bmtzIGludG8gdGhlIG5leHQgcGF0Y2gsIGJ1dCBJCnRoaW5rIGJlY2F1c2Ug b2YgdGhlIHNwbGl0IGludG8gcGF0Y2hlcyA1LzYgYW5kIDYvNiB0aGlzIHdpbGwgc3RpbGwKY2F1 c2UgcHJvYmxlbXMuIEknbGwgdHJ5IGl0IHRob3VnaCBidXQgSSBzdXNwZWN0IHdlIG1pZ2h0IGVu ZCB1cCBoYXZpbmcKdG8gc3F1YXNoIDUrNiB0b2dldGhlcj8KCkFsdGVybmF0aXZlbHkgSSd2ZSBi cm9rZW4gc29tZXRoaW5nIGR1cmluZyByZWJhc2luZyBhbmQgdGhpcyB1c2VkIHRvCndvcmsgZmlu ZSBhbmQgeW91IGtub3cgd2hhdCB0byBkbyA7LSkuLi4KCklhbi4KCgpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhl bi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo= From xen-devel-bounces@lists.xen.org Fri Oct 05 09:13:23 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 09:13:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK3y3-00087C-Fd; Fri, 05 Oct 2012 09:13:11 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK3y2-000877-Dr for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 09:13:10 +0000 Received: from [85.158.143.35:33122] by server-3.bemta-4.messagelabs.com id 27/4C-10986-5A4AE605; Fri, 05 Oct 2012 09:13:09 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1349428388!17579550!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23120 invoked from network); 5 Oct 2012 09:13:08 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 09:13:08 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14957628" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 09:13:08 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 10:13:08 +0100 Message-ID: <1349428386.20946.15.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Fri, 5 Oct 2012 10:13:06 +0100 In-Reply-To: <1345633688-31684-4-git-send-email-stefano.stabellini@eu.citrix.com> References: <1345633688-31684-4-git-send-email-stefano.stabellini@eu.citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , "Tim \(Xen.org\)" Subject: Re: [Xen-devel] [PATCH v4 4/6] xen: introduce XEN_GUEST_HANDLE_PARAM X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org T24gV2VkLCAyMDEyLTA4LTIyIGF0IDEyOjA4ICswMTAwLCBTdGVmYW5vIFN0YWJlbGxpbmkgd3Jv dGU6Cj4gZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL2FzbS1hcm0vZ3Vlc3RfYWNjZXNzLmggYi94 ZW4vaW5jbHVkZS9hc20tYXJtL2d1ZXN0X2FjY2Vzcy5oCj4gaW5kZXggMGZjZWFlNi4uNTY4NjIx NyAxMDA2NDQKPiAtLS0gYS94ZW4vaW5jbHVkZS9hc20tYXJtL2d1ZXN0X2FjY2Vzcy5oCj4gKysr IGIveGVuL2luY2x1ZGUvYXNtLWFybS9ndWVzdF9hY2Nlc3MuaAo+IEBAIC0yNywxNiArMjcsNDAg QEAgdW5zaWduZWQgbG9uZyByYXdfY2xlYXJfZ3Vlc3Qodm9pZCAqdG8sIHVuc2lnbmVkIGxlbik7 Cj4gICNkZWZpbmUgZ3Vlc3RfaGFuZGxlX2FkZF9vZmZzZXQoaG5kLCBucikgKChobmQpLnAgKz0g KG5yKSkKPiAgI2RlZmluZSBndWVzdF9oYW5kbGVfc3VidHJhY3Rfb2Zmc2V0KGhuZCwgbnIpICgo aG5kKS5wIC09IChucikpCj4gIAo+IC0vKiBDYXN0IGEgZ3Vlc3QgaGFuZGxlIHRvIHRoZSBzcGVj aWZpZWQgdHlwZSBvZiBoYW5kbGUuICovCj4gKy8qIENhc3QgYSBndWVzdCBoYW5kbGUgKGVpdGhl ciBYRU5fR1VFU1RfSEFORExFIG9yIFhFTl9HVUVTVF9IQU5ETEVfUEFSQU0pCj4gKyAqIHRvIHRo ZSBzcGVjaWZpZWQgdHlwZSBvZiBYRU5fR1VFU1RfSEFORExFX1BBUkFNLiAqLwo+ICAjZGVmaW5l IGd1ZXN0X2hhbmRsZV9jYXN0KGhuZCwgdHlwZSkgKHsgICAgICAgICBcCj4gICAgICB0eXBlICpf eCA9IChobmQpLnA7ICAgICAgICAgICAgICAgICAgICAgICAgIFwKPiAtICAgIChYRU5fR1VFU1Rf SEFORExFKHR5cGUpKSB7IF94IH07ICAgICAgICAgICAgXAo+ICsgICAgKFhFTl9HVUVTVF9IQU5E TEVfUEFSQU0odHlwZSkpIHsgX3ggfTsgICAgICAgICAgICBcClsuLi5dCj4gICNkZWZpbmUgZ3Vl c3RfaGFuZGxlX2Zyb21fcHRyKHB0ciwgdHlwZSkgICAgICAgIFwKPiAtICAgICgoWEVOX0dVRVNU X0hBTkRMRSh0eXBlKSkgeyAodHlwZSAqKXB0ciB9KQo+ICsgICAgKChYRU5fR1VFU1RfSEFORExF X1BBUkFNKHR5cGUpKSB7ICh0eXBlICopcHRyIH0pCj4gICNkZWZpbmUgY29uc3RfZ3Vlc3RfaGFu ZGxlX2Zyb21fcHRyKHB0ciwgdHlwZSkgIFwKPiAtICAgICgoWEVOX0dVRVNUX0hBTkRMRShjb25z dF8jI3R5cGUpKSB7IChjb25zdCB0eXBlICopcHRyIH0pCj4gKyAgICAoKFhFTl9HVUVTVF9IQU5E TEVfUEFSQU0oY29uc3RfIyN0eXBlKSkgeyAoY29uc3QgdHlwZSAqKXB0ciB9KQoKVGhlc2UgbGl0 dGxlIGJpdHMgY2F1c2UgYnVpbGQgYnJlYWthZ2UgaWYgeW91IG9ubHkgYXBwbHkgdG8gdGhpcyBw b2ludAppbiB0aGUgc2VyaWVzIChpLmUuIGJyZWFrcyBiaXNlY3RhYmlsaXR5KToKICAgICAgICBn cmFudF90YWJsZS5jOiBJbiBmdW5jdGlvbiDigJhkb19ncmFudF90YWJsZV9vcOKAmToKICAgICAg ICBncmFudF90YWJsZS5jOjI0NDk6MTM6IGVycm9yOiBpbnZhbGlkIGluaXRpYWxpemVyCiAgICAg ICAgZ3JhbnRfdGFibGUuYzoyNDU2OjE3OiBlcnJvcjogaW5jb21wYXRpYmxlIHR5cGVzIHdoZW4g YXNzaWduaW5nIHRvIHR5cGUg4oCYX19ndWVzdF9oYW5kbGVfNjRfdm9pZOKAmSBmcm9tIHR5cGUg 4oCYX19ndWVzdF9oYW5kbGVfdm9pZOKAmQogICAgICAgIFtsb3RzIG1vcmUgb2YgdGhlIHNhbWVd CgpJIHRoaW5rIHRoaXMgaXMgYmVjYXVzZSB5b3UgaGF2ZSBjaGFuZ2VkIGd1ZXN0X2hhbmRsZV9j YXN0IGJ1dCB5b3UKaGF2ZW4ndCB5ZXQgY2hhbmdlZCB0aGUgdHlwZSBvZiB0aGUgcGFyYW1ldGVy LgoKSSBoYXZlbid0IHRyaWVkIHg4NiBidXQgSSBjYW4ndCBzZWUgd2h5IHRoZSBzYW1lIHByb2Js ZW0gd291bGRuJ3QgZXhpc3QKdGhlcmUgYWxzby4KClRoZSBvYnZpb3VzIGFuc3dlciBpcyB0byBt b3ZlIHRoZXNlIGh1bmtzIGludG8gdGhlIG5leHQgcGF0Y2gsIGJ1dCBJCnRoaW5rIGJlY2F1c2Ug b2YgdGhlIHNwbGl0IGludG8gcGF0Y2hlcyA1LzYgYW5kIDYvNiB0aGlzIHdpbGwgc3RpbGwKY2F1 c2UgcHJvYmxlbXMuIEknbGwgdHJ5IGl0IHRob3VnaCBidXQgSSBzdXNwZWN0IHdlIG1pZ2h0IGVu ZCB1cCBoYXZpbmcKdG8gc3F1YXNoIDUrNiB0b2dldGhlcj8KCkFsdGVybmF0aXZlbHkgSSd2ZSBi cm9rZW4gc29tZXRoaW5nIGR1cmluZyByZWJhc2luZyBhbmQgdGhpcyB1c2VkIHRvCndvcmsgZmlu ZSBhbmQgeW91IGtub3cgd2hhdCB0byBkbyA7LSkuLi4KCklhbi4KCgpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhl bi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo= From xen-devel-bounces@lists.xen.org Fri Oct 05 09:21:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 09:21:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK462-0008HE-Iz; Fri, 05 Oct 2012 09:21:26 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK461-0008H9-7O for Xen-devel@lists.xensource.com; Fri, 05 Oct 2012 09:21:25 +0000 Received: from [85.158.138.51:61161] by server-8.bemta-3.messagelabs.com id 0F/3E-16337-496AE605; Fri, 05 Oct 2012 09:21:24 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1349428880!33138177!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29744 invoked from network); 5 Oct 2012 09:21:20 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 09:21:20 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14957814" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 09:21:20 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 10:21:20 +0100 Message-ID: <1349428878.20946.18.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Mukesh Rathor Date: Fri, 5 Oct 2012 10:21:18 +0100 In-Reply-To: <20121004112048.53767720@mantra.us.oracle.com> References: <20120921122123.33489ce1@mantra.us.oracle.com> <1349270495.650.144.camel@zakaz.uk.xensource.com> <20121003153106.65237f07@mantra.us.oracle.com> <1349340642.650.227.camel@zakaz.uk.xensource.com> <20121004112048.53767720@mantra.us.oracle.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 7/8]: PVH privcmd changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-10-04 at 19:20 +0100, Mukesh Rathor wrote: > On Thu, 4 Oct 2012 09:50:42 +0100 > Ian Campbell wrote: > > > On Wed, 2012-10-03 at 23:31 +0100, Mukesh Rathor wrote: > > > On Wed, 3 Oct 2012 14:21:35 +0100 > > > Ian Campbell wrote: > > > > > > > On Fri, 2012-09-21 at 20:21 +0100, Mukesh Rathor wrote: > > > > > +static int pvh_privcmd_resv_pfns(struct vm_area_struct *vma, > > > > > int numpgs) > > > > ... > > > > > + pvhp->pi_num_pgs = numpgs; > > > > > + BUG_ON(vma->vm_private_data != (void *)1); > > > > > + vma->vm_private_data = pvhp; > > > > > > > > How does this interact with: > > > > > > > > static int privcmd_enforce_singleshot_mapping(struct > > > > vm_area_struct *vma) { > > > > return (xchg(&vma->vm_private_data, (void *)1) == NULL); > > > > } > > > > > > > > If someone tries to map a second time then won't this correct the > > > > pvhp in vm_private_data by resetting it to 1? Then when the > > > > original mapping is torn down things all fall apart? > > > > > > > > Perhaps we need a cmpxchg here? Or to rework the callers a little > > > > bit perhaps. > > > > > > Right, that's why I had it originally checking for auto xlated and > > > doing something different. I think that is better than to change > > > this and change again. I'll change it back to just putting the ptr > > > here. > > > > Won't that break because on the second call you will pass in the > > freshly allocated pointer and overwrite the exiting (useful) one with > > it? > > No, for xlate, I just check for NULL. I didn't think it was big > deal to special case xlate in this case. We got so many if xlate > cases already thru the code. It leaves the semantics easy to > understand: NULL == avail. 1 == locked PV. PTR == Locked PVH. I'll add > a comment this time :). The transition from NULL => Locked PVH still needs to be done atomically and without clobbering any existing non-NULL value, otherwise it doesn't actually protect against multiple mappings like it is supposed to. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 09:21:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 09:21:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK462-0008HE-Iz; Fri, 05 Oct 2012 09:21:26 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK461-0008H9-7O for Xen-devel@lists.xensource.com; Fri, 05 Oct 2012 09:21:25 +0000 Received: from [85.158.138.51:61161] by server-8.bemta-3.messagelabs.com id 0F/3E-16337-496AE605; Fri, 05 Oct 2012 09:21:24 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1349428880!33138177!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29744 invoked from network); 5 Oct 2012 09:21:20 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 09:21:20 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14957814" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 09:21:20 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 10:21:20 +0100 Message-ID: <1349428878.20946.18.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Mukesh Rathor Date: Fri, 5 Oct 2012 10:21:18 +0100 In-Reply-To: <20121004112048.53767720@mantra.us.oracle.com> References: <20120921122123.33489ce1@mantra.us.oracle.com> <1349270495.650.144.camel@zakaz.uk.xensource.com> <20121003153106.65237f07@mantra.us.oracle.com> <1349340642.650.227.camel@zakaz.uk.xensource.com> <20121004112048.53767720@mantra.us.oracle.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 7/8]: PVH privcmd changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-10-04 at 19:20 +0100, Mukesh Rathor wrote: > On Thu, 4 Oct 2012 09:50:42 +0100 > Ian Campbell wrote: > > > On Wed, 2012-10-03 at 23:31 +0100, Mukesh Rathor wrote: > > > On Wed, 3 Oct 2012 14:21:35 +0100 > > > Ian Campbell wrote: > > > > > > > On Fri, 2012-09-21 at 20:21 +0100, Mukesh Rathor wrote: > > > > > +static int pvh_privcmd_resv_pfns(struct vm_area_struct *vma, > > > > > int numpgs) > > > > ... > > > > > + pvhp->pi_num_pgs = numpgs; > > > > > + BUG_ON(vma->vm_private_data != (void *)1); > > > > > + vma->vm_private_data = pvhp; > > > > > > > > How does this interact with: > > > > > > > > static int privcmd_enforce_singleshot_mapping(struct > > > > vm_area_struct *vma) { > > > > return (xchg(&vma->vm_private_data, (void *)1) == NULL); > > > > } > > > > > > > > If someone tries to map a second time then won't this correct the > > > > pvhp in vm_private_data by resetting it to 1? Then when the > > > > original mapping is torn down things all fall apart? > > > > > > > > Perhaps we need a cmpxchg here? Or to rework the callers a little > > > > bit perhaps. > > > > > > Right, that's why I had it originally checking for auto xlated and > > > doing something different. I think that is better than to change > > > this and change again. I'll change it back to just putting the ptr > > > here. > > > > Won't that break because on the second call you will pass in the > > freshly allocated pointer and overwrite the exiting (useful) one with > > it? > > No, for xlate, I just check for NULL. I didn't think it was big > deal to special case xlate in this case. We got so many if xlate > cases already thru the code. It leaves the semantics easy to > understand: NULL == avail. 1 == locked PV. PTR == Locked PVH. I'll add > a comment this time :). The transition from NULL => Locked PVH still needs to be done atomically and without clobbering any existing non-NULL value, otherwise it doesn't actually protect against multiple mappings like it is supposed to. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 09:23:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 09:23:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK482-0008MP-3H; Fri, 05 Oct 2012 09:23:30 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK480-0008MH-7B for Xen-devel@lists.xensource.com; Fri, 05 Oct 2012 09:23:28 +0000 Received: from [85.158.138.51:17421] by server-16.bemta-3.messagelabs.com id DE/D0-04167-F07AE605; Fri, 05 Oct 2012 09:23:27 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1349429006!31516419!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6591 invoked from network); 5 Oct 2012 09:23:27 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 09:23:27 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14957877" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 09:23:26 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 10:23:26 +0100 Message-ID: <1349429005.20946.20.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Mukesh Rathor Date: Fri, 5 Oct 2012 10:23:25 +0100 In-Reply-To: <20121004183528.060416a0@mantra.us.oracle.com> References: <20120921121659.5a723de9@mantra.us.oracle.com> <20120924154335.097d3fb9@mantra.us.oracle.com> <20120925180416.0137d61a@mantra.us.oracle.com> <20121002183619.70734b7a@mantra.us.oracle.com> <20121002190323.2e16f6ff@mantra.us.oracle.com> <1349265914.650.136.camel@zakaz.uk.xensource.com> <20121004183528.060416a0@mantra.us.oracle.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v1 3/8]: PVH startup changes (enlighten.c) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-10-05 at 02:35 +0100, Mukesh Rathor wrote: > On Wed, 3 Oct 2012 13:05:14 +0100 > Ian Campbell wrote: > > > On Wed, 2012-10-03 at 12:58 +0100, Stefano Stabellini wrote: > > > > So for now, how about, lets go > > > > with what I've got. I'll make a note, and when I do xen patch, > > > > I'll figure it out, and would be a very small linux patch. I want > > > > to get linux patch in soon before the window closes. > > > > > > We can leave page special as it is for now with very little > > > consequences, because it is not part of the interface with Xen. > > > However this is part of the interface, so whatever we choose here > > > is going to be hard to change later on. > > > > I suggested that until we have seen and reviewed the hypervisor side > > patches this guest side functionality all needs to be under an option > > which has CONFIG_EXPERIMENTAL as a dependency and a comment explaining > > that the ABI is not fixed yet, similar to what we did for the ARM > > port. > > Konrad is going to keep the changes in his tree and not upstream for > couple months while we go thru the xen patches. This would be a big > help for me as I won't have to constantly refresh linux tree. Ah, ok, that sounds like a good plan. In the case where the ARM stuff I have built on this becomes ripe first would it be OK with you guys if I were to cherry pick the relevant bits of the PVH stuff into a series to go in sooner? > I hope we can get some baseline in linux and xen soon. Likewise! Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 09:23:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 09:23:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK482-0008MP-3H; Fri, 05 Oct 2012 09:23:30 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK480-0008MH-7B for Xen-devel@lists.xensource.com; Fri, 05 Oct 2012 09:23:28 +0000 Received: from [85.158.138.51:17421] by server-16.bemta-3.messagelabs.com id DE/D0-04167-F07AE605; Fri, 05 Oct 2012 09:23:27 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1349429006!31516419!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6591 invoked from network); 5 Oct 2012 09:23:27 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 09:23:27 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14957877" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 09:23:26 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 10:23:26 +0100 Message-ID: <1349429005.20946.20.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Mukesh Rathor Date: Fri, 5 Oct 2012 10:23:25 +0100 In-Reply-To: <20121004183528.060416a0@mantra.us.oracle.com> References: <20120921121659.5a723de9@mantra.us.oracle.com> <20120924154335.097d3fb9@mantra.us.oracle.com> <20120925180416.0137d61a@mantra.us.oracle.com> <20121002183619.70734b7a@mantra.us.oracle.com> <20121002190323.2e16f6ff@mantra.us.oracle.com> <1349265914.650.136.camel@zakaz.uk.xensource.com> <20121004183528.060416a0@mantra.us.oracle.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v1 3/8]: PVH startup changes (enlighten.c) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-10-05 at 02:35 +0100, Mukesh Rathor wrote: > On Wed, 3 Oct 2012 13:05:14 +0100 > Ian Campbell wrote: > > > On Wed, 2012-10-03 at 12:58 +0100, Stefano Stabellini wrote: > > > > So for now, how about, lets go > > > > with what I've got. I'll make a note, and when I do xen patch, > > > > I'll figure it out, and would be a very small linux patch. I want > > > > to get linux patch in soon before the window closes. > > > > > > We can leave page special as it is for now with very little > > > consequences, because it is not part of the interface with Xen. > > > However this is part of the interface, so whatever we choose here > > > is going to be hard to change later on. > > > > I suggested that until we have seen and reviewed the hypervisor side > > patches this guest side functionality all needs to be under an option > > which has CONFIG_EXPERIMENTAL as a dependency and a comment explaining > > that the ABI is not fixed yet, similar to what we did for the ARM > > port. > > Konrad is going to keep the changes in his tree and not upstream for > couple months while we go thru the xen patches. This would be a big > help for me as I won't have to constantly refresh linux tree. Ah, ok, that sounds like a good plan. In the case where the ARM stuff I have built on this becomes ripe first would it be OK with you guys if I were to cherry pick the relevant bits of the PVH stuff into a series to go in sooner? > I hope we can get some baseline in linux and xen soon. Likewise! Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 09:25:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 09:25:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK4A7-0008UZ-KN; Fri, 05 Oct 2012 09:25:39 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK4A6-0008UN-QD for Xen-devel@lists.xensource.com; Fri, 05 Oct 2012 09:25:39 +0000 Received: from [85.158.137.99:14327] by server-2.bemta-3.messagelabs.com id B0/7F-16514-197AE605; Fri, 05 Oct 2012 09:25:37 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-217.messagelabs.com!1349429136!15023851!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12940 invoked from network); 5 Oct 2012 09:25:36 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 09:25:36 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14957937" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 09:25:36 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 10:25:35 +0100 Message-ID: <1349429134.20946.23.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Mukesh Rathor Date: Fri, 5 Oct 2012 10:25:34 +0100 In-Reply-To: <20121004112734.4f003584@mantra.us.oracle.com> References: <20120921121556.1a0ea8af@mantra.us.oracle.com> <1349278963.650.164.camel@zakaz.uk.xensource.com> <20121003152925.5af3a658@mantra.us.oracle.com> <1349339279.650.214.camel@zakaz.uk.xensource.com> <20121004112734.4f003584@mantra.us.oracle.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-10-04 at 19:27 +0100, Mukesh Rathor wrote: > On Thu, 4 Oct 2012 09:27:59 +0100 > Ian Campbell wrote: > > > On Wed, 2012-10-03 at 23:29 +0100, Mukesh Rathor wrote: > > > On Wed, 3 Oct 2012 16:42:43 +0100 > > > Ian Campbell wrote: > > > > > > > > > > > > int xen_remap_domain_mfn_range(struct vm_area_struct *vma, > > > > > unsigned long addr, > > > > > unsigned long mfn, int nr, > > > > > - pgprot_t prot, unsigned domid); > > > > > + pgprot_t prot, unsigned domid, > > > > > + struct xen_pvh_pfn_info *pvhp); > > > > > +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma, > > > > > + struct xen_pvh_pfn_info *pvhp); > > > > > + > > > > > +struct xen_pvh_pfn_info { > > > > > > > > Can we call this xen_remap_mfn_info or something? PVH is x86 > > > > specific while this struct is also useful on ARM. > > > > > > I already renamed it to: xen_xlat_pfn_info. > > > > What does xlat refer to here? I don't think we translate anything with > > this struct. > > paging mode xlate! See stefanno's prev email where he suggested changing > name to this. Oh, because the uses are under XENFEAT_auto_translated_physmap? I suppose that makes sense, kind of. I guess it doesn't really matter since I reckon we can get rid of the struct entirely anyway ;-) Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 09:25:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 09:25:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK4A7-0008UZ-KN; Fri, 05 Oct 2012 09:25:39 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK4A6-0008UN-QD for Xen-devel@lists.xensource.com; Fri, 05 Oct 2012 09:25:39 +0000 Received: from [85.158.137.99:14327] by server-2.bemta-3.messagelabs.com id B0/7F-16514-197AE605; Fri, 05 Oct 2012 09:25:37 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-217.messagelabs.com!1349429136!15023851!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12940 invoked from network); 5 Oct 2012 09:25:36 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 09:25:36 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14957937" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 09:25:36 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 10:25:35 +0100 Message-ID: <1349429134.20946.23.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Mukesh Rathor Date: Fri, 5 Oct 2012 10:25:34 +0100 In-Reply-To: <20121004112734.4f003584@mantra.us.oracle.com> References: <20120921121556.1a0ea8af@mantra.us.oracle.com> <1349278963.650.164.camel@zakaz.uk.xensource.com> <20121003152925.5af3a658@mantra.us.oracle.com> <1349339279.650.214.camel@zakaz.uk.xensource.com> <20121004112734.4f003584@mantra.us.oracle.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-10-04 at 19:27 +0100, Mukesh Rathor wrote: > On Thu, 4 Oct 2012 09:27:59 +0100 > Ian Campbell wrote: > > > On Wed, 2012-10-03 at 23:29 +0100, Mukesh Rathor wrote: > > > On Wed, 3 Oct 2012 16:42:43 +0100 > > > Ian Campbell wrote: > > > > > > > > > > > > int xen_remap_domain_mfn_range(struct vm_area_struct *vma, > > > > > unsigned long addr, > > > > > unsigned long mfn, int nr, > > > > > - pgprot_t prot, unsigned domid); > > > > > + pgprot_t prot, unsigned domid, > > > > > + struct xen_pvh_pfn_info *pvhp); > > > > > +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma, > > > > > + struct xen_pvh_pfn_info *pvhp); > > > > > + > > > > > +struct xen_pvh_pfn_info { > > > > > > > > Can we call this xen_remap_mfn_info or something? PVH is x86 > > > > specific while this struct is also useful on ARM. > > > > > > I already renamed it to: xen_xlat_pfn_info. > > > > What does xlat refer to here? I don't think we translate anything with > > this struct. > > paging mode xlate! See stefanno's prev email where he suggested changing > name to this. Oh, because the uses are under XENFEAT_auto_translated_physmap? I suppose that makes sense, kind of. I guess it doesn't really matter since I reckon we can get rid of the struct entirely anyway ;-) Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 09:27:36 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 09:27:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK4Bq-0000BO-5i; Fri, 05 Oct 2012 09:27:26 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK4Bo-0000BE-RV for Xen-devel@lists.xensource.com; Fri, 05 Oct 2012 09:27:25 +0000 Received: from [85.158.137.99:10817] by server-11.bemta-3.messagelabs.com id 2A/59-21460-CF7AE605; Fri, 05 Oct 2012 09:27:24 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-217.messagelabs.com!1349429243!15247572!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11884 invoked from network); 5 Oct 2012 09:27:23 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 09:27:23 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14957974" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 09:26:53 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 10:26:52 +0100 Message-ID: <1349429211.20946.24.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Mukesh Rathor Date: Fri, 5 Oct 2012 10:26:51 +0100 In-Reply-To: <20121004181712.604bcf3e@mantra.us.oracle.com> References: <20120921121556.1a0ea8af@mantra.us.oracle.com> <1349278963.650.164.camel@zakaz.uk.xensource.com> <20121003152925.5af3a658@mantra.us.oracle.com> <1349339496.650.216.camel@zakaz.uk.xensource.com> <20121004181712.604bcf3e@mantra.us.oracle.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-10-05 at 02:17 +0100, Mukesh Rathor wrote: > On Thu, 4 Oct 2012 09:31:36 +0100 > Ian Campbell wrote: > > > On Wed, 2012-10-03 at 23:29 +0100, Mukesh Rathor wrote: > > > On Wed, 3 Oct 2012 16:42:43 +0100 > > > Ian Campbell wrote: > > > > > > > > > > > > diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h > > > > > index 6a198e4..6c5ad83 100644 > > > > > --- a/include/xen/xen-ops.h > > > > > +++ b/include/xen/xen-ops.h > > > > > @@ -24,9 +24,19 @@ int xen_create_contiguous_region(unsigned > > > > > long vstart, unsigned int order, void > > > > > xen_destroy_contiguous_region(unsigned long vstart, unsigned int > > > > > order); struct vm_area_struct; > > > > > +struct xen_pvh_pfn_info; > > > > > > > > If you move the struct def'n up you don't need this forward decl. > > > > > > > > > int xen_remap_domain_mfn_range(struct vm_area_struct *vma, > > > > > unsigned long addr, > > > > > unsigned long mfn, int nr, > > > > > - pgprot_t prot, unsigned domid); > > > > > + pgprot_t prot, unsigned domid, > > > > > + struct xen_pvh_pfn_info *pvhp); > > > > > +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma, > > > > > + struct xen_pvh_pfn_info *pvhp); > > > > > + > > > > > +struct xen_pvh_pfn_info { > > > > > > > > Can we call this xen_remap_mfn_info or something? PVH is x86 > > > > specific while this struct is also useful on ARM. > > > > > > I already renamed it to: xen_xlat_pfn_info. > > > > BTW, where can I find you latest patches? > > In my local tree here. Will be submitting v3 soon. Great, thanks. > > I've just noticed that you've not been CCing LKML with this series -- > > was that deliberate? > > I was told I didn't need to since there is no common code change. I always (try to) CC both regardless but I suppose that's not really a rule. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 09:27:36 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 09:27:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK4Bq-0000BO-5i; Fri, 05 Oct 2012 09:27:26 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK4Bo-0000BE-RV for Xen-devel@lists.xensource.com; Fri, 05 Oct 2012 09:27:25 +0000 Received: from [85.158.137.99:10817] by server-11.bemta-3.messagelabs.com id 2A/59-21460-CF7AE605; Fri, 05 Oct 2012 09:27:24 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-217.messagelabs.com!1349429243!15247572!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11884 invoked from network); 5 Oct 2012 09:27:23 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 09:27:23 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14957974" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 09:26:53 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 10:26:52 +0100 Message-ID: <1349429211.20946.24.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Mukesh Rathor Date: Fri, 5 Oct 2012 10:26:51 +0100 In-Reply-To: <20121004181712.604bcf3e@mantra.us.oracle.com> References: <20120921121556.1a0ea8af@mantra.us.oracle.com> <1349278963.650.164.camel@zakaz.uk.xensource.com> <20121003152925.5af3a658@mantra.us.oracle.com> <1349339496.650.216.camel@zakaz.uk.xensource.com> <20121004181712.604bcf3e@mantra.us.oracle.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-10-05 at 02:17 +0100, Mukesh Rathor wrote: > On Thu, 4 Oct 2012 09:31:36 +0100 > Ian Campbell wrote: > > > On Wed, 2012-10-03 at 23:29 +0100, Mukesh Rathor wrote: > > > On Wed, 3 Oct 2012 16:42:43 +0100 > > > Ian Campbell wrote: > > > > > > > > > > > > diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h > > > > > index 6a198e4..6c5ad83 100644 > > > > > --- a/include/xen/xen-ops.h > > > > > +++ b/include/xen/xen-ops.h > > > > > @@ -24,9 +24,19 @@ int xen_create_contiguous_region(unsigned > > > > > long vstart, unsigned int order, void > > > > > xen_destroy_contiguous_region(unsigned long vstart, unsigned int > > > > > order); struct vm_area_struct; > > > > > +struct xen_pvh_pfn_info; > > > > > > > > If you move the struct def'n up you don't need this forward decl. > > > > > > > > > int xen_remap_domain_mfn_range(struct vm_area_struct *vma, > > > > > unsigned long addr, > > > > > unsigned long mfn, int nr, > > > > > - pgprot_t prot, unsigned domid); > > > > > + pgprot_t prot, unsigned domid, > > > > > + struct xen_pvh_pfn_info *pvhp); > > > > > +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma, > > > > > + struct xen_pvh_pfn_info *pvhp); > > > > > + > > > > > +struct xen_pvh_pfn_info { > > > > > > > > Can we call this xen_remap_mfn_info or something? PVH is x86 > > > > specific while this struct is also useful on ARM. > > > > > > I already renamed it to: xen_xlat_pfn_info. > > > > BTW, where can I find you latest patches? > > In my local tree here. Will be submitting v3 soon. Great, thanks. > > I've just noticed that you've not been CCing LKML with this series -- > > was that deliberate? > > I was told I didn't need to since there is no common code change. I always (try to) CC both regardless but I suppose that's not really a rule. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 09:28:14 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 09:28:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK4CS-0000Ge-PD; Fri, 05 Oct 2012 09:28:04 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK4CR-0000GS-Oa for xen-devel@lists.xen.org; Fri, 05 Oct 2012 09:28:03 +0000 Received: from [85.158.143.99:62860] by server-3.bemta-4.messagelabs.com id 82/74-10986-328AE605; Fri, 05 Oct 2012 09:28:03 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1349429282!24792147!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22518 invoked from network); 5 Oct 2012 09:28:02 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 09:28:02 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14958002" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 09:28:02 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 10:28:02 +0100 Message-ID: <1349429280.20946.25.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Jim Fehlig Date: Fri, 5 Oct 2012 10:28:00 +0100 In-Reply-To: <506E0DE1.7@suse.com> References: <201209191918.35305.hahn@univention.de> <201209201340.52218.hahn@univention.de> <505B88A1.1070701@suse.com> <505C4A82.2040305@eu.citrix.com> <50626355.7080402@suse.com> <1349339644.650.217.camel@zakaz.uk.xensource.com> <506E0DE1.7@suse.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: George Dunlap , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Xen 4.3 development update X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-10-04 at 23:29 +0100, Jim Fehlig wrote: > Ian Campbell wrote: > > BTW, I've been meaning to ask, and it's kind of the flipside of this so > > I'll mention it here -- would it be possible for you (or whoever is > > sending patches) to CC xen-devel with Xen related patches to libvirt? > > > > Sure. Thanks! > > Partly just to raise the visibility of the libvirt integration on the > > Xen side but also at least I am interested to see how libxl is being > > used outside of xl and what sorts of issues etc you guys are having. I > > suppose there would also be other benefits to review from libxl folks of > > patches which consume the APIs. > > > > Agreed. You could set us straight on any misuse of the API :). I think it's equally likely that we'll realise that our APIs are prone to easy misuse, but hopefully we'll meet somewhere in the middle ;-) Cheers, Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 09:28:14 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 09:28:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK4CS-0000Ge-PD; Fri, 05 Oct 2012 09:28:04 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK4CR-0000GS-Oa for xen-devel@lists.xen.org; Fri, 05 Oct 2012 09:28:03 +0000 Received: from [85.158.143.99:62860] by server-3.bemta-4.messagelabs.com id 82/74-10986-328AE605; Fri, 05 Oct 2012 09:28:03 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1349429282!24792147!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22518 invoked from network); 5 Oct 2012 09:28:02 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 09:28:02 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14958002" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 09:28:02 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 10:28:02 +0100 Message-ID: <1349429280.20946.25.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Jim Fehlig Date: Fri, 5 Oct 2012 10:28:00 +0100 In-Reply-To: <506E0DE1.7@suse.com> References: <201209191918.35305.hahn@univention.de> <201209201340.52218.hahn@univention.de> <505B88A1.1070701@suse.com> <505C4A82.2040305@eu.citrix.com> <50626355.7080402@suse.com> <1349339644.650.217.camel@zakaz.uk.xensource.com> <506E0DE1.7@suse.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: George Dunlap , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Xen 4.3 development update X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-10-04 at 23:29 +0100, Jim Fehlig wrote: > Ian Campbell wrote: > > BTW, I've been meaning to ask, and it's kind of the flipside of this so > > I'll mention it here -- would it be possible for you (or whoever is > > sending patches) to CC xen-devel with Xen related patches to libvirt? > > > > Sure. Thanks! > > Partly just to raise the visibility of the libvirt integration on the > > Xen side but also at least I am interested to see how libxl is being > > used outside of xl and what sorts of issues etc you guys are having. I > > suppose there would also be other benefits to review from libxl folks of > > patches which consume the APIs. > > > > Agreed. You could set us straight on any misuse of the API :). I think it's equally likely that we'll realise that our APIs are prone to easy misuse, but hopefully we'll meet somewhere in the middle ;-) Cheers, Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 09:45:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 09:45:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK4SW-0000hi-MX; Fri, 05 Oct 2012 09:44:40 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK4SV-0000hd-56 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 09:44:39 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1349430273!10244825!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26581 invoked from network); 5 Oct 2012 09:44:33 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 09:44:33 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14958389" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 09:44:33 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 10:44:32 +0100 Message-ID: <1349430271.20946.36.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Dan Magenheimer Date: Fri, 5 Oct 2012 10:44:31 +0100 In-Reply-To: <3e5cf0ba-4241-4f00-bef6-aaff2cc23419@default> References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> <20121002091017.GA95926@ocelot.phlegethon.org> <66cc0085-1216-40f7-8059-eaf615202c12@default> <20121002201624.GA98445@ocelot.phlegethon.org> <20121004100645.GC38243@ocelot.phlegethon.org> <1349345864.650.247.camel@zakaz.uk.xensource.com> <239799F4-AF29-494F-86D2-ADF45ACA8792@gridcentric.ca> <3e5cf0ba-4241-4f00-bef6-aaff2cc23419@default> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: Olaf Hering , "Keir \(Xen.org\)" , Konrad Wilk , George Dunlap , Andres Lagar-Cavilla , "Tim \(Xen.org\)" , "xen-devel@lists.xen.org" , George Shuklin , Dario Faggioli , Kurt Hackel , Ian Jackson Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-10-04 at 17:54 +0100, Dan Magenheimer wrote: > Scanning through the archived message I am under the impression > that the focus is on a single server... i.e. "punt if actor is > not xl", i.e. it addressed "balloon-to-fit" and only tries to avoid > stepping on other memory overcommit technologies. xl is inherently a single system toolstack, and a simple ballooning based actor would just be its default. The design is not intended to require that a toolstack only provide a single actor, or indeed that the actor is provided by the toolstack at all. It would be perfectly reasonable for xl to provide actors which work well with tmem or paging or sharing or some complex combination and even to select them by default when those technologies are enabled on the host. We also fully expect that other toolstacks will want to provide their own actors which make use of the facilities of those toolstacks to do a better job based on the additional stateetc (e.g. we expect xapi to want to provide a squeezed based actor). Lastly design is also intended to support "3rd party" actors which are not part of any toolstack. e.g. actors which talk to your cloud orchestration layer or with some central authority or which communicate with other hosts etc is intended to be a possibility. > That makes it > almost orthogonal, I think, to the problem I originally raised. > > But a bigger concern is that its focus on a single machine ignores > the "cloud", where Xen seems to hold an advantage. In the cloud, > the actor is "controlling" _many_ machines. In the problem I > originally raised, this actor (a centralized management console) > is simply looking for a server that has sufficient memory to house > a new domain, and it (or the automation/sysadmin running it) gets > unhappy if (xl running on) the server says "yes there is enough > memory" but then later says, "oops, I guess there wasn't enough > after all". Integrating some sort of "entry control" into the actor protocol seems like a logical addition to me (assuming we didn't already include it, I didn't go back and check), since the details of when to say yes or no seem like they would very depend on the policies of that particular actor and the technologies which it is using to implement them. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 09:45:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 09:45:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK4SW-0000hi-MX; Fri, 05 Oct 2012 09:44:40 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK4SV-0000hd-56 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 09:44:39 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1349430273!10244825!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26581 invoked from network); 5 Oct 2012 09:44:33 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 09:44:33 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14958389" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 09:44:33 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 10:44:32 +0100 Message-ID: <1349430271.20946.36.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Dan Magenheimer Date: Fri, 5 Oct 2012 10:44:31 +0100 In-Reply-To: <3e5cf0ba-4241-4f00-bef6-aaff2cc23419@default> References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> <20121002091017.GA95926@ocelot.phlegethon.org> <66cc0085-1216-40f7-8059-eaf615202c12@default> <20121002201624.GA98445@ocelot.phlegethon.org> <20121004100645.GC38243@ocelot.phlegethon.org> <1349345864.650.247.camel@zakaz.uk.xensource.com> <239799F4-AF29-494F-86D2-ADF45ACA8792@gridcentric.ca> <3e5cf0ba-4241-4f00-bef6-aaff2cc23419@default> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: Olaf Hering , "Keir \(Xen.org\)" , Konrad Wilk , George Dunlap , Andres Lagar-Cavilla , "Tim \(Xen.org\)" , "xen-devel@lists.xen.org" , George Shuklin , Dario Faggioli , Kurt Hackel , Ian Jackson Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 2012-10-04 at 17:54 +0100, Dan Magenheimer wrote: > Scanning through the archived message I am under the impression > that the focus is on a single server... i.e. "punt if actor is > not xl", i.e. it addressed "balloon-to-fit" and only tries to avoid > stepping on other memory overcommit technologies. xl is inherently a single system toolstack, and a simple ballooning based actor would just be its default. The design is not intended to require that a toolstack only provide a single actor, or indeed that the actor is provided by the toolstack at all. It would be perfectly reasonable for xl to provide actors which work well with tmem or paging or sharing or some complex combination and even to select them by default when those technologies are enabled on the host. We also fully expect that other toolstacks will want to provide their own actors which make use of the facilities of those toolstacks to do a better job based on the additional stateetc (e.g. we expect xapi to want to provide a squeezed based actor). Lastly design is also intended to support "3rd party" actors which are not part of any toolstack. e.g. actors which talk to your cloud orchestration layer or with some central authority or which communicate with other hosts etc is intended to be a possibility. > That makes it > almost orthogonal, I think, to the problem I originally raised. > > But a bigger concern is that its focus on a single machine ignores > the "cloud", where Xen seems to hold an advantage. In the cloud, > the actor is "controlling" _many_ machines. In the problem I > originally raised, this actor (a centralized management console) > is simply looking for a server that has sufficient memory to house > a new domain, and it (or the automation/sysadmin running it) gets > unhappy if (xl running on) the server says "yes there is enough > memory" but then later says, "oops, I guess there wasn't enough > after all". Integrating some sort of "entry control" into the actor protocol seems like a logical addition to me (assuming we didn't already include it, I didn't go back and check), since the details of when to say yes or no seem like they would very depend on the policies of that particular actor and the technologies which it is using to implement them. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 10:15:59 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 10:15:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK4wQ-0000zP-Bm; Fri, 05 Oct 2012 10:15:34 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK4wO-0000zK-CF for xen-devel@lists.xen.org; Fri, 05 Oct 2012 10:15:32 +0000 Received: from [85.158.143.99:30355] by server-1.bemta-4.messagelabs.com id 59/E3-05684-343BE605; Fri, 05 Oct 2012 10:15:31 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1349432130!32640383!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29356 invoked from network); 5 Oct 2012 10:15:31 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 10:15:31 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14959195" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 10:15:30 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 11:15:29 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TK4wL-0006Pv-Ly; Fri, 05 Oct 2012 10:15:29 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TK4wL-0000Kr-DU; Fri, 05 Oct 2012 11:15:29 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20590.45889.100206.747892@mariner.uk.xensource.com> Date: Fri, 5 Oct 2012 11:15:29 +0100 To: Anthony PERARD In-Reply-To: <1349427871-31195-2-git-send-email-anthony.perard@citrix.com> References: <1349427871-31195-1-git-send-email-anthony.perard@citrix.com> <1349427871-31195-2-git-send-email-anthony.perard@citrix.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Ian Campbell , Xen Devel Subject: Re: [Xen-devel] [PATCH V3 1/3] libxl: Move gc_is_real to libxl_internal.h. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Anthony PERARD writes ("[PATCH V3 1/3] libxl: Move gc_is_real to libxl_internal.h."): > Signed-off-by: Anthony PERARD Acked-by: Ian Jackson (Strictly speaking there is no need to rename the function if it's going to be static inline, but it's fine to do so.) Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 10:15:59 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 10:15:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK4wQ-0000zP-Bm; Fri, 05 Oct 2012 10:15:34 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK4wO-0000zK-CF for xen-devel@lists.xen.org; Fri, 05 Oct 2012 10:15:32 +0000 Received: from [85.158.143.99:30355] by server-1.bemta-4.messagelabs.com id 59/E3-05684-343BE605; Fri, 05 Oct 2012 10:15:31 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1349432130!32640383!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29356 invoked from network); 5 Oct 2012 10:15:31 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 10:15:31 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14959195" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 10:15:30 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 11:15:29 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TK4wL-0006Pv-Ly; Fri, 05 Oct 2012 10:15:29 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TK4wL-0000Kr-DU; Fri, 05 Oct 2012 11:15:29 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20590.45889.100206.747892@mariner.uk.xensource.com> Date: Fri, 5 Oct 2012 11:15:29 +0100 To: Anthony PERARD In-Reply-To: <1349427871-31195-2-git-send-email-anthony.perard@citrix.com> References: <1349427871-31195-1-git-send-email-anthony.perard@citrix.com> <1349427871-31195-2-git-send-email-anthony.perard@citrix.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Ian Campbell , Xen Devel Subject: Re: [Xen-devel] [PATCH V3 1/3] libxl: Move gc_is_real to libxl_internal.h. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Anthony PERARD writes ("[PATCH V3 1/3] libxl: Move gc_is_real to libxl_internal.h."): > Signed-off-by: Anthony PERARD Acked-by: Ian Jackson (Strictly speaking there is no need to rename the function if it's going to be static inline, but it's fine to do so.) Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 10:16:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 10:16:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK4wl-00010Q-OP; Fri, 05 Oct 2012 10:15:55 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK4wk-00010E-8n for xen-devel@lists.xen.org; Fri, 05 Oct 2012 10:15:54 +0000 Received: from [85.158.139.211:14408] by server-11.bemta-5.messagelabs.com id 7C/45-13866-953BE605; Fri, 05 Oct 2012 10:15:53 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-9.tower-206.messagelabs.com!1349432152!19680079!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31282 invoked from network); 5 Oct 2012 10:15:52 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 10:15:52 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14959203" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 10:15:52 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 11:15:52 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TK4wh-0006Q6-RA; Fri, 05 Oct 2012 10:15:51 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TK4wh-0000L2-MS; Fri, 05 Oct 2012 11:15:51 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20590.45911.575872.827214@mariner.uk.xensource.com> Date: Fri, 5 Oct 2012 11:15:51 +0100 To: Anthony PERARD In-Reply-To: <1349427871-31195-3-git-send-email-anthony.perard@citrix.com> References: <1349427871-31195-1-git-send-email-anthony.perard@citrix.com> <1349427871-31195-3-git-send-email-anthony.perard@citrix.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Ian Campbell , Xen Devel Subject: Re: [Xen-devel] [PATCH V3 2/3] libxl: Have flexarray using the GC X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Anthony PERARD writes ("[PATCH V3 2/3] libxl: Have flexarray using the GC"): > This patch makes the flexarray function libxl__gc aware. Acked-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 10:16:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 10:16:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK4wl-00010Q-OP; Fri, 05 Oct 2012 10:15:55 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK4wk-00010E-8n for xen-devel@lists.xen.org; Fri, 05 Oct 2012 10:15:54 +0000 Received: from [85.158.139.211:14408] by server-11.bemta-5.messagelabs.com id 7C/45-13866-953BE605; Fri, 05 Oct 2012 10:15:53 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-9.tower-206.messagelabs.com!1349432152!19680079!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31282 invoked from network); 5 Oct 2012 10:15:52 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 10:15:52 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14959203" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 10:15:52 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 11:15:52 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TK4wh-0006Q6-RA; Fri, 05 Oct 2012 10:15:51 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TK4wh-0000L2-MS; Fri, 05 Oct 2012 11:15:51 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20590.45911.575872.827214@mariner.uk.xensource.com> Date: Fri, 5 Oct 2012 11:15:51 +0100 To: Anthony PERARD In-Reply-To: <1349427871-31195-3-git-send-email-anthony.perard@citrix.com> References: <1349427871-31195-1-git-send-email-anthony.perard@citrix.com> <1349427871-31195-3-git-send-email-anthony.perard@citrix.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Ian Campbell , Xen Devel Subject: Re: [Xen-devel] [PATCH V3 2/3] libxl: Have flexarray using the GC X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Anthony PERARD writes ("[PATCH V3 2/3] libxl: Have flexarray using the GC"): > This patch makes the flexarray function libxl__gc aware. Acked-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 10:37:24 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 10:37:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5HD-0001Jr-QM; Fri, 05 Oct 2012 10:37:03 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5HC-0001Jm-5Q for xen-devel@lists.xen.org; Fri, 05 Oct 2012 10:37:02 +0000 Received: from [85.158.138.51:3905] by server-7.bemta-3.messagelabs.com id 8A/38-15765-D48BE605; Fri, 05 Oct 2012 10:37:01 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1349433420!32712300!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6869 invoked from network); 5 Oct 2012 10:37:00 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 10:37:00 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14959707" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 10:37:00 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 11:37:00 +0100 Message-ID: <1349433418.20946.46.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Tim Deegan , Stefano Stabellini , Keir Fraser , Jan Beulich Date: Fri, 5 Oct 2012 11:36:58 +0100 Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: xen-devel Subject: [Xen-devel] [PATCH 00/21] Sweep through arm-for-4.3 branch + a bit extra X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org The following consists of the ARM patches which were queued during the 4.2 freeze in git://xenbits.xen.org/people/ianc/xen-unstable.git arm-for-4.3 plus v4 of Stefano's "ARM hypercall ABI: 64 bit ready" rebased on current xen-unstable. Plus a couple of extras. Stefano's 64 bit interfaces patches needed a little bit of rebasing, due to the dropping of x86_32, the changes s/int/long/ in hypercall returns etc. Nothing major. I've tried to note in the changelog what I had to do. Stefano, it might be worth double checking you are happy with my rebase. The patch "HACK: arm: initial XENMAPSPACE_gmfn_foreign" from my branch and the patch "xen: improve changes to xen_add_to_physmap" from Stefano's series are dropped in favour of the new, non-hack implementation of foreign privileged mappings in "xen: arm: implement XENMEM_add_to_physmap_range". I've rebased this in at the beginning of the series (where HACK... was), which meant tweaking Stefano's old "xen/arm: grant table" just a tad. Note that I've dropped support for foreign mappings via XENMEM_add_to_physmap and therefore the union which Stefano added is gone. There is a bisectibility issue from "xen: introduce XEN_GUEST_HANDLE_PARAM" onwards so those patches should be considered RFC for now. (see <1349428386.20946.15.camel@zakaz.uk.xensource.com> posted this morning). There is also an issue with compat param handle handling exposed by tmem which I haven't looked at properly yet. This stuff works with the kernel tree described in <1349363496.866.49.camel@zakaz.uk.xensource.com> "arm: implement ballooning and privcmd foreign mappings based on x86 PVH" Keir, Jan, I've only CC'd you on those of the following which touch common or x86 code (basically "xen: xen_ulong_t substitution" onwards). N == New, or recently posted to the list A == ACKED B == Was in arm-for-4.3 branch R == RFC only 01 N xen: arm: implement XENMEM_add_to_physmap_range 02 B libxc: add ARM support to xc_dom (PV domain building) 03 AB arm: implement VGCF_online 04 AB xen/arm: implement page reference and gnttab functions needed by grant_table.c 05 AB xen/arm: implement get/put_page_type 06 AB xen/arm: create_p2m_entries should not call free_domheap_page 07 AB xen/arm: grant table 08 B arm: kill a guest which uses hvc with an immediate operand != XEN_HYPERCALL_TAG 09 AB libxc/arm: allocate xenstore and console pages 10 AB arm: disable distributor delivery on boot CPU only 11 AB xen/arm: protect LR registers and lr_mask changes with spin_lock_irq 12 AB xen/arm: introduce __lshrdi3 and __aeabi_llsr 13 AB arm: don't bother setting up vtimer, vgic etc on idle CPUs 14 AB arm/vtimer: convert result to ticks when reading CNTPCT register 15 AB arm: Use per-CPU irq_desc for PPIs and SGIs 16 N arm: tools: add arm to foreign structs checking 17 xen: xen_ulong_t substitution 18 xen: change the limit of nr_extents to UINT_MAX >> MEMOP_EXTENT_SHIFT 19 R xen: introduce XEN_GUEST_HANDLE_PARAM 20 R xen: replace XEN_GUEST_HANDLE with XEN_GUEST_HANDLE_PARAM when appropriate 21 R xen: more substitutions Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 10:37:24 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 10:37:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5HD-0001Jr-QM; Fri, 05 Oct 2012 10:37:03 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5HC-0001Jm-5Q for xen-devel@lists.xen.org; Fri, 05 Oct 2012 10:37:02 +0000 Received: from [85.158.138.51:3905] by server-7.bemta-3.messagelabs.com id 8A/38-15765-D48BE605; Fri, 05 Oct 2012 10:37:01 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1349433420!32712300!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6869 invoked from network); 5 Oct 2012 10:37:00 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 10:37:00 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14959707" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 10:37:00 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 11:37:00 +0100 Message-ID: <1349433418.20946.46.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Tim Deegan , Stefano Stabellini , Keir Fraser , Jan Beulich Date: Fri, 5 Oct 2012 11:36:58 +0100 Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: xen-devel Subject: [Xen-devel] [PATCH 00/21] Sweep through arm-for-4.3 branch + a bit extra X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org The following consists of the ARM patches which were queued during the 4.2 freeze in git://xenbits.xen.org/people/ianc/xen-unstable.git arm-for-4.3 plus v4 of Stefano's "ARM hypercall ABI: 64 bit ready" rebased on current xen-unstable. Plus a couple of extras. Stefano's 64 bit interfaces patches needed a little bit of rebasing, due to the dropping of x86_32, the changes s/int/long/ in hypercall returns etc. Nothing major. I've tried to note in the changelog what I had to do. Stefano, it might be worth double checking you are happy with my rebase. The patch "HACK: arm: initial XENMAPSPACE_gmfn_foreign" from my branch and the patch "xen: improve changes to xen_add_to_physmap" from Stefano's series are dropped in favour of the new, non-hack implementation of foreign privileged mappings in "xen: arm: implement XENMEM_add_to_physmap_range". I've rebased this in at the beginning of the series (where HACK... was), which meant tweaking Stefano's old "xen/arm: grant table" just a tad. Note that I've dropped support for foreign mappings via XENMEM_add_to_physmap and therefore the union which Stefano added is gone. There is a bisectibility issue from "xen: introduce XEN_GUEST_HANDLE_PARAM" onwards so those patches should be considered RFC for now. (see <1349428386.20946.15.camel@zakaz.uk.xensource.com> posted this morning). There is also an issue with compat param handle handling exposed by tmem which I haven't looked at properly yet. This stuff works with the kernel tree described in <1349363496.866.49.camel@zakaz.uk.xensource.com> "arm: implement ballooning and privcmd foreign mappings based on x86 PVH" Keir, Jan, I've only CC'd you on those of the following which touch common or x86 code (basically "xen: xen_ulong_t substitution" onwards). N == New, or recently posted to the list A == ACKED B == Was in arm-for-4.3 branch R == RFC only 01 N xen: arm: implement XENMEM_add_to_physmap_range 02 B libxc: add ARM support to xc_dom (PV domain building) 03 AB arm: implement VGCF_online 04 AB xen/arm: implement page reference and gnttab functions needed by grant_table.c 05 AB xen/arm: implement get/put_page_type 06 AB xen/arm: create_p2m_entries should not call free_domheap_page 07 AB xen/arm: grant table 08 B arm: kill a guest which uses hvc with an immediate operand != XEN_HYPERCALL_TAG 09 AB libxc/arm: allocate xenstore and console pages 10 AB arm: disable distributor delivery on boot CPU only 11 AB xen/arm: protect LR registers and lr_mask changes with spin_lock_irq 12 AB xen/arm: introduce __lshrdi3 and __aeabi_llsr 13 AB arm: don't bother setting up vtimer, vgic etc on idle CPUs 14 AB arm/vtimer: convert result to ticks when reading CNTPCT register 15 AB arm: Use per-CPU irq_desc for PPIs and SGIs 16 N arm: tools: add arm to foreign structs checking 17 xen: xen_ulong_t substitution 18 xen: change the limit of nr_extents to UINT_MAX >> MEMOP_EXTENT_SHIFT 19 R xen: introduce XEN_GUEST_HANDLE_PARAM 20 R xen: replace XEN_GUEST_HANDLE with XEN_GUEST_HANDLE_PARAM when appropriate 21 R xen: more substitutions Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 10:38:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 10:38:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5Ii-0001Oy-9i; Fri, 05 Oct 2012 10:38:36 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5Ig-0001Oa-3v for xen-devel@lists.xen.org; Fri, 05 Oct 2012 10:38:34 +0000 Received: from [85.158.143.35:44428] by server-1.bemta-4.messagelabs.com id 4E/95-05684-9A8BE605; Fri, 05 Oct 2012 10:38:33 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1349433509!14025963!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODA1MjM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16146 invoked from network); 5 Oct 2012 10:38:30 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 10:38:30 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="210396440" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 10:38:28 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 06:38:28 -0400 Received: from [10.80.246.74] (helo=army.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK5Ia-0003Rm-43; Fri, 05 Oct 2012 11:38:28 +0100 From: Ian Campbell To: Date: Fri, 5 Oct 2012 10:38:07 +0000 Message-ID: <1349433507-21148-1-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.9.1 In-Reply-To: <1349433418.20946.46.camel@zakaz.uk.xensource.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: tim@xen.org, Ian Campbell , stefano.stabelini@citrix.com Subject: [Xen-devel] [PATCH 01/21] xen: arm: implement XENMEM_add_to_physmap_range X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This allows for foreign mappings as well as batching, fitting all that into XENMEM_add_to_physmap wasn't possible. Signed-off-by: Ian Campbell --- xen/arch/arm/mm.c | 120 ++++++++++++++++++++++++++++++++++++++----- xen/include/public/memory.h | 40 +++++++++++--- xen/include/public/xen.h | 1 + 3 files changed, 139 insertions(+), 22 deletions(-) diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c index 40ac176..dde304b 100644 --- a/xen/arch/arm/mm.c +++ b/xen/arch/arm/mm.c @@ -25,6 +25,8 @@ #include #include #include +#include +#include #include #include #include @@ -461,37 +463,96 @@ void share_xen_page_with_guest(struct page_info *page, spin_unlock(&d->page_alloc_lock); } -static int xenmem_add_to_physmap_once( +static int xenmem_add_to_physmap_one( struct domain *d, - const struct xen_add_to_physmap *xatp) + uint16_t space, + domid_t foreign_domid, + unsigned long idx, + xen_pfn_t gpfn) { unsigned long mfn = 0; int rc; - switch ( xatp->space ) + switch ( space ) { - case XENMAPSPACE_shared_info: - if ( xatp->idx == 0 ) - mfn = virt_to_mfn(d->shared_info); - break; - default: - return -ENOSYS; + case XENMAPSPACE_shared_info: + if ( idx == 0 ) + mfn = virt_to_mfn(d->shared_info); + break; + case XENMAPSPACE_gmfn_foreign: + { + paddr_t maddr; + struct domain *od; + rc = rcu_lock_target_domain_by_id(foreign_domid, &od); + if ( rc < 0 ) + return rc; + + maddr = p2m_lookup(od, idx << PAGE_SHIFT); + if ( maddr == INVALID_PADDR ) + { + dump_p2m_lookup(od, idx << PAGE_SHIFT); + rcu_unlock_domain(od); + return -EINVAL; + } + + mfn = maddr >> PAGE_SHIFT; + + rcu_unlock_domain(od); + break; + } + + default: + return -ENOSYS; } domain_lock(d); /* Map at new location. */ - rc = guest_physmap_add_page(d, xatp->gpfn, mfn, 0); + rc = guest_physmap_add_page(d, gpfn, mfn, 0); domain_unlock(d); return rc; } -static int xenmem_add_to_physmap(struct domain *d, - struct xen_add_to_physmap *xatp) +static int xenmem_add_to_physmap_range(struct domain *d, + struct xen_add_to_physmap_range *xatpr) { - return xenmem_add_to_physmap_once(d, xatp); + int rc; + + /* Process entries in reverse order to allow continuations */ + while ( xatpr->size > 0 ) + { + xen_ulong_t idx; + xen_pfn_t gpfn; + + rc = copy_from_guest_offset(&idx, xatpr->idxs, xatpr->size-1, 1); + if ( rc < 0 ) + goto out; + + rc = copy_from_guest_offset(&gpfn, xatpr->gpfns, xatpr->size-1, 1); + if ( rc < 0 ) + goto out; + + rc = xenmem_add_to_physmap_one(d, xatpr->space, + xatpr->foreign_domid, + idx, gpfn); + + xatpr->size--; + + /* Check for continuation if it's not the last interation */ + if ( xatpr->size > 0 && hypercall_preempt_check() ) + { + rc = -EAGAIN; + goto out; + } + } + + rc = 0; + +out: + return rc; + } long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg) @@ -508,14 +569,45 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg) if ( copy_from_guest(&xatp, arg, 1) ) return -EFAULT; + /* This one is only supported by add_to_physmap_range */ + if ( xatp.space == XENMAPSPACE_gmfn_foreign ) + return -EINVAL; + rc = rcu_lock_target_domain_by_id(xatp.domid, &d); if ( rc != 0 ) return rc; - rc = xenmem_add_to_physmap(d, &xatp); + rc = xenmem_add_to_physmap_one(d, xatp.space, DOMID_INVALID, + xatp.idx, xatp.gpfn); + + rcu_unlock_domain(d); + + return rc; + } + + case XENMEM_add_to_physmap_range: + { + struct xen_add_to_physmap_range xatpr; + struct domain *d; + + if ( copy_from_guest(&xatpr, arg, 1) ) + return -EFAULT; + + rc = rcu_lock_target_domain_by_id(xatpr.domid, &d); + if ( rc != 0 ) + return rc; + + rc = xenmem_add_to_physmap_range(d, &xatpr); rcu_unlock_domain(d); + if ( rc && copy_to_guest(arg, &xatpr, 1) ) + rc = -EFAULT; + + if ( rc == -EAGAIN ) + rc = hypercall_create_continuation( + __HYPERVISOR_memory_op, "ih", op, arg); + return rc; } diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h index 86d02c8..f1ddbc0 100644 --- a/xen/include/public/memory.h +++ b/xen/include/public/memory.h @@ -198,6 +198,15 @@ struct xen_machphys_mapping { typedef struct xen_machphys_mapping xen_machphys_mapping_t; DEFINE_XEN_GUEST_HANDLE(xen_machphys_mapping_t); +/* Source mapping space. */ +/* ` enum phys_map_space { */ +#define XENMAPSPACE_shared_info 0 /* shared info page */ +#define XENMAPSPACE_grant_table 1 /* grant table page */ +#define XENMAPSPACE_gmfn 2 /* GMFN */ +#define XENMAPSPACE_gmfn_range 3 /* GMFN range */ +#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another dom */ +/* ` } */ + /* * Sets the GPFN at which a particular page appears in the specified guest's * pseudophysical address space. @@ -211,24 +220,39 @@ struct xen_add_to_physmap { /* Number of pages to go through for gmfn_range */ uint16_t size; - /* Source mapping space. */ -#define XENMAPSPACE_shared_info 0 /* shared info page */ -#define XENMAPSPACE_grant_table 1 /* grant table page */ -#define XENMAPSPACE_gmfn 2 /* GMFN */ -#define XENMAPSPACE_gmfn_range 3 /* GMFN range */ - unsigned int space; + unsigned int space; /* => enum phys_map_space */ #define XENMAPIDX_grant_table_status 0x80000000 - /* Index into source mapping space. */ + /* Index into space being mapped. */ xen_ulong_t idx; - /* GPFN where the source mapping page should appear. */ + /* GPFN in domid where the source mapping page should appear. */ xen_pfn_t gpfn; }; typedef struct xen_add_to_physmap xen_add_to_physmap_t; DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_t); +/* A batched version of add_to_physmap. */ +#define XENMEM_add_to_physmap_range 23 +struct xen_add_to_physmap_range { + /* Which domain to change the mapping for. */ + domid_t domid; + uint16_t space; /* => enum phys_map_space */ + + /* Number of pages to go through */ + uint16_t size; + domid_t foreign_domid; /* IFF gmfn_foreign */ + + /* Indexes into space being mapped. */ + XEN_GUEST_HANDLE(xen_ulong_t) idxs; + + /* GPFN in domdwhere the source mapping page should appear. */ + XEN_GUEST_HANDLE(xen_pfn_t) gpfns; +}; +typedef struct xen_add_to_physmap_range xen_add_to_physmap_range_t; +DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_range_t); + /* * Unmaps the page appearing at a particular GPFN from the specified guest's * pseudophysical address space. diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h index 361398b..e42d01f 100644 --- a/xen/include/public/xen.h +++ b/xen/include/public/xen.h @@ -49,6 +49,7 @@ DEFINE_XEN_GUEST_HANDLE(void); DEFINE_XEN_GUEST_HANDLE(uint64_t); DEFINE_XEN_GUEST_HANDLE(xen_pfn_t); +DEFINE_XEN_GUEST_HANDLE(xen_ulong_t); #endif /* -- 1.7.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 10:38:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 10:38:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5Ii-0001Oy-9i; Fri, 05 Oct 2012 10:38:36 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5Ig-0001Oa-3v for xen-devel@lists.xen.org; Fri, 05 Oct 2012 10:38:34 +0000 Received: from [85.158.143.35:44428] by server-1.bemta-4.messagelabs.com id 4E/95-05684-9A8BE605; Fri, 05 Oct 2012 10:38:33 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1349433509!14025963!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODA1MjM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16146 invoked from network); 5 Oct 2012 10:38:30 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 10:38:30 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="210396440" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 10:38:28 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 06:38:28 -0400 Received: from [10.80.246.74] (helo=army.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK5Ia-0003Rm-43; Fri, 05 Oct 2012 11:38:28 +0100 From: Ian Campbell To: Date: Fri, 5 Oct 2012 10:38:07 +0000 Message-ID: <1349433507-21148-1-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.9.1 In-Reply-To: <1349433418.20946.46.camel@zakaz.uk.xensource.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: tim@xen.org, Ian Campbell , stefano.stabelini@citrix.com Subject: [Xen-devel] [PATCH 01/21] xen: arm: implement XENMEM_add_to_physmap_range X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This allows for foreign mappings as well as batching, fitting all that into XENMEM_add_to_physmap wasn't possible. Signed-off-by: Ian Campbell --- xen/arch/arm/mm.c | 120 ++++++++++++++++++++++++++++++++++++++----- xen/include/public/memory.h | 40 +++++++++++--- xen/include/public/xen.h | 1 + 3 files changed, 139 insertions(+), 22 deletions(-) diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c index 40ac176..dde304b 100644 --- a/xen/arch/arm/mm.c +++ b/xen/arch/arm/mm.c @@ -25,6 +25,8 @@ #include #include #include +#include +#include #include #include #include @@ -461,37 +463,96 @@ void share_xen_page_with_guest(struct page_info *page, spin_unlock(&d->page_alloc_lock); } -static int xenmem_add_to_physmap_once( +static int xenmem_add_to_physmap_one( struct domain *d, - const struct xen_add_to_physmap *xatp) + uint16_t space, + domid_t foreign_domid, + unsigned long idx, + xen_pfn_t gpfn) { unsigned long mfn = 0; int rc; - switch ( xatp->space ) + switch ( space ) { - case XENMAPSPACE_shared_info: - if ( xatp->idx == 0 ) - mfn = virt_to_mfn(d->shared_info); - break; - default: - return -ENOSYS; + case XENMAPSPACE_shared_info: + if ( idx == 0 ) + mfn = virt_to_mfn(d->shared_info); + break; + case XENMAPSPACE_gmfn_foreign: + { + paddr_t maddr; + struct domain *od; + rc = rcu_lock_target_domain_by_id(foreign_domid, &od); + if ( rc < 0 ) + return rc; + + maddr = p2m_lookup(od, idx << PAGE_SHIFT); + if ( maddr == INVALID_PADDR ) + { + dump_p2m_lookup(od, idx << PAGE_SHIFT); + rcu_unlock_domain(od); + return -EINVAL; + } + + mfn = maddr >> PAGE_SHIFT; + + rcu_unlock_domain(od); + break; + } + + default: + return -ENOSYS; } domain_lock(d); /* Map at new location. */ - rc = guest_physmap_add_page(d, xatp->gpfn, mfn, 0); + rc = guest_physmap_add_page(d, gpfn, mfn, 0); domain_unlock(d); return rc; } -static int xenmem_add_to_physmap(struct domain *d, - struct xen_add_to_physmap *xatp) +static int xenmem_add_to_physmap_range(struct domain *d, + struct xen_add_to_physmap_range *xatpr) { - return xenmem_add_to_physmap_once(d, xatp); + int rc; + + /* Process entries in reverse order to allow continuations */ + while ( xatpr->size > 0 ) + { + xen_ulong_t idx; + xen_pfn_t gpfn; + + rc = copy_from_guest_offset(&idx, xatpr->idxs, xatpr->size-1, 1); + if ( rc < 0 ) + goto out; + + rc = copy_from_guest_offset(&gpfn, xatpr->gpfns, xatpr->size-1, 1); + if ( rc < 0 ) + goto out; + + rc = xenmem_add_to_physmap_one(d, xatpr->space, + xatpr->foreign_domid, + idx, gpfn); + + xatpr->size--; + + /* Check for continuation if it's not the last interation */ + if ( xatpr->size > 0 && hypercall_preempt_check() ) + { + rc = -EAGAIN; + goto out; + } + } + + rc = 0; + +out: + return rc; + } long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg) @@ -508,14 +569,45 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg) if ( copy_from_guest(&xatp, arg, 1) ) return -EFAULT; + /* This one is only supported by add_to_physmap_range */ + if ( xatp.space == XENMAPSPACE_gmfn_foreign ) + return -EINVAL; + rc = rcu_lock_target_domain_by_id(xatp.domid, &d); if ( rc != 0 ) return rc; - rc = xenmem_add_to_physmap(d, &xatp); + rc = xenmem_add_to_physmap_one(d, xatp.space, DOMID_INVALID, + xatp.idx, xatp.gpfn); + + rcu_unlock_domain(d); + + return rc; + } + + case XENMEM_add_to_physmap_range: + { + struct xen_add_to_physmap_range xatpr; + struct domain *d; + + if ( copy_from_guest(&xatpr, arg, 1) ) + return -EFAULT; + + rc = rcu_lock_target_domain_by_id(xatpr.domid, &d); + if ( rc != 0 ) + return rc; + + rc = xenmem_add_to_physmap_range(d, &xatpr); rcu_unlock_domain(d); + if ( rc && copy_to_guest(arg, &xatpr, 1) ) + rc = -EFAULT; + + if ( rc == -EAGAIN ) + rc = hypercall_create_continuation( + __HYPERVISOR_memory_op, "ih", op, arg); + return rc; } diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h index 86d02c8..f1ddbc0 100644 --- a/xen/include/public/memory.h +++ b/xen/include/public/memory.h @@ -198,6 +198,15 @@ struct xen_machphys_mapping { typedef struct xen_machphys_mapping xen_machphys_mapping_t; DEFINE_XEN_GUEST_HANDLE(xen_machphys_mapping_t); +/* Source mapping space. */ +/* ` enum phys_map_space { */ +#define XENMAPSPACE_shared_info 0 /* shared info page */ +#define XENMAPSPACE_grant_table 1 /* grant table page */ +#define XENMAPSPACE_gmfn 2 /* GMFN */ +#define XENMAPSPACE_gmfn_range 3 /* GMFN range */ +#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another dom */ +/* ` } */ + /* * Sets the GPFN at which a particular page appears in the specified guest's * pseudophysical address space. @@ -211,24 +220,39 @@ struct xen_add_to_physmap { /* Number of pages to go through for gmfn_range */ uint16_t size; - /* Source mapping space. */ -#define XENMAPSPACE_shared_info 0 /* shared info page */ -#define XENMAPSPACE_grant_table 1 /* grant table page */ -#define XENMAPSPACE_gmfn 2 /* GMFN */ -#define XENMAPSPACE_gmfn_range 3 /* GMFN range */ - unsigned int space; + unsigned int space; /* => enum phys_map_space */ #define XENMAPIDX_grant_table_status 0x80000000 - /* Index into source mapping space. */ + /* Index into space being mapped. */ xen_ulong_t idx; - /* GPFN where the source mapping page should appear. */ + /* GPFN in domid where the source mapping page should appear. */ xen_pfn_t gpfn; }; typedef struct xen_add_to_physmap xen_add_to_physmap_t; DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_t); +/* A batched version of add_to_physmap. */ +#define XENMEM_add_to_physmap_range 23 +struct xen_add_to_physmap_range { + /* Which domain to change the mapping for. */ + domid_t domid; + uint16_t space; /* => enum phys_map_space */ + + /* Number of pages to go through */ + uint16_t size; + domid_t foreign_domid; /* IFF gmfn_foreign */ + + /* Indexes into space being mapped. */ + XEN_GUEST_HANDLE(xen_ulong_t) idxs; + + /* GPFN in domdwhere the source mapping page should appear. */ + XEN_GUEST_HANDLE(xen_pfn_t) gpfns; +}; +typedef struct xen_add_to_physmap_range xen_add_to_physmap_range_t; +DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_range_t); + /* * Unmaps the page appearing at a particular GPFN from the specified guest's * pseudophysical address space. diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h index 361398b..e42d01f 100644 --- a/xen/include/public/xen.h +++ b/xen/include/public/xen.h @@ -49,6 +49,7 @@ DEFINE_XEN_GUEST_HANDLE(void); DEFINE_XEN_GUEST_HANDLE(uint64_t); DEFINE_XEN_GUEST_HANDLE(xen_pfn_t); +DEFINE_XEN_GUEST_HANDLE(xen_ulong_t); #endif /* -- 1.7.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 10:38:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 10:38:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5Ii-0001PA-Lq; Fri, 05 Oct 2012 10:38:36 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5Ig-0001Ob-Ar for xen-devel@lists.xen.org; Fri, 05 Oct 2012 10:38:34 +0000 Received: from [85.158.139.211:53642] by server-9.bemta-5.messagelabs.com id 47/CE-14846-9A8BE605; Fri, 05 Oct 2012 10:38:33 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-206.messagelabs.com!1349433511!21178219!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODA1MjM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13888 invoked from network); 5 Oct 2012 10:38:32 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 10:38:32 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="210396439" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 10:38:28 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 06:38:28 -0400 Received: from [10.80.246.74] (helo=army.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK5Ia-0003Rm-8x; Fri, 05 Oct 2012 11:38:28 +0100 From: Ian Campbell To: Date: Fri, 5 Oct 2012 10:38:09 +0000 Message-ID: <1349433507-21148-3-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.9.1 In-Reply-To: <1349433418.20946.46.camel@zakaz.uk.xensource.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: tim@xen.org, Ian Campbell , stefano.stabelini@citrix.com Subject: [Xen-devel] [PATCH 03/21] arm: implement VGCF_online X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Ian Campbell Acked-by: Tim Deegan --- tools/libxc/xc_dom_arm.c | 2 ++ xen/arch/arm/domain.c | 5 ++++- xen/include/public/arch-arm.h | 4 ++++ 3 files changed, 10 insertions(+), 1 deletions(-) diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c index 3eef0d0..65dafe8 100644 --- a/tools/libxc/xc_dom_arm.c +++ b/tools/libxc/xc_dom_arm.c @@ -101,6 +101,8 @@ static int vcpu_arm(struct xc_dom_image *dom, void *ptr) ctxt->user_regs.cpsr = PSR_ABT_MASK|PSR_FIQ_MASK|PSR_IRQ_MASK|PSR_MODE_SVC; + ctxt->flags = VGCF_online; + DOMPRINTF("Initial state CPSR %#"PRIx32" PC %#"PRIx32, ctxt->user_regs.cpsr, ctxt->user_regs.pc); diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c index 57d8746..ee58d68 100644 --- a/xen/arch/arm/domain.c +++ b/xen/arch/arm/domain.c @@ -503,7 +503,10 @@ int arch_set_info_guest( v->arch.ttbr1 = ctxt->ttbr1; v->arch.ttbcr = ctxt->ttbcr; - clear_bit(_VPF_down, &v->pause_flags); + if ( ctxt->flags & VGCF_online ) + clear_bit(_VPF_down, &v->pause_flags); + else + set_bit(_VPF_down, &v->pause_flags); return 0; } diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h index f18bafa..e3d4ad9 100644 --- a/xen/include/public/arch-arm.h +++ b/xen/include/public/arch-arm.h @@ -125,6 +125,10 @@ typedef uint64_t xen_pfn_t; typedef uint32_t xen_ulong_t; struct vcpu_guest_context { +#define _VGCF_online 0 +#define VGCF_online (1<<_VGCF_online) + uint32_t flags; /* VGCF_* */ + struct cpu_user_regs user_regs; /* User-level CPU registers */ uint32_t sctlr; -- 1.7.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 10:38:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 10:38:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5Ii-0001PA-Lq; Fri, 05 Oct 2012 10:38:36 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5Ig-0001Ob-Ar for xen-devel@lists.xen.org; Fri, 05 Oct 2012 10:38:34 +0000 Received: from [85.158.139.211:53642] by server-9.bemta-5.messagelabs.com id 47/CE-14846-9A8BE605; Fri, 05 Oct 2012 10:38:33 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-206.messagelabs.com!1349433511!21178219!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODA1MjM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13888 invoked from network); 5 Oct 2012 10:38:32 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 10:38:32 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="210396439" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 10:38:28 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 06:38:28 -0400 Received: from [10.80.246.74] (helo=army.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK5Ia-0003Rm-8x; Fri, 05 Oct 2012 11:38:28 +0100 From: Ian Campbell To: Date: Fri, 5 Oct 2012 10:38:09 +0000 Message-ID: <1349433507-21148-3-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.9.1 In-Reply-To: <1349433418.20946.46.camel@zakaz.uk.xensource.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: tim@xen.org, Ian Campbell , stefano.stabelini@citrix.com Subject: [Xen-devel] [PATCH 03/21] arm: implement VGCF_online X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Ian Campbell Acked-by: Tim Deegan --- tools/libxc/xc_dom_arm.c | 2 ++ xen/arch/arm/domain.c | 5 ++++- xen/include/public/arch-arm.h | 4 ++++ 3 files changed, 10 insertions(+), 1 deletions(-) diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c index 3eef0d0..65dafe8 100644 --- a/tools/libxc/xc_dom_arm.c +++ b/tools/libxc/xc_dom_arm.c @@ -101,6 +101,8 @@ static int vcpu_arm(struct xc_dom_image *dom, void *ptr) ctxt->user_regs.cpsr = PSR_ABT_MASK|PSR_FIQ_MASK|PSR_IRQ_MASK|PSR_MODE_SVC; + ctxt->flags = VGCF_online; + DOMPRINTF("Initial state CPSR %#"PRIx32" PC %#"PRIx32, ctxt->user_regs.cpsr, ctxt->user_regs.pc); diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c index 57d8746..ee58d68 100644 --- a/xen/arch/arm/domain.c +++ b/xen/arch/arm/domain.c @@ -503,7 +503,10 @@ int arch_set_info_guest( v->arch.ttbr1 = ctxt->ttbr1; v->arch.ttbcr = ctxt->ttbcr; - clear_bit(_VPF_down, &v->pause_flags); + if ( ctxt->flags & VGCF_online ) + clear_bit(_VPF_down, &v->pause_flags); + else + set_bit(_VPF_down, &v->pause_flags); return 0; } diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h index f18bafa..e3d4ad9 100644 --- a/xen/include/public/arch-arm.h +++ b/xen/include/public/arch-arm.h @@ -125,6 +125,10 @@ typedef uint64_t xen_pfn_t; typedef uint32_t xen_ulong_t; struct vcpu_guest_context { +#define _VGCF_online 0 +#define VGCF_online (1<<_VGCF_online) + uint32_t flags; /* VGCF_* */ + struct cpu_user_regs user_regs; /* User-level CPU registers */ uint32_t sctlr; -- 1.7.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 10:38:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 10:38:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5Ij-0001PP-Ez; Fri, 05 Oct 2012 10:38:37 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5Ih-0001Ol-1N for xen-devel@lists.xen.org; Fri, 05 Oct 2012 10:38:35 +0000 Received: from [85.158.143.35:44496] by server-2.bemta-4.messagelabs.com id 81/B2-06610-AA8BE605; Fri, 05 Oct 2012 10:38:34 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1349433509!14025963!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODA1MjM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16209 invoked from network); 5 Oct 2012 10:38:31 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 10:38:31 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="210396441" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 10:38:28 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 06:38:28 -0400 Received: from [10.80.246.74] (helo=army.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK5Ia-0003Rm-6V; Fri, 05 Oct 2012 11:38:28 +0100 From: Ian Campbell To: Date: Fri, 5 Oct 2012 10:38:08 +0000 Message-ID: <1349433507-21148-2-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.9.1 In-Reply-To: <1349433418.20946.46.camel@zakaz.uk.xensource.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: tim@xen.org, Ian Campbell , stefano.stabelini@citrix.com Subject: [Xen-devel] [PATCH 02/21] libxc: add ARM support to xc_dom (PV domain building) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Includes ARM zImage support. Signed-off-by: Ian Campbell --- tools/libxc/Makefile | 1 + tools/libxc/xc_dom.h | 20 ++++- tools/libxc/xc_dom_arm.c | 140 ++++++++++++++++++++++++++- tools/libxc/xc_dom_armzimageloader.c | 174 ++++++++++++++++++++++++++++++++++ tools/libxc/xc_dom_core.c | 10 +- tools/libxc/xg_private.h | 4 + 6 files changed, 339 insertions(+), 10 deletions(-) create mode 100644 tools/libxc/xc_dom_armzimageloader.c diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile index 441ba4d..d44abf9 100644 --- a/tools/libxc/Makefile +++ b/tools/libxc/Makefile @@ -58,6 +58,7 @@ GUEST_SRCS-y += libelf-dominfo.c libelf-relocate.c GUEST_SRCS-y += xc_dom_core.c xc_dom_boot.c GUEST_SRCS-y += xc_dom_elfloader.c GUEST_SRCS-$(CONFIG_X86) += xc_dom_bzimageloader.c +GUEST_SRCS-$(CONFIG_ARM) += xc_dom_armzimageloader.c GUEST_SRCS-y += xc_dom_binloader.c GUEST_SRCS-y += xc_dom_compat_linux.c diff --git a/tools/libxc/xc_dom.h b/tools/libxc/xc_dom.h index 2aef64a..3cd6dae 100644 --- a/tools/libxc/xc_dom.h +++ b/tools/libxc/xc_dom.h @@ -89,10 +89,24 @@ struct xc_dom_image { /* other state info */ uint32_t f_active[XENFEAT_NR_SUBMAPS]; + /* + * p2m_host maps guest physical addresses an offset from + * rambase_pfn (see below) into gfns. + * + * For a pure PV guest this means that it maps GPFNs into MFNs for + * a hybrid guest this means that it maps GPFNs to GPFNS. + * + * Note that the input is offset by rambase. + */ xen_pfn_t *p2m_host; void *p2m_guest; - /* physical memory */ + /* physical memory + * + * A PV guest has a single contiguous block of physical RAM, + * consisting of total_pages starting at rambase_pfn. + */ + xen_pfn_t rambase_pfn; xen_pfn_t total_pages; struct xc_dom_phys *phys_pages; int realmodearea_log; @@ -286,7 +300,7 @@ static inline xen_pfn_t xc_dom_p2m_host(struct xc_dom_image *dom, xen_pfn_t pfn) { if (dom->shadow_enabled) return pfn; - return dom->p2m_host[pfn]; + return dom->p2m_host[pfn - dom->rambase_pfn]; } static inline xen_pfn_t xc_dom_p2m_guest(struct xc_dom_image *dom, @@ -294,7 +308,7 @@ static inline xen_pfn_t xc_dom_p2m_guest(struct xc_dom_image *dom, { if (xc_dom_feature_translated(dom)) return pfn; - return dom->p2m_host[pfn]; + return dom->p2m_host[pfn - dom->rambase_pfn]; } /* --- arch bits --------------------------------------------------- */ diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c index 122d0e8..3eef0d0 100644 --- a/tools/libxc/xc_dom_arm.c +++ b/tools/libxc/xc_dom_arm.c @@ -18,14 +18,143 @@ * Copyright (c) 2011, Citrix Systems */ #include + #include +#include + #include "xg_private.h" #include "xc_dom.h" +/* ------------------------------------------------------------------------ */ +/* + * arm guests are hybrid and start off with paging disabled, therefore no + * pagetables and nothing to do here. + */ +static int count_pgtables_arm(struct xc_dom_image *dom) +{ + DOMPRINTF_CALLED(dom->xch); + return 0; +} + +static int setup_pgtables_arm(struct xc_dom_image *dom) +{ + DOMPRINTF_CALLED(dom->xch); + return 0; +} + +/* ------------------------------------------------------------------------ */ + +static int alloc_magic_pages(struct xc_dom_image *dom) +{ + DOMPRINTF_CALLED(dom->xch); + /* XXX + * dom->p2m_guest + * dom->start_info_pfn + * dom->xenstore_pfn + * dom->console_pfn + */ + return 0; +} + +/* ------------------------------------------------------------------------ */ + +static int start_info_arm(struct xc_dom_image *dom) +{ + DOMPRINTF_CALLED(dom->xch); + return 0; +} + +static int shared_info_arm(struct xc_dom_image *dom, void *ptr) +{ + DOMPRINTF_CALLED(dom->xch); + return 0; +} + +/* ------------------------------------------------------------------------ */ + +static int vcpu_arm(struct xc_dom_image *dom, void *ptr) +{ + vcpu_guest_context_t *ctxt = ptr; + + DOMPRINTF_CALLED(dom->xch); + + /* clear everything */ + memset(ctxt, 0, sizeof(*ctxt)); + + ctxt->user_regs.pc = dom->parms.virt_entry; + + /* Linux boot protocol. See linux.Documentation/arm/Booting. */ + ctxt->user_regs.r0 = 0; /* SBZ */ + /* Machine ID: We use DTB therefore no machine id */ + ctxt->user_regs.r1 = 0xffffffff; + /* ATAGS/DTB: We currently require that the guest kernel to be + * using CONFIG_ARM_APPENDED_DTB. Ensure that r2 does not look + * like a valid pointer to a set of ATAGS or a DTB. + */ + ctxt->user_regs.r2 = 0xffffffff; + + ctxt->sctlr = /* #define SCTLR_BASE */0x00c50078; + + ctxt->ttbr0 = 0; + ctxt->ttbr1 = 0; + ctxt->ttbcr = 0; /* Defined Reset Value */ + + ctxt->user_regs.cpsr = PSR_ABT_MASK|PSR_FIQ_MASK|PSR_IRQ_MASK|PSR_MODE_SVC; + + DOMPRINTF("Initial state CPSR %#"PRIx32" PC %#"PRIx32, + ctxt->user_regs.cpsr, ctxt->user_regs.pc); + + return 0; +} + +/* ------------------------------------------------------------------------ */ + +static struct xc_dom_arch xc_dom_32 = { + .guest_type = "xen-3.0-armv7l", + .native_protocol = XEN_IO_PROTO_ABI_ARM, + .page_shift = PAGE_SHIFT_ARM, + .sizeof_pfn = 8, + .alloc_magic_pages = alloc_magic_pages, + .count_pgtables = count_pgtables_arm, + .setup_pgtables = setup_pgtables_arm, + .start_info = start_info_arm, + .shared_info = shared_info_arm, + .vcpu = vcpu_arm, +}; + +static void __init register_arch_hooks(void) +{ + xc_dom_register_arch_hooks(&xc_dom_32); +} + int arch_setup_meminit(struct xc_dom_image *dom) { - errno = ENOSYS; - return -1; + int rc; + xen_pfn_t pfn, allocsz, i; + + dom->shadow_enabled = 1; + + dom->p2m_host = xc_dom_malloc(dom, sizeof(xen_pfn_t) * dom->total_pages); + + /* setup initial p2m */ + for ( pfn = 0; pfn < dom->total_pages; pfn++ ) + dom->p2m_host[pfn] = pfn + dom->rambase_pfn; + + /* allocate guest memory */ + for ( i = rc = allocsz = 0; + (i < dom->total_pages) && !rc; + i += allocsz ) + { + allocsz = dom->total_pages - i; + if ( allocsz > 1024*1024 ) + allocsz = 1024*1024; + + rc = xc_domain_populate_physmap_exact( + dom->xch, dom->guest_domid, allocsz, + 0, 0, &dom->p2m_host[i]); + } + + return 0; } int arch_setup_bootearly(struct xc_dom_image *dom) @@ -36,9 +165,14 @@ int arch_setup_bootearly(struct xc_dom_image *dom) int arch_setup_bootlate(struct xc_dom_image *dom) { - DOMPRINTF("%s: doing nothing", __FUNCTION__); + /* XXX + * map shared info + * map grant tables + * setup shared info + */ return 0; } + /* * Local variables: * mode: C diff --git a/tools/libxc/xc_dom_armzimageloader.c b/tools/libxc/xc_dom_armzimageloader.c new file mode 100644 index 0000000..f316e87 --- /dev/null +++ b/tools/libxc/xc_dom_armzimageloader.c @@ -0,0 +1,174 @@ +/* + * Xen domain builder -- ARM zImage bits + * + * Parse and load ARM zImage kernel images. + * + * Copyright (C) 2012, Citrix Systems. + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; + * version 2.1 of the License. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + * + */ + +#include +#include +#include + +#include "xg_private.h" +#include "xc_dom.h" + +#include /* XXX ntohl is not the right function... */ + +/* + * Guest virtual RAM starts here. This must be consistent with the DTB + * appended to the guest kernel. + */ +#define GUEST_RAM_BASE 0x80000000 + +#define ZIMAGE_MAGIC_OFFSET 0x24 +#define ZIMAGE_START_OFFSET 0x28 +#define ZIMAGE_END_OFFSET 0x2c + +#define ZIMAGE_MAGIC 0x016f2818 + +struct minimal_dtb_header { + uint32_t magic; + uint32_t total_size; + /* There are other fields but we don't use them yet. */ +}; + +#define DTB_MAGIC 0xd00dfeed + +static int xc_dom_probe_zimage_kernel(struct xc_dom_image *dom) +{ + uint32_t *zimage; + uint32_t end; + + if ( dom->kernel_blob == NULL ) + { + xc_dom_panic(dom->xch, XC_INTERNAL_ERROR, + "%s: no kernel image loaded", __FUNCTION__); + return -EINVAL; + } + + if ( dom->kernel_size < 0x30 /*sizeof(struct setup_header)*/ ) + { + xc_dom_printf(dom->xch, "%s: kernel image too small", __FUNCTION__); + return -EINVAL; + } + + zimage = (uint32_t *)dom->kernel_blob; + if ( zimage[ZIMAGE_MAGIC_OFFSET/4] != ZIMAGE_MAGIC ) + { + xc_dom_printf(dom->xch, "%s: kernel is not a bzImage", __FUNCTION__); + return -EINVAL; + } + + end = zimage[ZIMAGE_END_OFFSET/4]; + + /* + * Check for an appended DTB. + */ + if ( end + sizeof(struct minimal_dtb_header) < dom->kernel_size ) { + struct minimal_dtb_header *dtb_hdr; + dtb_hdr = (struct minimal_dtb_header *)(dom->kernel_blob + end); + if (ntohl/*be32_to_cpu*/(dtb_hdr->magic) == DTB_MAGIC) { + xc_dom_printf(dom->xch, "%s: found an appended DTB", __FUNCTION__); + end += ntohl/*be32_to_cpu*/(dtb_hdr->total_size); + } + } + + dom->kernel_size = end; + + return 0; +} + +static int xc_dom_parse_zimage_kernel(struct xc_dom_image *dom) +{ + uint32_t *zimage; + uint32_t start, entry_addr; + uint64_t v_start, v_end; + uint64_t rambase = GUEST_RAM_BASE; + + DOMPRINTF_CALLED(dom->xch); + + zimage = (uint32_t *)dom->kernel_blob; + + dom->rambase_pfn = rambase >> XC_PAGE_SHIFT; + + /* Do not load kernel at the very first RAM address */ + v_start = rambase + 0x8000; + v_end = v_start + dom->kernel_size; + + start = zimage[ZIMAGE_START_OFFSET/4]; + + if (start == 0) + entry_addr = v_start; + else + entry_addr = start; + + /* find kernel segment */ + dom->kernel_seg.vstart = v_start; + dom->kernel_seg.vend = v_end; + + dom->parms.virt_entry = entry_addr; + + dom->guest_type = "xen-3.0-armv7l"; + DOMPRINTF("%s: %s: RAM starts at %"PRI_xen_pfn, + __FUNCTION__, dom->guest_type, dom->rambase_pfn); + DOMPRINTF("%s: %s: 0x%" PRIx64 " -> 0x%" PRIx64 "", + __FUNCTION__, dom->guest_type, + dom->kernel_seg.vstart, dom->kernel_seg.vend); + return 0; +} + +static int xc_dom_load_zimage_kernel(struct xc_dom_image *dom) +{ + void *dst; + + DOMPRINTF_CALLED(dom->xch); + + dst = xc_dom_seg_to_ptr(dom, &dom->kernel_seg); + + DOMPRINTF("%s: kernel sed %#"PRIx64"-%#"PRIx64, + __func__, dom->kernel_seg.vstart, dom->kernel_seg.vend); + DOMPRINTF("%s: copy %zd bytes from blob %p to dst %p", + __func__, dom->kernel_size, dom->kernel_blob, dst); + + memcpy(dst, dom->kernel_blob, dom->kernel_size); + + return 0; +} + +static struct xc_dom_loader zimage_loader = { + .name = "Linux zImage (ARM)", + .probe = xc_dom_probe_zimage_kernel, + .parser = xc_dom_parse_zimage_kernel, + .loader = xc_dom_load_zimage_kernel, +}; + +static void __init register_loader(void) +{ + xc_dom_register_loader(&zimage_loader); +} + +/* + * Local variables: + * mode: C + * c-set-style: "BSD" + * c-basic-offset: 4 + * tab-width: 4 + * indent-tabs-mode: nil + * End: + */ diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c index fea9de5..5244b04 100644 --- a/tools/libxc/xc_dom_core.c +++ b/tools/libxc/xc_dom_core.c @@ -307,15 +307,17 @@ void *xc_dom_pfn_to_ptr(struct xc_dom_image *dom, xen_pfn_t pfn, xen_pfn_t count) { struct xc_dom_phys *phys; + xen_pfn_t offset; unsigned int page_shift = XC_DOM_PAGE_SHIFT(dom); char *mode = "unset"; - if ( pfn > dom->total_pages || /* multiple checks to avoid overflows */ + offset = pfn - dom->rambase_pfn; + if ( offset > dom->total_pages || /* multiple checks to avoid overflows */ count > dom->total_pages || - pfn > dom->total_pages - count ) + offset > dom->total_pages - count ) { - DOMPRINTF("%s: pfn out of range (0x%" PRIpfn " > 0x%" PRIpfn ")", - __FUNCTION__, pfn, dom->total_pages); + DOMPRINTF("%s: pfn %"PRI_xen_pfn" out of range (0x%" PRIpfn " > 0x%" PRIpfn ")", + __FUNCTION__, pfn, offset, dom->total_pages); return NULL; } diff --git a/tools/libxc/xg_private.h b/tools/libxc/xg_private.h index a29fa26..a271942 100644 --- a/tools/libxc/xg_private.h +++ b/tools/libxc/xg_private.h @@ -148,6 +148,10 @@ typedef l4_pgentry_64_t l4_pgentry_t; #define l4_table_offset(_a) l4_table_offset_x86_64(_a) #endif +#define PAGE_SHIFT_ARM 12 +#define PAGE_SIZE_ARM (1UL << PAGE_SHIFT_ARM) +#define PAGE_MASK_ARM (~(PAGE_SIZE_ARM-1)) + #define PAGE_SHIFT_X86 12 #define PAGE_SIZE_X86 (1UL << PAGE_SHIFT_X86) #define PAGE_MASK_X86 (~(PAGE_SIZE_X86-1)) -- 1.7.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 10:38:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 10:38:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5Ij-0001PP-Ez; Fri, 05 Oct 2012 10:38:37 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5Ih-0001Ol-1N for xen-devel@lists.xen.org; Fri, 05 Oct 2012 10:38:35 +0000 Received: from [85.158.143.35:44496] by server-2.bemta-4.messagelabs.com id 81/B2-06610-AA8BE605; Fri, 05 Oct 2012 10:38:34 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1349433509!14025963!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODA1MjM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16209 invoked from network); 5 Oct 2012 10:38:31 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 10:38:31 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="210396441" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 10:38:28 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 06:38:28 -0400 Received: from [10.80.246.74] (helo=army.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK5Ia-0003Rm-6V; Fri, 05 Oct 2012 11:38:28 +0100 From: Ian Campbell To: Date: Fri, 5 Oct 2012 10:38:08 +0000 Message-ID: <1349433507-21148-2-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.9.1 In-Reply-To: <1349433418.20946.46.camel@zakaz.uk.xensource.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: tim@xen.org, Ian Campbell , stefano.stabelini@citrix.com Subject: [Xen-devel] [PATCH 02/21] libxc: add ARM support to xc_dom (PV domain building) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Includes ARM zImage support. Signed-off-by: Ian Campbell --- tools/libxc/Makefile | 1 + tools/libxc/xc_dom.h | 20 ++++- tools/libxc/xc_dom_arm.c | 140 ++++++++++++++++++++++++++- tools/libxc/xc_dom_armzimageloader.c | 174 ++++++++++++++++++++++++++++++++++ tools/libxc/xc_dom_core.c | 10 +- tools/libxc/xg_private.h | 4 + 6 files changed, 339 insertions(+), 10 deletions(-) create mode 100644 tools/libxc/xc_dom_armzimageloader.c diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile index 441ba4d..d44abf9 100644 --- a/tools/libxc/Makefile +++ b/tools/libxc/Makefile @@ -58,6 +58,7 @@ GUEST_SRCS-y += libelf-dominfo.c libelf-relocate.c GUEST_SRCS-y += xc_dom_core.c xc_dom_boot.c GUEST_SRCS-y += xc_dom_elfloader.c GUEST_SRCS-$(CONFIG_X86) += xc_dom_bzimageloader.c +GUEST_SRCS-$(CONFIG_ARM) += xc_dom_armzimageloader.c GUEST_SRCS-y += xc_dom_binloader.c GUEST_SRCS-y += xc_dom_compat_linux.c diff --git a/tools/libxc/xc_dom.h b/tools/libxc/xc_dom.h index 2aef64a..3cd6dae 100644 --- a/tools/libxc/xc_dom.h +++ b/tools/libxc/xc_dom.h @@ -89,10 +89,24 @@ struct xc_dom_image { /* other state info */ uint32_t f_active[XENFEAT_NR_SUBMAPS]; + /* + * p2m_host maps guest physical addresses an offset from + * rambase_pfn (see below) into gfns. + * + * For a pure PV guest this means that it maps GPFNs into MFNs for + * a hybrid guest this means that it maps GPFNs to GPFNS. + * + * Note that the input is offset by rambase. + */ xen_pfn_t *p2m_host; void *p2m_guest; - /* physical memory */ + /* physical memory + * + * A PV guest has a single contiguous block of physical RAM, + * consisting of total_pages starting at rambase_pfn. + */ + xen_pfn_t rambase_pfn; xen_pfn_t total_pages; struct xc_dom_phys *phys_pages; int realmodearea_log; @@ -286,7 +300,7 @@ static inline xen_pfn_t xc_dom_p2m_host(struct xc_dom_image *dom, xen_pfn_t pfn) { if (dom->shadow_enabled) return pfn; - return dom->p2m_host[pfn]; + return dom->p2m_host[pfn - dom->rambase_pfn]; } static inline xen_pfn_t xc_dom_p2m_guest(struct xc_dom_image *dom, @@ -294,7 +308,7 @@ static inline xen_pfn_t xc_dom_p2m_guest(struct xc_dom_image *dom, { if (xc_dom_feature_translated(dom)) return pfn; - return dom->p2m_host[pfn]; + return dom->p2m_host[pfn - dom->rambase_pfn]; } /* --- arch bits --------------------------------------------------- */ diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c index 122d0e8..3eef0d0 100644 --- a/tools/libxc/xc_dom_arm.c +++ b/tools/libxc/xc_dom_arm.c @@ -18,14 +18,143 @@ * Copyright (c) 2011, Citrix Systems */ #include + #include +#include + #include "xg_private.h" #include "xc_dom.h" +/* ------------------------------------------------------------------------ */ +/* + * arm guests are hybrid and start off with paging disabled, therefore no + * pagetables and nothing to do here. + */ +static int count_pgtables_arm(struct xc_dom_image *dom) +{ + DOMPRINTF_CALLED(dom->xch); + return 0; +} + +static int setup_pgtables_arm(struct xc_dom_image *dom) +{ + DOMPRINTF_CALLED(dom->xch); + return 0; +} + +/* ------------------------------------------------------------------------ */ + +static int alloc_magic_pages(struct xc_dom_image *dom) +{ + DOMPRINTF_CALLED(dom->xch); + /* XXX + * dom->p2m_guest + * dom->start_info_pfn + * dom->xenstore_pfn + * dom->console_pfn + */ + return 0; +} + +/* ------------------------------------------------------------------------ */ + +static int start_info_arm(struct xc_dom_image *dom) +{ + DOMPRINTF_CALLED(dom->xch); + return 0; +} + +static int shared_info_arm(struct xc_dom_image *dom, void *ptr) +{ + DOMPRINTF_CALLED(dom->xch); + return 0; +} + +/* ------------------------------------------------------------------------ */ + +static int vcpu_arm(struct xc_dom_image *dom, void *ptr) +{ + vcpu_guest_context_t *ctxt = ptr; + + DOMPRINTF_CALLED(dom->xch); + + /* clear everything */ + memset(ctxt, 0, sizeof(*ctxt)); + + ctxt->user_regs.pc = dom->parms.virt_entry; + + /* Linux boot protocol. See linux.Documentation/arm/Booting. */ + ctxt->user_regs.r0 = 0; /* SBZ */ + /* Machine ID: We use DTB therefore no machine id */ + ctxt->user_regs.r1 = 0xffffffff; + /* ATAGS/DTB: We currently require that the guest kernel to be + * using CONFIG_ARM_APPENDED_DTB. Ensure that r2 does not look + * like a valid pointer to a set of ATAGS or a DTB. + */ + ctxt->user_regs.r2 = 0xffffffff; + + ctxt->sctlr = /* #define SCTLR_BASE */0x00c50078; + + ctxt->ttbr0 = 0; + ctxt->ttbr1 = 0; + ctxt->ttbcr = 0; /* Defined Reset Value */ + + ctxt->user_regs.cpsr = PSR_ABT_MASK|PSR_FIQ_MASK|PSR_IRQ_MASK|PSR_MODE_SVC; + + DOMPRINTF("Initial state CPSR %#"PRIx32" PC %#"PRIx32, + ctxt->user_regs.cpsr, ctxt->user_regs.pc); + + return 0; +} + +/* ------------------------------------------------------------------------ */ + +static struct xc_dom_arch xc_dom_32 = { + .guest_type = "xen-3.0-armv7l", + .native_protocol = XEN_IO_PROTO_ABI_ARM, + .page_shift = PAGE_SHIFT_ARM, + .sizeof_pfn = 8, + .alloc_magic_pages = alloc_magic_pages, + .count_pgtables = count_pgtables_arm, + .setup_pgtables = setup_pgtables_arm, + .start_info = start_info_arm, + .shared_info = shared_info_arm, + .vcpu = vcpu_arm, +}; + +static void __init register_arch_hooks(void) +{ + xc_dom_register_arch_hooks(&xc_dom_32); +} + int arch_setup_meminit(struct xc_dom_image *dom) { - errno = ENOSYS; - return -1; + int rc; + xen_pfn_t pfn, allocsz, i; + + dom->shadow_enabled = 1; + + dom->p2m_host = xc_dom_malloc(dom, sizeof(xen_pfn_t) * dom->total_pages); + + /* setup initial p2m */ + for ( pfn = 0; pfn < dom->total_pages; pfn++ ) + dom->p2m_host[pfn] = pfn + dom->rambase_pfn; + + /* allocate guest memory */ + for ( i = rc = allocsz = 0; + (i < dom->total_pages) && !rc; + i += allocsz ) + { + allocsz = dom->total_pages - i; + if ( allocsz > 1024*1024 ) + allocsz = 1024*1024; + + rc = xc_domain_populate_physmap_exact( + dom->xch, dom->guest_domid, allocsz, + 0, 0, &dom->p2m_host[i]); + } + + return 0; } int arch_setup_bootearly(struct xc_dom_image *dom) @@ -36,9 +165,14 @@ int arch_setup_bootearly(struct xc_dom_image *dom) int arch_setup_bootlate(struct xc_dom_image *dom) { - DOMPRINTF("%s: doing nothing", __FUNCTION__); + /* XXX + * map shared info + * map grant tables + * setup shared info + */ return 0; } + /* * Local variables: * mode: C diff --git a/tools/libxc/xc_dom_armzimageloader.c b/tools/libxc/xc_dom_armzimageloader.c new file mode 100644 index 0000000..f316e87 --- /dev/null +++ b/tools/libxc/xc_dom_armzimageloader.c @@ -0,0 +1,174 @@ +/* + * Xen domain builder -- ARM zImage bits + * + * Parse and load ARM zImage kernel images. + * + * Copyright (C) 2012, Citrix Systems. + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; + * version 2.1 of the License. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + * + */ + +#include +#include +#include + +#include "xg_private.h" +#include "xc_dom.h" + +#include /* XXX ntohl is not the right function... */ + +/* + * Guest virtual RAM starts here. This must be consistent with the DTB + * appended to the guest kernel. + */ +#define GUEST_RAM_BASE 0x80000000 + +#define ZIMAGE_MAGIC_OFFSET 0x24 +#define ZIMAGE_START_OFFSET 0x28 +#define ZIMAGE_END_OFFSET 0x2c + +#define ZIMAGE_MAGIC 0x016f2818 + +struct minimal_dtb_header { + uint32_t magic; + uint32_t total_size; + /* There are other fields but we don't use them yet. */ +}; + +#define DTB_MAGIC 0xd00dfeed + +static int xc_dom_probe_zimage_kernel(struct xc_dom_image *dom) +{ + uint32_t *zimage; + uint32_t end; + + if ( dom->kernel_blob == NULL ) + { + xc_dom_panic(dom->xch, XC_INTERNAL_ERROR, + "%s: no kernel image loaded", __FUNCTION__); + return -EINVAL; + } + + if ( dom->kernel_size < 0x30 /*sizeof(struct setup_header)*/ ) + { + xc_dom_printf(dom->xch, "%s: kernel image too small", __FUNCTION__); + return -EINVAL; + } + + zimage = (uint32_t *)dom->kernel_blob; + if ( zimage[ZIMAGE_MAGIC_OFFSET/4] != ZIMAGE_MAGIC ) + { + xc_dom_printf(dom->xch, "%s: kernel is not a bzImage", __FUNCTION__); + return -EINVAL; + } + + end = zimage[ZIMAGE_END_OFFSET/4]; + + /* + * Check for an appended DTB. + */ + if ( end + sizeof(struct minimal_dtb_header) < dom->kernel_size ) { + struct minimal_dtb_header *dtb_hdr; + dtb_hdr = (struct minimal_dtb_header *)(dom->kernel_blob + end); + if (ntohl/*be32_to_cpu*/(dtb_hdr->magic) == DTB_MAGIC) { + xc_dom_printf(dom->xch, "%s: found an appended DTB", __FUNCTION__); + end += ntohl/*be32_to_cpu*/(dtb_hdr->total_size); + } + } + + dom->kernel_size = end; + + return 0; +} + +static int xc_dom_parse_zimage_kernel(struct xc_dom_image *dom) +{ + uint32_t *zimage; + uint32_t start, entry_addr; + uint64_t v_start, v_end; + uint64_t rambase = GUEST_RAM_BASE; + + DOMPRINTF_CALLED(dom->xch); + + zimage = (uint32_t *)dom->kernel_blob; + + dom->rambase_pfn = rambase >> XC_PAGE_SHIFT; + + /* Do not load kernel at the very first RAM address */ + v_start = rambase + 0x8000; + v_end = v_start + dom->kernel_size; + + start = zimage[ZIMAGE_START_OFFSET/4]; + + if (start == 0) + entry_addr = v_start; + else + entry_addr = start; + + /* find kernel segment */ + dom->kernel_seg.vstart = v_start; + dom->kernel_seg.vend = v_end; + + dom->parms.virt_entry = entry_addr; + + dom->guest_type = "xen-3.0-armv7l"; + DOMPRINTF("%s: %s: RAM starts at %"PRI_xen_pfn, + __FUNCTION__, dom->guest_type, dom->rambase_pfn); + DOMPRINTF("%s: %s: 0x%" PRIx64 " -> 0x%" PRIx64 "", + __FUNCTION__, dom->guest_type, + dom->kernel_seg.vstart, dom->kernel_seg.vend); + return 0; +} + +static int xc_dom_load_zimage_kernel(struct xc_dom_image *dom) +{ + void *dst; + + DOMPRINTF_CALLED(dom->xch); + + dst = xc_dom_seg_to_ptr(dom, &dom->kernel_seg); + + DOMPRINTF("%s: kernel sed %#"PRIx64"-%#"PRIx64, + __func__, dom->kernel_seg.vstart, dom->kernel_seg.vend); + DOMPRINTF("%s: copy %zd bytes from blob %p to dst %p", + __func__, dom->kernel_size, dom->kernel_blob, dst); + + memcpy(dst, dom->kernel_blob, dom->kernel_size); + + return 0; +} + +static struct xc_dom_loader zimage_loader = { + .name = "Linux zImage (ARM)", + .probe = xc_dom_probe_zimage_kernel, + .parser = xc_dom_parse_zimage_kernel, + .loader = xc_dom_load_zimage_kernel, +}; + +static void __init register_loader(void) +{ + xc_dom_register_loader(&zimage_loader); +} + +/* + * Local variables: + * mode: C + * c-set-style: "BSD" + * c-basic-offset: 4 + * tab-width: 4 + * indent-tabs-mode: nil + * End: + */ diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c index fea9de5..5244b04 100644 --- a/tools/libxc/xc_dom_core.c +++ b/tools/libxc/xc_dom_core.c @@ -307,15 +307,17 @@ void *xc_dom_pfn_to_ptr(struct xc_dom_image *dom, xen_pfn_t pfn, xen_pfn_t count) { struct xc_dom_phys *phys; + xen_pfn_t offset; unsigned int page_shift = XC_DOM_PAGE_SHIFT(dom); char *mode = "unset"; - if ( pfn > dom->total_pages || /* multiple checks to avoid overflows */ + offset = pfn - dom->rambase_pfn; + if ( offset > dom->total_pages || /* multiple checks to avoid overflows */ count > dom->total_pages || - pfn > dom->total_pages - count ) + offset > dom->total_pages - count ) { - DOMPRINTF("%s: pfn out of range (0x%" PRIpfn " > 0x%" PRIpfn ")", - __FUNCTION__, pfn, dom->total_pages); + DOMPRINTF("%s: pfn %"PRI_xen_pfn" out of range (0x%" PRIpfn " > 0x%" PRIpfn ")", + __FUNCTION__, pfn, offset, dom->total_pages); return NULL; } diff --git a/tools/libxc/xg_private.h b/tools/libxc/xg_private.h index a29fa26..a271942 100644 --- a/tools/libxc/xg_private.h +++ b/tools/libxc/xg_private.h @@ -148,6 +148,10 @@ typedef l4_pgentry_64_t l4_pgentry_t; #define l4_table_offset(_a) l4_table_offset_x86_64(_a) #endif +#define PAGE_SHIFT_ARM 12 +#define PAGE_SIZE_ARM (1UL << PAGE_SHIFT_ARM) +#define PAGE_MASK_ARM (~(PAGE_SIZE_ARM-1)) + #define PAGE_SHIFT_X86 12 #define PAGE_SIZE_X86 (1UL << PAGE_SHIFT_X86) #define PAGE_MASK_X86 (~(PAGE_SIZE_X86-1)) -- 1.7.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 10:38:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 10:38:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5Ij-0001PH-1Y; Fri, 05 Oct 2012 10:38:37 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5Ig-0001Ob-R8 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 10:38:34 +0000 Received: from [85.158.139.211:44916] by server-9.bemta-5.messagelabs.com id 2B/CE-14846-AA8BE605; Fri, 05 Oct 2012 10:38:34 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-206.messagelabs.com!1349433511!21178219!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODA1MjM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14161 invoked from network); 5 Oct 2012 10:38:33 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 10:38:33 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="210396442" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 10:38:29 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 06:38:29 -0400 Received: from [10.80.246.74] (helo=army.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK5Ia-0003Rm-MH; Fri, 05 Oct 2012 11:38:28 +0100 From: Ian Campbell To: Date: Fri, 5 Oct 2012 10:38:14 +0000 Message-ID: <1349433507-21148-8-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.9.1 In-Reply-To: <1349433418.20946.46.camel@zakaz.uk.xensource.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: tim@xen.org, Ian Campbell , stefano.stabelini@citrix.com Subject: [Xen-devel] [PATCH 08/21] arm: kill a guest which uses hvc with an immediate operand != XEN_HYPERCALL_TAG X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org At best these guests are confused/broken and at worse they are malicious. In any case we don't know that they are expecting to handle a -errno style error. Signed-off-by: Ian Campbell --- xen/arch/arm/traps.c | 7 +------ 1 files changed, 1 insertions(+), 6 deletions(-) diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c index 8c818c2..19e2081 100644 --- a/xen/arch/arm/traps.c +++ b/xen/arch/arm/traps.c @@ -476,12 +476,7 @@ static void do_trap_hypercall(struct cpu_user_regs *regs, unsigned long iss) #endif if ( iss != XEN_HYPERCALL_TAG ) - { - printk("%s %d: received an alien hypercall iss=%lx\n", __func__ , - __LINE__ , iss); - regs->r0 = -EINVAL; - return; - } + domain_crash_synchronous(); if ( regs->r12 >= ARRAY_SIZE(arm_hypercall_table) ) { -- 1.7.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 10:38:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 10:38:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5Ij-0001PH-1Y; Fri, 05 Oct 2012 10:38:37 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5Ig-0001Ob-R8 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 10:38:34 +0000 Received: from [85.158.139.211:44916] by server-9.bemta-5.messagelabs.com id 2B/CE-14846-AA8BE605; Fri, 05 Oct 2012 10:38:34 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-206.messagelabs.com!1349433511!21178219!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODA1MjM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14161 invoked from network); 5 Oct 2012 10:38:33 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 10:38:33 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="210396442" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 10:38:29 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 06:38:29 -0400 Received: from [10.80.246.74] (helo=army.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK5Ia-0003Rm-MH; Fri, 05 Oct 2012 11:38:28 +0100 From: Ian Campbell To: Date: Fri, 5 Oct 2012 10:38:14 +0000 Message-ID: <1349433507-21148-8-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.9.1 In-Reply-To: <1349433418.20946.46.camel@zakaz.uk.xensource.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: tim@xen.org, Ian Campbell , stefano.stabelini@citrix.com Subject: [Xen-devel] [PATCH 08/21] arm: kill a guest which uses hvc with an immediate operand != XEN_HYPERCALL_TAG X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org At best these guests are confused/broken and at worse they are malicious. In any case we don't know that they are expecting to handle a -errno style error. Signed-off-by: Ian Campbell --- xen/arch/arm/traps.c | 7 +------ 1 files changed, 1 insertions(+), 6 deletions(-) diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c index 8c818c2..19e2081 100644 --- a/xen/arch/arm/traps.c +++ b/xen/arch/arm/traps.c @@ -476,12 +476,7 @@ static void do_trap_hypercall(struct cpu_user_regs *regs, unsigned long iss) #endif if ( iss != XEN_HYPERCALL_TAG ) - { - printk("%s %d: received an alien hypercall iss=%lx\n", __func__ , - __LINE__ , iss); - regs->r0 = -EINVAL; - return; - } + domain_crash_synchronous(); if ( regs->r12 >= ARRAY_SIZE(arm_hypercall_table) ) { -- 1.7.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 10:38:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 10:38:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5Ik-0001Pn-4Y; Fri, 05 Oct 2012 10:38:38 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5Ii-0001Ol-G0 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 10:38:36 +0000 Received: from [85.158.143.35:37262] by server-2.bemta-4.messagelabs.com id EB/B2-06610-CA8BE605; Fri, 05 Oct 2012 10:38:36 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1349433509!14025963!3 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODA1MjM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16364 invoked from network); 5 Oct 2012 10:38:33 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 10:38:33 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="210396443" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 10:38:29 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 06:38:29 -0400 Received: from [10.80.246.74] (helo=army.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK5Ia-0003Rm-Ib; Fri, 05 Oct 2012 11:38:28 +0100 From: Ian Campbell To: Date: Fri, 5 Oct 2012 10:38:13 +0000 Message-ID: <1349433507-21148-7-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.9.1 In-Reply-To: <1349433418.20946.46.camel@zakaz.uk.xensource.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Stefano Stabellini , tim@xen.org, stefano.stabelini@citrix.com Subject: [Xen-devel] [PATCH 07/21] xen/arm: grant table X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Stefano Stabellini Implement XENMAPSPACE_grant_table and grant_table_op. Signed-off-by: Stefano Stabellini Acked-by: Tim Deegan [ ijc -- fixed reject in traps.c, grant table op is a 3 argument hypercall, rebased over "xen: arm: implement XENMEM_add_to_physmap_range" ] --- xen/arch/arm/mm.c | 26 ++++++++++++++++++++++++++ xen/arch/arm/traps.c | 1 + 2 files changed, 27 insertions(+), 0 deletions(-) diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c index 478984f..bf9b6c5 100644 --- a/xen/arch/arm/mm.c +++ b/xen/arch/arm/mm.c @@ -25,6 +25,7 @@ #include #include #include +#include #include #include #include @@ -475,6 +476,31 @@ static int xenmem_add_to_physmap_one( switch ( space ) { + case XENMAPSPACE_grant_table: + spin_lock(&d->grant_table->lock); + + if ( d->grant_table->gt_version == 0 ) + d->grant_table->gt_version = 1; + + if ( d->grant_table->gt_version == 2 && + (idx & XENMAPIDX_grant_table_status) ) + { + idx &= ~XENMAPIDX_grant_table_status; + if ( idx < nr_status_frames(d->grant_table) ) + mfn = virt_to_mfn(d->grant_table->status[idx]); + } + else + { + if ( (idx >= nr_grant_frames(d->grant_table)) && + (idx < max_nr_grant_frames) ) + gnttab_grow_table(d, idx + 1); + + if ( idx < nr_grant_frames(d->grant_table) ) + mfn = virt_to_mfn(d->grant_table->shared_raw[idx]); + } + + spin_unlock(&d->grant_table->lock); + break; case XENMAPSPACE_shared_info: if ( idx == 0 ) mfn = virt_to_mfn(d->shared_info); diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c index e4bed69..8c818c2 100644 --- a/xen/arch/arm/traps.c +++ b/xen/arch/arm/traps.c @@ -438,6 +438,7 @@ static arm_hypercall_t arm_hypercall_table[] = { HYPERCALL(physdev_op, 2), HYPERCALL(sysctl, 2), HYPERCALL(hvm_op, 2), + HYPERCALL(grant_table_op, 3), }; static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code) -- 1.7.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 10:38:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 10:38:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5Ik-0001Pn-4Y; Fri, 05 Oct 2012 10:38:38 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5Ii-0001Ol-G0 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 10:38:36 +0000 Received: from [85.158.143.35:37262] by server-2.bemta-4.messagelabs.com id EB/B2-06610-CA8BE605; Fri, 05 Oct 2012 10:38:36 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1349433509!14025963!3 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODA1MjM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16364 invoked from network); 5 Oct 2012 10:38:33 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 10:38:33 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="210396443" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 10:38:29 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 06:38:29 -0400 Received: from [10.80.246.74] (helo=army.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK5Ia-0003Rm-Ib; Fri, 05 Oct 2012 11:38:28 +0100 From: Ian Campbell To: Date: Fri, 5 Oct 2012 10:38:13 +0000 Message-ID: <1349433507-21148-7-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.9.1 In-Reply-To: <1349433418.20946.46.camel@zakaz.uk.xensource.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Stefano Stabellini , tim@xen.org, stefano.stabelini@citrix.com Subject: [Xen-devel] [PATCH 07/21] xen/arm: grant table X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Stefano Stabellini Implement XENMAPSPACE_grant_table and grant_table_op. Signed-off-by: Stefano Stabellini Acked-by: Tim Deegan [ ijc -- fixed reject in traps.c, grant table op is a 3 argument hypercall, rebased over "xen: arm: implement XENMEM_add_to_physmap_range" ] --- xen/arch/arm/mm.c | 26 ++++++++++++++++++++++++++ xen/arch/arm/traps.c | 1 + 2 files changed, 27 insertions(+), 0 deletions(-) diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c index 478984f..bf9b6c5 100644 --- a/xen/arch/arm/mm.c +++ b/xen/arch/arm/mm.c @@ -25,6 +25,7 @@ #include #include #include +#include #include #include #include @@ -475,6 +476,31 @@ static int xenmem_add_to_physmap_one( switch ( space ) { + case XENMAPSPACE_grant_table: + spin_lock(&d->grant_table->lock); + + if ( d->grant_table->gt_version == 0 ) + d->grant_table->gt_version = 1; + + if ( d->grant_table->gt_version == 2 && + (idx & XENMAPIDX_grant_table_status) ) + { + idx &= ~XENMAPIDX_grant_table_status; + if ( idx < nr_status_frames(d->grant_table) ) + mfn = virt_to_mfn(d->grant_table->status[idx]); + } + else + { + if ( (idx >= nr_grant_frames(d->grant_table)) && + (idx < max_nr_grant_frames) ) + gnttab_grow_table(d, idx + 1); + + if ( idx < nr_grant_frames(d->grant_table) ) + mfn = virt_to_mfn(d->grant_table->shared_raw[idx]); + } + + spin_unlock(&d->grant_table->lock); + break; case XENMAPSPACE_shared_info: if ( idx == 0 ) mfn = virt_to_mfn(d->shared_info); diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c index e4bed69..8c818c2 100644 --- a/xen/arch/arm/traps.c +++ b/xen/arch/arm/traps.c @@ -438,6 +438,7 @@ static arm_hypercall_t arm_hypercall_table[] = { HYPERCALL(physdev_op, 2), HYPERCALL(sysctl, 2), HYPERCALL(hvm_op, 2), + HYPERCALL(grant_table_op, 3), }; static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code) -- 1.7.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 10:39:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 10:39:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5Iz-0001W7-J7; Fri, 05 Oct 2012 10:38:53 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5Ix-0001Ty-NO for xen-devel@lists.xen.org; Fri, 05 Oct 2012 10:38:51 +0000 Received: from [85.158.143.99:4575] by server-1.bemta-4.messagelabs.com id 4A/F5-05684-BB8BE605; Fri, 05 Oct 2012 10:38:51 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1349433529!32967422!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ1ODc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31341 invoked from network); 5 Oct 2012 10:38:50 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 10:38:50 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="40248712" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 10:38:29 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 06:38:28 -0400 Received: from [10.80.246.74] (helo=army.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK5Ia-0003Rm-Dp; Fri, 05 Oct 2012 11:38:28 +0100 From: Ian Campbell To: Date: Fri, 5 Oct 2012 10:38:11 +0000 Message-ID: <1349433507-21148-5-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.9.1 In-Reply-To: <1349433418.20946.46.camel@zakaz.uk.xensource.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Stefano Stabellini , tim@xen.org, stefano.stabelini@citrix.com Subject: [Xen-devel] [PATCH 05/21] xen/arm: implement get/put_page_type X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Stefano Stabellini Add a basic get_page_type and put_page_type implementation: we don't care about typecounts so just return success. Also remove PGT_shared_page, that is unused. Signed-off-by: Stefano Stabellini Acked-by: Ian Campbell --- xen/arch/arm/dummy.S | 4 ---- xen/arch/arm/mm.c | 13 +++++++++++++ xen/include/asm-arm/mm.h | 1 - 3 files changed, 13 insertions(+), 5 deletions(-) diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S index aaf1ff1..022338a 100644 --- a/xen/arch/arm/dummy.S +++ b/xen/arch/arm/dummy.S @@ -22,10 +22,6 @@ DUMMY(arch_get_info_guest); DUMMY(arch_vcpu_reset); NOP(update_vcpu_system_time); -/* Page Reference & Type Maintenance */ -DUMMY(get_page_type); -DUMMY(put_page_type); - /* Grant Tables */ DUMMY(steal_page); diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c index 8191c90..478984f 100644 --- a/xen/arch/arm/mm.c +++ b/xen/arch/arm/mm.c @@ -666,6 +666,19 @@ int get_page(struct page_info *page, struct domain *domain) return 0; } +/* Common code requires get_page_type and put_page_type. + * We don't care about typecounts so we just do the minimum to make it + * happy. */ +int get_page_type(struct page_info *page, unsigned long type) +{ + return 1; +} + +void put_page_type(struct page_info *page) +{ + return; +} + void gnttab_clear_flag(unsigned long nr, uint16_t *addr) { /* diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h index 53801b0..b37bd35 100644 --- a/xen/include/asm-arm/mm.h +++ b/xen/include/asm-arm/mm.h @@ -71,7 +71,6 @@ struct page_info #define PGT_none PG_mask(0, 4) /* no special uses of this page */ #define PGT_writable_page PG_mask(7, 4) /* has writable mappings? */ -#define PGT_shared_page PG_mask(8, 4) /* CoW sharable page */ #define PGT_type_mask PG_mask(15, 4) /* Bits 28-31 or 60-63. */ /* Owning guest has pinned this page to its current type? */ -- 1.7.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 10:39:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 10:39:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5Iz-0001W7-J7; Fri, 05 Oct 2012 10:38:53 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5Ix-0001Ty-NO for xen-devel@lists.xen.org; Fri, 05 Oct 2012 10:38:51 +0000 Received: from [85.158.143.99:4575] by server-1.bemta-4.messagelabs.com id 4A/F5-05684-BB8BE605; Fri, 05 Oct 2012 10:38:51 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1349433529!32967422!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ1ODc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31341 invoked from network); 5 Oct 2012 10:38:50 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 10:38:50 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="40248712" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 10:38:29 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 06:38:28 -0400 Received: from [10.80.246.74] (helo=army.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK5Ia-0003Rm-Dp; Fri, 05 Oct 2012 11:38:28 +0100 From: Ian Campbell To: Date: Fri, 5 Oct 2012 10:38:11 +0000 Message-ID: <1349433507-21148-5-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.9.1 In-Reply-To: <1349433418.20946.46.camel@zakaz.uk.xensource.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Stefano Stabellini , tim@xen.org, stefano.stabelini@citrix.com Subject: [Xen-devel] [PATCH 05/21] xen/arm: implement get/put_page_type X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Stefano Stabellini Add a basic get_page_type and put_page_type implementation: we don't care about typecounts so just return success. Also remove PGT_shared_page, that is unused. Signed-off-by: Stefano Stabellini Acked-by: Ian Campbell --- xen/arch/arm/dummy.S | 4 ---- xen/arch/arm/mm.c | 13 +++++++++++++ xen/include/asm-arm/mm.h | 1 - 3 files changed, 13 insertions(+), 5 deletions(-) diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S index aaf1ff1..022338a 100644 --- a/xen/arch/arm/dummy.S +++ b/xen/arch/arm/dummy.S @@ -22,10 +22,6 @@ DUMMY(arch_get_info_guest); DUMMY(arch_vcpu_reset); NOP(update_vcpu_system_time); -/* Page Reference & Type Maintenance */ -DUMMY(get_page_type); -DUMMY(put_page_type); - /* Grant Tables */ DUMMY(steal_page); diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c index 8191c90..478984f 100644 --- a/xen/arch/arm/mm.c +++ b/xen/arch/arm/mm.c @@ -666,6 +666,19 @@ int get_page(struct page_info *page, struct domain *domain) return 0; } +/* Common code requires get_page_type and put_page_type. + * We don't care about typecounts so we just do the minimum to make it + * happy. */ +int get_page_type(struct page_info *page, unsigned long type) +{ + return 1; +} + +void put_page_type(struct page_info *page) +{ + return; +} + void gnttab_clear_flag(unsigned long nr, uint16_t *addr) { /* diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h index 53801b0..b37bd35 100644 --- a/xen/include/asm-arm/mm.h +++ b/xen/include/asm-arm/mm.h @@ -71,7 +71,6 @@ struct page_info #define PGT_none PG_mask(0, 4) /* no special uses of this page */ #define PGT_writable_page PG_mask(7, 4) /* has writable mappings? */ -#define PGT_shared_page PG_mask(8, 4) /* CoW sharable page */ #define PGT_type_mask PG_mask(15, 4) /* Bits 28-31 or 60-63. */ /* Owning guest has pinned this page to its current type? */ -- 1.7.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 10:39:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 10:39:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5J1-0001Xf-29; Fri, 05 Oct 2012 10:38:55 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5Iz-0001Ty-FU for xen-devel@lists.xen.org; Fri, 05 Oct 2012 10:38:53 +0000 Received: from [85.158.143.99:18725] by server-1.bemta-4.messagelabs.com id 19/06-05684-DB8BE605; Fri, 05 Oct 2012 10:38:53 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1349433529!32967422!4 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ1ODc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31476 invoked from network); 5 Oct 2012 10:38:52 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 10:38:52 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="40248714" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 10:38:29 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 06:38:28 -0400 Received: from [10.80.246.74] (helo=army.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK5Ia-0003Rm-GB; Fri, 05 Oct 2012 11:38:28 +0100 From: Ian Campbell To: Date: Fri, 5 Oct 2012 10:38:12 +0000 Message-ID: <1349433507-21148-6-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.9.1 In-Reply-To: <1349433418.20946.46.camel@zakaz.uk.xensource.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Stefano Stabellini , tim@xen.org, stefano.stabelini@citrix.com Subject: [Xen-devel] [PATCH 06/21] xen/arm: create_p2m_entries should not call free_domheap_page X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Stefano Stabellini The guest is entitled to leak a page from its p2m (by overwriting it) if it wants to. Since the memory is effectively lost to it (can't even be recovered by XENMEM increase reservation etc). In these cases we shouldn't call free_domheap_page to free the existing page from create_p2m_entries, because it resets the reference counting but the page is still allocated to the guest (even if not in the p2m anymore) and common grant_table code is also going to call put_page on it. Signed-off-by: Stefano Stabellini Acked-by: Ian Campbell --- xen/arch/arm/p2m.c | 5 ----- 1 files changed, 0 insertions(+), 5 deletions(-) diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c index 7c23b7d..7ae4515 100644 --- a/xen/arch/arm/p2m.c +++ b/xen/arch/arm/p2m.c @@ -189,12 +189,7 @@ static int create_p2m_entries(struct domain *d, /* else: third already valid */ if ( third[third_table_offset(addr)].p2m.valid ) - { - /* p2m entry already present */ - free_domheap_page( - mfn_to_page(third[third_table_offset(addr)].p2m.base)); flush_tlb_all_local(); - } /* Allocate a new RAM page and attach */ switch (op) { -- 1.7.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 10:39:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 10:39:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5J1-0001Xf-29; Fri, 05 Oct 2012 10:38:55 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5Iz-0001Ty-FU for xen-devel@lists.xen.org; Fri, 05 Oct 2012 10:38:53 +0000 Received: from [85.158.143.99:18725] by server-1.bemta-4.messagelabs.com id 19/06-05684-DB8BE605; Fri, 05 Oct 2012 10:38:53 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1349433529!32967422!4 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ1ODc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31476 invoked from network); 5 Oct 2012 10:38:52 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 10:38:52 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="40248714" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 10:38:29 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 06:38:28 -0400 Received: from [10.80.246.74] (helo=army.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK5Ia-0003Rm-GB; Fri, 05 Oct 2012 11:38:28 +0100 From: Ian Campbell To: Date: Fri, 5 Oct 2012 10:38:12 +0000 Message-ID: <1349433507-21148-6-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.9.1 In-Reply-To: <1349433418.20946.46.camel@zakaz.uk.xensource.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Stefano Stabellini , tim@xen.org, stefano.stabelini@citrix.com Subject: [Xen-devel] [PATCH 06/21] xen/arm: create_p2m_entries should not call free_domheap_page X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Stefano Stabellini The guest is entitled to leak a page from its p2m (by overwriting it) if it wants to. Since the memory is effectively lost to it (can't even be recovered by XENMEM increase reservation etc). In these cases we shouldn't call free_domheap_page to free the existing page from create_p2m_entries, because it resets the reference counting but the page is still allocated to the guest (even if not in the p2m anymore) and common grant_table code is also going to call put_page on it. Signed-off-by: Stefano Stabellini Acked-by: Ian Campbell --- xen/arch/arm/p2m.c | 5 ----- 1 files changed, 0 insertions(+), 5 deletions(-) diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c index 7c23b7d..7ae4515 100644 --- a/xen/arch/arm/p2m.c +++ b/xen/arch/arm/p2m.c @@ -189,12 +189,7 @@ static int create_p2m_entries(struct domain *d, /* else: third already valid */ if ( third[third_table_offset(addr)].p2m.valid ) - { - /* p2m entry already present */ - free_domheap_page( - mfn_to_page(third[third_table_offset(addr)].p2m.base)); flush_tlb_all_local(); - } /* Allocate a new RAM page and attach */ switch (op) { -- 1.7.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 10:39:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 10:39:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5J0-0001XI-Lq; Fri, 05 Oct 2012 10:38:54 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5Iy-0001Ty-UD for xen-devel@lists.xen.org; Fri, 05 Oct 2012 10:38:53 +0000 Received: from [85.158.143.99:18701] by server-1.bemta-4.messagelabs.com id 24/06-05684-CB8BE605; Fri, 05 Oct 2012 10:38:52 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1349433529!32967422!3 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ1ODc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31444 invoked from network); 5 Oct 2012 10:38:51 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 10:38:51 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="40248715" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 10:38:29 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 06:38:29 -0400 Received: from [10.80.246.74] (helo=army.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK5Ia-0003Rm-SC; Fri, 05 Oct 2012 11:38:28 +0100 From: Ian Campbell To: Date: Fri, 5 Oct 2012 10:38:16 +0000 Message-ID: <1349433507-21148-10-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.9.1 In-Reply-To: <1349433418.20946.46.camel@zakaz.uk.xensource.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: tim@xen.org, Ian Campbell , stefano.stabelini@citrix.com Subject: [Xen-devel] [PATCH 10/21] arm: disable distributor delivery on boot CPU only X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org The secondary processors do not call enter_hyp_mode until the boot CPU has brought most of the system up, including enabling delivery via the distributor. This means that bringing up secondary CPUs unexpectedly disables the GICD again, meaning we get no further interrupts on any CPU. For completeness also disable the GICC (CPU interface) on all CPUs too. Signed-off-by: Ian Campbell Acked-by: Tim Deegan --- xen/arch/arm/mode_switch.S | 23 +++++++++++++++++------ 1 files changed, 17 insertions(+), 6 deletions(-) diff --git a/xen/arch/arm/mode_switch.S b/xen/arch/arm/mode_switch.S index f5549d7..83a682b 100644 --- a/xen/arch/arm/mode_switch.S +++ b/xen/arch/arm/mode_switch.S @@ -23,6 +23,8 @@ /* Get up a CPU into Hyp mode. Clobbers r0-r3. * + * Expects r12 == CPU number + * * This code is specific to the VE model, and not intended to be used * on production systems. As such it's a bit hackier than the main * boot code in head.S. In future it will be replaced by better @@ -46,19 +48,28 @@ enter_hyp_mode: mcr CP32(r0, CNTFRQ) ldr r0, =0x40c00 /* SMP, c11, c10 in non-secure mode */ mcr CP32(r0, NSACR) - /* Continuing ugliness: Set up the GIC so NS state owns interrupts */ mov r0, #GIC_BASE_ADDRESS add r0, r0, #GIC_DR_OFFSET + /* Disable the GIC distributor, on the boot CPU only */ mov r1, #0 - str r1, [r0] /* Disable delivery in the distributor */ + teq r12, #0 /* Is this the boot CPU? */ + streq r1, [r0] + /* Continuing ugliness: Set up the GIC so NS state owns interrupts, + * The first 32 interrupts (SGIs & PPIs) must be configured on all + * CPUs while the remainder are SPIs and only need to be done one, on + * the boot CPU. */ add r0, r0, #0x80 /* GICD_IGROUP0 */ mov r2, #0xffffffff /* All interrupts to group 1 */ - str r2, [r0] - str r2, [r0, #4] - str r2, [r0, #8] - /* Must drop priority mask below 0x80 before entering NS state */ + teq r12, #0 /* Boot CPU? */ + str r2, [r0] /* Interrupts 0-31 (SGI & PPI) */ + streq r2, [r0, #4] /* Interrupts 32-63 (SPI) */ + streq r2, [r0, #8] /* Interrupts 64-95 (SPI) */ + /* Disable the GIC CPU interface on all processors */ mov r0, #GIC_BASE_ADDRESS add r0, r0, #GIC_CR_OFFSET + mov r1, #0 + str r1, [r0] + /* Must drop priority mask below 0x80 before entering NS state */ ldr r1, =0xff str r1, [r0, #0x4] /* -> GICC_PMR */ /* Reset a few config registers */ -- 1.7.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 10:39:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 10:39:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5J0-0001XI-Lq; Fri, 05 Oct 2012 10:38:54 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5Iy-0001Ty-UD for xen-devel@lists.xen.org; Fri, 05 Oct 2012 10:38:53 +0000 Received: from [85.158.143.99:18701] by server-1.bemta-4.messagelabs.com id 24/06-05684-CB8BE605; Fri, 05 Oct 2012 10:38:52 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1349433529!32967422!3 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ1ODc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31444 invoked from network); 5 Oct 2012 10:38:51 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 10:38:51 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="40248715" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 10:38:29 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 06:38:29 -0400 Received: from [10.80.246.74] (helo=army.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK5Ia-0003Rm-SC; Fri, 05 Oct 2012 11:38:28 +0100 From: Ian Campbell To: Date: Fri, 5 Oct 2012 10:38:16 +0000 Message-ID: <1349433507-21148-10-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.9.1 In-Reply-To: <1349433418.20946.46.camel@zakaz.uk.xensource.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: tim@xen.org, Ian Campbell , stefano.stabelini@citrix.com Subject: [Xen-devel] [PATCH 10/21] arm: disable distributor delivery on boot CPU only X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org The secondary processors do not call enter_hyp_mode until the boot CPU has brought most of the system up, including enabling delivery via the distributor. This means that bringing up secondary CPUs unexpectedly disables the GICD again, meaning we get no further interrupts on any CPU. For completeness also disable the GICC (CPU interface) on all CPUs too. Signed-off-by: Ian Campbell Acked-by: Tim Deegan --- xen/arch/arm/mode_switch.S | 23 +++++++++++++++++------ 1 files changed, 17 insertions(+), 6 deletions(-) diff --git a/xen/arch/arm/mode_switch.S b/xen/arch/arm/mode_switch.S index f5549d7..83a682b 100644 --- a/xen/arch/arm/mode_switch.S +++ b/xen/arch/arm/mode_switch.S @@ -23,6 +23,8 @@ /* Get up a CPU into Hyp mode. Clobbers r0-r3. * + * Expects r12 == CPU number + * * This code is specific to the VE model, and not intended to be used * on production systems. As such it's a bit hackier than the main * boot code in head.S. In future it will be replaced by better @@ -46,19 +48,28 @@ enter_hyp_mode: mcr CP32(r0, CNTFRQ) ldr r0, =0x40c00 /* SMP, c11, c10 in non-secure mode */ mcr CP32(r0, NSACR) - /* Continuing ugliness: Set up the GIC so NS state owns interrupts */ mov r0, #GIC_BASE_ADDRESS add r0, r0, #GIC_DR_OFFSET + /* Disable the GIC distributor, on the boot CPU only */ mov r1, #0 - str r1, [r0] /* Disable delivery in the distributor */ + teq r12, #0 /* Is this the boot CPU? */ + streq r1, [r0] + /* Continuing ugliness: Set up the GIC so NS state owns interrupts, + * The first 32 interrupts (SGIs & PPIs) must be configured on all + * CPUs while the remainder are SPIs and only need to be done one, on + * the boot CPU. */ add r0, r0, #0x80 /* GICD_IGROUP0 */ mov r2, #0xffffffff /* All interrupts to group 1 */ - str r2, [r0] - str r2, [r0, #4] - str r2, [r0, #8] - /* Must drop priority mask below 0x80 before entering NS state */ + teq r12, #0 /* Boot CPU? */ + str r2, [r0] /* Interrupts 0-31 (SGI & PPI) */ + streq r2, [r0, #4] /* Interrupts 32-63 (SPI) */ + streq r2, [r0, #8] /* Interrupts 64-95 (SPI) */ + /* Disable the GIC CPU interface on all processors */ mov r0, #GIC_BASE_ADDRESS add r0, r0, #GIC_CR_OFFSET + mov r1, #0 + str r1, [r0] + /* Must drop priority mask below 0x80 before entering NS state */ ldr r1, =0xff str r1, [r0, #0x4] /* -> GICC_PMR */ /* Reset a few config registers */ -- 1.7.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 10:39:03 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 10:39:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5Iz-0001Wa-Vi; Fri, 05 Oct 2012 10:38:53 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5Iy-0001Ty-9e for xen-devel@lists.xen.org; Fri, 05 Oct 2012 10:38:52 +0000 Received: from [85.158.143.99:4639] by server-1.bemta-4.messagelabs.com id F0/06-05684-CB8BE605; Fri, 05 Oct 2012 10:38:52 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1349433529!32967422!2 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ1ODc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31390 invoked from network); 5 Oct 2012 10:38:51 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 10:38:51 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="40248713" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 10:38:29 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 06:38:28 -0400 Received: from [10.80.246.74] (helo=army.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK5Ia-0003Rm-BL; Fri, 05 Oct 2012 11:38:28 +0100 From: Ian Campbell To: Date: Fri, 5 Oct 2012 10:38:10 +0000 Message-ID: <1349433507-21148-4-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.9.1 In-Reply-To: <1349433418.20946.46.camel@zakaz.uk.xensource.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Stefano Stabellini , tim@xen.org, stefano.stabelini@citrix.com Subject: [Xen-devel] [PATCH 04/21] xen/arm: implement page reference and gnttab functions needed by grant_table.c X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Stefano Stabellini The implementation is strongly "inspired" by their x86 counterparts, except that we assume paging_mode_external and paging_mode_translate. TODO: read_only mappings and gnttab_mark_dirty. Signed-off-by: Stefano Stabellini Acked-by: Ian Campbell --- xen/arch/arm/dummy.S | 9 ---- xen/arch/arm/mm.c | 115 ++++++++++++++++++++++++++++++++++++++++++++++++++ xen/arch/arm/p2m.c | 77 +++++++++++++++++++++++---------- 3 files changed, 168 insertions(+), 33 deletions(-) diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S index 5406077..aaf1ff1 100644 --- a/xen/arch/arm/dummy.S +++ b/xen/arch/arm/dummy.S @@ -23,18 +23,10 @@ DUMMY(arch_vcpu_reset); NOP(update_vcpu_system_time); /* Page Reference & Type Maintenance */ -DUMMY(get_page); DUMMY(get_page_type); -DUMMY(page_get_owner_and_reference); -DUMMY(put_page); DUMMY(put_page_type); /* Grant Tables */ -DUMMY(create_grant_host_mapping); -DUMMY(gnttab_clear_flag); -DUMMY(gnttab_mark_dirty); -DUMMY(is_iomem_page); -DUMMY(replace_grant_host_mapping); DUMMY(steal_page); /* Page Offlining */ @@ -45,7 +37,6 @@ DUMMY(domain_get_maximum_gpfn); DUMMY(domain_relinquish_resources); DUMMY(domain_set_time_offset); DUMMY(dom_cow); -DUMMY(gmfn_to_mfn); DUMMY(send_timer_event); DUMMY(share_xen_page_with_privileged_guests); DUMMY(wallclock_time); diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c index dde304b..8191c90 100644 --- a/xen/arch/arm/mm.c +++ b/xen/arch/arm/mm.c @@ -617,6 +617,121 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg) return 0; } + +struct domain *page_get_owner_and_reference(struct page_info *page) +{ + unsigned long x, y = page->count_info; + + do { + x = y; + /* + * Count == 0: Page is not allocated, so we cannot take a reference. + * Count == -1: Reference count would wrap, which is invalid. + */ + if ( unlikely(((x + 1) & PGC_count_mask) <= 1) ) + return NULL; + } + while ( (y = cmpxchg(&page->count_info, x, x + 1)) != x ); + + return page_get_owner(page); +} + +void put_page(struct page_info *page) +{ + unsigned long nx, x, y = page->count_info; + + do { + ASSERT((y & PGC_count_mask) != 0); + x = y; + nx = x - 1; + } + while ( unlikely((y = cmpxchg(&page->count_info, x, nx)) != x) ); + + if ( unlikely((nx & PGC_count_mask) == 0) ) + { + free_domheap_page(page); + } +} + +int get_page(struct page_info *page, struct domain *domain) +{ + struct domain *owner = page_get_owner_and_reference(page); + + if ( likely(owner == domain) ) + return 1; + + if ( owner != NULL ) + put_page(page); + + return 0; +} + +void gnttab_clear_flag(unsigned long nr, uint16_t *addr) +{ + /* + * Note that this cannot be clear_bit(), as the access must be + * confined to the specified 2 bytes. + */ + uint16_t mask = ~(1 << nr), old; + + do { + old = *addr; + } while (cmpxchg(addr, old, old & mask) != old); +} + +void gnttab_mark_dirty(struct domain *d, unsigned long l) +{ + /* XXX: mark dirty */ + static int warning; + if (!warning) { + gdprintk(XENLOG_WARNING, "gnttab_mark_dirty not implemented yet\n"); + warning = 1; + } +} + +int create_grant_host_mapping(unsigned long addr, unsigned long frame, + unsigned int flags, unsigned int cache_flags) +{ + int rc; + + if ( cache_flags || (flags & ~GNTMAP_readonly) != GNTMAP_host_map ) + return GNTST_general_error; + + /* XXX: read only mappings */ + if ( flags & GNTMAP_readonly ) + { + gdprintk(XENLOG_WARNING, "read only mappings not implemented yet\n"); + return GNTST_general_error; + } + + rc = guest_physmap_add_page(current->domain, + addr >> PAGE_SHIFT, frame, 0); + if ( rc ) + return GNTST_general_error; + else + return GNTST_okay; +} + +int replace_grant_host_mapping(unsigned long addr, unsigned long mfn, + unsigned long new_addr, unsigned int flags) +{ + unsigned long gfn = (unsigned long)(addr >> PAGE_SHIFT); + struct domain *d = current->domain; + + if ( new_addr != 0 || (flags & GNTMAP_contains_pte) ) + return GNTST_general_error; + + guest_physmap_remove_page(d, gfn, mfn, 0); + + return GNTST_okay; +} + +int is_iomem_page(unsigned long mfn) +{ + if ( !mfn_valid(mfn) ) + return 1; + return 0; +} /* * Local variables: * mode: C diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c index 073216b..7c23b7d 100644 --- a/xen/arch/arm/p2m.c +++ b/xen/arch/arm/p2m.c @@ -120,8 +120,14 @@ static int p2m_create_table(struct domain *d, return 0; } +enum p2m_operation { + INSERT, + ALLOCATE, + REMOVE +}; + static int create_p2m_entries(struct domain *d, - int alloc, + enum p2m_operation op, paddr_t start_gpaddr, paddr_t end_gpaddr, paddr_t maddr, @@ -191,25 +197,39 @@ static int create_p2m_entries(struct domain *d, } /* Allocate a new RAM page and attach */ - if (alloc) - { - struct page_info *page; - lpae_t pte; - - rc = -ENOMEM; - page = alloc_domheap_page(d, 0); - if ( page == NULL ) { - printk("p2m_populate_ram: failed to allocate page\n"); - goto out; - } - - pte = mfn_to_p2m_entry(page_to_mfn(page), mattr); - - write_pte(&third[third_table_offset(addr)], pte); - } else { - lpae_t pte = mfn_to_p2m_entry(maddr >> PAGE_SHIFT, mattr); - write_pte(&third[third_table_offset(addr)], pte); - maddr += PAGE_SIZE; + switch (op) { + case ALLOCATE: + { + struct page_info *page; + lpae_t pte; + + rc = -ENOMEM; + page = alloc_domheap_page(d, 0); + if ( page == NULL ) { + printk("p2m_populate_ram: failed to allocate page\n"); + goto out; + } + + pte = mfn_to_p2m_entry(page_to_mfn(page), mattr); + + write_pte(&third[third_table_offset(addr)], pte); + } + break; + case INSERT: + { + lpae_t pte = mfn_to_p2m_entry(maddr >> PAGE_SHIFT, mattr); + write_pte(&third[third_table_offset(addr)], pte); + maddr += PAGE_SIZE; + } + break; + case REMOVE: + { + lpae_t pte; + memset(&pte, 0x00, sizeof(pte)); + write_pte(&third[third_table_offset(addr)], pte); + maddr += PAGE_SIZE; + } + break; } } @@ -229,7 +249,7 @@ int p2m_populate_ram(struct domain *d, paddr_t start, paddr_t end) { - return create_p2m_entries(d, 1, start, end, 0, MATTR_MEM); + return create_p2m_entries(d, ALLOCATE, start, end, 0, MATTR_MEM); } int map_mmio_regions(struct domain *d, @@ -237,7 +257,7 @@ int map_mmio_regions(struct domain *d, paddr_t end_gaddr, paddr_t maddr) { - return create_p2m_entries(d, 0, start_gaddr, end_gaddr, maddr, MATTR_DEV); + return create_p2m_entries(d, INSERT, start_gaddr, end_gaddr, maddr, MATTR_DEV); } int guest_physmap_add_page(struct domain *d, @@ -245,7 +265,7 @@ int guest_physmap_add_page(struct domain *d, unsigned long mfn, unsigned int page_order) { - return create_p2m_entries(d, 0, gpfn << PAGE_SHIFT, + return create_p2m_entries(d, INSERT, gpfn << PAGE_SHIFT, (gpfn + (1<> PAGE_SHIFT; +} + /* * Local variables: * mode: C -- 1.7.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 10:39:03 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 10:39:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5Iz-0001Wa-Vi; Fri, 05 Oct 2012 10:38:53 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5Iy-0001Ty-9e for xen-devel@lists.xen.org; Fri, 05 Oct 2012 10:38:52 +0000 Received: from [85.158.143.99:4639] by server-1.bemta-4.messagelabs.com id F0/06-05684-CB8BE605; Fri, 05 Oct 2012 10:38:52 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1349433529!32967422!2 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ1ODc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31390 invoked from network); 5 Oct 2012 10:38:51 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 10:38:51 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="40248713" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 10:38:29 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 06:38:28 -0400 Received: from [10.80.246.74] (helo=army.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK5Ia-0003Rm-BL; Fri, 05 Oct 2012 11:38:28 +0100 From: Ian Campbell To: Date: Fri, 5 Oct 2012 10:38:10 +0000 Message-ID: <1349433507-21148-4-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.9.1 In-Reply-To: <1349433418.20946.46.camel@zakaz.uk.xensource.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Stefano Stabellini , tim@xen.org, stefano.stabelini@citrix.com Subject: [Xen-devel] [PATCH 04/21] xen/arm: implement page reference and gnttab functions needed by grant_table.c X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Stefano Stabellini The implementation is strongly "inspired" by their x86 counterparts, except that we assume paging_mode_external and paging_mode_translate. TODO: read_only mappings and gnttab_mark_dirty. Signed-off-by: Stefano Stabellini Acked-by: Ian Campbell --- xen/arch/arm/dummy.S | 9 ---- xen/arch/arm/mm.c | 115 ++++++++++++++++++++++++++++++++++++++++++++++++++ xen/arch/arm/p2m.c | 77 +++++++++++++++++++++++---------- 3 files changed, 168 insertions(+), 33 deletions(-) diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S index 5406077..aaf1ff1 100644 --- a/xen/arch/arm/dummy.S +++ b/xen/arch/arm/dummy.S @@ -23,18 +23,10 @@ DUMMY(arch_vcpu_reset); NOP(update_vcpu_system_time); /* Page Reference & Type Maintenance */ -DUMMY(get_page); DUMMY(get_page_type); -DUMMY(page_get_owner_and_reference); -DUMMY(put_page); DUMMY(put_page_type); /* Grant Tables */ -DUMMY(create_grant_host_mapping); -DUMMY(gnttab_clear_flag); -DUMMY(gnttab_mark_dirty); -DUMMY(is_iomem_page); -DUMMY(replace_grant_host_mapping); DUMMY(steal_page); /* Page Offlining */ @@ -45,7 +37,6 @@ DUMMY(domain_get_maximum_gpfn); DUMMY(domain_relinquish_resources); DUMMY(domain_set_time_offset); DUMMY(dom_cow); -DUMMY(gmfn_to_mfn); DUMMY(send_timer_event); DUMMY(share_xen_page_with_privileged_guests); DUMMY(wallclock_time); diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c index dde304b..8191c90 100644 --- a/xen/arch/arm/mm.c +++ b/xen/arch/arm/mm.c @@ -617,6 +617,121 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg) return 0; } + +struct domain *page_get_owner_and_reference(struct page_info *page) +{ + unsigned long x, y = page->count_info; + + do { + x = y; + /* + * Count == 0: Page is not allocated, so we cannot take a reference. + * Count == -1: Reference count would wrap, which is invalid. + */ + if ( unlikely(((x + 1) & PGC_count_mask) <= 1) ) + return NULL; + } + while ( (y = cmpxchg(&page->count_info, x, x + 1)) != x ); + + return page_get_owner(page); +} + +void put_page(struct page_info *page) +{ + unsigned long nx, x, y = page->count_info; + + do { + ASSERT((y & PGC_count_mask) != 0); + x = y; + nx = x - 1; + } + while ( unlikely((y = cmpxchg(&page->count_info, x, nx)) != x) ); + + if ( unlikely((nx & PGC_count_mask) == 0) ) + { + free_domheap_page(page); + } +} + +int get_page(struct page_info *page, struct domain *domain) +{ + struct domain *owner = page_get_owner_and_reference(page); + + if ( likely(owner == domain) ) + return 1; + + if ( owner != NULL ) + put_page(page); + + return 0; +} + +void gnttab_clear_flag(unsigned long nr, uint16_t *addr) +{ + /* + * Note that this cannot be clear_bit(), as the access must be + * confined to the specified 2 bytes. + */ + uint16_t mask = ~(1 << nr), old; + + do { + old = *addr; + } while (cmpxchg(addr, old, old & mask) != old); +} + +void gnttab_mark_dirty(struct domain *d, unsigned long l) +{ + /* XXX: mark dirty */ + static int warning; + if (!warning) { + gdprintk(XENLOG_WARNING, "gnttab_mark_dirty not implemented yet\n"); + warning = 1; + } +} + +int create_grant_host_mapping(unsigned long addr, unsigned long frame, + unsigned int flags, unsigned int cache_flags) +{ + int rc; + + if ( cache_flags || (flags & ~GNTMAP_readonly) != GNTMAP_host_map ) + return GNTST_general_error; + + /* XXX: read only mappings */ + if ( flags & GNTMAP_readonly ) + { + gdprintk(XENLOG_WARNING, "read only mappings not implemented yet\n"); + return GNTST_general_error; + } + + rc = guest_physmap_add_page(current->domain, + addr >> PAGE_SHIFT, frame, 0); + if ( rc ) + return GNTST_general_error; + else + return GNTST_okay; +} + +int replace_grant_host_mapping(unsigned long addr, unsigned long mfn, + unsigned long new_addr, unsigned int flags) +{ + unsigned long gfn = (unsigned long)(addr >> PAGE_SHIFT); + struct domain *d = current->domain; + + if ( new_addr != 0 || (flags & GNTMAP_contains_pte) ) + return GNTST_general_error; + + guest_physmap_remove_page(d, gfn, mfn, 0); + + return GNTST_okay; +} + +int is_iomem_page(unsigned long mfn) +{ + if ( !mfn_valid(mfn) ) + return 1; + return 0; +} /* * Local variables: * mode: C diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c index 073216b..7c23b7d 100644 --- a/xen/arch/arm/p2m.c +++ b/xen/arch/arm/p2m.c @@ -120,8 +120,14 @@ static int p2m_create_table(struct domain *d, return 0; } +enum p2m_operation { + INSERT, + ALLOCATE, + REMOVE +}; + static int create_p2m_entries(struct domain *d, - int alloc, + enum p2m_operation op, paddr_t start_gpaddr, paddr_t end_gpaddr, paddr_t maddr, @@ -191,25 +197,39 @@ static int create_p2m_entries(struct domain *d, } /* Allocate a new RAM page and attach */ - if (alloc) - { - struct page_info *page; - lpae_t pte; - - rc = -ENOMEM; - page = alloc_domheap_page(d, 0); - if ( page == NULL ) { - printk("p2m_populate_ram: failed to allocate page\n"); - goto out; - } - - pte = mfn_to_p2m_entry(page_to_mfn(page), mattr); - - write_pte(&third[third_table_offset(addr)], pte); - } else { - lpae_t pte = mfn_to_p2m_entry(maddr >> PAGE_SHIFT, mattr); - write_pte(&third[third_table_offset(addr)], pte); - maddr += PAGE_SIZE; + switch (op) { + case ALLOCATE: + { + struct page_info *page; + lpae_t pte; + + rc = -ENOMEM; + page = alloc_domheap_page(d, 0); + if ( page == NULL ) { + printk("p2m_populate_ram: failed to allocate page\n"); + goto out; + } + + pte = mfn_to_p2m_entry(page_to_mfn(page), mattr); + + write_pte(&third[third_table_offset(addr)], pte); + } + break; + case INSERT: + { + lpae_t pte = mfn_to_p2m_entry(maddr >> PAGE_SHIFT, mattr); + write_pte(&third[third_table_offset(addr)], pte); + maddr += PAGE_SIZE; + } + break; + case REMOVE: + { + lpae_t pte; + memset(&pte, 0x00, sizeof(pte)); + write_pte(&third[third_table_offset(addr)], pte); + maddr += PAGE_SIZE; + } + break; } } @@ -229,7 +249,7 @@ int p2m_populate_ram(struct domain *d, paddr_t start, paddr_t end) { - return create_p2m_entries(d, 1, start, end, 0, MATTR_MEM); + return create_p2m_entries(d, ALLOCATE, start, end, 0, MATTR_MEM); } int map_mmio_regions(struct domain *d, @@ -237,7 +257,7 @@ int map_mmio_regions(struct domain *d, paddr_t end_gaddr, paddr_t maddr) { - return create_p2m_entries(d, 0, start_gaddr, end_gaddr, maddr, MATTR_DEV); + return create_p2m_entries(d, INSERT, start_gaddr, end_gaddr, maddr, MATTR_DEV); } int guest_physmap_add_page(struct domain *d, @@ -245,7 +265,7 @@ int guest_physmap_add_page(struct domain *d, unsigned long mfn, unsigned int page_order) { - return create_p2m_entries(d, 0, gpfn << PAGE_SHIFT, + return create_p2m_entries(d, INSERT, gpfn << PAGE_SHIFT, (gpfn + (1<> PAGE_SHIFT; +} + /* * Local variables: * mode: C -- 1.7.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 10:39:05 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 10:39:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5J6-0001bJ-FN; Fri, 05 Oct 2012 10:39:00 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5J4-0001Vy-N7 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 10:38:58 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1349433530!5882889!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ1ODc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32220 invoked from network); 5 Oct 2012 10:38:52 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 10:38:52 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="40248716" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 10:38:29 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 06:38:29 -0400 Received: from [10.80.246.74] (helo=army.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK5Ia-0003Rm-Oi; Fri, 05 Oct 2012 11:38:28 +0100 From: Ian Campbell To: Date: Fri, 5 Oct 2012 10:38:15 +0000 Message-ID: <1349433507-21148-9-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.9.1 In-Reply-To: <1349433418.20946.46.camel@zakaz.uk.xensource.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Stefano Stabellini , tim@xen.org, stefano.stabelini@citrix.com Subject: [Xen-devel] [PATCH 09/21] libxc/arm: allocate xenstore and console pages X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Stefano Stabellini Allocate two additional pages at the end of the guest physical memory for xenstore and console. Set HVM_PARAM_STORE_PFN and HVM_PARAM_CONSOLE_PFN to the corresponding values. Signed-off-by: Stefano Stabellini Acked-by: Ian Campbell [ ijc -- pass correct p2m array to populate physmap in alloc_magic_pages ] --- tools/libxc/xc_dom_arm.c | 33 +++++++++++++++++++++++++++------ 1 files changed, 27 insertions(+), 6 deletions(-) diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c index 65dafe8..b743a6c 100644 --- a/tools/libxc/xc_dom_arm.c +++ b/tools/libxc/xc_dom_arm.c @@ -25,6 +25,10 @@ #include "xg_private.h" #include "xc_dom.h" +#define NR_MAGIC_PAGES 2 +#define CONSOLE_PFN_OFFSET 0 +#define XENSTORE_PFN_OFFSET 1 + /* ------------------------------------------------------------------------ */ /* * arm guests are hybrid and start off with paging disabled, therefore no @@ -46,13 +50,30 @@ static int setup_pgtables_arm(struct xc_dom_image *dom) static int alloc_magic_pages(struct xc_dom_image *dom) { + int rc, i; + xen_pfn_t store_pfn, console_pfn, p2m[NR_MAGIC_PAGES]; + DOMPRINTF_CALLED(dom->xch); - /* XXX - * dom->p2m_guest - * dom->start_info_pfn - * dom->xenstore_pfn - * dom->console_pfn - */ + + for (i = 0; i < NR_MAGIC_PAGES; i++) + p2m[i] = dom->rambase_pfn + dom->total_pages + i; + + rc = xc_domain_populate_physmap_exact( + dom->xch, dom->guest_domid, NR_MAGIC_PAGES, + 0, 0, p2m); + if ( rc < 0 ) + return rc; + + console_pfn = dom->rambase_pfn + dom->total_pages + CONSOLE_PFN_OFFSET; + store_pfn = dom->rambase_pfn + dom->total_pages + XENSTORE_PFN_OFFSET; + + xc_clear_domain_page(dom->xch, dom->guest_domid, console_pfn); + xc_clear_domain_page(dom->xch, dom->guest_domid, store_pfn); + xc_set_hvm_param(dom->xch, dom->guest_domid, HVM_PARAM_CONSOLE_PFN, + console_pfn); + xc_set_hvm_param(dom->xch, dom->guest_domid, HVM_PARAM_STORE_PFN, + store_pfn); + return 0; } -- 1.7.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 10:39:05 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 10:39:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5J6-0001bJ-FN; Fri, 05 Oct 2012 10:39:00 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5J4-0001Vy-N7 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 10:38:58 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1349433530!5882889!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ1ODc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32220 invoked from network); 5 Oct 2012 10:38:52 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 10:38:52 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="40248716" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 10:38:29 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 06:38:29 -0400 Received: from [10.80.246.74] (helo=army.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK5Ia-0003Rm-Oi; Fri, 05 Oct 2012 11:38:28 +0100 From: Ian Campbell To: Date: Fri, 5 Oct 2012 10:38:15 +0000 Message-ID: <1349433507-21148-9-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.9.1 In-Reply-To: <1349433418.20946.46.camel@zakaz.uk.xensource.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Stefano Stabellini , tim@xen.org, stefano.stabelini@citrix.com Subject: [Xen-devel] [PATCH 09/21] libxc/arm: allocate xenstore and console pages X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Stefano Stabellini Allocate two additional pages at the end of the guest physical memory for xenstore and console. Set HVM_PARAM_STORE_PFN and HVM_PARAM_CONSOLE_PFN to the corresponding values. Signed-off-by: Stefano Stabellini Acked-by: Ian Campbell [ ijc -- pass correct p2m array to populate physmap in alloc_magic_pages ] --- tools/libxc/xc_dom_arm.c | 33 +++++++++++++++++++++++++++------ 1 files changed, 27 insertions(+), 6 deletions(-) diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c index 65dafe8..b743a6c 100644 --- a/tools/libxc/xc_dom_arm.c +++ b/tools/libxc/xc_dom_arm.c @@ -25,6 +25,10 @@ #include "xg_private.h" #include "xc_dom.h" +#define NR_MAGIC_PAGES 2 +#define CONSOLE_PFN_OFFSET 0 +#define XENSTORE_PFN_OFFSET 1 + /* ------------------------------------------------------------------------ */ /* * arm guests are hybrid and start off with paging disabled, therefore no @@ -46,13 +50,30 @@ static int setup_pgtables_arm(struct xc_dom_image *dom) static int alloc_magic_pages(struct xc_dom_image *dom) { + int rc, i; + xen_pfn_t store_pfn, console_pfn, p2m[NR_MAGIC_PAGES]; + DOMPRINTF_CALLED(dom->xch); - /* XXX - * dom->p2m_guest - * dom->start_info_pfn - * dom->xenstore_pfn - * dom->console_pfn - */ + + for (i = 0; i < NR_MAGIC_PAGES; i++) + p2m[i] = dom->rambase_pfn + dom->total_pages + i; + + rc = xc_domain_populate_physmap_exact( + dom->xch, dom->guest_domid, NR_MAGIC_PAGES, + 0, 0, p2m); + if ( rc < 0 ) + return rc; + + console_pfn = dom->rambase_pfn + dom->total_pages + CONSOLE_PFN_OFFSET; + store_pfn = dom->rambase_pfn + dom->total_pages + XENSTORE_PFN_OFFSET; + + xc_clear_domain_page(dom->xch, dom->guest_domid, console_pfn); + xc_clear_domain_page(dom->xch, dom->guest_domid, store_pfn); + xc_set_hvm_param(dom->xch, dom->guest_domid, HVM_PARAM_CONSOLE_PFN, + console_pfn); + xc_set_hvm_param(dom->xch, dom->guest_domid, HVM_PARAM_STORE_PFN, + store_pfn); + return 0; } -- 1.7.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 10:52:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 10:52:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5Vz-0002sl-5m; Fri, 05 Oct 2012 10:52:19 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5Vx-0002sP-E4 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 10:52:17 +0000 Received: from [85.158.138.51:29510] by server-14.bemta-3.messagelabs.com id 6A/4A-19528-0EBBE605; Fri, 05 Oct 2012 10:52:16 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1349434333!25181158!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODA1MjM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24807 invoked from network); 5 Oct 2012 10:52:15 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 10:52:15 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="210397082" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 10:52:14 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 06:52:14 -0400 Received: from [10.80.246.74] (helo=army.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK5Ib-0003Rm-FB; Fri, 05 Oct 2012 11:38:29 +0100 From: Ian Campbell To: Date: Fri, 5 Oct 2012 10:38:23 +0000 Message-ID: <1349433507-21148-17-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.9.1 In-Reply-To: <1349433418.20946.46.camel@zakaz.uk.xensource.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: keir@xen.org, Stefano Stabellini , tim@xen.org, JBeulich@suse.com, stefano.stabelini@citrix.com Subject: [Xen-devel] [PATCH 17/21] xen: xen_ulong_t substitution X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Stefano Stabellini There is still an unwanted unsigned long in the xen public interface: replace it with xen_ulong_t. Also typedef xen_ulong_t to uint64_t on ARM. Changes in v2: - do not replace the unsigned long in x86 specific calls; - do not replace the unsigned long in multicall_entry; - add missing include "xen.h" in version.h; - use proper printf flag for xen_ulong_t. Signed-off-by: Stefano Stabellini Cc: keir@xen.org Cc: JBeulich@suse.com --- tools/python/xen/lowlevel/xc/xc.c | 2 +- xen/include/public/arch-arm.h | 3 ++- xen/include/public/version.h | 4 +++- 3 files changed, 6 insertions(+), 3 deletions(-) diff --git a/tools/python/xen/lowlevel/xc/xc.c b/tools/python/xen/lowlevel/xc/xc.c index 7c89756..e220f68 100644 --- a/tools/python/xen/lowlevel/xc/xc.c +++ b/tools/python/xen/lowlevel/xc/xc.c @@ -1439,7 +1439,7 @@ static PyObject *pyxc_xeninfo(XcObject *self) if ( xc_version(self->xc_handle, XENVER_commandline, &xen_commandline) != 0 ) return pyxc_error_to_exception(self->xc_handle); - snprintf(str, sizeof(str), "virt_start=0x%lx", p_parms.virt_start); + snprintf(str, sizeof(str), "virt_start=0x%"PRI_xen_ulong, p_parms.virt_start); xen_pagesize = xc_version(self->xc_handle, XENVER_pagesize, NULL); if (xen_pagesize < 0 ) diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h index e3d4ad9..2ae6548 100644 --- a/xen/include/public/arch-arm.h +++ b/xen/include/public/arch-arm.h @@ -122,7 +122,8 @@ typedef uint64_t xen_pfn_t; /* Only one. All other VCPUS must use VCPUOP_register_vcpu_info */ #define XEN_LEGACY_MAX_VCPUS 1 -typedef uint32_t xen_ulong_t; +typedef uint64_t xen_ulong_t; +#define PRI_xen_ulong PRIx64 struct vcpu_guest_context { #define _VGCF_online 0 diff --git a/xen/include/public/version.h b/xen/include/public/version.h index 8742c2b..c7e6f8c 100644 --- a/xen/include/public/version.h +++ b/xen/include/public/version.h @@ -28,6 +28,8 @@ #ifndef __XEN_PUBLIC_VERSION_H__ #define __XEN_PUBLIC_VERSION_H__ +#include "xen.h" + /* NB. All ops return zero on success, except XENVER_{version,pagesize} */ /* arg == NULL; returns major:minor (16:16). */ @@ -58,7 +60,7 @@ typedef char xen_changeset_info_t[64]; #define XENVER_platform_parameters 5 struct xen_platform_parameters { - unsigned long virt_start; + xen_ulong_t virt_start; }; typedef struct xen_platform_parameters xen_platform_parameters_t; -- 1.7.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 10:52:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 10:52:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5W0-0002tO-N8; Fri, 05 Oct 2012 10:52:20 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5Vy-0002sY-Lh for xen-devel@lists.xen.org; Fri, 05 Oct 2012 10:52:18 +0000 Received: from [85.158.139.211:18429] by server-10.bemta-5.messagelabs.com id B9/A7-16911-1EBBE605; Fri, 05 Oct 2012 10:52:17 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-5.tower-206.messagelabs.com!1349434335!21149639!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ1ODc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13458 invoked from network); 5 Oct 2012 10:52:17 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 10:52:17 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="40249331" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 10:52:16 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 06:52:16 -0400 Received: from [10.80.246.74] (helo=army.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK5Ib-0003Rm-7y; Fri, 05 Oct 2012 11:38:29 +0100 From: Ian Campbell To: Date: Fri, 5 Oct 2012 10:38:20 +0000 Message-ID: <1349433507-21148-14-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.9.1 In-Reply-To: <1349433418.20946.46.camel@zakaz.uk.xensource.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: tim@xen.org, Ian Campbell , stefano.stabelini@citrix.com Subject: [Xen-devel] [PATCH 14/21] arm/vtimer: convert result to ticks when reading CNTPCT register X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Ian Campbell Acked-by: Tim Deegan --- xen/arch/arm/vtimer.c | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c index 6b1152e..490b021 100644 --- a/xen/arch/arm/vtimer.c +++ b/xen/arch/arm/vtimer.c @@ -103,6 +103,7 @@ static int vtimer_emulate_64(struct cpu_user_regs *regs, union hsr hsr) struct hsr_cp64 cp64 = hsr.cp64; uint32_t *r1 = ®s->r0 + cp64.reg1; uint32_t *r2 = ®s->r0 + cp64.reg2; + uint64_t ticks; s_time_t now; switch ( hsr.bits & HSR_CP64_REGS_MASK ) @@ -111,8 +112,9 @@ static int vtimer_emulate_64(struct cpu_user_regs *regs, union hsr hsr) if ( cp64.read ) { now = NOW() - v->arch.vtimer.offset; - *r1 = (uint32_t)(now & 0xffffffff); - *r2 = (uint32_t)(now >> 32); + ticks = ns_to_ticks(now); + *r1 = (uint32_t)(ticks & 0xffffffff); + *r2 = (uint32_t)(ticks >> 32); return 1; } else -- 1.7.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 10:52:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 10:52:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5Vy-0002sa-Qe; Fri, 05 Oct 2012 10:52:18 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5Vw-0002sO-OQ for xen-devel@lists.xen.org; Fri, 05 Oct 2012 10:52:17 +0000 Received: from [85.158.138.51:29480] by server-8.bemta-3.messagelabs.com id B4/54-16337-0EBBE605; Fri, 05 Oct 2012 10:52:16 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1349434333!25181158!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODA1MjM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24756 invoked from network); 5 Oct 2012 10:52:14 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 10:52:14 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="210397080" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 10:52:12 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 06:52:12 -0400 Received: from [10.80.246.74] (helo=army.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK5Ic-0003Rm-0b; Fri, 05 Oct 2012 11:38:30 +0100 From: Ian Campbell To: Date: Fri, 5 Oct 2012 10:38:27 +0000 Message-ID: <1349433507-21148-21-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.9.1 In-Reply-To: <1349433418.20946.46.camel@zakaz.uk.xensource.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: keir@xen.org, Stefano Stabellini , tim@xen.org, JBeulich@suse.com, stefano.stabelini@citrix.com Subject: [Xen-devel] [PATCH 21/21] xen: more substitutions X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Stefano Stabellini More substitutions in this patch, not as obvious as the ones in the previous patch. Signed-off-by: Stefano Stabellini Cc: keir@xen.org Cc: JBeulich@suse.com --- xen/arch/x86/mm.c | 12 +++++++++--- xen/arch/x86/oprofile/backtrace.c | 4 +++- xen/arch/x86/platform_hypercall.c | 8 ++++++-- xen/arch/x86/x86_64/cpu_idle.c | 4 +++- xen/arch/x86/x86_64/cpufreq.c | 4 +++- xen/arch/x86/x86_64/platform_hypercall.c | 1 + xen/common/compat/multicall.c | 1 + 7 files changed, 26 insertions(+), 8 deletions(-) diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index 9a828de..f9a41fd 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -2913,7 +2913,9 @@ long do_mmuext_op( { cpumask_t pmask; - if ( unlikely(vcpumask_to_pcpumask(d, op.arg2.vcpumask, &pmask)) ) + if ( unlikely(vcpumask_to_pcpumask(d, + guest_handle_to_param(op.arg2.vcpumask, const_void), + &pmask)) ) { okay = 0; break; @@ -4195,6 +4197,7 @@ static int handle_iomem_range(unsigned long s, unsigned long e, void *p) if ( s > ctxt->s ) { e820entry_t ent; + XEN_GUEST_HANDLE_PARAM(e820entry_t) buffer_t; XEN_GUEST_HANDLE(e820entry_t) buffer; if ( ctxt->n + 1 >= ctxt->map.nr_entries ) @@ -4202,7 +4205,8 @@ static int handle_iomem_range(unsigned long s, unsigned long e, void *p) ent.addr = (uint64_t)ctxt->s << PAGE_SHIFT; ent.size = (uint64_t)(s - ctxt->s) << PAGE_SHIFT; ent.type = E820_RESERVED; - buffer = guest_handle_cast(ctxt->map.buffer, e820entry_t); + buffer_t = guest_handle_cast(ctxt->map.buffer, e820entry_t); + buffer = guest_handle_from_param(buffer_t, e820entry_t); if ( __copy_to_guest_offset(buffer, ctxt->n, &ent, 1) ) return -EFAULT; ctxt->n++; @@ -4499,6 +4503,7 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg) { struct memory_map_context ctxt; XEN_GUEST_HANDLE(e820entry_t) buffer; + XEN_GUEST_HANDLE_PARAM(e820entry_t) buffer_t; unsigned int i; if ( !IS_PRIV(current->domain) ) @@ -4513,7 +4518,8 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg) if ( ctxt.map.nr_entries < e820.nr_map + 1 ) return -EINVAL; - buffer = guest_handle_cast(ctxt.map.buffer, e820entry_t); + buffer_t = guest_handle_cast(ctxt.map.buffer, e820entry_t); + buffer = guest_handle_from_param(buffer_t, e820entry_t); if ( !guest_handle_okay(buffer, ctxt.map.nr_entries) ) return -EFAULT; diff --git a/xen/arch/x86/oprofile/backtrace.c b/xen/arch/x86/oprofile/backtrace.c index 433f881..6924385 100644 --- a/xen/arch/x86/oprofile/backtrace.c +++ b/xen/arch/x86/oprofile/backtrace.c @@ -74,8 +74,10 @@ dump_guest_backtrace(struct vcpu *vcpu, const struct frame_head *head, } else { - XEN_GUEST_HANDLE(const_frame_head_t) guest_head = + XEN_GUEST_HANDLE(const_frame_head_t) guest_head; + XEN_GUEST_HANDLE_PARAM(const_frame_head_t) guest_head_t = const_guest_handle_from_ptr(head, frame_head_t); + guest_head = guest_handle_from_param(guest_head_t, const_frame_head_t); /* Also check accessibility of one struct frame_head beyond */ if (!guest_handle_okay(guest_head, 2)) diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hypercall.c index 7a7325f..a3b5a6b 100644 --- a/xen/arch/x86/platform_hypercall.c +++ b/xen/arch/x86/platform_hypercall.c @@ -186,7 +186,9 @@ ret_t do_platform_op(XEN_GUEST_HANDLE_PARAM(xen_platform_op_t) u_xenpf_op) } } - ret = microcode_update(data, op->u.microcode.length); + ret = microcode_update( + guest_handle_to_param(data, const_void), + op->u.microcode.length); spin_unlock(&vcpu_alloc_lock); } break; @@ -454,7 +456,9 @@ ret_t do_platform_op(XEN_GUEST_HANDLE_PARAM(xen_platform_op_t) u_xenpf_op) XEN_GUEST_HANDLE(uint32) pdc; guest_from_compat_handle(pdc, op->u.set_pminfo.u.pdc); - ret = acpi_set_pdc_bits(op->u.set_pminfo.id, pdc); + ret = acpi_set_pdc_bits( + op->u.set_pminfo.id, + guest_handle_to_param(pdc, uint32)); } break; diff --git a/xen/arch/x86/x86_64/cpu_idle.c b/xen/arch/x86/x86_64/cpu_idle.c index 3e7422f..1cdaf96 100644 --- a/xen/arch/x86/x86_64/cpu_idle.c +++ b/xen/arch/x86/x86_64/cpu_idle.c @@ -57,10 +57,12 @@ static int copy_from_compat_state(xen_processor_cx_t *xen_state, { #define XLAT_processor_cx_HNDL_dp(_d_, _s_) do { \ XEN_GUEST_HANDLE(compat_processor_csd_t) dps; \ + XEN_GUEST_HANDLE_PARAM(xen_processor_csd_t) dps_t; \ if ( unlikely(!compat_handle_okay((_s_)->dp, (_s_)->dpcnt)) ) \ return -EFAULT; \ guest_from_compat_handle(dps, (_s_)->dp); \ - (_d_)->dp = guest_handle_cast(dps, xen_processor_csd_t); \ + dps_t = guest_handle_cast(dps, xen_processor_csd_t); \ + (_d_)->dp = guest_handle_from_param(dps_t, xen_processor_csd_t); \ } while (0) XLAT_processor_cx(xen_state, state); #undef XLAT_processor_cx_HNDL_dp diff --git a/xen/arch/x86/x86_64/cpufreq.c b/xen/arch/x86/x86_64/cpufreq.c index ce9864e..1956777 100644 --- a/xen/arch/x86/x86_64/cpufreq.c +++ b/xen/arch/x86/x86_64/cpufreq.c @@ -45,10 +45,12 @@ compat_set_px_pminfo(uint32_t cpu, struct compat_processor_performance *perf) #define XLAT_processor_performance_HNDL_states(_d_, _s_) do { \ XEN_GUEST_HANDLE(compat_processor_px_t) states; \ + XEN_GUEST_HANDLE_PARAM(xen_processor_px_t) states_t; \ if ( unlikely(!compat_handle_okay((_s_)->states, (_s_)->state_count)) ) \ return -EFAULT; \ guest_from_compat_handle(states, (_s_)->states); \ - (_d_)->states = guest_handle_cast(states, xen_processor_px_t); \ + states_t = guest_handle_cast(states, xen_processor_px_t); \ + (_d_)->states = guest_handle_from_param(states_t, xen_processor_px_t); \ } while (0) XLAT_processor_performance(xen_perf, perf); diff --git a/xen/arch/x86/x86_64/platform_hypercall.c b/xen/arch/x86/x86_64/platform_hypercall.c index 188aa37..f577761 100644 --- a/xen/arch/x86/x86_64/platform_hypercall.c +++ b/xen/arch/x86/x86_64/platform_hypercall.c @@ -38,6 +38,7 @@ CHECK_pf_pcpu_version; #define COMPAT #define _XEN_GUEST_HANDLE(t) XEN_GUEST_HANDLE(t) +#define _XEN_GUEST_HANDLE_PARAM(t) XEN_GUEST_HANDLE(t) typedef int ret_t; #include "../platform_hypercall.c" diff --git a/xen/common/compat/multicall.c b/xen/common/compat/multicall.c index e7e2a40..3219d3c 100644 --- a/xen/common/compat/multicall.c +++ b/xen/common/compat/multicall.c @@ -25,6 +25,7 @@ DEFINE_XEN_GUEST_HANDLE(multicall_entry_compat_t); #define call compat_call #define do_multicall(l, n) compat_multicall(_##l, n) #define _XEN_GUEST_HANDLE(t) XEN_GUEST_HANDLE(t) +#define _XEN_GUEST_HANDLE_PARAM(t) XEN_GUEST_HANDLE(t) static void __trace_multicall_call(multicall_entry_t *call) { -- 1.7.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 10:52:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 10:52:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5W1-0002tb-2D; Fri, 05 Oct 2012 10:52:21 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5Vz-0002sZ-6O for xen-devel@lists.xen.org; Fri, 05 Oct 2012 10:52:19 +0000 Received: from [85.158.139.83:63504] by server-14.bemta-5.messagelabs.com id 8A/EE-31065-2EBBE605; Fri, 05 Oct 2012 10:52:18 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1349434336!33017323!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODA1MjM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12538 invoked from network); 5 Oct 2012 10:52:17 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 10:52:17 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="210397083" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 10:52:16 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 06:52:15 -0400 Received: from [10.80.246.74] (helo=army.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK5Ib-0003Rm-17; Fri, 05 Oct 2012 11:38:29 +0100 From: Ian Campbell To: Date: Fri, 5 Oct 2012 10:38:18 +0000 Message-ID: <1349433507-21148-12-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.9.1 In-Reply-To: <1349433418.20946.46.camel@zakaz.uk.xensource.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Stefano Stabellini , tim@xen.org, stefano.stabelini@citrix.com Subject: [Xen-devel] [PATCH 12/21] xen/arm: introduce __lshrdi3 and __aeabi_llsr X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Stefano Stabellini Taken from Linux. Signed-off-by: Stefano Stabellini Acked-by: Ian Campbell --- xen/arch/arm/lib/Makefile | 2 +- xen/arch/arm/lib/lshrdi3.S | 54 ++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 55 insertions(+), 1 deletions(-) create mode 100644 xen/arch/arm/lib/lshrdi3.S diff --git a/xen/arch/arm/lib/Makefile b/xen/arch/arm/lib/Makefile index cbbed68..4cf41f4 100644 --- a/xen/arch/arm/lib/Makefile +++ b/xen/arch/arm/lib/Makefile @@ -2,4 +2,4 @@ obj-y += memcpy.o memmove.o memset.o memzero.o obj-y += findbit.o setbit.o obj-y += setbit.o clearbit.o changebit.o obj-y += testsetbit.o testclearbit.o testchangebit.o -obj-y += lib1funcs.o div64.o +obj-y += lib1funcs.o lshrdi3.o div64.o diff --git a/xen/arch/arm/lib/lshrdi3.S b/xen/arch/arm/lib/lshrdi3.S new file mode 100644 index 0000000..3e8887e --- /dev/null +++ b/xen/arch/arm/lib/lshrdi3.S @@ -0,0 +1,54 @@ +/* Copyright 1995, 1996, 1998, 1999, 2000, 2003, 2004, 2005 + Free Software Foundation, Inc. + +This file is free software; you can redistribute it and/or modify it +under the terms of the GNU General Public License as published by the +Free Software Foundation; either version 2, or (at your option) any +later version. + +In addition to the permissions in the GNU General Public License, the +Free Software Foundation gives you unlimited permission to link the +compiled version of this file into combinations with other programs, +and to distribute those combinations without any restriction coming +from the use of this file. (The General Public License restrictions +do apply in other respects; for example, they cover modification of +the file, and distribution when not linked into a combine +executable.) + +This file is distributed in the hope that it will be useful, but +WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +General Public License for more details. + +You should have received a copy of the GNU General Public License +along with this program; see the file COPYING. If not, write to +the Free Software Foundation, 51 Franklin Street, Fifth Floor, +Boston, MA 02110-1301, USA. */ + + +#include +#include "assembler.h" + +#ifdef __ARMEB__ +#define al r1 +#define ah r0 +#else +#define al r0 +#define ah r1 +#endif + +ENTRY(__lshrdi3) +ENTRY(__aeabi_llsr) + + subs r3, r2, #32 + rsb ip, r2, #32 + movmi al, al, lsr r2 + movpl al, ah, lsr r3 + ARM( orrmi al, al, ah, lsl ip ) + THUMB( lslmi r3, ah, ip ) + THUMB( orrmi al, al, r3 ) + mov ah, ah, lsr r2 + mov pc, lr + +ENDPROC(__lshrdi3) +ENDPROC(__aeabi_llsr) -- 1.7.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 10:52:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 10:52:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5Vy-0002sa-Qe; Fri, 05 Oct 2012 10:52:18 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5Vw-0002sO-OQ for xen-devel@lists.xen.org; Fri, 05 Oct 2012 10:52:17 +0000 Received: from [85.158.138.51:29480] by server-8.bemta-3.messagelabs.com id B4/54-16337-0EBBE605; Fri, 05 Oct 2012 10:52:16 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1349434333!25181158!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODA1MjM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24756 invoked from network); 5 Oct 2012 10:52:14 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 10:52:14 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="210397080" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 10:52:12 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 06:52:12 -0400 Received: from [10.80.246.74] (helo=army.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK5Ic-0003Rm-0b; Fri, 05 Oct 2012 11:38:30 +0100 From: Ian Campbell To: Date: Fri, 5 Oct 2012 10:38:27 +0000 Message-ID: <1349433507-21148-21-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.9.1 In-Reply-To: <1349433418.20946.46.camel@zakaz.uk.xensource.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: keir@xen.org, Stefano Stabellini , tim@xen.org, JBeulich@suse.com, stefano.stabelini@citrix.com Subject: [Xen-devel] [PATCH 21/21] xen: more substitutions X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Stefano Stabellini More substitutions in this patch, not as obvious as the ones in the previous patch. Signed-off-by: Stefano Stabellini Cc: keir@xen.org Cc: JBeulich@suse.com --- xen/arch/x86/mm.c | 12 +++++++++--- xen/arch/x86/oprofile/backtrace.c | 4 +++- xen/arch/x86/platform_hypercall.c | 8 ++++++-- xen/arch/x86/x86_64/cpu_idle.c | 4 +++- xen/arch/x86/x86_64/cpufreq.c | 4 +++- xen/arch/x86/x86_64/platform_hypercall.c | 1 + xen/common/compat/multicall.c | 1 + 7 files changed, 26 insertions(+), 8 deletions(-) diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index 9a828de..f9a41fd 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -2913,7 +2913,9 @@ long do_mmuext_op( { cpumask_t pmask; - if ( unlikely(vcpumask_to_pcpumask(d, op.arg2.vcpumask, &pmask)) ) + if ( unlikely(vcpumask_to_pcpumask(d, + guest_handle_to_param(op.arg2.vcpumask, const_void), + &pmask)) ) { okay = 0; break; @@ -4195,6 +4197,7 @@ static int handle_iomem_range(unsigned long s, unsigned long e, void *p) if ( s > ctxt->s ) { e820entry_t ent; + XEN_GUEST_HANDLE_PARAM(e820entry_t) buffer_t; XEN_GUEST_HANDLE(e820entry_t) buffer; if ( ctxt->n + 1 >= ctxt->map.nr_entries ) @@ -4202,7 +4205,8 @@ static int handle_iomem_range(unsigned long s, unsigned long e, void *p) ent.addr = (uint64_t)ctxt->s << PAGE_SHIFT; ent.size = (uint64_t)(s - ctxt->s) << PAGE_SHIFT; ent.type = E820_RESERVED; - buffer = guest_handle_cast(ctxt->map.buffer, e820entry_t); + buffer_t = guest_handle_cast(ctxt->map.buffer, e820entry_t); + buffer = guest_handle_from_param(buffer_t, e820entry_t); if ( __copy_to_guest_offset(buffer, ctxt->n, &ent, 1) ) return -EFAULT; ctxt->n++; @@ -4499,6 +4503,7 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg) { struct memory_map_context ctxt; XEN_GUEST_HANDLE(e820entry_t) buffer; + XEN_GUEST_HANDLE_PARAM(e820entry_t) buffer_t; unsigned int i; if ( !IS_PRIV(current->domain) ) @@ -4513,7 +4518,8 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg) if ( ctxt.map.nr_entries < e820.nr_map + 1 ) return -EINVAL; - buffer = guest_handle_cast(ctxt.map.buffer, e820entry_t); + buffer_t = guest_handle_cast(ctxt.map.buffer, e820entry_t); + buffer = guest_handle_from_param(buffer_t, e820entry_t); if ( !guest_handle_okay(buffer, ctxt.map.nr_entries) ) return -EFAULT; diff --git a/xen/arch/x86/oprofile/backtrace.c b/xen/arch/x86/oprofile/backtrace.c index 433f881..6924385 100644 --- a/xen/arch/x86/oprofile/backtrace.c +++ b/xen/arch/x86/oprofile/backtrace.c @@ -74,8 +74,10 @@ dump_guest_backtrace(struct vcpu *vcpu, const struct frame_head *head, } else { - XEN_GUEST_HANDLE(const_frame_head_t) guest_head = + XEN_GUEST_HANDLE(const_frame_head_t) guest_head; + XEN_GUEST_HANDLE_PARAM(const_frame_head_t) guest_head_t = const_guest_handle_from_ptr(head, frame_head_t); + guest_head = guest_handle_from_param(guest_head_t, const_frame_head_t); /* Also check accessibility of one struct frame_head beyond */ if (!guest_handle_okay(guest_head, 2)) diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hypercall.c index 7a7325f..a3b5a6b 100644 --- a/xen/arch/x86/platform_hypercall.c +++ b/xen/arch/x86/platform_hypercall.c @@ -186,7 +186,9 @@ ret_t do_platform_op(XEN_GUEST_HANDLE_PARAM(xen_platform_op_t) u_xenpf_op) } } - ret = microcode_update(data, op->u.microcode.length); + ret = microcode_update( + guest_handle_to_param(data, const_void), + op->u.microcode.length); spin_unlock(&vcpu_alloc_lock); } break; @@ -454,7 +456,9 @@ ret_t do_platform_op(XEN_GUEST_HANDLE_PARAM(xen_platform_op_t) u_xenpf_op) XEN_GUEST_HANDLE(uint32) pdc; guest_from_compat_handle(pdc, op->u.set_pminfo.u.pdc); - ret = acpi_set_pdc_bits(op->u.set_pminfo.id, pdc); + ret = acpi_set_pdc_bits( + op->u.set_pminfo.id, + guest_handle_to_param(pdc, uint32)); } break; diff --git a/xen/arch/x86/x86_64/cpu_idle.c b/xen/arch/x86/x86_64/cpu_idle.c index 3e7422f..1cdaf96 100644 --- a/xen/arch/x86/x86_64/cpu_idle.c +++ b/xen/arch/x86/x86_64/cpu_idle.c @@ -57,10 +57,12 @@ static int copy_from_compat_state(xen_processor_cx_t *xen_state, { #define XLAT_processor_cx_HNDL_dp(_d_, _s_) do { \ XEN_GUEST_HANDLE(compat_processor_csd_t) dps; \ + XEN_GUEST_HANDLE_PARAM(xen_processor_csd_t) dps_t; \ if ( unlikely(!compat_handle_okay((_s_)->dp, (_s_)->dpcnt)) ) \ return -EFAULT; \ guest_from_compat_handle(dps, (_s_)->dp); \ - (_d_)->dp = guest_handle_cast(dps, xen_processor_csd_t); \ + dps_t = guest_handle_cast(dps, xen_processor_csd_t); \ + (_d_)->dp = guest_handle_from_param(dps_t, xen_processor_csd_t); \ } while (0) XLAT_processor_cx(xen_state, state); #undef XLAT_processor_cx_HNDL_dp diff --git a/xen/arch/x86/x86_64/cpufreq.c b/xen/arch/x86/x86_64/cpufreq.c index ce9864e..1956777 100644 --- a/xen/arch/x86/x86_64/cpufreq.c +++ b/xen/arch/x86/x86_64/cpufreq.c @@ -45,10 +45,12 @@ compat_set_px_pminfo(uint32_t cpu, struct compat_processor_performance *perf) #define XLAT_processor_performance_HNDL_states(_d_, _s_) do { \ XEN_GUEST_HANDLE(compat_processor_px_t) states; \ + XEN_GUEST_HANDLE_PARAM(xen_processor_px_t) states_t; \ if ( unlikely(!compat_handle_okay((_s_)->states, (_s_)->state_count)) ) \ return -EFAULT; \ guest_from_compat_handle(states, (_s_)->states); \ - (_d_)->states = guest_handle_cast(states, xen_processor_px_t); \ + states_t = guest_handle_cast(states, xen_processor_px_t); \ + (_d_)->states = guest_handle_from_param(states_t, xen_processor_px_t); \ } while (0) XLAT_processor_performance(xen_perf, perf); diff --git a/xen/arch/x86/x86_64/platform_hypercall.c b/xen/arch/x86/x86_64/platform_hypercall.c index 188aa37..f577761 100644 --- a/xen/arch/x86/x86_64/platform_hypercall.c +++ b/xen/arch/x86/x86_64/platform_hypercall.c @@ -38,6 +38,7 @@ CHECK_pf_pcpu_version; #define COMPAT #define _XEN_GUEST_HANDLE(t) XEN_GUEST_HANDLE(t) +#define _XEN_GUEST_HANDLE_PARAM(t) XEN_GUEST_HANDLE(t) typedef int ret_t; #include "../platform_hypercall.c" diff --git a/xen/common/compat/multicall.c b/xen/common/compat/multicall.c index e7e2a40..3219d3c 100644 --- a/xen/common/compat/multicall.c +++ b/xen/common/compat/multicall.c @@ -25,6 +25,7 @@ DEFINE_XEN_GUEST_HANDLE(multicall_entry_compat_t); #define call compat_call #define do_multicall(l, n) compat_multicall(_##l, n) #define _XEN_GUEST_HANDLE(t) XEN_GUEST_HANDLE(t) +#define _XEN_GUEST_HANDLE_PARAM(t) XEN_GUEST_HANDLE(t) static void __trace_multicall_call(multicall_entry_t *call) { -- 1.7.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 10:52:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 10:52:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5Vz-0002sl-5m; Fri, 05 Oct 2012 10:52:19 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5Vx-0002sP-E4 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 10:52:17 +0000 Received: from [85.158.138.51:29510] by server-14.bemta-3.messagelabs.com id 6A/4A-19528-0EBBE605; Fri, 05 Oct 2012 10:52:16 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1349434333!25181158!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODA1MjM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24807 invoked from network); 5 Oct 2012 10:52:15 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 10:52:15 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="210397082" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 10:52:14 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 06:52:14 -0400 Received: from [10.80.246.74] (helo=army.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK5Ib-0003Rm-FB; Fri, 05 Oct 2012 11:38:29 +0100 From: Ian Campbell To: Date: Fri, 5 Oct 2012 10:38:23 +0000 Message-ID: <1349433507-21148-17-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.9.1 In-Reply-To: <1349433418.20946.46.camel@zakaz.uk.xensource.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: keir@xen.org, Stefano Stabellini , tim@xen.org, JBeulich@suse.com, stefano.stabelini@citrix.com Subject: [Xen-devel] [PATCH 17/21] xen: xen_ulong_t substitution X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Stefano Stabellini There is still an unwanted unsigned long in the xen public interface: replace it with xen_ulong_t. Also typedef xen_ulong_t to uint64_t on ARM. Changes in v2: - do not replace the unsigned long in x86 specific calls; - do not replace the unsigned long in multicall_entry; - add missing include "xen.h" in version.h; - use proper printf flag for xen_ulong_t. Signed-off-by: Stefano Stabellini Cc: keir@xen.org Cc: JBeulich@suse.com --- tools/python/xen/lowlevel/xc/xc.c | 2 +- xen/include/public/arch-arm.h | 3 ++- xen/include/public/version.h | 4 +++- 3 files changed, 6 insertions(+), 3 deletions(-) diff --git a/tools/python/xen/lowlevel/xc/xc.c b/tools/python/xen/lowlevel/xc/xc.c index 7c89756..e220f68 100644 --- a/tools/python/xen/lowlevel/xc/xc.c +++ b/tools/python/xen/lowlevel/xc/xc.c @@ -1439,7 +1439,7 @@ static PyObject *pyxc_xeninfo(XcObject *self) if ( xc_version(self->xc_handle, XENVER_commandline, &xen_commandline) != 0 ) return pyxc_error_to_exception(self->xc_handle); - snprintf(str, sizeof(str), "virt_start=0x%lx", p_parms.virt_start); + snprintf(str, sizeof(str), "virt_start=0x%"PRI_xen_ulong, p_parms.virt_start); xen_pagesize = xc_version(self->xc_handle, XENVER_pagesize, NULL); if (xen_pagesize < 0 ) diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h index e3d4ad9..2ae6548 100644 --- a/xen/include/public/arch-arm.h +++ b/xen/include/public/arch-arm.h @@ -122,7 +122,8 @@ typedef uint64_t xen_pfn_t; /* Only one. All other VCPUS must use VCPUOP_register_vcpu_info */ #define XEN_LEGACY_MAX_VCPUS 1 -typedef uint32_t xen_ulong_t; +typedef uint64_t xen_ulong_t; +#define PRI_xen_ulong PRIx64 struct vcpu_guest_context { #define _VGCF_online 0 diff --git a/xen/include/public/version.h b/xen/include/public/version.h index 8742c2b..c7e6f8c 100644 --- a/xen/include/public/version.h +++ b/xen/include/public/version.h @@ -28,6 +28,8 @@ #ifndef __XEN_PUBLIC_VERSION_H__ #define __XEN_PUBLIC_VERSION_H__ +#include "xen.h" + /* NB. All ops return zero on success, except XENVER_{version,pagesize} */ /* arg == NULL; returns major:minor (16:16). */ @@ -58,7 +60,7 @@ typedef char xen_changeset_info_t[64]; #define XENVER_platform_parameters 5 struct xen_platform_parameters { - unsigned long virt_start; + xen_ulong_t virt_start; }; typedef struct xen_platform_parameters xen_platform_parameters_t; -- 1.7.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 10:52:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 10:52:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5W1-0002tb-2D; Fri, 05 Oct 2012 10:52:21 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5Vz-0002sZ-6O for xen-devel@lists.xen.org; Fri, 05 Oct 2012 10:52:19 +0000 Received: from [85.158.139.83:63504] by server-14.bemta-5.messagelabs.com id 8A/EE-31065-2EBBE605; Fri, 05 Oct 2012 10:52:18 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1349434336!33017323!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODA1MjM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12538 invoked from network); 5 Oct 2012 10:52:17 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 10:52:17 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="210397083" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 10:52:16 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 06:52:15 -0400 Received: from [10.80.246.74] (helo=army.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK5Ib-0003Rm-17; Fri, 05 Oct 2012 11:38:29 +0100 From: Ian Campbell To: Date: Fri, 5 Oct 2012 10:38:18 +0000 Message-ID: <1349433507-21148-12-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.9.1 In-Reply-To: <1349433418.20946.46.camel@zakaz.uk.xensource.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Stefano Stabellini , tim@xen.org, stefano.stabelini@citrix.com Subject: [Xen-devel] [PATCH 12/21] xen/arm: introduce __lshrdi3 and __aeabi_llsr X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Stefano Stabellini Taken from Linux. Signed-off-by: Stefano Stabellini Acked-by: Ian Campbell --- xen/arch/arm/lib/Makefile | 2 +- xen/arch/arm/lib/lshrdi3.S | 54 ++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 55 insertions(+), 1 deletions(-) create mode 100644 xen/arch/arm/lib/lshrdi3.S diff --git a/xen/arch/arm/lib/Makefile b/xen/arch/arm/lib/Makefile index cbbed68..4cf41f4 100644 --- a/xen/arch/arm/lib/Makefile +++ b/xen/arch/arm/lib/Makefile @@ -2,4 +2,4 @@ obj-y += memcpy.o memmove.o memset.o memzero.o obj-y += findbit.o setbit.o obj-y += setbit.o clearbit.o changebit.o obj-y += testsetbit.o testclearbit.o testchangebit.o -obj-y += lib1funcs.o div64.o +obj-y += lib1funcs.o lshrdi3.o div64.o diff --git a/xen/arch/arm/lib/lshrdi3.S b/xen/arch/arm/lib/lshrdi3.S new file mode 100644 index 0000000..3e8887e --- /dev/null +++ b/xen/arch/arm/lib/lshrdi3.S @@ -0,0 +1,54 @@ +/* Copyright 1995, 1996, 1998, 1999, 2000, 2003, 2004, 2005 + Free Software Foundation, Inc. + +This file is free software; you can redistribute it and/or modify it +under the terms of the GNU General Public License as published by the +Free Software Foundation; either version 2, or (at your option) any +later version. + +In addition to the permissions in the GNU General Public License, the +Free Software Foundation gives you unlimited permission to link the +compiled version of this file into combinations with other programs, +and to distribute those combinations without any restriction coming +from the use of this file. (The General Public License restrictions +do apply in other respects; for example, they cover modification of +the file, and distribution when not linked into a combine +executable.) + +This file is distributed in the hope that it will be useful, but +WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +General Public License for more details. + +You should have received a copy of the GNU General Public License +along with this program; see the file COPYING. If not, write to +the Free Software Foundation, 51 Franklin Street, Fifth Floor, +Boston, MA 02110-1301, USA. */ + + +#include +#include "assembler.h" + +#ifdef __ARMEB__ +#define al r1 +#define ah r0 +#else +#define al r0 +#define ah r1 +#endif + +ENTRY(__lshrdi3) +ENTRY(__aeabi_llsr) + + subs r3, r2, #32 + rsb ip, r2, #32 + movmi al, al, lsr r2 + movpl al, ah, lsr r3 + ARM( orrmi al, al, ah, lsl ip ) + THUMB( lslmi r3, ah, ip ) + THUMB( orrmi al, al, r3 ) + mov ah, ah, lsr r2 + mov pc, lr + +ENDPROC(__lshrdi3) +ENDPROC(__aeabi_llsr) -- 1.7.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 10:52:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 10:52:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5W0-0002tO-N8; Fri, 05 Oct 2012 10:52:20 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5Vy-0002sY-Lh for xen-devel@lists.xen.org; Fri, 05 Oct 2012 10:52:18 +0000 Received: from [85.158.139.211:18429] by server-10.bemta-5.messagelabs.com id B9/A7-16911-1EBBE605; Fri, 05 Oct 2012 10:52:17 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-5.tower-206.messagelabs.com!1349434335!21149639!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ1ODc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13458 invoked from network); 5 Oct 2012 10:52:17 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 10:52:17 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="40249331" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 10:52:16 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 06:52:16 -0400 Received: from [10.80.246.74] (helo=army.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK5Ib-0003Rm-7y; Fri, 05 Oct 2012 11:38:29 +0100 From: Ian Campbell To: Date: Fri, 5 Oct 2012 10:38:20 +0000 Message-ID: <1349433507-21148-14-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.9.1 In-Reply-To: <1349433418.20946.46.camel@zakaz.uk.xensource.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: tim@xen.org, Ian Campbell , stefano.stabelini@citrix.com Subject: [Xen-devel] [PATCH 14/21] arm/vtimer: convert result to ticks when reading CNTPCT register X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Ian Campbell Acked-by: Tim Deegan --- xen/arch/arm/vtimer.c | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c index 6b1152e..490b021 100644 --- a/xen/arch/arm/vtimer.c +++ b/xen/arch/arm/vtimer.c @@ -103,6 +103,7 @@ static int vtimer_emulate_64(struct cpu_user_regs *regs, union hsr hsr) struct hsr_cp64 cp64 = hsr.cp64; uint32_t *r1 = ®s->r0 + cp64.reg1; uint32_t *r2 = ®s->r0 + cp64.reg2; + uint64_t ticks; s_time_t now; switch ( hsr.bits & HSR_CP64_REGS_MASK ) @@ -111,8 +112,9 @@ static int vtimer_emulate_64(struct cpu_user_regs *regs, union hsr hsr) if ( cp64.read ) { now = NOW() - v->arch.vtimer.offset; - *r1 = (uint32_t)(now & 0xffffffff); - *r2 = (uint32_t)(now >> 32); + ticks = ns_to_ticks(now); + *r1 = (uint32_t)(ticks & 0xffffffff); + *r2 = (uint32_t)(ticks >> 32); return 1; } else -- 1.7.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 10:52:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 10:52:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5W3-0002vD-Va; Fri, 05 Oct 2012 10:52:23 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5W2-0002tw-8s for xen-devel@lists.xen.org; Fri, 05 Oct 2012 10:52:22 +0000 Received: from [85.158.143.99:18531] by server-3.bemta-4.messagelabs.com id 5E/66-10986-5EBBE605; Fri, 05 Oct 2012 10:52:21 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1349434338!24861283!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODA1MjM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26702 invoked from network); 5 Oct 2012 10:52:19 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 10:52:19 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="210397084" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 10:52:18 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 06:52:17 -0400 Received: from [10.80.246.74] (helo=army.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK5Ib-0003Rm-Re; Fri, 05 Oct 2012 11:38:29 +0100 From: Ian Campbell To: Date: Fri, 5 Oct 2012 10:38:26 +0000 Message-ID: <1349433507-21148-20-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.9.1 In-Reply-To: <1349433418.20946.46.camel@zakaz.uk.xensource.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: keir@xen.org, Stefano Stabellini , tim@xen.org, JBeulich@suse.com, stefano.stabelini@citrix.com Subject: [Xen-devel] [PATCH 20/21] xen: replace XEN_GUEST_HANDLE with XEN_GUEST_HANDLE_PARAM when appropriate X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Stefano Stabellini Note: these changes don't make any difference on x86 and ia64. Replace XEN_GUEST_HANDLE with XEN_GUEST_HANDLE_PARAM when it is used as an hypercall argument. Signed-off-by: Stefano Stabellini Cc: keir@xen.org Cc: JBeulich@suse.com --- xen/arch/arm/domain.c | 2 +- xen/arch/arm/domctl.c | 2 +- xen/arch/arm/hvm.c | 2 +- xen/arch/arm/mm.c | 2 +- xen/arch/arm/physdev.c | 2 +- xen/arch/arm/sysctl.c | 2 +- xen/arch/x86/compat.c | 2 +- xen/arch/x86/cpu/mcheck/mce.c | 2 +- xen/arch/x86/domain.c | 2 +- xen/arch/x86/domctl.c | 2 +- xen/arch/x86/efi/runtime.c | 2 +- xen/arch/x86/hvm/hvm.c | 26 +++++++++--------- xen/arch/x86/microcode.c | 2 +- xen/arch/x86/mm.c | 14 +++++----- xen/arch/x86/mm/hap/hap.c | 2 +- xen/arch/x86/mm/mem_event.c | 2 +- xen/arch/x86/mm/paging.c | 2 +- xen/arch/x86/mm/shadow/common.c | 2 +- xen/arch/x86/oprofile/xenoprof.c | 6 ++-- xen/arch/x86/physdev.c | 2 +- xen/arch/x86/platform_hypercall.c | 2 +- xen/arch/x86/sysctl.c | 2 +- xen/arch/x86/traps.c | 2 +- xen/arch/x86/x86_64/compat/mm.c | 10 +++--- xen/arch/x86/x86_64/domain.c | 2 +- xen/arch/x86/x86_64/mm.c | 2 +- xen/arch/x86/x86_64/traps.c | 2 +- xen/common/compat/domain.c | 2 +- xen/common/compat/grant_table.c | 8 +++--- xen/common/compat/memory.c | 4 +- xen/common/domain.c | 2 +- xen/common/domctl.c | 2 +- xen/common/event_channel.c | 2 +- xen/common/grant_table.c | 36 +++++++++++++------------- xen/common/kernel.c | 4 +- xen/common/kexec.c | 17 ++++++----- xen/common/memory.c | 4 +- xen/common/multicall.c | 2 +- xen/common/schedule.c | 2 +- xen/common/sysctl.c | 2 +- xen/common/xenoprof.c | 8 +++--- xen/drivers/acpi/pmstat.c | 2 +- xen/drivers/char/console.c | 6 ++-- xen/drivers/passthrough/iommu.c | 2 +- xen/include/asm-arm/hypercall.h | 2 +- xen/include/asm-arm/mm.h | 2 +- xen/include/asm-x86/hap.h | 2 +- xen/include/asm-x86/hypercall.h | 22 ++++++++-------- xen/include/asm-x86/mem_event.h | 2 +- xen/include/asm-x86/mm.h | 8 +++--- xen/include/asm-x86/paging.h | 2 +- xen/include/asm-x86/processor.h | 2 +- xen/include/asm-x86/shadow.h | 2 +- xen/include/asm-x86/xenoprof.h | 6 ++-- xen/include/public/tmem.h | 2 +- xen/include/xen/acpi.h | 4 +- xen/include/xen/hypercall.h | 52 ++++++++++++++++++------------------ xen/include/xen/iommu.h | 2 +- xen/include/xen/tmem_xen.h | 2 +- xen/include/xsm/xsm.h | 4 +- xen/xsm/dummy.c | 2 +- xen/xsm/flask/flask_op.c | 4 +- xen/xsm/flask/hooks.c | 2 +- xen/xsm/xsm_core.c | 2 +- 64 files changed, 167 insertions(+), 166 deletions(-) diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c index f47db4f..c5292c7 100644 --- a/xen/arch/arm/domain.c +++ b/xen/arch/arm/domain.c @@ -519,7 +519,7 @@ void arch_dump_domain_info(struct domain *d) { } -long arch_do_vcpu_op(int cmd, struct vcpu *v, XEN_GUEST_HANDLE(void) arg) +long arch_do_vcpu_op(int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg) { return -ENOSYS; } diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c index 1a5f79f..cf16791 100644 --- a/xen/arch/arm/domctl.c +++ b/xen/arch/arm/domctl.c @@ -11,7 +11,7 @@ #include long arch_do_domctl(struct xen_domctl *domctl, - XEN_GUEST_HANDLE(xen_domctl_t) u_domctl) + XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) { return -ENOSYS; } diff --git a/xen/arch/arm/hvm.c b/xen/arch/arm/hvm.c index c11378d..40f519e 100644 --- a/xen/arch/arm/hvm.c +++ b/xen/arch/arm/hvm.c @@ -11,7 +11,7 @@ #include -long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg) +long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg) { long rc = 0; diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c index bf9b6c5..49102db 100644 --- a/xen/arch/arm/mm.c +++ b/xen/arch/arm/mm.c @@ -581,7 +581,7 @@ out: } -long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg) +long arch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg) { int rc; diff --git a/xen/arch/arm/physdev.c b/xen/arch/arm/physdev.c index bcf4337..0801e8c 100644 --- a/xen/arch/arm/physdev.c +++ b/xen/arch/arm/physdev.c @@ -11,7 +11,7 @@ #include -int do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg) +int do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) { printk("%s %d cmd=%d: not implemented yet\n", __func__, __LINE__, cmd); return -ENOSYS; diff --git a/xen/arch/arm/sysctl.c b/xen/arch/arm/sysctl.c index e8e1c0d..a286abe 100644 --- a/xen/arch/arm/sysctl.c +++ b/xen/arch/arm/sysctl.c @@ -13,7 +13,7 @@ #include long arch_do_sysctl(struct xen_sysctl *sysctl, - XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl) + XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl) { return -ENOSYS; } diff --git a/xen/arch/x86/compat.c b/xen/arch/x86/compat.c index a4fda06..2d05867 100644 --- a/xen/arch/x86/compat.c +++ b/xen/arch/x86/compat.c @@ -27,7 +27,7 @@ ret_t do_physdev_op_compat(XEN_GUEST_HANDLE(physdev_op_t) uop) #ifndef COMPAT /* Legacy hypercall (as of 0x00030202). */ -long do_event_channel_op_compat(XEN_GUEST_HANDLE(evtchn_op_t) uop) +long do_event_channel_op_compat(XEN_GUEST_HANDLE_PARAM(evtchn_op_t) uop) { struct evtchn_op op; diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c index 5f03394..06dddee 100644 --- a/xen/arch/x86/cpu/mcheck/mce.c +++ b/xen/arch/x86/cpu/mcheck/mce.c @@ -1288,7 +1288,7 @@ CHECK_mcinfo_recovery; # undef xen_mcinfo_recovery /* Machine Check Architecture Hypercall */ -long do_mca(XEN_GUEST_HANDLE(xen_mc_t) u_xen_mc) +long do_mca(XEN_GUEST_HANDLE_PARAM(xen_mc_t) u_xen_mc) { long ret = 0; struct xen_mc curop, *op = &curop; diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index 58766ba..233c597 100644 --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -1077,7 +1077,7 @@ map_vcpu_info(struct vcpu *v, unsigned long gfn, unsigned offset) long arch_do_vcpu_op( - int cmd, struct vcpu *v, XEN_GUEST_HANDLE(void) arg) + int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg) { long rc = 0; diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c index 24b3178..c3d6093 100644 --- a/xen/arch/x86/domctl.c +++ b/xen/arch/x86/domctl.c @@ -48,7 +48,7 @@ static int gdbsx_guest_mem_io( long arch_do_domctl( struct xen_domctl *domctl, - XEN_GUEST_HANDLE(xen_domctl_t) u_domctl) + XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) { long ret = 0; diff --git a/xen/arch/x86/efi/runtime.c b/xen/arch/x86/efi/runtime.c index 1dbe2db..b2ff495 100644 --- a/xen/arch/x86/efi/runtime.c +++ b/xen/arch/x86/efi/runtime.c @@ -184,7 +184,7 @@ int efi_get_info(uint32_t idx, union xenpf_efi_info *info) return 0; } -static long gwstrlen(XEN_GUEST_HANDLE(CHAR16) str) +static long gwstrlen(XEN_GUEST_HANDLE_PARAM(CHAR16) str) { unsigned long len; diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index a5a1bcf..b83e336 100644 --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -3091,14 +3091,14 @@ static int grant_table_op_is_allowed(unsigned int cmd) } static long hvm_grant_table_op( - unsigned int cmd, XEN_GUEST_HANDLE(void) uop, unsigned int count) + unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) uop, unsigned int count) { if ( !grant_table_op_is_allowed(cmd) ) return -ENOSYS; /* all other commands need auditing */ return do_grant_table_op(cmd, uop, count); } -static long hvm_memory_op(int cmd, XEN_GUEST_HANDLE(void) arg) +static long hvm_memory_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) { long rc; @@ -3116,7 +3116,7 @@ static long hvm_memory_op(int cmd, XEN_GUEST_HANDLE(void) arg) return do_memory_op(cmd, arg); } -static long hvm_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg) +static long hvm_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) { switch ( cmd ) { @@ -3132,7 +3132,7 @@ static long hvm_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg) } static long hvm_vcpu_op( - int cmd, int vcpuid, XEN_GUEST_HANDLE(void) arg) + int cmd, int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg) { long rc; @@ -3163,7 +3163,7 @@ typedef unsigned long hvm_hypercall_t( [ __HYPERVISOR_ ## x ] = (hvm_hypercall_t *) do_ ## x static long hvm_grant_table_op_compat32(unsigned int cmd, - XEN_GUEST_HANDLE(void) uop, + XEN_GUEST_HANDLE_PARAM(void) uop, unsigned int count) { if ( !grant_table_op_is_allowed(cmd) ) @@ -3171,7 +3171,7 @@ static long hvm_grant_table_op_compat32(unsigned int cmd, return compat_grant_table_op(cmd, uop, count); } -static long hvm_memory_op_compat32(int cmd, XEN_GUEST_HANDLE(void) arg) +static long hvm_memory_op_compat32(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) { int rc; @@ -3190,7 +3190,7 @@ static long hvm_memory_op_compat32(int cmd, XEN_GUEST_HANDLE(void) arg) } static long hvm_vcpu_op_compat32( - int cmd, int vcpuid, XEN_GUEST_HANDLE(void) arg) + int cmd, int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg) { long rc; @@ -3214,7 +3214,7 @@ static long hvm_vcpu_op_compat32( } static long hvm_physdev_op_compat32( - int cmd, XEN_GUEST_HANDLE(void) arg) + int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) { switch ( cmd ) { @@ -3380,7 +3380,7 @@ void hvm_hypercall_page_initialise(struct domain *d, } static int hvmop_set_pci_intx_level( - XEN_GUEST_HANDLE(xen_hvm_set_pci_intx_level_t) uop) + XEN_GUEST_HANDLE_PARAM(xen_hvm_set_pci_intx_level_t) uop) { struct xen_hvm_set_pci_intx_level op; struct domain *d; @@ -3547,7 +3547,7 @@ static void hvm_s3_resume(struct domain *d) } static int hvmop_set_isa_irq_level( - XEN_GUEST_HANDLE(xen_hvm_set_isa_irq_level_t) uop) + XEN_GUEST_HANDLE_PARAM(xen_hvm_set_isa_irq_level_t) uop) { struct xen_hvm_set_isa_irq_level op; struct domain *d; @@ -3591,7 +3591,7 @@ static int hvmop_set_isa_irq_level( } static int hvmop_set_pci_link_route( - XEN_GUEST_HANDLE(xen_hvm_set_pci_link_route_t) uop) + XEN_GUEST_HANDLE_PARAM(xen_hvm_set_pci_link_route_t) uop) { struct xen_hvm_set_pci_link_route op; struct domain *d; @@ -3624,7 +3624,7 @@ static int hvmop_set_pci_link_route( } static int hvmop_inject_msi( - XEN_GUEST_HANDLE(xen_hvm_inject_msi_t) uop) + XEN_GUEST_HANDLE_PARAM(xen_hvm_inject_msi_t) uop) { struct xen_hvm_inject_msi op; struct domain *d; @@ -3708,7 +3708,7 @@ static int hvm_replace_event_channel(struct vcpu *v, domid_t remote_domid, return 0; } -long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg) +long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg) { struct domain *curr_d = current->domain; diff --git a/xen/arch/x86/microcode.c b/xen/arch/x86/microcode.c index fe51034..fbbf95b 100644 --- a/xen/arch/x86/microcode.c +++ b/xen/arch/x86/microcode.c @@ -195,7 +195,7 @@ static long do_microcode_update(void *_info) return error; } -int microcode_update(XEN_GUEST_HANDLE(const_void) buf, unsigned long len) +int microcode_update(XEN_GUEST_HANDLE_PARAM(const_void) buf, unsigned long len) { int ret; struct microcode_info *info; diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index 8ab92c9..9a828de 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -2652,7 +2652,7 @@ static void put_pg_owner(struct domain *pg_owner) } static inline int vcpumask_to_pcpumask( - struct domain *d, XEN_GUEST_HANDLE(const_void) bmap, cpumask_t *pmask) + struct domain *d, XEN_GUEST_HANDLE_PARAM(const_void) bmap, cpumask_t *pmask) { unsigned int vcpu_id, vcpu_bias, offs; unsigned long vmask; @@ -2692,9 +2692,9 @@ static inline int vcpumask_to_pcpumask( #define fixunmap_domain_page(ptr) ((void)(ptr)) long do_mmuext_op( - XEN_GUEST_HANDLE(mmuext_op_t) uops, + XEN_GUEST_HANDLE_PARAM(mmuext_op_t) uops, unsigned int count, - XEN_GUEST_HANDLE(uint) pdone, + XEN_GUEST_HANDLE_PARAM(uint) pdone, unsigned int foreigndom) { struct mmuext_op op; @@ -3151,9 +3151,9 @@ long do_mmuext_op( } long do_mmu_update( - XEN_GUEST_HANDLE(mmu_update_t) ureqs, + XEN_GUEST_HANDLE_PARAM(mmu_update_t) ureqs, unsigned int count, - XEN_GUEST_HANDLE(uint) pdone, + XEN_GUEST_HANDLE_PARAM(uint) pdone, unsigned int foreigndom) { struct mmu_update req; @@ -4098,7 +4098,7 @@ long set_gdt(struct vcpu *v, } -long do_set_gdt(XEN_GUEST_HANDLE(ulong) frame_list, unsigned int entries) +long do_set_gdt(XEN_GUEST_HANDLE_PARAM(ulong) frame_list, unsigned int entries) { int nr_pages = (entries + 511) / 512; unsigned long frames[16]; @@ -4370,7 +4370,7 @@ static int xenmem_add_to_physmap(struct domain *d, return xenmem_add_to_physmap_once(d, xatp); } -long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg) +long arch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg) { int rc; diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c index d2637d3..fd99cde 100644 --- a/xen/arch/x86/mm/hap/hap.c +++ b/xen/arch/x86/mm/hap/hap.c @@ -571,7 +571,7 @@ void hap_teardown(struct domain *d) } int hap_domctl(struct domain *d, xen_domctl_shadow_op_t *sc, - XEN_GUEST_HANDLE(void) u_domctl) + XEN_GUEST_HANDLE_PARAM(void) u_domctl) { int rc, preempted = 0; diff --git a/xen/arch/x86/mm/mem_event.c b/xen/arch/x86/mm/mem_event.c index 942c19e..27d1cf4 100644 --- a/xen/arch/x86/mm/mem_event.c +++ b/xen/arch/x86/mm/mem_event.c @@ -512,7 +512,7 @@ void mem_event_cleanup(struct domain *d) } int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec, - XEN_GUEST_HANDLE(void) u_domctl) + XEN_GUEST_HANDLE_PARAM(void) u_domctl) { int rc; diff --git a/xen/arch/x86/mm/paging.c b/xen/arch/x86/mm/paging.c index ca879f9..ea44e39 100644 --- a/xen/arch/x86/mm/paging.c +++ b/xen/arch/x86/mm/paging.c @@ -654,7 +654,7 @@ void paging_vcpu_init(struct vcpu *v) int paging_domctl(struct domain *d, xen_domctl_shadow_op_t *sc, - XEN_GUEST_HANDLE(void) u_domctl) + XEN_GUEST_HANDLE_PARAM(void) u_domctl) { int rc; diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c index 3f8ad88..ce79131 100644 --- a/xen/arch/x86/mm/shadow/common.c +++ b/xen/arch/x86/mm/shadow/common.c @@ -3641,7 +3641,7 @@ out: int shadow_domctl(struct domain *d, xen_domctl_shadow_op_t *sc, - XEN_GUEST_HANDLE(void) u_domctl) + XEN_GUEST_HANDLE_PARAM(void) u_domctl) { int rc, preempted = 0; diff --git a/xen/arch/x86/oprofile/xenoprof.c b/xen/arch/x86/oprofile/xenoprof.c index 160abac..90ef67d 100644 --- a/xen/arch/x86/oprofile/xenoprof.c +++ b/xen/arch/x86/oprofile/xenoprof.c @@ -17,7 +17,7 @@ #include "op_counter.h" -int xenoprof_arch_counter(XEN_GUEST_HANDLE(void) arg) +int xenoprof_arch_counter(XEN_GUEST_HANDLE_PARAM(void) arg) { struct xenoprof_counter counter; @@ -37,7 +37,7 @@ int xenoprof_arch_counter(XEN_GUEST_HANDLE(void) arg) return 0; } -int xenoprof_arch_ibs_counter(XEN_GUEST_HANDLE(void) arg) +int xenoprof_arch_ibs_counter(XEN_GUEST_HANDLE_PARAM(void) arg) { struct xenoprof_ibs_counter ibs_counter; @@ -54,7 +54,7 @@ int xenoprof_arch_ibs_counter(XEN_GUEST_HANDLE(void) arg) return 0; } -int compat_oprof_arch_counter(XEN_GUEST_HANDLE(void) arg) +int compat_oprof_arch_counter(XEN_GUEST_HANDLE_PARAM(void) arg) { struct compat_oprof_counter counter; diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c index 984c813..751cbd4 100644 --- a/xen/arch/x86/physdev.c +++ b/xen/arch/x86/physdev.c @@ -258,7 +258,7 @@ int physdev_unmap_pirq(domid_t domid, int pirq) } #endif /* COMPAT */ -ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg) +ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) { int irq; ret_t ret; diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hypercall.c index 073a2ea..7a7325f 100644 --- a/xen/arch/x86/platform_hypercall.c +++ b/xen/arch/x86/platform_hypercall.c @@ -61,7 +61,7 @@ long cpu_down_helper(void *data); long core_parking_helper(void *data); uint32_t get_cur_idle_nums(void); -ret_t do_platform_op(XEN_GUEST_HANDLE(xen_platform_op_t) u_xenpf_op) +ret_t do_platform_op(XEN_GUEST_HANDLE_PARAM(xen_platform_op_t) u_xenpf_op) { ret_t ret = 0; struct xen_platform_op curop, *op = &curop; diff --git a/xen/arch/x86/sysctl.c b/xen/arch/x86/sysctl.c index 379f071..b84dd34 100644 --- a/xen/arch/x86/sysctl.c +++ b/xen/arch/x86/sysctl.c @@ -58,7 +58,7 @@ long cpu_down_helper(void *data) } long arch_do_sysctl( - struct xen_sysctl *sysctl, XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl) + struct xen_sysctl *sysctl, XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl) { long ret = 0; diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c index de08e25..dfaf78e 100644 --- a/xen/arch/x86/traps.c +++ b/xen/arch/x86/traps.c @@ -3536,7 +3536,7 @@ int send_guest_trap(struct domain *d, uint16_t vcpuid, unsigned int trap_nr) } -long do_set_trap_table(XEN_GUEST_HANDLE(const_trap_info_t) traps) +long do_set_trap_table(XEN_GUEST_HANDLE_PARAM(const_trap_info_t) traps) { struct trap_info cur; struct vcpu *curr = current; diff --git a/xen/arch/x86/x86_64/compat/mm.c b/xen/arch/x86/x86_64/compat/mm.c index f497503..d1eb785 100644 --- a/xen/arch/x86/x86_64/compat/mm.c +++ b/xen/arch/x86/x86_64/compat/mm.c @@ -5,7 +5,7 @@ #include #include -int compat_set_gdt(XEN_GUEST_HANDLE(uint) frame_list, unsigned int entries) +int compat_set_gdt(XEN_GUEST_HANDLE_PARAM(uint) frame_list, unsigned int entries) { unsigned int i, nr_pages = (entries + 511) / 512; unsigned long frames[16]; @@ -44,7 +44,7 @@ int compat_update_descriptor(u32 pa_lo, u32 pa_hi, u32 desc_lo, u32 desc_hi) desc_lo | ((u64)desc_hi << 32)); } -int compat_arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg) +int compat_arch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg) { struct compat_machphys_mfn_list xmml; l2_pgentry_t l2e; @@ -260,14 +260,14 @@ int compat_update_va_mapping_otherdomain(unsigned long va, u32 lo, u32 hi, DEFINE_XEN_GUEST_HANDLE(mmuext_op_compat_t); -int compat_mmuext_op(XEN_GUEST_HANDLE(mmuext_op_compat_t) cmp_uops, +int compat_mmuext_op(XEN_GUEST_HANDLE_PARAM(mmuext_op_compat_t) cmp_uops, unsigned int count, - XEN_GUEST_HANDLE(uint) pdone, + XEN_GUEST_HANDLE_PARAM(uint) pdone, unsigned int foreigndom) { unsigned int i, preempt_mask; int rc = 0; - XEN_GUEST_HANDLE(mmuext_op_t) nat_ops; + XEN_GUEST_HANDLE_PARAM(mmuext_op_t) nat_ops; preempt_mask = count & MMU_UPDATE_PREEMPTED; count ^= preempt_mask; diff --git a/xen/arch/x86/x86_64/domain.c b/xen/arch/x86/x86_64/domain.c index e746c89..144ca2d 100644 --- a/xen/arch/x86/x86_64/domain.c +++ b/xen/arch/x86/x86_64/domain.c @@ -23,7 +23,7 @@ CHECK_vcpu_get_physid; int arch_compat_vcpu_op( - int cmd, struct vcpu *v, XEN_GUEST_HANDLE(void) arg) + int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg) { int rc = -ENOSYS; diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c index 1e001ea..35653b7 100644 --- a/xen/arch/x86/x86_64/mm.c +++ b/xen/arch/x86/x86_64/mm.c @@ -1027,7 +1027,7 @@ void __init subarch_init_memory(void) } } -long subarch_memory_op(int op, XEN_GUEST_HANDLE(void) arg) +long subarch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg) { struct xen_machphys_mfn_list xmml; l3_pgentry_t l3e; diff --git a/xen/arch/x86/x86_64/traps.c b/xen/arch/x86/x86_64/traps.c index 3361d19..dfe0fac 100644 --- a/xen/arch/x86/x86_64/traps.c +++ b/xen/arch/x86/x86_64/traps.c @@ -519,7 +519,7 @@ static long unregister_guest_callback(struct callback_unregister *unreg) } -long do_callback_op(int cmd, XEN_GUEST_HANDLE(const_void) arg) +long do_callback_op(int cmd, XEN_GUEST_HANDLE_PARAM(const_void) arg) { long ret; diff --git a/xen/common/compat/domain.c b/xen/common/compat/domain.c index 40a0287..e4c8ceb 100644 --- a/xen/common/compat/domain.c +++ b/xen/common/compat/domain.c @@ -15,7 +15,7 @@ CHECK_vcpu_set_periodic_timer; #undef xen_vcpu_set_periodic_timer -int compat_vcpu_op(int cmd, int vcpuid, XEN_GUEST_HANDLE(void) arg) +int compat_vcpu_op(int cmd, int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg) { struct domain *d = current->domain; struct vcpu *v; diff --git a/xen/common/compat/grant_table.c b/xen/common/compat/grant_table.c index edd20c6..b524955 100644 --- a/xen/common/compat/grant_table.c +++ b/xen/common/compat/grant_table.c @@ -52,12 +52,12 @@ CHECK_gnttab_swap_grant_ref; #undef xen_gnttab_swap_grant_ref int compat_grant_table_op(unsigned int cmd, - XEN_GUEST_HANDLE(void) cmp_uop, + XEN_GUEST_HANDLE_PARAM(void) cmp_uop, unsigned int count) { int rc = 0; unsigned int i; - XEN_GUEST_HANDLE(void) cnt_uop; + XEN_GUEST_HANDLE_PARAM(void) cnt_uop; set_xen_guest_handle(cnt_uop, NULL); switch ( cmd ) @@ -206,7 +206,7 @@ int compat_grant_table_op(unsigned int cmd, } if ( rc >= 0 ) { - XEN_GUEST_HANDLE(gnttab_transfer_compat_t) xfer; + XEN_GUEST_HANDLE_PARAM(gnttab_transfer_compat_t) xfer; xfer = guest_handle_cast(cmp_uop, gnttab_transfer_compat_t); guest_handle_add_offset(xfer, i); @@ -251,7 +251,7 @@ int compat_grant_table_op(unsigned int cmd, } if ( rc >= 0 ) { - XEN_GUEST_HANDLE(gnttab_copy_compat_t) copy; + XEN_GUEST_HANDLE_PARAM(gnttab_copy_compat_t) copy; copy = guest_handle_cast(cmp_uop, gnttab_copy_compat_t); guest_handle_add_offset(copy, i); diff --git a/xen/common/compat/memory.c b/xen/common/compat/memory.c index e7257cc..996151c 100644 --- a/xen/common/compat/memory.c +++ b/xen/common/compat/memory.c @@ -13,7 +13,7 @@ CHECK_TYPE(domid); #undef compat_domid_t #undef xen_domid_t -int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE(void) compat) +int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) compat) { int rc, split, op = cmd & MEMOP_CMD_MASK; unsigned int start_extent = cmd >> MEMOP_EXTENT_SHIFT; @@ -22,7 +22,7 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE(void) compat) { unsigned int i, end_extent = 0; union { - XEN_GUEST_HANDLE(void) hnd; + XEN_GUEST_HANDLE_PARAM(void) hnd; struct xen_memory_reservation *rsrv; struct xen_memory_exchange *xchg; struct xen_remove_from_physmap *xrfp; diff --git a/xen/common/domain.c b/xen/common/domain.c index a1aa05e..6f98b54 100644 --- a/xen/common/domain.c +++ b/xen/common/domain.c @@ -806,7 +806,7 @@ void vcpu_reset(struct vcpu *v) } -long do_vcpu_op(int cmd, int vcpuid, XEN_GUEST_HANDLE(void) arg) +long do_vcpu_op(int cmd, int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg) { struct domain *d = current->domain; struct vcpu *v; diff --git a/xen/common/domctl.c b/xen/common/domctl.c index 2b1f182..e153cb4 100644 --- a/xen/common/domctl.c +++ b/xen/common/domctl.c @@ -239,7 +239,7 @@ void domctl_lock_release(void) spin_unlock(¤t->domain->hypercall_deadlock_mutex); } -long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl) +long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) { long ret = 0; struct xen_domctl curop, *op = &curop; diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c index 53777f8..a80a0d1 100644 --- a/xen/common/event_channel.c +++ b/xen/common/event_channel.c @@ -970,7 +970,7 @@ out: } -long do_event_channel_op(int cmd, XEN_GUEST_HANDLE(void) arg) +long do_event_channel_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) { long rc; diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c index c8e342b..f4ae9ee 100644 --- a/xen/common/grant_table.c +++ b/xen/common/grant_table.c @@ -833,7 +833,7 @@ __gnttab_map_grant_ref( static long gnttab_map_grant_ref( - XEN_GUEST_HANDLE(gnttab_map_grant_ref_t) uop, unsigned int count) + XEN_GUEST_HANDLE_PARAM(gnttab_map_grant_ref_t) uop, unsigned int count) { int i; struct gnttab_map_grant_ref op; @@ -1102,7 +1102,7 @@ __gnttab_unmap_grant_ref( static long gnttab_unmap_grant_ref( - XEN_GUEST_HANDLE(gnttab_unmap_grant_ref_t) uop, unsigned int count) + XEN_GUEST_HANDLE_PARAM(gnttab_unmap_grant_ref_t) uop, unsigned int count) { int i, c, partial_done, done = 0; struct gnttab_unmap_grant_ref op; @@ -1164,7 +1164,7 @@ __gnttab_unmap_and_replace( static long gnttab_unmap_and_replace( - XEN_GUEST_HANDLE(gnttab_unmap_and_replace_t) uop, unsigned int count) + XEN_GUEST_HANDLE_PARAM(gnttab_unmap_and_replace_t) uop, unsigned int count) { int i, c, partial_done, done = 0; struct gnttab_unmap_and_replace op; @@ -1316,7 +1316,7 @@ active_alloc_failed: static long gnttab_setup_table( - XEN_GUEST_HANDLE(gnttab_setup_table_t) uop, unsigned int count) + XEN_GUEST_HANDLE_PARAM(gnttab_setup_table_t) uop, unsigned int count) { struct gnttab_setup_table op; struct domain *d; @@ -1395,7 +1395,7 @@ gnttab_setup_table( static long gnttab_query_size( - XEN_GUEST_HANDLE(gnttab_query_size_t) uop, unsigned int count) + XEN_GUEST_HANDLE_PARAM(gnttab_query_size_t) uop, unsigned int count) { struct gnttab_query_size op; struct domain *d; @@ -1517,7 +1517,7 @@ gnttab_prepare_for_transfer( static long gnttab_transfer( - XEN_GUEST_HANDLE(gnttab_transfer_t) uop, unsigned int count) + XEN_GUEST_HANDLE_PARAM(gnttab_transfer_t) uop, unsigned int count) { struct domain *d = current->domain; struct domain *e; @@ -2125,7 +2125,7 @@ __gnttab_copy( static long gnttab_copy( - XEN_GUEST_HANDLE(gnttab_copy_t) uop, unsigned int count) + XEN_GUEST_HANDLE_PARAM(gnttab_copy_t) uop, unsigned int count) { int i; struct gnttab_copy op; @@ -2144,7 +2144,7 @@ gnttab_copy( } static long -gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop)) +gnttab_set_version(XEN_GUEST_HANDLE_PARAM(gnttab_set_version_t uop)) { gnttab_set_version_t op; struct domain *d = current->domain; @@ -2263,7 +2263,7 @@ out: } static long -gnttab_get_status_frames(XEN_GUEST_HANDLE(gnttab_get_status_frames_t) uop, +gnttab_get_status_frames(XEN_GUEST_HANDLE_PARAM(gnttab_get_status_frames_t) uop, int count) { gnttab_get_status_frames_t op; @@ -2327,7 +2327,7 @@ out1: } static long -gnttab_get_version(XEN_GUEST_HANDLE(gnttab_get_version_t uop)) +gnttab_get_version(XEN_GUEST_HANDLE_PARAM(gnttab_get_version_t uop)) { gnttab_get_version_t op; struct domain *d; @@ -2412,7 +2412,7 @@ out: } static long -gnttab_swap_grant_ref(XEN_GUEST_HANDLE(gnttab_swap_grant_ref_t uop), +gnttab_swap_grant_ref(XEN_GUEST_HANDLE_PARAM(gnttab_swap_grant_ref_t uop), unsigned int count) { int i; @@ -2433,7 +2433,7 @@ gnttab_swap_grant_ref(XEN_GUEST_HANDLE(gnttab_swap_grant_ref_t uop), long do_grant_table_op( - unsigned int cmd, XEN_GUEST_HANDLE(void) uop, unsigned int count) + unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) uop, unsigned int count) { long rc; @@ -2445,7 +2445,7 @@ do_grant_table_op( { case GNTTABOP_map_grant_ref: { - XEN_GUEST_HANDLE(gnttab_map_grant_ref_t) map = + XEN_GUEST_HANDLE_PARAM(gnttab_map_grant_ref_t) map = guest_handle_cast(uop, gnttab_map_grant_ref_t); if ( unlikely(!guest_handle_okay(map, count)) ) goto out; @@ -2459,7 +2459,7 @@ do_grant_table_op( } case GNTTABOP_unmap_grant_ref: { - XEN_GUEST_HANDLE(gnttab_unmap_grant_ref_t) unmap = + XEN_GUEST_HANDLE_PARAM(gnttab_unmap_grant_ref_t) unmap = guest_handle_cast(uop, gnttab_unmap_grant_ref_t); if ( unlikely(!guest_handle_okay(unmap, count)) ) goto out; @@ -2473,7 +2473,7 @@ do_grant_table_op( } case GNTTABOP_unmap_and_replace: { - XEN_GUEST_HANDLE(gnttab_unmap_and_replace_t) unmap = + XEN_GUEST_HANDLE_PARAM(gnttab_unmap_and_replace_t) unmap = guest_handle_cast(uop, gnttab_unmap_and_replace_t); if ( unlikely(!guest_handle_okay(unmap, count)) ) goto out; @@ -2497,7 +2497,7 @@ do_grant_table_op( } case GNTTABOP_transfer: { - XEN_GUEST_HANDLE(gnttab_transfer_t) transfer = + XEN_GUEST_HANDLE_PARAM(gnttab_transfer_t) transfer = guest_handle_cast(uop, gnttab_transfer_t); if ( unlikely(!guest_handle_okay(transfer, count)) ) goto out; @@ -2511,7 +2511,7 @@ do_grant_table_op( } case GNTTABOP_copy: { - XEN_GUEST_HANDLE(gnttab_copy_t) copy = + XEN_GUEST_HANDLE_PARAM(gnttab_copy_t) copy = guest_handle_cast(uop, gnttab_copy_t); if ( unlikely(!guest_handle_okay(copy, count)) ) goto out; @@ -2548,7 +2548,7 @@ do_grant_table_op( } case GNTTABOP_swap_grant_ref: { - XEN_GUEST_HANDLE(gnttab_swap_grant_ref_t) swap = + XEN_GUEST_HANDLE_PARAM(gnttab_swap_grant_ref_t) swap = guest_handle_cast(uop, gnttab_swap_grant_ref_t); if ( unlikely(!guest_handle_okay(swap, count)) ) goto out; diff --git a/xen/common/kernel.c b/xen/common/kernel.c index c915bbc..55caff6 100644 --- a/xen/common/kernel.c +++ b/xen/common/kernel.c @@ -204,7 +204,7 @@ void __init do_initcalls(void) * Simple hypercalls. */ -DO(xen_version)(int cmd, XEN_GUEST_HANDLE(void) arg) +DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) { switch ( cmd ) { @@ -332,7 +332,7 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE(void) arg) return -ENOSYS; } -DO(nmi_op)(unsigned int cmd, XEN_GUEST_HANDLE(void) arg) +DO(nmi_op)(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) { struct xennmi_callback cb; long rc = 0; diff --git a/xen/common/kexec.c b/xen/common/kexec.c index 2bc3e33..25ebd6a 100644 --- a/xen/common/kexec.c +++ b/xen/common/kexec.c @@ -613,7 +613,7 @@ static int kexec_get_range_internal(xen_kexec_range_t *range) return ret; } -static int kexec_get_range(XEN_GUEST_HANDLE(void) uarg) +static int kexec_get_range(XEN_GUEST_HANDLE_PARAM(void) uarg) { xen_kexec_range_t range; int ret = -EINVAL; @@ -629,7 +629,7 @@ static int kexec_get_range(XEN_GUEST_HANDLE(void) uarg) return ret; } -static int kexec_get_range_compat(XEN_GUEST_HANDLE(void) uarg) +static int kexec_get_range_compat(XEN_GUEST_HANDLE_PARAM(void) uarg) { #ifdef CONFIG_COMPAT xen_kexec_range_t range; @@ -777,7 +777,7 @@ static int kexec_load_unload_internal(unsigned long op, xen_kexec_load_t *load) return ret; } -static int kexec_load_unload(unsigned long op, XEN_GUEST_HANDLE(void) uarg) +static int kexec_load_unload(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) uarg) { xen_kexec_load_t load; @@ -788,7 +788,7 @@ static int kexec_load_unload(unsigned long op, XEN_GUEST_HANDLE(void) uarg) } static int kexec_load_unload_compat(unsigned long op, - XEN_GUEST_HANDLE(void) uarg) + XEN_GUEST_HANDLE_PARAM(void) uarg) { #ifdef CONFIG_COMPAT compat_kexec_load_t compat_load; @@ -813,7 +813,7 @@ static int kexec_load_unload_compat(unsigned long op, #endif /* CONFIG_COMPAT */ } -static int kexec_exec(XEN_GUEST_HANDLE(void) uarg) +static int kexec_exec(XEN_GUEST_HANDLE_PARAM(void) uarg) { xen_kexec_exec_t exec; xen_kexec_image_t *image; @@ -845,7 +845,8 @@ static int kexec_exec(XEN_GUEST_HANDLE(void) uarg) return -EINVAL; /* never reached */ } -static int do_kexec_op_internal(unsigned long op, XEN_GUEST_HANDLE(void) uarg, +static int do_kexec_op_internal(unsigned long op, + XEN_GUEST_HANDLE_PARAM(void) uarg, bool_t compat) { unsigned long flags; @@ -886,13 +887,13 @@ static int do_kexec_op_internal(unsigned long op, XEN_GUEST_HANDLE(void) uarg, return ret; } -long do_kexec_op(unsigned long op, XEN_GUEST_HANDLE(void) uarg) +long do_kexec_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) uarg) { return do_kexec_op_internal(op, uarg, 0); } #ifdef CONFIG_COMPAT -int compat_kexec_op(unsigned long op, XEN_GUEST_HANDLE(void) uarg) +int compat_kexec_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) uarg) { return do_kexec_op_internal(op, uarg, 1); } diff --git a/xen/common/memory.c b/xen/common/memory.c index 401d06c..83e2666 100644 --- a/xen/common/memory.c +++ b/xen/common/memory.c @@ -277,7 +277,7 @@ static void decrease_reservation(struct memop_args *a) a->nr_done = i; } -static long memory_exchange(XEN_GUEST_HANDLE(xen_memory_exchange_t) arg) +static long memory_exchange(XEN_GUEST_HANDLE_PARAM(xen_memory_exchange_t) arg) { struct xen_memory_exchange exch; PAGE_LIST_HEAD(in_chunk_list); @@ -517,7 +517,7 @@ static long memory_exchange(XEN_GUEST_HANDLE(xen_memory_exchange_t) arg) return rc; } -long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE(void) arg) +long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg) { struct domain *d; int rc, op; diff --git a/xen/common/multicall.c b/xen/common/multicall.c index ca1839d..7e557e5 100644 --- a/xen/common/multicall.c +++ b/xen/common/multicall.c @@ -35,7 +35,7 @@ static void trace_multicall_call(multicall_entry_t *call) ret_t do_multicall( - XEN_GUEST_HANDLE(multicall_entry_t) call_list, unsigned int nr_calls) + XEN_GUEST_HANDLE_PARAM(multicall_entry_t) call_list, unsigned int nr_calls) { struct mc_state *mcs = ¤t->mc_state; unsigned int i; diff --git a/xen/common/schedule.c b/xen/common/schedule.c index eee74be..00812ac 100644 --- a/xen/common/schedule.c +++ b/xen/common/schedule.c @@ -836,7 +836,7 @@ typedef long ret_t; #endif /* !COMPAT */ -ret_t do_sched_op(int cmd, XEN_GUEST_HANDLE(void) arg) +ret_t do_sched_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) { ret_t ret = 0; diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c index ea68278..47142f4 100644 --- a/xen/common/sysctl.c +++ b/xen/common/sysctl.c @@ -27,7 +27,7 @@ #include #include -long do_sysctl(XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl) +long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl) { long ret = 0; struct xen_sysctl curop, *op = &curop; diff --git a/xen/common/xenoprof.c b/xen/common/xenoprof.c index 44a1fae..ae0435b 100644 --- a/xen/common/xenoprof.c +++ b/xen/common/xenoprof.c @@ -404,7 +404,7 @@ static int add_active_list(domid_t domid) return 0; } -static int add_passive_list(XEN_GUEST_HANDLE(void) arg) +static int add_passive_list(XEN_GUEST_HANDLE_PARAM(void) arg) { struct xenoprof_passive passive; struct domain *d; @@ -585,7 +585,7 @@ void xenoprof_log_event(struct vcpu *vcpu, const struct cpu_user_regs *regs, -static int xenoprof_op_init(XEN_GUEST_HANDLE(void) arg) +static int xenoprof_op_init(XEN_GUEST_HANDLE_PARAM(void) arg) { struct domain *d = current->domain; struct xenoprof_init xenoprof_init; @@ -611,7 +611,7 @@ static int xenoprof_op_init(XEN_GUEST_HANDLE(void) arg) #endif /* !COMPAT */ -static int xenoprof_op_get_buffer(XEN_GUEST_HANDLE(void) arg) +static int xenoprof_op_get_buffer(XEN_GUEST_HANDLE_PARAM(void) arg) { struct xenoprof_get_buffer xenoprof_get_buffer; struct domain *d = current->domain; @@ -662,7 +662,7 @@ static int xenoprof_op_get_buffer(XEN_GUEST_HANDLE(void) arg) || (op == XENOPROF_disable_virq) \ || (op == XENOPROF_get_buffer)) -ret_t do_xenoprof_op(int op, XEN_GUEST_HANDLE(void) arg) +ret_t do_xenoprof_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg) { int ret = 0; diff --git a/xen/drivers/acpi/pmstat.c b/xen/drivers/acpi/pmstat.c index 6f266ef..bf30cc7 100644 --- a/xen/drivers/acpi/pmstat.c +++ b/xen/drivers/acpi/pmstat.c @@ -496,7 +496,7 @@ int do_pm_op(struct xen_sysctl_pm_op *op) return ret; } -int acpi_set_pdc_bits(u32 acpi_id, XEN_GUEST_HANDLE(uint32) pdc) +int acpi_set_pdc_bits(u32 acpi_id, XEN_GUEST_HANDLE_PARAM(uint32) pdc) { u32 bits[3]; int ret; diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c index 9e1adb5..ff360fe 100644 --- a/xen/drivers/char/console.c +++ b/xen/drivers/char/console.c @@ -182,7 +182,7 @@ static void putchar_console_ring(int c) long read_console_ring(struct xen_sysctl_readconsole *op) { - XEN_GUEST_HANDLE(char) str; + XEN_GUEST_HANDLE_PARAM(char) str; uint32_t idx, len, max, sofar, c; str = guest_handle_cast(op->buffer, char), @@ -363,7 +363,7 @@ static void notify_dom0_con_ring(unsigned long unused) static DECLARE_SOFTIRQ_TASKLET(notify_dom0_con_ring_tasklet, notify_dom0_con_ring, 0); -static long guest_console_write(XEN_GUEST_HANDLE(char) buffer, int count) +static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, int count) { char kbuf[128], *kptr; int kcount; @@ -401,7 +401,7 @@ static long guest_console_write(XEN_GUEST_HANDLE(char) buffer, int count) return 0; } -long do_console_io(int cmd, int count, XEN_GUEST_HANDLE(char) buffer) +long do_console_io(int cmd, int count, XEN_GUEST_HANDLE_PARAM(char) buffer) { long rc; unsigned int idx, len; diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c index b4cf16c..4b5f8b7 100644 --- a/xen/drivers/passthrough/iommu.c +++ b/xen/drivers/passthrough/iommu.c @@ -527,7 +527,7 @@ void iommu_crash_shutdown(void) int iommu_do_domctl( struct xen_domctl *domctl, - XEN_GUEST_HANDLE(xen_domctl_t) u_domctl) + XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) { struct domain *d; u16 seg; diff --git a/xen/include/asm-arm/hypercall.h b/xen/include/asm-arm/hypercall.h index 454f02e..090e620 100644 --- a/xen/include/asm-arm/hypercall.h +++ b/xen/include/asm-arm/hypercall.h @@ -2,7 +2,7 @@ #define __ASM_ARM_HYPERCALL_H__ #include /* for arch_do_domctl */ -int do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg); +int do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg); #endif /* __ASM_ARM_HYPERCALL_H__ */ /* diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h index b37bd35..8bf45ba 100644 --- a/xen/include/asm-arm/mm.h +++ b/xen/include/asm-arm/mm.h @@ -267,7 +267,7 @@ static inline int relinquish_shared_pages(struct domain *d) /* Arch-specific portion of memory_op hypercall. */ -long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg); +long arch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg); int steal_page( struct domain *d, struct page_info *page, unsigned int memflags); diff --git a/xen/include/asm-x86/hap.h b/xen/include/asm-x86/hap.h index a2532a4..916a35b 100644 --- a/xen/include/asm-x86/hap.h +++ b/xen/include/asm-x86/hap.h @@ -51,7 +51,7 @@ hap_unmap_domain_page(void *p) /************************************************/ void hap_domain_init(struct domain *d); int hap_domctl(struct domain *d, xen_domctl_shadow_op_t *sc, - XEN_GUEST_HANDLE(void) u_domctl); + XEN_GUEST_HANDLE_PARAM(void) u_domctl); int hap_enable(struct domain *d, u32 mode); void hap_final_teardown(struct domain *d); void hap_teardown(struct domain *d); diff --git a/xen/include/asm-x86/hypercall.h b/xen/include/asm-x86/hypercall.h index a9af426..bd14220 100644 --- a/xen/include/asm-x86/hypercall.h +++ b/xen/include/asm-x86/hypercall.h @@ -18,22 +18,22 @@ extern long do_event_channel_op_compat( - XEN_GUEST_HANDLE(evtchn_op_t) uop); + XEN_GUEST_HANDLE_PARAM(evtchn_op_t) uop); extern long do_set_trap_table( - XEN_GUEST_HANDLE(const_trap_info_t) traps); + XEN_GUEST_HANDLE_PARAM(const_trap_info_t) traps); extern long do_mmu_update( - XEN_GUEST_HANDLE(mmu_update_t) ureqs, + XEN_GUEST_HANDLE_PARAM(mmu_update_t) ureqs, unsigned int count, - XEN_GUEST_HANDLE(uint) pdone, + XEN_GUEST_HANDLE_PARAM(uint) pdone, unsigned int foreigndom); extern long do_set_gdt( - XEN_GUEST_HANDLE(ulong) frame_list, + XEN_GUEST_HANDLE_PARAM(ulong) frame_list, unsigned int entries); extern long @@ -60,7 +60,7 @@ do_update_descriptor( u64 desc); extern long -do_mca(XEN_GUEST_HANDLE(xen_mc_t) u_xen_mc); +do_mca(XEN_GUEST_HANDLE_PARAM(xen_mc_t) u_xen_mc); extern long do_update_va_mapping( @@ -70,7 +70,7 @@ do_update_va_mapping( extern long do_physdev_op( - int cmd, XEN_GUEST_HANDLE(void) arg); + int cmd, XEN_GUEST_HANDLE_PARAM(void) arg); extern long do_update_va_mapping_otherdomain( @@ -81,9 +81,9 @@ do_update_va_mapping_otherdomain( extern long do_mmuext_op( - XEN_GUEST_HANDLE(mmuext_op_t) uops, + XEN_GUEST_HANDLE_PARAM(mmuext_op_t) uops, unsigned int count, - XEN_GUEST_HANDLE(uint) pdone, + XEN_GUEST_HANDLE_PARAM(uint) pdone, unsigned int foreigndom); extern unsigned long @@ -104,10 +104,10 @@ do_set_segment_base( extern int compat_physdev_op( int cmd, - XEN_GUEST_HANDLE(void) arg); + XEN_GUEST_HANDLE_PARAM(void) arg); extern int arch_compat_vcpu_op( - int cmd, struct vcpu *v, XEN_GUEST_HANDLE(void) arg); + int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg); #endif /* __ASM_X86_HYPERCALL_H__ */ diff --git a/xen/include/asm-x86/mem_event.h b/xen/include/asm-x86/mem_event.h index 23d71c1..e17f36b 100644 --- a/xen/include/asm-x86/mem_event.h +++ b/xen/include/asm-x86/mem_event.h @@ -65,7 +65,7 @@ int mem_event_get_response(struct domain *d, struct mem_event_domain *med, struct domain *get_mem_event_op_target(uint32_t domain, int *rc); int do_mem_event_op(int op, uint32_t domain, void *arg); int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec, - XEN_GUEST_HANDLE(void) u_domctl); + XEN_GUEST_HANDLE_PARAM(void) u_domctl); #endif /* __MEM_EVENT_H__ */ diff --git a/xen/include/asm-x86/mm.h b/xen/include/asm-x86/mm.h index 6e1e57c..494dad8 100644 --- a/xen/include/asm-x86/mm.h +++ b/xen/include/asm-x86/mm.h @@ -555,10 +555,10 @@ void *do_page_walk(struct vcpu *v, unsigned long addr); int __sync_local_execstate(void); /* Arch-specific portion of memory_op hypercall. */ -long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg); -long subarch_memory_op(int op, XEN_GUEST_HANDLE(void) arg); -int compat_arch_memory_op(int op, XEN_GUEST_HANDLE(void)); -int compat_subarch_memory_op(int op, XEN_GUEST_HANDLE(void)); +long arch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg); +long subarch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg); +int compat_arch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void)); +int compat_subarch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void)); int steal_page( struct domain *d, struct page_info *page, unsigned int memflags); diff --git a/xen/include/asm-x86/paging.h b/xen/include/asm-x86/paging.h index d9b6950..9a40f2c 100644 --- a/xen/include/asm-x86/paging.h +++ b/xen/include/asm-x86/paging.h @@ -207,7 +207,7 @@ int paging_domain_init(struct domain *d, unsigned int domcr_flags); * and disable ephemeral shadow modes (test mode and log-dirty mode) and * manipulate the log-dirty bitmap. */ int paging_domctl(struct domain *d, xen_domctl_shadow_op_t *sc, - XEN_GUEST_HANDLE(void) u_domctl); + XEN_GUEST_HANDLE_PARAM(void) u_domctl); /* Call when destroying a domain */ void paging_teardown(struct domain *d); diff --git a/xen/include/asm-x86/processor.h b/xen/include/asm-x86/processor.h index c969b11..637cea3 100644 --- a/xen/include/asm-x86/processor.h +++ b/xen/include/asm-x86/processor.h @@ -549,7 +549,7 @@ int rdmsr_hypervisor_regs(uint32_t idx, uint64_t *val); int wrmsr_hypervisor_regs(uint32_t idx, uint64_t val); void microcode_set_module(unsigned int); -int microcode_update(XEN_GUEST_HANDLE(const_void), unsigned long len); +int microcode_update(XEN_GUEST_HANDLE_PARAM(const_void), unsigned long len); int microcode_resume_cpu(int cpu); #endif /* !__ASSEMBLY__ */ diff --git a/xen/include/asm-x86/shadow.h b/xen/include/asm-x86/shadow.h index 88a8cd2..2eb6efc 100644 --- a/xen/include/asm-x86/shadow.h +++ b/xen/include/asm-x86/shadow.h @@ -73,7 +73,7 @@ int shadow_track_dirty_vram(struct domain *d, * manipulate the log-dirty bitmap. */ int shadow_domctl(struct domain *d, xen_domctl_shadow_op_t *sc, - XEN_GUEST_HANDLE(void) u_domctl); + XEN_GUEST_HANDLE_PARAM(void) u_domctl); /* Call when destroying a domain */ void shadow_teardown(struct domain *d); diff --git a/xen/include/asm-x86/xenoprof.h b/xen/include/asm-x86/xenoprof.h index a71f020..52a6881 100644 --- a/xen/include/asm-x86/xenoprof.h +++ b/xen/include/asm-x86/xenoprof.h @@ -40,9 +40,9 @@ int xenoprof_arch_init(int *num_events, char *cpu_type); #define xenoprof_arch_disable_virq() nmi_disable_virq() #define xenoprof_arch_release_counters() nmi_release_counters() -int xenoprof_arch_counter(XEN_GUEST_HANDLE(void) arg); -int compat_oprof_arch_counter(XEN_GUEST_HANDLE(void) arg); -int xenoprof_arch_ibs_counter(XEN_GUEST_HANDLE(void) arg); +int xenoprof_arch_counter(XEN_GUEST_HANDLE_PARAM(void) arg); +int compat_oprof_arch_counter(XEN_GUEST_HANDLE_PARAM(void) arg); +int xenoprof_arch_ibs_counter(XEN_GUEST_HANDLE_PARAM(void) arg); struct vcpu; struct cpu_user_regs; diff --git a/xen/include/public/tmem.h b/xen/include/public/tmem.h index 74bd1c6..7bd29ba 100644 --- a/xen/include/public/tmem.h +++ b/xen/include/public/tmem.h @@ -96,7 +96,7 @@ #ifndef __ASSEMBLY__ typedef xen_pfn_t tmem_cli_mfn_t; -typedef XEN_GUEST_HANDLE(char) tmem_cli_va_t; +typedef XEN_GUEST_HANDLE_PARAM(char) tmem_cli_va_t; struct tmem_op { uint32_t cmd; int32_t pool_id; diff --git a/xen/include/xen/acpi.h b/xen/include/xen/acpi.h index d7e2f94..8f3cdca 100644 --- a/xen/include/xen/acpi.h +++ b/xen/include/xen/acpi.h @@ -145,8 +145,8 @@ static inline unsigned int acpi_get_cstate_limit(void) { return 0; } static inline void acpi_set_cstate_limit(unsigned int new_limit) { return; } #endif -#ifdef XEN_GUEST_HANDLE -int acpi_set_pdc_bits(u32 acpi_id, XEN_GUEST_HANDLE(uint32)); +#ifdef XEN_GUEST_HANDLE_PARAM +int acpi_set_pdc_bits(u32 acpi_id, XEN_GUEST_HANDLE_PARAM(uint32)); #endif int arch_acpi_set_pdc_bits(u32 acpi_id, u32 *, u32 mask); diff --git a/xen/include/xen/hypercall.h b/xen/include/xen/hypercall.h index 1b71071..e315523 100644 --- a/xen/include/xen/hypercall.h +++ b/xen/include/xen/hypercall.h @@ -29,29 +29,29 @@ do_sched_op_compat( extern long do_sched_op( int cmd, - XEN_GUEST_HANDLE(void) arg); + XEN_GUEST_HANDLE_PARAM(void) arg); extern long do_domctl( - XEN_GUEST_HANDLE(xen_domctl_t) u_domctl); + XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl); extern long arch_do_domctl( struct xen_domctl *domctl, - XEN_GUEST_HANDLE(xen_domctl_t) u_domctl); + XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl); extern long do_sysctl( - XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl); + XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl); extern long arch_do_sysctl( struct xen_sysctl *sysctl, - XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl); + XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl); extern long do_platform_op( - XEN_GUEST_HANDLE(xen_platform_op_t) u_xenpf_op); + XEN_GUEST_HANDLE_PARAM(xen_platform_op_t) u_xenpf_op); /* * To allow safe resume of do_memory_op() after preemption, we need to know @@ -64,11 +64,11 @@ do_platform_op( extern long do_memory_op( unsigned long cmd, - XEN_GUEST_HANDLE(void) arg); + XEN_GUEST_HANDLE_PARAM(void) arg); extern long do_multicall( - XEN_GUEST_HANDLE(multicall_entry_t) call_list, + XEN_GUEST_HANDLE_PARAM(multicall_entry_t) call_list, unsigned int nr_calls); extern long @@ -77,23 +77,23 @@ do_set_timer_op( extern long do_event_channel_op( - int cmd, XEN_GUEST_HANDLE(void) arg); + int cmd, XEN_GUEST_HANDLE_PARAM(void) arg); extern long do_xen_version( int cmd, - XEN_GUEST_HANDLE(void) arg); + XEN_GUEST_HANDLE_PARAM(void) arg); extern long do_console_io( int cmd, int count, - XEN_GUEST_HANDLE(char) buffer); + XEN_GUEST_HANDLE_PARAM(char) buffer); extern long do_grant_table_op( unsigned int cmd, - XEN_GUEST_HANDLE(void) uop, + XEN_GUEST_HANDLE_PARAM(void) uop, unsigned int count); extern long @@ -105,72 +105,72 @@ extern long do_vcpu_op( int cmd, int vcpuid, - XEN_GUEST_HANDLE(void) arg); + XEN_GUEST_HANDLE_PARAM(void) arg); struct vcpu; extern long arch_do_vcpu_op(int cmd, struct vcpu *v, - XEN_GUEST_HANDLE(void) arg); + XEN_GUEST_HANDLE_PARAM(void) arg); extern long do_nmi_op( unsigned int cmd, - XEN_GUEST_HANDLE(void) arg); + XEN_GUEST_HANDLE_PARAM(void) arg); extern long do_hvm_op( unsigned long op, - XEN_GUEST_HANDLE(void) arg); + XEN_GUEST_HANDLE_PARAM(void) arg); extern long do_kexec_op( unsigned long op, int arg1, - XEN_GUEST_HANDLE(void) arg); + XEN_GUEST_HANDLE_PARAM(void) arg); extern long do_xsm_op( - XEN_GUEST_HANDLE(xsm_op_t) u_xsm_op); + XEN_GUEST_HANDLE_PARAM(xsm_op_t) u_xsm_op); extern long do_tmem_op( - XEN_GUEST_HANDLE(tmem_op_t) uops); + XEN_GUEST_HANDLE_PARAM(tmem_op_t) uops); extern long -do_xenoprof_op(int op, XEN_GUEST_HANDLE(void) arg); +do_xenoprof_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg); #ifdef CONFIG_COMPAT extern int compat_memory_op( unsigned int cmd, - XEN_GUEST_HANDLE(void) arg); + XEN_GUEST_HANDLE_PARAM(void) arg); extern int compat_grant_table_op( unsigned int cmd, - XEN_GUEST_HANDLE(void) uop, + XEN_GUEST_HANDLE_PARAM(void) uop, unsigned int count); extern int compat_vcpu_op( int cmd, int vcpuid, - XEN_GUEST_HANDLE(void) arg); + XEN_GUEST_HANDLE_PARAM(void) arg); extern int -compat_xenoprof_op(int op, XEN_GUEST_HANDLE(void) arg); +compat_xenoprof_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg); extern int compat_xen_version( int cmd, - XEN_GUEST_HANDLE(void) arg); + XEN_GUEST_HANDLE_PARAM(void) arg); extern int compat_sched_op( int cmd, - XEN_GUEST_HANDLE(void) arg); + XEN_GUEST_HANDLE_PARAM(void) arg); extern int compat_set_timer_op( diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h index 605c7b3..773a6d7 100644 --- a/xen/include/xen/iommu.h +++ b/xen/include/xen/iommu.h @@ -156,7 +156,7 @@ void iommu_crash_shutdown(void); void iommu_set_dom0_mapping(struct domain *d); void iommu_share_p2m_table(struct domain *d); -int iommu_do_domctl(struct xen_domctl *, XEN_GUEST_HANDLE(xen_domctl_t)); +int iommu_do_domctl(struct xen_domctl *, XEN_GUEST_HANDLE_PARAM(xen_domctl_t)); void iommu_iotlb_flush(struct domain *d, unsigned long gfn, unsigned int page_count); void iommu_iotlb_flush_all(struct domain *d); diff --git a/xen/include/xen/tmem_xen.h b/xen/include/xen/tmem_xen.h index 9492810..c31220a 100644 --- a/xen/include/xen/tmem_xen.h +++ b/xen/include/xen/tmem_xen.h @@ -430,7 +430,7 @@ static inline void tmh_tze_copy_from_pfp(void *tva, pfp_t *pfp, pagesize_t len) typedef XEN_GUEST_HANDLE(void) cli_mfn_t; typedef XEN_GUEST_HANDLE(char) cli_va_t; */ -typedef XEN_GUEST_HANDLE(tmem_op_t) tmem_cli_op_t; +typedef XEN_GUEST_HANDLE_PARAM(tmem_op_t) tmem_cli_op_t; static inline int tmh_get_tmemop_from_client(tmem_op_t *op, tmem_cli_op_t uops) { diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h index 593cdbd..a949c1e 100644 --- a/xen/include/xsm/xsm.h +++ b/xen/include/xsm/xsm.h @@ -139,7 +139,7 @@ struct xsm_operations { int (*cpupool_op)(void); int (*sched_op)(void); - long (*__do_xsm_op) (XEN_GUEST_HANDLE(xsm_op_t) op); + long (*__do_xsm_op) (XEN_GUEST_HANDLE_PARAM(xsm_op_t) op); #ifdef CONFIG_X86 int (*shadow_control) (struct domain *d, uint32_t op); @@ -585,7 +585,7 @@ static inline int xsm_sched_op(void) return xsm_call(sched_op()); } -static inline long __do_xsm_op (XEN_GUEST_HANDLE(xsm_op_t) op) +static inline long __do_xsm_op (XEN_GUEST_HANDLE_PARAM(xsm_op_t) op) { #ifdef XSM_ENABLE return xsm_ops->__do_xsm_op(op); diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c index 4836fc0..b726eaf6 100644 --- a/xen/xsm/dummy.c +++ b/xen/xsm/dummy.c @@ -380,7 +380,7 @@ static int dummy_sched_op (void) return 0; } -static long dummy___do_xsm_op(XEN_GUEST_HANDLE(xsm_op_t) op) +static long dummy___do_xsm_op(XEN_GUEST_HANDLE_PARAM(xsm_op_t) op) { return -ENOSYS; } diff --git a/xen/xsm/flask/flask_op.c b/xen/xsm/flask/flask_op.c index 9c8dfe7..a5d7748 100644 --- a/xen/xsm/flask/flask_op.c +++ b/xen/xsm/flask/flask_op.c @@ -71,7 +71,7 @@ static int domain_has_security(struct domain *d, u32 perms) perms, NULL); } -static int flask_copyin_string(XEN_GUEST_HANDLE(char) u_buf, char **buf, uint32_t size) +static int flask_copyin_string(XEN_GUEST_HANDLE_PARAM(char) u_buf, char **buf, uint32_t size) { char *tmp = xmalloc_bytes(size + 1); if ( !tmp ) @@ -618,7 +618,7 @@ static int flask_relabel_domain(struct xen_flask_relabel *arg) return rc; } -long do_flask_op(XEN_GUEST_HANDLE(xsm_op_t) u_flask_op) +long do_flask_op(XEN_GUEST_HANDLE_PARAM(xsm_op_t) u_flask_op) { xen_flask_op_t op; int rv; diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c index 88fef9c..0ca10d0 100644 --- a/xen/xsm/flask/hooks.c +++ b/xen/xsm/flask/hooks.c @@ -1462,7 +1462,7 @@ static int flask_vcpuextstate (struct domain *d, uint32_t cmd) } #endif -long do_flask_op(XEN_GUEST_HANDLE(xsm_op_t) u_flask_op); +long do_flask_op(XEN_GUEST_HANDLE_PARAM(xsm_op_t) u_flask_op); static struct xsm_operations flask_ops = { .security_domaininfo = flask_security_domaininfo, diff --git a/xen/xsm/xsm_core.c b/xen/xsm/xsm_core.c index 96c8669..46287cb 100644 --- a/xen/xsm/xsm_core.c +++ b/xen/xsm/xsm_core.c @@ -111,7 +111,7 @@ int unregister_xsm(struct xsm_operations *ops) #endif -long do_xsm_op (XEN_GUEST_HANDLE(xsm_op_t) op) +long do_xsm_op (XEN_GUEST_HANDLE_PARAM(xsm_op_t) op) { return __do_xsm_op(op); } -- 1.7.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 10:52:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 10:52:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5W5-0002w1-1C; Fri, 05 Oct 2012 10:52:25 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5W3-0002uH-I8 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 10:52:23 +0000 Received: from [85.158.143.35:42958] by server-1.bemta-4.messagelabs.com id 64/88-05684-6EBBE605; Fri, 05 Oct 2012 10:52:22 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1349434338!13467105!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODA1MjM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6496 invoked from network); 5 Oct 2012 10:52:19 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 10:52:19 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="210397087" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 10:52:19 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 06:52:19 -0400 Received: from [10.80.246.74] (helo=army.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK5Ia-0003Rm-VF; Fri, 05 Oct 2012 11:38:28 +0100 From: Ian Campbell To: Date: Fri, 5 Oct 2012 10:38:17 +0000 Message-ID: <1349433507-21148-11-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.9.1 In-Reply-To: <1349433418.20946.46.camel@zakaz.uk.xensource.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Stefano Stabellini , tim@xen.org, stefano.stabelini@citrix.com Subject: [Xen-devel] [PATCH 11/21] xen/arm: protect LR registers and lr_mask changes with spin_lock_irq X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Stefano Stabellini GICH_LR registers and lr_mask need to be kept in sync: make sure that their modifications are protected by spin_lock_irq(&gic.lock). Signed-off-by: Stefano Stabellini Acked-by: Ian Campbell --- xen/arch/arm/gic.c | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c index 6f5b0e1..ab93404 100644 --- a/xen/arch/arm/gic.c +++ b/xen/arch/arm/gic.c @@ -57,9 +57,11 @@ void gic_save_state(struct vcpu *v) { int i; + spin_lock_irq(&gic.lock); for ( i=0; iarch.gic_lr[i] = GICH[GICH_LR + i]; v->arch.lr_mask = gic.lr_mask; + spin_unlock_irq(&gic.lock); /* Disable until next VCPU scheduled */ GICH[GICH_HCR] = 0; isb(); @@ -72,9 +74,11 @@ void gic_restore_state(struct vcpu *v) if ( is_idle_vcpu(v) ) return; + spin_lock_irq(&gic.lock); gic.lr_mask = v->arch.lr_mask; for ( i=0; iarch.gic_lr[i]; + spin_unlock_irq(&gic.lock); GICH[GICH_HCR] = GICH_HCR_EN; isb(); @@ -469,9 +473,11 @@ static void gic_restore_pending_irqs(struct vcpu *v) i = find_first_zero_bit(&gic.lr_mask, nr_lrs); if ( i >= nr_lrs ) return; + spin_lock_irq(&gic.lock); gic_set_lr(i, p->irq, GICH_LR_PENDING, p->priority); list_del_init(&p->lr_queue); set_bit(i, &gic.lr_mask); + spin_unlock_irq(&gic.lock); } } -- 1.7.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 10:52:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 10:52:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5W3-0002vD-Va; Fri, 05 Oct 2012 10:52:23 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5W2-0002tw-8s for xen-devel@lists.xen.org; Fri, 05 Oct 2012 10:52:22 +0000 Received: from [85.158.143.99:18531] by server-3.bemta-4.messagelabs.com id 5E/66-10986-5EBBE605; Fri, 05 Oct 2012 10:52:21 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1349434338!24861283!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODA1MjM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26702 invoked from network); 5 Oct 2012 10:52:19 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 10:52:19 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="210397084" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 10:52:18 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 06:52:17 -0400 Received: from [10.80.246.74] (helo=army.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK5Ib-0003Rm-Re; Fri, 05 Oct 2012 11:38:29 +0100 From: Ian Campbell To: Date: Fri, 5 Oct 2012 10:38:26 +0000 Message-ID: <1349433507-21148-20-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.9.1 In-Reply-To: <1349433418.20946.46.camel@zakaz.uk.xensource.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: keir@xen.org, Stefano Stabellini , tim@xen.org, JBeulich@suse.com, stefano.stabelini@citrix.com Subject: [Xen-devel] [PATCH 20/21] xen: replace XEN_GUEST_HANDLE with XEN_GUEST_HANDLE_PARAM when appropriate X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Stefano Stabellini Note: these changes don't make any difference on x86 and ia64. Replace XEN_GUEST_HANDLE with XEN_GUEST_HANDLE_PARAM when it is used as an hypercall argument. Signed-off-by: Stefano Stabellini Cc: keir@xen.org Cc: JBeulich@suse.com --- xen/arch/arm/domain.c | 2 +- xen/arch/arm/domctl.c | 2 +- xen/arch/arm/hvm.c | 2 +- xen/arch/arm/mm.c | 2 +- xen/arch/arm/physdev.c | 2 +- xen/arch/arm/sysctl.c | 2 +- xen/arch/x86/compat.c | 2 +- xen/arch/x86/cpu/mcheck/mce.c | 2 +- xen/arch/x86/domain.c | 2 +- xen/arch/x86/domctl.c | 2 +- xen/arch/x86/efi/runtime.c | 2 +- xen/arch/x86/hvm/hvm.c | 26 +++++++++--------- xen/arch/x86/microcode.c | 2 +- xen/arch/x86/mm.c | 14 +++++----- xen/arch/x86/mm/hap/hap.c | 2 +- xen/arch/x86/mm/mem_event.c | 2 +- xen/arch/x86/mm/paging.c | 2 +- xen/arch/x86/mm/shadow/common.c | 2 +- xen/arch/x86/oprofile/xenoprof.c | 6 ++-- xen/arch/x86/physdev.c | 2 +- xen/arch/x86/platform_hypercall.c | 2 +- xen/arch/x86/sysctl.c | 2 +- xen/arch/x86/traps.c | 2 +- xen/arch/x86/x86_64/compat/mm.c | 10 +++--- xen/arch/x86/x86_64/domain.c | 2 +- xen/arch/x86/x86_64/mm.c | 2 +- xen/arch/x86/x86_64/traps.c | 2 +- xen/common/compat/domain.c | 2 +- xen/common/compat/grant_table.c | 8 +++--- xen/common/compat/memory.c | 4 +- xen/common/domain.c | 2 +- xen/common/domctl.c | 2 +- xen/common/event_channel.c | 2 +- xen/common/grant_table.c | 36 +++++++++++++------------- xen/common/kernel.c | 4 +- xen/common/kexec.c | 17 ++++++----- xen/common/memory.c | 4 +- xen/common/multicall.c | 2 +- xen/common/schedule.c | 2 +- xen/common/sysctl.c | 2 +- xen/common/xenoprof.c | 8 +++--- xen/drivers/acpi/pmstat.c | 2 +- xen/drivers/char/console.c | 6 ++-- xen/drivers/passthrough/iommu.c | 2 +- xen/include/asm-arm/hypercall.h | 2 +- xen/include/asm-arm/mm.h | 2 +- xen/include/asm-x86/hap.h | 2 +- xen/include/asm-x86/hypercall.h | 22 ++++++++-------- xen/include/asm-x86/mem_event.h | 2 +- xen/include/asm-x86/mm.h | 8 +++--- xen/include/asm-x86/paging.h | 2 +- xen/include/asm-x86/processor.h | 2 +- xen/include/asm-x86/shadow.h | 2 +- xen/include/asm-x86/xenoprof.h | 6 ++-- xen/include/public/tmem.h | 2 +- xen/include/xen/acpi.h | 4 +- xen/include/xen/hypercall.h | 52 ++++++++++++++++++------------------ xen/include/xen/iommu.h | 2 +- xen/include/xen/tmem_xen.h | 2 +- xen/include/xsm/xsm.h | 4 +- xen/xsm/dummy.c | 2 +- xen/xsm/flask/flask_op.c | 4 +- xen/xsm/flask/hooks.c | 2 +- xen/xsm/xsm_core.c | 2 +- 64 files changed, 167 insertions(+), 166 deletions(-) diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c index f47db4f..c5292c7 100644 --- a/xen/arch/arm/domain.c +++ b/xen/arch/arm/domain.c @@ -519,7 +519,7 @@ void arch_dump_domain_info(struct domain *d) { } -long arch_do_vcpu_op(int cmd, struct vcpu *v, XEN_GUEST_HANDLE(void) arg) +long arch_do_vcpu_op(int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg) { return -ENOSYS; } diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c index 1a5f79f..cf16791 100644 --- a/xen/arch/arm/domctl.c +++ b/xen/arch/arm/domctl.c @@ -11,7 +11,7 @@ #include long arch_do_domctl(struct xen_domctl *domctl, - XEN_GUEST_HANDLE(xen_domctl_t) u_domctl) + XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) { return -ENOSYS; } diff --git a/xen/arch/arm/hvm.c b/xen/arch/arm/hvm.c index c11378d..40f519e 100644 --- a/xen/arch/arm/hvm.c +++ b/xen/arch/arm/hvm.c @@ -11,7 +11,7 @@ #include -long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg) +long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg) { long rc = 0; diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c index bf9b6c5..49102db 100644 --- a/xen/arch/arm/mm.c +++ b/xen/arch/arm/mm.c @@ -581,7 +581,7 @@ out: } -long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg) +long arch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg) { int rc; diff --git a/xen/arch/arm/physdev.c b/xen/arch/arm/physdev.c index bcf4337..0801e8c 100644 --- a/xen/arch/arm/physdev.c +++ b/xen/arch/arm/physdev.c @@ -11,7 +11,7 @@ #include -int do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg) +int do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) { printk("%s %d cmd=%d: not implemented yet\n", __func__, __LINE__, cmd); return -ENOSYS; diff --git a/xen/arch/arm/sysctl.c b/xen/arch/arm/sysctl.c index e8e1c0d..a286abe 100644 --- a/xen/arch/arm/sysctl.c +++ b/xen/arch/arm/sysctl.c @@ -13,7 +13,7 @@ #include long arch_do_sysctl(struct xen_sysctl *sysctl, - XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl) + XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl) { return -ENOSYS; } diff --git a/xen/arch/x86/compat.c b/xen/arch/x86/compat.c index a4fda06..2d05867 100644 --- a/xen/arch/x86/compat.c +++ b/xen/arch/x86/compat.c @@ -27,7 +27,7 @@ ret_t do_physdev_op_compat(XEN_GUEST_HANDLE(physdev_op_t) uop) #ifndef COMPAT /* Legacy hypercall (as of 0x00030202). */ -long do_event_channel_op_compat(XEN_GUEST_HANDLE(evtchn_op_t) uop) +long do_event_channel_op_compat(XEN_GUEST_HANDLE_PARAM(evtchn_op_t) uop) { struct evtchn_op op; diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c index 5f03394..06dddee 100644 --- a/xen/arch/x86/cpu/mcheck/mce.c +++ b/xen/arch/x86/cpu/mcheck/mce.c @@ -1288,7 +1288,7 @@ CHECK_mcinfo_recovery; # undef xen_mcinfo_recovery /* Machine Check Architecture Hypercall */ -long do_mca(XEN_GUEST_HANDLE(xen_mc_t) u_xen_mc) +long do_mca(XEN_GUEST_HANDLE_PARAM(xen_mc_t) u_xen_mc) { long ret = 0; struct xen_mc curop, *op = &curop; diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index 58766ba..233c597 100644 --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -1077,7 +1077,7 @@ map_vcpu_info(struct vcpu *v, unsigned long gfn, unsigned offset) long arch_do_vcpu_op( - int cmd, struct vcpu *v, XEN_GUEST_HANDLE(void) arg) + int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg) { long rc = 0; diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c index 24b3178..c3d6093 100644 --- a/xen/arch/x86/domctl.c +++ b/xen/arch/x86/domctl.c @@ -48,7 +48,7 @@ static int gdbsx_guest_mem_io( long arch_do_domctl( struct xen_domctl *domctl, - XEN_GUEST_HANDLE(xen_domctl_t) u_domctl) + XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) { long ret = 0; diff --git a/xen/arch/x86/efi/runtime.c b/xen/arch/x86/efi/runtime.c index 1dbe2db..b2ff495 100644 --- a/xen/arch/x86/efi/runtime.c +++ b/xen/arch/x86/efi/runtime.c @@ -184,7 +184,7 @@ int efi_get_info(uint32_t idx, union xenpf_efi_info *info) return 0; } -static long gwstrlen(XEN_GUEST_HANDLE(CHAR16) str) +static long gwstrlen(XEN_GUEST_HANDLE_PARAM(CHAR16) str) { unsigned long len; diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index a5a1bcf..b83e336 100644 --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -3091,14 +3091,14 @@ static int grant_table_op_is_allowed(unsigned int cmd) } static long hvm_grant_table_op( - unsigned int cmd, XEN_GUEST_HANDLE(void) uop, unsigned int count) + unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) uop, unsigned int count) { if ( !grant_table_op_is_allowed(cmd) ) return -ENOSYS; /* all other commands need auditing */ return do_grant_table_op(cmd, uop, count); } -static long hvm_memory_op(int cmd, XEN_GUEST_HANDLE(void) arg) +static long hvm_memory_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) { long rc; @@ -3116,7 +3116,7 @@ static long hvm_memory_op(int cmd, XEN_GUEST_HANDLE(void) arg) return do_memory_op(cmd, arg); } -static long hvm_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg) +static long hvm_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) { switch ( cmd ) { @@ -3132,7 +3132,7 @@ static long hvm_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg) } static long hvm_vcpu_op( - int cmd, int vcpuid, XEN_GUEST_HANDLE(void) arg) + int cmd, int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg) { long rc; @@ -3163,7 +3163,7 @@ typedef unsigned long hvm_hypercall_t( [ __HYPERVISOR_ ## x ] = (hvm_hypercall_t *) do_ ## x static long hvm_grant_table_op_compat32(unsigned int cmd, - XEN_GUEST_HANDLE(void) uop, + XEN_GUEST_HANDLE_PARAM(void) uop, unsigned int count) { if ( !grant_table_op_is_allowed(cmd) ) @@ -3171,7 +3171,7 @@ static long hvm_grant_table_op_compat32(unsigned int cmd, return compat_grant_table_op(cmd, uop, count); } -static long hvm_memory_op_compat32(int cmd, XEN_GUEST_HANDLE(void) arg) +static long hvm_memory_op_compat32(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) { int rc; @@ -3190,7 +3190,7 @@ static long hvm_memory_op_compat32(int cmd, XEN_GUEST_HANDLE(void) arg) } static long hvm_vcpu_op_compat32( - int cmd, int vcpuid, XEN_GUEST_HANDLE(void) arg) + int cmd, int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg) { long rc; @@ -3214,7 +3214,7 @@ static long hvm_vcpu_op_compat32( } static long hvm_physdev_op_compat32( - int cmd, XEN_GUEST_HANDLE(void) arg) + int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) { switch ( cmd ) { @@ -3380,7 +3380,7 @@ void hvm_hypercall_page_initialise(struct domain *d, } static int hvmop_set_pci_intx_level( - XEN_GUEST_HANDLE(xen_hvm_set_pci_intx_level_t) uop) + XEN_GUEST_HANDLE_PARAM(xen_hvm_set_pci_intx_level_t) uop) { struct xen_hvm_set_pci_intx_level op; struct domain *d; @@ -3547,7 +3547,7 @@ static void hvm_s3_resume(struct domain *d) } static int hvmop_set_isa_irq_level( - XEN_GUEST_HANDLE(xen_hvm_set_isa_irq_level_t) uop) + XEN_GUEST_HANDLE_PARAM(xen_hvm_set_isa_irq_level_t) uop) { struct xen_hvm_set_isa_irq_level op; struct domain *d; @@ -3591,7 +3591,7 @@ static int hvmop_set_isa_irq_level( } static int hvmop_set_pci_link_route( - XEN_GUEST_HANDLE(xen_hvm_set_pci_link_route_t) uop) + XEN_GUEST_HANDLE_PARAM(xen_hvm_set_pci_link_route_t) uop) { struct xen_hvm_set_pci_link_route op; struct domain *d; @@ -3624,7 +3624,7 @@ static int hvmop_set_pci_link_route( } static int hvmop_inject_msi( - XEN_GUEST_HANDLE(xen_hvm_inject_msi_t) uop) + XEN_GUEST_HANDLE_PARAM(xen_hvm_inject_msi_t) uop) { struct xen_hvm_inject_msi op; struct domain *d; @@ -3708,7 +3708,7 @@ static int hvm_replace_event_channel(struct vcpu *v, domid_t remote_domid, return 0; } -long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg) +long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg) { struct domain *curr_d = current->domain; diff --git a/xen/arch/x86/microcode.c b/xen/arch/x86/microcode.c index fe51034..fbbf95b 100644 --- a/xen/arch/x86/microcode.c +++ b/xen/arch/x86/microcode.c @@ -195,7 +195,7 @@ static long do_microcode_update(void *_info) return error; } -int microcode_update(XEN_GUEST_HANDLE(const_void) buf, unsigned long len) +int microcode_update(XEN_GUEST_HANDLE_PARAM(const_void) buf, unsigned long len) { int ret; struct microcode_info *info; diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index 8ab92c9..9a828de 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -2652,7 +2652,7 @@ static void put_pg_owner(struct domain *pg_owner) } static inline int vcpumask_to_pcpumask( - struct domain *d, XEN_GUEST_HANDLE(const_void) bmap, cpumask_t *pmask) + struct domain *d, XEN_GUEST_HANDLE_PARAM(const_void) bmap, cpumask_t *pmask) { unsigned int vcpu_id, vcpu_bias, offs; unsigned long vmask; @@ -2692,9 +2692,9 @@ static inline int vcpumask_to_pcpumask( #define fixunmap_domain_page(ptr) ((void)(ptr)) long do_mmuext_op( - XEN_GUEST_HANDLE(mmuext_op_t) uops, + XEN_GUEST_HANDLE_PARAM(mmuext_op_t) uops, unsigned int count, - XEN_GUEST_HANDLE(uint) pdone, + XEN_GUEST_HANDLE_PARAM(uint) pdone, unsigned int foreigndom) { struct mmuext_op op; @@ -3151,9 +3151,9 @@ long do_mmuext_op( } long do_mmu_update( - XEN_GUEST_HANDLE(mmu_update_t) ureqs, + XEN_GUEST_HANDLE_PARAM(mmu_update_t) ureqs, unsigned int count, - XEN_GUEST_HANDLE(uint) pdone, + XEN_GUEST_HANDLE_PARAM(uint) pdone, unsigned int foreigndom) { struct mmu_update req; @@ -4098,7 +4098,7 @@ long set_gdt(struct vcpu *v, } -long do_set_gdt(XEN_GUEST_HANDLE(ulong) frame_list, unsigned int entries) +long do_set_gdt(XEN_GUEST_HANDLE_PARAM(ulong) frame_list, unsigned int entries) { int nr_pages = (entries + 511) / 512; unsigned long frames[16]; @@ -4370,7 +4370,7 @@ static int xenmem_add_to_physmap(struct domain *d, return xenmem_add_to_physmap_once(d, xatp); } -long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg) +long arch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg) { int rc; diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c index d2637d3..fd99cde 100644 --- a/xen/arch/x86/mm/hap/hap.c +++ b/xen/arch/x86/mm/hap/hap.c @@ -571,7 +571,7 @@ void hap_teardown(struct domain *d) } int hap_domctl(struct domain *d, xen_domctl_shadow_op_t *sc, - XEN_GUEST_HANDLE(void) u_domctl) + XEN_GUEST_HANDLE_PARAM(void) u_domctl) { int rc, preempted = 0; diff --git a/xen/arch/x86/mm/mem_event.c b/xen/arch/x86/mm/mem_event.c index 942c19e..27d1cf4 100644 --- a/xen/arch/x86/mm/mem_event.c +++ b/xen/arch/x86/mm/mem_event.c @@ -512,7 +512,7 @@ void mem_event_cleanup(struct domain *d) } int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec, - XEN_GUEST_HANDLE(void) u_domctl) + XEN_GUEST_HANDLE_PARAM(void) u_domctl) { int rc; diff --git a/xen/arch/x86/mm/paging.c b/xen/arch/x86/mm/paging.c index ca879f9..ea44e39 100644 --- a/xen/arch/x86/mm/paging.c +++ b/xen/arch/x86/mm/paging.c @@ -654,7 +654,7 @@ void paging_vcpu_init(struct vcpu *v) int paging_domctl(struct domain *d, xen_domctl_shadow_op_t *sc, - XEN_GUEST_HANDLE(void) u_domctl) + XEN_GUEST_HANDLE_PARAM(void) u_domctl) { int rc; diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c index 3f8ad88..ce79131 100644 --- a/xen/arch/x86/mm/shadow/common.c +++ b/xen/arch/x86/mm/shadow/common.c @@ -3641,7 +3641,7 @@ out: int shadow_domctl(struct domain *d, xen_domctl_shadow_op_t *sc, - XEN_GUEST_HANDLE(void) u_domctl) + XEN_GUEST_HANDLE_PARAM(void) u_domctl) { int rc, preempted = 0; diff --git a/xen/arch/x86/oprofile/xenoprof.c b/xen/arch/x86/oprofile/xenoprof.c index 160abac..90ef67d 100644 --- a/xen/arch/x86/oprofile/xenoprof.c +++ b/xen/arch/x86/oprofile/xenoprof.c @@ -17,7 +17,7 @@ #include "op_counter.h" -int xenoprof_arch_counter(XEN_GUEST_HANDLE(void) arg) +int xenoprof_arch_counter(XEN_GUEST_HANDLE_PARAM(void) arg) { struct xenoprof_counter counter; @@ -37,7 +37,7 @@ int xenoprof_arch_counter(XEN_GUEST_HANDLE(void) arg) return 0; } -int xenoprof_arch_ibs_counter(XEN_GUEST_HANDLE(void) arg) +int xenoprof_arch_ibs_counter(XEN_GUEST_HANDLE_PARAM(void) arg) { struct xenoprof_ibs_counter ibs_counter; @@ -54,7 +54,7 @@ int xenoprof_arch_ibs_counter(XEN_GUEST_HANDLE(void) arg) return 0; } -int compat_oprof_arch_counter(XEN_GUEST_HANDLE(void) arg) +int compat_oprof_arch_counter(XEN_GUEST_HANDLE_PARAM(void) arg) { struct compat_oprof_counter counter; diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c index 984c813..751cbd4 100644 --- a/xen/arch/x86/physdev.c +++ b/xen/arch/x86/physdev.c @@ -258,7 +258,7 @@ int physdev_unmap_pirq(domid_t domid, int pirq) } #endif /* COMPAT */ -ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg) +ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) { int irq; ret_t ret; diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hypercall.c index 073a2ea..7a7325f 100644 --- a/xen/arch/x86/platform_hypercall.c +++ b/xen/arch/x86/platform_hypercall.c @@ -61,7 +61,7 @@ long cpu_down_helper(void *data); long core_parking_helper(void *data); uint32_t get_cur_idle_nums(void); -ret_t do_platform_op(XEN_GUEST_HANDLE(xen_platform_op_t) u_xenpf_op) +ret_t do_platform_op(XEN_GUEST_HANDLE_PARAM(xen_platform_op_t) u_xenpf_op) { ret_t ret = 0; struct xen_platform_op curop, *op = &curop; diff --git a/xen/arch/x86/sysctl.c b/xen/arch/x86/sysctl.c index 379f071..b84dd34 100644 --- a/xen/arch/x86/sysctl.c +++ b/xen/arch/x86/sysctl.c @@ -58,7 +58,7 @@ long cpu_down_helper(void *data) } long arch_do_sysctl( - struct xen_sysctl *sysctl, XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl) + struct xen_sysctl *sysctl, XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl) { long ret = 0; diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c index de08e25..dfaf78e 100644 --- a/xen/arch/x86/traps.c +++ b/xen/arch/x86/traps.c @@ -3536,7 +3536,7 @@ int send_guest_trap(struct domain *d, uint16_t vcpuid, unsigned int trap_nr) } -long do_set_trap_table(XEN_GUEST_HANDLE(const_trap_info_t) traps) +long do_set_trap_table(XEN_GUEST_HANDLE_PARAM(const_trap_info_t) traps) { struct trap_info cur; struct vcpu *curr = current; diff --git a/xen/arch/x86/x86_64/compat/mm.c b/xen/arch/x86/x86_64/compat/mm.c index f497503..d1eb785 100644 --- a/xen/arch/x86/x86_64/compat/mm.c +++ b/xen/arch/x86/x86_64/compat/mm.c @@ -5,7 +5,7 @@ #include #include -int compat_set_gdt(XEN_GUEST_HANDLE(uint) frame_list, unsigned int entries) +int compat_set_gdt(XEN_GUEST_HANDLE_PARAM(uint) frame_list, unsigned int entries) { unsigned int i, nr_pages = (entries + 511) / 512; unsigned long frames[16]; @@ -44,7 +44,7 @@ int compat_update_descriptor(u32 pa_lo, u32 pa_hi, u32 desc_lo, u32 desc_hi) desc_lo | ((u64)desc_hi << 32)); } -int compat_arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg) +int compat_arch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg) { struct compat_machphys_mfn_list xmml; l2_pgentry_t l2e; @@ -260,14 +260,14 @@ int compat_update_va_mapping_otherdomain(unsigned long va, u32 lo, u32 hi, DEFINE_XEN_GUEST_HANDLE(mmuext_op_compat_t); -int compat_mmuext_op(XEN_GUEST_HANDLE(mmuext_op_compat_t) cmp_uops, +int compat_mmuext_op(XEN_GUEST_HANDLE_PARAM(mmuext_op_compat_t) cmp_uops, unsigned int count, - XEN_GUEST_HANDLE(uint) pdone, + XEN_GUEST_HANDLE_PARAM(uint) pdone, unsigned int foreigndom) { unsigned int i, preempt_mask; int rc = 0; - XEN_GUEST_HANDLE(mmuext_op_t) nat_ops; + XEN_GUEST_HANDLE_PARAM(mmuext_op_t) nat_ops; preempt_mask = count & MMU_UPDATE_PREEMPTED; count ^= preempt_mask; diff --git a/xen/arch/x86/x86_64/domain.c b/xen/arch/x86/x86_64/domain.c index e746c89..144ca2d 100644 --- a/xen/arch/x86/x86_64/domain.c +++ b/xen/arch/x86/x86_64/domain.c @@ -23,7 +23,7 @@ CHECK_vcpu_get_physid; int arch_compat_vcpu_op( - int cmd, struct vcpu *v, XEN_GUEST_HANDLE(void) arg) + int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg) { int rc = -ENOSYS; diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c index 1e001ea..35653b7 100644 --- a/xen/arch/x86/x86_64/mm.c +++ b/xen/arch/x86/x86_64/mm.c @@ -1027,7 +1027,7 @@ void __init subarch_init_memory(void) } } -long subarch_memory_op(int op, XEN_GUEST_HANDLE(void) arg) +long subarch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg) { struct xen_machphys_mfn_list xmml; l3_pgentry_t l3e; diff --git a/xen/arch/x86/x86_64/traps.c b/xen/arch/x86/x86_64/traps.c index 3361d19..dfe0fac 100644 --- a/xen/arch/x86/x86_64/traps.c +++ b/xen/arch/x86/x86_64/traps.c @@ -519,7 +519,7 @@ static long unregister_guest_callback(struct callback_unregister *unreg) } -long do_callback_op(int cmd, XEN_GUEST_HANDLE(const_void) arg) +long do_callback_op(int cmd, XEN_GUEST_HANDLE_PARAM(const_void) arg) { long ret; diff --git a/xen/common/compat/domain.c b/xen/common/compat/domain.c index 40a0287..e4c8ceb 100644 --- a/xen/common/compat/domain.c +++ b/xen/common/compat/domain.c @@ -15,7 +15,7 @@ CHECK_vcpu_set_periodic_timer; #undef xen_vcpu_set_periodic_timer -int compat_vcpu_op(int cmd, int vcpuid, XEN_GUEST_HANDLE(void) arg) +int compat_vcpu_op(int cmd, int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg) { struct domain *d = current->domain; struct vcpu *v; diff --git a/xen/common/compat/grant_table.c b/xen/common/compat/grant_table.c index edd20c6..b524955 100644 --- a/xen/common/compat/grant_table.c +++ b/xen/common/compat/grant_table.c @@ -52,12 +52,12 @@ CHECK_gnttab_swap_grant_ref; #undef xen_gnttab_swap_grant_ref int compat_grant_table_op(unsigned int cmd, - XEN_GUEST_HANDLE(void) cmp_uop, + XEN_GUEST_HANDLE_PARAM(void) cmp_uop, unsigned int count) { int rc = 0; unsigned int i; - XEN_GUEST_HANDLE(void) cnt_uop; + XEN_GUEST_HANDLE_PARAM(void) cnt_uop; set_xen_guest_handle(cnt_uop, NULL); switch ( cmd ) @@ -206,7 +206,7 @@ int compat_grant_table_op(unsigned int cmd, } if ( rc >= 0 ) { - XEN_GUEST_HANDLE(gnttab_transfer_compat_t) xfer; + XEN_GUEST_HANDLE_PARAM(gnttab_transfer_compat_t) xfer; xfer = guest_handle_cast(cmp_uop, gnttab_transfer_compat_t); guest_handle_add_offset(xfer, i); @@ -251,7 +251,7 @@ int compat_grant_table_op(unsigned int cmd, } if ( rc >= 0 ) { - XEN_GUEST_HANDLE(gnttab_copy_compat_t) copy; + XEN_GUEST_HANDLE_PARAM(gnttab_copy_compat_t) copy; copy = guest_handle_cast(cmp_uop, gnttab_copy_compat_t); guest_handle_add_offset(copy, i); diff --git a/xen/common/compat/memory.c b/xen/common/compat/memory.c index e7257cc..996151c 100644 --- a/xen/common/compat/memory.c +++ b/xen/common/compat/memory.c @@ -13,7 +13,7 @@ CHECK_TYPE(domid); #undef compat_domid_t #undef xen_domid_t -int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE(void) compat) +int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) compat) { int rc, split, op = cmd & MEMOP_CMD_MASK; unsigned int start_extent = cmd >> MEMOP_EXTENT_SHIFT; @@ -22,7 +22,7 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE(void) compat) { unsigned int i, end_extent = 0; union { - XEN_GUEST_HANDLE(void) hnd; + XEN_GUEST_HANDLE_PARAM(void) hnd; struct xen_memory_reservation *rsrv; struct xen_memory_exchange *xchg; struct xen_remove_from_physmap *xrfp; diff --git a/xen/common/domain.c b/xen/common/domain.c index a1aa05e..6f98b54 100644 --- a/xen/common/domain.c +++ b/xen/common/domain.c @@ -806,7 +806,7 @@ void vcpu_reset(struct vcpu *v) } -long do_vcpu_op(int cmd, int vcpuid, XEN_GUEST_HANDLE(void) arg) +long do_vcpu_op(int cmd, int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg) { struct domain *d = current->domain; struct vcpu *v; diff --git a/xen/common/domctl.c b/xen/common/domctl.c index 2b1f182..e153cb4 100644 --- a/xen/common/domctl.c +++ b/xen/common/domctl.c @@ -239,7 +239,7 @@ void domctl_lock_release(void) spin_unlock(¤t->domain->hypercall_deadlock_mutex); } -long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl) +long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) { long ret = 0; struct xen_domctl curop, *op = &curop; diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c index 53777f8..a80a0d1 100644 --- a/xen/common/event_channel.c +++ b/xen/common/event_channel.c @@ -970,7 +970,7 @@ out: } -long do_event_channel_op(int cmd, XEN_GUEST_HANDLE(void) arg) +long do_event_channel_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) { long rc; diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c index c8e342b..f4ae9ee 100644 --- a/xen/common/grant_table.c +++ b/xen/common/grant_table.c @@ -833,7 +833,7 @@ __gnttab_map_grant_ref( static long gnttab_map_grant_ref( - XEN_GUEST_HANDLE(gnttab_map_grant_ref_t) uop, unsigned int count) + XEN_GUEST_HANDLE_PARAM(gnttab_map_grant_ref_t) uop, unsigned int count) { int i; struct gnttab_map_grant_ref op; @@ -1102,7 +1102,7 @@ __gnttab_unmap_grant_ref( static long gnttab_unmap_grant_ref( - XEN_GUEST_HANDLE(gnttab_unmap_grant_ref_t) uop, unsigned int count) + XEN_GUEST_HANDLE_PARAM(gnttab_unmap_grant_ref_t) uop, unsigned int count) { int i, c, partial_done, done = 0; struct gnttab_unmap_grant_ref op; @@ -1164,7 +1164,7 @@ __gnttab_unmap_and_replace( static long gnttab_unmap_and_replace( - XEN_GUEST_HANDLE(gnttab_unmap_and_replace_t) uop, unsigned int count) + XEN_GUEST_HANDLE_PARAM(gnttab_unmap_and_replace_t) uop, unsigned int count) { int i, c, partial_done, done = 0; struct gnttab_unmap_and_replace op; @@ -1316,7 +1316,7 @@ active_alloc_failed: static long gnttab_setup_table( - XEN_GUEST_HANDLE(gnttab_setup_table_t) uop, unsigned int count) + XEN_GUEST_HANDLE_PARAM(gnttab_setup_table_t) uop, unsigned int count) { struct gnttab_setup_table op; struct domain *d; @@ -1395,7 +1395,7 @@ gnttab_setup_table( static long gnttab_query_size( - XEN_GUEST_HANDLE(gnttab_query_size_t) uop, unsigned int count) + XEN_GUEST_HANDLE_PARAM(gnttab_query_size_t) uop, unsigned int count) { struct gnttab_query_size op; struct domain *d; @@ -1517,7 +1517,7 @@ gnttab_prepare_for_transfer( static long gnttab_transfer( - XEN_GUEST_HANDLE(gnttab_transfer_t) uop, unsigned int count) + XEN_GUEST_HANDLE_PARAM(gnttab_transfer_t) uop, unsigned int count) { struct domain *d = current->domain; struct domain *e; @@ -2125,7 +2125,7 @@ __gnttab_copy( static long gnttab_copy( - XEN_GUEST_HANDLE(gnttab_copy_t) uop, unsigned int count) + XEN_GUEST_HANDLE_PARAM(gnttab_copy_t) uop, unsigned int count) { int i; struct gnttab_copy op; @@ -2144,7 +2144,7 @@ gnttab_copy( } static long -gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop)) +gnttab_set_version(XEN_GUEST_HANDLE_PARAM(gnttab_set_version_t uop)) { gnttab_set_version_t op; struct domain *d = current->domain; @@ -2263,7 +2263,7 @@ out: } static long -gnttab_get_status_frames(XEN_GUEST_HANDLE(gnttab_get_status_frames_t) uop, +gnttab_get_status_frames(XEN_GUEST_HANDLE_PARAM(gnttab_get_status_frames_t) uop, int count) { gnttab_get_status_frames_t op; @@ -2327,7 +2327,7 @@ out1: } static long -gnttab_get_version(XEN_GUEST_HANDLE(gnttab_get_version_t uop)) +gnttab_get_version(XEN_GUEST_HANDLE_PARAM(gnttab_get_version_t uop)) { gnttab_get_version_t op; struct domain *d; @@ -2412,7 +2412,7 @@ out: } static long -gnttab_swap_grant_ref(XEN_GUEST_HANDLE(gnttab_swap_grant_ref_t uop), +gnttab_swap_grant_ref(XEN_GUEST_HANDLE_PARAM(gnttab_swap_grant_ref_t uop), unsigned int count) { int i; @@ -2433,7 +2433,7 @@ gnttab_swap_grant_ref(XEN_GUEST_HANDLE(gnttab_swap_grant_ref_t uop), long do_grant_table_op( - unsigned int cmd, XEN_GUEST_HANDLE(void) uop, unsigned int count) + unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) uop, unsigned int count) { long rc; @@ -2445,7 +2445,7 @@ do_grant_table_op( { case GNTTABOP_map_grant_ref: { - XEN_GUEST_HANDLE(gnttab_map_grant_ref_t) map = + XEN_GUEST_HANDLE_PARAM(gnttab_map_grant_ref_t) map = guest_handle_cast(uop, gnttab_map_grant_ref_t); if ( unlikely(!guest_handle_okay(map, count)) ) goto out; @@ -2459,7 +2459,7 @@ do_grant_table_op( } case GNTTABOP_unmap_grant_ref: { - XEN_GUEST_HANDLE(gnttab_unmap_grant_ref_t) unmap = + XEN_GUEST_HANDLE_PARAM(gnttab_unmap_grant_ref_t) unmap = guest_handle_cast(uop, gnttab_unmap_grant_ref_t); if ( unlikely(!guest_handle_okay(unmap, count)) ) goto out; @@ -2473,7 +2473,7 @@ do_grant_table_op( } case GNTTABOP_unmap_and_replace: { - XEN_GUEST_HANDLE(gnttab_unmap_and_replace_t) unmap = + XEN_GUEST_HANDLE_PARAM(gnttab_unmap_and_replace_t) unmap = guest_handle_cast(uop, gnttab_unmap_and_replace_t); if ( unlikely(!guest_handle_okay(unmap, count)) ) goto out; @@ -2497,7 +2497,7 @@ do_grant_table_op( } case GNTTABOP_transfer: { - XEN_GUEST_HANDLE(gnttab_transfer_t) transfer = + XEN_GUEST_HANDLE_PARAM(gnttab_transfer_t) transfer = guest_handle_cast(uop, gnttab_transfer_t); if ( unlikely(!guest_handle_okay(transfer, count)) ) goto out; @@ -2511,7 +2511,7 @@ do_grant_table_op( } case GNTTABOP_copy: { - XEN_GUEST_HANDLE(gnttab_copy_t) copy = + XEN_GUEST_HANDLE_PARAM(gnttab_copy_t) copy = guest_handle_cast(uop, gnttab_copy_t); if ( unlikely(!guest_handle_okay(copy, count)) ) goto out; @@ -2548,7 +2548,7 @@ do_grant_table_op( } case GNTTABOP_swap_grant_ref: { - XEN_GUEST_HANDLE(gnttab_swap_grant_ref_t) swap = + XEN_GUEST_HANDLE_PARAM(gnttab_swap_grant_ref_t) swap = guest_handle_cast(uop, gnttab_swap_grant_ref_t); if ( unlikely(!guest_handle_okay(swap, count)) ) goto out; diff --git a/xen/common/kernel.c b/xen/common/kernel.c index c915bbc..55caff6 100644 --- a/xen/common/kernel.c +++ b/xen/common/kernel.c @@ -204,7 +204,7 @@ void __init do_initcalls(void) * Simple hypercalls. */ -DO(xen_version)(int cmd, XEN_GUEST_HANDLE(void) arg) +DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) { switch ( cmd ) { @@ -332,7 +332,7 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE(void) arg) return -ENOSYS; } -DO(nmi_op)(unsigned int cmd, XEN_GUEST_HANDLE(void) arg) +DO(nmi_op)(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) { struct xennmi_callback cb; long rc = 0; diff --git a/xen/common/kexec.c b/xen/common/kexec.c index 2bc3e33..25ebd6a 100644 --- a/xen/common/kexec.c +++ b/xen/common/kexec.c @@ -613,7 +613,7 @@ static int kexec_get_range_internal(xen_kexec_range_t *range) return ret; } -static int kexec_get_range(XEN_GUEST_HANDLE(void) uarg) +static int kexec_get_range(XEN_GUEST_HANDLE_PARAM(void) uarg) { xen_kexec_range_t range; int ret = -EINVAL; @@ -629,7 +629,7 @@ static int kexec_get_range(XEN_GUEST_HANDLE(void) uarg) return ret; } -static int kexec_get_range_compat(XEN_GUEST_HANDLE(void) uarg) +static int kexec_get_range_compat(XEN_GUEST_HANDLE_PARAM(void) uarg) { #ifdef CONFIG_COMPAT xen_kexec_range_t range; @@ -777,7 +777,7 @@ static int kexec_load_unload_internal(unsigned long op, xen_kexec_load_t *load) return ret; } -static int kexec_load_unload(unsigned long op, XEN_GUEST_HANDLE(void) uarg) +static int kexec_load_unload(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) uarg) { xen_kexec_load_t load; @@ -788,7 +788,7 @@ static int kexec_load_unload(unsigned long op, XEN_GUEST_HANDLE(void) uarg) } static int kexec_load_unload_compat(unsigned long op, - XEN_GUEST_HANDLE(void) uarg) + XEN_GUEST_HANDLE_PARAM(void) uarg) { #ifdef CONFIG_COMPAT compat_kexec_load_t compat_load; @@ -813,7 +813,7 @@ static int kexec_load_unload_compat(unsigned long op, #endif /* CONFIG_COMPAT */ } -static int kexec_exec(XEN_GUEST_HANDLE(void) uarg) +static int kexec_exec(XEN_GUEST_HANDLE_PARAM(void) uarg) { xen_kexec_exec_t exec; xen_kexec_image_t *image; @@ -845,7 +845,8 @@ static int kexec_exec(XEN_GUEST_HANDLE(void) uarg) return -EINVAL; /* never reached */ } -static int do_kexec_op_internal(unsigned long op, XEN_GUEST_HANDLE(void) uarg, +static int do_kexec_op_internal(unsigned long op, + XEN_GUEST_HANDLE_PARAM(void) uarg, bool_t compat) { unsigned long flags; @@ -886,13 +887,13 @@ static int do_kexec_op_internal(unsigned long op, XEN_GUEST_HANDLE(void) uarg, return ret; } -long do_kexec_op(unsigned long op, XEN_GUEST_HANDLE(void) uarg) +long do_kexec_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) uarg) { return do_kexec_op_internal(op, uarg, 0); } #ifdef CONFIG_COMPAT -int compat_kexec_op(unsigned long op, XEN_GUEST_HANDLE(void) uarg) +int compat_kexec_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) uarg) { return do_kexec_op_internal(op, uarg, 1); } diff --git a/xen/common/memory.c b/xen/common/memory.c index 401d06c..83e2666 100644 --- a/xen/common/memory.c +++ b/xen/common/memory.c @@ -277,7 +277,7 @@ static void decrease_reservation(struct memop_args *a) a->nr_done = i; } -static long memory_exchange(XEN_GUEST_HANDLE(xen_memory_exchange_t) arg) +static long memory_exchange(XEN_GUEST_HANDLE_PARAM(xen_memory_exchange_t) arg) { struct xen_memory_exchange exch; PAGE_LIST_HEAD(in_chunk_list); @@ -517,7 +517,7 @@ static long memory_exchange(XEN_GUEST_HANDLE(xen_memory_exchange_t) arg) return rc; } -long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE(void) arg) +long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg) { struct domain *d; int rc, op; diff --git a/xen/common/multicall.c b/xen/common/multicall.c index ca1839d..7e557e5 100644 --- a/xen/common/multicall.c +++ b/xen/common/multicall.c @@ -35,7 +35,7 @@ static void trace_multicall_call(multicall_entry_t *call) ret_t do_multicall( - XEN_GUEST_HANDLE(multicall_entry_t) call_list, unsigned int nr_calls) + XEN_GUEST_HANDLE_PARAM(multicall_entry_t) call_list, unsigned int nr_calls) { struct mc_state *mcs = ¤t->mc_state; unsigned int i; diff --git a/xen/common/schedule.c b/xen/common/schedule.c index eee74be..00812ac 100644 --- a/xen/common/schedule.c +++ b/xen/common/schedule.c @@ -836,7 +836,7 @@ typedef long ret_t; #endif /* !COMPAT */ -ret_t do_sched_op(int cmd, XEN_GUEST_HANDLE(void) arg) +ret_t do_sched_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) { ret_t ret = 0; diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c index ea68278..47142f4 100644 --- a/xen/common/sysctl.c +++ b/xen/common/sysctl.c @@ -27,7 +27,7 @@ #include #include -long do_sysctl(XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl) +long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl) { long ret = 0; struct xen_sysctl curop, *op = &curop; diff --git a/xen/common/xenoprof.c b/xen/common/xenoprof.c index 44a1fae..ae0435b 100644 --- a/xen/common/xenoprof.c +++ b/xen/common/xenoprof.c @@ -404,7 +404,7 @@ static int add_active_list(domid_t domid) return 0; } -static int add_passive_list(XEN_GUEST_HANDLE(void) arg) +static int add_passive_list(XEN_GUEST_HANDLE_PARAM(void) arg) { struct xenoprof_passive passive; struct domain *d; @@ -585,7 +585,7 @@ void xenoprof_log_event(struct vcpu *vcpu, const struct cpu_user_regs *regs, -static int xenoprof_op_init(XEN_GUEST_HANDLE(void) arg) +static int xenoprof_op_init(XEN_GUEST_HANDLE_PARAM(void) arg) { struct domain *d = current->domain; struct xenoprof_init xenoprof_init; @@ -611,7 +611,7 @@ static int xenoprof_op_init(XEN_GUEST_HANDLE(void) arg) #endif /* !COMPAT */ -static int xenoprof_op_get_buffer(XEN_GUEST_HANDLE(void) arg) +static int xenoprof_op_get_buffer(XEN_GUEST_HANDLE_PARAM(void) arg) { struct xenoprof_get_buffer xenoprof_get_buffer; struct domain *d = current->domain; @@ -662,7 +662,7 @@ static int xenoprof_op_get_buffer(XEN_GUEST_HANDLE(void) arg) || (op == XENOPROF_disable_virq) \ || (op == XENOPROF_get_buffer)) -ret_t do_xenoprof_op(int op, XEN_GUEST_HANDLE(void) arg) +ret_t do_xenoprof_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg) { int ret = 0; diff --git a/xen/drivers/acpi/pmstat.c b/xen/drivers/acpi/pmstat.c index 6f266ef..bf30cc7 100644 --- a/xen/drivers/acpi/pmstat.c +++ b/xen/drivers/acpi/pmstat.c @@ -496,7 +496,7 @@ int do_pm_op(struct xen_sysctl_pm_op *op) return ret; } -int acpi_set_pdc_bits(u32 acpi_id, XEN_GUEST_HANDLE(uint32) pdc) +int acpi_set_pdc_bits(u32 acpi_id, XEN_GUEST_HANDLE_PARAM(uint32) pdc) { u32 bits[3]; int ret; diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c index 9e1adb5..ff360fe 100644 --- a/xen/drivers/char/console.c +++ b/xen/drivers/char/console.c @@ -182,7 +182,7 @@ static void putchar_console_ring(int c) long read_console_ring(struct xen_sysctl_readconsole *op) { - XEN_GUEST_HANDLE(char) str; + XEN_GUEST_HANDLE_PARAM(char) str; uint32_t idx, len, max, sofar, c; str = guest_handle_cast(op->buffer, char), @@ -363,7 +363,7 @@ static void notify_dom0_con_ring(unsigned long unused) static DECLARE_SOFTIRQ_TASKLET(notify_dom0_con_ring_tasklet, notify_dom0_con_ring, 0); -static long guest_console_write(XEN_GUEST_HANDLE(char) buffer, int count) +static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, int count) { char kbuf[128], *kptr; int kcount; @@ -401,7 +401,7 @@ static long guest_console_write(XEN_GUEST_HANDLE(char) buffer, int count) return 0; } -long do_console_io(int cmd, int count, XEN_GUEST_HANDLE(char) buffer) +long do_console_io(int cmd, int count, XEN_GUEST_HANDLE_PARAM(char) buffer) { long rc; unsigned int idx, len; diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c index b4cf16c..4b5f8b7 100644 --- a/xen/drivers/passthrough/iommu.c +++ b/xen/drivers/passthrough/iommu.c @@ -527,7 +527,7 @@ void iommu_crash_shutdown(void) int iommu_do_domctl( struct xen_domctl *domctl, - XEN_GUEST_HANDLE(xen_domctl_t) u_domctl) + XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) { struct domain *d; u16 seg; diff --git a/xen/include/asm-arm/hypercall.h b/xen/include/asm-arm/hypercall.h index 454f02e..090e620 100644 --- a/xen/include/asm-arm/hypercall.h +++ b/xen/include/asm-arm/hypercall.h @@ -2,7 +2,7 @@ #define __ASM_ARM_HYPERCALL_H__ #include /* for arch_do_domctl */ -int do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg); +int do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg); #endif /* __ASM_ARM_HYPERCALL_H__ */ /* diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h index b37bd35..8bf45ba 100644 --- a/xen/include/asm-arm/mm.h +++ b/xen/include/asm-arm/mm.h @@ -267,7 +267,7 @@ static inline int relinquish_shared_pages(struct domain *d) /* Arch-specific portion of memory_op hypercall. */ -long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg); +long arch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg); int steal_page( struct domain *d, struct page_info *page, unsigned int memflags); diff --git a/xen/include/asm-x86/hap.h b/xen/include/asm-x86/hap.h index a2532a4..916a35b 100644 --- a/xen/include/asm-x86/hap.h +++ b/xen/include/asm-x86/hap.h @@ -51,7 +51,7 @@ hap_unmap_domain_page(void *p) /************************************************/ void hap_domain_init(struct domain *d); int hap_domctl(struct domain *d, xen_domctl_shadow_op_t *sc, - XEN_GUEST_HANDLE(void) u_domctl); + XEN_GUEST_HANDLE_PARAM(void) u_domctl); int hap_enable(struct domain *d, u32 mode); void hap_final_teardown(struct domain *d); void hap_teardown(struct domain *d); diff --git a/xen/include/asm-x86/hypercall.h b/xen/include/asm-x86/hypercall.h index a9af426..bd14220 100644 --- a/xen/include/asm-x86/hypercall.h +++ b/xen/include/asm-x86/hypercall.h @@ -18,22 +18,22 @@ extern long do_event_channel_op_compat( - XEN_GUEST_HANDLE(evtchn_op_t) uop); + XEN_GUEST_HANDLE_PARAM(evtchn_op_t) uop); extern long do_set_trap_table( - XEN_GUEST_HANDLE(const_trap_info_t) traps); + XEN_GUEST_HANDLE_PARAM(const_trap_info_t) traps); extern long do_mmu_update( - XEN_GUEST_HANDLE(mmu_update_t) ureqs, + XEN_GUEST_HANDLE_PARAM(mmu_update_t) ureqs, unsigned int count, - XEN_GUEST_HANDLE(uint) pdone, + XEN_GUEST_HANDLE_PARAM(uint) pdone, unsigned int foreigndom); extern long do_set_gdt( - XEN_GUEST_HANDLE(ulong) frame_list, + XEN_GUEST_HANDLE_PARAM(ulong) frame_list, unsigned int entries); extern long @@ -60,7 +60,7 @@ do_update_descriptor( u64 desc); extern long -do_mca(XEN_GUEST_HANDLE(xen_mc_t) u_xen_mc); +do_mca(XEN_GUEST_HANDLE_PARAM(xen_mc_t) u_xen_mc); extern long do_update_va_mapping( @@ -70,7 +70,7 @@ do_update_va_mapping( extern long do_physdev_op( - int cmd, XEN_GUEST_HANDLE(void) arg); + int cmd, XEN_GUEST_HANDLE_PARAM(void) arg); extern long do_update_va_mapping_otherdomain( @@ -81,9 +81,9 @@ do_update_va_mapping_otherdomain( extern long do_mmuext_op( - XEN_GUEST_HANDLE(mmuext_op_t) uops, + XEN_GUEST_HANDLE_PARAM(mmuext_op_t) uops, unsigned int count, - XEN_GUEST_HANDLE(uint) pdone, + XEN_GUEST_HANDLE_PARAM(uint) pdone, unsigned int foreigndom); extern unsigned long @@ -104,10 +104,10 @@ do_set_segment_base( extern int compat_physdev_op( int cmd, - XEN_GUEST_HANDLE(void) arg); + XEN_GUEST_HANDLE_PARAM(void) arg); extern int arch_compat_vcpu_op( - int cmd, struct vcpu *v, XEN_GUEST_HANDLE(void) arg); + int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg); #endif /* __ASM_X86_HYPERCALL_H__ */ diff --git a/xen/include/asm-x86/mem_event.h b/xen/include/asm-x86/mem_event.h index 23d71c1..e17f36b 100644 --- a/xen/include/asm-x86/mem_event.h +++ b/xen/include/asm-x86/mem_event.h @@ -65,7 +65,7 @@ int mem_event_get_response(struct domain *d, struct mem_event_domain *med, struct domain *get_mem_event_op_target(uint32_t domain, int *rc); int do_mem_event_op(int op, uint32_t domain, void *arg); int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec, - XEN_GUEST_HANDLE(void) u_domctl); + XEN_GUEST_HANDLE_PARAM(void) u_domctl); #endif /* __MEM_EVENT_H__ */ diff --git a/xen/include/asm-x86/mm.h b/xen/include/asm-x86/mm.h index 6e1e57c..494dad8 100644 --- a/xen/include/asm-x86/mm.h +++ b/xen/include/asm-x86/mm.h @@ -555,10 +555,10 @@ void *do_page_walk(struct vcpu *v, unsigned long addr); int __sync_local_execstate(void); /* Arch-specific portion of memory_op hypercall. */ -long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg); -long subarch_memory_op(int op, XEN_GUEST_HANDLE(void) arg); -int compat_arch_memory_op(int op, XEN_GUEST_HANDLE(void)); -int compat_subarch_memory_op(int op, XEN_GUEST_HANDLE(void)); +long arch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg); +long subarch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg); +int compat_arch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void)); +int compat_subarch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void)); int steal_page( struct domain *d, struct page_info *page, unsigned int memflags); diff --git a/xen/include/asm-x86/paging.h b/xen/include/asm-x86/paging.h index d9b6950..9a40f2c 100644 --- a/xen/include/asm-x86/paging.h +++ b/xen/include/asm-x86/paging.h @@ -207,7 +207,7 @@ int paging_domain_init(struct domain *d, unsigned int domcr_flags); * and disable ephemeral shadow modes (test mode and log-dirty mode) and * manipulate the log-dirty bitmap. */ int paging_domctl(struct domain *d, xen_domctl_shadow_op_t *sc, - XEN_GUEST_HANDLE(void) u_domctl); + XEN_GUEST_HANDLE_PARAM(void) u_domctl); /* Call when destroying a domain */ void paging_teardown(struct domain *d); diff --git a/xen/include/asm-x86/processor.h b/xen/include/asm-x86/processor.h index c969b11..637cea3 100644 --- a/xen/include/asm-x86/processor.h +++ b/xen/include/asm-x86/processor.h @@ -549,7 +549,7 @@ int rdmsr_hypervisor_regs(uint32_t idx, uint64_t *val); int wrmsr_hypervisor_regs(uint32_t idx, uint64_t val); void microcode_set_module(unsigned int); -int microcode_update(XEN_GUEST_HANDLE(const_void), unsigned long len); +int microcode_update(XEN_GUEST_HANDLE_PARAM(const_void), unsigned long len); int microcode_resume_cpu(int cpu); #endif /* !__ASSEMBLY__ */ diff --git a/xen/include/asm-x86/shadow.h b/xen/include/asm-x86/shadow.h index 88a8cd2..2eb6efc 100644 --- a/xen/include/asm-x86/shadow.h +++ b/xen/include/asm-x86/shadow.h @@ -73,7 +73,7 @@ int shadow_track_dirty_vram(struct domain *d, * manipulate the log-dirty bitmap. */ int shadow_domctl(struct domain *d, xen_domctl_shadow_op_t *sc, - XEN_GUEST_HANDLE(void) u_domctl); + XEN_GUEST_HANDLE_PARAM(void) u_domctl); /* Call when destroying a domain */ void shadow_teardown(struct domain *d); diff --git a/xen/include/asm-x86/xenoprof.h b/xen/include/asm-x86/xenoprof.h index a71f020..52a6881 100644 --- a/xen/include/asm-x86/xenoprof.h +++ b/xen/include/asm-x86/xenoprof.h @@ -40,9 +40,9 @@ int xenoprof_arch_init(int *num_events, char *cpu_type); #define xenoprof_arch_disable_virq() nmi_disable_virq() #define xenoprof_arch_release_counters() nmi_release_counters() -int xenoprof_arch_counter(XEN_GUEST_HANDLE(void) arg); -int compat_oprof_arch_counter(XEN_GUEST_HANDLE(void) arg); -int xenoprof_arch_ibs_counter(XEN_GUEST_HANDLE(void) arg); +int xenoprof_arch_counter(XEN_GUEST_HANDLE_PARAM(void) arg); +int compat_oprof_arch_counter(XEN_GUEST_HANDLE_PARAM(void) arg); +int xenoprof_arch_ibs_counter(XEN_GUEST_HANDLE_PARAM(void) arg); struct vcpu; struct cpu_user_regs; diff --git a/xen/include/public/tmem.h b/xen/include/public/tmem.h index 74bd1c6..7bd29ba 100644 --- a/xen/include/public/tmem.h +++ b/xen/include/public/tmem.h @@ -96,7 +96,7 @@ #ifndef __ASSEMBLY__ typedef xen_pfn_t tmem_cli_mfn_t; -typedef XEN_GUEST_HANDLE(char) tmem_cli_va_t; +typedef XEN_GUEST_HANDLE_PARAM(char) tmem_cli_va_t; struct tmem_op { uint32_t cmd; int32_t pool_id; diff --git a/xen/include/xen/acpi.h b/xen/include/xen/acpi.h index d7e2f94..8f3cdca 100644 --- a/xen/include/xen/acpi.h +++ b/xen/include/xen/acpi.h @@ -145,8 +145,8 @@ static inline unsigned int acpi_get_cstate_limit(void) { return 0; } static inline void acpi_set_cstate_limit(unsigned int new_limit) { return; } #endif -#ifdef XEN_GUEST_HANDLE -int acpi_set_pdc_bits(u32 acpi_id, XEN_GUEST_HANDLE(uint32)); +#ifdef XEN_GUEST_HANDLE_PARAM +int acpi_set_pdc_bits(u32 acpi_id, XEN_GUEST_HANDLE_PARAM(uint32)); #endif int arch_acpi_set_pdc_bits(u32 acpi_id, u32 *, u32 mask); diff --git a/xen/include/xen/hypercall.h b/xen/include/xen/hypercall.h index 1b71071..e315523 100644 --- a/xen/include/xen/hypercall.h +++ b/xen/include/xen/hypercall.h @@ -29,29 +29,29 @@ do_sched_op_compat( extern long do_sched_op( int cmd, - XEN_GUEST_HANDLE(void) arg); + XEN_GUEST_HANDLE_PARAM(void) arg); extern long do_domctl( - XEN_GUEST_HANDLE(xen_domctl_t) u_domctl); + XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl); extern long arch_do_domctl( struct xen_domctl *domctl, - XEN_GUEST_HANDLE(xen_domctl_t) u_domctl); + XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl); extern long do_sysctl( - XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl); + XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl); extern long arch_do_sysctl( struct xen_sysctl *sysctl, - XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl); + XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl); extern long do_platform_op( - XEN_GUEST_HANDLE(xen_platform_op_t) u_xenpf_op); + XEN_GUEST_HANDLE_PARAM(xen_platform_op_t) u_xenpf_op); /* * To allow safe resume of do_memory_op() after preemption, we need to know @@ -64,11 +64,11 @@ do_platform_op( extern long do_memory_op( unsigned long cmd, - XEN_GUEST_HANDLE(void) arg); + XEN_GUEST_HANDLE_PARAM(void) arg); extern long do_multicall( - XEN_GUEST_HANDLE(multicall_entry_t) call_list, + XEN_GUEST_HANDLE_PARAM(multicall_entry_t) call_list, unsigned int nr_calls); extern long @@ -77,23 +77,23 @@ do_set_timer_op( extern long do_event_channel_op( - int cmd, XEN_GUEST_HANDLE(void) arg); + int cmd, XEN_GUEST_HANDLE_PARAM(void) arg); extern long do_xen_version( int cmd, - XEN_GUEST_HANDLE(void) arg); + XEN_GUEST_HANDLE_PARAM(void) arg); extern long do_console_io( int cmd, int count, - XEN_GUEST_HANDLE(char) buffer); + XEN_GUEST_HANDLE_PARAM(char) buffer); extern long do_grant_table_op( unsigned int cmd, - XEN_GUEST_HANDLE(void) uop, + XEN_GUEST_HANDLE_PARAM(void) uop, unsigned int count); extern long @@ -105,72 +105,72 @@ extern long do_vcpu_op( int cmd, int vcpuid, - XEN_GUEST_HANDLE(void) arg); + XEN_GUEST_HANDLE_PARAM(void) arg); struct vcpu; extern long arch_do_vcpu_op(int cmd, struct vcpu *v, - XEN_GUEST_HANDLE(void) arg); + XEN_GUEST_HANDLE_PARAM(void) arg); extern long do_nmi_op( unsigned int cmd, - XEN_GUEST_HANDLE(void) arg); + XEN_GUEST_HANDLE_PARAM(void) arg); extern long do_hvm_op( unsigned long op, - XEN_GUEST_HANDLE(void) arg); + XEN_GUEST_HANDLE_PARAM(void) arg); extern long do_kexec_op( unsigned long op, int arg1, - XEN_GUEST_HANDLE(void) arg); + XEN_GUEST_HANDLE_PARAM(void) arg); extern long do_xsm_op( - XEN_GUEST_HANDLE(xsm_op_t) u_xsm_op); + XEN_GUEST_HANDLE_PARAM(xsm_op_t) u_xsm_op); extern long do_tmem_op( - XEN_GUEST_HANDLE(tmem_op_t) uops); + XEN_GUEST_HANDLE_PARAM(tmem_op_t) uops); extern long -do_xenoprof_op(int op, XEN_GUEST_HANDLE(void) arg); +do_xenoprof_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg); #ifdef CONFIG_COMPAT extern int compat_memory_op( unsigned int cmd, - XEN_GUEST_HANDLE(void) arg); + XEN_GUEST_HANDLE_PARAM(void) arg); extern int compat_grant_table_op( unsigned int cmd, - XEN_GUEST_HANDLE(void) uop, + XEN_GUEST_HANDLE_PARAM(void) uop, unsigned int count); extern int compat_vcpu_op( int cmd, int vcpuid, - XEN_GUEST_HANDLE(void) arg); + XEN_GUEST_HANDLE_PARAM(void) arg); extern int -compat_xenoprof_op(int op, XEN_GUEST_HANDLE(void) arg); +compat_xenoprof_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg); extern int compat_xen_version( int cmd, - XEN_GUEST_HANDLE(void) arg); + XEN_GUEST_HANDLE_PARAM(void) arg); extern int compat_sched_op( int cmd, - XEN_GUEST_HANDLE(void) arg); + XEN_GUEST_HANDLE_PARAM(void) arg); extern int compat_set_timer_op( diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h index 605c7b3..773a6d7 100644 --- a/xen/include/xen/iommu.h +++ b/xen/include/xen/iommu.h @@ -156,7 +156,7 @@ void iommu_crash_shutdown(void); void iommu_set_dom0_mapping(struct domain *d); void iommu_share_p2m_table(struct domain *d); -int iommu_do_domctl(struct xen_domctl *, XEN_GUEST_HANDLE(xen_domctl_t)); +int iommu_do_domctl(struct xen_domctl *, XEN_GUEST_HANDLE_PARAM(xen_domctl_t)); void iommu_iotlb_flush(struct domain *d, unsigned long gfn, unsigned int page_count); void iommu_iotlb_flush_all(struct domain *d); diff --git a/xen/include/xen/tmem_xen.h b/xen/include/xen/tmem_xen.h index 9492810..c31220a 100644 --- a/xen/include/xen/tmem_xen.h +++ b/xen/include/xen/tmem_xen.h @@ -430,7 +430,7 @@ static inline void tmh_tze_copy_from_pfp(void *tva, pfp_t *pfp, pagesize_t len) typedef XEN_GUEST_HANDLE(void) cli_mfn_t; typedef XEN_GUEST_HANDLE(char) cli_va_t; */ -typedef XEN_GUEST_HANDLE(tmem_op_t) tmem_cli_op_t; +typedef XEN_GUEST_HANDLE_PARAM(tmem_op_t) tmem_cli_op_t; static inline int tmh_get_tmemop_from_client(tmem_op_t *op, tmem_cli_op_t uops) { diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h index 593cdbd..a949c1e 100644 --- a/xen/include/xsm/xsm.h +++ b/xen/include/xsm/xsm.h @@ -139,7 +139,7 @@ struct xsm_operations { int (*cpupool_op)(void); int (*sched_op)(void); - long (*__do_xsm_op) (XEN_GUEST_HANDLE(xsm_op_t) op); + long (*__do_xsm_op) (XEN_GUEST_HANDLE_PARAM(xsm_op_t) op); #ifdef CONFIG_X86 int (*shadow_control) (struct domain *d, uint32_t op); @@ -585,7 +585,7 @@ static inline int xsm_sched_op(void) return xsm_call(sched_op()); } -static inline long __do_xsm_op (XEN_GUEST_HANDLE(xsm_op_t) op) +static inline long __do_xsm_op (XEN_GUEST_HANDLE_PARAM(xsm_op_t) op) { #ifdef XSM_ENABLE return xsm_ops->__do_xsm_op(op); diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c index 4836fc0..b726eaf6 100644 --- a/xen/xsm/dummy.c +++ b/xen/xsm/dummy.c @@ -380,7 +380,7 @@ static int dummy_sched_op (void) return 0; } -static long dummy___do_xsm_op(XEN_GUEST_HANDLE(xsm_op_t) op) +static long dummy___do_xsm_op(XEN_GUEST_HANDLE_PARAM(xsm_op_t) op) { return -ENOSYS; } diff --git a/xen/xsm/flask/flask_op.c b/xen/xsm/flask/flask_op.c index 9c8dfe7..a5d7748 100644 --- a/xen/xsm/flask/flask_op.c +++ b/xen/xsm/flask/flask_op.c @@ -71,7 +71,7 @@ static int domain_has_security(struct domain *d, u32 perms) perms, NULL); } -static int flask_copyin_string(XEN_GUEST_HANDLE(char) u_buf, char **buf, uint32_t size) +static int flask_copyin_string(XEN_GUEST_HANDLE_PARAM(char) u_buf, char **buf, uint32_t size) { char *tmp = xmalloc_bytes(size + 1); if ( !tmp ) @@ -618,7 +618,7 @@ static int flask_relabel_domain(struct xen_flask_relabel *arg) return rc; } -long do_flask_op(XEN_GUEST_HANDLE(xsm_op_t) u_flask_op) +long do_flask_op(XEN_GUEST_HANDLE_PARAM(xsm_op_t) u_flask_op) { xen_flask_op_t op; int rv; diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c index 88fef9c..0ca10d0 100644 --- a/xen/xsm/flask/hooks.c +++ b/xen/xsm/flask/hooks.c @@ -1462,7 +1462,7 @@ static int flask_vcpuextstate (struct domain *d, uint32_t cmd) } #endif -long do_flask_op(XEN_GUEST_HANDLE(xsm_op_t) u_flask_op); +long do_flask_op(XEN_GUEST_HANDLE_PARAM(xsm_op_t) u_flask_op); static struct xsm_operations flask_ops = { .security_domaininfo = flask_security_domaininfo, diff --git a/xen/xsm/xsm_core.c b/xen/xsm/xsm_core.c index 96c8669..46287cb 100644 --- a/xen/xsm/xsm_core.c +++ b/xen/xsm/xsm_core.c @@ -111,7 +111,7 @@ int unregister_xsm(struct xsm_operations *ops) #endif -long do_xsm_op (XEN_GUEST_HANDLE(xsm_op_t) op) +long do_xsm_op (XEN_GUEST_HANDLE_PARAM(xsm_op_t) op) { return __do_xsm_op(op); } -- 1.7.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 10:52:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 10:52:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5W5-0002w1-1C; Fri, 05 Oct 2012 10:52:25 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5W3-0002uH-I8 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 10:52:23 +0000 Received: from [85.158.143.35:42958] by server-1.bemta-4.messagelabs.com id 64/88-05684-6EBBE605; Fri, 05 Oct 2012 10:52:22 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1349434338!13467105!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODA1MjM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6496 invoked from network); 5 Oct 2012 10:52:19 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 10:52:19 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="210397087" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 10:52:19 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 06:52:19 -0400 Received: from [10.80.246.74] (helo=army.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK5Ia-0003Rm-VF; Fri, 05 Oct 2012 11:38:28 +0100 From: Ian Campbell To: Date: Fri, 5 Oct 2012 10:38:17 +0000 Message-ID: <1349433507-21148-11-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.9.1 In-Reply-To: <1349433418.20946.46.camel@zakaz.uk.xensource.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: Stefano Stabellini , tim@xen.org, stefano.stabelini@citrix.com Subject: [Xen-devel] [PATCH 11/21] xen/arm: protect LR registers and lr_mask changes with spin_lock_irq X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Stefano Stabellini GICH_LR registers and lr_mask need to be kept in sync: make sure that their modifications are protected by spin_lock_irq(&gic.lock). Signed-off-by: Stefano Stabellini Acked-by: Ian Campbell --- xen/arch/arm/gic.c | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c index 6f5b0e1..ab93404 100644 --- a/xen/arch/arm/gic.c +++ b/xen/arch/arm/gic.c @@ -57,9 +57,11 @@ void gic_save_state(struct vcpu *v) { int i; + spin_lock_irq(&gic.lock); for ( i=0; iarch.gic_lr[i] = GICH[GICH_LR + i]; v->arch.lr_mask = gic.lr_mask; + spin_unlock_irq(&gic.lock); /* Disable until next VCPU scheduled */ GICH[GICH_HCR] = 0; isb(); @@ -72,9 +74,11 @@ void gic_restore_state(struct vcpu *v) if ( is_idle_vcpu(v) ) return; + spin_lock_irq(&gic.lock); gic.lr_mask = v->arch.lr_mask; for ( i=0; iarch.gic_lr[i]; + spin_unlock_irq(&gic.lock); GICH[GICH_HCR] = GICH_HCR_EN; isb(); @@ -469,9 +473,11 @@ static void gic_restore_pending_irqs(struct vcpu *v) i = find_first_zero_bit(&gic.lr_mask, nr_lrs); if ( i >= nr_lrs ) return; + spin_lock_irq(&gic.lock); gic_set_lr(i, p->irq, GICH_LR_PENDING, p->priority); list_del_init(&p->lr_queue); set_bit(i, &gic.lr_mask); + spin_unlock_irq(&gic.lock); } } -- 1.7.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 10:52:30 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 10:52:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5W4-0002vT-Eg; Fri, 05 Oct 2012 10:52:24 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5W2-0002uH-Va for xen-devel@lists.xen.org; Fri, 05 Oct 2012 10:52:23 +0000 Received: from [85.158.143.99:18566] by server-1.bemta-4.messagelabs.com id 83/88-05684-6EBBE605; Fri, 05 Oct 2012 10:52:22 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1349434338!24861283!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODA1MjM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26888 invoked from network); 5 Oct 2012 10:52:21 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 10:52:21 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="210397091" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 10:52:20 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 06:52:20 -0400 Received: from [10.80.246.74] (helo=army.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK5Ib-0003Rm-9y; Fri, 05 Oct 2012 11:38:29 +0100 From: Ian Campbell To: Date: Fri, 5 Oct 2012 10:38:21 +0000 Message-ID: <1349433507-21148-15-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.9.1 In-Reply-To: <1349433418.20946.46.camel@zakaz.uk.xensource.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: tim@xen.org, Ian Campbell , stefano.stabelini@citrix.com Subject: [Xen-devel] [PATCH 15/21] arm: Use per-CPU irq_desc for PPIs and SGIs X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org The first 32 interrupts on a GIC are the Peripheral Private Interrupts and Software-Generated Interrupts and are local to each processor. The irq_desc cannot be shared since we use irq_desc->status to track whether the IRQ is in-progress etc. Therefore give each processor its own local irq_desc for each of these interupts. We must also route them on each CPU, so do so. This feels like a bit of a layering violation (since the core ARM irq.c now knows about thinkgs wich are really gic.c business) Signed-off-by: Ian Campbell Acked-by: Tim Deegan --- xen/arch/arm/gic.c | 23 ++++++++++++++++++----- xen/arch/arm/gic.h | 3 ++- xen/arch/arm/irq.c | 23 ++++++++++++++++++++++- xen/arch/arm/setup.c | 3 ++- xen/arch/arm/smpboot.c | 9 ++++++++- xen/include/asm-arm/irq.h | 13 +++++++++++++ xen/include/asm-arm/setup.h | 2 -- xen/include/xen/irq.h | 10 ++-------- 8 files changed, 67 insertions(+), 19 deletions(-) diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c index ab93404..5f06e08 100644 --- a/xen/arch/arm/gic.c +++ b/xen/arch/arm/gic.c @@ -50,9 +50,17 @@ static struct { uint64_t lr_mask; } gic; -irq_desc_t irq_desc[NR_IRQS]; +static irq_desc_t irq_desc[NR_IRQS]; +static DEFINE_PER_CPU(irq_desc_t[NR_LOCAL_IRQS], local_irq_desc); + unsigned nr_lrs; +irq_desc_t *__irq_to_desc(int irq) +{ + if (irq < NR_LOCAL_IRQS) return &this_cpu(local_irq_desc)[irq]; + return &irq_desc[irq-NR_LOCAL_IRQS]; +} + void gic_save_state(struct vcpu *v) { int i; @@ -260,8 +268,8 @@ static void __cpuinit gic_cpu_init(void) { int i; - /* The first 32 interrupts (PPI and SGI) are banked per-cpu, so - * even though they are controlled with GICD registers, they must + /* The first 32 interrupts (PPI and SGI) are banked per-cpu, so + * even though they are controlled with GICD registers, they must * be set up here with the other per-cpu state. */ GICD[GICD_ICENABLER] = 0xffff0000; /* Disable all PPI */ GICD[GICD_ISENABLER] = 0x0000ffff; /* Enable all SGI */ @@ -342,7 +350,7 @@ void gic_disable_cpu(void) spin_unlock_irq(&gic.lock); } -void gic_route_irqs(void) +void gic_route_ppis(void) { /* XXX should get these from DT */ /* GIC maintenance */ @@ -351,6 +359,11 @@ void gic_route_irqs(void) gic_route_irq(26, 1, 1u << smp_processor_id(), 0xa0); /* Timer */ gic_route_irq(30, 1, 1u << smp_processor_id(), 0xa0); +} + +void gic_route_spis(void) +{ + /* XXX should get these from DT */ /* UART */ gic_route_irq(37, 0, 1u << smp_processor_id(), 0xa0); } @@ -408,7 +421,7 @@ int __init setup_irq(unsigned int irq, struct irqaction *new) rc = __setup_irq(desc, irq, new); - spin_unlock_irqrestore(&desc->lock,flags); + spin_unlock_irqrestore(&desc->lock, flags); return rc; } diff --git a/xen/arch/arm/gic.h b/xen/arch/arm/gic.h index fa2cf06..b8f9f201 100644 --- a/xen/arch/arm/gic.h +++ b/xen/arch/arm/gic.h @@ -132,7 +132,8 @@ extern int vcpu_vgic_init(struct vcpu *v); extern void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq,int virtual); extern struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq); -extern void gic_route_irqs(void); +extern void gic_route_ppis(void); +extern void gic_route_spis(void); extern void gic_inject(void); diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c index f9d663b..72e83e6 100644 --- a/xen/arch/arm/irq.c +++ b/xen/arch/arm/irq.c @@ -58,20 +58,41 @@ static int __init init_irq_data(void) { int irq; - for (irq = 0; irq < NR_IRQS; irq++) { + for (irq = NR_LOCAL_IRQS; irq < NR_IRQS; irq++) { struct irq_desc *desc = irq_to_desc(irq); init_one_irq_desc(desc); desc->irq = irq; desc->action = NULL; } + + return 0; +} + +static int __cpuinit init_local_irq_data(void) +{ + int irq; + + for (irq = 0; irq < NR_LOCAL_IRQS; irq++) { + struct irq_desc *desc = irq_to_desc(irq); + init_one_irq_desc(desc); + desc->irq = irq; + desc->action = NULL; + } + return 0; } void __init init_IRQ(void) { + BUG_ON(init_local_irq_data() < 0); BUG_ON(init_irq_data() < 0); } +void __cpuinit init_secondary_IRQ(void) +{ + BUG_ON(init_local_irq_data() < 0); +} + int __init request_irq(unsigned int irq, void (*handler)(int, void *, struct cpu_user_regs *), unsigned long irqflags, const char * devname, void *dev_id) diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c index dc0e215..db8fe6a 100644 --- a/xen/arch/arm/setup.c +++ b/xen/arch/arm/setup.c @@ -200,7 +200,8 @@ void __init start_xen(unsigned long boot_phys_offset, init_IRQ(); - gic_route_irqs(); + gic_route_ppis(); + gic_route_spis(); init_maintenance_interrupt(); init_timer_interrupt(); diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c index 6463a8d..c0750c0 100644 --- a/xen/arch/arm/smpboot.c +++ b/xen/arch/arm/smpboot.c @@ -26,6 +26,8 @@ #include #include #include +#include +#include #include #include "gic.h" @@ -129,8 +131,13 @@ void __cpuinit start_secondary(unsigned long boot_phys_offset, enable_vfp(); gic_init_secondary_cpu(); + + init_secondary_IRQ(); + + gic_route_ppis(); + + init_maintenance_interrupt(); init_timer_interrupt(); - gic_route_irqs(); set_current(idle_vcpu[cpuid]); diff --git a/xen/include/asm-arm/irq.h b/xen/include/asm-arm/irq.h index 21e0b85..abde839 100644 --- a/xen/include/asm-arm/irq.h +++ b/xen/include/asm-arm/irq.h @@ -17,10 +17,23 @@ struct irq_cfg { #define arch_irq_desc irq_cfg }; +#define NR_LOCAL_IRQS 32 +#define NR_IRQS 1024 +#define nr_irqs NR_IRQS + +struct irq_desc; + +struct irq_desc *__irq_to_desc(int irq); + +#define irq_to_desc(irq) __irq_to_desc(irq) + void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq); #define domain_pirq_to_irq(d, pirq) (pirq) +void init_IRQ(void); +void init_secondary_IRQ(void); + #endif /* _ASM_HW_IRQ_H */ /* * Local variables: diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h index 6433b4e..8769f66 100644 --- a/xen/include/asm-arm/setup.h +++ b/xen/include/asm-arm/setup.h @@ -9,8 +9,6 @@ void arch_get_xen_caps(xen_capabilities_info_t *info); int construct_dom0(struct domain *d); -void init_IRQ(void); - #endif /* * Local variables: diff --git a/xen/include/xen/irq.h b/xen/include/xen/irq.h index cbe1dbc..5973cce 100644 --- a/xen/include/xen/irq.h +++ b/xen/include/xen/irq.h @@ -88,21 +88,15 @@ typedef struct irq_desc { struct list_head rl_link; } __cacheline_aligned irq_desc_t; +#ifndef irq_to_desc #define irq_to_desc(irq) (&irq_desc[irq]) +#endif int init_one_irq_desc(struct irq_desc *); int arch_init_one_irq_desc(struct irq_desc *); #define irq_desc_initialized(desc) ((desc)->handler != NULL) -#if defined(__arm__) - -#define NR_IRQS 1024 -#define nr_irqs NR_IRQS -extern irq_desc_t irq_desc[NR_IRQS]; - -#endif - extern int setup_irq(unsigned int irq, struct irqaction *); extern void release_irq(unsigned int irq); extern int request_irq(unsigned int irq, -- 1.7.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 10:52:30 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 10:52:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5W4-0002vT-Eg; Fri, 05 Oct 2012 10:52:24 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5W2-0002uH-Va for xen-devel@lists.xen.org; Fri, 05 Oct 2012 10:52:23 +0000 Received: from [85.158.143.99:18566] by server-1.bemta-4.messagelabs.com id 83/88-05684-6EBBE605; Fri, 05 Oct 2012 10:52:22 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1349434338!24861283!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODA1MjM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26888 invoked from network); 5 Oct 2012 10:52:21 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 10:52:21 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="210397091" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 10:52:20 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 06:52:20 -0400 Received: from [10.80.246.74] (helo=army.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK5Ib-0003Rm-9y; Fri, 05 Oct 2012 11:38:29 +0100 From: Ian Campbell To: Date: Fri, 5 Oct 2012 10:38:21 +0000 Message-ID: <1349433507-21148-15-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.9.1 In-Reply-To: <1349433418.20946.46.camel@zakaz.uk.xensource.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: tim@xen.org, Ian Campbell , stefano.stabelini@citrix.com Subject: [Xen-devel] [PATCH 15/21] arm: Use per-CPU irq_desc for PPIs and SGIs X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org The first 32 interrupts on a GIC are the Peripheral Private Interrupts and Software-Generated Interrupts and are local to each processor. The irq_desc cannot be shared since we use irq_desc->status to track whether the IRQ is in-progress etc. Therefore give each processor its own local irq_desc for each of these interupts. We must also route them on each CPU, so do so. This feels like a bit of a layering violation (since the core ARM irq.c now knows about thinkgs wich are really gic.c business) Signed-off-by: Ian Campbell Acked-by: Tim Deegan --- xen/arch/arm/gic.c | 23 ++++++++++++++++++----- xen/arch/arm/gic.h | 3 ++- xen/arch/arm/irq.c | 23 ++++++++++++++++++++++- xen/arch/arm/setup.c | 3 ++- xen/arch/arm/smpboot.c | 9 ++++++++- xen/include/asm-arm/irq.h | 13 +++++++++++++ xen/include/asm-arm/setup.h | 2 -- xen/include/xen/irq.h | 10 ++-------- 8 files changed, 67 insertions(+), 19 deletions(-) diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c index ab93404..5f06e08 100644 --- a/xen/arch/arm/gic.c +++ b/xen/arch/arm/gic.c @@ -50,9 +50,17 @@ static struct { uint64_t lr_mask; } gic; -irq_desc_t irq_desc[NR_IRQS]; +static irq_desc_t irq_desc[NR_IRQS]; +static DEFINE_PER_CPU(irq_desc_t[NR_LOCAL_IRQS], local_irq_desc); + unsigned nr_lrs; +irq_desc_t *__irq_to_desc(int irq) +{ + if (irq < NR_LOCAL_IRQS) return &this_cpu(local_irq_desc)[irq]; + return &irq_desc[irq-NR_LOCAL_IRQS]; +} + void gic_save_state(struct vcpu *v) { int i; @@ -260,8 +268,8 @@ static void __cpuinit gic_cpu_init(void) { int i; - /* The first 32 interrupts (PPI and SGI) are banked per-cpu, so - * even though they are controlled with GICD registers, they must + /* The first 32 interrupts (PPI and SGI) are banked per-cpu, so + * even though they are controlled with GICD registers, they must * be set up here with the other per-cpu state. */ GICD[GICD_ICENABLER] = 0xffff0000; /* Disable all PPI */ GICD[GICD_ISENABLER] = 0x0000ffff; /* Enable all SGI */ @@ -342,7 +350,7 @@ void gic_disable_cpu(void) spin_unlock_irq(&gic.lock); } -void gic_route_irqs(void) +void gic_route_ppis(void) { /* XXX should get these from DT */ /* GIC maintenance */ @@ -351,6 +359,11 @@ void gic_route_irqs(void) gic_route_irq(26, 1, 1u << smp_processor_id(), 0xa0); /* Timer */ gic_route_irq(30, 1, 1u << smp_processor_id(), 0xa0); +} + +void gic_route_spis(void) +{ + /* XXX should get these from DT */ /* UART */ gic_route_irq(37, 0, 1u << smp_processor_id(), 0xa0); } @@ -408,7 +421,7 @@ int __init setup_irq(unsigned int irq, struct irqaction *new) rc = __setup_irq(desc, irq, new); - spin_unlock_irqrestore(&desc->lock,flags); + spin_unlock_irqrestore(&desc->lock, flags); return rc; } diff --git a/xen/arch/arm/gic.h b/xen/arch/arm/gic.h index fa2cf06..b8f9f201 100644 --- a/xen/arch/arm/gic.h +++ b/xen/arch/arm/gic.h @@ -132,7 +132,8 @@ extern int vcpu_vgic_init(struct vcpu *v); extern void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq,int virtual); extern struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq); -extern void gic_route_irqs(void); +extern void gic_route_ppis(void); +extern void gic_route_spis(void); extern void gic_inject(void); diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c index f9d663b..72e83e6 100644 --- a/xen/arch/arm/irq.c +++ b/xen/arch/arm/irq.c @@ -58,20 +58,41 @@ static int __init init_irq_data(void) { int irq; - for (irq = 0; irq < NR_IRQS; irq++) { + for (irq = NR_LOCAL_IRQS; irq < NR_IRQS; irq++) { struct irq_desc *desc = irq_to_desc(irq); init_one_irq_desc(desc); desc->irq = irq; desc->action = NULL; } + + return 0; +} + +static int __cpuinit init_local_irq_data(void) +{ + int irq; + + for (irq = 0; irq < NR_LOCAL_IRQS; irq++) { + struct irq_desc *desc = irq_to_desc(irq); + init_one_irq_desc(desc); + desc->irq = irq; + desc->action = NULL; + } + return 0; } void __init init_IRQ(void) { + BUG_ON(init_local_irq_data() < 0); BUG_ON(init_irq_data() < 0); } +void __cpuinit init_secondary_IRQ(void) +{ + BUG_ON(init_local_irq_data() < 0); +} + int __init request_irq(unsigned int irq, void (*handler)(int, void *, struct cpu_user_regs *), unsigned long irqflags, const char * devname, void *dev_id) diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c index dc0e215..db8fe6a 100644 --- a/xen/arch/arm/setup.c +++ b/xen/arch/arm/setup.c @@ -200,7 +200,8 @@ void __init start_xen(unsigned long boot_phys_offset, init_IRQ(); - gic_route_irqs(); + gic_route_ppis(); + gic_route_spis(); init_maintenance_interrupt(); init_timer_interrupt(); diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c index 6463a8d..c0750c0 100644 --- a/xen/arch/arm/smpboot.c +++ b/xen/arch/arm/smpboot.c @@ -26,6 +26,8 @@ #include #include #include +#include +#include #include #include "gic.h" @@ -129,8 +131,13 @@ void __cpuinit start_secondary(unsigned long boot_phys_offset, enable_vfp(); gic_init_secondary_cpu(); + + init_secondary_IRQ(); + + gic_route_ppis(); + + init_maintenance_interrupt(); init_timer_interrupt(); - gic_route_irqs(); set_current(idle_vcpu[cpuid]); diff --git a/xen/include/asm-arm/irq.h b/xen/include/asm-arm/irq.h index 21e0b85..abde839 100644 --- a/xen/include/asm-arm/irq.h +++ b/xen/include/asm-arm/irq.h @@ -17,10 +17,23 @@ struct irq_cfg { #define arch_irq_desc irq_cfg }; +#define NR_LOCAL_IRQS 32 +#define NR_IRQS 1024 +#define nr_irqs NR_IRQS + +struct irq_desc; + +struct irq_desc *__irq_to_desc(int irq); + +#define irq_to_desc(irq) __irq_to_desc(irq) + void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq); #define domain_pirq_to_irq(d, pirq) (pirq) +void init_IRQ(void); +void init_secondary_IRQ(void); + #endif /* _ASM_HW_IRQ_H */ /* * Local variables: diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h index 6433b4e..8769f66 100644 --- a/xen/include/asm-arm/setup.h +++ b/xen/include/asm-arm/setup.h @@ -9,8 +9,6 @@ void arch_get_xen_caps(xen_capabilities_info_t *info); int construct_dom0(struct domain *d); -void init_IRQ(void); - #endif /* * Local variables: diff --git a/xen/include/xen/irq.h b/xen/include/xen/irq.h index cbe1dbc..5973cce 100644 --- a/xen/include/xen/irq.h +++ b/xen/include/xen/irq.h @@ -88,21 +88,15 @@ typedef struct irq_desc { struct list_head rl_link; } __cacheline_aligned irq_desc_t; +#ifndef irq_to_desc #define irq_to_desc(irq) (&irq_desc[irq]) +#endif int init_one_irq_desc(struct irq_desc *); int arch_init_one_irq_desc(struct irq_desc *); #define irq_desc_initialized(desc) ((desc)->handler != NULL) -#if defined(__arm__) - -#define NR_IRQS 1024 -#define nr_irqs NR_IRQS -extern irq_desc_t irq_desc[NR_IRQS]; - -#endif - extern int setup_irq(unsigned int irq, struct irqaction *); extern void release_irq(unsigned int irq); extern int request_irq(unsigned int irq, -- 1.7.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 10:52:30 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 10:52:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5W1-0002tz-TC; Fri, 05 Oct 2012 10:52:21 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5W0-0002t7-AN for xen-devel@lists.xen.org; Fri, 05 Oct 2012 10:52:20 +0000 Received: from [85.158.139.211:52408] by server-1.bemta-5.messagelabs.com id 15/AC-09825-3EBBE605; Fri, 05 Oct 2012 10:52:19 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-5.tower-206.messagelabs.com!1349434335!21149639!2 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ1ODc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13580 invoked from network); 5 Oct 2012 10:52:19 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 10:52:19 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="40249332" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 10:52:18 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 06:52:18 -0400 Received: from [10.80.246.74] (helo=army.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK5Ib-0003Rm-4X; Fri, 05 Oct 2012 11:38:29 +0100 From: Ian Campbell To: Date: Fri, 5 Oct 2012 10:38:19 +0000 Message-ID: <1349433507-21148-13-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.9.1 In-Reply-To: <1349433418.20946.46.camel@zakaz.uk.xensource.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: tim@xen.org, Ian Campbell , stefano.stabelini@citrix.com Subject: [Xen-devel] [PATCH 13/21] arm: don't bother setting up vtimer, vgic etc on idle CPUs X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Ian Campbell Acked-by: Tim Deegan --- xen/arch/arm/domain.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c index ee58d68..f47db4f 100644 --- a/xen/arch/arm/domain.c +++ b/xen/arch/arm/domain.c @@ -386,6 +386,10 @@ int vcpu_initialise(struct vcpu *v) v->arch.saved_context.sp = (uint32_t)v->arch.cpu_info; v->arch.saved_context.pc = (uint32_t)continue_new_vcpu; + /* Idle VCPUs don't need the rest of this setup */ + if ( is_idle_vcpu(v) ) + return rc; + if ( (rc = vcpu_vgic_init(v)) != 0 ) return rc; -- 1.7.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 10:52:30 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 10:52:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5W1-0002tz-TC; Fri, 05 Oct 2012 10:52:21 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5W0-0002t7-AN for xen-devel@lists.xen.org; Fri, 05 Oct 2012 10:52:20 +0000 Received: from [85.158.139.211:52408] by server-1.bemta-5.messagelabs.com id 15/AC-09825-3EBBE605; Fri, 05 Oct 2012 10:52:19 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-5.tower-206.messagelabs.com!1349434335!21149639!2 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ1ODc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13580 invoked from network); 5 Oct 2012 10:52:19 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 10:52:19 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="40249332" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 10:52:18 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 06:52:18 -0400 Received: from [10.80.246.74] (helo=army.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK5Ib-0003Rm-4X; Fri, 05 Oct 2012 11:38:29 +0100 From: Ian Campbell To: Date: Fri, 5 Oct 2012 10:38:19 +0000 Message-ID: <1349433507-21148-13-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.9.1 In-Reply-To: <1349433418.20946.46.camel@zakaz.uk.xensource.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: tim@xen.org, Ian Campbell , stefano.stabelini@citrix.com Subject: [Xen-devel] [PATCH 13/21] arm: don't bother setting up vtimer, vgic etc on idle CPUs X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Ian Campbell Acked-by: Tim Deegan --- xen/arch/arm/domain.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c index ee58d68..f47db4f 100644 --- a/xen/arch/arm/domain.c +++ b/xen/arch/arm/domain.c @@ -386,6 +386,10 @@ int vcpu_initialise(struct vcpu *v) v->arch.saved_context.sp = (uint32_t)v->arch.cpu_info; v->arch.saved_context.pc = (uint32_t)continue_new_vcpu; + /* Idle VCPUs don't need the rest of this setup */ + if ( is_idle_vcpu(v) ) + return rc; + if ( (rc = vcpu_vgic_init(v)) != 0 ) return rc; -- 1.7.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 10:52:30 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 10:52:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5W1-0002tm-EQ; Fri, 05 Oct 2012 10:52:21 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5W0-0002t4-3J for xen-devel@lists.xen.org; Fri, 05 Oct 2012 10:52:20 +0000 Received: from [85.158.143.35:42771] by server-2.bemta-4.messagelabs.com id C5/A5-06610-3EBBE605; Fri, 05 Oct 2012 10:52:19 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1349434334!13826764!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ1ODc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29757 invoked from network); 5 Oct 2012 10:52:15 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 10:52:15 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="40249327" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 10:52:13 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 06:52:13 -0400 Received: from [10.80.246.74] (helo=army.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK5Ib-0003Rm-CJ; Fri, 05 Oct 2012 11:38:29 +0100 From: Ian Campbell To: Date: Fri, 5 Oct 2012 10:38:22 +0000 Message-ID: <1349433507-21148-16-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.9.1 In-Reply-To: <1349433418.20946.46.camel@zakaz.uk.xensource.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: tim@xen.org, Ian Campbell , stefano.stabelini@citrix.com Subject: [Xen-devel] [PATCH 16/21] arm: tools: add arm to foreign structs checking X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Ian Campbell --- tools/include/xen-foreign/Makefile | 5 ++++- tools/include/xen-foreign/mkheader.py | 7 +++++++ tools/include/xen-foreign/reference.size | 27 +++++++++++++++------------ tools/include/xen-foreign/structs.py | 7 ++++++- 4 files changed, 32 insertions(+), 14 deletions(-) diff --git a/tools/include/xen-foreign/Makefile b/tools/include/xen-foreign/Makefile index 8b22b10..cfaf790 100644 --- a/tools/include/xen-foreign/Makefile +++ b/tools/include/xen-foreign/Makefile @@ -3,7 +3,7 @@ include $(XEN_ROOT)/tools/Rules.mk ROOT = $(XEN_ROOT)/xen/include/public -architectures := x86_32 x86_64 +architectures := arm x86_32 x86_64 headers := $(patsubst %, %.h, $(architectures)) .PHONY: all clean check-headers @@ -22,6 +22,9 @@ check-headers: checker diff -u reference.size tmp.size rm tmp.size +arm.h: mkheader.py structs.py $(ROOT)/arch-arm.h + $(PYTHON) $< $* $@ $(filter %.h,$^) + x86_32.h: mkheader.py structs.py $(ROOT)/arch-x86/xen-x86_32.h $(ROOT)/arch-x86/xen.h $(ROOT)/xen.h $(PYTHON) $< $* $@ $(filter %.h,$^) diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py index 797a880..d189b07 100644 --- a/tools/include/xen-foreign/mkheader.py +++ b/tools/include/xen-foreign/mkheader.py @@ -16,6 +16,13 @@ inttypes = {}; header = {}; footer = {}; +#arm +inttypes["arm"] = { + "unsigned long" : "uint32_t", + "long" : "uint32_t", + "xen_pfn_t" : "uint64_t", +}; + # x86_32 inttypes["x86_32"] = { "unsigned long" : "uint32_t", diff --git a/tools/include/xen-foreign/reference.size b/tools/include/xen-foreign/reference.size index fac1b1d..3c67ad8 100644 --- a/tools/include/xen-foreign/reference.size +++ b/tools/include/xen-foreign/reference.size @@ -1,13 +1,16 @@ +structs | arm x86_32 x86_64 -structs | x86_32 x86_64 - -start_info | 1112 1168 -trap_info | 8 16 -cpu_user_regs | 68 200 -vcpu_guest_context | 2800 5168 -arch_vcpu_info | 24 16 -vcpu_time_info | 32 32 -vcpu_info | 64 64 -arch_shared_info | 268 280 -shared_info | 2584 3368 - +start_info | - 1112 1168 +trap_info | - 8 16 +pt_fpreg | - - - +cpu_user_regs | 160 68 200 +xen_ia64_boot_param | - - - +ia64_tr_entry | - - - +vcpu_tr_regs | - - - +vcpu_guest_context_regs | - - - +vcpu_guest_context | 180 2800 5168 +arch_vcpu_info | - 24 16 +vcpu_time_info | - 32 32 +vcpu_info | - 64 64 +arch_shared_info | - 268 280 +shared_info | - 2584 3368 diff --git a/tools/include/xen-foreign/structs.py b/tools/include/xen-foreign/structs.py index 571f7bb..988bef2 100644 --- a/tools/include/xen-foreign/structs.py +++ b/tools/include/xen-foreign/structs.py @@ -13,9 +13,14 @@ structs = [ "start_info", "arch_shared_info", "shared_info" ]; -defines = [ "__i386__", +defines = [ "__arm__", + "__i386__", "__x86_64__", + # arm + # None + + # x86_{32,64} "FLAT_RING1_CS", "FLAT_RING1_DS", "FLAT_RING1_SS", -- 1.7.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 10:52:30 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 10:52:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5W1-0002tm-EQ; Fri, 05 Oct 2012 10:52:21 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5W0-0002t4-3J for xen-devel@lists.xen.org; Fri, 05 Oct 2012 10:52:20 +0000 Received: from [85.158.143.35:42771] by server-2.bemta-4.messagelabs.com id C5/A5-06610-3EBBE605; Fri, 05 Oct 2012 10:52:19 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1349434334!13826764!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ1ODc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29757 invoked from network); 5 Oct 2012 10:52:15 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 10:52:15 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="40249327" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 10:52:13 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 06:52:13 -0400 Received: from [10.80.246.74] (helo=army.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK5Ib-0003Rm-CJ; Fri, 05 Oct 2012 11:38:29 +0100 From: Ian Campbell To: Date: Fri, 5 Oct 2012 10:38:22 +0000 Message-ID: <1349433507-21148-16-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.9.1 In-Reply-To: <1349433418.20946.46.camel@zakaz.uk.xensource.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: tim@xen.org, Ian Campbell , stefano.stabelini@citrix.com Subject: [Xen-devel] [PATCH 16/21] arm: tools: add arm to foreign structs checking X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Ian Campbell --- tools/include/xen-foreign/Makefile | 5 ++++- tools/include/xen-foreign/mkheader.py | 7 +++++++ tools/include/xen-foreign/reference.size | 27 +++++++++++++++------------ tools/include/xen-foreign/structs.py | 7 ++++++- 4 files changed, 32 insertions(+), 14 deletions(-) diff --git a/tools/include/xen-foreign/Makefile b/tools/include/xen-foreign/Makefile index 8b22b10..cfaf790 100644 --- a/tools/include/xen-foreign/Makefile +++ b/tools/include/xen-foreign/Makefile @@ -3,7 +3,7 @@ include $(XEN_ROOT)/tools/Rules.mk ROOT = $(XEN_ROOT)/xen/include/public -architectures := x86_32 x86_64 +architectures := arm x86_32 x86_64 headers := $(patsubst %, %.h, $(architectures)) .PHONY: all clean check-headers @@ -22,6 +22,9 @@ check-headers: checker diff -u reference.size tmp.size rm tmp.size +arm.h: mkheader.py structs.py $(ROOT)/arch-arm.h + $(PYTHON) $< $* $@ $(filter %.h,$^) + x86_32.h: mkheader.py structs.py $(ROOT)/arch-x86/xen-x86_32.h $(ROOT)/arch-x86/xen.h $(ROOT)/xen.h $(PYTHON) $< $* $@ $(filter %.h,$^) diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py index 797a880..d189b07 100644 --- a/tools/include/xen-foreign/mkheader.py +++ b/tools/include/xen-foreign/mkheader.py @@ -16,6 +16,13 @@ inttypes = {}; header = {}; footer = {}; +#arm +inttypes["arm"] = { + "unsigned long" : "uint32_t", + "long" : "uint32_t", + "xen_pfn_t" : "uint64_t", +}; + # x86_32 inttypes["x86_32"] = { "unsigned long" : "uint32_t", diff --git a/tools/include/xen-foreign/reference.size b/tools/include/xen-foreign/reference.size index fac1b1d..3c67ad8 100644 --- a/tools/include/xen-foreign/reference.size +++ b/tools/include/xen-foreign/reference.size @@ -1,13 +1,16 @@ +structs | arm x86_32 x86_64 -structs | x86_32 x86_64 - -start_info | 1112 1168 -trap_info | 8 16 -cpu_user_regs | 68 200 -vcpu_guest_context | 2800 5168 -arch_vcpu_info | 24 16 -vcpu_time_info | 32 32 -vcpu_info | 64 64 -arch_shared_info | 268 280 -shared_info | 2584 3368 - +start_info | - 1112 1168 +trap_info | - 8 16 +pt_fpreg | - - - +cpu_user_regs | 160 68 200 +xen_ia64_boot_param | - - - +ia64_tr_entry | - - - +vcpu_tr_regs | - - - +vcpu_guest_context_regs | - - - +vcpu_guest_context | 180 2800 5168 +arch_vcpu_info | - 24 16 +vcpu_time_info | - 32 32 +vcpu_info | - 64 64 +arch_shared_info | - 268 280 +shared_info | - 2584 3368 diff --git a/tools/include/xen-foreign/structs.py b/tools/include/xen-foreign/structs.py index 571f7bb..988bef2 100644 --- a/tools/include/xen-foreign/structs.py +++ b/tools/include/xen-foreign/structs.py @@ -13,9 +13,14 @@ structs = [ "start_info", "arch_shared_info", "shared_info" ]; -defines = [ "__i386__", +defines = [ "__arm__", + "__i386__", "__x86_64__", + # arm + # None + + # x86_{32,64} "FLAT_RING1_CS", "FLAT_RING1_DS", "FLAT_RING1_SS", -- 1.7.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 10:52:30 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 10:52:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5W3-0002uh-Bd; Fri, 05 Oct 2012 10:52:23 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5W1-0002t4-Rk for xen-devel@lists.xen.org; Fri, 05 Oct 2012 10:52:22 +0000 Received: from [85.158.143.35:42875] by server-2.bemta-4.messagelabs.com id E3/B5-06610-5EBBE605; Fri, 05 Oct 2012 10:52:21 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1349434334!13826764!2 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ1ODc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29827 invoked from network); 5 Oct 2012 10:52:16 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 10:52:16 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="40249329" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 10:52:15 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 06:52:15 -0400 Received: from [10.80.246.74] (helo=army.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK5Ib-0003Rm-MK; Fri, 05 Oct 2012 11:38:29 +0100 From: Ian Campbell To: Date: Fri, 5 Oct 2012 10:38:25 +0000 Message-ID: <1349433507-21148-19-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.9.1 In-Reply-To: <1349433418.20946.46.camel@zakaz.uk.xensource.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: keir@xen.org, Stefano Stabellini , tim@xen.org, JBeulich@suse.com, stefano.stabelini@citrix.com Subject: [Xen-devel] [PATCH 19/21] xen: introduce XEN_GUEST_HANDLE_PARAM X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Stefano Stabellini XEN_GUEST_HANDLE_PARAM is going to be used to distinguish guest pointers stored in memory from guest pointers as hypercall parameters. guest_handle_* macros default to XEN_GUEST_HANDLE_PARAM as return type. Two new guest_handle_to_param and guest_handle_from_param macros are introduced to do conversions. Changes in v2: - add 2 missing #define _XEN_GUEST_HANDLE_PARAM for the compilation of the compat code. Changes in v3: - move the guest_handle_cast change into this patch; - add a clear comment on top of guest_handle_cast; - also s/XEN_GUEST_HANDLE/XEN_GUEST_HANDLE_PARAM in guest_handle_from_ptr and const_guest_handle_from_ptr; - introduce guest_handle_from_param and guest_handle_to_param. Changes in v4: - make both XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM unions on ARM; - simplify set_xen_guest_handle_raw on ARM; - add type checking in guest_handle_to_param and guest_handle_from_param trivial. Changes in v5 (ijc): - Fix arm's set_xen_guest_handle_raw which mixed up t and _t. Use a more unique variable name for the benefit of -Wshadow. Signed-off-by: Stefano Stabellini Cc: keir@xen.org Cc: JBeulich@suse.com --- This patch seems to cause issues with bisection, see <1349428386.20946.15.camel@zakaz.uk.xensource.com> -- ijc --- xen/include/asm-arm/guest_access.h | 32 ++++++++++++++++++++++++++++---- xen/include/asm-x86/guest_access.h | 29 +++++++++++++++++++++++++---- xen/include/public/arch-arm.h | 26 ++++++++++++++++++++++---- xen/include/public/arch-x86/xen.h | 9 +++++++++ xen/include/xen/xencomm.h | 22 +++++++++++++++++++++- 5 files changed, 105 insertions(+), 13 deletions(-) diff --git a/xen/include/asm-arm/guest_access.h b/xen/include/asm-arm/guest_access.h index 0fceae6..5686217 100644 --- a/xen/include/asm-arm/guest_access.h +++ b/xen/include/asm-arm/guest_access.h @@ -27,16 +27,40 @@ unsigned long raw_clear_guest(void *to, unsigned len); #define guest_handle_add_offset(hnd, nr) ((hnd).p += (nr)) #define guest_handle_subtract_offset(hnd, nr) ((hnd).p -= (nr)) -/* Cast a guest handle to the specified type of handle. */ +/* Cast a guest handle (either XEN_GUEST_HANDLE or XEN_GUEST_HANDLE_PARAM) + * to the specified type of XEN_GUEST_HANDLE_PARAM. */ #define guest_handle_cast(hnd, type) ({ \ type *_x = (hnd).p; \ - (XEN_GUEST_HANDLE(type)) { _x }; \ + (XEN_GUEST_HANDLE_PARAM(type)) { _x }; \ +}) + +/* Cast a XEN_GUEST_HANDLE to XEN_GUEST_HANDLE_PARAM */ +#define guest_handle_to_param(hnd, type) ({ \ + typeof((hnd).p) _x = (hnd).p; \ + XEN_GUEST_HANDLE_PARAM(type) _y = { _x }; \ + /* type checking: make sure that the pointers inside \ + * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of \ + * the same type, then return hnd */ \ + (void)(&_x == &_y.p); \ + _y; \ +}) + + +/* Cast a XEN_GUEST_HANDLE_PARAM to XEN_GUEST_HANDLE */ +#define guest_handle_from_param(hnd, type) ({ \ + typeof((hnd).p) _x = (hnd).p; \ + XEN_GUEST_HANDLE(type) _y = { _x }; \ + /* type checking: make sure that the pointers inside \ + * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of \ + * the same type, then return hnd */ \ + (void)(&_x == &_y.p); \ + _y; \ }) #define guest_handle_from_ptr(ptr, type) \ - ((XEN_GUEST_HANDLE(type)) { (type *)ptr }) + ((XEN_GUEST_HANDLE_PARAM(type)) { (type *)ptr }) #define const_guest_handle_from_ptr(ptr, type) \ - ((XEN_GUEST_HANDLE(const_##type)) { (const type *)ptr }) + ((XEN_GUEST_HANDLE_PARAM(const_##type)) { (const type *)ptr }) /* * Copy an array of objects to guest context via a guest handle, diff --git a/xen/include/asm-x86/guest_access.h b/xen/include/asm-x86/guest_access.h index e3ac1d6..ca700c9 100644 --- a/xen/include/asm-x86/guest_access.h +++ b/xen/include/asm-x86/guest_access.h @@ -45,19 +45,40 @@ #define guest_handle_add_offset(hnd, nr) ((hnd).p += (nr)) #define guest_handle_subtract_offset(hnd, nr) ((hnd).p -= (nr)) -/* Cast a guest handle to the specified type of handle. */ +/* Cast a guest handle (either XEN_GUEST_HANDLE or XEN_GUEST_HANDLE_PARAM) + * to the specified type of XEN_GUEST_HANDLE_PARAM. */ #define guest_handle_cast(hnd, type) ({ \ type *_x = (hnd).p; \ - (XEN_GUEST_HANDLE(type)) { _x }; \ + (XEN_GUEST_HANDLE_PARAM(type)) { _x }; \ +}) + +/* Cast a XEN_GUEST_HANDLE to XEN_GUEST_HANDLE_PARAM */ +#define guest_handle_to_param(hnd, type) ({ \ + /* type checking: make sure that the pointers inside \ + * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of \ + * the same type, then return hnd */ \ + (void)((typeof(&(hnd).p)) 0 == \ + (typeof(&((XEN_GUEST_HANDLE_PARAM(type)) {}).p)) 0); \ + (hnd); \ +}) + +/* Cast a XEN_GUEST_HANDLE_PARAM to XEN_GUEST_HANDLE */ +#define guest_handle_from_param(hnd, type) ({ \ + /* type checking: make sure that the pointers inside \ + * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of \ + * the same type, then return hnd */ \ + (void)((typeof(&(hnd).p)) 0 == \ + (typeof(&((XEN_GUEST_HANDLE_PARAM(type)) {}).p)) 0); \ + (hnd); \ }) #define guest_handle_for_field(hnd, type, fld) \ ((XEN_GUEST_HANDLE(type)) { &(hnd).p->fld }) #define guest_handle_from_ptr(ptr, type) \ - ((XEN_GUEST_HANDLE(type)) { (type *)ptr }) + ((XEN_GUEST_HANDLE_PARAM(type)) { (type *)ptr }) #define const_guest_handle_from_ptr(ptr, type) \ - ((XEN_GUEST_HANDLE(const_##type)) { (const type *)ptr }) + ((XEN_GUEST_HANDLE_PARAM(const_##type)) { (const type *)ptr }) /* * Copy an array of objects to guest context via a guest handle, diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h index 2ae6548..d5d8209 100644 --- a/xen/include/public/arch-arm.h +++ b/xen/include/public/arch-arm.h @@ -51,18 +51,36 @@ #define XEN_HYPERCALL_TAG 0XEA1 +#define uint64_aligned_t uint64_t __attribute__((aligned(8))) #ifndef __ASSEMBLY__ -#define ___DEFINE_XEN_GUEST_HANDLE(name, type) \ - typedef struct { type *p; } __guest_handle_ ## name +#define ___DEFINE_XEN_GUEST_HANDLE(name, type) \ + typedef union { type *p; unsigned long q; } \ + __guest_handle_ ## name; \ + typedef union { type *p; uint64_aligned_t q; } \ + __guest_handle_64_ ## name; +/* + * XEN_GUEST_HANDLE represents a guest pointer, when passed as a field + * in a struct in memory. On ARM is always 8 bytes sizes and 8 bytes + * aligned. + * XEN_GUEST_HANDLE_PARAM represent a guest pointer, when passed as an + * hypercall argument. It is 4 bytes on aarch and 8 bytes on aarch64. + */ #define __DEFINE_XEN_GUEST_HANDLE(name, type) \ ___DEFINE_XEN_GUEST_HANDLE(name, type); \ ___DEFINE_XEN_GUEST_HANDLE(const_##name, const type) #define DEFINE_XEN_GUEST_HANDLE(name) __DEFINE_XEN_GUEST_HANDLE(name, name) -#define __XEN_GUEST_HANDLE(name) __guest_handle_ ## name +#define __XEN_GUEST_HANDLE(name) __guest_handle_64_ ## name #define XEN_GUEST_HANDLE(name) __XEN_GUEST_HANDLE(name) -#define set_xen_guest_handle_raw(hnd, val) do { (hnd).p = val; } while (0) +/* this is going to be changes on 64 bit */ +#define XEN_GUEST_HANDLE_PARAM(name) __guest_handle_ ## name +#define set_xen_guest_handle_raw(hnd, val) \ + do { \ + typeof(&(hnd)) _sxghr_tmp = &(hnd); \ + _sxghr_tmp->q = 0; \ + _sxghr_tmp->p = val; \ + } while ( 0 ) #ifdef __XEN_TOOLS__ #define get_xen_guest_handle(val, hnd) do { val = (hnd).p; } while (0) #endif diff --git a/xen/include/public/arch-x86/xen.h b/xen/include/public/arch-x86/xen.h index 1c186d7..0e10260 100644 --- a/xen/include/public/arch-x86/xen.h +++ b/xen/include/public/arch-x86/xen.h @@ -38,12 +38,21 @@ typedef type * __guest_handle_ ## name #endif +/* + * XEN_GUEST_HANDLE represents a guest pointer, when passed as a field + * in a struct in memory. + * XEN_GUEST_HANDLE_PARAM represent a guest pointer, when passed as an + * hypercall argument. + * XEN_GUEST_HANDLE_PARAM and XEN_GUEST_HANDLE are the same on X86 but + * they might not be on other architectures. + */ #define __DEFINE_XEN_GUEST_HANDLE(name, type) \ ___DEFINE_XEN_GUEST_HANDLE(name, type); \ ___DEFINE_XEN_GUEST_HANDLE(const_##name, const type) #define DEFINE_XEN_GUEST_HANDLE(name) __DEFINE_XEN_GUEST_HANDLE(name, name) #define __XEN_GUEST_HANDLE(name) __guest_handle_ ## name #define XEN_GUEST_HANDLE(name) __XEN_GUEST_HANDLE(name) +#define XEN_GUEST_HANDLE_PARAM(name) XEN_GUEST_HANDLE(name) #define set_xen_guest_handle_raw(hnd, val) do { (hnd).p = val; } while (0) #ifdef __XEN_TOOLS__ #define get_xen_guest_handle(val, hnd) do { val = (hnd).p; } while (0) diff --git a/xen/include/xen/xencomm.h b/xen/include/xen/xencomm.h index 730da7c..3426b8a 100644 --- a/xen/include/xen/xencomm.h +++ b/xen/include/xen/xencomm.h @@ -66,11 +66,31 @@ static inline unsigned long xencomm_inline_addr(const void *handle) /* Cast a guest handle to the specified type of handle. */ #define guest_handle_cast(hnd, type) ({ \ type *_x = (hnd).p; \ - XEN_GUEST_HANDLE(type) _y; \ + XEN_GUEST_HANDLE_PARAM(type) _y; \ set_xen_guest_handle(_y, _x); \ _y; \ }) +/* Cast a XEN_GUEST_HANDLE to XEN_GUEST_HANDLE_PARAM */ +#define guest_handle_to_param(hnd, type) ({ \ + /* type checking: make sure that the pointers inside \ + * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of \ + * the same type, then return hnd */ \ + (void)((typeof(&(hnd).p)) 0 == \ + (typeof(&((XEN_GUEST_HANDLE_PARAM(type)) {}).p)) 0); \ + (hnd); \ +}) + +/* Cast a XEN_GUEST_HANDLE_PARAM to XEN_GUEST_HANDLE */ +#define guest_handle_from_param(hnd, type) ({ \ + /* type checking: make sure that the pointers inside \ + * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of \ + * the same type, then return hnd */ \ + (void)((typeof(&(hnd).p)) 0 == \ + (typeof(&((XEN_GUEST_HANDLE_PARAM(type)) {}).p)) 0); \ + (hnd); \ +}) + /* Since we run in real mode, we can safely access all addresses. That also * means our __routines are identical to our "normal" routines. */ #define guest_handle_okay(hnd, nr) 1 -- 1.7.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 10:52:30 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 10:52:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5W3-0002uh-Bd; Fri, 05 Oct 2012 10:52:23 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5W1-0002t4-Rk for xen-devel@lists.xen.org; Fri, 05 Oct 2012 10:52:22 +0000 Received: from [85.158.143.35:42875] by server-2.bemta-4.messagelabs.com id E3/B5-06610-5EBBE605; Fri, 05 Oct 2012 10:52:21 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1349434334!13826764!2 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ1ODc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29827 invoked from network); 5 Oct 2012 10:52:16 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 10:52:16 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="40249329" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 10:52:15 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 06:52:15 -0400 Received: from [10.80.246.74] (helo=army.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK5Ib-0003Rm-MK; Fri, 05 Oct 2012 11:38:29 +0100 From: Ian Campbell To: Date: Fri, 5 Oct 2012 10:38:25 +0000 Message-ID: <1349433507-21148-19-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.9.1 In-Reply-To: <1349433418.20946.46.camel@zakaz.uk.xensource.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: keir@xen.org, Stefano Stabellini , tim@xen.org, JBeulich@suse.com, stefano.stabelini@citrix.com Subject: [Xen-devel] [PATCH 19/21] xen: introduce XEN_GUEST_HANDLE_PARAM X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Stefano Stabellini XEN_GUEST_HANDLE_PARAM is going to be used to distinguish guest pointers stored in memory from guest pointers as hypercall parameters. guest_handle_* macros default to XEN_GUEST_HANDLE_PARAM as return type. Two new guest_handle_to_param and guest_handle_from_param macros are introduced to do conversions. Changes in v2: - add 2 missing #define _XEN_GUEST_HANDLE_PARAM for the compilation of the compat code. Changes in v3: - move the guest_handle_cast change into this patch; - add a clear comment on top of guest_handle_cast; - also s/XEN_GUEST_HANDLE/XEN_GUEST_HANDLE_PARAM in guest_handle_from_ptr and const_guest_handle_from_ptr; - introduce guest_handle_from_param and guest_handle_to_param. Changes in v4: - make both XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM unions on ARM; - simplify set_xen_guest_handle_raw on ARM; - add type checking in guest_handle_to_param and guest_handle_from_param trivial. Changes in v5 (ijc): - Fix arm's set_xen_guest_handle_raw which mixed up t and _t. Use a more unique variable name for the benefit of -Wshadow. Signed-off-by: Stefano Stabellini Cc: keir@xen.org Cc: JBeulich@suse.com --- This patch seems to cause issues with bisection, see <1349428386.20946.15.camel@zakaz.uk.xensource.com> -- ijc --- xen/include/asm-arm/guest_access.h | 32 ++++++++++++++++++++++++++++---- xen/include/asm-x86/guest_access.h | 29 +++++++++++++++++++++++++---- xen/include/public/arch-arm.h | 26 ++++++++++++++++++++++---- xen/include/public/arch-x86/xen.h | 9 +++++++++ xen/include/xen/xencomm.h | 22 +++++++++++++++++++++- 5 files changed, 105 insertions(+), 13 deletions(-) diff --git a/xen/include/asm-arm/guest_access.h b/xen/include/asm-arm/guest_access.h index 0fceae6..5686217 100644 --- a/xen/include/asm-arm/guest_access.h +++ b/xen/include/asm-arm/guest_access.h @@ -27,16 +27,40 @@ unsigned long raw_clear_guest(void *to, unsigned len); #define guest_handle_add_offset(hnd, nr) ((hnd).p += (nr)) #define guest_handle_subtract_offset(hnd, nr) ((hnd).p -= (nr)) -/* Cast a guest handle to the specified type of handle. */ +/* Cast a guest handle (either XEN_GUEST_HANDLE or XEN_GUEST_HANDLE_PARAM) + * to the specified type of XEN_GUEST_HANDLE_PARAM. */ #define guest_handle_cast(hnd, type) ({ \ type *_x = (hnd).p; \ - (XEN_GUEST_HANDLE(type)) { _x }; \ + (XEN_GUEST_HANDLE_PARAM(type)) { _x }; \ +}) + +/* Cast a XEN_GUEST_HANDLE to XEN_GUEST_HANDLE_PARAM */ +#define guest_handle_to_param(hnd, type) ({ \ + typeof((hnd).p) _x = (hnd).p; \ + XEN_GUEST_HANDLE_PARAM(type) _y = { _x }; \ + /* type checking: make sure that the pointers inside \ + * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of \ + * the same type, then return hnd */ \ + (void)(&_x == &_y.p); \ + _y; \ +}) + + +/* Cast a XEN_GUEST_HANDLE_PARAM to XEN_GUEST_HANDLE */ +#define guest_handle_from_param(hnd, type) ({ \ + typeof((hnd).p) _x = (hnd).p; \ + XEN_GUEST_HANDLE(type) _y = { _x }; \ + /* type checking: make sure that the pointers inside \ + * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of \ + * the same type, then return hnd */ \ + (void)(&_x == &_y.p); \ + _y; \ }) #define guest_handle_from_ptr(ptr, type) \ - ((XEN_GUEST_HANDLE(type)) { (type *)ptr }) + ((XEN_GUEST_HANDLE_PARAM(type)) { (type *)ptr }) #define const_guest_handle_from_ptr(ptr, type) \ - ((XEN_GUEST_HANDLE(const_##type)) { (const type *)ptr }) + ((XEN_GUEST_HANDLE_PARAM(const_##type)) { (const type *)ptr }) /* * Copy an array of objects to guest context via a guest handle, diff --git a/xen/include/asm-x86/guest_access.h b/xen/include/asm-x86/guest_access.h index e3ac1d6..ca700c9 100644 --- a/xen/include/asm-x86/guest_access.h +++ b/xen/include/asm-x86/guest_access.h @@ -45,19 +45,40 @@ #define guest_handle_add_offset(hnd, nr) ((hnd).p += (nr)) #define guest_handle_subtract_offset(hnd, nr) ((hnd).p -= (nr)) -/* Cast a guest handle to the specified type of handle. */ +/* Cast a guest handle (either XEN_GUEST_HANDLE or XEN_GUEST_HANDLE_PARAM) + * to the specified type of XEN_GUEST_HANDLE_PARAM. */ #define guest_handle_cast(hnd, type) ({ \ type *_x = (hnd).p; \ - (XEN_GUEST_HANDLE(type)) { _x }; \ + (XEN_GUEST_HANDLE_PARAM(type)) { _x }; \ +}) + +/* Cast a XEN_GUEST_HANDLE to XEN_GUEST_HANDLE_PARAM */ +#define guest_handle_to_param(hnd, type) ({ \ + /* type checking: make sure that the pointers inside \ + * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of \ + * the same type, then return hnd */ \ + (void)((typeof(&(hnd).p)) 0 == \ + (typeof(&((XEN_GUEST_HANDLE_PARAM(type)) {}).p)) 0); \ + (hnd); \ +}) + +/* Cast a XEN_GUEST_HANDLE_PARAM to XEN_GUEST_HANDLE */ +#define guest_handle_from_param(hnd, type) ({ \ + /* type checking: make sure that the pointers inside \ + * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of \ + * the same type, then return hnd */ \ + (void)((typeof(&(hnd).p)) 0 == \ + (typeof(&((XEN_GUEST_HANDLE_PARAM(type)) {}).p)) 0); \ + (hnd); \ }) #define guest_handle_for_field(hnd, type, fld) \ ((XEN_GUEST_HANDLE(type)) { &(hnd).p->fld }) #define guest_handle_from_ptr(ptr, type) \ - ((XEN_GUEST_HANDLE(type)) { (type *)ptr }) + ((XEN_GUEST_HANDLE_PARAM(type)) { (type *)ptr }) #define const_guest_handle_from_ptr(ptr, type) \ - ((XEN_GUEST_HANDLE(const_##type)) { (const type *)ptr }) + ((XEN_GUEST_HANDLE_PARAM(const_##type)) { (const type *)ptr }) /* * Copy an array of objects to guest context via a guest handle, diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h index 2ae6548..d5d8209 100644 --- a/xen/include/public/arch-arm.h +++ b/xen/include/public/arch-arm.h @@ -51,18 +51,36 @@ #define XEN_HYPERCALL_TAG 0XEA1 +#define uint64_aligned_t uint64_t __attribute__((aligned(8))) #ifndef __ASSEMBLY__ -#define ___DEFINE_XEN_GUEST_HANDLE(name, type) \ - typedef struct { type *p; } __guest_handle_ ## name +#define ___DEFINE_XEN_GUEST_HANDLE(name, type) \ + typedef union { type *p; unsigned long q; } \ + __guest_handle_ ## name; \ + typedef union { type *p; uint64_aligned_t q; } \ + __guest_handle_64_ ## name; +/* + * XEN_GUEST_HANDLE represents a guest pointer, when passed as a field + * in a struct in memory. On ARM is always 8 bytes sizes and 8 bytes + * aligned. + * XEN_GUEST_HANDLE_PARAM represent a guest pointer, when passed as an + * hypercall argument. It is 4 bytes on aarch and 8 bytes on aarch64. + */ #define __DEFINE_XEN_GUEST_HANDLE(name, type) \ ___DEFINE_XEN_GUEST_HANDLE(name, type); \ ___DEFINE_XEN_GUEST_HANDLE(const_##name, const type) #define DEFINE_XEN_GUEST_HANDLE(name) __DEFINE_XEN_GUEST_HANDLE(name, name) -#define __XEN_GUEST_HANDLE(name) __guest_handle_ ## name +#define __XEN_GUEST_HANDLE(name) __guest_handle_64_ ## name #define XEN_GUEST_HANDLE(name) __XEN_GUEST_HANDLE(name) -#define set_xen_guest_handle_raw(hnd, val) do { (hnd).p = val; } while (0) +/* this is going to be changes on 64 bit */ +#define XEN_GUEST_HANDLE_PARAM(name) __guest_handle_ ## name +#define set_xen_guest_handle_raw(hnd, val) \ + do { \ + typeof(&(hnd)) _sxghr_tmp = &(hnd); \ + _sxghr_tmp->q = 0; \ + _sxghr_tmp->p = val; \ + } while ( 0 ) #ifdef __XEN_TOOLS__ #define get_xen_guest_handle(val, hnd) do { val = (hnd).p; } while (0) #endif diff --git a/xen/include/public/arch-x86/xen.h b/xen/include/public/arch-x86/xen.h index 1c186d7..0e10260 100644 --- a/xen/include/public/arch-x86/xen.h +++ b/xen/include/public/arch-x86/xen.h @@ -38,12 +38,21 @@ typedef type * __guest_handle_ ## name #endif +/* + * XEN_GUEST_HANDLE represents a guest pointer, when passed as a field + * in a struct in memory. + * XEN_GUEST_HANDLE_PARAM represent a guest pointer, when passed as an + * hypercall argument. + * XEN_GUEST_HANDLE_PARAM and XEN_GUEST_HANDLE are the same on X86 but + * they might not be on other architectures. + */ #define __DEFINE_XEN_GUEST_HANDLE(name, type) \ ___DEFINE_XEN_GUEST_HANDLE(name, type); \ ___DEFINE_XEN_GUEST_HANDLE(const_##name, const type) #define DEFINE_XEN_GUEST_HANDLE(name) __DEFINE_XEN_GUEST_HANDLE(name, name) #define __XEN_GUEST_HANDLE(name) __guest_handle_ ## name #define XEN_GUEST_HANDLE(name) __XEN_GUEST_HANDLE(name) +#define XEN_GUEST_HANDLE_PARAM(name) XEN_GUEST_HANDLE(name) #define set_xen_guest_handle_raw(hnd, val) do { (hnd).p = val; } while (0) #ifdef __XEN_TOOLS__ #define get_xen_guest_handle(val, hnd) do { val = (hnd).p; } while (0) diff --git a/xen/include/xen/xencomm.h b/xen/include/xen/xencomm.h index 730da7c..3426b8a 100644 --- a/xen/include/xen/xencomm.h +++ b/xen/include/xen/xencomm.h @@ -66,11 +66,31 @@ static inline unsigned long xencomm_inline_addr(const void *handle) /* Cast a guest handle to the specified type of handle. */ #define guest_handle_cast(hnd, type) ({ \ type *_x = (hnd).p; \ - XEN_GUEST_HANDLE(type) _y; \ + XEN_GUEST_HANDLE_PARAM(type) _y; \ set_xen_guest_handle(_y, _x); \ _y; \ }) +/* Cast a XEN_GUEST_HANDLE to XEN_GUEST_HANDLE_PARAM */ +#define guest_handle_to_param(hnd, type) ({ \ + /* type checking: make sure that the pointers inside \ + * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of \ + * the same type, then return hnd */ \ + (void)((typeof(&(hnd).p)) 0 == \ + (typeof(&((XEN_GUEST_HANDLE_PARAM(type)) {}).p)) 0); \ + (hnd); \ +}) + +/* Cast a XEN_GUEST_HANDLE_PARAM to XEN_GUEST_HANDLE */ +#define guest_handle_from_param(hnd, type) ({ \ + /* type checking: make sure that the pointers inside \ + * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of \ + * the same type, then return hnd */ \ + (void)((typeof(&(hnd).p)) 0 == \ + (typeof(&((XEN_GUEST_HANDLE_PARAM(type)) {}).p)) 0); \ + (hnd); \ +}) + /* Since we run in real mode, we can safely access all addresses. That also * means our __routines are identical to our "normal" routines. */ #define guest_handle_okay(hnd, nr) 1 -- 1.7.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 10:52:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 10:52:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5WB-00033s-Dn; Fri, 05 Oct 2012 10:52:31 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5WA-0002vv-DB for xen-devel@lists.xen.org; Fri, 05 Oct 2012 10:52:30 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1349434340!8023514!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ1ODc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22212 invoked from network); 5 Oct 2012 10:52:22 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 10:52:22 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="40249334" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 10:52:20 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 06:52:19 -0400 Received: from [10.80.246.74] (helo=army.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK5Ib-0003Rm-JJ; Fri, 05 Oct 2012 11:38:29 +0100 From: Ian Campbell To: Date: Fri, 5 Oct 2012 10:38:24 +0000 Message-ID: <1349433507-21148-18-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.9.1 In-Reply-To: <1349433418.20946.46.camel@zakaz.uk.xensource.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: keir@xen.org, Stefano Stabellini , tim@xen.org, JBeulich@suse.com, stefano.stabelini@citrix.com Subject: [Xen-devel] [PATCH 18/21] xen: change the limit of nr_extents to UINT_MAX >> MEMOP_EXTENT_SHIFT X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Stefano Stabellini Currently do_memory_op has a different maximum limit for nr_extents on 32 bit and 64 bit. Change the limit to UINT_MAX >> MEMOP_EXTENT_SHIFT, so that it is the same in both cases. Signed-off-by: Stefano Stabellini Cc: keir@xen.org Cc: JBeulich@suse.com --- xen/common/memory.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/xen/common/memory.c b/xen/common/memory.c index 5bcb035..401d06c 100644 --- a/xen/common/memory.c +++ b/xen/common/memory.c @@ -540,7 +540,7 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE(void) arg) return start_extent; /* Is size too large for us to encode a continuation? */ - if ( reservation.nr_extents > (ULONG_MAX >> MEMOP_EXTENT_SHIFT) ) + if ( reservation.nr_extents > (UINT_MAX >> MEMOP_EXTENT_SHIFT) ) return start_extent; if ( unlikely(start_extent >= reservation.nr_extents) ) -- 1.7.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 10:52:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 10:52:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5WB-00033s-Dn; Fri, 05 Oct 2012 10:52:31 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5WA-0002vv-DB for xen-devel@lists.xen.org; Fri, 05 Oct 2012 10:52:30 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1349434340!8023514!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ1ODc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22212 invoked from network); 5 Oct 2012 10:52:22 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 10:52:22 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="40249334" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 10:52:20 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 06:52:19 -0400 Received: from [10.80.246.74] (helo=army.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK5Ib-0003Rm-JJ; Fri, 05 Oct 2012 11:38:29 +0100 From: Ian Campbell To: Date: Fri, 5 Oct 2012 10:38:24 +0000 Message-ID: <1349433507-21148-18-git-send-email-ian.campbell@citrix.com> X-Mailer: git-send-email 1.7.9.1 In-Reply-To: <1349433418.20946.46.camel@zakaz.uk.xensource.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: keir@xen.org, Stefano Stabellini , tim@xen.org, JBeulich@suse.com, stefano.stabelini@citrix.com Subject: [Xen-devel] [PATCH 18/21] xen: change the limit of nr_extents to UINT_MAX >> MEMOP_EXTENT_SHIFT X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org From: Stefano Stabellini Currently do_memory_op has a different maximum limit for nr_extents on 32 bit and 64 bit. Change the limit to UINT_MAX >> MEMOP_EXTENT_SHIFT, so that it is the same in both cases. Signed-off-by: Stefano Stabellini Cc: keir@xen.org Cc: JBeulich@suse.com --- xen/common/memory.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/xen/common/memory.c b/xen/common/memory.c index 5bcb035..401d06c 100644 --- a/xen/common/memory.c +++ b/xen/common/memory.c @@ -540,7 +540,7 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE(void) arg) return start_extent; /* Is size too large for us to encode a continuation? */ - if ( reservation.nr_extents > (ULONG_MAX >> MEMOP_EXTENT_SHIFT) ) + if ( reservation.nr_extents > (UINT_MAX >> MEMOP_EXTENT_SHIFT) ) return start_extent; if ( unlikely(start_extent >= reservation.nr_extents) ) -- 1.7.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 11:00:37 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 11:00:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5do-0004WR-DV; Fri, 05 Oct 2012 11:00:24 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5dn-0004WM-0P for xen-devel@lists.xen.org; Fri, 05 Oct 2012 11:00:23 +0000 Received: from [85.158.139.211:6680] by server-1.bemta-5.messagelabs.com id F6/1A-09825-5CDBE605; Fri, 05 Oct 2012 11:00:21 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-9.tower-206.messagelabs.com!1349434820!19686646!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15936 invoked from network); 5 Oct 2012 11:00:20 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-9.tower-206.messagelabs.com with SMTP; 5 Oct 2012 11:00:20 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 05 Oct 2012 12:00:20 +0100 Message-Id: <506ED9E2020000780009FE5A@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 05 Oct 2012 12:00:18 +0100 From: "Jan Beulich" To: "Ian Campbell" References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> <1349433507-21148-17-git-send-email-ian.campbell@citrix.com> In-Reply-To: <1349433507-21148-17-git-send-email-ian.campbell@citrix.com> Mime-Version: 1.0 Content-Disposition: inline Cc: keir@xen.org, tim@xen.org, Stefano Stabellini , xen-devel@lists.xen.org, stefano.stabelini@citrix.com Subject: Re: [Xen-devel] [PATCH 17/21] xen: xen_ulong_t substitution X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 05.10.12 at 12:38, Ian Campbell wrote: > --- a/tools/python/xen/lowlevel/xc/xc.c > +++ b/tools/python/xen/lowlevel/xc/xc.c > @@ -1439,7 +1439,7 @@ static PyObject *pyxc_xeninfo(XcObject *self) > if ( xc_version(self->xc_handle, XENVER_commandline, &xen_commandline) != 0 ) > return pyxc_error_to_exception(self->xc_handle); > > - snprintf(str, sizeof(str), "virt_start=0x%lx", p_parms.virt_start); > + snprintf(str, sizeof(str), "virt_start=0x%"PRI_xen_ulong, p_parms.virt_start); Does that build on x86? I ask because ... > > xen_pagesize = xc_version(self->xc_handle, XENVER_pagesize, NULL); > if (xen_pagesize < 0 ) > diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h > index e3d4ad9..2ae6548 100644 > --- a/xen/include/public/arch-arm.h > +++ b/xen/include/public/arch-arm.h > @@ -122,7 +122,8 @@ typedef uint64_t xen_pfn_t; > /* Only one. All other VCPUS must use VCPUOP_register_vcpu_info */ > #define XEN_LEGACY_MAX_VCPUS 1 > > -typedef uint32_t xen_ulong_t; > +typedef uint64_t xen_ulong_t; > +#define PRI_xen_ulong PRIx64 ... this doesn't seem to have an x86 counterpart. Jan > > struct vcpu_guest_context { > #define _VGCF_online 0 > diff --git a/xen/include/public/version.h b/xen/include/public/version.h > index 8742c2b..c7e6f8c 100644 > --- a/xen/include/public/version.h > +++ b/xen/include/public/version.h > @@ -28,6 +28,8 @@ > #ifndef __XEN_PUBLIC_VERSION_H__ > #define __XEN_PUBLIC_VERSION_H__ > > +#include "xen.h" > + > /* NB. All ops return zero on success, except XENVER_{version,pagesize} */ > > /* arg == NULL; returns major:minor (16:16). */ > @@ -58,7 +60,7 @@ typedef char xen_changeset_info_t[64]; > > #define XENVER_platform_parameters 5 > struct xen_platform_parameters { > - unsigned long virt_start; > + xen_ulong_t virt_start; > }; > typedef struct xen_platform_parameters xen_platform_parameters_t; > > -- > 1.7.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 11:00:37 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 11:00:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5do-0004WR-DV; Fri, 05 Oct 2012 11:00:24 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5dn-0004WM-0P for xen-devel@lists.xen.org; Fri, 05 Oct 2012 11:00:23 +0000 Received: from [85.158.139.211:6680] by server-1.bemta-5.messagelabs.com id F6/1A-09825-5CDBE605; Fri, 05 Oct 2012 11:00:21 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-9.tower-206.messagelabs.com!1349434820!19686646!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15936 invoked from network); 5 Oct 2012 11:00:20 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-9.tower-206.messagelabs.com with SMTP; 5 Oct 2012 11:00:20 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 05 Oct 2012 12:00:20 +0100 Message-Id: <506ED9E2020000780009FE5A@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 05 Oct 2012 12:00:18 +0100 From: "Jan Beulich" To: "Ian Campbell" References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> <1349433507-21148-17-git-send-email-ian.campbell@citrix.com> In-Reply-To: <1349433507-21148-17-git-send-email-ian.campbell@citrix.com> Mime-Version: 1.0 Content-Disposition: inline Cc: keir@xen.org, tim@xen.org, Stefano Stabellini , xen-devel@lists.xen.org, stefano.stabelini@citrix.com Subject: Re: [Xen-devel] [PATCH 17/21] xen: xen_ulong_t substitution X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 05.10.12 at 12:38, Ian Campbell wrote: > --- a/tools/python/xen/lowlevel/xc/xc.c > +++ b/tools/python/xen/lowlevel/xc/xc.c > @@ -1439,7 +1439,7 @@ static PyObject *pyxc_xeninfo(XcObject *self) > if ( xc_version(self->xc_handle, XENVER_commandline, &xen_commandline) != 0 ) > return pyxc_error_to_exception(self->xc_handle); > > - snprintf(str, sizeof(str), "virt_start=0x%lx", p_parms.virt_start); > + snprintf(str, sizeof(str), "virt_start=0x%"PRI_xen_ulong, p_parms.virt_start); Does that build on x86? I ask because ... > > xen_pagesize = xc_version(self->xc_handle, XENVER_pagesize, NULL); > if (xen_pagesize < 0 ) > diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h > index e3d4ad9..2ae6548 100644 > --- a/xen/include/public/arch-arm.h > +++ b/xen/include/public/arch-arm.h > @@ -122,7 +122,8 @@ typedef uint64_t xen_pfn_t; > /* Only one. All other VCPUS must use VCPUOP_register_vcpu_info */ > #define XEN_LEGACY_MAX_VCPUS 1 > > -typedef uint32_t xen_ulong_t; > +typedef uint64_t xen_ulong_t; > +#define PRI_xen_ulong PRIx64 ... this doesn't seem to have an x86 counterpart. Jan > > struct vcpu_guest_context { > #define _VGCF_online 0 > diff --git a/xen/include/public/version.h b/xen/include/public/version.h > index 8742c2b..c7e6f8c 100644 > --- a/xen/include/public/version.h > +++ b/xen/include/public/version.h > @@ -28,6 +28,8 @@ > #ifndef __XEN_PUBLIC_VERSION_H__ > #define __XEN_PUBLIC_VERSION_H__ > > +#include "xen.h" > + > /* NB. All ops return zero on success, except XENVER_{version,pagesize} */ > > /* arg == NULL; returns major:minor (16:16). */ > @@ -58,7 +60,7 @@ typedef char xen_changeset_info_t[64]; > > #define XENVER_platform_parameters 5 > struct xen_platform_parameters { > - unsigned long virt_start; > + xen_ulong_t virt_start; > }; > typedef struct xen_platform_parameters xen_platform_parameters_t; > > -- > 1.7.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 11:02:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 11:02:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5fs-0004ca-VF; Fri, 05 Oct 2012 11:02:32 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5fr-0004cS-6p for xen-devel@lists.xen.org; Fri, 05 Oct 2012 11:02:31 +0000 Received: from [85.158.139.211:23827] by server-16.bemta-5.messagelabs.com id 86/F4-21637-64EBE605; Fri, 05 Oct 2012 11:02:30 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-15.tower-206.messagelabs.com!1349434949!21244998!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21578 invoked from network); 5 Oct 2012 11:02:29 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-15.tower-206.messagelabs.com with SMTP; 5 Oct 2012 11:02:29 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 05 Oct 2012 12:02:29 +0100 Message-Id: <506EDA66020000780009FE69@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 05 Oct 2012 12:02:30 +0100 From: "Jan Beulich" To: "Ian Campbell" References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> <1349433507-21148-18-git-send-email-ian.campbell@citrix.com> In-Reply-To: <1349433507-21148-18-git-send-email-ian.campbell@citrix.com> Mime-Version: 1.0 Content-Disposition: inline Cc: keir@xen.org, tim@xen.org, Stefano Stabellini , xen-devel@lists.xen.org, stefano.stabelini@citrix.com Subject: Re: [Xen-devel] [PATCH 18/21] xen: change the limit of nr_extents to UINT_MAX >> MEMOP_EXTENT_SHIFT X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 05.10.12 at 12:38, Ian Campbell wrote: > From: Stefano Stabellini > > Currently do_memory_op has a different maximum limit for nr_extents on > 32 bit and 64 bit. > Change the limit to UINT_MAX >> MEMOP_EXTENT_SHIFT, so that it is the > same in both cases. As said before, this looks fine to me, but will need Keir's ack anyway for you to apply it (but feel free to stick my ack onto it anyway if you like). Plus it really is entirely independent of the rest of the series, so doesn't need to wait for any other eventual issues to be resolved. Jan > Signed-off-by: Stefano Stabellini > Cc: keir@xen.org > Cc: JBeulich@suse.com > --- > xen/common/memory.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/xen/common/memory.c b/xen/common/memory.c > index 5bcb035..401d06c 100644 > --- a/xen/common/memory.c > +++ b/xen/common/memory.c > @@ -540,7 +540,7 @@ long do_memory_op(unsigned long cmd, > XEN_GUEST_HANDLE(void) arg) > return start_extent; > > /* Is size too large for us to encode a continuation? */ > - if ( reservation.nr_extents > (ULONG_MAX >> MEMOP_EXTENT_SHIFT) ) > + if ( reservation.nr_extents > (UINT_MAX >> MEMOP_EXTENT_SHIFT) ) > return start_extent; > > if ( unlikely(start_extent >= reservation.nr_extents) ) > -- > 1.7.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 11:02:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 11:02:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5fs-0004ca-VF; Fri, 05 Oct 2012 11:02:32 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5fr-0004cS-6p for xen-devel@lists.xen.org; Fri, 05 Oct 2012 11:02:31 +0000 Received: from [85.158.139.211:23827] by server-16.bemta-5.messagelabs.com id 86/F4-21637-64EBE605; Fri, 05 Oct 2012 11:02:30 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-15.tower-206.messagelabs.com!1349434949!21244998!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21578 invoked from network); 5 Oct 2012 11:02:29 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-15.tower-206.messagelabs.com with SMTP; 5 Oct 2012 11:02:29 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 05 Oct 2012 12:02:29 +0100 Message-Id: <506EDA66020000780009FE69@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 05 Oct 2012 12:02:30 +0100 From: "Jan Beulich" To: "Ian Campbell" References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> <1349433507-21148-18-git-send-email-ian.campbell@citrix.com> In-Reply-To: <1349433507-21148-18-git-send-email-ian.campbell@citrix.com> Mime-Version: 1.0 Content-Disposition: inline Cc: keir@xen.org, tim@xen.org, Stefano Stabellini , xen-devel@lists.xen.org, stefano.stabelini@citrix.com Subject: Re: [Xen-devel] [PATCH 18/21] xen: change the limit of nr_extents to UINT_MAX >> MEMOP_EXTENT_SHIFT X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 05.10.12 at 12:38, Ian Campbell wrote: > From: Stefano Stabellini > > Currently do_memory_op has a different maximum limit for nr_extents on > 32 bit and 64 bit. > Change the limit to UINT_MAX >> MEMOP_EXTENT_SHIFT, so that it is the > same in both cases. As said before, this looks fine to me, but will need Keir's ack anyway for you to apply it (but feel free to stick my ack onto it anyway if you like). Plus it really is entirely independent of the rest of the series, so doesn't need to wait for any other eventual issues to be resolved. Jan > Signed-off-by: Stefano Stabellini > Cc: keir@xen.org > Cc: JBeulich@suse.com > --- > xen/common/memory.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/xen/common/memory.c b/xen/common/memory.c > index 5bcb035..401d06c 100644 > --- a/xen/common/memory.c > +++ b/xen/common/memory.c > @@ -540,7 +540,7 @@ long do_memory_op(unsigned long cmd, > XEN_GUEST_HANDLE(void) arg) > return start_extent; > > /* Is size too large for us to encode a continuation? */ > - if ( reservation.nr_extents > (ULONG_MAX >> MEMOP_EXTENT_SHIFT) ) > + if ( reservation.nr_extents > (UINT_MAX >> MEMOP_EXTENT_SHIFT) ) > return start_extent; > > if ( unlikely(start_extent >= reservation.nr_extents) ) > -- > 1.7.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 11:03:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 11:03:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5h3-0004it-DO; Fri, 05 Oct 2012 11:03:45 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5h2-0004il-N9 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 11:03:44 +0000 Received: from [85.158.143.35:62454] by server-3.bemta-4.messagelabs.com id B6/57-10986-09EBE605; Fri, 05 Oct 2012 11:03:44 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-2.tower-21.messagelabs.com!1349435022!10139217!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6801 invoked from network); 5 Oct 2012 11:03:42 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 11:03:42 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14960331" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 11:03:42 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 12:03:42 +0100 Message-ID: <1349435021.20946.51.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Jan Beulich Date: Fri, 5 Oct 2012 12:03:41 +0100 In-Reply-To: <506ED9E2020000780009FE5A@nat28.tlf.novell.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> <1349433507-21148-17-git-send-email-ian.campbell@citrix.com> <506ED9E2020000780009FE5A@nat28.tlf.novell.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Keir \(Xen.org\)" , "Tim \(Xen.org\)" , Stefano Stabellini , "xen-devel@lists.xen.org" , "stefano.stabelini@citrix.com" Subject: Re: [Xen-devel] [PATCH 17/21] xen: xen_ulong_t substitution X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-10-05 at 12:00 +0100, Jan Beulich wrote: > >>> On 05.10.12 at 12:38, Ian Campbell wrote: > > --- a/tools/python/xen/lowlevel/xc/xc.c > > +++ b/tools/python/xen/lowlevel/xc/xc.c > > @@ -1439,7 +1439,7 @@ static PyObject *pyxc_xeninfo(XcObject *self) > > if ( xc_version(self->xc_handle, XENVER_commandline, &xen_commandline) != 0 ) > > return pyxc_error_to_exception(self->xc_handle); > > > > - snprintf(str, sizeof(str), "virt_start=0x%lx", p_parms.virt_start); > > + snprintf(str, sizeof(str), "virt_start=0x%"PRI_xen_ulong, p_parms.virt_start); > > Does that build on x86? I ask because ... I appear to have forgotten to build test the tools side on x86, which was remiss of me. > > > > xen_pagesize = xc_version(self->xc_handle, XENVER_pagesize, NULL); > > if (xen_pagesize < 0 ) > > diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h > > index e3d4ad9..2ae6548 100644 > > --- a/xen/include/public/arch-arm.h > > +++ b/xen/include/public/arch-arm.h > > @@ -122,7 +122,8 @@ typedef uint64_t xen_pfn_t; > > /* Only one. All other VCPUS must use VCPUOP_register_vcpu_info */ > > #define XEN_LEGACY_MAX_VCPUS 1 > > > > -typedef uint32_t xen_ulong_t; > > +typedef uint64_t xen_ulong_t; > > +#define PRI_xen_ulong PRIx64 > > ... this doesn't seem to have an x86 counterpart. Indeed, I haven't tried but I'm sure it must be broken on x86. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 11:03:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 11:03:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5h3-0004it-DO; Fri, 05 Oct 2012 11:03:45 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5h2-0004il-N9 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 11:03:44 +0000 Received: from [85.158.143.35:62454] by server-3.bemta-4.messagelabs.com id B6/57-10986-09EBE605; Fri, 05 Oct 2012 11:03:44 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-2.tower-21.messagelabs.com!1349435022!10139217!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6801 invoked from network); 5 Oct 2012 11:03:42 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 11:03:42 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14960331" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 11:03:42 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 12:03:42 +0100 Message-ID: <1349435021.20946.51.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Jan Beulich Date: Fri, 5 Oct 2012 12:03:41 +0100 In-Reply-To: <506ED9E2020000780009FE5A@nat28.tlf.novell.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> <1349433507-21148-17-git-send-email-ian.campbell@citrix.com> <506ED9E2020000780009FE5A@nat28.tlf.novell.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Keir \(Xen.org\)" , "Tim \(Xen.org\)" , Stefano Stabellini , "xen-devel@lists.xen.org" , "stefano.stabelini@citrix.com" Subject: Re: [Xen-devel] [PATCH 17/21] xen: xen_ulong_t substitution X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-10-05 at 12:00 +0100, Jan Beulich wrote: > >>> On 05.10.12 at 12:38, Ian Campbell wrote: > > --- a/tools/python/xen/lowlevel/xc/xc.c > > +++ b/tools/python/xen/lowlevel/xc/xc.c > > @@ -1439,7 +1439,7 @@ static PyObject *pyxc_xeninfo(XcObject *self) > > if ( xc_version(self->xc_handle, XENVER_commandline, &xen_commandline) != 0 ) > > return pyxc_error_to_exception(self->xc_handle); > > > > - snprintf(str, sizeof(str), "virt_start=0x%lx", p_parms.virt_start); > > + snprintf(str, sizeof(str), "virt_start=0x%"PRI_xen_ulong, p_parms.virt_start); > > Does that build on x86? I ask because ... I appear to have forgotten to build test the tools side on x86, which was remiss of me. > > > > xen_pagesize = xc_version(self->xc_handle, XENVER_pagesize, NULL); > > if (xen_pagesize < 0 ) > > diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h > > index e3d4ad9..2ae6548 100644 > > --- a/xen/include/public/arch-arm.h > > +++ b/xen/include/public/arch-arm.h > > @@ -122,7 +122,8 @@ typedef uint64_t xen_pfn_t; > > /* Only one. All other VCPUS must use VCPUOP_register_vcpu_info */ > > #define XEN_LEGACY_MAX_VCPUS 1 > > > > -typedef uint32_t xen_ulong_t; > > +typedef uint64_t xen_ulong_t; > > +#define PRI_xen_ulong PRIx64 > > ... this doesn't seem to have an x86 counterpart. Indeed, I haven't tried but I'm sure it must be broken on x86. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 11:05:48 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 11:05:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5iv-0004t6-Tx; Fri, 05 Oct 2012 11:05:41 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5iu-0004sy-FD for xen-devel@lists.xen.org; Fri, 05 Oct 2012 11:05:40 +0000 Received: from [85.158.137.99:39567] by server-14.bemta-3.messagelabs.com id F1/C2-19528-30FBE605; Fri, 05 Oct 2012 11:05:39 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-11.tower-217.messagelabs.com!1349435139!19191935!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32179 invoked from network); 5 Oct 2012 11:05:39 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 11:05:39 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14960377" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 11:05:38 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 12:05:38 +0100 Message-ID: <1349435137.20946.52.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Jan Beulich Date: Fri, 5 Oct 2012 12:05:37 +0100 In-Reply-To: <506EDA66020000780009FE69@nat28.tlf.novell.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> <1349433507-21148-18-git-send-email-ian.campbell@citrix.com> <506EDA66020000780009FE69@nat28.tlf.novell.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Keir \(Xen.org\)" , "Tim \(Xen.org\)" , Stefano Stabellini , "xen-devel@lists.xen.org" , "stefano.stabelini@citrix.com" Subject: Re: [Xen-devel] [PATCH 18/21] xen: change the limit of nr_extents to UINT_MAX >> MEMOP_EXTENT_SHIFT X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-10-05 at 12:02 +0100, Jan Beulich wrote: > >>> On 05.10.12 at 12:38, Ian Campbell wrote: > > From: Stefano Stabellini > > > > Currently do_memory_op has a different maximum limit for nr_extents on > > 32 bit and 64 bit. > > Change the limit to UINT_MAX >> MEMOP_EXTENT_SHIFT, so that it is the > > same in both cases. > > As said before, this looks fine to me, sorry, I seem to have missed your previous reply. > but will need Keir's ack > anyway for you to apply it (but feel free to stick my ack onto > it anyway if you like). Plus it really is entirely independent of > the rest of the series, so doesn't need to wait for any other > eventual issues to be resolved. OK, thanks. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 11:05:48 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 11:05:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5iv-0004t6-Tx; Fri, 05 Oct 2012 11:05:41 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5iu-0004sy-FD for xen-devel@lists.xen.org; Fri, 05 Oct 2012 11:05:40 +0000 Received: from [85.158.137.99:39567] by server-14.bemta-3.messagelabs.com id F1/C2-19528-30FBE605; Fri, 05 Oct 2012 11:05:39 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-11.tower-217.messagelabs.com!1349435139!19191935!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32179 invoked from network); 5 Oct 2012 11:05:39 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 11:05:39 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14960377" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 11:05:38 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 12:05:38 +0100 Message-ID: <1349435137.20946.52.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Jan Beulich Date: Fri, 5 Oct 2012 12:05:37 +0100 In-Reply-To: <506EDA66020000780009FE69@nat28.tlf.novell.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> <1349433507-21148-18-git-send-email-ian.campbell@citrix.com> <506EDA66020000780009FE69@nat28.tlf.novell.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Keir \(Xen.org\)" , "Tim \(Xen.org\)" , Stefano Stabellini , "xen-devel@lists.xen.org" , "stefano.stabelini@citrix.com" Subject: Re: [Xen-devel] [PATCH 18/21] xen: change the limit of nr_extents to UINT_MAX >> MEMOP_EXTENT_SHIFT X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-10-05 at 12:02 +0100, Jan Beulich wrote: > >>> On 05.10.12 at 12:38, Ian Campbell wrote: > > From: Stefano Stabellini > > > > Currently do_memory_op has a different maximum limit for nr_extents on > > 32 bit and 64 bit. > > Change the limit to UINT_MAX >> MEMOP_EXTENT_SHIFT, so that it is the > > same in both cases. > > As said before, this looks fine to me, sorry, I seem to have missed your previous reply. > but will need Keir's ack > anyway for you to apply it (but feel free to stick my ack onto > it anyway if you like). Plus it really is entirely independent of > the rest of the series, so doesn't need to wait for any other > eventual issues to be resolved. OK, thanks. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 11:06:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 11:06:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5jD-0004w0-RM; Fri, 05 Oct 2012 11:05:59 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5jC-0004vl-Ra for xen-devel@lists.xen.org; Fri, 05 Oct 2012 11:05:58 +0000 Received: from [85.158.139.211:40078] by server-10.bemta-5.messagelabs.com id F5/76-16911-51FBE605; Fri, 05 Oct 2012 11:05:57 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-7.tower-206.messagelabs.com!1349435157!20743878!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3442 invoked from network); 5 Oct 2012 11:05:57 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-7.tower-206.messagelabs.com with SMTP; 5 Oct 2012 11:05:57 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 05 Oct 2012 12:05:56 +0100 Message-Id: <506EDB33020000780009FE6C@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 05 Oct 2012 12:05:55 +0100 From: "Jan Beulich" To: "Ian Campbell" References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> <1349433507-21148-19-git-send-email-ian.campbell@citrix.com> In-Reply-To: <1349433507-21148-19-git-send-email-ian.campbell@citrix.com> Mime-Version: 1.0 Content-Disposition: inline Cc: keir@xen.org, tim@xen.org, Stefano Stabellini , xen-devel@lists.xen.org, stefano.stabelini@citrix.com Subject: Re: [Xen-devel] [PATCH 19/21] xen: introduce XEN_GUEST_HANDLE_PARAM X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 05.10.12 at 12:38, Ian Campbell wrote: > From: Stefano Stabellini > > XEN_GUEST_HANDLE_PARAM is going to be used to distinguish guest pointers > stored in memory from guest pointers as hypercall parameters. > > guest_handle_* macros default to XEN_GUEST_HANDLE_PARAM as return type. > Two new guest_handle_to_param and guest_handle_from_param macros are > introduced to do conversions. > > Changes in v2: > > - add 2 missing #define _XEN_GUEST_HANDLE_PARAM for the compilation of > the compat code. > > Changes in v3: > > - move the guest_handle_cast change into this patch; > - add a clear comment on top of guest_handle_cast; > - also s/XEN_GUEST_HANDLE/XEN_GUEST_HANDLE_PARAM in > guest_handle_from_ptr and const_guest_handle_from_ptr; > - introduce guest_handle_from_param and guest_handle_to_param. I may have asked this before, but don't recall the answer: Is there really a use case for conversions in both directions? I would think that only the "to" version is really useful... Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 11:06:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 11:06:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5jD-0004w0-RM; Fri, 05 Oct 2012 11:05:59 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5jC-0004vl-Ra for xen-devel@lists.xen.org; Fri, 05 Oct 2012 11:05:58 +0000 Received: from [85.158.139.211:40078] by server-10.bemta-5.messagelabs.com id F5/76-16911-51FBE605; Fri, 05 Oct 2012 11:05:57 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-7.tower-206.messagelabs.com!1349435157!20743878!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3442 invoked from network); 5 Oct 2012 11:05:57 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-7.tower-206.messagelabs.com with SMTP; 5 Oct 2012 11:05:57 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 05 Oct 2012 12:05:56 +0100 Message-Id: <506EDB33020000780009FE6C@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 05 Oct 2012 12:05:55 +0100 From: "Jan Beulich" To: "Ian Campbell" References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> <1349433507-21148-19-git-send-email-ian.campbell@citrix.com> In-Reply-To: <1349433507-21148-19-git-send-email-ian.campbell@citrix.com> Mime-Version: 1.0 Content-Disposition: inline Cc: keir@xen.org, tim@xen.org, Stefano Stabellini , xen-devel@lists.xen.org, stefano.stabelini@citrix.com Subject: Re: [Xen-devel] [PATCH 19/21] xen: introduce XEN_GUEST_HANDLE_PARAM X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 05.10.12 at 12:38, Ian Campbell wrote: > From: Stefano Stabellini > > XEN_GUEST_HANDLE_PARAM is going to be used to distinguish guest pointers > stored in memory from guest pointers as hypercall parameters. > > guest_handle_* macros default to XEN_GUEST_HANDLE_PARAM as return type. > Two new guest_handle_to_param and guest_handle_from_param macros are > introduced to do conversions. > > Changes in v2: > > - add 2 missing #define _XEN_GUEST_HANDLE_PARAM for the compilation of > the compat code. > > Changes in v3: > > - move the guest_handle_cast change into this patch; > - add a clear comment on top of guest_handle_cast; > - also s/XEN_GUEST_HANDLE/XEN_GUEST_HANDLE_PARAM in > guest_handle_from_ptr and const_guest_handle_from_ptr; > - introduce guest_handle_from_param and guest_handle_to_param. I may have asked this before, but don't recall the answer: Is there really a use case for conversions in both directions? I would think that only the "to" version is really useful... Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 11:06:37 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 11:06:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5ji-00052l-8d; Fri, 05 Oct 2012 11:06:30 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5jh-00052K-6m for xen-devel@lists.xen.org; Fri, 05 Oct 2012 11:06:29 +0000 Received: from [85.158.139.211:26217] by server-13.bemta-5.messagelabs.com id 21/A6-06496-43FBE605; Fri, 05 Oct 2012 11:06:28 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-6.tower-206.messagelabs.com!1349435187!21201075!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19666 invoked from network); 5 Oct 2012 11:06:27 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-6.tower-206.messagelabs.com with SMTP; 5 Oct 2012 11:06:27 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 05 Oct 2012 12:06:27 +0100 Message-Id: <506EDB53020000780009FE90@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 05 Oct 2012 12:06:27 +0100 From: "Jan Beulich" To: "Ian Campbell" References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> <1349433507-21148-20-git-send-email-ian.campbell@citrix.com> In-Reply-To: <1349433507-21148-20-git-send-email-ian.campbell@citrix.com> Mime-Version: 1.0 Content-Disposition: inline Cc: keir@xen.org, tim@xen.org, Stefano Stabellini , xen-devel@lists.xen.org, stefano.stabelini@citrix.com Subject: Re: [Xen-devel] [PATCH 20/21] xen: replace XEN_GUEST_HANDLE with XEN_GUEST_HANDLE_PARAM when appropriate X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 05.10.12 at 12:38, Ian Campbell wrote: > From: Stefano Stabellini > > Note: these changes don't make any difference on x86 and ia64. ia64? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 11:06:37 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 11:06:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5ji-00052l-8d; Fri, 05 Oct 2012 11:06:30 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5jh-00052K-6m for xen-devel@lists.xen.org; Fri, 05 Oct 2012 11:06:29 +0000 Received: from [85.158.139.211:26217] by server-13.bemta-5.messagelabs.com id 21/A6-06496-43FBE605; Fri, 05 Oct 2012 11:06:28 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-6.tower-206.messagelabs.com!1349435187!21201075!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19666 invoked from network); 5 Oct 2012 11:06:27 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-6.tower-206.messagelabs.com with SMTP; 5 Oct 2012 11:06:27 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 05 Oct 2012 12:06:27 +0100 Message-Id: <506EDB53020000780009FE90@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 05 Oct 2012 12:06:27 +0100 From: "Jan Beulich" To: "Ian Campbell" References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> <1349433507-21148-20-git-send-email-ian.campbell@citrix.com> In-Reply-To: <1349433507-21148-20-git-send-email-ian.campbell@citrix.com> Mime-Version: 1.0 Content-Disposition: inline Cc: keir@xen.org, tim@xen.org, Stefano Stabellini , xen-devel@lists.xen.org, stefano.stabelini@citrix.com Subject: Re: [Xen-devel] [PATCH 20/21] xen: replace XEN_GUEST_HANDLE with XEN_GUEST_HANDLE_PARAM when appropriate X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 05.10.12 at 12:38, Ian Campbell wrote: > From: Stefano Stabellini > > Note: these changes don't make any difference on x86 and ia64. ia64? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 11:09:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 11:09:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5ml-0005U2-Hn; Fri, 05 Oct 2012 11:09:39 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5mk-0005Ts-Re for xen-devel@lists.xen.org; Fri, 05 Oct 2012 11:09:38 +0000 Received: from [85.158.139.211:3397] by server-7.bemta-5.messagelabs.com id 6B/4E-00431-2FFBE605; Fri, 05 Oct 2012 11:09:38 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-7.tower-206.messagelabs.com!1349435377!20744377!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20706 invoked from network); 5 Oct 2012 11:09:37 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-7.tower-206.messagelabs.com with SMTP; 5 Oct 2012 11:09:37 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 05 Oct 2012 12:09:37 +0100 Message-Id: <506EDC11020000780009FE93@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 05 Oct 2012 12:09:37 +0100 From: "Jan Beulich" To: "Ian Campbell" References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> <1349433507-21148-21-git-send-email-ian.campbell@citrix.com> In-Reply-To: <1349433507-21148-21-git-send-email-ian.campbell@citrix.com> Mime-Version: 1.0 Content-Disposition: inline Cc: keir@xen.org, tim@xen.org, Stefano Stabellini , xen-devel@lists.xen.org, stefano.stabelini@citrix.com Subject: Re: [Xen-devel] [PATCH 21/21] xen: more substitutions X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 05.10.12 at 12:38, Ian Campbell wrote: > @@ -4195,6 +4197,7 @@ static int handle_iomem_range(unsigned long s, unsigned long e, void *p) > if ( s > ctxt->s ) > { > e820entry_t ent; > + XEN_GUEST_HANDLE_PARAM(e820entry_t) buffer_t; I'm not really in favor fo the _t suffix chosen here and below, as that's generally used for typedef-s. Could this be replaced with e.g. _p, _h, or _hp? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 11:09:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 11:09:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5ml-0005U2-Hn; Fri, 05 Oct 2012 11:09:39 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5mk-0005Ts-Re for xen-devel@lists.xen.org; Fri, 05 Oct 2012 11:09:38 +0000 Received: from [85.158.139.211:3397] by server-7.bemta-5.messagelabs.com id 6B/4E-00431-2FFBE605; Fri, 05 Oct 2012 11:09:38 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-7.tower-206.messagelabs.com!1349435377!20744377!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20706 invoked from network); 5 Oct 2012 11:09:37 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-7.tower-206.messagelabs.com with SMTP; 5 Oct 2012 11:09:37 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 05 Oct 2012 12:09:37 +0100 Message-Id: <506EDC11020000780009FE93@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 05 Oct 2012 12:09:37 +0100 From: "Jan Beulich" To: "Ian Campbell" References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> <1349433507-21148-21-git-send-email-ian.campbell@citrix.com> In-Reply-To: <1349433507-21148-21-git-send-email-ian.campbell@citrix.com> Mime-Version: 1.0 Content-Disposition: inline Cc: keir@xen.org, tim@xen.org, Stefano Stabellini , xen-devel@lists.xen.org, stefano.stabelini@citrix.com Subject: Re: [Xen-devel] [PATCH 21/21] xen: more substitutions X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 05.10.12 at 12:38, Ian Campbell wrote: > @@ -4195,6 +4197,7 @@ static int handle_iomem_range(unsigned long s, unsigned long e, void *p) > if ( s > ctxt->s ) > { > e820entry_t ent; > + XEN_GUEST_HANDLE_PARAM(e820entry_t) buffer_t; I'm not really in favor fo the _t suffix chosen here and below, as that's generally used for typedef-s. Could this be replaced with e.g. _p, _h, or _hp? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 11:09:56 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 11:09:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5mv-0005W7-UY; Fri, 05 Oct 2012 11:09:49 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5mu-0005VS-9O for xen-devel@lists.xen.org; Fri, 05 Oct 2012 11:09:48 +0000 Received: from [85.158.139.211:3869] by server-8.bemta-5.messagelabs.com id AC/CB-20246-BFFBE605; Fri, 05 Oct 2012 11:09:47 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-13.tower-206.messagelabs.com!1349435386!17222515!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6264 invoked from network); 5 Oct 2012 11:09:47 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 11:09:47 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14960505" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 11:09:46 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 12:09:46 +0100 Message-ID: <1349435385.20946.53.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Jan Beulich Date: Fri, 5 Oct 2012 12:09:45 +0100 In-Reply-To: <506EDB33020000780009FE6C@nat28.tlf.novell.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> <1349433507-21148-19-git-send-email-ian.campbell@citrix.com> <506EDB33020000780009FE6C@nat28.tlf.novell.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Keir \(Xen.org\)" , "Tim \(Xen.org\)" , Stefano Stabellini , "xen-devel@lists.xen.org" , "stefano.stabelini@citrix.com" Subject: Re: [Xen-devel] [PATCH 19/21] xen: introduce XEN_GUEST_HANDLE_PARAM X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-10-05 at 12:05 +0100, Jan Beulich wrote: > >>> On 05.10.12 at 12:38, Ian Campbell wrote: > > From: Stefano Stabellini > > > > XEN_GUEST_HANDLE_PARAM is going to be used to distinguish guest pointers > > stored in memory from guest pointers as hypercall parameters. > > > > guest_handle_* macros default to XEN_GUEST_HANDLE_PARAM as return type. > > Two new guest_handle_to_param and guest_handle_from_param macros are > > introduced to do conversions. > > > > Changes in v2: > > > > - add 2 missing #define _XEN_GUEST_HANDLE_PARAM for the compilation of > > the compat code. > > > > Changes in v3: > > > > - move the guest_handle_cast change into this patch; > > - add a clear comment on top of guest_handle_cast; > > - also s/XEN_GUEST_HANDLE/XEN_GUEST_HANDLE_PARAM in > > guest_handle_from_ptr and const_guest_handle_from_ptr; > > - introduce guest_handle_from_param and guest_handle_to_param. > > I may have asked this before, but don't recall the answer: Is there > really a use case for conversions in both directions? I would think > that only the "to" version is really useful... I can see uses of both in the patched tree. e.g. the from case is used in handle_iomem_range on x86. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 11:09:56 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 11:09:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5mv-0005W7-UY; Fri, 05 Oct 2012 11:09:49 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5mu-0005VS-9O for xen-devel@lists.xen.org; Fri, 05 Oct 2012 11:09:48 +0000 Received: from [85.158.139.211:3869] by server-8.bemta-5.messagelabs.com id AC/CB-20246-BFFBE605; Fri, 05 Oct 2012 11:09:47 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-13.tower-206.messagelabs.com!1349435386!17222515!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6264 invoked from network); 5 Oct 2012 11:09:47 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 11:09:47 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14960505" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 11:09:46 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 12:09:46 +0100 Message-ID: <1349435385.20946.53.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Jan Beulich Date: Fri, 5 Oct 2012 12:09:45 +0100 In-Reply-To: <506EDB33020000780009FE6C@nat28.tlf.novell.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> <1349433507-21148-19-git-send-email-ian.campbell@citrix.com> <506EDB33020000780009FE6C@nat28.tlf.novell.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Keir \(Xen.org\)" , "Tim \(Xen.org\)" , Stefano Stabellini , "xen-devel@lists.xen.org" , "stefano.stabelini@citrix.com" Subject: Re: [Xen-devel] [PATCH 19/21] xen: introduce XEN_GUEST_HANDLE_PARAM X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-10-05 at 12:05 +0100, Jan Beulich wrote: > >>> On 05.10.12 at 12:38, Ian Campbell wrote: > > From: Stefano Stabellini > > > > XEN_GUEST_HANDLE_PARAM is going to be used to distinguish guest pointers > > stored in memory from guest pointers as hypercall parameters. > > > > guest_handle_* macros default to XEN_GUEST_HANDLE_PARAM as return type. > > Two new guest_handle_to_param and guest_handle_from_param macros are > > introduced to do conversions. > > > > Changes in v2: > > > > - add 2 missing #define _XEN_GUEST_HANDLE_PARAM for the compilation of > > the compat code. > > > > Changes in v3: > > > > - move the guest_handle_cast change into this patch; > > - add a clear comment on top of guest_handle_cast; > > - also s/XEN_GUEST_HANDLE/XEN_GUEST_HANDLE_PARAM in > > guest_handle_from_ptr and const_guest_handle_from_ptr; > > - introduce guest_handle_from_param and guest_handle_to_param. > > I may have asked this before, but don't recall the answer: Is there > really a use case for conversions in both directions? I would think > that only the "to" version is really useful... I can see uses of both in the patched tree. e.g. the from case is used in handle_iomem_range on x86. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 11:15:55 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 11:15:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5sg-0005yR-P2; Fri, 05 Oct 2012 11:15:46 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5sf-0005yJ-7r for xen-devel@lists.xen.org; Fri, 05 Oct 2012 11:15:45 +0000 Received: from [85.158.139.83:41565] by server-12.bemta-5.messagelabs.com id C8/CC-19095-061CE605; Fri, 05 Oct 2012 11:15:44 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1349435743!27948849!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12422 invoked from network); 5 Oct 2012 11:15:44 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 11:15:44 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14960601" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 11:14:59 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 12:14:59 +0100 Message-ID: <1349435697.20946.57.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Jan Beulich Date: Fri, 5 Oct 2012 12:14:57 +0100 In-Reply-To: <506EDC11020000780009FE93@nat28.tlf.novell.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> <1349433507-21148-21-git-send-email-ian.campbell@citrix.com> <506EDC11020000780009FE93@nat28.tlf.novell.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Tim \(Xen.org\)" , "xen-devel@lists.xen.org" , "Keir \(Xen.org\)" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH 21/21] xen: more substitutions X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-10-05 at 12:09 +0100, Jan Beulich wrote: > >>> On 05.10.12 at 12:38, Ian Campbell wrote: > > @@ -4195,6 +4197,7 @@ static int handle_iomem_range(unsigned long s, unsigned long e, void *p) > > if ( s > ctxt->s ) > > { > > e820entry_t ent; > > + XEN_GUEST_HANDLE_PARAM(e820entry_t) buffer_t; > > I'm not really in favor fo the _t suffix chosen here and below, as > that's generally used for typedef-s. Could this be replaced with > e.g. _p, _h, or _hp? The use is buffer_t = guest_handle_cast(ctxt->map.buffer, e820entry_t); buffer = guest_handle_from_param(buffer_t, e820entry_t); which seems a bit strange to me -- we launder through buffer_t solely to use guest_handle_from_param. Is there no macro which does that in one step? That would avoid the whole problem of the suffix choice. Also buffer is then passed to __copy_to_guest_offset, and I'm not sure why that can't be passed ctxt->map.buffer directly rather than laundering it through those two macros... Stefano? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 11:15:55 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 11:15:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5sg-0005yR-P2; Fri, 05 Oct 2012 11:15:46 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5sf-0005yJ-7r for xen-devel@lists.xen.org; Fri, 05 Oct 2012 11:15:45 +0000 Received: from [85.158.139.83:41565] by server-12.bemta-5.messagelabs.com id C8/CC-19095-061CE605; Fri, 05 Oct 2012 11:15:44 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1349435743!27948849!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12422 invoked from network); 5 Oct 2012 11:15:44 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 11:15:44 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14960601" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 11:14:59 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 12:14:59 +0100 Message-ID: <1349435697.20946.57.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Jan Beulich Date: Fri, 5 Oct 2012 12:14:57 +0100 In-Reply-To: <506EDC11020000780009FE93@nat28.tlf.novell.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> <1349433507-21148-21-git-send-email-ian.campbell@citrix.com> <506EDC11020000780009FE93@nat28.tlf.novell.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Tim \(Xen.org\)" , "xen-devel@lists.xen.org" , "Keir \(Xen.org\)" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH 21/21] xen: more substitutions X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-10-05 at 12:09 +0100, Jan Beulich wrote: > >>> On 05.10.12 at 12:38, Ian Campbell wrote: > > @@ -4195,6 +4197,7 @@ static int handle_iomem_range(unsigned long s, unsigned long e, void *p) > > if ( s > ctxt->s ) > > { > > e820entry_t ent; > > + XEN_GUEST_HANDLE_PARAM(e820entry_t) buffer_t; > > I'm not really in favor fo the _t suffix chosen here and below, as > that's generally used for typedef-s. Could this be replaced with > e.g. _p, _h, or _hp? The use is buffer_t = guest_handle_cast(ctxt->map.buffer, e820entry_t); buffer = guest_handle_from_param(buffer_t, e820entry_t); which seems a bit strange to me -- we launder through buffer_t solely to use guest_handle_from_param. Is there no macro which does that in one step? That would avoid the whole problem of the suffix choice. Also buffer is then passed to __copy_to_guest_offset, and I'm not sure why that can't be passed ctxt->map.buffer directly rather than laundering it through those two macros... Stefano? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 11:20:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 11:20:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5x8-0006Ch-Ej; Fri, 05 Oct 2012 11:20:22 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5x7-0006CY-BA for xen-devel@lists.xen.org; Fri, 05 Oct 2012 11:20:21 +0000 Received: from [85.158.139.83:17094] by server-4.bemta-5.messagelabs.com id 36/0E-20767-472CE605; Fri, 05 Oct 2012 11:20:20 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1349436019!27949726!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30467 invoked from network); 5 Oct 2012 11:20:20 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-5.tower-182.messagelabs.com with SMTP; 5 Oct 2012 11:20:20 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 05 Oct 2012 12:20:20 +0100 Message-Id: <506EDE92020000780009FECB@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 05 Oct 2012 12:20:18 +0100 From: "Jan Beulich" To: "Ian Campbell" References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> <1349433507-21148-19-git-send-email-ian.campbell@citrix.com> <506EDB33020000780009FE6C@nat28.tlf.novell.com> <1349435385.20946.53.camel@zakaz.uk.xensource.com> In-Reply-To: <1349435385.20946.53.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Disposition: inline Cc: "Keir \(Xen.org\)" , "Tim \(Xen.org\)" , StefanoStabellini , "xen-devel@lists.xen.org" , "stefano.stabelini@citrix.com" Subject: Re: [Xen-devel] [PATCH 19/21] xen: introduce XEN_GUEST_HANDLE_PARAM X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 05.10.12 at 13:09, Ian Campbell wrote: > On Fri, 2012-10-05 at 12:05 +0100, Jan Beulich wrote: >> >>> On 05.10.12 at 12:38, Ian Campbell wrote: >> > From: Stefano Stabellini >> > >> > XEN_GUEST_HANDLE_PARAM is going to be used to distinguish guest pointers >> > stored in memory from guest pointers as hypercall parameters. >> > >> > guest_handle_* macros default to XEN_GUEST_HANDLE_PARAM as return type. >> > Two new guest_handle_to_param and guest_handle_from_param macros are >> > introduced to do conversions. >> > >> > Changes in v2: >> > >> > - add 2 missing #define _XEN_GUEST_HANDLE_PARAM for the compilation of >> > the compat code. >> > >> > Changes in v3: >> > >> > - move the guest_handle_cast change into this patch; >> > - add a clear comment on top of guest_handle_cast; >> > - also s/XEN_GUEST_HANDLE/XEN_GUEST_HANDLE_PARAM in >> > guest_handle_from_ptr and const_guest_handle_from_ptr; >> > - introduce guest_handle_from_param and guest_handle_to_param. >> >> I may have asked this before, but don't recall the answer: Is there >> really a use case for conversions in both directions? I would think >> that only the "to" version is really useful... > > I can see uses of both in the patched tree. e.g. the from case is used > in handle_iomem_range on x86. Hmm, indeed. But I don't see why, so let me comment there instead. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 11:20:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 11:20:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5x8-0006Ch-Ej; Fri, 05 Oct 2012 11:20:22 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK5x7-0006CY-BA for xen-devel@lists.xen.org; Fri, 05 Oct 2012 11:20:21 +0000 Received: from [85.158.139.83:17094] by server-4.bemta-5.messagelabs.com id 36/0E-20767-472CE605; Fri, 05 Oct 2012 11:20:20 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1349436019!27949726!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30467 invoked from network); 5 Oct 2012 11:20:20 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-5.tower-182.messagelabs.com with SMTP; 5 Oct 2012 11:20:20 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 05 Oct 2012 12:20:20 +0100 Message-Id: <506EDE92020000780009FECB@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 05 Oct 2012 12:20:18 +0100 From: "Jan Beulich" To: "Ian Campbell" References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> <1349433507-21148-19-git-send-email-ian.campbell@citrix.com> <506EDB33020000780009FE6C@nat28.tlf.novell.com> <1349435385.20946.53.camel@zakaz.uk.xensource.com> In-Reply-To: <1349435385.20946.53.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Disposition: inline Cc: "Keir \(Xen.org\)" , "Tim \(Xen.org\)" , StefanoStabellini , "xen-devel@lists.xen.org" , "stefano.stabelini@citrix.com" Subject: Re: [Xen-devel] [PATCH 19/21] xen: introduce XEN_GUEST_HANDLE_PARAM X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 05.10.12 at 13:09, Ian Campbell wrote: > On Fri, 2012-10-05 at 12:05 +0100, Jan Beulich wrote: >> >>> On 05.10.12 at 12:38, Ian Campbell wrote: >> > From: Stefano Stabellini >> > >> > XEN_GUEST_HANDLE_PARAM is going to be used to distinguish guest pointers >> > stored in memory from guest pointers as hypercall parameters. >> > >> > guest_handle_* macros default to XEN_GUEST_HANDLE_PARAM as return type. >> > Two new guest_handle_to_param and guest_handle_from_param macros are >> > introduced to do conversions. >> > >> > Changes in v2: >> > >> > - add 2 missing #define _XEN_GUEST_HANDLE_PARAM for the compilation of >> > the compat code. >> > >> > Changes in v3: >> > >> > - move the guest_handle_cast change into this patch; >> > - add a clear comment on top of guest_handle_cast; >> > - also s/XEN_GUEST_HANDLE/XEN_GUEST_HANDLE_PARAM in >> > guest_handle_from_ptr and const_guest_handle_from_ptr; >> > - introduce guest_handle_from_param and guest_handle_to_param. >> >> I may have asked this before, but don't recall the answer: Is there >> really a use case for conversions in both directions? I would think >> that only the "to" version is really useful... > > I can see uses of both in the patched tree. e.g. the from case is used > in handle_iomem_range on x86. Hmm, indeed. But I don't see why, so let me comment there instead. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 11:25:39 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 11:25:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK622-0006PM-6N; Fri, 05 Oct 2012 11:25:26 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK621-0006PF-B0 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 11:25:25 +0000 Received: from [85.158.143.35:27814] by server-2.bemta-4.messagelabs.com id 9C/E3-06610-4A3CE605; Fri, 05 Oct 2012 11:25:24 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1349436291!5445034!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4627 invoked from network); 5 Oct 2012 11:24:52 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 11:24:52 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14960817" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 11:24:51 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 12:24:51 +0100 Message-ID: <1349436290.20946.60.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Jan Beulich Date: Fri, 5 Oct 2012 12:24:50 +0100 In-Reply-To: <506EDE92020000780009FECB@nat28.tlf.novell.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> <1349433507-21148-19-git-send-email-ian.campbell@citrix.com> <506EDB33020000780009FE6C@nat28.tlf.novell.com> <1349435385.20946.53.camel@zakaz.uk.xensource.com> <506EDE92020000780009FECB@nat28.tlf.novell.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Keir \(Xen.org\)" , "Tim \(Xen.org\)" , Stefano Stabellini , "xen-devel@lists.xen.org" , "stefano.stabelini@citrix.com" Subject: Re: [Xen-devel] [PATCH 19/21] xen: introduce XEN_GUEST_HANDLE_PARAM X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-10-05 at 12:20 +0100, Jan Beulich wrote: > >>> On 05.10.12 at 13:09, Ian Campbell wrote: > > I can see uses of both in the patched tree. e.g. the from case is used > > in handle_iomem_range on x86. > > Hmm, indeed. But I don't see why, so let me comment there instead. I suspect I just made the same observation in the subthread about the "buffer_t" variable that you are about to make. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 11:25:39 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 11:25:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK622-0006PM-6N; Fri, 05 Oct 2012 11:25:26 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK621-0006PF-B0 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 11:25:25 +0000 Received: from [85.158.143.35:27814] by server-2.bemta-4.messagelabs.com id 9C/E3-06610-4A3CE605; Fri, 05 Oct 2012 11:25:24 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1349436291!5445034!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4627 invoked from network); 5 Oct 2012 11:24:52 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 11:24:52 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14960817" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 11:24:51 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 12:24:51 +0100 Message-ID: <1349436290.20946.60.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Jan Beulich Date: Fri, 5 Oct 2012 12:24:50 +0100 In-Reply-To: <506EDE92020000780009FECB@nat28.tlf.novell.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> <1349433507-21148-19-git-send-email-ian.campbell@citrix.com> <506EDB33020000780009FE6C@nat28.tlf.novell.com> <1349435385.20946.53.camel@zakaz.uk.xensource.com> <506EDE92020000780009FECB@nat28.tlf.novell.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Keir \(Xen.org\)" , "Tim \(Xen.org\)" , Stefano Stabellini , "xen-devel@lists.xen.org" , "stefano.stabelini@citrix.com" Subject: Re: [Xen-devel] [PATCH 19/21] xen: introduce XEN_GUEST_HANDLE_PARAM X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-10-05 at 12:20 +0100, Jan Beulich wrote: > >>> On 05.10.12 at 13:09, Ian Campbell wrote: > > I can see uses of both in the patched tree. e.g. the from case is used > > in handle_iomem_range on x86. > > Hmm, indeed. But I don't see why, so let me comment there instead. I suspect I just made the same observation in the subthread about the "buffer_t" variable that you are about to make. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 11:30:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 11:30:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK66W-0006Y0-Sd; Fri, 05 Oct 2012 11:30:04 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK66U-0006Xu-Uv for xen-devel@lists.xen.org; Fri, 05 Oct 2012 11:30:03 +0000 Received: from [85.158.138.51:27222] by server-15.bemta-3.messagelabs.com id F9/86-11584-8B4CE605; Fri, 05 Oct 2012 11:30:00 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1349436599!31440683!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7875 invoked from network); 5 Oct 2012 11:29:59 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-15.tower-174.messagelabs.com with SMTP; 5 Oct 2012 11:29:59 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 05 Oct 2012 12:29:59 +0100 Message-Id: <506EE0D7020000780009FEEB@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 05 Oct 2012 12:29:59 +0100 From: "Jan Beulich" To: "Ian Campbell" References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> <1349433507-21148-21-git-send-email-ian.campbell@citrix.com> In-Reply-To: <1349433507-21148-21-git-send-email-ian.campbell@citrix.com> Mime-Version: 1.0 Content-Disposition: inline Cc: tim@xen.org, xen-devel@lists.xen.org, keir@xen.org, Stefano Stabellini Subject: Re: [Xen-devel] [PATCH 21/21] xen: more substitutions X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 05.10.12 at 12:38, Ian Campbell wrote: > @@ -4202,7 +4205,8 @@ static int handle_iomem_range(unsigned long s, unsigned long e, void *p) > ent.addr = (uint64_t)ctxt->s << PAGE_SHIFT; > ent.size = (uint64_t)(s - ctxt->s) << PAGE_SHIFT; > ent.type = E820_RESERVED; > - buffer = guest_handle_cast(ctxt->map.buffer, e820entry_t); > + buffer_t = guest_handle_cast(ctxt->map.buffer, e820entry_t); > + buffer = guest_handle_from_param(buffer_t, e820entry_t); So why is this needed in the first place? I suppose it's related to guest_handle_cast() returning a _HANDLE_PARAM(), but what's the reason for that? Nor would I expect __copy_to_guest_offset() to by unable to deal with one? I.e., can't the infrastructure be made capable of dealing with both, so pointless conversions can be avoided? Or if not, is there really a point in making these changes on the x86 side (they're benign there, and hence only reduce readability)? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 11:30:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 11:30:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK66W-0006Y0-Sd; Fri, 05 Oct 2012 11:30:04 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK66U-0006Xu-Uv for xen-devel@lists.xen.org; Fri, 05 Oct 2012 11:30:03 +0000 Received: from [85.158.138.51:27222] by server-15.bemta-3.messagelabs.com id F9/86-11584-8B4CE605; Fri, 05 Oct 2012 11:30:00 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1349436599!31440683!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7875 invoked from network); 5 Oct 2012 11:29:59 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-15.tower-174.messagelabs.com with SMTP; 5 Oct 2012 11:29:59 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 05 Oct 2012 12:29:59 +0100 Message-Id: <506EE0D7020000780009FEEB@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 05 Oct 2012 12:29:59 +0100 From: "Jan Beulich" To: "Ian Campbell" References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> <1349433507-21148-21-git-send-email-ian.campbell@citrix.com> In-Reply-To: <1349433507-21148-21-git-send-email-ian.campbell@citrix.com> Mime-Version: 1.0 Content-Disposition: inline Cc: tim@xen.org, xen-devel@lists.xen.org, keir@xen.org, Stefano Stabellini Subject: Re: [Xen-devel] [PATCH 21/21] xen: more substitutions X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 05.10.12 at 12:38, Ian Campbell wrote: > @@ -4202,7 +4205,8 @@ static int handle_iomem_range(unsigned long s, unsigned long e, void *p) > ent.addr = (uint64_t)ctxt->s << PAGE_SHIFT; > ent.size = (uint64_t)(s - ctxt->s) << PAGE_SHIFT; > ent.type = E820_RESERVED; > - buffer = guest_handle_cast(ctxt->map.buffer, e820entry_t); > + buffer_t = guest_handle_cast(ctxt->map.buffer, e820entry_t); > + buffer = guest_handle_from_param(buffer_t, e820entry_t); So why is this needed in the first place? I suppose it's related to guest_handle_cast() returning a _HANDLE_PARAM(), but what's the reason for that? Nor would I expect __copy_to_guest_offset() to by unable to deal with one? I.e., can't the infrastructure be made capable of dealing with both, so pointless conversions can be avoided? Or if not, is there really a point in making these changes on the x86 side (they're benign there, and hence only reduce readability)? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 11:31:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 11:31:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK67h-0006d6-Co; Fri, 05 Oct 2012 11:31:17 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK67f-0006d0-OT for xen-devel@lists.xen.org; Fri, 05 Oct 2012 11:31:16 +0000 Received: from [85.158.143.99:17929] by server-1.bemta-4.messagelabs.com id 8B/2F-05684-305CE605; Fri, 05 Oct 2012 11:31:15 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1349436672!24810689!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9362 invoked from network); 5 Oct 2012 11:31:12 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 11:31:12 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14960926" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 11:30:29 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 12:30:29 +0100 Message-ID: <1349436628.20946.63.camel@zakaz.uk.xensource.com> From: Ian Campbell To: "xen-devel@lists.xen.org" Date: Fri, 5 Oct 2012 12:30:28 +0100 In-Reply-To: <1349433507-21148-20-git-send-email-ian.campbell@citrix.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> <1349433507-21148-20-git-send-email-ian.campbell@citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Tim \(Xen.org\)" , "Keir \(Xen.org\)" , "JBeulich@suse.com" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH 20/21] xen: replace XEN_GUEST_HANDLE with XEN_GUEST_HANDLE_PARAM when appropriate X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-10-05 at 11:38 +0100, Ian Campbell wrote: > diff --git a/xen/include/public/tmem.h b/xen/include/public/tmem.h > index 74bd1c6..7bd29ba 100644 > --- a/xen/include/public/tmem.h > +++ b/xen/include/public/tmem.h > @@ -96,7 +96,7 @@ > > #ifndef __ASSEMBLY__ > typedef xen_pfn_t tmem_cli_mfn_t; > -typedef XEN_GUEST_HANDLE(char) tmem_cli_va_t; > +typedef XEN_GUEST_HANDLE_PARAM(char) tmem_cli_va_t; > struct tmem_op { > uint32_t cmd; > int32_t pool_id; This worked on ARM but not on x86_64 (or rather, not with the compat layer), and looking at the below was rather optimistic ;-) This probably ought to be folded into the original patch rather than kept separate. Reviewers, opinions on xen/include/xen/compat.h would be particularly appreciated. 8<-------------------------------------------------- >From b095a4414f146ec6ec7eff6c990bef49deac776b Mon Sep 17 00:00:00 2001 From: Ian Campbell Date: Fri, 5 Oct 2012 11:28:34 +0000 Subject: [PATCH] xen: correct usage of guest handle paramters in tmem Broken by "xen: replace XEN_GUEST_HANDLE with XEN_GUEST_HANDLE_PARAM when appropriate". Signed-off-by: Ian Campbell --- xen/common/tmem.c | 45 ++++++++++++++++++++++++------------------- xen/common/tmem_xen.c | 8 +++--- xen/include/public/tmem.h | 3 +- xen/include/xen/compat.h | 4 ++- xen/include/xen/tmem_xen.h | 15 ++++++++----- 5 files changed, 43 insertions(+), 32 deletions(-) diff --git a/xen/common/tmem.c b/xen/common/tmem.c index ed322b6..1280537 100644 --- a/xen/common/tmem.c +++ b/xen/common/tmem.c @@ -1444,7 +1444,7 @@ static inline void tmem_ensure_avail_pages(void) /************ TMEM CORE OPERATIONS ************************************/ static NOINLINE int do_tmem_put_compress(pgp_t *pgp, tmem_cli_mfn_t cmfn, - tmem_cli_va_t clibuf) + tmem_cli_va_param_t clibuf) { void *dst, *p; size_t size; @@ -1488,7 +1488,7 @@ out: static NOINLINE int do_tmem_dup_put(pgp_t *pgp, tmem_cli_mfn_t cmfn, pagesize_t tmem_offset, pagesize_t pfn_offset, pagesize_t len, - tmem_cli_va_t clibuf) + tmem_cli_va_param_t clibuf) { pool_t *pool; obj_t *obj; @@ -1579,7 +1579,7 @@ cleanup: static NOINLINE int do_tmem_put(pool_t *pool, OID *oidp, uint32_t index, tmem_cli_mfn_t cmfn, pagesize_t tmem_offset, - pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_t clibuf) + pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_param_t clibuf) { obj_t *obj = NULL, *objfound = NULL, *objnew = NULL; pgp_t *pgp = NULL, *pgpdel = NULL; @@ -1722,7 +1722,7 @@ free: static NOINLINE int do_tmem_get(pool_t *pool, OID *oidp, uint32_t index, tmem_cli_mfn_t cmfn, pagesize_t tmem_offset, - pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_t clibuf) + pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_param_t clibuf) { obj_t *obj; pgp_t *pgp; @@ -2066,8 +2066,8 @@ static int tmemc_flush_mem(cli_id_t cli_id, uint32_t kb) */ #define BSIZE 1024 -static int tmemc_list_client(client_t *c, tmem_cli_va_t buf, int off, - uint32_t len, bool_t use_long) +static int tmemc_list_client(client_t *c, tmem_cli_va_param_t buf, + int off, uint32_t len, bool_t use_long) { char info[BSIZE]; int i, n = 0, sum = 0; @@ -2119,7 +2119,7 @@ static int tmemc_list_client(client_t *c, tmem_cli_va_t buf, int off, return sum; } -static int tmemc_list_shared(tmem_cli_va_t buf, int off, uint32_t len, +static int tmemc_list_shared(tmem_cli_va_param_t buf, int off, uint32_t len, bool_t use_long) { char info[BSIZE]; @@ -2159,8 +2159,8 @@ static int tmemc_list_shared(tmem_cli_va_t buf, int off, uint32_t len, } #ifdef TMEM_PERF -static int tmemc_list_global_perf(tmem_cli_va_t buf, int off, uint32_t len, - bool_t use_long) +static int tmemc_list_global_perf(tmem_cli_va_param_t buf, int off, + uint32_t len, bool_t use_long) { char info[BSIZE]; int n = 0, sum = 0; @@ -2194,7 +2194,7 @@ static int tmemc_list_global_perf(tmem_cli_va_t buf, int off, uint32_t len, #define tmemc_list_global_perf(_buf,_off,_len,_use) (0) #endif -static int tmemc_list_global(tmem_cli_va_t buf, int off, uint32_t len, +static int tmemc_list_global(tmem_cli_va_param_t buf, int off, uint32_t len, bool_t use_long) { char info[BSIZE]; @@ -2226,7 +2226,7 @@ static int tmemc_list_global(tmem_cli_va_t buf, int off, uint32_t len, return sum; } -static int tmemc_list(cli_id_t cli_id, tmem_cli_va_t buf, uint32_t len, +static int tmemc_list(cli_id_t cli_id, tmem_cli_va_param_t buf, uint32_t len, bool_t use_long) { client_t *client; @@ -2338,7 +2338,7 @@ static NOINLINE int tmemc_shared_pool_auth(cli_id_t cli_id, uint64_t uuid_lo, } static NOINLINE int tmemc_save_subop(int cli_id, uint32_t pool_id, - uint32_t subop, tmem_cli_va_t buf, uint32_t arg1) + uint32_t subop, tmem_cli_va_param_t buf, uint32_t arg1) { client_t *client = tmh_client_from_cli_id(cli_id); pool_t *pool = (client == NULL || pool_id >= MAX_POOLS_PER_DOMAIN) @@ -2427,7 +2427,7 @@ static NOINLINE int tmemc_save_subop(int cli_id, uint32_t pool_id, } static NOINLINE int tmemc_save_get_next_page(int cli_id, uint32_t pool_id, - tmem_cli_va_t buf, uint32_t bufsize) + tmem_cli_va_param_t buf, uint32_t bufsize) { client_t *client = tmh_client_from_cli_id(cli_id); pool_t *pool = (client == NULL || pool_id >= MAX_POOLS_PER_DOMAIN) @@ -2479,7 +2479,7 @@ out: return ret; } -static NOINLINE int tmemc_save_get_next_inv(int cli_id, tmem_cli_va_t buf, +static NOINLINE int tmemc_save_get_next_inv(int cli_id, tmem_cli_va_param_t buf, uint32_t bufsize) { client_t *client = tmh_client_from_cli_id(cli_id); @@ -2522,7 +2522,7 @@ out: } static int tmemc_restore_put_page(int cli_id, uint32_t pool_id, OID *oidp, - uint32_t index, tmem_cli_va_t buf, uint32_t bufsize) + uint32_t index, tmem_cli_va_param_t buf, uint32_t bufsize) { client_t *client = tmh_client_from_cli_id(cli_id); pool_t *pool = (client == NULL || pool_id >= MAX_POOLS_PER_DOMAIN) @@ -2566,7 +2566,8 @@ static NOINLINE int do_tmem_control(struct tmem_op *op) ret = tmemc_flush_mem(op->u.ctrl.cli_id,op->u.ctrl.arg1); break; case TMEMC_LIST: - ret = tmemc_list(op->u.ctrl.cli_id,op->u.ctrl.buf, + ret = tmemc_list(op->u.ctrl.cli_id, + guest_handle_cast(op->u.ctrl.buf, char), op->u.ctrl.arg1,op->u.ctrl.arg2); break; case TMEMC_SET_WEIGHT: @@ -2589,20 +2590,24 @@ static NOINLINE int do_tmem_control(struct tmem_op *op) case TMEMC_SAVE_GET_POOL_UUID: case TMEMC_SAVE_END: ret = tmemc_save_subop(op->u.ctrl.cli_id,pool_id,subop, - op->u.ctrl.buf,op->u.ctrl.arg1); + guest_handle_cast(op->u.ctrl.buf, char), + op->u.ctrl.arg1); break; case TMEMC_SAVE_GET_NEXT_PAGE: ret = tmemc_save_get_next_page(op->u.ctrl.cli_id, pool_id, - op->u.ctrl.buf, op->u.ctrl.arg1); + guest_handle_cast(op->u.ctrl.buf, char), + op->u.ctrl.arg1); break; case TMEMC_SAVE_GET_NEXT_INV: - ret = tmemc_save_get_next_inv(op->u.ctrl.cli_id, op->u.ctrl.buf, + ret = tmemc_save_get_next_inv(op->u.ctrl.cli_id, + guest_handle_cast(op->u.ctrl.buf, char), op->u.ctrl.arg1); break; case TMEMC_RESTORE_PUT_PAGE: ret = tmemc_restore_put_page(op->u.ctrl.cli_id,pool_id, oidp, op->u.ctrl.arg2, - op->u.ctrl.buf, op->u.ctrl.arg1); + guest_handle_cast(op->u.ctrl.buf, char), + op->u.ctrl.arg1); break; case TMEMC_RESTORE_FLUSH_PAGE: ret = tmemc_restore_flush_page(op->u.ctrl.cli_id,pool_id, diff --git a/xen/common/tmem_xen.c b/xen/common/tmem_xen.c index 9dc2a1d..25fbd6c 100644 --- a/xen/common/tmem_xen.c +++ b/xen/common/tmem_xen.c @@ -146,7 +146,7 @@ static inline void cli_put_page(void *cli_va, pfp_t *cli_pfp, EXPORT int tmh_copy_from_client(pfp_t *pfp, tmem_cli_mfn_t cmfn, pagesize_t tmem_offset, - pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_t clibuf) + pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_param_t clibuf) { unsigned long tmem_mfn, cli_mfn = 0; char *tmem_va, *cli_va = NULL; @@ -194,7 +194,7 @@ EXPORT int tmh_copy_from_client(pfp_t *pfp, } EXPORT int tmh_compress_from_client(tmem_cli_mfn_t cmfn, - void **out_va, size_t *out_len, tmem_cli_va_t clibuf) + void **out_va, size_t *out_len, tmem_cli_va_param_t clibuf) { int ret = 0; unsigned char *dmem = this_cpu(dstmem); @@ -227,7 +227,7 @@ EXPORT int tmh_compress_from_client(tmem_cli_mfn_t cmfn, EXPORT int tmh_copy_to_client(tmem_cli_mfn_t cmfn, pfp_t *pfp, pagesize_t tmem_offset, pagesize_t pfn_offset, pagesize_t len, - tmem_cli_va_t clibuf) + tmem_cli_va_param_t clibuf) { unsigned long tmem_mfn, cli_mfn = 0; char *tmem_va, *cli_va = NULL; @@ -265,7 +265,7 @@ EXPORT int tmh_copy_to_client(tmem_cli_mfn_t cmfn, pfp_t *pfp, } EXPORT int tmh_decompress_to_client(tmem_cli_mfn_t cmfn, void *tmem_va, - size_t size, tmem_cli_va_t clibuf) + size_t size, tmem_cli_va_param_t clibuf) { unsigned long cli_mfn = 0; pfp_t *cli_pfp = NULL; diff --git a/xen/include/public/tmem.h b/xen/include/public/tmem.h index 7bd29ba..91f3a7d 100644 --- a/xen/include/public/tmem.h +++ b/xen/include/public/tmem.h @@ -96,7 +96,8 @@ #ifndef __ASSEMBLY__ typedef xen_pfn_t tmem_cli_mfn_t; -typedef XEN_GUEST_HANDLE_PARAM(char) tmem_cli_va_t; +typedef XEN_GUEST_HANDLE(char) tmem_cli_va_t; +typedef XEN_GUEST_HANDLE_PARAM(char) tmem_cli_va_param_t; struct tmem_op { uint32_t cmd; int32_t pool_id; diff --git a/xen/include/xen/compat.h b/xen/include/xen/compat.h index 857cbc7..5a51ce0 100644 --- a/xen/include/xen/compat.h +++ b/xen/include/xen/compat.h @@ -21,7 +21,9 @@ __DEFINE_COMPAT_HANDLE(name, name); \ __DEFINE_COMPAT_HANDLE(const_ ## name, const name) #define COMPAT_HANDLE(name) __compat_handle_ ## name - +/* NB: it is assumed that if an arch uses the compat layer it does not + * distinguish handles from parameter handles. */ +#define COMPAT_HANDLE_PARAM(name) __compat_handle_ ## name /* Is the compat handle a NULL reference? */ #define compat_handle_is_null(hnd) ((hnd).c == 0) diff --git a/xen/include/xen/tmem_xen.h b/xen/include/xen/tmem_xen.h index c31220a..ef720ed 100644 --- a/xen/include/xen/tmem_xen.h +++ b/xen/include/xen/tmem_xen.h @@ -466,8 +466,9 @@ static inline int tmh_get_tmemop_from_client(tmem_op_t *op, tmem_cli_op_t uops) #define tmh_cli_buf_null guest_handle_from_ptr(NULL, char) -static inline void tmh_copy_to_client_buf_offset(tmem_cli_va_t clibuf, int off, - char *tmembuf, int len) +static inline void tmh_copy_to_client_buf_offset(tmem_cli_va_param_t clibuf, + int off, + char *tmembuf, int len) { copy_to_guest_offset(clibuf,off,tmembuf,len); } @@ -482,15 +483,17 @@ static inline void tmh_copy_to_client_buf_offset(tmem_cli_va_t clibuf, int off, #define tmh_cli_id_str "domid" #define tmh_client_str "domain" -int tmh_decompress_to_client(tmem_cli_mfn_t, void *, size_t, tmem_cli_va_t); +int tmh_decompress_to_client(tmem_cli_mfn_t, void *, size_t, + tmem_cli_va_param_t); -int tmh_compress_from_client(tmem_cli_mfn_t, void **, size_t *, tmem_cli_va_t); +int tmh_compress_from_client(tmem_cli_mfn_t, void **, size_t *, + tmem_cli_va_param_t); int tmh_copy_from_client(pfp_t *, tmem_cli_mfn_t, pagesize_t tmem_offset, - pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_t); + pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_param_t); int tmh_copy_to_client(tmem_cli_mfn_t, pfp_t *, pagesize_t tmem_offset, - pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_t); + pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_param_t); extern int tmh_copy_tze_to_client(tmem_cli_mfn_t cmfn, void *tmem_va, pagesize_t len); -- 1.7.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 11:31:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 11:31:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK67h-0006d6-Co; Fri, 05 Oct 2012 11:31:17 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK67f-0006d0-OT for xen-devel@lists.xen.org; Fri, 05 Oct 2012 11:31:16 +0000 Received: from [85.158.143.99:17929] by server-1.bemta-4.messagelabs.com id 8B/2F-05684-305CE605; Fri, 05 Oct 2012 11:31:15 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1349436672!24810689!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9362 invoked from network); 5 Oct 2012 11:31:12 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 11:31:12 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14960926" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 11:30:29 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 12:30:29 +0100 Message-ID: <1349436628.20946.63.camel@zakaz.uk.xensource.com> From: Ian Campbell To: "xen-devel@lists.xen.org" Date: Fri, 5 Oct 2012 12:30:28 +0100 In-Reply-To: <1349433507-21148-20-git-send-email-ian.campbell@citrix.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> <1349433507-21148-20-git-send-email-ian.campbell@citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Tim \(Xen.org\)" , "Keir \(Xen.org\)" , "JBeulich@suse.com" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH 20/21] xen: replace XEN_GUEST_HANDLE with XEN_GUEST_HANDLE_PARAM when appropriate X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-10-05 at 11:38 +0100, Ian Campbell wrote: > diff --git a/xen/include/public/tmem.h b/xen/include/public/tmem.h > index 74bd1c6..7bd29ba 100644 > --- a/xen/include/public/tmem.h > +++ b/xen/include/public/tmem.h > @@ -96,7 +96,7 @@ > > #ifndef __ASSEMBLY__ > typedef xen_pfn_t tmem_cli_mfn_t; > -typedef XEN_GUEST_HANDLE(char) tmem_cli_va_t; > +typedef XEN_GUEST_HANDLE_PARAM(char) tmem_cli_va_t; > struct tmem_op { > uint32_t cmd; > int32_t pool_id; This worked on ARM but not on x86_64 (or rather, not with the compat layer), and looking at the below was rather optimistic ;-) This probably ought to be folded into the original patch rather than kept separate. Reviewers, opinions on xen/include/xen/compat.h would be particularly appreciated. 8<-------------------------------------------------- >From b095a4414f146ec6ec7eff6c990bef49deac776b Mon Sep 17 00:00:00 2001 From: Ian Campbell Date: Fri, 5 Oct 2012 11:28:34 +0000 Subject: [PATCH] xen: correct usage of guest handle paramters in tmem Broken by "xen: replace XEN_GUEST_HANDLE with XEN_GUEST_HANDLE_PARAM when appropriate". Signed-off-by: Ian Campbell --- xen/common/tmem.c | 45 ++++++++++++++++++++++++------------------- xen/common/tmem_xen.c | 8 +++--- xen/include/public/tmem.h | 3 +- xen/include/xen/compat.h | 4 ++- xen/include/xen/tmem_xen.h | 15 ++++++++----- 5 files changed, 43 insertions(+), 32 deletions(-) diff --git a/xen/common/tmem.c b/xen/common/tmem.c index ed322b6..1280537 100644 --- a/xen/common/tmem.c +++ b/xen/common/tmem.c @@ -1444,7 +1444,7 @@ static inline void tmem_ensure_avail_pages(void) /************ TMEM CORE OPERATIONS ************************************/ static NOINLINE int do_tmem_put_compress(pgp_t *pgp, tmem_cli_mfn_t cmfn, - tmem_cli_va_t clibuf) + tmem_cli_va_param_t clibuf) { void *dst, *p; size_t size; @@ -1488,7 +1488,7 @@ out: static NOINLINE int do_tmem_dup_put(pgp_t *pgp, tmem_cli_mfn_t cmfn, pagesize_t tmem_offset, pagesize_t pfn_offset, pagesize_t len, - tmem_cli_va_t clibuf) + tmem_cli_va_param_t clibuf) { pool_t *pool; obj_t *obj; @@ -1579,7 +1579,7 @@ cleanup: static NOINLINE int do_tmem_put(pool_t *pool, OID *oidp, uint32_t index, tmem_cli_mfn_t cmfn, pagesize_t tmem_offset, - pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_t clibuf) + pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_param_t clibuf) { obj_t *obj = NULL, *objfound = NULL, *objnew = NULL; pgp_t *pgp = NULL, *pgpdel = NULL; @@ -1722,7 +1722,7 @@ free: static NOINLINE int do_tmem_get(pool_t *pool, OID *oidp, uint32_t index, tmem_cli_mfn_t cmfn, pagesize_t tmem_offset, - pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_t clibuf) + pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_param_t clibuf) { obj_t *obj; pgp_t *pgp; @@ -2066,8 +2066,8 @@ static int tmemc_flush_mem(cli_id_t cli_id, uint32_t kb) */ #define BSIZE 1024 -static int tmemc_list_client(client_t *c, tmem_cli_va_t buf, int off, - uint32_t len, bool_t use_long) +static int tmemc_list_client(client_t *c, tmem_cli_va_param_t buf, + int off, uint32_t len, bool_t use_long) { char info[BSIZE]; int i, n = 0, sum = 0; @@ -2119,7 +2119,7 @@ static int tmemc_list_client(client_t *c, tmem_cli_va_t buf, int off, return sum; } -static int tmemc_list_shared(tmem_cli_va_t buf, int off, uint32_t len, +static int tmemc_list_shared(tmem_cli_va_param_t buf, int off, uint32_t len, bool_t use_long) { char info[BSIZE]; @@ -2159,8 +2159,8 @@ static int tmemc_list_shared(tmem_cli_va_t buf, int off, uint32_t len, } #ifdef TMEM_PERF -static int tmemc_list_global_perf(tmem_cli_va_t buf, int off, uint32_t len, - bool_t use_long) +static int tmemc_list_global_perf(tmem_cli_va_param_t buf, int off, + uint32_t len, bool_t use_long) { char info[BSIZE]; int n = 0, sum = 0; @@ -2194,7 +2194,7 @@ static int tmemc_list_global_perf(tmem_cli_va_t buf, int off, uint32_t len, #define tmemc_list_global_perf(_buf,_off,_len,_use) (0) #endif -static int tmemc_list_global(tmem_cli_va_t buf, int off, uint32_t len, +static int tmemc_list_global(tmem_cli_va_param_t buf, int off, uint32_t len, bool_t use_long) { char info[BSIZE]; @@ -2226,7 +2226,7 @@ static int tmemc_list_global(tmem_cli_va_t buf, int off, uint32_t len, return sum; } -static int tmemc_list(cli_id_t cli_id, tmem_cli_va_t buf, uint32_t len, +static int tmemc_list(cli_id_t cli_id, tmem_cli_va_param_t buf, uint32_t len, bool_t use_long) { client_t *client; @@ -2338,7 +2338,7 @@ static NOINLINE int tmemc_shared_pool_auth(cli_id_t cli_id, uint64_t uuid_lo, } static NOINLINE int tmemc_save_subop(int cli_id, uint32_t pool_id, - uint32_t subop, tmem_cli_va_t buf, uint32_t arg1) + uint32_t subop, tmem_cli_va_param_t buf, uint32_t arg1) { client_t *client = tmh_client_from_cli_id(cli_id); pool_t *pool = (client == NULL || pool_id >= MAX_POOLS_PER_DOMAIN) @@ -2427,7 +2427,7 @@ static NOINLINE int tmemc_save_subop(int cli_id, uint32_t pool_id, } static NOINLINE int tmemc_save_get_next_page(int cli_id, uint32_t pool_id, - tmem_cli_va_t buf, uint32_t bufsize) + tmem_cli_va_param_t buf, uint32_t bufsize) { client_t *client = tmh_client_from_cli_id(cli_id); pool_t *pool = (client == NULL || pool_id >= MAX_POOLS_PER_DOMAIN) @@ -2479,7 +2479,7 @@ out: return ret; } -static NOINLINE int tmemc_save_get_next_inv(int cli_id, tmem_cli_va_t buf, +static NOINLINE int tmemc_save_get_next_inv(int cli_id, tmem_cli_va_param_t buf, uint32_t bufsize) { client_t *client = tmh_client_from_cli_id(cli_id); @@ -2522,7 +2522,7 @@ out: } static int tmemc_restore_put_page(int cli_id, uint32_t pool_id, OID *oidp, - uint32_t index, tmem_cli_va_t buf, uint32_t bufsize) + uint32_t index, tmem_cli_va_param_t buf, uint32_t bufsize) { client_t *client = tmh_client_from_cli_id(cli_id); pool_t *pool = (client == NULL || pool_id >= MAX_POOLS_PER_DOMAIN) @@ -2566,7 +2566,8 @@ static NOINLINE int do_tmem_control(struct tmem_op *op) ret = tmemc_flush_mem(op->u.ctrl.cli_id,op->u.ctrl.arg1); break; case TMEMC_LIST: - ret = tmemc_list(op->u.ctrl.cli_id,op->u.ctrl.buf, + ret = tmemc_list(op->u.ctrl.cli_id, + guest_handle_cast(op->u.ctrl.buf, char), op->u.ctrl.arg1,op->u.ctrl.arg2); break; case TMEMC_SET_WEIGHT: @@ -2589,20 +2590,24 @@ static NOINLINE int do_tmem_control(struct tmem_op *op) case TMEMC_SAVE_GET_POOL_UUID: case TMEMC_SAVE_END: ret = tmemc_save_subop(op->u.ctrl.cli_id,pool_id,subop, - op->u.ctrl.buf,op->u.ctrl.arg1); + guest_handle_cast(op->u.ctrl.buf, char), + op->u.ctrl.arg1); break; case TMEMC_SAVE_GET_NEXT_PAGE: ret = tmemc_save_get_next_page(op->u.ctrl.cli_id, pool_id, - op->u.ctrl.buf, op->u.ctrl.arg1); + guest_handle_cast(op->u.ctrl.buf, char), + op->u.ctrl.arg1); break; case TMEMC_SAVE_GET_NEXT_INV: - ret = tmemc_save_get_next_inv(op->u.ctrl.cli_id, op->u.ctrl.buf, + ret = tmemc_save_get_next_inv(op->u.ctrl.cli_id, + guest_handle_cast(op->u.ctrl.buf, char), op->u.ctrl.arg1); break; case TMEMC_RESTORE_PUT_PAGE: ret = tmemc_restore_put_page(op->u.ctrl.cli_id,pool_id, oidp, op->u.ctrl.arg2, - op->u.ctrl.buf, op->u.ctrl.arg1); + guest_handle_cast(op->u.ctrl.buf, char), + op->u.ctrl.arg1); break; case TMEMC_RESTORE_FLUSH_PAGE: ret = tmemc_restore_flush_page(op->u.ctrl.cli_id,pool_id, diff --git a/xen/common/tmem_xen.c b/xen/common/tmem_xen.c index 9dc2a1d..25fbd6c 100644 --- a/xen/common/tmem_xen.c +++ b/xen/common/tmem_xen.c @@ -146,7 +146,7 @@ static inline void cli_put_page(void *cli_va, pfp_t *cli_pfp, EXPORT int tmh_copy_from_client(pfp_t *pfp, tmem_cli_mfn_t cmfn, pagesize_t tmem_offset, - pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_t clibuf) + pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_param_t clibuf) { unsigned long tmem_mfn, cli_mfn = 0; char *tmem_va, *cli_va = NULL; @@ -194,7 +194,7 @@ EXPORT int tmh_copy_from_client(pfp_t *pfp, } EXPORT int tmh_compress_from_client(tmem_cli_mfn_t cmfn, - void **out_va, size_t *out_len, tmem_cli_va_t clibuf) + void **out_va, size_t *out_len, tmem_cli_va_param_t clibuf) { int ret = 0; unsigned char *dmem = this_cpu(dstmem); @@ -227,7 +227,7 @@ EXPORT int tmh_compress_from_client(tmem_cli_mfn_t cmfn, EXPORT int tmh_copy_to_client(tmem_cli_mfn_t cmfn, pfp_t *pfp, pagesize_t tmem_offset, pagesize_t pfn_offset, pagesize_t len, - tmem_cli_va_t clibuf) + tmem_cli_va_param_t clibuf) { unsigned long tmem_mfn, cli_mfn = 0; char *tmem_va, *cli_va = NULL; @@ -265,7 +265,7 @@ EXPORT int tmh_copy_to_client(tmem_cli_mfn_t cmfn, pfp_t *pfp, } EXPORT int tmh_decompress_to_client(tmem_cli_mfn_t cmfn, void *tmem_va, - size_t size, tmem_cli_va_t clibuf) + size_t size, tmem_cli_va_param_t clibuf) { unsigned long cli_mfn = 0; pfp_t *cli_pfp = NULL; diff --git a/xen/include/public/tmem.h b/xen/include/public/tmem.h index 7bd29ba..91f3a7d 100644 --- a/xen/include/public/tmem.h +++ b/xen/include/public/tmem.h @@ -96,7 +96,8 @@ #ifndef __ASSEMBLY__ typedef xen_pfn_t tmem_cli_mfn_t; -typedef XEN_GUEST_HANDLE_PARAM(char) tmem_cli_va_t; +typedef XEN_GUEST_HANDLE(char) tmem_cli_va_t; +typedef XEN_GUEST_HANDLE_PARAM(char) tmem_cli_va_param_t; struct tmem_op { uint32_t cmd; int32_t pool_id; diff --git a/xen/include/xen/compat.h b/xen/include/xen/compat.h index 857cbc7..5a51ce0 100644 --- a/xen/include/xen/compat.h +++ b/xen/include/xen/compat.h @@ -21,7 +21,9 @@ __DEFINE_COMPAT_HANDLE(name, name); \ __DEFINE_COMPAT_HANDLE(const_ ## name, const name) #define COMPAT_HANDLE(name) __compat_handle_ ## name - +/* NB: it is assumed that if an arch uses the compat layer it does not + * distinguish handles from parameter handles. */ +#define COMPAT_HANDLE_PARAM(name) __compat_handle_ ## name /* Is the compat handle a NULL reference? */ #define compat_handle_is_null(hnd) ((hnd).c == 0) diff --git a/xen/include/xen/tmem_xen.h b/xen/include/xen/tmem_xen.h index c31220a..ef720ed 100644 --- a/xen/include/xen/tmem_xen.h +++ b/xen/include/xen/tmem_xen.h @@ -466,8 +466,9 @@ static inline int tmh_get_tmemop_from_client(tmem_op_t *op, tmem_cli_op_t uops) #define tmh_cli_buf_null guest_handle_from_ptr(NULL, char) -static inline void tmh_copy_to_client_buf_offset(tmem_cli_va_t clibuf, int off, - char *tmembuf, int len) +static inline void tmh_copy_to_client_buf_offset(tmem_cli_va_param_t clibuf, + int off, + char *tmembuf, int len) { copy_to_guest_offset(clibuf,off,tmembuf,len); } @@ -482,15 +483,17 @@ static inline void tmh_copy_to_client_buf_offset(tmem_cli_va_t clibuf, int off, #define tmh_cli_id_str "domid" #define tmh_client_str "domain" -int tmh_decompress_to_client(tmem_cli_mfn_t, void *, size_t, tmem_cli_va_t); +int tmh_decompress_to_client(tmem_cli_mfn_t, void *, size_t, + tmem_cli_va_param_t); -int tmh_compress_from_client(tmem_cli_mfn_t, void **, size_t *, tmem_cli_va_t); +int tmh_compress_from_client(tmem_cli_mfn_t, void **, size_t *, + tmem_cli_va_param_t); int tmh_copy_from_client(pfp_t *, tmem_cli_mfn_t, pagesize_t tmem_offset, - pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_t); + pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_param_t); int tmh_copy_to_client(tmem_cli_mfn_t, pfp_t *, pagesize_t tmem_offset, - pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_t); + pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_param_t); extern int tmh_copy_tze_to_client(tmem_cli_mfn_t cmfn, void *tmem_va, pagesize_t len); -- 1.7.9.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 11:33:23 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 11:33:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK69X-0006mG-3B; Fri, 05 Oct 2012 11:33:11 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with smtp (Exim 4.72) (envelope-from ) id 1TK69V-0006lq-SU for xen-devel@lists.xen.org; Fri, 05 Oct 2012 11:33:10 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1349436783!7479450!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14057 invoked from network); 5 Oct 2012 11:33:03 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-5.tower-27.messagelabs.com with SMTP; 5 Oct 2012 11:33:03 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 05 Oct 2012 12:33:03 +0100 Message-Id: <506EE190020000780009FEFB@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 05 Oct 2012 12:33:04 +0100 From: "Jan Beulich" To: "Ian Campbell" References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> <1349433507-21148-21-git-send-email-ian.campbell@citrix.com> <506EDC11020000780009FE93@nat28.tlf.novell.com> <1349435697.20946.57.camel@zakaz.uk.xensource.com> In-Reply-To: <1349435697.20946.57.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Disposition: inline Cc: "Tim \(Xen.org\)" , "xen-devel@lists.xen.org" , "Keir \(Xen.org\)" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH 21/21] xen: more substitutions X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 05.10.12 at 13:14, Ian Campbell wrote: > On Fri, 2012-10-05 at 12:09 +0100, Jan Beulich wrote: >> >>> On 05.10.12 at 12:38, Ian Campbell wrote: >> > @@ -4195,6 +4197,7 @@ static int handle_iomem_range(unsigned long s, > unsigned long e, void *p) >> > if ( s > ctxt->s ) >> > { >> > e820entry_t ent; >> > + XEN_GUEST_HANDLE_PARAM(e820entry_t) buffer_t; >> >> I'm not really in favor fo the _t suffix chosen here and below, as >> that's generally used for typedef-s. Could this be replaced with >> e.g. _p, _h, or _hp? > > The use is > buffer_t = guest_handle_cast(ctxt->map.buffer, e820entry_t); > buffer = guest_handle_from_param(buffer_t, e820entry_t); > which seems a bit strange to me -- we launder through buffer_t solely to > use guest_handle_from_param. Is there no macro which does that in one > step? > > That would avoid the whole problem of the suffix choice. > > Also buffer is then passed to __copy_to_guest_offset, and I'm not sure > why that can't be passed ctxt->map.buffer directly rather than > laundering it through those two macros... Passing directly is not possible, as the type referred to be the handle is relevant for the macro's operation (and it's "void" in struct xen_memory_map). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 11:33:23 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 11:33:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK69X-0006mG-3B; Fri, 05 Oct 2012 11:33:11 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with smtp (Exim 4.72) (envelope-from ) id 1TK69V-0006lq-SU for xen-devel@lists.xen.org; Fri, 05 Oct 2012 11:33:10 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1349436783!7479450!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14057 invoked from network); 5 Oct 2012 11:33:03 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-5.tower-27.messagelabs.com with SMTP; 5 Oct 2012 11:33:03 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 05 Oct 2012 12:33:03 +0100 Message-Id: <506EE190020000780009FEFB@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 05 Oct 2012 12:33:04 +0100 From: "Jan Beulich" To: "Ian Campbell" References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> <1349433507-21148-21-git-send-email-ian.campbell@citrix.com> <506EDC11020000780009FE93@nat28.tlf.novell.com> <1349435697.20946.57.camel@zakaz.uk.xensource.com> In-Reply-To: <1349435697.20946.57.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Disposition: inline Cc: "Tim \(Xen.org\)" , "xen-devel@lists.xen.org" , "Keir \(Xen.org\)" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH 21/21] xen: more substitutions X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 05.10.12 at 13:14, Ian Campbell wrote: > On Fri, 2012-10-05 at 12:09 +0100, Jan Beulich wrote: >> >>> On 05.10.12 at 12:38, Ian Campbell wrote: >> > @@ -4195,6 +4197,7 @@ static int handle_iomem_range(unsigned long s, > unsigned long e, void *p) >> > if ( s > ctxt->s ) >> > { >> > e820entry_t ent; >> > + XEN_GUEST_HANDLE_PARAM(e820entry_t) buffer_t; >> >> I'm not really in favor fo the _t suffix chosen here and below, as >> that's generally used for typedef-s. Could this be replaced with >> e.g. _p, _h, or _hp? > > The use is > buffer_t = guest_handle_cast(ctxt->map.buffer, e820entry_t); > buffer = guest_handle_from_param(buffer_t, e820entry_t); > which seems a bit strange to me -- we launder through buffer_t solely to > use guest_handle_from_param. Is there no macro which does that in one > step? > > That would avoid the whole problem of the suffix choice. > > Also buffer is then passed to __copy_to_guest_offset, and I'm not sure > why that can't be passed ctxt->map.buffer directly rather than > laundering it through those two macros... Passing directly is not possible, as the type referred to be the handle is relevant for the macro's operation (and it's "void" in struct xen_memory_map). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 11:33:44 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 11:33:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK69t-0006pX-GM; Fri, 05 Oct 2012 11:33:33 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK69r-0006pC-7V for xen-devel@lists.xen.org; Fri, 05 Oct 2012 11:33:31 +0000 Received: from [85.158.143.35:10301] by server-3.bemta-4.messagelabs.com id A7/F2-10986-A85CE605; Fri, 05 Oct 2012 11:33:30 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1349436809!14687667!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20003 invoked from network); 5 Oct 2012 11:33:29 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 11:33:29 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14961003" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 11:33:28 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 12:33:28 +0100 Date: Fri, 5 Oct 2012 12:32:27 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Ian Campbell In-Reply-To: <1349351583.866.10.camel@zakaz.uk.xensource.com> Message-ID: References: <1349351583.866.10.camel@zakaz.uk.xensource.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: Stefano Stabellini , "Keir \(Xen.org\)" , Jan Beulich , xen-devel Subject: Re: [Xen-devel] [PATCH] xen: arm: implement XENMEM_add_to_physmap_range X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 4 Oct 2012, Ian Campbell wrote: > This is an implementation of XENMEM_add_to_physmap_range as previously > discussed. > > This applies on top of > git://xenbits.xen.org/people/ianc/xen-unstable.git arm-for-4.3 + > Stefano's "ARM hypercall ABI: 64 bit ready" series. > > I think this should replace "HACK: arm: initial > XENMAPSPACE_gmfn_foreign" (from the branch) and "xen: improve changes to > xen_add_to_physmap" (from Stefano's series) and we should make it > invalid to call XENMEM_add_to_physmap with XENMAPSPACE_gmfn_foreign > (i.e. get rid of the union etc). > > I intend to do this as as I rebase the arm-for-4.3 branch to post for > inclusion in mainline. i.e. drop the original HACK in favour of this > patch. > > What is the status of Stefano's "ARM hypercall ABI: 64 bit ready"? It > touches common and arch/x86 code/interfaces so it'll need pretty wide > ranging ack's I think. > > 8<------------------------------------------------------- > > > From 1e889407a8e93fdbaf591c74fb3f2fe01f9016ac Mon Sep 17 00:00:00 2001 > From: Ian Campbell > Date: Thu, 4 Oct 2012 11:25:18 +0000 > Subject: [PATCH] xen: arm: implement XENMEM_add_to_physmap_range > > This allows for foreign mappings as well as batching, fitting all that > into XENMEM_add_to_physmap wasn't possible. > > Signed-off-by: Ian Campbell looks reasonable to me > xen/arch/arm/mm.c | 103 ++++++++++++++++++++++++++++++++++++------- > xen/include/public/memory.h | 41 +++++++++++++---- > xen/include/public/xen.h | 1 + > 3 files changed, 119 insertions(+), 26 deletions(-) > > diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c > index 3e8b6cc..9e7d2d2 100644 > --- a/xen/arch/arm/mm.c > +++ b/xen/arch/arm/mm.c > @@ -26,6 +26,8 @@ > #include > #include > #include > +#include > +#include > #include > #include > #include > @@ -462,14 +464,17 @@ void share_xen_page_with_guest(struct page_info *page, > spin_unlock(&d->page_alloc_lock); > } > > -static int xenmem_add_to_physmap_once( > +static int xenmem_add_to_physmap_one( > struct domain *d, > - const struct xen_add_to_physmap *xatp) > + uint16_t space, > + domid_t foreign_domid, > + unsigned long idx, > + xen_pfn_t gpfn) > { > - unsigned long mfn = 0, idx = 0; > + unsigned long mfn = 0; > int rc; > > - switch ( xatp->space ) > + switch ( space ) > { > case XENMAPSPACE_grant_table: > spin_lock(&d->grant_table->lock); > @@ -477,9 +482,8 @@ static int xenmem_add_to_physmap_once( > if ( d->grant_table->gt_version == 0 ) > d->grant_table->gt_version = 1; > > - idx = xatp->idx; > if ( d->grant_table->gt_version == 2 && > - (xatp->idx & XENMAPIDX_grant_table_status) ) > + (idx & XENMAPIDX_grant_table_status) ) > { > idx &= ~XENMAPIDX_grant_table_status; > if ( idx < nr_status_frames(d->grant_table) ) > @@ -498,29 +502,31 @@ static int xenmem_add_to_physmap_once( > spin_unlock(&d->grant_table->lock); > break; > case XENMAPSPACE_shared_info: > - if ( xatp->idx == 0 ) > + if ( idx == 0 ) > mfn = virt_to_mfn(d->shared_info); > break; > case XENMAPSPACE_gmfn_foreign: > { > paddr_t maddr; > struct domain *od; > - > - rc = rcu_lock_target_domain_by_id(xatp->u.foreign_domid, &od); > + rc = rcu_lock_target_domain_by_id(foreign_domid, &od); > if ( rc < 0 ) > return rc; > - maddr = p2m_lookup(od, xatp->idx << PAGE_SHIFT); > + > + maddr = p2m_lookup(od, idx << PAGE_SHIFT); > if ( maddr == INVALID_PADDR ) > { > - printk("bad p2m lookup\n"); > - dump_p2m_lookup(od, xatp->idx << PAGE_SHIFT); > + dump_p2m_lookup(od, idx << PAGE_SHIFT); > rcu_unlock_domain(od); > return -EINVAL; > } > + > mfn = maddr >> PAGE_SHIFT; > + > rcu_unlock_domain(od); > break; > } > + > default: > return -ENOSYS; > } > @@ -528,17 +534,51 @@ static int xenmem_add_to_physmap_once( > domain_lock(d); > > /* Map at new location. */ > - rc = guest_physmap_add_page(d, xatp->gpfn, mfn, 0); > + rc = guest_physmap_add_page(d, gpfn, mfn, 0); > > domain_unlock(d); > > return rc; > } > > -static int xenmem_add_to_physmap(struct domain *d, > - struct xen_add_to_physmap *xatp) > +static int xenmem_add_to_physmap_range(struct domain *d, > + struct xen_add_to_physmap_range *xatpr) > { > - return xenmem_add_to_physmap_once(d, xatp); > + int rc; > + > + /* Process entries in reverse order to allow continuations */ > + while ( xatpr->size > 0 ) > + { > + xen_ulong_t idx; > + xen_pfn_t gpfn; > + > + rc = copy_from_guest_offset(&idx, xatpr->idxs, xatpr->size-1, 1); > + if ( rc < 0 ) > + goto out; > + > + rc = copy_from_guest_offset(&gpfn, xatpr->gpfns, xatpr->size-1, 1); > + if ( rc < 0 ) > + goto out; > + > + rc = xenmem_add_to_physmap_one(d, xatpr->space, > + xatpr->foreign_domid, > + idx, gpfn); > + > + xatpr->size--; > + > + /* Check for continuation if it's not the last interation */ > + if ( xatpr->size > 0 && hypercall_preempt_check() ) > + { > + rc = -EAGAIN; > + goto out; > + } > + } > + > + rc = 0; > + > +out: > + return rc; > + > } > > long arch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg) > @@ -559,13 +599,42 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg) > if ( rc != 0 ) > return rc; > > - rc = xenmem_add_to_physmap(d, &xatp); > + rc = xenmem_add_to_physmap_one(d, xatp.space, > + xatp.space == XENMAPSPACE_gmfn_foreign ? > + xatp.u.foreign_domid : DOMID_INVALID, > + xatp.idx, xatp.gpfn); > > rcu_unlock_domain(d); > > return rc; > } > > + case XENMEM_add_to_physmap_range: > + { > + struct xen_add_to_physmap_range xatpr; > + struct domain *d; > + > + if ( copy_from_guest(&xatpr, arg, 1) ) > + return -EFAULT; > + > + rc = rcu_lock_target_domain_by_id(xatpr.domid, &d); > + if ( rc != 0 ) > + return rc; > + > + rc = xenmem_add_to_physmap_range(d, &xatpr); > + > + rcu_unlock_domain(d); > + > + if ( rc && copy_to_guest(arg, &xatpr, 1) ) > + rc = -EFAULT; > + > + if ( rc == -EAGAIN ) > + rc = hypercall_create_continuation( > + __HYPERVISOR_memory_op, "ih", op, arg); > + > + return rc; > + } > + > default: > return -ENOSYS; > } > diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h > index 7d4ee26..29d0b94 100644 > --- a/xen/include/public/memory.h > +++ b/xen/include/public/memory.h > @@ -198,6 +198,15 @@ struct xen_machphys_mapping { > typedef struct xen_machphys_mapping xen_machphys_mapping_t; > DEFINE_XEN_GUEST_HANDLE(xen_machphys_mapping_t); > > +/* Source mapping space. */ > +/* ` enum phys_map_space { */ > +#define XENMAPSPACE_shared_info 0 /* shared info page */ > +#define XENMAPSPACE_grant_table 1 /* grant table page */ > +#define XENMAPSPACE_gmfn 2 /* GMFN */ > +#define XENMAPSPACE_gmfn_range 3 /* GMFN range */ > +#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another dom */ > +/* ` } */ > + > /* > * Sets the GPFN at which a particular page appears in the specified guest's > * pseudophysical address space. > @@ -215,25 +224,39 @@ struct xen_add_to_physmap { > domid_t foreign_domid; > } u; > > - /* Source mapping space. */ > -#define XENMAPSPACE_shared_info 0 /* shared info page */ > -#define XENMAPSPACE_grant_table 1 /* grant table page */ > -#define XENMAPSPACE_gmfn 2 /* GMFN */ > -#define XENMAPSPACE_gmfn_range 3 /* GMFN range */ > -#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */ > - unsigned int space; > + unsigned int space; /* => enum phys_map_space */ > > #define XENMAPIDX_grant_table_status 0x80000000 > > - /* Index into source mapping space. */ > + /* Index into space being mapped. */ > xen_ulong_t idx; > > - /* GPFN where the source mapping page should appear. */ > + /* GPFN in domid where the source mapping page should appear. */ > xen_pfn_t gpfn; > }; > typedef struct xen_add_to_physmap xen_add_to_physmap_t; > DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_t); > > +/* A batched version of add_to_physmap. */ > +#define XENMEM_add_to_physmap_range 23 > +struct xen_add_to_physmap_range { > + /* Which domain to change the mapping for. */ > + domid_t domid; > + uint16_t space; /* => enum phys_map_space */ > + > + /* Number of pages to go through */ > + uint16_t size; > + domid_t foreign_domid; /* IFF gmfn_foreign */ > + > + /* Indexes into space being mapped. */ > + XEN_GUEST_HANDLE(xen_ulong_t) idxs; > + > + /* GPFN in domdwhere the source mapping page should appear. */ > + XEN_GUEST_HANDLE(xen_pfn_t) gpfns; > +}; > +typedef struct xen_add_to_physmap_range xen_add_to_physmap_range_t; > +DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_range_t); > + > /* > * Unmaps the page appearing at a particular GPFN from the specified guest's > * pseudophysical address space. > diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h > index b2f6c50..9425520 100644 > --- a/xen/include/public/xen.h > +++ b/xen/include/public/xen.h > @@ -51,6 +51,7 @@ DEFINE_XEN_GUEST_HANDLE(void); > > DEFINE_XEN_GUEST_HANDLE(uint64_t); > DEFINE_XEN_GUEST_HANDLE(xen_pfn_t); > +DEFINE_XEN_GUEST_HANDLE(xen_ulong_t); > #endif > > /* > -- > 1.7.9.1 > > > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 11:33:44 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 11:33:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK69t-0006pX-GM; Fri, 05 Oct 2012 11:33:33 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK69r-0006pC-7V for xen-devel@lists.xen.org; Fri, 05 Oct 2012 11:33:31 +0000 Received: from [85.158.143.35:10301] by server-3.bemta-4.messagelabs.com id A7/F2-10986-A85CE605; Fri, 05 Oct 2012 11:33:30 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1349436809!14687667!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20003 invoked from network); 5 Oct 2012 11:33:29 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 11:33:29 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14961003" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 11:33:28 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 12:33:28 +0100 Date: Fri, 5 Oct 2012 12:32:27 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Ian Campbell In-Reply-To: <1349351583.866.10.camel@zakaz.uk.xensource.com> Message-ID: References: <1349351583.866.10.camel@zakaz.uk.xensource.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: Stefano Stabellini , "Keir \(Xen.org\)" , Jan Beulich , xen-devel Subject: Re: [Xen-devel] [PATCH] xen: arm: implement XENMEM_add_to_physmap_range X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 4 Oct 2012, Ian Campbell wrote: > This is an implementation of XENMEM_add_to_physmap_range as previously > discussed. > > This applies on top of > git://xenbits.xen.org/people/ianc/xen-unstable.git arm-for-4.3 + > Stefano's "ARM hypercall ABI: 64 bit ready" series. > > I think this should replace "HACK: arm: initial > XENMAPSPACE_gmfn_foreign" (from the branch) and "xen: improve changes to > xen_add_to_physmap" (from Stefano's series) and we should make it > invalid to call XENMEM_add_to_physmap with XENMAPSPACE_gmfn_foreign > (i.e. get rid of the union etc). > > I intend to do this as as I rebase the arm-for-4.3 branch to post for > inclusion in mainline. i.e. drop the original HACK in favour of this > patch. > > What is the status of Stefano's "ARM hypercall ABI: 64 bit ready"? It > touches common and arch/x86 code/interfaces so it'll need pretty wide > ranging ack's I think. > > 8<------------------------------------------------------- > > > From 1e889407a8e93fdbaf591c74fb3f2fe01f9016ac Mon Sep 17 00:00:00 2001 > From: Ian Campbell > Date: Thu, 4 Oct 2012 11:25:18 +0000 > Subject: [PATCH] xen: arm: implement XENMEM_add_to_physmap_range > > This allows for foreign mappings as well as batching, fitting all that > into XENMEM_add_to_physmap wasn't possible. > > Signed-off-by: Ian Campbell looks reasonable to me > xen/arch/arm/mm.c | 103 ++++++++++++++++++++++++++++++++++++------- > xen/include/public/memory.h | 41 +++++++++++++---- > xen/include/public/xen.h | 1 + > 3 files changed, 119 insertions(+), 26 deletions(-) > > diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c > index 3e8b6cc..9e7d2d2 100644 > --- a/xen/arch/arm/mm.c > +++ b/xen/arch/arm/mm.c > @@ -26,6 +26,8 @@ > #include > #include > #include > +#include > +#include > #include > #include > #include > @@ -462,14 +464,17 @@ void share_xen_page_with_guest(struct page_info *page, > spin_unlock(&d->page_alloc_lock); > } > > -static int xenmem_add_to_physmap_once( > +static int xenmem_add_to_physmap_one( > struct domain *d, > - const struct xen_add_to_physmap *xatp) > + uint16_t space, > + domid_t foreign_domid, > + unsigned long idx, > + xen_pfn_t gpfn) > { > - unsigned long mfn = 0, idx = 0; > + unsigned long mfn = 0; > int rc; > > - switch ( xatp->space ) > + switch ( space ) > { > case XENMAPSPACE_grant_table: > spin_lock(&d->grant_table->lock); > @@ -477,9 +482,8 @@ static int xenmem_add_to_physmap_once( > if ( d->grant_table->gt_version == 0 ) > d->grant_table->gt_version = 1; > > - idx = xatp->idx; > if ( d->grant_table->gt_version == 2 && > - (xatp->idx & XENMAPIDX_grant_table_status) ) > + (idx & XENMAPIDX_grant_table_status) ) > { > idx &= ~XENMAPIDX_grant_table_status; > if ( idx < nr_status_frames(d->grant_table) ) > @@ -498,29 +502,31 @@ static int xenmem_add_to_physmap_once( > spin_unlock(&d->grant_table->lock); > break; > case XENMAPSPACE_shared_info: > - if ( xatp->idx == 0 ) > + if ( idx == 0 ) > mfn = virt_to_mfn(d->shared_info); > break; > case XENMAPSPACE_gmfn_foreign: > { > paddr_t maddr; > struct domain *od; > - > - rc = rcu_lock_target_domain_by_id(xatp->u.foreign_domid, &od); > + rc = rcu_lock_target_domain_by_id(foreign_domid, &od); > if ( rc < 0 ) > return rc; > - maddr = p2m_lookup(od, xatp->idx << PAGE_SHIFT); > + > + maddr = p2m_lookup(od, idx << PAGE_SHIFT); > if ( maddr == INVALID_PADDR ) > { > - printk("bad p2m lookup\n"); > - dump_p2m_lookup(od, xatp->idx << PAGE_SHIFT); > + dump_p2m_lookup(od, idx << PAGE_SHIFT); > rcu_unlock_domain(od); > return -EINVAL; > } > + > mfn = maddr >> PAGE_SHIFT; > + > rcu_unlock_domain(od); > break; > } > + > default: > return -ENOSYS; > } > @@ -528,17 +534,51 @@ static int xenmem_add_to_physmap_once( > domain_lock(d); > > /* Map at new location. */ > - rc = guest_physmap_add_page(d, xatp->gpfn, mfn, 0); > + rc = guest_physmap_add_page(d, gpfn, mfn, 0); > > domain_unlock(d); > > return rc; > } > > -static int xenmem_add_to_physmap(struct domain *d, > - struct xen_add_to_physmap *xatp) > +static int xenmem_add_to_physmap_range(struct domain *d, > + struct xen_add_to_physmap_range *xatpr) > { > - return xenmem_add_to_physmap_once(d, xatp); > + int rc; > + > + /* Process entries in reverse order to allow continuations */ > + while ( xatpr->size > 0 ) > + { > + xen_ulong_t idx; > + xen_pfn_t gpfn; > + > + rc = copy_from_guest_offset(&idx, xatpr->idxs, xatpr->size-1, 1); > + if ( rc < 0 ) > + goto out; > + > + rc = copy_from_guest_offset(&gpfn, xatpr->gpfns, xatpr->size-1, 1); > + if ( rc < 0 ) > + goto out; > + > + rc = xenmem_add_to_physmap_one(d, xatpr->space, > + xatpr->foreign_domid, > + idx, gpfn); > + > + xatpr->size--; > + > + /* Check for continuation if it's not the last interation */ > + if ( xatpr->size > 0 && hypercall_preempt_check() ) > + { > + rc = -EAGAIN; > + goto out; > + } > + } > + > + rc = 0; > + > +out: > + return rc; > + > } > > long arch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg) > @@ -559,13 +599,42 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg) > if ( rc != 0 ) > return rc; > > - rc = xenmem_add_to_physmap(d, &xatp); > + rc = xenmem_add_to_physmap_one(d, xatp.space, > + xatp.space == XENMAPSPACE_gmfn_foreign ? > + xatp.u.foreign_domid : DOMID_INVALID, > + xatp.idx, xatp.gpfn); > > rcu_unlock_domain(d); > > return rc; > } > > + case XENMEM_add_to_physmap_range: > + { > + struct xen_add_to_physmap_range xatpr; > + struct domain *d; > + > + if ( copy_from_guest(&xatpr, arg, 1) ) > + return -EFAULT; > + > + rc = rcu_lock_target_domain_by_id(xatpr.domid, &d); > + if ( rc != 0 ) > + return rc; > + > + rc = xenmem_add_to_physmap_range(d, &xatpr); > + > + rcu_unlock_domain(d); > + > + if ( rc && copy_to_guest(arg, &xatpr, 1) ) > + rc = -EFAULT; > + > + if ( rc == -EAGAIN ) > + rc = hypercall_create_continuation( > + __HYPERVISOR_memory_op, "ih", op, arg); > + > + return rc; > + } > + > default: > return -ENOSYS; > } > diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h > index 7d4ee26..29d0b94 100644 > --- a/xen/include/public/memory.h > +++ b/xen/include/public/memory.h > @@ -198,6 +198,15 @@ struct xen_machphys_mapping { > typedef struct xen_machphys_mapping xen_machphys_mapping_t; > DEFINE_XEN_GUEST_HANDLE(xen_machphys_mapping_t); > > +/* Source mapping space. */ > +/* ` enum phys_map_space { */ > +#define XENMAPSPACE_shared_info 0 /* shared info page */ > +#define XENMAPSPACE_grant_table 1 /* grant table page */ > +#define XENMAPSPACE_gmfn 2 /* GMFN */ > +#define XENMAPSPACE_gmfn_range 3 /* GMFN range */ > +#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another dom */ > +/* ` } */ > + > /* > * Sets the GPFN at which a particular page appears in the specified guest's > * pseudophysical address space. > @@ -215,25 +224,39 @@ struct xen_add_to_physmap { > domid_t foreign_domid; > } u; > > - /* Source mapping space. */ > -#define XENMAPSPACE_shared_info 0 /* shared info page */ > -#define XENMAPSPACE_grant_table 1 /* grant table page */ > -#define XENMAPSPACE_gmfn 2 /* GMFN */ > -#define XENMAPSPACE_gmfn_range 3 /* GMFN range */ > -#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */ > - unsigned int space; > + unsigned int space; /* => enum phys_map_space */ > > #define XENMAPIDX_grant_table_status 0x80000000 > > - /* Index into source mapping space. */ > + /* Index into space being mapped. */ > xen_ulong_t idx; > > - /* GPFN where the source mapping page should appear. */ > + /* GPFN in domid where the source mapping page should appear. */ > xen_pfn_t gpfn; > }; > typedef struct xen_add_to_physmap xen_add_to_physmap_t; > DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_t); > > +/* A batched version of add_to_physmap. */ > +#define XENMEM_add_to_physmap_range 23 > +struct xen_add_to_physmap_range { > + /* Which domain to change the mapping for. */ > + domid_t domid; > + uint16_t space; /* => enum phys_map_space */ > + > + /* Number of pages to go through */ > + uint16_t size; > + domid_t foreign_domid; /* IFF gmfn_foreign */ > + > + /* Indexes into space being mapped. */ > + XEN_GUEST_HANDLE(xen_ulong_t) idxs; > + > + /* GPFN in domdwhere the source mapping page should appear. */ > + XEN_GUEST_HANDLE(xen_pfn_t) gpfns; > +}; > +typedef struct xen_add_to_physmap_range xen_add_to_physmap_range_t; > +DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_range_t); > + > /* > * Unmaps the page appearing at a particular GPFN from the specified guest's > * pseudophysical address space. > diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h > index b2f6c50..9425520 100644 > --- a/xen/include/public/xen.h > +++ b/xen/include/public/xen.h > @@ -51,6 +51,7 @@ DEFINE_XEN_GUEST_HANDLE(void); > > DEFINE_XEN_GUEST_HANDLE(uint64_t); > DEFINE_XEN_GUEST_HANDLE(xen_pfn_t); > +DEFINE_XEN_GUEST_HANDLE(xen_ulong_t); > #endif > > /* > -- > 1.7.9.1 > > > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 11:41:31 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 11:41:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6HL-0007FH-HY; Fri, 05 Oct 2012 11:41:15 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6HJ-0007FC-Pr for xen-devel@lists.xen.org; Fri, 05 Oct 2012 11:41:14 +0000 Received: from [85.158.138.51:59337] by server-11.bemta-3.messagelabs.com id 3A/C0-21460-857CE605; Fri, 05 Oct 2012 11:41:12 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1349437270!32721157!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11584 invoked from network); 5 Oct 2012 11:41:10 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 11:41:10 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14961221" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 11:40:54 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 12:40:54 +0100 Message-ID: <1349437253.20946.70.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Jan Beulich Date: Fri, 5 Oct 2012 12:40:53 +0100 In-Reply-To: <506EE190020000780009FEFB@nat28.tlf.novell.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> <1349433507-21148-21-git-send-email-ian.campbell@citrix.com> <506EDC11020000780009FE93@nat28.tlf.novell.com> <1349435697.20946.57.camel@zakaz.uk.xensource.com> <506EE190020000780009FEFB@nat28.tlf.novell.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Tim \(Xen.org\)" , "xen-devel@lists.xen.org" , "Keir \(Xen.org\)" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH 21/21] xen: more substitutions X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-10-05 at 12:33 +0100, Jan Beulich wrote: > >>> On 05.10.12 at 13:14, Ian Campbell wrote: > > On Fri, 2012-10-05 at 12:09 +0100, Jan Beulich wrote: > >> >>> On 05.10.12 at 12:38, Ian Campbell wrote: > >> > @@ -4195,6 +4197,7 @@ static int handle_iomem_range(unsigned long s, > > unsigned long e, void *p) > >> > if ( s > ctxt->s ) > >> > { > >> > e820entry_t ent; > >> > + XEN_GUEST_HANDLE_PARAM(e820entry_t) buffer_t; > >> > >> I'm not really in favor fo the _t suffix chosen here and below, as > >> that's generally used for typedef-s. Could this be replaced with > >> e.g. _p, _h, or _hp? > > > > The use is > > buffer_t = guest_handle_cast(ctxt->map.buffer, e820entry_t); > > buffer = guest_handle_from_param(buffer_t, e820entry_t); > > which seems a bit strange to me -- we launder through buffer_t solely to > > use guest_handle_from_param. Is there no macro which does that in one > > step? > > > > That would avoid the whole problem of the suffix choice. > > > > Also buffer is then passed to __copy_to_guest_offset, and I'm not sure > > why that can't be passed ctxt->map.buffer directly rather than > > laundering it through those two macros... > > Passing directly is not possible, as the type referred to be the > handle is relevant for the macro's operation (and it's "void" in > struct xen_memory_map). That's the bit I missed. Although the question is then why not type the buffer correctly... Ian/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 11:41:31 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 11:41:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6HL-0007FH-HY; Fri, 05 Oct 2012 11:41:15 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6HJ-0007FC-Pr for xen-devel@lists.xen.org; Fri, 05 Oct 2012 11:41:14 +0000 Received: from [85.158.138.51:59337] by server-11.bemta-3.messagelabs.com id 3A/C0-21460-857CE605; Fri, 05 Oct 2012 11:41:12 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1349437270!32721157!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11584 invoked from network); 5 Oct 2012 11:41:10 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 11:41:10 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14961221" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 11:40:54 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 12:40:54 +0100 Message-ID: <1349437253.20946.70.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Jan Beulich Date: Fri, 5 Oct 2012 12:40:53 +0100 In-Reply-To: <506EE190020000780009FEFB@nat28.tlf.novell.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> <1349433507-21148-21-git-send-email-ian.campbell@citrix.com> <506EDC11020000780009FE93@nat28.tlf.novell.com> <1349435697.20946.57.camel@zakaz.uk.xensource.com> <506EE190020000780009FEFB@nat28.tlf.novell.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Tim \(Xen.org\)" , "xen-devel@lists.xen.org" , "Keir \(Xen.org\)" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH 21/21] xen: more substitutions X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-10-05 at 12:33 +0100, Jan Beulich wrote: > >>> On 05.10.12 at 13:14, Ian Campbell wrote: > > On Fri, 2012-10-05 at 12:09 +0100, Jan Beulich wrote: > >> >>> On 05.10.12 at 12:38, Ian Campbell wrote: > >> > @@ -4195,6 +4197,7 @@ static int handle_iomem_range(unsigned long s, > > unsigned long e, void *p) > >> > if ( s > ctxt->s ) > >> > { > >> > e820entry_t ent; > >> > + XEN_GUEST_HANDLE_PARAM(e820entry_t) buffer_t; > >> > >> I'm not really in favor fo the _t suffix chosen here and below, as > >> that's generally used for typedef-s. Could this be replaced with > >> e.g. _p, _h, or _hp? > > > > The use is > > buffer_t = guest_handle_cast(ctxt->map.buffer, e820entry_t); > > buffer = guest_handle_from_param(buffer_t, e820entry_t); > > which seems a bit strange to me -- we launder through buffer_t solely to > > use guest_handle_from_param. Is there no macro which does that in one > > step? > > > > That would avoid the whole problem of the suffix choice. > > > > Also buffer is then passed to __copy_to_guest_offset, and I'm not sure > > why that can't be passed ctxt->map.buffer directly rather than > > laundering it through those two macros... > > Passing directly is not possible, as the type referred to be the > handle is relevant for the macro's operation (and it's "void" in > struct xen_memory_map). That's the bit I missed. Although the question is then why not type the buffer correctly... Ian/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 11:42:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 11:42:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6IU-0007JY-W2; Fri, 05 Oct 2012 11:42:26 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6IU-0007JO-8y for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 11:42:26 +0000 Received: from [85.158.143.35:48943] by server-1.bemta-4.messagelabs.com id FA/0E-05684-1A7CE605; Fri, 05 Oct 2012 11:42:25 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1349437343!21170458!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ1ODc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28680 invoked from network); 5 Oct 2012 11:42:25 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 11:42:25 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="40252901" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 11:42:23 +0000 Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 07:42:22 -0400 Message-ID: <506EC79D.5080206@citrix.com> Date: Fri, 5 Oct 2012 12:42:21 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120428 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk References: <1348243464-15903-1-git-send-email-david.vrabel@citrix.com> <1348243464-15903-3-git-send-email-david.vrabel@citrix.com> <5061EFB2.1080407@citrix.com> <5069D097.60606@citrix.com> <20121002200255.GA668@phenom.dumpdata.com> In-Reply-To: <20121002200255.GA668@phenom.dumpdata.com> Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , Jan Beulich Subject: Re: [Xen-devel] [PATCH 2/6] xen-blkfront: handle backend CLOSED without CLOSING X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 02/10/12 21:02, Konrad Rzeszutek Wilk wrote: > On Mon, Oct 01, 2012 at 06:19:19PM +0100, David Vrabel wrote: >> On 25/09/12 18:53, David Vrabel wrote: >>> On 21/09/12 17:04, David Vrabel wrote: >>>> From: David Vrabel >>>> >>>> Backend drivers shouldn't transistion to CLOSED unless the frontend is >>>> CLOSED. If a backend does transition to CLOSED too soon then the >>>> frontend may not see the CLOSING state and will not properly shutdown. >>>> >>>> So, treat an unexpected backend CLOSED state the same as CLOSING. >>> >>> Didn't handle the frontend block device being mounted. Updated patch here. >> >> Konrad, can you ack this updated patch if you're happy with it. > > Acked-by: Konrad Rzeszutek Wilk > > Or should I just carry it in my for-jens-3.7 bug-fixes queue and ask > Jen to pull it once rc0 is out? This seems easiest, if Jan is happy with the patch. Thanks. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 11:42:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 11:42:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6IU-0007JY-W2; Fri, 05 Oct 2012 11:42:26 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6IU-0007JO-8y for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 11:42:26 +0000 Received: from [85.158.143.35:48943] by server-1.bemta-4.messagelabs.com id FA/0E-05684-1A7CE605; Fri, 05 Oct 2012 11:42:25 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-6.tower-21.messagelabs.com!1349437343!21170458!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ1ODc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28680 invoked from network); 5 Oct 2012 11:42:25 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 11:42:25 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="40252901" Received: from ftlpmailmx01.citrite.net ([10.13.107.65]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 11:42:23 +0000 Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net (10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 07:42:22 -0400 Message-ID: <506EC79D.5080206@citrix.com> Date: Fri, 5 Oct 2012 12:42:21 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120428 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk References: <1348243464-15903-1-git-send-email-david.vrabel@citrix.com> <1348243464-15903-3-git-send-email-david.vrabel@citrix.com> <5061EFB2.1080407@citrix.com> <5069D097.60606@citrix.com> <20121002200255.GA668@phenom.dumpdata.com> In-Reply-To: <20121002200255.GA668@phenom.dumpdata.com> Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , Jan Beulich Subject: Re: [Xen-devel] [PATCH 2/6] xen-blkfront: handle backend CLOSED without CLOSING X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 02/10/12 21:02, Konrad Rzeszutek Wilk wrote: > On Mon, Oct 01, 2012 at 06:19:19PM +0100, David Vrabel wrote: >> On 25/09/12 18:53, David Vrabel wrote: >>> On 21/09/12 17:04, David Vrabel wrote: >>>> From: David Vrabel >>>> >>>> Backend drivers shouldn't transistion to CLOSED unless the frontend is >>>> CLOSED. If a backend does transition to CLOSED too soon then the >>>> frontend may not see the CLOSING state and will not properly shutdown. >>>> >>>> So, treat an unexpected backend CLOSED state the same as CLOSING. >>> >>> Didn't handle the frontend block device being mounted. Updated patch here. >> >> Konrad, can you ack this updated patch if you're happy with it. > > Acked-by: Konrad Rzeszutek Wilk > > Or should I just carry it in my for-jens-3.7 bug-fixes queue and ask > Jen to pull it once rc0 is out? This seems easiest, if Jan is happy with the patch. Thanks. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 11:43:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 11:43:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6Jb-0007P8-Eg; Fri, 05 Oct 2012 11:43:35 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6JZ-0007P0-Je for xen-devel@lists.xen.org; Fri, 05 Oct 2012 11:43:33 +0000 Received: from [85.158.143.99:18302] by server-3.bemta-4.messagelabs.com id BE/E0-10986-4E7CE605; Fri, 05 Oct 2012 11:43:32 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1349437409!26740044!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28247 invoked from network); 5 Oct 2012 11:43:29 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-13.tower-216.messagelabs.com with SMTP; 5 Oct 2012 11:43:29 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 05 Oct 2012 12:43:29 +0100 Message-Id: <506EE3FF020000780009FF1B@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 05 Oct 2012 12:43:27 +0100 From: "Jan Beulich" To: "Ian Campbell" References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> <1349433507-21148-20-git-send-email-ian.campbell@citrix.com> <1349436628.20946.63.camel@zakaz.uk.xensource.com> In-Reply-To: <1349436628.20946.63.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Disposition: inline Cc: "Tim \(Xen.org\)" , "xen-devel@lists.xen.org" , "Keir \(Xen.org\)" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH 20/21] xen: replace XEN_GUEST_HANDLE with XEN_GUEST_HANDLE_PARAM when appropriate X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 05.10.12 at 13:30, Ian Campbell wrote: > This probably ought to be folded into the original patch rather than > kept separate. Think so, yes. > --- a/xen/include/public/tmem.h > +++ b/xen/include/public/tmem.h > @@ -96,7 +96,8 @@ > > #ifndef __ASSEMBLY__ > typedef xen_pfn_t tmem_cli_mfn_t; > -typedef XEN_GUEST_HANDLE_PARAM(char) tmem_cli_va_t; > +typedef XEN_GUEST_HANDLE(char) tmem_cli_va_t; > +typedef XEN_GUEST_HANDLE_PARAM(char) tmem_cli_va_param_t; This doesn't belong here - there's no use of tmem_cli_va_param_t anywhere in the public interface afaict. I didn't check, but if there are other uses of XEN_GUEST_HANDLE_PARAM() in the public headers, I would suspect them to be wrong too - at the interface layer, there shouldn't be any need for them. > --- a/xen/include/xen/compat.h > +++ b/xen/include/xen/compat.h > @@ -21,7 +21,9 @@ > __DEFINE_COMPAT_HANDLE(name, name); \ > __DEFINE_COMPAT_HANDLE(const_ ## name, const name) > #define COMPAT_HANDLE(name) __compat_handle_ ## name > - > +/* NB: it is assumed that if an arch uses the compat layer it does not > + * distinguish handles from parameter handles. */ > +#define COMPAT_HANDLE_PARAM(name) __compat_handle_ ## name > /* Is the compat handle a NULL reference? */ > #define compat_handle_is_null(hnd) ((hnd).c == 0) This seems acceptable to me (minus the dropped newline). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 11:43:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 11:43:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6Jb-0007P8-Eg; Fri, 05 Oct 2012 11:43:35 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6JZ-0007P0-Je for xen-devel@lists.xen.org; Fri, 05 Oct 2012 11:43:33 +0000 Received: from [85.158.143.99:18302] by server-3.bemta-4.messagelabs.com id BE/E0-10986-4E7CE605; Fri, 05 Oct 2012 11:43:32 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1349437409!26740044!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28247 invoked from network); 5 Oct 2012 11:43:29 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-13.tower-216.messagelabs.com with SMTP; 5 Oct 2012 11:43:29 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 05 Oct 2012 12:43:29 +0100 Message-Id: <506EE3FF020000780009FF1B@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 05 Oct 2012 12:43:27 +0100 From: "Jan Beulich" To: "Ian Campbell" References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> <1349433507-21148-20-git-send-email-ian.campbell@citrix.com> <1349436628.20946.63.camel@zakaz.uk.xensource.com> In-Reply-To: <1349436628.20946.63.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Disposition: inline Cc: "Tim \(Xen.org\)" , "xen-devel@lists.xen.org" , "Keir \(Xen.org\)" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH 20/21] xen: replace XEN_GUEST_HANDLE with XEN_GUEST_HANDLE_PARAM when appropriate X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 05.10.12 at 13:30, Ian Campbell wrote: > This probably ought to be folded into the original patch rather than > kept separate. Think so, yes. > --- a/xen/include/public/tmem.h > +++ b/xen/include/public/tmem.h > @@ -96,7 +96,8 @@ > > #ifndef __ASSEMBLY__ > typedef xen_pfn_t tmem_cli_mfn_t; > -typedef XEN_GUEST_HANDLE_PARAM(char) tmem_cli_va_t; > +typedef XEN_GUEST_HANDLE(char) tmem_cli_va_t; > +typedef XEN_GUEST_HANDLE_PARAM(char) tmem_cli_va_param_t; This doesn't belong here - there's no use of tmem_cli_va_param_t anywhere in the public interface afaict. I didn't check, but if there are other uses of XEN_GUEST_HANDLE_PARAM() in the public headers, I would suspect them to be wrong too - at the interface layer, there shouldn't be any need for them. > --- a/xen/include/xen/compat.h > +++ b/xen/include/xen/compat.h > @@ -21,7 +21,9 @@ > __DEFINE_COMPAT_HANDLE(name, name); \ > __DEFINE_COMPAT_HANDLE(const_ ## name, const name) > #define COMPAT_HANDLE(name) __compat_handle_ ## name > - > +/* NB: it is assumed that if an arch uses the compat layer it does not > + * distinguish handles from parameter handles. */ > +#define COMPAT_HANDLE_PARAM(name) __compat_handle_ ## name > /* Is the compat handle a NULL reference? */ > #define compat_handle_is_null(hnd) ((hnd).c == 0) This seems acceptable to me (minus the dropped newline). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 11:44:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 11:44:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6KG-0007UG-Sr; Fri, 05 Oct 2012 11:44:16 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6KF-0007TD-Da for xen-devel@lists.xen.org; Fri, 05 Oct 2012 11:44:15 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1349437449!3784938!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7798 invoked from network); 5 Oct 2012 11:44:09 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 11:44:09 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14961323" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 11:44:09 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 12:44:09 +0100 Date: Fri, 5 Oct 2012 12:43:07 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Ian Campbell In-Reply-To: <1349363515-26190-3-git-send-email-ian.campbell@citrix.com> Message-ID: References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-3-git-send-email-ian.campbell@citrix.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: Stefano Stabellini , "xen-devel@lists.xen.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 03/14] xen events: xen_callback_vector is x86 specific X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 4 Oct 2012, Ian Campbell wrote: > Signed-off-by: Ian Campbell > --- > Should instead move somewhere arch specific? This shouldn't be needed: it should be already protected by CONFIG_XEN_PVHVM (that is x86 specific). > drivers/xen/events.c | 4 ++++ > 1 files changed, 4 insertions(+), 0 deletions(-) > > diff --git a/drivers/xen/events.c b/drivers/xen/events.c > index 6f55ef2..2508981 100644 > --- a/drivers/xen/events.c > +++ b/drivers/xen/events.c > @@ -1775,6 +1775,7 @@ int xen_set_callback_via(uint64_t via) > EXPORT_SYMBOL_GPL(xen_set_callback_via); > > > +#ifdef CONFIG_X86 > /* Vector callbacks are better than PCI interrupts to receive event > * channel notifications because we can receive vector callbacks on any > * vcpu and we don't need PCI support or APIC interactions. */ > @@ -1798,6 +1799,9 @@ void xen_callback_vector(void) > alloc_intr_gate(XEN_HVM_EVTCHN_CALLBACK, xen_hvm_callback_vector); > } > } > +#else > +void xen_callback_vector(void) {} > +#endif > > void xen_init_IRQ(void) > { > -- > 1.7.2.5 > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 11:44:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 11:44:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6KG-0007UG-Sr; Fri, 05 Oct 2012 11:44:16 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6KF-0007TD-Da for xen-devel@lists.xen.org; Fri, 05 Oct 2012 11:44:15 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1349437449!3784938!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7798 invoked from network); 5 Oct 2012 11:44:09 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 11:44:09 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14961323" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 11:44:09 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 12:44:09 +0100 Date: Fri, 5 Oct 2012 12:43:07 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Ian Campbell In-Reply-To: <1349363515-26190-3-git-send-email-ian.campbell@citrix.com> Message-ID: References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-3-git-send-email-ian.campbell@citrix.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: Stefano Stabellini , "xen-devel@lists.xen.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 03/14] xen events: xen_callback_vector is x86 specific X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 4 Oct 2012, Ian Campbell wrote: > Signed-off-by: Ian Campbell > --- > Should instead move somewhere arch specific? This shouldn't be needed: it should be already protected by CONFIG_XEN_PVHVM (that is x86 specific). > drivers/xen/events.c | 4 ++++ > 1 files changed, 4 insertions(+), 0 deletions(-) > > diff --git a/drivers/xen/events.c b/drivers/xen/events.c > index 6f55ef2..2508981 100644 > --- a/drivers/xen/events.c > +++ b/drivers/xen/events.c > @@ -1775,6 +1775,7 @@ int xen_set_callback_via(uint64_t via) > EXPORT_SYMBOL_GPL(xen_set_callback_via); > > > +#ifdef CONFIG_X86 > /* Vector callbacks are better than PCI interrupts to receive event > * channel notifications because we can receive vector callbacks on any > * vcpu and we don't need PCI support or APIC interactions. */ > @@ -1798,6 +1799,9 @@ void xen_callback_vector(void) > alloc_intr_gate(XEN_HVM_EVTCHN_CALLBACK, xen_hvm_callback_vector); > } > } > +#else > +void xen_callback_vector(void) {} > +#endif > > void xen_init_IRQ(void) > { > -- > 1.7.2.5 > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 11:44:56 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 11:44:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6Kk-0007Zk-GL; Fri, 05 Oct 2012 11:44:46 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6Kj-0007ZQ-3i for xen-devel@lists.xen.org; Fri, 05 Oct 2012 11:44:45 +0000 Received: from [85.158.143.99:9127] by server-3.bemta-4.messagelabs.com id 53/92-10986-C28CE605; Fri, 05 Oct 2012 11:44:44 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1349437482!25988354!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODA1MjM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16587 invoked from network); 5 Oct 2012 11:44:43 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 11:44:43 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="210400664" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 11:44:40 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 07:44:39 -0400 Received: from elijah.uk.xensource.com ([10.80.2.24]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK6Kd-0004RI-DL; Fri, 05 Oct 2012 12:44:39 +0100 Message-ID: <506EC710.3020606@eu.citrix.com> Date: Fri, 5 Oct 2012 12:40:00 +0100 From: George Dunlap User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Dan Magenheimer References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> <20121002091017.GA95926@ocelot.phlegethon.org> <66cc0085-1216-40f7-8059-eaf615202c12@default> <20121002201624.GA98445@ocelot.phlegethon.org> <20121004100645.GC38243@ocelot.phlegethon.org> <1349345864.650.247.camel@zakaz.uk.xensource.com> <239799F4-AF29-494F-86D2-ADF45ACA8792@gridcentric.ca> <3e5cf0ba-4241-4f00-bef6-aaff2cc23419@default> In-Reply-To: <3e5cf0ba-4241-4f00-bef6-aaff2cc23419@default> Cc: Olaf Hering , "Keir \(Xen.org\)" , Ian Campbell , Konrad Wilk , Andres Lagar-Cavilla , "Tim \(Xen.org\)" , "xen-devel@lists.xen.org" , George Shuklin , Dario Faggioli , Kurt Hackel , Ian Jackson Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 04/10/12 17:54, Dan Magenheimer wrote: >> > Scanning through the archived message I am under the impression > that the focus is on a single server... i.e. "punt if actor is > not xl", i.e. it addressed "balloon-to-fit" and only tries to avoid > stepping on other memory overcommit technologies. That makes it > almost orthogonal, I think, to the problem I originally raised. No, the idea was to allow the flexibility of different actors in different situations. The plan was to start with a simple actor, but to add new ones as necessary. But on reflection, it seems like the whole "actor" thing was actually something completely separate to what we're talking about here. The idea behind the actor (IIRC) was that you could tell the toolstack, "Make VM A use X amount of host memory"; and the actor would determine the best way to do that -- either by only ballooning, or ballooning first and then swapping. But it doesn't decide how to get the value X. This thread has been very hard to follow for some reason, so let me see if I can understand everything: * You are concerned about being able to predictably start VMs in the face of: - concurrent requests, and - dynamic memory technologies (including PoD, ballooning, paging, page sharing, and tmem) Any of which may change the amount of free memory between the time a decision is made and the time memory is actually allocated. * You have proposed a hypervisor-based solution that allows the toolstack to "reserve" a specific amount of memory to a VM that will not be used for something else; this allocation is transactional -- it will either completely succeed, or completely fail, and do it quickly. Is that correct? The problem with that solution, it seems to me, is that the hypervisor does not (and I think probably should not) have any insight into the policy for allocating or freeing memory as a result of other activities, such as ballooning or page sharing. Suppose someone were ballooning down domain M to get 8GiB in order to start domain A; and at some point , another process looks and says, "Oh look, there's 4GiB free, that's enough to start domain B" and asks Xen to reserve that memory. Xen has no way of knowing that the memory freed by domain M was "earmarked" for domain A, and so will happily give it to domain B, causing domain A's creation to fail (potentially). So it seems like we need to have the idea of a memory controller -- one central process (per host, as you say) that would know about all of the knobs -- ballooning, paging, page sharing, tmem, whatever -- that could be in charge of knowing where all the memory was coming from and where it was going. So if xl wanted to start a new VM, it can ask the memory controller for 3GiB, and the controller could decide, "I'll take 1GiB from domain M and 2 from domain N, and give it to the new domain", and respond when it has the memory that it needs. Similarly, it can know that it should try to keep X megabytes for un-sharing of pages, and it can be responsible for freeing up more memory if that memory becomes exhausted. At the moment, the administrator himself (or the cloud orchestration layer) needs to be his own memory controller; that is, he needs to manually decide if there's enough free memory to start a VM; if there's not, he needs to figure out how to get that memory (either by ballooning or swapping). Ballooning and swapping are both totally under his control; the only thing he doesn't control is the unsharing of pages. But as long as there was a way to tell the page sharing daemon not to allocate an amount of free memory, then this "administrator-as-memory-controller" should work just fine. Does that make sense? Or am I still confused? :-) -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 11:44:56 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 11:44:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6Kk-0007Zk-GL; Fri, 05 Oct 2012 11:44:46 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6Kj-0007ZQ-3i for xen-devel@lists.xen.org; Fri, 05 Oct 2012 11:44:45 +0000 Received: from [85.158.143.99:9127] by server-3.bemta-4.messagelabs.com id 53/92-10986-C28CE605; Fri, 05 Oct 2012 11:44:44 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1349437482!25988354!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODA1MjM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16587 invoked from network); 5 Oct 2012 11:44:43 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 11:44:43 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="210400664" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 11:44:40 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 07:44:39 -0400 Received: from elijah.uk.xensource.com ([10.80.2.24]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK6Kd-0004RI-DL; Fri, 05 Oct 2012 12:44:39 +0100 Message-ID: <506EC710.3020606@eu.citrix.com> Date: Fri, 5 Oct 2012 12:40:00 +0100 From: George Dunlap User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Dan Magenheimer References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> <20121002091017.GA95926@ocelot.phlegethon.org> <66cc0085-1216-40f7-8059-eaf615202c12@default> <20121002201624.GA98445@ocelot.phlegethon.org> <20121004100645.GC38243@ocelot.phlegethon.org> <1349345864.650.247.camel@zakaz.uk.xensource.com> <239799F4-AF29-494F-86D2-ADF45ACA8792@gridcentric.ca> <3e5cf0ba-4241-4f00-bef6-aaff2cc23419@default> In-Reply-To: <3e5cf0ba-4241-4f00-bef6-aaff2cc23419@default> Cc: Olaf Hering , "Keir \(Xen.org\)" , Ian Campbell , Konrad Wilk , Andres Lagar-Cavilla , "Tim \(Xen.org\)" , "xen-devel@lists.xen.org" , George Shuklin , Dario Faggioli , Kurt Hackel , Ian Jackson Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 04/10/12 17:54, Dan Magenheimer wrote: >> > Scanning through the archived message I am under the impression > that the focus is on a single server... i.e. "punt if actor is > not xl", i.e. it addressed "balloon-to-fit" and only tries to avoid > stepping on other memory overcommit technologies. That makes it > almost orthogonal, I think, to the problem I originally raised. No, the idea was to allow the flexibility of different actors in different situations. The plan was to start with a simple actor, but to add new ones as necessary. But on reflection, it seems like the whole "actor" thing was actually something completely separate to what we're talking about here. The idea behind the actor (IIRC) was that you could tell the toolstack, "Make VM A use X amount of host memory"; and the actor would determine the best way to do that -- either by only ballooning, or ballooning first and then swapping. But it doesn't decide how to get the value X. This thread has been very hard to follow for some reason, so let me see if I can understand everything: * You are concerned about being able to predictably start VMs in the face of: - concurrent requests, and - dynamic memory technologies (including PoD, ballooning, paging, page sharing, and tmem) Any of which may change the amount of free memory between the time a decision is made and the time memory is actually allocated. * You have proposed a hypervisor-based solution that allows the toolstack to "reserve" a specific amount of memory to a VM that will not be used for something else; this allocation is transactional -- it will either completely succeed, or completely fail, and do it quickly. Is that correct? The problem with that solution, it seems to me, is that the hypervisor does not (and I think probably should not) have any insight into the policy for allocating or freeing memory as a result of other activities, such as ballooning or page sharing. Suppose someone were ballooning down domain M to get 8GiB in order to start domain A; and at some point , another process looks and says, "Oh look, there's 4GiB free, that's enough to start domain B" and asks Xen to reserve that memory. Xen has no way of knowing that the memory freed by domain M was "earmarked" for domain A, and so will happily give it to domain B, causing domain A's creation to fail (potentially). So it seems like we need to have the idea of a memory controller -- one central process (per host, as you say) that would know about all of the knobs -- ballooning, paging, page sharing, tmem, whatever -- that could be in charge of knowing where all the memory was coming from and where it was going. So if xl wanted to start a new VM, it can ask the memory controller for 3GiB, and the controller could decide, "I'll take 1GiB from domain M and 2 from domain N, and give it to the new domain", and respond when it has the memory that it needs. Similarly, it can know that it should try to keep X megabytes for un-sharing of pages, and it can be responsible for freeing up more memory if that memory becomes exhausted. At the moment, the administrator himself (or the cloud orchestration layer) needs to be his own memory controller; that is, he needs to manually decide if there's enough free memory to start a VM; if there's not, he needs to figure out how to get that memory (either by ballooning or swapping). Ballooning and swapping are both totally under his control; the only thing he doesn't control is the unsharing of pages. But as long as there was a way to tell the page sharing daemon not to allocate an amount of free memory, then this "administrator-as-memory-controller" should work just fine. Does that make sense? Or am I still confused? :-) -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 11:47:39 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 11:47:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6NN-0007uf-5r; Fri, 05 Oct 2012 11:47:29 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6NM-0007uT-0J for xen-devel@lists.xen.org; Fri, 05 Oct 2012 11:47:28 +0000 Received: from [85.158.137.99:57082] by server-2.bemta-3.messagelabs.com id 97/12-16514-FC8CE605; Fri, 05 Oct 2012 11:47:27 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-217.messagelabs.com!1349437646!15269990!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22802 invoked from network); 5 Oct 2012 11:47:26 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 11:47:26 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14961383" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 11:47:26 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 12:47:26 +0100 Message-ID: <1349437645.20946.74.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Fri, 5 Oct 2012 12:47:25 +0100 In-Reply-To: References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-3-git-send-email-ian.campbell@citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 03/14] xen events: xen_callback_vector is x86 specific X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-10-05 at 12:43 +0100, Stefano Stabellini wrote: > On Thu, 4 Oct 2012, Ian Campbell wrote: > > Signed-off-by: Ian Campbell > > --- > > Should instead move somewhere arch specific? > > This shouldn't be needed: it should be already protected by > CONFIG_XEN_PVHVM (that is x86 specific). Mukesh removed that ifdef because PVH also wants this function. Ian. > > > > drivers/xen/events.c | 4 ++++ > > 1 files changed, 4 insertions(+), 0 deletions(-) > > > > diff --git a/drivers/xen/events.c b/drivers/xen/events.c > > index 6f55ef2..2508981 100644 > > --- a/drivers/xen/events.c > > +++ b/drivers/xen/events.c > > @@ -1775,6 +1775,7 @@ int xen_set_callback_via(uint64_t via) > > EXPORT_SYMBOL_GPL(xen_set_callback_via); > > > > > > +#ifdef CONFIG_X86 > > /* Vector callbacks are better than PCI interrupts to receive event > > * channel notifications because we can receive vector callbacks on any > > * vcpu and we don't need PCI support or APIC interactions. */ > > @@ -1798,6 +1799,9 @@ void xen_callback_vector(void) > > alloc_intr_gate(XEN_HVM_EVTCHN_CALLBACK, xen_hvm_callback_vector); > > } > > } > > +#else > > +void xen_callback_vector(void) {} > > +#endif > > > > void xen_init_IRQ(void) > > { > > -- > > 1.7.2.5 > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 11:47:39 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 11:47:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6NN-0007uf-5r; Fri, 05 Oct 2012 11:47:29 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6NM-0007uT-0J for xen-devel@lists.xen.org; Fri, 05 Oct 2012 11:47:28 +0000 Received: from [85.158.137.99:57082] by server-2.bemta-3.messagelabs.com id 97/12-16514-FC8CE605; Fri, 05 Oct 2012 11:47:27 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-217.messagelabs.com!1349437646!15269990!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22802 invoked from network); 5 Oct 2012 11:47:26 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 11:47:26 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14961383" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 11:47:26 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 12:47:26 +0100 Message-ID: <1349437645.20946.74.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Fri, 5 Oct 2012 12:47:25 +0100 In-Reply-To: References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-3-git-send-email-ian.campbell@citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 03/14] xen events: xen_callback_vector is x86 specific X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-10-05 at 12:43 +0100, Stefano Stabellini wrote: > On Thu, 4 Oct 2012, Ian Campbell wrote: > > Signed-off-by: Ian Campbell > > --- > > Should instead move somewhere arch specific? > > This shouldn't be needed: it should be already protected by > CONFIG_XEN_PVHVM (that is x86 specific). Mukesh removed that ifdef because PVH also wants this function. Ian. > > > > drivers/xen/events.c | 4 ++++ > > 1 files changed, 4 insertions(+), 0 deletions(-) > > > > diff --git a/drivers/xen/events.c b/drivers/xen/events.c > > index 6f55ef2..2508981 100644 > > --- a/drivers/xen/events.c > > +++ b/drivers/xen/events.c > > @@ -1775,6 +1775,7 @@ int xen_set_callback_via(uint64_t via) > > EXPORT_SYMBOL_GPL(xen_set_callback_via); > > > > > > +#ifdef CONFIG_X86 > > /* Vector callbacks are better than PCI interrupts to receive event > > * channel notifications because we can receive vector callbacks on any > > * vcpu and we don't need PCI support or APIC interactions. */ > > @@ -1798,6 +1799,9 @@ void xen_callback_vector(void) > > alloc_intr_gate(XEN_HVM_EVTCHN_CALLBACK, xen_hvm_callback_vector); > > } > > } > > +#else > > +void xen_callback_vector(void) {} > > +#endif > > > > void xen_init_IRQ(void) > > { > > -- > > 1.7.2.5 > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 11:49:17 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 11:49:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6Ov-00082Y-L4; Fri, 05 Oct 2012 11:49:05 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6Ot-00082M-Q4 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 11:49:03 +0000 Received: from [85.158.143.99:44944] by server-1.bemta-4.messagelabs.com id 7D/96-05684-F29CE605; Fri, 05 Oct 2012 11:49:03 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1349437742!23382648!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11879 invoked from network); 5 Oct 2012 11:49:02 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 11:49:02 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14961422" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 11:49:01 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 12:49:01 +0100 Date: Fri, 5 Oct 2012 12:48:00 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Ian Campbell In-Reply-To: <1349363515-26190-5-git-send-email-ian.campbell@citrix.com> Message-ID: References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-5-git-send-email-ian.campbell@citrix.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: Stefano Stabellini , "xen-devel@lists.xen.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 05/14] xen: balloon: use correct type for frame_list X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 4 Oct 2012, Ian Campbell wrote: > This is now a xen_pfn_t. > > Signed-off-by: Ian Campbell > --- > drivers/xen/balloon.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c > index 85ef7e7..4625560 100644 > --- a/drivers/xen/balloon.c > +++ b/drivers/xen/balloon.c > @@ -87,7 +87,7 @@ struct balloon_stats balloon_stats; > EXPORT_SYMBOL_GPL(balloon_stats); > > /* We increase/decrease in batches which fit in a page */ > -static unsigned long frame_list[PAGE_SIZE / sizeof(unsigned long)]; > +static xen_pfn_t frame_list[PAGE_SIZE / sizeof(unsigned long)]; > > #ifdef CONFIG_HIGHMEM > #define inc_totalhigh_pages() (totalhigh_pages++) While I think is a good change, frame_list[i] is used as an argument to set_phys_to_machine, that takes an unsigned long. Also unsigned long are assigned to members of the array via page_to_pfn. I think that we should take care of these cases, either introducing explicit casts or changing the argument types. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 11:49:17 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 11:49:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6Ov-00082Y-L4; Fri, 05 Oct 2012 11:49:05 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6Ot-00082M-Q4 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 11:49:03 +0000 Received: from [85.158.143.99:44944] by server-1.bemta-4.messagelabs.com id 7D/96-05684-F29CE605; Fri, 05 Oct 2012 11:49:03 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1349437742!23382648!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11879 invoked from network); 5 Oct 2012 11:49:02 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 11:49:02 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14961422" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 11:49:01 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 12:49:01 +0100 Date: Fri, 5 Oct 2012 12:48:00 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Ian Campbell In-Reply-To: <1349363515-26190-5-git-send-email-ian.campbell@citrix.com> Message-ID: References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-5-git-send-email-ian.campbell@citrix.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: Stefano Stabellini , "xen-devel@lists.xen.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 05/14] xen: balloon: use correct type for frame_list X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 4 Oct 2012, Ian Campbell wrote: > This is now a xen_pfn_t. > > Signed-off-by: Ian Campbell > --- > drivers/xen/balloon.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c > index 85ef7e7..4625560 100644 > --- a/drivers/xen/balloon.c > +++ b/drivers/xen/balloon.c > @@ -87,7 +87,7 @@ struct balloon_stats balloon_stats; > EXPORT_SYMBOL_GPL(balloon_stats); > > /* We increase/decrease in batches which fit in a page */ > -static unsigned long frame_list[PAGE_SIZE / sizeof(unsigned long)]; > +static xen_pfn_t frame_list[PAGE_SIZE / sizeof(unsigned long)]; > > #ifdef CONFIG_HIGHMEM > #define inc_totalhigh_pages() (totalhigh_pages++) While I think is a good change, frame_list[i] is used as an argument to set_phys_to_machine, that takes an unsigned long. Also unsigned long are assigned to members of the array via page_to_pfn. I think that we should take care of these cases, either introducing explicit casts or changing the argument types. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 11:52:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 11:52:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6S3-0008GQ-S3; Fri, 05 Oct 2012 11:52:19 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6S2-0008GF-7P for xen-devel@lists.xen.org; Fri, 05 Oct 2012 11:52:18 +0000 Received: from [85.158.143.35:34204] by server-3.bemta-4.messagelabs.com id B5/5C-10986-1F9CE605; Fri, 05 Oct 2012 11:52:17 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1349437936!14037609!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12801 invoked from network); 5 Oct 2012 11:52:16 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-8.tower-21.messagelabs.com with SMTP; 5 Oct 2012 11:52:16 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 05 Oct 2012 12:52:16 +0100 Message-Id: <506EE610020000780009FF4B@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 05 Oct 2012 12:52:16 +0100 From: "Jan Beulich" To: "Ian Campbell" References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> <1349433507-21148-21-git-send-email-ian.campbell@citrix.com> <506EDC11020000780009FE93@nat28.tlf.novell.com> <1349435697.20946.57.camel@zakaz.uk.xensource.com> <506EE190020000780009FEFB@nat28.tlf.novell.com> <1349437253.20946.70.camel@zakaz.uk.xensource.com> In-Reply-To: <1349437253.20946.70.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Disposition: inline Cc: "Tim \(Xen.org\)" , xen-devel , "Keir \(Xen.org\)" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH 21/21] xen: more substitutions X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 05.10.12 at 13:40, Ian Campbell wrote: > On Fri, 2012-10-05 at 12:33 +0100, Jan Beulich wrote: >> >>> On 05.10.12 at 13:14, Ian Campbell wrote: >> > On Fri, 2012-10-05 at 12:09 +0100, Jan Beulich wrote: >> >> >>> On 05.10.12 at 12:38, Ian Campbell wrote: >> >> > @@ -4195,6 +4197,7 @@ static int handle_iomem_range(unsigned long s, >> > unsigned long e, void *p) >> >> > if ( s > ctxt->s ) >> >> > { >> >> > e820entry_t ent; >> >> > + XEN_GUEST_HANDLE_PARAM(e820entry_t) buffer_t; >> >> >> >> I'm not really in favor fo the _t suffix chosen here and below, as >> >> that's generally used for typedef-s. Could this be replaced with >> >> e.g. _p, _h, or _hp? >> > >> > The use is >> > buffer_t = guest_handle_cast(ctxt->map.buffer, e820entry_t); >> > buffer = guest_handle_from_param(buffer_t, e820entry_t); >> > which seems a bit strange to me -- we launder through buffer_t solely to >> > use guest_handle_from_param. Is there no macro which does that in one >> > step? >> > >> > That would avoid the whole problem of the suffix choice. >> > >> > Also buffer is then passed to __copy_to_guest_offset, and I'm not sure >> > why that can't be passed ctxt->map.buffer directly rather than >> > laundering it through those two macros... >> >> Passing directly is not possible, as the type referred to be the >> handle is relevant for the macro's operation (and it's "void" in >> struct xen_memory_map). > > That's the bit I missed. > > Although the question is then why not type the buffer correctly... Because the type itself isn't Xen-defined and hence also not exposed in Xen's public interface (which in particular allows guests to use their own type without any need of casting). Jan Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 11:52:32 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 11:52:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6S3-0008GQ-S3; Fri, 05 Oct 2012 11:52:19 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6S2-0008GF-7P for xen-devel@lists.xen.org; Fri, 05 Oct 2012 11:52:18 +0000 Received: from [85.158.143.35:34204] by server-3.bemta-4.messagelabs.com id B5/5C-10986-1F9CE605; Fri, 05 Oct 2012 11:52:17 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1349437936!14037609!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12801 invoked from network); 5 Oct 2012 11:52:16 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-8.tower-21.messagelabs.com with SMTP; 5 Oct 2012 11:52:16 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 05 Oct 2012 12:52:16 +0100 Message-Id: <506EE610020000780009FF4B@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 05 Oct 2012 12:52:16 +0100 From: "Jan Beulich" To: "Ian Campbell" References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> <1349433507-21148-21-git-send-email-ian.campbell@citrix.com> <506EDC11020000780009FE93@nat28.tlf.novell.com> <1349435697.20946.57.camel@zakaz.uk.xensource.com> <506EE190020000780009FEFB@nat28.tlf.novell.com> <1349437253.20946.70.camel@zakaz.uk.xensource.com> In-Reply-To: <1349437253.20946.70.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Disposition: inline Cc: "Tim \(Xen.org\)" , xen-devel , "Keir \(Xen.org\)" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH 21/21] xen: more substitutions X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 05.10.12 at 13:40, Ian Campbell wrote: > On Fri, 2012-10-05 at 12:33 +0100, Jan Beulich wrote: >> >>> On 05.10.12 at 13:14, Ian Campbell wrote: >> > On Fri, 2012-10-05 at 12:09 +0100, Jan Beulich wrote: >> >> >>> On 05.10.12 at 12:38, Ian Campbell wrote: >> >> > @@ -4195,6 +4197,7 @@ static int handle_iomem_range(unsigned long s, >> > unsigned long e, void *p) >> >> > if ( s > ctxt->s ) >> >> > { >> >> > e820entry_t ent; >> >> > + XEN_GUEST_HANDLE_PARAM(e820entry_t) buffer_t; >> >> >> >> I'm not really in favor fo the _t suffix chosen here and below, as >> >> that's generally used for typedef-s. Could this be replaced with >> >> e.g. _p, _h, or _hp? >> > >> > The use is >> > buffer_t = guest_handle_cast(ctxt->map.buffer, e820entry_t); >> > buffer = guest_handle_from_param(buffer_t, e820entry_t); >> > which seems a bit strange to me -- we launder through buffer_t solely to >> > use guest_handle_from_param. Is there no macro which does that in one >> > step? >> > >> > That would avoid the whole problem of the suffix choice. >> > >> > Also buffer is then passed to __copy_to_guest_offset, and I'm not sure >> > why that can't be passed ctxt->map.buffer directly rather than >> > laundering it through those two macros... >> >> Passing directly is not possible, as the type referred to be the >> handle is relevant for the macro's operation (and it's "void" in >> struct xen_memory_map). > > That's the bit I missed. > > Although the question is then why not type the buffer correctly... Because the type itself isn't Xen-defined and hence also not exposed in Xen's public interface (which in particular allows guests to use their own type without any need of casting). Jan Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 11:54:37 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 11:54:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6U5-0008VW-Cm; Fri, 05 Oct 2012 11:54:25 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6U3-0008VA-EN for xen-devel@lists.xen.org; Fri, 05 Oct 2012 11:54:23 +0000 Received: from [85.158.139.83:20406] by server-6.bemta-5.messagelabs.com id 00/E5-14717-E6ACE605; Fri, 05 Oct 2012 11:54:22 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1349438062!32900264!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27639 invoked from network); 5 Oct 2012 11:54:22 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 11:54:22 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14961557" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 11:54:22 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 12:54:21 +0100 Date: Fri, 5 Oct 2012 12:53:20 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Ian Campbell In-Reply-To: <1349363515-26190-6-git-send-email-ian.campbell@citrix.com> Message-ID: References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-6-git-send-email-ian.campbell@citrix.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: Stefano Stabellini , "xen-devel@lists.xen.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 06/14] arm: make p2m operations NOPs X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 4 Oct 2012, Ian Campbell wrote: > This makes common code less ifdef-y and is consistent with PVHVM on > x86. > > Also note that phys_to_machine_mapping_valid should take a pfn > argument and make it do so. > > Add __set_phys_to_machine, make set_phys_to_machine a simple wrapper > (on systems with non-nop implementations the outer one can allocate > new p2m pages). > > Make __set_phys_to_machine check for identity mapping or invalid only. > > Signed-off-by: Ian Campbell Acked-by: Stefano Stabellini > arch/arm/include/asm/xen/page.h | 13 ++++++++++--- > drivers/xen/balloon.c | 2 +- > 2 files changed, 11 insertions(+), 4 deletions(-) > > diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h > index 1742023..c6b9096 100644 > --- a/arch/arm/include/asm/xen/page.h > +++ b/arch/arm/include/asm/xen/page.h > @@ -10,7 +10,7 @@ > #include > > #define pfn_to_mfn(pfn) (pfn) > -#define phys_to_machine_mapping_valid (1) > +#define phys_to_machine_mapping_valid(pfn) (1) > #define mfn_to_pfn(mfn) (mfn) > #define mfn_to_virt(m) (__va(mfn_to_pfn(m) << PAGE_SHIFT)) > > @@ -30,6 +30,8 @@ typedef struct xpaddr { > #define XMADDR(x) ((xmaddr_t) { .maddr = (x) }) > #define XPADDR(x) ((xpaddr_t) { .paddr = (x) }) > > +#define INVALID_P2M_ENTRY (~0UL) > + > static inline xmaddr_t phys_to_machine(xpaddr_t phys) > { > unsigned offset = phys.paddr & ~PAGE_MASK; > @@ -74,9 +76,14 @@ static inline int m2p_remove_override(struct page *page, bool clear_pte) > return 0; > } > > +static inline bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn) > +{ > + BUG_ON(pfn != mfn && mfn != INVALID_P2M_ENTRY); > + return true; > +} > + > static inline bool set_phys_to_machine(unsigned long pfn, unsigned long mfn) > { > - BUG(); > - return false; > + return __set_phys_to_machine(pfn, mfn); > } > #endif /* _ASM_ARM_XEN_PAGE_H */ > diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c > index 4625560..7885a19 100644 > --- a/drivers/xen/balloon.c > +++ b/drivers/xen/balloon.c > @@ -452,7 +452,7 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp) > /* No more mappings: invalidate P2M and add to balloon. */ > for (i = 0; i < nr_pages; i++) { > pfn = mfn_to_pfn(frame_list[i]); > - /* PVH note: following will noop for auto translated */ > + /* The following is a noop for auto translated */ > __set_phys_to_machine(pfn, INVALID_P2M_ENTRY); > balloon_append(pfn_to_page(pfn)); > } > -- > 1.7.2.5 > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 11:54:37 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 11:54:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6U5-0008VW-Cm; Fri, 05 Oct 2012 11:54:25 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6U3-0008VA-EN for xen-devel@lists.xen.org; Fri, 05 Oct 2012 11:54:23 +0000 Received: from [85.158.139.83:20406] by server-6.bemta-5.messagelabs.com id 00/E5-14717-E6ACE605; Fri, 05 Oct 2012 11:54:22 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1349438062!32900264!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27639 invoked from network); 5 Oct 2012 11:54:22 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 11:54:22 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14961557" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 11:54:22 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 12:54:21 +0100 Date: Fri, 5 Oct 2012 12:53:20 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Ian Campbell In-Reply-To: <1349363515-26190-6-git-send-email-ian.campbell@citrix.com> Message-ID: References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-6-git-send-email-ian.campbell@citrix.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: Stefano Stabellini , "xen-devel@lists.xen.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 06/14] arm: make p2m operations NOPs X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 4 Oct 2012, Ian Campbell wrote: > This makes common code less ifdef-y and is consistent with PVHVM on > x86. > > Also note that phys_to_machine_mapping_valid should take a pfn > argument and make it do so. > > Add __set_phys_to_machine, make set_phys_to_machine a simple wrapper > (on systems with non-nop implementations the outer one can allocate > new p2m pages). > > Make __set_phys_to_machine check for identity mapping or invalid only. > > Signed-off-by: Ian Campbell Acked-by: Stefano Stabellini > arch/arm/include/asm/xen/page.h | 13 ++++++++++--- > drivers/xen/balloon.c | 2 +- > 2 files changed, 11 insertions(+), 4 deletions(-) > > diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h > index 1742023..c6b9096 100644 > --- a/arch/arm/include/asm/xen/page.h > +++ b/arch/arm/include/asm/xen/page.h > @@ -10,7 +10,7 @@ > #include > > #define pfn_to_mfn(pfn) (pfn) > -#define phys_to_machine_mapping_valid (1) > +#define phys_to_machine_mapping_valid(pfn) (1) > #define mfn_to_pfn(mfn) (mfn) > #define mfn_to_virt(m) (__va(mfn_to_pfn(m) << PAGE_SHIFT)) > > @@ -30,6 +30,8 @@ typedef struct xpaddr { > #define XMADDR(x) ((xmaddr_t) { .maddr = (x) }) > #define XPADDR(x) ((xpaddr_t) { .paddr = (x) }) > > +#define INVALID_P2M_ENTRY (~0UL) > + > static inline xmaddr_t phys_to_machine(xpaddr_t phys) > { > unsigned offset = phys.paddr & ~PAGE_MASK; > @@ -74,9 +76,14 @@ static inline int m2p_remove_override(struct page *page, bool clear_pte) > return 0; > } > > +static inline bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn) > +{ > + BUG_ON(pfn != mfn && mfn != INVALID_P2M_ENTRY); > + return true; > +} > + > static inline bool set_phys_to_machine(unsigned long pfn, unsigned long mfn) > { > - BUG(); > - return false; > + return __set_phys_to_machine(pfn, mfn); > } > #endif /* _ASM_ARM_XEN_PAGE_H */ > diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c > index 4625560..7885a19 100644 > --- a/drivers/xen/balloon.c > +++ b/drivers/xen/balloon.c > @@ -452,7 +452,7 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp) > /* No more mappings: invalidate P2M and add to balloon. */ > for (i = 0; i < nr_pages; i++) { > pfn = mfn_to_pfn(frame_list[i]); > - /* PVH note: following will noop for auto translated */ > + /* The following is a noop for auto translated */ > __set_phys_to_machine(pfn, INVALID_P2M_ENTRY); > balloon_append(pfn_to_page(pfn)); > } > -- > 1.7.2.5 > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 11:55:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 11:55:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6V6-0000Cu-RZ; Fri, 05 Oct 2012 11:55:28 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6V6-0000Cj-5L for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 11:55:28 +0000 Received: from [85.158.139.211:33989] by server-1.bemta-5.messagelabs.com id 05/78-09825-FAACE605; Fri, 05 Oct 2012 11:55:27 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-9.tower-206.messagelabs.com!1349438126!19694438!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6528 invoked from network); 5 Oct 2012 11:55:26 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-9.tower-206.messagelabs.com with SMTP; 5 Oct 2012 11:55:26 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 05 Oct 2012 12:55:25 +0100 Message-Id: <506EE6CD020000780009FF4E@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 05 Oct 2012 12:55:25 +0100 From: "Jan Beulich" To: "David Vrabel" , "Konrad Rzeszutek Wilk" References: <1348243464-15903-1-git-send-email-david.vrabel@citrix.com> <1348243464-15903-3-git-send-email-david.vrabel@citrix.com> <5061EFB2.1080407@citrix.com> <5069D097.60606@citrix.com> <20121002200255.GA668@phenom.dumpdata.com> <506EC79D.5080206@citrix.com> In-Reply-To: <506EC79D.5080206@citrix.com> Mime-Version: 1.0 Content-Disposition: inline Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" Subject: Re: [Xen-devel] [PATCH 2/6] xen-blkfront: handle backend CLOSED without CLOSING X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 05.10.12 at 13:42, David Vrabel wrote: > On 02/10/12 21:02, Konrad Rzeszutek Wilk wrote: >> On Mon, Oct 01, 2012 at 06:19:19PM +0100, David Vrabel wrote: >>> On 25/09/12 18:53, David Vrabel wrote: >>>> On 21/09/12 17:04, David Vrabel wrote: >>>>> From: David Vrabel >>>>> >>>>> Backend drivers shouldn't transistion to CLOSED unless the frontend is >>>>> CLOSED. If a backend does transition to CLOSED too soon then the >>>>> frontend may not see the CLOSING state and will not properly shutdown. >>>>> >>>>> So, treat an unexpected backend CLOSED state the same as CLOSING. >>>> >>>> Didn't handle the frontend block device being mounted. Updated patch here. >>> >>> Konrad, can you ack this updated patch if you're happy with it. >> >> Acked-by: Konrad Rzeszutek Wilk >> >> Or should I just carry it in my for-jens-3.7 bug-fixes queue and ask >> Jen to pull it once rc0 is out? > > This seems easiest, if Jan is happy with the patch. I see the point of your explanation yesterday, but am still not convinced that the early cleanup in spite of active users of the disk can't cause any problems (like dangling pointers or NULL dereferences). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 11:55:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 11:55:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6V6-0000Cu-RZ; Fri, 05 Oct 2012 11:55:28 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6V6-0000Cj-5L for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 11:55:28 +0000 Received: from [85.158.139.211:33989] by server-1.bemta-5.messagelabs.com id 05/78-09825-FAACE605; Fri, 05 Oct 2012 11:55:27 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-9.tower-206.messagelabs.com!1349438126!19694438!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6528 invoked from network); 5 Oct 2012 11:55:26 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-9.tower-206.messagelabs.com with SMTP; 5 Oct 2012 11:55:26 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 05 Oct 2012 12:55:25 +0100 Message-Id: <506EE6CD020000780009FF4E@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 05 Oct 2012 12:55:25 +0100 From: "Jan Beulich" To: "David Vrabel" , "Konrad Rzeszutek Wilk" References: <1348243464-15903-1-git-send-email-david.vrabel@citrix.com> <1348243464-15903-3-git-send-email-david.vrabel@citrix.com> <5061EFB2.1080407@citrix.com> <5069D097.60606@citrix.com> <20121002200255.GA668@phenom.dumpdata.com> <506EC79D.5080206@citrix.com> In-Reply-To: <506EC79D.5080206@citrix.com> Mime-Version: 1.0 Content-Disposition: inline Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" Subject: Re: [Xen-devel] [PATCH 2/6] xen-blkfront: handle backend CLOSED without CLOSING X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 05.10.12 at 13:42, David Vrabel wrote: > On 02/10/12 21:02, Konrad Rzeszutek Wilk wrote: >> On Mon, Oct 01, 2012 at 06:19:19PM +0100, David Vrabel wrote: >>> On 25/09/12 18:53, David Vrabel wrote: >>>> On 21/09/12 17:04, David Vrabel wrote: >>>>> From: David Vrabel >>>>> >>>>> Backend drivers shouldn't transistion to CLOSED unless the frontend is >>>>> CLOSED. If a backend does transition to CLOSED too soon then the >>>>> frontend may not see the CLOSING state and will not properly shutdown. >>>>> >>>>> So, treat an unexpected backend CLOSED state the same as CLOSING. >>>> >>>> Didn't handle the frontend block device being mounted. Updated patch here. >>> >>> Konrad, can you ack this updated patch if you're happy with it. >> >> Acked-by: Konrad Rzeszutek Wilk >> >> Or should I just carry it in my for-jens-3.7 bug-fixes queue and ask >> Jen to pull it once rc0 is out? > > This seems easiest, if Jan is happy with the patch. I see the point of your explanation yesterday, but am still not convinced that the early cleanup in spite of active users of the disk can't cause any problems (like dangling pointers or NULL dereferences). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 12:06:06 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 12:06:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6fA-0000oI-C5; Fri, 05 Oct 2012 12:05:52 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6f8-0000nc-Ew for xen-devel@lists.xen.org; Fri, 05 Oct 2012 12:05:50 +0000 Received: from [85.158.143.99:50165] by server-3.bemta-4.messagelabs.com id 1E/50-10986-C1DCE605; Fri, 05 Oct 2012 12:05:48 +0000 X-Env-Sender: ben.guthro@gmail.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1349438745!24871191!1 X-Originating-IP: [209.85.223.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15308 invoked from network); 5 Oct 2012 12:05:47 -0000 Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com) (209.85.223.173) by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 12:05:47 -0000 Received: by mail-ie0-f173.google.com with SMTP id 17so4537869iea.32 for ; Fri, 05 Oct 2012 05:05:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=LxTcLS8YHz6dmNdExc2yn0Qpth0yOm9poSqCpVFSuHA=; b=o+GYdb5iMqtbPZuhoi7CryzLbTzyoiAKM37b+NAIwGEM/Lwl5ctqdSNjl0Sau7L1uG JDRJwh1aoD/NtyYXUbKwrLB5jFV3RsaAk3BL2gVSW2wydXLh4KAwi1qVMV8G7Pa+cT94 8KZ7Tca+C0M+JNfuwlh+2JH+l35YAbU+K0JHISOJC1ANR8Z2Ap9c/dW/Rpq8uMZ7Q6OZ OhAGfXtrIze7oWG0qgZF4zk7YKORgCxJ4lviY3uNSvzafwGjaMxvKk/zQzOd/a7iQpP6 Wn7Lw6P5M5d96YuJsP/wpjjpkZTXuMYsTI9yP2qwFh/fhAqN4Q1/PzYWIh4/68hsl9Hy ONCQ== MIME-Version: 1.0 Received: by 10.50.183.200 with SMTP id eo8mr889856igc.54.1349438744903; Fri, 05 Oct 2012 05:05:44 -0700 (PDT) Received: by 10.64.48.197 with HTTP; Fri, 5 Oct 2012 05:05:44 -0700 (PDT) Date: Fri, 5 Oct 2012 08:05:44 -0400 X-Google-Sender-Auth: 8yjSBPpat_d2tNabTQgTcihKjO0 Message-ID: From: Ben Guthro To: xen-devel Content-Type: multipart/mixed; boundary=14dae934043509417204cb4eb1be Subject: [Xen-devel] [PATCH] fix public header hvm/save.h to be compatible with c++ X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --14dae934043509417204cb4eb1be Content-Type: text/plain; charset=ISO-8859-1 Including save.h in a C++ application was throwing some errors, as it was unhappy about the "new" keyword being used (even when wrapped in an "extern C" block) This change renames some variables to keep the compiler happy, as well as casts the (void*) as appropriate. Signed-off-by: Ben Guthro diff --git a/xen/include/public/arch-x86/hvm/save.h b/xen/include/public/arch-x86/hvm/save.h index a82a5ee..20e5061 100644 --- a/xen/include/public/arch-x86/hvm/save.h +++ b/xen/include/public/arch-x86/hvm/save.h @@ -269,15 +269,15 @@ struct hvm_hw_cpu_compat { }; static inline int _hvm_hw_fix_cpu(void *h) { - struct hvm_hw_cpu *new=h; - struct hvm_hw_cpu_compat *old=h; + struct hvm_hw_cpu *new_cpu = (struct hvm_hw_cpu *)h; + struct hvm_hw_cpu_compat *old_cpu = (struct hvm_hw_cpu_compat *)h; /* If we copy from the end backwards, we should * be able to do the modification in-place */ - new->error_code=old->error_code; - new->pending_event=old->pending_event; - new->tsc=old->tsc; - new->msr_tsc_aux=0; + new_cpu->error_code=old_cpu->error_code; + new_cpu->pending_event=old_cpu->pending_event; + new_cpu->tsc=old_cpu->tsc; + new_cpu->msr_tsc_aux=0; return 0; } --14dae934043509417204cb4eb1be Content-Type: application/octet-stream; name="public_headers_cpp_fixes.patch" Content-Disposition: attachment; filename="public_headers_cpp_fixes.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h7x8twla0 ZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3B1YmxpYy9hcmNoLXg4Ni9odm0vc2F2ZS5oIGIveGVu L2luY2x1ZGUvcHVibGljL2FyY2gteDg2L2h2bS9zYXZlLmgKaW5kZXggYTgyYTVlZS4uMjBlNTA2 MSAxMDA2NDQKLS0tIGEveGVuL2luY2x1ZGUvcHVibGljL2FyY2gteDg2L2h2bS9zYXZlLmgKKysr IGIveGVuL2luY2x1ZGUvcHVibGljL2FyY2gteDg2L2h2bS9zYXZlLmgKQEAgLTI2OSwxNSArMjY5 LDE1IEBAIHN0cnVjdCBodm1faHdfY3B1X2NvbXBhdCB7CiB9OwogCiBzdGF0aWMgaW5saW5lIGlu dCBfaHZtX2h3X2ZpeF9jcHUodm9pZCAqaCkgewotICAgIHN0cnVjdCBodm1faHdfY3B1ICpuZXc9 aDsKLSAgICBzdHJ1Y3QgaHZtX2h3X2NwdV9jb21wYXQgKm9sZD1oOworICAgIHN0cnVjdCBodm1f aHdfY3B1ICpuZXdfY3B1ID0gKHN0cnVjdCBodm1faHdfY3B1ICopaDsKKyAgICBzdHJ1Y3QgaHZt X2h3X2NwdV9jb21wYXQgKm9sZF9jcHUgPSAoc3RydWN0IGh2bV9od19jcHVfY29tcGF0ICopaDsK IAogICAgIC8qIElmIHdlIGNvcHkgZnJvbSB0aGUgZW5kIGJhY2t3YXJkcywgd2Ugc2hvdWxkCiAg ICAgICogYmUgYWJsZSB0byBkbyB0aGUgbW9kaWZpY2F0aW9uIGluLXBsYWNlICovCi0gICAgbmV3 LT5lcnJvcl9jb2RlPW9sZC0+ZXJyb3JfY29kZTsKLSAgICBuZXctPnBlbmRpbmdfZXZlbnQ9b2xk LT5wZW5kaW5nX2V2ZW50OwotICAgIG5ldy0+dHNjPW9sZC0+dHNjOwotICAgIG5ldy0+bXNyX3Rz Y19hdXg9MDsKKyAgICBuZXdfY3B1LT5lcnJvcl9jb2RlPW9sZF9jcHUtPmVycm9yX2NvZGU7Cisg ICAgbmV3X2NwdS0+cGVuZGluZ19ldmVudD1vbGRfY3B1LT5wZW5kaW5nX2V2ZW50OworICAgIG5l d19jcHUtPnRzYz1vbGRfY3B1LT50c2M7CisgICAgbmV3X2NwdS0+bXNyX3RzY19hdXg9MDsKIAog ICAgIHJldHVybiAwOwogfQo= --14dae934043509417204cb4eb1be Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --14dae934043509417204cb4eb1be-- From xen-devel-bounces@lists.xen.org Fri Oct 05 12:06:06 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 12:06:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6fA-0000oI-C5; Fri, 05 Oct 2012 12:05:52 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6f8-0000nc-Ew for xen-devel@lists.xen.org; Fri, 05 Oct 2012 12:05:50 +0000 Received: from [85.158.143.99:50165] by server-3.bemta-4.messagelabs.com id 1E/50-10986-C1DCE605; Fri, 05 Oct 2012 12:05:48 +0000 X-Env-Sender: ben.guthro@gmail.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1349438745!24871191!1 X-Originating-IP: [209.85.223.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15308 invoked from network); 5 Oct 2012 12:05:47 -0000 Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com) (209.85.223.173) by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 12:05:47 -0000 Received: by mail-ie0-f173.google.com with SMTP id 17so4537869iea.32 for ; Fri, 05 Oct 2012 05:05:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=LxTcLS8YHz6dmNdExc2yn0Qpth0yOm9poSqCpVFSuHA=; b=o+GYdb5iMqtbPZuhoi7CryzLbTzyoiAKM37b+NAIwGEM/Lwl5ctqdSNjl0Sau7L1uG JDRJwh1aoD/NtyYXUbKwrLB5jFV3RsaAk3BL2gVSW2wydXLh4KAwi1qVMV8G7Pa+cT94 8KZ7Tca+C0M+JNfuwlh+2JH+l35YAbU+K0JHISOJC1ANR8Z2Ap9c/dW/Rpq8uMZ7Q6OZ OhAGfXtrIze7oWG0qgZF4zk7YKORgCxJ4lviY3uNSvzafwGjaMxvKk/zQzOd/a7iQpP6 Wn7Lw6P5M5d96YuJsP/wpjjpkZTXuMYsTI9yP2qwFh/fhAqN4Q1/PzYWIh4/68hsl9Hy ONCQ== MIME-Version: 1.0 Received: by 10.50.183.200 with SMTP id eo8mr889856igc.54.1349438744903; Fri, 05 Oct 2012 05:05:44 -0700 (PDT) Received: by 10.64.48.197 with HTTP; Fri, 5 Oct 2012 05:05:44 -0700 (PDT) Date: Fri, 5 Oct 2012 08:05:44 -0400 X-Google-Sender-Auth: 8yjSBPpat_d2tNabTQgTcihKjO0 Message-ID: From: Ben Guthro To: xen-devel Content-Type: multipart/mixed; boundary=14dae934043509417204cb4eb1be Subject: [Xen-devel] [PATCH] fix public header hvm/save.h to be compatible with c++ X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --14dae934043509417204cb4eb1be Content-Type: text/plain; charset=ISO-8859-1 Including save.h in a C++ application was throwing some errors, as it was unhappy about the "new" keyword being used (even when wrapped in an "extern C" block) This change renames some variables to keep the compiler happy, as well as casts the (void*) as appropriate. Signed-off-by: Ben Guthro diff --git a/xen/include/public/arch-x86/hvm/save.h b/xen/include/public/arch-x86/hvm/save.h index a82a5ee..20e5061 100644 --- a/xen/include/public/arch-x86/hvm/save.h +++ b/xen/include/public/arch-x86/hvm/save.h @@ -269,15 +269,15 @@ struct hvm_hw_cpu_compat { }; static inline int _hvm_hw_fix_cpu(void *h) { - struct hvm_hw_cpu *new=h; - struct hvm_hw_cpu_compat *old=h; + struct hvm_hw_cpu *new_cpu = (struct hvm_hw_cpu *)h; + struct hvm_hw_cpu_compat *old_cpu = (struct hvm_hw_cpu_compat *)h; /* If we copy from the end backwards, we should * be able to do the modification in-place */ - new->error_code=old->error_code; - new->pending_event=old->pending_event; - new->tsc=old->tsc; - new->msr_tsc_aux=0; + new_cpu->error_code=old_cpu->error_code; + new_cpu->pending_event=old_cpu->pending_event; + new_cpu->tsc=old_cpu->tsc; + new_cpu->msr_tsc_aux=0; return 0; } --14dae934043509417204cb4eb1be Content-Type: application/octet-stream; name="public_headers_cpp_fixes.patch" Content-Disposition: attachment; filename="public_headers_cpp_fixes.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h7x8twla0 ZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3B1YmxpYy9hcmNoLXg4Ni9odm0vc2F2ZS5oIGIveGVu L2luY2x1ZGUvcHVibGljL2FyY2gteDg2L2h2bS9zYXZlLmgKaW5kZXggYTgyYTVlZS4uMjBlNTA2 MSAxMDA2NDQKLS0tIGEveGVuL2luY2x1ZGUvcHVibGljL2FyY2gteDg2L2h2bS9zYXZlLmgKKysr IGIveGVuL2luY2x1ZGUvcHVibGljL2FyY2gteDg2L2h2bS9zYXZlLmgKQEAgLTI2OSwxNSArMjY5 LDE1IEBAIHN0cnVjdCBodm1faHdfY3B1X2NvbXBhdCB7CiB9OwogCiBzdGF0aWMgaW5saW5lIGlu dCBfaHZtX2h3X2ZpeF9jcHUodm9pZCAqaCkgewotICAgIHN0cnVjdCBodm1faHdfY3B1ICpuZXc9 aDsKLSAgICBzdHJ1Y3QgaHZtX2h3X2NwdV9jb21wYXQgKm9sZD1oOworICAgIHN0cnVjdCBodm1f aHdfY3B1ICpuZXdfY3B1ID0gKHN0cnVjdCBodm1faHdfY3B1ICopaDsKKyAgICBzdHJ1Y3QgaHZt X2h3X2NwdV9jb21wYXQgKm9sZF9jcHUgPSAoc3RydWN0IGh2bV9od19jcHVfY29tcGF0ICopaDsK IAogICAgIC8qIElmIHdlIGNvcHkgZnJvbSB0aGUgZW5kIGJhY2t3YXJkcywgd2Ugc2hvdWxkCiAg ICAgICogYmUgYWJsZSB0byBkbyB0aGUgbW9kaWZpY2F0aW9uIGluLXBsYWNlICovCi0gICAgbmV3 LT5lcnJvcl9jb2RlPW9sZC0+ZXJyb3JfY29kZTsKLSAgICBuZXctPnBlbmRpbmdfZXZlbnQ9b2xk LT5wZW5kaW5nX2V2ZW50OwotICAgIG5ldy0+dHNjPW9sZC0+dHNjOwotICAgIG5ldy0+bXNyX3Rz Y19hdXg9MDsKKyAgICBuZXdfY3B1LT5lcnJvcl9jb2RlPW9sZF9jcHUtPmVycm9yX2NvZGU7Cisg ICAgbmV3X2NwdS0+cGVuZGluZ19ldmVudD1vbGRfY3B1LT5wZW5kaW5nX2V2ZW50OworICAgIG5l d19jcHUtPnRzYz1vbGRfY3B1LT50c2M7CisgICAgbmV3X2NwdS0+bXNyX3RzY19hdXg9MDsKIAog ICAgIHJldHVybiAwOwogfQo= --14dae934043509417204cb4eb1be Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --14dae934043509417204cb4eb1be-- From xen-devel-bounces@lists.xen.org Fri Oct 05 12:06:59 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 12:06:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6g2-0000zy-H3; Fri, 05 Oct 2012 12:06:46 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6g1-0000zb-DC for xen-devel@lists.xen.org; Fri, 05 Oct 2012 12:06:45 +0000 Received: from [85.158.143.99:56560] by server-3.bemta-4.messagelabs.com id 29/81-10986-45DCE605; Fri, 05 Oct 2012 12:06:44 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1349438803!26878741!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30571 invoked from network); 5 Oct 2012 12:06:44 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 12:06:44 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14961886" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 12:06:03 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 13:06:03 +0100 Date: Fri, 5 Oct 2012 13:05:01 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Ian Campbell In-Reply-To: <1349363515-26190-7-git-send-email-ian.campbell@citrix.com> Message-ID: References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-7-git-send-email-ian.campbell@citrix.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: Stefano Stabellini , "xen-devel@lists.xen.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 07/14] xen: balloon: do not update stage 1 pagetable for autotranslated guests X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 4 Oct 2012, Ian Campbell wrote: > This is unnecessary (since the page will be removed from the p2m) and > can be tricky if the page is in the middle of a superpage, as it is on > ARM. > I think that this patch is correct. I'll leave to Konrad whether we should carry the original incorrect PVH patch and this separate fix or just merge the two of them. > Signed-off-by: Ian Campbell > --- > Also effects PVH but in a benign way I think. > > drivers/xen/balloon.c | 23 +++-------------------- > 1 files changed, 3 insertions(+), 20 deletions(-) > > diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c > index 7885a19..1b56ae0 100644 > --- a/drivers/xen/balloon.c > +++ b/drivers/xen/balloon.c > @@ -357,15 +357,7 @@ static enum bp_state increase_reservation(unsigned long nr_pages) > BUG_ON(!xen_feature(XENFEAT_auto_translated_physmap) && > phys_to_machine_mapping_valid(pfn)); > > - if (xen_pv_domain() && > - xen_feature(XENFEAT_auto_translated_physmap)) { > - /* PVH: we just need to update native page table */ > - pte_t *ptep; > - unsigned int level; > - void *addr = __va(pfn << PAGE_SHIFT); > - ptep = lookup_address((unsigned long)addr, &level); > - set_pte(ptep, pfn_pte(pfn, PAGE_KERNEL)); > - } else > + if (!xen_feature(XENFEAT_auto_translated_physmap)) > set_phys_to_machine(pfn, frame_list[i]); > > /* Link back into the page tables if not highmem. */ > @@ -427,21 +419,12 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp) > > scrub_page(page); > > - if (xen_pv_domain() && !PageHighMem(page)) { > - if (xen_feature(XENFEAT_auto_translated_physmap)) { > - unsigned int level; > - pte_t *ptep; > - void *addr = __va(pfn << PAGE_SHIFT); > - ptep = lookup_address((unsigned long)addr, > - &level); > - set_pte(ptep, __pte(0)); > - > - } else { > + if (xen_pv_domain() && !PageHighMem(page) && > + !xen_feature(XENFEAT_auto_translated_physmap)) { > ret = HYPERVISOR_update_va_mapping( > (unsigned long)__va(pfn << PAGE_SHIFT), > __pte_ma(0), 0); > BUG_ON(ret); > - } > } > } > > -- > 1.7.2.5 > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 12:06:59 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 12:06:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6g2-0000zy-H3; Fri, 05 Oct 2012 12:06:46 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6g1-0000zb-DC for xen-devel@lists.xen.org; Fri, 05 Oct 2012 12:06:45 +0000 Received: from [85.158.143.99:56560] by server-3.bemta-4.messagelabs.com id 29/81-10986-45DCE605; Fri, 05 Oct 2012 12:06:44 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1349438803!26878741!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30571 invoked from network); 5 Oct 2012 12:06:44 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 12:06:44 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14961886" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 12:06:03 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 13:06:03 +0100 Date: Fri, 5 Oct 2012 13:05:01 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Ian Campbell In-Reply-To: <1349363515-26190-7-git-send-email-ian.campbell@citrix.com> Message-ID: References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-7-git-send-email-ian.campbell@citrix.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: Stefano Stabellini , "xen-devel@lists.xen.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 07/14] xen: balloon: do not update stage 1 pagetable for autotranslated guests X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 4 Oct 2012, Ian Campbell wrote: > This is unnecessary (since the page will be removed from the p2m) and > can be tricky if the page is in the middle of a superpage, as it is on > ARM. > I think that this patch is correct. I'll leave to Konrad whether we should carry the original incorrect PVH patch and this separate fix or just merge the two of them. > Signed-off-by: Ian Campbell > --- > Also effects PVH but in a benign way I think. > > drivers/xen/balloon.c | 23 +++-------------------- > 1 files changed, 3 insertions(+), 20 deletions(-) > > diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c > index 7885a19..1b56ae0 100644 > --- a/drivers/xen/balloon.c > +++ b/drivers/xen/balloon.c > @@ -357,15 +357,7 @@ static enum bp_state increase_reservation(unsigned long nr_pages) > BUG_ON(!xen_feature(XENFEAT_auto_translated_physmap) && > phys_to_machine_mapping_valid(pfn)); > > - if (xen_pv_domain() && > - xen_feature(XENFEAT_auto_translated_physmap)) { > - /* PVH: we just need to update native page table */ > - pte_t *ptep; > - unsigned int level; > - void *addr = __va(pfn << PAGE_SHIFT); > - ptep = lookup_address((unsigned long)addr, &level); > - set_pte(ptep, pfn_pte(pfn, PAGE_KERNEL)); > - } else > + if (!xen_feature(XENFEAT_auto_translated_physmap)) > set_phys_to_machine(pfn, frame_list[i]); > > /* Link back into the page tables if not highmem. */ > @@ -427,21 +419,12 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp) > > scrub_page(page); > > - if (xen_pv_domain() && !PageHighMem(page)) { > - if (xen_feature(XENFEAT_auto_translated_physmap)) { > - unsigned int level; > - pte_t *ptep; > - void *addr = __va(pfn << PAGE_SHIFT); > - ptep = lookup_address((unsigned long)addr, > - &level); > - set_pte(ptep, __pte(0)); > - > - } else { > + if (xen_pv_domain() && !PageHighMem(page) && > + !xen_feature(XENFEAT_auto_translated_physmap)) { > ret = HYPERVISOR_update_va_mapping( > (unsigned long)__va(pfn << PAGE_SHIFT), > __pte_ma(0), 0); > BUG_ON(ret); > - } > } > } > > -- > 1.7.2.5 > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 12:12:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 12:12:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6lm-0001d7-DI; Fri, 05 Oct 2012 12:12:42 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6ll-0001cx-9E for xen-devel@lists.xen.org; Fri, 05 Oct 2012 12:12:41 +0000 Received: from [85.158.143.99:31424] by server-3.bemta-4.messagelabs.com id 63/4A-10986-8BECE605; Fri, 05 Oct 2012 12:12:40 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1349439160!27709153!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9259 invoked from network); 5 Oct 2012 12:12:40 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 12:12:40 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14962118" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 12:12:40 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 13:12:40 +0100 Message-ID: <1349439158.20946.77.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Jan Beulich Date: Fri, 5 Oct 2012 13:12:38 +0100 In-Reply-To: <506EE3FF020000780009FF1B@nat28.tlf.novell.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> <1349433507-21148-20-git-send-email-ian.campbell@citrix.com> <1349436628.20946.63.camel@zakaz.uk.xensource.com> <506EE3FF020000780009FF1B@nat28.tlf.novell.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Tim \(Xen.org\)" , "xen-devel@lists.xen.org" , "Keir \(Xen.org\)" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH 20/21] xen: replace XEN_GUEST_HANDLE with XEN_GUEST_HANDLE_PARAM when appropriate X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-10-05 at 12:43 +0100, Jan Beulich wrote: > >>> On 05.10.12 at 13:30, Ian Campbell wrote: > > This probably ought to be folded into the original patch rather than > > kept separate. > > Think so, yes. > > > --- a/xen/include/public/tmem.h > > +++ b/xen/include/public/tmem.h > > @@ -96,7 +96,8 @@ > > > > #ifndef __ASSEMBLY__ > > typedef xen_pfn_t tmem_cli_mfn_t; > > -typedef XEN_GUEST_HANDLE_PARAM(char) tmem_cli_va_t; > > +typedef XEN_GUEST_HANDLE(char) tmem_cli_va_t; > > +typedef XEN_GUEST_HANDLE_PARAM(char) tmem_cli_va_param_t; > > This doesn't belong here - there's no use of tmem_cli_va_param_t > anywhere in the public interface afaict. Right. I'll throw it in xen/include/xen/tmem_xen.h instead. > I didn't check, but if there > are other uses of XEN_GUEST_HANDLE_PARAM() in the public > headers, I would suspect them to be wrong too - at the interface > layer, there shouldn't be any need for them. Only the #define itself. > > > --- a/xen/include/xen/compat.h > > +++ b/xen/include/xen/compat.h > > @@ -21,7 +21,9 @@ > > __DEFINE_COMPAT_HANDLE(name, name); \ > > __DEFINE_COMPAT_HANDLE(const_ ## name, const name) > > #define COMPAT_HANDLE(name) __compat_handle_ ## name > > - > > +/* NB: it is assumed that if an arch uses the compat layer it does not > > + * distinguish handles from parameter handles. */ > > +#define COMPAT_HANDLE_PARAM(name) __compat_handle_ ## name > > /* Is the compat handle a NULL reference? */ > > #define compat_handle_is_null(hnd) ((hnd).c == 0) > > This seems acceptable to me (minus the dropped newline). Thanks. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 12:12:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 12:12:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6lm-0001d7-DI; Fri, 05 Oct 2012 12:12:42 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK6ll-0001cx-9E for xen-devel@lists.xen.org; Fri, 05 Oct 2012 12:12:41 +0000 Received: from [85.158.143.99:31424] by server-3.bemta-4.messagelabs.com id 63/4A-10986-8BECE605; Fri, 05 Oct 2012 12:12:40 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1349439160!27709153!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9259 invoked from network); 5 Oct 2012 12:12:40 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 12:12:40 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14962118" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 12:12:40 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 13:12:40 +0100 Message-ID: <1349439158.20946.77.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Jan Beulich Date: Fri, 5 Oct 2012 13:12:38 +0100 In-Reply-To: <506EE3FF020000780009FF1B@nat28.tlf.novell.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> <1349433507-21148-20-git-send-email-ian.campbell@citrix.com> <1349436628.20946.63.camel@zakaz.uk.xensource.com> <506EE3FF020000780009FF1B@nat28.tlf.novell.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Tim \(Xen.org\)" , "xen-devel@lists.xen.org" , "Keir \(Xen.org\)" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH 20/21] xen: replace XEN_GUEST_HANDLE with XEN_GUEST_HANDLE_PARAM when appropriate X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-10-05 at 12:43 +0100, Jan Beulich wrote: > >>> On 05.10.12 at 13:30, Ian Campbell wrote: > > This probably ought to be folded into the original patch rather than > > kept separate. > > Think so, yes. > > > --- a/xen/include/public/tmem.h > > +++ b/xen/include/public/tmem.h > > @@ -96,7 +96,8 @@ > > > > #ifndef __ASSEMBLY__ > > typedef xen_pfn_t tmem_cli_mfn_t; > > -typedef XEN_GUEST_HANDLE_PARAM(char) tmem_cli_va_t; > > +typedef XEN_GUEST_HANDLE(char) tmem_cli_va_t; > > +typedef XEN_GUEST_HANDLE_PARAM(char) tmem_cli_va_param_t; > > This doesn't belong here - there's no use of tmem_cli_va_param_t > anywhere in the public interface afaict. Right. I'll throw it in xen/include/xen/tmem_xen.h instead. > I didn't check, but if there > are other uses of XEN_GUEST_HANDLE_PARAM() in the public > headers, I would suspect them to be wrong too - at the interface > layer, there shouldn't be any need for them. Only the #define itself. > > > --- a/xen/include/xen/compat.h > > +++ b/xen/include/xen/compat.h > > @@ -21,7 +21,9 @@ > > __DEFINE_COMPAT_HANDLE(name, name); \ > > __DEFINE_COMPAT_HANDLE(const_ ## name, const name) > > #define COMPAT_HANDLE(name) __compat_handle_ ## name > > - > > +/* NB: it is assumed that if an arch uses the compat layer it does not > > + * distinguish handles from parameter handles. */ > > +#define COMPAT_HANDLE_PARAM(name) __compat_handle_ ## name > > /* Is the compat handle a NULL reference? */ > > #define compat_handle_is_null(hnd) ((hnd).c == 0) > > This seems acceptable to me (minus the dropped newline). Thanks. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 12:28:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 12:28:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK70T-0001xN-S5; Fri, 05 Oct 2012 12:27:53 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK70S-0001xI-Ia for xen-devel@lists.xen.org; Fri, 05 Oct 2012 12:27:52 +0000 Received: from [85.158.143.35:51138] by server-1.bemta-4.messagelabs.com id F8/8C-05684-742DE605; Fri, 05 Oct 2012 12:27:51 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1349440026!14043148!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5527 invoked from network); 5 Oct 2012 12:27:07 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-8.tower-21.messagelabs.com with SMTP; 5 Oct 2012 12:27:07 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 05 Oct 2012 13:27:06 +0100 Message-Id: <506EEE39020000780009FF7F@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 05 Oct 2012 13:27:05 +0100 From: "Jan Beulich" To: "Ben Guthro" References: In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel Subject: Re: [Xen-devel] [PATCH] fix public header hvm/save.h to be compatible with c++ X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 05.10.12 at 14:05, Ben Guthro wrote: > Including save.h in a C++ application was throwing some errors, as it > was unhappy about the "new" keyword being used (even when wrapped in > an "extern C" block) > > This change renames some variables to keep the compiler happy, as well > as casts the (void*) as appropriate. > > Signed-off-by: Ben Guthro > > diff --git a/xen/include/public/arch-x86/hvm/save.h > b/xen/include/public/arch-x86/hvm/save.h > index a82a5ee..20e5061 100644 > --- a/xen/include/public/arch-x86/hvm/save.h > +++ b/xen/include/public/arch-x86/hvm/save.h > @@ -269,15 +269,15 @@ struct hvm_hw_cpu_compat { > }; > > static inline int _hvm_hw_fix_cpu(void *h) { > - struct hvm_hw_cpu *new=h; > - struct hvm_hw_cpu_compat *old=h; > + struct hvm_hw_cpu *new_cpu = (struct hvm_hw_cpu *)h; > + struct hvm_hw_cpu_compat *old_cpu = (struct hvm_hw_cpu_compat *)h; While I don't mind the variable renames (albeit I'm questioning whether the headers ought to be honoring the C++ reserved names in the first place), I dislike the casts - they're redundant in C (and it is my opinion that due to the mistakes casts can hide they should be used as sparingly as possible), and at best undesirable in C++ (you'd want to use static_cast<> there instead). Since the function is unused with __XEN__ undefined, I'd instead suggest putting it inside a respective preprocessor conditional. > /* If we copy from the end backwards, we should > * be able to do the modification in-place */ > - new->error_code=old->error_code; > - new->pending_event=old->pending_event; > - new->tsc=old->tsc; > - new->msr_tsc_aux=0; > + new_cpu->error_code=old_cpu->error_code; > + new_cpu->pending_event=old_cpu->pending_event; > + new_cpu->tsc=old_cpu->tsc; > + new_cpu->msr_tsc_aux=0; Once at it, you could have inserted the missing spaces around the equal signs at once... Jan > > return 0; > } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 12:28:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 12:28:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK70T-0001xN-S5; Fri, 05 Oct 2012 12:27:53 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK70S-0001xI-Ia for xen-devel@lists.xen.org; Fri, 05 Oct 2012 12:27:52 +0000 Received: from [85.158.143.35:51138] by server-1.bemta-4.messagelabs.com id F8/8C-05684-742DE605; Fri, 05 Oct 2012 12:27:51 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1349440026!14043148!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5527 invoked from network); 5 Oct 2012 12:27:07 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-8.tower-21.messagelabs.com with SMTP; 5 Oct 2012 12:27:07 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 05 Oct 2012 13:27:06 +0100 Message-Id: <506EEE39020000780009FF7F@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 05 Oct 2012 13:27:05 +0100 From: "Jan Beulich" To: "Ben Guthro" References: In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel Subject: Re: [Xen-devel] [PATCH] fix public header hvm/save.h to be compatible with c++ X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 05.10.12 at 14:05, Ben Guthro wrote: > Including save.h in a C++ application was throwing some errors, as it > was unhappy about the "new" keyword being used (even when wrapped in > an "extern C" block) > > This change renames some variables to keep the compiler happy, as well > as casts the (void*) as appropriate. > > Signed-off-by: Ben Guthro > > diff --git a/xen/include/public/arch-x86/hvm/save.h > b/xen/include/public/arch-x86/hvm/save.h > index a82a5ee..20e5061 100644 > --- a/xen/include/public/arch-x86/hvm/save.h > +++ b/xen/include/public/arch-x86/hvm/save.h > @@ -269,15 +269,15 @@ struct hvm_hw_cpu_compat { > }; > > static inline int _hvm_hw_fix_cpu(void *h) { > - struct hvm_hw_cpu *new=h; > - struct hvm_hw_cpu_compat *old=h; > + struct hvm_hw_cpu *new_cpu = (struct hvm_hw_cpu *)h; > + struct hvm_hw_cpu_compat *old_cpu = (struct hvm_hw_cpu_compat *)h; While I don't mind the variable renames (albeit I'm questioning whether the headers ought to be honoring the C++ reserved names in the first place), I dislike the casts - they're redundant in C (and it is my opinion that due to the mistakes casts can hide they should be used as sparingly as possible), and at best undesirable in C++ (you'd want to use static_cast<> there instead). Since the function is unused with __XEN__ undefined, I'd instead suggest putting it inside a respective preprocessor conditional. > /* If we copy from the end backwards, we should > * be able to do the modification in-place */ > - new->error_code=old->error_code; > - new->pending_event=old->pending_event; > - new->tsc=old->tsc; > - new->msr_tsc_aux=0; > + new_cpu->error_code=old_cpu->error_code; > + new_cpu->pending_event=old_cpu->pending_event; > + new_cpu->tsc=old_cpu->tsc; > + new_cpu->msr_tsc_aux=0; Once at it, you could have inserted the missing spaces around the equal signs at once... Jan > > return 0; > } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 12:28:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 12:28:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK71D-000205-8t; Fri, 05 Oct 2012 12:28:39 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK71C-0001zw-Fq for xen-devel@lists.xen.org; Fri, 05 Oct 2012 12:28:38 +0000 Received: from [85.158.143.35:57484] by server-3.bemta-4.messagelabs.com id 9E/00-10986-572DE605; Fri, 05 Oct 2012 12:28:37 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1349440115!13481734!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8350 invoked from network); 5 Oct 2012 12:28:36 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-3.tower-21.messagelabs.com with SMTP; 5 Oct 2012 12:28:36 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 05 Oct 2012 13:28:32 +0100 Message-Id: <506EEE90020000780009FF82@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 05 Oct 2012 13:28:32 +0100 From: "Jan Beulich" To: "Ian Campbell" References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> <1349433507-21148-20-git-send-email-ian.campbell@citrix.com> <1349436628.20946.63.camel@zakaz.uk.xensource.com> <506EE3FF020000780009FF1B@nat28.tlf.novell.com> <1349439158.20946.77.camel@zakaz.uk.xensource.com> In-Reply-To: <1349439158.20946.77.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Disposition: inline Cc: "Tim \(Xen.org\)" , "xen-devel@lists.xen.org" , "Keir \(Xen.org\)" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH 20/21] xen: replace XEN_GUEST_HANDLE with XEN_GUEST_HANDLE_PARAM when appropriate X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 05.10.12 at 14:12, Ian Campbell wrote: > On Fri, 2012-10-05 at 12:43 +0100, Jan Beulich wrote: >> I didn't check, but if there >> are other uses of XEN_GUEST_HANDLE_PARAM() in the public >> headers, I would suspect them to be wrong too - at the interface >> layer, there shouldn't be any need for them. > > Only the #define itself. That's acceptable, albeit perhaps not really correct/necessary either. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 12:28:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 12:28:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK71D-000205-8t; Fri, 05 Oct 2012 12:28:39 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK71C-0001zw-Fq for xen-devel@lists.xen.org; Fri, 05 Oct 2012 12:28:38 +0000 Received: from [85.158.143.35:57484] by server-3.bemta-4.messagelabs.com id 9E/00-10986-572DE605; Fri, 05 Oct 2012 12:28:37 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1349440115!13481734!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8350 invoked from network); 5 Oct 2012 12:28:36 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-3.tower-21.messagelabs.com with SMTP; 5 Oct 2012 12:28:36 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 05 Oct 2012 13:28:32 +0100 Message-Id: <506EEE90020000780009FF82@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 05 Oct 2012 13:28:32 +0100 From: "Jan Beulich" To: "Ian Campbell" References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> <1349433507-21148-20-git-send-email-ian.campbell@citrix.com> <1349436628.20946.63.camel@zakaz.uk.xensource.com> <506EE3FF020000780009FF1B@nat28.tlf.novell.com> <1349439158.20946.77.camel@zakaz.uk.xensource.com> In-Reply-To: <1349439158.20946.77.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Disposition: inline Cc: "Tim \(Xen.org\)" , "xen-devel@lists.xen.org" , "Keir \(Xen.org\)" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH 20/21] xen: replace XEN_GUEST_HANDLE with XEN_GUEST_HANDLE_PARAM when appropriate X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 05.10.12 at 14:12, Ian Campbell wrote: > On Fri, 2012-10-05 at 12:43 +0100, Jan Beulich wrote: >> I didn't check, but if there >> are other uses of XEN_GUEST_HANDLE_PARAM() in the public >> headers, I would suspect them to be wrong too - at the interface >> layer, there shouldn't be any need for them. > > Only the #define itself. That's acceptable, albeit perhaps not really correct/necessary either. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 12:33:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 12:33:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK75Z-0002EC-Up; Fri, 05 Oct 2012 12:33:09 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK75Y-0002Dv-9c for xen-devel@lists.xen.org; Fri, 05 Oct 2012 12:33:08 +0000 Received: from [85.158.143.35:53062] by server-3.bemta-4.messagelabs.com id B6/77-10986-283DE605; Fri, 05 Oct 2012 12:33:06 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1349440353!13842036!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31288 invoked from network); 5 Oct 2012 12:32:33 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 12:32:33 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14962633" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 12:32:19 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 13:32:19 +0100 Message-ID: <1349440338.20946.83.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Fri, 5 Oct 2012 13:32:18 +0100 In-Reply-To: References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-5-git-send-email-ian.campbell@citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 05/14] xen: balloon: use correct type for frame_list X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-10-05 at 12:48 +0100, Stefano Stabellini wrote: > On Thu, 4 Oct 2012, Ian Campbell wrote: > > This is now a xen_pfn_t. > > > > Signed-off-by: Ian Campbell > > --- > > drivers/xen/balloon.c | 2 +- > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c > > index 85ef7e7..4625560 100644 > > --- a/drivers/xen/balloon.c > > +++ b/drivers/xen/balloon.c > > @@ -87,7 +87,7 @@ struct balloon_stats balloon_stats; > > EXPORT_SYMBOL_GPL(balloon_stats); > > > > /* We increase/decrease in batches which fit in a page */ > > -static unsigned long frame_list[PAGE_SIZE / sizeof(unsigned long)]; > > +static xen_pfn_t frame_list[PAGE_SIZE / sizeof(unsigned long)]; > > > > #ifdef CONFIG_HIGHMEM > > #define inc_totalhigh_pages() (totalhigh_pages++) > > While I think is a good change, frame_list[i] is used as an argument to > set_phys_to_machine, that takes an unsigned long. Also unsigned long are > assigned to members of the array via page_to_pfn. > I think that we should take care of these cases, either introducing > explicit casts or changing the argument types. frame_list is used at the Xen interface, and so the pfn type has to be sized for the largest pfn the hypervisor will use (aka xen_pfn_t). Those unsigned longs are really "linux_pfn_t", that is they are the size of the largest pfn the guest is itself prepared to deal with. So long as sizeof(unsigned long) <= sizeof(xen_pfn_t) (which it is) then we are ok. If and when Linux wants to use pfn's which are not unsigned longs then the uses of unsigned long will need to be audited (globally, not just here) to become whatever type Linux then defines to contain a pfn. In the absence of that type being defined in the core Linux code I think it is correct for us to keep using unsigned long in those contexts. Konrad, now I think about it the same argument applies to the discussion of fgmfn in <20121004155400.GA12128@phenom.dumpdata.com>. So I'll leave that as unsigned long as well. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 12:33:26 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 12:33:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK75Z-0002EC-Up; Fri, 05 Oct 2012 12:33:09 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK75Y-0002Dv-9c for xen-devel@lists.xen.org; Fri, 05 Oct 2012 12:33:08 +0000 Received: from [85.158.143.35:53062] by server-3.bemta-4.messagelabs.com id B6/77-10986-283DE605; Fri, 05 Oct 2012 12:33:06 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1349440353!13842036!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31288 invoked from network); 5 Oct 2012 12:32:33 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 12:32:33 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14962633" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 12:32:19 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 13:32:19 +0100 Message-ID: <1349440338.20946.83.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Fri, 5 Oct 2012 13:32:18 +0100 In-Reply-To: References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-5-git-send-email-ian.campbell@citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 05/14] xen: balloon: use correct type for frame_list X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-10-05 at 12:48 +0100, Stefano Stabellini wrote: > On Thu, 4 Oct 2012, Ian Campbell wrote: > > This is now a xen_pfn_t. > > > > Signed-off-by: Ian Campbell > > --- > > drivers/xen/balloon.c | 2 +- > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c > > index 85ef7e7..4625560 100644 > > --- a/drivers/xen/balloon.c > > +++ b/drivers/xen/balloon.c > > @@ -87,7 +87,7 @@ struct balloon_stats balloon_stats; > > EXPORT_SYMBOL_GPL(balloon_stats); > > > > /* We increase/decrease in batches which fit in a page */ > > -static unsigned long frame_list[PAGE_SIZE / sizeof(unsigned long)]; > > +static xen_pfn_t frame_list[PAGE_SIZE / sizeof(unsigned long)]; > > > > #ifdef CONFIG_HIGHMEM > > #define inc_totalhigh_pages() (totalhigh_pages++) > > While I think is a good change, frame_list[i] is used as an argument to > set_phys_to_machine, that takes an unsigned long. Also unsigned long are > assigned to members of the array via page_to_pfn. > I think that we should take care of these cases, either introducing > explicit casts or changing the argument types. frame_list is used at the Xen interface, and so the pfn type has to be sized for the largest pfn the hypervisor will use (aka xen_pfn_t). Those unsigned longs are really "linux_pfn_t", that is they are the size of the largest pfn the guest is itself prepared to deal with. So long as sizeof(unsigned long) <= sizeof(xen_pfn_t) (which it is) then we are ok. If and when Linux wants to use pfn's which are not unsigned longs then the uses of unsigned long will need to be audited (globally, not just here) to become whatever type Linux then defines to contain a pfn. In the absence of that type being defined in the core Linux code I think it is correct for us to keep using unsigned long in those contexts. Konrad, now I think about it the same argument applies to the discussion of fgmfn in <20121004155400.GA12128@phenom.dumpdata.com>. So I'll leave that as unsigned long as well. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 12:47:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 12:47:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7JV-0002XZ-Jb; Fri, 05 Oct 2012 12:47:33 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7JU-0002XU-RS for xen-devel@lists.xen.org; Fri, 05 Oct 2012 12:47:33 +0000 X-Env-Sender: ben.guthro@gmail.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1349441216!8767847!1 X-Originating-IP: [209.85.223.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24667 invoked from network); 5 Oct 2012 12:46:57 -0000 Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com) (209.85.223.173) by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 12:46:57 -0000 Received: by mail-ie0-f173.google.com with SMTP id 17so4658500iea.32 for ; Fri, 05 Oct 2012 05:46:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=7Q+bKbUWmtXRWmxaKTLcBzenVxqgCdSB2JYccl6z768=; b=yhcQG+skTwX7f6DREDsooXo8jtNtrGC4uQvEHuf0ODsijrapfWlYBOiU6CP73t5QrH 5H2Azc0gfHoiRu6JAy5TWjUvKWYqucEDakX39E6WyuQzs4utdhEs151oB+CoUPbaUJCF nLUqbcFL736rN+hd/NDqkHG5qTXkFR1+Cy9nbmhzMY+/m1fsWf6NA+HrQ4qhSo0DOrb5 PrxCRpRGzHuKVbum6NGFix2mQEJxM6LXAj59TokS/ISmpB12yYSK/OQEJH4m+tdbbELw Rbl1t14zAbXDbf9Vz7c/IeSFkQFoLMyHwula7oxBGeiySxkVT9mvpntJFwOdwi3r4jMQ YZhQ== MIME-Version: 1.0 Received: by 10.42.110.130 with SMTP id q2mr6857891icp.53.1349441216126; Fri, 05 Oct 2012 05:46:56 -0700 (PDT) Received: by 10.64.48.197 with HTTP; Fri, 5 Oct 2012 05:46:55 -0700 (PDT) In-Reply-To: <506EEE39020000780009FF7F@nat28.tlf.novell.com> References: <506EEE39020000780009FF7F@nat28.tlf.novell.com> Date: Fri, 5 Oct 2012 08:46:55 -0400 X-Google-Sender-Auth: 8-ZQnSS8M4Xs0YNpa5cIYY7sCag Message-ID: From: Ben Guthro To: Jan Beulich Content-Type: multipart/mixed; boundary=485b397dcfb55520ac04cb4f44fb Cc: xen-devel Subject: Re: [Xen-devel] [PATCH] fix public header hvm/save.h to be compatible with c++ X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --485b397dcfb55520ac04cb4f44fb Content-Type: text/plain; charset=ISO-8859-1 Thanks for your review. Comments addressed, and re-tested. Including save.h in a C++ application was throwing some errors, as it was unhappy about the "new" keyword being used (even when wrapped in an "extern C" block) This change renames some variables, as well as wraps the function in a __XEN__ preprocessor directive. Signed-off-by: Ben Guthro diff --git a/xen/include/public/arch-x86/hvm/save.h b/xen/include/public/arch-x86/hvm/save.h index a82a5ee..1b88c28 100644 --- a/xen/include/public/arch-x86/hvm/save.h +++ b/xen/include/public/arch-x86/hvm/save.h @@ -268,19 +268,21 @@ struct hvm_hw_cpu_compat { uint32_t error_code; }; +#ifdef __XEN__ static inline int _hvm_hw_fix_cpu(void *h) { - struct hvm_hw_cpu *new=h; - struct hvm_hw_cpu_compat *old=h; + struct hvm_hw_cpu *new_cpu = h; + struct hvm_hw_cpu_compat *old_cpu = h; /* If we copy from the end backwards, we should * be able to do the modification in-place */ - new->error_code=old->error_code; - new->pending_event=old->pending_event; - new->tsc=old->tsc; - new->msr_tsc_aux=0; + new_cpu->error_code = old_cpu->error_code; + new_cpu->pending_event = old_cpu->pending_event; + new_cpu->tsc = old_cpu->tsc; + new_cpu->msr_tsc_aux = 0; return 0; } +#endif DECLARE_HVM_SAVE_TYPE_COMPAT(CPU, 2, struct hvm_hw_cpu, \ struct hvm_hw_cpu_compat, _hvm_hw_fix_cpu); --485b397dcfb55520ac04cb4f44fb Content-Type: application/octet-stream; name="public_headers_cpp_fixes.patch" Content-Disposition: attachment; filename="public_headers_cpp_fixes.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h7xaczvr0 ZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3B1YmxpYy9hcmNoLXg4Ni9odm0vc2F2ZS5oIGIveGVu L2luY2x1ZGUvcHVibGljL2FyY2gteDg2L2h2bS9zYXZlLmgKaW5kZXggYTgyYTVlZS4uMWI4OGMy OCAxMDA2NDQKLS0tIGEveGVuL2luY2x1ZGUvcHVibGljL2FyY2gteDg2L2h2bS9zYXZlLmgKKysr IGIveGVuL2luY2x1ZGUvcHVibGljL2FyY2gteDg2L2h2bS9zYXZlLmgKQEAgLTI2OCwxOSArMjY4 LDIxIEBAIHN0cnVjdCBodm1faHdfY3B1X2NvbXBhdCB7CiAgICAgdWludDMyX3QgZXJyb3JfY29k ZTsKIH07CiAKKyNpZmRlZiBfX1hFTl9fCiBzdGF0aWMgaW5saW5lIGludCBfaHZtX2h3X2ZpeF9j cHUodm9pZCAqaCkgewotICAgIHN0cnVjdCBodm1faHdfY3B1ICpuZXc9aDsKLSAgICBzdHJ1Y3Qg aHZtX2h3X2NwdV9jb21wYXQgKm9sZD1oOworICAgIHN0cnVjdCBodm1faHdfY3B1ICpuZXdfY3B1 ID0gaDsKKyAgICBzdHJ1Y3QgaHZtX2h3X2NwdV9jb21wYXQgKm9sZF9jcHUgPSBoOwogCiAgICAg LyogSWYgd2UgY29weSBmcm9tIHRoZSBlbmQgYmFja3dhcmRzLCB3ZSBzaG91bGQKICAgICAgKiBi ZSBhYmxlIHRvIGRvIHRoZSBtb2RpZmljYXRpb24gaW4tcGxhY2UgKi8KLSAgICBuZXctPmVycm9y X2NvZGU9b2xkLT5lcnJvcl9jb2RlOwotICAgIG5ldy0+cGVuZGluZ19ldmVudD1vbGQtPnBlbmRp bmdfZXZlbnQ7Ci0gICAgbmV3LT50c2M9b2xkLT50c2M7Ci0gICAgbmV3LT5tc3JfdHNjX2F1eD0w OworICAgIG5ld19jcHUtPmVycm9yX2NvZGUgPSBvbGRfY3B1LT5lcnJvcl9jb2RlOworICAgIG5l d19jcHUtPnBlbmRpbmdfZXZlbnQgPSBvbGRfY3B1LT5wZW5kaW5nX2V2ZW50OworICAgIG5ld19j cHUtPnRzYyA9IG9sZF9jcHUtPnRzYzsKKyAgICBuZXdfY3B1LT5tc3JfdHNjX2F1eCA9IDA7CiAK ICAgICByZXR1cm4gMDsKIH0KKyNlbmRpZgogCiBERUNMQVJFX0hWTV9TQVZFX1RZUEVfQ09NUEFU KENQVSwgMiwgc3RydWN0IGh2bV9od19jcHUsIFwKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgc3RydWN0IGh2bV9od19jcHVfY29tcGF0LCBfaHZtX2h3X2ZpeF9jcHUpOwo= --485b397dcfb55520ac04cb4f44fb Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --485b397dcfb55520ac04cb4f44fb-- From xen-devel-bounces@lists.xen.org Fri Oct 05 12:47:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 12:47:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7JV-0002XZ-Jb; Fri, 05 Oct 2012 12:47:33 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7JU-0002XU-RS for xen-devel@lists.xen.org; Fri, 05 Oct 2012 12:47:33 +0000 X-Env-Sender: ben.guthro@gmail.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1349441216!8767847!1 X-Originating-IP: [209.85.223.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24667 invoked from network); 5 Oct 2012 12:46:57 -0000 Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com) (209.85.223.173) by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 12:46:57 -0000 Received: by mail-ie0-f173.google.com with SMTP id 17so4658500iea.32 for ; Fri, 05 Oct 2012 05:46:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=7Q+bKbUWmtXRWmxaKTLcBzenVxqgCdSB2JYccl6z768=; b=yhcQG+skTwX7f6DREDsooXo8jtNtrGC4uQvEHuf0ODsijrapfWlYBOiU6CP73t5QrH 5H2Azc0gfHoiRu6JAy5TWjUvKWYqucEDakX39E6WyuQzs4utdhEs151oB+CoUPbaUJCF nLUqbcFL736rN+hd/NDqkHG5qTXkFR1+Cy9nbmhzMY+/m1fsWf6NA+HrQ4qhSo0DOrb5 PrxCRpRGzHuKVbum6NGFix2mQEJxM6LXAj59TokS/ISmpB12yYSK/OQEJH4m+tdbbELw Rbl1t14zAbXDbf9Vz7c/IeSFkQFoLMyHwula7oxBGeiySxkVT9mvpntJFwOdwi3r4jMQ YZhQ== MIME-Version: 1.0 Received: by 10.42.110.130 with SMTP id q2mr6857891icp.53.1349441216126; Fri, 05 Oct 2012 05:46:56 -0700 (PDT) Received: by 10.64.48.197 with HTTP; Fri, 5 Oct 2012 05:46:55 -0700 (PDT) In-Reply-To: <506EEE39020000780009FF7F@nat28.tlf.novell.com> References: <506EEE39020000780009FF7F@nat28.tlf.novell.com> Date: Fri, 5 Oct 2012 08:46:55 -0400 X-Google-Sender-Auth: 8-ZQnSS8M4Xs0YNpa5cIYY7sCag Message-ID: From: Ben Guthro To: Jan Beulich Content-Type: multipart/mixed; boundary=485b397dcfb55520ac04cb4f44fb Cc: xen-devel Subject: Re: [Xen-devel] [PATCH] fix public header hvm/save.h to be compatible with c++ X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --485b397dcfb55520ac04cb4f44fb Content-Type: text/plain; charset=ISO-8859-1 Thanks for your review. Comments addressed, and re-tested. Including save.h in a C++ application was throwing some errors, as it was unhappy about the "new" keyword being used (even when wrapped in an "extern C" block) This change renames some variables, as well as wraps the function in a __XEN__ preprocessor directive. Signed-off-by: Ben Guthro diff --git a/xen/include/public/arch-x86/hvm/save.h b/xen/include/public/arch-x86/hvm/save.h index a82a5ee..1b88c28 100644 --- a/xen/include/public/arch-x86/hvm/save.h +++ b/xen/include/public/arch-x86/hvm/save.h @@ -268,19 +268,21 @@ struct hvm_hw_cpu_compat { uint32_t error_code; }; +#ifdef __XEN__ static inline int _hvm_hw_fix_cpu(void *h) { - struct hvm_hw_cpu *new=h; - struct hvm_hw_cpu_compat *old=h; + struct hvm_hw_cpu *new_cpu = h; + struct hvm_hw_cpu_compat *old_cpu = h; /* If we copy from the end backwards, we should * be able to do the modification in-place */ - new->error_code=old->error_code; - new->pending_event=old->pending_event; - new->tsc=old->tsc; - new->msr_tsc_aux=0; + new_cpu->error_code = old_cpu->error_code; + new_cpu->pending_event = old_cpu->pending_event; + new_cpu->tsc = old_cpu->tsc; + new_cpu->msr_tsc_aux = 0; return 0; } +#endif DECLARE_HVM_SAVE_TYPE_COMPAT(CPU, 2, struct hvm_hw_cpu, \ struct hvm_hw_cpu_compat, _hvm_hw_fix_cpu); --485b397dcfb55520ac04cb4f44fb Content-Type: application/octet-stream; name="public_headers_cpp_fixes.patch" Content-Disposition: attachment; filename="public_headers_cpp_fixes.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h7xaczvr0 ZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3B1YmxpYy9hcmNoLXg4Ni9odm0vc2F2ZS5oIGIveGVu L2luY2x1ZGUvcHVibGljL2FyY2gteDg2L2h2bS9zYXZlLmgKaW5kZXggYTgyYTVlZS4uMWI4OGMy OCAxMDA2NDQKLS0tIGEveGVuL2luY2x1ZGUvcHVibGljL2FyY2gteDg2L2h2bS9zYXZlLmgKKysr IGIveGVuL2luY2x1ZGUvcHVibGljL2FyY2gteDg2L2h2bS9zYXZlLmgKQEAgLTI2OCwxOSArMjY4 LDIxIEBAIHN0cnVjdCBodm1faHdfY3B1X2NvbXBhdCB7CiAgICAgdWludDMyX3QgZXJyb3JfY29k ZTsKIH07CiAKKyNpZmRlZiBfX1hFTl9fCiBzdGF0aWMgaW5saW5lIGludCBfaHZtX2h3X2ZpeF9j cHUodm9pZCAqaCkgewotICAgIHN0cnVjdCBodm1faHdfY3B1ICpuZXc9aDsKLSAgICBzdHJ1Y3Qg aHZtX2h3X2NwdV9jb21wYXQgKm9sZD1oOworICAgIHN0cnVjdCBodm1faHdfY3B1ICpuZXdfY3B1 ID0gaDsKKyAgICBzdHJ1Y3QgaHZtX2h3X2NwdV9jb21wYXQgKm9sZF9jcHUgPSBoOwogCiAgICAg LyogSWYgd2UgY29weSBmcm9tIHRoZSBlbmQgYmFja3dhcmRzLCB3ZSBzaG91bGQKICAgICAgKiBi ZSBhYmxlIHRvIGRvIHRoZSBtb2RpZmljYXRpb24gaW4tcGxhY2UgKi8KLSAgICBuZXctPmVycm9y X2NvZGU9b2xkLT5lcnJvcl9jb2RlOwotICAgIG5ldy0+cGVuZGluZ19ldmVudD1vbGQtPnBlbmRp bmdfZXZlbnQ7Ci0gICAgbmV3LT50c2M9b2xkLT50c2M7Ci0gICAgbmV3LT5tc3JfdHNjX2F1eD0w OworICAgIG5ld19jcHUtPmVycm9yX2NvZGUgPSBvbGRfY3B1LT5lcnJvcl9jb2RlOworICAgIG5l d19jcHUtPnBlbmRpbmdfZXZlbnQgPSBvbGRfY3B1LT5wZW5kaW5nX2V2ZW50OworICAgIG5ld19j cHUtPnRzYyA9IG9sZF9jcHUtPnRzYzsKKyAgICBuZXdfY3B1LT5tc3JfdHNjX2F1eCA9IDA7CiAK ICAgICByZXR1cm4gMDsKIH0KKyNlbmRpZgogCiBERUNMQVJFX0hWTV9TQVZFX1RZUEVfQ09NUEFU KENQVSwgMiwgc3RydWN0IGh2bV9od19jcHUsIFwKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgc3RydWN0IGh2bV9od19jcHVfY29tcGF0LCBfaHZtX2h3X2ZpeF9jcHUpOwo= --485b397dcfb55520ac04cb4f44fb Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --485b397dcfb55520ac04cb4f44fb-- From xen-devel-bounces@lists.xen.org Fri Oct 05 13:09:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:09:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7e9-000388-Dj; Fri, 05 Oct 2012 13:08:53 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7e8-000381-LM for xen-devel@lists.xen.org; Fri, 05 Oct 2012 13:08:52 +0000 Received: from [85.158.143.99:43852] by server-2.bemta-4.messagelabs.com id FF/E7-06610-3EBDE605; Fri, 05 Oct 2012 13:08:51 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1349442531!24824384!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5679 invoked from network); 5 Oct 2012 13:08:51 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 13:08:51 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14963668" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 13:08:07 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 14:08:07 +0100 Message-ID: <1349442485.20946.87.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Anthony PERARD Date: Fri, 5 Oct 2012 14:08:05 +0100 In-Reply-To: <1348683325-12367-3-git-send-email-anthony.perard@citrix.com> References: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com> <1348683325-12367-3-git-send-email-anthony.perard@citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: Ian Jackson , Xen Devel Subject: Re: [Xen-devel] [PATCH V3 02/10] libxl_json: Remove JSON_ERROR from enum. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-09-26 at 19:15 +0100, Anthony PERARD wrote: > This value from libxl__json_node_type is never used. > > Signed-off-by: Anthony PERARD Acked-by: Ian Campbell > --- > tools/libxl/libxl_internal.h | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h > index f69f58d..49c62c0 100644 > --- a/tools/libxl/libxl_internal.h > +++ b/tools/libxl/libxl_internal.h > @@ -1427,7 +1427,6 @@ _hidden yajl_gen_status libxl__yajl_gen_asciiz(yajl_gen hand, const char *str); > _hidden yajl_gen_status libxl__yajl_gen_enum(yajl_gen hand, const char *str); > > typedef enum { > - JSON_ERROR, > JSON_NULL, > JSON_TRUE, > JSON_FALSE, _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 13:09:13 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:09:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7e9-000388-Dj; Fri, 05 Oct 2012 13:08:53 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7e8-000381-LM for xen-devel@lists.xen.org; Fri, 05 Oct 2012 13:08:52 +0000 Received: from [85.158.143.99:43852] by server-2.bemta-4.messagelabs.com id FF/E7-06610-3EBDE605; Fri, 05 Oct 2012 13:08:51 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1349442531!24824384!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5679 invoked from network); 5 Oct 2012 13:08:51 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 13:08:51 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14963668" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 13:08:07 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 14:08:07 +0100 Message-ID: <1349442485.20946.87.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Anthony PERARD Date: Fri, 5 Oct 2012 14:08:05 +0100 In-Reply-To: <1348683325-12367-3-git-send-email-anthony.perard@citrix.com> References: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com> <1348683325-12367-3-git-send-email-anthony.perard@citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: Ian Jackson , Xen Devel Subject: Re: [Xen-devel] [PATCH V3 02/10] libxl_json: Remove JSON_ERROR from enum. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-09-26 at 19:15 +0100, Anthony PERARD wrote: > This value from libxl__json_node_type is never used. > > Signed-off-by: Anthony PERARD Acked-by: Ian Campbell > --- > tools/libxl/libxl_internal.h | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h > index f69f58d..49c62c0 100644 > --- a/tools/libxl/libxl_internal.h > +++ b/tools/libxl/libxl_internal.h > @@ -1427,7 +1427,6 @@ _hidden yajl_gen_status libxl__yajl_gen_asciiz(yajl_gen hand, const char *str); > _hidden yajl_gen_status libxl__yajl_gen_enum(yajl_gen hand, const char *str); > > typedef enum { > - JSON_ERROR, > JSON_NULL, > JSON_TRUE, > JSON_FALSE, _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 13:11:17 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:11:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7gB-0003JU-NU; Fri, 05 Oct 2012 13:10:59 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7gA-0003JI-9e for xen-devel@lists.xen.org; Fri, 05 Oct 2012 13:10:58 +0000 Received: from [85.158.139.83:16337] by server-10.bemta-5.messagelabs.com id 33/6E-16911-16CDE605; Fri, 05 Oct 2012 13:10:57 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1349442656!29693841!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9611 invoked from network); 5 Oct 2012 13:10:57 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 13:10:57 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14963767" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 13:10:50 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 14:10:50 +0100 Message-ID: <1349442649.20946.89.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Anthony PERARD Date: Fri, 5 Oct 2012 14:10:49 +0100 In-Reply-To: <1348683325-12367-4-git-send-email-anthony.perard@citrix.com> References: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com> <1348683325-12367-4-git-send-email-anthony.perard@citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: Ian Jackson , Xen Devel Subject: Re: [Xen-devel] [PATCH V3 03/10] libxl_json: Replace JSON_TRUE/FALSE by JSON_BOOL. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-09-26 at 19:15 +0100, Anthony PERARD wrote: > Those two JSON_TRUE and JSON_FALSE were types of node. But it's better to have > a unique JSON_BOOL type. > > Signed-off-by: Anthony PERARD Acked-by: Ian Campbell Is it valid to call libxl__json_object_get_bool (and all the similar functions) with a wrongly typed thing? The other types seem to return NULL as an error indicator. The bool case just returns false. Just wondering if maybe there ought to be an assert in each of those? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 13:11:17 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:11:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7gB-0003JU-NU; Fri, 05 Oct 2012 13:10:59 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7gA-0003JI-9e for xen-devel@lists.xen.org; Fri, 05 Oct 2012 13:10:58 +0000 Received: from [85.158.139.83:16337] by server-10.bemta-5.messagelabs.com id 33/6E-16911-16CDE605; Fri, 05 Oct 2012 13:10:57 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1349442656!29693841!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9611 invoked from network); 5 Oct 2012 13:10:57 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 13:10:57 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14963767" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 13:10:50 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 14:10:50 +0100 Message-ID: <1349442649.20946.89.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Anthony PERARD Date: Fri, 5 Oct 2012 14:10:49 +0100 In-Reply-To: <1348683325-12367-4-git-send-email-anthony.perard@citrix.com> References: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com> <1348683325-12367-4-git-send-email-anthony.perard@citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: Ian Jackson , Xen Devel Subject: Re: [Xen-devel] [PATCH V3 03/10] libxl_json: Replace JSON_TRUE/FALSE by JSON_BOOL. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-09-26 at 19:15 +0100, Anthony PERARD wrote: > Those two JSON_TRUE and JSON_FALSE were types of node. But it's better to have > a unique JSON_BOOL type. > > Signed-off-by: Anthony PERARD Acked-by: Ian Campbell Is it valid to call libxl__json_object_get_bool (and all the similar functions) with a wrongly typed thing? The other types seem to return NULL as an error indicator. The bool case just returns false. Just wondering if maybe there ought to be an assert in each of those? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 13:12:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:12:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7hl-0003Uf-As; Fri, 05 Oct 2012 13:12:37 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7hk-0003Tz-E4 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 13:12:36 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1349442749!8883765!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4231 invoked from network); 5 Oct 2012 13:12:30 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 13:12:30 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14963811" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 13:12:29 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 14:12:29 +0100 Message-ID: <1349442748.20946.90.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Anthony PERARD Date: Fri, 5 Oct 2012 14:12:28 +0100 In-Reply-To: <1348683325-12367-5-git-send-email-anthony.perard@citrix.com> References: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com> <1348683325-12367-5-git-send-email-anthony.perard@citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: Ian Jackson , Xen Devel Subject: Re: [Xen-devel] [PATCH V3 04/10] libxl_json: Introduce libxl__json_object_to_yajl_gen. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-09-26 at 19:15 +0100, Anthony PERARD wrote: > This function converts a libxl__json_object to yajl by calling every yajl_gen_* > function on a preallocated yajl_gen hand. > > This helps to integrate a json_object into an already existing yajl_gen tree. > > This function is used in a later patch. > > Signed-off-by: Anthony PERARD Acked-by: Ian Campbell _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 13:12:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:12:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7hl-0003Uf-As; Fri, 05 Oct 2012 13:12:37 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7hk-0003Tz-E4 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 13:12:36 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1349442749!8883765!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4231 invoked from network); 5 Oct 2012 13:12:30 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 13:12:30 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14963811" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 13:12:29 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 14:12:29 +0100 Message-ID: <1349442748.20946.90.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Anthony PERARD Date: Fri, 5 Oct 2012 14:12:28 +0100 In-Reply-To: <1348683325-12367-5-git-send-email-anthony.perard@citrix.com> References: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com> <1348683325-12367-5-git-send-email-anthony.perard@citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: Ian Jackson , Xen Devel Subject: Re: [Xen-devel] [PATCH V3 04/10] libxl_json: Introduce libxl__json_object_to_yajl_gen. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-09-26 at 19:15 +0100, Anthony PERARD wrote: > This function converts a libxl__json_object to yajl by calling every yajl_gen_* > function on a preallocated yajl_gen hand. > > This helps to integrate a json_object into an already existing yajl_gen tree. > > This function is used in a later patch. > > Signed-off-by: Anthony PERARD Acked-by: Ian Campbell _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 13:14:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:14:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7jB-0003hD-Sb; Fri, 05 Oct 2012 13:14:05 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with smtp (Exim 4.72) (envelope-from ) id 1TK7jA-0003gP-1l for xen-devel@lists.xen.org; Fri, 05 Oct 2012 13:14:04 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1349442837!11620957!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6826 invoked from network); 5 Oct 2012 13:13:57 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-3.tower-27.messagelabs.com with SMTP; 5 Oct 2012 13:13:57 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 05 Oct 2012 14:13:57 +0100 Message-Id: <506EF935020000780009FFBC@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 05 Oct 2012 14:13:57 +0100 From: "Jan Beulich" To: "Ben Guthro" References: <506EEE39020000780009FF7F@nat28.tlf.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel Subject: Re: [Xen-devel] [PATCH] fix public header hvm/save.h to be compatible with c++ X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 05.10.12 at 14:46, Ben Guthro wrote: > Thanks for your review. Comments addressed, and re-tested. But now I fail to see why the rename is still necessary - you don't write hypervisor code in C++, do you? Jan > Including save.h in a C++ application was throwing some errors, as it > was unhappy about the "new" keyword being used (even when wrapped in > an "extern C" block) > > This change renames some variables, as well as wraps the function in a > __XEN__ preprocessor directive. > > Signed-off-by: Ben Guthro > > diff --git a/xen/include/public/arch-x86/hvm/save.h > b/xen/include/public/arch-x86/hvm/save.h > index a82a5ee..1b88c28 100644 > --- a/xen/include/public/arch-x86/hvm/save.h > +++ b/xen/include/public/arch-x86/hvm/save.h > @@ -268,19 +268,21 @@ struct hvm_hw_cpu_compat { > uint32_t error_code; > }; > > +#ifdef __XEN__ > static inline int _hvm_hw_fix_cpu(void *h) { > - struct hvm_hw_cpu *new=h; > - struct hvm_hw_cpu_compat *old=h; > + struct hvm_hw_cpu *new_cpu = h; > + struct hvm_hw_cpu_compat *old_cpu = h; > > /* If we copy from the end backwards, we should > * be able to do the modification in-place */ > - new->error_code=old->error_code; > - new->pending_event=old->pending_event; > - new->tsc=old->tsc; > - new->msr_tsc_aux=0; > + new_cpu->error_code = old_cpu->error_code; > + new_cpu->pending_event = old_cpu->pending_event; > + new_cpu->tsc = old_cpu->tsc; > + new_cpu->msr_tsc_aux = 0; > > return 0; > } > +#endif > > DECLARE_HVM_SAVE_TYPE_COMPAT(CPU, 2, struct hvm_hw_cpu, \ > struct hvm_hw_cpu_compat, _hvm_hw_fix_cpu); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 13:14:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:14:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7jB-0003hD-Sb; Fri, 05 Oct 2012 13:14:05 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with smtp (Exim 4.72) (envelope-from ) id 1TK7jA-0003gP-1l for xen-devel@lists.xen.org; Fri, 05 Oct 2012 13:14:04 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1349442837!11620957!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6826 invoked from network); 5 Oct 2012 13:13:57 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-3.tower-27.messagelabs.com with SMTP; 5 Oct 2012 13:13:57 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 05 Oct 2012 14:13:57 +0100 Message-Id: <506EF935020000780009FFBC@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 05 Oct 2012 14:13:57 +0100 From: "Jan Beulich" To: "Ben Guthro" References: <506EEE39020000780009FF7F@nat28.tlf.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel Subject: Re: [Xen-devel] [PATCH] fix public header hvm/save.h to be compatible with c++ X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 05.10.12 at 14:46, Ben Guthro wrote: > Thanks for your review. Comments addressed, and re-tested. But now I fail to see why the rename is still necessary - you don't write hypervisor code in C++, do you? Jan > Including save.h in a C++ application was throwing some errors, as it > was unhappy about the "new" keyword being used (even when wrapped in > an "extern C" block) > > This change renames some variables, as well as wraps the function in a > __XEN__ preprocessor directive. > > Signed-off-by: Ben Guthro > > diff --git a/xen/include/public/arch-x86/hvm/save.h > b/xen/include/public/arch-x86/hvm/save.h > index a82a5ee..1b88c28 100644 > --- a/xen/include/public/arch-x86/hvm/save.h > +++ b/xen/include/public/arch-x86/hvm/save.h > @@ -268,19 +268,21 @@ struct hvm_hw_cpu_compat { > uint32_t error_code; > }; > > +#ifdef __XEN__ > static inline int _hvm_hw_fix_cpu(void *h) { > - struct hvm_hw_cpu *new=h; > - struct hvm_hw_cpu_compat *old=h; > + struct hvm_hw_cpu *new_cpu = h; > + struct hvm_hw_cpu_compat *old_cpu = h; > > /* If we copy from the end backwards, we should > * be able to do the modification in-place */ > - new->error_code=old->error_code; > - new->pending_event=old->pending_event; > - new->tsc=old->tsc; > - new->msr_tsc_aux=0; > + new_cpu->error_code = old_cpu->error_code; > + new_cpu->pending_event = old_cpu->pending_event; > + new_cpu->tsc = old_cpu->tsc; > + new_cpu->msr_tsc_aux = 0; > > return 0; > } > +#endif > > DECLARE_HVM_SAVE_TYPE_COMPAT(CPU, 2, struct hvm_hw_cpu, \ > struct hvm_hw_cpu_compat, _hvm_hw_fix_cpu); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 13:16:09 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:16:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7kw-0003sM-CW; Fri, 05 Oct 2012 13:15:54 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7kv-0003s5-3e for xen-devel@lists.xen.org; Fri, 05 Oct 2012 13:15:53 +0000 Received: from [85.158.139.83:39416] by server-6.bemta-5.messagelabs.com id D6/02-14717-88DDE605; Fri, 05 Oct 2012 13:15:52 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1349442951!32915284!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2636 invoked from network); 5 Oct 2012 13:15:51 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 13:15:51 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14963895" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 13:15:51 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 14:15:51 +0100 Message-ID: <1349442950.20946.91.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Anthony PERARD Date: Fri, 5 Oct 2012 14:15:50 +0100 In-Reply-To: <1348683325-12367-6-git-send-email-anthony.perard@citrix.com> References: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com> <1348683325-12367-6-git-send-email-anthony.perard@citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: Ian Jackson , Xen Devel Subject: Re: [Xen-devel] [PATCH V3 05/10] libxl_qmp: Introduces helpers to create an argument list. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-09-26 at 19:15 +0100, Anthony PERARD wrote: > Those functions will be used to create a "list" of parameters that contain more > than just strings. This list is converted by qmp_send to a string to be sent to > QEMU. > > Those functions will be used in the next two patches, so right now there are > not compiled. > > Signed-off-by: Anthony PERARD Acked-by: Ian Campbell _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 13:16:09 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:16:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7kw-0003sM-CW; Fri, 05 Oct 2012 13:15:54 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7kv-0003s5-3e for xen-devel@lists.xen.org; Fri, 05 Oct 2012 13:15:53 +0000 Received: from [85.158.139.83:39416] by server-6.bemta-5.messagelabs.com id D6/02-14717-88DDE605; Fri, 05 Oct 2012 13:15:52 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1349442951!32915284!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2636 invoked from network); 5 Oct 2012 13:15:51 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 13:15:51 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14963895" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 13:15:51 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 14:15:51 +0100 Message-ID: <1349442950.20946.91.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Anthony PERARD Date: Fri, 5 Oct 2012 14:15:50 +0100 In-Reply-To: <1348683325-12367-6-git-send-email-anthony.perard@citrix.com> References: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com> <1348683325-12367-6-git-send-email-anthony.perard@citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: Ian Jackson , Xen Devel Subject: Re: [Xen-devel] [PATCH V3 05/10] libxl_qmp: Introduces helpers to create an argument list. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-09-26 at 19:15 +0100, Anthony PERARD wrote: > Those functions will be used to create a "list" of parameters that contain more > than just strings. This list is converted by qmp_send to a string to be sent to > QEMU. > > Those functions will be used in the next two patches, so right now there are > not compiled. > > Signed-off-by: Anthony PERARD Acked-by: Ian Campbell _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 13:19:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:19:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7oE-0004CW-An; Fri, 05 Oct 2012 13:19:18 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7oD-0004CP-Lg for xen-devel@lists.xen.org; Fri, 05 Oct 2012 13:19:17 +0000 Received: from [85.158.143.35:46016] by server-2.bemta-4.messagelabs.com id 60/97-06610-45EDE605; Fri, 05 Oct 2012 13:19:16 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1349443155!13182482!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29291 invoked from network); 5 Oct 2012 13:19:15 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 13:19:15 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14963983" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 13:19:06 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 14:19:06 +0100 Message-ID: <1349443144.20946.94.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Anthony PERARD Date: Fri, 5 Oct 2012 14:19:04 +0100 In-Reply-To: <1348683325-12367-11-git-send-email-anthony.perard@citrix.com> References: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com> <1348683325-12367-11-git-send-email-anthony.perard@citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: Ian Jackson , Xen Devel Subject: Re: [Xen-devel] [PATCH V3 10/10] libxl: Allow migration with qemu-xen. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-09-26 at 19:15 +0100, Anthony PERARD wrote: > Signed-off-by: Anthony PERARD Acked-by: Ian Campbell Are there any docs which need updating for this change? I had a look under docs/* and grep didn't find anything, in the wiki perhaps? Maybe this should be the inaugural entry in http://wiki/wiki/Xen_4.3_Feature_List ? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 13:19:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:19:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7oE-0004CW-An; Fri, 05 Oct 2012 13:19:18 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7oD-0004CP-Lg for xen-devel@lists.xen.org; Fri, 05 Oct 2012 13:19:17 +0000 Received: from [85.158.143.35:46016] by server-2.bemta-4.messagelabs.com id 60/97-06610-45EDE605; Fri, 05 Oct 2012 13:19:16 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1349443155!13182482!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29291 invoked from network); 5 Oct 2012 13:19:15 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 13:19:15 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14963983" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 13:19:06 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 14:19:06 +0100 Message-ID: <1349443144.20946.94.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Anthony PERARD Date: Fri, 5 Oct 2012 14:19:04 +0100 In-Reply-To: <1348683325-12367-11-git-send-email-anthony.perard@citrix.com> References: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com> <1348683325-12367-11-git-send-email-anthony.perard@citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: Ian Jackson , Xen Devel Subject: Re: [Xen-devel] [PATCH V3 10/10] libxl: Allow migration with qemu-xen. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, 2012-09-26 at 19:15 +0100, Anthony PERARD wrote: > Signed-off-by: Anthony PERARD Acked-by: Ian Campbell Are there any docs which need updating for this change? I had a look under docs/* and grep didn't find anything, in the wiki perhaps? Maybe this should be the inaugural entry in http://wiki/wiki/Xen_4.3_Feature_List ? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 13:19:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:19:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7oX-0004Ek-Ne; Fri, 05 Oct 2012 13:19:37 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7oV-0004EP-RY for xen-devel@lists.xen.org; Fri, 05 Oct 2012 13:19:36 +0000 Received: from [85.158.139.211:8270] by server-1.bemta-5.messagelabs.com id 0E/69-09825-76EDE605; Fri, 05 Oct 2012 13:19:35 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-10.tower-206.messagelabs.com!1349443174!21183891!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14035 invoked from network); 5 Oct 2012 13:19:34 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 13:19:34 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14964001" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 13:19:34 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 14:19:33 +0100 Date: Fri, 5 Oct 2012 14:18:31 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Ian Campbell In-Reply-To: <1349363515-26190-9-git-send-email-ian.campbell@citrix.com> Message-ID: References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-9-git-send-email-ian.campbell@citrix.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: Stefano Stabellini , "xen-devel@lists.xen.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 09/14] xen: arm: enable balloon driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 4 Oct 2012, Ian Campbell wrote: > Drop the *_xenballloned_pages duplicates since these are now supplied > by the balloon code. > > Signed-off-by: Ian Campbell Acked-by: Stefano Stabellini > arch/arm/xen/enlighten.c | 23 +++++------------------ > drivers/xen/Makefile | 4 ++-- > drivers/xen/privcmd.c | 9 ++++----- > 3 files changed, 11 insertions(+), 25 deletions(-) > > diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c > index 59bcb96..ba5cc13 100644 > --- a/arch/arm/xen/enlighten.c > +++ b/arch/arm/xen/enlighten.c > @@ -8,6 +8,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -29,6 +30,10 @@ struct shared_info *HYPERVISOR_shared_info = (void *)&xen_dummy_shared_info; > > DEFINE_PER_CPU(struct vcpu_info *, xen_vcpu); > > +/* These are unused until we support booting "pre-ballooned" */ > +unsigned long xen_released_pages; > +struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata; > + > /* TODO: to be removed */ > __read_mostly int xen_have_vector_callback; > EXPORT_SYMBOL_GPL(xen_have_vector_callback); > @@ -148,21 +153,3 @@ static int __init xen_init_events(void) > return 0; > } > postcore_initcall(xen_init_events); > - > -/* XXX: only until balloon is properly working */ > -int alloc_xenballooned_pages(int nr_pages, struct page **pages, bool highmem) > -{ > - *pages = alloc_pages(highmem ? GFP_HIGHUSER : GFP_KERNEL, > - get_order(nr_pages)); > - if (*pages == NULL) > - return -ENOMEM; > - return 0; > -} > -EXPORT_SYMBOL_GPL(alloc_xenballooned_pages); > - > -void free_xenballooned_pages(int nr_pages, struct page **pages) > -{ > - kfree(*pages); > - *pages = NULL; > -} > -EXPORT_SYMBOL_GPL(free_xenballooned_pages); > diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile > index 275abfc..9a7896f 100644 > --- a/drivers/xen/Makefile > +++ b/drivers/xen/Makefile > @@ -1,8 +1,8 @@ > ifneq ($(CONFIG_ARM),y) > -obj-y += manage.o balloon.o > +obj-y += manage.o > obj-$(CONFIG_HOTPLUG_CPU) += cpu_hotplug.o > endif > -obj-y += grant-table.o features.o events.o > +obj-y += grant-table.o features.o events.o balloon.o > obj-y += xenbus/ > > nostackp := $(call cc-option, -fno-stack-protector) > diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c > index 1010bf7..bf4d62a 100644 > --- a/drivers/xen/privcmd.c > +++ b/drivers/xen/privcmd.c > @@ -200,8 +200,8 @@ static long privcmd_ioctl_mmap(void __user *udata) > if (!xen_initial_domain()) > return -EPERM; > > - /* PVH: TBD/FIXME. For now we only support privcmd_ioctl_mmap_batch */ > - if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap)) > + /* We only support privcmd_ioctl_mmap_batch for auto translated. */ > + if (xen_feature(XENFEAT_auto_translated_physmap)) > return -ENOSYS; > > if (copy_from_user(&mmapcmd, udata, sizeof(mmapcmd))) > @@ -413,7 +413,7 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version) > up_write(&mm->mmap_sem); > goto out; > } > - if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap)) { > + if (xen_feature(XENFEAT_auto_translated_physmap)) { > if ((ret = pvh_privcmd_resv_pfns(vma, m.num))) { > up_write(&mm->mmap_sem); > goto out; > @@ -492,8 +492,7 @@ static void privcmd_close(struct vm_area_struct *vma) > int count; > struct xen_pvh_pfn_info *pvhp = vma ? vma->vm_private_data : NULL; > > - if (!xen_pv_domain() || !pvhp || > - !xen_feature(XENFEAT_auto_translated_physmap)) > + if (!pvhp || !xen_feature(XENFEAT_auto_translated_physmap)) > return; > > count = xen_unmap_domain_mfn_range(vma, pvhp); > -- > 1.7.2.5 > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 13:19:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:19:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7oX-0004Ek-Ne; Fri, 05 Oct 2012 13:19:37 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7oV-0004EP-RY for xen-devel@lists.xen.org; Fri, 05 Oct 2012 13:19:36 +0000 Received: from [85.158.139.211:8270] by server-1.bemta-5.messagelabs.com id 0E/69-09825-76EDE605; Fri, 05 Oct 2012 13:19:35 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-10.tower-206.messagelabs.com!1349443174!21183891!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14035 invoked from network); 5 Oct 2012 13:19:34 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 13:19:34 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14964001" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 13:19:34 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 14:19:33 +0100 Date: Fri, 5 Oct 2012 14:18:31 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Ian Campbell In-Reply-To: <1349363515-26190-9-git-send-email-ian.campbell@citrix.com> Message-ID: References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-9-git-send-email-ian.campbell@citrix.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: Stefano Stabellini , "xen-devel@lists.xen.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 09/14] xen: arm: enable balloon driver X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 4 Oct 2012, Ian Campbell wrote: > Drop the *_xenballloned_pages duplicates since these are now supplied > by the balloon code. > > Signed-off-by: Ian Campbell Acked-by: Stefano Stabellini > arch/arm/xen/enlighten.c | 23 +++++------------------ > drivers/xen/Makefile | 4 ++-- > drivers/xen/privcmd.c | 9 ++++----- > 3 files changed, 11 insertions(+), 25 deletions(-) > > diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c > index 59bcb96..ba5cc13 100644 > --- a/arch/arm/xen/enlighten.c > +++ b/arch/arm/xen/enlighten.c > @@ -8,6 +8,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -29,6 +30,10 @@ struct shared_info *HYPERVISOR_shared_info = (void *)&xen_dummy_shared_info; > > DEFINE_PER_CPU(struct vcpu_info *, xen_vcpu); > > +/* These are unused until we support booting "pre-ballooned" */ > +unsigned long xen_released_pages; > +struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata; > + > /* TODO: to be removed */ > __read_mostly int xen_have_vector_callback; > EXPORT_SYMBOL_GPL(xen_have_vector_callback); > @@ -148,21 +153,3 @@ static int __init xen_init_events(void) > return 0; > } > postcore_initcall(xen_init_events); > - > -/* XXX: only until balloon is properly working */ > -int alloc_xenballooned_pages(int nr_pages, struct page **pages, bool highmem) > -{ > - *pages = alloc_pages(highmem ? GFP_HIGHUSER : GFP_KERNEL, > - get_order(nr_pages)); > - if (*pages == NULL) > - return -ENOMEM; > - return 0; > -} > -EXPORT_SYMBOL_GPL(alloc_xenballooned_pages); > - > -void free_xenballooned_pages(int nr_pages, struct page **pages) > -{ > - kfree(*pages); > - *pages = NULL; > -} > -EXPORT_SYMBOL_GPL(free_xenballooned_pages); > diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile > index 275abfc..9a7896f 100644 > --- a/drivers/xen/Makefile > +++ b/drivers/xen/Makefile > @@ -1,8 +1,8 @@ > ifneq ($(CONFIG_ARM),y) > -obj-y += manage.o balloon.o > +obj-y += manage.o > obj-$(CONFIG_HOTPLUG_CPU) += cpu_hotplug.o > endif > -obj-y += grant-table.o features.o events.o > +obj-y += grant-table.o features.o events.o balloon.o > obj-y += xenbus/ > > nostackp := $(call cc-option, -fno-stack-protector) > diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c > index 1010bf7..bf4d62a 100644 > --- a/drivers/xen/privcmd.c > +++ b/drivers/xen/privcmd.c > @@ -200,8 +200,8 @@ static long privcmd_ioctl_mmap(void __user *udata) > if (!xen_initial_domain()) > return -EPERM; > > - /* PVH: TBD/FIXME. For now we only support privcmd_ioctl_mmap_batch */ > - if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap)) > + /* We only support privcmd_ioctl_mmap_batch for auto translated. */ > + if (xen_feature(XENFEAT_auto_translated_physmap)) > return -ENOSYS; > > if (copy_from_user(&mmapcmd, udata, sizeof(mmapcmd))) > @@ -413,7 +413,7 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version) > up_write(&mm->mmap_sem); > goto out; > } > - if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap)) { > + if (xen_feature(XENFEAT_auto_translated_physmap)) { > if ((ret = pvh_privcmd_resv_pfns(vma, m.num))) { > up_write(&mm->mmap_sem); > goto out; > @@ -492,8 +492,7 @@ static void privcmd_close(struct vm_area_struct *vma) > int count; > struct xen_pvh_pfn_info *pvhp = vma ? vma->vm_private_data : NULL; > > - if (!xen_pv_domain() || !pvhp || > - !xen_feature(XENFEAT_auto_translated_physmap)) > + if (!pvhp || !xen_feature(XENFEAT_auto_translated_physmap)) > return; > > count = xen_unmap_domain_mfn_range(vma, pvhp); > -- > 1.7.2.5 > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 13:20:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:20:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7pP-0004My-6K; Fri, 05 Oct 2012 13:20:31 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7pN-0004Ma-5R for xen-devel@lists.xen.org; Fri, 05 Oct 2012 13:20:29 +0000 Received: from [85.158.139.211:17830] by server-5.bemta-5.messagelabs.com id 69/76-21075-C9EDE605; Fri, 05 Oct 2012 13:20:28 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-10.tower-206.messagelabs.com!1349443227!21184016!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17572 invoked from network); 5 Oct 2012 13:20:27 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 13:20:27 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14964033" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 13:20:27 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 14:20:27 +0100 Date: Fri, 5 Oct 2012 14:19:25 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Ian Campbell In-Reply-To: <1349363515-26190-8-git-send-email-ian.campbell@citrix.com> Message-ID: References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-8-git-send-email-ian.campbell@citrix.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: Stefano Stabellini , "xen-devel@lists.xen.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 08/14] xen: balloon: allow PVMMU interfaces to be compiled out X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 4 Oct 2012, Ian Campbell wrote: > The ARM platform has no concept of PVMMU and therefor no > HYPERVISOR_update_va_mapping et al. Allow this code to be compiled out > when not required. > > Signed-off-by: Ian Campbell I am unsure whether it is worth a new symbol and two ifdef's > arch/x86/xen/Kconfig | 1 + > drivers/xen/Kconfig | 3 +++ > drivers/xen/balloon.c | 4 ++++ > 3 files changed, 8 insertions(+), 0 deletions(-) > > diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig > index fdce49c..c31ee77 100644 > --- a/arch/x86/xen/Kconfig > +++ b/arch/x86/xen/Kconfig > @@ -6,6 +6,7 @@ config XEN > bool "Xen guest support" > select PARAVIRT > select PARAVIRT_CLOCK > + select XEN_HAVE_PVMMU > depends on X86_64 || (X86_32 && X86_PAE && !X86_VISWS) > depends on X86_CMPXCHG && X86_TSC > help > diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig > index d4dffcd..9c00652 100644 > --- a/drivers/xen/Kconfig > +++ b/drivers/xen/Kconfig > @@ -204,4 +204,7 @@ config XEN_MCE_LOG > Allow kernel fetching MCE error from Xen platform and > converting it into Linux mcelog format for mcelog tools > > +config XEN_HAVE_PVMMU > + bool > + > endmenu > diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c > index 1b56ae0..cfe47dae 100644 > --- a/drivers/xen/balloon.c > +++ b/drivers/xen/balloon.c > @@ -360,6 +360,7 @@ static enum bp_state increase_reservation(unsigned long nr_pages) > if (!xen_feature(XENFEAT_auto_translated_physmap)) > set_phys_to_machine(pfn, frame_list[i]); > > +#ifdef CONFIG_XEN_HAVE_PVMMU > /* Link back into the page tables if not highmem. */ > if (xen_pv_domain() && !PageHighMem(page) && > !xen_feature(XENFEAT_auto_translated_physmap)) { > @@ -371,6 +372,7 @@ static enum bp_state increase_reservation(unsigned long nr_pages) > 0); > BUG_ON(ret); > } > +#endif > > /* Relinquish the page back to the allocator. */ > ClearPageReserved(page); > @@ -419,6 +421,7 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp) > > scrub_page(page); > > +#ifdef CONFIG_XEN_HAVE_PVMMU > if (xen_pv_domain() && !PageHighMem(page) && > !xen_feature(XENFEAT_auto_translated_physmap)) { > ret = HYPERVISOR_update_va_mapping( > @@ -426,6 +429,7 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp) > __pte_ma(0), 0); > BUG_ON(ret); > } > +#endif > } > > /* Ensure that ballooned highmem pages don't have kmaps. */ > -- > 1.7.2.5 > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 13:20:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:20:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7pP-0004My-6K; Fri, 05 Oct 2012 13:20:31 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7pN-0004Ma-5R for xen-devel@lists.xen.org; Fri, 05 Oct 2012 13:20:29 +0000 Received: from [85.158.139.211:17830] by server-5.bemta-5.messagelabs.com id 69/76-21075-C9EDE605; Fri, 05 Oct 2012 13:20:28 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-10.tower-206.messagelabs.com!1349443227!21184016!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17572 invoked from network); 5 Oct 2012 13:20:27 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 13:20:27 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14964033" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 13:20:27 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 14:20:27 +0100 Date: Fri, 5 Oct 2012 14:19:25 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Ian Campbell In-Reply-To: <1349363515-26190-8-git-send-email-ian.campbell@citrix.com> Message-ID: References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-8-git-send-email-ian.campbell@citrix.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: Stefano Stabellini , "xen-devel@lists.xen.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 08/14] xen: balloon: allow PVMMU interfaces to be compiled out X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 4 Oct 2012, Ian Campbell wrote: > The ARM platform has no concept of PVMMU and therefor no > HYPERVISOR_update_va_mapping et al. Allow this code to be compiled out > when not required. > > Signed-off-by: Ian Campbell I am unsure whether it is worth a new symbol and two ifdef's > arch/x86/xen/Kconfig | 1 + > drivers/xen/Kconfig | 3 +++ > drivers/xen/balloon.c | 4 ++++ > 3 files changed, 8 insertions(+), 0 deletions(-) > > diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig > index fdce49c..c31ee77 100644 > --- a/arch/x86/xen/Kconfig > +++ b/arch/x86/xen/Kconfig > @@ -6,6 +6,7 @@ config XEN > bool "Xen guest support" > select PARAVIRT > select PARAVIRT_CLOCK > + select XEN_HAVE_PVMMU > depends on X86_64 || (X86_32 && X86_PAE && !X86_VISWS) > depends on X86_CMPXCHG && X86_TSC > help > diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig > index d4dffcd..9c00652 100644 > --- a/drivers/xen/Kconfig > +++ b/drivers/xen/Kconfig > @@ -204,4 +204,7 @@ config XEN_MCE_LOG > Allow kernel fetching MCE error from Xen platform and > converting it into Linux mcelog format for mcelog tools > > +config XEN_HAVE_PVMMU > + bool > + > endmenu > diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c > index 1b56ae0..cfe47dae 100644 > --- a/drivers/xen/balloon.c > +++ b/drivers/xen/balloon.c > @@ -360,6 +360,7 @@ static enum bp_state increase_reservation(unsigned long nr_pages) > if (!xen_feature(XENFEAT_auto_translated_physmap)) > set_phys_to_machine(pfn, frame_list[i]); > > +#ifdef CONFIG_XEN_HAVE_PVMMU > /* Link back into the page tables if not highmem. */ > if (xen_pv_domain() && !PageHighMem(page) && > !xen_feature(XENFEAT_auto_translated_physmap)) { > @@ -371,6 +372,7 @@ static enum bp_state increase_reservation(unsigned long nr_pages) > 0); > BUG_ON(ret); > } > +#endif > > /* Relinquish the page back to the allocator. */ > ClearPageReserved(page); > @@ -419,6 +421,7 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp) > > scrub_page(page); > > +#ifdef CONFIG_XEN_HAVE_PVMMU > if (xen_pv_domain() && !PageHighMem(page) && > !xen_feature(XENFEAT_auto_translated_physmap)) { > ret = HYPERVISOR_update_va_mapping( > @@ -426,6 +429,7 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp) > __pte_ma(0), 0); > BUG_ON(ret); > } > +#endif > } > > /* Ensure that ballooned highmem pages don't have kmaps. */ > -- > 1.7.2.5 > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 13:21:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:21:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7qb-0004XC-Sh; Fri, 05 Oct 2012 13:21:45 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7qa-0004Ww-Nv for xen-devel@lists.xen.org; Fri, 05 Oct 2012 13:21:44 +0000 Received: from [85.158.137.99:60019] by server-14.bemta-3.messagelabs.com id 62/C9-19528-7EEDE605; Fri, 05 Oct 2012 13:21:43 +0000 X-Env-Sender: ben.guthro@gmail.com X-Msg-Ref: server-10.tower-217.messagelabs.com!1349443301!20309204!1 X-Originating-IP: [209.85.223.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18823 invoked from network); 5 Oct 2012 13:21:43 -0000 Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com) (209.85.223.173) by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 13:21:43 -0000 Received: by mail-ie0-f173.google.com with SMTP id 17so4775365iea.32 for ; Fri, 05 Oct 2012 06:21:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=l5Bn+npDldR4SzZve1EHg3gquUAGWuT5zj6u6EhH5c8=; b=WUNyoonFIQFJAxfHH0m2sDw2uBr/M/8k4vLt8KSI8NIxidlZWDJ0DbjQKoLPomZZ4x W+xs5V7vvc1hC+YDBzLbH26zQeSLCal/XHWMyJe010xFfV5XGG6m7fqUz3Rj7EwZgpBf zUqr7BqBMCTystaBKh8YwSzSWFhuOq4EXOo3lcxSX+xo2QMtKHUd2GQRxCF9wcSl7OdN hlx13SYQmb6JFio4MRe4LIF8a8Eq5t3JjVdk4kYCksMaf9Aq2wCHt+dvZocbCcGiPsJK hdfRNgzv7oAw1QjCeN2mEuFYxdxAsPRZJ2kiSPRWd7+qZ/LyXWGdqmpTKUNQn5woURA1 LiBQ== MIME-Version: 1.0 Received: by 10.50.77.138 with SMTP id s10mr1053856igw.70.1349443301473; Fri, 05 Oct 2012 06:21:41 -0700 (PDT) Received: by 10.64.48.197 with HTTP; Fri, 5 Oct 2012 06:21:41 -0700 (PDT) In-Reply-To: <506EF935020000780009FFBC@nat28.tlf.novell.com> References: <506EEE39020000780009FF7F@nat28.tlf.novell.com> <506EF935020000780009FFBC@nat28.tlf.novell.com> Date: Fri, 5 Oct 2012 09:21:41 -0400 X-Google-Sender-Auth: JGuouGuMO4ALmowmxDLApTsuKto Message-ID: From: Ben Guthro To: Jan Beulich Cc: xen-devel Subject: Re: [Xen-devel] [PATCH] fix public header hvm/save.h to be compatible with c++ X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, Oct 5, 2012 at 9:13 AM, Jan Beulich wrote: >>>> On 05.10.12 at 14:46, Ben Guthro wrote: >> Thanks for your review. Comments addressed, and re-tested. > > But now I fail to see why the rename is still necessary I left the rename in there because you said you didn't mind them. I was unsure if this meant you preferred the rename, or not. In the interest of minimizing code churn to just the minimum - the ifdef would be sufficient. However, since you suggested I also fix the spacing around the equal signs, I thought that the variable rename was in the same category, for "code cleanup" I think this is just a misunderstanding. Would you like to see a third patch with just the ifdef? Also - as a matter of procedure, should I reply to this original thread when iterating on a patch like this, or start a new one, with [PATCH v2] etc? > - you don't write hypervisor code in C++, do you? *shudders at the though* - no, most certainly not. This is someone else's userspace daemon that I'm just integrating with new public headers built against xen-unstable Ben > Jan > >> Including save.h in a C++ application was throwing some errors, as it >> was unhappy about the "new" keyword being used (even when wrapped in >> an "extern C" block) >> >> This change renames some variables, as well as wraps the function in a >> __XEN__ preprocessor directive. >> >> Signed-off-by: Ben Guthro >> >> diff --git a/xen/include/public/arch-x86/hvm/save.h >> b/xen/include/public/arch-x86/hvm/save.h >> index a82a5ee..1b88c28 100644 >> --- a/xen/include/public/arch-x86/hvm/save.h >> +++ b/xen/include/public/arch-x86/hvm/save.h >> @@ -268,19 +268,21 @@ struct hvm_hw_cpu_compat { >> uint32_t error_code; >> }; >> >> +#ifdef __XEN__ >> static inline int _hvm_hw_fix_cpu(void *h) { >> - struct hvm_hw_cpu *new=h; >> - struct hvm_hw_cpu_compat *old=h; >> + struct hvm_hw_cpu *new_cpu = h; >> + struct hvm_hw_cpu_compat *old_cpu = h; >> >> /* If we copy from the end backwards, we should >> * be able to do the modification in-place */ >> - new->error_code=old->error_code; >> - new->pending_event=old->pending_event; >> - new->tsc=old->tsc; >> - new->msr_tsc_aux=0; >> + new_cpu->error_code = old_cpu->error_code; >> + new_cpu->pending_event = old_cpu->pending_event; >> + new_cpu->tsc = old_cpu->tsc; >> + new_cpu->msr_tsc_aux = 0; >> >> return 0; >> } >> +#endif >> >> DECLARE_HVM_SAVE_TYPE_COMPAT(CPU, 2, struct hvm_hw_cpu, \ >> struct hvm_hw_cpu_compat, _hvm_hw_fix_cpu); > > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 13:21:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:21:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7qb-0004XC-Sh; Fri, 05 Oct 2012 13:21:45 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7qa-0004Ww-Nv for xen-devel@lists.xen.org; Fri, 05 Oct 2012 13:21:44 +0000 Received: from [85.158.137.99:60019] by server-14.bemta-3.messagelabs.com id 62/C9-19528-7EEDE605; Fri, 05 Oct 2012 13:21:43 +0000 X-Env-Sender: ben.guthro@gmail.com X-Msg-Ref: server-10.tower-217.messagelabs.com!1349443301!20309204!1 X-Originating-IP: [209.85.223.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18823 invoked from network); 5 Oct 2012 13:21:43 -0000 Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com) (209.85.223.173) by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 13:21:43 -0000 Received: by mail-ie0-f173.google.com with SMTP id 17so4775365iea.32 for ; Fri, 05 Oct 2012 06:21:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=l5Bn+npDldR4SzZve1EHg3gquUAGWuT5zj6u6EhH5c8=; b=WUNyoonFIQFJAxfHH0m2sDw2uBr/M/8k4vLt8KSI8NIxidlZWDJ0DbjQKoLPomZZ4x W+xs5V7vvc1hC+YDBzLbH26zQeSLCal/XHWMyJe010xFfV5XGG6m7fqUz3Rj7EwZgpBf zUqr7BqBMCTystaBKh8YwSzSWFhuOq4EXOo3lcxSX+xo2QMtKHUd2GQRxCF9wcSl7OdN hlx13SYQmb6JFio4MRe4LIF8a8Eq5t3JjVdk4kYCksMaf9Aq2wCHt+dvZocbCcGiPsJK hdfRNgzv7oAw1QjCeN2mEuFYxdxAsPRZJ2kiSPRWd7+qZ/LyXWGdqmpTKUNQn5woURA1 LiBQ== MIME-Version: 1.0 Received: by 10.50.77.138 with SMTP id s10mr1053856igw.70.1349443301473; Fri, 05 Oct 2012 06:21:41 -0700 (PDT) Received: by 10.64.48.197 with HTTP; Fri, 5 Oct 2012 06:21:41 -0700 (PDT) In-Reply-To: <506EF935020000780009FFBC@nat28.tlf.novell.com> References: <506EEE39020000780009FF7F@nat28.tlf.novell.com> <506EF935020000780009FFBC@nat28.tlf.novell.com> Date: Fri, 5 Oct 2012 09:21:41 -0400 X-Google-Sender-Auth: JGuouGuMO4ALmowmxDLApTsuKto Message-ID: From: Ben Guthro To: Jan Beulich Cc: xen-devel Subject: Re: [Xen-devel] [PATCH] fix public header hvm/save.h to be compatible with c++ X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, Oct 5, 2012 at 9:13 AM, Jan Beulich wrote: >>>> On 05.10.12 at 14:46, Ben Guthro wrote: >> Thanks for your review. Comments addressed, and re-tested. > > But now I fail to see why the rename is still necessary I left the rename in there because you said you didn't mind them. I was unsure if this meant you preferred the rename, or not. In the interest of minimizing code churn to just the minimum - the ifdef would be sufficient. However, since you suggested I also fix the spacing around the equal signs, I thought that the variable rename was in the same category, for "code cleanup" I think this is just a misunderstanding. Would you like to see a third patch with just the ifdef? Also - as a matter of procedure, should I reply to this original thread when iterating on a patch like this, or start a new one, with [PATCH v2] etc? > - you don't write hypervisor code in C++, do you? *shudders at the though* - no, most certainly not. This is someone else's userspace daemon that I'm just integrating with new public headers built against xen-unstable Ben > Jan > >> Including save.h in a C++ application was throwing some errors, as it >> was unhappy about the "new" keyword being used (even when wrapped in >> an "extern C" block) >> >> This change renames some variables, as well as wraps the function in a >> __XEN__ preprocessor directive. >> >> Signed-off-by: Ben Guthro >> >> diff --git a/xen/include/public/arch-x86/hvm/save.h >> b/xen/include/public/arch-x86/hvm/save.h >> index a82a5ee..1b88c28 100644 >> --- a/xen/include/public/arch-x86/hvm/save.h >> +++ b/xen/include/public/arch-x86/hvm/save.h >> @@ -268,19 +268,21 @@ struct hvm_hw_cpu_compat { >> uint32_t error_code; >> }; >> >> +#ifdef __XEN__ >> static inline int _hvm_hw_fix_cpu(void *h) { >> - struct hvm_hw_cpu *new=h; >> - struct hvm_hw_cpu_compat *old=h; >> + struct hvm_hw_cpu *new_cpu = h; >> + struct hvm_hw_cpu_compat *old_cpu = h; >> >> /* If we copy from the end backwards, we should >> * be able to do the modification in-place */ >> - new->error_code=old->error_code; >> - new->pending_event=old->pending_event; >> - new->tsc=old->tsc; >> - new->msr_tsc_aux=0; >> + new_cpu->error_code = old_cpu->error_code; >> + new_cpu->pending_event = old_cpu->pending_event; >> + new_cpu->tsc = old_cpu->tsc; >> + new_cpu->msr_tsc_aux = 0; >> >> return 0; >> } >> +#endif >> >> DECLARE_HVM_SAVE_TYPE_COMPAT(CPU, 2, struct hvm_hw_cpu, \ >> struct hvm_hw_cpu_compat, _hvm_hw_fix_cpu); > > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 13:22:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:22:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7r7-0004cS-Aq; Fri, 05 Oct 2012 13:22:17 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7r5-0004bC-AJ for xen-devel@lists.xen.org; Fri, 05 Oct 2012 13:22:15 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1349443328!5905594!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28574 invoked from network); 5 Oct 2012 13:22:09 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 13:22:09 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14964077" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 13:22:08 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 14:22:08 +0100 Date: Fri, 5 Oct 2012 14:21:06 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Ian Campbell In-Reply-To: <1349363515-26190-12-git-send-email-ian.campbell@citrix.com> Message-ID: References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-12-git-send-email-ian.campbell@citrix.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: Stefano Stabellini , "xen-devel@lists.xen.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 12/14] arm: xen: explain the EXPERIMENTAL dependency in the Kconfig help X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 4 Oct 2012, Ian Campbell wrote: > Signed-off-by: Ian Campbell > --- > arch/arm/Kconfig | 8 ++++++++ > 1 files changed, 8 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 3361466..b171c46 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -1907,6 +1907,14 @@ config XEN > help > Say Y if you want to run Linux in a Virtual Machine on Xen on ARM. > > + > + This option is EXPERIMETNAL because the hypervisor ^ EXPERIMENTAL > + interfaces which it uses are not yet considered stable > + therefore backwards and forwards compatibility is not yet > + guaranteed. > + > + If unsure, say N. > + > endmenu > > menu "Boot options" > -- > 1.7.2.5 > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 13:22:28 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:22:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7r7-0004cS-Aq; Fri, 05 Oct 2012 13:22:17 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7r5-0004bC-AJ for xen-devel@lists.xen.org; Fri, 05 Oct 2012 13:22:15 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1349443328!5905594!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28574 invoked from network); 5 Oct 2012 13:22:09 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 13:22:09 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14964077" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 13:22:08 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 14:22:08 +0100 Date: Fri, 5 Oct 2012 14:21:06 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Ian Campbell In-Reply-To: <1349363515-26190-12-git-send-email-ian.campbell@citrix.com> Message-ID: References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-12-git-send-email-ian.campbell@citrix.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: Stefano Stabellini , "xen-devel@lists.xen.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 12/14] arm: xen: explain the EXPERIMENTAL dependency in the Kconfig help X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 4 Oct 2012, Ian Campbell wrote: > Signed-off-by: Ian Campbell > --- > arch/arm/Kconfig | 8 ++++++++ > 1 files changed, 8 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 3361466..b171c46 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -1907,6 +1907,14 @@ config XEN > help > Say Y if you want to run Linux in a Virtual Machine on Xen on ARM. > > + > + This option is EXPERIMETNAL because the hypervisor ^ EXPERIMENTAL > + interfaces which it uses are not yet considered stable > + therefore backwards and forwards compatibility is not yet > + guaranteed. > + > + If unsure, say N. > + > endmenu > > menu "Boot options" > -- > 1.7.2.5 > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 13:23:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:23:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7s6-0004mZ-QQ; Fri, 05 Oct 2012 13:23:18 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7s5-0004mE-Cb for xen-devel@lists.xen.org; Fri, 05 Oct 2012 13:23:17 +0000 Received: from [85.158.143.35:21456] by server-2.bemta-4.messagelabs.com id 62/0E-06610-44FDE605; Fri, 05 Oct 2012 13:23:16 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1349443395!13490577!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16405 invoked from network); 5 Oct 2012 13:23:16 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 13:23:16 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14964125" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 13:23:13 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 14:23:13 +0100 Date: Fri, 5 Oct 2012 14:22:12 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Ian Campbell In-Reply-To: <1349363515-26190-13-git-send-email-ian.campbell@citrix.com> Message-ID: References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-13-git-send-email-ian.campbell@citrix.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: Stefano Stabellini , "xen-devel@lists.xen.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 13/14] xen: use xen_pft_t in struct xen_remove_from_physmap X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 4 Oct 2012, Ian Campbell wrote: > 4a6c2b4 "PVH basic and hader file changes" and bd3f79b "xen: Introduce > xen_pfn_t for pfn and mfn types" passed like ships in the night. > > Signed-off-by: Ian Campbell Acked-by: Stefano Stabellini > include/xen/interface/memory.h | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h > index 6d74c47..d38bdc1 100644 > --- a/include/xen/interface/memory.h > +++ b/include/xen/interface/memory.h > @@ -258,7 +258,7 @@ struct xen_remove_from_physmap { > domid_t domid; > > /* GPFN of the current mapping of the page. */ > - unsigned long gpfn; > + xen_pfn_t gpfn; > }; > DEFINE_GUEST_HANDLE_STRUCT(xen_remove_from_physmap); > > -- > 1.7.2.5 > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 13:23:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:23:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7s6-0004mZ-QQ; Fri, 05 Oct 2012 13:23:18 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7s5-0004mE-Cb for xen-devel@lists.xen.org; Fri, 05 Oct 2012 13:23:17 +0000 Received: from [85.158.143.35:21456] by server-2.bemta-4.messagelabs.com id 62/0E-06610-44FDE605; Fri, 05 Oct 2012 13:23:16 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1349443395!13490577!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16405 invoked from network); 5 Oct 2012 13:23:16 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 13:23:16 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14964125" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 13:23:13 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 14:23:13 +0100 Date: Fri, 5 Oct 2012 14:22:12 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Ian Campbell In-Reply-To: <1349363515-26190-13-git-send-email-ian.campbell@citrix.com> Message-ID: References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-13-git-send-email-ian.campbell@citrix.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: Stefano Stabellini , "xen-devel@lists.xen.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 13/14] xen: use xen_pft_t in struct xen_remove_from_physmap X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 4 Oct 2012, Ian Campbell wrote: > 4a6c2b4 "PVH basic and hader file changes" and bd3f79b "xen: Introduce > xen_pfn_t for pfn and mfn types" passed like ships in the night. > > Signed-off-by: Ian Campbell Acked-by: Stefano Stabellini > include/xen/interface/memory.h | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h > index 6d74c47..d38bdc1 100644 > --- a/include/xen/interface/memory.h > +++ b/include/xen/interface/memory.h > @@ -258,7 +258,7 @@ struct xen_remove_from_physmap { > domid_t domid; > > /* GPFN of the current mapping of the page. */ > - unsigned long gpfn; > + xen_pfn_t gpfn; > }; > DEFINE_GUEST_HANDLE_STRUCT(xen_remove_from_physmap); > > -- > 1.7.2.5 > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 13:27:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:27:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7w2-000589-KD; Fri, 05 Oct 2012 13:27:22 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7w1-00057w-34 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 13:27:21 +0000 Received: from [85.158.143.35:23326] by server-2.bemta-4.messagelabs.com id 96/E3-06610-830EE605; Fri, 05 Oct 2012 13:27:20 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1349443637!17618914!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28522 invoked from network); 5 Oct 2012 13:27:18 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 13:27:18 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14964350" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 13:27:17 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 14:27:17 +0100 Message-ID: <1349443636.20946.96.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Daniel Kiper Date: Fri, 5 Oct 2012 14:27:16 +0100 In-Reply-To: <20121001113046.GA2942@host-192-168-1-59.local.net-space.pl> References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-2-git-send-email-daniel.kiper@oracle.com> <5065729C020000780009E63B@nat28.tlf.novell.com> <20121001113046.GA2942@host-192-168-1-59.local.net-space.pl> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: Andrew Cooper , xen-devel , "linux-kernel@vger.kernel.org" , Jan Beulich , "konrad.wilk@oracle.com" Subject: Re: [Xen-devel] [PATCH 01/11] kexec: introduce kexec_ops struct X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, 2012-10-01 at 12:36 +0100, Daniel Kiper wrote: > On Fri, Sep 28, 2012 at 08:49:16AM +0100, Jan Beulich wrote: > > >>> On 27.09.12 at 20:06, Daniel Kiper wrote: > > > Some kexec/kdump implementations (e.g. Xen PVOPS) on different archs could > > > not use default functions or require some changes in behavior of kexec/kdump > > > generic code. To cope with that problem kexec_ops struct was introduced. > > > It allows a developer to replace all or some functions and control some > > > functionality of kexec/kdump generic code. > > > > I'm not convinced that doing this at the architecture independent > > layer is really necessary/desirable. Nevertheless, if that's the right > > place, then everything else looks good to me, except for a > > cosmetic thing: > > I do not like this patch, too. However, this is the simplest > solution. If you do not do that in that way then you must > duplicate most of kernel/kexec.c functionality in architecture > depndent files. It would have been a good idea to CC the maintainer of those files directly with at least this patch if not the whole series. If they don't like this approach then there not much point in doing a thorough reviewing of the other 10 patches I don't think, since I would expect they will be required to change pretty substantially under those circumstances. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 13:27:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:27:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7w2-000589-KD; Fri, 05 Oct 2012 13:27:22 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7w1-00057w-34 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 13:27:21 +0000 Received: from [85.158.143.35:23326] by server-2.bemta-4.messagelabs.com id 96/E3-06610-830EE605; Fri, 05 Oct 2012 13:27:20 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1349443637!17618914!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28522 invoked from network); 5 Oct 2012 13:27:18 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 13:27:18 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14964350" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 13:27:17 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 14:27:17 +0100 Message-ID: <1349443636.20946.96.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Daniel Kiper Date: Fri, 5 Oct 2012 14:27:16 +0100 In-Reply-To: <20121001113046.GA2942@host-192-168-1-59.local.net-space.pl> References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com> <1348769198-29580-2-git-send-email-daniel.kiper@oracle.com> <5065729C020000780009E63B@nat28.tlf.novell.com> <20121001113046.GA2942@host-192-168-1-59.local.net-space.pl> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: Andrew Cooper , xen-devel , "linux-kernel@vger.kernel.org" , Jan Beulich , "konrad.wilk@oracle.com" Subject: Re: [Xen-devel] [PATCH 01/11] kexec: introduce kexec_ops struct X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Mon, 2012-10-01 at 12:36 +0100, Daniel Kiper wrote: > On Fri, Sep 28, 2012 at 08:49:16AM +0100, Jan Beulich wrote: > > >>> On 27.09.12 at 20:06, Daniel Kiper wrote: > > > Some kexec/kdump implementations (e.g. Xen PVOPS) on different archs could > > > not use default functions or require some changes in behavior of kexec/kdump > > > generic code. To cope with that problem kexec_ops struct was introduced. > > > It allows a developer to replace all or some functions and control some > > > functionality of kexec/kdump generic code. > > > > I'm not convinced that doing this at the architecture independent > > layer is really necessary/desirable. Nevertheless, if that's the right > > place, then everything else looks good to me, except for a > > cosmetic thing: > > I do not like this patch, too. However, this is the simplest > solution. If you do not do that in that way then you must > duplicate most of kernel/kexec.c functionality in architecture > depndent files. It would have been a good idea to CC the maintainer of those files directly with at least this patch if not the whole series. If they don't like this approach then there not much point in doing a thorough reviewing of the other 10 patches I don't think, since I would expect they will be required to change pretty substantially under those circumstances. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 13:30:07 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:30:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7yX-0005HN-6C; Fri, 05 Oct 2012 13:29:57 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7yV-0005HH-BI for xen-devel@lists.xen.org; Fri, 05 Oct 2012 13:29:55 +0000 Received: from [85.158.138.51:18312] by server-13.bemta-3.messagelabs.com id A9/67-28885-2D0EE605; Fri, 05 Oct 2012 13:29:54 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1349443793!33195536!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6117 invoked from network); 5 Oct 2012 13:29:54 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 13:29:54 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14964430" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 13:29:53 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 14:29:53 +0100 Message-ID: <1349443792.20946.97.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Fri, 5 Oct 2012 14:29:52 +0100 In-Reply-To: References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-12-git-send-email-ian.campbell@citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 12/14] arm: xen: explain the EXPERIMENTAL dependency in the Kconfig help X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-10-05 at 14:21 +0100, Stefano Stabellini wrote: > On Thu, 4 Oct 2012, Ian Campbell wrote: > > Signed-off-by: Ian Campbell > > --- > > arch/arm/Kconfig | 8 ++++++++ > > 1 files changed, 8 insertions(+), 0 deletions(-) > > > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > > index 3361466..b171c46 100644 > > --- a/arch/arm/Kconfig > > +++ b/arch/arm/Kconfig > > @@ -1907,6 +1907,14 @@ config XEN > > help > > Say Y if you want to run Linux in a Virtual Machine on Xen on ARM. > > > > + > > + This option is EXPERIMETNAL because the hypervisor > ^ EXPERIMENTAL Fixed, thanks. > > + interfaces which it uses are not yet considered stable > > + therefore backwards and forwards compatibility is not yet > > + guaranteed. > > + > > + If unsure, say N. > > + > > endmenu > > > > menu "Boot options" > > -- > > 1.7.2.5 > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 13:30:07 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:30:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7yX-0005HN-6C; Fri, 05 Oct 2012 13:29:57 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK7yV-0005HH-BI for xen-devel@lists.xen.org; Fri, 05 Oct 2012 13:29:55 +0000 Received: from [85.158.138.51:18312] by server-13.bemta-3.messagelabs.com id A9/67-28885-2D0EE605; Fri, 05 Oct 2012 13:29:54 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1349443793!33195536!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6117 invoked from network); 5 Oct 2012 13:29:54 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 13:29:54 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14964430" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 13:29:53 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 14:29:53 +0100 Message-ID: <1349443792.20946.97.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Fri, 5 Oct 2012 14:29:52 +0100 In-Reply-To: References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-12-git-send-email-ian.campbell@citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 12/14] arm: xen: explain the EXPERIMENTAL dependency in the Kconfig help X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-10-05 at 14:21 +0100, Stefano Stabellini wrote: > On Thu, 4 Oct 2012, Ian Campbell wrote: > > Signed-off-by: Ian Campbell > > --- > > arch/arm/Kconfig | 8 ++++++++ > > 1 files changed, 8 insertions(+), 0 deletions(-) > > > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > > index 3361466..b171c46 100644 > > --- a/arch/arm/Kconfig > > +++ b/arch/arm/Kconfig > > @@ -1907,6 +1907,14 @@ config XEN > > help > > Say Y if you want to run Linux in a Virtual Machine on Xen on ARM. > > > > + > > + This option is EXPERIMETNAL because the hypervisor > ^ EXPERIMENTAL Fixed, thanks. > > + interfaces which it uses are not yet considered stable > > + therefore backwards and forwards compatibility is not yet > > + guaranteed. > > + > > + If unsure, say N. > > + > > endmenu > > > > menu "Boot options" > > -- > > 1.7.2.5 > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 13:33:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:33:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK81b-0005Ty-PB; Fri, 05 Oct 2012 13:33:07 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK81Z-0005Tb-Re for xen-devel@lists.xen.org; Fri, 05 Oct 2012 13:33:06 +0000 Received: from [85.158.139.211:41222] by server-12.bemta-5.messagelabs.com id 9B/51-19095-091EE605; Fri, 05 Oct 2012 13:33:04 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-10.tower-206.messagelabs.com!1349443984!21185981!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 514 invoked from network); 5 Oct 2012 13:33:04 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 13:33:04 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14964552" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 13:33:04 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 14:33:04 +0100 Message-ID: <1349443982.20946.100.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Fri, 5 Oct 2012 14:33:02 +0100 In-Reply-To: References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-8-git-send-email-ian.campbell@citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 08/14] xen: balloon: allow PVMMU interfaces to be compiled out X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-10-05 at 14:19 +0100, Stefano Stabellini wrote: > On Thu, 4 Oct 2012, Ian Campbell wrote: > > The ARM platform has no concept of PVMMU and therefor no > > HYPERVISOR_update_va_mapping et al. Allow this code to be compiled out > > when not required. > > > > Signed-off-by: Ian Campbell > > I am unsure whether it is worth a new symbol and two ifdef's ARM doesn't compile without it, since HYPERVISOR_update_va_mapping doesn't exist. Do you have a preferable alternative? I'm not sure how much more of this sort of thing there will be as we enable more features on the ARM port. > > > > arch/x86/xen/Kconfig | 1 + > > drivers/xen/Kconfig | 3 +++ > > drivers/xen/balloon.c | 4 ++++ > > 3 files changed, 8 insertions(+), 0 deletions(-) > > > > diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig > > index fdce49c..c31ee77 100644 > > --- a/arch/x86/xen/Kconfig > > +++ b/arch/x86/xen/Kconfig > > @@ -6,6 +6,7 @@ config XEN > > bool "Xen guest support" > > select PARAVIRT > > select PARAVIRT_CLOCK > > + select XEN_HAVE_PVMMU > > depends on X86_64 || (X86_32 && X86_PAE && !X86_VISWS) > > depends on X86_CMPXCHG && X86_TSC > > help > > diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig > > index d4dffcd..9c00652 100644 > > --- a/drivers/xen/Kconfig > > +++ b/drivers/xen/Kconfig > > @@ -204,4 +204,7 @@ config XEN_MCE_LOG > > Allow kernel fetching MCE error from Xen platform and > > converting it into Linux mcelog format for mcelog tools > > > > +config XEN_HAVE_PVMMU > > + bool > > + > > endmenu > > diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c > > index 1b56ae0..cfe47dae 100644 > > --- a/drivers/xen/balloon.c > > +++ b/drivers/xen/balloon.c > > @@ -360,6 +360,7 @@ static enum bp_state increase_reservation(unsigned long nr_pages) > > if (!xen_feature(XENFEAT_auto_translated_physmap)) > > set_phys_to_machine(pfn, frame_list[i]); > > > > +#ifdef CONFIG_XEN_HAVE_PVMMU > > /* Link back into the page tables if not highmem. */ > > if (xen_pv_domain() && !PageHighMem(page) && > > !xen_feature(XENFEAT_auto_translated_physmap)) { > > @@ -371,6 +372,7 @@ static enum bp_state increase_reservation(unsigned long nr_pages) > > 0); > > BUG_ON(ret); > > } > > +#endif > > > > /* Relinquish the page back to the allocator. */ > > ClearPageReserved(page); > > @@ -419,6 +421,7 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp) > > > > scrub_page(page); > > > > +#ifdef CONFIG_XEN_HAVE_PVMMU > > if (xen_pv_domain() && !PageHighMem(page) && > > !xen_feature(XENFEAT_auto_translated_physmap)) { > > ret = HYPERVISOR_update_va_mapping( > > @@ -426,6 +429,7 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp) > > __pte_ma(0), 0); > > BUG_ON(ret); > > } > > +#endif > > } > > > > /* Ensure that ballooned highmem pages don't have kmaps. */ > > -- > > 1.7.2.5 > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 13:33:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:33:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK81b-0005Ty-PB; Fri, 05 Oct 2012 13:33:07 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK81Z-0005Tb-Re for xen-devel@lists.xen.org; Fri, 05 Oct 2012 13:33:06 +0000 Received: from [85.158.139.211:41222] by server-12.bemta-5.messagelabs.com id 9B/51-19095-091EE605; Fri, 05 Oct 2012 13:33:04 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-10.tower-206.messagelabs.com!1349443984!21185981!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 514 invoked from network); 5 Oct 2012 13:33:04 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 13:33:04 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14964552" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 13:33:04 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 14:33:04 +0100 Message-ID: <1349443982.20946.100.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Fri, 5 Oct 2012 14:33:02 +0100 In-Reply-To: References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-8-git-send-email-ian.campbell@citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 08/14] xen: balloon: allow PVMMU interfaces to be compiled out X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-10-05 at 14:19 +0100, Stefano Stabellini wrote: > On Thu, 4 Oct 2012, Ian Campbell wrote: > > The ARM platform has no concept of PVMMU and therefor no > > HYPERVISOR_update_va_mapping et al. Allow this code to be compiled out > > when not required. > > > > Signed-off-by: Ian Campbell > > I am unsure whether it is worth a new symbol and two ifdef's ARM doesn't compile without it, since HYPERVISOR_update_va_mapping doesn't exist. Do you have a preferable alternative? I'm not sure how much more of this sort of thing there will be as we enable more features on the ARM port. > > > > arch/x86/xen/Kconfig | 1 + > > drivers/xen/Kconfig | 3 +++ > > drivers/xen/balloon.c | 4 ++++ > > 3 files changed, 8 insertions(+), 0 deletions(-) > > > > diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig > > index fdce49c..c31ee77 100644 > > --- a/arch/x86/xen/Kconfig > > +++ b/arch/x86/xen/Kconfig > > @@ -6,6 +6,7 @@ config XEN > > bool "Xen guest support" > > select PARAVIRT > > select PARAVIRT_CLOCK > > + select XEN_HAVE_PVMMU > > depends on X86_64 || (X86_32 && X86_PAE && !X86_VISWS) > > depends on X86_CMPXCHG && X86_TSC > > help > > diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig > > index d4dffcd..9c00652 100644 > > --- a/drivers/xen/Kconfig > > +++ b/drivers/xen/Kconfig > > @@ -204,4 +204,7 @@ config XEN_MCE_LOG > > Allow kernel fetching MCE error from Xen platform and > > converting it into Linux mcelog format for mcelog tools > > > > +config XEN_HAVE_PVMMU > > + bool > > + > > endmenu > > diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c > > index 1b56ae0..cfe47dae 100644 > > --- a/drivers/xen/balloon.c > > +++ b/drivers/xen/balloon.c > > @@ -360,6 +360,7 @@ static enum bp_state increase_reservation(unsigned long nr_pages) > > if (!xen_feature(XENFEAT_auto_translated_physmap)) > > set_phys_to_machine(pfn, frame_list[i]); > > > > +#ifdef CONFIG_XEN_HAVE_PVMMU > > /* Link back into the page tables if not highmem. */ > > if (xen_pv_domain() && !PageHighMem(page) && > > !xen_feature(XENFEAT_auto_translated_physmap)) { > > @@ -371,6 +372,7 @@ static enum bp_state increase_reservation(unsigned long nr_pages) > > 0); > > BUG_ON(ret); > > } > > +#endif > > > > /* Relinquish the page back to the allocator. */ > > ClearPageReserved(page); > > @@ -419,6 +421,7 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp) > > > > scrub_page(page); > > > > +#ifdef CONFIG_XEN_HAVE_PVMMU > > if (xen_pv_domain() && !PageHighMem(page) && > > !xen_feature(XENFEAT_auto_translated_physmap)) { > > ret = HYPERVISOR_update_va_mapping( > > @@ -426,6 +429,7 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp) > > __pte_ma(0), 0); > > BUG_ON(ret); > > } > > +#endif > > } > > > > /* Ensure that ballooned highmem pages don't have kmaps. */ > > -- > > 1.7.2.5 > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 13:37:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:37:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK85b-0005hR-Fg; Fri, 05 Oct 2012 13:37:15 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK85Z-0005hG-TP for xen-devel@lists.xen.org; Fri, 05 Oct 2012 13:37:14 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1349444227!8887286!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21141 invoked from network); 5 Oct 2012 13:37:07 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 13:37:07 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14964673" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 13:37:06 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 14:37:06 +0100 Date: Fri, 5 Oct 2012 14:36:05 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Ian Campbell In-Reply-To: <1349363515-26190-11-git-send-email-ian.campbell@citrix.com> Message-ID: References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-11-git-send-email-ian.campbell@citrix.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: Stefano Stabellini , "xen-devel@lists.xen.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 11/14] arm: implement remap interfaces needed for privcmd mappings. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 4 Oct 2012, Ian Campbell wrote: > Signed-off-by: Ian Campbell > --- > arch/arm/xen/enlighten.c | 94 +++++++++++++++++++++++++++++++++++++++++++++- > 1 files changed, 92 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c > index ba5cc13..9956af5 100644 > --- a/arch/arm/xen/enlighten.c > +++ b/arch/arm/xen/enlighten.c > @@ -9,6 +9,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -18,6 +19,8 @@ > #include > #include > > +#include > + > struct start_info _xen_start_info; > struct start_info *xen_start_info = &_xen_start_info; > EXPORT_SYMBOL_GPL(xen_start_info); > @@ -43,15 +46,102 @@ EXPORT_SYMBOL_GPL(xen_platform_pci_unplug); > > static __read_mostly int xen_events_irq = -1; > > +/* map fgmfn of domid to lpfn in the current domain */ > +static int map_foreign_page(unsigned long lpfn, unsigned long fgmfn, > + unsigned int domid) > +{ > + int rc; > + struct xen_add_to_physmap xatp = { > + .domid = DOMID_SELF, > + .u.foreign_domid = domid, > + .space = XENMAPSPACE_gmfn_foreign, > + .idx = fgmfn, > + .gpfn = lpfn, > + }; > + > + rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp); > + if (rc) { > + pr_warn("Failed to map pfn to mfn rc:%d pfn:%lx mfn:%lx\n", > + rc, lpfn, fgmfn); > + return 1; > + } > + return 0; > +} > + > +struct remap_data { > + unsigned long fgmfn; /* foreign domain's gmfn */ > + pgprot_t prot; > + domid_t domid; > + struct vm_area_struct *vma; > + struct xen_remap_mfn_info *info; > +}; > + > +static int remap_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr, > + void *data) > +{ > + struct remap_data *info = data; > + struct xen_remap_mfn_info *savp = info->info; > + struct page *page = savp->pi_paga[savp->pi_next_todo++]; > + unsigned long pfn = page_to_pfn(page); > + pte_t pte = pfn_pte(pfn, info->prot); > + > + if (map_foreign_page(pfn, info->fgmfn, info->domid)) > + return -EFAULT; > + set_pte_at(info->vma->vm_mm, addr, ptep, pte); > + > + return 0; > +} > + > int xen_remap_domain_mfn_range(struct vm_area_struct *vma, > unsigned long addr, > unsigned long mfn, int nr, > - pgprot_t prot, unsigned domid) > + pgprot_t prot, unsigned domid, > + struct xen_remap_mfn_info *info) > { > - return -ENOSYS; > + int err; > + struct remap_data data; > + > + /* TBD: Batching, current sole caller only does page at a time */ > + if (nr > 1) > + return -EINVAL; It looks like that this implementation of xen_remap_domain_mfn_range is capable of handling nr > 1, so why this return -EINVAL? > + data.fgmfn = mfn; > + data.prot = prot; > + data.domid = domid; > + data.vma = vma; > + data.info = info; > + err = apply_to_page_range(vma->vm_mm, addr, nr << PAGE_SHIFT, > + remap_pte_fn, &data); > + return err; > } > EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range); > > +/* Returns: Number of pages unmapped */ > +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma, > + struct xen_remap_mfn_info *info) > +{ > + int count = 0; > + > + while (info->pi_next_todo--) { > + struct xen_remove_from_physmap xrp; > + unsigned long rc, pfn; > + > + pfn = page_to_pfn(info->pi_paga[info->pi_next_todo]); > + > + xrp.domid = DOMID_SELF; > + xrp.gpfn = pfn; > + rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, &xrp); > + if (rc) { > + pr_warn("Failed to unmap pfn:%lx rc:%ld\n", > + pfn, rc); > + return count; > + } > + count++; > + } > + return count; > +} > +EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range); > + > /* > * see Documentation/devicetree/bindings/arm/xen.txt for the > * documentation of the Xen Device Tree format. > -- > 1.7.2.5 > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 13:37:25 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:37:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK85b-0005hR-Fg; Fri, 05 Oct 2012 13:37:15 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK85Z-0005hG-TP for xen-devel@lists.xen.org; Fri, 05 Oct 2012 13:37:14 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1349444227!8887286!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21141 invoked from network); 5 Oct 2012 13:37:07 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 13:37:07 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14964673" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 13:37:06 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 14:37:06 +0100 Date: Fri, 5 Oct 2012 14:36:05 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Ian Campbell In-Reply-To: <1349363515-26190-11-git-send-email-ian.campbell@citrix.com> Message-ID: References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-11-git-send-email-ian.campbell@citrix.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: Stefano Stabellini , "xen-devel@lists.xen.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 11/14] arm: implement remap interfaces needed for privcmd mappings. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 4 Oct 2012, Ian Campbell wrote: > Signed-off-by: Ian Campbell > --- > arch/arm/xen/enlighten.c | 94 +++++++++++++++++++++++++++++++++++++++++++++- > 1 files changed, 92 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c > index ba5cc13..9956af5 100644 > --- a/arch/arm/xen/enlighten.c > +++ b/arch/arm/xen/enlighten.c > @@ -9,6 +9,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -18,6 +19,8 @@ > #include > #include > > +#include > + > struct start_info _xen_start_info; > struct start_info *xen_start_info = &_xen_start_info; > EXPORT_SYMBOL_GPL(xen_start_info); > @@ -43,15 +46,102 @@ EXPORT_SYMBOL_GPL(xen_platform_pci_unplug); > > static __read_mostly int xen_events_irq = -1; > > +/* map fgmfn of domid to lpfn in the current domain */ > +static int map_foreign_page(unsigned long lpfn, unsigned long fgmfn, > + unsigned int domid) > +{ > + int rc; > + struct xen_add_to_physmap xatp = { > + .domid = DOMID_SELF, > + .u.foreign_domid = domid, > + .space = XENMAPSPACE_gmfn_foreign, > + .idx = fgmfn, > + .gpfn = lpfn, > + }; > + > + rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp); > + if (rc) { > + pr_warn("Failed to map pfn to mfn rc:%d pfn:%lx mfn:%lx\n", > + rc, lpfn, fgmfn); > + return 1; > + } > + return 0; > +} > + > +struct remap_data { > + unsigned long fgmfn; /* foreign domain's gmfn */ > + pgprot_t prot; > + domid_t domid; > + struct vm_area_struct *vma; > + struct xen_remap_mfn_info *info; > +}; > + > +static int remap_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr, > + void *data) > +{ > + struct remap_data *info = data; > + struct xen_remap_mfn_info *savp = info->info; > + struct page *page = savp->pi_paga[savp->pi_next_todo++]; > + unsigned long pfn = page_to_pfn(page); > + pte_t pte = pfn_pte(pfn, info->prot); > + > + if (map_foreign_page(pfn, info->fgmfn, info->domid)) > + return -EFAULT; > + set_pte_at(info->vma->vm_mm, addr, ptep, pte); > + > + return 0; > +} > + > int xen_remap_domain_mfn_range(struct vm_area_struct *vma, > unsigned long addr, > unsigned long mfn, int nr, > - pgprot_t prot, unsigned domid) > + pgprot_t prot, unsigned domid, > + struct xen_remap_mfn_info *info) > { > - return -ENOSYS; > + int err; > + struct remap_data data; > + > + /* TBD: Batching, current sole caller only does page at a time */ > + if (nr > 1) > + return -EINVAL; It looks like that this implementation of xen_remap_domain_mfn_range is capable of handling nr > 1, so why this return -EINVAL? > + data.fgmfn = mfn; > + data.prot = prot; > + data.domid = domid; > + data.vma = vma; > + data.info = info; > + err = apply_to_page_range(vma->vm_mm, addr, nr << PAGE_SHIFT, > + remap_pte_fn, &data); > + return err; > } > EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range); > > +/* Returns: Number of pages unmapped */ > +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma, > + struct xen_remap_mfn_info *info) > +{ > + int count = 0; > + > + while (info->pi_next_todo--) { > + struct xen_remove_from_physmap xrp; > + unsigned long rc, pfn; > + > + pfn = page_to_pfn(info->pi_paga[info->pi_next_todo]); > + > + xrp.domid = DOMID_SELF; > + xrp.gpfn = pfn; > + rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, &xrp); > + if (rc) { > + pr_warn("Failed to unmap pfn:%lx rc:%ld\n", > + pfn, rc); > + return count; > + } > + count++; > + } > + return count; > +} > +EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range); > + > /* > * see Documentation/devicetree/bindings/arm/xen.txt for the > * documentation of the Xen Device Tree format. > -- > 1.7.2.5 > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 13:37:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:37:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK85u-0005jq-1C; Fri, 05 Oct 2012 13:37:34 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK85s-0005jX-7c for xen-devel@lists.xen.org; Fri, 05 Oct 2012 13:37:32 +0000 Received: from [85.158.139.211:50857] by server-4.bemta-5.messagelabs.com id 98/5A-20767-B92EE605; Fri, 05 Oct 2012 13:37:31 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-7.tower-206.messagelabs.com!1349444250!20766468!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29914 invoked from network); 5 Oct 2012 13:37:30 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 13:37:30 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14964679" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 13:37:29 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 14:37:30 +0100 Date: Fri, 5 Oct 2012 14:36:28 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Ian Campbell In-Reply-To: <1349363515-26190-14-git-send-email-ian.campbell@citrix.com> Message-ID: References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-14-git-send-email-ian.campbell@citrix.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: Stefano Stabellini , "xen-devel@lists.xen.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 14/14] arm: implement foreign mapping using XENMEM_add_to_physmap_range X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 4 Oct 2012, Ian Campbell wrote: > This interface is prefered for foreign mappings. So now we have XENMEM_add_to_physmap_range but we only have XENMEM_remove_from_physmap. Would it be worth to introduce a XENMEM_remove_from_physmap_range too? > Signed-off-by: Ian Campbell > --- > arch/arm/xen/enlighten.c | 14 +++++++++----- > include/xen/interface/memory.h | 18 ++++++++++++++++++ > 2 files changed, 27 insertions(+), 5 deletions(-) > > diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c > index 9956af5..a9946aa 100644 > --- a/arch/arm/xen/enlighten.c > +++ b/arch/arm/xen/enlighten.c > @@ -51,15 +51,19 @@ static int map_foreign_page(unsigned long lpfn, unsigned long fgmfn, > unsigned int domid) > { > int rc; > - struct xen_add_to_physmap xatp = { > + struct xen_add_to_physmap_range xatp = { > .domid = DOMID_SELF, > - .u.foreign_domid = domid, > + .foreign_domid = domid, > + .size = 1, > .space = XENMAPSPACE_gmfn_foreign, > - .idx = fgmfn, > - .gpfn = lpfn, > }; > + unsigned long idx = fgmfn; > + xen_pfn_t gpfn = lpfn; > > - rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp); > + set_xen_guest_handle(xatp.idxs, &idx); > + set_xen_guest_handle(xatp.gpfns, &gpfn); > + > + rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap_range, &xatp); > if (rc) { > pr_warn("Failed to map pfn to mfn rc:%d pfn:%lx mfn:%lx\n", > rc, lpfn, fgmfn); Wouldn't it make sense to call XENMEM_add_to_physmap_range only once for the whole range, rather than once per page? > diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h > index d38bdc1..e5675bc 100644 > --- a/include/xen/interface/memory.h > +++ b/include/xen/interface/memory.h > @@ -188,6 +188,24 @@ struct xen_add_to_physmap { > }; > DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_physmap); > > +#define XENMEM_add_to_physmap_range 23 > +struct xen_add_to_physmap_range { > + /* Which domain to change the mapping for. */ > + domid_t domid; > + uint16_t space; /* => enum phys_map_space */ > + > + /* Number of pages to go through */ > + uint16_t size; > + domid_t foreign_domid; /* IFF gmfn_foreign */ > + > + /* Indexes into space being mapped. */ > + GUEST_HANDLE(ulong) idxs; > + > + /* GPFN in domid where the source mapping page should appear. */ > + GUEST_HANDLE(xen_pfn_t) gpfns; > +}; > +DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_physmap_range); > + > /* > * Translates a list of domain-specific GPFNs into MFNs. Returns a -ve error > * code on failure. This call only works for auto-translated guests. > -- > 1.7.2.5 > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 13:37:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:37:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK85u-0005jq-1C; Fri, 05 Oct 2012 13:37:34 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK85s-0005jX-7c for xen-devel@lists.xen.org; Fri, 05 Oct 2012 13:37:32 +0000 Received: from [85.158.139.211:50857] by server-4.bemta-5.messagelabs.com id 98/5A-20767-B92EE605; Fri, 05 Oct 2012 13:37:31 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-7.tower-206.messagelabs.com!1349444250!20766468!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29914 invoked from network); 5 Oct 2012 13:37:30 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 13:37:30 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14964679" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 13:37:29 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 14:37:30 +0100 Date: Fri, 5 Oct 2012 14:36:28 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Ian Campbell In-Reply-To: <1349363515-26190-14-git-send-email-ian.campbell@citrix.com> Message-ID: References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-14-git-send-email-ian.campbell@citrix.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: Stefano Stabellini , "xen-devel@lists.xen.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 14/14] arm: implement foreign mapping using XENMEM_add_to_physmap_range X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 4 Oct 2012, Ian Campbell wrote: > This interface is prefered for foreign mappings. So now we have XENMEM_add_to_physmap_range but we only have XENMEM_remove_from_physmap. Would it be worth to introduce a XENMEM_remove_from_physmap_range too? > Signed-off-by: Ian Campbell > --- > arch/arm/xen/enlighten.c | 14 +++++++++----- > include/xen/interface/memory.h | 18 ++++++++++++++++++ > 2 files changed, 27 insertions(+), 5 deletions(-) > > diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c > index 9956af5..a9946aa 100644 > --- a/arch/arm/xen/enlighten.c > +++ b/arch/arm/xen/enlighten.c > @@ -51,15 +51,19 @@ static int map_foreign_page(unsigned long lpfn, unsigned long fgmfn, > unsigned int domid) > { > int rc; > - struct xen_add_to_physmap xatp = { > + struct xen_add_to_physmap_range xatp = { > .domid = DOMID_SELF, > - .u.foreign_domid = domid, > + .foreign_domid = domid, > + .size = 1, > .space = XENMAPSPACE_gmfn_foreign, > - .idx = fgmfn, > - .gpfn = lpfn, > }; > + unsigned long idx = fgmfn; > + xen_pfn_t gpfn = lpfn; > > - rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp); > + set_xen_guest_handle(xatp.idxs, &idx); > + set_xen_guest_handle(xatp.gpfns, &gpfn); > + > + rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap_range, &xatp); > if (rc) { > pr_warn("Failed to map pfn to mfn rc:%d pfn:%lx mfn:%lx\n", > rc, lpfn, fgmfn); Wouldn't it make sense to call XENMEM_add_to_physmap_range only once for the whole range, rather than once per page? > diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h > index d38bdc1..e5675bc 100644 > --- a/include/xen/interface/memory.h > +++ b/include/xen/interface/memory.h > @@ -188,6 +188,24 @@ struct xen_add_to_physmap { > }; > DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_physmap); > > +#define XENMEM_add_to_physmap_range 23 > +struct xen_add_to_physmap_range { > + /* Which domain to change the mapping for. */ > + domid_t domid; > + uint16_t space; /* => enum phys_map_space */ > + > + /* Number of pages to go through */ > + uint16_t size; > + domid_t foreign_domid; /* IFF gmfn_foreign */ > + > + /* Indexes into space being mapped. */ > + GUEST_HANDLE(ulong) idxs; > + > + /* GPFN in domid where the source mapping page should appear. */ > + GUEST_HANDLE(xen_pfn_t) gpfns; > +}; > +DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_physmap_range); > + > /* > * Translates a list of domain-specific GPFNs into MFNs. Returns a -ve error > * code on failure. This call only works for auto-translated guests. > -- > 1.7.2.5 > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 13:38:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:38:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK870-0005sb-Fj; Fri, 05 Oct 2012 13:38:42 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK86y-0005sT-Ij for xen-devel@lists.xen.org; Fri, 05 Oct 2012 13:38:40 +0000 Received: from [85.158.143.35:22811] by server-2.bemta-4.messagelabs.com id DE/7C-06610-FD2EE605; Fri, 05 Oct 2012 13:38:39 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1349444317!13185481!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1392 invoked from network); 5 Oct 2012 13:38:37 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 13:38:37 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14964722" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 13:38:36 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 14:38:37 +0100 Date: Fri, 5 Oct 2012 14:37:35 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Ian Campbell In-Reply-To: <1349363515-26190-10-git-send-email-ian.campbell@citrix.com> Message-ID: References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-10-git-send-email-ian.campbell@citrix.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: Stefano Stabellini , "xen-devel@lists.xen.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 10/14] privcmd: refer to autotranslate not PVH in arch interfaces / comments. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 4 Oct 2012, Ian Campbell wrote: > PVH is X86 specific while this functionality is also used on ARM. I really think that this should be merged with the orignal PVH patch > Signed-off-by: Ian Campbell > --- > arch/x86/xen/mmu.c | 10 +++++----- > drivers/xen/privcmd.c | 46 ++++++++++++++++++++++------------------------ > include/xen/xen-ops.h | 8 ++++---- > 3 files changed, 31 insertions(+), 33 deletions(-) > > diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c > index 26097cb..3e781f9 100644 > --- a/arch/x86/xen/mmu.c > +++ b/arch/x86/xen/mmu.c > @@ -2506,7 +2506,7 @@ struct pvh_remap_data { > unsigned long fgmfn; /* foreign domain's gmfn */ > pgprot_t prot; > domid_t domid; > - struct xen_pvh_pfn_info *pvhinfop; > + struct xen_remap_mfn_info *pvhinfop; > }; > > static int pvh_map_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr, > @@ -2514,7 +2514,7 @@ static int pvh_map_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr, > { > int rc; > struct pvh_remap_data *remapp = data; > - struct xen_pvh_pfn_info *pvhp = remapp->pvhinfop; > + struct xen_remap_mfn_info *pvhp = remapp->pvhinfop; > unsigned long pfn = page_to_pfn(pvhp->pi_paga[pvhp->pi_next_todo++]); > pte_t pteval = pte_mkspecial(pfn_pte(pfn, remapp->prot)); > > @@ -2531,7 +2531,7 @@ static int pvh_map_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr, > static int pvh_remap_gmfn_range(struct vm_area_struct *vma, > unsigned long addr, unsigned long mfn, int nr, > pgprot_t prot, unsigned domid, > - struct xen_pvh_pfn_info *pvhp) > + struct xen_remap_mfn_info *pvhp) > { > int err; > struct pvh_remap_data pvhdata; > @@ -2574,7 +2574,7 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma, > unsigned long addr, > unsigned long mfn, int nr, > pgprot_t prot, unsigned domid, > - struct xen_pvh_pfn_info *pvhp) > + struct xen_remap_mfn_info *pvhp) > > { > struct remap_data rmd; > @@ -2629,7 +2629,7 @@ EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range); > > /* Returns: Number of pages unmapped */ > int xen_unmap_domain_mfn_range(struct vm_area_struct *vma, > - struct xen_pvh_pfn_info *pvhp) > + struct xen_remap_mfn_info *pvhp) > { > int count = 0; > > diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c > index bf4d62a..ebf3c8d 100644 > --- a/drivers/xen/privcmd.c > +++ b/drivers/xen/privcmd.c > @@ -265,18 +265,16 @@ struct mmap_batch_state { > xen_pfn_t __user *user_mfn; > }; > > -/* PVH dom0 fyi: if domU being created is PV, then mfn is mfn(addr on bus). If > - * it's PVH then mfn is pfn (input to HAP). */ > static int mmap_batch_fn(void *data, void *state) > { > xen_pfn_t *mfnp = data; > struct mmap_batch_state *st = state; > struct vm_area_struct *vma = st->vma; > - struct xen_pvh_pfn_info *pvhp = vma ? vma->vm_private_data : NULL; > + struct xen_remap_mfn_info *info = vma ? vma->vm_private_data : NULL; > int ret; > > ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1, > - st->vma->vm_page_prot, st->domain, pvhp); > + st->vma->vm_page_prot, st->domain, info); > > /* Store error code for second pass. */ > *(st->err++) = ret; > @@ -315,33 +313,33 @@ static int mmap_return_errors_v1(void *data, void *state) > /* Allocate pfns that are then mapped with gmfns from foreign domid. Update > * the vma with the page info to use later. > * Returns: 0 if success, otherwise -errno > - */ > -static int pvh_privcmd_resv_pfns(struct vm_area_struct *vma, int numpgs) > + */ > +static int alloc_empty_pages(struct vm_area_struct *vma, int numpgs) > { > int rc; > - struct xen_pvh_pfn_info *pvhp; > + struct xen_remap_mfn_info *info; > > - pvhp = kzalloc(sizeof(struct xen_pvh_pfn_info), GFP_KERNEL); > - if (pvhp == NULL) > + info = kzalloc(sizeof(struct xen_remap_mfn_info), GFP_KERNEL); > + if (info == NULL) > return -ENOMEM; > > - pvhp->pi_paga = kcalloc(numpgs, sizeof(pvhp->pi_paga[0]), GFP_KERNEL); > - if (pvhp->pi_paga == NULL) { > - kfree(pvhp); > + info->pi_paga = kcalloc(numpgs, sizeof(info->pi_paga[0]), GFP_KERNEL); > + if (info->pi_paga == NULL) { > + kfree(info); > return -ENOMEM; > } > > - rc = alloc_xenballooned_pages(numpgs, pvhp->pi_paga, 0); > + rc = alloc_xenballooned_pages(numpgs, info->pi_paga, 0); > if (rc != 0) { > pr_warn("%s Could not alloc %d pfns rc:%d\n", __FUNCTION__, > numpgs, rc); > - kfree(pvhp->pi_paga); > - kfree(pvhp); > + kfree(info->pi_paga); > + kfree(info); > return -ENOMEM; > } > - pvhp->pi_num_pgs = numpgs; > + info->pi_num_pgs = numpgs; > BUG_ON(vma->vm_private_data != (void *)1); > - vma->vm_private_data = pvhp; > + vma->vm_private_data = info; > > return 0; > } > @@ -414,7 +412,7 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version) > goto out; > } > if (xen_feature(XENFEAT_auto_translated_physmap)) { > - if ((ret = pvh_privcmd_resv_pfns(vma, m.num))) { > + if ((ret = alloc_empty_pages(vma, m.num))) { > up_write(&mm->mmap_sem); > goto out; > } > @@ -490,16 +488,16 @@ static long privcmd_ioctl(struct file *file, > static void privcmd_close(struct vm_area_struct *vma) > { > int count; > - struct xen_pvh_pfn_info *pvhp = vma ? vma->vm_private_data : NULL; > + struct xen_remap_mfn_info *info = vma ? vma->vm_private_data : NULL; > > - if (!pvhp || !xen_feature(XENFEAT_auto_translated_physmap)) > + if (!info || !xen_feature(XENFEAT_auto_translated_physmap)) > return; > > - count = xen_unmap_domain_mfn_range(vma, pvhp); > + count = xen_unmap_domain_mfn_range(vma, info); > while (count--) > - free_xenballooned_pages(1, &pvhp->pi_paga[count]); > - kfree(pvhp->pi_paga); > - kfree(pvhp); > + free_xenballooned_pages(1, &info->pi_paga[count]); > + kfree(info->pi_paga); > + kfree(info); > } > > static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf) > diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h > index 6c5ad83..2f3cb06 100644 > --- a/include/xen/xen-ops.h > +++ b/include/xen/xen-ops.h > @@ -24,16 +24,16 @@ int xen_create_contiguous_region(unsigned long vstart, unsigned int order, > void xen_destroy_contiguous_region(unsigned long vstart, unsigned int order); > > struct vm_area_struct; > -struct xen_pvh_pfn_info; > +struct xen_remap_mfn_info; > int xen_remap_domain_mfn_range(struct vm_area_struct *vma, > unsigned long addr, > unsigned long mfn, int nr, > pgprot_t prot, unsigned domid, > - struct xen_pvh_pfn_info *pvhp); > + struct xen_remap_mfn_info *pvhp); > int xen_unmap_domain_mfn_range(struct vm_area_struct *vma, > - struct xen_pvh_pfn_info *pvhp); > + struct xen_remap_mfn_info *pvhp); > > -struct xen_pvh_pfn_info { > +struct xen_remap_mfn_info { > struct page **pi_paga; /* pfn info page array */ > int pi_num_pgs; > int pi_next_todo; > -- > 1.7.2.5 > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 13:38:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:38:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK870-0005sb-Fj; Fri, 05 Oct 2012 13:38:42 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK86y-0005sT-Ij for xen-devel@lists.xen.org; Fri, 05 Oct 2012 13:38:40 +0000 Received: from [85.158.143.35:22811] by server-2.bemta-4.messagelabs.com id DE/7C-06610-FD2EE605; Fri, 05 Oct 2012 13:38:39 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1349444317!13185481!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1392 invoked from network); 5 Oct 2012 13:38:37 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 13:38:37 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14964722" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 13:38:36 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 14:38:37 +0100 Date: Fri, 5 Oct 2012 14:37:35 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Ian Campbell In-Reply-To: <1349363515-26190-10-git-send-email-ian.campbell@citrix.com> Message-ID: References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-10-git-send-email-ian.campbell@citrix.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: Stefano Stabellini , "xen-devel@lists.xen.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 10/14] privcmd: refer to autotranslate not PVH in arch interfaces / comments. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, 4 Oct 2012, Ian Campbell wrote: > PVH is X86 specific while this functionality is also used on ARM. I really think that this should be merged with the orignal PVH patch > Signed-off-by: Ian Campbell > --- > arch/x86/xen/mmu.c | 10 +++++----- > drivers/xen/privcmd.c | 46 ++++++++++++++++++++++------------------------ > include/xen/xen-ops.h | 8 ++++---- > 3 files changed, 31 insertions(+), 33 deletions(-) > > diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c > index 26097cb..3e781f9 100644 > --- a/arch/x86/xen/mmu.c > +++ b/arch/x86/xen/mmu.c > @@ -2506,7 +2506,7 @@ struct pvh_remap_data { > unsigned long fgmfn; /* foreign domain's gmfn */ > pgprot_t prot; > domid_t domid; > - struct xen_pvh_pfn_info *pvhinfop; > + struct xen_remap_mfn_info *pvhinfop; > }; > > static int pvh_map_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr, > @@ -2514,7 +2514,7 @@ static int pvh_map_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr, > { > int rc; > struct pvh_remap_data *remapp = data; > - struct xen_pvh_pfn_info *pvhp = remapp->pvhinfop; > + struct xen_remap_mfn_info *pvhp = remapp->pvhinfop; > unsigned long pfn = page_to_pfn(pvhp->pi_paga[pvhp->pi_next_todo++]); > pte_t pteval = pte_mkspecial(pfn_pte(pfn, remapp->prot)); > > @@ -2531,7 +2531,7 @@ static int pvh_map_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr, > static int pvh_remap_gmfn_range(struct vm_area_struct *vma, > unsigned long addr, unsigned long mfn, int nr, > pgprot_t prot, unsigned domid, > - struct xen_pvh_pfn_info *pvhp) > + struct xen_remap_mfn_info *pvhp) > { > int err; > struct pvh_remap_data pvhdata; > @@ -2574,7 +2574,7 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma, > unsigned long addr, > unsigned long mfn, int nr, > pgprot_t prot, unsigned domid, > - struct xen_pvh_pfn_info *pvhp) > + struct xen_remap_mfn_info *pvhp) > > { > struct remap_data rmd; > @@ -2629,7 +2629,7 @@ EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range); > > /* Returns: Number of pages unmapped */ > int xen_unmap_domain_mfn_range(struct vm_area_struct *vma, > - struct xen_pvh_pfn_info *pvhp) > + struct xen_remap_mfn_info *pvhp) > { > int count = 0; > > diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c > index bf4d62a..ebf3c8d 100644 > --- a/drivers/xen/privcmd.c > +++ b/drivers/xen/privcmd.c > @@ -265,18 +265,16 @@ struct mmap_batch_state { > xen_pfn_t __user *user_mfn; > }; > > -/* PVH dom0 fyi: if domU being created is PV, then mfn is mfn(addr on bus). If > - * it's PVH then mfn is pfn (input to HAP). */ > static int mmap_batch_fn(void *data, void *state) > { > xen_pfn_t *mfnp = data; > struct mmap_batch_state *st = state; > struct vm_area_struct *vma = st->vma; > - struct xen_pvh_pfn_info *pvhp = vma ? vma->vm_private_data : NULL; > + struct xen_remap_mfn_info *info = vma ? vma->vm_private_data : NULL; > int ret; > > ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1, > - st->vma->vm_page_prot, st->domain, pvhp); > + st->vma->vm_page_prot, st->domain, info); > > /* Store error code for second pass. */ > *(st->err++) = ret; > @@ -315,33 +313,33 @@ static int mmap_return_errors_v1(void *data, void *state) > /* Allocate pfns that are then mapped with gmfns from foreign domid. Update > * the vma with the page info to use later. > * Returns: 0 if success, otherwise -errno > - */ > -static int pvh_privcmd_resv_pfns(struct vm_area_struct *vma, int numpgs) > + */ > +static int alloc_empty_pages(struct vm_area_struct *vma, int numpgs) > { > int rc; > - struct xen_pvh_pfn_info *pvhp; > + struct xen_remap_mfn_info *info; > > - pvhp = kzalloc(sizeof(struct xen_pvh_pfn_info), GFP_KERNEL); > - if (pvhp == NULL) > + info = kzalloc(sizeof(struct xen_remap_mfn_info), GFP_KERNEL); > + if (info == NULL) > return -ENOMEM; > > - pvhp->pi_paga = kcalloc(numpgs, sizeof(pvhp->pi_paga[0]), GFP_KERNEL); > - if (pvhp->pi_paga == NULL) { > - kfree(pvhp); > + info->pi_paga = kcalloc(numpgs, sizeof(info->pi_paga[0]), GFP_KERNEL); > + if (info->pi_paga == NULL) { > + kfree(info); > return -ENOMEM; > } > > - rc = alloc_xenballooned_pages(numpgs, pvhp->pi_paga, 0); > + rc = alloc_xenballooned_pages(numpgs, info->pi_paga, 0); > if (rc != 0) { > pr_warn("%s Could not alloc %d pfns rc:%d\n", __FUNCTION__, > numpgs, rc); > - kfree(pvhp->pi_paga); > - kfree(pvhp); > + kfree(info->pi_paga); > + kfree(info); > return -ENOMEM; > } > - pvhp->pi_num_pgs = numpgs; > + info->pi_num_pgs = numpgs; > BUG_ON(vma->vm_private_data != (void *)1); > - vma->vm_private_data = pvhp; > + vma->vm_private_data = info; > > return 0; > } > @@ -414,7 +412,7 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version) > goto out; > } > if (xen_feature(XENFEAT_auto_translated_physmap)) { > - if ((ret = pvh_privcmd_resv_pfns(vma, m.num))) { > + if ((ret = alloc_empty_pages(vma, m.num))) { > up_write(&mm->mmap_sem); > goto out; > } > @@ -490,16 +488,16 @@ static long privcmd_ioctl(struct file *file, > static void privcmd_close(struct vm_area_struct *vma) > { > int count; > - struct xen_pvh_pfn_info *pvhp = vma ? vma->vm_private_data : NULL; > + struct xen_remap_mfn_info *info = vma ? vma->vm_private_data : NULL; > > - if (!pvhp || !xen_feature(XENFEAT_auto_translated_physmap)) > + if (!info || !xen_feature(XENFEAT_auto_translated_physmap)) > return; > > - count = xen_unmap_domain_mfn_range(vma, pvhp); > + count = xen_unmap_domain_mfn_range(vma, info); > while (count--) > - free_xenballooned_pages(1, &pvhp->pi_paga[count]); > - kfree(pvhp->pi_paga); > - kfree(pvhp); > + free_xenballooned_pages(1, &info->pi_paga[count]); > + kfree(info->pi_paga); > + kfree(info); > } > > static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf) > diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h > index 6c5ad83..2f3cb06 100644 > --- a/include/xen/xen-ops.h > +++ b/include/xen/xen-ops.h > @@ -24,16 +24,16 @@ int xen_create_contiguous_region(unsigned long vstart, unsigned int order, > void xen_destroy_contiguous_region(unsigned long vstart, unsigned int order); > > struct vm_area_struct; > -struct xen_pvh_pfn_info; > +struct xen_remap_mfn_info; > int xen_remap_domain_mfn_range(struct vm_area_struct *vma, > unsigned long addr, > unsigned long mfn, int nr, > pgprot_t prot, unsigned domid, > - struct xen_pvh_pfn_info *pvhp); > + struct xen_remap_mfn_info *pvhp); > int xen_unmap_domain_mfn_range(struct vm_area_struct *vma, > - struct xen_pvh_pfn_info *pvhp); > + struct xen_remap_mfn_info *pvhp); > > -struct xen_pvh_pfn_info { > +struct xen_remap_mfn_info { > struct page **pi_paga; /* pfn info page array */ > int pi_num_pgs; > int pi_next_todo; > -- > 1.7.2.5 > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 13:39:59 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:39:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK882-0005yk-UP; Fri, 05 Oct 2012 13:39:46 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK881-0005yZ-Oq for xen-devel@lists.xen.org; Fri, 05 Oct 2012 13:39:45 +0000 Received: from [85.158.137.99:45648] by server-3.bemta-3.messagelabs.com id 05/4F-25962-023EE605; Fri, 05 Oct 2012 13:39:44 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-2.tower-217.messagelabs.com!1349444384!20306475!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4483 invoked from network); 5 Oct 2012 13:39:44 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 13:39:44 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14964738" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 13:39:31 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 14:39:31 +0100 Message-ID: <1349444369.20946.101.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Fri, 5 Oct 2012 14:39:29 +0100 In-Reply-To: References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-10-git-send-email-ian.campbell@citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 10/14] privcmd: refer to autotranslate not PVH in arch interfaces / comments. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-10-05 at 14:37 +0100, Stefano Stabellini wrote: > On Thu, 4 Oct 2012, Ian Campbell wrote: > > PVH is X86 specific while this functionality is also used on ARM. > > I really think that this should be merged with the orignal PVH patch Agreed, I should have said as much. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 13:39:59 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:39:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK882-0005yk-UP; Fri, 05 Oct 2012 13:39:46 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK881-0005yZ-Oq for xen-devel@lists.xen.org; Fri, 05 Oct 2012 13:39:45 +0000 Received: from [85.158.137.99:45648] by server-3.bemta-3.messagelabs.com id 05/4F-25962-023EE605; Fri, 05 Oct 2012 13:39:44 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-2.tower-217.messagelabs.com!1349444384!20306475!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4483 invoked from network); 5 Oct 2012 13:39:44 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 13:39:44 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14964738" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 13:39:31 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 14:39:31 +0100 Message-ID: <1349444369.20946.101.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Fri, 5 Oct 2012 14:39:29 +0100 In-Reply-To: References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-10-git-send-email-ian.campbell@citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 10/14] privcmd: refer to autotranslate not PVH in arch interfaces / comments. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-10-05 at 14:37 +0100, Stefano Stabellini wrote: > On Thu, 4 Oct 2012, Ian Campbell wrote: > > PVH is X86 specific while this functionality is also used on ARM. > > I really think that this should be merged with the orignal PVH patch Agreed, I should have said as much. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 13:42:48 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:42:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8Ap-0006Fv-La; Fri, 05 Oct 2012 13:42:39 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8Ao-0006FP-A9 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 13:42:38 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1349444552!5908529!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32588 invoked from network); 5 Oct 2012 13:42:32 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 13:42:32 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14964826" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 13:42:32 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 14:42:32 +0100 Message-ID: <1349444550.20946.102.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Fri, 5 Oct 2012 14:42:30 +0100 In-Reply-To: References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-11-git-send-email-ian.campbell@citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 11/14] arm: implement remap interfaces needed for privcmd mappings. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-10-05 at 14:36 +0100, Stefano Stabellini wrote: [... snip dozens of pointless lines -- please trim your quotes...] > > - return -ENOSYS; > > + int err; > > + struct remap_data data; > > + > > + /* TBD: Batching, current sole caller only does page at a time */ > > + if (nr > 1) > > + return -EINVAL; > > It looks like that this implementation of xen_remap_domain_mfn_range is > capable of handling nr > 1, so why this return -EINVAL? Hrm, yes. I think I just blindly copied that from the pvh implementation. [...] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 13:42:48 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:42:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8Ap-0006Fv-La; Fri, 05 Oct 2012 13:42:39 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8Ao-0006FP-A9 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 13:42:38 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1349444552!5908529!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32588 invoked from network); 5 Oct 2012 13:42:32 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 13:42:32 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14964826" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 13:42:32 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 14:42:32 +0100 Message-ID: <1349444550.20946.102.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Fri, 5 Oct 2012 14:42:30 +0100 In-Reply-To: References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-11-git-send-email-ian.campbell@citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 11/14] arm: implement remap interfaces needed for privcmd mappings. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-10-05 at 14:36 +0100, Stefano Stabellini wrote: [... snip dozens of pointless lines -- please trim your quotes...] > > - return -ENOSYS; > > + int err; > > + struct remap_data data; > > + > > + /* TBD: Batching, current sole caller only does page at a time */ > > + if (nr > 1) > > + return -EINVAL; > > It looks like that this implementation of xen_remap_domain_mfn_range is > capable of handling nr > 1, so why this return -EINVAL? Hrm, yes. I think I just blindly copied that from the pvh implementation. [...] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 13:45:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:45:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8Cz-0006Oh-B9; Fri, 05 Oct 2012 13:44:53 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8Cx-0006Oa-E9 for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 13:44:51 +0000 Received: from [85.158.138.51:14682] by server-5.bemta-3.messagelabs.com id DF/68-00589-254EE605; Fri, 05 Oct 2012 13:44:50 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1349444689!14549918!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4683 invoked from network); 5 Oct 2012 13:44:50 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 13:44:50 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14964886" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 13:44:31 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 14:44:31 +0100 Message-ID: <1349444670.20946.105.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Ian Jackson Date: Fri, 5 Oct 2012 14:44:30 +0100 In-Reply-To: <20581.58276.573643.315620@mariner.uk.xensource.com> References: <20581.58276.573643.315620@mariner.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v2] libxl/qemu-xen: use cache=writeback for IDE and SCSI X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-09-28 at 18:51 +0100, Ian Jackson wrote: > Stefano Stabellini writes ("[Xen-devel] [PATCH v2] libxl/qemu-xen: use cache=writeback for IDE and SCSI"): > > Change caching mode from writethrough to writeback for upstream QEMU. > > > > After a lengthy discussion, we came up with the conclusion that > > WRITEBACK is OK for IDE. > > See: http://marc.info/?l=xen-devel&m=133311527009773 > > > > Given that the same reasons apply to SCSI as well, change to writeback > > for SCSI too. > > Acked-by: Ian Jackson Acked + applied. Are the performance benefits of this patch worthy of a 4.2 backport, even though qemu-xen is not the default? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 13:45:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:45:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8Cz-0006Oh-B9; Fri, 05 Oct 2012 13:44:53 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8Cx-0006Oa-E9 for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 13:44:51 +0000 Received: from [85.158.138.51:14682] by server-5.bemta-3.messagelabs.com id DF/68-00589-254EE605; Fri, 05 Oct 2012 13:44:50 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1349444689!14549918!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4683 invoked from network); 5 Oct 2012 13:44:50 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 13:44:50 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14964886" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 13:44:31 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 14:44:31 +0100 Message-ID: <1349444670.20946.105.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Ian Jackson Date: Fri, 5 Oct 2012 14:44:30 +0100 In-Reply-To: <20581.58276.573643.315620@mariner.uk.xensource.com> References: <20581.58276.573643.315620@mariner.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v2] libxl/qemu-xen: use cache=writeback for IDE and SCSI X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-09-28 at 18:51 +0100, Ian Jackson wrote: > Stefano Stabellini writes ("[Xen-devel] [PATCH v2] libxl/qemu-xen: use cache=writeback for IDE and SCSI"): > > Change caching mode from writethrough to writeback for upstream QEMU. > > > > After a lengthy discussion, we came up with the conclusion that > > WRITEBACK is OK for IDE. > > See: http://marc.info/?l=xen-devel&m=133311527009773 > > > > Given that the same reasons apply to SCSI as well, change to writeback > > for SCSI too. > > Acked-by: Ian Jackson Acked + applied. Are the performance benefits of this patch worthy of a 4.2 backport, even though qemu-xen is not the default? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 13:45:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:45:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8DC-0006Qm-P3; Fri, 05 Oct 2012 13:45:06 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8DB-0006QS-O6 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 13:45:05 +0000 Received: from [85.158.143.35:15243] by server-2.bemta-4.messagelabs.com id 8D/D5-06610-164EE605; Fri, 05 Oct 2012 13:45:05 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1349444689!13494090!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27353 invoked from network); 5 Oct 2012 13:44:50 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 13:44:50 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14964885" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 13:44:28 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 14:44:28 +0100 Message-ID: <1349444666.20946.104.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Anthony PERARD Date: Fri, 5 Oct 2012 14:44:26 +0100 In-Reply-To: <1349427871-31195-1-git-send-email-anthony.perard@citrix.com> References: <1349427871-31195-1-git-send-email-anthony.perard@citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: Ian Jackson , Xen Devel Subject: Re: [Xen-devel] [PATCH V3 0/3] Cleanup: flexarray taking gc. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-10-05 at 10:04 +0100, Anthony PERARD wrote: > This two patches do a bit of cleanup in the memomy managment in libxl, > regarding the use of flexarray. Applied all 3 with IanJ's acks. Thanks. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 13:45:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:45:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8DC-0006Qm-P3; Fri, 05 Oct 2012 13:45:06 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8DB-0006QS-O6 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 13:45:05 +0000 Received: from [85.158.143.35:15243] by server-2.bemta-4.messagelabs.com id 8D/D5-06610-164EE605; Fri, 05 Oct 2012 13:45:05 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1349444689!13494090!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27353 invoked from network); 5 Oct 2012 13:44:50 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 13:44:50 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14964885" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 13:44:28 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 14:44:28 +0100 Message-ID: <1349444666.20946.104.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Anthony PERARD Date: Fri, 5 Oct 2012 14:44:26 +0100 In-Reply-To: <1349427871-31195-1-git-send-email-anthony.perard@citrix.com> References: <1349427871-31195-1-git-send-email-anthony.perard@citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: Ian Jackson , Xen Devel Subject: Re: [Xen-devel] [PATCH V3 0/3] Cleanup: flexarray taking gc. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-10-05 at 10:04 +0100, Anthony PERARD wrote: > This two patches do a bit of cleanup in the memomy managment in libxl, > regarding the use of flexarray. Applied all 3 with IanJ's acks. Thanks. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 13:45:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:45:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8DH-0006RZ-54; Fri, 05 Oct 2012 13:45:11 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8DG-0006QS-1K for xen-devel@lists.xen.org; Fri, 05 Oct 2012 13:45:10 +0000 Received: from [85.158.143.35:54383] by server-2.bemta-4.messagelabs.com id B8/F5-06610-564EE605; Fri, 05 Oct 2012 13:45:09 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1349444689!13494090!2 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27440 invoked from network); 5 Oct 2012 13:44:51 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 13:44:51 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14964890" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 13:44:39 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 14:44:39 +0100 Message-ID: <1349444677.20946.106.camel@zakaz.uk.xensource.com> From: Ian Campbell To: George Dunlap Date: Fri, 5 Oct 2012 14:44:37 +0100 In-Reply-To: <1349184995.650.54.camel@zakaz.uk.xensource.com> References: <1348765860-11359-1-git-send-email-matthew.fioravante@jhuapl.edu> <1348765860-11359-2-git-send-email-matthew.fioravante@jhuapl.edu> <1349184995.650.54.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: Matthew Fioravante , Ian Jackson , Jan Beulich , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 10/11] make devid a type so it is initialized properly X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-10-02 at 14:36 +0100, Ian Campbell wrote: > On Fri, 2012-09-28 at 14:23 +0100, George Dunlap wrote: > > On Thu, Sep 27, 2012 at 6:10 PM, Matthew Fioravante > > wrote: > > > Previously device ids in libxl were treated as integers meaning they > > > were being initialized to 0, which is a valid device id. This patch > > > makes devid its own type in libxl and initializes it to -1, an invalid > > > value. > > > > > > This fixes a bug where if you try to do a xl DEV-attach multiple > > > time it will continuously try to reattach device 0 instead of > > > generating a new device id. > > > > > > Signed-off-by: Matthew Fioravante > > > > Reviewed-by: George Dunlap > > Acked-by: Ian Campbell I've applied this. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 13:45:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:45:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8DH-0006RZ-54; Fri, 05 Oct 2012 13:45:11 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8DG-0006QS-1K for xen-devel@lists.xen.org; Fri, 05 Oct 2012 13:45:10 +0000 Received: from [85.158.143.35:54383] by server-2.bemta-4.messagelabs.com id B8/F5-06610-564EE605; Fri, 05 Oct 2012 13:45:09 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1349444689!13494090!2 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27440 invoked from network); 5 Oct 2012 13:44:51 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 13:44:51 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14964890" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 13:44:39 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 14:44:39 +0100 Message-ID: <1349444677.20946.106.camel@zakaz.uk.xensource.com> From: Ian Campbell To: George Dunlap Date: Fri, 5 Oct 2012 14:44:37 +0100 In-Reply-To: <1349184995.650.54.camel@zakaz.uk.xensource.com> References: <1348765860-11359-1-git-send-email-matthew.fioravante@jhuapl.edu> <1348765860-11359-2-git-send-email-matthew.fioravante@jhuapl.edu> <1349184995.650.54.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: Matthew Fioravante , Ian Jackson , Jan Beulich , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 10/11] make devid a type so it is initialized properly X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-10-02 at 14:36 +0100, Ian Campbell wrote: > On Fri, 2012-09-28 at 14:23 +0100, George Dunlap wrote: > > On Thu, Sep 27, 2012 at 6:10 PM, Matthew Fioravante > > wrote: > > > Previously device ids in libxl were treated as integers meaning they > > > were being initialized to 0, which is a valid device id. This patch > > > makes devid its own type in libxl and initializes it to -1, an invalid > > > value. > > > > > > This fixes a bug where if you try to do a xl DEV-attach multiple > > > time it will continuously try to reattach device 0 instead of > > > generating a new device id. > > > > > > Signed-off-by: Matthew Fioravante > > > > Reviewed-by: George Dunlap > > Acked-by: Ian Campbell I've applied this. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 13:49:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:49:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8HQ-0006sM-0j; Fri, 05 Oct 2012 13:49:28 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with smtp (Exim 4.72) (envelope-from ) id 1TK8HO-0006rx-MX for xen-devel@lists.xen.org; Fri, 05 Oct 2012 13:49:26 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1349444960!6611030!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6383 invoked from network); 5 Oct 2012 13:49:20 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-15.tower-27.messagelabs.com with SMTP; 5 Oct 2012 13:49:20 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 05 Oct 2012 14:49:20 +0100 Message-Id: <506F018002000078000A003A@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 05 Oct 2012 14:49:20 +0100 From: "Jan Beulich" To: "Ben Guthro" References: <506EEE39020000780009FF7F@nat28.tlf.novell.com> <506EF935020000780009FFBC@nat28.tlf.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel Subject: Re: [Xen-devel] [PATCH] fix public header hvm/save.h to be compatible with c++ X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 05.10.12 at 15:21, Ben Guthro wrote: > On Fri, Oct 5, 2012 at 9:13 AM, Jan Beulich wrote: >>>>> On 05.10.12 at 14:46, Ben Guthro wrote: >>> Thanks for your review. Comments addressed, and re-tested. >> >> But now I fail to see why the rename is still necessary > > I left the rename in there because you said you didn't mind them. > I was unsure if this meant you preferred the rename, or not. In the > interest of minimizing code churn to just the minimum - the ifdef > would be sufficient. > However, since you suggested I also fix the spacing around the equal > signs, I thought that the variable rename was in the same category, > for "code cleanup" > > I think this is just a misunderstanding. > > Would you like to see a third patch with just the ifdef? I'll leave that decision to Keir, as it's going to be him to apply (or at least ack) the change anyway. > Also - as a matter of procedure, should I reply to this original > thread when iterating on a patch like this, or start a new one, with > [PATCH v2] etc? Afaic, that's up to your preference. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 13:49:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:49:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8HQ-0006sM-0j; Fri, 05 Oct 2012 13:49:28 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with smtp (Exim 4.72) (envelope-from ) id 1TK8HO-0006rx-MX for xen-devel@lists.xen.org; Fri, 05 Oct 2012 13:49:26 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1349444960!6611030!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6383 invoked from network); 5 Oct 2012 13:49:20 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-15.tower-27.messagelabs.com with SMTP; 5 Oct 2012 13:49:20 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 05 Oct 2012 14:49:20 +0100 Message-Id: <506F018002000078000A003A@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 05 Oct 2012 14:49:20 +0100 From: "Jan Beulich" To: "Ben Guthro" References: <506EEE39020000780009FF7F@nat28.tlf.novell.com> <506EF935020000780009FFBC@nat28.tlf.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: xen-devel Subject: Re: [Xen-devel] [PATCH] fix public header hvm/save.h to be compatible with c++ X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 05.10.12 at 15:21, Ben Guthro wrote: > On Fri, Oct 5, 2012 at 9:13 AM, Jan Beulich wrote: >>>>> On 05.10.12 at 14:46, Ben Guthro wrote: >>> Thanks for your review. Comments addressed, and re-tested. >> >> But now I fail to see why the rename is still necessary > > I left the rename in there because you said you didn't mind them. > I was unsure if this meant you preferred the rename, or not. In the > interest of minimizing code churn to just the minimum - the ifdef > would be sufficient. > However, since you suggested I also fix the spacing around the equal > signs, I thought that the variable rename was in the same category, > for "code cleanup" > > I think this is just a misunderstanding. > > Would you like to see a third patch with just the ifdef? I'll leave that decision to Keir, as it's going to be him to apply (or at least ack) the change anyway. > Also - as a matter of procedure, should I reply to this original > thread when iterating on a patch like this, or start a new one, with > [PATCH v2] etc? Afaic, that's up to your preference. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 13:51:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:51:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8JZ-0006zw-I0; Fri, 05 Oct 2012 13:51:41 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8JX-0006zm-Vj for xen-devel@lists.xen.org; Fri, 05 Oct 2012 13:51:40 +0000 Received: from [85.158.143.99:17861] by server-2.bemta-4.messagelabs.com id 8D/1F-06610-BE5EE605; Fri, 05 Oct 2012 13:51:39 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1349445098!32670671!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29717 invoked from network); 5 Oct 2012 13:51:38 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 13:51:38 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14965096" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 13:51:38 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 14:51:38 +0100 Message-ID: <1349445097.20946.108.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Fri, 5 Oct 2012 14:51:37 +0100 In-Reply-To: References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-14-git-send-email-ian.campbell@citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 14/14] arm: implement foreign mapping using XENMEM_add_to_physmap_range X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-10-05 at 14:36 +0100, Stefano Stabellini wrote: > On Thu, 4 Oct 2012, Ian Campbell wrote: > > This interface is prefered for foreign mappings. > > So now we have XENMEM_add_to_physmap_range but we only have > XENMEM_remove_from_physmap. Would it be worth to introduce a > XENMEM_remove_from_physmap_range too? Worth considering but the need isn't so urgent since you wouldn't need to coexist with XENMAPSPACE_gmfn_range's size parameter and the foreign_domid one isn't needed either. I wonder if XENMEM_add_to_physmap_range ought to reject XENMAPSPACE_gmfn_range, just for the sake of sanity. > > > Signed-off-by: Ian Campbell > > --- > > arch/arm/xen/enlighten.c | 14 +++++++++----- > > include/xen/interface/memory.h | 18 ++++++++++++++++++ > > 2 files changed, 27 insertions(+), 5 deletions(-) > > > > diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c > > index 9956af5..a9946aa 100644 > > --- a/arch/arm/xen/enlighten.c > > +++ b/arch/arm/xen/enlighten.c > > @@ -51,15 +51,19 @@ static int map_foreign_page(unsigned long lpfn, unsigned long fgmfn, > > unsigned int domid) > > { > > int rc; > > - struct xen_add_to_physmap xatp = { > > + struct xen_add_to_physmap_range xatp = { > > .domid = DOMID_SELF, > > - .u.foreign_domid = domid, > > + .foreign_domid = domid, > > + .size = 1, > > .space = XENMAPSPACE_gmfn_foreign, > > - .idx = fgmfn, > > - .gpfn = lpfn, > > }; > > + unsigned long idx = fgmfn; > > + xen_pfn_t gpfn = lpfn; > > > > - rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp); > > + set_xen_guest_handle(xatp.idxs, &idx); > > + set_xen_guest_handle(xatp.gpfns, &gpfn); > > + > > + rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap_range, &xatp); > > if (rc) { > > pr_warn("Failed to map pfn to mfn rc:%d pfn:%lx mfn:%lx\n", > > rc, lpfn, fgmfn); > > Wouldn't it make sense to call XENMEM_add_to_physmap_range only once for > the whole range, rather than once per page? > > > > diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h > > index d38bdc1..e5675bc 100644 > > --- a/include/xen/interface/memory.h > > +++ b/include/xen/interface/memory.h > > @@ -188,6 +188,24 @@ struct xen_add_to_physmap { > > }; > > DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_physmap); > > > > +#define XENMEM_add_to_physmap_range 23 > > +struct xen_add_to_physmap_range { > > + /* Which domain to change the mapping for. */ > > + domid_t domid; > > + uint16_t space; /* => enum phys_map_space */ > > + > > + /* Number of pages to go through */ > > + uint16_t size; > > + domid_t foreign_domid; /* IFF gmfn_foreign */ > > + > > + /* Indexes into space being mapped. */ > > + GUEST_HANDLE(ulong) idxs; > > + > > + /* GPFN in domid where the source mapping page should appear. */ > > + GUEST_HANDLE(xen_pfn_t) gpfns; > > +}; > > +DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_physmap_range); > > + > > /* > > * Translates a list of domain-specific GPFNs into MFNs. Returns a -ve error > > * code on failure. This call only works for auto-translated guests. > > -- > > 1.7.2.5 > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 13:51:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:51:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8JZ-0006zw-I0; Fri, 05 Oct 2012 13:51:41 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8JX-0006zm-Vj for xen-devel@lists.xen.org; Fri, 05 Oct 2012 13:51:40 +0000 Received: from [85.158.143.99:17861] by server-2.bemta-4.messagelabs.com id 8D/1F-06610-BE5EE605; Fri, 05 Oct 2012 13:51:39 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1349445098!32670671!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29717 invoked from network); 5 Oct 2012 13:51:38 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 13:51:38 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14965096" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 13:51:38 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 14:51:38 +0100 Message-ID: <1349445097.20946.108.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Fri, 5 Oct 2012 14:51:37 +0100 In-Reply-To: References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-14-git-send-email-ian.campbell@citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 14/14] arm: implement foreign mapping using XENMEM_add_to_physmap_range X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-10-05 at 14:36 +0100, Stefano Stabellini wrote: > On Thu, 4 Oct 2012, Ian Campbell wrote: > > This interface is prefered for foreign mappings. > > So now we have XENMEM_add_to_physmap_range but we only have > XENMEM_remove_from_physmap. Would it be worth to introduce a > XENMEM_remove_from_physmap_range too? Worth considering but the need isn't so urgent since you wouldn't need to coexist with XENMAPSPACE_gmfn_range's size parameter and the foreign_domid one isn't needed either. I wonder if XENMEM_add_to_physmap_range ought to reject XENMAPSPACE_gmfn_range, just for the sake of sanity. > > > Signed-off-by: Ian Campbell > > --- > > arch/arm/xen/enlighten.c | 14 +++++++++----- > > include/xen/interface/memory.h | 18 ++++++++++++++++++ > > 2 files changed, 27 insertions(+), 5 deletions(-) > > > > diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c > > index 9956af5..a9946aa 100644 > > --- a/arch/arm/xen/enlighten.c > > +++ b/arch/arm/xen/enlighten.c > > @@ -51,15 +51,19 @@ static int map_foreign_page(unsigned long lpfn, unsigned long fgmfn, > > unsigned int domid) > > { > > int rc; > > - struct xen_add_to_physmap xatp = { > > + struct xen_add_to_physmap_range xatp = { > > .domid = DOMID_SELF, > > - .u.foreign_domid = domid, > > + .foreign_domid = domid, > > + .size = 1, > > .space = XENMAPSPACE_gmfn_foreign, > > - .idx = fgmfn, > > - .gpfn = lpfn, > > }; > > + unsigned long idx = fgmfn; > > + xen_pfn_t gpfn = lpfn; > > > > - rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp); > > + set_xen_guest_handle(xatp.idxs, &idx); > > + set_xen_guest_handle(xatp.gpfns, &gpfn); > > + > > + rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap_range, &xatp); > > if (rc) { > > pr_warn("Failed to map pfn to mfn rc:%d pfn:%lx mfn:%lx\n", > > rc, lpfn, fgmfn); > > Wouldn't it make sense to call XENMEM_add_to_physmap_range only once for > the whole range, rather than once per page? > > > > diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h > > index d38bdc1..e5675bc 100644 > > --- a/include/xen/interface/memory.h > > +++ b/include/xen/interface/memory.h > > @@ -188,6 +188,24 @@ struct xen_add_to_physmap { > > }; > > DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_physmap); > > > > +#define XENMEM_add_to_physmap_range 23 > > +struct xen_add_to_physmap_range { > > + /* Which domain to change the mapping for. */ > > + domid_t domid; > > + uint16_t space; /* => enum phys_map_space */ > > + > > + /* Number of pages to go through */ > > + uint16_t size; > > + domid_t foreign_domid; /* IFF gmfn_foreign */ > > + > > + /* Indexes into space being mapped. */ > > + GUEST_HANDLE(ulong) idxs; > > + > > + /* GPFN in domid where the source mapping page should appear. */ > > + GUEST_HANDLE(xen_pfn_t) gpfns; > > +}; > > +DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_physmap_range); > > + > > /* > > * Translates a list of domain-specific GPFNs into MFNs. Returns a -ve error > > * code on failure. This call only works for auto-translated guests. > > -- > > 1.7.2.5 > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 13:54:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:54:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8Li-00077y-3d; Fri, 05 Oct 2012 13:53:54 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK89z-0006BS-7m for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 13:41:47 +0000 Received: from [85.158.139.83:12414] by server-5.bemta-5.messagelabs.com id 91/5E-21075-A93EE605; Fri, 05 Oct 2012 13:41:46 +0000 X-Env-Sender: fabio.fantoni@heliman.it X-Msg-Ref: server-2.tower-182.messagelabs.com!1349444505!30740114!1 X-Originating-IP: [209.85.214.43] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12303 invoked from network); 5 Oct 2012 13:41:45 -0000 Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com) (209.85.214.43) by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 13:41:45 -0000 Received: by mail-bk0-f43.google.com with SMTP id w5so1049280bku.30 for ; Fri, 05 Oct 2012 06:41:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-gm-message-state; bh=8xtQxQj7RZbaFNz/CJAlen0ar240uoe1YcXoi9ZaXzU=; b=KDztqsJHxy5L109RnslQC1dpyVwjBIpGm0R0kczNypp2C5+VtPpoLMMAaZjfMI0laU gzjr2an9Xv6HUj+1A26/hNynL2RxRfihgxpIRcG3PRM+YpwNTXArMcfDmd72MsrUelp3 BktbSopbMT09XGSvAKeMLgJURstzivgjAytbHskPcCKrZLCSA3dhlmXw9jRgcuiV7X1X RMk7JUmkTabQYZ2NNOc+TNLfhnmyGf8nB5AyzS46VZLY23/ymS41YOvQYe/oyPrVhQIj KVB/9y2n0k70u/X3sNMduKi/7vlZOK/M3mFl8iWhHOkG+klvses2vkkg/O8uz4FRmrwt kh4g== Received: by 10.204.145.85 with SMTP id c21mr2887363bkv.46.1349444505229; Fri, 05 Oct 2012 06:41:45 -0700 (PDT) Received: from [192.168.178.50] (host51-78-dynamic.2-87-r.retail.telecomitalia.it. [87.2.78.51]) by mx.google.com with ESMTPS id e13sm7739722bkw.12.2012.10.05.06.41.44 (version=SSLv3 cipher=OTHER); Fri, 05 Oct 2012 06:41:44 -0700 (PDT) Message-ID: <506EE392.3000707@heliman.it> Date: Fri, 05 Oct 2012 15:41:38 +0200 From: Fabio Fantoni User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: xen-devel X-Gm-Message-State: ALoCoQkWGwGbpVNXbj0vYVT07Sge18JUoYxt8ksnt+kXqWN2zcVf+278CdQQuYXHtfiasA0EhZ4B X-Mailman-Approved-At: Fri, 05 Oct 2012 13:53:52 +0000 Subject: [Xen-devel] Question about antispoofing and sys-flood protection on xen bridges X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org I'm in doubt about antispoofing and sys-flood protection on dom0 and their effect on xen bridges. Added these parameters on /etc/sysctl.conf: net.ipv4.conf.default.rp_filter=1 net.ipv4.conf.all.rp_filter=1 net.ipv4.tcp_syncookies=1 Can they give problem on xen bridges and/or its performance? Thanks for any reply _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 13:54:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:54:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8Li-00077y-3d; Fri, 05 Oct 2012 13:53:54 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK89z-0006BS-7m for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 13:41:47 +0000 Received: from [85.158.139.83:12414] by server-5.bemta-5.messagelabs.com id 91/5E-21075-A93EE605; Fri, 05 Oct 2012 13:41:46 +0000 X-Env-Sender: fabio.fantoni@heliman.it X-Msg-Ref: server-2.tower-182.messagelabs.com!1349444505!30740114!1 X-Originating-IP: [209.85.214.43] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12303 invoked from network); 5 Oct 2012 13:41:45 -0000 Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com) (209.85.214.43) by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 13:41:45 -0000 Received: by mail-bk0-f43.google.com with SMTP id w5so1049280bku.30 for ; Fri, 05 Oct 2012 06:41:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-gm-message-state; bh=8xtQxQj7RZbaFNz/CJAlen0ar240uoe1YcXoi9ZaXzU=; b=KDztqsJHxy5L109RnslQC1dpyVwjBIpGm0R0kczNypp2C5+VtPpoLMMAaZjfMI0laU gzjr2an9Xv6HUj+1A26/hNynL2RxRfihgxpIRcG3PRM+YpwNTXArMcfDmd72MsrUelp3 BktbSopbMT09XGSvAKeMLgJURstzivgjAytbHskPcCKrZLCSA3dhlmXw9jRgcuiV7X1X RMk7JUmkTabQYZ2NNOc+TNLfhnmyGf8nB5AyzS46VZLY23/ymS41YOvQYe/oyPrVhQIj KVB/9y2n0k70u/X3sNMduKi/7vlZOK/M3mFl8iWhHOkG+klvses2vkkg/O8uz4FRmrwt kh4g== Received: by 10.204.145.85 with SMTP id c21mr2887363bkv.46.1349444505229; Fri, 05 Oct 2012 06:41:45 -0700 (PDT) Received: from [192.168.178.50] (host51-78-dynamic.2-87-r.retail.telecomitalia.it. [87.2.78.51]) by mx.google.com with ESMTPS id e13sm7739722bkw.12.2012.10.05.06.41.44 (version=SSLv3 cipher=OTHER); Fri, 05 Oct 2012 06:41:44 -0700 (PDT) Message-ID: <506EE392.3000707@heliman.it> Date: Fri, 05 Oct 2012 15:41:38 +0200 From: Fabio Fantoni User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: xen-devel X-Gm-Message-State: ALoCoQkWGwGbpVNXbj0vYVT07Sge18JUoYxt8ksnt+kXqWN2zcVf+278CdQQuYXHtfiasA0EhZ4B X-Mailman-Approved-At: Fri, 05 Oct 2012 13:53:52 +0000 Subject: [Xen-devel] Question about antispoofing and sys-flood protection on xen bridges X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org I'm in doubt about antispoofing and sys-flood protection on dom0 and their effect on xen bridges. Added these parameters on /etc/sysctl.conf: net.ipv4.conf.default.rp_filter=1 net.ipv4.conf.all.rp_filter=1 net.ipv4.tcp_syncookies=1 Can they give problem on xen bridges and/or its performance? Thanks for any reply _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 13:55:27 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:55:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8N4-0007Ej-J4; Fri, 05 Oct 2012 13:55:18 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8N2-0007Ea-Bj for xen-devel@lists.xen.org; Fri, 05 Oct 2012 13:55:16 +0000 Received: from [85.158.139.211:27629] by server-7.bemta-5.messagelabs.com id 6B/FA-00431-3C6EE605; Fri, 05 Oct 2012 13:55:15 +0000 X-Env-Sender: Christoph.Egger@amd.com X-Msg-Ref: server-16.tower-206.messagelabs.com!1349445314!21257732!1 X-Originating-IP: [213.199.154.207] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22179 invoked from network); 5 Oct 2012 13:55:14 -0000 Received: from am1ehsobe004.messaging.microsoft.com (HELO am1outboundpool.messaging.microsoft.com) (213.199.154.207) by server-16.tower-206.messagelabs.com with AES128-SHA encrypted SMTP; 5 Oct 2012 13:55:14 -0000 Received: from mail113-am1-R.bigfish.com (10.3.201.233) by AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id 14.1.225.23; Fri, 5 Oct 2012 13:55:14 +0000 Received: from mail113-am1 (localhost [127.0.0.1]) by mail113-am1-R.bigfish.com (Postfix) with ESMTP id 46442240116 for ; Fri, 5 Oct 2012 13:55:14 +0000 (UTC) X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null); IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: VPS0(zzc85fhc85dhzz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12bdh137ah1441h34h1155h) Received: from mail113-am1 (localhost.localdomain [127.0.0.1]) by mail113-am1 (MessageSwitch) id 1349445312229962_21898; Fri, 5 Oct 2012 13:55:12 +0000 (UTC) Received: from AM1EHSMHS001.bigfish.com (unknown [10.3.201.242]) by mail113-am1.bigfish.com (Postfix) with ESMTP id 3631D380065 for ; Fri, 5 Oct 2012 13:55:12 +0000 (UTC) Received: from ausb3twp02.amd.com (163.181.249.109) by AM1EHSMHS001.bigfish.com (10.3.207.101) with Microsoft SMTP Server id 14.1.225.23; Fri, 5 Oct 2012 13:55:10 +0000 X-WSS-ID: 0MBFANS-02-EJC-02 X-M-MSG: Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com [163.181.249.72]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ausb3twp02.amd.com (Axway MailGate 3.8.1) with ESMTP id 21D5FC8078 for ; Fri, 5 Oct 2012 08:55:04 -0500 (CDT) Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep01.amd.com (163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1; Fri, 5 Oct 2012 08:55:27 -0500 Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag03.amd.com (163.181.55.3) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 5 Oct 2012 08:55:07 -0500 Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com (172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 5 Oct 2012 09:55:06 -0400 Message-ID: <506EE6B9.2070205@amd.com> Date: Fri, 5 Oct 2012 15:55:05 +0200 From: Christoph Egger User-Agent: Mozilla/5.0 (X11; NetBSD amd64; rv:11.0) Gecko/20120404 Thunderbird/11.0 MIME-Version: 1.0 To: "xen-devel@lists.xen.org" Content-Type: multipart/mixed; boundary="------------070207000902090809000902" X-OriginatorOrg: amd.com Subject: [Xen-devel] [PATCH] MCE: Implement memory page offlining for AMD X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --------------070207000902090809000902 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit Implement memory page offlining for AMD Signed-off-by: Christoph Egger -- ---to satisfy European Law for business letters: Advanced Micro Devices GmbH Einsteinring 24, 85689 Dornach b. Muenchen Geschaeftsfuehrer: Alberto Bozzo Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632 --------------070207000902090809000902 Content-Type: text/plain; charset="us-ascii"; name="xen_mce_pageoffline.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="xen_mce_pageoffline.diff" Content-Description: xen_mce_pageoffline.diff # User Christoph Egger # Date 1349440371 -7200 Implement page offline recovery action for AMD Signed-off-by: Christoph Egger diff -r ee2d4b68aa2b -r 13daa0d9bb59 xen/arch/x86/cpu/mcheck/Makefile --- a/xen/arch/x86/cpu/mcheck/Makefile +++ b/xen/arch/x86/cpu/mcheck/Makefile @@ -3,6 +3,7 @@ obj-y += k7.o obj-y += amd_k8.o obj-y += amd_f10.o obj-y += mce_amd.o +obj-y += mcaction.o obj-y += barrier.o obj-y += mctelem.o obj-y += mce.o diff -r ee2d4b68aa2b -r 13daa0d9bb59 xen/arch/x86/cpu/mcheck/amd_f10.c --- a/xen/arch/x86/cpu/mcheck/amd_f10.c +++ b/xen/arch/x86/cpu/mcheck/amd_f10.c @@ -44,6 +44,7 @@ #include "mce_quirks.h" #include "x86_mca.h" #include "mce_amd.h" +#include "mcaction.h" static struct mcinfo_extended * amd_f10_handler(struct mc_info *mi, uint16_t bank, uint64_t status) @@ -97,6 +98,7 @@ enum mcheck_type amd_f10_mcheck_init(str x86_mce_callback_register(amd_f10_handler); mce_recoverable_register(mc_amd_recoverable_scan); + mce_register_addrcheck(mc_amd_addrcheck); return mcheck_amd_famXX; } diff -r ee2d4b68aa2b -r 13daa0d9bb59 xen/arch/x86/cpu/mcheck/mcaction.c --- /dev/null +++ b/xen/arch/x86/cpu/mcheck/mcaction.c @@ -0,0 +1,139 @@ +#include +#include +#include "mcaction.h" +#include "vmce.h" +#include "mce.h" + +static struct mcinfo_recovery * +mci_action_add_pageoffline(int bank, struct mc_info *mi, + uint64_t mfn, uint32_t status) +{ + struct mcinfo_recovery *rec; + + if (!mi) + return NULL; + + rec = x86_mcinfo_reserve(mi, sizeof(struct mcinfo_recovery)); + if (!rec) { + mi->flags |= MCINFO_FLAGS_UNCOMPLETE; + return NULL; + } + + memset(rec, 0, sizeof(struct mcinfo_recovery)); + + rec->common.type = MC_TYPE_RECOVERY; + rec->common.size = sizeof(*rec); + rec->mc_bank = bank; + rec->action_types = MC_ACTION_PAGE_OFFLINE; + rec->action_info.page_retire.mfn = mfn; + rec->action_info.page_retire.status = status; + return rec; +} + +mce_check_addr_t mc_check_addr = NULL; + +void mce_register_addrcheck(mce_check_addr_t cbfunc) +{ + mc_check_addr = cbfunc; +} + +void +mc_memerr_dhandler(struct mca_binfo *binfo, + enum mce_result *result, + struct cpu_user_regs *regs) +{ + struct mcinfo_bank *bank = binfo->mib; + struct mcinfo_global *global = binfo->mig; + struct domain *d; + unsigned long mfn, gfn; + uint32_t status; + uint16_t vmce_vcpuid; + + if (!mc_check_addr(bank->mc_status, bank->mc_misc, MC_ADDR_PHYSICAL)) { + dprintk(XENLOG_WARNING, + "No physical address provided for memory error\n"); + return; + } + + mfn = bank->mc_addr >> PAGE_SHIFT; + if (offline_page(mfn, 1, &status)) + { + dprintk(XENLOG_WARNING, + "Failed to offline page %lx for MCE error\n", mfn); + return; + } + + mci_action_add_pageoffline(binfo->bank, binfo->mi, mfn, status); + + /* This is free page */ + if (status & PG_OFFLINE_OFFLINED) + *result = MCER_RECOVERED; + else if (status & PG_OFFLINE_AGAIN) + *result = MCER_CONTINUE; + else if (status & PG_OFFLINE_PENDING) { + /* This page has owner */ + if (status & PG_OFFLINE_OWNED) { + bank->mc_domid = status >> PG_OFFLINE_OWNER_SHIFT; + mce_printk(MCE_QUIET, "MCE: This error page is ownded" + " by DOM %d\n", bank->mc_domid); + /* XXX: Cannot handle shared pages yet + * (this should identify all domains and gfn mapping to + * the mfn in question) */ + BUG_ON( bank->mc_domid == DOMID_COW ); + if ( bank->mc_domid != DOMID_XEN ) { + d = get_domain_by_id(bank->mc_domid); + ASSERT(d); + gfn = get_gpfn_from_mfn((bank->mc_addr) >> PAGE_SHIFT); + + if ( !is_vmce_ready(bank, d) ) + { + printk("DOM%d not ready for vMCE\n", d->domain_id); + goto vmce_failed; + } + + if ( unmmap_broken_page(d, _mfn(mfn), gfn) ) + { + printk("Unmap broken memory %lx for DOM%d failed\n", + mfn, d->domain_id); + goto vmce_failed; + } + + bank->mc_addr = gfn << PAGE_SHIFT | + (bank->mc_addr & (PAGE_SIZE -1 )); + if ( fill_vmsr_data(bank, d, + global->mc_gstatus) == -1 ) + { + mce_printk(MCE_QUIET, "Fill vMCE# data for DOM%d " + "failed\n", bank->mc_domid); + goto vmce_failed; + } + + if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL ) + vmce_vcpuid = VMCE_INJECT_BROADCAST; + else + vmce_vcpuid = global->mc_vcpuid; + + /* We will inject vMCE to DOMU*/ + if ( inject_vmce(d, vmce_vcpuid) < 0 ) + { + mce_printk(MCE_QUIET, "inject vMCE to DOM%d" + " failed\n", d->domain_id); + goto vmce_failed; + } + + /* Impacted domain go on with domain's recovery job + * if the domain has its own MCA handler. + * For xen, it has contained the error and finished + * its own recovery job. + */ + *result = MCER_RECOVERED; + put_domain(d); + + return; +vmce_failed: + put_domain(d); + domain_crash(d); + } + } + } +} diff -r ee2d4b68aa2b -r 13daa0d9bb59 xen/arch/x86/cpu/mcheck/mcaction.h --- /dev/null +++ b/xen/arch/x86/cpu/mcheck/mcaction.h @@ -0,0 +1,20 @@ +#ifndef _MCHECK_ACTION_H +#define _MCHECK_ACTION_H + +#include +#include "x86_mca.h" + +void +mc_memerr_dhandler(struct mca_binfo *binfo, + enum mce_result *result, + struct cpu_user_regs *regs); + +#define MC_ADDR_PHYSICAL 0 +#define MC_ADDR_VIRTUAL 1 + +typedef int (*mce_check_addr_t)(uint64_t status, uint64_t misc, int addr_type); +extern void mce_register_addrcheck(mce_check_addr_t); + +extern mce_check_addr_t mc_check_addr; + +#endif diff -r ee2d4b68aa2b -r 13daa0d9bb59 xen/arch/x86/cpu/mcheck/mce.c --- a/xen/arch/x86/cpu/mcheck/mce.c +++ b/xen/arch/x86/cpu/mcheck/mce.c @@ -24,6 +24,7 @@ #include "mce.h" #include "barrier.h" +#include "mcaction.h" #include "util.h" #include "vmce.h" @@ -216,7 +217,7 @@ static void mca_init_bank(enum mca_sourc if ((mib->mc_status & MCi_STATUS_MISCV) && (mib->mc_status & MCi_STATUS_ADDRV) && - ((mib->mc_misc & MCi_MISC_ADDRMOD_MASK) == MCi_MISC_PHYSMOD) && + (mc_check_addr(mib->mc_status, mib->mc_misc, MC_ADDR_PHYSICAL)) && (who == MCA_POLLER || who == MCA_CMCI_HANDLER) && (mfn_valid(paddr_to_pfn(mib->mc_addr)))) { diff -r ee2d4b68aa2b -r 13daa0d9bb59 xen/arch/x86/cpu/mcheck/mce_amd.c --- a/xen/arch/x86/cpu/mcheck/mce_amd.c +++ b/xen/arch/x86/cpu/mcheck/mce_amd.c @@ -25,6 +25,7 @@ #include "mce.h" #include "x86_mca.h" #include "mce_amd.h" +#include "mcaction.h" /* Error Code Types */ enum mc_ec_type { @@ -75,3 +76,25 @@ mc_amd_recoverable_scan(uint64_t status) return ret; } + +int +mc_amd_addrcheck(uint64_t status, uint64_t misc, int addrtype) +{ + enum mc_ec_type ectype; + uint16_t errorcode; + + errorcode = status & (MCi_STATUS_MCA | MCi_STATUS_MSEC); + ectype = mc_ec2type(errorcode); + + switch (ectype) { + case MC_EC_BUS_TYPE: /* value in addr MSR is physical */ + case MC_EC_MEM_TYPE: /* value in addr MSR is physical */ + return (addrtype == MC_ADDR_PHYSICAL); + case MC_EC_TLB_TYPE: /* value in addr MSR is virtual */ + return (addrtype == MC_ADDR_VIRTUAL); + } + + /* unreached */ + BUG(); + return 0; +} diff -r ee2d4b68aa2b -r 13daa0d9bb59 xen/arch/x86/cpu/mcheck/mce_amd.h --- a/xen/arch/x86/cpu/mcheck/mce_amd.h +++ b/xen/arch/x86/cpu/mcheck/mce_amd.h @@ -2,5 +2,6 @@ #define _MCHECK_AMD_H int mc_amd_recoverable_scan(uint64_t status); +int mc_amd_addrcheck(uint64_t status, uint64_t misc, int addrtype); #endif diff -r ee2d4b68aa2b -r 13daa0d9bb59 xen/arch/x86/cpu/mcheck/mce_intel.c --- a/xen/arch/x86/cpu/mcheck/mce_intel.c +++ b/xen/arch/x86/cpu/mcheck/mce_intel.c @@ -19,6 +19,7 @@ #include "barrier.h" #include "util.h" #include "vmce.h" +#include "mcaction.h" DEFINE_PER_CPU(struct mca_banks *, mce_banks_owned); DEFINE_PER_CPU(struct mca_banks *, no_cmci_banks); @@ -257,130 +258,13 @@ static enum intel_mce_type intel_check_m return intel_mce_fatal; } -struct mcinfo_recovery *mci_add_pageoff_action(int bank, struct mc_info *mi, - uint64_t mfn, uint32_t status) -{ - struct mcinfo_recovery *rec; - - if (!mi) - return NULL; - - rec = x86_mcinfo_reserve(mi, sizeof(struct mcinfo_recovery)); - if (!rec) - { - mi->flags |= MCINFO_FLAGS_UNCOMPLETE; - return NULL; - } - - memset(rec, 0, sizeof(struct mcinfo_recovery)); - - rec->mc_bank = bank; - rec->action_types = MC_ACTION_PAGE_OFFLINE; - rec->action_info.page_retire.mfn = mfn; - rec->action_info.page_retire.status = status; - return rec; -} - static void intel_memerr_dhandler( struct mca_binfo *binfo, enum mce_result *result, struct cpu_user_regs *regs) { - struct mcinfo_bank *bank = binfo->mib; - struct mcinfo_global *global = binfo->mig; - struct domain *d; - unsigned long mfn, gfn; - uint32_t status; - uint64_t mc_status, mc_misc; - mce_printk(MCE_VERBOSE, "MCE: Enter UCR recovery action\n"); - - mc_status = bank->mc_status; - mc_misc = bank->mc_misc; - if (!(mc_status & MCi_STATUS_ADDRV) || - !(mc_status & MCi_STATUS_MISCV) || - ((mc_misc & MCi_MISC_ADDRMOD_MASK) != MCi_MISC_PHYSMOD) ) - { - dprintk(XENLOG_WARNING, - "No physical address provided for memory error\n"); - return; - } - - mfn = bank->mc_addr >> PAGE_SHIFT; - if (offline_page(mfn, 1, &status)) - { - dprintk(XENLOG_WARNING, - "Failed to offline page %lx for MCE error\n", mfn); - return; - } - - mci_add_pageoff_action(binfo->bank, binfo->mi, mfn, status); - - /* This is free page */ - if (status & PG_OFFLINE_OFFLINED) - *result = MCER_RECOVERED; - else if (status & PG_OFFLINE_AGAIN) - *result = MCER_CONTINUE; - else if (status & PG_OFFLINE_PENDING) { - /* This page has owner */ - if (status & PG_OFFLINE_OWNED) { - bank->mc_domid = status >> PG_OFFLINE_OWNER_SHIFT; - mce_printk(MCE_QUIET, "MCE: This error page is ownded" - " by DOM %d\n", bank->mc_domid); - /* XXX: Cannot handle shared pages yet - * (this should identify all domains and gfn mapping to - * the mfn in question) */ - BUG_ON( bank->mc_domid == DOMID_COW ); - if ( bank->mc_domid != DOMID_XEN ) { - d = get_domain_by_id(bank->mc_domid); - ASSERT(d); - gfn = get_gpfn_from_mfn((bank->mc_addr) >> PAGE_SHIFT); - - if ( !is_vmce_ready(bank, d) ) - { - printk("DOM%d not ready for vMCE\n", d->domain_id); - goto vmce_failed; - } - - if ( unmmap_broken_page(d, _mfn(mfn), gfn) ) - { - printk("Unmap broken memory %lx for DOM%d failed\n", - mfn, d->domain_id); - goto vmce_failed; - } - - bank->mc_addr = gfn << PAGE_SHIFT | - (bank->mc_addr & (PAGE_SIZE -1 )); - if ( fill_vmsr_data(bank, d, - global->mc_gstatus) == -1 ) - { - mce_printk(MCE_QUIET, "Fill vMCE# data for DOM%d " - "failed\n", bank->mc_domid); - goto vmce_failed; - } - - /* We will inject vMCE to DOMU*/ - if ( inject_vmce(d, VMCE_INJECT_BROADCAST) < 0 ) - { - mce_printk(MCE_QUIET, "inject vMCE to DOM%d" - " failed\n", d->domain_id); - goto vmce_failed; - } - /* Impacted domain go on with domain's recovery job - * if the domain has its own MCA handler. - * For xen, it has contained the error and finished - * its own recovery job. - */ - *result = MCER_RECOVERED; - put_domain(d); - - return; -vmce_failed: - put_domain(d); - domain_crash(d); - } - } - } + mc_memerr_dhandler(binfo, result, regs); } static int intel_srar_check(uint64_t status) @@ -388,6 +272,19 @@ static int intel_srar_check(uint64_t sta return ( intel_check_mce_type(status) == intel_mce_ucr_srar ); } +static int intel_checkaddr(uint64_t status, uint64_t misc, int addrtype) +{ + if (!(status & MCi_STATUS_ADDRV) || + !(status & MCi_STATUS_MISCV) || + ((misc & MCi_MISC_ADDRMOD_MASK) != MCi_MISC_PHYSMOD) ) + { + /* addr is virtual */ + return (addrtype == MC_ADDR_VIRTUAL); + } + + return (addrtype == MC_ADDR_PHYSICAL); +} + static void intel_srar_dhandler( struct mca_binfo *binfo, enum mce_result *result, @@ -882,6 +779,7 @@ static void intel_init_mce(void) x86_mce_vector_register(intel_machine_check); mce_recoverable_register(intel_recoverable_scan); mce_need_clearbank_register(intel_need_clearbank_scan); + mce_register_addrcheck(intel_checkaddr); mce_dhandlers = intel_mce_dhandlers; mce_dhandler_num = ARRAY_SIZE(intel_mce_dhandlers); --------------070207000902090809000902 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --------------070207000902090809000902-- From xen-devel-bounces@lists.xen.org Fri Oct 05 13:55:27 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 13:55:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8N4-0007Ej-J4; Fri, 05 Oct 2012 13:55:18 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8N2-0007Ea-Bj for xen-devel@lists.xen.org; Fri, 05 Oct 2012 13:55:16 +0000 Received: from [85.158.139.211:27629] by server-7.bemta-5.messagelabs.com id 6B/FA-00431-3C6EE605; Fri, 05 Oct 2012 13:55:15 +0000 X-Env-Sender: Christoph.Egger@amd.com X-Msg-Ref: server-16.tower-206.messagelabs.com!1349445314!21257732!1 X-Originating-IP: [213.199.154.207] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22179 invoked from network); 5 Oct 2012 13:55:14 -0000 Received: from am1ehsobe004.messaging.microsoft.com (HELO am1outboundpool.messaging.microsoft.com) (213.199.154.207) by server-16.tower-206.messagelabs.com with AES128-SHA encrypted SMTP; 5 Oct 2012 13:55:14 -0000 Received: from mail113-am1-R.bigfish.com (10.3.201.233) by AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id 14.1.225.23; Fri, 5 Oct 2012 13:55:14 +0000 Received: from mail113-am1 (localhost [127.0.0.1]) by mail113-am1-R.bigfish.com (Postfix) with ESMTP id 46442240116 for ; Fri, 5 Oct 2012 13:55:14 +0000 (UTC) X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null); IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: VPS0(zzc85fhc85dhzz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12bdh137ah1441h34h1155h) Received: from mail113-am1 (localhost.localdomain [127.0.0.1]) by mail113-am1 (MessageSwitch) id 1349445312229962_21898; Fri, 5 Oct 2012 13:55:12 +0000 (UTC) Received: from AM1EHSMHS001.bigfish.com (unknown [10.3.201.242]) by mail113-am1.bigfish.com (Postfix) with ESMTP id 3631D380065 for ; Fri, 5 Oct 2012 13:55:12 +0000 (UTC) Received: from ausb3twp02.amd.com (163.181.249.109) by AM1EHSMHS001.bigfish.com (10.3.207.101) with Microsoft SMTP Server id 14.1.225.23; Fri, 5 Oct 2012 13:55:10 +0000 X-WSS-ID: 0MBFANS-02-EJC-02 X-M-MSG: Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com [163.181.249.72]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ausb3twp02.amd.com (Axway MailGate 3.8.1) with ESMTP id 21D5FC8078 for ; Fri, 5 Oct 2012 08:55:04 -0500 (CDT) Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep01.amd.com (163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1; Fri, 5 Oct 2012 08:55:27 -0500 Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag03.amd.com (163.181.55.3) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 5 Oct 2012 08:55:07 -0500 Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com (172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 5 Oct 2012 09:55:06 -0400 Message-ID: <506EE6B9.2070205@amd.com> Date: Fri, 5 Oct 2012 15:55:05 +0200 From: Christoph Egger User-Agent: Mozilla/5.0 (X11; NetBSD amd64; rv:11.0) Gecko/20120404 Thunderbird/11.0 MIME-Version: 1.0 To: "xen-devel@lists.xen.org" Content-Type: multipart/mixed; boundary="------------070207000902090809000902" X-OriginatorOrg: amd.com Subject: [Xen-devel] [PATCH] MCE: Implement memory page offlining for AMD X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --------------070207000902090809000902 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit Implement memory page offlining for AMD Signed-off-by: Christoph Egger -- ---to satisfy European Law for business letters: Advanced Micro Devices GmbH Einsteinring 24, 85689 Dornach b. Muenchen Geschaeftsfuehrer: Alberto Bozzo Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632 --------------070207000902090809000902 Content-Type: text/plain; charset="us-ascii"; name="xen_mce_pageoffline.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="xen_mce_pageoffline.diff" Content-Description: xen_mce_pageoffline.diff # User Christoph Egger # Date 1349440371 -7200 Implement page offline recovery action for AMD Signed-off-by: Christoph Egger diff -r ee2d4b68aa2b -r 13daa0d9bb59 xen/arch/x86/cpu/mcheck/Makefile --- a/xen/arch/x86/cpu/mcheck/Makefile +++ b/xen/arch/x86/cpu/mcheck/Makefile @@ -3,6 +3,7 @@ obj-y += k7.o obj-y += amd_k8.o obj-y += amd_f10.o obj-y += mce_amd.o +obj-y += mcaction.o obj-y += barrier.o obj-y += mctelem.o obj-y += mce.o diff -r ee2d4b68aa2b -r 13daa0d9bb59 xen/arch/x86/cpu/mcheck/amd_f10.c --- a/xen/arch/x86/cpu/mcheck/amd_f10.c +++ b/xen/arch/x86/cpu/mcheck/amd_f10.c @@ -44,6 +44,7 @@ #include "mce_quirks.h" #include "x86_mca.h" #include "mce_amd.h" +#include "mcaction.h" static struct mcinfo_extended * amd_f10_handler(struct mc_info *mi, uint16_t bank, uint64_t status) @@ -97,6 +98,7 @@ enum mcheck_type amd_f10_mcheck_init(str x86_mce_callback_register(amd_f10_handler); mce_recoverable_register(mc_amd_recoverable_scan); + mce_register_addrcheck(mc_amd_addrcheck); return mcheck_amd_famXX; } diff -r ee2d4b68aa2b -r 13daa0d9bb59 xen/arch/x86/cpu/mcheck/mcaction.c --- /dev/null +++ b/xen/arch/x86/cpu/mcheck/mcaction.c @@ -0,0 +1,139 @@ +#include +#include +#include "mcaction.h" +#include "vmce.h" +#include "mce.h" + +static struct mcinfo_recovery * +mci_action_add_pageoffline(int bank, struct mc_info *mi, + uint64_t mfn, uint32_t status) +{ + struct mcinfo_recovery *rec; + + if (!mi) + return NULL; + + rec = x86_mcinfo_reserve(mi, sizeof(struct mcinfo_recovery)); + if (!rec) { + mi->flags |= MCINFO_FLAGS_UNCOMPLETE; + return NULL; + } + + memset(rec, 0, sizeof(struct mcinfo_recovery)); + + rec->common.type = MC_TYPE_RECOVERY; + rec->common.size = sizeof(*rec); + rec->mc_bank = bank; + rec->action_types = MC_ACTION_PAGE_OFFLINE; + rec->action_info.page_retire.mfn = mfn; + rec->action_info.page_retire.status = status; + return rec; +} + +mce_check_addr_t mc_check_addr = NULL; + +void mce_register_addrcheck(mce_check_addr_t cbfunc) +{ + mc_check_addr = cbfunc; +} + +void +mc_memerr_dhandler(struct mca_binfo *binfo, + enum mce_result *result, + struct cpu_user_regs *regs) +{ + struct mcinfo_bank *bank = binfo->mib; + struct mcinfo_global *global = binfo->mig; + struct domain *d; + unsigned long mfn, gfn; + uint32_t status; + uint16_t vmce_vcpuid; + + if (!mc_check_addr(bank->mc_status, bank->mc_misc, MC_ADDR_PHYSICAL)) { + dprintk(XENLOG_WARNING, + "No physical address provided for memory error\n"); + return; + } + + mfn = bank->mc_addr >> PAGE_SHIFT; + if (offline_page(mfn, 1, &status)) + { + dprintk(XENLOG_WARNING, + "Failed to offline page %lx for MCE error\n", mfn); + return; + } + + mci_action_add_pageoffline(binfo->bank, binfo->mi, mfn, status); + + /* This is free page */ + if (status & PG_OFFLINE_OFFLINED) + *result = MCER_RECOVERED; + else if (status & PG_OFFLINE_AGAIN) + *result = MCER_CONTINUE; + else if (status & PG_OFFLINE_PENDING) { + /* This page has owner */ + if (status & PG_OFFLINE_OWNED) { + bank->mc_domid = status >> PG_OFFLINE_OWNER_SHIFT; + mce_printk(MCE_QUIET, "MCE: This error page is ownded" + " by DOM %d\n", bank->mc_domid); + /* XXX: Cannot handle shared pages yet + * (this should identify all domains and gfn mapping to + * the mfn in question) */ + BUG_ON( bank->mc_domid == DOMID_COW ); + if ( bank->mc_domid != DOMID_XEN ) { + d = get_domain_by_id(bank->mc_domid); + ASSERT(d); + gfn = get_gpfn_from_mfn((bank->mc_addr) >> PAGE_SHIFT); + + if ( !is_vmce_ready(bank, d) ) + { + printk("DOM%d not ready for vMCE\n", d->domain_id); + goto vmce_failed; + } + + if ( unmmap_broken_page(d, _mfn(mfn), gfn) ) + { + printk("Unmap broken memory %lx for DOM%d failed\n", + mfn, d->domain_id); + goto vmce_failed; + } + + bank->mc_addr = gfn << PAGE_SHIFT | + (bank->mc_addr & (PAGE_SIZE -1 )); + if ( fill_vmsr_data(bank, d, + global->mc_gstatus) == -1 ) + { + mce_printk(MCE_QUIET, "Fill vMCE# data for DOM%d " + "failed\n", bank->mc_domid); + goto vmce_failed; + } + + if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL ) + vmce_vcpuid = VMCE_INJECT_BROADCAST; + else + vmce_vcpuid = global->mc_vcpuid; + + /* We will inject vMCE to DOMU*/ + if ( inject_vmce(d, vmce_vcpuid) < 0 ) + { + mce_printk(MCE_QUIET, "inject vMCE to DOM%d" + " failed\n", d->domain_id); + goto vmce_failed; + } + + /* Impacted domain go on with domain's recovery job + * if the domain has its own MCA handler. + * For xen, it has contained the error and finished + * its own recovery job. + */ + *result = MCER_RECOVERED; + put_domain(d); + + return; +vmce_failed: + put_domain(d); + domain_crash(d); + } + } + } +} diff -r ee2d4b68aa2b -r 13daa0d9bb59 xen/arch/x86/cpu/mcheck/mcaction.h --- /dev/null +++ b/xen/arch/x86/cpu/mcheck/mcaction.h @@ -0,0 +1,20 @@ +#ifndef _MCHECK_ACTION_H +#define _MCHECK_ACTION_H + +#include +#include "x86_mca.h" + +void +mc_memerr_dhandler(struct mca_binfo *binfo, + enum mce_result *result, + struct cpu_user_regs *regs); + +#define MC_ADDR_PHYSICAL 0 +#define MC_ADDR_VIRTUAL 1 + +typedef int (*mce_check_addr_t)(uint64_t status, uint64_t misc, int addr_type); +extern void mce_register_addrcheck(mce_check_addr_t); + +extern mce_check_addr_t mc_check_addr; + +#endif diff -r ee2d4b68aa2b -r 13daa0d9bb59 xen/arch/x86/cpu/mcheck/mce.c --- a/xen/arch/x86/cpu/mcheck/mce.c +++ b/xen/arch/x86/cpu/mcheck/mce.c @@ -24,6 +24,7 @@ #include "mce.h" #include "barrier.h" +#include "mcaction.h" #include "util.h" #include "vmce.h" @@ -216,7 +217,7 @@ static void mca_init_bank(enum mca_sourc if ((mib->mc_status & MCi_STATUS_MISCV) && (mib->mc_status & MCi_STATUS_ADDRV) && - ((mib->mc_misc & MCi_MISC_ADDRMOD_MASK) == MCi_MISC_PHYSMOD) && + (mc_check_addr(mib->mc_status, mib->mc_misc, MC_ADDR_PHYSICAL)) && (who == MCA_POLLER || who == MCA_CMCI_HANDLER) && (mfn_valid(paddr_to_pfn(mib->mc_addr)))) { diff -r ee2d4b68aa2b -r 13daa0d9bb59 xen/arch/x86/cpu/mcheck/mce_amd.c --- a/xen/arch/x86/cpu/mcheck/mce_amd.c +++ b/xen/arch/x86/cpu/mcheck/mce_amd.c @@ -25,6 +25,7 @@ #include "mce.h" #include "x86_mca.h" #include "mce_amd.h" +#include "mcaction.h" /* Error Code Types */ enum mc_ec_type { @@ -75,3 +76,25 @@ mc_amd_recoverable_scan(uint64_t status) return ret; } + +int +mc_amd_addrcheck(uint64_t status, uint64_t misc, int addrtype) +{ + enum mc_ec_type ectype; + uint16_t errorcode; + + errorcode = status & (MCi_STATUS_MCA | MCi_STATUS_MSEC); + ectype = mc_ec2type(errorcode); + + switch (ectype) { + case MC_EC_BUS_TYPE: /* value in addr MSR is physical */ + case MC_EC_MEM_TYPE: /* value in addr MSR is physical */ + return (addrtype == MC_ADDR_PHYSICAL); + case MC_EC_TLB_TYPE: /* value in addr MSR is virtual */ + return (addrtype == MC_ADDR_VIRTUAL); + } + + /* unreached */ + BUG(); + return 0; +} diff -r ee2d4b68aa2b -r 13daa0d9bb59 xen/arch/x86/cpu/mcheck/mce_amd.h --- a/xen/arch/x86/cpu/mcheck/mce_amd.h +++ b/xen/arch/x86/cpu/mcheck/mce_amd.h @@ -2,5 +2,6 @@ #define _MCHECK_AMD_H int mc_amd_recoverable_scan(uint64_t status); +int mc_amd_addrcheck(uint64_t status, uint64_t misc, int addrtype); #endif diff -r ee2d4b68aa2b -r 13daa0d9bb59 xen/arch/x86/cpu/mcheck/mce_intel.c --- a/xen/arch/x86/cpu/mcheck/mce_intel.c +++ b/xen/arch/x86/cpu/mcheck/mce_intel.c @@ -19,6 +19,7 @@ #include "barrier.h" #include "util.h" #include "vmce.h" +#include "mcaction.h" DEFINE_PER_CPU(struct mca_banks *, mce_banks_owned); DEFINE_PER_CPU(struct mca_banks *, no_cmci_banks); @@ -257,130 +258,13 @@ static enum intel_mce_type intel_check_m return intel_mce_fatal; } -struct mcinfo_recovery *mci_add_pageoff_action(int bank, struct mc_info *mi, - uint64_t mfn, uint32_t status) -{ - struct mcinfo_recovery *rec; - - if (!mi) - return NULL; - - rec = x86_mcinfo_reserve(mi, sizeof(struct mcinfo_recovery)); - if (!rec) - { - mi->flags |= MCINFO_FLAGS_UNCOMPLETE; - return NULL; - } - - memset(rec, 0, sizeof(struct mcinfo_recovery)); - - rec->mc_bank = bank; - rec->action_types = MC_ACTION_PAGE_OFFLINE; - rec->action_info.page_retire.mfn = mfn; - rec->action_info.page_retire.status = status; - return rec; -} - static void intel_memerr_dhandler( struct mca_binfo *binfo, enum mce_result *result, struct cpu_user_regs *regs) { - struct mcinfo_bank *bank = binfo->mib; - struct mcinfo_global *global = binfo->mig; - struct domain *d; - unsigned long mfn, gfn; - uint32_t status; - uint64_t mc_status, mc_misc; - mce_printk(MCE_VERBOSE, "MCE: Enter UCR recovery action\n"); - - mc_status = bank->mc_status; - mc_misc = bank->mc_misc; - if (!(mc_status & MCi_STATUS_ADDRV) || - !(mc_status & MCi_STATUS_MISCV) || - ((mc_misc & MCi_MISC_ADDRMOD_MASK) != MCi_MISC_PHYSMOD) ) - { - dprintk(XENLOG_WARNING, - "No physical address provided for memory error\n"); - return; - } - - mfn = bank->mc_addr >> PAGE_SHIFT; - if (offline_page(mfn, 1, &status)) - { - dprintk(XENLOG_WARNING, - "Failed to offline page %lx for MCE error\n", mfn); - return; - } - - mci_add_pageoff_action(binfo->bank, binfo->mi, mfn, status); - - /* This is free page */ - if (status & PG_OFFLINE_OFFLINED) - *result = MCER_RECOVERED; - else if (status & PG_OFFLINE_AGAIN) - *result = MCER_CONTINUE; - else if (status & PG_OFFLINE_PENDING) { - /* This page has owner */ - if (status & PG_OFFLINE_OWNED) { - bank->mc_domid = status >> PG_OFFLINE_OWNER_SHIFT; - mce_printk(MCE_QUIET, "MCE: This error page is ownded" - " by DOM %d\n", bank->mc_domid); - /* XXX: Cannot handle shared pages yet - * (this should identify all domains and gfn mapping to - * the mfn in question) */ - BUG_ON( bank->mc_domid == DOMID_COW ); - if ( bank->mc_domid != DOMID_XEN ) { - d = get_domain_by_id(bank->mc_domid); - ASSERT(d); - gfn = get_gpfn_from_mfn((bank->mc_addr) >> PAGE_SHIFT); - - if ( !is_vmce_ready(bank, d) ) - { - printk("DOM%d not ready for vMCE\n", d->domain_id); - goto vmce_failed; - } - - if ( unmmap_broken_page(d, _mfn(mfn), gfn) ) - { - printk("Unmap broken memory %lx for DOM%d failed\n", - mfn, d->domain_id); - goto vmce_failed; - } - - bank->mc_addr = gfn << PAGE_SHIFT | - (bank->mc_addr & (PAGE_SIZE -1 )); - if ( fill_vmsr_data(bank, d, - global->mc_gstatus) == -1 ) - { - mce_printk(MCE_QUIET, "Fill vMCE# data for DOM%d " - "failed\n", bank->mc_domid); - goto vmce_failed; - } - - /* We will inject vMCE to DOMU*/ - if ( inject_vmce(d, VMCE_INJECT_BROADCAST) < 0 ) - { - mce_printk(MCE_QUIET, "inject vMCE to DOM%d" - " failed\n", d->domain_id); - goto vmce_failed; - } - /* Impacted domain go on with domain's recovery job - * if the domain has its own MCA handler. - * For xen, it has contained the error and finished - * its own recovery job. - */ - *result = MCER_RECOVERED; - put_domain(d); - - return; -vmce_failed: - put_domain(d); - domain_crash(d); - } - } - } + mc_memerr_dhandler(binfo, result, regs); } static int intel_srar_check(uint64_t status) @@ -388,6 +272,19 @@ static int intel_srar_check(uint64_t sta return ( intel_check_mce_type(status) == intel_mce_ucr_srar ); } +static int intel_checkaddr(uint64_t status, uint64_t misc, int addrtype) +{ + if (!(status & MCi_STATUS_ADDRV) || + !(status & MCi_STATUS_MISCV) || + ((misc & MCi_MISC_ADDRMOD_MASK) != MCi_MISC_PHYSMOD) ) + { + /* addr is virtual */ + return (addrtype == MC_ADDR_VIRTUAL); + } + + return (addrtype == MC_ADDR_PHYSICAL); +} + static void intel_srar_dhandler( struct mca_binfo *binfo, enum mce_result *result, @@ -882,6 +779,7 @@ static void intel_init_mce(void) x86_mce_vector_register(intel_machine_check); mce_recoverable_register(intel_recoverable_scan); mce_need_clearbank_register(intel_need_clearbank_scan); + mce_register_addrcheck(intel_checkaddr); mce_dhandlers = intel_mce_dhandlers; mce_dhandler_num = ARRAY_SIZE(intel_mce_dhandlers); --------------070207000902090809000902 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --------------070207000902090809000902-- From xen-devel-bounces@lists.xen.org Fri Oct 05 14:03:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:03:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8V7-0007Z6-Mh; Fri, 05 Oct 2012 14:03:37 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8V7-0007Z1-06 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:03:37 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1349445810!8890875!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9222 invoked from network); 5 Oct 2012 14:03:30 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:03:30 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14965491" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 14:03:29 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 15:03:29 +0100 Date: Fri, 5 Oct 2012 15:02:27 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Ian Campbell In-Reply-To: <1349440338.20946.83.camel@zakaz.uk.xensource.com> Message-ID: References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-5-git-send-email-ian.campbell@citrix.com> <1349440338.20946.83.camel@zakaz.uk.xensource.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: Konrad Rzeszutek Wilk , "xen-devel@lists.xen.org" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH 05/14] xen: balloon: use correct type for frame_list X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 5 Oct 2012, Ian Campbell wrote: > On Fri, 2012-10-05 at 12:48 +0100, Stefano Stabellini wrote: > > On Thu, 4 Oct 2012, Ian Campbell wrote: > > > This is now a xen_pfn_t. > > > > > > Signed-off-by: Ian Campbell > > > --- > > > drivers/xen/balloon.c | 2 +- > > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > > > diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c > > > index 85ef7e7..4625560 100644 > > > --- a/drivers/xen/balloon.c > > > +++ b/drivers/xen/balloon.c > > > @@ -87,7 +87,7 @@ struct balloon_stats balloon_stats; > > > EXPORT_SYMBOL_GPL(balloon_stats); > > > > > > /* We increase/decrease in batches which fit in a page */ > > > -static unsigned long frame_list[PAGE_SIZE / sizeof(unsigned long)]; > > > +static xen_pfn_t frame_list[PAGE_SIZE / sizeof(unsigned long)]; > > > > > > #ifdef CONFIG_HIGHMEM > > > #define inc_totalhigh_pages() (totalhigh_pages++) > > > > While I think is a good change, frame_list[i] is used as an argument to > > set_phys_to_machine, that takes an unsigned long. Also unsigned long are > > assigned to members of the array via page_to_pfn. > > I think that we should take care of these cases, either introducing > > explicit casts or changing the argument types. > > frame_list is used at the Xen interface, and so the pfn type has to be > sized for the largest pfn the hypervisor will use (aka xen_pfn_t). Those > unsigned longs are really "linux_pfn_t", that is they are the size of > the largest pfn the guest is itself prepared to deal with. > > So long as sizeof(unsigned long) <= sizeof(xen_pfn_t) (which it is) then > we are ok. I think that we are playing with fire here. Let's imaging a future where physical addresses are actually 64 bit. Let's imaging that Xen is supporting them perfectly fine and returns to this balloon driver a pfn > ULONG_MAX (already possible on ARM). That is a perfectly valid value for Xen to give us and we should be able to handle it. If we are not we should return an error. With this change we would trimmer the pfn returned by Xen to 32 bit so we would actually have an incorrect behaviour instead. If we assume sizeof(unsigned long) <= sizeof(xen_pfn_t), we only need a macro like this: #define LINUX_PFN_MAX ULONG_MAX #define linux_pfn_t unsigned long #define xen_pfn_to_linux_pfn(pfn) ({BUG_ON(pfn > LINUX_PFN_MAX); (linux_pfn_t)pfn;}) that is called in the right places. > If and when Linux wants to use pfn's which are not unsigned longs then > the uses of unsigned long will need to be audited (globally, not just > here) to become whatever type Linux then defines to contain a pfn. In > the absence of that type being defined in the core Linux code I think it > is correct for us to keep using unsigned long in those contexts. I think is OK using unsigned long for linux_pfn, the problem is the conversion between what Xen gives us and linux_pfns. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:03:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:03:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8V7-0007Z6-Mh; Fri, 05 Oct 2012 14:03:37 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8V7-0007Z1-06 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:03:37 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1349445810!8890875!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9222 invoked from network); 5 Oct 2012 14:03:30 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:03:30 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14965491" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 14:03:29 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 15:03:29 +0100 Date: Fri, 5 Oct 2012 15:02:27 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Ian Campbell In-Reply-To: <1349440338.20946.83.camel@zakaz.uk.xensource.com> Message-ID: References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-5-git-send-email-ian.campbell@citrix.com> <1349440338.20946.83.camel@zakaz.uk.xensource.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: Konrad Rzeszutek Wilk , "xen-devel@lists.xen.org" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH 05/14] xen: balloon: use correct type for frame_list X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 5 Oct 2012, Ian Campbell wrote: > On Fri, 2012-10-05 at 12:48 +0100, Stefano Stabellini wrote: > > On Thu, 4 Oct 2012, Ian Campbell wrote: > > > This is now a xen_pfn_t. > > > > > > Signed-off-by: Ian Campbell > > > --- > > > drivers/xen/balloon.c | 2 +- > > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > > > diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c > > > index 85ef7e7..4625560 100644 > > > --- a/drivers/xen/balloon.c > > > +++ b/drivers/xen/balloon.c > > > @@ -87,7 +87,7 @@ struct balloon_stats balloon_stats; > > > EXPORT_SYMBOL_GPL(balloon_stats); > > > > > > /* We increase/decrease in batches which fit in a page */ > > > -static unsigned long frame_list[PAGE_SIZE / sizeof(unsigned long)]; > > > +static xen_pfn_t frame_list[PAGE_SIZE / sizeof(unsigned long)]; > > > > > > #ifdef CONFIG_HIGHMEM > > > #define inc_totalhigh_pages() (totalhigh_pages++) > > > > While I think is a good change, frame_list[i] is used as an argument to > > set_phys_to_machine, that takes an unsigned long. Also unsigned long are > > assigned to members of the array via page_to_pfn. > > I think that we should take care of these cases, either introducing > > explicit casts or changing the argument types. > > frame_list is used at the Xen interface, and so the pfn type has to be > sized for the largest pfn the hypervisor will use (aka xen_pfn_t). Those > unsigned longs are really "linux_pfn_t", that is they are the size of > the largest pfn the guest is itself prepared to deal with. > > So long as sizeof(unsigned long) <= sizeof(xen_pfn_t) (which it is) then > we are ok. I think that we are playing with fire here. Let's imaging a future where physical addresses are actually 64 bit. Let's imaging that Xen is supporting them perfectly fine and returns to this balloon driver a pfn > ULONG_MAX (already possible on ARM). That is a perfectly valid value for Xen to give us and we should be able to handle it. If we are not we should return an error. With this change we would trimmer the pfn returned by Xen to 32 bit so we would actually have an incorrect behaviour instead. If we assume sizeof(unsigned long) <= sizeof(xen_pfn_t), we only need a macro like this: #define LINUX_PFN_MAX ULONG_MAX #define linux_pfn_t unsigned long #define xen_pfn_to_linux_pfn(pfn) ({BUG_ON(pfn > LINUX_PFN_MAX); (linux_pfn_t)pfn;}) that is called in the right places. > If and when Linux wants to use pfn's which are not unsigned longs then > the uses of unsigned long will need to be audited (globally, not just > here) to become whatever type Linux then defines to contain a pfn. In > the absence of that type being defined in the core Linux code I think it > is correct for us to keep using unsigned long in those contexts. I think is OK using unsigned long for linux_pfn, the problem is the conversion between what Xen gives us and linux_pfns. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:05:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:05:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8X9-0007kz-0v; Fri, 05 Oct 2012 14:05:43 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8X7-0007kf-D7 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:05:41 +0000 Received: from [85.158.143.99:23421] by server-3.bemta-4.messagelabs.com id 74/EE-10986-339EE605; Fri, 05 Oct 2012 14:05:39 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1349445938!26760639!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16869 invoked from network); 5 Oct 2012 14:05:38 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:05:38 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14965561" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 14:05:38 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 15:05:38 +0100 Date: Fri, 5 Oct 2012 15:04:36 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Ian Campbell In-Reply-To: <1349443982.20946.100.camel@zakaz.uk.xensource.com> Message-ID: References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-8-git-send-email-ian.campbell@citrix.com> <1349443982.20946.100.camel@zakaz.uk.xensource.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: Konrad Rzeszutek Wilk , "xen-devel@lists.xen.org" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH 08/14] xen: balloon: allow PVMMU interfaces to be compiled out X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 5 Oct 2012, Ian Campbell wrote: > On Fri, 2012-10-05 at 14:19 +0100, Stefano Stabellini wrote: > > On Thu, 4 Oct 2012, Ian Campbell wrote: > > > The ARM platform has no concept of PVMMU and therefor no > > > HYPERVISOR_update_va_mapping et al. Allow this code to be compiled out > > > when not required. > > > > > > Signed-off-by: Ian Campbell > > > > I am unsure whether it is worth a new symbol and two ifdef's > > ARM doesn't compile without it, since HYPERVISOR_update_va_mapping > doesn't exist. Do you have a preferable alternative? > > I'm not sure how much more of this sort of thing there will be as we > enable more features on the ARM port. #define HYPERVISOR_update_va_mapping(va, new_val, flags) (0) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:05:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:05:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8X9-0007kz-0v; Fri, 05 Oct 2012 14:05:43 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8X7-0007kf-D7 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:05:41 +0000 Received: from [85.158.143.99:23421] by server-3.bemta-4.messagelabs.com id 74/EE-10986-339EE605; Fri, 05 Oct 2012 14:05:39 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1349445938!26760639!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16869 invoked from network); 5 Oct 2012 14:05:38 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:05:38 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14965561" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 14:05:38 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 15:05:38 +0100 Date: Fri, 5 Oct 2012 15:04:36 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Ian Campbell In-Reply-To: <1349443982.20946.100.camel@zakaz.uk.xensource.com> Message-ID: References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-8-git-send-email-ian.campbell@citrix.com> <1349443982.20946.100.camel@zakaz.uk.xensource.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: Konrad Rzeszutek Wilk , "xen-devel@lists.xen.org" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH 08/14] xen: balloon: allow PVMMU interfaces to be compiled out X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 5 Oct 2012, Ian Campbell wrote: > On Fri, 2012-10-05 at 14:19 +0100, Stefano Stabellini wrote: > > On Thu, 4 Oct 2012, Ian Campbell wrote: > > > The ARM platform has no concept of PVMMU and therefor no > > > HYPERVISOR_update_va_mapping et al. Allow this code to be compiled out > > > when not required. > > > > > > Signed-off-by: Ian Campbell > > > > I am unsure whether it is worth a new symbol and two ifdef's > > ARM doesn't compile without it, since HYPERVISOR_update_va_mapping > doesn't exist. Do you have a preferable alternative? > > I'm not sure how much more of this sort of thing there will be as we > enable more features on the ARM port. #define HYPERVISOR_update_va_mapping(va, new_val, flags) (0) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:07:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:07:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8YM-0007w0-Gu; Fri, 05 Oct 2012 14:06:58 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8YL-0007vj-3G for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:06:57 +0000 Received: from [85.158.138.51:2170] by server-12.bemta-3.messagelabs.com id 4F/F1-23730-089EE605; Fri, 05 Oct 2012 14:06:56 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1349446015!33201395!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7398 invoked from network); 5 Oct 2012 14:06:55 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:06:55 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14965597" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 14:06:55 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 15:06:55 +0100 Date: Fri, 5 Oct 2012 15:05:53 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Stefano Stabellini In-Reply-To: Message-ID: References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-8-git-send-email-ian.campbell@citrix.com> <1349443982.20946.100.camel@zakaz.uk.xensource.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" , Ian Campbell , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 08/14] xen: balloon: allow PVMMU interfaces to be compiled out X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 5 Oct 2012, Stefano Stabellini wrote: > On Fri, 5 Oct 2012, Ian Campbell wrote: > > On Fri, 2012-10-05 at 14:19 +0100, Stefano Stabellini wrote: > > > On Thu, 4 Oct 2012, Ian Campbell wrote: > > > > The ARM platform has no concept of PVMMU and therefor no > > > > HYPERVISOR_update_va_mapping et al. Allow this code to be compiled out > > > > when not required. > > > > > > > > Signed-off-by: Ian Campbell > > > > > > I am unsure whether it is worth a new symbol and two ifdef's > > > > ARM doesn't compile without it, since HYPERVISOR_update_va_mapping > > doesn't exist. Do you have a preferable alternative? > > > > I'm not sure how much more of this sort of thing there will be as we > > enable more features on the ARM port. > > #define HYPERVISOR_update_va_mapping(va, new_val, flags) (0) > actually a proper static line with a BUG would be better _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:07:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:07:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8YM-0007w0-Gu; Fri, 05 Oct 2012 14:06:58 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8YL-0007vj-3G for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:06:57 +0000 Received: from [85.158.138.51:2170] by server-12.bemta-3.messagelabs.com id 4F/F1-23730-089EE605; Fri, 05 Oct 2012 14:06:56 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1349446015!33201395!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7398 invoked from network); 5 Oct 2012 14:06:55 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:06:55 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14965597" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 14:06:55 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 15:06:55 +0100 Date: Fri, 5 Oct 2012 15:05:53 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Stefano Stabellini In-Reply-To: Message-ID: References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-8-git-send-email-ian.campbell@citrix.com> <1349443982.20946.100.camel@zakaz.uk.xensource.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" , Ian Campbell , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 08/14] xen: balloon: allow PVMMU interfaces to be compiled out X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 5 Oct 2012, Stefano Stabellini wrote: > On Fri, 5 Oct 2012, Ian Campbell wrote: > > On Fri, 2012-10-05 at 14:19 +0100, Stefano Stabellini wrote: > > > On Thu, 4 Oct 2012, Ian Campbell wrote: > > > > The ARM platform has no concept of PVMMU and therefor no > > > > HYPERVISOR_update_va_mapping et al. Allow this code to be compiled out > > > > when not required. > > > > > > > > Signed-off-by: Ian Campbell > > > > > > I am unsure whether it is worth a new symbol and two ifdef's > > > > ARM doesn't compile without it, since HYPERVISOR_update_va_mapping > > doesn't exist. Do you have a preferable alternative? > > > > I'm not sure how much more of this sort of thing there will be as we > > enable more features on the ARM port. > > #define HYPERVISOR_update_va_mapping(va, new_val, flags) (0) > actually a proper static line with a BUG would be better _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:07:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:07:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8Yb-0007yq-Th; Fri, 05 Oct 2012 14:07:13 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8Ya-0007xP-KI for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 14:07:12 +0000 X-Env-Sender: wdauchy@gmail.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1349446024!6613253!1 X-Originating-IP: [209.85.160.43] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31854 invoked from network); 5 Oct 2012 14:07:06 -0000 Received: from mail-pb0-f43.google.com (HELO mail-pb0-f43.google.com) (209.85.160.43) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:07:06 -0000 Received: by mail-pb0-f43.google.com with SMTP id jt11so2102009pbb.30 for ; Fri, 05 Oct 2012 07:07:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=YH4tPNSBZELedSDLSzlT/bPMCoADFUcr6dqw7X+jCm0=; b=Au3DneblooOX3XXmR4GwS/Ot818pC9BYYvT4PrW3j5IEadTqHVMlTKKp7zrnUqFMdk GDL+ekSkusiWbErmqw93NxNPXwmESgr0OI6opTc+4LgpanlY7ZtGH8Oky1AUdQMWa48d 7gVvMmo4pIUmDoiYdQZzndPb0UgV8pFE4+E5VywxW4fyzMrLn5dJ6I4MrV1QIIgG1ahZ NFNWzQoFjLT4D686UNiRJbEwI7WB1hcXu7c1zyTYXdjMA6TNfzEC1AtFf07xgYTiJSTN xLd7po1wMvARFY39qH7BqZ0KKYsCoyIFag0dSXr6FBD91SbrcyjCz8vkGyHjcQ/g3xYZ udpA== Received: by 10.68.217.201 with SMTP id pa9mr31007493pbc.45.1349446024504; Fri, 05 Oct 2012 07:07:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.135.42 with HTTP; Fri, 5 Oct 2012 07:06:43 -0700 (PDT) In-Reply-To: <20120925214114.GB5372@phenom.dumpdata.com> References: <20120918133650.GC12053@phenom.dumpdata.com> <20120920134851.GB1998@localhost.localdomain> <20120920162337.GB8912@reaktio.net> <20120920163525.GC8912@reaktio.net> <20120920212823.GE27312@konrad-lan.dumpdata.com> <20120925214114.GB5372@phenom.dumpdata.com> From: William Dauchy Date: Fri, 5 Oct 2012 16:06:43 +0200 Message-ID: To: Konrad Rzeszutek Wilk Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Error getting mfn X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > (XEN) mm.c:908:d0 Error getting mfn 2009b (pfn 5555555555555555) from > L1 entry 000000002009b023 for l1e_owner=0, pg_owner=0 For those interested, applying the following commit fixes my issue; found it through a bisection. 83d51ab xen/setup: update VA mapping when releasing memory during setup I however had to cherry pick lots of previous commits (p2m related) to be able to apply the patch on top of a 3.4.12 kernel. It's a shame that it sounds impossible to backport it for the stable tree since the issue will remain in those stable releases. -- William _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:07:20 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:07:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8Yb-0007yq-Th; Fri, 05 Oct 2012 14:07:13 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8Ya-0007xP-KI for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 14:07:12 +0000 X-Env-Sender: wdauchy@gmail.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1349446024!6613253!1 X-Originating-IP: [209.85.160.43] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31854 invoked from network); 5 Oct 2012 14:07:06 -0000 Received: from mail-pb0-f43.google.com (HELO mail-pb0-f43.google.com) (209.85.160.43) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:07:06 -0000 Received: by mail-pb0-f43.google.com with SMTP id jt11so2102009pbb.30 for ; Fri, 05 Oct 2012 07:07:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=YH4tPNSBZELedSDLSzlT/bPMCoADFUcr6dqw7X+jCm0=; b=Au3DneblooOX3XXmR4GwS/Ot818pC9BYYvT4PrW3j5IEadTqHVMlTKKp7zrnUqFMdk GDL+ekSkusiWbErmqw93NxNPXwmESgr0OI6opTc+4LgpanlY7ZtGH8Oky1AUdQMWa48d 7gVvMmo4pIUmDoiYdQZzndPb0UgV8pFE4+E5VywxW4fyzMrLn5dJ6I4MrV1QIIgG1ahZ NFNWzQoFjLT4D686UNiRJbEwI7WB1hcXu7c1zyTYXdjMA6TNfzEC1AtFf07xgYTiJSTN xLd7po1wMvARFY39qH7BqZ0KKYsCoyIFag0dSXr6FBD91SbrcyjCz8vkGyHjcQ/g3xYZ udpA== Received: by 10.68.217.201 with SMTP id pa9mr31007493pbc.45.1349446024504; Fri, 05 Oct 2012 07:07:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.135.42 with HTTP; Fri, 5 Oct 2012 07:06:43 -0700 (PDT) In-Reply-To: <20120925214114.GB5372@phenom.dumpdata.com> References: <20120918133650.GC12053@phenom.dumpdata.com> <20120920134851.GB1998@localhost.localdomain> <20120920162337.GB8912@reaktio.net> <20120920163525.GC8912@reaktio.net> <20120920212823.GE27312@konrad-lan.dumpdata.com> <20120925214114.GB5372@phenom.dumpdata.com> From: William Dauchy Date: Fri, 5 Oct 2012 16:06:43 +0200 Message-ID: To: Konrad Rzeszutek Wilk Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Error getting mfn X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org > (XEN) mm.c:908:d0 Error getting mfn 2009b (pfn 5555555555555555) from > L1 entry 000000002009b023 for l1e_owner=0, pg_owner=0 For those interested, applying the following commit fixes my issue; found it through a bisection. 83d51ab xen/setup: update VA mapping when releasing memory during setup I however had to cherry pick lots of previous commits (p2m related) to be able to apply the patch on top of a 3.4.12 kernel. It's a shame that it sounds impossible to backport it for the stable tree since the issue will remain in those stable releases. -- William _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:07:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:07:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8ZC-000888-C8; Fri, 05 Oct 2012 14:07:50 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8ZA-00087e-MU for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:07:49 +0000 Received: from [85.158.139.211:18601] by server-2.bemta-5.messagelabs.com id E7/1E-28944-3B9EE605; Fri, 05 Oct 2012 14:07:47 +0000 X-Env-Sender: Christoph.Egger@amd.com X-Msg-Ref: server-9.tower-206.messagelabs.com!1349446065!19714115!1 X-Originating-IP: [216.32.180.31] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4719 invoked from network); 5 Oct 2012 14:07:46 -0000 Received: from va3ehsobe005.messaging.microsoft.com (HELO va3outboundpool.messaging.microsoft.com) (216.32.180.31) by server-9.tower-206.messagelabs.com with AES128-SHA encrypted SMTP; 5 Oct 2012 14:07:46 -0000 Received: from mail120-va3-R.bigfish.com (10.7.14.246) by VA3EHSOBE011.bigfish.com (10.7.40.61) with Microsoft SMTP Server id 14.1.225.23; Fri, 5 Oct 2012 14:07:44 +0000 Received: from mail120-va3 (localhost [127.0.0.1]) by mail120-va3-R.bigfish.com (Postfix) with ESMTP id AE6E534009A for ; Fri, 5 Oct 2012 14:07:44 +0000 (UTC) X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null); IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: VPS0(zzc85fhc85dhzz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12bdh137ah1441h34h1155h) Received: from mail120-va3 (localhost.localdomain [127.0.0.1]) by mail120-va3 (MessageSwitch) id 1349446062186441_19331; Fri, 5 Oct 2012 14:07:42 +0000 (UTC) Received: from VA3EHSMHS023.bigfish.com (unknown [10.7.14.249]) by mail120-va3.bigfish.com (Postfix) with ESMTP id 205EF400074 for ; Fri, 5 Oct 2012 14:07:42 +0000 (UTC) Received: from ausb3twp02.amd.com (163.181.249.109) by VA3EHSMHS023.bigfish.com (10.7.99.33) with Microsoft SMTP Server id 14.1.225.23; Fri, 5 Oct 2012 14:07:40 +0000 X-WSS-ID: 0MBFB8M-02-FIO-02 X-M-MSG: Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com [163.181.249.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ausb3twp02.amd.com (Axway MailGate 3.8.1) with ESMTP id 2F1F9C8078 for ; Fri, 5 Oct 2012 09:07:34 -0500 (CDT) Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep02.amd.com (163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1; Fri, 5 Oct 2012 09:07:57 -0500 Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag01.amd.com (163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 5 Oct 2012 09:07:37 -0500 Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com (172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 5 Oct 2012 10:07:36 -0400 Message-ID: <506EE9A7.6090009@amd.com> Date: Fri, 5 Oct 2012 16:07:35 +0200 From: Christoph Egger User-Agent: Mozilla/5.0 (X11; NetBSD amd64; rv:11.0) Gecko/20120404 Thunderbird/11.0 MIME-Version: 1.0 To: "xen-devel@lists.xen.org" Content-Type: multipart/mixed; boundary="------------030605040308050803000702" X-OriginatorOrg: amd.com Subject: [Xen-devel] [PATCH] tools/xen-mceinj: support AMD X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --------------030605040308050803000702 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit xen-mceinj: Support AMD Signed-off-by: Christoph Egger -- ---to satisfy European Law for business letters: Advanced Micro Devices GmbH Einsteinring 24, 85689 Dornach b. Muenchen Geschaeftsfuehrer: Alberto Bozzo Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632 --------------030605040308050803000702 Content-Type: text/plain; charset="us-ascii"; name="xen_mceinj.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="xen_mceinj.diff" Content-Description: xen_mceinj.diff # User Christoph Egger # Date 1349437062 -7200 xen mceinj: support AMD. Signed-off-by: Christoph Egger diff -r 21704bc429b4 -r 1a3eea784e09 tools/tests/mce-test/tools/xen-mceinj.c --- a/tools/tests/mce-test/tools/xen-mceinj.c +++ b/tools/tests/mce-test/tools/xen-mceinj.c @@ -1,6 +1,7 @@ /* * xen-mceinj.c: utilities to inject fake MCE for x86. * Copyright (c) 2010, Intel Corporation. + * Copyright (c) 2012, AMD Cooperation Inc. * * This program is free software; you can redistribute it and/or modify it * under the terms and conditions of the GNU General Public License, @@ -18,6 +19,7 @@ * Authors: Yunhong Jiang * Haicheng Li * Xudong Hao + * Christoph Egger */ @@ -44,11 +46,14 @@ #define MCi_type_STATUS 0x1 #define MCi_type_ADDR 0x2 #define MCi_type_MISC 0x3 -#define MCi_type_CTL2 0x4 +#define MC4_type_MISC1 0x4 +#define MC4_type_MISC2 0x5 +#define MC4_type_MISC3 0x6 +#define MCi_type_CTL2 0x7 #define INVALID_MSR ~0UL -/* Intel MSRs */ +/* X86 machine check MSRs */ #define MSR_IA32_MCG_CAP 0x00000179 #define MSR_IA32_MCG_STATUS 0x0000017a #define MSR_IA32_MCG_CTL 0x0000017b @@ -56,35 +61,66 @@ #define MSR_IA32_MC0_STATUS 0x00000401 #define MSR_IA32_MC0_ADDR 0x00000402 #define MSR_IA32_MC0_MISC 0x00000403 + +/* Intel MSRs */ #define MSR_IA32_MC0_CTL2 0x00000280 -/* LLC (Last Level Cache) EWB (Explicit Write Back) SRAO MCE */ +/* Intel: LLC (Last Level Cache) EWB (Explicit Write Back) SRAO MCE */ #define MCG_STATUS_SRAO_LLC_VAL 0x5 #define MCE_SRAO_LLC_BANK 0x7 #define MCi_STATUS_SRAO_LLC_VAL 0xBD2000008000017AUL #define MCi_MISC_SRAO_LLC_VAL 0x86UL -/* Memory Patrol Scrub SRAO MCE */ +/* Intel: Memory Patrol Scrub SRAO MCE */ #define MCG_STATUS_SRAO_MEM_VAL 0x5 #define MCE_SRAO_MEM_BANK 0x8 #define MCi_STATUS_SRAO_MEM_VAL 0xBD000000004000CFUL #define MCi_MISC_SRAO_MEM_VAL 0x86UL -/* LLC EWB UCNA Error */ +/* Intel: LLC EWB UCNA Error */ #define MCG_STATUS_UCNA_LLC_VAL 0x0 #define CMCI_UCNA_LLC_BANK 0x9 #define MCi_STATUS_UCNA_LLC_VAL 0xBC20000080000136UL #define MCi_MISC_UCNA_LLC_VAL 0x86UL -/* Error Types */ -#define MCE_SRAO_MEM 0x0 -#define MCE_SRAO_LLC 0x1 -#define CMCI_UCNA_LLC 0x2 +/* Intel: Error Types */ +#define INTEL_MCE_SRAO_MEM 0x0 +#define INTEL_MCE_SRAO_LLC 0x1 +#define INTEL_CMCI_UCNA_LLC 0x2 + +/* AMD: Memory Error */ +#define MCG_STATUS_MEM_VAL 0x5 +#define MCE_MEM_BANK 0x4 +#define MCi_STATUS_MEM_VAL 0xb4000000001c0100UL +//#define MCi_STATUS_MEM_VAL 0xb600000000000100UL +#define MCi_MISC_MEM_VAL 0x0 + +/* AMD: L3 Cache Error */ +#define MCG_STATUS_L3_VAL 0x5 +#define MCE_L3_BANK 0x4 +#define MCi_STATUS_L3_VAL 0xbc000400001c010bULL +#define MC4_MISC0_VAL 0x0 +#define MC4_MISC1_VAL 0x0 +#define MC4_MISC2_L3_VAL 0xc008000000000003ULL + +/* AMD: CPU corruption error */ +#define MCG_STATUS_CPU_VAL 0x5 +#define MCE_CPU_BANK 0x2 +#define MCi_STATUS_CPU_VAL 0x9200000000000000ULL +//#define MCi_STATUS_CPU_VAL 0xb200000000000000ULL + +/* AMD: Error Types */ +#define AMD_MCE_MEM 0x20 /* memory error */ +#define AMD_MCE_L3 0x21 /* l3 cache */ #define LOGFILE stdout int dump; +int opt_exception; struct xen_mc_msrinject msr_inj; +int cpu_is_amd; +int cpu_is_intel; + static void Lprintf(const char *fmt, ...) { @@ -145,7 +181,7 @@ static int mca_cpuinfo(xc_interface *xc_ return 0; } -static int inject_cmci(xc_interface *xc_handle, int cpu_nr) +static int intel_inject_cmci(xc_interface *xc_handle) { struct xen_mc mc; int nr_cpus; @@ -191,6 +227,15 @@ static uint64_t bank_addr(int bank, int case MCi_type_MISC: addr = MSR_IA32_MC0_CTL + (bank * 4) + type; break; + case MC4_type_MISC1: + addr = 0xc0000408; + break; + case MC4_type_MISC2: + addr = 0xc0000409; + break; + case MC4_type_MISC3: + addr = 0xc000040a; + break; case MCi_type_CTL2: addr = MSR_IA32_MC0_CTL2 + bank; break; @@ -356,12 +401,11 @@ static int inject_mci_status(xc_interfac } static int inject_mci_misc(xc_interface *xc_handle, - uint32_t cpu_nr, - uint64_t bank, - uint64_t val) + uint32_t cpu_nr, uint32_t misctype, + uint64_t bank, uint64_t val) { return add_msr_bank_intpose(xc_handle, cpu_nr, MC_MSRINJ_F_INTERPOSE, - MCi_type_MISC, bank, val); + MCi_type_MISC + misctype, bank, val); } static int inject_mci_addr(xc_interface *xc_handle, @@ -373,10 +417,8 @@ static int inject_mci_addr(xc_interface MCi_type_ADDR, bank, val); } -static int inject_llc_srao(xc_interface *xc_handle, - uint32_t cpu_nr, - uint32_t domain, - uint64_t gaddr) +static int intel_inject_llc_srao(xc_interface *xc_handle, + uint32_t cpu_nr, uint32_t domain, uint64_t gaddr) { uint64_t gpfn, mfn, haddr; int ret = 0; @@ -390,7 +432,7 @@ static int inject_llc_srao(xc_interface if ( ret ) err(xc_handle, "Failed to inject MCi_STATUS MSR\n"); - ret = inject_mci_misc(xc_handle, cpu_nr, + ret = inject_mci_misc(xc_handle, cpu_nr, 0, MCE_SRAO_LLC_BANK, MCi_MISC_SRAO_LLC_VAL); if ( ret ) err(xc_handle, "Failed to inject MCi_MISC MSR\n"); @@ -407,17 +449,17 @@ static int inject_llc_srao(xc_interface ret = flush_msr_inj(xc_handle); if ( ret ) err(xc_handle, "Failed to inject MSR\n"); - ret = inject_mce(xc_handle, cpu_nr); - if ( ret ) - err(xc_handle, "Failed to inject MCE error\n"); + if (opt_exception) { + ret = inject_mce(xc_handle, cpu_nr); + if ( ret ) + err(xc_handle, "Failed to inject MCE error\n"); + } return 0; } -static int inject_mem_srao(xc_interface *xc_handle, - uint32_t cpu_nr, - uint32_t domain, - uint64_t gaddr) +static int intel_inject_mem_srao(xc_interface *xc_handle, + uint32_t cpu_nr, uint32_t domain, uint64_t gaddr) { uint64_t gpfn, mfn, haddr; int ret = 0; @@ -431,7 +473,7 @@ static int inject_mem_srao(xc_interface if ( ret ) err(xc_handle, "Failed to inject MCi_STATUS MSR\n"); - ret = inject_mci_misc(xc_handle, cpu_nr, + ret = inject_mci_misc(xc_handle, cpu_nr, 0, MCE_SRAO_MEM_BANK, MCi_MISC_SRAO_MEM_VAL); if ( ret ) err(xc_handle, "Failed to inject MCi_MISC MSR\n"); @@ -448,17 +490,17 @@ static int inject_mem_srao(xc_interface ret = flush_msr_inj(xc_handle); if ( ret ) err(xc_handle, "Failed to inject MSR\n"); - ret = inject_mce(xc_handle, cpu_nr); - if ( ret ) - err(xc_handle, "Failed to inject MCE error\n"); + if (opt_exception) { + ret = inject_mce(xc_handle, cpu_nr); + if ( ret ) + err(xc_handle, "Failed to inject MCE error\n"); + } return 0; } -static int inject_llc_ucna(xc_interface *xc_handle, - uint32_t cpu_nr, - uint32_t domain, - uint64_t gaddr) +static int intel_inject_llc_ucna(xc_interface *xc_handle, + uint32_t cpu_nr, uint32_t domain, uint64_t gaddr) { uint64_t gpfn, mfn, haddr; int ret = 0; @@ -472,7 +514,7 @@ static int inject_llc_ucna(xc_interface if ( ret ) err(xc_handle, "Failed to inject MCi_STATUS MSR\n"); - ret = inject_mci_misc(xc_handle, cpu_nr, + ret = inject_mci_misc(xc_handle, cpu_nr, 0, CMCI_UCNA_LLC_BANK, MCi_MISC_UCNA_LLC_VAL); if ( ret ) err(xc_handle, "Failed to inject MCi_MISC MSR\n"); @@ -489,13 +531,108 @@ static int inject_llc_ucna(xc_interface ret = flush_msr_inj(xc_handle); if ( ret ) err(xc_handle, "Failed to inject MSR\n"); - ret = inject_cmci(xc_handle, cpu_nr); + ret = intel_inject_cmci(xc_handle); if ( ret ) err(xc_handle, "Failed to inject MCE error\n"); return 0; } +static int amd_inject_mem(xc_interface *xc_handle, + uint32_t cpu_nr, uint32_t domain, uint64_t gaddr) +{ + uint64_t gpfn, mfn, haddr; + int ret = 0; + + ret = inject_mcg_status(xc_handle, cpu_nr, MCG_STATUS_MEM_VAL); + if ( ret ) + err(xc_handle, "Failed to inject MCG_STATUS MSR\n"); + + ret = inject_mci_status(xc_handle, cpu_nr, + MCE_MEM_BANK, MCi_STATUS_MEM_VAL); + if ( ret ) + err(xc_handle, "Failed to inject MCi_STATUS MSR\n"); + + ret = inject_mci_misc(xc_handle, cpu_nr, 0, + MCE_MEM_BANK, MCi_MISC_MEM_VAL); + if ( ret ) + err(xc_handle, "Failed to inject MCi_MISC MSR\n"); + + gpfn = gaddr >> PAGE_SHIFT; + mfn = mca_gpfn_to_mfn(xc_handle, domain, gpfn); + if (!mfn_valid(mfn)) + err(xc_handle, "The MFN is not valid\n"); + haddr = (mfn << PAGE_SHIFT) | (gaddr & (PAGE_SIZE - 1)); + ret = inject_mci_addr(xc_handle, cpu_nr, MCE_MEM_BANK, haddr); + if ( ret ) + err(xc_handle, "Failed to inject MCi_ADDR MSR\n"); + + ret = flush_msr_inj(xc_handle); + if ( ret ) + err(xc_handle, "Failed to inject MSR\n"); + + if (opt_exception) { + ret = inject_mce(xc_handle, cpu_nr); + if ( ret ) + err(xc_handle, "Failed to inject MCE error\n"); + } + + return 0; +} + +static int amd_inject_l3(xc_interface *xc_handle, + uint32_t cpu_nr, uint32_t domain, uint64_t gaddr) +{ + uint64_t gpfn, mfn, haddr; + int ret = 0; + + ret = inject_mcg_status(xc_handle, cpu_nr, MCG_STATUS_L3_VAL); + if ( ret ) + err(xc_handle, "Failed to inject MCG_STATUS MSR\n"); + + ret = inject_mci_status(xc_handle, cpu_nr, + MCE_L3_BANK, MCi_STATUS_L3_VAL); + if ( ret ) + err(xc_handle, "Failed to inject MCi_STATUS MSR\n"); + + ret = inject_mci_misc(xc_handle, cpu_nr, 0, + MCE_L3_BANK, MC4_MISC0_VAL); + if ( ret ) + err(xc_handle, "Failed to inject MC4_MISC0 MSR\n"); + + ret = inject_mci_misc(xc_handle, cpu_nr, 1, + MCE_L3_BANK, MC4_MISC1_VAL); + if ( ret ) + err(xc_handle, "Failed to inject MC4_MISC1 MSR\n"); + + ret = inject_mci_misc(xc_handle, cpu_nr, 2, + MCE_L3_BANK, MC4_MISC2_L3_VAL); + if ( ret ) + err(xc_handle, "Failed to inject MC4_MISC2 MSR\n"); + + gpfn = gaddr >> PAGE_SHIFT; + mfn = mca_gpfn_to_mfn(xc_handle, domain, gpfn); + if (!mfn_valid(mfn)) + err(xc_handle, "The MFN is not valid\n"); + haddr = (mfn << PAGE_SHIFT) | (gaddr & (PAGE_SIZE - 1)); + ret = inject_mci_addr(xc_handle, cpu_nr, MCE_L3_BANK, haddr); + if ( ret ) + err(xc_handle, "Failed to inject MCi_ADDR MSR\n"); + + ret = flush_msr_inj(xc_handle); + if ( ret ) + err(xc_handle, "Failed to inject MSR\n"); + + if (opt_exception) { + ret = inject_mce(xc_handle, cpu_nr); + if ( ret ) + err(xc_handle, "Failed to inject MCE error\n"); + } + + return 0; +} + + static long xs_get_dom_mem(int domid) { char path[128]; @@ -508,7 +645,7 @@ static long xs_get_dom_mem(int domid) if (!xs) return -1; - sprintf(path, "/local/domain/%d/memory/target", domid); + snprintf(path, sizeof(path), "/local/domain/%d/memory/target", domid); memstr = xs_read(xs, XBT_NULL, path, &plen); xs_daemon_close(xs); @@ -540,30 +677,80 @@ static void help(void) " -D, --dump dump addr info without error injection\n" " -c, --cpu=CPU_ID target CPU\n" " -d, --domain=DomID target domain, the default is Xen itself\n" + " -e raise MCE exception\n" " -h, --help print this page\n" " -p, --phyaddr physical address\n" " -t, --type=error error type\n" - " 0 : MCE_SRAO_MEM\n" - " 1 : MCE_SRAO_LLC\n" - " 2 : CMCI_UCNA_LLC\n" + " 0x0 : MCE_SRAO_MEM (Intel only)\n" + " 0x1 : MCE_SRAO_LLC (Intel only)\n" + " 0x2 : CMCI_UCNA_LLC (Intel only)\n" + " 0x20: DRAM error (AMD only)\n" + " 0x21: L3 cache error (AMD only)\n" "\n" ); } +static void cpuid(const unsigned int *input, unsigned int *regs) +{ + unsigned int count = (input[1] == XEN_CPUID_INPUT_UNUSED) ? 0 : input[1]; + asm ( +#ifdef __i386__ + "push %%ebx; push %%edx\n\t" +#else + "push %%rbx; push %%rdx\n\t" +#endif + "cpuid\n\t" + "mov %%ebx,4(%4)\n\t" + "mov %%edx,12(%4)\n\t" +#ifdef __i386__ + "pop %%edx; pop %%ebx\n\t" +#else + "pop %%rdx; pop %%rbx\n\t" +#endif + : "=a" (regs[0]), "=c" (regs[2]) + : "0" (input[0]), "1" (count), "S" (regs) + : "memory" ); +} + +/* Get the manufacturer brand name of the host processor. */ +static void cpuid_brand_get(char *str) +{ + unsigned int input[2] = { 0, 0 }; + unsigned int regs[4]; + + cpuid(input, regs); + + *(uint32_t *)(str + 0) = regs[1]; + *(uint32_t *)(str + 4) = regs[3]; + *(uint32_t *)(str + 8) = regs[2]; + str[12] = '\0'; +} + int main(int argc, char *argv[]) { - int type = MCE_SRAO_MEM; + int type; int c, opt_index; uint32_t domid; xc_interface *xc_handle; - int cpu_nr; - int64_t gaddr, gpfn, mfn, haddr, max_gpa; + unsigned int cpu_nr; + uint64_t gaddr, gpfn, mfn, haddr, max_gpa; + char cpu_brand[13]; /* Default Value */ domid = DOMID_XEN; gaddr = 0x180020; cpu_nr = 0; + cpu_is_amd = cpu_is_intel = 0; + cpuid_brand_get(cpu_brand); + if (strstr(cpu_brand, "AMD")) + cpu_is_amd = 1; + else + cpu_is_intel = 1; + + if (cpu_is_intel) + type = INTEL_MCE_SRAO_MEM; + init_msr_inj(); xc_handle = xc_interface_open(0, 0, 0); if ( !xc_handle ) { @@ -571,8 +758,8 @@ int main(int argc, char *argv[]) exit(EXIT_FAILURE); } - while ( 1 ) { - c = getopt_long(argc, argv, "c:Dd:t:hp:r", opts, &opt_index); + for (;;) { + c = getopt_long(argc, argv, "c:Dd:t:hp:r:e", opts, &opt_index); if ( c == -1 ) break; switch ( c ) { @@ -580,23 +767,26 @@ int main(int argc, char *argv[]) dump=1; break; case 'c': - cpu_nr = strtol(optarg, &optarg, 10); + cpu_nr = strtoul(optarg, &optarg, 0); if ( strlen(optarg) != 0 ) err(xc_handle, "Please input a digit parameter for CPU\n"); break; case 'd': - domid = strtol(optarg, &optarg, 10); + domid = strtoul(optarg, &optarg, 0); if ( strlen(optarg) != 0 ) err(xc_handle, "Please input a digit parameter for domain\n"); break; case 'p': - gaddr = strtol(optarg, &optarg, 0); + gaddr = strtoul(optarg, &optarg, 0); if ( strlen(optarg) != 0 ) err(xc_handle, "Please input correct page address\n"); break; case 't': type = strtol(optarg, NULL, 0); break; + case 'e': + opt_exception = 1; + break; case 'h': default: help(); @@ -627,16 +817,26 @@ int main(int argc, char *argv[]) goto out; } - switch ( type ) - { - case MCE_SRAO_MEM: - inject_mem_srao(xc_handle, cpu_nr, domid, gaddr); + switch ( type ) { + case INTEL_MCE_SRAO_MEM: + if ( cpu_is_intel ) + intel_inject_mem_srao(xc_handle, cpu_nr, domid, gaddr); break; - case MCE_SRAO_LLC: - inject_llc_srao(xc_handle, cpu_nr, domid, gaddr); + case INTEL_MCE_SRAO_LLC: + if ( cpu_is_intel ) + intel_inject_llc_srao(xc_handle, cpu_nr, domid, gaddr); break; - case CMCI_UCNA_LLC: - inject_llc_ucna(xc_handle, cpu_nr, domid, gaddr); + case INTEL_CMCI_UCNA_LLC: + if ( cpu_is_intel ) + intel_inject_llc_ucna(xc_handle, cpu_nr, domid, gaddr); + break; + case AMD_MCE_MEM: + if ( cpu_is_amd ) + amd_inject_mem(xc_handle, cpu_nr, domid, gaddr); + break; + case AMD_MCE_L3: + if ( cpu_is_amd ) + amd_inject_l3(xc_handle, cpu_nr, domid, gaddr); break; default: err(xc_handle, "Unsupported error type\n"); --------------030605040308050803000702 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --------------030605040308050803000702-- From xen-devel-bounces@lists.xen.org Fri Oct 05 14:07:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:07:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8ZC-000888-C8; Fri, 05 Oct 2012 14:07:50 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8ZA-00087e-MU for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:07:49 +0000 Received: from [85.158.139.211:18601] by server-2.bemta-5.messagelabs.com id E7/1E-28944-3B9EE605; Fri, 05 Oct 2012 14:07:47 +0000 X-Env-Sender: Christoph.Egger@amd.com X-Msg-Ref: server-9.tower-206.messagelabs.com!1349446065!19714115!1 X-Originating-IP: [216.32.180.31] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4719 invoked from network); 5 Oct 2012 14:07:46 -0000 Received: from va3ehsobe005.messaging.microsoft.com (HELO va3outboundpool.messaging.microsoft.com) (216.32.180.31) by server-9.tower-206.messagelabs.com with AES128-SHA encrypted SMTP; 5 Oct 2012 14:07:46 -0000 Received: from mail120-va3-R.bigfish.com (10.7.14.246) by VA3EHSOBE011.bigfish.com (10.7.40.61) with Microsoft SMTP Server id 14.1.225.23; Fri, 5 Oct 2012 14:07:44 +0000 Received: from mail120-va3 (localhost [127.0.0.1]) by mail120-va3-R.bigfish.com (Postfix) with ESMTP id AE6E534009A for ; Fri, 5 Oct 2012 14:07:44 +0000 (UTC) X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null); IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: VPS0(zzc85fhc85dhzz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12bdh137ah1441h34h1155h) Received: from mail120-va3 (localhost.localdomain [127.0.0.1]) by mail120-va3 (MessageSwitch) id 1349446062186441_19331; Fri, 5 Oct 2012 14:07:42 +0000 (UTC) Received: from VA3EHSMHS023.bigfish.com (unknown [10.7.14.249]) by mail120-va3.bigfish.com (Postfix) with ESMTP id 205EF400074 for ; Fri, 5 Oct 2012 14:07:42 +0000 (UTC) Received: from ausb3twp02.amd.com (163.181.249.109) by VA3EHSMHS023.bigfish.com (10.7.99.33) with Microsoft SMTP Server id 14.1.225.23; Fri, 5 Oct 2012 14:07:40 +0000 X-WSS-ID: 0MBFB8M-02-FIO-02 X-M-MSG: Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com [163.181.249.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ausb3twp02.amd.com (Axway MailGate 3.8.1) with ESMTP id 2F1F9C8078 for ; Fri, 5 Oct 2012 09:07:34 -0500 (CDT) Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep02.amd.com (163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1; Fri, 5 Oct 2012 09:07:57 -0500 Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag01.amd.com (163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 5 Oct 2012 09:07:37 -0500 Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com (172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 5 Oct 2012 10:07:36 -0400 Message-ID: <506EE9A7.6090009@amd.com> Date: Fri, 5 Oct 2012 16:07:35 +0200 From: Christoph Egger User-Agent: Mozilla/5.0 (X11; NetBSD amd64; rv:11.0) Gecko/20120404 Thunderbird/11.0 MIME-Version: 1.0 To: "xen-devel@lists.xen.org" Content-Type: multipart/mixed; boundary="------------030605040308050803000702" X-OriginatorOrg: amd.com Subject: [Xen-devel] [PATCH] tools/xen-mceinj: support AMD X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --------------030605040308050803000702 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit xen-mceinj: Support AMD Signed-off-by: Christoph Egger -- ---to satisfy European Law for business letters: Advanced Micro Devices GmbH Einsteinring 24, 85689 Dornach b. Muenchen Geschaeftsfuehrer: Alberto Bozzo Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632 --------------030605040308050803000702 Content-Type: text/plain; charset="us-ascii"; name="xen_mceinj.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="xen_mceinj.diff" Content-Description: xen_mceinj.diff # User Christoph Egger # Date 1349437062 -7200 xen mceinj: support AMD. Signed-off-by: Christoph Egger diff -r 21704bc429b4 -r 1a3eea784e09 tools/tests/mce-test/tools/xen-mceinj.c --- a/tools/tests/mce-test/tools/xen-mceinj.c +++ b/tools/tests/mce-test/tools/xen-mceinj.c @@ -1,6 +1,7 @@ /* * xen-mceinj.c: utilities to inject fake MCE for x86. * Copyright (c) 2010, Intel Corporation. + * Copyright (c) 2012, AMD Cooperation Inc. * * This program is free software; you can redistribute it and/or modify it * under the terms and conditions of the GNU General Public License, @@ -18,6 +19,7 @@ * Authors: Yunhong Jiang * Haicheng Li * Xudong Hao + * Christoph Egger */ @@ -44,11 +46,14 @@ #define MCi_type_STATUS 0x1 #define MCi_type_ADDR 0x2 #define MCi_type_MISC 0x3 -#define MCi_type_CTL2 0x4 +#define MC4_type_MISC1 0x4 +#define MC4_type_MISC2 0x5 +#define MC4_type_MISC3 0x6 +#define MCi_type_CTL2 0x7 #define INVALID_MSR ~0UL -/* Intel MSRs */ +/* X86 machine check MSRs */ #define MSR_IA32_MCG_CAP 0x00000179 #define MSR_IA32_MCG_STATUS 0x0000017a #define MSR_IA32_MCG_CTL 0x0000017b @@ -56,35 +61,66 @@ #define MSR_IA32_MC0_STATUS 0x00000401 #define MSR_IA32_MC0_ADDR 0x00000402 #define MSR_IA32_MC0_MISC 0x00000403 + +/* Intel MSRs */ #define MSR_IA32_MC0_CTL2 0x00000280 -/* LLC (Last Level Cache) EWB (Explicit Write Back) SRAO MCE */ +/* Intel: LLC (Last Level Cache) EWB (Explicit Write Back) SRAO MCE */ #define MCG_STATUS_SRAO_LLC_VAL 0x5 #define MCE_SRAO_LLC_BANK 0x7 #define MCi_STATUS_SRAO_LLC_VAL 0xBD2000008000017AUL #define MCi_MISC_SRAO_LLC_VAL 0x86UL -/* Memory Patrol Scrub SRAO MCE */ +/* Intel: Memory Patrol Scrub SRAO MCE */ #define MCG_STATUS_SRAO_MEM_VAL 0x5 #define MCE_SRAO_MEM_BANK 0x8 #define MCi_STATUS_SRAO_MEM_VAL 0xBD000000004000CFUL #define MCi_MISC_SRAO_MEM_VAL 0x86UL -/* LLC EWB UCNA Error */ +/* Intel: LLC EWB UCNA Error */ #define MCG_STATUS_UCNA_LLC_VAL 0x0 #define CMCI_UCNA_LLC_BANK 0x9 #define MCi_STATUS_UCNA_LLC_VAL 0xBC20000080000136UL #define MCi_MISC_UCNA_LLC_VAL 0x86UL -/* Error Types */ -#define MCE_SRAO_MEM 0x0 -#define MCE_SRAO_LLC 0x1 -#define CMCI_UCNA_LLC 0x2 +/* Intel: Error Types */ +#define INTEL_MCE_SRAO_MEM 0x0 +#define INTEL_MCE_SRAO_LLC 0x1 +#define INTEL_CMCI_UCNA_LLC 0x2 + +/* AMD: Memory Error */ +#define MCG_STATUS_MEM_VAL 0x5 +#define MCE_MEM_BANK 0x4 +#define MCi_STATUS_MEM_VAL 0xb4000000001c0100UL +//#define MCi_STATUS_MEM_VAL 0xb600000000000100UL +#define MCi_MISC_MEM_VAL 0x0 + +/* AMD: L3 Cache Error */ +#define MCG_STATUS_L3_VAL 0x5 +#define MCE_L3_BANK 0x4 +#define MCi_STATUS_L3_VAL 0xbc000400001c010bULL +#define MC4_MISC0_VAL 0x0 +#define MC4_MISC1_VAL 0x0 +#define MC4_MISC2_L3_VAL 0xc008000000000003ULL + +/* AMD: CPU corruption error */ +#define MCG_STATUS_CPU_VAL 0x5 +#define MCE_CPU_BANK 0x2 +#define MCi_STATUS_CPU_VAL 0x9200000000000000ULL +//#define MCi_STATUS_CPU_VAL 0xb200000000000000ULL + +/* AMD: Error Types */ +#define AMD_MCE_MEM 0x20 /* memory error */ +#define AMD_MCE_L3 0x21 /* l3 cache */ #define LOGFILE stdout int dump; +int opt_exception; struct xen_mc_msrinject msr_inj; +int cpu_is_amd; +int cpu_is_intel; + static void Lprintf(const char *fmt, ...) { @@ -145,7 +181,7 @@ static int mca_cpuinfo(xc_interface *xc_ return 0; } -static int inject_cmci(xc_interface *xc_handle, int cpu_nr) +static int intel_inject_cmci(xc_interface *xc_handle) { struct xen_mc mc; int nr_cpus; @@ -191,6 +227,15 @@ static uint64_t bank_addr(int bank, int case MCi_type_MISC: addr = MSR_IA32_MC0_CTL + (bank * 4) + type; break; + case MC4_type_MISC1: + addr = 0xc0000408; + break; + case MC4_type_MISC2: + addr = 0xc0000409; + break; + case MC4_type_MISC3: + addr = 0xc000040a; + break; case MCi_type_CTL2: addr = MSR_IA32_MC0_CTL2 + bank; break; @@ -356,12 +401,11 @@ static int inject_mci_status(xc_interfac } static int inject_mci_misc(xc_interface *xc_handle, - uint32_t cpu_nr, - uint64_t bank, - uint64_t val) + uint32_t cpu_nr, uint32_t misctype, + uint64_t bank, uint64_t val) { return add_msr_bank_intpose(xc_handle, cpu_nr, MC_MSRINJ_F_INTERPOSE, - MCi_type_MISC, bank, val); + MCi_type_MISC + misctype, bank, val); } static int inject_mci_addr(xc_interface *xc_handle, @@ -373,10 +417,8 @@ static int inject_mci_addr(xc_interface MCi_type_ADDR, bank, val); } -static int inject_llc_srao(xc_interface *xc_handle, - uint32_t cpu_nr, - uint32_t domain, - uint64_t gaddr) +static int intel_inject_llc_srao(xc_interface *xc_handle, + uint32_t cpu_nr, uint32_t domain, uint64_t gaddr) { uint64_t gpfn, mfn, haddr; int ret = 0; @@ -390,7 +432,7 @@ static int inject_llc_srao(xc_interface if ( ret ) err(xc_handle, "Failed to inject MCi_STATUS MSR\n"); - ret = inject_mci_misc(xc_handle, cpu_nr, + ret = inject_mci_misc(xc_handle, cpu_nr, 0, MCE_SRAO_LLC_BANK, MCi_MISC_SRAO_LLC_VAL); if ( ret ) err(xc_handle, "Failed to inject MCi_MISC MSR\n"); @@ -407,17 +449,17 @@ static int inject_llc_srao(xc_interface ret = flush_msr_inj(xc_handle); if ( ret ) err(xc_handle, "Failed to inject MSR\n"); - ret = inject_mce(xc_handle, cpu_nr); - if ( ret ) - err(xc_handle, "Failed to inject MCE error\n"); + if (opt_exception) { + ret = inject_mce(xc_handle, cpu_nr); + if ( ret ) + err(xc_handle, "Failed to inject MCE error\n"); + } return 0; } -static int inject_mem_srao(xc_interface *xc_handle, - uint32_t cpu_nr, - uint32_t domain, - uint64_t gaddr) +static int intel_inject_mem_srao(xc_interface *xc_handle, + uint32_t cpu_nr, uint32_t domain, uint64_t gaddr) { uint64_t gpfn, mfn, haddr; int ret = 0; @@ -431,7 +473,7 @@ static int inject_mem_srao(xc_interface if ( ret ) err(xc_handle, "Failed to inject MCi_STATUS MSR\n"); - ret = inject_mci_misc(xc_handle, cpu_nr, + ret = inject_mci_misc(xc_handle, cpu_nr, 0, MCE_SRAO_MEM_BANK, MCi_MISC_SRAO_MEM_VAL); if ( ret ) err(xc_handle, "Failed to inject MCi_MISC MSR\n"); @@ -448,17 +490,17 @@ static int inject_mem_srao(xc_interface ret = flush_msr_inj(xc_handle); if ( ret ) err(xc_handle, "Failed to inject MSR\n"); - ret = inject_mce(xc_handle, cpu_nr); - if ( ret ) - err(xc_handle, "Failed to inject MCE error\n"); + if (opt_exception) { + ret = inject_mce(xc_handle, cpu_nr); + if ( ret ) + err(xc_handle, "Failed to inject MCE error\n"); + } return 0; } -static int inject_llc_ucna(xc_interface *xc_handle, - uint32_t cpu_nr, - uint32_t domain, - uint64_t gaddr) +static int intel_inject_llc_ucna(xc_interface *xc_handle, + uint32_t cpu_nr, uint32_t domain, uint64_t gaddr) { uint64_t gpfn, mfn, haddr; int ret = 0; @@ -472,7 +514,7 @@ static int inject_llc_ucna(xc_interface if ( ret ) err(xc_handle, "Failed to inject MCi_STATUS MSR\n"); - ret = inject_mci_misc(xc_handle, cpu_nr, + ret = inject_mci_misc(xc_handle, cpu_nr, 0, CMCI_UCNA_LLC_BANK, MCi_MISC_UCNA_LLC_VAL); if ( ret ) err(xc_handle, "Failed to inject MCi_MISC MSR\n"); @@ -489,13 +531,108 @@ static int inject_llc_ucna(xc_interface ret = flush_msr_inj(xc_handle); if ( ret ) err(xc_handle, "Failed to inject MSR\n"); - ret = inject_cmci(xc_handle, cpu_nr); + ret = intel_inject_cmci(xc_handle); if ( ret ) err(xc_handle, "Failed to inject MCE error\n"); return 0; } +static int amd_inject_mem(xc_interface *xc_handle, + uint32_t cpu_nr, uint32_t domain, uint64_t gaddr) +{ + uint64_t gpfn, mfn, haddr; + int ret = 0; + + ret = inject_mcg_status(xc_handle, cpu_nr, MCG_STATUS_MEM_VAL); + if ( ret ) + err(xc_handle, "Failed to inject MCG_STATUS MSR\n"); + + ret = inject_mci_status(xc_handle, cpu_nr, + MCE_MEM_BANK, MCi_STATUS_MEM_VAL); + if ( ret ) + err(xc_handle, "Failed to inject MCi_STATUS MSR\n"); + + ret = inject_mci_misc(xc_handle, cpu_nr, 0, + MCE_MEM_BANK, MCi_MISC_MEM_VAL); + if ( ret ) + err(xc_handle, "Failed to inject MCi_MISC MSR\n"); + + gpfn = gaddr >> PAGE_SHIFT; + mfn = mca_gpfn_to_mfn(xc_handle, domain, gpfn); + if (!mfn_valid(mfn)) + err(xc_handle, "The MFN is not valid\n"); + haddr = (mfn << PAGE_SHIFT) | (gaddr & (PAGE_SIZE - 1)); + ret = inject_mci_addr(xc_handle, cpu_nr, MCE_MEM_BANK, haddr); + if ( ret ) + err(xc_handle, "Failed to inject MCi_ADDR MSR\n"); + + ret = flush_msr_inj(xc_handle); + if ( ret ) + err(xc_handle, "Failed to inject MSR\n"); + + if (opt_exception) { + ret = inject_mce(xc_handle, cpu_nr); + if ( ret ) + err(xc_handle, "Failed to inject MCE error\n"); + } + + return 0; +} + +static int amd_inject_l3(xc_interface *xc_handle, + uint32_t cpu_nr, uint32_t domain, uint64_t gaddr) +{ + uint64_t gpfn, mfn, haddr; + int ret = 0; + + ret = inject_mcg_status(xc_handle, cpu_nr, MCG_STATUS_L3_VAL); + if ( ret ) + err(xc_handle, "Failed to inject MCG_STATUS MSR\n"); + + ret = inject_mci_status(xc_handle, cpu_nr, + MCE_L3_BANK, MCi_STATUS_L3_VAL); + if ( ret ) + err(xc_handle, "Failed to inject MCi_STATUS MSR\n"); + + ret = inject_mci_misc(xc_handle, cpu_nr, 0, + MCE_L3_BANK, MC4_MISC0_VAL); + if ( ret ) + err(xc_handle, "Failed to inject MC4_MISC0 MSR\n"); + + ret = inject_mci_misc(xc_handle, cpu_nr, 1, + MCE_L3_BANK, MC4_MISC1_VAL); + if ( ret ) + err(xc_handle, "Failed to inject MC4_MISC1 MSR\n"); + + ret = inject_mci_misc(xc_handle, cpu_nr, 2, + MCE_L3_BANK, MC4_MISC2_L3_VAL); + if ( ret ) + err(xc_handle, "Failed to inject MC4_MISC2 MSR\n"); + + gpfn = gaddr >> PAGE_SHIFT; + mfn = mca_gpfn_to_mfn(xc_handle, domain, gpfn); + if (!mfn_valid(mfn)) + err(xc_handle, "The MFN is not valid\n"); + haddr = (mfn << PAGE_SHIFT) | (gaddr & (PAGE_SIZE - 1)); + ret = inject_mci_addr(xc_handle, cpu_nr, MCE_L3_BANK, haddr); + if ( ret ) + err(xc_handle, "Failed to inject MCi_ADDR MSR\n"); + + ret = flush_msr_inj(xc_handle); + if ( ret ) + err(xc_handle, "Failed to inject MSR\n"); + + if (opt_exception) { + ret = inject_mce(xc_handle, cpu_nr); + if ( ret ) + err(xc_handle, "Failed to inject MCE error\n"); + } + + return 0; +} + + static long xs_get_dom_mem(int domid) { char path[128]; @@ -508,7 +645,7 @@ static long xs_get_dom_mem(int domid) if (!xs) return -1; - sprintf(path, "/local/domain/%d/memory/target", domid); + snprintf(path, sizeof(path), "/local/domain/%d/memory/target", domid); memstr = xs_read(xs, XBT_NULL, path, &plen); xs_daemon_close(xs); @@ -540,30 +677,80 @@ static void help(void) " -D, --dump dump addr info without error injection\n" " -c, --cpu=CPU_ID target CPU\n" " -d, --domain=DomID target domain, the default is Xen itself\n" + " -e raise MCE exception\n" " -h, --help print this page\n" " -p, --phyaddr physical address\n" " -t, --type=error error type\n" - " 0 : MCE_SRAO_MEM\n" - " 1 : MCE_SRAO_LLC\n" - " 2 : CMCI_UCNA_LLC\n" + " 0x0 : MCE_SRAO_MEM (Intel only)\n" + " 0x1 : MCE_SRAO_LLC (Intel only)\n" + " 0x2 : CMCI_UCNA_LLC (Intel only)\n" + " 0x20: DRAM error (AMD only)\n" + " 0x21: L3 cache error (AMD only)\n" "\n" ); } +static void cpuid(const unsigned int *input, unsigned int *regs) +{ + unsigned int count = (input[1] == XEN_CPUID_INPUT_UNUSED) ? 0 : input[1]; + asm ( +#ifdef __i386__ + "push %%ebx; push %%edx\n\t" +#else + "push %%rbx; push %%rdx\n\t" +#endif + "cpuid\n\t" + "mov %%ebx,4(%4)\n\t" + "mov %%edx,12(%4)\n\t" +#ifdef __i386__ + "pop %%edx; pop %%ebx\n\t" +#else + "pop %%rdx; pop %%rbx\n\t" +#endif + : "=a" (regs[0]), "=c" (regs[2]) + : "0" (input[0]), "1" (count), "S" (regs) + : "memory" ); +} + +/* Get the manufacturer brand name of the host processor. */ +static void cpuid_brand_get(char *str) +{ + unsigned int input[2] = { 0, 0 }; + unsigned int regs[4]; + + cpuid(input, regs); + + *(uint32_t *)(str + 0) = regs[1]; + *(uint32_t *)(str + 4) = regs[3]; + *(uint32_t *)(str + 8) = regs[2]; + str[12] = '\0'; +} + int main(int argc, char *argv[]) { - int type = MCE_SRAO_MEM; + int type; int c, opt_index; uint32_t domid; xc_interface *xc_handle; - int cpu_nr; - int64_t gaddr, gpfn, mfn, haddr, max_gpa; + unsigned int cpu_nr; + uint64_t gaddr, gpfn, mfn, haddr, max_gpa; + char cpu_brand[13]; /* Default Value */ domid = DOMID_XEN; gaddr = 0x180020; cpu_nr = 0; + cpu_is_amd = cpu_is_intel = 0; + cpuid_brand_get(cpu_brand); + if (strstr(cpu_brand, "AMD")) + cpu_is_amd = 1; + else + cpu_is_intel = 1; + + if (cpu_is_intel) + type = INTEL_MCE_SRAO_MEM; + init_msr_inj(); xc_handle = xc_interface_open(0, 0, 0); if ( !xc_handle ) { @@ -571,8 +758,8 @@ int main(int argc, char *argv[]) exit(EXIT_FAILURE); } - while ( 1 ) { - c = getopt_long(argc, argv, "c:Dd:t:hp:r", opts, &opt_index); + for (;;) { + c = getopt_long(argc, argv, "c:Dd:t:hp:r:e", opts, &opt_index); if ( c == -1 ) break; switch ( c ) { @@ -580,23 +767,26 @@ int main(int argc, char *argv[]) dump=1; break; case 'c': - cpu_nr = strtol(optarg, &optarg, 10); + cpu_nr = strtoul(optarg, &optarg, 0); if ( strlen(optarg) != 0 ) err(xc_handle, "Please input a digit parameter for CPU\n"); break; case 'd': - domid = strtol(optarg, &optarg, 10); + domid = strtoul(optarg, &optarg, 0); if ( strlen(optarg) != 0 ) err(xc_handle, "Please input a digit parameter for domain\n"); break; case 'p': - gaddr = strtol(optarg, &optarg, 0); + gaddr = strtoul(optarg, &optarg, 0); if ( strlen(optarg) != 0 ) err(xc_handle, "Please input correct page address\n"); break; case 't': type = strtol(optarg, NULL, 0); break; + case 'e': + opt_exception = 1; + break; case 'h': default: help(); @@ -627,16 +817,26 @@ int main(int argc, char *argv[]) goto out; } - switch ( type ) - { - case MCE_SRAO_MEM: - inject_mem_srao(xc_handle, cpu_nr, domid, gaddr); + switch ( type ) { + case INTEL_MCE_SRAO_MEM: + if ( cpu_is_intel ) + intel_inject_mem_srao(xc_handle, cpu_nr, domid, gaddr); break; - case MCE_SRAO_LLC: - inject_llc_srao(xc_handle, cpu_nr, domid, gaddr); + case INTEL_MCE_SRAO_LLC: + if ( cpu_is_intel ) + intel_inject_llc_srao(xc_handle, cpu_nr, domid, gaddr); break; - case CMCI_UCNA_LLC: - inject_llc_ucna(xc_handle, cpu_nr, domid, gaddr); + case INTEL_CMCI_UCNA_LLC: + if ( cpu_is_intel ) + intel_inject_llc_ucna(xc_handle, cpu_nr, domid, gaddr); + break; + case AMD_MCE_MEM: + if ( cpu_is_amd ) + amd_inject_mem(xc_handle, cpu_nr, domid, gaddr); + break; + case AMD_MCE_L3: + if ( cpu_is_amd ) + amd_inject_l3(xc_handle, cpu_nr, domid, gaddr); break; default: err(xc_handle, "Unsupported error type\n"); --------------030605040308050803000702 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --------------030605040308050803000702-- From xen-devel-bounces@lists.xen.org Fri Oct 05 14:13:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:13:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8ea-0000Bz-DO; Fri, 05 Oct 2012 14:13:24 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8eZ-0000Bs-Mu for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:13:23 +0000 Received: from [85.158.143.35:10011] by server-1.bemta-4.messagelabs.com id 35/E4-05684-20BEE605; Fri, 05 Oct 2012 14:13:22 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1349446354!14356768!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18601 invoked from network); 5 Oct 2012 14:12:34 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:12:34 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14965765" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 14:12:34 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 15:12:34 +0100 Message-ID: <1349446353.20946.112.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Matthew Fioravante Date: Fri, 5 Oct 2012 15:12:33 +0100 In-Reply-To: <1349186992-14871-1-git-send-email-matthew.fioravante@jhuapl.edu> References: <1349186992-14871-1-git-send-email-matthew.fioravante@jhuapl.edu> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 09/12] add iomem support to libxl X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-10-02 at 15:09 +0100, Matthew Fioravante wrote: > This patch adds a new option for xen config files for > directly mapping hardware io memory into a vm. > > Signed-off-by: Matthew Fioravante I added George's Reviewed-by applied this version, I think it's the right one. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:13:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:13:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8ea-0000Bz-DO; Fri, 05 Oct 2012 14:13:24 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8eZ-0000Bs-Mu for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:13:23 +0000 Received: from [85.158.143.35:10011] by server-1.bemta-4.messagelabs.com id 35/E4-05684-20BEE605; Fri, 05 Oct 2012 14:13:22 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1349446354!14356768!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18601 invoked from network); 5 Oct 2012 14:12:34 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:12:34 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14965765" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 14:12:34 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 15:12:34 +0100 Message-ID: <1349446353.20946.112.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Matthew Fioravante Date: Fri, 5 Oct 2012 15:12:33 +0100 In-Reply-To: <1349186992-14871-1-git-send-email-matthew.fioravante@jhuapl.edu> References: <1349186992-14871-1-git-send-email-matthew.fioravante@jhuapl.edu> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 09/12] add iomem support to libxl X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-10-02 at 15:09 +0100, Matthew Fioravante wrote: > This patch adds a new option for xen config files for > directly mapping hardware io memory into a vm. > > Signed-off-by: Matthew Fioravante I added George's Reviewed-by applied this version, I think it's the right one. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:14:23 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:14:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8fL-0000Gg-Ri; Fri, 05 Oct 2012 14:14:11 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8fK-0000GR-Hj for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:14:10 +0000 Received: from [85.158.143.35:63510] by server-3.bemta-4.messagelabs.com id A7/BB-10986-13BEE605; Fri, 05 Oct 2012 14:14:09 +0000 X-Env-Sender: raistlin.df@gmail.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1349446448!12532791!1 X-Originating-IP: [74.125.82.51] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28259 invoked from network); 5 Oct 2012 14:14:08 -0000 Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com) (74.125.82.51) by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:14:08 -0000 Received: by mail-wg0-f51.google.com with SMTP id ed3so635331wgb.32 for ; Fri, 05 Oct 2012 07:14:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:content-transfer-encoding:subject :message-id:user-agent:date:from:to:cc; bh=wCQ82JgZ26wcAlNOW8upu8flNQxQkR1/7NLQ7OKQcp8=; b=quFQNnZ8AhKEY2uibRz6OXmxkoSuRkb8E36U7BbxvlSCrRWE5fkN2Iu9tRN2jg2lbb xBLGg/mwoBB0S4zCThhYvpZdEXoUVYrOzcPMdN3ChDsvQG9CFFsbqI16Yn2R9hXCJR+K vxziXdsxrzIuUycAyZsEjWVfxLfoHn9wm0/vmyHt5Ck/2ClDKdTpNeWXapEYY8zSvaId dQ+4IyjHUUdSHcHB8QvxNph80ARF9wh48+RjtdiNG5A7nPAsWoon4M1UKzl6jnZeuKYZ XMtSc7gHcq+eZSElSxjp0FPxwdFr26VhYPmSnk4VGBw1D8K60Tpw0jeYynsw358yIDqe FEsQ== Received: by 10.180.84.41 with SMTP id v9mr2205599wiy.8.1349446448487; Fri, 05 Oct 2012 07:14:08 -0700 (PDT) Received: from [127.0.1.1] (ip-170-24.sn3.eutelia.it. [213.136.170.24]) by mx.google.com with ESMTPS id fb20sm2909341wid.1.2012.10.05.07.14.05 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Oct 2012 07:14:07 -0700 (PDT) MIME-Version: 1.0 Message-Id: User-Agent: Mercurial-patchbomb/2.2.2 Date: Fri, 05 Oct 2012 16:08:18 +0200 From: Dario Faggioli To: xen-devel@lists.xen.org Cc: Andre Przywara , Ian Campbell , Anil Madhavapeddy , George Dunlap , Andrew Cooper , Juergen Gross , Ian Jackson , Jan Beulich , Marcus Granado , Daniel De Graaf , Matt Wilson Subject: [Xen-devel] [PATCH 0 of 8] NUMA Awareness for the Credit Scheduler X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hi Everyone, Here it comes a patch series instilling some NUMA awareness in the Credit scheduler. What the patches do is teaching the Xen's scheduler how to try maximizing performances on a NUMA host, taking advantage of the information coming from the automatic NUMA placement we have in libxl. Right now, the placement algorithm runs and selects a node (or a set of nodes) where it is best to put a new domain on. Then, all the memory for the new domain is allocated from those node(s) and all the vCPUs of the new domain are pinned to the pCPUs of those node(s). What we do here is, instead of statically pinning the domain's vCPUs to the nodes' pCPUs, have the (Credit) scheduler _prefer_ running them there. That enables most of the performances benefits of "real" pinning, but without its intrinsic lack of flexibility. The above happens by extending to the scheduler the knowledge of a domain's node-affinity. We then ask it to first try to run the domain's vCPUs on one of the nodes the domain has affinity with. Of course, if that turns out to be impossible, it falls back on the old behaviour (i.e., considering vcpu-affinity only). Just allow me to mention that NUMA aware scheduling not only is one of the item of the NUMA roadmap I'm trying to maintain here http://wiki.xen.org/wiki/Xen_NUMA_Roadmap. It is also one of the features we decided we want for Xen 4.3 (and thus it is part of the list of such features that George is maintaining). Up to now, I've been able to thoroughly test this only on my 2 NUMA nodes testbox, by running the SpecJBB2005 benchmark concurrently on multiple VMs, and the results looks really nice. A full set of what I got can be found inside my presentation from last XenSummit, which is available here: http://www.slideshare.net/xen_com_mgr/numa-and-virtualization-the-case-of-xen?ref=http://www.xen.org/xensummit/xs12na_talks/T9.html However, I rerun some of the tests in these last days (since I changed some bits of the implementation) and here's what I got: ------------------------------------------------------- SpecJBB2005 Total Aggregate Throughput ------------------------------------------------------- #VMs No NUMA affinity NUMA affinity & +/- % scheduling ------------------------------------------------------- 2 34653.273 40243.015 +16.13% 4 29883.057 35526.807 +18.88% 6 23512.926 27015.786 +14.89% 8 19120.243 21825.818 +14.15% 10 15676.675 17701.472 +12.91% Basically, results are consistent with what is shown in the super-nice graphs I have in the slides above! :-) As said, this looks nice to me, especially considering that my test machine is quite small, i.e., its 2 nodes are very close to each others from a latency point of view. I really expect more improvement on bigger hardware, where much greater NUMA effect is to be expected. Of course, I myself will continue benchmarking (hopefully, on systems with more than 2 nodes too), but should anyone want to run its own testing, that would be great, so feel free to do that and report results to me and/or to the list! A little bit more about the series: 1/8 xen, libxc: rename xenctl_cpumap to xenctl_bitmap 2/8 xen, libxc: introduce node maps and masks Is some preparation work. 3/8 xen: let the (credit) scheduler know about `node affinity` Is where the vcpu load balancing logic of the credit scheduler is modified to support node-affinity. 4/8 xen: allow for explicitly specifying node-affinity 5/8 libxc: allow for explicitly specifying node-affinity 6/8 libxl: allow for explicitly specifying node-affinity 7/8 libxl: automatic placement deals with node-affinity Is what wires the in-scheduler node-affinity support with the external world. Please, note that patch 4 touches XSM and Flask, which is the area with which I have less experience and less chance to test properly. So, If Daniel and/or anyone interested in that could take a look and comment, that would be awesome. 8/8 xl: report node-affinity for domains Is just some small output enhancement. Thanks and Regards, Dario -- <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:14:23 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:14:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8fL-0000Gg-Ri; Fri, 05 Oct 2012 14:14:11 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8fK-0000GR-Hj for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:14:10 +0000 Received: from [85.158.143.35:63510] by server-3.bemta-4.messagelabs.com id A7/BB-10986-13BEE605; Fri, 05 Oct 2012 14:14:09 +0000 X-Env-Sender: raistlin.df@gmail.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1349446448!12532791!1 X-Originating-IP: [74.125.82.51] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28259 invoked from network); 5 Oct 2012 14:14:08 -0000 Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com) (74.125.82.51) by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:14:08 -0000 Received: by mail-wg0-f51.google.com with SMTP id ed3so635331wgb.32 for ; Fri, 05 Oct 2012 07:14:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:content-transfer-encoding:subject :message-id:user-agent:date:from:to:cc; bh=wCQ82JgZ26wcAlNOW8upu8flNQxQkR1/7NLQ7OKQcp8=; b=quFQNnZ8AhKEY2uibRz6OXmxkoSuRkb8E36U7BbxvlSCrRWE5fkN2Iu9tRN2jg2lbb xBLGg/mwoBB0S4zCThhYvpZdEXoUVYrOzcPMdN3ChDsvQG9CFFsbqI16Yn2R9hXCJR+K vxziXdsxrzIuUycAyZsEjWVfxLfoHn9wm0/vmyHt5Ck/2ClDKdTpNeWXapEYY8zSvaId dQ+4IyjHUUdSHcHB8QvxNph80ARF9wh48+RjtdiNG5A7nPAsWoon4M1UKzl6jnZeuKYZ XMtSc7gHcq+eZSElSxjp0FPxwdFr26VhYPmSnk4VGBw1D8K60Tpw0jeYynsw358yIDqe FEsQ== Received: by 10.180.84.41 with SMTP id v9mr2205599wiy.8.1349446448487; Fri, 05 Oct 2012 07:14:08 -0700 (PDT) Received: from [127.0.1.1] (ip-170-24.sn3.eutelia.it. [213.136.170.24]) by mx.google.com with ESMTPS id fb20sm2909341wid.1.2012.10.05.07.14.05 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Oct 2012 07:14:07 -0700 (PDT) MIME-Version: 1.0 Message-Id: User-Agent: Mercurial-patchbomb/2.2.2 Date: Fri, 05 Oct 2012 16:08:18 +0200 From: Dario Faggioli To: xen-devel@lists.xen.org Cc: Andre Przywara , Ian Campbell , Anil Madhavapeddy , George Dunlap , Andrew Cooper , Juergen Gross , Ian Jackson , Jan Beulich , Marcus Granado , Daniel De Graaf , Matt Wilson Subject: [Xen-devel] [PATCH 0 of 8] NUMA Awareness for the Credit Scheduler X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hi Everyone, Here it comes a patch series instilling some NUMA awareness in the Credit scheduler. What the patches do is teaching the Xen's scheduler how to try maximizing performances on a NUMA host, taking advantage of the information coming from the automatic NUMA placement we have in libxl. Right now, the placement algorithm runs and selects a node (or a set of nodes) where it is best to put a new domain on. Then, all the memory for the new domain is allocated from those node(s) and all the vCPUs of the new domain are pinned to the pCPUs of those node(s). What we do here is, instead of statically pinning the domain's vCPUs to the nodes' pCPUs, have the (Credit) scheduler _prefer_ running them there. That enables most of the performances benefits of "real" pinning, but without its intrinsic lack of flexibility. The above happens by extending to the scheduler the knowledge of a domain's node-affinity. We then ask it to first try to run the domain's vCPUs on one of the nodes the domain has affinity with. Of course, if that turns out to be impossible, it falls back on the old behaviour (i.e., considering vcpu-affinity only). Just allow me to mention that NUMA aware scheduling not only is one of the item of the NUMA roadmap I'm trying to maintain here http://wiki.xen.org/wiki/Xen_NUMA_Roadmap. It is also one of the features we decided we want for Xen 4.3 (and thus it is part of the list of such features that George is maintaining). Up to now, I've been able to thoroughly test this only on my 2 NUMA nodes testbox, by running the SpecJBB2005 benchmark concurrently on multiple VMs, and the results looks really nice. A full set of what I got can be found inside my presentation from last XenSummit, which is available here: http://www.slideshare.net/xen_com_mgr/numa-and-virtualization-the-case-of-xen?ref=http://www.xen.org/xensummit/xs12na_talks/T9.html However, I rerun some of the tests in these last days (since I changed some bits of the implementation) and here's what I got: ------------------------------------------------------- SpecJBB2005 Total Aggregate Throughput ------------------------------------------------------- #VMs No NUMA affinity NUMA affinity & +/- % scheduling ------------------------------------------------------- 2 34653.273 40243.015 +16.13% 4 29883.057 35526.807 +18.88% 6 23512.926 27015.786 +14.89% 8 19120.243 21825.818 +14.15% 10 15676.675 17701.472 +12.91% Basically, results are consistent with what is shown in the super-nice graphs I have in the slides above! :-) As said, this looks nice to me, especially considering that my test machine is quite small, i.e., its 2 nodes are very close to each others from a latency point of view. I really expect more improvement on bigger hardware, where much greater NUMA effect is to be expected. Of course, I myself will continue benchmarking (hopefully, on systems with more than 2 nodes too), but should anyone want to run its own testing, that would be great, so feel free to do that and report results to me and/or to the list! A little bit more about the series: 1/8 xen, libxc: rename xenctl_cpumap to xenctl_bitmap 2/8 xen, libxc: introduce node maps and masks Is some preparation work. 3/8 xen: let the (credit) scheduler know about `node affinity` Is where the vcpu load balancing logic of the credit scheduler is modified to support node-affinity. 4/8 xen: allow for explicitly specifying node-affinity 5/8 libxc: allow for explicitly specifying node-affinity 6/8 libxl: allow for explicitly specifying node-affinity 7/8 libxl: automatic placement deals with node-affinity Is what wires the in-scheduler node-affinity support with the external world. Please, note that patch 4 touches XSM and Flask, which is the area with which I have less experience and less chance to test properly. So, If Daniel and/or anyone interested in that could take a look and comment, that would be awesome. 8/8 xl: report node-affinity for domains Is just some small output enhancement. Thanks and Regards, Dario -- <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:14:30 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:14:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8fR-0000HQ-7V; Fri, 05 Oct 2012 14:14:17 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8fP-0000H8-Nl for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:14:15 +0000 Received: from [85.158.143.35:12527] by server-2.bemta-4.messagelabs.com id 15/90-06610-73BEE605; Fri, 05 Oct 2012 14:14:15 +0000 X-Env-Sender: raistlin.df@gmail.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1349446448!12532791!2 X-Originating-IP: [74.125.82.51] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28466 invoked from network); 5 Oct 2012 14:14:14 -0000 Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com) (74.125.82.51) by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:14:14 -0000 Received: by mail-wg0-f51.google.com with SMTP id ed3so635331wgb.32 for ; Fri, 05 Oct 2012 07:14:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:content-transfer-encoding:subject :x-mercurial-node:message-id:in-reply-to:references:user-agent:date :from:to:cc; bh=EvtnFJbinmGoOPrYYDsp/jbuYF5vjvdJjS1m1YJURhA=; b=rZZ6WVIEfaO4/zdliT+FJ0nWTD7RBHY8IBlDm6d1NwNIiI+4/BF7WH2irVTI8cR6MH 4pPFXK7fMm0NA5OTHctKs+Ut7DUre6beduC/jZTpeFDoTwhPsLNpX6DuJSdpWUjBDzsQ NXUMUFWVprsts5Z2eRqvvKZ8F2sVmRk1jhxyEohIBwvT8eRBqFIiW3kHX70oxW1y33uH cWoZ3tGtyPEydqoBfEJ6L6b7cblTBRrfbpIsBH9/dhv325YSUBcI+IwwCiElkG40ZNhd 4ApDhNz4brL8d3ez815XhqDgiXsGCtLsHRa2lUWKP3xj5VCdehVLz4RkhB+9Ce43o4AO VTtQ== Received: by 10.180.99.194 with SMTP id es2mr3682495wib.15.1349446453823; Fri, 05 Oct 2012 07:14:13 -0700 (PDT) Received: from [127.0.1.1] (ip-170-24.sn3.eutelia.it. [213.136.170.24]) by mx.google.com with ESMTPS id fb20sm2909341wid.1.2012.10.05.07.14.11 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Oct 2012 07:14:13 -0700 (PDT) MIME-Version: 1.0 X-Mercurial-Node: 9e7d4c414d9566832d5254af0a3322a1c5a5f7cf Message-Id: <9e7d4c414d9566832d52.1349446100@Solace> In-Reply-To: References: User-Agent: Mercurial-patchbomb/2.2.2 Date: Fri, 05 Oct 2012 16:08:20 +0200 From: Dario Faggioli To: xen-devel@lists.xen.org Cc: Andre Przywara , Ian Campbell , Anil Madhavapeddy , George Dunlap , Andrew Cooper , Juergen Gross , Ian Jackson , Jan Beulich , Marcus Granado , Daniel De Graaf , Matt Wilson Subject: [Xen-devel] [PATCH 2 of 8] xen, libxc: introduce node maps and masks X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Following suit from cpumap and cpumask implementations. Signed-off-by: Dario Faggioli diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c --- a/tools/libxc/xc_misc.c +++ b/tools/libxc/xc_misc.c @@ -54,6 +54,11 @@ int xc_get_cpumap_size(xc_interface *xch return (xc_get_max_cpus(xch) + 7) / 8; } +int xc_get_nodemap_size(xc_interface *xch) +{ + return (xc_get_max_nodes(xch) + 7) / 8; +} + xc_cpumap_t xc_cpumap_alloc(xc_interface *xch) { int sz; @@ -64,6 +69,16 @@ xc_cpumap_t xc_cpumap_alloc(xc_interface return calloc(1, sz); } +xc_nodemap_t xc_nodemap_alloc(xc_interface *xch) +{ + int sz; + + sz = xc_get_nodemap_size(xch); + if (sz == 0) + return NULL; + return calloc(1, sz); +} + int xc_readconsolering(xc_interface *xch, char *buffer, unsigned int *pnr_chars, diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h --- a/tools/libxc/xenctrl.h +++ b/tools/libxc/xenctrl.h @@ -330,12 +330,20 @@ int xc_get_cpumap_size(xc_interface *xch /* allocate a cpumap */ xc_cpumap_t xc_cpumap_alloc(xc_interface *xch); - /* +/* * NODEMAP handling */ +typedef uint8_t *xc_nodemap_t; + /* return maximum number of NUMA nodes the hypervisor supports */ int xc_get_max_nodes(xc_interface *xch); +/* return array size for nodemap */ +int xc_get_nodemap_size(xc_interface *xch); + +/* allocate a nodemap */ +xc_nodemap_t xc_nodemap_alloc(xc_interface *xch); + /* * DOMAIN DEBUGGING FUNCTIONS */ diff --git a/xen/common/domctl.c b/xen/common/domctl.c --- a/xen/common/domctl.c +++ b/xen/common/domctl.c @@ -118,6 +118,30 @@ int xenctl_bitmap_to_cpumask(cpumask_var return err; } +int nodemask_to_xenctl_bitmap(struct xenctl_bitmap *xenctl_nodemap, + const nodemask_t *nodemask) +{ + return bitmap_to_xenctl_bitmap(xenctl_nodemap, cpumask_bits(nodemask), + MAX_NUMNODES); +} + +int xenctl_bitmap_to_nodemask(nodemask_t *nodemask, + const struct xenctl_bitmap *xenctl_nodemap) +{ + int err = 0; + + if ( alloc_nodemask_var(nodemask) ) { + err = xenctl_bitmap_to_bitmap(nodes_addr(*nodemask), xenctl_nodemap, + MAX_NUMNODES); + if ( err ) + free_nodemask_var(*nodemask); + } + else + err = -ENOMEM; + + return err; +} + static inline int is_free_domid(domid_t dom) { struct domain *d; diff --git a/xen/include/xen/nodemask.h b/xen/include/xen/nodemask.h --- a/xen/include/xen/nodemask.h +++ b/xen/include/xen/nodemask.h @@ -298,6 +298,53 @@ static inline int __nodemask_parse(const } #endif +/* + * nodemask_var_t: struct nodemask for stack usage. + * + * See definition of cpumask_var_t in include/xen//cpumask.h. + */ +#if MAX_NUMNODES > 2 * BITS_PER_LONG +#include + +typedef nodemask_t *nodemask_var_t; + +#define nr_nodemask_bits (BITS_TO_LONGS(MAX_NUMNODES) * BITS_PER_LONG) + +static inline bool_t alloc_nodemask_var(nodemask_var_t *mask) +{ + *(void **)mask = _xmalloc(nr_nodemask_bits / 8, sizeof(long)); + return *mask != NULL; +} + +static inline bool_t zalloc_nodemask_var(nodemask_var_t *mask) +{ + *(void **)mask = _xzalloc(nr_nodemask_bits / 8, sizeof(long)); + return *mask != NULL; +} + +static inline void free_nodemask_var(nodemask_var_t mask) +{ + xfree(mask); +} +#else +typedef nodemask_t nodemask_var_t; + +static inline bool_t alloc_nodemask_var(nodemask_var_t *mask) +{ + return 1; +} + +static inline bool_t zalloc_nodemask_var(nodemask_var_t *mask) +{ + nodes_clear(*mask); + return 1; +} + +static inline void free_nodemask_var(nodemask_var_t mask) +{ +} +#endif + #if MAX_NUMNODES > 1 #define for_each_node_mask(node, mask) \ for ((node) = first_node(mask); \ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:14:30 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:14:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8fR-0000HQ-7V; Fri, 05 Oct 2012 14:14:17 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8fP-0000H8-Nl for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:14:15 +0000 Received: from [85.158.143.35:12527] by server-2.bemta-4.messagelabs.com id 15/90-06610-73BEE605; Fri, 05 Oct 2012 14:14:15 +0000 X-Env-Sender: raistlin.df@gmail.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1349446448!12532791!2 X-Originating-IP: [74.125.82.51] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28466 invoked from network); 5 Oct 2012 14:14:14 -0000 Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com) (74.125.82.51) by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:14:14 -0000 Received: by mail-wg0-f51.google.com with SMTP id ed3so635331wgb.32 for ; Fri, 05 Oct 2012 07:14:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:content-transfer-encoding:subject :x-mercurial-node:message-id:in-reply-to:references:user-agent:date :from:to:cc; bh=EvtnFJbinmGoOPrYYDsp/jbuYF5vjvdJjS1m1YJURhA=; b=rZZ6WVIEfaO4/zdliT+FJ0nWTD7RBHY8IBlDm6d1NwNIiI+4/BF7WH2irVTI8cR6MH 4pPFXK7fMm0NA5OTHctKs+Ut7DUre6beduC/jZTpeFDoTwhPsLNpX6DuJSdpWUjBDzsQ NXUMUFWVprsts5Z2eRqvvKZ8F2sVmRk1jhxyEohIBwvT8eRBqFIiW3kHX70oxW1y33uH cWoZ3tGtyPEydqoBfEJ6L6b7cblTBRrfbpIsBH9/dhv325YSUBcI+IwwCiElkG40ZNhd 4ApDhNz4brL8d3ez815XhqDgiXsGCtLsHRa2lUWKP3xj5VCdehVLz4RkhB+9Ce43o4AO VTtQ== Received: by 10.180.99.194 with SMTP id es2mr3682495wib.15.1349446453823; Fri, 05 Oct 2012 07:14:13 -0700 (PDT) Received: from [127.0.1.1] (ip-170-24.sn3.eutelia.it. [213.136.170.24]) by mx.google.com with ESMTPS id fb20sm2909341wid.1.2012.10.05.07.14.11 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Oct 2012 07:14:13 -0700 (PDT) MIME-Version: 1.0 X-Mercurial-Node: 9e7d4c414d9566832d5254af0a3322a1c5a5f7cf Message-Id: <9e7d4c414d9566832d52.1349446100@Solace> In-Reply-To: References: User-Agent: Mercurial-patchbomb/2.2.2 Date: Fri, 05 Oct 2012 16:08:20 +0200 From: Dario Faggioli To: xen-devel@lists.xen.org Cc: Andre Przywara , Ian Campbell , Anil Madhavapeddy , George Dunlap , Andrew Cooper , Juergen Gross , Ian Jackson , Jan Beulich , Marcus Granado , Daniel De Graaf , Matt Wilson Subject: [Xen-devel] [PATCH 2 of 8] xen, libxc: introduce node maps and masks X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Following suit from cpumap and cpumask implementations. Signed-off-by: Dario Faggioli diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c --- a/tools/libxc/xc_misc.c +++ b/tools/libxc/xc_misc.c @@ -54,6 +54,11 @@ int xc_get_cpumap_size(xc_interface *xch return (xc_get_max_cpus(xch) + 7) / 8; } +int xc_get_nodemap_size(xc_interface *xch) +{ + return (xc_get_max_nodes(xch) + 7) / 8; +} + xc_cpumap_t xc_cpumap_alloc(xc_interface *xch) { int sz; @@ -64,6 +69,16 @@ xc_cpumap_t xc_cpumap_alloc(xc_interface return calloc(1, sz); } +xc_nodemap_t xc_nodemap_alloc(xc_interface *xch) +{ + int sz; + + sz = xc_get_nodemap_size(xch); + if (sz == 0) + return NULL; + return calloc(1, sz); +} + int xc_readconsolering(xc_interface *xch, char *buffer, unsigned int *pnr_chars, diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h --- a/tools/libxc/xenctrl.h +++ b/tools/libxc/xenctrl.h @@ -330,12 +330,20 @@ int xc_get_cpumap_size(xc_interface *xch /* allocate a cpumap */ xc_cpumap_t xc_cpumap_alloc(xc_interface *xch); - /* +/* * NODEMAP handling */ +typedef uint8_t *xc_nodemap_t; + /* return maximum number of NUMA nodes the hypervisor supports */ int xc_get_max_nodes(xc_interface *xch); +/* return array size for nodemap */ +int xc_get_nodemap_size(xc_interface *xch); + +/* allocate a nodemap */ +xc_nodemap_t xc_nodemap_alloc(xc_interface *xch); + /* * DOMAIN DEBUGGING FUNCTIONS */ diff --git a/xen/common/domctl.c b/xen/common/domctl.c --- a/xen/common/domctl.c +++ b/xen/common/domctl.c @@ -118,6 +118,30 @@ int xenctl_bitmap_to_cpumask(cpumask_var return err; } +int nodemask_to_xenctl_bitmap(struct xenctl_bitmap *xenctl_nodemap, + const nodemask_t *nodemask) +{ + return bitmap_to_xenctl_bitmap(xenctl_nodemap, cpumask_bits(nodemask), + MAX_NUMNODES); +} + +int xenctl_bitmap_to_nodemask(nodemask_t *nodemask, + const struct xenctl_bitmap *xenctl_nodemap) +{ + int err = 0; + + if ( alloc_nodemask_var(nodemask) ) { + err = xenctl_bitmap_to_bitmap(nodes_addr(*nodemask), xenctl_nodemap, + MAX_NUMNODES); + if ( err ) + free_nodemask_var(*nodemask); + } + else + err = -ENOMEM; + + return err; +} + static inline int is_free_domid(domid_t dom) { struct domain *d; diff --git a/xen/include/xen/nodemask.h b/xen/include/xen/nodemask.h --- a/xen/include/xen/nodemask.h +++ b/xen/include/xen/nodemask.h @@ -298,6 +298,53 @@ static inline int __nodemask_parse(const } #endif +/* + * nodemask_var_t: struct nodemask for stack usage. + * + * See definition of cpumask_var_t in include/xen//cpumask.h. + */ +#if MAX_NUMNODES > 2 * BITS_PER_LONG +#include + +typedef nodemask_t *nodemask_var_t; + +#define nr_nodemask_bits (BITS_TO_LONGS(MAX_NUMNODES) * BITS_PER_LONG) + +static inline bool_t alloc_nodemask_var(nodemask_var_t *mask) +{ + *(void **)mask = _xmalloc(nr_nodemask_bits / 8, sizeof(long)); + return *mask != NULL; +} + +static inline bool_t zalloc_nodemask_var(nodemask_var_t *mask) +{ + *(void **)mask = _xzalloc(nr_nodemask_bits / 8, sizeof(long)); + return *mask != NULL; +} + +static inline void free_nodemask_var(nodemask_var_t mask) +{ + xfree(mask); +} +#else +typedef nodemask_t nodemask_var_t; + +static inline bool_t alloc_nodemask_var(nodemask_var_t *mask) +{ + return 1; +} + +static inline bool_t zalloc_nodemask_var(nodemask_var_t *mask) +{ + nodes_clear(*mask); + return 1; +} + +static inline void free_nodemask_var(nodemask_var_t mask) +{ +} +#endif + #if MAX_NUMNODES > 1 #define for_each_node_mask(node, mask) \ for ((node) = first_node(mask); \ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:14:31 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:14:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8fW-0000JB-7W; Fri, 05 Oct 2012 14:14:22 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8fU-0000H8-1p for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:14:20 +0000 Received: from [85.158.143.35:2489] by server-2.bemta-4.messagelabs.com id 0C/A0-06610-B3BEE605; Fri, 05 Oct 2012 14:14:19 +0000 X-Env-Sender: raistlin.df@gmail.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1349446448!12532791!4 X-Originating-IP: [74.125.82.51] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28572 invoked from network); 5 Oct 2012 14:14:17 -0000 Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com) (74.125.82.51) by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:14:17 -0000 Received: by mail-wg0-f51.google.com with SMTP id ed3so635331wgb.32 for ; Fri, 05 Oct 2012 07:14:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:content-transfer-encoding:subject :x-mercurial-node:message-id:in-reply-to:references:user-agent:date :from:to:cc; bh=AFWsbnBSPdf7yS0TGrueIHHGKtS/4Oinxb61pdFaa2A=; b=UbX4CZdFRUFLQixR3/vkhIg433On5Igsc2L/eSn9q8zkp4PvU0INs5Dh646HxM3NDB hiQlt8fwzGt+rhe9Xu1eHi+35Ja6YYrm1/70k2/YRRqzMFXfrhVNRKikjy13ZfPBSWiV sedeVXINQ72mcyUTHAbaSIicUEgQBd6a6pXPpDAzs5F23vlLUvo5aITfuAjDSYUpKiCd Xkeksuhhk40iUwKYQ88s5mmqBWoibaAjxKeZ3Yvb2aYl8R54ueiQzL08eIFu7g+DfFLp A7TdBWlhln2a18T1XRq8vodT4i3wAfI8xhYDaY4i+F9WUZRmlhaFs5nvegZOZS6zaRlG woqg== Received: by 10.216.227.101 with SMTP id c79mr2660938weq.31.1349446450877; Fri, 05 Oct 2012 07:14:10 -0700 (PDT) Received: from [127.0.1.1] (ip-170-24.sn3.eutelia.it. [213.136.170.24]) by mx.google.com with ESMTPS id fb20sm2909341wid.1.2012.10.05.07.14.08 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Oct 2012 07:14:10 -0700 (PDT) MIME-Version: 1.0 X-Mercurial-Node: c2ffd1b229197f77aa8154891f08bc89e426036b Message-Id: In-Reply-To: References: User-Agent: Mercurial-patchbomb/2.2.2 Date: Fri, 05 Oct 2012 16:08:19 +0200 From: Dario Faggioli To: xen-devel@lists.xen.org Cc: Andre Przywara , Ian Campbell , Anil Madhavapeddy , George Dunlap , Andrew Cooper , Juergen Gross , Ian Jackson , Jan Beulich , Marcus Granado , Daniel De Graaf , Matt Wilson Subject: [Xen-devel] [PATCH 1 of 8] xen, libxc: rename xenctl_cpumap to xenctl_bitmap X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org More specifically: 1. replaces xenctl_cpumap with xenctl_bitmap 2. provides bitmap_to_xenctl_bitmap and the reverse; 3. re-implement cpumask_to_xenctl_bitmap with bitmap_to_xenctl_bitmap and the reverse; Other than #3, no functional changes. Interface only slightly afected. This is in preparation of introducing NUMA node-affinity maps. Signed-off-by: Dario Faggioli diff --git a/tools/libxc/xc_cpupool.c b/tools/libxc/xc_cpupool.c --- a/tools/libxc/xc_cpupool.c +++ b/tools/libxc/xc_cpupool.c @@ -90,7 +90,7 @@ xc_cpupoolinfo_t *xc_cpupool_getinfo(xc_ sysctl.u.cpupool_op.op = XEN_SYSCTL_CPUPOOL_OP_INFO; sysctl.u.cpupool_op.cpupool_id = poolid; set_xen_guest_handle(sysctl.u.cpupool_op.cpumap.bitmap, local); - sysctl.u.cpupool_op.cpumap.nr_cpus = local_size * 8; + sysctl.u.cpupool_op.cpumap.nr_elems = local_size * 8; err = do_sysctl_save(xch, &sysctl); @@ -184,7 +184,7 @@ xc_cpumap_t xc_cpupool_freeinfo(xc_inter sysctl.cmd = XEN_SYSCTL_cpupool_op; sysctl.u.cpupool_op.op = XEN_SYSCTL_CPUPOOL_OP_FREEINFO; set_xen_guest_handle(sysctl.u.cpupool_op.cpumap.bitmap, local); - sysctl.u.cpupool_op.cpumap.nr_cpus = mapsize * 8; + sysctl.u.cpupool_op.cpumap.nr_elems = mapsize * 8; err = do_sysctl_save(xch, &sysctl); diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c --- a/tools/libxc/xc_domain.c +++ b/tools/libxc/xc_domain.c @@ -142,7 +142,7 @@ int xc_vcpu_setaffinity(xc_interface *xc set_xen_guest_handle(domctl.u.vcpuaffinity.cpumap.bitmap, local); - domctl.u.vcpuaffinity.cpumap.nr_cpus = cpusize * 8; + domctl.u.vcpuaffinity.cpumap.nr_elems = cpusize * 8; ret = do_domctl(xch, &domctl); @@ -182,7 +182,7 @@ int xc_vcpu_getaffinity(xc_interface *xc domctl.u.vcpuaffinity.vcpu = vcpu; set_xen_guest_handle(domctl.u.vcpuaffinity.cpumap.bitmap, local); - domctl.u.vcpuaffinity.cpumap.nr_cpus = cpusize * 8; + domctl.u.vcpuaffinity.cpumap.nr_elems = cpusize * 8; ret = do_domctl(xch, &domctl); diff --git a/tools/libxc/xc_tbuf.c b/tools/libxc/xc_tbuf.c --- a/tools/libxc/xc_tbuf.c +++ b/tools/libxc/xc_tbuf.c @@ -134,7 +134,7 @@ int xc_tbuf_set_cpu_mask(xc_interface *x bitmap_64_to_byte(bytemap, &mask64, sizeof (mask64) * 8); set_xen_guest_handle(sysctl.u.tbuf_op.cpu_mask.bitmap, bytemap); - sysctl.u.tbuf_op.cpu_mask.nr_cpus = sizeof(bytemap) * 8; + sysctl.u.tbuf_op.cpu_mask.nr_elems = sizeof(bytemap) * 8; ret = do_sysctl(xch, &sysctl); diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c --- a/xen/arch/x86/cpu/mcheck/mce.c +++ b/xen/arch/x86/cpu/mcheck/mce.c @@ -1474,8 +1474,7 @@ long do_mca(XEN_GUEST_HANDLE(xen_mc_t) u cpumap = &cpu_online_map; else { - ret = xenctl_cpumap_to_cpumask(&cmv, - &op->u.mc_inject_v2.cpumap); + ret = xenctl_bitmap_to_cpumask(&cmv, &op->u.mc_inject_v2.cpumap); if ( ret ) break; cpumap = cmv; diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hypercall.c --- a/xen/arch/x86/platform_hypercall.c +++ b/xen/arch/x86/platform_hypercall.c @@ -371,7 +371,7 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe { uint32_t cpu; uint64_t idletime, now = NOW(); - struct xenctl_cpumap ctlmap; + struct xenctl_bitmap ctlmap; cpumask_var_t cpumap; XEN_GUEST_HANDLE(uint8) cpumap_bitmap; XEN_GUEST_HANDLE(uint64) idletimes; @@ -384,11 +384,11 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe if ( cpufreq_controller != FREQCTL_dom0_kernel ) break; - ctlmap.nr_cpus = op->u.getidletime.cpumap_nr_cpus; + ctlmap.nr_elems = op->u.getidletime.cpumap_nr_cpus; guest_from_compat_handle(cpumap_bitmap, op->u.getidletime.cpumap_bitmap); ctlmap.bitmap.p = cpumap_bitmap.p; /* handle -> handle_64 conversion */ - if ( (ret = xenctl_cpumap_to_cpumask(&cpumap, &ctlmap)) != 0 ) + if ( (ret = xenctl_bitmap_to_cpumask(&cpumap, &ctlmap)) != 0 ) goto out; guest_from_compat_handle(idletimes, op->u.getidletime.idletime); @@ -407,7 +407,7 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe op->u.getidletime.now = now; if ( ret == 0 ) - ret = cpumask_to_xenctl_cpumap(&ctlmap, cpumap); + ret = cpumask_to_xenctl_bitmap(&ctlmap, cpumap); free_cpumask_var(cpumap); if ( ret == 0 && copy_to_guest(u_xenpf_op, op, 1) ) diff --git a/xen/common/cpupool.c b/xen/common/cpupool.c --- a/xen/common/cpupool.c +++ b/xen/common/cpupool.c @@ -493,7 +493,7 @@ int cpupool_do_sysctl(struct xen_sysctl_ op->cpupool_id = c->cpupool_id; op->sched_id = c->sched->sched_id; op->n_dom = c->n_dom; - ret = cpumask_to_xenctl_cpumap(&op->cpumap, c->cpu_valid); + ret = cpumask_to_xenctl_bitmap(&op->cpumap, c->cpu_valid); cpupool_put(c); } break; @@ -588,7 +588,7 @@ int cpupool_do_sysctl(struct xen_sysctl_ case XEN_SYSCTL_CPUPOOL_OP_FREEINFO: { - ret = cpumask_to_xenctl_cpumap( + ret = cpumask_to_xenctl_bitmap( &op->cpumap, &cpupool_free_cpus); } break; diff --git a/xen/common/domctl.c b/xen/common/domctl.c --- a/xen/common/domctl.c +++ b/xen/common/domctl.c @@ -32,28 +32,29 @@ static DEFINE_SPINLOCK(domctl_lock); DEFINE_SPINLOCK(vcpu_alloc_lock); -int cpumask_to_xenctl_cpumap( - struct xenctl_cpumap *xenctl_cpumap, const cpumask_t *cpumask) +int bitmap_to_xenctl_bitmap(struct xenctl_bitmap *xenctl_bitmap, + const unsigned long *bitmap, + unsigned int nbits) { unsigned int guest_bytes, copy_bytes, i; uint8_t zero = 0; int err = 0; - uint8_t *bytemap = xmalloc_array(uint8_t, (nr_cpu_ids + 7) / 8); + uint8_t *bytemap = xmalloc_array(uint8_t, (nbits + 7) / 8); if ( !bytemap ) return -ENOMEM; - guest_bytes = (xenctl_cpumap->nr_cpus + 7) / 8; - copy_bytes = min_t(unsigned int, guest_bytes, (nr_cpu_ids + 7) / 8); + guest_bytes = (xenctl_bitmap->nr_elems + 7) / 8; + copy_bytes = min_t(unsigned int, guest_bytes, (nbits + 7) / 8); - bitmap_long_to_byte(bytemap, cpumask_bits(cpumask), nr_cpu_ids); + bitmap_long_to_byte(bytemap, bitmap, nbits); if ( copy_bytes != 0 ) - if ( copy_to_guest(xenctl_cpumap->bitmap, bytemap, copy_bytes) ) + if ( copy_to_guest(xenctl_bitmap->bitmap, bytemap, copy_bytes) ) err = -EFAULT; for ( i = copy_bytes; !err && i < guest_bytes; i++ ) - if ( copy_to_guest_offset(xenctl_cpumap->bitmap, i, &zero, 1) ) + if ( copy_to_guest_offset(xenctl_bitmap->bitmap, i, &zero, 1) ) err = -EFAULT; xfree(bytemap); @@ -61,36 +62,59 @@ int cpumask_to_xenctl_cpumap( return err; } -int xenctl_cpumap_to_cpumask( - cpumask_var_t *cpumask, const struct xenctl_cpumap *xenctl_cpumap) +int xenctl_bitmap_to_bitmap(unsigned long *bitmap, + const struct xenctl_bitmap *xenctl_bitmap, + unsigned int nbits) { unsigned int guest_bytes, copy_bytes; int err = 0; - uint8_t *bytemap = xzalloc_array(uint8_t, (nr_cpu_ids + 7) / 8); + uint8_t *bytemap = xzalloc_array(uint8_t, (nbits + 7) / 8); if ( !bytemap ) return -ENOMEM; - guest_bytes = (xenctl_cpumap->nr_cpus + 7) / 8; - copy_bytes = min_t(unsigned int, guest_bytes, (nr_cpu_ids + 7) / 8); + guest_bytes = (xenctl_bitmap->nr_elems + 7) / 8; + copy_bytes = min_t(unsigned int, guest_bytes, (nbits + 7) / 8); if ( copy_bytes != 0 ) { - if ( copy_from_guest(bytemap, xenctl_cpumap->bitmap, copy_bytes) ) + if ( copy_from_guest(bytemap, xenctl_bitmap->bitmap, copy_bytes) ) err = -EFAULT; - if ( (xenctl_cpumap->nr_cpus & 7) && (guest_bytes <= sizeof(bytemap)) ) - bytemap[guest_bytes-1] &= ~(0xff << (xenctl_cpumap->nr_cpus & 7)); + if ( (xenctl_bitmap->nr_elems & 7) && + (guest_bytes <= sizeof(bytemap)) ) + bytemap[guest_bytes-1] &= ~(0xff << (xenctl_bitmap->nr_elems & 7)); } - if ( err ) - /* nothing */; - else if ( alloc_cpumask_var(cpumask) ) - bitmap_byte_to_long(cpumask_bits(*cpumask), bytemap, nr_cpu_ids); + if ( !err ) + bitmap_byte_to_long(bitmap, bytemap, nbits); + + xfree(bytemap); + + return err; +} + +int cpumask_to_xenctl_bitmap(struct xenctl_bitmap *xenctl_cpumap, + const cpumask_t *cpumask) +{ + return bitmap_to_xenctl_bitmap(xenctl_cpumap, cpumask_bits(cpumask), + nr_cpu_ids); +} + +int xenctl_bitmap_to_cpumask(cpumask_var_t *cpumask, + const struct xenctl_bitmap *xenctl_cpumap) +{ + int err = 0; + + if ( alloc_cpumask_var(cpumask) ) { + err = xenctl_bitmap_to_bitmap(cpumask_bits(*cpumask), xenctl_cpumap, + nr_cpu_ids); + /* In case of error, cleanup is up to us, as the caller won't care! */ + if ( err ) + free_cpumask_var(*cpumask); + } else err = -ENOMEM; - xfree(bytemap); - return err; } @@ -621,7 +645,7 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc { cpumask_var_t new_affinity; - ret = xenctl_cpumap_to_cpumask( + ret = xenctl_bitmap_to_cpumask( &new_affinity, &op->u.vcpuaffinity.cpumap); if ( !ret ) { @@ -631,7 +655,7 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc } else { - ret = cpumask_to_xenctl_cpumap( + ret = cpumask_to_xenctl_bitmap( &op->u.vcpuaffinity.cpumap, v->cpu_affinity); } diff --git a/xen/common/trace.c b/xen/common/trace.c --- a/xen/common/trace.c +++ b/xen/common/trace.c @@ -384,7 +384,7 @@ int tb_control(xen_sysctl_tbuf_op_t *tbc { cpumask_var_t mask; - rc = xenctl_cpumap_to_cpumask(&mask, &tbc->cpu_mask); + rc = xenctl_bitmap_to_cpumask(&mask, &tbc->cpu_mask); if ( !rc ) { cpumask_copy(&tb_cpu_mask, mask); diff --git a/xen/include/public/arch-x86/xen-mca.h b/xen/include/public/arch-x86/xen-mca.h --- a/xen/include/public/arch-x86/xen-mca.h +++ b/xen/include/public/arch-x86/xen-mca.h @@ -414,7 +414,7 @@ struct xen_mc_mceinject { struct xen_mc_inject_v2 { uint32_t flags; - struct xenctl_cpumap cpumap; + struct xenctl_bitmap cpumap; }; #endif diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h --- a/xen/include/public/domctl.h +++ b/xen/include/public/domctl.h @@ -284,7 +284,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_getvc /* XEN_DOMCTL_getvcpuaffinity */ struct xen_domctl_vcpuaffinity { uint32_t vcpu; /* IN */ - struct xenctl_cpumap cpumap; /* IN/OUT */ + struct xenctl_bitmap cpumap; /* IN/OUT */ }; typedef struct xen_domctl_vcpuaffinity xen_domctl_vcpuaffinity_t; DEFINE_XEN_GUEST_HANDLE(xen_domctl_vcpuaffinity_t); diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h --- a/xen/include/public/sysctl.h +++ b/xen/include/public/sysctl.h @@ -71,7 +71,7 @@ struct xen_sysctl_tbuf_op { #define XEN_SYSCTL_TBUFOP_disable 5 uint32_t cmd; /* IN/OUT variables */ - struct xenctl_cpumap cpu_mask; + struct xenctl_bitmap cpu_mask; uint32_t evt_mask; /* OUT variables */ uint64_aligned_t buffer_mfn; @@ -532,7 +532,7 @@ struct xen_sysctl_cpupool_op { uint32_t domid; /* IN: M */ uint32_t cpu; /* IN: AR */ uint32_t n_dom; /* OUT: I */ - struct xenctl_cpumap cpumap; /* OUT: IF */ + struct xenctl_bitmap cpumap; /* OUT: IF */ }; typedef struct xen_sysctl_cpupool_op xen_sysctl_cpupool_op_t; DEFINE_XEN_GUEST_HANDLE(xen_sysctl_cpupool_op_t); diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h --- a/xen/include/public/xen.h +++ b/xen/include/public/xen.h @@ -820,9 +820,9 @@ typedef uint8_t xen_domain_handle_t[16]; #endif #ifndef __ASSEMBLY__ -struct xenctl_cpumap { +struct xenctl_bitmap { XEN_GUEST_HANDLE_64(uint8) bitmap; - uint32_t nr_cpus; + uint32_t nr_elems; }; #endif diff --git a/xen/include/xen/cpumask.h b/xen/include/xen/cpumask.h --- a/xen/include/xen/cpumask.h +++ b/xen/include/xen/cpumask.h @@ -424,8 +424,8 @@ extern cpumask_t cpu_present_map; #define for_each_present_cpu(cpu) for_each_cpu(cpu, &cpu_present_map) /* Copy to/from cpumap provided by control tools. */ -struct xenctl_cpumap; -int cpumask_to_xenctl_cpumap(struct xenctl_cpumap *, const cpumask_t *); -int xenctl_cpumap_to_cpumask(cpumask_var_t *, const struct xenctl_cpumap *); +struct xenctl_bitmap; +int cpumask_to_xenctl_bitmap(struct xenctl_bitmap *, const cpumask_t *); +int xenctl_bitmap_to_cpumask(cpumask_var_t *, const struct xenctl_bitmap *); #endif /* __XEN_CPUMASK_H */ diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst --- a/xen/include/xlat.lst +++ b/xen/include/xlat.lst @@ -2,7 +2,7 @@ # ! - needs translation # ? - needs checking ? dom0_vga_console_info xen.h -? xenctl_cpumap xen.h +? xenctl_bitmap xen.h ? mmu_update xen.h ! mmuext_op xen.h ! start_info xen.h _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:14:31 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:14:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8fW-0000JB-7W; Fri, 05 Oct 2012 14:14:22 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8fU-0000H8-1p for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:14:20 +0000 Received: from [85.158.143.35:2489] by server-2.bemta-4.messagelabs.com id 0C/A0-06610-B3BEE605; Fri, 05 Oct 2012 14:14:19 +0000 X-Env-Sender: raistlin.df@gmail.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1349446448!12532791!4 X-Originating-IP: [74.125.82.51] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28572 invoked from network); 5 Oct 2012 14:14:17 -0000 Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com) (74.125.82.51) by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:14:17 -0000 Received: by mail-wg0-f51.google.com with SMTP id ed3so635331wgb.32 for ; Fri, 05 Oct 2012 07:14:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:content-transfer-encoding:subject :x-mercurial-node:message-id:in-reply-to:references:user-agent:date :from:to:cc; bh=AFWsbnBSPdf7yS0TGrueIHHGKtS/4Oinxb61pdFaa2A=; b=UbX4CZdFRUFLQixR3/vkhIg433On5Igsc2L/eSn9q8zkp4PvU0INs5Dh646HxM3NDB hiQlt8fwzGt+rhe9Xu1eHi+35Ja6YYrm1/70k2/YRRqzMFXfrhVNRKikjy13ZfPBSWiV sedeVXINQ72mcyUTHAbaSIicUEgQBd6a6pXPpDAzs5F23vlLUvo5aITfuAjDSYUpKiCd Xkeksuhhk40iUwKYQ88s5mmqBWoibaAjxKeZ3Yvb2aYl8R54ueiQzL08eIFu7g+DfFLp A7TdBWlhln2a18T1XRq8vodT4i3wAfI8xhYDaY4i+F9WUZRmlhaFs5nvegZOZS6zaRlG woqg== Received: by 10.216.227.101 with SMTP id c79mr2660938weq.31.1349446450877; Fri, 05 Oct 2012 07:14:10 -0700 (PDT) Received: from [127.0.1.1] (ip-170-24.sn3.eutelia.it. [213.136.170.24]) by mx.google.com with ESMTPS id fb20sm2909341wid.1.2012.10.05.07.14.08 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Oct 2012 07:14:10 -0700 (PDT) MIME-Version: 1.0 X-Mercurial-Node: c2ffd1b229197f77aa8154891f08bc89e426036b Message-Id: In-Reply-To: References: User-Agent: Mercurial-patchbomb/2.2.2 Date: Fri, 05 Oct 2012 16:08:19 +0200 From: Dario Faggioli To: xen-devel@lists.xen.org Cc: Andre Przywara , Ian Campbell , Anil Madhavapeddy , George Dunlap , Andrew Cooper , Juergen Gross , Ian Jackson , Jan Beulich , Marcus Granado , Daniel De Graaf , Matt Wilson Subject: [Xen-devel] [PATCH 1 of 8] xen, libxc: rename xenctl_cpumap to xenctl_bitmap X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org More specifically: 1. replaces xenctl_cpumap with xenctl_bitmap 2. provides bitmap_to_xenctl_bitmap and the reverse; 3. re-implement cpumask_to_xenctl_bitmap with bitmap_to_xenctl_bitmap and the reverse; Other than #3, no functional changes. Interface only slightly afected. This is in preparation of introducing NUMA node-affinity maps. Signed-off-by: Dario Faggioli diff --git a/tools/libxc/xc_cpupool.c b/tools/libxc/xc_cpupool.c --- a/tools/libxc/xc_cpupool.c +++ b/tools/libxc/xc_cpupool.c @@ -90,7 +90,7 @@ xc_cpupoolinfo_t *xc_cpupool_getinfo(xc_ sysctl.u.cpupool_op.op = XEN_SYSCTL_CPUPOOL_OP_INFO; sysctl.u.cpupool_op.cpupool_id = poolid; set_xen_guest_handle(sysctl.u.cpupool_op.cpumap.bitmap, local); - sysctl.u.cpupool_op.cpumap.nr_cpus = local_size * 8; + sysctl.u.cpupool_op.cpumap.nr_elems = local_size * 8; err = do_sysctl_save(xch, &sysctl); @@ -184,7 +184,7 @@ xc_cpumap_t xc_cpupool_freeinfo(xc_inter sysctl.cmd = XEN_SYSCTL_cpupool_op; sysctl.u.cpupool_op.op = XEN_SYSCTL_CPUPOOL_OP_FREEINFO; set_xen_guest_handle(sysctl.u.cpupool_op.cpumap.bitmap, local); - sysctl.u.cpupool_op.cpumap.nr_cpus = mapsize * 8; + sysctl.u.cpupool_op.cpumap.nr_elems = mapsize * 8; err = do_sysctl_save(xch, &sysctl); diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c --- a/tools/libxc/xc_domain.c +++ b/tools/libxc/xc_domain.c @@ -142,7 +142,7 @@ int xc_vcpu_setaffinity(xc_interface *xc set_xen_guest_handle(domctl.u.vcpuaffinity.cpumap.bitmap, local); - domctl.u.vcpuaffinity.cpumap.nr_cpus = cpusize * 8; + domctl.u.vcpuaffinity.cpumap.nr_elems = cpusize * 8; ret = do_domctl(xch, &domctl); @@ -182,7 +182,7 @@ int xc_vcpu_getaffinity(xc_interface *xc domctl.u.vcpuaffinity.vcpu = vcpu; set_xen_guest_handle(domctl.u.vcpuaffinity.cpumap.bitmap, local); - domctl.u.vcpuaffinity.cpumap.nr_cpus = cpusize * 8; + domctl.u.vcpuaffinity.cpumap.nr_elems = cpusize * 8; ret = do_domctl(xch, &domctl); diff --git a/tools/libxc/xc_tbuf.c b/tools/libxc/xc_tbuf.c --- a/tools/libxc/xc_tbuf.c +++ b/tools/libxc/xc_tbuf.c @@ -134,7 +134,7 @@ int xc_tbuf_set_cpu_mask(xc_interface *x bitmap_64_to_byte(bytemap, &mask64, sizeof (mask64) * 8); set_xen_guest_handle(sysctl.u.tbuf_op.cpu_mask.bitmap, bytemap); - sysctl.u.tbuf_op.cpu_mask.nr_cpus = sizeof(bytemap) * 8; + sysctl.u.tbuf_op.cpu_mask.nr_elems = sizeof(bytemap) * 8; ret = do_sysctl(xch, &sysctl); diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c --- a/xen/arch/x86/cpu/mcheck/mce.c +++ b/xen/arch/x86/cpu/mcheck/mce.c @@ -1474,8 +1474,7 @@ long do_mca(XEN_GUEST_HANDLE(xen_mc_t) u cpumap = &cpu_online_map; else { - ret = xenctl_cpumap_to_cpumask(&cmv, - &op->u.mc_inject_v2.cpumap); + ret = xenctl_bitmap_to_cpumask(&cmv, &op->u.mc_inject_v2.cpumap); if ( ret ) break; cpumap = cmv; diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hypercall.c --- a/xen/arch/x86/platform_hypercall.c +++ b/xen/arch/x86/platform_hypercall.c @@ -371,7 +371,7 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe { uint32_t cpu; uint64_t idletime, now = NOW(); - struct xenctl_cpumap ctlmap; + struct xenctl_bitmap ctlmap; cpumask_var_t cpumap; XEN_GUEST_HANDLE(uint8) cpumap_bitmap; XEN_GUEST_HANDLE(uint64) idletimes; @@ -384,11 +384,11 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe if ( cpufreq_controller != FREQCTL_dom0_kernel ) break; - ctlmap.nr_cpus = op->u.getidletime.cpumap_nr_cpus; + ctlmap.nr_elems = op->u.getidletime.cpumap_nr_cpus; guest_from_compat_handle(cpumap_bitmap, op->u.getidletime.cpumap_bitmap); ctlmap.bitmap.p = cpumap_bitmap.p; /* handle -> handle_64 conversion */ - if ( (ret = xenctl_cpumap_to_cpumask(&cpumap, &ctlmap)) != 0 ) + if ( (ret = xenctl_bitmap_to_cpumask(&cpumap, &ctlmap)) != 0 ) goto out; guest_from_compat_handle(idletimes, op->u.getidletime.idletime); @@ -407,7 +407,7 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe op->u.getidletime.now = now; if ( ret == 0 ) - ret = cpumask_to_xenctl_cpumap(&ctlmap, cpumap); + ret = cpumask_to_xenctl_bitmap(&ctlmap, cpumap); free_cpumask_var(cpumap); if ( ret == 0 && copy_to_guest(u_xenpf_op, op, 1) ) diff --git a/xen/common/cpupool.c b/xen/common/cpupool.c --- a/xen/common/cpupool.c +++ b/xen/common/cpupool.c @@ -493,7 +493,7 @@ int cpupool_do_sysctl(struct xen_sysctl_ op->cpupool_id = c->cpupool_id; op->sched_id = c->sched->sched_id; op->n_dom = c->n_dom; - ret = cpumask_to_xenctl_cpumap(&op->cpumap, c->cpu_valid); + ret = cpumask_to_xenctl_bitmap(&op->cpumap, c->cpu_valid); cpupool_put(c); } break; @@ -588,7 +588,7 @@ int cpupool_do_sysctl(struct xen_sysctl_ case XEN_SYSCTL_CPUPOOL_OP_FREEINFO: { - ret = cpumask_to_xenctl_cpumap( + ret = cpumask_to_xenctl_bitmap( &op->cpumap, &cpupool_free_cpus); } break; diff --git a/xen/common/domctl.c b/xen/common/domctl.c --- a/xen/common/domctl.c +++ b/xen/common/domctl.c @@ -32,28 +32,29 @@ static DEFINE_SPINLOCK(domctl_lock); DEFINE_SPINLOCK(vcpu_alloc_lock); -int cpumask_to_xenctl_cpumap( - struct xenctl_cpumap *xenctl_cpumap, const cpumask_t *cpumask) +int bitmap_to_xenctl_bitmap(struct xenctl_bitmap *xenctl_bitmap, + const unsigned long *bitmap, + unsigned int nbits) { unsigned int guest_bytes, copy_bytes, i; uint8_t zero = 0; int err = 0; - uint8_t *bytemap = xmalloc_array(uint8_t, (nr_cpu_ids + 7) / 8); + uint8_t *bytemap = xmalloc_array(uint8_t, (nbits + 7) / 8); if ( !bytemap ) return -ENOMEM; - guest_bytes = (xenctl_cpumap->nr_cpus + 7) / 8; - copy_bytes = min_t(unsigned int, guest_bytes, (nr_cpu_ids + 7) / 8); + guest_bytes = (xenctl_bitmap->nr_elems + 7) / 8; + copy_bytes = min_t(unsigned int, guest_bytes, (nbits + 7) / 8); - bitmap_long_to_byte(bytemap, cpumask_bits(cpumask), nr_cpu_ids); + bitmap_long_to_byte(bytemap, bitmap, nbits); if ( copy_bytes != 0 ) - if ( copy_to_guest(xenctl_cpumap->bitmap, bytemap, copy_bytes) ) + if ( copy_to_guest(xenctl_bitmap->bitmap, bytemap, copy_bytes) ) err = -EFAULT; for ( i = copy_bytes; !err && i < guest_bytes; i++ ) - if ( copy_to_guest_offset(xenctl_cpumap->bitmap, i, &zero, 1) ) + if ( copy_to_guest_offset(xenctl_bitmap->bitmap, i, &zero, 1) ) err = -EFAULT; xfree(bytemap); @@ -61,36 +62,59 @@ int cpumask_to_xenctl_cpumap( return err; } -int xenctl_cpumap_to_cpumask( - cpumask_var_t *cpumask, const struct xenctl_cpumap *xenctl_cpumap) +int xenctl_bitmap_to_bitmap(unsigned long *bitmap, + const struct xenctl_bitmap *xenctl_bitmap, + unsigned int nbits) { unsigned int guest_bytes, copy_bytes; int err = 0; - uint8_t *bytemap = xzalloc_array(uint8_t, (nr_cpu_ids + 7) / 8); + uint8_t *bytemap = xzalloc_array(uint8_t, (nbits + 7) / 8); if ( !bytemap ) return -ENOMEM; - guest_bytes = (xenctl_cpumap->nr_cpus + 7) / 8; - copy_bytes = min_t(unsigned int, guest_bytes, (nr_cpu_ids + 7) / 8); + guest_bytes = (xenctl_bitmap->nr_elems + 7) / 8; + copy_bytes = min_t(unsigned int, guest_bytes, (nbits + 7) / 8); if ( copy_bytes != 0 ) { - if ( copy_from_guest(bytemap, xenctl_cpumap->bitmap, copy_bytes) ) + if ( copy_from_guest(bytemap, xenctl_bitmap->bitmap, copy_bytes) ) err = -EFAULT; - if ( (xenctl_cpumap->nr_cpus & 7) && (guest_bytes <= sizeof(bytemap)) ) - bytemap[guest_bytes-1] &= ~(0xff << (xenctl_cpumap->nr_cpus & 7)); + if ( (xenctl_bitmap->nr_elems & 7) && + (guest_bytes <= sizeof(bytemap)) ) + bytemap[guest_bytes-1] &= ~(0xff << (xenctl_bitmap->nr_elems & 7)); } - if ( err ) - /* nothing */; - else if ( alloc_cpumask_var(cpumask) ) - bitmap_byte_to_long(cpumask_bits(*cpumask), bytemap, nr_cpu_ids); + if ( !err ) + bitmap_byte_to_long(bitmap, bytemap, nbits); + + xfree(bytemap); + + return err; +} + +int cpumask_to_xenctl_bitmap(struct xenctl_bitmap *xenctl_cpumap, + const cpumask_t *cpumask) +{ + return bitmap_to_xenctl_bitmap(xenctl_cpumap, cpumask_bits(cpumask), + nr_cpu_ids); +} + +int xenctl_bitmap_to_cpumask(cpumask_var_t *cpumask, + const struct xenctl_bitmap *xenctl_cpumap) +{ + int err = 0; + + if ( alloc_cpumask_var(cpumask) ) { + err = xenctl_bitmap_to_bitmap(cpumask_bits(*cpumask), xenctl_cpumap, + nr_cpu_ids); + /* In case of error, cleanup is up to us, as the caller won't care! */ + if ( err ) + free_cpumask_var(*cpumask); + } else err = -ENOMEM; - xfree(bytemap); - return err; } @@ -621,7 +645,7 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc { cpumask_var_t new_affinity; - ret = xenctl_cpumap_to_cpumask( + ret = xenctl_bitmap_to_cpumask( &new_affinity, &op->u.vcpuaffinity.cpumap); if ( !ret ) { @@ -631,7 +655,7 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc } else { - ret = cpumask_to_xenctl_cpumap( + ret = cpumask_to_xenctl_bitmap( &op->u.vcpuaffinity.cpumap, v->cpu_affinity); } diff --git a/xen/common/trace.c b/xen/common/trace.c --- a/xen/common/trace.c +++ b/xen/common/trace.c @@ -384,7 +384,7 @@ int tb_control(xen_sysctl_tbuf_op_t *tbc { cpumask_var_t mask; - rc = xenctl_cpumap_to_cpumask(&mask, &tbc->cpu_mask); + rc = xenctl_bitmap_to_cpumask(&mask, &tbc->cpu_mask); if ( !rc ) { cpumask_copy(&tb_cpu_mask, mask); diff --git a/xen/include/public/arch-x86/xen-mca.h b/xen/include/public/arch-x86/xen-mca.h --- a/xen/include/public/arch-x86/xen-mca.h +++ b/xen/include/public/arch-x86/xen-mca.h @@ -414,7 +414,7 @@ struct xen_mc_mceinject { struct xen_mc_inject_v2 { uint32_t flags; - struct xenctl_cpumap cpumap; + struct xenctl_bitmap cpumap; }; #endif diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h --- a/xen/include/public/domctl.h +++ b/xen/include/public/domctl.h @@ -284,7 +284,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_getvc /* XEN_DOMCTL_getvcpuaffinity */ struct xen_domctl_vcpuaffinity { uint32_t vcpu; /* IN */ - struct xenctl_cpumap cpumap; /* IN/OUT */ + struct xenctl_bitmap cpumap; /* IN/OUT */ }; typedef struct xen_domctl_vcpuaffinity xen_domctl_vcpuaffinity_t; DEFINE_XEN_GUEST_HANDLE(xen_domctl_vcpuaffinity_t); diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h --- a/xen/include/public/sysctl.h +++ b/xen/include/public/sysctl.h @@ -71,7 +71,7 @@ struct xen_sysctl_tbuf_op { #define XEN_SYSCTL_TBUFOP_disable 5 uint32_t cmd; /* IN/OUT variables */ - struct xenctl_cpumap cpu_mask; + struct xenctl_bitmap cpu_mask; uint32_t evt_mask; /* OUT variables */ uint64_aligned_t buffer_mfn; @@ -532,7 +532,7 @@ struct xen_sysctl_cpupool_op { uint32_t domid; /* IN: M */ uint32_t cpu; /* IN: AR */ uint32_t n_dom; /* OUT: I */ - struct xenctl_cpumap cpumap; /* OUT: IF */ + struct xenctl_bitmap cpumap; /* OUT: IF */ }; typedef struct xen_sysctl_cpupool_op xen_sysctl_cpupool_op_t; DEFINE_XEN_GUEST_HANDLE(xen_sysctl_cpupool_op_t); diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h --- a/xen/include/public/xen.h +++ b/xen/include/public/xen.h @@ -820,9 +820,9 @@ typedef uint8_t xen_domain_handle_t[16]; #endif #ifndef __ASSEMBLY__ -struct xenctl_cpumap { +struct xenctl_bitmap { XEN_GUEST_HANDLE_64(uint8) bitmap; - uint32_t nr_cpus; + uint32_t nr_elems; }; #endif diff --git a/xen/include/xen/cpumask.h b/xen/include/xen/cpumask.h --- a/xen/include/xen/cpumask.h +++ b/xen/include/xen/cpumask.h @@ -424,8 +424,8 @@ extern cpumask_t cpu_present_map; #define for_each_present_cpu(cpu) for_each_cpu(cpu, &cpu_present_map) /* Copy to/from cpumap provided by control tools. */ -struct xenctl_cpumap; -int cpumask_to_xenctl_cpumap(struct xenctl_cpumap *, const cpumask_t *); -int xenctl_cpumap_to_cpumask(cpumask_var_t *, const struct xenctl_cpumap *); +struct xenctl_bitmap; +int cpumask_to_xenctl_bitmap(struct xenctl_bitmap *, const cpumask_t *); +int xenctl_bitmap_to_cpumask(cpumask_var_t *, const struct xenctl_bitmap *); #endif /* __XEN_CPUMASK_H */ diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst --- a/xen/include/xlat.lst +++ b/xen/include/xlat.lst @@ -2,7 +2,7 @@ # ! - needs translation # ? - needs checking ? dom0_vga_console_info xen.h -? xenctl_cpumap xen.h +? xenctl_bitmap xen.h ? mmu_update xen.h ! mmuext_op xen.h ! start_info xen.h _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:14:31 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:14:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8fb-0000Lr-4L; Fri, 05 Oct 2012 14:14:27 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8fZ-0000KZ-88 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:14:25 +0000 Received: from [85.158.137.99:21652] by server-16.bemta-3.messagelabs.com id 06/A3-04167-04BEE605; Fri, 05 Oct 2012 14:14:24 +0000 X-Env-Sender: raistlin.df@gmail.com X-Msg-Ref: server-15.tower-217.messagelabs.com!1349446463!18058335!1 X-Originating-IP: [209.85.212.169] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32665 invoked from network); 5 Oct 2012 14:14:23 -0000 Received: from mail-wi0-f169.google.com (HELO mail-wi0-f169.google.com) (209.85.212.169) by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:14:23 -0000 Received: by mail-wi0-f169.google.com with SMTP id hq4so644139wib.2 for ; Fri, 05 Oct 2012 07:14:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:content-transfer-encoding:subject :x-mercurial-node:message-id:in-reply-to:references:user-agent:date :from:to:cc; bh=QAmjjTH/iJx1rtNGZN4pJcWkzryu1FhQxFtzYy2lwtY=; b=z+gwlBrAYAoM/OrJNbdJrn48gKqUZfiws6lqBRfRH+NYza0TUFRWNiq6QorxIqYHtm ciulYd1C6Q0eK/rftAWpLKBsgD04DJNSTZ7vqZnd+fAtD61ODZCEsVeGzSD5J7XRhOBc CId6JSR1XouYQBbkuOGwAyCT13DinOLSkEgXljGatEyeYo6x2TgkIoF6tOPT2fi/2qM/ ZvFa+wpsiwPg4KGcqKK5Ap9RS/b6FikKLaR3GHQDBtCAZnU65nfE9Zj8JO4ED4TeSaHk lXW/qZuUDQat5SQwuVnEIMD39YNvoLEZ9LR+ECyVuZLMn4cu+EeX3S4isAYjPHpHKmsW wfew== Received: by 10.180.84.41 with SMTP id v9mr2206961wiy.8.1349446463423; Fri, 05 Oct 2012 07:14:23 -0700 (PDT) Received: from [127.0.1.1] (ip-170-24.sn3.eutelia.it. [213.136.170.24]) by mx.google.com with ESMTPS id fb20sm2909341wid.1.2012.10.05.07.14.21 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Oct 2012 07:14:22 -0700 (PDT) MIME-Version: 1.0 X-Mercurial-Node: d3ff6f36655c96056fe4b5f6d4248ce708460521 Message-Id: In-Reply-To: References: User-Agent: Mercurial-patchbomb/2.2.2 Date: Fri, 05 Oct 2012 16:08:24 +0200 From: Dario Faggioli To: xen-devel@lists.xen.org Cc: Andre Przywara , Ian Campbell , Anil Madhavapeddy , George Dunlap , Andrew Cooper , Juergen Gross , Ian Jackson , Jan Beulich , Marcus Granado , Daniel De Graaf , Matt Wilson Subject: [Xen-devel] [PATCH 6 of 8] libxl: allow for explicitly specifying node-affinity X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org By introducing a nodemap in libxl_domain_build_info and providing the get/set methods to deal with it. Signed-off-by: Dario Faggioli diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c --- a/tools/libxl/libxl.c +++ b/tools/libxl/libxl.c @@ -3926,6 +3926,26 @@ int libxl_set_vcpuaffinity_all(libxl_ctx return rc; } +int libxl_domain_set_nodeaffinity(libxl_ctx *ctx, uint32_t domid, + libxl_bitmap *nodemap) +{ + if (xc_domain_node_setaffinity(ctx->xch, domid, nodemap->map)) { + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "setting node affinity"); + return ERROR_FAIL; + } + return 0; +} + +int libxl_domain_get_nodeaffinity(libxl_ctx *ctx, uint32_t domid, + libxl_bitmap *nodemap) +{ + if (xc_domain_node_getaffinity(ctx->xch, domid, nodemap->map)) { + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting node affinity"); + return ERROR_FAIL; + } + return 0; +} + int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_bitmap *cpumap) { GC_INIT(ctx); diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h --- a/tools/libxl/libxl.h +++ b/tools/libxl/libxl.h @@ -859,6 +859,10 @@ int libxl_set_vcpuaffinity(libxl_ctx *ct libxl_bitmap *cpumap); int libxl_set_vcpuaffinity_all(libxl_ctx *ctx, uint32_t domid, unsigned int max_vcpus, libxl_bitmap *cpumap); +int libxl_domain_set_nodeaffinity(libxl_ctx *ctx, uint32_t domid, + libxl_bitmap *nodemap); +int libxl_domain_get_nodeaffinity(libxl_ctx *ctx, uint32_t domid, + libxl_bitmap *nodemap); int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_bitmap *cpumap); libxl_scheduler libxl_get_scheduler(libxl_ctx *ctx); diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -219,6 +219,12 @@ int libxl__domain_build_info_setdefault( libxl_defbool_setdefault(&b_info->numa_placement, true); + if (!b_info->nodemap.size) { + if (libxl_node_bitmap_alloc(CTX, &b_info->nodemap, 0)) + return ERROR_FAIL; + libxl_bitmap_set_any(&b_info->nodemap); + } + if (b_info->max_memkb == LIBXL_MEMKB_DEFAULT) b_info->max_memkb = 32 * 1024; if (b_info->target_memkb == LIBXL_MEMKB_DEFAULT) diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c --- a/tools/libxl/libxl_dom.c +++ b/tools/libxl/libxl_dom.c @@ -230,6 +230,7 @@ int libxl__build_pre(libxl__gc *gc, uint if (rc) return rc; } + libxl_domain_set_nodeaffinity(ctx, domid, &info->nodemap); libxl_set_vcpuaffinity_all(ctx, domid, info->max_vcpus, &info->cpumap); xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + LIBXL_MAXMEM_CONSTANT); diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl --- a/tools/libxl/libxl_types.idl +++ b/tools/libxl/libxl_types.idl @@ -255,6 +255,7 @@ libxl_domain_build_info = Struct("domain ("max_vcpus", integer), ("avail_vcpus", libxl_bitmap), ("cpumap", libxl_bitmap), + ("nodemap", libxl_bitmap), ("numa_placement", libxl_defbool), ("tsc_mode", libxl_tsc_mode), ("max_memkb", MemKB), _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:14:31 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:14:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8fb-0000Lr-4L; Fri, 05 Oct 2012 14:14:27 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8fZ-0000KZ-88 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:14:25 +0000 Received: from [85.158.137.99:21652] by server-16.bemta-3.messagelabs.com id 06/A3-04167-04BEE605; Fri, 05 Oct 2012 14:14:24 +0000 X-Env-Sender: raistlin.df@gmail.com X-Msg-Ref: server-15.tower-217.messagelabs.com!1349446463!18058335!1 X-Originating-IP: [209.85.212.169] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32665 invoked from network); 5 Oct 2012 14:14:23 -0000 Received: from mail-wi0-f169.google.com (HELO mail-wi0-f169.google.com) (209.85.212.169) by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:14:23 -0000 Received: by mail-wi0-f169.google.com with SMTP id hq4so644139wib.2 for ; Fri, 05 Oct 2012 07:14:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:content-transfer-encoding:subject :x-mercurial-node:message-id:in-reply-to:references:user-agent:date :from:to:cc; bh=QAmjjTH/iJx1rtNGZN4pJcWkzryu1FhQxFtzYy2lwtY=; b=z+gwlBrAYAoM/OrJNbdJrn48gKqUZfiws6lqBRfRH+NYza0TUFRWNiq6QorxIqYHtm ciulYd1C6Q0eK/rftAWpLKBsgD04DJNSTZ7vqZnd+fAtD61ODZCEsVeGzSD5J7XRhOBc CId6JSR1XouYQBbkuOGwAyCT13DinOLSkEgXljGatEyeYo6x2TgkIoF6tOPT2fi/2qM/ ZvFa+wpsiwPg4KGcqKK5Ap9RS/b6FikKLaR3GHQDBtCAZnU65nfE9Zj8JO4ED4TeSaHk lXW/qZuUDQat5SQwuVnEIMD39YNvoLEZ9LR+ECyVuZLMn4cu+EeX3S4isAYjPHpHKmsW wfew== Received: by 10.180.84.41 with SMTP id v9mr2206961wiy.8.1349446463423; Fri, 05 Oct 2012 07:14:23 -0700 (PDT) Received: from [127.0.1.1] (ip-170-24.sn3.eutelia.it. [213.136.170.24]) by mx.google.com with ESMTPS id fb20sm2909341wid.1.2012.10.05.07.14.21 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Oct 2012 07:14:22 -0700 (PDT) MIME-Version: 1.0 X-Mercurial-Node: d3ff6f36655c96056fe4b5f6d4248ce708460521 Message-Id: In-Reply-To: References: User-Agent: Mercurial-patchbomb/2.2.2 Date: Fri, 05 Oct 2012 16:08:24 +0200 From: Dario Faggioli To: xen-devel@lists.xen.org Cc: Andre Przywara , Ian Campbell , Anil Madhavapeddy , George Dunlap , Andrew Cooper , Juergen Gross , Ian Jackson , Jan Beulich , Marcus Granado , Daniel De Graaf , Matt Wilson Subject: [Xen-devel] [PATCH 6 of 8] libxl: allow for explicitly specifying node-affinity X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org By introducing a nodemap in libxl_domain_build_info and providing the get/set methods to deal with it. Signed-off-by: Dario Faggioli diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c --- a/tools/libxl/libxl.c +++ b/tools/libxl/libxl.c @@ -3926,6 +3926,26 @@ int libxl_set_vcpuaffinity_all(libxl_ctx return rc; } +int libxl_domain_set_nodeaffinity(libxl_ctx *ctx, uint32_t domid, + libxl_bitmap *nodemap) +{ + if (xc_domain_node_setaffinity(ctx->xch, domid, nodemap->map)) { + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "setting node affinity"); + return ERROR_FAIL; + } + return 0; +} + +int libxl_domain_get_nodeaffinity(libxl_ctx *ctx, uint32_t domid, + libxl_bitmap *nodemap) +{ + if (xc_domain_node_getaffinity(ctx->xch, domid, nodemap->map)) { + LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting node affinity"); + return ERROR_FAIL; + } + return 0; +} + int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_bitmap *cpumap) { GC_INIT(ctx); diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h --- a/tools/libxl/libxl.h +++ b/tools/libxl/libxl.h @@ -859,6 +859,10 @@ int libxl_set_vcpuaffinity(libxl_ctx *ct libxl_bitmap *cpumap); int libxl_set_vcpuaffinity_all(libxl_ctx *ctx, uint32_t domid, unsigned int max_vcpus, libxl_bitmap *cpumap); +int libxl_domain_set_nodeaffinity(libxl_ctx *ctx, uint32_t domid, + libxl_bitmap *nodemap); +int libxl_domain_get_nodeaffinity(libxl_ctx *ctx, uint32_t domid, + libxl_bitmap *nodemap); int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_bitmap *cpumap); libxl_scheduler libxl_get_scheduler(libxl_ctx *ctx); diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -219,6 +219,12 @@ int libxl__domain_build_info_setdefault( libxl_defbool_setdefault(&b_info->numa_placement, true); + if (!b_info->nodemap.size) { + if (libxl_node_bitmap_alloc(CTX, &b_info->nodemap, 0)) + return ERROR_FAIL; + libxl_bitmap_set_any(&b_info->nodemap); + } + if (b_info->max_memkb == LIBXL_MEMKB_DEFAULT) b_info->max_memkb = 32 * 1024; if (b_info->target_memkb == LIBXL_MEMKB_DEFAULT) diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c --- a/tools/libxl/libxl_dom.c +++ b/tools/libxl/libxl_dom.c @@ -230,6 +230,7 @@ int libxl__build_pre(libxl__gc *gc, uint if (rc) return rc; } + libxl_domain_set_nodeaffinity(ctx, domid, &info->nodemap); libxl_set_vcpuaffinity_all(ctx, domid, info->max_vcpus, &info->cpumap); xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + LIBXL_MAXMEM_CONSTANT); diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl --- a/tools/libxl/libxl_types.idl +++ b/tools/libxl/libxl_types.idl @@ -255,6 +255,7 @@ libxl_domain_build_info = Struct("domain ("max_vcpus", integer), ("avail_vcpus", libxl_bitmap), ("cpumap", libxl_bitmap), + ("nodemap", libxl_bitmap), ("numa_placement", libxl_defbool), ("tsc_mode", libxl_tsc_mode), ("max_memkb", MemKB), _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:14:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:14:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8fY-0000KU-L5; Fri, 05 Oct 2012 14:14:24 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8fW-0000Hg-ND for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:14:22 +0000 Received: from [85.158.143.99:45370] by server-1.bemta-4.messagelabs.com id E9/56-05684-E3BEE605; Fri, 05 Oct 2012 14:14:22 +0000 X-Env-Sender: raistlin.df@gmail.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1349446461!24834463!1 X-Originating-IP: [74.125.82.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8817 invoked from network); 5 Oct 2012 14:14:21 -0000 Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com) (74.125.82.173) by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:14:21 -0000 Received: by mail-we0-f173.google.com with SMTP id t11so1288032wey.32 for ; Fri, 05 Oct 2012 07:14:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:content-transfer-encoding:subject :x-mercurial-node:message-id:in-reply-to:references:user-agent:date :from:to:cc; bh=QjTxrOrxo2awt2Gz3Vfrv36Rx1QMZQKz+WEzjlNArqA=; b=o4FQ59g54DtGOHEf7fz/rwRztjs4xSe7E1VzOi/rU4tUULh/r3wtU/KRNxIvTwSjh4 orvBDnPA0qmngkd1eUt6Kh2j3uXYaXu9xuYdKSgT5Bw34os1cpKjFNPJEcPTWrqgGjYV KMXGHE6gwSorx4ZoPzEmTaTi4KJAes2p4IAsgw/urO82PCo9rGRGnuYfu8qXpawn0yS/ ylRIXZsHmfHiuoScNpsNVE/sGDOsjhzwmk0jjQkbkA7Pk7cwKkwBjNprJ426eCqwK2eo jryrJthiDSMCkZw71pjt8zGMAZStw2sYDbVZ5Wd29Izdqq++b8b/8LbD0WIEoJ1GuyYJ Xu2Q== Received: by 10.216.66.7 with SMTP id g7mr5629222wed.146.1349446461184; Fri, 05 Oct 2012 07:14:21 -0700 (PDT) Received: from [127.0.1.1] (ip-170-24.sn3.eutelia.it. [213.136.170.24]) by mx.google.com with ESMTPS id fb20sm2909341wid.1.2012.10.05.07.14.19 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Oct 2012 07:14:20 -0700 (PDT) MIME-Version: 1.0 X-Mercurial-Node: 54bd1b01516d2e354b57cb8ee4ac5b5f5740c0cc Message-Id: <54bd1b01516d2e354b57.1349446103@Solace> In-Reply-To: References: User-Agent: Mercurial-patchbomb/2.2.2 Date: Fri, 05 Oct 2012 16:08:23 +0200 From: Dario Faggioli To: xen-devel@lists.xen.org Cc: Andre Przywara , Ian Campbell , Anil Madhavapeddy , George Dunlap , Andrew Cooper , Juergen Gross , Ian Jackson , Jan Beulich , Marcus Granado , Daniel De Graaf , Matt Wilson Subject: [Xen-devel] [PATCH 5 of 8] libxc: allow for explicitly specifying node-affinity X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org By providing the proper get/set interface and wiring them to the new domctl-s from the previous commit. Signed-off-by: Dario Faggioli diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c --- a/tools/libxc/xc_domain.c +++ b/tools/libxc/xc_domain.c @@ -110,6 +110,83 @@ int xc_domain_shutdown(xc_interface *xch } +int xc_domain_node_setaffinity(xc_interface *xch, + uint32_t domid, + xc_nodemap_t nodemap) +{ + DECLARE_DOMCTL; + DECLARE_HYPERCALL_BUFFER(uint8_t, local); + int ret = -1; + int nodesize; + + nodesize = xc_get_nodemap_size(xch); + if (!nodesize) + { + PERROR("Could not get number of nodes"); + goto out; + } + + local = xc_hypercall_buffer_alloc(xch, local, nodesize); + if ( local == NULL ) + { + PERROR("Could not allocate memory for setnodeaffinity domctl hypercall"); + goto out; + } + + domctl.cmd = XEN_DOMCTL_setnodeaffinity; + domctl.domain = (domid_t)domid; + + memcpy(local, nodemap, nodesize); + set_xen_guest_handle(domctl.u.nodeaffinity.nodemap.bitmap, local); + domctl.u.nodeaffinity.nodemap.nr_elems = nodesize * 8; + + ret = do_domctl(xch, &domctl); + + xc_hypercall_buffer_free(xch, local); + + out: + return ret; +} + +int xc_domain_node_getaffinity(xc_interface *xch, + uint32_t domid, + xc_nodemap_t nodemap) +{ + DECLARE_DOMCTL; + DECLARE_HYPERCALL_BUFFER(uint8_t, local); + int ret = -1; + int nodesize; + + nodesize = xc_get_nodemap_size(xch); + if (!nodesize) + { + PERROR("Could not get number of nodes"); + goto out; + } + + local = xc_hypercall_buffer_alloc(xch, local, nodesize); + if ( local == NULL ) + { + PERROR("Could not allocate memory for getnodeaffinity domctl hypercall"); + goto out; + } + + domctl.cmd = XEN_DOMCTL_getnodeaffinity; + domctl.domain = (domid_t)domid; + + set_xen_guest_handle(domctl.u.nodeaffinity.nodemap.bitmap, local); + domctl.u.nodeaffinity.nodemap.nr_elems = nodesize * 8; + + ret = do_domctl(xch, &domctl); + + memcpy(nodemap, local, nodesize); + + xc_hypercall_buffer_free(xch, local); + + out: + return ret; +} + int xc_vcpu_setaffinity(xc_interface *xch, uint32_t domid, int vcpu, diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h --- a/tools/libxc/xenctrl.h +++ b/tools/libxc/xenctrl.h @@ -521,6 +521,32 @@ int xc_watchdog(xc_interface *xch, uint32_t id, uint32_t timeout); +/** + * This function explicitly sets the host NUMA nodes the domain will + * have affinity with. + * + * @parm xch a handle to an open hypervisor interface. + * @parm domid the domain id one wants to set the affinity of. + * @parm nodemap the map of the affine nodes. + * @return 0 on success, -1 on failure. + */ +int xc_domain_node_setaffinity(xc_interface *xch, + uint32_t domind, + xc_nodemap_t nodemap); + +/** + * This function retrieves the host NUMA nodes the domain has + * affinity with. + * + * @parm xch a handle to an open hypervisor interface. + * @parm domid the domain id one wants to get the node affinity of. + * @parm nodemap the map of the affine nodes. + * @return 0 on success, -1 on failure. + */ +int xc_domain_node_getaffinity(xc_interface *xch, + uint32_t domind, + xc_nodemap_t nodemap); + int xc_vcpu_setaffinity(xc_interface *xch, uint32_t domid, int vcpu, _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:14:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:14:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8fY-0000KU-L5; Fri, 05 Oct 2012 14:14:24 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8fW-0000Hg-ND for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:14:22 +0000 Received: from [85.158.143.99:45370] by server-1.bemta-4.messagelabs.com id E9/56-05684-E3BEE605; Fri, 05 Oct 2012 14:14:22 +0000 X-Env-Sender: raistlin.df@gmail.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1349446461!24834463!1 X-Originating-IP: [74.125.82.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8817 invoked from network); 5 Oct 2012 14:14:21 -0000 Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com) (74.125.82.173) by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:14:21 -0000 Received: by mail-we0-f173.google.com with SMTP id t11so1288032wey.32 for ; Fri, 05 Oct 2012 07:14:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:content-transfer-encoding:subject :x-mercurial-node:message-id:in-reply-to:references:user-agent:date :from:to:cc; bh=QjTxrOrxo2awt2Gz3Vfrv36Rx1QMZQKz+WEzjlNArqA=; b=o4FQ59g54DtGOHEf7fz/rwRztjs4xSe7E1VzOi/rU4tUULh/r3wtU/KRNxIvTwSjh4 orvBDnPA0qmngkd1eUt6Kh2j3uXYaXu9xuYdKSgT5Bw34os1cpKjFNPJEcPTWrqgGjYV KMXGHE6gwSorx4ZoPzEmTaTi4KJAes2p4IAsgw/urO82PCo9rGRGnuYfu8qXpawn0yS/ ylRIXZsHmfHiuoScNpsNVE/sGDOsjhzwmk0jjQkbkA7Pk7cwKkwBjNprJ426eCqwK2eo jryrJthiDSMCkZw71pjt8zGMAZStw2sYDbVZ5Wd29Izdqq++b8b/8LbD0WIEoJ1GuyYJ Xu2Q== Received: by 10.216.66.7 with SMTP id g7mr5629222wed.146.1349446461184; Fri, 05 Oct 2012 07:14:21 -0700 (PDT) Received: from [127.0.1.1] (ip-170-24.sn3.eutelia.it. [213.136.170.24]) by mx.google.com with ESMTPS id fb20sm2909341wid.1.2012.10.05.07.14.19 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Oct 2012 07:14:20 -0700 (PDT) MIME-Version: 1.0 X-Mercurial-Node: 54bd1b01516d2e354b57cb8ee4ac5b5f5740c0cc Message-Id: <54bd1b01516d2e354b57.1349446103@Solace> In-Reply-To: References: User-Agent: Mercurial-patchbomb/2.2.2 Date: Fri, 05 Oct 2012 16:08:23 +0200 From: Dario Faggioli To: xen-devel@lists.xen.org Cc: Andre Przywara , Ian Campbell , Anil Madhavapeddy , George Dunlap , Andrew Cooper , Juergen Gross , Ian Jackson , Jan Beulich , Marcus Granado , Daniel De Graaf , Matt Wilson Subject: [Xen-devel] [PATCH 5 of 8] libxc: allow for explicitly specifying node-affinity X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org By providing the proper get/set interface and wiring them to the new domctl-s from the previous commit. Signed-off-by: Dario Faggioli diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c --- a/tools/libxc/xc_domain.c +++ b/tools/libxc/xc_domain.c @@ -110,6 +110,83 @@ int xc_domain_shutdown(xc_interface *xch } +int xc_domain_node_setaffinity(xc_interface *xch, + uint32_t domid, + xc_nodemap_t nodemap) +{ + DECLARE_DOMCTL; + DECLARE_HYPERCALL_BUFFER(uint8_t, local); + int ret = -1; + int nodesize; + + nodesize = xc_get_nodemap_size(xch); + if (!nodesize) + { + PERROR("Could not get number of nodes"); + goto out; + } + + local = xc_hypercall_buffer_alloc(xch, local, nodesize); + if ( local == NULL ) + { + PERROR("Could not allocate memory for setnodeaffinity domctl hypercall"); + goto out; + } + + domctl.cmd = XEN_DOMCTL_setnodeaffinity; + domctl.domain = (domid_t)domid; + + memcpy(local, nodemap, nodesize); + set_xen_guest_handle(domctl.u.nodeaffinity.nodemap.bitmap, local); + domctl.u.nodeaffinity.nodemap.nr_elems = nodesize * 8; + + ret = do_domctl(xch, &domctl); + + xc_hypercall_buffer_free(xch, local); + + out: + return ret; +} + +int xc_domain_node_getaffinity(xc_interface *xch, + uint32_t domid, + xc_nodemap_t nodemap) +{ + DECLARE_DOMCTL; + DECLARE_HYPERCALL_BUFFER(uint8_t, local); + int ret = -1; + int nodesize; + + nodesize = xc_get_nodemap_size(xch); + if (!nodesize) + { + PERROR("Could not get number of nodes"); + goto out; + } + + local = xc_hypercall_buffer_alloc(xch, local, nodesize); + if ( local == NULL ) + { + PERROR("Could not allocate memory for getnodeaffinity domctl hypercall"); + goto out; + } + + domctl.cmd = XEN_DOMCTL_getnodeaffinity; + domctl.domain = (domid_t)domid; + + set_xen_guest_handle(domctl.u.nodeaffinity.nodemap.bitmap, local); + domctl.u.nodeaffinity.nodemap.nr_elems = nodesize * 8; + + ret = do_domctl(xch, &domctl); + + memcpy(nodemap, local, nodesize); + + xc_hypercall_buffer_free(xch, local); + + out: + return ret; +} + int xc_vcpu_setaffinity(xc_interface *xch, uint32_t domid, int vcpu, diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h --- a/tools/libxc/xenctrl.h +++ b/tools/libxc/xenctrl.h @@ -521,6 +521,32 @@ int xc_watchdog(xc_interface *xch, uint32_t id, uint32_t timeout); +/** + * This function explicitly sets the host NUMA nodes the domain will + * have affinity with. + * + * @parm xch a handle to an open hypervisor interface. + * @parm domid the domain id one wants to set the affinity of. + * @parm nodemap the map of the affine nodes. + * @return 0 on success, -1 on failure. + */ +int xc_domain_node_setaffinity(xc_interface *xch, + uint32_t domind, + xc_nodemap_t nodemap); + +/** + * This function retrieves the host NUMA nodes the domain has + * affinity with. + * + * @parm xch a handle to an open hypervisor interface. + * @parm domid the domain id one wants to get the node affinity of. + * @parm nodemap the map of the affine nodes. + * @return 0 on success, -1 on failure. + */ +int xc_domain_node_getaffinity(xc_interface *xch, + uint32_t domind, + xc_nodemap_t nodemap); + int xc_vcpu_setaffinity(xc_interface *xch, uint32_t domid, int vcpu, _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:14:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:14:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8fd-0000Ng-3S; Fri, 05 Oct 2012 14:14:29 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8fb-0000J2-G3 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:14:27 +0000 X-Env-Sender: raistlin.df@gmail.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1349446459!8892605!1 X-Originating-IP: [209.85.212.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28963 invoked from network); 5 Oct 2012 14:14:19 -0000 Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com) (209.85.212.173) by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:14:19 -0000 Received: by mail-wi0-f173.google.com with SMTP id hm4so597845wib.14 for ; Fri, 05 Oct 2012 07:14:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:content-transfer-encoding:subject :x-mercurial-node:message-id:in-reply-to:references:user-agent:date :from:to:cc; bh=yk1C+yJbTRxRfz5tsXVjGRgo9IS0j8TJ9HorqdmOuf8=; b=NmkXUIwfioEFqz3VHuh1QVvOYT+pNcfAtWCx6nmwvc4ZgMMg2LDZWXxntIlDIgVlMr 9wgbgIwPl0VmDduI4uIqdxRb5UwthOZv72P6+SuO3xortePS++wDvyC1CwTxJ/b1IPAn ZFxt20moXdyTwi28eXdC0XoSycdqmHgBE7ABKykaOSu4KIq4fwBl1ipkjgvXX6jan4DA uxns9ZzoAWHFHjPCDkaf2SZFIrgqUE5nfKB0Dsvz+d6tqQENvLByGmNFXroaWT+WtN0S 0nCKagsFQLme+xJ7ytna5CM/5ZLam1LMhN7TzsaY30lqcuEm43NLbbuTzKheULwJPmy3 2IAw== Received: by 10.217.0.145 with SMTP id l17mr5332956wes.133.1349446458954; Fri, 05 Oct 2012 07:14:18 -0700 (PDT) Received: from [127.0.1.1] (ip-170-24.sn3.eutelia.it. [213.136.170.24]) by mx.google.com with ESMTPS id fb20sm2909341wid.1.2012.10.05.07.14.16 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Oct 2012 07:14:18 -0700 (PDT) MIME-Version: 1.0 X-Mercurial-Node: 12134421b216e9c8eef688194e856d42081b5113 Message-Id: <12134421b216e9c8eef6.1349446102@Solace> In-Reply-To: References: User-Agent: Mercurial-patchbomb/2.2.2 Date: Fri, 05 Oct 2012 16:08:22 +0200 From: Dario Faggioli To: xen-devel@lists.xen.org Cc: Andre Przywara , Ian Campbell , Anil Madhavapeddy , George Dunlap , Andrew Cooper , Juergen Gross , Ian Jackson , Jan Beulich , Marcus Granado , Daniel De Graaf , Matt Wilson Subject: [Xen-devel] [PATCH 4 of 8] xen: allow for explicitly specifying node-affinity X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Make it possible to pass the node-affinity of a domain to the hypervisor from the upper layers, instead of always being computed automatically. Note that this also required generalizing the Flask hooks for setting and getting the affinity, so that they now deal with both vcpu and node affinity. Signed-off-by: Dario Faggioli diff --git a/xen/common/domain.c b/xen/common/domain.c --- a/xen/common/domain.c +++ b/xen/common/domain.c @@ -222,6 +222,7 @@ struct domain *domain_create( spin_lock_init(&d->node_affinity_lock); d->node_affinity = NODE_MASK_ALL; + d->auto_node_affinity = 1; spin_lock_init(&d->shutdown_lock); d->shutdown_code = -1; @@ -362,11 +363,26 @@ void domain_update_node_affinity(struct cpumask_or(cpumask, cpumask, online_affinity); } - for_each_online_node ( node ) - if ( cpumask_intersects(&node_to_cpumask(node), cpumask) ) - node_set(node, nodemask); + if ( d->auto_node_affinity ) + { + /* Node-affinity is automaically computed from all vcpu-affinities */ + for_each_online_node ( node ) + if ( cpumask_intersects(&node_to_cpumask(node), cpumask) ) + node_set(node, nodemask); - d->node_affinity = nodemask; + d->node_affinity = nodemask; + } + else + { + /* Node-affinity is provided by someone else, just filter out cpus + * that are either offline or not in the affinity of any vcpus. */ + for_each_node_mask ( node, d->node_affinity ) + if ( !cpumask_intersects(&node_to_cpumask(node), cpumask) ) + node_clear(node, d->node_affinity); + } + + sched_set_node_affinity(d, &d->node_affinity); + spin_unlock(&d->node_affinity_lock); free_cpumask_var(online_affinity); @@ -374,6 +390,36 @@ void domain_update_node_affinity(struct } +int domain_set_node_affinity(struct domain *d, const nodemask_t *affinity) +{ + /* Being affine with no nodes is just wrong */ + if ( nodes_empty(*affinity) ) + return -EINVAL; + + spin_lock(&d->node_affinity_lock); + + /* + * Being/becoming explicitly affine to all nodes is not particularly + * useful. Let's take it as the `reset node affinity` command. + */ + if ( nodes_full(*affinity) ) + { + d->auto_node_affinity = 1; + goto out; + } + + d->auto_node_affinity = 0; + d->node_affinity = *affinity; + +out: + spin_unlock(&d->node_affinity_lock); + + domain_update_node_affinity(d); + + return 0; +} + + struct domain *get_domain_by_id(domid_t dom) { struct domain *d; diff --git a/xen/common/domctl.c b/xen/common/domctl.c --- a/xen/common/domctl.c +++ b/xen/common/domctl.c @@ -642,6 +642,40 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc } break; + case XEN_DOMCTL_setnodeaffinity: + case XEN_DOMCTL_getnodeaffinity: + { + domid_t dom = op->domain; + struct domain *d = rcu_lock_domain_by_id(dom); + + ret = -ESRCH; + if ( d == NULL ) + break; + + ret = xsm_nodeaffinity(op->cmd, d); + if ( ret ) + goto nodeaffinity_out; + + if ( op->cmd == XEN_DOMCTL_setnodeaffinity ) + { + nodemask_t new_affinity; + + ret = xenctl_bitmap_to_nodemask(&new_affinity, + &op->u.nodeaffinity.nodemap); + if ( !ret ) + ret = domain_set_node_affinity(d, &new_affinity); + } + else + { + ret = nodemask_to_xenctl_bitmap(&op->u.nodeaffinity.nodemap, + &d->node_affinity); + } + + nodeaffinity_out: + rcu_unlock_domain(d); + } + break; + case XEN_DOMCTL_setvcpuaffinity: case XEN_DOMCTL_getvcpuaffinity: { diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c --- a/xen/common/keyhandler.c +++ b/xen/common/keyhandler.c @@ -217,6 +217,14 @@ static void cpuset_print(char *set, int *set++ = '\0'; } +static void nodeset_print(char *set, int size, const nodemask_t *mask) +{ + *set++ = '['; + set += nodelist_scnprintf(set, size-2, mask); + *set++ = ']'; + *set++ = '\0'; +} + static void periodic_timer_print(char *str, int size, uint64_t period) { if ( period == 0 ) @@ -272,6 +280,9 @@ static void dump_domains(unsigned char k dump_pageframe_info(d); + nodeset_print(tmpstr, sizeof(tmpstr), &d->node_affinity); + printk("NODE affinity for domain %d: %s\n", d->domain_id, tmpstr); + printk("VCPU information and callbacks for domain %u:\n", d->domain_id); for_each_vcpu ( d, v ) diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c --- a/xen/common/sched_credit.c +++ b/xen/common/sched_credit.c @@ -238,6 +238,33 @@ static inline void list_del_init(&svc->runq_elem); } +/* + * Translates node-affinity mask into a cpumask, so that we can use it during + * actual scheduling. That of course will contain all the cpus from all the + * set nodes in the original node-affinity mask. + * + * Note that any serialization needed to access mask safely is complete + * responsibility of the caller of this function/hook. + */ +static void csched_set_node_affinity( + const struct scheduler *ops, + struct domain *d, + nodemask_t *mask) +{ + struct csched_dom *sdom; + int node; + + /* Skip idle domain since it doesn't even have a node_affinity_cpumask */ + if ( unlikely(is_idle_domain(d)) ) + return; + + sdom = CSCHED_DOM(d); + cpumask_clear(sdom->node_affinity_cpumask); + for_each_node_mask( node, *mask ) + cpumask_or(sdom->node_affinity_cpumask, sdom->node_affinity_cpumask, + &node_to_cpumask(node)); +} + #define for_each_csched_balance_step(__step) \ for ( (__step) = CSCHED_BALANCE_LAST; (__step) >= 0; (__step)-- ) @@ -260,7 +287,8 @@ csched_balance_cpumask(const struct vcpu struct domain *d = vc->domain; struct csched_dom *sdom = CSCHED_DOM(d); - if ( cpumask_full(sdom->node_affinity_cpumask) ) + if ( cpumask_full(sdom->node_affinity_cpumask) || + d->auto_node_affinity == 1 ) return -1; cpumask_and(mask, sdom->node_affinity_cpumask, vc->cpu_affinity); @@ -1786,6 +1814,8 @@ const struct scheduler sched_credit_def .adjust = csched_dom_cntl, .adjust_global = csched_sys_cntl, + .set_node_affinity = csched_set_node_affinity, + .pick_cpu = csched_cpu_pick, .do_schedule = csched_schedule, diff --git a/xen/common/schedule.c b/xen/common/schedule.c --- a/xen/common/schedule.c +++ b/xen/common/schedule.c @@ -588,6 +588,11 @@ int cpu_disable_scheduler(unsigned int c return ret; } +void sched_set_node_affinity(struct domain *d, nodemask_t *mask) +{ + SCHED_OP(DOM2OP(d), set_node_affinity, d, mask); +} + int vcpu_set_affinity(struct vcpu *v, const cpumask_t *affinity) { cpumask_t online_affinity; diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h --- a/xen/include/public/domctl.h +++ b/xen/include/public/domctl.h @@ -279,6 +279,16 @@ typedef struct xen_domctl_getvcpuinfo xe DEFINE_XEN_GUEST_HANDLE(xen_domctl_getvcpuinfo_t); +/* Get/set the NUMA node(s) with which the guest has affinity with. */ +/* XEN_DOMCTL_setnodeaffinity */ +/* XEN_DOMCTL_getnodeaffinity */ +struct xen_domctl_nodeaffinity { + struct xenctl_bitmap nodemap;/* IN */ +}; +typedef struct xen_domctl_nodeaffinity xen_domctl_nodeaffinity_t; +DEFINE_XEN_GUEST_HANDLE(xen_domctl_nodeaffinity_t); + + /* Get/set which physical cpus a vcpu can execute on. */ /* XEN_DOMCTL_setvcpuaffinity */ /* XEN_DOMCTL_getvcpuaffinity */ @@ -900,6 +910,8 @@ struct xen_domctl { #define XEN_DOMCTL_set_access_required 64 #define XEN_DOMCTL_audit_p2m 65 #define XEN_DOMCTL_set_virq_handler 66 +#define XEN_DOMCTL_setnodeaffinity 67 +#define XEN_DOMCTL_getnodeaffinity 68 #define XEN_DOMCTL_gdbsx_guestmemio 1000 #define XEN_DOMCTL_gdbsx_pausevcpu 1001 #define XEN_DOMCTL_gdbsx_unpausevcpu 1002 @@ -913,6 +925,7 @@ struct xen_domctl { struct xen_domctl_getpageframeinfo getpageframeinfo; struct xen_domctl_getpageframeinfo2 getpageframeinfo2; struct xen_domctl_getpageframeinfo3 getpageframeinfo3; + struct xen_domctl_nodeaffinity nodeaffinity; struct xen_domctl_vcpuaffinity vcpuaffinity; struct xen_domctl_shadow_op shadow_op; struct xen_domctl_max_mem max_mem; diff --git a/xen/include/xen/nodemask.h b/xen/include/xen/nodemask.h --- a/xen/include/xen/nodemask.h +++ b/xen/include/xen/nodemask.h @@ -8,8 +8,9 @@ * See detailed comments in the file linux/bitmap.h describing the * data type on which these nodemasks are based. * - * For details of nodemask_scnprintf() and nodemask_parse(), - * see bitmap_scnprintf() and bitmap_parse() in lib/bitmap.c. + * For details of nodemask_scnprintf(), nodelist_scnpintf() and + * nodemask_parse(), see bitmap_scnprintf() and bitmap_parse() + * in lib/bitmap.c. * * The available nodemask operations are: * @@ -48,6 +49,7 @@ * unsigned long *nodes_addr(mask) Array of unsigned long's in mask * * int nodemask_scnprintf(buf, len, mask) Format nodemask for printing + * int nodelist_scnprintf(buf, len, mask) Format nodemask as a list for printing * int nodemask_parse(ubuf, ulen, mask) Parse ascii string as nodemask * * for_each_node_mask(node, mask) for-loop node over mask @@ -280,6 +282,14 @@ static inline int __first_unset_node(con #define nodes_addr(src) ((src).bits) +#define nodelist_scnprintf(buf, len, src) \ + __nodelist_scnprintf((buf), (len), (src), MAX_NUMNODES) +static inline int __nodelist_scnprintf(char *buf, int len, + const nodemask_t *srcp, int nbits) +{ + return bitmap_scnlistprintf(buf, len, srcp->bits, nbits); +} + #if 0 #define nodemask_scnprintf(buf, len, src) \ __nodemask_scnprintf((buf), (len), &(src), MAX_NUMNODES) diff --git a/xen/include/xen/sched-if.h b/xen/include/xen/sched-if.h --- a/xen/include/xen/sched-if.h +++ b/xen/include/xen/sched-if.h @@ -182,6 +182,8 @@ struct scheduler { struct xen_domctl_scheduler_op *); int (*adjust_global) (const struct scheduler *, struct xen_sysctl_scheduler_op *); + void (*set_node_affinity) (const struct scheduler *, + struct domain *, nodemask_t *); void (*dump_settings) (const struct scheduler *); void (*dump_cpu_state) (const struct scheduler *, int); diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h --- a/xen/include/xen/sched.h +++ b/xen/include/xen/sched.h @@ -346,8 +346,12 @@ struct domain /* Various mem_events */ struct mem_event_per_domain *mem_event; - /* Currently computed from union of all vcpu cpu-affinity masks. */ + /* + * Can be specified by the user. If that is not the case, it is + * computed from the union of all the vcpu cpu-affinity masks. + */ nodemask_t node_affinity; + int auto_node_affinity; unsigned int last_alloc_node; spinlock_t node_affinity_lock; }; @@ -416,6 +420,7 @@ static inline void get_knownalive_domain ASSERT(!(atomic_read(&d->refcnt) & DOMAIN_DESTROYED)); } +int domain_set_node_affinity(struct domain *d, const nodemask_t *affinity); void domain_update_node_affinity(struct domain *d); struct domain *domain_create( @@ -519,6 +524,7 @@ void sched_destroy_domain(struct domain int sched_move_domain(struct domain *d, struct cpupool *c); long sched_adjust(struct domain *, struct xen_domctl_scheduler_op *); long sched_adjust_global(struct xen_sysctl_scheduler_op *); +void sched_set_node_affinity(struct domain *, nodemask_t *); int sched_id(void); void sched_tick_suspend(void); void sched_tick_resume(void); diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h --- a/xen/include/xsm/xsm.h +++ b/xen/include/xsm/xsm.h @@ -56,6 +56,7 @@ struct xsm_operations { int (*domain_create) (struct domain *d, u32 ssidref); int (*max_vcpus) (struct domain *d); int (*destroydomain) (struct domain *d); + int (*nodeaffinity) (int cmd, struct domain *d); int (*vcpuaffinity) (int cmd, struct domain *d); int (*scheduler) (struct domain *d); int (*getdomaininfo) (struct domain *d); @@ -229,6 +230,11 @@ static inline int xsm_destroydomain (str return xsm_call(destroydomain(d)); } +static inline int xsm_nodeaffinity (int cmd, struct domain *d) +{ + return xsm_call(nodeaffinity(cmd, d)); +} + static inline int xsm_vcpuaffinity (int cmd, struct domain *d) { return xsm_call(vcpuaffinity(cmd, d)); diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c --- a/xen/xsm/dummy.c +++ b/xen/xsm/dummy.c @@ -634,6 +634,7 @@ void xsm_fixup_ops (struct xsm_operation set_to_dummy_if_null(ops, domain_create); set_to_dummy_if_null(ops, max_vcpus); set_to_dummy_if_null(ops, destroydomain); + set_to_dummy_if_null(ops, nodeaffinity); set_to_dummy_if_null(ops, vcpuaffinity); set_to_dummy_if_null(ops, scheduler); set_to_dummy_if_null(ops, getdomaininfo); diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c --- a/xen/xsm/flask/hooks.c +++ b/xen/xsm/flask/hooks.c @@ -521,17 +521,19 @@ static int flask_destroydomain(struct do DOMAIN__DESTROY); } -static int flask_vcpuaffinity(int cmd, struct domain *d) +static int flask_affinity(int cmd, struct domain *d) { u32 perm; switch ( cmd ) { case XEN_DOMCTL_setvcpuaffinity: - perm = DOMAIN__SETVCPUAFFINITY; + case XEN_DOMCTL_setnodeaffinity: + perm = DOMAIN__SETAFFINITY; break; case XEN_DOMCTL_getvcpuaffinity: - perm = DOMAIN__GETVCPUAFFINITY; + case XEN_DOMCTL_getnodeaffinity: + perm = DOMAIN__GETAFFINITY; break; default: return -EPERM; @@ -1473,7 +1475,8 @@ static struct xsm_operations flask_ops = .domain_create = flask_domain_create, .max_vcpus = flask_max_vcpus, .destroydomain = flask_destroydomain, - .vcpuaffinity = flask_vcpuaffinity, + .nodeaffinity = flask_affinity, + .vcpuaffinity = flask_affinity, .scheduler = flask_scheduler, .getdomaininfo = flask_getdomaininfo, .getvcpucontext = flask_getvcpucontext, diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h --- a/xen/xsm/flask/include/av_perm_to_string.h +++ b/xen/xsm/flask/include/av_perm_to_string.h @@ -37,8 +37,8 @@ S_(SECCLASS_DOMAIN, DOMAIN__TRANSITION, "transition") S_(SECCLASS_DOMAIN, DOMAIN__MAX_VCPUS, "max_vcpus") S_(SECCLASS_DOMAIN, DOMAIN__DESTROY, "destroy") - S_(SECCLASS_DOMAIN, DOMAIN__SETVCPUAFFINITY, "setvcpuaffinity") - S_(SECCLASS_DOMAIN, DOMAIN__GETVCPUAFFINITY, "getvcpuaffinity") + S_(SECCLASS_DOMAIN, DOMAIN__SETAFFINITY, "setaffinity") + S_(SECCLASS_DOMAIN, DOMAIN__GETAFFINITY, "getaffinity") S_(SECCLASS_DOMAIN, DOMAIN__SCHEDULER, "scheduler") S_(SECCLASS_DOMAIN, DOMAIN__GETDOMAININFO, "getdomaininfo") S_(SECCLASS_DOMAIN, DOMAIN__GETVCPUINFO, "getvcpuinfo") diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h --- a/xen/xsm/flask/include/av_permissions.h +++ b/xen/xsm/flask/include/av_permissions.h @@ -38,8 +38,8 @@ #define DOMAIN__TRANSITION 0x00000020UL #define DOMAIN__MAX_VCPUS 0x00000040UL #define DOMAIN__DESTROY 0x00000080UL -#define DOMAIN__SETVCPUAFFINITY 0x00000100UL -#define DOMAIN__GETVCPUAFFINITY 0x00000200UL +#define DOMAIN__SETAFFINITY 0x00000100UL +#define DOMAIN__GETAFFINITY 0x00000200UL #define DOMAIN__SCHEDULER 0x00000400UL #define DOMAIN__GETDOMAININFO 0x00000800UL #define DOMAIN__GETVCPUINFO 0x00001000UL _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:14:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:14:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8fd-0000Ng-3S; Fri, 05 Oct 2012 14:14:29 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8fb-0000J2-G3 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:14:27 +0000 X-Env-Sender: raistlin.df@gmail.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1349446459!8892605!1 X-Originating-IP: [209.85.212.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28963 invoked from network); 5 Oct 2012 14:14:19 -0000 Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com) (209.85.212.173) by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:14:19 -0000 Received: by mail-wi0-f173.google.com with SMTP id hm4so597845wib.14 for ; Fri, 05 Oct 2012 07:14:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:content-transfer-encoding:subject :x-mercurial-node:message-id:in-reply-to:references:user-agent:date :from:to:cc; bh=yk1C+yJbTRxRfz5tsXVjGRgo9IS0j8TJ9HorqdmOuf8=; b=NmkXUIwfioEFqz3VHuh1QVvOYT+pNcfAtWCx6nmwvc4ZgMMg2LDZWXxntIlDIgVlMr 9wgbgIwPl0VmDduI4uIqdxRb5UwthOZv72P6+SuO3xortePS++wDvyC1CwTxJ/b1IPAn ZFxt20moXdyTwi28eXdC0XoSycdqmHgBE7ABKykaOSu4KIq4fwBl1ipkjgvXX6jan4DA uxns9ZzoAWHFHjPCDkaf2SZFIrgqUE5nfKB0Dsvz+d6tqQENvLByGmNFXroaWT+WtN0S 0nCKagsFQLme+xJ7ytna5CM/5ZLam1LMhN7TzsaY30lqcuEm43NLbbuTzKheULwJPmy3 2IAw== Received: by 10.217.0.145 with SMTP id l17mr5332956wes.133.1349446458954; Fri, 05 Oct 2012 07:14:18 -0700 (PDT) Received: from [127.0.1.1] (ip-170-24.sn3.eutelia.it. [213.136.170.24]) by mx.google.com with ESMTPS id fb20sm2909341wid.1.2012.10.05.07.14.16 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Oct 2012 07:14:18 -0700 (PDT) MIME-Version: 1.0 X-Mercurial-Node: 12134421b216e9c8eef688194e856d42081b5113 Message-Id: <12134421b216e9c8eef6.1349446102@Solace> In-Reply-To: References: User-Agent: Mercurial-patchbomb/2.2.2 Date: Fri, 05 Oct 2012 16:08:22 +0200 From: Dario Faggioli To: xen-devel@lists.xen.org Cc: Andre Przywara , Ian Campbell , Anil Madhavapeddy , George Dunlap , Andrew Cooper , Juergen Gross , Ian Jackson , Jan Beulich , Marcus Granado , Daniel De Graaf , Matt Wilson Subject: [Xen-devel] [PATCH 4 of 8] xen: allow for explicitly specifying node-affinity X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Make it possible to pass the node-affinity of a domain to the hypervisor from the upper layers, instead of always being computed automatically. Note that this also required generalizing the Flask hooks for setting and getting the affinity, so that they now deal with both vcpu and node affinity. Signed-off-by: Dario Faggioli diff --git a/xen/common/domain.c b/xen/common/domain.c --- a/xen/common/domain.c +++ b/xen/common/domain.c @@ -222,6 +222,7 @@ struct domain *domain_create( spin_lock_init(&d->node_affinity_lock); d->node_affinity = NODE_MASK_ALL; + d->auto_node_affinity = 1; spin_lock_init(&d->shutdown_lock); d->shutdown_code = -1; @@ -362,11 +363,26 @@ void domain_update_node_affinity(struct cpumask_or(cpumask, cpumask, online_affinity); } - for_each_online_node ( node ) - if ( cpumask_intersects(&node_to_cpumask(node), cpumask) ) - node_set(node, nodemask); + if ( d->auto_node_affinity ) + { + /* Node-affinity is automaically computed from all vcpu-affinities */ + for_each_online_node ( node ) + if ( cpumask_intersects(&node_to_cpumask(node), cpumask) ) + node_set(node, nodemask); - d->node_affinity = nodemask; + d->node_affinity = nodemask; + } + else + { + /* Node-affinity is provided by someone else, just filter out cpus + * that are either offline or not in the affinity of any vcpus. */ + for_each_node_mask ( node, d->node_affinity ) + if ( !cpumask_intersects(&node_to_cpumask(node), cpumask) ) + node_clear(node, d->node_affinity); + } + + sched_set_node_affinity(d, &d->node_affinity); + spin_unlock(&d->node_affinity_lock); free_cpumask_var(online_affinity); @@ -374,6 +390,36 @@ void domain_update_node_affinity(struct } +int domain_set_node_affinity(struct domain *d, const nodemask_t *affinity) +{ + /* Being affine with no nodes is just wrong */ + if ( nodes_empty(*affinity) ) + return -EINVAL; + + spin_lock(&d->node_affinity_lock); + + /* + * Being/becoming explicitly affine to all nodes is not particularly + * useful. Let's take it as the `reset node affinity` command. + */ + if ( nodes_full(*affinity) ) + { + d->auto_node_affinity = 1; + goto out; + } + + d->auto_node_affinity = 0; + d->node_affinity = *affinity; + +out: + spin_unlock(&d->node_affinity_lock); + + domain_update_node_affinity(d); + + return 0; +} + + struct domain *get_domain_by_id(domid_t dom) { struct domain *d; diff --git a/xen/common/domctl.c b/xen/common/domctl.c --- a/xen/common/domctl.c +++ b/xen/common/domctl.c @@ -642,6 +642,40 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc } break; + case XEN_DOMCTL_setnodeaffinity: + case XEN_DOMCTL_getnodeaffinity: + { + domid_t dom = op->domain; + struct domain *d = rcu_lock_domain_by_id(dom); + + ret = -ESRCH; + if ( d == NULL ) + break; + + ret = xsm_nodeaffinity(op->cmd, d); + if ( ret ) + goto nodeaffinity_out; + + if ( op->cmd == XEN_DOMCTL_setnodeaffinity ) + { + nodemask_t new_affinity; + + ret = xenctl_bitmap_to_nodemask(&new_affinity, + &op->u.nodeaffinity.nodemap); + if ( !ret ) + ret = domain_set_node_affinity(d, &new_affinity); + } + else + { + ret = nodemask_to_xenctl_bitmap(&op->u.nodeaffinity.nodemap, + &d->node_affinity); + } + + nodeaffinity_out: + rcu_unlock_domain(d); + } + break; + case XEN_DOMCTL_setvcpuaffinity: case XEN_DOMCTL_getvcpuaffinity: { diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c --- a/xen/common/keyhandler.c +++ b/xen/common/keyhandler.c @@ -217,6 +217,14 @@ static void cpuset_print(char *set, int *set++ = '\0'; } +static void nodeset_print(char *set, int size, const nodemask_t *mask) +{ + *set++ = '['; + set += nodelist_scnprintf(set, size-2, mask); + *set++ = ']'; + *set++ = '\0'; +} + static void periodic_timer_print(char *str, int size, uint64_t period) { if ( period == 0 ) @@ -272,6 +280,9 @@ static void dump_domains(unsigned char k dump_pageframe_info(d); + nodeset_print(tmpstr, sizeof(tmpstr), &d->node_affinity); + printk("NODE affinity for domain %d: %s\n", d->domain_id, tmpstr); + printk("VCPU information and callbacks for domain %u:\n", d->domain_id); for_each_vcpu ( d, v ) diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c --- a/xen/common/sched_credit.c +++ b/xen/common/sched_credit.c @@ -238,6 +238,33 @@ static inline void list_del_init(&svc->runq_elem); } +/* + * Translates node-affinity mask into a cpumask, so that we can use it during + * actual scheduling. That of course will contain all the cpus from all the + * set nodes in the original node-affinity mask. + * + * Note that any serialization needed to access mask safely is complete + * responsibility of the caller of this function/hook. + */ +static void csched_set_node_affinity( + const struct scheduler *ops, + struct domain *d, + nodemask_t *mask) +{ + struct csched_dom *sdom; + int node; + + /* Skip idle domain since it doesn't even have a node_affinity_cpumask */ + if ( unlikely(is_idle_domain(d)) ) + return; + + sdom = CSCHED_DOM(d); + cpumask_clear(sdom->node_affinity_cpumask); + for_each_node_mask( node, *mask ) + cpumask_or(sdom->node_affinity_cpumask, sdom->node_affinity_cpumask, + &node_to_cpumask(node)); +} + #define for_each_csched_balance_step(__step) \ for ( (__step) = CSCHED_BALANCE_LAST; (__step) >= 0; (__step)-- ) @@ -260,7 +287,8 @@ csched_balance_cpumask(const struct vcpu struct domain *d = vc->domain; struct csched_dom *sdom = CSCHED_DOM(d); - if ( cpumask_full(sdom->node_affinity_cpumask) ) + if ( cpumask_full(sdom->node_affinity_cpumask) || + d->auto_node_affinity == 1 ) return -1; cpumask_and(mask, sdom->node_affinity_cpumask, vc->cpu_affinity); @@ -1786,6 +1814,8 @@ const struct scheduler sched_credit_def .adjust = csched_dom_cntl, .adjust_global = csched_sys_cntl, + .set_node_affinity = csched_set_node_affinity, + .pick_cpu = csched_cpu_pick, .do_schedule = csched_schedule, diff --git a/xen/common/schedule.c b/xen/common/schedule.c --- a/xen/common/schedule.c +++ b/xen/common/schedule.c @@ -588,6 +588,11 @@ int cpu_disable_scheduler(unsigned int c return ret; } +void sched_set_node_affinity(struct domain *d, nodemask_t *mask) +{ + SCHED_OP(DOM2OP(d), set_node_affinity, d, mask); +} + int vcpu_set_affinity(struct vcpu *v, const cpumask_t *affinity) { cpumask_t online_affinity; diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h --- a/xen/include/public/domctl.h +++ b/xen/include/public/domctl.h @@ -279,6 +279,16 @@ typedef struct xen_domctl_getvcpuinfo xe DEFINE_XEN_GUEST_HANDLE(xen_domctl_getvcpuinfo_t); +/* Get/set the NUMA node(s) with which the guest has affinity with. */ +/* XEN_DOMCTL_setnodeaffinity */ +/* XEN_DOMCTL_getnodeaffinity */ +struct xen_domctl_nodeaffinity { + struct xenctl_bitmap nodemap;/* IN */ +}; +typedef struct xen_domctl_nodeaffinity xen_domctl_nodeaffinity_t; +DEFINE_XEN_GUEST_HANDLE(xen_domctl_nodeaffinity_t); + + /* Get/set which physical cpus a vcpu can execute on. */ /* XEN_DOMCTL_setvcpuaffinity */ /* XEN_DOMCTL_getvcpuaffinity */ @@ -900,6 +910,8 @@ struct xen_domctl { #define XEN_DOMCTL_set_access_required 64 #define XEN_DOMCTL_audit_p2m 65 #define XEN_DOMCTL_set_virq_handler 66 +#define XEN_DOMCTL_setnodeaffinity 67 +#define XEN_DOMCTL_getnodeaffinity 68 #define XEN_DOMCTL_gdbsx_guestmemio 1000 #define XEN_DOMCTL_gdbsx_pausevcpu 1001 #define XEN_DOMCTL_gdbsx_unpausevcpu 1002 @@ -913,6 +925,7 @@ struct xen_domctl { struct xen_domctl_getpageframeinfo getpageframeinfo; struct xen_domctl_getpageframeinfo2 getpageframeinfo2; struct xen_domctl_getpageframeinfo3 getpageframeinfo3; + struct xen_domctl_nodeaffinity nodeaffinity; struct xen_domctl_vcpuaffinity vcpuaffinity; struct xen_domctl_shadow_op shadow_op; struct xen_domctl_max_mem max_mem; diff --git a/xen/include/xen/nodemask.h b/xen/include/xen/nodemask.h --- a/xen/include/xen/nodemask.h +++ b/xen/include/xen/nodemask.h @@ -8,8 +8,9 @@ * See detailed comments in the file linux/bitmap.h describing the * data type on which these nodemasks are based. * - * For details of nodemask_scnprintf() and nodemask_parse(), - * see bitmap_scnprintf() and bitmap_parse() in lib/bitmap.c. + * For details of nodemask_scnprintf(), nodelist_scnpintf() and + * nodemask_parse(), see bitmap_scnprintf() and bitmap_parse() + * in lib/bitmap.c. * * The available nodemask operations are: * @@ -48,6 +49,7 @@ * unsigned long *nodes_addr(mask) Array of unsigned long's in mask * * int nodemask_scnprintf(buf, len, mask) Format nodemask for printing + * int nodelist_scnprintf(buf, len, mask) Format nodemask as a list for printing * int nodemask_parse(ubuf, ulen, mask) Parse ascii string as nodemask * * for_each_node_mask(node, mask) for-loop node over mask @@ -280,6 +282,14 @@ static inline int __first_unset_node(con #define nodes_addr(src) ((src).bits) +#define nodelist_scnprintf(buf, len, src) \ + __nodelist_scnprintf((buf), (len), (src), MAX_NUMNODES) +static inline int __nodelist_scnprintf(char *buf, int len, + const nodemask_t *srcp, int nbits) +{ + return bitmap_scnlistprintf(buf, len, srcp->bits, nbits); +} + #if 0 #define nodemask_scnprintf(buf, len, src) \ __nodemask_scnprintf((buf), (len), &(src), MAX_NUMNODES) diff --git a/xen/include/xen/sched-if.h b/xen/include/xen/sched-if.h --- a/xen/include/xen/sched-if.h +++ b/xen/include/xen/sched-if.h @@ -182,6 +182,8 @@ struct scheduler { struct xen_domctl_scheduler_op *); int (*adjust_global) (const struct scheduler *, struct xen_sysctl_scheduler_op *); + void (*set_node_affinity) (const struct scheduler *, + struct domain *, nodemask_t *); void (*dump_settings) (const struct scheduler *); void (*dump_cpu_state) (const struct scheduler *, int); diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h --- a/xen/include/xen/sched.h +++ b/xen/include/xen/sched.h @@ -346,8 +346,12 @@ struct domain /* Various mem_events */ struct mem_event_per_domain *mem_event; - /* Currently computed from union of all vcpu cpu-affinity masks. */ + /* + * Can be specified by the user. If that is not the case, it is + * computed from the union of all the vcpu cpu-affinity masks. + */ nodemask_t node_affinity; + int auto_node_affinity; unsigned int last_alloc_node; spinlock_t node_affinity_lock; }; @@ -416,6 +420,7 @@ static inline void get_knownalive_domain ASSERT(!(atomic_read(&d->refcnt) & DOMAIN_DESTROYED)); } +int domain_set_node_affinity(struct domain *d, const nodemask_t *affinity); void domain_update_node_affinity(struct domain *d); struct domain *domain_create( @@ -519,6 +524,7 @@ void sched_destroy_domain(struct domain int sched_move_domain(struct domain *d, struct cpupool *c); long sched_adjust(struct domain *, struct xen_domctl_scheduler_op *); long sched_adjust_global(struct xen_sysctl_scheduler_op *); +void sched_set_node_affinity(struct domain *, nodemask_t *); int sched_id(void); void sched_tick_suspend(void); void sched_tick_resume(void); diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h --- a/xen/include/xsm/xsm.h +++ b/xen/include/xsm/xsm.h @@ -56,6 +56,7 @@ struct xsm_operations { int (*domain_create) (struct domain *d, u32 ssidref); int (*max_vcpus) (struct domain *d); int (*destroydomain) (struct domain *d); + int (*nodeaffinity) (int cmd, struct domain *d); int (*vcpuaffinity) (int cmd, struct domain *d); int (*scheduler) (struct domain *d); int (*getdomaininfo) (struct domain *d); @@ -229,6 +230,11 @@ static inline int xsm_destroydomain (str return xsm_call(destroydomain(d)); } +static inline int xsm_nodeaffinity (int cmd, struct domain *d) +{ + return xsm_call(nodeaffinity(cmd, d)); +} + static inline int xsm_vcpuaffinity (int cmd, struct domain *d) { return xsm_call(vcpuaffinity(cmd, d)); diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c --- a/xen/xsm/dummy.c +++ b/xen/xsm/dummy.c @@ -634,6 +634,7 @@ void xsm_fixup_ops (struct xsm_operation set_to_dummy_if_null(ops, domain_create); set_to_dummy_if_null(ops, max_vcpus); set_to_dummy_if_null(ops, destroydomain); + set_to_dummy_if_null(ops, nodeaffinity); set_to_dummy_if_null(ops, vcpuaffinity); set_to_dummy_if_null(ops, scheduler); set_to_dummy_if_null(ops, getdomaininfo); diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c --- a/xen/xsm/flask/hooks.c +++ b/xen/xsm/flask/hooks.c @@ -521,17 +521,19 @@ static int flask_destroydomain(struct do DOMAIN__DESTROY); } -static int flask_vcpuaffinity(int cmd, struct domain *d) +static int flask_affinity(int cmd, struct domain *d) { u32 perm; switch ( cmd ) { case XEN_DOMCTL_setvcpuaffinity: - perm = DOMAIN__SETVCPUAFFINITY; + case XEN_DOMCTL_setnodeaffinity: + perm = DOMAIN__SETAFFINITY; break; case XEN_DOMCTL_getvcpuaffinity: - perm = DOMAIN__GETVCPUAFFINITY; + case XEN_DOMCTL_getnodeaffinity: + perm = DOMAIN__GETAFFINITY; break; default: return -EPERM; @@ -1473,7 +1475,8 @@ static struct xsm_operations flask_ops = .domain_create = flask_domain_create, .max_vcpus = flask_max_vcpus, .destroydomain = flask_destroydomain, - .vcpuaffinity = flask_vcpuaffinity, + .nodeaffinity = flask_affinity, + .vcpuaffinity = flask_affinity, .scheduler = flask_scheduler, .getdomaininfo = flask_getdomaininfo, .getvcpucontext = flask_getvcpucontext, diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h --- a/xen/xsm/flask/include/av_perm_to_string.h +++ b/xen/xsm/flask/include/av_perm_to_string.h @@ -37,8 +37,8 @@ S_(SECCLASS_DOMAIN, DOMAIN__TRANSITION, "transition") S_(SECCLASS_DOMAIN, DOMAIN__MAX_VCPUS, "max_vcpus") S_(SECCLASS_DOMAIN, DOMAIN__DESTROY, "destroy") - S_(SECCLASS_DOMAIN, DOMAIN__SETVCPUAFFINITY, "setvcpuaffinity") - S_(SECCLASS_DOMAIN, DOMAIN__GETVCPUAFFINITY, "getvcpuaffinity") + S_(SECCLASS_DOMAIN, DOMAIN__SETAFFINITY, "setaffinity") + S_(SECCLASS_DOMAIN, DOMAIN__GETAFFINITY, "getaffinity") S_(SECCLASS_DOMAIN, DOMAIN__SCHEDULER, "scheduler") S_(SECCLASS_DOMAIN, DOMAIN__GETDOMAININFO, "getdomaininfo") S_(SECCLASS_DOMAIN, DOMAIN__GETVCPUINFO, "getvcpuinfo") diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h --- a/xen/xsm/flask/include/av_permissions.h +++ b/xen/xsm/flask/include/av_permissions.h @@ -38,8 +38,8 @@ #define DOMAIN__TRANSITION 0x00000020UL #define DOMAIN__MAX_VCPUS 0x00000040UL #define DOMAIN__DESTROY 0x00000080UL -#define DOMAIN__SETVCPUAFFINITY 0x00000100UL -#define DOMAIN__GETVCPUAFFINITY 0x00000200UL +#define DOMAIN__SETAFFINITY 0x00000100UL +#define DOMAIN__GETAFFINITY 0x00000200UL #define DOMAIN__SCHEDULER 0x00000400UL #define DOMAIN__GETDOMAININFO 0x00000800UL #define DOMAIN__GETVCPUINFO 0x00001000UL _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:14:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:14:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8fc-0000NM-Mv; Fri, 05 Oct 2012 14:14:28 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8fb-0000La-4b for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:14:27 +0000 Received: from [85.158.143.99:64173] by server-2.bemta-4.messagelabs.com id 6E/D0-06610-24BEE605; Fri, 05 Oct 2012 14:14:26 +0000 X-Env-Sender: raistlin.df@gmail.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1349446461!24834463!2 X-Originating-IP: [74.125.82.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9140 invoked from network); 5 Oct 2012 14:14:25 -0000 Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com) (74.125.82.173) by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:14:25 -0000 Received: by mail-we0-f173.google.com with SMTP id t11so1288032wey.32 for ; Fri, 05 Oct 2012 07:14:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:content-transfer-encoding:subject :x-mercurial-node:message-id:in-reply-to:references:user-agent:date :from:to:cc; bh=253kelXqNvmFtn8FZnGwVtwXhQlf6soH1bM3bLkOzv0=; b=S6k2LhFwAT6xzWkgZj2tUDc9Kx4QxMPnKCKx8DpfNDw5qWgo1fL+jnunw8xWlzOFbV 0mkG9i8rX/PTPfaMSGFTg+hAt0zNnGjK0XIBWYl0v91KkrEKILDACdPTlrE9Q6bO1/1e iCLRsj9xWE03K4S1jK9z8tz2wC/zjdgNycZL/6Npi5Gkns5x59XcUK5pFIWUH7zGuS// cHQ+WMyYBpfyN9TIOc5kYqJ/0mI9kjAVS1J2E1Q/+l/dHASo6OlWnjCrJEYNAIuRhyfG 4xwPy/owd6l+gFjWDiBc3Ta7JqBIP+QAcs2VZaV3VR7z9c2XAQ9veFTGMUQ4RbkjvAXG kKSQ== Received: by 10.180.100.136 with SMTP id ey8mr3751550wib.1.1349446465625; Fri, 05 Oct 2012 07:14:25 -0700 (PDT) Received: from [127.0.1.1] (ip-170-24.sn3.eutelia.it. [213.136.170.24]) by mx.google.com with ESMTPS id fb20sm2909341wid.1.2012.10.05.07.14.23 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Oct 2012 07:14:24 -0700 (PDT) MIME-Version: 1.0 X-Mercurial-Node: aa8255447a30ef25ff12066408e4ed655692fb45 Message-Id: In-Reply-To: References: User-Agent: Mercurial-patchbomb/2.2.2 Date: Fri, 05 Oct 2012 16:08:25 +0200 From: Dario Faggioli To: xen-devel@lists.xen.org Cc: Andre Przywara , Ian Campbell , Anil Madhavapeddy , George Dunlap , Andrew Cooper , Juergen Gross , Ian Jackson , Jan Beulich , Marcus Granado , Daniel De Graaf , Matt Wilson Subject: [Xen-devel] [PATCH 7 of 8] libxl: automatic placement deals with node-affinity X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Which basically means the following two things: 1) during domain creation, it is the node-affinity of the domain --rather than the vcpu-affinities of its vcpus-- that is affected by automatic placement; 2) during automatic placement, when counting how many vcpus are already "bound" to a placement candidate (as part of the process of choosing the best candidate), node-affinity is also considered, together with vcpu-affinity. Signed-off-by: Dario Faggioli diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c --- a/tools/libxl/libxl_dom.c +++ b/tools/libxl/libxl_dom.c @@ -133,13 +133,13 @@ static int numa_place_domain(libxl__gc * { int found; libxl__numa_candidate candidate; - libxl_bitmap candidate_nodemap; + libxl_bitmap cpupool_nodemap; libxl_cpupoolinfo cpupool_info; int i, cpupool, rc = 0; uint32_t memkb; libxl__numa_candidate_init(&candidate); - libxl_bitmap_init(&candidate_nodemap); + libxl_bitmap_init(&cpupool_nodemap); /* * Extract the cpumap from the cpupool the domain belong to. In fact, @@ -156,7 +156,7 @@ static int numa_place_domain(libxl__gc * rc = libxl_domain_need_memory(CTX, info, &memkb); if (rc) goto out; - if (libxl_node_bitmap_alloc(CTX, &candidate_nodemap, 0)) { + if (libxl_node_bitmap_alloc(CTX, &cpupool_nodemap, 0)) { rc = ERROR_FAIL; goto out; } @@ -174,17 +174,19 @@ static int numa_place_domain(libxl__gc * if (found == 0) goto out; - /* Map the candidate's node map to the domain's info->cpumap */ - libxl__numa_candidate_get_nodemap(gc, &candidate, &candidate_nodemap); - rc = libxl_nodemap_to_cpumap(CTX, &candidate_nodemap, &info->cpumap); + /* Map the candidate's node map to the domain's info->nodemap */ + libxl__numa_candidate_get_nodemap(gc, &candidate, &info->nodemap); + + /* Avoid trying to set the affinity to nodes that might be in the + * candidate's nodemap but out of our cpupool. */ + rc = libxl_cpumap_to_nodemap(CTX, &cpupool_info.cpumap, + &cpupool_nodemap); if (rc) goto out; - /* Avoid trying to set the affinity to cpus that might be in the - * nodemap but not in our cpupool. */ - libxl_for_each_set_bit(i, info->cpumap) { - if (!libxl_bitmap_test(&cpupool_info.cpumap, i)) - libxl_bitmap_reset(&info->cpumap, i); + libxl_for_each_set_bit(i, info->nodemap) { + if (!libxl_bitmap_test(&cpupool_nodemap, i)) + libxl_bitmap_reset(&info->nodemap, i); } LOG(DETAIL, "NUMA placement candidate with %d nodes, %d cpus and " @@ -193,7 +195,7 @@ static int numa_place_domain(libxl__gc * out: libxl__numa_candidate_dispose(&candidate); - libxl_bitmap_dispose(&candidate_nodemap); + libxl_bitmap_dispose(&cpupool_nodemap); libxl_cpupoolinfo_dispose(&cpupool_info); return rc; } @@ -211,10 +213,10 @@ int libxl__build_pre(libxl__gc *gc, uint /* * Check if the domain has any CPU affinity. If not, try to build * up one. In case numa_place_domain() find at least a suitable - * candidate, it will affect info->cpumap accordingly; if it + * candidate, it will affect info->nodemap accordingly; if it * does not, it just leaves it as it is. This means (unless * some weird error manifests) the subsequent call to - * libxl_set_vcpuaffinity_all() will do the actual placement, + * libxl_domain_set_nodeaffinity() will do the actual placement, * whatever that turns out to be. */ if (libxl_defbool_val(info->numa_placement)) { diff --git a/tools/libxl/libxl_numa.c b/tools/libxl/libxl_numa.c --- a/tools/libxl/libxl_numa.c +++ b/tools/libxl/libxl_numa.c @@ -171,7 +171,7 @@ static int nodemap_to_nr_vcpus(libxl__gc const libxl_bitmap *nodemap) { libxl_dominfo *dinfo = NULL; - libxl_bitmap vcpu_nodemap; + libxl_bitmap vcpu_nodemap, dom_nodemap; int nr_doms, nr_cpus; int nr_vcpus = 0; int i, j, k; @@ -185,6 +185,12 @@ static int nodemap_to_nr_vcpus(libxl__gc return ERROR_FAIL; } + if (libxl_node_bitmap_alloc(CTX, &dom_nodemap, 0) < 0) { + libxl_dominfo_list_free(dinfo, nr_doms); + libxl_bitmap_dispose(&vcpu_nodemap); + return ERROR_FAIL; + } + for (i = 0; i < nr_doms; i++) { libxl_vcpuinfo *vinfo; int nr_dom_vcpus; @@ -193,6 +199,9 @@ static int nodemap_to_nr_vcpus(libxl__gc if (vinfo == NULL) continue; + /* Retrieve the domain's node-affinity map (see below) */ + libxl_domain_get_nodeaffinity(CTX, dinfo[i].domid, &dom_nodemap); + /* For each vcpu of each domain ... */ for (j = 0; j < nr_dom_vcpus; j++) { @@ -201,9 +210,17 @@ static int nodemap_to_nr_vcpus(libxl__gc libxl_for_each_set_bit(k, vinfo[j].cpumap) libxl_bitmap_set(&vcpu_nodemap, tinfo[k].node); - /* And check if that map has any intersection with our nodemap */ + /* + * We now check whether the && of the vcpu's nodemap and the + * domain's nodemap has any intersection with the nodemap of our + * canidate. + * Using both (vcpu's and domain's) nodemaps allows us to take + * both vcpu-affinity and node-affinity into account when counting + * the number of vcpus bound to the candidate. + */ libxl_for_each_set_bit(k, vcpu_nodemap) { - if (libxl_bitmap_test(nodemap, k)) { + if (libxl_bitmap_test(&dom_nodemap, k) && + libxl_bitmap_test(nodemap, k)) { nr_vcpus++; break; } @@ -213,6 +230,7 @@ static int nodemap_to_nr_vcpus(libxl__gc libxl_vcpuinfo_list_free(vinfo, nr_dom_vcpus); } + libxl_bitmap_dispose(&dom_nodemap); libxl_bitmap_dispose(&vcpu_nodemap); libxl_dominfo_list_free(dinfo, nr_doms); return nr_vcpus; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:14:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:14:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8fc-0000NM-Mv; Fri, 05 Oct 2012 14:14:28 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8fb-0000La-4b for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:14:27 +0000 Received: from [85.158.143.99:64173] by server-2.bemta-4.messagelabs.com id 6E/D0-06610-24BEE605; Fri, 05 Oct 2012 14:14:26 +0000 X-Env-Sender: raistlin.df@gmail.com X-Msg-Ref: server-2.tower-216.messagelabs.com!1349446461!24834463!2 X-Originating-IP: [74.125.82.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9140 invoked from network); 5 Oct 2012 14:14:25 -0000 Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com) (74.125.82.173) by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:14:25 -0000 Received: by mail-we0-f173.google.com with SMTP id t11so1288032wey.32 for ; Fri, 05 Oct 2012 07:14:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:content-transfer-encoding:subject :x-mercurial-node:message-id:in-reply-to:references:user-agent:date :from:to:cc; bh=253kelXqNvmFtn8FZnGwVtwXhQlf6soH1bM3bLkOzv0=; b=S6k2LhFwAT6xzWkgZj2tUDc9Kx4QxMPnKCKx8DpfNDw5qWgo1fL+jnunw8xWlzOFbV 0mkG9i8rX/PTPfaMSGFTg+hAt0zNnGjK0XIBWYl0v91KkrEKILDACdPTlrE9Q6bO1/1e iCLRsj9xWE03K4S1jK9z8tz2wC/zjdgNycZL/6Npi5Gkns5x59XcUK5pFIWUH7zGuS// cHQ+WMyYBpfyN9TIOc5kYqJ/0mI9kjAVS1J2E1Q/+l/dHASo6OlWnjCrJEYNAIuRhyfG 4xwPy/owd6l+gFjWDiBc3Ta7JqBIP+QAcs2VZaV3VR7z9c2XAQ9veFTGMUQ4RbkjvAXG kKSQ== Received: by 10.180.100.136 with SMTP id ey8mr3751550wib.1.1349446465625; Fri, 05 Oct 2012 07:14:25 -0700 (PDT) Received: from [127.0.1.1] (ip-170-24.sn3.eutelia.it. [213.136.170.24]) by mx.google.com with ESMTPS id fb20sm2909341wid.1.2012.10.05.07.14.23 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Oct 2012 07:14:24 -0700 (PDT) MIME-Version: 1.0 X-Mercurial-Node: aa8255447a30ef25ff12066408e4ed655692fb45 Message-Id: In-Reply-To: References: User-Agent: Mercurial-patchbomb/2.2.2 Date: Fri, 05 Oct 2012 16:08:25 +0200 From: Dario Faggioli To: xen-devel@lists.xen.org Cc: Andre Przywara , Ian Campbell , Anil Madhavapeddy , George Dunlap , Andrew Cooper , Juergen Gross , Ian Jackson , Jan Beulich , Marcus Granado , Daniel De Graaf , Matt Wilson Subject: [Xen-devel] [PATCH 7 of 8] libxl: automatic placement deals with node-affinity X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Which basically means the following two things: 1) during domain creation, it is the node-affinity of the domain --rather than the vcpu-affinities of its vcpus-- that is affected by automatic placement; 2) during automatic placement, when counting how many vcpus are already "bound" to a placement candidate (as part of the process of choosing the best candidate), node-affinity is also considered, together with vcpu-affinity. Signed-off-by: Dario Faggioli diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c --- a/tools/libxl/libxl_dom.c +++ b/tools/libxl/libxl_dom.c @@ -133,13 +133,13 @@ static int numa_place_domain(libxl__gc * { int found; libxl__numa_candidate candidate; - libxl_bitmap candidate_nodemap; + libxl_bitmap cpupool_nodemap; libxl_cpupoolinfo cpupool_info; int i, cpupool, rc = 0; uint32_t memkb; libxl__numa_candidate_init(&candidate); - libxl_bitmap_init(&candidate_nodemap); + libxl_bitmap_init(&cpupool_nodemap); /* * Extract the cpumap from the cpupool the domain belong to. In fact, @@ -156,7 +156,7 @@ static int numa_place_domain(libxl__gc * rc = libxl_domain_need_memory(CTX, info, &memkb); if (rc) goto out; - if (libxl_node_bitmap_alloc(CTX, &candidate_nodemap, 0)) { + if (libxl_node_bitmap_alloc(CTX, &cpupool_nodemap, 0)) { rc = ERROR_FAIL; goto out; } @@ -174,17 +174,19 @@ static int numa_place_domain(libxl__gc * if (found == 0) goto out; - /* Map the candidate's node map to the domain's info->cpumap */ - libxl__numa_candidate_get_nodemap(gc, &candidate, &candidate_nodemap); - rc = libxl_nodemap_to_cpumap(CTX, &candidate_nodemap, &info->cpumap); + /* Map the candidate's node map to the domain's info->nodemap */ + libxl__numa_candidate_get_nodemap(gc, &candidate, &info->nodemap); + + /* Avoid trying to set the affinity to nodes that might be in the + * candidate's nodemap but out of our cpupool. */ + rc = libxl_cpumap_to_nodemap(CTX, &cpupool_info.cpumap, + &cpupool_nodemap); if (rc) goto out; - /* Avoid trying to set the affinity to cpus that might be in the - * nodemap but not in our cpupool. */ - libxl_for_each_set_bit(i, info->cpumap) { - if (!libxl_bitmap_test(&cpupool_info.cpumap, i)) - libxl_bitmap_reset(&info->cpumap, i); + libxl_for_each_set_bit(i, info->nodemap) { + if (!libxl_bitmap_test(&cpupool_nodemap, i)) + libxl_bitmap_reset(&info->nodemap, i); } LOG(DETAIL, "NUMA placement candidate with %d nodes, %d cpus and " @@ -193,7 +195,7 @@ static int numa_place_domain(libxl__gc * out: libxl__numa_candidate_dispose(&candidate); - libxl_bitmap_dispose(&candidate_nodemap); + libxl_bitmap_dispose(&cpupool_nodemap); libxl_cpupoolinfo_dispose(&cpupool_info); return rc; } @@ -211,10 +213,10 @@ int libxl__build_pre(libxl__gc *gc, uint /* * Check if the domain has any CPU affinity. If not, try to build * up one. In case numa_place_domain() find at least a suitable - * candidate, it will affect info->cpumap accordingly; if it + * candidate, it will affect info->nodemap accordingly; if it * does not, it just leaves it as it is. This means (unless * some weird error manifests) the subsequent call to - * libxl_set_vcpuaffinity_all() will do the actual placement, + * libxl_domain_set_nodeaffinity() will do the actual placement, * whatever that turns out to be. */ if (libxl_defbool_val(info->numa_placement)) { diff --git a/tools/libxl/libxl_numa.c b/tools/libxl/libxl_numa.c --- a/tools/libxl/libxl_numa.c +++ b/tools/libxl/libxl_numa.c @@ -171,7 +171,7 @@ static int nodemap_to_nr_vcpus(libxl__gc const libxl_bitmap *nodemap) { libxl_dominfo *dinfo = NULL; - libxl_bitmap vcpu_nodemap; + libxl_bitmap vcpu_nodemap, dom_nodemap; int nr_doms, nr_cpus; int nr_vcpus = 0; int i, j, k; @@ -185,6 +185,12 @@ static int nodemap_to_nr_vcpus(libxl__gc return ERROR_FAIL; } + if (libxl_node_bitmap_alloc(CTX, &dom_nodemap, 0) < 0) { + libxl_dominfo_list_free(dinfo, nr_doms); + libxl_bitmap_dispose(&vcpu_nodemap); + return ERROR_FAIL; + } + for (i = 0; i < nr_doms; i++) { libxl_vcpuinfo *vinfo; int nr_dom_vcpus; @@ -193,6 +199,9 @@ static int nodemap_to_nr_vcpus(libxl__gc if (vinfo == NULL) continue; + /* Retrieve the domain's node-affinity map (see below) */ + libxl_domain_get_nodeaffinity(CTX, dinfo[i].domid, &dom_nodemap); + /* For each vcpu of each domain ... */ for (j = 0; j < nr_dom_vcpus; j++) { @@ -201,9 +210,17 @@ static int nodemap_to_nr_vcpus(libxl__gc libxl_for_each_set_bit(k, vinfo[j].cpumap) libxl_bitmap_set(&vcpu_nodemap, tinfo[k].node); - /* And check if that map has any intersection with our nodemap */ + /* + * We now check whether the && of the vcpu's nodemap and the + * domain's nodemap has any intersection with the nodemap of our + * canidate. + * Using both (vcpu's and domain's) nodemaps allows us to take + * both vcpu-affinity and node-affinity into account when counting + * the number of vcpus bound to the candidate. + */ libxl_for_each_set_bit(k, vcpu_nodemap) { - if (libxl_bitmap_test(nodemap, k)) { + if (libxl_bitmap_test(&dom_nodemap, k) && + libxl_bitmap_test(nodemap, k)) { nr_vcpus++; break; } @@ -213,6 +230,7 @@ static int nodemap_to_nr_vcpus(libxl__gc libxl_vcpuinfo_list_free(vinfo, nr_dom_vcpus); } + libxl_bitmap_dispose(&dom_nodemap); libxl_bitmap_dispose(&vcpu_nodemap); libxl_dominfo_list_free(dinfo, nr_doms); return nr_vcpus; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:14:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:14:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8fU-0000IJ-LS; Fri, 05 Oct 2012 14:14:20 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8fT-0000Hg-NA for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:14:20 +0000 Received: from [85.158.143.35:12653] by server-1.bemta-4.messagelabs.com id CF/36-05684-93BEE605; Fri, 05 Oct 2012 14:14:17 +0000 X-Env-Sender: raistlin.df@gmail.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1349446448!12532791!3 X-Originating-IP: [74.125.82.51] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28558 invoked from network); 5 Oct 2012 14:14:16 -0000 Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com) (74.125.82.51) by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:14:16 -0000 Received: by mail-wg0-f51.google.com with SMTP id ed3so635331wgb.32 for ; Fri, 05 Oct 2012 07:14:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:content-transfer-encoding:subject :x-mercurial-node:message-id:in-reply-to:references:user-agent:date :from:to:cc; bh=uiuibp2eavr3ToYSR2MTs8P0QXJDXSmXitlB1uX96cU=; b=fUUdali+HGFbvFMvOX0UzqSSrZAdk5oKK+OWtr0YK0KqAeKzs0UVW7pv5VrsPBCRoQ qrHBmIXFHld54B9NPKqeVH8DdcQYdZ+SqYng5RwpyFunqbu9182iekTVSnRXE7Iy0FvS pss/JM29ytgWerg8adQJU338f+PqDvfmZc1pffq5TJkKzR4Pd2JdO7jQtbnJ6Eycae1Q 8M0wSu+qSP66QYHD0mshVeIWhNPzHQfGP+wZVeKNOhTX8gsB4z/7WSeEek6Ga7CFqF4i wSXqynzcizg8Bc+uecYLxaUC2V6DhJ/xgyvRqDfsg7GJTfib6+37V9R9jiW9TY+jEIiB WsLA== Received: by 10.216.195.170 with SMTP id p42mr5631627wen.132.1349446456475; Fri, 05 Oct 2012 07:14:16 -0700 (PDT) Received: from [127.0.1.1] (ip-170-24.sn3.eutelia.it. [213.136.170.24]) by mx.google.com with ESMTPS id fb20sm2909341wid.1.2012.10.05.07.14.13 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Oct 2012 07:14:15 -0700 (PDT) MIME-Version: 1.0 X-Mercurial-Node: ca2fa958879bbffa9bc695b51b765c40cc4b5564 Message-Id: In-Reply-To: References: User-Agent: Mercurial-patchbomb/2.2.2 Date: Fri, 05 Oct 2012 16:08:21 +0200 From: Dario Faggioli To: xen-devel@lists.xen.org Cc: Andre Przywara , Ian Campbell , Anil Madhavapeddy , George Dunlap , Andrew Cooper , Juergen Gross , Ian Jackson , Jan Beulich , Marcus Granado , Daniel De Graaf , Matt Wilson Subject: [Xen-devel] [PATCH 3 of 8] xen: let the (credit) scheduler know about `node affinity` X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org As vcpu-affinity tells where vcpus can run, node-affinity tells where a domain's vcpus prefer to run. Respecting vcpu-affinity is the primary concern, but honouring node-affinity will likely result in some performances benefit. This change modifies the vcpu load balancing algorithm (for the credit scheduler only), introducing a two steps logic. During the first step, we use the node-affinity mask. The aim is giving precedence to the CPUs where it is known to be preferrable for the domain to run. If that fails in finding a valid CPU, the node-affinity is just ignored and, in the second step, we fall back to using cpu-affinity only. Signed-off-by: Dario Faggioli diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c --- a/xen/common/sched_credit.c +++ b/xen/common/sched_credit.c @@ -101,6 +101,13 @@ /* + * Node Balancing + */ +#define CSCHED_BALANCE_CPU_AFFINITY 0 +#define CSCHED_BALANCE_NODE_AFFINITY 1 +#define CSCHED_BALANCE_LAST CSCHED_BALANCE_NODE_AFFINITY + +/* * Boot parameters */ static int __read_mostly sched_credit_tslice_ms = CSCHED_DEFAULT_TSLICE_MS; @@ -148,6 +155,9 @@ struct csched_dom { struct list_head active_vcpu; struct list_head active_sdom_elem; struct domain *dom; + /* cpumask translated from the domain' node-affinity + * mask. Basically, the CPUs we prefer to be scheduled on. */ + cpumask_var_t node_affinity_cpumask; uint16_t active_vcpu_count; uint16_t weight; uint16_t cap; @@ -228,6 +238,39 @@ static inline void list_del_init(&svc->runq_elem); } +#define for_each_csched_balance_step(__step) \ + for ( (__step) = CSCHED_BALANCE_LAST; (__step) >= 0; (__step)-- ) + +/* + * Each csched-balance step should use its own cpumask. This function + * determines which one, given the step, and copies it in mask. Notice + * that, in the case of a node balancing step, it also filters out from + * the node-affinity mask the cpus that are not part of vc's cpu-affinity, + * as we do not want to end up running a vcpu where it is not allowed to! + * + * As an optimization, if a domain does not have any specific node-affinity + * (namely, its node affinity is automatically computed), we inform the + * caller that he can skip the first step by returning -1. + */ +static int +csched_balance_cpumask(const struct vcpu *vc, int step, cpumask_t *mask) +{ + if ( step == CSCHED_BALANCE_NODE_AFFINITY ) + { + struct domain *d = vc->domain; + struct csched_dom *sdom = CSCHED_DOM(d); + + if ( cpumask_full(sdom->node_affinity_cpumask) ) + return -1; + + cpumask_and(mask, sdom->node_affinity_cpumask, vc->cpu_affinity); + } + else /* step == CSCHED_BALANACE_CPU_AFFINITY */ + cpumask_copy(mask, vc->cpu_affinity); + + return 0; +} + static void burn_credits(struct csched_vcpu *svc, s_time_t now) { s_time_t delta; @@ -250,6 +293,20 @@ boolean_param("tickle_one_idle_cpu", opt DEFINE_PER_CPU(unsigned int, last_tickle_cpu); static inline void +__cpumask_tickle(cpumask_t *mask, const cpumask_t *idle_mask) +{ + CSCHED_STAT_CRANK(tickle_idlers_some); + if ( opt_tickle_one_idle ) + { + this_cpu(last_tickle_cpu) = + cpumask_cycle(this_cpu(last_tickle_cpu), idle_mask); + cpumask_set_cpu(this_cpu(last_tickle_cpu), mask); + } + else + cpumask_or(mask, mask, idle_mask); +} + +static inline void __runq_tickle(unsigned int cpu, struct csched_vcpu *new) { struct csched_vcpu * const cur = @@ -287,22 +344,26 @@ static inline void } else { - cpumask_t idle_mask; + cpumask_t idle_mask, balance_mask; + int balance_step; - cpumask_and(&idle_mask, prv->idlers, new->vcpu->cpu_affinity); - if ( !cpumask_empty(&idle_mask) ) + for_each_csched_balance_step(balance_step) { - CSCHED_STAT_CRANK(tickle_idlers_some); - if ( opt_tickle_one_idle ) - { - this_cpu(last_tickle_cpu) = - cpumask_cycle(this_cpu(last_tickle_cpu), &idle_mask); - cpumask_set_cpu(this_cpu(last_tickle_cpu), &mask); - } - else - cpumask_or(&mask, &mask, &idle_mask); + if ( csched_balance_cpumask(new->vcpu, balance_step, + &balance_mask) ) + continue; + + /* Look for idlers in the step's cpumask */ + cpumask_and(&idle_mask, prv->idlers, &balance_mask); + if ( !cpumask_empty(&idle_mask) ) + __cpumask_tickle(&mask, &idle_mask); + + cpumask_and(&mask, &mask, &balance_mask); + + /* We can quit balancing if we found someone to tickle */ + if ( !cpumask_empty(&mask) ) + break; } - cpumask_and(&mask, &mask, new->vcpu->cpu_affinity); } } @@ -443,35 +504,42 @@ static inline int } static inline int -__csched_vcpu_is_migrateable(struct vcpu *vc, int dest_cpu) +__csched_vcpu_is_migrateable(struct vcpu *vc, int dest_cpu, cpumask_t *mask) { /* * Don't pick up work that's in the peer's scheduling tail or hot on - * peer PCPU. Only pick up work that's allowed to run on our CPU. + * peer PCPU. Only pick up work that prefers and/or is allowed to run + * on our CPU. */ return !vc->is_running && !__csched_vcpu_is_cache_hot(vc) && - cpumask_test_cpu(dest_cpu, vc->cpu_affinity); + cpumask_test_cpu(dest_cpu, mask); } static int _csched_cpu_pick(const struct scheduler *ops, struct vcpu *vc, bool_t commit) { - cpumask_t cpus; + cpumask_t cpus, start_cpus; cpumask_t idlers; cpumask_t *online; + struct csched_dom *sdom = CSCHED_DOM(vc->domain); struct csched_pcpu *spc = NULL; int cpu; /* - * Pick from online CPUs in VCPU's affinity mask, giving a - * preference to its current processor if it's in there. + * Pick an online CPU from the && of vcpu-affinity and node-affinity + * masks (if not empty, in which case only the vcpu-affinity mask is + * used). Also, try to give a preference to its current processor if + * it's in there. */ online = cpupool_scheduler_cpumask(vc->domain->cpupool); cpumask_and(&cpus, online, vc->cpu_affinity); - cpu = cpumask_test_cpu(vc->processor, &cpus) + cpumask_and(&start_cpus, &cpus, sdom->node_affinity_cpumask); + if ( unlikely(cpumask_empty(&start_cpus)) ) + cpumask_copy(&start_cpus, &cpus); + cpu = cpumask_test_cpu(vc->processor, &start_cpus) ? vc->processor - : cpumask_cycle(vc->processor, &cpus); + : cpumask_cycle(vc->processor, &start_cpus); ASSERT( !cpumask_empty(&cpus) && cpumask_test_cpu(cpu, &cpus) ); /* @@ -867,6 +935,13 @@ csched_alloc_domdata(const struct schedu if ( sdom == NULL ) return NULL; + if ( !alloc_cpumask_var(&sdom->node_affinity_cpumask) ) + { + xfree(sdom); + return NULL; + } + cpumask_setall(sdom->node_affinity_cpumask); + /* Initialize credit and weight */ INIT_LIST_HEAD(&sdom->active_vcpu); sdom->active_vcpu_count = 0; @@ -900,6 +975,9 @@ csched_dom_init(const struct scheduler * static void csched_free_domdata(const struct scheduler *ops, void *data) { + struct csched_dom *sdom = data; + + free_cpumask_var(sdom->node_affinity_cpumask); xfree(data); } @@ -1211,30 +1289,48 @@ csched_runq_steal(int peer_cpu, int cpu, */ if ( peer_pcpu != NULL && !is_idle_vcpu(peer_vcpu) ) { - list_for_each( iter, &peer_pcpu->runq ) + int balance_step; + + /* + * Take node-affinity into account. That means, for all the vcpus + * in peer_pcpu's runq, check _first_ if their node-affinity allows + * them to run on cpu. If not, retry the loop considering plain + * vcpu-affinity. Also, notice that as soon as one vcpu is found, + * balancing is considered done, and the vcpu is returned to the + * caller. + */ + for_each_csched_balance_step(balance_step) { - speer = __runq_elem(iter); + list_for_each( iter, &peer_pcpu->runq ) + { + cpumask_t balance_mask; - /* - * If next available VCPU here is not of strictly higher - * priority than ours, this PCPU is useless to us. - */ - if ( speer->pri <= pri ) - break; + speer = __runq_elem(iter); - /* Is this VCPU is runnable on our PCPU? */ - vc = speer->vcpu; - BUG_ON( is_idle_vcpu(vc) ); + /* + * If next available VCPU here is not of strictly higher + * priority than ours, this PCPU is useless to us. + */ + if ( speer->pri <= pri ) + break; - if (__csched_vcpu_is_migrateable(vc, cpu)) - { - /* We got a candidate. Grab it! */ - CSCHED_VCPU_STAT_CRANK(speer, migrate_q); - CSCHED_STAT_CRANK(migrate_queued); - WARN_ON(vc->is_urgent); - __runq_remove(speer); - vc->processor = cpu; - return speer; + /* Is this VCPU runnable on our PCPU? */ + vc = speer->vcpu; + BUG_ON( is_idle_vcpu(vc) ); + + if ( csched_balance_cpumask(vc, balance_step, &balance_mask) ) + continue; + + if (__csched_vcpu_is_migrateable(vc, cpu, &balance_mask)) + { + /* We got a candidate. Grab it! */ + CSCHED_VCPU_STAT_CRANK(speer, migrate_q); + CSCHED_STAT_CRANK(migrate_queued); + WARN_ON(vc->is_urgent); + __runq_remove(speer); + vc->processor = cpu; + return speer; + } } } } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:14:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:14:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8fU-0000IJ-LS; Fri, 05 Oct 2012 14:14:20 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8fT-0000Hg-NA for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:14:20 +0000 Received: from [85.158.143.35:12653] by server-1.bemta-4.messagelabs.com id CF/36-05684-93BEE605; Fri, 05 Oct 2012 14:14:17 +0000 X-Env-Sender: raistlin.df@gmail.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1349446448!12532791!3 X-Originating-IP: [74.125.82.51] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28558 invoked from network); 5 Oct 2012 14:14:16 -0000 Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com) (74.125.82.51) by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:14:16 -0000 Received: by mail-wg0-f51.google.com with SMTP id ed3so635331wgb.32 for ; Fri, 05 Oct 2012 07:14:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:content-transfer-encoding:subject :x-mercurial-node:message-id:in-reply-to:references:user-agent:date :from:to:cc; bh=uiuibp2eavr3ToYSR2MTs8P0QXJDXSmXitlB1uX96cU=; b=fUUdali+HGFbvFMvOX0UzqSSrZAdk5oKK+OWtr0YK0KqAeKzs0UVW7pv5VrsPBCRoQ qrHBmIXFHld54B9NPKqeVH8DdcQYdZ+SqYng5RwpyFunqbu9182iekTVSnRXE7Iy0FvS pss/JM29ytgWerg8adQJU338f+PqDvfmZc1pffq5TJkKzR4Pd2JdO7jQtbnJ6Eycae1Q 8M0wSu+qSP66QYHD0mshVeIWhNPzHQfGP+wZVeKNOhTX8gsB4z/7WSeEek6Ga7CFqF4i wSXqynzcizg8Bc+uecYLxaUC2V6DhJ/xgyvRqDfsg7GJTfib6+37V9R9jiW9TY+jEIiB WsLA== Received: by 10.216.195.170 with SMTP id p42mr5631627wen.132.1349446456475; Fri, 05 Oct 2012 07:14:16 -0700 (PDT) Received: from [127.0.1.1] (ip-170-24.sn3.eutelia.it. [213.136.170.24]) by mx.google.com with ESMTPS id fb20sm2909341wid.1.2012.10.05.07.14.13 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Oct 2012 07:14:15 -0700 (PDT) MIME-Version: 1.0 X-Mercurial-Node: ca2fa958879bbffa9bc695b51b765c40cc4b5564 Message-Id: In-Reply-To: References: User-Agent: Mercurial-patchbomb/2.2.2 Date: Fri, 05 Oct 2012 16:08:21 +0200 From: Dario Faggioli To: xen-devel@lists.xen.org Cc: Andre Przywara , Ian Campbell , Anil Madhavapeddy , George Dunlap , Andrew Cooper , Juergen Gross , Ian Jackson , Jan Beulich , Marcus Granado , Daniel De Graaf , Matt Wilson Subject: [Xen-devel] [PATCH 3 of 8] xen: let the (credit) scheduler know about `node affinity` X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org As vcpu-affinity tells where vcpus can run, node-affinity tells where a domain's vcpus prefer to run. Respecting vcpu-affinity is the primary concern, but honouring node-affinity will likely result in some performances benefit. This change modifies the vcpu load balancing algorithm (for the credit scheduler only), introducing a two steps logic. During the first step, we use the node-affinity mask. The aim is giving precedence to the CPUs where it is known to be preferrable for the domain to run. If that fails in finding a valid CPU, the node-affinity is just ignored and, in the second step, we fall back to using cpu-affinity only. Signed-off-by: Dario Faggioli diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c --- a/xen/common/sched_credit.c +++ b/xen/common/sched_credit.c @@ -101,6 +101,13 @@ /* + * Node Balancing + */ +#define CSCHED_BALANCE_CPU_AFFINITY 0 +#define CSCHED_BALANCE_NODE_AFFINITY 1 +#define CSCHED_BALANCE_LAST CSCHED_BALANCE_NODE_AFFINITY + +/* * Boot parameters */ static int __read_mostly sched_credit_tslice_ms = CSCHED_DEFAULT_TSLICE_MS; @@ -148,6 +155,9 @@ struct csched_dom { struct list_head active_vcpu; struct list_head active_sdom_elem; struct domain *dom; + /* cpumask translated from the domain' node-affinity + * mask. Basically, the CPUs we prefer to be scheduled on. */ + cpumask_var_t node_affinity_cpumask; uint16_t active_vcpu_count; uint16_t weight; uint16_t cap; @@ -228,6 +238,39 @@ static inline void list_del_init(&svc->runq_elem); } +#define for_each_csched_balance_step(__step) \ + for ( (__step) = CSCHED_BALANCE_LAST; (__step) >= 0; (__step)-- ) + +/* + * Each csched-balance step should use its own cpumask. This function + * determines which one, given the step, and copies it in mask. Notice + * that, in the case of a node balancing step, it also filters out from + * the node-affinity mask the cpus that are not part of vc's cpu-affinity, + * as we do not want to end up running a vcpu where it is not allowed to! + * + * As an optimization, if a domain does not have any specific node-affinity + * (namely, its node affinity is automatically computed), we inform the + * caller that he can skip the first step by returning -1. + */ +static int +csched_balance_cpumask(const struct vcpu *vc, int step, cpumask_t *mask) +{ + if ( step == CSCHED_BALANCE_NODE_AFFINITY ) + { + struct domain *d = vc->domain; + struct csched_dom *sdom = CSCHED_DOM(d); + + if ( cpumask_full(sdom->node_affinity_cpumask) ) + return -1; + + cpumask_and(mask, sdom->node_affinity_cpumask, vc->cpu_affinity); + } + else /* step == CSCHED_BALANACE_CPU_AFFINITY */ + cpumask_copy(mask, vc->cpu_affinity); + + return 0; +} + static void burn_credits(struct csched_vcpu *svc, s_time_t now) { s_time_t delta; @@ -250,6 +293,20 @@ boolean_param("tickle_one_idle_cpu", opt DEFINE_PER_CPU(unsigned int, last_tickle_cpu); static inline void +__cpumask_tickle(cpumask_t *mask, const cpumask_t *idle_mask) +{ + CSCHED_STAT_CRANK(tickle_idlers_some); + if ( opt_tickle_one_idle ) + { + this_cpu(last_tickle_cpu) = + cpumask_cycle(this_cpu(last_tickle_cpu), idle_mask); + cpumask_set_cpu(this_cpu(last_tickle_cpu), mask); + } + else + cpumask_or(mask, mask, idle_mask); +} + +static inline void __runq_tickle(unsigned int cpu, struct csched_vcpu *new) { struct csched_vcpu * const cur = @@ -287,22 +344,26 @@ static inline void } else { - cpumask_t idle_mask; + cpumask_t idle_mask, balance_mask; + int balance_step; - cpumask_and(&idle_mask, prv->idlers, new->vcpu->cpu_affinity); - if ( !cpumask_empty(&idle_mask) ) + for_each_csched_balance_step(balance_step) { - CSCHED_STAT_CRANK(tickle_idlers_some); - if ( opt_tickle_one_idle ) - { - this_cpu(last_tickle_cpu) = - cpumask_cycle(this_cpu(last_tickle_cpu), &idle_mask); - cpumask_set_cpu(this_cpu(last_tickle_cpu), &mask); - } - else - cpumask_or(&mask, &mask, &idle_mask); + if ( csched_balance_cpumask(new->vcpu, balance_step, + &balance_mask) ) + continue; + + /* Look for idlers in the step's cpumask */ + cpumask_and(&idle_mask, prv->idlers, &balance_mask); + if ( !cpumask_empty(&idle_mask) ) + __cpumask_tickle(&mask, &idle_mask); + + cpumask_and(&mask, &mask, &balance_mask); + + /* We can quit balancing if we found someone to tickle */ + if ( !cpumask_empty(&mask) ) + break; } - cpumask_and(&mask, &mask, new->vcpu->cpu_affinity); } } @@ -443,35 +504,42 @@ static inline int } static inline int -__csched_vcpu_is_migrateable(struct vcpu *vc, int dest_cpu) +__csched_vcpu_is_migrateable(struct vcpu *vc, int dest_cpu, cpumask_t *mask) { /* * Don't pick up work that's in the peer's scheduling tail or hot on - * peer PCPU. Only pick up work that's allowed to run on our CPU. + * peer PCPU. Only pick up work that prefers and/or is allowed to run + * on our CPU. */ return !vc->is_running && !__csched_vcpu_is_cache_hot(vc) && - cpumask_test_cpu(dest_cpu, vc->cpu_affinity); + cpumask_test_cpu(dest_cpu, mask); } static int _csched_cpu_pick(const struct scheduler *ops, struct vcpu *vc, bool_t commit) { - cpumask_t cpus; + cpumask_t cpus, start_cpus; cpumask_t idlers; cpumask_t *online; + struct csched_dom *sdom = CSCHED_DOM(vc->domain); struct csched_pcpu *spc = NULL; int cpu; /* - * Pick from online CPUs in VCPU's affinity mask, giving a - * preference to its current processor if it's in there. + * Pick an online CPU from the && of vcpu-affinity and node-affinity + * masks (if not empty, in which case only the vcpu-affinity mask is + * used). Also, try to give a preference to its current processor if + * it's in there. */ online = cpupool_scheduler_cpumask(vc->domain->cpupool); cpumask_and(&cpus, online, vc->cpu_affinity); - cpu = cpumask_test_cpu(vc->processor, &cpus) + cpumask_and(&start_cpus, &cpus, sdom->node_affinity_cpumask); + if ( unlikely(cpumask_empty(&start_cpus)) ) + cpumask_copy(&start_cpus, &cpus); + cpu = cpumask_test_cpu(vc->processor, &start_cpus) ? vc->processor - : cpumask_cycle(vc->processor, &cpus); + : cpumask_cycle(vc->processor, &start_cpus); ASSERT( !cpumask_empty(&cpus) && cpumask_test_cpu(cpu, &cpus) ); /* @@ -867,6 +935,13 @@ csched_alloc_domdata(const struct schedu if ( sdom == NULL ) return NULL; + if ( !alloc_cpumask_var(&sdom->node_affinity_cpumask) ) + { + xfree(sdom); + return NULL; + } + cpumask_setall(sdom->node_affinity_cpumask); + /* Initialize credit and weight */ INIT_LIST_HEAD(&sdom->active_vcpu); sdom->active_vcpu_count = 0; @@ -900,6 +975,9 @@ csched_dom_init(const struct scheduler * static void csched_free_domdata(const struct scheduler *ops, void *data) { + struct csched_dom *sdom = data; + + free_cpumask_var(sdom->node_affinity_cpumask); xfree(data); } @@ -1211,30 +1289,48 @@ csched_runq_steal(int peer_cpu, int cpu, */ if ( peer_pcpu != NULL && !is_idle_vcpu(peer_vcpu) ) { - list_for_each( iter, &peer_pcpu->runq ) + int balance_step; + + /* + * Take node-affinity into account. That means, for all the vcpus + * in peer_pcpu's runq, check _first_ if their node-affinity allows + * them to run on cpu. If not, retry the loop considering plain + * vcpu-affinity. Also, notice that as soon as one vcpu is found, + * balancing is considered done, and the vcpu is returned to the + * caller. + */ + for_each_csched_balance_step(balance_step) { - speer = __runq_elem(iter); + list_for_each( iter, &peer_pcpu->runq ) + { + cpumask_t balance_mask; - /* - * If next available VCPU here is not of strictly higher - * priority than ours, this PCPU is useless to us. - */ - if ( speer->pri <= pri ) - break; + speer = __runq_elem(iter); - /* Is this VCPU is runnable on our PCPU? */ - vc = speer->vcpu; - BUG_ON( is_idle_vcpu(vc) ); + /* + * If next available VCPU here is not of strictly higher + * priority than ours, this PCPU is useless to us. + */ + if ( speer->pri <= pri ) + break; - if (__csched_vcpu_is_migrateable(vc, cpu)) - { - /* We got a candidate. Grab it! */ - CSCHED_VCPU_STAT_CRANK(speer, migrate_q); - CSCHED_STAT_CRANK(migrate_queued); - WARN_ON(vc->is_urgent); - __runq_remove(speer); - vc->processor = cpu; - return speer; + /* Is this VCPU runnable on our PCPU? */ + vc = speer->vcpu; + BUG_ON( is_idle_vcpu(vc) ); + + if ( csched_balance_cpumask(vc, balance_step, &balance_mask) ) + continue; + + if (__csched_vcpu_is_migrateable(vc, cpu, &balance_mask)) + { + /* We got a candidate. Grab it! */ + CSCHED_VCPU_STAT_CRANK(speer, migrate_q); + CSCHED_STAT_CRANK(migrate_queued); + WARN_ON(vc->is_urgent); + __runq_remove(speer); + vc->processor = cpu; + return speer; + } } } } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:14:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:14:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8fk-0000UY-Gd; Fri, 05 Oct 2012 14:14:36 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8fj-0000OJ-E9 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:14:35 +0000 X-Env-Sender: raistlin.df@gmail.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1349446459!8892605!2 X-Originating-IP: [209.85.212.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29507 invoked from network); 5 Oct 2012 14:14:28 -0000 Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com) (209.85.212.173) by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:14:28 -0000 Received: by mail-wi0-f173.google.com with SMTP id hm4so597845wib.14 for ; Fri, 05 Oct 2012 07:14:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:content-transfer-encoding:subject :x-mercurial-node:message-id:in-reply-to:references:user-agent:date :from:to:cc; bh=NmPrq5K70biRHsIvaVRoxYTUmsVHgr9QQjuJe4FhPV8=; b=xQd9kXpk4vSRSYrg4t37+HslgmYSULkaRMwOfwhJ4btIwvO4OwSHiOPEtFp89AVOYD D7oMIYOOcx1X9W4mznh3mT3XTxh/ZGf03ibRZdasXyYEq2zKDVnCNXzOx5nBoBNbKfYz bIHnr9U5DtVyphGMFrRyFpJmCAecmLxf6TqVmxMVHSMLGrIMKt/CRW4mE1E75QRSVGdO kt59JGOvyDl6NB4mhg/Ynr5hKcBChF2bKElJCfsNEvrlXDGGZtMbi+b7Y/4TBuhZqL/D j9HvhesE2wKIEmK9Yx31PYe/n/N+g2hpLc80h6tlp5Lr3zA0F2XpEUCsQQwZNwA4By+B OECA== Received: by 10.180.76.69 with SMTP id i5mr3717258wiw.9.1349446467964; Fri, 05 Oct 2012 07:14:27 -0700 (PDT) Received: from [127.0.1.1] (ip-170-24.sn3.eutelia.it. [213.136.170.24]) by mx.google.com with ESMTPS id fb20sm2909341wid.1.2012.10.05.07.14.25 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Oct 2012 07:14:27 -0700 (PDT) MIME-Version: 1.0 X-Mercurial-Node: 7fba2d9044e720770c25d4089cd92fe2373d2277 Message-Id: <7fba2d9044e720770c25.1349446106@Solace> In-Reply-To: References: User-Agent: Mercurial-patchbomb/2.2.2 Date: Fri, 05 Oct 2012 16:08:26 +0200 From: Dario Faggioli To: xen-devel@lists.xen.org Cc: Andre Przywara , Ian Campbell , Anil Madhavapeddy , George Dunlap , Andrew Cooper , Juergen Gross , Ian Jackson , Jan Beulich , Marcus Granado , Daniel De Graaf , Matt Wilson Subject: [Xen-devel] [PATCH 8 of 8] xl: add node-affinity to the output of `xl list` X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Node-affinity is now something that is under (some) control of the user, so show it upon request as part of the output of `xl list'. Signed-off-by: Dario Faggioli diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c --- a/tools/libxl/xl_cmdimpl.c +++ b/tools/libxl/xl_cmdimpl.c @@ -2834,14 +2834,82 @@ out: } } -static void list_domains(int verbose, int context, const libxl_dominfo *info, int nb_domain) +static void print_bitmap(uint8_t *map, int maplen, FILE *stream, int cpu_node) +{ + int i; + uint8_t pmap = 0, bitmask = 0; + int firstset = 0, state = 0; + + for (i = 0; i < maplen; i++) { + if (i % 8 == 0) { + pmap = *map++; + bitmask = 1; + } else bitmask <<= 1; + + switch (state) { + case 0: + case 2: + if ((pmap & bitmask) != 0) { + firstset = i; + state++; + } + continue; + case 1: + case 3: + if ((pmap & bitmask) == 0) { + fprintf(stream, "%s%d", state > 1 ? "," : "", firstset); + if (i - 1 > firstset) + fprintf(stream, "-%d", i - 1); + state = 2; + } + continue; + } + } + switch (state) { + case 0: + fprintf(stream, "none"); + break; + case 2: + break; + case 1: + if (firstset == 0) { + fprintf(stream, cpu_node ? "any cpu" : "any node"); + break; + } + case 3: + fprintf(stream, "%s%d", state > 1 ? "," : "", firstset); + if (i - 1 > firstset) + fprintf(stream, "-%d", i - 1); + break; + } +} + +static void list_domains(int verbose, int context, int numa, const libxl_dominfo *info, int nb_domain) { int i; static const char shutdown_reason_letters[]= "-rscw"; + libxl_bitmap nodemap; + libxl_physinfo physinfo; + + libxl_bitmap_init(&nodemap); + libxl_physinfo_init(&physinfo); printf("Name ID Mem VCPUs\tState\tTime(s)"); if (verbose) printf(" UUID Reason-Code\tSecurity Label"); if (context && !verbose) printf(" Security Label"); + if (numa) { + if (libxl_node_bitmap_alloc(ctx, &nodemap, 0)) { + fprintf(stderr, "libxl_node_bitmap_alloc_failed.\n"); + exit(1); + } + if (libxl_get_physinfo(ctx, &physinfo) != 0) { + fprintf(stderr, "libxl_physinfo failed.\n"); + libxl_bitmap_dispose(&nodemap); + exit(1); + } + + printf(" NODE Affinity"); + } printf("\n"); for (i = 0; i < nb_domain; i++) { char *domname; @@ -2875,14 +2943,23 @@ static void list_domains(int verbose, in rc = libxl_flask_sid_to_context(ctx, info[i].ssidref, &buf, &size); if (rc < 0) - printf(" -"); + printf(" -"); else { - printf(" %s", buf); + printf(" %16s", buf); free(buf); } } + if (numa) { + libxl_domain_get_nodeaffinity(ctx, info[i].domid, &nodemap); + + putchar(' '); + print_bitmap(nodemap.map, physinfo.nr_nodes, stdout, 0); + } putchar('\n'); } + + libxl_bitmap_dispose(&nodemap); + libxl_physinfo_dispose(&physinfo); } static void list_vm(void) @@ -3724,12 +3801,14 @@ int main_list(int argc, char **argv) int opt, verbose = 0; int context = 0; int details = 0; + int numa = 0; int option_index = 0; static struct option long_options[] = { {"long", 0, 0, 'l'}, {"help", 0, 0, 'h'}, {"verbose", 0, 0, 'v'}, {"context", 0, 0, 'Z'}, + {"numa", 0, 0, 'n'}, {0, 0, 0, 0} }; @@ -3738,7 +3817,7 @@ int main_list(int argc, char **argv) int nb_domain, rc; while (1) { - opt = getopt_long(argc, argv, "lvhZ", long_options, &option_index); + opt = getopt_long(argc, argv, "lvhZn", long_options, &option_index); if (opt == -1) break; @@ -3755,6 +3834,9 @@ int main_list(int argc, char **argv) case 'Z': context = 1; break; + case 'n': + numa = 1; + break; default: fprintf(stderr, "option `%c' not supported.\n", optopt); break; @@ -3790,7 +3872,7 @@ int main_list(int argc, char **argv) if (details) list_domains_details(info, nb_domain); else - list_domains(verbose, context, info, nb_domain); + list_domains(verbose, context, numa, info, nb_domain); if (info_free) libxl_dominfo_list_free(info, nb_domain); @@ -4062,56 +4144,6 @@ int main_button_press(int argc, char **a return 0; } -static void print_bitmap(uint8_t *map, int maplen, FILE *stream) -{ - int i; - uint8_t pmap = 0, bitmask = 0; - int firstset = 0, state = 0; - - for (i = 0; i < maplen; i++) { - if (i % 8 == 0) { - pmap = *map++; - bitmask = 1; - } else bitmask <<= 1; - - switch (state) { - case 0: - case 2: - if ((pmap & bitmask) != 0) { - firstset = i; - state++; - } - continue; - case 1: - case 3: - if ((pmap & bitmask) == 0) { - fprintf(stream, "%s%d", state > 1 ? "," : "", firstset); - if (i - 1 > firstset) - fprintf(stream, "-%d", i - 1); - state = 2; - } - continue; - } - } - switch (state) { - case 0: - fprintf(stream, "none"); - break; - case 2: - break; - case 1: - if (firstset == 0) { - fprintf(stream, "any cpu"); - break; - } - case 3: - fprintf(stream, "%s%d", state > 1 ? "," : "", firstset); - if (i - 1 > firstset) - fprintf(stream, "-%d", i - 1); - break; - } -} - static void print_vcpuinfo(uint32_t tdomid, const libxl_vcpuinfo *vcpuinfo, uint32_t nr_cpus) @@ -4135,7 +4167,7 @@ static void print_vcpuinfo(uint32_t tdom /* TIM */ printf("%9.1f ", ((float)vcpuinfo->vcpu_time / 1e9)); /* CPU AFFINITY */ - print_bitmap(vcpuinfo->cpumap.map, nr_cpus, stdout); + print_bitmap(vcpuinfo->cpumap.map, nr_cpus, stdout, 1); printf("\n"); } diff --git a/tools/libxl/xl_cmdtable.c b/tools/libxl/xl_cmdtable.c --- a/tools/libxl/xl_cmdtable.c +++ b/tools/libxl/xl_cmdtable.c @@ -50,7 +50,8 @@ struct cmd_spec cmd_table[] = { "[options] [Domain]\n", "-l, --long Output all VM details\n" "-v, --verbose Prints out UUIDs and security context\n" - "-Z, --context Prints out security context" + "-Z, --context Prints out security context\n" + "-n, --numa Prints out NUMA node affinity" }, { "destroy", &main_destroy, 0, 1, _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:14:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:14:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8fk-0000UY-Gd; Fri, 05 Oct 2012 14:14:36 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8fj-0000OJ-E9 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:14:35 +0000 X-Env-Sender: raistlin.df@gmail.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1349446459!8892605!2 X-Originating-IP: [209.85.212.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29507 invoked from network); 5 Oct 2012 14:14:28 -0000 Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com) (209.85.212.173) by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:14:28 -0000 Received: by mail-wi0-f173.google.com with SMTP id hm4so597845wib.14 for ; Fri, 05 Oct 2012 07:14:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:content-transfer-encoding:subject :x-mercurial-node:message-id:in-reply-to:references:user-agent:date :from:to:cc; bh=NmPrq5K70biRHsIvaVRoxYTUmsVHgr9QQjuJe4FhPV8=; b=xQd9kXpk4vSRSYrg4t37+HslgmYSULkaRMwOfwhJ4btIwvO4OwSHiOPEtFp89AVOYD D7oMIYOOcx1X9W4mznh3mT3XTxh/ZGf03ibRZdasXyYEq2zKDVnCNXzOx5nBoBNbKfYz bIHnr9U5DtVyphGMFrRyFpJmCAecmLxf6TqVmxMVHSMLGrIMKt/CRW4mE1E75QRSVGdO kt59JGOvyDl6NB4mhg/Ynr5hKcBChF2bKElJCfsNEvrlXDGGZtMbi+b7Y/4TBuhZqL/D j9HvhesE2wKIEmK9Yx31PYe/n/N+g2hpLc80h6tlp5Lr3zA0F2XpEUCsQQwZNwA4By+B OECA== Received: by 10.180.76.69 with SMTP id i5mr3717258wiw.9.1349446467964; Fri, 05 Oct 2012 07:14:27 -0700 (PDT) Received: from [127.0.1.1] (ip-170-24.sn3.eutelia.it. [213.136.170.24]) by mx.google.com with ESMTPS id fb20sm2909341wid.1.2012.10.05.07.14.25 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Oct 2012 07:14:27 -0700 (PDT) MIME-Version: 1.0 X-Mercurial-Node: 7fba2d9044e720770c25d4089cd92fe2373d2277 Message-Id: <7fba2d9044e720770c25.1349446106@Solace> In-Reply-To: References: User-Agent: Mercurial-patchbomb/2.2.2 Date: Fri, 05 Oct 2012 16:08:26 +0200 From: Dario Faggioli To: xen-devel@lists.xen.org Cc: Andre Przywara , Ian Campbell , Anil Madhavapeddy , George Dunlap , Andrew Cooper , Juergen Gross , Ian Jackson , Jan Beulich , Marcus Granado , Daniel De Graaf , Matt Wilson Subject: [Xen-devel] [PATCH 8 of 8] xl: add node-affinity to the output of `xl list` X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Node-affinity is now something that is under (some) control of the user, so show it upon request as part of the output of `xl list'. Signed-off-by: Dario Faggioli diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c --- a/tools/libxl/xl_cmdimpl.c +++ b/tools/libxl/xl_cmdimpl.c @@ -2834,14 +2834,82 @@ out: } } -static void list_domains(int verbose, int context, const libxl_dominfo *info, int nb_domain) +static void print_bitmap(uint8_t *map, int maplen, FILE *stream, int cpu_node) +{ + int i; + uint8_t pmap = 0, bitmask = 0; + int firstset = 0, state = 0; + + for (i = 0; i < maplen; i++) { + if (i % 8 == 0) { + pmap = *map++; + bitmask = 1; + } else bitmask <<= 1; + + switch (state) { + case 0: + case 2: + if ((pmap & bitmask) != 0) { + firstset = i; + state++; + } + continue; + case 1: + case 3: + if ((pmap & bitmask) == 0) { + fprintf(stream, "%s%d", state > 1 ? "," : "", firstset); + if (i - 1 > firstset) + fprintf(stream, "-%d", i - 1); + state = 2; + } + continue; + } + } + switch (state) { + case 0: + fprintf(stream, "none"); + break; + case 2: + break; + case 1: + if (firstset == 0) { + fprintf(stream, cpu_node ? "any cpu" : "any node"); + break; + } + case 3: + fprintf(stream, "%s%d", state > 1 ? "," : "", firstset); + if (i - 1 > firstset) + fprintf(stream, "-%d", i - 1); + break; + } +} + +static void list_domains(int verbose, int context, int numa, const libxl_dominfo *info, int nb_domain) { int i; static const char shutdown_reason_letters[]= "-rscw"; + libxl_bitmap nodemap; + libxl_physinfo physinfo; + + libxl_bitmap_init(&nodemap); + libxl_physinfo_init(&physinfo); printf("Name ID Mem VCPUs\tState\tTime(s)"); if (verbose) printf(" UUID Reason-Code\tSecurity Label"); if (context && !verbose) printf(" Security Label"); + if (numa) { + if (libxl_node_bitmap_alloc(ctx, &nodemap, 0)) { + fprintf(stderr, "libxl_node_bitmap_alloc_failed.\n"); + exit(1); + } + if (libxl_get_physinfo(ctx, &physinfo) != 0) { + fprintf(stderr, "libxl_physinfo failed.\n"); + libxl_bitmap_dispose(&nodemap); + exit(1); + } + + printf(" NODE Affinity"); + } printf("\n"); for (i = 0; i < nb_domain; i++) { char *domname; @@ -2875,14 +2943,23 @@ static void list_domains(int verbose, in rc = libxl_flask_sid_to_context(ctx, info[i].ssidref, &buf, &size); if (rc < 0) - printf(" -"); + printf(" -"); else { - printf(" %s", buf); + printf(" %16s", buf); free(buf); } } + if (numa) { + libxl_domain_get_nodeaffinity(ctx, info[i].domid, &nodemap); + + putchar(' '); + print_bitmap(nodemap.map, physinfo.nr_nodes, stdout, 0); + } putchar('\n'); } + + libxl_bitmap_dispose(&nodemap); + libxl_physinfo_dispose(&physinfo); } static void list_vm(void) @@ -3724,12 +3801,14 @@ int main_list(int argc, char **argv) int opt, verbose = 0; int context = 0; int details = 0; + int numa = 0; int option_index = 0; static struct option long_options[] = { {"long", 0, 0, 'l'}, {"help", 0, 0, 'h'}, {"verbose", 0, 0, 'v'}, {"context", 0, 0, 'Z'}, + {"numa", 0, 0, 'n'}, {0, 0, 0, 0} }; @@ -3738,7 +3817,7 @@ int main_list(int argc, char **argv) int nb_domain, rc; while (1) { - opt = getopt_long(argc, argv, "lvhZ", long_options, &option_index); + opt = getopt_long(argc, argv, "lvhZn", long_options, &option_index); if (opt == -1) break; @@ -3755,6 +3834,9 @@ int main_list(int argc, char **argv) case 'Z': context = 1; break; + case 'n': + numa = 1; + break; default: fprintf(stderr, "option `%c' not supported.\n", optopt); break; @@ -3790,7 +3872,7 @@ int main_list(int argc, char **argv) if (details) list_domains_details(info, nb_domain); else - list_domains(verbose, context, info, nb_domain); + list_domains(verbose, context, numa, info, nb_domain); if (info_free) libxl_dominfo_list_free(info, nb_domain); @@ -4062,56 +4144,6 @@ int main_button_press(int argc, char **a return 0; } -static void print_bitmap(uint8_t *map, int maplen, FILE *stream) -{ - int i; - uint8_t pmap = 0, bitmask = 0; - int firstset = 0, state = 0; - - for (i = 0; i < maplen; i++) { - if (i % 8 == 0) { - pmap = *map++; - bitmask = 1; - } else bitmask <<= 1; - - switch (state) { - case 0: - case 2: - if ((pmap & bitmask) != 0) { - firstset = i; - state++; - } - continue; - case 1: - case 3: - if ((pmap & bitmask) == 0) { - fprintf(stream, "%s%d", state > 1 ? "," : "", firstset); - if (i - 1 > firstset) - fprintf(stream, "-%d", i - 1); - state = 2; - } - continue; - } - } - switch (state) { - case 0: - fprintf(stream, "none"); - break; - case 2: - break; - case 1: - if (firstset == 0) { - fprintf(stream, "any cpu"); - break; - } - case 3: - fprintf(stream, "%s%d", state > 1 ? "," : "", firstset); - if (i - 1 > firstset) - fprintf(stream, "-%d", i - 1); - break; - } -} - static void print_vcpuinfo(uint32_t tdomid, const libxl_vcpuinfo *vcpuinfo, uint32_t nr_cpus) @@ -4135,7 +4167,7 @@ static void print_vcpuinfo(uint32_t tdom /* TIM */ printf("%9.1f ", ((float)vcpuinfo->vcpu_time / 1e9)); /* CPU AFFINITY */ - print_bitmap(vcpuinfo->cpumap.map, nr_cpus, stdout); + print_bitmap(vcpuinfo->cpumap.map, nr_cpus, stdout, 1); printf("\n"); } diff --git a/tools/libxl/xl_cmdtable.c b/tools/libxl/xl_cmdtable.c --- a/tools/libxl/xl_cmdtable.c +++ b/tools/libxl/xl_cmdtable.c @@ -50,7 +50,8 @@ struct cmd_spec cmd_table[] = { "[options] [Domain]\n", "-l, --long Output all VM details\n" "-v, --verbose Prints out UUIDs and security context\n" - "-Z, --context Prints out security context" + "-Z, --context Prints out security context\n" + "-n, --numa Prints out NUMA node affinity" }, { "destroy", &main_destroy, 0, 1, _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:15:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:15:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8gh-00011b-64; Fri, 05 Oct 2012 14:15:35 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8gf-00010e-12 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:15:33 +0000 Received: from [85.158.138.51:18129] by server-3.bemta-3.messagelabs.com id 6E/E7-25962-48BEE605; Fri, 05 Oct 2012 14:15:32 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1349446531!32744198!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16735 invoked from network); 5 Oct 2012 14:15:31 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:15:31 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14965847" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 14:14:59 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 15:14:59 +0100 Date: Fri, 5 Oct 2012 15:13:57 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Jan Beulich In-Reply-To: <506ED9E2020000780009FE5A@nat28.tlf.novell.com> Message-ID: References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> <1349433507-21148-17-git-send-email-ian.campbell@citrix.com> <506ED9E2020000780009FE5A@nat28.tlf.novell.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: "Keir \(Xen.org\)" , Ian Campbell , Stefano Stabellini , "Tim \(Xen.org\)" , "xen-devel@lists.xen.org" , "stefano.stabelini@citrix.com" Subject: Re: [Xen-devel] [PATCH 17/21] xen: xen_ulong_t substitution X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 5 Oct 2012, Jan Beulich wrote: > >>> On 05.10.12 at 12:38, Ian Campbell wrote: > > --- a/tools/python/xen/lowlevel/xc/xc.c > > +++ b/tools/python/xen/lowlevel/xc/xc.c > > @@ -1439,7 +1439,7 @@ static PyObject *pyxc_xeninfo(XcObject *self) > > if ( xc_version(self->xc_handle, XENVER_commandline, &xen_commandline) != 0 ) > > return pyxc_error_to_exception(self->xc_handle); > > > > - snprintf(str, sizeof(str), "virt_start=0x%lx", p_parms.virt_start); > > + snprintf(str, sizeof(str), "virt_start=0x%"PRI_xen_ulong, p_parms.virt_start); > > Does that build on x86? I ask because ... > > > > > xen_pagesize = xc_version(self->xc_handle, XENVER_pagesize, NULL); > > if (xen_pagesize < 0 ) > > diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h > > index e3d4ad9..2ae6548 100644 > > --- a/xen/include/public/arch-arm.h > > +++ b/xen/include/public/arch-arm.h > > @@ -122,7 +122,8 @@ typedef uint64_t xen_pfn_t; > > /* Only one. All other VCPUS must use VCPUOP_register_vcpu_info */ > > #define XEN_LEGACY_MAX_VCPUS 1 > > > > -typedef uint32_t xen_ulong_t; > > +typedef uint64_t xen_ulong_t; > > +#define PRI_xen_ulong PRIx64 > > ... this doesn't seem to have an x86 counterpart. > xen/include/public/arch-x86/xen.h defines xen_ulong_t but it looks like that it is missing PRI_xen_ulong > > > > > struct vcpu_guest_context { > > #define _VGCF_online 0 > > diff --git a/xen/include/public/version.h b/xen/include/public/version.h > > index 8742c2b..c7e6f8c 100644 > > --- a/xen/include/public/version.h > > +++ b/xen/include/public/version.h > > @@ -28,6 +28,8 @@ > > #ifndef __XEN_PUBLIC_VERSION_H__ > > #define __XEN_PUBLIC_VERSION_H__ > > > > +#include "xen.h" > > + > > /* NB. All ops return zero on success, except XENVER_{version,pagesize} */ > > > > /* arg == NULL; returns major:minor (16:16). */ > > @@ -58,7 +60,7 @@ typedef char xen_changeset_info_t[64]; > > > > #define XENVER_platform_parameters 5 > > struct xen_platform_parameters { > > - unsigned long virt_start; > > + xen_ulong_t virt_start; > > }; > > typedef struct xen_platform_parameters xen_platform_parameters_t; > > > > -- > > 1.7.9.1 > > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:15:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:15:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8gh-00011b-64; Fri, 05 Oct 2012 14:15:35 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8gf-00010e-12 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:15:33 +0000 Received: from [85.158.138.51:18129] by server-3.bemta-3.messagelabs.com id 6E/E7-25962-48BEE605; Fri, 05 Oct 2012 14:15:32 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1349446531!32744198!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16735 invoked from network); 5 Oct 2012 14:15:31 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:15:31 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14965847" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 14:14:59 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 15:14:59 +0100 Date: Fri, 5 Oct 2012 15:13:57 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Jan Beulich In-Reply-To: <506ED9E2020000780009FE5A@nat28.tlf.novell.com> Message-ID: References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> <1349433507-21148-17-git-send-email-ian.campbell@citrix.com> <506ED9E2020000780009FE5A@nat28.tlf.novell.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: "Keir \(Xen.org\)" , Ian Campbell , Stefano Stabellini , "Tim \(Xen.org\)" , "xen-devel@lists.xen.org" , "stefano.stabelini@citrix.com" Subject: Re: [Xen-devel] [PATCH 17/21] xen: xen_ulong_t substitution X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 5 Oct 2012, Jan Beulich wrote: > >>> On 05.10.12 at 12:38, Ian Campbell wrote: > > --- a/tools/python/xen/lowlevel/xc/xc.c > > +++ b/tools/python/xen/lowlevel/xc/xc.c > > @@ -1439,7 +1439,7 @@ static PyObject *pyxc_xeninfo(XcObject *self) > > if ( xc_version(self->xc_handle, XENVER_commandline, &xen_commandline) != 0 ) > > return pyxc_error_to_exception(self->xc_handle); > > > > - snprintf(str, sizeof(str), "virt_start=0x%lx", p_parms.virt_start); > > + snprintf(str, sizeof(str), "virt_start=0x%"PRI_xen_ulong, p_parms.virt_start); > > Does that build on x86? I ask because ... > > > > > xen_pagesize = xc_version(self->xc_handle, XENVER_pagesize, NULL); > > if (xen_pagesize < 0 ) > > diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h > > index e3d4ad9..2ae6548 100644 > > --- a/xen/include/public/arch-arm.h > > +++ b/xen/include/public/arch-arm.h > > @@ -122,7 +122,8 @@ typedef uint64_t xen_pfn_t; > > /* Only one. All other VCPUS must use VCPUOP_register_vcpu_info */ > > #define XEN_LEGACY_MAX_VCPUS 1 > > > > -typedef uint32_t xen_ulong_t; > > +typedef uint64_t xen_ulong_t; > > +#define PRI_xen_ulong PRIx64 > > ... this doesn't seem to have an x86 counterpart. > xen/include/public/arch-x86/xen.h defines xen_ulong_t but it looks like that it is missing PRI_xen_ulong > > > > > struct vcpu_guest_context { > > #define _VGCF_online 0 > > diff --git a/xen/include/public/version.h b/xen/include/public/version.h > > index 8742c2b..c7e6f8c 100644 > > --- a/xen/include/public/version.h > > +++ b/xen/include/public/version.h > > @@ -28,6 +28,8 @@ > > #ifndef __XEN_PUBLIC_VERSION_H__ > > #define __XEN_PUBLIC_VERSION_H__ > > > > +#include "xen.h" > > + > > /* NB. All ops return zero on success, except XENVER_{version,pagesize} */ > > > > /* arg == NULL; returns major:minor (16:16). */ > > @@ -58,7 +60,7 @@ typedef char xen_changeset_info_t[64]; > > > > #define XENVER_platform_parameters 5 > > struct xen_platform_parameters { > > - unsigned long virt_start; > > + xen_ulong_t virt_start; > > }; > > typedef struct xen_platform_parameters xen_platform_parameters_t; > > > > -- > > 1.7.9.1 > > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:16:59 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:16:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8hv-0001RA-MX; Fri, 05 Oct 2012 14:16:51 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8hu-0001Qb-9Z for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:16:50 +0000 Received: from [85.158.139.211:12464] by server-5.bemta-5.messagelabs.com id E1/4B-21075-1DBEE605; Fri, 05 Oct 2012 14:16:49 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-6.tower-206.messagelabs.com!1349446607!21229568!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15937 invoked from network); 5 Oct 2012 14:16:48 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:16:48 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14965928" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 14:16:47 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 15:16:47 +0100 Date: Fri, 5 Oct 2012 15:15:45 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Jan Beulich In-Reply-To: <506EDB53020000780009FE90@nat28.tlf.novell.com> Message-ID: References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> <1349433507-21148-20-git-send-email-ian.campbell@citrix.com> <506EDB53020000780009FE90@nat28.tlf.novell.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: "Keir \(Xen.org\)" , Ian Campbell , Stefano Stabellini , "Tim \(Xen.org\)" , "xen-devel@lists.xen.org" , "stefano.stabelini@citrix.com" Subject: Re: [Xen-devel] [PATCH 20/21] xen: replace XEN_GUEST_HANDLE with XEN_GUEST_HANDLE_PARAM when appropriate X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 5 Oct 2012, Jan Beulich wrote: > >>> On 05.10.12 at 12:38, Ian Campbell wrote: > > From: Stefano Stabellini > > > > Note: these changes don't make any difference on x86 and ia64. > > ia64? > it was still around when I started working on the patch _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:16:59 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:16:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8hv-0001RA-MX; Fri, 05 Oct 2012 14:16:51 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8hu-0001Qb-9Z for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:16:50 +0000 Received: from [85.158.139.211:12464] by server-5.bemta-5.messagelabs.com id E1/4B-21075-1DBEE605; Fri, 05 Oct 2012 14:16:49 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-6.tower-206.messagelabs.com!1349446607!21229568!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15937 invoked from network); 5 Oct 2012 14:16:48 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:16:48 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14965928" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 14:16:47 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 15:16:47 +0100 Date: Fri, 5 Oct 2012 15:15:45 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Jan Beulich In-Reply-To: <506EDB53020000780009FE90@nat28.tlf.novell.com> Message-ID: References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> <1349433507-21148-20-git-send-email-ian.campbell@citrix.com> <506EDB53020000780009FE90@nat28.tlf.novell.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: "Keir \(Xen.org\)" , Ian Campbell , Stefano Stabellini , "Tim \(Xen.org\)" , "xen-devel@lists.xen.org" , "stefano.stabelini@citrix.com" Subject: Re: [Xen-devel] [PATCH 20/21] xen: replace XEN_GUEST_HANDLE with XEN_GUEST_HANDLE_PARAM when appropriate X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 5 Oct 2012, Jan Beulich wrote: > >>> On 05.10.12 at 12:38, Ian Campbell wrote: > > From: Stefano Stabellini > > > > Note: these changes don't make any difference on x86 and ia64. > > ia64? > it was still around when I started working on the patch _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:25:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:25:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8qH-0002AJ-O6; Fri, 05 Oct 2012 14:25:29 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8qG-0002AE-Hm for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:25:28 +0000 Received: from [85.158.143.35:14806] by server-3.bemta-4.messagelabs.com id BC/CA-10986-7DDEE605; Fri, 05 Oct 2012 14:25:27 +0000 X-Env-Sender: andreslc@gridcentric.ca X-Msg-Ref: server-15.tower-21.messagelabs.com!1349447121!13857627!1 X-Originating-IP: [209.85.223.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4745 invoked from network); 5 Oct 2012 14:25:26 -0000 Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com) (209.85.223.173) by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:25:26 -0000 Received: by mail-ie0-f173.google.com with SMTP id 17so5010837iea.32 for ; Fri, 05 Oct 2012 07:25:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:x-priority:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=/TjvSLfcB5zLgImW9frRVTPupLoy27pKraAFyV/GnJE=; b=jQFxI99hkKefWdxDAt++s3QtD6rraUNaNvZ6wq1MHUAVf3RIbRz0ciQyakoC1k6nTJ 2pVAO0QcgdkhdU+V1zNMTAjZ54FtVEhfMLy/DldQcDSeXHL/+mXpQcc/HV6YSA5ufB0r tK6UI/Y6ufZi9GQgmFAFjUZMexKelqGKqeuBOSNE3YTp0PHrFljg7XiuY8IAS5pteV1x g6Z5+q8Dsij4kZiwVZ3qTFqVd0LEaWvgBOe5Jt20h0RARC5bmzuxyMc9NSAE54bfy75Q ZqYJKaH+CDegPg41CT+q+t9PHtW3qiLvI3AZZgnRo5NLILlO6kDppnb7CJ0M9SSlTW9U tHGw== Received: by 10.50.5.180 with SMTP id t20mr1316702igt.31.1349447121328; Fri, 05 Oct 2012 07:25:21 -0700 (PDT) Received: from [192.168.3.238] ([206.223.182.18]) by mx.google.com with ESMTPS id a10sm915288igd.1.2012.10.05.07.25.18 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Oct 2012 07:25:19 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) From: Andres Lagar-Cavilla X-Priority: 3 In-Reply-To: <52e8fc33-59b3-4d28-82a7-b648e3e28cf5@default> Date: Fri, 5 Oct 2012 10:25:15 -0400 Message-Id: <78F5EF0B-15B6-4907-AE01-88CC42D052F0@gridcentric.ca> References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> <20121002091017.GA95926@ocelot.phlegethon.org> <66cc0085-1216-40f7-8059-eaf615202c12@default> <20121002201624.GA98445@ocelot.phlegethon.org> <20121004100645.GC38243@ocelot.phlegethon.org> <51CA094C-870A-4772-A22E-4CB151E854F2@gridcentric.ca> <48a08581-faa9-40a0-8afd-dc334ab82e43@default> <91C20B33-83CF-4B7A-A5AC-E61421B00536@gridcentric.ca> <16aa5326-5fd9-4f9c-b0fe-6196c6379991@default> <1C4CD35F-94F0-44CF-97EA-137DF20E9669@gridcentric.ca> <52e8fc33-59b3-4d28-82a7-b648e3e28cf5@default> To: Dan Magenheimer X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQl+IfgoYUf5qlo18obRm1WAGbE2H4MBFsHPiQHP0u/O6TtRBQu1VKFFSBRJ+P2e1qjqZUM9 Cc: Olaf Hering , Keir Fraser , Konrad Wilk , George Dunlap , Kurt Hackel , Tim Deegan , xen-devel@lists.xen.org, George Shuklin , Dario Faggioli , Ian Jackson Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Oct 4, 2012, at 1:55 PM, Dan Magenheimer wrote: >> From: Andres Lagar-Cavilla [mailto:andreslc@gridcentric.ca] >> Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) >> >> >> On Oct 4, 2012, at 1:18 PM, Dan Magenheimer wrote: >> >>>> From: Andres Lagar-Cavilla [mailto:andreslc@gridcentric.ca] >>>> Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) >>>> >>>> >>>> On Oct 4, 2012, at 12:59 PM, Dan Magenheimer wrote: >>>> >>> OK. I _think_ the design I proposed helps in systems that are using >>> page-sharing/host-swapping as well... I assume share-breaking just >>> calls the normal hypervisor allocator interface to allocate a >>> new page (if available)? If you could review and comment on >>> the design from a page-sharing/host-swapping perspective, I would >>> appreciate it. >> >> I think you will need to refine your notion of reservation. If you have nominal RAM N, and current RAM >> C, N >= C, it makes no sense to reserve N so the VM later has room to occupy by swapping-in, unsharing >> or whatever -- then you are not over-committing memory. >> >> To the extent that you want to facilitate VM creation, it does make sense to reserve C and guarantee >> that. >> >> Then it gets mm-specific. PoD has one way of dealing with the allocation growth. xenpaging tries to >> stick to the watermark -- if something swaps in something else swaps out. And uncooperative balloons >> are be stymied by xapi using d->max_pages. >> >> This is why I believe you need to solve the problem of initial reservation, and the problem of handing >> off to the right actor. And then xl need not care any further. >> >> Andres > > I think we may be saying the same thing, at least in the context > of the issue I am trying to solve (which, admittedly, may be > a smaller part of a bigger issue, and we should attempt to ensure > that the solution to the smaller part is at least a step in the > right direction for the bigger issue). And I am trying to > solve the mechanism problem only, not the policy which, I agree is > mm-specific. > > The core problem, as I see it, is that there are multiple consumers of > memory, some of which may be visible to xl and some of which are > not. Ultimately, the hypervisor is asked to provide memory > and will return failure if it can't, so the hypervisor is the > final arbiter. > > When a domain is created, we'd like to ensure there is enough memory > for it to "not fail". But when the toolstack asks for memory to > create a domain, it asks for it "piecemeal". I'll assume that > the toolstack knows how much memory it needs to allocate to ensure > the launch doesn't fail... my solution is that it asks for that > entire amount of memory at once as a "reservation". If the > hypervisor has that much memory available, it returns success and > must behave as if the memory has been already allocated. Then, > later, when the toolstack is happy that the domain did successfully > launch, it says "remember that reservation? any memory reserved > that has not yet been allocated, need no longer be reserved, you > can unreserve it" > > In other words, between reservation and unreserve, there is no > memory overcommit for that domain. Once the toolstack does > the unreserve, its memory is available for overcommit mechanisms. I think that will be fragile. Suppose you have a 16 GiB domain and an overcommit mechanism that allows you to start the VM with 8 GiB. Straight-forward scenario with xen-4.2 and a combination of PoD and ballooning. Suppose you have 14GiB of RAM free in the system. Why should creation of that domain fail? Andres > > Not sure if that part was clear: it's my intent that unreserve occur > soon after the domain is launched, _not_, for example, when the domain > is shut down. What I don't know is if there is a suitable point > in the launch when the toolstack knows it can do the "release"... > that may be the sticking point and may be mm-specific. > > Thanks, > Dan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:25:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:25:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8qH-0002AJ-O6; Fri, 05 Oct 2012 14:25:29 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8qG-0002AE-Hm for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:25:28 +0000 Received: from [85.158.143.35:14806] by server-3.bemta-4.messagelabs.com id BC/CA-10986-7DDEE605; Fri, 05 Oct 2012 14:25:27 +0000 X-Env-Sender: andreslc@gridcentric.ca X-Msg-Ref: server-15.tower-21.messagelabs.com!1349447121!13857627!1 X-Originating-IP: [209.85.223.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4745 invoked from network); 5 Oct 2012 14:25:26 -0000 Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com) (209.85.223.173) by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:25:26 -0000 Received: by mail-ie0-f173.google.com with SMTP id 17so5010837iea.32 for ; Fri, 05 Oct 2012 07:25:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:x-priority:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=/TjvSLfcB5zLgImW9frRVTPupLoy27pKraAFyV/GnJE=; b=jQFxI99hkKefWdxDAt++s3QtD6rraUNaNvZ6wq1MHUAVf3RIbRz0ciQyakoC1k6nTJ 2pVAO0QcgdkhdU+V1zNMTAjZ54FtVEhfMLy/DldQcDSeXHL/+mXpQcc/HV6YSA5ufB0r tK6UI/Y6ufZi9GQgmFAFjUZMexKelqGKqeuBOSNE3YTp0PHrFljg7XiuY8IAS5pteV1x g6Z5+q8Dsij4kZiwVZ3qTFqVd0LEaWvgBOe5Jt20h0RARC5bmzuxyMc9NSAE54bfy75Q ZqYJKaH+CDegPg41CT+q+t9PHtW3qiLvI3AZZgnRo5NLILlO6kDppnb7CJ0M9SSlTW9U tHGw== Received: by 10.50.5.180 with SMTP id t20mr1316702igt.31.1349447121328; Fri, 05 Oct 2012 07:25:21 -0700 (PDT) Received: from [192.168.3.238] ([206.223.182.18]) by mx.google.com with ESMTPS id a10sm915288igd.1.2012.10.05.07.25.18 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Oct 2012 07:25:19 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) From: Andres Lagar-Cavilla X-Priority: 3 In-Reply-To: <52e8fc33-59b3-4d28-82a7-b648e3e28cf5@default> Date: Fri, 5 Oct 2012 10:25:15 -0400 Message-Id: <78F5EF0B-15B6-4907-AE01-88CC42D052F0@gridcentric.ca> References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default> <20581.55931.246130.308384@mariner.uk.xensource.com> <8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default> <20121002091017.GA95926@ocelot.phlegethon.org> <66cc0085-1216-40f7-8059-eaf615202c12@default> <20121002201624.GA98445@ocelot.phlegethon.org> <20121004100645.GC38243@ocelot.phlegethon.org> <51CA094C-870A-4772-A22E-4CB151E854F2@gridcentric.ca> <48a08581-faa9-40a0-8afd-dc334ab82e43@default> <91C20B33-83CF-4B7A-A5AC-E61421B00536@gridcentric.ca> <16aa5326-5fd9-4f9c-b0fe-6196c6379991@default> <1C4CD35F-94F0-44CF-97EA-137DF20E9669@gridcentric.ca> <52e8fc33-59b3-4d28-82a7-b648e3e28cf5@default> To: Dan Magenheimer X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQl+IfgoYUf5qlo18obRm1WAGbE2H4MBFsHPiQHP0u/O6TtRBQu1VKFFSBRJ+P2e1qjqZUM9 Cc: Olaf Hering , Keir Fraser , Konrad Wilk , George Dunlap , Kurt Hackel , Tim Deegan , xen-devel@lists.xen.org, George Shuklin , Dario Faggioli , Ian Jackson Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Oct 4, 2012, at 1:55 PM, Dan Magenheimer wrote: >> From: Andres Lagar-Cavilla [mailto:andreslc@gridcentric.ca] >> Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) >> >> >> On Oct 4, 2012, at 1:18 PM, Dan Magenheimer wrote: >> >>>> From: Andres Lagar-Cavilla [mailto:andreslc@gridcentric.ca] >>>> Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl) >>>> >>>> >>>> On Oct 4, 2012, at 12:59 PM, Dan Magenheimer wrote: >>>> >>> OK. I _think_ the design I proposed helps in systems that are using >>> page-sharing/host-swapping as well... I assume share-breaking just >>> calls the normal hypervisor allocator interface to allocate a >>> new page (if available)? If you could review and comment on >>> the design from a page-sharing/host-swapping perspective, I would >>> appreciate it. >> >> I think you will need to refine your notion of reservation. If you have nominal RAM N, and current RAM >> C, N >= C, it makes no sense to reserve N so the VM later has room to occupy by swapping-in, unsharing >> or whatever -- then you are not over-committing memory. >> >> To the extent that you want to facilitate VM creation, it does make sense to reserve C and guarantee >> that. >> >> Then it gets mm-specific. PoD has one way of dealing with the allocation growth. xenpaging tries to >> stick to the watermark -- if something swaps in something else swaps out. And uncooperative balloons >> are be stymied by xapi using d->max_pages. >> >> This is why I believe you need to solve the problem of initial reservation, and the problem of handing >> off to the right actor. And then xl need not care any further. >> >> Andres > > I think we may be saying the same thing, at least in the context > of the issue I am trying to solve (which, admittedly, may be > a smaller part of a bigger issue, and we should attempt to ensure > that the solution to the smaller part is at least a step in the > right direction for the bigger issue). And I am trying to > solve the mechanism problem only, not the policy which, I agree is > mm-specific. > > The core problem, as I see it, is that there are multiple consumers of > memory, some of which may be visible to xl and some of which are > not. Ultimately, the hypervisor is asked to provide memory > and will return failure if it can't, so the hypervisor is the > final arbiter. > > When a domain is created, we'd like to ensure there is enough memory > for it to "not fail". But when the toolstack asks for memory to > create a domain, it asks for it "piecemeal". I'll assume that > the toolstack knows how much memory it needs to allocate to ensure > the launch doesn't fail... my solution is that it asks for that > entire amount of memory at once as a "reservation". If the > hypervisor has that much memory available, it returns success and > must behave as if the memory has been already allocated. Then, > later, when the toolstack is happy that the domain did successfully > launch, it says "remember that reservation? any memory reserved > that has not yet been allocated, need no longer be reserved, you > can unreserve it" > > In other words, between reservation and unreserve, there is no > memory overcommit for that domain. Once the toolstack does > the unreserve, its memory is available for overcommit mechanisms. I think that will be fragile. Suppose you have a 16 GiB domain and an overcommit mechanism that allows you to start the VM with 8 GiB. Straight-forward scenario with xen-4.2 and a combination of PoD and ballooning. Suppose you have 14GiB of RAM free in the system. Why should creation of that domain fail? Andres > > Not sure if that part was clear: it's my intent that unreserve occur > soon after the domain is launched, _not_, for example, when the domain > is shut down. What I don't know is if there is a suitable point > in the launch when the toolstack knows it can do the "release"... > that may be the sticking point and may be mm-specific. > > Thanks, > Dan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:26:14 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:26:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8qq-0002Ch-50; Fri, 05 Oct 2012 14:26:04 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8qo-0002CP-84 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:26:02 +0000 Received: from [85.158.139.211:22992] by server-15.bemta-5.messagelabs.com id 2B/5F-06905-9FDEE605; Fri, 05 Oct 2012 14:26:01 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-9.tower-206.messagelabs.com!1349447160!19716786!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29117 invoked from network); 5 Oct 2012 14:26:01 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-9.tower-206.messagelabs.com with SMTP; 5 Oct 2012 14:26:01 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 05 Oct 2012 15:26:07 +0100 Message-Id: <506F0A1602000078000A00F4@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 05 Oct 2012 15:25:58 +0100 From: "Jan Beulich" To: "Dario Faggioli" References: In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: Andre Przywara , Ian Campbell , Marcus Granado , George Dunlap , Andrew Cooper , Juergen Gross , Anil Madhavapeddy , Ian Jackson , xen-devel@lists.xen.org, Matt Wilson , Daniel De Graaf Subject: Re: [Xen-devel] [PATCH 3 of 8] xen: let the (credit) scheduler know about `node affinity` X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 05.10.12 at 16:08, Dario Faggioli wrote: > @@ -287,22 +344,26 @@ static inline void > } > else > { > - cpumask_t idle_mask; > + cpumask_t idle_mask, balance_mask; Be _very_ careful about adding on-stack CPU mask variables (also further below): each one of them grows the stack frame by 512 bytes (when building for the current maximum of 4095 CPUs), which is generally too much; you may want to consider pre-allocated scratch space instead. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:26:14 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:26:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8qq-0002Ch-50; Fri, 05 Oct 2012 14:26:04 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8qo-0002CP-84 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:26:02 +0000 Received: from [85.158.139.211:22992] by server-15.bemta-5.messagelabs.com id 2B/5F-06905-9FDEE605; Fri, 05 Oct 2012 14:26:01 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-9.tower-206.messagelabs.com!1349447160!19716786!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29117 invoked from network); 5 Oct 2012 14:26:01 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-9.tower-206.messagelabs.com with SMTP; 5 Oct 2012 14:26:01 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 05 Oct 2012 15:26:07 +0100 Message-Id: <506F0A1602000078000A00F4@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.0 Date: Fri, 05 Oct 2012 15:25:58 +0100 From: "Jan Beulich" To: "Dario Faggioli" References: In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: Andre Przywara , Ian Campbell , Marcus Granado , George Dunlap , Andrew Cooper , Juergen Gross , Anil Madhavapeddy , Ian Jackson , xen-devel@lists.xen.org, Matt Wilson , Daniel De Graaf Subject: Re: [Xen-devel] [PATCH 3 of 8] xen: let the (credit) scheduler know about `node affinity` X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org >>> On 05.10.12 at 16:08, Dario Faggioli wrote: > @@ -287,22 +344,26 @@ static inline void > } > else > { > - cpumask_t idle_mask; > + cpumask_t idle_mask, balance_mask; Be _very_ careful about adding on-stack CPU mask variables (also further below): each one of them grows the stack frame by 512 bytes (when building for the current maximum of 4095 CPUs), which is generally too much; you may want to consider pre-allocated scratch space instead. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:30:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:30:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8vJ-0002Sl-Jn; Fri, 05 Oct 2012 14:30:41 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8vH-0002Rq-S7 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:30:40 +0000 Received: from [85.158.143.99:13819] by server-1.bemta-4.messagelabs.com id 3A/9B-05684-F0FEE605; Fri, 05 Oct 2012 14:30:39 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1349447436!23406472!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODA1MjM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17142 invoked from network); 5 Oct 2012 14:30:38 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:30:38 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="210421563" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 14:30:34 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 10:30:34 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK8vB-0006rc-T8; Fri, 05 Oct 2012 15:30:33 +0100 From: Anthony PERARD To: Xen Devel Date: Fri, 5 Oct 2012 15:30:28 +0100 Message-ID: <1349447432-29511-7-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1349447432-29511-1-git-send-email-anthony.perard@citrix.com> References: <1349447432-29511-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Cc: Anthony PERARD , Ian Campbell Subject: [Xen-devel] [PATCH V4 06/10] libxl_qmp: Use qmp_parameters_* functions for param list of a QMP command. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Anthony PERARD Acked-by: Ian Campbell --- tools/libxl/libxl_qmp.c | 71 +++++++++++++++++++------------------------------ 1 file changed, 28 insertions(+), 43 deletions(-) diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c index d86f290..caf2a59 100644 --- a/tools/libxl/libxl_qmp.c +++ b/tools/libxl/libxl_qmp.c @@ -78,7 +78,7 @@ struct libxl__qmp_handler { }; static int qmp_send(libxl__qmp_handler *qmp, - const char *cmd, libxl_key_value_list *args, + const char *cmd, libxl__json_object *args, qmp_callback_t callback, void *opaque, qmp_request_context *context); @@ -502,7 +502,7 @@ static int qmp_next(libxl__gc *gc, libxl__qmp_handler *qmp) } static char *qmp_send_prepare(libxl__gc *gc, libxl__qmp_handler *qmp, - const char *cmd, libxl_key_value_list *args, + const char *cmd, libxl__json_object *args, qmp_callback_t callback, void *opaque, qmp_request_context *context) { @@ -526,7 +526,7 @@ static char *qmp_send_prepare(libxl__gc *gc, libxl__qmp_handler *qmp, yajl_gen_integer(hand, ++qmp->last_id_used); if (args) { libxl__yajl_gen_asciiz(hand, "arguments"); - libxl_key_value_list_gen_json(hand, args); + libxl__json_object_to_yajl_gen(gc, hand, args); } yajl_gen_map_close(hand); @@ -560,7 +560,7 @@ out: } static int qmp_send(libxl__qmp_handler *qmp, - const char *cmd, libxl_key_value_list *args, + const char *cmd, libxl__json_object *args, qmp_callback_t callback, void *opaque, qmp_request_context *context) { @@ -588,7 +588,7 @@ out: } static int qmp_synchronous_send(libxl__qmp_handler *qmp, const char *cmd, - libxl_key_value_list *args, + libxl__json_object *args, qmp_callback_t callback, void *opaque, int ask_timeout) { @@ -623,7 +623,6 @@ static void qmp_free_handler(libxl__qmp_handler *qmp) free(qmp); } -#if 0 /* * QMP Parameters Helpers */ @@ -658,6 +657,7 @@ static void qmp_parameters_add_string(libxl__gc *gc, qmp_parameters_common_add(gc, param, name, obj); } +#if 0 static void qmp_parameters_add_bool(libxl__gc *gc, libxl__json_object **param, const char *name, bool b) @@ -668,11 +668,11 @@ static void qmp_parameters_add_bool(libxl__gc *gc, obj->u.b = b; qmp_parameters_common_add(gc, param, name, obj); } +#endif #define QMP_PARAMETERS_SPRINTF(args, name, format, ...) \ qmp_parameters_add_string(gc, args, name, \ libxl__sprintf(gc, format, __VA_ARGS__)) -#endif /* * API @@ -800,8 +800,7 @@ out: int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev) { libxl__qmp_handler *qmp = NULL; - flexarray_t *parameters = NULL; - libxl_key_value_list args = NULL; + libxl__json_object *args = NULL; char *hostaddr = NULL; int rc = 0; @@ -814,22 +813,16 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev) if (!hostaddr) return -1; - parameters = flexarray_make(gc, 6, 1); - flexarray_append_pair(parameters, "driver", "xen-pci-passthrough"); - flexarray_append_pair(parameters, "id", - libxl__sprintf(gc, PCI_PT_QDEV_ID, - pcidev->bus, pcidev->dev, - pcidev->func)); - flexarray_append_pair(parameters, "hostaddr", hostaddr); + qmp_parameters_add_string(gc, &args, "driver", "xen-pci-passthrough"); + QMP_PARAMETERS_SPRINTF(&args, "id", PCI_PT_QDEV_ID, + pcidev->bus, pcidev->dev, pcidev->func); + qmp_parameters_add_string(gc, &args, "hostaddr", hostaddr); if (pcidev->vdevfn) { - flexarray_append_pair(parameters, "addr", - libxl__sprintf(gc, "%x.%x", - PCI_SLOT(pcidev->vdevfn), - PCI_FUNC(pcidev->vdevfn))); + QMP_PARAMETERS_SPRINTF(&args, "addr", "%x.%x", + PCI_SLOT(pcidev->vdevfn), PCI_FUNC(pcidev->vdevfn)); } - args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count); - rc = qmp_synchronous_send(qmp, "device_add", &args, + rc = qmp_synchronous_send(qmp, "device_add", args, NULL, NULL, qmp->timeout); if (rc == 0) { rc = qmp_synchronous_send(qmp, "query-pci", NULL, @@ -843,19 +836,16 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev) static int qmp_device_del(libxl__gc *gc, int domid, char *id) { libxl__qmp_handler *qmp = NULL; - flexarray_t *parameters = NULL; - libxl_key_value_list args = NULL; + libxl__json_object *args = NULL; int rc = 0; qmp = libxl__qmp_initialize(gc, domid); if (!qmp) return ERROR_FAIL; - parameters = flexarray_make(gc, 2, 1); - flexarray_append_pair(parameters, "id", id); - args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count); + qmp_parameters_add_string(gc, &args, "id", id); - rc = qmp_synchronous_send(qmp, "device_del", &args, + rc = qmp_synchronous_send(qmp, "device_del", args, NULL, NULL, qmp->timeout); libxl__qmp_close(qmp); @@ -875,19 +865,16 @@ int libxl__qmp_pci_del(libxl__gc *gc, int domid, libxl_device_pci *pcidev) int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename) { libxl__qmp_handler *qmp = NULL; - flexarray_t *parameters = NULL; - libxl_key_value_list args = NULL; + libxl__json_object *args = NULL; int rc = 0; qmp = libxl__qmp_initialize(gc, domid); if (!qmp) return ERROR_FAIL; - parameters = flexarray_make(gc, 2, 1); - flexarray_append_pair(parameters, "filename", (char *)filename); - args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count); + qmp_parameters_add_string(gc, &args, "filename", (char *)filename); - rc = qmp_synchronous_send(qmp, "xen-save-devices-state", &args, + rc = qmp_synchronous_send(qmp, "xen-save-devices-state", args, NULL, NULL, qmp->timeout); libxl__qmp_close(qmp); @@ -897,18 +884,16 @@ int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename) static int qmp_change(libxl__gc *gc, libxl__qmp_handler *qmp, char *device, char *target, char *arg) { - flexarray_t *parameters = NULL; - libxl_key_value_list args = NULL; + libxl__json_object *args = NULL; int rc = 0; - parameters = flexarray_make(gc, 6, 1); - flexarray_append_pair(parameters, "device", device); - flexarray_append_pair(parameters, "target", target); - if (arg) - flexarray_append_pair(parameters, "arg", arg); - args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count); + qmp_parameters_add_string(gc, &args, "device", device); + qmp_parameters_add_string(gc, &args, "target", target); + if (arg) { + qmp_parameters_add_string(gc, &args, "arg", arg); + } - rc = qmp_synchronous_send(qmp, "change", &args, + rc = qmp_synchronous_send(qmp, "change", args, NULL, NULL, qmp->timeout); return rc; -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:30:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:30:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8vJ-0002Sl-Jn; Fri, 05 Oct 2012 14:30:41 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8vH-0002Rq-S7 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:30:40 +0000 Received: from [85.158.143.99:13819] by server-1.bemta-4.messagelabs.com id 3A/9B-05684-F0FEE605; Fri, 05 Oct 2012 14:30:39 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1349447436!23406472!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODA1MjM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17142 invoked from network); 5 Oct 2012 14:30:38 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:30:38 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="210421563" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 14:30:34 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 10:30:34 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK8vB-0006rc-T8; Fri, 05 Oct 2012 15:30:33 +0100 From: Anthony PERARD To: Xen Devel Date: Fri, 5 Oct 2012 15:30:28 +0100 Message-ID: <1349447432-29511-7-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1349447432-29511-1-git-send-email-anthony.perard@citrix.com> References: <1349447432-29511-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Cc: Anthony PERARD , Ian Campbell Subject: [Xen-devel] [PATCH V4 06/10] libxl_qmp: Use qmp_parameters_* functions for param list of a QMP command. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Anthony PERARD Acked-by: Ian Campbell --- tools/libxl/libxl_qmp.c | 71 +++++++++++++++++++------------------------------ 1 file changed, 28 insertions(+), 43 deletions(-) diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c index d86f290..caf2a59 100644 --- a/tools/libxl/libxl_qmp.c +++ b/tools/libxl/libxl_qmp.c @@ -78,7 +78,7 @@ struct libxl__qmp_handler { }; static int qmp_send(libxl__qmp_handler *qmp, - const char *cmd, libxl_key_value_list *args, + const char *cmd, libxl__json_object *args, qmp_callback_t callback, void *opaque, qmp_request_context *context); @@ -502,7 +502,7 @@ static int qmp_next(libxl__gc *gc, libxl__qmp_handler *qmp) } static char *qmp_send_prepare(libxl__gc *gc, libxl__qmp_handler *qmp, - const char *cmd, libxl_key_value_list *args, + const char *cmd, libxl__json_object *args, qmp_callback_t callback, void *opaque, qmp_request_context *context) { @@ -526,7 +526,7 @@ static char *qmp_send_prepare(libxl__gc *gc, libxl__qmp_handler *qmp, yajl_gen_integer(hand, ++qmp->last_id_used); if (args) { libxl__yajl_gen_asciiz(hand, "arguments"); - libxl_key_value_list_gen_json(hand, args); + libxl__json_object_to_yajl_gen(gc, hand, args); } yajl_gen_map_close(hand); @@ -560,7 +560,7 @@ out: } static int qmp_send(libxl__qmp_handler *qmp, - const char *cmd, libxl_key_value_list *args, + const char *cmd, libxl__json_object *args, qmp_callback_t callback, void *opaque, qmp_request_context *context) { @@ -588,7 +588,7 @@ out: } static int qmp_synchronous_send(libxl__qmp_handler *qmp, const char *cmd, - libxl_key_value_list *args, + libxl__json_object *args, qmp_callback_t callback, void *opaque, int ask_timeout) { @@ -623,7 +623,6 @@ static void qmp_free_handler(libxl__qmp_handler *qmp) free(qmp); } -#if 0 /* * QMP Parameters Helpers */ @@ -658,6 +657,7 @@ static void qmp_parameters_add_string(libxl__gc *gc, qmp_parameters_common_add(gc, param, name, obj); } +#if 0 static void qmp_parameters_add_bool(libxl__gc *gc, libxl__json_object **param, const char *name, bool b) @@ -668,11 +668,11 @@ static void qmp_parameters_add_bool(libxl__gc *gc, obj->u.b = b; qmp_parameters_common_add(gc, param, name, obj); } +#endif #define QMP_PARAMETERS_SPRINTF(args, name, format, ...) \ qmp_parameters_add_string(gc, args, name, \ libxl__sprintf(gc, format, __VA_ARGS__)) -#endif /* * API @@ -800,8 +800,7 @@ out: int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev) { libxl__qmp_handler *qmp = NULL; - flexarray_t *parameters = NULL; - libxl_key_value_list args = NULL; + libxl__json_object *args = NULL; char *hostaddr = NULL; int rc = 0; @@ -814,22 +813,16 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev) if (!hostaddr) return -1; - parameters = flexarray_make(gc, 6, 1); - flexarray_append_pair(parameters, "driver", "xen-pci-passthrough"); - flexarray_append_pair(parameters, "id", - libxl__sprintf(gc, PCI_PT_QDEV_ID, - pcidev->bus, pcidev->dev, - pcidev->func)); - flexarray_append_pair(parameters, "hostaddr", hostaddr); + qmp_parameters_add_string(gc, &args, "driver", "xen-pci-passthrough"); + QMP_PARAMETERS_SPRINTF(&args, "id", PCI_PT_QDEV_ID, + pcidev->bus, pcidev->dev, pcidev->func); + qmp_parameters_add_string(gc, &args, "hostaddr", hostaddr); if (pcidev->vdevfn) { - flexarray_append_pair(parameters, "addr", - libxl__sprintf(gc, "%x.%x", - PCI_SLOT(pcidev->vdevfn), - PCI_FUNC(pcidev->vdevfn))); + QMP_PARAMETERS_SPRINTF(&args, "addr", "%x.%x", + PCI_SLOT(pcidev->vdevfn), PCI_FUNC(pcidev->vdevfn)); } - args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count); - rc = qmp_synchronous_send(qmp, "device_add", &args, + rc = qmp_synchronous_send(qmp, "device_add", args, NULL, NULL, qmp->timeout); if (rc == 0) { rc = qmp_synchronous_send(qmp, "query-pci", NULL, @@ -843,19 +836,16 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev) static int qmp_device_del(libxl__gc *gc, int domid, char *id) { libxl__qmp_handler *qmp = NULL; - flexarray_t *parameters = NULL; - libxl_key_value_list args = NULL; + libxl__json_object *args = NULL; int rc = 0; qmp = libxl__qmp_initialize(gc, domid); if (!qmp) return ERROR_FAIL; - parameters = flexarray_make(gc, 2, 1); - flexarray_append_pair(parameters, "id", id); - args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count); + qmp_parameters_add_string(gc, &args, "id", id); - rc = qmp_synchronous_send(qmp, "device_del", &args, + rc = qmp_synchronous_send(qmp, "device_del", args, NULL, NULL, qmp->timeout); libxl__qmp_close(qmp); @@ -875,19 +865,16 @@ int libxl__qmp_pci_del(libxl__gc *gc, int domid, libxl_device_pci *pcidev) int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename) { libxl__qmp_handler *qmp = NULL; - flexarray_t *parameters = NULL; - libxl_key_value_list args = NULL; + libxl__json_object *args = NULL; int rc = 0; qmp = libxl__qmp_initialize(gc, domid); if (!qmp) return ERROR_FAIL; - parameters = flexarray_make(gc, 2, 1); - flexarray_append_pair(parameters, "filename", (char *)filename); - args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count); + qmp_parameters_add_string(gc, &args, "filename", (char *)filename); - rc = qmp_synchronous_send(qmp, "xen-save-devices-state", &args, + rc = qmp_synchronous_send(qmp, "xen-save-devices-state", args, NULL, NULL, qmp->timeout); libxl__qmp_close(qmp); @@ -897,18 +884,16 @@ int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename) static int qmp_change(libxl__gc *gc, libxl__qmp_handler *qmp, char *device, char *target, char *arg) { - flexarray_t *parameters = NULL; - libxl_key_value_list args = NULL; + libxl__json_object *args = NULL; int rc = 0; - parameters = flexarray_make(gc, 6, 1); - flexarray_append_pair(parameters, "device", device); - flexarray_append_pair(parameters, "target", target); - if (arg) - flexarray_append_pair(parameters, "arg", arg); - args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count); + qmp_parameters_add_string(gc, &args, "device", device); + qmp_parameters_add_string(gc, &args, "target", target); + if (arg) { + qmp_parameters_add_string(gc, &args, "arg", arg); + } - rc = qmp_synchronous_send(qmp, "change", &args, + rc = qmp_synchronous_send(qmp, "change", args, NULL, NULL, qmp->timeout); return rc; -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:30:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:30:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8vH-0002Rg-6g; Fri, 05 Oct 2012 14:30:39 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8vG-0002RM-3n for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:30:38 +0000 Received: from [85.158.139.83:11587] by server-16.bemta-5.messagelabs.com id 55/6B-21637-D0FEE605; Fri, 05 Oct 2012 14:30:37 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1349447434!26376259!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODA1MjM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31522 invoked from network); 5 Oct 2012 14:30:36 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:30:36 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="210421561" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 14:30:34 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 10:30:34 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK8vB-0006rc-TS; Fri, 05 Oct 2012 15:30:33 +0100 From: Anthony PERARD To: Xen Devel Date: Fri, 5 Oct 2012 15:30:29 +0100 Message-ID: <1349447432-29511-8-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1349447432-29511-1-git-send-email-anthony.perard@citrix.com> References: <1349447432-29511-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Cc: Anthony PERARD , Ian Campbell Subject: [Xen-devel] [PATCH V4 07/10] libxl_qmp: Simplify run of single QMP commands. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This new function connects to QEMU, sends the command and disconnects. Signed-off-by: Anthony PERARD Acked-by: Ian Campbell --- tools/libxl/libxl_qmp.c | 70 ++++++++++++++++--------------------------------- 1 file changed, 22 insertions(+), 48 deletions(-) diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c index caf2a59..7bf56a7 100644 --- a/tools/libxl/libxl_qmp.c +++ b/tools/libxl/libxl_qmp.c @@ -797,6 +797,23 @@ out: return rc; } +static int qmp_run_command(libxl__gc *gc, int domid, + const char *cmd, libxl__json_object *args, + qmp_callback_t callback, void *opaque) +{ + libxl__qmp_handler *qmp = NULL; + int rc = 0; + + qmp = libxl__qmp_initialize(gc, domid); + if (!qmp) + return ERROR_FAIL; + + rc = qmp_synchronous_send(qmp, cmd, args, callback, opaque, qmp->timeout); + + libxl__qmp_close(qmp); + return rc; +} + int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev) { libxl__qmp_handler *qmp = NULL; @@ -835,21 +852,10 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev) static int qmp_device_del(libxl__gc *gc, int domid, char *id) { - libxl__qmp_handler *qmp = NULL; libxl__json_object *args = NULL; - int rc = 0; - - qmp = libxl__qmp_initialize(gc, domid); - if (!qmp) - return ERROR_FAIL; qmp_parameters_add_string(gc, &args, "id", id); - - rc = qmp_synchronous_send(qmp, "device_del", args, - NULL, NULL, qmp->timeout); - - libxl__qmp_close(qmp); - return rc; + return qmp_run_command(gc, domid, "device_del", args, NULL, NULL); } int libxl__qmp_pci_del(libxl__gc *gc, int domid, libxl_device_pci *pcidev) @@ -864,21 +870,11 @@ int libxl__qmp_pci_del(libxl__gc *gc, int domid, libxl_device_pci *pcidev) int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename) { - libxl__qmp_handler *qmp = NULL; libxl__json_object *args = NULL; - int rc = 0; - - qmp = libxl__qmp_initialize(gc, domid); - if (!qmp) - return ERROR_FAIL; qmp_parameters_add_string(gc, &args, "filename", (char *)filename); - - rc = qmp_synchronous_send(qmp, "xen-save-devices-state", args, - NULL, NULL, qmp->timeout); - - libxl__qmp_close(qmp); - return rc; + return qmp_run_command(gc, domid, "xen-save-devices-state", args, + NULL, NULL); } static int qmp_change(libxl__gc *gc, libxl__qmp_handler *qmp, @@ -901,34 +897,12 @@ static int qmp_change(libxl__gc *gc, libxl__qmp_handler *qmp, int libxl__qmp_stop(libxl__gc *gc, int domid) { - libxl__qmp_handler *qmp = NULL; - int rc = 0; - - qmp = libxl__qmp_initialize(gc, domid); - if (!qmp) - return ERROR_FAIL; - - rc = qmp_synchronous_send(qmp, "stop", NULL, - NULL, NULL, qmp->timeout); - - libxl__qmp_close(qmp); - return rc; + return qmp_run_command(gc, domid, "stop", NULL, NULL, NULL); } int libxl__qmp_resume(libxl__gc *gc, int domid) { - libxl__qmp_handler *qmp = NULL; - int rc = 0; - - qmp = libxl__qmp_initialize(gc, domid); - if (!qmp) - return ERROR_FAIL; - - rc = qmp_synchronous_send(qmp, "cont", NULL, - NULL, NULL, qmp->timeout); - - libxl__qmp_close(qmp); - return rc; + return qmp_run_command(gc, domid, "cont", NULL, NULL, NULL); } int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid, -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:30:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:30:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8vH-0002Rg-6g; Fri, 05 Oct 2012 14:30:39 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8vG-0002RM-3n for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:30:38 +0000 Received: from [85.158.139.83:11587] by server-16.bemta-5.messagelabs.com id 55/6B-21637-D0FEE605; Fri, 05 Oct 2012 14:30:37 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1349447434!26376259!2 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODA1MjM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31522 invoked from network); 5 Oct 2012 14:30:36 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:30:36 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="210421561" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 14:30:34 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 10:30:34 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK8vB-0006rc-TS; Fri, 05 Oct 2012 15:30:33 +0100 From: Anthony PERARD To: Xen Devel Date: Fri, 5 Oct 2012 15:30:29 +0100 Message-ID: <1349447432-29511-8-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1349447432-29511-1-git-send-email-anthony.perard@citrix.com> References: <1349447432-29511-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Cc: Anthony PERARD , Ian Campbell Subject: [Xen-devel] [PATCH V4 07/10] libxl_qmp: Simplify run of single QMP commands. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This new function connects to QEMU, sends the command and disconnects. Signed-off-by: Anthony PERARD Acked-by: Ian Campbell --- tools/libxl/libxl_qmp.c | 70 ++++++++++++++++--------------------------------- 1 file changed, 22 insertions(+), 48 deletions(-) diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c index caf2a59..7bf56a7 100644 --- a/tools/libxl/libxl_qmp.c +++ b/tools/libxl/libxl_qmp.c @@ -797,6 +797,23 @@ out: return rc; } +static int qmp_run_command(libxl__gc *gc, int domid, + const char *cmd, libxl__json_object *args, + qmp_callback_t callback, void *opaque) +{ + libxl__qmp_handler *qmp = NULL; + int rc = 0; + + qmp = libxl__qmp_initialize(gc, domid); + if (!qmp) + return ERROR_FAIL; + + rc = qmp_synchronous_send(qmp, cmd, args, callback, opaque, qmp->timeout); + + libxl__qmp_close(qmp); + return rc; +} + int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev) { libxl__qmp_handler *qmp = NULL; @@ -835,21 +852,10 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev) static int qmp_device_del(libxl__gc *gc, int domid, char *id) { - libxl__qmp_handler *qmp = NULL; libxl__json_object *args = NULL; - int rc = 0; - - qmp = libxl__qmp_initialize(gc, domid); - if (!qmp) - return ERROR_FAIL; qmp_parameters_add_string(gc, &args, "id", id); - - rc = qmp_synchronous_send(qmp, "device_del", args, - NULL, NULL, qmp->timeout); - - libxl__qmp_close(qmp); - return rc; + return qmp_run_command(gc, domid, "device_del", args, NULL, NULL); } int libxl__qmp_pci_del(libxl__gc *gc, int domid, libxl_device_pci *pcidev) @@ -864,21 +870,11 @@ int libxl__qmp_pci_del(libxl__gc *gc, int domid, libxl_device_pci *pcidev) int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename) { - libxl__qmp_handler *qmp = NULL; libxl__json_object *args = NULL; - int rc = 0; - - qmp = libxl__qmp_initialize(gc, domid); - if (!qmp) - return ERROR_FAIL; qmp_parameters_add_string(gc, &args, "filename", (char *)filename); - - rc = qmp_synchronous_send(qmp, "xen-save-devices-state", args, - NULL, NULL, qmp->timeout); - - libxl__qmp_close(qmp); - return rc; + return qmp_run_command(gc, domid, "xen-save-devices-state", args, + NULL, NULL); } static int qmp_change(libxl__gc *gc, libxl__qmp_handler *qmp, @@ -901,34 +897,12 @@ static int qmp_change(libxl__gc *gc, libxl__qmp_handler *qmp, int libxl__qmp_stop(libxl__gc *gc, int domid) { - libxl__qmp_handler *qmp = NULL; - int rc = 0; - - qmp = libxl__qmp_initialize(gc, domid); - if (!qmp) - return ERROR_FAIL; - - rc = qmp_synchronous_send(qmp, "stop", NULL, - NULL, NULL, qmp->timeout); - - libxl__qmp_close(qmp); - return rc; + return qmp_run_command(gc, domid, "stop", NULL, NULL, NULL); } int libxl__qmp_resume(libxl__gc *gc, int domid) { - libxl__qmp_handler *qmp = NULL; - int rc = 0; - - qmp = libxl__qmp_initialize(gc, domid); - if (!qmp) - return ERROR_FAIL; - - rc = qmp_synchronous_send(qmp, "cont", NULL, - NULL, NULL, qmp->timeout); - - libxl__qmp_close(qmp); - return rc; + return qmp_run_command(gc, domid, "cont", NULL, NULL, NULL); } int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid, -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:30:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:30:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8vG-0002RY-RZ; Fri, 05 Oct 2012 14:30:38 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8vF-0002RL-Ha for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:30:37 +0000 Received: from [85.158.139.83:8223] by server-3.bemta-5.messagelabs.com id 2B/7A-16108-C0FEE605; Fri, 05 Oct 2012 14:30:36 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1349447434!26376259!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODA1MjM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31449 invoked from network); 5 Oct 2012 14:30:35 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:30:35 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="210421560" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 14:30:34 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 10:30:34 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK8vB-0006rc-L3; Fri, 05 Oct 2012 15:30:33 +0100 From: Anthony PERARD To: Xen Devel Date: Fri, 5 Oct 2012 15:30:22 +0100 Message-ID: <1349447432-29511-1-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 MIME-Version: 1.0 Cc: Anthony PERARD , Ian Campbell Subject: [Xen-devel] [PATCH V4 00/10] Set dirty log on qemu-xen. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch series enables libxl to set dirty log on QEMU upstream during migration through a new QMP command. The success of the call depends on the presence of the specific QMP command xen-set-global-dirty-log in QEMU. Patches for this command have been sent. There is several patches that cleanup a bit the libxl_json/qmp codes. Change since v3: - Update the comment on the first patch to say that NOGC can be used. Anthony PERARD (10): libxl_json: Export json_object related function. libxl_json: Remove JSON_ERROR from enum. libxl_json: Replace JSON_TRUE/FALSE by JSON_BOOL. libxl_json: Introduce libxl__json_object_to_yajl_gen. libxl_qmp: Introduces helpers to create an argument list. libxl_qmp: Use qmp_parameters_* functions for param list of a QMP command. libxl_qmp: Simplify run of single QMP commands. libxl_qmp: Introduce libxl__qmp_set_global_dirty_log. libxl_dom: Call the right switch logdirty for the right DM. libxl: Allow migration with qemu-xen. tools/libxl/libxl.c | 17 ---- tools/libxl/libxl_dom.c | 45 ++++++++++- tools/libxl/libxl_internal.h | 35 ++++++-- tools/libxl/libxl_json.c | 95 ++++++++++++++++++---- tools/libxl/libxl_qmp.c | 189 ++++++++++++++++++++++++------------------- 5 files changed, 254 insertions(+), 127 deletions(-) -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:30:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:30:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8vG-0002RY-RZ; Fri, 05 Oct 2012 14:30:38 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8vF-0002RL-Ha for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:30:37 +0000 Received: from [85.158.139.83:8223] by server-3.bemta-5.messagelabs.com id 2B/7A-16108-C0FEE605; Fri, 05 Oct 2012 14:30:36 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1349447434!26376259!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODA1MjM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31449 invoked from network); 5 Oct 2012 14:30:35 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:30:35 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="210421560" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 14:30:34 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 10:30:34 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK8vB-0006rc-L3; Fri, 05 Oct 2012 15:30:33 +0100 From: Anthony PERARD To: Xen Devel Date: Fri, 5 Oct 2012 15:30:22 +0100 Message-ID: <1349447432-29511-1-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 MIME-Version: 1.0 Cc: Anthony PERARD , Ian Campbell Subject: [Xen-devel] [PATCH V4 00/10] Set dirty log on qemu-xen. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch series enables libxl to set dirty log on QEMU upstream during migration through a new QMP command. The success of the call depends on the presence of the specific QMP command xen-set-global-dirty-log in QEMU. Patches for this command have been sent. There is several patches that cleanup a bit the libxl_json/qmp codes. Change since v3: - Update the comment on the first patch to say that NOGC can be used. Anthony PERARD (10): libxl_json: Export json_object related function. libxl_json: Remove JSON_ERROR from enum. libxl_json: Replace JSON_TRUE/FALSE by JSON_BOOL. libxl_json: Introduce libxl__json_object_to_yajl_gen. libxl_qmp: Introduces helpers to create an argument list. libxl_qmp: Use qmp_parameters_* functions for param list of a QMP command. libxl_qmp: Simplify run of single QMP commands. libxl_qmp: Introduce libxl__qmp_set_global_dirty_log. libxl_dom: Call the right switch logdirty for the right DM. libxl: Allow migration with qemu-xen. tools/libxl/libxl.c | 17 ---- tools/libxl/libxl_dom.c | 45 ++++++++++- tools/libxl/libxl_internal.h | 35 ++++++-- tools/libxl/libxl_json.c | 95 ++++++++++++++++++---- tools/libxl/libxl_qmp.c | 189 ++++++++++++++++++++++++------------------- 5 files changed, 254 insertions(+), 127 deletions(-) -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:30:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:30:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8vN-0002Uz-MU; Fri, 05 Oct 2012 14:30:45 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8vM-0002Ro-MT for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:30:44 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1349447434!7502915!4 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ1ODc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19175 invoked from network); 5 Oct 2012 14:30:38 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:30:38 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="40274560" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 14:30:34 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 10:30:34 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK8vB-0006rc-RZ; Fri, 05 Oct 2012 15:30:33 +0100 From: Anthony PERARD To: Xen Devel Date: Fri, 5 Oct 2012 15:30:27 +0100 Message-ID: <1349447432-29511-6-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1349447432-29511-1-git-send-email-anthony.perard@citrix.com> References: <1349447432-29511-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Cc: Anthony PERARD , Ian Campbell Subject: [Xen-devel] [PATCH V4 05/10] libxl_qmp: Introduces helpers to create an argument list. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Those functions will be used to create a "list" of parameters that contain more than just strings. This list is converted by qmp_send to a string to be sent to QEMU. Those functions will be used in the next two patches, so right now there are not compiled. Signed-off-by: Anthony PERARD Acked-by: Ian Campbell --- tools/libxl/libxl_qmp.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 51 insertions(+) diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c index 9109ac5..d86f290 100644 --- a/tools/libxl/libxl_qmp.c +++ b/tools/libxl/libxl_qmp.c @@ -623,6 +623,57 @@ static void qmp_free_handler(libxl__qmp_handler *qmp) free(qmp); } +#if 0 +/* + * QMP Parameters Helpers + */ +static void qmp_parameters_common_add(libxl__gc *gc, + libxl__json_object **param, + const char *name, + libxl__json_object *obj) +{ + libxl__json_map_node *arg = NULL; + + if (!*param) { + *param = libxl__json_object_alloc(gc, JSON_MAP); + } + + arg = libxl__zalloc(gc, sizeof(*arg)); + + arg->map_key = libxl__strdup(gc, name); + arg->obj = obj; + + flexarray_append((*param)->u.map, arg); +} + +static void qmp_parameters_add_string(libxl__gc *gc, + libxl__json_object **param, + const char *name, const char *argument) +{ + libxl__json_object *obj; + + obj = libxl__json_object_alloc(gc, JSON_STRING); + obj->u.string = libxl__strdup(gc, argument); + + qmp_parameters_common_add(gc, param, name, obj); +} + +static void qmp_parameters_add_bool(libxl__gc *gc, + libxl__json_object **param, + const char *name, bool b) +{ + libxl__json_object *obj; + + obj = libxl__json_object_alloc(gc, JSON_BOOL); + obj->u.b = b; + qmp_parameters_common_add(gc, param, name, obj); +} + +#define QMP_PARAMETERS_SPRINTF(args, name, format, ...) \ + qmp_parameters_add_string(gc, args, name, \ + libxl__sprintf(gc, format, __VA_ARGS__)) +#endif + /* * API */ -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:30:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:30:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8vI-0002S7-Ju; Fri, 05 Oct 2012 14:30:40 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8vH-0002RW-2L for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:30:39 +0000 Received: from [85.158.139.83:8374] by server-2.bemta-5.messagelabs.com id 95/25-28944-E0FEE605; Fri, 05 Oct 2012 14:30:38 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1349447434!26376259!3 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODA1MjM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31580 invoked from network); 5 Oct 2012 14:30:37 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:30:37 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="210421562" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 14:30:34 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 10:30:34 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK8vB-0006rc-Uw; Fri, 05 Oct 2012 15:30:33 +0100 From: Anthony PERARD To: Xen Devel Date: Fri, 5 Oct 2012 15:30:30 +0100 Message-ID: <1349447432-29511-9-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1349447432-29511-1-git-send-email-anthony.perard@citrix.com> References: <1349447432-29511-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Cc: Anthony PERARD , Ian Campbell Subject: [Xen-devel] [PATCH V4 08/10] libxl_qmp: Introduce libxl__qmp_set_global_dirty_log. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This function will enable or disable the global dirty log on QEMU, used during a migration. Signed-off-by: Anthony PERARD Acked-by: Ian Campbell --- tools/libxl/libxl_internal.h | 2 ++ tools/libxl/libxl_qmp.c | 12 ++++++++++-- 2 files changed, 12 insertions(+), 2 deletions(-) diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 04ca5a5..afa36a7 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -1404,6 +1404,8 @@ _hidden int libxl__qmp_stop(libxl__gc *gc, int domid); _hidden int libxl__qmp_resume(libxl__gc *gc, int domid); /* Save current QEMU state into fd. */ _hidden int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename); +/* Set dirty bitmap logging status */ +_hidden int libxl__qmp_set_global_dirty_log(libxl__gc *gc, int domid, bool enable); /* close and free the QMP handler */ _hidden void libxl__qmp_close(libxl__qmp_handler *qmp); /* remove the socket file, if the file has already been removed, diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c index 7bf56a7..5fa0c65 100644 --- a/tools/libxl/libxl_qmp.c +++ b/tools/libxl/libxl_qmp.c @@ -657,7 +657,6 @@ static void qmp_parameters_add_string(libxl__gc *gc, qmp_parameters_common_add(gc, param, name, obj); } -#if 0 static void qmp_parameters_add_bool(libxl__gc *gc, libxl__json_object **param, const char *name, bool b) @@ -668,7 +667,6 @@ static void qmp_parameters_add_bool(libxl__gc *gc, obj->u.b = b; qmp_parameters_common_add(gc, param, name, obj); } -#endif #define QMP_PARAMETERS_SPRINTF(args, name, format, ...) \ qmp_parameters_add_string(gc, args, name, \ @@ -905,6 +903,16 @@ int libxl__qmp_resume(libxl__gc *gc, int domid) return qmp_run_command(gc, domid, "cont", NULL, NULL, NULL); } +int libxl__qmp_set_global_dirty_log(libxl__gc *gc, int domid, bool enable) +{ + libxl__json_object *args = NULL; + + qmp_parameters_add_bool(gc, &args, "enable", enable); + + return qmp_run_command(gc, domid, "xen-set-global-dirty-log", args, + NULL, NULL); +} + int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid, const libxl_domain_config *guest_config) { -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:30:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:30:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8vM-0002UO-U4; Fri, 05 Oct 2012 14:30:44 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8vL-0002RN-5R for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:30:43 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1349447434!7502915!2 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ1ODc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19000 invoked from network); 5 Oct 2012 14:30:36 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:30:36 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="40274557" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 14:30:34 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 10:30:34 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK8vB-0006rc-OU; Fri, 05 Oct 2012 15:30:33 +0100 From: Anthony PERARD To: Xen Devel Date: Fri, 5 Oct 2012 15:30:25 +0100 Message-ID: <1349447432-29511-4-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1349447432-29511-1-git-send-email-anthony.perard@citrix.com> References: <1349447432-29511-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Cc: Anthony PERARD , Ian Campbell Subject: [Xen-devel] [PATCH V4 03/10] libxl_json: Replace JSON_TRUE/FALSE by JSON_BOOL. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Those two JSON_TRUE and JSON_FALSE were types of node. But it's better to have a unique JSON_BOOL type. Signed-off-by: Anthony PERARD Acked-by: Ian Campbell --- tools/libxl/libxl_internal.h | 15 +++++++++++++-- tools/libxl/libxl_json.c | 4 ++-- tools/libxl/libxl_qmp.c | 3 ++- 3 files changed, 17 insertions(+), 5 deletions(-) diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 6977a6d..6744fda 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -1433,8 +1433,7 @@ _hidden yajl_gen_status libxl__yajl_gen_enum(yajl_gen hand, const char *str); typedef enum { JSON_NULL, - JSON_TRUE, - JSON_FALSE, + JSON_BOOL, JSON_INTEGER, JSON_DOUBLE, /* number is store in string, it's too big to be a long long or a double */ @@ -1448,6 +1447,7 @@ typedef enum { typedef struct libxl__json_object { libxl__json_node_type type; union { + bool b; long long i; double d; char *string; @@ -1466,6 +1466,10 @@ typedef struct { typedef struct libxl__yajl_ctx libxl__yajl_ctx; +static inline bool libxl__json_object_is_bool(const libxl__json_object *o) +{ + return o != NULL && o->type == JSON_BOOL; +} static inline bool libxl__json_object_is_string(const libxl__json_object *o) { return o != NULL && o->type == JSON_STRING; @@ -1483,6 +1487,13 @@ static inline bool libxl__json_object_is_array(const libxl__json_object *o) return o != NULL && o->type == JSON_ARRAY; } +static inline bool libxl__json_object_get_bool(const libxl__json_object *o) +{ + if (libxl__json_object_is_bool(o)) + return o->u.b; + else + return false; +} static inline const char *libxl__json_object_get_string(const libxl__json_object *o) { diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c index a045594..26a7370 100644 --- a/tools/libxl/libxl_json.c +++ b/tools/libxl/libxl_json.c @@ -394,8 +394,8 @@ static int json_callback_boolean(void *opaque, int boolean) DEBUG_GEN_VALUE(ctx, bool, boolean); - obj = libxl__json_object_alloc(ctx->gc, - boolean ? JSON_TRUE : JSON_FALSE); + obj = libxl__json_object_alloc(ctx->gc, JSON_BOOL); + obj->u.b = boolean; if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) { return 0; diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c index 15550e7..9109ac5 100644 --- a/tools/libxl/libxl_qmp.c +++ b/tools/libxl/libxl_qmp.c @@ -178,7 +178,8 @@ static int qmp_register_vnc_callback(libxl__qmp_handler *qmp, goto out; } - if (libxl__json_map_get("enabled", o, JSON_FALSE)) { + obj = libxl__json_map_get("enabled", o, JSON_BOOL); + if (!obj || !libxl__json_object_get_bool(obj)) { rc = 0; goto out; } -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:30:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:30:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8vL-0002Tj-H1; Fri, 05 Oct 2012 14:30:43 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8vK-0002RK-8U for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:30:42 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1349447434!7502915!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ1ODc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18924 invoked from network); 5 Oct 2012 14:30:36 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:30:36 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="40274556" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 14:30:34 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 10:30:34 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK8vB-0006rc-Mv; Fri, 05 Oct 2012 15:30:33 +0100 From: Anthony PERARD To: Xen Devel Date: Fri, 5 Oct 2012 15:30:24 +0100 Message-ID: <1349447432-29511-3-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1349447432-29511-1-git-send-email-anthony.perard@citrix.com> References: <1349447432-29511-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Cc: Anthony PERARD , Ian Campbell Subject: [Xen-devel] [PATCH V4 02/10] libxl_json: Remove JSON_ERROR from enum. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This value from libxl__json_node_type is never used. Signed-off-by: Anthony PERARD Acked-by: Ian Campbell --- tools/libxl/libxl_internal.h | 1 - 1 file changed, 1 deletion(-) diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index cdf5300..6977a6d 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -1432,7 +1432,6 @@ _hidden yajl_gen_status libxl__yajl_gen_asciiz(yajl_gen hand, const char *str); _hidden yajl_gen_status libxl__yajl_gen_enum(yajl_gen hand, const char *str); typedef enum { - JSON_ERROR, JSON_NULL, JSON_TRUE, JSON_FALSE, -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:30:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:30:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8vL-0002TR-32; Fri, 05 Oct 2012 14:30:43 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8vJ-0002SY-NN for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:30:41 +0000 Received: from [85.158.139.83:11977] by server-14.bemta-5.messagelabs.com id 17/AE-31065-11FEE605; Fri, 05 Oct 2012 14:30:41 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1349447436!29638886!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ1ODc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9955 invoked from network); 5 Oct 2012 14:30:38 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:30:38 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="40274559" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 14:30:34 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 10:30:34 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK8vB-0006rc-Q2; Fri, 05 Oct 2012 15:30:33 +0100 From: Anthony PERARD To: Xen Devel Date: Fri, 5 Oct 2012 15:30:26 +0100 Message-ID: <1349447432-29511-5-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1349447432-29511-1-git-send-email-anthony.perard@citrix.com> References: <1349447432-29511-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Cc: Anthony PERARD , Ian Campbell Subject: [Xen-devel] [PATCH V4 04/10] libxl_json: Introduce libxl__json_object_to_yajl_gen. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This function converts a libxl__json_object to yajl by calling every yajl_gen_* function on a preallocated yajl_gen hand. This helps to integrate a json_object into an already existing yajl_gen tree. This function is used in a later patch. Signed-off-by: Anthony PERARD Acked-by: Ian Campbell --- tools/libxl/libxl_internal.h | 3 +++ tools/libxl/libxl_json.c | 61 ++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 64 insertions(+) diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 6744fda..04ca5a5 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -1543,6 +1543,9 @@ libxl__json_map_node *libxl__json_map_node_get(const libxl__json_object *o, _hidden const libxl__json_object *libxl__json_map_get(const char *key, const libxl__json_object *o, libxl__json_node_type expected_type); +_hidden yajl_status libxl__json_object_to_yajl_gen(libxl__gc *gc_opt, + yajl_gen hand, + libxl__json_object *param); _hidden void libxl__json_object_free(libxl__gc *gc_opt, libxl__json_object *obj); diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c index 26a7370..f5d87f7 100644 --- a/tools/libxl/libxl_json.c +++ b/tools/libxl/libxl_json.c @@ -366,6 +366,67 @@ const libxl__json_object *libxl__json_map_get(const char *key, return NULL; } +yajl_status libxl__json_object_to_yajl_gen(libxl__gc *gc, + yajl_gen hand, + libxl__json_object *obj) +{ + int index = 0; + yajl_status rc; + + switch (obj->type) { + case JSON_NULL: + return yajl_gen_null(hand); + case JSON_BOOL: + return yajl_gen_bool(hand, obj->u.b); + case JSON_INTEGER: + return yajl_gen_integer(hand, obj->u.i); + case JSON_DOUBLE: + return yajl_gen_double(hand, obj->u.d); + case JSON_NUMBER: + return yajl_gen_number(hand, obj->u.string, strlen(obj->u.string)); + case JSON_STRING: + return libxl__yajl_gen_asciiz(hand, obj->u.string); + case JSON_MAP: { + libxl__json_map_node *node = NULL; + + rc = yajl_gen_map_open(hand); + if (rc != yajl_status_ok) + return rc; + for (index = 0; index < obj->u.map->count; index++) { + if (flexarray_get(obj->u.map, index, (void**)&node) != 0) + break; + + rc = libxl__yajl_gen_asciiz(hand, node->map_key); + if (rc != yajl_status_ok) + return rc; + rc = libxl__json_object_to_yajl_gen(gc, hand, node->obj); + if (rc != yajl_status_ok) + return rc; + } + return yajl_gen_map_close(hand); + } + case JSON_ARRAY: { + libxl__json_object *node = NULL; + + rc = yajl_gen_array_open(hand); + if (rc != yajl_status_ok) + return rc; + for (index = 0; index < obj->u.array->count; index++) { + if (flexarray_get(obj->u.array, index, (void**)&node) != 0) + break; + rc = libxl__json_object_to_yajl_gen(gc, hand, node); + if (rc != yajl_status_ok) + return rc; + } + return yajl_gen_array_close(hand); + } + case JSON_ANY: + /* JSON_ANY is not a valid value for obj->type. */ + ; + } + abort(); +} + /* * JSON callbacks -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:30:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:30:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8vM-0002UO-U4; Fri, 05 Oct 2012 14:30:44 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8vL-0002RN-5R for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:30:43 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1349447434!7502915!2 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ1ODc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19000 invoked from network); 5 Oct 2012 14:30:36 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:30:36 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="40274557" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 14:30:34 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 10:30:34 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK8vB-0006rc-OU; Fri, 05 Oct 2012 15:30:33 +0100 From: Anthony PERARD To: Xen Devel Date: Fri, 5 Oct 2012 15:30:25 +0100 Message-ID: <1349447432-29511-4-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1349447432-29511-1-git-send-email-anthony.perard@citrix.com> References: <1349447432-29511-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Cc: Anthony PERARD , Ian Campbell Subject: [Xen-devel] [PATCH V4 03/10] libxl_json: Replace JSON_TRUE/FALSE by JSON_BOOL. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Those two JSON_TRUE and JSON_FALSE were types of node. But it's better to have a unique JSON_BOOL type. Signed-off-by: Anthony PERARD Acked-by: Ian Campbell --- tools/libxl/libxl_internal.h | 15 +++++++++++++-- tools/libxl/libxl_json.c | 4 ++-- tools/libxl/libxl_qmp.c | 3 ++- 3 files changed, 17 insertions(+), 5 deletions(-) diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 6977a6d..6744fda 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -1433,8 +1433,7 @@ _hidden yajl_gen_status libxl__yajl_gen_enum(yajl_gen hand, const char *str); typedef enum { JSON_NULL, - JSON_TRUE, - JSON_FALSE, + JSON_BOOL, JSON_INTEGER, JSON_DOUBLE, /* number is store in string, it's too big to be a long long or a double */ @@ -1448,6 +1447,7 @@ typedef enum { typedef struct libxl__json_object { libxl__json_node_type type; union { + bool b; long long i; double d; char *string; @@ -1466,6 +1466,10 @@ typedef struct { typedef struct libxl__yajl_ctx libxl__yajl_ctx; +static inline bool libxl__json_object_is_bool(const libxl__json_object *o) +{ + return o != NULL && o->type == JSON_BOOL; +} static inline bool libxl__json_object_is_string(const libxl__json_object *o) { return o != NULL && o->type == JSON_STRING; @@ -1483,6 +1487,13 @@ static inline bool libxl__json_object_is_array(const libxl__json_object *o) return o != NULL && o->type == JSON_ARRAY; } +static inline bool libxl__json_object_get_bool(const libxl__json_object *o) +{ + if (libxl__json_object_is_bool(o)) + return o->u.b; + else + return false; +} static inline const char *libxl__json_object_get_string(const libxl__json_object *o) { diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c index a045594..26a7370 100644 --- a/tools/libxl/libxl_json.c +++ b/tools/libxl/libxl_json.c @@ -394,8 +394,8 @@ static int json_callback_boolean(void *opaque, int boolean) DEBUG_GEN_VALUE(ctx, bool, boolean); - obj = libxl__json_object_alloc(ctx->gc, - boolean ? JSON_TRUE : JSON_FALSE); + obj = libxl__json_object_alloc(ctx->gc, JSON_BOOL); + obj->u.b = boolean; if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) { return 0; diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c index 15550e7..9109ac5 100644 --- a/tools/libxl/libxl_qmp.c +++ b/tools/libxl/libxl_qmp.c @@ -178,7 +178,8 @@ static int qmp_register_vnc_callback(libxl__qmp_handler *qmp, goto out; } - if (libxl__json_map_get("enabled", o, JSON_FALSE)) { + obj = libxl__json_map_get("enabled", o, JSON_BOOL); + if (!obj || !libxl__json_object_get_bool(obj)) { rc = 0; goto out; } -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:30:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:30:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8vN-0002Uz-MU; Fri, 05 Oct 2012 14:30:45 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8vM-0002Ro-MT for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:30:44 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1349447434!7502915!4 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ1ODc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19175 invoked from network); 5 Oct 2012 14:30:38 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:30:38 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="40274560" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 14:30:34 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 10:30:34 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK8vB-0006rc-RZ; Fri, 05 Oct 2012 15:30:33 +0100 From: Anthony PERARD To: Xen Devel Date: Fri, 5 Oct 2012 15:30:27 +0100 Message-ID: <1349447432-29511-6-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1349447432-29511-1-git-send-email-anthony.perard@citrix.com> References: <1349447432-29511-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Cc: Anthony PERARD , Ian Campbell Subject: [Xen-devel] [PATCH V4 05/10] libxl_qmp: Introduces helpers to create an argument list. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Those functions will be used to create a "list" of parameters that contain more than just strings. This list is converted by qmp_send to a string to be sent to QEMU. Those functions will be used in the next two patches, so right now there are not compiled. Signed-off-by: Anthony PERARD Acked-by: Ian Campbell --- tools/libxl/libxl_qmp.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 51 insertions(+) diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c index 9109ac5..d86f290 100644 --- a/tools/libxl/libxl_qmp.c +++ b/tools/libxl/libxl_qmp.c @@ -623,6 +623,57 @@ static void qmp_free_handler(libxl__qmp_handler *qmp) free(qmp); } +#if 0 +/* + * QMP Parameters Helpers + */ +static void qmp_parameters_common_add(libxl__gc *gc, + libxl__json_object **param, + const char *name, + libxl__json_object *obj) +{ + libxl__json_map_node *arg = NULL; + + if (!*param) { + *param = libxl__json_object_alloc(gc, JSON_MAP); + } + + arg = libxl__zalloc(gc, sizeof(*arg)); + + arg->map_key = libxl__strdup(gc, name); + arg->obj = obj; + + flexarray_append((*param)->u.map, arg); +} + +static void qmp_parameters_add_string(libxl__gc *gc, + libxl__json_object **param, + const char *name, const char *argument) +{ + libxl__json_object *obj; + + obj = libxl__json_object_alloc(gc, JSON_STRING); + obj->u.string = libxl__strdup(gc, argument); + + qmp_parameters_common_add(gc, param, name, obj); +} + +static void qmp_parameters_add_bool(libxl__gc *gc, + libxl__json_object **param, + const char *name, bool b) +{ + libxl__json_object *obj; + + obj = libxl__json_object_alloc(gc, JSON_BOOL); + obj->u.b = b; + qmp_parameters_common_add(gc, param, name, obj); +} + +#define QMP_PARAMETERS_SPRINTF(args, name, format, ...) \ + qmp_parameters_add_string(gc, args, name, \ + libxl__sprintf(gc, format, __VA_ARGS__)) +#endif + /* * API */ -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:30:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:30:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8vL-0002Tj-H1; Fri, 05 Oct 2012 14:30:43 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8vK-0002RK-8U for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:30:42 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1349447434!7502915!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ1ODc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18924 invoked from network); 5 Oct 2012 14:30:36 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:30:36 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="40274556" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 14:30:34 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 10:30:34 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK8vB-0006rc-Mv; Fri, 05 Oct 2012 15:30:33 +0100 From: Anthony PERARD To: Xen Devel Date: Fri, 5 Oct 2012 15:30:24 +0100 Message-ID: <1349447432-29511-3-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1349447432-29511-1-git-send-email-anthony.perard@citrix.com> References: <1349447432-29511-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Cc: Anthony PERARD , Ian Campbell Subject: [Xen-devel] [PATCH V4 02/10] libxl_json: Remove JSON_ERROR from enum. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This value from libxl__json_node_type is never used. Signed-off-by: Anthony PERARD Acked-by: Ian Campbell --- tools/libxl/libxl_internal.h | 1 - 1 file changed, 1 deletion(-) diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index cdf5300..6977a6d 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -1432,7 +1432,6 @@ _hidden yajl_gen_status libxl__yajl_gen_asciiz(yajl_gen hand, const char *str); _hidden yajl_gen_status libxl__yajl_gen_enum(yajl_gen hand, const char *str); typedef enum { - JSON_ERROR, JSON_NULL, JSON_TRUE, JSON_FALSE, -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:30:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:30:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8vL-0002TR-32; Fri, 05 Oct 2012 14:30:43 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8vJ-0002SY-NN for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:30:41 +0000 Received: from [85.158.139.83:11977] by server-14.bemta-5.messagelabs.com id 17/AE-31065-11FEE605; Fri, 05 Oct 2012 14:30:41 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1349447436!29638886!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ1ODc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9955 invoked from network); 5 Oct 2012 14:30:38 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:30:38 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="40274559" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 14:30:34 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 10:30:34 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK8vB-0006rc-Q2; Fri, 05 Oct 2012 15:30:33 +0100 From: Anthony PERARD To: Xen Devel Date: Fri, 5 Oct 2012 15:30:26 +0100 Message-ID: <1349447432-29511-5-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1349447432-29511-1-git-send-email-anthony.perard@citrix.com> References: <1349447432-29511-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Cc: Anthony PERARD , Ian Campbell Subject: [Xen-devel] [PATCH V4 04/10] libxl_json: Introduce libxl__json_object_to_yajl_gen. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This function converts a libxl__json_object to yajl by calling every yajl_gen_* function on a preallocated yajl_gen hand. This helps to integrate a json_object into an already existing yajl_gen tree. This function is used in a later patch. Signed-off-by: Anthony PERARD Acked-by: Ian Campbell --- tools/libxl/libxl_internal.h | 3 +++ tools/libxl/libxl_json.c | 61 ++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 64 insertions(+) diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 6744fda..04ca5a5 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -1543,6 +1543,9 @@ libxl__json_map_node *libxl__json_map_node_get(const libxl__json_object *o, _hidden const libxl__json_object *libxl__json_map_get(const char *key, const libxl__json_object *o, libxl__json_node_type expected_type); +_hidden yajl_status libxl__json_object_to_yajl_gen(libxl__gc *gc_opt, + yajl_gen hand, + libxl__json_object *param); _hidden void libxl__json_object_free(libxl__gc *gc_opt, libxl__json_object *obj); diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c index 26a7370..f5d87f7 100644 --- a/tools/libxl/libxl_json.c +++ b/tools/libxl/libxl_json.c @@ -366,6 +366,67 @@ const libxl__json_object *libxl__json_map_get(const char *key, return NULL; } +yajl_status libxl__json_object_to_yajl_gen(libxl__gc *gc, + yajl_gen hand, + libxl__json_object *obj) +{ + int index = 0; + yajl_status rc; + + switch (obj->type) { + case JSON_NULL: + return yajl_gen_null(hand); + case JSON_BOOL: + return yajl_gen_bool(hand, obj->u.b); + case JSON_INTEGER: + return yajl_gen_integer(hand, obj->u.i); + case JSON_DOUBLE: + return yajl_gen_double(hand, obj->u.d); + case JSON_NUMBER: + return yajl_gen_number(hand, obj->u.string, strlen(obj->u.string)); + case JSON_STRING: + return libxl__yajl_gen_asciiz(hand, obj->u.string); + case JSON_MAP: { + libxl__json_map_node *node = NULL; + + rc = yajl_gen_map_open(hand); + if (rc != yajl_status_ok) + return rc; + for (index = 0; index < obj->u.map->count; index++) { + if (flexarray_get(obj->u.map, index, (void**)&node) != 0) + break; + + rc = libxl__yajl_gen_asciiz(hand, node->map_key); + if (rc != yajl_status_ok) + return rc; + rc = libxl__json_object_to_yajl_gen(gc, hand, node->obj); + if (rc != yajl_status_ok) + return rc; + } + return yajl_gen_map_close(hand); + } + case JSON_ARRAY: { + libxl__json_object *node = NULL; + + rc = yajl_gen_array_open(hand); + if (rc != yajl_status_ok) + return rc; + for (index = 0; index < obj->u.array->count; index++) { + if (flexarray_get(obj->u.array, index, (void**)&node) != 0) + break; + rc = libxl__json_object_to_yajl_gen(gc, hand, node); + if (rc != yajl_status_ok) + return rc; + } + return yajl_gen_array_close(hand); + } + case JSON_ANY: + /* JSON_ANY is not a valid value for obj->type. */ + ; + } + abort(); +} + /* * JSON callbacks -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:30:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:30:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8vI-0002S7-Ju; Fri, 05 Oct 2012 14:30:40 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8vH-0002RW-2L for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:30:39 +0000 Received: from [85.158.139.83:8374] by server-2.bemta-5.messagelabs.com id 95/25-28944-E0FEE605; Fri, 05 Oct 2012 14:30:38 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1349447434!26376259!3 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODA1MjM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31580 invoked from network); 5 Oct 2012 14:30:37 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:30:37 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="210421562" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 14:30:34 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 10:30:34 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK8vB-0006rc-Uw; Fri, 05 Oct 2012 15:30:33 +0100 From: Anthony PERARD To: Xen Devel Date: Fri, 5 Oct 2012 15:30:30 +0100 Message-ID: <1349447432-29511-9-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1349447432-29511-1-git-send-email-anthony.perard@citrix.com> References: <1349447432-29511-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Cc: Anthony PERARD , Ian Campbell Subject: [Xen-devel] [PATCH V4 08/10] libxl_qmp: Introduce libxl__qmp_set_global_dirty_log. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This function will enable or disable the global dirty log on QEMU, used during a migration. Signed-off-by: Anthony PERARD Acked-by: Ian Campbell --- tools/libxl/libxl_internal.h | 2 ++ tools/libxl/libxl_qmp.c | 12 ++++++++++-- 2 files changed, 12 insertions(+), 2 deletions(-) diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 04ca5a5..afa36a7 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -1404,6 +1404,8 @@ _hidden int libxl__qmp_stop(libxl__gc *gc, int domid); _hidden int libxl__qmp_resume(libxl__gc *gc, int domid); /* Save current QEMU state into fd. */ _hidden int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename); +/* Set dirty bitmap logging status */ +_hidden int libxl__qmp_set_global_dirty_log(libxl__gc *gc, int domid, bool enable); /* close and free the QMP handler */ _hidden void libxl__qmp_close(libxl__qmp_handler *qmp); /* remove the socket file, if the file has already been removed, diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c index 7bf56a7..5fa0c65 100644 --- a/tools/libxl/libxl_qmp.c +++ b/tools/libxl/libxl_qmp.c @@ -657,7 +657,6 @@ static void qmp_parameters_add_string(libxl__gc *gc, qmp_parameters_common_add(gc, param, name, obj); } -#if 0 static void qmp_parameters_add_bool(libxl__gc *gc, libxl__json_object **param, const char *name, bool b) @@ -668,7 +667,6 @@ static void qmp_parameters_add_bool(libxl__gc *gc, obj->u.b = b; qmp_parameters_common_add(gc, param, name, obj); } -#endif #define QMP_PARAMETERS_SPRINTF(args, name, format, ...) \ qmp_parameters_add_string(gc, args, name, \ @@ -905,6 +903,16 @@ int libxl__qmp_resume(libxl__gc *gc, int domid) return qmp_run_command(gc, domid, "cont", NULL, NULL, NULL); } +int libxl__qmp_set_global_dirty_log(libxl__gc *gc, int domid, bool enable) +{ + libxl__json_object *args = NULL; + + qmp_parameters_add_bool(gc, &args, "enable", enable); + + return qmp_run_command(gc, domid, "xen-set-global-dirty-log", args, + NULL, NULL); +} + int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid, const libxl_domain_config *guest_config) { -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:30:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:30:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8vN-0002Uj-B2; Fri, 05 Oct 2012 14:30:45 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8vM-0002RX-0H for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:30:44 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1349447434!7502915!3 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ1ODc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19132 invoked from network); 5 Oct 2012 14:30:37 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:30:37 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="40274558" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 14:30:34 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 10:30:34 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK8vB-0006rc-LQ; Fri, 05 Oct 2012 15:30:33 +0100 From: Anthony PERARD To: Xen Devel Date: Fri, 5 Oct 2012 15:30:23 +0100 Message-ID: <1349447432-29511-2-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1349447432-29511-1-git-send-email-anthony.perard@citrix.com> References: <1349447432-29511-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Cc: Anthony PERARD , Ian Campbell Subject: [Xen-devel] [PATCH V4 01/10] libxl_json: Export json_object related function. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Export libxl__json_object_alloc and libxl__json_object_append_to to use them in a later patch. Signed-off-by: Anthony PERARD --- tools/libxl/libxl_internal.h | 14 ++++++++++++-- tools/libxl/libxl_json.c | 34 +++++++++++++++++----------------- 2 files changed, 29 insertions(+), 19 deletions(-) diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index c0e879d..cdf5300 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -1516,6 +1516,15 @@ static inline long long libxl__json_object_get_integer(const libxl__json_object return -1; } +/* + * NOGC can be used with those json_object functions, but the + * libxl__json_object* will need to be freed with libxl__json_object_free. + */ +_hidden libxl__json_object *libxl__json_object_alloc(libxl__gc *gc_opt, + libxl__json_node_type type); +_hidden int libxl__json_object_append_to(libxl__gc *gc_opt, + libxl__json_object *obj, + libxl__json_object *dst); _hidden libxl__json_object *libxl__json_array_get(const libxl__json_object *o, int i); _hidden @@ -1524,9 +1533,10 @@ libxl__json_map_node *libxl__json_map_node_get(const libxl__json_object *o, _hidden const libxl__json_object *libxl__json_map_get(const char *key, const libxl__json_object *o, libxl__json_node_type expected_type); -_hidden void libxl__json_object_free(libxl__gc *gc, libxl__json_object *obj); +_hidden void libxl__json_object_free(libxl__gc *gc_opt, + libxl__json_object *obj); -_hidden libxl__json_object *libxl__json_parse(libxl__gc *gc, const char *s); +_hidden libxl__json_object *libxl__json_parse(libxl__gc *gc_opt, const char *s); /* Based on /local/domain/$domid/dm-version xenstore key * default is qemu xen traditional */ diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c index 3cba48f..a045594 100644 --- a/tools/libxl/libxl_json.c +++ b/tools/libxl/libxl_json.c @@ -205,7 +205,7 @@ yajl_gen_status libxl__string_gen_json(yajl_gen hand, * libxl__json_object helper functions */ -static libxl__json_object *json_object_alloc(libxl__gc *gc, +libxl__json_object *libxl__json_object_alloc(libxl__gc *gc, libxl__json_node_type type) { libxl__json_object *obj; @@ -225,7 +225,7 @@ static libxl__json_object *json_object_alloc(libxl__gc *gc, return obj; } -static int json_object_append_to(libxl__gc *gc, +int libxl__json_object_append_to(libxl__gc *gc, libxl__json_object *obj, libxl__json_object *dst) { @@ -378,9 +378,9 @@ static int json_callback_null(void *opaque) DEBUG_GEN(ctx, null); - obj = json_object_alloc(ctx->gc, JSON_NULL); + obj = libxl__json_object_alloc(ctx->gc, JSON_NULL); - if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { + if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) { return 0; } @@ -394,10 +394,10 @@ static int json_callback_boolean(void *opaque, int boolean) DEBUG_GEN_VALUE(ctx, bool, boolean); - obj = json_object_alloc(ctx->gc, - boolean ? JSON_TRUE : JSON_FALSE); + obj = libxl__json_object_alloc(ctx->gc, + boolean ? JSON_TRUE : JSON_FALSE); - if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { + if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) { return 0; } @@ -429,7 +429,7 @@ static int json_callback_number(void *opaque, const char *s, libxl_yajl_length l goto error; } - obj = json_object_alloc(ctx->gc, JSON_DOUBLE); + obj = libxl__json_object_alloc(ctx->gc, JSON_DOUBLE); obj->u.d = d; } else { long long i = strtoll(s, NULL, 10); @@ -438,14 +438,14 @@ static int json_callback_number(void *opaque, const char *s, libxl_yajl_length l goto error; } - obj = json_object_alloc(ctx->gc, JSON_INTEGER); + obj = libxl__json_object_alloc(ctx->gc, JSON_INTEGER); obj->u.i = i; } goto out; error: /* If the conversion fail, we just store the original string. */ - obj = json_object_alloc(ctx->gc, JSON_NUMBER); + obj = libxl__json_object_alloc(ctx->gc, JSON_NUMBER); t = libxl__zalloc(ctx->gc, len + 1); strncpy(t, s, len); @@ -454,7 +454,7 @@ error: obj->u.string = t; out: - if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { + if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) { return 0; } @@ -475,10 +475,10 @@ static int json_callback_string(void *opaque, const unsigned char *str, strncpy(t, (const char *) str, len); t[len] = 0; - obj = json_object_alloc(ctx->gc, JSON_STRING); + obj = libxl__json_object_alloc(ctx->gc, JSON_STRING); obj->u.string = t; - if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { + if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) { return 0; } @@ -524,10 +524,10 @@ static int json_callback_start_map(void *opaque) DEBUG_GEN(ctx, map_open); - obj = json_object_alloc(ctx->gc, JSON_MAP); + obj = libxl__json_object_alloc(ctx->gc, JSON_MAP); if (ctx->current) { - if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { + if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) { return 0; } } @@ -564,10 +564,10 @@ static int json_callback_start_array(void *opaque) DEBUG_GEN(ctx, array_open); - obj = json_object_alloc(ctx->gc, JSON_ARRAY); + obj = libxl__json_object_alloc(ctx->gc, JSON_ARRAY); if (ctx->current) { - if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { + if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) { return 0; } } -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:30:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:30:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8vN-0002Uj-B2; Fri, 05 Oct 2012 14:30:45 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8vM-0002RX-0H for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:30:44 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1349447434!7502915!3 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ1ODc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19132 invoked from network); 5 Oct 2012 14:30:37 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:30:37 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="40274558" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 14:30:34 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 10:30:34 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK8vB-0006rc-LQ; Fri, 05 Oct 2012 15:30:33 +0100 From: Anthony PERARD To: Xen Devel Date: Fri, 5 Oct 2012 15:30:23 +0100 Message-ID: <1349447432-29511-2-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1349447432-29511-1-git-send-email-anthony.perard@citrix.com> References: <1349447432-29511-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Cc: Anthony PERARD , Ian Campbell Subject: [Xen-devel] [PATCH V4 01/10] libxl_json: Export json_object related function. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Export libxl__json_object_alloc and libxl__json_object_append_to to use them in a later patch. Signed-off-by: Anthony PERARD --- tools/libxl/libxl_internal.h | 14 ++++++++++++-- tools/libxl/libxl_json.c | 34 +++++++++++++++++----------------- 2 files changed, 29 insertions(+), 19 deletions(-) diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index c0e879d..cdf5300 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -1516,6 +1516,15 @@ static inline long long libxl__json_object_get_integer(const libxl__json_object return -1; } +/* + * NOGC can be used with those json_object functions, but the + * libxl__json_object* will need to be freed with libxl__json_object_free. + */ +_hidden libxl__json_object *libxl__json_object_alloc(libxl__gc *gc_opt, + libxl__json_node_type type); +_hidden int libxl__json_object_append_to(libxl__gc *gc_opt, + libxl__json_object *obj, + libxl__json_object *dst); _hidden libxl__json_object *libxl__json_array_get(const libxl__json_object *o, int i); _hidden @@ -1524,9 +1533,10 @@ libxl__json_map_node *libxl__json_map_node_get(const libxl__json_object *o, _hidden const libxl__json_object *libxl__json_map_get(const char *key, const libxl__json_object *o, libxl__json_node_type expected_type); -_hidden void libxl__json_object_free(libxl__gc *gc, libxl__json_object *obj); +_hidden void libxl__json_object_free(libxl__gc *gc_opt, + libxl__json_object *obj); -_hidden libxl__json_object *libxl__json_parse(libxl__gc *gc, const char *s); +_hidden libxl__json_object *libxl__json_parse(libxl__gc *gc_opt, const char *s); /* Based on /local/domain/$domid/dm-version xenstore key * default is qemu xen traditional */ diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c index 3cba48f..a045594 100644 --- a/tools/libxl/libxl_json.c +++ b/tools/libxl/libxl_json.c @@ -205,7 +205,7 @@ yajl_gen_status libxl__string_gen_json(yajl_gen hand, * libxl__json_object helper functions */ -static libxl__json_object *json_object_alloc(libxl__gc *gc, +libxl__json_object *libxl__json_object_alloc(libxl__gc *gc, libxl__json_node_type type) { libxl__json_object *obj; @@ -225,7 +225,7 @@ static libxl__json_object *json_object_alloc(libxl__gc *gc, return obj; } -static int json_object_append_to(libxl__gc *gc, +int libxl__json_object_append_to(libxl__gc *gc, libxl__json_object *obj, libxl__json_object *dst) { @@ -378,9 +378,9 @@ static int json_callback_null(void *opaque) DEBUG_GEN(ctx, null); - obj = json_object_alloc(ctx->gc, JSON_NULL); + obj = libxl__json_object_alloc(ctx->gc, JSON_NULL); - if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { + if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) { return 0; } @@ -394,10 +394,10 @@ static int json_callback_boolean(void *opaque, int boolean) DEBUG_GEN_VALUE(ctx, bool, boolean); - obj = json_object_alloc(ctx->gc, - boolean ? JSON_TRUE : JSON_FALSE); + obj = libxl__json_object_alloc(ctx->gc, + boolean ? JSON_TRUE : JSON_FALSE); - if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { + if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) { return 0; } @@ -429,7 +429,7 @@ static int json_callback_number(void *opaque, const char *s, libxl_yajl_length l goto error; } - obj = json_object_alloc(ctx->gc, JSON_DOUBLE); + obj = libxl__json_object_alloc(ctx->gc, JSON_DOUBLE); obj->u.d = d; } else { long long i = strtoll(s, NULL, 10); @@ -438,14 +438,14 @@ static int json_callback_number(void *opaque, const char *s, libxl_yajl_length l goto error; } - obj = json_object_alloc(ctx->gc, JSON_INTEGER); + obj = libxl__json_object_alloc(ctx->gc, JSON_INTEGER); obj->u.i = i; } goto out; error: /* If the conversion fail, we just store the original string. */ - obj = json_object_alloc(ctx->gc, JSON_NUMBER); + obj = libxl__json_object_alloc(ctx->gc, JSON_NUMBER); t = libxl__zalloc(ctx->gc, len + 1); strncpy(t, s, len); @@ -454,7 +454,7 @@ error: obj->u.string = t; out: - if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { + if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) { return 0; } @@ -475,10 +475,10 @@ static int json_callback_string(void *opaque, const unsigned char *str, strncpy(t, (const char *) str, len); t[len] = 0; - obj = json_object_alloc(ctx->gc, JSON_STRING); + obj = libxl__json_object_alloc(ctx->gc, JSON_STRING); obj->u.string = t; - if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { + if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) { return 0; } @@ -524,10 +524,10 @@ static int json_callback_start_map(void *opaque) DEBUG_GEN(ctx, map_open); - obj = json_object_alloc(ctx->gc, JSON_MAP); + obj = libxl__json_object_alloc(ctx->gc, JSON_MAP); if (ctx->current) { - if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { + if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) { return 0; } } @@ -564,10 +564,10 @@ static int json_callback_start_array(void *opaque) DEBUG_GEN(ctx, array_open); - obj = json_object_alloc(ctx->gc, JSON_ARRAY); + obj = libxl__json_object_alloc(ctx->gc, JSON_ARRAY); if (ctx->current) { - if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) { + if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) { return 0; } } -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:30:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:30:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8vJ-0002SU-6E; Fri, 05 Oct 2012 14:30:41 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8vH-0002Re-PH for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:30:39 +0000 Received: from [85.158.139.83:11771] by server-13.bemta-5.messagelabs.com id 6E/E2-06496-E0FEE605; Fri, 05 Oct 2012 14:30:38 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1349447434!26376259!4 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODA1MjM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31683 invoked from network); 5 Oct 2012 14:30:38 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:30:38 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="210421564" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 14:30:34 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 10:30:34 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK8vC-0006rc-0D; Fri, 05 Oct 2012 15:30:34 +0100 From: Anthony PERARD To: Xen Devel Date: Fri, 5 Oct 2012 15:30:31 +0100 Message-ID: <1349447432-29511-10-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1349447432-29511-1-git-send-email-anthony.perard@citrix.com> References: <1349447432-29511-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Cc: Anthony PERARD , Ian Campbell Subject: [Xen-devel] [PATCH V4 09/10] libxl_dom: Call the right switch logdirty for the right DM. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch dispatch the switch logdirty call depending on which device model version is running. The call to qemu-xen right now is synchronous, not like the one to qemu-xen-traditional. Signed-off-by: Anthony PERARD Acked-by: Ian Campbell --- tools/libxl/libxl_dom.c | 45 ++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 42 insertions(+), 3 deletions(-) diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c index e1de832..95da18e 100644 --- a/tools/libxl/libxl_dom.c +++ b/tools/libxl/libxl_dom.c @@ -685,10 +685,10 @@ static void logdirty_init(libxl__logdirty_switch *lds) libxl__ev_time_init(&lds->timeout); } -void libxl__domain_suspend_common_switch_qemu_logdirty - (int domid, unsigned enable, void *user) +static void domain_suspend_switch_qemu_xen_traditional_logdirty + (int domid, unsigned enable, + libxl__save_helper_state *shs) { - libxl__save_helper_state *shs = user; libxl__egc *egc = shs->egc; libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs); libxl__logdirty_switch *lds = &dss->logdirty; @@ -756,6 +756,45 @@ void libxl__domain_suspend_common_switch_qemu_logdirty switch_logdirty_done(egc,dss,-1); } +static void domain_suspend_switch_qemu_xen_logdirty + (int domid, unsigned enable, + libxl__save_helper_state *shs) +{ + libxl__egc *egc = shs->egc; + libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs); + STATE_AO_GC(dss->ao); + int rc; + + rc = libxl__qmp_set_global_dirty_log(gc, domid, enable); + if (!rc) { + libxl__xc_domain_saverestore_async_callback_done(egc, shs, 0); + } else { + LOG(ERROR,"logdirty switch failed (rc=%d), aborting suspend",rc); + libxl__xc_domain_saverestore_async_callback_done(egc, shs, -1); + } +} + +void libxl__domain_suspend_common_switch_qemu_logdirty + (int domid, unsigned enable, void *user) +{ + libxl__save_helper_state *shs = user; + libxl__egc *egc = shs->egc; + libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs); + STATE_AO_GC(dss->ao); + + switch (libxl__device_model_version_running(gc, domid)) { + case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: + domain_suspend_switch_qemu_xen_traditional_logdirty(domid, enable, shs); + break; + case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN: + domain_suspend_switch_qemu_xen_logdirty(domid, enable, shs); + break; + default: + LOG(ERROR,"logdirty switch failed" + ", no valid device model version found, aborting suspend"); + libxl__xc_domain_saverestore_async_callback_done(egc, shs, -1); + } +} static void switch_logdirty_timeout(libxl__egc *egc, libxl__ev_time *ev, const struct timeval *requested_abs) { -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:30:54 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:30:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8vJ-0002SU-6E; Fri, 05 Oct 2012 14:30:41 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8vH-0002Re-PH for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:30:39 +0000 Received: from [85.158.139.83:11771] by server-13.bemta-5.messagelabs.com id 6E/E2-06496-E0FEE605; Fri, 05 Oct 2012 14:30:38 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1349447434!26376259!4 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODA1MjM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31683 invoked from network); 5 Oct 2012 14:30:38 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:30:38 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="210421564" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 14:30:34 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 10:30:34 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK8vC-0006rc-0D; Fri, 05 Oct 2012 15:30:34 +0100 From: Anthony PERARD To: Xen Devel Date: Fri, 5 Oct 2012 15:30:31 +0100 Message-ID: <1349447432-29511-10-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1349447432-29511-1-git-send-email-anthony.perard@citrix.com> References: <1349447432-29511-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Cc: Anthony PERARD , Ian Campbell Subject: [Xen-devel] [PATCH V4 09/10] libxl_dom: Call the right switch logdirty for the right DM. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch dispatch the switch logdirty call depending on which device model version is running. The call to qemu-xen right now is synchronous, not like the one to qemu-xen-traditional. Signed-off-by: Anthony PERARD Acked-by: Ian Campbell --- tools/libxl/libxl_dom.c | 45 ++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 42 insertions(+), 3 deletions(-) diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c index e1de832..95da18e 100644 --- a/tools/libxl/libxl_dom.c +++ b/tools/libxl/libxl_dom.c @@ -685,10 +685,10 @@ static void logdirty_init(libxl__logdirty_switch *lds) libxl__ev_time_init(&lds->timeout); } -void libxl__domain_suspend_common_switch_qemu_logdirty - (int domid, unsigned enable, void *user) +static void domain_suspend_switch_qemu_xen_traditional_logdirty + (int domid, unsigned enable, + libxl__save_helper_state *shs) { - libxl__save_helper_state *shs = user; libxl__egc *egc = shs->egc; libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs); libxl__logdirty_switch *lds = &dss->logdirty; @@ -756,6 +756,45 @@ void libxl__domain_suspend_common_switch_qemu_logdirty switch_logdirty_done(egc,dss,-1); } +static void domain_suspend_switch_qemu_xen_logdirty + (int domid, unsigned enable, + libxl__save_helper_state *shs) +{ + libxl__egc *egc = shs->egc; + libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs); + STATE_AO_GC(dss->ao); + int rc; + + rc = libxl__qmp_set_global_dirty_log(gc, domid, enable); + if (!rc) { + libxl__xc_domain_saverestore_async_callback_done(egc, shs, 0); + } else { + LOG(ERROR,"logdirty switch failed (rc=%d), aborting suspend",rc); + libxl__xc_domain_saverestore_async_callback_done(egc, shs, -1); + } +} + +void libxl__domain_suspend_common_switch_qemu_logdirty + (int domid, unsigned enable, void *user) +{ + libxl__save_helper_state *shs = user; + libxl__egc *egc = shs->egc; + libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs); + STATE_AO_GC(dss->ao); + + switch (libxl__device_model_version_running(gc, domid)) { + case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: + domain_suspend_switch_qemu_xen_traditional_logdirty(domid, enable, shs); + break; + case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN: + domain_suspend_switch_qemu_xen_logdirty(domid, enable, shs); + break; + default: + LOG(ERROR,"logdirty switch failed" + ", no valid device model version found, aborting suspend"); + libxl__xc_domain_saverestore_async_callback_done(egc, shs, -1); + } +} static void switch_logdirty_timeout(libxl__egc *egc, libxl__ev_time *ev, const struct timeval *requested_abs) { -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:33:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:33:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8y8-0003Yt-Ff; Fri, 05 Oct 2012 14:33:36 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8y7-0003XW-1a for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:33:35 +0000 X-Env-Sender: raistlin.df@gmail.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1349447608!6616499!1 X-Originating-IP: [209.85.212.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16851 invoked from network); 5 Oct 2012 14:33:29 -0000 Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com) (209.85.212.173) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:33:29 -0000 Received: by mail-wi0-f173.google.com with SMTP id hm4so623721wib.14 for ; Fri, 05 Oct 2012 07:33:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:subject:from:to:cc:date:in-reply-to:references :content-type:x-mailer:mime-version; bh=wVnaS1xRlpNh4GniZkaz4qwu7SWDPTJ5uy8qkGJIFBY=; b=i/J1n6QkhfGdOYfWMqcV+LBQF36ifQO5X848aTpVfSb6QihP7pgEqB+z0On9MV2FTY 9asyp1MYkXIu9nvoij/tfJOp4XbtyEe4XtBYeoBwfIT+x03TPhvQjpHtgH/5mSwX5TLz B+rxfG5H6PBQ6kyt3zeKfPwz5FpqolaaUsHQrDBASkI8LNuQO+pbbixZVRNx+hQd/76W qlPb6Ua3faD5rXFDpLugLkMpgC40+Uz318w3Z+fYGoUJpybVD64pruIYGSWy9RD6Mv+z Yi49N8Q49S+2KMgpVsUSr9jUyUG9z0gpoZwdjBzTfysce8791kQB5iRROP5jiJF6U1fj 7z6w== Received: by 10.216.197.104 with SMTP id s82mr5234161wen.62.1349447608740; Fri, 05 Oct 2012 07:33:28 -0700 (PDT) Received: from [192.168.0.40] (ip-170-24.sn3.eutelia.it. [213.136.170.24]) by mx.google.com with ESMTPS id v3sm2654727wiw.7.2012.10.05.07.33.26 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Oct 2012 07:33:27 -0700 (PDT) Message-ID: <1349447600.18984.18.camel@Solace> From: Dario Faggioli To: George Dunlap Date: Fri, 05 Oct 2012 16:33:20 +0200 In-Reply-To: References: X-Mailer: Evolution 3.4.3-1 Mime-Version: 1.0 Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.3 development update X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2626531756329080676==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============2626531756329080676== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-IK5yjHEc+sns8j4QdcQk" --=-IK5yjHEc+sns8j4QdcQk Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2012-09-19 at 17:58 +0100, George Dunlap wrote: > =3D Feature tracking =3D >=20 > Below is a list of features we're tracking for this release. Please > respond to this mail with any updates to the status. If the status > is "?", as most of them are, please respond with the status! Example > statuses include "not started", "in progress", "initial implementation > submitted for review", "patches submitted". > > ... > * NUMA scheduler affinity > critical > owner: dario@citrix > status: ? >=20 Patches sent. Waiting for review. > * NUMA Memory migration > owner: dario@citrix > status: ? >=20 Work starting in the upcoming weeks. Thanks and Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-IK5yjHEc+sns8j4QdcQk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAlBu77AACgkQk4XaBE3IOsQ43gCgmfJGO9rrGd0/BtmQ0o7dBPJO l4cAn010k6i8q2qJ3TYcIYzzsfk54Vop =UicH -----END PGP SIGNATURE----- --=-IK5yjHEc+sns8j4QdcQk-- --===============2626531756329080676== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============2626531756329080676==-- From xen-devel-bounces@lists.xen.org Fri Oct 05 14:33:41 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:33:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8y8-0003Yt-Ff; Fri, 05 Oct 2012 14:33:36 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8y7-0003XW-1a for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:33:35 +0000 X-Env-Sender: raistlin.df@gmail.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1349447608!6616499!1 X-Originating-IP: [209.85.212.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16851 invoked from network); 5 Oct 2012 14:33:29 -0000 Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com) (209.85.212.173) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:33:29 -0000 Received: by mail-wi0-f173.google.com with SMTP id hm4so623721wib.14 for ; Fri, 05 Oct 2012 07:33:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:subject:from:to:cc:date:in-reply-to:references :content-type:x-mailer:mime-version; bh=wVnaS1xRlpNh4GniZkaz4qwu7SWDPTJ5uy8qkGJIFBY=; b=i/J1n6QkhfGdOYfWMqcV+LBQF36ifQO5X848aTpVfSb6QihP7pgEqB+z0On9MV2FTY 9asyp1MYkXIu9nvoij/tfJOp4XbtyEe4XtBYeoBwfIT+x03TPhvQjpHtgH/5mSwX5TLz B+rxfG5H6PBQ6kyt3zeKfPwz5FpqolaaUsHQrDBASkI8LNuQO+pbbixZVRNx+hQd/76W qlPb6Ua3faD5rXFDpLugLkMpgC40+Uz318w3Z+fYGoUJpybVD64pruIYGSWy9RD6Mv+z Yi49N8Q49S+2KMgpVsUSr9jUyUG9z0gpoZwdjBzTfysce8791kQB5iRROP5jiJF6U1fj 7z6w== Received: by 10.216.197.104 with SMTP id s82mr5234161wen.62.1349447608740; Fri, 05 Oct 2012 07:33:28 -0700 (PDT) Received: from [192.168.0.40] (ip-170-24.sn3.eutelia.it. [213.136.170.24]) by mx.google.com with ESMTPS id v3sm2654727wiw.7.2012.10.05.07.33.26 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Oct 2012 07:33:27 -0700 (PDT) Message-ID: <1349447600.18984.18.camel@Solace> From: Dario Faggioli To: George Dunlap Date: Fri, 05 Oct 2012 16:33:20 +0200 In-Reply-To: References: X-Mailer: Evolution 3.4.3-1 Mime-Version: 1.0 Cc: xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.3 development update X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2626531756329080676==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============2626531756329080676== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-IK5yjHEc+sns8j4QdcQk" --=-IK5yjHEc+sns8j4QdcQk Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2012-09-19 at 17:58 +0100, George Dunlap wrote: > =3D Feature tracking =3D >=20 > Below is a list of features we're tracking for this release. Please > respond to this mail with any updates to the status. If the status > is "?", as most of them are, please respond with the status! Example > statuses include "not started", "in progress", "initial implementation > submitted for review", "patches submitted". > > ... > * NUMA scheduler affinity > critical > owner: dario@citrix > status: ? >=20 Patches sent. Waiting for review. > * NUMA Memory migration > owner: dario@citrix > status: ? >=20 Work starting in the upcoming weeks. Thanks and Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-IK5yjHEc+sns8j4QdcQk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAlBu77AACgkQk4XaBE3IOsQ43gCgmfJGO9rrGd0/BtmQ0o7dBPJO l4cAn010k6i8q2qJ3TYcIYzzsfk54Vop =UicH -----END PGP SIGNATURE----- --=-IK5yjHEc+sns8j4QdcQk-- --===============2626531756329080676== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============2626531756329080676==-- From xen-devel-bounces@lists.xen.org Fri Oct 05 14:34:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:34:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8yQ-0003ew-Ur; Fri, 05 Oct 2012 14:33:54 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8yP-0003cX-Df for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:33:53 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1349447626!6616545!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18197 invoked from network); 5 Oct 2012 14:33:47 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:33:47 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14966489" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 14:33:46 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 15:33:46 +0100 Message-ID: <1349447625.20946.130.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Fri, 5 Oct 2012 15:33:45 +0100 In-Reply-To: References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-5-git-send-email-ian.campbell@citrix.com> <1349440338.20946.83.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 05/14] xen: balloon: use correct type for frame_list X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-10-05 at 15:02 +0100, Stefano Stabellini wrote: > On Fri, 5 Oct 2012, Ian Campbell wrote: > > On Fri, 2012-10-05 at 12:48 +0100, Stefano Stabellini wrote: > > > On Thu, 4 Oct 2012, Ian Campbell wrote: > > > > This is now a xen_pfn_t. > > > > > > > > Signed-off-by: Ian Campbell > > > > --- > > > > drivers/xen/balloon.c | 2 +- > > > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > > > > > diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c > > > > index 85ef7e7..4625560 100644 > > > > --- a/drivers/xen/balloon.c > > > > +++ b/drivers/xen/balloon.c > > > > @@ -87,7 +87,7 @@ struct balloon_stats balloon_stats; > > > > EXPORT_SYMBOL_GPL(balloon_stats); > > > > > > > > /* We increase/decrease in batches which fit in a page */ > > > > -static unsigned long frame_list[PAGE_SIZE / sizeof(unsigned long)]; > > > > +static xen_pfn_t frame_list[PAGE_SIZE / sizeof(unsigned long)]; > > > > > > > > #ifdef CONFIG_HIGHMEM > > > > #define inc_totalhigh_pages() (totalhigh_pages++) > > > > > > While I think is a good change, frame_list[i] is used as an argument to > > > set_phys_to_machine, that takes an unsigned long. Also unsigned long are > > > assigned to members of the array via page_to_pfn. > > > I think that we should take care of these cases, either introducing > > > explicit casts or changing the argument types. > > > > frame_list is used at the Xen interface, and so the pfn type has to be > > sized for the largest pfn the hypervisor will use (aka xen_pfn_t). Those > > unsigned longs are really "linux_pfn_t", that is they are the size of > > the largest pfn the guest is itself prepared to deal with. > > > > So long as sizeof(unsigned long) <= sizeof(xen_pfn_t) (which it is) then > > we are ok. > > I think that we are playing with fire here. > > Let's imaging a future where physical addresses are actually 64 bit. > Let's imaging that Xen is supporting them perfectly fine and returns to > this balloon driver a pfn > ULONG_MAX (already possible on ARM). It might give us an *mfn* larger than ULONG_MAX but the guest would never see that, because ARM guests (and x86 PVHVM, PVH ones etc) never see real mfns, they are hypervisor internal with HAP and the interfaces are all in terms of pfns. The issue you describe could only happen for a 32 bit HAP guest if the guests was given > 16GB (2^(32+PAGE_SHIFT) bytes) of RAM and it was explicitly trying to balloon memory over that limit, but in order for that to even be possible it would already need to have made its concept of a pfn larger than 32 bits. In theory there might be a problem for a PV guest, but in the only case which matters: arch/x86/include/asm/xen/interface.h:typedef unsigned long xen_pfn_t; and furthermore 32 bit PV guests are limited to 160G of MFN space (which is less than 2^32) for other reasons already. > That is a perfectly valid value for Xen to give us and we should be able > to handle it. If we are not we should return an error. > With this change we would trimmer the pfn returned by Xen to 32 bit so we > would actually have an incorrect behaviour instead. > > If we assume sizeof(unsigned long) <= sizeof(xen_pfn_t), we only need a > macro like this: > > #define LINUX_PFN_MAX ULONG_MAX > #define linux_pfn_t unsigned long > #define xen_pfn_to_linux_pfn(pfn) ({BUG_ON(pfn > LINUX_PFN_MAX); (linux_pfn_t)pfn;}) > > that is called in the right places. > > > > If and when Linux wants to use pfn's which are not unsigned longs then > > the uses of unsigned long will need to be audited (globally, not just > > here) to become whatever type Linux then defines to contain a pfn. In > > the absence of that type being defined in the core Linux code I think it > > is correct for us to keep using unsigned long in those contexts. > > I think is OK using unsigned long for linux_pfn, the problem is the > conversion between what Xen gives us and linux_pfns. Xen never gives us PFNs, they are always the guest's choice. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:34:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:34:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8yQ-0003ew-Ur; Fri, 05 Oct 2012 14:33:54 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8yP-0003cX-Df for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:33:53 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1349447626!6616545!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18197 invoked from network); 5 Oct 2012 14:33:47 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:33:47 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14966489" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 14:33:46 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 15:33:46 +0100 Message-ID: <1349447625.20946.130.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Fri, 5 Oct 2012 15:33:45 +0100 In-Reply-To: References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-5-git-send-email-ian.campbell@citrix.com> <1349440338.20946.83.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 05/14] xen: balloon: use correct type for frame_list X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-10-05 at 15:02 +0100, Stefano Stabellini wrote: > On Fri, 5 Oct 2012, Ian Campbell wrote: > > On Fri, 2012-10-05 at 12:48 +0100, Stefano Stabellini wrote: > > > On Thu, 4 Oct 2012, Ian Campbell wrote: > > > > This is now a xen_pfn_t. > > > > > > > > Signed-off-by: Ian Campbell > > > > --- > > > > drivers/xen/balloon.c | 2 +- > > > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > > > > > diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c > > > > index 85ef7e7..4625560 100644 > > > > --- a/drivers/xen/balloon.c > > > > +++ b/drivers/xen/balloon.c > > > > @@ -87,7 +87,7 @@ struct balloon_stats balloon_stats; > > > > EXPORT_SYMBOL_GPL(balloon_stats); > > > > > > > > /* We increase/decrease in batches which fit in a page */ > > > > -static unsigned long frame_list[PAGE_SIZE / sizeof(unsigned long)]; > > > > +static xen_pfn_t frame_list[PAGE_SIZE / sizeof(unsigned long)]; > > > > > > > > #ifdef CONFIG_HIGHMEM > > > > #define inc_totalhigh_pages() (totalhigh_pages++) > > > > > > While I think is a good change, frame_list[i] is used as an argument to > > > set_phys_to_machine, that takes an unsigned long. Also unsigned long are > > > assigned to members of the array via page_to_pfn. > > > I think that we should take care of these cases, either introducing > > > explicit casts or changing the argument types. > > > > frame_list is used at the Xen interface, and so the pfn type has to be > > sized for the largest pfn the hypervisor will use (aka xen_pfn_t). Those > > unsigned longs are really "linux_pfn_t", that is they are the size of > > the largest pfn the guest is itself prepared to deal with. > > > > So long as sizeof(unsigned long) <= sizeof(xen_pfn_t) (which it is) then > > we are ok. > > I think that we are playing with fire here. > > Let's imaging a future where physical addresses are actually 64 bit. > Let's imaging that Xen is supporting them perfectly fine and returns to > this balloon driver a pfn > ULONG_MAX (already possible on ARM). It might give us an *mfn* larger than ULONG_MAX but the guest would never see that, because ARM guests (and x86 PVHVM, PVH ones etc) never see real mfns, they are hypervisor internal with HAP and the interfaces are all in terms of pfns. The issue you describe could only happen for a 32 bit HAP guest if the guests was given > 16GB (2^(32+PAGE_SHIFT) bytes) of RAM and it was explicitly trying to balloon memory over that limit, but in order for that to even be possible it would already need to have made its concept of a pfn larger than 32 bits. In theory there might be a problem for a PV guest, but in the only case which matters: arch/x86/include/asm/xen/interface.h:typedef unsigned long xen_pfn_t; and furthermore 32 bit PV guests are limited to 160G of MFN space (which is less than 2^32) for other reasons already. > That is a perfectly valid value for Xen to give us and we should be able > to handle it. If we are not we should return an error. > With this change we would trimmer the pfn returned by Xen to 32 bit so we > would actually have an incorrect behaviour instead. > > If we assume sizeof(unsigned long) <= sizeof(xen_pfn_t), we only need a > macro like this: > > #define LINUX_PFN_MAX ULONG_MAX > #define linux_pfn_t unsigned long > #define xen_pfn_to_linux_pfn(pfn) ({BUG_ON(pfn > LINUX_PFN_MAX); (linux_pfn_t)pfn;}) > > that is called in the right places. > > > > If and when Linux wants to use pfn's which are not unsigned longs then > > the uses of unsigned long will need to be audited (globally, not just > > here) to become whatever type Linux then defines to contain a pfn. In > > the absence of that type being defined in the core Linux code I think it > > is correct for us to keep using unsigned long in those contexts. > > I think is OK using unsigned long for linux_pfn, the problem is the > conversion between what Xen gives us and linux_pfns. Xen never gives us PFNs, they are always the guest's choice. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:35:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:35:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8ze-0003yW-Dn; Fri, 05 Oct 2012 14:35:10 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8zd-0003y9-0Y for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:35:09 +0000 Received: from [85.158.137.99:43707] by server-2.bemta-3.messagelabs.com id F1/D7-16514-C10FE605; Fri, 05 Oct 2012 14:35:08 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-5.tower-217.messagelabs.com!1349447706!15688383!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27999 invoked from network); 5 Oct 2012 14:35:06 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:35:06 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14966521" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 14:35:05 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 15:35:05 +0100 Message-ID: <1349447704.20946.131.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Fri, 5 Oct 2012 15:35:04 +0100 In-Reply-To: References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-8-git-send-email-ian.campbell@citrix.com> <1349443982.20946.100.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 08/14] xen: balloon: allow PVMMU interfaces to be compiled out X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-10-05 at 15:04 +0100, Stefano Stabellini wrote: > On Fri, 5 Oct 2012, Ian Campbell wrote: > > On Fri, 2012-10-05 at 14:19 +0100, Stefano Stabellini wrote: > > > On Thu, 4 Oct 2012, Ian Campbell wrote: > > > > The ARM platform has no concept of PVMMU and therefor no > > > > HYPERVISOR_update_va_mapping et al. Allow this code to be compiled out > > > > when not required. > > > > > > > > Signed-off-by: Ian Campbell > > > > > > I am unsure whether it is worth a new symbol and two ifdef's > > > > ARM doesn't compile without it, since HYPERVISOR_update_va_mapping > > doesn't exist. Do you have a preferable alternative? > > > > I'm not sure how much more of this sort of thing there will be as we > > enable more features on the ARM port. > > #define HYPERVISOR_update_va_mapping(va, new_val, flags) (0) This would mean we need to start defining things like mfn_pte() and __pte_ma() too though, I think. How far do we want to take that? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:35:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:35:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8ze-0003yW-Dn; Fri, 05 Oct 2012 14:35:10 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK8zd-0003y9-0Y for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:35:09 +0000 Received: from [85.158.137.99:43707] by server-2.bemta-3.messagelabs.com id F1/D7-16514-C10FE605; Fri, 05 Oct 2012 14:35:08 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-5.tower-217.messagelabs.com!1349447706!15688383!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27999 invoked from network); 5 Oct 2012 14:35:06 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:35:06 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14966521" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 14:35:05 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 15:35:05 +0100 Message-ID: <1349447704.20946.131.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Fri, 5 Oct 2012 15:35:04 +0100 In-Reply-To: References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-8-git-send-email-ian.campbell@citrix.com> <1349443982.20946.100.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 08/14] xen: balloon: allow PVMMU interfaces to be compiled out X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-10-05 at 15:04 +0100, Stefano Stabellini wrote: > On Fri, 5 Oct 2012, Ian Campbell wrote: > > On Fri, 2012-10-05 at 14:19 +0100, Stefano Stabellini wrote: > > > On Thu, 4 Oct 2012, Ian Campbell wrote: > > > > The ARM platform has no concept of PVMMU and therefor no > > > > HYPERVISOR_update_va_mapping et al. Allow this code to be compiled out > > > > when not required. > > > > > > > > Signed-off-by: Ian Campbell > > > > > > I am unsure whether it is worth a new symbol and two ifdef's > > > > ARM doesn't compile without it, since HYPERVISOR_update_va_mapping > > doesn't exist. Do you have a preferable alternative? > > > > I'm not sure how much more of this sort of thing there will be as we > > enable more features on the ARM port. > > #define HYPERVISOR_update_va_mapping(va, new_val, flags) (0) This would mean we need to start defining things like mfn_pte() and __pte_ma() too though, I think. How far do we want to take that? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:38:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:38:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK92G-0004Og-BF; Fri, 05 Oct 2012 14:37:52 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK92E-0004Nv-Oh for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:37:50 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1349447863!4302786!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24042 invoked from network); 5 Oct 2012 14:37:44 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:37:44 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14966570" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 14:37:43 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 15:37:44 +0100 Message-ID: <1349447862.20946.133.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Matthew Fioravante Date: Fri, 5 Oct 2012 15:37:42 +0100 In-Reply-To: <1349188052-15639-1-git-send-email-matthew.fioravante@jhuapl.edu> References: <1349188052-15639-1-git-send-email-matthew.fioravante@jhuapl.edu> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "samuel.thibault@ens-lyon.org" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 01/12] Add ioread/iowrite functions to mini-os X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-10-02 at 15:27 +0100, Matthew Fioravante wrote: > This patch adds iowritexx() and ioreadxx() functions for interacting > with hardware memory to mini-os. The functions are available in a header > iorw.h > > Signed-off-by: Matthew Fioravante > Acked-by: Samuel Thibault I was looking for a version of this (and the other acked mini-os patches to apply) but I'm a bit confused as to which version I should be taking and in which order I should apply things. This one seems to be 01/12 but I only seem to have 4 patches in the /12 series (#1, #4 and two lots of #8) in my INBOX -- I'm not sure what's happened to the rest of them. The previous posting was NN/11 but I don't want to be cherry picking bits of different series (I'll only mess it up). So, to avoid confusion can you collect the Acks/Reviewed-bys and resend using git format-patch's --subject-prefix option to tag the [PATCH V2] (I know there have been more than 2 previous postings but we haven't been counting until now). Thanks, Ian. > --- > Changes since last > * remove ia64 support > > diff --git a/extras/mini-os/arch/x86/iorw.c b/extras/mini-os/arch/x86/iorw.c > new file mode 100644 > index 0000000..3080769 > --- /dev/null > +++ b/extras/mini-os/arch/x86/iorw.c > @@ -0,0 +1,35 @@ > +#include > + > +void iowrite8(volatile void* addr, uint8_t val) > +{ > + *((volatile uint8_t*)addr) = val; > +} > +void iowrite16(volatile void* addr, uint16_t val) > +{ > + *((volatile uint16_t*)addr) = val; > +} > +void iowrite32(volatile void* addr, uint32_t val) > +{ > + *((volatile uint32_t*)addr) = val; > +} > +void iowrite64(volatile void* addr, uint64_t val) > +{ > + *((volatile uint64_t*)addr) = val; > +} > + > +uint8_t ioread8(volatile void* addr) > +{ > + return *((volatile uint8_t*) addr); > +} > +uint16_t ioread16(volatile void* addr) > +{ > + return *((volatile uint16_t*) addr); > +} > +uint32_t ioread32(volatile void* addr) > +{ > + return *((volatile uint32_t*) addr); > +} > +uint64_t ioread64(volatile void* addr) > +{ > + return *((volatile uint64_t*) addr); > +} > diff --git a/extras/mini-os/include/iorw.h b/extras/mini-os/include/iorw.h > new file mode 100644 > index 0000000..d5ec065 > --- /dev/null > +++ b/extras/mini-os/include/iorw.h > @@ -0,0 +1,16 @@ > +#ifndef MINIOS_IORW_H > +#define MINIOS_IORW_H > + > +#include > + > +void iowrite8(volatile void* addr, uint8_t val); > +void iowrite16(volatile void* addr, uint16_t val); > +void iowrite32(volatile void* addr, uint32_t val); > +void iowrite64(volatile void* addr, uint64_t val); > + > +uint8_t ioread8(volatile void* addr); > +uint16_t ioread16(volatile void* addr); > +uint32_t ioread32(volatile void* addr); > +uint64_t ioread64(volatile void* addr); > + > +#endif _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:38:02 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:38:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK92G-0004Og-BF; Fri, 05 Oct 2012 14:37:52 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK92E-0004Nv-Oh for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:37:50 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1349447863!4302786!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24042 invoked from network); 5 Oct 2012 14:37:44 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:37:44 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14966570" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 14:37:43 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 15:37:44 +0100 Message-ID: <1349447862.20946.133.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Matthew Fioravante Date: Fri, 5 Oct 2012 15:37:42 +0100 In-Reply-To: <1349188052-15639-1-git-send-email-matthew.fioravante@jhuapl.edu> References: <1349188052-15639-1-git-send-email-matthew.fioravante@jhuapl.edu> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "samuel.thibault@ens-lyon.org" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 01/12] Add ioread/iowrite functions to mini-os X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2012-10-02 at 15:27 +0100, Matthew Fioravante wrote: > This patch adds iowritexx() and ioreadxx() functions for interacting > with hardware memory to mini-os. The functions are available in a header > iorw.h > > Signed-off-by: Matthew Fioravante > Acked-by: Samuel Thibault I was looking for a version of this (and the other acked mini-os patches to apply) but I'm a bit confused as to which version I should be taking and in which order I should apply things. This one seems to be 01/12 but I only seem to have 4 patches in the /12 series (#1, #4 and two lots of #8) in my INBOX -- I'm not sure what's happened to the rest of them. The previous posting was NN/11 but I don't want to be cherry picking bits of different series (I'll only mess it up). So, to avoid confusion can you collect the Acks/Reviewed-bys and resend using git format-patch's --subject-prefix option to tag the [PATCH V2] (I know there have been more than 2 previous postings but we haven't been counting until now). Thanks, Ian. > --- > Changes since last > * remove ia64 support > > diff --git a/extras/mini-os/arch/x86/iorw.c b/extras/mini-os/arch/x86/iorw.c > new file mode 100644 > index 0000000..3080769 > --- /dev/null > +++ b/extras/mini-os/arch/x86/iorw.c > @@ -0,0 +1,35 @@ > +#include > + > +void iowrite8(volatile void* addr, uint8_t val) > +{ > + *((volatile uint8_t*)addr) = val; > +} > +void iowrite16(volatile void* addr, uint16_t val) > +{ > + *((volatile uint16_t*)addr) = val; > +} > +void iowrite32(volatile void* addr, uint32_t val) > +{ > + *((volatile uint32_t*)addr) = val; > +} > +void iowrite64(volatile void* addr, uint64_t val) > +{ > + *((volatile uint64_t*)addr) = val; > +} > + > +uint8_t ioread8(volatile void* addr) > +{ > + return *((volatile uint8_t*) addr); > +} > +uint16_t ioread16(volatile void* addr) > +{ > + return *((volatile uint16_t*) addr); > +} > +uint32_t ioread32(volatile void* addr) > +{ > + return *((volatile uint32_t*) addr); > +} > +uint64_t ioread64(volatile void* addr) > +{ > + return *((volatile uint64_t*) addr); > +} > diff --git a/extras/mini-os/include/iorw.h b/extras/mini-os/include/iorw.h > new file mode 100644 > index 0000000..d5ec065 > --- /dev/null > +++ b/extras/mini-os/include/iorw.h > @@ -0,0 +1,16 @@ > +#ifndef MINIOS_IORW_H > +#define MINIOS_IORW_H > + > +#include > + > +void iowrite8(volatile void* addr, uint8_t val); > +void iowrite16(volatile void* addr, uint16_t val); > +void iowrite32(volatile void* addr, uint32_t val); > +void iowrite64(volatile void* addr, uint64_t val); > + > +uint8_t ioread8(volatile void* addr); > +uint16_t ioread16(volatile void* addr); > +uint32_t ioread32(volatile void* addr); > +uint64_t ioread64(volatile void* addr); > + > +#endif _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:46:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:46:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK9AZ-0004jl-K9; Fri, 05 Oct 2012 14:46:27 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK9AX-0004jg-La for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 14:46:25 +0000 Received: from [85.158.139.83:9740] by server-5.bemta-5.messagelabs.com id 18/6D-21075-0C2FE605; Fri, 05 Oct 2012 14:46:24 +0000 X-Env-Sender: raistlin.df@gmail.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1349448383!29067659!1 X-Originating-IP: [209.85.212.177] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32134 invoked from network); 5 Oct 2012 14:46:24 -0000 Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com) (209.85.212.177) by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:46:24 -0000 Received: by mail-wi0-f177.google.com with SMTP id hj13so639337wib.6 for ; Fri, 05 Oct 2012 07:46:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:subject:from:to:cc:date:in-reply-to:references :content-type:x-mailer:mime-version; bh=N2aYkp8QRgEUg/x5+pz1ec7dE32WSLF6ncuRmBmOfJs=; b=V47wEENBgwRe/ELYZPg2NOsY/Q8pq7czi/c2LwO06mVvVCU8fFVWRXogJR2XqXyjcp mqhGn3KKM6YcNR4z73W8f/q7JfxYVK/DdbRcQsO2R5/wZ6q9+8dgraaJSvUD9Jq26+Pb Tk+FZPgFEcceGIL3syrkbeoWKgR9SlMF+pq0UjJjwp1l3T2sTI+dvflNAb/zbnYVFYfu Xv25b/PHR3FH2C9Svti5YaP2boiTPiw2v1++kEHi0YipCLORQGgFHEgkZN7LZ1Y1+/RA yZReXagvv70X5ghgrfJ7xs2WJr3Qy9n3AKxRm2m9P153SkUxGNf+hVKy+g19KZCVMfhO mcxg== Received: by 10.216.85.212 with SMTP id u62mr5658342wee.185.1349448383809; Fri, 05 Oct 2012 07:46:23 -0700 (PDT) Received: from [192.168.0.40] (ip-170-24.sn3.eutelia.it. [213.136.170.24]) by mx.google.com with ESMTPS id j8sm2704785wiy.9.2012.10.05.07.46.21 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Oct 2012 07:46:22 -0700 (PDT) Message-ID: <1349448373.18984.27.camel@Solace> From: Dario Faggioli To: "xen.org" Date: Fri, 05 Oct 2012 16:46:13 +0200 In-Reply-To: References: X-Mailer: Evolution 3.4.3-1 Mime-Version: 1.0 Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] [xen-unstable test] 13924: tolerable FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2113934102347793813==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============2113934102347793813== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-kCxh2n6kDWvAts3hccT/" --=-kCxh2n6kDWvAts3hccT/ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2012-10-05 at 07:35 +0100, xen.org wrote: > flight 13924 xen-unstable real [real] > http://www.chiark.greenend.org.uk/~xensrcts/logs/13924/ >=20 > Failures :-/ but no regressions. >=20 > Regressions which are regarded as allowable (not blocking): > test-amd64-amd64-xl-sedf 5 xen-boot fail like= 13923 > So, sorry for noticing this only now, but it seems the sedf test is failing to boot since flight 13900 (Sept 28). It seems to me that, from hat day on, this particular test is always running on the same machine (gall-mite). OTOH, 13900 run on a different one (moss-bug) and worked well. =46rom a super quick inspection of the logs, I couldn't spot anything particular that can be causing the failures, so I'm asking here: could it be something somehow machine-related? I remember you (IanJ) telling that there might be some problems with the test system in these days... Is that the case or should I be investigating more thoroughly? (In the latter case, I think I can have a look at it next week). Thanks and Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-kCxh2n6kDWvAts3hccT/ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAlBu8rUACgkQk4XaBE3IOsRvKwCdEAVcJNot3zh7rZYo+PCrSBCR 8oMAn1FydrdtzF/46BgzL6d9lQxmzoTM =wr+s -----END PGP SIGNATURE----- --=-kCxh2n6kDWvAts3hccT/-- --===============2113934102347793813== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============2113934102347793813==-- From xen-devel-bounces@lists.xen.org Fri Oct 05 14:46:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:46:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK9AZ-0004jl-K9; Fri, 05 Oct 2012 14:46:27 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK9AX-0004jg-La for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 14:46:25 +0000 Received: from [85.158.139.83:9740] by server-5.bemta-5.messagelabs.com id 18/6D-21075-0C2FE605; Fri, 05 Oct 2012 14:46:24 +0000 X-Env-Sender: raistlin.df@gmail.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1349448383!29067659!1 X-Originating-IP: [209.85.212.177] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32134 invoked from network); 5 Oct 2012 14:46:24 -0000 Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com) (209.85.212.177) by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:46:24 -0000 Received: by mail-wi0-f177.google.com with SMTP id hj13so639337wib.6 for ; Fri, 05 Oct 2012 07:46:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:subject:from:to:cc:date:in-reply-to:references :content-type:x-mailer:mime-version; bh=N2aYkp8QRgEUg/x5+pz1ec7dE32WSLF6ncuRmBmOfJs=; b=V47wEENBgwRe/ELYZPg2NOsY/Q8pq7czi/c2LwO06mVvVCU8fFVWRXogJR2XqXyjcp mqhGn3KKM6YcNR4z73W8f/q7JfxYVK/DdbRcQsO2R5/wZ6q9+8dgraaJSvUD9Jq26+Pb Tk+FZPgFEcceGIL3syrkbeoWKgR9SlMF+pq0UjJjwp1l3T2sTI+dvflNAb/zbnYVFYfu Xv25b/PHR3FH2C9Svti5YaP2boiTPiw2v1++kEHi0YipCLORQGgFHEgkZN7LZ1Y1+/RA yZReXagvv70X5ghgrfJ7xs2WJr3Qy9n3AKxRm2m9P153SkUxGNf+hVKy+g19KZCVMfhO mcxg== Received: by 10.216.85.212 with SMTP id u62mr5658342wee.185.1349448383809; Fri, 05 Oct 2012 07:46:23 -0700 (PDT) Received: from [192.168.0.40] (ip-170-24.sn3.eutelia.it. [213.136.170.24]) by mx.google.com with ESMTPS id j8sm2704785wiy.9.2012.10.05.07.46.21 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Oct 2012 07:46:22 -0700 (PDT) Message-ID: <1349448373.18984.27.camel@Solace> From: Dario Faggioli To: "xen.org" Date: Fri, 05 Oct 2012 16:46:13 +0200 In-Reply-To: References: X-Mailer: Evolution 3.4.3-1 Mime-Version: 1.0 Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] [xen-unstable test] 13924: tolerable FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2113934102347793813==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============2113934102347793813== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-kCxh2n6kDWvAts3hccT/" --=-kCxh2n6kDWvAts3hccT/ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2012-10-05 at 07:35 +0100, xen.org wrote: > flight 13924 xen-unstable real [real] > http://www.chiark.greenend.org.uk/~xensrcts/logs/13924/ >=20 > Failures :-/ but no regressions. >=20 > Regressions which are regarded as allowable (not blocking): > test-amd64-amd64-xl-sedf 5 xen-boot fail like= 13923 > So, sorry for noticing this only now, but it seems the sedf test is failing to boot since flight 13900 (Sept 28). It seems to me that, from hat day on, this particular test is always running on the same machine (gall-mite). OTOH, 13900 run on a different one (moss-bug) and worked well. =46rom a super quick inspection of the logs, I couldn't spot anything particular that can be causing the failures, so I'm asking here: could it be something somehow machine-related? I remember you (IanJ) telling that there might be some problems with the test system in these days... Is that the case or should I be investigating more thoroughly? (In the latter case, I think I can have a look at it next week). Thanks and Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-kCxh2n6kDWvAts3hccT/ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAlBu8rUACgkQk4XaBE3IOsRvKwCdEAVcJNot3zh7rZYo+PCrSBCR 8oMAn1FydrdtzF/46BgzL6d9lQxmzoTM =wr+s -----END PGP SIGNATURE----- --=-kCxh2n6kDWvAts3hccT/-- --===============2113934102347793813== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============2113934102347793813==-- From xen-devel-bounces@lists.xen.org Fri Oct 05 14:50:23 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:50:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK9EC-0004um-8s; Fri, 05 Oct 2012 14:50:12 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK9EB-0004ud-1E for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:50:11 +0000 Received: from [85.158.143.99:34858] by server-1.bemta-4.messagelabs.com id 5B/45-05684-2A3FE605; Fri, 05 Oct 2012 14:50:10 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1349448607!33057620!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ1ODc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14651 invoked from network); 5 Oct 2012 14:50:09 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:50:09 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="40277644" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 14:50:07 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 10:50:06 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK9E6-0007AA-FQ; Fri, 05 Oct 2012 15:50:06 +0100 From: Anthony PERARD To: Xen Devel Date: Fri, 5 Oct 2012 15:49:56 +0100 Message-ID: <1349448596-8611-1-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 MIME-Version: 1.0 Cc: Anthony PERARD , Ian Jackson , Ian Campbell Subject: [Xen-devel] [PATCH] libxl: Add a comment about NOGC usage with flexarray X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Anthony PERARD --- tools/libxl/flexarray.h | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/tools/libxl/flexarray.h b/tools/libxl/flexarray.h index aade417..a1e8647 100644 --- a/tools/libxl/flexarray.h +++ b/tools/libxl/flexarray.h @@ -26,7 +26,13 @@ typedef struct flexarray { struct libxl__gc *gc; } flexarray_t; -_hidden flexarray_t *flexarray_make(struct libxl__gc *gc, int size, int autogrow); +/* + * NOGC can be used with flexarrays, but flexarray_free will need to be called + * to free the struct. The content of the flexarray will not be freed through + * flexarray_free. + */ +_hidden flexarray_t *flexarray_make(struct libxl__gc *gc_opt, + int size, int autogrow); _hidden void flexarray_free(flexarray_t *array); _hidden void flexarray_grow(flexarray_t *array, int extents); _hidden int flexarray_set(flexarray_t *array, unsigned int index, void *ptr); -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:50:23 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:50:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK9EC-0004um-8s; Fri, 05 Oct 2012 14:50:12 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK9EB-0004ud-1E for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:50:11 +0000 Received: from [85.158.143.99:34858] by server-1.bemta-4.messagelabs.com id 5B/45-05684-2A3FE605; Fri, 05 Oct 2012 14:50:10 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1349448607!33057620!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ1ODc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14651 invoked from network); 5 Oct 2012 14:50:09 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:50:09 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="40277644" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 14:50:07 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 10:50:06 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK9E6-0007AA-FQ; Fri, 05 Oct 2012 15:50:06 +0100 From: Anthony PERARD To: Xen Devel Date: Fri, 5 Oct 2012 15:49:56 +0100 Message-ID: <1349448596-8611-1-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 MIME-Version: 1.0 Cc: Anthony PERARD , Ian Jackson , Ian Campbell Subject: [Xen-devel] [PATCH] libxl: Add a comment about NOGC usage with flexarray X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Anthony PERARD --- tools/libxl/flexarray.h | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/tools/libxl/flexarray.h b/tools/libxl/flexarray.h index aade417..a1e8647 100644 --- a/tools/libxl/flexarray.h +++ b/tools/libxl/flexarray.h @@ -26,7 +26,13 @@ typedef struct flexarray { struct libxl__gc *gc; } flexarray_t; -_hidden flexarray_t *flexarray_make(struct libxl__gc *gc, int size, int autogrow); +/* + * NOGC can be used with flexarrays, but flexarray_free will need to be called + * to free the struct. The content of the flexarray will not be freed through + * flexarray_free. + */ +_hidden flexarray_t *flexarray_make(struct libxl__gc *gc_opt, + int size, int autogrow); _hidden void flexarray_free(flexarray_t *array); _hidden void flexarray_grow(flexarray_t *array, int extents); _hidden int flexarray_set(flexarray_t *array, unsigned int index, void *ptr); -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:52:27 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:52:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK9GD-00052u-QP; Fri, 05 Oct 2012 14:52:17 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK9GC-00052n-Lb for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:52:16 +0000 Received: from [85.158.139.211:54490] by server-13.bemta-5.messagelabs.com id 8A/29-06496-F14FE605; Fri, 05 Oct 2012 14:52:15 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-14.tower-206.messagelabs.com!1349448733!21168199!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODA1MjM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20199 invoked from network); 5 Oct 2012 14:52:15 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:52:15 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="210424976" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 14:52:12 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 10:52:12 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK8vC-0006rc-1m; Fri, 05 Oct 2012 15:30:34 +0100 From: Anthony PERARD To: Xen Devel Date: Fri, 5 Oct 2012 15:30:32 +0100 Message-ID: <1349447432-29511-11-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1349447432-29511-1-git-send-email-anthony.perard@citrix.com> References: <1349447432-29511-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Cc: Anthony PERARD , Ian Campbell Subject: [Xen-devel] [PATCH V4 10/10] libxl: Allow migration with qemu-xen. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Anthony PERARD Acked-by: Ian Campbell --- tools/libxl/libxl.c | 17 ----------------- 1 file changed, 17 deletions(-) diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c index af3682f..0cf4768 100644 --- a/tools/libxl/libxl.c +++ b/tools/libxl/libxl.c @@ -767,23 +767,6 @@ int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd, int flags, goto out_err; } - if (type == LIBXL_DOMAIN_TYPE_HVM && flags & LIBXL_SUSPEND_LIVE) { - switch (libxl__device_model_version_running(gc, domid)) { - case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN: - LOG(ERROR, - "cannot live migrate HVM domains with qemu-xen device-model"); - rc = ERROR_FAIL; - goto out_err; - case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: - /* No problem */ - break; - case -1: - rc = ERROR_FAIL; - goto out_err; - default: abort(); - } - } - libxl__domain_suspend_state *dss; GCNEW(dss); -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:52:27 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:52:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK9GD-00052u-QP; Fri, 05 Oct 2012 14:52:17 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK9GC-00052n-Lb for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:52:16 +0000 Received: from [85.158.139.211:54490] by server-13.bemta-5.messagelabs.com id 8A/29-06496-F14FE605; Fri, 05 Oct 2012 14:52:15 +0000 X-Env-Sender: anthony.perard@citrix.com X-Msg-Ref: server-14.tower-206.messagelabs.com!1349448733!21168199!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODA1MjM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20199 invoked from network); 5 Oct 2012 14:52:15 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:52:15 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="210424976" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 14:52:12 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 10:52:12 -0400 Received: from [10.80.3.61] (helo=perard.uk.xensource.com) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1TK8vC-0006rc-1m; Fri, 05 Oct 2012 15:30:34 +0100 From: Anthony PERARD To: Xen Devel Date: Fri, 5 Oct 2012 15:30:32 +0100 Message-ID: <1349447432-29511-11-git-send-email-anthony.perard@citrix.com> X-Mailer: git-send-email 1.7.12.2 In-Reply-To: <1349447432-29511-1-git-send-email-anthony.perard@citrix.com> References: <1349447432-29511-1-git-send-email-anthony.perard@citrix.com> MIME-Version: 1.0 Cc: Anthony PERARD , Ian Campbell Subject: [Xen-devel] [PATCH V4 10/10] libxl: Allow migration with qemu-xen. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Anthony PERARD Acked-by: Ian Campbell --- tools/libxl/libxl.c | 17 ----------------- 1 file changed, 17 deletions(-) diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c index af3682f..0cf4768 100644 --- a/tools/libxl/libxl.c +++ b/tools/libxl/libxl.c @@ -767,23 +767,6 @@ int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd, int flags, goto out_err; } - if (type == LIBXL_DOMAIN_TYPE_HVM && flags & LIBXL_SUSPEND_LIVE) { - switch (libxl__device_model_version_running(gc, domid)) { - case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN: - LOG(ERROR, - "cannot live migrate HVM domains with qemu-xen device-model"); - rc = ERROR_FAIL; - goto out_err; - case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: - /* No problem */ - break; - case -1: - rc = ERROR_FAIL; - goto out_err; - default: abort(); - } - } - libxl__domain_suspend_state *dss; GCNEW(dss); -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:53:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:53:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK9Gz-00057A-8b; Fri, 05 Oct 2012 14:53:05 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK9Gx-00056y-Oj for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:53:03 +0000 Received: from [85.158.139.83:54103] by server-3.bemta-5.messagelabs.com id 2B/C0-16108-F44FE605; Fri, 05 Oct 2012 14:53:03 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1349448782!27986656!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20239 invoked from network); 5 Oct 2012 14:53:02 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:53:02 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14966903" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 14:53:00 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 15:52:59 +0100 Date: Fri, 5 Oct 2012 15:51:57 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Jan Beulich In-Reply-To: <506EE0D7020000780009FEEB@nat28.tlf.novell.com> Message-ID: References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> <1349433507-21148-21-git-send-email-ian.campbell@citrix.com> <506EE0D7020000780009FEEB@nat28.tlf.novell.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: "Tim \(Xen.org\)" , "xen-devel@lists.xen.org" , "Keir \(Xen.org\)" , Ian Campbell , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH 21/21] xen: more substitutions X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 5 Oct 2012, Jan Beulich wrote: > >>> On 05.10.12 at 12:38, Ian Campbell wrote: > > @@ -4202,7 +4205,8 @@ static int handle_iomem_range(unsigned long s, unsigned long e, void *p) > > ent.addr = (uint64_t)ctxt->s << PAGE_SHIFT; > > ent.size = (uint64_t)(s - ctxt->s) << PAGE_SHIFT; > > ent.type = E820_RESERVED; > > - buffer = guest_handle_cast(ctxt->map.buffer, e820entry_t); > > + buffer_t = guest_handle_cast(ctxt->map.buffer, e820entry_t); > > + buffer = guest_handle_from_param(buffer_t, e820entry_t); > > So why is this needed in the first place? I suppose it's related > to guest_handle_cast() returning a _HANDLE_PARAM(), but > what's the reason for that? Because almost everywhere is useful to get an _HANDLE_PARAM from guest_handle_cast, except two cases, and this is one of them > Nor would I expect __copy_to_guest_offset() to by unable to > deal with one? I.e., can't the infrastructure be made capable > of dealing with both, so pointless conversions can be avoided? I would rather have one more line of code but being very obvious about what I am doing: guest_handle_cast returns a XEN_GUEST_HANDLE_PARAM so we need to cast that to XEN_GUEST_HANDLE. We do that in the traditional way: calling guest_handle_from_param. > Or if not, is there really a point in making these changes on the > x86 side (they're benign there, and hence only reduce > readability)? It makes the code more coherent. I like the principle of least surprise. Also I would like that changing the type of XEN_GUEST_HANDLE_PARAM on x86 would actually work. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:53:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:53:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK9Gz-00057A-8b; Fri, 05 Oct 2012 14:53:05 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK9Gx-00056y-Oj for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:53:03 +0000 Received: from [85.158.139.83:54103] by server-3.bemta-5.messagelabs.com id 2B/C0-16108-F44FE605; Fri, 05 Oct 2012 14:53:03 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1349448782!27986656!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20239 invoked from network); 5 Oct 2012 14:53:02 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:53:02 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14966903" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 14:53:00 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 15:52:59 +0100 Date: Fri, 5 Oct 2012 15:51:57 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Jan Beulich In-Reply-To: <506EE0D7020000780009FEEB@nat28.tlf.novell.com> Message-ID: References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> <1349433507-21148-21-git-send-email-ian.campbell@citrix.com> <506EE0D7020000780009FEEB@nat28.tlf.novell.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: "Tim \(Xen.org\)" , "xen-devel@lists.xen.org" , "Keir \(Xen.org\)" , Ian Campbell , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH 21/21] xen: more substitutions X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 5 Oct 2012, Jan Beulich wrote: > >>> On 05.10.12 at 12:38, Ian Campbell wrote: > > @@ -4202,7 +4205,8 @@ static int handle_iomem_range(unsigned long s, unsigned long e, void *p) > > ent.addr = (uint64_t)ctxt->s << PAGE_SHIFT; > > ent.size = (uint64_t)(s - ctxt->s) << PAGE_SHIFT; > > ent.type = E820_RESERVED; > > - buffer = guest_handle_cast(ctxt->map.buffer, e820entry_t); > > + buffer_t = guest_handle_cast(ctxt->map.buffer, e820entry_t); > > + buffer = guest_handle_from_param(buffer_t, e820entry_t); > > So why is this needed in the first place? I suppose it's related > to guest_handle_cast() returning a _HANDLE_PARAM(), but > what's the reason for that? Because almost everywhere is useful to get an _HANDLE_PARAM from guest_handle_cast, except two cases, and this is one of them > Nor would I expect __copy_to_guest_offset() to by unable to > deal with one? I.e., can't the infrastructure be made capable > of dealing with both, so pointless conversions can be avoided? I would rather have one more line of code but being very obvious about what I am doing: guest_handle_cast returns a XEN_GUEST_HANDLE_PARAM so we need to cast that to XEN_GUEST_HANDLE. We do that in the traditional way: calling guest_handle_from_param. > Or if not, is there really a point in making these changes on the > x86 side (they're benign there, and hence only reduce > readability)? It makes the code more coherent. I like the principle of least surprise. Also I would like that changing the type of XEN_GUEST_HANDLE_PARAM on x86 would actually work. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:55:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:55:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK9J9-0005I7-Qb; Fri, 05 Oct 2012 14:55:19 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK9J8-0005Hv-Cs for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:55:18 +0000 Received: from [85.158.137.99:32619] by server-3.bemta-3.messagelabs.com id 1A/94-25962-5D4FE605; Fri, 05 Oct 2012 14:55:17 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-7.tower-217.messagelabs.com!1349448912!15637449!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30292 invoked from network); 5 Oct 2012 14:55:16 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:55:16 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14966996" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 14:55:11 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 15:55:11 +0100 Date: Fri, 5 Oct 2012 15:54:09 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Ian Campbell In-Reply-To: <1349447625.20946.130.camel@zakaz.uk.xensource.com> Message-ID: References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-5-git-send-email-ian.campbell@citrix.com> <1349440338.20946.83.camel@zakaz.uk.xensource.com> <1349447625.20946.130.camel@zakaz.uk.xensource.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: Konrad Rzeszutek Wilk , "xen-devel@lists.xen.org" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH 05/14] xen: balloon: use correct type for frame_list X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 5 Oct 2012, Ian Campbell wrote: > In theory there might be a problem for a PV guest, but in the only case > which matters: > arch/x86/include/asm/xen/interface.h:typedef unsigned long xen_pfn_t; > and furthermore 32 bit PV guests are limited to 160G of MFN space (which > is less than 2^32) for other reasons already. Well, we should at least write that in a comment _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 14:55:29 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 14:55:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK9J9-0005I7-Qb; Fri, 05 Oct 2012 14:55:19 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK9J8-0005Hv-Cs for xen-devel@lists.xen.org; Fri, 05 Oct 2012 14:55:18 +0000 Received: from [85.158.137.99:32619] by server-3.bemta-3.messagelabs.com id 1A/94-25962-5D4FE605; Fri, 05 Oct 2012 14:55:17 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-7.tower-217.messagelabs.com!1349448912!15637449!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30292 invoked from network); 5 Oct 2012 14:55:16 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 14:55:16 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14966996" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 14:55:11 +0000 Received: from kaball.uk.xensource.com (10.80.2.59) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 15:55:11 +0100 Date: Fri, 5 Oct 2012 15:54:09 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Ian Campbell In-Reply-To: <1349447625.20946.130.camel@zakaz.uk.xensource.com> Message-ID: References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-5-git-send-email-ian.campbell@citrix.com> <1349440338.20946.83.camel@zakaz.uk.xensource.com> <1349447625.20946.130.camel@zakaz.uk.xensource.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: Konrad Rzeszutek Wilk , "xen-devel@lists.xen.org" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH 05/14] xen: balloon: use correct type for frame_list X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 5 Oct 2012, Ian Campbell wrote: > In theory there might be a problem for a PV guest, but in the only case > which matters: > arch/x86/include/asm/xen/interface.h:typedef unsigned long xen_pfn_t; > and furthermore 32 bit PV guests are limited to 160G of MFN space (which > is less than 2^32) for other reasons already. Well, we should at least write that in a comment _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 15:13:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 15:13:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK9ai-0005u8-DK; Fri, 05 Oct 2012 15:13:28 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK9ag-0005u2-Tf for xen-devel@lists.xen.org; Fri, 05 Oct 2012 15:13:27 +0000 Received: from [85.158.139.83:10148] by server-15.bemta-5.messagelabs.com id B1/0D-06905-619FE605; Fri, 05 Oct 2012 15:13:26 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-3.tower-182.messagelabs.com!1349450003!33587208!1 X-Originating-IP: [128.244.251.36] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5963 invoked from network); 5 Oct 2012 15:13:24 -0000 Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36) by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 15:13:24 -0000 Received: from ([128.244.207.89]) by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.154379134; Fri, 05 Oct 2012 11:13:06 -0400 Message-ID: <506EF8AF.4080307@jhuapl.edu> Date: Fri, 05 Oct 2012 11:11:43 -0400 From: Matthew Fioravante User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Ian Campbell References: <1349189903-17524-1-git-send-email-matthew.fioravante@jhuapl.edu> <1349194332.650.102.camel@zakaz.uk.xensource.com> In-Reply-To: <1349194332.650.102.camel@zakaz.uk.xensource.com> X-Enigmail-Version: 1.4.4 Cc: "samuel.thibault@ens-lyon.org" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 08/12] add tpmfront, tpm_tis, and tpmback drivers to mini-os X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4650819707532372201==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a cryptographically signed message in MIME format. --===============4650819707532372201== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060103000306010907080900" This is a cryptographically signed message in MIME format. --------------ms060103000306010907080900 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Wow for some reason I totally missed the rest of your long email response. Anyway, comments below On 10/02/2012 12:12 PM, Ian Campbell wrote: > On Tue, 2012-10-02 at 15:58 +0100, Matthew Fioravante wrote: >> diff --git a/extras/mini-os/include/tpm_tis.h b/extras/mini-os/include= /tpm_tis.h >> new file mode 100644 >> index 0000000..a076a70 >> --- /dev/null >> +++ b/extras/mini-os/include/tpm_tis.h >> @@ -0,0 +1,64 @@ >> +/* >> + * Copyright (c) 2010-2012 United States Government, as represented b= y >> + * the Secretary of Defense. All rights reserved. >> + * >> + * This program is free software; you can redistribute it and/or >> + * modify it under the terms of the GNU General Public License >> + * as published by the Free Software Foundation; either version 2 >> + * of the License, or (at your option) any later version. > Sorry, but the original Linux files don't seem to use the "or (at your > option) any later version" part so I think you must not either. > >> + * This program is distributed in the hope that it will be useful, >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> + * GNU General Public License for more details. >> + * >> + * You should have received a copy of the GNU General Public License >> + * along with this program; if not, write to the Free Software >> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 021= 10-1301, USA. >> + * >> + * Based upon the files: >> + * drivers/char/tpm/tpm_tis.c >> + * drivers/char/tpm/tpm.c >> + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporatio= n >> + */ >> diff --git a/extras/mini-os/include/tpmback.h b/extras/mini-os/include= /tpmback.h >> new file mode 100644 >> index 0000000..4315e55 >> --- /dev/null >> +++ b/extras/mini-os/include/tpmback.h >> @@ -0,0 +1,96 @@ >> +/* >> + * Copyright (c) 2010-2012 United States Government, as represented b= y >> + * the Secretary of Defense. All rights reserved. >> + * >> + * This program is free software; you can redistribute it and/or >> + * modify it under the terms of the GNU General Public License >> + * as published by the Free Software Foundation; either version 2 >> + * of the License, or (at your option) any later version. >> + * >> + * This program is distributed in the hope that it will be useful, >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> + * GNU General Public License for more details. >> + * >> + * You should have received a copy of the GNU General Public License >> + * along with this program; if not, write to the Free Software >> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 021= 10-1301, USA. >> + * >> + * Based upon the files: >> + * drivers/xen/tpmbk.c > Where can I find this file? I looked in upstream Linux and > linux-2.6.18-xen.hg. In the internal tree I was using which was based off of xen linux 2.6.18, it was located there. It looks the current mercurial tree its been moved to drivers/xen/tpmback.c. >> diff --git a/extras/mini-os/include/tpmfront.h b/extras/mini-os/includ= e/tpmfront.h >> new file mode 100644 >> index 0000000..7e3d357 >> --- /dev/null >> +++ b/extras/mini-os/include/tpmfront.h >> @@ -0,0 +1,97 @@ >> +/* >> + * Copyright (c) 2010-2012 United States Government, as represented b= y >> + * the Secretary of Defense. All rights reserved. >> + * >> + * This program is free software; you can redistribute it and/or >> + * modify it under the terms of the GNU General Public License >> + * as published by the Free Software Foundation; either version 2 >> + * of the License, or (at your option) any later version. >> + * >> + * This program is distributed in the hope that it will be useful, >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> + * GNU General Public License for more details. >> + * >> + * You should have received a copy of the GNU General Public License >> + * along with this program; if not, write to the Free Software >> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 021= 10-1301, USA. >> + * >> + >> + * >> + * Based upon the files: >> + * drivers/char/tpm/tpm_vtpm.c > This one is GPLv2 only (not or later) also. > >> + * drivers/char/tpm/tpm_xen.c > This one does actually have the MIT alternative but given that you have= > combined it with the above it makes sense to omit that. > >> + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporatio= n > tpm_xen.c also has "Copyright (c) 2002-2004, K A Fraser", not just IBM > and that needs to be retained I think. > >> diff --git a/extras/mini-os/tpm_tis.c b/extras/mini-os/tpm_tis.c >> new file mode 100644 >> index 0000000..d94f798 >> --- /dev/null >> +++ b/extras/mini-os/tpm_tis.c >> @@ -0,0 +1,1345 @@ >> +/* >> + * Copyright (c) 2010-2012 United States Government, as represented b= y >> + * the Secretary of Defense. All rights reserved. >> + * >> + * This program is free software; you can redistribute it and/or >> + * modify it under the terms of the GNU General Public License >> + * as published by the Free Software Foundation; either version 2 >> + * of the License, or (at your option) any later version. >> + * >> + * This program is distributed in the hope that it will be useful, >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> + * GNU General Public License for more details. >> + * >> + * You should have received a copy of the GNU General Public License >> + * along with this program; if not, write to the Free Software >> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 021= 10-1301, USA. >> + * >> + * Based upon the files: >> + * drivers/char/tpm/tpm_tis.c >> + * drivers/char/tpm/tpm.c >> + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporatio= n > You seem to have copied this 2006 date from one source and applied it t= o > all these files even though the files which they are derived from have > differing dates. > e.g. drivers/char/tpm/tpm.c says "Copyright (C) 2004 IBM Corporation" > while drivers/char/tpm/tpm_tis.c says "Copyright (C) 2005, 2006 IBM > Corporation". > > I think it is important legally to retain the precise copyright for the= > code from which you have derived. I'm afraid this is going to > re-checking against all the files you have derived from. > > You also need to retain any other copyrights, such as Keir's. > > I think this would be far less error prone if you were to copy the exac= t > bits from each file. e.g. > > * Based upon the files: > * =3D=3D=3D=3D=3D=3D=3D=3D > * drivers/char/tpm/tpm_tis.c: > * > * =3D=3D=3D=3D=3D=3D=3D > * drivers/char/tpm/tpm.c: > * > */ > > And do this for every file which from which you have derived code. > > I'm sorry this is so tedious but it is important to get things like > licensing and copyright ownership correct. I was lazy to not pay attention to this more carefully, and for that I apologize. A new patch will be coming with fixes. > >> diff --git a/extras/mini-os/tpmback.c b/extras/mini-os/tpmback.c >> new file mode 100644 >> index 0000000..03bd20c >> --- /dev/null >> +++ b/extras/mini-os/tpmback.c >> @@ -0,0 +1,1115 @@ >> +/* >> + * Copyright (c) 2010-2012 United States Government, as represented b= y >> + * the Secretary of Defense. All rights reserved. >> + * >> + * This program is free software; you can redistribute it and/or >> + * modify it under the terms of the GNU General Public License >> + * as published by the Free Software Foundation; either version 2 >> + * of the License, or (at your option) any later version. >> + * >> + * This program is distributed in the hope that it will be useful, >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> + * GNU General Public License for more details. >> + * >> + * You should have received a copy of the GNU General Public License >> + * along with this program; if not, write to the Free Software >> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 021= 10-1301, USA. >> + * >> + * Based upon the files: >> + * drivers/xen/tpmbk.c > Do you mean ./drivers/xen/tpmback/tpmback.c ? See comment above > >> + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporatio= n >> + */ > [...] >> diff --git a/extras/mini-os/tpmfront.c b/extras/mini-os/tpmfront.c >> new file mode 100644 >> index 0000000..84fc6af >> --- /dev/null >> +++ b/extras/mini-os/tpmfront.c >> @@ -0,0 +1,607 @@ >> +/* >> + * Copyright (c) 2010-2012 United States Government, as represented b= y >> + * the Secretary of Defense. All rights reserved. >> + * >> + * This program is free software; you can redistribute it and/or >> + * modify it under the terms of the GNU General Public License >> + * as published by the Free Software Foundation; either version 2 >> + * of the License, or (at your option) any later version. >> + * >> + * This program is distributed in the hope that it will be useful, >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> + * GNU General Public License for more details. >> + * >> + * You should have received a copy of the GNU General Public License >> + * along with this program; if not, write to the Free Software >> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 021= 10-1301, USA. >> + * >> + * Based upon the files: >> + * drivers/char/tpm/tpm_vtpm.c >> + * drivers/char/tpm/tpm_xen.c >> + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporatio= n > Again not "...or later". > > Ian. > --------------ms060103000306010907080900 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4 NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50 ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz 4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTEyMTAwNTE1MTE0M1owIwYJKoZIhvcNAQkEMRYEFJh5JZ9fzT8S1nVW zIcDe+hDfJCZMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYACGOgaCbSi1lnp2VW3625136CqBeh9/cUO PKEhn8wF7VJRYIGupD41H9D8maYsNEbxoJIa7OZGJGBEod8u7xYttegswLT6P3t+hSgyXK/p izgsgqW2Xn9UTRV7Gw/qlORLH5/p6kOV75lWHy+LDclchp6y/BC0X+eYmU9dM2BHGAAAAAAA AA== --------------ms060103000306010907080900-- --===============4650819707532372201== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============4650819707532372201==-- From xen-devel-bounces@lists.xen.org Fri Oct 05 15:13:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 15:13:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK9ai-0005u8-DK; Fri, 05 Oct 2012 15:13:28 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TK9ag-0005u2-Tf for xen-devel@lists.xen.org; Fri, 05 Oct 2012 15:13:27 +0000 Received: from [85.158.139.83:10148] by server-15.bemta-5.messagelabs.com id B1/0D-06905-619FE605; Fri, 05 Oct 2012 15:13:26 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-3.tower-182.messagelabs.com!1349450003!33587208!1 X-Originating-IP: [128.244.251.36] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5963 invoked from network); 5 Oct 2012 15:13:24 -0000 Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36) by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 15:13:24 -0000 Received: from ([128.244.207.89]) by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.154379134; Fri, 05 Oct 2012 11:13:06 -0400 Message-ID: <506EF8AF.4080307@jhuapl.edu> Date: Fri, 05 Oct 2012 11:11:43 -0400 From: Matthew Fioravante User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Ian Campbell References: <1349189903-17524-1-git-send-email-matthew.fioravante@jhuapl.edu> <1349194332.650.102.camel@zakaz.uk.xensource.com> In-Reply-To: <1349194332.650.102.camel@zakaz.uk.xensource.com> X-Enigmail-Version: 1.4.4 Cc: "samuel.thibault@ens-lyon.org" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 08/12] add tpmfront, tpm_tis, and tpmback drivers to mini-os X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4650819707532372201==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a cryptographically signed message in MIME format. --===============4650819707532372201== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060103000306010907080900" This is a cryptographically signed message in MIME format. --------------ms060103000306010907080900 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Wow for some reason I totally missed the rest of your long email response. Anyway, comments below On 10/02/2012 12:12 PM, Ian Campbell wrote: > On Tue, 2012-10-02 at 15:58 +0100, Matthew Fioravante wrote: >> diff --git a/extras/mini-os/include/tpm_tis.h b/extras/mini-os/include= /tpm_tis.h >> new file mode 100644 >> index 0000000..a076a70 >> --- /dev/null >> +++ b/extras/mini-os/include/tpm_tis.h >> @@ -0,0 +1,64 @@ >> +/* >> + * Copyright (c) 2010-2012 United States Government, as represented b= y >> + * the Secretary of Defense. All rights reserved. >> + * >> + * This program is free software; you can redistribute it and/or >> + * modify it under the terms of the GNU General Public License >> + * as published by the Free Software Foundation; either version 2 >> + * of the License, or (at your option) any later version. > Sorry, but the original Linux files don't seem to use the "or (at your > option) any later version" part so I think you must not either. > >> + * This program is distributed in the hope that it will be useful, >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> + * GNU General Public License for more details. >> + * >> + * You should have received a copy of the GNU General Public License >> + * along with this program; if not, write to the Free Software >> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 021= 10-1301, USA. >> + * >> + * Based upon the files: >> + * drivers/char/tpm/tpm_tis.c >> + * drivers/char/tpm/tpm.c >> + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporatio= n >> + */ >> diff --git a/extras/mini-os/include/tpmback.h b/extras/mini-os/include= /tpmback.h >> new file mode 100644 >> index 0000000..4315e55 >> --- /dev/null >> +++ b/extras/mini-os/include/tpmback.h >> @@ -0,0 +1,96 @@ >> +/* >> + * Copyright (c) 2010-2012 United States Government, as represented b= y >> + * the Secretary of Defense. All rights reserved. >> + * >> + * This program is free software; you can redistribute it and/or >> + * modify it under the terms of the GNU General Public License >> + * as published by the Free Software Foundation; either version 2 >> + * of the License, or (at your option) any later version. >> + * >> + * This program is distributed in the hope that it will be useful, >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> + * GNU General Public License for more details. >> + * >> + * You should have received a copy of the GNU General Public License >> + * along with this program; if not, write to the Free Software >> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 021= 10-1301, USA. >> + * >> + * Based upon the files: >> + * drivers/xen/tpmbk.c > Where can I find this file? I looked in upstream Linux and > linux-2.6.18-xen.hg. In the internal tree I was using which was based off of xen linux 2.6.18, it was located there. It looks the current mercurial tree its been moved to drivers/xen/tpmback.c. >> diff --git a/extras/mini-os/include/tpmfront.h b/extras/mini-os/includ= e/tpmfront.h >> new file mode 100644 >> index 0000000..7e3d357 >> --- /dev/null >> +++ b/extras/mini-os/include/tpmfront.h >> @@ -0,0 +1,97 @@ >> +/* >> + * Copyright (c) 2010-2012 United States Government, as represented b= y >> + * the Secretary of Defense. All rights reserved. >> + * >> + * This program is free software; you can redistribute it and/or >> + * modify it under the terms of the GNU General Public License >> + * as published by the Free Software Foundation; either version 2 >> + * of the License, or (at your option) any later version. >> + * >> + * This program is distributed in the hope that it will be useful, >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> + * GNU General Public License for more details. >> + * >> + * You should have received a copy of the GNU General Public License >> + * along with this program; if not, write to the Free Software >> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 021= 10-1301, USA. >> + * >> + >> + * >> + * Based upon the files: >> + * drivers/char/tpm/tpm_vtpm.c > This one is GPLv2 only (not or later) also. > >> + * drivers/char/tpm/tpm_xen.c > This one does actually have the MIT alternative but given that you have= > combined it with the above it makes sense to omit that. > >> + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporatio= n > tpm_xen.c also has "Copyright (c) 2002-2004, K A Fraser", not just IBM > and that needs to be retained I think. > >> diff --git a/extras/mini-os/tpm_tis.c b/extras/mini-os/tpm_tis.c >> new file mode 100644 >> index 0000000..d94f798 >> --- /dev/null >> +++ b/extras/mini-os/tpm_tis.c >> @@ -0,0 +1,1345 @@ >> +/* >> + * Copyright (c) 2010-2012 United States Government, as represented b= y >> + * the Secretary of Defense. All rights reserved. >> + * >> + * This program is free software; you can redistribute it and/or >> + * modify it under the terms of the GNU General Public License >> + * as published by the Free Software Foundation; either version 2 >> + * of the License, or (at your option) any later version. >> + * >> + * This program is distributed in the hope that it will be useful, >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> + * GNU General Public License for more details. >> + * >> + * You should have received a copy of the GNU General Public License >> + * along with this program; if not, write to the Free Software >> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 021= 10-1301, USA. >> + * >> + * Based upon the files: >> + * drivers/char/tpm/tpm_tis.c >> + * drivers/char/tpm/tpm.c >> + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporatio= n > You seem to have copied this 2006 date from one source and applied it t= o > all these files even though the files which they are derived from have > differing dates. > e.g. drivers/char/tpm/tpm.c says "Copyright (C) 2004 IBM Corporation" > while drivers/char/tpm/tpm_tis.c says "Copyright (C) 2005, 2006 IBM > Corporation". > > I think it is important legally to retain the precise copyright for the= > code from which you have derived. I'm afraid this is going to > re-checking against all the files you have derived from. > > You also need to retain any other copyrights, such as Keir's. > > I think this would be far less error prone if you were to copy the exac= t > bits from each file. e.g. > > * Based upon the files: > * =3D=3D=3D=3D=3D=3D=3D=3D > * drivers/char/tpm/tpm_tis.c: > * > * =3D=3D=3D=3D=3D=3D=3D > * drivers/char/tpm/tpm.c: > * > */ > > And do this for every file which from which you have derived code. > > I'm sorry this is so tedious but it is important to get things like > licensing and copyright ownership correct. I was lazy to not pay attention to this more carefully, and for that I apologize. A new patch will be coming with fixes. > >> diff --git a/extras/mini-os/tpmback.c b/extras/mini-os/tpmback.c >> new file mode 100644 >> index 0000000..03bd20c >> --- /dev/null >> +++ b/extras/mini-os/tpmback.c >> @@ -0,0 +1,1115 @@ >> +/* >> + * Copyright (c) 2010-2012 United States Government, as represented b= y >> + * the Secretary of Defense. All rights reserved. >> + * >> + * This program is free software; you can redistribute it and/or >> + * modify it under the terms of the GNU General Public License >> + * as published by the Free Software Foundation; either version 2 >> + * of the License, or (at your option) any later version. >> + * >> + * This program is distributed in the hope that it will be useful, >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> + * GNU General Public License for more details. >> + * >> + * You should have received a copy of the GNU General Public License >> + * along with this program; if not, write to the Free Software >> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 021= 10-1301, USA. >> + * >> + * Based upon the files: >> + * drivers/xen/tpmbk.c > Do you mean ./drivers/xen/tpmback/tpmback.c ? See comment above > >> + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporatio= n >> + */ > [...] >> diff --git a/extras/mini-os/tpmfront.c b/extras/mini-os/tpmfront.c >> new file mode 100644 >> index 0000000..84fc6af >> --- /dev/null >> +++ b/extras/mini-os/tpmfront.c >> @@ -0,0 +1,607 @@ >> +/* >> + * Copyright (c) 2010-2012 United States Government, as represented b= y >> + * the Secretary of Defense. All rights reserved. >> + * >> + * This program is free software; you can redistribute it and/or >> + * modify it under the terms of the GNU General Public License >> + * as published by the Free Software Foundation; either version 2 >> + * of the License, or (at your option) any later version. >> + * >> + * This program is distributed in the hope that it will be useful, >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> + * GNU General Public License for more details. >> + * >> + * You should have received a copy of the GNU General Public License >> + * along with this program; if not, write to the Free Software >> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 021= 10-1301, USA. >> + * >> + * Based upon the files: >> + * drivers/char/tpm/tpm_vtpm.c >> + * drivers/char/tpm/tpm_xen.c >> + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporatio= n > Again not "...or later". > > Ian. > --------------ms060103000306010907080900 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4 NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50 ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz 4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTEyMTAwNTE1MTE0M1owIwYJKoZIhvcNAQkEMRYEFJh5JZ9fzT8S1nVW zIcDe+hDfJCZMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYACGOgaCbSi1lnp2VW3625136CqBeh9/cUO PKEhn8wF7VJRYIGupD41H9D8maYsNEbxoJIa7OZGJGBEod8u7xYttegswLT6P3t+hSgyXK/p izgsgqW2Xn9UTRV7Gw/qlORLH5/p6kOV75lWHy+LDclchp6y/BC0X+eYmU9dM2BHGAAAAAAA AA== --------------ms060103000306010907080900-- --===============4650819707532372201== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============4650819707532372201==-- From xen-devel-bounces@lists.xen.org Fri Oct 05 15:58:11 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 15:58:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAHX-0006XW-7E; Fri, 05 Oct 2012 15:57:43 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAHV-0006XR-Mr for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 15:57:41 +0000 Received: from [85.158.139.83:32917] by server-14.bemta-5.messagelabs.com id 32/9F-31065-4730F605; Fri, 05 Oct 2012 15:57:40 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1349452658!31405861!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODA1MjM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21519 invoked from network); 5 Oct 2012 15:57:40 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 15:57:40 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="210434517" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 15:57:38 +0000 Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 11:57:38 -0400 Message-ID: <506F0370.6050905@citrix.com> Date: Fri, 5 Oct 2012 16:57:36 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120428 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: Jan Beulich References: <1348243464-15903-1-git-send-email-david.vrabel@citrix.com> <1348243464-15903-3-git-send-email-david.vrabel@citrix.com> <5061EFB2.1080407@citrix.com> <5069D097.60606@citrix.com> <20121002200255.GA668@phenom.dumpdata.com> <506EC79D.5080206@citrix.com> <506EE6CD020000780009FF4E@nat28.tlf.novell.com> In-Reply-To: <506EE6CD020000780009FF4E@nat28.tlf.novell.com> Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 2/6] xen-blkfront: handle backend CLOSED without CLOSING X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 05/10/12 12:55, Jan Beulich wrote: >>>> On 05.10.12 at 13:42, David Vrabel wrote: >> On 02/10/12 21:02, Konrad Rzeszutek Wilk wrote: >>> On Mon, Oct 01, 2012 at 06:19:19PM +0100, David Vrabel wrote: >>>> On 25/09/12 18:53, David Vrabel wrote: >>>>> On 21/09/12 17:04, David Vrabel wrote: >>>>>> From: David Vrabel >>>>>> >>>>>> Backend drivers shouldn't transistion to CLOSED unless the frontend is >>>>>> CLOSED. If a backend does transition to CLOSED too soon then the >>>>>> frontend may not see the CLOSING state and will not properly shutdown. >>>>>> >>>>>> So, treat an unexpected backend CLOSED state the same as CLOSING. >>>>> >>>>> Didn't handle the frontend block device being mounted. Updated patch here. >>>> >>>> Konrad, can you ack this updated patch if you're happy with it. >>> >>> Acked-by: Konrad Rzeszutek Wilk >>> >>> Or should I just carry it in my for-jens-3.7 bug-fixes queue and ask >>> Jen to pull it once rc0 is out? >> >> This seems easiest, if Jan is happy with the patch. > > I see the point of your explanation yesterday, but am still not > convinced that the early cleanup in spite of active users of the > disk can't cause any problems (like dangling pointers or NULL > dereferences). I tested it some more and it is broken. Please apply the first version instead. blkfront needs to cancel and complete with an error requests that are are still on the ring after the backend has disconnected and it needs to complete with an error all requests submitted while disconnected. Otherwise, if there is outstanding requests or new requests then del_gendisk() blocks waiting for the I/O to complete. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 15:58:11 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 15:58:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAHX-0006XW-7E; Fri, 05 Oct 2012 15:57:43 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAHV-0006XR-Mr for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 15:57:41 +0000 Received: from [85.158.139.83:32917] by server-14.bemta-5.messagelabs.com id 32/9F-31065-4730F605; Fri, 05 Oct 2012 15:57:40 +0000 X-Env-Sender: david.vrabel@citrix.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1349452658!31405861!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODA1MjM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21519 invoked from network); 5 Oct 2012 15:57:40 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 15:57:40 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="210434517" Received: from ftlpmailmx02.citrite.net ([10.13.107.66]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 15:57:38 +0000 Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net (10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 11:57:38 -0400 Message-ID: <506F0370.6050905@citrix.com> Date: Fri, 5 Oct 2012 16:57:36 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120428 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: Jan Beulich References: <1348243464-15903-1-git-send-email-david.vrabel@citrix.com> <1348243464-15903-3-git-send-email-david.vrabel@citrix.com> <5061EFB2.1080407@citrix.com> <5069D097.60606@citrix.com> <20121002200255.GA668@phenom.dumpdata.com> <506EC79D.5080206@citrix.com> <506EE6CD020000780009FF4E@nat28.tlf.novell.com> In-Reply-To: <506EE6CD020000780009FF4E@nat28.tlf.novell.com> Cc: "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 2/6] xen-blkfront: handle backend CLOSED without CLOSING X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 05/10/12 12:55, Jan Beulich wrote: >>>> On 05.10.12 at 13:42, David Vrabel wrote: >> On 02/10/12 21:02, Konrad Rzeszutek Wilk wrote: >>> On Mon, Oct 01, 2012 at 06:19:19PM +0100, David Vrabel wrote: >>>> On 25/09/12 18:53, David Vrabel wrote: >>>>> On 21/09/12 17:04, David Vrabel wrote: >>>>>> From: David Vrabel >>>>>> >>>>>> Backend drivers shouldn't transistion to CLOSED unless the frontend is >>>>>> CLOSED. If a backend does transition to CLOSED too soon then the >>>>>> frontend may not see the CLOSING state and will not properly shutdown. >>>>>> >>>>>> So, treat an unexpected backend CLOSED state the same as CLOSING. >>>>> >>>>> Didn't handle the frontend block device being mounted. Updated patch here. >>>> >>>> Konrad, can you ack this updated patch if you're happy with it. >>> >>> Acked-by: Konrad Rzeszutek Wilk >>> >>> Or should I just carry it in my for-jens-3.7 bug-fixes queue and ask >>> Jen to pull it once rc0 is out? >> >> This seems easiest, if Jan is happy with the patch. > > I see the point of your explanation yesterday, but am still not > convinced that the early cleanup in spite of active users of the > disk can't cause any problems (like dangling pointers or NULL > dereferences). I tested it some more and it is broken. Please apply the first version instead. blkfront needs to cancel and complete with an error requests that are are still on the ring after the backend has disconnected and it needs to complete with an error all requests submitted while disconnected. Otherwise, if there is outstanding requests or new requests then del_gendisk() blocks waiting for the I/O to complete. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 16:08:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 16:08:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKARp-00079t-BD; Fri, 05 Oct 2012 16:08:21 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKARo-00079o-JO for xen-devel@lists.xen.org; Fri, 05 Oct 2012 16:08:20 +0000 Received: from [85.158.143.35:49606] by server-2.bemta-4.messagelabs.com id 07/CC-06610-3F50F605; Fri, 05 Oct 2012 16:08:19 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1349453299!13205610!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18110 invoked from network); 5 Oct 2012 16:08:19 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 16:08:19 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14968830" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 16:08:19 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 17:08:19 +0100 Message-ID: <1349453297.20946.141.camel@zakaz.uk.xensource.com> From: Ian Campbell To: "xen-devel@lists.xen.org" Date: Fri, 5 Oct 2012 17:08:17 +0100 In-Reply-To: <1349433507-21148-17-git-send-email-ian.campbell@citrix.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> <1349433507-21148-17-git-send-email-ian.campbell@citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Tim \(Xen.org\)" , "stefano.stabelini@citrix.com" , "Keir \(Xen.org\)" , "JBeulich@suse.com" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH 17/21] xen: xen_ulong_t substitution X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-10-05 at 11:38 +0100, Ian Campbell wrote: > From: Stefano Stabellini > > There is still an unwanted unsigned long in the xen public interface: > replace it with xen_ulong_t. > > Also typedef xen_ulong_t to uint64_t on ARM. Should this change be applied to the uses of XEN_GUEST_HANDLE(ulong) too? My main concern is the one in struct gnttab_setup_table but there are a few others. I suspect XEN_GUEST_HANDLE(ulong) needs to be removed entirely, everywhere it is used should be XEN_GUEST_HANDLE(xen_ulong_t) instead? Ian. > > Changes in v2: > > - do not replace the unsigned long in x86 specific calls; > - do not replace the unsigned long in multicall_entry; > - add missing include "xen.h" in version.h; > - use proper printf flag for xen_ulong_t. > > Signed-off-by: Stefano Stabellini > Cc: keir@xen.org > Cc: JBeulich@suse.com > --- > tools/python/xen/lowlevel/xc/xc.c | 2 +- > xen/include/public/arch-arm.h | 3 ++- > xen/include/public/version.h | 4 +++- > 3 files changed, 6 insertions(+), 3 deletions(-) > > diff --git a/tools/python/xen/lowlevel/xc/xc.c b/tools/python/xen/lowlevel/xc/xc.c > index 7c89756..e220f68 100644 > --- a/tools/python/xen/lowlevel/xc/xc.c > +++ b/tools/python/xen/lowlevel/xc/xc.c > @@ -1439,7 +1439,7 @@ static PyObject *pyxc_xeninfo(XcObject *self) > if ( xc_version(self->xc_handle, XENVER_commandline, &xen_commandline) != 0 ) > return pyxc_error_to_exception(self->xc_handle); > > - snprintf(str, sizeof(str), "virt_start=0x%lx", p_parms.virt_start); > + snprintf(str, sizeof(str), "virt_start=0x%"PRI_xen_ulong, p_parms.virt_start); > > xen_pagesize = xc_version(self->xc_handle, XENVER_pagesize, NULL); > if (xen_pagesize < 0 ) > diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h > index e3d4ad9..2ae6548 100644 > --- a/xen/include/public/arch-arm.h > +++ b/xen/include/public/arch-arm.h > @@ -122,7 +122,8 @@ typedef uint64_t xen_pfn_t; > /* Only one. All other VCPUS must use VCPUOP_register_vcpu_info */ > #define XEN_LEGACY_MAX_VCPUS 1 > > -typedef uint32_t xen_ulong_t; > +typedef uint64_t xen_ulong_t; > +#define PRI_xen_ulong PRIx64 > > struct vcpu_guest_context { > #define _VGCF_online 0 > diff --git a/xen/include/public/version.h b/xen/include/public/version.h > index 8742c2b..c7e6f8c 100644 > --- a/xen/include/public/version.h > +++ b/xen/include/public/version.h > @@ -28,6 +28,8 @@ > #ifndef __XEN_PUBLIC_VERSION_H__ > #define __XEN_PUBLIC_VERSION_H__ > > +#include "xen.h" > + > /* NB. All ops return zero on success, except XENVER_{version,pagesize} */ > > /* arg == NULL; returns major:minor (16:16). */ > @@ -58,7 +60,7 @@ typedef char xen_changeset_info_t[64]; > > #define XENVER_platform_parameters 5 > struct xen_platform_parameters { > - unsigned long virt_start; > + xen_ulong_t virt_start; > }; > typedef struct xen_platform_parameters xen_platform_parameters_t; > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 16:08:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 16:08:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKARp-00079t-BD; Fri, 05 Oct 2012 16:08:21 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKARo-00079o-JO for xen-devel@lists.xen.org; Fri, 05 Oct 2012 16:08:20 +0000 Received: from [85.158.143.35:49606] by server-2.bemta-4.messagelabs.com id 07/CC-06610-3F50F605; Fri, 05 Oct 2012 16:08:19 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1349453299!13205610!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18110 invoked from network); 5 Oct 2012 16:08:19 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 16:08:19 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14968830" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 16:08:19 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 17:08:19 +0100 Message-ID: <1349453297.20946.141.camel@zakaz.uk.xensource.com> From: Ian Campbell To: "xen-devel@lists.xen.org" Date: Fri, 5 Oct 2012 17:08:17 +0100 In-Reply-To: <1349433507-21148-17-git-send-email-ian.campbell@citrix.com> References: <1349433418.20946.46.camel@zakaz.uk.xensource.com> <1349433507-21148-17-git-send-email-ian.campbell@citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "Tim \(Xen.org\)" , "stefano.stabelini@citrix.com" , "Keir \(Xen.org\)" , "JBeulich@suse.com" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH 17/21] xen: xen_ulong_t substitution X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-10-05 at 11:38 +0100, Ian Campbell wrote: > From: Stefano Stabellini > > There is still an unwanted unsigned long in the xen public interface: > replace it with xen_ulong_t. > > Also typedef xen_ulong_t to uint64_t on ARM. Should this change be applied to the uses of XEN_GUEST_HANDLE(ulong) too? My main concern is the one in struct gnttab_setup_table but there are a few others. I suspect XEN_GUEST_HANDLE(ulong) needs to be removed entirely, everywhere it is used should be XEN_GUEST_HANDLE(xen_ulong_t) instead? Ian. > > Changes in v2: > > - do not replace the unsigned long in x86 specific calls; > - do not replace the unsigned long in multicall_entry; > - add missing include "xen.h" in version.h; > - use proper printf flag for xen_ulong_t. > > Signed-off-by: Stefano Stabellini > Cc: keir@xen.org > Cc: JBeulich@suse.com > --- > tools/python/xen/lowlevel/xc/xc.c | 2 +- > xen/include/public/arch-arm.h | 3 ++- > xen/include/public/version.h | 4 +++- > 3 files changed, 6 insertions(+), 3 deletions(-) > > diff --git a/tools/python/xen/lowlevel/xc/xc.c b/tools/python/xen/lowlevel/xc/xc.c > index 7c89756..e220f68 100644 > --- a/tools/python/xen/lowlevel/xc/xc.c > +++ b/tools/python/xen/lowlevel/xc/xc.c > @@ -1439,7 +1439,7 @@ static PyObject *pyxc_xeninfo(XcObject *self) > if ( xc_version(self->xc_handle, XENVER_commandline, &xen_commandline) != 0 ) > return pyxc_error_to_exception(self->xc_handle); > > - snprintf(str, sizeof(str), "virt_start=0x%lx", p_parms.virt_start); > + snprintf(str, sizeof(str), "virt_start=0x%"PRI_xen_ulong, p_parms.virt_start); > > xen_pagesize = xc_version(self->xc_handle, XENVER_pagesize, NULL); > if (xen_pagesize < 0 ) > diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h > index e3d4ad9..2ae6548 100644 > --- a/xen/include/public/arch-arm.h > +++ b/xen/include/public/arch-arm.h > @@ -122,7 +122,8 @@ typedef uint64_t xen_pfn_t; > /* Only one. All other VCPUS must use VCPUOP_register_vcpu_info */ > #define XEN_LEGACY_MAX_VCPUS 1 > > -typedef uint32_t xen_ulong_t; > +typedef uint64_t xen_ulong_t; > +#define PRI_xen_ulong PRIx64 > > struct vcpu_guest_context { > #define _VGCF_online 0 > diff --git a/xen/include/public/version.h b/xen/include/public/version.h > index 8742c2b..c7e6f8c 100644 > --- a/xen/include/public/version.h > +++ b/xen/include/public/version.h > @@ -28,6 +28,8 @@ > #ifndef __XEN_PUBLIC_VERSION_H__ > #define __XEN_PUBLIC_VERSION_H__ > > +#include "xen.h" > + > /* NB. All ops return zero on success, except XENVER_{version,pagesize} */ > > /* arg == NULL; returns major:minor (16:16). */ > @@ -58,7 +60,7 @@ typedef char xen_changeset_info_t[64]; > > #define XENVER_platform_parameters 5 > struct xen_platform_parameters { > - unsigned long virt_start; > + xen_ulong_t virt_start; > }; > typedef struct xen_platform_parameters xen_platform_parameters_t; > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 16:10:24 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 16:10:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKATQ-0007EB-R0; Fri, 05 Oct 2012 16:10:00 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKATP-0007E4-8T for xen-devel@lists.xen.org; Fri, 05 Oct 2012 16:09:59 +0000 Received: from [85.158.139.83:36209] by server-8.bemta-5.messagelabs.com id CF/D4-20246-6560F605; Fri, 05 Oct 2012 16:09:58 +0000 X-Env-Sender: singapore.mr.teo.en.ming@gmail.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1349453396!27997301!1 X-Originating-IP: [209.85.220.45] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23430 invoked from network); 5 Oct 2012 16:09:57 -0000 Received: from mail-pa0-f45.google.com (HELO mail-pa0-f45.google.com) (209.85.220.45) by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 16:09:57 -0000 Received: by mail-pa0-f45.google.com with SMTP id fb10so1979290pad.32 for ; Fri, 05 Oct 2012 09:09:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=qIYHZ+Aq86msNeSi71xuRgUpnG5Am3cU6MlDykwqhMo=; b=oSGSvnU655gJl+tqaTTEuwEH3l56RyAaypP4eOmsHzEe9m3Qt2I+x9jRoGx9LWFnKs ijOlIEJHxdjMqldaDjhKPb42MK7xQo8dXu31jzStczdGa9E96HX0HnRatUtaHR62xMC1 xlACPAvh6Jcm0wXMs3Qc4z1LjCBHvjzaSJ0kcmA1uce/uDbK/8XCQVthvLYUeHfwgQLe qFyeYBQizceboEPVKeQj8KhlM/IJxG5vlzkSSf50ESWZCBz/i9yOd7VX0nwKBaN3dx3o 7AiPJYSuuSB4qIDvbar9cFJ9tKt8XK63WWm2WK0CWRXYhUYXzIWuNll0XjYbMKD0Qy9c q8Hg== Received: by 10.68.232.163 with SMTP id tp3mr31945708pbc.44.1349453395758; Fri, 05 Oct 2012 09:09:55 -0700 (PDT) Received: from [192.168.1.2] (cm152.gamma205.maxonline.com.sg. [202.156.205.152]) by mx.google.com with ESMTPS id j10sm6227109pax.4.2012.10.05.09.09.53 (version=SSLv3 cipher=OTHER); Fri, 05 Oct 2012 09:09:54 -0700 (PDT) Message-ID: <506F064F.9010705@gmail.com> Date: Sat, 06 Oct 2012 00:09:51 +0800 From: "Teo En Ming (Zhang Enming)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Dariusz Krempa , "xen-devel@lists.xen.org" , "Teo En Ming (Zhang Enming)" References: <506E8BFD.9080504@gmail.com> In-Reply-To: Subject: Re: [Xen-devel] Help Needed from Xen Developers: Nasty Yellow Triangle with Exclamation Mark and Error Code 43 in Device Manager in Windows 8 HVM domU X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 05/10/2012 16:05, Dariusz Krempa wrote: > I'm afraid it is not possible to do this in this configuration. Nvidia > does not support virtualization for geforce cards and their drivers > have problems in windows 7, windows 8, vista, server 2008 etc. We can > easy setup virtual machine on windows xp but only with drivers less > than 280.xx and I did some trick (with a huge amount of luck) that I > setup windows 7, but first drivers for windows 8 are 295.73. I think > we will need to wait for different patch for xen to do this. > If You will study device manager under windows 7 or 8 with view set on > then You can see that windows do not recognize properly this memory > range: > mem 0xf4000000-0xf5ffffff > and this is the only range which isn't set in xen patch. Of course I > will try to work with windows 8 for a while but like I said, I'm > afraid this will not work in this moment. Dear Dariusz Krempa, Even with Windows XP Home Edition SP3 HVM domU, I also get the nasty yellow triangle with exclamation mark and error code 43. -- Yours sincerely, Mr. Teo En Ming (Zhang Enming) Singapore _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 16:10:24 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 16:10:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKATQ-0007EB-R0; Fri, 05 Oct 2012 16:10:00 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKATP-0007E4-8T for xen-devel@lists.xen.org; Fri, 05 Oct 2012 16:09:59 +0000 Received: from [85.158.139.83:36209] by server-8.bemta-5.messagelabs.com id CF/D4-20246-6560F605; Fri, 05 Oct 2012 16:09:58 +0000 X-Env-Sender: singapore.mr.teo.en.ming@gmail.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1349453396!27997301!1 X-Originating-IP: [209.85.220.45] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23430 invoked from network); 5 Oct 2012 16:09:57 -0000 Received: from mail-pa0-f45.google.com (HELO mail-pa0-f45.google.com) (209.85.220.45) by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 16:09:57 -0000 Received: by mail-pa0-f45.google.com with SMTP id fb10so1979290pad.32 for ; Fri, 05 Oct 2012 09:09:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=qIYHZ+Aq86msNeSi71xuRgUpnG5Am3cU6MlDykwqhMo=; b=oSGSvnU655gJl+tqaTTEuwEH3l56RyAaypP4eOmsHzEe9m3Qt2I+x9jRoGx9LWFnKs ijOlIEJHxdjMqldaDjhKPb42MK7xQo8dXu31jzStczdGa9E96HX0HnRatUtaHR62xMC1 xlACPAvh6Jcm0wXMs3Qc4z1LjCBHvjzaSJ0kcmA1uce/uDbK/8XCQVthvLYUeHfwgQLe qFyeYBQizceboEPVKeQj8KhlM/IJxG5vlzkSSf50ESWZCBz/i9yOd7VX0nwKBaN3dx3o 7AiPJYSuuSB4qIDvbar9cFJ9tKt8XK63WWm2WK0CWRXYhUYXzIWuNll0XjYbMKD0Qy9c q8Hg== Received: by 10.68.232.163 with SMTP id tp3mr31945708pbc.44.1349453395758; Fri, 05 Oct 2012 09:09:55 -0700 (PDT) Received: from [192.168.1.2] (cm152.gamma205.maxonline.com.sg. [202.156.205.152]) by mx.google.com with ESMTPS id j10sm6227109pax.4.2012.10.05.09.09.53 (version=SSLv3 cipher=OTHER); Fri, 05 Oct 2012 09:09:54 -0700 (PDT) Message-ID: <506F064F.9010705@gmail.com> Date: Sat, 06 Oct 2012 00:09:51 +0800 From: "Teo En Ming (Zhang Enming)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Dariusz Krempa , "xen-devel@lists.xen.org" , "Teo En Ming (Zhang Enming)" References: <506E8BFD.9080504@gmail.com> In-Reply-To: Subject: Re: [Xen-devel] Help Needed from Xen Developers: Nasty Yellow Triangle with Exclamation Mark and Error Code 43 in Device Manager in Windows 8 HVM domU X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 05/10/2012 16:05, Dariusz Krempa wrote: > I'm afraid it is not possible to do this in this configuration. Nvidia > does not support virtualization for geforce cards and their drivers > have problems in windows 7, windows 8, vista, server 2008 etc. We can > easy setup virtual machine on windows xp but only with drivers less > than 280.xx and I did some trick (with a huge amount of luck) that I > setup windows 7, but first drivers for windows 8 are 295.73. I think > we will need to wait for different patch for xen to do this. > If You will study device manager under windows 7 or 8 with view set on > then You can see that windows do not recognize properly this memory > range: > mem 0xf4000000-0xf5ffffff > and this is the only range which isn't set in xen patch. Of course I > will try to work with windows 8 for a while but like I said, I'm > afraid this will not work in this moment. Dear Dariusz Krempa, Even with Windows XP Home Edition SP3 HVM domU, I also get the nasty yellow triangle with exclamation mark and error code 43. -- Yours sincerely, Mr. Teo En Ming (Zhang Enming) Singapore _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 16:11:31 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 16:11:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAUa-0007JK-9g; Fri, 05 Oct 2012 16:11:12 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAUY-0007J9-O6 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 16:11:10 +0000 Received: from [85.158.139.211:42241] by server-8.bemta-5.messagelabs.com id BD/56-20246-E960F605; Fri, 05 Oct 2012 16:11:10 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-5.tower-206.messagelabs.com!1349453469!21192497!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20447 invoked from network); 5 Oct 2012 16:11:09 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 16:11:09 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14968875" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 16:11:09 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 17:11:09 +0100 Message-ID: <1349453467.20946.142.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Fri, 5 Oct 2012 17:11:07 +0100 In-Reply-To: <1349447625.20946.130.camel@zakaz.uk.xensource.com> References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-5-git-send-email-ian.campbell@citrix.com> <1349440338.20946.83.camel@zakaz.uk.xensource.com> <1349447625.20946.130.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: Konrad Rzeszutek Wilk , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 05/14] xen: balloon: use correct type for frame_list X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-10-05 at 15:33 +0100, Ian Campbell wrote: > The issue you describe could only happen for a 32 bit HAP guest if the > guests was given > 16GB (2^(32+PAGE_SHIFT) bytes) of RAM and it was > explicitly trying to balloon memory over that limit, but in order for > that to even be possible it would already need to have made its concept > of a pfn larger than 32 bits. The one place this might matter is in the privcmd IOCTL_PRIVCMD_MMAPBATCH interface for the *foreign* pfn (since a small dom0 needs to be able to build a big domU). Luckily that interface already uses xen_pfn_t, we just need to be a bit careful in the xen_remap_domain_mfn_range case, which Konrad tried to tell me already and he was right... On ARM that meant the following (built but not executed) patch, I suspect the PVH variant needs similar treatment. 8<-------------------------- diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h index ae05e56..ad87917 100644 --- a/arch/arm/include/asm/xen/interface.h +++ b/arch/arm/include/asm/xen/interface.h @@ -43,6 +43,7 @@ DEFINE_GUEST_HANDLE(void); DEFINE_GUEST_HANDLE(uint64_t); DEFINE_GUEST_HANDLE(uint32_t); DEFINE_GUEST_HANDLE(xen_pfn_t); +DEFINE_GUEST_HANDLE(xen_ulong_t); /* Maximum number of virtual CPUs in multi-processor guests. */ #define MAX_VIRT_CPUS 1 diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c index a9946aa..1d64c02 100644 --- a/arch/arm/xen/enlighten.c +++ b/arch/arm/xen/enlighten.c @@ -57,7 +57,7 @@ static int map_foreign_page(unsigned long lpfn, unsigned long fgmfn, .size = 1, .space = XENMAPSPACE_gmfn_foreign, }; - unsigned long idx = fgmfn; + xen_ulong_t idx = fgmfn; xen_pfn_t gpfn = lpfn; set_xen_guest_handle(xatp.idxs, &idx); @@ -73,7 +73,7 @@ static int map_foreign_page(unsigned long lpfn, unsigned long fgmfn, } struct remap_data { - unsigned long fgmfn; /* foreign domain's gmfn */ + xen_pfn_t fgmfn; /* foreign domain's gmfn */ pgprot_t prot; domid_t domid; struct vm_area_struct *vma; @@ -98,7 +98,7 @@ static int remap_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr, int xen_remap_domain_mfn_range(struct vm_area_struct *vma, unsigned long addr, - unsigned long mfn, int nr, + xen_pfn_t mfn, int nr, pgprot_t prot, unsigned domid, struct xen_remap_mfn_info *info) { diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h index 250c254..d67f3c6 100644 --- a/arch/x86/include/asm/xen/interface.h +++ b/arch/x86/include/asm/xen/interface.h @@ -63,6 +63,7 @@ DEFINE_GUEST_HANDLE(void); DEFINE_GUEST_HANDLE(uint64_t); DEFINE_GUEST_HANDLE(uint32_t); DEFINE_GUEST_HANDLE(xen_pfn_t); +DEFINE_GUEST_HANDLE(xen_ulong_t); #endif #ifndef HYPERVISOR_VIRT_START diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h index e5675bc..24e5731 100644 --- a/include/xen/interface/memory.h +++ b/include/xen/interface/memory.h @@ -199,7 +199,7 @@ struct xen_add_to_physmap_range { domid_t foreign_domid; /* IFF gmfn_foreign */ /* Indexes into space being mapped. */ - GUEST_HANDLE(ulong) idxs; + GUEST_HANDLE(xen_ulong_t) idxs; /* GPFN in domid where the source mapping page should appear. */ GUEST_HANDLE(xen_pfn_t) gpfns; diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h index 2f3cb06..59309f3 100644 --- a/include/xen/xen-ops.h +++ b/include/xen/xen-ops.h @@ -27,7 +27,7 @@ struct vm_area_struct; struct xen_remap_mfn_info; int xen_remap_domain_mfn_range(struct vm_area_struct *vma, unsigned long addr, - unsigned long mfn, int nr, + xen_pfn_t mfn, int nr, pgprot_t prot, unsigned domid, struct xen_remap_mfn_info *pvhp); int xen_unmap_domain_mfn_range(struct vm_area_struct *vma, _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 16:11:31 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 16:11:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAUa-0007JK-9g; Fri, 05 Oct 2012 16:11:12 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAUY-0007J9-O6 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 16:11:10 +0000 Received: from [85.158.139.211:42241] by server-8.bemta-5.messagelabs.com id BD/56-20246-E960F605; Fri, 05 Oct 2012 16:11:10 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-5.tower-206.messagelabs.com!1349453469!21192497!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20447 invoked from network); 5 Oct 2012 16:11:09 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 16:11:09 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14968875" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 16:11:09 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 17:11:09 +0100 Message-ID: <1349453467.20946.142.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Fri, 5 Oct 2012 17:11:07 +0100 In-Reply-To: <1349447625.20946.130.camel@zakaz.uk.xensource.com> References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-5-git-send-email-ian.campbell@citrix.com> <1349440338.20946.83.camel@zakaz.uk.xensource.com> <1349447625.20946.130.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: Konrad Rzeszutek Wilk , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH 05/14] xen: balloon: use correct type for frame_list X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-10-05 at 15:33 +0100, Ian Campbell wrote: > The issue you describe could only happen for a 32 bit HAP guest if the > guests was given > 16GB (2^(32+PAGE_SHIFT) bytes) of RAM and it was > explicitly trying to balloon memory over that limit, but in order for > that to even be possible it would already need to have made its concept > of a pfn larger than 32 bits. The one place this might matter is in the privcmd IOCTL_PRIVCMD_MMAPBATCH interface for the *foreign* pfn (since a small dom0 needs to be able to build a big domU). Luckily that interface already uses xen_pfn_t, we just need to be a bit careful in the xen_remap_domain_mfn_range case, which Konrad tried to tell me already and he was right... On ARM that meant the following (built but not executed) patch, I suspect the PVH variant needs similar treatment. 8<-------------------------- diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h index ae05e56..ad87917 100644 --- a/arch/arm/include/asm/xen/interface.h +++ b/arch/arm/include/asm/xen/interface.h @@ -43,6 +43,7 @@ DEFINE_GUEST_HANDLE(void); DEFINE_GUEST_HANDLE(uint64_t); DEFINE_GUEST_HANDLE(uint32_t); DEFINE_GUEST_HANDLE(xen_pfn_t); +DEFINE_GUEST_HANDLE(xen_ulong_t); /* Maximum number of virtual CPUs in multi-processor guests. */ #define MAX_VIRT_CPUS 1 diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c index a9946aa..1d64c02 100644 --- a/arch/arm/xen/enlighten.c +++ b/arch/arm/xen/enlighten.c @@ -57,7 +57,7 @@ static int map_foreign_page(unsigned long lpfn, unsigned long fgmfn, .size = 1, .space = XENMAPSPACE_gmfn_foreign, }; - unsigned long idx = fgmfn; + xen_ulong_t idx = fgmfn; xen_pfn_t gpfn = lpfn; set_xen_guest_handle(xatp.idxs, &idx); @@ -73,7 +73,7 @@ static int map_foreign_page(unsigned long lpfn, unsigned long fgmfn, } struct remap_data { - unsigned long fgmfn; /* foreign domain's gmfn */ + xen_pfn_t fgmfn; /* foreign domain's gmfn */ pgprot_t prot; domid_t domid; struct vm_area_struct *vma; @@ -98,7 +98,7 @@ static int remap_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr, int xen_remap_domain_mfn_range(struct vm_area_struct *vma, unsigned long addr, - unsigned long mfn, int nr, + xen_pfn_t mfn, int nr, pgprot_t prot, unsigned domid, struct xen_remap_mfn_info *info) { diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h index 250c254..d67f3c6 100644 --- a/arch/x86/include/asm/xen/interface.h +++ b/arch/x86/include/asm/xen/interface.h @@ -63,6 +63,7 @@ DEFINE_GUEST_HANDLE(void); DEFINE_GUEST_HANDLE(uint64_t); DEFINE_GUEST_HANDLE(uint32_t); DEFINE_GUEST_HANDLE(xen_pfn_t); +DEFINE_GUEST_HANDLE(xen_ulong_t); #endif #ifndef HYPERVISOR_VIRT_START diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h index e5675bc..24e5731 100644 --- a/include/xen/interface/memory.h +++ b/include/xen/interface/memory.h @@ -199,7 +199,7 @@ struct xen_add_to_physmap_range { domid_t foreign_domid; /* IFF gmfn_foreign */ /* Indexes into space being mapped. */ - GUEST_HANDLE(ulong) idxs; + GUEST_HANDLE(xen_ulong_t) idxs; /* GPFN in domid where the source mapping page should appear. */ GUEST_HANDLE(xen_pfn_t) gpfns; diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h index 2f3cb06..59309f3 100644 --- a/include/xen/xen-ops.h +++ b/include/xen/xen-ops.h @@ -27,7 +27,7 @@ struct vm_area_struct; struct xen_remap_mfn_info; int xen_remap_domain_mfn_range(struct vm_area_struct *vma, unsigned long addr, - unsigned long mfn, int nr, + xen_pfn_t mfn, int nr, pgprot_t prot, unsigned domid, struct xen_remap_mfn_info *pvhp); int xen_unmap_domain_mfn_range(struct vm_area_struct *vma, _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 16:18:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 16:18:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAbB-0007Zi-57; Fri, 05 Oct 2012 16:18:01 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAb9-0007Zd-Ab for xen-devel@lists.xen.org; Fri, 05 Oct 2012 16:17:59 +0000 Received: from [85.158.139.83:18002] by server-14.bemta-5.messagelabs.com id 91/4E-31065-6380F605; Fri, 05 Oct 2012 16:17:58 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1349453878!33595569!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9243 invoked from network); 5 Oct 2012 16:17:58 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 16:17:58 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14969064" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 16:17:58 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 17:17:58 +0100 Message-ID: <1349453876.20946.143.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Fri, 5 Oct 2012 17:17:56 +0100 In-Reply-To: <1349453467.20946.142.camel@zakaz.uk.xensource.com> References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-5-git-send-email-ian.campbell@citrix.com> <1349440338.20946.83.camel@zakaz.uk.xensource.com> <1349447625.20946.130.camel@zakaz.uk.xensource.com> <1349453467.20946.142.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 05/14] xen: balloon: use correct type for frame_list X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-10-05 at 17:11 +0100, Ian Campbell wrote: > On Fri, 2012-10-05 at 15:33 +0100, Ian Campbell wrote: > > The issue you describe could only happen for a 32 bit HAP guest if the > > guests was given > 16GB (2^(32+PAGE_SHIFT) bytes) of RAM and it was > > explicitly trying to balloon memory over that limit, but in order for > > that to even be possible it would already need to have made its concept > > of a pfn larger than 32 bits. > > The one place this might matter is in the privcmd > IOCTL_PRIVCMD_MMAPBATCH interface for the *foreign* pfn (since a small > dom0 needs to be able to build a big domU). Luckily that interface > already uses xen_pfn_t, we just need to be a bit careful in the > xen_remap_domain_mfn_range case, which Konrad tried to tell me already > and he was right... > > On ARM that meant the following (built but not executed) patch, I > suspect the PVH variant needs similar treatment. NB, this is mostly just a bug fix to "arm: implement foreign mapping using XENMEM_add_to_physmap_range" and/or "arm: implement remap interfaces needed for privcmd mappings." > 8<-------------------------- > > diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h > index ae05e56..ad87917 100644 > --- a/arch/arm/include/asm/xen/interface.h > +++ b/arch/arm/include/asm/xen/interface.h > @@ -43,6 +43,7 @@ DEFINE_GUEST_HANDLE(void); > DEFINE_GUEST_HANDLE(uint64_t); > DEFINE_GUEST_HANDLE(uint32_t); > DEFINE_GUEST_HANDLE(xen_pfn_t); > +DEFINE_GUEST_HANDLE(xen_ulong_t); > > /* Maximum number of virtual CPUs in multi-processor guests. */ > #define MAX_VIRT_CPUS 1 > diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c > index a9946aa..1d64c02 100644 > --- a/arch/arm/xen/enlighten.c > +++ b/arch/arm/xen/enlighten.c > @@ -57,7 +57,7 @@ static int map_foreign_page(unsigned long lpfn, unsigned long fgmfn, > .size = 1, > .space = XENMAPSPACE_gmfn_foreign, > }; > - unsigned long idx = fgmfn; > + xen_ulong_t idx = fgmfn; > xen_pfn_t gpfn = lpfn; > > set_xen_guest_handle(xatp.idxs, &idx); > @@ -73,7 +73,7 @@ static int map_foreign_page(unsigned long lpfn, unsigned long fgmfn, > } > > struct remap_data { > - unsigned long fgmfn; /* foreign domain's gmfn */ > + xen_pfn_t fgmfn; /* foreign domain's gmfn */ > pgprot_t prot; > domid_t domid; > struct vm_area_struct *vma; > @@ -98,7 +98,7 @@ static int remap_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr, > > int xen_remap_domain_mfn_range(struct vm_area_struct *vma, > unsigned long addr, > - unsigned long mfn, int nr, > + xen_pfn_t mfn, int nr, > pgprot_t prot, unsigned domid, > struct xen_remap_mfn_info *info) > { > diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h > index 250c254..d67f3c6 100644 > --- a/arch/x86/include/asm/xen/interface.h > +++ b/arch/x86/include/asm/xen/interface.h > @@ -63,6 +63,7 @@ DEFINE_GUEST_HANDLE(void); > DEFINE_GUEST_HANDLE(uint64_t); > DEFINE_GUEST_HANDLE(uint32_t); > DEFINE_GUEST_HANDLE(xen_pfn_t); > +DEFINE_GUEST_HANDLE(xen_ulong_t); > #endif > > #ifndef HYPERVISOR_VIRT_START > diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h > index e5675bc..24e5731 100644 > --- a/include/xen/interface/memory.h > +++ b/include/xen/interface/memory.h > @@ -199,7 +199,7 @@ struct xen_add_to_physmap_range { > domid_t foreign_domid; /* IFF gmfn_foreign */ > > /* Indexes into space being mapped. */ > - GUEST_HANDLE(ulong) idxs; > + GUEST_HANDLE(xen_ulong_t) idxs; > > /* GPFN in domid where the source mapping page should appear. */ > GUEST_HANDLE(xen_pfn_t) gpfns; > diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h > index 2f3cb06..59309f3 100644 > --- a/include/xen/xen-ops.h > +++ b/include/xen/xen-ops.h > @@ -27,7 +27,7 @@ struct vm_area_struct; > struct xen_remap_mfn_info; > int xen_remap_domain_mfn_range(struct vm_area_struct *vma, > unsigned long addr, > - unsigned long mfn, int nr, > + xen_pfn_t mfn, int nr, > pgprot_t prot, unsigned domid, > struct xen_remap_mfn_info *pvhp); > int xen_unmap_domain_mfn_range(struct vm_area_struct *vma, > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 16:18:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 16:18:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAbB-0007Zi-57; Fri, 05 Oct 2012 16:18:01 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAb9-0007Zd-Ab for xen-devel@lists.xen.org; Fri, 05 Oct 2012 16:17:59 +0000 Received: from [85.158.139.83:18002] by server-14.bemta-5.messagelabs.com id 91/4E-31065-6380F605; Fri, 05 Oct 2012 16:17:58 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1349453878!33595569!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9243 invoked from network); 5 Oct 2012 16:17:58 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 16:17:58 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14969064" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 16:17:58 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 17:17:58 +0100 Message-ID: <1349453876.20946.143.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Stefano Stabellini Date: Fri, 5 Oct 2012 17:17:56 +0100 In-Reply-To: <1349453467.20946.142.camel@zakaz.uk.xensource.com> References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-5-git-send-email-ian.campbell@citrix.com> <1349440338.20946.83.camel@zakaz.uk.xensource.com> <1349447625.20946.130.camel@zakaz.uk.xensource.com> <1349453467.20946.142.camel@zakaz.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: "xen-devel@lists.xen.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 05/14] xen: balloon: use correct type for frame_list X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-10-05 at 17:11 +0100, Ian Campbell wrote: > On Fri, 2012-10-05 at 15:33 +0100, Ian Campbell wrote: > > The issue you describe could only happen for a 32 bit HAP guest if the > > guests was given > 16GB (2^(32+PAGE_SHIFT) bytes) of RAM and it was > > explicitly trying to balloon memory over that limit, but in order for > > that to even be possible it would already need to have made its concept > > of a pfn larger than 32 bits. > > The one place this might matter is in the privcmd > IOCTL_PRIVCMD_MMAPBATCH interface for the *foreign* pfn (since a small > dom0 needs to be able to build a big domU). Luckily that interface > already uses xen_pfn_t, we just need to be a bit careful in the > xen_remap_domain_mfn_range case, which Konrad tried to tell me already > and he was right... > > On ARM that meant the following (built but not executed) patch, I > suspect the PVH variant needs similar treatment. NB, this is mostly just a bug fix to "arm: implement foreign mapping using XENMEM_add_to_physmap_range" and/or "arm: implement remap interfaces needed for privcmd mappings." > 8<-------------------------- > > diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h > index ae05e56..ad87917 100644 > --- a/arch/arm/include/asm/xen/interface.h > +++ b/arch/arm/include/asm/xen/interface.h > @@ -43,6 +43,7 @@ DEFINE_GUEST_HANDLE(void); > DEFINE_GUEST_HANDLE(uint64_t); > DEFINE_GUEST_HANDLE(uint32_t); > DEFINE_GUEST_HANDLE(xen_pfn_t); > +DEFINE_GUEST_HANDLE(xen_ulong_t); > > /* Maximum number of virtual CPUs in multi-processor guests. */ > #define MAX_VIRT_CPUS 1 > diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c > index a9946aa..1d64c02 100644 > --- a/arch/arm/xen/enlighten.c > +++ b/arch/arm/xen/enlighten.c > @@ -57,7 +57,7 @@ static int map_foreign_page(unsigned long lpfn, unsigned long fgmfn, > .size = 1, > .space = XENMAPSPACE_gmfn_foreign, > }; > - unsigned long idx = fgmfn; > + xen_ulong_t idx = fgmfn; > xen_pfn_t gpfn = lpfn; > > set_xen_guest_handle(xatp.idxs, &idx); > @@ -73,7 +73,7 @@ static int map_foreign_page(unsigned long lpfn, unsigned long fgmfn, > } > > struct remap_data { > - unsigned long fgmfn; /* foreign domain's gmfn */ > + xen_pfn_t fgmfn; /* foreign domain's gmfn */ > pgprot_t prot; > domid_t domid; > struct vm_area_struct *vma; > @@ -98,7 +98,7 @@ static int remap_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr, > > int xen_remap_domain_mfn_range(struct vm_area_struct *vma, > unsigned long addr, > - unsigned long mfn, int nr, > + xen_pfn_t mfn, int nr, > pgprot_t prot, unsigned domid, > struct xen_remap_mfn_info *info) > { > diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h > index 250c254..d67f3c6 100644 > --- a/arch/x86/include/asm/xen/interface.h > +++ b/arch/x86/include/asm/xen/interface.h > @@ -63,6 +63,7 @@ DEFINE_GUEST_HANDLE(void); > DEFINE_GUEST_HANDLE(uint64_t); > DEFINE_GUEST_HANDLE(uint32_t); > DEFINE_GUEST_HANDLE(xen_pfn_t); > +DEFINE_GUEST_HANDLE(xen_ulong_t); > #endif > > #ifndef HYPERVISOR_VIRT_START > diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h > index e5675bc..24e5731 100644 > --- a/include/xen/interface/memory.h > +++ b/include/xen/interface/memory.h > @@ -199,7 +199,7 @@ struct xen_add_to_physmap_range { > domid_t foreign_domid; /* IFF gmfn_foreign */ > > /* Indexes into space being mapped. */ > - GUEST_HANDLE(ulong) idxs; > + GUEST_HANDLE(xen_ulong_t) idxs; > > /* GPFN in domid where the source mapping page should appear. */ > GUEST_HANDLE(xen_pfn_t) gpfns; > diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h > index 2f3cb06..59309f3 100644 > --- a/include/xen/xen-ops.h > +++ b/include/xen/xen-ops.h > @@ -27,7 +27,7 @@ struct vm_area_struct; > struct xen_remap_mfn_info; > int xen_remap_domain_mfn_range(struct vm_area_struct *vma, > unsigned long addr, > - unsigned long mfn, int nr, > + xen_pfn_t mfn, int nr, > pgprot_t prot, unsigned domid, > struct xen_remap_mfn_info *pvhp); > int xen_unmap_domain_mfn_range(struct vm_area_struct *vma, > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 16:23:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 16:23:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAfm-0007i3-Lc; Fri, 05 Oct 2012 16:22:46 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAfk-0007hQ-6h for xen-devel@lists.xen.org; Fri, 05 Oct 2012 16:22:44 +0000 Received: from [85.158.139.211:64742] by server-2.bemta-5.messagelabs.com id EF/D1-28944-3590F605; Fri, 05 Oct 2012 16:22:43 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-9.tower-206.messagelabs.com!1349454162!19731477!1 X-Originating-IP: [81.169.146.162] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MjE2NDY=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MjE2NDY=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14056 invoked from network); 5 Oct 2012 16:22:42 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162) by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 16:22:42 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESMg X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-070-120.pools.arcor-ip.net [88.65.70.120]) by smtp.strato.de (josoe mo9) (RZmta 30.20 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id m02ab7o95FAieM for ; Fri, 5 Oct 2012 18:22:42 +0200 (CEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id CCC8E1863E for ; Fri, 5 Oct 2012 18:22:41 +0200 (CEST) MIME-Version: 1.0 X-Mercurial-Node: a4053f1f58ec42a24c963cac98d66f27fa54b8cc Message-Id: In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.7.5 Date: Fri, 05 Oct 2012 18:22:37 +0200 From: Olaf Hering To: xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH 1 of 5] xend/pvscsi: fix passing of SCSI control LUNs X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Olaf Hering # Date 1349453188 -7200 # Node ID a4053f1f58ec42a24c963cac98d66f27fa54b8cc # Parent 3eb9a891889a734a21643f02dac19b1b0cbe53f7 xend/pvscsi: fix passing of SCSI control LUNs Currently pvscsi can not pass SCSI devices that have just a scsi_generic node. In the following example sg3 is a control LUN for the disk sdd. But vscsi=['4:0:2:0,0:0:0:0'] does not work because the internal 'devname' variable remains None. Later writing p-devname to xenstore fails because None is not a valid string variable. Since devname is used for just informational purpose use sg also as devname. carron:~ $ lsscsi -g [0:0:0:0] disk ATA FK0032CAAZP HPF2 /dev/sda /dev/sg0 [4:0:0:0] disk HP P2000G3 FC/iSCSI T100 /dev/sdb /dev/sg1 [4:0:1:0] disk HP P2000G3 FC/iSCSI T100 /dev/sdc /dev/sg2 [4:0:2:0] storage HP HSV400 0950 - /dev/sg3 [4:0:2:1] disk HP HSV400 0950 /dev/sdd /dev/sg4 [4:0:3:0] storage HP HSV400 0950 - /dev/sg5 [4:0:3:1] disk HP HSV400 0950 /dev/sde /dev/sg6 Signed-off-by: Olaf Hering Acked-by: Ian Campbell diff -r 3eb9a891889a -r a4053f1f58ec tools/python/xen/util/vscsi_util.py --- a/tools/python/xen/util/vscsi_util.py +++ b/tools/python/xen/util/vscsi_util.py @@ -105,6 +105,8 @@ def _vscsi_get_scsidevices_by_lsscsi(opt devname = None try: sg = s[-1].split('/dev/')[1] + if devname is None: + devname = sg scsi_id = _vscsi_get_scsiid(sg) except IndexError: sg = None _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 16:23:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 16:23:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAfm-0007i3-Lc; Fri, 05 Oct 2012 16:22:46 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAfk-0007hQ-6h for xen-devel@lists.xen.org; Fri, 05 Oct 2012 16:22:44 +0000 Received: from [85.158.139.211:64742] by server-2.bemta-5.messagelabs.com id EF/D1-28944-3590F605; Fri, 05 Oct 2012 16:22:43 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-9.tower-206.messagelabs.com!1349454162!19731477!1 X-Originating-IP: [81.169.146.162] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MjE2NDY=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MjE2NDY=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14056 invoked from network); 5 Oct 2012 16:22:42 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162) by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 16:22:42 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESMg X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-070-120.pools.arcor-ip.net [88.65.70.120]) by smtp.strato.de (josoe mo9) (RZmta 30.20 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id m02ab7o95FAieM for ; Fri, 5 Oct 2012 18:22:42 +0200 (CEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id CCC8E1863E for ; Fri, 5 Oct 2012 18:22:41 +0200 (CEST) MIME-Version: 1.0 X-Mercurial-Node: a4053f1f58ec42a24c963cac98d66f27fa54b8cc Message-Id: In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.7.5 Date: Fri, 05 Oct 2012 18:22:37 +0200 From: Olaf Hering To: xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH 1 of 5] xend/pvscsi: fix passing of SCSI control LUNs X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Olaf Hering # Date 1349453188 -7200 # Node ID a4053f1f58ec42a24c963cac98d66f27fa54b8cc # Parent 3eb9a891889a734a21643f02dac19b1b0cbe53f7 xend/pvscsi: fix passing of SCSI control LUNs Currently pvscsi can not pass SCSI devices that have just a scsi_generic node. In the following example sg3 is a control LUN for the disk sdd. But vscsi=['4:0:2:0,0:0:0:0'] does not work because the internal 'devname' variable remains None. Later writing p-devname to xenstore fails because None is not a valid string variable. Since devname is used for just informational purpose use sg also as devname. carron:~ $ lsscsi -g [0:0:0:0] disk ATA FK0032CAAZP HPF2 /dev/sda /dev/sg0 [4:0:0:0] disk HP P2000G3 FC/iSCSI T100 /dev/sdb /dev/sg1 [4:0:1:0] disk HP P2000G3 FC/iSCSI T100 /dev/sdc /dev/sg2 [4:0:2:0] storage HP HSV400 0950 - /dev/sg3 [4:0:2:1] disk HP HSV400 0950 /dev/sdd /dev/sg4 [4:0:3:0] storage HP HSV400 0950 - /dev/sg5 [4:0:3:1] disk HP HSV400 0950 /dev/sde /dev/sg6 Signed-off-by: Olaf Hering Acked-by: Ian Campbell diff -r 3eb9a891889a -r a4053f1f58ec tools/python/xen/util/vscsi_util.py --- a/tools/python/xen/util/vscsi_util.py +++ b/tools/python/xen/util/vscsi_util.py @@ -105,6 +105,8 @@ def _vscsi_get_scsidevices_by_lsscsi(opt devname = None try: sg = s[-1].split('/dev/')[1] + if devname is None: + devname = sg scsi_id = _vscsi_get_scsiid(sg) except IndexError: sg = None _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 16:23:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 16:23:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAfn-0007iJ-GH; Fri, 05 Oct 2012 16:22:47 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAfk-0007hT-NK for xen-devel@lists.xen.org; Fri, 05 Oct 2012 16:22:44 +0000 Received: from [85.158.143.35:31797] by server-1.bemta-4.messagelabs.com id 26/BE-05684-3590F605; Fri, 05 Oct 2012 16:22:43 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-11.tower-21.messagelabs.com!1349454162!14373154!1 X-Originating-IP: [81.169.146.161] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NDUwOTc=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NDUwOTc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6494 invoked from network); 5 Oct 2012 16:22:43 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161) by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 16:22:43 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESMg X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-070-120.pools.arcor-ip.net [88.65.70.120]) by smtp.strato.de (josoe mo31) (RZmta 30.20 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id e02f1eo95FNuFb for ; Fri, 5 Oct 2012 18:22:42 +0200 (CEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id AD94418631 for ; Fri, 5 Oct 2012 18:22:41 +0200 (CEST) MIME-Version: 1.0 Message-Id: User-Agent: Mercurial-patchbomb/1.7.5 Date: Fri, 05 Oct 2012 18:22:36 +0200 From: Olaf Hering To: xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH 0 of 5] misc tools changes, backport request X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org The following 5 patches were sent shortly before 4.2 was released, so they were not considered (I think). I propose the vscsi changes and the stubdom parallel build change for inclusion in 4.2.1. Olaf Changes: xend/pvscsi: fix passing of SCSI control LUNs xend/pvscsi: fix usage of persistant device names for SCSI devices xend/pvscsi: update sysfs parser for Linux 3.0 stubdom: fix parallel build by expanding CROSS_MAKE tools/configure.ac: fill PACKAGE_TARNAME in AC_INIT stubdom/Makefile | 54 +++++++++++++++++------------------- tools/configure.ac | 2 - tools/python/xen/util/vscsi_util.py | 32 ++++++++++++++++----- 3 files changed, 52 insertions(+), 36 deletions(-) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 16:23:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 16:23:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAfn-0007iJ-GH; Fri, 05 Oct 2012 16:22:47 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAfk-0007hT-NK for xen-devel@lists.xen.org; Fri, 05 Oct 2012 16:22:44 +0000 Received: from [85.158.143.35:31797] by server-1.bemta-4.messagelabs.com id 26/BE-05684-3590F605; Fri, 05 Oct 2012 16:22:43 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-11.tower-21.messagelabs.com!1349454162!14373154!1 X-Originating-IP: [81.169.146.161] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NDUwOTc=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NDUwOTc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6494 invoked from network); 5 Oct 2012 16:22:43 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161) by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 16:22:43 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESMg X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-070-120.pools.arcor-ip.net [88.65.70.120]) by smtp.strato.de (josoe mo31) (RZmta 30.20 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id e02f1eo95FNuFb for ; Fri, 5 Oct 2012 18:22:42 +0200 (CEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id AD94418631 for ; Fri, 5 Oct 2012 18:22:41 +0200 (CEST) MIME-Version: 1.0 Message-Id: User-Agent: Mercurial-patchbomb/1.7.5 Date: Fri, 05 Oct 2012 18:22:36 +0200 From: Olaf Hering To: xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH 0 of 5] misc tools changes, backport request X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org The following 5 patches were sent shortly before 4.2 was released, so they were not considered (I think). I propose the vscsi changes and the stubdom parallel build change for inclusion in 4.2.1. Olaf Changes: xend/pvscsi: fix passing of SCSI control LUNs xend/pvscsi: fix usage of persistant device names for SCSI devices xend/pvscsi: update sysfs parser for Linux 3.0 stubdom: fix parallel build by expanding CROSS_MAKE tools/configure.ac: fill PACKAGE_TARNAME in AC_INIT stubdom/Makefile | 54 +++++++++++++++++------------------- tools/configure.ac | 2 - tools/python/xen/util/vscsi_util.py | 32 ++++++++++++++++----- 3 files changed, 52 insertions(+), 36 deletions(-) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 16:23:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 16:23:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAfo-0007ih-88; Fri, 05 Oct 2012 16:22:48 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAfl-0007hR-2l for xen-devel@lists.xen.org; Fri, 05 Oct 2012 16:22:45 +0000 Received: from [85.158.143.35:36645] by server-2.bemta-4.messagelabs.com id A5/D9-06610-4590F605; Fri, 05 Oct 2012 16:22:44 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-16.tower-21.messagelabs.com!1349454163!15002372!1 X-Originating-IP: [81.169.146.160] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MzUzOTI=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MzUzOTI=\n,UPPERCASE_25_50 X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4990 invoked from network); 5 Oct 2012 16:22:43 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160) by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 16:22:43 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESMg X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-070-120.pools.arcor-ip.net [88.65.70.120]) by smtp.strato.de (jorabe mo27) (RZmta 30.20 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id k05bedo95FdQwD for ; Fri, 5 Oct 2012 18:22:43 +0200 (CEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id 3417318641 for ; Fri, 5 Oct 2012 18:22:42 +0200 (CEST) MIME-Version: 1.0 X-Mercurial-Node: 3753af2506dab7f92d43693104686efd812372a5 Message-Id: <3753af2506dab7f92d43.1349454160@probook.site> In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.7.5 Date: Fri, 05 Oct 2012 18:22:40 +0200 From: Olaf Hering To: xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH 4 of 5] stubdom: fix parallel build by expanding CROSS_MAKE X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Olaf Hering # Date 1349453236 -7200 # Node ID 3753af2506dab7f92d43693104686efd812372a5 # Parent c18b7d4f0d665d8bc9eb4ff62aad1575088db1a8 stubdom: fix parallel build by expanding CROSS_MAKE Recently I changed my rpm xen.spec file from doing 'make -C tools -j N && make stubdom' to 'make -j N stubdom' because stubdom depends on tools, so both get built. The result was the failure below. .... mkdir -p grub-x86_64 CPPFLAGS="-isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include -D__MINIOS__ -DHAVE_LIBC -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include/posix -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../tools/xenstore -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include/x86 -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include/x86/x86_64 -U __linux__ -U __FreeBSD__ -U __sun__ -nostdinc -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include/posix -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/cross-root-x86_64/x86_64-xen-elf/include -isystem /usr/lib64/gcc/x86_64-suse-linux/4.7/include -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/lwip-x86_64/src/include -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/lwip-x86_64/src/include/ipv4 -I/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/include -I/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../xen/include" CFLAGS="-mno-red-zone -O1 -fno-omit-frame-pointer -m64 -mno-red-zone -fno-reorder-blocks -fno-asynchronous-unwind-tables -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -fno-stack-protector -fno-exceptions" make DESTDIR= -C grub OBJ_DIR=/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/grub-x86_64 make[2]: Entering directory `/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/grub' make[2]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule. make[2]: *** INTERNAL: readdir: Bad file descriptor . Stop. make[2]: Makefile: Field 'stem' not cached: Makefile make[2]: Leaving directory `/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/grub' make[1]: *** [grub] Error 2 [ -d mini-os-x86_64-xenstore ] || \ for i in $(cd /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os ; find . -type d) ; do \ mkdir -p mini-os-x86_64-xenstore/$i ; \ done .... Expanding every occurrence of CROSS_MAKE qvoids this error. It also has the nice side effect of actually enabling parallel build for stubdom. According to the GNU make documentation $(MAKE) gets its special meaning only if it appears directly in the recipe: http://www.gnu.org/software/make/manual/html_node/MAKE-Variable.html Signed-off-by: Olaf Hering diff -r c18b7d4f0d66 -r 3753af2506da stubdom/Makefile --- a/stubdom/Makefile +++ b/stubdom/Makefile @@ -76,8 +76,6 @@ TARGET_LDFLAGS += -nostdlib -L$(CROSS_PR TARGETS=ioemu c caml grub xenstore -CROSS_MAKE := $(MAKE) DESTDIR= - .PHONY: all all: build ifeq ($(STUBDOM_SUPPORTED),1) @@ -113,8 +111,8 @@ cross-newlib: $(NEWLIB_STAMPFILE) mkdir -p newlib-$(XEN_TARGET_ARCH) ( cd newlib-$(XEN_TARGET_ARCH) && \ CC_FOR_TARGET="$(CC) $(TARGET_CPPFLAGS) $(TARGET_CFLAGS) $(NEWLIB_CFLAGS)" AR_FOR_TARGET=$(AR) LD_FOR_TARGET=$(LD) RANLIB_FOR_TARGET=$(RANLIB) ../newlib-$(NEWLIB_VERSION)/configure --prefix=$(CROSS_PREFIX) --verbose --target=$(GNU_TARGET_ARCH)-xen-elf --enable-newlib-io-long-long --disable-multilib && \ - $(CROSS_MAKE) && \ - $(CROSS_MAKE) install ) + $(MAKE) DESTDIR= && \ + $(MAKE) DESTDIR= install ) ############ # Cross-zlib @@ -133,8 +131,8 @@ cross-zlib: $(ZLIB_STAMPFILE) $(ZLIB_STAMPFILE): zlib-$(XEN_TARGET_ARCH) $(NEWLIB_STAMPFILE) ( cd $< && \ CFLAGS="$(TARGET_CPPFLAGS) $(TARGET_CFLAGS)" CC=$(CC) ./configure --prefix=$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf && \ - $(CROSS_MAKE) libz.a && \ - $(CROSS_MAKE) install ) + $(MAKE) DESTDIR= libz.a && \ + $(MAKE) DESTDIR= install ) ############## # Cross-libpci @@ -158,7 +156,7 @@ cross-libpci: $(LIBPCI_STAMPFILE) chmod u+w lib/config.h && \ echo '#define PCILIB_VERSION "$(LIBPCI_VERSION)"' >> lib/config.h && \ ln -sf ../../libpci.config.mak lib/config.mk && \ - $(CROSS_MAKE) CC="$(CC) $(TARGET_CPPFLAGS) $(TARGET_CFLAGS) -I$(call realpath,$(MINI_OS)/include)" lib/libpci.a && \ + $(MAKE) DESTDIR= CC="$(CC) $(TARGET_CPPFLAGS) $(TARGET_CFLAGS) -I$(call realpath,$(MINI_OS)/include)" lib/libpci.a && \ $(INSTALL_DATA) lib/libpci.a $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/lib/ && \ $(INSTALL_DIR) $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/include/pci && \ $(INSTALL_DATA) lib/config.h lib/header.h lib/pci.h lib/types.h $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/include/pci/ \ @@ -203,8 +201,8 @@ cross-ocaml: $(OCAML_STAMPFILE) -no-pthread -no-shared-libs -no-tk -no-curses \ -cc "$(CC) -U_FORTIFY_SOURCE -fno-stack-protector -mno-red-zone" $(foreach i,$(MINIOS_HASNOT),sed -i 's,^\(#define HAS_$(i)\),//\1,' ocaml-$(XEN_TARGET_ARCH)/config/s.h ; ) - $(CROSS_MAKE) -C ocaml-$(XEN_TARGET_ARCH) world - $(CROSS_MAKE) -C ocaml-$(XEN_TARGET_ARCH) opt + $(MAKE) DESTDIR= -C ocaml-$(XEN_TARGET_ARCH) world + $(MAKE) DESTDIR= -C ocaml-$(XEN_TARGET_ARCH) opt $(MAKE) -C ocaml-$(XEN_TARGET_ARCH) install touch $@ @@ -219,7 +217,7 @@ QEMU_ROOT := $(shell if [ -d "$(CONFIG_Q ifeq ($(QEMU_ROOT),.) $(XEN_ROOT)/tools/qemu-xen-traditional-dir: - $(CROSS_MAKE) -C $(XEN_ROOT)/tools qemu-xen-traditional-dir-find + $(MAKE) DESTDIR= -C $(XEN_ROOT)/tools qemu-xen-traditional-dir-find ioemu/linkfarm.stamp: $(XEN_ROOT)/tools/qemu-xen-traditional-dir mkdir -p ioemu @@ -250,7 +248,7 @@ mk-headers-$(XEN_TARGET_ARCH): ioemu/lin ( [ -h include/xen/libelf ] || ln -sf $(XEN_ROOT)/tools/include/xen/libelf include/xen/libelf ) && \ mkdir -p include/xen-foreign && \ ln -sf $(wildcard $(XEN_ROOT)/tools/include/xen-foreign/*) include/xen-foreign/ && \ - $(CROSS_MAKE) -C include/xen-foreign/ && \ + $(MAKE) DESTDIR= -C include/xen-foreign/ && \ ( [ -h include/xen/foreign ] || ln -sf ../xen-foreign include/xen/foreign ) mkdir -p libxc-$(XEN_TARGET_ARCH) [ -h libxc-$(XEN_TARGET_ARCH)/Makefile ] || ( cd libxc-$(XEN_TARGET_ARCH) && \ @@ -267,7 +265,7 @@ mk-headers-$(XEN_TARGET_ARCH): ioemu/lin ln -sf $(XEN_ROOT)/tools/xenstore/*.c . && \ ln -sf $(XEN_ROOT)/tools/xenstore/*.h . && \ ln -sf $(XEN_ROOT)/tools/xenstore/Makefile . ) - $(CROSS_MAKE) -C $(MINI_OS) links + $(MAKE) DESTDIR= -C $(MINI_OS) links touch mk-headers-$(XEN_TARGET_ARCH) TARGETS_MINIOS=$(addprefix mini-os-$(XEN_TARGET_ARCH)-,$(TARGETS)) @@ -284,7 +282,7 @@ TARGETS_MINIOS=$(addprefix mini-os-$(XEN .PHONY: libxc libxc: libxc-$(XEN_TARGET_ARCH)/libxenctrl.a libxc-$(XEN_TARGET_ARCH)/libxenguest.a libxc-$(XEN_TARGET_ARCH)/libxenctrl.a: cross-zlib - CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(CROSS_MAKE) -C libxc-$(XEN_TARGET_ARCH) + CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(MAKE) DESTDIR= -C libxc-$(XEN_TARGET_ARCH) libxc-$(XEN_TARGET_ARCH)/libxenguest.a: libxc-$(XEN_TARGET_ARCH)/libxenctrl.a @@ -302,7 +300,7 @@ ioemu: cross-zlib cross-libpci libxc TARGET_CFLAGS="$(TARGET_CFLAGS)" \ TARGET_LDFLAGS="$(TARGET_LDFLAGS)" \ $(QEMU_ROOT)/xen-setup-stubdom ) - $(CROSS_MAKE) -C ioemu -f $(QEMU_ROOT)/Makefile + $(MAKE) DESTDIR= -C ioemu -f $(QEMU_ROOT)/Makefile ###### # caml @@ -310,7 +308,7 @@ ioemu: cross-zlib cross-libpci libxc .PHONY: caml caml: $(CROSS_ROOT) - CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(CROSS_MAKE) -C $@ LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) OCAMLC_CROSS_PREFIX=$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/bin/ + CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(MAKE) DESTDIR= -C $@ LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) OCAMLC_CROSS_PREFIX=$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/bin/ ### # C @@ -318,7 +316,7 @@ caml: $(CROSS_ROOT) .PHONY: c c: $(CROSS_ROOT) - CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(CROSS_MAKE) -C $@ LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) + CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(MAKE) DESTDIR= -C $@ LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) ###### # Grub @@ -337,7 +335,7 @@ grub-upstream: grub-$(GRUB_VERSION).tar. .PHONY: grub grub: grub-upstream $(CROSS_ROOT) mkdir -p grub-$(XEN_TARGET_ARCH) - CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(CROSS_MAKE) -C $@ OBJ_DIR=$(CURDIR)/grub-$(XEN_TARGET_ARCH) + CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(MAKE) DESTDIR= -C $@ OBJ_DIR=$(CURDIR)/grub-$(XEN_TARGET_ARCH) ########## # xenstore @@ -345,7 +343,7 @@ grub: grub-upstream $(CROSS_ROOT) .PHONY: xenstore xenstore: $(CROSS_ROOT) - CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(CROSS_MAKE) -C $@ xenstored.a CONFIG_STUBDOM=y + CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(MAKE) DESTDIR= -C $@ xenstored.a CONFIG_STUBDOM=y ######## # minios @@ -354,23 +352,23 @@ xenstore: $(CROSS_ROOT) .PHONY: ioemu-stubdom ioemu-stubdom: APP_OBJS=$(CURDIR)/ioemu/i386-stubdom/qemu.a $(CURDIR)/ioemu/i386-stubdom/libqemu.a $(CURDIR)/ioemu/libqemu_common.a ioemu-stubdom: mini-os-$(XEN_TARGET_ARCH)-ioemu lwip-$(XEN_TARGET_ARCH) libxc ioemu - DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/ioemu-minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(APP_OBJS)" + DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/ioemu-minios.cfg" $(MAKE) DESTDIR= -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(APP_OBJS)" .PHONY: caml-stubdom caml-stubdom: mini-os-$(XEN_TARGET_ARCH)-caml lwip-$(XEN_TARGET_ARCH) libxc cross-ocaml caml - DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/caml/minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(CURDIR)/caml/main-caml.o $(CURDIR)/caml/caml.o $(CAMLLIB)/libasmrun.a" + DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/caml/minios.cfg" $(MAKE) DESTDIR= -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(CURDIR)/caml/main-caml.o $(CURDIR)/caml/caml.o $(CAMLLIB)/libasmrun.a" .PHONY: c-stubdom c-stubdom: mini-os-$(XEN_TARGET_ARCH)-c lwip-$(XEN_TARGET_ARCH) libxc c - DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/c/minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS=$(CURDIR)/c/main.a + DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/c/minios.cfg" $(MAKE) DESTDIR= -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS=$(CURDIR)/c/main.a .PHONY: pv-grub pv-grub: mini-os-$(XEN_TARGET_ARCH)-grub libxc grub - DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/grub/minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< APP_OBJS=$(CURDIR)/grub-$(XEN_TARGET_ARCH)/main.a + DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/grub/minios.cfg" $(MAKE) DESTDIR= -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< APP_OBJS=$(CURDIR)/grub-$(XEN_TARGET_ARCH)/main.a .PHONY: xenstore-stubdom xenstore-stubdom: mini-os-$(XEN_TARGET_ARCH)-xenstore libxc xenstore - DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/xenstore-minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< APP_OBJS=$(CURDIR)/xenstore/xenstored.a + DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/xenstore-minios.cfg" $(MAKE) DESTDIR= -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< APP_OBJS=$(CURDIR)/xenstore/xenstored.a ######### # install @@ -412,13 +410,13 @@ clean: rm -fr mini-os-$(XEN_TARGET_ARCH)-caml rm -fr mini-os-$(XEN_TARGET_ARCH)-grub rm -fr mini-os-$(XEN_TARGET_ARCH)-xenstore - $(CROSS_MAKE) -C caml clean - $(CROSS_MAKE) -C c clean + $(MAKE) DESTDIR= -C caml clean + $(MAKE) DESTDIR= -C c clean rm -fr grub-$(XEN_TARGET_ARCH) rm -f $(STUBDOMPATH) - [ ! -d libxc-$(XEN_TARGET_ARCH) ] || $(CROSS_MAKE) -C libxc-$(XEN_TARGET_ARCH) clean - -[ ! -d ioemu ] || $(CROSS_MAKE) -C ioemu clean - -[ ! -d xenstore ] || $(CROSS_MAKE) -C xenstore clean + [ ! -d libxc-$(XEN_TARGET_ARCH) ] || $(MAKE) DESTDIR= -C libxc-$(XEN_TARGET_ARCH) clean + -[ ! -d ioemu ] || $(MAKE) DESTDIR= -C ioemu clean + -[ ! -d xenstore ] || $(MAKE) DESTDIR= -C xenstore clean # clean the cross-compilation result .PHONY: crossclean _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 16:23:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 16:23:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAfo-0007ih-88; Fri, 05 Oct 2012 16:22:48 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAfl-0007hR-2l for xen-devel@lists.xen.org; Fri, 05 Oct 2012 16:22:45 +0000 Received: from [85.158.143.35:36645] by server-2.bemta-4.messagelabs.com id A5/D9-06610-4590F605; Fri, 05 Oct 2012 16:22:44 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-16.tower-21.messagelabs.com!1349454163!15002372!1 X-Originating-IP: [81.169.146.160] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MzUzOTI=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MzUzOTI=\n,UPPERCASE_25_50 X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4990 invoked from network); 5 Oct 2012 16:22:43 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160) by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 16:22:43 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESMg X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-070-120.pools.arcor-ip.net [88.65.70.120]) by smtp.strato.de (jorabe mo27) (RZmta 30.20 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id k05bedo95FdQwD for ; Fri, 5 Oct 2012 18:22:43 +0200 (CEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id 3417318641 for ; Fri, 5 Oct 2012 18:22:42 +0200 (CEST) MIME-Version: 1.0 X-Mercurial-Node: 3753af2506dab7f92d43693104686efd812372a5 Message-Id: <3753af2506dab7f92d43.1349454160@probook.site> In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.7.5 Date: Fri, 05 Oct 2012 18:22:40 +0200 From: Olaf Hering To: xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH 4 of 5] stubdom: fix parallel build by expanding CROSS_MAKE X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Olaf Hering # Date 1349453236 -7200 # Node ID 3753af2506dab7f92d43693104686efd812372a5 # Parent c18b7d4f0d665d8bc9eb4ff62aad1575088db1a8 stubdom: fix parallel build by expanding CROSS_MAKE Recently I changed my rpm xen.spec file from doing 'make -C tools -j N && make stubdom' to 'make -j N stubdom' because stubdom depends on tools, so both get built. The result was the failure below. .... mkdir -p grub-x86_64 CPPFLAGS="-isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include -D__MINIOS__ -DHAVE_LIBC -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include/posix -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../tools/xenstore -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include/x86 -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include/x86/x86_64 -U __linux__ -U __FreeBSD__ -U __sun__ -nostdinc -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include/posix -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/cross-root-x86_64/x86_64-xen-elf/include -isystem /usr/lib64/gcc/x86_64-suse-linux/4.7/include -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/lwip-x86_64/src/include -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/lwip-x86_64/src/include/ipv4 -I/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/include -I/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../xen/include" CFLAGS="-mno-red-zone -O1 -fno-omit-frame-pointer -m64 -mno-red-zone -fno-reorder-blocks -fno-asynchronous-unwind-tables -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -fno-stack-protector -fno-exceptions" make DESTDIR= -C grub OBJ_DIR=/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/grub-x86_64 make[2]: Entering directory `/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/grub' make[2]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule. make[2]: *** INTERNAL: readdir: Bad file descriptor . Stop. make[2]: Makefile: Field 'stem' not cached: Makefile make[2]: Leaving directory `/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/grub' make[1]: *** [grub] Error 2 [ -d mini-os-x86_64-xenstore ] || \ for i in $(cd /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os ; find . -type d) ; do \ mkdir -p mini-os-x86_64-xenstore/$i ; \ done .... Expanding every occurrence of CROSS_MAKE qvoids this error. It also has the nice side effect of actually enabling parallel build for stubdom. According to the GNU make documentation $(MAKE) gets its special meaning only if it appears directly in the recipe: http://www.gnu.org/software/make/manual/html_node/MAKE-Variable.html Signed-off-by: Olaf Hering diff -r c18b7d4f0d66 -r 3753af2506da stubdom/Makefile --- a/stubdom/Makefile +++ b/stubdom/Makefile @@ -76,8 +76,6 @@ TARGET_LDFLAGS += -nostdlib -L$(CROSS_PR TARGETS=ioemu c caml grub xenstore -CROSS_MAKE := $(MAKE) DESTDIR= - .PHONY: all all: build ifeq ($(STUBDOM_SUPPORTED),1) @@ -113,8 +111,8 @@ cross-newlib: $(NEWLIB_STAMPFILE) mkdir -p newlib-$(XEN_TARGET_ARCH) ( cd newlib-$(XEN_TARGET_ARCH) && \ CC_FOR_TARGET="$(CC) $(TARGET_CPPFLAGS) $(TARGET_CFLAGS) $(NEWLIB_CFLAGS)" AR_FOR_TARGET=$(AR) LD_FOR_TARGET=$(LD) RANLIB_FOR_TARGET=$(RANLIB) ../newlib-$(NEWLIB_VERSION)/configure --prefix=$(CROSS_PREFIX) --verbose --target=$(GNU_TARGET_ARCH)-xen-elf --enable-newlib-io-long-long --disable-multilib && \ - $(CROSS_MAKE) && \ - $(CROSS_MAKE) install ) + $(MAKE) DESTDIR= && \ + $(MAKE) DESTDIR= install ) ############ # Cross-zlib @@ -133,8 +131,8 @@ cross-zlib: $(ZLIB_STAMPFILE) $(ZLIB_STAMPFILE): zlib-$(XEN_TARGET_ARCH) $(NEWLIB_STAMPFILE) ( cd $< && \ CFLAGS="$(TARGET_CPPFLAGS) $(TARGET_CFLAGS)" CC=$(CC) ./configure --prefix=$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf && \ - $(CROSS_MAKE) libz.a && \ - $(CROSS_MAKE) install ) + $(MAKE) DESTDIR= libz.a && \ + $(MAKE) DESTDIR= install ) ############## # Cross-libpci @@ -158,7 +156,7 @@ cross-libpci: $(LIBPCI_STAMPFILE) chmod u+w lib/config.h && \ echo '#define PCILIB_VERSION "$(LIBPCI_VERSION)"' >> lib/config.h && \ ln -sf ../../libpci.config.mak lib/config.mk && \ - $(CROSS_MAKE) CC="$(CC) $(TARGET_CPPFLAGS) $(TARGET_CFLAGS) -I$(call realpath,$(MINI_OS)/include)" lib/libpci.a && \ + $(MAKE) DESTDIR= CC="$(CC) $(TARGET_CPPFLAGS) $(TARGET_CFLAGS) -I$(call realpath,$(MINI_OS)/include)" lib/libpci.a && \ $(INSTALL_DATA) lib/libpci.a $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/lib/ && \ $(INSTALL_DIR) $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/include/pci && \ $(INSTALL_DATA) lib/config.h lib/header.h lib/pci.h lib/types.h $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/include/pci/ \ @@ -203,8 +201,8 @@ cross-ocaml: $(OCAML_STAMPFILE) -no-pthread -no-shared-libs -no-tk -no-curses \ -cc "$(CC) -U_FORTIFY_SOURCE -fno-stack-protector -mno-red-zone" $(foreach i,$(MINIOS_HASNOT),sed -i 's,^\(#define HAS_$(i)\),//\1,' ocaml-$(XEN_TARGET_ARCH)/config/s.h ; ) - $(CROSS_MAKE) -C ocaml-$(XEN_TARGET_ARCH) world - $(CROSS_MAKE) -C ocaml-$(XEN_TARGET_ARCH) opt + $(MAKE) DESTDIR= -C ocaml-$(XEN_TARGET_ARCH) world + $(MAKE) DESTDIR= -C ocaml-$(XEN_TARGET_ARCH) opt $(MAKE) -C ocaml-$(XEN_TARGET_ARCH) install touch $@ @@ -219,7 +217,7 @@ QEMU_ROOT := $(shell if [ -d "$(CONFIG_Q ifeq ($(QEMU_ROOT),.) $(XEN_ROOT)/tools/qemu-xen-traditional-dir: - $(CROSS_MAKE) -C $(XEN_ROOT)/tools qemu-xen-traditional-dir-find + $(MAKE) DESTDIR= -C $(XEN_ROOT)/tools qemu-xen-traditional-dir-find ioemu/linkfarm.stamp: $(XEN_ROOT)/tools/qemu-xen-traditional-dir mkdir -p ioemu @@ -250,7 +248,7 @@ mk-headers-$(XEN_TARGET_ARCH): ioemu/lin ( [ -h include/xen/libelf ] || ln -sf $(XEN_ROOT)/tools/include/xen/libelf include/xen/libelf ) && \ mkdir -p include/xen-foreign && \ ln -sf $(wildcard $(XEN_ROOT)/tools/include/xen-foreign/*) include/xen-foreign/ && \ - $(CROSS_MAKE) -C include/xen-foreign/ && \ + $(MAKE) DESTDIR= -C include/xen-foreign/ && \ ( [ -h include/xen/foreign ] || ln -sf ../xen-foreign include/xen/foreign ) mkdir -p libxc-$(XEN_TARGET_ARCH) [ -h libxc-$(XEN_TARGET_ARCH)/Makefile ] || ( cd libxc-$(XEN_TARGET_ARCH) && \ @@ -267,7 +265,7 @@ mk-headers-$(XEN_TARGET_ARCH): ioemu/lin ln -sf $(XEN_ROOT)/tools/xenstore/*.c . && \ ln -sf $(XEN_ROOT)/tools/xenstore/*.h . && \ ln -sf $(XEN_ROOT)/tools/xenstore/Makefile . ) - $(CROSS_MAKE) -C $(MINI_OS) links + $(MAKE) DESTDIR= -C $(MINI_OS) links touch mk-headers-$(XEN_TARGET_ARCH) TARGETS_MINIOS=$(addprefix mini-os-$(XEN_TARGET_ARCH)-,$(TARGETS)) @@ -284,7 +282,7 @@ TARGETS_MINIOS=$(addprefix mini-os-$(XEN .PHONY: libxc libxc: libxc-$(XEN_TARGET_ARCH)/libxenctrl.a libxc-$(XEN_TARGET_ARCH)/libxenguest.a libxc-$(XEN_TARGET_ARCH)/libxenctrl.a: cross-zlib - CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(CROSS_MAKE) -C libxc-$(XEN_TARGET_ARCH) + CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(MAKE) DESTDIR= -C libxc-$(XEN_TARGET_ARCH) libxc-$(XEN_TARGET_ARCH)/libxenguest.a: libxc-$(XEN_TARGET_ARCH)/libxenctrl.a @@ -302,7 +300,7 @@ ioemu: cross-zlib cross-libpci libxc TARGET_CFLAGS="$(TARGET_CFLAGS)" \ TARGET_LDFLAGS="$(TARGET_LDFLAGS)" \ $(QEMU_ROOT)/xen-setup-stubdom ) - $(CROSS_MAKE) -C ioemu -f $(QEMU_ROOT)/Makefile + $(MAKE) DESTDIR= -C ioemu -f $(QEMU_ROOT)/Makefile ###### # caml @@ -310,7 +308,7 @@ ioemu: cross-zlib cross-libpci libxc .PHONY: caml caml: $(CROSS_ROOT) - CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(CROSS_MAKE) -C $@ LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) OCAMLC_CROSS_PREFIX=$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/bin/ + CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(MAKE) DESTDIR= -C $@ LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) OCAMLC_CROSS_PREFIX=$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/bin/ ### # C @@ -318,7 +316,7 @@ caml: $(CROSS_ROOT) .PHONY: c c: $(CROSS_ROOT) - CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(CROSS_MAKE) -C $@ LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) + CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(MAKE) DESTDIR= -C $@ LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) ###### # Grub @@ -337,7 +335,7 @@ grub-upstream: grub-$(GRUB_VERSION).tar. .PHONY: grub grub: grub-upstream $(CROSS_ROOT) mkdir -p grub-$(XEN_TARGET_ARCH) - CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(CROSS_MAKE) -C $@ OBJ_DIR=$(CURDIR)/grub-$(XEN_TARGET_ARCH) + CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(MAKE) DESTDIR= -C $@ OBJ_DIR=$(CURDIR)/grub-$(XEN_TARGET_ARCH) ########## # xenstore @@ -345,7 +343,7 @@ grub: grub-upstream $(CROSS_ROOT) .PHONY: xenstore xenstore: $(CROSS_ROOT) - CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(CROSS_MAKE) -C $@ xenstored.a CONFIG_STUBDOM=y + CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(MAKE) DESTDIR= -C $@ xenstored.a CONFIG_STUBDOM=y ######## # minios @@ -354,23 +352,23 @@ xenstore: $(CROSS_ROOT) .PHONY: ioemu-stubdom ioemu-stubdom: APP_OBJS=$(CURDIR)/ioemu/i386-stubdom/qemu.a $(CURDIR)/ioemu/i386-stubdom/libqemu.a $(CURDIR)/ioemu/libqemu_common.a ioemu-stubdom: mini-os-$(XEN_TARGET_ARCH)-ioemu lwip-$(XEN_TARGET_ARCH) libxc ioemu - DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/ioemu-minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(APP_OBJS)" + DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/ioemu-minios.cfg" $(MAKE) DESTDIR= -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(APP_OBJS)" .PHONY: caml-stubdom caml-stubdom: mini-os-$(XEN_TARGET_ARCH)-caml lwip-$(XEN_TARGET_ARCH) libxc cross-ocaml caml - DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/caml/minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(CURDIR)/caml/main-caml.o $(CURDIR)/caml/caml.o $(CAMLLIB)/libasmrun.a" + DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/caml/minios.cfg" $(MAKE) DESTDIR= -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(CURDIR)/caml/main-caml.o $(CURDIR)/caml/caml.o $(CAMLLIB)/libasmrun.a" .PHONY: c-stubdom c-stubdom: mini-os-$(XEN_TARGET_ARCH)-c lwip-$(XEN_TARGET_ARCH) libxc c - DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/c/minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS=$(CURDIR)/c/main.a + DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/c/minios.cfg" $(MAKE) DESTDIR= -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS=$(CURDIR)/c/main.a .PHONY: pv-grub pv-grub: mini-os-$(XEN_TARGET_ARCH)-grub libxc grub - DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/grub/minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< APP_OBJS=$(CURDIR)/grub-$(XEN_TARGET_ARCH)/main.a + DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/grub/minios.cfg" $(MAKE) DESTDIR= -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< APP_OBJS=$(CURDIR)/grub-$(XEN_TARGET_ARCH)/main.a .PHONY: xenstore-stubdom xenstore-stubdom: mini-os-$(XEN_TARGET_ARCH)-xenstore libxc xenstore - DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/xenstore-minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< APP_OBJS=$(CURDIR)/xenstore/xenstored.a + DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/xenstore-minios.cfg" $(MAKE) DESTDIR= -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< APP_OBJS=$(CURDIR)/xenstore/xenstored.a ######### # install @@ -412,13 +410,13 @@ clean: rm -fr mini-os-$(XEN_TARGET_ARCH)-caml rm -fr mini-os-$(XEN_TARGET_ARCH)-grub rm -fr mini-os-$(XEN_TARGET_ARCH)-xenstore - $(CROSS_MAKE) -C caml clean - $(CROSS_MAKE) -C c clean + $(MAKE) DESTDIR= -C caml clean + $(MAKE) DESTDIR= -C c clean rm -fr grub-$(XEN_TARGET_ARCH) rm -f $(STUBDOMPATH) - [ ! -d libxc-$(XEN_TARGET_ARCH) ] || $(CROSS_MAKE) -C libxc-$(XEN_TARGET_ARCH) clean - -[ ! -d ioemu ] || $(CROSS_MAKE) -C ioemu clean - -[ ! -d xenstore ] || $(CROSS_MAKE) -C xenstore clean + [ ! -d libxc-$(XEN_TARGET_ARCH) ] || $(MAKE) DESTDIR= -C libxc-$(XEN_TARGET_ARCH) clean + -[ ! -d ioemu ] || $(MAKE) DESTDIR= -C ioemu clean + -[ ! -d xenstore ] || $(MAKE) DESTDIR= -C xenstore clean # clean the cross-compilation result .PHONY: crossclean _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 16:23:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 16:23:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAfn-0007iA-1o; Fri, 05 Oct 2012 16:22:47 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAfk-0007hR-JG for xen-devel@lists.xen.org; Fri, 05 Oct 2012 16:22:44 +0000 Received: from [85.158.143.99:7932] by server-2.bemta-4.messagelabs.com id B2/D9-06610-3590F605; Fri, 05 Oct 2012 16:22:43 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-5.tower-216.messagelabs.com!1349454163!32689829!1 X-Originating-IP: [81.169.146.160] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MzUzOTI=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MzUzOTI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11094 invoked from network); 5 Oct 2012 16:22:43 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160) by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 16:22:43 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESMg X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-070-120.pools.arcor-ip.net [88.65.70.120]) by smtp.strato.de (jored mo13) (RZmta 30.20 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id y064eao95FfMkK for ; Fri, 5 Oct 2012 18:22:43 +0200 (CEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id 6221018642 for ; Fri, 5 Oct 2012 18:22:42 +0200 (CEST) MIME-Version: 1.0 X-Mercurial-Node: 93e92c12bc13952ed15312f937a37e6ab2d197ad Message-Id: <93e92c12bc13952ed153.1349454161@probook.site> In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.7.5 Date: Fri, 05 Oct 2012 18:22:41 +0200 From: Olaf Hering To: xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH 5 of 5] tools/configure.ac: fill PACKAGE_TARNAME in AC_INIT X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Olaf Hering # Date 1349453874 -7200 # Node ID 93e92c12bc13952ed15312f937a37e6ab2d197ad # Parent 3753af2506dab7f92d43693104686efd812372a5 tools/configure.ac: fill PACKAGE_TARNAME in AC_INIT Upcoming changes may move DOCDIR from Config.mk to config/Tools.mk. To preserve the currently used path, which ends with /xen, specify a value for PACKAGE_TARNAME. Without this change the path would end with /xen-hypervisor. Please rerun autoconf after applying this. Signed-off-by: Olaf Hering Acked-by: Ian Campbell diff -r 3753af2506da -r 93e92c12bc13 tools/configure.ac --- a/tools/configure.ac +++ b/tools/configure.ac @@ -3,7 +3,7 @@ AC_PREREQ([2.67]) AC_INIT([Xen Hypervisor], m4_esyscmd([../version.sh ../xen/Makefile]), - [xen-devel@lists.xen.org]) + [xen-devel@lists.xen.org], [xen], [http://www.xen.org/]) AC_CONFIG_SRCDIR([libxl/libxl.c]) AC_CONFIG_FILES([../config/Tools.mk]) AC_CONFIG_HEADERS([config.h]) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 16:23:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 16:23:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAfn-0007iA-1o; Fri, 05 Oct 2012 16:22:47 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAfk-0007hR-JG for xen-devel@lists.xen.org; Fri, 05 Oct 2012 16:22:44 +0000 Received: from [85.158.143.99:7932] by server-2.bemta-4.messagelabs.com id B2/D9-06610-3590F605; Fri, 05 Oct 2012 16:22:43 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-5.tower-216.messagelabs.com!1349454163!32689829!1 X-Originating-IP: [81.169.146.160] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MzUzOTI=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MzUzOTI=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11094 invoked from network); 5 Oct 2012 16:22:43 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160) by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 16:22:43 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESMg X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-070-120.pools.arcor-ip.net [88.65.70.120]) by smtp.strato.de (jored mo13) (RZmta 30.20 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id y064eao95FfMkK for ; Fri, 5 Oct 2012 18:22:43 +0200 (CEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id 6221018642 for ; Fri, 5 Oct 2012 18:22:42 +0200 (CEST) MIME-Version: 1.0 X-Mercurial-Node: 93e92c12bc13952ed15312f937a37e6ab2d197ad Message-Id: <93e92c12bc13952ed153.1349454161@probook.site> In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.7.5 Date: Fri, 05 Oct 2012 18:22:41 +0200 From: Olaf Hering To: xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH 5 of 5] tools/configure.ac: fill PACKAGE_TARNAME in AC_INIT X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Olaf Hering # Date 1349453874 -7200 # Node ID 93e92c12bc13952ed15312f937a37e6ab2d197ad # Parent 3753af2506dab7f92d43693104686efd812372a5 tools/configure.ac: fill PACKAGE_TARNAME in AC_INIT Upcoming changes may move DOCDIR from Config.mk to config/Tools.mk. To preserve the currently used path, which ends with /xen, specify a value for PACKAGE_TARNAME. Without this change the path would end with /xen-hypervisor. Please rerun autoconf after applying this. Signed-off-by: Olaf Hering Acked-by: Ian Campbell diff -r 3753af2506da -r 93e92c12bc13 tools/configure.ac --- a/tools/configure.ac +++ b/tools/configure.ac @@ -3,7 +3,7 @@ AC_PREREQ([2.67]) AC_INIT([Xen Hypervisor], m4_esyscmd([../version.sh ../xen/Makefile]), - [xen-devel@lists.xen.org]) + [xen-devel@lists.xen.org], [xen], [http://www.xen.org/]) AC_CONFIG_SRCDIR([libxl/libxl.c]) AC_CONFIG_FILES([../config/Tools.mk]) AC_CONFIG_HEADERS([config.h]) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 16:23:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 16:23:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAfm-0007hv-AT; Fri, 05 Oct 2012 16:22:46 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAfk-0007hP-8v for xen-devel@lists.xen.org; Fri, 05 Oct 2012 16:22:44 +0000 Received: from [85.158.138.51:14603] by server-10.bemta-3.messagelabs.com id 1C/34-02525-3590F605; Fri, 05 Oct 2012 16:22:43 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-16.tower-174.messagelabs.com!1349454162!33178976!1 X-Originating-IP: [81.169.146.162] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MjE2NDY=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MjE2NDY=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19220 invoked from network); 5 Oct 2012 16:22:42 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162) by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 16:22:42 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESMg X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-070-120.pools.arcor-ip.net [88.65.70.120]) by smtp.strato.de (jorabe mo30) (RZmta 30.20 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id n05cdao95FQgjU for ; Fri, 5 Oct 2012 18:22:42 +0200 (CEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id E817E1863F for ; Fri, 5 Oct 2012 18:22:41 +0200 (CEST) MIME-Version: 1.0 X-Mercurial-Node: 9f361dc559ddf9e468bbc039584aa8837abdf2bb Message-Id: <9f361dc559ddf9e468bb.1349454158@probook.site> In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.7.5 Date: Fri, 05 Oct 2012 18:22:38 +0200 From: Olaf Hering To: xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH 2 of 5] xend/pvscsi: fix usage of persistant device names for SCSI devices X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Olaf Hering # Date 1349453205 -7200 # Node ID 9f361dc559ddf9e468bbc039584aa8837abdf2bb # Parent a4053f1f58ec42a24c963cac98d66f27fa54b8cc xend/pvscsi: fix usage of persistant device names for SCSI devices Currently the callers of vscsi_get_scsidevices() do not pass a mask string. This will call "lsscsi -g '[]'", which causes a lsscsi syntax error. As a result the sysfs parser _vscsi_get_scsidevices() is used. But this parser is broken and the specified names in the config file are not found. Using a mask '*' if no mask was given will call lsscsi correctly and the following config is parsed correctly: vscsi=[ '/dev/sg3, 0:0:0:0', '/dev/disk/by-id/wwn-0x600508b4000cf1c30000800000410000, 0:0:0:1' ] Signed-off-by: Olaf Hering Acked-by: Ian Campbell diff -r a4053f1f58ec -r 9f361dc559dd tools/python/xen/util/vscsi_util.py --- a/tools/python/xen/util/vscsi_util.py +++ b/tools/python/xen/util/vscsi_util.py @@ -150,7 +150,7 @@ def _vscsi_get_scsidevices_by_sysfs(): return devices -def vscsi_get_scsidevices(mask=""): +def vscsi_get_scsidevices(mask="*"): """ get all scsi devices information """ devices = _vscsi_get_scsidevices_by_lsscsi("[%s]" % mask) @@ -279,7 +279,7 @@ def get_scsi_device(pHCTL): return _make_scsi_record(scsi_info) return None -def get_all_scsi_devices(mask=""): +def get_all_scsi_devices(mask="*"): scsi_records = [] for scsi_info in vscsi_get_scsidevices(mask): scsi_record = _make_scsi_record(scsi_info) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 16:23:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 16:23:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAfm-0007hv-AT; Fri, 05 Oct 2012 16:22:46 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAfk-0007hP-8v for xen-devel@lists.xen.org; Fri, 05 Oct 2012 16:22:44 +0000 Received: from [85.158.138.51:14603] by server-10.bemta-3.messagelabs.com id 1C/34-02525-3590F605; Fri, 05 Oct 2012 16:22:43 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-16.tower-174.messagelabs.com!1349454162!33178976!1 X-Originating-IP: [81.169.146.162] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MjE2NDY=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MjE2NDY=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19220 invoked from network); 5 Oct 2012 16:22:42 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162) by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 16:22:42 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESMg X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-070-120.pools.arcor-ip.net [88.65.70.120]) by smtp.strato.de (jorabe mo30) (RZmta 30.20 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id n05cdao95FQgjU for ; Fri, 5 Oct 2012 18:22:42 +0200 (CEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id E817E1863F for ; Fri, 5 Oct 2012 18:22:41 +0200 (CEST) MIME-Version: 1.0 X-Mercurial-Node: 9f361dc559ddf9e468bbc039584aa8837abdf2bb Message-Id: <9f361dc559ddf9e468bb.1349454158@probook.site> In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.7.5 Date: Fri, 05 Oct 2012 18:22:38 +0200 From: Olaf Hering To: xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH 2 of 5] xend/pvscsi: fix usage of persistant device names for SCSI devices X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Olaf Hering # Date 1349453205 -7200 # Node ID 9f361dc559ddf9e468bbc039584aa8837abdf2bb # Parent a4053f1f58ec42a24c963cac98d66f27fa54b8cc xend/pvscsi: fix usage of persistant device names for SCSI devices Currently the callers of vscsi_get_scsidevices() do not pass a mask string. This will call "lsscsi -g '[]'", which causes a lsscsi syntax error. As a result the sysfs parser _vscsi_get_scsidevices() is used. But this parser is broken and the specified names in the config file are not found. Using a mask '*' if no mask was given will call lsscsi correctly and the following config is parsed correctly: vscsi=[ '/dev/sg3, 0:0:0:0', '/dev/disk/by-id/wwn-0x600508b4000cf1c30000800000410000, 0:0:0:1' ] Signed-off-by: Olaf Hering Acked-by: Ian Campbell diff -r a4053f1f58ec -r 9f361dc559dd tools/python/xen/util/vscsi_util.py --- a/tools/python/xen/util/vscsi_util.py +++ b/tools/python/xen/util/vscsi_util.py @@ -150,7 +150,7 @@ def _vscsi_get_scsidevices_by_sysfs(): return devices -def vscsi_get_scsidevices(mask=""): +def vscsi_get_scsidevices(mask="*"): """ get all scsi devices information """ devices = _vscsi_get_scsidevices_by_lsscsi("[%s]" % mask) @@ -279,7 +279,7 @@ def get_scsi_device(pHCTL): return _make_scsi_record(scsi_info) return None -def get_all_scsi_devices(mask=""): +def get_all_scsi_devices(mask="*"): scsi_records = [] for scsi_info in vscsi_get_scsidevices(mask): scsi_record = _make_scsi_record(scsi_info) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 16:23:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 16:23:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAfn-0007iV-Sx; Fri, 05 Oct 2012 16:22:47 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAfk-0007hS-T7 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 16:22:45 +0000 Received: from [85.158.139.211:18033] by server-7.bemta-5.messagelabs.com id A5/E2-00431-3590F605; Fri, 05 Oct 2012 16:22:43 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-12.tower-206.messagelabs.com!1349454163!20232028!1 X-Originating-IP: [81.169.146.161] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NDUwOTc=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NDUwOTc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5512 invoked from network); 5 Oct 2012 16:22:43 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161) by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 16:22:43 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESMg X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-070-120.pools.arcor-ip.net [88.65.70.120]) by smtp.strato.de (jored mo10) (RZmta 30.20 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 90648ao95FAHUd for ; Fri, 5 Oct 2012 18:22:42 +0200 (CEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id 11F4B18640 for ; Fri, 5 Oct 2012 18:22:42 +0200 (CEST) MIME-Version: 1.0 X-Mercurial-Node: c18b7d4f0d665d8bc9eb4ff62aad1575088db1a8 Message-Id: In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.7.5 Date: Fri, 05 Oct 2012 18:22:39 +0200 From: Olaf Hering To: xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH 3 of 5] xend/pvscsi: update sysfs parser for Linux 3.0 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Olaf Hering # Date 1349453226 -7200 # Node ID c18b7d4f0d665d8bc9eb4ff62aad1575088db1a8 # Parent 9f361dc559ddf9e468bbc039584aa8837abdf2bb xend/pvscsi: update sysfs parser for Linux 3.0 The sysfs parser for /sys/bus/scsi/devices understands only the layout of kernel version 2.6.16. This looks as follows: /sys/bus/scsi/devices/1:0:0:0/block:sda is a symlink to /sys/block/sda/ /sys/bus/scsi/devices/1:0:0:0/scsi_generic:sg1 is a symlink to /sys/class/scsi_generic/sg1 Both directories contain a 'dev' file with the major:minor information. This patch updates the used regex strings to match also the colon to make it more robust against possible future changes. In kernel version 3.0 the layout changed: /sys/bus/scsi/devices/ contains now additional symlinks to directories such as host1 and target1:0:0. This patch ignores these as they do not point to the desired scsi devices. They just clutter the devices array. The directory layout in '1:0:0:0' changed as well, the 'type:name' notation was replaced with 'type/name' directories: /sys/bus/scsi/devices/1:0:0:0/block/sda/ /sys/bus/scsi/devices/1:0:0:0/scsi_generic/sg1/ Both directories contain a 'dev' file with the major:minor information. This patch adds additional code to walk the subdir to find the 'dev' file to make sure the given subdirectory is really the kernel name. In addition this patch makes sure devname is not None. Signed-off-by: Olaf Hering diff -r 9f361dc559dd -r c18b7d4f0d66 tools/python/xen/util/vscsi_util.py --- a/tools/python/xen/util/vscsi_util.py +++ b/tools/python/xen/util/vscsi_util.py @@ -130,20 +130,36 @@ def _vscsi_get_scsidevices_by_sysfs(): for dirpath, dirnames, files in os.walk(sysfs_mnt + SYSFS_SCSI_PATH): for hctl in dirnames: + if len(hctl.split(':')) != 4: + continue paths = os.path.join(dirpath, hctl) devname = None sg = None scsi_id = None for f in os.listdir(paths): realpath = os.path.realpath(os.path.join(paths, f)) - if re.match('^block', f) or \ - re.match('^tape', f) or \ - re.match('^scsi_changer', f) or \ - re.match('^onstream_tape', f): + if re.match('^block:', f) or \ + re.match('^tape:', f) or \ + re.match('^scsi_changer:', f) or \ + re.match('^onstream_tape:', f): devname = os.path.basename(realpath) + elif f == "block" or \ + f == "tape" or \ + f == "scsi_changer" or \ + f == "onstream_tape": + for dir in os.listdir(os.path.join(paths, f)): + if os.path.exists(os.path.join(paths, f, dir, "dev")): + devname = os.path.basename(dir) - if re.match('^scsi_generic', f): + if re.match('^scsi_generic:', f): sg = os.path.basename(realpath) + elif f == "scsi_generic": + for dir in os.listdir(os.path.join(paths, f)): + if os.path.exists(os.path.join(paths, f, dir, "dev")): + sg = os.path.basename(dir) + if sg: + if devname is None: + devname = sg scsi_id = _vscsi_get_scsiid(sg) devices.append([hctl, devname, sg, scsi_id]) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 16:23:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 16:23:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAfn-0007iV-Sx; Fri, 05 Oct 2012 16:22:47 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAfk-0007hS-T7 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 16:22:45 +0000 Received: from [85.158.139.211:18033] by server-7.bemta-5.messagelabs.com id A5/E2-00431-3590F605; Fri, 05 Oct 2012 16:22:43 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-12.tower-206.messagelabs.com!1349454163!20232028!1 X-Originating-IP: [81.169.146.161] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NDUwOTc=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NDUwOTc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5512 invoked from network); 5 Oct 2012 16:22:43 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161) by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 16:22:43 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESMg X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-070-120.pools.arcor-ip.net [88.65.70.120]) by smtp.strato.de (jored mo10) (RZmta 30.20 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 90648ao95FAHUd for ; Fri, 5 Oct 2012 18:22:42 +0200 (CEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id 11F4B18640 for ; Fri, 5 Oct 2012 18:22:42 +0200 (CEST) MIME-Version: 1.0 X-Mercurial-Node: c18b7d4f0d665d8bc9eb4ff62aad1575088db1a8 Message-Id: In-Reply-To: References: User-Agent: Mercurial-patchbomb/1.7.5 Date: Fri, 05 Oct 2012 18:22:39 +0200 From: Olaf Hering To: xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH 3 of 5] xend/pvscsi: update sysfs parser for Linux 3.0 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Olaf Hering # Date 1349453226 -7200 # Node ID c18b7d4f0d665d8bc9eb4ff62aad1575088db1a8 # Parent 9f361dc559ddf9e468bbc039584aa8837abdf2bb xend/pvscsi: update sysfs parser for Linux 3.0 The sysfs parser for /sys/bus/scsi/devices understands only the layout of kernel version 2.6.16. This looks as follows: /sys/bus/scsi/devices/1:0:0:0/block:sda is a symlink to /sys/block/sda/ /sys/bus/scsi/devices/1:0:0:0/scsi_generic:sg1 is a symlink to /sys/class/scsi_generic/sg1 Both directories contain a 'dev' file with the major:minor information. This patch updates the used regex strings to match also the colon to make it more robust against possible future changes. In kernel version 3.0 the layout changed: /sys/bus/scsi/devices/ contains now additional symlinks to directories such as host1 and target1:0:0. This patch ignores these as they do not point to the desired scsi devices. They just clutter the devices array. The directory layout in '1:0:0:0' changed as well, the 'type:name' notation was replaced with 'type/name' directories: /sys/bus/scsi/devices/1:0:0:0/block/sda/ /sys/bus/scsi/devices/1:0:0:0/scsi_generic/sg1/ Both directories contain a 'dev' file with the major:minor information. This patch adds additional code to walk the subdir to find the 'dev' file to make sure the given subdirectory is really the kernel name. In addition this patch makes sure devname is not None. Signed-off-by: Olaf Hering diff -r 9f361dc559dd -r c18b7d4f0d66 tools/python/xen/util/vscsi_util.py --- a/tools/python/xen/util/vscsi_util.py +++ b/tools/python/xen/util/vscsi_util.py @@ -130,20 +130,36 @@ def _vscsi_get_scsidevices_by_sysfs(): for dirpath, dirnames, files in os.walk(sysfs_mnt + SYSFS_SCSI_PATH): for hctl in dirnames: + if len(hctl.split(':')) != 4: + continue paths = os.path.join(dirpath, hctl) devname = None sg = None scsi_id = None for f in os.listdir(paths): realpath = os.path.realpath(os.path.join(paths, f)) - if re.match('^block', f) or \ - re.match('^tape', f) or \ - re.match('^scsi_changer', f) or \ - re.match('^onstream_tape', f): + if re.match('^block:', f) or \ + re.match('^tape:', f) or \ + re.match('^scsi_changer:', f) or \ + re.match('^onstream_tape:', f): devname = os.path.basename(realpath) + elif f == "block" or \ + f == "tape" or \ + f == "scsi_changer" or \ + f == "onstream_tape": + for dir in os.listdir(os.path.join(paths, f)): + if os.path.exists(os.path.join(paths, f, dir, "dev")): + devname = os.path.basename(dir) - if re.match('^scsi_generic', f): + if re.match('^scsi_generic:', f): sg = os.path.basename(realpath) + elif f == "scsi_generic": + for dir in os.listdir(os.path.join(paths, f)): + if os.path.exists(os.path.join(paths, f, dir, "dev")): + sg = os.path.basename(dir) + if sg: + if devname is None: + devname = sg scsi_id = _vscsi_get_scsiid(sg) devices.append([hctl, devname, sg, scsi_id]) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 16:27:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 16:27:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAk4-0008Vx-7H; Fri, 05 Oct 2012 16:27:12 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAk2-0008Vl-Tu for xen-devel@lists.xen.org; Fri, 05 Oct 2012 16:27:11 +0000 Received: from [85.158.143.99:22747] by server-3.bemta-4.messagelabs.com id 55/8B-10986-E5A0F605; Fri, 05 Oct 2012 16:27:10 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1349454429!32690314!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31310 invoked from network); 5 Oct 2012 16:27:09 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 16:27:09 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14969223" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 16:27:09 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 17:27:09 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TKAk0-0001wA-SI; Fri, 05 Oct 2012 16:27:08 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TKAk0-0000hz-O2; Fri, 05 Oct 2012 17:27:08 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20591.2652.642081.644934@mariner.uk.xensource.com> Date: Fri, 5 Oct 2012 17:27:08 +0100 To: Ian Campbell In-Reply-To: <1349442649.20946.89.camel@zakaz.uk.xensource.com> References: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com> <1348683325-12367-4-git-send-email-anthony.perard@citrix.com> <1349442649.20946.89.camel@zakaz.uk.xensource.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Anthony Perard , Xen Devel Subject: Re: [Xen-devel] [PATCH V3 03/10] libxl_json: Replace JSON_TRUE/FALSE by JSON_BOOL. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Campbell writes ("Re: [PATCH V3 03/10] libxl_json: Replace JSON_TRUE/FALSE by JSON_BOOL."): > Just wondering if maybe there ought to be an assert in each of those? It shouldn't be an assertion. In general these objects are unmarshalled from serialisations provided outside the process, so they may contain "wrong" things. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 16:27:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 16:27:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAk4-0008Vx-7H; Fri, 05 Oct 2012 16:27:12 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAk2-0008Vl-Tu for xen-devel@lists.xen.org; Fri, 05 Oct 2012 16:27:11 +0000 Received: from [85.158.143.99:22747] by server-3.bemta-4.messagelabs.com id 55/8B-10986-E5A0F605; Fri, 05 Oct 2012 16:27:10 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1349454429!32690314!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31310 invoked from network); 5 Oct 2012 16:27:09 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 16:27:09 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14969223" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 16:27:09 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 17:27:09 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TKAk0-0001wA-SI; Fri, 05 Oct 2012 16:27:08 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TKAk0-0000hz-O2; Fri, 05 Oct 2012 17:27:08 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20591.2652.642081.644934@mariner.uk.xensource.com> Date: Fri, 5 Oct 2012 17:27:08 +0100 To: Ian Campbell In-Reply-To: <1349442649.20946.89.camel@zakaz.uk.xensource.com> References: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com> <1348683325-12367-4-git-send-email-anthony.perard@citrix.com> <1349442649.20946.89.camel@zakaz.uk.xensource.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Anthony Perard , Xen Devel Subject: Re: [Xen-devel] [PATCH V3 03/10] libxl_json: Replace JSON_TRUE/FALSE by JSON_BOOL. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Campbell writes ("Re: [PATCH V3 03/10] libxl_json: Replace JSON_TRUE/FALSE by JSON_BOOL."): > Just wondering if maybe there ought to be an assert in each of those? It shouldn't be an assertion. In general these objects are unmarshalled from serialisations provided outside the process, so they may contain "wrong" things. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 16:29:07 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 16:29:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAlj-0000Cq-O3; Fri, 05 Oct 2012 16:28:55 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAli-0000CW-Ew for xen-devel@lists.xen.org; Fri, 05 Oct 2012 16:28:54 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1349454528!4316171!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4192 invoked from network); 5 Oct 2012 16:28:48 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 16:28:48 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14969276" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 16:28:48 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 17:28:48 +0100 Message-ID: <1349454527.20946.144.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Ian Jackson Date: Fri, 5 Oct 2012 17:28:47 +0100 In-Reply-To: <20591.2652.642081.644934@mariner.uk.xensource.com> References: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com> <1348683325-12367-4-git-send-email-anthony.perard@citrix.com> <1349442649.20946.89.camel@zakaz.uk.xensource.com> <20591.2652.642081.644934@mariner.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: Anthony Perard , Xen Devel Subject: Re: [Xen-devel] [PATCH V3 03/10] libxl_json: Replace JSON_TRUE/FALSE by JSON_BOOL. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-10-05 at 17:27 +0100, Ian Jackson wrote: > Ian Campbell writes ("Re: [PATCH V3 03/10] libxl_json: Replace JSON_TRUE/FALSE by JSON_BOOL."): > > Just wondering if maybe there ought to be an assert in each of those? > > It shouldn't be an assertion. In general these objects are > unmarshalled from serialisations provided outside the process, so they > may contain "wrong" things. I assumed they were all checked before use, since otherwise why would you be calling that particular variant of the getter, but if not then that's fine too. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 16:29:07 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 16:29:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAlj-0000Cq-O3; Fri, 05 Oct 2012 16:28:55 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAli-0000CW-Ew for xen-devel@lists.xen.org; Fri, 05 Oct 2012 16:28:54 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1349454528!4316171!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4192 invoked from network); 5 Oct 2012 16:28:48 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 16:28:48 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14969276" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 16:28:48 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 17:28:48 +0100 Message-ID: <1349454527.20946.144.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Ian Jackson Date: Fri, 5 Oct 2012 17:28:47 +0100 In-Reply-To: <20591.2652.642081.644934@mariner.uk.xensource.com> References: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com> <1348683325-12367-4-git-send-email-anthony.perard@citrix.com> <1349442649.20946.89.camel@zakaz.uk.xensource.com> <20591.2652.642081.644934@mariner.uk.xensource.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.3-1 MIME-Version: 1.0 Cc: Anthony Perard , Xen Devel Subject: Re: [Xen-devel] [PATCH V3 03/10] libxl_json: Replace JSON_TRUE/FALSE by JSON_BOOL. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 2012-10-05 at 17:27 +0100, Ian Jackson wrote: > Ian Campbell writes ("Re: [PATCH V3 03/10] libxl_json: Replace JSON_TRUE/FALSE by JSON_BOOL."): > > Just wondering if maybe there ought to be an assert in each of those? > > It shouldn't be an assertion. In general these objects are > unmarshalled from serialisations provided outside the process, so they > may contain "wrong" things. I assumed they were all checked before use, since otherwise why would you be calling that particular variant of the getter, but if not then that's fine too. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 16:36:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 16:36:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAtC-0000Xg-MB; Fri, 05 Oct 2012 16:36:38 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAtA-0000Xb-Ve for xen-devel@lists.xen.org; Fri, 05 Oct 2012 16:36:37 +0000 Received: from [85.158.138.51:45488] by server-9.bemta-3.messagelabs.com id 43/75-20338-49C0F605; Fri, 05 Oct 2012 16:36:36 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-174.messagelabs.com!1349454994!25186749!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14537 invoked from network); 5 Oct 2012 16:36:35 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 16:36:35 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14969442" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 16:36:34 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 17:36:34 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TKAt8-00022I-AK; Fri, 05 Oct 2012 16:36:34 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TKAt8-0000iZ-4z; Fri, 05 Oct 2012 17:36:34 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20591.3218.46221.931473@mariner.uk.xensource.com> Date: Fri, 5 Oct 2012 17:36:34 +0100 To: Dario Faggioli In-Reply-To: <7fba2d9044e720770c25.1349446106@Solace> References: <7fba2d9044e720770c25.1349446106@Solace> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Andre Przywara , Ian Campbell , Anil Madhavapeddy , George Dunlap , Andrew Cooper , Juergen Gross , "xen-devel@lists.xen.org" , Jan Beulich , Marcus Granado , Daniel De Graaf , Matt Wilson Subject: Re: [Xen-devel] [PATCH 8 of 8] xl: add node-affinity to the output of `xl list` X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Dario Faggioli writes ("[PATCH 8 of 8] xl: add node-affinity to the output of `xl list`"): > Node-affinity is now something that is under (some) control of the > user, so show it upon request as part of the output of `xl list'. ... > -static void list_domains(int verbose, int context, const libxl_dominfo *info, int nb_domain) > +static void print_bitmap(uint8_t *map, int maplen, FILE *stream, int cpu_node) > +{ > + int i; > + uint8_t pmap = 0, bitmask = 0; > + int firstset = 0, state = 0; > + > + for (i = 0; i < maplen; i++) { > + if (i % 8 == 0) { > + pmap = *map++; > + bitmask = 1; > + } else bitmask <<= 1; > + > + switch (state) { > + case 0: > + case 2: > + if ((pmap & bitmask) != 0) { > + firstset = i; > + state++; > + } > + continue; > + case 1: > + case 3: > + if ((pmap & bitmask) == 0) { > + fprintf(stream, "%s%d", state > 1 ? "," : "", firstset); > + if (i - 1 > firstset) > + fprintf(stream, "-%d", i - 1); > + state = 2; > + } > + continue; > + } > + } Is this business with a state variable really the least opaque way of writing this ? Oh I see you're just moving it about. Oh well.. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 16:36:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 16:36:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAtC-0000Xg-MB; Fri, 05 Oct 2012 16:36:38 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAtA-0000Xb-Ve for xen-devel@lists.xen.org; Fri, 05 Oct 2012 16:36:37 +0000 Received: from [85.158.138.51:45488] by server-9.bemta-3.messagelabs.com id 43/75-20338-49C0F605; Fri, 05 Oct 2012 16:36:36 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-174.messagelabs.com!1349454994!25186749!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14537 invoked from network); 5 Oct 2012 16:36:35 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 16:36:35 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14969442" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 16:36:34 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 17:36:34 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TKAt8-00022I-AK; Fri, 05 Oct 2012 16:36:34 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TKAt8-0000iZ-4z; Fri, 05 Oct 2012 17:36:34 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20591.3218.46221.931473@mariner.uk.xensource.com> Date: Fri, 5 Oct 2012 17:36:34 +0100 To: Dario Faggioli In-Reply-To: <7fba2d9044e720770c25.1349446106@Solace> References: <7fba2d9044e720770c25.1349446106@Solace> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Andre Przywara , Ian Campbell , Anil Madhavapeddy , George Dunlap , Andrew Cooper , Juergen Gross , "xen-devel@lists.xen.org" , Jan Beulich , Marcus Granado , Daniel De Graaf , Matt Wilson Subject: Re: [Xen-devel] [PATCH 8 of 8] xl: add node-affinity to the output of `xl list` X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Dario Faggioli writes ("[PATCH 8 of 8] xl: add node-affinity to the output of `xl list`"): > Node-affinity is now something that is under (some) control of the > user, so show it upon request as part of the output of `xl list'. ... > -static void list_domains(int verbose, int context, const libxl_dominfo *info, int nb_domain) > +static void print_bitmap(uint8_t *map, int maplen, FILE *stream, int cpu_node) > +{ > + int i; > + uint8_t pmap = 0, bitmask = 0; > + int firstset = 0, state = 0; > + > + for (i = 0; i < maplen; i++) { > + if (i % 8 == 0) { > + pmap = *map++; > + bitmask = 1; > + } else bitmask <<= 1; > + > + switch (state) { > + case 0: > + case 2: > + if ((pmap & bitmask) != 0) { > + firstset = i; > + state++; > + } > + continue; > + case 1: > + case 3: > + if ((pmap & bitmask) == 0) { > + fprintf(stream, "%s%d", state > 1 ? "," : "", firstset); > + if (i - 1 > firstset) > + fprintf(stream, "-%d", i - 1); > + state = 2; > + } > + continue; > + } > + } Is this business with a state variable really the least opaque way of writing this ? Oh I see you're just moving it about. Oh well.. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 16:39:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 16:39:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAvT-0000e4-7w; Fri, 05 Oct 2012 16:38:59 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAvS-0000du-3T for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 16:38:58 +0000 Received: from [85.158.137.99:46978] by server-6.bemta-3.messagelabs.com id F6/FD-11085-12D0F605; Fri, 05 Oct 2012 16:38:57 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-15.tower-217.messagelabs.com!1349455136!18075753!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10362 invoked from network); 5 Oct 2012 16:38:56 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 16:38:56 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14969507" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 16:38:56 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 17:38:56 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TKAvQ-00025K-18; Fri, 05 Oct 2012 16:38:56 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TKAvP-0000ip-TW; Fri, 05 Oct 2012 17:38:55 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20591.3359.810368.864702@mariner.uk.xensource.com> Date: Fri, 5 Oct 2012 17:38:55 +0100 To: Dario Faggioli In-Reply-To: <1349448373.18984.27.camel@Solace> References: <1349448373.18984.27.camel@Solace> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [xen-unstable test] 13924: tolerable FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Dario Faggioli writes ("Re: [Xen-devel] [xen-unstable test] 13924: tolerable FAIL"): > So, sorry for noticing this only now, but it seems the sedf test is > failing to boot since flight 13900 (Sept 28). > > It seems to me that, from hat day on, this particular test is always > running on the same machine (gall-mite). OTOH, 13900 run on a different > one (moss-bug) and worked well. The tester likes to reuse the same machine when the test fails. That means that when a new machine-specific bug is introduced, it blocks a push. > From a super quick inspection of the logs, I couldn't spot anything > particular that can be causing the failures, so I'm asking here: could > it be something somehow machine-related? It's quite possible. > I remember you (IanJ) telling that there might be some problems with the > test system in these days... Is that the case or should I be > investigating more thoroughly? (In the latter case, I think I can have a > look at it next week). I am not aware of any problems that might suggest this was a false failure. Given the test history I would expect that this is a real bug. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 16:39:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 16:39:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAvT-0000e4-7w; Fri, 05 Oct 2012 16:38:59 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAvS-0000du-3T for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 16:38:58 +0000 Received: from [85.158.137.99:46978] by server-6.bemta-3.messagelabs.com id F6/FD-11085-12D0F605; Fri, 05 Oct 2012 16:38:57 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-15.tower-217.messagelabs.com!1349455136!18075753!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10362 invoked from network); 5 Oct 2012 16:38:56 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 16:38:56 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14969507" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 16:38:56 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 17:38:56 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TKAvQ-00025K-18; Fri, 05 Oct 2012 16:38:56 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TKAvP-0000ip-TW; Fri, 05 Oct 2012 17:38:55 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20591.3359.810368.864702@mariner.uk.xensource.com> Date: Fri, 5 Oct 2012 17:38:55 +0100 To: Dario Faggioli In-Reply-To: <1349448373.18984.27.camel@Solace> References: <1349448373.18984.27.camel@Solace> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: "xen-devel@lists.xensource.com" Subject: Re: [Xen-devel] [xen-unstable test] 13924: tolerable FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Dario Faggioli writes ("Re: [Xen-devel] [xen-unstable test] 13924: tolerable FAIL"): > So, sorry for noticing this only now, but it seems the sedf test is > failing to boot since flight 13900 (Sept 28). > > It seems to me that, from hat day on, this particular test is always > running on the same machine (gall-mite). OTOH, 13900 run on a different > one (moss-bug) and worked well. The tester likes to reuse the same machine when the test fails. That means that when a new machine-specific bug is introduced, it blocks a push. > From a super quick inspection of the logs, I couldn't spot anything > particular that can be causing the failures, so I'm asking here: could > it be something somehow machine-related? It's quite possible. > I remember you (IanJ) telling that there might be some problems with the > test system in these days... Is that the case or should I be > investigating more thoroughly? (In the latter case, I think I can have a > look at it next week). I am not aware of any problems that might suggest this was a false failure. Given the test history I would expect that this is a real bug. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 16:39:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 16:39:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAvr-0000gQ-Kf; Fri, 05 Oct 2012 16:39:23 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAvp-0000gD-Hm for xen-devel@lists.xen.org; Fri, 05 Oct 2012 16:39:21 +0000 Received: from [85.158.139.83:54723] by server-2.bemta-5.messagelabs.com id F1/25-28944-83D0F605; Fri, 05 Oct 2012 16:39:20 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1349455160!31410592!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24149 invoked from network); 5 Oct 2012 16:39:20 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 16:39:20 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14969513" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 16:39:19 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 17:39:20 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TKAvn-00025V-EV; Fri, 05 Oct 2012 16:39:19 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TKAvn-0000j2-85; Fri, 05 Oct 2012 17:39:19 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20591.3383.99356.802311@mariner.uk.xensource.com> Date: Fri, 5 Oct 2012 17:39:19 +0100 To: Anthony PERARD In-Reply-To: <1349448596-8611-1-git-send-email-anthony.perard@citrix.com> References: <1349448596-8611-1-git-send-email-anthony.perard@citrix.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Ian Campbell , Xen Devel Subject: Re: [Xen-devel] [PATCH] libxl: Add a comment about NOGC usage with flexarray X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Anthony PERARD writes ("[PATCH] libxl: Add a comment about NOGC usage with flexarray"): > Signed-off-by: Anthony PERARD Acked-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 16:39:33 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 16:39:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAvr-0000gQ-Kf; Fri, 05 Oct 2012 16:39:23 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKAvp-0000gD-Hm for xen-devel@lists.xen.org; Fri, 05 Oct 2012 16:39:21 +0000 Received: from [85.158.139.83:54723] by server-2.bemta-5.messagelabs.com id F1/25-28944-83D0F605; Fri, 05 Oct 2012 16:39:20 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1349455160!31410592!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24149 invoked from network); 5 Oct 2012 16:39:20 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 16:39:20 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14969513" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 16:39:19 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 17:39:20 +0100 Received: from mariner.cam.xci-test.com ([10.80.2.22] helo=mariner.uk.xensource.com ident=Debian-exim) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TKAvn-00025V-EV; Fri, 05 Oct 2012 16:39:19 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72) (envelope-from ) id 1TKAvn-0000j2-85; Fri, 05 Oct 2012 17:39:19 +0100 From: Ian Jackson MIME-Version: 1.0 Message-ID: <20591.3383.99356.802311@mariner.uk.xensource.com> Date: Fri, 5 Oct 2012 17:39:19 +0100 To: Anthony PERARD In-Reply-To: <1349448596-8611-1-git-send-email-anthony.perard@citrix.com> References: <1349448596-8611-1-git-send-email-anthony.perard@citrix.com> X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) Cc: Ian Campbell , Xen Devel Subject: Re: [Xen-devel] [PATCH] libxl: Add a comment about NOGC usage with flexarray X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Anthony PERARD writes ("[PATCH] libxl: Add a comment about NOGC usage with flexarray"): > Signed-off-by: Anthony PERARD Acked-by: Ian Jackson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 16:52:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 16:52:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKB8g-0000ya-VW; Fri, 05 Oct 2012 16:52:38 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKB8g-0000yV-5Y for xen-devel@lists.xen.org; Fri, 05 Oct 2012 16:52:38 +0000 Received: from [85.158.139.211:59525] by server-9.bemta-5.messagelabs.com id 9D/9C-14846-5501F605; Fri, 05 Oct 2012 16:52:37 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-10.tower-206.messagelabs.com!1349455956!21210735!1 X-Originating-IP: [81.169.146.161] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NDUwOTc=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NDUwOTc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10835 invoked from network); 5 Oct 2012 16:52:36 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161) by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 16:52:36 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESMg X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-070-120.pools.arcor-ip.net [88.65.70.120]) by smtp.strato.de (jorabe mo38) (RZmta 30.20 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id j05e59o95FpWcr for ; Fri, 5 Oct 2012 18:52:36 +0200 (CEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id 045CE18631 for ; Fri, 5 Oct 2012 18:52:36 +0200 (CEST) MIME-Version: 1.0 X-Mercurial-Node: 964fd4a693f940b5ae31d6d9021e0c89afaee703 Message-Id: <964fd4a693f940b5ae31.1349455955@probook.site> User-Agent: Mercurial-patchbomb/1.7.5 Date: Fri, 05 Oct 2012 18:52:35 +0200 From: Olaf Hering To: xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH] hotplug/Linux: Remove tracing (bash -x) from network-nat script X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Olaf Hering # Date 1349455879 -7200 # Node ID 964fd4a693f940b5ae31d6d9021e0c89afaee703 # Parent 93e92c12bc13952ed15312f937a37e6ab2d197ad hotplug/Linux: Remove tracing (bash -x) from network-nat script Signed-off-by: Olaf Hering diff -r 93e92c12bc13 -r 964fd4a693f9 tools/hotplug/Linux/network-nat --- a/tools/hotplug/Linux/network-nat +++ b/tools/hotplug/Linux/network-nat @@ -1,4 +1,4 @@ -#!/bin/bash -x +#!/bin/bash #============================================================================ # Default Xen network start/stop script when using NAT. # Xend calls a network script when it starts. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 16:52:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 16:52:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKB8g-0000ya-VW; Fri, 05 Oct 2012 16:52:38 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKB8g-0000yV-5Y for xen-devel@lists.xen.org; Fri, 05 Oct 2012 16:52:38 +0000 Received: from [85.158.139.211:59525] by server-9.bemta-5.messagelabs.com id 9D/9C-14846-5501F605; Fri, 05 Oct 2012 16:52:37 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-10.tower-206.messagelabs.com!1349455956!21210735!1 X-Originating-IP: [81.169.146.161] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NDUwOTc=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NDUwOTc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10835 invoked from network); 5 Oct 2012 16:52:36 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161) by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 16:52:36 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESMg X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-070-120.pools.arcor-ip.net [88.65.70.120]) by smtp.strato.de (jorabe mo38) (RZmta 30.20 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id j05e59o95FpWcr for ; Fri, 5 Oct 2012 18:52:36 +0200 (CEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id 045CE18631 for ; Fri, 5 Oct 2012 18:52:36 +0200 (CEST) MIME-Version: 1.0 X-Mercurial-Node: 964fd4a693f940b5ae31d6d9021e0c89afaee703 Message-Id: <964fd4a693f940b5ae31.1349455955@probook.site> User-Agent: Mercurial-patchbomb/1.7.5 Date: Fri, 05 Oct 2012 18:52:35 +0200 From: Olaf Hering To: xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH] hotplug/Linux: Remove tracing (bash -x) from network-nat script X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Olaf Hering # Date 1349455879 -7200 # Node ID 964fd4a693f940b5ae31d6d9021e0c89afaee703 # Parent 93e92c12bc13952ed15312f937a37e6ab2d197ad hotplug/Linux: Remove tracing (bash -x) from network-nat script Signed-off-by: Olaf Hering diff -r 93e92c12bc13 -r 964fd4a693f9 tools/hotplug/Linux/network-nat --- a/tools/hotplug/Linux/network-nat +++ b/tools/hotplug/Linux/network-nat @@ -1,4 +1,4 @@ -#!/bin/bash -x +#!/bin/bash #============================================================================ # Default Xen network start/stop script when using NAT. # Xend calls a network script when it starts. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 17:02:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 17:02:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKBIL-0001CS-2Z; Fri, 05 Oct 2012 17:02:37 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKBIJ-0001CN-85 for Xen-devel@lists.xen.org; Fri, 05 Oct 2012 17:02:35 +0000 Received: from [85.158.143.99:31884] by server-2.bemta-4.messagelabs.com id C3/39-06610-AA21F605; Fri, 05 Oct 2012 17:02:34 +0000 X-Env-Sender: xinxinjin89@gmail.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1349456552!26028532!1 X-Originating-IP: [209.85.216.173] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1733 invoked from network); 5 Oct 2012 17:02:33 -0000 Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com) (209.85.216.173) by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 17:02:33 -0000 Received: by mail-qc0-f173.google.com with SMTP id b12so1583047qca.32 for ; Fri, 05 Oct 2012 10:02:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=szBFL/SbdKLDKKjzHCUJABUpMq3dO8uMWsGubFf+ioc=; b=Qw1AvkVFvn6nga+7Rwwu/RUN8VOKyyKFvb5c/Se/TVUW9/qG9gC8oCbIbF/MUnDy7J J1LghxWHMQ+FfIr5p7nYQWY8Svjzmxp3FI0dWvU5+m1X2aBNNqRysYJmfEET4EKRoP+T 1qjPTMG54EFkGMDz4OXvvlOh4isjnWSApxqVLDQ+dD9c0GNqMXCb42ePtfNVXKHetv1s QwBxZIAhYC5bMKY8RPHH0niUe54J8H90mLQbZ/etEoMhWYSFbPBvSpXjujE6VQ//mihb ga5s86D2fyiMsTDb07HsMLY3fJt0ohCE/Ek30vJb8BVWXinuYfZ90nMugEmkaBtKRyRM UrWg== MIME-Version: 1.0 Received: by 10.229.77.21 with SMTP id e21mr522293qck.70.1349456552163; Fri, 05 Oct 2012 10:02:32 -0700 (PDT) Received: by 10.229.176.85 with HTTP; Fri, 5 Oct 2012 10:02:32 -0700 (PDT) Date: Fri, 5 Oct 2012 10:02:32 -0700 Message-ID: From: Xinxin Jin To: Xen-devel@lists.xen.org Subject: [Xen-devel] Where is PV's root page table? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1548205010710903311==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============1548205010710903311== Content-Type: multipart/alternative; boundary=0023543336266e7a8d04cb52d69c --0023543336266e7a8d04cb52d69c Content-Type: text/plain; charset=ISO-8859-1 Hi, I want to manually walk guest's page table in Xen, but I cannot find where the base address of the guest root page table is defined. Could anyone give me some clue ? Thanks! -- Xinxin --0023543336266e7a8d04cb52d69c Content-Type: text/html; charset=ISO-8859-1 Hi, I want to manually walk guest's page table in Xen, but I cannot find where the base address of the guest root page table is defined. Could anyone give me some clue ?
Thanks!
--
Xinxin

--0023543336266e7a8d04cb52d69c-- --===============1548205010710903311== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============1548205010710903311==-- From xen-devel-bounces@lists.xen.org Fri Oct 05 17:02:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 17:02:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKBIL-0001CS-2Z; Fri, 05 Oct 2012 17:02:37 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKBIJ-0001CN-85 for Xen-devel@lists.xen.org; Fri, 05 Oct 2012 17:02:35 +0000 Received: from [85.158.143.99:31884] by server-2.bemta-4.messagelabs.com id C3/39-06610-AA21F605; Fri, 05 Oct 2012 17:02:34 +0000 X-Env-Sender: xinxinjin89@gmail.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1349456552!26028532!1 X-Originating-IP: [209.85.216.173] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1733 invoked from network); 5 Oct 2012 17:02:33 -0000 Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com) (209.85.216.173) by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 17:02:33 -0000 Received: by mail-qc0-f173.google.com with SMTP id b12so1583047qca.32 for ; Fri, 05 Oct 2012 10:02:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=szBFL/SbdKLDKKjzHCUJABUpMq3dO8uMWsGubFf+ioc=; b=Qw1AvkVFvn6nga+7Rwwu/RUN8VOKyyKFvb5c/Se/TVUW9/qG9gC8oCbIbF/MUnDy7J J1LghxWHMQ+FfIr5p7nYQWY8Svjzmxp3FI0dWvU5+m1X2aBNNqRysYJmfEET4EKRoP+T 1qjPTMG54EFkGMDz4OXvvlOh4isjnWSApxqVLDQ+dD9c0GNqMXCb42ePtfNVXKHetv1s QwBxZIAhYC5bMKY8RPHH0niUe54J8H90mLQbZ/etEoMhWYSFbPBvSpXjujE6VQ//mihb ga5s86D2fyiMsTDb07HsMLY3fJt0ohCE/Ek30vJb8BVWXinuYfZ90nMugEmkaBtKRyRM UrWg== MIME-Version: 1.0 Received: by 10.229.77.21 with SMTP id e21mr522293qck.70.1349456552163; Fri, 05 Oct 2012 10:02:32 -0700 (PDT) Received: by 10.229.176.85 with HTTP; Fri, 5 Oct 2012 10:02:32 -0700 (PDT) Date: Fri, 5 Oct 2012 10:02:32 -0700 Message-ID: From: Xinxin Jin To: Xen-devel@lists.xen.org Subject: [Xen-devel] Where is PV's root page table? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1548205010710903311==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --===============1548205010710903311== Content-Type: multipart/alternative; boundary=0023543336266e7a8d04cb52d69c --0023543336266e7a8d04cb52d69c Content-Type: text/plain; charset=ISO-8859-1 Hi, I want to manually walk guest's page table in Xen, but I cannot find where the base address of the guest root page table is defined. Could anyone give me some clue ? Thanks! -- Xinxin --0023543336266e7a8d04cb52d69c Content-Type: text/html; charset=ISO-8859-1 Hi, I want to manually walk guest's page table in Xen, but I cannot find where the base address of the guest root page table is defined. Could anyone give me some clue ?
Thanks!
--
Xinxin

--0023543336266e7a8d04cb52d69c-- --===============1548205010710903311== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============1548205010710903311==-- From xen-devel-bounces@lists.xen.org Fri Oct 05 17:23:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 17:23:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKBby-0001Tm-UC; Fri, 05 Oct 2012 17:22:54 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKBbw-0001Th-HR for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 17:22:52 +0000 Received: from [85.158.139.83:43181] by server-16.bemta-5.messagelabs.com id 95/E3-21637-B671F605; Fri, 05 Oct 2012 17:22:51 +0000 X-Env-Sender: linux@eikelenboom.it X-Msg-Ref: server-13.tower-182.messagelabs.com!1349457771!33078350!1 X-Originating-IP: [188.40.164.121] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2923 invoked from network); 5 Oct 2012 17:22:51 -0000 Received: from static.121.164.40.188.clients.your-server.de (HELO smtp.eikelenboom.it) (188.40.164.121) by server-13.tower-182.messagelabs.com with AES256-SHA encrypted SMTP; 5 Oct 2012 17:22:51 -0000 Received: from 100-66-ftth.onsneteindhoven.nl ([88.159.66.100]:52967 helo=[172.16.1.20]) by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TKBd6-0002Pa-UA; Fri, 05 Oct 2012 19:24:04 +0200 Date: Fri, 5 Oct 2012 19:22:46 +0200 From: Sander Eikelenboom Organization: Eikelenboom IT services X-Priority: 3 (Normal) Message-ID: <1610131025.20121005192246@eikelenboom.it> To: "Konrad Rzeszutek Wilk" MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: [Xen-devel] Kernel 3.7.0-pre-rc1 kernel BUG at drivers/net/xen-netback/netback.c:405 RIP: e030:[] [] netbk_gop_frag_copy+0x379/0x380 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hi Konrad, Just tested kernel 3.7.0-pre-rc1 but ran into a oops in netback on boot after starting some guests: [ 402.723915] ------------[ cut here ]------------ [ 402.734629] kernel BUG at drivers/net/xen-netback/netback.c:405! [ 402.744207] invalid opcode: 0000 [#5] PREEMPT SMP [ 402.752692] Modules linked in: [ 402.761307] CPU 1 [ 402.761358] Pid: 1329, comm: netback/1 Tainted: G D 3.6.0-pre-rc1-20121005a #1 MSI MS-7640/890FXA-GD70 (MS-7640) [ 402.778214] RIP: e030:[] [] netbk_gop_frag_copy+0x379/0x380 [ 402.786779] RSP: e02b:ffff880037955bb0 EFLAGS: 00010206 [ 402.795183] RAX: 000000000000486a RBX: ffff88003878c9c0 RCX: ffffea0000b3d400 [ 402.803536] RDX: ffff880037955cd0 RSI: ffff880037955d1c RDI: ffff88003878c9c0 [ 402.811867] RBP: ffff880037955c20 R08: 0000000000000000 R09: 00000000000042c2 [ 402.820008] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88002f58b100 [ 402.828022] R13: ffff880037955cd0 R14: 00000000000005a8 R15: ffff880037955d1c [ 402.835927] FS: 00007ffe2ca5b760(0000) GS:ffff88003f840000(0000) knlGS:0000000000000000 [ 402.843826] CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b [ 402.851539] CR2: 00007fff99c3b018 CR3: 00000000377c9000 CR4: 0000000000000660 [ 402.859251] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 402.866816] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 402.874188] Process netback/1 (pid: 1329, threadinfo ffff880037954000, task ffff8800398c20a0) [ 402.881621] Stack: [ 402.888811] ffff880037955d1c 0000000000000000 ffff88002f58b100 ffff88003878c9c0 [ 402.896102] ffff880000000000 ffff88002cf54000 0000000000000000 0000000000000000 [ 402.903320] ffff880037955c20 ffff88002f58b100 0000000000000001 0000000000000010 [ 402.910356] Call Trace: [ 402.917180] [] xen_netbk_rx_action+0x303/0x840 [ 402.924065] [] ? trace_hardirqs_on+0xd/0x10 [ 402.930776] [] xen_netbk_kthread+0xba/0xac0 [ 402.937352] [] ? try_to_wake_up+0x1b6/0x310 [ 402.943856] [] ? wake_up_bit+0x40/0x40 [ 402.950173] [] ? xen_netbk_tx_build_gops+0xa70/0xa70 [ 402.956370] [] kthread+0xd6/0xe0 [ 402.962524] [] kernel_thread_helper+0x4/0x10 [ 402.968668] [] ? retint_restore_args+0x13/0x13 [ 402.974735] [] ? gs_change+0x13/0x13 [ 402.980715] Code: b8 01 00 00 00 48 69 d2 b8 b3 00 00 48 8d 84 f8 60 01 00 00 48 3b 0c 10 0f 85 de fc ff ff e9 e2 fc ff ff 0f 0b eb fe 0f 0b eb fe <0f> 0b eb fe 0f 1f 00 55 48 89 e5 48 83 ec 10 48 89 1c 24 4c 89 [ 402.993584] RIP [] netbk_gop_frag_copy+0x379/0x380 [ 403.000075] RSP [ 403.006603] ---[ end trace 6eada309643a3fc7 ]--- -- Sander _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 17:23:18 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 17:23:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKBby-0001Tm-UC; Fri, 05 Oct 2012 17:22:54 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKBbw-0001Th-HR for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 17:22:52 +0000 Received: from [85.158.139.83:43181] by server-16.bemta-5.messagelabs.com id 95/E3-21637-B671F605; Fri, 05 Oct 2012 17:22:51 +0000 X-Env-Sender: linux@eikelenboom.it X-Msg-Ref: server-13.tower-182.messagelabs.com!1349457771!33078350!1 X-Originating-IP: [188.40.164.121] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2923 invoked from network); 5 Oct 2012 17:22:51 -0000 Received: from static.121.164.40.188.clients.your-server.de (HELO smtp.eikelenboom.it) (188.40.164.121) by server-13.tower-182.messagelabs.com with AES256-SHA encrypted SMTP; 5 Oct 2012 17:22:51 -0000 Received: from 100-66-ftth.onsneteindhoven.nl ([88.159.66.100]:52967 helo=[172.16.1.20]) by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TKBd6-0002Pa-UA; Fri, 05 Oct 2012 19:24:04 +0200 Date: Fri, 5 Oct 2012 19:22:46 +0200 From: Sander Eikelenboom Organization: Eikelenboom IT services X-Priority: 3 (Normal) Message-ID: <1610131025.20121005192246@eikelenboom.it> To: "Konrad Rzeszutek Wilk" MIME-Version: 1.0 Cc: "xen-devel@lists.xensource.com" Subject: [Xen-devel] Kernel 3.7.0-pre-rc1 kernel BUG at drivers/net/xen-netback/netback.c:405 RIP: e030:[] [] netbk_gop_frag_copy+0x379/0x380 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Hi Konrad, Just tested kernel 3.7.0-pre-rc1 but ran into a oops in netback on boot after starting some guests: [ 402.723915] ------------[ cut here ]------------ [ 402.734629] kernel BUG at drivers/net/xen-netback/netback.c:405! [ 402.744207] invalid opcode: 0000 [#5] PREEMPT SMP [ 402.752692] Modules linked in: [ 402.761307] CPU 1 [ 402.761358] Pid: 1329, comm: netback/1 Tainted: G D 3.6.0-pre-rc1-20121005a #1 MSI MS-7640/890FXA-GD70 (MS-7640) [ 402.778214] RIP: e030:[] [] netbk_gop_frag_copy+0x379/0x380 [ 402.786779] RSP: e02b:ffff880037955bb0 EFLAGS: 00010206 [ 402.795183] RAX: 000000000000486a RBX: ffff88003878c9c0 RCX: ffffea0000b3d400 [ 402.803536] RDX: ffff880037955cd0 RSI: ffff880037955d1c RDI: ffff88003878c9c0 [ 402.811867] RBP: ffff880037955c20 R08: 0000000000000000 R09: 00000000000042c2 [ 402.820008] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88002f58b100 [ 402.828022] R13: ffff880037955cd0 R14: 00000000000005a8 R15: ffff880037955d1c [ 402.835927] FS: 00007ffe2ca5b760(0000) GS:ffff88003f840000(0000) knlGS:0000000000000000 [ 402.843826] CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b [ 402.851539] CR2: 00007fff99c3b018 CR3: 00000000377c9000 CR4: 0000000000000660 [ 402.859251] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 402.866816] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 402.874188] Process netback/1 (pid: 1329, threadinfo ffff880037954000, task ffff8800398c20a0) [ 402.881621] Stack: [ 402.888811] ffff880037955d1c 0000000000000000 ffff88002f58b100 ffff88003878c9c0 [ 402.896102] ffff880000000000 ffff88002cf54000 0000000000000000 0000000000000000 [ 402.903320] ffff880037955c20 ffff88002f58b100 0000000000000001 0000000000000010 [ 402.910356] Call Trace: [ 402.917180] [] xen_netbk_rx_action+0x303/0x840 [ 402.924065] [] ? trace_hardirqs_on+0xd/0x10 [ 402.930776] [] xen_netbk_kthread+0xba/0xac0 [ 402.937352] [] ? try_to_wake_up+0x1b6/0x310 [ 402.943856] [] ? wake_up_bit+0x40/0x40 [ 402.950173] [] ? xen_netbk_tx_build_gops+0xa70/0xa70 [ 402.956370] [] kthread+0xd6/0xe0 [ 402.962524] [] kernel_thread_helper+0x4/0x10 [ 402.968668] [] ? retint_restore_args+0x13/0x13 [ 402.974735] [] ? gs_change+0x13/0x13 [ 402.980715] Code: b8 01 00 00 00 48 69 d2 b8 b3 00 00 48 8d 84 f8 60 01 00 00 48 3b 0c 10 0f 85 de fc ff ff e9 e2 fc ff ff 0f 0b eb fe 0f 0b eb fe <0f> 0b eb fe 0f 1f 00 55 48 89 e5 48 83 ec 10 48 89 1c 24 4c 89 [ 402.993584] RIP [] netbk_gop_frag_copy+0x379/0x380 [ 403.000075] RSP [ 403.006603] ---[ end trace 6eada309643a3fc7 ]--- -- Sander _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 17:35:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 17:35:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKBnH-0001fa-5j; Fri, 05 Oct 2012 17:34:35 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKBnF-0001fV-Op for Xen-devel@lists.xensource.com; Fri, 05 Oct 2012 17:34:33 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1349458464!8913587!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc5NjAzMQ==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21393 invoked from network); 5 Oct 2012 17:34:25 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 17:34:25 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q95HYHiG020028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Oct 2012 17:34:18 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q95HYG49011234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Oct 2012 17:34:16 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q95HYF6w031939; Fri, 5 Oct 2012 12:34:15 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 05 Oct 2012 10:34:15 -0700 Date: Fri, 5 Oct 2012 10:34:14 -0700 From: Mukesh Rathor To: Ian Campbell Message-ID: <20121005103414.22202e9a@mantra.us.oracle.com> In-Reply-To: <1349428878.20946.18.camel@zakaz.uk.xensource.com> References: <20120921122123.33489ce1@mantra.us.oracle.com> <1349270495.650.144.camel@zakaz.uk.xensource.com> <20121003153106.65237f07@mantra.us.oracle.com> <1349340642.650.227.camel@zakaz.uk.xensource.com> <20121004112048.53767720@mantra.us.oracle.com> <1349428878.20946.18.camel@zakaz.uk.xensource.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 7/8]: PVH privcmd changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 5 Oct 2012 10:21:18 +0100 Ian Campbell wrote: > On Thu, 2012-10-04 at 19:20 +0100, Mukesh Rathor wrote: > > On Thu, 4 Oct 2012 09:50:42 +0100 > > Ian Campbell wrote: > > > > > On Wed, 2012-10-03 at 23:31 +0100, Mukesh Rathor wrote: > > > > On Wed, 3 Oct 2012 14:21:35 +0100 > > > > Ian Campbell wrote: ..... > > > > Right, that's why I had it originally checking for auto xlated > > > > and doing something different. I think that is better than to > > > > change this and change again. I'll change it back to just > > > > putting the ptr here. > > > > > > Won't that break because on the second call you will pass in the > > > freshly allocated pointer and overwrite the exiting (useful) one > > > with it? > > > > No, for xlate, I just check for NULL. I didn't think it was big > > deal to special case xlate in this case. We got so many if xlate > > cases already thru the code. It leaves the semantics easy to > > understand: NULL == avail. 1 == locked PV. PTR == Locked PVH. I'll > > add a comment this time :). > > The transition from NULL => Locked PVH still needs to be done > atomically and without clobbering any existing non-NULL value, > otherwise it doesn't actually protect against multiple mappings like > it is supposed to. > > Ian. > yes, of course :). _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 17:35:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 17:35:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKBnH-0001fa-5j; Fri, 05 Oct 2012 17:34:35 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKBnF-0001fV-Op for Xen-devel@lists.xensource.com; Fri, 05 Oct 2012 17:34:33 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1349458464!8913587!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc5NjAzMQ==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21393 invoked from network); 5 Oct 2012 17:34:25 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 17:34:25 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q95HYHiG020028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Oct 2012 17:34:18 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q95HYG49011234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Oct 2012 17:34:16 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q95HYF6w031939; Fri, 5 Oct 2012 12:34:15 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 05 Oct 2012 10:34:15 -0700 Date: Fri, 5 Oct 2012 10:34:14 -0700 From: Mukesh Rathor To: Ian Campbell Message-ID: <20121005103414.22202e9a@mantra.us.oracle.com> In-Reply-To: <1349428878.20946.18.camel@zakaz.uk.xensource.com> References: <20120921122123.33489ce1@mantra.us.oracle.com> <1349270495.650.144.camel@zakaz.uk.xensource.com> <20121003153106.65237f07@mantra.us.oracle.com> <1349340642.650.227.camel@zakaz.uk.xensource.com> <20121004112048.53767720@mantra.us.oracle.com> <1349428878.20946.18.camel@zakaz.uk.xensource.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 7/8]: PVH privcmd changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 5 Oct 2012 10:21:18 +0100 Ian Campbell wrote: > On Thu, 2012-10-04 at 19:20 +0100, Mukesh Rathor wrote: > > On Thu, 4 Oct 2012 09:50:42 +0100 > > Ian Campbell wrote: > > > > > On Wed, 2012-10-03 at 23:31 +0100, Mukesh Rathor wrote: > > > > On Wed, 3 Oct 2012 14:21:35 +0100 > > > > Ian Campbell wrote: ..... > > > > Right, that's why I had it originally checking for auto xlated > > > > and doing something different. I think that is better than to > > > > change this and change again. I'll change it back to just > > > > putting the ptr here. > > > > > > Won't that break because on the second call you will pass in the > > > freshly allocated pointer and overwrite the exiting (useful) one > > > with it? > > > > No, for xlate, I just check for NULL. I didn't think it was big > > deal to special case xlate in this case. We got so many if xlate > > cases already thru the code. It leaves the semantics easy to > > understand: NULL == avail. 1 == locked PV. PTR == Locked PVH. I'll > > add a comment this time :). > > The transition from NULL => Locked PVH still needs to be done > atomically and without clobbering any existing non-NULL value, > otherwise it doesn't actually protect against multiple mappings like > it is supposed to. > > Ian. > yes, of course :). _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 17:35:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 17:35:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKBo0-0001iz-PH; Fri, 05 Oct 2012 17:35:20 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKBny-0001iS-Nb for xen-devel@lists.xen.org; Fri, 05 Oct 2012 17:35:18 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-2.tower-27.messagelabs.com!1349458512!13593476!1 X-Originating-IP: [81.169.146.161] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NDUwOTc=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NDUwOTc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7594 invoked from network); 5 Oct 2012 17:35:12 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161) by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 17:35:12 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESMg X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-070-120.pools.arcor-ip.net [88.65.70.120]) by smtp.strato.de (josoe mo50) (RZmta 30.20 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id z033e4o95H19PB for ; Fri, 5 Oct 2012 19:35:11 +0200 (CEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id D360418631 for ; Fri, 5 Oct 2012 19:35:10 +0200 (CEST) MIME-Version: 1.0 X-Mercurial-Node: 65ab6762cd37d0f43ff031e00637d5a88514aadb Message-Id: <65ab6762cd37d0f43ff0.1349458510@probook.site> User-Agent: Mercurial-patchbomb/1.7.5 Date: Fri, 05 Oct 2012 19:35:10 +0200 From: Olaf Hering To: xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH] xenballoond.init: remove 4 from default runlevel X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Olaf Hering # Date 1349458470 -7200 # Node ID 65ab6762cd37d0f43ff031e00637d5a88514aadb # Parent 964fd4a693f940b5ae31d6d9021e0c89afaee703 xenballoond.init: remove 4 from default runlevel Remove 4 from default runlevel in xenballoond.init. Similar to what changeset 24847:0900b1c905f1 does in xencommons, remove runlevel 4 from the other runlevel scripts. LSB defines runlevel 4 as reserved for local use, the local sysadmin is responsible for symlink creation in rc4.d. Signed-off-by: Olaf Hering diff -r 964fd4a693f9 -r 65ab6762cd37 tools/xenballoon/xenballoond.init --- a/tools/xenballoon/xenballoond.init +++ b/tools/xenballoon/xenballoond.init @@ -14,7 +14,7 @@ # Should-Start: # Required-Stop: $syslog $remote_fs # Should-Stop: -# Default-Start: 3 4 5 +# Default-Start: 3 5 # Default-Stop: 0 1 2 6 # Short-Description: Start/stop xenballoond # Description: Starts and stops the Xen ballooning daemon. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 17:35:43 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 17:35:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKBo0-0001iz-PH; Fri, 05 Oct 2012 17:35:20 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKBny-0001iS-Nb for xen-devel@lists.xen.org; Fri, 05 Oct 2012 17:35:18 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-2.tower-27.messagelabs.com!1349458512!13593476!1 X-Originating-IP: [81.169.146.161] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NDUwOTc=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NDUwOTc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7594 invoked from network); 5 Oct 2012 17:35:12 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161) by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 17:35:12 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESMg X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-070-120.pools.arcor-ip.net [88.65.70.120]) by smtp.strato.de (josoe mo50) (RZmta 30.20 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id z033e4o95H19PB for ; Fri, 5 Oct 2012 19:35:11 +0200 (CEST) Received: from probook.site (localhost [IPv6:::1]) by probook.site (Postfix) with ESMTP id D360418631 for ; Fri, 5 Oct 2012 19:35:10 +0200 (CEST) MIME-Version: 1.0 X-Mercurial-Node: 65ab6762cd37d0f43ff031e00637d5a88514aadb Message-Id: <65ab6762cd37d0f43ff0.1349458510@probook.site> User-Agent: Mercurial-patchbomb/1.7.5 Date: Fri, 05 Oct 2012 19:35:10 +0200 From: Olaf Hering To: xen-devel@lists.xen.org Subject: [Xen-devel] [PATCH] xenballoond.init: remove 4 from default runlevel X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org # HG changeset patch # User Olaf Hering # Date 1349458470 -7200 # Node ID 65ab6762cd37d0f43ff031e00637d5a88514aadb # Parent 964fd4a693f940b5ae31d6d9021e0c89afaee703 xenballoond.init: remove 4 from default runlevel Remove 4 from default runlevel in xenballoond.init. Similar to what changeset 24847:0900b1c905f1 does in xencommons, remove runlevel 4 from the other runlevel scripts. LSB defines runlevel 4 as reserved for local use, the local sysadmin is responsible for symlink creation in rc4.d. Signed-off-by: Olaf Hering diff -r 964fd4a693f9 -r 65ab6762cd37 tools/xenballoon/xenballoond.init --- a/tools/xenballoon/xenballoond.init +++ b/tools/xenballoon/xenballoond.init @@ -14,7 +14,7 @@ # Should-Start: # Required-Stop: $syslog $remote_fs # Should-Stop: -# Default-Start: 3 4 5 +# Default-Start: 3 5 # Default-Stop: 0 1 2 6 # Short-Description: Start/stop xenballoond # Description: Starts and stops the Xen ballooning daemon. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 17:38:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 17:38:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKBqz-0001vI-DE; Fri, 05 Oct 2012 17:38:25 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKBqx-0001v6-D1 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 17:38:23 +0000 Received: from [85.158.137.99:32654] by server-6.bemta-3.messagelabs.com id 4B/DB-11085-E0B1F605; Fri, 05 Oct 2012 17:38:22 +0000 X-Env-Sender: rshriram@cs.ubc.ca X-Msg-Ref: server-13.tower-217.messagelabs.com!1349458699!20473728!1 X-Originating-IP: [142.103.6.52] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1407 invoked from network); 5 Oct 2012 17:38:20 -0000 Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52) by server-13.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 17:38:20 -0000 Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (authenticated bits=0) by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q95HcGsS012216 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Fri, 5 Oct 2012 10:38:17 -0700 Received: by mail-wi0-f173.google.com with SMTP id hm4so854425wib.14 for ; Fri, 05 Oct 2012 10:38:14 -0700 (PDT) Received: by 10.180.78.102 with SMTP id a6mr4715142wix.20.1349458694826; Fri, 05 Oct 2012 10:38:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.40.102 with HTTP; Fri, 5 Oct 2012 10:37:34 -0700 (PDT) In-Reply-To: References: <75A1D5EB-12C7-4829-A3F7-4D77B2405FBB@gmail.com> From: Shriram Rajagopalan Date: Fri, 5 Oct 2012 10:37:34 -0700 Message-ID: To: =?ISO-8859-1?Q?Jos=E9_Eduardo_Fran=E7a?= Content-Type: multipart/mixed; boundary=20cf3068469f24eb5604cb535631 Cc: lmingcsce , xen-devel@lists.xen.org Subject: Re: [Xen-devel] How to get the checkpoint size in remus code? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: rshriram@cs.ubc.ca List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --20cf3068469f24eb5604cb535631 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Oct 3, 2012 at 4:11 AM, Jos=E9 Eduardo Fran=E7a wrote: > > I thought remus used xc_domain_save. Is this function used from live > migration? > > Futhermore I have two doubts if really Remus takes the last iteration of > live migration > > What's the function? There is no specific function. xc_domain_save is where everything happens. The infinite loop that basically keeps sending checkpoints @ a particular frequency > And how to get de I/O disk size on each period? > This depends on the disk backend. With blktap2 (unfortunately not available in 3.* kernels) tap-remus driver can give you the number of disk blocks sent per checkpoint= . With DRBD, it needs a little bit of hacking into the kernel module to return the number of disk blocks being sent with each checkpoint. >> I'm doing my master research and I need to adapt remus code. Now... I >> wanna get the checkpoint size (memory + disk) on each period. Does someo= ne >> know what function does this? I think some fd object's function in remus >> code could just get the memory size. >> You can get memory checkpoint stats for each iteration - like number of pages dirtied, size of data actually transmitted after compression (including headers, etc), time to checkpoint, etc. The attached patch (for xen-4.1.2) will give you the memory checkpoint stats for each checkpoint and can be easily parsed. shriram --20cf3068469f24eb5604cb535631 Content-Type: application/octet-stream; name="04_stats_fix.patch" Content-Disposition: attachment; filename="04_stats_fix.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h7xksv9e0 ZGlmZiAtciBhOWZkNmMwNWY0NjkgdG9vbHMvbGlieGMveGNfY29tcHJlc3Npb24uYwotLS0gYS90 b29scy9saWJ4Yy94Y19jb21wcmVzc2lvbi5jCVRodSBPY3QgMTMgMDg6NTM6MDMgMjAxMSAtMDcw MAorKysgYi90b29scy9saWJ4Yy94Y19jb21wcmVzc2lvbi5jCVdlZCBPY3QgMjYgMDk6MTk6MDIg MjAxMSAtMDcwMApAQCAtNDUxLDggKzQ1MSw4IEBACiB2b2lkIHhjX2NvbXByZXNzaW9uX3Jlc2V0 X3BhZ2VidWYoeGNfaW50ZXJmYWNlICp4Y2gsIGNvbXBfY3R4ICpjdHgpCiB7CiAgICAgY3R4LT5w Zm5zX2luZGV4ID0gY3R4LT5wZm5zX2xlbiA9IDA7Ci0gICAgLyogZnByaW50ZihzdGRlcnIsICJw YWdldGFibGVzPSV1LGNhY2hlX21pc3Nlcz0ldSxlbXB0eXBhZ2VzPSV1XG4iLCAqLwotICAgIC8q ICAgICAgICAgY3R4LT5wYWdldGFibGVfcGFnZXMsIGN0eC0+Y2FjaGVfbWlzc2VzLCBjdHgtPmVt cHR5cGFnZXMpOyAqLworICAgIGZwcmludGYoc3RkZXJyLCAicGFnZXRhYmxlcz0ldSxjYWNoZV9t aXNzZXM9JXUsZW1wdHlwYWdlcz0ldVxuIiwKKyAgICAgICAgICAgIGN0eC0+cGFnZXRhYmxlX3Bh Z2VzLCBjdHgtPmNhY2hlX21pc3NlcywgY3R4LT5lbXB0eXBhZ2VzKTsKICAgICBjdHgtPnBhZ2V0 YWJsZV9wYWdlcyA9IGN0eC0+Y2FjaGVfbWlzc2VzID0gY3R4LT5lbXB0eXBhZ2VzID0gMDsKIH0K IApkaWZmIC1yIGE5ZmQ2YzA1ZjQ2OSB0b29scy9saWJ4Yy94Y19kb21haW5fc2F2ZS5jCi0tLSBh L3Rvb2xzL2xpYnhjL3hjX2RvbWFpbl9zYXZlLmMJVGh1IE9jdCAxMyAwODo1MzowMyAyMDExIC0w NzAwCisrKyBiL3Rvb2xzL2xpYnhjL3hjX2RvbWFpbl9zYXZlLmMJV2VkIE9jdCAyNiAwOToxOTow MiAyMDExIC0wNzAwCkBAIC01NCwxMSArNTQsMjQgQEAKICAgICBzdHJ1Y3QgZG9tYWluX2luZm9f Y29udGV4dCBkaW5mbzsKIH07CiAKK3N0cnVjdCByZW11c19zdGF0cyB7CisgICAgc3RydWN0IHRp bWV2YWwgc3VzcGVuZFRpbWUsIHJlc3VtZVRpbWUsIGNvbXByZXNzVGltZSwgbWVtZmx1c2hUaW1l OworICAgIHVuc2lnbmVkIGludCBjb21taXREZWxheTsKKyAgICB1bnNpZ25lZCBpbnQgaXRlcl9z ZW50OworICAgIHVuc2lnbmVkIGxvbmcgY29tcHJlc3Npb247CisgICAgdW5zaWduZWQgaW50IGl0 ZXJfc3RhcnQ7CisgICAgdW5zaWduZWQgaW50IGl0ZXJfbm93OworICAgIHVuc2lnbmVkIGxvbmcg dG90YWxfc2VudDsKKyAgICB1bnNpZ25lZCBsb25nIHAybV9zaXplOworICAgIHN0cnVjdCB0aW1l dmFsIHN1c3BlbmRDYWxsLCByZXN1bWVDYWxsLCBzaGFkb3dDYWxsOworfTsKKwogLyogYnVmZmVy IGZvciBvdXRwdXQgKi8KIHN0cnVjdCBvdXRidWYgewogICAgIHZvaWQqIGJ1ZjsKICAgICBzaXpl X3Qgc2l6ZTsKICAgICBzaXplX3QgcG9zOworICAgIHVuc2lnbmVkIGxvbmcgdG90YWxfZGF0YV9z ZW50OwogfTsKIAogI2RlZmluZSBPVVRCVUZfU0laRSAoMTYzODQgKiAxMDI0KQpAQCAtMjE5LDYg KzIzMiw3IEBACiAgICAgICAgIHJjID0gd3JpdGUoZmQsIG9iLT5idWYgKyBjdXIsIG9iLT5wb3Mg LSBjdXIpOwogICAgIH0KIAorICAgIG9iLT50b3RhbF9kYXRhX3NlbnQgKz0gb2ItPnBvczsKICAg ICBvYi0+cG9zID0gMDsKIAogICAgIHJldHVybiAwOwpAQCAtMjUzLDcgKzI2Nyw3IEBACiB9CiAK IHN0YXRpYyBpbnQgd3JpdGVfY29tcHJlc3NlZCh4Y19pbnRlcmZhY2UgKnhjaCwgdm9pZCAqY29t cF9jdHgsIGludCBkb2J1ZiwKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJ1Y3Qgb3V0 YnVmKiBvYiwgaW50IGZkKQorICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0cnVjdCBvdXRi dWYqIG9iLCBpbnQgZmQsIHVuc2lnbmVkIGxvbmcgKmRhdGFfc2VudCkKIHsKICAgICBpbnQgcmMg PSAwOwogICAgIGludCBoZWFkZXIgPSBzaXplb2YoaW50KSArIHNpemVvZih1bnNpZ25lZCBsb25n KTsKQEAgLTI5Miw2ICszMDYsNyBAQAogICAgICAgICB9CiAKICAgICAgICAgb2ItPnBvcyArPSAo c2l6ZV90KSBjb21wYnVmX2xlbjsKKyAgICAgICAgKmRhdGFfc2VudCArPSBjb21wYnVmX2xlbjsK ICAgICAgICAgaWYgKCFkb2J1ZiAmJiBvdXRidWZfZmx1c2goeGNoLCBvYiwgZmQpIDwgMCkKICAg ICAgICAgewogICAgICAgICAgICAgRVJST1IoIkVycm9yIHdoZW4gd3JpdGluZyBjb21wcmVzc2Vk IGNodW5rIik7CkBAIC00NTksNiArNDc0LDQ3IEBACiAgICAgcmV0dXJuIDA7CiB9CiAKK3N0YXRp YyB2b2lkIHByaW50X3JlbXVzX3N0YXRzKHhjX2ludGVyZmFjZSAqeGNoLCBzdHJ1Y3QgcmVtdXNf c3RhdHMgKnJzdGF0cykKK3sKKyAgICB1bnNpZ25lZCBpbnQgc3VzcGVuZFRpbWUgPSAwLCBjb21w cmVzc1RpbWUgPSAwLCBmbHVzaFRpbWUgPSAwOworICAgIHVuc2lnbmVkIGludCBzdXNwZW5kQ2Fs bCA9IDAsIHJlc3VtZUNhbGwgPSAwLCBzaGFkb3dDYWxsID0gMDsKKworICAgIC8qIGludGVydmFs IHByZWNpc2lvbiBpbiBtaWNyb3NlY29uZHMuICovCisgICAgc3VzcGVuZENhbGwgPSAodW5zaWdu ZWQgaW50KSh0dl9kZWx0YSgmcnN0YXRzLT5zdXNwZW5kVGltZSwKKyAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICZyc3RhdHMtPnN1c3BlbmRDYWxsKSk7CisgICAgcmVz dW1lQ2FsbCA9ICh1bnNpZ25lZCBpbnQpKHR2X2RlbHRhKCZyc3RhdHMtPnJlc3VtZVRpbWUsCisg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZyc3RhdHMtPnJlc3VtZUNh bGwpKTsKKyAgICBzaGFkb3dDYWxsID0gKHVuc2lnbmVkIGludCkodHZfZGVsdGEoJnJzdGF0cy0+ c2hhZG93Q2FsbCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJnJz dGF0cy0+c3VzcGVuZFRpbWUpKTsKKyAgICBzdXNwZW5kVGltZSA9ICh1bnNpZ25lZCBpbnQpKHR2 X2RlbHRhKCZyc3RhdHMtPnJlc3VtZUNhbGwsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAmcnN0YXRzLT5zdXNwZW5kVGltZSkpOworCisgICAgaWYgKCFyc3RhdHMt PmNvbXByZXNzaW9uKQorICAgIHsKKyAgICAgICAgZmx1c2hUaW1lID0gKHVuc2lnbmVkIGludCko dHZfZGVsdGEoJnJzdGF0cy0+bWVtZmx1c2hUaW1lLAorICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAmcnN0YXRzLT5yZXN1bWVUaW1lKSk7CisgICAgfQorICAgIGVs c2UKKyAgICB7CisgICAgICAgIGNvbXByZXNzVGltZSA9ICh1bnNpZ25lZCBpbnQpKHR2X2RlbHRh KCZyc3RhdHMtPmNvbXByZXNzVGltZSwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgJnJzdGF0cy0+cmVzdW1lVGltZSkpOworICAgICAgICBmbHVzaFRpbWUg PSAodW5zaWduZWQgaW50KSh0dl9kZWx0YSgmcnN0YXRzLT5tZW1mbHVzaFRpbWUsCisgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZyc3RhdHMtPmNvbXByZXNzVGlt ZSkpOworICAgIH0KKworICAgIGZwcmludGYoc3RkZXJyLCAiJXM6JXU6c3VzcGVuZEF0OiVsdS4l MDZsdTpzY2FsbDoldTpyY2FsbDoldTpkY2FsbDoldToiCisgICAgICAgICAgICAic3VzcGVuZEZv cjoldTpjdGltZToldTpmbHVzaDoldTpjb21taXQ6JXU6dG9zZW5kOiV1OmNvbXA6JWx1XG4iLAor ICAgICAgICAgICAgcnN0YXRzLT5pdGVyX3N0YXJ0PyJSRU1VUyI6IklOSVRJQUwiLAorICAgICAg ICAgICAgKHJzdGF0cy0+aXRlcl9ub3cgLSByc3RhdHMtPml0ZXJfc3RhcnQpLAorICAgICAgICAg ICAgcnN0YXRzLT5zdXNwZW5kVGltZS50dl9zZWMsIHJzdGF0cy0+c3VzcGVuZFRpbWUudHZfdXNl YywKKyAgICAgICAgICAgIHN1c3BlbmRDYWxsLCByZXN1bWVDYWxsLCBzaGFkb3dDYWxsLAorICAg ICAgICAgICAgc3VzcGVuZFRpbWUsIGNvbXByZXNzVGltZSwgZmx1c2hUaW1lLAorICAgICAgICAg ICAgcnN0YXRzLT5jb21taXREZWxheSwKKyAgICAgICAgICAgIHJzdGF0cy0+aXRlcl9zZW50LCBy c3RhdHMtPmNvbXByZXNzaW9uKTsKKyAgICBmcHJpbnRmKHN0ZGVyciwgIlRvdGFsIERhdGEgU2Vu dD0gJS4zZiBNQlxuIiwKKyAgICAgICAgICAgICgoZmxvYXQpKHJzdGF0cy0+dG90YWxfc2VudC8o MTAyNC4wICogMTAyNC4wKSkpKTsKK30KKwogCiBzdGF0aWMgaW50IGFuYWx5c2lzX3BoYXNlKHhj X2ludGVyZmFjZSAqeGNoLCB1aW50MzJfdCBkb21pZCwgc3RydWN0IHNhdmVfY3R4ICpjdHgsCiAg ICAgICAgICAgICAgICAgICAgICAgICAgIHhjX2h5cGVyY2FsbF9idWZmZXJfdCAqYXJyLCBpbnQg cnVucykKQEAgLTk5NSw2ICsxMDUxLDcgQEAKICAgICB1bnNpZ25lZCBsb25nICp0b19maXggPSBO VUxMOwogCiAgICAgeGNfc2hhZG93X29wX3N0YXRzX3Qgc3RhdHM7CisgICAgc3RydWN0IHJlbXVz X3N0YXRzIHJzdGF0czsKIAogICAgIHVuc2lnbmVkIGxvbmcgbmVlZGVkX3RvX2ZpeCA9IDA7CiAg ICAgdW5zaWduZWQgbG9uZyB0b3RhbF9zZW50ICAgID0gMDsKQEAgLTEwMzYsNiArMTA5MywxMiBA QAogICAgIH0KIAogICAgIG91dGJ1Zl9pbml0KHhjaCwgJm9iX3BhZ2VidWYsIE9VVEJVRl9TSVpF KTsKKyAgICBtZW1zZXQoJnJzdGF0cywgMCwgc2l6ZW9mKHN0cnVjdCByZW11c19zdGF0cykpOyAg ICAKKyAgICBnZXR0aW1lb2ZkYXkoJnJzdGF0cy5zdXNwZW5kVGltZSwgTlVMTCk7CisgICAgZ2V0 dGltZW9mZGF5KCZyc3RhdHMucmVzdW1lVGltZSwgTlVMTCk7CisgICAgZ2V0dGltZW9mZGF5KCZy c3RhdHMuY29tcHJlc3NUaW1lLCBOVUxMKTsKKyAgICBnZXR0aW1lb2ZkYXkoJnJzdGF0cy5tZW1m bHVzaFRpbWUsIE5VTEwpOworICAgIGdldHRpbWVvZmRheSgmcnN0YXRzLmNvbXByZXNzVGltZSwg TlVMTCk7CiAKICAgICAvKiBJZiBubyBleHBsaWNpdCBjb250cm9sIHBhcmFtZXRlcnMgZ2l2ZW4s IHVzZSBkZWZhdWx0cyAqLwogICAgIG1heF9pdGVycyAgPSBtYXhfaXRlcnMgID8gOiBERUZfTUFY X0lURVJTOwpAQCAtMTA3Miw2ICsxMTM1LDcgQEAKIAogICAgIC8qIEdldCB0aGUgc2l6ZSBvZiB0 aGUgUDJNIHRhYmxlICovCiAgICAgZGluZm8tPnAybV9zaXplID0geGNfZG9tYWluX21heGltdW1f Z3Bmbih4Y2gsIGRvbSkgKyAxOworICAgIHJzdGF0cy5wMm1fc2l6ZSA9IGRpbmZvLT5wMm1fc2l6 ZTsKIAogICAgIGlmICggZGluZm8tPnAybV9zaXplID4gflhFTl9ET01DVExfUEZJTkZPX0xUQUJf TUFTSyApCiAgICAgewpAQCAtMTI3Myw5ICsxMzM3LDEwIEBACiAjdW5kZWYgcmF0ZXdyaXRlCiAj ZW5kaWYKICNkZWZpbmUgcmF0ZXdyaXRlKGZkLCBsaXZlLCBidWYsIGxlbikgcmF0ZXdyaXRlX2J1 ZmZlcih4Y2gsIGxhc3RfaXRlciwgb2IsIChmZCksIChsaXZlKSwgKGJ1ZiksIChsZW4pKQotI2Rl ZmluZSB3cmNvbXByZXNzZWQoZmQpIHdyaXRlX2NvbXByZXNzZWQoeGNoLCBjb21wcmVzc19jdHgs IGxhc3RfaXRlciwgb2IsIChmZCkpCisjZGVmaW5lIHdyY29tcHJlc3NlZChmZCkgd3JpdGVfY29t cHJlc3NlZCh4Y2gsIGNvbXByZXNzX2N0eCwgbGFzdF9pdGVyLCBvYiwgKGZkKSwgJihyc3RhdHMu Y29tcHJlc3Npb24pKQogCiAgICAgb2IgPSAmb2JfcGFnZWJ1ZjsgLyogSG9sZHMgcGZuX3R5cGVz LCBwYWdlcy9jb21wcmVzc2VkIHBhZ2VzICovCisgICAgb2JfcGFnZWJ1Zi50b3RhbF9kYXRhX3Nl bnQgPSBvYl90YWlsYnVmLnRvdGFsX2RhdGFfc2VudCA9IDA7CiAgICAgLyogTm93IHdyaXRlIG91 dCBlYWNoIGRhdGEgcGFnZSwgY2Fub25pY2FsaXNpbmcgcGFnZSB0YWJsZXMgYXMgd2UgZ28uLi4g Ki8KICAgICBmb3IgKCA7IDsgKQogICAgIHsKQEAgLTEyOTEsNiArMTM1Niw4IEBACiAgICAgICAg IGl0ZXIrKzsKICAgICAgICAgc2VudF90aGlzX2l0ZXIgPSAwOwogICAgICAgICBza2lwX3RoaXNf aXRlciA9IDA7CisgICAgICAgIHJzdGF0cy5jb21wcmVzc2lvbiA9IDA7CisgICAgICAgIHJzdGF0 cy5pdGVyX25vdyA9IGl0ZXI7CiAgICAgICAgIE4gPSAwOwogCiAgICAgICAgIHdoaWxlICggTiA8 IGRpbmZvLT5wMm1fc2l6ZSApCkBAIC0xNjUzLDggKzE3MjAsOSBAQAogICAgICAgICB4Y19yZXBv cnRfcHJvZ3Jlc3Nfc3RlcCh4Y2gsIGRpbmZvLT5wMm1fc2l6ZSwgZGluZm8tPnAybV9zaXplKTsK IAogICAgICAgICB0b3RhbF9zZW50ICs9IHNlbnRfdGhpc19pdGVyOworICAgICAgICByc3RhdHMu aXRlcl9zZW50ID0gc2VudF90aGlzX2l0ZXI7CiAKLSAgICAgICAgaWYgKCBsYXN0X2l0ZXIgKQor ICAgICAgICBpZiAoIDAgKQogICAgICAgICB7CiAgICAgICAgICAgICBwcmludF9zdGF0cyggeGNo LCBkb20sIHNlbnRfdGhpc19pdGVyLCAmc3RhdHMsIDEpOwogCkBAIC0xNjkyLDEzICsxNzYwLDE2 IEBACiAgICAgICAgICAgICB7CiAgICAgICAgICAgICAgICAgRFBSSU5URigiU3RhcnQgbGFzdCBp dGVyYXRpb25cbiIpOwogICAgICAgICAgICAgICAgIGxhc3RfaXRlciA9IDE7CisgICAgICAgICAg ICAgICAgcnN0YXRzLml0ZXJfc3RhcnQgPSBpdGVyOwogCisgICAgICAgICAgICAgICAgZ2V0dGlt ZW9mZGF5KCZyc3RhdHMuc3VzcGVuZENhbGwsIE5VTEwpOwogICAgICAgICAgICAgICAgIGlmICgg c3VzcGVuZF9hbmRfc3RhdGUoY2FsbGJhY2tzLT5zdXNwZW5kLCBjYWxsYmFja3MtPmRhdGEsCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB4Y2gsIGlvX2ZkLCBkb20sICZp bmZvKSApCiAgICAgICAgICAgICAgICAgewogICAgICAgICAgICAgICAgICAgICBFUlJPUigiRG9t YWluIGFwcGVhcnMgbm90IHRvIGhhdmUgc3VzcGVuZGVkIik7CiAgICAgICAgICAgICAgICAgICAg IGdvdG8gb3V0OwogICAgICAgICAgICAgICAgIH0KKyAgICAgICAgICAgICAgICBnZXR0aW1lb2Zk YXkoJnJzdGF0cy5zdXNwZW5kVGltZSwgTlVMTCk7CiAKICAgICAgICAgICAgICAgICBEUFJJTlRG KCJTVVNQRU5EIHNoaW5mbyAlMDhseFxuIiwgaW5mby5zaGFyZWRfaW5mb19mcmFtZSk7CiAgICAg ICAgICAgICAgICAgaWYgKCAodG1lbV9zYXZlZCA+IDApICYmCkBAIC0xNzI1LDE0ICsxNzk2LDE1 IEBACiAgICAgICAgICAgICAgICAgZ290byBvdXQ7CiAgICAgICAgICAgICB9CiAKKyAgICAgICAg ICAgIGdldHRpbWVvZmRheSgmcnN0YXRzLnNoYWRvd0NhbGwsIE5VTEwpOwogICAgICAgICAgICAg c2VudF9sYXN0X2l0ZXIgPSBzZW50X3RoaXNfaXRlcjsKIAotICAgICAgICAgICAgcHJpbnRfc3Rh dHMoeGNoLCBkb20sIHNlbnRfdGhpc19pdGVyLCAmc3RhdHMsIDEpOworICAgICAgICAgICAgLyog cHJpbnRfc3RhdHMoeGNoLCBkb20sIHNlbnRfdGhpc19pdGVyLCAmc3RhdHMsIDEpOyAqLwogCiAg ICAgICAgIH0KICAgICB9IC8qIGVuZCBvZiBpbmZpbml0ZSBmb3IgbG9vcCAqLwogCi0gICAgRFBS SU5URigiQWxsIG1lbW9yeSBpcyBzYXZlZFxuIik7CisgICAgLyogRFBSSU5URigiQWxsIG1lbW9y eSBpcyBzYXZlZFxuIik7ICovCiAKICAgICAvKiBBZnRlciBsYXN0X2l0ZXIsIGJ1ZmZlciB0aGUg cmVzdCBvZiBwYWdlYnVmICYgdGFpbGJ1ZiBkYXRhIGludG8gYQogICAgICAqIHNlcGFyYXRlIG91 dHB1dCBidWZmZXIgYW5kIGZsdXNoIGl0IGFmdGVyIHRoZSBjb21wcmVzc2VkIHBhZ2UgY2h1bmtz LgpAQCAtMjExMiw4ICsyMTg0LDEwIEBACiAgb3V0OgogICAgIGNvbXBsZXRlZCA9IDE7CiAKKyAg ICBnZXR0aW1lb2ZkYXkoJnJzdGF0cy5yZXN1bWVDYWxsLCBOVUxMKTsKICAgICBpZiAoICFyYyAm JiBjYWxsYmFja3MtPnBvc3Rjb3B5ICkKICAgICAgICAgY2FsbGJhY2tzLT5wb3N0Y29weShjYWxs YmFja3MtPmRhdGEpOworICAgIGdldHRpbWVvZmRheSgmcnN0YXRzLnJlc3VtZVRpbWUsIE5VTEwp OwogCiAgICAgLyogZ3Vlc3QgaGFzIGJlZW4gcmVzdW1lZC4gTm93IHdlIGNhbiBjb21wcmVzcyBk YXRhCiAgICAgICogYXQgb3VyIG93biBwYWNlLgpAQCAtMjEzNSw2ICsyMjA5LDcgQEAKICAgICAg ICAgICAgIGdvdG8gb3V0OwogICAgICAgICB9CiAgICAgfQorICAgIGdldHRpbWVvZmRheSgmcnN0 YXRzLmNvbXByZXNzVGltZSwgTlVMTCk7CiAKICAgICAvKiBGbHVzaCBsYXN0IHdyaXRlIGFuZCBk aXNjYXJkIGNhY2hlIGZvciBmaWxlLiAqLwogICAgIGlmICggb3V0YnVmX2ZsdXNoKHhjaCwgb2Is IGlvX2ZkKSA8IDAgKSB7CkBAIC0yMTQzLDI3ICsyMjE4LDM2IEBACiAgICAgfQogCiAgICAgZGlz Y2FyZF9maWxlX2NhY2hlKHhjaCwgaW9fZmQsIDEgLyogZmx1c2ggKi8pOworICAgIGdldHRpbWVv ZmRheSgmcnN0YXRzLm1lbWZsdXNoVGltZSwgTlVMTCk7CiAKICAgICAvKiBFbmFibGUgY29tcHJl c3Npb24gbm93LCBmaW5hbGx5ICovCiAgICAgY29tcHJlc3NpbmcgPSAoZmxhZ3MgJiBYQ0ZMQUdT X0NIRUNLUE9JTlRfQ09NUFJFU1MpOwogCiAgICAgLyogY2hlY2twb2ludF9jYiBjYW4gc3BlbmQg YXJiaXRyYXJpbHkgbG9uZyBpbiBiZXR3ZWVuIHJvdW5kcyAqLwogICAgIGlmICghcmMgJiYgY2Fs bGJhY2tzLT5jaGVja3BvaW50ICYmCi0gICAgICAgIGNhbGxiYWNrcy0+Y2hlY2twb2ludChjYWxs YmFja3MtPmRhdGEpID4gMCkKKyAgICAgICAgKHJzdGF0cy5jb21taXREZWxheSA9IGNhbGxiYWNr cy0+Y2hlY2twb2ludChjYWxsYmFja3MtPmRhdGEpKSA+IDApCiAgICAgewogICAgICAgICAvKiBy ZXNldCBzdGF0cyB0aW1lciAqLwotICAgICAgICBwcmludF9zdGF0cyh4Y2gsIGRvbSwgMCwgJnN0 YXRzLCAwKTsKKyAgICAgICAgLyogcHJpbnRfc3RhdHMoeGNoLCBkb20sIDAsICZzdGF0cywgMCk7 ICovCisgICAgICAgIC8qIHByaW50X3N0YXRzKHhjaCwgZG9tLCAwLCAmdGltZV9zdGF0cywgJnNo YWRvd19zdGF0cywgMCk7ICovCisgICAgICAgIC8qIHN1YnRyYWN0IDEgZnJvbSBjb21taXREZWxh eSBzaW5jZSB0aGUgcHl0aG9uIGNvZGUgYWRkcyAxICovCisgICAgICAgIHJzdGF0cy5jb21taXRE ZWxheSAtPSAxOworICAgICAgICByc3RhdHMudG90YWxfc2VudCArPSBvYl9wYWdlYnVmLnRvdGFs X2RhdGFfc2VudDsKKyAgICAgICAgcnN0YXRzLnRvdGFsX3NlbnQgKz0gb2JfdGFpbGJ1Zi50b3Rh bF9kYXRhX3NlbnQ7CisgICAgICAgIHByaW50X3JlbXVzX3N0YXRzKHhjaCwgJnJzdGF0cyk7CiAK ICAgICAgICAgcmMgPSAxOwogICAgICAgICAvKiBsYXN0X2l0ZXIgPSAxOyAqLworICAgICAgICBn ZXR0aW1lb2ZkYXkoJnJzdGF0cy5zdXNwZW5kQ2FsbCwgTlVMTCk7CiAgICAgICAgIGlmICggc3Vz cGVuZF9hbmRfc3RhdGUoY2FsbGJhY2tzLT5zdXNwZW5kLCBjYWxsYmFja3MtPmRhdGEsIHhjaCwK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpb19mZCwgZG9tLCAmaW5mbykgKQogICAg ICAgICB7CiAgICAgICAgICAgICBFUlJPUigiRG9tYWluIGFwcGVhcnMgbm90IHRvIGhhdmUgc3Vz cGVuZGVkIik7CiAgICAgICAgICAgICBnb3RvIG91dDsKICAgICAgICAgfQotICAgICAgICBEUFJJ TlRGKCJTVVNQRU5EIHNoaW5mbyAlMDhseFxuIiwgaW5mby5zaGFyZWRfaW5mb19mcmFtZSk7Ci0g ICAgICAgIHByaW50X3N0YXRzKHhjaCwgZG9tLCAwLCAmc3RhdHMsIDEpOworICAgICAgICAvKiBE UFJJTlRGKCJTVVNQRU5EIHNoaW5mbyAlMDhseFxuIiwgaW5mby5zaGFyZWRfaW5mb19mcmFtZSk7 ICovCisgICAgICAgIC8qIHByaW50X3N0YXRzKHhjaCwgZG9tLCAwLCAmc3RhdHMsIDEpOyAqLwor ICAgICAgICBnZXR0aW1lb2ZkYXkoJnJzdGF0cy5zdXNwZW5kVGltZSwgTlVMTCk7CiAKICAgICAg ICAgaWYgKCB4Y19zaGFkb3dfY29udHJvbCh4Y2gsIGRvbSwKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBYRU5fRE9NQ1RMX1NIQURPV19PUF9DTEVBTiwgSFlQRVJDQUxMX0JVRkZFUih0 b19zZW5kKSwKQEAgLTIxNzIsNiArMjI1Niw3IEBACiAgICAgICAgICAgICBQRVJST1IoIkVycm9y IGZsdXNoaW5nIHNoYWRvdyBQVCIpOwogICAgICAgICB9CiAKKyAgICAgICAgZ2V0dGltZW9mZGF5 KCZyc3RhdHMuc2hhZG93Q2FsbCwgTlVMTCk7CiAgICAgICAgIGdvdG8gY29weXBhZ2VzOwogICAg IH0KIApkaWZmIC1yIGE5ZmQ2YzA1ZjQ2OSB0b29scy9weXRob24veGVuL2xvd2xldmVsL2NoZWNr cG9pbnQvY2hlY2twb2ludC5jCi0tLSBhL3Rvb2xzL3B5dGhvbi94ZW4vbG93bGV2ZWwvY2hlY2tw b2ludC9jaGVja3BvaW50LmMJVGh1IE9jdCAxMyAwODo1MzowMyAyMDExIC0wNzAwCisrKyBiL3Rv b2xzL3B5dGhvbi94ZW4vbG93bGV2ZWwvY2hlY2twb2ludC9jaGVja3BvaW50LmMJV2VkIE9jdCAy NiAwOToxOTowMiAyMDExIC0wNzAwCkBAIC0zNDMsNiArMzQzLDcgQEAKICAgQ2hlY2twb2ludE9i amVjdCogc2VsZiA9IChDaGVja3BvaW50T2JqZWN0KilkYXRhOwogCiAgIFB5T2JqZWN0KiByZXN1 bHQ7CisgIGxvbmcgY29tbWl0VGltZSA9IDE7CiAKICAgaWYgKGNoZWNrcG9pbnRfcG9zdGZsdXNo KCZzZWxmLT5jcHMpIDwgMCkgewogICAgICAgZnByaW50ZihzdGRlcnIsICIlc1xuIiwgY2hlY2tw b2ludF9lcnJvcigmc2VsZi0+Y3BzKSk7CkBAIC0zNTksMTIgKzM2MCwxMCBAQAogICBpZiAoIXJl c3VsdCkKICAgICByZXR1cm4gMDsKIAotICBpZiAocmVzdWx0ID09IFB5X05vbmUgfHwgUHlPYmpl Y3RfSXNUcnVlKHJlc3VsdCkpIHsKLSAgICBQeV9ERUNSRUYocmVzdWx0KTsKLSAgICByZXR1cm4g MTsKLSAgfQorICBpZiAocmVzdWx0ICE9IFB5X05vbmUpCisgICAgY29tbWl0VGltZSA9IFB5SW50 X0FTX0xPTkcocmVzdWx0KTsKIAogICBQeV9ERUNSRUYocmVzdWx0KTsKIAotICByZXR1cm4gMDsK KyAgcmV0dXJuIChpbnQpY29tbWl0VGltZTsKIH0KZGlmZiAtciBhOWZkNmMwNWY0NjkgdG9vbHMv cHl0aG9uL3hlbi9sb3dsZXZlbC9jaGVja3BvaW50L2xpYmNoZWNrcG9pbnQuYwotLS0gYS90b29s cy9weXRob24veGVuL2xvd2xldmVsL2NoZWNrcG9pbnQvbGliY2hlY2twb2ludC5jCVRodSBPY3Qg MTMgMDg6NTM6MDMgMjAxMSAtMDcwMAorKysgYi90b29scy9weXRob24veGVuL2xvd2xldmVsL2No ZWNrcG9pbnQvbGliY2hlY2twb2ludC5jCVdlZCBPY3QgMjYgMDk6MTk6MDIgMjAxMSAtMDcwMApA QCAtMjA1LDEzICsyMDUsOCBAQAogLyogc3VzcGVuZCB0aGUgZG9tYWluLiBSZXR1cm5zIDAgb24g ZmFpbHVyZSwgMSBvbiBzdWNjZXNzICovCiBpbnQgY2hlY2twb2ludF9zdXNwZW5kKGNoZWNrcG9p bnRfc3RhdGUqIHMpCiB7Ci0gIHN0cnVjdCB0aW1ldmFsIHR2OwogICBpbnQgcmM7CiAKLSAgZ2V0 dGltZW9mZGF5KCZ0diwgTlVMTCk7Ci0gIGZwcmludGYoc3RkZXJyLCAiUFJPRjogc3VzcGVuZGlu ZyBhdCAlbHUuJTA2bHVcbiIsICh1bnNpZ25lZCBsb25nKXR2LnR2X3NlYywKLSAgICAgICAgICh1 bnNpZ25lZCBsb25nKXR2LnR2X3VzZWMpOwotCiAgIGlmIChzLT5zdXNwZW5kX2V2dGNobiA+PSAw KQogICAgICAgcmMgPSBldnRjaG5fc3VzcGVuZChzKTsKICAgZWxzZSBpZiAocy0+ZG9tdHlwZSA9 PSBkdF9odm0pCkBAIC0yNTQsNyArMjQ5LDYgQEAKIC8qIGxldCBndWVzdCBleGVjdXRpb24gcmVz dW1lICovCiBpbnQgY2hlY2twb2ludF9yZXN1bWUoY2hlY2twb2ludF9zdGF0ZSogcykKIHsKLSAg c3RydWN0IHRpbWV2YWwgdHY7CiAgIGludCByYzsKIAogICBpZiAoeGNfZG9tYWluX3Jlc3VtZShz LT54Y2gsIHMtPmRvbWlkLCAxKSkgewpAQCAtMjY0LDEwICsyNTgsNiBAQAogICAgIHJldHVybiAt MTsKICAgfQogCi0gIGdldHRpbWVvZmRheSgmdHYsIE5VTEwpOwotICBmcHJpbnRmKHN0ZGVyciwg IlBST0Y6IHJlc3VtZWQgYXQgJWx1LiUwNmx1XG4iLCAodW5zaWduZWQgbG9uZyl0di50dl9zZWMs Ci0gICAgICAgICAodW5zaWduZWQgbG9uZyl0di50dl91c2VjKTsKLQogICBpZiAocy0+ZG9tdHlw ZSA+IGR0X3B2ICYmIHJlc3VtZV9xZW11KHMpIDwgMCkKICAgICAgIHJldHVybiAtMTsKIApAQCAt NTgwLDEzICs1NzAsMTMgQEAKIHsKICAgICBpbnQgcmMgPSAtMTsKIAotICAgIGZwcmludGYoc3Rk ZXJyLCAiaXNzdWluZyBIVk0gc3VzcGVuZCBoeXBlcmNhbGxcbiIpOworICAgIC8qIGZwcmludGYo c3RkZXJyLCAiaXNzdWluZyBIVk0gc3VzcGVuZCBoeXBlcmNhbGxcbiIpOyAqLwogICAgIHJjID0g eGNfZG9tYWluX3NodXRkb3duKHMtPnhjaCwgcy0+ZG9taWQsIFNIVVRET1dOX3N1c3BlbmQpOwog ICAgIGlmIChyYyA8IDApIHsKICAgICAgICBzLT5lcnJzdHIgPSAic2h1dGRvd24gaHlwZXJjYWxs IGZhaWxlZCI7CiAgICAgICAgcmV0dXJuIC0xOwogICAgIH0KLSAgICBmcHJpbnRmKHN0ZGVyciwg InN1c3BlbmQgaHlwZXJjYWxsIHJldHVybmVkICVkXG4iLCByYyk7CisgICAgLyogZnByaW50Zihz dGRlcnIsICJzdXNwZW5kIGh5cGVyY2FsbCByZXR1cm5lZCAlZFxuIiwgcmMpOyAqLwogCiAgICAg aWYgKGNoZWNrX3NodXRkb3duKHMpICE9IDEpCiAgICAgICAgcmV0dXJuIC0xOwpAQCAtNjAwLDcg KzU5MCw3IEBACiB7CiAgICAgY2hhciBwYXRoWzEyOF07CiAKLSAgICBmcHJpbnRmKHN0ZGVyciwg InBhdXNpbmcgUUVNVVxuIik7CisgICAgLyogZnByaW50ZihzdGRlcnIsICJwYXVzaW5nIFFFTVVc biIpOyAqLwogCiAgICAgc3ByaW50ZihwYXRoLCAiL2xvY2FsL2RvbWFpbi8wL2RldmljZS1tb2Rl bC8lZC9jb21tYW5kIiwgcy0+ZG9taWQpOwogICAgIGlmICgheHNfd3JpdGUocy0+eHNoLCBYQlRf TlVMTCwgcGF0aCwgInNhdmUiLCA0KSkgewpAQCAtNjM1LDcgKzYyNSw3IEBACiBzdGF0aWMgaW50 IHJlc3VtZV9xZW11KGNoZWNrcG9pbnRfc3RhdGUgKnMpCiB7CiAgICAgY2hhciBwYXRoWzEyOF07 Ci0gICAgZnByaW50ZihzdGRlcnIsICJyZXN1bWluZyBRRU1VXG4iKTsKKyAgICAvKiBmcHJpbnRm KHN0ZGVyciwgInJlc3VtaW5nIFFFTVVcbiIpOyAqLwogCiAgICAgc3ByaW50ZihwYXRoLCAiL2xv Y2FsL2RvbWFpbi8wL2RldmljZS1tb2RlbC8lZC9jb21tYW5kIiwgcy0+ZG9taWQpOwogICAgIGlm ICgheHNfd3JpdGUocy0+eHNoLCBYQlRfTlVMTCwgcGF0aCwgImNvbnRpbnVlIiwgOCkpIHsKZGlm ZiAtciBhOWZkNmMwNWY0NjkgdG9vbHMvcmVtdXMvcmVtdXMKLS0tIGEvdG9vbHMvcmVtdXMvcmVt dXMJVGh1IE9jdCAxMyAwODo1MzowMyAyMDExIC0wNzAwCisrKyBiL3Rvb2xzL3JlbXVzL3JlbXVz CVdlZCBPY3QgMjYgMDk6MTk6MDIgMjAxMSAtMDcwMApAQCAtNzgsNiArNzgsNyBAQAogZGVmIHJ1 bihjZmcpOgogICAgIGNsb3N1cmUgPSBsYW1iZGE6IE5vbmUKICAgICBjbG9zdXJlLmNtZCA9IE5v bmUKKyAgICBjbG9zdXJlLmVwb2NoID0gMAogCiAgICAgZGVmIHNpZ2V4Y2VwdGlvbihzaWdubywg ZnJhbWUpOgogICAgICAgICByYWlzZSBTaWduYWxFeGNlcHRpb24oc2lnbm8pCkBAIC0xNDIsNiAr MTQzLDcgQEAKICAgICAgICAgaWYgbm90IGNmZy50aW1lcjoKICAgICAgICAgICAgICMgd2hlbiBu b3QgdXNpbmcgYSB0aW1lciB0aHJlYWQsIHNsZWVwIHVudGlsIG5vdyArIGludGVydmFsCiAgICAg ICAgICAgICBjbG9zdXJlLnN0YXJ0dGltZSA9IHRpbWUudGltZSgpCisgICAgICAgICAgICBjbG9z dXJlLmVwb2NoID0gY2xvc3VyZS5lcG9jaCArIDEKIAogICAgICAgICBpZiBjbG9zdXJlLmNtZCA9 PSAncyc6CiAgICAgICAgICAgICBkaWUoKQpAQCAtMTY4LDEwICsxNzAsMTEgQEAKICAgICAgICAg aWYgY2xvc3VyZS5jbWQgPT0gJ2MnOgogICAgICAgICAgICAgZGllKCkKIAotICAgICAgICBwcmlu dCA+PiBzeXMuc3RkZXJyLCAiUFJPRjogZmx1c2hlZCBtZW1vcnkgYXQgJTAuNmYiICUgKHRpbWUu dGltZSgpKQotCisgICAgICAgICMgcHJpbnQgPj4gc3lzLnN0ZGVyciwgIlBST0Y6IGZsdXNoZWQg bWVtb3J5IGF0ICUwLjZmIiAlICh0aW1lLnRpbWUoKSkKKyAgICAgICAgdG1wdGltZSA9IHRpbWUu dGltZSgpCiAgICAgICAgIGZvciBidWYgaW4gYnVmczoKICAgICAgICAgICAgIGJ1Zi5jb21taXQo KQorICAgICAgICBlbmR0aW1lID0gdGltZS50aW1lKCkKIAogICAgICAgICBpZiBjbG9zdXJlLmNt ZCA9PSAnYzInOgogICAgICAgICAgICAgZGllKCkKQEAgLTE4MSwxNCArMTg0LDEzIEBACiAgICAg ICAgICMgZ2V0Y29tbWFuZCgpCiAKICAgICAgICAgaWYgbm90IGNmZy50aW1lcjoKLSAgICAgICAg ICAgIGVuZHRpbWUgPSB0aW1lLnRpbWUoKQogICAgICAgICAgICAgZWxhcHNlZCA9IChlbmR0aW1l IC0gY2xvc3VyZS5zdGFydHRpbWUpICogMTAwMAogCiAgICAgICAgICAgICBpZiBlbGFwc2VkIDwg Y2ZnLmludGVydmFsOgogICAgICAgICAgICAgICAgIHRpbWUuc2xlZXAoKGNmZy5pbnRlcnZhbCAt IGVsYXBzZWQpIC8gMTAwMC4wKQogCi0gICAgICAgICMgRmFsc2UgZW5kcyBjaGVja3BvaW50aW5n Ci0gICAgICAgIHJldHVybiBUcnVlCisgICAgICAgICMgMCBlbmRzIGNoZWNrcG9pbnRpbmcKKyAg ICAgICAgcmV0dXJuIGludCgoKGVuZHRpbWUgLSB0bXB0aW1lKSAqIDEwMDApICsgMSkKIAogICAg IGlmIGNmZy50aW1lcjoKICAgICAgICAgaW50ZXJ2YWwgPSBjZmcuaW50ZXJ2YWwKZGlmZiAtciBh OWZkNmMwNWY0NjkgeGVuL2NvbW1vbi9odm0vc2F2ZS5jCi0tLSBhL3hlbi9jb21tb24vaHZtL3Nh dmUuYwlUaHUgT2N0IDEzIDA4OjUzOjAzIDIwMTEgLTA3MDAKKysrIGIveGVuL2NvbW1vbi9odm0v c2F2ZS5jCVdlZCBPY3QgMjYgMDk6MTk6MDIgMjAxMSAtMDcwMApAQCAtMTU5LDcgKzE1OSw3IEBA CiAgICAgICAgIGhhbmRsZXIgPSBodm1fc3JfaGFuZGxlcnNbaV0uc2F2ZTsKICAgICAgICAgaWYg KCBoYW5kbGVyICE9IE5VTEwgKSAKICAgICAgICAgewotICAgICAgICAgICAgZ2RwcmludGsoWEVO TE9HX0lORk8sICJIVk0gc2F2ZTogJXNcbiIsICBodm1fc3JfaGFuZGxlcnNbaV0ubmFtZSk7Cisg ICAgICAgICAgICAvL2dkcHJpbnRrKFhFTkxPR19JTkZPLCAiSFZNIHNhdmU6ICVzXG4iLCAgaHZt X3NyX2hhbmRsZXJzW2ldLm5hbWUpOwogICAgICAgICAgICAgaWYgKCBoYW5kbGVyKGQsIGgpICE9 IDAgKSAKICAgICAgICAgICAgIHsKICAgICAgICAgICAgICAgICBnZHByaW50ayhYRU5MT0dfRVJS LCAK --20cf3068469f24eb5604cb535631 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --20cf3068469f24eb5604cb535631-- From xen-devel-bounces@lists.xen.org Fri Oct 05 17:38:46 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 17:38:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKBqz-0001vI-DE; Fri, 05 Oct 2012 17:38:25 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKBqx-0001v6-D1 for xen-devel@lists.xen.org; Fri, 05 Oct 2012 17:38:23 +0000 Received: from [85.158.137.99:32654] by server-6.bemta-3.messagelabs.com id 4B/DB-11085-E0B1F605; Fri, 05 Oct 2012 17:38:22 +0000 X-Env-Sender: rshriram@cs.ubc.ca X-Msg-Ref: server-13.tower-217.messagelabs.com!1349458699!20473728!1 X-Originating-IP: [142.103.6.52] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1407 invoked from network); 5 Oct 2012 17:38:20 -0000 Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52) by server-13.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 17:38:20 -0000 Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (authenticated bits=0) by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q95HcGsS012216 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Fri, 5 Oct 2012 10:38:17 -0700 Received: by mail-wi0-f173.google.com with SMTP id hm4so854425wib.14 for ; Fri, 05 Oct 2012 10:38:14 -0700 (PDT) Received: by 10.180.78.102 with SMTP id a6mr4715142wix.20.1349458694826; Fri, 05 Oct 2012 10:38:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.40.102 with HTTP; Fri, 5 Oct 2012 10:37:34 -0700 (PDT) In-Reply-To: References: <75A1D5EB-12C7-4829-A3F7-4D77B2405FBB@gmail.com> From: Shriram Rajagopalan Date: Fri, 5 Oct 2012 10:37:34 -0700 Message-ID: To: =?ISO-8859-1?Q?Jos=E9_Eduardo_Fran=E7a?= Content-Type: multipart/mixed; boundary=20cf3068469f24eb5604cb535631 Cc: lmingcsce , xen-devel@lists.xen.org Subject: Re: [Xen-devel] How to get the checkpoint size in remus code? X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: rshriram@cs.ubc.ca List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --20cf3068469f24eb5604cb535631 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Oct 3, 2012 at 4:11 AM, Jos=E9 Eduardo Fran=E7a wrote: > > I thought remus used xc_domain_save. Is this function used from live > migration? > > Futhermore I have two doubts if really Remus takes the last iteration of > live migration > > What's the function? There is no specific function. xc_domain_save is where everything happens. The infinite loop that basically keeps sending checkpoints @ a particular frequency > And how to get de I/O disk size on each period? > This depends on the disk backend. With blktap2 (unfortunately not available in 3.* kernels) tap-remus driver can give you the number of disk blocks sent per checkpoint= . With DRBD, it needs a little bit of hacking into the kernel module to return the number of disk blocks being sent with each checkpoint. >> I'm doing my master research and I need to adapt remus code. Now... I >> wanna get the checkpoint size (memory + disk) on each period. Does someo= ne >> know what function does this? I think some fd object's function in remus >> code could just get the memory size. >> You can get memory checkpoint stats for each iteration - like number of pages dirtied, size of data actually transmitted after compression (including headers, etc), time to checkpoint, etc. The attached patch (for xen-4.1.2) will give you the memory checkpoint stats for each checkpoint and can be easily parsed. shriram --20cf3068469f24eb5604cb535631 Content-Type: application/octet-stream; name="04_stats_fix.patch" Content-Disposition: attachment; filename="04_stats_fix.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h7xksv9e0 ZGlmZiAtciBhOWZkNmMwNWY0NjkgdG9vbHMvbGlieGMveGNfY29tcHJlc3Npb24uYwotLS0gYS90 b29scy9saWJ4Yy94Y19jb21wcmVzc2lvbi5jCVRodSBPY3QgMTMgMDg6NTM6MDMgMjAxMSAtMDcw MAorKysgYi90b29scy9saWJ4Yy94Y19jb21wcmVzc2lvbi5jCVdlZCBPY3QgMjYgMDk6MTk6MDIg MjAxMSAtMDcwMApAQCAtNDUxLDggKzQ1MSw4IEBACiB2b2lkIHhjX2NvbXByZXNzaW9uX3Jlc2V0 X3BhZ2VidWYoeGNfaW50ZXJmYWNlICp4Y2gsIGNvbXBfY3R4ICpjdHgpCiB7CiAgICAgY3R4LT5w Zm5zX2luZGV4ID0gY3R4LT5wZm5zX2xlbiA9IDA7Ci0gICAgLyogZnByaW50ZihzdGRlcnIsICJw YWdldGFibGVzPSV1LGNhY2hlX21pc3Nlcz0ldSxlbXB0eXBhZ2VzPSV1XG4iLCAqLwotICAgIC8q ICAgICAgICAgY3R4LT5wYWdldGFibGVfcGFnZXMsIGN0eC0+Y2FjaGVfbWlzc2VzLCBjdHgtPmVt cHR5cGFnZXMpOyAqLworICAgIGZwcmludGYoc3RkZXJyLCAicGFnZXRhYmxlcz0ldSxjYWNoZV9t aXNzZXM9JXUsZW1wdHlwYWdlcz0ldVxuIiwKKyAgICAgICAgICAgIGN0eC0+cGFnZXRhYmxlX3Bh Z2VzLCBjdHgtPmNhY2hlX21pc3NlcywgY3R4LT5lbXB0eXBhZ2VzKTsKICAgICBjdHgtPnBhZ2V0 YWJsZV9wYWdlcyA9IGN0eC0+Y2FjaGVfbWlzc2VzID0gY3R4LT5lbXB0eXBhZ2VzID0gMDsKIH0K IApkaWZmIC1yIGE5ZmQ2YzA1ZjQ2OSB0b29scy9saWJ4Yy94Y19kb21haW5fc2F2ZS5jCi0tLSBh L3Rvb2xzL2xpYnhjL3hjX2RvbWFpbl9zYXZlLmMJVGh1IE9jdCAxMyAwODo1MzowMyAyMDExIC0w NzAwCisrKyBiL3Rvb2xzL2xpYnhjL3hjX2RvbWFpbl9zYXZlLmMJV2VkIE9jdCAyNiAwOToxOTow MiAyMDExIC0wNzAwCkBAIC01NCwxMSArNTQsMjQgQEAKICAgICBzdHJ1Y3QgZG9tYWluX2luZm9f Y29udGV4dCBkaW5mbzsKIH07CiAKK3N0cnVjdCByZW11c19zdGF0cyB7CisgICAgc3RydWN0IHRp bWV2YWwgc3VzcGVuZFRpbWUsIHJlc3VtZVRpbWUsIGNvbXByZXNzVGltZSwgbWVtZmx1c2hUaW1l OworICAgIHVuc2lnbmVkIGludCBjb21taXREZWxheTsKKyAgICB1bnNpZ25lZCBpbnQgaXRlcl9z ZW50OworICAgIHVuc2lnbmVkIGxvbmcgY29tcHJlc3Npb247CisgICAgdW5zaWduZWQgaW50IGl0 ZXJfc3RhcnQ7CisgICAgdW5zaWduZWQgaW50IGl0ZXJfbm93OworICAgIHVuc2lnbmVkIGxvbmcg dG90YWxfc2VudDsKKyAgICB1bnNpZ25lZCBsb25nIHAybV9zaXplOworICAgIHN0cnVjdCB0aW1l dmFsIHN1c3BlbmRDYWxsLCByZXN1bWVDYWxsLCBzaGFkb3dDYWxsOworfTsKKwogLyogYnVmZmVy IGZvciBvdXRwdXQgKi8KIHN0cnVjdCBvdXRidWYgewogICAgIHZvaWQqIGJ1ZjsKICAgICBzaXpl X3Qgc2l6ZTsKICAgICBzaXplX3QgcG9zOworICAgIHVuc2lnbmVkIGxvbmcgdG90YWxfZGF0YV9z ZW50OwogfTsKIAogI2RlZmluZSBPVVRCVUZfU0laRSAoMTYzODQgKiAxMDI0KQpAQCAtMjE5LDYg KzIzMiw3IEBACiAgICAgICAgIHJjID0gd3JpdGUoZmQsIG9iLT5idWYgKyBjdXIsIG9iLT5wb3Mg LSBjdXIpOwogICAgIH0KIAorICAgIG9iLT50b3RhbF9kYXRhX3NlbnQgKz0gb2ItPnBvczsKICAg ICBvYi0+cG9zID0gMDsKIAogICAgIHJldHVybiAwOwpAQCAtMjUzLDcgKzI2Nyw3IEBACiB9CiAK IHN0YXRpYyBpbnQgd3JpdGVfY29tcHJlc3NlZCh4Y19pbnRlcmZhY2UgKnhjaCwgdm9pZCAqY29t cF9jdHgsIGludCBkb2J1ZiwKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJ1Y3Qgb3V0 YnVmKiBvYiwgaW50IGZkKQorICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0cnVjdCBvdXRi dWYqIG9iLCBpbnQgZmQsIHVuc2lnbmVkIGxvbmcgKmRhdGFfc2VudCkKIHsKICAgICBpbnQgcmMg PSAwOwogICAgIGludCBoZWFkZXIgPSBzaXplb2YoaW50KSArIHNpemVvZih1bnNpZ25lZCBsb25n KTsKQEAgLTI5Miw2ICszMDYsNyBAQAogICAgICAgICB9CiAKICAgICAgICAgb2ItPnBvcyArPSAo c2l6ZV90KSBjb21wYnVmX2xlbjsKKyAgICAgICAgKmRhdGFfc2VudCArPSBjb21wYnVmX2xlbjsK ICAgICAgICAgaWYgKCFkb2J1ZiAmJiBvdXRidWZfZmx1c2goeGNoLCBvYiwgZmQpIDwgMCkKICAg ICAgICAgewogICAgICAgICAgICAgRVJST1IoIkVycm9yIHdoZW4gd3JpdGluZyBjb21wcmVzc2Vk IGNodW5rIik7CkBAIC00NTksNiArNDc0LDQ3IEBACiAgICAgcmV0dXJuIDA7CiB9CiAKK3N0YXRp YyB2b2lkIHByaW50X3JlbXVzX3N0YXRzKHhjX2ludGVyZmFjZSAqeGNoLCBzdHJ1Y3QgcmVtdXNf c3RhdHMgKnJzdGF0cykKK3sKKyAgICB1bnNpZ25lZCBpbnQgc3VzcGVuZFRpbWUgPSAwLCBjb21w cmVzc1RpbWUgPSAwLCBmbHVzaFRpbWUgPSAwOworICAgIHVuc2lnbmVkIGludCBzdXNwZW5kQ2Fs bCA9IDAsIHJlc3VtZUNhbGwgPSAwLCBzaGFkb3dDYWxsID0gMDsKKworICAgIC8qIGludGVydmFs IHByZWNpc2lvbiBpbiBtaWNyb3NlY29uZHMuICovCisgICAgc3VzcGVuZENhbGwgPSAodW5zaWdu ZWQgaW50KSh0dl9kZWx0YSgmcnN0YXRzLT5zdXNwZW5kVGltZSwKKyAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICZyc3RhdHMtPnN1c3BlbmRDYWxsKSk7CisgICAgcmVz dW1lQ2FsbCA9ICh1bnNpZ25lZCBpbnQpKHR2X2RlbHRhKCZyc3RhdHMtPnJlc3VtZVRpbWUsCisg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZyc3RhdHMtPnJlc3VtZUNh bGwpKTsKKyAgICBzaGFkb3dDYWxsID0gKHVuc2lnbmVkIGludCkodHZfZGVsdGEoJnJzdGF0cy0+ c2hhZG93Q2FsbCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJnJz dGF0cy0+c3VzcGVuZFRpbWUpKTsKKyAgICBzdXNwZW5kVGltZSA9ICh1bnNpZ25lZCBpbnQpKHR2 X2RlbHRhKCZyc3RhdHMtPnJlc3VtZUNhbGwsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAmcnN0YXRzLT5zdXNwZW5kVGltZSkpOworCisgICAgaWYgKCFyc3RhdHMt PmNvbXByZXNzaW9uKQorICAgIHsKKyAgICAgICAgZmx1c2hUaW1lID0gKHVuc2lnbmVkIGludCko dHZfZGVsdGEoJnJzdGF0cy0+bWVtZmx1c2hUaW1lLAorICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAmcnN0YXRzLT5yZXN1bWVUaW1lKSk7CisgICAgfQorICAgIGVs c2UKKyAgICB7CisgICAgICAgIGNvbXByZXNzVGltZSA9ICh1bnNpZ25lZCBpbnQpKHR2X2RlbHRh KCZyc3RhdHMtPmNvbXByZXNzVGltZSwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgJnJzdGF0cy0+cmVzdW1lVGltZSkpOworICAgICAgICBmbHVzaFRpbWUg PSAodW5zaWduZWQgaW50KSh0dl9kZWx0YSgmcnN0YXRzLT5tZW1mbHVzaFRpbWUsCisgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZyc3RhdHMtPmNvbXByZXNzVGlt ZSkpOworICAgIH0KKworICAgIGZwcmludGYoc3RkZXJyLCAiJXM6JXU6c3VzcGVuZEF0OiVsdS4l MDZsdTpzY2FsbDoldTpyY2FsbDoldTpkY2FsbDoldToiCisgICAgICAgICAgICAic3VzcGVuZEZv cjoldTpjdGltZToldTpmbHVzaDoldTpjb21taXQ6JXU6dG9zZW5kOiV1OmNvbXA6JWx1XG4iLAor ICAgICAgICAgICAgcnN0YXRzLT5pdGVyX3N0YXJ0PyJSRU1VUyI6IklOSVRJQUwiLAorICAgICAg ICAgICAgKHJzdGF0cy0+aXRlcl9ub3cgLSByc3RhdHMtPml0ZXJfc3RhcnQpLAorICAgICAgICAg ICAgcnN0YXRzLT5zdXNwZW5kVGltZS50dl9zZWMsIHJzdGF0cy0+c3VzcGVuZFRpbWUudHZfdXNl YywKKyAgICAgICAgICAgIHN1c3BlbmRDYWxsLCByZXN1bWVDYWxsLCBzaGFkb3dDYWxsLAorICAg ICAgICAgICAgc3VzcGVuZFRpbWUsIGNvbXByZXNzVGltZSwgZmx1c2hUaW1lLAorICAgICAgICAg ICAgcnN0YXRzLT5jb21taXREZWxheSwKKyAgICAgICAgICAgIHJzdGF0cy0+aXRlcl9zZW50LCBy c3RhdHMtPmNvbXByZXNzaW9uKTsKKyAgICBmcHJpbnRmKHN0ZGVyciwgIlRvdGFsIERhdGEgU2Vu dD0gJS4zZiBNQlxuIiwKKyAgICAgICAgICAgICgoZmxvYXQpKHJzdGF0cy0+dG90YWxfc2VudC8o MTAyNC4wICogMTAyNC4wKSkpKTsKK30KKwogCiBzdGF0aWMgaW50IGFuYWx5c2lzX3BoYXNlKHhj X2ludGVyZmFjZSAqeGNoLCB1aW50MzJfdCBkb21pZCwgc3RydWN0IHNhdmVfY3R4ICpjdHgsCiAg ICAgICAgICAgICAgICAgICAgICAgICAgIHhjX2h5cGVyY2FsbF9idWZmZXJfdCAqYXJyLCBpbnQg cnVucykKQEAgLTk5NSw2ICsxMDUxLDcgQEAKICAgICB1bnNpZ25lZCBsb25nICp0b19maXggPSBO VUxMOwogCiAgICAgeGNfc2hhZG93X29wX3N0YXRzX3Qgc3RhdHM7CisgICAgc3RydWN0IHJlbXVz X3N0YXRzIHJzdGF0czsKIAogICAgIHVuc2lnbmVkIGxvbmcgbmVlZGVkX3RvX2ZpeCA9IDA7CiAg ICAgdW5zaWduZWQgbG9uZyB0b3RhbF9zZW50ICAgID0gMDsKQEAgLTEwMzYsNiArMTA5MywxMiBA QAogICAgIH0KIAogICAgIG91dGJ1Zl9pbml0KHhjaCwgJm9iX3BhZ2VidWYsIE9VVEJVRl9TSVpF KTsKKyAgICBtZW1zZXQoJnJzdGF0cywgMCwgc2l6ZW9mKHN0cnVjdCByZW11c19zdGF0cykpOyAg ICAKKyAgICBnZXR0aW1lb2ZkYXkoJnJzdGF0cy5zdXNwZW5kVGltZSwgTlVMTCk7CisgICAgZ2V0 dGltZW9mZGF5KCZyc3RhdHMucmVzdW1lVGltZSwgTlVMTCk7CisgICAgZ2V0dGltZW9mZGF5KCZy c3RhdHMuY29tcHJlc3NUaW1lLCBOVUxMKTsKKyAgICBnZXR0aW1lb2ZkYXkoJnJzdGF0cy5tZW1m bHVzaFRpbWUsIE5VTEwpOworICAgIGdldHRpbWVvZmRheSgmcnN0YXRzLmNvbXByZXNzVGltZSwg TlVMTCk7CiAKICAgICAvKiBJZiBubyBleHBsaWNpdCBjb250cm9sIHBhcmFtZXRlcnMgZ2l2ZW4s IHVzZSBkZWZhdWx0cyAqLwogICAgIG1heF9pdGVycyAgPSBtYXhfaXRlcnMgID8gOiBERUZfTUFY X0lURVJTOwpAQCAtMTA3Miw2ICsxMTM1LDcgQEAKIAogICAgIC8qIEdldCB0aGUgc2l6ZSBvZiB0 aGUgUDJNIHRhYmxlICovCiAgICAgZGluZm8tPnAybV9zaXplID0geGNfZG9tYWluX21heGltdW1f Z3Bmbih4Y2gsIGRvbSkgKyAxOworICAgIHJzdGF0cy5wMm1fc2l6ZSA9IGRpbmZvLT5wMm1fc2l6 ZTsKIAogICAgIGlmICggZGluZm8tPnAybV9zaXplID4gflhFTl9ET01DVExfUEZJTkZPX0xUQUJf TUFTSyApCiAgICAgewpAQCAtMTI3Myw5ICsxMzM3LDEwIEBACiAjdW5kZWYgcmF0ZXdyaXRlCiAj ZW5kaWYKICNkZWZpbmUgcmF0ZXdyaXRlKGZkLCBsaXZlLCBidWYsIGxlbikgcmF0ZXdyaXRlX2J1 ZmZlcih4Y2gsIGxhc3RfaXRlciwgb2IsIChmZCksIChsaXZlKSwgKGJ1ZiksIChsZW4pKQotI2Rl ZmluZSB3cmNvbXByZXNzZWQoZmQpIHdyaXRlX2NvbXByZXNzZWQoeGNoLCBjb21wcmVzc19jdHgs IGxhc3RfaXRlciwgb2IsIChmZCkpCisjZGVmaW5lIHdyY29tcHJlc3NlZChmZCkgd3JpdGVfY29t cHJlc3NlZCh4Y2gsIGNvbXByZXNzX2N0eCwgbGFzdF9pdGVyLCBvYiwgKGZkKSwgJihyc3RhdHMu Y29tcHJlc3Npb24pKQogCiAgICAgb2IgPSAmb2JfcGFnZWJ1ZjsgLyogSG9sZHMgcGZuX3R5cGVz LCBwYWdlcy9jb21wcmVzc2VkIHBhZ2VzICovCisgICAgb2JfcGFnZWJ1Zi50b3RhbF9kYXRhX3Nl bnQgPSBvYl90YWlsYnVmLnRvdGFsX2RhdGFfc2VudCA9IDA7CiAgICAgLyogTm93IHdyaXRlIG91 dCBlYWNoIGRhdGEgcGFnZSwgY2Fub25pY2FsaXNpbmcgcGFnZSB0YWJsZXMgYXMgd2UgZ28uLi4g Ki8KICAgICBmb3IgKCA7IDsgKQogICAgIHsKQEAgLTEyOTEsNiArMTM1Niw4IEBACiAgICAgICAg IGl0ZXIrKzsKICAgICAgICAgc2VudF90aGlzX2l0ZXIgPSAwOwogICAgICAgICBza2lwX3RoaXNf aXRlciA9IDA7CisgICAgICAgIHJzdGF0cy5jb21wcmVzc2lvbiA9IDA7CisgICAgICAgIHJzdGF0 cy5pdGVyX25vdyA9IGl0ZXI7CiAgICAgICAgIE4gPSAwOwogCiAgICAgICAgIHdoaWxlICggTiA8 IGRpbmZvLT5wMm1fc2l6ZSApCkBAIC0xNjUzLDggKzE3MjAsOSBAQAogICAgICAgICB4Y19yZXBv cnRfcHJvZ3Jlc3Nfc3RlcCh4Y2gsIGRpbmZvLT5wMm1fc2l6ZSwgZGluZm8tPnAybV9zaXplKTsK IAogICAgICAgICB0b3RhbF9zZW50ICs9IHNlbnRfdGhpc19pdGVyOworICAgICAgICByc3RhdHMu aXRlcl9zZW50ID0gc2VudF90aGlzX2l0ZXI7CiAKLSAgICAgICAgaWYgKCBsYXN0X2l0ZXIgKQor ICAgICAgICBpZiAoIDAgKQogICAgICAgICB7CiAgICAgICAgICAgICBwcmludF9zdGF0cyggeGNo LCBkb20sIHNlbnRfdGhpc19pdGVyLCAmc3RhdHMsIDEpOwogCkBAIC0xNjkyLDEzICsxNzYwLDE2 IEBACiAgICAgICAgICAgICB7CiAgICAgICAgICAgICAgICAgRFBSSU5URigiU3RhcnQgbGFzdCBp dGVyYXRpb25cbiIpOwogICAgICAgICAgICAgICAgIGxhc3RfaXRlciA9IDE7CisgICAgICAgICAg ICAgICAgcnN0YXRzLml0ZXJfc3RhcnQgPSBpdGVyOwogCisgICAgICAgICAgICAgICAgZ2V0dGlt ZW9mZGF5KCZyc3RhdHMuc3VzcGVuZENhbGwsIE5VTEwpOwogICAgICAgICAgICAgICAgIGlmICgg c3VzcGVuZF9hbmRfc3RhdGUoY2FsbGJhY2tzLT5zdXNwZW5kLCBjYWxsYmFja3MtPmRhdGEsCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB4Y2gsIGlvX2ZkLCBkb20sICZp bmZvKSApCiAgICAgICAgICAgICAgICAgewogICAgICAgICAgICAgICAgICAgICBFUlJPUigiRG9t YWluIGFwcGVhcnMgbm90IHRvIGhhdmUgc3VzcGVuZGVkIik7CiAgICAgICAgICAgICAgICAgICAg IGdvdG8gb3V0OwogICAgICAgICAgICAgICAgIH0KKyAgICAgICAgICAgICAgICBnZXR0aW1lb2Zk YXkoJnJzdGF0cy5zdXNwZW5kVGltZSwgTlVMTCk7CiAKICAgICAgICAgICAgICAgICBEUFJJTlRG KCJTVVNQRU5EIHNoaW5mbyAlMDhseFxuIiwgaW5mby5zaGFyZWRfaW5mb19mcmFtZSk7CiAgICAg ICAgICAgICAgICAgaWYgKCAodG1lbV9zYXZlZCA+IDApICYmCkBAIC0xNzI1LDE0ICsxNzk2LDE1 IEBACiAgICAgICAgICAgICAgICAgZ290byBvdXQ7CiAgICAgICAgICAgICB9CiAKKyAgICAgICAg ICAgIGdldHRpbWVvZmRheSgmcnN0YXRzLnNoYWRvd0NhbGwsIE5VTEwpOwogICAgICAgICAgICAg c2VudF9sYXN0X2l0ZXIgPSBzZW50X3RoaXNfaXRlcjsKIAotICAgICAgICAgICAgcHJpbnRfc3Rh dHMoeGNoLCBkb20sIHNlbnRfdGhpc19pdGVyLCAmc3RhdHMsIDEpOworICAgICAgICAgICAgLyog cHJpbnRfc3RhdHMoeGNoLCBkb20sIHNlbnRfdGhpc19pdGVyLCAmc3RhdHMsIDEpOyAqLwogCiAg ICAgICAgIH0KICAgICB9IC8qIGVuZCBvZiBpbmZpbml0ZSBmb3IgbG9vcCAqLwogCi0gICAgRFBS SU5URigiQWxsIG1lbW9yeSBpcyBzYXZlZFxuIik7CisgICAgLyogRFBSSU5URigiQWxsIG1lbW9y eSBpcyBzYXZlZFxuIik7ICovCiAKICAgICAvKiBBZnRlciBsYXN0X2l0ZXIsIGJ1ZmZlciB0aGUg cmVzdCBvZiBwYWdlYnVmICYgdGFpbGJ1ZiBkYXRhIGludG8gYQogICAgICAqIHNlcGFyYXRlIG91 dHB1dCBidWZmZXIgYW5kIGZsdXNoIGl0IGFmdGVyIHRoZSBjb21wcmVzc2VkIHBhZ2UgY2h1bmtz LgpAQCAtMjExMiw4ICsyMTg0LDEwIEBACiAgb3V0OgogICAgIGNvbXBsZXRlZCA9IDE7CiAKKyAg ICBnZXR0aW1lb2ZkYXkoJnJzdGF0cy5yZXN1bWVDYWxsLCBOVUxMKTsKICAgICBpZiAoICFyYyAm JiBjYWxsYmFja3MtPnBvc3Rjb3B5ICkKICAgICAgICAgY2FsbGJhY2tzLT5wb3N0Y29weShjYWxs YmFja3MtPmRhdGEpOworICAgIGdldHRpbWVvZmRheSgmcnN0YXRzLnJlc3VtZVRpbWUsIE5VTEwp OwogCiAgICAgLyogZ3Vlc3QgaGFzIGJlZW4gcmVzdW1lZC4gTm93IHdlIGNhbiBjb21wcmVzcyBk YXRhCiAgICAgICogYXQgb3VyIG93biBwYWNlLgpAQCAtMjEzNSw2ICsyMjA5LDcgQEAKICAgICAg ICAgICAgIGdvdG8gb3V0OwogICAgICAgICB9CiAgICAgfQorICAgIGdldHRpbWVvZmRheSgmcnN0 YXRzLmNvbXByZXNzVGltZSwgTlVMTCk7CiAKICAgICAvKiBGbHVzaCBsYXN0IHdyaXRlIGFuZCBk aXNjYXJkIGNhY2hlIGZvciBmaWxlLiAqLwogICAgIGlmICggb3V0YnVmX2ZsdXNoKHhjaCwgb2Is IGlvX2ZkKSA8IDAgKSB7CkBAIC0yMTQzLDI3ICsyMjE4LDM2IEBACiAgICAgfQogCiAgICAgZGlz Y2FyZF9maWxlX2NhY2hlKHhjaCwgaW9fZmQsIDEgLyogZmx1c2ggKi8pOworICAgIGdldHRpbWVv ZmRheSgmcnN0YXRzLm1lbWZsdXNoVGltZSwgTlVMTCk7CiAKICAgICAvKiBFbmFibGUgY29tcHJl c3Npb24gbm93LCBmaW5hbGx5ICovCiAgICAgY29tcHJlc3NpbmcgPSAoZmxhZ3MgJiBYQ0ZMQUdT X0NIRUNLUE9JTlRfQ09NUFJFU1MpOwogCiAgICAgLyogY2hlY2twb2ludF9jYiBjYW4gc3BlbmQg YXJiaXRyYXJpbHkgbG9uZyBpbiBiZXR3ZWVuIHJvdW5kcyAqLwogICAgIGlmICghcmMgJiYgY2Fs bGJhY2tzLT5jaGVja3BvaW50ICYmCi0gICAgICAgIGNhbGxiYWNrcy0+Y2hlY2twb2ludChjYWxs YmFja3MtPmRhdGEpID4gMCkKKyAgICAgICAgKHJzdGF0cy5jb21taXREZWxheSA9IGNhbGxiYWNr cy0+Y2hlY2twb2ludChjYWxsYmFja3MtPmRhdGEpKSA+IDApCiAgICAgewogICAgICAgICAvKiBy ZXNldCBzdGF0cyB0aW1lciAqLwotICAgICAgICBwcmludF9zdGF0cyh4Y2gsIGRvbSwgMCwgJnN0 YXRzLCAwKTsKKyAgICAgICAgLyogcHJpbnRfc3RhdHMoeGNoLCBkb20sIDAsICZzdGF0cywgMCk7 ICovCisgICAgICAgIC8qIHByaW50X3N0YXRzKHhjaCwgZG9tLCAwLCAmdGltZV9zdGF0cywgJnNo YWRvd19zdGF0cywgMCk7ICovCisgICAgICAgIC8qIHN1YnRyYWN0IDEgZnJvbSBjb21taXREZWxh eSBzaW5jZSB0aGUgcHl0aG9uIGNvZGUgYWRkcyAxICovCisgICAgICAgIHJzdGF0cy5jb21taXRE ZWxheSAtPSAxOworICAgICAgICByc3RhdHMudG90YWxfc2VudCArPSBvYl9wYWdlYnVmLnRvdGFs X2RhdGFfc2VudDsKKyAgICAgICAgcnN0YXRzLnRvdGFsX3NlbnQgKz0gb2JfdGFpbGJ1Zi50b3Rh bF9kYXRhX3NlbnQ7CisgICAgICAgIHByaW50X3JlbXVzX3N0YXRzKHhjaCwgJnJzdGF0cyk7CiAK ICAgICAgICAgcmMgPSAxOwogICAgICAgICAvKiBsYXN0X2l0ZXIgPSAxOyAqLworICAgICAgICBn ZXR0aW1lb2ZkYXkoJnJzdGF0cy5zdXNwZW5kQ2FsbCwgTlVMTCk7CiAgICAgICAgIGlmICggc3Vz cGVuZF9hbmRfc3RhdGUoY2FsbGJhY2tzLT5zdXNwZW5kLCBjYWxsYmFja3MtPmRhdGEsIHhjaCwK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpb19mZCwgZG9tLCAmaW5mbykgKQogICAg ICAgICB7CiAgICAgICAgICAgICBFUlJPUigiRG9tYWluIGFwcGVhcnMgbm90IHRvIGhhdmUgc3Vz cGVuZGVkIik7CiAgICAgICAgICAgICBnb3RvIG91dDsKICAgICAgICAgfQotICAgICAgICBEUFJJ TlRGKCJTVVNQRU5EIHNoaW5mbyAlMDhseFxuIiwgaW5mby5zaGFyZWRfaW5mb19mcmFtZSk7Ci0g ICAgICAgIHByaW50X3N0YXRzKHhjaCwgZG9tLCAwLCAmc3RhdHMsIDEpOworICAgICAgICAvKiBE UFJJTlRGKCJTVVNQRU5EIHNoaW5mbyAlMDhseFxuIiwgaW5mby5zaGFyZWRfaW5mb19mcmFtZSk7 ICovCisgICAgICAgIC8qIHByaW50X3N0YXRzKHhjaCwgZG9tLCAwLCAmc3RhdHMsIDEpOyAqLwor ICAgICAgICBnZXR0aW1lb2ZkYXkoJnJzdGF0cy5zdXNwZW5kVGltZSwgTlVMTCk7CiAKICAgICAg ICAgaWYgKCB4Y19zaGFkb3dfY29udHJvbCh4Y2gsIGRvbSwKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBYRU5fRE9NQ1RMX1NIQURPV19PUF9DTEVBTiwgSFlQRVJDQUxMX0JVRkZFUih0 b19zZW5kKSwKQEAgLTIxNzIsNiArMjI1Niw3IEBACiAgICAgICAgICAgICBQRVJST1IoIkVycm9y IGZsdXNoaW5nIHNoYWRvdyBQVCIpOwogICAgICAgICB9CiAKKyAgICAgICAgZ2V0dGltZW9mZGF5 KCZyc3RhdHMuc2hhZG93Q2FsbCwgTlVMTCk7CiAgICAgICAgIGdvdG8gY29weXBhZ2VzOwogICAg IH0KIApkaWZmIC1yIGE5ZmQ2YzA1ZjQ2OSB0b29scy9weXRob24veGVuL2xvd2xldmVsL2NoZWNr cG9pbnQvY2hlY2twb2ludC5jCi0tLSBhL3Rvb2xzL3B5dGhvbi94ZW4vbG93bGV2ZWwvY2hlY2tw b2ludC9jaGVja3BvaW50LmMJVGh1IE9jdCAxMyAwODo1MzowMyAyMDExIC0wNzAwCisrKyBiL3Rv b2xzL3B5dGhvbi94ZW4vbG93bGV2ZWwvY2hlY2twb2ludC9jaGVja3BvaW50LmMJV2VkIE9jdCAy NiAwOToxOTowMiAyMDExIC0wNzAwCkBAIC0zNDMsNiArMzQzLDcgQEAKICAgQ2hlY2twb2ludE9i amVjdCogc2VsZiA9IChDaGVja3BvaW50T2JqZWN0KilkYXRhOwogCiAgIFB5T2JqZWN0KiByZXN1 bHQ7CisgIGxvbmcgY29tbWl0VGltZSA9IDE7CiAKICAgaWYgKGNoZWNrcG9pbnRfcG9zdGZsdXNo KCZzZWxmLT5jcHMpIDwgMCkgewogICAgICAgZnByaW50ZihzdGRlcnIsICIlc1xuIiwgY2hlY2tw b2ludF9lcnJvcigmc2VsZi0+Y3BzKSk7CkBAIC0zNTksMTIgKzM2MCwxMCBAQAogICBpZiAoIXJl c3VsdCkKICAgICByZXR1cm4gMDsKIAotICBpZiAocmVzdWx0ID09IFB5X05vbmUgfHwgUHlPYmpl Y3RfSXNUcnVlKHJlc3VsdCkpIHsKLSAgICBQeV9ERUNSRUYocmVzdWx0KTsKLSAgICByZXR1cm4g MTsKLSAgfQorICBpZiAocmVzdWx0ICE9IFB5X05vbmUpCisgICAgY29tbWl0VGltZSA9IFB5SW50 X0FTX0xPTkcocmVzdWx0KTsKIAogICBQeV9ERUNSRUYocmVzdWx0KTsKIAotICByZXR1cm4gMDsK KyAgcmV0dXJuIChpbnQpY29tbWl0VGltZTsKIH0KZGlmZiAtciBhOWZkNmMwNWY0NjkgdG9vbHMv cHl0aG9uL3hlbi9sb3dsZXZlbC9jaGVja3BvaW50L2xpYmNoZWNrcG9pbnQuYwotLS0gYS90b29s cy9weXRob24veGVuL2xvd2xldmVsL2NoZWNrcG9pbnQvbGliY2hlY2twb2ludC5jCVRodSBPY3Qg MTMgMDg6NTM6MDMgMjAxMSAtMDcwMAorKysgYi90b29scy9weXRob24veGVuL2xvd2xldmVsL2No ZWNrcG9pbnQvbGliY2hlY2twb2ludC5jCVdlZCBPY3QgMjYgMDk6MTk6MDIgMjAxMSAtMDcwMApA QCAtMjA1LDEzICsyMDUsOCBAQAogLyogc3VzcGVuZCB0aGUgZG9tYWluLiBSZXR1cm5zIDAgb24g ZmFpbHVyZSwgMSBvbiBzdWNjZXNzICovCiBpbnQgY2hlY2twb2ludF9zdXNwZW5kKGNoZWNrcG9p bnRfc3RhdGUqIHMpCiB7Ci0gIHN0cnVjdCB0aW1ldmFsIHR2OwogICBpbnQgcmM7CiAKLSAgZ2V0 dGltZW9mZGF5KCZ0diwgTlVMTCk7Ci0gIGZwcmludGYoc3RkZXJyLCAiUFJPRjogc3VzcGVuZGlu ZyBhdCAlbHUuJTA2bHVcbiIsICh1bnNpZ25lZCBsb25nKXR2LnR2X3NlYywKLSAgICAgICAgICh1 bnNpZ25lZCBsb25nKXR2LnR2X3VzZWMpOwotCiAgIGlmIChzLT5zdXNwZW5kX2V2dGNobiA+PSAw KQogICAgICAgcmMgPSBldnRjaG5fc3VzcGVuZChzKTsKICAgZWxzZSBpZiAocy0+ZG9tdHlwZSA9 PSBkdF9odm0pCkBAIC0yNTQsNyArMjQ5LDYgQEAKIC8qIGxldCBndWVzdCBleGVjdXRpb24gcmVz dW1lICovCiBpbnQgY2hlY2twb2ludF9yZXN1bWUoY2hlY2twb2ludF9zdGF0ZSogcykKIHsKLSAg c3RydWN0IHRpbWV2YWwgdHY7CiAgIGludCByYzsKIAogICBpZiAoeGNfZG9tYWluX3Jlc3VtZShz LT54Y2gsIHMtPmRvbWlkLCAxKSkgewpAQCAtMjY0LDEwICsyNTgsNiBAQAogICAgIHJldHVybiAt MTsKICAgfQogCi0gIGdldHRpbWVvZmRheSgmdHYsIE5VTEwpOwotICBmcHJpbnRmKHN0ZGVyciwg IlBST0Y6IHJlc3VtZWQgYXQgJWx1LiUwNmx1XG4iLCAodW5zaWduZWQgbG9uZyl0di50dl9zZWMs Ci0gICAgICAgICAodW5zaWduZWQgbG9uZyl0di50dl91c2VjKTsKLQogICBpZiAocy0+ZG9tdHlw ZSA+IGR0X3B2ICYmIHJlc3VtZV9xZW11KHMpIDwgMCkKICAgICAgIHJldHVybiAtMTsKIApAQCAt NTgwLDEzICs1NzAsMTMgQEAKIHsKICAgICBpbnQgcmMgPSAtMTsKIAotICAgIGZwcmludGYoc3Rk ZXJyLCAiaXNzdWluZyBIVk0gc3VzcGVuZCBoeXBlcmNhbGxcbiIpOworICAgIC8qIGZwcmludGYo c3RkZXJyLCAiaXNzdWluZyBIVk0gc3VzcGVuZCBoeXBlcmNhbGxcbiIpOyAqLwogICAgIHJjID0g eGNfZG9tYWluX3NodXRkb3duKHMtPnhjaCwgcy0+ZG9taWQsIFNIVVRET1dOX3N1c3BlbmQpOwog ICAgIGlmIChyYyA8IDApIHsKICAgICAgICBzLT5lcnJzdHIgPSAic2h1dGRvd24gaHlwZXJjYWxs IGZhaWxlZCI7CiAgICAgICAgcmV0dXJuIC0xOwogICAgIH0KLSAgICBmcHJpbnRmKHN0ZGVyciwg InN1c3BlbmQgaHlwZXJjYWxsIHJldHVybmVkICVkXG4iLCByYyk7CisgICAgLyogZnByaW50Zihz dGRlcnIsICJzdXNwZW5kIGh5cGVyY2FsbCByZXR1cm5lZCAlZFxuIiwgcmMpOyAqLwogCiAgICAg aWYgKGNoZWNrX3NodXRkb3duKHMpICE9IDEpCiAgICAgICAgcmV0dXJuIC0xOwpAQCAtNjAwLDcg KzU5MCw3IEBACiB7CiAgICAgY2hhciBwYXRoWzEyOF07CiAKLSAgICBmcHJpbnRmKHN0ZGVyciwg InBhdXNpbmcgUUVNVVxuIik7CisgICAgLyogZnByaW50ZihzdGRlcnIsICJwYXVzaW5nIFFFTVVc biIpOyAqLwogCiAgICAgc3ByaW50ZihwYXRoLCAiL2xvY2FsL2RvbWFpbi8wL2RldmljZS1tb2Rl bC8lZC9jb21tYW5kIiwgcy0+ZG9taWQpOwogICAgIGlmICgheHNfd3JpdGUocy0+eHNoLCBYQlRf TlVMTCwgcGF0aCwgInNhdmUiLCA0KSkgewpAQCAtNjM1LDcgKzYyNSw3IEBACiBzdGF0aWMgaW50 IHJlc3VtZV9xZW11KGNoZWNrcG9pbnRfc3RhdGUgKnMpCiB7CiAgICAgY2hhciBwYXRoWzEyOF07 Ci0gICAgZnByaW50ZihzdGRlcnIsICJyZXN1bWluZyBRRU1VXG4iKTsKKyAgICAvKiBmcHJpbnRm KHN0ZGVyciwgInJlc3VtaW5nIFFFTVVcbiIpOyAqLwogCiAgICAgc3ByaW50ZihwYXRoLCAiL2xv Y2FsL2RvbWFpbi8wL2RldmljZS1tb2RlbC8lZC9jb21tYW5kIiwgcy0+ZG9taWQpOwogICAgIGlm ICgheHNfd3JpdGUocy0+eHNoLCBYQlRfTlVMTCwgcGF0aCwgImNvbnRpbnVlIiwgOCkpIHsKZGlm ZiAtciBhOWZkNmMwNWY0NjkgdG9vbHMvcmVtdXMvcmVtdXMKLS0tIGEvdG9vbHMvcmVtdXMvcmVt dXMJVGh1IE9jdCAxMyAwODo1MzowMyAyMDExIC0wNzAwCisrKyBiL3Rvb2xzL3JlbXVzL3JlbXVz CVdlZCBPY3QgMjYgMDk6MTk6MDIgMjAxMSAtMDcwMApAQCAtNzgsNiArNzgsNyBAQAogZGVmIHJ1 bihjZmcpOgogICAgIGNsb3N1cmUgPSBsYW1iZGE6IE5vbmUKICAgICBjbG9zdXJlLmNtZCA9IE5v bmUKKyAgICBjbG9zdXJlLmVwb2NoID0gMAogCiAgICAgZGVmIHNpZ2V4Y2VwdGlvbihzaWdubywg ZnJhbWUpOgogICAgICAgICByYWlzZSBTaWduYWxFeGNlcHRpb24oc2lnbm8pCkBAIC0xNDIsNiAr MTQzLDcgQEAKICAgICAgICAgaWYgbm90IGNmZy50aW1lcjoKICAgICAgICAgICAgICMgd2hlbiBu b3QgdXNpbmcgYSB0aW1lciB0aHJlYWQsIHNsZWVwIHVudGlsIG5vdyArIGludGVydmFsCiAgICAg ICAgICAgICBjbG9zdXJlLnN0YXJ0dGltZSA9IHRpbWUudGltZSgpCisgICAgICAgICAgICBjbG9z dXJlLmVwb2NoID0gY2xvc3VyZS5lcG9jaCArIDEKIAogICAgICAgICBpZiBjbG9zdXJlLmNtZCA9 PSAncyc6CiAgICAgICAgICAgICBkaWUoKQpAQCAtMTY4LDEwICsxNzAsMTEgQEAKICAgICAgICAg aWYgY2xvc3VyZS5jbWQgPT0gJ2MnOgogICAgICAgICAgICAgZGllKCkKIAotICAgICAgICBwcmlu dCA+PiBzeXMuc3RkZXJyLCAiUFJPRjogZmx1c2hlZCBtZW1vcnkgYXQgJTAuNmYiICUgKHRpbWUu dGltZSgpKQotCisgICAgICAgICMgcHJpbnQgPj4gc3lzLnN0ZGVyciwgIlBST0Y6IGZsdXNoZWQg bWVtb3J5IGF0ICUwLjZmIiAlICh0aW1lLnRpbWUoKSkKKyAgICAgICAgdG1wdGltZSA9IHRpbWUu dGltZSgpCiAgICAgICAgIGZvciBidWYgaW4gYnVmczoKICAgICAgICAgICAgIGJ1Zi5jb21taXQo KQorICAgICAgICBlbmR0aW1lID0gdGltZS50aW1lKCkKIAogICAgICAgICBpZiBjbG9zdXJlLmNt ZCA9PSAnYzInOgogICAgICAgICAgICAgZGllKCkKQEAgLTE4MSwxNCArMTg0LDEzIEBACiAgICAg ICAgICMgZ2V0Y29tbWFuZCgpCiAKICAgICAgICAgaWYgbm90IGNmZy50aW1lcjoKLSAgICAgICAg ICAgIGVuZHRpbWUgPSB0aW1lLnRpbWUoKQogICAgICAgICAgICAgZWxhcHNlZCA9IChlbmR0aW1l IC0gY2xvc3VyZS5zdGFydHRpbWUpICogMTAwMAogCiAgICAgICAgICAgICBpZiBlbGFwc2VkIDwg Y2ZnLmludGVydmFsOgogICAgICAgICAgICAgICAgIHRpbWUuc2xlZXAoKGNmZy5pbnRlcnZhbCAt IGVsYXBzZWQpIC8gMTAwMC4wKQogCi0gICAgICAgICMgRmFsc2UgZW5kcyBjaGVja3BvaW50aW5n Ci0gICAgICAgIHJldHVybiBUcnVlCisgICAgICAgICMgMCBlbmRzIGNoZWNrcG9pbnRpbmcKKyAg ICAgICAgcmV0dXJuIGludCgoKGVuZHRpbWUgLSB0bXB0aW1lKSAqIDEwMDApICsgMSkKIAogICAg IGlmIGNmZy50aW1lcjoKICAgICAgICAgaW50ZXJ2YWwgPSBjZmcuaW50ZXJ2YWwKZGlmZiAtciBh OWZkNmMwNWY0NjkgeGVuL2NvbW1vbi9odm0vc2F2ZS5jCi0tLSBhL3hlbi9jb21tb24vaHZtL3Nh dmUuYwlUaHUgT2N0IDEzIDA4OjUzOjAzIDIwMTEgLTA3MDAKKysrIGIveGVuL2NvbW1vbi9odm0v c2F2ZS5jCVdlZCBPY3QgMjYgMDk6MTk6MDIgMjAxMSAtMDcwMApAQCAtMTU5LDcgKzE1OSw3IEBA CiAgICAgICAgIGhhbmRsZXIgPSBodm1fc3JfaGFuZGxlcnNbaV0uc2F2ZTsKICAgICAgICAgaWYg KCBoYW5kbGVyICE9IE5VTEwgKSAKICAgICAgICAgewotICAgICAgICAgICAgZ2RwcmludGsoWEVO TE9HX0lORk8sICJIVk0gc2F2ZTogJXNcbiIsICBodm1fc3JfaGFuZGxlcnNbaV0ubmFtZSk7Cisg ICAgICAgICAgICAvL2dkcHJpbnRrKFhFTkxPR19JTkZPLCAiSFZNIHNhdmU6ICVzXG4iLCAgaHZt X3NyX2hhbmRsZXJzW2ldLm5hbWUpOwogICAgICAgICAgICAgaWYgKCBoYW5kbGVyKGQsIGgpICE9 IDAgKSAKICAgICAgICAgICAgIHsKICAgICAgICAgICAgICAgICBnZHByaW50ayhYRU5MT0dfRVJS LCAK --20cf3068469f24eb5604cb535631 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --20cf3068469f24eb5604cb535631-- From xen-devel-bounces@lists.xen.org Fri Oct 05 18:01:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 18:01:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCDP-0002Q8-SR; Fri, 05 Oct 2012 18:01:35 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCDO-0002Pb-TR for xen-devel@lists.xen.org; Fri, 05 Oct 2012 18:01:35 +0000 Received: from [85.158.139.83:49489] by server-1.bemta-5.messagelabs.com id 2D/C9-09825-D702F605; Fri, 05 Oct 2012 18:01:33 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-10.tower-182.messagelabs.com!1349460091!33900991!1 X-Originating-IP: [128.244.251.37] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20058 invoked from network); 5 Oct 2012 18:01:32 -0000 Received: from piper.jhuapl.edu (HELO jhuapl.edu) (128.244.251.37) by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 18:01:32 -0000 Received: from ([128.244.207.97]) by piper.jhuapl.edu with ESMTP with TLS id 5Y8HCH1.146215564; Fri, 05 Oct 2012 14:01:02 -0400 From: Matthew Fioravante To: xen-devel@lists.xen.org, ian.campbell@citrix.com, samuel.thibault@ens-lyons.org Date: Fri, 5 Oct 2012 14:01:14 -0400 Message-Id: <1349460077-13770-5-git-send-email-matthew.fioravante@jhuapl.edu> X-Mailer: git-send-email 1.7.4.4 In-Reply-To: <1349460077-13770-1-git-send-email-matthew.fioravante@jhuapl.edu> References: <1349460077-13770-1-git-send-email-matthew.fioravante@jhuapl.edu> Cc: Matthew Fioravante Subject: [Xen-devel] [PATCH vtpm v2 05/12] add CONFIG_XC conditional X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch adds a CONFIG_XC option to mini-os, to allow conditional support for libxc for mini-os domains. Signed-off-by: Matthew Fioravante Acked-by: Samuel Thibault diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile index c425f76..2422db3 100644 --- a/extras/mini-os/Makefile +++ b/extras/mini-os/Makefile @@ -27,6 +27,7 @@ CONFIG_FBFRONT ?= y CONFIG_KBDFRONT ?= y CONFIG_CONSFRONT ?= y CONFIG_XENBUS ?= y +CONFIG_XC ?=y CONFIG_LWIP ?= $(lwip) # Export config items as compiler directives @@ -144,7 +145,9 @@ endif OBJS := $(filter-out $(OBJ_DIR)/lwip%.o $(LWO), $(OBJS)) ifeq ($(libc),y) +ifeq ($(CONFIG_XC),y) APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libxc-$(XEN_TARGET_ARCH) -whole-archive -lxenguest -lxenctrl -no-whole-archive +endif APP_LDLIBS += -lpci APP_LDLIBS += -lz APP_LDLIBS += -lm diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c index 7ddbbf8..6cb97b1 100644 --- a/extras/mini-os/lib/sys.c +++ b/extras/mini-os/lib/sys.c @@ -397,6 +397,7 @@ int close(int fd) return res; } #endif +#ifdef CONFIG_XC case FTYPE_XC: minios_interface_close_fd(fd); return 0; @@ -406,6 +407,7 @@ int close(int fd) case FTYPE_GNTMAP: minios_gnttab_close_fd(fd); return 0; +#endif #ifdef CONFIG_NETFRONT case FTYPE_TAP: shutdown_netfront(files[fd].tap.dev); @@ -1195,10 +1197,13 @@ void *mmap(void *start, size_t length, int prot, int flags, int fd, off_t offset if (fd == -1) return map_zero(n, 1); +#ifdef CONFIG_XC else if (files[fd].type == FTYPE_XC) { unsigned long zero = 0; return map_frames_ex(&zero, n, 0, 0, 1, DOMID_SELF, NULL, 0); - } else if (files[fd].type == FTYPE_MEM) { + } +#endif + else if (files[fd].type == FTYPE_MEM) { unsigned long first_mfn = offset >> PAGE_SHIFT; return map_frames_ex(&first_mfn, n, 0, 1, 1, DOMID_IO, NULL, _PAGE_PRESENT|_PAGE_RW); } else ASSERT(0); -- 1.7.4.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 18:01:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 18:01:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCDP-0002Q8-SR; Fri, 05 Oct 2012 18:01:35 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCDO-0002Pb-TR for xen-devel@lists.xen.org; Fri, 05 Oct 2012 18:01:35 +0000 Received: from [85.158.139.83:49489] by server-1.bemta-5.messagelabs.com id 2D/C9-09825-D702F605; Fri, 05 Oct 2012 18:01:33 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-10.tower-182.messagelabs.com!1349460091!33900991!1 X-Originating-IP: [128.244.251.37] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20058 invoked from network); 5 Oct 2012 18:01:32 -0000 Received: from piper.jhuapl.edu (HELO jhuapl.edu) (128.244.251.37) by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 18:01:32 -0000 Received: from ([128.244.207.97]) by piper.jhuapl.edu with ESMTP with TLS id 5Y8HCH1.146215564; Fri, 05 Oct 2012 14:01:02 -0400 From: Matthew Fioravante To: xen-devel@lists.xen.org, ian.campbell@citrix.com, samuel.thibault@ens-lyons.org Date: Fri, 5 Oct 2012 14:01:14 -0400 Message-Id: <1349460077-13770-5-git-send-email-matthew.fioravante@jhuapl.edu> X-Mailer: git-send-email 1.7.4.4 In-Reply-To: <1349460077-13770-1-git-send-email-matthew.fioravante@jhuapl.edu> References: <1349460077-13770-1-git-send-email-matthew.fioravante@jhuapl.edu> Cc: Matthew Fioravante Subject: [Xen-devel] [PATCH vtpm v2 05/12] add CONFIG_XC conditional X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch adds a CONFIG_XC option to mini-os, to allow conditional support for libxc for mini-os domains. Signed-off-by: Matthew Fioravante Acked-by: Samuel Thibault diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile index c425f76..2422db3 100644 --- a/extras/mini-os/Makefile +++ b/extras/mini-os/Makefile @@ -27,6 +27,7 @@ CONFIG_FBFRONT ?= y CONFIG_KBDFRONT ?= y CONFIG_CONSFRONT ?= y CONFIG_XENBUS ?= y +CONFIG_XC ?=y CONFIG_LWIP ?= $(lwip) # Export config items as compiler directives @@ -144,7 +145,9 @@ endif OBJS := $(filter-out $(OBJ_DIR)/lwip%.o $(LWO), $(OBJS)) ifeq ($(libc),y) +ifeq ($(CONFIG_XC),y) APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libxc-$(XEN_TARGET_ARCH) -whole-archive -lxenguest -lxenctrl -no-whole-archive +endif APP_LDLIBS += -lpci APP_LDLIBS += -lz APP_LDLIBS += -lm diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c index 7ddbbf8..6cb97b1 100644 --- a/extras/mini-os/lib/sys.c +++ b/extras/mini-os/lib/sys.c @@ -397,6 +397,7 @@ int close(int fd) return res; } #endif +#ifdef CONFIG_XC case FTYPE_XC: minios_interface_close_fd(fd); return 0; @@ -406,6 +407,7 @@ int close(int fd) case FTYPE_GNTMAP: minios_gnttab_close_fd(fd); return 0; +#endif #ifdef CONFIG_NETFRONT case FTYPE_TAP: shutdown_netfront(files[fd].tap.dev); @@ -1195,10 +1197,13 @@ void *mmap(void *start, size_t length, int prot, int flags, int fd, off_t offset if (fd == -1) return map_zero(n, 1); +#ifdef CONFIG_XC else if (files[fd].type == FTYPE_XC) { unsigned long zero = 0; return map_frames_ex(&zero, n, 0, 0, 1, DOMID_SELF, NULL, 0); - } else if (files[fd].type == FTYPE_MEM) { + } +#endif + else if (files[fd].type == FTYPE_MEM) { unsigned long first_mfn = offset >> PAGE_SHIFT; return map_frames_ex(&first_mfn, n, 0, 1, 1, DOMID_IO, NULL, _PAGE_PRESENT|_PAGE_RW); } else ASSERT(0); -- 1.7.4.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 18:01:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 18:01:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCDN-0002PL-UP; Fri, 05 Oct 2012 18:01:33 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCDL-0002PG-WF for xen-devel@lists.xen.org; Fri, 05 Oct 2012 18:01:32 +0000 Received: from [85.158.143.99:13138] by server-2.bemta-4.messagelabs.com id 97/98-06610-B702F605; Fri, 05 Oct 2012 18:01:31 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-11.tower-216.messagelabs.com!1349460089!25514646!1 X-Originating-IP: [128.244.251.37] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28560 invoked from network); 5 Oct 2012 18:01:30 -0000 Received: from piper.jhuapl.edu (HELO jhuapl.edu) (128.244.251.37) by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 18:01:30 -0000 Received: from ([128.244.207.97]) by piper.jhuapl.edu with ESMTP with TLS id 5Y8HCH1.146215538; Fri, 05 Oct 2012 14:01:02 -0400 From: Matthew Fioravante To: xen-devel@lists.xen.org, ian.campbell@citrix.com, samuel.thibault@ens-lyons.org Date: Fri, 5 Oct 2012 14:01:10 -0400 Message-Id: <1349460077-13770-1-git-send-email-matthew.fioravante@jhuapl.edu> X-Mailer: git-send-email 1.7.4.4 Cc: Matthew Fioravante Subject: [Xen-devel] [PATCH vtpm v2 01/12] Add ioread/iowrite functions to mini-os X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch adds iowritexx() and ioreadxx() functions for interacting with hardware memory to mini-os. The functions are available in a header iorw.h Signed-off-by: Matthew Fioravante Acked-by: Samuel Thibault Reviewed-by: George Dunlap diff --git a/extras/mini-os/arch/x86/iorw.c b/extras/mini-os/arch/x86/iorw.c new file mode 100644 index 0000000..3080769 --- /dev/null +++ b/extras/mini-os/arch/x86/iorw.c @@ -0,0 +1,35 @@ +#include + +void iowrite8(volatile void* addr, uint8_t val) +{ + *((volatile uint8_t*)addr) = val; +} +void iowrite16(volatile void* addr, uint16_t val) +{ + *((volatile uint16_t*)addr) = val; +} +void iowrite32(volatile void* addr, uint32_t val) +{ + *((volatile uint32_t*)addr) = val; +} +void iowrite64(volatile void* addr, uint64_t val) +{ + *((volatile uint64_t*)addr) = val; +} + +uint8_t ioread8(volatile void* addr) +{ + return *((volatile uint8_t*) addr); +} +uint16_t ioread16(volatile void* addr) +{ + return *((volatile uint16_t*) addr); +} +uint32_t ioread32(volatile void* addr) +{ + return *((volatile uint32_t*) addr); +} +uint64_t ioread64(volatile void* addr) +{ + return *((volatile uint64_t*) addr); +} diff --git a/extras/mini-os/include/iorw.h b/extras/mini-os/include/iorw.h new file mode 100644 index 0000000..d5ec065 --- /dev/null +++ b/extras/mini-os/include/iorw.h @@ -0,0 +1,16 @@ +#ifndef MINIOS_IORW_H +#define MINIOS_IORW_H + +#include + +void iowrite8(volatile void* addr, uint8_t val); +void iowrite16(volatile void* addr, uint16_t val); +void iowrite32(volatile void* addr, uint32_t val); +void iowrite64(volatile void* addr, uint64_t val); + +uint8_t ioread8(volatile void* addr); +uint16_t ioread16(volatile void* addr); +uint32_t ioread32(volatile void* addr); +uint64_t ioread64(volatile void* addr); + +#endif -- 1.7.4.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 18:01:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 18:01:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCDN-0002PL-UP; Fri, 05 Oct 2012 18:01:33 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCDL-0002PG-WF for xen-devel@lists.xen.org; Fri, 05 Oct 2012 18:01:32 +0000 Received: from [85.158.143.99:13138] by server-2.bemta-4.messagelabs.com id 97/98-06610-B702F605; Fri, 05 Oct 2012 18:01:31 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-11.tower-216.messagelabs.com!1349460089!25514646!1 X-Originating-IP: [128.244.251.37] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28560 invoked from network); 5 Oct 2012 18:01:30 -0000 Received: from piper.jhuapl.edu (HELO jhuapl.edu) (128.244.251.37) by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 18:01:30 -0000 Received: from ([128.244.207.97]) by piper.jhuapl.edu with ESMTP with TLS id 5Y8HCH1.146215538; Fri, 05 Oct 2012 14:01:02 -0400 From: Matthew Fioravante To: xen-devel@lists.xen.org, ian.campbell@citrix.com, samuel.thibault@ens-lyons.org Date: Fri, 5 Oct 2012 14:01:10 -0400 Message-Id: <1349460077-13770-1-git-send-email-matthew.fioravante@jhuapl.edu> X-Mailer: git-send-email 1.7.4.4 Cc: Matthew Fioravante Subject: [Xen-devel] [PATCH vtpm v2 01/12] Add ioread/iowrite functions to mini-os X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch adds iowritexx() and ioreadxx() functions for interacting with hardware memory to mini-os. The functions are available in a header iorw.h Signed-off-by: Matthew Fioravante Acked-by: Samuel Thibault Reviewed-by: George Dunlap diff --git a/extras/mini-os/arch/x86/iorw.c b/extras/mini-os/arch/x86/iorw.c new file mode 100644 index 0000000..3080769 --- /dev/null +++ b/extras/mini-os/arch/x86/iorw.c @@ -0,0 +1,35 @@ +#include + +void iowrite8(volatile void* addr, uint8_t val) +{ + *((volatile uint8_t*)addr) = val; +} +void iowrite16(volatile void* addr, uint16_t val) +{ + *((volatile uint16_t*)addr) = val; +} +void iowrite32(volatile void* addr, uint32_t val) +{ + *((volatile uint32_t*)addr) = val; +} +void iowrite64(volatile void* addr, uint64_t val) +{ + *((volatile uint64_t*)addr) = val; +} + +uint8_t ioread8(volatile void* addr) +{ + return *((volatile uint8_t*) addr); +} +uint16_t ioread16(volatile void* addr) +{ + return *((volatile uint16_t*) addr); +} +uint32_t ioread32(volatile void* addr) +{ + return *((volatile uint32_t*) addr); +} +uint64_t ioread64(volatile void* addr) +{ + return *((volatile uint64_t*) addr); +} diff --git a/extras/mini-os/include/iorw.h b/extras/mini-os/include/iorw.h new file mode 100644 index 0000000..d5ec065 --- /dev/null +++ b/extras/mini-os/include/iorw.h @@ -0,0 +1,16 @@ +#ifndef MINIOS_IORW_H +#define MINIOS_IORW_H + +#include + +void iowrite8(volatile void* addr, uint8_t val); +void iowrite16(volatile void* addr, uint16_t val); +void iowrite32(volatile void* addr, uint32_t val); +void iowrite64(volatile void* addr, uint64_t val); + +uint8_t ioread8(volatile void* addr); +uint16_t ioread16(volatile void* addr); +uint32_t ioread32(volatile void* addr); +uint64_t ioread64(volatile void* addr); + +#endif -- 1.7.4.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 18:01:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 18:01:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCDT-0002RG-5S; Fri, 05 Oct 2012 18:01:39 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCDR-0002Pb-Na for xen-devel@lists.xen.org; Fri, 05 Oct 2012 18:01:37 +0000 Received: from [85.158.139.211:2797] by server-1.bemta-5.messagelabs.com id 89/D9-09825-1802F605; Fri, 05 Oct 2012 18:01:37 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-11.tower-206.messagelabs.com!1349460095!21252190!1 X-Originating-IP: [128.244.251.37] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29866 invoked from network); 5 Oct 2012 18:01:36 -0000 Received: from piper.jhuapl.edu (HELO jhuapl.edu) (128.244.251.37) by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 18:01:36 -0000 Received: from ([128.244.207.97]) by piper.jhuapl.edu with ESMTP with TLS id 5Y8HCH1.146215570; Fri, 05 Oct 2012 14:01:02 -0400 From: Matthew Fioravante To: xen-devel@lists.xen.org, ian.campbell@citrix.com, samuel.thibault@ens-lyons.org Date: Fri, 5 Oct 2012 14:01:15 -0400 Message-Id: <1349460077-13770-6-git-send-email-matthew.fioravante@jhuapl.edu> X-Mailer: git-send-email 1.7.4.4 In-Reply-To: <1349460077-13770-1-git-send-email-matthew.fioravante@jhuapl.edu> References: <1349460077-13770-1-git-send-email-matthew.fioravante@jhuapl.edu> Cc: Matthew Fioravante Subject: [Xen-devel] [PATCH vtpm v2 06/12] add select definition to sys/time.h when HAVE_LIBC is defined X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch adds the select function to sys/time.h when HAVE_LIBC is defined, which is according to standard (see the select() manpage). Signed-off-by: Matthew Fioravante Acked-by: Samuel Thibault diff --git a/extras/mini-os/include/sys/time.h b/extras/mini-os/include/sys/time.h index d6623a4..3be3653 100644 --- a/extras/mini-os/include/sys/time.h +++ b/extras/mini-os/include/sys/time.h @@ -22,6 +22,7 @@ #ifdef HAVE_LIBC #include_next + #else struct timespec { time_t tv_sec; @@ -37,6 +38,10 @@ struct timeval { }; int gettimeofday(struct timeval *tv, void *tz); + +#endif +#ifdef HAVE_LIBC +#include #endif #endif /* _MINIOS_SYS_TIME_H_ */ -- 1.7.4.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 18:01:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 18:01:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCDT-0002RG-5S; Fri, 05 Oct 2012 18:01:39 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCDR-0002Pb-Na for xen-devel@lists.xen.org; Fri, 05 Oct 2012 18:01:37 +0000 Received: from [85.158.139.211:2797] by server-1.bemta-5.messagelabs.com id 89/D9-09825-1802F605; Fri, 05 Oct 2012 18:01:37 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-11.tower-206.messagelabs.com!1349460095!21252190!1 X-Originating-IP: [128.244.251.37] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29866 invoked from network); 5 Oct 2012 18:01:36 -0000 Received: from piper.jhuapl.edu (HELO jhuapl.edu) (128.244.251.37) by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 18:01:36 -0000 Received: from ([128.244.207.97]) by piper.jhuapl.edu with ESMTP with TLS id 5Y8HCH1.146215570; Fri, 05 Oct 2012 14:01:02 -0400 From: Matthew Fioravante To: xen-devel@lists.xen.org, ian.campbell@citrix.com, samuel.thibault@ens-lyons.org Date: Fri, 5 Oct 2012 14:01:15 -0400 Message-Id: <1349460077-13770-6-git-send-email-matthew.fioravante@jhuapl.edu> X-Mailer: git-send-email 1.7.4.4 In-Reply-To: <1349460077-13770-1-git-send-email-matthew.fioravante@jhuapl.edu> References: <1349460077-13770-1-git-send-email-matthew.fioravante@jhuapl.edu> Cc: Matthew Fioravante Subject: [Xen-devel] [PATCH vtpm v2 06/12] add select definition to sys/time.h when HAVE_LIBC is defined X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch adds the select function to sys/time.h when HAVE_LIBC is defined, which is according to standard (see the select() manpage). Signed-off-by: Matthew Fioravante Acked-by: Samuel Thibault diff --git a/extras/mini-os/include/sys/time.h b/extras/mini-os/include/sys/time.h index d6623a4..3be3653 100644 --- a/extras/mini-os/include/sys/time.h +++ b/extras/mini-os/include/sys/time.h @@ -22,6 +22,7 @@ #ifdef HAVE_LIBC #include_next + #else struct timespec { time_t tv_sec; @@ -37,6 +38,10 @@ struct timeval { }; int gettimeofday(struct timeval *tv, void *tz); + +#endif +#ifdef HAVE_LIBC +#include #endif #endif /* _MINIOS_SYS_TIME_H_ */ -- 1.7.4.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 18:01:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 18:01:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCDP-0002Pw-E4; Fri, 05 Oct 2012 18:01:35 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCDO-0002PR-OS for xen-devel@lists.xen.org; Fri, 05 Oct 2012 18:01:34 +0000 Received: from [85.158.138.51:2808] by server-16.bemta-3.messagelabs.com id F6/A2-04167-D702F605; Fri, 05 Oct 2012 18:01:33 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-9.tower-174.messagelabs.com!1349460091!31584847!1 X-Originating-IP: [128.244.251.37] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18751 invoked from network); 5 Oct 2012 18:01:32 -0000 Received: from piper.jhuapl.edu (HELO jhuapl.edu) (128.244.251.37) by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 18:01:32 -0000 Received: from ([128.244.207.97]) by piper.jhuapl.edu with ESMTP with TLS id 5Y8HCH1.146215557; Fri, 05 Oct 2012 14:01:02 -0400 From: Matthew Fioravante To: xen-devel@lists.xen.org, ian.campbell@citrix.com, samuel.thibault@ens-lyons.org Date: Fri, 5 Oct 2012 14:01:13 -0400 Message-Id: <1349460077-13770-4-git-send-email-matthew.fioravante@jhuapl.edu> X-Mailer: git-send-email 1.7.4.4 In-Reply-To: <1349460077-13770-1-git-send-email-matthew.fioravante@jhuapl.edu> References: <1349460077-13770-1-git-send-email-matthew.fioravante@jhuapl.edu> Cc: Matthew Fioravante Subject: [Xen-devel] [PATCH vtpm v2 04/12] Disable the mfn_is_ram() check, it doesn't work correctly on all systems X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch disables the mfn_is_ram check in mini-os. The current check is insufficient and fails on some systems with larger than 4gb memory. Signed-off-by: Matthew Fioravante Acked-by: Samuel Thibault diff --git a/extras/mini-os/arch/x86/ioremap.c b/extras/mini-os/arch/x86/ioremap.c index c7f8186..4384b1c 100644 --- a/extras/mini-os/arch/x86/ioremap.c +++ b/extras/mini-os/arch/x86/ioremap.c @@ -35,7 +35,6 @@ static void *__do_ioremap(unsigned long phys_addr, unsigned long size, unsigned long va; unsigned long mfns, mfn; unsigned long num_pages, offset; - int i; /* allow non page aligned addresses but for mapping we need to align them */ offset = (phys_addr & ~PAGE_MASK); @@ -43,21 +42,9 @@ static void *__do_ioremap(unsigned long phys_addr, unsigned long size, phys_addr &= PAGE_MASK; mfns = mfn = phys_addr >> PAGE_SHIFT; - /* sanity checks on list of MFNs */ - for ( i = 0; i < num_pages; i++, mfn++ ) - { - if ( mfn_is_ram(mfn) ) - { - printk("ioremap: mfn 0x%ulx is RAM\n", mfn); - goto mfn_invalid; - } - } va = (unsigned long)map_frames_ex(&mfns, num_pages, 0, 1, 1, DOMID_IO, NULL, prot); return (void *)(va + offset); - -mfn_invalid: - return NULL; } void *ioremap(unsigned long phys_addr, unsigned long size) diff --git a/extras/mini-os/arch/x86/mm.c b/extras/mini-os/arch/x86/mm.c index 80aceac..35df15b 100644 --- a/extras/mini-os/arch/x86/mm.c +++ b/extras/mini-os/arch/x86/mm.c @@ -845,18 +845,6 @@ unsigned long alloc_contig_pages(int order, unsigned int addr_bits) } /* - * Check if a given MFN refers to real memory - */ -static long system_ram_end_mfn; -int mfn_is_ram(unsigned long mfn) -{ - /* very crude check if a given MFN is memory or not. Probably should - * make this a little more sophisticated ;) */ - return (mfn <= system_ram_end_mfn) ? 1 : 0; -} - - -/* * Clear some of the bootstrap memory */ static void clear_bootstrap(void) @@ -951,10 +939,6 @@ void arch_init_mm(unsigned long* start_pfn_p, unsigned long* max_pfn_p) clear_bootstrap(); set_readonly(&_text, &_erodata); - /* get the number of physical pages the system has. Used to check for - * system memory. */ - system_ram_end_mfn = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL); - *start_pfn_p = start_pfn; *max_pfn_p = max_pfn; } diff --git a/extras/mini-os/include/x86/arch_mm.h b/extras/mini-os/include/x86/arch_mm.h index a95632a..23cfca7 100644 --- a/extras/mini-os/include/x86/arch_mm.h +++ b/extras/mini-os/include/x86/arch_mm.h @@ -229,6 +229,5 @@ static __inline__ paddr_t machine_to_phys(maddr_t machine) #define do_map_zero(start, n) do_map_frames(start, &mfn_zero, n, 0, 0, DOMID_SELF, NULL, L1_PROT_RO) pgentry_t *need_pgt(unsigned long addr); -int mfn_is_ram(unsigned long mfn); #endif /* _ARCH_MM_H_ */ -- 1.7.4.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 18:01:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 18:01:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCDP-0002Pw-E4; Fri, 05 Oct 2012 18:01:35 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCDO-0002PR-OS for xen-devel@lists.xen.org; Fri, 05 Oct 2012 18:01:34 +0000 Received: from [85.158.138.51:2808] by server-16.bemta-3.messagelabs.com id F6/A2-04167-D702F605; Fri, 05 Oct 2012 18:01:33 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-9.tower-174.messagelabs.com!1349460091!31584847!1 X-Originating-IP: [128.244.251.37] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18751 invoked from network); 5 Oct 2012 18:01:32 -0000 Received: from piper.jhuapl.edu (HELO jhuapl.edu) (128.244.251.37) by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 18:01:32 -0000 Received: from ([128.244.207.97]) by piper.jhuapl.edu with ESMTP with TLS id 5Y8HCH1.146215557; Fri, 05 Oct 2012 14:01:02 -0400 From: Matthew Fioravante To: xen-devel@lists.xen.org, ian.campbell@citrix.com, samuel.thibault@ens-lyons.org Date: Fri, 5 Oct 2012 14:01:13 -0400 Message-Id: <1349460077-13770-4-git-send-email-matthew.fioravante@jhuapl.edu> X-Mailer: git-send-email 1.7.4.4 In-Reply-To: <1349460077-13770-1-git-send-email-matthew.fioravante@jhuapl.edu> References: <1349460077-13770-1-git-send-email-matthew.fioravante@jhuapl.edu> Cc: Matthew Fioravante Subject: [Xen-devel] [PATCH vtpm v2 04/12] Disable the mfn_is_ram() check, it doesn't work correctly on all systems X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch disables the mfn_is_ram check in mini-os. The current check is insufficient and fails on some systems with larger than 4gb memory. Signed-off-by: Matthew Fioravante Acked-by: Samuel Thibault diff --git a/extras/mini-os/arch/x86/ioremap.c b/extras/mini-os/arch/x86/ioremap.c index c7f8186..4384b1c 100644 --- a/extras/mini-os/arch/x86/ioremap.c +++ b/extras/mini-os/arch/x86/ioremap.c @@ -35,7 +35,6 @@ static void *__do_ioremap(unsigned long phys_addr, unsigned long size, unsigned long va; unsigned long mfns, mfn; unsigned long num_pages, offset; - int i; /* allow non page aligned addresses but for mapping we need to align them */ offset = (phys_addr & ~PAGE_MASK); @@ -43,21 +42,9 @@ static void *__do_ioremap(unsigned long phys_addr, unsigned long size, phys_addr &= PAGE_MASK; mfns = mfn = phys_addr >> PAGE_SHIFT; - /* sanity checks on list of MFNs */ - for ( i = 0; i < num_pages; i++, mfn++ ) - { - if ( mfn_is_ram(mfn) ) - { - printk("ioremap: mfn 0x%ulx is RAM\n", mfn); - goto mfn_invalid; - } - } va = (unsigned long)map_frames_ex(&mfns, num_pages, 0, 1, 1, DOMID_IO, NULL, prot); return (void *)(va + offset); - -mfn_invalid: - return NULL; } void *ioremap(unsigned long phys_addr, unsigned long size) diff --git a/extras/mini-os/arch/x86/mm.c b/extras/mini-os/arch/x86/mm.c index 80aceac..35df15b 100644 --- a/extras/mini-os/arch/x86/mm.c +++ b/extras/mini-os/arch/x86/mm.c @@ -845,18 +845,6 @@ unsigned long alloc_contig_pages(int order, unsigned int addr_bits) } /* - * Check if a given MFN refers to real memory - */ -static long system_ram_end_mfn; -int mfn_is_ram(unsigned long mfn) -{ - /* very crude check if a given MFN is memory or not. Probably should - * make this a little more sophisticated ;) */ - return (mfn <= system_ram_end_mfn) ? 1 : 0; -} - - -/* * Clear some of the bootstrap memory */ static void clear_bootstrap(void) @@ -951,10 +939,6 @@ void arch_init_mm(unsigned long* start_pfn_p, unsigned long* max_pfn_p) clear_bootstrap(); set_readonly(&_text, &_erodata); - /* get the number of physical pages the system has. Used to check for - * system memory. */ - system_ram_end_mfn = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL); - *start_pfn_p = start_pfn; *max_pfn_p = max_pfn; } diff --git a/extras/mini-os/include/x86/arch_mm.h b/extras/mini-os/include/x86/arch_mm.h index a95632a..23cfca7 100644 --- a/extras/mini-os/include/x86/arch_mm.h +++ b/extras/mini-os/include/x86/arch_mm.h @@ -229,6 +229,5 @@ static __inline__ paddr_t machine_to_phys(maddr_t machine) #define do_map_zero(start, n) do_map_frames(start, &mfn_zero, n, 0, 0, DOMID_SELF, NULL, L1_PROT_RO) pgentry_t *need_pgt(unsigned long addr); -int mfn_is_ram(unsigned long mfn); #endif /* _ARCH_MM_H_ */ -- 1.7.4.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 18:01:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 18:01:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCDQ-0002QG-8Q; Fri, 05 Oct 2012 18:01:36 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCDO-0002Pc-Uw for xen-devel@lists.xen.org; Fri, 05 Oct 2012 18:01:35 +0000 Received: from [85.158.143.35:46588] by server-3.bemta-4.messagelabs.com id D0/66-10986-E702F605; Fri, 05 Oct 2012 18:01:34 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-5.tower-21.messagelabs.com!1349460091!4131303!1 X-Originating-IP: [128.244.251.37] X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD,UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15883 invoked from network); 5 Oct 2012 18:01:32 -0000 Received: from piper.jhuapl.edu (HELO jhuapl.edu) (128.244.251.37) by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 18:01:32 -0000 Received: from ([128.244.207.97]) by piper.jhuapl.edu with ESMTP with TLS id 5Y8HCH1.146215546; Fri, 05 Oct 2012 14:01:02 -0400 From: Matthew Fioravante To: xen-devel@lists.xen.org, ian.campbell@citrix.com, samuel.thibault@ens-lyons.org Date: Fri, 5 Oct 2012 14:01:11 -0400 Message-Id: <1349460077-13770-2-git-send-email-matthew.fioravante@jhuapl.edu> X-Mailer: git-send-email 1.7.4.4 In-Reply-To: <1349460077-13770-1-git-send-email-matthew.fioravante@jhuapl.edu> References: <1349460077-13770-1-git-send-email-matthew.fioravante@jhuapl.edu> Cc: Matthew Fioravante Subject: [Xen-devel] [PATCH vtpm v2 02/12] add posix io for blkfront X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch adds posix io support (read,write,lseek) to block devices using blkfront. Signed-off-by: Matthew Fioravante Acked-by: Samuel Thibault diff --git a/extras/mini-os/blkfront.c b/extras/mini-os/blkfront.c index 74b8b26..a7b42ec 100644 --- a/extras/mini-os/blkfront.c +++ b/extras/mini-os/blkfront.c @@ -392,6 +392,7 @@ void blkfront_aio(struct blkfront_aiocb *aiocbp, int write) static void blkfront_aio_cb(struct blkfront_aiocb *aiocbp, int ret) { aiocbp->data = (void*) 1; + aiocbp->aio_cb = NULL; } void blkfront_io(struct blkfront_aiocb *aiocbp, int write) @@ -547,9 +548,171 @@ moretodo: #ifdef HAVE_LIBC int blkfront_open(struct blkfront_dev *dev) { + /* Silently prevent multiple opens */ + if(dev->fd != -1) { + return dev->fd; + } dev->fd = alloc_fd(FTYPE_BLK); printk("blk_open(%s) -> %d\n", dev->nodename, dev->fd); files[dev->fd].blk.dev = dev; + files[dev->fd].blk.offset = 0; return dev->fd; } + +int blkfront_posix_rwop(int fd, uint8_t* buf, size_t count, int write) +{ + struct blkfront_dev* dev = files[fd].blk.dev; + off_t offset = files[fd].blk.offset; + struct blkfront_aiocb aiocb; + unsigned long long disksize = dev->info.sectors * dev->info.sector_size; + unsigned int blocksize = dev->info.sector_size; + + int blknum; + int blkoff; + size_t bytes; + int rc = 0; + int alignedbuf = 0; + uint8_t* copybuf = NULL; + + /* RW 0 bytes is just a NOP */ + if(count == 0) { + return 0; + } + /* Check for NULL buffer */ + if( buf == NULL ) { + errno = EFAULT; + return -1; + } + + /* Write mode checks */ + if(write) { + /*Make sure we have write permission */ + if(dev->info.info & VDISK_READONLY + || (dev->info.mode != O_RDWR && dev->info.mode != O_WRONLY)) { + errno = EACCES; + return -1; + } + /*Make sure disk is big enough for this write */ + if(offset + count > disksize) { + errno = ENOSPC; + return -1; + } + } + /* Read mode checks */ + else + { + /* Reading past the disk? Just return 0 */ + if(offset >= disksize) { + return 0; + } + + /*If the requested read is bigger than the disk, just + * read as much as we can until the end */ + if(offset + count > disksize) { + count = disksize - offset; + } + } + /* Determine which block to start at and at which offset inside of it */ + blknum = offset / blocksize; + blkoff = offset % blocksize; + + /* Optimization: We need to check if buf is aligned to the sector size. + * This is somewhat tricky code. We have to add the blocksize - block offset + * because the first block may be a partial block and then for every subsequent + * block rw the buffer will be offset.*/ + if(!((uintptr_t) (buf +(blocksize - blkoff)) & (dev->info.sector_size-1))) { + alignedbuf = 1; + } + + /* Setup aiocb block object */ + aiocb.aio_dev = dev; + aiocb.aio_offset = blknum * blocksize; + aiocb.aio_cb = NULL; + aiocb.data = NULL; + + /* If our buffer is unaligned or its aligned but we will need to rw a partial block + * then a copy will have to be done */ + if(!alignedbuf || blkoff != 0 || count % blocksize != 0) { + copybuf = _xmalloc(blocksize, dev->info.sector_size); + } + + rc = count; + while(count > 0) { + /* determine how many bytes to read/write from/to the current block buffer */ + if(!alignedbuf || blkoff != 0 || count < blocksize) { + /* This is the case for unaligned R/W or partial block */ + bytes = count < blocksize - blkoff ? count : blocksize - blkoff; + aiocb.aio_nbytes = blocksize; + } else { + /* For an aligned R/W we can read up to the maximum transfer size */ + bytes = count > (BLKIF_MAX_SEGMENTS_PER_REQUEST-1)*PAGE_SIZE + ? (BLKIF_MAX_SEGMENTS_PER_REQUEST-1)*PAGE_SIZE + : count & ~(blocksize -1); + aiocb.aio_nbytes = bytes; + } + + /* read operation */ + if(!write) { + if (alignedbuf && bytes >= blocksize) { + /* If aligned and were reading a whole block, just read right into buf */ + aiocb.aio_buf = buf; + blkfront_read(&aiocb); + } else { + /* If not then we have to do a copy */ + aiocb.aio_buf = copybuf; + blkfront_read(&aiocb); + memcpy(buf, ©buf[blkoff], bytes); + } + } + /* Write operation */ + else { + if(alignedbuf && bytes >= blocksize) { + /* If aligned and were writing a whole block, just write directly from buf */ + aiocb.aio_buf = buf; + blkfront_write(&aiocb); + } else { + /* If not then we have to do a copy. */ + aiocb.aio_buf = copybuf; + /* If we're writing a partial block, we need to read the current contents first + * so we don't overwrite the extra bits with garbage */ + if(blkoff != 0 || bytes < blocksize) { + blkfront_read(&aiocb); + } + memcpy(©buf[blkoff], buf, bytes); + blkfront_write(&aiocb); + } + } + /* Will start at beginning of all remaining blocks */ + blkoff = 0; + + /* Increment counters and continue */ + count -= bytes; + buf += bytes; + if(bytes < blocksize) { + //At minimum we read one block + aiocb.aio_offset += blocksize; + } else { + //If we read more than a block, was a multiple of blocksize + aiocb.aio_offset += bytes; + } + } + + free(copybuf); + files[fd].blk.offset += rc; + return rc; + +} + +int blkfront_posix_fstat(int fd, struct stat* buf) +{ + struct blkfront_dev* dev = files[fd].blk.dev; + + buf->st_mode = dev->info.mode; + buf->st_uid = 0; + buf->st_gid = 0; + buf->st_size = dev->info.sectors * dev->info.sector_size; + buf->st_atime = buf->st_mtime = buf->st_ctime = time(NULL); + + return 0; +} #endif diff --git a/extras/mini-os/include/blkfront.h b/extras/mini-os/include/blkfront.h index 724137e..3528af9 100644 --- a/extras/mini-os/include/blkfront.h +++ b/extras/mini-os/include/blkfront.h @@ -28,7 +28,17 @@ struct blkfront_info }; struct blkfront_dev *init_blkfront(char *nodename, struct blkfront_info *info); #ifdef HAVE_LIBC +#include +/* POSIX IO functions: + * use blkfront_open() to get a file descriptor to the block device + * Don't use the other blkfront posix functions here directly, instead use + * read(), write(), lseek() and fstat() on the file descriptor + */ int blkfront_open(struct blkfront_dev *dev); +int blkfront_posix_rwop(int fd, uint8_t* buf, size_t count, int write); +#define blkfront_posix_write(fd, buf, count) blkfront_posix_rwop(fd, (uint8_t*)buf, count, 1) +#define blkfront_posix_read(fd, buf, count) blkfront_posix_rwop(fd, (uint8_t*)buf, count, 0) +int blkfront_posix_fstat(int fd, struct stat* buf); #endif void blkfront_aio(struct blkfront_aiocb *aiocbp, int write); #define blkfront_aio_read(aiocbp) blkfront_aio(aiocbp, 0) diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h index 1af2717..d4641b6 100644 --- a/extras/mini-os/include/lib.h +++ b/extras/mini-os/include/lib.h @@ -174,6 +174,7 @@ extern struct file { } tap; struct { struct blkfront_dev *dev; + off_t offset; } blk; struct { struct kbdfront_dev *dev; diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c index a7d35d6..7ddbbf8 100644 --- a/extras/mini-os/lib/sys.c +++ b/extras/mini-os/lib/sys.c @@ -289,6 +289,11 @@ int read(int fd, void *buf, size_t nbytes) return ret * sizeof(union xenfb_in_event); } #endif +#ifdef CONFIG_BLKFRONT + case FTYPE_BLK: { + return blkfront_posix_read(fd, buf, nbytes); + } +#endif default: break; } @@ -321,6 +326,10 @@ int write(int fd, const void *buf, size_t nbytes) netfront_xmit(files[fd].tap.dev, (void*) buf, nbytes); return nbytes; #endif +#ifdef CONFIG_BLKFRONT + case FTYPE_BLK: + return blkfront_posix_write(fd, buf, nbytes); +#endif default: break; } @@ -331,8 +340,37 @@ int write(int fd, const void *buf, size_t nbytes) off_t lseek(int fd, off_t offset, int whence) { - errno = ESPIPE; - return (off_t) -1; + switch(files[fd].type) { +#ifdef CONFIG_BLKFRONT + case FTYPE_BLK: + switch (whence) { + case SEEK_SET: + files[fd].file.offset = offset; + break; + case SEEK_CUR: + files[fd].file.offset += offset; + break; + case SEEK_END: + { + struct stat st; + int ret; + ret = fstat(fd, &st); + if (ret) + return -1; + files[fd].file.offset = st.st_size + offset; + break; + } + default: + errno = EINVAL; + return -1; + } + return files[fd].file.offset; + break; +#endif + default: /* Not implemented on this FTYPE */ + errno = ESPIPE; + return (off_t) -1; + } } int fsync(int fd) { @@ -445,6 +483,10 @@ int fstat(int fd, struct stat *buf) buf->st_ctime = time(NULL); return 0; } +#ifdef CONFIG_BLKFRONT + case FTYPE_BLK: + return blkfront_posix_fstat(fd, buf); +#endif default: break; } -- 1.7.4.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 18:01:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 18:01:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCDQ-0002QG-8Q; Fri, 05 Oct 2012 18:01:36 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCDO-0002Pc-Uw for xen-devel@lists.xen.org; Fri, 05 Oct 2012 18:01:35 +0000 Received: from [85.158.143.35:46588] by server-3.bemta-4.messagelabs.com id D0/66-10986-E702F605; Fri, 05 Oct 2012 18:01:34 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-5.tower-21.messagelabs.com!1349460091!4131303!1 X-Originating-IP: [128.244.251.37] X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD,UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15883 invoked from network); 5 Oct 2012 18:01:32 -0000 Received: from piper.jhuapl.edu (HELO jhuapl.edu) (128.244.251.37) by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 18:01:32 -0000 Received: from ([128.244.207.97]) by piper.jhuapl.edu with ESMTP with TLS id 5Y8HCH1.146215546; Fri, 05 Oct 2012 14:01:02 -0400 From: Matthew Fioravante To: xen-devel@lists.xen.org, ian.campbell@citrix.com, samuel.thibault@ens-lyons.org Date: Fri, 5 Oct 2012 14:01:11 -0400 Message-Id: <1349460077-13770-2-git-send-email-matthew.fioravante@jhuapl.edu> X-Mailer: git-send-email 1.7.4.4 In-Reply-To: <1349460077-13770-1-git-send-email-matthew.fioravante@jhuapl.edu> References: <1349460077-13770-1-git-send-email-matthew.fioravante@jhuapl.edu> Cc: Matthew Fioravante Subject: [Xen-devel] [PATCH vtpm v2 02/12] add posix io for blkfront X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch adds posix io support (read,write,lseek) to block devices using blkfront. Signed-off-by: Matthew Fioravante Acked-by: Samuel Thibault diff --git a/extras/mini-os/blkfront.c b/extras/mini-os/blkfront.c index 74b8b26..a7b42ec 100644 --- a/extras/mini-os/blkfront.c +++ b/extras/mini-os/blkfront.c @@ -392,6 +392,7 @@ void blkfront_aio(struct blkfront_aiocb *aiocbp, int write) static void blkfront_aio_cb(struct blkfront_aiocb *aiocbp, int ret) { aiocbp->data = (void*) 1; + aiocbp->aio_cb = NULL; } void blkfront_io(struct blkfront_aiocb *aiocbp, int write) @@ -547,9 +548,171 @@ moretodo: #ifdef HAVE_LIBC int blkfront_open(struct blkfront_dev *dev) { + /* Silently prevent multiple opens */ + if(dev->fd != -1) { + return dev->fd; + } dev->fd = alloc_fd(FTYPE_BLK); printk("blk_open(%s) -> %d\n", dev->nodename, dev->fd); files[dev->fd].blk.dev = dev; + files[dev->fd].blk.offset = 0; return dev->fd; } + +int blkfront_posix_rwop(int fd, uint8_t* buf, size_t count, int write) +{ + struct blkfront_dev* dev = files[fd].blk.dev; + off_t offset = files[fd].blk.offset; + struct blkfront_aiocb aiocb; + unsigned long long disksize = dev->info.sectors * dev->info.sector_size; + unsigned int blocksize = dev->info.sector_size; + + int blknum; + int blkoff; + size_t bytes; + int rc = 0; + int alignedbuf = 0; + uint8_t* copybuf = NULL; + + /* RW 0 bytes is just a NOP */ + if(count == 0) { + return 0; + } + /* Check for NULL buffer */ + if( buf == NULL ) { + errno = EFAULT; + return -1; + } + + /* Write mode checks */ + if(write) { + /*Make sure we have write permission */ + if(dev->info.info & VDISK_READONLY + || (dev->info.mode != O_RDWR && dev->info.mode != O_WRONLY)) { + errno = EACCES; + return -1; + } + /*Make sure disk is big enough for this write */ + if(offset + count > disksize) { + errno = ENOSPC; + return -1; + } + } + /* Read mode checks */ + else + { + /* Reading past the disk? Just return 0 */ + if(offset >= disksize) { + return 0; + } + + /*If the requested read is bigger than the disk, just + * read as much as we can until the end */ + if(offset + count > disksize) { + count = disksize - offset; + } + } + /* Determine which block to start at and at which offset inside of it */ + blknum = offset / blocksize; + blkoff = offset % blocksize; + + /* Optimization: We need to check if buf is aligned to the sector size. + * This is somewhat tricky code. We have to add the blocksize - block offset + * because the first block may be a partial block and then for every subsequent + * block rw the buffer will be offset.*/ + if(!((uintptr_t) (buf +(blocksize - blkoff)) & (dev->info.sector_size-1))) { + alignedbuf = 1; + } + + /* Setup aiocb block object */ + aiocb.aio_dev = dev; + aiocb.aio_offset = blknum * blocksize; + aiocb.aio_cb = NULL; + aiocb.data = NULL; + + /* If our buffer is unaligned or its aligned but we will need to rw a partial block + * then a copy will have to be done */ + if(!alignedbuf || blkoff != 0 || count % blocksize != 0) { + copybuf = _xmalloc(blocksize, dev->info.sector_size); + } + + rc = count; + while(count > 0) { + /* determine how many bytes to read/write from/to the current block buffer */ + if(!alignedbuf || blkoff != 0 || count < blocksize) { + /* This is the case for unaligned R/W or partial block */ + bytes = count < blocksize - blkoff ? count : blocksize - blkoff; + aiocb.aio_nbytes = blocksize; + } else { + /* For an aligned R/W we can read up to the maximum transfer size */ + bytes = count > (BLKIF_MAX_SEGMENTS_PER_REQUEST-1)*PAGE_SIZE + ? (BLKIF_MAX_SEGMENTS_PER_REQUEST-1)*PAGE_SIZE + : count & ~(blocksize -1); + aiocb.aio_nbytes = bytes; + } + + /* read operation */ + if(!write) { + if (alignedbuf && bytes >= blocksize) { + /* If aligned and were reading a whole block, just read right into buf */ + aiocb.aio_buf = buf; + blkfront_read(&aiocb); + } else { + /* If not then we have to do a copy */ + aiocb.aio_buf = copybuf; + blkfront_read(&aiocb); + memcpy(buf, ©buf[blkoff], bytes); + } + } + /* Write operation */ + else { + if(alignedbuf && bytes >= blocksize) { + /* If aligned and were writing a whole block, just write directly from buf */ + aiocb.aio_buf = buf; + blkfront_write(&aiocb); + } else { + /* If not then we have to do a copy. */ + aiocb.aio_buf = copybuf; + /* If we're writing a partial block, we need to read the current contents first + * so we don't overwrite the extra bits with garbage */ + if(blkoff != 0 || bytes < blocksize) { + blkfront_read(&aiocb); + } + memcpy(©buf[blkoff], buf, bytes); + blkfront_write(&aiocb); + } + } + /* Will start at beginning of all remaining blocks */ + blkoff = 0; + + /* Increment counters and continue */ + count -= bytes; + buf += bytes; + if(bytes < blocksize) { + //At minimum we read one block + aiocb.aio_offset += blocksize; + } else { + //If we read more than a block, was a multiple of blocksize + aiocb.aio_offset += bytes; + } + } + + free(copybuf); + files[fd].blk.offset += rc; + return rc; + +} + +int blkfront_posix_fstat(int fd, struct stat* buf) +{ + struct blkfront_dev* dev = files[fd].blk.dev; + + buf->st_mode = dev->info.mode; + buf->st_uid = 0; + buf->st_gid = 0; + buf->st_size = dev->info.sectors * dev->info.sector_size; + buf->st_atime = buf->st_mtime = buf->st_ctime = time(NULL); + + return 0; +} #endif diff --git a/extras/mini-os/include/blkfront.h b/extras/mini-os/include/blkfront.h index 724137e..3528af9 100644 --- a/extras/mini-os/include/blkfront.h +++ b/extras/mini-os/include/blkfront.h @@ -28,7 +28,17 @@ struct blkfront_info }; struct blkfront_dev *init_blkfront(char *nodename, struct blkfront_info *info); #ifdef HAVE_LIBC +#include +/* POSIX IO functions: + * use blkfront_open() to get a file descriptor to the block device + * Don't use the other blkfront posix functions here directly, instead use + * read(), write(), lseek() and fstat() on the file descriptor + */ int blkfront_open(struct blkfront_dev *dev); +int blkfront_posix_rwop(int fd, uint8_t* buf, size_t count, int write); +#define blkfront_posix_write(fd, buf, count) blkfront_posix_rwop(fd, (uint8_t*)buf, count, 1) +#define blkfront_posix_read(fd, buf, count) blkfront_posix_rwop(fd, (uint8_t*)buf, count, 0) +int blkfront_posix_fstat(int fd, struct stat* buf); #endif void blkfront_aio(struct blkfront_aiocb *aiocbp, int write); #define blkfront_aio_read(aiocbp) blkfront_aio(aiocbp, 0) diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h index 1af2717..d4641b6 100644 --- a/extras/mini-os/include/lib.h +++ b/extras/mini-os/include/lib.h @@ -174,6 +174,7 @@ extern struct file { } tap; struct { struct blkfront_dev *dev; + off_t offset; } blk; struct { struct kbdfront_dev *dev; diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c index a7d35d6..7ddbbf8 100644 --- a/extras/mini-os/lib/sys.c +++ b/extras/mini-os/lib/sys.c @@ -289,6 +289,11 @@ int read(int fd, void *buf, size_t nbytes) return ret * sizeof(union xenfb_in_event); } #endif +#ifdef CONFIG_BLKFRONT + case FTYPE_BLK: { + return blkfront_posix_read(fd, buf, nbytes); + } +#endif default: break; } @@ -321,6 +326,10 @@ int write(int fd, const void *buf, size_t nbytes) netfront_xmit(files[fd].tap.dev, (void*) buf, nbytes); return nbytes; #endif +#ifdef CONFIG_BLKFRONT + case FTYPE_BLK: + return blkfront_posix_write(fd, buf, nbytes); +#endif default: break; } @@ -331,8 +340,37 @@ int write(int fd, const void *buf, size_t nbytes) off_t lseek(int fd, off_t offset, int whence) { - errno = ESPIPE; - return (off_t) -1; + switch(files[fd].type) { +#ifdef CONFIG_BLKFRONT + case FTYPE_BLK: + switch (whence) { + case SEEK_SET: + files[fd].file.offset = offset; + break; + case SEEK_CUR: + files[fd].file.offset += offset; + break; + case SEEK_END: + { + struct stat st; + int ret; + ret = fstat(fd, &st); + if (ret) + return -1; + files[fd].file.offset = st.st_size + offset; + break; + } + default: + errno = EINVAL; + return -1; + } + return files[fd].file.offset; + break; +#endif + default: /* Not implemented on this FTYPE */ + errno = ESPIPE; + return (off_t) -1; + } } int fsync(int fd) { @@ -445,6 +483,10 @@ int fstat(int fd, struct stat *buf) buf->st_ctime = time(NULL); return 0; } +#ifdef CONFIG_BLKFRONT + case FTYPE_BLK: + return blkfront_posix_fstat(fd, buf); +#endif default: break; } -- 1.7.4.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 18:01:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 18:01:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCDQ-0002QR-Mi; Fri, 05 Oct 2012 18:01:36 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCDP-0002Pd-1E for xen-devel@lists.xen.org; Fri, 05 Oct 2012 18:01:35 +0000 Received: from [85.158.137.99:22188] by server-9.bemta-3.messagelabs.com id 79/D5-20338-E702F605; Fri, 05 Oct 2012 18:01:34 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-15.tower-217.messagelabs.com!1349460091!18082258!1 X-Originating-IP: [128.244.251.37] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19583 invoked from network); 5 Oct 2012 18:01:33 -0000 Received: from piper.jhuapl.edu (HELO jhuapl.edu) (128.244.251.37) by server-15.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 18:01:33 -0000 Received: from ([128.244.207.97]) by piper.jhuapl.edu with ESMTP with TLS id 5Y8HCH1.146215550; Fri, 05 Oct 2012 14:01:02 -0400 From: Matthew Fioravante To: xen-devel@lists.xen.org, ian.campbell@citrix.com, samuel.thibault@ens-lyons.org Date: Fri, 5 Oct 2012 14:01:12 -0400 Message-Id: <1349460077-13770-3-git-send-email-matthew.fioravante@jhuapl.edu> X-Mailer: git-send-email 1.7.4.4 In-Reply-To: <1349460077-13770-1-git-send-email-matthew.fioravante@jhuapl.edu> References: <1349460077-13770-1-git-send-email-matthew.fioravante@jhuapl.edu> Cc: Matthew Fioravante Subject: [Xen-devel] [PATCH vtpm v2 03/12] Add endian, byteswap, and wordsize macros to mini-os X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch addes byte swapping macros and endian support to mini-os. Signed-off-by: Matthew Fioravante Acked-by: Samuel Thibault diff --git a/extras/mini-os/include/byteorder.h b/extras/mini-os/include/byteorder.h new file mode 100644 index 0000000..c0e29df --- /dev/null +++ b/extras/mini-os/include/byteorder.h @@ -0,0 +1,36 @@ +#ifndef MINIOS_BYTEORDER_H +#define MINIOS_BYTEORDER_H + +#include +#include + +#if __BYTE_ORDER == __LITTLE_ENDIAN +#define be16_to_cpu(v) bswap_16(v) +#define be32_to_cpu(v) bswap_32(v) +#define be64_to_cpu(v) bswap_64(v) + +#define le16_to_cpu(v) (v) +#define le32_to_cpu(v) (v) +#define le64_to_cpu(v) (v) + +#else /*__BIG_ENDIAN*/ +#define be16_to_cpu(v) (v) +#define be32_to_cpu(v) (v) +#define be64_to_cpu(v) (v) + +#define le16_to_cpu(v) bswap_16(v) +#define le32_to_cpu(v) bswap_32(v) +#define le64_to_cpu(v) bswap_64(v) + +#endif + +#define cpu_to_be16(v) be16_to_cpu(v) +#define cpu_to_be32(v) be32_to_cpu(v) +#define cpu_to_be64(v) be64_to_cpu(v) + +#define cpu_to_le16(v) le16_to_cpu(v) +#define cpu_to_le32(v) le32_to_cpu(v) +#define cpu_to_le64(v) le64_to_cpu(v) + + +#endif diff --git a/extras/mini-os/include/byteswap.h b/extras/mini-os/include/byteswap.h index 46821ae..992c8bd 100644 --- a/extras/mini-os/include/byteswap.h +++ b/extras/mini-os/include/byteswap.h @@ -4,30 +4,36 @@ /* Unfortunately not provided by newlib. */ #include -static inline uint16_t bswap_16(uint16_t x) -{ - return - ((((x) & 0xff00) >> 8) | (((x) & 0xff) << 8)); -} - -static inline uint32_t bswap_32(uint32_t x) -{ - return - ((((x) & 0xff000000) >> 24) | (((x) & 0x00ff0000) >> 8) | - (((x) & 0x0000ff00) << 8) | (((x) & 0x000000ff) << 24)); -} - -static inline uint64_t bswap_64(uint64_t x) -{ - return - ((((x) & 0xff00000000000000ULL) >> 56) | - (((x) & 0x00ff000000000000ULL) >> 40) | - (((x) & 0x0000ff0000000000ULL) >> 24) | - (((x) & 0x000000ff00000000ULL) >> 8) | - (((x) & 0x00000000ff000000ULL) << 8) | - (((x) & 0x0000000000ff0000ULL) << 24) | - (((x) & 0x000000000000ff00ULL) << 40) | - (((x) & 0x00000000000000ffULL) << 56)); -} + +#define bswap_16(x) ((uint16_t)( \ + (((uint16_t)(x) & (uint16_t)0x00ffU) << 8) | \ + (((uint16_t)(x) & (uint16_t)0xff00U) >> 8))) + +/* Use gcc optimized versions if they exist */ +#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 3) +#define bswap_32(v) __builtin_bswap32(v) +#define bswap_64(v) __builtin_bswap64(v) +#else + +#define bswap_32(x) ((uint32_t)( \ + (((uint32_t)(x) & (uint32_t)0x000000ffUL) << 24) | \ + (((uint32_t)(x) & (uint32_t)0x0000ff00UL) << 8) | \ + (((uint32_t)(x) & (uint32_t)0x00ff0000UL) >> 8) | \ + (((uint32_t)(x) & (uint32_t)0xff000000UL) >> 24))) + +#define bswap_64(x) ((uint64_t)( \ + (((uint64_t)(x) & (uint64_t)0x00000000000000ffULL) << 56) | \ + (((uint64_t)(x) & (uint64_t)0x000000000000ff00ULL) << 40) | \ + (((uint64_t)(x) & (uint64_t)0x0000000000ff0000ULL) << 24) | \ + (((uint64_t)(x) & (uint64_t)0x00000000ff000000ULL) << 8) | \ + (((uint64_t)(x) & (uint64_t)0x000000ff00000000ULL) >> 8) | \ + (((uint64_t)(x) & (uint64_t)0x0000ff0000000000ULL) >> 24) | \ + (((uint64_t)(x) & (uint64_t)0x00ff000000000000ULL) >> 40) | \ + (((uint64_t)(x) & (uint64_t)0xff00000000000000ULL) >> 56))) + +#endif + + + #endif /* _BYTESWAP_H */ diff --git a/extras/mini-os/include/endian.h b/extras/mini-os/include/endian.h new file mode 100644 index 0000000..cdf432b --- /dev/null +++ b/extras/mini-os/include/endian.h @@ -0,0 +1,15 @@ +#ifndef _ENDIAN_H_ +#define _ENDIAN_H_ + +#define __LITTLE_ENDIAN 1234 +#define __BIG_ENDIAN 4321 +#define __PDP_ENDIAN 3412 + +#define ARCH_ENDIAN_H +/* This will define __BYTE_ORDER for the current arch */ +#include +#undef ARCH_ENDIAN_H + +#include + +#endif /* endian.h */ diff --git a/extras/mini-os/include/x86/arch_endian.h b/extras/mini-os/include/x86/arch_endian.h new file mode 100644 index 0000000..0771683 --- /dev/null +++ b/extras/mini-os/include/x86/arch_endian.h @@ -0,0 +1,7 @@ +#ifndef ARCH_ENDIAN_H +#error "Do not include arch_endian by itself, include endian.h" +#else + +#define __BYTE_ORDER __LITTLE_ENDIAN + +#endif diff --git a/extras/mini-os/include/x86/x86_32/arch_wordsize.h b/extras/mini-os/include/x86/x86_32/arch_wordsize.h new file mode 100644 index 0000000..b47eee9 --- /dev/null +++ b/extras/mini-os/include/x86/x86_32/arch_wordsize.h @@ -0,0 +1 @@ +#define __WORDSIZE 32 diff --git a/extras/mini-os/include/x86/x86_64/arch_wordsize.h b/extras/mini-os/include/x86/x86_64/arch_wordsize.h new file mode 100644 index 0000000..3048136 --- /dev/null +++ b/extras/mini-os/include/x86/x86_64/arch_wordsize.h @@ -0,0 +1,2 @@ +#define __WORDSIZE 64 +#define __WORDSIZE_COMPAT32 1 -- 1.7.4.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 18:01:51 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 18:01:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCDQ-0002QR-Mi; Fri, 05 Oct 2012 18:01:36 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCDP-0002Pd-1E for xen-devel@lists.xen.org; Fri, 05 Oct 2012 18:01:35 +0000 Received: from [85.158.137.99:22188] by server-9.bemta-3.messagelabs.com id 79/D5-20338-E702F605; Fri, 05 Oct 2012 18:01:34 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-15.tower-217.messagelabs.com!1349460091!18082258!1 X-Originating-IP: [128.244.251.37] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19583 invoked from network); 5 Oct 2012 18:01:33 -0000 Received: from piper.jhuapl.edu (HELO jhuapl.edu) (128.244.251.37) by server-15.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 18:01:33 -0000 Received: from ([128.244.207.97]) by piper.jhuapl.edu with ESMTP with TLS id 5Y8HCH1.146215550; Fri, 05 Oct 2012 14:01:02 -0400 From: Matthew Fioravante To: xen-devel@lists.xen.org, ian.campbell@citrix.com, samuel.thibault@ens-lyons.org Date: Fri, 5 Oct 2012 14:01:12 -0400 Message-Id: <1349460077-13770-3-git-send-email-matthew.fioravante@jhuapl.edu> X-Mailer: git-send-email 1.7.4.4 In-Reply-To: <1349460077-13770-1-git-send-email-matthew.fioravante@jhuapl.edu> References: <1349460077-13770-1-git-send-email-matthew.fioravante@jhuapl.edu> Cc: Matthew Fioravante Subject: [Xen-devel] [PATCH vtpm v2 03/12] Add endian, byteswap, and wordsize macros to mini-os X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch addes byte swapping macros and endian support to mini-os. Signed-off-by: Matthew Fioravante Acked-by: Samuel Thibault diff --git a/extras/mini-os/include/byteorder.h b/extras/mini-os/include/byteorder.h new file mode 100644 index 0000000..c0e29df --- /dev/null +++ b/extras/mini-os/include/byteorder.h @@ -0,0 +1,36 @@ +#ifndef MINIOS_BYTEORDER_H +#define MINIOS_BYTEORDER_H + +#include +#include + +#if __BYTE_ORDER == __LITTLE_ENDIAN +#define be16_to_cpu(v) bswap_16(v) +#define be32_to_cpu(v) bswap_32(v) +#define be64_to_cpu(v) bswap_64(v) + +#define le16_to_cpu(v) (v) +#define le32_to_cpu(v) (v) +#define le64_to_cpu(v) (v) + +#else /*__BIG_ENDIAN*/ +#define be16_to_cpu(v) (v) +#define be32_to_cpu(v) (v) +#define be64_to_cpu(v) (v) + +#define le16_to_cpu(v) bswap_16(v) +#define le32_to_cpu(v) bswap_32(v) +#define le64_to_cpu(v) bswap_64(v) + +#endif + +#define cpu_to_be16(v) be16_to_cpu(v) +#define cpu_to_be32(v) be32_to_cpu(v) +#define cpu_to_be64(v) be64_to_cpu(v) + +#define cpu_to_le16(v) le16_to_cpu(v) +#define cpu_to_le32(v) le32_to_cpu(v) +#define cpu_to_le64(v) le64_to_cpu(v) + + +#endif diff --git a/extras/mini-os/include/byteswap.h b/extras/mini-os/include/byteswap.h index 46821ae..992c8bd 100644 --- a/extras/mini-os/include/byteswap.h +++ b/extras/mini-os/include/byteswap.h @@ -4,30 +4,36 @@ /* Unfortunately not provided by newlib. */ #include -static inline uint16_t bswap_16(uint16_t x) -{ - return - ((((x) & 0xff00) >> 8) | (((x) & 0xff) << 8)); -} - -static inline uint32_t bswap_32(uint32_t x) -{ - return - ((((x) & 0xff000000) >> 24) | (((x) & 0x00ff0000) >> 8) | - (((x) & 0x0000ff00) << 8) | (((x) & 0x000000ff) << 24)); -} - -static inline uint64_t bswap_64(uint64_t x) -{ - return - ((((x) & 0xff00000000000000ULL) >> 56) | - (((x) & 0x00ff000000000000ULL) >> 40) | - (((x) & 0x0000ff0000000000ULL) >> 24) | - (((x) & 0x000000ff00000000ULL) >> 8) | - (((x) & 0x00000000ff000000ULL) << 8) | - (((x) & 0x0000000000ff0000ULL) << 24) | - (((x) & 0x000000000000ff00ULL) << 40) | - (((x) & 0x00000000000000ffULL) << 56)); -} + +#define bswap_16(x) ((uint16_t)( \ + (((uint16_t)(x) & (uint16_t)0x00ffU) << 8) | \ + (((uint16_t)(x) & (uint16_t)0xff00U) >> 8))) + +/* Use gcc optimized versions if they exist */ +#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 3) +#define bswap_32(v) __builtin_bswap32(v) +#define bswap_64(v) __builtin_bswap64(v) +#else + +#define bswap_32(x) ((uint32_t)( \ + (((uint32_t)(x) & (uint32_t)0x000000ffUL) << 24) | \ + (((uint32_t)(x) & (uint32_t)0x0000ff00UL) << 8) | \ + (((uint32_t)(x) & (uint32_t)0x00ff0000UL) >> 8) | \ + (((uint32_t)(x) & (uint32_t)0xff000000UL) >> 24))) + +#define bswap_64(x) ((uint64_t)( \ + (((uint64_t)(x) & (uint64_t)0x00000000000000ffULL) << 56) | \ + (((uint64_t)(x) & (uint64_t)0x000000000000ff00ULL) << 40) | \ + (((uint64_t)(x) & (uint64_t)0x0000000000ff0000ULL) << 24) | \ + (((uint64_t)(x) & (uint64_t)0x00000000ff000000ULL) << 8) | \ + (((uint64_t)(x) & (uint64_t)0x000000ff00000000ULL) >> 8) | \ + (((uint64_t)(x) & (uint64_t)0x0000ff0000000000ULL) >> 24) | \ + (((uint64_t)(x) & (uint64_t)0x00ff000000000000ULL) >> 40) | \ + (((uint64_t)(x) & (uint64_t)0xff00000000000000ULL) >> 56))) + +#endif + + + #endif /* _BYTESWAP_H */ diff --git a/extras/mini-os/include/endian.h b/extras/mini-os/include/endian.h new file mode 100644 index 0000000..cdf432b --- /dev/null +++ b/extras/mini-os/include/endian.h @@ -0,0 +1,15 @@ +#ifndef _ENDIAN_H_ +#define _ENDIAN_H_ + +#define __LITTLE_ENDIAN 1234 +#define __BIG_ENDIAN 4321 +#define __PDP_ENDIAN 3412 + +#define ARCH_ENDIAN_H +/* This will define __BYTE_ORDER for the current arch */ +#include +#undef ARCH_ENDIAN_H + +#include + +#endif /* endian.h */ diff --git a/extras/mini-os/include/x86/arch_endian.h b/extras/mini-os/include/x86/arch_endian.h new file mode 100644 index 0000000..0771683 --- /dev/null +++ b/extras/mini-os/include/x86/arch_endian.h @@ -0,0 +1,7 @@ +#ifndef ARCH_ENDIAN_H +#error "Do not include arch_endian by itself, include endian.h" +#else + +#define __BYTE_ORDER __LITTLE_ENDIAN + +#endif diff --git a/extras/mini-os/include/x86/x86_32/arch_wordsize.h b/extras/mini-os/include/x86/x86_32/arch_wordsize.h new file mode 100644 index 0000000..b47eee9 --- /dev/null +++ b/extras/mini-os/include/x86/x86_32/arch_wordsize.h @@ -0,0 +1 @@ +#define __WORDSIZE 32 diff --git a/extras/mini-os/include/x86/x86_64/arch_wordsize.h b/extras/mini-os/include/x86/x86_64/arch_wordsize.h new file mode 100644 index 0000000..3048136 --- /dev/null +++ b/extras/mini-os/include/x86/x86_64/arch_wordsize.h @@ -0,0 +1,2 @@ +#define __WORDSIZE 64 +#define __WORDSIZE_COMPAT32 1 -- 1.7.4.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 18:01:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 18:01:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCDY-0002T9-PP; Fri, 05 Oct 2012 18:01:44 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCDW-0002Qf-Lp for xen-devel@lists.xen.org; Fri, 05 Oct 2012 18:01:42 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-13.tower-27.messagelabs.com!1349460094!8915599!1 X-Originating-IP: [128.244.251.37] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7049 invoked from network); 5 Oct 2012 18:01:35 -0000 Received: from piper.jhuapl.edu (HELO jhuapl.edu) (128.244.251.37) by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 18:01:35 -0000 Received: from ([128.244.207.97]) by piper.jhuapl.edu with ESMTP with TLS id 5Y8HCH1.146215576; Fri, 05 Oct 2012 14:01:02 -0400 From: Matthew Fioravante To: xen-devel@lists.xen.org, ian.campbell@citrix.com, samuel.thibault@ens-lyons.org Date: Fri, 5 Oct 2012 14:01:16 -0400 Message-Id: <1349460077-13770-7-git-send-email-matthew.fioravante@jhuapl.edu> X-Mailer: git-send-email 1.7.4.4 In-Reply-To: <1349460077-13770-1-git-send-email-matthew.fioravante@jhuapl.edu> References: <1349460077-13770-1-git-send-email-matthew.fioravante@jhuapl.edu> Cc: Matthew Fioravante Subject: [Xen-devel] [PATCH vtpm v2 07/12] setup fpu and sse in mini-os X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch adds floating point and sse support to mini-os by initializing the floating point unit and the see unit during domain boot up. Signed-off-by: Matthew Fioravante Acked-by: Samuel Thibault diff --git a/extras/mini-os/arch/x86/setup.c b/extras/mini-os/arch/x86/setup.c index 923901e..54046d3 100644 --- a/extras/mini-os/arch/x86/setup.c +++ b/extras/mini-os/arch/x86/setup.c @@ -74,9 +74,28 @@ shared_info_t *map_shared_info(unsigned long pa) return (shared_info_t *)shared_info; } +static inline void fpu_init(void) { + asm volatile("fninit"); +} + +#ifdef __SSE__ +static inline void sse_init(void) { + unsigned long status = 0x1f80; + asm volatile("ldmxcsr %0" : : "m" (status)); +} +#else +#define sse_init() +#endif + void arch_init(start_info_t *si) { + /*Initialize floating point unit */ + fpu_init(); + + /* Initialize SSE */ + sse_init(); + /* Copy the start_info struct to a globally-accessible area. */ /* WARN: don't do printk before here, it uses information from shared_info. Use xprintk instead. */ @@ -99,6 +118,7 @@ arch_init(start_info_t *si) (unsigned long)failsafe_callback, 0); #endif + } void -- 1.7.4.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 18:01:52 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 18:01:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCDY-0002T9-PP; Fri, 05 Oct 2012 18:01:44 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCDW-0002Qf-Lp for xen-devel@lists.xen.org; Fri, 05 Oct 2012 18:01:42 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-13.tower-27.messagelabs.com!1349460094!8915599!1 X-Originating-IP: [128.244.251.37] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7049 invoked from network); 5 Oct 2012 18:01:35 -0000 Received: from piper.jhuapl.edu (HELO jhuapl.edu) (128.244.251.37) by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 18:01:35 -0000 Received: from ([128.244.207.97]) by piper.jhuapl.edu with ESMTP with TLS id 5Y8HCH1.146215576; Fri, 05 Oct 2012 14:01:02 -0400 From: Matthew Fioravante To: xen-devel@lists.xen.org, ian.campbell@citrix.com, samuel.thibault@ens-lyons.org Date: Fri, 5 Oct 2012 14:01:16 -0400 Message-Id: <1349460077-13770-7-git-send-email-matthew.fioravante@jhuapl.edu> X-Mailer: git-send-email 1.7.4.4 In-Reply-To: <1349460077-13770-1-git-send-email-matthew.fioravante@jhuapl.edu> References: <1349460077-13770-1-git-send-email-matthew.fioravante@jhuapl.edu> Cc: Matthew Fioravante Subject: [Xen-devel] [PATCH vtpm v2 07/12] setup fpu and sse in mini-os X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch adds floating point and sse support to mini-os by initializing the floating point unit and the see unit during domain boot up. Signed-off-by: Matthew Fioravante Acked-by: Samuel Thibault diff --git a/extras/mini-os/arch/x86/setup.c b/extras/mini-os/arch/x86/setup.c index 923901e..54046d3 100644 --- a/extras/mini-os/arch/x86/setup.c +++ b/extras/mini-os/arch/x86/setup.c @@ -74,9 +74,28 @@ shared_info_t *map_shared_info(unsigned long pa) return (shared_info_t *)shared_info; } +static inline void fpu_init(void) { + asm volatile("fninit"); +} + +#ifdef __SSE__ +static inline void sse_init(void) { + unsigned long status = 0x1f80; + asm volatile("ldmxcsr %0" : : "m" (status)); +} +#else +#define sse_init() +#endif + void arch_init(start_info_t *si) { + /*Initialize floating point unit */ + fpu_init(); + + /* Initialize SSE */ + sse_init(); + /* Copy the start_info struct to a globally-accessible area. */ /* WARN: don't do printk before here, it uses information from shared_info. Use xprintk instead. */ @@ -99,6 +118,7 @@ arch_init(start_info_t *si) (unsigned long)failsafe_callback, 0); #endif + } void -- 1.7.4.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 18:01:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 18:01:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCDb-0002Ua-6E; Fri, 05 Oct 2012 18:01:47 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCDZ-0002T7-4W for xen-devel@lists.xen.org; Fri, 05 Oct 2012 18:01:45 +0000 Received: from [85.158.139.211:3025] by server-7.bemta-5.messagelabs.com id 71/CC-00431-8802F605; Fri, 05 Oct 2012 18:01:44 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-12.tower-206.messagelabs.com!1349460097!20239802!1 X-Originating-IP: [128.244.251.37] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6021 invoked from network); 5 Oct 2012 18:01:39 -0000 Received: from piper.jhuapl.edu (HELO jhuapl.edu) (128.244.251.37) by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 18:01:39 -0000 Received: from ([128.244.207.97]) by piper.jhuapl.edu with ESMTP with TLS id 5Y8HCH1.146215583; Fri, 05 Oct 2012 14:01:02 -0400 From: Matthew Fioravante To: xen-devel@lists.xen.org, ian.campbell@citrix.com, samuel.thibault@ens-lyons.org Date: Fri, 5 Oct 2012 14:01:17 -0400 Message-Id: <1349460077-13770-8-git-send-email-matthew.fioravante@jhuapl.edu> X-Mailer: git-send-email 1.7.4.4 In-Reply-To: <1349460077-13770-1-git-send-email-matthew.fioravante@jhuapl.edu> References: <1349460077-13770-1-git-send-email-matthew.fioravante@jhuapl.edu> Cc: Matthew Fioravante Subject: [Xen-devel] [PATCH vtpm v2 08/12] add tpmfront, tpm_tis, and tpmback drivers to mini-os X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch adds 3 new drivers to mini-os. tpmfront - paravirtualized tpm frontend driver tpmback - paravirtualized tpm backend driver tpm_tis - hardware tpm driver Unfortunately these drivers were derived from GPL licensed linux kernel drivers so they must carry the GPL license. However, since mini-os now supports conditional compilation, hopefully these drivers can be included into the xen tree and conditionally removed from non-gpl projects. By default they are disabled in the makefile. Signed-off-by: Matthew Fioravante diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile index 2422db3..2302a23 100644 --- a/extras/mini-os/Makefile +++ b/extras/mini-os/Makefile @@ -22,6 +22,9 @@ CONFIG_QEMU_XS_ARGS ?= n CONFIG_TEST ?= n CONFIG_PCIFRONT ?= n CONFIG_BLKFRONT ?= y +CONFIG_TPMFRONT ?= n +CONFIG_TPM_TIS ?= n +CONFIG_TPMBACK ?= n CONFIG_NETFRONT ?= y CONFIG_FBFRONT ?= y CONFIG_KBDFRONT ?= y @@ -36,6 +39,9 @@ flags-$(CONFIG_SPARSE_BSS) += -DCONFIG_SPARSE_BSS flags-$(CONFIG_QEMU_XS_ARGS) += -DCONFIG_QEMU_XS_ARGS flags-$(CONFIG_PCIFRONT) += -DCONFIG_PCIFRONT flags-$(CONFIG_BLKFRONT) += -DCONFIG_BLKFRONT +flags-$(CONFIG_TPMFRONT) += -DCONFIG_TPMFRONT +flags-$(CONFIG_TPM_TIS) += -DCONFIG_TPM_TIS +flags-$(CONFIG_TPMBACK) += -DCONFIG_TPMBACK flags-$(CONFIG_NETFRONT) += -DCONFIG_NETFRONT flags-$(CONFIG_KBDFRONT) += -DCONFIG_KBDFRONT flags-$(CONFIG_FBFRONT) += -DCONFIG_FBFRONT @@ -67,6 +73,9 @@ TARGET := mini-os SUBDIRS := lib xenbus console src-$(CONFIG_BLKFRONT) += blkfront.c +src-$(CONFIG_TPMFRONT) += tpmfront.c +src-$(CONFIG_TPM_TIS) += tpm_tis.c +src-$(CONFIG_TPMBACK) += tpmback.c src-y += daytime.c src-y += events.c src-$(CONFIG_FBFRONT) += fbfront.c diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h index d4641b6..935bede 100644 --- a/extras/mini-os/include/lib.h +++ b/extras/mini-os/include/lib.h @@ -142,6 +142,8 @@ enum fd_type { FTYPE_FB, FTYPE_MEM, FTYPE_SAVEFILE, + FTYPE_TPMFRONT, + FTYPE_TPM_TIS, }; LIST_HEAD(evtchn_port_list, evtchn_port_info); @@ -185,6 +187,20 @@ extern struct file { struct { struct consfront_dev *dev; } cons; +#ifdef CONFIG_TPMFRONT + struct { + struct tpmfront_dev *dev; + int respgot; + off_t offset; + } tpmfront; +#endif +#ifdef CONFIG_TPM_TIS + struct { + struct tpm_chip *dev; + int respgot; + off_t offset; + } tpm_tis; +#endif #ifdef CONFIG_XENBUS struct { /* To each xenbus FD is associated a queue of watch events for this diff --git a/extras/mini-os/include/tpm_tis.h b/extras/mini-os/include/tpm_tis.h new file mode 100644 index 0000000..1faca0d --- /dev/null +++ b/extras/mini-os/include/tpm_tis.h @@ -0,0 +1,60 @@ +/* + * Copyright (c) 2010-2012 United States Government, as represented by + * the Secretary of Defense. All rights reserved. + * + * This code has been derived from drivers/char/tpm.c + * from the linux kernel + * + * Copyright (C) 2004 IBM Corporation + * + * This code has also been derived from drivers/char/tpm/tpm_tis.c + * from the linux kernel + * + * Copyright (C) 2005, 2006 IBM Corporation + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation, version 2 + * of the License + */ +#ifndef TPM_TIS_H +#define TPM_TIS_H + +#include +#include + +#define TPM_TIS_EN_LOCL0 1 +#define TPM_TIS_EN_LOCL1 (1 << 1) +#define TPM_TIS_EN_LOCL2 (1 << 2) +#define TPM_TIS_EN_LOCL3 (1 << 3) +#define TPM_TIS_EN_LOCL4 (1 << 4) +#define TPM_TIS_EN_LOCLALL (TPM_TIS_EN_LOCL0 | TPM_TIS_EN_LOCL1 | TPM_TIS_EN_LOCL2 | TPM_TIS_EN_LOCL3 | TPM_TIS_EN_LOCL4) +#define TPM_TIS_LOCL_INT_TO_FLAG(x) (1 << x) +#define TPM_BASEADDR 0xFED40000 +#define TPM_PROBE_IRQ 0xFFFF + +struct tpm_chip; + +struct tpm_chip* init_tpm_tis(unsigned long baseaddr, int localities, unsigned int irq); +void shutdown_tpm_tis(struct tpm_chip* tpm); + +int tpm_tis_request_locality(struct tpm_chip* tpm, int locality); +int tpm_tis_cmd(struct tpm_chip* tpm, uint8_t* req, size_t reqlen, uint8_t** resp, size_t* resplen); + +#ifdef HAVE_LIBC +#include +#include +/* POSIX IO functions: + * use tpm_tis_open() to get a file descriptor to the tpm device + * use write() on the fd to send a command to the backend. You must + * include the entire command in a single call to write(). + * use read() on the fd to read the response. You can use + * fstat() to get the size of the response and lseek() to seek on it. + */ +int tpm_tis_open(struct tpm_chip* tpm); +int tpm_tis_posix_read(int fd, uint8_t* buf, size_t count); +int tpm_tis_posix_write(int fd, const uint8_t* buf, size_t count); +int tpm_tis_posix_fstat(int fd, struct stat* buf); +#endif + +#endif diff --git a/extras/mini-os/include/tpmback.h b/extras/mini-os/include/tpmback.h new file mode 100644 index 0000000..302f83b --- /dev/null +++ b/extras/mini-os/include/tpmback.h @@ -0,0 +1,110 @@ +/* + * Copyright (c) 2010-2012 United States Government, as represented by + * the Secretary of Defense. All rights reserved. + * + * This code has been derived from drivers/xen/tpmback/tpmback.c + * from the xen 2.6.18 linux kernel + * + * Copyright (c) 2005, IBM Corporation + * + * which was itself derived from drivers/xen/netback/netback.c + * from the xen 2.6.18 linux kernel + * + * Copyright (c) 2002-2004, K A Fraser + * + * This code has also been derived from drivers/xen/tpmback/xenbus.c + * from the xen 2.6.18 linux kernel + * + * Copyright (C) 2005 IBM Corporation + * Copyright (C) 2005 Rusty Russell + * + * This code has also been derived from drivers/xen/tpmback/interface.c + * from the xen 2.6.18 linux kernel + * + * Copyright (c) 2005, IBM Corporation + * + * which was itself also derived from drvivers/xen/netback/interface.c + * from the xen 2.6.18 linux kernel + * + * Copyright (c) 2004, Keir Fraser + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation, version 2 + * of the License + */ + +#include +#include +#include +#include +#ifndef TPMBACK_H +#define TPMBACK_H + +struct tpmcmd { + domid_t domid; /* Domid of the frontend */ + unsigned int handle; /* Handle of the frontend */ + char* uuid; /* uuid of the tpm interface - allocated internally, dont free it */ + + unsigned int req_len; /* Size of the command in buf - set by tpmback driver */ + uint8_t* req; /* tpm command bits, allocated by driver, DON'T FREE IT */ + unsigned int resp_len; /* Size of the outgoing command, + you set this before passing the cmd object to tpmback_resp */ + uint8_t* resp; /* Buffer for response - YOU MUST ALLOCATE IT, YOU MUST ALSO FREE IT */ +}; +typedef struct tpmcmd tpmcmd_t; + +/* Initialize the tpm backend driver + * @exclusive_domname - This is NULL terminated list of vtpm uuid strings. If this list + * is non-empty, then only frontend domains with vtpm uuid's matching + * entries in this list will be allowed to connect. + * Other connections will be immediatly closed. + * Set this argument to NULL to allow any vtpm to connect. + */ +void init_tpmback(char** exclusive_uuids); +/* Shutdown tpm backend driver */ +void shutdown_tpmback(void); + +/* Blocks until a tpm command is sent from any front end. + * Returns a pointer to the tpm command to handle. + * Do not try to free this pointer or the req buffer + * This function will return NULL if the tpm backend driver + * is shutdown or any other error occurs */ +tpmcmd_t* tpmback_req_any(void); + +/* Blocks until a tpm command from the frontend at domid/handle + * is sent. + * Returns NULL if domid/handle is not connected, tpmback is + * shutdown or shutting down, or if there is an error + */ +tpmcmd_t* tpmback_req(domid_t domid, unsigned int handle); + +/* Send the response to the tpm command back to the frontend + * This function will free the tpmcmd object, but you must free the resp + * buffer yourself */ +void tpmback_resp(tpmcmd_t* tpmcmd); + +/* Waits for the first frontend to connect and then sets domid and handle appropriately. + * If one or more frontends are already connected, this will set domid and handle to one + * of them arbitrarily. The main use for this function is to wait until a single + * frontend connection has occured. + * returns 0 on success, non-zero on failure */ +int tpmback_wait_for_frontend_connect(domid_t *domid, unsigned int *handle); + +/* returns the number of frontends connected */ +int tpmback_num_frontends(void); + +/* Returns the uuid of the specified frontend, NULL on error */ +char* tpmback_get_uuid(domid_t domid, unsigned int handle); + +/* Specify a function to call when a new tpm device connects */ +void tpmback_set_open_callback(void (*cb)(domid_t, unsigned int)); + +/* Specify a function to call when a tpm device disconnects */ +void tpmback_set_close_callback(void (*cb)(domid_t, unsigned int)); + +//Not Implemented +void tpmback_set_suspend_callback(void (*cb)(domid_t, unsigned int)); +void tpmback_set_resume_callback(void (*cb)(domid_t, unsigned int)); + +#endif diff --git a/extras/mini-os/include/tpmfront.h b/extras/mini-os/include/tpmfront.h new file mode 100644 index 0000000..fd2cb17 --- /dev/null +++ b/extras/mini-os/include/tpmfront.h @@ -0,0 +1,96 @@ +/* + * Copyright (c) 2010-2012 United States Government, as represented by + * the Secretary of Defense. All rights reserved. + * + * This code has been derived from drivers/char/tpm_vtpm.c + * from the xen 2.6.18 linux kernel + * + * Copyright (C) 2006 IBM Corporation + * + * This code has also been derived from drivers/char/tpm_xen.c + * from the xen 2.6.18 linux kernel + * + * Copyright (c) 2005, IBM Corporation + * + * which was itself derived from drivers/xen/netfront/netfront.c + * from the linux kernel + * + * Copyright (c) 2002-2004, K A Fraser + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation, version 2 of the + * License. + */ +#ifndef TPMFRONT_H +#define TPMFRONT_H + +#include +#include +#include +#include +#include +#include +#include + +struct tpmfront_dev { + grant_ref_t ring_ref; + evtchn_port_t evtchn; + + tpmif_tx_interface_t* tx; + + void** pages; + + domid_t bedomid; + char* nodename; + char* bepath; + + XenbusState state; + + uint8_t waiting; + struct wait_queue_head waitq; + + uint8_t* respbuf; + size_t resplen; + +#ifdef HAVE_LIBC + int fd; +#endif + +}; + + +/*Initialize frontend */ +struct tpmfront_dev* init_tpmfront(const char* nodename); +/*Shutdown frontend */ +void shutdown_tpmfront(struct tpmfront_dev* dev); + +/* Send a tpm command to the backend and wait for the response + * + * @dev - frontend device + * @req - request buffer + * @reqlen - length of request buffer + * @resp - *resp will be set to internal response buffer, don't free it! Value is undefined on error + * @resplen - *resplen will be set to the length of the response. Value is undefined on error + * + * returns 0 on success, non zero on failure. + * */ +int tpmfront_cmd(struct tpmfront_dev* dev, uint8_t* req, size_t reqlen, uint8_t** resp, size_t* resplen); + +#ifdef HAVE_LIBC +#include +/* POSIX IO functions: + * use tpmfront_open() to get a file descriptor to the tpm device + * use write() on the fd to send a command to the backend. You must + * include the entire command in a single call to write(). + * use read() on the fd to read the response. You can use + * fstat() to get the size of the response and lseek() to seek on it. + */ +int tpmfront_open(struct tpmfront_dev* dev); +int tpmfront_posix_read(int fd, uint8_t* buf, size_t count); +int tpmfront_posix_write(int fd, const uint8_t* buf, size_t count); +int tpmfront_posix_fstat(int fd, struct stat* buf); +#endif + + +#endif diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c index 6cb97b1..d212969 100644 --- a/extras/mini-os/lib/sys.c +++ b/extras/mini-os/lib/sys.c @@ -27,6 +27,8 @@ #include #include #include +#include +#include #include #include @@ -294,6 +296,16 @@ int read(int fd, void *buf, size_t nbytes) return blkfront_posix_read(fd, buf, nbytes); } #endif +#ifdef CONFIG_TPMFRONT + case FTYPE_TPMFRONT: { + return tpmfront_posix_read(fd, buf, nbytes); + } +#endif +#ifdef CONFIG_TPM_TIS + case FTYPE_TPM_TIS: { + return tpm_tis_posix_read(fd, buf, nbytes); + } +#endif default: break; } @@ -330,6 +342,14 @@ int write(int fd, const void *buf, size_t nbytes) case FTYPE_BLK: return blkfront_posix_write(fd, buf, nbytes); #endif +#ifdef CONFIG_TPMFRONT + case FTYPE_TPMFRONT: + return tpmfront_posix_write(fd, buf, nbytes); +#endif +#ifdef CONFIG_TPM_TIS + case FTYPE_TPM_TIS: + return tpm_tis_posix_write(fd, buf, nbytes); +#endif default: break; } @@ -341,8 +361,16 @@ int write(int fd, const void *buf, size_t nbytes) off_t lseek(int fd, off_t offset, int whence) { switch(files[fd].type) { +#if defined(CONFIG_BLKFRONT) || defined(CONFIG_TPMFRONT) || defined(CONFIG_TPM_TIS) #ifdef CONFIG_BLKFRONT case FTYPE_BLK: +#endif +#ifdef CONFIG_TPMFRNT + case FTYPE_TPMFRONT: +#endif +#ifdef CONFIG_TPM_TIS + case FTYPE_TPM_TIS: +#endif switch (whence) { case SEEK_SET: files[fd].file.offset = offset; @@ -420,6 +448,18 @@ int close(int fd) files[fd].type = FTYPE_NONE; return 0; #endif +#ifdef CONFIG_TPMFRONT + case FTYPE_TPMFRONT: + shutdown_tpmfront(files[fd].tpmfront.dev); + files[fd].type = FTYPE_NONE; + return 0; +#endif +#ifdef CONFIG_TPM_TIS + case FTYPE_TPM_TIS: + shutdown_tpm_tis(files[fd].tpm_tis.dev); + files[fd].type = FTYPE_NONE; + return 0; +#endif #ifdef CONFIG_KBDFRONT case FTYPE_KBD: shutdown_kbdfront(files[fd].kbd.dev); @@ -489,6 +529,14 @@ int fstat(int fd, struct stat *buf) case FTYPE_BLK: return blkfront_posix_fstat(fd, buf); #endif +#ifdef CONFIG_TPMFRONT + case FTYPE_TPMFRONT: + return tpmfront_posix_fstat(fd, buf); +#endif +#ifdef CONFIG_TPM_TIS + case FTYPE_TPM_TIS: + return tpm_tis_posix_fstat(fd, buf); +#endif default: break; } diff --git a/extras/mini-os/tpm_tis.c b/extras/mini-os/tpm_tis.c new file mode 100644 index 0000000..b0e27b2 --- /dev/null +++ b/extras/mini-os/tpm_tis.c @@ -0,0 +1,1341 @@ +/* + * Copyright (c) 2010-2012 United States Government, as represented by + * the Secretary of Defense. All rights reserved. + * + * This code has been derived from drivers/char/tpm.c + * from the linux kernel + * + * Copyright (C) 2004 IBM Corporation + * + * This code has also been derived from drivers/char/tpm/tpm_tis.c + * from the linux kernel + * + * Copyright (C) 2005, 2006 IBM Corporation + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation, version 2 + * of the License + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#ifndef min + #define min( a, b ) ( ((a) < (b)) ? (a) : (b) ) +#endif + +#define TPM_HEADER_SIZE 10 + +#define TPM_BUFSIZE 2048 + +struct tpm_input_header { + uint16_t tag; + uint32_t length; + uint32_t ordinal; +}__attribute__((packed)); + +struct tpm_output_header { + uint16_t tag; + uint32_t length; + uint32_t return_code; +}__attribute__((packed)); + +struct stclear_flags_t { + uint16_t tag; + uint8_t deactivated; + uint8_t disableForceClear; + uint8_t physicalPresence; + uint8_t physicalPresenceLock; + uint8_t bGlobalLock; +}__attribute__((packed)); + +struct tpm_version_t { + uint8_t Major; + uint8_t Minor; + uint8_t revMajor; + uint8_t revMinor; +}__attribute__((packed)); + +struct tpm_version_1_2_t { + uint16_t tag; + uint8_t Major; + uint8_t Minor; + uint8_t revMajor; + uint8_t revMinor; +}__attribute__((packed)); + +struct timeout_t { + uint32_t a; + uint32_t b; + uint32_t c; + uint32_t d; +}__attribute__((packed)); + +struct duration_t { + uint32_t tpm_short; + uint32_t tpm_medium; + uint32_t tpm_long; +}__attribute__((packed)); + +struct permanent_flags_t { + uint16_t tag; + uint8_t disable; + uint8_t ownership; + uint8_t deactivated; + uint8_t readPubek; + uint8_t disableOwnerClear; + uint8_t allowMaintenance; + uint8_t physicalPresenceLifetimeLock; + uint8_t physicalPresenceHWEnable; + uint8_t physicalPresenceCMDEnable; + uint8_t CEKPUsed; + uint8_t TPMpost; + uint8_t TPMpostLock; + uint8_t FIPS; + uint8_t operator; + uint8_t enableRevokeEK; + uint8_t nvLocked; + uint8_t readSRKPub; + uint8_t tpmEstablished; + uint8_t maintenanceDone; + uint8_t disableFullDALogicInfo; +}__attribute__((packed)); + +typedef union { + struct permanent_flags_t perm_flags; + struct stclear_flags_t stclear_flags; + bool owned; + uint32_t num_pcrs; + struct tpm_version_t tpm_version; + struct tpm_version_1_2_t tpm_version_1_2; + uint32_t manufacturer_id; + struct timeout_t timeout; + struct duration_t duration; +} cap_t; + +struct tpm_getcap_params_in { + uint32_t cap; + uint32_t subcap_size; + uint32_t subcap; +}__attribute__((packed)); + +struct tpm_getcap_params_out { + uint32_t cap_size; + cap_t cap; +}__attribute__((packed)); + +struct tpm_readpubek_params_out { + uint8_t algorithm[4]; + uint8_t encscheme[2]; + uint8_t sigscheme[2]; + uint32_t paramsize; + uint8_t parameters[12]; /*assuming RSA*/ + uint32_t keysize; + uint8_t modulus[256]; + uint8_t checksum[20]; +}__attribute__((packed)); + +typedef union { + struct tpm_input_header in; + struct tpm_output_header out; +} tpm_cmd_header; + +#define TPM_DIGEST_SIZE 20 +struct tpm_pcrread_out { + uint8_t pcr_result[TPM_DIGEST_SIZE]; +}__attribute__((packed)); + +struct tpm_pcrread_in { + uint32_t pcr_idx; +}__attribute__((packed)); + +struct tpm_pcrextend_in { + uint32_t pcr_idx; + uint8_t hash[TPM_DIGEST_SIZE]; +}__attribute__((packed)); + +typedef union { + struct tpm_getcap_params_out getcap_out; + struct tpm_readpubek_params_out readpubek_out; + uint8_t readpubek_out_buffer[sizeof(struct tpm_readpubek_params_out)]; + struct tpm_getcap_params_in getcap_in; + struct tpm_pcrread_in pcrread_in; + struct tpm_pcrread_out pcrread_out; + struct tpm_pcrextend_in pcrextend_in; +} tpm_cmd_params; + +struct tpm_cmd_t { + tpm_cmd_header header; + tpm_cmd_params params; +}__attribute__((packed)); + + +enum tpm_duration { + TPM_SHORT = 0, + TPM_MEDIUM = 1, + TPM_LONG = 2, + TPM_UNDEFINED, +}; + +#define TPM_MAX_ORDINAL 243 +#define TPM_MAX_PROTECTED_ORDINAL 12 +#define TPM_PROTECTED_ORDINAL_MASK 0xFF + +extern const uint8_t tpm_protected_ordinal_duration[TPM_MAX_PROTECTED_ORDINAL]; +extern const uint8_t tpm_ordinal_duration[TPM_MAX_ORDINAL]; + +#define TPM_DIGEST_SIZE 20 +#define TPM_ERROR_SIZE 10 +#define TPM_RET_CODE_IDX 6 + +/* tpm_capabilities */ +#define TPM_CAP_FLAG cpu_to_be32(4) +#define TPM_CAP_PROP cpu_to_be32(5) +#define CAP_VERSION_1_1 cpu_to_be32(0x06) +#define CAP_VERSION_1_2 cpu_to_be32(0x1A) + +/* tpm_sub_capabilities */ +#define TPM_CAP_PROP_PCR cpu_to_be32(0x101) +#define TPM_CAP_PROP_MANUFACTURER cpu_to_be32(0x103) +#define TPM_CAP_FLAG_PERM cpu_to_be32(0x108) +#define TPM_CAP_FLAG_VOL cpu_to_be32(0x109) +#define TPM_CAP_PROP_OWNER cpu_to_be32(0x111) +#define TPM_CAP_PROP_TIS_TIMEOUT cpu_to_be32(0x115) +#define TPM_CAP_PROP_TIS_DURATION cpu_to_be32(0x120) + + +#define TPM_INTERNAL_RESULT_SIZE 200 +#define TPM_TAG_RQU_COMMAND cpu_to_be16(193) +#define TPM_ORD_GET_CAP cpu_to_be32(101) + +extern const struct tpm_input_header tpm_getcap_header; + + + +const uint8_t tpm_protected_ordinal_duration[TPM_MAX_PROTECTED_ORDINAL] = { + TPM_UNDEFINED, /* 0 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 5 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 10 */ + TPM_SHORT, +}; + +const uint8_t tpm_ordinal_duration[TPM_MAX_ORDINAL] = { + TPM_UNDEFINED, /* 0 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 5 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 10 */ + TPM_SHORT, + TPM_MEDIUM, + TPM_LONG, + TPM_LONG, + TPM_MEDIUM, /* 15 */ + TPM_SHORT, + TPM_SHORT, + TPM_MEDIUM, + TPM_LONG, + TPM_SHORT, /* 20 */ + TPM_SHORT, + TPM_MEDIUM, + TPM_MEDIUM, + TPM_MEDIUM, + TPM_SHORT, /* 25 */ + TPM_SHORT, + TPM_MEDIUM, + TPM_SHORT, + TPM_SHORT, + TPM_MEDIUM, /* 30 */ + TPM_LONG, + TPM_MEDIUM, + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, /* 35 */ + TPM_MEDIUM, + TPM_MEDIUM, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_MEDIUM, /* 40 */ + TPM_LONG, + TPM_MEDIUM, + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, /* 45 */ + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_LONG, + TPM_MEDIUM, /* 50 */ + TPM_MEDIUM, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 55 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_MEDIUM, /* 60 */ + TPM_MEDIUM, + TPM_MEDIUM, + TPM_SHORT, + TPM_SHORT, + TPM_MEDIUM, /* 65 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 70 */ + TPM_SHORT, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 75 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_LONG, /* 80 */ + TPM_UNDEFINED, + TPM_MEDIUM, + TPM_LONG, + TPM_SHORT, + TPM_UNDEFINED, /* 85 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 90 */ + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_UNDEFINED, /* 95 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_MEDIUM, /* 100 */ + TPM_SHORT, + TPM_SHORT, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 105 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 110 */ + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, /* 115 */ + TPM_SHORT, + TPM_SHORT, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_LONG, /* 120 */ + TPM_LONG, + TPM_MEDIUM, + TPM_UNDEFINED, + TPM_SHORT, + TPM_SHORT, /* 125 */ + TPM_SHORT, + TPM_LONG, + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, /* 130 */ + TPM_MEDIUM, + TPM_UNDEFINED, + TPM_SHORT, + TPM_MEDIUM, + TPM_UNDEFINED, /* 135 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 140 */ + TPM_SHORT, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 145 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 150 */ + TPM_MEDIUM, + TPM_MEDIUM, + TPM_SHORT, + TPM_SHORT, + TPM_UNDEFINED, /* 155 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 160 */ + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 165 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_LONG, /* 170 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 175 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_MEDIUM, /* 180 */ + TPM_SHORT, + TPM_MEDIUM, + TPM_MEDIUM, + TPM_MEDIUM, + TPM_MEDIUM, /* 185 */ + TPM_SHORT, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 190 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 195 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 200 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, + TPM_SHORT, /* 205 */ + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_MEDIUM, /* 210 */ + TPM_UNDEFINED, + TPM_MEDIUM, + TPM_MEDIUM, + TPM_MEDIUM, + TPM_UNDEFINED, /* 215 */ + TPM_MEDIUM, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, + TPM_SHORT, /* 220 */ + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_UNDEFINED, /* 225 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 230 */ + TPM_LONG, + TPM_MEDIUM, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 235 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 240 */ + TPM_UNDEFINED, + TPM_MEDIUM, +}; + +const struct tpm_input_header tpm_getcap_header = { + .tag = TPM_TAG_RQU_COMMAND, + .length = cpu_to_be32(22), + .ordinal = TPM_ORD_GET_CAP +}; + + +enum tis_access { + TPM_ACCESS_VALID = 0x80, + TPM_ACCESS_ACTIVE_LOCALITY = 0x20, /* (R) */ + TPM_ACCESS_RELINQUISH_LOCALITY = 0x20,/* (W) */ + TPM_ACCESS_REQUEST_PENDING = 0x04, /* (W) */ + TPM_ACCESS_REQUEST_USE = 0x02, /* (W) */ +}; + +enum tis_status { + TPM_STS_VALID = 0x80, /* (R) */ + TPM_STS_COMMAND_READY = 0x40, /* (R) */ + TPM_STS_DATA_AVAIL = 0x10, /* (R) */ + TPM_STS_DATA_EXPECT = 0x08, /* (R) */ + TPM_STS_GO = 0x20, /* (W) */ +}; + +enum tis_int_flags { + TPM_GLOBAL_INT_ENABLE = 0x80000000, + TPM_INTF_BURST_COUNT_STATIC = 0x100, + TPM_INTF_CMD_READY_INT = 0x080, + TPM_INTF_INT_EDGE_FALLING = 0x040, + TPM_INTF_INT_EDGE_RISING = 0x020, + TPM_INTF_INT_LEVEL_LOW = 0x010, + TPM_INTF_INT_LEVEL_HIGH = 0x008, + TPM_INTF_LOCALITY_CHANGE_INT = 0x004, + TPM_INTF_STS_VALID_INT = 0x002, + TPM_INTF_DATA_AVAIL_INT = 0x001, +}; + +enum tis_defaults { + TIS_MEM_BASE = 0xFED40000, + TIS_MEM_LEN = 0x5000, + TIS_SHORT_TIMEOUT = 750, /*ms*/ + TIS_LONG_TIMEOUT = 2000, /*2 sec */ +}; + +#define TPM_TIMEOUT 5 + +#define TPM_ACCESS(t, l) (((uint8_t*)t->pages[l]) + 0x0000) +#define TPM_INT_ENABLE(t, l) ((uint32_t*)(((uint8_t*)t->pages[l]) + 0x0008)) +#define TPM_INT_VECTOR(t, l) (((uint8_t*)t->pages[l]) + 0x000C) +#define TPM_INT_STATUS(t, l) (((uint8_t*)t->pages[l]) + 0x0010) +#define TPM_INTF_CAPS(t, l) ((uint32_t*)(((uint8_t*)t->pages[l]) + 0x0014)) +#define TPM_STS(t, l) ((uint8_t*)(((uint8_t*)t->pages[l]) + 0x0018)) +#define TPM_DATA_FIFO(t, l) (((uint8_t*)t->pages[l]) + 0x0024) + +#define TPM_DID_VID(t, l) ((uint32_t*)(((uint8_t*)t->pages[l]) + 0x0F00)) +#define TPM_RID(t, l) (((uint8_t*)t->pages[l]) + 0x0F04) + +struct tpm_chip { + int enabled_localities; + int locality; + unsigned long baseaddr; + uint8_t* pages[5]; + int did, vid, rid; + + uint8_t data_buffer[TPM_BUFSIZE]; + int data_len; + + s_time_t timeout_a, timeout_b, timeout_c, timeout_d; + s_time_t duration[3]; + +#ifdef HAVE_LIBC + int fd; +#endif + + unsigned int irq; + struct wait_queue_head read_queue; + struct wait_queue_head int_queue; +}; + + +static void __init_tpm_chip(struct tpm_chip* tpm) { + tpm->enabled_localities = TPM_TIS_EN_LOCLALL; + tpm->locality = -1; + tpm->baseaddr = 0; + tpm->pages[0] = tpm->pages[1] = tpm->pages[2] = tpm->pages[3] = tpm->pages[4] = NULL; + tpm->vid = 0; + tpm->did = 0; + tpm->irq = 0; + init_waitqueue_head(&tpm->read_queue); + init_waitqueue_head(&tpm->int_queue); + + tpm->data_len = -1; + +#ifdef HAVE_LIBC + tpm->fd = -1; +#endif +} + +/* + * Returns max number of nsecs to wait + */ +s_time_t tpm_calc_ordinal_duration(struct tpm_chip *chip, + uint32_t ordinal) +{ + int duration_idx = TPM_UNDEFINED; + s_time_t duration = 0; + + if (ordinal < TPM_MAX_ORDINAL) + duration_idx = tpm_ordinal_duration[ordinal]; + else if ((ordinal & TPM_PROTECTED_ORDINAL_MASK) < + TPM_MAX_PROTECTED_ORDINAL) + duration_idx = + tpm_protected_ordinal_duration[ordinal & + TPM_PROTECTED_ORDINAL_MASK]; + + if (duration_idx != TPM_UNDEFINED) { + duration = chip->duration[duration_idx]; + } + + if (duration <= 0) { + return SECONDS(120); + } + else + { + return duration; + } +} + + +static int locality_enabled(struct tpm_chip* tpm, int l) { + return tpm->enabled_localities & (1 << l); +} + +static int check_locality(struct tpm_chip* tpm, int l) { + if(locality_enabled(tpm, l) && (ioread8(TPM_ACCESS(tpm, l)) & + (TPM_ACCESS_ACTIVE_LOCALITY | TPM_ACCESS_VALID)) == + (TPM_ACCESS_ACTIVE_LOCALITY | TPM_ACCESS_VALID)) { + return l; + } + return -1; +} + +void release_locality(struct tpm_chip* tpm, int l, int force) +{ + if (locality_enabled(tpm, l) && (force || (ioread8(TPM_ACCESS(tpm, l)) & + (TPM_ACCESS_REQUEST_PENDING | TPM_ACCESS_VALID)) == + (TPM_ACCESS_REQUEST_PENDING | TPM_ACCESS_VALID))) { + iowrite8(TPM_ACCESS(tpm, l), TPM_ACCESS_RELINQUISH_LOCALITY); + } +} + +int tpm_tis_request_locality(struct tpm_chip* tpm, int l) { + + s_time_t stop; + /*Make sure locality is valid */ + if(!locality_enabled(tpm, l)) { + printk("tpm_tis_change_locality() Tried to change to locality %d, but it is disabled or invalid!\n", l); + return -1; + } + /* Check if we already have the current locality */ + if(check_locality(tpm, l) >= 0) { + return tpm->locality = l; + } + /* Set the new locality*/ + iowrite8(TPM_ACCESS(tpm, l), TPM_ACCESS_REQUEST_USE); + + if(tpm->irq) { + /* Wait for interrupt */ + wait_event_deadline(tpm->int_queue, (check_locality(tpm, l) >= 0), NOW() + tpm->timeout_a); + + /* FIXME: Handle timeout event, should return error in that case */ + return l; + } else { + /* Wait for burstcount */ + stop = NOW() + tpm->timeout_a; + do { + if(check_locality(tpm, l) >= 0) { + return tpm->locality = l; + } + msleep(TPM_TIMEOUT); + } while(NOW() < stop); + } + + printk("REQ LOCALITY FAILURE\n"); + return -1; +} + +static uint8_t tpm_tis_status(struct tpm_chip* tpm) { + return ioread8(TPM_STS(tpm, tpm->locality)); +} + +/* This causes the current command to be aborted */ +static void tpm_tis_ready(struct tpm_chip* tpm) { + iowrite8(TPM_STS(tpm, tpm->locality), TPM_STS_COMMAND_READY); +} +#define tpm_tis_cancel_cmd(v) tpm_tis_ready(v) + +static int get_burstcount(struct tpm_chip* tpm) { + s_time_t stop; + int burstcnt; + + stop = NOW() + tpm->timeout_d; + do { + burstcnt = ioread8((TPM_STS(tpm, tpm->locality) + 1)); + burstcnt += ioread8(TPM_STS(tpm, tpm->locality) + 2) << 8; + + if (burstcnt) { + return burstcnt; + } + msleep(TPM_TIMEOUT); + } while(NOW() < stop); + return -EBUSY; +} + +static int wait_for_stat(struct tpm_chip* tpm, uint8_t mask, + unsigned long timeout, struct wait_queue_head* queue) { + s_time_t stop; + uint8_t status; + + status = tpm_tis_status(tpm); + if((status & mask) == mask) { + return 0; + } + + if(tpm->irq) { + wait_event_deadline(*queue, ((tpm_tis_status(tpm) & mask) == mask), timeout); + /* FIXME: Check for timeout and return -ETIME */ + return 0; + } else { + stop = NOW() + timeout; + do { + msleep(TPM_TIMEOUT); + status = tpm_tis_status(tpm); + if((status & mask) == mask) + return 0; + } while( NOW() < stop); + } + return -ETIME; +} + +static int recv_data(struct tpm_chip* tpm, uint8_t* buf, size_t count) { + int size = 0; + int burstcnt; + while( size < count && + wait_for_stat(tpm, + TPM_STS_DATA_AVAIL | TPM_STS_VALID, + tpm->timeout_c, + &tpm->read_queue) + == 0) { + burstcnt = get_burstcount(tpm); + for(; burstcnt > 0 && size < count; --burstcnt) + { + buf[size++] = ioread8(TPM_DATA_FIFO(tpm, tpm->locality)); + } + } + return size; +} + +int tpm_tis_recv(struct tpm_chip* tpm, uint8_t* buf, size_t count) { + int size = 0; + int expected, status; + + if (count < TPM_HEADER_SIZE) { + size = -EIO; + goto out; + } + + /* read first 10 bytes, including tag, paramsize, and result */ + if((size = + recv_data(tpm, buf, TPM_HEADER_SIZE)) < TPM_HEADER_SIZE) { + printk("Error reading tpm cmd header\n"); + goto out; + } + + expected = be32_to_cpu(*((uint32_t*)(buf + 2))); + if(expected > count) { + size = -EIO; + goto out; + } + + if((size += recv_data(tpm, & buf[TPM_HEADER_SIZE], + expected - TPM_HEADER_SIZE)) < expected) { + printk("Unable to read rest of tpm command size=%d expected=%d\n", size, expected); + size = -ETIME; + goto out; + } + + wait_for_stat(tpm, TPM_STS_VALID, tpm->timeout_c, &tpm->int_queue); + status = tpm_tis_status(tpm); + if(status & TPM_STS_DATA_AVAIL) { + printk("Error: left over data\n"); + size = -EIO; + goto out; + } + +out: + tpm_tis_ready(tpm); + release_locality(tpm, tpm->locality, 0); + return size; +} +int tpm_tis_send(struct tpm_chip* tpm, uint8_t* buf, size_t len) { + int rc; + int status, burstcnt = 0; + int count = 0; + uint32_t ordinal; + + if(tpm_tis_request_locality(tpm, tpm->locality) < 0) { + return -EBUSY; + } + + status = tpm_tis_status(tpm); + if((status & TPM_STS_COMMAND_READY) == 0) { + tpm_tis_ready(tpm); + if(wait_for_stat(tpm, TPM_STS_COMMAND_READY, tpm->timeout_b, &tpm->int_queue) < 0) { + rc = -ETIME; + goto out_err; + } + } + + while(count < len - 1) { + burstcnt = get_burstcount(tpm); + for(;burstcnt > 0 && count < len -1; --burstcnt) { + iowrite8(TPM_DATA_FIFO(tpm, tpm->locality), buf[count++]); + } + + wait_for_stat(tpm, TPM_STS_VALID, tpm->timeout_c, &tpm->int_queue); + status = tpm_tis_status(tpm); + if((status & TPM_STS_DATA_EXPECT) == 0) { + rc = -EIO; + goto out_err; + } + } + + /*Write last byte*/ + iowrite8(TPM_DATA_FIFO(tpm, tpm->locality), buf[count]); + wait_for_stat(tpm, TPM_STS_VALID, tpm->timeout_c, &tpm->read_queue); + status = tpm_tis_status(tpm); + if((status & TPM_STS_DATA_EXPECT) != 0) { + rc = -EIO; + goto out_err; + } + + /*go and do it*/ + iowrite8(TPM_STS(tpm, tpm->locality), TPM_STS_GO); + + if(tpm->irq) { + /*Wait for interrupt */ + ordinal = be32_to_cpu(*(buf + 6)); + if(wait_for_stat(tpm, + TPM_STS_DATA_AVAIL | TPM_STS_VALID, + tpm_calc_ordinal_duration(tpm, ordinal), + &tpm->read_queue) < 0) { + rc = -ETIME; + goto out_err; + } + } +#ifdef HAVE_LIBC + if(tpm->fd >= 0) { + files[tpm->fd].read = 0; + files[tpm->fd].tpm_tis.respgot = 0; + files[tpm->fd].tpm_tis.offset = 0; + } +#endif + return len; + +out_err: + tpm_tis_ready(tpm); + release_locality(tpm, tpm->locality, 0); + return rc; +} + +static void tpm_tis_irq_handler(evtchn_port_t port, struct pt_regs *regs, void* data) +{ + struct tpm_chip* tpm = data; + uint32_t interrupt; + int i; + + interrupt = ioread32(TPM_INT_STATUS(tpm, tpm->locality)); + if(interrupt == 0) { + return; + } + + if(interrupt & TPM_INTF_DATA_AVAIL_INT) { + wake_up(&tpm->read_queue); + } + if(interrupt & TPM_INTF_LOCALITY_CHANGE_INT) { + for(i = 0; i < 5; ++i) { + if(check_locality(tpm, i) >= 0) { + break; + } + } + } + if(interrupt & (TPM_INTF_LOCALITY_CHANGE_INT | TPM_INTF_STS_VALID_INT | + TPM_INTF_CMD_READY_INT)) { + wake_up(&tpm->int_queue); + } + + /* Clear interrupts handled with TPM_EOI */ + iowrite32(TPM_INT_STATUS(tpm, tpm->locality), interrupt); + ioread32(TPM_INT_STATUS(tpm, tpm->locality)); + return; +} + +/* + * Internal kernel interface to transmit TPM commands + */ +static ssize_t tpm_transmit(struct tpm_chip *chip, const uint8_t *buf, + size_t bufsiz) +{ + ssize_t rc; + uint32_t count, ordinal; + s_time_t stop; + + count = be32_to_cpu(*((uint32_t *) (buf + 2))); + ordinal = be32_to_cpu(*((uint32_t *) (buf + 6))); + if (count == 0) + return -ENODATA; + if (count > bufsiz) { + printk("Error: invalid count value %x %zx \n", count, bufsiz); + return -E2BIG; + } + + //down(&chip->tpm_mutex); + + if ((rc = tpm_tis_send(chip, (uint8_t *) buf, count)) < 0) { + printk("tpm_transmit: tpm_send: error %zd\n", rc); + goto out; + } + + if (chip->irq) + goto out_recv; + + stop = NOW() + tpm_calc_ordinal_duration(chip, ordinal); + do { + uint8_t status = tpm_tis_status(chip); + if ((status & (TPM_STS_DATA_AVAIL | TPM_STS_VALID)) == + (TPM_STS_DATA_AVAIL | TPM_STS_VALID)) + goto out_recv; + + if ((status == TPM_STS_COMMAND_READY)) { + printk("TPM Error: Operation Canceled\n"); + rc = -ECANCELED; + goto out; + } + + msleep(TPM_TIMEOUT); /* CHECK */ + rmb(); + } while (NOW() < stop); + + /* Cancel the command */ + tpm_tis_cancel_cmd(chip); + printk("TPM Operation Timed out\n"); + rc = -ETIME; + goto out; + +out_recv: + if((rc = tpm_tis_recv(chip, (uint8_t *) buf, bufsiz)) < 0) { + printk("tpm_transmit: tpm_recv: error %d\n", rc); + } +out: + //up(&chip->tpm_mutex); + return rc; +} + +static ssize_t transmit_cmd(struct tpm_chip *chip, struct tpm_cmd_t *cmd, + int len, const char *desc) +{ + int err; + + len = tpm_transmit(chip,(uint8_t *) cmd, len); + if (len < 0) + return len; + if (len == TPM_ERROR_SIZE) { + err = be32_to_cpu(cmd->header.out.return_code); + printk("A TPM error (%d) occurred %s\n", err, desc); + return err; + } + return 0; +} + +void tpm_get_timeouts(struct tpm_chip *chip) +{ + struct tpm_cmd_t tpm_cmd; + struct timeout_t *timeout_cap; + struct duration_t *duration_cap; + ssize_t rc; + uint32_t timeout; + + tpm_cmd.header.in = tpm_getcap_header; + tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP; + tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4); + tpm_cmd.params.getcap_in.subcap = TPM_CAP_PROP_TIS_TIMEOUT; + + if((rc = transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE, + "attempting to determine the timeouts")) != 0) { + printk("transmit failed %d\n", rc); + goto duration; + } + + if (be32_to_cpu(tpm_cmd.params.getcap_out.cap_size) + != 4 * sizeof(uint32_t)) { + printk("Out len check failure %lu \n", be32_to_cpu(tpm_cmd.header.out.length)); + goto duration; + } + + timeout_cap = &tpm_cmd.params.getcap_out.cap.timeout; + /* Don't overwrite default if value is 0 */ + timeout = be32_to_cpu(timeout_cap->a); + if (timeout) + chip->timeout_a = MICROSECS(timeout); /*Convert to msec */ + timeout = be32_to_cpu(timeout_cap->b); + if (timeout) + chip->timeout_b = MICROSECS(timeout); /*Convert to msec */ + timeout = be32_to_cpu(timeout_cap->c); + if (timeout) + chip->timeout_c = MICROSECS(timeout); /*Convert to msec */ + timeout = be32_to_cpu(timeout_cap->d); + if (timeout) + chip->timeout_d = MICROSECS(timeout); /*Convert to msec */ + +duration: + tpm_cmd.header.in = tpm_getcap_header; + tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP; + tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4); + tpm_cmd.params.getcap_in.subcap = TPM_CAP_PROP_TIS_DURATION; + + if((rc = transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE, + "attempting to determine the durations")) < 0) { + return; + } + + if (be32_to_cpu(tpm_cmd.params.getcap_out.cap_size) + != 3 * sizeof(uint32_t)) { + return; + } + duration_cap = &tpm_cmd.params.getcap_out.cap.duration; + chip->duration[TPM_SHORT] = be32_to_cpu(duration_cap->tpm_short); + /* The Broadcom BCM0102 chipset in a Dell Latitude D820 gets the above + * value wrong and apparently reports msecs rather than usecs. So we + * fix up the resulting too-small TPM_SHORT value to make things work. + */ + if (chip->duration[TPM_SHORT] < 10) { + chip->duration[TPM_SHORT] = MILLISECS(chip->duration[TPM_SHORT]); + } else { + chip->duration[TPM_SHORT] = MICROSECS(chip->duration[TPM_SHORT]); + } + + chip->duration[TPM_MEDIUM] = MICROSECS(be32_to_cpu(duration_cap->tpm_medium)); + chip->duration[TPM_LONG] = MICROSECS(be32_to_cpu(duration_cap->tpm_long)); +} + + + +void tpm_continue_selftest(struct tpm_chip* chip) { + uint8_t data[] = { + 0, 193, /* TPM_TAG_RQU_COMMAND */ + 0, 0, 0, 10, /* length */ + 0, 0, 0, 83, /* TPM_ORD_GetCapability */ + }; + + tpm_transmit(chip, data, sizeof(data)); +} + +ssize_t tpm_getcap(struct tpm_chip *chip, uint32_t subcap_id, cap_t *cap, + const char *desc) +{ + struct tpm_cmd_t tpm_cmd; + int rc; + + tpm_cmd.header.in = tpm_getcap_header; + if (subcap_id == CAP_VERSION_1_1 || subcap_id == CAP_VERSION_1_2) { + tpm_cmd.params.getcap_in.cap = subcap_id; + /*subcap field not necessary */ + tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(0); + tpm_cmd.header.in.length -= cpu_to_be32(sizeof(uint32_t)); + } else { + if (subcap_id == TPM_CAP_FLAG_PERM || + subcap_id == TPM_CAP_FLAG_VOL) + tpm_cmd.params.getcap_in.cap = TPM_CAP_FLAG; + else + tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP; + tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4); + tpm_cmd.params.getcap_in.subcap = subcap_id; + } + rc = transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE, desc); + if (!rc) + *cap = tpm_cmd.params.getcap_out.cap; + return rc; +} + + +struct tpm_chip* init_tpm_tis(unsigned long baseaddr, int localities, unsigned int irq) +{ + int i; + unsigned long addr; + struct tpm_chip* tpm = NULL; + uint32_t didvid; + uint32_t intfcaps; + uint32_t intmask; + + printk("============= Init TPM TIS Driver ==============\n"); + + /*Sanity check the localities input */ + if(localities & ~TPM_TIS_EN_LOCLALL) { + printk("init_tpm_tis() Invalid locality specification! %X\n", localities); + goto abort_egress; + } + + printk("IOMEM Machine Base Address: %lX\n", baseaddr); + + /* Create the tpm data structure */ + tpm = malloc(sizeof(struct tpm_chip)); + __init_tpm_chip(tpm); + + /* Set the enabled localities - if 0 we leave default as all enabled */ + if(localities != 0) { + tpm->enabled_localities = localities; + } + printk("Enabled Localities: "); + for(i = 0; i < 5; ++i) { + if(locality_enabled(tpm, i)) { + printk("%d ", i); + } + } + printk("\n"); + + /* Set the base machine address */ + tpm->baseaddr = baseaddr; + + /* Set default timeouts */ + tpm->timeout_a = MILLISECS(TIS_SHORT_TIMEOUT); + tpm->timeout_b = MILLISECS(TIS_LONG_TIMEOUT); + tpm->timeout_c = MILLISECS(TIS_SHORT_TIMEOUT); + tpm->timeout_d = MILLISECS(TIS_SHORT_TIMEOUT); + + /*Map the mmio pages */ + addr = tpm->baseaddr; + for(i = 0; i < 5; ++i) { + if(locality_enabled(tpm, i)) { + /* Map the page in now */ + if((tpm->pages[i] = ioremap_nocache(addr, PAGE_SIZE)) == NULL) { + printk("Unable to map iomem page a address %p\n", addr); + goto abort_egress; + } + + /* Set default locality to the first enabled one */ + if (tpm->locality < 0) { + if(tpm_tis_request_locality(tpm, i) < 0) { + printk("Unable to request locality %d??\n", i); + goto abort_egress; + } + } + } + addr += PAGE_SIZE; + } + + + /* Get the vendor and device ids */ + didvid = ioread32(TPM_DID_VID(tpm, tpm->locality)); + tpm->did = didvid >> 16; + tpm->vid = didvid & 0xFFFF; + + + /* Get the revision id */ + tpm->rid = ioread8(TPM_RID(tpm, tpm->locality)); + + printk("1.2 TPM (device-id=0x%X vendor-id = %X rev-id = %X)\n", tpm->did, tpm->vid, tpm->rid); + + intfcaps = ioread32(TPM_INTF_CAPS(tpm, tpm->locality)); + printk("TPM interface capabilities (0x%x):\n", intfcaps); + if (intfcaps & TPM_INTF_BURST_COUNT_STATIC) + printk("\tBurst Count Static\n"); + if (intfcaps & TPM_INTF_CMD_READY_INT) + printk("\tCommand Ready Int Support\n"); + if (intfcaps & TPM_INTF_INT_EDGE_FALLING) + printk("\tInterrupt Edge Falling\n"); + if (intfcaps & TPM_INTF_INT_EDGE_RISING) + printk("\tInterrupt Edge Rising\n"); + if (intfcaps & TPM_INTF_INT_LEVEL_LOW) + printk("\tInterrupt Level Low\n"); + if (intfcaps & TPM_INTF_INT_LEVEL_HIGH) + printk("\tInterrupt Level High\n"); + if (intfcaps & TPM_INTF_LOCALITY_CHANGE_INT) + printk("\tLocality Change Int Support\n"); + if (intfcaps & TPM_INTF_STS_VALID_INT) + printk("\tSts Valid Int Support\n"); + if (intfcaps & TPM_INTF_DATA_AVAIL_INT) + printk("\tData Avail Int Support\n"); + + /*Interupt setup */ + intmask = ioread32(TPM_INT_ENABLE(tpm, tpm->locality)); + + intmask |= TPM_INTF_CMD_READY_INT + | TPM_INTF_LOCALITY_CHANGE_INT | TPM_INTF_DATA_AVAIL_INT + | TPM_INTF_STS_VALID_INT; + + iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), intmask); + + /*If interupts are enabled, handle it */ + if(irq) { + if(irq != TPM_PROBE_IRQ) { + tpm->irq = irq; + } else { + /*FIXME add irq probing feature later */ + printk("IRQ probing not implemented\n"); + } + } + + if(tpm->irq) { + iowrite8(TPM_INT_VECTOR(tpm, tpm->locality), tpm->irq); + + if(bind_pirq(tpm->irq, 1, tpm_tis_irq_handler, tpm) != 0) { + printk("Unabled to request irq: %u for use\n", tpm->irq); + printk("Will use polling mode\n"); + tpm->irq = 0; + } else { + /* Clear all existing */ + iowrite32(TPM_INT_STATUS(tpm, tpm->locality), ioread32(TPM_INT_STATUS(tpm, tpm->locality))); + + /* Turn on interrupts */ + iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), intmask | TPM_GLOBAL_INT_ENABLE); + } + } + + tpm_get_timeouts(tpm); + tpm_continue_selftest(tpm); + + + return tpm; +abort_egress: + if(tpm != NULL) { + shutdown_tpm_tis(tpm); + } + return NULL; +} + +void shutdown_tpm_tis(struct tpm_chip* tpm){ + int i; + + printk("Shutting down tpm_tis device\n"); + + iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), ~TPM_GLOBAL_INT_ENABLE); + + /*Unmap all of the mmio pages */ + for(i = 0; i < 5; ++i) { + if(tpm->pages[i] != NULL) { + iounmap(tpm->pages[i], PAGE_SIZE); + tpm->pages[i] = NULL; + } + } + free(tpm); + return; +} + + +int tpm_tis_cmd(struct tpm_chip* tpm, uint8_t* req, size_t reqlen, uint8_t** resp, size_t* resplen) +{ + if(tpm->locality < 0) { + printk("tpm_tis_cmd() failed! locality not set!\n"); + return -1; + } + if(reqlen > TPM_BUFSIZE) { + reqlen = TPM_BUFSIZE; + } + memcpy(tpm->data_buffer, req, reqlen); + *resplen = tpm_transmit(tpm, tpm->data_buffer, TPM_BUFSIZE); + + *resp = malloc(*resplen); + memcpy(*resp, tpm->data_buffer, *resplen); + return 0; +} + +#ifdef HAVE_LIBC +int tpm_tis_open(struct tpm_chip* tpm) +{ + /* Silently prevent multiple opens */ + if(tpm->fd != -1) { + return tpm->fd; + } + + tpm->fd = alloc_fd(FTYPE_TPM_TIS); + printk("tpm_tis_open() -> %d\n", tpm->fd); + files[tpm->fd].tpm_tis.dev = tpm; + files[tpm->fd].tpm_tis.offset = 0; + files[tpm->fd].tpm_tis.respgot = 0; + return tpm->fd; +} + +int tpm_tis_posix_write(int fd, const uint8_t* buf, size_t count) +{ + struct tpm_chip* tpm; + tpm = files[fd].tpm_tis.dev; + + if(tpm->locality < 0) { + printk("tpm_tis_posix_write() failed! locality not set!\n"); + errno = EINPROGRESS; + return -1; + } + if(count == 0) { + return 0; + } + + /* Return an error if we are already processing a command */ + if(count > TPM_BUFSIZE) { + count = TPM_BUFSIZE; + } + /* Send the command now */ + memcpy(tpm->data_buffer, buf, count); + if((tpm->data_len = tpm_transmit(tpm, tpm->data_buffer, TPM_BUFSIZE)) < 0) { + errno = EIO; + return -1; + } + return count; +} + +int tpm_tis_posix_read(int fd, uint8_t* buf, size_t count) +{ + int rc; + struct tpm_chip* tpm; + tpm = files[fd].tpm_tis.dev; + + if(count == 0) { + return 0; + } + + /* If there is no tpm resp to read, return EIO */ + if(tpm->data_len < 0) { + errno = EIO; + return -1; + } + + + /* Handle EOF case */ + if(files[fd].tpm_tis.offset >= tpm->data_len) { + rc = 0; + } else { + rc = min(tpm->data_len - files[fd].tpm_tis.offset, count); + memcpy(buf, tpm->data_buffer + files[fd].tpm_tis.offset, rc); + } + files[fd].tpm_tis.offset += rc; + /* Reset the data pending flag */ + return rc; +} +int tpm_tis_posix_fstat(int fd, struct stat* buf) +{ + struct tpm_chip* tpm; + tpm = files[fd].tpm_tis.dev; + + buf->st_mode = O_RDWR; + buf->st_uid = 0; + buf->st_gid = 0; + buf->st_size = be32_to_cpu(*((uint32_t*)(tpm->data_buffer + 2))); + buf->st_atime = buf->st_mtime = buf->st_ctime = time(NULL); + return 0; +} + + +#endif diff --git a/extras/mini-os/tpmback.c b/extras/mini-os/tpmback.c new file mode 100644 index 0000000..b6ae2e6 --- /dev/null +++ b/extras/mini-os/tpmback.c @@ -0,0 +1,1128 @@ +/* + * Copyright (c) 2010-2012 United States Government, as represented by + * the Secretary of Defense. All rights reserved. + * + * This code has been derived from drivers/xen/tpmback/tpmback.c + * from the xen 2.6.18 linux kernel + * + * Copyright (c) 2005, IBM Corporation + * + * which was itself derived from drivers/xen/netback/netback.c + * from the xen 2.6.18 linux kernel + * + * Copyright (c) 2002-2004, K A Fraser + * + * This code has also been derived from drivers/xen/tpmback/xenbus.c + * from the xen 2.6.18 linux kernel + * + * Copyright (C) 2005 IBM Corporation + * Copyright (C) 2005 Rusty Russell + * + * This code has also been derived from drivers/xen/tpmback/interface.c + * from the xen 2.6.18 linux kernel + * + * Copyright (c) 2005, IBM Corporation + * + * which was itself also derived from drvivers/xen/netback/interface.c + * from the xen 2.6.18 linux kernel + * + * Copyright (c) 2004, Keir Fraser + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation, version 2 + * of the License + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + + +#ifndef HAVE_LIBC +#define strtoul simple_strtoul +#endif + +//#define TPMBACK_PRINT_DEBUG +#ifdef TPMBACK_PRINT_DEBUG +#define TPMBACK_DEBUG(fmt,...) printk("Tpmback:Debug("__FILE__":%d) " fmt, __LINE__, ##__VA_ARGS__) +#define TPMBACK_DEBUG_MORE(fmt,...) printk(fmt, ##__VA_ARGS__) +#else +#define TPMBACK_DEBUG(fmt,...) +#endif +#define TPMBACK_ERR(fmt,...) printk("Tpmback:Error " fmt, ##__VA_ARGS__) +#define TPMBACK_LOG(fmt,...) printk("Tpmback:Info " fmt, ##__VA_ARGS__) + +#define min(a,b) (((a) < (b)) ? (a) : (b)) + +/* Default size of the tpmif array at initialization */ +#define DEF_ARRAY_SIZE 1 + +/* tpmif and tpmdev flags */ +#define TPMIF_CLOSED 1 +#define TPMIF_REQ_READY 2 + +struct tpmif { + domid_t domid; + unsigned int handle; + + char* fe_path; + char* fe_state_path; + + /* Locally bound event channel*/ + evtchn_port_t evtchn; + + /* Shared page */ + tpmif_tx_interface_t* tx; + + /* pointer to TPMIF_RX_RING_SIZE pages */ + void** pages; + + enum xenbus_state state; + enum { DISCONNECTED, DISCONNECTING, CONNECTED } status; + + char* uuid; + + /* state flags */ + int flags; +}; +typedef struct tpmif tpmif_t; + +struct tpmback_dev { + + tpmif_t** tpmlist; + unsigned long num_tpms; + unsigned long num_alloc; + + struct gntmap map; + + /* True if at least one tpmif has a request to be handled */ + int flags; + + /* exclusive domains, see init_tpmback comment in tpmback.h */ + char** exclusive_uuids; + + xenbus_event_queue events; + + /* Callbacks */ + void (*open_callback)(domid_t, unsigned int); + void (*close_callback)(domid_t, unsigned int); + void (*suspend_callback)(domid_t, unsigned int); + void (*resume_callback)(domid_t, unsigned int); +}; +typedef struct tpmback_dev tpmback_dev_t; + +enum { EV_NONE, EV_NEWFE, EV_STCHNG } tpm_ev_enum; + +/* Global objects */ +static struct thread* eventthread = NULL; +static tpmback_dev_t gtpmdev = { + .tpmlist = NULL, + .num_tpms = 0, + .num_alloc = 0, + .flags = TPMIF_CLOSED, + .events = NULL, + .open_callback = NULL, + .close_callback = NULL, + .suspend_callback = NULL, + .resume_callback = NULL, +}; +struct wait_queue_head waitq; +int globalinit = 0; + +/************************************ + * TPMIF SORTED ARRAY FUNCTIONS + * tpmback_dev_t.tpmlist is a sorted array, sorted by domid and then handle number + * Duplicates are not allowed + * **********************************/ + +inline void tpmif_req_ready(tpmif_t* tpmif) { + tpmif->flags |= TPMIF_REQ_READY; + gtpmdev.flags |= TPMIF_REQ_READY; +} + +inline void tpmdev_check_req(void) { + int i; + int flags; + local_irq_save(flags); + for(i = 0; i < gtpmdev.num_tpms; ++i) { + if(gtpmdev.tpmlist[i]->flags & TPMIF_REQ_READY) { + gtpmdev.flags |= TPMIF_REQ_READY; + local_irq_restore(flags); + return; + } + } + gtpmdev.flags &= ~TPMIF_REQ_READY; + local_irq_restore(flags); +} + +inline void tpmif_req_finished(tpmif_t* tpmif) { + tpmif->flags &= ~TPMIF_REQ_READY; + tpmdev_check_req(); +} + +int __get_tpmif_index(int st, int n, domid_t domid, unsigned int handle) +{ + int i = st + n /2; + tpmif_t* tmp; + + if( n <= 0 ) + return -1; + + tmp = gtpmdev.tpmlist[i]; + if(domid == tmp->domid && tmp->handle == handle) { + return i; + } else if ( (domid < tmp->domid) || + (domid == tmp->domid && handle < tmp->handle)) { + return __get_tpmif_index(st, n/2, domid, handle); + } else { + return __get_tpmif_index(i + 1, n/2 - ((n +1) % 2), domid, handle); + } +} + +/* Returns the array index of the tpmif domid/handle. Returns -1 if no such tpmif exists */ +int get_tpmif_index(domid_t domid, unsigned int handle) +{ + int flags; + int index; + local_irq_save(flags); + index = __get_tpmif_index(0, gtpmdev.num_tpms, domid, handle); + local_irq_restore(flags); + return index; +} + +/* Returns the tpmif domid/handle or NULL if none exists */ +tpmif_t* get_tpmif(domid_t domid, unsigned int handle) +{ + int flags; + int i; + tpmif_t* ret; + local_irq_save(flags); + i = get_tpmif_index(domid, handle); + if (i < 0) { + ret = NULL; + } else { + ret = gtpmdev.tpmlist[i]; + } + local_irq_restore(flags); + return ret; +} + +/* Remove the given tpmif. Returns 0 if it was removed, -1 if it was not removed */ +int remove_tpmif(tpmif_t* tpmif) +{ + int i, j; + char* err; + int flags; + local_irq_save(flags); + + /* Find the index in the array if it exists */ + i = get_tpmif_index(tpmif->domid, tpmif->handle); + if (i < 0) { + goto error; + } + + /* Remove the interface from the list */ + for(j = i; j < gtpmdev.num_tpms - 1; ++j) { + gtpmdev.tpmlist[j] = gtpmdev.tpmlist[j+1]; + } + gtpmdev.tpmlist[j] = NULL; + --gtpmdev.num_tpms; + + /* If removed tpm was the only ready tpm, then we need to check and turn off the ready flag */ + tpmdev_check_req(); + + local_irq_restore(flags); + + /* Stop listening for events on this tpm interface */ + if((err = xenbus_unwatch_path_token(XBT_NIL, tpmif->fe_state_path, tpmif->fe_state_path))) { + TPMBACK_ERR("Unable to unwatch path token `%s' Error was %s Ignoring..\n", tpmif->fe_state_path, err); + free(err); + } + + return 0; +error: + local_irq_restore(flags); + return -1; +} + +/* Insert tpmif into dev->tpmlist. Returns 0 on success and non zero on error. + * It is an error to insert a tpmif with the same domid and handle + * number + * as something already in the list */ +int insert_tpmif(tpmif_t* tpmif) +{ + int flags; + unsigned int i, j; + tpmif_t* tmp; + char* err; + + local_irq_save(flags); + + /*Check if we need to allocate more space */ + if (gtpmdev.num_tpms == gtpmdev.num_alloc) { + gtpmdev.num_alloc *= 2; + gtpmdev.tpmlist = realloc(gtpmdev.tpmlist, gtpmdev.num_alloc); + } + + /*Find where to put the new interface */ + for(i = 0; i < gtpmdev.num_tpms; ++i) + { + tmp = gtpmdev.tpmlist[i]; + if(tpmif->domid == tmp->domid && tpmif->handle == tmp->handle) { + TPMBACK_ERR("Tried to insert duplicate tpm interface %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle); + goto error; + } + if((tpmif->domid < tmp->domid) || + (tpmif->domid == tmp->domid && tpmif->handle < tmp->handle)) { + break; + } + } + + /*Shift all the tpm pointers past i down one */ + for(j = gtpmdev.num_tpms; j > i; --j) { + gtpmdev.tpmlist[j] = gtpmdev.tpmlist[j-1]; + } + + /*Add the new interface */ + gtpmdev.tpmlist[i] = tpmif; + ++gtpmdev.num_tpms; + + /*Should not be needed, anything inserted with ready flag is probably an error */ + tpmdev_check_req(); + + local_irq_restore(flags); + + /*Listen for state changes on the new interface */ + if((err = xenbus_watch_path_token(XBT_NIL, tpmif->fe_state_path, tpmif->fe_state_path, >pmdev.events))) + { + /* if we got an error here we should carefully remove the interface and then return */ + TPMBACK_ERR("Unable to watch path token `%s' Error was %s\n", tpmif->fe_state_path, err); + free(err); + remove_tpmif(tpmif); + goto error_post_irq; + } + + return 0; +error: + local_irq_restore(flags); +error_post_irq: + return -1; +} + + +/***************** + * CHANGE BACKEND STATE + * *****************/ +/*Attempts to change the backend state in xenstore + * returns 0 on success and non-zero on error */ +int tpmif_change_state(tpmif_t* tpmif, enum xenbus_state state) +{ + char path[512]; + char *value; + char *err; + enum xenbus_state readst; + TPMBACK_DEBUG("Backend state change %u/%u from=%d to=%d\n", (unsigned int) tpmif->domid, tpmif->handle, tpmif->state, state); + if (tpmif->state == state) + return 0; + + snprintf(path, 512, "backend/vtpm/%u/%u/state", (unsigned int) tpmif->domid, tpmif->handle); + + if((err = xenbus_read(XBT_NIL, path, &value))) { + TPMBACK_ERR("Unable to read backend state %s, error was %s\n", path, err); + free(err); + return -1; + } + if(sscanf(value, "%d", &readst) != 1) { + TPMBACK_ERR("Non integer value (%s) in %s ??\n", value, path); + free(value); + return -1; + } + free(value); + + /* It's possible that the backend state got updated by hotplug or something else behind our back */ + if(readst != tpmif->state) { + TPMBACK_DEBUG("tpm interface state was %d but xenstore state was %d!\n", tpmif->state, readst); + tpmif->state = readst; + } + + /*If if the state isnt changing, then we dont update xenstore b/c we dont want to fire extraneous events */ + if(tpmif->state == state) { + return 0; + } + + /*update xenstore*/ + snprintf(path, 512, "backend/vtpm/%u/%u", (unsigned int) tpmif->domid, tpmif->handle); + if((err = xenbus_printf(XBT_NIL, path, "state", "%u", state))) { + TPMBACK_ERR("Error writing to xenstore %s, error was %s new state=%d\n", path, err, state); + free(err); + return -1; + } + + tpmif->state = state; + + return 0; +} +/********************************** + * TPMIF CREATION AND DELETION + * *******************************/ +inline tpmif_t* __init_tpmif(domid_t domid, unsigned int handle) +{ + tpmif_t* tpmif; + tpmif = malloc(sizeof(*tpmif)); + tpmif->domid = domid; + tpmif->handle = handle; + tpmif->fe_path = NULL; + tpmif->fe_state_path = NULL; + tpmif->state = XenbusStateInitialising; + tpmif->status = DISCONNECTED; + tpmif->tx = NULL; + tpmif->pages = NULL; + tpmif->flags = 0; + tpmif->uuid = NULL; + return tpmif; +} + +void __free_tpmif(tpmif_t* tpmif) +{ + if(tpmif->pages) { + free(tpmif->pages); + } + if(tpmif->fe_path) { + free(tpmif->fe_path); + } + if(tpmif->fe_state_path) { + free(tpmif->fe_state_path); + } + if(tpmif->uuid) { + free(tpmif->uuid); + } + free(tpmif); +} +/* Creates a new tpm interface, adds it to the sorted array and returns it. + * returns NULL on error + * If the tpm interface already exists, it is returned*/ +tpmif_t* new_tpmif(domid_t domid, unsigned int handle) +{ + tpmif_t* tpmif; + char* err; + char path[512]; + + /* Make sure we haven't already created this tpm + * Double events can occur */ + if((tpmif = get_tpmif(domid, handle)) != NULL) { + return tpmif; + } + + tpmif = __init_tpmif(domid, handle); + + /* Get the uuid from xenstore */ + snprintf(path, 512, "backend/vtpm/%u/%u/uuid", (unsigned int) domid, handle); + if((err = xenbus_read(XBT_NIL, path, &tpmif->uuid))) { + TPMBACK_ERR("Error reading %s, Error = %s\n", path, err); + free(err); + goto error; + } + + /* Do the exclusive uuid check now */ + if(gtpmdev.exclusive_uuids != NULL) { + char** ptr; + + /* Check that its in the whitelist */ + for(ptr = gtpmdev.exclusive_uuids; *ptr != NULL; ++ptr) { + if(!strcmp(tpmif->uuid, *ptr)) { + break; + } + } + /* If *ptr == NULL then we went through the whole list without a match, so close the connection */ + if(*ptr == NULL) { + tpmif_change_state(tpmif, XenbusStateClosed); + TPMBACK_ERR("Frontend %u/%u tried to connect with invalid uuid=%s\n", (unsigned int) domid, handle, tpmif->uuid); + goto error; + } + } + + /* allocate pages to be used for shared mapping */ + if((tpmif->pages = malloc(sizeof(void*) * TPMIF_TX_RING_SIZE)) == NULL) { + goto error; + } + memset(tpmif->pages, 0, sizeof(void*) * TPMIF_TX_RING_SIZE); + + if(tpmif_change_state(tpmif, XenbusStateInitWait)) { + goto error; + } + + snprintf(path, 512, "backend/vtpm/%u/%u/frontend", (unsigned int) domid, handle); + if((err = xenbus_read(XBT_NIL, path, &tpmif->fe_path))) { + TPMBACK_ERR("Error creating new tpm instance xenbus_read(%s), Error = %s", path, err); + free(err); + goto error; + } + + /*Set the state path */ + tpmif->fe_state_path = malloc(strlen(tpmif->fe_path) + 7); + strcpy(tpmif->fe_state_path, tpmif->fe_path); + strcat(tpmif->fe_state_path, "/state"); + + if(insert_tpmif(tpmif)) { + goto error; + } + TPMBACK_DEBUG("New tpmif %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle); + /* Do the callback now */ + if(gtpmdev.open_callback) { + gtpmdev.open_callback(tpmif->domid, tpmif->handle); + } + return tpmif; +error: + __free_tpmif(tpmif); + return NULL; + +} + +/* Removes tpmif from dev->tpmlist and frees it's memory usage */ +void free_tpmif(tpmif_t* tpmif) +{ + char* err; + char path[512]; + TPMBACK_DEBUG("Free tpmif %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle); + if(tpmif->flags & TPMIF_CLOSED) { + TPMBACK_ERR("Tried to free an instance twice! Theres a bug somewhere!\n"); + BUG(); + } + tpmif->flags = TPMIF_CLOSED; + + tpmif_change_state(tpmif, XenbusStateClosing); + + /* Unmap share page and unbind event channel */ + if(tpmif->status == CONNECTED) { + tpmif->status = DISCONNECTING; + mask_evtchn(tpmif->evtchn); + + if(gntmap_munmap(>pmdev.map, (unsigned long)tpmif->tx, 1)) { + TPMBACK_ERR("%u/%u Error occured while trying to unmap shared page\n", (unsigned int) tpmif->domid, tpmif->handle); + } + + unbind_evtchn(tpmif->evtchn); + } + tpmif->status = DISCONNECTED; + tpmif_change_state(tpmif, XenbusStateClosed); + + /* Do the callback now */ + if(gtpmdev.close_callback) { + gtpmdev.close_callback(tpmif->domid, tpmif->handle); + } + + /* remove from array */ + remove_tpmif(tpmif); + + /* Wake up anyone possibly waiting on this interface and let them exit */ + wake_up(&waitq); + schedule(); + + /* Remove the old xenbus entries */ + snprintf(path, 512, "backend/vtpm/%u/%u", (unsigned int) tpmif->domid, tpmif->handle); + if((err = xenbus_rm(XBT_NIL, path))) { + TPMBACK_ERR("Error cleaning up xenbus entries path=%s error=%s\n", path, err); + free(err); + } + + TPMBACK_LOG("Frontend %u/%u disconnected\n", (unsigned int) tpmif->domid, tpmif->handle); + + /* free memory */ + __free_tpmif(tpmif); + +} + +/********************** + * REMAINING TPMBACK FUNCTIONS + * ********************/ + +/*Event channel handler */ +void tpmback_handler(evtchn_port_t port, struct pt_regs *regs, void *data) +{ + tpmif_t* tpmif = (tpmif_t*) data; + tpmif_tx_request_t* tx = &tpmif->tx->ring[0].req; + /* Throw away 0 size events, these can trigger from event channel unmasking */ + if(tx->size == 0) + return; + + TPMBACK_DEBUG("EVENT CHANNEL FIRE %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle); + tpmif_req_ready(tpmif); + wake_up(&waitq); + +} + +/* Connect to frontend */ +int connect_fe(tpmif_t* tpmif) +{ + char path[512]; + char* err, *value; + uint32_t domid; + grant_ref_t ringref; + evtchn_port_t evtchn; + + /* If already connected then quit */ + if (tpmif->status == CONNECTED) { + TPMBACK_DEBUG("%u/%u tried to connect while it was already connected?\n", (unsigned int) tpmif->domid, tpmif->handle); + return 0; + } + + /* Fetch the grant reference */ + snprintf(path, 512, "%s/ring-ref", tpmif->fe_path); + if((err = xenbus_read(XBT_NIL, path, &value))) { + TPMBACK_ERR("Error creating new tpm instance xenbus_read(%s) Error = %s", path, err); + free(err); + return -1; + } + if(sscanf(value, "%d", &ringref) != 1) { + TPMBACK_ERR("Non integer value (%s) in %s ??\n", value, path); + free(value); + return -1; + } + free(value); + + + /* Fetch the event channel*/ + snprintf(path, 512, "%s/event-channel", tpmif->fe_path); + if((err = xenbus_read(XBT_NIL, path, &value))) { + TPMBACK_ERR("Error creating new tpm instance xenbus_read(%s) Error = %s", path, err); + free(err); + return -1; + } + if(sscanf(value, "%d", &evtchn) != 1) { + TPMBACK_ERR("Non integer value (%s) in %s ??\n", value, path); + free(value); + return -1; + } + free(value); + + domid = tpmif->domid; + if((tpmif->tx = gntmap_map_grant_refs(>pmdev.map, 1, &domid, 0, &ringref, PROT_READ | PROT_WRITE)) == NULL) { + TPMBACK_ERR("Failed to map grant reference %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle); + return -1; + } + memset(tpmif->tx, 0, PAGE_SIZE); + + /*Bind the event channel */ + if((evtchn_bind_interdomain(tpmif->domid, evtchn, tpmback_handler, tpmif, &tpmif->evtchn))) + { + TPMBACK_ERR("%u/%u Unable to bind to interdomain event channel!\n", (unsigned int) tpmif->domid, tpmif->handle); + goto error_post_map; + } + unmask_evtchn(tpmif->evtchn); + + /* Write the ready flag and change status to connected */ + snprintf(path, 512, "backend/vtpm/%u/%u", (unsigned int) tpmif->domid, tpmif->handle); + if((err = xenbus_printf(XBT_NIL, path, "ready", "%u", 1))) { + TPMBACK_ERR("%u/%u Unable to write ready flag on connect_fe()\n", (unsigned int) tpmif->domid, tpmif->handle); + free(err); + goto error_post_evtchn; + } + tpmif->status = CONNECTED; + if((tpmif_change_state(tpmif, XenbusStateConnected))){ + goto error_post_evtchn; + } + + TPMBACK_LOG("Frontend %u/%u connected\n", (unsigned int) tpmif->domid, tpmif->handle); + + return 0; +error_post_evtchn: + mask_evtchn(tpmif->evtchn); + unbind_evtchn(tpmif->evtchn); +error_post_map: + gntmap_munmap(>pmdev.map, (unsigned long)tpmif->tx, 1); + return -1; +} + +static int frontend_changed(tpmif_t* tpmif) +{ + int state = xenbus_read_integer(tpmif->fe_state_path); + if(state < 0) { + state = XenbusStateUnknown; + } + + TPMBACK_DEBUG("Frontend %u/%u state changed to %d\n", (unsigned int) tpmif->domid, tpmif->handle, state); + + switch (state) { + case XenbusStateInitialising: + case XenbusStateInitialised: + break; + + case XenbusStateConnected: + if(connect_fe(tpmif)) { + TPMBACK_ERR("Failed to connect to front end %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle); + tpmif_change_state(tpmif, XenbusStateClosed); + return -1; + } + break; + + case XenbusStateClosing: + tpmif_change_state(tpmif, XenbusStateClosing); + break; + + case XenbusStateUnknown: /* keep it here */ + case XenbusStateClosed: + free_tpmif(tpmif); + break; + + default: + TPMBACK_DEBUG("BAD STATE CHANGE %u/%u state = %d for tpmif\n", (unsigned int) tpmif->domid, tpmif->handle, state); + return -1; + } + return 0; +} + + +/* parses the string that comes out of xenbus_watch_wait_return. */ +static int parse_eventstr(const char* evstr, domid_t* domid, unsigned int* handle) +{ + int ret; + char cmd[40]; + char* err; + char* value; + unsigned int udomid = 0; + tpmif_t* tpmif; + /* First check for new frontends, this occurs when /backend/vtpm// gets created. Note we what the sscanf to fail on the last %s */ + if (sscanf(evstr, "backend/vtpm/%u/%u/%40s", &udomid, handle, cmd) == 2) { + *domid = udomid; + /* Make sure the entry exists, if this event triggers because the entry dissapeared then ignore it */ + if((err = xenbus_read(XBT_NIL, evstr, &value))) { + free(err); + return EV_NONE; + } + free(value); + /* Make sure the tpmif entry does not already exist, this should not happen */ + if((tpmif = get_tpmif(*domid, *handle)) != NULL) { + TPMBACK_DEBUG("Duplicate tpm entries! %u %u\n", tpmif->domid, tpmif->handle); + return EV_NONE; + } + return EV_NEWFE; + } else if((ret = sscanf(evstr, "/local/domain/%u/device/vtpm/%u/%40s", &udomid, handle, cmd)) == 3) { + *domid = udomid; + if (!strcmp(cmd, "state")) + return EV_STCHNG; + } + return EV_NONE; +} + +void handle_backend_event(char* evstr) { + tpmif_t* tpmif; + domid_t domid; + unsigned int handle; + int event; + + TPMBACK_DEBUG("Xenbus Event: %s\n", evstr); + + event = parse_eventstr(evstr, &domid, &handle); + + switch(event) { + case EV_NEWFE: + if(new_tpmif(domid, handle) == NULL) { + TPMBACK_ERR("Failed to create new tpm instance %u/%u\n", (unsigned int) domid, handle); + } + wake_up(&waitq); + break; + case EV_STCHNG: + if((tpmif = get_tpmif(domid, handle))) { + frontend_changed(tpmif); + } else { + TPMBACK_DEBUG("Event Received for non-existant tpm! instance=%u/%u xenbus_event=%s\n", (unsigned int) domid, handle, evstr); + } + break; + } +} + +/* Runs through the given path and creates events recursively + * for all of its children. + * @path - xenstore path to scan */ +static void generate_backend_events(const char* path) +{ + char* err; + int i, len; + char **dirs; + char *entry; + + if((err = xenbus_ls(XBT_NIL, path, &dirs)) != NULL) { + free(err); + return; + } + + for(i = 0; dirs[i] != NULL; ++i) { + len = strlen(path) + strlen(dirs[i]) + 2; + entry = malloc(len); + snprintf(entry, len, "%s/%s", path, dirs[i]); + + /* Generate and handle event for the entry itself */ + handle_backend_event(entry); + + /* Do children */ + generate_backend_events(entry); + + /* Cleanup */ + free(entry); + free(dirs[i]); + } + free(dirs); + return; +} + +char* tpmback_get_uuid(domid_t domid, unsigned int handle) +{ + tpmif_t* tpmif; + if((tpmif = get_tpmif(domid, handle)) == NULL) { + TPMBACK_DEBUG("get_uuid() failed, %u/%u is an invalid frontend\n", (unsigned int) domid, handle); + return NULL; + } + + return tpmif->uuid; +} + +void tpmback_set_open_callback(void (*cb)(domid_t, unsigned int)) +{ + gtpmdev.open_callback = cb; +} +void tpmback_set_close_callback(void (*cb)(domid_t, unsigned int)) +{ + gtpmdev.close_callback = cb; +} +void tpmback_set_suspend_callback(void (*cb)(domid_t, unsigned int)) +{ + gtpmdev.suspend_callback = cb; +} +void tpmback_set_resume_callback(void (*cb)(domid_t, unsigned int)) +{ + gtpmdev.resume_callback = cb; +} + +static void event_listener(void) +{ + const char* bepath = "backend/vtpm"; + char **path; + char* err; + + /* Setup the backend device watch */ + if((err = xenbus_watch_path_token(XBT_NIL, bepath, bepath, >pmdev.events)) != NULL) { + TPMBACK_ERR("xenbus_watch_path_token(%s) failed with error %s!\n", bepath, err); + free(err); + goto egress; + } + + /* Check for any frontends that connected before we set the watch. + * This is almost guaranteed to happen if both domains are started + * immediatly one after the other. + * We do this by manually generating events on everything in the backend + * path */ + generate_backend_events(bepath); + + /* Wait and listen for changes in frontend connections */ + while(1) { + path = xenbus_wait_for_watch_return(>pmdev.events); + + /*If quit flag was set then exit */ + if(gtpmdev.flags & TPMIF_CLOSED) { + TPMBACK_DEBUG("listener thread got quit event. Exiting..\n"); + free(path); + break; + } + handle_backend_event(*path); + free(path); + + } + + if((err = xenbus_unwatch_path_token(XBT_NIL, bepath, bepath)) != NULL) { + free(err); + } +egress: + return; +} + +void event_thread(void* p) { + event_listener(); +} + +void init_tpmback(char** exclusive_uuids) +{ + if(!globalinit) { + init_waitqueue_head(&waitq); + globalinit = 1; + } + printk("============= Init TPM BACK ================\n"); + gtpmdev.tpmlist = malloc(sizeof(tpmif_t*) * DEF_ARRAY_SIZE); + gtpmdev.num_alloc = DEF_ARRAY_SIZE; + gtpmdev.num_tpms = 0; + gtpmdev.flags = 0; + gtpmdev.exclusive_uuids = exclusive_uuids; + + gtpmdev.open_callback = gtpmdev.close_callback = NULL; + gtpmdev.suspend_callback = gtpmdev.resume_callback = NULL; + + eventthread = create_thread("tpmback-listener", event_thread, NULL); + +} + +void shutdown_tpmback(void) +{ + /* Disable callbacks */ + gtpmdev.open_callback = gtpmdev.close_callback = NULL; + gtpmdev.suspend_callback = gtpmdev.resume_callback = NULL; + + TPMBACK_LOG("Shutting down tpm backend\n"); + /* Set the quit flag */ + gtpmdev.flags = TPMIF_CLOSED; + + //printk("num tpms is %d\n", gtpmdev.num_tpms); + /*Free all backend instances */ + while(gtpmdev.num_tpms) { + free_tpmif(gtpmdev.tpmlist[0]); + } + free(gtpmdev.tpmlist); + gtpmdev.tpmlist = NULL; + gtpmdev.num_alloc = 0; + + /* Wake up anyone possibly waiting on the device and let them exit */ + wake_up(&waitq); + schedule(); +} + +inline void init_tpmcmd(tpmcmd_t* tpmcmd, domid_t domid, unsigned int handle, char* uuid) +{ + tpmcmd->domid = domid; + tpmcmd->handle = handle; + tpmcmd->uuid = uuid; + tpmcmd->req = NULL; + tpmcmd->req_len = 0; + tpmcmd->resp = NULL; + tpmcmd->resp_len = 0; +} + +tpmcmd_t* get_request(tpmif_t* tpmif) { + tpmcmd_t* cmd; + tpmif_tx_request_t* tx; + int offset; + int tocopy; + int i; + uint32_t domid; + int flags; + + local_irq_save(flags); + + /* Allocate the cmd object to hold the data */ + if((cmd = malloc(sizeof(*cmd))) == NULL) { + goto error; + } + init_tpmcmd(cmd, tpmif->domid, tpmif->handle, tpmif->uuid); + + tx = &tpmif->tx->ring[0].req; + cmd->req_len = tx->size; + /* Allocate the buffer */ + if(cmd->req_len) { + if((cmd->req = malloc(cmd->req_len)) == NULL) { + goto error; + } + } + /* Copy the bits from the shared pages */ + offset = 0; + for(i = 0; i < TPMIF_TX_RING_SIZE && offset < cmd->req_len; ++i) { + tx = &tpmif->tx->ring[i].req; + + /* Map the page with the data */ + domid = (uint32_t)tpmif->domid; + if((tpmif->pages[i] = gntmap_map_grant_refs(>pmdev.map, 1, &domid, 0, &tx->ref, PROT_READ)) == NULL) { + TPMBACK_ERR("%u/%u Unable to map shared page during read!\n", (unsigned int) tpmif->domid, tpmif->handle); + goto error; + } + + /* do the copy now */ + tocopy = min(cmd->req_len - offset, PAGE_SIZE); + memcpy(&cmd->req[offset], tpmif->pages[i], tocopy); + offset += tocopy; + + /* release the page */ + gntmap_munmap(>pmdev.map, (unsigned long)tpmif->pages[i], 1); + + } + +#ifdef TPMBACK_PRINT_DEBUG + TPMBACK_DEBUG("Received Tpm Command from %u/%u of size %u", (unsigned int) tpmif->domid, tpmif->handle, cmd->req_len); + for(i = 0; i < cmd->req_len; ++i) { + if (!(i % 30)) { + TPMBACK_DEBUG_MORE("\n"); + } + TPMBACK_DEBUG_MORE("%02hhX ", cmd->req[i]); + } + TPMBACK_DEBUG_MORE("\n\n"); +#endif + + local_irq_restore(flags); + return cmd; +error: + if(cmd != NULL) { + if (cmd->req != NULL) { + free(cmd->req); + cmd->req = NULL; + } + free(cmd); + cmd = NULL; + } + local_irq_restore(flags); + return NULL; + +} + +void send_response(tpmcmd_t* cmd, tpmif_t* tpmif) +{ + tpmif_tx_request_t* tx; + int offset; + int i; + uint32_t domid; + int tocopy; + int flags; + + local_irq_save(flags); + + tx = &tpmif->tx->ring[0].req; + tx->size = cmd->resp_len; + + offset = 0; + for(i = 0; i < TPMIF_TX_RING_SIZE && offset < cmd->resp_len; ++i) { + tx = &tpmif->tx->ring[i].req; + + /* Map the page with the data */ + domid = (uint32_t)tpmif->domid; + if((tpmif->pages[i] = gntmap_map_grant_refs(>pmdev.map, 1, &domid, 0, &tx->ref, PROT_WRITE)) == NULL) { + TPMBACK_ERR("%u/%u Unable to map shared page during write!\n", (unsigned int) tpmif->domid, tpmif->handle); + goto error; + } + + /* do the copy now */ + tocopy = min(cmd->resp_len - offset, PAGE_SIZE); + memcpy(tpmif->pages[i], &cmd->resp[offset], tocopy); + offset += tocopy; + + /* release the page */ + gntmap_munmap(>pmdev.map, (unsigned long)tpmif->pages[i], 1); + + } + +#ifdef TPMBACK_PRINT_DEBUG + TPMBACK_DEBUG("Sent response to %u/%u of size %u", (unsigned int) tpmif->domid, tpmif->handle, cmd->resp_len); + for(i = 0; i < cmd->resp_len; ++i) { + if (!(i % 30)) { + TPMBACK_DEBUG_MORE("\n"); + } + TPMBACK_DEBUG_MORE("%02hhX ", cmd->resp[i]); + } + TPMBACK_DEBUG_MORE("\n\n"); +#endif + /* clear the ready flag and send the event channel notice to the frontend */ + tpmif_req_finished(tpmif); + notify_remote_via_evtchn(tpmif->evtchn); +error: + local_irq_restore(flags); + return; +} + +tpmcmd_t* tpmback_req_any(void) +{ + int i; + /* Block until something has a request */ + wait_event(waitq, (gtpmdev.flags & (TPMIF_REQ_READY | TPMIF_CLOSED))); + + /* Check if were shutting down */ + if(gtpmdev.flags & TPMIF_CLOSED) { + /* if something was waiting for us to give up the queue so it can shutdown, let it finish */ + schedule(); + return NULL; + } + + for(i = 0; i < gtpmdev.num_tpms; ++i) { + if(gtpmdev.tpmlist[i]->flags & TPMIF_REQ_READY) { + return get_request(gtpmdev.tpmlist[i]); + } + } + + TPMBACK_ERR("backend request ready flag was set but no interfaces were actually ready\n"); + return NULL; +} + +tpmcmd_t* tpmback_req(domid_t domid, unsigned int handle) +{ + tpmif_t* tpmif; + tpmif = get_tpmif(domid, handle); + if(tpmif == NULL) { + return NULL; + } + + wait_event(waitq, (tpmif->flags & (TPMIF_REQ_READY | TPMIF_CLOSED) || gtpmdev.flags & TPMIF_CLOSED)); + + /* Check if were shutting down */ + if(tpmif->flags & TPMIF_CLOSED || gtpmdev.flags & TPMIF_CLOSED) { + /* if something was waiting for us to give up the queue so it can free this instance, let it finish */ + schedule(); + return NULL; + } + + return get_request(tpmif); +} + +void tpmback_resp(tpmcmd_t* tpmcmd) +{ + tpmif_t* tpmif; + + /* Get the associated interface, if it doesnt exist then just quit */ + tpmif = get_tpmif(tpmcmd->domid, tpmcmd->handle); + if(tpmif == NULL) { + TPMBACK_ERR("Tried to send a reponse to non existant frontend %u/%u\n", (unsigned int) tpmcmd->domid, tpmcmd->handle); + goto end; + } + + if(!(tpmif->flags & TPMIF_REQ_READY)) { + TPMBACK_ERR("Tried to send response to a frontend that was not waiting for one %u/%u\n", (unsigned int) tpmcmd->domid, tpmcmd->handle); + goto end; + } + + /* Send response to frontend */ + send_response(tpmcmd, tpmif); + +end: + if(tpmcmd->req != NULL) { + free(tpmcmd->req); + } + free(tpmcmd); + return; +} + +int tpmback_wait_for_frontend_connect(domid_t *domid, unsigned int *handle) +{ + tpmif_t* tpmif; + int flags; + wait_event(waitq, ((gtpmdev.num_tpms > 0) || gtpmdev.flags & TPMIF_CLOSED)); + if(gtpmdev.flags & TPMIF_CLOSED) { + return -1; + } + local_irq_save(flags); + tpmif = gtpmdev.tpmlist[0]; + *domid = tpmif->domid; + *handle = tpmif->handle; + local_irq_restore(flags); + + return 0; +} + +int tpmback_num_frontends(void) +{ + return gtpmdev.num_tpms; +} diff --git a/extras/mini-os/tpmfront.c b/extras/mini-os/tpmfront.c new file mode 100644 index 0000000..0218d7f --- /dev/null +++ b/extras/mini-os/tpmfront.c @@ -0,0 +1,608 @@ +/* + * Copyright (c) 2010-2012 United States Government, as represented by + * the Secretary of Defense. All rights reserved. + * + * This code has been derived from drivers/char/tpm_vtpm.c + * from the xen 2.6.18 linux kernel + * + * Copyright (C) 2006 IBM Corporation + * + * This code has also been derived from drivers/char/tpm_xen.c + * from the xen 2.6.18 linux kernel + * + * Copyright (c) 2005, IBM Corporation + * + * which was itself derived from drivers/xen/netfront/netfront.c + * from the linux kernel + * + * Copyright (c) 2002-2004, K A Fraser + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation, version 2 of the + * License. + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +//#define TPMFRONT_PRINT_DEBUG +#ifdef TPMFRONT_PRINT_DEBUG +#define TPMFRONT_DEBUG(fmt,...) printk("Tpmfront:Debug("__FILE__":%d) " fmt, __LINE__, ##__VA_ARGS__) +#define TPMFRONT_DEBUG_MORE(fmt,...) printk(fmt, ##__VA_ARGS__) +#else +#define TPMFRONT_DEBUG(fmt,...) +#endif +#define TPMFRONT_ERR(fmt,...) printk("Tpmfront:Error " fmt, ##__VA_ARGS__) +#define TPMFRONT_LOG(fmt,...) printk("Tpmfront:Info " fmt, ##__VA_ARGS__) + +#define min(a,b) (((a) < (b)) ? (a) : (b)) + +void tpmfront_handler(evtchn_port_t port, struct pt_regs *regs, void *data) { + struct tpmfront_dev* dev = (struct tpmfront_dev*) data; + /*If we get a response when we didnt make a request, just ignore it */ + if(!dev->waiting) { + return; + } + + dev->waiting = 0; +#ifdef HAVE_LIBC + if(dev->fd >= 0) { + files[dev->fd].read = 1; + } +#endif + wake_up(&dev->waitq); +} + +static int publish_xenbus(struct tpmfront_dev* dev) { + xenbus_transaction_t xbt; + int retry; + char* err; + /* Write the grant reference and event channel to xenstore */ +again: + if((err = xenbus_transaction_start(&xbt))) { + TPMFRONT_ERR("Unable to start xenbus transaction, error was %s\n", err); + free(err); + return -1; + } + + if((err = xenbus_printf(xbt, dev->nodename, "ring-ref", "%u", (unsigned int) dev->ring_ref))) { + TPMFRONT_ERR("Unable to write %s/ring-ref, error was %s\n", dev->nodename, err); + free(err); + goto abort_transaction; + } + + if((err = xenbus_printf(xbt, dev->nodename, "event-channel", "%u", (unsigned int) dev->evtchn))) { + TPMFRONT_ERR("Unable to write %s/event-channel, error was %s\n", dev->nodename, err); + free(err); + goto abort_transaction; + } + + if((err = xenbus_transaction_end(xbt, 0, &retry))) { + TPMFRONT_ERR("Unable to complete xenbus transaction, error was %s\n", err); + free(err); + return -1; + } + if(retry) { + goto again; + } + + return 0; +abort_transaction: + if((err = xenbus_transaction_end(xbt, 1, &retry))) { + free(err); + } + return -1; +} + +static int wait_for_backend_connect(xenbus_event_queue* events, char* path) +{ + int state; + + TPMFRONT_LOG("Waiting for backend connection..\n"); + /* Wait for the backend to connect */ + while(1) { + state = xenbus_read_integer(path); + if ( state < 0) + state = XenbusStateUnknown; + switch(state) { + /* Bad states, we quit with error */ + case XenbusStateUnknown: + case XenbusStateClosing: + case XenbusStateClosed: + TPMFRONT_ERR("Unable to connect to backend\n"); + return -1; + /* If backend is connected then break out of loop */ + case XenbusStateConnected: + TPMFRONT_LOG("Backend Connected\n"); + return 0; + default: + xenbus_wait_for_watch(events); + } + } + +} + +static int wait_for_backend_closed(xenbus_event_queue* events, char* path) +{ + int state; + + TPMFRONT_LOG("Waiting for backend to close..\n"); + while(1) { + state = xenbus_read_integer(path); + if ( state < 0) + state = XenbusStateUnknown; + switch(state) { + case XenbusStateUnknown: + TPMFRONT_ERR("Backend Unknown state, forcing shutdown\n"); + return -1; + case XenbusStateClosed: + TPMFRONT_LOG("Backend Closed\n"); + return 0; + default: + xenbus_wait_for_watch(events); + } + } + +} + +static int wait_for_backend_state_changed(struct tpmfront_dev* dev, XenbusState state) { + char* err; + int ret = 0; + xenbus_event_queue events = NULL; + char path[512]; + + snprintf(path, 512, "%s/state", dev->bepath); + /*Setup the watch to wait for the backend */ + if((err = xenbus_watch_path_token(XBT_NIL, path, path, &events))) { + TPMFRONT_ERR("Could not set a watch on %s, error was %s\n", path, err); + free(err); + return -1; + } + + /* Do the actual wait loop now */ + switch(state) { + case XenbusStateConnected: + ret = wait_for_backend_connect(&events, path); + break; + case XenbusStateClosed: + ret = wait_for_backend_closed(&events, path); + break; + default: + break; + } + + if((err = xenbus_unwatch_path_token(XBT_NIL, path, path))) { + TPMFRONT_ERR("Unable to unwatch %s, error was %s, ignoring..\n", path, err); + free(err); + } + return ret; +} + +static int tpmfront_connect(struct tpmfront_dev* dev) +{ + char* err; + /* Create shared page */ + dev->tx = (tpmif_tx_interface_t*) alloc_page(); + if(dev->tx == NULL) { + TPMFRONT_ERR("Unable to allocate page for shared memory\n"); + goto error; + } + memset(dev->tx, 0, PAGE_SIZE); + dev->ring_ref = gnttab_grant_access(dev->bedomid, virt_to_mfn(dev->tx), 0); + TPMFRONT_DEBUG("grant ref is %lu\n", (unsigned long) dev->ring_ref); + + /*Create event channel */ + if(evtchn_alloc_unbound(dev->bedomid, tpmfront_handler, dev, &dev->evtchn)) { + TPMFRONT_ERR("Unable to allocate event channel\n"); + goto error_postmap; + } + unmask_evtchn(dev->evtchn); + TPMFRONT_DEBUG("event channel is %lu\n", (unsigned long) dev->evtchn); + + /* Write the entries to xenstore */ + if(publish_xenbus(dev)) { + goto error_postevtchn; + } + + /* Change state to connected */ + dev->state = XenbusStateConnected; + + /* Tell the backend that we are ready */ + if((err = xenbus_printf(XBT_NIL, dev->nodename, "state", "%u", dev->state))) { + TPMFRONT_ERR("Unable to write to xenstore %s/state, value=%u", dev->nodename, XenbusStateConnected); + free(err); + goto error; + } + + return 0; +error_postevtchn: + mask_evtchn(dev->evtchn); + unbind_evtchn(dev->evtchn); +error_postmap: + gnttab_end_access(dev->ring_ref); + free_page(dev->tx); +error: + return -1; +} + +struct tpmfront_dev* init_tpmfront(const char* _nodename) +{ + struct tpmfront_dev* dev; + const char* nodename; + char path[512]; + char* value, *err; + unsigned long long ival; + int i; + + printk("============= Init TPM Front ================\n"); + + dev = malloc(sizeof(struct tpmfront_dev)); + memset(dev, 0, sizeof(struct tpmfront_dev)); + +#ifdef HAVE_LIBC + dev->fd = -1; +#endif + + nodename = _nodename ? _nodename : "device/vtpm/0"; + dev->nodename = strdup(nodename); + + init_waitqueue_head(&dev->waitq); + + /* Get backend domid */ + snprintf(path, 512, "%s/backend-id", dev->nodename); + if((err = xenbus_read(XBT_NIL, path, &value))) { + TPMFRONT_ERR("Unable to read %s during tpmfront initialization! error = %s\n", path, err); + free(err); + goto error; + } + if(sscanf(value, "%llu", &ival) != 1) { + TPMFRONT_ERR("%s has non-integer value (%s)\n", path, value); + free(value); + goto error; + } + free(value); + dev->bedomid = ival; + + /* Get backend xenstore path */ + snprintf(path, 512, "%s/backend", dev->nodename); + if((err = xenbus_read(XBT_NIL, path, &dev->bepath))) { + TPMFRONT_ERR("Unable to read %s during tpmfront initialization! error = %s\n", path, err); + free(err); + goto error; + } + + /* Create and publish grant reference and event channel */ + if (tpmfront_connect(dev)) { + goto error; + } + + /* Wait for backend to connect */ + if( wait_for_backend_state_changed(dev, XenbusStateConnected)) { + goto error; + } + + /* Allocate pages that will contain the messages */ + dev->pages = malloc(sizeof(void*) * TPMIF_TX_RING_SIZE); + if(dev->pages == NULL) { + goto error; + } + memset(dev->pages, 0, sizeof(void*) * TPMIF_TX_RING_SIZE); + for(i = 0; i < TPMIF_TX_RING_SIZE; ++i) { + dev->pages[i] = (void*)alloc_page(); + if(dev->pages[i] == NULL) { + goto error; + } + } + + TPMFRONT_LOG("Initialization Completed successfully\n"); + + return dev; + +error: + shutdown_tpmfront(dev); + return NULL; +} +void shutdown_tpmfront(struct tpmfront_dev* dev) +{ + char* err; + char path[512]; + int i; + tpmif_tx_request_t* tx; + if(dev == NULL) { + return; + } + TPMFRONT_LOG("Shutting down tpmfront\n"); + /* disconnect */ + if(dev->state == XenbusStateConnected) { + dev->state = XenbusStateClosing; + //FIXME: Transaction for this? + /* Tell backend we are closing */ + if((err = xenbus_printf(XBT_NIL, dev->nodename, "state", "%u", (unsigned int) dev->state))) { + free(err); + } + + /* Clean up xenstore entries */ + snprintf(path, 512, "%s/event-channel", dev->nodename); + if((err = xenbus_rm(XBT_NIL, path))) { + free(err); + } + snprintf(path, 512, "%s/ring-ref", dev->nodename); + if((err = xenbus_rm(XBT_NIL, path))) { + free(err); + } + + /* Tell backend we are closed */ + dev->state = XenbusStateClosed; + if((err = xenbus_printf(XBT_NIL, dev->nodename, "state", "%u", (unsigned int) dev->state))) { + TPMFRONT_ERR("Unable to write to %s, error was %s", dev->nodename, err); + free(err); + } + + /* Wait for the backend to close and unmap shared pages, ignore any errors */ + wait_for_backend_state_changed(dev, XenbusStateClosed); + + /* Cleanup any shared pages */ + if(dev->pages) { + for(i = 0; i < TPMIF_TX_RING_SIZE; ++i) { + if(dev->pages[i]) { + tx = &dev->tx->ring[i].req; + if(tx->ref != 0) { + gnttab_end_access(tx->ref); + } + free_page(dev->pages[i]); + } + } + free(dev->pages); + } + + /* Close event channel and unmap shared page */ + mask_evtchn(dev->evtchn); + unbind_evtchn(dev->evtchn); + gnttab_end_access(dev->ring_ref); + + free_page(dev->tx); + + } + + /* Cleanup memory usage */ + if(dev->respbuf) { + free(dev->respbuf); + } + if(dev->bepath) { + free(dev->bepath); + } + if(dev->nodename) { + free(dev->nodename); + } + free(dev); +} + +int tpmfront_send(struct tpmfront_dev* dev, const uint8_t* msg, size_t length) +{ + int i; + tpmif_tx_request_t* tx = NULL; + /* Error Checking */ + if(dev == NULL || dev->state != XenbusStateConnected) { + TPMFRONT_ERR("Tried to send message through disconnected frontend\n"); + return -1; + } + +#ifdef TPMFRONT_PRINT_DEBUG + TPMFRONT_DEBUG("Sending Msg to backend size=%u", (unsigned int) length); + for(i = 0; i < length; ++i) { + if(!(i % 30)) { + TPMFRONT_DEBUG_MORE("\n"); + } + TPMFRONT_DEBUG_MORE("%02X ", msg[i]); + } + TPMFRONT_DEBUG_MORE("\n"); +#endif + + /* Copy to shared pages now */ + for(i = 0; length > 0 && i < TPMIF_TX_RING_SIZE; ++i) { + /* Share the page */ + tx = &dev->tx->ring[i].req; + tx->unused = 0; + tx->addr = virt_to_mach(dev->pages[i]); + tx->ref = gnttab_grant_access(dev->bedomid, virt_to_mfn(dev->pages[i]), 0); + /* Copy the bits to the page */ + tx->size = length > PAGE_SIZE ? PAGE_SIZE : length; + memcpy(dev->pages[i], &msg[i * PAGE_SIZE], tx->size); + + /* Update counters */ + length -= tx->size; + } + dev->waiting = 1; + dev->resplen = 0; +#ifdef HAVE_LIBC + if(dev->fd >= 0) { + files[dev->fd].read = 0; + files[dev->fd].tpmfront.respgot = 0; + files[dev->fd].tpmfront.offset = 0; + } +#endif + notify_remote_via_evtchn(dev->evtchn); + return 0; +} +int tpmfront_recv(struct tpmfront_dev* dev, uint8_t** msg, size_t *length) +{ + tpmif_tx_request_t* tx; + int i; + if(dev == NULL || dev->state != XenbusStateConnected) { + TPMFRONT_ERR("Tried to receive message from disconnected frontend\n"); + return -1; + } + /*Wait for the response */ + wait_event(dev->waitq, (!dev->waiting)); + + /* Initialize */ + *msg = NULL; + *length = 0; + + /* special case, just quit */ + tx = &dev->tx->ring[0].req; + if(tx->size == 0 ) { + goto quit; + } + /* Get the total size */ + tx = &dev->tx->ring[0].req; + for(i = 0; i < TPMIF_TX_RING_SIZE && tx->size > 0; ++i) { + tx = &dev->tx->ring[i].req; + *length += tx->size; + } + /* Alloc the buffer */ + if(dev->respbuf) { + free(dev->respbuf); + } + *msg = dev->respbuf = malloc(*length); + dev->resplen = *length; + /* Copy the bits */ + tx = &dev->tx->ring[0].req; + for(i = 0; i < TPMIF_TX_RING_SIZE && tx->size > 0; ++i) { + tx = &dev->tx->ring[i].req; + memcpy(&(*msg)[i * PAGE_SIZE], dev->pages[i], tx->size); + gnttab_end_access(tx->ref); + tx->ref = 0; + } +#ifdef TPMFRONT_PRINT_DEBUG + TPMFRONT_DEBUG("Received response from backend size=%u", (unsigned int) *length); + for(i = 0; i < *length; ++i) { + if(!(i % 30)) { + TPMFRONT_DEBUG_MORE("\n"); + } + TPMFRONT_DEBUG_MORE("%02X ", (*msg)[i]); + } + TPMFRONT_DEBUG_MORE("\n"); +#endif +#ifdef HAVE_LIBC + if(dev->fd >= 0) { + files[dev->fd].tpmfront.respgot = 1; + } +#endif +quit: + return 0; +} + +int tpmfront_cmd(struct tpmfront_dev* dev, uint8_t* req, size_t reqlen, uint8_t** resp, size_t* resplen) +{ + int rc; + if((rc = tpmfront_send(dev, req, reqlen))) { + return rc; + } + if((rc = tpmfront_recv(dev, resp, resplen))) { + return rc; + } + + return 0; +} + +#ifdef HAVE_LIBC +#include +int tpmfront_open(struct tpmfront_dev* dev) +{ + /* Silently prevent multiple opens */ + if(dev->fd != -1) { + return dev->fd; + } + + dev->fd = alloc_fd(FTYPE_TPMFRONT); + printk("tpmfront_open(%s) -> %d\n", dev->nodename, dev->fd); + files[dev->fd].tpmfront.dev = dev; + files[dev->fd].tpmfront.offset = 0; + files[dev->fd].tpmfront.respgot = 0; + return dev->fd; +} + +int tpmfront_posix_write(int fd, const uint8_t* buf, size_t count) +{ + int rc; + struct tpmfront_dev* dev; + dev = files[fd].tpmfront.dev; + + if(count == 0) { + return 0; + } + + /* Return an error if we are already processing a command */ + if(dev->waiting) { + errno = EINPROGRESS; + return -1; + } + /* Send the command now */ + if((rc = tpmfront_send(dev, buf, count)) != 0) { + errno = EIO; + return -1; + } + return count; +} + +int tpmfront_posix_read(int fd, uint8_t* buf, size_t count) +{ + int rc; + uint8_t* dummybuf; + size_t dummysz; + struct tpmfront_dev* dev; + + dev = files[fd].tpmfront.dev; + + if(count == 0) { + return 0; + } + + /* get the response if we haven't already */ + if(files[dev->fd].tpmfront.respgot == 0) { + if ((rc = tpmfront_recv(dev, &dummybuf, &dummysz)) != 0) { + errno = EIO; + return -1; + } + } + + /* handle EOF case */ + if(files[dev->fd].tpmfront.offset >= dev->resplen) { + return 0; + } + + /* Compute the number of bytes and do the copy operation */ + if((rc = min(count, dev->resplen - files[dev->fd].tpmfront.offset)) != 0) { + memcpy(buf, dev->respbuf + files[dev->fd].tpmfront.offset, rc); + files[dev->fd].tpmfront.offset += rc; + } + + return rc; +} + +int tpmfront_posix_fstat(int fd, struct stat* buf) +{ + uint8_t* dummybuf; + size_t dummysz; + int rc; + struct tpmfront_dev* dev = files[fd].tpmfront.dev; + + /* If we have a response waiting, then read it now from the backend + * so we can get its length*/ + if(dev->waiting || (files[dev->fd].read == 1 && !files[dev->fd].tpmfront.respgot)) { + if ((rc = tpmfront_recv(dev, &dummybuf, &dummysz)) != 0) { + errno = EIO; + return -1; + } + } + + buf->st_mode = O_RDWR; + buf->st_uid = 0; + buf->st_gid = 0; + buf->st_size = dev->resplen; + buf->st_atime = buf->st_mtime = buf->st_ctime = time(NULL); + + return 0; +} + + +#endif -- 1.7.4.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 18:01:53 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 18:01:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCDb-0002Ua-6E; Fri, 05 Oct 2012 18:01:47 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCDZ-0002T7-4W for xen-devel@lists.xen.org; Fri, 05 Oct 2012 18:01:45 +0000 Received: from [85.158.139.211:3025] by server-7.bemta-5.messagelabs.com id 71/CC-00431-8802F605; Fri, 05 Oct 2012 18:01:44 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-12.tower-206.messagelabs.com!1349460097!20239802!1 X-Originating-IP: [128.244.251.37] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6021 invoked from network); 5 Oct 2012 18:01:39 -0000 Received: from piper.jhuapl.edu (HELO jhuapl.edu) (128.244.251.37) by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 18:01:39 -0000 Received: from ([128.244.207.97]) by piper.jhuapl.edu with ESMTP with TLS id 5Y8HCH1.146215583; Fri, 05 Oct 2012 14:01:02 -0400 From: Matthew Fioravante To: xen-devel@lists.xen.org, ian.campbell@citrix.com, samuel.thibault@ens-lyons.org Date: Fri, 5 Oct 2012 14:01:17 -0400 Message-Id: <1349460077-13770-8-git-send-email-matthew.fioravante@jhuapl.edu> X-Mailer: git-send-email 1.7.4.4 In-Reply-To: <1349460077-13770-1-git-send-email-matthew.fioravante@jhuapl.edu> References: <1349460077-13770-1-git-send-email-matthew.fioravante@jhuapl.edu> Cc: Matthew Fioravante Subject: [Xen-devel] [PATCH vtpm v2 08/12] add tpmfront, tpm_tis, and tpmback drivers to mini-os X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch adds 3 new drivers to mini-os. tpmfront - paravirtualized tpm frontend driver tpmback - paravirtualized tpm backend driver tpm_tis - hardware tpm driver Unfortunately these drivers were derived from GPL licensed linux kernel drivers so they must carry the GPL license. However, since mini-os now supports conditional compilation, hopefully these drivers can be included into the xen tree and conditionally removed from non-gpl projects. By default they are disabled in the makefile. Signed-off-by: Matthew Fioravante diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile index 2422db3..2302a23 100644 --- a/extras/mini-os/Makefile +++ b/extras/mini-os/Makefile @@ -22,6 +22,9 @@ CONFIG_QEMU_XS_ARGS ?= n CONFIG_TEST ?= n CONFIG_PCIFRONT ?= n CONFIG_BLKFRONT ?= y +CONFIG_TPMFRONT ?= n +CONFIG_TPM_TIS ?= n +CONFIG_TPMBACK ?= n CONFIG_NETFRONT ?= y CONFIG_FBFRONT ?= y CONFIG_KBDFRONT ?= y @@ -36,6 +39,9 @@ flags-$(CONFIG_SPARSE_BSS) += -DCONFIG_SPARSE_BSS flags-$(CONFIG_QEMU_XS_ARGS) += -DCONFIG_QEMU_XS_ARGS flags-$(CONFIG_PCIFRONT) += -DCONFIG_PCIFRONT flags-$(CONFIG_BLKFRONT) += -DCONFIG_BLKFRONT +flags-$(CONFIG_TPMFRONT) += -DCONFIG_TPMFRONT +flags-$(CONFIG_TPM_TIS) += -DCONFIG_TPM_TIS +flags-$(CONFIG_TPMBACK) += -DCONFIG_TPMBACK flags-$(CONFIG_NETFRONT) += -DCONFIG_NETFRONT flags-$(CONFIG_KBDFRONT) += -DCONFIG_KBDFRONT flags-$(CONFIG_FBFRONT) += -DCONFIG_FBFRONT @@ -67,6 +73,9 @@ TARGET := mini-os SUBDIRS := lib xenbus console src-$(CONFIG_BLKFRONT) += blkfront.c +src-$(CONFIG_TPMFRONT) += tpmfront.c +src-$(CONFIG_TPM_TIS) += tpm_tis.c +src-$(CONFIG_TPMBACK) += tpmback.c src-y += daytime.c src-y += events.c src-$(CONFIG_FBFRONT) += fbfront.c diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h index d4641b6..935bede 100644 --- a/extras/mini-os/include/lib.h +++ b/extras/mini-os/include/lib.h @@ -142,6 +142,8 @@ enum fd_type { FTYPE_FB, FTYPE_MEM, FTYPE_SAVEFILE, + FTYPE_TPMFRONT, + FTYPE_TPM_TIS, }; LIST_HEAD(evtchn_port_list, evtchn_port_info); @@ -185,6 +187,20 @@ extern struct file { struct { struct consfront_dev *dev; } cons; +#ifdef CONFIG_TPMFRONT + struct { + struct tpmfront_dev *dev; + int respgot; + off_t offset; + } tpmfront; +#endif +#ifdef CONFIG_TPM_TIS + struct { + struct tpm_chip *dev; + int respgot; + off_t offset; + } tpm_tis; +#endif #ifdef CONFIG_XENBUS struct { /* To each xenbus FD is associated a queue of watch events for this diff --git a/extras/mini-os/include/tpm_tis.h b/extras/mini-os/include/tpm_tis.h new file mode 100644 index 0000000..1faca0d --- /dev/null +++ b/extras/mini-os/include/tpm_tis.h @@ -0,0 +1,60 @@ +/* + * Copyright (c) 2010-2012 United States Government, as represented by + * the Secretary of Defense. All rights reserved. + * + * This code has been derived from drivers/char/tpm.c + * from the linux kernel + * + * Copyright (C) 2004 IBM Corporation + * + * This code has also been derived from drivers/char/tpm/tpm_tis.c + * from the linux kernel + * + * Copyright (C) 2005, 2006 IBM Corporation + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation, version 2 + * of the License + */ +#ifndef TPM_TIS_H +#define TPM_TIS_H + +#include +#include + +#define TPM_TIS_EN_LOCL0 1 +#define TPM_TIS_EN_LOCL1 (1 << 1) +#define TPM_TIS_EN_LOCL2 (1 << 2) +#define TPM_TIS_EN_LOCL3 (1 << 3) +#define TPM_TIS_EN_LOCL4 (1 << 4) +#define TPM_TIS_EN_LOCLALL (TPM_TIS_EN_LOCL0 | TPM_TIS_EN_LOCL1 | TPM_TIS_EN_LOCL2 | TPM_TIS_EN_LOCL3 | TPM_TIS_EN_LOCL4) +#define TPM_TIS_LOCL_INT_TO_FLAG(x) (1 << x) +#define TPM_BASEADDR 0xFED40000 +#define TPM_PROBE_IRQ 0xFFFF + +struct tpm_chip; + +struct tpm_chip* init_tpm_tis(unsigned long baseaddr, int localities, unsigned int irq); +void shutdown_tpm_tis(struct tpm_chip* tpm); + +int tpm_tis_request_locality(struct tpm_chip* tpm, int locality); +int tpm_tis_cmd(struct tpm_chip* tpm, uint8_t* req, size_t reqlen, uint8_t** resp, size_t* resplen); + +#ifdef HAVE_LIBC +#include +#include +/* POSIX IO functions: + * use tpm_tis_open() to get a file descriptor to the tpm device + * use write() on the fd to send a command to the backend. You must + * include the entire command in a single call to write(). + * use read() on the fd to read the response. You can use + * fstat() to get the size of the response and lseek() to seek on it. + */ +int tpm_tis_open(struct tpm_chip* tpm); +int tpm_tis_posix_read(int fd, uint8_t* buf, size_t count); +int tpm_tis_posix_write(int fd, const uint8_t* buf, size_t count); +int tpm_tis_posix_fstat(int fd, struct stat* buf); +#endif + +#endif diff --git a/extras/mini-os/include/tpmback.h b/extras/mini-os/include/tpmback.h new file mode 100644 index 0000000..302f83b --- /dev/null +++ b/extras/mini-os/include/tpmback.h @@ -0,0 +1,110 @@ +/* + * Copyright (c) 2010-2012 United States Government, as represented by + * the Secretary of Defense. All rights reserved. + * + * This code has been derived from drivers/xen/tpmback/tpmback.c + * from the xen 2.6.18 linux kernel + * + * Copyright (c) 2005, IBM Corporation + * + * which was itself derived from drivers/xen/netback/netback.c + * from the xen 2.6.18 linux kernel + * + * Copyright (c) 2002-2004, K A Fraser + * + * This code has also been derived from drivers/xen/tpmback/xenbus.c + * from the xen 2.6.18 linux kernel + * + * Copyright (C) 2005 IBM Corporation + * Copyright (C) 2005 Rusty Russell + * + * This code has also been derived from drivers/xen/tpmback/interface.c + * from the xen 2.6.18 linux kernel + * + * Copyright (c) 2005, IBM Corporation + * + * which was itself also derived from drvivers/xen/netback/interface.c + * from the xen 2.6.18 linux kernel + * + * Copyright (c) 2004, Keir Fraser + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation, version 2 + * of the License + */ + +#include +#include +#include +#include +#ifndef TPMBACK_H +#define TPMBACK_H + +struct tpmcmd { + domid_t domid; /* Domid of the frontend */ + unsigned int handle; /* Handle of the frontend */ + char* uuid; /* uuid of the tpm interface - allocated internally, dont free it */ + + unsigned int req_len; /* Size of the command in buf - set by tpmback driver */ + uint8_t* req; /* tpm command bits, allocated by driver, DON'T FREE IT */ + unsigned int resp_len; /* Size of the outgoing command, + you set this before passing the cmd object to tpmback_resp */ + uint8_t* resp; /* Buffer for response - YOU MUST ALLOCATE IT, YOU MUST ALSO FREE IT */ +}; +typedef struct tpmcmd tpmcmd_t; + +/* Initialize the tpm backend driver + * @exclusive_domname - This is NULL terminated list of vtpm uuid strings. If this list + * is non-empty, then only frontend domains with vtpm uuid's matching + * entries in this list will be allowed to connect. + * Other connections will be immediatly closed. + * Set this argument to NULL to allow any vtpm to connect. + */ +void init_tpmback(char** exclusive_uuids); +/* Shutdown tpm backend driver */ +void shutdown_tpmback(void); + +/* Blocks until a tpm command is sent from any front end. + * Returns a pointer to the tpm command to handle. + * Do not try to free this pointer or the req buffer + * This function will return NULL if the tpm backend driver + * is shutdown or any other error occurs */ +tpmcmd_t* tpmback_req_any(void); + +/* Blocks until a tpm command from the frontend at domid/handle + * is sent. + * Returns NULL if domid/handle is not connected, tpmback is + * shutdown or shutting down, or if there is an error + */ +tpmcmd_t* tpmback_req(domid_t domid, unsigned int handle); + +/* Send the response to the tpm command back to the frontend + * This function will free the tpmcmd object, but you must free the resp + * buffer yourself */ +void tpmback_resp(tpmcmd_t* tpmcmd); + +/* Waits for the first frontend to connect and then sets domid and handle appropriately. + * If one or more frontends are already connected, this will set domid and handle to one + * of them arbitrarily. The main use for this function is to wait until a single + * frontend connection has occured. + * returns 0 on success, non-zero on failure */ +int tpmback_wait_for_frontend_connect(domid_t *domid, unsigned int *handle); + +/* returns the number of frontends connected */ +int tpmback_num_frontends(void); + +/* Returns the uuid of the specified frontend, NULL on error */ +char* tpmback_get_uuid(domid_t domid, unsigned int handle); + +/* Specify a function to call when a new tpm device connects */ +void tpmback_set_open_callback(void (*cb)(domid_t, unsigned int)); + +/* Specify a function to call when a tpm device disconnects */ +void tpmback_set_close_callback(void (*cb)(domid_t, unsigned int)); + +//Not Implemented +void tpmback_set_suspend_callback(void (*cb)(domid_t, unsigned int)); +void tpmback_set_resume_callback(void (*cb)(domid_t, unsigned int)); + +#endif diff --git a/extras/mini-os/include/tpmfront.h b/extras/mini-os/include/tpmfront.h new file mode 100644 index 0000000..fd2cb17 --- /dev/null +++ b/extras/mini-os/include/tpmfront.h @@ -0,0 +1,96 @@ +/* + * Copyright (c) 2010-2012 United States Government, as represented by + * the Secretary of Defense. All rights reserved. + * + * This code has been derived from drivers/char/tpm_vtpm.c + * from the xen 2.6.18 linux kernel + * + * Copyright (C) 2006 IBM Corporation + * + * This code has also been derived from drivers/char/tpm_xen.c + * from the xen 2.6.18 linux kernel + * + * Copyright (c) 2005, IBM Corporation + * + * which was itself derived from drivers/xen/netfront/netfront.c + * from the linux kernel + * + * Copyright (c) 2002-2004, K A Fraser + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation, version 2 of the + * License. + */ +#ifndef TPMFRONT_H +#define TPMFRONT_H + +#include +#include +#include +#include +#include +#include +#include + +struct tpmfront_dev { + grant_ref_t ring_ref; + evtchn_port_t evtchn; + + tpmif_tx_interface_t* tx; + + void** pages; + + domid_t bedomid; + char* nodename; + char* bepath; + + XenbusState state; + + uint8_t waiting; + struct wait_queue_head waitq; + + uint8_t* respbuf; + size_t resplen; + +#ifdef HAVE_LIBC + int fd; +#endif + +}; + + +/*Initialize frontend */ +struct tpmfront_dev* init_tpmfront(const char* nodename); +/*Shutdown frontend */ +void shutdown_tpmfront(struct tpmfront_dev* dev); + +/* Send a tpm command to the backend and wait for the response + * + * @dev - frontend device + * @req - request buffer + * @reqlen - length of request buffer + * @resp - *resp will be set to internal response buffer, don't free it! Value is undefined on error + * @resplen - *resplen will be set to the length of the response. Value is undefined on error + * + * returns 0 on success, non zero on failure. + * */ +int tpmfront_cmd(struct tpmfront_dev* dev, uint8_t* req, size_t reqlen, uint8_t** resp, size_t* resplen); + +#ifdef HAVE_LIBC +#include +/* POSIX IO functions: + * use tpmfront_open() to get a file descriptor to the tpm device + * use write() on the fd to send a command to the backend. You must + * include the entire command in a single call to write(). + * use read() on the fd to read the response. You can use + * fstat() to get the size of the response and lseek() to seek on it. + */ +int tpmfront_open(struct tpmfront_dev* dev); +int tpmfront_posix_read(int fd, uint8_t* buf, size_t count); +int tpmfront_posix_write(int fd, const uint8_t* buf, size_t count); +int tpmfront_posix_fstat(int fd, struct stat* buf); +#endif + + +#endif diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c index 6cb97b1..d212969 100644 --- a/extras/mini-os/lib/sys.c +++ b/extras/mini-os/lib/sys.c @@ -27,6 +27,8 @@ #include #include #include +#include +#include #include #include @@ -294,6 +296,16 @@ int read(int fd, void *buf, size_t nbytes) return blkfront_posix_read(fd, buf, nbytes); } #endif +#ifdef CONFIG_TPMFRONT + case FTYPE_TPMFRONT: { + return tpmfront_posix_read(fd, buf, nbytes); + } +#endif +#ifdef CONFIG_TPM_TIS + case FTYPE_TPM_TIS: { + return tpm_tis_posix_read(fd, buf, nbytes); + } +#endif default: break; } @@ -330,6 +342,14 @@ int write(int fd, const void *buf, size_t nbytes) case FTYPE_BLK: return blkfront_posix_write(fd, buf, nbytes); #endif +#ifdef CONFIG_TPMFRONT + case FTYPE_TPMFRONT: + return tpmfront_posix_write(fd, buf, nbytes); +#endif +#ifdef CONFIG_TPM_TIS + case FTYPE_TPM_TIS: + return tpm_tis_posix_write(fd, buf, nbytes); +#endif default: break; } @@ -341,8 +361,16 @@ int write(int fd, const void *buf, size_t nbytes) off_t lseek(int fd, off_t offset, int whence) { switch(files[fd].type) { +#if defined(CONFIG_BLKFRONT) || defined(CONFIG_TPMFRONT) || defined(CONFIG_TPM_TIS) #ifdef CONFIG_BLKFRONT case FTYPE_BLK: +#endif +#ifdef CONFIG_TPMFRNT + case FTYPE_TPMFRONT: +#endif +#ifdef CONFIG_TPM_TIS + case FTYPE_TPM_TIS: +#endif switch (whence) { case SEEK_SET: files[fd].file.offset = offset; @@ -420,6 +448,18 @@ int close(int fd) files[fd].type = FTYPE_NONE; return 0; #endif +#ifdef CONFIG_TPMFRONT + case FTYPE_TPMFRONT: + shutdown_tpmfront(files[fd].tpmfront.dev); + files[fd].type = FTYPE_NONE; + return 0; +#endif +#ifdef CONFIG_TPM_TIS + case FTYPE_TPM_TIS: + shutdown_tpm_tis(files[fd].tpm_tis.dev); + files[fd].type = FTYPE_NONE; + return 0; +#endif #ifdef CONFIG_KBDFRONT case FTYPE_KBD: shutdown_kbdfront(files[fd].kbd.dev); @@ -489,6 +529,14 @@ int fstat(int fd, struct stat *buf) case FTYPE_BLK: return blkfront_posix_fstat(fd, buf); #endif +#ifdef CONFIG_TPMFRONT + case FTYPE_TPMFRONT: + return tpmfront_posix_fstat(fd, buf); +#endif +#ifdef CONFIG_TPM_TIS + case FTYPE_TPM_TIS: + return tpm_tis_posix_fstat(fd, buf); +#endif default: break; } diff --git a/extras/mini-os/tpm_tis.c b/extras/mini-os/tpm_tis.c new file mode 100644 index 0000000..b0e27b2 --- /dev/null +++ b/extras/mini-os/tpm_tis.c @@ -0,0 +1,1341 @@ +/* + * Copyright (c) 2010-2012 United States Government, as represented by + * the Secretary of Defense. All rights reserved. + * + * This code has been derived from drivers/char/tpm.c + * from the linux kernel + * + * Copyright (C) 2004 IBM Corporation + * + * This code has also been derived from drivers/char/tpm/tpm_tis.c + * from the linux kernel + * + * Copyright (C) 2005, 2006 IBM Corporation + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation, version 2 + * of the License + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#ifndef min + #define min( a, b ) ( ((a) < (b)) ? (a) : (b) ) +#endif + +#define TPM_HEADER_SIZE 10 + +#define TPM_BUFSIZE 2048 + +struct tpm_input_header { + uint16_t tag; + uint32_t length; + uint32_t ordinal; +}__attribute__((packed)); + +struct tpm_output_header { + uint16_t tag; + uint32_t length; + uint32_t return_code; +}__attribute__((packed)); + +struct stclear_flags_t { + uint16_t tag; + uint8_t deactivated; + uint8_t disableForceClear; + uint8_t physicalPresence; + uint8_t physicalPresenceLock; + uint8_t bGlobalLock; +}__attribute__((packed)); + +struct tpm_version_t { + uint8_t Major; + uint8_t Minor; + uint8_t revMajor; + uint8_t revMinor; +}__attribute__((packed)); + +struct tpm_version_1_2_t { + uint16_t tag; + uint8_t Major; + uint8_t Minor; + uint8_t revMajor; + uint8_t revMinor; +}__attribute__((packed)); + +struct timeout_t { + uint32_t a; + uint32_t b; + uint32_t c; + uint32_t d; +}__attribute__((packed)); + +struct duration_t { + uint32_t tpm_short; + uint32_t tpm_medium; + uint32_t tpm_long; +}__attribute__((packed)); + +struct permanent_flags_t { + uint16_t tag; + uint8_t disable; + uint8_t ownership; + uint8_t deactivated; + uint8_t readPubek; + uint8_t disableOwnerClear; + uint8_t allowMaintenance; + uint8_t physicalPresenceLifetimeLock; + uint8_t physicalPresenceHWEnable; + uint8_t physicalPresenceCMDEnable; + uint8_t CEKPUsed; + uint8_t TPMpost; + uint8_t TPMpostLock; + uint8_t FIPS; + uint8_t operator; + uint8_t enableRevokeEK; + uint8_t nvLocked; + uint8_t readSRKPub; + uint8_t tpmEstablished; + uint8_t maintenanceDone; + uint8_t disableFullDALogicInfo; +}__attribute__((packed)); + +typedef union { + struct permanent_flags_t perm_flags; + struct stclear_flags_t stclear_flags; + bool owned; + uint32_t num_pcrs; + struct tpm_version_t tpm_version; + struct tpm_version_1_2_t tpm_version_1_2; + uint32_t manufacturer_id; + struct timeout_t timeout; + struct duration_t duration; +} cap_t; + +struct tpm_getcap_params_in { + uint32_t cap; + uint32_t subcap_size; + uint32_t subcap; +}__attribute__((packed)); + +struct tpm_getcap_params_out { + uint32_t cap_size; + cap_t cap; +}__attribute__((packed)); + +struct tpm_readpubek_params_out { + uint8_t algorithm[4]; + uint8_t encscheme[2]; + uint8_t sigscheme[2]; + uint32_t paramsize; + uint8_t parameters[12]; /*assuming RSA*/ + uint32_t keysize; + uint8_t modulus[256]; + uint8_t checksum[20]; +}__attribute__((packed)); + +typedef union { + struct tpm_input_header in; + struct tpm_output_header out; +} tpm_cmd_header; + +#define TPM_DIGEST_SIZE 20 +struct tpm_pcrread_out { + uint8_t pcr_result[TPM_DIGEST_SIZE]; +}__attribute__((packed)); + +struct tpm_pcrread_in { + uint32_t pcr_idx; +}__attribute__((packed)); + +struct tpm_pcrextend_in { + uint32_t pcr_idx; + uint8_t hash[TPM_DIGEST_SIZE]; +}__attribute__((packed)); + +typedef union { + struct tpm_getcap_params_out getcap_out; + struct tpm_readpubek_params_out readpubek_out; + uint8_t readpubek_out_buffer[sizeof(struct tpm_readpubek_params_out)]; + struct tpm_getcap_params_in getcap_in; + struct tpm_pcrread_in pcrread_in; + struct tpm_pcrread_out pcrread_out; + struct tpm_pcrextend_in pcrextend_in; +} tpm_cmd_params; + +struct tpm_cmd_t { + tpm_cmd_header header; + tpm_cmd_params params; +}__attribute__((packed)); + + +enum tpm_duration { + TPM_SHORT = 0, + TPM_MEDIUM = 1, + TPM_LONG = 2, + TPM_UNDEFINED, +}; + +#define TPM_MAX_ORDINAL 243 +#define TPM_MAX_PROTECTED_ORDINAL 12 +#define TPM_PROTECTED_ORDINAL_MASK 0xFF + +extern const uint8_t tpm_protected_ordinal_duration[TPM_MAX_PROTECTED_ORDINAL]; +extern const uint8_t tpm_ordinal_duration[TPM_MAX_ORDINAL]; + +#define TPM_DIGEST_SIZE 20 +#define TPM_ERROR_SIZE 10 +#define TPM_RET_CODE_IDX 6 + +/* tpm_capabilities */ +#define TPM_CAP_FLAG cpu_to_be32(4) +#define TPM_CAP_PROP cpu_to_be32(5) +#define CAP_VERSION_1_1 cpu_to_be32(0x06) +#define CAP_VERSION_1_2 cpu_to_be32(0x1A) + +/* tpm_sub_capabilities */ +#define TPM_CAP_PROP_PCR cpu_to_be32(0x101) +#define TPM_CAP_PROP_MANUFACTURER cpu_to_be32(0x103) +#define TPM_CAP_FLAG_PERM cpu_to_be32(0x108) +#define TPM_CAP_FLAG_VOL cpu_to_be32(0x109) +#define TPM_CAP_PROP_OWNER cpu_to_be32(0x111) +#define TPM_CAP_PROP_TIS_TIMEOUT cpu_to_be32(0x115) +#define TPM_CAP_PROP_TIS_DURATION cpu_to_be32(0x120) + + +#define TPM_INTERNAL_RESULT_SIZE 200 +#define TPM_TAG_RQU_COMMAND cpu_to_be16(193) +#define TPM_ORD_GET_CAP cpu_to_be32(101) + +extern const struct tpm_input_header tpm_getcap_header; + + + +const uint8_t tpm_protected_ordinal_duration[TPM_MAX_PROTECTED_ORDINAL] = { + TPM_UNDEFINED, /* 0 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 5 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 10 */ + TPM_SHORT, +}; + +const uint8_t tpm_ordinal_duration[TPM_MAX_ORDINAL] = { + TPM_UNDEFINED, /* 0 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 5 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 10 */ + TPM_SHORT, + TPM_MEDIUM, + TPM_LONG, + TPM_LONG, + TPM_MEDIUM, /* 15 */ + TPM_SHORT, + TPM_SHORT, + TPM_MEDIUM, + TPM_LONG, + TPM_SHORT, /* 20 */ + TPM_SHORT, + TPM_MEDIUM, + TPM_MEDIUM, + TPM_MEDIUM, + TPM_SHORT, /* 25 */ + TPM_SHORT, + TPM_MEDIUM, + TPM_SHORT, + TPM_SHORT, + TPM_MEDIUM, /* 30 */ + TPM_LONG, + TPM_MEDIUM, + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, /* 35 */ + TPM_MEDIUM, + TPM_MEDIUM, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_MEDIUM, /* 40 */ + TPM_LONG, + TPM_MEDIUM, + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, /* 45 */ + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_LONG, + TPM_MEDIUM, /* 50 */ + TPM_MEDIUM, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 55 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_MEDIUM, /* 60 */ + TPM_MEDIUM, + TPM_MEDIUM, + TPM_SHORT, + TPM_SHORT, + TPM_MEDIUM, /* 65 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 70 */ + TPM_SHORT, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 75 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_LONG, /* 80 */ + TPM_UNDEFINED, + TPM_MEDIUM, + TPM_LONG, + TPM_SHORT, + TPM_UNDEFINED, /* 85 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 90 */ + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_UNDEFINED, /* 95 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_MEDIUM, /* 100 */ + TPM_SHORT, + TPM_SHORT, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 105 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 110 */ + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, /* 115 */ + TPM_SHORT, + TPM_SHORT, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_LONG, /* 120 */ + TPM_LONG, + TPM_MEDIUM, + TPM_UNDEFINED, + TPM_SHORT, + TPM_SHORT, /* 125 */ + TPM_SHORT, + TPM_LONG, + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, /* 130 */ + TPM_MEDIUM, + TPM_UNDEFINED, + TPM_SHORT, + TPM_MEDIUM, + TPM_UNDEFINED, /* 135 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 140 */ + TPM_SHORT, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 145 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 150 */ + TPM_MEDIUM, + TPM_MEDIUM, + TPM_SHORT, + TPM_SHORT, + TPM_UNDEFINED, /* 155 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 160 */ + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 165 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_LONG, /* 170 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 175 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_MEDIUM, /* 180 */ + TPM_SHORT, + TPM_MEDIUM, + TPM_MEDIUM, + TPM_MEDIUM, + TPM_MEDIUM, /* 185 */ + TPM_SHORT, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 190 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 195 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 200 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, + TPM_SHORT, /* 205 */ + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_MEDIUM, /* 210 */ + TPM_UNDEFINED, + TPM_MEDIUM, + TPM_MEDIUM, + TPM_MEDIUM, + TPM_UNDEFINED, /* 215 */ + TPM_MEDIUM, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, + TPM_SHORT, /* 220 */ + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_SHORT, + TPM_UNDEFINED, /* 225 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 230 */ + TPM_LONG, + TPM_MEDIUM, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, /* 235 */ + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_UNDEFINED, + TPM_SHORT, /* 240 */ + TPM_UNDEFINED, + TPM_MEDIUM, +}; + +const struct tpm_input_header tpm_getcap_header = { + .tag = TPM_TAG_RQU_COMMAND, + .length = cpu_to_be32(22), + .ordinal = TPM_ORD_GET_CAP +}; + + +enum tis_access { + TPM_ACCESS_VALID = 0x80, + TPM_ACCESS_ACTIVE_LOCALITY = 0x20, /* (R) */ + TPM_ACCESS_RELINQUISH_LOCALITY = 0x20,/* (W) */ + TPM_ACCESS_REQUEST_PENDING = 0x04, /* (W) */ + TPM_ACCESS_REQUEST_USE = 0x02, /* (W) */ +}; + +enum tis_status { + TPM_STS_VALID = 0x80, /* (R) */ + TPM_STS_COMMAND_READY = 0x40, /* (R) */ + TPM_STS_DATA_AVAIL = 0x10, /* (R) */ + TPM_STS_DATA_EXPECT = 0x08, /* (R) */ + TPM_STS_GO = 0x20, /* (W) */ +}; + +enum tis_int_flags { + TPM_GLOBAL_INT_ENABLE = 0x80000000, + TPM_INTF_BURST_COUNT_STATIC = 0x100, + TPM_INTF_CMD_READY_INT = 0x080, + TPM_INTF_INT_EDGE_FALLING = 0x040, + TPM_INTF_INT_EDGE_RISING = 0x020, + TPM_INTF_INT_LEVEL_LOW = 0x010, + TPM_INTF_INT_LEVEL_HIGH = 0x008, + TPM_INTF_LOCALITY_CHANGE_INT = 0x004, + TPM_INTF_STS_VALID_INT = 0x002, + TPM_INTF_DATA_AVAIL_INT = 0x001, +}; + +enum tis_defaults { + TIS_MEM_BASE = 0xFED40000, + TIS_MEM_LEN = 0x5000, + TIS_SHORT_TIMEOUT = 750, /*ms*/ + TIS_LONG_TIMEOUT = 2000, /*2 sec */ +}; + +#define TPM_TIMEOUT 5 + +#define TPM_ACCESS(t, l) (((uint8_t*)t->pages[l]) + 0x0000) +#define TPM_INT_ENABLE(t, l) ((uint32_t*)(((uint8_t*)t->pages[l]) + 0x0008)) +#define TPM_INT_VECTOR(t, l) (((uint8_t*)t->pages[l]) + 0x000C) +#define TPM_INT_STATUS(t, l) (((uint8_t*)t->pages[l]) + 0x0010) +#define TPM_INTF_CAPS(t, l) ((uint32_t*)(((uint8_t*)t->pages[l]) + 0x0014)) +#define TPM_STS(t, l) ((uint8_t*)(((uint8_t*)t->pages[l]) + 0x0018)) +#define TPM_DATA_FIFO(t, l) (((uint8_t*)t->pages[l]) + 0x0024) + +#define TPM_DID_VID(t, l) ((uint32_t*)(((uint8_t*)t->pages[l]) + 0x0F00)) +#define TPM_RID(t, l) (((uint8_t*)t->pages[l]) + 0x0F04) + +struct tpm_chip { + int enabled_localities; + int locality; + unsigned long baseaddr; + uint8_t* pages[5]; + int did, vid, rid; + + uint8_t data_buffer[TPM_BUFSIZE]; + int data_len; + + s_time_t timeout_a, timeout_b, timeout_c, timeout_d; + s_time_t duration[3]; + +#ifdef HAVE_LIBC + int fd; +#endif + + unsigned int irq; + struct wait_queue_head read_queue; + struct wait_queue_head int_queue; +}; + + +static void __init_tpm_chip(struct tpm_chip* tpm) { + tpm->enabled_localities = TPM_TIS_EN_LOCLALL; + tpm->locality = -1; + tpm->baseaddr = 0; + tpm->pages[0] = tpm->pages[1] = tpm->pages[2] = tpm->pages[3] = tpm->pages[4] = NULL; + tpm->vid = 0; + tpm->did = 0; + tpm->irq = 0; + init_waitqueue_head(&tpm->read_queue); + init_waitqueue_head(&tpm->int_queue); + + tpm->data_len = -1; + +#ifdef HAVE_LIBC + tpm->fd = -1; +#endif +} + +/* + * Returns max number of nsecs to wait + */ +s_time_t tpm_calc_ordinal_duration(struct tpm_chip *chip, + uint32_t ordinal) +{ + int duration_idx = TPM_UNDEFINED; + s_time_t duration = 0; + + if (ordinal < TPM_MAX_ORDINAL) + duration_idx = tpm_ordinal_duration[ordinal]; + else if ((ordinal & TPM_PROTECTED_ORDINAL_MASK) < + TPM_MAX_PROTECTED_ORDINAL) + duration_idx = + tpm_protected_ordinal_duration[ordinal & + TPM_PROTECTED_ORDINAL_MASK]; + + if (duration_idx != TPM_UNDEFINED) { + duration = chip->duration[duration_idx]; + } + + if (duration <= 0) { + return SECONDS(120); + } + else + { + return duration; + } +} + + +static int locality_enabled(struct tpm_chip* tpm, int l) { + return tpm->enabled_localities & (1 << l); +} + +static int check_locality(struct tpm_chip* tpm, int l) { + if(locality_enabled(tpm, l) && (ioread8(TPM_ACCESS(tpm, l)) & + (TPM_ACCESS_ACTIVE_LOCALITY | TPM_ACCESS_VALID)) == + (TPM_ACCESS_ACTIVE_LOCALITY | TPM_ACCESS_VALID)) { + return l; + } + return -1; +} + +void release_locality(struct tpm_chip* tpm, int l, int force) +{ + if (locality_enabled(tpm, l) && (force || (ioread8(TPM_ACCESS(tpm, l)) & + (TPM_ACCESS_REQUEST_PENDING | TPM_ACCESS_VALID)) == + (TPM_ACCESS_REQUEST_PENDING | TPM_ACCESS_VALID))) { + iowrite8(TPM_ACCESS(tpm, l), TPM_ACCESS_RELINQUISH_LOCALITY); + } +} + +int tpm_tis_request_locality(struct tpm_chip* tpm, int l) { + + s_time_t stop; + /*Make sure locality is valid */ + if(!locality_enabled(tpm, l)) { + printk("tpm_tis_change_locality() Tried to change to locality %d, but it is disabled or invalid!\n", l); + return -1; + } + /* Check if we already have the current locality */ + if(check_locality(tpm, l) >= 0) { + return tpm->locality = l; + } + /* Set the new locality*/ + iowrite8(TPM_ACCESS(tpm, l), TPM_ACCESS_REQUEST_USE); + + if(tpm->irq) { + /* Wait for interrupt */ + wait_event_deadline(tpm->int_queue, (check_locality(tpm, l) >= 0), NOW() + tpm->timeout_a); + + /* FIXME: Handle timeout event, should return error in that case */ + return l; + } else { + /* Wait for burstcount */ + stop = NOW() + tpm->timeout_a; + do { + if(check_locality(tpm, l) >= 0) { + return tpm->locality = l; + } + msleep(TPM_TIMEOUT); + } while(NOW() < stop); + } + + printk("REQ LOCALITY FAILURE\n"); + return -1; +} + +static uint8_t tpm_tis_status(struct tpm_chip* tpm) { + return ioread8(TPM_STS(tpm, tpm->locality)); +} + +/* This causes the current command to be aborted */ +static void tpm_tis_ready(struct tpm_chip* tpm) { + iowrite8(TPM_STS(tpm, tpm->locality), TPM_STS_COMMAND_READY); +} +#define tpm_tis_cancel_cmd(v) tpm_tis_ready(v) + +static int get_burstcount(struct tpm_chip* tpm) { + s_time_t stop; + int burstcnt; + + stop = NOW() + tpm->timeout_d; + do { + burstcnt = ioread8((TPM_STS(tpm, tpm->locality) + 1)); + burstcnt += ioread8(TPM_STS(tpm, tpm->locality) + 2) << 8; + + if (burstcnt) { + return burstcnt; + } + msleep(TPM_TIMEOUT); + } while(NOW() < stop); + return -EBUSY; +} + +static int wait_for_stat(struct tpm_chip* tpm, uint8_t mask, + unsigned long timeout, struct wait_queue_head* queue) { + s_time_t stop; + uint8_t status; + + status = tpm_tis_status(tpm); + if((status & mask) == mask) { + return 0; + } + + if(tpm->irq) { + wait_event_deadline(*queue, ((tpm_tis_status(tpm) & mask) == mask), timeout); + /* FIXME: Check for timeout and return -ETIME */ + return 0; + } else { + stop = NOW() + timeout; + do { + msleep(TPM_TIMEOUT); + status = tpm_tis_status(tpm); + if((status & mask) == mask) + return 0; + } while( NOW() < stop); + } + return -ETIME; +} + +static int recv_data(struct tpm_chip* tpm, uint8_t* buf, size_t count) { + int size = 0; + int burstcnt; + while( size < count && + wait_for_stat(tpm, + TPM_STS_DATA_AVAIL | TPM_STS_VALID, + tpm->timeout_c, + &tpm->read_queue) + == 0) { + burstcnt = get_burstcount(tpm); + for(; burstcnt > 0 && size < count; --burstcnt) + { + buf[size++] = ioread8(TPM_DATA_FIFO(tpm, tpm->locality)); + } + } + return size; +} + +int tpm_tis_recv(struct tpm_chip* tpm, uint8_t* buf, size_t count) { + int size = 0; + int expected, status; + + if (count < TPM_HEADER_SIZE) { + size = -EIO; + goto out; + } + + /* read first 10 bytes, including tag, paramsize, and result */ + if((size = + recv_data(tpm, buf, TPM_HEADER_SIZE)) < TPM_HEADER_SIZE) { + printk("Error reading tpm cmd header\n"); + goto out; + } + + expected = be32_to_cpu(*((uint32_t*)(buf + 2))); + if(expected > count) { + size = -EIO; + goto out; + } + + if((size += recv_data(tpm, & buf[TPM_HEADER_SIZE], + expected - TPM_HEADER_SIZE)) < expected) { + printk("Unable to read rest of tpm command size=%d expected=%d\n", size, expected); + size = -ETIME; + goto out; + } + + wait_for_stat(tpm, TPM_STS_VALID, tpm->timeout_c, &tpm->int_queue); + status = tpm_tis_status(tpm); + if(status & TPM_STS_DATA_AVAIL) { + printk("Error: left over data\n"); + size = -EIO; + goto out; + } + +out: + tpm_tis_ready(tpm); + release_locality(tpm, tpm->locality, 0); + return size; +} +int tpm_tis_send(struct tpm_chip* tpm, uint8_t* buf, size_t len) { + int rc; + int status, burstcnt = 0; + int count = 0; + uint32_t ordinal; + + if(tpm_tis_request_locality(tpm, tpm->locality) < 0) { + return -EBUSY; + } + + status = tpm_tis_status(tpm); + if((status & TPM_STS_COMMAND_READY) == 0) { + tpm_tis_ready(tpm); + if(wait_for_stat(tpm, TPM_STS_COMMAND_READY, tpm->timeout_b, &tpm->int_queue) < 0) { + rc = -ETIME; + goto out_err; + } + } + + while(count < len - 1) { + burstcnt = get_burstcount(tpm); + for(;burstcnt > 0 && count < len -1; --burstcnt) { + iowrite8(TPM_DATA_FIFO(tpm, tpm->locality), buf[count++]); + } + + wait_for_stat(tpm, TPM_STS_VALID, tpm->timeout_c, &tpm->int_queue); + status = tpm_tis_status(tpm); + if((status & TPM_STS_DATA_EXPECT) == 0) { + rc = -EIO; + goto out_err; + } + } + + /*Write last byte*/ + iowrite8(TPM_DATA_FIFO(tpm, tpm->locality), buf[count]); + wait_for_stat(tpm, TPM_STS_VALID, tpm->timeout_c, &tpm->read_queue); + status = tpm_tis_status(tpm); + if((status & TPM_STS_DATA_EXPECT) != 0) { + rc = -EIO; + goto out_err; + } + + /*go and do it*/ + iowrite8(TPM_STS(tpm, tpm->locality), TPM_STS_GO); + + if(tpm->irq) { + /*Wait for interrupt */ + ordinal = be32_to_cpu(*(buf + 6)); + if(wait_for_stat(tpm, + TPM_STS_DATA_AVAIL | TPM_STS_VALID, + tpm_calc_ordinal_duration(tpm, ordinal), + &tpm->read_queue) < 0) { + rc = -ETIME; + goto out_err; + } + } +#ifdef HAVE_LIBC + if(tpm->fd >= 0) { + files[tpm->fd].read = 0; + files[tpm->fd].tpm_tis.respgot = 0; + files[tpm->fd].tpm_tis.offset = 0; + } +#endif + return len; + +out_err: + tpm_tis_ready(tpm); + release_locality(tpm, tpm->locality, 0); + return rc; +} + +static void tpm_tis_irq_handler(evtchn_port_t port, struct pt_regs *regs, void* data) +{ + struct tpm_chip* tpm = data; + uint32_t interrupt; + int i; + + interrupt = ioread32(TPM_INT_STATUS(tpm, tpm->locality)); + if(interrupt == 0) { + return; + } + + if(interrupt & TPM_INTF_DATA_AVAIL_INT) { + wake_up(&tpm->read_queue); + } + if(interrupt & TPM_INTF_LOCALITY_CHANGE_INT) { + for(i = 0; i < 5; ++i) { + if(check_locality(tpm, i) >= 0) { + break; + } + } + } + if(interrupt & (TPM_INTF_LOCALITY_CHANGE_INT | TPM_INTF_STS_VALID_INT | + TPM_INTF_CMD_READY_INT)) { + wake_up(&tpm->int_queue); + } + + /* Clear interrupts handled with TPM_EOI */ + iowrite32(TPM_INT_STATUS(tpm, tpm->locality), interrupt); + ioread32(TPM_INT_STATUS(tpm, tpm->locality)); + return; +} + +/* + * Internal kernel interface to transmit TPM commands + */ +static ssize_t tpm_transmit(struct tpm_chip *chip, const uint8_t *buf, + size_t bufsiz) +{ + ssize_t rc; + uint32_t count, ordinal; + s_time_t stop; + + count = be32_to_cpu(*((uint32_t *) (buf + 2))); + ordinal = be32_to_cpu(*((uint32_t *) (buf + 6))); + if (count == 0) + return -ENODATA; + if (count > bufsiz) { + printk("Error: invalid count value %x %zx \n", count, bufsiz); + return -E2BIG; + } + + //down(&chip->tpm_mutex); + + if ((rc = tpm_tis_send(chip, (uint8_t *) buf, count)) < 0) { + printk("tpm_transmit: tpm_send: error %zd\n", rc); + goto out; + } + + if (chip->irq) + goto out_recv; + + stop = NOW() + tpm_calc_ordinal_duration(chip, ordinal); + do { + uint8_t status = tpm_tis_status(chip); + if ((status & (TPM_STS_DATA_AVAIL | TPM_STS_VALID)) == + (TPM_STS_DATA_AVAIL | TPM_STS_VALID)) + goto out_recv; + + if ((status == TPM_STS_COMMAND_READY)) { + printk("TPM Error: Operation Canceled\n"); + rc = -ECANCELED; + goto out; + } + + msleep(TPM_TIMEOUT); /* CHECK */ + rmb(); + } while (NOW() < stop); + + /* Cancel the command */ + tpm_tis_cancel_cmd(chip); + printk("TPM Operation Timed out\n"); + rc = -ETIME; + goto out; + +out_recv: + if((rc = tpm_tis_recv(chip, (uint8_t *) buf, bufsiz)) < 0) { + printk("tpm_transmit: tpm_recv: error %d\n", rc); + } +out: + //up(&chip->tpm_mutex); + return rc; +} + +static ssize_t transmit_cmd(struct tpm_chip *chip, struct tpm_cmd_t *cmd, + int len, const char *desc) +{ + int err; + + len = tpm_transmit(chip,(uint8_t *) cmd, len); + if (len < 0) + return len; + if (len == TPM_ERROR_SIZE) { + err = be32_to_cpu(cmd->header.out.return_code); + printk("A TPM error (%d) occurred %s\n", err, desc); + return err; + } + return 0; +} + +void tpm_get_timeouts(struct tpm_chip *chip) +{ + struct tpm_cmd_t tpm_cmd; + struct timeout_t *timeout_cap; + struct duration_t *duration_cap; + ssize_t rc; + uint32_t timeout; + + tpm_cmd.header.in = tpm_getcap_header; + tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP; + tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4); + tpm_cmd.params.getcap_in.subcap = TPM_CAP_PROP_TIS_TIMEOUT; + + if((rc = transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE, + "attempting to determine the timeouts")) != 0) { + printk("transmit failed %d\n", rc); + goto duration; + } + + if (be32_to_cpu(tpm_cmd.params.getcap_out.cap_size) + != 4 * sizeof(uint32_t)) { + printk("Out len check failure %lu \n", be32_to_cpu(tpm_cmd.header.out.length)); + goto duration; + } + + timeout_cap = &tpm_cmd.params.getcap_out.cap.timeout; + /* Don't overwrite default if value is 0 */ + timeout = be32_to_cpu(timeout_cap->a); + if (timeout) + chip->timeout_a = MICROSECS(timeout); /*Convert to msec */ + timeout = be32_to_cpu(timeout_cap->b); + if (timeout) + chip->timeout_b = MICROSECS(timeout); /*Convert to msec */ + timeout = be32_to_cpu(timeout_cap->c); + if (timeout) + chip->timeout_c = MICROSECS(timeout); /*Convert to msec */ + timeout = be32_to_cpu(timeout_cap->d); + if (timeout) + chip->timeout_d = MICROSECS(timeout); /*Convert to msec */ + +duration: + tpm_cmd.header.in = tpm_getcap_header; + tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP; + tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4); + tpm_cmd.params.getcap_in.subcap = TPM_CAP_PROP_TIS_DURATION; + + if((rc = transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE, + "attempting to determine the durations")) < 0) { + return; + } + + if (be32_to_cpu(tpm_cmd.params.getcap_out.cap_size) + != 3 * sizeof(uint32_t)) { + return; + } + duration_cap = &tpm_cmd.params.getcap_out.cap.duration; + chip->duration[TPM_SHORT] = be32_to_cpu(duration_cap->tpm_short); + /* The Broadcom BCM0102 chipset in a Dell Latitude D820 gets the above + * value wrong and apparently reports msecs rather than usecs. So we + * fix up the resulting too-small TPM_SHORT value to make things work. + */ + if (chip->duration[TPM_SHORT] < 10) { + chip->duration[TPM_SHORT] = MILLISECS(chip->duration[TPM_SHORT]); + } else { + chip->duration[TPM_SHORT] = MICROSECS(chip->duration[TPM_SHORT]); + } + + chip->duration[TPM_MEDIUM] = MICROSECS(be32_to_cpu(duration_cap->tpm_medium)); + chip->duration[TPM_LONG] = MICROSECS(be32_to_cpu(duration_cap->tpm_long)); +} + + + +void tpm_continue_selftest(struct tpm_chip* chip) { + uint8_t data[] = { + 0, 193, /* TPM_TAG_RQU_COMMAND */ + 0, 0, 0, 10, /* length */ + 0, 0, 0, 83, /* TPM_ORD_GetCapability */ + }; + + tpm_transmit(chip, data, sizeof(data)); +} + +ssize_t tpm_getcap(struct tpm_chip *chip, uint32_t subcap_id, cap_t *cap, + const char *desc) +{ + struct tpm_cmd_t tpm_cmd; + int rc; + + tpm_cmd.header.in = tpm_getcap_header; + if (subcap_id == CAP_VERSION_1_1 || subcap_id == CAP_VERSION_1_2) { + tpm_cmd.params.getcap_in.cap = subcap_id; + /*subcap field not necessary */ + tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(0); + tpm_cmd.header.in.length -= cpu_to_be32(sizeof(uint32_t)); + } else { + if (subcap_id == TPM_CAP_FLAG_PERM || + subcap_id == TPM_CAP_FLAG_VOL) + tpm_cmd.params.getcap_in.cap = TPM_CAP_FLAG; + else + tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP; + tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4); + tpm_cmd.params.getcap_in.subcap = subcap_id; + } + rc = transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE, desc); + if (!rc) + *cap = tpm_cmd.params.getcap_out.cap; + return rc; +} + + +struct tpm_chip* init_tpm_tis(unsigned long baseaddr, int localities, unsigned int irq) +{ + int i; + unsigned long addr; + struct tpm_chip* tpm = NULL; + uint32_t didvid; + uint32_t intfcaps; + uint32_t intmask; + + printk("============= Init TPM TIS Driver ==============\n"); + + /*Sanity check the localities input */ + if(localities & ~TPM_TIS_EN_LOCLALL) { + printk("init_tpm_tis() Invalid locality specification! %X\n", localities); + goto abort_egress; + } + + printk("IOMEM Machine Base Address: %lX\n", baseaddr); + + /* Create the tpm data structure */ + tpm = malloc(sizeof(struct tpm_chip)); + __init_tpm_chip(tpm); + + /* Set the enabled localities - if 0 we leave default as all enabled */ + if(localities != 0) { + tpm->enabled_localities = localities; + } + printk("Enabled Localities: "); + for(i = 0; i < 5; ++i) { + if(locality_enabled(tpm, i)) { + printk("%d ", i); + } + } + printk("\n"); + + /* Set the base machine address */ + tpm->baseaddr = baseaddr; + + /* Set default timeouts */ + tpm->timeout_a = MILLISECS(TIS_SHORT_TIMEOUT); + tpm->timeout_b = MILLISECS(TIS_LONG_TIMEOUT); + tpm->timeout_c = MILLISECS(TIS_SHORT_TIMEOUT); + tpm->timeout_d = MILLISECS(TIS_SHORT_TIMEOUT); + + /*Map the mmio pages */ + addr = tpm->baseaddr; + for(i = 0; i < 5; ++i) { + if(locality_enabled(tpm, i)) { + /* Map the page in now */ + if((tpm->pages[i] = ioremap_nocache(addr, PAGE_SIZE)) == NULL) { + printk("Unable to map iomem page a address %p\n", addr); + goto abort_egress; + } + + /* Set default locality to the first enabled one */ + if (tpm->locality < 0) { + if(tpm_tis_request_locality(tpm, i) < 0) { + printk("Unable to request locality %d??\n", i); + goto abort_egress; + } + } + } + addr += PAGE_SIZE; + } + + + /* Get the vendor and device ids */ + didvid = ioread32(TPM_DID_VID(tpm, tpm->locality)); + tpm->did = didvid >> 16; + tpm->vid = didvid & 0xFFFF; + + + /* Get the revision id */ + tpm->rid = ioread8(TPM_RID(tpm, tpm->locality)); + + printk("1.2 TPM (device-id=0x%X vendor-id = %X rev-id = %X)\n", tpm->did, tpm->vid, tpm->rid); + + intfcaps = ioread32(TPM_INTF_CAPS(tpm, tpm->locality)); + printk("TPM interface capabilities (0x%x):\n", intfcaps); + if (intfcaps & TPM_INTF_BURST_COUNT_STATIC) + printk("\tBurst Count Static\n"); + if (intfcaps & TPM_INTF_CMD_READY_INT) + printk("\tCommand Ready Int Support\n"); + if (intfcaps & TPM_INTF_INT_EDGE_FALLING) + printk("\tInterrupt Edge Falling\n"); + if (intfcaps & TPM_INTF_INT_EDGE_RISING) + printk("\tInterrupt Edge Rising\n"); + if (intfcaps & TPM_INTF_INT_LEVEL_LOW) + printk("\tInterrupt Level Low\n"); + if (intfcaps & TPM_INTF_INT_LEVEL_HIGH) + printk("\tInterrupt Level High\n"); + if (intfcaps & TPM_INTF_LOCALITY_CHANGE_INT) + printk("\tLocality Change Int Support\n"); + if (intfcaps & TPM_INTF_STS_VALID_INT) + printk("\tSts Valid Int Support\n"); + if (intfcaps & TPM_INTF_DATA_AVAIL_INT) + printk("\tData Avail Int Support\n"); + + /*Interupt setup */ + intmask = ioread32(TPM_INT_ENABLE(tpm, tpm->locality)); + + intmask |= TPM_INTF_CMD_READY_INT + | TPM_INTF_LOCALITY_CHANGE_INT | TPM_INTF_DATA_AVAIL_INT + | TPM_INTF_STS_VALID_INT; + + iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), intmask); + + /*If interupts are enabled, handle it */ + if(irq) { + if(irq != TPM_PROBE_IRQ) { + tpm->irq = irq; + } else { + /*FIXME add irq probing feature later */ + printk("IRQ probing not implemented\n"); + } + } + + if(tpm->irq) { + iowrite8(TPM_INT_VECTOR(tpm, tpm->locality), tpm->irq); + + if(bind_pirq(tpm->irq, 1, tpm_tis_irq_handler, tpm) != 0) { + printk("Unabled to request irq: %u for use\n", tpm->irq); + printk("Will use polling mode\n"); + tpm->irq = 0; + } else { + /* Clear all existing */ + iowrite32(TPM_INT_STATUS(tpm, tpm->locality), ioread32(TPM_INT_STATUS(tpm, tpm->locality))); + + /* Turn on interrupts */ + iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), intmask | TPM_GLOBAL_INT_ENABLE); + } + } + + tpm_get_timeouts(tpm); + tpm_continue_selftest(tpm); + + + return tpm; +abort_egress: + if(tpm != NULL) { + shutdown_tpm_tis(tpm); + } + return NULL; +} + +void shutdown_tpm_tis(struct tpm_chip* tpm){ + int i; + + printk("Shutting down tpm_tis device\n"); + + iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), ~TPM_GLOBAL_INT_ENABLE); + + /*Unmap all of the mmio pages */ + for(i = 0; i < 5; ++i) { + if(tpm->pages[i] != NULL) { + iounmap(tpm->pages[i], PAGE_SIZE); + tpm->pages[i] = NULL; + } + } + free(tpm); + return; +} + + +int tpm_tis_cmd(struct tpm_chip* tpm, uint8_t* req, size_t reqlen, uint8_t** resp, size_t* resplen) +{ + if(tpm->locality < 0) { + printk("tpm_tis_cmd() failed! locality not set!\n"); + return -1; + } + if(reqlen > TPM_BUFSIZE) { + reqlen = TPM_BUFSIZE; + } + memcpy(tpm->data_buffer, req, reqlen); + *resplen = tpm_transmit(tpm, tpm->data_buffer, TPM_BUFSIZE); + + *resp = malloc(*resplen); + memcpy(*resp, tpm->data_buffer, *resplen); + return 0; +} + +#ifdef HAVE_LIBC +int tpm_tis_open(struct tpm_chip* tpm) +{ + /* Silently prevent multiple opens */ + if(tpm->fd != -1) { + return tpm->fd; + } + + tpm->fd = alloc_fd(FTYPE_TPM_TIS); + printk("tpm_tis_open() -> %d\n", tpm->fd); + files[tpm->fd].tpm_tis.dev = tpm; + files[tpm->fd].tpm_tis.offset = 0; + files[tpm->fd].tpm_tis.respgot = 0; + return tpm->fd; +} + +int tpm_tis_posix_write(int fd, const uint8_t* buf, size_t count) +{ + struct tpm_chip* tpm; + tpm = files[fd].tpm_tis.dev; + + if(tpm->locality < 0) { + printk("tpm_tis_posix_write() failed! locality not set!\n"); + errno = EINPROGRESS; + return -1; + } + if(count == 0) { + return 0; + } + + /* Return an error if we are already processing a command */ + if(count > TPM_BUFSIZE) { + count = TPM_BUFSIZE; + } + /* Send the command now */ + memcpy(tpm->data_buffer, buf, count); + if((tpm->data_len = tpm_transmit(tpm, tpm->data_buffer, TPM_BUFSIZE)) < 0) { + errno = EIO; + return -1; + } + return count; +} + +int tpm_tis_posix_read(int fd, uint8_t* buf, size_t count) +{ + int rc; + struct tpm_chip* tpm; + tpm = files[fd].tpm_tis.dev; + + if(count == 0) { + return 0; + } + + /* If there is no tpm resp to read, return EIO */ + if(tpm->data_len < 0) { + errno = EIO; + return -1; + } + + + /* Handle EOF case */ + if(files[fd].tpm_tis.offset >= tpm->data_len) { + rc = 0; + } else { + rc = min(tpm->data_len - files[fd].tpm_tis.offset, count); + memcpy(buf, tpm->data_buffer + files[fd].tpm_tis.offset, rc); + } + files[fd].tpm_tis.offset += rc; + /* Reset the data pending flag */ + return rc; +} +int tpm_tis_posix_fstat(int fd, struct stat* buf) +{ + struct tpm_chip* tpm; + tpm = files[fd].tpm_tis.dev; + + buf->st_mode = O_RDWR; + buf->st_uid = 0; + buf->st_gid = 0; + buf->st_size = be32_to_cpu(*((uint32_t*)(tpm->data_buffer + 2))); + buf->st_atime = buf->st_mtime = buf->st_ctime = time(NULL); + return 0; +} + + +#endif diff --git a/extras/mini-os/tpmback.c b/extras/mini-os/tpmback.c new file mode 100644 index 0000000..b6ae2e6 --- /dev/null +++ b/extras/mini-os/tpmback.c @@ -0,0 +1,1128 @@ +/* + * Copyright (c) 2010-2012 United States Government, as represented by + * the Secretary of Defense. All rights reserved. + * + * This code has been derived from drivers/xen/tpmback/tpmback.c + * from the xen 2.6.18 linux kernel + * + * Copyright (c) 2005, IBM Corporation + * + * which was itself derived from drivers/xen/netback/netback.c + * from the xen 2.6.18 linux kernel + * + * Copyright (c) 2002-2004, K A Fraser + * + * This code has also been derived from drivers/xen/tpmback/xenbus.c + * from the xen 2.6.18 linux kernel + * + * Copyright (C) 2005 IBM Corporation + * Copyright (C) 2005 Rusty Russell + * + * This code has also been derived from drivers/xen/tpmback/interface.c + * from the xen 2.6.18 linux kernel + * + * Copyright (c) 2005, IBM Corporation + * + * which was itself also derived from drvivers/xen/netback/interface.c + * from the xen 2.6.18 linux kernel + * + * Copyright (c) 2004, Keir Fraser + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation, version 2 + * of the License + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + + +#ifndef HAVE_LIBC +#define strtoul simple_strtoul +#endif + +//#define TPMBACK_PRINT_DEBUG +#ifdef TPMBACK_PRINT_DEBUG +#define TPMBACK_DEBUG(fmt,...) printk("Tpmback:Debug("__FILE__":%d) " fmt, __LINE__, ##__VA_ARGS__) +#define TPMBACK_DEBUG_MORE(fmt,...) printk(fmt, ##__VA_ARGS__) +#else +#define TPMBACK_DEBUG(fmt,...) +#endif +#define TPMBACK_ERR(fmt,...) printk("Tpmback:Error " fmt, ##__VA_ARGS__) +#define TPMBACK_LOG(fmt,...) printk("Tpmback:Info " fmt, ##__VA_ARGS__) + +#define min(a,b) (((a) < (b)) ? (a) : (b)) + +/* Default size of the tpmif array at initialization */ +#define DEF_ARRAY_SIZE 1 + +/* tpmif and tpmdev flags */ +#define TPMIF_CLOSED 1 +#define TPMIF_REQ_READY 2 + +struct tpmif { + domid_t domid; + unsigned int handle; + + char* fe_path; + char* fe_state_path; + + /* Locally bound event channel*/ + evtchn_port_t evtchn; + + /* Shared page */ + tpmif_tx_interface_t* tx; + + /* pointer to TPMIF_RX_RING_SIZE pages */ + void** pages; + + enum xenbus_state state; + enum { DISCONNECTED, DISCONNECTING, CONNECTED } status; + + char* uuid; + + /* state flags */ + int flags; +}; +typedef struct tpmif tpmif_t; + +struct tpmback_dev { + + tpmif_t** tpmlist; + unsigned long num_tpms; + unsigned long num_alloc; + + struct gntmap map; + + /* True if at least one tpmif has a request to be handled */ + int flags; + + /* exclusive domains, see init_tpmback comment in tpmback.h */ + char** exclusive_uuids; + + xenbus_event_queue events; + + /* Callbacks */ + void (*open_callback)(domid_t, unsigned int); + void (*close_callback)(domid_t, unsigned int); + void (*suspend_callback)(domid_t, unsigned int); + void (*resume_callback)(domid_t, unsigned int); +}; +typedef struct tpmback_dev tpmback_dev_t; + +enum { EV_NONE, EV_NEWFE, EV_STCHNG } tpm_ev_enum; + +/* Global objects */ +static struct thread* eventthread = NULL; +static tpmback_dev_t gtpmdev = { + .tpmlist = NULL, + .num_tpms = 0, + .num_alloc = 0, + .flags = TPMIF_CLOSED, + .events = NULL, + .open_callback = NULL, + .close_callback = NULL, + .suspend_callback = NULL, + .resume_callback = NULL, +}; +struct wait_queue_head waitq; +int globalinit = 0; + +/************************************ + * TPMIF SORTED ARRAY FUNCTIONS + * tpmback_dev_t.tpmlist is a sorted array, sorted by domid and then handle number + * Duplicates are not allowed + * **********************************/ + +inline void tpmif_req_ready(tpmif_t* tpmif) { + tpmif->flags |= TPMIF_REQ_READY; + gtpmdev.flags |= TPMIF_REQ_READY; +} + +inline void tpmdev_check_req(void) { + int i; + int flags; + local_irq_save(flags); + for(i = 0; i < gtpmdev.num_tpms; ++i) { + if(gtpmdev.tpmlist[i]->flags & TPMIF_REQ_READY) { + gtpmdev.flags |= TPMIF_REQ_READY; + local_irq_restore(flags); + return; + } + } + gtpmdev.flags &= ~TPMIF_REQ_READY; + local_irq_restore(flags); +} + +inline void tpmif_req_finished(tpmif_t* tpmif) { + tpmif->flags &= ~TPMIF_REQ_READY; + tpmdev_check_req(); +} + +int __get_tpmif_index(int st, int n, domid_t domid, unsigned int handle) +{ + int i = st + n /2; + tpmif_t* tmp; + + if( n <= 0 ) + return -1; + + tmp = gtpmdev.tpmlist[i]; + if(domid == tmp->domid && tmp->handle == handle) { + return i; + } else if ( (domid < tmp->domid) || + (domid == tmp->domid && handle < tmp->handle)) { + return __get_tpmif_index(st, n/2, domid, handle); + } else { + return __get_tpmif_index(i + 1, n/2 - ((n +1) % 2), domid, handle); + } +} + +/* Returns the array index of the tpmif domid/handle. Returns -1 if no such tpmif exists */ +int get_tpmif_index(domid_t domid, unsigned int handle) +{ + int flags; + int index; + local_irq_save(flags); + index = __get_tpmif_index(0, gtpmdev.num_tpms, domid, handle); + local_irq_restore(flags); + return index; +} + +/* Returns the tpmif domid/handle or NULL if none exists */ +tpmif_t* get_tpmif(domid_t domid, unsigned int handle) +{ + int flags; + int i; + tpmif_t* ret; + local_irq_save(flags); + i = get_tpmif_index(domid, handle); + if (i < 0) { + ret = NULL; + } else { + ret = gtpmdev.tpmlist[i]; + } + local_irq_restore(flags); + return ret; +} + +/* Remove the given tpmif. Returns 0 if it was removed, -1 if it was not removed */ +int remove_tpmif(tpmif_t* tpmif) +{ + int i, j; + char* err; + int flags; + local_irq_save(flags); + + /* Find the index in the array if it exists */ + i = get_tpmif_index(tpmif->domid, tpmif->handle); + if (i < 0) { + goto error; + } + + /* Remove the interface from the list */ + for(j = i; j < gtpmdev.num_tpms - 1; ++j) { + gtpmdev.tpmlist[j] = gtpmdev.tpmlist[j+1]; + } + gtpmdev.tpmlist[j] = NULL; + --gtpmdev.num_tpms; + + /* If removed tpm was the only ready tpm, then we need to check and turn off the ready flag */ + tpmdev_check_req(); + + local_irq_restore(flags); + + /* Stop listening for events on this tpm interface */ + if((err = xenbus_unwatch_path_token(XBT_NIL, tpmif->fe_state_path, tpmif->fe_state_path))) { + TPMBACK_ERR("Unable to unwatch path token `%s' Error was %s Ignoring..\n", tpmif->fe_state_path, err); + free(err); + } + + return 0; +error: + local_irq_restore(flags); + return -1; +} + +/* Insert tpmif into dev->tpmlist. Returns 0 on success and non zero on error. + * It is an error to insert a tpmif with the same domid and handle + * number + * as something already in the list */ +int insert_tpmif(tpmif_t* tpmif) +{ + int flags; + unsigned int i, j; + tpmif_t* tmp; + char* err; + + local_irq_save(flags); + + /*Check if we need to allocate more space */ + if (gtpmdev.num_tpms == gtpmdev.num_alloc) { + gtpmdev.num_alloc *= 2; + gtpmdev.tpmlist = realloc(gtpmdev.tpmlist, gtpmdev.num_alloc); + } + + /*Find where to put the new interface */ + for(i = 0; i < gtpmdev.num_tpms; ++i) + { + tmp = gtpmdev.tpmlist[i]; + if(tpmif->domid == tmp->domid && tpmif->handle == tmp->handle) { + TPMBACK_ERR("Tried to insert duplicate tpm interface %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle); + goto error; + } + if((tpmif->domid < tmp->domid) || + (tpmif->domid == tmp->domid && tpmif->handle < tmp->handle)) { + break; + } + } + + /*Shift all the tpm pointers past i down one */ + for(j = gtpmdev.num_tpms; j > i; --j) { + gtpmdev.tpmlist[j] = gtpmdev.tpmlist[j-1]; + } + + /*Add the new interface */ + gtpmdev.tpmlist[i] = tpmif; + ++gtpmdev.num_tpms; + + /*Should not be needed, anything inserted with ready flag is probably an error */ + tpmdev_check_req(); + + local_irq_restore(flags); + + /*Listen for state changes on the new interface */ + if((err = xenbus_watch_path_token(XBT_NIL, tpmif->fe_state_path, tpmif->fe_state_path, >pmdev.events))) + { + /* if we got an error here we should carefully remove the interface and then return */ + TPMBACK_ERR("Unable to watch path token `%s' Error was %s\n", tpmif->fe_state_path, err); + free(err); + remove_tpmif(tpmif); + goto error_post_irq; + } + + return 0; +error: + local_irq_restore(flags); +error_post_irq: + return -1; +} + + +/***************** + * CHANGE BACKEND STATE + * *****************/ +/*Attempts to change the backend state in xenstore + * returns 0 on success and non-zero on error */ +int tpmif_change_state(tpmif_t* tpmif, enum xenbus_state state) +{ + char path[512]; + char *value; + char *err; + enum xenbus_state readst; + TPMBACK_DEBUG("Backend state change %u/%u from=%d to=%d\n", (unsigned int) tpmif->domid, tpmif->handle, tpmif->state, state); + if (tpmif->state == state) + return 0; + + snprintf(path, 512, "backend/vtpm/%u/%u/state", (unsigned int) tpmif->domid, tpmif->handle); + + if((err = xenbus_read(XBT_NIL, path, &value))) { + TPMBACK_ERR("Unable to read backend state %s, error was %s\n", path, err); + free(err); + return -1; + } + if(sscanf(value, "%d", &readst) != 1) { + TPMBACK_ERR("Non integer value (%s) in %s ??\n", value, path); + free(value); + return -1; + } + free(value); + + /* It's possible that the backend state got updated by hotplug or something else behind our back */ + if(readst != tpmif->state) { + TPMBACK_DEBUG("tpm interface state was %d but xenstore state was %d!\n", tpmif->state, readst); + tpmif->state = readst; + } + + /*If if the state isnt changing, then we dont update xenstore b/c we dont want to fire extraneous events */ + if(tpmif->state == state) { + return 0; + } + + /*update xenstore*/ + snprintf(path, 512, "backend/vtpm/%u/%u", (unsigned int) tpmif->domid, tpmif->handle); + if((err = xenbus_printf(XBT_NIL, path, "state", "%u", state))) { + TPMBACK_ERR("Error writing to xenstore %s, error was %s new state=%d\n", path, err, state); + free(err); + return -1; + } + + tpmif->state = state; + + return 0; +} +/********************************** + * TPMIF CREATION AND DELETION + * *******************************/ +inline tpmif_t* __init_tpmif(domid_t domid, unsigned int handle) +{ + tpmif_t* tpmif; + tpmif = malloc(sizeof(*tpmif)); + tpmif->domid = domid; + tpmif->handle = handle; + tpmif->fe_path = NULL; + tpmif->fe_state_path = NULL; + tpmif->state = XenbusStateInitialising; + tpmif->status = DISCONNECTED; + tpmif->tx = NULL; + tpmif->pages = NULL; + tpmif->flags = 0; + tpmif->uuid = NULL; + return tpmif; +} + +void __free_tpmif(tpmif_t* tpmif) +{ + if(tpmif->pages) { + free(tpmif->pages); + } + if(tpmif->fe_path) { + free(tpmif->fe_path); + } + if(tpmif->fe_state_path) { + free(tpmif->fe_state_path); + } + if(tpmif->uuid) { + free(tpmif->uuid); + } + free(tpmif); +} +/* Creates a new tpm interface, adds it to the sorted array and returns it. + * returns NULL on error + * If the tpm interface already exists, it is returned*/ +tpmif_t* new_tpmif(domid_t domid, unsigned int handle) +{ + tpmif_t* tpmif; + char* err; + char path[512]; + + /* Make sure we haven't already created this tpm + * Double events can occur */ + if((tpmif = get_tpmif(domid, handle)) != NULL) { + return tpmif; + } + + tpmif = __init_tpmif(domid, handle); + + /* Get the uuid from xenstore */ + snprintf(path, 512, "backend/vtpm/%u/%u/uuid", (unsigned int) domid, handle); + if((err = xenbus_read(XBT_NIL, path, &tpmif->uuid))) { + TPMBACK_ERR("Error reading %s, Error = %s\n", path, err); + free(err); + goto error; + } + + /* Do the exclusive uuid check now */ + if(gtpmdev.exclusive_uuids != NULL) { + char** ptr; + + /* Check that its in the whitelist */ + for(ptr = gtpmdev.exclusive_uuids; *ptr != NULL; ++ptr) { + if(!strcmp(tpmif->uuid, *ptr)) { + break; + } + } + /* If *ptr == NULL then we went through the whole list without a match, so close the connection */ + if(*ptr == NULL) { + tpmif_change_state(tpmif, XenbusStateClosed); + TPMBACK_ERR("Frontend %u/%u tried to connect with invalid uuid=%s\n", (unsigned int) domid, handle, tpmif->uuid); + goto error; + } + } + + /* allocate pages to be used for shared mapping */ + if((tpmif->pages = malloc(sizeof(void*) * TPMIF_TX_RING_SIZE)) == NULL) { + goto error; + } + memset(tpmif->pages, 0, sizeof(void*) * TPMIF_TX_RING_SIZE); + + if(tpmif_change_state(tpmif, XenbusStateInitWait)) { + goto error; + } + + snprintf(path, 512, "backend/vtpm/%u/%u/frontend", (unsigned int) domid, handle); + if((err = xenbus_read(XBT_NIL, path, &tpmif->fe_path))) { + TPMBACK_ERR("Error creating new tpm instance xenbus_read(%s), Error = %s", path, err); + free(err); + goto error; + } + + /*Set the state path */ + tpmif->fe_state_path = malloc(strlen(tpmif->fe_path) + 7); + strcpy(tpmif->fe_state_path, tpmif->fe_path); + strcat(tpmif->fe_state_path, "/state"); + + if(insert_tpmif(tpmif)) { + goto error; + } + TPMBACK_DEBUG("New tpmif %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle); + /* Do the callback now */ + if(gtpmdev.open_callback) { + gtpmdev.open_callback(tpmif->domid, tpmif->handle); + } + return tpmif; +error: + __free_tpmif(tpmif); + return NULL; + +} + +/* Removes tpmif from dev->tpmlist and frees it's memory usage */ +void free_tpmif(tpmif_t* tpmif) +{ + char* err; + char path[512]; + TPMBACK_DEBUG("Free tpmif %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle); + if(tpmif->flags & TPMIF_CLOSED) { + TPMBACK_ERR("Tried to free an instance twice! Theres a bug somewhere!\n"); + BUG(); + } + tpmif->flags = TPMIF_CLOSED; + + tpmif_change_state(tpmif, XenbusStateClosing); + + /* Unmap share page and unbind event channel */ + if(tpmif->status == CONNECTED) { + tpmif->status = DISCONNECTING; + mask_evtchn(tpmif->evtchn); + + if(gntmap_munmap(>pmdev.map, (unsigned long)tpmif->tx, 1)) { + TPMBACK_ERR("%u/%u Error occured while trying to unmap shared page\n", (unsigned int) tpmif->domid, tpmif->handle); + } + + unbind_evtchn(tpmif->evtchn); + } + tpmif->status = DISCONNECTED; + tpmif_change_state(tpmif, XenbusStateClosed); + + /* Do the callback now */ + if(gtpmdev.close_callback) { + gtpmdev.close_callback(tpmif->domid, tpmif->handle); + } + + /* remove from array */ + remove_tpmif(tpmif); + + /* Wake up anyone possibly waiting on this interface and let them exit */ + wake_up(&waitq); + schedule(); + + /* Remove the old xenbus entries */ + snprintf(path, 512, "backend/vtpm/%u/%u", (unsigned int) tpmif->domid, tpmif->handle); + if((err = xenbus_rm(XBT_NIL, path))) { + TPMBACK_ERR("Error cleaning up xenbus entries path=%s error=%s\n", path, err); + free(err); + } + + TPMBACK_LOG("Frontend %u/%u disconnected\n", (unsigned int) tpmif->domid, tpmif->handle); + + /* free memory */ + __free_tpmif(tpmif); + +} + +/********************** + * REMAINING TPMBACK FUNCTIONS + * ********************/ + +/*Event channel handler */ +void tpmback_handler(evtchn_port_t port, struct pt_regs *regs, void *data) +{ + tpmif_t* tpmif = (tpmif_t*) data; + tpmif_tx_request_t* tx = &tpmif->tx->ring[0].req; + /* Throw away 0 size events, these can trigger from event channel unmasking */ + if(tx->size == 0) + return; + + TPMBACK_DEBUG("EVENT CHANNEL FIRE %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle); + tpmif_req_ready(tpmif); + wake_up(&waitq); + +} + +/* Connect to frontend */ +int connect_fe(tpmif_t* tpmif) +{ + char path[512]; + char* err, *value; + uint32_t domid; + grant_ref_t ringref; + evtchn_port_t evtchn; + + /* If already connected then quit */ + if (tpmif->status == CONNECTED) { + TPMBACK_DEBUG("%u/%u tried to connect while it was already connected?\n", (unsigned int) tpmif->domid, tpmif->handle); + return 0; + } + + /* Fetch the grant reference */ + snprintf(path, 512, "%s/ring-ref", tpmif->fe_path); + if((err = xenbus_read(XBT_NIL, path, &value))) { + TPMBACK_ERR("Error creating new tpm instance xenbus_read(%s) Error = %s", path, err); + free(err); + return -1; + } + if(sscanf(value, "%d", &ringref) != 1) { + TPMBACK_ERR("Non integer value (%s) in %s ??\n", value, path); + free(value); + return -1; + } + free(value); + + + /* Fetch the event channel*/ + snprintf(path, 512, "%s/event-channel", tpmif->fe_path); + if((err = xenbus_read(XBT_NIL, path, &value))) { + TPMBACK_ERR("Error creating new tpm instance xenbus_read(%s) Error = %s", path, err); + free(err); + return -1; + } + if(sscanf(value, "%d", &evtchn) != 1) { + TPMBACK_ERR("Non integer value (%s) in %s ??\n", value, path); + free(value); + return -1; + } + free(value); + + domid = tpmif->domid; + if((tpmif->tx = gntmap_map_grant_refs(>pmdev.map, 1, &domid, 0, &ringref, PROT_READ | PROT_WRITE)) == NULL) { + TPMBACK_ERR("Failed to map grant reference %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle); + return -1; + } + memset(tpmif->tx, 0, PAGE_SIZE); + + /*Bind the event channel */ + if((evtchn_bind_interdomain(tpmif->domid, evtchn, tpmback_handler, tpmif, &tpmif->evtchn))) + { + TPMBACK_ERR("%u/%u Unable to bind to interdomain event channel!\n", (unsigned int) tpmif->domid, tpmif->handle); + goto error_post_map; + } + unmask_evtchn(tpmif->evtchn); + + /* Write the ready flag and change status to connected */ + snprintf(path, 512, "backend/vtpm/%u/%u", (unsigned int) tpmif->domid, tpmif->handle); + if((err = xenbus_printf(XBT_NIL, path, "ready", "%u", 1))) { + TPMBACK_ERR("%u/%u Unable to write ready flag on connect_fe()\n", (unsigned int) tpmif->domid, tpmif->handle); + free(err); + goto error_post_evtchn; + } + tpmif->status = CONNECTED; + if((tpmif_change_state(tpmif, XenbusStateConnected))){ + goto error_post_evtchn; + } + + TPMBACK_LOG("Frontend %u/%u connected\n", (unsigned int) tpmif->domid, tpmif->handle); + + return 0; +error_post_evtchn: + mask_evtchn(tpmif->evtchn); + unbind_evtchn(tpmif->evtchn); +error_post_map: + gntmap_munmap(>pmdev.map, (unsigned long)tpmif->tx, 1); + return -1; +} + +static int frontend_changed(tpmif_t* tpmif) +{ + int state = xenbus_read_integer(tpmif->fe_state_path); + if(state < 0) { + state = XenbusStateUnknown; + } + + TPMBACK_DEBUG("Frontend %u/%u state changed to %d\n", (unsigned int) tpmif->domid, tpmif->handle, state); + + switch (state) { + case XenbusStateInitialising: + case XenbusStateInitialised: + break; + + case XenbusStateConnected: + if(connect_fe(tpmif)) { + TPMBACK_ERR("Failed to connect to front end %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle); + tpmif_change_state(tpmif, XenbusStateClosed); + return -1; + } + break; + + case XenbusStateClosing: + tpmif_change_state(tpmif, XenbusStateClosing); + break; + + case XenbusStateUnknown: /* keep it here */ + case XenbusStateClosed: + free_tpmif(tpmif); + break; + + default: + TPMBACK_DEBUG("BAD STATE CHANGE %u/%u state = %d for tpmif\n", (unsigned int) tpmif->domid, tpmif->handle, state); + return -1; + } + return 0; +} + + +/* parses the string that comes out of xenbus_watch_wait_return. */ +static int parse_eventstr(const char* evstr, domid_t* domid, unsigned int* handle) +{ + int ret; + char cmd[40]; + char* err; + char* value; + unsigned int udomid = 0; + tpmif_t* tpmif; + /* First check for new frontends, this occurs when /backend/vtpm// gets created. Note we what the sscanf to fail on the last %s */ + if (sscanf(evstr, "backend/vtpm/%u/%u/%40s", &udomid, handle, cmd) == 2) { + *domid = udomid; + /* Make sure the entry exists, if this event triggers because the entry dissapeared then ignore it */ + if((err = xenbus_read(XBT_NIL, evstr, &value))) { + free(err); + return EV_NONE; + } + free(value); + /* Make sure the tpmif entry does not already exist, this should not happen */ + if((tpmif = get_tpmif(*domid, *handle)) != NULL) { + TPMBACK_DEBUG("Duplicate tpm entries! %u %u\n", tpmif->domid, tpmif->handle); + return EV_NONE; + } + return EV_NEWFE; + } else if((ret = sscanf(evstr, "/local/domain/%u/device/vtpm/%u/%40s", &udomid, handle, cmd)) == 3) { + *domid = udomid; + if (!strcmp(cmd, "state")) + return EV_STCHNG; + } + return EV_NONE; +} + +void handle_backend_event(char* evstr) { + tpmif_t* tpmif; + domid_t domid; + unsigned int handle; + int event; + + TPMBACK_DEBUG("Xenbus Event: %s\n", evstr); + + event = parse_eventstr(evstr, &domid, &handle); + + switch(event) { + case EV_NEWFE: + if(new_tpmif(domid, handle) == NULL) { + TPMBACK_ERR("Failed to create new tpm instance %u/%u\n", (unsigned int) domid, handle); + } + wake_up(&waitq); + break; + case EV_STCHNG: + if((tpmif = get_tpmif(domid, handle))) { + frontend_changed(tpmif); + } else { + TPMBACK_DEBUG("Event Received for non-existant tpm! instance=%u/%u xenbus_event=%s\n", (unsigned int) domid, handle, evstr); + } + break; + } +} + +/* Runs through the given path and creates events recursively + * for all of its children. + * @path - xenstore path to scan */ +static void generate_backend_events(const char* path) +{ + char* err; + int i, len; + char **dirs; + char *entry; + + if((err = xenbus_ls(XBT_NIL, path, &dirs)) != NULL) { + free(err); + return; + } + + for(i = 0; dirs[i] != NULL; ++i) { + len = strlen(path) + strlen(dirs[i]) + 2; + entry = malloc(len); + snprintf(entry, len, "%s/%s", path, dirs[i]); + + /* Generate and handle event for the entry itself */ + handle_backend_event(entry); + + /* Do children */ + generate_backend_events(entry); + + /* Cleanup */ + free(entry); + free(dirs[i]); + } + free(dirs); + return; +} + +char* tpmback_get_uuid(domid_t domid, unsigned int handle) +{ + tpmif_t* tpmif; + if((tpmif = get_tpmif(domid, handle)) == NULL) { + TPMBACK_DEBUG("get_uuid() failed, %u/%u is an invalid frontend\n", (unsigned int) domid, handle); + return NULL; + } + + return tpmif->uuid; +} + +void tpmback_set_open_callback(void (*cb)(domid_t, unsigned int)) +{ + gtpmdev.open_callback = cb; +} +void tpmback_set_close_callback(void (*cb)(domid_t, unsigned int)) +{ + gtpmdev.close_callback = cb; +} +void tpmback_set_suspend_callback(void (*cb)(domid_t, unsigned int)) +{ + gtpmdev.suspend_callback = cb; +} +void tpmback_set_resume_callback(void (*cb)(domid_t, unsigned int)) +{ + gtpmdev.resume_callback = cb; +} + +static void event_listener(void) +{ + const char* bepath = "backend/vtpm"; + char **path; + char* err; + + /* Setup the backend device watch */ + if((err = xenbus_watch_path_token(XBT_NIL, bepath, bepath, >pmdev.events)) != NULL) { + TPMBACK_ERR("xenbus_watch_path_token(%s) failed with error %s!\n", bepath, err); + free(err); + goto egress; + } + + /* Check for any frontends that connected before we set the watch. + * This is almost guaranteed to happen if both domains are started + * immediatly one after the other. + * We do this by manually generating events on everything in the backend + * path */ + generate_backend_events(bepath); + + /* Wait and listen for changes in frontend connections */ + while(1) { + path = xenbus_wait_for_watch_return(>pmdev.events); + + /*If quit flag was set then exit */ + if(gtpmdev.flags & TPMIF_CLOSED) { + TPMBACK_DEBUG("listener thread got quit event. Exiting..\n"); + free(path); + break; + } + handle_backend_event(*path); + free(path); + + } + + if((err = xenbus_unwatch_path_token(XBT_NIL, bepath, bepath)) != NULL) { + free(err); + } +egress: + return; +} + +void event_thread(void* p) { + event_listener(); +} + +void init_tpmback(char** exclusive_uuids) +{ + if(!globalinit) { + init_waitqueue_head(&waitq); + globalinit = 1; + } + printk("============= Init TPM BACK ================\n"); + gtpmdev.tpmlist = malloc(sizeof(tpmif_t*) * DEF_ARRAY_SIZE); + gtpmdev.num_alloc = DEF_ARRAY_SIZE; + gtpmdev.num_tpms = 0; + gtpmdev.flags = 0; + gtpmdev.exclusive_uuids = exclusive_uuids; + + gtpmdev.open_callback = gtpmdev.close_callback = NULL; + gtpmdev.suspend_callback = gtpmdev.resume_callback = NULL; + + eventthread = create_thread("tpmback-listener", event_thread, NULL); + +} + +void shutdown_tpmback(void) +{ + /* Disable callbacks */ + gtpmdev.open_callback = gtpmdev.close_callback = NULL; + gtpmdev.suspend_callback = gtpmdev.resume_callback = NULL; + + TPMBACK_LOG("Shutting down tpm backend\n"); + /* Set the quit flag */ + gtpmdev.flags = TPMIF_CLOSED; + + //printk("num tpms is %d\n", gtpmdev.num_tpms); + /*Free all backend instances */ + while(gtpmdev.num_tpms) { + free_tpmif(gtpmdev.tpmlist[0]); + } + free(gtpmdev.tpmlist); + gtpmdev.tpmlist = NULL; + gtpmdev.num_alloc = 0; + + /* Wake up anyone possibly waiting on the device and let them exit */ + wake_up(&waitq); + schedule(); +} + +inline void init_tpmcmd(tpmcmd_t* tpmcmd, domid_t domid, unsigned int handle, char* uuid) +{ + tpmcmd->domid = domid; + tpmcmd->handle = handle; + tpmcmd->uuid = uuid; + tpmcmd->req = NULL; + tpmcmd->req_len = 0; + tpmcmd->resp = NULL; + tpmcmd->resp_len = 0; +} + +tpmcmd_t* get_request(tpmif_t* tpmif) { + tpmcmd_t* cmd; + tpmif_tx_request_t* tx; + int offset; + int tocopy; + int i; + uint32_t domid; + int flags; + + local_irq_save(flags); + + /* Allocate the cmd object to hold the data */ + if((cmd = malloc(sizeof(*cmd))) == NULL) { + goto error; + } + init_tpmcmd(cmd, tpmif->domid, tpmif->handle, tpmif->uuid); + + tx = &tpmif->tx->ring[0].req; + cmd->req_len = tx->size; + /* Allocate the buffer */ + if(cmd->req_len) { + if((cmd->req = malloc(cmd->req_len)) == NULL) { + goto error; + } + } + /* Copy the bits from the shared pages */ + offset = 0; + for(i = 0; i < TPMIF_TX_RING_SIZE && offset < cmd->req_len; ++i) { + tx = &tpmif->tx->ring[i].req; + + /* Map the page with the data */ + domid = (uint32_t)tpmif->domid; + if((tpmif->pages[i] = gntmap_map_grant_refs(>pmdev.map, 1, &domid, 0, &tx->ref, PROT_READ)) == NULL) { + TPMBACK_ERR("%u/%u Unable to map shared page during read!\n", (unsigned int) tpmif->domid, tpmif->handle); + goto error; + } + + /* do the copy now */ + tocopy = min(cmd->req_len - offset, PAGE_SIZE); + memcpy(&cmd->req[offset], tpmif->pages[i], tocopy); + offset += tocopy; + + /* release the page */ + gntmap_munmap(>pmdev.map, (unsigned long)tpmif->pages[i], 1); + + } + +#ifdef TPMBACK_PRINT_DEBUG + TPMBACK_DEBUG("Received Tpm Command from %u/%u of size %u", (unsigned int) tpmif->domid, tpmif->handle, cmd->req_len); + for(i = 0; i < cmd->req_len; ++i) { + if (!(i % 30)) { + TPMBACK_DEBUG_MORE("\n"); + } + TPMBACK_DEBUG_MORE("%02hhX ", cmd->req[i]); + } + TPMBACK_DEBUG_MORE("\n\n"); +#endif + + local_irq_restore(flags); + return cmd; +error: + if(cmd != NULL) { + if (cmd->req != NULL) { + free(cmd->req); + cmd->req = NULL; + } + free(cmd); + cmd = NULL; + } + local_irq_restore(flags); + return NULL; + +} + +void send_response(tpmcmd_t* cmd, tpmif_t* tpmif) +{ + tpmif_tx_request_t* tx; + int offset; + int i; + uint32_t domid; + int tocopy; + int flags; + + local_irq_save(flags); + + tx = &tpmif->tx->ring[0].req; + tx->size = cmd->resp_len; + + offset = 0; + for(i = 0; i < TPMIF_TX_RING_SIZE && offset < cmd->resp_len; ++i) { + tx = &tpmif->tx->ring[i].req; + + /* Map the page with the data */ + domid = (uint32_t)tpmif->domid; + if((tpmif->pages[i] = gntmap_map_grant_refs(>pmdev.map, 1, &domid, 0, &tx->ref, PROT_WRITE)) == NULL) { + TPMBACK_ERR("%u/%u Unable to map shared page during write!\n", (unsigned int) tpmif->domid, tpmif->handle); + goto error; + } + + /* do the copy now */ + tocopy = min(cmd->resp_len - offset, PAGE_SIZE); + memcpy(tpmif->pages[i], &cmd->resp[offset], tocopy); + offset += tocopy; + + /* release the page */ + gntmap_munmap(>pmdev.map, (unsigned long)tpmif->pages[i], 1); + + } + +#ifdef TPMBACK_PRINT_DEBUG + TPMBACK_DEBUG("Sent response to %u/%u of size %u", (unsigned int) tpmif->domid, tpmif->handle, cmd->resp_len); + for(i = 0; i < cmd->resp_len; ++i) { + if (!(i % 30)) { + TPMBACK_DEBUG_MORE("\n"); + } + TPMBACK_DEBUG_MORE("%02hhX ", cmd->resp[i]); + } + TPMBACK_DEBUG_MORE("\n\n"); +#endif + /* clear the ready flag and send the event channel notice to the frontend */ + tpmif_req_finished(tpmif); + notify_remote_via_evtchn(tpmif->evtchn); +error: + local_irq_restore(flags); + return; +} + +tpmcmd_t* tpmback_req_any(void) +{ + int i; + /* Block until something has a request */ + wait_event(waitq, (gtpmdev.flags & (TPMIF_REQ_READY | TPMIF_CLOSED))); + + /* Check if were shutting down */ + if(gtpmdev.flags & TPMIF_CLOSED) { + /* if something was waiting for us to give up the queue so it can shutdown, let it finish */ + schedule(); + return NULL; + } + + for(i = 0; i < gtpmdev.num_tpms; ++i) { + if(gtpmdev.tpmlist[i]->flags & TPMIF_REQ_READY) { + return get_request(gtpmdev.tpmlist[i]); + } + } + + TPMBACK_ERR("backend request ready flag was set but no interfaces were actually ready\n"); + return NULL; +} + +tpmcmd_t* tpmback_req(domid_t domid, unsigned int handle) +{ + tpmif_t* tpmif; + tpmif = get_tpmif(domid, handle); + if(tpmif == NULL) { + return NULL; + } + + wait_event(waitq, (tpmif->flags & (TPMIF_REQ_READY | TPMIF_CLOSED) || gtpmdev.flags & TPMIF_CLOSED)); + + /* Check if were shutting down */ + if(tpmif->flags & TPMIF_CLOSED || gtpmdev.flags & TPMIF_CLOSED) { + /* if something was waiting for us to give up the queue so it can free this instance, let it finish */ + schedule(); + return NULL; + } + + return get_request(tpmif); +} + +void tpmback_resp(tpmcmd_t* tpmcmd) +{ + tpmif_t* tpmif; + + /* Get the associated interface, if it doesnt exist then just quit */ + tpmif = get_tpmif(tpmcmd->domid, tpmcmd->handle); + if(tpmif == NULL) { + TPMBACK_ERR("Tried to send a reponse to non existant frontend %u/%u\n", (unsigned int) tpmcmd->domid, tpmcmd->handle); + goto end; + } + + if(!(tpmif->flags & TPMIF_REQ_READY)) { + TPMBACK_ERR("Tried to send response to a frontend that was not waiting for one %u/%u\n", (unsigned int) tpmcmd->domid, tpmcmd->handle); + goto end; + } + + /* Send response to frontend */ + send_response(tpmcmd, tpmif); + +end: + if(tpmcmd->req != NULL) { + free(tpmcmd->req); + } + free(tpmcmd); + return; +} + +int tpmback_wait_for_frontend_connect(domid_t *domid, unsigned int *handle) +{ + tpmif_t* tpmif; + int flags; + wait_event(waitq, ((gtpmdev.num_tpms > 0) || gtpmdev.flags & TPMIF_CLOSED)); + if(gtpmdev.flags & TPMIF_CLOSED) { + return -1; + } + local_irq_save(flags); + tpmif = gtpmdev.tpmlist[0]; + *domid = tpmif->domid; + *handle = tpmif->handle; + local_irq_restore(flags); + + return 0; +} + +int tpmback_num_frontends(void) +{ + return gtpmdev.num_tpms; +} diff --git a/extras/mini-os/tpmfront.c b/extras/mini-os/tpmfront.c new file mode 100644 index 0000000..0218d7f --- /dev/null +++ b/extras/mini-os/tpmfront.c @@ -0,0 +1,608 @@ +/* + * Copyright (c) 2010-2012 United States Government, as represented by + * the Secretary of Defense. All rights reserved. + * + * This code has been derived from drivers/char/tpm_vtpm.c + * from the xen 2.6.18 linux kernel + * + * Copyright (C) 2006 IBM Corporation + * + * This code has also been derived from drivers/char/tpm_xen.c + * from the xen 2.6.18 linux kernel + * + * Copyright (c) 2005, IBM Corporation + * + * which was itself derived from drivers/xen/netfront/netfront.c + * from the linux kernel + * + * Copyright (c) 2002-2004, K A Fraser + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation, version 2 of the + * License. + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +//#define TPMFRONT_PRINT_DEBUG +#ifdef TPMFRONT_PRINT_DEBUG +#define TPMFRONT_DEBUG(fmt,...) printk("Tpmfront:Debug("__FILE__":%d) " fmt, __LINE__, ##__VA_ARGS__) +#define TPMFRONT_DEBUG_MORE(fmt,...) printk(fmt, ##__VA_ARGS__) +#else +#define TPMFRONT_DEBUG(fmt,...) +#endif +#define TPMFRONT_ERR(fmt,...) printk("Tpmfront:Error " fmt, ##__VA_ARGS__) +#define TPMFRONT_LOG(fmt,...) printk("Tpmfront:Info " fmt, ##__VA_ARGS__) + +#define min(a,b) (((a) < (b)) ? (a) : (b)) + +void tpmfront_handler(evtchn_port_t port, struct pt_regs *regs, void *data) { + struct tpmfront_dev* dev = (struct tpmfront_dev*) data; + /*If we get a response when we didnt make a request, just ignore it */ + if(!dev->waiting) { + return; + } + + dev->waiting = 0; +#ifdef HAVE_LIBC + if(dev->fd >= 0) { + files[dev->fd].read = 1; + } +#endif + wake_up(&dev->waitq); +} + +static int publish_xenbus(struct tpmfront_dev* dev) { + xenbus_transaction_t xbt; + int retry; + char* err; + /* Write the grant reference and event channel to xenstore */ +again: + if((err = xenbus_transaction_start(&xbt))) { + TPMFRONT_ERR("Unable to start xenbus transaction, error was %s\n", err); + free(err); + return -1; + } + + if((err = xenbus_printf(xbt, dev->nodename, "ring-ref", "%u", (unsigned int) dev->ring_ref))) { + TPMFRONT_ERR("Unable to write %s/ring-ref, error was %s\n", dev->nodename, err); + free(err); + goto abort_transaction; + } + + if((err = xenbus_printf(xbt, dev->nodename, "event-channel", "%u", (unsigned int) dev->evtchn))) { + TPMFRONT_ERR("Unable to write %s/event-channel, error was %s\n", dev->nodename, err); + free(err); + goto abort_transaction; + } + + if((err = xenbus_transaction_end(xbt, 0, &retry))) { + TPMFRONT_ERR("Unable to complete xenbus transaction, error was %s\n", err); + free(err); + return -1; + } + if(retry) { + goto again; + } + + return 0; +abort_transaction: + if((err = xenbus_transaction_end(xbt, 1, &retry))) { + free(err); + } + return -1; +} + +static int wait_for_backend_connect(xenbus_event_queue* events, char* path) +{ + int state; + + TPMFRONT_LOG("Waiting for backend connection..\n"); + /* Wait for the backend to connect */ + while(1) { + state = xenbus_read_integer(path); + if ( state < 0) + state = XenbusStateUnknown; + switch(state) { + /* Bad states, we quit with error */ + case XenbusStateUnknown: + case XenbusStateClosing: + case XenbusStateClosed: + TPMFRONT_ERR("Unable to connect to backend\n"); + return -1; + /* If backend is connected then break out of loop */ + case XenbusStateConnected: + TPMFRONT_LOG("Backend Connected\n"); + return 0; + default: + xenbus_wait_for_watch(events); + } + } + +} + +static int wait_for_backend_closed(xenbus_event_queue* events, char* path) +{ + int state; + + TPMFRONT_LOG("Waiting for backend to close..\n"); + while(1) { + state = xenbus_read_integer(path); + if ( state < 0) + state = XenbusStateUnknown; + switch(state) { + case XenbusStateUnknown: + TPMFRONT_ERR("Backend Unknown state, forcing shutdown\n"); + return -1; + case XenbusStateClosed: + TPMFRONT_LOG("Backend Closed\n"); + return 0; + default: + xenbus_wait_for_watch(events); + } + } + +} + +static int wait_for_backend_state_changed(struct tpmfront_dev* dev, XenbusState state) { + char* err; + int ret = 0; + xenbus_event_queue events = NULL; + char path[512]; + + snprintf(path, 512, "%s/state", dev->bepath); + /*Setup the watch to wait for the backend */ + if((err = xenbus_watch_path_token(XBT_NIL, path, path, &events))) { + TPMFRONT_ERR("Could not set a watch on %s, error was %s\n", path, err); + free(err); + return -1; + } + + /* Do the actual wait loop now */ + switch(state) { + case XenbusStateConnected: + ret = wait_for_backend_connect(&events, path); + break; + case XenbusStateClosed: + ret = wait_for_backend_closed(&events, path); + break; + default: + break; + } + + if((err = xenbus_unwatch_path_token(XBT_NIL, path, path))) { + TPMFRONT_ERR("Unable to unwatch %s, error was %s, ignoring..\n", path, err); + free(err); + } + return ret; +} + +static int tpmfront_connect(struct tpmfront_dev* dev) +{ + char* err; + /* Create shared page */ + dev->tx = (tpmif_tx_interface_t*) alloc_page(); + if(dev->tx == NULL) { + TPMFRONT_ERR("Unable to allocate page for shared memory\n"); + goto error; + } + memset(dev->tx, 0, PAGE_SIZE); + dev->ring_ref = gnttab_grant_access(dev->bedomid, virt_to_mfn(dev->tx), 0); + TPMFRONT_DEBUG("grant ref is %lu\n", (unsigned long) dev->ring_ref); + + /*Create event channel */ + if(evtchn_alloc_unbound(dev->bedomid, tpmfront_handler, dev, &dev->evtchn)) { + TPMFRONT_ERR("Unable to allocate event channel\n"); + goto error_postmap; + } + unmask_evtchn(dev->evtchn); + TPMFRONT_DEBUG("event channel is %lu\n", (unsigned long) dev->evtchn); + + /* Write the entries to xenstore */ + if(publish_xenbus(dev)) { + goto error_postevtchn; + } + + /* Change state to connected */ + dev->state = XenbusStateConnected; + + /* Tell the backend that we are ready */ + if((err = xenbus_printf(XBT_NIL, dev->nodename, "state", "%u", dev->state))) { + TPMFRONT_ERR("Unable to write to xenstore %s/state, value=%u", dev->nodename, XenbusStateConnected); + free(err); + goto error; + } + + return 0; +error_postevtchn: + mask_evtchn(dev->evtchn); + unbind_evtchn(dev->evtchn); +error_postmap: + gnttab_end_access(dev->ring_ref); + free_page(dev->tx); +error: + return -1; +} + +struct tpmfront_dev* init_tpmfront(const char* _nodename) +{ + struct tpmfront_dev* dev; + const char* nodename; + char path[512]; + char* value, *err; + unsigned long long ival; + int i; + + printk("============= Init TPM Front ================\n"); + + dev = malloc(sizeof(struct tpmfront_dev)); + memset(dev, 0, sizeof(struct tpmfront_dev)); + +#ifdef HAVE_LIBC + dev->fd = -1; +#endif + + nodename = _nodename ? _nodename : "device/vtpm/0"; + dev->nodename = strdup(nodename); + + init_waitqueue_head(&dev->waitq); + + /* Get backend domid */ + snprintf(path, 512, "%s/backend-id", dev->nodename); + if((err = xenbus_read(XBT_NIL, path, &value))) { + TPMFRONT_ERR("Unable to read %s during tpmfront initialization! error = %s\n", path, err); + free(err); + goto error; + } + if(sscanf(value, "%llu", &ival) != 1) { + TPMFRONT_ERR("%s has non-integer value (%s)\n", path, value); + free(value); + goto error; + } + free(value); + dev->bedomid = ival; + + /* Get backend xenstore path */ + snprintf(path, 512, "%s/backend", dev->nodename); + if((err = xenbus_read(XBT_NIL, path, &dev->bepath))) { + TPMFRONT_ERR("Unable to read %s during tpmfront initialization! error = %s\n", path, err); + free(err); + goto error; + } + + /* Create and publish grant reference and event channel */ + if (tpmfront_connect(dev)) { + goto error; + } + + /* Wait for backend to connect */ + if( wait_for_backend_state_changed(dev, XenbusStateConnected)) { + goto error; + } + + /* Allocate pages that will contain the messages */ + dev->pages = malloc(sizeof(void*) * TPMIF_TX_RING_SIZE); + if(dev->pages == NULL) { + goto error; + } + memset(dev->pages, 0, sizeof(void*) * TPMIF_TX_RING_SIZE); + for(i = 0; i < TPMIF_TX_RING_SIZE; ++i) { + dev->pages[i] = (void*)alloc_page(); + if(dev->pages[i] == NULL) { + goto error; + } + } + + TPMFRONT_LOG("Initialization Completed successfully\n"); + + return dev; + +error: + shutdown_tpmfront(dev); + return NULL; +} +void shutdown_tpmfront(struct tpmfront_dev* dev) +{ + char* err; + char path[512]; + int i; + tpmif_tx_request_t* tx; + if(dev == NULL) { + return; + } + TPMFRONT_LOG("Shutting down tpmfront\n"); + /* disconnect */ + if(dev->state == XenbusStateConnected) { + dev->state = XenbusStateClosing; + //FIXME: Transaction for this? + /* Tell backend we are closing */ + if((err = xenbus_printf(XBT_NIL, dev->nodename, "state", "%u", (unsigned int) dev->state))) { + free(err); + } + + /* Clean up xenstore entries */ + snprintf(path, 512, "%s/event-channel", dev->nodename); + if((err = xenbus_rm(XBT_NIL, path))) { + free(err); + } + snprintf(path, 512, "%s/ring-ref", dev->nodename); + if((err = xenbus_rm(XBT_NIL, path))) { + free(err); + } + + /* Tell backend we are closed */ + dev->state = XenbusStateClosed; + if((err = xenbus_printf(XBT_NIL, dev->nodename, "state", "%u", (unsigned int) dev->state))) { + TPMFRONT_ERR("Unable to write to %s, error was %s", dev->nodename, err); + free(err); + } + + /* Wait for the backend to close and unmap shared pages, ignore any errors */ + wait_for_backend_state_changed(dev, XenbusStateClosed); + + /* Cleanup any shared pages */ + if(dev->pages) { + for(i = 0; i < TPMIF_TX_RING_SIZE; ++i) { + if(dev->pages[i]) { + tx = &dev->tx->ring[i].req; + if(tx->ref != 0) { + gnttab_end_access(tx->ref); + } + free_page(dev->pages[i]); + } + } + free(dev->pages); + } + + /* Close event channel and unmap shared page */ + mask_evtchn(dev->evtchn); + unbind_evtchn(dev->evtchn); + gnttab_end_access(dev->ring_ref); + + free_page(dev->tx); + + } + + /* Cleanup memory usage */ + if(dev->respbuf) { + free(dev->respbuf); + } + if(dev->bepath) { + free(dev->bepath); + } + if(dev->nodename) { + free(dev->nodename); + } + free(dev); +} + +int tpmfront_send(struct tpmfront_dev* dev, const uint8_t* msg, size_t length) +{ + int i; + tpmif_tx_request_t* tx = NULL; + /* Error Checking */ + if(dev == NULL || dev->state != XenbusStateConnected) { + TPMFRONT_ERR("Tried to send message through disconnected frontend\n"); + return -1; + } + +#ifdef TPMFRONT_PRINT_DEBUG + TPMFRONT_DEBUG("Sending Msg to backend size=%u", (unsigned int) length); + for(i = 0; i < length; ++i) { + if(!(i % 30)) { + TPMFRONT_DEBUG_MORE("\n"); + } + TPMFRONT_DEBUG_MORE("%02X ", msg[i]); + } + TPMFRONT_DEBUG_MORE("\n"); +#endif + + /* Copy to shared pages now */ + for(i = 0; length > 0 && i < TPMIF_TX_RING_SIZE; ++i) { + /* Share the page */ + tx = &dev->tx->ring[i].req; + tx->unused = 0; + tx->addr = virt_to_mach(dev->pages[i]); + tx->ref = gnttab_grant_access(dev->bedomid, virt_to_mfn(dev->pages[i]), 0); + /* Copy the bits to the page */ + tx->size = length > PAGE_SIZE ? PAGE_SIZE : length; + memcpy(dev->pages[i], &msg[i * PAGE_SIZE], tx->size); + + /* Update counters */ + length -= tx->size; + } + dev->waiting = 1; + dev->resplen = 0; +#ifdef HAVE_LIBC + if(dev->fd >= 0) { + files[dev->fd].read = 0; + files[dev->fd].tpmfront.respgot = 0; + files[dev->fd].tpmfront.offset = 0; + } +#endif + notify_remote_via_evtchn(dev->evtchn); + return 0; +} +int tpmfront_recv(struct tpmfront_dev* dev, uint8_t** msg, size_t *length) +{ + tpmif_tx_request_t* tx; + int i; + if(dev == NULL || dev->state != XenbusStateConnected) { + TPMFRONT_ERR("Tried to receive message from disconnected frontend\n"); + return -1; + } + /*Wait for the response */ + wait_event(dev->waitq, (!dev->waiting)); + + /* Initialize */ + *msg = NULL; + *length = 0; + + /* special case, just quit */ + tx = &dev->tx->ring[0].req; + if(tx->size == 0 ) { + goto quit; + } + /* Get the total size */ + tx = &dev->tx->ring[0].req; + for(i = 0; i < TPMIF_TX_RING_SIZE && tx->size > 0; ++i) { + tx = &dev->tx->ring[i].req; + *length += tx->size; + } + /* Alloc the buffer */ + if(dev->respbuf) { + free(dev->respbuf); + } + *msg = dev->respbuf = malloc(*length); + dev->resplen = *length; + /* Copy the bits */ + tx = &dev->tx->ring[0].req; + for(i = 0; i < TPMIF_TX_RING_SIZE && tx->size > 0; ++i) { + tx = &dev->tx->ring[i].req; + memcpy(&(*msg)[i * PAGE_SIZE], dev->pages[i], tx->size); + gnttab_end_access(tx->ref); + tx->ref = 0; + } +#ifdef TPMFRONT_PRINT_DEBUG + TPMFRONT_DEBUG("Received response from backend size=%u", (unsigned int) *length); + for(i = 0; i < *length; ++i) { + if(!(i % 30)) { + TPMFRONT_DEBUG_MORE("\n"); + } + TPMFRONT_DEBUG_MORE("%02X ", (*msg)[i]); + } + TPMFRONT_DEBUG_MORE("\n"); +#endif +#ifdef HAVE_LIBC + if(dev->fd >= 0) { + files[dev->fd].tpmfront.respgot = 1; + } +#endif +quit: + return 0; +} + +int tpmfront_cmd(struct tpmfront_dev* dev, uint8_t* req, size_t reqlen, uint8_t** resp, size_t* resplen) +{ + int rc; + if((rc = tpmfront_send(dev, req, reqlen))) { + return rc; + } + if((rc = tpmfront_recv(dev, resp, resplen))) { + return rc; + } + + return 0; +} + +#ifdef HAVE_LIBC +#include +int tpmfront_open(struct tpmfront_dev* dev) +{ + /* Silently prevent multiple opens */ + if(dev->fd != -1) { + return dev->fd; + } + + dev->fd = alloc_fd(FTYPE_TPMFRONT); + printk("tpmfront_open(%s) -> %d\n", dev->nodename, dev->fd); + files[dev->fd].tpmfront.dev = dev; + files[dev->fd].tpmfront.offset = 0; + files[dev->fd].tpmfront.respgot = 0; + return dev->fd; +} + +int tpmfront_posix_write(int fd, const uint8_t* buf, size_t count) +{ + int rc; + struct tpmfront_dev* dev; + dev = files[fd].tpmfront.dev; + + if(count == 0) { + return 0; + } + + /* Return an error if we are already processing a command */ + if(dev->waiting) { + errno = EINPROGRESS; + return -1; + } + /* Send the command now */ + if((rc = tpmfront_send(dev, buf, count)) != 0) { + errno = EIO; + return -1; + } + return count; +} + +int tpmfront_posix_read(int fd, uint8_t* buf, size_t count) +{ + int rc; + uint8_t* dummybuf; + size_t dummysz; + struct tpmfront_dev* dev; + + dev = files[fd].tpmfront.dev; + + if(count == 0) { + return 0; + } + + /* get the response if we haven't already */ + if(files[dev->fd].tpmfront.respgot == 0) { + if ((rc = tpmfront_recv(dev, &dummybuf, &dummysz)) != 0) { + errno = EIO; + return -1; + } + } + + /* handle EOF case */ + if(files[dev->fd].tpmfront.offset >= dev->resplen) { + return 0; + } + + /* Compute the number of bytes and do the copy operation */ + if((rc = min(count, dev->resplen - files[dev->fd].tpmfront.offset)) != 0) { + memcpy(buf, dev->respbuf + files[dev->fd].tpmfront.offset, rc); + files[dev->fd].tpmfront.offset += rc; + } + + return rc; +} + +int tpmfront_posix_fstat(int fd, struct stat* buf) +{ + uint8_t* dummybuf; + size_t dummysz; + int rc; + struct tpmfront_dev* dev = files[fd].tpmfront.dev; + + /* If we have a response waiting, then read it now from the backend + * so we can get its length*/ + if(dev->waiting || (files[dev->fd].read == 1 && !files[dev->fd].tpmfront.respgot)) { + if ((rc = tpmfront_recv(dev, &dummybuf, &dummysz)) != 0) { + errno = EIO; + return -1; + } + } + + buf->st_mode = O_RDWR; + buf->st_uid = 0; + buf->st_gid = 0; + buf->st_size = dev->resplen; + buf->st_atime = buf->st_mtime = buf->st_ctime = time(NULL); + + return 0; +} + + +#endif -- 1.7.4.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 18:02:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 18:02:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCEH-0002qq-VW; Fri, 05 Oct 2012 18:02:29 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCEF-0002pX-UT for xen-devel@lists.xen.org; Fri, 05 Oct 2012 18:02:28 +0000 Received: from [85.158.143.35:5562] by server-1.bemta-4.messagelabs.com id 1C/9C-05684-3B02F605; Fri, 05 Oct 2012 18:02:27 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-8.tower-21.messagelabs.com!1349460144!14082984!1 X-Originating-IP: [128.244.251.37] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10800 invoked from network); 5 Oct 2012 18:02:25 -0000 Received: from piper.jhuapl.edu (HELO jhuapl.edu) (128.244.251.37) by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 18:02:25 -0000 Received: from ([128.244.207.97]) by piper.jhuapl.edu with ESMTP with TLS id 5Y8HCH1.146215714; Fri, 05 Oct 2012 14:02:01 -0400 From: Matthew Fioravante To: xen-devel@lists.xen.org, ian.campbell@citrix.com Date: Fri, 5 Oct 2012 14:02:09 -0400 Message-Id: <1349460132-13853-1-git-send-email-matthew.fioravante@jhuapl.edu> X-Mailer: git-send-email 1.7.4.4 Cc: Matthew Fioravante Subject: [Xen-devel] [PATCH vtpm v2 09/12] add iomem support to libxl X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch adds a new option for xen config files for directly mapping hardware io memory into a vm. Signed-off-by: Matthew Fioravante Reviewed-by: George Dunlap diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5 index 013270d..428da21 100644 --- a/docs/man/xl.cfg.pod.5 +++ b/docs/man/xl.cfg.pod.5 @@ -496,6 +496,17 @@ is given in hexadecimal and may either a span e.g. C<2f8-2ff> It is recommended to use this option only for trusted VMs under administrator control. +=item B + +Allow guest to access specific hardware I/O memory pages. B +is a physical page number. B is the number +of pages beginning with B to allow access. Both values +must be given in hexadecimal. + +It is recommended to use this option only for trusted VMs under +administrator control. + + =item B Allow a guest to access specific physical IRQs. diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index ef17f05..96f9018 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -942,7 +942,7 @@ static void domcreate_launch_dm(libxl__egc *egc, libxl__multidev *multidev, ret = xc_domain_ioport_permission(CTX->xch, domid, io->first, io->number, 1); - if ( ret<0 ){ + if ( ret < 0 ){ LOGE(ERROR, "failed give dom%d access to ioports %"PRIx32"-%"PRIx32, domid, io->first, io->first + io->number - 1); @@ -956,13 +956,31 @@ static void domcreate_launch_dm(libxl__egc *egc, libxl__multidev *multidev, LOG(DEBUG, "dom%d irq %"PRIx32, domid, irq); ret = xc_domain_irq_permission(CTX->xch, domid, irq, 1); - if ( ret<0 ){ + if ( ret < 0 ){ LOGE(ERROR, "failed give dom%d access to irq %"PRId32, domid, irq); ret = ERROR_FAIL; } } + for (i = 0; i < d_config->b_info.num_iomem; i++) { + libxl_iomem_range *io = &d_config->b_info.iomem[i]; + + LOG(DEBUG, "dom%d iomem %"PRIx64"-%"PRIx64, + domid, io->start, io->start + io->number - 1); + + ret = xc_domain_iomem_permission(CTX->xch, domid, + io->start, io->number, 1); + if ( ret < 0 ) { + LOGE(ERROR, + "failed give dom%d access to iomem range %"PRIx64"-%"PRIx64, + domid, io->start, io->start + io->number - 1); + ret = ERROR_FAIL; + } + } + + + for (i = 0; i < d_config->num_nics; i++) { /* We have to init the nic here, because we still haven't * called libxl_device_nic_add at this point, but qemu needs diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl index 6d5c578..cf83c60 100644 --- a/tools/libxl/libxl_types.idl +++ b/tools/libxl/libxl_types.idl @@ -140,6 +140,11 @@ libxl_ioport_range = Struct("ioport_range", [ ("number", uint32), ]) +libxl_iomem_range = Struct("iomem_range", [ + ("start", uint64), + ("number", uint64), + ]) + libxl_vga_interface_info = Struct("vga_interface_info", [ ("kind", libxl_vga_interface_type), ]) @@ -284,6 +289,7 @@ libxl_domain_build_info = Struct("domain_build_info",[ ("ioports", Array(libxl_ioport_range, "num_ioports")), ("irqs", Array(uint32, "num_irqs")), + ("iomem", Array(libxl_iomem_range, "num_iomem")), ("u", KeyedUnion(None, libxl_domain_type, "type", [("hvm", Struct(None, [("firmware", string), diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c index 1627cac..f13d983 100644 --- a/tools/libxl/xl_cmdimpl.c +++ b/tools/libxl/xl_cmdimpl.c @@ -574,8 +574,8 @@ static void parse_config_data(const char *config_source, long l; XLU_Config *config; XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids; - XLU_ConfigList *ioports, *irqs; - int num_ioports, num_irqs; + XLU_ConfigList *ioports, *irqs, *iomem; + int num_ioports, num_irqs, num_iomem; int pci_power_mgmt = 0; int pci_msitranslate = 0; int pci_permissive = 0; @@ -1005,6 +1005,33 @@ static void parse_config_data(const char *config_source, } } + if (!xlu_cfg_get_list(config, "iomem", &iomem, &num_iomem, 0)) { + b_info->num_iomem = num_iomem; + b_info->iomem = calloc(num_iomem, sizeof(*b_info->iomem)); + if (b_info->iomem == NULL) { + fprintf(stderr, "unable to allocate memory for iomem\n"); + exit(-1); + } + for (i = 0; i < num_iomem; i++) { + buf = xlu_cfg_get_listitem (iomem, i); + if (!buf) { + fprintf(stderr, + "xl: Unable to get element %d in iomem list\n", i); + exit(1); + } + if(sscanf(buf, "%" SCNx64",%" SCNx64, + &b_info->iomem[i].start, + &b_info->iomem[i].number) + != 2) { + fprintf(stderr, + "xl: Invalid argument parsing iomem: %s\n", buf); + exit(1); + } + } + } + + + if (!xlu_cfg_get_list (config, "disk", &vbds, 0, 0)) { d_config->num_disks = 0; d_config->disks = NULL; -- 1.7.4.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 18:02:38 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 18:02:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCEH-0002qq-VW; Fri, 05 Oct 2012 18:02:29 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCEF-0002pX-UT for xen-devel@lists.xen.org; Fri, 05 Oct 2012 18:02:28 +0000 Received: from [85.158.143.35:5562] by server-1.bemta-4.messagelabs.com id 1C/9C-05684-3B02F605; Fri, 05 Oct 2012 18:02:27 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-8.tower-21.messagelabs.com!1349460144!14082984!1 X-Originating-IP: [128.244.251.37] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10800 invoked from network); 5 Oct 2012 18:02:25 -0000 Received: from piper.jhuapl.edu (HELO jhuapl.edu) (128.244.251.37) by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 18:02:25 -0000 Received: from ([128.244.207.97]) by piper.jhuapl.edu with ESMTP with TLS id 5Y8HCH1.146215714; Fri, 05 Oct 2012 14:02:01 -0400 From: Matthew Fioravante To: xen-devel@lists.xen.org, ian.campbell@citrix.com Date: Fri, 5 Oct 2012 14:02:09 -0400 Message-Id: <1349460132-13853-1-git-send-email-matthew.fioravante@jhuapl.edu> X-Mailer: git-send-email 1.7.4.4 Cc: Matthew Fioravante Subject: [Xen-devel] [PATCH vtpm v2 09/12] add iomem support to libxl X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch adds a new option for xen config files for directly mapping hardware io memory into a vm. Signed-off-by: Matthew Fioravante Reviewed-by: George Dunlap diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5 index 013270d..428da21 100644 --- a/docs/man/xl.cfg.pod.5 +++ b/docs/man/xl.cfg.pod.5 @@ -496,6 +496,17 @@ is given in hexadecimal and may either a span e.g. C<2f8-2ff> It is recommended to use this option only for trusted VMs under administrator control. +=item B + +Allow guest to access specific hardware I/O memory pages. B +is a physical page number. B is the number +of pages beginning with B to allow access. Both values +must be given in hexadecimal. + +It is recommended to use this option only for trusted VMs under +administrator control. + + =item B Allow a guest to access specific physical IRQs. diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index ef17f05..96f9018 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -942,7 +942,7 @@ static void domcreate_launch_dm(libxl__egc *egc, libxl__multidev *multidev, ret = xc_domain_ioport_permission(CTX->xch, domid, io->first, io->number, 1); - if ( ret<0 ){ + if ( ret < 0 ){ LOGE(ERROR, "failed give dom%d access to ioports %"PRIx32"-%"PRIx32, domid, io->first, io->first + io->number - 1); @@ -956,13 +956,31 @@ static void domcreate_launch_dm(libxl__egc *egc, libxl__multidev *multidev, LOG(DEBUG, "dom%d irq %"PRIx32, domid, irq); ret = xc_domain_irq_permission(CTX->xch, domid, irq, 1); - if ( ret<0 ){ + if ( ret < 0 ){ LOGE(ERROR, "failed give dom%d access to irq %"PRId32, domid, irq); ret = ERROR_FAIL; } } + for (i = 0; i < d_config->b_info.num_iomem; i++) { + libxl_iomem_range *io = &d_config->b_info.iomem[i]; + + LOG(DEBUG, "dom%d iomem %"PRIx64"-%"PRIx64, + domid, io->start, io->start + io->number - 1); + + ret = xc_domain_iomem_permission(CTX->xch, domid, + io->start, io->number, 1); + if ( ret < 0 ) { + LOGE(ERROR, + "failed give dom%d access to iomem range %"PRIx64"-%"PRIx64, + domid, io->start, io->start + io->number - 1); + ret = ERROR_FAIL; + } + } + + + for (i = 0; i < d_config->num_nics; i++) { /* We have to init the nic here, because we still haven't * called libxl_device_nic_add at this point, but qemu needs diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl index 6d5c578..cf83c60 100644 --- a/tools/libxl/libxl_types.idl +++ b/tools/libxl/libxl_types.idl @@ -140,6 +140,11 @@ libxl_ioport_range = Struct("ioport_range", [ ("number", uint32), ]) +libxl_iomem_range = Struct("iomem_range", [ + ("start", uint64), + ("number", uint64), + ]) + libxl_vga_interface_info = Struct("vga_interface_info", [ ("kind", libxl_vga_interface_type), ]) @@ -284,6 +289,7 @@ libxl_domain_build_info = Struct("domain_build_info",[ ("ioports", Array(libxl_ioport_range, "num_ioports")), ("irqs", Array(uint32, "num_irqs")), + ("iomem", Array(libxl_iomem_range, "num_iomem")), ("u", KeyedUnion(None, libxl_domain_type, "type", [("hvm", Struct(None, [("firmware", string), diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c index 1627cac..f13d983 100644 --- a/tools/libxl/xl_cmdimpl.c +++ b/tools/libxl/xl_cmdimpl.c @@ -574,8 +574,8 @@ static void parse_config_data(const char *config_source, long l; XLU_Config *config; XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids; - XLU_ConfigList *ioports, *irqs; - int num_ioports, num_irqs; + XLU_ConfigList *ioports, *irqs, *iomem; + int num_ioports, num_irqs, num_iomem; int pci_power_mgmt = 0; int pci_msitranslate = 0; int pci_permissive = 0; @@ -1005,6 +1005,33 @@ static void parse_config_data(const char *config_source, } } + if (!xlu_cfg_get_list(config, "iomem", &iomem, &num_iomem, 0)) { + b_info->num_iomem = num_iomem; + b_info->iomem = calloc(num_iomem, sizeof(*b_info->iomem)); + if (b_info->iomem == NULL) { + fprintf(stderr, "unable to allocate memory for iomem\n"); + exit(-1); + } + for (i = 0; i < num_iomem; i++) { + buf = xlu_cfg_get_listitem (iomem, i); + if (!buf) { + fprintf(stderr, + "xl: Unable to get element %d in iomem list\n", i); + exit(1); + } + if(sscanf(buf, "%" SCNx64",%" SCNx64, + &b_info->iomem[i].start, + &b_info->iomem[i].number) + != 2) { + fprintf(stderr, + "xl: Invalid argument parsing iomem: %s\n", buf); + exit(1); + } + } + } + + + if (!xlu_cfg_get_list (config, "disk", &vbds, 0, 0)) { d_config->num_disks = 0; d_config->disks = NULL; -- 1.7.4.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 18:02:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 18:02:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCEN-0002tJ-Db; Fri, 05 Oct 2012 18:02:35 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCEM-0002sW-0i for xen-devel@lists.xen.org; Fri, 05 Oct 2012 18:02:34 +0000 Received: from [85.158.139.211:55450] by server-16.bemta-5.messagelabs.com id 9B/63-21637-9B02F605; Fri, 05 Oct 2012 18:02:33 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-8.tower-206.messagelabs.com!1349460150!21233332!1 X-Originating-IP: [128.244.251.37] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17527 invoked from network); 5 Oct 2012 18:02:32 -0000 Received: from piper.jhuapl.edu (HELO jhuapl.edu) (128.244.251.37) by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 18:02:32 -0000 Received: from ([128.244.207.97]) by piper.jhuapl.edu with ESMTP with TLS id 5Y8HCH1.146215724; Fri, 05 Oct 2012 14:02:01 -0400 From: Matthew Fioravante To: xen-devel@lists.xen.org, ian.campbell@citrix.com Date: Fri, 5 Oct 2012 14:02:10 -0400 Message-Id: <1349460132-13853-2-git-send-email-matthew.fioravante@jhuapl.edu> X-Mailer: git-send-email 1.7.4.4 In-Reply-To: <1349460132-13853-1-git-send-email-matthew.fioravante@jhuapl.edu> References: <1349460132-13853-1-git-send-email-matthew.fioravante@jhuapl.edu> Cc: Matthew Fioravante Subject: [Xen-devel] [PATCH vtpm v2 10/12] make devid a type so it is initialized properly X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Previously device ids in libxl were treated as integers meaning they were being initialized to 0, which is a valid device id. This patch makes devid its own type in libxl and initializes it to -1, an invalid value. This fixes a bug where if you try to do a xl DEV-attach multiple time it will continuously try to reattach device 0 instead of generated a new device id. Signed-off-by: Matthew Fioravante Reviewed-by: George Dunlap Acked-by: Ian Campbell diff --git a/tools/libxl/gentest.py b/tools/libxl/gentest.py index 2915f71..84b4fd7 100644 --- a/tools/libxl/gentest.py +++ b/tools/libxl/gentest.py @@ -60,7 +60,7 @@ def gen_rand_init(ty, v, indent = " ", parent = None): passby=idl.PASS_BY_REFERENCE)) elif ty.typename in ["libxl_uuid", "libxl_mac", "libxl_hwcap"]: s += "rand_bytes((uint8_t *)%s, sizeof(*%s));\n" % (v,v) - elif ty.typename in ["libxl_domid"] or isinstance(ty, idl.Number): + elif ty.typename in ["libxl_domid", "libxl_devid"] or isinstance(ty, idl.Number): s += "%s = rand() %% (sizeof(%s)*8);\n" % \ (ty.pass_arg(v, parent is None), ty.pass_arg(v, parent is None)) diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h index 599c7f1..7a7c419 100644 --- a/tools/libxl/libxl.h +++ b/tools/libxl/libxl.h @@ -307,6 +307,7 @@ void libxl_cpuid_dispose(libxl_cpuid_policy_list *cpuid_list); #define LIBXL_PCI_FUNC_ALL (~0U) typedef uint32_t libxl_domid; +typedef int libxl_devid; /* * Formatting Enumerations. diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl index cf83c60..de111a6 100644 --- a/tools/libxl/libxl_types.idl +++ b/tools/libxl/libxl_types.idl @@ -8,6 +8,7 @@ namespace("libxl_") libxl_defbool = Builtin("defbool", passby=PASS_BY_REFERENCE) libxl_domid = Builtin("domid", json_fn = "yajl_gen_integer", autogenerate_json = False) +libxl_devid = Builtin("devid", json_fn = "yajl_gen_integer", autogenerate_json = False, signed = True, init_val="-1") libxl_uuid = Builtin("uuid", passby=PASS_BY_REFERENCE) libxl_mac = Builtin("mac", passby=PASS_BY_REFERENCE) libxl_bitmap = Builtin("bitmap", dispose_fn="libxl_bitmap_dispose", passby=PASS_BY_REFERENCE) @@ -343,7 +344,7 @@ libxl_domain_build_info = Struct("domain_build_info",[ libxl_device_vfb = Struct("device_vfb", [ ("backend_domid", libxl_domid), - ("devid", integer), + ("devid", libxl_devid), ("vnc", libxl_vnc_info), ("sdl", libxl_sdl_info), # set keyboard layout, default is en-us keyboard @@ -352,7 +353,7 @@ libxl_device_vfb = Struct("device_vfb", [ libxl_device_vkb = Struct("device_vkb", [ ("backend_domid", libxl_domid), - ("devid", integer), + ("devid", libxl_devid), ]) libxl_device_disk = Struct("device_disk", [ @@ -369,7 +370,7 @@ libxl_device_disk = Struct("device_disk", [ libxl_device_nic = Struct("device_nic", [ ("backend_domid", libxl_domid), - ("devid", integer), + ("devid", libxl_devid), ("mtu", integer), ("model", string), ("mac", libxl_mac), @@ -399,7 +400,7 @@ libxl_diskinfo = Struct("diskinfo", [ ("backend_id", uint32), ("frontend", string), ("frontend_id", uint32), - ("devid", integer), + ("devid", libxl_devid), ("state", integer), ("evtch", integer), ("rref", integer), @@ -410,7 +411,7 @@ libxl_nicinfo = Struct("nicinfo", [ ("backend_id", uint32), ("frontend", string), ("frontend_id", uint32), - ("devid", integer), + ("devid", libxl_devid), ("state", integer), ("evtch", integer), ("rref_tx", integer), diff --git a/tools/ocaml/libs/xl/genwrap.py b/tools/ocaml/libs/xl/genwrap.py index 42f374e..97d088d 100644 --- a/tools/ocaml/libs/xl/genwrap.py +++ b/tools/ocaml/libs/xl/genwrap.py @@ -10,6 +10,7 @@ builtins = { "int": ("int", "%(c)s = Int_val(%(o)s)", "Val_int(%(c)s)" ), "char *": ("string", "%(c)s = dup_String_val(gc, %(o)s)", "caml_copy_string(%(c)s)"), "libxl_domid": ("domid", "%(c)s = Int_val(%(o)s)", "Val_int(%(c)s)" ), + "libxl_devid": ("devid", "%(c)s = Int_val(%(o)s)", "Val_int(%(c)s)" ), "libxl_defbool": ("bool option", "%(c)s = Defbool_val(%(o)s)", "Val_defbool(%(c)s)" ), "libxl_uuid": ("int array", "Uuid_val(gc, lg, &%(c)s, %(o)s)", "Val_uuid(&%(c)s)"), "libxl_key_value_list": ("(string * string) list", None, None), @@ -41,8 +42,8 @@ def stub_fn_name(ty, name): return "stub_xl_%s_%s" % (ty.rawname,name) def ocaml_type_of(ty): - if ty.rawname == "domid": - return "domid" + if ty.rawname in ["domid","devid"]: + return ty.rawname elif isinstance(ty,idl.UInt): if ty.width in [8, 16]: # handle as ints diff --git a/tools/ocaml/libs/xl/xenlight.ml.in b/tools/ocaml/libs/xl/xenlight.ml.in index c47623c..dcc1a38 100644 --- a/tools/ocaml/libs/xl/xenlight.ml.in +++ b/tools/ocaml/libs/xl/xenlight.ml.in @@ -16,6 +16,7 @@ exception Error of string type domid = int +type devid = int (* @@LIBXL_TYPES@@ *) diff --git a/tools/ocaml/libs/xl/xenlight.mli.in b/tools/ocaml/libs/xl/xenlight.mli.in index 4717bac..3fd0165 100644 --- a/tools/ocaml/libs/xl/xenlight.mli.in +++ b/tools/ocaml/libs/xl/xenlight.mli.in @@ -16,6 +16,7 @@ exception Error of string type domid = int +type devid = int (* @@LIBXL_TYPES@@ *) diff --git a/tools/python/xen/lowlevel/xl/xl.c b/tools/python/xen/lowlevel/xl/xl.c index 0551c76..32f982a 100644 --- a/tools/python/xen/lowlevel/xl/xl.c +++ b/tools/python/xen/lowlevel/xl/xl.c @@ -281,6 +281,11 @@ int attrib__libxl_domid_set(PyObject *v, libxl_domid *domid) { return 0; } +int attrib__libxl_devid_set(PyObject *v, libxl_devid *devid) { + *devid = PyInt_AsLong(v); + return 0; +} + int attrib__struct_in_addr_set(PyObject *v, struct in_addr *pptr) { PyErr_SetString(PyExc_NotImplementedError, "Setting in_addr"); @@ -342,6 +347,10 @@ PyObject *attrib__libxl_domid_get(libxl_domid *domid) { return PyInt_FromLong(*domid); } +PyObject *attrib__libxl_devid_get(libxl_devid *devid) { + return PyInt_FromLong(*devid); +} + PyObject *attrib__struct_in_addr_get(struct in_addr *pptr) { PyErr_SetString(PyExc_NotImplementedError, "Getting in_addr"); -- 1.7.4.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 18:02:40 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 18:02:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCEN-0002tJ-Db; Fri, 05 Oct 2012 18:02:35 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCEM-0002sW-0i for xen-devel@lists.xen.org; Fri, 05 Oct 2012 18:02:34 +0000 Received: from [85.158.139.211:55450] by server-16.bemta-5.messagelabs.com id 9B/63-21637-9B02F605; Fri, 05 Oct 2012 18:02:33 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-8.tower-206.messagelabs.com!1349460150!21233332!1 X-Originating-IP: [128.244.251.37] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17527 invoked from network); 5 Oct 2012 18:02:32 -0000 Received: from piper.jhuapl.edu (HELO jhuapl.edu) (128.244.251.37) by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 18:02:32 -0000 Received: from ([128.244.207.97]) by piper.jhuapl.edu with ESMTP with TLS id 5Y8HCH1.146215724; Fri, 05 Oct 2012 14:02:01 -0400 From: Matthew Fioravante To: xen-devel@lists.xen.org, ian.campbell@citrix.com Date: Fri, 5 Oct 2012 14:02:10 -0400 Message-Id: <1349460132-13853-2-git-send-email-matthew.fioravante@jhuapl.edu> X-Mailer: git-send-email 1.7.4.4 In-Reply-To: <1349460132-13853-1-git-send-email-matthew.fioravante@jhuapl.edu> References: <1349460132-13853-1-git-send-email-matthew.fioravante@jhuapl.edu> Cc: Matthew Fioravante Subject: [Xen-devel] [PATCH vtpm v2 10/12] make devid a type so it is initialized properly X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Previously device ids in libxl were treated as integers meaning they were being initialized to 0, which is a valid device id. This patch makes devid its own type in libxl and initializes it to -1, an invalid value. This fixes a bug where if you try to do a xl DEV-attach multiple time it will continuously try to reattach device 0 instead of generated a new device id. Signed-off-by: Matthew Fioravante Reviewed-by: George Dunlap Acked-by: Ian Campbell diff --git a/tools/libxl/gentest.py b/tools/libxl/gentest.py index 2915f71..84b4fd7 100644 --- a/tools/libxl/gentest.py +++ b/tools/libxl/gentest.py @@ -60,7 +60,7 @@ def gen_rand_init(ty, v, indent = " ", parent = None): passby=idl.PASS_BY_REFERENCE)) elif ty.typename in ["libxl_uuid", "libxl_mac", "libxl_hwcap"]: s += "rand_bytes((uint8_t *)%s, sizeof(*%s));\n" % (v,v) - elif ty.typename in ["libxl_domid"] or isinstance(ty, idl.Number): + elif ty.typename in ["libxl_domid", "libxl_devid"] or isinstance(ty, idl.Number): s += "%s = rand() %% (sizeof(%s)*8);\n" % \ (ty.pass_arg(v, parent is None), ty.pass_arg(v, parent is None)) diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h index 599c7f1..7a7c419 100644 --- a/tools/libxl/libxl.h +++ b/tools/libxl/libxl.h @@ -307,6 +307,7 @@ void libxl_cpuid_dispose(libxl_cpuid_policy_list *cpuid_list); #define LIBXL_PCI_FUNC_ALL (~0U) typedef uint32_t libxl_domid; +typedef int libxl_devid; /* * Formatting Enumerations. diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl index cf83c60..de111a6 100644 --- a/tools/libxl/libxl_types.idl +++ b/tools/libxl/libxl_types.idl @@ -8,6 +8,7 @@ namespace("libxl_") libxl_defbool = Builtin("defbool", passby=PASS_BY_REFERENCE) libxl_domid = Builtin("domid", json_fn = "yajl_gen_integer", autogenerate_json = False) +libxl_devid = Builtin("devid", json_fn = "yajl_gen_integer", autogenerate_json = False, signed = True, init_val="-1") libxl_uuid = Builtin("uuid", passby=PASS_BY_REFERENCE) libxl_mac = Builtin("mac", passby=PASS_BY_REFERENCE) libxl_bitmap = Builtin("bitmap", dispose_fn="libxl_bitmap_dispose", passby=PASS_BY_REFERENCE) @@ -343,7 +344,7 @@ libxl_domain_build_info = Struct("domain_build_info",[ libxl_device_vfb = Struct("device_vfb", [ ("backend_domid", libxl_domid), - ("devid", integer), + ("devid", libxl_devid), ("vnc", libxl_vnc_info), ("sdl", libxl_sdl_info), # set keyboard layout, default is en-us keyboard @@ -352,7 +353,7 @@ libxl_device_vfb = Struct("device_vfb", [ libxl_device_vkb = Struct("device_vkb", [ ("backend_domid", libxl_domid), - ("devid", integer), + ("devid", libxl_devid), ]) libxl_device_disk = Struct("device_disk", [ @@ -369,7 +370,7 @@ libxl_device_disk = Struct("device_disk", [ libxl_device_nic = Struct("device_nic", [ ("backend_domid", libxl_domid), - ("devid", integer), + ("devid", libxl_devid), ("mtu", integer), ("model", string), ("mac", libxl_mac), @@ -399,7 +400,7 @@ libxl_diskinfo = Struct("diskinfo", [ ("backend_id", uint32), ("frontend", string), ("frontend_id", uint32), - ("devid", integer), + ("devid", libxl_devid), ("state", integer), ("evtch", integer), ("rref", integer), @@ -410,7 +411,7 @@ libxl_nicinfo = Struct("nicinfo", [ ("backend_id", uint32), ("frontend", string), ("frontend_id", uint32), - ("devid", integer), + ("devid", libxl_devid), ("state", integer), ("evtch", integer), ("rref_tx", integer), diff --git a/tools/ocaml/libs/xl/genwrap.py b/tools/ocaml/libs/xl/genwrap.py index 42f374e..97d088d 100644 --- a/tools/ocaml/libs/xl/genwrap.py +++ b/tools/ocaml/libs/xl/genwrap.py @@ -10,6 +10,7 @@ builtins = { "int": ("int", "%(c)s = Int_val(%(o)s)", "Val_int(%(c)s)" ), "char *": ("string", "%(c)s = dup_String_val(gc, %(o)s)", "caml_copy_string(%(c)s)"), "libxl_domid": ("domid", "%(c)s = Int_val(%(o)s)", "Val_int(%(c)s)" ), + "libxl_devid": ("devid", "%(c)s = Int_val(%(o)s)", "Val_int(%(c)s)" ), "libxl_defbool": ("bool option", "%(c)s = Defbool_val(%(o)s)", "Val_defbool(%(c)s)" ), "libxl_uuid": ("int array", "Uuid_val(gc, lg, &%(c)s, %(o)s)", "Val_uuid(&%(c)s)"), "libxl_key_value_list": ("(string * string) list", None, None), @@ -41,8 +42,8 @@ def stub_fn_name(ty, name): return "stub_xl_%s_%s" % (ty.rawname,name) def ocaml_type_of(ty): - if ty.rawname == "domid": - return "domid" + if ty.rawname in ["domid","devid"]: + return ty.rawname elif isinstance(ty,idl.UInt): if ty.width in [8, 16]: # handle as ints diff --git a/tools/ocaml/libs/xl/xenlight.ml.in b/tools/ocaml/libs/xl/xenlight.ml.in index c47623c..dcc1a38 100644 --- a/tools/ocaml/libs/xl/xenlight.ml.in +++ b/tools/ocaml/libs/xl/xenlight.ml.in @@ -16,6 +16,7 @@ exception Error of string type domid = int +type devid = int (* @@LIBXL_TYPES@@ *) diff --git a/tools/ocaml/libs/xl/xenlight.mli.in b/tools/ocaml/libs/xl/xenlight.mli.in index 4717bac..3fd0165 100644 --- a/tools/ocaml/libs/xl/xenlight.mli.in +++ b/tools/ocaml/libs/xl/xenlight.mli.in @@ -16,6 +16,7 @@ exception Error of string type domid = int +type devid = int (* @@LIBXL_TYPES@@ *) diff --git a/tools/python/xen/lowlevel/xl/xl.c b/tools/python/xen/lowlevel/xl/xl.c index 0551c76..32f982a 100644 --- a/tools/python/xen/lowlevel/xl/xl.c +++ b/tools/python/xen/lowlevel/xl/xl.c @@ -281,6 +281,11 @@ int attrib__libxl_domid_set(PyObject *v, libxl_domid *domid) { return 0; } +int attrib__libxl_devid_set(PyObject *v, libxl_devid *devid) { + *devid = PyInt_AsLong(v); + return 0; +} + int attrib__struct_in_addr_set(PyObject *v, struct in_addr *pptr) { PyErr_SetString(PyExc_NotImplementedError, "Setting in_addr"); @@ -342,6 +347,10 @@ PyObject *attrib__libxl_domid_get(libxl_domid *domid) { return PyInt_FromLong(*domid); } +PyObject *attrib__libxl_devid_get(libxl_devid *devid) { + return PyInt_FromLong(*devid); +} + PyObject *attrib__struct_in_addr_get(struct in_addr *pptr) { PyErr_SetString(PyExc_NotImplementedError, "Getting in_addr"); -- 1.7.4.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 18:02:42 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 18:02:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCEQ-0002vI-GP; Fri, 05 Oct 2012 18:02:38 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCEO-0002sW-ES for xen-devel@lists.xen.org; Fri, 05 Oct 2012 18:02:36 +0000 Received: from [85.158.139.211:13076] by server-16.bemta-5.messagelabs.com id 45/73-21637-CB02F605; Fri, 05 Oct 2012 18:02:36 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-7.tower-206.messagelabs.com!1349460153!20795214!1 X-Originating-IP: [128.244.251.37] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19298 invoked from network); 5 Oct 2012 18:02:35 -0000 Received: from piper.jhuapl.edu (HELO jhuapl.edu) (128.244.251.37) by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 18:02:35 -0000 Received: from ([128.244.207.97]) by piper.jhuapl.edu with ESMTP with TLS id 5Y8HCH1.146215737; Fri, 05 Oct 2012 14:02:01 -0400 From: Matthew Fioravante To: xen-devel@lists.xen.org, ian.campbell@citrix.com Date: Fri, 5 Oct 2012 14:02:12 -0400 Message-Id: <1349460132-13853-4-git-send-email-matthew.fioravante@jhuapl.edu> X-Mailer: git-send-email 1.7.4.4 In-Reply-To: <1349460132-13853-1-git-send-email-matthew.fioravante@jhuapl.edu> References: <1349460132-13853-1-git-send-email-matthew.fioravante@jhuapl.edu> Cc: Matthew Fioravante Subject: [Xen-devel] [PATCH vtpm v2 12/12] Matthew Fioravante now maintains VTPM X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org See MAINTAINERS file Signed-off-by: Matthew Fioravante diff --git a/MAINTAINERS b/MAINTAINERS index 094fe9e..0bde721 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -242,6 +242,21 @@ S: Supported T: hg http://xenbits.xen.org/linux-2.6.18-xen.hg F: drivers/xen/usb*/ +VTPM +M: Matthew Fioravante +S: Supported +F: tools/vtpm/ +F: tools/vtpm_manager/ +F: extras/minios-os/tpmfront.c +F: extras/minios-os/tpmback.c +F: extras/minios-os/tpm-tis.c +F: extras/minios-os/include/tpmfront.h +F: extras/minios-os/include/tpmback.h +F: extras/minios-os/include/tpm-tis.h +F: stubdom/vtpm/ +F: stubdom/vtpmmgr/ +F: docs/misc/vtpm.txt + X86 ARCHITECTURE M: Keir Fraser M: Jan Beulich -- 1.7.4.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 18:02:42 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 18:02:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCEQ-0002vI-GP; Fri, 05 Oct 2012 18:02:38 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCEO-0002sW-ES for xen-devel@lists.xen.org; Fri, 05 Oct 2012 18:02:36 +0000 Received: from [85.158.139.211:13076] by server-16.bemta-5.messagelabs.com id 45/73-21637-CB02F605; Fri, 05 Oct 2012 18:02:36 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-7.tower-206.messagelabs.com!1349460153!20795214!1 X-Originating-IP: [128.244.251.37] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19298 invoked from network); 5 Oct 2012 18:02:35 -0000 Received: from piper.jhuapl.edu (HELO jhuapl.edu) (128.244.251.37) by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 18:02:35 -0000 Received: from ([128.244.207.97]) by piper.jhuapl.edu with ESMTP with TLS id 5Y8HCH1.146215737; Fri, 05 Oct 2012 14:02:01 -0400 From: Matthew Fioravante To: xen-devel@lists.xen.org, ian.campbell@citrix.com Date: Fri, 5 Oct 2012 14:02:12 -0400 Message-Id: <1349460132-13853-4-git-send-email-matthew.fioravante@jhuapl.edu> X-Mailer: git-send-email 1.7.4.4 In-Reply-To: <1349460132-13853-1-git-send-email-matthew.fioravante@jhuapl.edu> References: <1349460132-13853-1-git-send-email-matthew.fioravante@jhuapl.edu> Cc: Matthew Fioravante Subject: [Xen-devel] [PATCH vtpm v2 12/12] Matthew Fioravante now maintains VTPM X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org See MAINTAINERS file Signed-off-by: Matthew Fioravante diff --git a/MAINTAINERS b/MAINTAINERS index 094fe9e..0bde721 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -242,6 +242,21 @@ S: Supported T: hg http://xenbits.xen.org/linux-2.6.18-xen.hg F: drivers/xen/usb*/ +VTPM +M: Matthew Fioravante +S: Supported +F: tools/vtpm/ +F: tools/vtpm_manager/ +F: extras/minios-os/tpmfront.c +F: extras/minios-os/tpmback.c +F: extras/minios-os/tpm-tis.c +F: extras/minios-os/include/tpmfront.h +F: extras/minios-os/include/tpmback.h +F: extras/minios-os/include/tpm-tis.h +F: stubdom/vtpm/ +F: stubdom/vtpmmgr/ +F: docs/misc/vtpm.txt + X86 ARCHITECTURE M: Keir Fraser M: Jan Beulich -- 1.7.4.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 18:02:42 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 18:02:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCEO-0002u2-Qg; Fri, 05 Oct 2012 18:02:36 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCEN-0002t8-9v for xen-devel@lists.xen.org; Fri, 05 Oct 2012 18:02:35 +0000 Received: from [85.158.139.83:51189] by server-7.bemta-5.messagelabs.com id 78/7D-00431-AB02F605; Fri, 05 Oct 2012 18:02:34 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-3.tower-182.messagelabs.com!1349460150!33605348!1 X-Originating-IP: [128.244.251.37] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG, UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22154 invoked from network); 5 Oct 2012 18:02:32 -0000 Received: from piper.jhuapl.edu (HELO jhuapl.edu) (128.244.251.37) by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 18:02:32 -0000 Received: from ([128.244.207.97]) by piper.jhuapl.edu with ESMTP with TLS id 5Y8HCH1.146215729; Fri, 05 Oct 2012 14:02:01 -0400 From: Matthew Fioravante To: xen-devel@lists.xen.org, ian.campbell@citrix.com Date: Fri, 5 Oct 2012 14:02:11 -0400 Message-Id: <1349460132-13853-3-git-send-email-matthew.fioravante@jhuapl.edu> X-Mailer: git-send-email 1.7.4.4 In-Reply-To: <1349460132-13853-1-git-send-email-matthew.fioravante@jhuapl.edu> References: <1349460132-13853-1-git-send-email-matthew.fioravante@jhuapl.edu> Cc: Matthew Fioravante Subject: [Xen-devel] [PATCH vtpm v2 11/12] add vtpm support to libxl X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch adds vtpm support to libxl. It adds vtpm parsing to config files and 3 new xl commands: vtpm-attach vtpm-detach vtpm-list Signed-off-by: Matthew Fioravante diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5 index 428da21..9f6ee5a 100644 --- a/docs/man/xl.cfg.pod.5 +++ b/docs/man/xl.cfg.pod.5 @@ -298,6 +298,35 @@ Specifies the networking provision (both emulated network adapters, and Xen virtual interfaces) to provided to the guest. See F. +=item B + +Specifies the virtual trusted platform module to be +provided to the guest. Please see F +for more details. + +Each B is a comma-separated list of C +settings, from the following list: + +=over 4 + +=item C + +Specify the backend domain name of id. This value is required! +If this domain is a guest, the backend should be set to the +vtpm domain name. If this domain is a vtpm, the +backend should be set to the vtpm manager domain name. + +=item C + +Specify the uuid of this vtpm device. The uuid is used to uniquely +identify the vtpm device. You can create one using the uuidgen +program on unix systems. If left unspecified, a new uuid +will be randomly generated every time the domain boots. +If this is a vtpm domain, you should specify a value. The +value is optional if this is a guest domain. + +=back + =item B Specifies the paravirtual framebuffer devices which should be supplied diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1 index 25ce777..be9ad4c 100644 --- a/docs/man/xl.pod.1 +++ b/docs/man/xl.pod.1 @@ -1101,6 +1101,31 @@ List virtual network interfaces for a domain. =back +=head2 VTPM DEVICES + +=over 4 + +=item B I I + +Creates a new vtpm device in the domain specified by I. +I describes the device to attach, using the same format as the +B string in the domain config file. See L for +more information. + +=item B I I + +Removes the vtpm device from the domain specified by I. +I is the numeric device id given to the virtual trusted +platform module device. You will need to run B to determine that number. +Alternatively the I of the vtpm can be used to +select the virtual device to detach. + +=item B I + +List virtual trusted platform modules for a domain. + +=back + =head1 PCI PASS-THROUGH =over 4 diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c index 1606eb1..17094ca 100644 --- a/tools/libxl/libxl.c +++ b/tools/libxl/libxl.c @@ -1726,6 +1726,246 @@ out: } /******************************************************************************/ +int libxl__device_vtpm_setdefault(libxl__gc *gc, libxl_device_vtpm *vtpm) +{ + if(libxl_uuid_is_nil(&vtpm->uuid)) { + libxl_uuid_generate(&vtpm->uuid); + } + return 0; +} + +static int libxl__device_from_vtpm(libxl__gc *gc, uint32_t domid, + libxl_device_vtpm *vtpm, + libxl__device *device) +{ + device->backend_devid = vtpm->devid; + device->backend_domid = vtpm->backend_domid; + device->backend_kind = LIBXL__DEVICE_KIND_VTPM; + device->devid = vtpm->devid; + device->domid = domid; + device->kind = LIBXL__DEVICE_KIND_VTPM; + + return 0; +} + +void libxl__device_vtpm_add(libxl__egc *egc, uint32_t domid, + libxl_device_vtpm *vtpm, + libxl__ao_device *aodev) +{ + STATE_AO_GC(aodev->ao); + flexarray_t *front; + flexarray_t *back; + libxl__device *device; + char *dompath, **l; + unsigned int nb, rc; + + rc = libxl__device_vtpm_setdefault(gc, vtpm); + if (rc) goto out; + + front = flexarray_make(16, 1); + if (!front) { + rc = ERROR_NOMEM; + goto out; + } + back = flexarray_make(16, 1); + if (!back) { + rc = ERROR_NOMEM; + goto out; + } + + if(vtpm->devid == -1) { + if (!(dompath = libxl__xs_get_dompath(gc, domid))) { + rc = ERROR_FAIL; + goto out_free; + } + l = libxl__xs_directory(gc, XBT_NULL, libxl__sprintf(gc, "%s/device/vtpm", dompath), &nb); + if(l == NULL || nb == 0) { + vtpm->devid = 0; + } else { + vtpm->devid = strtoul(l[nb - 1], NULL, 10) + 1; + } + } + + GCNEW(device); + rc = libxl__device_from_vtpm(gc, domid, vtpm, device); + if ( rc != 0 ) goto out_free; + + flexarray_append(back, "frontend-id"); + flexarray_append(back, libxl__sprintf(gc, "%d", domid)); + flexarray_append(back, "online"); + flexarray_append(back, "1"); + flexarray_append(back, "state"); + flexarray_append(back, libxl__sprintf(gc, "%d", 1)); + + flexarray_append(back, "uuid"); + flexarray_append(back, libxl__sprintf(gc, LIBXL_UUID_FMT, LIBXL_UUID_BYTES(vtpm->uuid))); + flexarray_append(back, "instance"); /* MAYBE CAN GET RID OF THIS */ + flexarray_append(back, "0"); + flexarray_append(back, "pref_instance"); /* MAYBE CAN GET RID OF THIS */ + flexarray_append(back, "0"); + flexarray_append(back, "resume"); + flexarray_append(back, "False"); + flexarray_append(back, "ready"); /* MAYBE CAN GET RID OF THIS */ + flexarray_append(back, "1"); + + flexarray_append(front, "backend-id"); + flexarray_append(front, libxl__sprintf(gc, "%d", vtpm->backend_domid)); + flexarray_append(front, "state"); + flexarray_append(front, libxl__sprintf(gc, "%d", 1)); + flexarray_append(front, "handle"); + flexarray_append(front, libxl__sprintf(gc, "%d", vtpm->devid)); + + libxl__device_generic_add(gc, XBT_NULL, device, + libxl__xs_kvs_of_flexarray(gc, back, back->count), + libxl__xs_kvs_of_flexarray(gc, front, front->count)); + + aodev->dev = device; + aodev->action = DEVICE_CONNECT; + libxl__wait_device_connection(egc, aodev); + + rc = 0; +out_free: + flexarray_free(back); + flexarray_free(front); +out: + aodev->rc = rc; + if(rc) aodev->callback(egc, aodev); + return; +} + +static void libxl__device_vtpm_from_xs_fe(libxl__gc *gc, + const char* fe_path, + libxl_device_vtpm *vtpm) +{ + char* tmp; + + memset(vtpm, 0, sizeof(*vtpm)); + tmp = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/handle", fe_path)); + if (tmp) { + vtpm->devid = atoi(tmp); + } + tmp = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/backend-id", fe_path)); + if(tmp) { + vtpm->backend_domid = atoi(tmp); + } + tmp = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/uuid", fe_path)); + if(tmp) { + libxl_uuid_from_string(&(vtpm->uuid), tmp); + } +} + +libxl_device_vtpm *libxl_device_vtpm_list(libxl_ctx *ctx, uint32_t domid, int *num) +{ + GC_INIT(ctx); + + libxl_device_vtpm* vtpms = NULL; + char* fe_path = NULL; + char** dir = NULL; + unsigned int ndirs = 0; + + *num = 0; + + fe_path = libxl__sprintf(gc, "%s/device/vtpm", libxl__xs_get_dompath(gc, domid)); + dir = libxl__xs_directory(gc, XBT_NULL, fe_path, &ndirs); + if(dir) { + vtpms = malloc(sizeof(*vtpms) * ndirs); + libxl_device_vtpm* vtpm; + libxl_device_vtpm* end = vtpms + ndirs; + for(vtpm = vtpms; vtpm < end; ++vtpm, ++dir) { + const char* path = libxl__sprintf(gc, "%s/%s", fe_path, *dir); + libxl__device_vtpm_from_xs_fe(gc, path, vtpm); + } + } + *num = ndirs; + + GC_FREE; + return vtpms; +} + +int libxl_device_vtpm_getinfo(libxl_ctx *ctx, uint32_t domid, + libxl_device_vtpm *vtpm, libxl_vtpminfo *vtpminfo) +{ + GC_INIT(ctx); + char *dompath, *vtpmpath; + char *val; + int rc = 0; + + libxl_vtpminfo_init(vtpminfo); + dompath = libxl__xs_get_dompath(gc, domid); + vtpminfo->devid = vtpm->devid; + + vtpmpath = libxl__sprintf(gc, "%s/device/vtpm/%d", dompath, vtpminfo->devid); + vtpminfo->backend = xs_read(ctx->xsh, XBT_NULL, + libxl__sprintf(gc, "%s/backend", vtpmpath), NULL); + if (!vtpminfo->backend) { + goto err; + } + if(!libxl__xs_read(gc, XBT_NULL, vtpminfo->backend)) { + goto err; + } + + val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/backend-id", vtpmpath)); + vtpminfo->backend_id = val ? strtoul(val, NULL, 10) : -1; + val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/state", vtpmpath)); + vtpminfo->state = val ? strtoul(val, NULL, 10) : -1; + val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/event-channel", vtpmpath)); + vtpminfo->evtch = val ? strtoul(val, NULL, 10) : -1; + val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/ring-ref", vtpmpath)); + vtpminfo->rref = val ? strtoul(val, NULL, 10) : -1; + vtpminfo->frontend = xs_read(ctx->xsh, XBT_NULL, + libxl__sprintf(gc, "%s/frontend", vtpminfo->backend), NULL); + val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/frontend-id", vtpminfo->backend)); + vtpminfo->frontend_id = val ? strtoul(val, NULL, 10) : -1; + + val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/uuid", vtpminfo->backend)); + if(val == NULL) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s/uuid does not exist!\n", vtpminfo->backend); + goto err; + } + if(libxl_uuid_from_string(&(vtpminfo->uuid), val)) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s/uuid is a malformed uuid?? (%s) Probably a bug!\n", vtpminfo->backend, val); + goto err; + } + + goto exit; +err: + rc = ERROR_FAIL; +exit: + GC_FREE; + return rc; +} + +int libxl_devid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid, + int devid, libxl_device_vtpm *vtpm) +{ + libxl_device_vtpm *vtpms; + int nb, i; + int rc; + + vtpms = libxl_device_vtpm_list(ctx, domid, &nb); + if (!vtpms) + return ERROR_FAIL; + + memset(vtpm, 0, sizeof (libxl_device_vtpm)); + rc = 1; + for (i = 0; i < nb; ++i) { + if(devid == vtpms[i].devid) { + vtpm->backend_domid = vtpms[i].backend_domid; + vtpm->devid = vtpms[i].devid; + libxl_uuid_copy(&vtpm->uuid, &vtpms[i].uuid); + rc = 0; + break; + } + } + + for (i=0; ivkbs[i]); free(d_config->vkbs); + for (i=0; inum_vtpms; i++) + libxl_device_vtpm_dispose(&d_config->vtpms[i]); + free(d_config->vtpms); + libxl_domain_create_info_dispose(&d_config->c_info); libxl_domain_build_info_dispose(&d_config->b_info); } @@ -601,6 +605,8 @@ static void domcreate_bootloader_done(libxl__egc *egc, static void domcreate_launch_dm(libxl__egc *egc, libxl__multidev *aodevs, int ret); +static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multidev *multidev, + int ret); static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev *aodevs, int ret); @@ -1084,13 +1090,13 @@ static void domcreate_devmodel_started(libxl__egc *egc, if (d_config->num_nics > 0) { /* Attach nics */ libxl__multidev_begin(ao, &dcs->multidev); - dcs->multidev.callback = domcreate_attach_pci; + dcs->multidev.callback = domcreate_attach_vtpms; libxl__add_nics(egc, ao, domid, d_config, &dcs->multidev); libxl__multidev_prepared(egc, &dcs->multidev, 0); return; } - domcreate_attach_pci(egc, &dcs->multidev, 0); + domcreate_attach_vtpms(egc, &dcs->multidev, 0); return; error_out: @@ -1098,6 +1104,36 @@ error_out: domcreate_complete(egc, dcs, ret); } +static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multidev *multidev, int ret) { + libxl__domain_create_state *dcs = CONTAINER_OF(multidev, *dcs, multidev); + STATE_AO_GC(dcs->ao); + int domid = dcs->guest_domid; + + libxl_domain_config* const d_config = dcs->guest_config; + + if(ret) { + LOG(ERROR, "unable to add nic devices"); + goto error_out; + } + + /* Plug vtpm devices */ + if (d_config->num_vtpms > 0) { + /* Attach vtpms */ + libxl__multidev_begin(ao, &dcs->multidev); + dcs->multidev.callback = domcreate_attach_pci; + libxl__add_vtpms(egc, ao, domid, d_config, &dcs->multidev); + libxl__multidev_prepared(egc, &dcs->multidev, 0); + return; + } + + domcreate_attach_pci(egc, multidev, 0); + return; + +error_out: + assert(ret); + domcreate_complete(egc, dcs, ret); +} + static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev *multidev, int ret) { @@ -1111,7 +1147,7 @@ static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev *multidev, libxl_domain_config *const d_config = dcs->guest_config; if (ret) { - LOG(ERROR, "unable to add nic devices"); + LOG(ERROR, "unable to add vtpm devices"); goto error_out; } diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c index c3283f1..51dd06e 100644 --- a/tools/libxl/libxl_device.c +++ b/tools/libxl/libxl_device.c @@ -497,6 +497,7 @@ void libxl__multidev_prepared(libxl__egc *egc, * The following functions are defined: * libxl__add_disks * libxl__add_nics + * libxl__add_vtpms */ #define DEFINE_DEVICES_ADD(type) \ @@ -515,6 +516,7 @@ void libxl__multidev_prepared(libxl__egc *egc, DEFINE_DEVICES_ADD(disk) DEFINE_DEVICES_ADD(nic) +DEFINE_DEVICES_ADD(vtpm) #undef DEFINE_DEVICES_ADD diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index b6f54ba..e9a7cbb 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -954,6 +954,7 @@ _hidden int libxl__device_disk_setdefault(libxl__gc *gc, libxl_device_disk *disk); _hidden int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic, uint32_t domid); +_hidden int libxl__device_vtpm_setdefault(libxl__gc *gc, libxl_device_vtpm *vtpm); _hidden int libxl__device_vfb_setdefault(libxl__gc *gc, libxl_device_vfb *vfb); _hidden int libxl__device_vkb_setdefault(libxl__gc *gc, libxl_device_vkb *vkb); _hidden int libxl__device_pci_setdefault(libxl__gc *gc, libxl_device_pci *pci); @@ -1975,6 +1976,10 @@ _hidden void libxl__device_nic_add(libxl__egc *egc, uint32_t domid, libxl_device_nic *nic, libxl__ao_device *aodev); +_hidden void libxl__device_vtpm_add(libxl__egc *egc, uint32_t domid, + libxl_device_vtpm *vtpm, + 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); @@ -2407,6 +2412,10 @@ _hidden void libxl__add_nics(libxl__egc *egc, libxl__ao *ao, uint32_t domid, libxl_domain_config *d_config, libxl__multidev *multidev); +_hidden void libxl__add_vtpms(libxl__egc *egc, libxl__ao *ao, uint32_t domid, + libxl_domain_config *d_config, + libxl__multidev *multidev); + /*----- device model creation -----*/ /* First layer; wraps libxl__spawn_spawn. */ diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl index de111a6..7eac4a8 100644 --- a/tools/libxl/libxl_types.idl +++ b/tools/libxl/libxl_types.idl @@ -395,6 +395,12 @@ libxl_device_pci = Struct("device_pci", [ ("permissive", bool), ]) +libxl_device_vtpm = Struct("device_vtpm", [ + ("backend_domid", libxl_domid), + ("devid", libxl_devid), + ("uuid", libxl_uuid), +]) + libxl_diskinfo = Struct("diskinfo", [ ("backend", string), ("backend_id", uint32), @@ -418,6 +424,18 @@ libxl_nicinfo = Struct("nicinfo", [ ("rref_rx", integer), ], dir=DIR_OUT) +libxl_vtpminfo = Struct("vtpminfo", [ + ("backend", string), + ("backend_id", uint32), + ("frontend", string), + ("frontend_id", uint32), + ("devid", libxl_devid), + ("state", integer), + ("evtch", integer), + ("rref", integer), + ("uuid", libxl_uuid), + ], dir=DIR_OUT) + libxl_vcpuinfo = Struct("vcpuinfo", [ ("vcpuid", uint32), ("cpu", uint32), diff --git a/tools/libxl/libxl_types_internal.idl b/tools/libxl/libxl_types_internal.idl index 5ac8c9c..c40120e 100644 --- a/tools/libxl/libxl_types_internal.idl +++ b/tools/libxl/libxl_types_internal.idl @@ -19,6 +19,7 @@ libxl__device_kind = Enumeration("device_kind", [ (5, "VFB"), (6, "VKBD"), (7, "CONSOLE"), + (8, "VTPM"), ]) libxl__console_backend = Enumeration("console_backend", [ diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c index 55cd299..73a158a 100644 --- a/tools/libxl/libxl_utils.c +++ b/tools/libxl/libxl_utils.c @@ -463,6 +463,35 @@ int libxl_pipe(libxl_ctx *ctx, int pipes[2]) return 0; } +int libxl_uuid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid, + libxl_uuid* uuid, libxl_device_vtpm *vtpm) +{ + libxl_device_vtpm *vtpms; + int nb, i; + int rc; + + vtpms = libxl_device_vtpm_list(ctx, domid, &nb); + if (!vtpms) + return ERROR_FAIL; + + memset(vtpm, 0, sizeof (libxl_device_vtpm)); + rc = 1; + for (i = 0; i < nb; ++i) { + if(!libxl_uuid_compare(uuid, &vtpms[i].uuid)) { + vtpm->backend_domid = vtpms[i].backend_domid; + vtpm->devid = vtpms[i].devid; + libxl_uuid_copy(&vtpm->uuid, &vtpms[i].uuid); + rc = 0; + break; + } + } + + for (i=0; inum_vtpms = 0; + d_config->vtpms = NULL; + while ((buf = xlu_cfg_get_listitem (vtpms, d_config->num_vtpms)) != NULL) { + libxl_device_vtpm *vtpm; + char * buf2 = strdup(buf); + char *p, *p2; + bool got_backend = false; + + d_config->vtpms = (libxl_device_vtpm *) realloc(d_config->vtpms, sizeof(libxl_device_vtpm) * (d_config->num_vtpms+1)); + vtpm = d_config->vtpms + d_config->num_vtpms; + libxl_device_vtpm_init(vtpm); + vtpm->devid = d_config->num_vtpms; + + p = strtok(buf2, ","); + if(p) { + do { + while(*p == ' ') + ++p; + if ((p2 = strchr(p, '=')) == NULL) + break; + *p2 = '\0'; + if (!strcmp(p, "backend")) { + if(domain_qualifier_to_domid(p2 + 1, &(vtpm->backend_domid), 0)) + { + fprintf(stderr, "Specified vtpm backend domain `%s' does not exist!\n", p2 + 1); + exit(1); + } + got_backend = true; + } else if(!strcmp(p, "uuid")) { + if( libxl_uuid_from_string(&vtpm->uuid, p2 + 1) ) { + fprintf(stderr, "Failed to parse vtpm UUID: %s\n", p2 + 1); + exit(1); + } + } else { + fprintf(stderr, "Unknown string `%s' in vtpm spec\n", p); + exit(1); + } + } while ((p = strtok(NULL, ",")) != NULL); + } + if(!got_backend) { + fprintf(stderr, "vtpm spec missing required backend field!\n"); + exit(1); + } + free(buf2); + d_config->num_vtpms++; + } + } + if (!xlu_cfg_get_list (config, "vif", &nics, 0, 0)) { d_config->num_nics = 0; d_config->nics = NULL; @@ -1073,7 +1122,7 @@ static void parse_config_data(const char *config_source, p = strtok(buf2, ","); if (!p) - goto skip; + goto skip_nic; do { while (*p == ' ') p++; @@ -1137,7 +1186,7 @@ static void parse_config_data(const char *config_source, fprintf(stderr, "the accel parameter for vifs is currently not supported\n"); } } while ((p = strtok(NULL, ",")) != NULL); -skip: +skip_nic: free(buf2); d_config->num_nics++; } @@ -5573,6 +5622,131 @@ int main_blockdetach(int argc, char **argv) return rc; } +int main_vtpmattach(int argc, char **argv) +{ + int opt; + libxl_device_vtpm vtpm; + char *oparg; + unsigned int val; + uint32_t domid; + + if ((opt = def_getopt(argc, argv, "", "vtpm-attach", 1)) != -1) + return opt; + + if (domain_qualifier_to_domid(argv[optind], &domid, 0) < 0) { + fprintf(stderr, "%s is an invalid domain identifier\n", argv[optind]); + return 1; + } + ++optind; + + libxl_device_vtpm_init(&vtpm); + for (argv += optind, argc -= optind; argc > 0; ++argv, --argc) { + if (MATCH_OPTION("uuid", *argv, oparg)) { + if(libxl_uuid_from_string(&(vtpm.uuid), oparg)) { + fprintf(stderr, "Invalid uuid specified (%s)\n", oparg); + return 1; + } + } else if (MATCH_OPTION("backend", *argv, oparg)) { + if(domain_qualifier_to_domid(oparg, &val, 0)) { + fprintf(stderr, "Specified backend domain does not exist, defaulting to Dom0\n"); + val = 0; + } + vtpm.backend_domid = val; + } else { + fprintf(stderr, "unrecognized argument `%s'\n", *argv); + return 1; + } + } + + if(dryrun_only) { + char* json = libxl_device_vtpm_to_json(ctx, &vtpm); + printf("vtpm: %s\n", json); + free(json); + libxl_device_vtpm_dispose(&vtpm); + if (ferror(stdout) || fflush(stdout)) { perror("stdout"); exit(-1); } + return 0; + } + + if (libxl_device_vtpm_add(ctx, domid, &vtpm, 0)) { + fprintf(stderr, "libxl_device_vtpm_add failed.\n"); + return 1; + } + libxl_device_vtpm_dispose(&vtpm); + return 0; +} + +int main_vtpmlist(int argc, char **argv) +{ + int opt; + libxl_device_vtpm *vtpms; + libxl_vtpminfo vtpminfo; + int nb, i; + + if ((opt = def_getopt(argc, argv, "", "vtpm-list", 1)) != -1) + return opt; + + /* Idx BE UUID Hdl Sta evch rref BE-path */ + printf("%-3s %-2s %-36s %-6s %-5s %-6s %-5s %-10s\n", + "Idx", "BE", "Uuid", "handle", "state", "evt-ch", "ring-ref", "BE-path"); + for (argv += optind, argc -= optind; argc > 0; --argc, ++argv) { + uint32_t domid; + if (domain_qualifier_to_domid(*argv, &domid, 0) < 0) { + fprintf(stderr, "%s is an invalid domain identifier\n", *argv); + continue; + } + if (!(vtpms = libxl_device_vtpm_list(ctx, domid, &nb))) { + continue; + } + for (i = 0; i < nb; ++i) { + if(!libxl_device_vtpm_getinfo(ctx, domid, &vtpms[i], &vtpminfo)) { + /* Idx BE UUID Hdl Sta evch rref BE-path*/ + printf("%-3d %-2d " LIBXL_UUID_FMT " %6d %5d %6d %8d %-30s\n", + vtpminfo.devid, vtpminfo.backend_id, + LIBXL_UUID_BYTES(vtpminfo.uuid), + vtpminfo.devid, vtpminfo.state, vtpminfo.evtch, + vtpminfo.rref, vtpminfo.backend); + + libxl_vtpminfo_dispose(&vtpminfo); + } + libxl_device_vtpm_dispose(&vtpms[i]); + } + free(vtpms); + } + return 0; +} + +int main_vtpmdetach(int argc, char **argv) +{ + uint32_t domid; + int opt, rc=0; + libxl_device_vtpm vtpm; + libxl_uuid uuid; + + if ((opt = def_getopt(argc, argv, "", "vtpm-detach", 2)) != -1) + return opt; + + domid = find_domain(argv[optind]); + + if ( libxl_uuid_from_string(&uuid, argv[optind+1])) { + if (libxl_devid_to_device_vtpm(ctx, domid, atoi(argv[optind+1]), &vtpm)) { + fprintf(stderr, "Unknown device %s.\n", argv[optind+1]); + return 1; + } + } else { + if (libxl_uuid_to_device_vtpm(ctx, domid, &uuid, &vtpm)) { + fprintf(stderr, "Unknown device %s.\n", argv[optind+1]); + return 1; + } + } + rc = libxl_device_vtpm_remove(ctx, domid, &vtpm, 0); + if (rc) { + fprintf(stderr, "libxl_device_vtpm_remove failed.\n"); + } + libxl_device_vtpm_dispose(&vtpm); + return rc; +} + + static char *uptime_to_string(unsigned long uptime, int short_mode) { int sec, min, hour, day; diff --git a/tools/libxl/xl_cmdtable.c b/tools/libxl/xl_cmdtable.c index 85ea768..7c018eb 100644 --- a/tools/libxl/xl_cmdtable.c +++ b/tools/libxl/xl_cmdtable.c @@ -338,6 +338,21 @@ struct cmd_spec cmd_table[] = { "Destroy a domain's virtual block device", " ", }, + { "vtpm-attach", + &main_vtpmattach, 0, 1, + "Create a new virtual TPM device", + " [uuid=] [backend=]", + }, + { "vtpm-list", + &main_vtpmlist, 0, 0, + "List virtual TPM devices for a domain", + "", + }, + { "vtpm-detach", + &main_vtpmdetach, 0, 1, + "Destroy a domain's virtual TPM device", + " ", + }, { "uptime", &main_uptime, 0, 0, "Print uptime for all/some domains", -- 1.7.4.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 18:02:42 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 18:02:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCEO-0002u2-Qg; Fri, 05 Oct 2012 18:02:36 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCEN-0002t8-9v for xen-devel@lists.xen.org; Fri, 05 Oct 2012 18:02:35 +0000 Received: from [85.158.139.83:51189] by server-7.bemta-5.messagelabs.com id 78/7D-00431-AB02F605; Fri, 05 Oct 2012 18:02:34 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-3.tower-182.messagelabs.com!1349460150!33605348!1 X-Originating-IP: [128.244.251.37] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG, UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22154 invoked from network); 5 Oct 2012 18:02:32 -0000 Received: from piper.jhuapl.edu (HELO jhuapl.edu) (128.244.251.37) by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 18:02:32 -0000 Received: from ([128.244.207.97]) by piper.jhuapl.edu with ESMTP with TLS id 5Y8HCH1.146215729; Fri, 05 Oct 2012 14:02:01 -0400 From: Matthew Fioravante To: xen-devel@lists.xen.org, ian.campbell@citrix.com Date: Fri, 5 Oct 2012 14:02:11 -0400 Message-Id: <1349460132-13853-3-git-send-email-matthew.fioravante@jhuapl.edu> X-Mailer: git-send-email 1.7.4.4 In-Reply-To: <1349460132-13853-1-git-send-email-matthew.fioravante@jhuapl.edu> References: <1349460132-13853-1-git-send-email-matthew.fioravante@jhuapl.edu> Cc: Matthew Fioravante Subject: [Xen-devel] [PATCH vtpm v2 11/12] add vtpm support to libxl X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This patch adds vtpm support to libxl. It adds vtpm parsing to config files and 3 new xl commands: vtpm-attach vtpm-detach vtpm-list Signed-off-by: Matthew Fioravante diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5 index 428da21..9f6ee5a 100644 --- a/docs/man/xl.cfg.pod.5 +++ b/docs/man/xl.cfg.pod.5 @@ -298,6 +298,35 @@ Specifies the networking provision (both emulated network adapters, and Xen virtual interfaces) to provided to the guest. See F. +=item B + +Specifies the virtual trusted platform module to be +provided to the guest. Please see F +for more details. + +Each B is a comma-separated list of C +settings, from the following list: + +=over 4 + +=item C + +Specify the backend domain name of id. This value is required! +If this domain is a guest, the backend should be set to the +vtpm domain name. If this domain is a vtpm, the +backend should be set to the vtpm manager domain name. + +=item C + +Specify the uuid of this vtpm device. The uuid is used to uniquely +identify the vtpm device. You can create one using the uuidgen +program on unix systems. If left unspecified, a new uuid +will be randomly generated every time the domain boots. +If this is a vtpm domain, you should specify a value. The +value is optional if this is a guest domain. + +=back + =item B Specifies the paravirtual framebuffer devices which should be supplied diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1 index 25ce777..be9ad4c 100644 --- a/docs/man/xl.pod.1 +++ b/docs/man/xl.pod.1 @@ -1101,6 +1101,31 @@ List virtual network interfaces for a domain. =back +=head2 VTPM DEVICES + +=over 4 + +=item B I I + +Creates a new vtpm device in the domain specified by I. +I describes the device to attach, using the same format as the +B string in the domain config file. See L for +more information. + +=item B I I + +Removes the vtpm device from the domain specified by I. +I is the numeric device id given to the virtual trusted +platform module device. You will need to run B to determine that number. +Alternatively the I of the vtpm can be used to +select the virtual device to detach. + +=item B I + +List virtual trusted platform modules for a domain. + +=back + =head1 PCI PASS-THROUGH =over 4 diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c index 1606eb1..17094ca 100644 --- a/tools/libxl/libxl.c +++ b/tools/libxl/libxl.c @@ -1726,6 +1726,246 @@ out: } /******************************************************************************/ +int libxl__device_vtpm_setdefault(libxl__gc *gc, libxl_device_vtpm *vtpm) +{ + if(libxl_uuid_is_nil(&vtpm->uuid)) { + libxl_uuid_generate(&vtpm->uuid); + } + return 0; +} + +static int libxl__device_from_vtpm(libxl__gc *gc, uint32_t domid, + libxl_device_vtpm *vtpm, + libxl__device *device) +{ + device->backend_devid = vtpm->devid; + device->backend_domid = vtpm->backend_domid; + device->backend_kind = LIBXL__DEVICE_KIND_VTPM; + device->devid = vtpm->devid; + device->domid = domid; + device->kind = LIBXL__DEVICE_KIND_VTPM; + + return 0; +} + +void libxl__device_vtpm_add(libxl__egc *egc, uint32_t domid, + libxl_device_vtpm *vtpm, + libxl__ao_device *aodev) +{ + STATE_AO_GC(aodev->ao); + flexarray_t *front; + flexarray_t *back; + libxl__device *device; + char *dompath, **l; + unsigned int nb, rc; + + rc = libxl__device_vtpm_setdefault(gc, vtpm); + if (rc) goto out; + + front = flexarray_make(16, 1); + if (!front) { + rc = ERROR_NOMEM; + goto out; + } + back = flexarray_make(16, 1); + if (!back) { + rc = ERROR_NOMEM; + goto out; + } + + if(vtpm->devid == -1) { + if (!(dompath = libxl__xs_get_dompath(gc, domid))) { + rc = ERROR_FAIL; + goto out_free; + } + l = libxl__xs_directory(gc, XBT_NULL, libxl__sprintf(gc, "%s/device/vtpm", dompath), &nb); + if(l == NULL || nb == 0) { + vtpm->devid = 0; + } else { + vtpm->devid = strtoul(l[nb - 1], NULL, 10) + 1; + } + } + + GCNEW(device); + rc = libxl__device_from_vtpm(gc, domid, vtpm, device); + if ( rc != 0 ) goto out_free; + + flexarray_append(back, "frontend-id"); + flexarray_append(back, libxl__sprintf(gc, "%d", domid)); + flexarray_append(back, "online"); + flexarray_append(back, "1"); + flexarray_append(back, "state"); + flexarray_append(back, libxl__sprintf(gc, "%d", 1)); + + flexarray_append(back, "uuid"); + flexarray_append(back, libxl__sprintf(gc, LIBXL_UUID_FMT, LIBXL_UUID_BYTES(vtpm->uuid))); + flexarray_append(back, "instance"); /* MAYBE CAN GET RID OF THIS */ + flexarray_append(back, "0"); + flexarray_append(back, "pref_instance"); /* MAYBE CAN GET RID OF THIS */ + flexarray_append(back, "0"); + flexarray_append(back, "resume"); + flexarray_append(back, "False"); + flexarray_append(back, "ready"); /* MAYBE CAN GET RID OF THIS */ + flexarray_append(back, "1"); + + flexarray_append(front, "backend-id"); + flexarray_append(front, libxl__sprintf(gc, "%d", vtpm->backend_domid)); + flexarray_append(front, "state"); + flexarray_append(front, libxl__sprintf(gc, "%d", 1)); + flexarray_append(front, "handle"); + flexarray_append(front, libxl__sprintf(gc, "%d", vtpm->devid)); + + libxl__device_generic_add(gc, XBT_NULL, device, + libxl__xs_kvs_of_flexarray(gc, back, back->count), + libxl__xs_kvs_of_flexarray(gc, front, front->count)); + + aodev->dev = device; + aodev->action = DEVICE_CONNECT; + libxl__wait_device_connection(egc, aodev); + + rc = 0; +out_free: + flexarray_free(back); + flexarray_free(front); +out: + aodev->rc = rc; + if(rc) aodev->callback(egc, aodev); + return; +} + +static void libxl__device_vtpm_from_xs_fe(libxl__gc *gc, + const char* fe_path, + libxl_device_vtpm *vtpm) +{ + char* tmp; + + memset(vtpm, 0, sizeof(*vtpm)); + tmp = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/handle", fe_path)); + if (tmp) { + vtpm->devid = atoi(tmp); + } + tmp = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/backend-id", fe_path)); + if(tmp) { + vtpm->backend_domid = atoi(tmp); + } + tmp = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/uuid", fe_path)); + if(tmp) { + libxl_uuid_from_string(&(vtpm->uuid), tmp); + } +} + +libxl_device_vtpm *libxl_device_vtpm_list(libxl_ctx *ctx, uint32_t domid, int *num) +{ + GC_INIT(ctx); + + libxl_device_vtpm* vtpms = NULL; + char* fe_path = NULL; + char** dir = NULL; + unsigned int ndirs = 0; + + *num = 0; + + fe_path = libxl__sprintf(gc, "%s/device/vtpm", libxl__xs_get_dompath(gc, domid)); + dir = libxl__xs_directory(gc, XBT_NULL, fe_path, &ndirs); + if(dir) { + vtpms = malloc(sizeof(*vtpms) * ndirs); + libxl_device_vtpm* vtpm; + libxl_device_vtpm* end = vtpms + ndirs; + for(vtpm = vtpms; vtpm < end; ++vtpm, ++dir) { + const char* path = libxl__sprintf(gc, "%s/%s", fe_path, *dir); + libxl__device_vtpm_from_xs_fe(gc, path, vtpm); + } + } + *num = ndirs; + + GC_FREE; + return vtpms; +} + +int libxl_device_vtpm_getinfo(libxl_ctx *ctx, uint32_t domid, + libxl_device_vtpm *vtpm, libxl_vtpminfo *vtpminfo) +{ + GC_INIT(ctx); + char *dompath, *vtpmpath; + char *val; + int rc = 0; + + libxl_vtpminfo_init(vtpminfo); + dompath = libxl__xs_get_dompath(gc, domid); + vtpminfo->devid = vtpm->devid; + + vtpmpath = libxl__sprintf(gc, "%s/device/vtpm/%d", dompath, vtpminfo->devid); + vtpminfo->backend = xs_read(ctx->xsh, XBT_NULL, + libxl__sprintf(gc, "%s/backend", vtpmpath), NULL); + if (!vtpminfo->backend) { + goto err; + } + if(!libxl__xs_read(gc, XBT_NULL, vtpminfo->backend)) { + goto err; + } + + val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/backend-id", vtpmpath)); + vtpminfo->backend_id = val ? strtoul(val, NULL, 10) : -1; + val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/state", vtpmpath)); + vtpminfo->state = val ? strtoul(val, NULL, 10) : -1; + val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/event-channel", vtpmpath)); + vtpminfo->evtch = val ? strtoul(val, NULL, 10) : -1; + val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/ring-ref", vtpmpath)); + vtpminfo->rref = val ? strtoul(val, NULL, 10) : -1; + vtpminfo->frontend = xs_read(ctx->xsh, XBT_NULL, + libxl__sprintf(gc, "%s/frontend", vtpminfo->backend), NULL); + val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/frontend-id", vtpminfo->backend)); + vtpminfo->frontend_id = val ? strtoul(val, NULL, 10) : -1; + + val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/uuid", vtpminfo->backend)); + if(val == NULL) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s/uuid does not exist!\n", vtpminfo->backend); + goto err; + } + if(libxl_uuid_from_string(&(vtpminfo->uuid), val)) { + LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s/uuid is a malformed uuid?? (%s) Probably a bug!\n", vtpminfo->backend, val); + goto err; + } + + goto exit; +err: + rc = ERROR_FAIL; +exit: + GC_FREE; + return rc; +} + +int libxl_devid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid, + int devid, libxl_device_vtpm *vtpm) +{ + libxl_device_vtpm *vtpms; + int nb, i; + int rc; + + vtpms = libxl_device_vtpm_list(ctx, domid, &nb); + if (!vtpms) + return ERROR_FAIL; + + memset(vtpm, 0, sizeof (libxl_device_vtpm)); + rc = 1; + for (i = 0; i < nb; ++i) { + if(devid == vtpms[i].devid) { + vtpm->backend_domid = vtpms[i].backend_domid; + vtpm->devid = vtpms[i].devid; + libxl_uuid_copy(&vtpm->uuid, &vtpms[i].uuid); + rc = 0; + break; + } + } + + for (i=0; ivkbs[i]); free(d_config->vkbs); + for (i=0; inum_vtpms; i++) + libxl_device_vtpm_dispose(&d_config->vtpms[i]); + free(d_config->vtpms); + libxl_domain_create_info_dispose(&d_config->c_info); libxl_domain_build_info_dispose(&d_config->b_info); } @@ -601,6 +605,8 @@ static void domcreate_bootloader_done(libxl__egc *egc, static void domcreate_launch_dm(libxl__egc *egc, libxl__multidev *aodevs, int ret); +static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multidev *multidev, + int ret); static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev *aodevs, int ret); @@ -1084,13 +1090,13 @@ static void domcreate_devmodel_started(libxl__egc *egc, if (d_config->num_nics > 0) { /* Attach nics */ libxl__multidev_begin(ao, &dcs->multidev); - dcs->multidev.callback = domcreate_attach_pci; + dcs->multidev.callback = domcreate_attach_vtpms; libxl__add_nics(egc, ao, domid, d_config, &dcs->multidev); libxl__multidev_prepared(egc, &dcs->multidev, 0); return; } - domcreate_attach_pci(egc, &dcs->multidev, 0); + domcreate_attach_vtpms(egc, &dcs->multidev, 0); return; error_out: @@ -1098,6 +1104,36 @@ error_out: domcreate_complete(egc, dcs, ret); } +static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multidev *multidev, int ret) { + libxl__domain_create_state *dcs = CONTAINER_OF(multidev, *dcs, multidev); + STATE_AO_GC(dcs->ao); + int domid = dcs->guest_domid; + + libxl_domain_config* const d_config = dcs->guest_config; + + if(ret) { + LOG(ERROR, "unable to add nic devices"); + goto error_out; + } + + /* Plug vtpm devices */ + if (d_config->num_vtpms > 0) { + /* Attach vtpms */ + libxl__multidev_begin(ao, &dcs->multidev); + dcs->multidev.callback = domcreate_attach_pci; + libxl__add_vtpms(egc, ao, domid, d_config, &dcs->multidev); + libxl__multidev_prepared(egc, &dcs->multidev, 0); + return; + } + + domcreate_attach_pci(egc, multidev, 0); + return; + +error_out: + assert(ret); + domcreate_complete(egc, dcs, ret); +} + static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev *multidev, int ret) { @@ -1111,7 +1147,7 @@ static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev *multidev, libxl_domain_config *const d_config = dcs->guest_config; if (ret) { - LOG(ERROR, "unable to add nic devices"); + LOG(ERROR, "unable to add vtpm devices"); goto error_out; } diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c index c3283f1..51dd06e 100644 --- a/tools/libxl/libxl_device.c +++ b/tools/libxl/libxl_device.c @@ -497,6 +497,7 @@ void libxl__multidev_prepared(libxl__egc *egc, * The following functions are defined: * libxl__add_disks * libxl__add_nics + * libxl__add_vtpms */ #define DEFINE_DEVICES_ADD(type) \ @@ -515,6 +516,7 @@ void libxl__multidev_prepared(libxl__egc *egc, DEFINE_DEVICES_ADD(disk) DEFINE_DEVICES_ADD(nic) +DEFINE_DEVICES_ADD(vtpm) #undef DEFINE_DEVICES_ADD diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index b6f54ba..e9a7cbb 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -954,6 +954,7 @@ _hidden int libxl__device_disk_setdefault(libxl__gc *gc, libxl_device_disk *disk); _hidden int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic, uint32_t domid); +_hidden int libxl__device_vtpm_setdefault(libxl__gc *gc, libxl_device_vtpm *vtpm); _hidden int libxl__device_vfb_setdefault(libxl__gc *gc, libxl_device_vfb *vfb); _hidden int libxl__device_vkb_setdefault(libxl__gc *gc, libxl_device_vkb *vkb); _hidden int libxl__device_pci_setdefault(libxl__gc *gc, libxl_device_pci *pci); @@ -1975,6 +1976,10 @@ _hidden void libxl__device_nic_add(libxl__egc *egc, uint32_t domid, libxl_device_nic *nic, libxl__ao_device *aodev); +_hidden void libxl__device_vtpm_add(libxl__egc *egc, uint32_t domid, + libxl_device_vtpm *vtpm, + 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); @@ -2407,6 +2412,10 @@ _hidden void libxl__add_nics(libxl__egc *egc, libxl__ao *ao, uint32_t domid, libxl_domain_config *d_config, libxl__multidev *multidev); +_hidden void libxl__add_vtpms(libxl__egc *egc, libxl__ao *ao, uint32_t domid, + libxl_domain_config *d_config, + libxl__multidev *multidev); + /*----- device model creation -----*/ /* First layer; wraps libxl__spawn_spawn. */ diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl index de111a6..7eac4a8 100644 --- a/tools/libxl/libxl_types.idl +++ b/tools/libxl/libxl_types.idl @@ -395,6 +395,12 @@ libxl_device_pci = Struct("device_pci", [ ("permissive", bool), ]) +libxl_device_vtpm = Struct("device_vtpm", [ + ("backend_domid", libxl_domid), + ("devid", libxl_devid), + ("uuid", libxl_uuid), +]) + libxl_diskinfo = Struct("diskinfo", [ ("backend", string), ("backend_id", uint32), @@ -418,6 +424,18 @@ libxl_nicinfo = Struct("nicinfo", [ ("rref_rx", integer), ], dir=DIR_OUT) +libxl_vtpminfo = Struct("vtpminfo", [ + ("backend", string), + ("backend_id", uint32), + ("frontend", string), + ("frontend_id", uint32), + ("devid", libxl_devid), + ("state", integer), + ("evtch", integer), + ("rref", integer), + ("uuid", libxl_uuid), + ], dir=DIR_OUT) + libxl_vcpuinfo = Struct("vcpuinfo", [ ("vcpuid", uint32), ("cpu", uint32), diff --git a/tools/libxl/libxl_types_internal.idl b/tools/libxl/libxl_types_internal.idl index 5ac8c9c..c40120e 100644 --- a/tools/libxl/libxl_types_internal.idl +++ b/tools/libxl/libxl_types_internal.idl @@ -19,6 +19,7 @@ libxl__device_kind = Enumeration("device_kind", [ (5, "VFB"), (6, "VKBD"), (7, "CONSOLE"), + (8, "VTPM"), ]) libxl__console_backend = Enumeration("console_backend", [ diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c index 55cd299..73a158a 100644 --- a/tools/libxl/libxl_utils.c +++ b/tools/libxl/libxl_utils.c @@ -463,6 +463,35 @@ int libxl_pipe(libxl_ctx *ctx, int pipes[2]) return 0; } +int libxl_uuid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid, + libxl_uuid* uuid, libxl_device_vtpm *vtpm) +{ + libxl_device_vtpm *vtpms; + int nb, i; + int rc; + + vtpms = libxl_device_vtpm_list(ctx, domid, &nb); + if (!vtpms) + return ERROR_FAIL; + + memset(vtpm, 0, sizeof (libxl_device_vtpm)); + rc = 1; + for (i = 0; i < nb; ++i) { + if(!libxl_uuid_compare(uuid, &vtpms[i].uuid)) { + vtpm->backend_domid = vtpms[i].backend_domid; + vtpm->devid = vtpms[i].devid; + libxl_uuid_copy(&vtpm->uuid, &vtpms[i].uuid); + rc = 0; + break; + } + } + + for (i=0; inum_vtpms = 0; + d_config->vtpms = NULL; + while ((buf = xlu_cfg_get_listitem (vtpms, d_config->num_vtpms)) != NULL) { + libxl_device_vtpm *vtpm; + char * buf2 = strdup(buf); + char *p, *p2; + bool got_backend = false; + + d_config->vtpms = (libxl_device_vtpm *) realloc(d_config->vtpms, sizeof(libxl_device_vtpm) * (d_config->num_vtpms+1)); + vtpm = d_config->vtpms + d_config->num_vtpms; + libxl_device_vtpm_init(vtpm); + vtpm->devid = d_config->num_vtpms; + + p = strtok(buf2, ","); + if(p) { + do { + while(*p == ' ') + ++p; + if ((p2 = strchr(p, '=')) == NULL) + break; + *p2 = '\0'; + if (!strcmp(p, "backend")) { + if(domain_qualifier_to_domid(p2 + 1, &(vtpm->backend_domid), 0)) + { + fprintf(stderr, "Specified vtpm backend domain `%s' does not exist!\n", p2 + 1); + exit(1); + } + got_backend = true; + } else if(!strcmp(p, "uuid")) { + if( libxl_uuid_from_string(&vtpm->uuid, p2 + 1) ) { + fprintf(stderr, "Failed to parse vtpm UUID: %s\n", p2 + 1); + exit(1); + } + } else { + fprintf(stderr, "Unknown string `%s' in vtpm spec\n", p); + exit(1); + } + } while ((p = strtok(NULL, ",")) != NULL); + } + if(!got_backend) { + fprintf(stderr, "vtpm spec missing required backend field!\n"); + exit(1); + } + free(buf2); + d_config->num_vtpms++; + } + } + if (!xlu_cfg_get_list (config, "vif", &nics, 0, 0)) { d_config->num_nics = 0; d_config->nics = NULL; @@ -1073,7 +1122,7 @@ static void parse_config_data(const char *config_source, p = strtok(buf2, ","); if (!p) - goto skip; + goto skip_nic; do { while (*p == ' ') p++; @@ -1137,7 +1186,7 @@ static void parse_config_data(const char *config_source, fprintf(stderr, "the accel parameter for vifs is currently not supported\n"); } } while ((p = strtok(NULL, ",")) != NULL); -skip: +skip_nic: free(buf2); d_config->num_nics++; } @@ -5573,6 +5622,131 @@ int main_blockdetach(int argc, char **argv) return rc; } +int main_vtpmattach(int argc, char **argv) +{ + int opt; + libxl_device_vtpm vtpm; + char *oparg; + unsigned int val; + uint32_t domid; + + if ((opt = def_getopt(argc, argv, "", "vtpm-attach", 1)) != -1) + return opt; + + if (domain_qualifier_to_domid(argv[optind], &domid, 0) < 0) { + fprintf(stderr, "%s is an invalid domain identifier\n", argv[optind]); + return 1; + } + ++optind; + + libxl_device_vtpm_init(&vtpm); + for (argv += optind, argc -= optind; argc > 0; ++argv, --argc) { + if (MATCH_OPTION("uuid", *argv, oparg)) { + if(libxl_uuid_from_string(&(vtpm.uuid), oparg)) { + fprintf(stderr, "Invalid uuid specified (%s)\n", oparg); + return 1; + } + } else if (MATCH_OPTION("backend", *argv, oparg)) { + if(domain_qualifier_to_domid(oparg, &val, 0)) { + fprintf(stderr, "Specified backend domain does not exist, defaulting to Dom0\n"); + val = 0; + } + vtpm.backend_domid = val; + } else { + fprintf(stderr, "unrecognized argument `%s'\n", *argv); + return 1; + } + } + + if(dryrun_only) { + char* json = libxl_device_vtpm_to_json(ctx, &vtpm); + printf("vtpm: %s\n", json); + free(json); + libxl_device_vtpm_dispose(&vtpm); + if (ferror(stdout) || fflush(stdout)) { perror("stdout"); exit(-1); } + return 0; + } + + if (libxl_device_vtpm_add(ctx, domid, &vtpm, 0)) { + fprintf(stderr, "libxl_device_vtpm_add failed.\n"); + return 1; + } + libxl_device_vtpm_dispose(&vtpm); + return 0; +} + +int main_vtpmlist(int argc, char **argv) +{ + int opt; + libxl_device_vtpm *vtpms; + libxl_vtpminfo vtpminfo; + int nb, i; + + if ((opt = def_getopt(argc, argv, "", "vtpm-list", 1)) != -1) + return opt; + + /* Idx BE UUID Hdl Sta evch rref BE-path */ + printf("%-3s %-2s %-36s %-6s %-5s %-6s %-5s %-10s\n", + "Idx", "BE", "Uuid", "handle", "state", "evt-ch", "ring-ref", "BE-path"); + for (argv += optind, argc -= optind; argc > 0; --argc, ++argv) { + uint32_t domid; + if (domain_qualifier_to_domid(*argv, &domid, 0) < 0) { + fprintf(stderr, "%s is an invalid domain identifier\n", *argv); + continue; + } + if (!(vtpms = libxl_device_vtpm_list(ctx, domid, &nb))) { + continue; + } + for (i = 0; i < nb; ++i) { + if(!libxl_device_vtpm_getinfo(ctx, domid, &vtpms[i], &vtpminfo)) { + /* Idx BE UUID Hdl Sta evch rref BE-path*/ + printf("%-3d %-2d " LIBXL_UUID_FMT " %6d %5d %6d %8d %-30s\n", + vtpminfo.devid, vtpminfo.backend_id, + LIBXL_UUID_BYTES(vtpminfo.uuid), + vtpminfo.devid, vtpminfo.state, vtpminfo.evtch, + vtpminfo.rref, vtpminfo.backend); + + libxl_vtpminfo_dispose(&vtpminfo); + } + libxl_device_vtpm_dispose(&vtpms[i]); + } + free(vtpms); + } + return 0; +} + +int main_vtpmdetach(int argc, char **argv) +{ + uint32_t domid; + int opt, rc=0; + libxl_device_vtpm vtpm; + libxl_uuid uuid; + + if ((opt = def_getopt(argc, argv, "", "vtpm-detach", 2)) != -1) + return opt; + + domid = find_domain(argv[optind]); + + if ( libxl_uuid_from_string(&uuid, argv[optind+1])) { + if (libxl_devid_to_device_vtpm(ctx, domid, atoi(argv[optind+1]), &vtpm)) { + fprintf(stderr, "Unknown device %s.\n", argv[optind+1]); + return 1; + } + } else { + if (libxl_uuid_to_device_vtpm(ctx, domid, &uuid, &vtpm)) { + fprintf(stderr, "Unknown device %s.\n", argv[optind+1]); + return 1; + } + } + rc = libxl_device_vtpm_remove(ctx, domid, &vtpm, 0); + if (rc) { + fprintf(stderr, "libxl_device_vtpm_remove failed.\n"); + } + libxl_device_vtpm_dispose(&vtpm); + return rc; +} + + static char *uptime_to_string(unsigned long uptime, int short_mode) { int sec, min, hour, day; diff --git a/tools/libxl/xl_cmdtable.c b/tools/libxl/xl_cmdtable.c index 85ea768..7c018eb 100644 --- a/tools/libxl/xl_cmdtable.c +++ b/tools/libxl/xl_cmdtable.c @@ -338,6 +338,21 @@ struct cmd_spec cmd_table[] = { "Destroy a domain's virtual block device", " ", }, + { "vtpm-attach", + &main_vtpmattach, 0, 1, + "Create a new virtual TPM device", + " [uuid=] [backend=]", + }, + { "vtpm-list", + &main_vtpmlist, 0, 0, + "List virtual TPM devices for a domain", + "", + }, + { "vtpm-detach", + &main_vtpmdetach, 0, 1, + "Destroy a domain's virtual TPM device", + " ", + }, { "uptime", &main_uptime, 0, 0, "Print uptime for all/some domains", -- 1.7.4.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 18:03:57 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 18:03:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCFc-0003Vm-0c; Fri, 05 Oct 2012 18:03:52 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCFb-0003VI-3j for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 18:03:51 +0000 Received: from [85.158.138.51:29603] by server-13.bemta-3.messagelabs.com id 49/E7-28885-6012F605; Fri, 05 Oct 2012 18:03:50 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-16.tower-174.messagelabs.com!1349460227!33187631!1 X-Originating-IP: [128.244.251.36] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4994 invoked from network); 5 Oct 2012 18:03:48 -0000 Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36) by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 18:03:48 -0000 Received: from ([128.244.207.89]) by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.154408453; Fri, 05 Oct 2012 14:03:28 -0400 Message-ID: <506F209E.2040902@jhuapl.edu> Date: Fri, 05 Oct 2012 14:02:06 -0400 From: Matthew Fioravante User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Samuel Thibault , "xen-devel@lists.xensource.com" References: <50579C5F.5040004@jhuapl.edu> <20120917224619.GO5110@type.youpi.perso.aquilenet.fr> In-Reply-To: <20120917224619.GO5110@type.youpi.perso.aquilenet.fr> X-Enigmail-Version: 1.4.4 Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 2/8] add posix io to blkfront X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6077436773460114346==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a cryptographically signed message in MIME format. --===============6077436773460114346== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020907020505030200070201" This is a cryptographically signed message in MIME format. --------------ms020907020505030200070201 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 09/17/2012 06:46 PM, Samuel Thibault wrote: > Matthew Fioravante, le Mon 17 Sep 2012 17:55:43 -0400, a =E9crit : >> + /* Read mode checks */ >> + else >> + { >> + /*If the requested read is bigger than the disk, just >> + * read as much as we can until the end */ >> + if(offset + count > disksize) { >> + count =3D offset >=3D disksize ? 0 : disksize - offset; >> + } >> + } > Perhaps return 0 here already instead of just setting count to 0? I agree > >> + >> + /* Setup aiocb block object */ >> + aiocb.aio_dev =3D dev; >> + aiocb.aio_nbytes =3D blocksize; >> + aiocb.aio_offset =3D blknum * blocksize; >> + aiocb.aio_cb =3D NULL; >> + aiocb.data =3D NULL; >> + >> + /* If our buffer is unaligned or its aligned but we will need to r= w >> a partial block >> + * then a copy will have to be done */ >> + if(!alignedbuf || blkoff !=3D 0 || count % blocksize !=3D 0) { >> + copybuf =3D _xmalloc(blocksize, dev->info.sector_size); >> + } >> + >> + rc =3D count; >> + while(count > 0) { >> + /* determine how many bytes to read/write from/to the current >> block buffer */ >> + bytes =3D count > (blocksize - blkoff) ? blocksize - blkoff : c= ount; > Mmm. Optimizing the non-aligned case would make the code > tricky, but shouldn't optimizing the aligned case at least > a little bit not too hard? i.e. set bytes to max(count, > BLKIF_MAX_SEGMENTS_PER_REQUEST*PAGE_SIZE); in the optimized case? That'= d > get much better 44KiB transfers instead of one sector at a time. > > Ideally we should even push a series of aio requests, but that's a lot > less easy since you need to know how many requests you can afford. See latest v2 patch > Apart from that, > > Acked-by: Samuel Thibault --------------ms020907020505030200070201 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4 NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50 ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz 4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTEyMTAwNTE4MDIwNlowIwYJKoZIhvcNAQkEMRYEFDAH2yz5joLU0UTm Ppd4sCL4SYzqMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBzf6qSlqC+7ZktUK2rPiKz2ejydH94RSGS U/Th4APLLx/M6wreMqlqLc0qiWsplo4Pikb32ms45Tu17EHiCUjoDmReZaBudTrGH52wfEsq bNu/5kEPYAZRbpLzFIbtd0ONsdekrIiX2sOtEu19MZq1/3W07Rty9TiH8VI7A1LIlgAAAAAA AA== --------------ms020907020505030200070201-- --===============6077436773460114346== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6077436773460114346==-- From xen-devel-bounces@lists.xen.org Fri Oct 05 18:03:57 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 18:03:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCFc-0003Vm-0c; Fri, 05 Oct 2012 18:03:52 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCFb-0003VI-3j for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 18:03:51 +0000 Received: from [85.158.138.51:29603] by server-13.bemta-3.messagelabs.com id 49/E7-28885-6012F605; Fri, 05 Oct 2012 18:03:50 +0000 X-Env-Sender: matthew.fioravante@jhuapl.edu X-Msg-Ref: server-16.tower-174.messagelabs.com!1349460227!33187631!1 X-Originating-IP: [128.244.251.36] X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4994 invoked from network); 5 Oct 2012 18:03:48 -0000 Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36) by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 18:03:48 -0000 Received: from ([128.244.207.89]) by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.154408453; Fri, 05 Oct 2012 14:03:28 -0400 Message-ID: <506F209E.2040902@jhuapl.edu> Date: Fri, 05 Oct 2012 14:02:06 -0400 From: Matthew Fioravante User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Samuel Thibault , "xen-devel@lists.xensource.com" References: <50579C5F.5040004@jhuapl.edu> <20120917224619.GO5110@type.youpi.perso.aquilenet.fr> In-Reply-To: <20120917224619.GO5110@type.youpi.perso.aquilenet.fr> X-Enigmail-Version: 1.4.4 Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 2/8] add posix io to blkfront X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6077436773460114346==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a cryptographically signed message in MIME format. --===============6077436773460114346== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020907020505030200070201" This is a cryptographically signed message in MIME format. --------------ms020907020505030200070201 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 09/17/2012 06:46 PM, Samuel Thibault wrote: > Matthew Fioravante, le Mon 17 Sep 2012 17:55:43 -0400, a =E9crit : >> + /* Read mode checks */ >> + else >> + { >> + /*If the requested read is bigger than the disk, just >> + * read as much as we can until the end */ >> + if(offset + count > disksize) { >> + count =3D offset >=3D disksize ? 0 : disksize - offset; >> + } >> + } > Perhaps return 0 here already instead of just setting count to 0? I agree > >> + >> + /* Setup aiocb block object */ >> + aiocb.aio_dev =3D dev; >> + aiocb.aio_nbytes =3D blocksize; >> + aiocb.aio_offset =3D blknum * blocksize; >> + aiocb.aio_cb =3D NULL; >> + aiocb.data =3D NULL; >> + >> + /* If our buffer is unaligned or its aligned but we will need to r= w >> a partial block >> + * then a copy will have to be done */ >> + if(!alignedbuf || blkoff !=3D 0 || count % blocksize !=3D 0) { >> + copybuf =3D _xmalloc(blocksize, dev->info.sector_size); >> + } >> + >> + rc =3D count; >> + while(count > 0) { >> + /* determine how many bytes to read/write from/to the current >> block buffer */ >> + bytes =3D count > (blocksize - blkoff) ? blocksize - blkoff : c= ount; > Mmm. Optimizing the non-aligned case would make the code > tricky, but shouldn't optimizing the aligned case at least > a little bit not too hard? i.e. set bytes to max(count, > BLKIF_MAX_SEGMENTS_PER_REQUEST*PAGE_SIZE); in the optimized case? That'= d > get much better 44KiB transfers instead of one sector at a time. > > Ideally we should even push a series of aio requests, but that's a lot > less easy since you need to know how many requests you can afford. See latest v2 patch > Apart from that, > > Acked-by: Samuel Thibault --------------ms020907020505030200070201 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4 NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50 ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz 4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTEyMTAwNTE4MDIwNlowIwYJKoZIhvcNAQkEMRYEFDAH2yz5joLU0UTm Ppd4sCL4SYzqMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBzf6qSlqC+7ZktUK2rPiKz2ejydH94RSGS U/Th4APLLx/M6wreMqlqLc0qiWsplo4Pikb32ms45Tu17EHiCUjoDmReZaBudTrGH52wfEsq bNu/5kEPYAZRbpLzFIbtd0ONsdekrIiX2sOtEu19MZq1/3W07Rty9TiH8VI7A1LIlgAAAAAA AA== --------------ms020907020505030200070201-- --===============6077436773460114346== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6077436773460114346==-- From xen-devel-bounces@lists.xen.org Fri Oct 05 18:37:11 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 18:37:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKClX-0004Np-Qp; Fri, 05 Oct 2012 18:36:51 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with smtp (Exim 4.72) (envelope-from ) id 1TKClW-0004Nh-AK for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 18:36:50 +0000 X-Env-Sender: ehabkost@redhat.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1349462201!8803160!1 X-Originating-IP: [209.132.183.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTcwODY=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1849 invoked from network); 5 Oct 2012 18:36:42 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-4.tower-27.messagelabs.com with SMTP; 5 Oct 2012 18:36:42 -0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q95Ia9m5016528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Oct 2012 14:36:10 -0400 Received: from blackpad.lan.raisama.net (vpn1-7-193.gru2.redhat.com [10.97.7.193]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q95Ia6JZ003269; Fri, 5 Oct 2012 14:36:06 -0400 Received: by blackpad.lan.raisama.net (Postfix, from userid 500) id E256C203604; Fri, 5 Oct 2012 15:37:05 -0300 (BRT) From: Eduardo Habkost To: qemu-devel@nongnu.org Date: Fri, 5 Oct 2012 15:37:00 -0300 Message-Id: <1349462220-13742-1-git-send-email-ehabkost@redhat.com> X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 Cc: Peter Maydell , Evgeny Voevodin , Peter Crosthwaite , Max Filippov , "Edgar E. Iglesias" , Guan Xuetao , xen-devel@lists.xensource.com, Igor Mitsyanko , Magnus Damm , Alexander Graf , =?UTF-8?q?Herv=C3=A9=20Poussineau?= , Maksim Kozlov , Andrzej Zaborowski , Fabien Chouteau , Jan Kiszka , Paul Brook , Blue Swirl , Anthony Liguori , Michael Walle , qemu-ppc@nongnu.org, Dmitry Solodkiy , Aurelien Jarno Subject: [Xen-devel] [QEMU PATCH] create struct for machine initialization arguments X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This should help us to: - More easily add or remove machine initialization arguments without having to change every single machine init function; - More easily make mechanical changes involving the machine init functions in the future; - Let machine initialization forward the init arguments to other functions more easily. This change was half-mechanical process: first the struct was added with the local ram_size, boot_device, kernel_*, initrd_*, and cpu_model local variable initialization to all functions. Then the compiler helped me locate the local variables that are unused, so they could be removed. Signed-off-by: Eduardo Habkost --- hw/alpha_dp264.c | 12 ++-- hw/an5206.c | 8 +-- hw/axis_dev88.c | 9 +-- hw/boards.h | 16 +++-- hw/collie.c | 9 +-- hw/dummy_m68k.c | 8 +-- hw/exynos4_boards.c | 16 ++--- hw/gumstix.c | 11 +--- hw/highbank.c | 10 ++-- hw/integratorcp.c | 10 ++-- hw/kzm.c | 10 ++-- hw/leon3.c | 10 ++-- hw/lm32_boards.c | 18 +++--- hw/mainstone.c | 10 ++-- hw/mcf5208.c | 8 +-- hw/milkymist.c | 10 ++-- hw/mips_fulong2e.c | 9 ++- hw/mips_jazz.c | 14 ++--- hw/mips_malta.c | 10 ++-- hw/mips_mipssim.c | 10 ++-- hw/mips_r4k.c | 10 ++-- hw/musicpal.c | 9 +-- hw/nseries.c | 22 ++++--- hw/null-machine.c | 7 +-- hw/omap_sx1.c | 22 ++++--- hw/openrisc_sim.c | 10 ++-- hw/palm.c | 9 +-- hw/pc_piix.c | 42 +++++++------ hw/petalogix_ml605_mmu.c | 8 +-- hw/petalogix_s3adsp1800_mmu.c | 8 +-- hw/ppc/e500plat.c | 13 +++-- hw/ppc/mpc8544ds.c | 13 +++-- hw/ppc405_boards.c | 25 ++++---- hw/ppc440_bamboo.c | 12 ++-- hw/ppc_newworld.c | 13 +++-- hw/ppc_oldworld.c | 13 +++-- hw/ppc_prep.c | 13 +++-- hw/puv3.c | 8 ++- hw/r2d.c | 9 +-- hw/realview.c | 44 +++++++++----- hw/s390-virtio.c | 13 +++-- hw/shix.c | 6 +- hw/spapr.c | 13 +++-- hw/spitz.c | 40 ++++++++----- hw/stellaris.c | 14 ++--- hw/sun4m.c | 133 ++++++++++++++++++++++++++---------------- hw/sun4u.c | 39 ++++++++----- hw/tosa.c | 9 +-- hw/versatilepb.c | 22 ++++--- hw/vexpress.c | 26 +++++---- hw/virtex_ml507.c | 10 ++-- hw/xen_machine_pv.c | 13 +++-- hw/xilinx_zynq.c | 9 ++- hw/xtensa_lx60.c | 22 ++++--- hw/xtensa_sim.c | 11 ++-- hw/z2.c | 9 +-- vl.c | 9 ++- 57 files changed, 520 insertions(+), 406 deletions(-) diff --git a/hw/alpha_dp264.c b/hw/alpha_dp264.c index 9eb939f..2c2e237 100644 --- a/hw/alpha_dp264.c +++ b/hw/alpha_dp264.c @@ -42,13 +42,13 @@ static int clipper_pci_map_irq(PCIDevice *d, int irq_num) return (slot + 1) * 4 + irq_num; } -static void clipper_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void clipper_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; CPUAlphaState *cpus[4]; PCIBus *pci_bus; ISABus *isa_bus; diff --git a/hw/an5206.c b/hw/an5206.c index 25407c0..042c5fc 100644 --- a/hw/an5206.c +++ b/hw/an5206.c @@ -19,11 +19,11 @@ /* Board init. */ -static void an5206_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void an5206_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; CPUM68KState *env; int kernel_size; uint64_t elf_entry; diff --git a/hw/axis_dev88.c b/hw/axis_dev88.c index eab6327..2fd7356 100644 --- a/hw/axis_dev88.c +++ b/hw/axis_dev88.c @@ -242,11 +242,12 @@ static const MemoryRegionOps gpio_ops = { static struct cris_load_info li; static -void axisdev88_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +void axisdev88_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; CRISCPU *cpu; CPUCRISState *env; DeviceState *dev; diff --git a/hw/boards.h b/hw/boards.h index a2e0a54..813d0e5 100644 --- a/hw/boards.h +++ b/hw/boards.h @@ -5,12 +5,16 @@ #include "qdev.h" -typedef void QEMUMachineInitFunc(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model); +typedef struct QEMUMachineInitArgs { + ram_addr_t ram_size; + const char *boot_device; + const char *kernel_filename; + const char *kernel_cmdline; + const char *initrd_filename; + const char *cpu_model; +} QEMUMachineInitArgs; + +typedef void QEMUMachineInitFunc(QEMUMachineInitArgs *args); typedef void QEMUMachineResetFunc(void); diff --git a/hw/collie.c b/hw/collie.c index 56f89a9..695982a 100644 --- a/hw/collie.c +++ b/hw/collie.c @@ -23,11 +23,12 @@ static struct arm_boot_info collie_binfo = { .ram_size = 0x20000000, }; -static void collie_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void collie_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; StrongARMState *s; DriveInfo *dinfo; MemoryRegion *sysmem = get_system_memory(); diff --git a/hw/dummy_m68k.c b/hw/dummy_m68k.c index 7cc7a99..f436a0c 100644 --- a/hw/dummy_m68k.c +++ b/hw/dummy_m68k.c @@ -16,11 +16,11 @@ /* Board init. */ -static void dummy_m68k_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void dummy_m68k_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; CPUM68KState *env; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *ram = g_new(MemoryRegion, 1); diff --git a/hw/exynos4_boards.c b/hw/exynos4_boards.c index 4bb0a60..4951064 100644 --- a/hw/exynos4_boards.c +++ b/hw/exynos4_boards.c @@ -130,22 +130,22 @@ static Exynos4210State *exynos4_boards_init_common( exynos4_board_ram_size[board_type]); } -static void nuri_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void nuri_init(QEMUMachineInitArgs *args) { + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; exynos4_boards_init_common(kernel_filename, kernel_cmdline, initrd_filename, EXYNOS4_BOARD_NURI); arm_load_kernel(arm_env_get_cpu(first_cpu), &exynos4_board_binfo); } -static void smdkc210_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void smdkc210_init(QEMUMachineInitArgs *args) { + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; Exynos4210State *s = exynos4_boards_init_common(kernel_filename, kernel_cmdline, initrd_filename, EXYNOS4_BOARD_SMDKC210); diff --git a/hw/gumstix.c b/hw/gumstix.c index 13a36ea..4103a88 100644 --- a/hw/gumstix.c +++ b/hw/gumstix.c @@ -45,10 +45,7 @@ static const int sector_len = 128 * 1024; -static void connex_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void connex_init(QEMUMachineInitArgs *args) { PXA2xxState *cpu; DriveInfo *dinfo; @@ -84,11 +81,9 @@ static void connex_init(ram_addr_t ram_size, qdev_get_gpio_in(cpu->gpio, 36)); } -static void verdex_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void verdex_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; PXA2xxState *cpu; DriveInfo *dinfo; int be; diff --git a/hw/highbank.c b/hw/highbank.c index 11aa131..15036b6 100644 --- a/hw/highbank.c +++ b/hw/highbank.c @@ -187,11 +187,13 @@ static struct arm_boot_info highbank_binfo; * 32-bit host, set the reg value of memory to 0xf7ff00000 in the * device tree and pass -m 2047 to QEMU. */ -static void highbank_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void highbank_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; DeviceState *dev; SysBusDevice *busdev; qemu_irq *irqp; diff --git a/hw/integratorcp.c b/hw/integratorcp.c index d0e2e90..ac0ea83 100644 --- a/hw/integratorcp.c +++ b/hw/integratorcp.c @@ -438,11 +438,13 @@ static struct arm_boot_info integrator_binfo = { .board_id = 0x113, }; -static void integratorcp_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void integratorcp_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; ARMCPU *cpu; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *ram = g_new(MemoryRegion, 1); diff --git a/hw/kzm.c b/hw/kzm.c index 68cd1b4..d1266d9 100644 --- a/hw/kzm.c +++ b/hw/kzm.c @@ -70,11 +70,13 @@ static struct arm_boot_info kzm_binfo = { .board_id = 1722, }; -static void kzm_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void kzm_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; ARMCPU *cpu; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *ram = g_new(MemoryRegion, 1); diff --git a/hw/leon3.c b/hw/leon3.c index 878d3aa..6486b7b 100644 --- a/hw/leon3.c +++ b/hw/leon3.c @@ -94,13 +94,11 @@ static void leon3_set_pil_in(void *opaque, uint32_t pil_in) } } -static void leon3_generic_hw_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void leon3_generic_hw_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; SPARCCPU *cpu; CPUSPARCState *env; MemoryRegion *address_space_mem = get_system_memory(); diff --git a/hw/lm32_boards.c b/hw/lm32_boards.c index b76d800..c5a62c8 100644 --- a/hw/lm32_boards.c +++ b/hw/lm32_boards.c @@ -69,12 +69,10 @@ static void main_cpu_reset(void *opaque) env->deba = reset_info->flash_base; } -static void lm32_evr_init(ram_addr_t ram_size_not_used, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void lm32_evr_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; LM32CPU *cpu; CPULM32State *env; DriveInfo *dinfo; @@ -159,12 +157,12 @@ static void lm32_evr_init(ram_addr_t ram_size_not_used, qemu_register_reset(main_cpu_reset, reset_info); } -static void lm32_uclinux_init(ram_addr_t ram_size_not_used, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void lm32_uclinux_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; LM32CPU *cpu; CPULM32State *env; DriveInfo *dinfo; diff --git a/hw/mainstone.c b/hw/mainstone.c index 97687b6..c0d6034 100644 --- a/hw/mainstone.c +++ b/hw/mainstone.c @@ -171,11 +171,13 @@ static void mainstone_common_init(MemoryRegion *address_space_mem, arm_load_kernel(mpu->cpu, &mainstone_binfo); } -static void mainstone_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void mainstone_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; mainstone_common_init(get_system_memory(), ram_size, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, mainstone, 0x196); } diff --git a/hw/mcf5208.c b/hw/mcf5208.c index ee25b1b..688bc3c 100644 --- a/hw/mcf5208.c +++ b/hw/mcf5208.c @@ -187,11 +187,11 @@ static void mcf5208_sys_init(MemoryRegion *address_space, qemu_irq *pic) } } -static void mcf5208evb_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void mcf5208evb_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; CPUM68KState *env; int kernel_size; uint64_t elf_entry; diff --git a/hw/milkymist.c b/hw/milkymist.c index 2e7235b..ca9ed43 100644 --- a/hw/milkymist.c +++ b/hw/milkymist.c @@ -73,12 +73,12 @@ static void main_cpu_reset(void *opaque) } static void -milkymist_init(ram_addr_t ram_size_not_used, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +milkymist_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; LM32CPU *cpu; CPULM32State *env; int kernel_size; diff --git a/hw/mips_fulong2e.c b/hw/mips_fulong2e.c index 38e4b86..af7bb50 100644 --- a/hw/mips_fulong2e.c +++ b/hw/mips_fulong2e.c @@ -256,10 +256,13 @@ static void cpu_request_exit(void *opaque, int irq, int level) } } -static void mips_fulong2e_init(ram_addr_t ram_size, const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void mips_fulong2e_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; char *filename; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *ram = g_new(MemoryRegion, 1); diff --git a/hw/mips_jazz.c b/hw/mips_jazz.c index db927f1..14df4d7 100644 --- a/hw/mips_jazz.c +++ b/hw/mips_jazz.c @@ -302,21 +302,19 @@ static void mips_jazz_init(MemoryRegion *address_space, } static -void mips_magnum_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +void mips_magnum_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; mips_jazz_init(get_system_memory(), get_system_io(), ram_size, cpu_model, JAZZ_MAGNUM); } static -void mips_pica61_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +void mips_pica61_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; mips_jazz_init(get_system_memory(), get_system_io(), ram_size, cpu_model, JAZZ_PICA61); } diff --git a/hw/mips_malta.c b/hw/mips_malta.c index ad23f26..14151f9 100644 --- a/hw/mips_malta.c +++ b/hw/mips_malta.c @@ -777,11 +777,13 @@ static void cpu_request_exit(void *opaque, int irq, int level) } static -void mips_malta_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +void mips_malta_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; char *filename; pflash_t *fl; MemoryRegion *system_memory = get_system_memory(); diff --git a/hw/mips_mipssim.c b/hw/mips_mipssim.c index 830f635..a1d3945 100644 --- a/hw/mips_mipssim.c +++ b/hw/mips_mipssim.c @@ -131,11 +131,13 @@ static void mipsnet_init(int base, qemu_irq irq, NICInfo *nd) } static void -mips_mipssim_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +mips_mipssim_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; char *filename; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *ram = g_new(MemoryRegion, 1); diff --git a/hw/mips_r4k.c b/hw/mips_r4k.c index 967a76e..b73cdc3 100644 --- a/hw/mips_r4k.c +++ b/hw/mips_r4k.c @@ -151,11 +151,13 @@ static void main_cpu_reset(void *opaque) static const int sector_len = 32 * 1024; static -void mips_r4k_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +void mips_r4k_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; char *filename; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *ram = g_new(MemoryRegion, 1); diff --git a/hw/musicpal.c b/hw/musicpal.c index f305e21..f06814c 100644 --- a/hw/musicpal.c +++ b/hw/musicpal.c @@ -1508,11 +1508,12 @@ static struct arm_boot_info musicpal_binfo = { .board_id = 0x20e, }; -static void musicpal_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void musicpal_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; ARMCPU *cpu; qemu_irq *cpu_pic; qemu_irq pic[32]; diff --git a/hw/nseries.c b/hw/nseries.c index 6df71eb..7ada90d 100644 --- a/hw/nseries.c +++ b/hw/nseries.c @@ -1397,21 +1397,27 @@ static struct arm_boot_info n810_binfo = { .atag_board = n810_atag_setup, }; -static void n800_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void n800_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; return n8x0_init(ram_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, &n800_binfo, 800); } -static void n810_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void n810_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; return n8x0_init(ram_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, &n810_binfo, 810); diff --git a/hw/null-machine.c b/hw/null-machine.c index 69910d3..d813c08 100644 --- a/hw/null-machine.c +++ b/hw/null-machine.c @@ -15,12 +15,7 @@ #include "hw/hw.h" #include "hw/boards.h" -static void machine_none_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void machine_none_init(QEMUMachineInitArgs *args) { } diff --git a/hw/omap_sx1.c b/hw/omap_sx1.c index abca341..ad17487 100644 --- a/hw/omap_sx1.c +++ b/hw/omap_sx1.c @@ -209,20 +209,26 @@ static void sx1_init(ram_addr_t ram_size, //~ qemu_console_resize(ds, 640, 480); } -static void sx1_init_v1(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void sx1_init_v1(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sx1_init(ram_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, 1); } -static void sx1_init_v2(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void sx1_init_v2(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sx1_init(ram_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, 2); } diff --git a/hw/openrisc_sim.c b/hw/openrisc_sim.c index 55e97f0..e96a944 100644 --- a/hw/openrisc_sim.c +++ b/hw/openrisc_sim.c @@ -90,13 +90,11 @@ static void cpu_openrisc_load_kernel(ram_addr_t ram_size, cpu->env.pc = entry; } -static void openrisc_sim_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void openrisc_sim_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; OpenRISCCPU *cpu = NULL; MemoryRegion *ram; int n; diff --git a/hw/palm.c b/hw/palm.c index bacdc90..032b8d6 100644 --- a/hw/palm.c +++ b/hw/palm.c @@ -190,11 +190,12 @@ static struct arm_boot_info palmte_binfo = { .board_id = 0x331, }; -static void palmte_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void palmte_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; MemoryRegion *address_space_mem = get_system_memory(); struct omap_mpu_state_s *mpu; int flash_size = 0x00800000; diff --git a/hw/pc_piix.c b/hw/pc_piix.c index fd5898f..9efc822 100644 --- a/hw/pc_piix.c +++ b/hw/pc_piix.c @@ -287,13 +287,14 @@ static void pc_init1(MemoryRegion *system_memory, } } -static void pc_init_pci(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void pc_init_pci(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; pc_init1(get_system_memory(), get_system_io(), ram_size, boot_device, @@ -301,13 +302,14 @@ static void pc_init_pci(ram_addr_t ram_size, initrd_filename, cpu_model, 1, 1); } -static void pc_init_pci_no_kvmclock(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void pc_init_pci_no_kvmclock(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; pc_init1(get_system_memory(), get_system_io(), ram_size, boot_device, @@ -315,13 +317,14 @@ static void pc_init_pci_no_kvmclock(ram_addr_t ram_size, initrd_filename, cpu_model, 1, 0); } -static void pc_init_isa(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void pc_init_isa(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; if (cpu_model == NULL) cpu_model = "486"; pc_init1(get_system_memory(), @@ -332,7 +335,8 @@ static void pc_init_isa(ram_addr_t ram_size, } #ifdef CONFIG_XEN -static void pc_xen_hvm_init(ram_addr_t ram_size, +static void pc_xen_hvm_init(QEMUMachine *machine, + ram_addr_t ram_size, const char *boot_device, const char *kernel_filename, const char *kernel_cmdline, diff --git a/hw/petalogix_ml605_mmu.c b/hw/petalogix_ml605_mmu.c index dced648..ace0187 100644 --- a/hw/petalogix_ml605_mmu.c +++ b/hw/petalogix_ml605_mmu.c @@ -70,12 +70,10 @@ static void machine_cpu_reset(MicroBlazeCPU *cpu) } static void -petalogix_ml605_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +petalogix_ml605_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; MemoryRegion *address_space_mem = get_system_memory(); DeviceState *dev, *dma, *eth0; MicroBlazeCPU *cpu; diff --git a/hw/petalogix_s3adsp1800_mmu.c b/hw/petalogix_s3adsp1800_mmu.c index 2cf6882..71c32ce 100644 --- a/hw/petalogix_s3adsp1800_mmu.c +++ b/hw/petalogix_s3adsp1800_mmu.c @@ -57,12 +57,10 @@ static void machine_cpu_reset(MicroBlazeCPU *cpu) } static void -petalogix_s3adsp1800_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +petalogix_s3adsp1800_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; DeviceState *dev; MicroBlazeCPU *cpu; CPUMBState *env; diff --git a/hw/ppc/e500plat.c b/hw/ppc/e500plat.c index 60a5cb3..4cfb940 100644 --- a/hw/ppc/e500plat.c +++ b/hw/ppc/e500plat.c @@ -25,13 +25,14 @@ static void e500plat_fixup_devtree(PPCE500Params *params, void *fdt) sizeof(compatible)); } -static void e500plat_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void e500plat_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *boot_device = args->boot_device; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; PPCE500Params params = { .ram_size = ram_size, .boot_device = boot_device, diff --git a/hw/ppc/mpc8544ds.c b/hw/ppc/mpc8544ds.c index 984d21c..e651661 100644 --- a/hw/ppc/mpc8544ds.c +++ b/hw/ppc/mpc8544ds.c @@ -25,13 +25,14 @@ static void mpc8544ds_fixup_devtree(PPCE500Params *params, void *fdt) sizeof(compatible)); } -static void mpc8544ds_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void mpc8544ds_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *boot_device = args->boot_device; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; PPCE500Params params = { .ram_size = ram_size, .boot_device = boot_device, diff --git a/hw/ppc405_boards.c b/hw/ppc405_boards.c index 476775d..e848cb0 100644 --- a/hw/ppc405_boards.c +++ b/hw/ppc405_boards.c @@ -158,7 +158,7 @@ static void ref405ep_fpga_reset (void *opaque) fpga->reg1 = 0x0F; } -static void ref405ep_fpga_init (MemoryRegion *sysmem, uint32_t base) +static void ref405ep_fpga_init(MemoryRegion *sysmem, uint32_t base) { ref405ep_fpga_t *fpga; MemoryRegion *fpga_memory = g_new(MemoryRegion, 1); @@ -170,13 +170,12 @@ static void ref405ep_fpga_init (MemoryRegion *sysmem, uint32_t base) qemu_register_reset(&ref405ep_fpga_reset, fpga); } -static void ref405ep_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void ref405ep_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; char *filename; ppc4xx_bd_info_t bd; CPUPPCState *env; @@ -484,7 +483,7 @@ static void taihu_cpld_reset (void *opaque) cpld->reg1 = 0x80; } -static void taihu_cpld_init (MemoryRegion *sysmem, uint32_t base) +static void taihu_cpld_init(MemoryRegion *sysmem, uint32_t base) { taihu_cpld_t *cpld; MemoryRegion *cpld_memory = g_new(MemoryRegion, 1); @@ -495,13 +494,11 @@ static void taihu_cpld_init (MemoryRegion *sysmem, uint32_t base) qemu_register_reset(&taihu_cpld_reset, cpld); } -static void taihu_405ep_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void taihu_405ep_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *kernel_filename = args->kernel_filename; + const char *initrd_filename = args->initrd_filename; char *filename; qemu_irq *pic; MemoryRegion *sysmem = get_system_memory(); diff --git a/hw/ppc440_bamboo.c b/hw/ppc440_bamboo.c index c198071..78e7985 100644 --- a/hw/ppc440_bamboo.c +++ b/hw/ppc440_bamboo.c @@ -157,13 +157,13 @@ static void main_cpu_reset(void *opaque) mmubooke_create_initial_mapping(env, 0, 0); } -static void bamboo_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void bamboo_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; unsigned int pci_irq_nrs[4] = { 28, 27, 26, 25 }; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *ram_memories diff --git a/hw/ppc_newworld.c b/hw/ppc_newworld.c index e95cfe8..e7c0747 100644 --- a/hw/ppc_newworld.c +++ b/hw/ppc_newworld.c @@ -129,13 +129,14 @@ static void ppc_core99_reset(void *opaque) } /* PowerPC Mac99 hardware initialisation */ -static void ppc_core99_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void ppc_core99_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; PowerPCCPU *cpu = NULL; CPUPPCState *env = NULL; char *filename; diff --git a/hw/ppc_oldworld.c b/hw/ppc_oldworld.c index 1dcd8a6..d9f76a8 100644 --- a/hw/ppc_oldworld.c +++ b/hw/ppc_oldworld.c @@ -72,13 +72,14 @@ static void ppc_heathrow_reset(void *opaque) cpu_reset(CPU(cpu)); } -static void ppc_heathrow_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void ppc_heathrow_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; MemoryRegion *sysmem = get_system_memory(); PowerPCCPU *cpu = NULL; CPUPPCState *env = NULL; diff --git a/hw/ppc_prep.c b/hw/ppc_prep.c index 592b7b2..f51f78a 100644 --- a/hw/ppc_prep.c +++ b/hw/ppc_prep.c @@ -448,13 +448,14 @@ static void ppc_prep_reset(void *opaque) } /* PowerPC PREP hardware initialisation */ -static void ppc_prep_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void ppc_prep_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; MemoryRegion *sysmem = get_system_memory(); PowerPCCPU *cpu = NULL; CPUPPCState *env = NULL; diff --git a/hw/puv3.c b/hw/puv3.c index 43f7216..764799c 100644 --- a/hw/puv3.c +++ b/hw/puv3.c @@ -91,10 +91,12 @@ static void puv3_load_kernel(const char *kernel_filename) graphic_console_init(NULL, NULL, NULL, NULL, NULL); } -static void puv3_init(ram_addr_t ram_size, const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void puv3_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *initrd_filename = args->initrd_filename; CPUUniCore32State *env; if (initrd_filename) { diff --git a/hw/r2d.c b/hw/r2d.c index 0f16e81..5daa42f 100644 --- a/hw/r2d.c +++ b/hw/r2d.c @@ -219,11 +219,12 @@ static struct QEMU_PACKED char kernel_cmdline[256]; } boot_params; -static void r2d_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void r2d_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; SuperHCPU *cpu; CPUSH4State *env; ResetData *reset_info; diff --git a/hw/realview.c b/hw/realview.c index 19db4d0..8dc4be6 100644 --- a/hw/realview.c +++ b/hw/realview.c @@ -330,11 +330,14 @@ static void realview_init(ram_addr_t ram_size, arm_load_kernel(arm_env_get_cpu(first_cpu), &realview_binfo); } -static void realview_eb_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void realview_eb_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; if (!cpu_model) { cpu_model = "arm926"; } @@ -342,11 +345,14 @@ static void realview_eb_init(ram_addr_t ram_size, initrd_filename, cpu_model, BOARD_EB); } -static void realview_eb_mpcore_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void realview_eb_mpcore_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; if (!cpu_model) { cpu_model = "arm11mpcore"; } @@ -354,11 +360,14 @@ static void realview_eb_mpcore_init(ram_addr_t ram_size, initrd_filename, cpu_model, BOARD_EB_MPCORE); } -static void realview_pb_a8_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void realview_pb_a8_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; if (!cpu_model) { cpu_model = "cortex-a8"; } @@ -366,11 +375,14 @@ static void realview_pb_a8_init(ram_addr_t ram_size, initrd_filename, cpu_model, BOARD_PB_A8); } -static void realview_pbx_a9_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void realview_pbx_a9_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; if (!cpu_model) { cpu_model = "cortex-a9"; } diff --git a/hw/s390-virtio.c b/hw/s390-virtio.c index 47eed35..39ff178 100644 --- a/hw/s390-virtio.c +++ b/hw/s390-virtio.c @@ -151,13 +151,14 @@ unsigned s390_del_running_cpu(CPUS390XState *env) } /* PC hardware initialisation */ -static void s390_init(ram_addr_t my_ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void s390_init(QEMUMachineInitArgs *args) { + ram_addr_t my_ram_size = args->ram_size; + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; CPUS390XState *env = NULL; MemoryRegion *sysmem = get_system_memory(); MemoryRegion *ram = g_new(MemoryRegion, 1); diff --git a/hw/shix.c b/hw/shix.c index dd9ce17..b56dd54 100644 --- a/hw/shix.c +++ b/hw/shix.c @@ -37,11 +37,9 @@ #define BIOS_FILENAME "shix_bios.bin" #define BIOS_ADDRESS 0xA0000000 -static void shix_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void shix_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; int ret; CPUSH4State *env; struct SH7750State *s; diff --git a/hw/spapr.c b/hw/spapr.c index c34b767..8921c4d 100644 --- a/hw/spapr.c +++ b/hw/spapr.c @@ -603,13 +603,14 @@ static int spapr_vga_init(PCIBus *pci_bus) } /* pSeries LPAR / sPAPR hardware init */ -static void ppc_spapr_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void ppc_spapr_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; PowerPCCPU *cpu; CPUPPCState *env; PCIHostState *phb; diff --git a/hw/spitz.c b/hw/spitz.c index 20e7835..df829b3 100644 --- a/hw/spitz.c +++ b/hw/spitz.c @@ -936,38 +936,46 @@ static void spitz_common_init(ram_addr_t ram_size, sl_bootparam_write(SL_PXA_PARAM_BASE); } -static void spitz_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void spitz_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; spitz_common_init(ram_size, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, spitz, 0x2c9); } -static void borzoi_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void borzoi_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; spitz_common_init(ram_size, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, borzoi, 0x33f); } -static void akita_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void akita_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; spitz_common_init(ram_size, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, akita, 0x2e8); } -static void terrier_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void terrier_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; spitz_common_init(ram_size, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, terrier, 0x33f); } diff --git a/hw/stellaris.c b/hw/stellaris.c index 562fbbf..b79c7fb 100644 --- a/hw/stellaris.c +++ b/hw/stellaris.c @@ -1358,19 +1358,17 @@ static void stellaris_init(const char *kernel_filename, const char *cpu_model, } /* FIXME: Figure out how to generate these from stellaris_boards. */ -static void lm3s811evb_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void lm3s811evb_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; stellaris_init(kernel_filename, cpu_model, &stellaris_boards[0]); } -static void lm3s6965evb_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void lm3s6965evb_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; stellaris_init(kernel_filename, cpu_model, &stellaris_boards[1]); } diff --git a/hw/sun4m.c b/hw/sun4m.c index c98cd5e..22e011f 100644 --- a/hw/sun4m.c +++ b/hw/sun4m.c @@ -1303,92 +1303,118 @@ static const struct sun4m_hwdef sun4m_hwdefs[] = { }; /* SPARCstation 5 hardware initialisation */ -static void ss5_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss5_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[0], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCstation 10 hardware initialisation */ -static void ss10_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss10_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[1], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCserver 600MP hardware initialisation */ -static void ss600mp_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss600mp_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[2], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCstation 20 hardware initialisation */ -static void ss20_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss20_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[3], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCstation Voyager hardware initialisation */ -static void vger_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void vger_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[4], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCstation LX hardware initialisation */ -static void ss_lx_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss_lx_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[5], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCstation 4 hardware initialisation */ -static void ss4_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss4_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[6], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCClassic hardware initialisation */ -static void scls_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void scls_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[7], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCbook hardware initialisation */ -static void sbook_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void sbook_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[8], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } @@ -1651,21 +1677,27 @@ static void sun4d_hw_init(const struct sun4d_hwdef *hwdef, ram_addr_t RAM_size, } /* SPARCserver 1000 hardware initialisation */ -static void ss1000_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss1000_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4d_hw_init(&sun4d_hwdefs[0], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCcenter 2000 hardware initialisation */ -static void ss2000_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss2000_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4d_hw_init(&sun4d_hwdefs[1], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } @@ -1845,11 +1877,14 @@ static void sun4c_hw_init(const struct sun4c_hwdef *hwdef, ram_addr_t RAM_size, } /* SPARCstation 2 hardware initialisation */ -static void ss2_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss2_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4c_hw_init(&sun4c_hwdefs[0], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } diff --git a/hw/sun4u.c b/hw/sun4u.c index 07cd042..379768c 100644 --- a/hw/sun4u.c +++ b/hw/sun4u.c @@ -930,31 +930,40 @@ static const struct hwdef hwdefs[] = { }; /* Sun4u hardware initialisation */ -static void sun4u_init(ram_addr_t RAM_size, - const char *boot_devices, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) -{ +static void sun4u_init(QEMUMachineInitArgs *args) +{ + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_devices = args->boot_device; sun4uv_init(get_system_memory(), RAM_size, boot_devices, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, &hwdefs[0]); } /* Sun4v hardware initialisation */ -static void sun4v_init(ram_addr_t RAM_size, - const char *boot_devices, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) -{ +static void sun4v_init(QEMUMachineInitArgs *args) +{ + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_devices = args->boot_device; sun4uv_init(get_system_memory(), RAM_size, boot_devices, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, &hwdefs[1]); } /* Niagara hardware initialisation */ -static void niagara_init(ram_addr_t RAM_size, - const char *boot_devices, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) -{ +static void niagara_init(QEMUMachineInitArgs *args) +{ + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_devices = args->boot_device; sun4uv_init(get_system_memory(), RAM_size, boot_devices, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, &hwdefs[2]); } diff --git a/hw/tosa.c b/hw/tosa.c index 297a8c2..512278c 100644 --- a/hw/tosa.c +++ b/hw/tosa.c @@ -205,11 +205,12 @@ static struct arm_boot_info tosa_binfo = { .ram_size = 0x04000000, }; -static void tosa_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void tosa_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *rom = g_new(MemoryRegion, 1); PXA2xxState *mpu; diff --git a/hw/versatilepb.c b/hw/versatilepb.c index 7a92034..686dcc7 100644 --- a/hw/versatilepb.c +++ b/hw/versatilepb.c @@ -342,22 +342,28 @@ static void versatile_init(ram_addr_t ram_size, arm_load_kernel(cpu, &versatile_binfo); } -static void vpb_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void vpb_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; versatile_init(ram_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, 0x183); } -static void vab_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void vab_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; versatile_init(ram_size, boot_device, kernel_filename, kernel_cmdline, diff --git a/hw/vexpress.c b/hw/vexpress.c index 3596d1e..36503d6 100644 --- a/hw/vexpress.c +++ b/hw/vexpress.c @@ -467,25 +467,27 @@ static void vexpress_common_init(const VEDBoardInfo *daughterboard, arm_load_kernel(arm_env_get_cpu(first_cpu), &vexpress_binfo); } -static void vexpress_a9_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void vexpress_a9_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; vexpress_common_init(&a9_daughterboard, ram_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } -static void vexpress_a15_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void vexpress_a15_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; vexpress_common_init(&a15_daughterboard, ram_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); diff --git a/hw/virtex_ml507.c b/hw/virtex_ml507.c index 79bc0d1..a09b27a 100644 --- a/hw/virtex_ml507.c +++ b/hw/virtex_ml507.c @@ -183,12 +183,12 @@ static int xilinx_load_device_tree(target_phys_addr_t addr, return fdt_size; } -static void virtex_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void virtex_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; MemoryRegion *address_space_mem = get_system_memory(); DeviceState *dev; PowerPCCPU *cpu; diff --git a/hw/xen_machine_pv.c b/hw/xen_machine_pv.c index 4b72aa7..1ac9990 100644 --- a/hw/xen_machine_pv.c +++ b/hw/xen_machine_pv.c @@ -29,12 +29,13 @@ #include "xen_domainbuild.h" #include "blockdev.h" -static void xen_init_pv(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void xen_init_pv(QEMUMachine *machine, + ram_addr_t ram_size, + const char *boot_device, + const char *kernel_filename, + const char *kernel_cmdline, + const char *initrd_filename, + const char *cpu_model) { X86CPU *cpu; CPUX86State *env; diff --git a/hw/xilinx_zynq.c b/hw/xilinx_zynq.c index 7e6c273..83f322e 100644 --- a/hw/xilinx_zynq.c +++ b/hw/xilinx_zynq.c @@ -46,10 +46,13 @@ static void gem_init(NICInfo *nd, uint32_t base, qemu_irq irq) sysbus_connect_irq(s, 0, irq); } -static void zynq_init(ram_addr_t ram_size, const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void zynq_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; ARMCPU *cpu; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *ext_ram = g_new(MemoryRegion, 1); diff --git a/hw/xtensa_lx60.c b/hw/xtensa_lx60.c index 3653f65..1fd2c47 100644 --- a/hw/xtensa_lx60.c +++ b/hw/xtensa_lx60.c @@ -268,11 +268,14 @@ static void lx_init(const LxBoardDesc *board, } } -static void xtensa_lx60_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void xtensa_lx60_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; static const LxBoardDesc lx60_board = { .flash_size = 0x400000, .flash_sector_size = 0x10000, @@ -283,11 +286,14 @@ static void xtensa_lx60_init(ram_addr_t ram_size, initrd_filename, cpu_model); } -static void xtensa_lx200_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void xtensa_lx200_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; static const LxBoardDesc lx200_board = { .flash_size = 0x1000000, .flash_sector_size = 0x20000, diff --git a/hw/xtensa_sim.c b/hw/xtensa_sim.c index 831460b..2e846d8 100644 --- a/hw/xtensa_sim.c +++ b/hw/xtensa_sim.c @@ -96,11 +96,14 @@ static void sim_init(ram_addr_t ram_size, } } -static void xtensa_sim_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void xtensa_sim_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; if (!cpu_model) { cpu_model = XTENSA_DEFAULT_CPU_MODEL; } diff --git a/hw/z2.c b/hw/z2.c index 289cee9..0927bad 100644 --- a/hw/z2.c +++ b/hw/z2.c @@ -294,11 +294,12 @@ static TypeInfo aer915_info = { .class_init = aer915_class_init, }; -static void z2_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void z2_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; MemoryRegion *address_space_mem = get_system_memory(); uint32_t sector_len = 0x10000; PXA2xxState *mpu; diff --git a/vl.c b/vl.c index 8d305ca..f663e7c 100644 --- a/vl.c +++ b/vl.c @@ -3624,8 +3624,13 @@ int main(int argc, char **argv, char **envp) qdev_machine_init(); - machine->init(ram_size, boot_devices, - kernel_filename, kernel_cmdline, initrd_filename, cpu_model); + QEMUMachineInitArgs args = { .ram_size = ram_size, + .boot_device = boot_devices, + .kernel_filename = kernel_filename, + .kernel_cmdline = kernel_cmdline, + initrd_filename = initrd_filename, + .cpu_model = cpu_model }; + machine->init(&args); cpu_synchronize_all_post_init(); -- 1.7.11.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 18:37:11 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 18:37:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKClX-0004Np-Qp; Fri, 05 Oct 2012 18:36:51 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with smtp (Exim 4.72) (envelope-from ) id 1TKClW-0004Nh-AK for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 18:36:50 +0000 X-Env-Sender: ehabkost@redhat.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1349462201!8803160!1 X-Originating-IP: [209.132.183.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTcwODY=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1849 invoked from network); 5 Oct 2012 18:36:42 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-4.tower-27.messagelabs.com with SMTP; 5 Oct 2012 18:36:42 -0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q95Ia9m5016528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Oct 2012 14:36:10 -0400 Received: from blackpad.lan.raisama.net (vpn1-7-193.gru2.redhat.com [10.97.7.193]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q95Ia6JZ003269; Fri, 5 Oct 2012 14:36:06 -0400 Received: by blackpad.lan.raisama.net (Postfix, from userid 500) id E256C203604; Fri, 5 Oct 2012 15:37:05 -0300 (BRT) From: Eduardo Habkost To: qemu-devel@nongnu.org Date: Fri, 5 Oct 2012 15:37:00 -0300 Message-Id: <1349462220-13742-1-git-send-email-ehabkost@redhat.com> X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 Cc: Peter Maydell , Evgeny Voevodin , Peter Crosthwaite , Max Filippov , "Edgar E. Iglesias" , Guan Xuetao , xen-devel@lists.xensource.com, Igor Mitsyanko , Magnus Damm , Alexander Graf , =?UTF-8?q?Herv=C3=A9=20Poussineau?= , Maksim Kozlov , Andrzej Zaborowski , Fabien Chouteau , Jan Kiszka , Paul Brook , Blue Swirl , Anthony Liguori , Michael Walle , qemu-ppc@nongnu.org, Dmitry Solodkiy , Aurelien Jarno Subject: [Xen-devel] [QEMU PATCH] create struct for machine initialization arguments X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This should help us to: - More easily add or remove machine initialization arguments without having to change every single machine init function; - More easily make mechanical changes involving the machine init functions in the future; - Let machine initialization forward the init arguments to other functions more easily. This change was half-mechanical process: first the struct was added with the local ram_size, boot_device, kernel_*, initrd_*, and cpu_model local variable initialization to all functions. Then the compiler helped me locate the local variables that are unused, so they could be removed. Signed-off-by: Eduardo Habkost --- hw/alpha_dp264.c | 12 ++-- hw/an5206.c | 8 +-- hw/axis_dev88.c | 9 +-- hw/boards.h | 16 +++-- hw/collie.c | 9 +-- hw/dummy_m68k.c | 8 +-- hw/exynos4_boards.c | 16 ++--- hw/gumstix.c | 11 +--- hw/highbank.c | 10 ++-- hw/integratorcp.c | 10 ++-- hw/kzm.c | 10 ++-- hw/leon3.c | 10 ++-- hw/lm32_boards.c | 18 +++--- hw/mainstone.c | 10 ++-- hw/mcf5208.c | 8 +-- hw/milkymist.c | 10 ++-- hw/mips_fulong2e.c | 9 ++- hw/mips_jazz.c | 14 ++--- hw/mips_malta.c | 10 ++-- hw/mips_mipssim.c | 10 ++-- hw/mips_r4k.c | 10 ++-- hw/musicpal.c | 9 +-- hw/nseries.c | 22 ++++--- hw/null-machine.c | 7 +-- hw/omap_sx1.c | 22 ++++--- hw/openrisc_sim.c | 10 ++-- hw/palm.c | 9 +-- hw/pc_piix.c | 42 +++++++------ hw/petalogix_ml605_mmu.c | 8 +-- hw/petalogix_s3adsp1800_mmu.c | 8 +-- hw/ppc/e500plat.c | 13 +++-- hw/ppc/mpc8544ds.c | 13 +++-- hw/ppc405_boards.c | 25 ++++---- hw/ppc440_bamboo.c | 12 ++-- hw/ppc_newworld.c | 13 +++-- hw/ppc_oldworld.c | 13 +++-- hw/ppc_prep.c | 13 +++-- hw/puv3.c | 8 ++- hw/r2d.c | 9 +-- hw/realview.c | 44 +++++++++----- hw/s390-virtio.c | 13 +++-- hw/shix.c | 6 +- hw/spapr.c | 13 +++-- hw/spitz.c | 40 ++++++++----- hw/stellaris.c | 14 ++--- hw/sun4m.c | 133 ++++++++++++++++++++++++++---------------- hw/sun4u.c | 39 ++++++++----- hw/tosa.c | 9 +-- hw/versatilepb.c | 22 ++++--- hw/vexpress.c | 26 +++++---- hw/virtex_ml507.c | 10 ++-- hw/xen_machine_pv.c | 13 +++-- hw/xilinx_zynq.c | 9 ++- hw/xtensa_lx60.c | 22 ++++--- hw/xtensa_sim.c | 11 ++-- hw/z2.c | 9 +-- vl.c | 9 ++- 57 files changed, 520 insertions(+), 406 deletions(-) diff --git a/hw/alpha_dp264.c b/hw/alpha_dp264.c index 9eb939f..2c2e237 100644 --- a/hw/alpha_dp264.c +++ b/hw/alpha_dp264.c @@ -42,13 +42,13 @@ static int clipper_pci_map_irq(PCIDevice *d, int irq_num) return (slot + 1) * 4 + irq_num; } -static void clipper_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void clipper_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; CPUAlphaState *cpus[4]; PCIBus *pci_bus; ISABus *isa_bus; diff --git a/hw/an5206.c b/hw/an5206.c index 25407c0..042c5fc 100644 --- a/hw/an5206.c +++ b/hw/an5206.c @@ -19,11 +19,11 @@ /* Board init. */ -static void an5206_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void an5206_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; CPUM68KState *env; int kernel_size; uint64_t elf_entry; diff --git a/hw/axis_dev88.c b/hw/axis_dev88.c index eab6327..2fd7356 100644 --- a/hw/axis_dev88.c +++ b/hw/axis_dev88.c @@ -242,11 +242,12 @@ static const MemoryRegionOps gpio_ops = { static struct cris_load_info li; static -void axisdev88_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +void axisdev88_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; CRISCPU *cpu; CPUCRISState *env; DeviceState *dev; diff --git a/hw/boards.h b/hw/boards.h index a2e0a54..813d0e5 100644 --- a/hw/boards.h +++ b/hw/boards.h @@ -5,12 +5,16 @@ #include "qdev.h" -typedef void QEMUMachineInitFunc(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model); +typedef struct QEMUMachineInitArgs { + ram_addr_t ram_size; + const char *boot_device; + const char *kernel_filename; + const char *kernel_cmdline; + const char *initrd_filename; + const char *cpu_model; +} QEMUMachineInitArgs; + +typedef void QEMUMachineInitFunc(QEMUMachineInitArgs *args); typedef void QEMUMachineResetFunc(void); diff --git a/hw/collie.c b/hw/collie.c index 56f89a9..695982a 100644 --- a/hw/collie.c +++ b/hw/collie.c @@ -23,11 +23,12 @@ static struct arm_boot_info collie_binfo = { .ram_size = 0x20000000, }; -static void collie_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void collie_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; StrongARMState *s; DriveInfo *dinfo; MemoryRegion *sysmem = get_system_memory(); diff --git a/hw/dummy_m68k.c b/hw/dummy_m68k.c index 7cc7a99..f436a0c 100644 --- a/hw/dummy_m68k.c +++ b/hw/dummy_m68k.c @@ -16,11 +16,11 @@ /* Board init. */ -static void dummy_m68k_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void dummy_m68k_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; CPUM68KState *env; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *ram = g_new(MemoryRegion, 1); diff --git a/hw/exynos4_boards.c b/hw/exynos4_boards.c index 4bb0a60..4951064 100644 --- a/hw/exynos4_boards.c +++ b/hw/exynos4_boards.c @@ -130,22 +130,22 @@ static Exynos4210State *exynos4_boards_init_common( exynos4_board_ram_size[board_type]); } -static void nuri_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void nuri_init(QEMUMachineInitArgs *args) { + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; exynos4_boards_init_common(kernel_filename, kernel_cmdline, initrd_filename, EXYNOS4_BOARD_NURI); arm_load_kernel(arm_env_get_cpu(first_cpu), &exynos4_board_binfo); } -static void smdkc210_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void smdkc210_init(QEMUMachineInitArgs *args) { + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; Exynos4210State *s = exynos4_boards_init_common(kernel_filename, kernel_cmdline, initrd_filename, EXYNOS4_BOARD_SMDKC210); diff --git a/hw/gumstix.c b/hw/gumstix.c index 13a36ea..4103a88 100644 --- a/hw/gumstix.c +++ b/hw/gumstix.c @@ -45,10 +45,7 @@ static const int sector_len = 128 * 1024; -static void connex_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void connex_init(QEMUMachineInitArgs *args) { PXA2xxState *cpu; DriveInfo *dinfo; @@ -84,11 +81,9 @@ static void connex_init(ram_addr_t ram_size, qdev_get_gpio_in(cpu->gpio, 36)); } -static void verdex_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void verdex_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; PXA2xxState *cpu; DriveInfo *dinfo; int be; diff --git a/hw/highbank.c b/hw/highbank.c index 11aa131..15036b6 100644 --- a/hw/highbank.c +++ b/hw/highbank.c @@ -187,11 +187,13 @@ static struct arm_boot_info highbank_binfo; * 32-bit host, set the reg value of memory to 0xf7ff00000 in the * device tree and pass -m 2047 to QEMU. */ -static void highbank_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void highbank_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; DeviceState *dev; SysBusDevice *busdev; qemu_irq *irqp; diff --git a/hw/integratorcp.c b/hw/integratorcp.c index d0e2e90..ac0ea83 100644 --- a/hw/integratorcp.c +++ b/hw/integratorcp.c @@ -438,11 +438,13 @@ static struct arm_boot_info integrator_binfo = { .board_id = 0x113, }; -static void integratorcp_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void integratorcp_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; ARMCPU *cpu; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *ram = g_new(MemoryRegion, 1); diff --git a/hw/kzm.c b/hw/kzm.c index 68cd1b4..d1266d9 100644 --- a/hw/kzm.c +++ b/hw/kzm.c @@ -70,11 +70,13 @@ static struct arm_boot_info kzm_binfo = { .board_id = 1722, }; -static void kzm_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void kzm_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; ARMCPU *cpu; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *ram = g_new(MemoryRegion, 1); diff --git a/hw/leon3.c b/hw/leon3.c index 878d3aa..6486b7b 100644 --- a/hw/leon3.c +++ b/hw/leon3.c @@ -94,13 +94,11 @@ static void leon3_set_pil_in(void *opaque, uint32_t pil_in) } } -static void leon3_generic_hw_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void leon3_generic_hw_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; SPARCCPU *cpu; CPUSPARCState *env; MemoryRegion *address_space_mem = get_system_memory(); diff --git a/hw/lm32_boards.c b/hw/lm32_boards.c index b76d800..c5a62c8 100644 --- a/hw/lm32_boards.c +++ b/hw/lm32_boards.c @@ -69,12 +69,10 @@ static void main_cpu_reset(void *opaque) env->deba = reset_info->flash_base; } -static void lm32_evr_init(ram_addr_t ram_size_not_used, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void lm32_evr_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; LM32CPU *cpu; CPULM32State *env; DriveInfo *dinfo; @@ -159,12 +157,12 @@ static void lm32_evr_init(ram_addr_t ram_size_not_used, qemu_register_reset(main_cpu_reset, reset_info); } -static void lm32_uclinux_init(ram_addr_t ram_size_not_used, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void lm32_uclinux_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; LM32CPU *cpu; CPULM32State *env; DriveInfo *dinfo; diff --git a/hw/mainstone.c b/hw/mainstone.c index 97687b6..c0d6034 100644 --- a/hw/mainstone.c +++ b/hw/mainstone.c @@ -171,11 +171,13 @@ static void mainstone_common_init(MemoryRegion *address_space_mem, arm_load_kernel(mpu->cpu, &mainstone_binfo); } -static void mainstone_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void mainstone_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; mainstone_common_init(get_system_memory(), ram_size, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, mainstone, 0x196); } diff --git a/hw/mcf5208.c b/hw/mcf5208.c index ee25b1b..688bc3c 100644 --- a/hw/mcf5208.c +++ b/hw/mcf5208.c @@ -187,11 +187,11 @@ static void mcf5208_sys_init(MemoryRegion *address_space, qemu_irq *pic) } } -static void mcf5208evb_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void mcf5208evb_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; CPUM68KState *env; int kernel_size; uint64_t elf_entry; diff --git a/hw/milkymist.c b/hw/milkymist.c index 2e7235b..ca9ed43 100644 --- a/hw/milkymist.c +++ b/hw/milkymist.c @@ -73,12 +73,12 @@ static void main_cpu_reset(void *opaque) } static void -milkymist_init(ram_addr_t ram_size_not_used, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +milkymist_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; LM32CPU *cpu; CPULM32State *env; int kernel_size; diff --git a/hw/mips_fulong2e.c b/hw/mips_fulong2e.c index 38e4b86..af7bb50 100644 --- a/hw/mips_fulong2e.c +++ b/hw/mips_fulong2e.c @@ -256,10 +256,13 @@ static void cpu_request_exit(void *opaque, int irq, int level) } } -static void mips_fulong2e_init(ram_addr_t ram_size, const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void mips_fulong2e_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; char *filename; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *ram = g_new(MemoryRegion, 1); diff --git a/hw/mips_jazz.c b/hw/mips_jazz.c index db927f1..14df4d7 100644 --- a/hw/mips_jazz.c +++ b/hw/mips_jazz.c @@ -302,21 +302,19 @@ static void mips_jazz_init(MemoryRegion *address_space, } static -void mips_magnum_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +void mips_magnum_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; mips_jazz_init(get_system_memory(), get_system_io(), ram_size, cpu_model, JAZZ_MAGNUM); } static -void mips_pica61_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +void mips_pica61_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; mips_jazz_init(get_system_memory(), get_system_io(), ram_size, cpu_model, JAZZ_PICA61); } diff --git a/hw/mips_malta.c b/hw/mips_malta.c index ad23f26..14151f9 100644 --- a/hw/mips_malta.c +++ b/hw/mips_malta.c @@ -777,11 +777,13 @@ static void cpu_request_exit(void *opaque, int irq, int level) } static -void mips_malta_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +void mips_malta_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; char *filename; pflash_t *fl; MemoryRegion *system_memory = get_system_memory(); diff --git a/hw/mips_mipssim.c b/hw/mips_mipssim.c index 830f635..a1d3945 100644 --- a/hw/mips_mipssim.c +++ b/hw/mips_mipssim.c @@ -131,11 +131,13 @@ static void mipsnet_init(int base, qemu_irq irq, NICInfo *nd) } static void -mips_mipssim_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +mips_mipssim_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; char *filename; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *ram = g_new(MemoryRegion, 1); diff --git a/hw/mips_r4k.c b/hw/mips_r4k.c index 967a76e..b73cdc3 100644 --- a/hw/mips_r4k.c +++ b/hw/mips_r4k.c @@ -151,11 +151,13 @@ static void main_cpu_reset(void *opaque) static const int sector_len = 32 * 1024; static -void mips_r4k_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +void mips_r4k_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; char *filename; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *ram = g_new(MemoryRegion, 1); diff --git a/hw/musicpal.c b/hw/musicpal.c index f305e21..f06814c 100644 --- a/hw/musicpal.c +++ b/hw/musicpal.c @@ -1508,11 +1508,12 @@ static struct arm_boot_info musicpal_binfo = { .board_id = 0x20e, }; -static void musicpal_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void musicpal_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; ARMCPU *cpu; qemu_irq *cpu_pic; qemu_irq pic[32]; diff --git a/hw/nseries.c b/hw/nseries.c index 6df71eb..7ada90d 100644 --- a/hw/nseries.c +++ b/hw/nseries.c @@ -1397,21 +1397,27 @@ static struct arm_boot_info n810_binfo = { .atag_board = n810_atag_setup, }; -static void n800_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void n800_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; return n8x0_init(ram_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, &n800_binfo, 800); } -static void n810_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void n810_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; return n8x0_init(ram_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, &n810_binfo, 810); diff --git a/hw/null-machine.c b/hw/null-machine.c index 69910d3..d813c08 100644 --- a/hw/null-machine.c +++ b/hw/null-machine.c @@ -15,12 +15,7 @@ #include "hw/hw.h" #include "hw/boards.h" -static void machine_none_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void machine_none_init(QEMUMachineInitArgs *args) { } diff --git a/hw/omap_sx1.c b/hw/omap_sx1.c index abca341..ad17487 100644 --- a/hw/omap_sx1.c +++ b/hw/omap_sx1.c @@ -209,20 +209,26 @@ static void sx1_init(ram_addr_t ram_size, //~ qemu_console_resize(ds, 640, 480); } -static void sx1_init_v1(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void sx1_init_v1(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sx1_init(ram_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, 1); } -static void sx1_init_v2(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void sx1_init_v2(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sx1_init(ram_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, 2); } diff --git a/hw/openrisc_sim.c b/hw/openrisc_sim.c index 55e97f0..e96a944 100644 --- a/hw/openrisc_sim.c +++ b/hw/openrisc_sim.c @@ -90,13 +90,11 @@ static void cpu_openrisc_load_kernel(ram_addr_t ram_size, cpu->env.pc = entry; } -static void openrisc_sim_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void openrisc_sim_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; OpenRISCCPU *cpu = NULL; MemoryRegion *ram; int n; diff --git a/hw/palm.c b/hw/palm.c index bacdc90..032b8d6 100644 --- a/hw/palm.c +++ b/hw/palm.c @@ -190,11 +190,12 @@ static struct arm_boot_info palmte_binfo = { .board_id = 0x331, }; -static void palmte_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void palmte_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; MemoryRegion *address_space_mem = get_system_memory(); struct omap_mpu_state_s *mpu; int flash_size = 0x00800000; diff --git a/hw/pc_piix.c b/hw/pc_piix.c index fd5898f..9efc822 100644 --- a/hw/pc_piix.c +++ b/hw/pc_piix.c @@ -287,13 +287,14 @@ static void pc_init1(MemoryRegion *system_memory, } } -static void pc_init_pci(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void pc_init_pci(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; pc_init1(get_system_memory(), get_system_io(), ram_size, boot_device, @@ -301,13 +302,14 @@ static void pc_init_pci(ram_addr_t ram_size, initrd_filename, cpu_model, 1, 1); } -static void pc_init_pci_no_kvmclock(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void pc_init_pci_no_kvmclock(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; pc_init1(get_system_memory(), get_system_io(), ram_size, boot_device, @@ -315,13 +317,14 @@ static void pc_init_pci_no_kvmclock(ram_addr_t ram_size, initrd_filename, cpu_model, 1, 0); } -static void pc_init_isa(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void pc_init_isa(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; if (cpu_model == NULL) cpu_model = "486"; pc_init1(get_system_memory(), @@ -332,7 +335,8 @@ static void pc_init_isa(ram_addr_t ram_size, } #ifdef CONFIG_XEN -static void pc_xen_hvm_init(ram_addr_t ram_size, +static void pc_xen_hvm_init(QEMUMachine *machine, + ram_addr_t ram_size, const char *boot_device, const char *kernel_filename, const char *kernel_cmdline, diff --git a/hw/petalogix_ml605_mmu.c b/hw/petalogix_ml605_mmu.c index dced648..ace0187 100644 --- a/hw/petalogix_ml605_mmu.c +++ b/hw/petalogix_ml605_mmu.c @@ -70,12 +70,10 @@ static void machine_cpu_reset(MicroBlazeCPU *cpu) } static void -petalogix_ml605_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +petalogix_ml605_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; MemoryRegion *address_space_mem = get_system_memory(); DeviceState *dev, *dma, *eth0; MicroBlazeCPU *cpu; diff --git a/hw/petalogix_s3adsp1800_mmu.c b/hw/petalogix_s3adsp1800_mmu.c index 2cf6882..71c32ce 100644 --- a/hw/petalogix_s3adsp1800_mmu.c +++ b/hw/petalogix_s3adsp1800_mmu.c @@ -57,12 +57,10 @@ static void machine_cpu_reset(MicroBlazeCPU *cpu) } static void -petalogix_s3adsp1800_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +petalogix_s3adsp1800_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; DeviceState *dev; MicroBlazeCPU *cpu; CPUMBState *env; diff --git a/hw/ppc/e500plat.c b/hw/ppc/e500plat.c index 60a5cb3..4cfb940 100644 --- a/hw/ppc/e500plat.c +++ b/hw/ppc/e500plat.c @@ -25,13 +25,14 @@ static void e500plat_fixup_devtree(PPCE500Params *params, void *fdt) sizeof(compatible)); } -static void e500plat_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void e500plat_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *boot_device = args->boot_device; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; PPCE500Params params = { .ram_size = ram_size, .boot_device = boot_device, diff --git a/hw/ppc/mpc8544ds.c b/hw/ppc/mpc8544ds.c index 984d21c..e651661 100644 --- a/hw/ppc/mpc8544ds.c +++ b/hw/ppc/mpc8544ds.c @@ -25,13 +25,14 @@ static void mpc8544ds_fixup_devtree(PPCE500Params *params, void *fdt) sizeof(compatible)); } -static void mpc8544ds_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void mpc8544ds_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *boot_device = args->boot_device; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; PPCE500Params params = { .ram_size = ram_size, .boot_device = boot_device, diff --git a/hw/ppc405_boards.c b/hw/ppc405_boards.c index 476775d..e848cb0 100644 --- a/hw/ppc405_boards.c +++ b/hw/ppc405_boards.c @@ -158,7 +158,7 @@ static void ref405ep_fpga_reset (void *opaque) fpga->reg1 = 0x0F; } -static void ref405ep_fpga_init (MemoryRegion *sysmem, uint32_t base) +static void ref405ep_fpga_init(MemoryRegion *sysmem, uint32_t base) { ref405ep_fpga_t *fpga; MemoryRegion *fpga_memory = g_new(MemoryRegion, 1); @@ -170,13 +170,12 @@ static void ref405ep_fpga_init (MemoryRegion *sysmem, uint32_t base) qemu_register_reset(&ref405ep_fpga_reset, fpga); } -static void ref405ep_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void ref405ep_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; char *filename; ppc4xx_bd_info_t bd; CPUPPCState *env; @@ -484,7 +483,7 @@ static void taihu_cpld_reset (void *opaque) cpld->reg1 = 0x80; } -static void taihu_cpld_init (MemoryRegion *sysmem, uint32_t base) +static void taihu_cpld_init(MemoryRegion *sysmem, uint32_t base) { taihu_cpld_t *cpld; MemoryRegion *cpld_memory = g_new(MemoryRegion, 1); @@ -495,13 +494,11 @@ static void taihu_cpld_init (MemoryRegion *sysmem, uint32_t base) qemu_register_reset(&taihu_cpld_reset, cpld); } -static void taihu_405ep_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void taihu_405ep_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *kernel_filename = args->kernel_filename; + const char *initrd_filename = args->initrd_filename; char *filename; qemu_irq *pic; MemoryRegion *sysmem = get_system_memory(); diff --git a/hw/ppc440_bamboo.c b/hw/ppc440_bamboo.c index c198071..78e7985 100644 --- a/hw/ppc440_bamboo.c +++ b/hw/ppc440_bamboo.c @@ -157,13 +157,13 @@ static void main_cpu_reset(void *opaque) mmubooke_create_initial_mapping(env, 0, 0); } -static void bamboo_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void bamboo_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; unsigned int pci_irq_nrs[4] = { 28, 27, 26, 25 }; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *ram_memories diff --git a/hw/ppc_newworld.c b/hw/ppc_newworld.c index e95cfe8..e7c0747 100644 --- a/hw/ppc_newworld.c +++ b/hw/ppc_newworld.c @@ -129,13 +129,14 @@ static void ppc_core99_reset(void *opaque) } /* PowerPC Mac99 hardware initialisation */ -static void ppc_core99_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void ppc_core99_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; PowerPCCPU *cpu = NULL; CPUPPCState *env = NULL; char *filename; diff --git a/hw/ppc_oldworld.c b/hw/ppc_oldworld.c index 1dcd8a6..d9f76a8 100644 --- a/hw/ppc_oldworld.c +++ b/hw/ppc_oldworld.c @@ -72,13 +72,14 @@ static void ppc_heathrow_reset(void *opaque) cpu_reset(CPU(cpu)); } -static void ppc_heathrow_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void ppc_heathrow_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; MemoryRegion *sysmem = get_system_memory(); PowerPCCPU *cpu = NULL; CPUPPCState *env = NULL; diff --git a/hw/ppc_prep.c b/hw/ppc_prep.c index 592b7b2..f51f78a 100644 --- a/hw/ppc_prep.c +++ b/hw/ppc_prep.c @@ -448,13 +448,14 @@ static void ppc_prep_reset(void *opaque) } /* PowerPC PREP hardware initialisation */ -static void ppc_prep_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void ppc_prep_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; MemoryRegion *sysmem = get_system_memory(); PowerPCCPU *cpu = NULL; CPUPPCState *env = NULL; diff --git a/hw/puv3.c b/hw/puv3.c index 43f7216..764799c 100644 --- a/hw/puv3.c +++ b/hw/puv3.c @@ -91,10 +91,12 @@ static void puv3_load_kernel(const char *kernel_filename) graphic_console_init(NULL, NULL, NULL, NULL, NULL); } -static void puv3_init(ram_addr_t ram_size, const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void puv3_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *initrd_filename = args->initrd_filename; CPUUniCore32State *env; if (initrd_filename) { diff --git a/hw/r2d.c b/hw/r2d.c index 0f16e81..5daa42f 100644 --- a/hw/r2d.c +++ b/hw/r2d.c @@ -219,11 +219,12 @@ static struct QEMU_PACKED char kernel_cmdline[256]; } boot_params; -static void r2d_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void r2d_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; SuperHCPU *cpu; CPUSH4State *env; ResetData *reset_info; diff --git a/hw/realview.c b/hw/realview.c index 19db4d0..8dc4be6 100644 --- a/hw/realview.c +++ b/hw/realview.c @@ -330,11 +330,14 @@ static void realview_init(ram_addr_t ram_size, arm_load_kernel(arm_env_get_cpu(first_cpu), &realview_binfo); } -static void realview_eb_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void realview_eb_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; if (!cpu_model) { cpu_model = "arm926"; } @@ -342,11 +345,14 @@ static void realview_eb_init(ram_addr_t ram_size, initrd_filename, cpu_model, BOARD_EB); } -static void realview_eb_mpcore_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void realview_eb_mpcore_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; if (!cpu_model) { cpu_model = "arm11mpcore"; } @@ -354,11 +360,14 @@ static void realview_eb_mpcore_init(ram_addr_t ram_size, initrd_filename, cpu_model, BOARD_EB_MPCORE); } -static void realview_pb_a8_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void realview_pb_a8_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; if (!cpu_model) { cpu_model = "cortex-a8"; } @@ -366,11 +375,14 @@ static void realview_pb_a8_init(ram_addr_t ram_size, initrd_filename, cpu_model, BOARD_PB_A8); } -static void realview_pbx_a9_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void realview_pbx_a9_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; if (!cpu_model) { cpu_model = "cortex-a9"; } diff --git a/hw/s390-virtio.c b/hw/s390-virtio.c index 47eed35..39ff178 100644 --- a/hw/s390-virtio.c +++ b/hw/s390-virtio.c @@ -151,13 +151,14 @@ unsigned s390_del_running_cpu(CPUS390XState *env) } /* PC hardware initialisation */ -static void s390_init(ram_addr_t my_ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void s390_init(QEMUMachineInitArgs *args) { + ram_addr_t my_ram_size = args->ram_size; + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; CPUS390XState *env = NULL; MemoryRegion *sysmem = get_system_memory(); MemoryRegion *ram = g_new(MemoryRegion, 1); diff --git a/hw/shix.c b/hw/shix.c index dd9ce17..b56dd54 100644 --- a/hw/shix.c +++ b/hw/shix.c @@ -37,11 +37,9 @@ #define BIOS_FILENAME "shix_bios.bin" #define BIOS_ADDRESS 0xA0000000 -static void shix_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void shix_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; int ret; CPUSH4State *env; struct SH7750State *s; diff --git a/hw/spapr.c b/hw/spapr.c index c34b767..8921c4d 100644 --- a/hw/spapr.c +++ b/hw/spapr.c @@ -603,13 +603,14 @@ static int spapr_vga_init(PCIBus *pci_bus) } /* pSeries LPAR / sPAPR hardware init */ -static void ppc_spapr_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void ppc_spapr_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; PowerPCCPU *cpu; CPUPPCState *env; PCIHostState *phb; diff --git a/hw/spitz.c b/hw/spitz.c index 20e7835..df829b3 100644 --- a/hw/spitz.c +++ b/hw/spitz.c @@ -936,38 +936,46 @@ static void spitz_common_init(ram_addr_t ram_size, sl_bootparam_write(SL_PXA_PARAM_BASE); } -static void spitz_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void spitz_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; spitz_common_init(ram_size, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, spitz, 0x2c9); } -static void borzoi_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void borzoi_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; spitz_common_init(ram_size, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, borzoi, 0x33f); } -static void akita_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void akita_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; spitz_common_init(ram_size, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, akita, 0x2e8); } -static void terrier_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void terrier_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; spitz_common_init(ram_size, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, terrier, 0x33f); } diff --git a/hw/stellaris.c b/hw/stellaris.c index 562fbbf..b79c7fb 100644 --- a/hw/stellaris.c +++ b/hw/stellaris.c @@ -1358,19 +1358,17 @@ static void stellaris_init(const char *kernel_filename, const char *cpu_model, } /* FIXME: Figure out how to generate these from stellaris_boards. */ -static void lm3s811evb_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void lm3s811evb_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; stellaris_init(kernel_filename, cpu_model, &stellaris_boards[0]); } -static void lm3s6965evb_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void lm3s6965evb_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; stellaris_init(kernel_filename, cpu_model, &stellaris_boards[1]); } diff --git a/hw/sun4m.c b/hw/sun4m.c index c98cd5e..22e011f 100644 --- a/hw/sun4m.c +++ b/hw/sun4m.c @@ -1303,92 +1303,118 @@ static const struct sun4m_hwdef sun4m_hwdefs[] = { }; /* SPARCstation 5 hardware initialisation */ -static void ss5_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss5_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[0], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCstation 10 hardware initialisation */ -static void ss10_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss10_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[1], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCserver 600MP hardware initialisation */ -static void ss600mp_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss600mp_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[2], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCstation 20 hardware initialisation */ -static void ss20_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss20_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[3], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCstation Voyager hardware initialisation */ -static void vger_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void vger_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[4], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCstation LX hardware initialisation */ -static void ss_lx_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss_lx_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[5], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCstation 4 hardware initialisation */ -static void ss4_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss4_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[6], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCClassic hardware initialisation */ -static void scls_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void scls_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[7], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCbook hardware initialisation */ -static void sbook_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void sbook_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[8], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } @@ -1651,21 +1677,27 @@ static void sun4d_hw_init(const struct sun4d_hwdef *hwdef, ram_addr_t RAM_size, } /* SPARCserver 1000 hardware initialisation */ -static void ss1000_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss1000_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4d_hw_init(&sun4d_hwdefs[0], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCcenter 2000 hardware initialisation */ -static void ss2000_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss2000_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4d_hw_init(&sun4d_hwdefs[1], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } @@ -1845,11 +1877,14 @@ static void sun4c_hw_init(const struct sun4c_hwdef *hwdef, ram_addr_t RAM_size, } /* SPARCstation 2 hardware initialisation */ -static void ss2_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss2_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4c_hw_init(&sun4c_hwdefs[0], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } diff --git a/hw/sun4u.c b/hw/sun4u.c index 07cd042..379768c 100644 --- a/hw/sun4u.c +++ b/hw/sun4u.c @@ -930,31 +930,40 @@ static const struct hwdef hwdefs[] = { }; /* Sun4u hardware initialisation */ -static void sun4u_init(ram_addr_t RAM_size, - const char *boot_devices, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) -{ +static void sun4u_init(QEMUMachineInitArgs *args) +{ + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_devices = args->boot_device; sun4uv_init(get_system_memory(), RAM_size, boot_devices, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, &hwdefs[0]); } /* Sun4v hardware initialisation */ -static void sun4v_init(ram_addr_t RAM_size, - const char *boot_devices, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) -{ +static void sun4v_init(QEMUMachineInitArgs *args) +{ + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_devices = args->boot_device; sun4uv_init(get_system_memory(), RAM_size, boot_devices, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, &hwdefs[1]); } /* Niagara hardware initialisation */ -static void niagara_init(ram_addr_t RAM_size, - const char *boot_devices, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) -{ +static void niagara_init(QEMUMachineInitArgs *args) +{ + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_devices = args->boot_device; sun4uv_init(get_system_memory(), RAM_size, boot_devices, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, &hwdefs[2]); } diff --git a/hw/tosa.c b/hw/tosa.c index 297a8c2..512278c 100644 --- a/hw/tosa.c +++ b/hw/tosa.c @@ -205,11 +205,12 @@ static struct arm_boot_info tosa_binfo = { .ram_size = 0x04000000, }; -static void tosa_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void tosa_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *rom = g_new(MemoryRegion, 1); PXA2xxState *mpu; diff --git a/hw/versatilepb.c b/hw/versatilepb.c index 7a92034..686dcc7 100644 --- a/hw/versatilepb.c +++ b/hw/versatilepb.c @@ -342,22 +342,28 @@ static void versatile_init(ram_addr_t ram_size, arm_load_kernel(cpu, &versatile_binfo); } -static void vpb_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void vpb_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; versatile_init(ram_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, 0x183); } -static void vab_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void vab_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; versatile_init(ram_size, boot_device, kernel_filename, kernel_cmdline, diff --git a/hw/vexpress.c b/hw/vexpress.c index 3596d1e..36503d6 100644 --- a/hw/vexpress.c +++ b/hw/vexpress.c @@ -467,25 +467,27 @@ static void vexpress_common_init(const VEDBoardInfo *daughterboard, arm_load_kernel(arm_env_get_cpu(first_cpu), &vexpress_binfo); } -static void vexpress_a9_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void vexpress_a9_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; vexpress_common_init(&a9_daughterboard, ram_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } -static void vexpress_a15_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void vexpress_a15_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; vexpress_common_init(&a15_daughterboard, ram_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); diff --git a/hw/virtex_ml507.c b/hw/virtex_ml507.c index 79bc0d1..a09b27a 100644 --- a/hw/virtex_ml507.c +++ b/hw/virtex_ml507.c @@ -183,12 +183,12 @@ static int xilinx_load_device_tree(target_phys_addr_t addr, return fdt_size; } -static void virtex_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void virtex_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; MemoryRegion *address_space_mem = get_system_memory(); DeviceState *dev; PowerPCCPU *cpu; diff --git a/hw/xen_machine_pv.c b/hw/xen_machine_pv.c index 4b72aa7..1ac9990 100644 --- a/hw/xen_machine_pv.c +++ b/hw/xen_machine_pv.c @@ -29,12 +29,13 @@ #include "xen_domainbuild.h" #include "blockdev.h" -static void xen_init_pv(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void xen_init_pv(QEMUMachine *machine, + ram_addr_t ram_size, + const char *boot_device, + const char *kernel_filename, + const char *kernel_cmdline, + const char *initrd_filename, + const char *cpu_model) { X86CPU *cpu; CPUX86State *env; diff --git a/hw/xilinx_zynq.c b/hw/xilinx_zynq.c index 7e6c273..83f322e 100644 --- a/hw/xilinx_zynq.c +++ b/hw/xilinx_zynq.c @@ -46,10 +46,13 @@ static void gem_init(NICInfo *nd, uint32_t base, qemu_irq irq) sysbus_connect_irq(s, 0, irq); } -static void zynq_init(ram_addr_t ram_size, const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void zynq_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; ARMCPU *cpu; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *ext_ram = g_new(MemoryRegion, 1); diff --git a/hw/xtensa_lx60.c b/hw/xtensa_lx60.c index 3653f65..1fd2c47 100644 --- a/hw/xtensa_lx60.c +++ b/hw/xtensa_lx60.c @@ -268,11 +268,14 @@ static void lx_init(const LxBoardDesc *board, } } -static void xtensa_lx60_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void xtensa_lx60_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; static const LxBoardDesc lx60_board = { .flash_size = 0x400000, .flash_sector_size = 0x10000, @@ -283,11 +286,14 @@ static void xtensa_lx60_init(ram_addr_t ram_size, initrd_filename, cpu_model); } -static void xtensa_lx200_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void xtensa_lx200_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; static const LxBoardDesc lx200_board = { .flash_size = 0x1000000, .flash_sector_size = 0x20000, diff --git a/hw/xtensa_sim.c b/hw/xtensa_sim.c index 831460b..2e846d8 100644 --- a/hw/xtensa_sim.c +++ b/hw/xtensa_sim.c @@ -96,11 +96,14 @@ static void sim_init(ram_addr_t ram_size, } } -static void xtensa_sim_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void xtensa_sim_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; if (!cpu_model) { cpu_model = XTENSA_DEFAULT_CPU_MODEL; } diff --git a/hw/z2.c b/hw/z2.c index 289cee9..0927bad 100644 --- a/hw/z2.c +++ b/hw/z2.c @@ -294,11 +294,12 @@ static TypeInfo aer915_info = { .class_init = aer915_class_init, }; -static void z2_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void z2_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; MemoryRegion *address_space_mem = get_system_memory(); uint32_t sector_len = 0x10000; PXA2xxState *mpu; diff --git a/vl.c b/vl.c index 8d305ca..f663e7c 100644 --- a/vl.c +++ b/vl.c @@ -3624,8 +3624,13 @@ int main(int argc, char **argv, char **envp) qdev_machine_init(); - machine->init(ram_size, boot_devices, - kernel_filename, kernel_cmdline, initrd_filename, cpu_model); + QEMUMachineInitArgs args = { .ram_size = ram_size, + .boot_device = boot_devices, + .kernel_filename = kernel_filename, + .kernel_cmdline = kernel_cmdline, + initrd_filename = initrd_filename, + .cpu_model = cpu_model }; + machine->init(&args); cpu_synchronize_all_post_init(); -- 1.7.11.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 18:40:36 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 18:40:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCor-0004Ws-L6; Fri, 05 Oct 2012 18:40:17 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCoq-0004Wm-ST for xen-devel@lists.xen.org; Fri, 05 Oct 2012 18:40:17 +0000 Received: from [85.158.143.35:17059] by server-1.bemta-4.messagelabs.com id 3D/7F-05684-0992F605; Fri, 05 Oct 2012 18:40:16 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1349462413!5496248!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzg2MDM5\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7589 invoked from network); 5 Oct 2012 18:40:15 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 18:40:15 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q95Ie8Wv007258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Oct 2012 18:40:09 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q95Ie7cq018349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Oct 2012 18:40:08 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q95Ie7R6004860; Fri, 5 Oct 2012 13:40:07 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 05 Oct 2012 11:40:07 -0700 Date: Fri, 5 Oct 2012 11:40:06 -0700 From: Mukesh Rathor To: Ian Campbell Message-ID: <20121005114006.55115cca@mantra.us.oracle.com> In-Reply-To: <1349437645.20946.74.camel@zakaz.uk.xensource.com> References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-3-git-send-email-ian.campbell@citrix.com> <1349437645.20946.74.camel@zakaz.uk.xensource.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: Konrad Rzeszutek Wilk , "xen-devel@lists.xen.org" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH 03/14] xen events: xen_callback_vector is x86 specific X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 5 Oct 2012 12:47:25 +0100 Ian Campbell wrote: > On Fri, 2012-10-05 at 12:43 +0100, Stefano Stabellini wrote: > > On Thu, 4 Oct 2012, Ian Campbell wrote: > > > Signed-off-by: Ian Campbell > > > --- > > > Should instead move somewhere arch specific? > > > > This shouldn't be needed: it should be already protected by > > CONFIG_XEN_PVHVM (that is x86 specific). > > Mukesh removed that ifdef because PVH also wants this function. > I'm putting #ifdef CONFIG_X86 around it. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 18:40:36 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 18:40:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCor-0004Ws-L6; Fri, 05 Oct 2012 18:40:17 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCoq-0004Wm-ST for xen-devel@lists.xen.org; Fri, 05 Oct 2012 18:40:17 +0000 Received: from [85.158.143.35:17059] by server-1.bemta-4.messagelabs.com id 3D/7F-05684-0992F605; Fri, 05 Oct 2012 18:40:16 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1349462413!5496248!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzg2MDM5\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7589 invoked from network); 5 Oct 2012 18:40:15 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 18:40:15 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q95Ie8Wv007258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Oct 2012 18:40:09 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q95Ie7cq018349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Oct 2012 18:40:08 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q95Ie7R6004860; Fri, 5 Oct 2012 13:40:07 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 05 Oct 2012 11:40:07 -0700 Date: Fri, 5 Oct 2012 11:40:06 -0700 From: Mukesh Rathor To: Ian Campbell Message-ID: <20121005114006.55115cca@mantra.us.oracle.com> In-Reply-To: <1349437645.20946.74.camel@zakaz.uk.xensource.com> References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-3-git-send-email-ian.campbell@citrix.com> <1349437645.20946.74.camel@zakaz.uk.xensource.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: Konrad Rzeszutek Wilk , "xen-devel@lists.xen.org" , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH 03/14] xen events: xen_callback_vector is x86 specific X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 5 Oct 2012 12:47:25 +0100 Ian Campbell wrote: > On Fri, 2012-10-05 at 12:43 +0100, Stefano Stabellini wrote: > > On Thu, 4 Oct 2012, Ian Campbell wrote: > > > Signed-off-by: Ian Campbell > > > --- > > > Should instead move somewhere arch specific? > > > > This shouldn't be needed: it should be already protected by > > CONFIG_XEN_PVHVM (that is x86 specific). > > Mukesh removed that ifdef because PVH also wants this function. > I'm putting #ifdef CONFIG_X86 around it. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 18:45:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 18:45:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCth-0004lT-Bq; Fri, 05 Oct 2012 18:45:17 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCtg-0004lO-4f for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 18:45:16 +0000 Received: from [85.158.143.35:49814] by server-3.bemta-4.messagelabs.com id F0/0C-10986-BBA2F605; Fri, 05 Oct 2012 18:45:15 +0000 X-Env-Sender: agraf@suse.de X-Msg-Ref: server-16.tower-21.messagelabs.com!1349462709!15013806!1 X-Originating-IP: [195.135.220.15] X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, MIME_QP_LONG_LINE X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4230 invoked from network); 5 Oct 2012 18:45:10 -0000 Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15) by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 18:45:10 -0000 Received: from relay1.suse.de (unknown [195.135.220.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id 9B9CF9A78E; Fri, 5 Oct 2012 20:45:05 +0200 (CEST) References: <1349462220-13742-1-git-send-email-ehabkost@redhat.com> In-Reply-To: <1349462220-13742-1-git-send-email-ehabkost@redhat.com> Mime-Version: 1.0 (1.0) Message-Id: <34AF8EDF-D8BB-437B-9417-2FFAB6FC626F@suse.de> X-Mailer: iPhone Mail (9B206) From: Alexander Graf Date: Fri, 5 Oct 2012 20:45:19 +0200 To: Eduardo Habkost Cc: Peter Maydell , Evgeny Voevodin , "qemu-devel@nongnu.org" , Peter Crosthwaite , Max Filippov , "Edgar E. Iglesias" , Guan Xuetao , "xen-devel@lists.xensource.com" , Igor Mitsyanko , Magnus Damm , =?utf-8?Q?Herv=C3=A9_Poussineau?= , Maksim Kozlov , Andrzej Zaborowski , Fabien Chouteau , Jan Kiszka , Paul Brook , Blue Swirl , Anthony Liguori , Michael Walle , "qemu-ppc@nongnu.org" , Dmitry Solodkiy , Aurelien Jarno Subject: Re: [Xen-devel] [QEMU PATCH] create struct for machine initialization arguments X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 05.10.2012, at 20:37, Eduardo Habkost wrote: > > This should help us to: > - More easily add or remove machine initialization arguments without > having to change every single machine init function; > - More easily make mechanical changes involving the machine init > functions in the future; > - Let machine initialization forward the init arguments to other > functions more easily. > > This change was half-mechanical process: first the struct was added with > the local ram_size, boot_device, kernel_*, initrd_*, and cpu_model local > variable initialization to all functions. Then the compiler helped me > locate the local variables that are unused, so they could be removed. > > Signed-off-by: Eduardo Habkost Very good idea :). Alex > --- > hw/alpha_dp264.c | 12 ++-- > hw/an5206.c | 8 +-- > hw/axis_dev88.c | 9 +-- > hw/boards.h | 16 +++-- > hw/collie.c | 9 +-- > hw/dummy_m68k.c | 8 +-- > hw/exynos4_boards.c | 16 ++--- > hw/gumstix.c | 11 +--- > hw/highbank.c | 10 ++-- > hw/integratorcp.c | 10 ++-- > hw/kzm.c | 10 ++-- > hw/leon3.c | 10 ++-- > hw/lm32_boards.c | 18 +++--- > hw/mainstone.c | 10 ++-- > hw/mcf5208.c | 8 +-- > hw/milkymist.c | 10 ++-- > hw/mips_fulong2e.c | 9 ++- > hw/mips_jazz.c | 14 ++--- > hw/mips_malta.c | 10 ++-- > hw/mips_mipssim.c | 10 ++-- > hw/mips_r4k.c | 10 ++-- > hw/musicpal.c | 9 +-- > hw/nseries.c | 22 ++++--- > hw/null-machine.c | 7 +-- > hw/omap_sx1.c | 22 ++++--- > hw/openrisc_sim.c | 10 ++-- > hw/palm.c | 9 +-- > hw/pc_piix.c | 42 +++++++------ > hw/petalogix_ml605_mmu.c | 8 +-- > hw/petalogix_s3adsp1800_mmu.c | 8 +-- > hw/ppc/e500plat.c | 13 +++-- > hw/ppc/mpc8544ds.c | 13 +++-- > hw/ppc405_boards.c | 25 ++++---- > hw/ppc440_bamboo.c | 12 ++-- > hw/ppc_newworld.c | 13 +++-- > hw/ppc_oldworld.c | 13 +++-- > hw/ppc_prep.c | 13 +++-- > hw/puv3.c | 8 ++- > hw/r2d.c | 9 +-- > hw/realview.c | 44 +++++++++----- > hw/s390-virtio.c | 13 +++-- > hw/shix.c | 6 +- > hw/spapr.c | 13 +++-- > hw/spitz.c | 40 ++++++++----- > hw/stellaris.c | 14 ++--- > hw/sun4m.c | 133 ++++++++++++++++++++++++++---------------- > hw/sun4u.c | 39 ++++++++----- > hw/tosa.c | 9 +-- > hw/versatilepb.c | 22 ++++--- > hw/vexpress.c | 26 +++++---- > hw/virtex_ml507.c | 10 ++-- > hw/xen_machine_pv.c | 13 +++-- > hw/xilinx_zynq.c | 9 ++- > hw/xtensa_lx60.c | 22 ++++--- > hw/xtensa_sim.c | 11 ++-- > hw/z2.c | 9 +-- > vl.c | 9 ++- > 57 files changed, 520 insertions(+), 406 deletions(-) > > diff --git a/hw/alpha_dp264.c b/hw/alpha_dp264.c > index 9eb939f..2c2e237 100644 > --- a/hw/alpha_dp264.c > +++ b/hw/alpha_dp264.c > @@ -42,13 +42,13 @@ static int clipper_pci_map_irq(PCIDevice *d, int irq_num) > return (slot + 1) * 4 + irq_num; > } > > -static void clipper_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, > - const char *cpu_model) > +static void clipper_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > CPUAlphaState *cpus[4]; > PCIBus *pci_bus; > ISABus *isa_bus; > diff --git a/hw/an5206.c b/hw/an5206.c > index 25407c0..042c5fc 100644 > --- a/hw/an5206.c > +++ b/hw/an5206.c > @@ -19,11 +19,11 @@ > > /* Board init. */ > > -static void an5206_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void an5206_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > CPUM68KState *env; > int kernel_size; > uint64_t elf_entry; > diff --git a/hw/axis_dev88.c b/hw/axis_dev88.c > index eab6327..2fd7356 100644 > --- a/hw/axis_dev88.c > +++ b/hw/axis_dev88.c > @@ -242,11 +242,12 @@ static const MemoryRegionOps gpio_ops = { > static struct cris_load_info li; > > static > -void axisdev88_init (ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +void axisdev88_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > CRISCPU *cpu; > CPUCRISState *env; > DeviceState *dev; > diff --git a/hw/boards.h b/hw/boards.h > index a2e0a54..813d0e5 100644 > --- a/hw/boards.h > +++ b/hw/boards.h > @@ -5,12 +5,16 @@ > > #include "qdev.h" > > -typedef void QEMUMachineInitFunc(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, > - const char *cpu_model); > +typedef struct QEMUMachineInitArgs { > + ram_addr_t ram_size; > + const char *boot_device; > + const char *kernel_filename; > + const char *kernel_cmdline; > + const char *initrd_filename; > + const char *cpu_model; > +} QEMUMachineInitArgs; > + > +typedef void QEMUMachineInitFunc(QEMUMachineInitArgs *args); > > typedef void QEMUMachineResetFunc(void); > > diff --git a/hw/collie.c b/hw/collie.c > index 56f89a9..695982a 100644 > --- a/hw/collie.c > +++ b/hw/collie.c > @@ -23,11 +23,12 @@ static struct arm_boot_info collie_binfo = { > .ram_size = 0x20000000, > }; > > -static void collie_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void collie_init(QEMUMachineInitArgs *args) > { > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > StrongARMState *s; > DriveInfo *dinfo; > MemoryRegion *sysmem = get_system_memory(); > diff --git a/hw/dummy_m68k.c b/hw/dummy_m68k.c > index 7cc7a99..f436a0c 100644 > --- a/hw/dummy_m68k.c > +++ b/hw/dummy_m68k.c > @@ -16,11 +16,11 @@ > > /* Board init. */ > > -static void dummy_m68k_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void dummy_m68k_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > CPUM68KState *env; > MemoryRegion *address_space_mem = get_system_memory(); > MemoryRegion *ram = g_new(MemoryRegion, 1); > diff --git a/hw/exynos4_boards.c b/hw/exynos4_boards.c > index 4bb0a60..4951064 100644 > --- a/hw/exynos4_boards.c > +++ b/hw/exynos4_boards.c > @@ -130,22 +130,22 @@ static Exynos4210State *exynos4_boards_init_common( > exynos4_board_ram_size[board_type]); > } > > -static void nuri_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void nuri_init(QEMUMachineInitArgs *args) > { > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > exynos4_boards_init_common(kernel_filename, kernel_cmdline, > initrd_filename, EXYNOS4_BOARD_NURI); > > arm_load_kernel(arm_env_get_cpu(first_cpu), &exynos4_board_binfo); > } > > -static void smdkc210_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void smdkc210_init(QEMUMachineInitArgs *args) > { > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > Exynos4210State *s = exynos4_boards_init_common(kernel_filename, > kernel_cmdline, initrd_filename, EXYNOS4_BOARD_SMDKC210); > > diff --git a/hw/gumstix.c b/hw/gumstix.c > index 13a36ea..4103a88 100644 > --- a/hw/gumstix.c > +++ b/hw/gumstix.c > @@ -45,10 +45,7 @@ > > static const int sector_len = 128 * 1024; > > -static void connex_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void connex_init(QEMUMachineInitArgs *args) > { > PXA2xxState *cpu; > DriveInfo *dinfo; > @@ -84,11 +81,9 @@ static void connex_init(ram_addr_t ram_size, > qdev_get_gpio_in(cpu->gpio, 36)); > } > > -static void verdex_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void verdex_init(QEMUMachineInitArgs *args) > { > + const char *cpu_model = args->cpu_model; > PXA2xxState *cpu; > DriveInfo *dinfo; > int be; > diff --git a/hw/highbank.c b/hw/highbank.c > index 11aa131..15036b6 100644 > --- a/hw/highbank.c > +++ b/hw/highbank.c > @@ -187,11 +187,13 @@ static struct arm_boot_info highbank_binfo; > * 32-bit host, set the reg value of memory to 0xf7ff00000 in the > * device tree and pass -m 2047 to QEMU. > */ > -static void highbank_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void highbank_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > DeviceState *dev; > SysBusDevice *busdev; > qemu_irq *irqp; > diff --git a/hw/integratorcp.c b/hw/integratorcp.c > index d0e2e90..ac0ea83 100644 > --- a/hw/integratorcp.c > +++ b/hw/integratorcp.c > @@ -438,11 +438,13 @@ static struct arm_boot_info integrator_binfo = { > .board_id = 0x113, > }; > > -static void integratorcp_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void integratorcp_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > ARMCPU *cpu; > MemoryRegion *address_space_mem = get_system_memory(); > MemoryRegion *ram = g_new(MemoryRegion, 1); > diff --git a/hw/kzm.c b/hw/kzm.c > index 68cd1b4..d1266d9 100644 > --- a/hw/kzm.c > +++ b/hw/kzm.c > @@ -70,11 +70,13 @@ static struct arm_boot_info kzm_binfo = { > .board_id = 1722, > }; > > -static void kzm_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void kzm_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > ARMCPU *cpu; > MemoryRegion *address_space_mem = get_system_memory(); > MemoryRegion *ram = g_new(MemoryRegion, 1); > diff --git a/hw/leon3.c b/hw/leon3.c > index 878d3aa..6486b7b 100644 > --- a/hw/leon3.c > +++ b/hw/leon3.c > @@ -94,13 +94,11 @@ static void leon3_set_pil_in(void *opaque, uint32_t pil_in) > } > } > > -static void leon3_generic_hw_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, > - const char *cpu_model) > +static void leon3_generic_hw_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > SPARCCPU *cpu; > CPUSPARCState *env; > MemoryRegion *address_space_mem = get_system_memory(); > diff --git a/hw/lm32_boards.c b/hw/lm32_boards.c > index b76d800..c5a62c8 100644 > --- a/hw/lm32_boards.c > +++ b/hw/lm32_boards.c > @@ -69,12 +69,10 @@ static void main_cpu_reset(void *opaque) > env->deba = reset_info->flash_base; > } > > -static void lm32_evr_init(ram_addr_t ram_size_not_used, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void lm32_evr_init(QEMUMachineInitArgs *args) > { > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > LM32CPU *cpu; > CPULM32State *env; > DriveInfo *dinfo; > @@ -159,12 +157,12 @@ static void lm32_evr_init(ram_addr_t ram_size_not_used, > qemu_register_reset(main_cpu_reset, reset_info); > } > > -static void lm32_uclinux_init(ram_addr_t ram_size_not_used, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void lm32_uclinux_init(QEMUMachineInitArgs *args) > { > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > LM32CPU *cpu; > CPULM32State *env; > DriveInfo *dinfo; > diff --git a/hw/mainstone.c b/hw/mainstone.c > index 97687b6..c0d6034 100644 > --- a/hw/mainstone.c > +++ b/hw/mainstone.c > @@ -171,11 +171,13 @@ static void mainstone_common_init(MemoryRegion *address_space_mem, > arm_load_kernel(mpu->cpu, &mainstone_binfo); > } > > -static void mainstone_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void mainstone_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > mainstone_common_init(get_system_memory(), ram_size, kernel_filename, > kernel_cmdline, initrd_filename, cpu_model, mainstone, 0x196); > } > diff --git a/hw/mcf5208.c b/hw/mcf5208.c > index ee25b1b..688bc3c 100644 > --- a/hw/mcf5208.c > +++ b/hw/mcf5208.c > @@ -187,11 +187,11 @@ static void mcf5208_sys_init(MemoryRegion *address_space, qemu_irq *pic) > } > } > > -static void mcf5208evb_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void mcf5208evb_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > CPUM68KState *env; > int kernel_size; > uint64_t elf_entry; > diff --git a/hw/milkymist.c b/hw/milkymist.c > index 2e7235b..ca9ed43 100644 > --- a/hw/milkymist.c > +++ b/hw/milkymist.c > @@ -73,12 +73,12 @@ static void main_cpu_reset(void *opaque) > } > > static void > -milkymist_init(ram_addr_t ram_size_not_used, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +milkymist_init(QEMUMachineInitArgs *args) > { > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > LM32CPU *cpu; > CPULM32State *env; > int kernel_size; > diff --git a/hw/mips_fulong2e.c b/hw/mips_fulong2e.c > index 38e4b86..af7bb50 100644 > --- a/hw/mips_fulong2e.c > +++ b/hw/mips_fulong2e.c > @@ -256,10 +256,13 @@ static void cpu_request_exit(void *opaque, int irq, int level) > } > } > > -static void mips_fulong2e_init(ram_addr_t ram_size, const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void mips_fulong2e_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > char *filename; > MemoryRegion *address_space_mem = get_system_memory(); > MemoryRegion *ram = g_new(MemoryRegion, 1); > diff --git a/hw/mips_jazz.c b/hw/mips_jazz.c > index db927f1..14df4d7 100644 > --- a/hw/mips_jazz.c > +++ b/hw/mips_jazz.c > @@ -302,21 +302,19 @@ static void mips_jazz_init(MemoryRegion *address_space, > } > > static > -void mips_magnum_init (ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +void mips_magnum_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > mips_jazz_init(get_system_memory(), get_system_io(), > ram_size, cpu_model, JAZZ_MAGNUM); > } > > static > -void mips_pica61_init (ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +void mips_pica61_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > mips_jazz_init(get_system_memory(), get_system_io(), > ram_size, cpu_model, JAZZ_PICA61); > } > diff --git a/hw/mips_malta.c b/hw/mips_malta.c > index ad23f26..14151f9 100644 > --- a/hw/mips_malta.c > +++ b/hw/mips_malta.c > @@ -777,11 +777,13 @@ static void cpu_request_exit(void *opaque, int irq, int level) > } > > static > -void mips_malta_init (ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +void mips_malta_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > char *filename; > pflash_t *fl; > MemoryRegion *system_memory = get_system_memory(); > diff --git a/hw/mips_mipssim.c b/hw/mips_mipssim.c > index 830f635..a1d3945 100644 > --- a/hw/mips_mipssim.c > +++ b/hw/mips_mipssim.c > @@ -131,11 +131,13 @@ static void mipsnet_init(int base, qemu_irq irq, NICInfo *nd) > } > > static void > -mips_mipssim_init (ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +mips_mipssim_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > char *filename; > MemoryRegion *address_space_mem = get_system_memory(); > MemoryRegion *ram = g_new(MemoryRegion, 1); > diff --git a/hw/mips_r4k.c b/hw/mips_r4k.c > index 967a76e..b73cdc3 100644 > --- a/hw/mips_r4k.c > +++ b/hw/mips_r4k.c > @@ -151,11 +151,13 @@ static void main_cpu_reset(void *opaque) > > static const int sector_len = 32 * 1024; > static > -void mips_r4k_init (ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +void mips_r4k_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > char *filename; > MemoryRegion *address_space_mem = get_system_memory(); > MemoryRegion *ram = g_new(MemoryRegion, 1); > diff --git a/hw/musicpal.c b/hw/musicpal.c > index f305e21..f06814c 100644 > --- a/hw/musicpal.c > +++ b/hw/musicpal.c > @@ -1508,11 +1508,12 @@ static struct arm_boot_info musicpal_binfo = { > .board_id = 0x20e, > }; > > -static void musicpal_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void musicpal_init(QEMUMachineInitArgs *args) > { > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > ARMCPU *cpu; > qemu_irq *cpu_pic; > qemu_irq pic[32]; > diff --git a/hw/nseries.c b/hw/nseries.c > index 6df71eb..7ada90d 100644 > --- a/hw/nseries.c > +++ b/hw/nseries.c > @@ -1397,21 +1397,27 @@ static struct arm_boot_info n810_binfo = { > .atag_board = n810_atag_setup, > }; > > -static void n800_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void n800_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > return n8x0_init(ram_size, boot_device, > kernel_filename, kernel_cmdline, initrd_filename, > cpu_model, &n800_binfo, 800); > } > > -static void n810_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void n810_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > return n8x0_init(ram_size, boot_device, > kernel_filename, kernel_cmdline, initrd_filename, > cpu_model, &n810_binfo, 810); > diff --git a/hw/null-machine.c b/hw/null-machine.c > index 69910d3..d813c08 100644 > --- a/hw/null-machine.c > +++ b/hw/null-machine.c > @@ -15,12 +15,7 @@ > #include "hw/hw.h" > #include "hw/boards.h" > > -static void machine_none_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, > - const char *cpu_model) > +static void machine_none_init(QEMUMachineInitArgs *args) > { > } > > diff --git a/hw/omap_sx1.c b/hw/omap_sx1.c > index abca341..ad17487 100644 > --- a/hw/omap_sx1.c > +++ b/hw/omap_sx1.c > @@ -209,20 +209,26 @@ static void sx1_init(ram_addr_t ram_size, > //~ qemu_console_resize(ds, 640, 480); > } > > -static void sx1_init_v1(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void sx1_init_v1(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > sx1_init(ram_size, boot_device, kernel_filename, > kernel_cmdline, initrd_filename, cpu_model, 1); > } > > -static void sx1_init_v2(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void sx1_init_v2(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > sx1_init(ram_size, boot_device, kernel_filename, > kernel_cmdline, initrd_filename, cpu_model, 2); > } > diff --git a/hw/openrisc_sim.c b/hw/openrisc_sim.c > index 55e97f0..e96a944 100644 > --- a/hw/openrisc_sim.c > +++ b/hw/openrisc_sim.c > @@ -90,13 +90,11 @@ static void cpu_openrisc_load_kernel(ram_addr_t ram_size, > cpu->env.pc = entry; > } > > -static void openrisc_sim_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, > - const char *cpu_model) > +static void openrisc_sim_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > OpenRISCCPU *cpu = NULL; > MemoryRegion *ram; > int n; > diff --git a/hw/palm.c b/hw/palm.c > index bacdc90..032b8d6 100644 > --- a/hw/palm.c > +++ b/hw/palm.c > @@ -190,11 +190,12 @@ static struct arm_boot_info palmte_binfo = { > .board_id = 0x331, > }; > > -static void palmte_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void palmte_init(QEMUMachineInitArgs *args) > { > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > MemoryRegion *address_space_mem = get_system_memory(); > struct omap_mpu_state_s *mpu; > int flash_size = 0x00800000; > diff --git a/hw/pc_piix.c b/hw/pc_piix.c > index fd5898f..9efc822 100644 > --- a/hw/pc_piix.c > +++ b/hw/pc_piix.c > @@ -287,13 +287,14 @@ static void pc_init1(MemoryRegion *system_memory, > } > } > > -static void pc_init_pci(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, > - const char *cpu_model) > +static void pc_init_pci(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > pc_init1(get_system_memory(), > get_system_io(), > ram_size, boot_device, > @@ -301,13 +302,14 @@ static void pc_init_pci(ram_addr_t ram_size, > initrd_filename, cpu_model, 1, 1); > } > > -static void pc_init_pci_no_kvmclock(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, > - const char *cpu_model) > +static void pc_init_pci_no_kvmclock(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > pc_init1(get_system_memory(), > get_system_io(), > ram_size, boot_device, > @@ -315,13 +317,14 @@ static void pc_init_pci_no_kvmclock(ram_addr_t ram_size, > initrd_filename, cpu_model, 1, 0); > } > > -static void pc_init_isa(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, > - const char *cpu_model) > +static void pc_init_isa(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > if (cpu_model == NULL) > cpu_model = "486"; > pc_init1(get_system_memory(), > @@ -332,7 +335,8 @@ static void pc_init_isa(ram_addr_t ram_size, > } > > #ifdef CONFIG_XEN > -static void pc_xen_hvm_init(ram_addr_t ram_size, > +static void pc_xen_hvm_init(QEMUMachine *machine, > + ram_addr_t ram_size, > const char *boot_device, > const char *kernel_filename, > const char *kernel_cmdline, > diff --git a/hw/petalogix_ml605_mmu.c b/hw/petalogix_ml605_mmu.c > index dced648..ace0187 100644 > --- a/hw/petalogix_ml605_mmu.c > +++ b/hw/petalogix_ml605_mmu.c > @@ -70,12 +70,10 @@ static void machine_cpu_reset(MicroBlazeCPU *cpu) > } > > static void > -petalogix_ml605_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +petalogix_ml605_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > MemoryRegion *address_space_mem = get_system_memory(); > DeviceState *dev, *dma, *eth0; > MicroBlazeCPU *cpu; > diff --git a/hw/petalogix_s3adsp1800_mmu.c b/hw/petalogix_s3adsp1800_mmu.c > index 2cf6882..71c32ce 100644 > --- a/hw/petalogix_s3adsp1800_mmu.c > +++ b/hw/petalogix_s3adsp1800_mmu.c > @@ -57,12 +57,10 @@ static void machine_cpu_reset(MicroBlazeCPU *cpu) > } > > static void > -petalogix_s3adsp1800_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +petalogix_s3adsp1800_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > DeviceState *dev; > MicroBlazeCPU *cpu; > CPUMBState *env; > diff --git a/hw/ppc/e500plat.c b/hw/ppc/e500plat.c > index 60a5cb3..4cfb940 100644 > --- a/hw/ppc/e500plat.c > +++ b/hw/ppc/e500plat.c > @@ -25,13 +25,14 @@ static void e500plat_fixup_devtree(PPCE500Params *params, void *fdt) > sizeof(compatible)); > } > > -static void e500plat_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, > - const char *cpu_model) > +static void e500plat_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *boot_device = args->boot_device; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > PPCE500Params params = { > .ram_size = ram_size, > .boot_device = boot_device, > diff --git a/hw/ppc/mpc8544ds.c b/hw/ppc/mpc8544ds.c > index 984d21c..e651661 100644 > --- a/hw/ppc/mpc8544ds.c > +++ b/hw/ppc/mpc8544ds.c > @@ -25,13 +25,14 @@ static void mpc8544ds_fixup_devtree(PPCE500Params *params, void *fdt) > sizeof(compatible)); > } > > -static void mpc8544ds_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, > - const char *cpu_model) > +static void mpc8544ds_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *boot_device = args->boot_device; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > PPCE500Params params = { > .ram_size = ram_size, > .boot_device = boot_device, > diff --git a/hw/ppc405_boards.c b/hw/ppc405_boards.c > index 476775d..e848cb0 100644 > --- a/hw/ppc405_boards.c > +++ b/hw/ppc405_boards.c > @@ -158,7 +158,7 @@ static void ref405ep_fpga_reset (void *opaque) > fpga->reg1 = 0x0F; > } > > -static void ref405ep_fpga_init (MemoryRegion *sysmem, uint32_t base) > +static void ref405ep_fpga_init(MemoryRegion *sysmem, uint32_t base) > { > ref405ep_fpga_t *fpga; > MemoryRegion *fpga_memory = g_new(MemoryRegion, 1); > @@ -170,13 +170,12 @@ static void ref405ep_fpga_init (MemoryRegion *sysmem, uint32_t base) > qemu_register_reset(&ref405ep_fpga_reset, fpga); > } > > -static void ref405ep_init (ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, > - const char *cpu_model) > +static void ref405ep_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > char *filename; > ppc4xx_bd_info_t bd; > CPUPPCState *env; > @@ -484,7 +483,7 @@ static void taihu_cpld_reset (void *opaque) > cpld->reg1 = 0x80; > } > > -static void taihu_cpld_init (MemoryRegion *sysmem, uint32_t base) > +static void taihu_cpld_init(MemoryRegion *sysmem, uint32_t base) > { > taihu_cpld_t *cpld; > MemoryRegion *cpld_memory = g_new(MemoryRegion, 1); > @@ -495,13 +494,11 @@ static void taihu_cpld_init (MemoryRegion *sysmem, uint32_t base) > qemu_register_reset(&taihu_cpld_reset, cpld); > } > > -static void taihu_405ep_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, > - const char *cpu_model) > +static void taihu_405ep_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *kernel_filename = args->kernel_filename; > + const char *initrd_filename = args->initrd_filename; > char *filename; > qemu_irq *pic; > MemoryRegion *sysmem = get_system_memory(); > diff --git a/hw/ppc440_bamboo.c b/hw/ppc440_bamboo.c > index c198071..78e7985 100644 > --- a/hw/ppc440_bamboo.c > +++ b/hw/ppc440_bamboo.c > @@ -157,13 +157,13 @@ static void main_cpu_reset(void *opaque) > mmubooke_create_initial_mapping(env, 0, 0); > } > > -static void bamboo_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, > - const char *cpu_model) > +static void bamboo_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > unsigned int pci_irq_nrs[4] = { 28, 27, 26, 25 }; > MemoryRegion *address_space_mem = get_system_memory(); > MemoryRegion *ram_memories > diff --git a/hw/ppc_newworld.c b/hw/ppc_newworld.c > index e95cfe8..e7c0747 100644 > --- a/hw/ppc_newworld.c > +++ b/hw/ppc_newworld.c > @@ -129,13 +129,14 @@ static void ppc_core99_reset(void *opaque) > } > > /* PowerPC Mac99 hardware initialisation */ > -static void ppc_core99_init (ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, > - const char *cpu_model) > +static void ppc_core99_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > PowerPCCPU *cpu = NULL; > CPUPPCState *env = NULL; > char *filename; > diff --git a/hw/ppc_oldworld.c b/hw/ppc_oldworld.c > index 1dcd8a6..d9f76a8 100644 > --- a/hw/ppc_oldworld.c > +++ b/hw/ppc_oldworld.c > @@ -72,13 +72,14 @@ static void ppc_heathrow_reset(void *opaque) > cpu_reset(CPU(cpu)); > } > > -static void ppc_heathrow_init (ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, > - const char *cpu_model) > +static void ppc_heathrow_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > MemoryRegion *sysmem = get_system_memory(); > PowerPCCPU *cpu = NULL; > CPUPPCState *env = NULL; > diff --git a/hw/ppc_prep.c b/hw/ppc_prep.c > index 592b7b2..f51f78a 100644 > --- a/hw/ppc_prep.c > +++ b/hw/ppc_prep.c > @@ -448,13 +448,14 @@ static void ppc_prep_reset(void *opaque) > } > > /* PowerPC PREP hardware initialisation */ > -static void ppc_prep_init (ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, > - const char *cpu_model) > +static void ppc_prep_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > MemoryRegion *sysmem = get_system_memory(); > PowerPCCPU *cpu = NULL; > CPUPPCState *env = NULL; > diff --git a/hw/puv3.c b/hw/puv3.c > index 43f7216..764799c 100644 > --- a/hw/puv3.c > +++ b/hw/puv3.c > @@ -91,10 +91,12 @@ static void puv3_load_kernel(const char *kernel_filename) > graphic_console_init(NULL, NULL, NULL, NULL, NULL); > } > > -static void puv3_init(ram_addr_t ram_size, const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void puv3_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *initrd_filename = args->initrd_filename; > CPUUniCore32State *env; > > if (initrd_filename) { > diff --git a/hw/r2d.c b/hw/r2d.c > index 0f16e81..5daa42f 100644 > --- a/hw/r2d.c > +++ b/hw/r2d.c > @@ -219,11 +219,12 @@ static struct QEMU_PACKED > char kernel_cmdline[256]; > } boot_params; > > -static void r2d_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void r2d_init(QEMUMachineInitArgs *args) > { > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > SuperHCPU *cpu; > CPUSH4State *env; > ResetData *reset_info; > diff --git a/hw/realview.c b/hw/realview.c > index 19db4d0..8dc4be6 100644 > --- a/hw/realview.c > +++ b/hw/realview.c > @@ -330,11 +330,14 @@ static void realview_init(ram_addr_t ram_size, > arm_load_kernel(arm_env_get_cpu(first_cpu), &realview_binfo); > } > > -static void realview_eb_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void realview_eb_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > if (!cpu_model) { > cpu_model = "arm926"; > } > @@ -342,11 +345,14 @@ static void realview_eb_init(ram_addr_t ram_size, > initrd_filename, cpu_model, BOARD_EB); > } > > -static void realview_eb_mpcore_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void realview_eb_mpcore_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > if (!cpu_model) { > cpu_model = "arm11mpcore"; > } > @@ -354,11 +360,14 @@ static void realview_eb_mpcore_init(ram_addr_t ram_size, > initrd_filename, cpu_model, BOARD_EB_MPCORE); > } > > -static void realview_pb_a8_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void realview_pb_a8_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > if (!cpu_model) { > cpu_model = "cortex-a8"; > } > @@ -366,11 +375,14 @@ static void realview_pb_a8_init(ram_addr_t ram_size, > initrd_filename, cpu_model, BOARD_PB_A8); > } > > -static void realview_pbx_a9_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void realview_pbx_a9_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > if (!cpu_model) { > cpu_model = "cortex-a9"; > } > diff --git a/hw/s390-virtio.c b/hw/s390-virtio.c > index 47eed35..39ff178 100644 > --- a/hw/s390-virtio.c > +++ b/hw/s390-virtio.c > @@ -151,13 +151,14 @@ unsigned s390_del_running_cpu(CPUS390XState *env) > } > > /* PC hardware initialisation */ > -static void s390_init(ram_addr_t my_ram_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, > - const char *cpu_model) > +static void s390_init(QEMUMachineInitArgs *args) > { > + ram_addr_t my_ram_size = args->ram_size; > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > CPUS390XState *env = NULL; > MemoryRegion *sysmem = get_system_memory(); > MemoryRegion *ram = g_new(MemoryRegion, 1); > diff --git a/hw/shix.c b/hw/shix.c > index dd9ce17..b56dd54 100644 > --- a/hw/shix.c > +++ b/hw/shix.c > @@ -37,11 +37,9 @@ > #define BIOS_FILENAME "shix_bios.bin" > #define BIOS_ADDRESS 0xA0000000 > > -static void shix_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void shix_init(QEMUMachineInitArgs *args) > { > + const char *cpu_model = args->cpu_model; > int ret; > CPUSH4State *env; > struct SH7750State *s; > diff --git a/hw/spapr.c b/hw/spapr.c > index c34b767..8921c4d 100644 > --- a/hw/spapr.c > +++ b/hw/spapr.c > @@ -603,13 +603,14 @@ static int spapr_vga_init(PCIBus *pci_bus) > } > > /* pSeries LPAR / sPAPR hardware init */ > -static void ppc_spapr_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, > - const char *cpu_model) > +static void ppc_spapr_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > PowerPCCPU *cpu; > CPUPPCState *env; > PCIHostState *phb; > diff --git a/hw/spitz.c b/hw/spitz.c > index 20e7835..df829b3 100644 > --- a/hw/spitz.c > +++ b/hw/spitz.c > @@ -936,38 +936,46 @@ static void spitz_common_init(ram_addr_t ram_size, > sl_bootparam_write(SL_PXA_PARAM_BASE); > } > > -static void spitz_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void spitz_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > spitz_common_init(ram_size, kernel_filename, > kernel_cmdline, initrd_filename, cpu_model, spitz, 0x2c9); > } > > -static void borzoi_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void borzoi_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > spitz_common_init(ram_size, kernel_filename, > kernel_cmdline, initrd_filename, cpu_model, borzoi, 0x33f); > } > > -static void akita_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void akita_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > spitz_common_init(ram_size, kernel_filename, > kernel_cmdline, initrd_filename, cpu_model, akita, 0x2e8); > } > > -static void terrier_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void terrier_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > spitz_common_init(ram_size, kernel_filename, > kernel_cmdline, initrd_filename, cpu_model, terrier, 0x33f); > } > diff --git a/hw/stellaris.c b/hw/stellaris.c > index 562fbbf..b79c7fb 100644 > --- a/hw/stellaris.c > +++ b/hw/stellaris.c > @@ -1358,19 +1358,17 @@ static void stellaris_init(const char *kernel_filename, const char *cpu_model, > } > > /* FIXME: Figure out how to generate these from stellaris_boards. */ > -static void lm3s811evb_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void lm3s811evb_init(QEMUMachineInitArgs *args) > { > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > stellaris_init(kernel_filename, cpu_model, &stellaris_boards[0]); > } > > -static void lm3s6965evb_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void lm3s6965evb_init(QEMUMachineInitArgs *args) > { > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > stellaris_init(kernel_filename, cpu_model, &stellaris_boards[1]); > } > > diff --git a/hw/sun4m.c b/hw/sun4m.c > index c98cd5e..22e011f 100644 > --- a/hw/sun4m.c > +++ b/hw/sun4m.c > @@ -1303,92 +1303,118 @@ static const struct sun4m_hwdef sun4m_hwdefs[] = { > }; > > /* SPARCstation 5 hardware initialisation */ > -static void ss5_init(ram_addr_t RAM_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void ss5_init(QEMUMachineInitArgs *args) > { > + ram_addr_t RAM_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > sun4m_hw_init(&sun4m_hwdefs[0], RAM_size, boot_device, kernel_filename, > kernel_cmdline, initrd_filename, cpu_model); > } > > /* SPARCstation 10 hardware initialisation */ > -static void ss10_init(ram_addr_t RAM_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void ss10_init(QEMUMachineInitArgs *args) > { > + ram_addr_t RAM_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > sun4m_hw_init(&sun4m_hwdefs[1], RAM_size, boot_device, kernel_filename, > kernel_cmdline, initrd_filename, cpu_model); > } > > /* SPARCserver 600MP hardware initialisation */ > -static void ss600mp_init(ram_addr_t RAM_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void ss600mp_init(QEMUMachineInitArgs *args) > { > + ram_addr_t RAM_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > sun4m_hw_init(&sun4m_hwdefs[2], RAM_size, boot_device, kernel_filename, > kernel_cmdline, initrd_filename, cpu_model); > } > > /* SPARCstation 20 hardware initialisation */ > -static void ss20_init(ram_addr_t RAM_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void ss20_init(QEMUMachineInitArgs *args) > { > + ram_addr_t RAM_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > sun4m_hw_init(&sun4m_hwdefs[3], RAM_size, boot_device, kernel_filename, > kernel_cmdline, initrd_filename, cpu_model); > } > > /* SPARCstation Voyager hardware initialisation */ > -static void vger_init(ram_addr_t RAM_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void vger_init(QEMUMachineInitArgs *args) > { > + ram_addr_t RAM_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > sun4m_hw_init(&sun4m_hwdefs[4], RAM_size, boot_device, kernel_filename, > kernel_cmdline, initrd_filename, cpu_model); > } > > /* SPARCstation LX hardware initialisation */ > -static void ss_lx_init(ram_addr_t RAM_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void ss_lx_init(QEMUMachineInitArgs *args) > { > + ram_addr_t RAM_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > sun4m_hw_init(&sun4m_hwdefs[5], RAM_size, boot_device, kernel_filename, > kernel_cmdline, initrd_filename, cpu_model); > } > > /* SPARCstation 4 hardware initialisation */ > -static void ss4_init(ram_addr_t RAM_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void ss4_init(QEMUMachineInitArgs *args) > { > + ram_addr_t RAM_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > sun4m_hw_init(&sun4m_hwdefs[6], RAM_size, boot_device, kernel_filename, > kernel_cmdline, initrd_filename, cpu_model); > } > > /* SPARCClassic hardware initialisation */ > -static void scls_init(ram_addr_t RAM_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void scls_init(QEMUMachineInitArgs *args) > { > + ram_addr_t RAM_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > sun4m_hw_init(&sun4m_hwdefs[7], RAM_size, boot_device, kernel_filename, > kernel_cmdline, initrd_filename, cpu_model); > } > > /* SPARCbook hardware initialisation */ > -static void sbook_init(ram_addr_t RAM_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void sbook_init(QEMUMachineInitArgs *args) > { > + ram_addr_t RAM_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > sun4m_hw_init(&sun4m_hwdefs[8], RAM_size, boot_device, kernel_filename, > kernel_cmdline, initrd_filename, cpu_model); > } > @@ -1651,21 +1677,27 @@ static void sun4d_hw_init(const struct sun4d_hwdef *hwdef, ram_addr_t RAM_size, > } > > /* SPARCserver 1000 hardware initialisation */ > -static void ss1000_init(ram_addr_t RAM_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void ss1000_init(QEMUMachineInitArgs *args) > { > + ram_addr_t RAM_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > sun4d_hw_init(&sun4d_hwdefs[0], RAM_size, boot_device, kernel_filename, > kernel_cmdline, initrd_filename, cpu_model); > } > > /* SPARCcenter 2000 hardware initialisation */ > -static void ss2000_init(ram_addr_t RAM_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void ss2000_init(QEMUMachineInitArgs *args) > { > + ram_addr_t RAM_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > sun4d_hw_init(&sun4d_hwdefs[1], RAM_size, boot_device, kernel_filename, > kernel_cmdline, initrd_filename, cpu_model); > } > @@ -1845,11 +1877,14 @@ static void sun4c_hw_init(const struct sun4c_hwdef *hwdef, ram_addr_t RAM_size, > } > > /* SPARCstation 2 hardware initialisation */ > -static void ss2_init(ram_addr_t RAM_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void ss2_init(QEMUMachineInitArgs *args) > { > + ram_addr_t RAM_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > sun4c_hw_init(&sun4c_hwdefs[0], RAM_size, boot_device, kernel_filename, > kernel_cmdline, initrd_filename, cpu_model); > } > diff --git a/hw/sun4u.c b/hw/sun4u.c > index 07cd042..379768c 100644 > --- a/hw/sun4u.c > +++ b/hw/sun4u.c > @@ -930,31 +930,40 @@ static const struct hwdef hwdefs[] = { > }; > > /* Sun4u hardware initialisation */ > -static void sun4u_init(ram_addr_t RAM_size, > - const char *boot_devices, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > -{ > +static void sun4u_init(QEMUMachineInitArgs *args) > +{ > + ram_addr_t RAM_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_devices = args->boot_device; > sun4uv_init(get_system_memory(), RAM_size, boot_devices, kernel_filename, > kernel_cmdline, initrd_filename, cpu_model, &hwdefs[0]); > } > > /* Sun4v hardware initialisation */ > -static void sun4v_init(ram_addr_t RAM_size, > - const char *boot_devices, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > -{ > +static void sun4v_init(QEMUMachineInitArgs *args) > +{ > + ram_addr_t RAM_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_devices = args->boot_device; > sun4uv_init(get_system_memory(), RAM_size, boot_devices, kernel_filename, > kernel_cmdline, initrd_filename, cpu_model, &hwdefs[1]); > } > > /* Niagara hardware initialisation */ > -static void niagara_init(ram_addr_t RAM_size, > - const char *boot_devices, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > -{ > +static void niagara_init(QEMUMachineInitArgs *args) > +{ > + ram_addr_t RAM_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_devices = args->boot_device; > sun4uv_init(get_system_memory(), RAM_size, boot_devices, kernel_filename, > kernel_cmdline, initrd_filename, cpu_model, &hwdefs[2]); > } > diff --git a/hw/tosa.c b/hw/tosa.c > index 297a8c2..512278c 100644 > --- a/hw/tosa.c > +++ b/hw/tosa.c > @@ -205,11 +205,12 @@ static struct arm_boot_info tosa_binfo = { > .ram_size = 0x04000000, > }; > > -static void tosa_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void tosa_init(QEMUMachineInitArgs *args) > { > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > MemoryRegion *address_space_mem = get_system_memory(); > MemoryRegion *rom = g_new(MemoryRegion, 1); > PXA2xxState *mpu; > diff --git a/hw/versatilepb.c b/hw/versatilepb.c > index 7a92034..686dcc7 100644 > --- a/hw/versatilepb.c > +++ b/hw/versatilepb.c > @@ -342,22 +342,28 @@ static void versatile_init(ram_addr_t ram_size, > arm_load_kernel(cpu, &versatile_binfo); > } > > -static void vpb_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void vpb_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > versatile_init(ram_size, > boot_device, > kernel_filename, kernel_cmdline, > initrd_filename, cpu_model, 0x183); > } > > -static void vab_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void vab_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > versatile_init(ram_size, > boot_device, > kernel_filename, kernel_cmdline, > diff --git a/hw/vexpress.c b/hw/vexpress.c > index 3596d1e..36503d6 100644 > --- a/hw/vexpress.c > +++ b/hw/vexpress.c > @@ -467,25 +467,27 @@ static void vexpress_common_init(const VEDBoardInfo *daughterboard, > arm_load_kernel(arm_env_get_cpu(first_cpu), &vexpress_binfo); > } > > -static void vexpress_a9_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, > - const char *cpu_model) > +static void vexpress_a9_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > vexpress_common_init(&a9_daughterboard, > ram_size, boot_device, kernel_filename, > kernel_cmdline, initrd_filename, cpu_model); > } > > -static void vexpress_a15_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, > - const char *cpu_model) > +static void vexpress_a15_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > vexpress_common_init(&a15_daughterboard, > ram_size, boot_device, kernel_filename, > kernel_cmdline, initrd_filename, cpu_model); > diff --git a/hw/virtex_ml507.c b/hw/virtex_ml507.c > index 79bc0d1..a09b27a 100644 > --- a/hw/virtex_ml507.c > +++ b/hw/virtex_ml507.c > @@ -183,12 +183,12 @@ static int xilinx_load_device_tree(target_phys_addr_t addr, > return fdt_size; > } > > -static void virtex_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void virtex_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > MemoryRegion *address_space_mem = get_system_memory(); > DeviceState *dev; > PowerPCCPU *cpu; > diff --git a/hw/xen_machine_pv.c b/hw/xen_machine_pv.c > index 4b72aa7..1ac9990 100644 > --- a/hw/xen_machine_pv.c > +++ b/hw/xen_machine_pv.c > @@ -29,12 +29,13 @@ > #include "xen_domainbuild.h" > #include "blockdev.h" > > -static void xen_init_pv(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, > - const char *cpu_model) > +static void xen_init_pv(QEMUMachine *machine, > + ram_addr_t ram_size, > + const char *boot_device, > + const char *kernel_filename, > + const char *kernel_cmdline, > + const char *initrd_filename, > + const char *cpu_model) > { > X86CPU *cpu; > CPUX86State *env; > diff --git a/hw/xilinx_zynq.c b/hw/xilinx_zynq.c > index 7e6c273..83f322e 100644 > --- a/hw/xilinx_zynq.c > +++ b/hw/xilinx_zynq.c > @@ -46,10 +46,13 @@ static void gem_init(NICInfo *nd, uint32_t base, qemu_irq irq) > sysbus_connect_irq(s, 0, irq); > } > > -static void zynq_init(ram_addr_t ram_size, const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void zynq_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > ARMCPU *cpu; > MemoryRegion *address_space_mem = get_system_memory(); > MemoryRegion *ext_ram = g_new(MemoryRegion, 1); > diff --git a/hw/xtensa_lx60.c b/hw/xtensa_lx60.c > index 3653f65..1fd2c47 100644 > --- a/hw/xtensa_lx60.c > +++ b/hw/xtensa_lx60.c > @@ -268,11 +268,14 @@ static void lx_init(const LxBoardDesc *board, > } > } > > -static void xtensa_lx60_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void xtensa_lx60_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > static const LxBoardDesc lx60_board = { > .flash_size = 0x400000, > .flash_sector_size = 0x10000, > @@ -283,11 +286,14 @@ static void xtensa_lx60_init(ram_addr_t ram_size, > initrd_filename, cpu_model); > } > > -static void xtensa_lx200_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void xtensa_lx200_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > static const LxBoardDesc lx200_board = { > .flash_size = 0x1000000, > .flash_sector_size = 0x20000, > diff --git a/hw/xtensa_sim.c b/hw/xtensa_sim.c > index 831460b..2e846d8 100644 > --- a/hw/xtensa_sim.c > +++ b/hw/xtensa_sim.c > @@ -96,11 +96,14 @@ static void sim_init(ram_addr_t ram_size, > } > } > > -static void xtensa_sim_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void xtensa_sim_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > if (!cpu_model) { > cpu_model = XTENSA_DEFAULT_CPU_MODEL; > } > diff --git a/hw/z2.c b/hw/z2.c > index 289cee9..0927bad 100644 > --- a/hw/z2.c > +++ b/hw/z2.c > @@ -294,11 +294,12 @@ static TypeInfo aer915_info = { > .class_init = aer915_class_init, > }; > > -static void z2_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void z2_init(QEMUMachineInitArgs *args) > { > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > MemoryRegion *address_space_mem = get_system_memory(); > uint32_t sector_len = 0x10000; > PXA2xxState *mpu; > diff --git a/vl.c b/vl.c > index 8d305ca..f663e7c 100644 > --- a/vl.c > +++ b/vl.c > @@ -3624,8 +3624,13 @@ int main(int argc, char **argv, char **envp) > > qdev_machine_init(); > > - machine->init(ram_size, boot_devices, > - kernel_filename, kernel_cmdline, initrd_filename, cpu_model); > + QEMUMachineInitArgs args = { .ram_size = ram_size, > + .boot_device = boot_devices, > + .kernel_filename = kernel_filename, > + .kernel_cmdline = kernel_cmdline, > + initrd_filename = initrd_filename, > + .cpu_model = cpu_model }; > + machine->init(&args); > > cpu_synchronize_all_post_init(); > > -- > 1.7.11.4 > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 18:45:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 18:45:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCth-0004lT-Bq; Fri, 05 Oct 2012 18:45:17 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKCtg-0004lO-4f for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 18:45:16 +0000 Received: from [85.158.143.35:49814] by server-3.bemta-4.messagelabs.com id F0/0C-10986-BBA2F605; Fri, 05 Oct 2012 18:45:15 +0000 X-Env-Sender: agraf@suse.de X-Msg-Ref: server-16.tower-21.messagelabs.com!1349462709!15013806!1 X-Originating-IP: [195.135.220.15] X-SpamReason: No, hits=0.7 required=7.0 tests=BODY_RANDOM_LONG, MIME_QP_LONG_LINE X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4230 invoked from network); 5 Oct 2012 18:45:10 -0000 Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15) by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 18:45:10 -0000 Received: from relay1.suse.de (unknown [195.135.220.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id 9B9CF9A78E; Fri, 5 Oct 2012 20:45:05 +0200 (CEST) References: <1349462220-13742-1-git-send-email-ehabkost@redhat.com> In-Reply-To: <1349462220-13742-1-git-send-email-ehabkost@redhat.com> Mime-Version: 1.0 (1.0) Message-Id: <34AF8EDF-D8BB-437B-9417-2FFAB6FC626F@suse.de> X-Mailer: iPhone Mail (9B206) From: Alexander Graf Date: Fri, 5 Oct 2012 20:45:19 +0200 To: Eduardo Habkost Cc: Peter Maydell , Evgeny Voevodin , "qemu-devel@nongnu.org" , Peter Crosthwaite , Max Filippov , "Edgar E. Iglesias" , Guan Xuetao , "xen-devel@lists.xensource.com" , Igor Mitsyanko , Magnus Damm , =?utf-8?Q?Herv=C3=A9_Poussineau?= , Maksim Kozlov , Andrzej Zaborowski , Fabien Chouteau , Jan Kiszka , Paul Brook , Blue Swirl , Anthony Liguori , Michael Walle , "qemu-ppc@nongnu.org" , Dmitry Solodkiy , Aurelien Jarno Subject: Re: [Xen-devel] [QEMU PATCH] create struct for machine initialization arguments X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 05.10.2012, at 20:37, Eduardo Habkost wrote: > > This should help us to: > - More easily add or remove machine initialization arguments without > having to change every single machine init function; > - More easily make mechanical changes involving the machine init > functions in the future; > - Let machine initialization forward the init arguments to other > functions more easily. > > This change was half-mechanical process: first the struct was added with > the local ram_size, boot_device, kernel_*, initrd_*, and cpu_model local > variable initialization to all functions. Then the compiler helped me > locate the local variables that are unused, so they could be removed. > > Signed-off-by: Eduardo Habkost Very good idea :). Alex > --- > hw/alpha_dp264.c | 12 ++-- > hw/an5206.c | 8 +-- > hw/axis_dev88.c | 9 +-- > hw/boards.h | 16 +++-- > hw/collie.c | 9 +-- > hw/dummy_m68k.c | 8 +-- > hw/exynos4_boards.c | 16 ++--- > hw/gumstix.c | 11 +--- > hw/highbank.c | 10 ++-- > hw/integratorcp.c | 10 ++-- > hw/kzm.c | 10 ++-- > hw/leon3.c | 10 ++-- > hw/lm32_boards.c | 18 +++--- > hw/mainstone.c | 10 ++-- > hw/mcf5208.c | 8 +-- > hw/milkymist.c | 10 ++-- > hw/mips_fulong2e.c | 9 ++- > hw/mips_jazz.c | 14 ++--- > hw/mips_malta.c | 10 ++-- > hw/mips_mipssim.c | 10 ++-- > hw/mips_r4k.c | 10 ++-- > hw/musicpal.c | 9 +-- > hw/nseries.c | 22 ++++--- > hw/null-machine.c | 7 +-- > hw/omap_sx1.c | 22 ++++--- > hw/openrisc_sim.c | 10 ++-- > hw/palm.c | 9 +-- > hw/pc_piix.c | 42 +++++++------ > hw/petalogix_ml605_mmu.c | 8 +-- > hw/petalogix_s3adsp1800_mmu.c | 8 +-- > hw/ppc/e500plat.c | 13 +++-- > hw/ppc/mpc8544ds.c | 13 +++-- > hw/ppc405_boards.c | 25 ++++---- > hw/ppc440_bamboo.c | 12 ++-- > hw/ppc_newworld.c | 13 +++-- > hw/ppc_oldworld.c | 13 +++-- > hw/ppc_prep.c | 13 +++-- > hw/puv3.c | 8 ++- > hw/r2d.c | 9 +-- > hw/realview.c | 44 +++++++++----- > hw/s390-virtio.c | 13 +++-- > hw/shix.c | 6 +- > hw/spapr.c | 13 +++-- > hw/spitz.c | 40 ++++++++----- > hw/stellaris.c | 14 ++--- > hw/sun4m.c | 133 ++++++++++++++++++++++++++---------------- > hw/sun4u.c | 39 ++++++++----- > hw/tosa.c | 9 +-- > hw/versatilepb.c | 22 ++++--- > hw/vexpress.c | 26 +++++---- > hw/virtex_ml507.c | 10 ++-- > hw/xen_machine_pv.c | 13 +++-- > hw/xilinx_zynq.c | 9 ++- > hw/xtensa_lx60.c | 22 ++++--- > hw/xtensa_sim.c | 11 ++-- > hw/z2.c | 9 +-- > vl.c | 9 ++- > 57 files changed, 520 insertions(+), 406 deletions(-) > > diff --git a/hw/alpha_dp264.c b/hw/alpha_dp264.c > index 9eb939f..2c2e237 100644 > --- a/hw/alpha_dp264.c > +++ b/hw/alpha_dp264.c > @@ -42,13 +42,13 @@ static int clipper_pci_map_irq(PCIDevice *d, int irq_num) > return (slot + 1) * 4 + irq_num; > } > > -static void clipper_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, > - const char *cpu_model) > +static void clipper_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > CPUAlphaState *cpus[4]; > PCIBus *pci_bus; > ISABus *isa_bus; > diff --git a/hw/an5206.c b/hw/an5206.c > index 25407c0..042c5fc 100644 > --- a/hw/an5206.c > +++ b/hw/an5206.c > @@ -19,11 +19,11 @@ > > /* Board init. */ > > -static void an5206_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void an5206_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > CPUM68KState *env; > int kernel_size; > uint64_t elf_entry; > diff --git a/hw/axis_dev88.c b/hw/axis_dev88.c > index eab6327..2fd7356 100644 > --- a/hw/axis_dev88.c > +++ b/hw/axis_dev88.c > @@ -242,11 +242,12 @@ static const MemoryRegionOps gpio_ops = { > static struct cris_load_info li; > > static > -void axisdev88_init (ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +void axisdev88_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > CRISCPU *cpu; > CPUCRISState *env; > DeviceState *dev; > diff --git a/hw/boards.h b/hw/boards.h > index a2e0a54..813d0e5 100644 > --- a/hw/boards.h > +++ b/hw/boards.h > @@ -5,12 +5,16 @@ > > #include "qdev.h" > > -typedef void QEMUMachineInitFunc(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, > - const char *cpu_model); > +typedef struct QEMUMachineInitArgs { > + ram_addr_t ram_size; > + const char *boot_device; > + const char *kernel_filename; > + const char *kernel_cmdline; > + const char *initrd_filename; > + const char *cpu_model; > +} QEMUMachineInitArgs; > + > +typedef void QEMUMachineInitFunc(QEMUMachineInitArgs *args); > > typedef void QEMUMachineResetFunc(void); > > diff --git a/hw/collie.c b/hw/collie.c > index 56f89a9..695982a 100644 > --- a/hw/collie.c > +++ b/hw/collie.c > @@ -23,11 +23,12 @@ static struct arm_boot_info collie_binfo = { > .ram_size = 0x20000000, > }; > > -static void collie_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void collie_init(QEMUMachineInitArgs *args) > { > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > StrongARMState *s; > DriveInfo *dinfo; > MemoryRegion *sysmem = get_system_memory(); > diff --git a/hw/dummy_m68k.c b/hw/dummy_m68k.c > index 7cc7a99..f436a0c 100644 > --- a/hw/dummy_m68k.c > +++ b/hw/dummy_m68k.c > @@ -16,11 +16,11 @@ > > /* Board init. */ > > -static void dummy_m68k_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void dummy_m68k_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > CPUM68KState *env; > MemoryRegion *address_space_mem = get_system_memory(); > MemoryRegion *ram = g_new(MemoryRegion, 1); > diff --git a/hw/exynos4_boards.c b/hw/exynos4_boards.c > index 4bb0a60..4951064 100644 > --- a/hw/exynos4_boards.c > +++ b/hw/exynos4_boards.c > @@ -130,22 +130,22 @@ static Exynos4210State *exynos4_boards_init_common( > exynos4_board_ram_size[board_type]); > } > > -static void nuri_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void nuri_init(QEMUMachineInitArgs *args) > { > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > exynos4_boards_init_common(kernel_filename, kernel_cmdline, > initrd_filename, EXYNOS4_BOARD_NURI); > > arm_load_kernel(arm_env_get_cpu(first_cpu), &exynos4_board_binfo); > } > > -static void smdkc210_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void smdkc210_init(QEMUMachineInitArgs *args) > { > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > Exynos4210State *s = exynos4_boards_init_common(kernel_filename, > kernel_cmdline, initrd_filename, EXYNOS4_BOARD_SMDKC210); > > diff --git a/hw/gumstix.c b/hw/gumstix.c > index 13a36ea..4103a88 100644 > --- a/hw/gumstix.c > +++ b/hw/gumstix.c > @@ -45,10 +45,7 @@ > > static const int sector_len = 128 * 1024; > > -static void connex_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void connex_init(QEMUMachineInitArgs *args) > { > PXA2xxState *cpu; > DriveInfo *dinfo; > @@ -84,11 +81,9 @@ static void connex_init(ram_addr_t ram_size, > qdev_get_gpio_in(cpu->gpio, 36)); > } > > -static void verdex_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void verdex_init(QEMUMachineInitArgs *args) > { > + const char *cpu_model = args->cpu_model; > PXA2xxState *cpu; > DriveInfo *dinfo; > int be; > diff --git a/hw/highbank.c b/hw/highbank.c > index 11aa131..15036b6 100644 > --- a/hw/highbank.c > +++ b/hw/highbank.c > @@ -187,11 +187,13 @@ static struct arm_boot_info highbank_binfo; > * 32-bit host, set the reg value of memory to 0xf7ff00000 in the > * device tree and pass -m 2047 to QEMU. > */ > -static void highbank_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void highbank_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > DeviceState *dev; > SysBusDevice *busdev; > qemu_irq *irqp; > diff --git a/hw/integratorcp.c b/hw/integratorcp.c > index d0e2e90..ac0ea83 100644 > --- a/hw/integratorcp.c > +++ b/hw/integratorcp.c > @@ -438,11 +438,13 @@ static struct arm_boot_info integrator_binfo = { > .board_id = 0x113, > }; > > -static void integratorcp_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void integratorcp_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > ARMCPU *cpu; > MemoryRegion *address_space_mem = get_system_memory(); > MemoryRegion *ram = g_new(MemoryRegion, 1); > diff --git a/hw/kzm.c b/hw/kzm.c > index 68cd1b4..d1266d9 100644 > --- a/hw/kzm.c > +++ b/hw/kzm.c > @@ -70,11 +70,13 @@ static struct arm_boot_info kzm_binfo = { > .board_id = 1722, > }; > > -static void kzm_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void kzm_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > ARMCPU *cpu; > MemoryRegion *address_space_mem = get_system_memory(); > MemoryRegion *ram = g_new(MemoryRegion, 1); > diff --git a/hw/leon3.c b/hw/leon3.c > index 878d3aa..6486b7b 100644 > --- a/hw/leon3.c > +++ b/hw/leon3.c > @@ -94,13 +94,11 @@ static void leon3_set_pil_in(void *opaque, uint32_t pil_in) > } > } > > -static void leon3_generic_hw_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, > - const char *cpu_model) > +static void leon3_generic_hw_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > SPARCCPU *cpu; > CPUSPARCState *env; > MemoryRegion *address_space_mem = get_system_memory(); > diff --git a/hw/lm32_boards.c b/hw/lm32_boards.c > index b76d800..c5a62c8 100644 > --- a/hw/lm32_boards.c > +++ b/hw/lm32_boards.c > @@ -69,12 +69,10 @@ static void main_cpu_reset(void *opaque) > env->deba = reset_info->flash_base; > } > > -static void lm32_evr_init(ram_addr_t ram_size_not_used, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void lm32_evr_init(QEMUMachineInitArgs *args) > { > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > LM32CPU *cpu; > CPULM32State *env; > DriveInfo *dinfo; > @@ -159,12 +157,12 @@ static void lm32_evr_init(ram_addr_t ram_size_not_used, > qemu_register_reset(main_cpu_reset, reset_info); > } > > -static void lm32_uclinux_init(ram_addr_t ram_size_not_used, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void lm32_uclinux_init(QEMUMachineInitArgs *args) > { > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > LM32CPU *cpu; > CPULM32State *env; > DriveInfo *dinfo; > diff --git a/hw/mainstone.c b/hw/mainstone.c > index 97687b6..c0d6034 100644 > --- a/hw/mainstone.c > +++ b/hw/mainstone.c > @@ -171,11 +171,13 @@ static void mainstone_common_init(MemoryRegion *address_space_mem, > arm_load_kernel(mpu->cpu, &mainstone_binfo); > } > > -static void mainstone_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void mainstone_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > mainstone_common_init(get_system_memory(), ram_size, kernel_filename, > kernel_cmdline, initrd_filename, cpu_model, mainstone, 0x196); > } > diff --git a/hw/mcf5208.c b/hw/mcf5208.c > index ee25b1b..688bc3c 100644 > --- a/hw/mcf5208.c > +++ b/hw/mcf5208.c > @@ -187,11 +187,11 @@ static void mcf5208_sys_init(MemoryRegion *address_space, qemu_irq *pic) > } > } > > -static void mcf5208evb_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void mcf5208evb_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > CPUM68KState *env; > int kernel_size; > uint64_t elf_entry; > diff --git a/hw/milkymist.c b/hw/milkymist.c > index 2e7235b..ca9ed43 100644 > --- a/hw/milkymist.c > +++ b/hw/milkymist.c > @@ -73,12 +73,12 @@ static void main_cpu_reset(void *opaque) > } > > static void > -milkymist_init(ram_addr_t ram_size_not_used, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +milkymist_init(QEMUMachineInitArgs *args) > { > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > LM32CPU *cpu; > CPULM32State *env; > int kernel_size; > diff --git a/hw/mips_fulong2e.c b/hw/mips_fulong2e.c > index 38e4b86..af7bb50 100644 > --- a/hw/mips_fulong2e.c > +++ b/hw/mips_fulong2e.c > @@ -256,10 +256,13 @@ static void cpu_request_exit(void *opaque, int irq, int level) > } > } > > -static void mips_fulong2e_init(ram_addr_t ram_size, const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void mips_fulong2e_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > char *filename; > MemoryRegion *address_space_mem = get_system_memory(); > MemoryRegion *ram = g_new(MemoryRegion, 1); > diff --git a/hw/mips_jazz.c b/hw/mips_jazz.c > index db927f1..14df4d7 100644 > --- a/hw/mips_jazz.c > +++ b/hw/mips_jazz.c > @@ -302,21 +302,19 @@ static void mips_jazz_init(MemoryRegion *address_space, > } > > static > -void mips_magnum_init (ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +void mips_magnum_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > mips_jazz_init(get_system_memory(), get_system_io(), > ram_size, cpu_model, JAZZ_MAGNUM); > } > > static > -void mips_pica61_init (ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +void mips_pica61_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > mips_jazz_init(get_system_memory(), get_system_io(), > ram_size, cpu_model, JAZZ_PICA61); > } > diff --git a/hw/mips_malta.c b/hw/mips_malta.c > index ad23f26..14151f9 100644 > --- a/hw/mips_malta.c > +++ b/hw/mips_malta.c > @@ -777,11 +777,13 @@ static void cpu_request_exit(void *opaque, int irq, int level) > } > > static > -void mips_malta_init (ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +void mips_malta_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > char *filename; > pflash_t *fl; > MemoryRegion *system_memory = get_system_memory(); > diff --git a/hw/mips_mipssim.c b/hw/mips_mipssim.c > index 830f635..a1d3945 100644 > --- a/hw/mips_mipssim.c > +++ b/hw/mips_mipssim.c > @@ -131,11 +131,13 @@ static void mipsnet_init(int base, qemu_irq irq, NICInfo *nd) > } > > static void > -mips_mipssim_init (ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +mips_mipssim_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > char *filename; > MemoryRegion *address_space_mem = get_system_memory(); > MemoryRegion *ram = g_new(MemoryRegion, 1); > diff --git a/hw/mips_r4k.c b/hw/mips_r4k.c > index 967a76e..b73cdc3 100644 > --- a/hw/mips_r4k.c > +++ b/hw/mips_r4k.c > @@ -151,11 +151,13 @@ static void main_cpu_reset(void *opaque) > > static const int sector_len = 32 * 1024; > static > -void mips_r4k_init (ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +void mips_r4k_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > char *filename; > MemoryRegion *address_space_mem = get_system_memory(); > MemoryRegion *ram = g_new(MemoryRegion, 1); > diff --git a/hw/musicpal.c b/hw/musicpal.c > index f305e21..f06814c 100644 > --- a/hw/musicpal.c > +++ b/hw/musicpal.c > @@ -1508,11 +1508,12 @@ static struct arm_boot_info musicpal_binfo = { > .board_id = 0x20e, > }; > > -static void musicpal_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void musicpal_init(QEMUMachineInitArgs *args) > { > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > ARMCPU *cpu; > qemu_irq *cpu_pic; > qemu_irq pic[32]; > diff --git a/hw/nseries.c b/hw/nseries.c > index 6df71eb..7ada90d 100644 > --- a/hw/nseries.c > +++ b/hw/nseries.c > @@ -1397,21 +1397,27 @@ static struct arm_boot_info n810_binfo = { > .atag_board = n810_atag_setup, > }; > > -static void n800_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void n800_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > return n8x0_init(ram_size, boot_device, > kernel_filename, kernel_cmdline, initrd_filename, > cpu_model, &n800_binfo, 800); > } > > -static void n810_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void n810_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > return n8x0_init(ram_size, boot_device, > kernel_filename, kernel_cmdline, initrd_filename, > cpu_model, &n810_binfo, 810); > diff --git a/hw/null-machine.c b/hw/null-machine.c > index 69910d3..d813c08 100644 > --- a/hw/null-machine.c > +++ b/hw/null-machine.c > @@ -15,12 +15,7 @@ > #include "hw/hw.h" > #include "hw/boards.h" > > -static void machine_none_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, > - const char *cpu_model) > +static void machine_none_init(QEMUMachineInitArgs *args) > { > } > > diff --git a/hw/omap_sx1.c b/hw/omap_sx1.c > index abca341..ad17487 100644 > --- a/hw/omap_sx1.c > +++ b/hw/omap_sx1.c > @@ -209,20 +209,26 @@ static void sx1_init(ram_addr_t ram_size, > //~ qemu_console_resize(ds, 640, 480); > } > > -static void sx1_init_v1(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void sx1_init_v1(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > sx1_init(ram_size, boot_device, kernel_filename, > kernel_cmdline, initrd_filename, cpu_model, 1); > } > > -static void sx1_init_v2(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void sx1_init_v2(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > sx1_init(ram_size, boot_device, kernel_filename, > kernel_cmdline, initrd_filename, cpu_model, 2); > } > diff --git a/hw/openrisc_sim.c b/hw/openrisc_sim.c > index 55e97f0..e96a944 100644 > --- a/hw/openrisc_sim.c > +++ b/hw/openrisc_sim.c > @@ -90,13 +90,11 @@ static void cpu_openrisc_load_kernel(ram_addr_t ram_size, > cpu->env.pc = entry; > } > > -static void openrisc_sim_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, > - const char *cpu_model) > +static void openrisc_sim_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > OpenRISCCPU *cpu = NULL; > MemoryRegion *ram; > int n; > diff --git a/hw/palm.c b/hw/palm.c > index bacdc90..032b8d6 100644 > --- a/hw/palm.c > +++ b/hw/palm.c > @@ -190,11 +190,12 @@ static struct arm_boot_info palmte_binfo = { > .board_id = 0x331, > }; > > -static void palmte_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void palmte_init(QEMUMachineInitArgs *args) > { > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > MemoryRegion *address_space_mem = get_system_memory(); > struct omap_mpu_state_s *mpu; > int flash_size = 0x00800000; > diff --git a/hw/pc_piix.c b/hw/pc_piix.c > index fd5898f..9efc822 100644 > --- a/hw/pc_piix.c > +++ b/hw/pc_piix.c > @@ -287,13 +287,14 @@ static void pc_init1(MemoryRegion *system_memory, > } > } > > -static void pc_init_pci(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, > - const char *cpu_model) > +static void pc_init_pci(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > pc_init1(get_system_memory(), > get_system_io(), > ram_size, boot_device, > @@ -301,13 +302,14 @@ static void pc_init_pci(ram_addr_t ram_size, > initrd_filename, cpu_model, 1, 1); > } > > -static void pc_init_pci_no_kvmclock(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, > - const char *cpu_model) > +static void pc_init_pci_no_kvmclock(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > pc_init1(get_system_memory(), > get_system_io(), > ram_size, boot_device, > @@ -315,13 +317,14 @@ static void pc_init_pci_no_kvmclock(ram_addr_t ram_size, > initrd_filename, cpu_model, 1, 0); > } > > -static void pc_init_isa(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, > - const char *cpu_model) > +static void pc_init_isa(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > if (cpu_model == NULL) > cpu_model = "486"; > pc_init1(get_system_memory(), > @@ -332,7 +335,8 @@ static void pc_init_isa(ram_addr_t ram_size, > } > > #ifdef CONFIG_XEN > -static void pc_xen_hvm_init(ram_addr_t ram_size, > +static void pc_xen_hvm_init(QEMUMachine *machine, > + ram_addr_t ram_size, > const char *boot_device, > const char *kernel_filename, > const char *kernel_cmdline, > diff --git a/hw/petalogix_ml605_mmu.c b/hw/petalogix_ml605_mmu.c > index dced648..ace0187 100644 > --- a/hw/petalogix_ml605_mmu.c > +++ b/hw/petalogix_ml605_mmu.c > @@ -70,12 +70,10 @@ static void machine_cpu_reset(MicroBlazeCPU *cpu) > } > > static void > -petalogix_ml605_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +petalogix_ml605_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > MemoryRegion *address_space_mem = get_system_memory(); > DeviceState *dev, *dma, *eth0; > MicroBlazeCPU *cpu; > diff --git a/hw/petalogix_s3adsp1800_mmu.c b/hw/petalogix_s3adsp1800_mmu.c > index 2cf6882..71c32ce 100644 > --- a/hw/petalogix_s3adsp1800_mmu.c > +++ b/hw/petalogix_s3adsp1800_mmu.c > @@ -57,12 +57,10 @@ static void machine_cpu_reset(MicroBlazeCPU *cpu) > } > > static void > -petalogix_s3adsp1800_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +petalogix_s3adsp1800_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > DeviceState *dev; > MicroBlazeCPU *cpu; > CPUMBState *env; > diff --git a/hw/ppc/e500plat.c b/hw/ppc/e500plat.c > index 60a5cb3..4cfb940 100644 > --- a/hw/ppc/e500plat.c > +++ b/hw/ppc/e500plat.c > @@ -25,13 +25,14 @@ static void e500plat_fixup_devtree(PPCE500Params *params, void *fdt) > sizeof(compatible)); > } > > -static void e500plat_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, > - const char *cpu_model) > +static void e500plat_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *boot_device = args->boot_device; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > PPCE500Params params = { > .ram_size = ram_size, > .boot_device = boot_device, > diff --git a/hw/ppc/mpc8544ds.c b/hw/ppc/mpc8544ds.c > index 984d21c..e651661 100644 > --- a/hw/ppc/mpc8544ds.c > +++ b/hw/ppc/mpc8544ds.c > @@ -25,13 +25,14 @@ static void mpc8544ds_fixup_devtree(PPCE500Params *params, void *fdt) > sizeof(compatible)); > } > > -static void mpc8544ds_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, > - const char *cpu_model) > +static void mpc8544ds_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *boot_device = args->boot_device; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > PPCE500Params params = { > .ram_size = ram_size, > .boot_device = boot_device, > diff --git a/hw/ppc405_boards.c b/hw/ppc405_boards.c > index 476775d..e848cb0 100644 > --- a/hw/ppc405_boards.c > +++ b/hw/ppc405_boards.c > @@ -158,7 +158,7 @@ static void ref405ep_fpga_reset (void *opaque) > fpga->reg1 = 0x0F; > } > > -static void ref405ep_fpga_init (MemoryRegion *sysmem, uint32_t base) > +static void ref405ep_fpga_init(MemoryRegion *sysmem, uint32_t base) > { > ref405ep_fpga_t *fpga; > MemoryRegion *fpga_memory = g_new(MemoryRegion, 1); > @@ -170,13 +170,12 @@ static void ref405ep_fpga_init (MemoryRegion *sysmem, uint32_t base) > qemu_register_reset(&ref405ep_fpga_reset, fpga); > } > > -static void ref405ep_init (ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, > - const char *cpu_model) > +static void ref405ep_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > char *filename; > ppc4xx_bd_info_t bd; > CPUPPCState *env; > @@ -484,7 +483,7 @@ static void taihu_cpld_reset (void *opaque) > cpld->reg1 = 0x80; > } > > -static void taihu_cpld_init (MemoryRegion *sysmem, uint32_t base) > +static void taihu_cpld_init(MemoryRegion *sysmem, uint32_t base) > { > taihu_cpld_t *cpld; > MemoryRegion *cpld_memory = g_new(MemoryRegion, 1); > @@ -495,13 +494,11 @@ static void taihu_cpld_init (MemoryRegion *sysmem, uint32_t base) > qemu_register_reset(&taihu_cpld_reset, cpld); > } > > -static void taihu_405ep_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, > - const char *cpu_model) > +static void taihu_405ep_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *kernel_filename = args->kernel_filename; > + const char *initrd_filename = args->initrd_filename; > char *filename; > qemu_irq *pic; > MemoryRegion *sysmem = get_system_memory(); > diff --git a/hw/ppc440_bamboo.c b/hw/ppc440_bamboo.c > index c198071..78e7985 100644 > --- a/hw/ppc440_bamboo.c > +++ b/hw/ppc440_bamboo.c > @@ -157,13 +157,13 @@ static void main_cpu_reset(void *opaque) > mmubooke_create_initial_mapping(env, 0, 0); > } > > -static void bamboo_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, > - const char *cpu_model) > +static void bamboo_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > unsigned int pci_irq_nrs[4] = { 28, 27, 26, 25 }; > MemoryRegion *address_space_mem = get_system_memory(); > MemoryRegion *ram_memories > diff --git a/hw/ppc_newworld.c b/hw/ppc_newworld.c > index e95cfe8..e7c0747 100644 > --- a/hw/ppc_newworld.c > +++ b/hw/ppc_newworld.c > @@ -129,13 +129,14 @@ static void ppc_core99_reset(void *opaque) > } > > /* PowerPC Mac99 hardware initialisation */ > -static void ppc_core99_init (ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, > - const char *cpu_model) > +static void ppc_core99_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > PowerPCCPU *cpu = NULL; > CPUPPCState *env = NULL; > char *filename; > diff --git a/hw/ppc_oldworld.c b/hw/ppc_oldworld.c > index 1dcd8a6..d9f76a8 100644 > --- a/hw/ppc_oldworld.c > +++ b/hw/ppc_oldworld.c > @@ -72,13 +72,14 @@ static void ppc_heathrow_reset(void *opaque) > cpu_reset(CPU(cpu)); > } > > -static void ppc_heathrow_init (ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, > - const char *cpu_model) > +static void ppc_heathrow_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > MemoryRegion *sysmem = get_system_memory(); > PowerPCCPU *cpu = NULL; > CPUPPCState *env = NULL; > diff --git a/hw/ppc_prep.c b/hw/ppc_prep.c > index 592b7b2..f51f78a 100644 > --- a/hw/ppc_prep.c > +++ b/hw/ppc_prep.c > @@ -448,13 +448,14 @@ static void ppc_prep_reset(void *opaque) > } > > /* PowerPC PREP hardware initialisation */ > -static void ppc_prep_init (ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, > - const char *cpu_model) > +static void ppc_prep_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > MemoryRegion *sysmem = get_system_memory(); > PowerPCCPU *cpu = NULL; > CPUPPCState *env = NULL; > diff --git a/hw/puv3.c b/hw/puv3.c > index 43f7216..764799c 100644 > --- a/hw/puv3.c > +++ b/hw/puv3.c > @@ -91,10 +91,12 @@ static void puv3_load_kernel(const char *kernel_filename) > graphic_console_init(NULL, NULL, NULL, NULL, NULL); > } > > -static void puv3_init(ram_addr_t ram_size, const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void puv3_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *initrd_filename = args->initrd_filename; > CPUUniCore32State *env; > > if (initrd_filename) { > diff --git a/hw/r2d.c b/hw/r2d.c > index 0f16e81..5daa42f 100644 > --- a/hw/r2d.c > +++ b/hw/r2d.c > @@ -219,11 +219,12 @@ static struct QEMU_PACKED > char kernel_cmdline[256]; > } boot_params; > > -static void r2d_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void r2d_init(QEMUMachineInitArgs *args) > { > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > SuperHCPU *cpu; > CPUSH4State *env; > ResetData *reset_info; > diff --git a/hw/realview.c b/hw/realview.c > index 19db4d0..8dc4be6 100644 > --- a/hw/realview.c > +++ b/hw/realview.c > @@ -330,11 +330,14 @@ static void realview_init(ram_addr_t ram_size, > arm_load_kernel(arm_env_get_cpu(first_cpu), &realview_binfo); > } > > -static void realview_eb_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void realview_eb_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > if (!cpu_model) { > cpu_model = "arm926"; > } > @@ -342,11 +345,14 @@ static void realview_eb_init(ram_addr_t ram_size, > initrd_filename, cpu_model, BOARD_EB); > } > > -static void realview_eb_mpcore_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void realview_eb_mpcore_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > if (!cpu_model) { > cpu_model = "arm11mpcore"; > } > @@ -354,11 +360,14 @@ static void realview_eb_mpcore_init(ram_addr_t ram_size, > initrd_filename, cpu_model, BOARD_EB_MPCORE); > } > > -static void realview_pb_a8_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void realview_pb_a8_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > if (!cpu_model) { > cpu_model = "cortex-a8"; > } > @@ -366,11 +375,14 @@ static void realview_pb_a8_init(ram_addr_t ram_size, > initrd_filename, cpu_model, BOARD_PB_A8); > } > > -static void realview_pbx_a9_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void realview_pbx_a9_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > if (!cpu_model) { > cpu_model = "cortex-a9"; > } > diff --git a/hw/s390-virtio.c b/hw/s390-virtio.c > index 47eed35..39ff178 100644 > --- a/hw/s390-virtio.c > +++ b/hw/s390-virtio.c > @@ -151,13 +151,14 @@ unsigned s390_del_running_cpu(CPUS390XState *env) > } > > /* PC hardware initialisation */ > -static void s390_init(ram_addr_t my_ram_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, > - const char *cpu_model) > +static void s390_init(QEMUMachineInitArgs *args) > { > + ram_addr_t my_ram_size = args->ram_size; > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > CPUS390XState *env = NULL; > MemoryRegion *sysmem = get_system_memory(); > MemoryRegion *ram = g_new(MemoryRegion, 1); > diff --git a/hw/shix.c b/hw/shix.c > index dd9ce17..b56dd54 100644 > --- a/hw/shix.c > +++ b/hw/shix.c > @@ -37,11 +37,9 @@ > #define BIOS_FILENAME "shix_bios.bin" > #define BIOS_ADDRESS 0xA0000000 > > -static void shix_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void shix_init(QEMUMachineInitArgs *args) > { > + const char *cpu_model = args->cpu_model; > int ret; > CPUSH4State *env; > struct SH7750State *s; > diff --git a/hw/spapr.c b/hw/spapr.c > index c34b767..8921c4d 100644 > --- a/hw/spapr.c > +++ b/hw/spapr.c > @@ -603,13 +603,14 @@ static int spapr_vga_init(PCIBus *pci_bus) > } > > /* pSeries LPAR / sPAPR hardware init */ > -static void ppc_spapr_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, > - const char *cpu_model) > +static void ppc_spapr_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > PowerPCCPU *cpu; > CPUPPCState *env; > PCIHostState *phb; > diff --git a/hw/spitz.c b/hw/spitz.c > index 20e7835..df829b3 100644 > --- a/hw/spitz.c > +++ b/hw/spitz.c > @@ -936,38 +936,46 @@ static void spitz_common_init(ram_addr_t ram_size, > sl_bootparam_write(SL_PXA_PARAM_BASE); > } > > -static void spitz_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void spitz_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > spitz_common_init(ram_size, kernel_filename, > kernel_cmdline, initrd_filename, cpu_model, spitz, 0x2c9); > } > > -static void borzoi_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void borzoi_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > spitz_common_init(ram_size, kernel_filename, > kernel_cmdline, initrd_filename, cpu_model, borzoi, 0x33f); > } > > -static void akita_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void akita_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > spitz_common_init(ram_size, kernel_filename, > kernel_cmdline, initrd_filename, cpu_model, akita, 0x2e8); > } > > -static void terrier_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void terrier_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > spitz_common_init(ram_size, kernel_filename, > kernel_cmdline, initrd_filename, cpu_model, terrier, 0x33f); > } > diff --git a/hw/stellaris.c b/hw/stellaris.c > index 562fbbf..b79c7fb 100644 > --- a/hw/stellaris.c > +++ b/hw/stellaris.c > @@ -1358,19 +1358,17 @@ static void stellaris_init(const char *kernel_filename, const char *cpu_model, > } > > /* FIXME: Figure out how to generate these from stellaris_boards. */ > -static void lm3s811evb_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void lm3s811evb_init(QEMUMachineInitArgs *args) > { > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > stellaris_init(kernel_filename, cpu_model, &stellaris_boards[0]); > } > > -static void lm3s6965evb_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void lm3s6965evb_init(QEMUMachineInitArgs *args) > { > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > stellaris_init(kernel_filename, cpu_model, &stellaris_boards[1]); > } > > diff --git a/hw/sun4m.c b/hw/sun4m.c > index c98cd5e..22e011f 100644 > --- a/hw/sun4m.c > +++ b/hw/sun4m.c > @@ -1303,92 +1303,118 @@ static const struct sun4m_hwdef sun4m_hwdefs[] = { > }; > > /* SPARCstation 5 hardware initialisation */ > -static void ss5_init(ram_addr_t RAM_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void ss5_init(QEMUMachineInitArgs *args) > { > + ram_addr_t RAM_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > sun4m_hw_init(&sun4m_hwdefs[0], RAM_size, boot_device, kernel_filename, > kernel_cmdline, initrd_filename, cpu_model); > } > > /* SPARCstation 10 hardware initialisation */ > -static void ss10_init(ram_addr_t RAM_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void ss10_init(QEMUMachineInitArgs *args) > { > + ram_addr_t RAM_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > sun4m_hw_init(&sun4m_hwdefs[1], RAM_size, boot_device, kernel_filename, > kernel_cmdline, initrd_filename, cpu_model); > } > > /* SPARCserver 600MP hardware initialisation */ > -static void ss600mp_init(ram_addr_t RAM_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void ss600mp_init(QEMUMachineInitArgs *args) > { > + ram_addr_t RAM_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > sun4m_hw_init(&sun4m_hwdefs[2], RAM_size, boot_device, kernel_filename, > kernel_cmdline, initrd_filename, cpu_model); > } > > /* SPARCstation 20 hardware initialisation */ > -static void ss20_init(ram_addr_t RAM_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void ss20_init(QEMUMachineInitArgs *args) > { > + ram_addr_t RAM_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > sun4m_hw_init(&sun4m_hwdefs[3], RAM_size, boot_device, kernel_filename, > kernel_cmdline, initrd_filename, cpu_model); > } > > /* SPARCstation Voyager hardware initialisation */ > -static void vger_init(ram_addr_t RAM_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void vger_init(QEMUMachineInitArgs *args) > { > + ram_addr_t RAM_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > sun4m_hw_init(&sun4m_hwdefs[4], RAM_size, boot_device, kernel_filename, > kernel_cmdline, initrd_filename, cpu_model); > } > > /* SPARCstation LX hardware initialisation */ > -static void ss_lx_init(ram_addr_t RAM_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void ss_lx_init(QEMUMachineInitArgs *args) > { > + ram_addr_t RAM_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > sun4m_hw_init(&sun4m_hwdefs[5], RAM_size, boot_device, kernel_filename, > kernel_cmdline, initrd_filename, cpu_model); > } > > /* SPARCstation 4 hardware initialisation */ > -static void ss4_init(ram_addr_t RAM_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void ss4_init(QEMUMachineInitArgs *args) > { > + ram_addr_t RAM_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > sun4m_hw_init(&sun4m_hwdefs[6], RAM_size, boot_device, kernel_filename, > kernel_cmdline, initrd_filename, cpu_model); > } > > /* SPARCClassic hardware initialisation */ > -static void scls_init(ram_addr_t RAM_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void scls_init(QEMUMachineInitArgs *args) > { > + ram_addr_t RAM_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > sun4m_hw_init(&sun4m_hwdefs[7], RAM_size, boot_device, kernel_filename, > kernel_cmdline, initrd_filename, cpu_model); > } > > /* SPARCbook hardware initialisation */ > -static void sbook_init(ram_addr_t RAM_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void sbook_init(QEMUMachineInitArgs *args) > { > + ram_addr_t RAM_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > sun4m_hw_init(&sun4m_hwdefs[8], RAM_size, boot_device, kernel_filename, > kernel_cmdline, initrd_filename, cpu_model); > } > @@ -1651,21 +1677,27 @@ static void sun4d_hw_init(const struct sun4d_hwdef *hwdef, ram_addr_t RAM_size, > } > > /* SPARCserver 1000 hardware initialisation */ > -static void ss1000_init(ram_addr_t RAM_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void ss1000_init(QEMUMachineInitArgs *args) > { > + ram_addr_t RAM_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > sun4d_hw_init(&sun4d_hwdefs[0], RAM_size, boot_device, kernel_filename, > kernel_cmdline, initrd_filename, cpu_model); > } > > /* SPARCcenter 2000 hardware initialisation */ > -static void ss2000_init(ram_addr_t RAM_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void ss2000_init(QEMUMachineInitArgs *args) > { > + ram_addr_t RAM_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > sun4d_hw_init(&sun4d_hwdefs[1], RAM_size, boot_device, kernel_filename, > kernel_cmdline, initrd_filename, cpu_model); > } > @@ -1845,11 +1877,14 @@ static void sun4c_hw_init(const struct sun4c_hwdef *hwdef, ram_addr_t RAM_size, > } > > /* SPARCstation 2 hardware initialisation */ > -static void ss2_init(ram_addr_t RAM_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void ss2_init(QEMUMachineInitArgs *args) > { > + ram_addr_t RAM_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > sun4c_hw_init(&sun4c_hwdefs[0], RAM_size, boot_device, kernel_filename, > kernel_cmdline, initrd_filename, cpu_model); > } > diff --git a/hw/sun4u.c b/hw/sun4u.c > index 07cd042..379768c 100644 > --- a/hw/sun4u.c > +++ b/hw/sun4u.c > @@ -930,31 +930,40 @@ static const struct hwdef hwdefs[] = { > }; > > /* Sun4u hardware initialisation */ > -static void sun4u_init(ram_addr_t RAM_size, > - const char *boot_devices, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > -{ > +static void sun4u_init(QEMUMachineInitArgs *args) > +{ > + ram_addr_t RAM_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_devices = args->boot_device; > sun4uv_init(get_system_memory(), RAM_size, boot_devices, kernel_filename, > kernel_cmdline, initrd_filename, cpu_model, &hwdefs[0]); > } > > /* Sun4v hardware initialisation */ > -static void sun4v_init(ram_addr_t RAM_size, > - const char *boot_devices, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > -{ > +static void sun4v_init(QEMUMachineInitArgs *args) > +{ > + ram_addr_t RAM_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_devices = args->boot_device; > sun4uv_init(get_system_memory(), RAM_size, boot_devices, kernel_filename, > kernel_cmdline, initrd_filename, cpu_model, &hwdefs[1]); > } > > /* Niagara hardware initialisation */ > -static void niagara_init(ram_addr_t RAM_size, > - const char *boot_devices, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > -{ > +static void niagara_init(QEMUMachineInitArgs *args) > +{ > + ram_addr_t RAM_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_devices = args->boot_device; > sun4uv_init(get_system_memory(), RAM_size, boot_devices, kernel_filename, > kernel_cmdline, initrd_filename, cpu_model, &hwdefs[2]); > } > diff --git a/hw/tosa.c b/hw/tosa.c > index 297a8c2..512278c 100644 > --- a/hw/tosa.c > +++ b/hw/tosa.c > @@ -205,11 +205,12 @@ static struct arm_boot_info tosa_binfo = { > .ram_size = 0x04000000, > }; > > -static void tosa_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void tosa_init(QEMUMachineInitArgs *args) > { > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > MemoryRegion *address_space_mem = get_system_memory(); > MemoryRegion *rom = g_new(MemoryRegion, 1); > PXA2xxState *mpu; > diff --git a/hw/versatilepb.c b/hw/versatilepb.c > index 7a92034..686dcc7 100644 > --- a/hw/versatilepb.c > +++ b/hw/versatilepb.c > @@ -342,22 +342,28 @@ static void versatile_init(ram_addr_t ram_size, > arm_load_kernel(cpu, &versatile_binfo); > } > > -static void vpb_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void vpb_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > versatile_init(ram_size, > boot_device, > kernel_filename, kernel_cmdline, > initrd_filename, cpu_model, 0x183); > } > > -static void vab_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void vab_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > versatile_init(ram_size, > boot_device, > kernel_filename, kernel_cmdline, > diff --git a/hw/vexpress.c b/hw/vexpress.c > index 3596d1e..36503d6 100644 > --- a/hw/vexpress.c > +++ b/hw/vexpress.c > @@ -467,25 +467,27 @@ static void vexpress_common_init(const VEDBoardInfo *daughterboard, > arm_load_kernel(arm_env_get_cpu(first_cpu), &vexpress_binfo); > } > > -static void vexpress_a9_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, > - const char *cpu_model) > +static void vexpress_a9_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > vexpress_common_init(&a9_daughterboard, > ram_size, boot_device, kernel_filename, > kernel_cmdline, initrd_filename, cpu_model); > } > > -static void vexpress_a15_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, > - const char *cpu_model) > +static void vexpress_a15_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > vexpress_common_init(&a15_daughterboard, > ram_size, boot_device, kernel_filename, > kernel_cmdline, initrd_filename, cpu_model); > diff --git a/hw/virtex_ml507.c b/hw/virtex_ml507.c > index 79bc0d1..a09b27a 100644 > --- a/hw/virtex_ml507.c > +++ b/hw/virtex_ml507.c > @@ -183,12 +183,12 @@ static int xilinx_load_device_tree(target_phys_addr_t addr, > return fdt_size; > } > > -static void virtex_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void virtex_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > MemoryRegion *address_space_mem = get_system_memory(); > DeviceState *dev; > PowerPCCPU *cpu; > diff --git a/hw/xen_machine_pv.c b/hw/xen_machine_pv.c > index 4b72aa7..1ac9990 100644 > --- a/hw/xen_machine_pv.c > +++ b/hw/xen_machine_pv.c > @@ -29,12 +29,13 @@ > #include "xen_domainbuild.h" > #include "blockdev.h" > > -static void xen_init_pv(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, > - const char *cpu_model) > +static void xen_init_pv(QEMUMachine *machine, > + ram_addr_t ram_size, > + const char *boot_device, > + const char *kernel_filename, > + const char *kernel_cmdline, > + const char *initrd_filename, > + const char *cpu_model) > { > X86CPU *cpu; > CPUX86State *env; > diff --git a/hw/xilinx_zynq.c b/hw/xilinx_zynq.c > index 7e6c273..83f322e 100644 > --- a/hw/xilinx_zynq.c > +++ b/hw/xilinx_zynq.c > @@ -46,10 +46,13 @@ static void gem_init(NICInfo *nd, uint32_t base, qemu_irq irq) > sysbus_connect_irq(s, 0, irq); > } > > -static void zynq_init(ram_addr_t ram_size, const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void zynq_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > ARMCPU *cpu; > MemoryRegion *address_space_mem = get_system_memory(); > MemoryRegion *ext_ram = g_new(MemoryRegion, 1); > diff --git a/hw/xtensa_lx60.c b/hw/xtensa_lx60.c > index 3653f65..1fd2c47 100644 > --- a/hw/xtensa_lx60.c > +++ b/hw/xtensa_lx60.c > @@ -268,11 +268,14 @@ static void lx_init(const LxBoardDesc *board, > } > } > > -static void xtensa_lx60_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void xtensa_lx60_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > static const LxBoardDesc lx60_board = { > .flash_size = 0x400000, > .flash_sector_size = 0x10000, > @@ -283,11 +286,14 @@ static void xtensa_lx60_init(ram_addr_t ram_size, > initrd_filename, cpu_model); > } > > -static void xtensa_lx200_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void xtensa_lx200_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > static const LxBoardDesc lx200_board = { > .flash_size = 0x1000000, > .flash_sector_size = 0x20000, > diff --git a/hw/xtensa_sim.c b/hw/xtensa_sim.c > index 831460b..2e846d8 100644 > --- a/hw/xtensa_sim.c > +++ b/hw/xtensa_sim.c > @@ -96,11 +96,14 @@ static void sim_init(ram_addr_t ram_size, > } > } > > -static void xtensa_sim_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void xtensa_sim_init(QEMUMachineInitArgs *args) > { > + ram_addr_t ram_size = args->ram_size; > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > + const char *boot_device = args->boot_device; > if (!cpu_model) { > cpu_model = XTENSA_DEFAULT_CPU_MODEL; > } > diff --git a/hw/z2.c b/hw/z2.c > index 289cee9..0927bad 100644 > --- a/hw/z2.c > +++ b/hw/z2.c > @@ -294,11 +294,12 @@ static TypeInfo aer915_info = { > .class_init = aer915_class_init, > }; > > -static void z2_init(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, const char *kernel_cmdline, > - const char *initrd_filename, const char *cpu_model) > +static void z2_init(QEMUMachineInitArgs *args) > { > + const char *cpu_model = args->cpu_model; > + const char *kernel_filename = args->kernel_filename; > + const char *kernel_cmdline = args->kernel_cmdline; > + const char *initrd_filename = args->initrd_filename; > MemoryRegion *address_space_mem = get_system_memory(); > uint32_t sector_len = 0x10000; > PXA2xxState *mpu; > diff --git a/vl.c b/vl.c > index 8d305ca..f663e7c 100644 > --- a/vl.c > +++ b/vl.c > @@ -3624,8 +3624,13 @@ int main(int argc, char **argv, char **envp) > > qdev_machine_init(); > > - machine->init(ram_size, boot_devices, > - kernel_filename, kernel_cmdline, initrd_filename, cpu_model); > + QEMUMachineInitArgs args = { .ram_size = ram_size, > + .boot_device = boot_devices, > + .kernel_filename = kernel_filename, > + .kernel_cmdline = kernel_cmdline, > + initrd_filename = initrd_filename, > + .cpu_model = cpu_model }; > + machine->init(&args); > > cpu_synchronize_all_post_init(); > > -- > 1.7.11.4 > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 18:58:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 18:58:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKD5z-0004wn-Sw; Fri, 05 Oct 2012 18:57:59 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKD5x-0004wf-RM; Fri, 05 Oct 2012 18:57:58 +0000 X-Env-Sender: singapore.mr.teo.en.ming@gmail.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1349463469!1780341!1 X-Originating-IP: [209.85.220.45] X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG, HTML_30_40, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15187 invoked from network); 5 Oct 2012 18:57:51 -0000 Received: from mail-pa0-f45.google.com (HELO mail-pa0-f45.google.com) (209.85.220.45) by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 18:57:51 -0000 Received: by mail-pa0-f45.google.com with SMTP id fb10so2155121pad.32 for ; Fri, 05 Oct 2012 11:57:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type; bh=RkbrNC1pvywwG5m2uhNsRKVPCuyqtDCwbuXK1XnefGc=; b=HWy9eSgOMyu0SvedTk4kXmOo8qLxlVJ62EI6430AV5RhUvGvCRMlyA1WdJnSEMzLSp bqYHx5fDfNNK55bBkviXlEqX7MILngEUBgAdjyE83Fvzq1LpqhWA5rDrc2mOTL5W0ZMf wJgK9+XqFhggut5VwHUkVN4uL/hpIpxCKc/Qyto5UjHCeYTmvPcCbCI8fdt0KoTemV7Z xQedDt7jLKMIIKsDXOOjR0Otnfs5Hh/kUaDObZbNZVCmVmDGbNmLowdU2E4yvHIiNduy /ajloYu4O3kRPSubBMlLkZK2Hsds+bXDZR9vBrqABK0NwSdA+fIDGRJsYK9ORKXs41VC 0BwA== Received: by 10.68.130.194 with SMTP id og2mr33042881pbb.131.1349463469125; Fri, 05 Oct 2012 11:57:49 -0700 (PDT) Received: from [192.168.1.2] (cm152.gamma205.maxonline.com.sg. [202.156.205.152]) by mx.google.com with ESMTPS id m5sm6413174pax.10.2012.10.05.11.57.46 (version=SSLv3 cipher=OTHER); Fri, 05 Oct 2012 11:57:48 -0700 (PDT) Message-ID: <506F2DA8.5070803@gmail.com> Date: Sat, 06 Oct 2012 02:57:44 +0800 From: "Teo En Ming (Zhang Enming)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Teo En Ming (Zhang Enming)" References: <506E8BFD.9080504@gmail.com> <506F064F.9010705@gmail.com> In-Reply-To: <506F064F.9010705@gmail.com> Cc: "xen-users@lists.xen.org" , "xen-devel@lists.xen.org" , Dariusz Krempa Subject: Re: [Xen-devel] Help Needed from Xen Developers: Nasty Yellow Triangle with Exclamation Mark and Error Code 43 in Device Manager in Windows 8 HVM domU X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7643307461304818022==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a multi-part message in MIME format. --===============7643307461304818022== Content-Type: multipart/alternative; boundary="------------090709020405090203010303" This is a multi-part message in MIME format. --------------090709020405090203010303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 06/10/2012 00:09, Teo En Ming (Zhang Enming) wrote: > On 05/10/2012 16:05, Dariusz Krempa wrote: >> I'm afraid it is not possible to do this in this configuration. >> Nvidia does not support virtualization for geforce cards and their >> drivers have problems in windows 7, windows 8, vista, server 2008 >> etc. We can easy setup virtual machine on windows xp but only with >> drivers less than 280.xx and I did some trick (with a huge amount of >> luck) that I setup windows 7, but first drivers for windows 8 are >> 295.73. I think we will need to wait for different patch for xen to >> do this. >> If You will study device manager under windows 7 or 8 with view set >> on then You can see that windows do not recognize properly this >> memory range: >> mem 0xf4000000-0xf5ffffff >> and this is the only range which isn't set in xen patch. Of course I >> will try to work with windows 8 for a while but like I said, I'm >> afraid this will not work in this moment. > > Dear Dariusz Krempa, > > Even with Windows XP Home Edition SP3 HVM domU, I also get the nasty > yellow triangle with exclamation mark and error code 43. > Dear Dariusz Krempa, Correction: I have just tried it. Even with Windows XP Home Edition SP3 HVM domU and NVIDIA driver version 275.33, I still get the nasty yellow _circle_ with exclamation mark and error code 10. I am simply wondering. What is wrong? -- Yours sincerely, Mr. Teo En Ming (Zhang Enming) Singapore --------------090709020405090203010303 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 06/10/2012 00:09, Teo En Ming (Zhang Enming) wrote:
On 05/10/2012 16:05, Dariusz Krempa wrote:
I'm afraid it is not possible to do this in this configuration. Nvidia does not support virtualization for geforce cards and their drivers have problems in windows 7, windows 8, vista, server 2008 etc. We can easy setup virtual machine on windows xp but only with drivers less than 280.xx and I did some trick (with a huge amount of luck) that I setup windows 7, but first drivers for windows 8 are 295.73. I think we will need to wait for different patch for xen to do this.
If You will study device manager under windows 7 or 8 with view set on  then You can see that windows do not recognize properly this memory range:
mem 0xf4000000-0xf5ffffff
and this is the only range which isn't set in xen patch. Of course I will try to work with windows 8 for a while but like I said, I'm afraid this will not work in this moment.

Dear Dariusz Krempa,

Even with Windows XP Home Edition SP3 HVM domU, I also get the nasty yellow triangle with exclamation mark and error code 43.


Dear Dariusz Krempa,

Correction: I have just tried it. Even with Windows XP Home Edition SP3 HVM domU and NVIDIA driver version 275.33, I still get the nasty yellow circle with exclamation mark and error code 10.

I am simply wondering. What is wrong?
-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore
--------------090709020405090203010303-- --===============7643307461304818022== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============7643307461304818022==-- From xen-devel-bounces@lists.xen.org Fri Oct 05 18:58:16 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 18:58:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKD5z-0004wn-Sw; Fri, 05 Oct 2012 18:57:59 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKD5x-0004wf-RM; Fri, 05 Oct 2012 18:57:58 +0000 X-Env-Sender: singapore.mr.teo.en.ming@gmail.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1349463469!1780341!1 X-Originating-IP: [209.85.220.45] X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG, HTML_30_40, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15187 invoked from network); 5 Oct 2012 18:57:51 -0000 Received: from mail-pa0-f45.google.com (HELO mail-pa0-f45.google.com) (209.85.220.45) by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 18:57:51 -0000 Received: by mail-pa0-f45.google.com with SMTP id fb10so2155121pad.32 for ; Fri, 05 Oct 2012 11:57:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type; bh=RkbrNC1pvywwG5m2uhNsRKVPCuyqtDCwbuXK1XnefGc=; b=HWy9eSgOMyu0SvedTk4kXmOo8qLxlVJ62EI6430AV5RhUvGvCRMlyA1WdJnSEMzLSp bqYHx5fDfNNK55bBkviXlEqX7MILngEUBgAdjyE83Fvzq1LpqhWA5rDrc2mOTL5W0ZMf wJgK9+XqFhggut5VwHUkVN4uL/hpIpxCKc/Qyto5UjHCeYTmvPcCbCI8fdt0KoTemV7Z xQedDt7jLKMIIKsDXOOjR0Otnfs5Hh/kUaDObZbNZVCmVmDGbNmLowdU2E4yvHIiNduy /ajloYu4O3kRPSubBMlLkZK2Hsds+bXDZR9vBrqABK0NwSdA+fIDGRJsYK9ORKXs41VC 0BwA== Received: by 10.68.130.194 with SMTP id og2mr33042881pbb.131.1349463469125; Fri, 05 Oct 2012 11:57:49 -0700 (PDT) Received: from [192.168.1.2] (cm152.gamma205.maxonline.com.sg. [202.156.205.152]) by mx.google.com with ESMTPS id m5sm6413174pax.10.2012.10.05.11.57.46 (version=SSLv3 cipher=OTHER); Fri, 05 Oct 2012 11:57:48 -0700 (PDT) Message-ID: <506F2DA8.5070803@gmail.com> Date: Sat, 06 Oct 2012 02:57:44 +0800 From: "Teo En Ming (Zhang Enming)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Teo En Ming (Zhang Enming)" References: <506E8BFD.9080504@gmail.com> <506F064F.9010705@gmail.com> In-Reply-To: <506F064F.9010705@gmail.com> Cc: "xen-users@lists.xen.org" , "xen-devel@lists.xen.org" , Dariusz Krempa Subject: Re: [Xen-devel] Help Needed from Xen Developers: Nasty Yellow Triangle with Exclamation Mark and Error Code 43 in Device Manager in Windows 8 HVM domU X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7643307461304818022==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a multi-part message in MIME format. --===============7643307461304818022== Content-Type: multipart/alternative; boundary="------------090709020405090203010303" This is a multi-part message in MIME format. --------------090709020405090203010303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 06/10/2012 00:09, Teo En Ming (Zhang Enming) wrote: > On 05/10/2012 16:05, Dariusz Krempa wrote: >> I'm afraid it is not possible to do this in this configuration. >> Nvidia does not support virtualization for geforce cards and their >> drivers have problems in windows 7, windows 8, vista, server 2008 >> etc. We can easy setup virtual machine on windows xp but only with >> drivers less than 280.xx and I did some trick (with a huge amount of >> luck) that I setup windows 7, but first drivers for windows 8 are >> 295.73. I think we will need to wait for different patch for xen to >> do this. >> If You will study device manager under windows 7 or 8 with view set >> on then You can see that windows do not recognize properly this >> memory range: >> mem 0xf4000000-0xf5ffffff >> and this is the only range which isn't set in xen patch. Of course I >> will try to work with windows 8 for a while but like I said, I'm >> afraid this will not work in this moment. > > Dear Dariusz Krempa, > > Even with Windows XP Home Edition SP3 HVM domU, I also get the nasty > yellow triangle with exclamation mark and error code 43. > Dear Dariusz Krempa, Correction: I have just tried it. Even with Windows XP Home Edition SP3 HVM domU and NVIDIA driver version 275.33, I still get the nasty yellow _circle_ with exclamation mark and error code 10. I am simply wondering. What is wrong? -- Yours sincerely, Mr. Teo En Ming (Zhang Enming) Singapore --------------090709020405090203010303 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 06/10/2012 00:09, Teo En Ming (Zhang Enming) wrote:
On 05/10/2012 16:05, Dariusz Krempa wrote:
I'm afraid it is not possible to do this in this configuration. Nvidia does not support virtualization for geforce cards and their drivers have problems in windows 7, windows 8, vista, server 2008 etc. We can easy setup virtual machine on windows xp but only with drivers less than 280.xx and I did some trick (with a huge amount of luck) that I setup windows 7, but first drivers for windows 8 are 295.73. I think we will need to wait for different patch for xen to do this.
If You will study device manager under windows 7 or 8 with view set on  then You can see that windows do not recognize properly this memory range:
mem 0xf4000000-0xf5ffffff
and this is the only range which isn't set in xen patch. Of course I will try to work with windows 8 for a while but like I said, I'm afraid this will not work in this moment.

Dear Dariusz Krempa,

Even with Windows XP Home Edition SP3 HVM domU, I also get the nasty yellow triangle with exclamation mark and error code 43.


Dear Dariusz Krempa,

Correction: I have just tried it. Even with Windows XP Home Edition SP3 HVM domU and NVIDIA driver version 275.33, I still get the nasty yellow circle with exclamation mark and error code 10.

I am simply wondering. What is wrong?
-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore
--------------090709020405090203010303-- --===============7643307461304818022== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============7643307461304818022==-- From xen-devel-bounces@lists.xen.org Fri Oct 05 19:01:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 19:01:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKD8o-0005DM-4z; Fri, 05 Oct 2012 19:00:54 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKD8n-0005D7-1o for xen-devel@lists.xen.org; Fri, 05 Oct 2012 19:00:53 +0000 Received: from [85.158.137.99:51057] by server-8.bemta-3.messagelabs.com id BC/19-16337-46E2F605; Fri, 05 Oct 2012 19:00:52 +0000 X-Env-Sender: singapore.mr.teo.en.ming@gmail.com X-Msg-Ref: server-10.tower-217.messagelabs.com!1349463649!20347435!1 X-Originating-IP: [209.85.160.45] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5462 invoked from network); 5 Oct 2012 19:00:51 -0000 Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com) (209.85.160.45) by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 19:00:51 -0000 Received: by mail-pb0-f45.google.com with SMTP id rp2so2237167pbb.32 for ; Fri, 05 Oct 2012 12:00:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=c/0eatf2G3c9yHxqm7g3w7zscnr1hnaLlCpTUgwdUnY=; b=TbBO47g3dgzXjjObpYdUka/sobrFzRDn5e2RblBRGwielSd28dLCyz0SGSDQDFSezA xOjrPl/T8qPdaXKdaAjZWI7kFpNry0aPTyjJ2E4Tqcfbl9SOjrxv8nn1so8IFmXRQ3+f R/ALXYPYA4pw3K0iSs6B9iWjC6xvuiaD3XuxbEGKgnR5B6dv/YmsN3HidfkG1ds+sQkZ gjSCWL+mtvRFv2H5yrOaymGqN8gkm2acEcr9rPpCRhVjPB2BuBNtZclDQm1GrT0hIUgg GVhCEnvKO8MIxI6l052D6nv744mPsLl7KUoTdaWTLRdmjqvCQ1z8TmH/kD53y+Z59ugP AVZA== Received: by 10.68.135.234 with SMTP id pv10mr32868889pbb.156.1349463648886; Fri, 05 Oct 2012 12:00:48 -0700 (PDT) Received: from [192.168.1.2] (cm152.gamma205.maxonline.com.sg. [202.156.205.152]) by mx.google.com with ESMTPS id j10sm6419567pax.4.2012.10.05.12.00.46 (version=SSLv3 cipher=OTHER); Fri, 05 Oct 2012 12:00:48 -0700 (PDT) Message-ID: <506F2E5D.9010201@gmail.com> Date: Sat, 06 Oct 2012 03:00:45 +0800 From: "Teo En Ming (Zhang Enming)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Dariusz Krempa , "xen-users@lists.xen.org" , "xen-devel@lists.xen.org" , "Teo En Ming (Zhang Enming)" References: <506E8BFD.9080504@gmail.com> In-Reply-To: Subject: Re: [Xen-devel] Help Needed from Xen Developers: Nasty Yellow Triangle with Exclamation Mark and Error Code 43 in Device Manager in Windows 8 HVM domU X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 05/10/2012 19:48, Dariusz Krempa wrote: > > I just installed windows 8 and like before, which I mentioned on > mail-list its possible to install nvidia drivers under windows 8 but: > - drivers has to be 275.33 > - gpu-z shows that only Direct Computing is available, no physX, no > OpenCL, no CUDA > - windows index is much lower than normal, 7.8 under windows 7 > standalone and hvm and 7.1 under windows 8 hvm > > I don't know if this will work with stub, but with pciback I don't > need to do special tricks just install drivers 275.33 for win 7/vista How did it go with your Windows 8 HVM domU? -- Yours sincerely, Mr. Teo En Ming (Zhang Enming) Singapore _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 19:01:10 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 19:01:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKD8o-0005DM-4z; Fri, 05 Oct 2012 19:00:54 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKD8n-0005D7-1o for xen-devel@lists.xen.org; Fri, 05 Oct 2012 19:00:53 +0000 Received: from [85.158.137.99:51057] by server-8.bemta-3.messagelabs.com id BC/19-16337-46E2F605; Fri, 05 Oct 2012 19:00:52 +0000 X-Env-Sender: singapore.mr.teo.en.ming@gmail.com X-Msg-Ref: server-10.tower-217.messagelabs.com!1349463649!20347435!1 X-Originating-IP: [209.85.160.45] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5462 invoked from network); 5 Oct 2012 19:00:51 -0000 Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com) (209.85.160.45) by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 19:00:51 -0000 Received: by mail-pb0-f45.google.com with SMTP id rp2so2237167pbb.32 for ; Fri, 05 Oct 2012 12:00:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=c/0eatf2G3c9yHxqm7g3w7zscnr1hnaLlCpTUgwdUnY=; b=TbBO47g3dgzXjjObpYdUka/sobrFzRDn5e2RblBRGwielSd28dLCyz0SGSDQDFSezA xOjrPl/T8qPdaXKdaAjZWI7kFpNry0aPTyjJ2E4Tqcfbl9SOjrxv8nn1so8IFmXRQ3+f R/ALXYPYA4pw3K0iSs6B9iWjC6xvuiaD3XuxbEGKgnR5B6dv/YmsN3HidfkG1ds+sQkZ gjSCWL+mtvRFv2H5yrOaymGqN8gkm2acEcr9rPpCRhVjPB2BuBNtZclDQm1GrT0hIUgg GVhCEnvKO8MIxI6l052D6nv744mPsLl7KUoTdaWTLRdmjqvCQ1z8TmH/kD53y+Z59ugP AVZA== Received: by 10.68.135.234 with SMTP id pv10mr32868889pbb.156.1349463648886; Fri, 05 Oct 2012 12:00:48 -0700 (PDT) Received: from [192.168.1.2] (cm152.gamma205.maxonline.com.sg. [202.156.205.152]) by mx.google.com with ESMTPS id j10sm6419567pax.4.2012.10.05.12.00.46 (version=SSLv3 cipher=OTHER); Fri, 05 Oct 2012 12:00:48 -0700 (PDT) Message-ID: <506F2E5D.9010201@gmail.com> Date: Sat, 06 Oct 2012 03:00:45 +0800 From: "Teo En Ming (Zhang Enming)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Dariusz Krempa , "xen-users@lists.xen.org" , "xen-devel@lists.xen.org" , "Teo En Ming (Zhang Enming)" References: <506E8BFD.9080504@gmail.com> In-Reply-To: Subject: Re: [Xen-devel] Help Needed from Xen Developers: Nasty Yellow Triangle with Exclamation Mark and Error Code 43 in Device Manager in Windows 8 HVM domU X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 05/10/2012 19:48, Dariusz Krempa wrote: > > I just installed windows 8 and like before, which I mentioned on > mail-list its possible to install nvidia drivers under windows 8 but: > - drivers has to be 275.33 > - gpu-z shows that only Direct Computing is available, no physX, no > OpenCL, no CUDA > - windows index is much lower than normal, 7.8 under windows 7 > standalone and hvm and 7.1 under windows 8 hvm > > I don't know if this will work with stub, but with pciback I don't > need to do special tricks just install drivers 275.33 for win 7/vista How did it go with your Windows 8 HVM domU? -- Yours sincerely, Mr. Teo En Ming (Zhang Enming) Singapore _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 19:11:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 19:11:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKDIE-0005qL-UW; Fri, 05 Oct 2012 19:10:38 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKDID-0005qE-8x for xen-devel@lists.xen.org; Fri, 05 Oct 2012 19:10:37 +0000 Received: from [85.158.139.83:23078] by server-4.bemta-5.messagelabs.com id 8B/69-20767-CA03F605; Fri, 05 Oct 2012 19:10:36 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1349464234!26407535!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzg2MDM5\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27317 invoked from network); 5 Oct 2012 19:10:35 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 19:10:35 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q95JAS0J002504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Oct 2012 19:10:29 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q95JARLC006664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Oct 2012 19:10:28 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q95JARvV024894; Fri, 5 Oct 2012 14:10:27 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 05 Oct 2012 12:10:25 -0700 Date: Fri, 5 Oct 2012 12:10:24 -0700 From: Mukesh Rathor To: Stefano Stabellini Message-ID: <20121005121024.17c22c7d@mantra.us.oracle.com> In-Reply-To: References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-7-git-send-email-ian.campbell@citrix.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "xen-devel@lists.xen.org" , Ian Campbell , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 07/14] xen: balloon: do not update stage 1 pagetable for autotranslated guests X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 5 Oct 2012 13:05:01 +0100 Stefano Stabellini wrote: > On Thu, 4 Oct 2012, Ian Campbell wrote: > > This is unnecessary (since the page will be removed from the p2m) > > and can be tricky if the page is in the middle of a superpage, as > > it is on ARM. > > > > I think that this patch is correct. I'll leave to Konrad whether we > should carry the original incorrect PVH patch and this separate fix or > just merge the two of them. > > > > Signed-off-by: Ian Campbell > > --- > > Also effects PVH but in a benign way I think. > > > > drivers/xen/balloon.c | 23 +++-------------------- > > 1 files changed, 3 insertions(+), 20 deletions(-) > > > > diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c > > index 7885a19..1b56ae0 100644 > > --- a/drivers/xen/balloon.c > > +++ b/drivers/xen/balloon.c > > @@ -357,15 +357,7 @@ static enum bp_state > > increase_reservation(unsigned long nr_pages) > > BUG_ON(!xen_feature(XENFEAT_auto_translated_physmap) && > > phys_to_machine_mapping_valid(pfn)); > > - if (xen_pv_domain() && > > - xen_feature(XENFEAT_auto_translated_physmap)) { > > - /* PVH: we just need to update native page > > table */ > > - pte_t *ptep; > > - unsigned int level; > > - void *addr = __va(pfn << PAGE_SHIFT); > > - ptep = lookup_address((unsigned long)addr, > > &level); > > - set_pte(ptep, pfn_pte(pfn, PAGE_KERNEL)); > > - } else > > + if (!xen_feature(XENFEAT_auto_translated_physmap)) > > set_phys_to_machine(pfn, frame_list[i]); > > > > /* Link back into the page tables if not highmem. > > */ @@ -427,21 +419,12 @@ static enum bp_state > > decrease_reservation(unsigned long nr_pages, gfp_t gfp) > > scrub_page(page); > > > > - if (xen_pv_domain() && !PageHighMem(page)) { > > - if > > (xen_feature(XENFEAT_auto_translated_physmap)) { > > - unsigned int level; > > - pte_t *ptep; > > - void *addr = __va(pfn << > > PAGE_SHIFT); > > - ptep = lookup_address((unsigned > > long)addr, > > - &level); > > - set_pte(ptep, __pte(0)); > > - > > - } else { > > + if (xen_pv_domain() && !PageHighMem(page) && > > + !xen_feature(XENFEAT_auto_translated_physmap)) > > { ret = HYPERVISOR_update_va_mapping( > > (unsigned long)__va(pfn << > > PAGE_SHIFT), __pte_ma(0), 0); > > BUG_ON(ret); > > - } > > } > > } > > > > -- > > 1.7.2.5 > > I've made this change in my tree also. So, its good for PVH also. thanks Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 19:11:00 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 19:11:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKDIE-0005qL-UW; Fri, 05 Oct 2012 19:10:38 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKDID-0005qE-8x for xen-devel@lists.xen.org; Fri, 05 Oct 2012 19:10:37 +0000 Received: from [85.158.139.83:23078] by server-4.bemta-5.messagelabs.com id 8B/69-20767-CA03F605; Fri, 05 Oct 2012 19:10:36 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1349464234!26407535!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzg2MDM5\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27317 invoked from network); 5 Oct 2012 19:10:35 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 19:10:35 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q95JAS0J002504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Oct 2012 19:10:29 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q95JARLC006664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Oct 2012 19:10:28 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q95JARvV024894; Fri, 5 Oct 2012 14:10:27 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 05 Oct 2012 12:10:25 -0700 Date: Fri, 5 Oct 2012 12:10:24 -0700 From: Mukesh Rathor To: Stefano Stabellini Message-ID: <20121005121024.17c22c7d@mantra.us.oracle.com> In-Reply-To: References: <1349363496.866.49.camel@zakaz.uk.xensource.com> <1349363515-26190-7-git-send-email-ian.campbell@citrix.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "xen-devel@lists.xen.org" , Ian Campbell , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH 07/14] xen: balloon: do not update stage 1 pagetable for autotranslated guests X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 5 Oct 2012 13:05:01 +0100 Stefano Stabellini wrote: > On Thu, 4 Oct 2012, Ian Campbell wrote: > > This is unnecessary (since the page will be removed from the p2m) > > and can be tricky if the page is in the middle of a superpage, as > > it is on ARM. > > > > I think that this patch is correct. I'll leave to Konrad whether we > should carry the original incorrect PVH patch and this separate fix or > just merge the two of them. > > > > Signed-off-by: Ian Campbell > > --- > > Also effects PVH but in a benign way I think. > > > > drivers/xen/balloon.c | 23 +++-------------------- > > 1 files changed, 3 insertions(+), 20 deletions(-) > > > > diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c > > index 7885a19..1b56ae0 100644 > > --- a/drivers/xen/balloon.c > > +++ b/drivers/xen/balloon.c > > @@ -357,15 +357,7 @@ static enum bp_state > > increase_reservation(unsigned long nr_pages) > > BUG_ON(!xen_feature(XENFEAT_auto_translated_physmap) && > > phys_to_machine_mapping_valid(pfn)); > > - if (xen_pv_domain() && > > - xen_feature(XENFEAT_auto_translated_physmap)) { > > - /* PVH: we just need to update native page > > table */ > > - pte_t *ptep; > > - unsigned int level; > > - void *addr = __va(pfn << PAGE_SHIFT); > > - ptep = lookup_address((unsigned long)addr, > > &level); > > - set_pte(ptep, pfn_pte(pfn, PAGE_KERNEL)); > > - } else > > + if (!xen_feature(XENFEAT_auto_translated_physmap)) > > set_phys_to_machine(pfn, frame_list[i]); > > > > /* Link back into the page tables if not highmem. > > */ @@ -427,21 +419,12 @@ static enum bp_state > > decrease_reservation(unsigned long nr_pages, gfp_t gfp) > > scrub_page(page); > > > > - if (xen_pv_domain() && !PageHighMem(page)) { > > - if > > (xen_feature(XENFEAT_auto_translated_physmap)) { > > - unsigned int level; > > - pte_t *ptep; > > - void *addr = __va(pfn << > > PAGE_SHIFT); > > - ptep = lookup_address((unsigned > > long)addr, > > - &level); > > - set_pte(ptep, __pte(0)); > > - > > - } else { > > + if (xen_pv_domain() && !PageHighMem(page) && > > + !xen_feature(XENFEAT_auto_translated_physmap)) > > { ret = HYPERVISOR_update_va_mapping( > > (unsigned long)__va(pfn << > > PAGE_SHIFT), __pte_ma(0), 0); > > BUG_ON(ret); > > - } > > } > > } > > > > -- > > 1.7.2.5 > > I've made this change in my tree also. So, its good for PVH also. thanks Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 19:13:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 19:13:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKDKo-000601-Gv; Fri, 05 Oct 2012 19:13:18 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKDKm-0005zu-T1 for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 19:13:17 +0000 Received: from [85.158.143.99:46203] by server-3.bemta-4.messagelabs.com id 78/69-10986-C413F605; Fri, 05 Oct 2012 19:13:16 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1349464395!32437231!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31119 invoked from network); 5 Oct 2012 19:13:15 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 19:13:15 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14971777" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 19:13:15 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 20:13:15 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TKDKl-0002xl-3H; Fri, 05 Oct 2012 19:13:15 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1TKDKk-00024k-SZ; Fri, 05 Oct 2012 20:13:14 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Fri, 5 Oct 2012 20:13:14 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.2-testing test] 13925: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 13925 xen-4.2-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13925/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail REGR. vs. 13922 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-i386-i386-xl-qemuu-winxpsp3 9 guest-localmigrate fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: xen 27db446078b5 baseline version: xen a69c8e5c4afc ------------------------------------------------------------ People who touched revisions under test: Ben Guthro Christoph Egger Jan Beulich Keir Fraser Tim Deegan ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 25872:27db446078b5 tag: tip user: Christoph Egger date: Fri Oct 05 12:55:27 2012 +0200 x86/nested-svm: Update the paging mode on VMRUN and VMEXIT emulation. This allows Xen to walk the l1 hypervisor's shadow pagetable correctly. Not needed for hap-on-hap guests because they are handled at lookup time. Problem found with 64bit Win7 and 32bit XPMode where Win7 switches forth and back between long mode and PAE legacy pagetables. Signed-off-by: Christoph Egger [Adjusted to update in all cases where the l1 vmm uses shadows] Signed-off-by: Tim Deegan xen-unstable changeset: 25984:a9c84069c248 xen-unstable date: Thu Oct 4 13:20:50 UTC 2012 changeset: 25871:a69c8e5c4afc user: Jan Beulich date: Thu Oct 04 10:16:20 2012 +0200 x86/ucode: fix Intel case of resume handling on boot CPU Checking the stored version doesn't tell us anything about the need to apply the update (during resume, what is stored doesn't necessarily match what is loaded). Note that the check can be removed altogether because once switched to use what was read from the CPU (uci->cpu_sig.rev, as used in the subsequent pr_debug()), it would become redundant with the checks that lead to microcode_update_match() returning the indication that an update should be applied. Note further that this was not an issue on APs since they start with uci->mc.mc_intel being NULL. Signed-off-by: Jan Beulich Tested-by: Ben Guthro Acked-by: Keir Fraser xen-unstable changeset: 25965:4496d56c68a0 xen-unstable date: Fri Sep 28 07:28:11 UTC 2012 (qemu changes not included) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 19:13:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 19:13:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKDKo-000601-Gv; Fri, 05 Oct 2012 19:13:18 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKDKm-0005zu-T1 for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 19:13:17 +0000 Received: from [85.158.143.99:46203] by server-3.bemta-4.messagelabs.com id 78/69-10986-C413F605; Fri, 05 Oct 2012 19:13:16 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1349464395!32437231!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31119 invoked from network); 5 Oct 2012 19:13:15 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 19:13:15 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14971777" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 19:13:15 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 20:13:15 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TKDKl-0002xl-3H; Fri, 05 Oct 2012 19:13:15 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1TKDKk-00024k-SZ; Fri, 05 Oct 2012 20:13:14 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Fri, 5 Oct 2012 20:13:14 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.2-testing test] 13925: regressions - FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 13925 xen-4.2-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13925/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail REGR. vs. 13922 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-i386-i386-xl-qemuu-winxpsp3 9 guest-localmigrate fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: xen 27db446078b5 baseline version: xen a69c8e5c4afc ------------------------------------------------------------ People who touched revisions under test: Ben Guthro Christoph Egger Jan Beulich Keir Fraser Tim Deegan ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ changeset: 25872:27db446078b5 tag: tip user: Christoph Egger date: Fri Oct 05 12:55:27 2012 +0200 x86/nested-svm: Update the paging mode on VMRUN and VMEXIT emulation. This allows Xen to walk the l1 hypervisor's shadow pagetable correctly. Not needed for hap-on-hap guests because they are handled at lookup time. Problem found with 64bit Win7 and 32bit XPMode where Win7 switches forth and back between long mode and PAE legacy pagetables. Signed-off-by: Christoph Egger [Adjusted to update in all cases where the l1 vmm uses shadows] Signed-off-by: Tim Deegan xen-unstable changeset: 25984:a9c84069c248 xen-unstable date: Thu Oct 4 13:20:50 UTC 2012 changeset: 25871:a69c8e5c4afc user: Jan Beulich date: Thu Oct 04 10:16:20 2012 +0200 x86/ucode: fix Intel case of resume handling on boot CPU Checking the stored version doesn't tell us anything about the need to apply the update (during resume, what is stored doesn't necessarily match what is loaded). Note that the check can be removed altogether because once switched to use what was read from the CPU (uci->cpu_sig.rev, as used in the subsequent pr_debug()), it would become redundant with the checks that lead to microcode_update_match() returning the indication that an update should be applied. Note further that this was not an issue on APs since they start with uci->mc.mc_intel being NULL. Signed-off-by: Jan Beulich Tested-by: Ben Guthro Acked-by: Keir Fraser xen-unstable changeset: 25965:4496d56c68a0 xen-unstable date: Fri Sep 28 07:28:11 UTC 2012 (qemu changes not included) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 19:27:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 19:27:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKDXv-0006G4-Rc; Fri, 05 Oct 2012 19:26:51 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKDXt-0006Fw-VB for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 19:26:50 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1349465202!8806303!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc5NjAzMQ==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19764 invoked from network); 5 Oct 2012 19:26:43 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 19:26:43 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q95JQbAU026088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Oct 2012 19:26:38 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q95JQagg010639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Oct 2012 19:26:36 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q95JQZbc002113; Fri, 5 Oct 2012 14:26:35 -0500 Received: from [192.168.2.136] (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 05 Oct 2012 12:26:35 -0700 Date: Fri, 05 Oct 2012 15:26:31 -0400 Message-ID: From: konrad To: Sander Eikelenboom MIME-Version: 1.0 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Kernel 3.7.0-pre-rc1 kernel BUG at drivers/net/xen-netback/netback.c:405 RIP: e030:[] [] netbk_gop_frag_copy+0x379/0x380 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Sorry for top posting - on mobile. I saw it too yesterday but only on a specific hardware - AMD FX8. What type of CPU do you have? Does xsave=off on Xen line help? Sander Eikelenboom wrote: >Hi Konrad, > >Just tested kernel 3.7.0-pre-rc1 but ran into a oops in netback on boot after starting some guests: > >[ 402.723915] ------------[ cut here ]------------ >[ 402.734629] kernel BUG at drivers/net/xen-netback/netback.c:405! >[ 402.744207] invalid opcode: 0000 [#5] PREEMPT SMP >[ 402.752692] Modules linked in: >[ 402.761307] CPU 1 >[ 402.761358] Pid: 1329, comm: netback/1 Tainted: G D 3.6.0-pre-rc1-20121005a #1 MSI MS-7640/890FXA-GD70 (MS-7640) >[ 402.778214] RIP: e030:[] [] netbk_gop_frag_copy+0x379/0x380 >[ 402.786779] RSP: e02b:ffff880037955bb0 EFLAGS: 00010206 >[ 402.795183] RAX: 000000000000486a RBX: ffff88003878c9c0 RCX: ffffea0000b3d400 >[ 402.803536] RDX: ffff880037955cd0 RSI: ffff880037955d1c RDI: ffff88003878c9c0 >[ 402.811867] RBP: ffff880037955c20 R08: 0000000000000000 R09: 00000000000042c2 >[ 402.820008] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88002f58b100 >[ 402.828022] R13: ffff880037955cd0 R14: 00000000000005a8 R15: ffff880037955d1c >[ 402.835927] FS: 00007ffe2ca5b760(0000) GS:ffff88003f840000(0000) knlGS:0000000000000000 >[ 402.843826] CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b >[ 402.851539] CR2: 00007fff99c3b018 CR3: 00000000377c9000 CR4: 0000000000000660 >[ 402.859251] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 >[ 402.866816] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 >[ 402.874188] Process netback/1 (pid: 1329, threadinfo ffff880037954000, task ffff8800398c20a0) >[ 402.881621] Stack: >[ 402.888811] ffff880037955d1c 0000000000000000 ffff88002f58b100 ffff88003878c9c0 >[ 402.896102] ffff880000000000 ffff88002cf54000 0000000000000000 0000000000000000 >[ 402.903320] ffff880037955c20 ffff88002f58b100 0000000000000001 0000000000000010 >[ 402.910356] Call Trace: >[ 402.917180] [] xen_netbk_rx_action+0x303/0x840 >[ 402.924065] [] ? trace_hardirqs_on+0xd/0x10 >[ 402.930776] [] xen_netbk_kthread+0xba/0xac0 >[ 402.937352] [] ? try_to_wake_up+0x1b6/0x310 >[ 402.943856] [] ? wake_up_bit+0x40/0x40 >[ 402.950173] [] ? xen_netbk_tx_build_gops+0xa70/0xa70 >[ 402.956370] [] kthread+0xd6/0xe0 >[ 402.962524] [] kernel_thread_helper+0x4/0x10 >[ 402.968668] [] ? retint_restore_args+0x13/0x13 >[ 402.974735] [] ? gs_change+0x13/0x13 >[ 402.980715] Code: b8 01 00 00 00 48 69 d2 b8 b3 00 00 48 8d 84 f8 60 01 00 00 48 3b 0c 10 0f 85 de fc ff ff e9 e2 fc ff ff 0f 0b eb fe 0f 0b eb fe <0f> 0b eb fe 0f 1f 00 55 48 89 e5 48 83 ec 10 48 89 1c 24 4c 89 >[ 402.993584] RIP [] netbk_gop_frag_copy+0x379/0x380 >[ 403.000075] RSP >[ 403.006603] ---[ end trace 6eada309643a3fc7 ]--- > >-- > >Sander > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 19:27:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 19:27:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKDXv-0006G4-Rc; Fri, 05 Oct 2012 19:26:51 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKDXt-0006Fw-VB for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 19:26:50 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1349465202!8806303!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc5NjAzMQ==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19764 invoked from network); 5 Oct 2012 19:26:43 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 19:26:43 -0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q95JQbAU026088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Oct 2012 19:26:38 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q95JQagg010639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Oct 2012 19:26:36 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q95JQZbc002113; Fri, 5 Oct 2012 14:26:35 -0500 Received: from [192.168.2.136] (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 05 Oct 2012 12:26:35 -0700 Date: Fri, 05 Oct 2012 15:26:31 -0400 Message-ID: From: konrad To: Sander Eikelenboom MIME-Version: 1.0 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Kernel 3.7.0-pre-rc1 kernel BUG at drivers/net/xen-netback/netback.c:405 RIP: e030:[] [] netbk_gop_frag_copy+0x379/0x380 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Sorry for top posting - on mobile. I saw it too yesterday but only on a specific hardware - AMD FX8. What type of CPU do you have? Does xsave=off on Xen line help? Sander Eikelenboom wrote: >Hi Konrad, > >Just tested kernel 3.7.0-pre-rc1 but ran into a oops in netback on boot after starting some guests: > >[ 402.723915] ------------[ cut here ]------------ >[ 402.734629] kernel BUG at drivers/net/xen-netback/netback.c:405! >[ 402.744207] invalid opcode: 0000 [#5] PREEMPT SMP >[ 402.752692] Modules linked in: >[ 402.761307] CPU 1 >[ 402.761358] Pid: 1329, comm: netback/1 Tainted: G D 3.6.0-pre-rc1-20121005a #1 MSI MS-7640/890FXA-GD70 (MS-7640) >[ 402.778214] RIP: e030:[] [] netbk_gop_frag_copy+0x379/0x380 >[ 402.786779] RSP: e02b:ffff880037955bb0 EFLAGS: 00010206 >[ 402.795183] RAX: 000000000000486a RBX: ffff88003878c9c0 RCX: ffffea0000b3d400 >[ 402.803536] RDX: ffff880037955cd0 RSI: ffff880037955d1c RDI: ffff88003878c9c0 >[ 402.811867] RBP: ffff880037955c20 R08: 0000000000000000 R09: 00000000000042c2 >[ 402.820008] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88002f58b100 >[ 402.828022] R13: ffff880037955cd0 R14: 00000000000005a8 R15: ffff880037955d1c >[ 402.835927] FS: 00007ffe2ca5b760(0000) GS:ffff88003f840000(0000) knlGS:0000000000000000 >[ 402.843826] CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b >[ 402.851539] CR2: 00007fff99c3b018 CR3: 00000000377c9000 CR4: 0000000000000660 >[ 402.859251] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 >[ 402.866816] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 >[ 402.874188] Process netback/1 (pid: 1329, threadinfo ffff880037954000, task ffff8800398c20a0) >[ 402.881621] Stack: >[ 402.888811] ffff880037955d1c 0000000000000000 ffff88002f58b100 ffff88003878c9c0 >[ 402.896102] ffff880000000000 ffff88002cf54000 0000000000000000 0000000000000000 >[ 402.903320] ffff880037955c20 ffff88002f58b100 0000000000000001 0000000000000010 >[ 402.910356] Call Trace: >[ 402.917180] [] xen_netbk_rx_action+0x303/0x840 >[ 402.924065] [] ? trace_hardirqs_on+0xd/0x10 >[ 402.930776] [] xen_netbk_kthread+0xba/0xac0 >[ 402.937352] [] ? try_to_wake_up+0x1b6/0x310 >[ 402.943856] [] ? wake_up_bit+0x40/0x40 >[ 402.950173] [] ? xen_netbk_tx_build_gops+0xa70/0xa70 >[ 402.956370] [] kthread+0xd6/0xe0 >[ 402.962524] [] kernel_thread_helper+0x4/0x10 >[ 402.968668] [] ? retint_restore_args+0x13/0x13 >[ 402.974735] [] ? gs_change+0x13/0x13 >[ 402.980715] Code: b8 01 00 00 00 48 69 d2 b8 b3 00 00 48 8d 84 f8 60 01 00 00 48 3b 0c 10 0f 85 de fc ff ff e9 e2 fc ff ff 0f 0b eb fe 0f 0b eb fe <0f> 0b eb fe 0f 1f 00 55 48 89 e5 48 83 ec 10 48 89 1c 24 4c 89 >[ 402.993584] RIP [] netbk_gop_frag_copy+0x379/0x380 >[ 403.000075] RSP >[ 403.006603] ---[ end trace 6eada309643a3fc7 ]--- > >-- > >Sander > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 19:31:44 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 19:31:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKDcL-0006PN-Ml; Fri, 05 Oct 2012 19:31:25 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKDcK-0006PF-LS for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 19:31:24 +0000 X-Env-Sender: linux@eikelenboom.it X-Msg-Ref: server-16.tower-27.messagelabs.com!1349465473!12214971!1 X-Originating-IP: [188.40.164.121] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3266 invoked from network); 5 Oct 2012 19:31:15 -0000 Received: from static.121.164.40.188.clients.your-server.de (HELO smtp.eikelenboom.it) (188.40.164.121) by server-16.tower-27.messagelabs.com with AES256-SHA encrypted SMTP; 5 Oct 2012 19:31:15 -0000 Received: from 100-66-ftth.onsneteindhoven.nl ([88.159.66.100]:54086 helo=[172.16.1.20]) by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TKDdM-0003ac-38; Fri, 05 Oct 2012 21:32:28 +0200 Date: Fri, 5 Oct 2012 21:31:09 +0200 From: Sander Eikelenboom Organization: Eikelenboom IT services X-Priority: 3 (Normal) Message-ID: <1357529177.20121005213109@eikelenboom.it> To: konrad In-Reply-To: References: MIME-Version: 1.0 Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Kernel 3.7.0-pre-rc1 kernel BUG at drivers/net/xen-netback/netback.c:405 RIP: e030:[] [] netbk_gop_frag_copy+0x379/0x380 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Friday, October 5, 2012, 9:26:31 PM, you wrote: > Sorry for top posting - on mobile. > I saw it too yesterday but only on a specific hardware - AMD FX8. What type of CPU do you have? Does xsave=off on Xen line help? AMD Phenom II X6, will try the xsave=off and report later ! -- Sander > Sander Eikelenboom wrote: >>Hi Konrad, >> >>Just tested kernel 3.7.0-pre-rc1 but ran into a oops in netback on boot after starting some guests: >> >>[ 402.723915] ------------[ cut here ]------------ >>[ 402.734629] kernel BUG at drivers/net/xen-netback/netback.c:405! >>[ 402.744207] invalid opcode: 0000 [#5] PREEMPT SMP >>[ 402.752692] Modules linked in: >>[ 402.761307] CPU 1 >>[ 402.761358] Pid: 1329, comm: netback/1 Tainted: G D 3.6.0-pre-rc1-20121005a #1 MSI MS-7640/890FXA-GD70 (MS-7640) >>[ 402.778214] RIP: e030:[] [] netbk_gop_frag_copy+0x379/0x380 >>[ 402.786779] RSP: e02b:ffff880037955bb0 EFLAGS: 00010206 >>[ 402.795183] RAX: 000000000000486a RBX: ffff88003878c9c0 RCX: ffffea0000b3d400 >>[ 402.803536] RDX: ffff880037955cd0 RSI: ffff880037955d1c RDI: ffff88003878c9c0 >>[ 402.811867] RBP: ffff880037955c20 R08: 0000000000000000 R09: 00000000000042c2 >>[ 402.820008] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88002f58b100 >>[ 402.828022] R13: ffff880037955cd0 R14: 00000000000005a8 R15: ffff880037955d1c >>[ 402.835927] FS: 00007ffe2ca5b760(0000) GS:ffff88003f840000(0000) knlGS:0000000000000000 >>[ 402.843826] CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b >>[ 402.851539] CR2: 00007fff99c3b018 CR3: 00000000377c9000 CR4: 0000000000000660 >>[ 402.859251] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 >>[ 402.866816] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 >>[ 402.874188] Process netback/1 (pid: 1329, threadinfo ffff880037954000, task ffff8800398c20a0) >>[ 402.881621] Stack: >>[ 402.888811] ffff880037955d1c 0000000000000000 ffff88002f58b100 ffff88003878c9c0 >>[ 402.896102] ffff880000000000 ffff88002cf54000 0000000000000000 0000000000000000 >>[ 402.903320] ffff880037955c20 ffff88002f58b100 0000000000000001 0000000000000010 >>[ 402.910356] Call Trace: >>[ 402.917180] [] xen_netbk_rx_action+0x303/0x840 >>[ 402.924065] [] ? trace_hardirqs_on+0xd/0x10 >>[ 402.930776] [] xen_netbk_kthread+0xba/0xac0 >>[ 402.937352] [] ? try_to_wake_up+0x1b6/0x310 >>[ 402.943856] [] ? wake_up_bit+0x40/0x40 >>[ 402.950173] [] ? xen_netbk_tx_build_gops+0xa70/0xa70 >>[ 402.956370] [] kthread+0xd6/0xe0 >>[ 402.962524] [] kernel_thread_helper+0x4/0x10 >>[ 402.968668] [] ? retint_restore_args+0x13/0x13 >>[ 402.974735] [] ? gs_change+0x13/0x13 >>[ 402.980715] Code: b8 01 00 00 00 48 69 d2 b8 b3 00 00 48 8d 84 f8 60 01 00 00 48 3b 0c 10 0f 85 de fc ff ff e9 e2 fc ff ff 0f 0b eb fe 0f 0b eb fe <0f> 0b eb fe 0f 1f 00 55 48 89 e5 48 83 ec 10 48 89 1c 24 4c 89 >>[ 402.993584] RIP [] netbk_gop_frag_copy+0x379/0x380 >>[ 403.000075] RSP >>[ 403.006603] ---[ end trace 6eada309643a3fc7 ]--- >> >>-- >> >>Sander >> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 19:31:44 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 19:31:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKDcL-0006PN-Ml; Fri, 05 Oct 2012 19:31:25 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKDcK-0006PF-LS for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 19:31:24 +0000 X-Env-Sender: linux@eikelenboom.it X-Msg-Ref: server-16.tower-27.messagelabs.com!1349465473!12214971!1 X-Originating-IP: [188.40.164.121] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3266 invoked from network); 5 Oct 2012 19:31:15 -0000 Received: from static.121.164.40.188.clients.your-server.de (HELO smtp.eikelenboom.it) (188.40.164.121) by server-16.tower-27.messagelabs.com with AES256-SHA encrypted SMTP; 5 Oct 2012 19:31:15 -0000 Received: from 100-66-ftth.onsneteindhoven.nl ([88.159.66.100]:54086 helo=[172.16.1.20]) by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TKDdM-0003ac-38; Fri, 05 Oct 2012 21:32:28 +0200 Date: Fri, 5 Oct 2012 21:31:09 +0200 From: Sander Eikelenboom Organization: Eikelenboom IT services X-Priority: 3 (Normal) Message-ID: <1357529177.20121005213109@eikelenboom.it> To: konrad In-Reply-To: References: MIME-Version: 1.0 Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Kernel 3.7.0-pre-rc1 kernel BUG at drivers/net/xen-netback/netback.c:405 RIP: e030:[] [] netbk_gop_frag_copy+0x379/0x380 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Friday, October 5, 2012, 9:26:31 PM, you wrote: > Sorry for top posting - on mobile. > I saw it too yesterday but only on a specific hardware - AMD FX8. What type of CPU do you have? Does xsave=off on Xen line help? AMD Phenom II X6, will try the xsave=off and report later ! -- Sander > Sander Eikelenboom wrote: >>Hi Konrad, >> >>Just tested kernel 3.7.0-pre-rc1 but ran into a oops in netback on boot after starting some guests: >> >>[ 402.723915] ------------[ cut here ]------------ >>[ 402.734629] kernel BUG at drivers/net/xen-netback/netback.c:405! >>[ 402.744207] invalid opcode: 0000 [#5] PREEMPT SMP >>[ 402.752692] Modules linked in: >>[ 402.761307] CPU 1 >>[ 402.761358] Pid: 1329, comm: netback/1 Tainted: G D 3.6.0-pre-rc1-20121005a #1 MSI MS-7640/890FXA-GD70 (MS-7640) >>[ 402.778214] RIP: e030:[] [] netbk_gop_frag_copy+0x379/0x380 >>[ 402.786779] RSP: e02b:ffff880037955bb0 EFLAGS: 00010206 >>[ 402.795183] RAX: 000000000000486a RBX: ffff88003878c9c0 RCX: ffffea0000b3d400 >>[ 402.803536] RDX: ffff880037955cd0 RSI: ffff880037955d1c RDI: ffff88003878c9c0 >>[ 402.811867] RBP: ffff880037955c20 R08: 0000000000000000 R09: 00000000000042c2 >>[ 402.820008] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88002f58b100 >>[ 402.828022] R13: ffff880037955cd0 R14: 00000000000005a8 R15: ffff880037955d1c >>[ 402.835927] FS: 00007ffe2ca5b760(0000) GS:ffff88003f840000(0000) knlGS:0000000000000000 >>[ 402.843826] CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b >>[ 402.851539] CR2: 00007fff99c3b018 CR3: 00000000377c9000 CR4: 0000000000000660 >>[ 402.859251] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 >>[ 402.866816] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 >>[ 402.874188] Process netback/1 (pid: 1329, threadinfo ffff880037954000, task ffff8800398c20a0) >>[ 402.881621] Stack: >>[ 402.888811] ffff880037955d1c 0000000000000000 ffff88002f58b100 ffff88003878c9c0 >>[ 402.896102] ffff880000000000 ffff88002cf54000 0000000000000000 0000000000000000 >>[ 402.903320] ffff880037955c20 ffff88002f58b100 0000000000000001 0000000000000010 >>[ 402.910356] Call Trace: >>[ 402.917180] [] xen_netbk_rx_action+0x303/0x840 >>[ 402.924065] [] ? trace_hardirqs_on+0xd/0x10 >>[ 402.930776] [] xen_netbk_kthread+0xba/0xac0 >>[ 402.937352] [] ? try_to_wake_up+0x1b6/0x310 >>[ 402.943856] [] ? wake_up_bit+0x40/0x40 >>[ 402.950173] [] ? xen_netbk_tx_build_gops+0xa70/0xa70 >>[ 402.956370] [] kthread+0xd6/0xe0 >>[ 402.962524] [] kernel_thread_helper+0x4/0x10 >>[ 402.968668] [] ? retint_restore_args+0x13/0x13 >>[ 402.974735] [] ? gs_change+0x13/0x13 >>[ 402.980715] Code: b8 01 00 00 00 48 69 d2 b8 b3 00 00 48 8d 84 f8 60 01 00 00 48 3b 0c 10 0f 85 de fc ff ff e9 e2 fc ff ff 0f 0b eb fe 0f 0b eb fe <0f> 0b eb fe 0f 1f 00 55 48 89 e5 48 83 ec 10 48 89 1c 24 4c 89 >>[ 402.993584] RIP [] netbk_gop_frag_copy+0x379/0x380 >>[ 403.000075] RSP >>[ 403.006603] ---[ end trace 6eada309643a3fc7 ]--- >> >>-- >> >>Sander >> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 20:09:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 20:09:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKECu-0006mS-RR; Fri, 05 Oct 2012 20:09:12 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKECs-0006mN-TK for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 20:09:11 +0000 Received: from [85.158.143.99:35054] by server-2.bemta-4.messagelabs.com id A4/A3-06610-66E3F605; Fri, 05 Oct 2012 20:09:10 +0000 X-Env-Sender: ehabkost@redhat.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1349467749!24921902!1 X-Originating-IP: [209.132.183.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTcwODY=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10842 invoked from network); 5 Oct 2012 20:09:09 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-12.tower-216.messagelabs.com with SMTP; 5 Oct 2012 20:09:09 -0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q95K8v0Y028937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Oct 2012 16:08:57 -0400 Received: from blackpad.lan.raisama.net (vpn1-7-193.gru2.redhat.com [10.97.7.193]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q95K8rRQ019656; Fri, 5 Oct 2012 16:08:54 -0400 Received: by blackpad.lan.raisama.net (Postfix, from userid 500) id F1FA7203604; Fri, 5 Oct 2012 17:09:53 -0300 (BRT) Date: Fri, 5 Oct 2012 17:09:53 -0300 From: Eduardo Habkost To: qemu-devel@nongnu.org Message-ID: <20121005200953.GE4362@otherpad.lan.raisama.net> References: <1349462220-13742-1-git-send-email-ehabkost@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1349462220-13742-1-git-send-email-ehabkost@redhat.com> X-Fnord: you can see the fnord User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Cc: Peter Maydell , Anthony Liguori , xen-devel@lists.xensource.com, Igor Mitsyanko , Evgeny Voevodin , qemu-ppc@nongnu.org, Aurelien Jarno , Alexander Graf , Fabien Chouteau , Peter Crosthwaite , Max Filippov , Michael Walle , =?iso-8859-1?Q?Herv=E9?= Poussineau , Paul Brook , Blue Swirl , "Edgar E. Iglesias" , Maksim Kozlov , Guan Xuetao , Jan Kiszka , Dmitry Solodkiy Subject: Re: [Xen-devel] [Qemu-devel] [QEMU PATCH] create struct for machine initialization arguments X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, Oct 05, 2012 at 03:37:00PM -0300, Eduardo Habkost wrote: [...] > diff --git a/hw/boards.h b/hw/boards.h > index a2e0a54..813d0e5 100644 > --- a/hw/boards.h > +++ b/hw/boards.h > @@ -5,12 +5,16 @@ > > #include "qdev.h" > > -typedef void QEMUMachineInitFunc(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, > - const char *cpu_model); > +typedef struct QEMUMachineInitArgs { > + ram_addr_t ram_size; > + const char *boot_device; > + const char *kernel_filename; > + const char *kernel_cmdline; > + const char *initrd_filename; > + const char *cpu_model; > +} QEMUMachineInitArgs; > + > +typedef void QEMUMachineInitFunc(QEMUMachineInitArgs *args); > > typedef void QEMUMachineResetFunc(void); > [...] > @@ -332,7 +335,8 @@ static void pc_init_isa(ram_addr_t ram_size, > } > > #ifdef CONFIG_XEN > -static void pc_xen_hvm_init(ram_addr_t ram_size, > +static void pc_xen_hvm_init(QEMUMachine *machine, > + ram_addr_t ram_size, Oops. This is a leftover of an idea on which I was working previously (and then abandoned). It's obviously broken. I will submit a fixed version. -- Eduardo _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 20:09:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 20:09:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKECu-0006mS-RR; Fri, 05 Oct 2012 20:09:12 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKECs-0006mN-TK for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 20:09:11 +0000 Received: from [85.158.143.99:35054] by server-2.bemta-4.messagelabs.com id A4/A3-06610-66E3F605; Fri, 05 Oct 2012 20:09:10 +0000 X-Env-Sender: ehabkost@redhat.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1349467749!24921902!1 X-Originating-IP: [209.132.183.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTcwODY=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10842 invoked from network); 5 Oct 2012 20:09:09 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-12.tower-216.messagelabs.com with SMTP; 5 Oct 2012 20:09:09 -0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q95K8v0Y028937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Oct 2012 16:08:57 -0400 Received: from blackpad.lan.raisama.net (vpn1-7-193.gru2.redhat.com [10.97.7.193]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q95K8rRQ019656; Fri, 5 Oct 2012 16:08:54 -0400 Received: by blackpad.lan.raisama.net (Postfix, from userid 500) id F1FA7203604; Fri, 5 Oct 2012 17:09:53 -0300 (BRT) Date: Fri, 5 Oct 2012 17:09:53 -0300 From: Eduardo Habkost To: qemu-devel@nongnu.org Message-ID: <20121005200953.GE4362@otherpad.lan.raisama.net> References: <1349462220-13742-1-git-send-email-ehabkost@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1349462220-13742-1-git-send-email-ehabkost@redhat.com> X-Fnord: you can see the fnord User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Cc: Peter Maydell , Anthony Liguori , xen-devel@lists.xensource.com, Igor Mitsyanko , Evgeny Voevodin , qemu-ppc@nongnu.org, Aurelien Jarno , Alexander Graf , Fabien Chouteau , Peter Crosthwaite , Max Filippov , Michael Walle , =?iso-8859-1?Q?Herv=E9?= Poussineau , Paul Brook , Blue Swirl , "Edgar E. Iglesias" , Maksim Kozlov , Guan Xuetao , Jan Kiszka , Dmitry Solodkiy Subject: Re: [Xen-devel] [Qemu-devel] [QEMU PATCH] create struct for machine initialization arguments X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, Oct 05, 2012 at 03:37:00PM -0300, Eduardo Habkost wrote: [...] > diff --git a/hw/boards.h b/hw/boards.h > index a2e0a54..813d0e5 100644 > --- a/hw/boards.h > +++ b/hw/boards.h > @@ -5,12 +5,16 @@ > > #include "qdev.h" > > -typedef void QEMUMachineInitFunc(ram_addr_t ram_size, > - const char *boot_device, > - const char *kernel_filename, > - const char *kernel_cmdline, > - const char *initrd_filename, > - const char *cpu_model); > +typedef struct QEMUMachineInitArgs { > + ram_addr_t ram_size; > + const char *boot_device; > + const char *kernel_filename; > + const char *kernel_cmdline; > + const char *initrd_filename; > + const char *cpu_model; > +} QEMUMachineInitArgs; > + > +typedef void QEMUMachineInitFunc(QEMUMachineInitArgs *args); > > typedef void QEMUMachineResetFunc(void); > [...] > @@ -332,7 +335,8 @@ static void pc_init_isa(ram_addr_t ram_size, > } > > #ifdef CONFIG_XEN > -static void pc_xen_hvm_init(ram_addr_t ram_size, > +static void pc_xen_hvm_init(QEMUMachine *machine, > + ram_addr_t ram_size, Oops. This is a leftover of an idea on which I was working previously (and then abandoned). It's obviously broken. I will submit a fixed version. -- Eduardo _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 20:11:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 20:11:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKEF8-0006rA-BV; Fri, 05 Oct 2012 20:11:30 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKEF7-0006r4-Tt for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 20:11:30 +0000 Received: from [85.158.143.35:12781] by server-2.bemta-4.messagelabs.com id 24/84-06610-1FE3F605; Fri, 05 Oct 2012 20:11:29 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-15.tower-21.messagelabs.com!1349467888!13889453!1 X-Originating-IP: [81.169.146.162] X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MjE2NDY=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MjE2NDY=\n,BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14917 invoked from network); 5 Oct 2012 20:11:28 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162) by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 20:11:28 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESMg X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-070-120.pools.arcor-ip.net [88.65.70.120]) by smtp.strato.de (jored mo36) (RZmta 30.20 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id x06a2eo95JblxD ; Fri, 5 Oct 2012 22:11:27 +0200 (CEST) Received: by probook.site (Postfix, from userid 1000) id 21D3E1863E; Fri, 5 Oct 2012 22:11:27 +0200 (CEST) From: Olaf Hering To: xen-devel@lists.xensource.com Date: Fri, 5 Oct 2012 22:11:22 +0200 Message-Id: <1349467882-21865-1-git-send-email-olaf@aepfle.de> X-Mailer: git-send-email 1.7.12.1 Cc: Olaf Hering Subject: [Xen-devel] [PATCH] qemu-xen-trad: do not strip binaries during make install X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Olaf Hering --- Makefile | 2 +- Makefile.target | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 37c7066..594f0ef 100644 --- a/Makefile +++ b/Makefile @@ -243,7 +243,7 @@ endif install: all $(if $(BUILD_DOCS),install-doc) mkdir -p "$(DESTDIR)$(bindir)" ifneq ($(TOOLS),) - $(INSTALL) -m 755 -s $(TOOLS) "$(DESTDIR)$(bindir)" + $(INSTALL) -m 755 $(TOOLS) "$(DESTDIR)$(bindir)" endif ifneq ($(BLOBS),) mkdir -p "$(DESTDIR)$(datadir)" diff --git a/Makefile.target b/Makefile.target index 19bb0fd..1cf7f34 100644 --- a/Makefile.target +++ b/Makefile.target @@ -755,7 +755,7 @@ clean: install: all install-hook ifneq ($(PROGS),) - $(INSTALL) -m 755 -s $(PROGS) "$(DESTDIR)$(bindir)" + $(INSTALL) -m 755 $(PROGS) "$(DESTDIR)$(bindir)" endif # Include automatically generated dependency files -- 1.7.12.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 20:11:49 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 20:11:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKEF8-0006rA-BV; Fri, 05 Oct 2012 20:11:30 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKEF7-0006r4-Tt for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 20:11:30 +0000 Received: from [85.158.143.35:12781] by server-2.bemta-4.messagelabs.com id 24/84-06610-1FE3F605; Fri, 05 Oct 2012 20:11:29 +0000 X-Env-Sender: olaf@aepfle.de X-Msg-Ref: server-15.tower-21.messagelabs.com!1349467888!13889453!1 X-Originating-IP: [81.169.146.162] X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MjE2NDY=\n,sa_preprocessor: QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MjE2NDY=\n,BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14917 invoked from network); 5 Oct 2012 20:11:28 -0000 Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162) by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 20:11:28 -0000 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESMg X-RZG-CLASS-ID: mo00 Received: from probook.site (dslb-088-065-070-120.pools.arcor-ip.net [88.65.70.120]) by smtp.strato.de (jored mo36) (RZmta 30.20 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id x06a2eo95JblxD ; Fri, 5 Oct 2012 22:11:27 +0200 (CEST) Received: by probook.site (Postfix, from userid 1000) id 21D3E1863E; Fri, 5 Oct 2012 22:11:27 +0200 (CEST) From: Olaf Hering To: xen-devel@lists.xensource.com Date: Fri, 5 Oct 2012 22:11:22 +0200 Message-Id: <1349467882-21865-1-git-send-email-olaf@aepfle.de> X-Mailer: git-send-email 1.7.12.1 Cc: Olaf Hering Subject: [Xen-devel] [PATCH] qemu-xen-trad: do not strip binaries during make install X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Signed-off-by: Olaf Hering --- Makefile | 2 +- Makefile.target | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 37c7066..594f0ef 100644 --- a/Makefile +++ b/Makefile @@ -243,7 +243,7 @@ endif install: all $(if $(BUILD_DOCS),install-doc) mkdir -p "$(DESTDIR)$(bindir)" ifneq ($(TOOLS),) - $(INSTALL) -m 755 -s $(TOOLS) "$(DESTDIR)$(bindir)" + $(INSTALL) -m 755 $(TOOLS) "$(DESTDIR)$(bindir)" endif ifneq ($(BLOBS),) mkdir -p "$(DESTDIR)$(datadir)" diff --git a/Makefile.target b/Makefile.target index 19bb0fd..1cf7f34 100644 --- a/Makefile.target +++ b/Makefile.target @@ -755,7 +755,7 @@ clean: install: all install-hook ifneq ($(PROGS),) - $(INSTALL) -m 755 -s $(PROGS) "$(DESTDIR)$(bindir)" + $(INSTALL) -m 755 $(PROGS) "$(DESTDIR)$(bindir)" endif # Include automatically generated dependency files -- 1.7.12.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 20:19:48 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 20:19:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKEMp-00073u-AK; Fri, 05 Oct 2012 20:19:27 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKEMn-00073p-Rt for xen-devel@lists.xen.org; Fri, 05 Oct 2012 20:19:26 +0000 Received: from [85.158.139.83:41893] by server-2.bemta-5.messagelabs.com id 0F/31-28944-DC04F605; Fri, 05 Oct 2012 20:19:25 +0000 X-Env-Sender: peter.maloney@brockmann-consult.de X-Msg-Ref: server-10.tower-182.messagelabs.com!1349468364!33911200!1 X-Originating-IP: [212.227.126.187] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiAyMTIuMjI3LjEyNi4xODcgPT4gODIyNDc=\n,sa_preprocessor: QmFkIElQOiAyMTIuMjI3LjEyNi4xODcgPT4gODIyNDc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1108 invoked from network); 5 Oct 2012 20:19:24 -0000 Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de) (212.227.126.187) by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 20:19:24 -0000 Received: from [192.168.179.201] (hmbg-5f7739f5.pool.mediaWays.net [95.119.57.245]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0MRijR-1SrKgi15gn-00Tb3d; Fri, 05 Oct 2012 22:19:21 +0200 Message-ID: <506F40C8.2060007@brockmann-consult.de> Date: Fri, 05 Oct 2012 22:19:20 +0200 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120825 Thunderbird/15.0 MIME-Version: 1.0 To: xen-devel@lists.xen.org References: <501F98A1.4070806@brockmann-consult.de> <501FB9060200007800092D4E@nat28.tlf.novell.com> <5020C2DE.304@brockmann-consult.de> <50294D4B.9050405@brockmann-consult.de> <50296AC2.80600@brockmann-consult.de> <506C73A3.2030605@brockmann-consult.de> <506C9A84.5040408@brockmann-consult.de> <20121004142538.GA9979@phenom.dumpdata.com> In-Reply-To: <20121004142538.GA9979@phenom.dumpdata.com> X-Provags-ID: V02:K0:vvgNn/QFRlGLUMep9WtUc/4TNhGzvLrY4Bg9zDY0wKb LZbfPtDVCWR9fR++J0J1Kh3UeWt53IR7WgYyWcTyB2hTjikpOM ku38kYIBg1OiZ3kzFzLZwN0GbT/ltiftzkTgde44n68H+ezw7P /cWZXEHaKXs5AI6MD7YlMqZ4M7wcdjqV1gNWJQGHXJ/z+DCmgT ueDYWhXqQTO/AZXuKyOqjp1yhnRafA2hnZh3LjmuUYSt8/9vpb 6EqWh4WEa4/6HNMFwdwHpLHKlQyJDUSoKMnCQCeCanvok6kiNY FdC5ObWyFUG/K4El1gHj5klJvBBzUn6Rv7SfDoaq/leXo3XXYH BitjJ/UO5QOEwuu+mticsJxS7uR7Rx974irzuwHVzPMPaI8Ar4 CmVO0WjpT7Z/Q== Cc: konrad@kernel.org Subject: Re: [Xen-devel] 4.1.2 very slow without upstream patches, but fast with them, also 4.2 very slow X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 10/04/2012 04:25 PM, Konrad Rzeszutek Wilk wrote: > On Wed, Oct 03, 2012 at 10:05:24PM +0200, Peter Maloney wrote: >> I also tested: >> modprobe xen-acpi-processor > You didn't say what kind of CPU you have. Nor if you compiled > your kernel or if you used a distros' kernel. > > One thing (just to eliminate this being a power management issue), > is to do this on the Linux command line: > > xen-acpi-processor.off=1 > > It would also help if you provided the .config you are using. There > are some options you should not have one (like XEN_DEBUGFS.. something). > AMD FX-8150 990 FX chipset I compiled the for-linus branch of cmason's linux-btrfs git repo ( git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus ) Here's some hardware info: http://pastebin.com/XUZjmiVz Here's the kernel config: http://pastebin.com/1GQbiFZE (only weird thing I set was CONFIG_NR_CPUS=16 for no particular reason; default was 512 or 256) 3d stuff works fine (other than no es1370 sound device support) and fast in windows8 preview also, without that 0fps 'warmup' / 'hicup' thing happening (apparently as new textures are loading), which I wrote about before in IRC but not in the mailing list. At some point I plan on also testing: - builds between 4.1 and xen 4.2 to find where the 32 bit windowsxp starts going slow - a 64 bit windows xp if I can find one... I don't have one at the moment - a 32 bit windows 8 preview (I assume I can just download this like 64 bit win8 preview) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 20:19:48 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 20:19:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKEMp-00073u-AK; Fri, 05 Oct 2012 20:19:27 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKEMn-00073p-Rt for xen-devel@lists.xen.org; Fri, 05 Oct 2012 20:19:26 +0000 Received: from [85.158.139.83:41893] by server-2.bemta-5.messagelabs.com id 0F/31-28944-DC04F605; Fri, 05 Oct 2012 20:19:25 +0000 X-Env-Sender: peter.maloney@brockmann-consult.de X-Msg-Ref: server-10.tower-182.messagelabs.com!1349468364!33911200!1 X-Originating-IP: [212.227.126.187] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiAyMTIuMjI3LjEyNi4xODcgPT4gODIyNDc=\n,sa_preprocessor: QmFkIElQOiAyMTIuMjI3LjEyNi4xODcgPT4gODIyNDc=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1108 invoked from network); 5 Oct 2012 20:19:24 -0000 Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de) (212.227.126.187) by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 20:19:24 -0000 Received: from [192.168.179.201] (hmbg-5f7739f5.pool.mediaWays.net [95.119.57.245]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0MRijR-1SrKgi15gn-00Tb3d; Fri, 05 Oct 2012 22:19:21 +0200 Message-ID: <506F40C8.2060007@brockmann-consult.de> Date: Fri, 05 Oct 2012 22:19:20 +0200 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120825 Thunderbird/15.0 MIME-Version: 1.0 To: xen-devel@lists.xen.org References: <501F98A1.4070806@brockmann-consult.de> <501FB9060200007800092D4E@nat28.tlf.novell.com> <5020C2DE.304@brockmann-consult.de> <50294D4B.9050405@brockmann-consult.de> <50296AC2.80600@brockmann-consult.de> <506C73A3.2030605@brockmann-consult.de> <506C9A84.5040408@brockmann-consult.de> <20121004142538.GA9979@phenom.dumpdata.com> In-Reply-To: <20121004142538.GA9979@phenom.dumpdata.com> X-Provags-ID: V02:K0:vvgNn/QFRlGLUMep9WtUc/4TNhGzvLrY4Bg9zDY0wKb LZbfPtDVCWR9fR++J0J1Kh3UeWt53IR7WgYyWcTyB2hTjikpOM ku38kYIBg1OiZ3kzFzLZwN0GbT/ltiftzkTgde44n68H+ezw7P /cWZXEHaKXs5AI6MD7YlMqZ4M7wcdjqV1gNWJQGHXJ/z+DCmgT ueDYWhXqQTO/AZXuKyOqjp1yhnRafA2hnZh3LjmuUYSt8/9vpb 6EqWh4WEa4/6HNMFwdwHpLHKlQyJDUSoKMnCQCeCanvok6kiNY FdC5ObWyFUG/K4El1gHj5klJvBBzUn6Rv7SfDoaq/leXo3XXYH BitjJ/UO5QOEwuu+mticsJxS7uR7Rx974irzuwHVzPMPaI8Ar4 CmVO0WjpT7Z/Q== Cc: konrad@kernel.org Subject: Re: [Xen-devel] 4.1.2 very slow without upstream patches, but fast with them, also 4.2 very slow X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 10/04/2012 04:25 PM, Konrad Rzeszutek Wilk wrote: > On Wed, Oct 03, 2012 at 10:05:24PM +0200, Peter Maloney wrote: >> I also tested: >> modprobe xen-acpi-processor > You didn't say what kind of CPU you have. Nor if you compiled > your kernel or if you used a distros' kernel. > > One thing (just to eliminate this being a power management issue), > is to do this on the Linux command line: > > xen-acpi-processor.off=1 > > It would also help if you provided the .config you are using. There > are some options you should not have one (like XEN_DEBUGFS.. something). > AMD FX-8150 990 FX chipset I compiled the for-linus branch of cmason's linux-btrfs git repo ( git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus ) Here's some hardware info: http://pastebin.com/XUZjmiVz Here's the kernel config: http://pastebin.com/1GQbiFZE (only weird thing I set was CONFIG_NR_CPUS=16 for no particular reason; default was 512 or 256) 3d stuff works fine (other than no es1370 sound device support) and fast in windows8 preview also, without that 0fps 'warmup' / 'hicup' thing happening (apparently as new textures are loading), which I wrote about before in IRC but not in the mailing list. At some point I plan on also testing: - builds between 4.1 and xen 4.2 to find where the 32 bit windowsxp starts going slow - a 64 bit windows xp if I can find one... I don't have one at the moment - a 32 bit windows 8 preview (I assume I can just download this like 64 bit win8 preview) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 20:22:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 20:22:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKEPG-00079H-Sf; Fri, 05 Oct 2012 20:21:58 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with smtp (Exim 4.72) (envelope-from ) id 1TKEPF-00079A-6z for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 20:21:57 +0000 X-Env-Sender: ehabkost@redhat.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1349468509!1785447!1 X-Originating-IP: [209.132.183.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTcwODY=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32430 invoked from network); 5 Oct 2012 20:21:49 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-14.tower-27.messagelabs.com with SMTP; 5 Oct 2012 20:21:49 -0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q95KLJvR032621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Oct 2012 16:21:19 -0400 Received: from blackpad.lan.raisama.net (vpn1-7-193.gru2.redhat.com [10.97.7.193]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q95KLHg2020961; Fri, 5 Oct 2012 16:21:17 -0400 Received: by blackpad.lan.raisama.net (Postfix, from userid 500) id 61DFB203604; Fri, 5 Oct 2012 17:22:17 -0300 (BRT) From: Eduardo Habkost To: qemu-devel@nongnu.org Date: Fri, 5 Oct 2012 17:22:15 -0300 Message-Id: <1349468535-14499-1-git-send-email-ehabkost@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Cc: Peter Maydell , Evgeny Voevodin , Peter Crosthwaite , Max Filippov , "Edgar E. Iglesias" , Guan Xuetao , xen-devel@lists.xensource.com, Igor Mitsyanko , Magnus Damm , Alexander Graf , =?UTF-8?q?Herv=C3=A9=20Poussineau?= , Maksim Kozlov , Andrzej Zaborowski , Fabien Chouteau , Jan Kiszka , Paul Brook , Blue Swirl , Anthony Liguori , Michael Walle , qemu-ppc@nongnu.org, Dmitry Solodkiy , Aurelien Jarno Subject: [Xen-devel] [QEMU PATCH] create struct for machine initialization arguments (v2) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This should help us to: - More easily add or remove machine initialization arguments without having to change every single machine init function; - More easily make mechanical changes involving the machine init functions in the future; - Let machine initialization forward the init arguments to other functions more easily. This change was half-mechanical process: first the struct was added with the local ram_size, boot_device, kernel_*, initrd_*, and cpu_model local variable initialization to all functions. Then the compiler helped me locate the local variables that are unused, so they could be removed. Changes v1 -> v2: - Fix mistake on the conversion of pc_xen_hvm_init() and xen_init_pv() Signed-off-by: Eduardo Habkost --- hw/alpha_dp264.c | 12 ++-- hw/an5206.c | 8 +-- hw/axis_dev88.c | 9 +-- hw/boards.h | 16 +++-- hw/collie.c | 9 +-- hw/dummy_m68k.c | 8 +-- hw/exynos4_boards.c | 16 ++--- hw/gumstix.c | 11 +--- hw/highbank.c | 10 ++-- hw/integratorcp.c | 10 ++-- hw/kzm.c | 10 ++-- hw/leon3.c | 10 ++-- hw/lm32_boards.c | 18 +++--- hw/mainstone.c | 10 ++-- hw/mcf5208.c | 8 +-- hw/milkymist.c | 10 ++-- hw/mips_fulong2e.c | 9 ++- hw/mips_jazz.c | 14 ++--- hw/mips_malta.c | 10 ++-- hw/mips_mipssim.c | 10 ++-- hw/mips_r4k.c | 10 ++-- hw/musicpal.c | 9 +-- hw/nseries.c | 22 ++++--- hw/null-machine.c | 7 +-- hw/omap_sx1.c | 22 ++++--- hw/openrisc_sim.c | 10 ++-- hw/palm.c | 9 +-- hw/pc_piix.c | 50 ++++++++-------- hw/petalogix_ml605_mmu.c | 8 +-- hw/petalogix_s3adsp1800_mmu.c | 8 +-- hw/ppc/e500plat.c | 13 +++-- hw/ppc/mpc8544ds.c | 13 +++-- hw/ppc405_boards.c | 25 ++++---- hw/ppc440_bamboo.c | 12 ++-- hw/ppc_newworld.c | 13 +++-- hw/ppc_oldworld.c | 13 +++-- hw/ppc_prep.c | 13 +++-- hw/puv3.c | 8 ++- hw/r2d.c | 9 +-- hw/realview.c | 44 +++++++++----- hw/s390-virtio.c | 13 +++-- hw/shix.c | 6 +- hw/spapr.c | 13 +++-- hw/spitz.c | 40 ++++++++----- hw/stellaris.c | 14 ++--- hw/sun4m.c | 133 ++++++++++++++++++++++++++---------------- hw/sun4u.c | 39 ++++++++----- hw/tosa.c | 9 +-- hw/versatilepb.c | 22 ++++--- hw/vexpress.c | 26 +++++---- hw/virtex_ml507.c | 10 ++-- hw/xen_machine_pv.c | 7 +-- hw/xilinx_zynq.c | 9 ++- hw/xtensa_lx60.c | 22 ++++--- hw/xtensa_sim.c | 11 ++-- hw/z2.c | 9 +-- vl.c | 9 ++- 57 files changed, 514 insertions(+), 414 deletions(-) diff --git a/hw/alpha_dp264.c b/hw/alpha_dp264.c index 9eb939f..2c2e237 100644 --- a/hw/alpha_dp264.c +++ b/hw/alpha_dp264.c @@ -42,13 +42,13 @@ static int clipper_pci_map_irq(PCIDevice *d, int irq_num) return (slot + 1) * 4 + irq_num; } -static void clipper_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void clipper_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; CPUAlphaState *cpus[4]; PCIBus *pci_bus; ISABus *isa_bus; diff --git a/hw/an5206.c b/hw/an5206.c index 25407c0..042c5fc 100644 --- a/hw/an5206.c +++ b/hw/an5206.c @@ -19,11 +19,11 @@ /* Board init. */ -static void an5206_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void an5206_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; CPUM68KState *env; int kernel_size; uint64_t elf_entry; diff --git a/hw/axis_dev88.c b/hw/axis_dev88.c index eab6327..2fd7356 100644 --- a/hw/axis_dev88.c +++ b/hw/axis_dev88.c @@ -242,11 +242,12 @@ static const MemoryRegionOps gpio_ops = { static struct cris_load_info li; static -void axisdev88_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +void axisdev88_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; CRISCPU *cpu; CPUCRISState *env; DeviceState *dev; diff --git a/hw/boards.h b/hw/boards.h index a2e0a54..813d0e5 100644 --- a/hw/boards.h +++ b/hw/boards.h @@ -5,12 +5,16 @@ #include "qdev.h" -typedef void QEMUMachineInitFunc(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model); +typedef struct QEMUMachineInitArgs { + ram_addr_t ram_size; + const char *boot_device; + const char *kernel_filename; + const char *kernel_cmdline; + const char *initrd_filename; + const char *cpu_model; +} QEMUMachineInitArgs; + +typedef void QEMUMachineInitFunc(QEMUMachineInitArgs *args); typedef void QEMUMachineResetFunc(void); diff --git a/hw/collie.c b/hw/collie.c index 56f89a9..695982a 100644 --- a/hw/collie.c +++ b/hw/collie.c @@ -23,11 +23,12 @@ static struct arm_boot_info collie_binfo = { .ram_size = 0x20000000, }; -static void collie_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void collie_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; StrongARMState *s; DriveInfo *dinfo; MemoryRegion *sysmem = get_system_memory(); diff --git a/hw/dummy_m68k.c b/hw/dummy_m68k.c index 7cc7a99..f436a0c 100644 --- a/hw/dummy_m68k.c +++ b/hw/dummy_m68k.c @@ -16,11 +16,11 @@ /* Board init. */ -static void dummy_m68k_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void dummy_m68k_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; CPUM68KState *env; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *ram = g_new(MemoryRegion, 1); diff --git a/hw/exynos4_boards.c b/hw/exynos4_boards.c index 4bb0a60..4951064 100644 --- a/hw/exynos4_boards.c +++ b/hw/exynos4_boards.c @@ -130,22 +130,22 @@ static Exynos4210State *exynos4_boards_init_common( exynos4_board_ram_size[board_type]); } -static void nuri_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void nuri_init(QEMUMachineInitArgs *args) { + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; exynos4_boards_init_common(kernel_filename, kernel_cmdline, initrd_filename, EXYNOS4_BOARD_NURI); arm_load_kernel(arm_env_get_cpu(first_cpu), &exynos4_board_binfo); } -static void smdkc210_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void smdkc210_init(QEMUMachineInitArgs *args) { + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; Exynos4210State *s = exynos4_boards_init_common(kernel_filename, kernel_cmdline, initrd_filename, EXYNOS4_BOARD_SMDKC210); diff --git a/hw/gumstix.c b/hw/gumstix.c index 13a36ea..4103a88 100644 --- a/hw/gumstix.c +++ b/hw/gumstix.c @@ -45,10 +45,7 @@ static const int sector_len = 128 * 1024; -static void connex_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void connex_init(QEMUMachineInitArgs *args) { PXA2xxState *cpu; DriveInfo *dinfo; @@ -84,11 +81,9 @@ static void connex_init(ram_addr_t ram_size, qdev_get_gpio_in(cpu->gpio, 36)); } -static void verdex_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void verdex_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; PXA2xxState *cpu; DriveInfo *dinfo; int be; diff --git a/hw/highbank.c b/hw/highbank.c index 11aa131..15036b6 100644 --- a/hw/highbank.c +++ b/hw/highbank.c @@ -187,11 +187,13 @@ static struct arm_boot_info highbank_binfo; * 32-bit host, set the reg value of memory to 0xf7ff00000 in the * device tree and pass -m 2047 to QEMU. */ -static void highbank_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void highbank_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; DeviceState *dev; SysBusDevice *busdev; qemu_irq *irqp; diff --git a/hw/integratorcp.c b/hw/integratorcp.c index d0e2e90..ac0ea83 100644 --- a/hw/integratorcp.c +++ b/hw/integratorcp.c @@ -438,11 +438,13 @@ static struct arm_boot_info integrator_binfo = { .board_id = 0x113, }; -static void integratorcp_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void integratorcp_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; ARMCPU *cpu; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *ram = g_new(MemoryRegion, 1); diff --git a/hw/kzm.c b/hw/kzm.c index 68cd1b4..d1266d9 100644 --- a/hw/kzm.c +++ b/hw/kzm.c @@ -70,11 +70,13 @@ static struct arm_boot_info kzm_binfo = { .board_id = 1722, }; -static void kzm_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void kzm_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; ARMCPU *cpu; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *ram = g_new(MemoryRegion, 1); diff --git a/hw/leon3.c b/hw/leon3.c index 878d3aa..6486b7b 100644 --- a/hw/leon3.c +++ b/hw/leon3.c @@ -94,13 +94,11 @@ static void leon3_set_pil_in(void *opaque, uint32_t pil_in) } } -static void leon3_generic_hw_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void leon3_generic_hw_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; SPARCCPU *cpu; CPUSPARCState *env; MemoryRegion *address_space_mem = get_system_memory(); diff --git a/hw/lm32_boards.c b/hw/lm32_boards.c index b76d800..c5a62c8 100644 --- a/hw/lm32_boards.c +++ b/hw/lm32_boards.c @@ -69,12 +69,10 @@ static void main_cpu_reset(void *opaque) env->deba = reset_info->flash_base; } -static void lm32_evr_init(ram_addr_t ram_size_not_used, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void lm32_evr_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; LM32CPU *cpu; CPULM32State *env; DriveInfo *dinfo; @@ -159,12 +157,12 @@ static void lm32_evr_init(ram_addr_t ram_size_not_used, qemu_register_reset(main_cpu_reset, reset_info); } -static void lm32_uclinux_init(ram_addr_t ram_size_not_used, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void lm32_uclinux_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; LM32CPU *cpu; CPULM32State *env; DriveInfo *dinfo; diff --git a/hw/mainstone.c b/hw/mainstone.c index 97687b6..c0d6034 100644 --- a/hw/mainstone.c +++ b/hw/mainstone.c @@ -171,11 +171,13 @@ static void mainstone_common_init(MemoryRegion *address_space_mem, arm_load_kernel(mpu->cpu, &mainstone_binfo); } -static void mainstone_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void mainstone_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; mainstone_common_init(get_system_memory(), ram_size, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, mainstone, 0x196); } diff --git a/hw/mcf5208.c b/hw/mcf5208.c index ee25b1b..688bc3c 100644 --- a/hw/mcf5208.c +++ b/hw/mcf5208.c @@ -187,11 +187,11 @@ static void mcf5208_sys_init(MemoryRegion *address_space, qemu_irq *pic) } } -static void mcf5208evb_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void mcf5208evb_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; CPUM68KState *env; int kernel_size; uint64_t elf_entry; diff --git a/hw/milkymist.c b/hw/milkymist.c index 2e7235b..ca9ed43 100644 --- a/hw/milkymist.c +++ b/hw/milkymist.c @@ -73,12 +73,12 @@ static void main_cpu_reset(void *opaque) } static void -milkymist_init(ram_addr_t ram_size_not_used, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +milkymist_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; LM32CPU *cpu; CPULM32State *env; int kernel_size; diff --git a/hw/mips_fulong2e.c b/hw/mips_fulong2e.c index 38e4b86..af7bb50 100644 --- a/hw/mips_fulong2e.c +++ b/hw/mips_fulong2e.c @@ -256,10 +256,13 @@ static void cpu_request_exit(void *opaque, int irq, int level) } } -static void mips_fulong2e_init(ram_addr_t ram_size, const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void mips_fulong2e_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; char *filename; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *ram = g_new(MemoryRegion, 1); diff --git a/hw/mips_jazz.c b/hw/mips_jazz.c index db927f1..14df4d7 100644 --- a/hw/mips_jazz.c +++ b/hw/mips_jazz.c @@ -302,21 +302,19 @@ static void mips_jazz_init(MemoryRegion *address_space, } static -void mips_magnum_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +void mips_magnum_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; mips_jazz_init(get_system_memory(), get_system_io(), ram_size, cpu_model, JAZZ_MAGNUM); } static -void mips_pica61_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +void mips_pica61_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; mips_jazz_init(get_system_memory(), get_system_io(), ram_size, cpu_model, JAZZ_PICA61); } diff --git a/hw/mips_malta.c b/hw/mips_malta.c index ad23f26..14151f9 100644 --- a/hw/mips_malta.c +++ b/hw/mips_malta.c @@ -777,11 +777,13 @@ static void cpu_request_exit(void *opaque, int irq, int level) } static -void mips_malta_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +void mips_malta_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; char *filename; pflash_t *fl; MemoryRegion *system_memory = get_system_memory(); diff --git a/hw/mips_mipssim.c b/hw/mips_mipssim.c index 830f635..a1d3945 100644 --- a/hw/mips_mipssim.c +++ b/hw/mips_mipssim.c @@ -131,11 +131,13 @@ static void mipsnet_init(int base, qemu_irq irq, NICInfo *nd) } static void -mips_mipssim_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +mips_mipssim_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; char *filename; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *ram = g_new(MemoryRegion, 1); diff --git a/hw/mips_r4k.c b/hw/mips_r4k.c index 967a76e..b73cdc3 100644 --- a/hw/mips_r4k.c +++ b/hw/mips_r4k.c @@ -151,11 +151,13 @@ static void main_cpu_reset(void *opaque) static const int sector_len = 32 * 1024; static -void mips_r4k_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +void mips_r4k_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; char *filename; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *ram = g_new(MemoryRegion, 1); diff --git a/hw/musicpal.c b/hw/musicpal.c index f305e21..f06814c 100644 --- a/hw/musicpal.c +++ b/hw/musicpal.c @@ -1508,11 +1508,12 @@ static struct arm_boot_info musicpal_binfo = { .board_id = 0x20e, }; -static void musicpal_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void musicpal_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; ARMCPU *cpu; qemu_irq *cpu_pic; qemu_irq pic[32]; diff --git a/hw/nseries.c b/hw/nseries.c index 6df71eb..7ada90d 100644 --- a/hw/nseries.c +++ b/hw/nseries.c @@ -1397,21 +1397,27 @@ static struct arm_boot_info n810_binfo = { .atag_board = n810_atag_setup, }; -static void n800_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void n800_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; return n8x0_init(ram_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, &n800_binfo, 800); } -static void n810_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void n810_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; return n8x0_init(ram_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, &n810_binfo, 810); diff --git a/hw/null-machine.c b/hw/null-machine.c index 69910d3..d813c08 100644 --- a/hw/null-machine.c +++ b/hw/null-machine.c @@ -15,12 +15,7 @@ #include "hw/hw.h" #include "hw/boards.h" -static void machine_none_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void machine_none_init(QEMUMachineInitArgs *args) { } diff --git a/hw/omap_sx1.c b/hw/omap_sx1.c index abca341..ad17487 100644 --- a/hw/omap_sx1.c +++ b/hw/omap_sx1.c @@ -209,20 +209,26 @@ static void sx1_init(ram_addr_t ram_size, //~ qemu_console_resize(ds, 640, 480); } -static void sx1_init_v1(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void sx1_init_v1(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sx1_init(ram_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, 1); } -static void sx1_init_v2(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void sx1_init_v2(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sx1_init(ram_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, 2); } diff --git a/hw/openrisc_sim.c b/hw/openrisc_sim.c index 55e97f0..e96a944 100644 --- a/hw/openrisc_sim.c +++ b/hw/openrisc_sim.c @@ -90,13 +90,11 @@ static void cpu_openrisc_load_kernel(ram_addr_t ram_size, cpu->env.pc = entry; } -static void openrisc_sim_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void openrisc_sim_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; OpenRISCCPU *cpu = NULL; MemoryRegion *ram; int n; diff --git a/hw/palm.c b/hw/palm.c index bacdc90..032b8d6 100644 --- a/hw/palm.c +++ b/hw/palm.c @@ -190,11 +190,12 @@ static struct arm_boot_info palmte_binfo = { .board_id = 0x331, }; -static void palmte_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void palmte_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; MemoryRegion *address_space_mem = get_system_memory(); struct omap_mpu_state_s *mpu; int flash_size = 0x00800000; diff --git a/hw/pc_piix.c b/hw/pc_piix.c index fd5898f..c9fca05 100644 --- a/hw/pc_piix.c +++ b/hw/pc_piix.c @@ -287,13 +287,14 @@ static void pc_init1(MemoryRegion *system_memory, } } -static void pc_init_pci(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void pc_init_pci(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; pc_init1(get_system_memory(), get_system_io(), ram_size, boot_device, @@ -301,13 +302,14 @@ static void pc_init_pci(ram_addr_t ram_size, initrd_filename, cpu_model, 1, 1); } -static void pc_init_pci_no_kvmclock(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void pc_init_pci_no_kvmclock(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; pc_init1(get_system_memory(), get_system_io(), ram_size, boot_device, @@ -315,13 +317,14 @@ static void pc_init_pci_no_kvmclock(ram_addr_t ram_size, initrd_filename, cpu_model, 1, 0); } -static void pc_init_isa(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void pc_init_isa(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; if (cpu_model == NULL) cpu_model = "486"; pc_init1(get_system_memory(), @@ -332,19 +335,12 @@ static void pc_init_isa(ram_addr_t ram_size, } #ifdef CONFIG_XEN -static void pc_xen_hvm_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void pc_xen_hvm_init(QEMUMachineInitArgs *args) { if (xen_hvm_init() != 0) { hw_error("xen hardware virtual machine initialisation failed"); } - pc_init_pci_no_kvmclock(ram_size, boot_device, - kernel_filename, kernel_cmdline, - initrd_filename, cpu_model); + pc_init_pci_no_kvmclock(args); xen_vcpu_init(); } #endif diff --git a/hw/petalogix_ml605_mmu.c b/hw/petalogix_ml605_mmu.c index dced648..ace0187 100644 --- a/hw/petalogix_ml605_mmu.c +++ b/hw/petalogix_ml605_mmu.c @@ -70,12 +70,10 @@ static void machine_cpu_reset(MicroBlazeCPU *cpu) } static void -petalogix_ml605_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +petalogix_ml605_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; MemoryRegion *address_space_mem = get_system_memory(); DeviceState *dev, *dma, *eth0; MicroBlazeCPU *cpu; diff --git a/hw/petalogix_s3adsp1800_mmu.c b/hw/petalogix_s3adsp1800_mmu.c index 2cf6882..71c32ce 100644 --- a/hw/petalogix_s3adsp1800_mmu.c +++ b/hw/petalogix_s3adsp1800_mmu.c @@ -57,12 +57,10 @@ static void machine_cpu_reset(MicroBlazeCPU *cpu) } static void -petalogix_s3adsp1800_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +petalogix_s3adsp1800_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; DeviceState *dev; MicroBlazeCPU *cpu; CPUMBState *env; diff --git a/hw/ppc/e500plat.c b/hw/ppc/e500plat.c index 60a5cb3..4cfb940 100644 --- a/hw/ppc/e500plat.c +++ b/hw/ppc/e500plat.c @@ -25,13 +25,14 @@ static void e500plat_fixup_devtree(PPCE500Params *params, void *fdt) sizeof(compatible)); } -static void e500plat_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void e500plat_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *boot_device = args->boot_device; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; PPCE500Params params = { .ram_size = ram_size, .boot_device = boot_device, diff --git a/hw/ppc/mpc8544ds.c b/hw/ppc/mpc8544ds.c index 984d21c..e651661 100644 --- a/hw/ppc/mpc8544ds.c +++ b/hw/ppc/mpc8544ds.c @@ -25,13 +25,14 @@ static void mpc8544ds_fixup_devtree(PPCE500Params *params, void *fdt) sizeof(compatible)); } -static void mpc8544ds_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void mpc8544ds_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *boot_device = args->boot_device; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; PPCE500Params params = { .ram_size = ram_size, .boot_device = boot_device, diff --git a/hw/ppc405_boards.c b/hw/ppc405_boards.c index 476775d..e848cb0 100644 --- a/hw/ppc405_boards.c +++ b/hw/ppc405_boards.c @@ -158,7 +158,7 @@ static void ref405ep_fpga_reset (void *opaque) fpga->reg1 = 0x0F; } -static void ref405ep_fpga_init (MemoryRegion *sysmem, uint32_t base) +static void ref405ep_fpga_init(MemoryRegion *sysmem, uint32_t base) { ref405ep_fpga_t *fpga; MemoryRegion *fpga_memory = g_new(MemoryRegion, 1); @@ -170,13 +170,12 @@ static void ref405ep_fpga_init (MemoryRegion *sysmem, uint32_t base) qemu_register_reset(&ref405ep_fpga_reset, fpga); } -static void ref405ep_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void ref405ep_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; char *filename; ppc4xx_bd_info_t bd; CPUPPCState *env; @@ -484,7 +483,7 @@ static void taihu_cpld_reset (void *opaque) cpld->reg1 = 0x80; } -static void taihu_cpld_init (MemoryRegion *sysmem, uint32_t base) +static void taihu_cpld_init(MemoryRegion *sysmem, uint32_t base) { taihu_cpld_t *cpld; MemoryRegion *cpld_memory = g_new(MemoryRegion, 1); @@ -495,13 +494,11 @@ static void taihu_cpld_init (MemoryRegion *sysmem, uint32_t base) qemu_register_reset(&taihu_cpld_reset, cpld); } -static void taihu_405ep_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void taihu_405ep_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *kernel_filename = args->kernel_filename; + const char *initrd_filename = args->initrd_filename; char *filename; qemu_irq *pic; MemoryRegion *sysmem = get_system_memory(); diff --git a/hw/ppc440_bamboo.c b/hw/ppc440_bamboo.c index c198071..78e7985 100644 --- a/hw/ppc440_bamboo.c +++ b/hw/ppc440_bamboo.c @@ -157,13 +157,13 @@ static void main_cpu_reset(void *opaque) mmubooke_create_initial_mapping(env, 0, 0); } -static void bamboo_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void bamboo_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; unsigned int pci_irq_nrs[4] = { 28, 27, 26, 25 }; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *ram_memories diff --git a/hw/ppc_newworld.c b/hw/ppc_newworld.c index e95cfe8..e7c0747 100644 --- a/hw/ppc_newworld.c +++ b/hw/ppc_newworld.c @@ -129,13 +129,14 @@ static void ppc_core99_reset(void *opaque) } /* PowerPC Mac99 hardware initialisation */ -static void ppc_core99_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void ppc_core99_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; PowerPCCPU *cpu = NULL; CPUPPCState *env = NULL; char *filename; diff --git a/hw/ppc_oldworld.c b/hw/ppc_oldworld.c index 1dcd8a6..d9f76a8 100644 --- a/hw/ppc_oldworld.c +++ b/hw/ppc_oldworld.c @@ -72,13 +72,14 @@ static void ppc_heathrow_reset(void *opaque) cpu_reset(CPU(cpu)); } -static void ppc_heathrow_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void ppc_heathrow_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; MemoryRegion *sysmem = get_system_memory(); PowerPCCPU *cpu = NULL; CPUPPCState *env = NULL; diff --git a/hw/ppc_prep.c b/hw/ppc_prep.c index 592b7b2..f51f78a 100644 --- a/hw/ppc_prep.c +++ b/hw/ppc_prep.c @@ -448,13 +448,14 @@ static void ppc_prep_reset(void *opaque) } /* PowerPC PREP hardware initialisation */ -static void ppc_prep_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void ppc_prep_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; MemoryRegion *sysmem = get_system_memory(); PowerPCCPU *cpu = NULL; CPUPPCState *env = NULL; diff --git a/hw/puv3.c b/hw/puv3.c index 43f7216..764799c 100644 --- a/hw/puv3.c +++ b/hw/puv3.c @@ -91,10 +91,12 @@ static void puv3_load_kernel(const char *kernel_filename) graphic_console_init(NULL, NULL, NULL, NULL, NULL); } -static void puv3_init(ram_addr_t ram_size, const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void puv3_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *initrd_filename = args->initrd_filename; CPUUniCore32State *env; if (initrd_filename) { diff --git a/hw/r2d.c b/hw/r2d.c index 0f16e81..5daa42f 100644 --- a/hw/r2d.c +++ b/hw/r2d.c @@ -219,11 +219,12 @@ static struct QEMU_PACKED char kernel_cmdline[256]; } boot_params; -static void r2d_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void r2d_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; SuperHCPU *cpu; CPUSH4State *env; ResetData *reset_info; diff --git a/hw/realview.c b/hw/realview.c index 19db4d0..8dc4be6 100644 --- a/hw/realview.c +++ b/hw/realview.c @@ -330,11 +330,14 @@ static void realview_init(ram_addr_t ram_size, arm_load_kernel(arm_env_get_cpu(first_cpu), &realview_binfo); } -static void realview_eb_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void realview_eb_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; if (!cpu_model) { cpu_model = "arm926"; } @@ -342,11 +345,14 @@ static void realview_eb_init(ram_addr_t ram_size, initrd_filename, cpu_model, BOARD_EB); } -static void realview_eb_mpcore_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void realview_eb_mpcore_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; if (!cpu_model) { cpu_model = "arm11mpcore"; } @@ -354,11 +360,14 @@ static void realview_eb_mpcore_init(ram_addr_t ram_size, initrd_filename, cpu_model, BOARD_EB_MPCORE); } -static void realview_pb_a8_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void realview_pb_a8_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; if (!cpu_model) { cpu_model = "cortex-a8"; } @@ -366,11 +375,14 @@ static void realview_pb_a8_init(ram_addr_t ram_size, initrd_filename, cpu_model, BOARD_PB_A8); } -static void realview_pbx_a9_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void realview_pbx_a9_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; if (!cpu_model) { cpu_model = "cortex-a9"; } diff --git a/hw/s390-virtio.c b/hw/s390-virtio.c index 47eed35..39ff178 100644 --- a/hw/s390-virtio.c +++ b/hw/s390-virtio.c @@ -151,13 +151,14 @@ unsigned s390_del_running_cpu(CPUS390XState *env) } /* PC hardware initialisation */ -static void s390_init(ram_addr_t my_ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void s390_init(QEMUMachineInitArgs *args) { + ram_addr_t my_ram_size = args->ram_size; + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; CPUS390XState *env = NULL; MemoryRegion *sysmem = get_system_memory(); MemoryRegion *ram = g_new(MemoryRegion, 1); diff --git a/hw/shix.c b/hw/shix.c index dd9ce17..b56dd54 100644 --- a/hw/shix.c +++ b/hw/shix.c @@ -37,11 +37,9 @@ #define BIOS_FILENAME "shix_bios.bin" #define BIOS_ADDRESS 0xA0000000 -static void shix_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void shix_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; int ret; CPUSH4State *env; struct SH7750State *s; diff --git a/hw/spapr.c b/hw/spapr.c index c34b767..8921c4d 100644 --- a/hw/spapr.c +++ b/hw/spapr.c @@ -603,13 +603,14 @@ static int spapr_vga_init(PCIBus *pci_bus) } /* pSeries LPAR / sPAPR hardware init */ -static void ppc_spapr_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void ppc_spapr_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; PowerPCCPU *cpu; CPUPPCState *env; PCIHostState *phb; diff --git a/hw/spitz.c b/hw/spitz.c index 20e7835..df829b3 100644 --- a/hw/spitz.c +++ b/hw/spitz.c @@ -936,38 +936,46 @@ static void spitz_common_init(ram_addr_t ram_size, sl_bootparam_write(SL_PXA_PARAM_BASE); } -static void spitz_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void spitz_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; spitz_common_init(ram_size, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, spitz, 0x2c9); } -static void borzoi_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void borzoi_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; spitz_common_init(ram_size, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, borzoi, 0x33f); } -static void akita_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void akita_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; spitz_common_init(ram_size, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, akita, 0x2e8); } -static void terrier_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void terrier_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; spitz_common_init(ram_size, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, terrier, 0x33f); } diff --git a/hw/stellaris.c b/hw/stellaris.c index 562fbbf..b79c7fb 100644 --- a/hw/stellaris.c +++ b/hw/stellaris.c @@ -1358,19 +1358,17 @@ static void stellaris_init(const char *kernel_filename, const char *cpu_model, } /* FIXME: Figure out how to generate these from stellaris_boards. */ -static void lm3s811evb_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void lm3s811evb_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; stellaris_init(kernel_filename, cpu_model, &stellaris_boards[0]); } -static void lm3s6965evb_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void lm3s6965evb_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; stellaris_init(kernel_filename, cpu_model, &stellaris_boards[1]); } diff --git a/hw/sun4m.c b/hw/sun4m.c index c98cd5e..22e011f 100644 --- a/hw/sun4m.c +++ b/hw/sun4m.c @@ -1303,92 +1303,118 @@ static const struct sun4m_hwdef sun4m_hwdefs[] = { }; /* SPARCstation 5 hardware initialisation */ -static void ss5_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss5_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[0], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCstation 10 hardware initialisation */ -static void ss10_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss10_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[1], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCserver 600MP hardware initialisation */ -static void ss600mp_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss600mp_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[2], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCstation 20 hardware initialisation */ -static void ss20_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss20_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[3], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCstation Voyager hardware initialisation */ -static void vger_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void vger_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[4], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCstation LX hardware initialisation */ -static void ss_lx_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss_lx_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[5], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCstation 4 hardware initialisation */ -static void ss4_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss4_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[6], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCClassic hardware initialisation */ -static void scls_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void scls_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[7], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCbook hardware initialisation */ -static void sbook_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void sbook_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[8], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } @@ -1651,21 +1677,27 @@ static void sun4d_hw_init(const struct sun4d_hwdef *hwdef, ram_addr_t RAM_size, } /* SPARCserver 1000 hardware initialisation */ -static void ss1000_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss1000_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4d_hw_init(&sun4d_hwdefs[0], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCcenter 2000 hardware initialisation */ -static void ss2000_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss2000_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4d_hw_init(&sun4d_hwdefs[1], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } @@ -1845,11 +1877,14 @@ static void sun4c_hw_init(const struct sun4c_hwdef *hwdef, ram_addr_t RAM_size, } /* SPARCstation 2 hardware initialisation */ -static void ss2_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss2_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4c_hw_init(&sun4c_hwdefs[0], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } diff --git a/hw/sun4u.c b/hw/sun4u.c index 07cd042..379768c 100644 --- a/hw/sun4u.c +++ b/hw/sun4u.c @@ -930,31 +930,40 @@ static const struct hwdef hwdefs[] = { }; /* Sun4u hardware initialisation */ -static void sun4u_init(ram_addr_t RAM_size, - const char *boot_devices, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) -{ +static void sun4u_init(QEMUMachineInitArgs *args) +{ + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_devices = args->boot_device; sun4uv_init(get_system_memory(), RAM_size, boot_devices, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, &hwdefs[0]); } /* Sun4v hardware initialisation */ -static void sun4v_init(ram_addr_t RAM_size, - const char *boot_devices, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) -{ +static void sun4v_init(QEMUMachineInitArgs *args) +{ + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_devices = args->boot_device; sun4uv_init(get_system_memory(), RAM_size, boot_devices, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, &hwdefs[1]); } /* Niagara hardware initialisation */ -static void niagara_init(ram_addr_t RAM_size, - const char *boot_devices, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) -{ +static void niagara_init(QEMUMachineInitArgs *args) +{ + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_devices = args->boot_device; sun4uv_init(get_system_memory(), RAM_size, boot_devices, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, &hwdefs[2]); } diff --git a/hw/tosa.c b/hw/tosa.c index 297a8c2..512278c 100644 --- a/hw/tosa.c +++ b/hw/tosa.c @@ -205,11 +205,12 @@ static struct arm_boot_info tosa_binfo = { .ram_size = 0x04000000, }; -static void tosa_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void tosa_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *rom = g_new(MemoryRegion, 1); PXA2xxState *mpu; diff --git a/hw/versatilepb.c b/hw/versatilepb.c index 7a92034..686dcc7 100644 --- a/hw/versatilepb.c +++ b/hw/versatilepb.c @@ -342,22 +342,28 @@ static void versatile_init(ram_addr_t ram_size, arm_load_kernel(cpu, &versatile_binfo); } -static void vpb_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void vpb_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; versatile_init(ram_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, 0x183); } -static void vab_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void vab_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; versatile_init(ram_size, boot_device, kernel_filename, kernel_cmdline, diff --git a/hw/vexpress.c b/hw/vexpress.c index 3596d1e..36503d6 100644 --- a/hw/vexpress.c +++ b/hw/vexpress.c @@ -467,25 +467,27 @@ static void vexpress_common_init(const VEDBoardInfo *daughterboard, arm_load_kernel(arm_env_get_cpu(first_cpu), &vexpress_binfo); } -static void vexpress_a9_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void vexpress_a9_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; vexpress_common_init(&a9_daughterboard, ram_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } -static void vexpress_a15_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void vexpress_a15_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; vexpress_common_init(&a15_daughterboard, ram_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); diff --git a/hw/virtex_ml507.c b/hw/virtex_ml507.c index 79bc0d1..a09b27a 100644 --- a/hw/virtex_ml507.c +++ b/hw/virtex_ml507.c @@ -183,12 +183,12 @@ static int xilinx_load_device_tree(target_phys_addr_t addr, return fdt_size; } -static void virtex_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void virtex_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; MemoryRegion *address_space_mem = get_system_memory(); DeviceState *dev; PowerPCCPU *cpu; diff --git a/hw/xen_machine_pv.c b/hw/xen_machine_pv.c index 4b72aa7..50aba34 100644 --- a/hw/xen_machine_pv.c +++ b/hw/xen_machine_pv.c @@ -29,12 +29,7 @@ #include "xen_domainbuild.h" #include "blockdev.h" -static void xen_init_pv(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void xen_init_pv(QEMUMachineInitArgs *args) { X86CPU *cpu; CPUX86State *env; diff --git a/hw/xilinx_zynq.c b/hw/xilinx_zynq.c index 7e6c273..83f322e 100644 --- a/hw/xilinx_zynq.c +++ b/hw/xilinx_zynq.c @@ -46,10 +46,13 @@ static void gem_init(NICInfo *nd, uint32_t base, qemu_irq irq) sysbus_connect_irq(s, 0, irq); } -static void zynq_init(ram_addr_t ram_size, const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void zynq_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; ARMCPU *cpu; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *ext_ram = g_new(MemoryRegion, 1); diff --git a/hw/xtensa_lx60.c b/hw/xtensa_lx60.c index 3653f65..1fd2c47 100644 --- a/hw/xtensa_lx60.c +++ b/hw/xtensa_lx60.c @@ -268,11 +268,14 @@ static void lx_init(const LxBoardDesc *board, } } -static void xtensa_lx60_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void xtensa_lx60_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; static const LxBoardDesc lx60_board = { .flash_size = 0x400000, .flash_sector_size = 0x10000, @@ -283,11 +286,14 @@ static void xtensa_lx60_init(ram_addr_t ram_size, initrd_filename, cpu_model); } -static void xtensa_lx200_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void xtensa_lx200_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; static const LxBoardDesc lx200_board = { .flash_size = 0x1000000, .flash_sector_size = 0x20000, diff --git a/hw/xtensa_sim.c b/hw/xtensa_sim.c index 831460b..2e846d8 100644 --- a/hw/xtensa_sim.c +++ b/hw/xtensa_sim.c @@ -96,11 +96,14 @@ static void sim_init(ram_addr_t ram_size, } } -static void xtensa_sim_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void xtensa_sim_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; if (!cpu_model) { cpu_model = XTENSA_DEFAULT_CPU_MODEL; } diff --git a/hw/z2.c b/hw/z2.c index 289cee9..0927bad 100644 --- a/hw/z2.c +++ b/hw/z2.c @@ -294,11 +294,12 @@ static TypeInfo aer915_info = { .class_init = aer915_class_init, }; -static void z2_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void z2_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; MemoryRegion *address_space_mem = get_system_memory(); uint32_t sector_len = 0x10000; PXA2xxState *mpu; diff --git a/vl.c b/vl.c index 8d305ca..f663e7c 100644 --- a/vl.c +++ b/vl.c @@ -3624,8 +3624,13 @@ int main(int argc, char **argv, char **envp) qdev_machine_init(); - machine->init(ram_size, boot_devices, - kernel_filename, kernel_cmdline, initrd_filename, cpu_model); + QEMUMachineInitArgs args = { .ram_size = ram_size, + .boot_device = boot_devices, + .kernel_filename = kernel_filename, + .kernel_cmdline = kernel_cmdline, + initrd_filename = initrd_filename, + .cpu_model = cpu_model }; + machine->init(&args); cpu_synchronize_all_post_init(); -- 1.7.11.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 20:22:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 20:22:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKEPG-00079H-Sf; Fri, 05 Oct 2012 20:21:58 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with smtp (Exim 4.72) (envelope-from ) id 1TKEPF-00079A-6z for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 20:21:57 +0000 X-Env-Sender: ehabkost@redhat.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1349468509!1785447!1 X-Originating-IP: [209.132.183.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTcwODY=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32430 invoked from network); 5 Oct 2012 20:21:49 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-14.tower-27.messagelabs.com with SMTP; 5 Oct 2012 20:21:49 -0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q95KLJvR032621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Oct 2012 16:21:19 -0400 Received: from blackpad.lan.raisama.net (vpn1-7-193.gru2.redhat.com [10.97.7.193]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q95KLHg2020961; Fri, 5 Oct 2012 16:21:17 -0400 Received: by blackpad.lan.raisama.net (Postfix, from userid 500) id 61DFB203604; Fri, 5 Oct 2012 17:22:17 -0300 (BRT) From: Eduardo Habkost To: qemu-devel@nongnu.org Date: Fri, 5 Oct 2012 17:22:15 -0300 Message-Id: <1349468535-14499-1-git-send-email-ehabkost@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Cc: Peter Maydell , Evgeny Voevodin , Peter Crosthwaite , Max Filippov , "Edgar E. Iglesias" , Guan Xuetao , xen-devel@lists.xensource.com, Igor Mitsyanko , Magnus Damm , Alexander Graf , =?UTF-8?q?Herv=C3=A9=20Poussineau?= , Maksim Kozlov , Andrzej Zaborowski , Fabien Chouteau , Jan Kiszka , Paul Brook , Blue Swirl , Anthony Liguori , Michael Walle , qemu-ppc@nongnu.org, Dmitry Solodkiy , Aurelien Jarno Subject: [Xen-devel] [QEMU PATCH] create struct for machine initialization arguments (v2) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This should help us to: - More easily add or remove machine initialization arguments without having to change every single machine init function; - More easily make mechanical changes involving the machine init functions in the future; - Let machine initialization forward the init arguments to other functions more easily. This change was half-mechanical process: first the struct was added with the local ram_size, boot_device, kernel_*, initrd_*, and cpu_model local variable initialization to all functions. Then the compiler helped me locate the local variables that are unused, so they could be removed. Changes v1 -> v2: - Fix mistake on the conversion of pc_xen_hvm_init() and xen_init_pv() Signed-off-by: Eduardo Habkost --- hw/alpha_dp264.c | 12 ++-- hw/an5206.c | 8 +-- hw/axis_dev88.c | 9 +-- hw/boards.h | 16 +++-- hw/collie.c | 9 +-- hw/dummy_m68k.c | 8 +-- hw/exynos4_boards.c | 16 ++--- hw/gumstix.c | 11 +--- hw/highbank.c | 10 ++-- hw/integratorcp.c | 10 ++-- hw/kzm.c | 10 ++-- hw/leon3.c | 10 ++-- hw/lm32_boards.c | 18 +++--- hw/mainstone.c | 10 ++-- hw/mcf5208.c | 8 +-- hw/milkymist.c | 10 ++-- hw/mips_fulong2e.c | 9 ++- hw/mips_jazz.c | 14 ++--- hw/mips_malta.c | 10 ++-- hw/mips_mipssim.c | 10 ++-- hw/mips_r4k.c | 10 ++-- hw/musicpal.c | 9 +-- hw/nseries.c | 22 ++++--- hw/null-machine.c | 7 +-- hw/omap_sx1.c | 22 ++++--- hw/openrisc_sim.c | 10 ++-- hw/palm.c | 9 +-- hw/pc_piix.c | 50 ++++++++-------- hw/petalogix_ml605_mmu.c | 8 +-- hw/petalogix_s3adsp1800_mmu.c | 8 +-- hw/ppc/e500plat.c | 13 +++-- hw/ppc/mpc8544ds.c | 13 +++-- hw/ppc405_boards.c | 25 ++++---- hw/ppc440_bamboo.c | 12 ++-- hw/ppc_newworld.c | 13 +++-- hw/ppc_oldworld.c | 13 +++-- hw/ppc_prep.c | 13 +++-- hw/puv3.c | 8 ++- hw/r2d.c | 9 +-- hw/realview.c | 44 +++++++++----- hw/s390-virtio.c | 13 +++-- hw/shix.c | 6 +- hw/spapr.c | 13 +++-- hw/spitz.c | 40 ++++++++----- hw/stellaris.c | 14 ++--- hw/sun4m.c | 133 ++++++++++++++++++++++++++---------------- hw/sun4u.c | 39 ++++++++----- hw/tosa.c | 9 +-- hw/versatilepb.c | 22 ++++--- hw/vexpress.c | 26 +++++---- hw/virtex_ml507.c | 10 ++-- hw/xen_machine_pv.c | 7 +-- hw/xilinx_zynq.c | 9 ++- hw/xtensa_lx60.c | 22 ++++--- hw/xtensa_sim.c | 11 ++-- hw/z2.c | 9 +-- vl.c | 9 ++- 57 files changed, 514 insertions(+), 414 deletions(-) diff --git a/hw/alpha_dp264.c b/hw/alpha_dp264.c index 9eb939f..2c2e237 100644 --- a/hw/alpha_dp264.c +++ b/hw/alpha_dp264.c @@ -42,13 +42,13 @@ static int clipper_pci_map_irq(PCIDevice *d, int irq_num) return (slot + 1) * 4 + irq_num; } -static void clipper_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void clipper_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; CPUAlphaState *cpus[4]; PCIBus *pci_bus; ISABus *isa_bus; diff --git a/hw/an5206.c b/hw/an5206.c index 25407c0..042c5fc 100644 --- a/hw/an5206.c +++ b/hw/an5206.c @@ -19,11 +19,11 @@ /* Board init. */ -static void an5206_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void an5206_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; CPUM68KState *env; int kernel_size; uint64_t elf_entry; diff --git a/hw/axis_dev88.c b/hw/axis_dev88.c index eab6327..2fd7356 100644 --- a/hw/axis_dev88.c +++ b/hw/axis_dev88.c @@ -242,11 +242,12 @@ static const MemoryRegionOps gpio_ops = { static struct cris_load_info li; static -void axisdev88_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +void axisdev88_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; CRISCPU *cpu; CPUCRISState *env; DeviceState *dev; diff --git a/hw/boards.h b/hw/boards.h index a2e0a54..813d0e5 100644 --- a/hw/boards.h +++ b/hw/boards.h @@ -5,12 +5,16 @@ #include "qdev.h" -typedef void QEMUMachineInitFunc(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model); +typedef struct QEMUMachineInitArgs { + ram_addr_t ram_size; + const char *boot_device; + const char *kernel_filename; + const char *kernel_cmdline; + const char *initrd_filename; + const char *cpu_model; +} QEMUMachineInitArgs; + +typedef void QEMUMachineInitFunc(QEMUMachineInitArgs *args); typedef void QEMUMachineResetFunc(void); diff --git a/hw/collie.c b/hw/collie.c index 56f89a9..695982a 100644 --- a/hw/collie.c +++ b/hw/collie.c @@ -23,11 +23,12 @@ static struct arm_boot_info collie_binfo = { .ram_size = 0x20000000, }; -static void collie_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void collie_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; StrongARMState *s; DriveInfo *dinfo; MemoryRegion *sysmem = get_system_memory(); diff --git a/hw/dummy_m68k.c b/hw/dummy_m68k.c index 7cc7a99..f436a0c 100644 --- a/hw/dummy_m68k.c +++ b/hw/dummy_m68k.c @@ -16,11 +16,11 @@ /* Board init. */ -static void dummy_m68k_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void dummy_m68k_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; CPUM68KState *env; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *ram = g_new(MemoryRegion, 1); diff --git a/hw/exynos4_boards.c b/hw/exynos4_boards.c index 4bb0a60..4951064 100644 --- a/hw/exynos4_boards.c +++ b/hw/exynos4_boards.c @@ -130,22 +130,22 @@ static Exynos4210State *exynos4_boards_init_common( exynos4_board_ram_size[board_type]); } -static void nuri_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void nuri_init(QEMUMachineInitArgs *args) { + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; exynos4_boards_init_common(kernel_filename, kernel_cmdline, initrd_filename, EXYNOS4_BOARD_NURI); arm_load_kernel(arm_env_get_cpu(first_cpu), &exynos4_board_binfo); } -static void smdkc210_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void smdkc210_init(QEMUMachineInitArgs *args) { + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; Exynos4210State *s = exynos4_boards_init_common(kernel_filename, kernel_cmdline, initrd_filename, EXYNOS4_BOARD_SMDKC210); diff --git a/hw/gumstix.c b/hw/gumstix.c index 13a36ea..4103a88 100644 --- a/hw/gumstix.c +++ b/hw/gumstix.c @@ -45,10 +45,7 @@ static const int sector_len = 128 * 1024; -static void connex_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void connex_init(QEMUMachineInitArgs *args) { PXA2xxState *cpu; DriveInfo *dinfo; @@ -84,11 +81,9 @@ static void connex_init(ram_addr_t ram_size, qdev_get_gpio_in(cpu->gpio, 36)); } -static void verdex_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void verdex_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; PXA2xxState *cpu; DriveInfo *dinfo; int be; diff --git a/hw/highbank.c b/hw/highbank.c index 11aa131..15036b6 100644 --- a/hw/highbank.c +++ b/hw/highbank.c @@ -187,11 +187,13 @@ static struct arm_boot_info highbank_binfo; * 32-bit host, set the reg value of memory to 0xf7ff00000 in the * device tree and pass -m 2047 to QEMU. */ -static void highbank_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void highbank_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; DeviceState *dev; SysBusDevice *busdev; qemu_irq *irqp; diff --git a/hw/integratorcp.c b/hw/integratorcp.c index d0e2e90..ac0ea83 100644 --- a/hw/integratorcp.c +++ b/hw/integratorcp.c @@ -438,11 +438,13 @@ static struct arm_boot_info integrator_binfo = { .board_id = 0x113, }; -static void integratorcp_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void integratorcp_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; ARMCPU *cpu; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *ram = g_new(MemoryRegion, 1); diff --git a/hw/kzm.c b/hw/kzm.c index 68cd1b4..d1266d9 100644 --- a/hw/kzm.c +++ b/hw/kzm.c @@ -70,11 +70,13 @@ static struct arm_boot_info kzm_binfo = { .board_id = 1722, }; -static void kzm_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void kzm_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; ARMCPU *cpu; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *ram = g_new(MemoryRegion, 1); diff --git a/hw/leon3.c b/hw/leon3.c index 878d3aa..6486b7b 100644 --- a/hw/leon3.c +++ b/hw/leon3.c @@ -94,13 +94,11 @@ static void leon3_set_pil_in(void *opaque, uint32_t pil_in) } } -static void leon3_generic_hw_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void leon3_generic_hw_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; SPARCCPU *cpu; CPUSPARCState *env; MemoryRegion *address_space_mem = get_system_memory(); diff --git a/hw/lm32_boards.c b/hw/lm32_boards.c index b76d800..c5a62c8 100644 --- a/hw/lm32_boards.c +++ b/hw/lm32_boards.c @@ -69,12 +69,10 @@ static void main_cpu_reset(void *opaque) env->deba = reset_info->flash_base; } -static void lm32_evr_init(ram_addr_t ram_size_not_used, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void lm32_evr_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; LM32CPU *cpu; CPULM32State *env; DriveInfo *dinfo; @@ -159,12 +157,12 @@ static void lm32_evr_init(ram_addr_t ram_size_not_used, qemu_register_reset(main_cpu_reset, reset_info); } -static void lm32_uclinux_init(ram_addr_t ram_size_not_used, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void lm32_uclinux_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; LM32CPU *cpu; CPULM32State *env; DriveInfo *dinfo; diff --git a/hw/mainstone.c b/hw/mainstone.c index 97687b6..c0d6034 100644 --- a/hw/mainstone.c +++ b/hw/mainstone.c @@ -171,11 +171,13 @@ static void mainstone_common_init(MemoryRegion *address_space_mem, arm_load_kernel(mpu->cpu, &mainstone_binfo); } -static void mainstone_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void mainstone_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; mainstone_common_init(get_system_memory(), ram_size, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, mainstone, 0x196); } diff --git a/hw/mcf5208.c b/hw/mcf5208.c index ee25b1b..688bc3c 100644 --- a/hw/mcf5208.c +++ b/hw/mcf5208.c @@ -187,11 +187,11 @@ static void mcf5208_sys_init(MemoryRegion *address_space, qemu_irq *pic) } } -static void mcf5208evb_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void mcf5208evb_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; CPUM68KState *env; int kernel_size; uint64_t elf_entry; diff --git a/hw/milkymist.c b/hw/milkymist.c index 2e7235b..ca9ed43 100644 --- a/hw/milkymist.c +++ b/hw/milkymist.c @@ -73,12 +73,12 @@ static void main_cpu_reset(void *opaque) } static void -milkymist_init(ram_addr_t ram_size_not_used, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +milkymist_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; LM32CPU *cpu; CPULM32State *env; int kernel_size; diff --git a/hw/mips_fulong2e.c b/hw/mips_fulong2e.c index 38e4b86..af7bb50 100644 --- a/hw/mips_fulong2e.c +++ b/hw/mips_fulong2e.c @@ -256,10 +256,13 @@ static void cpu_request_exit(void *opaque, int irq, int level) } } -static void mips_fulong2e_init(ram_addr_t ram_size, const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void mips_fulong2e_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; char *filename; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *ram = g_new(MemoryRegion, 1); diff --git a/hw/mips_jazz.c b/hw/mips_jazz.c index db927f1..14df4d7 100644 --- a/hw/mips_jazz.c +++ b/hw/mips_jazz.c @@ -302,21 +302,19 @@ static void mips_jazz_init(MemoryRegion *address_space, } static -void mips_magnum_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +void mips_magnum_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; mips_jazz_init(get_system_memory(), get_system_io(), ram_size, cpu_model, JAZZ_MAGNUM); } static -void mips_pica61_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +void mips_pica61_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; mips_jazz_init(get_system_memory(), get_system_io(), ram_size, cpu_model, JAZZ_PICA61); } diff --git a/hw/mips_malta.c b/hw/mips_malta.c index ad23f26..14151f9 100644 --- a/hw/mips_malta.c +++ b/hw/mips_malta.c @@ -777,11 +777,13 @@ static void cpu_request_exit(void *opaque, int irq, int level) } static -void mips_malta_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +void mips_malta_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; char *filename; pflash_t *fl; MemoryRegion *system_memory = get_system_memory(); diff --git a/hw/mips_mipssim.c b/hw/mips_mipssim.c index 830f635..a1d3945 100644 --- a/hw/mips_mipssim.c +++ b/hw/mips_mipssim.c @@ -131,11 +131,13 @@ static void mipsnet_init(int base, qemu_irq irq, NICInfo *nd) } static void -mips_mipssim_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +mips_mipssim_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; char *filename; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *ram = g_new(MemoryRegion, 1); diff --git a/hw/mips_r4k.c b/hw/mips_r4k.c index 967a76e..b73cdc3 100644 --- a/hw/mips_r4k.c +++ b/hw/mips_r4k.c @@ -151,11 +151,13 @@ static void main_cpu_reset(void *opaque) static const int sector_len = 32 * 1024; static -void mips_r4k_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +void mips_r4k_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; char *filename; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *ram = g_new(MemoryRegion, 1); diff --git a/hw/musicpal.c b/hw/musicpal.c index f305e21..f06814c 100644 --- a/hw/musicpal.c +++ b/hw/musicpal.c @@ -1508,11 +1508,12 @@ static struct arm_boot_info musicpal_binfo = { .board_id = 0x20e, }; -static void musicpal_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void musicpal_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; ARMCPU *cpu; qemu_irq *cpu_pic; qemu_irq pic[32]; diff --git a/hw/nseries.c b/hw/nseries.c index 6df71eb..7ada90d 100644 --- a/hw/nseries.c +++ b/hw/nseries.c @@ -1397,21 +1397,27 @@ static struct arm_boot_info n810_binfo = { .atag_board = n810_atag_setup, }; -static void n800_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void n800_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; return n8x0_init(ram_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, &n800_binfo, 800); } -static void n810_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void n810_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; return n8x0_init(ram_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, &n810_binfo, 810); diff --git a/hw/null-machine.c b/hw/null-machine.c index 69910d3..d813c08 100644 --- a/hw/null-machine.c +++ b/hw/null-machine.c @@ -15,12 +15,7 @@ #include "hw/hw.h" #include "hw/boards.h" -static void machine_none_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void machine_none_init(QEMUMachineInitArgs *args) { } diff --git a/hw/omap_sx1.c b/hw/omap_sx1.c index abca341..ad17487 100644 --- a/hw/omap_sx1.c +++ b/hw/omap_sx1.c @@ -209,20 +209,26 @@ static void sx1_init(ram_addr_t ram_size, //~ qemu_console_resize(ds, 640, 480); } -static void sx1_init_v1(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void sx1_init_v1(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sx1_init(ram_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, 1); } -static void sx1_init_v2(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void sx1_init_v2(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sx1_init(ram_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, 2); } diff --git a/hw/openrisc_sim.c b/hw/openrisc_sim.c index 55e97f0..e96a944 100644 --- a/hw/openrisc_sim.c +++ b/hw/openrisc_sim.c @@ -90,13 +90,11 @@ static void cpu_openrisc_load_kernel(ram_addr_t ram_size, cpu->env.pc = entry; } -static void openrisc_sim_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void openrisc_sim_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; OpenRISCCPU *cpu = NULL; MemoryRegion *ram; int n; diff --git a/hw/palm.c b/hw/palm.c index bacdc90..032b8d6 100644 --- a/hw/palm.c +++ b/hw/palm.c @@ -190,11 +190,12 @@ static struct arm_boot_info palmte_binfo = { .board_id = 0x331, }; -static void palmte_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void palmte_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; MemoryRegion *address_space_mem = get_system_memory(); struct omap_mpu_state_s *mpu; int flash_size = 0x00800000; diff --git a/hw/pc_piix.c b/hw/pc_piix.c index fd5898f..c9fca05 100644 --- a/hw/pc_piix.c +++ b/hw/pc_piix.c @@ -287,13 +287,14 @@ static void pc_init1(MemoryRegion *system_memory, } } -static void pc_init_pci(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void pc_init_pci(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; pc_init1(get_system_memory(), get_system_io(), ram_size, boot_device, @@ -301,13 +302,14 @@ static void pc_init_pci(ram_addr_t ram_size, initrd_filename, cpu_model, 1, 1); } -static void pc_init_pci_no_kvmclock(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void pc_init_pci_no_kvmclock(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; pc_init1(get_system_memory(), get_system_io(), ram_size, boot_device, @@ -315,13 +317,14 @@ static void pc_init_pci_no_kvmclock(ram_addr_t ram_size, initrd_filename, cpu_model, 1, 0); } -static void pc_init_isa(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void pc_init_isa(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; if (cpu_model == NULL) cpu_model = "486"; pc_init1(get_system_memory(), @@ -332,19 +335,12 @@ static void pc_init_isa(ram_addr_t ram_size, } #ifdef CONFIG_XEN -static void pc_xen_hvm_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void pc_xen_hvm_init(QEMUMachineInitArgs *args) { if (xen_hvm_init() != 0) { hw_error("xen hardware virtual machine initialisation failed"); } - pc_init_pci_no_kvmclock(ram_size, boot_device, - kernel_filename, kernel_cmdline, - initrd_filename, cpu_model); + pc_init_pci_no_kvmclock(args); xen_vcpu_init(); } #endif diff --git a/hw/petalogix_ml605_mmu.c b/hw/petalogix_ml605_mmu.c index dced648..ace0187 100644 --- a/hw/petalogix_ml605_mmu.c +++ b/hw/petalogix_ml605_mmu.c @@ -70,12 +70,10 @@ static void machine_cpu_reset(MicroBlazeCPU *cpu) } static void -petalogix_ml605_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +petalogix_ml605_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; MemoryRegion *address_space_mem = get_system_memory(); DeviceState *dev, *dma, *eth0; MicroBlazeCPU *cpu; diff --git a/hw/petalogix_s3adsp1800_mmu.c b/hw/petalogix_s3adsp1800_mmu.c index 2cf6882..71c32ce 100644 --- a/hw/petalogix_s3adsp1800_mmu.c +++ b/hw/petalogix_s3adsp1800_mmu.c @@ -57,12 +57,10 @@ static void machine_cpu_reset(MicroBlazeCPU *cpu) } static void -petalogix_s3adsp1800_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +petalogix_s3adsp1800_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; DeviceState *dev; MicroBlazeCPU *cpu; CPUMBState *env; diff --git a/hw/ppc/e500plat.c b/hw/ppc/e500plat.c index 60a5cb3..4cfb940 100644 --- a/hw/ppc/e500plat.c +++ b/hw/ppc/e500plat.c @@ -25,13 +25,14 @@ static void e500plat_fixup_devtree(PPCE500Params *params, void *fdt) sizeof(compatible)); } -static void e500plat_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void e500plat_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *boot_device = args->boot_device; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; PPCE500Params params = { .ram_size = ram_size, .boot_device = boot_device, diff --git a/hw/ppc/mpc8544ds.c b/hw/ppc/mpc8544ds.c index 984d21c..e651661 100644 --- a/hw/ppc/mpc8544ds.c +++ b/hw/ppc/mpc8544ds.c @@ -25,13 +25,14 @@ static void mpc8544ds_fixup_devtree(PPCE500Params *params, void *fdt) sizeof(compatible)); } -static void mpc8544ds_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void mpc8544ds_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *boot_device = args->boot_device; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; PPCE500Params params = { .ram_size = ram_size, .boot_device = boot_device, diff --git a/hw/ppc405_boards.c b/hw/ppc405_boards.c index 476775d..e848cb0 100644 --- a/hw/ppc405_boards.c +++ b/hw/ppc405_boards.c @@ -158,7 +158,7 @@ static void ref405ep_fpga_reset (void *opaque) fpga->reg1 = 0x0F; } -static void ref405ep_fpga_init (MemoryRegion *sysmem, uint32_t base) +static void ref405ep_fpga_init(MemoryRegion *sysmem, uint32_t base) { ref405ep_fpga_t *fpga; MemoryRegion *fpga_memory = g_new(MemoryRegion, 1); @@ -170,13 +170,12 @@ static void ref405ep_fpga_init (MemoryRegion *sysmem, uint32_t base) qemu_register_reset(&ref405ep_fpga_reset, fpga); } -static void ref405ep_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void ref405ep_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; char *filename; ppc4xx_bd_info_t bd; CPUPPCState *env; @@ -484,7 +483,7 @@ static void taihu_cpld_reset (void *opaque) cpld->reg1 = 0x80; } -static void taihu_cpld_init (MemoryRegion *sysmem, uint32_t base) +static void taihu_cpld_init(MemoryRegion *sysmem, uint32_t base) { taihu_cpld_t *cpld; MemoryRegion *cpld_memory = g_new(MemoryRegion, 1); @@ -495,13 +494,11 @@ static void taihu_cpld_init (MemoryRegion *sysmem, uint32_t base) qemu_register_reset(&taihu_cpld_reset, cpld); } -static void taihu_405ep_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void taihu_405ep_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *kernel_filename = args->kernel_filename; + const char *initrd_filename = args->initrd_filename; char *filename; qemu_irq *pic; MemoryRegion *sysmem = get_system_memory(); diff --git a/hw/ppc440_bamboo.c b/hw/ppc440_bamboo.c index c198071..78e7985 100644 --- a/hw/ppc440_bamboo.c +++ b/hw/ppc440_bamboo.c @@ -157,13 +157,13 @@ static void main_cpu_reset(void *opaque) mmubooke_create_initial_mapping(env, 0, 0); } -static void bamboo_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void bamboo_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; unsigned int pci_irq_nrs[4] = { 28, 27, 26, 25 }; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *ram_memories diff --git a/hw/ppc_newworld.c b/hw/ppc_newworld.c index e95cfe8..e7c0747 100644 --- a/hw/ppc_newworld.c +++ b/hw/ppc_newworld.c @@ -129,13 +129,14 @@ static void ppc_core99_reset(void *opaque) } /* PowerPC Mac99 hardware initialisation */ -static void ppc_core99_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void ppc_core99_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; PowerPCCPU *cpu = NULL; CPUPPCState *env = NULL; char *filename; diff --git a/hw/ppc_oldworld.c b/hw/ppc_oldworld.c index 1dcd8a6..d9f76a8 100644 --- a/hw/ppc_oldworld.c +++ b/hw/ppc_oldworld.c @@ -72,13 +72,14 @@ static void ppc_heathrow_reset(void *opaque) cpu_reset(CPU(cpu)); } -static void ppc_heathrow_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void ppc_heathrow_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; MemoryRegion *sysmem = get_system_memory(); PowerPCCPU *cpu = NULL; CPUPPCState *env = NULL; diff --git a/hw/ppc_prep.c b/hw/ppc_prep.c index 592b7b2..f51f78a 100644 --- a/hw/ppc_prep.c +++ b/hw/ppc_prep.c @@ -448,13 +448,14 @@ static void ppc_prep_reset(void *opaque) } /* PowerPC PREP hardware initialisation */ -static void ppc_prep_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void ppc_prep_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; MemoryRegion *sysmem = get_system_memory(); PowerPCCPU *cpu = NULL; CPUPPCState *env = NULL; diff --git a/hw/puv3.c b/hw/puv3.c index 43f7216..764799c 100644 --- a/hw/puv3.c +++ b/hw/puv3.c @@ -91,10 +91,12 @@ static void puv3_load_kernel(const char *kernel_filename) graphic_console_init(NULL, NULL, NULL, NULL, NULL); } -static void puv3_init(ram_addr_t ram_size, const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void puv3_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *initrd_filename = args->initrd_filename; CPUUniCore32State *env; if (initrd_filename) { diff --git a/hw/r2d.c b/hw/r2d.c index 0f16e81..5daa42f 100644 --- a/hw/r2d.c +++ b/hw/r2d.c @@ -219,11 +219,12 @@ static struct QEMU_PACKED char kernel_cmdline[256]; } boot_params; -static void r2d_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void r2d_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; SuperHCPU *cpu; CPUSH4State *env; ResetData *reset_info; diff --git a/hw/realview.c b/hw/realview.c index 19db4d0..8dc4be6 100644 --- a/hw/realview.c +++ b/hw/realview.c @@ -330,11 +330,14 @@ static void realview_init(ram_addr_t ram_size, arm_load_kernel(arm_env_get_cpu(first_cpu), &realview_binfo); } -static void realview_eb_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void realview_eb_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; if (!cpu_model) { cpu_model = "arm926"; } @@ -342,11 +345,14 @@ static void realview_eb_init(ram_addr_t ram_size, initrd_filename, cpu_model, BOARD_EB); } -static void realview_eb_mpcore_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void realview_eb_mpcore_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; if (!cpu_model) { cpu_model = "arm11mpcore"; } @@ -354,11 +360,14 @@ static void realview_eb_mpcore_init(ram_addr_t ram_size, initrd_filename, cpu_model, BOARD_EB_MPCORE); } -static void realview_pb_a8_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void realview_pb_a8_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; if (!cpu_model) { cpu_model = "cortex-a8"; } @@ -366,11 +375,14 @@ static void realview_pb_a8_init(ram_addr_t ram_size, initrd_filename, cpu_model, BOARD_PB_A8); } -static void realview_pbx_a9_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void realview_pbx_a9_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; if (!cpu_model) { cpu_model = "cortex-a9"; } diff --git a/hw/s390-virtio.c b/hw/s390-virtio.c index 47eed35..39ff178 100644 --- a/hw/s390-virtio.c +++ b/hw/s390-virtio.c @@ -151,13 +151,14 @@ unsigned s390_del_running_cpu(CPUS390XState *env) } /* PC hardware initialisation */ -static void s390_init(ram_addr_t my_ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void s390_init(QEMUMachineInitArgs *args) { + ram_addr_t my_ram_size = args->ram_size; + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; CPUS390XState *env = NULL; MemoryRegion *sysmem = get_system_memory(); MemoryRegion *ram = g_new(MemoryRegion, 1); diff --git a/hw/shix.c b/hw/shix.c index dd9ce17..b56dd54 100644 --- a/hw/shix.c +++ b/hw/shix.c @@ -37,11 +37,9 @@ #define BIOS_FILENAME "shix_bios.bin" #define BIOS_ADDRESS 0xA0000000 -static void shix_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void shix_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; int ret; CPUSH4State *env; struct SH7750State *s; diff --git a/hw/spapr.c b/hw/spapr.c index c34b767..8921c4d 100644 --- a/hw/spapr.c +++ b/hw/spapr.c @@ -603,13 +603,14 @@ static int spapr_vga_init(PCIBus *pci_bus) } /* pSeries LPAR / sPAPR hardware init */ -static void ppc_spapr_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void ppc_spapr_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; PowerPCCPU *cpu; CPUPPCState *env; PCIHostState *phb; diff --git a/hw/spitz.c b/hw/spitz.c index 20e7835..df829b3 100644 --- a/hw/spitz.c +++ b/hw/spitz.c @@ -936,38 +936,46 @@ static void spitz_common_init(ram_addr_t ram_size, sl_bootparam_write(SL_PXA_PARAM_BASE); } -static void spitz_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void spitz_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; spitz_common_init(ram_size, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, spitz, 0x2c9); } -static void borzoi_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void borzoi_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; spitz_common_init(ram_size, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, borzoi, 0x33f); } -static void akita_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void akita_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; spitz_common_init(ram_size, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, akita, 0x2e8); } -static void terrier_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void terrier_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; spitz_common_init(ram_size, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, terrier, 0x33f); } diff --git a/hw/stellaris.c b/hw/stellaris.c index 562fbbf..b79c7fb 100644 --- a/hw/stellaris.c +++ b/hw/stellaris.c @@ -1358,19 +1358,17 @@ static void stellaris_init(const char *kernel_filename, const char *cpu_model, } /* FIXME: Figure out how to generate these from stellaris_boards. */ -static void lm3s811evb_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void lm3s811evb_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; stellaris_init(kernel_filename, cpu_model, &stellaris_boards[0]); } -static void lm3s6965evb_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void lm3s6965evb_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; stellaris_init(kernel_filename, cpu_model, &stellaris_boards[1]); } diff --git a/hw/sun4m.c b/hw/sun4m.c index c98cd5e..22e011f 100644 --- a/hw/sun4m.c +++ b/hw/sun4m.c @@ -1303,92 +1303,118 @@ static const struct sun4m_hwdef sun4m_hwdefs[] = { }; /* SPARCstation 5 hardware initialisation */ -static void ss5_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss5_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[0], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCstation 10 hardware initialisation */ -static void ss10_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss10_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[1], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCserver 600MP hardware initialisation */ -static void ss600mp_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss600mp_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[2], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCstation 20 hardware initialisation */ -static void ss20_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss20_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[3], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCstation Voyager hardware initialisation */ -static void vger_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void vger_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[4], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCstation LX hardware initialisation */ -static void ss_lx_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss_lx_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[5], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCstation 4 hardware initialisation */ -static void ss4_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss4_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[6], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCClassic hardware initialisation */ -static void scls_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void scls_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[7], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCbook hardware initialisation */ -static void sbook_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void sbook_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[8], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } @@ -1651,21 +1677,27 @@ static void sun4d_hw_init(const struct sun4d_hwdef *hwdef, ram_addr_t RAM_size, } /* SPARCserver 1000 hardware initialisation */ -static void ss1000_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss1000_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4d_hw_init(&sun4d_hwdefs[0], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCcenter 2000 hardware initialisation */ -static void ss2000_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss2000_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4d_hw_init(&sun4d_hwdefs[1], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } @@ -1845,11 +1877,14 @@ static void sun4c_hw_init(const struct sun4c_hwdef *hwdef, ram_addr_t RAM_size, } /* SPARCstation 2 hardware initialisation */ -static void ss2_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss2_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4c_hw_init(&sun4c_hwdefs[0], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } diff --git a/hw/sun4u.c b/hw/sun4u.c index 07cd042..379768c 100644 --- a/hw/sun4u.c +++ b/hw/sun4u.c @@ -930,31 +930,40 @@ static const struct hwdef hwdefs[] = { }; /* Sun4u hardware initialisation */ -static void sun4u_init(ram_addr_t RAM_size, - const char *boot_devices, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) -{ +static void sun4u_init(QEMUMachineInitArgs *args) +{ + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_devices = args->boot_device; sun4uv_init(get_system_memory(), RAM_size, boot_devices, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, &hwdefs[0]); } /* Sun4v hardware initialisation */ -static void sun4v_init(ram_addr_t RAM_size, - const char *boot_devices, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) -{ +static void sun4v_init(QEMUMachineInitArgs *args) +{ + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_devices = args->boot_device; sun4uv_init(get_system_memory(), RAM_size, boot_devices, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, &hwdefs[1]); } /* Niagara hardware initialisation */ -static void niagara_init(ram_addr_t RAM_size, - const char *boot_devices, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) -{ +static void niagara_init(QEMUMachineInitArgs *args) +{ + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_devices = args->boot_device; sun4uv_init(get_system_memory(), RAM_size, boot_devices, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, &hwdefs[2]); } diff --git a/hw/tosa.c b/hw/tosa.c index 297a8c2..512278c 100644 --- a/hw/tosa.c +++ b/hw/tosa.c @@ -205,11 +205,12 @@ static struct arm_boot_info tosa_binfo = { .ram_size = 0x04000000, }; -static void tosa_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void tosa_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *rom = g_new(MemoryRegion, 1); PXA2xxState *mpu; diff --git a/hw/versatilepb.c b/hw/versatilepb.c index 7a92034..686dcc7 100644 --- a/hw/versatilepb.c +++ b/hw/versatilepb.c @@ -342,22 +342,28 @@ static void versatile_init(ram_addr_t ram_size, arm_load_kernel(cpu, &versatile_binfo); } -static void vpb_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void vpb_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; versatile_init(ram_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, 0x183); } -static void vab_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void vab_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; versatile_init(ram_size, boot_device, kernel_filename, kernel_cmdline, diff --git a/hw/vexpress.c b/hw/vexpress.c index 3596d1e..36503d6 100644 --- a/hw/vexpress.c +++ b/hw/vexpress.c @@ -467,25 +467,27 @@ static void vexpress_common_init(const VEDBoardInfo *daughterboard, arm_load_kernel(arm_env_get_cpu(first_cpu), &vexpress_binfo); } -static void vexpress_a9_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void vexpress_a9_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; vexpress_common_init(&a9_daughterboard, ram_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } -static void vexpress_a15_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void vexpress_a15_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; vexpress_common_init(&a15_daughterboard, ram_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); diff --git a/hw/virtex_ml507.c b/hw/virtex_ml507.c index 79bc0d1..a09b27a 100644 --- a/hw/virtex_ml507.c +++ b/hw/virtex_ml507.c @@ -183,12 +183,12 @@ static int xilinx_load_device_tree(target_phys_addr_t addr, return fdt_size; } -static void virtex_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void virtex_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; MemoryRegion *address_space_mem = get_system_memory(); DeviceState *dev; PowerPCCPU *cpu; diff --git a/hw/xen_machine_pv.c b/hw/xen_machine_pv.c index 4b72aa7..50aba34 100644 --- a/hw/xen_machine_pv.c +++ b/hw/xen_machine_pv.c @@ -29,12 +29,7 @@ #include "xen_domainbuild.h" #include "blockdev.h" -static void xen_init_pv(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void xen_init_pv(QEMUMachineInitArgs *args) { X86CPU *cpu; CPUX86State *env; diff --git a/hw/xilinx_zynq.c b/hw/xilinx_zynq.c index 7e6c273..83f322e 100644 --- a/hw/xilinx_zynq.c +++ b/hw/xilinx_zynq.c @@ -46,10 +46,13 @@ static void gem_init(NICInfo *nd, uint32_t base, qemu_irq irq) sysbus_connect_irq(s, 0, irq); } -static void zynq_init(ram_addr_t ram_size, const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void zynq_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; ARMCPU *cpu; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *ext_ram = g_new(MemoryRegion, 1); diff --git a/hw/xtensa_lx60.c b/hw/xtensa_lx60.c index 3653f65..1fd2c47 100644 --- a/hw/xtensa_lx60.c +++ b/hw/xtensa_lx60.c @@ -268,11 +268,14 @@ static void lx_init(const LxBoardDesc *board, } } -static void xtensa_lx60_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void xtensa_lx60_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; static const LxBoardDesc lx60_board = { .flash_size = 0x400000, .flash_sector_size = 0x10000, @@ -283,11 +286,14 @@ static void xtensa_lx60_init(ram_addr_t ram_size, initrd_filename, cpu_model); } -static void xtensa_lx200_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void xtensa_lx200_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; static const LxBoardDesc lx200_board = { .flash_size = 0x1000000, .flash_sector_size = 0x20000, diff --git a/hw/xtensa_sim.c b/hw/xtensa_sim.c index 831460b..2e846d8 100644 --- a/hw/xtensa_sim.c +++ b/hw/xtensa_sim.c @@ -96,11 +96,14 @@ static void sim_init(ram_addr_t ram_size, } } -static void xtensa_sim_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void xtensa_sim_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; if (!cpu_model) { cpu_model = XTENSA_DEFAULT_CPU_MODEL; } diff --git a/hw/z2.c b/hw/z2.c index 289cee9..0927bad 100644 --- a/hw/z2.c +++ b/hw/z2.c @@ -294,11 +294,12 @@ static TypeInfo aer915_info = { .class_init = aer915_class_init, }; -static void z2_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void z2_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; MemoryRegion *address_space_mem = get_system_memory(); uint32_t sector_len = 0x10000; PXA2xxState *mpu; diff --git a/vl.c b/vl.c index 8d305ca..f663e7c 100644 --- a/vl.c +++ b/vl.c @@ -3624,8 +3624,13 @@ int main(int argc, char **argv, char **envp) qdev_machine_init(); - machine->init(ram_size, boot_devices, - kernel_filename, kernel_cmdline, initrd_filename, cpu_model); + QEMUMachineInitArgs args = { .ram_size = ram_size, + .boot_device = boot_devices, + .kernel_filename = kernel_filename, + .kernel_cmdline = kernel_cmdline, + initrd_filename = initrd_filename, + .cpu_model = cpu_model }; + machine->init(&args); cpu_synchronize_all_post_init(); -- 1.7.11.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 20:40:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 20:40:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKEgQ-0007S4-Rc; Fri, 05 Oct 2012 20:39:42 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKEgQ-0007Rz-4N for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 20:39:42 +0000 Received: from [85.158.143.99:26732] by server-3.bemta-4.messagelabs.com id 5C/4E-10986-D854F605; Fri, 05 Oct 2012 20:39:41 +0000 X-Env-Sender: ehabkost@redhat.com X-Msg-Ref: server-11.tower-216.messagelabs.com!1349469580!25524917!1 X-Originating-IP: [209.132.183.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTcwODY=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28601 invoked from network); 5 Oct 2012 20:39:40 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-11.tower-216.messagelabs.com with SMTP; 5 Oct 2012 20:39:40 -0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q95KdRqM023609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Oct 2012 16:39:27 -0400 Received: from blackpad.lan.raisama.net (vpn1-7-193.gru2.redhat.com [10.97.7.193]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q95KdPJX007026; Fri, 5 Oct 2012 16:39:25 -0400 Received: by blackpad.lan.raisama.net (Postfix, from userid 500) id 4189F203604; Fri, 5 Oct 2012 17:40:25 -0300 (BRT) Date: Fri, 5 Oct 2012 17:40:25 -0300 From: Eduardo Habkost To: Max Filippov Message-ID: <20121005204024.GF4362@otherpad.lan.raisama.net> References: <1349468535-14499-1-git-send-email-ehabkost@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Fnord: you can see the fnord User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Cc: Peter Maydell , Anthony Liguori , xen-devel@lists.xensource.com, Igor Mitsyanko , Evgeny Voevodin , qemu-ppc@nongnu.org, Aurelien Jarno , qemu-devel@nongnu.org, Fabien Chouteau , Alexander Graf , Peter Crosthwaite , Maksim Kozlov , Michael Walle , =?iso-8859-1?Q?Herv=E9?= Poussineau , Paul Brook , Blue Swirl , "Edgar E. Iglesias" , Guan Xuetao , Jan Kiszka , Dmitry Solodkiy Subject: Re: [Xen-devel] [Qemu-devel] [QEMU PATCH] create struct for machine initialization arguments (v2) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Sat, Oct 06, 2012 at 12:33:09AM +0400, Max Filippov wrote: > On Sat, Oct 6, 2012 at 12:22 AM, Eduardo Habkost wrote: > > This should help us to: > > - More easily add or remove machine initialization arguments without > > having to change every single machine init function; > > - More easily make mechanical changes involving the machine init > > functions in the future; > > - Let machine initialization forward the init arguments to other > > functions more easily. > > > > This change was half-mechanical process: first the struct was added with > > the local ram_size, boot_device, kernel_*, initrd_*, and cpu_model local > > variable initialization to all functions. Then the compiler helped me > > locate the local variables that are unused, so they could be removed. > > > > Changes v1 -> v2: > > - Fix mistake on the conversion of pc_xen_hvm_init() and xen_init_pv() > > > > Signed-off-by: Eduardo Habkost > > [...] > > > diff --git a/vl.c b/vl.c > > index 8d305ca..f663e7c 100644 > > --- a/vl.c > > +++ b/vl.c > > @@ -3624,8 +3624,13 @@ int main(int argc, char **argv, char **envp) > > > > qdev_machine_init(); > > > > - machine->init(ram_size, boot_devices, > > - kernel_filename, kernel_cmdline, initrd_filename, cpu_model); > > + QEMUMachineInitArgs args = { .ram_size = ram_size, > > + .boot_device = boot_devices, > > + .kernel_filename = kernel_filename, > > + .kernel_cmdline = kernel_cmdline, > > + initrd_filename = initrd_filename, > > Missing dot? Funny, GCC didn't complain. Thanks for spotting it! I am fixing this (and another problem I have found) and submit v3. > > > + .cpu_model = cpu_model }; > > + machine->init(&args); > > > > cpu_synchronize_all_post_init(); > > -- > Thanks. > -- Max > -- Eduardo _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 20:40:08 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 20:40:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKEgQ-0007S4-Rc; Fri, 05 Oct 2012 20:39:42 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKEgQ-0007Rz-4N for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 20:39:42 +0000 Received: from [85.158.143.99:26732] by server-3.bemta-4.messagelabs.com id 5C/4E-10986-D854F605; Fri, 05 Oct 2012 20:39:41 +0000 X-Env-Sender: ehabkost@redhat.com X-Msg-Ref: server-11.tower-216.messagelabs.com!1349469580!25524917!1 X-Originating-IP: [209.132.183.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTcwODY=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28601 invoked from network); 5 Oct 2012 20:39:40 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-11.tower-216.messagelabs.com with SMTP; 5 Oct 2012 20:39:40 -0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q95KdRqM023609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Oct 2012 16:39:27 -0400 Received: from blackpad.lan.raisama.net (vpn1-7-193.gru2.redhat.com [10.97.7.193]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q95KdPJX007026; Fri, 5 Oct 2012 16:39:25 -0400 Received: by blackpad.lan.raisama.net (Postfix, from userid 500) id 4189F203604; Fri, 5 Oct 2012 17:40:25 -0300 (BRT) Date: Fri, 5 Oct 2012 17:40:25 -0300 From: Eduardo Habkost To: Max Filippov Message-ID: <20121005204024.GF4362@otherpad.lan.raisama.net> References: <1349468535-14499-1-git-send-email-ehabkost@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Fnord: you can see the fnord User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Cc: Peter Maydell , Anthony Liguori , xen-devel@lists.xensource.com, Igor Mitsyanko , Evgeny Voevodin , qemu-ppc@nongnu.org, Aurelien Jarno , qemu-devel@nongnu.org, Fabien Chouteau , Alexander Graf , Peter Crosthwaite , Maksim Kozlov , Michael Walle , =?iso-8859-1?Q?Herv=E9?= Poussineau , Paul Brook , Blue Swirl , "Edgar E. Iglesias" , Guan Xuetao , Jan Kiszka , Dmitry Solodkiy Subject: Re: [Xen-devel] [Qemu-devel] [QEMU PATCH] create struct for machine initialization arguments (v2) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Sat, Oct 06, 2012 at 12:33:09AM +0400, Max Filippov wrote: > On Sat, Oct 6, 2012 at 12:22 AM, Eduardo Habkost wrote: > > This should help us to: > > - More easily add or remove machine initialization arguments without > > having to change every single machine init function; > > - More easily make mechanical changes involving the machine init > > functions in the future; > > - Let machine initialization forward the init arguments to other > > functions more easily. > > > > This change was half-mechanical process: first the struct was added with > > the local ram_size, boot_device, kernel_*, initrd_*, and cpu_model local > > variable initialization to all functions. Then the compiler helped me > > locate the local variables that are unused, so they could be removed. > > > > Changes v1 -> v2: > > - Fix mistake on the conversion of pc_xen_hvm_init() and xen_init_pv() > > > > Signed-off-by: Eduardo Habkost > > [...] > > > diff --git a/vl.c b/vl.c > > index 8d305ca..f663e7c 100644 > > --- a/vl.c > > +++ b/vl.c > > @@ -3624,8 +3624,13 @@ int main(int argc, char **argv, char **envp) > > > > qdev_machine_init(); > > > > - machine->init(ram_size, boot_devices, > > - kernel_filename, kernel_cmdline, initrd_filename, cpu_model); > > + QEMUMachineInitArgs args = { .ram_size = ram_size, > > + .boot_device = boot_devices, > > + .kernel_filename = kernel_filename, > > + .kernel_cmdline = kernel_cmdline, > > + initrd_filename = initrd_filename, > > Missing dot? Funny, GCC didn't complain. Thanks for spotting it! I am fixing this (and another problem I have found) and submit v3. > > > + .cpu_model = cpu_model }; > > + machine->init(&args); > > > > cpu_synchronize_all_post_init(); > > -- > Thanks. > -- Max > -- Eduardo _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 20:44:23 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 20:44:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKEkW-0007ZF-H1; Fri, 05 Oct 2012 20:43:56 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKEkV-0007Z9-4n for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 20:43:55 +0000 Received: from [85.158.139.83:46792] by server-6.bemta-5.messagelabs.com id 14/4A-14717-A864F605; Fri, 05 Oct 2012 20:43:54 +0000 X-Env-Sender: ehabkost@redhat.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1349469831!28019695!1 X-Originating-IP: [209.132.183.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTcwODY=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6430 invoked from network); 5 Oct 2012 20:43:52 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-5.tower-182.messagelabs.com with SMTP; 5 Oct 2012 20:43:52 -0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q95KhTnu005967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Oct 2012 16:43:29 -0400 Received: from blackpad.lan.raisama.net (vpn1-7-193.gru2.redhat.com [10.97.7.193]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q95KhSte026003; Fri, 5 Oct 2012 16:43:28 -0400 Received: by blackpad.lan.raisama.net (Postfix, from userid 500) id 25B96203604; Fri, 5 Oct 2012 17:44:28 -0300 (BRT) From: Eduardo Habkost To: qemu-devel@nongnu.org Date: Fri, 5 Oct 2012 17:44:26 -0300 Message-Id: <1349469866-1542-1-git-send-email-ehabkost@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Cc: Peter Maydell , Evgeny Voevodin , Peter Crosthwaite , Max Filippov , "Edgar E. Iglesias" , Guan Xuetao , xen-devel@lists.xensource.com, Igor Mitsyanko , Magnus Damm , Alexander Graf , =?UTF-8?q?Herv=C3=A9=20Poussineau?= , Maksim Kozlov , Andrzej Zaborowski , Fabien Chouteau , Jan Kiszka , Paul Brook , Blue Swirl , Anthony Liguori , Michael Walle , qemu-ppc@nongnu.org, Dmitry Solodkiy , Aurelien Jarno Subject: [Xen-devel] [QEMU PATCH] create struct for machine initialization arguments (v3) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This should help us to: - More easily add or remove machine initialization arguments without having to change every single machine init function; - More easily make mechanical changes involving the machine init functions in the future; - Let machine initialization forward the init arguments to other functions more easily. This change was half-mechanical process: first the struct was added with the local ram_size, boot_device, kernel_*, initrd_*, and cpu_model local variable initialization to all functions. Then the compiler helped me locate the local variables that are unused, so they could be removed. Changes v2 -> v3: - Fix typo (missing dot) on main() - Fix another mistake on xen_init_pv() (I had forgotten to add local variables to replace the old function arguments) Changes v1 -> v2: - Fix mistake on the conversion of pc_xen_hvm_init() and xen_init_pv() Signed-off-by: Eduardo Habkost --- hw/alpha_dp264.c | 12 ++-- hw/an5206.c | 8 +-- hw/axis_dev88.c | 9 +-- hw/boards.h | 16 +++-- hw/collie.c | 9 +-- hw/dummy_m68k.c | 8 +-- hw/exynos4_boards.c | 16 ++--- hw/gumstix.c | 11 +--- hw/highbank.c | 10 ++-- hw/integratorcp.c | 10 ++-- hw/kzm.c | 10 ++-- hw/leon3.c | 10 ++-- hw/lm32_boards.c | 18 +++--- hw/mainstone.c | 10 ++-- hw/mcf5208.c | 8 +-- hw/milkymist.c | 10 ++-- hw/mips_fulong2e.c | 9 ++- hw/mips_jazz.c | 14 ++--- hw/mips_malta.c | 10 ++-- hw/mips_mipssim.c | 10 ++-- hw/mips_r4k.c | 10 ++-- hw/musicpal.c | 9 +-- hw/nseries.c | 22 ++++--- hw/null-machine.c | 7 +-- hw/omap_sx1.c | 22 ++++--- hw/openrisc_sim.c | 10 ++-- hw/palm.c | 9 +-- hw/pc_piix.c | 50 ++++++++-------- hw/petalogix_ml605_mmu.c | 8 +-- hw/petalogix_s3adsp1800_mmu.c | 8 +-- hw/ppc/e500plat.c | 13 +++-- hw/ppc/mpc8544ds.c | 13 +++-- hw/ppc405_boards.c | 25 ++++---- hw/ppc440_bamboo.c | 12 ++-- hw/ppc_newworld.c | 13 +++-- hw/ppc_oldworld.c | 13 +++-- hw/ppc_prep.c | 13 +++-- hw/puv3.c | 8 ++- hw/r2d.c | 9 +-- hw/realview.c | 44 +++++++++----- hw/s390-virtio.c | 13 +++-- hw/shix.c | 6 +- hw/spapr.c | 13 +++-- hw/spitz.c | 40 ++++++++----- hw/stellaris.c | 14 ++--- hw/sun4m.c | 133 ++++++++++++++++++++++++++---------------- hw/sun4u.c | 39 ++++++++----- hw/tosa.c | 9 +-- hw/versatilepb.c | 22 ++++--- hw/vexpress.c | 26 +++++---- hw/virtex_ml507.c | 10 ++-- hw/xen_machine_pv.c | 11 ++-- hw/xilinx_zynq.c | 9 ++- hw/xtensa_lx60.c | 22 ++++--- hw/xtensa_sim.c | 11 ++-- hw/z2.c | 9 +-- vl.c | 9 ++- 57 files changed, 518 insertions(+), 414 deletions(-) diff --git a/hw/alpha_dp264.c b/hw/alpha_dp264.c index 9eb939f..2c2e237 100644 --- a/hw/alpha_dp264.c +++ b/hw/alpha_dp264.c @@ -42,13 +42,13 @@ static int clipper_pci_map_irq(PCIDevice *d, int irq_num) return (slot + 1) * 4 + irq_num; } -static void clipper_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void clipper_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; CPUAlphaState *cpus[4]; PCIBus *pci_bus; ISABus *isa_bus; diff --git a/hw/an5206.c b/hw/an5206.c index 25407c0..042c5fc 100644 --- a/hw/an5206.c +++ b/hw/an5206.c @@ -19,11 +19,11 @@ /* Board init. */ -static void an5206_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void an5206_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; CPUM68KState *env; int kernel_size; uint64_t elf_entry; diff --git a/hw/axis_dev88.c b/hw/axis_dev88.c index eab6327..2fd7356 100644 --- a/hw/axis_dev88.c +++ b/hw/axis_dev88.c @@ -242,11 +242,12 @@ static const MemoryRegionOps gpio_ops = { static struct cris_load_info li; static -void axisdev88_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +void axisdev88_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; CRISCPU *cpu; CPUCRISState *env; DeviceState *dev; diff --git a/hw/boards.h b/hw/boards.h index a2e0a54..813d0e5 100644 --- a/hw/boards.h +++ b/hw/boards.h @@ -5,12 +5,16 @@ #include "qdev.h" -typedef void QEMUMachineInitFunc(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model); +typedef struct QEMUMachineInitArgs { + ram_addr_t ram_size; + const char *boot_device; + const char *kernel_filename; + const char *kernel_cmdline; + const char *initrd_filename; + const char *cpu_model; +} QEMUMachineInitArgs; + +typedef void QEMUMachineInitFunc(QEMUMachineInitArgs *args); typedef void QEMUMachineResetFunc(void); diff --git a/hw/collie.c b/hw/collie.c index 56f89a9..695982a 100644 --- a/hw/collie.c +++ b/hw/collie.c @@ -23,11 +23,12 @@ static struct arm_boot_info collie_binfo = { .ram_size = 0x20000000, }; -static void collie_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void collie_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; StrongARMState *s; DriveInfo *dinfo; MemoryRegion *sysmem = get_system_memory(); diff --git a/hw/dummy_m68k.c b/hw/dummy_m68k.c index 7cc7a99..f436a0c 100644 --- a/hw/dummy_m68k.c +++ b/hw/dummy_m68k.c @@ -16,11 +16,11 @@ /* Board init. */ -static void dummy_m68k_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void dummy_m68k_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; CPUM68KState *env; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *ram = g_new(MemoryRegion, 1); diff --git a/hw/exynos4_boards.c b/hw/exynos4_boards.c index 4bb0a60..4951064 100644 --- a/hw/exynos4_boards.c +++ b/hw/exynos4_boards.c @@ -130,22 +130,22 @@ static Exynos4210State *exynos4_boards_init_common( exynos4_board_ram_size[board_type]); } -static void nuri_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void nuri_init(QEMUMachineInitArgs *args) { + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; exynos4_boards_init_common(kernel_filename, kernel_cmdline, initrd_filename, EXYNOS4_BOARD_NURI); arm_load_kernel(arm_env_get_cpu(first_cpu), &exynos4_board_binfo); } -static void smdkc210_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void smdkc210_init(QEMUMachineInitArgs *args) { + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; Exynos4210State *s = exynos4_boards_init_common(kernel_filename, kernel_cmdline, initrd_filename, EXYNOS4_BOARD_SMDKC210); diff --git a/hw/gumstix.c b/hw/gumstix.c index 13a36ea..4103a88 100644 --- a/hw/gumstix.c +++ b/hw/gumstix.c @@ -45,10 +45,7 @@ static const int sector_len = 128 * 1024; -static void connex_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void connex_init(QEMUMachineInitArgs *args) { PXA2xxState *cpu; DriveInfo *dinfo; @@ -84,11 +81,9 @@ static void connex_init(ram_addr_t ram_size, qdev_get_gpio_in(cpu->gpio, 36)); } -static void verdex_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void verdex_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; PXA2xxState *cpu; DriveInfo *dinfo; int be; diff --git a/hw/highbank.c b/hw/highbank.c index 11aa131..15036b6 100644 --- a/hw/highbank.c +++ b/hw/highbank.c @@ -187,11 +187,13 @@ static struct arm_boot_info highbank_binfo; * 32-bit host, set the reg value of memory to 0xf7ff00000 in the * device tree and pass -m 2047 to QEMU. */ -static void highbank_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void highbank_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; DeviceState *dev; SysBusDevice *busdev; qemu_irq *irqp; diff --git a/hw/integratorcp.c b/hw/integratorcp.c index d0e2e90..ac0ea83 100644 --- a/hw/integratorcp.c +++ b/hw/integratorcp.c @@ -438,11 +438,13 @@ static struct arm_boot_info integrator_binfo = { .board_id = 0x113, }; -static void integratorcp_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void integratorcp_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; ARMCPU *cpu; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *ram = g_new(MemoryRegion, 1); diff --git a/hw/kzm.c b/hw/kzm.c index 68cd1b4..d1266d9 100644 --- a/hw/kzm.c +++ b/hw/kzm.c @@ -70,11 +70,13 @@ static struct arm_boot_info kzm_binfo = { .board_id = 1722, }; -static void kzm_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void kzm_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; ARMCPU *cpu; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *ram = g_new(MemoryRegion, 1); diff --git a/hw/leon3.c b/hw/leon3.c index 878d3aa..6486b7b 100644 --- a/hw/leon3.c +++ b/hw/leon3.c @@ -94,13 +94,11 @@ static void leon3_set_pil_in(void *opaque, uint32_t pil_in) } } -static void leon3_generic_hw_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void leon3_generic_hw_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; SPARCCPU *cpu; CPUSPARCState *env; MemoryRegion *address_space_mem = get_system_memory(); diff --git a/hw/lm32_boards.c b/hw/lm32_boards.c index b76d800..c5a62c8 100644 --- a/hw/lm32_boards.c +++ b/hw/lm32_boards.c @@ -69,12 +69,10 @@ static void main_cpu_reset(void *opaque) env->deba = reset_info->flash_base; } -static void lm32_evr_init(ram_addr_t ram_size_not_used, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void lm32_evr_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; LM32CPU *cpu; CPULM32State *env; DriveInfo *dinfo; @@ -159,12 +157,12 @@ static void lm32_evr_init(ram_addr_t ram_size_not_used, qemu_register_reset(main_cpu_reset, reset_info); } -static void lm32_uclinux_init(ram_addr_t ram_size_not_used, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void lm32_uclinux_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; LM32CPU *cpu; CPULM32State *env; DriveInfo *dinfo; diff --git a/hw/mainstone.c b/hw/mainstone.c index 97687b6..c0d6034 100644 --- a/hw/mainstone.c +++ b/hw/mainstone.c @@ -171,11 +171,13 @@ static void mainstone_common_init(MemoryRegion *address_space_mem, arm_load_kernel(mpu->cpu, &mainstone_binfo); } -static void mainstone_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void mainstone_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; mainstone_common_init(get_system_memory(), ram_size, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, mainstone, 0x196); } diff --git a/hw/mcf5208.c b/hw/mcf5208.c index ee25b1b..688bc3c 100644 --- a/hw/mcf5208.c +++ b/hw/mcf5208.c @@ -187,11 +187,11 @@ static void mcf5208_sys_init(MemoryRegion *address_space, qemu_irq *pic) } } -static void mcf5208evb_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void mcf5208evb_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; CPUM68KState *env; int kernel_size; uint64_t elf_entry; diff --git a/hw/milkymist.c b/hw/milkymist.c index 2e7235b..ca9ed43 100644 --- a/hw/milkymist.c +++ b/hw/milkymist.c @@ -73,12 +73,12 @@ static void main_cpu_reset(void *opaque) } static void -milkymist_init(ram_addr_t ram_size_not_used, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +milkymist_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; LM32CPU *cpu; CPULM32State *env; int kernel_size; diff --git a/hw/mips_fulong2e.c b/hw/mips_fulong2e.c index 38e4b86..af7bb50 100644 --- a/hw/mips_fulong2e.c +++ b/hw/mips_fulong2e.c @@ -256,10 +256,13 @@ static void cpu_request_exit(void *opaque, int irq, int level) } } -static void mips_fulong2e_init(ram_addr_t ram_size, const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void mips_fulong2e_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; char *filename; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *ram = g_new(MemoryRegion, 1); diff --git a/hw/mips_jazz.c b/hw/mips_jazz.c index db927f1..14df4d7 100644 --- a/hw/mips_jazz.c +++ b/hw/mips_jazz.c @@ -302,21 +302,19 @@ static void mips_jazz_init(MemoryRegion *address_space, } static -void mips_magnum_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +void mips_magnum_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; mips_jazz_init(get_system_memory(), get_system_io(), ram_size, cpu_model, JAZZ_MAGNUM); } static -void mips_pica61_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +void mips_pica61_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; mips_jazz_init(get_system_memory(), get_system_io(), ram_size, cpu_model, JAZZ_PICA61); } diff --git a/hw/mips_malta.c b/hw/mips_malta.c index ad23f26..14151f9 100644 --- a/hw/mips_malta.c +++ b/hw/mips_malta.c @@ -777,11 +777,13 @@ static void cpu_request_exit(void *opaque, int irq, int level) } static -void mips_malta_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +void mips_malta_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; char *filename; pflash_t *fl; MemoryRegion *system_memory = get_system_memory(); diff --git a/hw/mips_mipssim.c b/hw/mips_mipssim.c index 830f635..a1d3945 100644 --- a/hw/mips_mipssim.c +++ b/hw/mips_mipssim.c @@ -131,11 +131,13 @@ static void mipsnet_init(int base, qemu_irq irq, NICInfo *nd) } static void -mips_mipssim_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +mips_mipssim_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; char *filename; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *ram = g_new(MemoryRegion, 1); diff --git a/hw/mips_r4k.c b/hw/mips_r4k.c index 967a76e..b73cdc3 100644 --- a/hw/mips_r4k.c +++ b/hw/mips_r4k.c @@ -151,11 +151,13 @@ static void main_cpu_reset(void *opaque) static const int sector_len = 32 * 1024; static -void mips_r4k_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +void mips_r4k_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; char *filename; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *ram = g_new(MemoryRegion, 1); diff --git a/hw/musicpal.c b/hw/musicpal.c index f305e21..f06814c 100644 --- a/hw/musicpal.c +++ b/hw/musicpal.c @@ -1508,11 +1508,12 @@ static struct arm_boot_info musicpal_binfo = { .board_id = 0x20e, }; -static void musicpal_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void musicpal_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; ARMCPU *cpu; qemu_irq *cpu_pic; qemu_irq pic[32]; diff --git a/hw/nseries.c b/hw/nseries.c index 6df71eb..7ada90d 100644 --- a/hw/nseries.c +++ b/hw/nseries.c @@ -1397,21 +1397,27 @@ static struct arm_boot_info n810_binfo = { .atag_board = n810_atag_setup, }; -static void n800_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void n800_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; return n8x0_init(ram_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, &n800_binfo, 800); } -static void n810_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void n810_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; return n8x0_init(ram_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, &n810_binfo, 810); diff --git a/hw/null-machine.c b/hw/null-machine.c index 69910d3..d813c08 100644 --- a/hw/null-machine.c +++ b/hw/null-machine.c @@ -15,12 +15,7 @@ #include "hw/hw.h" #include "hw/boards.h" -static void machine_none_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void machine_none_init(QEMUMachineInitArgs *args) { } diff --git a/hw/omap_sx1.c b/hw/omap_sx1.c index abca341..ad17487 100644 --- a/hw/omap_sx1.c +++ b/hw/omap_sx1.c @@ -209,20 +209,26 @@ static void sx1_init(ram_addr_t ram_size, //~ qemu_console_resize(ds, 640, 480); } -static void sx1_init_v1(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void sx1_init_v1(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sx1_init(ram_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, 1); } -static void sx1_init_v2(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void sx1_init_v2(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sx1_init(ram_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, 2); } diff --git a/hw/openrisc_sim.c b/hw/openrisc_sim.c index 55e97f0..e96a944 100644 --- a/hw/openrisc_sim.c +++ b/hw/openrisc_sim.c @@ -90,13 +90,11 @@ static void cpu_openrisc_load_kernel(ram_addr_t ram_size, cpu->env.pc = entry; } -static void openrisc_sim_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void openrisc_sim_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; OpenRISCCPU *cpu = NULL; MemoryRegion *ram; int n; diff --git a/hw/palm.c b/hw/palm.c index bacdc90..032b8d6 100644 --- a/hw/palm.c +++ b/hw/palm.c @@ -190,11 +190,12 @@ static struct arm_boot_info palmte_binfo = { .board_id = 0x331, }; -static void palmte_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void palmte_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; MemoryRegion *address_space_mem = get_system_memory(); struct omap_mpu_state_s *mpu; int flash_size = 0x00800000; diff --git a/hw/pc_piix.c b/hw/pc_piix.c index fd5898f..c9fca05 100644 --- a/hw/pc_piix.c +++ b/hw/pc_piix.c @@ -287,13 +287,14 @@ static void pc_init1(MemoryRegion *system_memory, } } -static void pc_init_pci(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void pc_init_pci(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; pc_init1(get_system_memory(), get_system_io(), ram_size, boot_device, @@ -301,13 +302,14 @@ static void pc_init_pci(ram_addr_t ram_size, initrd_filename, cpu_model, 1, 1); } -static void pc_init_pci_no_kvmclock(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void pc_init_pci_no_kvmclock(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; pc_init1(get_system_memory(), get_system_io(), ram_size, boot_device, @@ -315,13 +317,14 @@ static void pc_init_pci_no_kvmclock(ram_addr_t ram_size, initrd_filename, cpu_model, 1, 0); } -static void pc_init_isa(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void pc_init_isa(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; if (cpu_model == NULL) cpu_model = "486"; pc_init1(get_system_memory(), @@ -332,19 +335,12 @@ static void pc_init_isa(ram_addr_t ram_size, } #ifdef CONFIG_XEN -static void pc_xen_hvm_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void pc_xen_hvm_init(QEMUMachineInitArgs *args) { if (xen_hvm_init() != 0) { hw_error("xen hardware virtual machine initialisation failed"); } - pc_init_pci_no_kvmclock(ram_size, boot_device, - kernel_filename, kernel_cmdline, - initrd_filename, cpu_model); + pc_init_pci_no_kvmclock(args); xen_vcpu_init(); } #endif diff --git a/hw/petalogix_ml605_mmu.c b/hw/petalogix_ml605_mmu.c index dced648..ace0187 100644 --- a/hw/petalogix_ml605_mmu.c +++ b/hw/petalogix_ml605_mmu.c @@ -70,12 +70,10 @@ static void machine_cpu_reset(MicroBlazeCPU *cpu) } static void -petalogix_ml605_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +petalogix_ml605_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; MemoryRegion *address_space_mem = get_system_memory(); DeviceState *dev, *dma, *eth0; MicroBlazeCPU *cpu; diff --git a/hw/petalogix_s3adsp1800_mmu.c b/hw/petalogix_s3adsp1800_mmu.c index 2cf6882..71c32ce 100644 --- a/hw/petalogix_s3adsp1800_mmu.c +++ b/hw/petalogix_s3adsp1800_mmu.c @@ -57,12 +57,10 @@ static void machine_cpu_reset(MicroBlazeCPU *cpu) } static void -petalogix_s3adsp1800_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +petalogix_s3adsp1800_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; DeviceState *dev; MicroBlazeCPU *cpu; CPUMBState *env; diff --git a/hw/ppc/e500plat.c b/hw/ppc/e500plat.c index 60a5cb3..4cfb940 100644 --- a/hw/ppc/e500plat.c +++ b/hw/ppc/e500plat.c @@ -25,13 +25,14 @@ static void e500plat_fixup_devtree(PPCE500Params *params, void *fdt) sizeof(compatible)); } -static void e500plat_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void e500plat_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *boot_device = args->boot_device; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; PPCE500Params params = { .ram_size = ram_size, .boot_device = boot_device, diff --git a/hw/ppc/mpc8544ds.c b/hw/ppc/mpc8544ds.c index 984d21c..e651661 100644 --- a/hw/ppc/mpc8544ds.c +++ b/hw/ppc/mpc8544ds.c @@ -25,13 +25,14 @@ static void mpc8544ds_fixup_devtree(PPCE500Params *params, void *fdt) sizeof(compatible)); } -static void mpc8544ds_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void mpc8544ds_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *boot_device = args->boot_device; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; PPCE500Params params = { .ram_size = ram_size, .boot_device = boot_device, diff --git a/hw/ppc405_boards.c b/hw/ppc405_boards.c index 476775d..e848cb0 100644 --- a/hw/ppc405_boards.c +++ b/hw/ppc405_boards.c @@ -158,7 +158,7 @@ static void ref405ep_fpga_reset (void *opaque) fpga->reg1 = 0x0F; } -static void ref405ep_fpga_init (MemoryRegion *sysmem, uint32_t base) +static void ref405ep_fpga_init(MemoryRegion *sysmem, uint32_t base) { ref405ep_fpga_t *fpga; MemoryRegion *fpga_memory = g_new(MemoryRegion, 1); @@ -170,13 +170,12 @@ static void ref405ep_fpga_init (MemoryRegion *sysmem, uint32_t base) qemu_register_reset(&ref405ep_fpga_reset, fpga); } -static void ref405ep_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void ref405ep_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; char *filename; ppc4xx_bd_info_t bd; CPUPPCState *env; @@ -484,7 +483,7 @@ static void taihu_cpld_reset (void *opaque) cpld->reg1 = 0x80; } -static void taihu_cpld_init (MemoryRegion *sysmem, uint32_t base) +static void taihu_cpld_init(MemoryRegion *sysmem, uint32_t base) { taihu_cpld_t *cpld; MemoryRegion *cpld_memory = g_new(MemoryRegion, 1); @@ -495,13 +494,11 @@ static void taihu_cpld_init (MemoryRegion *sysmem, uint32_t base) qemu_register_reset(&taihu_cpld_reset, cpld); } -static void taihu_405ep_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void taihu_405ep_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *kernel_filename = args->kernel_filename; + const char *initrd_filename = args->initrd_filename; char *filename; qemu_irq *pic; MemoryRegion *sysmem = get_system_memory(); diff --git a/hw/ppc440_bamboo.c b/hw/ppc440_bamboo.c index c198071..78e7985 100644 --- a/hw/ppc440_bamboo.c +++ b/hw/ppc440_bamboo.c @@ -157,13 +157,13 @@ static void main_cpu_reset(void *opaque) mmubooke_create_initial_mapping(env, 0, 0); } -static void bamboo_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void bamboo_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; unsigned int pci_irq_nrs[4] = { 28, 27, 26, 25 }; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *ram_memories diff --git a/hw/ppc_newworld.c b/hw/ppc_newworld.c index e95cfe8..e7c0747 100644 --- a/hw/ppc_newworld.c +++ b/hw/ppc_newworld.c @@ -129,13 +129,14 @@ static void ppc_core99_reset(void *opaque) } /* PowerPC Mac99 hardware initialisation */ -static void ppc_core99_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void ppc_core99_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; PowerPCCPU *cpu = NULL; CPUPPCState *env = NULL; char *filename; diff --git a/hw/ppc_oldworld.c b/hw/ppc_oldworld.c index 1dcd8a6..d9f76a8 100644 --- a/hw/ppc_oldworld.c +++ b/hw/ppc_oldworld.c @@ -72,13 +72,14 @@ static void ppc_heathrow_reset(void *opaque) cpu_reset(CPU(cpu)); } -static void ppc_heathrow_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void ppc_heathrow_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; MemoryRegion *sysmem = get_system_memory(); PowerPCCPU *cpu = NULL; CPUPPCState *env = NULL; diff --git a/hw/ppc_prep.c b/hw/ppc_prep.c index 592b7b2..f51f78a 100644 --- a/hw/ppc_prep.c +++ b/hw/ppc_prep.c @@ -448,13 +448,14 @@ static void ppc_prep_reset(void *opaque) } /* PowerPC PREP hardware initialisation */ -static void ppc_prep_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void ppc_prep_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; MemoryRegion *sysmem = get_system_memory(); PowerPCCPU *cpu = NULL; CPUPPCState *env = NULL; diff --git a/hw/puv3.c b/hw/puv3.c index 43f7216..764799c 100644 --- a/hw/puv3.c +++ b/hw/puv3.c @@ -91,10 +91,12 @@ static void puv3_load_kernel(const char *kernel_filename) graphic_console_init(NULL, NULL, NULL, NULL, NULL); } -static void puv3_init(ram_addr_t ram_size, const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void puv3_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *initrd_filename = args->initrd_filename; CPUUniCore32State *env; if (initrd_filename) { diff --git a/hw/r2d.c b/hw/r2d.c index 0f16e81..5daa42f 100644 --- a/hw/r2d.c +++ b/hw/r2d.c @@ -219,11 +219,12 @@ static struct QEMU_PACKED char kernel_cmdline[256]; } boot_params; -static void r2d_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void r2d_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; SuperHCPU *cpu; CPUSH4State *env; ResetData *reset_info; diff --git a/hw/realview.c b/hw/realview.c index 19db4d0..8dc4be6 100644 --- a/hw/realview.c +++ b/hw/realview.c @@ -330,11 +330,14 @@ static void realview_init(ram_addr_t ram_size, arm_load_kernel(arm_env_get_cpu(first_cpu), &realview_binfo); } -static void realview_eb_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void realview_eb_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; if (!cpu_model) { cpu_model = "arm926"; } @@ -342,11 +345,14 @@ static void realview_eb_init(ram_addr_t ram_size, initrd_filename, cpu_model, BOARD_EB); } -static void realview_eb_mpcore_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void realview_eb_mpcore_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; if (!cpu_model) { cpu_model = "arm11mpcore"; } @@ -354,11 +360,14 @@ static void realview_eb_mpcore_init(ram_addr_t ram_size, initrd_filename, cpu_model, BOARD_EB_MPCORE); } -static void realview_pb_a8_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void realview_pb_a8_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; if (!cpu_model) { cpu_model = "cortex-a8"; } @@ -366,11 +375,14 @@ static void realview_pb_a8_init(ram_addr_t ram_size, initrd_filename, cpu_model, BOARD_PB_A8); } -static void realview_pbx_a9_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void realview_pbx_a9_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; if (!cpu_model) { cpu_model = "cortex-a9"; } diff --git a/hw/s390-virtio.c b/hw/s390-virtio.c index 47eed35..39ff178 100644 --- a/hw/s390-virtio.c +++ b/hw/s390-virtio.c @@ -151,13 +151,14 @@ unsigned s390_del_running_cpu(CPUS390XState *env) } /* PC hardware initialisation */ -static void s390_init(ram_addr_t my_ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void s390_init(QEMUMachineInitArgs *args) { + ram_addr_t my_ram_size = args->ram_size; + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; CPUS390XState *env = NULL; MemoryRegion *sysmem = get_system_memory(); MemoryRegion *ram = g_new(MemoryRegion, 1); diff --git a/hw/shix.c b/hw/shix.c index dd9ce17..b56dd54 100644 --- a/hw/shix.c +++ b/hw/shix.c @@ -37,11 +37,9 @@ #define BIOS_FILENAME "shix_bios.bin" #define BIOS_ADDRESS 0xA0000000 -static void shix_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void shix_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; int ret; CPUSH4State *env; struct SH7750State *s; diff --git a/hw/spapr.c b/hw/spapr.c index c34b767..8921c4d 100644 --- a/hw/spapr.c +++ b/hw/spapr.c @@ -603,13 +603,14 @@ static int spapr_vga_init(PCIBus *pci_bus) } /* pSeries LPAR / sPAPR hardware init */ -static void ppc_spapr_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void ppc_spapr_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; PowerPCCPU *cpu; CPUPPCState *env; PCIHostState *phb; diff --git a/hw/spitz.c b/hw/spitz.c index 20e7835..df829b3 100644 --- a/hw/spitz.c +++ b/hw/spitz.c @@ -936,38 +936,46 @@ static void spitz_common_init(ram_addr_t ram_size, sl_bootparam_write(SL_PXA_PARAM_BASE); } -static void spitz_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void spitz_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; spitz_common_init(ram_size, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, spitz, 0x2c9); } -static void borzoi_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void borzoi_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; spitz_common_init(ram_size, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, borzoi, 0x33f); } -static void akita_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void akita_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; spitz_common_init(ram_size, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, akita, 0x2e8); } -static void terrier_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void terrier_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; spitz_common_init(ram_size, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, terrier, 0x33f); } diff --git a/hw/stellaris.c b/hw/stellaris.c index 562fbbf..b79c7fb 100644 --- a/hw/stellaris.c +++ b/hw/stellaris.c @@ -1358,19 +1358,17 @@ static void stellaris_init(const char *kernel_filename, const char *cpu_model, } /* FIXME: Figure out how to generate these from stellaris_boards. */ -static void lm3s811evb_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void lm3s811evb_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; stellaris_init(kernel_filename, cpu_model, &stellaris_boards[0]); } -static void lm3s6965evb_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void lm3s6965evb_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; stellaris_init(kernel_filename, cpu_model, &stellaris_boards[1]); } diff --git a/hw/sun4m.c b/hw/sun4m.c index c98cd5e..22e011f 100644 --- a/hw/sun4m.c +++ b/hw/sun4m.c @@ -1303,92 +1303,118 @@ static const struct sun4m_hwdef sun4m_hwdefs[] = { }; /* SPARCstation 5 hardware initialisation */ -static void ss5_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss5_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[0], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCstation 10 hardware initialisation */ -static void ss10_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss10_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[1], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCserver 600MP hardware initialisation */ -static void ss600mp_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss600mp_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[2], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCstation 20 hardware initialisation */ -static void ss20_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss20_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[3], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCstation Voyager hardware initialisation */ -static void vger_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void vger_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[4], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCstation LX hardware initialisation */ -static void ss_lx_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss_lx_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[5], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCstation 4 hardware initialisation */ -static void ss4_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss4_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[6], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCClassic hardware initialisation */ -static void scls_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void scls_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[7], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCbook hardware initialisation */ -static void sbook_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void sbook_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[8], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } @@ -1651,21 +1677,27 @@ static void sun4d_hw_init(const struct sun4d_hwdef *hwdef, ram_addr_t RAM_size, } /* SPARCserver 1000 hardware initialisation */ -static void ss1000_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss1000_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4d_hw_init(&sun4d_hwdefs[0], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCcenter 2000 hardware initialisation */ -static void ss2000_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss2000_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4d_hw_init(&sun4d_hwdefs[1], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } @@ -1845,11 +1877,14 @@ static void sun4c_hw_init(const struct sun4c_hwdef *hwdef, ram_addr_t RAM_size, } /* SPARCstation 2 hardware initialisation */ -static void ss2_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss2_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4c_hw_init(&sun4c_hwdefs[0], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } diff --git a/hw/sun4u.c b/hw/sun4u.c index 07cd042..379768c 100644 --- a/hw/sun4u.c +++ b/hw/sun4u.c @@ -930,31 +930,40 @@ static const struct hwdef hwdefs[] = { }; /* Sun4u hardware initialisation */ -static void sun4u_init(ram_addr_t RAM_size, - const char *boot_devices, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) -{ +static void sun4u_init(QEMUMachineInitArgs *args) +{ + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_devices = args->boot_device; sun4uv_init(get_system_memory(), RAM_size, boot_devices, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, &hwdefs[0]); } /* Sun4v hardware initialisation */ -static void sun4v_init(ram_addr_t RAM_size, - const char *boot_devices, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) -{ +static void sun4v_init(QEMUMachineInitArgs *args) +{ + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_devices = args->boot_device; sun4uv_init(get_system_memory(), RAM_size, boot_devices, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, &hwdefs[1]); } /* Niagara hardware initialisation */ -static void niagara_init(ram_addr_t RAM_size, - const char *boot_devices, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) -{ +static void niagara_init(QEMUMachineInitArgs *args) +{ + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_devices = args->boot_device; sun4uv_init(get_system_memory(), RAM_size, boot_devices, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, &hwdefs[2]); } diff --git a/hw/tosa.c b/hw/tosa.c index 297a8c2..512278c 100644 --- a/hw/tosa.c +++ b/hw/tosa.c @@ -205,11 +205,12 @@ static struct arm_boot_info tosa_binfo = { .ram_size = 0x04000000, }; -static void tosa_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void tosa_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *rom = g_new(MemoryRegion, 1); PXA2xxState *mpu; diff --git a/hw/versatilepb.c b/hw/versatilepb.c index 7a92034..686dcc7 100644 --- a/hw/versatilepb.c +++ b/hw/versatilepb.c @@ -342,22 +342,28 @@ static void versatile_init(ram_addr_t ram_size, arm_load_kernel(cpu, &versatile_binfo); } -static void vpb_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void vpb_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; versatile_init(ram_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, 0x183); } -static void vab_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void vab_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; versatile_init(ram_size, boot_device, kernel_filename, kernel_cmdline, diff --git a/hw/vexpress.c b/hw/vexpress.c index 3596d1e..36503d6 100644 --- a/hw/vexpress.c +++ b/hw/vexpress.c @@ -467,25 +467,27 @@ static void vexpress_common_init(const VEDBoardInfo *daughterboard, arm_load_kernel(arm_env_get_cpu(first_cpu), &vexpress_binfo); } -static void vexpress_a9_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void vexpress_a9_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; vexpress_common_init(&a9_daughterboard, ram_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } -static void vexpress_a15_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void vexpress_a15_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; vexpress_common_init(&a15_daughterboard, ram_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); diff --git a/hw/virtex_ml507.c b/hw/virtex_ml507.c index 79bc0d1..a09b27a 100644 --- a/hw/virtex_ml507.c +++ b/hw/virtex_ml507.c @@ -183,12 +183,12 @@ static int xilinx_load_device_tree(target_phys_addr_t addr, return fdt_size; } -static void virtex_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void virtex_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; MemoryRegion *address_space_mem = get_system_memory(); DeviceState *dev; PowerPCCPU *cpu; diff --git a/hw/xen_machine_pv.c b/hw/xen_machine_pv.c index 4b72aa7..4264703 100644 --- a/hw/xen_machine_pv.c +++ b/hw/xen_machine_pv.c @@ -29,13 +29,12 @@ #include "xen_domainbuild.h" #include "blockdev.h" -static void xen_init_pv(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void xen_init_pv(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; X86CPU *cpu; CPUX86State *env; DriveInfo *dinfo; diff --git a/hw/xilinx_zynq.c b/hw/xilinx_zynq.c index 7e6c273..83f322e 100644 --- a/hw/xilinx_zynq.c +++ b/hw/xilinx_zynq.c @@ -46,10 +46,13 @@ static void gem_init(NICInfo *nd, uint32_t base, qemu_irq irq) sysbus_connect_irq(s, 0, irq); } -static void zynq_init(ram_addr_t ram_size, const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void zynq_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; ARMCPU *cpu; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *ext_ram = g_new(MemoryRegion, 1); diff --git a/hw/xtensa_lx60.c b/hw/xtensa_lx60.c index 3653f65..1fd2c47 100644 --- a/hw/xtensa_lx60.c +++ b/hw/xtensa_lx60.c @@ -268,11 +268,14 @@ static void lx_init(const LxBoardDesc *board, } } -static void xtensa_lx60_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void xtensa_lx60_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; static const LxBoardDesc lx60_board = { .flash_size = 0x400000, .flash_sector_size = 0x10000, @@ -283,11 +286,14 @@ static void xtensa_lx60_init(ram_addr_t ram_size, initrd_filename, cpu_model); } -static void xtensa_lx200_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void xtensa_lx200_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; static const LxBoardDesc lx200_board = { .flash_size = 0x1000000, .flash_sector_size = 0x20000, diff --git a/hw/xtensa_sim.c b/hw/xtensa_sim.c index 831460b..2e846d8 100644 --- a/hw/xtensa_sim.c +++ b/hw/xtensa_sim.c @@ -96,11 +96,14 @@ static void sim_init(ram_addr_t ram_size, } } -static void xtensa_sim_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void xtensa_sim_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; if (!cpu_model) { cpu_model = XTENSA_DEFAULT_CPU_MODEL; } diff --git a/hw/z2.c b/hw/z2.c index 289cee9..0927bad 100644 --- a/hw/z2.c +++ b/hw/z2.c @@ -294,11 +294,12 @@ static TypeInfo aer915_info = { .class_init = aer915_class_init, }; -static void z2_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void z2_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; MemoryRegion *address_space_mem = get_system_memory(); uint32_t sector_len = 0x10000; PXA2xxState *mpu; diff --git a/vl.c b/vl.c index 8d305ca..b05e224 100644 --- a/vl.c +++ b/vl.c @@ -3624,8 +3624,13 @@ int main(int argc, char **argv, char **envp) qdev_machine_init(); - machine->init(ram_size, boot_devices, - kernel_filename, kernel_cmdline, initrd_filename, cpu_model); + QEMUMachineInitArgs args = { .ram_size = ram_size, + .boot_device = boot_devices, + .kernel_filename = kernel_filename, + .kernel_cmdline = kernel_cmdline, + .initrd_filename = initrd_filename, + .cpu_model = cpu_model }; + machine->init(&args); cpu_synchronize_all_post_init(); -- 1.7.11.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 20:44:23 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 20:44:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKEkW-0007ZF-H1; Fri, 05 Oct 2012 20:43:56 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKEkV-0007Z9-4n for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 20:43:55 +0000 Received: from [85.158.139.83:46792] by server-6.bemta-5.messagelabs.com id 14/4A-14717-A864F605; Fri, 05 Oct 2012 20:43:54 +0000 X-Env-Sender: ehabkost@redhat.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1349469831!28019695!1 X-Originating-IP: [209.132.183.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTcwODY=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6430 invoked from network); 5 Oct 2012 20:43:52 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-5.tower-182.messagelabs.com with SMTP; 5 Oct 2012 20:43:52 -0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q95KhTnu005967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Oct 2012 16:43:29 -0400 Received: from blackpad.lan.raisama.net (vpn1-7-193.gru2.redhat.com [10.97.7.193]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q95KhSte026003; Fri, 5 Oct 2012 16:43:28 -0400 Received: by blackpad.lan.raisama.net (Postfix, from userid 500) id 25B96203604; Fri, 5 Oct 2012 17:44:28 -0300 (BRT) From: Eduardo Habkost To: qemu-devel@nongnu.org Date: Fri, 5 Oct 2012 17:44:26 -0300 Message-Id: <1349469866-1542-1-git-send-email-ehabkost@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Cc: Peter Maydell , Evgeny Voevodin , Peter Crosthwaite , Max Filippov , "Edgar E. Iglesias" , Guan Xuetao , xen-devel@lists.xensource.com, Igor Mitsyanko , Magnus Damm , Alexander Graf , =?UTF-8?q?Herv=C3=A9=20Poussineau?= , Maksim Kozlov , Andrzej Zaborowski , Fabien Chouteau , Jan Kiszka , Paul Brook , Blue Swirl , Anthony Liguori , Michael Walle , qemu-ppc@nongnu.org, Dmitry Solodkiy , Aurelien Jarno Subject: [Xen-devel] [QEMU PATCH] create struct for machine initialization arguments (v3) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This should help us to: - More easily add or remove machine initialization arguments without having to change every single machine init function; - More easily make mechanical changes involving the machine init functions in the future; - Let machine initialization forward the init arguments to other functions more easily. This change was half-mechanical process: first the struct was added with the local ram_size, boot_device, kernel_*, initrd_*, and cpu_model local variable initialization to all functions. Then the compiler helped me locate the local variables that are unused, so they could be removed. Changes v2 -> v3: - Fix typo (missing dot) on main() - Fix another mistake on xen_init_pv() (I had forgotten to add local variables to replace the old function arguments) Changes v1 -> v2: - Fix mistake on the conversion of pc_xen_hvm_init() and xen_init_pv() Signed-off-by: Eduardo Habkost --- hw/alpha_dp264.c | 12 ++-- hw/an5206.c | 8 +-- hw/axis_dev88.c | 9 +-- hw/boards.h | 16 +++-- hw/collie.c | 9 +-- hw/dummy_m68k.c | 8 +-- hw/exynos4_boards.c | 16 ++--- hw/gumstix.c | 11 +--- hw/highbank.c | 10 ++-- hw/integratorcp.c | 10 ++-- hw/kzm.c | 10 ++-- hw/leon3.c | 10 ++-- hw/lm32_boards.c | 18 +++--- hw/mainstone.c | 10 ++-- hw/mcf5208.c | 8 +-- hw/milkymist.c | 10 ++-- hw/mips_fulong2e.c | 9 ++- hw/mips_jazz.c | 14 ++--- hw/mips_malta.c | 10 ++-- hw/mips_mipssim.c | 10 ++-- hw/mips_r4k.c | 10 ++-- hw/musicpal.c | 9 +-- hw/nseries.c | 22 ++++--- hw/null-machine.c | 7 +-- hw/omap_sx1.c | 22 ++++--- hw/openrisc_sim.c | 10 ++-- hw/palm.c | 9 +-- hw/pc_piix.c | 50 ++++++++-------- hw/petalogix_ml605_mmu.c | 8 +-- hw/petalogix_s3adsp1800_mmu.c | 8 +-- hw/ppc/e500plat.c | 13 +++-- hw/ppc/mpc8544ds.c | 13 +++-- hw/ppc405_boards.c | 25 ++++---- hw/ppc440_bamboo.c | 12 ++-- hw/ppc_newworld.c | 13 +++-- hw/ppc_oldworld.c | 13 +++-- hw/ppc_prep.c | 13 +++-- hw/puv3.c | 8 ++- hw/r2d.c | 9 +-- hw/realview.c | 44 +++++++++----- hw/s390-virtio.c | 13 +++-- hw/shix.c | 6 +- hw/spapr.c | 13 +++-- hw/spitz.c | 40 ++++++++----- hw/stellaris.c | 14 ++--- hw/sun4m.c | 133 ++++++++++++++++++++++++++---------------- hw/sun4u.c | 39 ++++++++----- hw/tosa.c | 9 +-- hw/versatilepb.c | 22 ++++--- hw/vexpress.c | 26 +++++---- hw/virtex_ml507.c | 10 ++-- hw/xen_machine_pv.c | 11 ++-- hw/xilinx_zynq.c | 9 ++- hw/xtensa_lx60.c | 22 ++++--- hw/xtensa_sim.c | 11 ++-- hw/z2.c | 9 +-- vl.c | 9 ++- 57 files changed, 518 insertions(+), 414 deletions(-) diff --git a/hw/alpha_dp264.c b/hw/alpha_dp264.c index 9eb939f..2c2e237 100644 --- a/hw/alpha_dp264.c +++ b/hw/alpha_dp264.c @@ -42,13 +42,13 @@ static int clipper_pci_map_irq(PCIDevice *d, int irq_num) return (slot + 1) * 4 + irq_num; } -static void clipper_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void clipper_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; CPUAlphaState *cpus[4]; PCIBus *pci_bus; ISABus *isa_bus; diff --git a/hw/an5206.c b/hw/an5206.c index 25407c0..042c5fc 100644 --- a/hw/an5206.c +++ b/hw/an5206.c @@ -19,11 +19,11 @@ /* Board init. */ -static void an5206_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void an5206_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; CPUM68KState *env; int kernel_size; uint64_t elf_entry; diff --git a/hw/axis_dev88.c b/hw/axis_dev88.c index eab6327..2fd7356 100644 --- a/hw/axis_dev88.c +++ b/hw/axis_dev88.c @@ -242,11 +242,12 @@ static const MemoryRegionOps gpio_ops = { static struct cris_load_info li; static -void axisdev88_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +void axisdev88_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; CRISCPU *cpu; CPUCRISState *env; DeviceState *dev; diff --git a/hw/boards.h b/hw/boards.h index a2e0a54..813d0e5 100644 --- a/hw/boards.h +++ b/hw/boards.h @@ -5,12 +5,16 @@ #include "qdev.h" -typedef void QEMUMachineInitFunc(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model); +typedef struct QEMUMachineInitArgs { + ram_addr_t ram_size; + const char *boot_device; + const char *kernel_filename; + const char *kernel_cmdline; + const char *initrd_filename; + const char *cpu_model; +} QEMUMachineInitArgs; + +typedef void QEMUMachineInitFunc(QEMUMachineInitArgs *args); typedef void QEMUMachineResetFunc(void); diff --git a/hw/collie.c b/hw/collie.c index 56f89a9..695982a 100644 --- a/hw/collie.c +++ b/hw/collie.c @@ -23,11 +23,12 @@ static struct arm_boot_info collie_binfo = { .ram_size = 0x20000000, }; -static void collie_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void collie_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; StrongARMState *s; DriveInfo *dinfo; MemoryRegion *sysmem = get_system_memory(); diff --git a/hw/dummy_m68k.c b/hw/dummy_m68k.c index 7cc7a99..f436a0c 100644 --- a/hw/dummy_m68k.c +++ b/hw/dummy_m68k.c @@ -16,11 +16,11 @@ /* Board init. */ -static void dummy_m68k_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void dummy_m68k_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; CPUM68KState *env; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *ram = g_new(MemoryRegion, 1); diff --git a/hw/exynos4_boards.c b/hw/exynos4_boards.c index 4bb0a60..4951064 100644 --- a/hw/exynos4_boards.c +++ b/hw/exynos4_boards.c @@ -130,22 +130,22 @@ static Exynos4210State *exynos4_boards_init_common( exynos4_board_ram_size[board_type]); } -static void nuri_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void nuri_init(QEMUMachineInitArgs *args) { + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; exynos4_boards_init_common(kernel_filename, kernel_cmdline, initrd_filename, EXYNOS4_BOARD_NURI); arm_load_kernel(arm_env_get_cpu(first_cpu), &exynos4_board_binfo); } -static void smdkc210_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void smdkc210_init(QEMUMachineInitArgs *args) { + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; Exynos4210State *s = exynos4_boards_init_common(kernel_filename, kernel_cmdline, initrd_filename, EXYNOS4_BOARD_SMDKC210); diff --git a/hw/gumstix.c b/hw/gumstix.c index 13a36ea..4103a88 100644 --- a/hw/gumstix.c +++ b/hw/gumstix.c @@ -45,10 +45,7 @@ static const int sector_len = 128 * 1024; -static void connex_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void connex_init(QEMUMachineInitArgs *args) { PXA2xxState *cpu; DriveInfo *dinfo; @@ -84,11 +81,9 @@ static void connex_init(ram_addr_t ram_size, qdev_get_gpio_in(cpu->gpio, 36)); } -static void verdex_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void verdex_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; PXA2xxState *cpu; DriveInfo *dinfo; int be; diff --git a/hw/highbank.c b/hw/highbank.c index 11aa131..15036b6 100644 --- a/hw/highbank.c +++ b/hw/highbank.c @@ -187,11 +187,13 @@ static struct arm_boot_info highbank_binfo; * 32-bit host, set the reg value of memory to 0xf7ff00000 in the * device tree and pass -m 2047 to QEMU. */ -static void highbank_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void highbank_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; DeviceState *dev; SysBusDevice *busdev; qemu_irq *irqp; diff --git a/hw/integratorcp.c b/hw/integratorcp.c index d0e2e90..ac0ea83 100644 --- a/hw/integratorcp.c +++ b/hw/integratorcp.c @@ -438,11 +438,13 @@ static struct arm_boot_info integrator_binfo = { .board_id = 0x113, }; -static void integratorcp_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void integratorcp_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; ARMCPU *cpu; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *ram = g_new(MemoryRegion, 1); diff --git a/hw/kzm.c b/hw/kzm.c index 68cd1b4..d1266d9 100644 --- a/hw/kzm.c +++ b/hw/kzm.c @@ -70,11 +70,13 @@ static struct arm_boot_info kzm_binfo = { .board_id = 1722, }; -static void kzm_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void kzm_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; ARMCPU *cpu; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *ram = g_new(MemoryRegion, 1); diff --git a/hw/leon3.c b/hw/leon3.c index 878d3aa..6486b7b 100644 --- a/hw/leon3.c +++ b/hw/leon3.c @@ -94,13 +94,11 @@ static void leon3_set_pil_in(void *opaque, uint32_t pil_in) } } -static void leon3_generic_hw_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void leon3_generic_hw_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; SPARCCPU *cpu; CPUSPARCState *env; MemoryRegion *address_space_mem = get_system_memory(); diff --git a/hw/lm32_boards.c b/hw/lm32_boards.c index b76d800..c5a62c8 100644 --- a/hw/lm32_boards.c +++ b/hw/lm32_boards.c @@ -69,12 +69,10 @@ static void main_cpu_reset(void *opaque) env->deba = reset_info->flash_base; } -static void lm32_evr_init(ram_addr_t ram_size_not_used, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void lm32_evr_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; LM32CPU *cpu; CPULM32State *env; DriveInfo *dinfo; @@ -159,12 +157,12 @@ static void lm32_evr_init(ram_addr_t ram_size_not_used, qemu_register_reset(main_cpu_reset, reset_info); } -static void lm32_uclinux_init(ram_addr_t ram_size_not_used, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void lm32_uclinux_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; LM32CPU *cpu; CPULM32State *env; DriveInfo *dinfo; diff --git a/hw/mainstone.c b/hw/mainstone.c index 97687b6..c0d6034 100644 --- a/hw/mainstone.c +++ b/hw/mainstone.c @@ -171,11 +171,13 @@ static void mainstone_common_init(MemoryRegion *address_space_mem, arm_load_kernel(mpu->cpu, &mainstone_binfo); } -static void mainstone_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void mainstone_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; mainstone_common_init(get_system_memory(), ram_size, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, mainstone, 0x196); } diff --git a/hw/mcf5208.c b/hw/mcf5208.c index ee25b1b..688bc3c 100644 --- a/hw/mcf5208.c +++ b/hw/mcf5208.c @@ -187,11 +187,11 @@ static void mcf5208_sys_init(MemoryRegion *address_space, qemu_irq *pic) } } -static void mcf5208evb_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void mcf5208evb_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; CPUM68KState *env; int kernel_size; uint64_t elf_entry; diff --git a/hw/milkymist.c b/hw/milkymist.c index 2e7235b..ca9ed43 100644 --- a/hw/milkymist.c +++ b/hw/milkymist.c @@ -73,12 +73,12 @@ static void main_cpu_reset(void *opaque) } static void -milkymist_init(ram_addr_t ram_size_not_used, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +milkymist_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; LM32CPU *cpu; CPULM32State *env; int kernel_size; diff --git a/hw/mips_fulong2e.c b/hw/mips_fulong2e.c index 38e4b86..af7bb50 100644 --- a/hw/mips_fulong2e.c +++ b/hw/mips_fulong2e.c @@ -256,10 +256,13 @@ static void cpu_request_exit(void *opaque, int irq, int level) } } -static void mips_fulong2e_init(ram_addr_t ram_size, const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void mips_fulong2e_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; char *filename; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *ram = g_new(MemoryRegion, 1); diff --git a/hw/mips_jazz.c b/hw/mips_jazz.c index db927f1..14df4d7 100644 --- a/hw/mips_jazz.c +++ b/hw/mips_jazz.c @@ -302,21 +302,19 @@ static void mips_jazz_init(MemoryRegion *address_space, } static -void mips_magnum_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +void mips_magnum_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; mips_jazz_init(get_system_memory(), get_system_io(), ram_size, cpu_model, JAZZ_MAGNUM); } static -void mips_pica61_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +void mips_pica61_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; mips_jazz_init(get_system_memory(), get_system_io(), ram_size, cpu_model, JAZZ_PICA61); } diff --git a/hw/mips_malta.c b/hw/mips_malta.c index ad23f26..14151f9 100644 --- a/hw/mips_malta.c +++ b/hw/mips_malta.c @@ -777,11 +777,13 @@ static void cpu_request_exit(void *opaque, int irq, int level) } static -void mips_malta_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +void mips_malta_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; char *filename; pflash_t *fl; MemoryRegion *system_memory = get_system_memory(); diff --git a/hw/mips_mipssim.c b/hw/mips_mipssim.c index 830f635..a1d3945 100644 --- a/hw/mips_mipssim.c +++ b/hw/mips_mipssim.c @@ -131,11 +131,13 @@ static void mipsnet_init(int base, qemu_irq irq, NICInfo *nd) } static void -mips_mipssim_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +mips_mipssim_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; char *filename; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *ram = g_new(MemoryRegion, 1); diff --git a/hw/mips_r4k.c b/hw/mips_r4k.c index 967a76e..b73cdc3 100644 --- a/hw/mips_r4k.c +++ b/hw/mips_r4k.c @@ -151,11 +151,13 @@ static void main_cpu_reset(void *opaque) static const int sector_len = 32 * 1024; static -void mips_r4k_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +void mips_r4k_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; char *filename; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *ram = g_new(MemoryRegion, 1); diff --git a/hw/musicpal.c b/hw/musicpal.c index f305e21..f06814c 100644 --- a/hw/musicpal.c +++ b/hw/musicpal.c @@ -1508,11 +1508,12 @@ static struct arm_boot_info musicpal_binfo = { .board_id = 0x20e, }; -static void musicpal_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void musicpal_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; ARMCPU *cpu; qemu_irq *cpu_pic; qemu_irq pic[32]; diff --git a/hw/nseries.c b/hw/nseries.c index 6df71eb..7ada90d 100644 --- a/hw/nseries.c +++ b/hw/nseries.c @@ -1397,21 +1397,27 @@ static struct arm_boot_info n810_binfo = { .atag_board = n810_atag_setup, }; -static void n800_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void n800_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; return n8x0_init(ram_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, &n800_binfo, 800); } -static void n810_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void n810_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; return n8x0_init(ram_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, &n810_binfo, 810); diff --git a/hw/null-machine.c b/hw/null-machine.c index 69910d3..d813c08 100644 --- a/hw/null-machine.c +++ b/hw/null-machine.c @@ -15,12 +15,7 @@ #include "hw/hw.h" #include "hw/boards.h" -static void machine_none_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void machine_none_init(QEMUMachineInitArgs *args) { } diff --git a/hw/omap_sx1.c b/hw/omap_sx1.c index abca341..ad17487 100644 --- a/hw/omap_sx1.c +++ b/hw/omap_sx1.c @@ -209,20 +209,26 @@ static void sx1_init(ram_addr_t ram_size, //~ qemu_console_resize(ds, 640, 480); } -static void sx1_init_v1(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void sx1_init_v1(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sx1_init(ram_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, 1); } -static void sx1_init_v2(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void sx1_init_v2(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sx1_init(ram_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, 2); } diff --git a/hw/openrisc_sim.c b/hw/openrisc_sim.c index 55e97f0..e96a944 100644 --- a/hw/openrisc_sim.c +++ b/hw/openrisc_sim.c @@ -90,13 +90,11 @@ static void cpu_openrisc_load_kernel(ram_addr_t ram_size, cpu->env.pc = entry; } -static void openrisc_sim_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void openrisc_sim_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; OpenRISCCPU *cpu = NULL; MemoryRegion *ram; int n; diff --git a/hw/palm.c b/hw/palm.c index bacdc90..032b8d6 100644 --- a/hw/palm.c +++ b/hw/palm.c @@ -190,11 +190,12 @@ static struct arm_boot_info palmte_binfo = { .board_id = 0x331, }; -static void palmte_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void palmte_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; MemoryRegion *address_space_mem = get_system_memory(); struct omap_mpu_state_s *mpu; int flash_size = 0x00800000; diff --git a/hw/pc_piix.c b/hw/pc_piix.c index fd5898f..c9fca05 100644 --- a/hw/pc_piix.c +++ b/hw/pc_piix.c @@ -287,13 +287,14 @@ static void pc_init1(MemoryRegion *system_memory, } } -static void pc_init_pci(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void pc_init_pci(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; pc_init1(get_system_memory(), get_system_io(), ram_size, boot_device, @@ -301,13 +302,14 @@ static void pc_init_pci(ram_addr_t ram_size, initrd_filename, cpu_model, 1, 1); } -static void pc_init_pci_no_kvmclock(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void pc_init_pci_no_kvmclock(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; pc_init1(get_system_memory(), get_system_io(), ram_size, boot_device, @@ -315,13 +317,14 @@ static void pc_init_pci_no_kvmclock(ram_addr_t ram_size, initrd_filename, cpu_model, 1, 0); } -static void pc_init_isa(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void pc_init_isa(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; if (cpu_model == NULL) cpu_model = "486"; pc_init1(get_system_memory(), @@ -332,19 +335,12 @@ static void pc_init_isa(ram_addr_t ram_size, } #ifdef CONFIG_XEN -static void pc_xen_hvm_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void pc_xen_hvm_init(QEMUMachineInitArgs *args) { if (xen_hvm_init() != 0) { hw_error("xen hardware virtual machine initialisation failed"); } - pc_init_pci_no_kvmclock(ram_size, boot_device, - kernel_filename, kernel_cmdline, - initrd_filename, cpu_model); + pc_init_pci_no_kvmclock(args); xen_vcpu_init(); } #endif diff --git a/hw/petalogix_ml605_mmu.c b/hw/petalogix_ml605_mmu.c index dced648..ace0187 100644 --- a/hw/petalogix_ml605_mmu.c +++ b/hw/petalogix_ml605_mmu.c @@ -70,12 +70,10 @@ static void machine_cpu_reset(MicroBlazeCPU *cpu) } static void -petalogix_ml605_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +petalogix_ml605_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; MemoryRegion *address_space_mem = get_system_memory(); DeviceState *dev, *dma, *eth0; MicroBlazeCPU *cpu; diff --git a/hw/petalogix_s3adsp1800_mmu.c b/hw/petalogix_s3adsp1800_mmu.c index 2cf6882..71c32ce 100644 --- a/hw/petalogix_s3adsp1800_mmu.c +++ b/hw/petalogix_s3adsp1800_mmu.c @@ -57,12 +57,10 @@ static void machine_cpu_reset(MicroBlazeCPU *cpu) } static void -petalogix_s3adsp1800_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +petalogix_s3adsp1800_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; DeviceState *dev; MicroBlazeCPU *cpu; CPUMBState *env; diff --git a/hw/ppc/e500plat.c b/hw/ppc/e500plat.c index 60a5cb3..4cfb940 100644 --- a/hw/ppc/e500plat.c +++ b/hw/ppc/e500plat.c @@ -25,13 +25,14 @@ static void e500plat_fixup_devtree(PPCE500Params *params, void *fdt) sizeof(compatible)); } -static void e500plat_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void e500plat_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *boot_device = args->boot_device; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; PPCE500Params params = { .ram_size = ram_size, .boot_device = boot_device, diff --git a/hw/ppc/mpc8544ds.c b/hw/ppc/mpc8544ds.c index 984d21c..e651661 100644 --- a/hw/ppc/mpc8544ds.c +++ b/hw/ppc/mpc8544ds.c @@ -25,13 +25,14 @@ static void mpc8544ds_fixup_devtree(PPCE500Params *params, void *fdt) sizeof(compatible)); } -static void mpc8544ds_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void mpc8544ds_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *boot_device = args->boot_device; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; PPCE500Params params = { .ram_size = ram_size, .boot_device = boot_device, diff --git a/hw/ppc405_boards.c b/hw/ppc405_boards.c index 476775d..e848cb0 100644 --- a/hw/ppc405_boards.c +++ b/hw/ppc405_boards.c @@ -158,7 +158,7 @@ static void ref405ep_fpga_reset (void *opaque) fpga->reg1 = 0x0F; } -static void ref405ep_fpga_init (MemoryRegion *sysmem, uint32_t base) +static void ref405ep_fpga_init(MemoryRegion *sysmem, uint32_t base) { ref405ep_fpga_t *fpga; MemoryRegion *fpga_memory = g_new(MemoryRegion, 1); @@ -170,13 +170,12 @@ static void ref405ep_fpga_init (MemoryRegion *sysmem, uint32_t base) qemu_register_reset(&ref405ep_fpga_reset, fpga); } -static void ref405ep_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void ref405ep_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; char *filename; ppc4xx_bd_info_t bd; CPUPPCState *env; @@ -484,7 +483,7 @@ static void taihu_cpld_reset (void *opaque) cpld->reg1 = 0x80; } -static void taihu_cpld_init (MemoryRegion *sysmem, uint32_t base) +static void taihu_cpld_init(MemoryRegion *sysmem, uint32_t base) { taihu_cpld_t *cpld; MemoryRegion *cpld_memory = g_new(MemoryRegion, 1); @@ -495,13 +494,11 @@ static void taihu_cpld_init (MemoryRegion *sysmem, uint32_t base) qemu_register_reset(&taihu_cpld_reset, cpld); } -static void taihu_405ep_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void taihu_405ep_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *kernel_filename = args->kernel_filename; + const char *initrd_filename = args->initrd_filename; char *filename; qemu_irq *pic; MemoryRegion *sysmem = get_system_memory(); diff --git a/hw/ppc440_bamboo.c b/hw/ppc440_bamboo.c index c198071..78e7985 100644 --- a/hw/ppc440_bamboo.c +++ b/hw/ppc440_bamboo.c @@ -157,13 +157,13 @@ static void main_cpu_reset(void *opaque) mmubooke_create_initial_mapping(env, 0, 0); } -static void bamboo_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void bamboo_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; unsigned int pci_irq_nrs[4] = { 28, 27, 26, 25 }; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *ram_memories diff --git a/hw/ppc_newworld.c b/hw/ppc_newworld.c index e95cfe8..e7c0747 100644 --- a/hw/ppc_newworld.c +++ b/hw/ppc_newworld.c @@ -129,13 +129,14 @@ static void ppc_core99_reset(void *opaque) } /* PowerPC Mac99 hardware initialisation */ -static void ppc_core99_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void ppc_core99_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; PowerPCCPU *cpu = NULL; CPUPPCState *env = NULL; char *filename; diff --git a/hw/ppc_oldworld.c b/hw/ppc_oldworld.c index 1dcd8a6..d9f76a8 100644 --- a/hw/ppc_oldworld.c +++ b/hw/ppc_oldworld.c @@ -72,13 +72,14 @@ static void ppc_heathrow_reset(void *opaque) cpu_reset(CPU(cpu)); } -static void ppc_heathrow_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void ppc_heathrow_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; MemoryRegion *sysmem = get_system_memory(); PowerPCCPU *cpu = NULL; CPUPPCState *env = NULL; diff --git a/hw/ppc_prep.c b/hw/ppc_prep.c index 592b7b2..f51f78a 100644 --- a/hw/ppc_prep.c +++ b/hw/ppc_prep.c @@ -448,13 +448,14 @@ static void ppc_prep_reset(void *opaque) } /* PowerPC PREP hardware initialisation */ -static void ppc_prep_init (ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void ppc_prep_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; MemoryRegion *sysmem = get_system_memory(); PowerPCCPU *cpu = NULL; CPUPPCState *env = NULL; diff --git a/hw/puv3.c b/hw/puv3.c index 43f7216..764799c 100644 --- a/hw/puv3.c +++ b/hw/puv3.c @@ -91,10 +91,12 @@ static void puv3_load_kernel(const char *kernel_filename) graphic_console_init(NULL, NULL, NULL, NULL, NULL); } -static void puv3_init(ram_addr_t ram_size, const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void puv3_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *initrd_filename = args->initrd_filename; CPUUniCore32State *env; if (initrd_filename) { diff --git a/hw/r2d.c b/hw/r2d.c index 0f16e81..5daa42f 100644 --- a/hw/r2d.c +++ b/hw/r2d.c @@ -219,11 +219,12 @@ static struct QEMU_PACKED char kernel_cmdline[256]; } boot_params; -static void r2d_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void r2d_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; SuperHCPU *cpu; CPUSH4State *env; ResetData *reset_info; diff --git a/hw/realview.c b/hw/realview.c index 19db4d0..8dc4be6 100644 --- a/hw/realview.c +++ b/hw/realview.c @@ -330,11 +330,14 @@ static void realview_init(ram_addr_t ram_size, arm_load_kernel(arm_env_get_cpu(first_cpu), &realview_binfo); } -static void realview_eb_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void realview_eb_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; if (!cpu_model) { cpu_model = "arm926"; } @@ -342,11 +345,14 @@ static void realview_eb_init(ram_addr_t ram_size, initrd_filename, cpu_model, BOARD_EB); } -static void realview_eb_mpcore_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void realview_eb_mpcore_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; if (!cpu_model) { cpu_model = "arm11mpcore"; } @@ -354,11 +360,14 @@ static void realview_eb_mpcore_init(ram_addr_t ram_size, initrd_filename, cpu_model, BOARD_EB_MPCORE); } -static void realview_pb_a8_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void realview_pb_a8_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; if (!cpu_model) { cpu_model = "cortex-a8"; } @@ -366,11 +375,14 @@ static void realview_pb_a8_init(ram_addr_t ram_size, initrd_filename, cpu_model, BOARD_PB_A8); } -static void realview_pbx_a9_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void realview_pbx_a9_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; if (!cpu_model) { cpu_model = "cortex-a9"; } diff --git a/hw/s390-virtio.c b/hw/s390-virtio.c index 47eed35..39ff178 100644 --- a/hw/s390-virtio.c +++ b/hw/s390-virtio.c @@ -151,13 +151,14 @@ unsigned s390_del_running_cpu(CPUS390XState *env) } /* PC hardware initialisation */ -static void s390_init(ram_addr_t my_ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void s390_init(QEMUMachineInitArgs *args) { + ram_addr_t my_ram_size = args->ram_size; + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; CPUS390XState *env = NULL; MemoryRegion *sysmem = get_system_memory(); MemoryRegion *ram = g_new(MemoryRegion, 1); diff --git a/hw/shix.c b/hw/shix.c index dd9ce17..b56dd54 100644 --- a/hw/shix.c +++ b/hw/shix.c @@ -37,11 +37,9 @@ #define BIOS_FILENAME "shix_bios.bin" #define BIOS_ADDRESS 0xA0000000 -static void shix_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void shix_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; int ret; CPUSH4State *env; struct SH7750State *s; diff --git a/hw/spapr.c b/hw/spapr.c index c34b767..8921c4d 100644 --- a/hw/spapr.c +++ b/hw/spapr.c @@ -603,13 +603,14 @@ static int spapr_vga_init(PCIBus *pci_bus) } /* pSeries LPAR / sPAPR hardware init */ -static void ppc_spapr_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void ppc_spapr_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; PowerPCCPU *cpu; CPUPPCState *env; PCIHostState *phb; diff --git a/hw/spitz.c b/hw/spitz.c index 20e7835..df829b3 100644 --- a/hw/spitz.c +++ b/hw/spitz.c @@ -936,38 +936,46 @@ static void spitz_common_init(ram_addr_t ram_size, sl_bootparam_write(SL_PXA_PARAM_BASE); } -static void spitz_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void spitz_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; spitz_common_init(ram_size, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, spitz, 0x2c9); } -static void borzoi_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void borzoi_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; spitz_common_init(ram_size, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, borzoi, 0x33f); } -static void akita_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void akita_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; spitz_common_init(ram_size, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, akita, 0x2e8); } -static void terrier_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void terrier_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; spitz_common_init(ram_size, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, terrier, 0x33f); } diff --git a/hw/stellaris.c b/hw/stellaris.c index 562fbbf..b79c7fb 100644 --- a/hw/stellaris.c +++ b/hw/stellaris.c @@ -1358,19 +1358,17 @@ static void stellaris_init(const char *kernel_filename, const char *cpu_model, } /* FIXME: Figure out how to generate these from stellaris_boards. */ -static void lm3s811evb_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void lm3s811evb_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; stellaris_init(kernel_filename, cpu_model, &stellaris_boards[0]); } -static void lm3s6965evb_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void lm3s6965evb_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; stellaris_init(kernel_filename, cpu_model, &stellaris_boards[1]); } diff --git a/hw/sun4m.c b/hw/sun4m.c index c98cd5e..22e011f 100644 --- a/hw/sun4m.c +++ b/hw/sun4m.c @@ -1303,92 +1303,118 @@ static const struct sun4m_hwdef sun4m_hwdefs[] = { }; /* SPARCstation 5 hardware initialisation */ -static void ss5_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss5_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[0], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCstation 10 hardware initialisation */ -static void ss10_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss10_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[1], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCserver 600MP hardware initialisation */ -static void ss600mp_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss600mp_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[2], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCstation 20 hardware initialisation */ -static void ss20_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss20_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[3], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCstation Voyager hardware initialisation */ -static void vger_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void vger_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[4], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCstation LX hardware initialisation */ -static void ss_lx_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss_lx_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[5], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCstation 4 hardware initialisation */ -static void ss4_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss4_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[6], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCClassic hardware initialisation */ -static void scls_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void scls_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[7], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCbook hardware initialisation */ -static void sbook_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void sbook_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4m_hw_init(&sun4m_hwdefs[8], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } @@ -1651,21 +1677,27 @@ static void sun4d_hw_init(const struct sun4d_hwdef *hwdef, ram_addr_t RAM_size, } /* SPARCserver 1000 hardware initialisation */ -static void ss1000_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss1000_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4d_hw_init(&sun4d_hwdefs[0], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } /* SPARCcenter 2000 hardware initialisation */ -static void ss2000_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss2000_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4d_hw_init(&sun4d_hwdefs[1], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } @@ -1845,11 +1877,14 @@ static void sun4c_hw_init(const struct sun4c_hwdef *hwdef, ram_addr_t RAM_size, } /* SPARCstation 2 hardware initialisation */ -static void ss2_init(ram_addr_t RAM_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void ss2_init(QEMUMachineInitArgs *args) { + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; sun4c_hw_init(&sun4c_hwdefs[0], RAM_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } diff --git a/hw/sun4u.c b/hw/sun4u.c index 07cd042..379768c 100644 --- a/hw/sun4u.c +++ b/hw/sun4u.c @@ -930,31 +930,40 @@ static const struct hwdef hwdefs[] = { }; /* Sun4u hardware initialisation */ -static void sun4u_init(ram_addr_t RAM_size, - const char *boot_devices, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) -{ +static void sun4u_init(QEMUMachineInitArgs *args) +{ + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_devices = args->boot_device; sun4uv_init(get_system_memory(), RAM_size, boot_devices, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, &hwdefs[0]); } /* Sun4v hardware initialisation */ -static void sun4v_init(ram_addr_t RAM_size, - const char *boot_devices, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) -{ +static void sun4v_init(QEMUMachineInitArgs *args) +{ + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_devices = args->boot_device; sun4uv_init(get_system_memory(), RAM_size, boot_devices, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, &hwdefs[1]); } /* Niagara hardware initialisation */ -static void niagara_init(ram_addr_t RAM_size, - const char *boot_devices, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) -{ +static void niagara_init(QEMUMachineInitArgs *args) +{ + ram_addr_t RAM_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_devices = args->boot_device; sun4uv_init(get_system_memory(), RAM_size, boot_devices, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, &hwdefs[2]); } diff --git a/hw/tosa.c b/hw/tosa.c index 297a8c2..512278c 100644 --- a/hw/tosa.c +++ b/hw/tosa.c @@ -205,11 +205,12 @@ static struct arm_boot_info tosa_binfo = { .ram_size = 0x04000000, }; -static void tosa_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void tosa_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *rom = g_new(MemoryRegion, 1); PXA2xxState *mpu; diff --git a/hw/versatilepb.c b/hw/versatilepb.c index 7a92034..686dcc7 100644 --- a/hw/versatilepb.c +++ b/hw/versatilepb.c @@ -342,22 +342,28 @@ static void versatile_init(ram_addr_t ram_size, arm_load_kernel(cpu, &versatile_binfo); } -static void vpb_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void vpb_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; versatile_init(ram_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model, 0x183); } -static void vab_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void vab_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; versatile_init(ram_size, boot_device, kernel_filename, kernel_cmdline, diff --git a/hw/vexpress.c b/hw/vexpress.c index 3596d1e..36503d6 100644 --- a/hw/vexpress.c +++ b/hw/vexpress.c @@ -467,25 +467,27 @@ static void vexpress_common_init(const VEDBoardInfo *daughterboard, arm_load_kernel(arm_env_get_cpu(first_cpu), &vexpress_binfo); } -static void vexpress_a9_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void vexpress_a9_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; vexpress_common_init(&a9_daughterboard, ram_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); } -static void vexpress_a15_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void vexpress_a15_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; vexpress_common_init(&a15_daughterboard, ram_size, boot_device, kernel_filename, kernel_cmdline, initrd_filename, cpu_model); diff --git a/hw/virtex_ml507.c b/hw/virtex_ml507.c index 79bc0d1..a09b27a 100644 --- a/hw/virtex_ml507.c +++ b/hw/virtex_ml507.c @@ -183,12 +183,12 @@ static int xilinx_load_device_tree(target_phys_addr_t addr, return fdt_size; } -static void virtex_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void virtex_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; MemoryRegion *address_space_mem = get_system_memory(); DeviceState *dev; PowerPCCPU *cpu; diff --git a/hw/xen_machine_pv.c b/hw/xen_machine_pv.c index 4b72aa7..4264703 100644 --- a/hw/xen_machine_pv.c +++ b/hw/xen_machine_pv.c @@ -29,13 +29,12 @@ #include "xen_domainbuild.h" #include "blockdev.h" -static void xen_init_pv(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, - const char *kernel_cmdline, - const char *initrd_filename, - const char *cpu_model) +static void xen_init_pv(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; X86CPU *cpu; CPUX86State *env; DriveInfo *dinfo; diff --git a/hw/xilinx_zynq.c b/hw/xilinx_zynq.c index 7e6c273..83f322e 100644 --- a/hw/xilinx_zynq.c +++ b/hw/xilinx_zynq.c @@ -46,10 +46,13 @@ static void gem_init(NICInfo *nd, uint32_t base, qemu_irq irq) sysbus_connect_irq(s, 0, irq); } -static void zynq_init(ram_addr_t ram_size, const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void zynq_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; ARMCPU *cpu; MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *ext_ram = g_new(MemoryRegion, 1); diff --git a/hw/xtensa_lx60.c b/hw/xtensa_lx60.c index 3653f65..1fd2c47 100644 --- a/hw/xtensa_lx60.c +++ b/hw/xtensa_lx60.c @@ -268,11 +268,14 @@ static void lx_init(const LxBoardDesc *board, } } -static void xtensa_lx60_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void xtensa_lx60_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; static const LxBoardDesc lx60_board = { .flash_size = 0x400000, .flash_sector_size = 0x10000, @@ -283,11 +286,14 @@ static void xtensa_lx60_init(ram_addr_t ram_size, initrd_filename, cpu_model); } -static void xtensa_lx200_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void xtensa_lx200_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; static const LxBoardDesc lx200_board = { .flash_size = 0x1000000, .flash_sector_size = 0x20000, diff --git a/hw/xtensa_sim.c b/hw/xtensa_sim.c index 831460b..2e846d8 100644 --- a/hw/xtensa_sim.c +++ b/hw/xtensa_sim.c @@ -96,11 +96,14 @@ static void sim_init(ram_addr_t ram_size, } } -static void xtensa_sim_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void xtensa_sim_init(QEMUMachineInitArgs *args) { + ram_addr_t ram_size = args->ram_size; + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; + const char *boot_device = args->boot_device; if (!cpu_model) { cpu_model = XTENSA_DEFAULT_CPU_MODEL; } diff --git a/hw/z2.c b/hw/z2.c index 289cee9..0927bad 100644 --- a/hw/z2.c +++ b/hw/z2.c @@ -294,11 +294,12 @@ static TypeInfo aer915_info = { .class_init = aer915_class_init, }; -static void z2_init(ram_addr_t ram_size, - const char *boot_device, - const char *kernel_filename, const char *kernel_cmdline, - const char *initrd_filename, const char *cpu_model) +static void z2_init(QEMUMachineInitArgs *args) { + const char *cpu_model = args->cpu_model; + const char *kernel_filename = args->kernel_filename; + const char *kernel_cmdline = args->kernel_cmdline; + const char *initrd_filename = args->initrd_filename; MemoryRegion *address_space_mem = get_system_memory(); uint32_t sector_len = 0x10000; PXA2xxState *mpu; diff --git a/vl.c b/vl.c index 8d305ca..b05e224 100644 --- a/vl.c +++ b/vl.c @@ -3624,8 +3624,13 @@ int main(int argc, char **argv, char **envp) qdev_machine_init(); - machine->init(ram_size, boot_devices, - kernel_filename, kernel_cmdline, initrd_filename, cpu_model); + QEMUMachineInitArgs args = { .ram_size = ram_size, + .boot_device = boot_devices, + .kernel_filename = kernel_filename, + .kernel_cmdline = kernel_cmdline, + .initrd_filename = initrd_filename, + .cpu_model = cpu_model }; + machine->init(&args); cpu_synchronize_all_post_init(); -- 1.7.11.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 20:55:05 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 20:55:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKEv2-0008Ad-6Q; Fri, 05 Oct 2012 20:54:48 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKEv0-0008AQ-U0 for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 20:54:47 +0000 Received: from [85.158.139.83:11816] by server-3.bemta-5.messagelabs.com id 41/66-16108-6194F605; Fri, 05 Oct 2012 20:54:46 +0000 X-Env-Sender: eblake@redhat.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1349470484!29350682!1 X-Originating-IP: [209.132.183.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTcwODY=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7202 invoked from network); 5 Oct 2012 20:54:45 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-14.tower-182.messagelabs.com with SMTP; 5 Oct 2012 20:54:45 -0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q95KsUtw026782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Oct 2012 16:54:31 -0400 Received: from [10.3.113.159] (ovpn-113-159.phx2.redhat.com [10.3.113.159]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q95KsQYu027754; Fri, 5 Oct 2012 16:54:27 -0400 Message-ID: <506F4900.8080404@redhat.com> Date: Fri, 05 Oct 2012 14:54:24 -0600 From: Eric Blake Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: Eduardo Habkost References: <1349468535-14499-1-git-send-email-ehabkost@redhat.com> <20121005204024.GF4362@otherpad.lan.raisama.net> In-Reply-To: <20121005204024.GF4362@otherpad.lan.raisama.net> X-Enigmail-Version: 1.4.4 OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Cc: Peter Maydell , Anthony Liguori , xen-devel@lists.xensource.com, Igor Mitsyanko , Evgeny Voevodin , qemu-devel@nongnu.org, Fabien Chouteau , Alexander Graf , Peter Crosthwaite , Max Filippov , Michael Walle , qemu-ppc@nongnu.org, Paul Brook , Blue Swirl , "Edgar E. Iglesias" , Guan Xuetao , =?ISO-8859-1?Q?Herv=E9_Poussineau?= , Maksim Kozlov , Jan Kiszka , Aurelien Jarno , Dmitry Solodkiy Subject: Re: [Xen-devel] [Qemu-devel] [QEMU PATCH] create struct for machine initialization arguments (v2) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7509912610227064556==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============7509912610227064556== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig2D4E4C062482115DB94FD4D0" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2D4E4C062482115DB94FD4D0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 10/05/2012 02:40 PM, Eduardo Habkost wrote: >>> - machine->init(ram_size, boot_devices, >>> - kernel_filename, kernel_cmdline, initrd_filename, = cpu_model); >>> + QEMUMachineInitArgs args =3D { .ram_size =3D ram_size, >>> + .boot_device =3D boot_devices, >>> + .kernel_filename =3D kernel_filenam= e, >>> + .kernel_cmdline =3D kernel_cmdline,= >>> + initrd_filename =3D initrd_filename= , >> >> Missing dot? >=20 > Funny, GCC didn't complain. Thanks for spotting it! Eww, insidious :P. This assigned local variable initrd_filename to itself, then put the lvalue result of that assignment as the initializer to the next available struct member residing after .kernel_cmdline (which happened to be .initrd_filename). That is, gcc didn't complain because it worked by sheer dumb luck. --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enig2D4E4C062482115DB94FD4D0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBCAAGBQJQb0kCAAoJEKeha0olJ0NqTaQH/iAFRHdvwJYOaXv8ksZrxT22 mimB0inM+fbtYYsjYynjcK+DOs9Jew4L8ZjQDXOT+b79qXJCvu56uzKKnz9O5yw6 dDZX58KHUwLHGrnW1yFG2/k1kRfO+PyQyS0KTFxVpNZMFbX1HPjuQ779waX6Tb8D 1XijiIPsH2JcKk2dvN/3hYR+5AhR6KX82Fs4fB2Y/CxRYah9u1PrIduqMiDLmpV8 JAsuIhpDcgPCk3QewvOxWp4V5OHIYgo/1FdkMgZWXJCjxA2kNrHpcOtdSmKBg7GE BovTo3gjCNHbq0it6hN5PbuoQB2RIXA3jMtWbnhpfA8YV9jMSXV6aPxCU40nZ0c= =40e2 -----END PGP SIGNATURE----- --------------enig2D4E4C062482115DB94FD4D0-- --===============7509912610227064556== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============7509912610227064556==-- From xen-devel-bounces@lists.xen.org Fri Oct 05 20:55:05 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 20:55:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKEv2-0008Ad-6Q; Fri, 05 Oct 2012 20:54:48 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKEv0-0008AQ-U0 for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 20:54:47 +0000 Received: from [85.158.139.83:11816] by server-3.bemta-5.messagelabs.com id 41/66-16108-6194F605; Fri, 05 Oct 2012 20:54:46 +0000 X-Env-Sender: eblake@redhat.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1349470484!29350682!1 X-Originating-IP: [209.132.183.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTcwODY=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7202 invoked from network); 5 Oct 2012 20:54:45 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-14.tower-182.messagelabs.com with SMTP; 5 Oct 2012 20:54:45 -0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q95KsUtw026782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Oct 2012 16:54:31 -0400 Received: from [10.3.113.159] (ovpn-113-159.phx2.redhat.com [10.3.113.159]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q95KsQYu027754; Fri, 5 Oct 2012 16:54:27 -0400 Message-ID: <506F4900.8080404@redhat.com> Date: Fri, 05 Oct 2012 14:54:24 -0600 From: Eric Blake Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: Eduardo Habkost References: <1349468535-14499-1-git-send-email-ehabkost@redhat.com> <20121005204024.GF4362@otherpad.lan.raisama.net> In-Reply-To: <20121005204024.GF4362@otherpad.lan.raisama.net> X-Enigmail-Version: 1.4.4 OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Cc: Peter Maydell , Anthony Liguori , xen-devel@lists.xensource.com, Igor Mitsyanko , Evgeny Voevodin , qemu-devel@nongnu.org, Fabien Chouteau , Alexander Graf , Peter Crosthwaite , Max Filippov , Michael Walle , qemu-ppc@nongnu.org, Paul Brook , Blue Swirl , "Edgar E. Iglesias" , Guan Xuetao , =?ISO-8859-1?Q?Herv=E9_Poussineau?= , Maksim Kozlov , Jan Kiszka , Aurelien Jarno , Dmitry Solodkiy Subject: Re: [Xen-devel] [Qemu-devel] [QEMU PATCH] create struct for machine initialization arguments (v2) X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7509912610227064556==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============7509912610227064556== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig2D4E4C062482115DB94FD4D0" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2D4E4C062482115DB94FD4D0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 10/05/2012 02:40 PM, Eduardo Habkost wrote: >>> - machine->init(ram_size, boot_devices, >>> - kernel_filename, kernel_cmdline, initrd_filename, = cpu_model); >>> + QEMUMachineInitArgs args =3D { .ram_size =3D ram_size, >>> + .boot_device =3D boot_devices, >>> + .kernel_filename =3D kernel_filenam= e, >>> + .kernel_cmdline =3D kernel_cmdline,= >>> + initrd_filename =3D initrd_filename= , >> >> Missing dot? >=20 > Funny, GCC didn't complain. Thanks for spotting it! Eww, insidious :P. This assigned local variable initrd_filename to itself, then put the lvalue result of that assignment as the initializer to the next available struct member residing after .kernel_cmdline (which happened to be .initrd_filename). That is, gcc didn't complain because it worked by sheer dumb luck. --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enig2D4E4C062482115DB94FD4D0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBCAAGBQJQb0kCAAoJEKeha0olJ0NqTaQH/iAFRHdvwJYOaXv8ksZrxT22 mimB0inM+fbtYYsjYynjcK+DOs9Jew4L8ZjQDXOT+b79qXJCvu56uzKKnz9O5yw6 dDZX58KHUwLHGrnW1yFG2/k1kRfO+PyQyS0KTFxVpNZMFbX1HPjuQ779waX6Tb8D 1XijiIPsH2JcKk2dvN/3hYR+5AhR6KX82Fs4fB2Y/CxRYah9u1PrIduqMiDLmpV8 JAsuIhpDcgPCk3QewvOxWp4V5OHIYgo/1FdkMgZWXJCjxA2kNrHpcOtdSmKBg7GE BovTo3gjCNHbq0it6hN5PbuoQB2RIXA3jMtWbnhpfA8YV9jMSXV6aPxCU40nZ0c= =40e2 -----END PGP SIGNATURE----- --------------enig2D4E4C062482115DB94FD4D0-- --===============7509912610227064556== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============7509912610227064556==-- From xen-devel-bounces@lists.xen.org Fri Oct 05 21:23:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 21:23:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKFMH-0000Bo-Iy; Fri, 05 Oct 2012 21:22:57 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKFMG-0000Bj-Dx for Xen-devel@lists.xensource.com; Fri, 05 Oct 2012 21:22:56 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1349472169!4334998!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc5NjAzMQ==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25873 invoked from network); 5 Oct 2012 21:22:50 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 21:22:50 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q95LMhu2027437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Oct 2012 21:22:44 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q95LMghC017023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Oct 2012 21:22:43 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q95LMgOX013994; Fri, 5 Oct 2012 16:22:42 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 05 Oct 2012 14:22:42 -0700 Date: Fri, 5 Oct 2012 14:22:40 -0700 From: Mukesh Rathor To: Ian Campbell Message-ID: <20121005142240.340815be@mantra.us.oracle.com> In-Reply-To: <1349428878.20946.18.camel@zakaz.uk.xensource.com> References: <20120921122123.33489ce1@mantra.us.oracle.com> <1349270495.650.144.camel@zakaz.uk.xensource.com> <20121003153106.65237f07@mantra.us.oracle.com> <1349340642.650.227.camel@zakaz.uk.xensource.com> <20121004112048.53767720@mantra.us.oracle.com> <1349428878.20946.18.camel@zakaz.uk.xensource.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 7/8]: PVH privcmd changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 5 Oct 2012 10:21:18 +0100 Ian Campbell wrote: > On Thu, 2012-10-04 at 19:20 +0100, Mukesh Rathor wrote: > > On Thu, 4 Oct 2012 09:50:42 +0100 > > Ian Campbell wrote: > > > > > > > > Won't that break because on the second call you will pass in the > > > freshly allocated pointer and overwrite the exiting (useful) one > > > with it? > > > > No, for xlate, I just check for NULL. I didn't think it was big > > deal to special case xlate in this case. We got so many if xlate > > cases already thru the code. It leaves the semantics easy to > > understand: NULL == avail. 1 == locked PV. PTR == Locked PVH. I'll > > add a comment this time :). > > The transition from NULL => Locked PVH still needs to be done > atomically and without clobbering any existing non-NULL value, > otherwise it doesn't actually protect against multiple mappings like > it is supposed to. Ok, changed it to, and tested it: static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma) { if (xen_feature(XENFEAT_auto_translated_physmap)) { int sz = sizeof(vma->vm_private_data); return (!__cmpxchg(&vma->vm_private_data, NULL, NULL, sz)); } return (xchg(&vma->vm_private_data, (void *)1) == NULL); } Then in pvh_privcmd_resv_pfns(): BUG_ON(vma->vm_private_data); vma->vm_private_data = pvhp; Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 21:23:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 21:23:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKFMH-0000Bo-Iy; Fri, 05 Oct 2012 21:22:57 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKFMG-0000Bj-Dx for Xen-devel@lists.xensource.com; Fri, 05 Oct 2012 21:22:56 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1349472169!4334998!1 X-Originating-IP: [141.146.126.227] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc5NjAzMQ==\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25873 invoked from network); 5 Oct 2012 21:22:50 -0000 Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2012 21:22:50 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q95LMhu2027437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Oct 2012 21:22:44 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q95LMghC017023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Oct 2012 21:22:43 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q95LMgOX013994; Fri, 5 Oct 2012 16:22:42 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 05 Oct 2012 14:22:42 -0700 Date: Fri, 5 Oct 2012 14:22:40 -0700 From: Mukesh Rathor To: Ian Campbell Message-ID: <20121005142240.340815be@mantra.us.oracle.com> In-Reply-To: <1349428878.20946.18.camel@zakaz.uk.xensource.com> References: <20120921122123.33489ce1@mantra.us.oracle.com> <1349270495.650.144.camel@zakaz.uk.xensource.com> <20121003153106.65237f07@mantra.us.oracle.com> <1349340642.650.227.camel@zakaz.uk.xensource.com> <20121004112048.53767720@mantra.us.oracle.com> <1349428878.20946.18.camel@zakaz.uk.xensource.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 7/8]: PVH privcmd changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Fri, 5 Oct 2012 10:21:18 +0100 Ian Campbell wrote: > On Thu, 2012-10-04 at 19:20 +0100, Mukesh Rathor wrote: > > On Thu, 4 Oct 2012 09:50:42 +0100 > > Ian Campbell wrote: > > > > > > > > Won't that break because on the second call you will pass in the > > > freshly allocated pointer and overwrite the exiting (useful) one > > > with it? > > > > No, for xlate, I just check for NULL. I didn't think it was big > > deal to special case xlate in this case. We got so many if xlate > > cases already thru the code. It leaves the semantics easy to > > understand: NULL == avail. 1 == locked PV. PTR == Locked PVH. I'll > > add a comment this time :). > > The transition from NULL => Locked PVH still needs to be done > atomically and without clobbering any existing non-NULL value, > otherwise it doesn't actually protect against multiple mappings like > it is supposed to. Ok, changed it to, and tested it: static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma) { if (xen_feature(XENFEAT_auto_translated_physmap)) { int sz = sizeof(vma->vm_private_data); return (!__cmpxchg(&vma->vm_private_data, NULL, NULL, sz)); } return (xchg(&vma->vm_private_data, (void *)1) == NULL); } Then in pvh_privcmd_resv_pfns(): BUG_ON(vma->vm_private_data); vma->vm_private_data = pvhp; Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 21:41:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 21:41:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKFdv-0000PB-Ca; Fri, 05 Oct 2012 21:41:11 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKFdu-0000P3-6t for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 21:41:10 +0000 Received: from [85.158.143.35:42314] by server-2.bemta-4.messagelabs.com id D8/22-06610-5F35F605; Fri, 05 Oct 2012 21:41:09 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1349473266!14750600!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9944 invoked from network); 5 Oct 2012 21:41:06 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 21:41:06 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14973228" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 21:41:06 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 22:41:06 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TKFdp-00046W-VH; Fri, 05 Oct 2012 21:41:05 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1TKFdp-0004fd-OH; Fri, 05 Oct 2012 22:41:05 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Fri, 5 Oct 2012 22:41:05 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 13926: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 13926 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13926/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail like 13924 test-amd64-amd64-xl-sedf 5 xen-boot fail like 13924 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail like 13924 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail like 13924 Tests which did not succeed, but are not blocking: test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: xen 10277c76aed4 baseline version: xen 032de7030d20 ------------------------------------------------------------ People who touched revisions under test: Anthony PERARD Christoph Egger Ian Campbell Ian Jackson Jan Beulich Keir Fraser Liu, Jinsong Matthew Fioravante Stefano Stabellini ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-amd64-amd64-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable + revision=10277c76aed4 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 10277c76aed4 + branch=xen-unstable + revision=10277c76aed4 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + . cri-common ++ umask 002 + select_xenbranch + case "$branch" in + tree=xen + xenbranch=xen-unstable + '[' xxen = xlinux ']' + linuxbranch=linux + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg ++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.xen-unstable ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git ++ : daily-cron.xen-unstable + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git + info_linux_tree xen-unstable + case $1 in + return 1 + case "$branch" in + cd /export/home/osstest/repos/xen-unstable.hg + hg push -r 10277c76aed4 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 7 changesets with 28 changes to 24 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 21:41:34 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 21:41:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKFdv-0000PB-Ca; Fri, 05 Oct 2012 21:41:11 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKFdu-0000P3-6t for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 21:41:10 +0000 Received: from [85.158.143.35:42314] by server-2.bemta-4.messagelabs.com id D8/22-06610-5F35F605; Fri, 05 Oct 2012 21:41:09 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1349473266!14750600!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9944 invoked from network); 5 Oct 2012 21:41:06 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2012 21:41:06 -0000 X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="14973228" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Oct 2012 21:41:06 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 5 Oct 2012 22:41:06 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TKFdp-00046W-VH; Fri, 05 Oct 2012 21:41:05 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1TKFdp-0004fd-OH; Fri, 05 Oct 2012 22:41:05 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Fri, 5 Oct 2012 22:41:05 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 13926: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 13926 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13926/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail like 13924 test-amd64-amd64-xl-sedf 5 xen-boot fail like 13924 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail like 13924 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail like 13924 Tests which did not succeed, but are not blocking: test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: xen 10277c76aed4 baseline version: xen 032de7030d20 ------------------------------------------------------------ People who touched revisions under test: Anthony PERARD Christoph Egger Ian Campbell Ian Jackson Jan Beulich Keir Fraser Liu, Jinsong Matthew Fioravante Stefano Stabellini ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-amd64-amd64-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable + revision=10277c76aed4 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 10277c76aed4 + branch=xen-unstable + revision=10277c76aed4 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + . cri-common ++ umask 002 + select_xenbranch + case "$branch" in + tree=xen + xenbranch=xen-unstable + '[' xxen = xlinux ']' + linuxbranch=linux + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg ++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.xen-unstable ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git ++ : daily-cron.xen-unstable + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git + info_linux_tree xen-unstable + case $1 in + return 1 + case "$branch" in + cd /export/home/osstest/repos/xen-unstable.hg + hg push -r 10277c76aed4 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 7 changesets with 28 changes to 24 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 22:21:24 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 22:21:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKGGV-0001DR-KS; Fri, 05 Oct 2012 22:21:03 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKGGT-0001DM-7O for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 22:21:01 +0000 Received: from [85.158.143.99:38453] by server-3.bemta-4.messagelabs.com id E8/BB-10986-C4D5F605; Fri, 05 Oct 2012 22:21:00 +0000 X-Env-Sender: linux@eikelenboom.it X-Msg-Ref: server-10.tower-216.messagelabs.com!1349475659!26616822!1 X-Originating-IP: [188.40.164.121] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17562 invoked from network); 5 Oct 2012 22:20:59 -0000 Received: from static.121.164.40.188.clients.your-server.de (HELO smtp.eikelenboom.it) (188.40.164.121) by server-10.tower-216.messagelabs.com with AES256-SHA encrypted SMTP; 5 Oct 2012 22:20:59 -0000 Received: from 100-66-ftth.onsneteindhoven.nl ([88.159.66.100]:55938 helo=[172.16.1.20]) by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TKGHd-0004Z4-Gh; Sat, 06 Oct 2012 00:22:13 +0200 Date: Sat, 6 Oct 2012 00:20:54 +0200 From: Sander Eikelenboom Organization: Eikelenboom IT services X-Priority: 3 (Normal) Message-ID: <729626082.20121006002054@eikelenboom.it> To: konrad In-Reply-To: References: MIME-Version: 1.0 Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Kernel 3.7.0-pre-rc1 kernel BUG at drivers/net/xen-netback/netback.c:405 RIP: e030:[] [] netbk_gop_frag_copy+0x379/0x380 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Friday, October 5, 2012, 9:26:31 PM, you wrote: > Sorry for top posting - on mobile. > I saw it too yesterday but only on a specific hardware - AMD FX8. What type of CPU do you have? Does xsave=off on Xen line help? Nope the xsave=off doesn't help > Sander Eikelenboom wrote: >>Hi Konrad, >> >>Just tested kernel 3.7.0-pre-rc1 but ran into a oops in netback on boot after starting some guests: >> >>[ 402.723915] ------------[ cut here ]------------ >>[ 402.734629] kernel BUG at drivers/net/xen-netback/netback.c:405! >>[ 402.744207] invalid opcode: 0000 [#5] PREEMPT SMP >>[ 402.752692] Modules linked in: >>[ 402.761307] CPU 1 >>[ 402.761358] Pid: 1329, comm: netback/1 Tainted: G D 3.6.0-pre-rc1-20121005a #1 MSI MS-7640/890FXA-GD70 (MS-7640) >>[ 402.778214] RIP: e030:[] [] netbk_gop_frag_copy+0x379/0x380 >>[ 402.786779] RSP: e02b:ffff880037955bb0 EFLAGS: 00010206 >>[ 402.795183] RAX: 000000000000486a RBX: ffff88003878c9c0 RCX: ffffea0000b3d400 >>[ 402.803536] RDX: ffff880037955cd0 RSI: ffff880037955d1c RDI: ffff88003878c9c0 >>[ 402.811867] RBP: ffff880037955c20 R08: 0000000000000000 R09: 00000000000042c2 >>[ 402.820008] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88002f58b100 >>[ 402.828022] R13: ffff880037955cd0 R14: 00000000000005a8 R15: ffff880037955d1c >>[ 402.835927] FS: 00007ffe2ca5b760(0000) GS:ffff88003f840000(0000) knlGS:0000000000000000 >>[ 402.843826] CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b >>[ 402.851539] CR2: 00007fff99c3b018 CR3: 00000000377c9000 CR4: 0000000000000660 >>[ 402.859251] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 >>[ 402.866816] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 >>[ 402.874188] Process netback/1 (pid: 1329, threadinfo ffff880037954000, task ffff8800398c20a0) >>[ 402.881621] Stack: >>[ 402.888811] ffff880037955d1c 0000000000000000 ffff88002f58b100 ffff88003878c9c0 >>[ 402.896102] ffff880000000000 ffff88002cf54000 0000000000000000 0000000000000000 >>[ 402.903320] ffff880037955c20 ffff88002f58b100 0000000000000001 0000000000000010 >>[ 402.910356] Call Trace: >>[ 402.917180] [] xen_netbk_rx_action+0x303/0x840 >>[ 402.924065] [] ? trace_hardirqs_on+0xd/0x10 >>[ 402.930776] [] xen_netbk_kthread+0xba/0xac0 >>[ 402.937352] [] ? try_to_wake_up+0x1b6/0x310 >>[ 402.943856] [] ? wake_up_bit+0x40/0x40 >>[ 402.950173] [] ? xen_netbk_tx_build_gops+0xa70/0xa70 >>[ 402.956370] [] kthread+0xd6/0xe0 >>[ 402.962524] [] kernel_thread_helper+0x4/0x10 >>[ 402.968668] [] ? retint_restore_args+0x13/0x13 >>[ 402.974735] [] ? gs_change+0x13/0x13 >>[ 402.980715] Code: b8 01 00 00 00 48 69 d2 b8 b3 00 00 48 8d 84 f8 60 01 00 00 48 3b 0c 10 0f 85 de fc ff ff e9 e2 fc ff ff 0f 0b eb fe 0f 0b eb fe <0f> 0b eb fe 0f 1f 00 55 48 89 e5 48 83 ec 10 48 89 1c 24 4c 89 >>[ 402.993584] RIP [] netbk_gop_frag_copy+0x379/0x380 >>[ 403.000075] RSP >>[ 403.006603] ---[ end trace 6eada309643a3fc7 ]--- >> >>-- >> >>Sander >> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 22:21:24 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 22:21:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKGGV-0001DR-KS; Fri, 05 Oct 2012 22:21:03 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKGGT-0001DM-7O for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 22:21:01 +0000 Received: from [85.158.143.99:38453] by server-3.bemta-4.messagelabs.com id E8/BB-10986-C4D5F605; Fri, 05 Oct 2012 22:21:00 +0000 X-Env-Sender: linux@eikelenboom.it X-Msg-Ref: server-10.tower-216.messagelabs.com!1349475659!26616822!1 X-Originating-IP: [188.40.164.121] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17562 invoked from network); 5 Oct 2012 22:20:59 -0000 Received: from static.121.164.40.188.clients.your-server.de (HELO smtp.eikelenboom.it) (188.40.164.121) by server-10.tower-216.messagelabs.com with AES256-SHA encrypted SMTP; 5 Oct 2012 22:20:59 -0000 Received: from 100-66-ftth.onsneteindhoven.nl ([88.159.66.100]:55938 helo=[172.16.1.20]) by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TKGHd-0004Z4-Gh; Sat, 06 Oct 2012 00:22:13 +0200 Date: Sat, 6 Oct 2012 00:20:54 +0200 From: Sander Eikelenboom Organization: Eikelenboom IT services X-Priority: 3 (Normal) Message-ID: <729626082.20121006002054@eikelenboom.it> To: konrad In-Reply-To: References: MIME-Version: 1.0 Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Kernel 3.7.0-pre-rc1 kernel BUG at drivers/net/xen-netback/netback.c:405 RIP: e030:[] [] netbk_gop_frag_copy+0x379/0x380 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Friday, October 5, 2012, 9:26:31 PM, you wrote: > Sorry for top posting - on mobile. > I saw it too yesterday but only on a specific hardware - AMD FX8. What type of CPU do you have? Does xsave=off on Xen line help? Nope the xsave=off doesn't help > Sander Eikelenboom wrote: >>Hi Konrad, >> >>Just tested kernel 3.7.0-pre-rc1 but ran into a oops in netback on boot after starting some guests: >> >>[ 402.723915] ------------[ cut here ]------------ >>[ 402.734629] kernel BUG at drivers/net/xen-netback/netback.c:405! >>[ 402.744207] invalid opcode: 0000 [#5] PREEMPT SMP >>[ 402.752692] Modules linked in: >>[ 402.761307] CPU 1 >>[ 402.761358] Pid: 1329, comm: netback/1 Tainted: G D 3.6.0-pre-rc1-20121005a #1 MSI MS-7640/890FXA-GD70 (MS-7640) >>[ 402.778214] RIP: e030:[] [] netbk_gop_frag_copy+0x379/0x380 >>[ 402.786779] RSP: e02b:ffff880037955bb0 EFLAGS: 00010206 >>[ 402.795183] RAX: 000000000000486a RBX: ffff88003878c9c0 RCX: ffffea0000b3d400 >>[ 402.803536] RDX: ffff880037955cd0 RSI: ffff880037955d1c RDI: ffff88003878c9c0 >>[ 402.811867] RBP: ffff880037955c20 R08: 0000000000000000 R09: 00000000000042c2 >>[ 402.820008] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88002f58b100 >>[ 402.828022] R13: ffff880037955cd0 R14: 00000000000005a8 R15: ffff880037955d1c >>[ 402.835927] FS: 00007ffe2ca5b760(0000) GS:ffff88003f840000(0000) knlGS:0000000000000000 >>[ 402.843826] CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b >>[ 402.851539] CR2: 00007fff99c3b018 CR3: 00000000377c9000 CR4: 0000000000000660 >>[ 402.859251] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 >>[ 402.866816] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 >>[ 402.874188] Process netback/1 (pid: 1329, threadinfo ffff880037954000, task ffff8800398c20a0) >>[ 402.881621] Stack: >>[ 402.888811] ffff880037955d1c 0000000000000000 ffff88002f58b100 ffff88003878c9c0 >>[ 402.896102] ffff880000000000 ffff88002cf54000 0000000000000000 0000000000000000 >>[ 402.903320] ffff880037955c20 ffff88002f58b100 0000000000000001 0000000000000010 >>[ 402.910356] Call Trace: >>[ 402.917180] [] xen_netbk_rx_action+0x303/0x840 >>[ 402.924065] [] ? trace_hardirqs_on+0xd/0x10 >>[ 402.930776] [] xen_netbk_kthread+0xba/0xac0 >>[ 402.937352] [] ? try_to_wake_up+0x1b6/0x310 >>[ 402.943856] [] ? wake_up_bit+0x40/0x40 >>[ 402.950173] [] ? xen_netbk_tx_build_gops+0xa70/0xa70 >>[ 402.956370] [] kthread+0xd6/0xe0 >>[ 402.962524] [] kernel_thread_helper+0x4/0x10 >>[ 402.968668] [] ? retint_restore_args+0x13/0x13 >>[ 402.974735] [] ? gs_change+0x13/0x13 >>[ 402.980715] Code: b8 01 00 00 00 48 69 d2 b8 b3 00 00 48 8d 84 f8 60 01 00 00 48 3b 0c 10 0f 85 de fc ff ff e9 e2 fc ff ff 0f 0b eb fe 0f 0b eb fe <0f> 0b eb fe 0f 1f 00 55 48 89 e5 48 83 ec 10 48 89 1c 24 4c 89 >>[ 402.993584] RIP [] netbk_gop_frag_copy+0x379/0x380 >>[ 403.000075] RSP >>[ 403.006603] ---[ end trace 6eada309643a3fc7 ]--- >> >>-- >> >>Sander >> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 23:57:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 23:57:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKHlc-0001bA-37; Fri, 05 Oct 2012 23:57:16 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with smtp (Exim 4.72) (envelope-from ) id 1TKHla-0001b2-TX for xen-devel@lists.xen.org; Fri, 05 Oct 2012 23:57:15 +0000 X-Env-Sender: greg@wind.enjellic.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1349481427!6657058!1 X-Originating-IP: [76.10.64.91] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5568 invoked from network); 5 Oct 2012 23:57:08 -0000 Received: from wind.enjellic.com (HELO wind.enjellic.com) (76.10.64.91) by server-15.tower-27.messagelabs.com with SMTP; 5 Oct 2012 23:57:08 -0000 Received: from wind.enjellic.com (localhost [127.0.0.1]) by wind.enjellic.com (8.14.3/8.14.3) with ESMTP id q95Nv6cE004902; Fri, 5 Oct 2012 18:57:06 -0500 Received: (from greg@localhost) by wind.enjellic.com (8.14.3/8.14.3/Submit) id q95Nv6jK004901; Fri, 5 Oct 2012 18:57:06 -0500 Date: Fri, 5 Oct 2012 18:57:06 -0500 From: "Dr. Greg Wettstein" Message-Id: <201210052357.q95Nv6jK004901@wind.enjellic.com> In-Reply-To: Moritz =?iso-8859-1?q?M=FChlenhoff?= "[Xen-devel] Compilation fixes for blktap kernel patch" (Oct 5, 10:31am) X-Mailer: Mail User's Shell (7.2.6-ESD1.0 03/31/2012) To: Moritz =?iso-8859-1?q?M=FChlenhoff?= , "xen-devel@lists.xen.org" X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3 (wind.enjellic.com [0.0.0.0]); Fri, 05 Oct 2012 18:57:06 -0500 (CDT) Subject: Re: [Xen-devel] Compilation fixes for blktap kernel patch X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: greg@enjellic.com List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Oct 5, 10:31am, Moritz =?iso-8859-1?q?M=FChlenhoff?= wrote: } Subject: [Xen-devel] Compilation fixes for blktap kernel patch > Hi, Hi Moritz, hope your week went well. > I hope this is the correct mailing list for the blktap patches available at > ftp://ftp.enjellic.com/pub/xen/ ? I'm not sure any of the core Xen developers wants to lay claim to blktap2 in general and these patches in particular.... :-) I try to keep these patches updated since blktap2 is useful in our implementations and I wanted to save everyone else what seemed like endless hours of googling and searching trying to get these facilities working the way they are supposed to. I'm glad you have found them useful. > When integrating the patch into Linux 3.2.30 I noticed two compile errors=20 > related to a missing include of module.h: > > /var/build/temp/tmp.TujmUayDmG/3.1-0-0/linux/linux-3.2.30/drivers/block/blk= > tap/ring.c:536:=20 > error: 'THIS_MODULE' undeclared here (not in a function) > > I'm attaching patches against the=20 > ftp://ftp.enjellic.com/pub/xen/blktap2-3.2.patch patch Thanks for bringing this to my attention. I thought I had that issue corrected but the 3.2 patches must have escaped those fixes. In any event I made the needed changes so the patches on the above FTP site should now drop in without any problems. > Cheers, > Moritz > =2D-=20 > Moritz M=FChlenhoff > Open Source Software Engineer Thanks again for the heads up on this. Good luck with your Xen efforts and have a nice weekend. Greg }-- End of excerpt from Moritz =?iso-8859-1?q?M=FChlenhoff?= As always, Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC. 4206 N. 19th Ave. Specializing in information infra-structure Fargo, ND 58102 development. PH: 701-281-1686 FAX: 701-281-3949 EMAIL: greg@enjellic.com ------------------------------------------------------------------------------ "Simplicity is prerequisite for reliability." -- Edsger W. Dijkstra _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Fri Oct 05 23:57:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Oct 2012 23:57:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKHlc-0001bA-37; Fri, 05 Oct 2012 23:57:16 +0000 Received: from mail27.messagelabs.com ([193.109.254.147]) by lists.xen.org with smtp (Exim 4.72) (envelope-from ) id 1TKHla-0001b2-TX for xen-devel@lists.xen.org; Fri, 05 Oct 2012 23:57:15 +0000 X-Env-Sender: greg@wind.enjellic.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1349481427!6657058!1 X-Originating-IP: [76.10.64.91] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5568 invoked from network); 5 Oct 2012 23:57:08 -0000 Received: from wind.enjellic.com (HELO wind.enjellic.com) (76.10.64.91) by server-15.tower-27.messagelabs.com with SMTP; 5 Oct 2012 23:57:08 -0000 Received: from wind.enjellic.com (localhost [127.0.0.1]) by wind.enjellic.com (8.14.3/8.14.3) with ESMTP id q95Nv6cE004902; Fri, 5 Oct 2012 18:57:06 -0500 Received: (from greg@localhost) by wind.enjellic.com (8.14.3/8.14.3/Submit) id q95Nv6jK004901; Fri, 5 Oct 2012 18:57:06 -0500 Date: Fri, 5 Oct 2012 18:57:06 -0500 From: "Dr. Greg Wettstein" Message-Id: <201210052357.q95Nv6jK004901@wind.enjellic.com> In-Reply-To: Moritz =?iso-8859-1?q?M=FChlenhoff?= "[Xen-devel] Compilation fixes for blktap kernel patch" (Oct 5, 10:31am) X-Mailer: Mail User's Shell (7.2.6-ESD1.0 03/31/2012) To: Moritz =?iso-8859-1?q?M=FChlenhoff?= , "xen-devel@lists.xen.org" X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3 (wind.enjellic.com [0.0.0.0]); Fri, 05 Oct 2012 18:57:06 -0500 (CDT) Subject: Re: [Xen-devel] Compilation fixes for blktap kernel patch X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: greg@enjellic.com List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Oct 5, 10:31am, Moritz =?iso-8859-1?q?M=FChlenhoff?= wrote: } Subject: [Xen-devel] Compilation fixes for blktap kernel patch > Hi, Hi Moritz, hope your week went well. > I hope this is the correct mailing list for the blktap patches available at > ftp://ftp.enjellic.com/pub/xen/ ? I'm not sure any of the core Xen developers wants to lay claim to blktap2 in general and these patches in particular.... :-) I try to keep these patches updated since blktap2 is useful in our implementations and I wanted to save everyone else what seemed like endless hours of googling and searching trying to get these facilities working the way they are supposed to. I'm glad you have found them useful. > When integrating the patch into Linux 3.2.30 I noticed two compile errors=20 > related to a missing include of module.h: > > /var/build/temp/tmp.TujmUayDmG/3.1-0-0/linux/linux-3.2.30/drivers/block/blk= > tap/ring.c:536:=20 > error: 'THIS_MODULE' undeclared here (not in a function) > > I'm attaching patches against the=20 > ftp://ftp.enjellic.com/pub/xen/blktap2-3.2.patch patch Thanks for bringing this to my attention. I thought I had that issue corrected but the 3.2 patches must have escaped those fixes. In any event I made the needed changes so the patches on the above FTP site should now drop in without any problems. > Cheers, > Moritz > =2D-=20 > Moritz M=FChlenhoff > Open Source Software Engineer Thanks again for the heads up on this. Good luck with your Xen efforts and have a nice weekend. Greg }-- End of excerpt from Moritz =?iso-8859-1?q?M=FChlenhoff?= As always, Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC. 4206 N. 19th Ave. Specializing in information infra-structure Fargo, ND 58102 development. PH: 701-281-1686 FAX: 701-281-3949 EMAIL: greg@enjellic.com ------------------------------------------------------------------------------ "Simplicity is prerequisite for reliability." -- Edsger W. Dijkstra _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat Oct 06 01:27:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 06 Oct 2012 01:27:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKJAk-0006Bt-8h; Sat, 06 Oct 2012 01:27:18 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKJAi-0006Bo-Kc for xen-devel@lists.xensource.com; Sat, 06 Oct 2012 01:27:16 +0000 Received: from [85.158.138.51:12478] by server-13.bemta-3.messagelabs.com id DD/46-28885-3F88F605; Sat, 06 Oct 2012 01:27:15 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1349486834!33252983!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12708 invoked from network); 6 Oct 2012 01:27:15 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 6 Oct 2012 01:27:15 -0000 X-IronPort-AV: E=Sophos;i="4.80,543,1344211200"; d="scan'208";a="14975763" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 06 Oct 2012 01:26:36 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Sat, 6 Oct 2012 02:26:36 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TKJA4-0005d6-0v; Sat, 06 Oct 2012 01:26:36 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1TKJA3-0000R7-Gm; Sat, 06 Oct 2012 02:26:35 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Sat, 6 Oct 2012 02:26:35 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.2-testing test] 13927: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 13927 xen-4.2-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13927/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-i386-i386-xl-qemuu-winxpsp3 9 guest-localmigrate fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: xen 27db446078b5 baseline version: xen a69c8e5c4afc ------------------------------------------------------------ People who touched revisions under test: Ben Guthro Christoph Egger Jan Beulich Keir Fraser Tim Deegan ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-4.2-testing + revision=27db446078b5 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.2-testing 27db446078b5 + branch=xen-4.2-testing + revision=27db446078b5 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + . cri-common ++ umask 002 + select_xenbranch + case "$branch" in + tree=xen + xenbranch=xen-4.2-testing + '[' xxen = xlinux ']' + linuxbranch=linux + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : http://xenbits.xen.org/hg/staging/xen-4.2-testing.hg ++ : git://xenbits.xen.org/staging/qemu-xen-4.2-testing.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.xen-4.2-testing ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-4.2-testing.git ++ : daily-cron.xen-4.2-testing + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.2-testing.git + info_linux_tree xen-4.2-testing + case $1 in + return 1 + case "$branch" in + cd /export/home/osstest/repos/xen-4.2-testing.hg + hg push -r 27db446078b5 ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 1 changesets with 1 changes to 1 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat Oct 06 01:27:50 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 06 Oct 2012 01:27:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKJAk-0006Bt-8h; Sat, 06 Oct 2012 01:27:18 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKJAi-0006Bo-Kc for xen-devel@lists.xensource.com; Sat, 06 Oct 2012 01:27:16 +0000 Received: from [85.158.138.51:12478] by server-13.bemta-3.messagelabs.com id DD/46-28885-3F88F605; Sat, 06 Oct 2012 01:27:15 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1349486834!33252983!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMxNTE=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12708 invoked from network); 6 Oct 2012 01:27:15 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 6 Oct 2012 01:27:15 -0000 X-IronPort-AV: E=Sophos;i="4.80,543,1344211200"; d="scan'208";a="14975763" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 06 Oct 2012 01:26:36 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Sat, 6 Oct 2012 02:26:36 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TKJA4-0005d6-0v; Sat, 06 Oct 2012 01:26:36 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1TKJA3-0000R7-Gm; Sat, 06 Oct 2012 02:26:35 +0100 To: xen-devel@lists.xensource.com Message-ID: From: xen.org Date: Sat, 6 Oct 2012 02:26:35 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-4.2-testing test] 13927: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 13927 xen-4.2-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13927/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-i386-i386-xl-qemuu-winxpsp3 9 guest-localmigrate fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail never pass test-i386-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-i386-i386-xl-win 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: xen 27db446078b5 baseline version: xen a69c8e5c4afc ------------------------------------------------------------ People who touched revisions under test: Ben Guthro Christoph Egger Jan Beulich Keir Fraser Tim Deegan ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-i386-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-i386-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-i386-i386-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-i386-i386-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-4.2-testing + revision=27db446078b5 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.2-testing 27db446078b5 + branch=xen-4.2-testing + revision=27db446078b5 + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + . cri-common ++ umask 002 + select_xenbranch + case "$branch" in + tree=xen + xenbranch=xen-4.2-testing + '[' xxen = xlinux ']' + linuxbranch=linux + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : http://xenbits.xen.org/hg/staging/xen-4.2-testing.hg ++ : git://xenbits.xen.org/staging/qemu-xen-4.2-testing.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.xen-4.2-testing ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-4.2-testing.git ++ : daily-cron.xen-4.2-testing + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.2-testing.git + info_linux_tree xen-4.2-testing + case $1 in + return 1 + case "$branch" in + cd /export/home/osstest/repos/xen-4.2-testing.hg + hg push -r 27db446078b5 ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 1 changesets with 1 changes to 1 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat Oct 06 02:01:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 06 Oct 2012 02:01:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKJgr-0006nD-Dq; Sat, 06 Oct 2012 02:00:29 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKJgp-0006fE-AE for Xen-devel@lists.xensource.com; Sat, 06 Oct 2012 02:00:27 +0000 Received: from [85.158.138.51:9119] by server-7.bemta-3.messagelabs.com id B9/1E-15765-AB09F605; Sat, 06 Oct 2012 02:00:26 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-5.tower-174.messagelabs.com!1349488823!33379391!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzg3MjI1\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29302 invoked from network); 6 Oct 2012 02:00:24 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Oct 2012 02:00:24 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q9620EbZ015142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 6 Oct 2012 02:00:15 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q9620Drb029661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Oct 2012 02:00:14 GMT Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q9620DK9011447; Fri, 5 Oct 2012 21:00:13 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 05 Oct 2012 19:00:12 -0700 Date: Fri, 5 Oct 2012 19:00:11 -0700 From: Mukesh Rathor To: Ian Campbell Message-ID: <20121005190011.2653bcfa@mantra.us.oracle.com> In-Reply-To: <1349339279.650.214.camel@zakaz.uk.xensource.com> References: <20120921121556.1a0ea8af@mantra.us.oracle.com> <1349278963.650.164.camel@zakaz.uk.xensource.com> <20121003152925.5af3a658@mantra.us.oracle.com> <1349339279.650.214.camel@zakaz.uk.xensource.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/kT_PskLq9cVTOBVGRjrj25F" X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --MP_/kT_PskLq9cVTOBVGRjrj25F Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline On Thu, 4 Oct 2012 09:27:59 +0100 Ian Campbell wrote: > On Wed, 2012-10-03 at 23:29 +0100, Mukesh Rathor wrote: > > On Wed, 3 Oct 2012 16:42:43 +0100 > > Ian Campbell wrote: > > > While implementing the ARM version of this interface it occurred to me > that the num_pgs and next_todo fields here are not really needed > across the arch interface e.g. you already get pi_num_pgs from the nr > argument to xen_remap_domain_mfn_range and pi_next_todo is really > state which fits in struct pvh_remap_data. That would mean that > remap_foo could take a struct page * directly and I think you would > save an allocation. Ok, take a look at the attached and inlined diffs. I redid it, passing struct page to the api, and getting rid of the pi_* struct completely. thanks Mukesh diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c index ef63895..6cbf59a 100644 --- a/drivers/xen/privcmd.c +++ b/drivers/xen/privcmd.c @@ -33,6 +33,7 @@ #include #include #include +#include #include "privcmd.h" @@ -178,7 +179,7 @@ static int mmap_mfn_range(void *data, void *state) msg->va & PAGE_MASK, msg->mfn, msg->npages, vma->vm_page_prot, - st->domain); + st->domain, NULL); if (rc < 0) return rc; @@ -199,6 +200,10 @@ static long privcmd_ioctl_mmap(void __user *udata) if (!xen_initial_domain()) return -EPERM; + /* We only support privcmd_ioctl_mmap_batch for auto translated. */ + if (xen_feature(XENFEAT_auto_translated_physmap)) + return -ENOSYS; + if (copy_from_user(&mmapcmd, udata, sizeof(mmapcmd))) return -EFAULT; @@ -246,6 +251,7 @@ struct mmap_batch_state { domid_t domain; unsigned long va; struct vm_area_struct *vma; + int index; /* A tristate: * 0 for no errors * 1 if at least one error has happened (and no @@ -260,14 +266,20 @@ struct mmap_batch_state { xen_pfn_t __user *user_mfn; }; +/* PVH dom0 fyi: if domU being created is PV, then mfn is mfn(addr on bus). If + * it's PVH then mfn is pfn (input to HAP). */ static int mmap_batch_fn(void *data, void *state) { xen_pfn_t *mfnp = data; struct mmap_batch_state *st = state; + struct vm_area_struct *vma = st->vma; + struct page **pages = vma ? vma->vm_private_data : NULL; + struct page *cur_page = pages[st->index++]; int ret; ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1, - st->vma->vm_page_prot, st->domain); + st->vma->vm_page_prot, st->domain, + &cur_page); /* Store error code for second pass. */ *(st->err++) = ret; @@ -303,6 +315,32 @@ static int mmap_return_errors_v1(void *data, void *state) return __put_user(*mfnp, st->user_mfn++); } +/* Allocate pfns that are then mapped with gmfns from foreign domid. Update + * the vma with the page info to use later. + * Returns: 0 if success, otherwise -errno + */ +static int pvh_privcmd_resv_pfns(struct vm_area_struct *vma, int numpgs) +{ + int rc; + struct page **pages; + + pages = kcalloc(numpgs, sizeof(pages[0]), GFP_KERNEL); + if (pages == NULL) + return -ENOMEM; + + rc = alloc_xenballooned_pages(numpgs, pages, 0); + if (rc != 0) { + pr_warn("%s Could not alloc %d pfns rc:%d\n", __func__, + numpgs, rc); + kfree(pages); + return -ENOMEM; + } + BUG_ON(vma->vm_private_data); + vma->vm_private_data = pages; + + return 0; +} + static struct vm_operations_struct privcmd_vm_ops; static long privcmd_ioctl_mmap_batch(void __user *udata, int version) @@ -370,10 +408,17 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version) up_write(&mm->mmap_sem); goto out; } + if (xen_feature(XENFEAT_auto_translated_physmap)) { + if ((ret = pvh_privcmd_resv_pfns(vma, m.num)) < 0) { + up_write(&mm->mmap_sem); + goto out; + } + } state.domain = m.dom; state.vma = vma; state.va = m.addr; + state.index = 0; state.global_error = 0; state.err = err_array; @@ -438,6 +483,20 @@ static long privcmd_ioctl(struct file *file, return ret; } +static void privcmd_close(struct vm_area_struct *vma) +{ + struct page **pages = vma ? vma->vm_private_data : NULL; + int numpgs = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT; + + if (!pages || !numpgs || !xen_feature(XENFEAT_auto_translated_physmap)) + return; + + xen_unmap_domain_mfn_range(vma); + while (numpgs--) + free_xenballooned_pages(1, &pages[numpgs]); + kfree(pages); +} + static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf) { printk(KERN_DEBUG "privcmd_fault: vma=%p %lx-%lx, pgoff=%lx, uv=%p\n", @@ -448,6 +507,7 @@ static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf) } static struct vm_operations_struct privcmd_vm_ops = { + .close = privcmd_close, .fault = privcmd_fault }; @@ -464,6 +524,10 @@ static int privcmd_mmap(struct file *file, struct vm_area_struct *vma) static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma) { + if (xen_feature(XENFEAT_auto_translated_physmap)) { + int sz = sizeof(vma->vm_private_data); + return (!__cmpxchg(&vma->vm_private_data, NULL, NULL, sz)); + } return (xchg(&vma->vm_private_data, (void *)1) == NULL); } =============================================================================================== diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c index 5a16824..d5e53ad 100644 --- a/arch/x86/xen/mmu.c +++ b/arch/x86/xen/mmu.c @@ -73,6 +73,7 @@ #include #include #include +#include #include "multicalls.h" #include "mmu.h" @@ -331,6 +332,20 @@ static void xen_set_pte(pte_t *ptep, pte_t pteval) __xen_set_pte(ptep, pteval); } +void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn, + int nr_mfns, int add_mapping) +{ + struct physdev_map_iomem iomem; + + iomem.first_gfn = pfn; + iomem.first_mfn = mfn; + iomem.nr_mfns = nr_mfns; + iomem.add_mapping = add_mapping; + + if (HYPERVISOR_physdev_op(PHYSDEVOP_pvh_map_iomem, &iomem)) + BUG(); +} + static void xen_set_pte_at(struct mm_struct *mm, unsigned long addr, pte_t *ptep, pte_t pteval) { @@ -1220,6 +1235,8 @@ static void __init xen_pagetable_init(void) #endif paging_init(); xen_setup_shared_info(); + if (xen_feature(XENFEAT_auto_translated_physmap)) + return; #ifdef CONFIG_X86_64 if (!xen_feature(XENFEAT_auto_translated_physmap)) { unsigned long new_mfn_list; @@ -1527,6 +1544,10 @@ static void __init xen_set_pte_init(pte_t *ptep, pte_t pte) static void pin_pagetable_pfn(unsigned cmd, unsigned long pfn) { struct mmuext_op op; + + if (xen_feature(XENFEAT_writable_page_tables)) + return; + op.cmd = cmd; op.arg1.mfn = pfn_to_mfn(pfn); if (HYPERVISOR_mmuext_op(&op, 1, NULL, DOMID_SELF)) @@ -1724,6 +1745,10 @@ static void set_page_prot(void *addr, pgprot_t prot) unsigned long pfn = __pa(addr) >> PAGE_SHIFT; pte_t pte = pfn_pte(pfn, prot); + /* recall for PVH, page tables are native. */ + if (xen_feature(XENFEAT_auto_translated_physmap)) + return; + if (HYPERVISOR_update_va_mapping((unsigned long)addr, pte, 0)) BUG(); } @@ -1801,6 +1826,9 @@ static void convert_pfn_mfn(void *v) pte_t *pte = v; int i; + if (xen_feature(XENFEAT_auto_translated_physmap)) + return; + /* All levels are converted the same way, so just treat them as ptes. */ for (i = 0; i < PTRS_PER_PTE; i++) @@ -1820,6 +1848,7 @@ static void __init check_pt_base(unsigned long *pt_base, unsigned long *pt_end, (*pt_end)--; } } + /* * Set up the initial kernel pagetable. * @@ -1830,6 +1859,7 @@ static void __init check_pt_base(unsigned long *pt_base, unsigned long *pt_end, * but that's enough to get __va working. We need to fill in the rest * of the physical mapping once some sort of allocator has been set * up. + * NOTE: for PVH, the page tables are native. */ void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn) { @@ -1907,10 +1937,13 @@ void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn) * structure to attach it to, so make sure we just set kernel * pgd. */ - xen_mc_batch(); - __xen_write_cr3(true, __pa(init_level4_pgt)); - xen_mc_issue(PARAVIRT_LAZY_CPU); - + if (xen_feature(XENFEAT_writable_page_tables)) { + native_write_cr3(__pa(init_level4_pgt)); + } else { + xen_mc_batch(); + __xen_write_cr3(true, __pa(init_level4_pgt)); + xen_mc_issue(PARAVIRT_LAZY_CPU); + } /* We can't that easily rip out L3 and L2, as the Xen pagetables are * set out this way: [L4], [L1], [L2], [L3], [L1], [L1] ... for * the initial domain. For guests using the toolstack, they are in: @@ -2177,8 +2210,19 @@ static const struct pv_mmu_ops xen_mmu_ops __initconst = { void __init xen_init_mmu_ops(void) { - x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve; x86_init.paging.pagetable_init = xen_pagetable_init; + + if (xen_feature(XENFEAT_auto_translated_physmap)) { + pv_mmu_ops.flush_tlb_others = xen_flush_tlb_others; + + /* set_pte* for PCI devices to map iomem. */ + if (xen_initial_domain()) { + pv_mmu_ops.set_pte = native_set_pte; + pv_mmu_ops.set_pte_at = native_set_pte_at; + } + return; + } + x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve; pv_mmu_ops = xen_mmu_ops; memset(dummy_mapping, 0xff, PAGE_SIZE); @@ -2414,6 +2458,94 @@ void __init xen_hvm_init_mmu_ops(void) } #endif +/* Map foreign gmfn, fgmfn, to local pfn, lpfn. This for the user space + * creating new guest on PVH dom0 and needs to map domU pages. + */ +static int pvh_add_to_xen_p2m(unsigned long lpfn, unsigned long fgmfn, + unsigned int domid) +{ + int rc; + struct xen_add_to_physmap xatp = { .u.foreign_domid = domid }; + + xatp.gpfn = lpfn; + xatp.idx = fgmfn; + xatp.domid = DOMID_SELF; + xatp.space = XENMAPSPACE_gmfn_foreign; + rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp); + if (rc) + pr_warn("d0: Failed to map pfn to mfn rc:%d pfn:%lx mfn:%lx\n", + rc, lpfn, fgmfn); + return rc; +} + +int pvh_rem_xen_p2m(unsigned long spfn, int count) +{ + struct xen_remove_from_physmap xrp; + int i, rc; + + for (i=0; i < count; i++) { + xrp.domid = DOMID_SELF; + xrp.gpfn = spfn+i; + rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, &xrp); + if (rc) { + pr_warn("Failed to unmap pfn:%lx rc:%d done:%d\n", + spfn+i, rc, i); + return 1; + } + } + return 0; +} +EXPORT_SYMBOL_GPL(pvh_rem_xen_p2m); + +struct pvh_remap_data { + unsigned long fgmfn; /* foreign domain's gmfn */ + pgprot_t prot; + domid_t domid; + int index; + struct page **pages; +}; + +static int pvh_map_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr, + void *data) +{ + int rc; + struct pvh_remap_data *remap = data; + unsigned long pfn = page_to_pfn(remap->pages[remap->index++]); + pte_t pteval = pte_mkspecial(pfn_pte(pfn, remap->prot)); + + if ((rc=pvh_add_to_xen_p2m(pfn, remap->fgmfn, remap->domid))) + return rc; + native_set_pte(ptep, pteval); + + return 0; +} + +/* The only caller at moment passes one gmfn at a time. + * PVH TBD/FIXME: expand this in future to honor batch requests. + */ +static int pvh_remap_gmfn_range(struct vm_area_struct *vma, + unsigned long addr, unsigned long mfn, int nr, + pgprot_t prot, unsigned domid, + struct page **pages) +{ + int err; + struct pvh_remap_data pvhdata; + + if (nr > 1) + return -EINVAL; + + pvhdata.fgmfn = mfn; + pvhdata.prot = prot; + pvhdata.domid = domid; + pvhdata.index = 0; + pvhdata.pages = pages; + err = apply_to_page_range(vma->vm_mm, addr, nr << PAGE_SHIFT, + pvh_map_pte_fn, &pvhdata); + flush_tlb_all(); + /* flush_tlb_page(vma, addr); */ + return err; +} + #define REMAP_BATCH_SIZE 16 struct remap_data { @@ -2438,7 +2570,9 @@ static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token, int xen_remap_domain_mfn_range(struct vm_area_struct *vma, unsigned long addr, unsigned long mfn, int nr, - pgprot_t prot, unsigned domid) + pgprot_t prot, unsigned domid, + struct page **pages) + { struct remap_data rmd; struct mmu_update mmu_update[REMAP_BATCH_SIZE]; @@ -2446,14 +2580,17 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma, unsigned long range; int err = 0; - if (xen_feature(XENFEAT_auto_translated_physmap)) - return -EINVAL; - prot = __pgprot(pgprot_val(prot) | _PAGE_IOMAP); BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_RESERVED | VM_IO)) == (VM_PFNMAP | VM_RESERVED | VM_IO))); + if (xen_feature(XENFEAT_auto_translated_physmap)) { + /* We need to update the local page tables and the xen HAP */ + return pvh_remap_gmfn_range(vma, addr, mfn, nr, prot, domid, + pages); + } + rmd.mfn = mfn; rmd.prot = prot; @@ -2483,3 +2620,25 @@ out: return err; } EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range); + +/* Returns: 0 success */ +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma) +{ + int numpgs = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT; + struct page **pages = vma ? vma->vm_private_data : NULL; + + if (!pages || !xen_feature(XENFEAT_auto_translated_physmap)) + return 0; + + while (numpgs--) { + + /* the mmu has already cleaned up the process mmu resources at + * this point (lookup_address will return NULL). */ + unsigned long pfn = page_to_pfn(pages[numpgs]); + + pvh_rem_xen_p2m(pfn, 1); + } + flush_tlb_all(); + return 0; +} +EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range); --MP_/kT_PskLq9cVTOBVGRjrj25F Content-Type: text/x-patch Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=priv.diff diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c index ef63895..6cbf59a 100644 --- a/drivers/xen/privcmd.c +++ b/drivers/xen/privcmd.c @@ -33,6 +33,7 @@ #include #include #include +#include #include "privcmd.h" @@ -178,7 +179,7 @@ static int mmap_mfn_range(void *data, void *state) msg->va & PAGE_MASK, msg->mfn, msg->npages, vma->vm_page_prot, - st->domain); + st->domain, NULL); if (rc < 0) return rc; @@ -199,6 +200,10 @@ static long privcmd_ioctl_mmap(void __user *udata) if (!xen_initial_domain()) return -EPERM; + /* We only support privcmd_ioctl_mmap_batch for auto translated. */ + if (xen_feature(XENFEAT_auto_translated_physmap)) + return -ENOSYS; + if (copy_from_user(&mmapcmd, udata, sizeof(mmapcmd))) return -EFAULT; @@ -246,6 +251,7 @@ struct mmap_batch_state { domid_t domain; unsigned long va; struct vm_area_struct *vma; + int index; /* A tristate: * 0 for no errors * 1 if at least one error has happened (and no @@ -260,14 +266,20 @@ struct mmap_batch_state { xen_pfn_t __user *user_mfn; }; +/* PVH dom0 fyi: if domU being created is PV, then mfn is mfn(addr on bus). If + * it's PVH then mfn is pfn (input to HAP). */ static int mmap_batch_fn(void *data, void *state) { xen_pfn_t *mfnp = data; struct mmap_batch_state *st = state; + struct vm_area_struct *vma = st->vma; + struct page **pages = vma ? vma->vm_private_data : NULL; + struct page *cur_page = pages[st->index++]; int ret; ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1, - st->vma->vm_page_prot, st->domain); + st->vma->vm_page_prot, st->domain, + &cur_page); /* Store error code for second pass. */ *(st->err++) = ret; @@ -303,6 +315,32 @@ static int mmap_return_errors_v1(void *data, void *state) return __put_user(*mfnp, st->user_mfn++); } +/* Allocate pfns that are then mapped with gmfns from foreign domid. Update + * the vma with the page info to use later. + * Returns: 0 if success, otherwise -errno + */ +static int pvh_privcmd_resv_pfns(struct vm_area_struct *vma, int numpgs) +{ + int rc; + struct page **pages; + + pages = kcalloc(numpgs, sizeof(pages[0]), GFP_KERNEL); + if (pages == NULL) + return -ENOMEM; + + rc = alloc_xenballooned_pages(numpgs, pages, 0); + if (rc != 0) { + pr_warn("%s Could not alloc %d pfns rc:%d\n", __func__, + numpgs, rc); + kfree(pages); + return -ENOMEM; + } + BUG_ON(vma->vm_private_data); + vma->vm_private_data = pages; + + return 0; +} + static struct vm_operations_struct privcmd_vm_ops; static long privcmd_ioctl_mmap_batch(void __user *udata, int version) @@ -370,10 +408,17 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version) up_write(&mm->mmap_sem); goto out; } + if (xen_feature(XENFEAT_auto_translated_physmap)) { + if ((ret = pvh_privcmd_resv_pfns(vma, m.num)) < 0) { + up_write(&mm->mmap_sem); + goto out; + } + } state.domain = m.dom; state.vma = vma; state.va = m.addr; + state.index = 0; state.global_error = 0; state.err = err_array; @@ -438,6 +483,20 @@ static long privcmd_ioctl(struct file *file, return ret; } +static void privcmd_close(struct vm_area_struct *vma) +{ + struct page **pages = vma ? vma->vm_private_data : NULL; + int numpgs = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT; + + if (!pages || !numpgs || !xen_feature(XENFEAT_auto_translated_physmap)) + return; + + xen_unmap_domain_mfn_range(vma); + while (numpgs--) + free_xenballooned_pages(1, &pages[numpgs]); + kfree(pages); +} + static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf) { printk(KERN_DEBUG "privcmd_fault: vma=%p %lx-%lx, pgoff=%lx, uv=%p\n", @@ -448,6 +507,7 @@ static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf) } static struct vm_operations_struct privcmd_vm_ops = { + .close = privcmd_close, .fault = privcmd_fault }; @@ -464,6 +524,10 @@ static int privcmd_mmap(struct file *file, struct vm_area_struct *vma) static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma) { + if (xen_feature(XENFEAT_auto_translated_physmap)) { + int sz = sizeof(vma->vm_private_data); + return (!__cmpxchg(&vma->vm_private_data, NULL, NULL, sz)); + } return (xchg(&vma->vm_private_data, (void *)1) == NULL); } --MP_/kT_PskLq9cVTOBVGRjrj25F Content-Type: text/x-patch Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=mmu.diff diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c index 5a16824..d5e53ad 100644 --- a/arch/x86/xen/mmu.c +++ b/arch/x86/xen/mmu.c @@ -73,6 +73,7 @@ #include #include #include +#include #include "multicalls.h" #include "mmu.h" @@ -331,6 +332,20 @@ static void xen_set_pte(pte_t *ptep, pte_t pteval) __xen_set_pte(ptep, pteval); } +void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn, + int nr_mfns, int add_mapping) +{ + struct physdev_map_iomem iomem; + + iomem.first_gfn = pfn; + iomem.first_mfn = mfn; + iomem.nr_mfns = nr_mfns; + iomem.add_mapping = add_mapping; + + if (HYPERVISOR_physdev_op(PHYSDEVOP_pvh_map_iomem, &iomem)) + BUG(); +} + static void xen_set_pte_at(struct mm_struct *mm, unsigned long addr, pte_t *ptep, pte_t pteval) { @@ -1220,6 +1235,8 @@ static void __init xen_pagetable_init(void) #endif paging_init(); xen_setup_shared_info(); + if (xen_feature(XENFEAT_auto_translated_physmap)) + return; #ifdef CONFIG_X86_64 if (!xen_feature(XENFEAT_auto_translated_physmap)) { unsigned long new_mfn_list; @@ -1527,6 +1544,10 @@ static void __init xen_set_pte_init(pte_t *ptep, pte_t pte) static void pin_pagetable_pfn(unsigned cmd, unsigned long pfn) { struct mmuext_op op; + + if (xen_feature(XENFEAT_writable_page_tables)) + return; + op.cmd = cmd; op.arg1.mfn = pfn_to_mfn(pfn); if (HYPERVISOR_mmuext_op(&op, 1, NULL, DOMID_SELF)) @@ -1724,6 +1745,10 @@ static void set_page_prot(void *addr, pgprot_t prot) unsigned long pfn = __pa(addr) >> PAGE_SHIFT; pte_t pte = pfn_pte(pfn, prot); + /* recall for PVH, page tables are native. */ + if (xen_feature(XENFEAT_auto_translated_physmap)) + return; + if (HYPERVISOR_update_va_mapping((unsigned long)addr, pte, 0)) BUG(); } @@ -1801,6 +1826,9 @@ static void convert_pfn_mfn(void *v) pte_t *pte = v; int i; + if (xen_feature(XENFEAT_auto_translated_physmap)) + return; + /* All levels are converted the same way, so just treat them as ptes. */ for (i = 0; i < PTRS_PER_PTE; i++) @@ -1820,6 +1848,7 @@ static void __init check_pt_base(unsigned long *pt_base, unsigned long *pt_end, (*pt_end)--; } } + /* * Set up the initial kernel pagetable. * @@ -1830,6 +1859,7 @@ static void __init check_pt_base(unsigned long *pt_base, unsigned long *pt_end, * but that's enough to get __va working. We need to fill in the rest * of the physical mapping once some sort of allocator has been set * up. + * NOTE: for PVH, the page tables are native. */ void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn) { @@ -1907,10 +1937,13 @@ void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn) * structure to attach it to, so make sure we just set kernel * pgd. */ - xen_mc_batch(); - __xen_write_cr3(true, __pa(init_level4_pgt)); - xen_mc_issue(PARAVIRT_LAZY_CPU); - + if (xen_feature(XENFEAT_writable_page_tables)) { + native_write_cr3(__pa(init_level4_pgt)); + } else { + xen_mc_batch(); + __xen_write_cr3(true, __pa(init_level4_pgt)); + xen_mc_issue(PARAVIRT_LAZY_CPU); + } /* We can't that easily rip out L3 and L2, as the Xen pagetables are * set out this way: [L4], [L1], [L2], [L3], [L1], [L1] ... for * the initial domain. For guests using the toolstack, they are in: @@ -2177,8 +2210,19 @@ static const struct pv_mmu_ops xen_mmu_ops __initconst = { void __init xen_init_mmu_ops(void) { - x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve; x86_init.paging.pagetable_init = xen_pagetable_init; + + if (xen_feature(XENFEAT_auto_translated_physmap)) { + pv_mmu_ops.flush_tlb_others = xen_flush_tlb_others; + + /* set_pte* for PCI devices to map iomem. */ + if (xen_initial_domain()) { + pv_mmu_ops.set_pte = native_set_pte; + pv_mmu_ops.set_pte_at = native_set_pte_at; + } + return; + } + x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve; pv_mmu_ops = xen_mmu_ops; memset(dummy_mapping, 0xff, PAGE_SIZE); @@ -2414,6 +2458,94 @@ void __init xen_hvm_init_mmu_ops(void) } #endif +/* Map foreign gmfn, fgmfn, to local pfn, lpfn. This for the user space + * creating new guest on PVH dom0 and needs to map domU pages. + */ +static int pvh_add_to_xen_p2m(unsigned long lpfn, unsigned long fgmfn, + unsigned int domid) +{ + int rc; + struct xen_add_to_physmap xatp = { .u.foreign_domid = domid }; + + xatp.gpfn = lpfn; + xatp.idx = fgmfn; + xatp.domid = DOMID_SELF; + xatp.space = XENMAPSPACE_gmfn_foreign; + rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp); + if (rc) + pr_warn("d0: Failed to map pfn to mfn rc:%d pfn:%lx mfn:%lx\n", + rc, lpfn, fgmfn); + return rc; +} + +int pvh_rem_xen_p2m(unsigned long spfn, int count) +{ + struct xen_remove_from_physmap xrp; + int i, rc; + + for (i=0; i < count; i++) { + xrp.domid = DOMID_SELF; + xrp.gpfn = spfn+i; + rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, &xrp); + if (rc) { + pr_warn("Failed to unmap pfn:%lx rc:%d done:%d\n", + spfn+i, rc, i); + return 1; + } + } + return 0; +} +EXPORT_SYMBOL_GPL(pvh_rem_xen_p2m); + +struct pvh_remap_data { + unsigned long fgmfn; /* foreign domain's gmfn */ + pgprot_t prot; + domid_t domid; + int index; + struct page **pages; +}; + +static int pvh_map_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr, + void *data) +{ + int rc; + struct pvh_remap_data *remap = data; + unsigned long pfn = page_to_pfn(remap->pages[remap->index++]); + pte_t pteval = pte_mkspecial(pfn_pte(pfn, remap->prot)); + + if ((rc=pvh_add_to_xen_p2m(pfn, remap->fgmfn, remap->domid))) + return rc; + native_set_pte(ptep, pteval); + + return 0; +} + +/* The only caller at moment passes one gmfn at a time. + * PVH TBD/FIXME: expand this in future to honor batch requests. + */ +static int pvh_remap_gmfn_range(struct vm_area_struct *vma, + unsigned long addr, unsigned long mfn, int nr, + pgprot_t prot, unsigned domid, + struct page **pages) +{ + int err; + struct pvh_remap_data pvhdata; + + if (nr > 1) + return -EINVAL; + + pvhdata.fgmfn = mfn; + pvhdata.prot = prot; + pvhdata.domid = domid; + pvhdata.index = 0; + pvhdata.pages = pages; + err = apply_to_page_range(vma->vm_mm, addr, nr << PAGE_SHIFT, + pvh_map_pte_fn, &pvhdata); + flush_tlb_all(); + /* flush_tlb_page(vma, addr); */ + return err; +} + #define REMAP_BATCH_SIZE 16 struct remap_data { @@ -2438,7 +2570,9 @@ static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token, int xen_remap_domain_mfn_range(struct vm_area_struct *vma, unsigned long addr, unsigned long mfn, int nr, - pgprot_t prot, unsigned domid) + pgprot_t prot, unsigned domid, + struct page **pages) + { struct remap_data rmd; struct mmu_update mmu_update[REMAP_BATCH_SIZE]; @@ -2446,14 +2580,17 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma, unsigned long range; int err = 0; - if (xen_feature(XENFEAT_auto_translated_physmap)) - return -EINVAL; - prot = __pgprot(pgprot_val(prot) | _PAGE_IOMAP); BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_RESERVED | VM_IO)) == (VM_PFNMAP | VM_RESERVED | VM_IO))); + if (xen_feature(XENFEAT_auto_translated_physmap)) { + /* We need to update the local page tables and the xen HAP */ + return pvh_remap_gmfn_range(vma, addr, mfn, nr, prot, domid, + pages); + } + rmd.mfn = mfn; rmd.prot = prot; @@ -2483,3 +2620,25 @@ out: return err; } EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range); + +/* Returns: 0 success */ +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma) +{ + int numpgs = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT; + struct page **pages = vma ? vma->vm_private_data : NULL; + + if (!pages || !xen_feature(XENFEAT_auto_translated_physmap)) + return 0; + + while (numpgs--) { + + /* the mmu has already cleaned up the process mmu resources at + * this point (lookup_address will return NULL). */ + unsigned long pfn = page_to_pfn(pages[numpgs]); + + pvh_rem_xen_p2m(pfn, 1); + } + flush_tlb_all(); + return 0; +} +EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range); --MP_/kT_PskLq9cVTOBVGRjrj25F Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --MP_/kT_PskLq9cVTOBVGRjrj25F-- From xen-devel-bounces@lists.xen.org Sat Oct 06 02:01:01 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 06 Oct 2012 02:01:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKJgr-0006nD-Dq; Sat, 06 Oct 2012 02:00:29 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKJgp-0006fE-AE for Xen-devel@lists.xensource.com; Sat, 06 Oct 2012 02:00:27 +0000 Received: from [85.158.138.51:9119] by server-7.bemta-3.messagelabs.com id B9/1E-15765-AB09F605; Sat, 06 Oct 2012 02:00:26 +0000 X-Env-Sender: mukesh.rathor@oracle.com X-Msg-Ref: server-5.tower-174.messagelabs.com!1349488823!33379391!1 X-Originating-IP: [148.87.113.117] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzg3MjI1\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29302 invoked from network); 6 Oct 2012 02:00:24 -0000 Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Oct 2012 02:00:24 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q9620EbZ015142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 6 Oct 2012 02:00:15 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q9620Drb029661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Oct 2012 02:00:14 GMT Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q9620DK9011447; Fri, 5 Oct 2012 21:00:13 -0500 Received: from mantra.us.oracle.com (/130.35.68.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 05 Oct 2012 19:00:12 -0700 Date: Fri, 5 Oct 2012 19:00:11 -0700 From: Mukesh Rathor To: Ian Campbell Message-ID: <20121005190011.2653bcfa@mantra.us.oracle.com> In-Reply-To: <1349339279.650.214.camel@zakaz.uk.xensource.com> References: <20120921121556.1a0ea8af@mantra.us.oracle.com> <1349278963.650.164.camel@zakaz.uk.xensource.com> <20121003152925.5af3a658@mantra.us.oracle.com> <1349339279.650.214.camel@zakaz.uk.xensource.com> Organization: Oracle Corporation X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/kT_PskLq9cVTOBVGRjrj25F" X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org --MP_/kT_PskLq9cVTOBVGRjrj25F Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline On Thu, 4 Oct 2012 09:27:59 +0100 Ian Campbell wrote: > On Wed, 2012-10-03 at 23:29 +0100, Mukesh Rathor wrote: > > On Wed, 3 Oct 2012 16:42:43 +0100 > > Ian Campbell wrote: > > > While implementing the ARM version of this interface it occurred to me > that the num_pgs and next_todo fields here are not really needed > across the arch interface e.g. you already get pi_num_pgs from the nr > argument to xen_remap_domain_mfn_range and pi_next_todo is really > state which fits in struct pvh_remap_data. That would mean that > remap_foo could take a struct page * directly and I think you would > save an allocation. Ok, take a look at the attached and inlined diffs. I redid it, passing struct page to the api, and getting rid of the pi_* struct completely. thanks Mukesh diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c index ef63895..6cbf59a 100644 --- a/drivers/xen/privcmd.c +++ b/drivers/xen/privcmd.c @@ -33,6 +33,7 @@ #include #include #include +#include #include "privcmd.h" @@ -178,7 +179,7 @@ static int mmap_mfn_range(void *data, void *state) msg->va & PAGE_MASK, msg->mfn, msg->npages, vma->vm_page_prot, - st->domain); + st->domain, NULL); if (rc < 0) return rc; @@ -199,6 +200,10 @@ static long privcmd_ioctl_mmap(void __user *udata) if (!xen_initial_domain()) return -EPERM; + /* We only support privcmd_ioctl_mmap_batch for auto translated. */ + if (xen_feature(XENFEAT_auto_translated_physmap)) + return -ENOSYS; + if (copy_from_user(&mmapcmd, udata, sizeof(mmapcmd))) return -EFAULT; @@ -246,6 +251,7 @@ struct mmap_batch_state { domid_t domain; unsigned long va; struct vm_area_struct *vma; + int index; /* A tristate: * 0 for no errors * 1 if at least one error has happened (and no @@ -260,14 +266,20 @@ struct mmap_batch_state { xen_pfn_t __user *user_mfn; }; +/* PVH dom0 fyi: if domU being created is PV, then mfn is mfn(addr on bus). If + * it's PVH then mfn is pfn (input to HAP). */ static int mmap_batch_fn(void *data, void *state) { xen_pfn_t *mfnp = data; struct mmap_batch_state *st = state; + struct vm_area_struct *vma = st->vma; + struct page **pages = vma ? vma->vm_private_data : NULL; + struct page *cur_page = pages[st->index++]; int ret; ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1, - st->vma->vm_page_prot, st->domain); + st->vma->vm_page_prot, st->domain, + &cur_page); /* Store error code for second pass. */ *(st->err++) = ret; @@ -303,6 +315,32 @@ static int mmap_return_errors_v1(void *data, void *state) return __put_user(*mfnp, st->user_mfn++); } +/* Allocate pfns that are then mapped with gmfns from foreign domid. Update + * the vma with the page info to use later. + * Returns: 0 if success, otherwise -errno + */ +static int pvh_privcmd_resv_pfns(struct vm_area_struct *vma, int numpgs) +{ + int rc; + struct page **pages; + + pages = kcalloc(numpgs, sizeof(pages[0]), GFP_KERNEL); + if (pages == NULL) + return -ENOMEM; + + rc = alloc_xenballooned_pages(numpgs, pages, 0); + if (rc != 0) { + pr_warn("%s Could not alloc %d pfns rc:%d\n", __func__, + numpgs, rc); + kfree(pages); + return -ENOMEM; + } + BUG_ON(vma->vm_private_data); + vma->vm_private_data = pages; + + return 0; +} + static struct vm_operations_struct privcmd_vm_ops; static long privcmd_ioctl_mmap_batch(void __user *udata, int version) @@ -370,10 +408,17 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version) up_write(&mm->mmap_sem); goto out; } + if (xen_feature(XENFEAT_auto_translated_physmap)) { + if ((ret = pvh_privcmd_resv_pfns(vma, m.num)) < 0) { + up_write(&mm->mmap_sem); + goto out; + } + } state.domain = m.dom; state.vma = vma; state.va = m.addr; + state.index = 0; state.global_error = 0; state.err = err_array; @@ -438,6 +483,20 @@ static long privcmd_ioctl(struct file *file, return ret; } +static void privcmd_close(struct vm_area_struct *vma) +{ + struct page **pages = vma ? vma->vm_private_data : NULL; + int numpgs = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT; + + if (!pages || !numpgs || !xen_feature(XENFEAT_auto_translated_physmap)) + return; + + xen_unmap_domain_mfn_range(vma); + while (numpgs--) + free_xenballooned_pages(1, &pages[numpgs]); + kfree(pages); +} + static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf) { printk(KERN_DEBUG "privcmd_fault: vma=%p %lx-%lx, pgoff=%lx, uv=%p\n", @@ -448,6 +507,7 @@ static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf) } static struct vm_operations_struct privcmd_vm_ops = { + .close = privcmd_close, .fault = privcmd_fault }; @@ -464,6 +524,10 @@ static int privcmd_mmap(struct file *file, struct vm_area_struct *vma) static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma) { + if (xen_feature(XENFEAT_auto_translated_physmap)) { + int sz = sizeof(vma->vm_private_data); + return (!__cmpxchg(&vma->vm_private_data, NULL, NULL, sz)); + } return (xchg(&vma->vm_private_data, (void *)1) == NULL); } =============================================================================================== diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c index 5a16824..d5e53ad 100644 --- a/arch/x86/xen/mmu.c +++ b/arch/x86/xen/mmu.c @@ -73,6 +73,7 @@ #include #include #include +#include #include "multicalls.h" #include "mmu.h" @@ -331,6 +332,20 @@ static void xen_set_pte(pte_t *ptep, pte_t pteval) __xen_set_pte(ptep, pteval); } +void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn, + int nr_mfns, int add_mapping) +{ + struct physdev_map_iomem iomem; + + iomem.first_gfn = pfn; + iomem.first_mfn = mfn; + iomem.nr_mfns = nr_mfns; + iomem.add_mapping = add_mapping; + + if (HYPERVISOR_physdev_op(PHYSDEVOP_pvh_map_iomem, &iomem)) + BUG(); +} + static void xen_set_pte_at(struct mm_struct *mm, unsigned long addr, pte_t *ptep, pte_t pteval) { @@ -1220,6 +1235,8 @@ static void __init xen_pagetable_init(void) #endif paging_init(); xen_setup_shared_info(); + if (xen_feature(XENFEAT_auto_translated_physmap)) + return; #ifdef CONFIG_X86_64 if (!xen_feature(XENFEAT_auto_translated_physmap)) { unsigned long new_mfn_list; @@ -1527,6 +1544,10 @@ static void __init xen_set_pte_init(pte_t *ptep, pte_t pte) static void pin_pagetable_pfn(unsigned cmd, unsigned long pfn) { struct mmuext_op op; + + if (xen_feature(XENFEAT_writable_page_tables)) + return; + op.cmd = cmd; op.arg1.mfn = pfn_to_mfn(pfn); if (HYPERVISOR_mmuext_op(&op, 1, NULL, DOMID_SELF)) @@ -1724,6 +1745,10 @@ static void set_page_prot(void *addr, pgprot_t prot) unsigned long pfn = __pa(addr) >> PAGE_SHIFT; pte_t pte = pfn_pte(pfn, prot); + /* recall for PVH, page tables are native. */ + if (xen_feature(XENFEAT_auto_translated_physmap)) + return; + if (HYPERVISOR_update_va_mapping((unsigned long)addr, pte, 0)) BUG(); } @@ -1801,6 +1826,9 @@ static void convert_pfn_mfn(void *v) pte_t *pte = v; int i; + if (xen_feature(XENFEAT_auto_translated_physmap)) + return; + /* All levels are converted the same way, so just treat them as ptes. */ for (i = 0; i < PTRS_PER_PTE; i++) @@ -1820,6 +1848,7 @@ static void __init check_pt_base(unsigned long *pt_base, unsigned long *pt_end, (*pt_end)--; } } + /* * Set up the initial kernel pagetable. * @@ -1830,6 +1859,7 @@ static void __init check_pt_base(unsigned long *pt_base, unsigned long *pt_end, * but that's enough to get __va working. We need to fill in the rest * of the physical mapping once some sort of allocator has been set * up. + * NOTE: for PVH, the page tables are native. */ void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn) { @@ -1907,10 +1937,13 @@ void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn) * structure to attach it to, so make sure we just set kernel * pgd. */ - xen_mc_batch(); - __xen_write_cr3(true, __pa(init_level4_pgt)); - xen_mc_issue(PARAVIRT_LAZY_CPU); - + if (xen_feature(XENFEAT_writable_page_tables)) { + native_write_cr3(__pa(init_level4_pgt)); + } else { + xen_mc_batch(); + __xen_write_cr3(true, __pa(init_level4_pgt)); + xen_mc_issue(PARAVIRT_LAZY_CPU); + } /* We can't that easily rip out L3 and L2, as the Xen pagetables are * set out this way: [L4], [L1], [L2], [L3], [L1], [L1] ... for * the initial domain. For guests using the toolstack, they are in: @@ -2177,8 +2210,19 @@ static const struct pv_mmu_ops xen_mmu_ops __initconst = { void __init xen_init_mmu_ops(void) { - x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve; x86_init.paging.pagetable_init = xen_pagetable_init; + + if (xen_feature(XENFEAT_auto_translated_physmap)) { + pv_mmu_ops.flush_tlb_others = xen_flush_tlb_others; + + /* set_pte* for PCI devices to map iomem. */ + if (xen_initial_domain()) { + pv_mmu_ops.set_pte = native_set_pte; + pv_mmu_ops.set_pte_at = native_set_pte_at; + } + return; + } + x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve; pv_mmu_ops = xen_mmu_ops; memset(dummy_mapping, 0xff, PAGE_SIZE); @@ -2414,6 +2458,94 @@ void __init xen_hvm_init_mmu_ops(void) } #endif +/* Map foreign gmfn, fgmfn, to local pfn, lpfn. This for the user space + * creating new guest on PVH dom0 and needs to map domU pages. + */ +static int pvh_add_to_xen_p2m(unsigned long lpfn, unsigned long fgmfn, + unsigned int domid) +{ + int rc; + struct xen_add_to_physmap xatp = { .u.foreign_domid = domid }; + + xatp.gpfn = lpfn; + xatp.idx = fgmfn; + xatp.domid = DOMID_SELF; + xatp.space = XENMAPSPACE_gmfn_foreign; + rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp); + if (rc) + pr_warn("d0: Failed to map pfn to mfn rc:%d pfn:%lx mfn:%lx\n", + rc, lpfn, fgmfn); + return rc; +} + +int pvh_rem_xen_p2m(unsigned long spfn, int count) +{ + struct xen_remove_from_physmap xrp; + int i, rc; + + for (i=0; i < count; i++) { + xrp.domid = DOMID_SELF; + xrp.gpfn = spfn+i; + rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, &xrp); + if (rc) { + pr_warn("Failed to unmap pfn:%lx rc:%d done:%d\n", + spfn+i, rc, i); + return 1; + } + } + return 0; +} +EXPORT_SYMBOL_GPL(pvh_rem_xen_p2m); + +struct pvh_remap_data { + unsigned long fgmfn; /* foreign domain's gmfn */ + pgprot_t prot; + domid_t domid; + int index; + struct page **pages; +}; + +static int pvh_map_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr, + void *data) +{ + int rc; + struct pvh_remap_data *remap = data; + unsigned long pfn = page_to_pfn(remap->pages[remap->index++]); + pte_t pteval = pte_mkspecial(pfn_pte(pfn, remap->prot)); + + if ((rc=pvh_add_to_xen_p2m(pfn, remap->fgmfn, remap->domid))) + return rc; + native_set_pte(ptep, pteval); + + return 0; +} + +/* The only caller at moment passes one gmfn at a time. + * PVH TBD/FIXME: expand this in future to honor batch requests. + */ +static int pvh_remap_gmfn_range(struct vm_area_struct *vma, + unsigned long addr, unsigned long mfn, int nr, + pgprot_t prot, unsigned domid, + struct page **pages) +{ + int err; + struct pvh_remap_data pvhdata; + + if (nr > 1) + return -EINVAL; + + pvhdata.fgmfn = mfn; + pvhdata.prot = prot; + pvhdata.domid = domid; + pvhdata.index = 0; + pvhdata.pages = pages; + err = apply_to_page_range(vma->vm_mm, addr, nr << PAGE_SHIFT, + pvh_map_pte_fn, &pvhdata); + flush_tlb_all(); + /* flush_tlb_page(vma, addr); */ + return err; +} + #define REMAP_BATCH_SIZE 16 struct remap_data { @@ -2438,7 +2570,9 @@ static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token, int xen_remap_domain_mfn_range(struct vm_area_struct *vma, unsigned long addr, unsigned long mfn, int nr, - pgprot_t prot, unsigned domid) + pgprot_t prot, unsigned domid, + struct page **pages) + { struct remap_data rmd; struct mmu_update mmu_update[REMAP_BATCH_SIZE]; @@ -2446,14 +2580,17 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma, unsigned long range; int err = 0; - if (xen_feature(XENFEAT_auto_translated_physmap)) - return -EINVAL; - prot = __pgprot(pgprot_val(prot) | _PAGE_IOMAP); BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_RESERVED | VM_IO)) == (VM_PFNMAP | VM_RESERVED | VM_IO))); + if (xen_feature(XENFEAT_auto_translated_physmap)) { + /* We need to update the local page tables and the xen HAP */ + return pvh_remap_gmfn_range(vma, addr, mfn, nr, prot, domid, + pages); + } + rmd.mfn = mfn; rmd.prot = prot; @@ -2483,3 +2620,25 @@ out: return err; } EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range); + +/* Returns: 0 success */ +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma) +{ + int numpgs = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT; + struct page **pages = vma ? vma->vm_private_data : NULL; + + if (!pages || !xen_feature(XENFEAT_auto_translated_physmap)) + return 0; + + while (numpgs--) { + + /* the mmu has already cleaned up the process mmu resources at + * this point (lookup_address will return NULL). */ + unsigned long pfn = page_to_pfn(pages[numpgs]); + + pvh_rem_xen_p2m(pfn, 1); + } + flush_tlb_all(); + return 0; +} +EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range); --MP_/kT_PskLq9cVTOBVGRjrj25F Content-Type: text/x-patch Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=priv.diff diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c index ef63895..6cbf59a 100644 --- a/drivers/xen/privcmd.c +++ b/drivers/xen/privcmd.c @@ -33,6 +33,7 @@ #include #include #include +#include #include "privcmd.h" @@ -178,7 +179,7 @@ static int mmap_mfn_range(void *data, void *state) msg->va & PAGE_MASK, msg->mfn, msg->npages, vma->vm_page_prot, - st->domain); + st->domain, NULL); if (rc < 0) return rc; @@ -199,6 +200,10 @@ static long privcmd_ioctl_mmap(void __user *udata) if (!xen_initial_domain()) return -EPERM; + /* We only support privcmd_ioctl_mmap_batch for auto translated. */ + if (xen_feature(XENFEAT_auto_translated_physmap)) + return -ENOSYS; + if (copy_from_user(&mmapcmd, udata, sizeof(mmapcmd))) return -EFAULT; @@ -246,6 +251,7 @@ struct mmap_batch_state { domid_t domain; unsigned long va; struct vm_area_struct *vma; + int index; /* A tristate: * 0 for no errors * 1 if at least one error has happened (and no @@ -260,14 +266,20 @@ struct mmap_batch_state { xen_pfn_t __user *user_mfn; }; +/* PVH dom0 fyi: if domU being created is PV, then mfn is mfn(addr on bus). If + * it's PVH then mfn is pfn (input to HAP). */ static int mmap_batch_fn(void *data, void *state) { xen_pfn_t *mfnp = data; struct mmap_batch_state *st = state; + struct vm_area_struct *vma = st->vma; + struct page **pages = vma ? vma->vm_private_data : NULL; + struct page *cur_page = pages[st->index++]; int ret; ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1, - st->vma->vm_page_prot, st->domain); + st->vma->vm_page_prot, st->domain, + &cur_page); /* Store error code for second pass. */ *(st->err++) = ret; @@ -303,6 +315,32 @@ static int mmap_return_errors_v1(void *data, void *state) return __put_user(*mfnp, st->user_mfn++); } +/* Allocate pfns that are then mapped with gmfns from foreign domid. Update + * the vma with the page info to use later. + * Returns: 0 if success, otherwise -errno + */ +static int pvh_privcmd_resv_pfns(struct vm_area_struct *vma, int numpgs) +{ + int rc; + struct page **pages; + + pages = kcalloc(numpgs, sizeof(pages[0]), GFP_KERNEL); + if (pages == NULL) + return -ENOMEM; + + rc = alloc_xenballooned_pages(numpgs, pages, 0); + if (rc != 0) { + pr_warn("%s Could not alloc %d pfns rc:%d\n", __func__, + numpgs, rc); + kfree(pages); + return -ENOMEM; + } + BUG_ON(vma->vm_private_data); + vma->vm_private_data = pages; + + return 0; +} + static struct vm_operations_struct privcmd_vm_ops; static long privcmd_ioctl_mmap_batch(void __user *udata, int version) @@ -370,10 +408,17 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version) up_write(&mm->mmap_sem); goto out; } + if (xen_feature(XENFEAT_auto_translated_physmap)) { + if ((ret = pvh_privcmd_resv_pfns(vma, m.num)) < 0) { + up_write(&mm->mmap_sem); + goto out; + } + } state.domain = m.dom; state.vma = vma; state.va = m.addr; + state.index = 0; state.global_error = 0; state.err = err_array; @@ -438,6 +483,20 @@ static long privcmd_ioctl(struct file *file, return ret; } +static void privcmd_close(struct vm_area_struct *vma) +{ + struct page **pages = vma ? vma->vm_private_data : NULL; + int numpgs = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT; + + if (!pages || !numpgs || !xen_feature(XENFEAT_auto_translated_physmap)) + return; + + xen_unmap_domain_mfn_range(vma); + while (numpgs--) + free_xenballooned_pages(1, &pages[numpgs]); + kfree(pages); +} + static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf) { printk(KERN_DEBUG "privcmd_fault: vma=%p %lx-%lx, pgoff=%lx, uv=%p\n", @@ -448,6 +507,7 @@ static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf) } static struct vm_operations_struct privcmd_vm_ops = { + .close = privcmd_close, .fault = privcmd_fault }; @@ -464,6 +524,10 @@ static int privcmd_mmap(struct file *file, struct vm_area_struct *vma) static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma) { + if (xen_feature(XENFEAT_auto_translated_physmap)) { + int sz = sizeof(vma->vm_private_data); + return (!__cmpxchg(&vma->vm_private_data, NULL, NULL, sz)); + } return (xchg(&vma->vm_private_data, (void *)1) == NULL); } --MP_/kT_PskLq9cVTOBVGRjrj25F Content-Type: text/x-patch Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=mmu.diff diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c index 5a16824..d5e53ad 100644 --- a/arch/x86/xen/mmu.c +++ b/arch/x86/xen/mmu.c @@ -73,6 +73,7 @@ #include #include #include +#include #include "multicalls.h" #include "mmu.h" @@ -331,6 +332,20 @@ static void xen_set_pte(pte_t *ptep, pte_t pteval) __xen_set_pte(ptep, pteval); } +void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn, + int nr_mfns, int add_mapping) +{ + struct physdev_map_iomem iomem; + + iomem.first_gfn = pfn; + iomem.first_mfn = mfn; + iomem.nr_mfns = nr_mfns; + iomem.add_mapping = add_mapping; + + if (HYPERVISOR_physdev_op(PHYSDEVOP_pvh_map_iomem, &iomem)) + BUG(); +} + static void xen_set_pte_at(struct mm_struct *mm, unsigned long addr, pte_t *ptep, pte_t pteval) { @@ -1220,6 +1235,8 @@ static void __init xen_pagetable_init(void) #endif paging_init(); xen_setup_shared_info(); + if (xen_feature(XENFEAT_auto_translated_physmap)) + return; #ifdef CONFIG_X86_64 if (!xen_feature(XENFEAT_auto_translated_physmap)) { unsigned long new_mfn_list; @@ -1527,6 +1544,10 @@ static void __init xen_set_pte_init(pte_t *ptep, pte_t pte) static void pin_pagetable_pfn(unsigned cmd, unsigned long pfn) { struct mmuext_op op; + + if (xen_feature(XENFEAT_writable_page_tables)) + return; + op.cmd = cmd; op.arg1.mfn = pfn_to_mfn(pfn); if (HYPERVISOR_mmuext_op(&op, 1, NULL, DOMID_SELF)) @@ -1724,6 +1745,10 @@ static void set_page_prot(void *addr, pgprot_t prot) unsigned long pfn = __pa(addr) >> PAGE_SHIFT; pte_t pte = pfn_pte(pfn, prot); + /* recall for PVH, page tables are native. */ + if (xen_feature(XENFEAT_auto_translated_physmap)) + return; + if (HYPERVISOR_update_va_mapping((unsigned long)addr, pte, 0)) BUG(); } @@ -1801,6 +1826,9 @@ static void convert_pfn_mfn(void *v) pte_t *pte = v; int i; + if (xen_feature(XENFEAT_auto_translated_physmap)) + return; + /* All levels are converted the same way, so just treat them as ptes. */ for (i = 0; i < PTRS_PER_PTE; i++) @@ -1820,6 +1848,7 @@ static void __init check_pt_base(unsigned long *pt_base, unsigned long *pt_end, (*pt_end)--; } } + /* * Set up the initial kernel pagetable. * @@ -1830,6 +1859,7 @@ static void __init check_pt_base(unsigned long *pt_base, unsigned long *pt_end, * but that's enough to get __va working. We need to fill in the rest * of the physical mapping once some sort of allocator has been set * up. + * NOTE: for PVH, the page tables are native. */ void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn) { @@ -1907,10 +1937,13 @@ void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn) * structure to attach it to, so make sure we just set kernel * pgd. */ - xen_mc_batch(); - __xen_write_cr3(true, __pa(init_level4_pgt)); - xen_mc_issue(PARAVIRT_LAZY_CPU); - + if (xen_feature(XENFEAT_writable_page_tables)) { + native_write_cr3(__pa(init_level4_pgt)); + } else { + xen_mc_batch(); + __xen_write_cr3(true, __pa(init_level4_pgt)); + xen_mc_issue(PARAVIRT_LAZY_CPU); + } /* We can't that easily rip out L3 and L2, as the Xen pagetables are * set out this way: [L4], [L1], [L2], [L3], [L1], [L1] ... for * the initial domain. For guests using the toolstack, they are in: @@ -2177,8 +2210,19 @@ static const struct pv_mmu_ops xen_mmu_ops __initconst = { void __init xen_init_mmu_ops(void) { - x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve; x86_init.paging.pagetable_init = xen_pagetable_init; + + if (xen_feature(XENFEAT_auto_translated_physmap)) { + pv_mmu_ops.flush_tlb_others = xen_flush_tlb_others; + + /* set_pte* for PCI devices to map iomem. */ + if (xen_initial_domain()) { + pv_mmu_ops.set_pte = native_set_pte; + pv_mmu_ops.set_pte_at = native_set_pte_at; + } + return; + } + x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve; pv_mmu_ops = xen_mmu_ops; memset(dummy_mapping, 0xff, PAGE_SIZE); @@ -2414,6 +2458,94 @@ void __init xen_hvm_init_mmu_ops(void) } #endif +/* Map foreign gmfn, fgmfn, to local pfn, lpfn. This for the user space + * creating new guest on PVH dom0 and needs to map domU pages. + */ +static int pvh_add_to_xen_p2m(unsigned long lpfn, unsigned long fgmfn, + unsigned int domid) +{ + int rc; + struct xen_add_to_physmap xatp = { .u.foreign_domid = domid }; + + xatp.gpfn = lpfn; + xatp.idx = fgmfn; + xatp.domid = DOMID_SELF; + xatp.space = XENMAPSPACE_gmfn_foreign; + rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp); + if (rc) + pr_warn("d0: Failed to map pfn to mfn rc:%d pfn:%lx mfn:%lx\n", + rc, lpfn, fgmfn); + return rc; +} + +int pvh_rem_xen_p2m(unsigned long spfn, int count) +{ + struct xen_remove_from_physmap xrp; + int i, rc; + + for (i=0; i < count; i++) { + xrp.domid = DOMID_SELF; + xrp.gpfn = spfn+i; + rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, &xrp); + if (rc) { + pr_warn("Failed to unmap pfn:%lx rc:%d done:%d\n", + spfn+i, rc, i); + return 1; + } + } + return 0; +} +EXPORT_SYMBOL_GPL(pvh_rem_xen_p2m); + +struct pvh_remap_data { + unsigned long fgmfn; /* foreign domain's gmfn */ + pgprot_t prot; + domid_t domid; + int index; + struct page **pages; +}; + +static int pvh_map_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr, + void *data) +{ + int rc; + struct pvh_remap_data *remap = data; + unsigned long pfn = page_to_pfn(remap->pages[remap->index++]); + pte_t pteval = pte_mkspecial(pfn_pte(pfn, remap->prot)); + + if ((rc=pvh_add_to_xen_p2m(pfn, remap->fgmfn, remap->domid))) + return rc; + native_set_pte(ptep, pteval); + + return 0; +} + +/* The only caller at moment passes one gmfn at a time. + * PVH TBD/FIXME: expand this in future to honor batch requests. + */ +static int pvh_remap_gmfn_range(struct vm_area_struct *vma, + unsigned long addr, unsigned long mfn, int nr, + pgprot_t prot, unsigned domid, + struct page **pages) +{ + int err; + struct pvh_remap_data pvhdata; + + if (nr > 1) + return -EINVAL; + + pvhdata.fgmfn = mfn; + pvhdata.prot = prot; + pvhdata.domid = domid; + pvhdata.index = 0; + pvhdata.pages = pages; + err = apply_to_page_range(vma->vm_mm, addr, nr << PAGE_SHIFT, + pvh_map_pte_fn, &pvhdata); + flush_tlb_all(); + /* flush_tlb_page(vma, addr); */ + return err; +} + #define REMAP_BATCH_SIZE 16 struct remap_data { @@ -2438,7 +2570,9 @@ static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token, int xen_remap_domain_mfn_range(struct vm_area_struct *vma, unsigned long addr, unsigned long mfn, int nr, - pgprot_t prot, unsigned domid) + pgprot_t prot, unsigned domid, + struct page **pages) + { struct remap_data rmd; struct mmu_update mmu_update[REMAP_BATCH_SIZE]; @@ -2446,14 +2580,17 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma, unsigned long range; int err = 0; - if (xen_feature(XENFEAT_auto_translated_physmap)) - return -EINVAL; - prot = __pgprot(pgprot_val(prot) | _PAGE_IOMAP); BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_RESERVED | VM_IO)) == (VM_PFNMAP | VM_RESERVED | VM_IO))); + if (xen_feature(XENFEAT_auto_translated_physmap)) { + /* We need to update the local page tables and the xen HAP */ + return pvh_remap_gmfn_range(vma, addr, mfn, nr, prot, domid, + pages); + } + rmd.mfn = mfn; rmd.prot = prot; @@ -2483,3 +2620,25 @@ out: return err; } EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range); + +/* Returns: 0 success */ +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma) +{ + int numpgs = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT; + struct page **pages = vma ? vma->vm_private_data : NULL; + + if (!pages || !xen_feature(XENFEAT_auto_translated_physmap)) + return 0; + + while (numpgs--) { + + /* the mmu has already cleaned up the process mmu resources at + * this point (lookup_address will return NULL). */ + unsigned long pfn = page_to_pfn(pages[numpgs]); + + pvh_rem_xen_p2m(pfn, 1); + } + flush_tlb_all(); + return 0; +} +EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range); --MP_/kT_PskLq9cVTOBVGRjrj25F Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --MP_/kT_PskLq9cVTOBVGRjrj25F-- From xen-devel-bounces@lists.xen.org Sat Oct 06 02:05:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 06 Oct 2012 02:05:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKJl6-0006vC-4c; Sat, 06 Oct 2012 02:04:52 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKJl4-0006v1-Ne for xen-devel@lists.xen.org; Sat, 06 Oct 2012 02:04:51 +0000 Received: from [85.158.138.51:21537] by server-8.bemta-3.messagelabs.com id 25/51-16337-1C19F605; Sat, 06 Oct 2012 02:04:49 +0000 X-Env-Sender: singapore.mr.teo.en.ming@gmail.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1349489087!31611946!1 X-Originating-IP: [209.85.220.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5497 invoked from network); 6 Oct 2012 02:04:49 -0000 Received: from mail-pa0-f45.google.com (HELO mail-pa0-f45.google.com) (209.85.220.45) by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 6 Oct 2012 02:04:49 -0000 Received: by mail-pa0-f45.google.com with SMTP id fb10so2452818pad.32 for ; Fri, 05 Oct 2012 19:04:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8pZr/i42K2Z1X5cZAIsXM2mAEQsbpFOSPz8beU6Wzag=; b=ftkpfqiM91iKEU0Tx2jMqueQeOycPf/TP17aO8Z9Mnyruh7LPcb7mrc2stqhGwlXnb qMhD056RgFpOuq8TiYxADtoAR+PzZ0ZV5el49Rfe9xGzPlY6v0brAE7zP5iBoymDKDMy E7NIlU/9ShG5Vmo0JtGKMvVbGRiPylxZE7KUIHWvnB/Owzz8k01j4vJxoUdjRJBODbI+ dmlUdy4W201UJN1q8YZrAcixe9UFh1OiK7XhKefo1df2ZJz/V4w+DXkZIKyhboyYvE3D qtR+JyeRFmhJjDnGB4nAv+eKAbdr8sInb6AyvfNJC0B5duSsfecN31LjdvuESPkbJibv Wphw== Received: by 10.68.225.3 with SMTP id rg3mr35513925pbc.27.1349489086914; Fri, 05 Oct 2012 19:04:46 -0700 (PDT) Received: from [192.168.1.2] (cm152.gamma205.maxonline.com.sg. [202.156.205.152]) by mx.google.com with ESMTPS id sa2sm6908508pbc.4.2012.10.05.19.04.44 (version=SSLv3 cipher=OTHER); Fri, 05 Oct 2012 19:04:46 -0700 (PDT) Message-ID: <506F91BB.5080002@gmail.com> Date: Sat, 06 Oct 2012 10:04:43 +0800 From: "Teo En Ming (Zhang Enming)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Dariusz Krempa , "xen-users@lists.xen.org" , "xen-devel@lists.xen.org" , "Teo En Ming (Zhang Enming)" References: <506E8BFD.9080504@gmail.com> <506F064F.9010705@gmail.com> In-Reply-To: Subject: Re: [Xen-devel] Help Needed from Xen Developers: Nasty Yellow Triangle with Exclamation Mark and Error Code 43 in Device Manager in Windows 8 HVM domU X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 06/10/2012 05:46, Dariusz Krempa wrote: > > > > > Dear Dariusz Krempa, > > > > Even with Windows XP Home Edition SP3 HVM domU, I also get the nasty > yellow triangle with exclamation mark and error code 43. > > > > -- > > Yours sincerely, > > > > Mr. Teo En Ming (Zhang Enming) > > Singapore > > > > > Im just wondering. In last patch is 7 files to patch and in tutorial > from march You did was just 6. Maybe You missed that additional file. > There should work exact the same makings for gtx560 like before for 4xx. Dear Dariusz Krempa, I have just checked. I can confirm that there are only 6 patch files from David Techer's personal website. How did you get 7 patch files? May I know whose patch files did you use? wget http://www.davidgis.fr/download/xen-4.2_rev24798_gfx-passthrough-patchs.tar.bz2 tar xfvj xen-4.2_rev24798_gfx-passthrough-patchs.tar.bz2 -- Yours sincerely, Mr. Teo En Ming (Zhang Enming) Singapore _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat Oct 06 02:05:19 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 06 Oct 2012 02:05:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKJl6-0006vC-4c; Sat, 06 Oct 2012 02:04:52 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKJl4-0006v1-Ne for xen-devel@lists.xen.org; Sat, 06 Oct 2012 02:04:51 +0000 Received: from [85.158.138.51:21537] by server-8.bemta-3.messagelabs.com id 25/51-16337-1C19F605; Sat, 06 Oct 2012 02:04:49 +0000 X-Env-Sender: singapore.mr.teo.en.ming@gmail.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1349489087!31611946!1 X-Originating-IP: [209.85.220.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5497 invoked from network); 6 Oct 2012 02:04:49 -0000 Received: from mail-pa0-f45.google.com (HELO mail-pa0-f45.google.com) (209.85.220.45) by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 6 Oct 2012 02:04:49 -0000 Received: by mail-pa0-f45.google.com with SMTP id fb10so2452818pad.32 for ; Fri, 05 Oct 2012 19:04:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8pZr/i42K2Z1X5cZAIsXM2mAEQsbpFOSPz8beU6Wzag=; b=ftkpfqiM91iKEU0Tx2jMqueQeOycPf/TP17aO8Z9Mnyruh7LPcb7mrc2stqhGwlXnb qMhD056RgFpOuq8TiYxADtoAR+PzZ0ZV5el49Rfe9xGzPlY6v0brAE7zP5iBoymDKDMy E7NIlU/9ShG5Vmo0JtGKMvVbGRiPylxZE7KUIHWvnB/Owzz8k01j4vJxoUdjRJBODbI+ dmlUdy4W201UJN1q8YZrAcixe9UFh1OiK7XhKefo1df2ZJz/V4w+DXkZIKyhboyYvE3D qtR+JyeRFmhJjDnGB4nAv+eKAbdr8sInb6AyvfNJC0B5duSsfecN31LjdvuESPkbJibv Wphw== Received: by 10.68.225.3 with SMTP id rg3mr35513925pbc.27.1349489086914; Fri, 05 Oct 2012 19:04:46 -0700 (PDT) Received: from [192.168.1.2] (cm152.gamma205.maxonline.com.sg. [202.156.205.152]) by mx.google.com with ESMTPS id sa2sm6908508pbc.4.2012.10.05.19.04.44 (version=SSLv3 cipher=OTHER); Fri, 05 Oct 2012 19:04:46 -0700 (PDT) Message-ID: <506F91BB.5080002@gmail.com> Date: Sat, 06 Oct 2012 10:04:43 +0800 From: "Teo En Ming (Zhang Enming)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Dariusz Krempa , "xen-users@lists.xen.org" , "xen-devel@lists.xen.org" , "Teo En Ming (Zhang Enming)" References: <506E8BFD.9080504@gmail.com> <506F064F.9010705@gmail.com> In-Reply-To: Subject: Re: [Xen-devel] Help Needed from Xen Developers: Nasty Yellow Triangle with Exclamation Mark and Error Code 43 in Device Manager in Windows 8 HVM domU X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 06/10/2012 05:46, Dariusz Krempa wrote: > > > > > Dear Dariusz Krempa, > > > > Even with Windows XP Home Edition SP3 HVM domU, I also get the nasty > yellow triangle with exclamation mark and error code 43. > > > > -- > > Yours sincerely, > > > > Mr. Teo En Ming (Zhang Enming) > > Singapore > > > > > Im just wondering. In last patch is 7 files to patch and in tutorial > from march You did was just 6. Maybe You missed that additional file. > There should work exact the same makings for gtx560 like before for 4xx. Dear Dariusz Krempa, I have just checked. I can confirm that there are only 6 patch files from David Techer's personal website. How did you get 7 patch files? May I know whose patch files did you use? wget http://www.davidgis.fr/download/xen-4.2_rev24798_gfx-passthrough-patchs.tar.bz2 tar xfvj xen-4.2_rev24798_gfx-passthrough-patchs.tar.bz2 -- Yours sincerely, Mr. Teo En Ming (Zhang Enming) Singapore _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat Oct 06 03:31:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 06 Oct 2012 03:31:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKL6L-0007fY-30; Sat, 06 Oct 2012 03:30:53 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKL6J-0007fT-Kn for xen-devel@lists.xensource.com; Sat, 06 Oct 2012 03:30:51 +0000 Received: from [85.158.143.99:9242] by server-1.bemta-4.messagelabs.com id 21/28-05684-AE5AF605; Sat, 06 Oct 2012 03:30:50 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1349494250!23460946!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMyNTM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4978 invoked from network); 6 Oct 2012 03:30:50 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 6 Oct 2012 03:30:50 -0000 X-IronPort-AV: E=Sophos;i="4.80,543,1344211200"; d="scan'208";a="14976140" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 06 Oct 2012 03:30:43 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Sat, 6 Oct 2012 04:30:43 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TKL6A-0006Gu-P9; Sat, 06 Oct 2012 03:30:42 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1TKL6A-0000Gf-MA; Sat, 06 Oct 2012 04:30:42 +0100 To: Message-ID: From: xen.org Date: Sat, 6 Oct 2012 04:30:42 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 13928: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 13928 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13928/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail like 13926 test-amd64-amd64-xl-sedf 5 xen-boot fail like 13926 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail like 13926 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail like 13926 Tests which did not succeed, but are not blocking: test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: xen 3eb9a891889a baseline version: xen 10277c76aed4 ------------------------------------------------------------ People who touched revisions under test: Anthony PERARD Ian Campbell Ian Jackson Matthew Fioravante ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-amd64-amd64-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable + revision=3eb9a891889a + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 3eb9a891889a + branch=xen-unstable + revision=3eb9a891889a + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + . cri-common ++ umask 002 + select_xenbranch + case "$branch" in + tree=xen + xenbranch=xen-unstable + '[' xxen = xlinux ']' + linuxbranch=linux + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg ++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.xen-unstable ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git ++ : daily-cron.xen-unstable + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git + info_linux_tree xen-unstable + case $1 in + return 1 + case "$branch" in + cd /export/home/osstest/repos/xen-unstable.hg + hg push -r 3eb9a891889a ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 1 changesets with 4 changes to 4 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat Oct 06 03:31:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 06 Oct 2012 03:31:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKL6L-0007fY-30; Sat, 06 Oct 2012 03:30:53 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKL6J-0007fT-Kn for xen-devel@lists.xensource.com; Sat, 06 Oct 2012 03:30:51 +0000 Received: from [85.158.143.99:9242] by server-1.bemta-4.messagelabs.com id 21/28-05684-AE5AF605; Sat, 06 Oct 2012 03:30:50 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1349494250!23460946!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMyNTM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4978 invoked from network); 6 Oct 2012 03:30:50 -0000 Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 6 Oct 2012 03:30:50 -0000 X-IronPort-AV: E=Sophos;i="4.80,543,1344211200"; d="scan'208";a="14976140" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 06 Oct 2012 03:30:43 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Sat, 6 Oct 2012 04:30:43 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TKL6A-0006Gu-P9; Sat, 06 Oct 2012 03:30:42 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1TKL6A-0000Gf-MA; Sat, 06 Oct 2012 04:30:42 +0100 To: Message-ID: From: xen.org Date: Sat, 6 Oct 2012 04:30:42 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 13928: tolerable FAIL - PUSHED X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 13928 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13928/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail like 13926 test-amd64-amd64-xl-sedf 5 xen-boot fail like 13926 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail like 13926 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail like 13926 Tests which did not succeed, but are not blocking: test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: xen 3eb9a891889a baseline version: xen 10277c76aed4 ------------------------------------------------------------ People who touched revisions under test: Anthony PERARD Ian Campbell Ian Jackson Matthew Fioravante ------------------------------------------------------------ jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-amd64-amd64-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable + revision=3eb9a891889a + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x '!=' x/export/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock ++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 3eb9a891889a + branch=xen-unstable + revision=3eb9a891889a + . cri-lock-repos ++ . cri-common +++ umask 002 +++ getconfig Repos +++ perl -e ' use Osstest; readconfigonly(); print $c{Repos} or die $!; ' ++ repos=/export/home/osstest/repos ++ repos_lock=/export/home/osstest/repos/lock ++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']' + . cri-common ++ umask 002 + select_xenbranch + case "$branch" in + tree=xen + xenbranch=xen-unstable + '[' xxen = xlinux ']' + linuxbranch=linux + : master + : tested/2.6.39.x + . ap-common ++ : xen@xenbits.xensource.com ++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg ++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : xen@xenbits.xensource.com:git/linux-pvops.git ++ : git://xenbits.xen.org/linux-pvops.git ++ : master ++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git ++ : tested/2.6.39.x ++ : daily-cron.xen-unstable ++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27 ++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git ++ : daily-cron.xen-unstable + TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git + TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git + info_linux_tree xen-unstable + case $1 in + return 1 + case "$branch" in + cd /export/home/osstest/repos/xen-unstable.hg + hg push -r 3eb9a891889a ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 1 changesets with 4 changes to 4 files _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat Oct 06 03:37:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 06 Oct 2012 03:37:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKLCB-0007vi-Dq; Sat, 06 Oct 2012 03:36:55 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKLCA-0007vd-Q4 for xen-devel@lists.xen.org; Sat, 06 Oct 2012 03:36:55 +0000 Received: from [85.158.139.211:13092] by server-13.bemta-5.messagelabs.com id 55/9C-06496-657AF605; Sat, 06 Oct 2012 03:36:54 +0000 X-Env-Sender: singapore.mr.teo.en.ming@gmail.com X-Msg-Ref: server-11.tower-206.messagelabs.com!1349494611!21283639!1 X-Originating-IP: [209.85.210.45] X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_60_70,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27139 invoked from network); 6 Oct 2012 03:36:53 -0000 Received: from mail-da0-f45.google.com (HELO mail-da0-f45.google.com) (209.85.210.45) by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 6 Oct 2012 03:36:53 -0000 Received: by mail-da0-f45.google.com with SMTP id n15so600680dad.32 for ; Fri, 05 Oct 2012 20:36:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:subject:references:in-reply-to:content-type; bh=GLPElwxTqTuwJLxyKxg7UOOEgfNlA/RlkmJSAbZxWJg=; b=TDU/M1c3o3zGXnmsIBHsle70TpE1A9h0W1mRuoGDpi4K8L0WUxZjml9DwemNr1amAm ZY6eftIxnzDLBuPxG9K1+BsZwnx59wkc2D1QJ0mLvnvEOY/ZxnYBj0hLG8gTNJ7m25av SAfDZQF4jQGu6NXpsqOd2g5pYoCpTEf6NUZ0WKmDbbIQr2EsYLaRUcw8+jb3LKLPRgPE sEoOi4SLndmzEqQwN+MgmO+uEcrOIr/h3t+5gcebeiFD/87Y2SnmwfBHythq3u12s1a0 +nwfEyMzwUD6BDDCEjMzINXpR5JFTAnKOX+jFqnkCgPbjPISATlW45grckthq/GZBWYr ZJQA== Received: by 10.68.83.68 with SMTP id o4mr36298256pby.25.1349494610455; Fri, 05 Oct 2012 20:36:50 -0700 (PDT) Received: from [192.168.1.2] (cm152.gamma205.maxonline.com.sg. [202.156.205.152]) by mx.google.com with ESMTPS id h8sm7001062pay.0.2012.10.05.20.36.48 (version=SSLv3 cipher=OTHER); Fri, 05 Oct 2012 20:36:49 -0700 (PDT) Message-ID: <506FA74E.8050706@gmail.com> Date: Sat, 06 Oct 2012 11:36:46 +0800 From: "Teo En Ming (Zhang Enming)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Dariusz Krempa , "xen-users@lists.xen.org" , "xen-devel@lists.xen.org" , "Teo En Ming (Zhang Enming)" , Ian Campbell , konrad@kernel.org References: <506E8BFD.9080504@gmail.com> <506F064F.9010705@gmail.com> <506F91BB.5080002@gmail.com> In-Reply-To: Subject: Re: [Xen-devel] Help Needed from Xen Developers: Nasty Yellow Triangle with Exclamation Mark and Error Code 43 in Device Manager in Windows 8 HVM domU X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1745709094667436486==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a multi-part message in MIME format. --===============1745709094667436486== Content-Type: multipart/alternative; boundary="------------020608090404090707050608" This is a multi-part message in MIME format. --------------020608090404090707050608 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 06/10/2012 10:13, Dariusz Krempa wrote: > > > 2012/10/6 Teo En Ming (Zhang Enming) > > > > On 06/10/2012 05:46, Dariusz Krempa wrote: > > > > > > Dear Dariusz Krempa, > > > > Even with Windows XP Home Edition SP3 HVM domU, I also get > the nasty yellow triangle with exclamation mark and error code 43. > > > > -- > > Yours sincerely, > > > > Mr. Teo En Ming (Zhang Enming) > > Singapore > > > > > Im just wondering. In last patch is 7 files to patch and in > tutorial from march You did was just 6. Maybe You missed that > additional file. There should work exact the same makings for > gtx560 like before for 4xx. > > > Dear Dariusz Krempa, > > I have just checked. I can confirm that there are only 6 patch > files from David Techer's personal website. How did you get 7 > patch files? May I know whose patch files did you use? > > wget > http://www.davidgis.fr/download/xen-4.2_rev24798_gfx-passthrough-patchs.tar.bz2 > tar xfvj xen-4.2_rev24798_gfx-passthrough-patchs.tar.bz2 > > > -- > Yours sincerely, > > Mr. Teo En Ming (Zhang Enming) > Singapore > > I am using last patches rev25240 > > wget > http://www.davidgis.fr/download/xen-4.2_rev25240_gfx-passthrough-patchs.tar.bz2 > > tar xfvj xen-4.2_rev25240_gfx-passthrough-patchs.tar.bz2 You mean there are 7 patch files in this patch set? Thanks! I will go and try it out. By the way, this patch set was not published by David Techer himself. The link you have given above was not published on his personal website. I have also observed one strange phenomenon. When it comes to Xen VGA Passthrough, no Xen developers appear to be willing to help. I have already provided full information, ie. configuration files and troubleshooting logs. -- Yours sincerely, Mr. Teo En Ming (Zhang Enming) Singapore --------------020608090404090707050608 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 06/10/2012 10:13, Dariusz Krempa wrote:


2012/10/6 Teo En Ming (Zhang Enming) <singapore.mr.teo.en.ming@gmail.com>
On 06/10/2012 05:46, Dariusz Krempa wrote:

>
> Dear Dariusz Krempa,
>
> Even with Windows XP Home Edition SP3 HVM domU, I also get the nasty yellow triangle with exclamation mark and error code 43.
>
> --
> Yours sincerely,
>
> Mr. Teo En Ming (Zhang Enming)
> Singapore
>
>
Im just wondering. In last patch is 7 files to patch and in tutorial from march You did was just 6. Maybe You missed that additional file. There should work exact the same makings for gtx560 like before for 4xx.

Dear Dariusz Krempa,

I have just checked. I can confirm that there are only 6 patch files from David Techer's personal website. How did you get 7 patch files? May I know whose patch files did you use?

wget http://www.davidgis.fr/download/xen-4.2_rev24798_gfx-passthrough-patchs.tar.bz2
tar xfvj xen-4.2_rev24798_gfx-passthrough-patchs.tar.bz2


--
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore

I am using last patches rev25240

wget http://www.davidgis.fr/download/xen-4.2_rev25240_gfx-passthrough-patchs.tar.bz2
tar xfvj xen-4.2_rev25240_gfx-passthrough-patchs.tar.bz2
You mean there are 7 patch files in this patch set? Thanks! I will go and try it out.

By the way, this patch set was not published by David Techer himself. The link you have given above was not published on his personal website.

I have also observed one strange phenomenon. When it comes to Xen VGA Passthrough, no Xen developers appear to be willing to help. I have already provided full information, ie. configuration files and troubleshooting logs.

-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore
--------------020608090404090707050608-- --===============1745709094667436486== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============1745709094667436486==-- From xen-devel-bounces@lists.xen.org Sat Oct 06 03:37:21 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 06 Oct 2012 03:37:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKLCB-0007vi-Dq; Sat, 06 Oct 2012 03:36:55 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKLCA-0007vd-Q4 for xen-devel@lists.xen.org; Sat, 06 Oct 2012 03:36:55 +0000 Received: from [85.158.139.211:13092] by server-13.bemta-5.messagelabs.com id 55/9C-06496-657AF605; Sat, 06 Oct 2012 03:36:54 +0000 X-Env-Sender: singapore.mr.teo.en.ming@gmail.com X-Msg-Ref: server-11.tower-206.messagelabs.com!1349494611!21283639!1 X-Originating-IP: [209.85.210.45] X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_60_70,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27139 invoked from network); 6 Oct 2012 03:36:53 -0000 Received: from mail-da0-f45.google.com (HELO mail-da0-f45.google.com) (209.85.210.45) by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 6 Oct 2012 03:36:53 -0000 Received: by mail-da0-f45.google.com with SMTP id n15so600680dad.32 for ; Fri, 05 Oct 2012 20:36:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:subject:references:in-reply-to:content-type; bh=GLPElwxTqTuwJLxyKxg7UOOEgfNlA/RlkmJSAbZxWJg=; b=TDU/M1c3o3zGXnmsIBHsle70TpE1A9h0W1mRuoGDpi4K8L0WUxZjml9DwemNr1amAm ZY6eftIxnzDLBuPxG9K1+BsZwnx59wkc2D1QJ0mLvnvEOY/ZxnYBj0hLG8gTNJ7m25av SAfDZQF4jQGu6NXpsqOd2g5pYoCpTEf6NUZ0WKmDbbIQr2EsYLaRUcw8+jb3LKLPRgPE sEoOi4SLndmzEqQwN+MgmO+uEcrOIr/h3t+5gcebeiFD/87Y2SnmwfBHythq3u12s1a0 +nwfEyMzwUD6BDDCEjMzINXpR5JFTAnKOX+jFqnkCgPbjPISATlW45grckthq/GZBWYr ZJQA== Received: by 10.68.83.68 with SMTP id o4mr36298256pby.25.1349494610455; Fri, 05 Oct 2012 20:36:50 -0700 (PDT) Received: from [192.168.1.2] (cm152.gamma205.maxonline.com.sg. [202.156.205.152]) by mx.google.com with ESMTPS id h8sm7001062pay.0.2012.10.05.20.36.48 (version=SSLv3 cipher=OTHER); Fri, 05 Oct 2012 20:36:49 -0700 (PDT) Message-ID: <506FA74E.8050706@gmail.com> Date: Sat, 06 Oct 2012 11:36:46 +0800 From: "Teo En Ming (Zhang Enming)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Dariusz Krempa , "xen-users@lists.xen.org" , "xen-devel@lists.xen.org" , "Teo En Ming (Zhang Enming)" , Ian Campbell , konrad@kernel.org References: <506E8BFD.9080504@gmail.com> <506F064F.9010705@gmail.com> <506F91BB.5080002@gmail.com> In-Reply-To: Subject: Re: [Xen-devel] Help Needed from Xen Developers: Nasty Yellow Triangle with Exclamation Mark and Error Code 43 in Device Manager in Windows 8 HVM domU X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1745709094667436486==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a multi-part message in MIME format. --===============1745709094667436486== Content-Type: multipart/alternative; boundary="------------020608090404090707050608" This is a multi-part message in MIME format. --------------020608090404090707050608 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 06/10/2012 10:13, Dariusz Krempa wrote: > > > 2012/10/6 Teo En Ming (Zhang Enming) > > > > On 06/10/2012 05:46, Dariusz Krempa wrote: > > > > > > Dear Dariusz Krempa, > > > > Even with Windows XP Home Edition SP3 HVM domU, I also get > the nasty yellow triangle with exclamation mark and error code 43. > > > > -- > > Yours sincerely, > > > > Mr. Teo En Ming (Zhang Enming) > > Singapore > > > > > Im just wondering. In last patch is 7 files to patch and in > tutorial from march You did was just 6. Maybe You missed that > additional file. There should work exact the same makings for > gtx560 like before for 4xx. > > > Dear Dariusz Krempa, > > I have just checked. I can confirm that there are only 6 patch > files from David Techer's personal website. How did you get 7 > patch files? May I know whose patch files did you use? > > wget > http://www.davidgis.fr/download/xen-4.2_rev24798_gfx-passthrough-patchs.tar.bz2 > tar xfvj xen-4.2_rev24798_gfx-passthrough-patchs.tar.bz2 > > > -- > Yours sincerely, > > Mr. Teo En Ming (Zhang Enming) > Singapore > > I am using last patches rev25240 > > wget > http://www.davidgis.fr/download/xen-4.2_rev25240_gfx-passthrough-patchs.tar.bz2 > > tar xfvj xen-4.2_rev25240_gfx-passthrough-patchs.tar.bz2 You mean there are 7 patch files in this patch set? Thanks! I will go and try it out. By the way, this patch set was not published by David Techer himself. The link you have given above was not published on his personal website. I have also observed one strange phenomenon. When it comes to Xen VGA Passthrough, no Xen developers appear to be willing to help. I have already provided full information, ie. configuration files and troubleshooting logs. -- Yours sincerely, Mr. Teo En Ming (Zhang Enming) Singapore --------------020608090404090707050608 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 06/10/2012 10:13, Dariusz Krempa wrote:


2012/10/6 Teo En Ming (Zhang Enming) <singapore.mr.teo.en.ming@gmail.com>
On 06/10/2012 05:46, Dariusz Krempa wrote:

>
> Dear Dariusz Krempa,
>
> Even with Windows XP Home Edition SP3 HVM domU, I also get the nasty yellow triangle with exclamation mark and error code 43.
>
> --
> Yours sincerely,
>
> Mr. Teo En Ming (Zhang Enming)
> Singapore
>
>
Im just wondering. In last patch is 7 files to patch and in tutorial from march You did was just 6. Maybe You missed that additional file. There should work exact the same makings for gtx560 like before for 4xx.

Dear Dariusz Krempa,

I have just checked. I can confirm that there are only 6 patch files from David Techer's personal website. How did you get 7 patch files? May I know whose patch files did you use?

wget http://www.davidgis.fr/download/xen-4.2_rev24798_gfx-passthrough-patchs.tar.bz2
tar xfvj xen-4.2_rev24798_gfx-passthrough-patchs.tar.bz2


--
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore

I am using last patches rev25240

wget http://www.davidgis.fr/download/xen-4.2_rev25240_gfx-passthrough-patchs.tar.bz2
tar xfvj xen-4.2_rev25240_gfx-passthrough-patchs.tar.bz2
You mean there are 7 patch files in this patch set? Thanks! I will go and try it out.

By the way, this patch set was not published by David Techer himself. The link you have given above was not published on his personal website.

I have also observed one strange phenomenon. When it comes to Xen VGA Passthrough, no Xen developers appear to be willing to help. I have already provided full information, ie. configuration files and troubleshooting logs.

-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore
--------------020608090404090707050608-- --===============1745709094667436486== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============1745709094667436486==-- From xen-devel-bounces@lists.xen.org Sat Oct 06 05:21:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 06 Oct 2012 05:21:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKMpG-0001He-65; Sat, 06 Oct 2012 05:21:22 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKMpE-0001HT-Rs for xen-devel@lists.xen.org; Sat, 06 Oct 2012 05:21:21 +0000 Received: from [85.158.143.35:42097] by server-1.bemta-4.messagelabs.com id AF/CD-05684-0DFBF605; Sat, 06 Oct 2012 05:21:20 +0000 X-Env-Sender: singapore.mr.teo.en.ming@gmail.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1349500875!13253649!1 X-Originating-IP: [209.85.210.45] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_50_60,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21827 invoked from network); 6 Oct 2012 05:21:18 -0000 Received: from mail-da0-f45.google.com (HELO mail-da0-f45.google.com) (209.85.210.45) by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 6 Oct 2012 05:21:18 -0000 Received: by mail-da0-f45.google.com with SMTP id n15so630567dad.32 for ; Fri, 05 Oct 2012 22:21:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type; bh=RIjlR5RepbucojkeAKi3osKzjbqyGCNWklfkpv2xo+4=; b=rxd1kckttobndOzMhrFYOVkyWHTcgjKzKg8gN6KoHVVnbvz0VV1423PjG3oTRZBjwN xl+tgDJPYyY641oUKLV46Eus9bSOxbzXs1EZl2+jpJ5Dx4JsbMaGy5cRQV7iAtGwCwnC AEjwX0x2drrH0aix72ilclZV+0ONFdGQ8elY7OKRTiCtUOqwZoMsAZt3Wj8cZHNip2Lb Pnjagykr17ztngaXwWxZpM0FM5dMSqPdUr33rtMN29HxmNmo4IUOs121xMj+0DMsMxZY oluXtn6H2TjkaZBZnoH1rIqoxK7xo8/vBANFKrEgVahKDRFVL3xUgi9jAFdt+QSPTEVZ IcRQ== Received: by 10.68.229.138 with SMTP id sq10mr36619345pbc.126.1349500875486; Fri, 05 Oct 2012 22:21:15 -0700 (PDT) Received: from [192.168.1.2] (cm152.gamma205.maxonline.com.sg. [202.156.205.152]) by mx.google.com with ESMTPS id uq5sm7130781pbc.56.2012.10.05.22.21.12 (version=SSLv3 cipher=OTHER); Fri, 05 Oct 2012 22:21:14 -0700 (PDT) Message-ID: <506FBFB8.7010209@gmail.com> Date: Sat, 06 Oct 2012 13:20:56 +0800 From: "Teo En Ming (Zhang Enming)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Teo En Ming (Zhang Enming)" References: <506E8BFD.9080504@gmail.com> <506F064F.9010705@gmail.com> <506F91BB.5080002@gmail.com> <506FA74E.8050706@gmail.com> In-Reply-To: <506FA74E.8050706@gmail.com> Cc: "xen-users@lists.xen.org" , "xen-devel@lists.xen.org" , konrad@kernel.org, Ian Campbell , Dariusz Krempa Subject: Re: [Xen-devel] Help Needed from Xen Developers: Nasty Yellow Triangle with Exclamation Mark and Error Code 43 in Device Manager in Windows 8 HVM domU X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============9125929640952181433==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a multi-part message in MIME format. --===============9125929640952181433== Content-Type: multipart/alternative; boundary="------------060400040806040302040008" This is a multi-part message in MIME format. --------------060400040806040302040008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 06/10/2012 11:36, Teo En Ming (Zhang Enming) wrote: > On 06/10/2012 10:13, Dariusz Krempa wrote: >> >> >> 2012/10/6 Teo En Ming (Zhang Enming) >> > > >> >> On 06/10/2012 05:46, Dariusz Krempa wrote: >> >> >> > >> > Dear Dariusz Krempa, >> > >> > Even with Windows XP Home Edition SP3 HVM domU, I also get >> the nasty yellow triangle with exclamation mark and error >> code 43. >> > >> > -- >> > Yours sincerely, >> > >> > Mr. Teo En Ming (Zhang Enming) >> > Singapore >> > >> > >> Im just wondering. In last patch is 7 files to patch and in >> tutorial from march You did was just 6. Maybe You missed that >> additional file. There should work exact the same makings for >> gtx560 like before for 4xx. >> >> >> Dear Dariusz Krempa, >> >> I have just checked. I can confirm that there are only 6 patch >> files from David Techer's personal website. How did you get 7 >> patch files? May I know whose patch files did you use? >> >> wget >> http://www.davidgis.fr/download/xen-4.2_rev24798_gfx-passthrough-patchs.tar.bz2 >> tar xfvj xen-4.2_rev24798_gfx-passthrough-patchs.tar.bz2 >> >> >> -- >> Yours sincerely, >> >> Mr. Teo En Ming (Zhang Enming) >> Singapore >> >> I am using last patches rev25240 >> >> wget >> http://www.davidgis.fr/download/xen-4.2_rev25240_gfx-passthrough-patchs.tar.bz2 >> >> tar xfvj xen-4.2_rev25240_gfx-passthrough-patchs.tar.bz2 > You mean there are 7 patch files in this patch set? Thanks! I will go > and try it out. > > By the way, this patch set was not published by David Techer himself. > The link you have given above was not published on his personal website. > > I have also observed one strange phenomenon. When it comes to Xen VGA > Passthrough, no Xen developers appear to be willing to help. I have > already provided full information, ie. configuration files and > troubleshooting logs. > > -- > Yours sincerely, > > Mr. Teo En Ming (Zhang Enming) > Singapore Dear Dariusz Krempa, I have used patch set 25240 from David Techer's personal website as you have recommended and applied it to Xen 4.2.1-pre. Now I am able to get *PARTIAL SUCCESS* with Xen 4.2.1-pre but there is still this nasty yellow triangle with exclamation mark and error code 43. Could you carefully look through my manual/tutorial/guide for me and see what is missing from my manual. BUT, using the same manual/tutorial/guide that I have written, I was able to get 100% success with Frank Lyon's Xen VGA Passthrough server. There is no nasty yellow triangle with exclamation mark and error code 43 in Frank Lyon's case. Just what is wrong with my setup?!?!?! By the way, patch set 25240 is for Xen 4.2-unstable changset 25099 and above. -- Yours sincerely, Mr. Teo En Ming (Zhang Enming) Singapore --------------060400040806040302040008 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 06/10/2012 11:36, Teo En Ming (Zhang Enming) wrote:
On 06/10/2012 10:13, Dariusz Krempa wrote:


2012/10/6 Teo En Ming (Zhang Enming) <singapore.mr.teo.en.ming@gmail.com>
On 06/10/2012 05:46, Dariusz Krempa wrote:

>
> Dear Dariusz Krempa,
>
> Even with Windows XP Home Edition SP3 HVM domU, I also get the nasty yellow triangle with exclamation mark and error code 43.
>
> --
> Yours sincerely,
>
> Mr. Teo En Ming (Zhang Enming)
> Singapore
>
>
Im just wondering. In last patch is 7 files to patch and in tutorial from march You did was just 6. Maybe You missed that additional file. There should work exact the same makings for gtx560 like before for 4xx.

Dear Dariusz Krempa,

I have just checked. I can confirm that there are only 6 patch files from David Techer's personal website. How did you get 7 patch files? May I know whose patch files did you use?

wget http://www.davidgis.fr/download/xen-4.2_rev24798_gfx-passthrough-patchs.tar.bz2
tar xfvj xen-4.2_rev24798_gfx-passthrough-patchs.tar.bz2


--
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore

I am using last patches rev25240

wget http://www.davidgis.fr/download/xen-4.2_rev25240_gfx-passthrough-patchs.tar.bz2
tar xfvj xen-4.2_rev25240_gfx-passthrough-patchs.tar.bz2
You mean there are 7 patch files in this patch set? Thanks! I will go and try it out.

By the way, this patch set was not published by David Techer himself. The link you have given above was not published on his personal website.

I have also observed one strange phenomenon. When it comes to Xen VGA Passthrough, no Xen developers appear to be willing to help. I have already provided full information, ie. configuration files and troubleshooting logs.

-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore

Dear Dariusz Krempa,

I have used patch set 25240 from David Techer's personal website as you have recommended and applied it to Xen 4.2.1-pre. Now I am able to get *PARTIAL SUCCESS* with Xen 4.2.1-pre but there is still this nasty yellow triangle with exclamation mark and error code 43.

Could you carefully look through my manual/tutorial/guide for me and see what is missing from my manual. BUT, using the same manual/tutorial/guide that I have written, I was able to get 100% success with Frank Lyon's Xen VGA Passthrough server. There is no nasty yellow triangle with exclamation mark and error code 43 in Frank Lyon's case.

Just what is wrong with my setup?!?!?!

By the way, patch set 25240 is for Xen 4.2-unstable changset 25099 and above.
-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore
--------------060400040806040302040008-- --===============9125929640952181433== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============9125929640952181433==-- From xen-devel-bounces@lists.xen.org Sat Oct 06 05:21:47 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 06 Oct 2012 05:21:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKMpG-0001He-65; Sat, 06 Oct 2012 05:21:22 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKMpE-0001HT-Rs for xen-devel@lists.xen.org; Sat, 06 Oct 2012 05:21:21 +0000 Received: from [85.158.143.35:42097] by server-1.bemta-4.messagelabs.com id AF/CD-05684-0DFBF605; Sat, 06 Oct 2012 05:21:20 +0000 X-Env-Sender: singapore.mr.teo.en.ming@gmail.com X-Msg-Ref: server-12.tower-21.messagelabs.com!1349500875!13253649!1 X-Originating-IP: [209.85.210.45] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_50_60,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21827 invoked from network); 6 Oct 2012 05:21:18 -0000 Received: from mail-da0-f45.google.com (HELO mail-da0-f45.google.com) (209.85.210.45) by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 6 Oct 2012 05:21:18 -0000 Received: by mail-da0-f45.google.com with SMTP id n15so630567dad.32 for ; Fri, 05 Oct 2012 22:21:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type; bh=RIjlR5RepbucojkeAKi3osKzjbqyGCNWklfkpv2xo+4=; b=rxd1kckttobndOzMhrFYOVkyWHTcgjKzKg8gN6KoHVVnbvz0VV1423PjG3oTRZBjwN xl+tgDJPYyY641oUKLV46Eus9bSOxbzXs1EZl2+jpJ5Dx4JsbMaGy5cRQV7iAtGwCwnC AEjwX0x2drrH0aix72ilclZV+0ONFdGQ8elY7OKRTiCtUOqwZoMsAZt3Wj8cZHNip2Lb Pnjagykr17ztngaXwWxZpM0FM5dMSqPdUr33rtMN29HxmNmo4IUOs121xMj+0DMsMxZY oluXtn6H2TjkaZBZnoH1rIqoxK7xo8/vBANFKrEgVahKDRFVL3xUgi9jAFdt+QSPTEVZ IcRQ== Received: by 10.68.229.138 with SMTP id sq10mr36619345pbc.126.1349500875486; Fri, 05 Oct 2012 22:21:15 -0700 (PDT) Received: from [192.168.1.2] (cm152.gamma205.maxonline.com.sg. [202.156.205.152]) by mx.google.com with ESMTPS id uq5sm7130781pbc.56.2012.10.05.22.21.12 (version=SSLv3 cipher=OTHER); Fri, 05 Oct 2012 22:21:14 -0700 (PDT) Message-ID: <506FBFB8.7010209@gmail.com> Date: Sat, 06 Oct 2012 13:20:56 +0800 From: "Teo En Ming (Zhang Enming)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Teo En Ming (Zhang Enming)" References: <506E8BFD.9080504@gmail.com> <506F064F.9010705@gmail.com> <506F91BB.5080002@gmail.com> <506FA74E.8050706@gmail.com> In-Reply-To: <506FA74E.8050706@gmail.com> Cc: "xen-users@lists.xen.org" , "xen-devel@lists.xen.org" , konrad@kernel.org, Ian Campbell , Dariusz Krempa Subject: Re: [Xen-devel] Help Needed from Xen Developers: Nasty Yellow Triangle with Exclamation Mark and Error Code 43 in Device Manager in Windows 8 HVM domU X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============9125929640952181433==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a multi-part message in MIME format. --===============9125929640952181433== Content-Type: multipart/alternative; boundary="------------060400040806040302040008" This is a multi-part message in MIME format. --------------060400040806040302040008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 06/10/2012 11:36, Teo En Ming (Zhang Enming) wrote: > On 06/10/2012 10:13, Dariusz Krempa wrote: >> >> >> 2012/10/6 Teo En Ming (Zhang Enming) >> > > >> >> On 06/10/2012 05:46, Dariusz Krempa wrote: >> >> >> > >> > Dear Dariusz Krempa, >> > >> > Even with Windows XP Home Edition SP3 HVM domU, I also get >> the nasty yellow triangle with exclamation mark and error >> code 43. >> > >> > -- >> > Yours sincerely, >> > >> > Mr. Teo En Ming (Zhang Enming) >> > Singapore >> > >> > >> Im just wondering. In last patch is 7 files to patch and in >> tutorial from march You did was just 6. Maybe You missed that >> additional file. There should work exact the same makings for >> gtx560 like before for 4xx. >> >> >> Dear Dariusz Krempa, >> >> I have just checked. I can confirm that there are only 6 patch >> files from David Techer's personal website. How did you get 7 >> patch files? May I know whose patch files did you use? >> >> wget >> http://www.davidgis.fr/download/xen-4.2_rev24798_gfx-passthrough-patchs.tar.bz2 >> tar xfvj xen-4.2_rev24798_gfx-passthrough-patchs.tar.bz2 >> >> >> -- >> Yours sincerely, >> >> Mr. Teo En Ming (Zhang Enming) >> Singapore >> >> I am using last patches rev25240 >> >> wget >> http://www.davidgis.fr/download/xen-4.2_rev25240_gfx-passthrough-patchs.tar.bz2 >> >> tar xfvj xen-4.2_rev25240_gfx-passthrough-patchs.tar.bz2 > You mean there are 7 patch files in this patch set? Thanks! I will go > and try it out. > > By the way, this patch set was not published by David Techer himself. > The link you have given above was not published on his personal website. > > I have also observed one strange phenomenon. When it comes to Xen VGA > Passthrough, no Xen developers appear to be willing to help. I have > already provided full information, ie. configuration files and > troubleshooting logs. > > -- > Yours sincerely, > > Mr. Teo En Ming (Zhang Enming) > Singapore Dear Dariusz Krempa, I have used patch set 25240 from David Techer's personal website as you have recommended and applied it to Xen 4.2.1-pre. Now I am able to get *PARTIAL SUCCESS* with Xen 4.2.1-pre but there is still this nasty yellow triangle with exclamation mark and error code 43. Could you carefully look through my manual/tutorial/guide for me and see what is missing from my manual. BUT, using the same manual/tutorial/guide that I have written, I was able to get 100% success with Frank Lyon's Xen VGA Passthrough server. There is no nasty yellow triangle with exclamation mark and error code 43 in Frank Lyon's case. Just what is wrong with my setup?!?!?! By the way, patch set 25240 is for Xen 4.2-unstable changset 25099 and above. -- Yours sincerely, Mr. Teo En Ming (Zhang Enming) Singapore --------------060400040806040302040008 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 06/10/2012 11:36, Teo En Ming (Zhang Enming) wrote:
On 06/10/2012 10:13, Dariusz Krempa wrote:


2012/10/6 Teo En Ming (Zhang Enming) <singapore.mr.teo.en.ming@gmail.com>
On 06/10/2012 05:46, Dariusz Krempa wrote:

>
> Dear Dariusz Krempa,
>
> Even with Windows XP Home Edition SP3 HVM domU, I also get the nasty yellow triangle with exclamation mark and error code 43.
>
> --
> Yours sincerely,
>
> Mr. Teo En Ming (Zhang Enming)
> Singapore
>
>
Im just wondering. In last patch is 7 files to patch and in tutorial from march You did was just 6. Maybe You missed that additional file. There should work exact the same makings for gtx560 like before for 4xx.

Dear Dariusz Krempa,

I have just checked. I can confirm that there are only 6 patch files from David Techer's personal website. How did you get 7 patch files? May I know whose patch files did you use?

wget http://www.davidgis.fr/download/xen-4.2_rev24798_gfx-passthrough-patchs.tar.bz2
tar xfvj xen-4.2_rev24798_gfx-passthrough-patchs.tar.bz2


--
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore

I am using last patches rev25240

wget http://www.davidgis.fr/download/xen-4.2_rev25240_gfx-passthrough-patchs.tar.bz2
tar xfvj xen-4.2_rev25240_gfx-passthrough-patchs.tar.bz2
You mean there are 7 patch files in this patch set? Thanks! I will go and try it out.

By the way, this patch set was not published by David Techer himself. The link you have given above was not published on his personal website.

I have also observed one strange phenomenon. When it comes to Xen VGA Passthrough, no Xen developers appear to be willing to help. I have already provided full information, ie. configuration files and troubleshooting logs.

-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore

Dear Dariusz Krempa,

I have used patch set 25240 from David Techer's personal website as you have recommended and applied it to Xen 4.2.1-pre. Now I am able to get *PARTIAL SUCCESS* with Xen 4.2.1-pre but there is still this nasty yellow triangle with exclamation mark and error code 43.

Could you carefully look through my manual/tutorial/guide for me and see what is missing from my manual. BUT, using the same manual/tutorial/guide that I have written, I was able to get 100% success with Frank Lyon's Xen VGA Passthrough server. There is no nasty yellow triangle with exclamation mark and error code 43 in Frank Lyon's case.

Just what is wrong with my setup?!?!?!

By the way, patch set 25240 is for Xen 4.2-unstable changset 25099 and above.
-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore
--------------060400040806040302040008-- --===============9125929640952181433== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============9125929640952181433==-- From xen-devel-bounces@lists.xen.org Sat Oct 06 06:23:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 06 Oct 2012 06:23:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKNmO-00021G-Re; Sat, 06 Oct 2012 06:22:28 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKNmN-000217-Go for xen-devel@lists.xen.org; Sat, 06 Oct 2012 06:22:27 +0000 Received: from [85.158.138.51:29691] by server-13.bemta-3.messagelabs.com id F2/88-28885-22ECF605; Sat, 06 Oct 2012 06:22:26 +0000 X-Env-Sender: singapore.mr.teo.en.ming@gmail.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1349504544!24429121!1 X-Originating-IP: [209.85.160.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3142 invoked from network); 6 Oct 2012 06:22:26 -0000 Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com) (209.85.160.45) by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 6 Oct 2012 06:22:26 -0000 Received: by mail-pb0-f45.google.com with SMTP id rp2so2648766pbb.32 for ; Fri, 05 Oct 2012 23:22:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8Bny612c44QBcy4J58xZTKpDPOThH9RUpvid9gm2bEI=; b=bIHzJwXBo3jgT3bq5+WzejKjmeJgQBsorUGViy6zYHCoiiHlodXqQ6WCo5riKP4PwK 0hU2x9y/9cI5TAVWgihii+yKk8WoAtsNKM0rfHqSP8DwQexJmPq0RntfAG+/Q0LYjQHX 4txyWX7N6lhe2EHX1GBXF3UsKIZMMYid5ezGjxqBE/HwalnoDFx+ag8ofgjHBdLl/z4W CVaPITArgsgViGSxFmBirrKNDq8KeqlESTQBpJEImun+0WASuUEFKMWX0g79XEzNtzh1 u9FgCVE128NXt57zAzmPtzoGE9USElSuv5IOsXtJpghQ8lrkohARgQuZLc3E1tPUUTyz OE7Q== Received: by 10.68.132.41 with SMTP id or9mr37092580pbb.67.1349504543634; Fri, 05 Oct 2012 23:22:23 -0700 (PDT) Received: from [192.168.1.2] (cm152.gamma205.maxonline.com.sg. [202.156.205.152]) by mx.google.com with ESMTPS id nu8sm7203760pbc.45.2012.10.05.23.22.21 (version=SSLv3 cipher=OTHER); Fri, 05 Oct 2012 23:22:23 -0700 (PDT) Message-ID: <506FCE1C.5010802@gmail.com> Date: Sat, 06 Oct 2012 14:22:20 +0800 From: "Teo En Ming (Zhang Enming)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Dariusz Krempa , "xen-users@lists.xen.org" , "xen-devel@lists.xen.org" , "Teo En Ming (Zhang Enming)" , Frank Lyon References: <506E8BFD.9080504@gmail.com> <506F064F.9010705@gmail.com> <506F91BB.5080002@gmail.com> <506FA74E.8050706@gmail.com> In-Reply-To: Subject: Re: [Xen-devel] Help Needed from Xen Developers: Nasty Yellow Triangle with Exclamation Mark and Error Code 43 in Device Manager in Windows 8 HVM domU X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 06/10/2012 13:25, Dariusz Krempa wrote: > > > > > You mean there are 7 patch files in this patch set? Thanks! I will > go and try it out. > > > > By the way, this patch set was not published by David Techer > himself. The link you have given above was not published on his > personal website. > > > > I have also observed one strange phenomenon. When it comes to Xen > VGA Passthrough, no Xen developers appear to be willing to help. I > have already provided full information, ie. configuration files and > troubleshooting logs. > > > > -- > > Yours sincerely, > > > > Mr. Teo En Ming (Zhang Enming) > > Singapore > > This patch was published on David's website but it was just short > note. It still is link on left side with other shortcuts to last news. > About devs, they just dont bother about gtx vga passthrough cause its > not pro card and with quadro and tesla there is no problem. No wonder I have no problems with Frank Lyon's NVIDIA Quadro 6000 at all. Complete 100% success. -- Yours sincerely, Mr. Teo En Ming (Zhang Enming) Singapore _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat Oct 06 06:23:04 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 06 Oct 2012 06:23:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKNmO-00021G-Re; Sat, 06 Oct 2012 06:22:28 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKNmN-000217-Go for xen-devel@lists.xen.org; Sat, 06 Oct 2012 06:22:27 +0000 Received: from [85.158.138.51:29691] by server-13.bemta-3.messagelabs.com id F2/88-28885-22ECF605; Sat, 06 Oct 2012 06:22:26 +0000 X-Env-Sender: singapore.mr.teo.en.ming@gmail.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1349504544!24429121!1 X-Originating-IP: [209.85.160.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3142 invoked from network); 6 Oct 2012 06:22:26 -0000 Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com) (209.85.160.45) by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 6 Oct 2012 06:22:26 -0000 Received: by mail-pb0-f45.google.com with SMTP id rp2so2648766pbb.32 for ; Fri, 05 Oct 2012 23:22:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8Bny612c44QBcy4J58xZTKpDPOThH9RUpvid9gm2bEI=; b=bIHzJwXBo3jgT3bq5+WzejKjmeJgQBsorUGViy6zYHCoiiHlodXqQ6WCo5riKP4PwK 0hU2x9y/9cI5TAVWgihii+yKk8WoAtsNKM0rfHqSP8DwQexJmPq0RntfAG+/Q0LYjQHX 4txyWX7N6lhe2EHX1GBXF3UsKIZMMYid5ezGjxqBE/HwalnoDFx+ag8ofgjHBdLl/z4W CVaPITArgsgViGSxFmBirrKNDq8KeqlESTQBpJEImun+0WASuUEFKMWX0g79XEzNtzh1 u9FgCVE128NXt57zAzmPtzoGE9USElSuv5IOsXtJpghQ8lrkohARgQuZLc3E1tPUUTyz OE7Q== Received: by 10.68.132.41 with SMTP id or9mr37092580pbb.67.1349504543634; Fri, 05 Oct 2012 23:22:23 -0700 (PDT) Received: from [192.168.1.2] (cm152.gamma205.maxonline.com.sg. [202.156.205.152]) by mx.google.com with ESMTPS id nu8sm7203760pbc.45.2012.10.05.23.22.21 (version=SSLv3 cipher=OTHER); Fri, 05 Oct 2012 23:22:23 -0700 (PDT) Message-ID: <506FCE1C.5010802@gmail.com> Date: Sat, 06 Oct 2012 14:22:20 +0800 From: "Teo En Ming (Zhang Enming)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Dariusz Krempa , "xen-users@lists.xen.org" , "xen-devel@lists.xen.org" , "Teo En Ming (Zhang Enming)" , Frank Lyon References: <506E8BFD.9080504@gmail.com> <506F064F.9010705@gmail.com> <506F91BB.5080002@gmail.com> <506FA74E.8050706@gmail.com> In-Reply-To: Subject: Re: [Xen-devel] Help Needed from Xen Developers: Nasty Yellow Triangle with Exclamation Mark and Error Code 43 in Device Manager in Windows 8 HVM domU X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 06/10/2012 13:25, Dariusz Krempa wrote: > > > > > You mean there are 7 patch files in this patch set? Thanks! I will > go and try it out. > > > > By the way, this patch set was not published by David Techer > himself. The link you have given above was not published on his > personal website. > > > > I have also observed one strange phenomenon. When it comes to Xen > VGA Passthrough, no Xen developers appear to be willing to help. I > have already provided full information, ie. configuration files and > troubleshooting logs. > > > > -- > > Yours sincerely, > > > > Mr. Teo En Ming (Zhang Enming) > > Singapore > > This patch was published on David's website but it was just short > note. It still is link on left side with other shortcuts to last news. > About devs, they just dont bother about gtx vga passthrough cause its > not pro card and with quadro and tesla there is no problem. No wonder I have no problems with Frank Lyon's NVIDIA Quadro 6000 at all. Complete 100% success. -- Yours sincerely, Mr. Teo En Ming (Zhang Enming) Singapore _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat Oct 06 06:32:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 06 Oct 2012 06:32:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKNvm-0002UL-UJ; Sat, 06 Oct 2012 06:32:10 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKNvl-0002U8-C6 for xen-devel@lists.xen.org; Sat, 06 Oct 2012 06:32:09 +0000 Received: from [85.158.138.51:43345] by server-2.bemta-3.messagelabs.com id 8F/68-16514-860DF605; Sat, 06 Oct 2012 06:32:08 +0000 X-Env-Sender: singapore.mr.teo.en.ming@gmail.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1349505125!32808276!1 X-Originating-IP: [209.85.160.45] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7191 invoked from network); 6 Oct 2012 06:32:07 -0000 Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com) (209.85.160.45) by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 6 Oct 2012 06:32:07 -0000 Received: by mail-pb0-f45.google.com with SMTP id rp2so2653190pbb.32 for ; Fri, 05 Oct 2012 23:32:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:subject:references:in-reply-to:content-type; bh=aqdB0L68Ge+l2WFEMPzxVi+24yPko84TWktHXX6CbDI=; b=dIz+hnGTVnGMz4RIpiaSetujRNAp+EqbvkA6KUBNHnDSm9soYSygZylS/h4WjSCGmh u3QSFANldkVzkbKAzp+MgfKG5k8Oq4Sm3Al/CmFAa3rWTJt7B1OBCwr3CCt5uoa9ZARF PPgbyEYchkQIKji6pU3gXtw/coIhh1B+2TQkucAqtL9sQW9tlBUBbEKHsvfBWlL5Zp2+ 5N0pBp2TKAFP+dSrd75VezzEAmZjf+zHsW/nnMj/4T85SmZU+T/V+0Gb4jrj41a60v94 PhN0lSaVaepIuP3VNdw0l8+z4BTY3eM+Y4oP9GgdkKz27EpiULOqBwCMzHLw0uK20hI4 nMfQ== Received: by 10.68.189.5 with SMTP id ge5mr24492089pbc.1.1349505125062; Fri, 05 Oct 2012 23:32:05 -0700 (PDT) Received: from [192.168.1.2] (cm152.gamma205.maxonline.com.sg. [202.156.205.152]) by mx.google.com with ESMTPS id kp3sm7213781pbc.64.2012.10.05.23.32.02 (version=SSLv3 cipher=OTHER); Fri, 05 Oct 2012 23:32:04 -0700 (PDT) Message-ID: <506FD061.10206@gmail.com> Date: Sat, 06 Oct 2012 14:32:01 +0800 From: "Teo En Ming (Zhang Enming)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Dariusz Krempa , Frank Lyon , "xen-users@lists.xen.org" , "xen-devel@lists.xen.org" , "Teo En Ming (Zhang Enming)" References: <506E8BFD.9080504@gmail.com> <506F064F.9010705@gmail.com> <506F91BB.5080002@gmail.com> <506FA74E.8050706@gmail.com> <506FBFB8.7010209@gmail.com> In-Reply-To: Subject: Re: [Xen-devel] Help Needed from Xen Developers: Nasty Yellow Triangle with Exclamation Mark and Error Code 43 in Device Manager in Windows 8 HVM domU X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7582806588642359606==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a multi-part message in MIME format. --===============7582806588642359606== Content-Type: multipart/alternative; boundary="------------060505090001040305030000" This is a multi-part message in MIME format. --------------060505090001040305030000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 06/10/2012 13:55, Dariusz Krempa wrote: > > > Could you carefully look through my manual/tutorial/guide for me > and see what is missing from my manual. BUT, using the same > manual/tutorial/guide that I have written, I was able to get 100% > success with Frank Lyon's Xen VGA Passthrough server. There is no > nasty yellow triangle with exclamation mark and error code 43 in > Frank Lyon's case. > > Just what is wrong with my setup?!?!?! > > > When I started with Xen and linux about 3 weeks ago I found Yours > manuals in pdf. My first steps was simple copy paste. Later I realized > that for me not whole manual is needed and in this moment im using: > - to build kernel points 1-5, but without modified /etc/modules > -- in this moment Im using kernel 3.6-rc7 instead 3.3-rc7 > -- in config I set all *XEN* for y > - to build xen from sources (I also copy-pasted at start from Xen > manual from You and from David's website): > -- apt-get install texinfo git-core libglib2.0-dev libyajl-dev > build-essential vncviewer bridge-utils mercurial > -- apt-get build-dep xen > -- patch rev25240 > > Also Im using pciback instead stub, cause Im having problems with > stub. It report me errors (missing files). > This is all what I need to start hvm. Now like I said before first I > install windows without vga passthrough (its because 1 gfx also with > problems with usb drivers under windows). When I have windows ready Im > passing pci with vga to hvm and Im installing nvidia drivers 275.33 > or 275.50 and when it is done Im setting gfx_passthrough=1 in DomU > config. Isn't it gfx_passthru=1 instead of gfx_passthrough=1? I believe your syntax is wrong. What a joke man! I can only get Frank Lyon's NVIDIA Quadro 6000 VGA Passthrough completely 100% working but I cannot get 100% success for my own display cards. I have been trying a lot of things but still cannot get rid of the yellow triangle with exclamation mark and error code 43. Frank Lyon's NVIDIA Quadro 6000 costs S$6000++ and I can't afford that. -- Yours sincerely, Mr. Teo En Ming (Zhang Enming) Singapore --------------060505090001040305030000 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 06/10/2012 13:55, Dariusz Krempa wrote:


Could you carefully look through my manual/tutorial/guide for me and see what is missing from my manual. BUT, using the same manual/tutorial/guide that I have written, I was able to get 100% success with Frank Lyon's Xen VGA Passthrough server. There is no nasty yellow triangle with exclamation mark and error code 43 in Frank Lyon's case.

Just what is wrong with my setup?!?!?!
 

When I started with Xen and linux about 3 weeks ago I found Yours manuals in pdf. My first steps was simple copy paste. Later I realized that for me not whole manual is needed and in this moment im using:
- to build kernel points 1-5, but without modified /etc/modules 
-- in this moment Im using kernel 3.6-rc7 instead 3.3-rc7
-- in config I set all *XEN* for y
- to build xen from sources (I also copy-pasted at start from Xen manual from You and from David's website):
-- apt-get install texinfo git-core libglib2.0-dev libyajl-dev build-essential vncviewer bridge-utils mercurial
-- apt-get build-dep xen
-- patch rev25240 

Also Im using pciback instead stub, cause Im having problems with stub. It report me errors (missing files).
This is all what I need to start hvm. Now like I said before first I install windows without vga passthrough (its because 1 gfx also with problems with usb drivers under windows). When I have windows ready Im passing pci  with vga to hvm and Im installing nvidia drivers 275.33 or 275.50 and when it is done Im setting gfx_passthrough=1 in DomU config. 

Isn't it gfx_passthru=1 instead of gfx_passthrough=1? I believe your syntax is wrong.

What a joke man! I can only get Frank Lyon's NVIDIA Quadro 6000 VGA Passthrough completely 100% working but I cannot get 100% success for my own display cards. I have been trying a lot of things but still cannot get rid of the yellow triangle with exclamation mark and error code 43. Frank Lyon's NVIDIA Quadro 6000 costs S$6000++ and I can't afford that.
-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore
--------------060505090001040305030000-- --===============7582806588642359606== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============7582806588642359606==-- From xen-devel-bounces@lists.xen.org Sat Oct 06 06:32:35 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 06 Oct 2012 06:32:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKNvm-0002UL-UJ; Sat, 06 Oct 2012 06:32:10 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKNvl-0002U8-C6 for xen-devel@lists.xen.org; Sat, 06 Oct 2012 06:32:09 +0000 Received: from [85.158.138.51:43345] by server-2.bemta-3.messagelabs.com id 8F/68-16514-860DF605; Sat, 06 Oct 2012 06:32:08 +0000 X-Env-Sender: singapore.mr.teo.en.ming@gmail.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1349505125!32808276!1 X-Originating-IP: [209.85.160.45] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7191 invoked from network); 6 Oct 2012 06:32:07 -0000 Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com) (209.85.160.45) by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 6 Oct 2012 06:32:07 -0000 Received: by mail-pb0-f45.google.com with SMTP id rp2so2653190pbb.32 for ; Fri, 05 Oct 2012 23:32:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:subject:references:in-reply-to:content-type; bh=aqdB0L68Ge+l2WFEMPzxVi+24yPko84TWktHXX6CbDI=; b=dIz+hnGTVnGMz4RIpiaSetujRNAp+EqbvkA6KUBNHnDSm9soYSygZylS/h4WjSCGmh u3QSFANldkVzkbKAzp+MgfKG5k8Oq4Sm3Al/CmFAa3rWTJt7B1OBCwr3CCt5uoa9ZARF PPgbyEYchkQIKji6pU3gXtw/coIhh1B+2TQkucAqtL9sQW9tlBUBbEKHsvfBWlL5Zp2+ 5N0pBp2TKAFP+dSrd75VezzEAmZjf+zHsW/nnMj/4T85SmZU+T/V+0Gb4jrj41a60v94 PhN0lSaVaepIuP3VNdw0l8+z4BTY3eM+Y4oP9GgdkKz27EpiULOqBwCMzHLw0uK20hI4 nMfQ== Received: by 10.68.189.5 with SMTP id ge5mr24492089pbc.1.1349505125062; Fri, 05 Oct 2012 23:32:05 -0700 (PDT) Received: from [192.168.1.2] (cm152.gamma205.maxonline.com.sg. [202.156.205.152]) by mx.google.com with ESMTPS id kp3sm7213781pbc.64.2012.10.05.23.32.02 (version=SSLv3 cipher=OTHER); Fri, 05 Oct 2012 23:32:04 -0700 (PDT) Message-ID: <506FD061.10206@gmail.com> Date: Sat, 06 Oct 2012 14:32:01 +0800 From: "Teo En Ming (Zhang Enming)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Dariusz Krempa , Frank Lyon , "xen-users@lists.xen.org" , "xen-devel@lists.xen.org" , "Teo En Ming (Zhang Enming)" References: <506E8BFD.9080504@gmail.com> <506F064F.9010705@gmail.com> <506F91BB.5080002@gmail.com> <506FA74E.8050706@gmail.com> <506FBFB8.7010209@gmail.com> In-Reply-To: Subject: Re: [Xen-devel] Help Needed from Xen Developers: Nasty Yellow Triangle with Exclamation Mark and Error Code 43 in Device Manager in Windows 8 HVM domU X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7582806588642359606==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a multi-part message in MIME format. --===============7582806588642359606== Content-Type: multipart/alternative; boundary="------------060505090001040305030000" This is a multi-part message in MIME format. --------------060505090001040305030000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 06/10/2012 13:55, Dariusz Krempa wrote: > > > Could you carefully look through my manual/tutorial/guide for me > and see what is missing from my manual. BUT, using the same > manual/tutorial/guide that I have written, I was able to get 100% > success with Frank Lyon's Xen VGA Passthrough server. There is no > nasty yellow triangle with exclamation mark and error code 43 in > Frank Lyon's case. > > Just what is wrong with my setup?!?!?! > > > When I started with Xen and linux about 3 weeks ago I found Yours > manuals in pdf. My first steps was simple copy paste. Later I realized > that for me not whole manual is needed and in this moment im using: > - to build kernel points 1-5, but without modified /etc/modules > -- in this moment Im using kernel 3.6-rc7 instead 3.3-rc7 > -- in config I set all *XEN* for y > - to build xen from sources (I also copy-pasted at start from Xen > manual from You and from David's website): > -- apt-get install texinfo git-core libglib2.0-dev libyajl-dev > build-essential vncviewer bridge-utils mercurial > -- apt-get build-dep xen > -- patch rev25240 > > Also Im using pciback instead stub, cause Im having problems with > stub. It report me errors (missing files). > This is all what I need to start hvm. Now like I said before first I > install windows without vga passthrough (its because 1 gfx also with > problems with usb drivers under windows). When I have windows ready Im > passing pci with vga to hvm and Im installing nvidia drivers 275.33 > or 275.50 and when it is done Im setting gfx_passthrough=1 in DomU > config. Isn't it gfx_passthru=1 instead of gfx_passthrough=1? I believe your syntax is wrong. What a joke man! I can only get Frank Lyon's NVIDIA Quadro 6000 VGA Passthrough completely 100% working but I cannot get 100% success for my own display cards. I have been trying a lot of things but still cannot get rid of the yellow triangle with exclamation mark and error code 43. Frank Lyon's NVIDIA Quadro 6000 costs S$6000++ and I can't afford that. -- Yours sincerely, Mr. Teo En Ming (Zhang Enming) Singapore --------------060505090001040305030000 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 06/10/2012 13:55, Dariusz Krempa wrote:


Could you carefully look through my manual/tutorial/guide for me and see what is missing from my manual. BUT, using the same manual/tutorial/guide that I have written, I was able to get 100% success with Frank Lyon's Xen VGA Passthrough server. There is no nasty yellow triangle with exclamation mark and error code 43 in Frank Lyon's case.

Just what is wrong with my setup?!?!?!
 

When I started with Xen and linux about 3 weeks ago I found Yours manuals in pdf. My first steps was simple copy paste. Later I realized that for me not whole manual is needed and in this moment im using:
- to build kernel points 1-5, but without modified /etc/modules 
-- in this moment Im using kernel 3.6-rc7 instead 3.3-rc7
-- in config I set all *XEN* for y
- to build xen from sources (I also copy-pasted at start from Xen manual from You and from David's website):
-- apt-get install texinfo git-core libglib2.0-dev libyajl-dev build-essential vncviewer bridge-utils mercurial
-- apt-get build-dep xen
-- patch rev25240 

Also Im using pciback instead stub, cause Im having problems with stub. It report me errors (missing files).
This is all what I need to start hvm. Now like I said before first I install windows without vga passthrough (its because 1 gfx also with problems with usb drivers under windows). When I have windows ready Im passing pci  with vga to hvm and Im installing nvidia drivers 275.33 or 275.50 and when it is done Im setting gfx_passthrough=1 in DomU config. 

Isn't it gfx_passthru=1 instead of gfx_passthrough=1? I believe your syntax is wrong.

What a joke man! I can only get Frank Lyon's NVIDIA Quadro 6000 VGA Passthrough completely 100% working but I cannot get 100% success for my own display cards. I have been trying a lot of things but still cannot get rid of the yellow triangle with exclamation mark and error code 43. Frank Lyon's NVIDIA Quadro 6000 costs S$6000++ and I can't afford that.
-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore
--------------060505090001040305030000-- --===============7582806588642359606== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============7582806588642359606==-- From xen-devel-bounces@lists.xen.org Sat Oct 06 07:40:14 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 06 Oct 2012 07:40:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKOzC-0003LW-2t; Sat, 06 Oct 2012 07:39:46 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKOz9-0003LR-PZ for xen-devel@lists.xensource.com; Sat, 06 Oct 2012 07:39:44 +0000 Received: from [85.158.138.51:46782] by server-11.bemta-3.messagelabs.com id CB/EF-21460-E30EF605; Sat, 06 Oct 2012 07:39:42 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1349509182!25281034!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMyNTM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30529 invoked from network); 6 Oct 2012 07:39:42 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 6 Oct 2012 07:39:42 -0000 X-IronPort-AV: E=Sophos;i="4.80,543,1344211200"; d="scan'208";a="14977052" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 06 Oct 2012 07:39:41 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Sat, 6 Oct 2012 08:39:41 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TKOz6-0007cy-T3; Sat, 06 Oct 2012 07:39:40 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1TKOz6-0006Sj-Lz; Sat, 06 Oct 2012 08:39:40 +0100 To: Message-ID: From: xen.org Date: Sat, 6 Oct 2012 08:39:40 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 13929: tolerable FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 13929 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13929/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail like 13928 test-amd64-amd64-xl-sedf 5 xen-boot fail like 13928 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail like 13928 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail like 13928 Tests which did not succeed, but are not blocking: test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: xen 3eb9a891889a baseline version: xen 3eb9a891889a jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-amd64-amd64-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat Oct 06 07:40:14 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 06 Oct 2012 07:40:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKOzC-0003LW-2t; Sat, 06 Oct 2012 07:39:46 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKOz9-0003LR-PZ for xen-devel@lists.xensource.com; Sat, 06 Oct 2012 07:39:44 +0000 Received: from [85.158.138.51:46782] by server-11.bemta-3.messagelabs.com id CB/EF-21460-E30EF605; Sat, 06 Oct 2012 07:39:42 +0000 X-Env-Sender: Ian.Jackson@eu.citrix.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1349509182!25281034!1 X-Originating-IP: [62.200.22.115] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMyNTM=\n X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30529 invoked from network); 6 Oct 2012 07:39:42 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115) by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 6 Oct 2012 07:39:42 -0000 X-IronPort-AV: E=Sophos;i="4.80,543,1344211200"; d="scan'208";a="14977052" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 06 Oct 2012 07:39:41 +0000 Received: from norwich.cam.xci-test.com (10.80.248.129) by smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Sat, 6 Oct 2012 08:39:41 +0100 Received: from [10.80.248.135] (helo=woking.cam.xci-test.com) by norwich.cam.xci-test.com with esmtp (Exim 4.72) (envelope-from ) id 1TKOz6-0007cy-T3; Sat, 06 Oct 2012 07:39:40 +0000 Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69) (envelope-from ) id 1TKOz6-0006Sj-Lz; Sat, 06 Oct 2012 08:39:40 +0100 To: Message-ID: From: xen.org Date: Sat, 6 Oct 2012 08:39:40 +0100 MIME-Version: 1.0 Cc: ian.jackson@eu.citrix.com Subject: [Xen-devel] [xen-unstable test] 13929: tolerable FAIL X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org flight 13929 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13929/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail like 13928 test-amd64-amd64-xl-sedf 5 xen-boot fail like 13928 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail like 13928 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail like 13928 Tests which did not succeed, but are not blocking: test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-i386-win 16 leak-check/check fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: xen 3eb9a891889a baseline version: xen 3eb9a891889a jobs: build-amd64 pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-amd64-win fail test-amd64-i386-win fail test-amd64-amd64-xl-win fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel From xen-devel-bounces@lists.xen.org Sat Oct 06 07:57:45 2012 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 06 Oct 2012 07:57:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKPGE-0003Zx-TW; Sat, 06 Oct 2012 07:57:22 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1TKPGD-0003Zo-3O for xen-devel@lists.xen.org; Sat, 06 Oct 2012 07:57:21 +0000 Received: from [85.158.139.83:18365] by server-2.bemta-5.messagelabs.com id 60/C2-28944-064EF605; Sat, 06 Oct 2012 07:57:20 +0000 X-Env-Sender: singapore.mr.teo.en.ming@gmail.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1349510237!28057147!1 X-Originating-IP: [209.85.220.45] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11209 invoked from network); 6 Oct 2012 07:57:19 -0000 Received: from mail-pa0-f45.google.com (HELO mail-pa0-f45.google.com) (209.85.220.45) by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 6 Oct 2012 07:57:19 -0000 Received: by mail-pa0-f45.google.com with SMTP id fb10so2610793pad.32 for ; Sat, 06 Oct 2012 00:57:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=c+wgXNc/oSy6AojlD7AXVD7goV20dW0VYuN8gmFnXTw=; b=jgbZyEFWjmm5doaLhgl9nP4WaEQ/EyuI24tUcNRomXBt097FIPrMIOO+apts+gj2Om gKyKMlrC2GRtm2zZ68NAgZzZLPwbLhc4HMAM0paJOTbmwKYBQviQM6wvTaVrzTEwt8Ge 8xjs0qZrpw+DgJt6HqvqR1phJ8A07dw76cPEL8kXg0hGrXoJ2tPBNdDZopfbVzJt7GX5 mKDW6lrfXGh+EBgDAqHJaDLRfULDlkCRBo5j9KYDutYdek7fpGjoXxlCnBy8SMT2MbNB /ZmOSulvQK6a68EtyIgilasNfpZRJGjm4HRwVbXMw+wXVvN5oh88Jspax/K2793PVIG9 nURQ== Received: by 10.68.225.5 with SMTP id rg5mr36611429pbc.73.1349510236812; Sat, 06 Oct 2012 00:57:16 -0700 (PDT) Received: from [192.168.1.2] (cm152.gamma205.maxonline.com.sg. [202.156.205.152]) by mx.google.com with ESMTPS id oi2sm6079532pbb.62.2012.10.06.00.57.14 (version=SSLv3 cipher=OTHER); Sat, 06 Oct 2012 00:57:16 -0700 (PDT) Message-ID: <506FE459.9070107@gmail.com> Date: Sat, 06 Oct 2012 15:57:13 +0800 From: "Teo En Ming (Zhang Enming)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Dariusz Krempa , "xen-users@lists.xen.org" , "xen-devel@lists.xen.org" , "Teo En Ming (Zhang Enming)" References: <506E8BFD.9080504@gmail.com> <506F064F.9010705@gmail.com> <506F91BB.5080002@gmail.com> <506FA74E.8050706@gmail.com> <506FBFB8.7010209@gmail.com> <506FD061.10206@gmail.com> In-Reply-To: Subject: Re: [Xen-devel] Help Needed from Xen Developers: Nasty Yellow Triangle with Exclamation Mark and Error Code 43 in Device Manager in Windows 8 HVM domU X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0999742626228694172==" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a multi-part message in MIME format. --===============0999742626228694172== Content-Type: multipart/alternative; boundary="------------010003070007050707060104" This is a multi-part message in MIME format. --------------010003070007050707060104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 06/10/2012 15:23, Dariusz Krempa wrote: > > Isn't it gfx_passthru=1 instead of gfx_passthrough=1? I believe > your syntax is wrong. > > > You right. That was misspelling. > > > What a joke man! I can only get Frank Lyon's NVIDIA Quadro 6000 > VGA Passthrough completely 100% working but I cannot get 100% > success for my own display cards. I have been trying a lot of > things but still cannot get rid of the yellow triangle with > exclamation mark and error code 43. Frank Lyon's NVIDIA Quadro > 6000 costs S$6000++ and I can't afford that. > > There can be another problem why You cant pass thru vga. The problem > can be with Yours motherboard. You never wrote what chipset You have > and, I assume, You don't test Q6000 on Yours MB. I have luck, cause > even if nvidia's and Intel's workers claims that chipset H67 don't > have implemented passthrough and I don't have any option in bios to > turn it on/off, then at least partially passthrough is implemented. If > You have possibilities to check this on different MB or put Q6000 into > Yours box then You will see if there is problem. > > > If You are willing we can try something. You can install teamviewer on > windows DomU and send me invitation or number by email then I will > inspect DomU and maybe I can help. We will have possibilities to chat > in teamviewer and You will control everything. Dear Dariusz Krempa, My motherboard is the Intel DQ45CB. It supports VT-d officially. There is a BIOS option to enable/disable VT-d. It was enabled. By the way, what is teamviewer? Maybe we can chat on IRC? -- Yours sincerely, Mr. Teo En Ming (Zhang Enming) Singapore --------------010003070007050707060104 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 06/10/2012 15:23, Dariusz Krempa wrote:

Isn't it gfx_passthru=1 instead of gfx_passthrough=1? I believe your syntax is wrong.

You right. That was misspelling.  

What a joke man! I can only get Frank Lyon's NVIDIA Quadro 6000 VGA Passthrough completely 100% working but I cannot get 100% success for my own display cards. I have been trying a lot of things but still cannot get rid of the yellow triangle with exclamation mark and error code 43. Frank Lyon's NVIDIA Quadro 6000 costs S$6000++ and I can't afford that. 

            

          

        

        
 There can be another problem why You cant pass thru vga.
          The problem can be with Yours motherboard. You never wrote
          what chipset You have and, I assume, You don't test Q6000 on
          Yours MB. I have luck, cause even if nvidia's and Intel's
          workers claims that chipset H67 don't have implemented
          passthrough and I don't have any option in bios to turn it
          on/off, then at least partially passthrough is implemented. If
          You have possibilities to check this on different MB or put
          Q6000 into Yours box then You will see if there is problem.

        


        

        


        

        
If You are willing we can try something. You can install
          teamviewer on windows DomU and send me invitation or number by
          email then I will inspect DomU and maybe I can help. We will
          have possibilities to chat in teamviewer and You will control
          everything.

      

    

    

    Dear Dariusz Krempa,

    

    My motherboard is the Intel DQ45CB. It supports VT-d officially.
    There is a BIOS option to enable/disable VT-d. It was enabled.

    

    By the way, what is teamviewer? Maybe we can chat on IRC?

    
-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore

  


--------------010003070007050707060104--


--===============0999742626228694172==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0999742626228694172==--


From xen-devel-bounces@lists.xen.org Sat Oct 06 07:57:45 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Oct 2012 07:57:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TKPGE-0003Zx-TW; Sat, 06 Oct 2012 07:57:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TKPGD-0003Zo-3O
	for xen-devel@lists.xen.org; Sat, 06 Oct 2012 07:57:21 +0000
Received: from [85.158.139.83:18365] by server-2.bemta-5.messagelabs.com id
	60/C2-28944-064EF605; Sat, 06 Oct 2012 07:57:20 +0000
X-Env-Sender: singapore.mr.teo.en.ming@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1349510237!28057147!1
X-Originating-IP: [209.85.220.45]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11209 invoked from network); 6 Oct 2012 07:57:19 -0000
Received: from mail-pa0-f45.google.com (HELO mail-pa0-f45.google.com)
	(209.85.220.45)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Oct 2012 07:57:19 -0000
Received: by mail-pa0-f45.google.com with SMTP id fb10so2610793pad.32
	for ; Sat, 06 Oct 2012 00:57:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:subject:references
	:in-reply-to:content-type;
	bh=c+wgXNc/oSy6AojlD7AXVD7goV20dW0VYuN8gmFnXTw=;
	b=jgbZyEFWjmm5doaLhgl9nP4WaEQ/EyuI24tUcNRomXBt097FIPrMIOO+apts+gj2Om
	gKyKMlrC2GRtm2zZ68NAgZzZLPwbLhc4HMAM0paJOTbmwKYBQviQM6wvTaVrzTEwt8Ge
	8xjs0qZrpw+DgJt6HqvqR1phJ8A07dw76cPEL8kXg0hGrXoJ2tPBNdDZopfbVzJt7GX5
	mKDW6lrfXGh+EBgDAqHJaDLRfULDlkCRBo5j9KYDutYdek7fpGjoXxlCnBy8SMT2MbNB
	/ZmOSulvQK6a68EtyIgilasNfpZRJGjm4HRwVbXMw+wXVvN5oh88Jspax/K2793PVIG9
	nURQ==
Received: by 10.68.225.5 with SMTP id rg5mr36611429pbc.73.1349510236812;
	Sat, 06 Oct 2012 00:57:16 -0700 (PDT)
Received: from [192.168.1.2] (cm152.gamma205.maxonline.com.sg.
	[202.156.205.152])
	by mx.google.com with ESMTPS id oi2sm6079532pbb.62.2012.10.06.00.57.14
	(version=SSLv3 cipher=OTHER); Sat, 06 Oct 2012 00:57:16 -0700 (PDT)
Message-ID: <506FE459.9070107@gmail.com>
Date: Sat, 06 Oct 2012 15:57:13 +0800
From: "Teo En Ming (Zhang Enming)" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: Dariusz Krempa , 
	"xen-users@lists.xen.org" ,
	"xen-devel@lists.xen.org" , 
	"Teo En Ming (Zhang Enming)" 
References: <506E8BFD.9080504@gmail.com>
	
	<506F064F.9010705@gmail.com>
	
	<506F91BB.5080002@gmail.com>
	
	<506FA74E.8050706@gmail.com> <506FBFB8.7010209@gmail.com>
	
	<506FD061.10206@gmail.com>
	
In-Reply-To: 
Subject: Re: [Xen-devel] Help Needed from Xen Developers: Nasty Yellow
 Triangle with Exclamation Mark and Error Code 43 in Device Manager in
 Windows 8 HVM domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0999742626228694172=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============0999742626228694172==
Content-Type: multipart/alternative;
 boundary="------------010003070007050707060104"

This is a multi-part message in MIME format.
--------------010003070007050707060104
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 06/10/2012 15:23, Dariusz Krempa wrote:
>
>     Isn't it gfx_passthru=1 instead of gfx_passthrough=1? I believe
>     your syntax is wrong.
>
>
> You right. That was misspelling.
>
>
>     What a joke man! I can only get Frank Lyon's NVIDIA Quadro 6000
>     VGA Passthrough completely 100% working but I cannot get 100%
>     success for my own display cards. I have been trying a lot of
>     things but still cannot get rid of the yellow triangle with
>     exclamation mark and error code 43. Frank Lyon's NVIDIA Quadro
>     6000 costs S$6000++ and I can't afford that.
>
>  There can be another problem why You cant pass thru vga. The problem 
> can be with Yours motherboard. You never wrote what chipset You have 
> and, I assume, You don't test Q6000 on Yours MB. I have luck, cause 
> even if nvidia's and Intel's workers claims that chipset H67 don't 
> have implemented passthrough and I don't have any option in bios to 
> turn it on/off, then at least partially passthrough is implemented. If 
> You have possibilities to check this on different MB or put Q6000 into 
> Yours box then You will see if there is problem.
>
>
> If You are willing we can try something. You can install teamviewer on 
> windows DomU and send me invitation or number by email then I will 
> inspect DomU and maybe I can help. We will have possibilities to chat 
> in teamviewer and You will control everything.

Dear Dariusz Krempa,

My motherboard is the Intel DQ45CB. It supports VT-d officially. There 
is a BIOS option to enable/disable VT-d. It was enabled.

By the way, what is teamviewer? Maybe we can chat on IRC?

-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore


--------------010003070007050707060104
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 06/10/2012 15:23, Dariusz Krempa
      wrote:

    

    


      

        

          
 Isn't it gfx_passthru=1
            instead of gfx_passthrough=1? I believe your syntax is
            wrong.

          

        

        


        

        
You right. That was misspelling.  

        

          
 

            What a joke man! I can only get Frank Lyon's NVIDIA Quadro
            6000 VGA Passthrough completely 100% working but I cannot
            get 100% success for my own display cards. I have been
            trying a lot of things but still cannot get rid of the
            yellow triangle with exclamation mark and error code 43.
            Frank Lyon's NVIDIA Quadro 6000 costs S$6000++ and I can't
            afford that.
            

              

            

          

        

        
 There can be another problem why You cant pass thru vga.
          The problem can be with Yours motherboard. You never wrote
          what chipset You have and, I assume, You don't test Q6000 on
          Yours MB. I have luck, cause even if nvidia's and Intel's
          workers claims that chipset H67 don't have implemented
          passthrough and I don't have any option in bios to turn it
          on/off, then at least partially passthrough is implemented. If
          You have possibilities to check this on different MB or put
          Q6000 into Yours box then You will see if there is problem.

        


        

        


        

        
If You are willing we can try something. You can install
          teamviewer on windows DomU and send me invitation or number by
          email then I will inspect DomU and maybe I can help. We will
          have possibilities to chat in teamviewer and You will control
          everything.

      

    

    

    Dear Dariusz Krempa,

    

    My motherboard is the Intel DQ45CB. It supports VT-d officially.
    There is a BIOS option to enable/disable VT-d. It was enabled.

    

    By the way, what is teamviewer? Maybe we can chat on IRC?

    
-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore

  


--------------010003070007050707060104--


--===============0999742626228694172==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0999742626228694172==--


From xen-devel-bounces@lists.xen.org Sat Oct 06 08:37:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Oct 2012 08:37:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TKPsf-0004bG-9X; Sat, 06 Oct 2012 08:37:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TKPse-0004bB-Cd
	for xen-devel@lists.xen.org; Sat, 06 Oct 2012 08:37:04 +0000
Received: from [85.158.139.83:42153] by server-10.bemta-5.messagelabs.com id
	29/AD-16911-FADEF605; Sat, 06 Oct 2012 08:37:03 +0000
X-Env-Sender: peter.maloney@brockmann-consult.de
X-Msg-Ref: server-11.tower-182.messagelabs.com!1349512622!26454363!1
X-Originating-IP: [212.227.126.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xNzEgPT4gNzE3Njk=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xNzEgPT4gNzE3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26342 invoked from network); 6 Oct 2012 08:37:03 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.126.171)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Oct 2012 08:37:03 -0000
Received: from [192.168.179.201] (hmbg-5f77232a.pool.mediaWays.net
	[95.119.35.42])
	by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis)
	id 0MBjmR-1T9edH2zwt-00Anx9; Sat, 06 Oct 2012 10:37:02 +0200
Message-ID: <506FEDA7.9080402@brockmann-consult.de>
Date: Sat, 06 Oct 2012 10:36:55 +0200
From: Peter Maloney 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120825 Thunderbird/15.0
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <501F98A1.4070806@brockmann-consult.de>
	<501FB9060200007800092D4E@nat28.tlf.novell.com>
	<5020C2DE.304@brockmann-consult.de>
	<50294D4B.9050405@brockmann-consult.de>
	<50296AC2.80600@brockmann-consult.de>
	<506C73A3.2030605@brockmann-consult.de>
	<506C9A84.5040408@brockmann-consult.de>
	<20121004142538.GA9979@phenom.dumpdata.com>
	<506F40C8.2060007@brockmann-consult.de>
In-Reply-To: <506F40C8.2060007@brockmann-consult.de>
X-Provags-ID: V02:K0:YWuOkhv2TbabJpu54+CfGBqJjsTlMflQ1tZq75eq5K9
	FptdNTu9KCI3RlAq/tMsgjd3Xu90kTJoHoYGxbzUq8O9r3MB4Q
	5mq+8CaPPLENPid95IbgZh4cZt/5wLqIVJ/S9HjPsBO8/QtC9V
	3v7e6vlFSNMdnzCcYlu0ptPeHyCykJ+/NUT7XiNTCWR0pWcTyu
	v3rxDLmHqSvHyRwBdb6gUJxq1k1nxXc4gDTm9IzpJ4Diwz67v7
	8m7nOaND+Fpd5G+sEzUyiVTgBwx5Se7PrPWdS0PAHhmFwn0qs6
	BNCLiSU+O8BzTZ7YnTqqFAx56AmFBGm9A6ZwebSdZUI/yVbEPL
	2uXYlvkvIGb7wJd25dJsokE8JCJXaDRWrBUKcYCvAT/NK6eI9Q
	6o21zpyTBoV1Q==
Subject: Re: [Xen-devel] 4.1.2 very slow without upstream patches,
 but fast with them, also 4.2 very slow
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/05/2012 10:19 PM, Peter Maloney wrote:
> On 10/04/2012 04:25 PM, Konrad Rzeszutek Wilk wrote:
>> On Wed, Oct 03, 2012 at 10:05:24PM +0200, Peter Maloney wrote:
>>> I also tested:
>>> modprobe xen-acpi-processor
>> You didn't say what kind of CPU you have. Nor if you compiled
>> your kernel or if you used a distros' kernel.
>>
>> One thing (just to eliminate this being a power management issue),
>> is to do this on the Linux command line:
>>
>> xen-acpi-processor.off=1
>>
>> It would also help if you provided the .config you are using. There
>> are some options you should not have one (like XEN_DEBUGFS.. something).
>>
> AMD FX-8150
> 990 FX chipset
> I compiled the for-linus branch of cmason's linux-btrfs git repo (
> git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git
> for-linus )
>
> Here's some hardware info: http://pastebin.com/XUZjmiVz
> Here's the kernel config: http://pastebin.com/1GQbiFZE (only weird thing
> I set was CONFIG_NR_CPUS=16 for no particular reason; default was 512 or
> 256)
>
>
> 3d stuff works fine (other than no es1370 sound device support) and fast
> in windows8 preview also, without that 0fps 'warmup' / 'hicup' thing
> happening (apparently as new textures are loading), which I wrote about
> before in IRC but not in the mailing list.
>
> At some point I plan on also testing:
> - builds between 4.1 and xen 4.2 to find where the 32 bit windowsxp
> starts going slow
> - a 64 bit windows xp if I can find one... I don't have one at the moment
> - a 32 bit windows 8 preview (I assume I can just download this like 64
> bit win8 preview)
32 bit Windows 8 preview is fast... so then it's only Windows xp that is
slow so far. And es1370 sound also works in 32 bit win8.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 06 08:37:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Oct 2012 08:37:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TKPsf-0004bG-9X; Sat, 06 Oct 2012 08:37:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TKPse-0004bB-Cd
	for xen-devel@lists.xen.org; Sat, 06 Oct 2012 08:37:04 +0000
Received: from [85.158.139.83:42153] by server-10.bemta-5.messagelabs.com id
	29/AD-16911-FADEF605; Sat, 06 Oct 2012 08:37:03 +0000
X-Env-Sender: peter.maloney@brockmann-consult.de
X-Msg-Ref: server-11.tower-182.messagelabs.com!1349512622!26454363!1
X-Originating-IP: [212.227.126.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xNzEgPT4gNzE3Njk=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xNzEgPT4gNzE3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26342 invoked from network); 6 Oct 2012 08:37:03 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.126.171)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Oct 2012 08:37:03 -0000
Received: from [192.168.179.201] (hmbg-5f77232a.pool.mediaWays.net
	[95.119.35.42])
	by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis)
	id 0MBjmR-1T9edH2zwt-00Anx9; Sat, 06 Oct 2012 10:37:02 +0200
Message-ID: <506FEDA7.9080402@brockmann-consult.de>
Date: Sat, 06 Oct 2012 10:36:55 +0200
From: Peter Maloney 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120825 Thunderbird/15.0
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <501F98A1.4070806@brockmann-consult.de>
	<501FB9060200007800092D4E@nat28.tlf.novell.com>
	<5020C2DE.304@brockmann-consult.de>
	<50294D4B.9050405@brockmann-consult.de>
	<50296AC2.80600@brockmann-consult.de>
	<506C73A3.2030605@brockmann-consult.de>
	<506C9A84.5040408@brockmann-consult.de>
	<20121004142538.GA9979@phenom.dumpdata.com>
	<506F40C8.2060007@brockmann-consult.de>
In-Reply-To: <506F40C8.2060007@brockmann-consult.de>
X-Provags-ID: V02:K0:YWuOkhv2TbabJpu54+CfGBqJjsTlMflQ1tZq75eq5K9
	FptdNTu9KCI3RlAq/tMsgjd3Xu90kTJoHoYGxbzUq8O9r3MB4Q
	5mq+8CaPPLENPid95IbgZh4cZt/5wLqIVJ/S9HjPsBO8/QtC9V
	3v7e6vlFSNMdnzCcYlu0ptPeHyCykJ+/NUT7XiNTCWR0pWcTyu
	v3rxDLmHqSvHyRwBdb6gUJxq1k1nxXc4gDTm9IzpJ4Diwz67v7
	8m7nOaND+Fpd5G+sEzUyiVTgBwx5Se7PrPWdS0PAHhmFwn0qs6
	BNCLiSU+O8BzTZ7YnTqqFAx56AmFBGm9A6ZwebSdZUI/yVbEPL
	2uXYlvkvIGb7wJd25dJsokE8JCJXaDRWrBUKcYCvAT/NK6eI9Q
	6o21zpyTBoV1Q==
Subject: Re: [Xen-devel] 4.1.2 very slow without upstream patches,
 but fast with them, also 4.2 very slow
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/05/2012 10:19 PM, Peter Maloney wrote:
> On 10/04/2012 04:25 PM, Konrad Rzeszutek Wilk wrote:
>> On Wed, Oct 03, 2012 at 10:05:24PM +0200, Peter Maloney wrote:
>>> I also tested:
>>> modprobe xen-acpi-processor
>> You didn't say what kind of CPU you have. Nor if you compiled
>> your kernel or if you used a distros' kernel.
>>
>> One thing (just to eliminate this being a power management issue),
>> is to do this on the Linux command line:
>>
>> xen-acpi-processor.off=1
>>
>> It would also help if you provided the .config you are using. There
>> are some options you should not have one (like XEN_DEBUGFS.. something).
>>
> AMD FX-8150
> 990 FX chipset
> I compiled the for-linus branch of cmason's linux-btrfs git repo (
> git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git
> for-linus )
>
> Here's some hardware info: http://pastebin.com/XUZjmiVz
> Here's the kernel config: http://pastebin.com/1GQbiFZE (only weird thing
> I set was CONFIG_NR_CPUS=16 for no particular reason; default was 512 or
> 256)
>
>
> 3d stuff works fine (other than no es1370 sound device support) and fast
> in windows8 preview also, without that 0fps 'warmup' / 'hicup' thing
> happening (apparently as new textures are loading), which I wrote about
> before in IRC but not in the mailing list.
>
> At some point I plan on also testing:
> - builds between 4.1 and xen 4.2 to find where the 32 bit windowsxp
> starts going slow
> - a 64 bit windows xp if I can find one... I don't have one at the moment
> - a 32 bit windows 8 preview (I assume I can just download this like 64
> bit win8 preview)
32 bit Windows 8 preview is fast... so then it's only Windows xp that is
slow so far. And es1370 sound also works in 32 bit win8.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 06 08:40:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Oct 2012 08:40:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TKPvC-0004iB-Nm; Sat, 06 Oct 2012 08:39:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TKPi7-0004ZF-8F
	for xen-devel@lists.xensource.com; Sat, 06 Oct 2012 08:26:11 +0000
Received: from [85.158.143.35:38384] by server-1.bemta-4.messagelabs.com id
	55/9B-05684-22BEF605; Sat, 06 Oct 2012 08:26:10 +0000
X-Env-Sender: andi@darwinistic.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1349511969!5540438!1
X-Originating-IP: [65.254.45.238]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21013 invoked from network); 6 Oct 2012 08:26:09 -0000
Received: from www.darwinistic.com (HELO brain.darwinistic.com) (65.254.45.238)
	by server-4.tower-21.messagelabs.com with SMTP;
	6 Oct 2012 08:26:09 -0000
Received: from [192.168.0.13] (196-215-2-84.dynamic.isadsl.co.za
	[196.215.2.84])
	by brain.darwinistic.com (Postfix) with ESMTP id 912C9135A3E7
	for ;
	Sat,  6 Oct 2012 10:26:05 +0200 (SAST)
Message-ID: <1349511963.3350.15.camel@multiplex>
From: Andi Reinbrech 
To: Xen Devel List 
Date: Sat, 06 Oct 2012 10:26:03 +0200
X-Mailer: Evolution 3.4.1 (3.4.1-2.fc17) 
Mime-Version: 1.0
X-Mailman-Approved-At: Sat, 06 Oct 2012 08:39:41 +0000
Subject: [Xen-devel] Can create PV domain in 4.2 only with xm and not xl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Xenners,

This problem has been cropping up since late 4.2-unstable builds:  I can
create all my HVM guests (windows 7, 8, XP and XP64) with xl create, but
my existing PV guests (Fedora based) don't start.  They either hang or
time out with an error that they can't connect to a vbd backend device.

This happens after the GRUB menu, so the bootloader is in fact accessed.

The strangest thing is, that by starting xend and creating the same
domain with xm create works 100%, but after stopping xend afterwards I
cannot create any more domains with xl, because udev gets messed up
between xm and xl.  Obviously I shouldn't, and don't want to mix the
two.

Another strange thing is that xl create on this same domain works fine
on kernel 3.5...  But I can't use kernel >=3.5, as the PCI USB
passthrough is broken.

So I am sitting with a catch-22: use kernel 3.5/3.6 and have xl work for
all domains, but can't use my HVM Windows machine that needs PCI
passthrough for VGA and USB, or use only kernel 3.3.4, but can't start
PV domains unless I use xend.

Any suggestions would be appreciated!  If I need to send configs or
logs, please let me know.

Kind regards,
Andi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 06 08:40:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Oct 2012 08:40:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TKPvC-0004iB-Nm; Sat, 06 Oct 2012 08:39:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TKPi7-0004ZF-8F
	for xen-devel@lists.xensource.com; Sat, 06 Oct 2012 08:26:11 +0000
Received: from [85.158.143.35:38384] by server-1.bemta-4.messagelabs.com id
	55/9B-05684-22BEF605; Sat, 06 Oct 2012 08:26:10 +0000
X-Env-Sender: andi@darwinistic.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1349511969!5540438!1
X-Originating-IP: [65.254.45.238]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21013 invoked from network); 6 Oct 2012 08:26:09 -0000
Received: from www.darwinistic.com (HELO brain.darwinistic.com) (65.254.45.238)
	by server-4.tower-21.messagelabs.com with SMTP;
	6 Oct 2012 08:26:09 -0000
Received: from [192.168.0.13] (196-215-2-84.dynamic.isadsl.co.za
	[196.215.2.84])
	by brain.darwinistic.com (Postfix) with ESMTP id 912C9135A3E7
	for ;
	Sat,  6 Oct 2012 10:26:05 +0200 (SAST)
Message-ID: <1349511963.3350.15.camel@multiplex>
From: Andi Reinbrech 
To: Xen Devel List 
Date: Sat, 06 Oct 2012 10:26:03 +0200
X-Mailer: Evolution 3.4.1 (3.4.1-2.fc17) 
Mime-Version: 1.0
X-Mailman-Approved-At: Sat, 06 Oct 2012 08:39:41 +0000
Subject: [Xen-devel] Can create PV domain in 4.2 only with xm and not xl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Xenners,

This problem has been cropping up since late 4.2-unstable builds:  I can
create all my HVM guests (windows 7, 8, XP and XP64) with xl create, but
my existing PV guests (Fedora based) don't start.  They either hang or
time out with an error that they can't connect to a vbd backend device.

This happens after the GRUB menu, so the bootloader is in fact accessed.

The strangest thing is, that by starting xend and creating the same
domain with xm create works 100%, but after stopping xend afterwards I
cannot create any more domains with xl, because udev gets messed up
between xm and xl.  Obviously I shouldn't, and don't want to mix the
two.

Another strange thing is that xl create on this same domain works fine
on kernel 3.5...  But I can't use kernel >=3.5, as the PCI USB
passthrough is broken.

So I am sitting with a catch-22: use kernel 3.5/3.6 and have xl work for
all domains, but can't use my HVM Windows machine that needs PCI
passthrough for VGA and USB, or use only kernel 3.3.4, but can't start
PV domains unless I use xend.

Any suggestions would be appreciated!  If I need to send configs or
logs, please let me know.

Kind regards,
Andi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 06 08:40:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Oct 2012 08:40:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TKPvC-0004hw-0s; Sat, 06 Oct 2012 08:39:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TKEa8-0007PI-E0
	for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 20:33:12 +0000
Received: from [85.158.143.99:17664] by server-3.bemta-4.messagelabs.com id
	53/1C-10986-7044F605; Fri, 05 Oct 2012 20:33:11 +0000
X-Env-Sender: jcmvbkbc@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1349469189!24923310!1
X-Originating-IP: [209.85.219.43]
X-SpamReason: No, hits=3.3 required=7.0 tests=BODY_RANDOM_LONG,
	FROM_LOCAL_NOVOWEL,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19280 invoked from network); 5 Oct 2012 20:33:10 -0000
Received: from mail-oa0-f43.google.com (HELO mail-oa0-f43.google.com)
	(209.85.219.43)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Oct 2012 20:33:10 -0000
Received: by mail-oa0-f43.google.com with SMTP id k1so2966752oag.30
	for ;
	Fri, 05 Oct 2012 13:33:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=xRtMMRlnUY14h5zGutv3qAxpg+0CJ3O3mKTcybziK7c=;
	b=AmRnYY7V3VCXJUamV3F5Sw2nOvSksMd6NC/8eCOl5yTYDilh22qlEKkxgw8hlaB9Dl
	TU8z/4e6K/gYFQG5IjE2snXs1PjTWrlMA/UGlusdkjApgBtEbgFR1jptkeUzvSLX5OSq
	9YPIxypesfINLr+0gaoRrzmu+LO8tuydr0DncIFmgBfC5GxkhpJYw+Y7B+guKk8DqnVc
	4NgwkOe/iVFqrRS9uXu7b+mXLTGJAC+xgmJuVjH/qIPWBXCdJbOkEIhyVeTtRXaYs9qV
	pltoHUD+dcf+Nh76RsgY1Q/4AHqjDzjVsPT3MHEJh38qjv3VVhrhbELqghFYQUgRwBwO
	SzIw==
MIME-Version: 1.0
Received: by 10.182.212.7 with SMTP id ng7mr7369706obc.74.1349469189369; Fri,
	05 Oct 2012 13:33:09 -0700 (PDT)
Received: by 10.182.43.196 with HTTP; Fri, 5 Oct 2012 13:33:09 -0700 (PDT)
In-Reply-To: <1349468535-14499-1-git-send-email-ehabkost@redhat.com>
References: <1349468535-14499-1-git-send-email-ehabkost@redhat.com>
Date: Sat, 6 Oct 2012 00:33:09 +0400
Message-ID: 
From: Max Filippov 
To: Eduardo Habkost 
X-Mailman-Approved-At: Sat, 06 Oct 2012 08:39:41 +0000
Cc: Peter Maydell ,
	Evgeny Voevodin , qemu-devel@nongnu.org,
	Peter Crosthwaite ,
	"Edgar E. Iglesias" ,
	Guan Xuetao , xen-devel@lists.xensource.com,
	Igor Mitsyanko ,
	Magnus Damm , Alexander Graf ,
	=?ISO-8859-1?Q?Herv=E9_Poussineau?= ,
	Maksim Kozlov ,
	Andrzej Zaborowski ,
	Fabien Chouteau , Jan Kiszka ,
	Paul Brook , Blue Swirl ,
	Anthony Liguori ,
	Michael Walle , qemu-ppc@nongnu.org,
	Dmitry Solodkiy ,
	Aurelien Jarno 
Subject: Re: [Xen-devel] [QEMU PATCH] create struct for machine
	initialization arguments (v2)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Oct 6, 2012 at 12:22 AM, Eduardo Habkost  wrote:
> This should help us to:
> - More easily add or remove machine initialization arguments without
>   having to change every single machine init function;
> - More easily make mechanical changes involving the machine init
>   functions in the future;
> - Let machine initialization forward the init arguments to other
>   functions more easily.
>
> This change was half-mechanical process: first the struct was added with
> the local ram_size, boot_device, kernel_*, initrd_*, and cpu_model local
> variable initialization to all functions. Then the compiler helped me
> locate the local variables that are unused, so they could be removed.
>
> Changes v1 -> v2:
>  - Fix mistake on the conversion of pc_xen_hvm_init() and xen_init_pv()
>
> Signed-off-by: Eduardo Habkost 

[...]

> diff --git a/vl.c b/vl.c
> index 8d305ca..f663e7c 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -3624,8 +3624,13 @@ int main(int argc, char **argv, char **envp)
>
>      qdev_machine_init();
>
> -    machine->init(ram_size, boot_devices,
> -                  kernel_filename, kernel_cmdline, initrd_filename, cpu_model);
> +    QEMUMachineInitArgs args = { .ram_size = ram_size,
> +                                 .boot_device = boot_devices,
> +                                 .kernel_filename = kernel_filename,
> +                                 .kernel_cmdline = kernel_cmdline,
> +                                 initrd_filename = initrd_filename,

Missing dot?

> +                                 .cpu_model = cpu_model };
> +    machine->init(&args);
>
>      cpu_synchronize_all_post_init();

-- 
Thanks.
-- Max

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 06 08:40:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Oct 2012 08:40:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TKPvC-0004hw-0s; Sat, 06 Oct 2012 08:39:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TKEa8-0007PI-E0
	for xen-devel@lists.xensource.com; Fri, 05 Oct 2012 20:33:12 +0000
Received: from [85.158.143.99:17664] by server-3.bemta-4.messagelabs.com id
	53/1C-10986-7044F605; Fri, 05 Oct 2012 20:33:11 +0000
X-Env-Sender: jcmvbkbc@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1349469189!24923310!1
X-Originating-IP: [209.85.219.43]
X-SpamReason: No, hits=3.3 required=7.0 tests=BODY_RANDOM_LONG,
	FROM_LOCAL_NOVOWEL,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19280 invoked from network); 5 Oct 2012 20:33:10 -0000
Received: from mail-oa0-f43.google.com (HELO mail-oa0-f43.google.com)
	(209.85.219.43)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Oct 2012 20:33:10 -0000
Received: by mail-oa0-f43.google.com with SMTP id k1so2966752oag.30
	for ;
	Fri, 05 Oct 2012 13:33:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=xRtMMRlnUY14h5zGutv3qAxpg+0CJ3O3mKTcybziK7c=;
	b=AmRnYY7V3VCXJUamV3F5Sw2nOvSksMd6NC/8eCOl5yTYDilh22qlEKkxgw8hlaB9Dl
	TU8z/4e6K/gYFQG5IjE2snXs1PjTWrlMA/UGlusdkjApgBtEbgFR1jptkeUzvSLX5OSq
	9YPIxypesfINLr+0gaoRrzmu+LO8tuydr0DncIFmgBfC5GxkhpJYw+Y7B+guKk8DqnVc
	4NgwkOe/iVFqrRS9uXu7b+mXLTGJAC+xgmJuVjH/qIPWBXCdJbOkEIhyVeTtRXaYs9qV
	pltoHUD+dcf+Nh76RsgY1Q/4AHqjDzjVsPT3MHEJh38qjv3VVhrhbELqghFYQUgRwBwO
	SzIw==
MIME-Version: 1.0
Received: by 10.182.212.7 with SMTP id ng7mr7369706obc.74.1349469189369; Fri,
	05 Oct 2012 13:33:09 -0700 (PDT)
Received: by 10.182.43.196 with HTTP; Fri, 5 Oct 2012 13:33:09 -0700 (PDT)
In-Reply-To: <1349468535-14499-1-git-send-email-ehabkost@redhat.com>
References: <1349468535-14499-1-git-send-email-ehabkost@redhat.com>
Date: Sat, 6 Oct 2012 00:33:09 +0400
Message-ID: 
From: Max Filippov 
To: Eduardo Habkost 
X-Mailman-Approved-At: Sat, 06 Oct 2012 08:39:41 +0000
Cc: Peter Maydell ,
	Evgeny Voevodin , qemu-devel@nongnu.org,
	Peter Crosthwaite ,
	"Edgar E. Iglesias" ,
	Guan Xuetao , xen-devel@lists.xensource.com,
	Igor Mitsyanko ,
	Magnus Damm , Alexander Graf ,
	=?ISO-8859-1?Q?Herv=E9_Poussineau?= ,
	Maksim Kozlov ,
	Andrzej Zaborowski ,
	Fabien Chouteau , Jan Kiszka ,
	Paul Brook , Blue Swirl ,
	Anthony Liguori ,
	Michael Walle , qemu-ppc@nongnu.org,
	Dmitry Solodkiy ,
	Aurelien Jarno 
Subject: Re: [Xen-devel] [QEMU PATCH] create struct for machine
	initialization arguments (v2)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Oct 6, 2012 at 12:22 AM, Eduardo Habkost  wrote:
> This should help us to:
> - More easily add or remove machine initialization arguments without
>   having to change every single machine init function;
> - More easily make mechanical changes involving the machine init
>   functions in the future;
> - Let machine initialization forward the init arguments to other
>   functions more easily.
>
> This change was half-mechanical process: first the struct was added with
> the local ram_size, boot_device, kernel_*, initrd_*, and cpu_model local
> variable initialization to all functions. Then the compiler helped me
> locate the local variables that are unused, so they could be removed.
>
> Changes v1 -> v2:
>  - Fix mistake on the conversion of pc_xen_hvm_init() and xen_init_pv()
>
> Signed-off-by: Eduardo Habkost 

[...]

> diff --git a/vl.c b/vl.c
> index 8d305ca..f663e7c 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -3624,8 +3624,13 @@ int main(int argc, char **argv, char **envp)
>
>      qdev_machine_init();
>
> -    machine->init(ram_size, boot_devices,
> -                  kernel_filename, kernel_cmdline, initrd_filename, cpu_model);
> +    QEMUMachineInitArgs args = { .ram_size = ram_size,
> +                                 .boot_device = boot_devices,
> +                                 .kernel_filename = kernel_filename,
> +                                 .kernel_cmdline = kernel_cmdline,
> +                                 initrd_filename = initrd_filename,

Missing dot?

> +                                 .cpu_model = cpu_model };
> +    machine->init(&args);
>
>      cpu_synchronize_all_post_init();

-- 
Thanks.
-- Max

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 06 08:40:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Oct 2012 08:40:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TKPvC-0004i3-C4; Sat, 06 Oct 2012 08:39:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TKPbN-0004Y6-Cp
	for xen-devel@lists.xensource.com; Sat, 06 Oct 2012 08:19:13 +0000
Received: from [85.158.143.99:55642] by server-3.bemta-4.messagelabs.com id
	63/A7-10986-089EF605; Sat, 06 Oct 2012 08:19:12 +0000
X-Env-Sender: andi@darwinistic.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1349511551!26079560!1
X-Originating-IP: [65.254.45.238]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2462 invoked from network); 6 Oct 2012 08:19:11 -0000
Received: from www.darwinistic.com (HELO brain.darwinistic.com) (65.254.45.238)
	by server-6.tower-216.messagelabs.com with SMTP;
	6 Oct 2012 08:19:11 -0000
Received: from [192.168.0.13] (196-215-2-84.dynamic.isadsl.co.za
	[196.215.2.84])
	by brain.darwinistic.com (Postfix) with ESMTP id A5EB1135A3E7
	for ;
	Sat,  6 Oct 2012 10:19:09 +0200 (SAST)
Message-ID: <1349511545.3350.8.camel@multiplex>
From: Andi Reinbrech 
To: Xen Devel List 
Date: Sat, 06 Oct 2012 10:19:05 +0200
X-Mailer: Evolution 3.4.1 (3.4.1-2.fc17) 
Mime-Version: 1.0
X-Mailman-Approved-At: Sat, 06 Oct 2012 08:39:41 +0000
Subject: [Xen-devel] PCI USB Passthrough on Kernel 3.5 and 3.6 not working
	(HVM or PVM)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Xenners,

I have tried to upgrade to kernel 3.5 and experienced the USB/PCI
passthrough problem.  This has not been "fixed" in 3.6 either.  I do not
know if this is qemu, xen or kernel related.

I am using Xen 4.2 final and Xen 4.3-unstable to test.

DomU is Windows 7 64 bit or Linux Fedora 17.  In Windows, I get the
little yellow triangle with Code 10 (I know this means nothing...
really).  In linux, the PCI device is recognised, but a few seconds
later disabled due to a "fatal error", no more details than that in
dmesg.  

Dom0 retains full control over the USB controller (this is not the case
when passthrough works, xl switches between Dom0 and DomU depending on
who claims the device).  

In both Windows and Linux (lspci), the device is "seen" but cannot be
activated.  

In Dom0, the device is assigned to the guest (xl pci-list show that it
is assigned and has a valid guest PCI ID).

Xen logs are normal, devices get assigned as if they were working with a
kernel 3.3.4 Dom0 - no errors according to xen logs or xl dmesg.

VGA PCI passthrough works 100%.

I tried also with device model qemu-xen, but then passthrough doesn't
work at all (no VGA either), even with upstream QEMU from git.

Please tell me if I'm missing something obvious or if I can provide more
information for troubleshooting!

Kind regards,
Andi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 06 08:40:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Oct 2012 08:40:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TKPvC-0004i3-C4; Sat, 06 Oct 2012 08:39:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TKPbN-0004Y6-Cp
	for xen-devel@lists.xensource.com; Sat, 06 Oct 2012 08:19:13 +0000
Received: from [85.158.143.99:55642] by server-3.bemta-4.messagelabs.com id
	63/A7-10986-089EF605; Sat, 06 Oct 2012 08:19:12 +0000
X-Env-Sender: andi@darwinistic.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1349511551!26079560!1
X-Originating-IP: [65.254.45.238]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2462 invoked from network); 6 Oct 2012 08:19:11 -0000
Received: from www.darwinistic.com (HELO brain.darwinistic.com) (65.254.45.238)
	by server-6.tower-216.messagelabs.com with SMTP;
	6 Oct 2012 08:19:11 -0000
Received: from [192.168.0.13] (196-215-2-84.dynamic.isadsl.co.za
	[196.215.2.84])
	by brain.darwinistic.com (Postfix) with ESMTP id A5EB1135A3E7
	for ;
	Sat,  6 Oct 2012 10:19:09 +0200 (SAST)
Message-ID: <1349511545.3350.8.camel@multiplex>
From: Andi Reinbrech 
To: Xen Devel List 
Date: Sat, 06 Oct 2012 10:19:05 +0200
X-Mailer: Evolution 3.4.1 (3.4.1-2.fc17) 
Mime-Version: 1.0
X-Mailman-Approved-At: Sat, 06 Oct 2012 08:39:41 +0000
Subject: [Xen-devel] PCI USB Passthrough on Kernel 3.5 and 3.6 not working
	(HVM or PVM)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Xenners,

I have tried to upgrade to kernel 3.5 and experienced the USB/PCI
passthrough problem.  This has not been "fixed" in 3.6 either.  I do not
know if this is qemu, xen or kernel related.

I am using Xen 4.2 final and Xen 4.3-unstable to test.

DomU is Windows 7 64 bit or Linux Fedora 17.  In Windows, I get the
little yellow triangle with Code 10 (I know this means nothing...
really).  In linux, the PCI device is recognised, but a few seconds
later disabled due to a "fatal error", no more details than that in
dmesg.  

Dom0 retains full control over the USB controller (this is not the case
when passthrough works, xl switches between Dom0 and DomU depending on
who claims the device).  

In both Windows and Linux (lspci), the device is "seen" but cannot be
activated.  

In Dom0, the device is assigned to the guest (xl pci-list show that it
is assigned and has a valid guest PCI ID).

Xen logs are normal, devices get assigned as if they were working with a
kernel 3.3.4 Dom0 - no errors according to xen logs or xl dmesg.

VGA PCI passthrough works 100%.

I tried also with device model qemu-xen, but then passthrough doesn't
work at all (no VGA either), even with upstream QEMU from git.

Please tell me if I'm missing something obvious or if I can provide more
information for troubleshooting!

Kind regards,
Andi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 06 16:50:20 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Oct 2012 16:50:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TKXZH-0001at-3m; Sat, 06 Oct 2012 16:49:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TKXZE-0001ak-GP
	for xen-devel@lists.xen.org; Sat, 06 Oct 2012 16:49:32 +0000
Received: from [85.158.139.211:44708] by server-10.bemta-5.messagelabs.com id
	21/E1-16911-B1160705; Sat, 06 Oct 2012 16:49:31 +0000
X-Env-Sender: singapore.mr.teo.en.ming@gmail.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1349542168!21272274!1
X-Originating-IP: [209.85.220.45]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12237 invoked from network); 6 Oct 2012 16:49:30 -0000
Received: from mail-pa0-f45.google.com (HELO mail-pa0-f45.google.com)
	(209.85.220.45)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Oct 2012 16:49:30 -0000
Received: by mail-pa0-f45.google.com with SMTP id fb10so2833357pad.32
	for ; Sat, 06 Oct 2012 09:49:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:disposition-notification-to:date:from:user-agent
	:mime-version:to:subject:content-type;
	bh=qjMfeduvwtLhtFK/8VVGxv6Oxs2TH7gIFfMk4RdWywM=;
	b=HNYSJWxOI6U6gvTgfqZ+07VN7mUvXZ9LEQHjFQNwabI5dR3Izup3t4ZM/U4h1pWhoH
	4L4VUGUe8P+vMUg8WZW7d0S8Ncoatd6b8Zxu2gJcDvnpE5bR36ODAlFbIE+kCkiKYWnQ
	9AiZEamvYdE0xJMTUgqxmsqEqgUa6SBFtB9Eetujxh9JitCIHIxrR8TauYelNozZtVyy
	8FRN94BaolFUWwtV8PQbPqpzWgL9QUzeDAfQeVigPSgNIUfYo56i8VvcoaPLTu8Bu8nC
	6q+oVtNZvAgmtENmBFrgmnfPQVDgIVTxvnTmv0C+cqCyiU3u6SojsFKhbPXQVUlw99KD
	i3Nw==
Received: by 10.68.225.68 with SMTP id ri4mr39356168pbc.115.1349542168187;
	Sat, 06 Oct 2012 09:49:28 -0700 (PDT)
Received: from [192.168.1.2] (cm152.gamma205.maxonline.com.sg.
	[202.156.205.152])
	by mx.google.com with ESMTPS id rw5sm7870934pbc.54.2012.10.06.09.49.24
	(version=SSLv3 cipher=OTHER); Sat, 06 Oct 2012 09:49:27 -0700 (PDT)
Message-ID: <50706112.1030801@gmail.com>
Date: Sun, 07 Oct 2012 00:49:22 +0800
From: "Teo En Ming (Zhang Enming)" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: "xen-users@lists.xen.org" , 
	"xen-devel@lists.xen.org" ,
	"Teo En Ming (Zhang Enming)" , 
	Frank Lyon ,
	Dariusz Krempa , 
	Casey DeLorme ,
	Tobias Geiger , 
	David TECHER ,
	daniel.oon@ivicinternational.com, dorothy.ong@ivicinternational.com
Subject: [Xen-devel] I offer a reward of USD$50 + VGA card Giveaway to
 anyone who can solve my Xen VGA Passthrough Problem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============4539661456418373727=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============4539661456418373727==
Content-Type: multipart/alternative;
 boundary="------------070605050806030400050800"

This is a multi-part message in MIME format.
--------------070605050806030400050800
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

_History_

I have 100% success in Xen VGA Passthrough with Xen 3.5-unstable with my 
first Palit NVIDIA Geforce 8400 GS VGA card in 2009, which is 3 years 
ago. Then my first Palit NVIDIA Geforce 8400 GS VGA card overheated and 
malfunctioned. So I bought a 2nd Palit NVIDIA Geforce 8400 GS VGA card 
several months ago in March 2012 for S$44, to replace the first card. At 
that point in time, Xen was already of version 4.2-unstable. I have 
tried to passthrough my 2nd Palit NVIDIA Geforce 8400 GS, which is only 
partially working, or partial success. _In Windows 8 HVM domU, you will 
see a yellow triangle with exclamation mark and error code 43 in Device 
Manager for the 2nd Palit NVIDIA Geforce 8400 GS. In Windows XP Home 
Edition HVM domU, you will see a yellow circle with exclamation mark and 
error code 10 in Device Manager for the 2nd Palit NVIDIA Geforce 8400 GS._

Then I noticed Jean David Techer uses a Geforce 560 Ti for his Xen VGA 
Passthrough. So 1-2 weeks ago I bought a EVGA Geforce GTX 560 1 GB GDDR5 
for S$269. Same thing. Xen VGA Passthrough is only partially working or 
partial success. So I went back to the computer shop and exchanged my 
EVGA Geforce GTX 560 with a Gigabyte Geforce GTX 560 1 GB GDDR5, which 
costs S$289. Again, Xen VGA Passthrough is only partially working or 
partial success. _In Windows 8 HVM domU, you will see a yellow triangle 
with exclamation mark and error code 43 in Device Manager for the 
Gigabyte Geforce GTX 560. In Windows XP Home Edition HVM domU, you will 
see a yellow circle with exclamation mark and error code 10 in Device 
Manager for the Gigabyte Geforce GTX 560._

_The Challenge_

My computer hardware specifications:

Processor: Intel Pentium Dual Core E2300 @ 2.8 GHz
Motherboard: Intel DQ45CB Desktop Board with VT-d enabled
VGA Card: Gigabyte Geforce GTX 560 1 GB GDDR5
Memory: 6 GB

My computer software specifications:

Host operating system: Ubuntu 12.04.1 LTS Desktop Linux
Xen Hypervisor version: (a) Xen 4.2-unstable Changeset 25099 (b) Xen 
4.2.1-pre (c) Xen 4.3-unstable Changeset 25993
Linux Dom0 Kernel: (a) 3.5.4 (b) 3.6.0-rc7
Windows HVM domU: (a) Windows XP Home Edition SP3 (b) Windows 8 Release 
Preview 64-bit

Manuals which I have followed in getting Xen VGA Passthrough done:

(1) 
http://wiki.xen.org/wiki/Building_and_Installing_Xen_4.x_and_Linux_Kernel_3.x_on_Ubuntu_and_Debian_Linux

(2) 
http://wiki.xen.org/wiki/Xen_VGA_Passthrough_to_Windows_8_with_Xen_4.2-unstable

The above 2 are manuals which I have written myself, after studying 
several Xen Wiki Pages and Jean David Techer's notes.

Now, the above 2 manuals are the same manuals which I have used to 
obtain 100% success in Xen VGA Passthrough for Frank Lyon's NVIDIA 
Quadro 6000. Yes, 100% success. Absolutely no yellow triangle with 
exclamation mark and error code 43 in Windows 7 and Windows 8 HVM domU. 
It is an irony and a joke that, with the same set of manuals which I 
have written, I cannot get 100% success in Xen VGA Passthrough with my 
very own display cards. Frank Lyon's NVIDIA Quadro 6000 costs S$6000++, 
and I can't afford it.

So now, the problem stands. I get a yellow triangle with exclamation 
mark and error code 43 in device manager for Gigabyte Geforce GTX 560 in 
Windows 8 HVM domU and a yellow circle with exclamation mark and error 
code 10 in device manager for Gigabyte Geforce GTX 560 in Windows XP 
Home Edition HVM domU.

_The Reward_

1. USD$50 in cash
2. Palit NVIDIA Geforce 8400 GS PCI Express x16 VGA card (costs S$44)

_How to Get the Reward_

If I can say that you have solved my Xen VGA Passthrough problem 100%, 
you get the reward! Basically, the idea is to get rid of the yellow 
triangle with exclamation mark and error code 43 in Windows 8 HVM domU 
and the yellow circle with exclamation mark and error code 10 in Windows 
XP HVM domU.

Hence,

(1) If you can tell me off-hand the solution which leads to my Xen VGA 
Passthrough problem being solved 100%, you get the reward. OR

(2) You have spotted mistakes or errors in the manuals which I have 
written, leading to my Xen VGA Passthrough problem being solved 100%. 
You get the reward. OR

(3) You have a VT-d capable motherboard and processor, and a compatible 
NVIDIA Geforce GTX 560 like mine, and follows the 2 manuals which I have 
written for your Xen VGA Passthrough needs. If you can obtain 100% 
success, please tell me the mistakes or errors in my manuals, which 
leads to my Xen VGA Passthrough problem being solved 100%. You get the 
reward.

*_100% success means no error code 43 and no error code 10._*

For a start, you may follow the thread series "*Help Needed from Xen 
Developers: Nasty Yellow Triangle with Exclamation Mark and Error Code 
43 in Device Manager in Windows 8 HVM domU 
" in 
the xen-users and xen-devel mailing lists.*

Please note that the prize money of US$50 is guaranteed and there is 
only one winner. There is no closing date for this challenge.


-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore


--------------070605050806030400050800
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    History

    

    I have 100% success in Xen VGA Passthrough with Xen 3.5-unstable
    with my first Palit NVIDIA Geforce 8400 GS VGA card in 2009, which
    is 3 years ago. Then my first Palit NVIDIA Geforce 8400 GS VGA card
    overheated and malfunctioned. So I bought a 2nd Palit NVIDIA Geforce
    8400 GS VGA card several months ago in March 2012 for S$44, to
    replace the first card. At that point in time, Xen was already of
    version 4.2-unstable. I have tried to passthrough my 2nd Palit
    NVIDIA Geforce 8400 GS, which is only partially working, or partial
    success. In Windows 8 HVM domU, you will see a yellow triangle
      with exclamation mark and error code 43 in Device Manager for the
      2nd Palit NVIDIA Geforce 8400 GS. In Windows XP Home Edition HVM
      domU, you will see a yellow circle with exclamation mark and error
      code 10 in Device Manager for the 2nd Palit NVIDIA Geforce 8400
      GS.

    

    Then I noticed Jean David Techer uses a Geforce 560 Ti for his Xen
    VGA Passthrough. So 1-2 weeks ago I bought a EVGA Geforce GTX 560 1
    GB GDDR5 for S$269. Same thing. Xen VGA Passthrough is only
    partially working or partial success. So I went back to the computer
    shop and exchanged my EVGA Geforce GTX 560 with a Gigabyte Geforce
    GTX 560 1 GB GDDR5, which costs S$289. Again, Xen VGA Passthrough is
    only partially working or partial success. In Windows 8 HVM
      domU, you will see a yellow triangle with exclamation mark and
      error code 43 in Device Manager for the Gigabyte Geforce GTX 560.
      In Windows XP Home Edition HVM domU, you will see a yellow circle
      with exclamation mark and error code 10 in Device Manager for the
      Gigabyte Geforce GTX 560.

    

    The Challenge

    

    My computer hardware specifications:

    

    Processor: Intel Pentium Dual Core E2300 @ 2.8 GHz

    Motherboard: Intel DQ45CB Desktop Board with VT-d enabled

    VGA Card: Gigabyte Geforce GTX 560 1 GB GDDR5

    Memory: 6 GB

    

    My computer software specifications:

    

    Host operating system: Ubuntu 12.04.1 LTS Desktop Linux

    Xen Hypervisor version: (a) Xen 4.2-unstable Changeset 25099 (b) Xen
    4.2.1-pre (c) Xen 4.3-unstable Changeset 25993

    Linux Dom0 Kernel: (a) 3.5.4 (b) 3.6.0-rc7

    Windows HVM domU: (a) Windows XP Home Edition SP3 (b) Windows 8
    Release Preview 64-bit

    

    Manuals which I have followed in getting Xen VGA Passthrough done:

    

    (1)
http://wiki.xen.org/wiki/Building_and_Installing_Xen_4.x_and_Linux_Kernel_3.x_on_Ubuntu_and_Debian_Linux

    

    (2)
http://wiki.xen.org/wiki/Xen_VGA_Passthrough_to_Windows_8_with_Xen_4.2-unstable

    

    The above 2 are manuals which I have written myself, after studying
    several Xen Wiki Pages and Jean David Techer's notes.

    

    Now, the above 2 manuals are the same manuals which I have used to
    obtain 100% success in Xen VGA Passthrough for Frank Lyon's NVIDIA
    Quadro 6000. Yes, 100% success. Absolutely no yellow triangle with
    exclamation mark and error code 43 in Windows 7 and Windows 8 HVM
    domU. It is an irony and a joke that, with the same set of manuals
    which I have written, I cannot get 100% success in Xen VGA
    Passthrough with my very own display cards. Frank Lyon's NVIDIA
    Quadro 6000 costs S$6000++, and I can't afford it. 

    

    So now, the problem stands. I get a yellow triangle with exclamation
    mark and error code 43 in device manager for Gigabyte Geforce GTX
    560 in Windows 8 HVM domU and a yellow circle with exclamation mark
    and error code 10 in device manager for Gigabyte Geforce GTX 560 in
    Windows XP Home Edition HVM domU.

    

    The Reward

    

    1. USD$50 in cash

    2. Palit NVIDIA Geforce 8400 GS PCI Express x16 VGA card (costs
    S$44)

    

    How to Get the Reward

    

    If I can say that you have solved my Xen VGA Passthrough problem
    100%, you get the reward! Basically, the idea is to get rid of the
    yellow triangle with exclamation mark and error code 43 in Windows 8
    HVM domU and the yellow circle with exclamation mark and error code
    10 in Windows XP HVM domU.

    

    Hence,

    

    (1) If you can tell me off-hand the solution which leads to my Xen
    VGA Passthrough problem being solved 100%, you get the reward. OR

    

    (2) You have spotted mistakes or errors in the manuals which I have
    written, leading to my Xen VGA Passthrough problem being solved
    100%. You get the reward. OR

    

    (3) You have a VT-d capable motherboard and processor, and a
    compatible NVIDIA Geforce GTX 560 like mine, and follows the 2
    manuals which I have written for your Xen VGA Passthrough needs. If
    you can obtain 100% success, please tell me the mistakes or errors
    in my manuals, which leads to my Xen VGA Passthrough problem being
    solved 100%. You get the reward.

    

    100% success means no error code 43 and no error code 10.

    

    For a start, you may follow the thread series "Help

        Needed from Xen Developers: Nasty Yellow Triangle with
        Exclamation Mark and Error Code 43 in Device Manager in Windows
        8 HVM domU" in the xen-users and xen-devel mailing lists.

    

    Please note that the prize money of US$50 is guaranteed and there is
    only one winner. There is no closing date for this challenge.

    

    

    
-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore

  


--------------070605050806030400050800--


--===============4539661456418373727==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4539661456418373727==--


From xen-devel-bounces@lists.xen.org Sat Oct 06 16:50:20 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Oct 2012 16:50:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TKXZH-0001at-3m; Sat, 06 Oct 2012 16:49:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TKXZE-0001ak-GP
	for xen-devel@lists.xen.org; Sat, 06 Oct 2012 16:49:32 +0000
Received: from [85.158.139.211:44708] by server-10.bemta-5.messagelabs.com id
	21/E1-16911-B1160705; Sat, 06 Oct 2012 16:49:31 +0000
X-Env-Sender: singapore.mr.teo.en.ming@gmail.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1349542168!21272274!1
X-Originating-IP: [209.85.220.45]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12237 invoked from network); 6 Oct 2012 16:49:30 -0000
Received: from mail-pa0-f45.google.com (HELO mail-pa0-f45.google.com)
	(209.85.220.45)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Oct 2012 16:49:30 -0000
Received: by mail-pa0-f45.google.com with SMTP id fb10so2833357pad.32
	for ; Sat, 06 Oct 2012 09:49:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:disposition-notification-to:date:from:user-agent
	:mime-version:to:subject:content-type;
	bh=qjMfeduvwtLhtFK/8VVGxv6Oxs2TH7gIFfMk4RdWywM=;
	b=HNYSJWxOI6U6gvTgfqZ+07VN7mUvXZ9LEQHjFQNwabI5dR3Izup3t4ZM/U4h1pWhoH
	4L4VUGUe8P+vMUg8WZW7d0S8Ncoatd6b8Zxu2gJcDvnpE5bR36ODAlFbIE+kCkiKYWnQ
	9AiZEamvYdE0xJMTUgqxmsqEqgUa6SBFtB9Eetujxh9JitCIHIxrR8TauYelNozZtVyy
	8FRN94BaolFUWwtV8PQbPqpzWgL9QUzeDAfQeVigPSgNIUfYo56i8VvcoaPLTu8Bu8nC
	6q+oVtNZvAgmtENmBFrgmnfPQVDgIVTxvnTmv0C+cqCyiU3u6SojsFKhbPXQVUlw99KD
	i3Nw==
Received: by 10.68.225.68 with SMTP id ri4mr39356168pbc.115.1349542168187;
	Sat, 06 Oct 2012 09:49:28 -0700 (PDT)
Received: from [192.168.1.2] (cm152.gamma205.maxonline.com.sg.
	[202.156.205.152])
	by mx.google.com with ESMTPS id rw5sm7870934pbc.54.2012.10.06.09.49.24
	(version=SSLv3 cipher=OTHER); Sat, 06 Oct 2012 09:49:27 -0700 (PDT)
Message-ID: <50706112.1030801@gmail.com>
Date: Sun, 07 Oct 2012 00:49:22 +0800
From: "Teo En Ming (Zhang Enming)" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: "xen-users@lists.xen.org" , 
	"xen-devel@lists.xen.org" ,
	"Teo En Ming (Zhang Enming)" , 
	Frank Lyon ,
	Dariusz Krempa , 
	Casey DeLorme ,
	Tobias Geiger , 
	David TECHER ,
	daniel.oon@ivicinternational.com, dorothy.ong@ivicinternational.com
Subject: [Xen-devel] I offer a reward of USD$50 + VGA card Giveaway to
 anyone who can solve my Xen VGA Passthrough Problem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============4539661456418373727=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============4539661456418373727==
Content-Type: multipart/alternative;
 boundary="------------070605050806030400050800"

This is a multi-part message in MIME format.
--------------070605050806030400050800
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

_History_

I have 100% success in Xen VGA Passthrough with Xen 3.5-unstable with my 
first Palit NVIDIA Geforce 8400 GS VGA card in 2009, which is 3 years 
ago. Then my first Palit NVIDIA Geforce 8400 GS VGA card overheated and 
malfunctioned. So I bought a 2nd Palit NVIDIA Geforce 8400 GS VGA card 
several months ago in March 2012 for S$44, to replace the first card. At 
that point in time, Xen was already of version 4.2-unstable. I have 
tried to passthrough my 2nd Palit NVIDIA Geforce 8400 GS, which is only 
partially working, or partial success. _In Windows 8 HVM domU, you will 
see a yellow triangle with exclamation mark and error code 43 in Device 
Manager for the 2nd Palit NVIDIA Geforce 8400 GS. In Windows XP Home 
Edition HVM domU, you will see a yellow circle with exclamation mark and 
error code 10 in Device Manager for the 2nd Palit NVIDIA Geforce 8400 GS._

Then I noticed Jean David Techer uses a Geforce 560 Ti for his Xen VGA 
Passthrough. So 1-2 weeks ago I bought a EVGA Geforce GTX 560 1 GB GDDR5 
for S$269. Same thing. Xen VGA Passthrough is only partially working or 
partial success. So I went back to the computer shop and exchanged my 
EVGA Geforce GTX 560 with a Gigabyte Geforce GTX 560 1 GB GDDR5, which 
costs S$289. Again, Xen VGA Passthrough is only partially working or 
partial success. _In Windows 8 HVM domU, you will see a yellow triangle 
with exclamation mark and error code 43 in Device Manager for the 
Gigabyte Geforce GTX 560. In Windows XP Home Edition HVM domU, you will 
see a yellow circle with exclamation mark and error code 10 in Device 
Manager for the Gigabyte Geforce GTX 560._

_The Challenge_

My computer hardware specifications:

Processor: Intel Pentium Dual Core E2300 @ 2.8 GHz
Motherboard: Intel DQ45CB Desktop Board with VT-d enabled
VGA Card: Gigabyte Geforce GTX 560 1 GB GDDR5
Memory: 6 GB

My computer software specifications:

Host operating system: Ubuntu 12.04.1 LTS Desktop Linux
Xen Hypervisor version: (a) Xen 4.2-unstable Changeset 25099 (b) Xen 
4.2.1-pre (c) Xen 4.3-unstable Changeset 25993
Linux Dom0 Kernel: (a) 3.5.4 (b) 3.6.0-rc7
Windows HVM domU: (a) Windows XP Home Edition SP3 (b) Windows 8 Release 
Preview 64-bit

Manuals which I have followed in getting Xen VGA Passthrough done:

(1) 
http://wiki.xen.org/wiki/Building_and_Installing_Xen_4.x_and_Linux_Kernel_3.x_on_Ubuntu_and_Debian_Linux

(2) 
http://wiki.xen.org/wiki/Xen_VGA_Passthrough_to_Windows_8_with_Xen_4.2-unstable

The above 2 are manuals which I have written myself, after studying 
several Xen Wiki Pages and Jean David Techer's notes.

Now, the above 2 manuals are the same manuals which I have used to 
obtain 100% success in Xen VGA Passthrough for Frank Lyon's NVIDIA 
Quadro 6000. Yes, 100% success. Absolutely no yellow triangle with 
exclamation mark and error code 43 in Windows 7 and Windows 8 HVM domU. 
It is an irony and a joke that, with the same set of manuals which I 
have written, I cannot get 100% success in Xen VGA Passthrough with my 
very own display cards. Frank Lyon's NVIDIA Quadro 6000 costs S$6000++, 
and I can't afford it.

So now, the problem stands. I get a yellow triangle with exclamation 
mark and error code 43 in device manager for Gigabyte Geforce GTX 560 in 
Windows 8 HVM domU and a yellow circle with exclamation mark and error 
code 10 in device manager for Gigabyte Geforce GTX 560 in Windows XP 
Home Edition HVM domU.

_The Reward_

1. USD$50 in cash
2. Palit NVIDIA Geforce 8400 GS PCI Express x16 VGA card (costs S$44)

_How to Get the Reward_

If I can say that you have solved my Xen VGA Passthrough problem 100%, 
you get the reward! Basically, the idea is to get rid of the yellow 
triangle with exclamation mark and error code 43 in Windows 8 HVM domU 
and the yellow circle with exclamation mark and error code 10 in Windows 
XP HVM domU.

Hence,

(1) If you can tell me off-hand the solution which leads to my Xen VGA 
Passthrough problem being solved 100%, you get the reward. OR

(2) You have spotted mistakes or errors in the manuals which I have 
written, leading to my Xen VGA Passthrough problem being solved 100%. 
You get the reward. OR

(3) You have a VT-d capable motherboard and processor, and a compatible 
NVIDIA Geforce GTX 560 like mine, and follows the 2 manuals which I have 
written for your Xen VGA Passthrough needs. If you can obtain 100% 
success, please tell me the mistakes or errors in my manuals, which 
leads to my Xen VGA Passthrough problem being solved 100%. You get the 
reward.

*_100% success means no error code 43 and no error code 10._*

For a start, you may follow the thread series "*Help Needed from Xen 
Developers: Nasty Yellow Triangle with Exclamation Mark and Error Code 
43 in Device Manager in Windows 8 HVM domU 
" in 
the xen-users and xen-devel mailing lists.*

Please note that the prize money of US$50 is guaranteed and there is 
only one winner. There is no closing date for this challenge.


-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore


--------------070605050806030400050800
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    History

    

    I have 100% success in Xen VGA Passthrough with Xen 3.5-unstable
    with my first Palit NVIDIA Geforce 8400 GS VGA card in 2009, which
    is 3 years ago. Then my first Palit NVIDIA Geforce 8400 GS VGA card
    overheated and malfunctioned. So I bought a 2nd Palit NVIDIA Geforce
    8400 GS VGA card several months ago in March 2012 for S$44, to
    replace the first card. At that point in time, Xen was already of
    version 4.2-unstable. I have tried to passthrough my 2nd Palit
    NVIDIA Geforce 8400 GS, which is only partially working, or partial
    success. In Windows 8 HVM domU, you will see a yellow triangle
      with exclamation mark and error code 43 in Device Manager for the
      2nd Palit NVIDIA Geforce 8400 GS. In Windows XP Home Edition HVM
      domU, you will see a yellow circle with exclamation mark and error
      code 10 in Device Manager for the 2nd Palit NVIDIA Geforce 8400
      GS.

    

    Then I noticed Jean David Techer uses a Geforce 560 Ti for his Xen
    VGA Passthrough. So 1-2 weeks ago I bought a EVGA Geforce GTX 560 1
    GB GDDR5 for S$269. Same thing. Xen VGA Passthrough is only
    partially working or partial success. So I went back to the computer
    shop and exchanged my EVGA Geforce GTX 560 with a Gigabyte Geforce
    GTX 560 1 GB GDDR5, which costs S$289. Again, Xen VGA Passthrough is
    only partially working or partial success. In Windows 8 HVM
      domU, you will see a yellow triangle with exclamation mark and
      error code 43 in Device Manager for the Gigabyte Geforce GTX 560.
      In Windows XP Home Edition HVM domU, you will see a yellow circle
      with exclamation mark and error code 10 in Device Manager for the
      Gigabyte Geforce GTX 560.

    

    The Challenge

    

    My computer hardware specifications:

    

    Processor: Intel Pentium Dual Core E2300 @ 2.8 GHz

    Motherboard: Intel DQ45CB Desktop Board with VT-d enabled

    VGA Card: Gigabyte Geforce GTX 560 1 GB GDDR5

    Memory: 6 GB

    

    My computer software specifications:

    

    Host operating system: Ubuntu 12.04.1 LTS Desktop Linux

    Xen Hypervisor version: (a) Xen 4.2-unstable Changeset 25099 (b) Xen
    4.2.1-pre (c) Xen 4.3-unstable Changeset 25993

    Linux Dom0 Kernel: (a) 3.5.4 (b) 3.6.0-rc7

    Windows HVM domU: (a) Windows XP Home Edition SP3 (b) Windows 8
    Release Preview 64-bit

    

    Manuals which I have followed in getting Xen VGA Passthrough done:

    

    (1)
http://wiki.xen.org/wiki/Building_and_Installing_Xen_4.x_and_Linux_Kernel_3.x_on_Ubuntu_and_Debian_Linux

    

    (2)
http://wiki.xen.org/wiki/Xen_VGA_Passthrough_to_Windows_8_with_Xen_4.2-unstable

    

    The above 2 are manuals which I have written myself, after studying
    several Xen Wiki Pages and Jean David Techer's notes.

    

    Now, the above 2 manuals are the same manuals which I have used to
    obtain 100% success in Xen VGA Passthrough for Frank Lyon's NVIDIA
    Quadro 6000. Yes, 100% success. Absolutely no yellow triangle with
    exclamation mark and error code 43 in Windows 7 and Windows 8 HVM
    domU. It is an irony and a joke that, with the same set of manuals
    which I have written, I cannot get 100% success in Xen VGA
    Passthrough with my very own display cards. Frank Lyon's NVIDIA
    Quadro 6000 costs S$6000++, and I can't afford it. 

    

    So now, the problem stands. I get a yellow triangle with exclamation
    mark and error code 43 in device manager for Gigabyte Geforce GTX
    560 in Windows 8 HVM domU and a yellow circle with exclamation mark
    and error code 10 in device manager for Gigabyte Geforce GTX 560 in
    Windows XP Home Edition HVM domU.

    

    The Reward

    

    1. USD$50 in cash

    2. Palit NVIDIA Geforce 8400 GS PCI Express x16 VGA card (costs
    S$44)

    

    How to Get the Reward

    

    If I can say that you have solved my Xen VGA Passthrough problem
    100%, you get the reward! Basically, the idea is to get rid of the
    yellow triangle with exclamation mark and error code 43 in Windows 8
    HVM domU and the yellow circle with exclamation mark and error code
    10 in Windows XP HVM domU.

    

    Hence,

    

    (1) If you can tell me off-hand the solution which leads to my Xen
    VGA Passthrough problem being solved 100%, you get the reward. OR

    

    (2) You have spotted mistakes or errors in the manuals which I have
    written, leading to my Xen VGA Passthrough problem being solved
    100%. You get the reward. OR

    

    (3) You have a VT-d capable motherboard and processor, and a
    compatible NVIDIA Geforce GTX 560 like mine, and follows the 2
    manuals which I have written for your Xen VGA Passthrough needs. If
    you can obtain 100% success, please tell me the mistakes or errors
    in my manuals, which leads to my Xen VGA Passthrough problem being
    solved 100%. You get the reward.

    

    100% success means no error code 43 and no error code 10.

    

    For a start, you may follow the thread series "Help

        Needed from Xen Developers: Nasty Yellow Triangle with
        Exclamation Mark and Error Code 43 in Device Manager in Windows
        8 HVM domU" in the xen-users and xen-devel mailing lists.

    

    Please note that the prize money of US$50 is guaranteed and there is
    only one winner. There is no closing date for this challenge.

    

    

    
-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore

  


--------------070605050806030400050800--


--===============4539661456418373727==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4539661456418373727==--


From xen-devel-bounces@lists.xen.org Sat Oct 06 16:56:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Oct 2012 16:56:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TKXfw-0001jQ-3b; Sat, 06 Oct 2012 16:56:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TKXfu-0001jG-T0
	for xen-devel@lists.xen.org; Sat, 06 Oct 2012 16:56:27 +0000
Received: from [85.158.137.99:51740] by server-11.bemta-3.messagelabs.com id
	61/CE-21460-9B260705; Sat, 06 Oct 2012 16:56:25 +0000
X-Env-Sender: tknchris@gmail.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1349542582!19321051!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2366 invoked from network); 6 Oct 2012 16:56:24 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Oct 2012 16:56:24 -0000
Received: by mail-ie0-f173.google.com with SMTP id 17so8052116iea.32
	for ; Sat, 06 Oct 2012 09:56:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=91RYxmX1k+Zzf301NK3EkYi2x6YiqpHU53FJrgK717I=;
	b=XE6LvFhdNFpDGaZYaT6VEIaRwAByyv2tWfTqRssNDiTYMylV/43V0v4qoVAp4Rq23q
	mdkbDhORHIyO0WYjmWCSU5TCQsGQmYAvcPuk+IUS6hTvuBglMvkw0l8G139pCr1d1tVZ
	xcXTmNBfk6/cY2HtyrkpVnc1PvzlrIOc+LuiQowIvYdxZePXGe6Z9TieJxKRitD1rFUf
	GcVKTTLLHt+rENo4Ky5MLQ6tfWp/0jw5F71k4hYymt56FseyIK2FxZGl+YzvKSBlYxso
	0qNY+hR+NG5EysezKU9sT7br4f25yDnTmlM43cTi7dAVYfbyoubl34IljPam/PV8dd3P
	MBLg==
MIME-Version: 1.0
Received: by 10.42.65.6 with SMTP id j6mr9589819ici.2.1349542581819; Sat, 06
	Oct 2012 09:56:21 -0700 (PDT)
Received: by 10.64.41.67 with HTTP; Sat, 6 Oct 2012 09:56:21 -0700 (PDT)
Received: by 10.64.41.67 with HTTP; Sat, 6 Oct 2012 09:56:21 -0700 (PDT)
In-Reply-To: <50706112.1030801@gmail.com>
References: <50706112.1030801@gmail.com>
Date: Sat, 6 Oct 2012 12:56:21 -0400
Message-ID: 
From: chris 
To: "Teo En Ming (Zhang Enming)" 
Cc: daniel.oon@ivicinternational.com, Frank Lyon ,
	dorothy.ong@ivicinternational.com,
	"xen-devel@lists.xen.org" ,
	Tobias Geiger ,
	"xen-users@lists.xen.org" ,
	Casey DeLorme ,
	Dariusz Krempa ,
	David TECHER 
Subject: Re: [Xen-devel] I offer a reward of USD$50 + VGA card Giveaway to
 anyone who can solve my Xen VGA Passthrough Problem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============3091408667578392708=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3091408667578392708==
Content-Type: multipart/alternative; boundary=90e6ba61477432d99e04cb66debc

--90e6ba61477432d99e04cb66debc
Content-Type: text/plain; charset=ISO-8859-1

Sounds like someone is jealous of all the recent success reports :)
On Oct 6, 2012 12:51 PM, "Teo En Ming (Zhang Enming)" <
singapore.mr.teo.en.ming@gmail.com> wrote:

>  *History*
>
> I have 100% success in Xen VGA Passthrough with Xen 3.5-unstable with my
> first Palit NVIDIA Geforce 8400 GS VGA card in 2009, which is 3 years ago.
> Then my first Palit NVIDIA Geforce 8400 GS VGA card overheated and
> malfunctioned. So I bought a 2nd Palit NVIDIA Geforce 8400 GS VGA card
> several months ago in March 2012 for S$44, to replace the first card. At
> that point in time, Xen was already of version 4.2-unstable. I have tried
> to passthrough my 2nd Palit NVIDIA Geforce 8400 GS, which is only partially
> working, or partial success. *In Windows 8 HVM domU, you will see a
> yellow triangle with exclamation mark and error code 43 in Device Manager
> for the 2nd Palit NVIDIA Geforce 8400 GS. In Windows XP Home Edition HVM
> domU, you will see a yellow circle with exclamation mark and error code 10
> in Device Manager for the 2nd Palit NVIDIA Geforce 8400 GS.*
>
> Then I noticed Jean David Techer uses a Geforce 560 Ti for his Xen VGA
> Passthrough. So 1-2 weeks ago I bought a EVGA Geforce GTX 560 1 GB GDDR5
> for S$269. Same thing. Xen VGA Passthrough is only partially working or
> partial success. So I went back to the computer shop and exchanged my EVGA
> Geforce GTX 560 with a Gigabyte Geforce GTX 560 1 GB GDDR5, which costs
> S$289. Again, Xen VGA Passthrough is only partially working or partial
> success. *In Windows 8 HVM domU, you will see a yellow triangle with
> exclamation mark and error code 43 in Device Manager for the Gigabyte
> Geforce GTX 560. In Windows XP Home Edition HVM domU, you will see a yellow
> circle with exclamation mark and error code 10 in Device Manager for the
> Gigabyte Geforce GTX 560.*
>
> *The Challenge*
>
> My computer hardware specifications:
>
> Processor: Intel Pentium Dual Core E2300 @ 2.8 GHz
> Motherboard: Intel DQ45CB Desktop Board with VT-d enabled
> VGA Card: Gigabyte Geforce GTX 560 1 GB GDDR5
> Memory: 6 GB
>
> My computer software specifications:
>
> Host operating system: Ubuntu 12.04.1 LTS Desktop Linux
> Xen Hypervisor version: (a) Xen 4.2-unstable Changeset 25099 (b) Xen
> 4.2.1-pre (c) Xen 4.3-unstable Changeset 25993
> Linux Dom0 Kernel: (a) 3.5.4 (b) 3.6.0-rc7
> Windows HVM domU: (a) Windows XP Home Edition SP3 (b) Windows 8 Release
> Preview 64-bit
>
> Manuals which I have followed in getting Xen VGA Passthrough done:
>
> (1)
> http://wiki.xen.org/wiki/Building_and_Installing_Xen_4.x_and_Linux_Kernel_3.x_on_Ubuntu_and_Debian_Linux
>
> (2)
> http://wiki.xen.org/wiki/Xen_VGA_Passthrough_to_Windows_8_with_Xen_4.2-unstable
>
> The above 2 are manuals which I have written myself, after studying
> several Xen Wiki Pages and Jean David Techer's notes.
>
> Now, the above 2 manuals are the same manuals which I have used to obtain
> 100% success in Xen VGA Passthrough for Frank Lyon's NVIDIA Quadro 6000.
> Yes, 100% success. Absolutely no yellow triangle with exclamation mark and
> error code 43 in Windows 7 and Windows 8 HVM domU. It is an irony and a
> joke that, with the same set of manuals which I have written, I cannot get
> 100% success in Xen VGA Passthrough with my very own display cards. Frank
> Lyon's NVIDIA Quadro 6000 costs S$6000++, and I can't afford it.
>
> So now, the problem stands. I get a yellow triangle with exclamation mark
> and error code 43 in device manager for Gigabyte Geforce GTX 560 in Windows
> 8 HVM domU and a yellow circle with exclamation mark and error code 10 in
> device manager for Gigabyte Geforce GTX 560 in Windows XP Home Edition HVM
> domU.
>
> *The Reward*
>
> 1. USD$50 in cash
> 2. Palit NVIDIA Geforce 8400 GS PCI Express x16 VGA card (costs S$44)
>
> *How to Get the Reward*
>
> If I can say that you have solved my Xen VGA Passthrough problem 100%, you
> get the reward! Basically, the idea is to get rid of the yellow triangle
> with exclamation mark and error code 43 in Windows 8 HVM domU and the
> yellow circle with exclamation mark and error code 10 in Windows XP HVM
> domU.
>
> Hence,
>
> (1) If you can tell me off-hand the solution which leads to my Xen VGA
> Passthrough problem being solved 100%, you get the reward. OR
>
> (2) You have spotted mistakes or errors in the manuals which I have
> written, leading to my Xen VGA Passthrough problem being solved 100%. You
> get the reward. OR
>
> (3) You have a VT-d capable motherboard and processor, and a compatible
> NVIDIA Geforce GTX 560 like mine, and follows the 2 manuals which I have
> written for your Xen VGA Passthrough needs. If you can obtain 100% success,
> please tell me the mistakes or errors in my manuals, which leads to my Xen
> VGA Passthrough problem being solved 100%. You get the reward.
>
> *100% success means no error code 43 and no error code 10.*
>
> For a start, you may follow the thread series "*Help Needed from Xen
> Developers: Nasty Yellow Triangle with Exclamation Mark and Error Code 43
> in Device Manager in Windows 8 HVM domU"
> in the xen-users and xen-devel mailing lists.*
>
> Please note that the prize money of US$50 is guaranteed and there is only
> one winner. There is no closing date for this challenge.
>
>
> --
> Yours sincerely,
>
> Mr. Teo En Ming (Zhang Enming)
> Singapore
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
>

--90e6ba61477432d99e04cb66debc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Sounds like someone is jealous of all the recent success rep=
orts :)


On Oct 6, 2012 12:51 PM, "Teo En Ming (Zhan=
g Enming)" <s=
ingapore.mr.teo.en.ming@gmail.com> wrote:


 =20
   =20
 =20
  

    History

    

    I have 100% success in Xen VGA Passthrough with Xen 3.5-unstable
    with my first Palit NVIDIA Geforce 8400 GS VGA card in 2009, which
    is 3 years ago. Then my first Palit NVIDIA Geforce 8400 GS VGA card
    overheated and malfunctioned. So I bought a 2nd Palit NVIDIA Geforce
    8400 GS VGA card several months ago in March 2012 for S$44, to
    replace the first card. At that point in time, Xen was already of
    version 4.2-unstable. I have tried to passthrough my 2nd Palit
    NVIDIA Geforce 8400 GS, which is only partially working, or partial
    success. In Windows 8 HVM domU, you will see a yellow triangle
      with exclamation mark and error code 43 in Device Manager for the
      2nd Palit NVIDIA Geforce 8400 GS. In Windows XP Home Edition HVM
      domU, you will see a yellow circle with exclamation mark and error
      code 10 in Device Manager for the 2nd Palit NVIDIA Geforce 8400
      GS.

    

    Then I noticed Jean David Techer uses a Geforce 560 Ti for his Xen
    VGA Passthrough. So 1-2 weeks ago I bought a EVGA Geforce GTX 560 1
    GB GDDR5 for S$269. Same thing. Xen VGA Passthrough is only
    partially working or partial success. So I went back to the computer
    shop and exchanged my EVGA Geforce GTX 560 with a Gigabyte Geforce
    GTX 560 1 GB GDDR5, which costs S$289. Again, Xen VGA Passthrough is
    only partially working or partial success. In Windows 8 HVM
      domU, you will see a yellow triangle with exclamation mark and
      error code 43 in Device Manager for the Gigabyte Geforce GTX 560.
      In Windows XP Home Edition HVM domU, you will see a yellow circle
      with exclamation mark and error code 10 in Device Manager for the
      Gigabyte Geforce GTX 560.

    

    The Challenge

    

    My computer hardware specifications:

    

    Processor: Intel Pentium Dual Core E2300 @ 2.8 GHz

    Motherboard: Intel DQ45CB Desktop Board with VT-d enabled

    VGA Card: Gigabyte Geforce GTX 560 1 GB GDDR5

    Memory: 6 GB

    

    My computer software specifications:

    

    Host operating system: Ubuntu 12.04.1 LTS Desktop Linux

    Xen Hypervisor version: (a) Xen 4.2-unstable Changeset 25099 (b) Xen
    4.2.1-pre (c) Xen 4.3-unstable Changeset 25993

    Linux Dom0 Kernel: (a) 3.5.4 (b) 3.6.0-rc7

    Windows HVM domU: (a) Windows XP Home Edition SP3 (b) Windows 8
    Release Preview 64-bit

    

    Manuals which I have followed in getting Xen VGA Passthrough done:

    

    (1)
http://wiki.xen=
.org/wiki/Building_and_Installing_Xen_4.x_and_Linux_Kernel_3.x_on_Ubuntu_an=
d_Debian_Linux


    

    (2)
http://wiki.xen.org/wiki/Xen_VGA_Passthr=
ough_to_Windows_8_with_Xen_4.2-unstable

    

    The above 2 are manuals which I have written myself, after studying
    several Xen Wiki Pages and Jean David Techer's notes.

    

    Now, the above 2 manuals are the same manuals which I have used to
    obtain 100% success in Xen VGA Passthrough for Frank Lyon's NVIDIA
    Quadro 6000. Yes, 100% success. Absolutely no yellow triangle with
    exclamation mark and error code 43 in Windows 7 and Windows 8 HVM
    domU. It is an irony and a joke that, with the same set of manuals
    which I have written, I cannot get 100% success in Xen VGA
    Passthrough with my very own display cards. Frank Lyon's NVIDIA
    Quadro 6000 costs S$6000++, and I can't afford it. 

    

    So now, the problem stands. I get a yellow triangle with exclamation
    mark and error code 43 in device manager for Gigabyte Geforce GTX
    560 in Windows 8 HVM domU and a yellow circle with exclamation mark
    and error code 10 in device manager for Gigabyte Geforce GTX 560 in
    Windows XP Home Edition HVM domU.

    

    The Reward

    

    1. USD$50 in cash

    2. Palit NVIDIA Geforce 8400 GS PCI Express x16 VGA card (costs
    S$44)

    

    How to Get the Reward

    

    If I can say that you have solved my Xen VGA Passthrough problem
    100%, you get the reward! Basically, the idea is to get rid of the
    yellow triangle with exclamation mark and error code 43 in Windows 8
    HVM domU and the yellow circle with exclamation mark and error code
    10 in Windows XP HVM domU.

    

    Hence,

    

    (1) If you can tell me off-hand the solution which leads to my Xen
    VGA Passthrough problem being solved 100%, you get the reward. OR

    

    (2) You have spotted mistakes or errors in the manuals which I have
    written, leading to my Xen VGA Passthrough problem being solved
    100%. You get the reward. OR

    

    (3) You have a VT-d capable motherboard and processor, and a
    compatible NVIDIA Geforce GTX 560 like mine, and follows the 2
    manuals which I have written for your Xen VGA Passthrough needs. If
    you can obtain 100% success, please tell me the mistakes or errors
    in my manuals, which leads to my Xen VGA Passthrough problem being
    solved 100%. You get the reward.

    

    100% success means no error code 43 and no error code 10.=


    

    For a start, you may follow the thread series "Help

        Needed from Xen Developers: Nasty Yellow Triangle with
        Exclamation Mark and Error Code 43 in Device Manager in Windows
        8 HVM domU" in the xen-users and xen-devel mailing lists.<=
/b>

    

    Please note that the prize money of US$50 is guaranteed and there is
    only one winner. There is no closing date for this challenge.

    

    

    
--=20
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore

  



_______________________________________________

Xen-devel mailing list

Xen-devel@lists.xen.org

http://lists.x=
en.org/xen-devel




--90e6ba61477432d99e04cb66debc--


--===============3091408667578392708==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3091408667578392708==--


From xen-devel-bounces@lists.xen.org Sat Oct 06 16:56:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Oct 2012 16:56:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TKXfw-0001jQ-3b; Sat, 06 Oct 2012 16:56:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TKXfu-0001jG-T0
	for xen-devel@lists.xen.org; Sat, 06 Oct 2012 16:56:27 +0000
Received: from [85.158.137.99:51740] by server-11.bemta-3.messagelabs.com id
	61/CE-21460-9B260705; Sat, 06 Oct 2012 16:56:25 +0000
X-Env-Sender: tknchris@gmail.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1349542582!19321051!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2366 invoked from network); 6 Oct 2012 16:56:24 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Oct 2012 16:56:24 -0000
Received: by mail-ie0-f173.google.com with SMTP id 17so8052116iea.32
	for ; Sat, 06 Oct 2012 09:56:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=91RYxmX1k+Zzf301NK3EkYi2x6YiqpHU53FJrgK717I=;
	b=XE6LvFhdNFpDGaZYaT6VEIaRwAByyv2tWfTqRssNDiTYMylV/43V0v4qoVAp4Rq23q
	mdkbDhORHIyO0WYjmWCSU5TCQsGQmYAvcPuk+IUS6hTvuBglMvkw0l8G139pCr1d1tVZ
	xcXTmNBfk6/cY2HtyrkpVnc1PvzlrIOc+LuiQowIvYdxZePXGe6Z9TieJxKRitD1rFUf
	GcVKTTLLHt+rENo4Ky5MLQ6tfWp/0jw5F71k4hYymt56FseyIK2FxZGl+YzvKSBlYxso
	0qNY+hR+NG5EysezKU9sT7br4f25yDnTmlM43cTi7dAVYfbyoubl34IljPam/PV8dd3P
	MBLg==
MIME-Version: 1.0
Received: by 10.42.65.6 with SMTP id j6mr9589819ici.2.1349542581819; Sat, 06
	Oct 2012 09:56:21 -0700 (PDT)
Received: by 10.64.41.67 with HTTP; Sat, 6 Oct 2012 09:56:21 -0700 (PDT)
Received: by 10.64.41.67 with HTTP; Sat, 6 Oct 2012 09:56:21 -0700 (PDT)
In-Reply-To: <50706112.1030801@gmail.com>
References: <50706112.1030801@gmail.com>
Date: Sat, 6 Oct 2012 12:56:21 -0400
Message-ID: 
From: chris 
To: "Teo En Ming (Zhang Enming)" 
Cc: daniel.oon@ivicinternational.com, Frank Lyon ,
	dorothy.ong@ivicinternational.com,
	"xen-devel@lists.xen.org" ,
	Tobias Geiger ,
	"xen-users@lists.xen.org" ,
	Casey DeLorme ,
	Dariusz Krempa ,
	David TECHER 
Subject: Re: [Xen-devel] I offer a reward of USD$50 + VGA card Giveaway to
 anyone who can solve my Xen VGA Passthrough Problem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============3091408667578392708=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3091408667578392708==
Content-Type: multipart/alternative; boundary=90e6ba61477432d99e04cb66debc

--90e6ba61477432d99e04cb66debc
Content-Type: text/plain; charset=ISO-8859-1

Sounds like someone is jealous of all the recent success reports :)
On Oct 6, 2012 12:51 PM, "Teo En Ming (Zhang Enming)" <
singapore.mr.teo.en.ming@gmail.com> wrote:

>  *History*
>
> I have 100% success in Xen VGA Passthrough with Xen 3.5-unstable with my
> first Palit NVIDIA Geforce 8400 GS VGA card in 2009, which is 3 years ago.
> Then my first Palit NVIDIA Geforce 8400 GS VGA card overheated and
> malfunctioned. So I bought a 2nd Palit NVIDIA Geforce 8400 GS VGA card
> several months ago in March 2012 for S$44, to replace the first card. At
> that point in time, Xen was already of version 4.2-unstable. I have tried
> to passthrough my 2nd Palit NVIDIA Geforce 8400 GS, which is only partially
> working, or partial success. *In Windows 8 HVM domU, you will see a
> yellow triangle with exclamation mark and error code 43 in Device Manager
> for the 2nd Palit NVIDIA Geforce 8400 GS. In Windows XP Home Edition HVM
> domU, you will see a yellow circle with exclamation mark and error code 10
> in Device Manager for the 2nd Palit NVIDIA Geforce 8400 GS.*
>
> Then I noticed Jean David Techer uses a Geforce 560 Ti for his Xen VGA
> Passthrough. So 1-2 weeks ago I bought a EVGA Geforce GTX 560 1 GB GDDR5
> for S$269. Same thing. Xen VGA Passthrough is only partially working or
> partial success. So I went back to the computer shop and exchanged my EVGA
> Geforce GTX 560 with a Gigabyte Geforce GTX 560 1 GB GDDR5, which costs
> S$289. Again, Xen VGA Passthrough is only partially working or partial
> success. *In Windows 8 HVM domU, you will see a yellow triangle with
> exclamation mark and error code 43 in Device Manager for the Gigabyte
> Geforce GTX 560. In Windows XP Home Edition HVM domU, you will see a yellow
> circle with exclamation mark and error code 10 in Device Manager for the
> Gigabyte Geforce GTX 560.*
>
> *The Challenge*
>
> My computer hardware specifications:
>
> Processor: Intel Pentium Dual Core E2300 @ 2.8 GHz
> Motherboard: Intel DQ45CB Desktop Board with VT-d enabled
> VGA Card: Gigabyte Geforce GTX 560 1 GB GDDR5
> Memory: 6 GB
>
> My computer software specifications:
>
> Host operating system: Ubuntu 12.04.1 LTS Desktop Linux
> Xen Hypervisor version: (a) Xen 4.2-unstable Changeset 25099 (b) Xen
> 4.2.1-pre (c) Xen 4.3-unstable Changeset 25993
> Linux Dom0 Kernel: (a) 3.5.4 (b) 3.6.0-rc7
> Windows HVM domU: (a) Windows XP Home Edition SP3 (b) Windows 8 Release
> Preview 64-bit
>
> Manuals which I have followed in getting Xen VGA Passthrough done:
>
> (1)
> http://wiki.xen.org/wiki/Building_and_Installing_Xen_4.x_and_Linux_Kernel_3.x_on_Ubuntu_and_Debian_Linux
>
> (2)
> http://wiki.xen.org/wiki/Xen_VGA_Passthrough_to_Windows_8_with_Xen_4.2-unstable
>
> The above 2 are manuals which I have written myself, after studying
> several Xen Wiki Pages and Jean David Techer's notes.
>
> Now, the above 2 manuals are the same manuals which I have used to obtain
> 100% success in Xen VGA Passthrough for Frank Lyon's NVIDIA Quadro 6000.
> Yes, 100% success. Absolutely no yellow triangle with exclamation mark and
> error code 43 in Windows 7 and Windows 8 HVM domU. It is an irony and a
> joke that, with the same set of manuals which I have written, I cannot get
> 100% success in Xen VGA Passthrough with my very own display cards. Frank
> Lyon's NVIDIA Quadro 6000 costs S$6000++, and I can't afford it.
>
> So now, the problem stands. I get a yellow triangle with exclamation mark
> and error code 43 in device manager for Gigabyte Geforce GTX 560 in Windows
> 8 HVM domU and a yellow circle with exclamation mark and error code 10 in
> device manager for Gigabyte Geforce GTX 560 in Windows XP Home Edition HVM
> domU.
>
> *The Reward*
>
> 1. USD$50 in cash
> 2. Palit NVIDIA Geforce 8400 GS PCI Express x16 VGA card (costs S$44)
>
> *How to Get the Reward*
>
> If I can say that you have solved my Xen VGA Passthrough problem 100%, you
> get the reward! Basically, the idea is to get rid of the yellow triangle
> with exclamation mark and error code 43 in Windows 8 HVM domU and the
> yellow circle with exclamation mark and error code 10 in Windows XP HVM
> domU.
>
> Hence,
>
> (1) If you can tell me off-hand the solution which leads to my Xen VGA
> Passthrough problem being solved 100%, you get the reward. OR
>
> (2) You have spotted mistakes or errors in the manuals which I have
> written, leading to my Xen VGA Passthrough problem being solved 100%. You
> get the reward. OR
>
> (3) You have a VT-d capable motherboard and processor, and a compatible
> NVIDIA Geforce GTX 560 like mine, and follows the 2 manuals which I have
> written for your Xen VGA Passthrough needs. If you can obtain 100% success,
> please tell me the mistakes or errors in my manuals, which leads to my Xen
> VGA Passthrough problem being solved 100%. You get the reward.
>
> *100% success means no error code 43 and no error code 10.*
>
> For a start, you may follow the thread series "*Help Needed from Xen
> Developers: Nasty Yellow Triangle with Exclamation Mark and Error Code 43
> in Device Manager in Windows 8 HVM domU"
> in the xen-users and xen-devel mailing lists.*
>
> Please note that the prize money of US$50 is guaranteed and there is only
> one winner. There is no closing date for this challenge.
>
>
> --
> Yours sincerely,
>
> Mr. Teo En Ming (Zhang Enming)
> Singapore
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
>

--90e6ba61477432d99e04cb66debc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Sounds like someone is jealous of all the recent success rep=
orts :)


On Oct 6, 2012 12:51 PM, "Teo En Ming (Zhan=
g Enming)" <s=
ingapore.mr.teo.en.ming@gmail.com> wrote:


 =20
   =20
 =20
  

    History

    

    I have 100% success in Xen VGA Passthrough with Xen 3.5-unstable
    with my first Palit NVIDIA Geforce 8400 GS VGA card in 2009, which
    is 3 years ago. Then my first Palit NVIDIA Geforce 8400 GS VGA card
    overheated and malfunctioned. So I bought a 2nd Palit NVIDIA Geforce
    8400 GS VGA card several months ago in March 2012 for S$44, to
    replace the first card. At that point in time, Xen was already of
    version 4.2-unstable. I have tried to passthrough my 2nd Palit
    NVIDIA Geforce 8400 GS, which is only partially working, or partial
    success. In Windows 8 HVM domU, you will see a yellow triangle
      with exclamation mark and error code 43 in Device Manager for the
      2nd Palit NVIDIA Geforce 8400 GS. In Windows XP Home Edition HVM
      domU, you will see a yellow circle with exclamation mark and error
      code 10 in Device Manager for the 2nd Palit NVIDIA Geforce 8400
      GS.

    

    Then I noticed Jean David Techer uses a Geforce 560 Ti for his Xen
    VGA Passthrough. So 1-2 weeks ago I bought a EVGA Geforce GTX 560 1
    GB GDDR5 for S$269. Same thing. Xen VGA Passthrough is only
    partially working or partial success. So I went back to the computer
    shop and exchanged my EVGA Geforce GTX 560 with a Gigabyte Geforce
    GTX 560 1 GB GDDR5, which costs S$289. Again, Xen VGA Passthrough is
    only partially working or partial success. In Windows 8 HVM
      domU, you will see a yellow triangle with exclamation mark and
      error code 43 in Device Manager for the Gigabyte Geforce GTX 560.
      In Windows XP Home Edition HVM domU, you will see a yellow circle
      with exclamation mark and error code 10 in Device Manager for the
      Gigabyte Geforce GTX 560.

    

    The Challenge

    

    My computer hardware specifications:

    

    Processor: Intel Pentium Dual Core E2300 @ 2.8 GHz

    Motherboard: Intel DQ45CB Desktop Board with VT-d enabled

    VGA Card: Gigabyte Geforce GTX 560 1 GB GDDR5

    Memory: 6 GB

    

    My computer software specifications:

    

    Host operating system: Ubuntu 12.04.1 LTS Desktop Linux

    Xen Hypervisor version: (a) Xen 4.2-unstable Changeset 25099 (b) Xen
    4.2.1-pre (c) Xen 4.3-unstable Changeset 25993

    Linux Dom0 Kernel: (a) 3.5.4 (b) 3.6.0-rc7

    Windows HVM domU: (a) Windows XP Home Edition SP3 (b) Windows 8
    Release Preview 64-bit

    

    Manuals which I have followed in getting Xen VGA Passthrough done:

    

    (1)
http://wiki.xen=
.org/wiki/Building_and_Installing_Xen_4.x_and_Linux_Kernel_3.x_on_Ubuntu_an=
d_Debian_Linux


    

    (2)
http://wiki.xen.org/wiki/Xen_VGA_Passthr=
ough_to_Windows_8_with_Xen_4.2-unstable

    

    The above 2 are manuals which I have written myself, after studying
    several Xen Wiki Pages and Jean David Techer's notes.

    

    Now, the above 2 manuals are the same manuals which I have used to
    obtain 100% success in Xen VGA Passthrough for Frank Lyon's NVIDIA
    Quadro 6000. Yes, 100% success. Absolutely no yellow triangle with
    exclamation mark and error code 43 in Windows 7 and Windows 8 HVM
    domU. It is an irony and a joke that, with the same set of manuals
    which I have written, I cannot get 100% success in Xen VGA
    Passthrough with my very own display cards. Frank Lyon's NVIDIA
    Quadro 6000 costs S$6000++, and I can't afford it. 

    

    So now, the problem stands. I get a yellow triangle with exclamation
    mark and error code 43 in device manager for Gigabyte Geforce GTX
    560 in Windows 8 HVM domU and a yellow circle with exclamation mark
    and error code 10 in device manager for Gigabyte Geforce GTX 560 in
    Windows XP Home Edition HVM domU.

    

    The Reward

    

    1. USD$50 in cash

    2. Palit NVIDIA Geforce 8400 GS PCI Express x16 VGA card (costs
    S$44)

    

    How to Get the Reward

    

    If I can say that you have solved my Xen VGA Passthrough problem
    100%, you get the reward! Basically, the idea is to get rid of the
    yellow triangle with exclamation mark and error code 43 in Windows 8
    HVM domU and the yellow circle with exclamation mark and error code
    10 in Windows XP HVM domU.

    

    Hence,

    

    (1) If you can tell me off-hand the solution which leads to my Xen
    VGA Passthrough problem being solved 100%, you get the reward. OR

    

    (2) You have spotted mistakes or errors in the manuals which I have
    written, leading to my Xen VGA Passthrough problem being solved
    100%. You get the reward. OR

    

    (3) You have a VT-d capable motherboard and processor, and a
    compatible NVIDIA Geforce GTX 560 like mine, and follows the 2
    manuals which I have written for your Xen VGA Passthrough needs. If
    you can obtain 100% success, please tell me the mistakes or errors
    in my manuals, which leads to my Xen VGA Passthrough problem being
    solved 100%. You get the reward.

    

    100% success means no error code 43 and no error code 10.=


    

    For a start, you may follow the thread series "Help

        Needed from Xen Developers: Nasty Yellow Triangle with
        Exclamation Mark and Error Code 43 in Device Manager in Windows
        8 HVM domU" in the xen-users and xen-devel mailing lists.<=
/b>

    

    Please note that the prize money of US$50 is guaranteed and there is
    only one winner. There is no closing date for this challenge.

    

    

    
--=20
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore

  



_______________________________________________

Xen-devel mailing list

Xen-devel@lists.xen.org

http://lists.x=
en.org/xen-devel




--90e6ba61477432d99e04cb66debc--


--===============3091408667578392708==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3091408667578392708==--


From xen-devel-bounces@lists.xen.org Sat Oct 06 17:20:45 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Oct 2012 17:20:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TKY32-0002DP-5X; Sat, 06 Oct 2012 17:20:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TKY2z-0002DF-Ls
	for xen-devel@lists.xen.org; Sat, 06 Oct 2012 17:20:18 +0000
Received: from [85.158.138.51:9718] by server-5.bemta-3.messagelabs.com id
	B2/3C-00589-05860705; Sat, 06 Oct 2012 17:20:16 +0000
X-Env-Sender: singapore.mr.teo.en.ming@gmail.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1349544012!33279098!1
X-Originating-IP: [209.85.220.45]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12061 invoked from network); 6 Oct 2012 17:20:14 -0000
Received: from mail-pa0-f45.google.com (HELO mail-pa0-f45.google.com)
	(209.85.220.45)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Oct 2012 17:20:14 -0000
Received: by mail-pa0-f45.google.com with SMTP id fb10so2845662pad.32
	for ; Sat, 06 Oct 2012 10:20:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type;
	bh=WJSGkUilK9glMY2X0SWZ4U4PveSB0DN5K0K7M6DnYMw=;
	b=TNxoCUIf/RNG4QK4UX2GYjClZJofMufUqZRmYVfHHP0l4KvKROA2wz24fWHktV5zcJ
	Sb2P7B/3M3e7dYK8yntp6Rl32FN9CpXwGFo3pUA8If7cn7VgFdYhZzkJO0pEi4Pg1kFi
	yhE9rsS504gPlJwqCHyv7Kn5C4ZuT9WDw+rMnUfFYxlL8alQDEkRlHcV3XCVaMUaut9G
	eJ7ExVoKo95k+eBXcMq79qcXQNxgN14xIEm+3rDfKt2HAIwMcfA9KYjxd5pBb4pV4fl2
	EvsW9NzCsOwf1aPPpZFsjaoJbbbSSy+j2L0Wbrz0tOwijZqv6HyQn3nUsp1BEqGd0tOk
	F9Wg==
Received: by 10.68.241.137 with SMTP id wi9mr39742092pbc.158.1349544012037;
	Sat, 06 Oct 2012 10:20:12 -0700 (PDT)
Received: from [192.168.1.2] (cm152.gamma205.maxonline.com.sg.
	[202.156.205.152])
	by mx.google.com with ESMTPS id n3sm6808723paz.25.2012.10.06.10.20.09
	(version=SSLv3 cipher=OTHER); Sat, 06 Oct 2012 10:20:11 -0700 (PDT)
Message-ID: <50706848.9090104@gmail.com>
Date: Sun, 07 Oct 2012 01:20:08 +0800
From: "Teo En Ming (Zhang Enming)" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: "xen-users@lists.xen.org" 
References: <50706112.1030801@gmail.com>
	
In-Reply-To: 
Cc: "Teo En Ming \(Zhang Enming\)" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] I offer a reward of USD$50 + VGA card Giveaway to
 anyone who can solve my Xen VGA Passthrough Problem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============6252828551598041009=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============6252828551598041009==
Content-Type: multipart/alternative;
 boundary="------------090403070709090405080300"

This is a multi-part message in MIME format.
--------------090403070709090405080300
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

LOL. My Xen VGA Passthrough problem is long overdue. I have been trying 
to fix the problem since March 2012.

-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore



On 07/10/2012 00:56, chris wrote:
>
> Sounds like someone is jealous of all the recent success reports :)
>
> On Oct 6, 2012 12:51 PM, "Teo En Ming (Zhang Enming)" 
>  > wrote:
>
>     _History_
>
>     I have 100% success in Xen VGA Passthrough with Xen 3.5-unstable
>     with my first Palit NVIDIA Geforce 8400 GS VGA card in 2009, which
>     is 3 years ago. Then my first Palit NVIDIA Geforce 8400 GS VGA
>     card overheated and malfunctioned. So I bought a 2nd Palit NVIDIA
>     Geforce 8400 GS VGA card several months ago in March 2012 for
>     S$44, to replace the first card. At that point in time, Xen was
>     already of version 4.2-unstable. I have tried to passthrough my
>     2nd Palit NVIDIA Geforce 8400 GS, which is only partially working,
>     or partial success. _In Windows 8 HVM domU, you will see a yellow
>     triangle with exclamation mark and error code 43 in Device Manager
>     for the 2nd Palit NVIDIA Geforce 8400 GS. In Windows XP Home
>     Edition HVM domU, you will see a yellow circle with exclamation
>     mark and error code 10 in Device Manager for the 2nd Palit NVIDIA
>     Geforce 8400 GS._
>
>     Then I noticed Jean David Techer uses a Geforce 560 Ti for his Xen
>     VGA Passthrough. So 1-2 weeks ago I bought a EVGA Geforce GTX 560
>     1 GB GDDR5 for S$269. Same thing. Xen VGA Passthrough is only
>     partially working or partial success. So I went back to the
>     computer shop and exchanged my EVGA Geforce GTX 560 with a
>     Gigabyte Geforce GTX 560 1 GB GDDR5, which costs S$289. Again, Xen
>     VGA Passthrough is only partially working or partial success. _In
>     Windows 8 HVM domU, you will see a yellow triangle with
>     exclamation mark and error code 43 in Device Manager for the
>     Gigabyte Geforce GTX 560. In Windows XP Home Edition HVM domU, you
>     will see a yellow circle with exclamation mark and error code 10
>     in Device Manager for the Gigabyte Geforce GTX 560._
>
>     _The Challenge_
>
>     My computer hardware specifications:
>
>     Processor: Intel Pentium Dual Core E2300 @ 2.8 GHz
>     Motherboard: Intel DQ45CB Desktop Board with VT-d enabled
>     VGA Card: Gigabyte Geforce GTX 560 1 GB GDDR5
>     Memory: 6 GB
>
>     My computer software specifications:
>
>     Host operating system: Ubuntu 12.04.1 LTS Desktop Linux
>     Xen Hypervisor version: (a) Xen 4.2-unstable Changeset 25099 (b)
>     Xen 4.2.1-pre (c) Xen 4.3-unstable Changeset 25993
>     Linux Dom0 Kernel: (a) 3.5.4 (b) 3.6.0-rc7
>     Windows HVM domU: (a) Windows XP Home Edition SP3 (b) Windows 8
>     Release Preview 64-bit
>
>     Manuals which I have followed in getting Xen VGA Passthrough done:
>
>     (1)
>     http://wiki.xen.org/wiki/Building_and_Installing_Xen_4.x_and_Linux_Kernel_3.x_on_Ubuntu_and_Debian_Linux
>
>     (2)
>     http://wiki.xen.org/wiki/Xen_VGA_Passthrough_to_Windows_8_with_Xen_4.2-unstable
>
>     The above 2 are manuals which I have written myself, after
>     studying several Xen Wiki Pages and Jean David Techer's notes.
>
>     Now, the above 2 manuals are the same manuals which I have used to
>     obtain 100% success in Xen VGA Passthrough for Frank Lyon's NVIDIA
>     Quadro 6000. Yes, 100% success. Absolutely no yellow triangle with
>     exclamation mark and error code 43 in Windows 7 and Windows 8 HVM
>     domU. It is an irony and a joke that, with the same set of manuals
>     which I have written, I cannot get 100% success in Xen VGA
>     Passthrough with my very own display cards. Frank Lyon's NVIDIA
>     Quadro 6000 costs S$6000++, and I can't afford it.
>
>     So now, the problem stands. I get a yellow triangle with
>     exclamation mark and error code 43 in device manager for Gigabyte
>     Geforce GTX 560 in Windows 8 HVM domU and a yellow circle with
>     exclamation mark and error code 10 in device manager for Gigabyte
>     Geforce GTX 560 in Windows XP Home Edition HVM domU.
>
>     _The Reward_
>
>     1. USD$50 in cash
>     2. Palit NVIDIA Geforce 8400 GS PCI Express x16 VGA card (costs S$44)
>
>     _How to Get the Reward_
>
>     If I can say that you have solved my Xen VGA Passthrough problem
>     100%, you get the reward! Basically, the idea is to get rid of the
>     yellow triangle with exclamation mark and error code 43 in Windows
>     8 HVM domU and the yellow circle with exclamation mark and error
>     code 10 in Windows XP HVM domU.
>
>     Hence,
>
>     (1) If you can tell me off-hand the solution which leads to my Xen
>     VGA Passthrough problem being solved 100%, you get the reward. OR
>
>     (2) You have spotted mistakes or errors in the manuals which I
>     have written, leading to my Xen VGA Passthrough problem being
>     solved 100%. You get the reward. OR
>
>     (3) You have a VT-d capable motherboard and processor, and a
>     compatible NVIDIA Geforce GTX 560 like mine, and follows the 2
>     manuals which I have written for your Xen VGA Passthrough needs.
>     If you can obtain 100% success, please tell me the mistakes or
>     errors in my manuals, which leads to my Xen VGA Passthrough
>     problem being solved 100%. You get the reward.
>
>     *_100% success means no error code 43 and no error code 10._*
>
>     For a start, you may follow the thread series "*Help Needed from
>     Xen Developers: Nasty Yellow Triangle with Exclamation Mark and
>     Error Code 43 in Device Manager in Windows 8 HVM domU
>     "
>     in the xen-users and xen-devel mailing lists.*
>
>     Please note that the prize money of US$50 is guaranteed and there
>     is only one winner. There is no closing date for this challenge.
>
>
>     -- 
>     Yours sincerely,
>
>     Mr. Teo En Ming (Zhang Enming)
>     Singapore
>
>
>     _______________________________________________
>     Xen-devel mailing list
>     Xen-devel@lists.xen.org 
>     http://lists.xen.org/xen-devel
>



--------------090403070709090405080300
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
LOL. My Xen VGA Passthrough problem is
      long overdue. I have been trying to fix the problem since March
      2012.

      

      
-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore

      

      

      On 07/10/2012 00:56, chris wrote:

    

    

      
Sounds like someone is jealous of all the recent
        success reports :)

      
On Oct 6, 2012 12:51 PM, "Teo En Ming
        (Zhang Enming)" <singapore.mr.teo.en.ming@gmail.com>
        wrote:

        

          
 History

            

            I have 100% success in Xen VGA Passthrough with Xen
            3.5-unstable with my first Palit NVIDIA Geforce 8400 GS VGA
            card in 2009, which is 3 years ago. Then my first Palit
            NVIDIA Geforce 8400 GS VGA card overheated and
            malfunctioned. So I bought a 2nd Palit NVIDIA Geforce 8400
            GS VGA card several months ago in March 2012 for S$44, to
            replace the first card. At that point in time, Xen was
            already of version 4.2-unstable. I have tried to passthrough
            my 2nd Palit NVIDIA Geforce 8400 GS, which is only partially
            working, or partial success. In Windows 8 HVM domU, you
              will see a yellow triangle with exclamation mark and error
              code 43 in Device Manager for the 2nd Palit NVIDIA Geforce
              8400 GS. In Windows XP Home Edition HVM domU, you will see
              a yellow circle with exclamation mark and error code 10 in
              Device Manager for the 2nd Palit NVIDIA Geforce 8400 GS.

            

            Then I noticed Jean David Techer uses a Geforce 560 Ti for
            his Xen VGA Passthrough. So 1-2 weeks ago I bought a EVGA
            Geforce GTX 560 1 GB GDDR5 for S$269. Same thing. Xen VGA
            Passthrough is only partially working or partial success. So
            I went back to the computer shop and exchanged my EVGA
            Geforce GTX 560 with a Gigabyte Geforce GTX 560 1 GB GDDR5,
            which costs S$289. Again, Xen VGA Passthrough is only
            partially working or partial success. In Windows 8 HVM
              domU, you will see a yellow triangle with exclamation mark
              and error code 43 in Device Manager for the Gigabyte
              Geforce GTX 560. In Windows XP Home Edition HVM domU, you
              will see a yellow circle with exclamation mark and error
              code 10 in Device Manager for the Gigabyte Geforce GTX
              560.

            

            The Challenge

            

            My computer hardware specifications:

            

            Processor: Intel Pentium Dual Core E2300 @ 2.8 GHz

            Motherboard: Intel DQ45CB Desktop Board with VT-d enabled

            VGA Card: Gigabyte Geforce GTX 560 1 GB GDDR5

            Memory: 6 GB

            

            My computer software specifications:

            

            Host operating system: Ubuntu 12.04.1 LTS Desktop Linux

            Xen Hypervisor version: (a) Xen 4.2-unstable Changeset 25099
            (b) Xen 4.2.1-pre (c) Xen 4.3-unstable Changeset 25993

            Linux Dom0 Kernel: (a) 3.5.4 (b) 3.6.0-rc7

            Windows HVM domU: (a) Windows XP Home Edition SP3 (b)
            Windows 8 Release Preview 64-bit

            

            Manuals which I have followed in getting Xen VGA Passthrough
            done:

            

            (1)
            http://wiki.xen.org/wiki/Building_and_Installing_Xen_4.x_and_Linux_Kernel_3.x_on_Ubuntu_and_Debian_Linux

            

            (2)
            http://wiki.xen.org/wiki/Xen_VGA_Passthrough_to_Windows_8_with_Xen_4.2-unstable

            

            The above 2 are manuals which I have written myself, after
            studying several Xen Wiki Pages and Jean David Techer's
            notes.

            

            Now, the above 2 manuals are the same manuals which I have
            used to obtain 100% success in Xen VGA Passthrough for Frank
            Lyon's NVIDIA Quadro 6000. Yes, 100% success. Absolutely no
            yellow triangle with exclamation mark and error code 43 in
            Windows 7 and Windows 8 HVM domU. It is an irony and a joke
            that, with the same set of manuals which I have written, I
            cannot get 100% success in Xen VGA Passthrough with my very
            own display cards. Frank Lyon's NVIDIA Quadro 6000 costs
            S$6000++, and I can't afford it. 

            

            So now, the problem stands. I get a yellow triangle with
            exclamation mark and error code 43 in device manager for
            Gigabyte Geforce GTX 560 in Windows 8 HVM domU and a yellow
            circle with exclamation mark and error code 10 in device
            manager for Gigabyte Geforce GTX 560 in Windows XP Home
            Edition HVM domU.

            

            The Reward

            

            1. USD$50 in cash

            2. Palit NVIDIA Geforce 8400 GS PCI Express x16 VGA card
            (costs S$44)

            

            How to Get the Reward

            

            If I can say that you have solved my Xen VGA Passthrough
            problem 100%, you get the reward! Basically, the idea is to
            get rid of the yellow triangle with exclamation mark and
            error code 43 in Windows 8 HVM domU and the yellow circle
            with exclamation mark and error code 10 in Windows XP HVM
            domU.

            

            Hence,

            

            (1) If you can tell me off-hand the solution which leads to
            my Xen VGA Passthrough problem being solved 100%, you get
            the reward. OR

            

            (2) You have spotted mistakes or errors in the manuals which
            I have written, leading to my Xen VGA Passthrough problem
            being solved 100%. You get the reward. OR

            

            (3) You have a VT-d capable motherboard and processor, and a
            compatible NVIDIA Geforce GTX 560 like mine, and follows the
            2 manuals which I have written for your Xen VGA Passthrough
            needs. If you can obtain 100% success, please tell me the
            mistakes or errors in my manuals, which leads to my Xen VGA
            Passthrough problem being solved 100%. You get the reward.

            

            100% success means no error code 43 and no error code
                10.

            

            For a start, you may follow the thread series "Help Needed from Xen Developers: Nasty
                Yellow Triangle with Exclamation Mark and Error Code 43
                in Device Manager in Windows 8 HVM domU" in the
              xen-users and xen-devel mailing lists.

            

            Please note that the prize money of US$50 is guaranteed and
            there is only one winner. There is no closing date for this
            challenge.

            

            

            
-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore

          

          

          _______________________________________________

          Xen-devel mailing list

          Xen-devel@lists.xen.org

          http://lists.xen.org/xen-devel

          

        

      

    

    

    

    

  


--------------090403070709090405080300--


--===============6252828551598041009==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6252828551598041009==--


From xen-devel-bounces@lists.xen.org Sat Oct 06 17:20:45 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Oct 2012 17:20:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TKY32-0002DP-5X; Sat, 06 Oct 2012 17:20:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TKY2z-0002DF-Ls
	for xen-devel@lists.xen.org; Sat, 06 Oct 2012 17:20:18 +0000
Received: from [85.158.138.51:9718] by server-5.bemta-3.messagelabs.com id
	B2/3C-00589-05860705; Sat, 06 Oct 2012 17:20:16 +0000
X-Env-Sender: singapore.mr.teo.en.ming@gmail.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1349544012!33279098!1
X-Originating-IP: [209.85.220.45]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12061 invoked from network); 6 Oct 2012 17:20:14 -0000
Received: from mail-pa0-f45.google.com (HELO mail-pa0-f45.google.com)
	(209.85.220.45)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Oct 2012 17:20:14 -0000
Received: by mail-pa0-f45.google.com with SMTP id fb10so2845662pad.32
	for ; Sat, 06 Oct 2012 10:20:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type;
	bh=WJSGkUilK9glMY2X0SWZ4U4PveSB0DN5K0K7M6DnYMw=;
	b=TNxoCUIf/RNG4QK4UX2GYjClZJofMufUqZRmYVfHHP0l4KvKROA2wz24fWHktV5zcJ
	Sb2P7B/3M3e7dYK8yntp6Rl32FN9CpXwGFo3pUA8If7cn7VgFdYhZzkJO0pEi4Pg1kFi
	yhE9rsS504gPlJwqCHyv7Kn5C4ZuT9WDw+rMnUfFYxlL8alQDEkRlHcV3XCVaMUaut9G
	eJ7ExVoKo95k+eBXcMq79qcXQNxgN14xIEm+3rDfKt2HAIwMcfA9KYjxd5pBb4pV4fl2
	EvsW9NzCsOwf1aPPpZFsjaoJbbbSSy+j2L0Wbrz0tOwijZqv6HyQn3nUsp1BEqGd0tOk
	F9Wg==
Received: by 10.68.241.137 with SMTP id wi9mr39742092pbc.158.1349544012037;
	Sat, 06 Oct 2012 10:20:12 -0700 (PDT)
Received: from [192.168.1.2] (cm152.gamma205.maxonline.com.sg.
	[202.156.205.152])
	by mx.google.com with ESMTPS id n3sm6808723paz.25.2012.10.06.10.20.09
	(version=SSLv3 cipher=OTHER); Sat, 06 Oct 2012 10:20:11 -0700 (PDT)
Message-ID: <50706848.9090104@gmail.com>
Date: Sun, 07 Oct 2012 01:20:08 +0800
From: "Teo En Ming (Zhang Enming)" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: "xen-users@lists.xen.org" 
References: <50706112.1030801@gmail.com>
	
In-Reply-To: 
Cc: "Teo En Ming \(Zhang Enming\)" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] I offer a reward of USD$50 + VGA card Giveaway to
 anyone who can solve my Xen VGA Passthrough Problem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============6252828551598041009=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============6252828551598041009==
Content-Type: multipart/alternative;
 boundary="------------090403070709090405080300"

This is a multi-part message in MIME format.
--------------090403070709090405080300
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

LOL. My Xen VGA Passthrough problem is long overdue. I have been trying 
to fix the problem since March 2012.

-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore



On 07/10/2012 00:56, chris wrote:
>
> Sounds like someone is jealous of all the recent success reports :)
>
> On Oct 6, 2012 12:51 PM, "Teo En Ming (Zhang Enming)" 
>  > wrote:
>
>     _History_
>
>     I have 100% success in Xen VGA Passthrough with Xen 3.5-unstable
>     with my first Palit NVIDIA Geforce 8400 GS VGA card in 2009, which
>     is 3 years ago. Then my first Palit NVIDIA Geforce 8400 GS VGA
>     card overheated and malfunctioned. So I bought a 2nd Palit NVIDIA
>     Geforce 8400 GS VGA card several months ago in March 2012 for
>     S$44, to replace the first card. At that point in time, Xen was
>     already of version 4.2-unstable. I have tried to passthrough my
>     2nd Palit NVIDIA Geforce 8400 GS, which is only partially working,
>     or partial success. _In Windows 8 HVM domU, you will see a yellow
>     triangle with exclamation mark and error code 43 in Device Manager
>     for the 2nd Palit NVIDIA Geforce 8400 GS. In Windows XP Home
>     Edition HVM domU, you will see a yellow circle with exclamation
>     mark and error code 10 in Device Manager for the 2nd Palit NVIDIA
>     Geforce 8400 GS._
>
>     Then I noticed Jean David Techer uses a Geforce 560 Ti for his Xen
>     VGA Passthrough. So 1-2 weeks ago I bought a EVGA Geforce GTX 560
>     1 GB GDDR5 for S$269. Same thing. Xen VGA Passthrough is only
>     partially working or partial success. So I went back to the
>     computer shop and exchanged my EVGA Geforce GTX 560 with a
>     Gigabyte Geforce GTX 560 1 GB GDDR5, which costs S$289. Again, Xen
>     VGA Passthrough is only partially working or partial success. _In
>     Windows 8 HVM domU, you will see a yellow triangle with
>     exclamation mark and error code 43 in Device Manager for the
>     Gigabyte Geforce GTX 560. In Windows XP Home Edition HVM domU, you
>     will see a yellow circle with exclamation mark and error code 10
>     in Device Manager for the Gigabyte Geforce GTX 560._
>
>     _The Challenge_
>
>     My computer hardware specifications:
>
>     Processor: Intel Pentium Dual Core E2300 @ 2.8 GHz
>     Motherboard: Intel DQ45CB Desktop Board with VT-d enabled
>     VGA Card: Gigabyte Geforce GTX 560 1 GB GDDR5
>     Memory: 6 GB
>
>     My computer software specifications:
>
>     Host operating system: Ubuntu 12.04.1 LTS Desktop Linux
>     Xen Hypervisor version: (a) Xen 4.2-unstable Changeset 25099 (b)
>     Xen 4.2.1-pre (c) Xen 4.3-unstable Changeset 25993
>     Linux Dom0 Kernel: (a) 3.5.4 (b) 3.6.0-rc7
>     Windows HVM domU: (a) Windows XP Home Edition SP3 (b) Windows 8
>     Release Preview 64-bit
>
>     Manuals which I have followed in getting Xen VGA Passthrough done:
>
>     (1)
>     http://wiki.xen.org/wiki/Building_and_Installing_Xen_4.x_and_Linux_Kernel_3.x_on_Ubuntu_and_Debian_Linux
>
>     (2)
>     http://wiki.xen.org/wiki/Xen_VGA_Passthrough_to_Windows_8_with_Xen_4.2-unstable
>
>     The above 2 are manuals which I have written myself, after
>     studying several Xen Wiki Pages and Jean David Techer's notes.
>
>     Now, the above 2 manuals are the same manuals which I have used to
>     obtain 100% success in Xen VGA Passthrough for Frank Lyon's NVIDIA
>     Quadro 6000. Yes, 100% success. Absolutely no yellow triangle with
>     exclamation mark and error code 43 in Windows 7 and Windows 8 HVM
>     domU. It is an irony and a joke that, with the same set of manuals
>     which I have written, I cannot get 100% success in Xen VGA
>     Passthrough with my very own display cards. Frank Lyon's NVIDIA
>     Quadro 6000 costs S$6000++, and I can't afford it.
>
>     So now, the problem stands. I get a yellow triangle with
>     exclamation mark and error code 43 in device manager for Gigabyte
>     Geforce GTX 560 in Windows 8 HVM domU and a yellow circle with
>     exclamation mark and error code 10 in device manager for Gigabyte
>     Geforce GTX 560 in Windows XP Home Edition HVM domU.
>
>     _The Reward_
>
>     1. USD$50 in cash
>     2. Palit NVIDIA Geforce 8400 GS PCI Express x16 VGA card (costs S$44)
>
>     _How to Get the Reward_
>
>     If I can say that you have solved my Xen VGA Passthrough problem
>     100%, you get the reward! Basically, the idea is to get rid of the
>     yellow triangle with exclamation mark and error code 43 in Windows
>     8 HVM domU and the yellow circle with exclamation mark and error
>     code 10 in Windows XP HVM domU.
>
>     Hence,
>
>     (1) If you can tell me off-hand the solution which leads to my Xen
>     VGA Passthrough problem being solved 100%, you get the reward. OR
>
>     (2) You have spotted mistakes or errors in the manuals which I
>     have written, leading to my Xen VGA Passthrough problem being
>     solved 100%. You get the reward. OR
>
>     (3) You have a VT-d capable motherboard and processor, and a
>     compatible NVIDIA Geforce GTX 560 like mine, and follows the 2
>     manuals which I have written for your Xen VGA Passthrough needs.
>     If you can obtain 100% success, please tell me the mistakes or
>     errors in my manuals, which leads to my Xen VGA Passthrough
>     problem being solved 100%. You get the reward.
>
>     *_100% success means no error code 43 and no error code 10._*
>
>     For a start, you may follow the thread series "*Help Needed from
>     Xen Developers: Nasty Yellow Triangle with Exclamation Mark and
>     Error Code 43 in Device Manager in Windows 8 HVM domU
>     "
>     in the xen-users and xen-devel mailing lists.*
>
>     Please note that the prize money of US$50 is guaranteed and there
>     is only one winner. There is no closing date for this challenge.
>
>
>     -- 
>     Yours sincerely,
>
>     Mr. Teo En Ming (Zhang Enming)
>     Singapore
>
>
>     _______________________________________________
>     Xen-devel mailing list
>     Xen-devel@lists.xen.org 
>     http://lists.xen.org/xen-devel
>



--------------090403070709090405080300
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
LOL. My Xen VGA Passthrough problem is
      long overdue. I have been trying to fix the problem since March
      2012.

      

      
-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore

      

      

      On 07/10/2012 00:56, chris wrote:

    

    

      
Sounds like someone is jealous of all the recent
        success reports :)

      
On Oct 6, 2012 12:51 PM, "Teo En Ming
        (Zhang Enming)" <singapore.mr.teo.en.ming@gmail.com>
        wrote:

        

          
 History

            

            I have 100% success in Xen VGA Passthrough with Xen
            3.5-unstable with my first Palit NVIDIA Geforce 8400 GS VGA
            card in 2009, which is 3 years ago. Then my first Palit
            NVIDIA Geforce 8400 GS VGA card overheated and
            malfunctioned. So I bought a 2nd Palit NVIDIA Geforce 8400
            GS VGA card several months ago in March 2012 for S$44, to
            replace the first card. At that point in time, Xen was
            already of version 4.2-unstable. I have tried to passthrough
            my 2nd Palit NVIDIA Geforce 8400 GS, which is only partially
            working, or partial success. In Windows 8 HVM domU, you
              will see a yellow triangle with exclamation mark and error
              code 43 in Device Manager for the 2nd Palit NVIDIA Geforce
              8400 GS. In Windows XP Home Edition HVM domU, you will see
              a yellow circle with exclamation mark and error code 10 in
              Device Manager for the 2nd Palit NVIDIA Geforce 8400 GS.

            

            Then I noticed Jean David Techer uses a Geforce 560 Ti for
            his Xen VGA Passthrough. So 1-2 weeks ago I bought a EVGA
            Geforce GTX 560 1 GB GDDR5 for S$269. Same thing. Xen VGA
            Passthrough is only partially working or partial success. So
            I went back to the computer shop and exchanged my EVGA
            Geforce GTX 560 with a Gigabyte Geforce GTX 560 1 GB GDDR5,
            which costs S$289. Again, Xen VGA Passthrough is only
            partially working or partial success. In Windows 8 HVM
              domU, you will see a yellow triangle with exclamation mark
              and error code 43 in Device Manager for the Gigabyte
              Geforce GTX 560. In Windows XP Home Edition HVM domU, you
              will see a yellow circle with exclamation mark and error
              code 10 in Device Manager for the Gigabyte Geforce GTX
              560.

            

            The Challenge

            

            My computer hardware specifications:

            

            Processor: Intel Pentium Dual Core E2300 @ 2.8 GHz

            Motherboard: Intel DQ45CB Desktop Board with VT-d enabled

            VGA Card: Gigabyte Geforce GTX 560 1 GB GDDR5

            Memory: 6 GB

            

            My computer software specifications:

            

            Host operating system: Ubuntu 12.04.1 LTS Desktop Linux

            Xen Hypervisor version: (a) Xen 4.2-unstable Changeset 25099
            (b) Xen 4.2.1-pre (c) Xen 4.3-unstable Changeset 25993

            Linux Dom0 Kernel: (a) 3.5.4 (b) 3.6.0-rc7

            Windows HVM domU: (a) Windows XP Home Edition SP3 (b)
            Windows 8 Release Preview 64-bit

            

            Manuals which I have followed in getting Xen VGA Passthrough
            done:

            

            (1)
            http://wiki.xen.org/wiki/Building_and_Installing_Xen_4.x_and_Linux_Kernel_3.x_on_Ubuntu_and_Debian_Linux

            

            (2)
            http://wiki.xen.org/wiki/Xen_VGA_Passthrough_to_Windows_8_with_Xen_4.2-unstable

            

            The above 2 are manuals which I have written myself, after
            studying several Xen Wiki Pages and Jean David Techer's
            notes.

            

            Now, the above 2 manuals are the same manuals which I have
            used to obtain 100% success in Xen VGA Passthrough for Frank
            Lyon's NVIDIA Quadro 6000. Yes, 100% success. Absolutely no
            yellow triangle with exclamation mark and error code 43 in
            Windows 7 and Windows 8 HVM domU. It is an irony and a joke
            that, with the same set of manuals which I have written, I
            cannot get 100% success in Xen VGA Passthrough with my very
            own display cards. Frank Lyon's NVIDIA Quadro 6000 costs
            S$6000++, and I can't afford it. 

            

            So now, the problem stands. I get a yellow triangle with
            exclamation mark and error code 43 in device manager for
            Gigabyte Geforce GTX 560 in Windows 8 HVM domU and a yellow
            circle with exclamation mark and error code 10 in device
            manager for Gigabyte Geforce GTX 560 in Windows XP Home
            Edition HVM domU.

            

            The Reward

            

            1. USD$50 in cash

            2. Palit NVIDIA Geforce 8400 GS PCI Express x16 VGA card
            (costs S$44)

            

            How to Get the Reward

            

            If I can say that you have solved my Xen VGA Passthrough
            problem 100%, you get the reward! Basically, the idea is to
            get rid of the yellow triangle with exclamation mark and
            error code 43 in Windows 8 HVM domU and the yellow circle
            with exclamation mark and error code 10 in Windows XP HVM
            domU.

            

            Hence,

            

            (1) If you can tell me off-hand the solution which leads to
            my Xen VGA Passthrough problem being solved 100%, you get
            the reward. OR

            

            (2) You have spotted mistakes or errors in the manuals which
            I have written, leading to my Xen VGA Passthrough problem
            being solved 100%. You get the reward. OR

            

            (3) You have a VT-d capable motherboard and processor, and a
            compatible NVIDIA Geforce GTX 560 like mine, and follows the
            2 manuals which I have written for your Xen VGA Passthrough
            needs. If you can obtain 100% success, please tell me the
            mistakes or errors in my manuals, which leads to my Xen VGA
            Passthrough problem being solved 100%. You get the reward.

            

            100% success means no error code 43 and no error code
                10.

            

            For a start, you may follow the thread series "Help Needed from Xen Developers: Nasty
                Yellow Triangle with Exclamation Mark and Error Code 43
                in Device Manager in Windows 8 HVM domU" in the
              xen-users and xen-devel mailing lists.

            

            Please note that the prize money of US$50 is guaranteed and
            there is only one winner. There is no closing date for this
            challenge.

            

            

            
-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore

          

          

          _______________________________________________

          Xen-devel mailing list

          Xen-devel@lists.xen.org

          http://lists.xen.org/xen-devel

          

        

      

    

    

    

    

  


--------------090403070709090405080300--


--===============6252828551598041009==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6252828551598041009==--


From xen-devel-bounces@lists.xen.org Sat Oct 06 17:33:51 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Oct 2012 17:33:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TKYFi-0002lO-6U; Sat, 06 Oct 2012 17:33:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TKYFf-0002lE-Oi
	for xen-devel@lists.xen.org; Sat, 06 Oct 2012 17:33:24 +0000
Received: from [85.158.139.211:28100] by server-16.bemta-5.messagelabs.com id
	C5/26-21637-26B60705; Sat, 06 Oct 2012 17:33:22 +0000
X-Env-Sender: singapore.mr.teo.en.ming@gmail.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1349544799!21358147!1
X-Originating-IP: [209.85.210.45]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31252 invoked from network); 6 Oct 2012 17:33:21 -0000
Received: from mail-da0-f45.google.com (HELO mail-da0-f45.google.com)
	(209.85.210.45)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Oct 2012 17:33:21 -0000
Received: by mail-da0-f45.google.com with SMTP id n15so827545dad.32
	for ; Sat, 06 Oct 2012 10:33:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type;
	bh=9VOiRzzDHaaM6HAhOoJjiBSNPRAMNiWtr3Zh4sdbjWg=;
	b=oZsIilGU0yPBOJfKmVh3u0O4ECWgyfjVZABei9h12iU2DrU4pLnEi1kd41cWioOcAz
	omYCi+z2fMQ6qiZEADVbUZuM8y3GWYFVumhSP352hXdCnRUHlf67FvgylHElijbYzNHy
	KgdlgqZHu1I1H99LlUWRqIfFdDJcxMooxf+l0vNrhimR/nX/xgKoSIzyK2QfCsnWEjWK
	1OprW+2z4F2+ugCeblFn2BPftSLpm5XD2NaedhAoCau8RWvdBXtsFRjwjUezBIMm6RvD
	LoNmLdpL2/L6IISjufX/9mZXahO/OnsUuvPmaZ9IyjhzqF2mi+Px01M8W/+CJ8/UQGKD
	fuzA==
Received: by 10.66.87.73 with SMTP id v9mr30561726paz.1.1349544798831;
	Sat, 06 Oct 2012 10:33:18 -0700 (PDT)
Received: from [192.168.1.2] (cm152.gamma205.maxonline.com.sg.
	[202.156.205.152])
	by mx.google.com with ESMTPS id w4sm7942033pav.27.2012.10.06.10.33.16
	(version=SSLv3 cipher=OTHER); Sat, 06 Oct 2012 10:33:18 -0700 (PDT)
Message-ID: <50706B5B.5050008@gmail.com>
Date: Sun, 07 Oct 2012 01:33:15 +0800
From: "Teo En Ming (Zhang Enming)" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: "Teo En Ming (Zhang Enming)" 
References: <50706112.1030801@gmail.com>
	
	<50706848.9090104@gmail.com>
In-Reply-To: <50706848.9090104@gmail.com>
Cc: "xen-users@lists.xen.org" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] I offer a reward of USD$50 + VGA card Giveaway to
 anyone who can solve my Xen VGA Passthrough Problem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============6592236682877069031=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============6592236682877069031==
Content-Type: multipart/alternative;
 boundary="------------050709040608000905040006"

This is a multi-part message in MIME format.
--------------050709040608000905040006
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I just had Xen 4.3-unstable changeset 25993 compiled, installed and 
working, after applying Jean David Techer's revision 25240 patchset. 
BUT, as usual, I get the WIndows HVM domU device manager error code 43 
and error code 10.

Somebody please enlighten me!

-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore


On 07/10/2012 01:20, Teo En Ming (Zhang Enming) wrote:
> LOL. My Xen VGA Passthrough problem is long overdue. I have been 
> trying to fix the problem since March 2012.
>
> -- 
> Yours sincerely,
>
> Mr. Teo En Ming (Zhang Enming)
> Singapore
>
>
> On 07/10/2012 00:56, chris wrote:
>>
>> Sounds like someone is jealous of all the recent success reports :)
>>
>> On Oct 6, 2012 12:51 PM, "Teo En Ming (Zhang Enming)" 
>> > > wrote:
>>
>>     _History_
>>
>>     I have 100% success in Xen VGA Passthrough with Xen 3.5-unstable
>>     with my first Palit NVIDIA Geforce 8400 GS VGA card in 2009,
>>     which is 3 years ago. Then my first Palit NVIDIA Geforce 8400 GS
>>     VGA card overheated and malfunctioned. So I bought a 2nd Palit
>>     NVIDIA Geforce 8400 GS VGA card several months ago in March 2012
>>     for S$44, to replace the first card. At that point in time, Xen
>>     was already of version 4.2-unstable. I have tried to passthrough
>>     my 2nd Palit NVIDIA Geforce 8400 GS, which is only partially
>>     working, or partial success. _In Windows 8 HVM domU, you will see
>>     a yellow triangle with exclamation mark and error code 43 in
>>     Device Manager for the 2nd Palit NVIDIA Geforce 8400 GS. In
>>     Windows XP Home Edition HVM domU, you will see a yellow circle
>>     with exclamation mark and error code 10 in Device Manager for the
>>     2nd Palit NVIDIA Geforce 8400 GS._
>>
>>     Then I noticed Jean David Techer uses a Geforce 560 Ti for his
>>     Xen VGA Passthrough. So 1-2 weeks ago I bought a EVGA Geforce GTX
>>     560 1 GB GDDR5 for S$269. Same thing. Xen VGA Passthrough is only
>>     partially working or partial success. So I went back to the
>>     computer shop and exchanged my EVGA Geforce GTX 560 with a
>>     Gigabyte Geforce GTX 560 1 GB GDDR5, which costs S$289. Again,
>>     Xen VGA Passthrough is only partially working or partial success.
>>     _In Windows 8 HVM domU, you will see a yellow triangle with
>>     exclamation mark and error code 43 in Device Manager for the
>>     Gigabyte Geforce GTX 560. In Windows XP Home Edition HVM domU,
>>     you will see a yellow circle with exclamation mark and error code
>>     10 in Device Manager for the Gigabyte Geforce GTX 560._
>>
>>     _The Challenge_
>>
>>     My computer hardware specifications:
>>
>>     Processor: Intel Pentium Dual Core E2300 @ 2.8 GHz
>>     Motherboard: Intel DQ45CB Desktop Board with VT-d enabled
>>     VGA Card: Gigabyte Geforce GTX 560 1 GB GDDR5
>>     Memory: 6 GB
>>
>>     My computer software specifications:
>>
>>     Host operating system: Ubuntu 12.04.1 LTS Desktop Linux
>>     Xen Hypervisor version: (a) Xen 4.2-unstable Changeset 25099 (b)
>>     Xen 4.2.1-pre (c) Xen 4.3-unstable Changeset 25993
>>     Linux Dom0 Kernel: (a) 3.5.4 (b) 3.6.0-rc7
>>     Windows HVM domU: (a) Windows XP Home Edition SP3 (b) Windows 8
>>     Release Preview 64-bit
>>
>>     Manuals which I have followed in getting Xen VGA Passthrough done:
>>
>>     (1)
>>     http://wiki.xen.org/wiki/Building_and_Installing_Xen_4.x_and_Linux_Kernel_3.x_on_Ubuntu_and_Debian_Linux
>>
>>     (2)
>>     http://wiki.xen.org/wiki/Xen_VGA_Passthrough_to_Windows_8_with_Xen_4.2-unstable
>>
>>     The above 2 are manuals which I have written myself, after
>>     studying several Xen Wiki Pages and Jean David Techer's notes.
>>
>>     Now, the above 2 manuals are the same manuals which I have used
>>     to obtain 100% success in Xen VGA Passthrough for Frank Lyon's
>>     NVIDIA Quadro 6000. Yes, 100% success. Absolutely no yellow
>>     triangle with exclamation mark and error code 43 in Windows 7 and
>>     Windows 8 HVM domU. It is an irony and a joke that, with the same
>>     set of manuals which I have written, I cannot get 100% success in
>>     Xen VGA Passthrough with my very own display cards. Frank Lyon's
>>     NVIDIA Quadro 6000 costs S$6000++, and I can't afford it.
>>
>>     So now, the problem stands. I get a yellow triangle with
>>     exclamation mark and error code 43 in device manager for Gigabyte
>>     Geforce GTX 560 in Windows 8 HVM domU and a yellow circle with
>>     exclamation mark and error code 10 in device manager for Gigabyte
>>     Geforce GTX 560 in Windows XP Home Edition HVM domU.
>>
>>     _The Reward_
>>
>>     1. USD$50 in cash
>>     2. Palit NVIDIA Geforce 8400 GS PCI Express x16 VGA card (costs S$44)
>>
>>     _How to Get the Reward_
>>
>>     If I can say that you have solved my Xen VGA Passthrough problem
>>     100%, you get the reward! Basically, the idea is to get rid of
>>     the yellow triangle with exclamation mark and error code 43 in
>>     Windows 8 HVM domU and the yellow circle with exclamation mark
>>     and error code 10 in Windows XP HVM domU.
>>
>>     Hence,
>>
>>     (1) If you can tell me off-hand the solution which leads to my
>>     Xen VGA Passthrough problem being solved 100%, you get the reward. OR
>>
>>     (2) You have spotted mistakes or errors in the manuals which I
>>     have written, leading to my Xen VGA Passthrough problem being
>>     solved 100%. You get the reward. OR
>>
>>     (3) You have a VT-d capable motherboard and processor, and a
>>     compatible NVIDIA Geforce GTX 560 like mine, and follows the 2
>>     manuals which I have written for your Xen VGA Passthrough needs.
>>     If you can obtain 100% success, please tell me the mistakes or
>>     errors in my manuals, which leads to my Xen VGA Passthrough
>>     problem being solved 100%. You get the reward.
>>
>>     *_100% success means no error code 43 and no error code 10._*
>>
>>     For a start, you may follow the thread series "*Help Needed from
>>     Xen Developers: Nasty Yellow Triangle with Exclamation Mark and
>>     Error Code 43 in Device Manager in Windows 8 HVM domU
>>     "
>>     in the xen-users and xen-devel mailing lists.*
>>
>>     Please note that the prize money of US$50 is guaranteed and there
>>     is only one winner. There is no closing date for this challenge.
>>
>>
>>     -- 
>>     Yours sincerely,
>>
>>     Mr. Teo En Ming (Zhang Enming)
>>     Singapore
>>
>>
>>     _______________________________________________
>>     Xen-devel mailing list
>>     Xen-devel@lists.xen.org 
>>     http://lists.xen.org/xen-devel
>>
>
>



--------------050709040608000905040006
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
I just had Xen 4.3-unstable changeset
      25993 compiled, installed and working, after applying Jean David
      Techer's revision 25240 patchset. BUT, as usual, I get the WIndows
      HVM domU device manager error code 43 and error code 10.

      

      Somebody please enlighten me!

      
-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore

      

      On 07/10/2012 01:20, Teo En Ming (Zhang Enming) wrote:

    

    

      
      
LOL. My Xen VGA Passthrough problem
        is long overdue. I have been trying to fix the problem since
        March 2012.

        

        
-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore

        

        

        On 07/10/2012 00:56, chris wrote:

      

      

        
Sounds like someone is jealous of all the recent
          success reports :)

        
On Oct 6, 2012 12:51 PM, "Teo En Ming
          (Zhang Enming)" <singapore.mr.teo.en.ming@gmail.com>

          wrote:

          

            
 History

              

              I have 100% success in Xen VGA Passthrough with Xen
              3.5-unstable with my first Palit NVIDIA Geforce 8400 GS
              VGA card in 2009, which is 3 years ago. Then my first
              Palit NVIDIA Geforce 8400 GS VGA card overheated and
              malfunctioned. So I bought a 2nd Palit NVIDIA Geforce 8400
              GS VGA card several months ago in March 2012 for S$44, to
              replace the first card. At that point in time, Xen was
              already of version 4.2-unstable. I have tried to
              passthrough my 2nd Palit NVIDIA Geforce 8400 GS, which is
              only partially working, or partial success. In Windows
                8 HVM domU, you will see a yellow triangle with
                exclamation mark and error code 43 in Device Manager for
                the 2nd Palit NVIDIA Geforce 8400 GS. In Windows XP Home
                Edition HVM domU, you will see a yellow circle with
                exclamation mark and error code 10 in Device Manager for
                the 2nd Palit NVIDIA Geforce 8400 GS.

              

              Then I noticed Jean David Techer uses a Geforce 560 Ti for
              his Xen VGA Passthrough. So 1-2 weeks ago I bought a EVGA
              Geforce GTX 560 1 GB GDDR5 for S$269. Same thing. Xen VGA
              Passthrough is only partially working or partial success.
              So I went back to the computer shop and exchanged my EVGA
              Geforce GTX 560 with a Gigabyte Geforce GTX 560 1 GB
              GDDR5, which costs S$289. Again, Xen VGA Passthrough is
              only partially working or partial success. In Windows
                8 HVM domU, you will see a yellow triangle with
                exclamation mark and error code 43 in Device Manager for
                the Gigabyte Geforce GTX 560. In Windows XP Home Edition
                HVM domU, you will see a yellow circle with exclamation
                mark and error code 10 in Device Manager for the
                Gigabyte Geforce GTX 560.

              

              The Challenge

              

              My computer hardware specifications:

              

              Processor: Intel Pentium Dual Core E2300 @ 2.8 GHz

              Motherboard: Intel DQ45CB Desktop Board with VT-d enabled

              VGA Card: Gigabyte Geforce GTX 560 1 GB GDDR5

              Memory: 6 GB

              

              My computer software specifications:

              

              Host operating system: Ubuntu 12.04.1 LTS Desktop Linux

              Xen Hypervisor version: (a) Xen 4.2-unstable Changeset
              25099 (b) Xen 4.2.1-pre (c) Xen 4.3-unstable Changeset
              25993

              Linux Dom0 Kernel: (a) 3.5.4 (b) 3.6.0-rc7

              Windows HVM domU: (a) Windows XP Home Edition SP3 (b)
              Windows 8 Release Preview 64-bit

              

              Manuals which I have followed in getting Xen VGA
              Passthrough done:

              

              (1) http://wiki.xen.org/wiki/Building_and_Installing_Xen_4.x_and_Linux_Kernel_3.x_on_Ubuntu_and_Debian_Linux

              

              (2) http://wiki.xen.org/wiki/Xen_VGA_Passthrough_to_Windows_8_with_Xen_4.2-unstable

              

              The above 2 are manuals which I have written myself, after
              studying several Xen Wiki Pages and Jean David Techer's
              notes.

              

              Now, the above 2 manuals are the same manuals which I have
              used to obtain 100% success in Xen VGA Passthrough for
              Frank Lyon's NVIDIA Quadro 6000. Yes, 100% success.
              Absolutely no yellow triangle with exclamation mark and
              error code 43 in Windows 7 and Windows 8 HVM domU. It is
              an irony and a joke that, with the same set of manuals
              which I have written, I cannot get 100% success in Xen VGA
              Passthrough with my very own display cards. Frank Lyon's
              NVIDIA Quadro 6000 costs S$6000++, and I can't afford it.
              

              

              So now, the problem stands. I get a yellow triangle with
              exclamation mark and error code 43 in device manager for
              Gigabyte Geforce GTX 560 in Windows 8 HVM domU and a
              yellow circle with exclamation mark and error code 10 in
              device manager for Gigabyte Geforce GTX 560 in Windows XP
              Home Edition HVM domU.

              

              The Reward

              

              1. USD$50 in cash

              2. Palit NVIDIA Geforce 8400 GS PCI Express x16 VGA card
              (costs S$44)

              

              How to Get the Reward

              

              If I can say that you have solved my Xen VGA Passthrough
              problem 100%, you get the reward! Basically, the idea is
              to get rid of the yellow triangle with exclamation mark
              and error code 43 in Windows 8 HVM domU and the yellow
              circle with exclamation mark and error code 10 in Windows
              XP HVM domU.

              

              Hence,

              

              (1) If you can tell me off-hand the solution which leads
              to my Xen VGA Passthrough problem being solved 100%, you
              get the reward. OR

              

              (2) You have spotted mistakes or errors in the manuals
              which I have written, leading to my Xen VGA Passthrough
              problem being solved 100%. You get the reward. OR

              

              (3) You have a VT-d capable motherboard and processor, and
              a compatible NVIDIA Geforce GTX 560 like mine, and follows
              the 2 manuals which I have written for your Xen VGA
              Passthrough needs. If you can obtain 100% success, please
              tell me the mistakes or errors in my manuals, which leads
              to my Xen VGA Passthrough problem being solved 100%. You
              get the reward.

              

              100% success means no error code 43 and no error
                  code 10.

              

              For a start, you may follow the thread series "Help Needed from Xen Developers: Nasty
                  Yellow Triangle with Exclamation Mark and Error Code
                  43 in Device Manager in Windows 8 HVM domU" in the
                xen-users and xen-devel mailing lists.

              

              Please note that the prize money of US$50 is guaranteed
              and there is only one winner. There is no closing date for
              this challenge.

              

              

              
-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore

            

            

            _______________________________________________

            Xen-devel mailing list

            Xen-devel@lists.xen.org

            http://lists.xen.org/xen-devel

            

          

        

      

      

      

    

    

    

    

  


--------------050709040608000905040006--


--===============6592236682877069031==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6592236682877069031==--


From xen-devel-bounces@lists.xen.org Sat Oct 06 17:33:51 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Oct 2012 17:33:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TKYFi-0002lO-6U; Sat, 06 Oct 2012 17:33:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TKYFf-0002lE-Oi
	for xen-devel@lists.xen.org; Sat, 06 Oct 2012 17:33:24 +0000
Received: from [85.158.139.211:28100] by server-16.bemta-5.messagelabs.com id
	C5/26-21637-26B60705; Sat, 06 Oct 2012 17:33:22 +0000
X-Env-Sender: singapore.mr.teo.en.ming@gmail.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1349544799!21358147!1
X-Originating-IP: [209.85.210.45]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31252 invoked from network); 6 Oct 2012 17:33:21 -0000
Received: from mail-da0-f45.google.com (HELO mail-da0-f45.google.com)
	(209.85.210.45)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Oct 2012 17:33:21 -0000
Received: by mail-da0-f45.google.com with SMTP id n15so827545dad.32
	for ; Sat, 06 Oct 2012 10:33:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type;
	bh=9VOiRzzDHaaM6HAhOoJjiBSNPRAMNiWtr3Zh4sdbjWg=;
	b=oZsIilGU0yPBOJfKmVh3u0O4ECWgyfjVZABei9h12iU2DrU4pLnEi1kd41cWioOcAz
	omYCi+z2fMQ6qiZEADVbUZuM8y3GWYFVumhSP352hXdCnRUHlf67FvgylHElijbYzNHy
	KgdlgqZHu1I1H99LlUWRqIfFdDJcxMooxf+l0vNrhimR/nX/xgKoSIzyK2QfCsnWEjWK
	1OprW+2z4F2+ugCeblFn2BPftSLpm5XD2NaedhAoCau8RWvdBXtsFRjwjUezBIMm6RvD
	LoNmLdpL2/L6IISjufX/9mZXahO/OnsUuvPmaZ9IyjhzqF2mi+Px01M8W/+CJ8/UQGKD
	fuzA==
Received: by 10.66.87.73 with SMTP id v9mr30561726paz.1.1349544798831;
	Sat, 06 Oct 2012 10:33:18 -0700 (PDT)
Received: from [192.168.1.2] (cm152.gamma205.maxonline.com.sg.
	[202.156.205.152])
	by mx.google.com with ESMTPS id w4sm7942033pav.27.2012.10.06.10.33.16
	(version=SSLv3 cipher=OTHER); Sat, 06 Oct 2012 10:33:18 -0700 (PDT)
Message-ID: <50706B5B.5050008@gmail.com>
Date: Sun, 07 Oct 2012 01:33:15 +0800
From: "Teo En Ming (Zhang Enming)" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: "Teo En Ming (Zhang Enming)" 
References: <50706112.1030801@gmail.com>
	
	<50706848.9090104@gmail.com>
In-Reply-To: <50706848.9090104@gmail.com>
Cc: "xen-users@lists.xen.org" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] I offer a reward of USD$50 + VGA card Giveaway to
 anyone who can solve my Xen VGA Passthrough Problem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============6592236682877069031=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============6592236682877069031==
Content-Type: multipart/alternative;
 boundary="------------050709040608000905040006"

This is a multi-part message in MIME format.
--------------050709040608000905040006
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I just had Xen 4.3-unstable changeset 25993 compiled, installed and 
working, after applying Jean David Techer's revision 25240 patchset. 
BUT, as usual, I get the WIndows HVM domU device manager error code 43 
and error code 10.

Somebody please enlighten me!

-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore


On 07/10/2012 01:20, Teo En Ming (Zhang Enming) wrote:
> LOL. My Xen VGA Passthrough problem is long overdue. I have been 
> trying to fix the problem since March 2012.
>
> -- 
> Yours sincerely,
>
> Mr. Teo En Ming (Zhang Enming)
> Singapore
>
>
> On 07/10/2012 00:56, chris wrote:
>>
>> Sounds like someone is jealous of all the recent success reports :)
>>
>> On Oct 6, 2012 12:51 PM, "Teo En Ming (Zhang Enming)" 
>> > > wrote:
>>
>>     _History_
>>
>>     I have 100% success in Xen VGA Passthrough with Xen 3.5-unstable
>>     with my first Palit NVIDIA Geforce 8400 GS VGA card in 2009,
>>     which is 3 years ago. Then my first Palit NVIDIA Geforce 8400 GS
>>     VGA card overheated and malfunctioned. So I bought a 2nd Palit
>>     NVIDIA Geforce 8400 GS VGA card several months ago in March 2012
>>     for S$44, to replace the first card. At that point in time, Xen
>>     was already of version 4.2-unstable. I have tried to passthrough
>>     my 2nd Palit NVIDIA Geforce 8400 GS, which is only partially
>>     working, or partial success. _In Windows 8 HVM domU, you will see
>>     a yellow triangle with exclamation mark and error code 43 in
>>     Device Manager for the 2nd Palit NVIDIA Geforce 8400 GS. In
>>     Windows XP Home Edition HVM domU, you will see a yellow circle
>>     with exclamation mark and error code 10 in Device Manager for the
>>     2nd Palit NVIDIA Geforce 8400 GS._
>>
>>     Then I noticed Jean David Techer uses a Geforce 560 Ti for his
>>     Xen VGA Passthrough. So 1-2 weeks ago I bought a EVGA Geforce GTX
>>     560 1 GB GDDR5 for S$269. Same thing. Xen VGA Passthrough is only
>>     partially working or partial success. So I went back to the
>>     computer shop and exchanged my EVGA Geforce GTX 560 with a
>>     Gigabyte Geforce GTX 560 1 GB GDDR5, which costs S$289. Again,
>>     Xen VGA Passthrough is only partially working or partial success.
>>     _In Windows 8 HVM domU, you will see a yellow triangle with
>>     exclamation mark and error code 43 in Device Manager for the
>>     Gigabyte Geforce GTX 560. In Windows XP Home Edition HVM domU,
>>     you will see a yellow circle with exclamation mark and error code
>>     10 in Device Manager for the Gigabyte Geforce GTX 560._
>>
>>     _The Challenge_
>>
>>     My computer hardware specifications:
>>
>>     Processor: Intel Pentium Dual Core E2300 @ 2.8 GHz
>>     Motherboard: Intel DQ45CB Desktop Board with VT-d enabled
>>     VGA Card: Gigabyte Geforce GTX 560 1 GB GDDR5
>>     Memory: 6 GB
>>
>>     My computer software specifications:
>>
>>     Host operating system: Ubuntu 12.04.1 LTS Desktop Linux
>>     Xen Hypervisor version: (a) Xen 4.2-unstable Changeset 25099 (b)
>>     Xen 4.2.1-pre (c) Xen 4.3-unstable Changeset 25993
>>     Linux Dom0 Kernel: (a) 3.5.4 (b) 3.6.0-rc7
>>     Windows HVM domU: (a) Windows XP Home Edition SP3 (b) Windows 8
>>     Release Preview 64-bit
>>
>>     Manuals which I have followed in getting Xen VGA Passthrough done:
>>
>>     (1)
>>     http://wiki.xen.org/wiki/Building_and_Installing_Xen_4.x_and_Linux_Kernel_3.x_on_Ubuntu_and_Debian_Linux
>>
>>     (2)
>>     http://wiki.xen.org/wiki/Xen_VGA_Passthrough_to_Windows_8_with_Xen_4.2-unstable
>>
>>     The above 2 are manuals which I have written myself, after
>>     studying several Xen Wiki Pages and Jean David Techer's notes.
>>
>>     Now, the above 2 manuals are the same manuals which I have used
>>     to obtain 100% success in Xen VGA Passthrough for Frank Lyon's
>>     NVIDIA Quadro 6000. Yes, 100% success. Absolutely no yellow
>>     triangle with exclamation mark and error code 43 in Windows 7 and
>>     Windows 8 HVM domU. It is an irony and a joke that, with the same
>>     set of manuals which I have written, I cannot get 100% success in
>>     Xen VGA Passthrough with my very own display cards. Frank Lyon's
>>     NVIDIA Quadro 6000 costs S$6000++, and I can't afford it.
>>
>>     So now, the problem stands. I get a yellow triangle with
>>     exclamation mark and error code 43 in device manager for Gigabyte
>>     Geforce GTX 560 in Windows 8 HVM domU and a yellow circle with
>>     exclamation mark and error code 10 in device manager for Gigabyte
>>     Geforce GTX 560 in Windows XP Home Edition HVM domU.
>>
>>     _The Reward_
>>
>>     1. USD$50 in cash
>>     2. Palit NVIDIA Geforce 8400 GS PCI Express x16 VGA card (costs S$44)
>>
>>     _How to Get the Reward_
>>
>>     If I can say that you have solved my Xen VGA Passthrough problem
>>     100%, you get the reward! Basically, the idea is to get rid of
>>     the yellow triangle with exclamation mark and error code 43 in
>>     Windows 8 HVM domU and the yellow circle with exclamation mark
>>     and error code 10 in Windows XP HVM domU.
>>
>>     Hence,
>>
>>     (1) If you can tell me off-hand the solution which leads to my
>>     Xen VGA Passthrough problem being solved 100%, you get the reward. OR
>>
>>     (2) You have spotted mistakes or errors in the manuals which I
>>     have written, leading to my Xen VGA Passthrough problem being
>>     solved 100%. You get the reward. OR
>>
>>     (3) You have a VT-d capable motherboard and processor, and a
>>     compatible NVIDIA Geforce GTX 560 like mine, and follows the 2
>>     manuals which I have written for your Xen VGA Passthrough needs.
>>     If you can obtain 100% success, please tell me the mistakes or
>>     errors in my manuals, which leads to my Xen VGA Passthrough
>>     problem being solved 100%. You get the reward.
>>
>>     *_100% success means no error code 43 and no error code 10._*
>>
>>     For a start, you may follow the thread series "*Help Needed from
>>     Xen Developers: Nasty Yellow Triangle with Exclamation Mark and
>>     Error Code 43 in Device Manager in Windows 8 HVM domU
>>     "
>>     in the xen-users and xen-devel mailing lists.*
>>
>>     Please note that the prize money of US$50 is guaranteed and there
>>     is only one winner. There is no closing date for this challenge.
>>
>>
>>     -- 
>>     Yours sincerely,
>>
>>     Mr. Teo En Ming (Zhang Enming)
>>     Singapore
>>
>>
>>     _______________________________________________
>>     Xen-devel mailing list
>>     Xen-devel@lists.xen.org 
>>     http://lists.xen.org/xen-devel
>>
>
>



--------------050709040608000905040006
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
I just had Xen 4.3-unstable changeset
      25993 compiled, installed and working, after applying Jean David
      Techer's revision 25240 patchset. BUT, as usual, I get the WIndows
      HVM domU device manager error code 43 and error code 10.

      

      Somebody please enlighten me!

      
-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore

      

      On 07/10/2012 01:20, Teo En Ming (Zhang Enming) wrote:

    

    

      
      
LOL. My Xen VGA Passthrough problem
        is long overdue. I have been trying to fix the problem since
        March 2012.

        

        
-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore

        

        

        On 07/10/2012 00:56, chris wrote:

      

      

        
Sounds like someone is jealous of all the recent
          success reports :)

        
On Oct 6, 2012 12:51 PM, "Teo En Ming
          (Zhang Enming)" <singapore.mr.teo.en.ming@gmail.com>

          wrote:

          

            
 History

              

              I have 100% success in Xen VGA Passthrough with Xen
              3.5-unstable with my first Palit NVIDIA Geforce 8400 GS
              VGA card in 2009, which is 3 years ago. Then my first
              Palit NVIDIA Geforce 8400 GS VGA card overheated and
              malfunctioned. So I bought a 2nd Palit NVIDIA Geforce 8400
              GS VGA card several months ago in March 2012 for S$44, to
              replace the first card. At that point in time, Xen was
              already of version 4.2-unstable. I have tried to
              passthrough my 2nd Palit NVIDIA Geforce 8400 GS, which is
              only partially working, or partial success. In Windows
                8 HVM domU, you will see a yellow triangle with
                exclamation mark and error code 43 in Device Manager for
                the 2nd Palit NVIDIA Geforce 8400 GS. In Windows XP Home
                Edition HVM domU, you will see a yellow circle with
                exclamation mark and error code 10 in Device Manager for
                the 2nd Palit NVIDIA Geforce 8400 GS.

              

              Then I noticed Jean David Techer uses a Geforce 560 Ti for
              his Xen VGA Passthrough. So 1-2 weeks ago I bought a EVGA
              Geforce GTX 560 1 GB GDDR5 for S$269. Same thing. Xen VGA
              Passthrough is only partially working or partial success.
              So I went back to the computer shop and exchanged my EVGA
              Geforce GTX 560 with a Gigabyte Geforce GTX 560 1 GB
              GDDR5, which costs S$289. Again, Xen VGA Passthrough is
              only partially working or partial success. In Windows
                8 HVM domU, you will see a yellow triangle with
                exclamation mark and error code 43 in Device Manager for
                the Gigabyte Geforce GTX 560. In Windows XP Home Edition
                HVM domU, you will see a yellow circle with exclamation
                mark and error code 10 in Device Manager for the
                Gigabyte Geforce GTX 560.

              

              The Challenge

              

              My computer hardware specifications:

              

              Processor: Intel Pentium Dual Core E2300 @ 2.8 GHz

              Motherboard: Intel DQ45CB Desktop Board with VT-d enabled

              VGA Card: Gigabyte Geforce GTX 560 1 GB GDDR5

              Memory: 6 GB

              

              My computer software specifications:

              

              Host operating system: Ubuntu 12.04.1 LTS Desktop Linux

              Xen Hypervisor version: (a) Xen 4.2-unstable Changeset
              25099 (b) Xen 4.2.1-pre (c) Xen 4.3-unstable Changeset
              25993

              Linux Dom0 Kernel: (a) 3.5.4 (b) 3.6.0-rc7

              Windows HVM domU: (a) Windows XP Home Edition SP3 (b)
              Windows 8 Release Preview 64-bit

              

              Manuals which I have followed in getting Xen VGA
              Passthrough done:

              

              (1) http://wiki.xen.org/wiki/Building_and_Installing_Xen_4.x_and_Linux_Kernel_3.x_on_Ubuntu_and_Debian_Linux

              

              (2) http://wiki.xen.org/wiki/Xen_VGA_Passthrough_to_Windows_8_with_Xen_4.2-unstable

              

              The above 2 are manuals which I have written myself, after
              studying several Xen Wiki Pages and Jean David Techer's
              notes.

              

              Now, the above 2 manuals are the same manuals which I have
              used to obtain 100% success in Xen VGA Passthrough for
              Frank Lyon's NVIDIA Quadro 6000. Yes, 100% success.
              Absolutely no yellow triangle with exclamation mark and
              error code 43 in Windows 7 and Windows 8 HVM domU. It is
              an irony and a joke that, with the same set of manuals
              which I have written, I cannot get 100% success in Xen VGA
              Passthrough with my very own display cards. Frank Lyon's
              NVIDIA Quadro 6000 costs S$6000++, and I can't afford it.
              

              

              So now, the problem stands. I get a yellow triangle with
              exclamation mark and error code 43 in device manager for
              Gigabyte Geforce GTX 560 in Windows 8 HVM domU and a
              yellow circle with exclamation mark and error code 10 in
              device manager for Gigabyte Geforce GTX 560 in Windows XP
              Home Edition HVM domU.

              

              The Reward

              

              1. USD$50 in cash

              2. Palit NVIDIA Geforce 8400 GS PCI Express x16 VGA card
              (costs S$44)

              

              How to Get the Reward

              

              If I can say that you have solved my Xen VGA Passthrough
              problem 100%, you get the reward! Basically, the idea is
              to get rid of the yellow triangle with exclamation mark
              and error code 43 in Windows 8 HVM domU and the yellow
              circle with exclamation mark and error code 10 in Windows
              XP HVM domU.

              

              Hence,

              

              (1) If you can tell me off-hand the solution which leads
              to my Xen VGA Passthrough problem being solved 100%, you
              get the reward. OR

              

              (2) You have spotted mistakes or errors in the manuals
              which I have written, leading to my Xen VGA Passthrough
              problem being solved 100%. You get the reward. OR

              

              (3) You have a VT-d capable motherboard and processor, and
              a compatible NVIDIA Geforce GTX 560 like mine, and follows
              the 2 manuals which I have written for your Xen VGA
              Passthrough needs. If you can obtain 100% success, please
              tell me the mistakes or errors in my manuals, which leads
              to my Xen VGA Passthrough problem being solved 100%. You
              get the reward.

              

              100% success means no error code 43 and no error
                  code 10.

              

              For a start, you may follow the thread series "Help Needed from Xen Developers: Nasty
                  Yellow Triangle with Exclamation Mark and Error Code
                  43 in Device Manager in Windows 8 HVM domU" in the
                xen-users and xen-devel mailing lists.

              

              Please note that the prize money of US$50 is guaranteed
              and there is only one winner. There is no closing date for
              this challenge.

              

              

              
-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore

            

            

            _______________________________________________

            Xen-devel mailing list

            Xen-devel@lists.xen.org

            http://lists.xen.org/xen-devel

            

          

        

      

      

      

    

    

    

    

  


--------------050709040608000905040006--


--===============6592236682877069031==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6592236682877069031==--


From xen-devel-bounces@lists.xen.org Sat Oct 06 19:13:20 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Oct 2012 19:13:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TKZnx-0004tw-3g; Sat, 06 Oct 2012 19:12:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TKZnv-0004tr-Qs
	for xen-devel@lists.xen.org; Sat, 06 Oct 2012 19:12:51 +0000
Received: from [85.158.139.211:59607] by server-8.bemta-5.messagelabs.com id
	05/6C-23193-3B280705; Sat, 06 Oct 2012 19:12:51 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-4.tower-206.messagelabs.com!1349550770!21341693!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MzA1NjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26861 invoked from network); 6 Oct 2012 19:12:50 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-4.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Oct 2012 19:12:50 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id DDDE528C7;
	Sat,  6 Oct 2012 22:12:49 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id DAC0020058; Sat,  6 Oct 2012 22:12:48 +0300 (EEST)
Date: Sat, 6 Oct 2012 22:12:48 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= 
To: greg@enjellic.com
Message-ID: <20121006191248.GZ8912@reaktio.net>
References: 
	<201210052357.q95Nv6jK004901@wind.enjellic.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <201210052357.q95Nv6jK004901@wind.enjellic.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Moritz =?iso-8859-1?Q?M=FChlenhoff?= ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Compilation fixes for blktap kernel patch
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 05, 2012 at 06:57:06PM -0500, Dr. Greg Wettstein wrote:
> On Oct 5, 10:31am, Moritz =?iso-8859-1?q?M=FChlenhoff?= wrote:
> } Subject: [Xen-devel] Compilation fixes for blktap kernel patch
> 
> > Hi,
> 
> Hi Moritz, hope your week went well.
> 
> > I hope this is the correct mailing list for the blktap patches available at
> > ftp://ftp.enjellic.com/pub/xen/ ?
> 
> I'm not sure any of the core Xen developers wants to lay claim to
> blktap2 in general and these patches in particular.... :-)
> 

Please submit your patches for inclusion in Xen upstream!
We've been trying to ask for this in the other thread :)

> I try to keep these patches updated since blktap2 is useful in our
> implementations and I wanted to save everyone else what seemed like
> endless hours of googling and searching trying to get these facilities
> working the way they are supposed to.  I'm glad you have found them
> useful.
> 

Yes, that's good, and let's get the patches merged to upstream Xen!

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 06 19:13:20 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 06 Oct 2012 19:13:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TKZnx-0004tw-3g; Sat, 06 Oct 2012 19:12:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TKZnv-0004tr-Qs
	for xen-devel@lists.xen.org; Sat, 06 Oct 2012 19:12:51 +0000
Received: from [85.158.139.211:59607] by server-8.bemta-5.messagelabs.com id
	05/6C-23193-3B280705; Sat, 06 Oct 2012 19:12:51 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-4.tower-206.messagelabs.com!1349550770!21341693!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MzA1NjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26861 invoked from network); 6 Oct 2012 19:12:50 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-4.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Oct 2012 19:12:50 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id DDDE528C7;
	Sat,  6 Oct 2012 22:12:49 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id DAC0020058; Sat,  6 Oct 2012 22:12:48 +0300 (EEST)
Date: Sat, 6 Oct 2012 22:12:48 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= 
To: greg@enjellic.com
Message-ID: <20121006191248.GZ8912@reaktio.net>
References: 
	<201210052357.q95Nv6jK004901@wind.enjellic.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <201210052357.q95Nv6jK004901@wind.enjellic.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Moritz =?iso-8859-1?Q?M=FChlenhoff?= ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Compilation fixes for blktap kernel patch
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 05, 2012 at 06:57:06PM -0500, Dr. Greg Wettstein wrote:
> On Oct 5, 10:31am, Moritz =?iso-8859-1?q?M=FChlenhoff?= wrote:
> } Subject: [Xen-devel] Compilation fixes for blktap kernel patch
> 
> > Hi,
> 
> Hi Moritz, hope your week went well.
> 
> > I hope this is the correct mailing list for the blktap patches available at
> > ftp://ftp.enjellic.com/pub/xen/ ?
> 
> I'm not sure any of the core Xen developers wants to lay claim to
> blktap2 in general and these patches in particular.... :-)
> 

Please submit your patches for inclusion in Xen upstream!
We've been trying to ask for this in the other thread :)

> I try to keep these patches updated since blktap2 is useful in our
> implementations and I wanted to save everyone else what seemed like
> endless hours of googling and searching trying to get these facilities
> working the way they are supposed to.  I'm glad you have found them
> useful.
> 

Yes, that's good, and let's get the patches merged to upstream Xen!

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 07 05:07:12 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Oct 2012 05:07:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TKj4T-0005YF-H2; Sun, 07 Oct 2012 05:06:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TKj4S-0005YA-78
	for xen-devel@lists.xensource.com; Sun, 07 Oct 2012 05:06:32 +0000
Received: from [85.158.139.83:57745] by server-9.bemta-5.messagelabs.com id
	DA/5A-14846-7DD01705; Sun, 07 Oct 2012 05:06:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1349586390!33198578!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMzODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20831 invoked from network); 7 Oct 2012 05:06:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Oct 2012 05:06:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,546,1344211200"; d="scan'208";a="14981764"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Oct 2012 05:06:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sun, 7 Oct 2012 06:06:29 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TKj4P-0005oK-4R;
	Sun, 07 Oct 2012 05:06:29 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TKj4O-00005B-NC;
	Sun, 07 Oct 2012 06:06:28 +0100
To: 
Message-ID: 
From: xen.org 
Date: Sun, 7 Oct 2012 06:06:28 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13930: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13930 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13930/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13929
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13929
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13929
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13929

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  3eb9a891889a
baseline version:
 xen                  3eb9a891889a

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 07 05:07:12 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Oct 2012 05:07:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TKj4T-0005YF-H2; Sun, 07 Oct 2012 05:06:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TKj4S-0005YA-78
	for xen-devel@lists.xensource.com; Sun, 07 Oct 2012 05:06:32 +0000
Received: from [85.158.139.83:57745] by server-9.bemta-5.messagelabs.com id
	DA/5A-14846-7DD01705; Sun, 07 Oct 2012 05:06:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1349586390!33198578!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMzODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20831 invoked from network); 7 Oct 2012 05:06:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Oct 2012 05:06:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,546,1344211200"; d="scan'208";a="14981764"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Oct 2012 05:06:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sun, 7 Oct 2012 06:06:29 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TKj4P-0005oK-4R;
	Sun, 07 Oct 2012 05:06:29 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TKj4O-00005B-NC;
	Sun, 07 Oct 2012 06:06:28 +0100
To: 
Message-ID: 
From: xen.org 
Date: Sun, 7 Oct 2012 06:06:28 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13930: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13930 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13930/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13929
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13929
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13929
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13929

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  3eb9a891889a
baseline version:
 xen                  3eb9a891889a

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 07 15:46:20 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Oct 2012 15:46:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TKt2u-0002F2-6b; Sun, 07 Oct 2012 15:45:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TKrVK-0001xt-0g
	for xen-devel@lists.xensource.com; Sun, 07 Oct 2012 14:06:50 +0000
Received: from [85.158.143.35:5720] by server-3.bemta-4.messagelabs.com id
	B1/58-10986-97C81705; Sun, 07 Oct 2012 14:06:49 +0000
X-Env-Sender: weiyj.lk@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1349618807!15146282!1
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7048 invoked from network); 7 Oct 2012 14:06:48 -0000
Received: from mail-qa0-f43.google.com (HELO mail-qa0-f43.google.com)
	(209.85.216.43)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Oct 2012 14:06:48 -0000
Received: by mail-qa0-f43.google.com with SMTP id k1so1485182qaf.9
	for ;
	Sun, 07 Oct 2012 07:06:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:cc:content-type;
	bh=WY8hGgfYChffkLIh12nQbBf+Utv2xFdlhzIijbXkXCY=;
	b=Q8jNmoheZUbNH08JI7njvxyQ/rRUcnmDzW90/3en6lm3myLA0z2PmCKRcIjt3cgsDe
	ZIpm0TJ1UcP15RO91LU0meGZvl1LL7uRkgknn784VJjrl+SOwHpgpUf1y4HrDIb+Kw6Z
	W5Y+KP7CY5qu5oQXJ8CAJp3iMSVXmc82FZrWC5kVnw0+ojsp9YHxHMFFVQpIcUl0FL/p
	4qP4zw0fCMqWVIDcs+eCJrwvvK/LkKuy8JSw20n6i0ZZiwjDZlDyEvPLFsazGVMESy6t
	QzMED5yhrurEvoyMoXUeP5zp7N1x/YzZkBWdCKJUtyIgSO+FI7zNZoDs1u9SMYErviyK
	/WGQ==
MIME-Version: 1.0
Received: by 10.224.100.200 with SMTP id z8mr25637046qan.75.1349618807509;
	Sun, 07 Oct 2012 07:06:47 -0700 (PDT)
Received: by 10.229.146.194 with HTTP; Sun, 7 Oct 2012 07:06:47 -0700 (PDT)
Date: Sun, 7 Oct 2012 22:06:47 +0800
Message-ID: 
From: Wei Yongjun 
To: konrad.wilk@oracle.com, jeremy@goop.org, tglx@linutronix.de, 
	mingo@redhat.com, hpa@zytor.com
X-Mailman-Approved-At: Sun, 07 Oct 2012 15:45:34 +0000
Cc: linux-kernel@vger.kernel.org, yongjun_wei@trendmicro.com.cn, x86@kernel.org,
	xen-devel@lists.xensource.com, virtualization@lists.linux-foundation.org
Subject: [Xen-devel] [PATCH] xen/x86: remove duplicated include from
	enlighten.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Wei Yongjun 

Remove duplicated include.

dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)

Signed-off-by: Wei Yongjun 
---
 arch/x86/xen/enlighten.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index bf788d3..061b148 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -81,8 +81,6 @@
 #include "smp.h"
 #include "multicalls.h"
 
-#include 
-
 EXPORT_SYMBOL_GPL(hypercall_page);
 
 DEFINE_PER_CPU(struct vcpu_info *, xen_vcpu);


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 07 15:46:20 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Oct 2012 15:46:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TKt2u-0002F2-6b; Sun, 07 Oct 2012 15:45:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TKrVK-0001xt-0g
	for xen-devel@lists.xensource.com; Sun, 07 Oct 2012 14:06:50 +0000
Received: from [85.158.143.35:5720] by server-3.bemta-4.messagelabs.com id
	B1/58-10986-97C81705; Sun, 07 Oct 2012 14:06:49 +0000
X-Env-Sender: weiyj.lk@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1349618807!15146282!1
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7048 invoked from network); 7 Oct 2012 14:06:48 -0000
Received: from mail-qa0-f43.google.com (HELO mail-qa0-f43.google.com)
	(209.85.216.43)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Oct 2012 14:06:48 -0000
Received: by mail-qa0-f43.google.com with SMTP id k1so1485182qaf.9
	for ;
	Sun, 07 Oct 2012 07:06:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:cc:content-type;
	bh=WY8hGgfYChffkLIh12nQbBf+Utv2xFdlhzIijbXkXCY=;
	b=Q8jNmoheZUbNH08JI7njvxyQ/rRUcnmDzW90/3en6lm3myLA0z2PmCKRcIjt3cgsDe
	ZIpm0TJ1UcP15RO91LU0meGZvl1LL7uRkgknn784VJjrl+SOwHpgpUf1y4HrDIb+Kw6Z
	W5Y+KP7CY5qu5oQXJ8CAJp3iMSVXmc82FZrWC5kVnw0+ojsp9YHxHMFFVQpIcUl0FL/p
	4qP4zw0fCMqWVIDcs+eCJrwvvK/LkKuy8JSw20n6i0ZZiwjDZlDyEvPLFsazGVMESy6t
	QzMED5yhrurEvoyMoXUeP5zp7N1x/YzZkBWdCKJUtyIgSO+FI7zNZoDs1u9SMYErviyK
	/WGQ==
MIME-Version: 1.0
Received: by 10.224.100.200 with SMTP id z8mr25637046qan.75.1349618807509;
	Sun, 07 Oct 2012 07:06:47 -0700 (PDT)
Received: by 10.229.146.194 with HTTP; Sun, 7 Oct 2012 07:06:47 -0700 (PDT)
Date: Sun, 7 Oct 2012 22:06:47 +0800
Message-ID: 
From: Wei Yongjun 
To: konrad.wilk@oracle.com, jeremy@goop.org, tglx@linutronix.de, 
	mingo@redhat.com, hpa@zytor.com
X-Mailman-Approved-At: Sun, 07 Oct 2012 15:45:34 +0000
Cc: linux-kernel@vger.kernel.org, yongjun_wei@trendmicro.com.cn, x86@kernel.org,
	xen-devel@lists.xensource.com, virtualization@lists.linux-foundation.org
Subject: [Xen-devel] [PATCH] xen/x86: remove duplicated include from
	enlighten.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Wei Yongjun 

Remove duplicated include.

dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)

Signed-off-by: Wei Yongjun 
---
 arch/x86/xen/enlighten.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index bf788d3..061b148 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -81,8 +81,6 @@
 #include "smp.h"
 #include "multicalls.h"
 
-#include 
-
 EXPORT_SYMBOL_GPL(hypercall_page);
 
 DEFINE_PER_CPU(struct vcpu_info *, xen_vcpu);


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 07 23:35:38 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Oct 2012 23:35:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TL0N6-0004qz-O5; Sun, 07 Oct 2012 23:34:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TL0N5-0004qu-EX
	for xen-devel@lists.xensource.com; Sun, 07 Oct 2012 23:34:55 +0000
Received: from [85.158.143.35:49275] by server-2.bemta-4.messagelabs.com id
	FD/EA-06610-E9112705; Sun, 07 Oct 2012 23:34:54 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1349652892!13382187!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22438 invoked from network); 7 Oct 2012 23:34:53 -0000
Received: from mail-qc0-f171.google.com (HELO mail-qc0-f171.google.com)
	(209.85.216.171)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Oct 2012 23:34:53 -0000
Received: by mail-qc0-f171.google.com with SMTP id d1so34651qca.30
	for ;
	Sun, 07 Oct 2012 16:34:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=NfaqQvQ219mn5EAO2liZnJnKHEpGi1CLfwRmYiiVXa8=;
	b=FVb8mEDJlvRNmvSodU+Z4okxZfnkUr6Z6hVn2PJ4b6Psrhb1Ayrxd9r29fg731yP4e
	Ey9pmxHUY4AWN6WZ2vfj4sFHE9y0+7QgU3qHCSKD1xdoaYPrDPpyZX4JNEjxWc2DEb+1
	2vwkdJ8p5uW725FeCPkHAYi161Ebj61XUqGNxOYv9FjoMmNIoqafNvRFFTZ/xv1N7CEu
	OYGWJwFIHGM6iBsP6LZL1IcEXy3JxMvfjtWK+R5qUqIYAeiVjhrX4JCNuOGeFdwu6MqR
	mdgLIVKUSWNXalcem40+7nHqA+g/9OP14KH2IEPud4dVWs6K3j31AkEPv58RZPNq5d2y
	Yudw==
Received: by 10.49.27.71 with SMTP id r7mr38396491qeg.38.1349652892703;
	Sun, 07 Oct 2012 16:34:52 -0700 (PDT)
Received: from localhost.localdomain
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id f12sm16388440qey.5.2012.10.07.16.34.51
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sun, 07 Oct 2012 16:34:52 -0700 (PDT)
Date: Sun, 7 Oct 2012 19:34:45 -0400
From: Konrad Rzeszutek Wilk 
To: Sander Eikelenboom 
Message-ID: <20121007233444.GA26929@localhost.localdomain>
References: 
	<729626082.20121006002054@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <729626082.20121006002054@eikelenboom.it>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xensource.com, konrad 
Subject: Re: [Xen-devel] Kernel 3.7.0-pre-rc1 kernel BUG at
 drivers/net/xen-netback/netback.c:405 RIP: e030:[]
 [] netbk_gop_frag_copy+0x379/0x380
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Oct 06, 2012 at 12:20:54AM +0200, Sander Eikelenboom wrote:
> 
> Friday, October 5, 2012, 9:26:31 PM, you wrote:
> 
> > Sorry for top posting - on mobile.
> 
> > I saw it too yesterday but only on a specific hardware - AMD FX8. What type of CPU do you have?  Does xsave=off on Xen line help?
> 
> Nope the xsave=off doesn't help
> 
> > Sander Eikelenboom  wrote:
> 
> >>Hi Konrad,
> >>
> >>Just tested kernel 3.7.0-pre-rc1 but ran into a oops in netback on boot after starting some guests:
> >>
> >>[  402.723915] ------------[ cut here ]------------
> >>[  402.734629] kernel BUG at drivers/net/xen-netback/netback.c:405!

Looking at the code, this is what we get:

        /* Data must not cross a page boundary. */
        BUG_ON(size + offset > PAGE_SIZE);

Looking at the commits, the one recently added was:
commit c571898ffc24a1768e1b2dabeac0fc7dd4c14601
Author: Andres Lagar-Cavilla 
Date:   Fri Sep 14 14:26:59 2012 +0000

    xen/gndev: Xen backend support for paged out grant targets V4.
    

But after reverting it and trying the kernel I still got the crash.

So .. the weirdness is that this seems to be only happening on
certain AMD machines - for example on my AMD A8 box I did not see this.

I fear that the next step is to do a bit off git bisection to
get an idea of which merge it might be. I am going to be AFK
on Monday so I won't get to this until Tuesday/Wednesay :-(

.. Thought to help speed this process, this looks like a
candidate:

commit 229993001282e128a49a59ec43d255614775703a
Merge: 7687b80 fd0f586
Author: Linus Torvalds 
Date:   Mon Oct 1 11:13:33 2012 -0700

    Merge branch 'x86-mm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
    
    Pull x86/mm changes from Ingo Molnar:
     "The biggest change is new TLB partial flushing code for AMD CPUs.
      (The v3.6 kernel had the Intel CPU side code, see commits
      e0ba94f14f74..effee4b9b3b.)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 07 23:35:38 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Oct 2012 23:35:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TL0N6-0004qz-O5; Sun, 07 Oct 2012 23:34:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TL0N5-0004qu-EX
	for xen-devel@lists.xensource.com; Sun, 07 Oct 2012 23:34:55 +0000
Received: from [85.158.143.35:49275] by server-2.bemta-4.messagelabs.com id
	FD/EA-06610-E9112705; Sun, 07 Oct 2012 23:34:54 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1349652892!13382187!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22438 invoked from network); 7 Oct 2012 23:34:53 -0000
Received: from mail-qc0-f171.google.com (HELO mail-qc0-f171.google.com)
	(209.85.216.171)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Oct 2012 23:34:53 -0000
Received: by mail-qc0-f171.google.com with SMTP id d1so34651qca.30
	for ;
	Sun, 07 Oct 2012 16:34:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=NfaqQvQ219mn5EAO2liZnJnKHEpGi1CLfwRmYiiVXa8=;
	b=FVb8mEDJlvRNmvSodU+Z4okxZfnkUr6Z6hVn2PJ4b6Psrhb1Ayrxd9r29fg731yP4e
	Ey9pmxHUY4AWN6WZ2vfj4sFHE9y0+7QgU3qHCSKD1xdoaYPrDPpyZX4JNEjxWc2DEb+1
	2vwkdJ8p5uW725FeCPkHAYi161Ebj61XUqGNxOYv9FjoMmNIoqafNvRFFTZ/xv1N7CEu
	OYGWJwFIHGM6iBsP6LZL1IcEXy3JxMvfjtWK+R5qUqIYAeiVjhrX4JCNuOGeFdwu6MqR
	mdgLIVKUSWNXalcem40+7nHqA+g/9OP14KH2IEPud4dVWs6K3j31AkEPv58RZPNq5d2y
	Yudw==
Received: by 10.49.27.71 with SMTP id r7mr38396491qeg.38.1349652892703;
	Sun, 07 Oct 2012 16:34:52 -0700 (PDT)
Received: from localhost.localdomain
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id f12sm16388440qey.5.2012.10.07.16.34.51
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sun, 07 Oct 2012 16:34:52 -0700 (PDT)
Date: Sun, 7 Oct 2012 19:34:45 -0400
From: Konrad Rzeszutek Wilk 
To: Sander Eikelenboom 
Message-ID: <20121007233444.GA26929@localhost.localdomain>
References: 
	<729626082.20121006002054@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <729626082.20121006002054@eikelenboom.it>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xensource.com, konrad 
Subject: Re: [Xen-devel] Kernel 3.7.0-pre-rc1 kernel BUG at
 drivers/net/xen-netback/netback.c:405 RIP: e030:[]
 [] netbk_gop_frag_copy+0x379/0x380
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Oct 06, 2012 at 12:20:54AM +0200, Sander Eikelenboom wrote:
> 
> Friday, October 5, 2012, 9:26:31 PM, you wrote:
> 
> > Sorry for top posting - on mobile.
> 
> > I saw it too yesterday but only on a specific hardware - AMD FX8. What type of CPU do you have?  Does xsave=off on Xen line help?
> 
> Nope the xsave=off doesn't help
> 
> > Sander Eikelenboom  wrote:
> 
> >>Hi Konrad,
> >>
> >>Just tested kernel 3.7.0-pre-rc1 but ran into a oops in netback on boot after starting some guests:
> >>
> >>[  402.723915] ------------[ cut here ]------------
> >>[  402.734629] kernel BUG at drivers/net/xen-netback/netback.c:405!

Looking at the code, this is what we get:

        /* Data must not cross a page boundary. */
        BUG_ON(size + offset > PAGE_SIZE);

Looking at the commits, the one recently added was:
commit c571898ffc24a1768e1b2dabeac0fc7dd4c14601
Author: Andres Lagar-Cavilla 
Date:   Fri Sep 14 14:26:59 2012 +0000

    xen/gndev: Xen backend support for paged out grant targets V4.
    

But after reverting it and trying the kernel I still got the crash.

So .. the weirdness is that this seems to be only happening on
certain AMD machines - for example on my AMD A8 box I did not see this.

I fear that the next step is to do a bit off git bisection to
get an idea of which merge it might be. I am going to be AFK
on Monday so I won't get to this until Tuesday/Wednesay :-(

.. Thought to help speed this process, this looks like a
candidate:

commit 229993001282e128a49a59ec43d255614775703a
Merge: 7687b80 fd0f586
Author: Linus Torvalds 
Date:   Mon Oct 1 11:13:33 2012 -0700

    Merge branch 'x86-mm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
    
    Pull x86/mm changes from Ingo Molnar:
     "The biggest change is new TLB partial flushing code for AMD CPUs.
      (The v3.6 kernel had the Intel CPU side code, see commits
      e0ba94f14f74..effee4b9b3b.)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 07 23:44:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Oct 2012 23:44:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TL0Vp-000508-Oj; Sun, 07 Oct 2012 23:43:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TL0Vn-000503-GJ
	for xen-devel@lists.xen.org; Sun, 07 Oct 2012 23:43:55 +0000
Received: from [85.158.143.35:64160] by server-2.bemta-4.messagelabs.com id
	15/8C-06610-AB312705; Sun, 07 Oct 2012 23:43:54 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1349653432!12725000!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzg4ODA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17706 invoked from network); 7 Oct 2012 23:43:53 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Oct 2012 23:43:53 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q97Nhbd5022661
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 7 Oct 2012 23:43:39 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q97NhbJ5006396
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 7 Oct 2012 23:43:37 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q97Nha6O001557; Sun, 7 Oct 2012 18:43:36 -0500
MIME-Version: 1.0
Message-ID: <8d8eda1d-5598-4df4-96c4-1d7a307e6423@default>
Date: Sun, 7 Oct 2012 16:43:33 -0700 (PDT)
From: Dan Magenheimer 
To: Andres Lagar-Cavilla 
References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default>
	<20581.55931.246130.308384@mariner.uk.xensource.com>
	<8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default>
	<20121002091017.GA95926@ocelot.phlegethon.org>
	<66cc0085-1216-40f7-8059-eaf615202c12@default>
	<20121002201624.GA98445@ocelot.phlegethon.org>
	
	<20121004100645.GC38243@ocelot.phlegethon.org>
	<51CA094C-870A-4772-A22E-4CB151E854F2@gridcentric.ca>
	<48a08581-faa9-40a0-8afd-dc334ab82e43@default>
	<91C20B33-83CF-4B7A-A5AC-E61421B00536@gridcentric.ca>
	<16aa5326-5fd9-4f9c-b0fe-6196c6379991@default>
	<1C4CD35F-94F0-44CF-97EA-137DF20E9669@gridcentric.ca>
	<52e8fc33-59b3-4d28-82a7-b648e3e28cf5@default>
	<78F5EF0B-15B6-4907-AE01-88CC42D052F0@gridcentric.ca>
In-Reply-To: <78F5EF0B-15B6-4907-AE01-88CC42D052F0@gridcentric.ca>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Olaf Hering , Keir Fraser ,
	Konrad Wilk ,
	George Dunlap ,
	Kurt Hackel , Tim Deegan ,
	xen-devel@lists.xen.org, George Shuklin ,
	Dario Faggioli , Ian Jackson 
Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and
	xl)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > In other words, between reservation and unreserve, there is no
> > memory overcommit for that domain.  Once the toolstack does
> > the unreserve, its memory is available for overcommit mechanisms.
> 
> I think that will be fragile. Suppose you have a 16 GiB domain and an overcommit mechanism that allows
> you to start the VM with 8 GiB. Straight-forward scenario with xen-4.2 and a combination of PoD and
> ballooning. Suppose you have 14GiB of RAM free in the system. Why should creation of that domain fail?

It shouldn't.  Either I'm not clear or I don't understand PoD.

My understanding of PoD is that, for the above case, the
domain has "mem=8192 maxmem=16394".  So with my proposal
xl would ask for a reservation of 8192M and, when the domain
is successfully launched (i.e. for PoD, balloon driver is running?),
make the matching unreserve call. *

Not sure why that would be any more fragile than today.  In
fact it seems to me it is less fragile... changing your example
to "8GiB of RAM free in the system", today, xl will ask if there
is enough memory and will be told yes and attempt to launch the
domain.  But then suppose in between the time xl asks the hypervisor
if there is enough free memory and the time it attempts to launch
the domain, another domain eats up a few pages and now there is
ever so slightly less than 8GiB.  Won't the domain creation
commence and then fail a few moments later?  (A few moments, 
probably not a big deal, but multiply the memory sizes by 64
and a few moments becomes a few minutes!)

With my proposal, the domain will immediately fail to launch
because the reservation will fail.
 
* Maybe the above "there is no memory overcommit for that domain"
was confusing?  I suppose you could call that "mem=8192
maxmem=16384" overcommit... I just didn't think of it that
way.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 07 23:44:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 07 Oct 2012 23:44:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TL0Vp-000508-Oj; Sun, 07 Oct 2012 23:43:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TL0Vn-000503-GJ
	for xen-devel@lists.xen.org; Sun, 07 Oct 2012 23:43:55 +0000
Received: from [85.158.143.35:64160] by server-2.bemta-4.messagelabs.com id
	15/8C-06610-AB312705; Sun, 07 Oct 2012 23:43:54 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1349653432!12725000!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzg4ODA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17706 invoked from network); 7 Oct 2012 23:43:53 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Oct 2012 23:43:53 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q97Nhbd5022661
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 7 Oct 2012 23:43:39 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q97NhbJ5006396
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 7 Oct 2012 23:43:37 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q97Nha6O001557; Sun, 7 Oct 2012 18:43:36 -0500
MIME-Version: 1.0
Message-ID: <8d8eda1d-5598-4df4-96c4-1d7a307e6423@default>
Date: Sun, 7 Oct 2012 16:43:33 -0700 (PDT)
From: Dan Magenheimer 
To: Andres Lagar-Cavilla 
References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default>
	<20581.55931.246130.308384@mariner.uk.xensource.com>
	<8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default>
	<20121002091017.GA95926@ocelot.phlegethon.org>
	<66cc0085-1216-40f7-8059-eaf615202c12@default>
	<20121002201624.GA98445@ocelot.phlegethon.org>
	
	<20121004100645.GC38243@ocelot.phlegethon.org>
	<51CA094C-870A-4772-A22E-4CB151E854F2@gridcentric.ca>
	<48a08581-faa9-40a0-8afd-dc334ab82e43@default>
	<91C20B33-83CF-4B7A-A5AC-E61421B00536@gridcentric.ca>
	<16aa5326-5fd9-4f9c-b0fe-6196c6379991@default>
	<1C4CD35F-94F0-44CF-97EA-137DF20E9669@gridcentric.ca>
	<52e8fc33-59b3-4d28-82a7-b648e3e28cf5@default>
	<78F5EF0B-15B6-4907-AE01-88CC42D052F0@gridcentric.ca>
In-Reply-To: <78F5EF0B-15B6-4907-AE01-88CC42D052F0@gridcentric.ca>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Olaf Hering , Keir Fraser ,
	Konrad Wilk ,
	George Dunlap ,
	Kurt Hackel , Tim Deegan ,
	xen-devel@lists.xen.org, George Shuklin ,
	Dario Faggioli , Ian Jackson 
Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and
	xl)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > In other words, between reservation and unreserve, there is no
> > memory overcommit for that domain.  Once the toolstack does
> > the unreserve, its memory is available for overcommit mechanisms.
> 
> I think that will be fragile. Suppose you have a 16 GiB domain and an overcommit mechanism that allows
> you to start the VM with 8 GiB. Straight-forward scenario with xen-4.2 and a combination of PoD and
> ballooning. Suppose you have 14GiB of RAM free in the system. Why should creation of that domain fail?

It shouldn't.  Either I'm not clear or I don't understand PoD.

My understanding of PoD is that, for the above case, the
domain has "mem=8192 maxmem=16394".  So with my proposal
xl would ask for a reservation of 8192M and, when the domain
is successfully launched (i.e. for PoD, balloon driver is running?),
make the matching unreserve call. *

Not sure why that would be any more fragile than today.  In
fact it seems to me it is less fragile... changing your example
to "8GiB of RAM free in the system", today, xl will ask if there
is enough memory and will be told yes and attempt to launch the
domain.  But then suppose in between the time xl asks the hypervisor
if there is enough free memory and the time it attempts to launch
the domain, another domain eats up a few pages and now there is
ever so slightly less than 8GiB.  Won't the domain creation
commence and then fail a few moments later?  (A few moments, 
probably not a big deal, but multiply the memory sizes by 64
and a few moments becomes a few minutes!)

With my proposal, the domain will immediately fail to launch
because the reservation will fail.
 
* Maybe the above "there is no memory overcommit for that domain"
was confusing?  I suppose you could call that "mem=8192
maxmem=16384" overcommit... I just didn't think of it that
way.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 01:03:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 01:03:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TL1jt-000169-26; Mon, 08 Oct 2012 01:02:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TL1jr-000164-2n
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 01:02:31 +0000
Received: from [85.158.143.35:42661] by server-3.bemta-4.messagelabs.com id
	59/91-10986-62622705; Mon, 08 Oct 2012 01:02:30 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1349658147!21385760!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzg4ODA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14077 invoked from network); 8 Oct 2012 01:02:29 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 01:02:29 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9812FXf031199
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 8 Oct 2012 01:02:16 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9812DVJ026342
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 8 Oct 2012 01:02:14 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9812C4C017213; Sun, 7 Oct 2012 20:02:12 -0500
MIME-Version: 1.0
Message-ID: <58b5a25d-ccdd-4d0c-a0d9-9c249825f7f1@default>
Date: Sun, 7 Oct 2012 18:02:09 -0700 (PDT)
From: Dan Magenheimer 
To: George Dunlap 
References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default>
	<20581.55931.246130.308384@mariner.uk.xensource.com>
	<8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default>
	<20121002091017.GA95926@ocelot.phlegethon.org>
	<66cc0085-1216-40f7-8059-eaf615202c12@default>
	<20121002201624.GA98445@ocelot.phlegethon.org>
	
	<20121004100645.GC38243@ocelot.phlegethon.org>
	<1349345864.650.247.camel@zakaz.uk.xensource.com>
	<239799F4-AF29-494F-86D2-ADF45ACA8792@gridcentric.ca>
	<3e5cf0ba-4241-4f00-bef6-aaff2cc23419@default>
	<506EC710.3020606@eu.citrix.com>
In-Reply-To: <506EC710.3020606@eu.citrix.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Olaf Hering , "Keir \(Xen.org\)" ,
	Ian Campbell ,
	Konrad Wilk ,
	Andres Lagar-Cavilla ,
	"Tim \(Xen.org\)" , xen-devel@lists.xen.org,
	George Shuklin ,
	Dario Faggioli , Kurt Hackel ,
	Ian Jackson 
Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and
	xl)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: George Dunlap [mailto:george.dunlap@eu.citrix.com]
> Sent: Friday, October 05, 2012 5:40 AM
> To: Dan Magenheimer
> Cc: Andres Lagar-Cavilla; Ian Campbell; Tim (Xen.org); Olaf Hering; Keir (Xen.org); Konrad Wilk; Kurt
> Hackel; Ian Jackson; xen-devel@lists.xen.org; George Shuklin; Dario Faggioli
> Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl)

Hi George --

Thanks for your thoughts!
 
> On 04/10/12 17:54, Dan Magenheimer wrote:
> >>
> > Scanning through the archived message I am under the impression
> > that the focus is on a single server... i.e. "punt if actor is
> > not xl", i.e. it addressed "balloon-to-fit" and only tries to avoid
> > stepping on other memory overcommit technologies.  That makes it
> > almost orthogonal, I think, to the problem I originally raised.
> No, the idea was to allow the flexibility of different actors in
> different situations.  The plan was to start with a simple actor, but to
> add new ones as necessary.  But on reflection, it seems like the whole
> "actor" thing was actually something completely separate to what we're
> talking about here.  The idea behind the actor (IIRC) was that you could
> tell the toolstack, "Make VM A use X amount of host memory"; and the
> actor would determine the best way to do that -- either by only
> ballooning, or ballooning first and then swapping.  But it doesn't
> decide how to get the value X.

OK, so if the actor stuff is orthogonal, let's go back to the
original problem.  We do want to ensure the solution doesn't _break_
the actor idea... but IMHO any assumption that there is an actor
that can always sufficiently "control" memory allocation is suspect.

> This thread has been very hard to follow for some reason, so let me see
> if I can understand everything:
> * You are concerned about being able to predictably start VMs in the
> face of:
>   - concurrent requests, and
>   - dynamic memory technologies (including PoD, ballooning, paging, page
> sharing, and tmem)
> Any of which may change the amount of free memory between the time a
> decision is made and the time memory is actually allocated.
> * You have proposed a hypervisor-based solution that allows the
> toolstack to "reserve" a specific amount of memory to a VM that will not
> be used for something else; this allocation is transactional -- it will
> either completely succeed, or completely fail, and do it quickly.
> 
> Is that correct?

Yes, good summary.

> The problem with that solution, it seems to me, is that the hypervisor
> does not (and I think probably should not) have any insight into the
> policy for allocating or freeing memory as a result of other activities,
> such as ballooning or page sharing.  Suppose someone were ballooning
> down domain M to get 8GiB in order to start domain A; and at some point
> , another process looks and says, "Oh look, there's 4GiB free, that's
> enough to start domain B" and asks Xen to reserve that memory.  Xen has
> no way of knowing that the memory freed by domain M was "earmarked" for
> domain A, and so will happily give it to domain B, causing domain A's
> creation to fail (potentially).

I agree completely that the hypervisor shouldn't have any insight into
the _policy_ (though see below).  I'm just proposing an extension to the
existing mechanism and I am quite convinced that the hypervisor must
be involved (e.g. a new hypercall) for the extension to work properly.

In your example, the "someone" ballooning down domain M to get 8GiB
for domain M would need somehow to "reserve" the memory for domain M.
I didn't foresee the use of the proposed reservation mechanism beyond
domain creation, but it could probably be used for large ballooning
quantities as well.

> So it seems like we need to have the idea of a memory controller -- one
> central process (per host, as you say) that would know about all of the
> knobs -- ballooning, paging, page sharing, tmem, whatever -- that could
> be in charge of knowing where all the memory was coming from and where
> it was going.  So if xl wanted to start a new VM, it can ask the memory
> controller for 3GiB, and the controller could decide, "I'll take 1GiB
> from domain M and 2 from domain N, and give it to the new domain", and
> respond when it has the memory that it needs.  Similarly, it can know
> that it should try to keep X megabytes for un-sharing of pages, and it
> can be responsible for freeing up more memory if that memory becomes
> exhausted.

First, let me quibble about the term you used.  It's especially
important for you, George, because I know your previous Xen contributions.

IMHO, we are not talking about a "memory controller", we are talking
about a "memory scheduler".  In a CPU scheduler, one would never
assume that all demands for CPU time should be reviewed and granted
by some userland process in dom0 (and certainly not by some grand
central data center manager).  That would be silly.  Instead, we
provide some policy parameters and let each hypervisor make intelligent
dynamic decisions thousands of times every second based on those parameters.

IMHO, the example you give for asking a memory controller for GiB
of memory is equally silly.  Outside of some geek with a handful
of VMs on a single machine, there is inadequate information from
any VM to drive automatic memory allocation decisions and, even if
there was, it just doesn't scale.  It doesn't scale either up, to
many VMs across many physical machines, or down, to instantaneous
needs of one-page-at-a-time requests for unsharing or for tmem.

(Also see my previous comments to Tim about memory-overcommit-by-
undercommit:  There isn't sufficient information to size any
emergency buffer for unsharing either... too big and you waste
memory, too little and it doesn't solve the underlying problem.)

> At the moment, the administrator himself (or the cloud orchestration
> layer) needs to be his own memory controller; that is, he needs to
> manually decide if there's enough free memory to start a VM; if there's
> not, he needs to figure out how to get that memory (either by ballooning
> or swapping).  Ballooning and swapping are both totally under his
> control; the only thing he doesn't control is the unsharing of pages.
> But as long as there was a way to tell the page sharing daemon not to
> allocate an amount of free memory, then this
> "administrator-as-memory-controller" should work just fine.
> 
> Does that make sense?  Or am I still confused? :-)

It mostly makes sense until you get to host-swapping/unsharing,
see comments above.  And tmem takes the "doesn't control" to a
whole new level.  Meaning tmem (IMHO) completely eliminates
the possibility of a "memory controller" and begs for a
"memory scheduler".

Tmem really is a breakthrough on memory management in a virtualized
system.  I realize that many people are in the "if it doesn't
work on Windows, I don't care" camp.  And others never thought
it would make it into upstream Linux (or don't care because it isn't
completely functional in any distros yet... other than Oracle's..
but since all parts are now upstream, it will be soon).  But there
probably are also many that just don't understand it... I guess I need
to work on fixing that.  Any thoughts on how to start?

In any case, though the reservation proposal is intended to cover
tmem as well, I think it is still needed for page-sharing and
domain-creation "races".

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 01:03:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 01:03:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TL1jt-000169-26; Mon, 08 Oct 2012 01:02:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TL1jr-000164-2n
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 01:02:31 +0000
Received: from [85.158.143.35:42661] by server-3.bemta-4.messagelabs.com id
	59/91-10986-62622705; Mon, 08 Oct 2012 01:02:30 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1349658147!21385760!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzg4ODA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14077 invoked from network); 8 Oct 2012 01:02:29 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 01:02:29 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9812FXf031199
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 8 Oct 2012 01:02:16 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9812DVJ026342
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 8 Oct 2012 01:02:14 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9812C4C017213; Sun, 7 Oct 2012 20:02:12 -0500
MIME-Version: 1.0
Message-ID: <58b5a25d-ccdd-4d0c-a0d9-9c249825f7f1@default>
Date: Sun, 7 Oct 2012 18:02:09 -0700 (PDT)
From: Dan Magenheimer 
To: George Dunlap 
References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default>
	<20581.55931.246130.308384@mariner.uk.xensource.com>
	<8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default>
	<20121002091017.GA95926@ocelot.phlegethon.org>
	<66cc0085-1216-40f7-8059-eaf615202c12@default>
	<20121002201624.GA98445@ocelot.phlegethon.org>
	
	<20121004100645.GC38243@ocelot.phlegethon.org>
	<1349345864.650.247.camel@zakaz.uk.xensource.com>
	<239799F4-AF29-494F-86D2-ADF45ACA8792@gridcentric.ca>
	<3e5cf0ba-4241-4f00-bef6-aaff2cc23419@default>
	<506EC710.3020606@eu.citrix.com>
In-Reply-To: <506EC710.3020606@eu.citrix.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Olaf Hering , "Keir \(Xen.org\)" ,
	Ian Campbell ,
	Konrad Wilk ,
	Andres Lagar-Cavilla ,
	"Tim \(Xen.org\)" , xen-devel@lists.xen.org,
	George Shuklin ,
	Dario Faggioli , Kurt Hackel ,
	Ian Jackson 
Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and
	xl)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: George Dunlap [mailto:george.dunlap@eu.citrix.com]
> Sent: Friday, October 05, 2012 5:40 AM
> To: Dan Magenheimer
> Cc: Andres Lagar-Cavilla; Ian Campbell; Tim (Xen.org); Olaf Hering; Keir (Xen.org); Konrad Wilk; Kurt
> Hackel; Ian Jackson; xen-devel@lists.xen.org; George Shuklin; Dario Faggioli
> Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl)

Hi George --

Thanks for your thoughts!
 
> On 04/10/12 17:54, Dan Magenheimer wrote:
> >>
> > Scanning through the archived message I am under the impression
> > that the focus is on a single server... i.e. "punt if actor is
> > not xl", i.e. it addressed "balloon-to-fit" and only tries to avoid
> > stepping on other memory overcommit technologies.  That makes it
> > almost orthogonal, I think, to the problem I originally raised.
> No, the idea was to allow the flexibility of different actors in
> different situations.  The plan was to start with a simple actor, but to
> add new ones as necessary.  But on reflection, it seems like the whole
> "actor" thing was actually something completely separate to what we're
> talking about here.  The idea behind the actor (IIRC) was that you could
> tell the toolstack, "Make VM A use X amount of host memory"; and the
> actor would determine the best way to do that -- either by only
> ballooning, or ballooning first and then swapping.  But it doesn't
> decide how to get the value X.

OK, so if the actor stuff is orthogonal, let's go back to the
original problem.  We do want to ensure the solution doesn't _break_
the actor idea... but IMHO any assumption that there is an actor
that can always sufficiently "control" memory allocation is suspect.

> This thread has been very hard to follow for some reason, so let me see
> if I can understand everything:
> * You are concerned about being able to predictably start VMs in the
> face of:
>   - concurrent requests, and
>   - dynamic memory technologies (including PoD, ballooning, paging, page
> sharing, and tmem)
> Any of which may change the amount of free memory between the time a
> decision is made and the time memory is actually allocated.
> * You have proposed a hypervisor-based solution that allows the
> toolstack to "reserve" a specific amount of memory to a VM that will not
> be used for something else; this allocation is transactional -- it will
> either completely succeed, or completely fail, and do it quickly.
> 
> Is that correct?

Yes, good summary.

> The problem with that solution, it seems to me, is that the hypervisor
> does not (and I think probably should not) have any insight into the
> policy for allocating or freeing memory as a result of other activities,
> such as ballooning or page sharing.  Suppose someone were ballooning
> down domain M to get 8GiB in order to start domain A; and at some point
> , another process looks and says, "Oh look, there's 4GiB free, that's
> enough to start domain B" and asks Xen to reserve that memory.  Xen has
> no way of knowing that the memory freed by domain M was "earmarked" for
> domain A, and so will happily give it to domain B, causing domain A's
> creation to fail (potentially).

I agree completely that the hypervisor shouldn't have any insight into
the _policy_ (though see below).  I'm just proposing an extension to the
existing mechanism and I am quite convinced that the hypervisor must
be involved (e.g. a new hypercall) for the extension to work properly.

In your example, the "someone" ballooning down domain M to get 8GiB
for domain M would need somehow to "reserve" the memory for domain M.
I didn't foresee the use of the proposed reservation mechanism beyond
domain creation, but it could probably be used for large ballooning
quantities as well.

> So it seems like we need to have the idea of a memory controller -- one
> central process (per host, as you say) that would know about all of the
> knobs -- ballooning, paging, page sharing, tmem, whatever -- that could
> be in charge of knowing where all the memory was coming from and where
> it was going.  So if xl wanted to start a new VM, it can ask the memory
> controller for 3GiB, and the controller could decide, "I'll take 1GiB
> from domain M and 2 from domain N, and give it to the new domain", and
> respond when it has the memory that it needs.  Similarly, it can know
> that it should try to keep X megabytes for un-sharing of pages, and it
> can be responsible for freeing up more memory if that memory becomes
> exhausted.

First, let me quibble about the term you used.  It's especially
important for you, George, because I know your previous Xen contributions.

IMHO, we are not talking about a "memory controller", we are talking
about a "memory scheduler".  In a CPU scheduler, one would never
assume that all demands for CPU time should be reviewed and granted
by some userland process in dom0 (and certainly not by some grand
central data center manager).  That would be silly.  Instead, we
provide some policy parameters and let each hypervisor make intelligent
dynamic decisions thousands of times every second based on those parameters.

IMHO, the example you give for asking a memory controller for GiB
of memory is equally silly.  Outside of some geek with a handful
of VMs on a single machine, there is inadequate information from
any VM to drive automatic memory allocation decisions and, even if
there was, it just doesn't scale.  It doesn't scale either up, to
many VMs across many physical machines, or down, to instantaneous
needs of one-page-at-a-time requests for unsharing or for tmem.

(Also see my previous comments to Tim about memory-overcommit-by-
undercommit:  There isn't sufficient information to size any
emergency buffer for unsharing either... too big and you waste
memory, too little and it doesn't solve the underlying problem.)

> At the moment, the administrator himself (or the cloud orchestration
> layer) needs to be his own memory controller; that is, he needs to
> manually decide if there's enough free memory to start a VM; if there's
> not, he needs to figure out how to get that memory (either by ballooning
> or swapping).  Ballooning and swapping are both totally under his
> control; the only thing he doesn't control is the unsharing of pages.
> But as long as there was a way to tell the page sharing daemon not to
> allocate an amount of free memory, then this
> "administrator-as-memory-controller" should work just fine.
> 
> Does that make sense?  Or am I still confused? :-)

It mostly makes sense until you get to host-swapping/unsharing,
see comments above.  And tmem takes the "doesn't control" to a
whole new level.  Meaning tmem (IMHO) completely eliminates
the possibility of a "memory controller" and begs for a
"memory scheduler".

Tmem really is a breakthrough on memory management in a virtualized
system.  I realize that many people are in the "if it doesn't
work on Windows, I don't care" camp.  And others never thought
it would make it into upstream Linux (or don't care because it isn't
completely functional in any distros yet... other than Oracle's..
but since all parts are now upstream, it will be soon).  But there
probably are also many that just don't understand it... I guess I need
to work on fixing that.  Any thoughts on how to start?

In any case, though the reservation proposal is intended to cover
tmem as well, I think it is still needed for page-sharing and
domain-creation "races".

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 02:17:21 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 02:17:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TL2th-0001uc-N4; Mon, 08 Oct 2012 02:16:45 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TL2tf-0001uX-OW
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 02:16:43 +0000
X-Env-Sender: aware.why@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1349662596!3994388!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23225 invoked from network); 8 Oct 2012 02:16:37 -0000
Received: from mail-ea0-f171.google.com (HELO mail-ea0-f171.google.com)
	(209.85.215.171)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 02:16:37 -0000
Received: by mail-ea0-f171.google.com with SMTP id k14so115377eaa.30
	for ;
	Sun, 07 Oct 2012 19:16:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=PAn8bmgk04YsSwRxV1KAlokZhzok3SZS06sqN7q3Xx8=;
	b=oisVKal4Xu0k3EFrOLMwHHL+TwN5L56VXumryRkFySRuIzxgKFGROjLEAPlksd59B9
	4D1WmOBJMIERujfEk9eX6bGShftf1kC1sDWkRrk8JfIOtJBj2AXzW2k8DsiNX0181Ca3
	lbv5fl6p3XY6jGhUnVcOdLUM6uxVterGtVX3ilYzZMj0owXLvDZ1rzuY0BQDxDWfYM4P
	FEJaMBaxdtc33dk2Oj/LArO77jqinf8MZJAdM1C21LvYO/BAiuASH3CPYX6uQ7xoDCXZ
	8+iooJg6fC4MzaZUKJY8wCYMwed6S+7Em04U2kBOo2ChcrmhLnnNtOJ0XLkCV1DhrcAS
	FQEA==
MIME-Version: 1.0
Received: by 10.14.194.136 with SMTP id m8mr20463768een.10.1349662596580; Sun,
	07 Oct 2012 19:16:36 -0700 (PDT)
Received: by 10.14.100.71 with HTTP; Sun, 7 Oct 2012 19:16:36 -0700 (PDT)
In-Reply-To: 
References: 
	
Date: Mon, 8 Oct 2012 10:16:36 +0800
Message-ID: 
From: =?UTF-8?B?6ams56OK?= 
To: George Dunlap 
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] =?utf-8?b?44CQY29uZnVzZWTjgJF3aGF0IGRvZXMgeGNfbWFw?=
	=?utf-8?b?X2ZvcmVpZ25fYmF0Y2ggZG/vvJ8=?=
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============6912409168489172128=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6912409168489172128==
Content-Type: multipart/alternative; boundary=047d7b33dc5ca2c42304cb82cfab

--047d7b33dc5ca2c42304cb82cfab
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Oct 1, 2012 at 10:17 PM, George Dunlap
wrote:

> On Sat, Sep 29, 2012 at 4:07 AM, =E9=A9=AC=E7=A3=8A =
 wrote:
> > Hi=EF=BC=8C all
> >  In tools/libxc/xc_domain_save .c, one function called
> > `map_and_save_p2m_table` where there exists a confusing problem, as is
> shown
> > below:
> >
> >  621    live_p2m_frame_list =3D
> >  622        xc_map_foreign_batch(xc_handle, dom, PROT_READ,
> >  623                             p2m_frame_list_list,
> >  624                             P2M_FLL_ENTRIES);
> >
> > memcpy(p2m_frame_list, live_p2m_frame_list, P2M_GUEST_FL_SIZE);
> >
> >  654    p2m =3D xc_map_foreign_batch(xc_handle, dom, PROT_READ,
> >  655                               p2m_frame_list,
> >  656                               P2M_FL_ENTRIES);
> >
> >
> > maybe someone encountered the same problem, would you help me?
>
> What's the problem?
>
> > Besides, what's the difference between IOCTL_PRIVCMD_MMAP and
> > IOCTL_PRIVCMD_MMAPBATCH?
>
> IOCTL_PRIVCMD_MMAP will only map a single page; MMAPBATCH will map an
> array of pages.
>
> (To "batch" something in computing means to do a bunch of things all
> together rather than doing them separately; e.g., rather than mapping
> each page with a separate ioctl, you "batch" them all together in one
> ioctl.)
>
>  -George
>
Thanks, yours makes me clear and confident.

--047d7b33dc5ca2c42304cb82cfab
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Mon, Oct 1, 2012 at 10:17 PM, George =
Dunlap <George.Dunlap@eu.citrix.com> wrote:


On Sat, Sep 29, 2012 at 4:07 AM, =
=E9=A9=AC=E7=A3=8A <aware.why@gma=
il.com> wrote:

> Hi=EF=BC=8C all

> =C2=A0In tools/libxc/xc_domain_save .c, one function called

> `map_and_save_p2m_table` where there exists a confusing problem, as is=
 shown

> below:

>

> =C2=A0621 =C2=A0 =C2=A0live_p2m_frame_list =3D

> =C2=A0622 =C2=A0 =C2=A0 =C2=A0 =C2=A0xc_map_foreign_batch(xc_handle, d=
om, PROT_READ,

> =C2=A0623 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 p2m_frame_list_list,

> =C2=A0624 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 P2M_FLL_ENTRIES);

>

> memcpy(p2m_frame_list, live_p2m_frame_list, P2M_GUEST_FL_SIZE);

>

> =C2=A0654 =C2=A0 =C2=A0p2m =3D xc_map_foreign_batch(xc_handle, dom, PR=
OT_READ,

> =C2=A0655 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 p2m_frame_list,

> =C2=A0656 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 P2M_FL_ENTRIES);

>

>

> maybe someone encountered the same problem, would you help me?




What's the problem?




> Besides, what's the difference between IOCTL_PRIVCMD_MMAP and

> IOCTL_PRIVCMD_MMAPBATCH?




IOCTL_PRIVCMD_MMAP will only map a single page; MMAPBATCH will map an=


array of pages.



(To "batch" something in computing means to do a bunch of things =
all

together rather than doing them separately; e.g., rather than mapping

each page with a separate ioctl, you "batch" them all together in=
 one

ioctl.)



=C2=A0-George


Thanks, yours makes me clear and confident=
.

--047d7b33dc5ca2c42304cb82cfab--


--===============6912409168489172128==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6912409168489172128==--


From xen-devel-bounces@lists.xen.org Mon Oct 08 02:17:21 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 02:17:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TL2th-0001uc-N4; Mon, 08 Oct 2012 02:16:45 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TL2tf-0001uX-OW
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 02:16:43 +0000
X-Env-Sender: aware.why@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1349662596!3994388!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23225 invoked from network); 8 Oct 2012 02:16:37 -0000
Received: from mail-ea0-f171.google.com (HELO mail-ea0-f171.google.com)
	(209.85.215.171)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 02:16:37 -0000
Received: by mail-ea0-f171.google.com with SMTP id k14so115377eaa.30
	for ;
	Sun, 07 Oct 2012 19:16:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=PAn8bmgk04YsSwRxV1KAlokZhzok3SZS06sqN7q3Xx8=;
	b=oisVKal4Xu0k3EFrOLMwHHL+TwN5L56VXumryRkFySRuIzxgKFGROjLEAPlksd59B9
	4D1WmOBJMIERujfEk9eX6bGShftf1kC1sDWkRrk8JfIOtJBj2AXzW2k8DsiNX0181Ca3
	lbv5fl6p3XY6jGhUnVcOdLUM6uxVterGtVX3ilYzZMj0owXLvDZ1rzuY0BQDxDWfYM4P
	FEJaMBaxdtc33dk2Oj/LArO77jqinf8MZJAdM1C21LvYO/BAiuASH3CPYX6uQ7xoDCXZ
	8+iooJg6fC4MzaZUKJY8wCYMwed6S+7Em04U2kBOo2ChcrmhLnnNtOJ0XLkCV1DhrcAS
	FQEA==
MIME-Version: 1.0
Received: by 10.14.194.136 with SMTP id m8mr20463768een.10.1349662596580; Sun,
	07 Oct 2012 19:16:36 -0700 (PDT)
Received: by 10.14.100.71 with HTTP; Sun, 7 Oct 2012 19:16:36 -0700 (PDT)
In-Reply-To: 
References: 
	
Date: Mon, 8 Oct 2012 10:16:36 +0800
Message-ID: 
From: =?UTF-8?B?6ams56OK?= 
To: George Dunlap 
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] =?utf-8?b?44CQY29uZnVzZWTjgJF3aGF0IGRvZXMgeGNfbWFw?=
	=?utf-8?b?X2ZvcmVpZ25fYmF0Y2ggZG/vvJ8=?=
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============6912409168489172128=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6912409168489172128==
Content-Type: multipart/alternative; boundary=047d7b33dc5ca2c42304cb82cfab

--047d7b33dc5ca2c42304cb82cfab
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Oct 1, 2012 at 10:17 PM, George Dunlap
wrote:

> On Sat, Sep 29, 2012 at 4:07 AM, =E9=A9=AC=E7=A3=8A =
 wrote:
> > Hi=EF=BC=8C all
> >  In tools/libxc/xc_domain_save .c, one function called
> > `map_and_save_p2m_table` where there exists a confusing problem, as is
> shown
> > below:
> >
> >  621    live_p2m_frame_list =3D
> >  622        xc_map_foreign_batch(xc_handle, dom, PROT_READ,
> >  623                             p2m_frame_list_list,
> >  624                             P2M_FLL_ENTRIES);
> >
> > memcpy(p2m_frame_list, live_p2m_frame_list, P2M_GUEST_FL_SIZE);
> >
> >  654    p2m =3D xc_map_foreign_batch(xc_handle, dom, PROT_READ,
> >  655                               p2m_frame_list,
> >  656                               P2M_FL_ENTRIES);
> >
> >
> > maybe someone encountered the same problem, would you help me?
>
> What's the problem?
>
> > Besides, what's the difference between IOCTL_PRIVCMD_MMAP and
> > IOCTL_PRIVCMD_MMAPBATCH?
>
> IOCTL_PRIVCMD_MMAP will only map a single page; MMAPBATCH will map an
> array of pages.
>
> (To "batch" something in computing means to do a bunch of things all
> together rather than doing them separately; e.g., rather than mapping
> each page with a separate ioctl, you "batch" them all together in one
> ioctl.)
>
>  -George
>
Thanks, yours makes me clear and confident.

--047d7b33dc5ca2c42304cb82cfab
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Mon, Oct 1, 2012 at 10:17 PM, George =
Dunlap <George.Dunlap@eu.citrix.com> wrote:


On Sat, Sep 29, 2012 at 4:07 AM, =
=E9=A9=AC=E7=A3=8A <aware.why@gma=
il.com> wrote:

> Hi=EF=BC=8C all

> =C2=A0In tools/libxc/xc_domain_save .c, one function called

> `map_and_save_p2m_table` where there exists a confusing problem, as is=
 shown

> below:

>

> =C2=A0621 =C2=A0 =C2=A0live_p2m_frame_list =3D

> =C2=A0622 =C2=A0 =C2=A0 =C2=A0 =C2=A0xc_map_foreign_batch(xc_handle, d=
om, PROT_READ,

> =C2=A0623 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 p2m_frame_list_list,

> =C2=A0624 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 P2M_FLL_ENTRIES);

>

> memcpy(p2m_frame_list, live_p2m_frame_list, P2M_GUEST_FL_SIZE);

>

> =C2=A0654 =C2=A0 =C2=A0p2m =3D xc_map_foreign_batch(xc_handle, dom, PR=
OT_READ,

> =C2=A0655 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 p2m_frame_list,

> =C2=A0656 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 P2M_FL_ENTRIES);

>

>

> maybe someone encountered the same problem, would you help me?




What's the problem?




> Besides, what's the difference between IOCTL_PRIVCMD_MMAP and

> IOCTL_PRIVCMD_MMAPBATCH?




IOCTL_PRIVCMD_MMAP will only map a single page; MMAPBATCH will map an=


array of pages.



(To "batch" something in computing means to do a bunch of things =
all

together rather than doing them separately; e.g., rather than mapping

each page with a separate ioctl, you "batch" them all together in=
 one

ioctl.)



=C2=A0-George


Thanks, yours makes me clear and confident=
.

--047d7b33dc5ca2c42304cb82cfab--


--===============6912409168489172128==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6912409168489172128==--


From xen-devel-bounces@lists.xen.org Mon Oct 08 04:53:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 04:53:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TL5KW-0002yK-4I; Mon, 08 Oct 2012 04:52:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TL5KU-0002yF-Qh
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 04:52:35 +0000
Received: from [85.158.143.35:3738] by server-2.bemta-4.messagelabs.com id
	18/59-06610-21C52705; Mon, 08 Oct 2012 04:52:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1349671953!5674859!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMzOTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23613 invoked from network); 8 Oct 2012 04:52:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 04:52:33 -0000
X-IronPort-AV: E=Sophos;i="4.80,549,1344211200"; d="scan'208";a="14989130"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 04:52:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Mon, 8 Oct 2012 05:52:32 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TL5KP-0004kf-Fu;
	Mon, 08 Oct 2012 04:52:31 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TL5KK-0001Ze-5y;
	Mon, 08 Oct 2012 05:52:27 +0100
To: 
Message-ID: 
From: xen.org 
Date: Mon, 8 Oct 2012 05:52:24 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13931: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13931 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13931/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-winxpsp3-vcpus1 12 guest-localmigrate/x10 fail pass in 13930

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13930
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13930
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13930
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13930

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 13930 never pass

version targeted for testing:
 xen                  3eb9a891889a
baseline version:
 xen                  3eb9a891889a

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 04:53:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 04:53:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TL5KW-0002yK-4I; Mon, 08 Oct 2012 04:52:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TL5KU-0002yF-Qh
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 04:52:35 +0000
Received: from [85.158.143.35:3738] by server-2.bemta-4.messagelabs.com id
	18/59-06610-21C52705; Mon, 08 Oct 2012 04:52:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1349671953!5674859!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMzOTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23613 invoked from network); 8 Oct 2012 04:52:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 04:52:33 -0000
X-IronPort-AV: E=Sophos;i="4.80,549,1344211200"; d="scan'208";a="14989130"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 04:52:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Mon, 8 Oct 2012 05:52:32 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TL5KP-0004kf-Fu;
	Mon, 08 Oct 2012 04:52:31 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TL5KK-0001Ze-5y;
	Mon, 08 Oct 2012 05:52:27 +0100
To: 
Message-ID: 
From: xen.org 
Date: Mon, 8 Oct 2012 05:52:24 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13931: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13931 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13931/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-winxpsp3-vcpus1 12 guest-localmigrate/x10 fail pass in 13930

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13930
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13930
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13930
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13930

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 13930 never pass

version targeted for testing:
 xen                  3eb9a891889a
baseline version:
 xen                  3eb9a891889a

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 08:05:40 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 08:05:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TL8Ko-0004V5-8B; Mon, 08 Oct 2012 08:05:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TL8Kk-0004V0-I6
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 08:05:02 +0000
Received: from [85.158.138.51:35101] by server-7.bemta-3.messagelabs.com id
	88/6D-15765-D2982705; Mon, 08 Oct 2012 08:05:01 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-7.tower-174.messagelabs.com!1349683501!24590194!1
X-Originating-IP: [192.134.164.82]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25093 invoked from network); 8 Oct 2012 08:05:01 -0000
Received: from mail1-relais-roc.national.inria.fr (HELO
	mail1-relais-roc.national.inria.fr) (192.134.164.82)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 08:05:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,551,1344204000"; d="scan'208";a="176214505"
Received: from unknown (HELO type.ipv6) ([193.50.110.124])
	by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA;
	08 Oct 2012 10:05:00 +0200
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from )
	id 1TL8Ki-0002Mw-EL; Mon, 08 Oct 2012 10:05:00 +0200
Date: Mon, 8 Oct 2012 10:05:00 +0200
From: Samuel Thibault 
To: Matthew Fioravante 
Message-ID: <20121008080500.GA5985@type.bordeaux.inria.fr>
Mail-Followup-To: Samuel Thibault ,
	Matthew Fioravante ,
	"xen-devel@lists.xensource.com" 
References: <50579C5F.5040004@jhuapl.edu>
	<20120917224619.GO5110@type.youpi.perso.aquilenet.fr>
	<506F209E.2040902@jhuapl.edu>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <506F209E.2040902@jhuapl.edu>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 2/8] add posix
 io to blkfront
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Matthew Fioravante, le Fri 05 Oct 2012 14:02:06 -0400, a =E9crit :
> See latest v2 patch

It looks good, except why BLKIF_MAX_SEGMENTS_PER_REQUEST-1 and not
BLKIF_MAX_SEGMENTS_PER_REQUEST?

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 08:05:40 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 08:05:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TL8Ko-0004V5-8B; Mon, 08 Oct 2012 08:05:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TL8Kk-0004V0-I6
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 08:05:02 +0000
Received: from [85.158.138.51:35101] by server-7.bemta-3.messagelabs.com id
	88/6D-15765-D2982705; Mon, 08 Oct 2012 08:05:01 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-7.tower-174.messagelabs.com!1349683501!24590194!1
X-Originating-IP: [192.134.164.82]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25093 invoked from network); 8 Oct 2012 08:05:01 -0000
Received: from mail1-relais-roc.national.inria.fr (HELO
	mail1-relais-roc.national.inria.fr) (192.134.164.82)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 08:05:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,551,1344204000"; d="scan'208";a="176214505"
Received: from unknown (HELO type.ipv6) ([193.50.110.124])
	by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA;
	08 Oct 2012 10:05:00 +0200
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from )
	id 1TL8Ki-0002Mw-EL; Mon, 08 Oct 2012 10:05:00 +0200
Date: Mon, 8 Oct 2012 10:05:00 +0200
From: Samuel Thibault 
To: Matthew Fioravante 
Message-ID: <20121008080500.GA5985@type.bordeaux.inria.fr>
Mail-Followup-To: Samuel Thibault ,
	Matthew Fioravante ,
	"xen-devel@lists.xensource.com" 
References: <50579C5F.5040004@jhuapl.edu>
	<20120917224619.GO5110@type.youpi.perso.aquilenet.fr>
	<506F209E.2040902@jhuapl.edu>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <506F209E.2040902@jhuapl.edu>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 2/8] add posix
 io to blkfront
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Matthew Fioravante, le Fri 05 Oct 2012 14:02:06 -0400, a =E9crit :
> See latest v2 patch

It looks good, except why BLKIF_MAX_SEGMENTS_PER_REQUEST-1 and not
BLKIF_MAX_SEGMENTS_PER_REQUEST?

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 08:55:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 08:55:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TL96Y-0004jF-62; Mon, 08 Oct 2012 08:54:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TL96X-0004jA-Gr
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 08:54:25 +0000
Received: from [85.158.137.99:62278] by server-11.bemta-3.messagelabs.com id
	68/3F-21460-0C492705; Mon, 08 Oct 2012 08:54:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1349686463!19460135!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMzNDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8379 invoked from network); 8 Oct 2012 08:54:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 08:54:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,551,1344211200"; d="scan'208";a="14994548"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 08:54:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 8 Oct 2012
	09:54:23 +0100
Message-ID: <1349686461.18008.18.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Mon, 8 Oct 2012 09:54:21 +0100
In-Reply-To: <20121007233444.GA26929@localhost.localdomain>
References: 
	<729626082.20121006002054@eikelenboom.it>
	<20121007233444.GA26929@localhost.localdomain>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Sander Eikelenboom ,
	"xen-devel@lists.xensource.com" ,
	konrad 
Subject: Re: [Xen-devel] Kernel 3.7.0-pre-rc1 kernel BUG at
 drivers/net/xen-netback/netback.c:405 RIP: e030:[]
 [] netbk_gop_frag_copy+0x379/0x380
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-10-08 at 00:34 +0100, Konrad Rzeszutek Wilk wrote:
> On Sat, Oct 06, 2012 at 12:20:54AM +0200, Sander Eikelenboom wrote:
> > 
> > Friday, October 5, 2012, 9:26:31 PM, you wrote:
> > 
> > > Sorry for top posting - on mobile.
> > 
> > > I saw it too yesterday but only on a specific hardware - AMD FX8. What type of CPU do you have?  Does xsave=off on Xen line help?
> > 
> > Nope the xsave=off doesn't help
> > 
> > > Sander Eikelenboom  wrote:
> > 
> > >>Hi Konrad,
> > >>
> > >>Just tested kernel 3.7.0-pre-rc1 but ran into a oops in netback on boot after starting some guests:
> > >>
> > >>[  402.723915] ------------[ cut here ]------------
> > >>[  402.734629] kernel BUG at drivers/net/xen-netback/netback.c:405!
> 
> Looking at the code, this is what we get:
> 
>         /* Data must not cross a page boundary. */
>         BUG_ON(size + offset > PAGE_SIZE);
> 
> Looking at the commits, the one recently added was:
> commit c571898ffc24a1768e1b2dabeac0fc7dd4c14601
> Author: Andres Lagar-Cavilla 
> Date:   Fri Sep 14 14:26:59 2012 +0000
> 
>     xen/gndev: Xen backend support for paged out grant targets V4.
>     
> 
> But after reverting it and trying the kernel I still got the crash.
> 
> So .. the weirdness is that this seems to be only happening on
> certain AMD machines - for example on my AMD A8 box I did not see this.

I took a look at this last week and can't repro.

The code which calls this function is supposed to ensure that the buffer
doesn't cross a page boundary.

There are two places which call it, one is looping over the skb's frags,
which just can't cross page boundaries and if they did it would be
breaking left and right for everyone AFAICT (although I'm very behind on
my LKML and netdev reading, so maybe it is ;-)).

The other case is processing the SKB's linear data area, which can cross
a page boundary but the code loops over it and processes it in chunks
which fit in single pages. I was suspicious of this code so I pulled it
out into a little userspace test harness and fed it some corner cases
but it looked like it was doing the right thing.

I speculated that this might be NIC rather than processor related
(perhaps there's some weak correlation between certain NICs and certain
processor manufacturers).

Konrad seems to have an r8169 but the module list wasn't in Sander's
output -- do you know what you have?

> I fear that the next step is to do a bit off git bisection to
> get an idea of which merge it might be. I am going to be AFK
> on Monday so I won't get to this until Tuesday/Wednesay :-(
> 
> .. Thought to help speed this process, this looks like a
> candidate:
> 
> commit 229993001282e128a49a59ec43d255614775703a
> Merge: 7687b80 fd0f586
> Author: Linus Torvalds 
> Date:   Mon Oct 1 11:13:33 2012 -0700
> 
>     Merge branch 'x86-mm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
>     
>     Pull x86/mm changes from Ingo Molnar:
>      "The biggest change is new TLB partial flushing code for AMD CPUs.
>       (The v3.6 kernel had the Intel CPU side code, see commits
>       e0ba94f14f74..effee4b9b3b.)

Would be interesting to try although I don't think anything in this area
is actively messing with page table mappings (that happens later, and
doesn't effect the non-data bits of the skb like the sizes and offsets).

Perhaps this debug patch might shed some light? PG_compound or THP might
be an interesting case?

Ian.

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 05593d8..ca4c47d 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -386,7 +386,7 @@ static struct netbk_rx_meta *get_next_rx_buffer(struct xenvif *vif,
  * Set up the grant operations for this fragment. If it's a flipping
  * interface, we also set up the unmap request from here.
  */
-static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
+static int netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 				struct netrx_pending_operations *npo,
 				struct page *page, unsigned long size,
 				unsigned long offset, int *head)
@@ -402,7 +402,8 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 	unsigned long bytes;
 
 	/* Data must not cross a page boundary. */
-	BUG_ON(size + offset > PAGE_SIZE);
+	if (size + offset > PAGE_SIZE)
+		return -1;
 
 	meta = npo->meta + npo->meta_prod - 1;
 
@@ -459,6 +460,7 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 		*head = 0; /* There must be something in this buffer now. */
 
 	}
+	return 0;
 }
 
 /*
@@ -517,17 +519,31 @@ static int netbk_gop_skb(struct sk_buff *skb,
 		if (data + len > skb_tail_pointer(skb))
 			len = skb_tail_pointer(skb) - data;
 
-		netbk_gop_frag_copy(vif, skb, npo,
-				    virt_to_page(data), len, offset, &head);
+		if (netbk_gop_frag_copy(vif, skb, npo,
+				virt_to_page(data), len, offset, &head) < 0) {
+printk(KERN_CRIT "netbk_gop_frag_copy failed: skb head %p-%p\n",
+       skb->data, skb_tail_pointer);
+printk(KERN_CRIT "copying from %p-%p, offset %x, len %x\n",
+       data, data+len, offset, len);
+dump_page(virt_to_page(data));
+BUG();
+		}
 		data += len;
 	}
 
 	for (i = 0; i < nr_frags; i++) {
-		netbk_gop_frag_copy(vif, skb, npo,
+		if (netbk_gop_frag_copy(vif, skb, npo,
 				    skb_frag_page(&skb_shinfo(skb)->frags[i]),
 				    skb_frag_size(&skb_shinfo(skb)->frags[i]),
 				    skb_shinfo(skb)->frags[i].page_offset,
-				    &head);
+				    &head) < 0) {
+printk(KERN_CRIT "netbk_gop_frag_copy failed: skb frag %d page\n", i);
+printk(KERN_CRIT "copying from offset %x, len %x\n",
+       skb_shinfo(skb)->frags[i].page_offset,
+       skb_frag_size(&skb_shinfo(skb)->frags[i]));
+dump_page(skb_frag_page(&skb_shinfo(skb)->frags[i]));
+BUG();
+		}
 	}
 
 	return npo->meta_prod - old_meta_prod;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 08:55:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 08:55:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TL96Y-0004jF-62; Mon, 08 Oct 2012 08:54:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TL96X-0004jA-Gr
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 08:54:25 +0000
Received: from [85.158.137.99:62278] by server-11.bemta-3.messagelabs.com id
	68/3F-21460-0C492705; Mon, 08 Oct 2012 08:54:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1349686463!19460135!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMzNDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8379 invoked from network); 8 Oct 2012 08:54:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 08:54:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,551,1344211200"; d="scan'208";a="14994548"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 08:54:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 8 Oct 2012
	09:54:23 +0100
Message-ID: <1349686461.18008.18.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Mon, 8 Oct 2012 09:54:21 +0100
In-Reply-To: <20121007233444.GA26929@localhost.localdomain>
References: 
	<729626082.20121006002054@eikelenboom.it>
	<20121007233444.GA26929@localhost.localdomain>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Sander Eikelenboom ,
	"xen-devel@lists.xensource.com" ,
	konrad 
Subject: Re: [Xen-devel] Kernel 3.7.0-pre-rc1 kernel BUG at
 drivers/net/xen-netback/netback.c:405 RIP: e030:[]
 [] netbk_gop_frag_copy+0x379/0x380
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-10-08 at 00:34 +0100, Konrad Rzeszutek Wilk wrote:
> On Sat, Oct 06, 2012 at 12:20:54AM +0200, Sander Eikelenboom wrote:
> > 
> > Friday, October 5, 2012, 9:26:31 PM, you wrote:
> > 
> > > Sorry for top posting - on mobile.
> > 
> > > I saw it too yesterday but only on a specific hardware - AMD FX8. What type of CPU do you have?  Does xsave=off on Xen line help?
> > 
> > Nope the xsave=off doesn't help
> > 
> > > Sander Eikelenboom  wrote:
> > 
> > >>Hi Konrad,
> > >>
> > >>Just tested kernel 3.7.0-pre-rc1 but ran into a oops in netback on boot after starting some guests:
> > >>
> > >>[  402.723915] ------------[ cut here ]------------
> > >>[  402.734629] kernel BUG at drivers/net/xen-netback/netback.c:405!
> 
> Looking at the code, this is what we get:
> 
>         /* Data must not cross a page boundary. */
>         BUG_ON(size + offset > PAGE_SIZE);
> 
> Looking at the commits, the one recently added was:
> commit c571898ffc24a1768e1b2dabeac0fc7dd4c14601
> Author: Andres Lagar-Cavilla 
> Date:   Fri Sep 14 14:26:59 2012 +0000
> 
>     xen/gndev: Xen backend support for paged out grant targets V4.
>     
> 
> But after reverting it and trying the kernel I still got the crash.
> 
> So .. the weirdness is that this seems to be only happening on
> certain AMD machines - for example on my AMD A8 box I did not see this.

I took a look at this last week and can't repro.

The code which calls this function is supposed to ensure that the buffer
doesn't cross a page boundary.

There are two places which call it, one is looping over the skb's frags,
which just can't cross page boundaries and if they did it would be
breaking left and right for everyone AFAICT (although I'm very behind on
my LKML and netdev reading, so maybe it is ;-)).

The other case is processing the SKB's linear data area, which can cross
a page boundary but the code loops over it and processes it in chunks
which fit in single pages. I was suspicious of this code so I pulled it
out into a little userspace test harness and fed it some corner cases
but it looked like it was doing the right thing.

I speculated that this might be NIC rather than processor related
(perhaps there's some weak correlation between certain NICs and certain
processor manufacturers).

Konrad seems to have an r8169 but the module list wasn't in Sander's
output -- do you know what you have?

> I fear that the next step is to do a bit off git bisection to
> get an idea of which merge it might be. I am going to be AFK
> on Monday so I won't get to this until Tuesday/Wednesay :-(
> 
> .. Thought to help speed this process, this looks like a
> candidate:
> 
> commit 229993001282e128a49a59ec43d255614775703a
> Merge: 7687b80 fd0f586
> Author: Linus Torvalds 
> Date:   Mon Oct 1 11:13:33 2012 -0700
> 
>     Merge branch 'x86-mm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
>     
>     Pull x86/mm changes from Ingo Molnar:
>      "The biggest change is new TLB partial flushing code for AMD CPUs.
>       (The v3.6 kernel had the Intel CPU side code, see commits
>       e0ba94f14f74..effee4b9b3b.)

Would be interesting to try although I don't think anything in this area
is actively messing with page table mappings (that happens later, and
doesn't effect the non-data bits of the skb like the sizes and offsets).

Perhaps this debug patch might shed some light? PG_compound or THP might
be an interesting case?

Ian.

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 05593d8..ca4c47d 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -386,7 +386,7 @@ static struct netbk_rx_meta *get_next_rx_buffer(struct xenvif *vif,
  * Set up the grant operations for this fragment. If it's a flipping
  * interface, we also set up the unmap request from here.
  */
-static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
+static int netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 				struct netrx_pending_operations *npo,
 				struct page *page, unsigned long size,
 				unsigned long offset, int *head)
@@ -402,7 +402,8 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 	unsigned long bytes;
 
 	/* Data must not cross a page boundary. */
-	BUG_ON(size + offset > PAGE_SIZE);
+	if (size + offset > PAGE_SIZE)
+		return -1;
 
 	meta = npo->meta + npo->meta_prod - 1;
 
@@ -459,6 +460,7 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 		*head = 0; /* There must be something in this buffer now. */
 
 	}
+	return 0;
 }
 
 /*
@@ -517,17 +519,31 @@ static int netbk_gop_skb(struct sk_buff *skb,
 		if (data + len > skb_tail_pointer(skb))
 			len = skb_tail_pointer(skb) - data;
 
-		netbk_gop_frag_copy(vif, skb, npo,
-				    virt_to_page(data), len, offset, &head);
+		if (netbk_gop_frag_copy(vif, skb, npo,
+				virt_to_page(data), len, offset, &head) < 0) {
+printk(KERN_CRIT "netbk_gop_frag_copy failed: skb head %p-%p\n",
+       skb->data, skb_tail_pointer);
+printk(KERN_CRIT "copying from %p-%p, offset %x, len %x\n",
+       data, data+len, offset, len);
+dump_page(virt_to_page(data));
+BUG();
+		}
 		data += len;
 	}
 
 	for (i = 0; i < nr_frags; i++) {
-		netbk_gop_frag_copy(vif, skb, npo,
+		if (netbk_gop_frag_copy(vif, skb, npo,
 				    skb_frag_page(&skb_shinfo(skb)->frags[i]),
 				    skb_frag_size(&skb_shinfo(skb)->frags[i]),
 				    skb_shinfo(skb)->frags[i].page_offset,
-				    &head);
+				    &head) < 0) {
+printk(KERN_CRIT "netbk_gop_frag_copy failed: skb frag %d page\n", i);
+printk(KERN_CRIT "copying from offset %x, len %x\n",
+       skb_shinfo(skb)->frags[i].page_offset,
+       skb_frag_size(&skb_shinfo(skb)->frags[i]));
+dump_page(skb_frag_page(&skb_shinfo(skb)->frags[i]));
+BUG();
+		}
 	}
 
 	return npo->meta_prod - old_meta_prod;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 08:59:33 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 08:59:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TL9Aw-0004q2-Rx; Mon, 08 Oct 2012 08:58:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TL9Av-0004px-GA
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 08:58:57 +0000
Received: from [85.158.137.99:56610] by server-7.bemta-3.messagelabs.com id
	10/45-15765-0D592705; Mon, 08 Oct 2012 08:58:56 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-7.tower-217.messagelabs.com!1349686735!15873718!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28316 invoked from network); 8 Oct 2012 08:58:55 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-7.tower-217.messagelabs.com with AES256-SHA encrypted SMTP;
	8 Oct 2012 08:58:55 -0000
Received: from 100-66-ftth.onsneteindhoven.nl ([88.159.66.100]:52052
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TL9C7-0000j3-TE; Mon, 08 Oct 2012 11:00:11 +0200
Date: Mon, 8 Oct 2012 10:58:50 +0200
From: Sander Eikelenboom 
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <3010147558.20121008105850@eikelenboom.it>
To: Ian Campbell 
In-Reply-To: <1349686461.18008.18.camel@zakaz.uk.xensource.com>
References: 
	<729626082.20121006002054@eikelenboom.it>
	<20121007233444.GA26929@localhost.localdomain>
	<1349686461.18008.18.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk ,
	"xen-devel@lists.xensource.com" ,
	konrad 
Subject: Re: [Xen-devel] Kernel 3.7.0-pre-rc1 kernel BUG at
	drivers/net/xen-netback/netback.c:405 RIP:
	e030:[] []
	netbk_gop_frag_copy+0x379/0x380
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Monday, October 8, 2012, 10:54:21 AM, you wrote:

> On Mon, 2012-10-08 at 00:34 +0100, Konrad Rzeszutek Wilk wrote:
>> On Sat, Oct 06, 2012 at 12:20:54AM +0200, Sander Eikelenboom wrote:
>> > 
>> > Friday, October 5, 2012, 9:26:31 PM, you wrote:
>> > 
>> > > Sorry for top posting - on mobile.
>> > 
>> > > I saw it too yesterday but only on a specific hardware - AMD FX8. What type of CPU do you have?  Does xsave=off on Xen line help?
>> > 
>> > Nope the xsave=off doesn't help
>> > 
>> > > Sander Eikelenboom  wrote:
>> > 
>> > >>Hi Konrad,
>> > >>
>> > >>Just tested kernel 3.7.0-pre-rc1 but ran into a oops in netback on boot after starting some guests:
>> > >>
>> > >>[  402.723915] ------------[ cut here ]------------
>> > >>[  402.734629] kernel BUG at drivers/net/xen-netback/netback.c:405!
>> 
>> Looking at the code, this is what we get:
>> 
>>         /* Data must not cross a page boundary. */
>>         BUG_ON(size + offset > PAGE_SIZE);
>> 
>> Looking at the commits, the one recently added was:
>> commit c571898ffc24a1768e1b2dabeac0fc7dd4c14601
>> Author: Andres Lagar-Cavilla 
>> Date:   Fri Sep 14 14:26:59 2012 +0000
>> 
>>     xen/gndev: Xen backend support for paged out grant targets V4.
>>     
>> 
>> But after reverting it and trying the kernel I still got the crash.
>> 
>> So .. the weirdness is that this seems to be only happening on
>> certain AMD machines - for example on my AMD A8 box I did not see this.

> I took a look at this last week and can't repro.

> The code which calls this function is supposed to ensure that the buffer
> doesn't cross a page boundary.

> There are two places which call it, one is looping over the skb's frags,
> which just can't cross page boundaries and if they did it would be
> breaking left and right for everyone AFAICT (although I'm very behind on
> my LKML and netdev reading, so maybe it is ;-)).

> The other case is processing the SKB's linear data area, which can cross
> a page boundary but the code loops over it and processes it in chunks
> which fit in single pages. I was suspicious of this code so I pulled it
> out into a little userspace test harness and fed it some corner cases
> but it looked like it was doing the right thing.

> I speculated that this might be NIC rather than processor related
> (perhaps there's some weak correlation between certain NICs and certain
> processor manufacturers).

> Konrad seems to have an r8169 but the module list wasn't in Sander's
> output -- do you know what you have?

Surprise surprise .. a r8169 as well ..

>> I fear that the next step is to do a bit off git bisection to
>> get an idea of which merge it might be. I am going to be AFK
>> on Monday so I won't get to this until Tuesday/Wednesay :-(
>> 
>> .. Thought to help speed this process, this looks like a
>> candidate:
>> 
>> commit 229993001282e128a49a59ec43d255614775703a
>> Merge: 7687b80 fd0f586
>> Author: Linus Torvalds 
>> Date:   Mon Oct 1 11:13:33 2012 -0700
>> 
>>     Merge branch 'x86-mm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
>>     
>>     Pull x86/mm changes from Ingo Molnar:
>>      "The biggest change is new TLB partial flushing code for AMD CPUs.
>>       (The v3.6 kernel had the Intel CPU side code, see commits
>>       e0ba94f14f74..effee4b9b3b.)

> Would be interesting to try although I don't think anything in this area
> is actively messing with page table mappings (that happens later, and
> doesn't effect the non-data bits of the skb like the sizes and offsets).

> Perhaps this debug patch might shed some light? PG_compound or THP might
> be an interesting case?

> Ian.

> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index 05593d8..ca4c47d 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -386,7 +386,7 @@ static struct netbk_rx_meta *get_next_rx_buffer(struct xenvif *vif,
>   * Set up the grant operations for this fragment. If it's a flipping
>   * interface, we also set up the unmap request from here.
>   */
> -static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
> +static int netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
>                                 struct netrx_pending_operations *npo,
>                                 struct page *page, unsigned long size,
>                                 unsigned long offset, int *head)
> @@ -402,7 +402,8 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
>         unsigned long bytes;
>  
>         /* Data must not cross a page boundary. */
> -       BUG_ON(size + offset > PAGE_SIZE);
> +       if (size + offset > PAGE_SIZE)
> +               return -1;
>  
>         meta = npo->meta + npo->meta_prod - 1;
>  
> @@ -459,6 +460,7 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
>                 *head = 0; /* There must be something in this buffer now. */
>  
>         }
> +       return 0;
>  }
>  
>  /*
> @@ -517,17 +519,31 @@ static int netbk_gop_skb(struct sk_buff *skb,
>                 if (data + len > skb_tail_pointer(skb))
>                         len = skb_tail_pointer(skb) - data;
>  
> -               netbk_gop_frag_copy(vif, skb, npo,
> -                                   virt_to_page(data), len, offset, &head);
> +               if (netbk_gop_frag_copy(vif, skb, npo,
> +                               virt_to_page(data), len, offset, &head) < 0) {
> +printk(KERN_CRIT "netbk_gop_frag_copy failed: skb head %p-%p\n",
+       skb->>data, skb_tail_pointer);
> +printk(KERN_CRIT "copying from %p-%p, offset %x, len %x\n",
> +       data, data+len, offset, len);
> +dump_page(virt_to_page(data));
> +BUG();
> +               }
>                 data += len;
>         }
>  
>         for (i = 0; i < nr_frags; i++) {
> -               netbk_gop_frag_copy(vif, skb, npo,
> +               if (netbk_gop_frag_copy(vif, skb, npo,
>                                     skb_frag_page(&skb_shinfo(skb)->frags[i]),
>                                     skb_frag_size(&skb_shinfo(skb)->frags[i]),
>                                     skb_shinfo(skb)->frags[i].page_offset,
> -                                   &head);
> +                                   &head) < 0) {
> +printk(KERN_CRIT "netbk_gop_frag_copy failed: skb frag %d page\n", i);
> +printk(KERN_CRIT "copying from offset %x, len %x\n",
> +       skb_shinfo(skb)->frags[i].page_offset,
> +       skb_frag_size(&skb_shinfo(skb)->frags[i]));
> +dump_page(skb_frag_page(&skb_shinfo(skb)->frags[i]));
> +BUG();
> +               }
>         }
>  
>         return npo->meta_prod - old_meta_prod;





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 08:59:33 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 08:59:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TL9Aw-0004q2-Rx; Mon, 08 Oct 2012 08:58:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TL9Av-0004px-GA
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 08:58:57 +0000
Received: from [85.158.137.99:56610] by server-7.bemta-3.messagelabs.com id
	10/45-15765-0D592705; Mon, 08 Oct 2012 08:58:56 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-7.tower-217.messagelabs.com!1349686735!15873718!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28316 invoked from network); 8 Oct 2012 08:58:55 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-7.tower-217.messagelabs.com with AES256-SHA encrypted SMTP;
	8 Oct 2012 08:58:55 -0000
Received: from 100-66-ftth.onsneteindhoven.nl ([88.159.66.100]:52052
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TL9C7-0000j3-TE; Mon, 08 Oct 2012 11:00:11 +0200
Date: Mon, 8 Oct 2012 10:58:50 +0200
From: Sander Eikelenboom 
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <3010147558.20121008105850@eikelenboom.it>
To: Ian Campbell 
In-Reply-To: <1349686461.18008.18.camel@zakaz.uk.xensource.com>
References: 
	<729626082.20121006002054@eikelenboom.it>
	<20121007233444.GA26929@localhost.localdomain>
	<1349686461.18008.18.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk ,
	"xen-devel@lists.xensource.com" ,
	konrad 
Subject: Re: [Xen-devel] Kernel 3.7.0-pre-rc1 kernel BUG at
	drivers/net/xen-netback/netback.c:405 RIP:
	e030:[] []
	netbk_gop_frag_copy+0x379/0x380
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Monday, October 8, 2012, 10:54:21 AM, you wrote:

> On Mon, 2012-10-08 at 00:34 +0100, Konrad Rzeszutek Wilk wrote:
>> On Sat, Oct 06, 2012 at 12:20:54AM +0200, Sander Eikelenboom wrote:
>> > 
>> > Friday, October 5, 2012, 9:26:31 PM, you wrote:
>> > 
>> > > Sorry for top posting - on mobile.
>> > 
>> > > I saw it too yesterday but only on a specific hardware - AMD FX8. What type of CPU do you have?  Does xsave=off on Xen line help?
>> > 
>> > Nope the xsave=off doesn't help
>> > 
>> > > Sander Eikelenboom  wrote:
>> > 
>> > >>Hi Konrad,
>> > >>
>> > >>Just tested kernel 3.7.0-pre-rc1 but ran into a oops in netback on boot after starting some guests:
>> > >>
>> > >>[  402.723915] ------------[ cut here ]------------
>> > >>[  402.734629] kernel BUG at drivers/net/xen-netback/netback.c:405!
>> 
>> Looking at the code, this is what we get:
>> 
>>         /* Data must not cross a page boundary. */
>>         BUG_ON(size + offset > PAGE_SIZE);
>> 
>> Looking at the commits, the one recently added was:
>> commit c571898ffc24a1768e1b2dabeac0fc7dd4c14601
>> Author: Andres Lagar-Cavilla 
>> Date:   Fri Sep 14 14:26:59 2012 +0000
>> 
>>     xen/gndev: Xen backend support for paged out grant targets V4.
>>     
>> 
>> But after reverting it and trying the kernel I still got the crash.
>> 
>> So .. the weirdness is that this seems to be only happening on
>> certain AMD machines - for example on my AMD A8 box I did not see this.

> I took a look at this last week and can't repro.

> The code which calls this function is supposed to ensure that the buffer
> doesn't cross a page boundary.

> There are two places which call it, one is looping over the skb's frags,
> which just can't cross page boundaries and if they did it would be
> breaking left and right for everyone AFAICT (although I'm very behind on
> my LKML and netdev reading, so maybe it is ;-)).

> The other case is processing the SKB's linear data area, which can cross
> a page boundary but the code loops over it and processes it in chunks
> which fit in single pages. I was suspicious of this code so I pulled it
> out into a little userspace test harness and fed it some corner cases
> but it looked like it was doing the right thing.

> I speculated that this might be NIC rather than processor related
> (perhaps there's some weak correlation between certain NICs and certain
> processor manufacturers).

> Konrad seems to have an r8169 but the module list wasn't in Sander's
> output -- do you know what you have?

Surprise surprise .. a r8169 as well ..

>> I fear that the next step is to do a bit off git bisection to
>> get an idea of which merge it might be. I am going to be AFK
>> on Monday so I won't get to this until Tuesday/Wednesay :-(
>> 
>> .. Thought to help speed this process, this looks like a
>> candidate:
>> 
>> commit 229993001282e128a49a59ec43d255614775703a
>> Merge: 7687b80 fd0f586
>> Author: Linus Torvalds 
>> Date:   Mon Oct 1 11:13:33 2012 -0700
>> 
>>     Merge branch 'x86-mm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
>>     
>>     Pull x86/mm changes from Ingo Molnar:
>>      "The biggest change is new TLB partial flushing code for AMD CPUs.
>>       (The v3.6 kernel had the Intel CPU side code, see commits
>>       e0ba94f14f74..effee4b9b3b.)

> Would be interesting to try although I don't think anything in this area
> is actively messing with page table mappings (that happens later, and
> doesn't effect the non-data bits of the skb like the sizes and offsets).

> Perhaps this debug patch might shed some light? PG_compound or THP might
> be an interesting case?

> Ian.

> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index 05593d8..ca4c47d 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -386,7 +386,7 @@ static struct netbk_rx_meta *get_next_rx_buffer(struct xenvif *vif,
>   * Set up the grant operations for this fragment. If it's a flipping
>   * interface, we also set up the unmap request from here.
>   */
> -static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
> +static int netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
>                                 struct netrx_pending_operations *npo,
>                                 struct page *page, unsigned long size,
>                                 unsigned long offset, int *head)
> @@ -402,7 +402,8 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
>         unsigned long bytes;
>  
>         /* Data must not cross a page boundary. */
> -       BUG_ON(size + offset > PAGE_SIZE);
> +       if (size + offset > PAGE_SIZE)
> +               return -1;
>  
>         meta = npo->meta + npo->meta_prod - 1;
>  
> @@ -459,6 +460,7 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
>                 *head = 0; /* There must be something in this buffer now. */
>  
>         }
> +       return 0;
>  }
>  
>  /*
> @@ -517,17 +519,31 @@ static int netbk_gop_skb(struct sk_buff *skb,
>                 if (data + len > skb_tail_pointer(skb))
>                         len = skb_tail_pointer(skb) - data;
>  
> -               netbk_gop_frag_copy(vif, skb, npo,
> -                                   virt_to_page(data), len, offset, &head);
> +               if (netbk_gop_frag_copy(vif, skb, npo,
> +                               virt_to_page(data), len, offset, &head) < 0) {
> +printk(KERN_CRIT "netbk_gop_frag_copy failed: skb head %p-%p\n",
+       skb->>data, skb_tail_pointer);
> +printk(KERN_CRIT "copying from %p-%p, offset %x, len %x\n",
> +       data, data+len, offset, len);
> +dump_page(virt_to_page(data));
> +BUG();
> +               }
>                 data += len;
>         }
>  
>         for (i = 0; i < nr_frags; i++) {
> -               netbk_gop_frag_copy(vif, skb, npo,
> +               if (netbk_gop_frag_copy(vif, skb, npo,
>                                     skb_frag_page(&skb_shinfo(skb)->frags[i]),
>                                     skb_frag_size(&skb_shinfo(skb)->frags[i]),
>                                     skb_shinfo(skb)->frags[i].page_offset,
> -                                   &head);
> +                                   &head) < 0) {
> +printk(KERN_CRIT "netbk_gop_frag_copy failed: skb frag %d page\n", i);
> +printk(KERN_CRIT "copying from offset %x, len %x\n",
> +       skb_shinfo(skb)->frags[i].page_offset,
> +       skb_frag_size(&skb_shinfo(skb)->frags[i]));
> +dump_page(skb_frag_page(&skb_shinfo(skb)->frags[i]));
> +BUG();
> +               }
>         }
>  
>         return npo->meta_prod - old_meta_prod;





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 09:22:18 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 09:22:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TL9X1-00058f-4P; Mon, 08 Oct 2012 09:21:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TL9Wz-00058Y-J9
	for Xen-devel@lists.xensource.com; Mon, 08 Oct 2012 09:21:45 +0000
Received: from [85.158.138.51:17426] by server-13.bemta-3.messagelabs.com id
	5A/BF-28885-82B92705; Mon, 08 Oct 2012 09:21:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1349688104!24603008!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMzNDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18276 invoked from network); 8 Oct 2012 09:21:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 09:21:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,551,1344211200"; d="scan'208";a="14995336"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 09:21:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 8 Oct 2012
	10:21:44 +0100
Message-ID: <1349688102.18008.34.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Mukesh Rathor 
Date: Mon, 8 Oct 2012 10:21:42 +0100
In-Reply-To: <20121005142240.340815be@mantra.us.oracle.com>
References: <20120921122123.33489ce1@mantra.us.oracle.com>
	<1349270495.650.144.camel@zakaz.uk.xensource.com>
	<20121003153106.65237f07@mantra.us.oracle.com>
	<1349340642.650.227.camel@zakaz.uk.xensource.com>
	<20121004112048.53767720@mantra.us.oracle.com>
	<1349428878.20946.18.camel@zakaz.uk.xensource.com>
	<20121005142240.340815be@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" ,
	Stefano Stabellini ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH v1 7/8]: PVH privcmd changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-05 at 22:22 +0100, Mukesh Rathor wrote:
> On Fri, 5 Oct 2012 10:21:18 +0100
> Ian Campbell  wrote:
> 
> > On Thu, 2012-10-04 at 19:20 +0100, Mukesh Rathor wrote:
> > > On Thu, 4 Oct 2012 09:50:42 +0100
> > > Ian Campbell  wrote:
> > > 
> > > > 
> > > > Won't that break because on the second call you will pass in the
> > > > freshly allocated pointer and overwrite the exiting (useful) one
> > > > with it?
> > > 
> > > No, for xlate, I just check for NULL. I didn't think it was big 
> > > deal to special case xlate in this case. We got so many if xlate 
> > > cases already thru the code. It leaves the semantics easy to 
> > > understand: NULL == avail. 1 == locked PV. PTR == Locked PVH. I'll
> > > add a comment this time :).
> > 
> > The transition from NULL => Locked PVH still needs to be done
> > atomically and without clobbering any existing non-NULL value,
> > otherwise it doesn't actually protect against multiple mappings like
> > it is supposed to.

> Ok, changed it to, and tested it:
> 
> static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma)
> {
>         if (xen_feature(XENFEAT_auto_translated_physmap)) {
>                 int sz = sizeof(vma->vm_private_data);
>                 return (!__cmpxchg(&vma->vm_private_data, NULL, NULL, sz));

Passing NULL for both old and new values can't be right, can it? Did you
test with something which tries to map twice?

Also using cmpxchg instead of __cmpxchg includes the sizeof bit for you
automatically and IIRC Coding-Style doesn't like () around return
values.

So, I think you want:
	return !cmpxchg(&vma->vm_private_data, NULL, 1);

This will set vma->vm_private_data to 1 iff it is currently NULL and
returns true success iff the old values was NULL (although you might
want to double check my logic on the return value).

As Konrad said though using a symbolic constant for the 1 would be a
good idea.

I'm not sure if the cmpxchg is so expensive to be worth special casing
XENFEAT_auto_translated_physmap. It'd probably be fine to just
unconditionally use cmpxchg even in the other case, I don't think this
this path is so hot that it would matter.

>         }
>         return (xchg(&vma->vm_private_data, (void *)1) == NULL);
> }
> 
> Then in pvh_privcmd_resv_pfns():
> 
>         BUG_ON(vma->vm_private_data);
> 	vma->vm_private_data = pvhp;

With the above this becomes:
        BUG_ON(vma->vm_private_data != 1);
        vma->vm_private_data = pvhp;

I previously thought this assignment was unsafe, but
privcmd_enforce_singleshot_mapping is always called first and ensures
that only one thread ever gets to this part and that v_p_d is always 1
if that happens, so I think it is likely be OK.  A comment to that
effect would be helpful.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 09:22:18 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 09:22:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TL9X1-00058f-4P; Mon, 08 Oct 2012 09:21:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TL9Wz-00058Y-J9
	for Xen-devel@lists.xensource.com; Mon, 08 Oct 2012 09:21:45 +0000
Received: from [85.158.138.51:17426] by server-13.bemta-3.messagelabs.com id
	5A/BF-28885-82B92705; Mon, 08 Oct 2012 09:21:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1349688104!24603008!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMzNDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18276 invoked from network); 8 Oct 2012 09:21:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 09:21:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,551,1344211200"; d="scan'208";a="14995336"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 09:21:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 8 Oct 2012
	10:21:44 +0100
Message-ID: <1349688102.18008.34.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Mukesh Rathor 
Date: Mon, 8 Oct 2012 10:21:42 +0100
In-Reply-To: <20121005142240.340815be@mantra.us.oracle.com>
References: <20120921122123.33489ce1@mantra.us.oracle.com>
	<1349270495.650.144.camel@zakaz.uk.xensource.com>
	<20121003153106.65237f07@mantra.us.oracle.com>
	<1349340642.650.227.camel@zakaz.uk.xensource.com>
	<20121004112048.53767720@mantra.us.oracle.com>
	<1349428878.20946.18.camel@zakaz.uk.xensource.com>
	<20121005142240.340815be@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" ,
	Stefano Stabellini ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH v1 7/8]: PVH privcmd changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-05 at 22:22 +0100, Mukesh Rathor wrote:
> On Fri, 5 Oct 2012 10:21:18 +0100
> Ian Campbell  wrote:
> 
> > On Thu, 2012-10-04 at 19:20 +0100, Mukesh Rathor wrote:
> > > On Thu, 4 Oct 2012 09:50:42 +0100
> > > Ian Campbell  wrote:
> > > 
> > > > 
> > > > Won't that break because on the second call you will pass in the
> > > > freshly allocated pointer and overwrite the exiting (useful) one
> > > > with it?
> > > 
> > > No, for xlate, I just check for NULL. I didn't think it was big 
> > > deal to special case xlate in this case. We got so many if xlate 
> > > cases already thru the code. It leaves the semantics easy to 
> > > understand: NULL == avail. 1 == locked PV. PTR == Locked PVH. I'll
> > > add a comment this time :).
> > 
> > The transition from NULL => Locked PVH still needs to be done
> > atomically and without clobbering any existing non-NULL value,
> > otherwise it doesn't actually protect against multiple mappings like
> > it is supposed to.

> Ok, changed it to, and tested it:
> 
> static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma)
> {
>         if (xen_feature(XENFEAT_auto_translated_physmap)) {
>                 int sz = sizeof(vma->vm_private_data);
>                 return (!__cmpxchg(&vma->vm_private_data, NULL, NULL, sz));

Passing NULL for both old and new values can't be right, can it? Did you
test with something which tries to map twice?

Also using cmpxchg instead of __cmpxchg includes the sizeof bit for you
automatically and IIRC Coding-Style doesn't like () around return
values.

So, I think you want:
	return !cmpxchg(&vma->vm_private_data, NULL, 1);

This will set vma->vm_private_data to 1 iff it is currently NULL and
returns true success iff the old values was NULL (although you might
want to double check my logic on the return value).

As Konrad said though using a symbolic constant for the 1 would be a
good idea.

I'm not sure if the cmpxchg is so expensive to be worth special casing
XENFEAT_auto_translated_physmap. It'd probably be fine to just
unconditionally use cmpxchg even in the other case, I don't think this
this path is so hot that it would matter.

>         }
>         return (xchg(&vma->vm_private_data, (void *)1) == NULL);
> }
> 
> Then in pvh_privcmd_resv_pfns():
> 
>         BUG_ON(vma->vm_private_data);
> 	vma->vm_private_data = pvhp;

With the above this becomes:
        BUG_ON(vma->vm_private_data != 1);
        vma->vm_private_data = pvhp;

I previously thought this assignment was unsafe, but
privcmd_enforce_singleshot_mapping is always called first and ensures
that only one thread ever gets to this part and that v_p_d is always 1
if that happens, so I think it is likely be OK.  A comment to that
effect would be helpful.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 09:32:38 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 09:32:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TL9gk-0005Jx-GX; Mon, 08 Oct 2012 09:31:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TL9gj-0005Js-0s
	for Xen-devel@lists.xensource.com; Mon, 08 Oct 2012 09:31:49 +0000
Received: from [85.158.139.211:61228] by server-9.bemta-5.messagelabs.com id
	A2/71-14846-48D92705; Mon, 08 Oct 2012 09:31:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1349688707!21487793!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMzNDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7820 invoked from network); 8 Oct 2012 09:31:47 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 09:31:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,551,1344211200"; d="scan'208";a="14995616"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 09:31:15 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 8 Oct 2012
	10:31:15 +0100
Message-ID: <1349688674.18008.40.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Mukesh Rathor 
Date: Mon, 8 Oct 2012 10:31:14 +0100
In-Reply-To: <20121005190011.2653bcfa@mantra.us.oracle.com>
References: <20120921121556.1a0ea8af@mantra.us.oracle.com>
	<1349278963.650.164.camel@zakaz.uk.xensource.com>
	<20121003152925.5af3a658@mantra.us.oracle.com>
	<1349339279.650.214.camel@zakaz.uk.xensource.com>
	<20121005190011.2653bcfa@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" ,
	Stefano Stabellini ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 2012-10-06 at 03:00 +0100, Mukesh Rathor wrote:
> On Thu, 4 Oct 2012 09:27:59 +0100
> Ian Campbell  wrote:
> 
> > On Wed, 2012-10-03 at 23:29 +0100, Mukesh Rathor wrote:
> > > On Wed, 3 Oct 2012 16:42:43 +0100
> > > Ian Campbell  wrote:
> > >
> > While implementing the ARM version of this interface it occurred to me
> > that the num_pgs and next_todo fields here are not really needed
> > across the arch interface e.g. you already get pi_num_pgs from the nr
> > argument to xen_remap_domain_mfn_range and pi_next_todo is really
> > state which fits in struct pvh_remap_data. That would mean that
> > remap_foo could take a struct page * directly and I think you would
> > save an allocation.
> 
> Ok, take a look at the attached and inlined diffs. I redid it, passing
> struct page to the api, and getting rid of the pi_* struct completely.

Excellent, thanks.

> @@ -260,14 +266,20 @@ struct mmap_batch_state {
>         xen_pfn_t __user *user_mfn;
>  };
> 
> +/* PVH dom0 fyi: if domU being created is PV, then mfn is mfn(addr on bus). If
> + * it's PVH then mfn is pfn (input to HAP). */

Can we say XENFEAT_auto_translated_physmap (or some abbrev.) instead of
PVH here, since this is generic code.

>  static int mmap_batch_fn(void *data, void *state)
>  {
>         xen_pfn_t *mfnp = data;
>         struct mmap_batch_state *st = state;
> +       struct vm_area_struct *vma = st->vma;
> +       struct page **pages = vma ? vma->vm_private_data : NULL;
> +       struct page *cur_page = pages[st->index++];
>         int ret;
> 
>         ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
> -                                        st->vma->vm_page_prot, st->domain);
> +                                        st->vma->vm_page_prot, st->domain,
> +                                        &cur_page);
> 
>         /* Store error code for second pass. */
>         *(st->err++) = ret;
[...]
> @@ -370,10 +408,17 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
>                 up_write(&mm->mmap_sem);
>                 goto out;
>         }
> +       if (xen_feature(XENFEAT_auto_translated_physmap)) {
> +               if ((ret = pvh_privcmd_resv_pfns(vma, m.num)) < 0) {

I renamed this alloc_empty_pages to avoid the PVH terminology in common
code.

There could be an argument for moving this to next to
alloc_xenballooned_pages e.g. as alloc_xenballooned_pagearray. We used
to have alloc_empty_pages_and_pagevec() In the classic kernels which was
effectively that same function.


Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 09:32:38 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 09:32:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TL9gk-0005Jx-GX; Mon, 08 Oct 2012 09:31:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TL9gj-0005Js-0s
	for Xen-devel@lists.xensource.com; Mon, 08 Oct 2012 09:31:49 +0000
Received: from [85.158.139.211:61228] by server-9.bemta-5.messagelabs.com id
	A2/71-14846-48D92705; Mon, 08 Oct 2012 09:31:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1349688707!21487793!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMzNDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7820 invoked from network); 8 Oct 2012 09:31:47 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 09:31:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,551,1344211200"; d="scan'208";a="14995616"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 09:31:15 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 8 Oct 2012
	10:31:15 +0100
Message-ID: <1349688674.18008.40.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Mukesh Rathor 
Date: Mon, 8 Oct 2012 10:31:14 +0100
In-Reply-To: <20121005190011.2653bcfa@mantra.us.oracle.com>
References: <20120921121556.1a0ea8af@mantra.us.oracle.com>
	<1349278963.650.164.camel@zakaz.uk.xensource.com>
	<20121003152925.5af3a658@mantra.us.oracle.com>
	<1349339279.650.214.camel@zakaz.uk.xensource.com>
	<20121005190011.2653bcfa@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" ,
	Stefano Stabellini ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 2012-10-06 at 03:00 +0100, Mukesh Rathor wrote:
> On Thu, 4 Oct 2012 09:27:59 +0100
> Ian Campbell  wrote:
> 
> > On Wed, 2012-10-03 at 23:29 +0100, Mukesh Rathor wrote:
> > > On Wed, 3 Oct 2012 16:42:43 +0100
> > > Ian Campbell  wrote:
> > >
> > While implementing the ARM version of this interface it occurred to me
> > that the num_pgs and next_todo fields here are not really needed
> > across the arch interface e.g. you already get pi_num_pgs from the nr
> > argument to xen_remap_domain_mfn_range and pi_next_todo is really
> > state which fits in struct pvh_remap_data. That would mean that
> > remap_foo could take a struct page * directly and I think you would
> > save an allocation.
> 
> Ok, take a look at the attached and inlined diffs. I redid it, passing
> struct page to the api, and getting rid of the pi_* struct completely.

Excellent, thanks.

> @@ -260,14 +266,20 @@ struct mmap_batch_state {
>         xen_pfn_t __user *user_mfn;
>  };
> 
> +/* PVH dom0 fyi: if domU being created is PV, then mfn is mfn(addr on bus). If
> + * it's PVH then mfn is pfn (input to HAP). */

Can we say XENFEAT_auto_translated_physmap (or some abbrev.) instead of
PVH here, since this is generic code.

>  static int mmap_batch_fn(void *data, void *state)
>  {
>         xen_pfn_t *mfnp = data;
>         struct mmap_batch_state *st = state;
> +       struct vm_area_struct *vma = st->vma;
> +       struct page **pages = vma ? vma->vm_private_data : NULL;
> +       struct page *cur_page = pages[st->index++];
>         int ret;
> 
>         ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
> -                                        st->vma->vm_page_prot, st->domain);
> +                                        st->vma->vm_page_prot, st->domain,
> +                                        &cur_page);
> 
>         /* Store error code for second pass. */
>         *(st->err++) = ret;
[...]
> @@ -370,10 +408,17 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
>                 up_write(&mm->mmap_sem);
>                 goto out;
>         }
> +       if (xen_feature(XENFEAT_auto_translated_physmap)) {
> +               if ((ret = pvh_privcmd_resv_pfns(vma, m.num)) < 0) {

I renamed this alloc_empty_pages to avoid the PVH terminology in common
code.

There could be an argument for moving this to next to
alloc_xenballooned_pages e.g. as alloc_xenballooned_pagearray. We used
to have alloc_empty_pages_and_pagevec() In the classic kernels which was
effectively that same function.


Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 10:25:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 10:25:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLAW2-0005xj-Ir; Mon, 08 Oct 2012 10:24:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLAW0-0005xc-Bi
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 10:24:48 +0000
Received: from [85.158.138.51:52433] by server-3.bemta-3.messagelabs.com id
	60/5E-25962-FE9A2705; Mon, 08 Oct 2012 10:24:47 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1349691885!33410893!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16417 invoked from network); 8 Oct 2012 10:24:46 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 10:24:46 -0000
Received: by mail-vc0-f173.google.com with SMTP id fl15so5205735vcb.32
	for ; Mon, 08 Oct 2012 03:24:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=2X1DFRU9NyhXEE3zDKnjFREPMApwWEddrFK7erYMKoI=;
	b=evdck5fWqfpFCkgD/4uGZWS5i6JG0JQF/zrYjT9gu1AsJ+dJY9N1bnIvSy1Po/DaqL
	M+hcyCQU//Zs7KrjYjiBJ9O9gFm8x6xjyjE+XsP0EfIaGLRDMXcgiY7eXZb/vTzST0Zk
	Ht9xPuF6Su/y3NF9p6xttj8WY8XB9JPTX2Ovo0o+iUfKNmrf04gRV5du7fveU01PX9Z9
	2TbrkTC+l8B40LUd2WvnCu82iwtAEvtS8D2sEO2Qe6iJVcMQkitcrt2WNK8XoqacdHC/
	a+pNMi4yJVVQjgqygAO/aUSVBrXNIDgqYdjdAK9xZoBaeaFUw3Derc3BoiJhboZIQuai
	ePxQ==
Received: by 10.52.96.10 with SMTP id do10mr7753086vdb.91.1349691885338; Mon,
	08 Oct 2012 03:24:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.58.234.5 with HTTP; Mon, 8 Oct 2012 03:24:25 -0700 (PDT)
In-Reply-To: <506EBF67020000780009FD94@nat28.tlf.novell.com>
References: <1348141322-28657-1-git-send-email-jean.guyader@citrix.com>
	<1348141322-28657-5-git-send-email-jean.guyader@citrix.com>
	<505B2636020000780009CAA6@nat28.tlf.novell.com>
	
	<506D98FE020000780009FA23@nat28.tlf.novell.com>
	
	<20121004151214.GG38243@ocelot.phlegethon.org>
	
	<506EBBD7020000780009FD84@nat28.tlf.novell.com>
	<506EBF67020000780009FD94@nat28.tlf.novell.com>
From: Jean Guyader 
Date: Mon, 8 Oct 2012 11:24:25 +0100
Message-ID: 
To: Jan Beulich 
Cc: Tim Deegan , Jean Guyader ,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 4/4] xen: Add V4V implementation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 5 October 2012 10:07, Jan Beulich  wrote:
>>>> On 05.10.12 at 10:52, "Jan Beulich"  wrote:
>>>>> On 04.10.12 at 19:00, Jean Guyader  wrote:
>>> On 4 October 2012 16:12, Tim Deegan  wrote:
>>>> AIUI you need to use compat_handle_okay() instead of guest_handle_okay()
>>>> to check the handles if is_pv_32on64_domain(current).
>>>>
>>>
>>> How about something like that?
>>
>> Could be done, but not by modifying guest_handle_okay() (which
>> penalizes all its users), nor by (incorrectly) open-coding
>> compat_handle_okay(). And neither should any such implementation
>> use is_pv_32on64_domain() twice - use the conditional operator
>> instead (that way you also avoid evaluating arguments twice).
>>
>> So you could either introduce e.g. any_guest_handle_okay(), or
>> switch all current users of guest_handle_okay() to, say,
>> native_handle_okay() (perhaps with the exception of those where
>> the compat mode wrapper source files #define guest_handle_okay()
>> to compat_handle_okay(), which could then be dropped).
>
> Actually, after some more recalling of how all this was put together,
> you can use the existing guest_handle_okay() on anything that
> legitimately is a XEN_GUEST_HANDLE(). In particular, direct
> hypercall arguments can be expressed that way since they get
> properly zero-extended from 32 to 64 bits on the hypercall entry
> path. The things needing extra consideration are only handles
> embedded in structures - you need to either translate these
> handles, or validate that their upper halves are zero.
>
> That's also one of the reasons why I didn't make the guest
> memory accessor/validation macros transparently handle both
> cases.
>

Ok, thanks for the background info.

In my hypercall I only use direct hypercall argument handle.
The other handles that I use have been created with
guest_handle_add_offset from the original argument handle.

Considering this, I think I might be ok.

Thanks,
Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 10:25:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 10:25:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLAW2-0005xj-Ir; Mon, 08 Oct 2012 10:24:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLAW0-0005xc-Bi
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 10:24:48 +0000
Received: from [85.158.138.51:52433] by server-3.bemta-3.messagelabs.com id
	60/5E-25962-FE9A2705; Mon, 08 Oct 2012 10:24:47 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1349691885!33410893!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16417 invoked from network); 8 Oct 2012 10:24:46 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 10:24:46 -0000
Received: by mail-vc0-f173.google.com with SMTP id fl15so5205735vcb.32
	for ; Mon, 08 Oct 2012 03:24:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=2X1DFRU9NyhXEE3zDKnjFREPMApwWEddrFK7erYMKoI=;
	b=evdck5fWqfpFCkgD/4uGZWS5i6JG0JQF/zrYjT9gu1AsJ+dJY9N1bnIvSy1Po/DaqL
	M+hcyCQU//Zs7KrjYjiBJ9O9gFm8x6xjyjE+XsP0EfIaGLRDMXcgiY7eXZb/vTzST0Zk
	Ht9xPuF6Su/y3NF9p6xttj8WY8XB9JPTX2Ovo0o+iUfKNmrf04gRV5du7fveU01PX9Z9
	2TbrkTC+l8B40LUd2WvnCu82iwtAEvtS8D2sEO2Qe6iJVcMQkitcrt2WNK8XoqacdHC/
	a+pNMi4yJVVQjgqygAO/aUSVBrXNIDgqYdjdAK9xZoBaeaFUw3Derc3BoiJhboZIQuai
	ePxQ==
Received: by 10.52.96.10 with SMTP id do10mr7753086vdb.91.1349691885338; Mon,
	08 Oct 2012 03:24:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.58.234.5 with HTTP; Mon, 8 Oct 2012 03:24:25 -0700 (PDT)
In-Reply-To: <506EBF67020000780009FD94@nat28.tlf.novell.com>
References: <1348141322-28657-1-git-send-email-jean.guyader@citrix.com>
	<1348141322-28657-5-git-send-email-jean.guyader@citrix.com>
	<505B2636020000780009CAA6@nat28.tlf.novell.com>
	
	<506D98FE020000780009FA23@nat28.tlf.novell.com>
	
	<20121004151214.GG38243@ocelot.phlegethon.org>
	
	<506EBBD7020000780009FD84@nat28.tlf.novell.com>
	<506EBF67020000780009FD94@nat28.tlf.novell.com>
From: Jean Guyader 
Date: Mon, 8 Oct 2012 11:24:25 +0100
Message-ID: 
To: Jan Beulich 
Cc: Tim Deegan , Jean Guyader ,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 4/4] xen: Add V4V implementation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 5 October 2012 10:07, Jan Beulich  wrote:
>>>> On 05.10.12 at 10:52, "Jan Beulich"  wrote:
>>>>> On 04.10.12 at 19:00, Jean Guyader  wrote:
>>> On 4 October 2012 16:12, Tim Deegan  wrote:
>>>> AIUI you need to use compat_handle_okay() instead of guest_handle_okay()
>>>> to check the handles if is_pv_32on64_domain(current).
>>>>
>>>
>>> How about something like that?
>>
>> Could be done, but not by modifying guest_handle_okay() (which
>> penalizes all its users), nor by (incorrectly) open-coding
>> compat_handle_okay(). And neither should any such implementation
>> use is_pv_32on64_domain() twice - use the conditional operator
>> instead (that way you also avoid evaluating arguments twice).
>>
>> So you could either introduce e.g. any_guest_handle_okay(), or
>> switch all current users of guest_handle_okay() to, say,
>> native_handle_okay() (perhaps with the exception of those where
>> the compat mode wrapper source files #define guest_handle_okay()
>> to compat_handle_okay(), which could then be dropped).
>
> Actually, after some more recalling of how all this was put together,
> you can use the existing guest_handle_okay() on anything that
> legitimately is a XEN_GUEST_HANDLE(). In particular, direct
> hypercall arguments can be expressed that way since they get
> properly zero-extended from 32 to 64 bits on the hypercall entry
> path. The things needing extra consideration are only handles
> embedded in structures - you need to either translate these
> handles, or validate that their upper halves are zero.
>
> That's also one of the reasons why I didn't make the guest
> memory accessor/validation macros transparently handle both
> cases.
>

Ok, thanks for the background info.

In my hypercall I only use direct hypercall argument handle.
The other handles that I use have been created with
guest_handle_add_offset from the original argument handle.

Considering this, I think I might be ok.

Thanks,
Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 11:19:39 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 11:19:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLBMd-0006IT-AW; Mon, 08 Oct 2012 11:19:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLBMb-0006IO-FG
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 11:19:09 +0000
Received: from [85.158.143.35:33407] by server-2.bemta-4.messagelabs.com id
	70/DA-06610-CA6B2705; Mon, 08 Oct 2012 11:19:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1349695147!14616957!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMzNDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24439 invoked from network); 8 Oct 2012 11:19:08 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 11:19:08 -0000
X-IronPort-AV: E=Sophos;i="4.80,553,1344211200"; d="scan'208";a="14998625"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 11:19:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 8 Oct 2012
	12:19:05 +0100
Message-ID: <1349695144.18008.102.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Olaf Hering 
Date: Mon, 8 Oct 2012 12:19:04 +0100
In-Reply-To: 
References: 
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 0 of 5] misc tools changes, backport request
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-05 at 17:22 +0100, Olaf Hering wrote:
> The following 5 patches were sent shortly before 4.2 was released, so
> they were not considered (I think).  I propose the vscsi changes and the
> stubdom parallel build change for inclusion in 4.2.1.

I nearly skipped this because it said backport request but I spotted
that these were actually new patches to also be backported. I've now
acked the unacked ones and applied.

CCing Ian J for the backport request.

> 
> Olaf
> 
> Changes:
> xend/pvscsi: fix passing of SCSI control LUNs
> xend/pvscsi: fix usage of persistant device names for SCSI devices
> xend/pvscsi: update sysfs parser for Linux 3.0
> stubdom: fix parallel build by expanding CROSS_MAKE
> tools/configure.ac: fill PACKAGE_TARNAME in AC_INIT
> 
>  stubdom/Makefile                    |   54 +++++++++++++++++-------------------
>  tools/configure.ac                  |    2 -
>  tools/python/xen/util/vscsi_util.py |   32 ++++++++++++++++-----
>  3 files changed, 52 insertions(+), 36 deletions(-)
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 11:19:39 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 11:19:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLBMd-0006IT-AW; Mon, 08 Oct 2012 11:19:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLBMb-0006IO-FG
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 11:19:09 +0000
Received: from [85.158.143.35:33407] by server-2.bemta-4.messagelabs.com id
	70/DA-06610-CA6B2705; Mon, 08 Oct 2012 11:19:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1349695147!14616957!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMzNDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24439 invoked from network); 8 Oct 2012 11:19:08 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 11:19:08 -0000
X-IronPort-AV: E=Sophos;i="4.80,553,1344211200"; d="scan'208";a="14998625"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 11:19:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 8 Oct 2012
	12:19:05 +0100
Message-ID: <1349695144.18008.102.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Olaf Hering 
Date: Mon, 8 Oct 2012 12:19:04 +0100
In-Reply-To: 
References: 
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 0 of 5] misc tools changes, backport request
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-05 at 17:22 +0100, Olaf Hering wrote:
> The following 5 patches were sent shortly before 4.2 was released, so
> they were not considered (I think).  I propose the vscsi changes and the
> stubdom parallel build change for inclusion in 4.2.1.

I nearly skipped this because it said backport request but I spotted
that these were actually new patches to also be backported. I've now
acked the unacked ones and applied.

CCing Ian J for the backport request.

> 
> Olaf
> 
> Changes:
> xend/pvscsi: fix passing of SCSI control LUNs
> xend/pvscsi: fix usage of persistant device names for SCSI devices
> xend/pvscsi: update sysfs parser for Linux 3.0
> stubdom: fix parallel build by expanding CROSS_MAKE
> tools/configure.ac: fill PACKAGE_TARNAME in AC_INIT
> 
>  stubdom/Makefile                    |   54 +++++++++++++++++-------------------
>  tools/configure.ac                  |    2 -
>  tools/python/xen/util/vscsi_util.py |   32 ++++++++++++++++-----
>  3 files changed, 52 insertions(+), 36 deletions(-)
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 11:19:40 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 11:19:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLBMj-0006Is-Mj; Mon, 08 Oct 2012 11:19:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLBMi-0006Ii-AR
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 11:19:16 +0000
Received: from [85.158.143.35:37786] by server-1.bemta-4.messagelabs.com id
	FB/4C-05684-3B6B2705; Mon, 08 Oct 2012 11:19:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1349695147!14616957!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMzNDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24648 invoked from network); 8 Oct 2012 11:19:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 11:19:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,553,1344211200"; d="scan'208";a="14998628"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 11:19:12 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 8 Oct 2012
	12:19:12 +0100
Message-ID: <1349695151.18008.103.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Olaf Hering 
Date: Mon, 8 Oct 2012 12:19:11 +0100
In-Reply-To: <65ab6762cd37d0f43ff0.1349458510@probook.site>
References: <65ab6762cd37d0f43ff0.1349458510@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] xenballoond.init: remove 4 from default
 runlevel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-05 at 18:35 +0100, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering 
> # Date 1349458470 -7200
> # Node ID 65ab6762cd37d0f43ff031e00637d5a88514aadb
> # Parent  964fd4a693f940b5ae31d6d9021e0c89afaee703
> xenballoond.init: remove 4 from default runlevel
> 
> Remove 4 from default runlevel in xenballoond.init.
> 
> Similar to what changeset 24847:0900b1c905f1 does in xencommons, remove
> runlevel 4 from the other runlevel scripts. LSB defines runlevel 4 as
> reserved for local use, the local sysadmin is responsible for symlink
> creation in rc4.d.
> 
> Signed-off-by: Olaf Hering 

Acked and applied, thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 11:19:40 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 11:19:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLBMj-0006Is-Mj; Mon, 08 Oct 2012 11:19:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLBMi-0006Ii-AR
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 11:19:16 +0000
Received: from [85.158.143.35:37786] by server-1.bemta-4.messagelabs.com id
	FB/4C-05684-3B6B2705; Mon, 08 Oct 2012 11:19:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1349695147!14616957!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMzNDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24648 invoked from network); 8 Oct 2012 11:19:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 11:19:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,553,1344211200"; d="scan'208";a="14998628"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 11:19:12 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 8 Oct 2012
	12:19:12 +0100
Message-ID: <1349695151.18008.103.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Olaf Hering 
Date: Mon, 8 Oct 2012 12:19:11 +0100
In-Reply-To: <65ab6762cd37d0f43ff0.1349458510@probook.site>
References: <65ab6762cd37d0f43ff0.1349458510@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] xenballoond.init: remove 4 from default
 runlevel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-05 at 18:35 +0100, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering 
> # Date 1349458470 -7200
> # Node ID 65ab6762cd37d0f43ff031e00637d5a88514aadb
> # Parent  964fd4a693f940b5ae31d6d9021e0c89afaee703
> xenballoond.init: remove 4 from default runlevel
> 
> Remove 4 from default runlevel in xenballoond.init.
> 
> Similar to what changeset 24847:0900b1c905f1 does in xencommons, remove
> runlevel 4 from the other runlevel scripts. LSB defines runlevel 4 as
> reserved for local use, the local sysadmin is responsible for symlink
> creation in rc4.d.
> 
> Signed-off-by: Olaf Hering 

Acked and applied, thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 11:19:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 11:19:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLBMo-0006JG-2k; Mon, 08 Oct 2012 11:19:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLBMn-0006Ii-89
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 11:19:21 +0000
Received: from [85.158.143.35:38092] by server-1.bemta-4.messagelabs.com id
	DE/6C-05684-8B6B2705; Mon, 08 Oct 2012 11:19:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1349695147!14616957!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMzNDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24959 invoked from network); 8 Oct 2012 11:19:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 11:19:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,553,1344211200"; d="scan'208";a="14998632"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 11:19:18 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 8 Oct 2012
	12:19:18 +0100
Message-ID: <1349695156.18008.104.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Olaf Hering 
Date: Mon, 8 Oct 2012 12:19:16 +0100
In-Reply-To: <964fd4a693f940b5ae31.1349455955@probook.site>
References: <964fd4a693f940b5ae31.1349455955@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] hotplug/Linux: Remove tracing (bash -x)
 from network-nat script
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-05 at 17:52 +0100, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering 
> # Date 1349455879 -7200
> # Node ID 964fd4a693f940b5ae31d6d9021e0c89afaee703
> # Parent  93e92c12bc13952ed15312f937a37e6ab2d197ad
> hotplug/Linux: Remove tracing (bash -x) from network-nat script
> 
> Signed-off-by: Olaf Hering 

Acked and applied, thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 11:19:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 11:19:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLBMo-0006JG-2k; Mon, 08 Oct 2012 11:19:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLBMn-0006Ii-89
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 11:19:21 +0000
Received: from [85.158.143.35:38092] by server-1.bemta-4.messagelabs.com id
	DE/6C-05684-8B6B2705; Mon, 08 Oct 2012 11:19:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1349695147!14616957!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMzNDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24959 invoked from network); 8 Oct 2012 11:19:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 11:19:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,553,1344211200"; d="scan'208";a="14998632"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 11:19:18 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 8 Oct 2012
	12:19:18 +0100
Message-ID: <1349695156.18008.104.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Olaf Hering 
Date: Mon, 8 Oct 2012 12:19:16 +0100
In-Reply-To: <964fd4a693f940b5ae31.1349455955@probook.site>
References: <964fd4a693f940b5ae31.1349455955@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] hotplug/Linux: Remove tracing (bash -x)
 from network-nat script
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-05 at 17:52 +0100, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering 
> # Date 1349455879 -7200
> # Node ID 964fd4a693f940b5ae31d6d9021e0c89afaee703
> # Parent  93e92c12bc13952ed15312f937a37e6ab2d197ad
> hotplug/Linux: Remove tracing (bash -x) from network-nat script
> 
> Signed-off-by: Olaf Hering 

Acked and applied, thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 11:19:49 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 11:19:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLBMx-0006KS-Fd; Mon, 08 Oct 2012 11:19:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLBMv-0006K7-Po
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 11:19:29 +0000
Received: from [85.158.143.99:52093] by server-3.bemta-4.messagelabs.com id
	C9/D3-10986-1C6B2705; Mon, 08 Oct 2012 11:19:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1349695168!27150177!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMzNDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3084 invoked from network); 8 Oct 2012 11:19:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 11:19:28 -0000
X-IronPort-AV: E=Sophos;i="4.80,553,1344211200"; d="scan'208";a="14998640"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 11:19:28 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 8 Oct 2012
	12:19:27 +0100
Message-ID: <1349695166.18008.105.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Anthony PERARD 
Date: Mon, 8 Oct 2012 12:19:26 +0100
In-Reply-To: <1349447432-29511-1-git-send-email-anthony.perard@citrix.com>
References: <1349447432-29511-1-git-send-email-anthony.perard@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Xen Devel 
Subject: Re: [Xen-devel] [PATCH V4 00/10] Set dirty log on qemu-xen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gRnJpLCAyMDEyLTEwLTA1IGF0IDE1OjMwICswMTAwLCBBbnRob255IFBFUkFSRCB3cm90ZToK
PiBUaGlzIHBhdGNoIHNlcmllcyBlbmFibGVzIGxpYnhsIHRvIHNldCBkaXJ0eSBsb2cgb24gUUVN
VSB1cHN0cmVhbSBkdXJpbmcKPiBtaWdyYXRpb24gdGhyb3VnaCBhIG5ldyBRTVAgY29tbWFuZC4K
CkFwcGxpZWQuCgpJIG1hZGUgb25lIGNoYW5nZSwgdG8gSW50cm9kdWNlIGxpYnhsX19qc29uX29i
amVjdF90b195YWpsX2dlbiwgdG8gZml4OgoKY2MxOiB3YXJuaW5ncyBiZWluZyB0cmVhdGVkIGFz
IGVycm9ycwpsaWJ4bF9qc29uLmM6IEluIGZ1bmN0aW9uIOKAmGxpYnhsX19qc29uX29iamVjdF90
b195YWpsX2dlbuKAmToKbGlieGxfanNvbi5jOjM3MzogZXJyb3I6IGRlY2xhcmF0aW9uIG9mIOKA
mGluZGV44oCZIHNoYWRvd3MgYSBnbG9iYWwgZGVjbGFyYXRpb24KL3Vzci9pbmNsdWRlL3N0cmlu
Zy5oOjQ4NzogZXJyb3I6IHNoYWRvd2VkIGRlY2xhcmF0aW9uIGlzIGhlcmUKCkkgZGlkIHMvaW5k
ZXgvaWR4Ly4gSG9wZSB0aGF0J3Mgb2sKCklhbi4KCj4gCj4gVGhlIHN1Y2Nlc3Mgb2YgdGhlIGNh
bGwgZGVwZW5kcyBvbiB0aGUgcHJlc2VuY2Ugb2YgdGhlIHNwZWNpZmljIFFNUCBjb21tYW5kCj4g
eGVuLXNldC1nbG9iYWwtZGlydHktbG9nIGluIFFFTVUuIFBhdGNoZXMgZm9yIHRoaXMgY29tbWFu
ZCBoYXZlIGJlZW4gc2VudC4KPiAKPiBUaGVyZSBpcyBzZXZlcmFsIHBhdGNoZXMgdGhhdCBjbGVh
bnVwIGEgYml0IHRoZSBsaWJ4bF9qc29uL3FtcCBjb2Rlcy4KPiAKPiBDaGFuZ2Ugc2luY2UgdjM6
Cj4gICAtIFVwZGF0ZSB0aGUgY29tbWVudCBvbiB0aGUgZmlyc3QgcGF0Y2ggdG8gc2F5IHRoYXQg
Tk9HQyBjYW4gYmUgdXNlZC4KPiAKPiAKPiBBbnRob255IFBFUkFSRCAoMTApOgo+ICAgbGlieGxf
anNvbjogRXhwb3J0IGpzb25fb2JqZWN0IHJlbGF0ZWQgZnVuY3Rpb24uCj4gICBsaWJ4bF9qc29u
OiBSZW1vdmUgSlNPTl9FUlJPUiBmcm9tIGVudW0uCj4gICBsaWJ4bF9qc29uOiBSZXBsYWNlIEpT
T05fVFJVRS9GQUxTRSBieSBKU09OX0JPT0wuCj4gICBsaWJ4bF9qc29uOiBJbnRyb2R1Y2UgbGli
eGxfX2pzb25fb2JqZWN0X3RvX3lhamxfZ2VuLgo+ICAgbGlieGxfcW1wOiBJbnRyb2R1Y2VzIGhl
bHBlcnMgdG8gY3JlYXRlIGFuIGFyZ3VtZW50IGxpc3QuCj4gICBsaWJ4bF9xbXA6IFVzZSBxbXBf
cGFyYW1ldGVyc18qIGZ1bmN0aW9ucyBmb3IgcGFyYW0gbGlzdCBvZiBhIFFNUAo+ICAgICBjb21t
YW5kLgo+ICAgbGlieGxfcW1wOiBTaW1wbGlmeSBydW4gb2Ygc2luZ2xlIFFNUCBjb21tYW5kcy4K
PiAgIGxpYnhsX3FtcDogSW50cm9kdWNlIGxpYnhsX19xbXBfc2V0X2dsb2JhbF9kaXJ0eV9sb2cu
Cj4gICBsaWJ4bF9kb206IENhbGwgdGhlIHJpZ2h0IHN3aXRjaCBsb2dkaXJ0eSBmb3IgdGhlIHJp
Z2h0IERNLgo+ICAgbGlieGw6IEFsbG93IG1pZ3JhdGlvbiB3aXRoIHFlbXUteGVuLgo+IAo+ICB0
b29scy9saWJ4bC9saWJ4bC5jICAgICAgICAgIHwgIDE3IC0tLS0KPiAgdG9vbHMvbGlieGwvbGli
eGxfZG9tLmMgICAgICB8ICA0NSArKysrKysrKysrLQo+ICB0b29scy9saWJ4bC9saWJ4bF9pbnRl
cm5hbC5oIHwgIDM1ICsrKysrKy0tCj4gIHRvb2xzL2xpYnhsL2xpYnhsX2pzb24uYyAgICAgfCAg
OTUgKysrKysrKysrKysrKysrKysrLS0tLQo+ICB0b29scy9saWJ4bC9saWJ4bF9xbXAuYyAgICAg
IHwgMTg5ICsrKysrKysrKysrKysrKysrKysrKysrKy0tLS0tLS0tLS0tLS0tLS0tLS0KPiAgNSBm
aWxlcyBjaGFuZ2VkLCAyNTQgaW5zZXJ0aW9ucygrKSwgMTI3IGRlbGV0aW9ucygtKQo+IAoKCgpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwg
bWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3Jn
L3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Mon Oct 08 11:19:49 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 11:19:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLBMx-0006KS-Fd; Mon, 08 Oct 2012 11:19:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLBMv-0006K7-Po
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 11:19:29 +0000
Received: from [85.158.143.99:52093] by server-3.bemta-4.messagelabs.com id
	C9/D3-10986-1C6B2705; Mon, 08 Oct 2012 11:19:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1349695168!27150177!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMzNDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3084 invoked from network); 8 Oct 2012 11:19:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 11:19:28 -0000
X-IronPort-AV: E=Sophos;i="4.80,553,1344211200"; d="scan'208";a="14998640"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 11:19:28 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 8 Oct 2012
	12:19:27 +0100
Message-ID: <1349695166.18008.105.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Anthony PERARD 
Date: Mon, 8 Oct 2012 12:19:26 +0100
In-Reply-To: <1349447432-29511-1-git-send-email-anthony.perard@citrix.com>
References: <1349447432-29511-1-git-send-email-anthony.perard@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Xen Devel 
Subject: Re: [Xen-devel] [PATCH V4 00/10] Set dirty log on qemu-xen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gRnJpLCAyMDEyLTEwLTA1IGF0IDE1OjMwICswMTAwLCBBbnRob255IFBFUkFSRCB3cm90ZToK
PiBUaGlzIHBhdGNoIHNlcmllcyBlbmFibGVzIGxpYnhsIHRvIHNldCBkaXJ0eSBsb2cgb24gUUVN
VSB1cHN0cmVhbSBkdXJpbmcKPiBtaWdyYXRpb24gdGhyb3VnaCBhIG5ldyBRTVAgY29tbWFuZC4K
CkFwcGxpZWQuCgpJIG1hZGUgb25lIGNoYW5nZSwgdG8gSW50cm9kdWNlIGxpYnhsX19qc29uX29i
amVjdF90b195YWpsX2dlbiwgdG8gZml4OgoKY2MxOiB3YXJuaW5ncyBiZWluZyB0cmVhdGVkIGFz
IGVycm9ycwpsaWJ4bF9qc29uLmM6IEluIGZ1bmN0aW9uIOKAmGxpYnhsX19qc29uX29iamVjdF90
b195YWpsX2dlbuKAmToKbGlieGxfanNvbi5jOjM3MzogZXJyb3I6IGRlY2xhcmF0aW9uIG9mIOKA
mGluZGV44oCZIHNoYWRvd3MgYSBnbG9iYWwgZGVjbGFyYXRpb24KL3Vzci9pbmNsdWRlL3N0cmlu
Zy5oOjQ4NzogZXJyb3I6IHNoYWRvd2VkIGRlY2xhcmF0aW9uIGlzIGhlcmUKCkkgZGlkIHMvaW5k
ZXgvaWR4Ly4gSG9wZSB0aGF0J3Mgb2sKCklhbi4KCj4gCj4gVGhlIHN1Y2Nlc3Mgb2YgdGhlIGNh
bGwgZGVwZW5kcyBvbiB0aGUgcHJlc2VuY2Ugb2YgdGhlIHNwZWNpZmljIFFNUCBjb21tYW5kCj4g
eGVuLXNldC1nbG9iYWwtZGlydHktbG9nIGluIFFFTVUuIFBhdGNoZXMgZm9yIHRoaXMgY29tbWFu
ZCBoYXZlIGJlZW4gc2VudC4KPiAKPiBUaGVyZSBpcyBzZXZlcmFsIHBhdGNoZXMgdGhhdCBjbGVh
bnVwIGEgYml0IHRoZSBsaWJ4bF9qc29uL3FtcCBjb2Rlcy4KPiAKPiBDaGFuZ2Ugc2luY2UgdjM6
Cj4gICAtIFVwZGF0ZSB0aGUgY29tbWVudCBvbiB0aGUgZmlyc3QgcGF0Y2ggdG8gc2F5IHRoYXQg
Tk9HQyBjYW4gYmUgdXNlZC4KPiAKPiAKPiBBbnRob255IFBFUkFSRCAoMTApOgo+ICAgbGlieGxf
anNvbjogRXhwb3J0IGpzb25fb2JqZWN0IHJlbGF0ZWQgZnVuY3Rpb24uCj4gICBsaWJ4bF9qc29u
OiBSZW1vdmUgSlNPTl9FUlJPUiBmcm9tIGVudW0uCj4gICBsaWJ4bF9qc29uOiBSZXBsYWNlIEpT
T05fVFJVRS9GQUxTRSBieSBKU09OX0JPT0wuCj4gICBsaWJ4bF9qc29uOiBJbnRyb2R1Y2UgbGli
eGxfX2pzb25fb2JqZWN0X3RvX3lhamxfZ2VuLgo+ICAgbGlieGxfcW1wOiBJbnRyb2R1Y2VzIGhl
bHBlcnMgdG8gY3JlYXRlIGFuIGFyZ3VtZW50IGxpc3QuCj4gICBsaWJ4bF9xbXA6IFVzZSBxbXBf
cGFyYW1ldGVyc18qIGZ1bmN0aW9ucyBmb3IgcGFyYW0gbGlzdCBvZiBhIFFNUAo+ICAgICBjb21t
YW5kLgo+ICAgbGlieGxfcW1wOiBTaW1wbGlmeSBydW4gb2Ygc2luZ2xlIFFNUCBjb21tYW5kcy4K
PiAgIGxpYnhsX3FtcDogSW50cm9kdWNlIGxpYnhsX19xbXBfc2V0X2dsb2JhbF9kaXJ0eV9sb2cu
Cj4gICBsaWJ4bF9kb206IENhbGwgdGhlIHJpZ2h0IHN3aXRjaCBsb2dkaXJ0eSBmb3IgdGhlIHJp
Z2h0IERNLgo+ICAgbGlieGw6IEFsbG93IG1pZ3JhdGlvbiB3aXRoIHFlbXUteGVuLgo+IAo+ICB0
b29scy9saWJ4bC9saWJ4bC5jICAgICAgICAgIHwgIDE3IC0tLS0KPiAgdG9vbHMvbGlieGwvbGli
eGxfZG9tLmMgICAgICB8ICA0NSArKysrKysrKysrLQo+ICB0b29scy9saWJ4bC9saWJ4bF9pbnRl
cm5hbC5oIHwgIDM1ICsrKysrKy0tCj4gIHRvb2xzL2xpYnhsL2xpYnhsX2pzb24uYyAgICAgfCAg
OTUgKysrKysrKysrKysrKysrKysrLS0tLQo+ICB0b29scy9saWJ4bC9saWJ4bF9xbXAuYyAgICAg
IHwgMTg5ICsrKysrKysrKysrKysrKysrKysrKysrKy0tLS0tLS0tLS0tLS0tLS0tLS0KPiAgNSBm
aWxlcyBjaGFuZ2VkLCAyNTQgaW5zZXJ0aW9ucygrKSwgMTI3IGRlbGV0aW9ucygtKQo+IAoKCgpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwg
bWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3Jn
L3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Mon Oct 08 11:19:53 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 11:19:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLBN1-0006LS-Sx; Mon, 08 Oct 2012 11:19:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLBN0-0006Ky-J5
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 11:19:34 +0000
Received: from [85.158.143.99:52388] by server-1.bemta-4.messagelabs.com id
	39/CC-05684-5C6B2705; Mon, 08 Oct 2012 11:19:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1349695168!27150177!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMzNDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3310 invoked from network); 8 Oct 2012 11:19:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 11:19:33 -0000
X-IronPort-AV: E=Sophos;i="4.80,553,1344211200"; d="scan'208";a="14998644"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 11:19:33 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 8 Oct 2012
	12:19:33 +0100
Message-ID: <1349695171.18008.106.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Ian Jackson 
Date: Mon, 8 Oct 2012 12:19:31 +0100
In-Reply-To: <20591.3383.99356.802311@mariner.uk.xensource.com>
References: <1349448596-8611-1-git-send-email-anthony.perard@citrix.com>
	<20591.3383.99356.802311@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Anthony Perard ,
	Xen Devel 
Subject: Re: [Xen-devel] [PATCH] libxl: Add a comment about NOGC usage with
	flexarray
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-05 at 17:39 +0100, Ian Jackson wrote:
> Anthony PERARD writes ("[PATCH] libxl: Add a comment about NOGC usage with flexarray"):
> > Signed-off-by: Anthony PERARD 
> 
> Acked-by: Ian Jackson 

Applied, thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 11:19:53 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 11:19:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLBN1-0006LS-Sx; Mon, 08 Oct 2012 11:19:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLBN0-0006Ky-J5
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 11:19:34 +0000
Received: from [85.158.143.99:52388] by server-1.bemta-4.messagelabs.com id
	39/CC-05684-5C6B2705; Mon, 08 Oct 2012 11:19:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1349695168!27150177!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMzNDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3310 invoked from network); 8 Oct 2012 11:19:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 11:19:33 -0000
X-IronPort-AV: E=Sophos;i="4.80,553,1344211200"; d="scan'208";a="14998644"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 11:19:33 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 8 Oct 2012
	12:19:33 +0100
Message-ID: <1349695171.18008.106.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Ian Jackson 
Date: Mon, 8 Oct 2012 12:19:31 +0100
In-Reply-To: <20591.3383.99356.802311@mariner.uk.xensource.com>
References: <1349448596-8611-1-git-send-email-anthony.perard@citrix.com>
	<20591.3383.99356.802311@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Anthony Perard ,
	Xen Devel 
Subject: Re: [Xen-devel] [PATCH] libxl: Add a comment about NOGC usage with
	flexarray
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-05 at 17:39 +0100, Ian Jackson wrote:
> Anthony PERARD writes ("[PATCH] libxl: Add a comment about NOGC usage with flexarray"):
> > Signed-off-by: Anthony PERARD 
> 
> Acked-by: Ian Jackson 

Applied, thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 11:20:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 11:20:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLBNJ-0006Rt-AF; Mon, 08 Oct 2012 11:19:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLBNH-0006RJ-O5
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 11:19:51 +0000
Received: from [85.158.143.99:53372] by server-3.bemta-4.messagelabs.com id
	04/B4-10986-7D6B2705; Mon, 08 Oct 2012 11:19:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1349695190!27015682!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMzNDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19677 invoked from network); 8 Oct 2012 11:19:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 11:19:50 -0000
X-IronPort-AV: E=Sophos;i="4.80,553,1344211200"; d="scan'208";a="14998658"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 11:19:50 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 8 Oct 2012
	12:19:50 +0100
Message-ID: <1349695188.18008.107.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Roger Pau Monne 
Date: Mon, 8 Oct 2012 12:19:48 +0100
In-Reply-To: <506BF7FD.4000707@citrix.com>
References: <20121002163136.GA5378@intersect>
	<1349196417.650.115.camel@zakaz.uk.xensource.com>
	<506BF7FD.4000707@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-users@lists.xen.org" ,
	Ian Jackson ,
	Giorgio Mossa ,
	xen-devel 
Subject: Re: [Xen-devel] libutil.h moved to bsd/libutil.h (Was: Re:
 [Xen-users] Problem compiling Xen 4.2 from sources)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-03 at 09:31 +0100, Roger Pau Monne wrote:
> From 250c0d533bab3c9705ade8e4bffed54abcb53b1c Mon Sep 17 00:00:00 2001
> From: Roger Pau Monne 
> Date: Wed, 3 Oct 2012 10:22:21 +0200
> Subject: [PATCH] autoconf: add -Werror to libutil.h header check
> 
> libutil.h is only needed on BSDs, but not in Linux. Debian package
> libbsd-dev-0.3.0-1 installed a libutil.h overlay that contains a
> #warning, thus making libxl compilation broken due to -Werror.
> 
> Perform the libutil.h check with -Werror, so we don't include this
> bogus header.
> 
> Signed-off-by: Roger Pau Monne 

Acked-by: Ian Campbell 

and applied.

Arguably, since we compile with -Werror we should run configure with it
too -- but I bet the fallout from doing that would be horrific though!

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 11:20:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 11:20:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLBNJ-0006Rt-AF; Mon, 08 Oct 2012 11:19:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLBNH-0006RJ-O5
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 11:19:51 +0000
Received: from [85.158.143.99:53372] by server-3.bemta-4.messagelabs.com id
	04/B4-10986-7D6B2705; Mon, 08 Oct 2012 11:19:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1349695190!27015682!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMzNDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19677 invoked from network); 8 Oct 2012 11:19:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 11:19:50 -0000
X-IronPort-AV: E=Sophos;i="4.80,553,1344211200"; d="scan'208";a="14998658"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 11:19:50 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 8 Oct 2012
	12:19:50 +0100
Message-ID: <1349695188.18008.107.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Roger Pau Monne 
Date: Mon, 8 Oct 2012 12:19:48 +0100
In-Reply-To: <506BF7FD.4000707@citrix.com>
References: <20121002163136.GA5378@intersect>
	<1349196417.650.115.camel@zakaz.uk.xensource.com>
	<506BF7FD.4000707@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-users@lists.xen.org" ,
	Ian Jackson ,
	Giorgio Mossa ,
	xen-devel 
Subject: Re: [Xen-devel] libutil.h moved to bsd/libutil.h (Was: Re:
 [Xen-users] Problem compiling Xen 4.2 from sources)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-03 at 09:31 +0100, Roger Pau Monne wrote:
> From 250c0d533bab3c9705ade8e4bffed54abcb53b1c Mon Sep 17 00:00:00 2001
> From: Roger Pau Monne 
> Date: Wed, 3 Oct 2012 10:22:21 +0200
> Subject: [PATCH] autoconf: add -Werror to libutil.h header check
> 
> libutil.h is only needed on BSDs, but not in Linux. Debian package
> libbsd-dev-0.3.0-1 installed a libutil.h overlay that contains a
> #warning, thus making libxl compilation broken due to -Werror.
> 
> Perform the libutil.h check with -Werror, so we don't include this
> bogus header.
> 
> Signed-off-by: Roger Pau Monne 

Acked-by: Ian Campbell 

and applied.

Arguably, since we compile with -Werror we should run configure with it
too -- but I bet the fallout from doing that would be horrific though!

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 11:34:40 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 11:34:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLBbP-0007WM-30; Mon, 08 Oct 2012 11:34:27 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLBbN-0007WF-OJ
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 11:34:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1349696058!10107886!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMzNDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8005 invoked from network); 8 Oct 2012 11:34:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 11:34:19 -0000
X-IronPort-AV: E=Sophos;i="4.80,553,1344211200"; d="scan'208";a="14998991"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 11:34:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 8 Oct 2012
	12:34:07 +0100
Message-ID: <1349696046.18008.116.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: "valgrind-developers@lists.sourceforge.net"
	
Date: Mon, 8 Oct 2012 12:34:06 +0100
In-Reply-To: <1346775635.6712.63.camel@zakaz.uk.xensource.com>
References: <1346775635.6712.63.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel 
Subject: Re: [Xen-devel] [PATCH] valgrind: Support for ioctls used by Xen
 toolstack processes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-09-04 at 17:20 +0100, Ian Campbell wrote:
> Under Xen the toolstack is responsible for managing the domains in
> the system, e.g. creating, destroying, and otherwise manipulating
> them.

Julien Grall took these patches for a spin, which resulted in the
following 4 fixes/improvements. Rather than resend the mega patch I'll
followup with the incremental patches.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 11:34:40 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 11:34:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLBbP-0007WM-30; Mon, 08 Oct 2012 11:34:27 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLBbN-0007WF-OJ
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 11:34:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1349696058!10107886!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMzNDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8005 invoked from network); 8 Oct 2012 11:34:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 11:34:19 -0000
X-IronPort-AV: E=Sophos;i="4.80,553,1344211200"; d="scan'208";a="14998991"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 11:34:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 8 Oct 2012
	12:34:07 +0100
Message-ID: <1349696046.18008.116.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: "valgrind-developers@lists.sourceforge.net"
	
Date: Mon, 8 Oct 2012 12:34:06 +0100
In-Reply-To: <1346775635.6712.63.camel@zakaz.uk.xensource.com>
References: <1346775635.6712.63.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel 
Subject: Re: [Xen-devel] [PATCH] valgrind: Support for ioctls used by Xen
 toolstack processes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-09-04 at 17:20 +0100, Ian Campbell wrote:
> Under Xen the toolstack is responsible for managing the domains in
> the system, e.g. creating, destroying, and otherwise manipulating
> them.

Julien Grall took these patches for a spin, which resulted in the
following 4 fixes/improvements. Rather than resend the mega patch I'll
followup with the incremental patches.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 11:34:45 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 11:34:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLBbV-0007X8-FM; Mon, 08 Oct 2012 11:34:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLBbU-0007We-6z
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 11:34:32 +0000
Received: from [85.158.143.35:12283] by server-1.bemta-4.messagelabs.com id
	09/43-05684-74AB2705; Mon, 08 Oct 2012 11:34:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1349696069!10429512!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ5NjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23269 invoked from network); 8 Oct 2012 11:34:30 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 11:34:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,553,1344211200"; d="scan'208";a="40436047"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 11:34:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 8 Oct 2012 07:34:28 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TLBbP-0001Io-Oq;
	Mon, 08 Oct 2012 12:34:27 +0100
From: Ian Campbell 
To: "valgrind-developers@lists.sourceforge.net"
	, 
	xen-devel 
Date: Mon, 8 Oct 2012 12:34:27 +0100
Message-ID: <1349696067-4273-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1349696046.18008.116.camel@zakaz.uk.xensource.com>
References: <1349696046.18008.116.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell 
Subject: [Xen-devel] [PATCH 4/4] xen: include arg struct field names when
	marking memory as read.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Makes it easier to figure out what was not initialised.

Thanks, once again, to Julien Grall.
---
 coregrind/m_syswrap/syswrap-xen.c |   33 +++++++++++++++++----------------
 1 files changed, 17 insertions(+), 16 deletions(-)

diff --git a/coregrind/m_syswrap/syswrap-xen.c b/coregrind/m_syswrap/syswrap-xen.c
index cca6930..156775c 100644
--- a/coregrind/m_syswrap/syswrap-xen.c
+++ b/coregrind/m_syswrap/syswrap-xen.c
@@ -104,9 +104,9 @@ PRE(memory_op)
    switch (ARG1) {
    case XENMEM_set_memory_map: {
       xen_foreign_memory_map_t *arg =(xen_foreign_memory_map_t *)ARG2;
-      PRE_MEM_READ("XENMEM_set_memory_map",
+      PRE_MEM_READ("XENMEM_set_memory_map domid",
                    (Addr)&arg->domid, sizeof(arg->domid));
-      PRE_MEM_READ("XENMEM_set_memory_map",
+      PRE_MEM_READ("XENMEM_set_memory_map map",
                    (Addr)&arg->map, sizeof(arg->map));
       break;
    }
@@ -171,7 +171,7 @@ PRE(mmuext_op)
 
    for (i=0; icmd, sizeof(op->cmd));
       switch(op->cmd) {
       case MMUEXT_PIN_L1_TABLE:
@@ -264,9 +264,9 @@ static void pre_evtchn_op(ThreadId tid,
    switch (cmd) {
    case EVTCHNOP_alloc_unbound: {
       struct evtchn_alloc_unbound *alloc_unbound = arg;
-      PRE_MEM_READ("EVTCHNOP_alloc_unbound",
+      PRE_MEM_READ("EVTCHNOP_alloc_unbound dom",
                    (Addr)&alloc_unbound->dom, sizeof(alloc_unbound->dom));
-      PRE_MEM_READ("EVTCHNOP_alloc_unbound",
+      PRE_MEM_READ("EVTCHNOP_alloc_unbound remote_dom",
                    (Addr)&alloc_unbound->remote_dom,
                    sizeof(alloc_unbound->remote_dom));
       break;
@@ -329,8 +329,9 @@ PRE(grant_table_op)
    switch (ARG1) {
    case GNTTABOP_setup_table: {
       struct gnttab_setup_table *gst = (void *)(intptr_t)ARG2;
-      PRE_MEM_READ("GNTTABOP_setup_table", (Addr)&gst->dom, sizeof(gst->dom));
-      PRE_MEM_READ("GNTTABOP_setup_table",
+      PRE_MEM_READ("GNTTABOP_setup_table dom",
+		   (Addr)&gst->dom, sizeof(gst->dom));
+      PRE_MEM_READ("GNTTABOP_setup_table nr_frames",
                    (Addr)&gst->nr_frames, sizeof(gst->nr_frames));
       break;
    }
@@ -375,9 +376,9 @@ PRE(sysctl) {
       return;
    }
 
-#define __PRE_XEN_SYSCTL_READ(_sysctl, _union, _field)  \
-      PRE_MEM_READ("XEN_SYSCTL_" # _sysctl,             \
-                   (Addr)&sysctl->u._union._field,      \
+#define __PRE_XEN_SYSCTL_READ(_sysctl, _union, _field)			\
+      PRE_MEM_READ("XEN_SYSCTL_" #_sysctl " u." #_union "." #_field,	\
+                   (Addr)&sysctl->u._union._field,			\
                    sizeof(sysctl->u._union._field))
 #define PRE_XEN_SYSCTL_READ(_sysctl, _field) \
       __PRE_XEN_SYSCTL_READ(_sysctl, _sysctl, _field)
@@ -477,9 +478,9 @@ PRE(domctl)
       return;
    }
 
-#define __PRE_XEN_DOMCTL_READ(_domctl, _union, _field)  \
-      PRE_MEM_READ("XEN_DOMCTL_" # _domctl,             \
-                   (Addr)&domctl->u._union._field,      \
+#define __PRE_XEN_DOMCTL_READ(_domctl, _union, _field)			\
+      PRE_MEM_READ("XEN_DOMCTL_" #_domctl " u." #_union "." #_field,	\
+                   (Addr)&domctl->u._union._field,			\
                    sizeof(domctl->u._union._field))
 #define PRE_XEN_DOMCTL_READ(_domctl, _field) \
       __PRE_XEN_DOMCTL_READ(_domctl, _domctl, _field)
@@ -555,7 +556,7 @@ PRE(domctl)
 
    case XEN_DOMCTL_setvcpuaffinity:
       __PRE_XEN_DOMCTL_READ(setvcpuaffinity, vcpuaffinity, vcpu);
-      PRE_MEM_READ("XEN_DOMCTL_setvcpuaffinity",
+      PRE_MEM_READ("XEN_DOMCTL_setvcpuaffinity u.vcpuaffinity.cpumap.bitmap",
                    (Addr)domctl->u.vcpuaffinity.cpumap.bitmap.p,
                    domctl->u.vcpuaffinity.cpumap.nr_cpus / 8);
       break;
@@ -570,7 +571,7 @@ PRE(domctl)
       break;
 
    case XEN_DOMCTL_set_cpuid:
-      PRE_MEM_READ("XEN_DOMCTL_set_cpuid",
+      PRE_MEM_READ("XEN_DOMCTL_set_cpuid u.cpuid",
                    (Addr)&domctl->u.cpuid, sizeof(domctl->u.cpuid));
       break;
 
@@ -598,7 +599,7 @@ PRE(hvm_op)
    PRINT("__HYPERVISOR_hvm_op ( %ld, %p )", op, arg);
 
 #define __PRE_XEN_HVMOP_READ(_hvm_op, _type, _field)    \
-   PRE_MEM_READ("XEN_HVMOP_" # _hvm_op,                 \
+   PRE_MEM_READ("XEN_HVMOP_" # _hvm_op " " #_field,     \
                 (Addr)&((_type*)arg)->_field,           \
                 sizeof(((_type*)arg)->_field))
 #define PRE_XEN_HVMOP_READ(_hvm_op, _field)                             \
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 11:34:45 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 11:34:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLBbW-0007XW-J8; Mon, 08 Oct 2012 11:34:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLBbV-0007Wg-1V
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 11:34:33 +0000
Received: from [85.158.143.35:39467] by server-3.bemta-4.messagelabs.com id
	4D/1C-10986-84AB2705; Mon, 08 Oct 2012 11:34:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1349696068!17882917!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODA4NTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30998 invoked from network); 8 Oct 2012 11:34:32 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 11:34:32 -0000
X-IronPort-AV: E=Sophos;i="4.80,553,1344211200"; d="scan'208";a="210575859"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 11:34:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 8 Oct 2012 07:34:28 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TLBbP-0001Io-OK;
	Mon, 08 Oct 2012 12:34:27 +0100
From: Ian Campbell 
To: "valgrind-developers@lists.sourceforge.net"
	, 
	xen-devel 
Date: Mon, 8 Oct 2012 12:34:26 +0100
Message-ID: <1349696067-4273-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1349696046.18008.116.camel@zakaz.uk.xensource.com>
References: <1349696046.18008.116.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell 
Subject: [Xen-devel] [PATCH 3/4] xen: Remove cast of ARG* to unsigned int
	before pointer conversion.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is pretty dodgy on 64 bit systems.

Thanks to Julien Grall.
---
 coregrind/m_syswrap/syswrap-xen.c |   27 +++++++++++++--------------
 1 files changed, 13 insertions(+), 14 deletions(-)

diff --git a/coregrind/m_syswrap/syswrap-xen.c b/coregrind/m_syswrap/syswrap-xen.c
index 3557ba1..cca6930 100644
--- a/coregrind/m_syswrap/syswrap-xen.c
+++ b/coregrind/m_syswrap/syswrap-xen.c
@@ -103,8 +103,7 @@ PRE(memory_op)
 
    switch (ARG1) {
    case XENMEM_set_memory_map: {
-      xen_foreign_memory_map_t *arg =
-         (xen_foreign_memory_map_t *)(unsigned int)ARG2;
+      xen_foreign_memory_map_t *arg =(xen_foreign_memory_map_t *)ARG2;
       PRE_MEM_READ("XENMEM_set_memory_map",
                    (Addr)&arg->domid, sizeof(arg->domid));
       PRE_MEM_READ("XENMEM_set_memory_map",
@@ -115,7 +114,7 @@ PRE(memory_op)
    case XENMEM_decrease_reservation:
    case XENMEM_populate_physmap: {
       struct xen_memory_reservation *memory_reservation =
-         (struct xen_memory_reservation *)(unsigned int)ARG2;
+         (struct xen_memory_reservation *)ARG2;
       char *which;
 
       switch (ARG1) {
@@ -166,7 +165,7 @@ PRE(memory_op)
 
 PRE(mmuext_op)
 {
-   mmuext_op_t *ops = (void *)(unsigned int)ARG1;
+   mmuext_op_t *ops = (mmuext_op_t *)ARG1;
    unsigned int i, nr = ARG2;
 
 
@@ -286,12 +285,12 @@ static void pre_evtchn_op(ThreadId tid,
 PRE(evtchn_op)
 {
    pre_evtchn_op(tid, layout, arrghs, status, flags,
-                 ARG1, (void *)(unsigned int)ARG2, 0);
+                 ARG1, (void *)ARG2, 0);
 }
 
 PRE(evtchn_op_compat)
 {
-   struct evtchn_op *evtchn = (struct evtchn_op *)(unsigned int)ARG1;
+   struct evtchn_op *evtchn = (struct evtchn_op *)ARG1;
    PRE_MEM_READ("__HYPERVISOR_event_channel_op_compat",
                 ARG1, sizeof(*evtchn));
 
@@ -343,7 +342,7 @@ PRE(grant_table_op)
 }
 
 PRE(sysctl) {
-   struct xen_sysctl *sysctl = (struct xen_sysctl *)(unsigned int)ARG1;
+   struct xen_sysctl *sysctl = (struct xen_sysctl *)ARG1;
 
    PRINT("__HYPERVISOR_sysctl ( %d )", sysctl->cmd);
 
@@ -444,7 +443,7 @@ PRE(sysctl) {
 
 PRE(domctl)
 {
-   struct xen_domctl *domctl = (struct xen_domctl *)(unsigned int)ARG1;
+   struct xen_domctl *domctl = (struct xen_domctl *)ARG1;
 
    PRINT("__HYPERVISOR_domctl ( %d ) on dom%d", domctl->cmd, domctl->domain);
 
@@ -636,7 +635,7 @@ POST(memory_op)
    case XENMEM_increase_reservation:
    case XENMEM_populate_physmap: {
       struct xen_memory_reservation *memory_reservation =
-         (struct xen_memory_reservation *)(unsigned int)ARG2;
+         (struct xen_memory_reservation *)ARG2;
 
       POST_MEM_WRITE((Addr)memory_reservation->extent_start.p,
                      sizeof(xen_pfn_t) * memory_reservation->nr_extents);
@@ -647,7 +646,7 @@ POST(memory_op)
 
 POST(mmuext_op)
 {
-   unsigned int *pdone = (void *)(unsigned int)ARG3;
+   unsigned int *pdone = (unsigned int *)ARG3;
    /* simplistic */
    POST_MEM_WRITE((Addr)pdone, sizeof(*pdone));
 }
@@ -665,12 +664,12 @@ static void post_evtchn_op(ThreadId tid, __vki_u32 cmd, void *arg, int compat)
 
 POST(evtchn_op)
 {
-   post_evtchn_op(tid, ARG1, (void *)(unsigned int)ARG2, 0);
+   post_evtchn_op(tid, ARG1, (void *)ARG2, 0);
 }
 
 POST(evtchn_op_compat)
 {
-   struct evtchn_op *evtchn = (struct evtchn_op *)(unsigned int)ARG1;
+   struct evtchn_op *evtchn = (struct evtchn_op *)ARG1;
    post_evtchn_op(tid, evtchn->cmd, &evtchn->u, 1);
 }
 
@@ -727,7 +726,7 @@ POST(grant_table_op)
 
 POST(sysctl)
 {
-   struct xen_sysctl *sysctl = (struct xen_sysctl *)(unsigned int)ARG1;
+   struct xen_sysctl *sysctl = (struct xen_sysctl *)ARG1;
 
    if (!sysctl || sysctl->interface_version != XEN_SYSCTL_INTERFACE_VERSION)
       return;
@@ -801,7 +800,7 @@ POST(sysctl)
 }
 
 POST(domctl){
-   struct xen_domctl *domctl = (struct xen_domctl *)(unsigned int)ARG1;
+   struct xen_domctl *domctl = (struct xen_domctl *)ARG1;
 
    if (!domctl || domctl->interface_version != XEN_DOMCTL_INTERFACE_VERSION)
       return;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 11:34:45 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 11:34:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLBbV-0007X8-FM; Mon, 08 Oct 2012 11:34:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLBbU-0007We-6z
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 11:34:32 +0000
Received: from [85.158.143.35:12283] by server-1.bemta-4.messagelabs.com id
	09/43-05684-74AB2705; Mon, 08 Oct 2012 11:34:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1349696069!10429512!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ5NjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23269 invoked from network); 8 Oct 2012 11:34:30 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 11:34:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,553,1344211200"; d="scan'208";a="40436047"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 11:34:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 8 Oct 2012 07:34:28 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TLBbP-0001Io-Oq;
	Mon, 08 Oct 2012 12:34:27 +0100
From: Ian Campbell 
To: "valgrind-developers@lists.sourceforge.net"
	, 
	xen-devel 
Date: Mon, 8 Oct 2012 12:34:27 +0100
Message-ID: <1349696067-4273-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1349696046.18008.116.camel@zakaz.uk.xensource.com>
References: <1349696046.18008.116.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell 
Subject: [Xen-devel] [PATCH 4/4] xen: include arg struct field names when
	marking memory as read.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Makes it easier to figure out what was not initialised.

Thanks, once again, to Julien Grall.
---
 coregrind/m_syswrap/syswrap-xen.c |   33 +++++++++++++++++----------------
 1 files changed, 17 insertions(+), 16 deletions(-)

diff --git a/coregrind/m_syswrap/syswrap-xen.c b/coregrind/m_syswrap/syswrap-xen.c
index cca6930..156775c 100644
--- a/coregrind/m_syswrap/syswrap-xen.c
+++ b/coregrind/m_syswrap/syswrap-xen.c
@@ -104,9 +104,9 @@ PRE(memory_op)
    switch (ARG1) {
    case XENMEM_set_memory_map: {
       xen_foreign_memory_map_t *arg =(xen_foreign_memory_map_t *)ARG2;
-      PRE_MEM_READ("XENMEM_set_memory_map",
+      PRE_MEM_READ("XENMEM_set_memory_map domid",
                    (Addr)&arg->domid, sizeof(arg->domid));
-      PRE_MEM_READ("XENMEM_set_memory_map",
+      PRE_MEM_READ("XENMEM_set_memory_map map",
                    (Addr)&arg->map, sizeof(arg->map));
       break;
    }
@@ -171,7 +171,7 @@ PRE(mmuext_op)
 
    for (i=0; icmd, sizeof(op->cmd));
       switch(op->cmd) {
       case MMUEXT_PIN_L1_TABLE:
@@ -264,9 +264,9 @@ static void pre_evtchn_op(ThreadId tid,
    switch (cmd) {
    case EVTCHNOP_alloc_unbound: {
       struct evtchn_alloc_unbound *alloc_unbound = arg;
-      PRE_MEM_READ("EVTCHNOP_alloc_unbound",
+      PRE_MEM_READ("EVTCHNOP_alloc_unbound dom",
                    (Addr)&alloc_unbound->dom, sizeof(alloc_unbound->dom));
-      PRE_MEM_READ("EVTCHNOP_alloc_unbound",
+      PRE_MEM_READ("EVTCHNOP_alloc_unbound remote_dom",
                    (Addr)&alloc_unbound->remote_dom,
                    sizeof(alloc_unbound->remote_dom));
       break;
@@ -329,8 +329,9 @@ PRE(grant_table_op)
    switch (ARG1) {
    case GNTTABOP_setup_table: {
       struct gnttab_setup_table *gst = (void *)(intptr_t)ARG2;
-      PRE_MEM_READ("GNTTABOP_setup_table", (Addr)&gst->dom, sizeof(gst->dom));
-      PRE_MEM_READ("GNTTABOP_setup_table",
+      PRE_MEM_READ("GNTTABOP_setup_table dom",
+		   (Addr)&gst->dom, sizeof(gst->dom));
+      PRE_MEM_READ("GNTTABOP_setup_table nr_frames",
                    (Addr)&gst->nr_frames, sizeof(gst->nr_frames));
       break;
    }
@@ -375,9 +376,9 @@ PRE(sysctl) {
       return;
    }
 
-#define __PRE_XEN_SYSCTL_READ(_sysctl, _union, _field)  \
-      PRE_MEM_READ("XEN_SYSCTL_" # _sysctl,             \
-                   (Addr)&sysctl->u._union._field,      \
+#define __PRE_XEN_SYSCTL_READ(_sysctl, _union, _field)			\
+      PRE_MEM_READ("XEN_SYSCTL_" #_sysctl " u." #_union "." #_field,	\
+                   (Addr)&sysctl->u._union._field,			\
                    sizeof(sysctl->u._union._field))
 #define PRE_XEN_SYSCTL_READ(_sysctl, _field) \
       __PRE_XEN_SYSCTL_READ(_sysctl, _sysctl, _field)
@@ -477,9 +478,9 @@ PRE(domctl)
       return;
    }
 
-#define __PRE_XEN_DOMCTL_READ(_domctl, _union, _field)  \
-      PRE_MEM_READ("XEN_DOMCTL_" # _domctl,             \
-                   (Addr)&domctl->u._union._field,      \
+#define __PRE_XEN_DOMCTL_READ(_domctl, _union, _field)			\
+      PRE_MEM_READ("XEN_DOMCTL_" #_domctl " u." #_union "." #_field,	\
+                   (Addr)&domctl->u._union._field,			\
                    sizeof(domctl->u._union._field))
 #define PRE_XEN_DOMCTL_READ(_domctl, _field) \
       __PRE_XEN_DOMCTL_READ(_domctl, _domctl, _field)
@@ -555,7 +556,7 @@ PRE(domctl)
 
    case XEN_DOMCTL_setvcpuaffinity:
       __PRE_XEN_DOMCTL_READ(setvcpuaffinity, vcpuaffinity, vcpu);
-      PRE_MEM_READ("XEN_DOMCTL_setvcpuaffinity",
+      PRE_MEM_READ("XEN_DOMCTL_setvcpuaffinity u.vcpuaffinity.cpumap.bitmap",
                    (Addr)domctl->u.vcpuaffinity.cpumap.bitmap.p,
                    domctl->u.vcpuaffinity.cpumap.nr_cpus / 8);
       break;
@@ -570,7 +571,7 @@ PRE(domctl)
       break;
 
    case XEN_DOMCTL_set_cpuid:
-      PRE_MEM_READ("XEN_DOMCTL_set_cpuid",
+      PRE_MEM_READ("XEN_DOMCTL_set_cpuid u.cpuid",
                    (Addr)&domctl->u.cpuid, sizeof(domctl->u.cpuid));
       break;
 
@@ -598,7 +599,7 @@ PRE(hvm_op)
    PRINT("__HYPERVISOR_hvm_op ( %ld, %p )", op, arg);
 
 #define __PRE_XEN_HVMOP_READ(_hvm_op, _type, _field)    \
-   PRE_MEM_READ("XEN_HVMOP_" # _hvm_op,                 \
+   PRE_MEM_READ("XEN_HVMOP_" # _hvm_op " " #_field,     \
                 (Addr)&((_type*)arg)->_field,           \
                 sizeof(((_type*)arg)->_field))
 #define PRE_XEN_HVMOP_READ(_hvm_op, _field)                             \
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 11:34:45 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 11:34:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLBbW-0007XW-J8; Mon, 08 Oct 2012 11:34:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLBbV-0007Wg-1V
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 11:34:33 +0000
Received: from [85.158.143.35:39467] by server-3.bemta-4.messagelabs.com id
	4D/1C-10986-84AB2705; Mon, 08 Oct 2012 11:34:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1349696068!17882917!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODA4NTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30998 invoked from network); 8 Oct 2012 11:34:32 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 11:34:32 -0000
X-IronPort-AV: E=Sophos;i="4.80,553,1344211200"; d="scan'208";a="210575859"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 11:34:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 8 Oct 2012 07:34:28 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TLBbP-0001Io-OK;
	Mon, 08 Oct 2012 12:34:27 +0100
From: Ian Campbell 
To: "valgrind-developers@lists.sourceforge.net"
	, 
	xen-devel 
Date: Mon, 8 Oct 2012 12:34:26 +0100
Message-ID: <1349696067-4273-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1349696046.18008.116.camel@zakaz.uk.xensource.com>
References: <1349696046.18008.116.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell 
Subject: [Xen-devel] [PATCH 3/4] xen: Remove cast of ARG* to unsigned int
	before pointer conversion.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is pretty dodgy on 64 bit systems.

Thanks to Julien Grall.
---
 coregrind/m_syswrap/syswrap-xen.c |   27 +++++++++++++--------------
 1 files changed, 13 insertions(+), 14 deletions(-)

diff --git a/coregrind/m_syswrap/syswrap-xen.c b/coregrind/m_syswrap/syswrap-xen.c
index 3557ba1..cca6930 100644
--- a/coregrind/m_syswrap/syswrap-xen.c
+++ b/coregrind/m_syswrap/syswrap-xen.c
@@ -103,8 +103,7 @@ PRE(memory_op)
 
    switch (ARG1) {
    case XENMEM_set_memory_map: {
-      xen_foreign_memory_map_t *arg =
-         (xen_foreign_memory_map_t *)(unsigned int)ARG2;
+      xen_foreign_memory_map_t *arg =(xen_foreign_memory_map_t *)ARG2;
       PRE_MEM_READ("XENMEM_set_memory_map",
                    (Addr)&arg->domid, sizeof(arg->domid));
       PRE_MEM_READ("XENMEM_set_memory_map",
@@ -115,7 +114,7 @@ PRE(memory_op)
    case XENMEM_decrease_reservation:
    case XENMEM_populate_physmap: {
       struct xen_memory_reservation *memory_reservation =
-         (struct xen_memory_reservation *)(unsigned int)ARG2;
+         (struct xen_memory_reservation *)ARG2;
       char *which;
 
       switch (ARG1) {
@@ -166,7 +165,7 @@ PRE(memory_op)
 
 PRE(mmuext_op)
 {
-   mmuext_op_t *ops = (void *)(unsigned int)ARG1;
+   mmuext_op_t *ops = (mmuext_op_t *)ARG1;
    unsigned int i, nr = ARG2;
 
 
@@ -286,12 +285,12 @@ static void pre_evtchn_op(ThreadId tid,
 PRE(evtchn_op)
 {
    pre_evtchn_op(tid, layout, arrghs, status, flags,
-                 ARG1, (void *)(unsigned int)ARG2, 0);
+                 ARG1, (void *)ARG2, 0);
 }
 
 PRE(evtchn_op_compat)
 {
-   struct evtchn_op *evtchn = (struct evtchn_op *)(unsigned int)ARG1;
+   struct evtchn_op *evtchn = (struct evtchn_op *)ARG1;
    PRE_MEM_READ("__HYPERVISOR_event_channel_op_compat",
                 ARG1, sizeof(*evtchn));
 
@@ -343,7 +342,7 @@ PRE(grant_table_op)
 }
 
 PRE(sysctl) {
-   struct xen_sysctl *sysctl = (struct xen_sysctl *)(unsigned int)ARG1;
+   struct xen_sysctl *sysctl = (struct xen_sysctl *)ARG1;
 
    PRINT("__HYPERVISOR_sysctl ( %d )", sysctl->cmd);
 
@@ -444,7 +443,7 @@ PRE(sysctl) {
 
 PRE(domctl)
 {
-   struct xen_domctl *domctl = (struct xen_domctl *)(unsigned int)ARG1;
+   struct xen_domctl *domctl = (struct xen_domctl *)ARG1;
 
    PRINT("__HYPERVISOR_domctl ( %d ) on dom%d", domctl->cmd, domctl->domain);
 
@@ -636,7 +635,7 @@ POST(memory_op)
    case XENMEM_increase_reservation:
    case XENMEM_populate_physmap: {
       struct xen_memory_reservation *memory_reservation =
-         (struct xen_memory_reservation *)(unsigned int)ARG2;
+         (struct xen_memory_reservation *)ARG2;
 
       POST_MEM_WRITE((Addr)memory_reservation->extent_start.p,
                      sizeof(xen_pfn_t) * memory_reservation->nr_extents);
@@ -647,7 +646,7 @@ POST(memory_op)
 
 POST(mmuext_op)
 {
-   unsigned int *pdone = (void *)(unsigned int)ARG3;
+   unsigned int *pdone = (unsigned int *)ARG3;
    /* simplistic */
    POST_MEM_WRITE((Addr)pdone, sizeof(*pdone));
 }
@@ -665,12 +664,12 @@ static void post_evtchn_op(ThreadId tid, __vki_u32 cmd, void *arg, int compat)
 
 POST(evtchn_op)
 {
-   post_evtchn_op(tid, ARG1, (void *)(unsigned int)ARG2, 0);
+   post_evtchn_op(tid, ARG1, (void *)ARG2, 0);
 }
 
 POST(evtchn_op_compat)
 {
-   struct evtchn_op *evtchn = (struct evtchn_op *)(unsigned int)ARG1;
+   struct evtchn_op *evtchn = (struct evtchn_op *)ARG1;
    post_evtchn_op(tid, evtchn->cmd, &evtchn->u, 1);
 }
 
@@ -727,7 +726,7 @@ POST(grant_table_op)
 
 POST(sysctl)
 {
-   struct xen_sysctl *sysctl = (struct xen_sysctl *)(unsigned int)ARG1;
+   struct xen_sysctl *sysctl = (struct xen_sysctl *)ARG1;
 
    if (!sysctl || sysctl->interface_version != XEN_SYSCTL_INTERFACE_VERSION)
       return;
@@ -801,7 +800,7 @@ POST(sysctl)
 }
 
 POST(domctl){
-   struct xen_domctl *domctl = (struct xen_domctl *)(unsigned int)ARG1;
+   struct xen_domctl *domctl = (struct xen_domctl *)ARG1;
 
    if (!domctl || domctl->interface_version != XEN_DOMCTL_INTERFACE_VERSION)
       return;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 11:34:46 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 11:34:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLBbV-0007XI-QZ; Mon, 08 Oct 2012 11:34:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLBbU-0007Wg-Ev
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 11:34:32 +0000
Received: from [85.158.143.35:12301] by server-3.bemta-4.messagelabs.com id
	57/1C-10986-74AB2705; Mon, 08 Oct 2012 11:34:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1349696068!17882917!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODA4NTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30809 invoked from network); 8 Oct 2012 11:34:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 11:34:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,553,1344211200"; d="scan'208";a="210575857"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 11:34:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 8 Oct 2012 07:34:28 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TLBbP-0001Io-MV;
	Mon, 08 Oct 2012 12:34:27 +0100
From: Ian Campbell 
To: "valgrind-developers@lists.sourceforge.net"
	, 
	xen-devel 
Date: Mon, 8 Oct 2012 12:34:25 +0100
Message-ID: <1349696067-4273-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1349696046.18008.116.camel@zakaz.uk.xensource.com>
References: <1349696046.18008.116.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell 
Subject: [Xen-devel] [PATCH 2/4] xen: adding missing break.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thanks to Julien Grall.
---
 coregrind/m_syswrap/syswrap-xen.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/coregrind/m_syswrap/syswrap-xen.c b/coregrind/m_syswrap/syswrap-xen.c
index 6226f7e..3557ba1 100644
--- a/coregrind/m_syswrap/syswrap-xen.c
+++ b/coregrind/m_syswrap/syswrap-xen.c
@@ -127,6 +127,7 @@ PRE(memory_op)
          PRE_MEM_READ(which,
                       (Addr)memory_reservation->extent_start.p,
                       sizeof(xen_pfn_t) * memory_reservation->nr_extents);
+	 break;
       case XENMEM_populate_physmap:
          which = "XENMEM_populate_physmap";
          PRE_MEM_READ(which,
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 11:34:46 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 11:34:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLBbW-0007XP-7T; Mon, 08 Oct 2012 11:34:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLBbU-0007Wl-Po
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 11:34:32 +0000
Received: from [85.158.143.35:12323] by server-2.bemta-4.messagelabs.com id
	1B/91-06610-84AB2705; Mon, 08 Oct 2012 11:34:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1349696068!17882917!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODA4NTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30914 invoked from network); 8 Oct 2012 11:34:31 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 11:34:31 -0000
X-IronPort-AV: E=Sophos;i="4.80,553,1344211200"; d="scan'208";a="210575858"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 11:34:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 8 Oct 2012 07:34:28 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TLBbP-0001Io-M0;
	Mon, 08 Oct 2012 12:34:27 +0100
From: Ian Campbell 
To: "valgrind-developers@lists.sourceforge.net"
	, 
	xen-devel 
Date: Mon, 8 Oct 2012 12:34:24 +0100
Message-ID: <1349696067-4273-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1349696046.18008.116.camel@zakaz.uk.xensource.com>
References: <1349696046.18008.116.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell 
Subject: [Xen-devel] [PATCH 1/4] Useful messages for sys/domctl
	interface_version mismatch.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

---
 coregrind/m_syswrap/syswrap-xen.c |   52 ++++++++++++++++++++++++++++++++-----
 1 files changed, 45 insertions(+), 7 deletions(-)

diff --git a/coregrind/m_syswrap/syswrap-xen.c b/coregrind/m_syswrap/syswrap-xen.c
index 00192bf..6226f7e 100644
--- a/coregrind/m_syswrap/syswrap-xen.c
+++ b/coregrind/m_syswrap/syswrap-xen.c
@@ -59,6 +59,7 @@
 #include "priv_syswrap-xen.h"
 
 #include 
+#include 
 
 #define __XEN_TOOLS__
 
@@ -353,9 +354,26 @@ PRE(sysctl) {
    PRE_MEM_READ("__HYPERVISOR_sysctl", ARG1,
                 sizeof(uint32_t) + sizeof(uint32_t));
 
-   if (!sysctl || sysctl->interface_version != XEN_SYSCTL_INTERFACE_VERSION)
-      /* BUG ? */
+   if (!sysctl)
+      return;
+
+   if (sysctl->interface_version != XEN_SYSCTL_INTERFACE_VERSION) {
+      VG_(dmsg)("WARNING: sysctl version %"PRIx32" not supported, "
+                "built for %"PRIx32"\n",
+                sysctl->interface_version,
+                XEN_SYSCTL_INTERFACE_VERSION);
+      if (VG_(clo_verbosity) > 1) {
+         VG_(get_and_pp_StackTrace)(tid, VG_(clo_backtrace_size));
+      }
+      VG_(dmsg)("You may be able to write your own handler.\n");
+      VG_(dmsg)("Read the file README_MISSING_SYSCALL_OR_IOCTL.\n");
+      VG_(dmsg)("Nevertheless we consider this a bug.  Please report\n");
+      VG_(dmsg)("it at http://valgrind.org/support/bug_reports.html &\n");
+      VG_(dmsg)("http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen.\n");
+
+      SET_STATUS_Failure(VKI_EINVAL);
       return;
+   }
 
 #define __PRE_XEN_SYSCTL_READ(_sysctl, _union, _field)  \
       PRE_MEM_READ("XEN_SYSCTL_" # _sysctl,             \
@@ -438,9 +456,26 @@ PRE(domctl)
    PRE_MEM_READ("__HYPERVISOR_domctl", ARG1,
                 sizeof(uint32_t) + sizeof(uint32_t) + sizeof(domid_t));
 
-   if (!domctl || domctl->interface_version != XEN_DOMCTL_INTERFACE_VERSION)
-      /* BUG ? */
+   if (!domctl)
+      return;
+
+   if (domctl->interface_version != XEN_DOMCTL_INTERFACE_VERSION) {
+      VG_(dmsg)("WARNING: domctl version %"PRIx32" not supported, "
+                "built for %"PRIx32"\n",
+                domctl->interface_version,
+                XEN_DOMCTL_INTERFACE_VERSION);
+      if (VG_(clo_verbosity) > 1) {
+         VG_(get_and_pp_StackTrace)(tid, VG_(clo_backtrace_size));
+      }
+      VG_(dmsg)("You may be able to write your own handler.\n");
+      VG_(dmsg)("Read the file README_MISSING_SYSCALL_OR_IOCTL.\n");
+      VG_(dmsg)("Nevertheless we consider this a bug.  Please report\n");
+      VG_(dmsg)("it at http://valgrind.org/support/bug_reports.html &\n");
+      VG_(dmsg)("http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen.\n");
+
+      SET_STATUS_Failure(VKI_EINVAL);
       return;
+   }
 
 #define __PRE_XEN_DOMCTL_READ(_domctl, _union, _field)  \
       PRE_MEM_READ("XEN_DOMCTL_" # _domctl,             \
@@ -740,11 +775,14 @@ POST(sysctl)
 
    case XEN_SYSCTL_topologyinfo:
       POST_XEN_SYSCTL_WRITE(topologyinfo, max_cpu_index);
-      POST_MEM_WRITE((Addr)sysctl->u.topologyinfo.cpu_to_core.p,
+      if (sysctl->u.topologyinfo.cpu_to_core.p)
+         POST_MEM_WRITE((Addr)sysctl->u.topologyinfo.cpu_to_core.p,
                      sizeof(uint32_t) * sysctl->u.topologyinfo.max_cpu_index);
-      POST_MEM_WRITE((Addr)sysctl->u.topologyinfo.cpu_to_socket.p,
+      if (sysctl->u.topologyinfo.cpu_to_socket.p)
+         POST_MEM_WRITE((Addr)sysctl->u.topologyinfo.cpu_to_socket.p,
                      sizeof(uint32_t) * sysctl->u.topologyinfo.max_cpu_index);
-      POST_MEM_WRITE((Addr)sysctl->u.topologyinfo.cpu_to_node.p,
+      if (sysctl->u.topologyinfo.cpu_to_node.p)
+         POST_MEM_WRITE((Addr)sysctl->u.topologyinfo.cpu_to_node.p,
                      sizeof(uint32_t) * sysctl->u.topologyinfo.max_cpu_index);
       break;
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 11:34:46 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 11:34:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLBbW-0007XP-7T; Mon, 08 Oct 2012 11:34:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLBbU-0007Wl-Po
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 11:34:32 +0000
Received: from [85.158.143.35:12323] by server-2.bemta-4.messagelabs.com id
	1B/91-06610-84AB2705; Mon, 08 Oct 2012 11:34:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1349696068!17882917!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODA4NTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30914 invoked from network); 8 Oct 2012 11:34:31 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 11:34:31 -0000
X-IronPort-AV: E=Sophos;i="4.80,553,1344211200"; d="scan'208";a="210575858"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 11:34:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 8 Oct 2012 07:34:28 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TLBbP-0001Io-M0;
	Mon, 08 Oct 2012 12:34:27 +0100
From: Ian Campbell 
To: "valgrind-developers@lists.sourceforge.net"
	, 
	xen-devel 
Date: Mon, 8 Oct 2012 12:34:24 +0100
Message-ID: <1349696067-4273-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1349696046.18008.116.camel@zakaz.uk.xensource.com>
References: <1349696046.18008.116.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell 
Subject: [Xen-devel] [PATCH 1/4] Useful messages for sys/domctl
	interface_version mismatch.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

---
 coregrind/m_syswrap/syswrap-xen.c |   52 ++++++++++++++++++++++++++++++++-----
 1 files changed, 45 insertions(+), 7 deletions(-)

diff --git a/coregrind/m_syswrap/syswrap-xen.c b/coregrind/m_syswrap/syswrap-xen.c
index 00192bf..6226f7e 100644
--- a/coregrind/m_syswrap/syswrap-xen.c
+++ b/coregrind/m_syswrap/syswrap-xen.c
@@ -59,6 +59,7 @@
 #include "priv_syswrap-xen.h"
 
 #include 
+#include 
 
 #define __XEN_TOOLS__
 
@@ -353,9 +354,26 @@ PRE(sysctl) {
    PRE_MEM_READ("__HYPERVISOR_sysctl", ARG1,
                 sizeof(uint32_t) + sizeof(uint32_t));
 
-   if (!sysctl || sysctl->interface_version != XEN_SYSCTL_INTERFACE_VERSION)
-      /* BUG ? */
+   if (!sysctl)
+      return;
+
+   if (sysctl->interface_version != XEN_SYSCTL_INTERFACE_VERSION) {
+      VG_(dmsg)("WARNING: sysctl version %"PRIx32" not supported, "
+                "built for %"PRIx32"\n",
+                sysctl->interface_version,
+                XEN_SYSCTL_INTERFACE_VERSION);
+      if (VG_(clo_verbosity) > 1) {
+         VG_(get_and_pp_StackTrace)(tid, VG_(clo_backtrace_size));
+      }
+      VG_(dmsg)("You may be able to write your own handler.\n");
+      VG_(dmsg)("Read the file README_MISSING_SYSCALL_OR_IOCTL.\n");
+      VG_(dmsg)("Nevertheless we consider this a bug.  Please report\n");
+      VG_(dmsg)("it at http://valgrind.org/support/bug_reports.html &\n");
+      VG_(dmsg)("http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen.\n");
+
+      SET_STATUS_Failure(VKI_EINVAL);
       return;
+   }
 
 #define __PRE_XEN_SYSCTL_READ(_sysctl, _union, _field)  \
       PRE_MEM_READ("XEN_SYSCTL_" # _sysctl,             \
@@ -438,9 +456,26 @@ PRE(domctl)
    PRE_MEM_READ("__HYPERVISOR_domctl", ARG1,
                 sizeof(uint32_t) + sizeof(uint32_t) + sizeof(domid_t));
 
-   if (!domctl || domctl->interface_version != XEN_DOMCTL_INTERFACE_VERSION)
-      /* BUG ? */
+   if (!domctl)
+      return;
+
+   if (domctl->interface_version != XEN_DOMCTL_INTERFACE_VERSION) {
+      VG_(dmsg)("WARNING: domctl version %"PRIx32" not supported, "
+                "built for %"PRIx32"\n",
+                domctl->interface_version,
+                XEN_DOMCTL_INTERFACE_VERSION);
+      if (VG_(clo_verbosity) > 1) {
+         VG_(get_and_pp_StackTrace)(tid, VG_(clo_backtrace_size));
+      }
+      VG_(dmsg)("You may be able to write your own handler.\n");
+      VG_(dmsg)("Read the file README_MISSING_SYSCALL_OR_IOCTL.\n");
+      VG_(dmsg)("Nevertheless we consider this a bug.  Please report\n");
+      VG_(dmsg)("it at http://valgrind.org/support/bug_reports.html &\n");
+      VG_(dmsg)("http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen.\n");
+
+      SET_STATUS_Failure(VKI_EINVAL);
       return;
+   }
 
 #define __PRE_XEN_DOMCTL_READ(_domctl, _union, _field)  \
       PRE_MEM_READ("XEN_DOMCTL_" # _domctl,             \
@@ -740,11 +775,14 @@ POST(sysctl)
 
    case XEN_SYSCTL_topologyinfo:
       POST_XEN_SYSCTL_WRITE(topologyinfo, max_cpu_index);
-      POST_MEM_WRITE((Addr)sysctl->u.topologyinfo.cpu_to_core.p,
+      if (sysctl->u.topologyinfo.cpu_to_core.p)
+         POST_MEM_WRITE((Addr)sysctl->u.topologyinfo.cpu_to_core.p,
                      sizeof(uint32_t) * sysctl->u.topologyinfo.max_cpu_index);
-      POST_MEM_WRITE((Addr)sysctl->u.topologyinfo.cpu_to_socket.p,
+      if (sysctl->u.topologyinfo.cpu_to_socket.p)
+         POST_MEM_WRITE((Addr)sysctl->u.topologyinfo.cpu_to_socket.p,
                      sizeof(uint32_t) * sysctl->u.topologyinfo.max_cpu_index);
-      POST_MEM_WRITE((Addr)sysctl->u.topologyinfo.cpu_to_node.p,
+      if (sysctl->u.topologyinfo.cpu_to_node.p)
+         POST_MEM_WRITE((Addr)sysctl->u.topologyinfo.cpu_to_node.p,
                      sizeof(uint32_t) * sysctl->u.topologyinfo.max_cpu_index);
       break;
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 11:34:46 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 11:34:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLBbV-0007XI-QZ; Mon, 08 Oct 2012 11:34:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLBbU-0007Wg-Ev
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 11:34:32 +0000
Received: from [85.158.143.35:12301] by server-3.bemta-4.messagelabs.com id
	57/1C-10986-74AB2705; Mon, 08 Oct 2012 11:34:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1349696068!17882917!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODA4NTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30809 invoked from network); 8 Oct 2012 11:34:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 11:34:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,553,1344211200"; d="scan'208";a="210575857"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 11:34:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 8 Oct 2012 07:34:28 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TLBbP-0001Io-MV;
	Mon, 08 Oct 2012 12:34:27 +0100
From: Ian Campbell 
To: "valgrind-developers@lists.sourceforge.net"
	, 
	xen-devel 
Date: Mon, 8 Oct 2012 12:34:25 +0100
Message-ID: <1349696067-4273-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1349696046.18008.116.camel@zakaz.uk.xensource.com>
References: <1349696046.18008.116.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell 
Subject: [Xen-devel] [PATCH 2/4] xen: adding missing break.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thanks to Julien Grall.
---
 coregrind/m_syswrap/syswrap-xen.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/coregrind/m_syswrap/syswrap-xen.c b/coregrind/m_syswrap/syswrap-xen.c
index 6226f7e..3557ba1 100644
--- a/coregrind/m_syswrap/syswrap-xen.c
+++ b/coregrind/m_syswrap/syswrap-xen.c
@@ -127,6 +127,7 @@ PRE(memory_op)
          PRE_MEM_READ(which,
                       (Addr)memory_reservation->extent_start.p,
                       sizeof(xen_pfn_t) * memory_reservation->nr_extents);
+	 break;
       case XENMEM_populate_physmap:
          which = "XENMEM_populate_physmap";
          PRE_MEM_READ(which,
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 11:48:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 11:48:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLBoj-0008DL-4h; Mon, 08 Oct 2012 11:48:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLBoh-0008DG-LW
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 11:48:11 +0000
Received: from [85.158.138.51:10918] by server-15.bemta-3.messagelabs.com id
	87/00-11584-A7DB2705; Mon, 08 Oct 2012 11:48:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1349696889!33424943!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMzNDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12250 invoked from network); 8 Oct 2012 11:48:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 11:48:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,553,1344211200"; d="scan'208";a="14999333"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 11:48:09 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 8 Oct 2012
	12:48:09 +0100
Message-ID: <1349696888.18008.126.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Matthew Fioravante 
Date: Mon, 8 Oct 2012 12:48:08 +0100
In-Reply-To: <1349460077-13770-1-git-send-email-matthew.fioravante@jhuapl.edu>
References: <1349460077-13770-1-git-send-email-matthew.fioravante@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "samuel.thibault@ens-lyons.org" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH vtpm v2 01/12] Add ioread/iowrite functions
	to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SSB3YXMgYWJvdXQgdG8gYXBwbHkgbm9zLiAxICYgMy03IGJ1dCB0aGVyZSB3YXMgYSBidWlsZCBl
cnJvcjoKICAgICAgICBJbiBmaWxlIGluY2x1ZGVkIGZyb20gbWluaS1vcy5jOjIzOgogICAgICAg
IC4uL2dydWItdXBzdHJlYW0vbmV0Ym9vdC9ldGhlcmJvb3QuaDo1MjY6IGVycm9yOiBjb25mbGlj
dGluZyB0eXBlcyBmb3Ig4oCYaW5ldF9hdG9u4oCZCiAgICAgICAgL2xvY2FsL3NjcmF0Y2gvaWFu
Yy9kZXZlbC9jb21taXR0ZXIuZ2l0L3N0dWJkb20vbHdpcC14ODZfNjQvc3JjL2luY2x1ZGUvaXB2
NC9sd2lwL2luZXQuaDo0NDogbm90ZTogcHJldmlvdXMgZGVjbGFyYXRpb24gb2Yg4oCYaW5ldF9h
dG9u4oCZIHdhcyBoZXJlCiAgICAgICAgbWluaS1vcy5jOiBJbiBmdW5jdGlvbiDigJhsb2FkX21v
ZHVsZeKAmToKICAgICAgICBtaW5pLW9zLmM6MjQ0OiB3YXJuaW5nOiBzdGF0ZW1lbnQgd2l0aCBu
byBlZmZlY3QKICAgICAgICBtaW5pLW9zLmM6IEluIGZ1bmN0aW9uIOKAmG1haW7igJk6CiAgICAg
ICAgbWluaS1vcy5jOjc0Nzogd2FybmluZzogY2FzdCBmcm9tIHBvaW50ZXIgdG8gaW50ZWdlciBv
ZiBkaWZmZXJlbnQgc2l6ZQogICAgICAgIG1ha2VbMl06ICoqKiBbL2xvY2FsL3NjcmF0Y2gvaWFu
Yy9kZXZlbC9jb21taXR0ZXIuZ2l0L3N0dWJkb20vZ3J1Yi14ODZfNjQvbWluaS1vcy5vXSBFcnJv
ciAxCiAgICAgICAgbWFrZVsyXTogKioqIFdhaXRpbmcgZm9yIHVuZmluaXNoZWQgam9icy4uLi4K
ClRoZXJlIHdhcyBhbHNvIGEgc2xldyBvZiB3YXJuaW5ncyAtLSBidXQgSSB0aGluayBtYW55IG9m
IHRoZW0gbWlnaHQgYmUKbm9ybWFsIGZvciBhIHN0dWJkb20gYnVpbGQgKEknbGwgaGF2ZSB0byBj
aGVjaykuCgpCVFcgSSB3YXMgc2tpcHBpbmcsIHRoaXMgdGltZSByb3VuZDoKCiMyIGJlY2F1c2Ug
U2FtdWVsIHNlZW1lZCB0byBoYXZlIHNvbWUgYWRkaXRpb25hbCB0aG91Z2h0cyB0aGlzIG1vcm5p
bmcuCgojOCBiZWNhdXNlIEkgd2FudGVkIHRvIGhhdmUgYW5vdGhlciBxdWljayByZWFkIHRocm91
Z2ggYmVmb3JlIEkgYXBwbGllZAppdC4KCiM5IGFuZCAjMTAgYXJlIGFscmVhZHkgYXBwbGllZC4K
CiMxMSBoYXNuJ3QgYmVlbiBhY2tlZCwgYWx0aG91Z2ggSSBzZWUgR2VvcmdlIGhhcyByZXZpZXdl
ZCBpdCBhdCBsZWFzdApzb21ld2hhdC4gSG9wZWZ1bGx5IG9uZSBvciB0aGUgb3RoZXIgb2YgdXMg
KG9yIHNvbWVvbmUgZWxzZSkgd2lsbCBmaW5kCnRoZSB0aW1lIHNob3J0bHkuCgojMTIgaXMgYWxy
ZWFkeSBhcHBsaWVkCgpJYW4uCgpPbiBGcmksIDIwMTItMTAtMDUgYXQgMTk6MDEgKzAxMDAsIE1h
dHRoZXcgRmlvcmF2YW50ZSB3cm90ZToKPiBUaGlzIHBhdGNoIGFkZHMgaW93cml0ZXh4KCkgYW5k
IGlvcmVhZHh4KCkgZnVuY3Rpb25zIGZvciBpbnRlcmFjdGluZwo+IHdpdGggaGFyZHdhcmUgbWVt
b3J5IHRvIG1pbmktb3MuIFRoZSBmdW5jdGlvbnMgYXJlIGF2YWlsYWJsZSBpbiBhIGhlYWRlcgo+
IGlvcncuaAo+IAo+IFNpZ25lZC1vZmYtYnk6IE1hdHRoZXcgRmlvcmF2YW50ZSA8bWF0dGhldy5m
aW9yYXZhbnRlQGpodWFwbC5lZHU+Cj4gQWNrZWQtYnk6IFNhbXVlbCBUaGliYXVsdCA8c2FtdWVs
LnRoaWJhdWx0QGVucy1seW9ucy5vcmc+Cj4gUmV2aWV3ZWQtYnk6IEdlb3JnZSBEdW5sYXAgPGdl
b3JnZS5kdW5sYXBAZXUuY2l0cml4LmNvbT4KPiAKPiBkaWZmIC0tZ2l0IGEvZXh0cmFzL21pbmkt
b3MvYXJjaC94ODYvaW9ydy5jIGIvZXh0cmFzL21pbmktb3MvYXJjaC94ODYvaW9ydy5jCj4gbmV3
IGZpbGUgbW9kZSAxMDA2NDQKPiBpbmRleCAwMDAwMDAwLi4zMDgwNzY5Cj4gLS0tIC9kZXYvbnVs
bAo+ICsrKyBiL2V4dHJhcy9taW5pLW9zL2FyY2gveDg2L2lvcncuYwo+IEBAIC0wLDAgKzEsMzUg
QEAKPiArI2luY2x1ZGUgPG1pbmktb3MvaW9ydy5oPgo+ICsKPiArdm9pZCBpb3dyaXRlOCh2b2xh
dGlsZSB2b2lkKiBhZGRyLCB1aW50OF90IHZhbCkKPiArewo+ICsgICAqKCh2b2xhdGlsZSB1aW50
OF90KilhZGRyKSA9IHZhbDsKPiArfQo+ICt2b2lkIGlvd3JpdGUxNih2b2xhdGlsZSB2b2lkKiBh
ZGRyLCB1aW50MTZfdCB2YWwpCj4gK3sKPiArICAgKigodm9sYXRpbGUgdWludDE2X3QqKWFkZHIp
ID0gdmFsOwo+ICt9Cj4gK3ZvaWQgaW93cml0ZTMyKHZvbGF0aWxlIHZvaWQqIGFkZHIsIHVpbnQz
Ml90IHZhbCkKPiArewo+ICsgICAqKCh2b2xhdGlsZSB1aW50MzJfdCopYWRkcikgPSB2YWw7Cj4g
K30KPiArdm9pZCBpb3dyaXRlNjQodm9sYXRpbGUgdm9pZCogYWRkciwgdWludDY0X3QgdmFsKQo+
ICt7Cj4gKyAgICooKHZvbGF0aWxlIHVpbnQ2NF90KilhZGRyKSA9IHZhbDsKPiArfQo+ICsKPiAr
dWludDhfdCBpb3JlYWQ4KHZvbGF0aWxlIHZvaWQqIGFkZHIpCj4gK3sKPiArICAgcmV0dXJuICoo
KHZvbGF0aWxlIHVpbnQ4X3QqKSBhZGRyKTsKPiArfQo+ICt1aW50MTZfdCBpb3JlYWQxNih2b2xh
dGlsZSB2b2lkKiBhZGRyKQo+ICt7Cj4gKyAgIHJldHVybiAqKCh2b2xhdGlsZSB1aW50MTZfdCop
IGFkZHIpOwo+ICt9Cj4gK3VpbnQzMl90IGlvcmVhZDMyKHZvbGF0aWxlIHZvaWQqIGFkZHIpCj4g
K3sKPiArICAgcmV0dXJuICooKHZvbGF0aWxlIHVpbnQzMl90KikgYWRkcik7Cj4gK30KPiArdWlu
dDY0X3QgaW9yZWFkNjQodm9sYXRpbGUgdm9pZCogYWRkcikKPiArewo+ICsgICByZXR1cm4gKigo
dm9sYXRpbGUgdWludDY0X3QqKSBhZGRyKTsKPiArfQo+IGRpZmYgLS1naXQgYS9leHRyYXMvbWlu
aS1vcy9pbmNsdWRlL2lvcncuaCBiL2V4dHJhcy9taW5pLW9zL2luY2x1ZGUvaW9ydy5oCj4gbmV3
IGZpbGUgbW9kZSAxMDA2NDQKPiBpbmRleCAwMDAwMDAwLi5kNWVjMDY1Cj4gLS0tIC9kZXYvbnVs
bAo+ICsrKyBiL2V4dHJhcy9taW5pLW9zL2luY2x1ZGUvaW9ydy5oCj4gQEAgLTAsMCArMSwxNiBA
QAo+ICsjaWZuZGVmIE1JTklPU19JT1JXX0gKPiArI2RlZmluZSBNSU5JT1NfSU9SV19ICj4gKwo+
ICsjaW5jbHVkZSA8bWluaS1vcy90eXBlcy5oPgo+ICsKPiArdm9pZCBpb3dyaXRlOCh2b2xhdGls
ZSB2b2lkKiBhZGRyLCB1aW50OF90IHZhbCk7Cj4gK3ZvaWQgaW93cml0ZTE2KHZvbGF0aWxlIHZv
aWQqIGFkZHIsIHVpbnQxNl90IHZhbCk7Cj4gK3ZvaWQgaW93cml0ZTMyKHZvbGF0aWxlIHZvaWQq
IGFkZHIsIHVpbnQzMl90IHZhbCk7Cj4gK3ZvaWQgaW93cml0ZTY0KHZvbGF0aWxlIHZvaWQqIGFk
ZHIsIHVpbnQ2NF90IHZhbCk7Cj4gKwo+ICt1aW50OF90IGlvcmVhZDgodm9sYXRpbGUgdm9pZCog
YWRkcik7Cj4gK3VpbnQxNl90IGlvcmVhZDE2KHZvbGF0aWxlIHZvaWQqIGFkZHIpOwo+ICt1aW50
MzJfdCBpb3JlYWQzMih2b2xhdGlsZSB2b2lkKiBhZGRyKTsKPiArdWludDY0X3QgaW9yZWFkNjQo
dm9sYXRpbGUgdm9pZCogYWRkcik7Cj4gKwo+ICsjZW5kaWYKCgoKX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4t
ZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Mon Oct 08 11:48:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 11:48:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLBoj-0008DL-4h; Mon, 08 Oct 2012 11:48:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLBoh-0008DG-LW
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 11:48:11 +0000
Received: from [85.158.138.51:10918] by server-15.bemta-3.messagelabs.com id
	87/00-11584-A7DB2705; Mon, 08 Oct 2012 11:48:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1349696889!33424943!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMzNDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12250 invoked from network); 8 Oct 2012 11:48:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 11:48:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,553,1344211200"; d="scan'208";a="14999333"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 11:48:09 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 8 Oct 2012
	12:48:09 +0100
Message-ID: <1349696888.18008.126.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Matthew Fioravante 
Date: Mon, 8 Oct 2012 12:48:08 +0100
In-Reply-To: <1349460077-13770-1-git-send-email-matthew.fioravante@jhuapl.edu>
References: <1349460077-13770-1-git-send-email-matthew.fioravante@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "samuel.thibault@ens-lyons.org" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH vtpm v2 01/12] Add ioread/iowrite functions
	to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SSB3YXMgYWJvdXQgdG8gYXBwbHkgbm9zLiAxICYgMy03IGJ1dCB0aGVyZSB3YXMgYSBidWlsZCBl
cnJvcjoKICAgICAgICBJbiBmaWxlIGluY2x1ZGVkIGZyb20gbWluaS1vcy5jOjIzOgogICAgICAg
IC4uL2dydWItdXBzdHJlYW0vbmV0Ym9vdC9ldGhlcmJvb3QuaDo1MjY6IGVycm9yOiBjb25mbGlj
dGluZyB0eXBlcyBmb3Ig4oCYaW5ldF9hdG9u4oCZCiAgICAgICAgL2xvY2FsL3NjcmF0Y2gvaWFu
Yy9kZXZlbC9jb21taXR0ZXIuZ2l0L3N0dWJkb20vbHdpcC14ODZfNjQvc3JjL2luY2x1ZGUvaXB2
NC9sd2lwL2luZXQuaDo0NDogbm90ZTogcHJldmlvdXMgZGVjbGFyYXRpb24gb2Yg4oCYaW5ldF9h
dG9u4oCZIHdhcyBoZXJlCiAgICAgICAgbWluaS1vcy5jOiBJbiBmdW5jdGlvbiDigJhsb2FkX21v
ZHVsZeKAmToKICAgICAgICBtaW5pLW9zLmM6MjQ0OiB3YXJuaW5nOiBzdGF0ZW1lbnQgd2l0aCBu
byBlZmZlY3QKICAgICAgICBtaW5pLW9zLmM6IEluIGZ1bmN0aW9uIOKAmG1haW7igJk6CiAgICAg
ICAgbWluaS1vcy5jOjc0Nzogd2FybmluZzogY2FzdCBmcm9tIHBvaW50ZXIgdG8gaW50ZWdlciBv
ZiBkaWZmZXJlbnQgc2l6ZQogICAgICAgIG1ha2VbMl06ICoqKiBbL2xvY2FsL3NjcmF0Y2gvaWFu
Yy9kZXZlbC9jb21taXR0ZXIuZ2l0L3N0dWJkb20vZ3J1Yi14ODZfNjQvbWluaS1vcy5vXSBFcnJv
ciAxCiAgICAgICAgbWFrZVsyXTogKioqIFdhaXRpbmcgZm9yIHVuZmluaXNoZWQgam9icy4uLi4K
ClRoZXJlIHdhcyBhbHNvIGEgc2xldyBvZiB3YXJuaW5ncyAtLSBidXQgSSB0aGluayBtYW55IG9m
IHRoZW0gbWlnaHQgYmUKbm9ybWFsIGZvciBhIHN0dWJkb20gYnVpbGQgKEknbGwgaGF2ZSB0byBj
aGVjaykuCgpCVFcgSSB3YXMgc2tpcHBpbmcsIHRoaXMgdGltZSByb3VuZDoKCiMyIGJlY2F1c2Ug
U2FtdWVsIHNlZW1lZCB0byBoYXZlIHNvbWUgYWRkaXRpb25hbCB0aG91Z2h0cyB0aGlzIG1vcm5p
bmcuCgojOCBiZWNhdXNlIEkgd2FudGVkIHRvIGhhdmUgYW5vdGhlciBxdWljayByZWFkIHRocm91
Z2ggYmVmb3JlIEkgYXBwbGllZAppdC4KCiM5IGFuZCAjMTAgYXJlIGFscmVhZHkgYXBwbGllZC4K
CiMxMSBoYXNuJ3QgYmVlbiBhY2tlZCwgYWx0aG91Z2ggSSBzZWUgR2VvcmdlIGhhcyByZXZpZXdl
ZCBpdCBhdCBsZWFzdApzb21ld2hhdC4gSG9wZWZ1bGx5IG9uZSBvciB0aGUgb3RoZXIgb2YgdXMg
KG9yIHNvbWVvbmUgZWxzZSkgd2lsbCBmaW5kCnRoZSB0aW1lIHNob3J0bHkuCgojMTIgaXMgYWxy
ZWFkeSBhcHBsaWVkCgpJYW4uCgpPbiBGcmksIDIwMTItMTAtMDUgYXQgMTk6MDEgKzAxMDAsIE1h
dHRoZXcgRmlvcmF2YW50ZSB3cm90ZToKPiBUaGlzIHBhdGNoIGFkZHMgaW93cml0ZXh4KCkgYW5k
IGlvcmVhZHh4KCkgZnVuY3Rpb25zIGZvciBpbnRlcmFjdGluZwo+IHdpdGggaGFyZHdhcmUgbWVt
b3J5IHRvIG1pbmktb3MuIFRoZSBmdW5jdGlvbnMgYXJlIGF2YWlsYWJsZSBpbiBhIGhlYWRlcgo+
IGlvcncuaAo+IAo+IFNpZ25lZC1vZmYtYnk6IE1hdHRoZXcgRmlvcmF2YW50ZSA8bWF0dGhldy5m
aW9yYXZhbnRlQGpodWFwbC5lZHU+Cj4gQWNrZWQtYnk6IFNhbXVlbCBUaGliYXVsdCA8c2FtdWVs
LnRoaWJhdWx0QGVucy1seW9ucy5vcmc+Cj4gUmV2aWV3ZWQtYnk6IEdlb3JnZSBEdW5sYXAgPGdl
b3JnZS5kdW5sYXBAZXUuY2l0cml4LmNvbT4KPiAKPiBkaWZmIC0tZ2l0IGEvZXh0cmFzL21pbmkt
b3MvYXJjaC94ODYvaW9ydy5jIGIvZXh0cmFzL21pbmktb3MvYXJjaC94ODYvaW9ydy5jCj4gbmV3
IGZpbGUgbW9kZSAxMDA2NDQKPiBpbmRleCAwMDAwMDAwLi4zMDgwNzY5Cj4gLS0tIC9kZXYvbnVs
bAo+ICsrKyBiL2V4dHJhcy9taW5pLW9zL2FyY2gveDg2L2lvcncuYwo+IEBAIC0wLDAgKzEsMzUg
QEAKPiArI2luY2x1ZGUgPG1pbmktb3MvaW9ydy5oPgo+ICsKPiArdm9pZCBpb3dyaXRlOCh2b2xh
dGlsZSB2b2lkKiBhZGRyLCB1aW50OF90IHZhbCkKPiArewo+ICsgICAqKCh2b2xhdGlsZSB1aW50
OF90KilhZGRyKSA9IHZhbDsKPiArfQo+ICt2b2lkIGlvd3JpdGUxNih2b2xhdGlsZSB2b2lkKiBh
ZGRyLCB1aW50MTZfdCB2YWwpCj4gK3sKPiArICAgKigodm9sYXRpbGUgdWludDE2X3QqKWFkZHIp
ID0gdmFsOwo+ICt9Cj4gK3ZvaWQgaW93cml0ZTMyKHZvbGF0aWxlIHZvaWQqIGFkZHIsIHVpbnQz
Ml90IHZhbCkKPiArewo+ICsgICAqKCh2b2xhdGlsZSB1aW50MzJfdCopYWRkcikgPSB2YWw7Cj4g
K30KPiArdm9pZCBpb3dyaXRlNjQodm9sYXRpbGUgdm9pZCogYWRkciwgdWludDY0X3QgdmFsKQo+
ICt7Cj4gKyAgICooKHZvbGF0aWxlIHVpbnQ2NF90KilhZGRyKSA9IHZhbDsKPiArfQo+ICsKPiAr
dWludDhfdCBpb3JlYWQ4KHZvbGF0aWxlIHZvaWQqIGFkZHIpCj4gK3sKPiArICAgcmV0dXJuICoo
KHZvbGF0aWxlIHVpbnQ4X3QqKSBhZGRyKTsKPiArfQo+ICt1aW50MTZfdCBpb3JlYWQxNih2b2xh
dGlsZSB2b2lkKiBhZGRyKQo+ICt7Cj4gKyAgIHJldHVybiAqKCh2b2xhdGlsZSB1aW50MTZfdCop
IGFkZHIpOwo+ICt9Cj4gK3VpbnQzMl90IGlvcmVhZDMyKHZvbGF0aWxlIHZvaWQqIGFkZHIpCj4g
K3sKPiArICAgcmV0dXJuICooKHZvbGF0aWxlIHVpbnQzMl90KikgYWRkcik7Cj4gK30KPiArdWlu
dDY0X3QgaW9yZWFkNjQodm9sYXRpbGUgdm9pZCogYWRkcikKPiArewo+ICsgICByZXR1cm4gKigo
dm9sYXRpbGUgdWludDY0X3QqKSBhZGRyKTsKPiArfQo+IGRpZmYgLS1naXQgYS9leHRyYXMvbWlu
aS1vcy9pbmNsdWRlL2lvcncuaCBiL2V4dHJhcy9taW5pLW9zL2luY2x1ZGUvaW9ydy5oCj4gbmV3
IGZpbGUgbW9kZSAxMDA2NDQKPiBpbmRleCAwMDAwMDAwLi5kNWVjMDY1Cj4gLS0tIC9kZXYvbnVs
bAo+ICsrKyBiL2V4dHJhcy9taW5pLW9zL2luY2x1ZGUvaW9ydy5oCj4gQEAgLTAsMCArMSwxNiBA
QAo+ICsjaWZuZGVmIE1JTklPU19JT1JXX0gKPiArI2RlZmluZSBNSU5JT1NfSU9SV19ICj4gKwo+
ICsjaW5jbHVkZSA8bWluaS1vcy90eXBlcy5oPgo+ICsKPiArdm9pZCBpb3dyaXRlOCh2b2xhdGls
ZSB2b2lkKiBhZGRyLCB1aW50OF90IHZhbCk7Cj4gK3ZvaWQgaW93cml0ZTE2KHZvbGF0aWxlIHZv
aWQqIGFkZHIsIHVpbnQxNl90IHZhbCk7Cj4gK3ZvaWQgaW93cml0ZTMyKHZvbGF0aWxlIHZvaWQq
IGFkZHIsIHVpbnQzMl90IHZhbCk7Cj4gK3ZvaWQgaW93cml0ZTY0KHZvbGF0aWxlIHZvaWQqIGFk
ZHIsIHVpbnQ2NF90IHZhbCk7Cj4gKwo+ICt1aW50OF90IGlvcmVhZDgodm9sYXRpbGUgdm9pZCog
YWRkcik7Cj4gK3VpbnQxNl90IGlvcmVhZDE2KHZvbGF0aWxlIHZvaWQqIGFkZHIpOwo+ICt1aW50
MzJfdCBpb3JlYWQzMih2b2xhdGlsZSB2b2lkKiBhZGRyKTsKPiArdWludDY0X3QgaW9yZWFkNjQo
dm9sYXRpbGUgdm9pZCogYWRkcik7Cj4gKwo+ICsjZW5kaWYKCgoKX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4t
ZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Mon Oct 08 11:54:35 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 11:54:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLBuf-0008OW-4G; Mon, 08 Oct 2012 11:54:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLBue-0008OR-7i
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 11:54:20 +0000
Received: from [85.158.143.35:46514] by server-3.bemta-4.messagelabs.com id
	EE/38-10986-BEEB2705; Mon, 08 Oct 2012 11:54:19 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1349697253!13454375!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc5OTA1Nw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6567 invoked from network); 8 Oct 2012 11:54:18 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 11:54:18 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q98BsASj009991
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 8 Oct 2012 11:54:10 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q98Bs9NK004687
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 8 Oct 2012 11:54:09 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q98Bs9hj011315; Mon, 8 Oct 2012 06:54:09 -0500
MIME-Version: 1.0
Message-ID: 
Date: Mon, 8 Oct 2012 04:54:08 -0700 (PDT)
From: Daniel Kiper 
To: 
X-Mailer: Zimbra on Oracle Beehive
Content-Disposition: inline
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Andrew.Cooper3@citrix.com, xen-devel@lists.xen.org,
	linux-kernel@vger.kernel.org, JBeulich@suse.com, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH 01/11] kexec: introduce kexec_ops struct
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

> On Mon, 2012-10-01 at 12:36 +0100, Daniel Kiper wrote:
> > On Fri, Sep 28, 2012 at 08:49:16AM +0100, Jan Beulich wrote:
> > > >>> On 27.09.12 at 20:06, Daniel Kiper  wrote:
> > > > Some kexec/kdump implementations (e.g. Xen PVOPS) on different archs could
> > > > not use default functions or require some changes in behavior of kexec/kdump
> > > > generic code. To cope with that problem kexec_ops struct was introduced.
> > > > It allows a developer to replace all or some functions and control some
> > > > functionality of kexec/kdump generic code.
> > >
> > > I'm not convinced that doing this at the architecture independent
> > > layer is really necessary/desirable. Nevertheless, if that's the right
> > > place, then everything else looks good to me, except for a
> > > cosmetic thing:
> >
> > I do not like this patch, too. However, this is the simplest
> > solution. If you do not do that in that way then you must
> > duplicate most of kernel/kexec.c functionality in architecture
> > depndent files.
>
> It would have been a good idea to CC the maintainer of those files
> directly with at least this patch if not the whole series.

Thanks. I spotted later that maintainers are not in CC.
I am going to prepare next version of patches with
minor suggested fixes and repost them once again
for review next week.

> If they don't like this approach then there not much point in doing a
> thorough reviewing of the other 10 patches I don't think, since I would
> expect they will be required to change pretty substantially under those
> circumstances.

Sure.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 11:54:35 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 11:54:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLBuf-0008OW-4G; Mon, 08 Oct 2012 11:54:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLBue-0008OR-7i
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 11:54:20 +0000
Received: from [85.158.143.35:46514] by server-3.bemta-4.messagelabs.com id
	EE/38-10986-BEEB2705; Mon, 08 Oct 2012 11:54:19 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1349697253!13454375!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc5OTA1Nw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6567 invoked from network); 8 Oct 2012 11:54:18 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 11:54:18 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q98BsASj009991
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 8 Oct 2012 11:54:10 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q98Bs9NK004687
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 8 Oct 2012 11:54:09 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q98Bs9hj011315; Mon, 8 Oct 2012 06:54:09 -0500
MIME-Version: 1.0
Message-ID: 
Date: Mon, 8 Oct 2012 04:54:08 -0700 (PDT)
From: Daniel Kiper 
To: 
X-Mailer: Zimbra on Oracle Beehive
Content-Disposition: inline
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Andrew.Cooper3@citrix.com, xen-devel@lists.xen.org,
	linux-kernel@vger.kernel.org, JBeulich@suse.com, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH 01/11] kexec: introduce kexec_ops struct
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

> On Mon, 2012-10-01 at 12:36 +0100, Daniel Kiper wrote:
> > On Fri, Sep 28, 2012 at 08:49:16AM +0100, Jan Beulich wrote:
> > > >>> On 27.09.12 at 20:06, Daniel Kiper  wrote:
> > > > Some kexec/kdump implementations (e.g. Xen PVOPS) on different archs could
> > > > not use default functions or require some changes in behavior of kexec/kdump
> > > > generic code. To cope with that problem kexec_ops struct was introduced.
> > > > It allows a developer to replace all or some functions and control some
> > > > functionality of kexec/kdump generic code.
> > >
> > > I'm not convinced that doing this at the architecture independent
> > > layer is really necessary/desirable. Nevertheless, if that's the right
> > > place, then everything else looks good to me, except for a
> > > cosmetic thing:
> >
> > I do not like this patch, too. However, this is the simplest
> > solution. If you do not do that in that way then you must
> > duplicate most of kernel/kexec.c functionality in architecture
> > depndent files.
>
> It would have been a good idea to CC the maintainer of those files
> directly with at least this patch if not the whole series.

Thanks. I spotted later that maintainers are not in CC.
I am going to prepare next version of patches with
minor suggested fixes and repost them once again
for review next week.

> If they don't like this approach then there not much point in doing a
> thorough reviewing of the other 10 patches I don't think, since I would
> expect they will be required to change pretty substantially under those
> circumstances.

Sure.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 12:24:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 12:24:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLCNV-0000To-2F; Mon, 08 Oct 2012 12:24:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLCNS-0000TI-UA
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 12:24:07 +0000
Received: from [85.158.137.99:49223] by server-2.bemta-3.messagelabs.com id
	A3/16-16514-6E5C2705; Mon, 08 Oct 2012 12:24:06 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-4.tower-217.messagelabs.com!1349699045!20720664!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4415 invoked from network); 8 Oct 2012 12:24:05 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-4.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 12:24:05 -0000
Received: from relay2.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id 84914A37E0;
	Mon,  8 Oct 2012 14:24:05 +0200 (CEST)
From: Alexander Graf 
To: qemu-devel qemu-devel 
Date: Mon,  8 Oct 2012 14:23:45 +0200
Message-Id: <1349699033-6703-7-git-send-email-agraf@suse.de>
X-Mailer: git-send-email 1.6.0.2
In-Reply-To: <1349699033-6703-1-git-send-email-agraf@suse.de>
References: <1349699033-6703-1-git-send-email-agraf@suse.de>
Cc: Anthony Liguori , xen-devel@lists.xensource.com,
	Stefano Stabellini ,
	"qemu-ppc@nongnu.org List" ,
	Avi Kivity ,
	Scott Wood , malc ,
	David Gibson 
Subject: [Xen-devel] [PATCH 06/14] mc146818rtc: convert PIO to new memory
	api read/write
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Alexander Graf 
---
 hw/mc146818rtc.c |   19 +++++++++++--------
 1 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
index 332a77d..670f826 100644
--- a/hw/mc146818rtc.c
+++ b/hw/mc146818rtc.c
@@ -383,7 +383,8 @@ static void rtc_update_timer(void *opaque)
     check_update_timer(s);
 }
 
-static void cmos_ioport_write(void *opaque, uint32_t addr, uint32_t data)
+static void cmos_ioport_write(void *opaque, target_phys_addr_t addr,
+                              uint64_t data, unsigned size)
 {
     RTCState *s = opaque;
 
@@ -595,7 +596,8 @@ static int update_in_progress(RTCState *s)
     return 0;
 }
 
-static uint32_t cmos_ioport_read(void *opaque, uint32_t addr)
+static uint64_t cmos_ioport_read(void *opaque, target_phys_addr_t addr,
+                                 unsigned size)
 {
     RTCState *s = opaque;
     int ret;
@@ -769,13 +771,14 @@ static void rtc_reset(void *opaque)
 #endif
 }
 
-static const MemoryRegionPortio cmos_portio[] = {
-    {0, 2, 1, .read = cmos_ioport_read, .write = cmos_ioport_write },
-    PORTIO_END_OF_LIST(),
-};
-
 static const MemoryRegionOps cmos_ops = {
-    .old_portio = cmos_portio
+    .read = cmos_ioport_read,
+    .write = cmos_ioport_write,
+    .impl = {
+        .min_access_size = 1,
+        .max_access_size = 1,
+    },
+    .endianness = DEVICE_LITTLE_ENDIAN,
 };
 
 static void rtc_get_date(Object *obj, Visitor *v, void *opaque,
-- 
1.6.0.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 12:24:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 12:24:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLCNV-0000To-2F; Mon, 08 Oct 2012 12:24:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLCNS-0000TI-UA
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 12:24:07 +0000
Received: from [85.158.137.99:49223] by server-2.bemta-3.messagelabs.com id
	A3/16-16514-6E5C2705; Mon, 08 Oct 2012 12:24:06 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-4.tower-217.messagelabs.com!1349699045!20720664!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4415 invoked from network); 8 Oct 2012 12:24:05 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-4.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 12:24:05 -0000
Received: from relay2.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id 84914A37E0;
	Mon,  8 Oct 2012 14:24:05 +0200 (CEST)
From: Alexander Graf 
To: qemu-devel qemu-devel 
Date: Mon,  8 Oct 2012 14:23:45 +0200
Message-Id: <1349699033-6703-7-git-send-email-agraf@suse.de>
X-Mailer: git-send-email 1.6.0.2
In-Reply-To: <1349699033-6703-1-git-send-email-agraf@suse.de>
References: <1349699033-6703-1-git-send-email-agraf@suse.de>
Cc: Anthony Liguori , xen-devel@lists.xensource.com,
	Stefano Stabellini ,
	"qemu-ppc@nongnu.org List" ,
	Avi Kivity ,
	Scott Wood , malc ,
	David Gibson 
Subject: [Xen-devel] [PATCH 06/14] mc146818rtc: convert PIO to new memory
	api read/write
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Alexander Graf 
---
 hw/mc146818rtc.c |   19 +++++++++++--------
 1 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
index 332a77d..670f826 100644
--- a/hw/mc146818rtc.c
+++ b/hw/mc146818rtc.c
@@ -383,7 +383,8 @@ static void rtc_update_timer(void *opaque)
     check_update_timer(s);
 }
 
-static void cmos_ioport_write(void *opaque, uint32_t addr, uint32_t data)
+static void cmos_ioport_write(void *opaque, target_phys_addr_t addr,
+                              uint64_t data, unsigned size)
 {
     RTCState *s = opaque;
 
@@ -595,7 +596,8 @@ static int update_in_progress(RTCState *s)
     return 0;
 }
 
-static uint32_t cmos_ioport_read(void *opaque, uint32_t addr)
+static uint64_t cmos_ioport_read(void *opaque, target_phys_addr_t addr,
+                                 unsigned size)
 {
     RTCState *s = opaque;
     int ret;
@@ -769,13 +771,14 @@ static void rtc_reset(void *opaque)
 #endif
 }
 
-static const MemoryRegionPortio cmos_portio[] = {
-    {0, 2, 1, .read = cmos_ioport_read, .write = cmos_ioport_write },
-    PORTIO_END_OF_LIST(),
-};
-
 static const MemoryRegionOps cmos_ops = {
-    .old_portio = cmos_portio
+    .read = cmos_ioport_read,
+    .write = cmos_ioport_write,
+    .impl = {
+        .min_access_size = 1,
+        .max_access_size = 1,
+    },
+    .endianness = DEVICE_LITTLE_ENDIAN,
 };
 
 static void rtc_get_date(Object *obj, Visitor *v, void *opaque,
-- 
1.6.0.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 12:24:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 12:24:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLCNW-0000UI-Fy; Mon, 08 Oct 2012 12:24:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLCNU-0000TV-GE
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 12:24:08 +0000
Received: from [85.158.137.99:49359] by server-7.bemta-3.messagelabs.com id
	D2/D5-15765-7E5C2705; Mon, 08 Oct 2012 12:24:07 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-4.tower-217.messagelabs.com!1349699047!20720668!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4547 invoked from network); 8 Oct 2012 12:24:07 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-4.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 12:24:07 -0000
Received: from relay1.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id F1536A24CA;
	Mon,  8 Oct 2012 14:24:06 +0200 (CEST)
From: Alexander Graf 
To: qemu-devel qemu-devel 
Date: Mon,  8 Oct 2012 14:23:46 +0200
Message-Id: <1349699033-6703-8-git-send-email-agraf@suse.de>
X-Mailer: git-send-email 1.6.0.2
In-Reply-To: <1349699033-6703-1-git-send-email-agraf@suse.de>
References: <1349699033-6703-1-git-send-email-agraf@suse.de>
Cc: Anthony Liguori , xen-devel@lists.xensource.com,
	Stefano Stabellini ,
	"qemu-ppc@nongnu.org List" ,
	Avi Kivity ,
	Scott Wood , malc ,
	David Gibson 
Subject: [Xen-devel] [PATCH 07/14] pc port92: convert PIO to new memory api
	read/write
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Alexander Graf 
---
 hw/pc.c |   19 +++++++++++--------
 1 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/hw/pc.c b/hw/pc.c
index 7e7e0e2..9eb1230 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -422,7 +422,8 @@ typedef struct Port92State {
     qemu_irq *a20_out;
 } Port92State;
 
-static void port92_write(void *opaque, uint32_t addr, uint32_t val)
+static void port92_write(void *opaque, target_phys_addr_t addr, uint64_t val,
+                         unsigned size)
 {
     Port92State *s = opaque;
 
@@ -434,7 +435,8 @@ static void port92_write(void *opaque, uint32_t addr, uint32_t val)
     }
 }
 
-static uint32_t port92_read(void *opaque, uint32_t addr)
+static uint64_t port92_read(void *opaque, target_phys_addr_t addr,
+                            unsigned size)
 {
     Port92State *s = opaque;
     uint32_t ret;
@@ -469,13 +471,14 @@ static void port92_reset(DeviceState *d)
     s->outport &= ~1;
 }
 
-static const MemoryRegionPortio port92_portio[] = {
-    { 0, 1, 1, .read = port92_read, .write = port92_write },
-    PORTIO_END_OF_LIST(),
-};
-
 static const MemoryRegionOps port92_ops = {
-    .old_portio = port92_portio
+    .read = port92_read,
+    .write = port92_write,
+    .impl = {
+        .min_access_size = 1,
+        .max_access_size = 1,
+    },
+    .endianness = DEVICE_LITTLE_ENDIAN,
 };
 
 static int port92_initfn(ISADevice *dev)
-- 
1.6.0.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 12:24:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 12:24:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLCNW-0000UI-Fy; Mon, 08 Oct 2012 12:24:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLCNU-0000TV-GE
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 12:24:08 +0000
Received: from [85.158.137.99:49359] by server-7.bemta-3.messagelabs.com id
	D2/D5-15765-7E5C2705; Mon, 08 Oct 2012 12:24:07 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-4.tower-217.messagelabs.com!1349699047!20720668!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4547 invoked from network); 8 Oct 2012 12:24:07 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-4.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 12:24:07 -0000
Received: from relay1.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id F1536A24CA;
	Mon,  8 Oct 2012 14:24:06 +0200 (CEST)
From: Alexander Graf 
To: qemu-devel qemu-devel 
Date: Mon,  8 Oct 2012 14:23:46 +0200
Message-Id: <1349699033-6703-8-git-send-email-agraf@suse.de>
X-Mailer: git-send-email 1.6.0.2
In-Reply-To: <1349699033-6703-1-git-send-email-agraf@suse.de>
References: <1349699033-6703-1-git-send-email-agraf@suse.de>
Cc: Anthony Liguori , xen-devel@lists.xensource.com,
	Stefano Stabellini ,
	"qemu-ppc@nongnu.org List" ,
	Avi Kivity ,
	Scott Wood , malc ,
	David Gibson 
Subject: [Xen-devel] [PATCH 07/14] pc port92: convert PIO to new memory api
	read/write
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Alexander Graf 
---
 hw/pc.c |   19 +++++++++++--------
 1 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/hw/pc.c b/hw/pc.c
index 7e7e0e2..9eb1230 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -422,7 +422,8 @@ typedef struct Port92State {
     qemu_irq *a20_out;
 } Port92State;
 
-static void port92_write(void *opaque, uint32_t addr, uint32_t val)
+static void port92_write(void *opaque, target_phys_addr_t addr, uint64_t val,
+                         unsigned size)
 {
     Port92State *s = opaque;
 
@@ -434,7 +435,8 @@ static void port92_write(void *opaque, uint32_t addr, uint32_t val)
     }
 }
 
-static uint32_t port92_read(void *opaque, uint32_t addr)
+static uint64_t port92_read(void *opaque, target_phys_addr_t addr,
+                            unsigned size)
 {
     Port92State *s = opaque;
     uint32_t ret;
@@ -469,13 +471,14 @@ static void port92_reset(DeviceState *d)
     s->outport &= ~1;
 }
 
-static const MemoryRegionPortio port92_portio[] = {
-    { 0, 1, 1, .read = port92_read, .write = port92_write },
-    PORTIO_END_OF_LIST(),
-};
-
 static const MemoryRegionOps port92_ops = {
-    .old_portio = port92_portio
+    .read = port92_read,
+    .write = port92_write,
+    .impl = {
+        .min_access_size = 1,
+        .max_access_size = 1,
+    },
+    .endianness = DEVICE_LITTLE_ENDIAN,
 };
 
 static int port92_initfn(ISADevice *dev)
-- 
1.6.0.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 12:24:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 12:24:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLCNR-0000T5-Sp; Mon, 08 Oct 2012 12:24:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLCNQ-0000Sj-HL
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 12:24:04 +0000
Received: from [85.158.139.83:31459] by server-5.bemta-5.messagelabs.com id
	00/BE-21075-3E5C2705; Mon, 08 Oct 2012 12:24:03 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-9.tower-182.messagelabs.com!1349699043!33223692!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29593 invoked from network); 8 Oct 2012 12:24:03 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 12:24:03 -0000
Received: from relay1.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id DADD8A341E;
	Mon,  8 Oct 2012 14:24:02 +0200 (CEST)
From: Alexander Graf 
To: qemu-devel qemu-devel 
Date: Mon,  8 Oct 2012 14:23:43 +0200
Message-Id: <1349699033-6703-5-git-send-email-agraf@suse.de>
X-Mailer: git-send-email 1.6.0.2
In-Reply-To: <1349699033-6703-1-git-send-email-agraf@suse.de>
References: <1349699033-6703-1-git-send-email-agraf@suse.de>
Cc: Anthony Liguori , xen-devel@lists.xensource.com,
	Stefano Stabellini ,
	"qemu-ppc@nongnu.org List" ,
	Avi Kivity ,
	Scott Wood , malc ,
	David Gibson 
Subject: [Xen-devel] [PATCH 04/14] i8254: convert PIO to new memory api
	read/write
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Alexander Graf 
---
 hw/i8254.c |   20 +++++++++++---------
 1 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/hw/i8254.c b/hw/i8254.c
index 77bd5e8..cea8d13 100644
--- a/hw/i8254.c
+++ b/hw/i8254.c
@@ -111,7 +111,8 @@ static void pit_latch_count(PITChannelState *s)
     }
 }
 
-static void pit_ioport_write(void *opaque, uint32_t addr, uint32_t val)
+static void pit_ioport_write(void *opaque, target_phys_addr_t addr,
+                             uint64_t val, unsigned size)
 {
     PITCommonState *pit = opaque;
     int channel, access;
@@ -178,7 +179,8 @@ static void pit_ioport_write(void *opaque, uint32_t addr, uint32_t val)
     }
 }
 
-static uint32_t pit_ioport_read(void *opaque, uint32_t addr)
+static uint64_t pit_ioport_read(void *opaque, target_phys_addr_t addr,
+                                unsigned size)
 {
     PITCommonState *pit = opaque;
     int ret, count;
@@ -290,14 +292,14 @@ static void pit_irq_control(void *opaque, int n, int enable)
     }
 }
 
-static const MemoryRegionPortio pit_portio[] = {
-    { 0, 4, 1, .write = pit_ioport_write },
-    { 0, 3, 1, .read = pit_ioport_read },
-    PORTIO_END_OF_LIST()
-};
-
 static const MemoryRegionOps pit_ioport_ops = {
-    .old_portio = pit_portio
+    .read = pit_ioport_read,
+    .write = pit_ioport_write,
+    .impl = {
+        .min_access_size = 1,
+        .max_access_size = 1,
+    },
+    .endianness = DEVICE_LITTLE_ENDIAN,
 };
 
 static void pit_post_load(PITCommonState *s)
-- 
1.6.0.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 12:24:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 12:24:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLCNR-0000T5-Sp; Mon, 08 Oct 2012 12:24:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLCNQ-0000Sj-HL
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 12:24:04 +0000
Received: from [85.158.139.83:31459] by server-5.bemta-5.messagelabs.com id
	00/BE-21075-3E5C2705; Mon, 08 Oct 2012 12:24:03 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-9.tower-182.messagelabs.com!1349699043!33223692!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29593 invoked from network); 8 Oct 2012 12:24:03 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 12:24:03 -0000
Received: from relay1.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id DADD8A341E;
	Mon,  8 Oct 2012 14:24:02 +0200 (CEST)
From: Alexander Graf 
To: qemu-devel qemu-devel 
Date: Mon,  8 Oct 2012 14:23:43 +0200
Message-Id: <1349699033-6703-5-git-send-email-agraf@suse.de>
X-Mailer: git-send-email 1.6.0.2
In-Reply-To: <1349699033-6703-1-git-send-email-agraf@suse.de>
References: <1349699033-6703-1-git-send-email-agraf@suse.de>
Cc: Anthony Liguori , xen-devel@lists.xensource.com,
	Stefano Stabellini ,
	"qemu-ppc@nongnu.org List" ,
	Avi Kivity ,
	Scott Wood , malc ,
	David Gibson 
Subject: [Xen-devel] [PATCH 04/14] i8254: convert PIO to new memory api
	read/write
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Alexander Graf 
---
 hw/i8254.c |   20 +++++++++++---------
 1 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/hw/i8254.c b/hw/i8254.c
index 77bd5e8..cea8d13 100644
--- a/hw/i8254.c
+++ b/hw/i8254.c
@@ -111,7 +111,8 @@ static void pit_latch_count(PITChannelState *s)
     }
 }
 
-static void pit_ioport_write(void *opaque, uint32_t addr, uint32_t val)
+static void pit_ioport_write(void *opaque, target_phys_addr_t addr,
+                             uint64_t val, unsigned size)
 {
     PITCommonState *pit = opaque;
     int channel, access;
@@ -178,7 +179,8 @@ static void pit_ioport_write(void *opaque, uint32_t addr, uint32_t val)
     }
 }
 
-static uint32_t pit_ioport_read(void *opaque, uint32_t addr)
+static uint64_t pit_ioport_read(void *opaque, target_phys_addr_t addr,
+                                unsigned size)
 {
     PITCommonState *pit = opaque;
     int ret, count;
@@ -290,14 +292,14 @@ static void pit_irq_control(void *opaque, int n, int enable)
     }
 }
 
-static const MemoryRegionPortio pit_portio[] = {
-    { 0, 4, 1, .write = pit_ioport_write },
-    { 0, 3, 1, .read = pit_ioport_read },
-    PORTIO_END_OF_LIST()
-};
-
 static const MemoryRegionOps pit_ioport_ops = {
-    .old_portio = pit_portio
+    .read = pit_ioport_read,
+    .write = pit_ioport_write,
+    .impl = {
+        .min_access_size = 1,
+        .max_access_size = 1,
+    },
+    .endianness = DEVICE_LITTLE_ENDIAN,
 };
 
 static void pit_post_load(PITCommonState *s)
-- 
1.6.0.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 12:24:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 12:24:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLCNU-0000Tb-Ld; Mon, 08 Oct 2012 12:24:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLCNS-0000T9-Je
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 12:24:06 +0000
Received: from [85.158.138.51:7459] by server-3.bemta-3.messagelabs.com id
	D2/8A-25962-5E5C2705; Mon, 08 Oct 2012 12:24:05 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-4.tower-174.messagelabs.com!1349699044!33009375!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18121 invoked from network); 8 Oct 2012 12:24:04 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 12:24:04 -0000
Received: from relay1.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id 5FDA2A3421;
	Mon,  8 Oct 2012 14:24:04 +0200 (CEST)
From: Alexander Graf 
To: qemu-devel qemu-devel 
Date: Mon,  8 Oct 2012 14:23:44 +0200
Message-Id: <1349699033-6703-6-git-send-email-agraf@suse.de>
X-Mailer: git-send-email 1.6.0.2
In-Reply-To: <1349699033-6703-1-git-send-email-agraf@suse.de>
References: <1349699033-6703-1-git-send-email-agraf@suse.de>
Cc: Anthony Liguori , xen-devel@lists.xensource.com,
	Stefano Stabellini ,
	"qemu-ppc@nongnu.org List" ,
	Avi Kivity ,
	Scott Wood , malc ,
	David Gibson 
Subject: [Xen-devel] [PATCH 05/14] m48t59: convert PIO to new memory api
	read/write
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Alexander Graf 
---
 hw/m48t59.c |   24 ++++++++++++++----------
 1 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/hw/m48t59.c b/hw/m48t59.c
index dd6cb37..389f6c9 100644
--- a/hw/m48t59.c
+++ b/hw/m48t59.c
@@ -27,6 +27,7 @@
 #include "sysemu.h"
 #include "sysbus.h"
 #include "isa.h"
+#include "exec-memory.h"
 
 //#define DEBUG_NVRAM
 
@@ -80,6 +81,7 @@ typedef struct M48t59ISAState {
 typedef struct M48t59SysBusState {
     SysBusDevice busdev;
     M48t59State state;
+    MemoryRegion io;
 } M48t59SysBusState;
 
 /* Fake timer functions */
@@ -481,7 +483,8 @@ void m48t59_toggle_lock (void *opaque, int lock)
 }
 
 /* IO access to NVRAM */
-static void NVRAM_writeb (void *opaque, uint32_t addr, uint32_t val)
+static void NVRAM_writeb(void *opaque, target_phys_addr_t addr, uint64_t val,
+                         unsigned size)
 {
     M48t59State *NVRAM = opaque;
 
@@ -504,7 +507,7 @@ static void NVRAM_writeb (void *opaque, uint32_t addr, uint32_t val)
     }
 }
 
-static uint32_t NVRAM_readb (void *opaque, uint32_t addr)
+static uint64_t NVRAM_readb(void *opaque, target_phys_addr_t addr, unsigned size)
 {
     M48t59State *NVRAM = opaque;
     uint32_t retval;
@@ -626,13 +629,14 @@ static void m48t59_reset_sysbus(DeviceState *d)
     m48t59_reset_common(NVRAM);
 }
 
-static const MemoryRegionPortio m48t59_portio[] = {
-    {0, 4, 1, .read = NVRAM_readb, .write = NVRAM_writeb },
-    PORTIO_END_OF_LIST(),
-};
-
 static const MemoryRegionOps m48t59_io_ops = {
-    .old_portio = m48t59_portio,
+    .read = NVRAM_readb,
+    .write = NVRAM_writeb,
+    .impl = {
+        .min_access_size = 1,
+        .max_access_size = 1,
+    },
+    .endianness = DEVICE_LITTLE_ENDIAN,
 };
 
 /* Initialisation routine */
@@ -653,9 +657,9 @@ M48t59State *m48t59_init(qemu_irq IRQ, target_phys_addr_t mem_base,
     d = FROM_SYSBUS(M48t59SysBusState, s);
     state = &d->state;
     sysbus_connect_irq(s, 0, IRQ);
+    memory_region_init_io(&d->io, &m48t59_io_ops, state, "m48t59", 4);
     if (io_base != 0) {
-        register_ioport_read(io_base, 0x04, 1, NVRAM_readb, state);
-        register_ioport_write(io_base, 0x04, 1, NVRAM_writeb, state);
+        memory_region_add_subregion(get_system_io(), io_base, &d->io);
     }
     if (mem_base != 0) {
         sysbus_mmio_map(s, 0, mem_base);
-- 
1.6.0.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 12:24:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 12:24:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLCNW-0000UX-Tm; Mon, 08 Oct 2012 12:24:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLCNV-0000Sh-1s
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 12:24:09 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-2.tower-27.messagelabs.com!1349699042!13826558!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13179 invoked from network); 8 Oct 2012 12:24:03 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 12:24:03 -0000
Received: from relay2.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id 20112A24CA;
	Mon,  8 Oct 2012 14:23:59 +0200 (CEST)
From: Alexander Graf 
To: qemu-devel qemu-devel 
Date: Mon,  8 Oct 2012 14:23:40 +0200
Message-Id: <1349699033-6703-2-git-send-email-agraf@suse.de>
X-Mailer: git-send-email 1.6.0.2
In-Reply-To: <1349699033-6703-1-git-send-email-agraf@suse.de>
References: <1349699033-6703-1-git-send-email-agraf@suse.de>
Cc: Anthony Liguori , xen-devel@lists.xensource.com,
	Stefano Stabellini ,
	"qemu-ppc@nongnu.org List" ,
	Avi Kivity ,
	Scott Wood , malc ,
	David Gibson 
Subject: [Xen-devel] [PATCH 01/14] ac97: convert PIO to new memory api
	read/write
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Alexander Graf 
---
 hw/ac97.c |  109 +++++++++++++++++++++++++++++++++++++++++++++++++-----------
 1 files changed, 89 insertions(+), 20 deletions(-)

diff --git a/hw/ac97.c b/hw/ac97.c
index 0f561fa..c1cc3dd 100644
--- a/hw/ac97.c
+++ b/hw/ac97.c
@@ -1226,32 +1226,101 @@ static const VMStateDescription vmstate_ac97 = {
     }
 };
 
-static const MemoryRegionPortio nam_portio[] = {
-    { 0, 256 * 1, 1, .read = nam_readb, },
-    { 0, 256 * 2, 2, .read = nam_readw, },
-    { 0, 256 * 4, 4, .read = nam_readl, },
-    { 0, 256 * 1, 1, .write = nam_writeb, },
-    { 0, 256 * 2, 2, .write = nam_writew, },
-    { 0, 256 * 4, 4, .write = nam_writel, },
-    PORTIO_END_OF_LIST (),
-};
+static uint64_t nam_read(void *opaque, target_phys_addr_t addr, unsigned size)
+{
+    if ((addr / size) > 256) {
+        return -1;
+    }
+
+    switch (size) {
+    case 1:
+        return nam_readb(opaque, addr);
+    case 2:
+        return nam_readw(opaque, addr);
+    case 4:
+        return nam_readl(opaque, addr);
+    default:
+        return -1;
+    }
+}
+
+static void nam_write(void *opaque, target_phys_addr_t addr, uint64_t val,
+                      unsigned size)
+{
+    if ((addr / size) > 256) {
+        return;
+    }
+
+    switch (size) {
+    case 1:
+        nam_writeb(opaque, addr, val);
+        break;
+    case 2:
+        nam_writew(opaque, addr, val);
+        break;
+    case 4:
+        nam_writel(opaque, addr, val);
+        break;
+    }
+}
 
 static const MemoryRegionOps ac97_io_nam_ops = {
-    .old_portio = nam_portio,
+    .read = nam_read,
+    .write = nam_write,
+    .impl = {
+        .min_access_size = 1,
+        .max_access_size = 4,
+    },
+    .endianness = DEVICE_LITTLE_ENDIAN,
 };
 
-static const MemoryRegionPortio nabm_portio[] = {
-    { 0, 64 * 1, 1, .read = nabm_readb, },
-    { 0, 64 * 2, 2, .read = nabm_readw, },
-    { 0, 64 * 4, 4, .read = nabm_readl, },
-    { 0, 64 * 1, 1, .write = nabm_writeb, },
-    { 0, 64 * 2, 2, .write = nabm_writew, },
-    { 0, 64 * 4, 4, .write = nabm_writel, },
-    PORTIO_END_OF_LIST ()
-};
+static uint64_t nabm_read(void *opaque, target_phys_addr_t addr, unsigned size)
+{
+    if ((addr / size) > 64) {
+        return -1;
+    }
+
+    switch (size) {
+    case 1:
+        return nabm_readb(opaque, addr);
+    case 2:
+        return nabm_readw(opaque, addr);
+    case 4:
+        return nabm_readl(opaque, addr);
+    default:
+        return -1;
+    }
+}
+
+static void nabm_write(void *opaque, target_phys_addr_t addr, uint64_t val,
+                      unsigned size)
+{
+    if ((addr / size) > 64) {
+        return;
+    }
+
+    switch (size) {
+    case 1:
+        nabm_writeb(opaque, addr, val);
+        break;
+    case 2:
+        nabm_writew(opaque, addr, val);
+        break;
+    case 4:
+        nabm_writel(opaque, addr, val);
+        break;
+    }
+}
+
 
 static const MemoryRegionOps ac97_io_nabm_ops = {
-    .old_portio = nabm_portio,
+    .read = nabm_read,
+    .write = nabm_write,
+    .impl = {
+        .min_access_size = 1,
+        .max_access_size = 4,
+    },
+    .endianness = DEVICE_LITTLE_ENDIAN,
 };
 
 static void ac97_on_reset (void *opaque)
-- 
1.6.0.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 12:24:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 12:24:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLCNW-0000UX-Tm; Mon, 08 Oct 2012 12:24:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLCNV-0000Sh-1s
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 12:24:09 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-2.tower-27.messagelabs.com!1349699042!13826558!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13179 invoked from network); 8 Oct 2012 12:24:03 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 12:24:03 -0000
Received: from relay2.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id 20112A24CA;
	Mon,  8 Oct 2012 14:23:59 +0200 (CEST)
From: Alexander Graf 
To: qemu-devel qemu-devel 
Date: Mon,  8 Oct 2012 14:23:40 +0200
Message-Id: <1349699033-6703-2-git-send-email-agraf@suse.de>
X-Mailer: git-send-email 1.6.0.2
In-Reply-To: <1349699033-6703-1-git-send-email-agraf@suse.de>
References: <1349699033-6703-1-git-send-email-agraf@suse.de>
Cc: Anthony Liguori , xen-devel@lists.xensource.com,
	Stefano Stabellini ,
	"qemu-ppc@nongnu.org List" ,
	Avi Kivity ,
	Scott Wood , malc ,
	David Gibson 
Subject: [Xen-devel] [PATCH 01/14] ac97: convert PIO to new memory api
	read/write
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Alexander Graf 
---
 hw/ac97.c |  109 +++++++++++++++++++++++++++++++++++++++++++++++++-----------
 1 files changed, 89 insertions(+), 20 deletions(-)

diff --git a/hw/ac97.c b/hw/ac97.c
index 0f561fa..c1cc3dd 100644
--- a/hw/ac97.c
+++ b/hw/ac97.c
@@ -1226,32 +1226,101 @@ static const VMStateDescription vmstate_ac97 = {
     }
 };
 
-static const MemoryRegionPortio nam_portio[] = {
-    { 0, 256 * 1, 1, .read = nam_readb, },
-    { 0, 256 * 2, 2, .read = nam_readw, },
-    { 0, 256 * 4, 4, .read = nam_readl, },
-    { 0, 256 * 1, 1, .write = nam_writeb, },
-    { 0, 256 * 2, 2, .write = nam_writew, },
-    { 0, 256 * 4, 4, .write = nam_writel, },
-    PORTIO_END_OF_LIST (),
-};
+static uint64_t nam_read(void *opaque, target_phys_addr_t addr, unsigned size)
+{
+    if ((addr / size) > 256) {
+        return -1;
+    }
+
+    switch (size) {
+    case 1:
+        return nam_readb(opaque, addr);
+    case 2:
+        return nam_readw(opaque, addr);
+    case 4:
+        return nam_readl(opaque, addr);
+    default:
+        return -1;
+    }
+}
+
+static void nam_write(void *opaque, target_phys_addr_t addr, uint64_t val,
+                      unsigned size)
+{
+    if ((addr / size) > 256) {
+        return;
+    }
+
+    switch (size) {
+    case 1:
+        nam_writeb(opaque, addr, val);
+        break;
+    case 2:
+        nam_writew(opaque, addr, val);
+        break;
+    case 4:
+        nam_writel(opaque, addr, val);
+        break;
+    }
+}
 
 static const MemoryRegionOps ac97_io_nam_ops = {
-    .old_portio = nam_portio,
+    .read = nam_read,
+    .write = nam_write,
+    .impl = {
+        .min_access_size = 1,
+        .max_access_size = 4,
+    },
+    .endianness = DEVICE_LITTLE_ENDIAN,
 };
 
-static const MemoryRegionPortio nabm_portio[] = {
-    { 0, 64 * 1, 1, .read = nabm_readb, },
-    { 0, 64 * 2, 2, .read = nabm_readw, },
-    { 0, 64 * 4, 4, .read = nabm_readl, },
-    { 0, 64 * 1, 1, .write = nabm_writeb, },
-    { 0, 64 * 2, 2, .write = nabm_writew, },
-    { 0, 64 * 4, 4, .write = nabm_writel, },
-    PORTIO_END_OF_LIST ()
-};
+static uint64_t nabm_read(void *opaque, target_phys_addr_t addr, unsigned size)
+{
+    if ((addr / size) > 64) {
+        return -1;
+    }
+
+    switch (size) {
+    case 1:
+        return nabm_readb(opaque, addr);
+    case 2:
+        return nabm_readw(opaque, addr);
+    case 4:
+        return nabm_readl(opaque, addr);
+    default:
+        return -1;
+    }
+}
+
+static void nabm_write(void *opaque, target_phys_addr_t addr, uint64_t val,
+                      unsigned size)
+{
+    if ((addr / size) > 64) {
+        return;
+    }
+
+    switch (size) {
+    case 1:
+        nabm_writeb(opaque, addr, val);
+        break;
+    case 2:
+        nabm_writew(opaque, addr, val);
+        break;
+    case 4:
+        nabm_writel(opaque, addr, val);
+        break;
+    }
+}
+
 
 static const MemoryRegionOps ac97_io_nabm_ops = {
-    .old_portio = nabm_portio,
+    .read = nabm_read,
+    .write = nabm_write,
+    .impl = {
+        .min_access_size = 1,
+        .max_access_size = 4,
+    },
+    .endianness = DEVICE_LITTLE_ENDIAN,
 };
 
 static void ac97_on_reset (void *opaque)
-- 
1.6.0.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 12:24:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 12:24:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLCNU-0000Tb-Ld; Mon, 08 Oct 2012 12:24:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLCNS-0000T9-Je
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 12:24:06 +0000
Received: from [85.158.138.51:7459] by server-3.bemta-3.messagelabs.com id
	D2/8A-25962-5E5C2705; Mon, 08 Oct 2012 12:24:05 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-4.tower-174.messagelabs.com!1349699044!33009375!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18121 invoked from network); 8 Oct 2012 12:24:04 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 12:24:04 -0000
Received: from relay1.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id 5FDA2A3421;
	Mon,  8 Oct 2012 14:24:04 +0200 (CEST)
From: Alexander Graf 
To: qemu-devel qemu-devel 
Date: Mon,  8 Oct 2012 14:23:44 +0200
Message-Id: <1349699033-6703-6-git-send-email-agraf@suse.de>
X-Mailer: git-send-email 1.6.0.2
In-Reply-To: <1349699033-6703-1-git-send-email-agraf@suse.de>
References: <1349699033-6703-1-git-send-email-agraf@suse.de>
Cc: Anthony Liguori , xen-devel@lists.xensource.com,
	Stefano Stabellini ,
	"qemu-ppc@nongnu.org List" ,
	Avi Kivity ,
	Scott Wood , malc ,
	David Gibson 
Subject: [Xen-devel] [PATCH 05/14] m48t59: convert PIO to new memory api
	read/write
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Alexander Graf 
---
 hw/m48t59.c |   24 ++++++++++++++----------
 1 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/hw/m48t59.c b/hw/m48t59.c
index dd6cb37..389f6c9 100644
--- a/hw/m48t59.c
+++ b/hw/m48t59.c
@@ -27,6 +27,7 @@
 #include "sysemu.h"
 #include "sysbus.h"
 #include "isa.h"
+#include "exec-memory.h"
 
 //#define DEBUG_NVRAM
 
@@ -80,6 +81,7 @@ typedef struct M48t59ISAState {
 typedef struct M48t59SysBusState {
     SysBusDevice busdev;
     M48t59State state;
+    MemoryRegion io;
 } M48t59SysBusState;
 
 /* Fake timer functions */
@@ -481,7 +483,8 @@ void m48t59_toggle_lock (void *opaque, int lock)
 }
 
 /* IO access to NVRAM */
-static void NVRAM_writeb (void *opaque, uint32_t addr, uint32_t val)
+static void NVRAM_writeb(void *opaque, target_phys_addr_t addr, uint64_t val,
+                         unsigned size)
 {
     M48t59State *NVRAM = opaque;
 
@@ -504,7 +507,7 @@ static void NVRAM_writeb (void *opaque, uint32_t addr, uint32_t val)
     }
 }
 
-static uint32_t NVRAM_readb (void *opaque, uint32_t addr)
+static uint64_t NVRAM_readb(void *opaque, target_phys_addr_t addr, unsigned size)
 {
     M48t59State *NVRAM = opaque;
     uint32_t retval;
@@ -626,13 +629,14 @@ static void m48t59_reset_sysbus(DeviceState *d)
     m48t59_reset_common(NVRAM);
 }
 
-static const MemoryRegionPortio m48t59_portio[] = {
-    {0, 4, 1, .read = NVRAM_readb, .write = NVRAM_writeb },
-    PORTIO_END_OF_LIST(),
-};
-
 static const MemoryRegionOps m48t59_io_ops = {
-    .old_portio = m48t59_portio,
+    .read = NVRAM_readb,
+    .write = NVRAM_writeb,
+    .impl = {
+        .min_access_size = 1,
+        .max_access_size = 1,
+    },
+    .endianness = DEVICE_LITTLE_ENDIAN,
 };
 
 /* Initialisation routine */
@@ -653,9 +657,9 @@ M48t59State *m48t59_init(qemu_irq IRQ, target_phys_addr_t mem_base,
     d = FROM_SYSBUS(M48t59SysBusState, s);
     state = &d->state;
     sysbus_connect_irq(s, 0, IRQ);
+    memory_region_init_io(&d->io, &m48t59_io_ops, state, "m48t59", 4);
     if (io_base != 0) {
-        register_ioport_read(io_base, 0x04, 1, NVRAM_readb, state);
-        register_ioport_write(io_base, 0x04, 1, NVRAM_writeb, state);
+        memory_region_add_subregion(get_system_io(), io_base, &d->io);
     }
     if (mem_base != 0) {
         sysbus_mmio_map(s, 0, mem_base);
-- 
1.6.0.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 12:24:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 12:24:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLCNe-0000YR-2U; Mon, 08 Oct 2012 12:24:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLCNc-0000Wt-6S
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 12:24:16 +0000
Received: from [85.158.138.51:10099] by server-10.bemta-3.messagelabs.com id
	0B/D7-02525-FE5C2705; Mon, 08 Oct 2012 12:24:15 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-6.tower-174.messagelabs.com!1349699054!25480236!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21323 invoked from network); 8 Oct 2012 12:24:15 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 12:24:15 -0000
Received: from relay1.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id CD5CDA0FF5;
	Mon,  8 Oct 2012 14:24:14 +0200 (CEST)
From: Alexander Graf 
To: qemu-devel qemu-devel 
Date: Mon,  8 Oct 2012 14:23:52 +0200
Message-Id: <1349699033-6703-14-git-send-email-agraf@suse.de>
X-Mailer: git-send-email 1.6.0.2
In-Reply-To: <1349699033-6703-1-git-send-email-agraf@suse.de>
References: <1349699033-6703-1-git-send-email-agraf@suse.de>
Cc: Anthony Liguori , xen-devel@lists.xensource.com,
	Stefano Stabellini ,
	"qemu-ppc@nongnu.org List" ,
	Avi Kivity ,
	Scott Wood , malc ,
	David Gibson 
Subject: [Xen-devel] [PATCH 13/14] PPC: e500: Map PIO space into core memory
	region
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On PPC, we don't have PIO. So usually PIO space behind a PCI bridge is
accessible via MMIO. Do this mapping explicitly by mapping the PIO space
of our PCI bus into a memory region that lives in memory space.

Signed-off-by: Alexander Graf 
---
 hw/ppc/e500.c    |    3 +--
 hw/ppce500_pci.c |    9 +++++++--
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/hw/ppc/e500.c b/hw/ppc/e500.c
index d23f9b2..857d4dc 100644
--- a/hw/ppc/e500.c
+++ b/hw/ppc/e500.c
@@ -52,7 +52,6 @@
 #define MPC8544_PCI_REGS_BASE      (MPC8544_CCSRBAR_BASE + 0x8000ULL)
 #define MPC8544_PCI_REGS_SIZE      0x1000ULL
 #define MPC8544_PCI_IO             0xE1000000ULL
-#define MPC8544_PCI_IOLEN          0x10000ULL
 #define MPC8544_UTIL_BASE          (MPC8544_CCSRBAR_BASE + 0xe0000ULL)
 #define MPC8544_SPIN_BASE          0xEF000000ULL
 
@@ -511,7 +510,7 @@ void ppce500_init(PPCE500Params *params)
     if (!pci_bus)
         printf("couldn't create PCI controller!\n");
 
-    isa_mmio_init(MPC8544_PCI_IO, MPC8544_PCI_IOLEN);
+    sysbus_mmio_map(sysbus_from_qdev(dev), 1, MPC8544_PCI_IO);
 
     if (pci_bus) {
         /* Register network interfaces. */
diff --git a/hw/ppce500_pci.c b/hw/ppce500_pci.c
index 92b1dc0..27c6d7d 100644
--- a/hw/ppce500_pci.c
+++ b/hw/ppce500_pci.c
@@ -31,6 +31,8 @@
 #define PCIE500_ALL_SIZE      0x1000
 #define PCIE500_REG_SIZE      (PCIE500_ALL_SIZE - PCIE500_REG_BASE)
 
+#define PCIE500_PCI_IOLEN     0x10000ULL
+
 #define PPCE500_PCI_CONFIG_ADDR         0x0
 #define PPCE500_PCI_CONFIG_DATA         0x4
 #define PPCE500_PCI_INTACK              0x8
@@ -87,6 +89,7 @@ struct PPCE500PCIState {
     /* mmio maps */
     MemoryRegion container;
     MemoryRegion iomem;
+    MemoryRegion pio;
 };
 
 typedef struct PPCE500PCIState PPCE500PCIState;
@@ -314,7 +317,6 @@ static int e500_pcihost_initfn(SysBusDevice *dev)
     PCIBus *b;
     int i;
     MemoryRegion *address_space_mem = get_system_memory();
-    MemoryRegion *address_space_io = get_system_io();
 
     h = PCI_HOST_BRIDGE(dev);
     s = PPC_E500_PCI_HOST_BRIDGE(dev);
@@ -323,9 +325,11 @@ static int e500_pcihost_initfn(SysBusDevice *dev)
         sysbus_init_irq(dev, &s->irq[i]);
     }
 
+    memory_region_init(&s->pio, "pci-pio", PCIE500_PCI_IOLEN);
+
     b = pci_register_bus(DEVICE(dev), NULL, mpc85xx_pci_set_irq,
                          mpc85xx_pci_map_irq, s->irq, address_space_mem,
-                         address_space_io, PCI_DEVFN(0x11, 0), 4);
+                         &s->pio, PCI_DEVFN(0x11, 0), 4);
     h->bus = b;
 
     pci_create_simple(b, 0, "e500-host-bridge");
@@ -341,6 +345,7 @@ static int e500_pcihost_initfn(SysBusDevice *dev)
     memory_region_add_subregion(&s->container, PCIE500_CFGDATA, &h->data_mem);
     memory_region_add_subregion(&s->container, PCIE500_REG_BASE, &s->iomem);
     sysbus_init_mmio(dev, &s->container);
+    sysbus_init_mmio(dev, &s->pio);
 
     return 0;
 }
-- 
1.6.0.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 12:24:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 12:24:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLCNe-0000YR-2U; Mon, 08 Oct 2012 12:24:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLCNc-0000Wt-6S
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 12:24:16 +0000
Received: from [85.158.138.51:10099] by server-10.bemta-3.messagelabs.com id
	0B/D7-02525-FE5C2705; Mon, 08 Oct 2012 12:24:15 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-6.tower-174.messagelabs.com!1349699054!25480236!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21323 invoked from network); 8 Oct 2012 12:24:15 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 12:24:15 -0000
Received: from relay1.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id CD5CDA0FF5;
	Mon,  8 Oct 2012 14:24:14 +0200 (CEST)
From: Alexander Graf 
To: qemu-devel qemu-devel 
Date: Mon,  8 Oct 2012 14:23:52 +0200
Message-Id: <1349699033-6703-14-git-send-email-agraf@suse.de>
X-Mailer: git-send-email 1.6.0.2
In-Reply-To: <1349699033-6703-1-git-send-email-agraf@suse.de>
References: <1349699033-6703-1-git-send-email-agraf@suse.de>
Cc: Anthony Liguori , xen-devel@lists.xensource.com,
	Stefano Stabellini ,
	"qemu-ppc@nongnu.org List" ,
	Avi Kivity ,
	Scott Wood , malc ,
	David Gibson 
Subject: [Xen-devel] [PATCH 13/14] PPC: e500: Map PIO space into core memory
	region
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On PPC, we don't have PIO. So usually PIO space behind a PCI bridge is
accessible via MMIO. Do this mapping explicitly by mapping the PIO space
of our PCI bus into a memory region that lives in memory space.

Signed-off-by: Alexander Graf 
---
 hw/ppc/e500.c    |    3 +--
 hw/ppce500_pci.c |    9 +++++++--
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/hw/ppc/e500.c b/hw/ppc/e500.c
index d23f9b2..857d4dc 100644
--- a/hw/ppc/e500.c
+++ b/hw/ppc/e500.c
@@ -52,7 +52,6 @@
 #define MPC8544_PCI_REGS_BASE      (MPC8544_CCSRBAR_BASE + 0x8000ULL)
 #define MPC8544_PCI_REGS_SIZE      0x1000ULL
 #define MPC8544_PCI_IO             0xE1000000ULL
-#define MPC8544_PCI_IOLEN          0x10000ULL
 #define MPC8544_UTIL_BASE          (MPC8544_CCSRBAR_BASE + 0xe0000ULL)
 #define MPC8544_SPIN_BASE          0xEF000000ULL
 
@@ -511,7 +510,7 @@ void ppce500_init(PPCE500Params *params)
     if (!pci_bus)
         printf("couldn't create PCI controller!\n");
 
-    isa_mmio_init(MPC8544_PCI_IO, MPC8544_PCI_IOLEN);
+    sysbus_mmio_map(sysbus_from_qdev(dev), 1, MPC8544_PCI_IO);
 
     if (pci_bus) {
         /* Register network interfaces. */
diff --git a/hw/ppce500_pci.c b/hw/ppce500_pci.c
index 92b1dc0..27c6d7d 100644
--- a/hw/ppce500_pci.c
+++ b/hw/ppce500_pci.c
@@ -31,6 +31,8 @@
 #define PCIE500_ALL_SIZE      0x1000
 #define PCIE500_REG_SIZE      (PCIE500_ALL_SIZE - PCIE500_REG_BASE)
 
+#define PCIE500_PCI_IOLEN     0x10000ULL
+
 #define PPCE500_PCI_CONFIG_ADDR         0x0
 #define PPCE500_PCI_CONFIG_DATA         0x4
 #define PPCE500_PCI_INTACK              0x8
@@ -87,6 +89,7 @@ struct PPCE500PCIState {
     /* mmio maps */
     MemoryRegion container;
     MemoryRegion iomem;
+    MemoryRegion pio;
 };
 
 typedef struct PPCE500PCIState PPCE500PCIState;
@@ -314,7 +317,6 @@ static int e500_pcihost_initfn(SysBusDevice *dev)
     PCIBus *b;
     int i;
     MemoryRegion *address_space_mem = get_system_memory();
-    MemoryRegion *address_space_io = get_system_io();
 
     h = PCI_HOST_BRIDGE(dev);
     s = PPC_E500_PCI_HOST_BRIDGE(dev);
@@ -323,9 +325,11 @@ static int e500_pcihost_initfn(SysBusDevice *dev)
         sysbus_init_irq(dev, &s->irq[i]);
     }
 
+    memory_region_init(&s->pio, "pci-pio", PCIE500_PCI_IOLEN);
+
     b = pci_register_bus(DEVICE(dev), NULL, mpc85xx_pci_set_irq,
                          mpc85xx_pci_map_irq, s->irq, address_space_mem,
-                         address_space_io, PCI_DEVFN(0x11, 0), 4);
+                         &s->pio, PCI_DEVFN(0x11, 0), 4);
     h->bus = b;
 
     pci_create_simple(b, 0, "e500-host-bridge");
@@ -341,6 +345,7 @@ static int e500_pcihost_initfn(SysBusDevice *dev)
     memory_region_add_subregion(&s->container, PCIE500_CFGDATA, &h->data_mem);
     memory_region_add_subregion(&s->container, PCIE500_REG_BASE, &s->iomem);
     sysbus_init_mmio(dev, &s->container);
+    sysbus_init_mmio(dev, &s->pio);
 
     return 0;
 }
-- 
1.6.0.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 12:24:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 12:24:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLCNd-0000YC-NM; Mon, 08 Oct 2012 12:24:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLCNb-0000Wt-JW
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 12:24:15 +0000
Received: from [85.158.137.99:53706] by server-10.bemta-3.messagelabs.com id
	93/D7-02525-EE5C2705; Mon, 08 Oct 2012 12:24:14 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-2.tower-217.messagelabs.com!1349699052!20586903!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3229 invoked from network); 8 Oct 2012 12:24:12 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-2.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 12:24:12 -0000
Received: from relay1.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id 330F498E46;
	Mon,  8 Oct 2012 14:24:12 +0200 (CEST)
From: Alexander Graf 
To: qemu-devel qemu-devel 
Date: Mon,  8 Oct 2012 14:23:50 +0200
Message-Id: <1349699033-6703-12-git-send-email-agraf@suse.de>
X-Mailer: git-send-email 1.6.0.2
In-Reply-To: <1349699033-6703-1-git-send-email-agraf@suse.de>
References: <1349699033-6703-1-git-send-email-agraf@suse.de>
Cc: Anthony Liguori , xen-devel@lists.xensource.com,
	Stefano Stabellini ,
	"qemu-ppc@nongnu.org List" ,
	Avi Kivity ,
	Scott Wood , malc ,
	David Gibson 
Subject: [Xen-devel] [PATCH 11/14] vmport: convert PIO to new memory api
	read/write
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Alexander Graf 
---
 hw/vmport.c |   21 ++++++++++++---------
 1 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/hw/vmport.c b/hw/vmport.c
index a4f52ee..77dc8d6 100644
--- a/hw/vmport.c
+++ b/hw/vmport.c
@@ -54,7 +54,8 @@ void vmport_register(unsigned char command, IOPortReadFunc *func, void *opaque)
     port_state->opaque[command] = opaque;
 }
 
-static uint32_t vmport_ioport_read(void *opaque, uint32_t addr)
+static uint64_t vmport_ioport_read(void *opaque, target_phys_addr_t addr,
+                                   unsigned size)
 {
     VMPortState *s = opaque;
     CPUX86State *env = cpu_single_env;
@@ -81,11 +82,12 @@ static uint32_t vmport_ioport_read(void *opaque, uint32_t addr)
     return s->func[command](s->opaque[command], addr);
 }
 
-static void vmport_ioport_write(void *opaque, uint32_t addr, uint32_t val)
+static void vmport_ioport_write(void *opaque, target_phys_addr_t addr,
+                                uint64_t val, unsigned size)
 {
     CPUX86State *env = cpu_single_env;
 
-    env->regs[R_EAX] = vmport_ioport_read(opaque, addr);
+    env->regs[R_EAX] = vmport_ioport_read(opaque, addr, 4);
 }
 
 static uint32_t vmport_cmd_get_version(void *opaque, uint32_t addr)
@@ -121,13 +123,14 @@ void vmmouse_set_data(const uint32_t *data)
     env->regs[R_ESI] = data[4]; env->regs[R_EDI] = data[5];
 }
 
-static const MemoryRegionPortio vmport_portio[] = {
-    {0, 1, 4, .read = vmport_ioport_read, .write = vmport_ioport_write },
-    PORTIO_END_OF_LIST(),
-};
-
 static const MemoryRegionOps vmport_ops = {
-    .old_portio = vmport_portio
+    .read = vmport_ioport_read,
+    .write = vmport_ioport_write,
+    .impl = {
+        .min_access_size = 4,
+        .max_access_size = 4,
+    },
+    .endianness = DEVICE_LITTLE_ENDIAN,
 };
 
 static int vmport_initfn(ISADevice *dev)
-- 
1.6.0.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 12:24:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 12:24:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLCNd-0000YC-NM; Mon, 08 Oct 2012 12:24:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLCNb-0000Wt-JW
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 12:24:15 +0000
Received: from [85.158.137.99:53706] by server-10.bemta-3.messagelabs.com id
	93/D7-02525-EE5C2705; Mon, 08 Oct 2012 12:24:14 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-2.tower-217.messagelabs.com!1349699052!20586903!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3229 invoked from network); 8 Oct 2012 12:24:12 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-2.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 12:24:12 -0000
Received: from relay1.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id 330F498E46;
	Mon,  8 Oct 2012 14:24:12 +0200 (CEST)
From: Alexander Graf 
To: qemu-devel qemu-devel 
Date: Mon,  8 Oct 2012 14:23:50 +0200
Message-Id: <1349699033-6703-12-git-send-email-agraf@suse.de>
X-Mailer: git-send-email 1.6.0.2
In-Reply-To: <1349699033-6703-1-git-send-email-agraf@suse.de>
References: <1349699033-6703-1-git-send-email-agraf@suse.de>
Cc: Anthony Liguori , xen-devel@lists.xensource.com,
	Stefano Stabellini ,
	"qemu-ppc@nongnu.org List" ,
	Avi Kivity ,
	Scott Wood , malc ,
	David Gibson 
Subject: [Xen-devel] [PATCH 11/14] vmport: convert PIO to new memory api
	read/write
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Alexander Graf 
---
 hw/vmport.c |   21 ++++++++++++---------
 1 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/hw/vmport.c b/hw/vmport.c
index a4f52ee..77dc8d6 100644
--- a/hw/vmport.c
+++ b/hw/vmport.c
@@ -54,7 +54,8 @@ void vmport_register(unsigned char command, IOPortReadFunc *func, void *opaque)
     port_state->opaque[command] = opaque;
 }
 
-static uint32_t vmport_ioport_read(void *opaque, uint32_t addr)
+static uint64_t vmport_ioport_read(void *opaque, target_phys_addr_t addr,
+                                   unsigned size)
 {
     VMPortState *s = opaque;
     CPUX86State *env = cpu_single_env;
@@ -81,11 +82,12 @@ static uint32_t vmport_ioport_read(void *opaque, uint32_t addr)
     return s->func[command](s->opaque[command], addr);
 }
 
-static void vmport_ioport_write(void *opaque, uint32_t addr, uint32_t val)
+static void vmport_ioport_write(void *opaque, target_phys_addr_t addr,
+                                uint64_t val, unsigned size)
 {
     CPUX86State *env = cpu_single_env;
 
-    env->regs[R_EAX] = vmport_ioport_read(opaque, addr);
+    env->regs[R_EAX] = vmport_ioport_read(opaque, addr, 4);
 }
 
 static uint32_t vmport_cmd_get_version(void *opaque, uint32_t addr)
@@ -121,13 +123,14 @@ void vmmouse_set_data(const uint32_t *data)
     env->regs[R_ESI] = data[4]; env->regs[R_EDI] = data[5];
 }
 
-static const MemoryRegionPortio vmport_portio[] = {
-    {0, 1, 4, .read = vmport_ioport_read, .write = vmport_ioport_write },
-    PORTIO_END_OF_LIST(),
-};
-
 static const MemoryRegionOps vmport_ops = {
-    .old_portio = vmport_portio
+    .read = vmport_ioport_read,
+    .write = vmport_ioport_write,
+    .impl = {
+        .min_access_size = 4,
+        .max_access_size = 4,
+    },
+    .endianness = DEVICE_LITTLE_ENDIAN,
 };
 
 static int vmport_initfn(ISADevice *dev)
-- 
1.6.0.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 12:24:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 12:24:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLCNk-0000cp-Ep; Mon, 08 Oct 2012 12:24:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLCNi-0000Xr-CX
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 12:24:22 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-14.tower-27.messagelabs.com!1349699056!2010409!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1876 invoked from network); 8 Oct 2012 12:24:16 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 12:24:16 -0000
Received: from relay2.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id 0B82C98E46;
	Mon,  8 Oct 2012 14:24:16 +0200 (CEST)
From: Alexander Graf 
To: qemu-devel qemu-devel 
Date: Mon,  8 Oct 2012 14:23:53 +0200
Message-Id: <1349699033-6703-15-git-send-email-agraf@suse.de>
X-Mailer: git-send-email 1.6.0.2
In-Reply-To: <1349699033-6703-1-git-send-email-agraf@suse.de>
References: <1349699033-6703-1-git-send-email-agraf@suse.de>
Cc: Anthony Liguori , xen-devel@lists.xensource.com,
	Stefano Stabellini ,
	"qemu-ppc@nongnu.org List" ,
	Avi Kivity ,
	Scott Wood , malc ,
	David Gibson 
Subject: [Xen-devel] [PATCH 14/14] PPC: pseries: Remove hack for PIO window
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Now that all users of old_portio are gone, we can remove the hack
that enabled us to support them.

Signed-off-by: Alexander Graf 
---
 hw/spapr_pci.c |   44 +-------------------------------------------
 hw/spapr_pci.h |    2 +-
 2 files changed, 2 insertions(+), 44 deletions(-)

diff --git a/hw/spapr_pci.c b/hw/spapr_pci.c
index b628f89..0128f3e 100644
--- a/hw/spapr_pci.c
+++ b/hw/spapr_pci.c
@@ -439,43 +439,6 @@ static void pci_spapr_set_irq(void *opaque, int irq_num, int level)
     qemu_set_irq(spapr_phb_lsi_qirq(phb, irq_num), level);
 }
 
-static uint64_t spapr_io_read(void *opaque, target_phys_addr_t addr,
-                              unsigned size)
-{
-    switch (size) {
-    case 1:
-        return cpu_inb(addr);
-    case 2:
-        return cpu_inw(addr);
-    case 4:
-        return cpu_inl(addr);
-    }
-    assert(0);
-}
-
-static void spapr_io_write(void *opaque, target_phys_addr_t addr,
-                           uint64_t data, unsigned size)
-{
-    switch (size) {
-    case 1:
-        cpu_outb(addr, data);
-        return;
-    case 2:
-        cpu_outw(addr, data);
-        return;
-    case 4:
-        cpu_outl(addr, data);
-        return;
-    }
-    assert(0);
-}
-
-static const MemoryRegionOps spapr_io_ops = {
-    .endianness = DEVICE_LITTLE_ENDIAN,
-    .read = spapr_io_read,
-    .write = spapr_io_write
-};
-
 /*
  * MSI/MSIX memory region implementation.
  * The handler handles both MSI and MSIX.
@@ -545,14 +508,9 @@ static int spapr_phb_init(SysBusDevice *s)
      * old_portion are updated */
     sprintf(namebuf, "%s.io", sphb->dtbusname);
     memory_region_init(&sphb->iospace, namebuf, SPAPR_PCI_IO_WIN_SIZE);
-    /* FIXME: fix to support multiple PHBs */
-    memory_region_add_subregion(get_system_io(), 0, &sphb->iospace);
 
-    sprintf(namebuf, "%s.io-alias", sphb->dtbusname);
-    memory_region_init_io(&sphb->iowindow, &spapr_io_ops, sphb,
-                          namebuf, SPAPR_PCI_IO_WIN_SIZE);
     memory_region_add_subregion(get_system_memory(), sphb->io_win_addr,
-                                &sphb->iowindow);
+                                &sphb->iospace);
 
     /* As MSI/MSIX interrupts trigger by writing at MSI/MSIX vectors,
      * we need to allocate some memory to catch those writes coming
diff --git a/hw/spapr_pci.h b/hw/spapr_pci.h
index 670dc62..02163a7 100644
--- a/hw/spapr_pci.h
+++ b/hw/spapr_pci.h
@@ -44,7 +44,7 @@ typedef struct sPAPRPHBState {
     MemoryRegion memspace, iospace;
     target_phys_addr_t mem_win_addr, mem_win_size, io_win_addr, io_win_size;
     target_phys_addr_t msi_win_addr;
-    MemoryRegion memwindow, iowindow, msiwindow;
+    MemoryRegion memwindow, msiwindow;
 
     uint32_t dma_liobn;
     uint64_t dma_window_start;
-- 
1.6.0.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 12:24:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 12:24:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLCNk-0000cp-Ep; Mon, 08 Oct 2012 12:24:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLCNi-0000Xr-CX
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 12:24:22 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-14.tower-27.messagelabs.com!1349699056!2010409!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1876 invoked from network); 8 Oct 2012 12:24:16 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 12:24:16 -0000
Received: from relay2.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id 0B82C98E46;
	Mon,  8 Oct 2012 14:24:16 +0200 (CEST)
From: Alexander Graf 
To: qemu-devel qemu-devel 
Date: Mon,  8 Oct 2012 14:23:53 +0200
Message-Id: <1349699033-6703-15-git-send-email-agraf@suse.de>
X-Mailer: git-send-email 1.6.0.2
In-Reply-To: <1349699033-6703-1-git-send-email-agraf@suse.de>
References: <1349699033-6703-1-git-send-email-agraf@suse.de>
Cc: Anthony Liguori , xen-devel@lists.xensource.com,
	Stefano Stabellini ,
	"qemu-ppc@nongnu.org List" ,
	Avi Kivity ,
	Scott Wood , malc ,
	David Gibson 
Subject: [Xen-devel] [PATCH 14/14] PPC: pseries: Remove hack for PIO window
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Now that all users of old_portio are gone, we can remove the hack
that enabled us to support them.

Signed-off-by: Alexander Graf 
---
 hw/spapr_pci.c |   44 +-------------------------------------------
 hw/spapr_pci.h |    2 +-
 2 files changed, 2 insertions(+), 44 deletions(-)

diff --git a/hw/spapr_pci.c b/hw/spapr_pci.c
index b628f89..0128f3e 100644
--- a/hw/spapr_pci.c
+++ b/hw/spapr_pci.c
@@ -439,43 +439,6 @@ static void pci_spapr_set_irq(void *opaque, int irq_num, int level)
     qemu_set_irq(spapr_phb_lsi_qirq(phb, irq_num), level);
 }
 
-static uint64_t spapr_io_read(void *opaque, target_phys_addr_t addr,
-                              unsigned size)
-{
-    switch (size) {
-    case 1:
-        return cpu_inb(addr);
-    case 2:
-        return cpu_inw(addr);
-    case 4:
-        return cpu_inl(addr);
-    }
-    assert(0);
-}
-
-static void spapr_io_write(void *opaque, target_phys_addr_t addr,
-                           uint64_t data, unsigned size)
-{
-    switch (size) {
-    case 1:
-        cpu_outb(addr, data);
-        return;
-    case 2:
-        cpu_outw(addr, data);
-        return;
-    case 4:
-        cpu_outl(addr, data);
-        return;
-    }
-    assert(0);
-}
-
-static const MemoryRegionOps spapr_io_ops = {
-    .endianness = DEVICE_LITTLE_ENDIAN,
-    .read = spapr_io_read,
-    .write = spapr_io_write
-};
-
 /*
  * MSI/MSIX memory region implementation.
  * The handler handles both MSI and MSIX.
@@ -545,14 +508,9 @@ static int spapr_phb_init(SysBusDevice *s)
      * old_portion are updated */
     sprintf(namebuf, "%s.io", sphb->dtbusname);
     memory_region_init(&sphb->iospace, namebuf, SPAPR_PCI_IO_WIN_SIZE);
-    /* FIXME: fix to support multiple PHBs */
-    memory_region_add_subregion(get_system_io(), 0, &sphb->iospace);
 
-    sprintf(namebuf, "%s.io-alias", sphb->dtbusname);
-    memory_region_init_io(&sphb->iowindow, &spapr_io_ops, sphb,
-                          namebuf, SPAPR_PCI_IO_WIN_SIZE);
     memory_region_add_subregion(get_system_memory(), sphb->io_win_addr,
-                                &sphb->iowindow);
+                                &sphb->iospace);
 
     /* As MSI/MSIX interrupts trigger by writing at MSI/MSIX vectors,
      * we need to allocate some memory to catch those writes coming
diff --git a/hw/spapr_pci.h b/hw/spapr_pci.h
index 670dc62..02163a7 100644
--- a/hw/spapr_pci.h
+++ b/hw/spapr_pci.h
@@ -44,7 +44,7 @@ typedef struct sPAPRPHBState {
     MemoryRegion memspace, iospace;
     target_phys_addr_t mem_win_addr, mem_win_size, io_win_addr, io_win_size;
     target_phys_addr_t msi_win_addr;
-    MemoryRegion memwindow, iowindow, msiwindow;
+    MemoryRegion memwindow, msiwindow;
 
     uint32_t dma_liobn;
     uint64_t dma_window_start;
-- 
1.6.0.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 12:24:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 12:24:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLCNd-0000Xx-AZ; Mon, 08 Oct 2012 12:24:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLCNa-0000WS-TM
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 12:24:15 +0000
Received: from [85.158.139.83:34387] by server-5.bemta-5.messagelabs.com id
	05/FE-21075-EE5C2705; Mon, 08 Oct 2012 12:24:14 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-16.tower-182.messagelabs.com!1349699053!26550931!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3908 invoked from network); 8 Oct 2012 12:24:13 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Oct 2012 12:24:13 -0000
Received: from relay2.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id 58E05A0FED;
	Mon,  8 Oct 2012 14:24:13 +0200 (CEST)
From: Alexander Graf 
To: qemu-devel qemu-devel 
Date: Mon,  8 Oct 2012 14:23:51 +0200
Message-Id: <1349699033-6703-13-git-send-email-agraf@suse.de>
X-Mailer: git-send-email 1.6.0.2
In-Reply-To: <1349699033-6703-1-git-send-email-agraf@suse.de>
References: <1349699033-6703-1-git-send-email-agraf@suse.de>
Cc: Anthony Liguori , xen-devel@lists.xensource.com,
	Stefano Stabellini ,
	"qemu-ppc@nongnu.org List" ,
	Avi Kivity ,
	Scott Wood , malc ,
	David Gibson 
Subject: [Xen-devel] [PATCH 12/14] xen_platform: convert PIO to new memory
	api read/write
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Alexander Graf 
---
 hw/xen_platform.c |   48 ++++++++++++++++++++++++++++++++++++++----------
 1 files changed, 38 insertions(+), 10 deletions(-)

diff --git a/hw/xen_platform.c b/hw/xen_platform.c
index 956dbfe..171f8ff 100644
--- a/hw/xen_platform.c
+++ b/hw/xen_platform.c
@@ -228,18 +228,46 @@ static void platform_fixed_ioport_reset(void *opaque)
     platform_fixed_ioport_writeb(s, 0, 0);
 }
 
-const MemoryRegionPortio xen_platform_ioport[] = {
-    { 0, 16, 4, .write = platform_fixed_ioport_writel, },
-    { 0, 16, 2, .write = platform_fixed_ioport_writew, },
-    { 0, 16, 1, .write = platform_fixed_ioport_writeb, },
-    { 0, 16, 2, .read = platform_fixed_ioport_readw, },
-    { 0, 16, 1, .read = platform_fixed_ioport_readb, },
-    PORTIO_END_OF_LIST()
-};
+static uint64_t platform_fixed_ioport_read(void *opaque,
+                                           target_phys_addr_t addr,
+                                           unsigned size)
+{
+    switch (size) {
+    case 1:
+        return platform_fixed_ioport_readb(opaque, addr);
+    case 2:
+        return platform_fixed_ioport_readw(opaque, addr);
+    default:
+        return -1;
+    }
+}
+
+static void platform_fixed_ioport_write(void *opaque, target_phys_addr_t addr,
+
+                                        uint64_t val, unsigned size)
+{
+    switch (size) {
+    case 1:
+        platform_fixed_ioport_writeb(opaque, addr, val);
+        break;
+    case 2:
+        platform_fixed_ioport_writew(opaque, addr, val);
+        break;
+    case 4:
+        platform_fixed_ioport_writel(opaque, addr, val);
+        break;
+    }
+}
+
 
 static const MemoryRegionOps platform_fixed_io_ops = {
-    .old_portio = xen_platform_ioport,
-    .endianness = DEVICE_NATIVE_ENDIAN,
+    .read = platform_fixed_ioport_read,
+    .write = platform_fixed_ioport_write,
+    .impl = {
+        .min_access_size = 1,
+        .max_access_size = 4,
+    },
+    .endianness = DEVICE_LITTLE_ENDIAN,
 };
 
 static void platform_fixed_ioport_init(PCIXenPlatformState* s)
-- 
1.6.0.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 12:24:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 12:24:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLCNd-0000Xx-AZ; Mon, 08 Oct 2012 12:24:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLCNa-0000WS-TM
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 12:24:15 +0000
Received: from [85.158.139.83:34387] by server-5.bemta-5.messagelabs.com id
	05/FE-21075-EE5C2705; Mon, 08 Oct 2012 12:24:14 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-16.tower-182.messagelabs.com!1349699053!26550931!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3908 invoked from network); 8 Oct 2012 12:24:13 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Oct 2012 12:24:13 -0000
Received: from relay2.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id 58E05A0FED;
	Mon,  8 Oct 2012 14:24:13 +0200 (CEST)
From: Alexander Graf 
To: qemu-devel qemu-devel 
Date: Mon,  8 Oct 2012 14:23:51 +0200
Message-Id: <1349699033-6703-13-git-send-email-agraf@suse.de>
X-Mailer: git-send-email 1.6.0.2
In-Reply-To: <1349699033-6703-1-git-send-email-agraf@suse.de>
References: <1349699033-6703-1-git-send-email-agraf@suse.de>
Cc: Anthony Liguori , xen-devel@lists.xensource.com,
	Stefano Stabellini ,
	"qemu-ppc@nongnu.org List" ,
	Avi Kivity ,
	Scott Wood , malc ,
	David Gibson 
Subject: [Xen-devel] [PATCH 12/14] xen_platform: convert PIO to new memory
	api read/write
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Alexander Graf 
---
 hw/xen_platform.c |   48 ++++++++++++++++++++++++++++++++++++++----------
 1 files changed, 38 insertions(+), 10 deletions(-)

diff --git a/hw/xen_platform.c b/hw/xen_platform.c
index 956dbfe..171f8ff 100644
--- a/hw/xen_platform.c
+++ b/hw/xen_platform.c
@@ -228,18 +228,46 @@ static void platform_fixed_ioport_reset(void *opaque)
     platform_fixed_ioport_writeb(s, 0, 0);
 }
 
-const MemoryRegionPortio xen_platform_ioport[] = {
-    { 0, 16, 4, .write = platform_fixed_ioport_writel, },
-    { 0, 16, 2, .write = platform_fixed_ioport_writew, },
-    { 0, 16, 1, .write = platform_fixed_ioport_writeb, },
-    { 0, 16, 2, .read = platform_fixed_ioport_readw, },
-    { 0, 16, 1, .read = platform_fixed_ioport_readb, },
-    PORTIO_END_OF_LIST()
-};
+static uint64_t platform_fixed_ioport_read(void *opaque,
+                                           target_phys_addr_t addr,
+                                           unsigned size)
+{
+    switch (size) {
+    case 1:
+        return platform_fixed_ioport_readb(opaque, addr);
+    case 2:
+        return platform_fixed_ioport_readw(opaque, addr);
+    default:
+        return -1;
+    }
+}
+
+static void platform_fixed_ioport_write(void *opaque, target_phys_addr_t addr,
+
+                                        uint64_t val, unsigned size)
+{
+    switch (size) {
+    case 1:
+        platform_fixed_ioport_writeb(opaque, addr, val);
+        break;
+    case 2:
+        platform_fixed_ioport_writew(opaque, addr, val);
+        break;
+    case 4:
+        platform_fixed_ioport_writel(opaque, addr, val);
+        break;
+    }
+}
+
 
 static const MemoryRegionOps platform_fixed_io_ops = {
-    .old_portio = xen_platform_ioport,
-    .endianness = DEVICE_NATIVE_ENDIAN,
+    .read = platform_fixed_ioport_read,
+    .write = platform_fixed_ioport_write,
+    .impl = {
+        .min_access_size = 1,
+        .max_access_size = 4,
+    },
+    .endianness = DEVICE_LITTLE_ENDIAN,
 };
 
 static void platform_fixed_ioport_init(PCIXenPlatformState* s)
-- 
1.6.0.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 12:24:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 12:24:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLCNX-0000Uv-Gz; Mon, 08 Oct 2012 12:24:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLCNV-0000U0-U5
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 12:24:10 +0000
Received: from [85.158.137.99:23152] by server-4.bemta-3.messagelabs.com id
	D3/EA-14155-8E5C2705; Mon, 08 Oct 2012 12:24:08 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-12.tower-217.messagelabs.com!1349699048!17579362!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9502 invoked from network); 8 Oct 2012 12:24:08 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-12.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Oct 2012 12:24:08 -0000
Received: from relay2.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id 3A63998E46;
	Mon,  8 Oct 2012 14:24:08 +0200 (CEST)
From: Alexander Graf 
To: qemu-devel qemu-devel 
Date: Mon,  8 Oct 2012 14:23:47 +0200
Message-Id: <1349699033-6703-9-git-send-email-agraf@suse.de>
X-Mailer: git-send-email 1.6.0.2
In-Reply-To: <1349699033-6703-1-git-send-email-agraf@suse.de>
References: <1349699033-6703-1-git-send-email-agraf@suse.de>
Cc: Anthony Liguori , xen-devel@lists.xensource.com,
	Stefano Stabellini ,
	"qemu-ppc@nongnu.org List" ,
	Avi Kivity ,
	Scott Wood , malc ,
	David Gibson 
Subject: [Xen-devel] [PATCH 08/14] pckbd: convert PIO to new memory api
	read/write
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Alexander Graf 
---
 hw/pckbd.c |   48 +++++++++++++++++++++++++++---------------------
 1 files changed, 27 insertions(+), 21 deletions(-)

diff --git a/hw/pckbd.c b/hw/pckbd.c
index 69857ba..2c78f7d 100644
--- a/hw/pckbd.c
+++ b/hw/pckbd.c
@@ -194,7 +194,8 @@ static void kbd_update_aux_irq(void *opaque, int level)
     kbd_update_irq(s);
 }
 
-static uint32_t kbd_read_status(void *opaque, uint32_t addr)
+static uint64_t kbd_read_status(void *opaque, target_phys_addr_t addr,
+                                unsigned size)
 {
     KBDState *s = opaque;
     int val;
@@ -223,7 +224,8 @@ static void outport_write(KBDState *s, uint32_t val)
     }
 }
 
-static void kbd_write_command(void *opaque, uint32_t addr, uint32_t val)
+static void kbd_write_command(void *opaque, target_phys_addr_t addr,
+                              uint64_t val, unsigned size)
 {
     KBDState *s = opaque;
 
@@ -303,12 +305,13 @@ static void kbd_write_command(void *opaque, uint32_t addr, uint32_t val)
         /* ignore that */
         break;
     default:
-        fprintf(stderr, "qemu: unsupported keyboard cmd=0x%02x\n", val);
+        fprintf(stderr, "qemu: unsupported keyboard cmd=0x%02x\n", (int)val);
         break;
     }
 }
 
-static uint32_t kbd_read_data(void *opaque, uint32_t addr)
+static uint64_t kbd_read_data(void *opaque, target_phys_addr_t addr,
+                              unsigned size)
 {
     KBDState *s = opaque;
     uint32_t val;
@@ -322,7 +325,8 @@ static uint32_t kbd_read_data(void *opaque, uint32_t addr)
     return val;
 }
 
-static void kbd_write_data(void *opaque, uint32_t addr, uint32_t val)
+static void kbd_write_data(void *opaque, target_phys_addr_t addr,
+                           uint64_t val, unsigned size)
 {
     KBDState *s = opaque;
 
@@ -385,9 +389,9 @@ static uint32_t kbd_mm_readb (void *opaque, target_phys_addr_t addr)
     KBDState *s = opaque;
 
     if (addr & s->mask)
-        return kbd_read_status(s, 0) & 0xff;
+        return kbd_read_status(s, 0, 1) & 0xff;
     else
-        return kbd_read_data(s, 0) & 0xff;
+        return kbd_read_data(s, 0, 1) & 0xff;
 }
 
 static void kbd_mm_writeb (void *opaque, target_phys_addr_t addr, uint32_t value)
@@ -395,9 +399,9 @@ static void kbd_mm_writeb (void *opaque, target_phys_addr_t addr, uint32_t value
     KBDState *s = opaque;
 
     if (addr & s->mask)
-        kbd_write_command(s, 0, value & 0xff);
+        kbd_write_command(s, 0, value & 0xff, 1);
     else
-        kbd_write_data(s, 0, value & 0xff);
+        kbd_write_data(s, 0, value & 0xff, 1);
 }
 
 static const MemoryRegionOps i8042_mmio_ops = {
@@ -459,22 +463,24 @@ static const VMStateDescription vmstate_kbd_isa = {
     }
 };
 
-static const MemoryRegionPortio i8042_data_portio[] = {
-    { 0, 1, 1, .read = kbd_read_data, .write = kbd_write_data },
-    PORTIO_END_OF_LIST()
-};
-
-static const MemoryRegionPortio i8042_cmd_portio[] = {
-    { 0, 1, 1, .read = kbd_read_status, .write = kbd_write_command },
-    PORTIO_END_OF_LIST()
-};
-
 static const MemoryRegionOps i8042_data_ops = {
-    .old_portio = i8042_data_portio
+    .read = kbd_read_data,
+    .write = kbd_write_data,
+    .impl = {
+        .min_access_size = 1,
+        .max_access_size = 1,
+    },
+    .endianness = DEVICE_LITTLE_ENDIAN,
 };
 
 static const MemoryRegionOps i8042_cmd_ops = {
-    .old_portio = i8042_cmd_portio
+    .read = kbd_read_status,
+    .write = kbd_write_command,
+    .impl = {
+        .min_access_size = 1,
+        .max_access_size = 1,
+    },
+    .endianness = DEVICE_LITTLE_ENDIAN,
 };
 
 static int i8042_initfn(ISADevice *dev)
-- 
1.6.0.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 12:24:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 12:24:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLCNX-0000Uv-Gz; Mon, 08 Oct 2012 12:24:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLCNV-0000U0-U5
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 12:24:10 +0000
Received: from [85.158.137.99:23152] by server-4.bemta-3.messagelabs.com id
	D3/EA-14155-8E5C2705; Mon, 08 Oct 2012 12:24:08 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-12.tower-217.messagelabs.com!1349699048!17579362!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9502 invoked from network); 8 Oct 2012 12:24:08 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-12.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Oct 2012 12:24:08 -0000
Received: from relay2.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id 3A63998E46;
	Mon,  8 Oct 2012 14:24:08 +0200 (CEST)
From: Alexander Graf 
To: qemu-devel qemu-devel 
Date: Mon,  8 Oct 2012 14:23:47 +0200
Message-Id: <1349699033-6703-9-git-send-email-agraf@suse.de>
X-Mailer: git-send-email 1.6.0.2
In-Reply-To: <1349699033-6703-1-git-send-email-agraf@suse.de>
References: <1349699033-6703-1-git-send-email-agraf@suse.de>
Cc: Anthony Liguori , xen-devel@lists.xensource.com,
	Stefano Stabellini ,
	"qemu-ppc@nongnu.org List" ,
	Avi Kivity ,
	Scott Wood , malc ,
	David Gibson 
Subject: [Xen-devel] [PATCH 08/14] pckbd: convert PIO to new memory api
	read/write
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Alexander Graf 
---
 hw/pckbd.c |   48 +++++++++++++++++++++++++++---------------------
 1 files changed, 27 insertions(+), 21 deletions(-)

diff --git a/hw/pckbd.c b/hw/pckbd.c
index 69857ba..2c78f7d 100644
--- a/hw/pckbd.c
+++ b/hw/pckbd.c
@@ -194,7 +194,8 @@ static void kbd_update_aux_irq(void *opaque, int level)
     kbd_update_irq(s);
 }
 
-static uint32_t kbd_read_status(void *opaque, uint32_t addr)
+static uint64_t kbd_read_status(void *opaque, target_phys_addr_t addr,
+                                unsigned size)
 {
     KBDState *s = opaque;
     int val;
@@ -223,7 +224,8 @@ static void outport_write(KBDState *s, uint32_t val)
     }
 }
 
-static void kbd_write_command(void *opaque, uint32_t addr, uint32_t val)
+static void kbd_write_command(void *opaque, target_phys_addr_t addr,
+                              uint64_t val, unsigned size)
 {
     KBDState *s = opaque;
 
@@ -303,12 +305,13 @@ static void kbd_write_command(void *opaque, uint32_t addr, uint32_t val)
         /* ignore that */
         break;
     default:
-        fprintf(stderr, "qemu: unsupported keyboard cmd=0x%02x\n", val);
+        fprintf(stderr, "qemu: unsupported keyboard cmd=0x%02x\n", (int)val);
         break;
     }
 }
 
-static uint32_t kbd_read_data(void *opaque, uint32_t addr)
+static uint64_t kbd_read_data(void *opaque, target_phys_addr_t addr,
+                              unsigned size)
 {
     KBDState *s = opaque;
     uint32_t val;
@@ -322,7 +325,8 @@ static uint32_t kbd_read_data(void *opaque, uint32_t addr)
     return val;
 }
 
-static void kbd_write_data(void *opaque, uint32_t addr, uint32_t val)
+static void kbd_write_data(void *opaque, target_phys_addr_t addr,
+                           uint64_t val, unsigned size)
 {
     KBDState *s = opaque;
 
@@ -385,9 +389,9 @@ static uint32_t kbd_mm_readb (void *opaque, target_phys_addr_t addr)
     KBDState *s = opaque;
 
     if (addr & s->mask)
-        return kbd_read_status(s, 0) & 0xff;
+        return kbd_read_status(s, 0, 1) & 0xff;
     else
-        return kbd_read_data(s, 0) & 0xff;
+        return kbd_read_data(s, 0, 1) & 0xff;
 }
 
 static void kbd_mm_writeb (void *opaque, target_phys_addr_t addr, uint32_t value)
@@ -395,9 +399,9 @@ static void kbd_mm_writeb (void *opaque, target_phys_addr_t addr, uint32_t value
     KBDState *s = opaque;
 
     if (addr & s->mask)
-        kbd_write_command(s, 0, value & 0xff);
+        kbd_write_command(s, 0, value & 0xff, 1);
     else
-        kbd_write_data(s, 0, value & 0xff);
+        kbd_write_data(s, 0, value & 0xff, 1);
 }
 
 static const MemoryRegionOps i8042_mmio_ops = {
@@ -459,22 +463,24 @@ static const VMStateDescription vmstate_kbd_isa = {
     }
 };
 
-static const MemoryRegionPortio i8042_data_portio[] = {
-    { 0, 1, 1, .read = kbd_read_data, .write = kbd_write_data },
-    PORTIO_END_OF_LIST()
-};
-
-static const MemoryRegionPortio i8042_cmd_portio[] = {
-    { 0, 1, 1, .read = kbd_read_status, .write = kbd_write_command },
-    PORTIO_END_OF_LIST()
-};
-
 static const MemoryRegionOps i8042_data_ops = {
-    .old_portio = i8042_data_portio
+    .read = kbd_read_data,
+    .write = kbd_write_data,
+    .impl = {
+        .min_access_size = 1,
+        .max_access_size = 1,
+    },
+    .endianness = DEVICE_LITTLE_ENDIAN,
 };
 
 static const MemoryRegionOps i8042_cmd_ops = {
-    .old_portio = i8042_cmd_portio
+    .read = kbd_read_status,
+    .write = kbd_write_command,
+    .impl = {
+        .min_access_size = 1,
+        .max_access_size = 1,
+    },
+    .endianness = DEVICE_LITTLE_ENDIAN,
 };
 
 static int i8042_initfn(ISADevice *dev)
-- 
1.6.0.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 12:24:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 12:24:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLCNS-0000TD-8P; Mon, 08 Oct 2012 12:24:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLCNQ-0000Sk-IW
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 12:24:04 +0000
Received: from [85.158.139.211:12319] by server-1.bemta-5.messagelabs.com id
	65/2E-09825-3E5C2705; Mon, 08 Oct 2012 12:24:03 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-14.tower-206.messagelabs.com!1349699043!21424200!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23847 invoked from network); 8 Oct 2012 12:24:03 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Oct 2012 12:24:03 -0000
Received: from relay1.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id AA7B498E46;
	Mon,  8 Oct 2012 14:23:57 +0200 (CEST)
From: Alexander Graf 
To: qemu-devel qemu-devel 
Date: Mon,  8 Oct 2012 14:23:39 +0200
Message-Id: <1349699033-6703-1-git-send-email-agraf@suse.de>
X-Mailer: git-send-email 1.6.0.2
Cc: Anthony Liguori , xen-devel@lists.xensource.com,
	Stefano Stabellini ,
	"qemu-ppc@nongnu.org List" ,
	Avi Kivity ,
	Scott Wood , malc ,
	David Gibson 
Subject: [Xen-devel] [PATCH 00/14] Remove old_portio users for memory region
	PIO mapping
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

When running on PowerPC, we don't have native PIO support. There are a few hacks
around to enable PIO access on PowerPC nevertheless.

The most typical one is the isa-mmio device. It takes MMIO requests and converts
them to PIO requests on the (QEMU internal) PIO bus.

This however is not how real hardware works and it limits us in the ability to
spawn eventfd's on PIO ports which doesn't work with this approach.  Instead,
let's model it more easily. Let's just map the PIO memory region into MMIO
space.

For this to work, we need to get rid of all old_portio struct users, as they
break with this approach. This is what this patch set does. It also converts
the e500 machines and sPAPR to the new memory region model.


Alex

Alexander Graf (14):
  ac97: convert PIO to new memory api read/write
  virtio-pci: convert PIO to new memory api read/write
  es1370: convert PIO to new memory api read/write
  i8254: convert PIO to new memory api read/write
  m48t59: convert PIO to new memory api read/write
  mc146818rtc: convert PIO to new memory api read/write
  pc port92: convert PIO to new memory api read/write
  pckbd: convert PIO to new memory api read/write
  rtl8139: convert PIO to new memory api read/write
  serial: convert PIO to new memory api read/write
  vmport: convert PIO to new memory api read/write
  xen_platform: convert PIO to new memory api read/write
  PPC: e500: Map PIO space into core memory region
  PPC: pseries: Remove hack for PIO window

 hw/ac97.c         |  109 +++++++++++++++++++++++++++++++++++++--------
 hw/es1370.c       |   46 +++++++++++++++----
 hw/i8254.c        |   20 +++++----
 hw/m48t59.c       |   24 ++++++----
 hw/mc146818rtc.c  |   19 +++++---
 hw/pc.c           |   19 +++++---
 hw/pckbd.c        |   48 +++++++++++---------
 hw/ppc/e500.c     |    3 +-
 hw/ppce500_pci.c  |    9 +++-
 hw/rtl8139.c      |   78 +++++++++++++++------------------
 hw/serial.c       |   31 ++++++++-----
 hw/spapr_pci.c    |   44 +------------------
 hw/spapr_pci.h    |    2 +-
 hw/virtio-pci.c   |  126 ++++++++++++++++++++--------------------------------
 hw/vmport.c       |   21 +++++----
 hw/xen_platform.c |   48 ++++++++++++++++----
 16 files changed, 362 insertions(+), 285 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 12:24:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 12:24:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLCNS-0000TD-8P; Mon, 08 Oct 2012 12:24:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLCNQ-0000Sk-IW
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 12:24:04 +0000
Received: from [85.158.139.211:12319] by server-1.bemta-5.messagelabs.com id
	65/2E-09825-3E5C2705; Mon, 08 Oct 2012 12:24:03 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-14.tower-206.messagelabs.com!1349699043!21424200!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23847 invoked from network); 8 Oct 2012 12:24:03 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Oct 2012 12:24:03 -0000
Received: from relay1.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id AA7B498E46;
	Mon,  8 Oct 2012 14:23:57 +0200 (CEST)
From: Alexander Graf 
To: qemu-devel qemu-devel 
Date: Mon,  8 Oct 2012 14:23:39 +0200
Message-Id: <1349699033-6703-1-git-send-email-agraf@suse.de>
X-Mailer: git-send-email 1.6.0.2
Cc: Anthony Liguori , xen-devel@lists.xensource.com,
	Stefano Stabellini ,
	"qemu-ppc@nongnu.org List" ,
	Avi Kivity ,
	Scott Wood , malc ,
	David Gibson 
Subject: [Xen-devel] [PATCH 00/14] Remove old_portio users for memory region
	PIO mapping
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

When running on PowerPC, we don't have native PIO support. There are a few hacks
around to enable PIO access on PowerPC nevertheless.

The most typical one is the isa-mmio device. It takes MMIO requests and converts
them to PIO requests on the (QEMU internal) PIO bus.

This however is not how real hardware works and it limits us in the ability to
spawn eventfd's on PIO ports which doesn't work with this approach.  Instead,
let's model it more easily. Let's just map the PIO memory region into MMIO
space.

For this to work, we need to get rid of all old_portio struct users, as they
break with this approach. This is what this patch set does. It also converts
the e500 machines and sPAPR to the new memory region model.


Alex

Alexander Graf (14):
  ac97: convert PIO to new memory api read/write
  virtio-pci: convert PIO to new memory api read/write
  es1370: convert PIO to new memory api read/write
  i8254: convert PIO to new memory api read/write
  m48t59: convert PIO to new memory api read/write
  mc146818rtc: convert PIO to new memory api read/write
  pc port92: convert PIO to new memory api read/write
  pckbd: convert PIO to new memory api read/write
  rtl8139: convert PIO to new memory api read/write
  serial: convert PIO to new memory api read/write
  vmport: convert PIO to new memory api read/write
  xen_platform: convert PIO to new memory api read/write
  PPC: e500: Map PIO space into core memory region
  PPC: pseries: Remove hack for PIO window

 hw/ac97.c         |  109 +++++++++++++++++++++++++++++++++++++--------
 hw/es1370.c       |   46 +++++++++++++++----
 hw/i8254.c        |   20 +++++----
 hw/m48t59.c       |   24 ++++++----
 hw/mc146818rtc.c  |   19 +++++---
 hw/pc.c           |   19 +++++---
 hw/pckbd.c        |   48 +++++++++++---------
 hw/ppc/e500.c     |    3 +-
 hw/ppce500_pci.c  |    9 +++-
 hw/rtl8139.c      |   78 +++++++++++++++------------------
 hw/serial.c       |   31 ++++++++-----
 hw/spapr_pci.c    |   44 +------------------
 hw/spapr_pci.h    |    2 +-
 hw/virtio-pci.c   |  126 ++++++++++++++++++++--------------------------------
 hw/vmport.c       |   21 +++++----
 hw/xen_platform.c |   48 ++++++++++++++++----
 16 files changed, 362 insertions(+), 285 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 12:24:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 12:24:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLCNZ-0000W6-UY; Mon, 08 Oct 2012 12:24:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLCNY-0000Ux-0L
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 12:24:12 +0000
Received: from [85.158.143.35:13852] by server-3.bemta-4.messagelabs.com id
	DF/84-10986-BE5C2705; Mon, 08 Oct 2012 12:24:11 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-8.tower-21.messagelabs.com!1349699049!14325899!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18068 invoked from network); 8 Oct 2012 12:24:10 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 12:24:10 -0000
Received: from relay1.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id 8CDEEA341E;
	Mon,  8 Oct 2012 14:24:09 +0200 (CEST)
From: Alexander Graf 
To: qemu-devel qemu-devel 
Date: Mon,  8 Oct 2012 14:23:48 +0200
Message-Id: <1349699033-6703-10-git-send-email-agraf@suse.de>
X-Mailer: git-send-email 1.6.0.2
In-Reply-To: <1349699033-6703-1-git-send-email-agraf@suse.de>
References: <1349699033-6703-1-git-send-email-agraf@suse.de>
Cc: Anthony Liguori , xen-devel@lists.xensource.com,
	Stefano Stabellini ,
	"qemu-ppc@nongnu.org List" ,
	Avi Kivity ,
	Scott Wood , malc ,
	David Gibson 
Subject: [Xen-devel] [PATCH 09/14] rtl8139: convert PIO to new memory api
	read/write
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Alexander Graf 
---
 hw/rtl8139.c |   78 ++++++++++++++++++++++++++-------------------------------
 1 files changed, 36 insertions(+), 42 deletions(-)

diff --git a/hw/rtl8139.c b/hw/rtl8139.c
index b7c82ee..6be6883 100644
--- a/hw/rtl8139.c
+++ b/hw/rtl8139.c
@@ -3186,38 +3186,6 @@ static uint32_t rtl8139_io_readl(void *opaque, uint8_t addr)
 
 /* */
 
-static void rtl8139_ioport_writeb(void *opaque, uint32_t addr, uint32_t val)
-{
-    rtl8139_io_writeb(opaque, addr & 0xFF, val);
-}
-
-static void rtl8139_ioport_writew(void *opaque, uint32_t addr, uint32_t val)
-{
-    rtl8139_io_writew(opaque, addr & 0xFF, val);
-}
-
-static void rtl8139_ioport_writel(void *opaque, uint32_t addr, uint32_t val)
-{
-    rtl8139_io_writel(opaque, addr & 0xFF, val);
-}
-
-static uint32_t rtl8139_ioport_readb(void *opaque, uint32_t addr)
-{
-    return rtl8139_io_readb(opaque, addr & 0xFF);
-}
-
-static uint32_t rtl8139_ioport_readw(void *opaque, uint32_t addr)
-{
-    return rtl8139_io_readw(opaque, addr & 0xFF);
-}
-
-static uint32_t rtl8139_ioport_readl(void *opaque, uint32_t addr)
-{
-    return rtl8139_io_readl(opaque, addr & 0xFF);
-}
-
-/* */
-
 static void rtl8139_mmio_writeb(void *opaque, target_phys_addr_t addr, uint32_t val)
 {
     rtl8139_io_writeb(opaque, addr & 0xFF, val);
@@ -3381,18 +3349,44 @@ static const VMStateDescription vmstate_rtl8139 = {
 /***********************************************************/
 /* PCI RTL8139 definitions */
 
-static const MemoryRegionPortio rtl8139_portio[] = {
-    { 0, 0x100, 1, .read = rtl8139_ioport_readb, },
-    { 0, 0x100, 1, .write = rtl8139_ioport_writeb, },
-    { 0, 0x100, 2, .read = rtl8139_ioport_readw, },
-    { 0, 0x100, 2, .write = rtl8139_ioport_writew, },
-    { 0, 0x100, 4, .read = rtl8139_ioport_readl, },
-    { 0, 0x100, 4, .write = rtl8139_ioport_writel, },
-    PORTIO_END_OF_LIST()
-};
+static void rtl8139_ioport_write(void *opaque, target_phys_addr_t addr,
+                                 uint64_t val, unsigned size)
+{
+    switch (size) {
+    case 1:
+        rtl8139_io_writeb(opaque, addr, val);
+        break;
+    case 2:
+        rtl8139_io_writew(opaque, addr, val);
+        break;
+    case 4:
+        rtl8139_io_writel(opaque, addr, val);
+        break;
+    }
+}
+
+static uint64_t rtl8139_ioport_read(void *opaque, target_phys_addr_t addr,
+                                    unsigned size)
+{
+    switch (size) {
+    case 1:
+        return rtl8139_io_readb(opaque, addr);
+    case 2:
+        return rtl8139_io_readw(opaque, addr);
+    case 4:
+        return rtl8139_io_readl(opaque, addr);
+    }
+
+    return -1;
+}
 
 static const MemoryRegionOps rtl8139_io_ops = {
-    .old_portio = rtl8139_portio,
+    .read = rtl8139_ioport_read,
+    .write = rtl8139_ioport_write,
+    .impl = {
+        .min_access_size = 1,
+        .max_access_size = 4,
+    },
     .endianness = DEVICE_LITTLE_ENDIAN,
 };
 
-- 
1.6.0.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 12:24:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 12:24:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLCNZ-0000W6-UY; Mon, 08 Oct 2012 12:24:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLCNY-0000Ux-0L
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 12:24:12 +0000
Received: from [85.158.143.35:13852] by server-3.bemta-4.messagelabs.com id
	DF/84-10986-BE5C2705; Mon, 08 Oct 2012 12:24:11 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-8.tower-21.messagelabs.com!1349699049!14325899!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18068 invoked from network); 8 Oct 2012 12:24:10 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 12:24:10 -0000
Received: from relay1.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id 8CDEEA341E;
	Mon,  8 Oct 2012 14:24:09 +0200 (CEST)
From: Alexander Graf 
To: qemu-devel qemu-devel 
Date: Mon,  8 Oct 2012 14:23:48 +0200
Message-Id: <1349699033-6703-10-git-send-email-agraf@suse.de>
X-Mailer: git-send-email 1.6.0.2
In-Reply-To: <1349699033-6703-1-git-send-email-agraf@suse.de>
References: <1349699033-6703-1-git-send-email-agraf@suse.de>
Cc: Anthony Liguori , xen-devel@lists.xensource.com,
	Stefano Stabellini ,
	"qemu-ppc@nongnu.org List" ,
	Avi Kivity ,
	Scott Wood , malc ,
	David Gibson 
Subject: [Xen-devel] [PATCH 09/14] rtl8139: convert PIO to new memory api
	read/write
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Alexander Graf 
---
 hw/rtl8139.c |   78 ++++++++++++++++++++++++++-------------------------------
 1 files changed, 36 insertions(+), 42 deletions(-)

diff --git a/hw/rtl8139.c b/hw/rtl8139.c
index b7c82ee..6be6883 100644
--- a/hw/rtl8139.c
+++ b/hw/rtl8139.c
@@ -3186,38 +3186,6 @@ static uint32_t rtl8139_io_readl(void *opaque, uint8_t addr)
 
 /* */
 
-static void rtl8139_ioport_writeb(void *opaque, uint32_t addr, uint32_t val)
-{
-    rtl8139_io_writeb(opaque, addr & 0xFF, val);
-}
-
-static void rtl8139_ioport_writew(void *opaque, uint32_t addr, uint32_t val)
-{
-    rtl8139_io_writew(opaque, addr & 0xFF, val);
-}
-
-static void rtl8139_ioport_writel(void *opaque, uint32_t addr, uint32_t val)
-{
-    rtl8139_io_writel(opaque, addr & 0xFF, val);
-}
-
-static uint32_t rtl8139_ioport_readb(void *opaque, uint32_t addr)
-{
-    return rtl8139_io_readb(opaque, addr & 0xFF);
-}
-
-static uint32_t rtl8139_ioport_readw(void *opaque, uint32_t addr)
-{
-    return rtl8139_io_readw(opaque, addr & 0xFF);
-}
-
-static uint32_t rtl8139_ioport_readl(void *opaque, uint32_t addr)
-{
-    return rtl8139_io_readl(opaque, addr & 0xFF);
-}
-
-/* */
-
 static void rtl8139_mmio_writeb(void *opaque, target_phys_addr_t addr, uint32_t val)
 {
     rtl8139_io_writeb(opaque, addr & 0xFF, val);
@@ -3381,18 +3349,44 @@ static const VMStateDescription vmstate_rtl8139 = {
 /***********************************************************/
 /* PCI RTL8139 definitions */
 
-static const MemoryRegionPortio rtl8139_portio[] = {
-    { 0, 0x100, 1, .read = rtl8139_ioport_readb, },
-    { 0, 0x100, 1, .write = rtl8139_ioport_writeb, },
-    { 0, 0x100, 2, .read = rtl8139_ioport_readw, },
-    { 0, 0x100, 2, .write = rtl8139_ioport_writew, },
-    { 0, 0x100, 4, .read = rtl8139_ioport_readl, },
-    { 0, 0x100, 4, .write = rtl8139_ioport_writel, },
-    PORTIO_END_OF_LIST()
-};
+static void rtl8139_ioport_write(void *opaque, target_phys_addr_t addr,
+                                 uint64_t val, unsigned size)
+{
+    switch (size) {
+    case 1:
+        rtl8139_io_writeb(opaque, addr, val);
+        break;
+    case 2:
+        rtl8139_io_writew(opaque, addr, val);
+        break;
+    case 4:
+        rtl8139_io_writel(opaque, addr, val);
+        break;
+    }
+}
+
+static uint64_t rtl8139_ioport_read(void *opaque, target_phys_addr_t addr,
+                                    unsigned size)
+{
+    switch (size) {
+    case 1:
+        return rtl8139_io_readb(opaque, addr);
+    case 2:
+        return rtl8139_io_readw(opaque, addr);
+    case 4:
+        return rtl8139_io_readl(opaque, addr);
+    }
+
+    return -1;
+}
 
 static const MemoryRegionOps rtl8139_io_ops = {
-    .old_portio = rtl8139_portio,
+    .read = rtl8139_ioport_read,
+    .write = rtl8139_ioport_write,
+    .impl = {
+        .min_access_size = 1,
+        .max_access_size = 4,
+    },
     .endianness = DEVICE_LITTLE_ENDIAN,
 };
 
-- 
1.6.0.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 12:24:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 12:24:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLCNR-0000Sy-Hc; Mon, 08 Oct 2012 12:24:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLCNQ-0000Si-59
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 12:24:04 +0000
Received: from [85.158.143.99:59273] by server-1.bemta-4.messagelabs.com id
	9E/19-05684-3E5C2705; Mon, 08 Oct 2012 12:24:03 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-15.tower-216.messagelabs.com!1349699042!33262417!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3431 invoked from network); 8 Oct 2012 12:24:02 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Oct 2012 12:24:02 -0000
Received: from relay1.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id 48029A329D;
	Mon,  8 Oct 2012 14:24:00 +0200 (CEST)
From: Alexander Graf 
To: qemu-devel qemu-devel 
Date: Mon,  8 Oct 2012 14:23:41 +0200
Message-Id: <1349699033-6703-3-git-send-email-agraf@suse.de>
X-Mailer: git-send-email 1.6.0.2
In-Reply-To: <1349699033-6703-1-git-send-email-agraf@suse.de>
References: <1349699033-6703-1-git-send-email-agraf@suse.de>
Cc: Anthony Liguori , xen-devel@lists.xensource.com,
	Stefano Stabellini ,
	"qemu-ppc@nongnu.org List" ,
	Avi Kivity ,
	Scott Wood , malc ,
	David Gibson 
Subject: [Xen-devel] [PATCH 02/14] virtio-pci: convert PIO to new memory api
	read/write
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Alexander Graf 
---
 hw/virtio-pci.c |  126 +++++++++++++++++++++---------------------------------
 1 files changed, 49 insertions(+), 77 deletions(-)

diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
index 400f3c2..e28254f 100644
--- a/hw/virtio-pci.c
+++ b/hw/virtio-pci.c
@@ -374,79 +374,39 @@ static uint32_t virtio_ioport_read(VirtIOPCIProxy *proxy, uint32_t addr)
     return ret;
 }
 
-static uint32_t virtio_pci_config_readb(void *opaque, uint32_t addr)
-{
-    VirtIOPCIProxy *proxy = opaque;
-    uint32_t config = VIRTIO_PCI_CONFIG(&proxy->pci_dev);
-    if (addr < config)
-        return virtio_ioport_read(proxy, addr);
-    addr -= config;
-    return virtio_config_readb(proxy->vdev, addr);
-}
-
-static uint32_t virtio_pci_config_readw(void *opaque, uint32_t addr)
-{
-    VirtIOPCIProxy *proxy = opaque;
-    uint32_t config = VIRTIO_PCI_CONFIG(&proxy->pci_dev);
-    uint16_t val;
-    if (addr < config)
-        return virtio_ioport_read(proxy, addr);
-    addr -= config;
-    val = virtio_config_readw(proxy->vdev, addr);
-    if (virtio_is_big_endian()) {
-        /*
-         * virtio is odd, ioports are LE but config space is target native
-         * endian. However, in qemu, all PIO is LE, so we need to re-swap
-         * on BE targets
-         */
-        val = bswap16(val);
-    }
-    return val;
-}
-
-static uint32_t virtio_pci_config_readl(void *opaque, uint32_t addr)
-{
-    VirtIOPCIProxy *proxy = opaque;
-    uint32_t config = VIRTIO_PCI_CONFIG(&proxy->pci_dev);
-    uint32_t val;
-    if (addr < config)
-        return virtio_ioport_read(proxy, addr);
-    addr -= config;
-    val = virtio_config_readl(proxy->vdev, addr);
-    if (virtio_is_big_endian()) {
-        val = bswap32(val);
-    }
-    return val;
-}
-
-static void virtio_pci_config_writeb(void *opaque, uint32_t addr, uint32_t val)
+static uint64_t virtio_pci_config_read(void *opaque, target_phys_addr_t addr,
+                                       unsigned size)
 {
     VirtIOPCIProxy *proxy = opaque;
     uint32_t config = VIRTIO_PCI_CONFIG(&proxy->pci_dev);
+    uint64_t val = 0;
     if (addr < config) {
-        virtio_ioport_write(proxy, addr, val);
-        return;
+        return virtio_ioport_read(proxy, addr);
     }
     addr -= config;
-    virtio_config_writeb(proxy->vdev, addr, val);
-}
 
-static void virtio_pci_config_writew(void *opaque, uint32_t addr, uint32_t val)
-{
-    VirtIOPCIProxy *proxy = opaque;
-    uint32_t config = VIRTIO_PCI_CONFIG(&proxy->pci_dev);
-    if (addr < config) {
-        virtio_ioport_write(proxy, addr, val);
-        return;
-    }
-    addr -= config;
-    if (virtio_is_big_endian()) {
-        val = bswap16(val);
+    switch (size) {
+    case 1:
+        val = virtio_config_readb(proxy->vdev, addr);
+        break;
+    case 2:
+        val = virtio_config_readw(proxy->vdev, addr);
+        if (virtio_is_big_endian()) {
+            val = bswap16(val);
+        }
+        break;
+    case 4:
+        val = virtio_config_readl(proxy->vdev, addr);
+        if (virtio_is_big_endian()) {
+            val = bswap32(val);
+        }
+        break;
     }
-    virtio_config_writew(proxy->vdev, addr, val);
+    return val;
 }
 
-static void virtio_pci_config_writel(void *opaque, uint32_t addr, uint32_t val)
+static void virtio_pci_config_write(void *opaque, target_phys_addr_t addr,
+                                    uint64_t val, unsigned size)
 {
     VirtIOPCIProxy *proxy = opaque;
     uint32_t config = VIRTIO_PCI_CONFIG(&proxy->pci_dev);
@@ -455,24 +415,36 @@ static void virtio_pci_config_writel(void *opaque, uint32_t addr, uint32_t val)
         return;
     }
     addr -= config;
-    if (virtio_is_big_endian()) {
-        val = bswap32(val);
+    /*
+     * Virtio-PCI is odd. Ioports are LE but config space is target native
+     * endian.
+     */
+    switch (size) {
+    case 1:
+        virtio_config_writeb(proxy->vdev, addr, val);
+        break;
+    case 2:
+        if (virtio_is_big_endian()) {
+            val = bswap16(val);
+        }
+        virtio_config_writew(proxy->vdev, addr, val);
+        break;
+    case 4:
+        if (virtio_is_big_endian()) {
+            val = bswap32(val);
+        }
+        virtio_config_writel(proxy->vdev, addr, val);
+        break;
     }
-    virtio_config_writel(proxy->vdev, addr, val);
 }
 
-static const MemoryRegionPortio virtio_portio[] = {
-    { 0, 0x10000, 1, .write = virtio_pci_config_writeb, },
-    { 0, 0x10000, 2, .write = virtio_pci_config_writew, },
-    { 0, 0x10000, 4, .write = virtio_pci_config_writel, },
-    { 0, 0x10000, 1, .read = virtio_pci_config_readb, },
-    { 0, 0x10000, 2, .read = virtio_pci_config_readw, },
-    { 0, 0x10000, 4, .read = virtio_pci_config_readl, },
-    PORTIO_END_OF_LIST()
-};
-
 static const MemoryRegionOps virtio_pci_config_ops = {
-    .old_portio = virtio_portio,
+    .read = virtio_pci_config_read,
+    .write = virtio_pci_config_write,
+    .impl = {
+        .min_access_size = 1,
+        .max_access_size = 4,
+    },
     .endianness = DEVICE_LITTLE_ENDIAN,
 };
 
-- 
1.6.0.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 12:24:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 12:24:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLCNR-0000Sy-Hc; Mon, 08 Oct 2012 12:24:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLCNQ-0000Si-59
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 12:24:04 +0000
Received: from [85.158.143.99:59273] by server-1.bemta-4.messagelabs.com id
	9E/19-05684-3E5C2705; Mon, 08 Oct 2012 12:24:03 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-15.tower-216.messagelabs.com!1349699042!33262417!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3431 invoked from network); 8 Oct 2012 12:24:02 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Oct 2012 12:24:02 -0000
Received: from relay1.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id 48029A329D;
	Mon,  8 Oct 2012 14:24:00 +0200 (CEST)
From: Alexander Graf 
To: qemu-devel qemu-devel 
Date: Mon,  8 Oct 2012 14:23:41 +0200
Message-Id: <1349699033-6703-3-git-send-email-agraf@suse.de>
X-Mailer: git-send-email 1.6.0.2
In-Reply-To: <1349699033-6703-1-git-send-email-agraf@suse.de>
References: <1349699033-6703-1-git-send-email-agraf@suse.de>
Cc: Anthony Liguori , xen-devel@lists.xensource.com,
	Stefano Stabellini ,
	"qemu-ppc@nongnu.org List" ,
	Avi Kivity ,
	Scott Wood , malc ,
	David Gibson 
Subject: [Xen-devel] [PATCH 02/14] virtio-pci: convert PIO to new memory api
	read/write
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Alexander Graf 
---
 hw/virtio-pci.c |  126 +++++++++++++++++++++---------------------------------
 1 files changed, 49 insertions(+), 77 deletions(-)

diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
index 400f3c2..e28254f 100644
--- a/hw/virtio-pci.c
+++ b/hw/virtio-pci.c
@@ -374,79 +374,39 @@ static uint32_t virtio_ioport_read(VirtIOPCIProxy *proxy, uint32_t addr)
     return ret;
 }
 
-static uint32_t virtio_pci_config_readb(void *opaque, uint32_t addr)
-{
-    VirtIOPCIProxy *proxy = opaque;
-    uint32_t config = VIRTIO_PCI_CONFIG(&proxy->pci_dev);
-    if (addr < config)
-        return virtio_ioport_read(proxy, addr);
-    addr -= config;
-    return virtio_config_readb(proxy->vdev, addr);
-}
-
-static uint32_t virtio_pci_config_readw(void *opaque, uint32_t addr)
-{
-    VirtIOPCIProxy *proxy = opaque;
-    uint32_t config = VIRTIO_PCI_CONFIG(&proxy->pci_dev);
-    uint16_t val;
-    if (addr < config)
-        return virtio_ioport_read(proxy, addr);
-    addr -= config;
-    val = virtio_config_readw(proxy->vdev, addr);
-    if (virtio_is_big_endian()) {
-        /*
-         * virtio is odd, ioports are LE but config space is target native
-         * endian. However, in qemu, all PIO is LE, so we need to re-swap
-         * on BE targets
-         */
-        val = bswap16(val);
-    }
-    return val;
-}
-
-static uint32_t virtio_pci_config_readl(void *opaque, uint32_t addr)
-{
-    VirtIOPCIProxy *proxy = opaque;
-    uint32_t config = VIRTIO_PCI_CONFIG(&proxy->pci_dev);
-    uint32_t val;
-    if (addr < config)
-        return virtio_ioport_read(proxy, addr);
-    addr -= config;
-    val = virtio_config_readl(proxy->vdev, addr);
-    if (virtio_is_big_endian()) {
-        val = bswap32(val);
-    }
-    return val;
-}
-
-static void virtio_pci_config_writeb(void *opaque, uint32_t addr, uint32_t val)
+static uint64_t virtio_pci_config_read(void *opaque, target_phys_addr_t addr,
+                                       unsigned size)
 {
     VirtIOPCIProxy *proxy = opaque;
     uint32_t config = VIRTIO_PCI_CONFIG(&proxy->pci_dev);
+    uint64_t val = 0;
     if (addr < config) {
-        virtio_ioport_write(proxy, addr, val);
-        return;
+        return virtio_ioport_read(proxy, addr);
     }
     addr -= config;
-    virtio_config_writeb(proxy->vdev, addr, val);
-}
 
-static void virtio_pci_config_writew(void *opaque, uint32_t addr, uint32_t val)
-{
-    VirtIOPCIProxy *proxy = opaque;
-    uint32_t config = VIRTIO_PCI_CONFIG(&proxy->pci_dev);
-    if (addr < config) {
-        virtio_ioport_write(proxy, addr, val);
-        return;
-    }
-    addr -= config;
-    if (virtio_is_big_endian()) {
-        val = bswap16(val);
+    switch (size) {
+    case 1:
+        val = virtio_config_readb(proxy->vdev, addr);
+        break;
+    case 2:
+        val = virtio_config_readw(proxy->vdev, addr);
+        if (virtio_is_big_endian()) {
+            val = bswap16(val);
+        }
+        break;
+    case 4:
+        val = virtio_config_readl(proxy->vdev, addr);
+        if (virtio_is_big_endian()) {
+            val = bswap32(val);
+        }
+        break;
     }
-    virtio_config_writew(proxy->vdev, addr, val);
+    return val;
 }
 
-static void virtio_pci_config_writel(void *opaque, uint32_t addr, uint32_t val)
+static void virtio_pci_config_write(void *opaque, target_phys_addr_t addr,
+                                    uint64_t val, unsigned size)
 {
     VirtIOPCIProxy *proxy = opaque;
     uint32_t config = VIRTIO_PCI_CONFIG(&proxy->pci_dev);
@@ -455,24 +415,36 @@ static void virtio_pci_config_writel(void *opaque, uint32_t addr, uint32_t val)
         return;
     }
     addr -= config;
-    if (virtio_is_big_endian()) {
-        val = bswap32(val);
+    /*
+     * Virtio-PCI is odd. Ioports are LE but config space is target native
+     * endian.
+     */
+    switch (size) {
+    case 1:
+        virtio_config_writeb(proxy->vdev, addr, val);
+        break;
+    case 2:
+        if (virtio_is_big_endian()) {
+            val = bswap16(val);
+        }
+        virtio_config_writew(proxy->vdev, addr, val);
+        break;
+    case 4:
+        if (virtio_is_big_endian()) {
+            val = bswap32(val);
+        }
+        virtio_config_writel(proxy->vdev, addr, val);
+        break;
     }
-    virtio_config_writel(proxy->vdev, addr, val);
 }
 
-static const MemoryRegionPortio virtio_portio[] = {
-    { 0, 0x10000, 1, .write = virtio_pci_config_writeb, },
-    { 0, 0x10000, 2, .write = virtio_pci_config_writew, },
-    { 0, 0x10000, 4, .write = virtio_pci_config_writel, },
-    { 0, 0x10000, 1, .read = virtio_pci_config_readb, },
-    { 0, 0x10000, 2, .read = virtio_pci_config_readw, },
-    { 0, 0x10000, 4, .read = virtio_pci_config_readl, },
-    PORTIO_END_OF_LIST()
-};
-
 static const MemoryRegionOps virtio_pci_config_ops = {
-    .old_portio = virtio_portio,
+    .read = virtio_pci_config_read,
+    .write = virtio_pci_config_write,
+    .impl = {
+        .min_access_size = 1,
+        .max_access_size = 4,
+    },
     .endianness = DEVICE_LITTLE_ENDIAN,
 };
 
-- 
1.6.0.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 12:24:48 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 12:24:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLCNu-0000or-0g; Mon, 08 Oct 2012 12:24:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLCNs-0000mO-Dc
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 12:24:32 +0000
Received: from [85.158.143.35:17117] by server-1.bemta-4.messagelabs.com id
	BA/C9-05684-FF5C2705; Mon, 08 Oct 2012 12:24:31 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-10.tower-21.messagelabs.com!1349699042!10588399!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16186 invoked from network); 8 Oct 2012 12:24:03 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 12:24:03 -0000
Received: from relay2.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id B113DA329E;
	Mon,  8 Oct 2012 14:24:01 +0200 (CEST)
From: Alexander Graf 
To: qemu-devel qemu-devel 
Date: Mon,  8 Oct 2012 14:23:42 +0200
Message-Id: <1349699033-6703-4-git-send-email-agraf@suse.de>
X-Mailer: git-send-email 1.6.0.2
In-Reply-To: <1349699033-6703-1-git-send-email-agraf@suse.de>
References: <1349699033-6703-1-git-send-email-agraf@suse.de>
Cc: Anthony Liguori , xen-devel@lists.xensource.com,
	Stefano Stabellini ,
	"qemu-ppc@nongnu.org List" ,
	Avi Kivity ,
	Scott Wood , malc ,
	David Gibson 
Subject: [Xen-devel] [PATCH 03/14] es1370: convert PIO to new memory api
	read/write
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Alexander Graf 
---
 hw/es1370.c |   46 ++++++++++++++++++++++++++++++++++++----------
 1 files changed, 36 insertions(+), 10 deletions(-)

diff --git a/hw/es1370.c b/hw/es1370.c
index e34234c..308f2c2 100644
--- a/hw/es1370.c
+++ b/hw/es1370.c
@@ -908,18 +908,44 @@ static void es1370_adc_callback (void *opaque, int avail)
     es1370_run_channel (s, ADC_CHANNEL, avail);
 }
 
-static const MemoryRegionPortio es1370_portio[] = {
-    { 0, 0x40 * 4, 1, .write = es1370_writeb, },
-    { 0, 0x40 * 2, 2, .write = es1370_writew, },
-    { 0, 0x40, 4, .write = es1370_writel, },
-    { 0, 0x40 * 4, 1, .read = es1370_readb, },
-    { 0, 0x40 * 2, 2, .read = es1370_readw, },
-    { 0, 0x40, 4, .read = es1370_readl, },
-    PORTIO_END_OF_LIST ()
-};
+static uint64_t es1370_read(void *opaque, target_phys_addr_t addr,
+                            unsigned size)
+{
+    switch (size) {
+    case 1:
+        return es1370_readb(opaque, addr);
+    case 2:
+        return es1370_readw(opaque, addr);
+    case 4:
+        return es1370_readl(opaque, addr);
+    default:
+        return -1;
+    }
+}
+
+static void es1370_write(void *opaque, target_phys_addr_t addr, uint64_t val,
+                      unsigned size)
+{
+    switch (size) {
+    case 1:
+        es1370_writeb(opaque, addr, val);
+        break;
+    case 2:
+        es1370_writew(opaque, addr, val);
+        break;
+    case 4:
+        es1370_writel(opaque, addr, val);
+        break;
+    }
+}
 
 static const MemoryRegionOps es1370_io_ops = {
-    .old_portio = es1370_portio,
+    .read = es1370_read,
+    .write = es1370_write,
+    .impl = {
+        .min_access_size = 1,
+        .max_access_size = 4,
+    },
     .endianness = DEVICE_LITTLE_ENDIAN,
 };
 
-- 
1.6.0.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 12:24:48 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 12:24:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLCNu-0000or-0g; Mon, 08 Oct 2012 12:24:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLCNs-0000mO-Dc
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 12:24:32 +0000
Received: from [85.158.143.35:17117] by server-1.bemta-4.messagelabs.com id
	BA/C9-05684-FF5C2705; Mon, 08 Oct 2012 12:24:31 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-10.tower-21.messagelabs.com!1349699042!10588399!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16186 invoked from network); 8 Oct 2012 12:24:03 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 12:24:03 -0000
Received: from relay2.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id B113DA329E;
	Mon,  8 Oct 2012 14:24:01 +0200 (CEST)
From: Alexander Graf 
To: qemu-devel qemu-devel 
Date: Mon,  8 Oct 2012 14:23:42 +0200
Message-Id: <1349699033-6703-4-git-send-email-agraf@suse.de>
X-Mailer: git-send-email 1.6.0.2
In-Reply-To: <1349699033-6703-1-git-send-email-agraf@suse.de>
References: <1349699033-6703-1-git-send-email-agraf@suse.de>
Cc: Anthony Liguori , xen-devel@lists.xensource.com,
	Stefano Stabellini ,
	"qemu-ppc@nongnu.org List" ,
	Avi Kivity ,
	Scott Wood , malc ,
	David Gibson 
Subject: [Xen-devel] [PATCH 03/14] es1370: convert PIO to new memory api
	read/write
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Alexander Graf 
---
 hw/es1370.c |   46 ++++++++++++++++++++++++++++++++++++----------
 1 files changed, 36 insertions(+), 10 deletions(-)

diff --git a/hw/es1370.c b/hw/es1370.c
index e34234c..308f2c2 100644
--- a/hw/es1370.c
+++ b/hw/es1370.c
@@ -908,18 +908,44 @@ static void es1370_adc_callback (void *opaque, int avail)
     es1370_run_channel (s, ADC_CHANNEL, avail);
 }
 
-static const MemoryRegionPortio es1370_portio[] = {
-    { 0, 0x40 * 4, 1, .write = es1370_writeb, },
-    { 0, 0x40 * 2, 2, .write = es1370_writew, },
-    { 0, 0x40, 4, .write = es1370_writel, },
-    { 0, 0x40 * 4, 1, .read = es1370_readb, },
-    { 0, 0x40 * 2, 2, .read = es1370_readw, },
-    { 0, 0x40, 4, .read = es1370_readl, },
-    PORTIO_END_OF_LIST ()
-};
+static uint64_t es1370_read(void *opaque, target_phys_addr_t addr,
+                            unsigned size)
+{
+    switch (size) {
+    case 1:
+        return es1370_readb(opaque, addr);
+    case 2:
+        return es1370_readw(opaque, addr);
+    case 4:
+        return es1370_readl(opaque, addr);
+    default:
+        return -1;
+    }
+}
+
+static void es1370_write(void *opaque, target_phys_addr_t addr, uint64_t val,
+                      unsigned size)
+{
+    switch (size) {
+    case 1:
+        es1370_writeb(opaque, addr, val);
+        break;
+    case 2:
+        es1370_writew(opaque, addr, val);
+        break;
+    case 4:
+        es1370_writel(opaque, addr, val);
+        break;
+    }
+}
 
 static const MemoryRegionOps es1370_io_ops = {
-    .old_portio = es1370_portio,
+    .read = es1370_read,
+    .write = es1370_write,
+    .impl = {
+        .min_access_size = 1,
+        .max_access_size = 4,
+    },
     .endianness = DEVICE_LITTLE_ENDIAN,
 };
 
-- 
1.6.0.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 12:24:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 12:24:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLCNu-0000pS-DH; Mon, 08 Oct 2012 12:24:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLCNs-0000mO-SH
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 12:24:33 +0000
Received: from [85.158.143.35:8299] by server-1.bemta-4.messagelabs.com id
	12/D9-05684-006C2705; Mon, 08 Oct 2012 12:24:32 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-10.tower-21.messagelabs.com!1349699050!10588431!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17271 invoked from network); 8 Oct 2012 12:24:11 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 12:24:11 -0000
Received: from relay2.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id C0327A3421;
	Mon,  8 Oct 2012 14:24:10 +0200 (CEST)
From: Alexander Graf 
To: qemu-devel qemu-devel 
Date: Mon,  8 Oct 2012 14:23:49 +0200
Message-Id: <1349699033-6703-11-git-send-email-agraf@suse.de>
X-Mailer: git-send-email 1.6.0.2
In-Reply-To: <1349699033-6703-1-git-send-email-agraf@suse.de>
References: <1349699033-6703-1-git-send-email-agraf@suse.de>
Cc: Anthony Liguori , xen-devel@lists.xensource.com,
	Stefano Stabellini ,
	"qemu-ppc@nongnu.org List" ,
	Avi Kivity ,
	Scott Wood , malc ,
	David Gibson 
Subject: [Xen-devel] [PATCH 10/14] serial: convert PIO to new memory api
	read/write
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Alexander Graf 
---
 hw/serial.c |   31 ++++++++++++++++++-------------
 1 files changed, 18 insertions(+), 13 deletions(-)

diff --git a/hw/serial.c b/hw/serial.c
index a421d1e..abae1e7 100644
--- a/hw/serial.c
+++ b/hw/serial.c
@@ -28,6 +28,7 @@
 #include "pc.h"
 #include "qemu-timer.h"
 #include "sysemu.h"
+#include "exec-memory.h"
 
 //#define DEBUG_SERIAL
 
@@ -367,7 +368,8 @@ static void serial_xmit(void *opaque)
 }
 
 
-static void serial_ioport_write(void *opaque, uint32_t addr, uint32_t val)
+static void serial_ioport_write(void *opaque, target_phys_addr_t addr,
+                                uint64_t val, unsigned size)
 {
     SerialState *s = opaque;
 
@@ -513,7 +515,8 @@ static void serial_ioport_write(void *opaque, uint32_t addr, uint32_t val)
     }
 }
 
-static uint32_t serial_ioport_read(void *opaque, uint32_t addr)
+static uint64_t serial_ioport_read(void *opaque, target_phys_addr_t addr,
+                                   unsigned size)
 {
     SerialState *s = opaque;
     uint32_t ret;
@@ -682,7 +685,7 @@ static int serial_post_load(void *opaque, int version_id)
         s->fcr_vmstate = 0;
     }
     /* Initialize fcr via setter to perform essential side-effects */
-    serial_ioport_write(s, 0x02, s->fcr_vmstate);
+    serial_ioport_write(s, 0x02, s->fcr_vmstate, 1);
     serial_update_parameters(s);
     return 0;
 }
@@ -764,13 +767,14 @@ void serial_set_frequency(SerialState *s, uint32_t frequency)
 static const int isa_serial_io[MAX_SERIAL_PORTS] = { 0x3f8, 0x2f8, 0x3e8, 0x2e8 };
 static const int isa_serial_irq[MAX_SERIAL_PORTS] = { 4, 3, 4, 3 };
 
-static const MemoryRegionPortio serial_portio[] = {
-    { 0, 8, 1, .read = serial_ioport_read, .write = serial_ioport_write },
-    PORTIO_END_OF_LIST()
-};
-
 static const MemoryRegionOps serial_io_ops = {
-    .old_portio = serial_portio
+    .read = serial_ioport_read,
+    .write = serial_ioport_write,
+    .impl = {
+        .min_access_size = 1,
+        .max_access_size = 1,
+    },
+    .endianness = DEVICE_LITTLE_ENDIAN,
 };
 
 static int serial_isa_initfn(ISADevice *dev)
@@ -823,8 +827,9 @@ SerialState *serial_init(int base, qemu_irq irq, int baudbase,
 
     vmstate_register(NULL, base, &vmstate_serial, s);
 
-    register_ioport_write(base, 8, 1, serial_ioport_write, s);
-    register_ioport_read(base, 8, 1, serial_ioport_read, s);
+    memory_region_init_io(&s->io, &serial_io_ops, s, "serial", 8);
+    memory_region_add_subregion(get_system_io(), base, &s->io);
+
     return s;
 }
 
@@ -833,7 +838,7 @@ static uint64_t serial_mm_read(void *opaque, target_phys_addr_t addr,
                                unsigned size)
 {
     SerialState *s = opaque;
-    return serial_ioport_read(s, addr >> s->it_shift);
+    return serial_ioport_read(s, addr >> s->it_shift, 1);
 }
 
 static void serial_mm_write(void *opaque, target_phys_addr_t addr,
@@ -841,7 +846,7 @@ static void serial_mm_write(void *opaque, target_phys_addr_t addr,
 {
     SerialState *s = opaque;
     value &= ~0u >> (32 - (size * 8));
-    serial_ioport_write(s, addr >> s->it_shift, value);
+    serial_ioport_write(s, addr >> s->it_shift, value, 1);
 }
 
 static const MemoryRegionOps serial_mm_ops[3] = {
-- 
1.6.0.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 12:24:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 12:24:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLCNu-0000pS-DH; Mon, 08 Oct 2012 12:24:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLCNs-0000mO-SH
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 12:24:33 +0000
Received: from [85.158.143.35:8299] by server-1.bemta-4.messagelabs.com id
	12/D9-05684-006C2705; Mon, 08 Oct 2012 12:24:32 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-10.tower-21.messagelabs.com!1349699050!10588431!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17271 invoked from network); 8 Oct 2012 12:24:11 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 12:24:11 -0000
Received: from relay2.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id C0327A3421;
	Mon,  8 Oct 2012 14:24:10 +0200 (CEST)
From: Alexander Graf 
To: qemu-devel qemu-devel 
Date: Mon,  8 Oct 2012 14:23:49 +0200
Message-Id: <1349699033-6703-11-git-send-email-agraf@suse.de>
X-Mailer: git-send-email 1.6.0.2
In-Reply-To: <1349699033-6703-1-git-send-email-agraf@suse.de>
References: <1349699033-6703-1-git-send-email-agraf@suse.de>
Cc: Anthony Liguori , xen-devel@lists.xensource.com,
	Stefano Stabellini ,
	"qemu-ppc@nongnu.org List" ,
	Avi Kivity ,
	Scott Wood , malc ,
	David Gibson 
Subject: [Xen-devel] [PATCH 10/14] serial: convert PIO to new memory api
	read/write
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Alexander Graf 
---
 hw/serial.c |   31 ++++++++++++++++++-------------
 1 files changed, 18 insertions(+), 13 deletions(-)

diff --git a/hw/serial.c b/hw/serial.c
index a421d1e..abae1e7 100644
--- a/hw/serial.c
+++ b/hw/serial.c
@@ -28,6 +28,7 @@
 #include "pc.h"
 #include "qemu-timer.h"
 #include "sysemu.h"
+#include "exec-memory.h"
 
 //#define DEBUG_SERIAL
 
@@ -367,7 +368,8 @@ static void serial_xmit(void *opaque)
 }
 
 
-static void serial_ioport_write(void *opaque, uint32_t addr, uint32_t val)
+static void serial_ioport_write(void *opaque, target_phys_addr_t addr,
+                                uint64_t val, unsigned size)
 {
     SerialState *s = opaque;
 
@@ -513,7 +515,8 @@ static void serial_ioport_write(void *opaque, uint32_t addr, uint32_t val)
     }
 }
 
-static uint32_t serial_ioport_read(void *opaque, uint32_t addr)
+static uint64_t serial_ioport_read(void *opaque, target_phys_addr_t addr,
+                                   unsigned size)
 {
     SerialState *s = opaque;
     uint32_t ret;
@@ -682,7 +685,7 @@ static int serial_post_load(void *opaque, int version_id)
         s->fcr_vmstate = 0;
     }
     /* Initialize fcr via setter to perform essential side-effects */
-    serial_ioport_write(s, 0x02, s->fcr_vmstate);
+    serial_ioport_write(s, 0x02, s->fcr_vmstate, 1);
     serial_update_parameters(s);
     return 0;
 }
@@ -764,13 +767,14 @@ void serial_set_frequency(SerialState *s, uint32_t frequency)
 static const int isa_serial_io[MAX_SERIAL_PORTS] = { 0x3f8, 0x2f8, 0x3e8, 0x2e8 };
 static const int isa_serial_irq[MAX_SERIAL_PORTS] = { 4, 3, 4, 3 };
 
-static const MemoryRegionPortio serial_portio[] = {
-    { 0, 8, 1, .read = serial_ioport_read, .write = serial_ioport_write },
-    PORTIO_END_OF_LIST()
-};
-
 static const MemoryRegionOps serial_io_ops = {
-    .old_portio = serial_portio
+    .read = serial_ioport_read,
+    .write = serial_ioport_write,
+    .impl = {
+        .min_access_size = 1,
+        .max_access_size = 1,
+    },
+    .endianness = DEVICE_LITTLE_ENDIAN,
 };
 
 static int serial_isa_initfn(ISADevice *dev)
@@ -823,8 +827,9 @@ SerialState *serial_init(int base, qemu_irq irq, int baudbase,
 
     vmstate_register(NULL, base, &vmstate_serial, s);
 
-    register_ioport_write(base, 8, 1, serial_ioport_write, s);
-    register_ioport_read(base, 8, 1, serial_ioport_read, s);
+    memory_region_init_io(&s->io, &serial_io_ops, s, "serial", 8);
+    memory_region_add_subregion(get_system_io(), base, &s->io);
+
     return s;
 }
 
@@ -833,7 +838,7 @@ static uint64_t serial_mm_read(void *opaque, target_phys_addr_t addr,
                                unsigned size)
 {
     SerialState *s = opaque;
-    return serial_ioport_read(s, addr >> s->it_shift);
+    return serial_ioport_read(s, addr >> s->it_shift, 1);
 }
 
 static void serial_mm_write(void *opaque, target_phys_addr_t addr,
@@ -841,7 +846,7 @@ static void serial_mm_write(void *opaque, target_phys_addr_t addr,
 {
     SerialState *s = opaque;
     value &= ~0u >> (32 - (size * 8));
-    serial_ioport_write(s, addr >> s->it_shift, value);
+    serial_ioport_write(s, addr >> s->it_shift, value, 1);
 }
 
 static const MemoryRegionOps serial_mm_ops[3] = {
-- 
1.6.0.2


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 12:31:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 12:31:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLCUU-0002Y8-At; Mon, 08 Oct 2012 12:31:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLCUS-0002Y3-Bd
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 12:31:20 +0000
Received: from [85.158.143.35:49261] by server-3.bemta-4.messagelabs.com id
	98/EE-10986-797C2705; Mon, 08 Oct 2012 12:31:19 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1349699465!14326925!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMyNjc2Mg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10572 invoked from network); 8 Oct 2012 12:31:07 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-8.tower-21.messagelabs.com with SMTP;
	8 Oct 2012 12:31:07 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 08 Oct 2012 05:31:05 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,553,1344236400"; d="scan'208";a="231973177"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by fmsmga002.fm.intel.com with ESMTP; 08 Oct 2012 05:31:04 -0700
Received: from FMSMSX110.amr.corp.intel.com (10.19.9.29) by
	FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 8 Oct 2012 05:31:04 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	fmsmsx110.amr.corp.intel.com (10.19.9.29) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 8 Oct 2012 05:31:04 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.92]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.162]) with mapi id
	14.01.0355.002; Mon, 8 Oct 2012 20:31:02 +0800
From: "Hao, Xudong" 
To: "ian.campbell@citrix.com" , "keir@xen.org"
	
Thread-Topic: [PATCH v3] xen/tools: Add 64 bits big bar support
Thread-Index: AQHNm8GbNOE8aT1fVEaIth3aKGlXepevaYGA
Date: Mon, 8 Oct 2012 12:31:00 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FECC549@SHSMSX102.ccr.corp.intel.com>
References: <1348648582-11461-1-git-send-email-xudong.hao@intel.com>
In-Reply-To: <1348648582-11461-1-git-send-email-xudong.hao@intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "Stefano.Stabellini@eu.citrix.com" ,
	"Zhang, Xiantao" ,
	"jbeulich@suse.com" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH v3] xen/tools: Add 64 bits big bar support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, Ian and Keir

Do you have other comments for this patch?

Thanks,
-Xudong

> -----Original Message-----
> From: Hao, Xudong
> Sent: Wednesday, September 26, 2012 4:36 PM
> To: ian.campbell@citrix.com; keir@xen.org
> Cc: xen-devel@lists.xen.org; Stefano.Stabellini@eu.citrix.com;
> jbeulich@suse.com; Zhang, Xiantao; Hao, Xudong
> Subject: [PATCH v3] xen/tools: Add 64 bits big bar support
> 
> Currently it is assumed PCI device BAR access < 4G memory. If there is such a
> device whose BAR size is larger than 4G, it must access > 4G memory address.
> This patch enable the 64bits big BAR support on hvmloader.
> 
> v3 changes from v2:
> - Remain original print information
> 
> v2 changes from v1 as comments by Jan.
> 1) Set Dynamic MMIO high memory address instead of a fixed number 640G
> 2) Mask bar_sz earlier to avoid older code changes
> 3) Add bar size barrier to judge high memory resource
> 4) Clean up bar64_relocate code
> 
> Signed-off-by: Xiantao Zhang 
> Signed-off-by: Xudong Hao 
> ---
>  tools/firmware/hvmloader/cacheattr.c |   25 +++++++----
>  tools/firmware/hvmloader/config.h    |    2 +
>  tools/firmware/hvmloader/pci.c       |   77
> ++++++++++++++++++++++++++-------
>  tools/firmware/hvmloader/util.h      |    1 +
>  4 files changed, 80 insertions(+), 25 deletions(-)
> 
> diff --git a/tools/firmware/hvmloader/cacheattr.c
> b/tools/firmware/hvmloader/cacheattr.c
> index 646f07f..592b455 100644
> --- a/tools/firmware/hvmloader/cacheattr.c
> +++ b/tools/firmware/hvmloader/cacheattr.c
> @@ -40,24 +40,33 @@
>  #define MSR_PAT              0x0277
>  #define MSR_MTRRdefType      0x02ff
> 
> +unsigned int cpu_phys_addr(void)
> +{
> +    uint32_t eax, ebx, ecx, edx;
> +    unsigned int phys_bits = 36;
> +    /* Find the physical address size for this CPU. */
> +    cpuid(0x80000000, &eax, &ebx, &ecx, &edx);
> +    if ( eax >= 0x80000008 )
> +    {
> +        cpuid(0x80000008, &eax, &ebx, &ecx, &edx);
> +        phys_bits = (uint8_t)eax;
> +    }
> +
> +    return phys_bits;
> +}
> +
>  void cacheattr_init(void)
>  {
>      uint32_t eax, ebx, ecx, edx;
>      uint64_t mtrr_cap, mtrr_def, content, addr_mask;
> -    unsigned int i, nr_var_ranges, phys_bits = 36;
> +    unsigned int i, nr_var_ranges, phys_bits;
> 
>      /* Does the CPU support architectural MTRRs? */
>      cpuid(0x00000001, &eax, &ebx, &ecx, &edx);
>      if ( !(edx & (1u << 12)) )
>           return;
> 
> -    /* Find the physical address size for this CPU. */
> -    cpuid(0x80000000, &eax, &ebx, &ecx, &edx);
> -    if ( eax >= 0x80000008 )
> -    {
> -        cpuid(0x80000008, &eax, &ebx, &ecx, &edx);
> -        phys_bits = (uint8_t)eax;
> -    }
> +    phys_bits = cpu_phys_addr();
> 
>      printf("%u-bit phys ... ", phys_bits);
> 
> diff --git a/tools/firmware/hvmloader/config.h
> b/tools/firmware/hvmloader/config.h
> index 7c0180d..bbf2993 100644
> --- a/tools/firmware/hvmloader/config.h
> +++ b/tools/firmware/hvmloader/config.h
> @@ -53,6 +53,8 @@ extern struct bios_config ovmf_config;
>  /* MMIO hole: Hardcoded defaults, which can be dynamically expanded. */
>  #define PCI_MEM_START       0xf0000000
>  #define PCI_MEM_END         0xfc000000
> +#define PCI_MIN_BIG_BAR_SIZE          0x20000000
> +
>  extern unsigned long pci_mem_start, pci_mem_end;
> 
> 
> diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
> index fd56e50..0500db5 100644
> --- a/tools/firmware/hvmloader/pci.c
> +++ b/tools/firmware/hvmloader/pci.c
> @@ -36,19 +36,25 @@ unsigned long igd_opregion_pgbase = 0;
> 
>  void pci_setup(void)
>  {
> -    uint32_t base, devfn, bar_reg, bar_data, bar_sz, cmd, mmio_total = 0;
> +    uint8_t is_64bar, using_64bar, bar64_relocate = 0;
> +    uint32_t devfn, bar_reg, cmd, bar_data, bar_data_upper;
> +    uint64_t base, bar_sz, bar_sz_upper, mmio_total = 0;
>      uint32_t vga_devfn = 256;
>      uint16_t class, vendor_id, device_id;
>      unsigned int bar, pin, link, isa_irq;
> +    int64_t mmio_left;
> 
>      /* Resources assignable to PCI devices via BARs. */
>      struct resource {
> -        uint32_t base, max;
> -    } *resource, mem_resource, io_resource;
> +        uint64_t base, max;
> +    } *resource, mem_resource, high_mem_resource, io_resource;
> 
>      /* Create a list of device BARs in descending order of size. */
>      struct bars {
> -        uint32_t devfn, bar_reg, bar_sz;
> +        uint32_t is_64bar;
> +        uint32_t devfn;
> +        uint32_t bar_reg;
> +        uint64_t bar_sz;
>      } *bars = (struct bars *)scratch_start;
>      unsigned int i, nr_bars = 0;
> 
> @@ -133,22 +139,34 @@ void pci_setup(void)
>          /* Map the I/O memory and port resources. */
>          for ( bar = 0; bar < 7; bar++ )
>          {
> +            bar_sz_upper = 0;
>              bar_reg = PCI_BASE_ADDRESS_0 + 4*bar;
>              if ( bar == 6 )
>                  bar_reg = PCI_ROM_ADDRESS;
> 
>              bar_data = pci_readl(devfn, bar_reg);
> +            is_64bar = !!((bar_data & (PCI_BASE_ADDRESS_SPACE |
> +                         PCI_BASE_ADDRESS_MEM_TYPE_MASK)) ==
> +                         (PCI_BASE_ADDRESS_SPACE_MEMORY |
> +                         PCI_BASE_ADDRESS_MEM_TYPE_64));
>              pci_writel(devfn, bar_reg, ~0);
>              bar_sz = pci_readl(devfn, bar_reg);
>              pci_writel(devfn, bar_reg, bar_data);
> -            if ( bar_sz == 0 )
> -                continue;
> 
>              bar_sz &= (((bar_data & PCI_BASE_ADDRESS_SPACE) ==
>                          PCI_BASE_ADDRESS_SPACE_MEMORY) ?
>                         PCI_BASE_ADDRESS_MEM_MASK :
>                         (PCI_BASE_ADDRESS_IO_MASK & 0xffff));
> +            if (is_64bar) {
> +                bar_data_upper = pci_readl(devfn, bar_reg + 4);
> +                pci_writel(devfn, bar_reg + 4, ~0);
> +                bar_sz_upper = pci_readl(devfn, bar_reg + 4);
> +                pci_writel(devfn, bar_reg + 4, bar_data_upper);
> +                bar_sz = (bar_sz_upper << 32) | bar_sz;
> +            }
>              bar_sz &= ~(bar_sz - 1);
> +            if ( bar_sz == 0 )
> +                continue;
> 
>              for ( i = 0; i < nr_bars; i++ )
>                  if ( bars[i].bar_sz < bar_sz )
> @@ -157,6 +175,7 @@ void pci_setup(void)
>              if ( i != nr_bars )
>                  memmove(&bars[i+1], &bars[i], (nr_bars-i) *
> sizeof(*bars));
> 
> +            bars[i].is_64bar = is_64bar;
>              bars[i].devfn   = devfn;
>              bars[i].bar_reg = bar_reg;
>              bars[i].bar_sz  = bar_sz;
> @@ -167,11 +186,8 @@ void pci_setup(void)
> 
>              nr_bars++;
> 
> -            /* Skip the upper-half of the address for a 64-bit BAR. */
> -            if ( (bar_data & (PCI_BASE_ADDRESS_SPACE |
> -                              PCI_BASE_ADDRESS_MEM_TYPE_MASK))
> ==
> -                 (PCI_BASE_ADDRESS_SPACE_MEMORY |
> -                  PCI_BASE_ADDRESS_MEM_TYPE_64) )
> +            /*The upper half is already calculated, skip it! */
> +            if (is_64bar)
>                  bar++;
>          }
> 
> @@ -197,6 +213,9 @@ void pci_setup(void)
>              ((pci_mem_start << 1) != 0) )
>          pci_mem_start <<= 1;
> 
> +    if ( (pci_mem_start << 1) != 0 )
> +        bar64_relocate = 1;
> +
>      /* Relocate RAM that overlaps PCI space (in 64k-page chunks). */
>      while ( (pci_mem_start >> PAGE_SHIFT) < hvm_info->low_mem_pgend )
>      {
> @@ -218,11 +237,15 @@ void pci_setup(void)
>          hvm_info->high_mem_pgend += nr_pages;
>      }
> 
> +    high_mem_resource.base = ((uint64_t)hvm_info->high_mem_pgend) <<
> PAGE_SHIFT;
> +    high_mem_resource.max = 1ull << cpu_phys_addr();
>      mem_resource.base = pci_mem_start;
>      mem_resource.max = pci_mem_end;
>      io_resource.base = 0xc000;
>      io_resource.max = 0x10000;
> 
> +    mmio_left = pci_mem_end - pci_mem_start;
> +
>      /* Assign iomem and ioport resources in descending order of size. */
>      for ( i = 0; i < nr_bars; i++ )
>      {
> @@ -230,13 +253,29 @@ void pci_setup(void)
>          bar_reg = bars[i].bar_reg;
>          bar_sz  = bars[i].bar_sz;
> 
> +        using_64bar = bars[i].is_64bar && bar64_relocate && (mmio_left <
> bar_sz);
>          bar_data = pci_readl(devfn, bar_reg);
> 
>          if ( (bar_data & PCI_BASE_ADDRESS_SPACE) ==
>               PCI_BASE_ADDRESS_SPACE_MEMORY )
>          {
> -            resource = &mem_resource;
> -            bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
> +            /* Mapping high memory if PCI deivce is 64 bits bar and the bar
> size
> +               is larger than 512M */
> +            if (using_64bar && (bar_sz > PCI_MIN_BIG_BAR_SIZE)) {
> +                if ( high_mem_resource.base & (bar_sz - 1) )
> +                    high_mem_resource.base =
> high_mem_resource.base -
> +                        (high_mem_resource.base & (bar_sz - 1)) +
> bar_sz;
> +                else
> +                    high_mem_resource.base =
> high_mem_resource.base -
> +                        (high_mem_resource.base & (bar_sz - 1));
> +                resource = &high_mem_resource;
> +                bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
> +            }
> +            else {
> +                resource = &mem_resource;
> +                bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
> +            }
> +            mmio_left -= bar_sz;
>          }
>          else
>          {
> @@ -244,13 +283,14 @@ void pci_setup(void)
>              bar_data &= ~PCI_BASE_ADDRESS_IO_MASK;
>          }
> 
> -        base = (resource->base + bar_sz - 1) & ~(bar_sz - 1);
> -        bar_data |= base;
> +        base = (resource->base  + bar_sz - 1) & ~(uint64_t)(bar_sz - 1);
> +        bar_data |= (uint32_t)base;
> +        bar_data_upper = (uint32_t)(base >> 32);
>          base += bar_sz;
> 
>          if ( (base < resource->base) || (base > resource->max) )
>          {
> -            printf("pci dev %02x:%x bar %02x size %08x: no space for "
> +            printf("pci dev %02x:%x bar %02x size %llx: no space for "
>                     "resource!\n", devfn>>3, devfn&7, bar_reg, bar_sz);
>              continue;
>          }
> @@ -258,8 +298,11 @@ void pci_setup(void)
>          resource->base = base;
> 
>          pci_writel(devfn, bar_reg, bar_data);
> -        printf("pci dev %02x:%x bar %02x size %08x: %08x\n",
> +        if (using_64bar)
> +            pci_writel(devfn, bar_reg + 4, bar_data_upper);
> +        printf("pci dev %02x:%x bar %02x size %llx: %08x\n",
>                 devfn>>3, devfn&7, bar_reg, bar_sz, bar_data);
> +
> 
>          /* Now enable the memory or I/O mapping. */
>          cmd = pci_readw(devfn, PCI_COMMAND);
> diff --git a/tools/firmware/hvmloader/util.h b/tools/firmware/hvmloader/util.h
> index 07a9d42..ff06071 100644
> --- a/tools/firmware/hvmloader/util.h
> +++ b/tools/firmware/hvmloader/util.h
> @@ -215,6 +215,7 @@ void pci_setup(void);
>  uint32_t rombios_highbios_setup(void);
> 
>  /* Miscellaneous. */
> +unsigned int cpu_phys_addr(void);
>  void cacheattr_init(void);
>  unsigned long create_mp_tables(void *table);
>  void hvm_write_smbios_tables(
> --
> 1.5.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 12:31:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 12:31:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLCUU-0002Y8-At; Mon, 08 Oct 2012 12:31:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLCUS-0002Y3-Bd
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 12:31:20 +0000
Received: from [85.158.143.35:49261] by server-3.bemta-4.messagelabs.com id
	98/EE-10986-797C2705; Mon, 08 Oct 2012 12:31:19 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1349699465!14326925!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMyNjc2Mg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10572 invoked from network); 8 Oct 2012 12:31:07 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-8.tower-21.messagelabs.com with SMTP;
	8 Oct 2012 12:31:07 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 08 Oct 2012 05:31:05 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,553,1344236400"; d="scan'208";a="231973177"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by fmsmga002.fm.intel.com with ESMTP; 08 Oct 2012 05:31:04 -0700
Received: from FMSMSX110.amr.corp.intel.com (10.19.9.29) by
	FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 8 Oct 2012 05:31:04 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	fmsmsx110.amr.corp.intel.com (10.19.9.29) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 8 Oct 2012 05:31:04 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.92]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.162]) with mapi id
	14.01.0355.002; Mon, 8 Oct 2012 20:31:02 +0800
From: "Hao, Xudong" 
To: "ian.campbell@citrix.com" , "keir@xen.org"
	
Thread-Topic: [PATCH v3] xen/tools: Add 64 bits big bar support
Thread-Index: AQHNm8GbNOE8aT1fVEaIth3aKGlXepevaYGA
Date: Mon, 8 Oct 2012 12:31:00 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FECC549@SHSMSX102.ccr.corp.intel.com>
References: <1348648582-11461-1-git-send-email-xudong.hao@intel.com>
In-Reply-To: <1348648582-11461-1-git-send-email-xudong.hao@intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "Stefano.Stabellini@eu.citrix.com" ,
	"Zhang, Xiantao" ,
	"jbeulich@suse.com" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH v3] xen/tools: Add 64 bits big bar support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, Ian and Keir

Do you have other comments for this patch?

Thanks,
-Xudong

> -----Original Message-----
> From: Hao, Xudong
> Sent: Wednesday, September 26, 2012 4:36 PM
> To: ian.campbell@citrix.com; keir@xen.org
> Cc: xen-devel@lists.xen.org; Stefano.Stabellini@eu.citrix.com;
> jbeulich@suse.com; Zhang, Xiantao; Hao, Xudong
> Subject: [PATCH v3] xen/tools: Add 64 bits big bar support
> 
> Currently it is assumed PCI device BAR access < 4G memory. If there is such a
> device whose BAR size is larger than 4G, it must access > 4G memory address.
> This patch enable the 64bits big BAR support on hvmloader.
> 
> v3 changes from v2:
> - Remain original print information
> 
> v2 changes from v1 as comments by Jan.
> 1) Set Dynamic MMIO high memory address instead of a fixed number 640G
> 2) Mask bar_sz earlier to avoid older code changes
> 3) Add bar size barrier to judge high memory resource
> 4) Clean up bar64_relocate code
> 
> Signed-off-by: Xiantao Zhang 
> Signed-off-by: Xudong Hao 
> ---
>  tools/firmware/hvmloader/cacheattr.c |   25 +++++++----
>  tools/firmware/hvmloader/config.h    |    2 +
>  tools/firmware/hvmloader/pci.c       |   77
> ++++++++++++++++++++++++++-------
>  tools/firmware/hvmloader/util.h      |    1 +
>  4 files changed, 80 insertions(+), 25 deletions(-)
> 
> diff --git a/tools/firmware/hvmloader/cacheattr.c
> b/tools/firmware/hvmloader/cacheattr.c
> index 646f07f..592b455 100644
> --- a/tools/firmware/hvmloader/cacheattr.c
> +++ b/tools/firmware/hvmloader/cacheattr.c
> @@ -40,24 +40,33 @@
>  #define MSR_PAT              0x0277
>  #define MSR_MTRRdefType      0x02ff
> 
> +unsigned int cpu_phys_addr(void)
> +{
> +    uint32_t eax, ebx, ecx, edx;
> +    unsigned int phys_bits = 36;
> +    /* Find the physical address size for this CPU. */
> +    cpuid(0x80000000, &eax, &ebx, &ecx, &edx);
> +    if ( eax >= 0x80000008 )
> +    {
> +        cpuid(0x80000008, &eax, &ebx, &ecx, &edx);
> +        phys_bits = (uint8_t)eax;
> +    }
> +
> +    return phys_bits;
> +}
> +
>  void cacheattr_init(void)
>  {
>      uint32_t eax, ebx, ecx, edx;
>      uint64_t mtrr_cap, mtrr_def, content, addr_mask;
> -    unsigned int i, nr_var_ranges, phys_bits = 36;
> +    unsigned int i, nr_var_ranges, phys_bits;
> 
>      /* Does the CPU support architectural MTRRs? */
>      cpuid(0x00000001, &eax, &ebx, &ecx, &edx);
>      if ( !(edx & (1u << 12)) )
>           return;
> 
> -    /* Find the physical address size for this CPU. */
> -    cpuid(0x80000000, &eax, &ebx, &ecx, &edx);
> -    if ( eax >= 0x80000008 )
> -    {
> -        cpuid(0x80000008, &eax, &ebx, &ecx, &edx);
> -        phys_bits = (uint8_t)eax;
> -    }
> +    phys_bits = cpu_phys_addr();
> 
>      printf("%u-bit phys ... ", phys_bits);
> 
> diff --git a/tools/firmware/hvmloader/config.h
> b/tools/firmware/hvmloader/config.h
> index 7c0180d..bbf2993 100644
> --- a/tools/firmware/hvmloader/config.h
> +++ b/tools/firmware/hvmloader/config.h
> @@ -53,6 +53,8 @@ extern struct bios_config ovmf_config;
>  /* MMIO hole: Hardcoded defaults, which can be dynamically expanded. */
>  #define PCI_MEM_START       0xf0000000
>  #define PCI_MEM_END         0xfc000000
> +#define PCI_MIN_BIG_BAR_SIZE          0x20000000
> +
>  extern unsigned long pci_mem_start, pci_mem_end;
> 
> 
> diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
> index fd56e50..0500db5 100644
> --- a/tools/firmware/hvmloader/pci.c
> +++ b/tools/firmware/hvmloader/pci.c
> @@ -36,19 +36,25 @@ unsigned long igd_opregion_pgbase = 0;
> 
>  void pci_setup(void)
>  {
> -    uint32_t base, devfn, bar_reg, bar_data, bar_sz, cmd, mmio_total = 0;
> +    uint8_t is_64bar, using_64bar, bar64_relocate = 0;
> +    uint32_t devfn, bar_reg, cmd, bar_data, bar_data_upper;
> +    uint64_t base, bar_sz, bar_sz_upper, mmio_total = 0;
>      uint32_t vga_devfn = 256;
>      uint16_t class, vendor_id, device_id;
>      unsigned int bar, pin, link, isa_irq;
> +    int64_t mmio_left;
> 
>      /* Resources assignable to PCI devices via BARs. */
>      struct resource {
> -        uint32_t base, max;
> -    } *resource, mem_resource, io_resource;
> +        uint64_t base, max;
> +    } *resource, mem_resource, high_mem_resource, io_resource;
> 
>      /* Create a list of device BARs in descending order of size. */
>      struct bars {
> -        uint32_t devfn, bar_reg, bar_sz;
> +        uint32_t is_64bar;
> +        uint32_t devfn;
> +        uint32_t bar_reg;
> +        uint64_t bar_sz;
>      } *bars = (struct bars *)scratch_start;
>      unsigned int i, nr_bars = 0;
> 
> @@ -133,22 +139,34 @@ void pci_setup(void)
>          /* Map the I/O memory and port resources. */
>          for ( bar = 0; bar < 7; bar++ )
>          {
> +            bar_sz_upper = 0;
>              bar_reg = PCI_BASE_ADDRESS_0 + 4*bar;
>              if ( bar == 6 )
>                  bar_reg = PCI_ROM_ADDRESS;
> 
>              bar_data = pci_readl(devfn, bar_reg);
> +            is_64bar = !!((bar_data & (PCI_BASE_ADDRESS_SPACE |
> +                         PCI_BASE_ADDRESS_MEM_TYPE_MASK)) ==
> +                         (PCI_BASE_ADDRESS_SPACE_MEMORY |
> +                         PCI_BASE_ADDRESS_MEM_TYPE_64));
>              pci_writel(devfn, bar_reg, ~0);
>              bar_sz = pci_readl(devfn, bar_reg);
>              pci_writel(devfn, bar_reg, bar_data);
> -            if ( bar_sz == 0 )
> -                continue;
> 
>              bar_sz &= (((bar_data & PCI_BASE_ADDRESS_SPACE) ==
>                          PCI_BASE_ADDRESS_SPACE_MEMORY) ?
>                         PCI_BASE_ADDRESS_MEM_MASK :
>                         (PCI_BASE_ADDRESS_IO_MASK & 0xffff));
> +            if (is_64bar) {
> +                bar_data_upper = pci_readl(devfn, bar_reg + 4);
> +                pci_writel(devfn, bar_reg + 4, ~0);
> +                bar_sz_upper = pci_readl(devfn, bar_reg + 4);
> +                pci_writel(devfn, bar_reg + 4, bar_data_upper);
> +                bar_sz = (bar_sz_upper << 32) | bar_sz;
> +            }
>              bar_sz &= ~(bar_sz - 1);
> +            if ( bar_sz == 0 )
> +                continue;
> 
>              for ( i = 0; i < nr_bars; i++ )
>                  if ( bars[i].bar_sz < bar_sz )
> @@ -157,6 +175,7 @@ void pci_setup(void)
>              if ( i != nr_bars )
>                  memmove(&bars[i+1], &bars[i], (nr_bars-i) *
> sizeof(*bars));
> 
> +            bars[i].is_64bar = is_64bar;
>              bars[i].devfn   = devfn;
>              bars[i].bar_reg = bar_reg;
>              bars[i].bar_sz  = bar_sz;
> @@ -167,11 +186,8 @@ void pci_setup(void)
> 
>              nr_bars++;
> 
> -            /* Skip the upper-half of the address for a 64-bit BAR. */
> -            if ( (bar_data & (PCI_BASE_ADDRESS_SPACE |
> -                              PCI_BASE_ADDRESS_MEM_TYPE_MASK))
> ==
> -                 (PCI_BASE_ADDRESS_SPACE_MEMORY |
> -                  PCI_BASE_ADDRESS_MEM_TYPE_64) )
> +            /*The upper half is already calculated, skip it! */
> +            if (is_64bar)
>                  bar++;
>          }
> 
> @@ -197,6 +213,9 @@ void pci_setup(void)
>              ((pci_mem_start << 1) != 0) )
>          pci_mem_start <<= 1;
> 
> +    if ( (pci_mem_start << 1) != 0 )
> +        bar64_relocate = 1;
> +
>      /* Relocate RAM that overlaps PCI space (in 64k-page chunks). */
>      while ( (pci_mem_start >> PAGE_SHIFT) < hvm_info->low_mem_pgend )
>      {
> @@ -218,11 +237,15 @@ void pci_setup(void)
>          hvm_info->high_mem_pgend += nr_pages;
>      }
> 
> +    high_mem_resource.base = ((uint64_t)hvm_info->high_mem_pgend) <<
> PAGE_SHIFT;
> +    high_mem_resource.max = 1ull << cpu_phys_addr();
>      mem_resource.base = pci_mem_start;
>      mem_resource.max = pci_mem_end;
>      io_resource.base = 0xc000;
>      io_resource.max = 0x10000;
> 
> +    mmio_left = pci_mem_end - pci_mem_start;
> +
>      /* Assign iomem and ioport resources in descending order of size. */
>      for ( i = 0; i < nr_bars; i++ )
>      {
> @@ -230,13 +253,29 @@ void pci_setup(void)
>          bar_reg = bars[i].bar_reg;
>          bar_sz  = bars[i].bar_sz;
> 
> +        using_64bar = bars[i].is_64bar && bar64_relocate && (mmio_left <
> bar_sz);
>          bar_data = pci_readl(devfn, bar_reg);
> 
>          if ( (bar_data & PCI_BASE_ADDRESS_SPACE) ==
>               PCI_BASE_ADDRESS_SPACE_MEMORY )
>          {
> -            resource = &mem_resource;
> -            bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
> +            /* Mapping high memory if PCI deivce is 64 bits bar and the bar
> size
> +               is larger than 512M */
> +            if (using_64bar && (bar_sz > PCI_MIN_BIG_BAR_SIZE)) {
> +                if ( high_mem_resource.base & (bar_sz - 1) )
> +                    high_mem_resource.base =
> high_mem_resource.base -
> +                        (high_mem_resource.base & (bar_sz - 1)) +
> bar_sz;
> +                else
> +                    high_mem_resource.base =
> high_mem_resource.base -
> +                        (high_mem_resource.base & (bar_sz - 1));
> +                resource = &high_mem_resource;
> +                bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
> +            }
> +            else {
> +                resource = &mem_resource;
> +                bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
> +            }
> +            mmio_left -= bar_sz;
>          }
>          else
>          {
> @@ -244,13 +283,14 @@ void pci_setup(void)
>              bar_data &= ~PCI_BASE_ADDRESS_IO_MASK;
>          }
> 
> -        base = (resource->base + bar_sz - 1) & ~(bar_sz - 1);
> -        bar_data |= base;
> +        base = (resource->base  + bar_sz - 1) & ~(uint64_t)(bar_sz - 1);
> +        bar_data |= (uint32_t)base;
> +        bar_data_upper = (uint32_t)(base >> 32);
>          base += bar_sz;
> 
>          if ( (base < resource->base) || (base > resource->max) )
>          {
> -            printf("pci dev %02x:%x bar %02x size %08x: no space for "
> +            printf("pci dev %02x:%x bar %02x size %llx: no space for "
>                     "resource!\n", devfn>>3, devfn&7, bar_reg, bar_sz);
>              continue;
>          }
> @@ -258,8 +298,11 @@ void pci_setup(void)
>          resource->base = base;
> 
>          pci_writel(devfn, bar_reg, bar_data);
> -        printf("pci dev %02x:%x bar %02x size %08x: %08x\n",
> +        if (using_64bar)
> +            pci_writel(devfn, bar_reg + 4, bar_data_upper);
> +        printf("pci dev %02x:%x bar %02x size %llx: %08x\n",
>                 devfn>>3, devfn&7, bar_reg, bar_sz, bar_data);
> +
> 
>          /* Now enable the memory or I/O mapping. */
>          cmd = pci_readw(devfn, PCI_COMMAND);
> diff --git a/tools/firmware/hvmloader/util.h b/tools/firmware/hvmloader/util.h
> index 07a9d42..ff06071 100644
> --- a/tools/firmware/hvmloader/util.h
> +++ b/tools/firmware/hvmloader/util.h
> @@ -215,6 +215,7 @@ void pci_setup(void);
>  uint32_t rombios_highbios_setup(void);
> 
>  /* Miscellaneous. */
> +unsigned int cpu_phys_addr(void);
>  void cacheattr_init(void);
>  unsigned long create_mp_tables(void *table);
>  void hvm_write_smbios_tables(
> --
> 1.5.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 12:32:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 12:32:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLCVb-0002cJ-QD; Mon, 08 Oct 2012 12:32:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLCVa-0002c8-RV
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 12:32:31 +0000
Received: from [85.158.138.51:61512] by server-14.bemta-3.messagelabs.com id
	DB/E4-19528-CD7C2705; Mon, 08 Oct 2012 12:32:28 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1349699545!33501403!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22077 invoked from network); 8 Oct 2012 12:32:26 -0000
Received: from mail-qc0-f171.google.com (HELO mail-qc0-f171.google.com)
	(209.85.216.171)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 12:32:26 -0000
Received: by mail-qc0-f171.google.com with SMTP id d1so169968qca.30
	for ;
	Mon, 08 Oct 2012 05:32:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=UtbFGZ8H1E1emmsdG0Np21Ja0e48ZM3Lx7LCSiNvaUQ=;
	b=EMAMZqXkHOGShKj1YzfuvvI9+wu156eUt3atl0O+rsfqQfXgBUjtXHhwW1WLrN56EE
	9IAC9UvwR8aaTdbrtZ6m1FDoIDh8CjxiWNhX0AqXW1ec0yw8GphBAHACfVYpu6j/+ie1
	aB4F3VuyKErWbhj3xElBuOTLNJmZzYnYfanJf0wfOI6+jZAOL904qsm4g+xntlCcNfip
	nbvwmbLfGz1cBIXVpp1Am4PYyb2gkjabRKl47rsdUADdanG2rpBxHiXMzDctKGMg00Eq
	QKsj4hjGM2iX2uEU1tg88VBEhHeVipwfamlmuyjVkCBswcy41Sj0HvAa/l922efBruky
	OxLg==
Received: by 10.49.3.234 with SMTP id f10mr41138722qef.45.1349699545443;
	Mon, 08 Oct 2012 05:32:25 -0700 (PDT)
Received: from localhost.localdomain
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id c9sm17659805qeh.1.2012.10.08.05.32.24
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 08 Oct 2012 05:32:24 -0700 (PDT)
Date: Mon, 8 Oct 2012 08:32:19 -0400
From: Konrad Rzeszutek Wilk 
To: Andi Reinbrech 
Message-ID: <20121008123218.GA29650@localhost.localdomain>
References: <1349511963.3350.15.camel@multiplex>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1349511963.3350.15.camel@multiplex>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Xen Devel List 
Subject: Re: [Xen-devel] Can create PV domain in 4.2 only with xm and not xl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Oct 06, 2012 at 10:26:03AM +0200, Andi Reinbrech wrote:
> Hi Xenners,
> 
> This problem has been cropping up since late 4.2-unstable builds:  I can
> create all my HVM guests (windows 7, 8, XP and XP64) with xl create, but
> my existing PV guests (Fedora based) don't start.  They either hang or
> time out with an error that they can't connect to a vbd backend device.
> 
> This happens after the GRUB menu, so the bootloader is in fact accessed.
> 
> The strangest thing is, that by starting xend and creating the same
> domain with xm create works 100%, but after stopping xend afterwards I
> cannot create any more domains with xl, because udev gets messed up
> between xm and xl.  Obviously I shouldn't, and don't want to mix the
> two.
> 
> Another strange thing is that xl create on this same domain works fine
> on kernel 3.5...  But I can't use kernel >=3.5, as the PCI USB
> passthrough is broken.

The last of the patches for that should show up in the 3.5.x branch.
And also in 3.6. Look for:

c341ca45ce56143804ef5a8f4db753e554e640b4
Author: Konrad Rzeszutek Wilk 
Date:   Tue Sep 25 16:48:24 2012 -0400

    xen/pciback: Restore the PCI config space after an FLR.

> 
> So I am sitting with a catch-22: use kernel 3.5/3.6 and have xl work for
> all domains, but can't use my HVM Windows machine that needs PCI
> passthrough for VGA and USB, or use only kernel 3.3.4, but can't start
> PV domains unless I use xend.

> 
> Any suggestions would be appreciated!  If I need to send configs or
> logs, please let me know.
> 
> Kind regards,
> Andi
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 12:32:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 12:32:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLCVb-0002cJ-QD; Mon, 08 Oct 2012 12:32:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLCVa-0002c8-RV
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 12:32:31 +0000
Received: from [85.158.138.51:61512] by server-14.bemta-3.messagelabs.com id
	DB/E4-19528-CD7C2705; Mon, 08 Oct 2012 12:32:28 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1349699545!33501403!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22077 invoked from network); 8 Oct 2012 12:32:26 -0000
Received: from mail-qc0-f171.google.com (HELO mail-qc0-f171.google.com)
	(209.85.216.171)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 12:32:26 -0000
Received: by mail-qc0-f171.google.com with SMTP id d1so169968qca.30
	for ;
	Mon, 08 Oct 2012 05:32:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=UtbFGZ8H1E1emmsdG0Np21Ja0e48ZM3Lx7LCSiNvaUQ=;
	b=EMAMZqXkHOGShKj1YzfuvvI9+wu156eUt3atl0O+rsfqQfXgBUjtXHhwW1WLrN56EE
	9IAC9UvwR8aaTdbrtZ6m1FDoIDh8CjxiWNhX0AqXW1ec0yw8GphBAHACfVYpu6j/+ie1
	aB4F3VuyKErWbhj3xElBuOTLNJmZzYnYfanJf0wfOI6+jZAOL904qsm4g+xntlCcNfip
	nbvwmbLfGz1cBIXVpp1Am4PYyb2gkjabRKl47rsdUADdanG2rpBxHiXMzDctKGMg00Eq
	QKsj4hjGM2iX2uEU1tg88VBEhHeVipwfamlmuyjVkCBswcy41Sj0HvAa/l922efBruky
	OxLg==
Received: by 10.49.3.234 with SMTP id f10mr41138722qef.45.1349699545443;
	Mon, 08 Oct 2012 05:32:25 -0700 (PDT)
Received: from localhost.localdomain
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id c9sm17659805qeh.1.2012.10.08.05.32.24
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 08 Oct 2012 05:32:24 -0700 (PDT)
Date: Mon, 8 Oct 2012 08:32:19 -0400
From: Konrad Rzeszutek Wilk 
To: Andi Reinbrech 
Message-ID: <20121008123218.GA29650@localhost.localdomain>
References: <1349511963.3350.15.camel@multiplex>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1349511963.3350.15.camel@multiplex>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Xen Devel List 
Subject: Re: [Xen-devel] Can create PV domain in 4.2 only with xm and not xl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Oct 06, 2012 at 10:26:03AM +0200, Andi Reinbrech wrote:
> Hi Xenners,
> 
> This problem has been cropping up since late 4.2-unstable builds:  I can
> create all my HVM guests (windows 7, 8, XP and XP64) with xl create, but
> my existing PV guests (Fedora based) don't start.  They either hang or
> time out with an error that they can't connect to a vbd backend device.
> 
> This happens after the GRUB menu, so the bootloader is in fact accessed.
> 
> The strangest thing is, that by starting xend and creating the same
> domain with xm create works 100%, but after stopping xend afterwards I
> cannot create any more domains with xl, because udev gets messed up
> between xm and xl.  Obviously I shouldn't, and don't want to mix the
> two.
> 
> Another strange thing is that xl create on this same domain works fine
> on kernel 3.5...  But I can't use kernel >=3.5, as the PCI USB
> passthrough is broken.

The last of the patches for that should show up in the 3.5.x branch.
And also in 3.6. Look for:

c341ca45ce56143804ef5a8f4db753e554e640b4
Author: Konrad Rzeszutek Wilk 
Date:   Tue Sep 25 16:48:24 2012 -0400

    xen/pciback: Restore the PCI config space after an FLR.

> 
> So I am sitting with a catch-22: use kernel 3.5/3.6 and have xl work for
> all domains, but can't use my HVM Windows machine that needs PCI
> passthrough for VGA and USB, or use only kernel 3.3.4, but can't start
> PV domains unless I use xend.

> 
> Any suggestions would be appreciated!  If I need to send configs or
> logs, please let me know.
> 
> Kind regards,
> Andi
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 12:36:26 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 12:36:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLCZ9-0002sZ-Ek; Mon, 08 Oct 2012 12:36:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLCZ7-0002sP-UI
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 12:36:10 +0000
Received: from [85.158.138.51:20994] by server-5.bemta-3.messagelabs.com id
	26/CC-00589-8B8C2705; Mon, 08 Oct 2012 12:36:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1349699768!33432995!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMzNDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32450 invoked from network); 8 Oct 2012 12:36:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 12:36:08 -0000
X-IronPort-AV: E=Sophos;i="4.80,554,1344211200"; d="scan'208";a="15000693"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 12:34:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 8 Oct 2012
	13:34:49 +0100
Message-ID: <1349699688.21847.5.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: "Hao, Xudong" 
Date: Mon, 8 Oct 2012 13:34:48 +0100
In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FECC549@SHSMSX102.ccr.corp.intel.com>
References: <1348648582-11461-1-git-send-email-xudong.hao@intel.com>
	<403610A45A2B5242BD291EDAE8B37D300FECC549@SHSMSX102.ccr.corp.intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	"Keir \(Xen.org\)" , "Zhang,
	Xiantao" ,
	"jbeulich@suse.com" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH v3] xen/tools: Add 64 bits big bar support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Didn't Keir already check this in last week?

On Mon, 2012-10-08 at 13:31 +0100, Hao, Xudong wrote:
> Hi, Ian and Keir
> 
> Do you have other comments for this patch?
> 
> Thanks,
> -Xudong
> 
> > -----Original Message-----
> > From: Hao, Xudong
> > Sent: Wednesday, September 26, 2012 4:36 PM
> > To: ian.campbell@citrix.com; keir@xen.org
> > Cc: xen-devel@lists.xen.org; Stefano.Stabellini@eu.citrix.com;
> > jbeulich@suse.com; Zhang, Xiantao; Hao, Xudong
> > Subject: [PATCH v3] xen/tools: Add 64 bits big bar support
> > 
> > Currently it is assumed PCI device BAR access < 4G memory. If there is such a
> > device whose BAR size is larger than 4G, it must access > 4G memory address.
> > This patch enable the 64bits big BAR support on hvmloader.
> > 
> > v3 changes from v2:
> > - Remain original print information
> > 
> > v2 changes from v1 as comments by Jan.
> > 1) Set Dynamic MMIO high memory address instead of a fixed number 640G
> > 2) Mask bar_sz earlier to avoid older code changes
> > 3) Add bar size barrier to judge high memory resource
> > 4) Clean up bar64_relocate code
> > 
> > Signed-off-by: Xiantao Zhang 
> > Signed-off-by: Xudong Hao 
> > ---
> >  tools/firmware/hvmloader/cacheattr.c |   25 +++++++----
> >  tools/firmware/hvmloader/config.h    |    2 +
> >  tools/firmware/hvmloader/pci.c       |   77
> > ++++++++++++++++++++++++++-------
> >  tools/firmware/hvmloader/util.h      |    1 +
> >  4 files changed, 80 insertions(+), 25 deletions(-)
> > 
> > diff --git a/tools/firmware/hvmloader/cacheattr.c
> > b/tools/firmware/hvmloader/cacheattr.c
> > index 646f07f..592b455 100644
> > --- a/tools/firmware/hvmloader/cacheattr.c
> > +++ b/tools/firmware/hvmloader/cacheattr.c
> > @@ -40,24 +40,33 @@
> >  #define MSR_PAT              0x0277
> >  #define MSR_MTRRdefType      0x02ff
> > 
> > +unsigned int cpu_phys_addr(void)
> > +{
> > +    uint32_t eax, ebx, ecx, edx;
> > +    unsigned int phys_bits = 36;
> > +    /* Find the physical address size for this CPU. */
> > +    cpuid(0x80000000, &eax, &ebx, &ecx, &edx);
> > +    if ( eax >= 0x80000008 )
> > +    {
> > +        cpuid(0x80000008, &eax, &ebx, &ecx, &edx);
> > +        phys_bits = (uint8_t)eax;
> > +    }
> > +
> > +    return phys_bits;
> > +}
> > +
> >  void cacheattr_init(void)
> >  {
> >      uint32_t eax, ebx, ecx, edx;
> >      uint64_t mtrr_cap, mtrr_def, content, addr_mask;
> > -    unsigned int i, nr_var_ranges, phys_bits = 36;
> > +    unsigned int i, nr_var_ranges, phys_bits;
> > 
> >      /* Does the CPU support architectural MTRRs? */
> >      cpuid(0x00000001, &eax, &ebx, &ecx, &edx);
> >      if ( !(edx & (1u << 12)) )
> >           return;
> > 
> > -    /* Find the physical address size for this CPU. */
> > -    cpuid(0x80000000, &eax, &ebx, &ecx, &edx);
> > -    if ( eax >= 0x80000008 )
> > -    {
> > -        cpuid(0x80000008, &eax, &ebx, &ecx, &edx);
> > -        phys_bits = (uint8_t)eax;
> > -    }
> > +    phys_bits = cpu_phys_addr();
> > 
> >      printf("%u-bit phys ... ", phys_bits);
> > 
> > diff --git a/tools/firmware/hvmloader/config.h
> > b/tools/firmware/hvmloader/config.h
> > index 7c0180d..bbf2993 100644
> > --- a/tools/firmware/hvmloader/config.h
> > +++ b/tools/firmware/hvmloader/config.h
> > @@ -53,6 +53,8 @@ extern struct bios_config ovmf_config;
> >  /* MMIO hole: Hardcoded defaults, which can be dynamically expanded. */
> >  #define PCI_MEM_START       0xf0000000
> >  #define PCI_MEM_END         0xfc000000
> > +#define PCI_MIN_BIG_BAR_SIZE          0x20000000
> > +
> >  extern unsigned long pci_mem_start, pci_mem_end;
> > 
> > 
> > diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
> > index fd56e50..0500db5 100644
> > --- a/tools/firmware/hvmloader/pci.c
> > +++ b/tools/firmware/hvmloader/pci.c
> > @@ -36,19 +36,25 @@ unsigned long igd_opregion_pgbase = 0;
> > 
> >  void pci_setup(void)
> >  {
> > -    uint32_t base, devfn, bar_reg, bar_data, bar_sz, cmd, mmio_total = 0;
> > +    uint8_t is_64bar, using_64bar, bar64_relocate = 0;
> > +    uint32_t devfn, bar_reg, cmd, bar_data, bar_data_upper;
> > +    uint64_t base, bar_sz, bar_sz_upper, mmio_total = 0;
> >      uint32_t vga_devfn = 256;
> >      uint16_t class, vendor_id, device_id;
> >      unsigned int bar, pin, link, isa_irq;
> > +    int64_t mmio_left;
> > 
> >      /* Resources assignable to PCI devices via BARs. */
> >      struct resource {
> > -        uint32_t base, max;
> > -    } *resource, mem_resource, io_resource;
> > +        uint64_t base, max;
> > +    } *resource, mem_resource, high_mem_resource, io_resource;
> > 
> >      /* Create a list of device BARs in descending order of size. */
> >      struct bars {
> > -        uint32_t devfn, bar_reg, bar_sz;
> > +        uint32_t is_64bar;
> > +        uint32_t devfn;
> > +        uint32_t bar_reg;
> > +        uint64_t bar_sz;
> >      } *bars = (struct bars *)scratch_start;
> >      unsigned int i, nr_bars = 0;
> > 
> > @@ -133,22 +139,34 @@ void pci_setup(void)
> >          /* Map the I/O memory and port resources. */
> >          for ( bar = 0; bar < 7; bar++ )
> >          {
> > +            bar_sz_upper = 0;
> >              bar_reg = PCI_BASE_ADDRESS_0 + 4*bar;
> >              if ( bar == 6 )
> >                  bar_reg = PCI_ROM_ADDRESS;
> > 
> >              bar_data = pci_readl(devfn, bar_reg);
> > +            is_64bar = !!((bar_data & (PCI_BASE_ADDRESS_SPACE |
> > +                         PCI_BASE_ADDRESS_MEM_TYPE_MASK)) ==
> > +                         (PCI_BASE_ADDRESS_SPACE_MEMORY |
> > +                         PCI_BASE_ADDRESS_MEM_TYPE_64));
> >              pci_writel(devfn, bar_reg, ~0);
> >              bar_sz = pci_readl(devfn, bar_reg);
> >              pci_writel(devfn, bar_reg, bar_data);
> > -            if ( bar_sz == 0 )
> > -                continue;
> > 
> >              bar_sz &= (((bar_data & PCI_BASE_ADDRESS_SPACE) ==
> >                          PCI_BASE_ADDRESS_SPACE_MEMORY) ?
> >                         PCI_BASE_ADDRESS_MEM_MASK :
> >                         (PCI_BASE_ADDRESS_IO_MASK & 0xffff));
> > +            if (is_64bar) {
> > +                bar_data_upper = pci_readl(devfn, bar_reg + 4);
> > +                pci_writel(devfn, bar_reg + 4, ~0);
> > +                bar_sz_upper = pci_readl(devfn, bar_reg + 4);
> > +                pci_writel(devfn, bar_reg + 4, bar_data_upper);
> > +                bar_sz = (bar_sz_upper << 32) | bar_sz;
> > +            }
> >              bar_sz &= ~(bar_sz - 1);
> > +            if ( bar_sz == 0 )
> > +                continue;
> > 
> >              for ( i = 0; i < nr_bars; i++ )
> >                  if ( bars[i].bar_sz < bar_sz )
> > @@ -157,6 +175,7 @@ void pci_setup(void)
> >              if ( i != nr_bars )
> >                  memmove(&bars[i+1], &bars[i], (nr_bars-i) *
> > sizeof(*bars));
> > 
> > +            bars[i].is_64bar = is_64bar;
> >              bars[i].devfn   = devfn;
> >              bars[i].bar_reg = bar_reg;
> >              bars[i].bar_sz  = bar_sz;
> > @@ -167,11 +186,8 @@ void pci_setup(void)
> > 
> >              nr_bars++;
> > 
> > -            /* Skip the upper-half of the address for a 64-bit BAR. */
> > -            if ( (bar_data & (PCI_BASE_ADDRESS_SPACE |
> > -                              PCI_BASE_ADDRESS_MEM_TYPE_MASK))
> > ==
> > -                 (PCI_BASE_ADDRESS_SPACE_MEMORY |
> > -                  PCI_BASE_ADDRESS_MEM_TYPE_64) )
> > +            /*The upper half is already calculated, skip it! */
> > +            if (is_64bar)
> >                  bar++;
> >          }
> > 
> > @@ -197,6 +213,9 @@ void pci_setup(void)
> >              ((pci_mem_start << 1) != 0) )
> >          pci_mem_start <<= 1;
> > 
> > +    if ( (pci_mem_start << 1) != 0 )
> > +        bar64_relocate = 1;
> > +
> >      /* Relocate RAM that overlaps PCI space (in 64k-page chunks). */
> >      while ( (pci_mem_start >> PAGE_SHIFT) < hvm_info->low_mem_pgend )
> >      {
> > @@ -218,11 +237,15 @@ void pci_setup(void)
> >          hvm_info->high_mem_pgend += nr_pages;
> >      }
> > 
> > +    high_mem_resource.base = ((uint64_t)hvm_info->high_mem_pgend) <<
> > PAGE_SHIFT;
> > +    high_mem_resource.max = 1ull << cpu_phys_addr();
> >      mem_resource.base = pci_mem_start;
> >      mem_resource.max = pci_mem_end;
> >      io_resource.base = 0xc000;
> >      io_resource.max = 0x10000;
> > 
> > +    mmio_left = pci_mem_end - pci_mem_start;
> > +
> >      /* Assign iomem and ioport resources in descending order of size. */
> >      for ( i = 0; i < nr_bars; i++ )
> >      {
> > @@ -230,13 +253,29 @@ void pci_setup(void)
> >          bar_reg = bars[i].bar_reg;
> >          bar_sz  = bars[i].bar_sz;
> > 
> > +        using_64bar = bars[i].is_64bar && bar64_relocate && (mmio_left <
> > bar_sz);
> >          bar_data = pci_readl(devfn, bar_reg);
> > 
> >          if ( (bar_data & PCI_BASE_ADDRESS_SPACE) ==
> >               PCI_BASE_ADDRESS_SPACE_MEMORY )
> >          {
> > -            resource = &mem_resource;
> > -            bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
> > +            /* Mapping high memory if PCI deivce is 64 bits bar and the bar
> > size
> > +               is larger than 512M */
> > +            if (using_64bar && (bar_sz > PCI_MIN_BIG_BAR_SIZE)) {
> > +                if ( high_mem_resource.base & (bar_sz - 1) )
> > +                    high_mem_resource.base =
> > high_mem_resource.base -
> > +                        (high_mem_resource.base & (bar_sz - 1)) +
> > bar_sz;
> > +                else
> > +                    high_mem_resource.base =
> > high_mem_resource.base -
> > +                        (high_mem_resource.base & (bar_sz - 1));
> > +                resource = &high_mem_resource;
> > +                bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
> > +            }
> > +            else {
> > +                resource = &mem_resource;
> > +                bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
> > +            }
> > +            mmio_left -= bar_sz;
> >          }
> >          else
> >          {
> > @@ -244,13 +283,14 @@ void pci_setup(void)
> >              bar_data &= ~PCI_BASE_ADDRESS_IO_MASK;
> >          }
> > 
> > -        base = (resource->base + bar_sz - 1) & ~(bar_sz - 1);
> > -        bar_data |= base;
> > +        base = (resource->base  + bar_sz - 1) & ~(uint64_t)(bar_sz - 1);
> > +        bar_data |= (uint32_t)base;
> > +        bar_data_upper = (uint32_t)(base >> 32);
> >          base += bar_sz;
> > 
> >          if ( (base < resource->base) || (base > resource->max) )
> >          {
> > -            printf("pci dev %02x:%x bar %02x size %08x: no space for "
> > +            printf("pci dev %02x:%x bar %02x size %llx: no space for "
> >                     "resource!\n", devfn>>3, devfn&7, bar_reg, bar_sz);
> >              continue;
> >          }
> > @@ -258,8 +298,11 @@ void pci_setup(void)
> >          resource->base = base;
> > 
> >          pci_writel(devfn, bar_reg, bar_data);
> > -        printf("pci dev %02x:%x bar %02x size %08x: %08x\n",
> > +        if (using_64bar)
> > +            pci_writel(devfn, bar_reg + 4, bar_data_upper);
> > +        printf("pci dev %02x:%x bar %02x size %llx: %08x\n",
> >                 devfn>>3, devfn&7, bar_reg, bar_sz, bar_data);
> > +
> > 
> >          /* Now enable the memory or I/O mapping. */
> >          cmd = pci_readw(devfn, PCI_COMMAND);
> > diff --git a/tools/firmware/hvmloader/util.h b/tools/firmware/hvmloader/util.h
> > index 07a9d42..ff06071 100644
> > --- a/tools/firmware/hvmloader/util.h
> > +++ b/tools/firmware/hvmloader/util.h
> > @@ -215,6 +215,7 @@ void pci_setup(void);
> >  uint32_t rombios_highbios_setup(void);
> > 
> >  /* Miscellaneous. */
> > +unsigned int cpu_phys_addr(void);
> >  void cacheattr_init(void);
> >  unsigned long create_mp_tables(void *table);
> >  void hvm_write_smbios_tables(
> > --
> > 1.5.5
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 12:36:26 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 12:36:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLCZ9-0002sZ-Ek; Mon, 08 Oct 2012 12:36:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLCZ7-0002sP-UI
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 12:36:10 +0000
Received: from [85.158.138.51:20994] by server-5.bemta-3.messagelabs.com id
	26/CC-00589-8B8C2705; Mon, 08 Oct 2012 12:36:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1349699768!33432995!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMzNDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32450 invoked from network); 8 Oct 2012 12:36:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 12:36:08 -0000
X-IronPort-AV: E=Sophos;i="4.80,554,1344211200"; d="scan'208";a="15000693"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 12:34:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 8 Oct 2012
	13:34:49 +0100
Message-ID: <1349699688.21847.5.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: "Hao, Xudong" 
Date: Mon, 8 Oct 2012 13:34:48 +0100
In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FECC549@SHSMSX102.ccr.corp.intel.com>
References: <1348648582-11461-1-git-send-email-xudong.hao@intel.com>
	<403610A45A2B5242BD291EDAE8B37D300FECC549@SHSMSX102.ccr.corp.intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	"Keir \(Xen.org\)" , "Zhang,
	Xiantao" ,
	"jbeulich@suse.com" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH v3] xen/tools: Add 64 bits big bar support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Didn't Keir already check this in last week?

On Mon, 2012-10-08 at 13:31 +0100, Hao, Xudong wrote:
> Hi, Ian and Keir
> 
> Do you have other comments for this patch?
> 
> Thanks,
> -Xudong
> 
> > -----Original Message-----
> > From: Hao, Xudong
> > Sent: Wednesday, September 26, 2012 4:36 PM
> > To: ian.campbell@citrix.com; keir@xen.org
> > Cc: xen-devel@lists.xen.org; Stefano.Stabellini@eu.citrix.com;
> > jbeulich@suse.com; Zhang, Xiantao; Hao, Xudong
> > Subject: [PATCH v3] xen/tools: Add 64 bits big bar support
> > 
> > Currently it is assumed PCI device BAR access < 4G memory. If there is such a
> > device whose BAR size is larger than 4G, it must access > 4G memory address.
> > This patch enable the 64bits big BAR support on hvmloader.
> > 
> > v3 changes from v2:
> > - Remain original print information
> > 
> > v2 changes from v1 as comments by Jan.
> > 1) Set Dynamic MMIO high memory address instead of a fixed number 640G
> > 2) Mask bar_sz earlier to avoid older code changes
> > 3) Add bar size barrier to judge high memory resource
> > 4) Clean up bar64_relocate code
> > 
> > Signed-off-by: Xiantao Zhang 
> > Signed-off-by: Xudong Hao 
> > ---
> >  tools/firmware/hvmloader/cacheattr.c |   25 +++++++----
> >  tools/firmware/hvmloader/config.h    |    2 +
> >  tools/firmware/hvmloader/pci.c       |   77
> > ++++++++++++++++++++++++++-------
> >  tools/firmware/hvmloader/util.h      |    1 +
> >  4 files changed, 80 insertions(+), 25 deletions(-)
> > 
> > diff --git a/tools/firmware/hvmloader/cacheattr.c
> > b/tools/firmware/hvmloader/cacheattr.c
> > index 646f07f..592b455 100644
> > --- a/tools/firmware/hvmloader/cacheattr.c
> > +++ b/tools/firmware/hvmloader/cacheattr.c
> > @@ -40,24 +40,33 @@
> >  #define MSR_PAT              0x0277
> >  #define MSR_MTRRdefType      0x02ff
> > 
> > +unsigned int cpu_phys_addr(void)
> > +{
> > +    uint32_t eax, ebx, ecx, edx;
> > +    unsigned int phys_bits = 36;
> > +    /* Find the physical address size for this CPU. */
> > +    cpuid(0x80000000, &eax, &ebx, &ecx, &edx);
> > +    if ( eax >= 0x80000008 )
> > +    {
> > +        cpuid(0x80000008, &eax, &ebx, &ecx, &edx);
> > +        phys_bits = (uint8_t)eax;
> > +    }
> > +
> > +    return phys_bits;
> > +}
> > +
> >  void cacheattr_init(void)
> >  {
> >      uint32_t eax, ebx, ecx, edx;
> >      uint64_t mtrr_cap, mtrr_def, content, addr_mask;
> > -    unsigned int i, nr_var_ranges, phys_bits = 36;
> > +    unsigned int i, nr_var_ranges, phys_bits;
> > 
> >      /* Does the CPU support architectural MTRRs? */
> >      cpuid(0x00000001, &eax, &ebx, &ecx, &edx);
> >      if ( !(edx & (1u << 12)) )
> >           return;
> > 
> > -    /* Find the physical address size for this CPU. */
> > -    cpuid(0x80000000, &eax, &ebx, &ecx, &edx);
> > -    if ( eax >= 0x80000008 )
> > -    {
> > -        cpuid(0x80000008, &eax, &ebx, &ecx, &edx);
> > -        phys_bits = (uint8_t)eax;
> > -    }
> > +    phys_bits = cpu_phys_addr();
> > 
> >      printf("%u-bit phys ... ", phys_bits);
> > 
> > diff --git a/tools/firmware/hvmloader/config.h
> > b/tools/firmware/hvmloader/config.h
> > index 7c0180d..bbf2993 100644
> > --- a/tools/firmware/hvmloader/config.h
> > +++ b/tools/firmware/hvmloader/config.h
> > @@ -53,6 +53,8 @@ extern struct bios_config ovmf_config;
> >  /* MMIO hole: Hardcoded defaults, which can be dynamically expanded. */
> >  #define PCI_MEM_START       0xf0000000
> >  #define PCI_MEM_END         0xfc000000
> > +#define PCI_MIN_BIG_BAR_SIZE          0x20000000
> > +
> >  extern unsigned long pci_mem_start, pci_mem_end;
> > 
> > 
> > diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
> > index fd56e50..0500db5 100644
> > --- a/tools/firmware/hvmloader/pci.c
> > +++ b/tools/firmware/hvmloader/pci.c
> > @@ -36,19 +36,25 @@ unsigned long igd_opregion_pgbase = 0;
> > 
> >  void pci_setup(void)
> >  {
> > -    uint32_t base, devfn, bar_reg, bar_data, bar_sz, cmd, mmio_total = 0;
> > +    uint8_t is_64bar, using_64bar, bar64_relocate = 0;
> > +    uint32_t devfn, bar_reg, cmd, bar_data, bar_data_upper;
> > +    uint64_t base, bar_sz, bar_sz_upper, mmio_total = 0;
> >      uint32_t vga_devfn = 256;
> >      uint16_t class, vendor_id, device_id;
> >      unsigned int bar, pin, link, isa_irq;
> > +    int64_t mmio_left;
> > 
> >      /* Resources assignable to PCI devices via BARs. */
> >      struct resource {
> > -        uint32_t base, max;
> > -    } *resource, mem_resource, io_resource;
> > +        uint64_t base, max;
> > +    } *resource, mem_resource, high_mem_resource, io_resource;
> > 
> >      /* Create a list of device BARs in descending order of size. */
> >      struct bars {
> > -        uint32_t devfn, bar_reg, bar_sz;
> > +        uint32_t is_64bar;
> > +        uint32_t devfn;
> > +        uint32_t bar_reg;
> > +        uint64_t bar_sz;
> >      } *bars = (struct bars *)scratch_start;
> >      unsigned int i, nr_bars = 0;
> > 
> > @@ -133,22 +139,34 @@ void pci_setup(void)
> >          /* Map the I/O memory and port resources. */
> >          for ( bar = 0; bar < 7; bar++ )
> >          {
> > +            bar_sz_upper = 0;
> >              bar_reg = PCI_BASE_ADDRESS_0 + 4*bar;
> >              if ( bar == 6 )
> >                  bar_reg = PCI_ROM_ADDRESS;
> > 
> >              bar_data = pci_readl(devfn, bar_reg);
> > +            is_64bar = !!((bar_data & (PCI_BASE_ADDRESS_SPACE |
> > +                         PCI_BASE_ADDRESS_MEM_TYPE_MASK)) ==
> > +                         (PCI_BASE_ADDRESS_SPACE_MEMORY |
> > +                         PCI_BASE_ADDRESS_MEM_TYPE_64));
> >              pci_writel(devfn, bar_reg, ~0);
> >              bar_sz = pci_readl(devfn, bar_reg);
> >              pci_writel(devfn, bar_reg, bar_data);
> > -            if ( bar_sz == 0 )
> > -                continue;
> > 
> >              bar_sz &= (((bar_data & PCI_BASE_ADDRESS_SPACE) ==
> >                          PCI_BASE_ADDRESS_SPACE_MEMORY) ?
> >                         PCI_BASE_ADDRESS_MEM_MASK :
> >                         (PCI_BASE_ADDRESS_IO_MASK & 0xffff));
> > +            if (is_64bar) {
> > +                bar_data_upper = pci_readl(devfn, bar_reg + 4);
> > +                pci_writel(devfn, bar_reg + 4, ~0);
> > +                bar_sz_upper = pci_readl(devfn, bar_reg + 4);
> > +                pci_writel(devfn, bar_reg + 4, bar_data_upper);
> > +                bar_sz = (bar_sz_upper << 32) | bar_sz;
> > +            }
> >              bar_sz &= ~(bar_sz - 1);
> > +            if ( bar_sz == 0 )
> > +                continue;
> > 
> >              for ( i = 0; i < nr_bars; i++ )
> >                  if ( bars[i].bar_sz < bar_sz )
> > @@ -157,6 +175,7 @@ void pci_setup(void)
> >              if ( i != nr_bars )
> >                  memmove(&bars[i+1], &bars[i], (nr_bars-i) *
> > sizeof(*bars));
> > 
> > +            bars[i].is_64bar = is_64bar;
> >              bars[i].devfn   = devfn;
> >              bars[i].bar_reg = bar_reg;
> >              bars[i].bar_sz  = bar_sz;
> > @@ -167,11 +186,8 @@ void pci_setup(void)
> > 
> >              nr_bars++;
> > 
> > -            /* Skip the upper-half of the address for a 64-bit BAR. */
> > -            if ( (bar_data & (PCI_BASE_ADDRESS_SPACE |
> > -                              PCI_BASE_ADDRESS_MEM_TYPE_MASK))
> > ==
> > -                 (PCI_BASE_ADDRESS_SPACE_MEMORY |
> > -                  PCI_BASE_ADDRESS_MEM_TYPE_64) )
> > +            /*The upper half is already calculated, skip it! */
> > +            if (is_64bar)
> >                  bar++;
> >          }
> > 
> > @@ -197,6 +213,9 @@ void pci_setup(void)
> >              ((pci_mem_start << 1) != 0) )
> >          pci_mem_start <<= 1;
> > 
> > +    if ( (pci_mem_start << 1) != 0 )
> > +        bar64_relocate = 1;
> > +
> >      /* Relocate RAM that overlaps PCI space (in 64k-page chunks). */
> >      while ( (pci_mem_start >> PAGE_SHIFT) < hvm_info->low_mem_pgend )
> >      {
> > @@ -218,11 +237,15 @@ void pci_setup(void)
> >          hvm_info->high_mem_pgend += nr_pages;
> >      }
> > 
> > +    high_mem_resource.base = ((uint64_t)hvm_info->high_mem_pgend) <<
> > PAGE_SHIFT;
> > +    high_mem_resource.max = 1ull << cpu_phys_addr();
> >      mem_resource.base = pci_mem_start;
> >      mem_resource.max = pci_mem_end;
> >      io_resource.base = 0xc000;
> >      io_resource.max = 0x10000;
> > 
> > +    mmio_left = pci_mem_end - pci_mem_start;
> > +
> >      /* Assign iomem and ioport resources in descending order of size. */
> >      for ( i = 0; i < nr_bars; i++ )
> >      {
> > @@ -230,13 +253,29 @@ void pci_setup(void)
> >          bar_reg = bars[i].bar_reg;
> >          bar_sz  = bars[i].bar_sz;
> > 
> > +        using_64bar = bars[i].is_64bar && bar64_relocate && (mmio_left <
> > bar_sz);
> >          bar_data = pci_readl(devfn, bar_reg);
> > 
> >          if ( (bar_data & PCI_BASE_ADDRESS_SPACE) ==
> >               PCI_BASE_ADDRESS_SPACE_MEMORY )
> >          {
> > -            resource = &mem_resource;
> > -            bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
> > +            /* Mapping high memory if PCI deivce is 64 bits bar and the bar
> > size
> > +               is larger than 512M */
> > +            if (using_64bar && (bar_sz > PCI_MIN_BIG_BAR_SIZE)) {
> > +                if ( high_mem_resource.base & (bar_sz - 1) )
> > +                    high_mem_resource.base =
> > high_mem_resource.base -
> > +                        (high_mem_resource.base & (bar_sz - 1)) +
> > bar_sz;
> > +                else
> > +                    high_mem_resource.base =
> > high_mem_resource.base -
> > +                        (high_mem_resource.base & (bar_sz - 1));
> > +                resource = &high_mem_resource;
> > +                bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
> > +            }
> > +            else {
> > +                resource = &mem_resource;
> > +                bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
> > +            }
> > +            mmio_left -= bar_sz;
> >          }
> >          else
> >          {
> > @@ -244,13 +283,14 @@ void pci_setup(void)
> >              bar_data &= ~PCI_BASE_ADDRESS_IO_MASK;
> >          }
> > 
> > -        base = (resource->base + bar_sz - 1) & ~(bar_sz - 1);
> > -        bar_data |= base;
> > +        base = (resource->base  + bar_sz - 1) & ~(uint64_t)(bar_sz - 1);
> > +        bar_data |= (uint32_t)base;
> > +        bar_data_upper = (uint32_t)(base >> 32);
> >          base += bar_sz;
> > 
> >          if ( (base < resource->base) || (base > resource->max) )
> >          {
> > -            printf("pci dev %02x:%x bar %02x size %08x: no space for "
> > +            printf("pci dev %02x:%x bar %02x size %llx: no space for "
> >                     "resource!\n", devfn>>3, devfn&7, bar_reg, bar_sz);
> >              continue;
> >          }
> > @@ -258,8 +298,11 @@ void pci_setup(void)
> >          resource->base = base;
> > 
> >          pci_writel(devfn, bar_reg, bar_data);
> > -        printf("pci dev %02x:%x bar %02x size %08x: %08x\n",
> > +        if (using_64bar)
> > +            pci_writel(devfn, bar_reg + 4, bar_data_upper);
> > +        printf("pci dev %02x:%x bar %02x size %llx: %08x\n",
> >                 devfn>>3, devfn&7, bar_reg, bar_sz, bar_data);
> > +
> > 
> >          /* Now enable the memory or I/O mapping. */
> >          cmd = pci_readw(devfn, PCI_COMMAND);
> > diff --git a/tools/firmware/hvmloader/util.h b/tools/firmware/hvmloader/util.h
> > index 07a9d42..ff06071 100644
> > --- a/tools/firmware/hvmloader/util.h
> > +++ b/tools/firmware/hvmloader/util.h
> > @@ -215,6 +215,7 @@ void pci_setup(void);
> >  uint32_t rombios_highbios_setup(void);
> > 
> >  /* Miscellaneous. */
> > +unsigned int cpu_phys_addr(void);
> >  void cacheattr_init(void);
> >  unsigned long create_mp_tables(void *table);
> >  void hvm_write_smbios_tables(
> > --
> > 1.5.5
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 12:41:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 12:41:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLCdy-00034P-Fg; Mon, 08 Oct 2012 12:41:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLCdw-00034H-OU
	for Xen-devel@lists.xensource.com; Mon, 08 Oct 2012 12:41:08 +0000
Received: from [85.158.137.99:13992] by server-7.bemta-3.messagelabs.com id
	54/1F-15765-3E9C2705; Mon, 08 Oct 2012 12:41:07 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1349700066!15572511!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32301 invoked from network); 8 Oct 2012 12:41:07 -0000
Received: from mail-qc0-f171.google.com (HELO mail-qc0-f171.google.com)
	(209.85.216.171)
	by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 12:41:07 -0000
Received: by mail-qc0-f171.google.com with SMTP id d1so177476qca.30
	for ;
	Mon, 08 Oct 2012 05:41:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=OrrcgjUTLSPmi1ocKCS54pDd1642oPVRo4CciDvUgSg=;
	b=oNur6VhE8m+CzaY1XOX6ixHykD8+9wonpZo0+MhZqawIwgvt3MZoQfKyDaOx6JVKfL
	/0hsNNa///nPwLJ1NkQ9xU7Y40dGKS3Y0VlVyTEE2vKmynYxqgb17orCRJr3FsnY+J9m
	+7XHPPpdmyydDaxlMKWgErlOgLIW6aZUOPubXpd0DBuM6J1ZqS1abyfakgeVgmMO5fZe
	Vk+TR5ylwmHO6B9JbaApDjedi1g9RSuIgIwMU8cSxp1Iwn7U0iPEHSbYwainmL/VbSK0
	UtFjWWIMAcgk7HX7HG2pKg/NCnLiiazpCsfr7jDwAqRP2OC4tv/hnIq7iJM14LDGEZET
	lsEA==
Received: by 10.49.48.43 with SMTP id i11mr28123441qen.10.1349700065876;
	Mon, 08 Oct 2012 05:41:05 -0700 (PDT)
Received: from localhost.localdomain
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id em3sm17980161qab.5.2012.10.08.05.41.04
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 08 Oct 2012 05:41:05 -0700 (PDT)
Date: Mon, 8 Oct 2012 08:41:02 -0400
From: Konrad Rzeszutek Wilk 
To: Ian Campbell 
Message-ID: <20121008124101.GB29650@localhost.localdomain>
References: <20120924154335.097d3fb9@mantra.us.oracle.com>
	
	<20120925180416.0137d61a@mantra.us.oracle.com>
	
	<20121002183619.70734b7a@mantra.us.oracle.com>
	<20121002190323.2e16f6ff@mantra.us.oracle.com>
	
	<1349265914.650.136.camel@zakaz.uk.xensource.com>
	<20121004183528.060416a0@mantra.us.oracle.com>
	<1349429005.20946.20.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1349429005.20946.20.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "Xen-devel@lists.xensource.com" ,
	Stefano Stabellini ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH v1 3/8]: PVH startup changes (enlighten.c)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 05, 2012 at 10:23:25AM +0100, Ian Campbell wrote:
> On Fri, 2012-10-05 at 02:35 +0100, Mukesh Rathor wrote:
> > On Wed, 3 Oct 2012 13:05:14 +0100
> > Ian Campbell  wrote:
> > 
> > > On Wed, 2012-10-03 at 12:58 +0100, Stefano Stabellini wrote:
> > > > > So for now, how about, lets go
> > > > > with what I've got. I'll make a note, and when I do xen patch,
> > > > > I'll figure it out, and would be a very small linux patch. I want
> > > > > to get linux patch in soon before the window closes.
> > > > 
> > > > We can leave page special as it is for now with very little
> > > > consequences, because it is not part of the interface with Xen.
> > > > However this is part of the interface, so whatever we choose here
> > > > is going to be hard to change later on.
> > > 
> > > I suggested that until we have seen and reviewed the hypervisor side
> > > patches this guest side functionality all needs to be under an option
> > > which has CONFIG_EXPERIMENTAL as a dependency and a comment explaining
> > > that the ABI is not fixed yet, similar to what we did for the ARM
> > > port.
> > 
> > Konrad is going to keep the changes in his tree and not upstream for
> > couple months while we go thru the xen patches. This would be a big
> > help for me as I won't have to constantly refresh linux tree.
> 
> Ah, ok, that sounds like a good plan.
> 
> In the case where the ARM stuff I have built on this becomes ripe first
> would it be OK with you guys if I were to cherry pick the relevant bits
> of the PVH stuff into a series to go in sooner?

My plan right now was to wait for Mukesh to repost his series (which
I hope will address all our review comments) and then I can shovel
any other patches on top of that.

But if it makes sense to intermix Mukeshes's patchs, and yours.
(or squash some together) I can do that too.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 12:41:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 12:41:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLCdy-00034P-Fg; Mon, 08 Oct 2012 12:41:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLCdw-00034H-OU
	for Xen-devel@lists.xensource.com; Mon, 08 Oct 2012 12:41:08 +0000
Received: from [85.158.137.99:13992] by server-7.bemta-3.messagelabs.com id
	54/1F-15765-3E9C2705; Mon, 08 Oct 2012 12:41:07 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1349700066!15572511!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32301 invoked from network); 8 Oct 2012 12:41:07 -0000
Received: from mail-qc0-f171.google.com (HELO mail-qc0-f171.google.com)
	(209.85.216.171)
	by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 12:41:07 -0000
Received: by mail-qc0-f171.google.com with SMTP id d1so177476qca.30
	for ;
	Mon, 08 Oct 2012 05:41:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=OrrcgjUTLSPmi1ocKCS54pDd1642oPVRo4CciDvUgSg=;
	b=oNur6VhE8m+CzaY1XOX6ixHykD8+9wonpZo0+MhZqawIwgvt3MZoQfKyDaOx6JVKfL
	/0hsNNa///nPwLJ1NkQ9xU7Y40dGKS3Y0VlVyTEE2vKmynYxqgb17orCRJr3FsnY+J9m
	+7XHPPpdmyydDaxlMKWgErlOgLIW6aZUOPubXpd0DBuM6J1ZqS1abyfakgeVgmMO5fZe
	Vk+TR5ylwmHO6B9JbaApDjedi1g9RSuIgIwMU8cSxp1Iwn7U0iPEHSbYwainmL/VbSK0
	UtFjWWIMAcgk7HX7HG2pKg/NCnLiiazpCsfr7jDwAqRP2OC4tv/hnIq7iJM14LDGEZET
	lsEA==
Received: by 10.49.48.43 with SMTP id i11mr28123441qen.10.1349700065876;
	Mon, 08 Oct 2012 05:41:05 -0700 (PDT)
Received: from localhost.localdomain
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id em3sm17980161qab.5.2012.10.08.05.41.04
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 08 Oct 2012 05:41:05 -0700 (PDT)
Date: Mon, 8 Oct 2012 08:41:02 -0400
From: Konrad Rzeszutek Wilk 
To: Ian Campbell 
Message-ID: <20121008124101.GB29650@localhost.localdomain>
References: <20120924154335.097d3fb9@mantra.us.oracle.com>
	
	<20120925180416.0137d61a@mantra.us.oracle.com>
	
	<20121002183619.70734b7a@mantra.us.oracle.com>
	<20121002190323.2e16f6ff@mantra.us.oracle.com>
	
	<1349265914.650.136.camel@zakaz.uk.xensource.com>
	<20121004183528.060416a0@mantra.us.oracle.com>
	<1349429005.20946.20.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1349429005.20946.20.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "Xen-devel@lists.xensource.com" ,
	Stefano Stabellini ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH v1 3/8]: PVH startup changes (enlighten.c)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 05, 2012 at 10:23:25AM +0100, Ian Campbell wrote:
> On Fri, 2012-10-05 at 02:35 +0100, Mukesh Rathor wrote:
> > On Wed, 3 Oct 2012 13:05:14 +0100
> > Ian Campbell  wrote:
> > 
> > > On Wed, 2012-10-03 at 12:58 +0100, Stefano Stabellini wrote:
> > > > > So for now, how about, lets go
> > > > > with what I've got. I'll make a note, and when I do xen patch,
> > > > > I'll figure it out, and would be a very small linux patch. I want
> > > > > to get linux patch in soon before the window closes.
> > > > 
> > > > We can leave page special as it is for now with very little
> > > > consequences, because it is not part of the interface with Xen.
> > > > However this is part of the interface, so whatever we choose here
> > > > is going to be hard to change later on.
> > > 
> > > I suggested that until we have seen and reviewed the hypervisor side
> > > patches this guest side functionality all needs to be under an option
> > > which has CONFIG_EXPERIMENTAL as a dependency and a comment explaining
> > > that the ABI is not fixed yet, similar to what we did for the ARM
> > > port.
> > 
> > Konrad is going to keep the changes in his tree and not upstream for
> > couple months while we go thru the xen patches. This would be a big
> > help for me as I won't have to constantly refresh linux tree.
> 
> Ah, ok, that sounds like a good plan.
> 
> In the case where the ARM stuff I have built on this becomes ripe first
> would it be OK with you guys if I were to cherry pick the relevant bits
> of the PVH stuff into a series to go in sooner?

My plan right now was to wait for Mukesh to repost his series (which
I hope will address all our review comments) and then I can shovel
any other patches on top of that.

But if it makes sense to intermix Mukeshes's patchs, and yours.
(or squash some together) I can do that too.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 12:44:21 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 12:44:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLCgs-0003Bw-2n; Mon, 08 Oct 2012 12:44:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLCgq-0003Bn-Gc
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 12:44:08 +0000
Received: from [85.158.139.211:43129] by server-7.bemta-5.messagelabs.com id
	39/2D-00431-79AC2705; Mon, 08 Oct 2012 12:44:07 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-7.tower-206.messagelabs.com!1349700246!21035525!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22769 invoked from network); 8 Oct 2012 12:44:07 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-7.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	8 Oct 2012 12:44:07 -0000
Received: from 100-66-ftth.onsneteindhoven.nl ([88.159.66.100]:56535
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TLCi0-00033c-DZ; Mon, 08 Oct 2012 14:45:20 +0200
Date: Mon, 8 Oct 2012 14:43:58 +0200
From: Sander Eikelenboom 
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1408711673.20121008144358@eikelenboom.it>
To: Ian Campbell 
In-Reply-To: <1349686461.18008.18.camel@zakaz.uk.xensource.com>
References: 
	<729626082.20121006002054@eikelenboom.it>
	<20121007233444.GA26929@localhost.localdomain>
	<1349686461.18008.18.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk ,
	"xen-devel@lists.xensource.com" ,
	konrad 
Subject: Re: [Xen-devel] Kernel 3.7.0-pre-rc1 kernel BUG at
	drivers/net/xen-netback/netback.c:405 RIP:
	e030:[] []
	netbk_gop_frag_copy+0x379/0x380
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Monday, October 8, 2012, 10:54:21 AM, you wrote:

> On Mon, 2012-10-08 at 00:34 +0100, Konrad Rzeszutek Wilk wrote:
>> On Sat, Oct 06, 2012 at 12:20:54AM +0200, Sander Eikelenboom wrote:
>> > 
>> > Friday, October 5, 2012, 9:26:31 PM, you wrote:
>> > 
>> > > Sorry for top posting - on mobile.
>> > 
>> > > I saw it too yesterday but only on a specific hardware - AMD FX8. What type of CPU do you have?  Does xsave=off on Xen line help?
>> > 
>> > Nope the xsave=off doesn't help
>> > 
>> > > Sander Eikelenboom  wrote:
>> > 
>> > >>Hi Konrad,
>> > >>
>> > >>Just tested kernel 3.7.0-pre-rc1 but ran into a oops in netback on boot after starting some guests:
>> > >>
>> > >>[  402.723915] ------------[ cut here ]------------
>> > >>[  402.734629] kernel BUG at drivers/net/xen-netback/netback.c:405!
>> 
>> Looking at the code, this is what we get:
>> 
>>         /* Data must not cross a page boundary. */
>>         BUG_ON(size + offset > PAGE_SIZE);
>> 
>> Looking at the commits, the one recently added was:
>> commit c571898ffc24a1768e1b2dabeac0fc7dd4c14601
>> Author: Andres Lagar-Cavilla 
>> Date:   Fri Sep 14 14:26:59 2012 +0000
>> 
>>     xen/gndev: Xen backend support for paged out grant targets V4.
>>     
>> 
>> But after reverting it and trying the kernel I still got the crash.
>> 
>> So .. the weirdness is that this seems to be only happening on
>> certain AMD machines - for example on my AMD A8 box I did not see this.

> I took a look at this last week and can't repro.

> The code which calls this function is supposed to ensure that the buffer
> doesn't cross a page boundary.

> There are two places which call it, one is looping over the skb's frags,
> which just can't cross page boundaries and if they did it would be
> breaking left and right for everyone AFAICT (although I'm very behind on
> my LKML and netdev reading, so maybe it is ;-)).

> The other case is processing the SKB's linear data area, which can cross
> a page boundary but the code loops over it and processes it in chunks
> which fit in single pages. I was suspicious of this code so I pulled it
> out into a little userspace test harness and fed it some corner cases
> but it looked like it was doing the right thing.

> I speculated that this might be NIC rather than processor related
> (perhaps there's some weak correlation between certain NICs and certain
> processor manufacturers).

> Konrad seems to have an r8169 but the module list wasn't in Sander's
> output -- do you know what you have?

>> I fear that the next step is to do a bit off git bisection to
>> get an idea of which merge it might be. I am going to be AFK
>> on Monday so I won't get to this until Tuesday/Wednesay :-(
>> 
>> .. Thought to help speed this process, this looks like a
>> candidate:
>>

It doesn't seem to be this commit, tested before and after, both seem to work.
I don't see a r8169 related commit to test, will see for a net related one.

--
Sander

>> commit 229993001282e128a49a59ec43d255614775703a
>> Merge: 7687b80 fd0f586
>> Author: Linus Torvalds 
>> Date:   Mon Oct 1 11:13:33 2012 -0700
>> 
>>     Merge branch 'x86-mm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
>>     
>>     Pull x86/mm changes from Ingo Molnar:
>>      "The biggest change is new TLB partial flushing code for AMD CPUs.
>>       (The v3.6 kernel had the Intel CPU side code, see commits
>>       e0ba94f14f74..effee4b9b3b.)

> Would be interesting to try although I don't think anything in this area
> is actively messing with page table mappings (that happens later, and
> doesn't effect the non-data bits of the skb like the sizes and offsets).

> Perhaps this debug patch might shed some light? PG_compound or THP might
> be an interesting case?

> Ian.

> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index 05593d8..ca4c47d 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -386,7 +386,7 @@ static struct netbk_rx_meta *get_next_rx_buffer(struct xenvif *vif,
>   * Set up the grant operations for this fragment. If it's a flipping
>   * interface, we also set up the unmap request from here.
>   */
> -static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
> +static int netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
>                                 struct netrx_pending_operations *npo,
>                                 struct page *page, unsigned long size,
>                                 unsigned long offset, int *head)
> @@ -402,7 +402,8 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
>         unsigned long bytes;
>  
>         /* Data must not cross a page boundary. */
> -       BUG_ON(size + offset > PAGE_SIZE);
> +       if (size + offset > PAGE_SIZE)
> +               return -1;
>  
>         meta = npo->meta + npo->meta_prod - 1;
>  
> @@ -459,6 +460,7 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
>                 *head = 0; /* There must be something in this buffer now. */
>  
>         }
> +       return 0;
>  }
>  
>  /*
> @@ -517,17 +519,31 @@ static int netbk_gop_skb(struct sk_buff *skb,
>                 if (data + len > skb_tail_pointer(skb))
>                         len = skb_tail_pointer(skb) - data;
>  
> -               netbk_gop_frag_copy(vif, skb, npo,
> -                                   virt_to_page(data), len, offset, &head);
> +               if (netbk_gop_frag_copy(vif, skb, npo,
> +                               virt_to_page(data), len, offset, &head) < 0) {
> +printk(KERN_CRIT "netbk_gop_frag_copy failed: skb head %p-%p\n",
+       skb->>data, skb_tail_pointer);
> +printk(KERN_CRIT "copying from %p-%p, offset %x, len %x\n",
> +       data, data+len, offset, len);
> +dump_page(virt_to_page(data));
> +BUG();
> +               }
>                 data += len;
>         }
>  
>         for (i = 0; i < nr_frags; i++) {
> -               netbk_gop_frag_copy(vif, skb, npo,
> +               if (netbk_gop_frag_copy(vif, skb, npo,
>                                     skb_frag_page(&skb_shinfo(skb)->frags[i]),
>                                     skb_frag_size(&skb_shinfo(skb)->frags[i]),
>                                     skb_shinfo(skb)->frags[i].page_offset,
> -                                   &head);
> +                                   &head) < 0) {
> +printk(KERN_CRIT "netbk_gop_frag_copy failed: skb frag %d page\n", i);
> +printk(KERN_CRIT "copying from offset %x, len %x\n",
> +       skb_shinfo(skb)->frags[i].page_offset,
> +       skb_frag_size(&skb_shinfo(skb)->frags[i]));
> +dump_page(skb_frag_page(&skb_shinfo(skb)->frags[i]));
> +BUG();
> +               }
>         }
>  
>         return npo->meta_prod - old_meta_prod;





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 12:44:21 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 12:44:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLCgs-0003Bw-2n; Mon, 08 Oct 2012 12:44:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLCgq-0003Bn-Gc
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 12:44:08 +0000
Received: from [85.158.139.211:43129] by server-7.bemta-5.messagelabs.com id
	39/2D-00431-79AC2705; Mon, 08 Oct 2012 12:44:07 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-7.tower-206.messagelabs.com!1349700246!21035525!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22769 invoked from network); 8 Oct 2012 12:44:07 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-7.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	8 Oct 2012 12:44:07 -0000
Received: from 100-66-ftth.onsneteindhoven.nl ([88.159.66.100]:56535
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TLCi0-00033c-DZ; Mon, 08 Oct 2012 14:45:20 +0200
Date: Mon, 8 Oct 2012 14:43:58 +0200
From: Sander Eikelenboom 
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1408711673.20121008144358@eikelenboom.it>
To: Ian Campbell 
In-Reply-To: <1349686461.18008.18.camel@zakaz.uk.xensource.com>
References: 
	<729626082.20121006002054@eikelenboom.it>
	<20121007233444.GA26929@localhost.localdomain>
	<1349686461.18008.18.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk ,
	"xen-devel@lists.xensource.com" ,
	konrad 
Subject: Re: [Xen-devel] Kernel 3.7.0-pre-rc1 kernel BUG at
	drivers/net/xen-netback/netback.c:405 RIP:
	e030:[] []
	netbk_gop_frag_copy+0x379/0x380
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Monday, October 8, 2012, 10:54:21 AM, you wrote:

> On Mon, 2012-10-08 at 00:34 +0100, Konrad Rzeszutek Wilk wrote:
>> On Sat, Oct 06, 2012 at 12:20:54AM +0200, Sander Eikelenboom wrote:
>> > 
>> > Friday, October 5, 2012, 9:26:31 PM, you wrote:
>> > 
>> > > Sorry for top posting - on mobile.
>> > 
>> > > I saw it too yesterday but only on a specific hardware - AMD FX8. What type of CPU do you have?  Does xsave=off on Xen line help?
>> > 
>> > Nope the xsave=off doesn't help
>> > 
>> > > Sander Eikelenboom  wrote:
>> > 
>> > >>Hi Konrad,
>> > >>
>> > >>Just tested kernel 3.7.0-pre-rc1 but ran into a oops in netback on boot after starting some guests:
>> > >>
>> > >>[  402.723915] ------------[ cut here ]------------
>> > >>[  402.734629] kernel BUG at drivers/net/xen-netback/netback.c:405!
>> 
>> Looking at the code, this is what we get:
>> 
>>         /* Data must not cross a page boundary. */
>>         BUG_ON(size + offset > PAGE_SIZE);
>> 
>> Looking at the commits, the one recently added was:
>> commit c571898ffc24a1768e1b2dabeac0fc7dd4c14601
>> Author: Andres Lagar-Cavilla 
>> Date:   Fri Sep 14 14:26:59 2012 +0000
>> 
>>     xen/gndev: Xen backend support for paged out grant targets V4.
>>     
>> 
>> But after reverting it and trying the kernel I still got the crash.
>> 
>> So .. the weirdness is that this seems to be only happening on
>> certain AMD machines - for example on my AMD A8 box I did not see this.

> I took a look at this last week and can't repro.

> The code which calls this function is supposed to ensure that the buffer
> doesn't cross a page boundary.

> There are two places which call it, one is looping over the skb's frags,
> which just can't cross page boundaries and if they did it would be
> breaking left and right for everyone AFAICT (although I'm very behind on
> my LKML and netdev reading, so maybe it is ;-)).

> The other case is processing the SKB's linear data area, which can cross
> a page boundary but the code loops over it and processes it in chunks
> which fit in single pages. I was suspicious of this code so I pulled it
> out into a little userspace test harness and fed it some corner cases
> but it looked like it was doing the right thing.

> I speculated that this might be NIC rather than processor related
> (perhaps there's some weak correlation between certain NICs and certain
> processor manufacturers).

> Konrad seems to have an r8169 but the module list wasn't in Sander's
> output -- do you know what you have?

>> I fear that the next step is to do a bit off git bisection to
>> get an idea of which merge it might be. I am going to be AFK
>> on Monday so I won't get to this until Tuesday/Wednesay :-(
>> 
>> .. Thought to help speed this process, this looks like a
>> candidate:
>>

It doesn't seem to be this commit, tested before and after, both seem to work.
I don't see a r8169 related commit to test, will see for a net related one.

--
Sander

>> commit 229993001282e128a49a59ec43d255614775703a
>> Merge: 7687b80 fd0f586
>> Author: Linus Torvalds 
>> Date:   Mon Oct 1 11:13:33 2012 -0700
>> 
>>     Merge branch 'x86-mm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
>>     
>>     Pull x86/mm changes from Ingo Molnar:
>>      "The biggest change is new TLB partial flushing code for AMD CPUs.
>>       (The v3.6 kernel had the Intel CPU side code, see commits
>>       e0ba94f14f74..effee4b9b3b.)

> Would be interesting to try although I don't think anything in this area
> is actively messing with page table mappings (that happens later, and
> doesn't effect the non-data bits of the skb like the sizes and offsets).

> Perhaps this debug patch might shed some light? PG_compound or THP might
> be an interesting case?

> Ian.

> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index 05593d8..ca4c47d 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -386,7 +386,7 @@ static struct netbk_rx_meta *get_next_rx_buffer(struct xenvif *vif,
>   * Set up the grant operations for this fragment. If it's a flipping
>   * interface, we also set up the unmap request from here.
>   */
> -static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
> +static int netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
>                                 struct netrx_pending_operations *npo,
>                                 struct page *page, unsigned long size,
>                                 unsigned long offset, int *head)
> @@ -402,7 +402,8 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
>         unsigned long bytes;
>  
>         /* Data must not cross a page boundary. */
> -       BUG_ON(size + offset > PAGE_SIZE);
> +       if (size + offset > PAGE_SIZE)
> +               return -1;
>  
>         meta = npo->meta + npo->meta_prod - 1;
>  
> @@ -459,6 +460,7 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
>                 *head = 0; /* There must be something in this buffer now. */
>  
>         }
> +       return 0;
>  }
>  
>  /*
> @@ -517,17 +519,31 @@ static int netbk_gop_skb(struct sk_buff *skb,
>                 if (data + len > skb_tail_pointer(skb))
>                         len = skb_tail_pointer(skb) - data;
>  
> -               netbk_gop_frag_copy(vif, skb, npo,
> -                                   virt_to_page(data), len, offset, &head);
> +               if (netbk_gop_frag_copy(vif, skb, npo,
> +                               virt_to_page(data), len, offset, &head) < 0) {
> +printk(KERN_CRIT "netbk_gop_frag_copy failed: skb head %p-%p\n",
+       skb->>data, skb_tail_pointer);
> +printk(KERN_CRIT "copying from %p-%p, offset %x, len %x\n",
> +       data, data+len, offset, len);
> +dump_page(virt_to_page(data));
> +BUG();
> +               }
>                 data += len;
>         }
>  
>         for (i = 0; i < nr_frags; i++) {
> -               netbk_gop_frag_copy(vif, skb, npo,
> +               if (netbk_gop_frag_copy(vif, skb, npo,
>                                     skb_frag_page(&skb_shinfo(skb)->frags[i]),
>                                     skb_frag_size(&skb_shinfo(skb)->frags[i]),
>                                     skb_shinfo(skb)->frags[i].page_offset,
> -                                   &head);
> +                                   &head) < 0) {
> +printk(KERN_CRIT "netbk_gop_frag_copy failed: skb frag %d page\n", i);
> +printk(KERN_CRIT "copying from offset %x, len %x\n",
> +       skb_shinfo(skb)->frags[i].page_offset,
> +       skb_frag_size(&skb_shinfo(skb)->frags[i]));
> +dump_page(skb_frag_page(&skb_shinfo(skb)->frags[i]));
> +BUG();
> +               }
>         }
>  
>         return npo->meta_prod - old_meta_prod;





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 12:50:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 12:50:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLCmk-0003OM-Sz; Mon, 08 Oct 2012 12:50:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from ) id 1TLCmj-0003OE-QW
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 12:50:14 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1349700605!13830534!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzUyNzc3\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2056 invoked from network); 8 Oct 2012 12:50:06 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-2.tower-27.messagelabs.com with SMTP;
	8 Oct 2012 12:50:06 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 08 Oct 2012 05:49:45 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,554,1344236400"; d="scan'208";a="202928131"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by orsmga001.jf.intel.com with ESMTP; 08 Oct 2012 05:50:04 -0700
Received: from fmsmsx101.amr.corp.intel.com (10.19.9.52) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 8 Oct 2012 05:50:04 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX101.amr.corp.intel.com (10.19.9.52) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 8 Oct 2012 05:50:03 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.92]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.162]) with mapi id
	14.01.0355.002; Mon, 8 Oct 2012 20:50:02 +0800
From: "Hao, Xudong" 
To: Ian Campbell 
Thread-Topic: [PATCH v3] xen/tools: Add 64 bits big bar support
Thread-Index: AQHNm8GbNOE8aT1fVEaIth3aKGlXepevaYGA//97ewCAAIoZIA==
Date: Mon, 8 Oct 2012 12:50:01 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FECC581@SHSMSX102.ccr.corp.intel.com>
References: <1348648582-11461-1-git-send-email-xudong.hao@intel.com>
	<403610A45A2B5242BD291EDAE8B37D300FECC549@SHSMSX102.ccr.corp.intel.com>
	<1349699688.21847.5.camel@zakaz.uk.xensource.com>
In-Reply-To: <1349699688.21847.5.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	"Keir \(Xen.org\)" , "Zhang,
	Xiantao" ,
	"jbeulich@suse.com" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH v3] xen/tools: Add 64 bits big bar support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Oh, I got it, I miss a latest update. Thanks!

Thanks,
-Xudong


> -----Original Message-----
> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> Sent: Monday, October 08, 2012 8:35 PM
> To: Hao, Xudong
> Cc: Keir (Xen.org); xen-devel@lists.xen.org; Stefano Stabellini;
> jbeulich@suse.com; Zhang, Xiantao
> Subject: Re: [PATCH v3] xen/tools: Add 64 bits big bar support
> 
> Didn't Keir already check this in last week?
> 
> On Mon, 2012-10-08 at 13:31 +0100, Hao, Xudong wrote:
> > Hi, Ian and Keir
> >
> > Do you have other comments for this patch?
> >
> > Thanks,
> > -Xudong
> >
> > > -----Original Message-----
> > > From: Hao, Xudong
> > > Sent: Wednesday, September 26, 2012 4:36 PM
> > > To: ian.campbell@citrix.com; keir@xen.org
> > > Cc: xen-devel@lists.xen.org; Stefano.Stabellini@eu.citrix.com;
> > > jbeulich@suse.com; Zhang, Xiantao; Hao, Xudong
> > > Subject: [PATCH v3] xen/tools: Add 64 bits big bar support
> > >
> > > Currently it is assumed PCI device BAR access < 4G memory. If there is such
> a
> > > device whose BAR size is larger than 4G, it must access > 4G memory
> address.
> > > This patch enable the 64bits big BAR support on hvmloader.
> > >
> > > v3 changes from v2:
> > > - Remain original print information
> > >
> > > v2 changes from v1 as comments by Jan.
> > > 1) Set Dynamic MMIO high memory address instead of a fixed number 640G
> > > 2) Mask bar_sz earlier to avoid older code changes
> > > 3) Add bar size barrier to judge high memory resource
> > > 4) Clean up bar64_relocate code
> > >
> > > Signed-off-by: Xiantao Zhang 
> > > Signed-off-by: Xudong Hao 
> > > ---
> > >  tools/firmware/hvmloader/cacheattr.c |   25 +++++++----
> > >  tools/firmware/hvmloader/config.h    |    2 +
> > >  tools/firmware/hvmloader/pci.c       |   77
> > > ++++++++++++++++++++++++++-------
> > >  tools/firmware/hvmloader/util.h      |    1 +
> > >  4 files changed, 80 insertions(+), 25 deletions(-)
> > >
> > > diff --git a/tools/firmware/hvmloader/cacheattr.c
> > > b/tools/firmware/hvmloader/cacheattr.c
> > > index 646f07f..592b455 100644
> > > --- a/tools/firmware/hvmloader/cacheattr.c
> > > +++ b/tools/firmware/hvmloader/cacheattr.c
> > > @@ -40,24 +40,33 @@
> > >  #define MSR_PAT              0x0277
> > >  #define MSR_MTRRdefType      0x02ff
> > >
> > > +unsigned int cpu_phys_addr(void)
> > > +{
> > > +    uint32_t eax, ebx, ecx, edx;
> > > +    unsigned int phys_bits = 36;
> > > +    /* Find the physical address size for this CPU. */
> > > +    cpuid(0x80000000, &eax, &ebx, &ecx, &edx);
> > > +    if ( eax >= 0x80000008 )
> > > +    {
> > > +        cpuid(0x80000008, &eax, &ebx, &ecx, &edx);
> > > +        phys_bits = (uint8_t)eax;
> > > +    }
> > > +
> > > +    return phys_bits;
> > > +}
> > > +
> > >  void cacheattr_init(void)
> > >  {
> > >      uint32_t eax, ebx, ecx, edx;
> > >      uint64_t mtrr_cap, mtrr_def, content, addr_mask;
> > > -    unsigned int i, nr_var_ranges, phys_bits = 36;
> > > +    unsigned int i, nr_var_ranges, phys_bits;
> > >
> > >      /* Does the CPU support architectural MTRRs? */
> > >      cpuid(0x00000001, &eax, &ebx, &ecx, &edx);
> > >      if ( !(edx & (1u << 12)) )
> > >           return;
> > >
> > > -    /* Find the physical address size for this CPU. */
> > > -    cpuid(0x80000000, &eax, &ebx, &ecx, &edx);
> > > -    if ( eax >= 0x80000008 )
> > > -    {
> > > -        cpuid(0x80000008, &eax, &ebx, &ecx, &edx);
> > > -        phys_bits = (uint8_t)eax;
> > > -    }
> > > +    phys_bits = cpu_phys_addr();
> > >
> > >      printf("%u-bit phys ... ", phys_bits);
> > >
> > > diff --git a/tools/firmware/hvmloader/config.h
> > > b/tools/firmware/hvmloader/config.h
> > > index 7c0180d..bbf2993 100644
> > > --- a/tools/firmware/hvmloader/config.h
> > > +++ b/tools/firmware/hvmloader/config.h
> > > @@ -53,6 +53,8 @@ extern struct bios_config ovmf_config;
> > >  /* MMIO hole: Hardcoded defaults, which can be dynamically expanded.
> */
> > >  #define PCI_MEM_START       0xf0000000
> > >  #define PCI_MEM_END         0xfc000000
> > > +#define PCI_MIN_BIG_BAR_SIZE          0x20000000
> > > +
> > >  extern unsigned long pci_mem_start, pci_mem_end;
> > >
> > >
> > > diff --git a/tools/firmware/hvmloader/pci.c
> b/tools/firmware/hvmloader/pci.c
> > > index fd56e50..0500db5 100644
> > > --- a/tools/firmware/hvmloader/pci.c
> > > +++ b/tools/firmware/hvmloader/pci.c
> > > @@ -36,19 +36,25 @@ unsigned long igd_opregion_pgbase = 0;
> > >
> > >  void pci_setup(void)
> > >  {
> > > -    uint32_t base, devfn, bar_reg, bar_data, bar_sz, cmd, mmio_total =
> 0;
> > > +    uint8_t is_64bar, using_64bar, bar64_relocate = 0;
> > > +    uint32_t devfn, bar_reg, cmd, bar_data, bar_data_upper;
> > > +    uint64_t base, bar_sz, bar_sz_upper, mmio_total = 0;
> > >      uint32_t vga_devfn = 256;
> > >      uint16_t class, vendor_id, device_id;
> > >      unsigned int bar, pin, link, isa_irq;
> > > +    int64_t mmio_left;
> > >
> > >      /* Resources assignable to PCI devices via BARs. */
> > >      struct resource {
> > > -        uint32_t base, max;
> > > -    } *resource, mem_resource, io_resource;
> > > +        uint64_t base, max;
> > > +    } *resource, mem_resource, high_mem_resource, io_resource;
> > >
> > >      /* Create a list of device BARs in descending order of size. */
> > >      struct bars {
> > > -        uint32_t devfn, bar_reg, bar_sz;
> > > +        uint32_t is_64bar;
> > > +        uint32_t devfn;
> > > +        uint32_t bar_reg;
> > > +        uint64_t bar_sz;
> > >      } *bars = (struct bars *)scratch_start;
> > >      unsigned int i, nr_bars = 0;
> > >
> > > @@ -133,22 +139,34 @@ void pci_setup(void)
> > >          /* Map the I/O memory and port resources. */
> > >          for ( bar = 0; bar < 7; bar++ )
> > >          {
> > > +            bar_sz_upper = 0;
> > >              bar_reg = PCI_BASE_ADDRESS_0 + 4*bar;
> > >              if ( bar == 6 )
> > >                  bar_reg = PCI_ROM_ADDRESS;
> > >
> > >              bar_data = pci_readl(devfn, bar_reg);
> > > +            is_64bar = !!((bar_data & (PCI_BASE_ADDRESS_SPACE |
> > > +                         PCI_BASE_ADDRESS_MEM_TYPE_MASK))
> ==
> > > +                         (PCI_BASE_ADDRESS_SPACE_MEMORY |
> > > +                         PCI_BASE_ADDRESS_MEM_TYPE_64));
> > >              pci_writel(devfn, bar_reg, ~0);
> > >              bar_sz = pci_readl(devfn, bar_reg);
> > >              pci_writel(devfn, bar_reg, bar_data);
> > > -            if ( bar_sz == 0 )
> > > -                continue;
> > >
> > >              bar_sz &= (((bar_data & PCI_BASE_ADDRESS_SPACE) ==
> > >                          PCI_BASE_ADDRESS_SPACE_MEMORY) ?
> > >                         PCI_BASE_ADDRESS_MEM_MASK :
> > >                         (PCI_BASE_ADDRESS_IO_MASK & 0xffff));
> > > +            if (is_64bar) {
> > > +                bar_data_upper = pci_readl(devfn, bar_reg + 4);
> > > +                pci_writel(devfn, bar_reg + 4, ~0);
> > > +                bar_sz_upper = pci_readl(devfn, bar_reg + 4);
> > > +                pci_writel(devfn, bar_reg + 4, bar_data_upper);
> > > +                bar_sz = (bar_sz_upper << 32) | bar_sz;
> > > +            }
> > >              bar_sz &= ~(bar_sz - 1);
> > > +            if ( bar_sz == 0 )
> > > +                continue;
> > >
> > >              for ( i = 0; i < nr_bars; i++ )
> > >                  if ( bars[i].bar_sz < bar_sz )
> > > @@ -157,6 +175,7 @@ void pci_setup(void)
> > >              if ( i != nr_bars )
> > >                  memmove(&bars[i+1], &bars[i], (nr_bars-i) *
> > > sizeof(*bars));
> > >
> > > +            bars[i].is_64bar = is_64bar;
> > >              bars[i].devfn   = devfn;
> > >              bars[i].bar_reg = bar_reg;
> > >              bars[i].bar_sz  = bar_sz;
> > > @@ -167,11 +186,8 @@ void pci_setup(void)
> > >
> > >              nr_bars++;
> > >
> > > -            /* Skip the upper-half of the address for a 64-bit BAR. */
> > > -            if ( (bar_data & (PCI_BASE_ADDRESS_SPACE |
> > > -
> PCI_BASE_ADDRESS_MEM_TYPE_MASK))
> > > ==
> > > -                 (PCI_BASE_ADDRESS_SPACE_MEMORY |
> > > -                  PCI_BASE_ADDRESS_MEM_TYPE_64) )
> > > +            /*The upper half is already calculated, skip it! */
> > > +            if (is_64bar)
> > >                  bar++;
> > >          }
> > >
> > > @@ -197,6 +213,9 @@ void pci_setup(void)
> > >              ((pci_mem_start << 1) != 0) )
> > >          pci_mem_start <<= 1;
> > >
> > > +    if ( (pci_mem_start << 1) != 0 )
> > > +        bar64_relocate = 1;
> > > +
> > >      /* Relocate RAM that overlaps PCI space (in 64k-page chunks). */
> > >      while ( (pci_mem_start >> PAGE_SHIFT) <
> hvm_info->low_mem_pgend )
> > >      {
> > > @@ -218,11 +237,15 @@ void pci_setup(void)
> > >          hvm_info->high_mem_pgend += nr_pages;
> > >      }
> > >
> > > +    high_mem_resource.base = ((uint64_t)hvm_info->high_mem_pgend)
> <<
> > > PAGE_SHIFT;
> > > +    high_mem_resource.max = 1ull << cpu_phys_addr();
> > >      mem_resource.base = pci_mem_start;
> > >      mem_resource.max = pci_mem_end;
> > >      io_resource.base = 0xc000;
> > >      io_resource.max = 0x10000;
> > >
> > > +    mmio_left = pci_mem_end - pci_mem_start;
> > > +
> > >      /* Assign iomem and ioport resources in descending order of size. */
> > >      for ( i = 0; i < nr_bars; i++ )
> > >      {
> > > @@ -230,13 +253,29 @@ void pci_setup(void)
> > >          bar_reg = bars[i].bar_reg;
> > >          bar_sz  = bars[i].bar_sz;
> > >
> > > +        using_64bar = bars[i].is_64bar && bar64_relocate &&
> (mmio_left <
> > > bar_sz);
> > >          bar_data = pci_readl(devfn, bar_reg);
> > >
> > >          if ( (bar_data & PCI_BASE_ADDRESS_SPACE) ==
> > >               PCI_BASE_ADDRESS_SPACE_MEMORY )
> > >          {
> > > -            resource = &mem_resource;
> > > -            bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
> > > +            /* Mapping high memory if PCI deivce is 64 bits bar and the
> bar
> > > size
> > > +               is larger than 512M */
> > > +            if (using_64bar && (bar_sz > PCI_MIN_BIG_BAR_SIZE)) {
> > > +                if ( high_mem_resource.base & (bar_sz - 1) )
> > > +                    high_mem_resource.base =
> > > high_mem_resource.base -
> > > +                        (high_mem_resource.base & (bar_sz - 1)) +
> > > bar_sz;
> > > +                else
> > > +                    high_mem_resource.base =
> > > high_mem_resource.base -
> > > +                        (high_mem_resource.base & (bar_sz - 1));
> > > +                resource = &high_mem_resource;
> > > +                bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
> > > +            }
> > > +            else {
> > > +                resource = &mem_resource;
> > > +                bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
> > > +            }
> > > +            mmio_left -= bar_sz;
> > >          }
> > >          else
> > >          {
> > > @@ -244,13 +283,14 @@ void pci_setup(void)
> > >              bar_data &= ~PCI_BASE_ADDRESS_IO_MASK;
> > >          }
> > >
> > > -        base = (resource->base + bar_sz - 1) & ~(bar_sz - 1);
> > > -        bar_data |= base;
> > > +        base = (resource->base  + bar_sz - 1) & ~(uint64_t)(bar_sz - 1);
> > > +        bar_data |= (uint32_t)base;
> > > +        bar_data_upper = (uint32_t)(base >> 32);
> > >          base += bar_sz;
> > >
> > >          if ( (base < resource->base) || (base > resource->max) )
> > >          {
> > > -            printf("pci dev %02x:%x bar %02x size %08x: no space for "
> > > +            printf("pci dev %02x:%x bar %02x size %llx: no space for "
> > >                     "resource!\n", devfn>>3, devfn&7, bar_reg,
> bar_sz);
> > >              continue;
> > >          }
> > > @@ -258,8 +298,11 @@ void pci_setup(void)
> > >          resource->base = base;
> > >
> > >          pci_writel(devfn, bar_reg, bar_data);
> > > -        printf("pci dev %02x:%x bar %02x size %08x: %08x\n",
> > > +        if (using_64bar)
> > > +            pci_writel(devfn, bar_reg + 4, bar_data_upper);
> > > +        printf("pci dev %02x:%x bar %02x size %llx: %08x\n",
> > >                 devfn>>3, devfn&7, bar_reg, bar_sz, bar_data);
> > > +
> > >
> > >          /* Now enable the memory or I/O mapping. */
> > >          cmd = pci_readw(devfn, PCI_COMMAND);
> > > diff --git a/tools/firmware/hvmloader/util.h
> b/tools/firmware/hvmloader/util.h
> > > index 07a9d42..ff06071 100644
> > > --- a/tools/firmware/hvmloader/util.h
> > > +++ b/tools/firmware/hvmloader/util.h
> > > @@ -215,6 +215,7 @@ void pci_setup(void);
> > >  uint32_t rombios_highbios_setup(void);
> > >
> > >  /* Miscellaneous. */
> > > +unsigned int cpu_phys_addr(void);
> > >  void cacheattr_init(void);
> > >  unsigned long create_mp_tables(void *table);
> > >  void hvm_write_smbios_tables(
> > > --
> > > 1.5.5
> >
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 12:50:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 12:50:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLCmk-0003OM-Sz; Mon, 08 Oct 2012 12:50:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from ) id 1TLCmj-0003OE-QW
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 12:50:14 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1349700605!13830534!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzUyNzc3\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2056 invoked from network); 8 Oct 2012 12:50:06 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-2.tower-27.messagelabs.com with SMTP;
	8 Oct 2012 12:50:06 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 08 Oct 2012 05:49:45 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,554,1344236400"; d="scan'208";a="202928131"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by orsmga001.jf.intel.com with ESMTP; 08 Oct 2012 05:50:04 -0700
Received: from fmsmsx101.amr.corp.intel.com (10.19.9.52) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 8 Oct 2012 05:50:04 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX101.amr.corp.intel.com (10.19.9.52) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 8 Oct 2012 05:50:03 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.92]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.162]) with mapi id
	14.01.0355.002; Mon, 8 Oct 2012 20:50:02 +0800
From: "Hao, Xudong" 
To: Ian Campbell 
Thread-Topic: [PATCH v3] xen/tools: Add 64 bits big bar support
Thread-Index: AQHNm8GbNOE8aT1fVEaIth3aKGlXepevaYGA//97ewCAAIoZIA==
Date: Mon, 8 Oct 2012 12:50:01 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FECC581@SHSMSX102.ccr.corp.intel.com>
References: <1348648582-11461-1-git-send-email-xudong.hao@intel.com>
	<403610A45A2B5242BD291EDAE8B37D300FECC549@SHSMSX102.ccr.corp.intel.com>
	<1349699688.21847.5.camel@zakaz.uk.xensource.com>
In-Reply-To: <1349699688.21847.5.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	"Keir \(Xen.org\)" , "Zhang,
	Xiantao" ,
	"jbeulich@suse.com" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH v3] xen/tools: Add 64 bits big bar support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Oh, I got it, I miss a latest update. Thanks!

Thanks,
-Xudong


> -----Original Message-----
> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> Sent: Monday, October 08, 2012 8:35 PM
> To: Hao, Xudong
> Cc: Keir (Xen.org); xen-devel@lists.xen.org; Stefano Stabellini;
> jbeulich@suse.com; Zhang, Xiantao
> Subject: Re: [PATCH v3] xen/tools: Add 64 bits big bar support
> 
> Didn't Keir already check this in last week?
> 
> On Mon, 2012-10-08 at 13:31 +0100, Hao, Xudong wrote:
> > Hi, Ian and Keir
> >
> > Do you have other comments for this patch?
> >
> > Thanks,
> > -Xudong
> >
> > > -----Original Message-----
> > > From: Hao, Xudong
> > > Sent: Wednesday, September 26, 2012 4:36 PM
> > > To: ian.campbell@citrix.com; keir@xen.org
> > > Cc: xen-devel@lists.xen.org; Stefano.Stabellini@eu.citrix.com;
> > > jbeulich@suse.com; Zhang, Xiantao; Hao, Xudong
> > > Subject: [PATCH v3] xen/tools: Add 64 bits big bar support
> > >
> > > Currently it is assumed PCI device BAR access < 4G memory. If there is such
> a
> > > device whose BAR size is larger than 4G, it must access > 4G memory
> address.
> > > This patch enable the 64bits big BAR support on hvmloader.
> > >
> > > v3 changes from v2:
> > > - Remain original print information
> > >
> > > v2 changes from v1 as comments by Jan.
> > > 1) Set Dynamic MMIO high memory address instead of a fixed number 640G
> > > 2) Mask bar_sz earlier to avoid older code changes
> > > 3) Add bar size barrier to judge high memory resource
> > > 4) Clean up bar64_relocate code
> > >
> > > Signed-off-by: Xiantao Zhang 
> > > Signed-off-by: Xudong Hao 
> > > ---
> > >  tools/firmware/hvmloader/cacheattr.c |   25 +++++++----
> > >  tools/firmware/hvmloader/config.h    |    2 +
> > >  tools/firmware/hvmloader/pci.c       |   77
> > > ++++++++++++++++++++++++++-------
> > >  tools/firmware/hvmloader/util.h      |    1 +
> > >  4 files changed, 80 insertions(+), 25 deletions(-)
> > >
> > > diff --git a/tools/firmware/hvmloader/cacheattr.c
> > > b/tools/firmware/hvmloader/cacheattr.c
> > > index 646f07f..592b455 100644
> > > --- a/tools/firmware/hvmloader/cacheattr.c
> > > +++ b/tools/firmware/hvmloader/cacheattr.c
> > > @@ -40,24 +40,33 @@
> > >  #define MSR_PAT              0x0277
> > >  #define MSR_MTRRdefType      0x02ff
> > >
> > > +unsigned int cpu_phys_addr(void)
> > > +{
> > > +    uint32_t eax, ebx, ecx, edx;
> > > +    unsigned int phys_bits = 36;
> > > +    /* Find the physical address size for this CPU. */
> > > +    cpuid(0x80000000, &eax, &ebx, &ecx, &edx);
> > > +    if ( eax >= 0x80000008 )
> > > +    {
> > > +        cpuid(0x80000008, &eax, &ebx, &ecx, &edx);
> > > +        phys_bits = (uint8_t)eax;
> > > +    }
> > > +
> > > +    return phys_bits;
> > > +}
> > > +
> > >  void cacheattr_init(void)
> > >  {
> > >      uint32_t eax, ebx, ecx, edx;
> > >      uint64_t mtrr_cap, mtrr_def, content, addr_mask;
> > > -    unsigned int i, nr_var_ranges, phys_bits = 36;
> > > +    unsigned int i, nr_var_ranges, phys_bits;
> > >
> > >      /* Does the CPU support architectural MTRRs? */
> > >      cpuid(0x00000001, &eax, &ebx, &ecx, &edx);
> > >      if ( !(edx & (1u << 12)) )
> > >           return;
> > >
> > > -    /* Find the physical address size for this CPU. */
> > > -    cpuid(0x80000000, &eax, &ebx, &ecx, &edx);
> > > -    if ( eax >= 0x80000008 )
> > > -    {
> > > -        cpuid(0x80000008, &eax, &ebx, &ecx, &edx);
> > > -        phys_bits = (uint8_t)eax;
> > > -    }
> > > +    phys_bits = cpu_phys_addr();
> > >
> > >      printf("%u-bit phys ... ", phys_bits);
> > >
> > > diff --git a/tools/firmware/hvmloader/config.h
> > > b/tools/firmware/hvmloader/config.h
> > > index 7c0180d..bbf2993 100644
> > > --- a/tools/firmware/hvmloader/config.h
> > > +++ b/tools/firmware/hvmloader/config.h
> > > @@ -53,6 +53,8 @@ extern struct bios_config ovmf_config;
> > >  /* MMIO hole: Hardcoded defaults, which can be dynamically expanded.
> */
> > >  #define PCI_MEM_START       0xf0000000
> > >  #define PCI_MEM_END         0xfc000000
> > > +#define PCI_MIN_BIG_BAR_SIZE          0x20000000
> > > +
> > >  extern unsigned long pci_mem_start, pci_mem_end;
> > >
> > >
> > > diff --git a/tools/firmware/hvmloader/pci.c
> b/tools/firmware/hvmloader/pci.c
> > > index fd56e50..0500db5 100644
> > > --- a/tools/firmware/hvmloader/pci.c
> > > +++ b/tools/firmware/hvmloader/pci.c
> > > @@ -36,19 +36,25 @@ unsigned long igd_opregion_pgbase = 0;
> > >
> > >  void pci_setup(void)
> > >  {
> > > -    uint32_t base, devfn, bar_reg, bar_data, bar_sz, cmd, mmio_total =
> 0;
> > > +    uint8_t is_64bar, using_64bar, bar64_relocate = 0;
> > > +    uint32_t devfn, bar_reg, cmd, bar_data, bar_data_upper;
> > > +    uint64_t base, bar_sz, bar_sz_upper, mmio_total = 0;
> > >      uint32_t vga_devfn = 256;
> > >      uint16_t class, vendor_id, device_id;
> > >      unsigned int bar, pin, link, isa_irq;
> > > +    int64_t mmio_left;
> > >
> > >      /* Resources assignable to PCI devices via BARs. */
> > >      struct resource {
> > > -        uint32_t base, max;
> > > -    } *resource, mem_resource, io_resource;
> > > +        uint64_t base, max;
> > > +    } *resource, mem_resource, high_mem_resource, io_resource;
> > >
> > >      /* Create a list of device BARs in descending order of size. */
> > >      struct bars {
> > > -        uint32_t devfn, bar_reg, bar_sz;
> > > +        uint32_t is_64bar;
> > > +        uint32_t devfn;
> > > +        uint32_t bar_reg;
> > > +        uint64_t bar_sz;
> > >      } *bars = (struct bars *)scratch_start;
> > >      unsigned int i, nr_bars = 0;
> > >
> > > @@ -133,22 +139,34 @@ void pci_setup(void)
> > >          /* Map the I/O memory and port resources. */
> > >          for ( bar = 0; bar < 7; bar++ )
> > >          {
> > > +            bar_sz_upper = 0;
> > >              bar_reg = PCI_BASE_ADDRESS_0 + 4*bar;
> > >              if ( bar == 6 )
> > >                  bar_reg = PCI_ROM_ADDRESS;
> > >
> > >              bar_data = pci_readl(devfn, bar_reg);
> > > +            is_64bar = !!((bar_data & (PCI_BASE_ADDRESS_SPACE |
> > > +                         PCI_BASE_ADDRESS_MEM_TYPE_MASK))
> ==
> > > +                         (PCI_BASE_ADDRESS_SPACE_MEMORY |
> > > +                         PCI_BASE_ADDRESS_MEM_TYPE_64));
> > >              pci_writel(devfn, bar_reg, ~0);
> > >              bar_sz = pci_readl(devfn, bar_reg);
> > >              pci_writel(devfn, bar_reg, bar_data);
> > > -            if ( bar_sz == 0 )
> > > -                continue;
> > >
> > >              bar_sz &= (((bar_data & PCI_BASE_ADDRESS_SPACE) ==
> > >                          PCI_BASE_ADDRESS_SPACE_MEMORY) ?
> > >                         PCI_BASE_ADDRESS_MEM_MASK :
> > >                         (PCI_BASE_ADDRESS_IO_MASK & 0xffff));
> > > +            if (is_64bar) {
> > > +                bar_data_upper = pci_readl(devfn, bar_reg + 4);
> > > +                pci_writel(devfn, bar_reg + 4, ~0);
> > > +                bar_sz_upper = pci_readl(devfn, bar_reg + 4);
> > > +                pci_writel(devfn, bar_reg + 4, bar_data_upper);
> > > +                bar_sz = (bar_sz_upper << 32) | bar_sz;
> > > +            }
> > >              bar_sz &= ~(bar_sz - 1);
> > > +            if ( bar_sz == 0 )
> > > +                continue;
> > >
> > >              for ( i = 0; i < nr_bars; i++ )
> > >                  if ( bars[i].bar_sz < bar_sz )
> > > @@ -157,6 +175,7 @@ void pci_setup(void)
> > >              if ( i != nr_bars )
> > >                  memmove(&bars[i+1], &bars[i], (nr_bars-i) *
> > > sizeof(*bars));
> > >
> > > +            bars[i].is_64bar = is_64bar;
> > >              bars[i].devfn   = devfn;
> > >              bars[i].bar_reg = bar_reg;
> > >              bars[i].bar_sz  = bar_sz;
> > > @@ -167,11 +186,8 @@ void pci_setup(void)
> > >
> > >              nr_bars++;
> > >
> > > -            /* Skip the upper-half of the address for a 64-bit BAR. */
> > > -            if ( (bar_data & (PCI_BASE_ADDRESS_SPACE |
> > > -
> PCI_BASE_ADDRESS_MEM_TYPE_MASK))
> > > ==
> > > -                 (PCI_BASE_ADDRESS_SPACE_MEMORY |
> > > -                  PCI_BASE_ADDRESS_MEM_TYPE_64) )
> > > +            /*The upper half is already calculated, skip it! */
> > > +            if (is_64bar)
> > >                  bar++;
> > >          }
> > >
> > > @@ -197,6 +213,9 @@ void pci_setup(void)
> > >              ((pci_mem_start << 1) != 0) )
> > >          pci_mem_start <<= 1;
> > >
> > > +    if ( (pci_mem_start << 1) != 0 )
> > > +        bar64_relocate = 1;
> > > +
> > >      /* Relocate RAM that overlaps PCI space (in 64k-page chunks). */
> > >      while ( (pci_mem_start >> PAGE_SHIFT) <
> hvm_info->low_mem_pgend )
> > >      {
> > > @@ -218,11 +237,15 @@ void pci_setup(void)
> > >          hvm_info->high_mem_pgend += nr_pages;
> > >      }
> > >
> > > +    high_mem_resource.base = ((uint64_t)hvm_info->high_mem_pgend)
> <<
> > > PAGE_SHIFT;
> > > +    high_mem_resource.max = 1ull << cpu_phys_addr();
> > >      mem_resource.base = pci_mem_start;
> > >      mem_resource.max = pci_mem_end;
> > >      io_resource.base = 0xc000;
> > >      io_resource.max = 0x10000;
> > >
> > > +    mmio_left = pci_mem_end - pci_mem_start;
> > > +
> > >      /* Assign iomem and ioport resources in descending order of size. */
> > >      for ( i = 0; i < nr_bars; i++ )
> > >      {
> > > @@ -230,13 +253,29 @@ void pci_setup(void)
> > >          bar_reg = bars[i].bar_reg;
> > >          bar_sz  = bars[i].bar_sz;
> > >
> > > +        using_64bar = bars[i].is_64bar && bar64_relocate &&
> (mmio_left <
> > > bar_sz);
> > >          bar_data = pci_readl(devfn, bar_reg);
> > >
> > >          if ( (bar_data & PCI_BASE_ADDRESS_SPACE) ==
> > >               PCI_BASE_ADDRESS_SPACE_MEMORY )
> > >          {
> > > -            resource = &mem_resource;
> > > -            bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
> > > +            /* Mapping high memory if PCI deivce is 64 bits bar and the
> bar
> > > size
> > > +               is larger than 512M */
> > > +            if (using_64bar && (bar_sz > PCI_MIN_BIG_BAR_SIZE)) {
> > > +                if ( high_mem_resource.base & (bar_sz - 1) )
> > > +                    high_mem_resource.base =
> > > high_mem_resource.base -
> > > +                        (high_mem_resource.base & (bar_sz - 1)) +
> > > bar_sz;
> > > +                else
> > > +                    high_mem_resource.base =
> > > high_mem_resource.base -
> > > +                        (high_mem_resource.base & (bar_sz - 1));
> > > +                resource = &high_mem_resource;
> > > +                bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
> > > +            }
> > > +            else {
> > > +                resource = &mem_resource;
> > > +                bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
> > > +            }
> > > +            mmio_left -= bar_sz;
> > >          }
> > >          else
> > >          {
> > > @@ -244,13 +283,14 @@ void pci_setup(void)
> > >              bar_data &= ~PCI_BASE_ADDRESS_IO_MASK;
> > >          }
> > >
> > > -        base = (resource->base + bar_sz - 1) & ~(bar_sz - 1);
> > > -        bar_data |= base;
> > > +        base = (resource->base  + bar_sz - 1) & ~(uint64_t)(bar_sz - 1);
> > > +        bar_data |= (uint32_t)base;
> > > +        bar_data_upper = (uint32_t)(base >> 32);
> > >          base += bar_sz;
> > >
> > >          if ( (base < resource->base) || (base > resource->max) )
> > >          {
> > > -            printf("pci dev %02x:%x bar %02x size %08x: no space for "
> > > +            printf("pci dev %02x:%x bar %02x size %llx: no space for "
> > >                     "resource!\n", devfn>>3, devfn&7, bar_reg,
> bar_sz);
> > >              continue;
> > >          }
> > > @@ -258,8 +298,11 @@ void pci_setup(void)
> > >          resource->base = base;
> > >
> > >          pci_writel(devfn, bar_reg, bar_data);
> > > -        printf("pci dev %02x:%x bar %02x size %08x: %08x\n",
> > > +        if (using_64bar)
> > > +            pci_writel(devfn, bar_reg + 4, bar_data_upper);
> > > +        printf("pci dev %02x:%x bar %02x size %llx: %08x\n",
> > >                 devfn>>3, devfn&7, bar_reg, bar_sz, bar_data);
> > > +
> > >
> > >          /* Now enable the memory or I/O mapping. */
> > >          cmd = pci_readw(devfn, PCI_COMMAND);
> > > diff --git a/tools/firmware/hvmloader/util.h
> b/tools/firmware/hvmloader/util.h
> > > index 07a9d42..ff06071 100644
> > > --- a/tools/firmware/hvmloader/util.h
> > > +++ b/tools/firmware/hvmloader/util.h
> > > @@ -215,6 +215,7 @@ void pci_setup(void);
> > >  uint32_t rombios_highbios_setup(void);
> > >
> > >  /* Miscellaneous. */
> > > +unsigned int cpu_phys_addr(void);
> > >  void cacheattr_init(void);
> > >  unsigned long create_mp_tables(void *table);
> > >  void hvm_write_smbios_tables(
> > > --
> > > 1.5.5
> >
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 13:09:53 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 13:09:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLD5V-0003zD-Fm; Mon, 08 Oct 2012 13:09:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLD5U-0003z7-7o
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 13:09:36 +0000
Received: from [85.158.138.51:22019] by server-8.bemta-3.messagelabs.com id
	C2/E1-16337-F80D2705; Mon, 08 Oct 2012 13:09:35 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1349701773!31738166!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ5NjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3179 invoked from network); 8 Oct 2012 13:09:34 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 13:09:34 -0000
X-IronPort-AV: E=Sophos;i="4.80,554,1344211200"; d="scan'208";a="40445122"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 13:09:32 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 8 Oct 2012 09:09:32 -0400
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TLD5Q-0002zg-7q;
	Mon, 08 Oct 2012 14:09:32 +0100
MIME-Version: 1.0
X-Mercurial-Node: 37f1afbec80b0f052aec9aa8c1130419f102a181
Message-ID: <37f1afbec80b0f052aec.1349701772@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.3.1
Date: Mon, 8 Oct 2012 14:09:32 +0100
From: Andrew Cooper 
To: 
Cc: Ian Campbell , Keir Fraser ,
	Jan Beulich ,
	Stefano Stabellini 
Subject: [Xen-devel] [PATCH] irq: Remove irqaction.free_on_release
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

It is always set to 1, and only checked on some of the codepaths which free an
irqaction.

Signed-off-by: Andrew Cooper 

--
This patch does touch common code as well as x86 and arm architectures,
so probably needs quite a few acks.

diff -r 5fbdbf585f5f -r 37f1afbec80b xen/arch/arm/gic.c
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -373,7 +373,7 @@ void __init release_irq(unsigned int irq
     /* Wait to make sure it's not being used on another CPU */
     do { smp_mb(); } while ( desc->status & IRQ_INPROGRESS );
 
-    if (action && action->free_on_release)
+    if ( action )
         xfree(action);
 }
 
diff -r 5fbdbf585f5f -r 37f1afbec80b xen/arch/arm/irq.c
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -97,7 +97,6 @@ int __init request_irq(unsigned int irq,
     action->handler = handler;
     action->name = devname;
     action->dev_id = dev_id;
-    action->free_on_release = 1;
 
     retval = setup_irq(irq, action);
     if (retval)
diff -r 5fbdbf585f5f -r 37f1afbec80b xen/arch/x86/irq.c
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -952,7 +952,6 @@ int __init request_irq(unsigned int irq,
     action->handler = handler;
     action->name = devname;
     action->dev_id = dev_id;
-    action->free_on_release = 1;
 
     retval = setup_irq(irq, action);
     if (retval)
@@ -979,7 +978,7 @@ void __init release_irq(unsigned int irq
     /* Wait to make sure it's not being used on another CPU */
     do { smp_mb(); } while ( desc->status & IRQ_INPROGRESS );
 
-    if (action && action->free_on_release)
+    if ( action )
         xfree(action);
 }
 
diff -r 5fbdbf585f5f -r 37f1afbec80b xen/include/xen/irq.h
--- a/xen/include/xen/irq.h
+++ b/xen/include/xen/irq.h
@@ -13,7 +13,6 @@ struct irqaction {
     void (*handler)(int, void *, struct cpu_user_regs *);
     const char *name;
     void *dev_id;
-    bool_t free_on_release;
 };
 
 /*

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 13:09:53 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 13:09:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLD5V-0003zD-Fm; Mon, 08 Oct 2012 13:09:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLD5U-0003z7-7o
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 13:09:36 +0000
Received: from [85.158.138.51:22019] by server-8.bemta-3.messagelabs.com id
	C2/E1-16337-F80D2705; Mon, 08 Oct 2012 13:09:35 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1349701773!31738166!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ5NjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3179 invoked from network); 8 Oct 2012 13:09:34 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 13:09:34 -0000
X-IronPort-AV: E=Sophos;i="4.80,554,1344211200"; d="scan'208";a="40445122"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 13:09:32 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 8 Oct 2012 09:09:32 -0400
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TLD5Q-0002zg-7q;
	Mon, 08 Oct 2012 14:09:32 +0100
MIME-Version: 1.0
X-Mercurial-Node: 37f1afbec80b0f052aec9aa8c1130419f102a181
Message-ID: <37f1afbec80b0f052aec.1349701772@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.3.1
Date: Mon, 8 Oct 2012 14:09:32 +0100
From: Andrew Cooper 
To: 
Cc: Ian Campbell , Keir Fraser ,
	Jan Beulich ,
	Stefano Stabellini 
Subject: [Xen-devel] [PATCH] irq: Remove irqaction.free_on_release
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

It is always set to 1, and only checked on some of the codepaths which free an
irqaction.

Signed-off-by: Andrew Cooper 

--
This patch does touch common code as well as x86 and arm architectures,
so probably needs quite a few acks.

diff -r 5fbdbf585f5f -r 37f1afbec80b xen/arch/arm/gic.c
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -373,7 +373,7 @@ void __init release_irq(unsigned int irq
     /* Wait to make sure it's not being used on another CPU */
     do { smp_mb(); } while ( desc->status & IRQ_INPROGRESS );
 
-    if (action && action->free_on_release)
+    if ( action )
         xfree(action);
 }
 
diff -r 5fbdbf585f5f -r 37f1afbec80b xen/arch/arm/irq.c
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -97,7 +97,6 @@ int __init request_irq(unsigned int irq,
     action->handler = handler;
     action->name = devname;
     action->dev_id = dev_id;
-    action->free_on_release = 1;
 
     retval = setup_irq(irq, action);
     if (retval)
diff -r 5fbdbf585f5f -r 37f1afbec80b xen/arch/x86/irq.c
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -952,7 +952,6 @@ int __init request_irq(unsigned int irq,
     action->handler = handler;
     action->name = devname;
     action->dev_id = dev_id;
-    action->free_on_release = 1;
 
     retval = setup_irq(irq, action);
     if (retval)
@@ -979,7 +978,7 @@ void __init release_irq(unsigned int irq
     /* Wait to make sure it's not being used on another CPU */
     do { smp_mb(); } while ( desc->status & IRQ_INPROGRESS );
 
-    if (action && action->free_on_release)
+    if ( action )
         xfree(action);
 }
 
diff -r 5fbdbf585f5f -r 37f1afbec80b xen/include/xen/irq.h
--- a/xen/include/xen/irq.h
+++ b/xen/include/xen/irq.h
@@ -13,7 +13,6 @@ struct irqaction {
     void (*handler)(int, void *, struct cpu_user_regs *);
     const char *name;
     void *dev_id;
-    bool_t free_on_release;
 };
 
 /*

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 13:36:46 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 13:36:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLDVR-0004HG-0p; Mon, 08 Oct 2012 13:36:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLDVP-0004HB-1f
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 13:36:23 +0000
Received: from [85.158.137.99:64466] by server-7.bemta-3.messagelabs.com id
	37/67-15765-6D6D2705; Mon, 08 Oct 2012 13:36:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1349703381!17562765!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMzNDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4030 invoked from network); 8 Oct 2012 13:36:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 13:36:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,554,1344211200"; d="scan'208";a="15002805"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 13:36:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 8 Oct 2012
	14:36:21 +0100
Message-ID: <1349703379.21847.9.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Matthew Fioravante 
Date: Mon, 8 Oct 2012 14:36:19 +0100
In-Reply-To: <1349696888.18008.126.camel@zakaz.uk.xensource.com>
References: <1349460077-13770-1-git-send-email-matthew.fioravante@jhuapl.edu>
	<1349696888.18008.126.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "samuel.thibault@ens-lyons.org" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH vtpm v2 01/12] Add ioread/iowrite functions
 to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gTW9uLCAyMDEyLTEwLTA4IGF0IDEyOjQ4ICswMTAwLCBJYW4gQ2FtcGJlbGwgd3JvdGU6Cj4g
SSB3YXMgYWJvdXQgdG8gYXBwbHkgbm9zLiAxICYgMy03IGJ1dCB0aGVyZSB3YXMgYSBidWlsZCBl
cnJvcjoKPiAgICAgICAgIEluIGZpbGUgaW5jbHVkZWQgZnJvbSBtaW5pLW9zLmM6MjM6Cj4gICAg
ICAgICAuLi9ncnViLXVwc3RyZWFtL25ldGJvb3QvZXRoZXJib290Lmg6NTI2OiBlcnJvcjogY29u
ZmxpY3RpbmcgdHlwZXMgZm9yIOKAmGluZXRfYXRvbuKAmQo+ICAgICAgICAgL2xvY2FsL3NjcmF0
Y2gvaWFuYy9kZXZlbC9jb21taXR0ZXIuZ2l0L3N0dWJkb20vbHdpcC14ODZfNjQvc3JjL2luY2x1
ZGUvaXB2NC9sd2lwL2luZXQuaDo0NDogbm90ZTogcHJldmlvdXMgZGVjbGFyYXRpb24gb2Yg4oCY
aW5ldF9hdG9u4oCZIHdhcyBoZXJlCj4gICAgICAgICBtaW5pLW9zLmM6IEluIGZ1bmN0aW9uIOKA
mGxvYWRfbW9kdWxl4oCZOgo+ICAgICAgICAgbWluaS1vcy5jOjI0NDogd2FybmluZzogc3RhdGVt
ZW50IHdpdGggbm8gZWZmZWN0Cj4gICAgICAgICBtaW5pLW9zLmM6IEluIGZ1bmN0aW9uIOKAmG1h
aW7igJk6Cj4gICAgICAgICBtaW5pLW9zLmM6NzQ3OiB3YXJuaW5nOiBjYXN0IGZyb20gcG9pbnRl
ciB0byBpbnRlZ2VyIG9mIGRpZmZlcmVudCBzaXplCj4gICAgICAgICBtYWtlWzJdOiAqKiogWy9s
b2NhbC9zY3JhdGNoL2lhbmMvZGV2ZWwvY29tbWl0dGVyLmdpdC9zdHViZG9tL2dydWIteDg2XzY0
L21pbmktb3Mub10gRXJyb3IgMQo+ICAgICAgICAgbWFrZVsyXTogKioqIFdhaXRpbmcgZm9yIHVu
ZmluaXNoZWQgam9icy4uLi4KClRoaXMgd2FzIGRvd24gdG8gIzYgIm1pbmlvczogYWRkIHNlbGVj
dCBkZWZpbml0aW9uIHRvIHN5cy90aW1lLmggd2hlbgpIQVZFX0xJQkMgaXMgZGVmaW5lZCIgLS0g
d2hpY2ggSSBndWVzcyBjYXVzZWQgYW4gaW5kaXJlY3QgaW5jbHVzaW9uIG9mCnRoZSBwcm9ibGVt
YXRpYyBoZWFkZXI/IEknbSBjb21waWxpbmcgb24gRGViaWFuIFNxdWVlemUgQlRXLgoKU28gSSBo
YXZlIGdvbmUgYWhlYWQgYW5kIGNvbW1pdHRlZCAxLCAzLTUgJiA3LCBJT1c6Cm1pbmlvczogc2V0
dXAgZnB1IGFuZCBzc2UgaW4gbWluaS1vcwptaW5pb3M6IGFkZCBDT05GSUdfWEMgY29uZGl0aW9u
YWwKbWluaW9zOiBEaXNhYmxlIHRoZSBtZm5faXNfcmFtKCkgY2hlY2ssIGl0IGRvZXNuJ3Qgd29y
ayBjb3JyZWN0bHkgb24gYWxsCm1pbmlvczogQWRkIGVuZGlhbiwgYnl0ZXN3YXAsIGFuZCB3b3Jk
c2l6ZSBtYWNyb3MgdG8gbWluaS1vcwptaW5pb3M6IEFkZCBpb3JlYWQvaW93cml0ZSBmdW5jdGlv
bnMgdG8gbWluaS1vcwoKPiBUaGVyZSB3YXMgYWxzbyBhIHNsZXcgb2Ygd2FybmluZ3MgLS0gYnV0
IEkgdGhpbmsgbWFueSBvZiB0aGVtIG1pZ2h0IGJlCj4gbm9ybWFsIGZvciBhIHN0dWJkb20gYnVp
bGQgKEknbGwgaGF2ZSB0byBjaGVjaykuCgpUaGVzZSB0dXJuZWQgb3V0IHRvIGJlIHByZS1leGlz
dGluZy4KCj4gQlRXIEkgd2FzIHNraXBwaW5nLCB0aGlzIHRpbWUgcm91bmQ6Cj4gCj4gIzIgYmVj
YXVzZSBTYW11ZWwgc2VlbWVkIHRvIGhhdmUgc29tZSBhZGRpdGlvbmFsIHRob3VnaHRzIHRoaXMg
bW9ybmluZy4KPiAKPiAjOCBiZWNhdXNlIEkgd2FudGVkIHRvIGhhdmUgYW5vdGhlciBxdWljayBy
ZWFkIHRocm91Z2ggYmVmb3JlIEkgYXBwbGllZAo+IGl0Lgo+IAo+ICM5IGFuZCAjMTAgYXJlIGFs
cmVhZHkgYXBwbGllZC4KPiAKPiAjMTEgaGFzbid0IGJlZW4gYWNrZWQsIGFsdGhvdWdoIEkgc2Vl
IEdlb3JnZSBoYXMgcmV2aWV3ZWQgaXQgYXQgbGVhc3QKPiBzb21ld2hhdC4gSG9wZWZ1bGx5IG9u
ZSBvciB0aGUgb3RoZXIgb2YgdXMgKG9yIHNvbWVvbmUgZWxzZSkgd2lsbCBmaW5kCj4gdGhlIHRp
bWUgc2hvcnRseS4KPiAKPiAjMTIgaXMgYWxyZWFkeSBhcHBsaWVkCj4gCj4gSWFuLgo+IAo+IE9u
IEZyaSwgMjAxMi0xMC0wNSBhdCAxOTowMSArMDEwMCwgTWF0dGhldyBGaW9yYXZhbnRlIHdyb3Rl
Ogo+ID4gVGhpcyBwYXRjaCBhZGRzIGlvd3JpdGV4eCgpIGFuZCBpb3JlYWR4eCgpIGZ1bmN0aW9u
cyBmb3IgaW50ZXJhY3RpbmcKPiA+IHdpdGggaGFyZHdhcmUgbWVtb3J5IHRvIG1pbmktb3MuIFRo
ZSBmdW5jdGlvbnMgYXJlIGF2YWlsYWJsZSBpbiBhIGhlYWRlcgo+ID4gaW9ydy5oCj4gPiAKPiA+
IFNpZ25lZC1vZmYtYnk6IE1hdHRoZXcgRmlvcmF2YW50ZSA8bWF0dGhldy5maW9yYXZhbnRlQGpo
dWFwbC5lZHU+Cj4gPiBBY2tlZC1ieTogU2FtdWVsIFRoaWJhdWx0IDxzYW11ZWwudGhpYmF1bHRA
ZW5zLWx5b25zLm9yZz4KPiA+IFJldmlld2VkLWJ5OiBHZW9yZ2UgRHVubGFwIDxnZW9yZ2UuZHVu
bGFwQGV1LmNpdHJpeC5jb20+Cj4gPiAKPiA+IGRpZmYgLS1naXQgYS9leHRyYXMvbWluaS1vcy9h
cmNoL3g4Ni9pb3J3LmMgYi9leHRyYXMvbWluaS1vcy9hcmNoL3g4Ni9pb3J3LmMKPiA+IG5ldyBm
aWxlIG1vZGUgMTAwNjQ0Cj4gPiBpbmRleCAwMDAwMDAwLi4zMDgwNzY5Cj4gPiAtLS0gL2Rldi9u
dWxsCj4gPiArKysgYi9leHRyYXMvbWluaS1vcy9hcmNoL3g4Ni9pb3J3LmMKPiA+IEBAIC0wLDAg
KzEsMzUgQEAKPiA+ICsjaW5jbHVkZSA8bWluaS1vcy9pb3J3Lmg+Cj4gPiArCj4gPiArdm9pZCBp
b3dyaXRlOCh2b2xhdGlsZSB2b2lkKiBhZGRyLCB1aW50OF90IHZhbCkKPiA+ICt7Cj4gPiArICAg
Kigodm9sYXRpbGUgdWludDhfdCopYWRkcikgPSB2YWw7Cj4gPiArfQo+ID4gK3ZvaWQgaW93cml0
ZTE2KHZvbGF0aWxlIHZvaWQqIGFkZHIsIHVpbnQxNl90IHZhbCkKPiA+ICt7Cj4gPiArICAgKigo
dm9sYXRpbGUgdWludDE2X3QqKWFkZHIpID0gdmFsOwo+ID4gK30KPiA+ICt2b2lkIGlvd3JpdGUz
Mih2b2xhdGlsZSB2b2lkKiBhZGRyLCB1aW50MzJfdCB2YWwpCj4gPiArewo+ID4gKyAgICooKHZv
bGF0aWxlIHVpbnQzMl90KilhZGRyKSA9IHZhbDsKPiA+ICt9Cj4gPiArdm9pZCBpb3dyaXRlNjQo
dm9sYXRpbGUgdm9pZCogYWRkciwgdWludDY0X3QgdmFsKQo+ID4gK3sKPiA+ICsgICAqKCh2b2xh
dGlsZSB1aW50NjRfdCopYWRkcikgPSB2YWw7Cj4gPiArfQo+ID4gKwo+ID4gK3VpbnQ4X3QgaW9y
ZWFkOCh2b2xhdGlsZSB2b2lkKiBhZGRyKQo+ID4gK3sKPiA+ICsgICByZXR1cm4gKigodm9sYXRp
bGUgdWludDhfdCopIGFkZHIpOwo+ID4gK30KPiA+ICt1aW50MTZfdCBpb3JlYWQxNih2b2xhdGls
ZSB2b2lkKiBhZGRyKQo+ID4gK3sKPiA+ICsgICByZXR1cm4gKigodm9sYXRpbGUgdWludDE2X3Qq
KSBhZGRyKTsKPiA+ICt9Cj4gPiArdWludDMyX3QgaW9yZWFkMzIodm9sYXRpbGUgdm9pZCogYWRk
cikKPiA+ICt7Cj4gPiArICAgcmV0dXJuICooKHZvbGF0aWxlIHVpbnQzMl90KikgYWRkcik7Cj4g
PiArfQo+ID4gK3VpbnQ2NF90IGlvcmVhZDY0KHZvbGF0aWxlIHZvaWQqIGFkZHIpCj4gPiArewo+
ID4gKyAgIHJldHVybiAqKCh2b2xhdGlsZSB1aW50NjRfdCopIGFkZHIpOwo+ID4gK30KPiA+IGRp
ZmYgLS1naXQgYS9leHRyYXMvbWluaS1vcy9pbmNsdWRlL2lvcncuaCBiL2V4dHJhcy9taW5pLW9z
L2luY2x1ZGUvaW9ydy5oCj4gPiBuZXcgZmlsZSBtb2RlIDEwMDY0NAo+ID4gaW5kZXggMDAwMDAw
MC4uZDVlYzA2NQo+ID4gLS0tIC9kZXYvbnVsbAo+ID4gKysrIGIvZXh0cmFzL21pbmktb3MvaW5j
bHVkZS9pb3J3LmgKPiA+IEBAIC0wLDAgKzEsMTYgQEAKPiA+ICsjaWZuZGVmIE1JTklPU19JT1JX
X0gKPiA+ICsjZGVmaW5lIE1JTklPU19JT1JXX0gKPiA+ICsKPiA+ICsjaW5jbHVkZSA8bWluaS1v
cy90eXBlcy5oPgo+ID4gKwo+ID4gK3ZvaWQgaW93cml0ZTgodm9sYXRpbGUgdm9pZCogYWRkciwg
dWludDhfdCB2YWwpOwo+ID4gK3ZvaWQgaW93cml0ZTE2KHZvbGF0aWxlIHZvaWQqIGFkZHIsIHVp
bnQxNl90IHZhbCk7Cj4gPiArdm9pZCBpb3dyaXRlMzIodm9sYXRpbGUgdm9pZCogYWRkciwgdWlu
dDMyX3QgdmFsKTsKPiA+ICt2b2lkIGlvd3JpdGU2NCh2b2xhdGlsZSB2b2lkKiBhZGRyLCB1aW50
NjRfdCB2YWwpOwo+ID4gKwo+ID4gK3VpbnQ4X3QgaW9yZWFkOCh2b2xhdGlsZSB2b2lkKiBhZGRy
KTsKPiA+ICt1aW50MTZfdCBpb3JlYWQxNih2b2xhdGlsZSB2b2lkKiBhZGRyKTsKPiA+ICt1aW50
MzJfdCBpb3JlYWQzMih2b2xhdGlsZSB2b2lkKiBhZGRyKTsKPiA+ICt1aW50NjRfdCBpb3JlYWQ2
NCh2b2xhdGlsZSB2b2lkKiBhZGRyKTsKPiA+ICsKPiA+ICsjZW5kaWYKPiAKPiAKPiAKPiBfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IFhlbi1kZXZlbCBt
YWlsaW5nIGxpc3QKPiBYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwo+IGh0dHA6Ly9saXN0cy54ZW4u
b3JnL3hlbi1kZXZlbAoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0
dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Mon Oct 08 13:36:46 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 13:36:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLDVR-0004HG-0p; Mon, 08 Oct 2012 13:36:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLDVP-0004HB-1f
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 13:36:23 +0000
Received: from [85.158.137.99:64466] by server-7.bemta-3.messagelabs.com id
	37/67-15765-6D6D2705; Mon, 08 Oct 2012 13:36:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1349703381!17562765!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMzNDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4030 invoked from network); 8 Oct 2012 13:36:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 13:36:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,554,1344211200"; d="scan'208";a="15002805"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 13:36:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 8 Oct 2012
	14:36:21 +0100
Message-ID: <1349703379.21847.9.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Matthew Fioravante 
Date: Mon, 8 Oct 2012 14:36:19 +0100
In-Reply-To: <1349696888.18008.126.camel@zakaz.uk.xensource.com>
References: <1349460077-13770-1-git-send-email-matthew.fioravante@jhuapl.edu>
	<1349696888.18008.126.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "samuel.thibault@ens-lyons.org" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH vtpm v2 01/12] Add ioread/iowrite functions
 to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gTW9uLCAyMDEyLTEwLTA4IGF0IDEyOjQ4ICswMTAwLCBJYW4gQ2FtcGJlbGwgd3JvdGU6Cj4g
SSB3YXMgYWJvdXQgdG8gYXBwbHkgbm9zLiAxICYgMy03IGJ1dCB0aGVyZSB3YXMgYSBidWlsZCBl
cnJvcjoKPiAgICAgICAgIEluIGZpbGUgaW5jbHVkZWQgZnJvbSBtaW5pLW9zLmM6MjM6Cj4gICAg
ICAgICAuLi9ncnViLXVwc3RyZWFtL25ldGJvb3QvZXRoZXJib290Lmg6NTI2OiBlcnJvcjogY29u
ZmxpY3RpbmcgdHlwZXMgZm9yIOKAmGluZXRfYXRvbuKAmQo+ICAgICAgICAgL2xvY2FsL3NjcmF0
Y2gvaWFuYy9kZXZlbC9jb21taXR0ZXIuZ2l0L3N0dWJkb20vbHdpcC14ODZfNjQvc3JjL2luY2x1
ZGUvaXB2NC9sd2lwL2luZXQuaDo0NDogbm90ZTogcHJldmlvdXMgZGVjbGFyYXRpb24gb2Yg4oCY
aW5ldF9hdG9u4oCZIHdhcyBoZXJlCj4gICAgICAgICBtaW5pLW9zLmM6IEluIGZ1bmN0aW9uIOKA
mGxvYWRfbW9kdWxl4oCZOgo+ICAgICAgICAgbWluaS1vcy5jOjI0NDogd2FybmluZzogc3RhdGVt
ZW50IHdpdGggbm8gZWZmZWN0Cj4gICAgICAgICBtaW5pLW9zLmM6IEluIGZ1bmN0aW9uIOKAmG1h
aW7igJk6Cj4gICAgICAgICBtaW5pLW9zLmM6NzQ3OiB3YXJuaW5nOiBjYXN0IGZyb20gcG9pbnRl
ciB0byBpbnRlZ2VyIG9mIGRpZmZlcmVudCBzaXplCj4gICAgICAgICBtYWtlWzJdOiAqKiogWy9s
b2NhbC9zY3JhdGNoL2lhbmMvZGV2ZWwvY29tbWl0dGVyLmdpdC9zdHViZG9tL2dydWIteDg2XzY0
L21pbmktb3Mub10gRXJyb3IgMQo+ICAgICAgICAgbWFrZVsyXTogKioqIFdhaXRpbmcgZm9yIHVu
ZmluaXNoZWQgam9icy4uLi4KClRoaXMgd2FzIGRvd24gdG8gIzYgIm1pbmlvczogYWRkIHNlbGVj
dCBkZWZpbml0aW9uIHRvIHN5cy90aW1lLmggd2hlbgpIQVZFX0xJQkMgaXMgZGVmaW5lZCIgLS0g
d2hpY2ggSSBndWVzcyBjYXVzZWQgYW4gaW5kaXJlY3QgaW5jbHVzaW9uIG9mCnRoZSBwcm9ibGVt
YXRpYyBoZWFkZXI/IEknbSBjb21waWxpbmcgb24gRGViaWFuIFNxdWVlemUgQlRXLgoKU28gSSBo
YXZlIGdvbmUgYWhlYWQgYW5kIGNvbW1pdHRlZCAxLCAzLTUgJiA3LCBJT1c6Cm1pbmlvczogc2V0
dXAgZnB1IGFuZCBzc2UgaW4gbWluaS1vcwptaW5pb3M6IGFkZCBDT05GSUdfWEMgY29uZGl0aW9u
YWwKbWluaW9zOiBEaXNhYmxlIHRoZSBtZm5faXNfcmFtKCkgY2hlY2ssIGl0IGRvZXNuJ3Qgd29y
ayBjb3JyZWN0bHkgb24gYWxsCm1pbmlvczogQWRkIGVuZGlhbiwgYnl0ZXN3YXAsIGFuZCB3b3Jk
c2l6ZSBtYWNyb3MgdG8gbWluaS1vcwptaW5pb3M6IEFkZCBpb3JlYWQvaW93cml0ZSBmdW5jdGlv
bnMgdG8gbWluaS1vcwoKPiBUaGVyZSB3YXMgYWxzbyBhIHNsZXcgb2Ygd2FybmluZ3MgLS0gYnV0
IEkgdGhpbmsgbWFueSBvZiB0aGVtIG1pZ2h0IGJlCj4gbm9ybWFsIGZvciBhIHN0dWJkb20gYnVp
bGQgKEknbGwgaGF2ZSB0byBjaGVjaykuCgpUaGVzZSB0dXJuZWQgb3V0IHRvIGJlIHByZS1leGlz
dGluZy4KCj4gQlRXIEkgd2FzIHNraXBwaW5nLCB0aGlzIHRpbWUgcm91bmQ6Cj4gCj4gIzIgYmVj
YXVzZSBTYW11ZWwgc2VlbWVkIHRvIGhhdmUgc29tZSBhZGRpdGlvbmFsIHRob3VnaHRzIHRoaXMg
bW9ybmluZy4KPiAKPiAjOCBiZWNhdXNlIEkgd2FudGVkIHRvIGhhdmUgYW5vdGhlciBxdWljayBy
ZWFkIHRocm91Z2ggYmVmb3JlIEkgYXBwbGllZAo+IGl0Lgo+IAo+ICM5IGFuZCAjMTAgYXJlIGFs
cmVhZHkgYXBwbGllZC4KPiAKPiAjMTEgaGFzbid0IGJlZW4gYWNrZWQsIGFsdGhvdWdoIEkgc2Vl
IEdlb3JnZSBoYXMgcmV2aWV3ZWQgaXQgYXQgbGVhc3QKPiBzb21ld2hhdC4gSG9wZWZ1bGx5IG9u
ZSBvciB0aGUgb3RoZXIgb2YgdXMgKG9yIHNvbWVvbmUgZWxzZSkgd2lsbCBmaW5kCj4gdGhlIHRp
bWUgc2hvcnRseS4KPiAKPiAjMTIgaXMgYWxyZWFkeSBhcHBsaWVkCj4gCj4gSWFuLgo+IAo+IE9u
IEZyaSwgMjAxMi0xMC0wNSBhdCAxOTowMSArMDEwMCwgTWF0dGhldyBGaW9yYXZhbnRlIHdyb3Rl
Ogo+ID4gVGhpcyBwYXRjaCBhZGRzIGlvd3JpdGV4eCgpIGFuZCBpb3JlYWR4eCgpIGZ1bmN0aW9u
cyBmb3IgaW50ZXJhY3RpbmcKPiA+IHdpdGggaGFyZHdhcmUgbWVtb3J5IHRvIG1pbmktb3MuIFRo
ZSBmdW5jdGlvbnMgYXJlIGF2YWlsYWJsZSBpbiBhIGhlYWRlcgo+ID4gaW9ydy5oCj4gPiAKPiA+
IFNpZ25lZC1vZmYtYnk6IE1hdHRoZXcgRmlvcmF2YW50ZSA8bWF0dGhldy5maW9yYXZhbnRlQGpo
dWFwbC5lZHU+Cj4gPiBBY2tlZC1ieTogU2FtdWVsIFRoaWJhdWx0IDxzYW11ZWwudGhpYmF1bHRA
ZW5zLWx5b25zLm9yZz4KPiA+IFJldmlld2VkLWJ5OiBHZW9yZ2UgRHVubGFwIDxnZW9yZ2UuZHVu
bGFwQGV1LmNpdHJpeC5jb20+Cj4gPiAKPiA+IGRpZmYgLS1naXQgYS9leHRyYXMvbWluaS1vcy9h
cmNoL3g4Ni9pb3J3LmMgYi9leHRyYXMvbWluaS1vcy9hcmNoL3g4Ni9pb3J3LmMKPiA+IG5ldyBm
aWxlIG1vZGUgMTAwNjQ0Cj4gPiBpbmRleCAwMDAwMDAwLi4zMDgwNzY5Cj4gPiAtLS0gL2Rldi9u
dWxsCj4gPiArKysgYi9leHRyYXMvbWluaS1vcy9hcmNoL3g4Ni9pb3J3LmMKPiA+IEBAIC0wLDAg
KzEsMzUgQEAKPiA+ICsjaW5jbHVkZSA8bWluaS1vcy9pb3J3Lmg+Cj4gPiArCj4gPiArdm9pZCBp
b3dyaXRlOCh2b2xhdGlsZSB2b2lkKiBhZGRyLCB1aW50OF90IHZhbCkKPiA+ICt7Cj4gPiArICAg
Kigodm9sYXRpbGUgdWludDhfdCopYWRkcikgPSB2YWw7Cj4gPiArfQo+ID4gK3ZvaWQgaW93cml0
ZTE2KHZvbGF0aWxlIHZvaWQqIGFkZHIsIHVpbnQxNl90IHZhbCkKPiA+ICt7Cj4gPiArICAgKigo
dm9sYXRpbGUgdWludDE2X3QqKWFkZHIpID0gdmFsOwo+ID4gK30KPiA+ICt2b2lkIGlvd3JpdGUz
Mih2b2xhdGlsZSB2b2lkKiBhZGRyLCB1aW50MzJfdCB2YWwpCj4gPiArewo+ID4gKyAgICooKHZv
bGF0aWxlIHVpbnQzMl90KilhZGRyKSA9IHZhbDsKPiA+ICt9Cj4gPiArdm9pZCBpb3dyaXRlNjQo
dm9sYXRpbGUgdm9pZCogYWRkciwgdWludDY0X3QgdmFsKQo+ID4gK3sKPiA+ICsgICAqKCh2b2xh
dGlsZSB1aW50NjRfdCopYWRkcikgPSB2YWw7Cj4gPiArfQo+ID4gKwo+ID4gK3VpbnQ4X3QgaW9y
ZWFkOCh2b2xhdGlsZSB2b2lkKiBhZGRyKQo+ID4gK3sKPiA+ICsgICByZXR1cm4gKigodm9sYXRp
bGUgdWludDhfdCopIGFkZHIpOwo+ID4gK30KPiA+ICt1aW50MTZfdCBpb3JlYWQxNih2b2xhdGls
ZSB2b2lkKiBhZGRyKQo+ID4gK3sKPiA+ICsgICByZXR1cm4gKigodm9sYXRpbGUgdWludDE2X3Qq
KSBhZGRyKTsKPiA+ICt9Cj4gPiArdWludDMyX3QgaW9yZWFkMzIodm9sYXRpbGUgdm9pZCogYWRk
cikKPiA+ICt7Cj4gPiArICAgcmV0dXJuICooKHZvbGF0aWxlIHVpbnQzMl90KikgYWRkcik7Cj4g
PiArfQo+ID4gK3VpbnQ2NF90IGlvcmVhZDY0KHZvbGF0aWxlIHZvaWQqIGFkZHIpCj4gPiArewo+
ID4gKyAgIHJldHVybiAqKCh2b2xhdGlsZSB1aW50NjRfdCopIGFkZHIpOwo+ID4gK30KPiA+IGRp
ZmYgLS1naXQgYS9leHRyYXMvbWluaS1vcy9pbmNsdWRlL2lvcncuaCBiL2V4dHJhcy9taW5pLW9z
L2luY2x1ZGUvaW9ydy5oCj4gPiBuZXcgZmlsZSBtb2RlIDEwMDY0NAo+ID4gaW5kZXggMDAwMDAw
MC4uZDVlYzA2NQo+ID4gLS0tIC9kZXYvbnVsbAo+ID4gKysrIGIvZXh0cmFzL21pbmktb3MvaW5j
bHVkZS9pb3J3LmgKPiA+IEBAIC0wLDAgKzEsMTYgQEAKPiA+ICsjaWZuZGVmIE1JTklPU19JT1JX
X0gKPiA+ICsjZGVmaW5lIE1JTklPU19JT1JXX0gKPiA+ICsKPiA+ICsjaW5jbHVkZSA8bWluaS1v
cy90eXBlcy5oPgo+ID4gKwo+ID4gK3ZvaWQgaW93cml0ZTgodm9sYXRpbGUgdm9pZCogYWRkciwg
dWludDhfdCB2YWwpOwo+ID4gK3ZvaWQgaW93cml0ZTE2KHZvbGF0aWxlIHZvaWQqIGFkZHIsIHVp
bnQxNl90IHZhbCk7Cj4gPiArdm9pZCBpb3dyaXRlMzIodm9sYXRpbGUgdm9pZCogYWRkciwgdWlu
dDMyX3QgdmFsKTsKPiA+ICt2b2lkIGlvd3JpdGU2NCh2b2xhdGlsZSB2b2lkKiBhZGRyLCB1aW50
NjRfdCB2YWwpOwo+ID4gKwo+ID4gK3VpbnQ4X3QgaW9yZWFkOCh2b2xhdGlsZSB2b2lkKiBhZGRy
KTsKPiA+ICt1aW50MTZfdCBpb3JlYWQxNih2b2xhdGlsZSB2b2lkKiBhZGRyKTsKPiA+ICt1aW50
MzJfdCBpb3JlYWQzMih2b2xhdGlsZSB2b2lkKiBhZGRyKTsKPiA+ICt1aW50NjRfdCBpb3JlYWQ2
NCh2b2xhdGlsZSB2b2lkKiBhZGRyKTsKPiA+ICsKPiA+ICsjZW5kaWYKPiAKPiAKPiAKPiBfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IFhlbi1kZXZlbCBt
YWlsaW5nIGxpc3QKPiBYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwo+IGh0dHA6Ly9saXN0cy54ZW4u
b3JnL3hlbi1kZXZlbAoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0
dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Mon Oct 08 13:43:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 13:43:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLDbY-0004Qc-RH; Mon, 08 Oct 2012 13:42:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLDbX-0004QX-4w
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 13:42:43 +0000
Received: from [85.158.143.35:59218] by server-2.bemta-4.messagelabs.com id
	1A/9E-06610-258D2705; Mon, 08 Oct 2012 13:42:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1349703759!10451788!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMzNDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11428 invoked from network); 8 Oct 2012 13:42:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 13:42:39 -0000
X-IronPort-AV: E=Sophos;i="4.80,554,1344211200"; d="scan'208";a="15003067"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 13:42:39 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 8 Oct 2012
	14:42:39 +0100
Message-ID: <1349703757.21847.13.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: "xen-devel@lists.xen.org" 
Date: Mon, 8 Oct 2012 14:42:37 +0100
In-Reply-To: <1349433507-21148-1-git-send-email-ian.campbell@citrix.com>
References: <1349433418.20946.46.camel@zakaz.uk.xensource.com>
	<1349433507-21148-1-git-send-email-ian.campbell@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Keir Fraser , "Tim
	\(Xen.org\)" , Jan Beulich ,
	"stefano.stabelini@citrix.com" 
Subject: Re: [Xen-devel] [PATCH 01/21] xen: arm: implement
	XENMEM_add_to_physmap_range
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I should have CC'd Keir, Jan and Mukesh on this one and forgot. Done
now.

On Fri, 2012-10-05 at 11:38 +0100, Ian Campbell wrote:
> This allows for foreign mappings as well as batching, fitting all that
> into XENMEM_add_to_physmap wasn't possible.
> 
> Signed-off-by: Ian Campbell 
> ---
>  xen/arch/arm/mm.c           |  120 ++++++++++++++++++++++++++++++++++++++-----
>  xen/include/public/memory.h |   40 +++++++++++---
>  xen/include/public/xen.h    |    1 +
>  3 files changed, 139 insertions(+), 22 deletions(-)
> 
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index 40ac176..dde304b 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -25,6 +25,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -461,37 +463,96 @@ void share_xen_page_with_guest(struct page_info *page,
>      spin_unlock(&d->page_alloc_lock);
>  }
>  
> -static int xenmem_add_to_physmap_once(
> +static int xenmem_add_to_physmap_one(
>      struct domain *d,
> -    const struct xen_add_to_physmap *xatp)
> +    uint16_t space,
> +    domid_t foreign_domid,
> +    unsigned long idx,
> +    xen_pfn_t gpfn)
>  {
>      unsigned long mfn = 0;
>      int rc;
>  
> -    switch ( xatp->space )
> +    switch ( space )
>      {
> -        case XENMAPSPACE_shared_info:
> -            if ( xatp->idx == 0 )
> -                mfn = virt_to_mfn(d->shared_info);
> -            break;
> -        default:
> -            return -ENOSYS;
> +    case XENMAPSPACE_shared_info:
> +        if ( idx == 0 )
> +            mfn = virt_to_mfn(d->shared_info);
> +        break;
> +    case XENMAPSPACE_gmfn_foreign:
> +    {
> +        paddr_t maddr;
> +        struct domain *od;
> +        rc = rcu_lock_target_domain_by_id(foreign_domid, &od);
> +        if ( rc < 0 )
> +            return rc;
> +
> +        maddr = p2m_lookup(od, idx << PAGE_SHIFT);
> +        if ( maddr == INVALID_PADDR )
> +        {
> +            dump_p2m_lookup(od, idx << PAGE_SHIFT);
> +            rcu_unlock_domain(od);
> +            return -EINVAL;
> +        }
> +
> +        mfn = maddr >> PAGE_SHIFT;
> +
> +        rcu_unlock_domain(od);
> +        break;
> +    }
> +
> +    default:
> +        return -ENOSYS;
>      }
>  
>      domain_lock(d);
>  
>      /* Map at new location. */
> -    rc = guest_physmap_add_page(d, xatp->gpfn, mfn, 0);
> +    rc = guest_physmap_add_page(d, gpfn, mfn, 0);
>  
>      domain_unlock(d);
>  
>      return rc;
>  }
>  
> -static int xenmem_add_to_physmap(struct domain *d,
> -                                 struct xen_add_to_physmap *xatp)
> +static int xenmem_add_to_physmap_range(struct domain *d,
> +                                       struct xen_add_to_physmap_range *xatpr)
>  {
> -    return xenmem_add_to_physmap_once(d, xatp);
> +    int rc;
> +
> +    /* Process entries in reverse order to allow continuations */
> +    while ( xatpr->size > 0 )
> +    {
> +        xen_ulong_t idx;
> +        xen_pfn_t gpfn;
> +
> +        rc = copy_from_guest_offset(&idx, xatpr->idxs, xatpr->size-1, 1);
> +        if ( rc < 0 )
> +            goto out;
> +
> +        rc = copy_from_guest_offset(&gpfn, xatpr->gpfns, xatpr->size-1, 1);
> +        if ( rc < 0 )
> +            goto out;
> +
> +        rc = xenmem_add_to_physmap_one(d, xatpr->space,
> +                                       xatpr->foreign_domid,
> +                                       idx, gpfn);
> +
> +        xatpr->size--;
> +
> +        /* Check for continuation if it's not the last interation */
> +        if ( xatpr->size > 0 && hypercall_preempt_check() )
> +        {
> +            rc = -EAGAIN;
> +            goto out;
> +        }
> +    }
> +
> +    rc = 0;
> +
> +out:
> +    return rc;
> +
>  }
>  
>  long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
> @@ -508,14 +569,45 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
>          if ( copy_from_guest(&xatp, arg, 1) )
>              return -EFAULT;
>  
> +        /* This one is only supported by add_to_physmap_range */
> +        if ( xatp.space == XENMAPSPACE_gmfn_foreign )
> +            return -EINVAL;
> +
>          rc = rcu_lock_target_domain_by_id(xatp.domid, &d);
>          if ( rc != 0 )
>              return rc;
>  
> -        rc = xenmem_add_to_physmap(d, &xatp);
> +        rc = xenmem_add_to_physmap_one(d, xatp.space, DOMID_INVALID,
> +                                       xatp.idx, xatp.gpfn);
> +
> +        rcu_unlock_domain(d);
> +
> +        return rc;
> +    }
> +
> +    case XENMEM_add_to_physmap_range:
> +    {
> +        struct xen_add_to_physmap_range xatpr;
> +        struct domain *d;
> +
> +        if ( copy_from_guest(&xatpr, arg, 1) )
> +            return -EFAULT;
> +
> +        rc = rcu_lock_target_domain_by_id(xatpr.domid, &d);
> +        if ( rc != 0 )
> +            return rc;
> +
> +        rc = xenmem_add_to_physmap_range(d, &xatpr);
>  
>          rcu_unlock_domain(d);
>  
> +        if ( rc && copy_to_guest(arg, &xatpr, 1) )
> +            rc = -EFAULT;
> +
> +        if ( rc == -EAGAIN )
> +            rc = hypercall_create_continuation(
> +                __HYPERVISOR_memory_op, "ih", op, arg);
> +
>          return rc;
>      }
>  
> diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
> index 86d02c8..f1ddbc0 100644
> --- a/xen/include/public/memory.h
> +++ b/xen/include/public/memory.h
> @@ -198,6 +198,15 @@ struct xen_machphys_mapping {
>  typedef struct xen_machphys_mapping xen_machphys_mapping_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_machphys_mapping_t);
>  
> +/* Source mapping space. */
> +/* ` enum phys_map_space { */
> +#define XENMAPSPACE_shared_info  0 /* shared info page */
> +#define XENMAPSPACE_grant_table  1 /* grant table page */
> +#define XENMAPSPACE_gmfn         2 /* GMFN */
> +#define XENMAPSPACE_gmfn_range   3 /* GMFN range */
> +#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another dom */
> +/* ` } */
> +
>  /*
>   * Sets the GPFN at which a particular page appears in the specified guest's
>   * pseudophysical address space.
> @@ -211,24 +220,39 @@ struct xen_add_to_physmap {
>      /* Number of pages to go through for gmfn_range */
>      uint16_t    size;
>  
> -    /* Source mapping space. */
> -#define XENMAPSPACE_shared_info 0 /* shared info page */
> -#define XENMAPSPACE_grant_table 1 /* grant table page */
> -#define XENMAPSPACE_gmfn        2 /* GMFN */
> -#define XENMAPSPACE_gmfn_range  3 /* GMFN range */
> -    unsigned int space;
> +    unsigned int space; /* => enum phys_map_space */
>  
>  #define XENMAPIDX_grant_table_status 0x80000000
>  
> -    /* Index into source mapping space. */
> +    /* Index into space being mapped. */
>      xen_ulong_t idx;
>  
> -    /* GPFN where the source mapping page should appear. */
> +    /* GPFN in domid where the source mapping page should appear. */
>      xen_pfn_t     gpfn;
>  };
>  typedef struct xen_add_to_physmap xen_add_to_physmap_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_t);
>  
> +/* A batched version of add_to_physmap. */
> +#define XENMEM_add_to_physmap_range 23
> +struct xen_add_to_physmap_range {
> +    /* Which domain to change the mapping for. */
> +    domid_t domid;
> +    uint16_t space; /* => enum phys_map_space */
> +
> +    /* Number of pages to go through */
> +    uint16_t size;
> +    domid_t foreign_domid; /* IFF gmfn_foreign */
> +
> +    /* Indexes into space being mapped. */
> +    XEN_GUEST_HANDLE(xen_ulong_t) idxs;
> +
> +    /* GPFN in domdwhere the source mapping page should appear. */
> +    XEN_GUEST_HANDLE(xen_pfn_t) gpfns;
> +};
> +typedef struct xen_add_to_physmap_range xen_add_to_physmap_range_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_range_t);
> +
>  /*
>   * Unmaps the page appearing at a particular GPFN from the specified guest's
>   * pseudophysical address space.
> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> index 361398b..e42d01f 100644
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -49,6 +49,7 @@ DEFINE_XEN_GUEST_HANDLE(void);
>  
>  DEFINE_XEN_GUEST_HANDLE(uint64_t);
>  DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
> +DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
>  #endif
>  
>  /*



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 13:43:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 13:43:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLDbY-0004Qc-RH; Mon, 08 Oct 2012 13:42:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLDbX-0004QX-4w
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 13:42:43 +0000
Received: from [85.158.143.35:59218] by server-2.bemta-4.messagelabs.com id
	1A/9E-06610-258D2705; Mon, 08 Oct 2012 13:42:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1349703759!10451788!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMzNDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11428 invoked from network); 8 Oct 2012 13:42:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 13:42:39 -0000
X-IronPort-AV: E=Sophos;i="4.80,554,1344211200"; d="scan'208";a="15003067"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 13:42:39 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 8 Oct 2012
	14:42:39 +0100
Message-ID: <1349703757.21847.13.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: "xen-devel@lists.xen.org" 
Date: Mon, 8 Oct 2012 14:42:37 +0100
In-Reply-To: <1349433507-21148-1-git-send-email-ian.campbell@citrix.com>
References: <1349433418.20946.46.camel@zakaz.uk.xensource.com>
	<1349433507-21148-1-git-send-email-ian.campbell@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Keir Fraser , "Tim
	\(Xen.org\)" , Jan Beulich ,
	"stefano.stabelini@citrix.com" 
Subject: Re: [Xen-devel] [PATCH 01/21] xen: arm: implement
	XENMEM_add_to_physmap_range
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I should have CC'd Keir, Jan and Mukesh on this one and forgot. Done
now.

On Fri, 2012-10-05 at 11:38 +0100, Ian Campbell wrote:
> This allows for foreign mappings as well as batching, fitting all that
> into XENMEM_add_to_physmap wasn't possible.
> 
> Signed-off-by: Ian Campbell 
> ---
>  xen/arch/arm/mm.c           |  120 ++++++++++++++++++++++++++++++++++++++-----
>  xen/include/public/memory.h |   40 +++++++++++---
>  xen/include/public/xen.h    |    1 +
>  3 files changed, 139 insertions(+), 22 deletions(-)
> 
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index 40ac176..dde304b 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -25,6 +25,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -461,37 +463,96 @@ void share_xen_page_with_guest(struct page_info *page,
>      spin_unlock(&d->page_alloc_lock);
>  }
>  
> -static int xenmem_add_to_physmap_once(
> +static int xenmem_add_to_physmap_one(
>      struct domain *d,
> -    const struct xen_add_to_physmap *xatp)
> +    uint16_t space,
> +    domid_t foreign_domid,
> +    unsigned long idx,
> +    xen_pfn_t gpfn)
>  {
>      unsigned long mfn = 0;
>      int rc;
>  
> -    switch ( xatp->space )
> +    switch ( space )
>      {
> -        case XENMAPSPACE_shared_info:
> -            if ( xatp->idx == 0 )
> -                mfn = virt_to_mfn(d->shared_info);
> -            break;
> -        default:
> -            return -ENOSYS;
> +    case XENMAPSPACE_shared_info:
> +        if ( idx == 0 )
> +            mfn = virt_to_mfn(d->shared_info);
> +        break;
> +    case XENMAPSPACE_gmfn_foreign:
> +    {
> +        paddr_t maddr;
> +        struct domain *od;
> +        rc = rcu_lock_target_domain_by_id(foreign_domid, &od);
> +        if ( rc < 0 )
> +            return rc;
> +
> +        maddr = p2m_lookup(od, idx << PAGE_SHIFT);
> +        if ( maddr == INVALID_PADDR )
> +        {
> +            dump_p2m_lookup(od, idx << PAGE_SHIFT);
> +            rcu_unlock_domain(od);
> +            return -EINVAL;
> +        }
> +
> +        mfn = maddr >> PAGE_SHIFT;
> +
> +        rcu_unlock_domain(od);
> +        break;
> +    }
> +
> +    default:
> +        return -ENOSYS;
>      }
>  
>      domain_lock(d);
>  
>      /* Map at new location. */
> -    rc = guest_physmap_add_page(d, xatp->gpfn, mfn, 0);
> +    rc = guest_physmap_add_page(d, gpfn, mfn, 0);
>  
>      domain_unlock(d);
>  
>      return rc;
>  }
>  
> -static int xenmem_add_to_physmap(struct domain *d,
> -                                 struct xen_add_to_physmap *xatp)
> +static int xenmem_add_to_physmap_range(struct domain *d,
> +                                       struct xen_add_to_physmap_range *xatpr)
>  {
> -    return xenmem_add_to_physmap_once(d, xatp);
> +    int rc;
> +
> +    /* Process entries in reverse order to allow continuations */
> +    while ( xatpr->size > 0 )
> +    {
> +        xen_ulong_t idx;
> +        xen_pfn_t gpfn;
> +
> +        rc = copy_from_guest_offset(&idx, xatpr->idxs, xatpr->size-1, 1);
> +        if ( rc < 0 )
> +            goto out;
> +
> +        rc = copy_from_guest_offset(&gpfn, xatpr->gpfns, xatpr->size-1, 1);
> +        if ( rc < 0 )
> +            goto out;
> +
> +        rc = xenmem_add_to_physmap_one(d, xatpr->space,
> +                                       xatpr->foreign_domid,
> +                                       idx, gpfn);
> +
> +        xatpr->size--;
> +
> +        /* Check for continuation if it's not the last interation */
> +        if ( xatpr->size > 0 && hypercall_preempt_check() )
> +        {
> +            rc = -EAGAIN;
> +            goto out;
> +        }
> +    }
> +
> +    rc = 0;
> +
> +out:
> +    return rc;
> +
>  }
>  
>  long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
> @@ -508,14 +569,45 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
>          if ( copy_from_guest(&xatp, arg, 1) )
>              return -EFAULT;
>  
> +        /* This one is only supported by add_to_physmap_range */
> +        if ( xatp.space == XENMAPSPACE_gmfn_foreign )
> +            return -EINVAL;
> +
>          rc = rcu_lock_target_domain_by_id(xatp.domid, &d);
>          if ( rc != 0 )
>              return rc;
>  
> -        rc = xenmem_add_to_physmap(d, &xatp);
> +        rc = xenmem_add_to_physmap_one(d, xatp.space, DOMID_INVALID,
> +                                       xatp.idx, xatp.gpfn);
> +
> +        rcu_unlock_domain(d);
> +
> +        return rc;
> +    }
> +
> +    case XENMEM_add_to_physmap_range:
> +    {
> +        struct xen_add_to_physmap_range xatpr;
> +        struct domain *d;
> +
> +        if ( copy_from_guest(&xatpr, arg, 1) )
> +            return -EFAULT;
> +
> +        rc = rcu_lock_target_domain_by_id(xatpr.domid, &d);
> +        if ( rc != 0 )
> +            return rc;
> +
> +        rc = xenmem_add_to_physmap_range(d, &xatpr);
>  
>          rcu_unlock_domain(d);
>  
> +        if ( rc && copy_to_guest(arg, &xatpr, 1) )
> +            rc = -EFAULT;
> +
> +        if ( rc == -EAGAIN )
> +            rc = hypercall_create_continuation(
> +                __HYPERVISOR_memory_op, "ih", op, arg);
> +
>          return rc;
>      }
>  
> diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
> index 86d02c8..f1ddbc0 100644
> --- a/xen/include/public/memory.h
> +++ b/xen/include/public/memory.h
> @@ -198,6 +198,15 @@ struct xen_machphys_mapping {
>  typedef struct xen_machphys_mapping xen_machphys_mapping_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_machphys_mapping_t);
>  
> +/* Source mapping space. */
> +/* ` enum phys_map_space { */
> +#define XENMAPSPACE_shared_info  0 /* shared info page */
> +#define XENMAPSPACE_grant_table  1 /* grant table page */
> +#define XENMAPSPACE_gmfn         2 /* GMFN */
> +#define XENMAPSPACE_gmfn_range   3 /* GMFN range */
> +#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another dom */
> +/* ` } */
> +
>  /*
>   * Sets the GPFN at which a particular page appears in the specified guest's
>   * pseudophysical address space.
> @@ -211,24 +220,39 @@ struct xen_add_to_physmap {
>      /* Number of pages to go through for gmfn_range */
>      uint16_t    size;
>  
> -    /* Source mapping space. */
> -#define XENMAPSPACE_shared_info 0 /* shared info page */
> -#define XENMAPSPACE_grant_table 1 /* grant table page */
> -#define XENMAPSPACE_gmfn        2 /* GMFN */
> -#define XENMAPSPACE_gmfn_range  3 /* GMFN range */
> -    unsigned int space;
> +    unsigned int space; /* => enum phys_map_space */
>  
>  #define XENMAPIDX_grant_table_status 0x80000000
>  
> -    /* Index into source mapping space. */
> +    /* Index into space being mapped. */
>      xen_ulong_t idx;
>  
> -    /* GPFN where the source mapping page should appear. */
> +    /* GPFN in domid where the source mapping page should appear. */
>      xen_pfn_t     gpfn;
>  };
>  typedef struct xen_add_to_physmap xen_add_to_physmap_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_t);
>  
> +/* A batched version of add_to_physmap. */
> +#define XENMEM_add_to_physmap_range 23
> +struct xen_add_to_physmap_range {
> +    /* Which domain to change the mapping for. */
> +    domid_t domid;
> +    uint16_t space; /* => enum phys_map_space */
> +
> +    /* Number of pages to go through */
> +    uint16_t size;
> +    domid_t foreign_domid; /* IFF gmfn_foreign */
> +
> +    /* Indexes into space being mapped. */
> +    XEN_GUEST_HANDLE(xen_ulong_t) idxs;
> +
> +    /* GPFN in domdwhere the source mapping page should appear. */
> +    XEN_GUEST_HANDLE(xen_pfn_t) gpfns;
> +};
> +typedef struct xen_add_to_physmap_range xen_add_to_physmap_range_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_range_t);
> +
>  /*
>   * Unmaps the page appearing at a particular GPFN from the specified guest's
>   * pseudophysical address space.
> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> index 361398b..e42d01f 100644
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -49,6 +49,7 @@ DEFINE_XEN_GUEST_HANDLE(void);
>  
>  DEFINE_XEN_GUEST_HANDLE(uint64_t);
>  DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
> +DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
>  #endif
>  
>  /*



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 13:45:53 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 13:45:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLDeK-0004il-B8; Mon, 08 Oct 2012 13:45:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLDeI-0004iR-D3
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 13:45:34 +0000
Received: from [85.158.143.99:5744] by server-1.bemta-4.messagelabs.com id
	E4/E1-05684-DF8D2705; Mon, 08 Oct 2012 13:45:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1349703926!26853620!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMzNDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14536 invoked from network); 8 Oct 2012 13:45:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 13:45:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,554,1344211200"; d="scan'208";a="15003183"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 13:45:25 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 8 Oct 2012
	14:45:25 +0100
Message-ID: <1349703924.21847.14.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Mon, 8 Oct 2012 14:45:24 +0100
In-Reply-To: 
References: <1349433418.20946.46.camel@zakaz.uk.xensource.com>
	<1349433507-21148-17-git-send-email-ian.campbell@citrix.com>
	<506ED9E2020000780009FE5A@nat28.tlf.novell.com>
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" ,
	"xen-devel@lists.xen.org" ,
	"Keir \(Xen.org\)" , Jan Beulich ,
	"stefano.stabelini@citrix.com" 
Subject: Re: [Xen-devel] [PATCH 17/21] xen: xen_ulong_t substitution
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-05 at 15:13 +0100, Stefano Stabellini wrote:
> xen/include/public/arch-x86/xen.h defines xen_ulong_t but it looks like
> that  it is missing PRI_xen_ulong

I've added:
#define PRI_xen_ulong lx

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 13:45:53 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 13:45:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLDeK-0004il-B8; Mon, 08 Oct 2012 13:45:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLDeI-0004iR-D3
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 13:45:34 +0000
Received: from [85.158.143.99:5744] by server-1.bemta-4.messagelabs.com id
	E4/E1-05684-DF8D2705; Mon, 08 Oct 2012 13:45:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1349703926!26853620!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMzNDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14536 invoked from network); 8 Oct 2012 13:45:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 13:45:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,554,1344211200"; d="scan'208";a="15003183"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 13:45:25 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 8 Oct 2012
	14:45:25 +0100
Message-ID: <1349703924.21847.14.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Mon, 8 Oct 2012 14:45:24 +0100
In-Reply-To: 
References: <1349433418.20946.46.camel@zakaz.uk.xensource.com>
	<1349433507-21148-17-git-send-email-ian.campbell@citrix.com>
	<506ED9E2020000780009FE5A@nat28.tlf.novell.com>
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" ,
	"xen-devel@lists.xen.org" ,
	"Keir \(Xen.org\)" , Jan Beulich ,
	"stefano.stabelini@citrix.com" 
Subject: Re: [Xen-devel] [PATCH 17/21] xen: xen_ulong_t substitution
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-05 at 15:13 +0100, Stefano Stabellini wrote:
> xen/include/public/arch-x86/xen.h defines xen_ulong_t but it looks like
> that  it is missing PRI_xen_ulong

I've added:
#define PRI_xen_ulong lx

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 14:36:57 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 14:36:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLERI-0005K3-Gk; Mon, 08 Oct 2012 14:36:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLERH-0005Jy-8d
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 14:36:11 +0000
Received: from [85.158.138.51:47087] by server-15.bemta-3.messagelabs.com id
	6A/CD-11584-AD4E2705; Mon, 08 Oct 2012 14:36:10 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-2.tower-174.messagelabs.com!1349706965!33464227!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY,
	UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9955 invoked from network); 8 Oct 2012 14:36:06 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 14:36:06 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.154523754;
	Mon, 08 Oct 2012 10:35:48 -0400
Message-ID: <5072E470.1060404@jhuapl.edu>
Date: Mon, 08 Oct 2012 10:34:24 -0400
From: Matthew Fioravante 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Samuel Thibault , 
	"xen-devel@lists.xensource.com" 
References: <50579C5F.5040004@jhuapl.edu>
	<20120917224619.GO5110@type.youpi.perso.aquilenet.fr>
	<506F209E.2040902@jhuapl.edu>
	<20121008080500.GA5985@type.bordeaux.inria.fr>
In-Reply-To: <20121008080500.GA5985@type.bordeaux.inria.fr>
X-Enigmail-Version: 1.4.4
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 2/8] add posix
	io to blkfront
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============4453656654419012687=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============4453656654419012687==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090708060107090700090408"

This is a cryptographically signed message in MIME format.

--------------ms090708060107090700090408
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

The math done by blkfront doesn't always work if your use
BLKIF_MAX_SEGMENTS_PER_REQUEST (11).

Where you do:
ASSERT(n <=3D BLKIF_MAX_SEGMENTS_PER_REQUEST);

Sometimes n comes out to be BLKIF_MAX_SEGEMENTS_PER_REQUEST +1. This
happens when your buffer address is sector aligned (512k), but not page
aligned (4096k). So we can either optimize yet again if address is page
aligned or use BLKIF_MAX_SEGMENTS_PER_REQUEST-1;

Is the page math being done above that assertion correct?


On 10/08/2012 04:05 AM, Samuel Thibault wrote:
> Matthew Fioravante, le Fri 05 Oct 2012 14:02:06 -0400, a =E9crit :
>> See latest v2 patch
> It looks good, except why BLKIF_MAX_SEGMENTS_PER_REQUEST-1 and not
> BLKIF_MAX_SEGMENTS_PER_REQUEST?
>
> Samuel



--------------ms090708060107090700090408
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMTAwODE0MzQyNFowIwYJKoZIhvcNAQkEMRYEFNHmNxgSIVYT8kLV
zq1pCsyeKyIVMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBAho8zILIpt3/0vl7lCo/PtuyGzdyGj+z1
7dCqG1S5fh0NNa/dQ3ftj5tR7wr5AytHhVz7lt8sdAz2QUxnGsxrmAOsVNx4rLl0BSI0v7IJ
3vcDvBkj/QFGYDbVU9dNSjIPf7Q/i63KcZIj3DGDrdCNaIovP7QDr9WBZB9N7IH6bAAAAAAA
AA==
--------------ms090708060107090700090408--


--===============4453656654419012687==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4453656654419012687==--


From xen-devel-bounces@lists.xen.org Mon Oct 08 14:36:57 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 14:36:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLERI-0005K3-Gk; Mon, 08 Oct 2012 14:36:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLERH-0005Jy-8d
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 14:36:11 +0000
Received: from [85.158.138.51:47087] by server-15.bemta-3.messagelabs.com id
	6A/CD-11584-AD4E2705; Mon, 08 Oct 2012 14:36:10 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-2.tower-174.messagelabs.com!1349706965!33464227!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY,
	UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9955 invoked from network); 8 Oct 2012 14:36:06 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 14:36:06 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.154523754;
	Mon, 08 Oct 2012 10:35:48 -0400
Message-ID: <5072E470.1060404@jhuapl.edu>
Date: Mon, 08 Oct 2012 10:34:24 -0400
From: Matthew Fioravante 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Samuel Thibault , 
	"xen-devel@lists.xensource.com" 
References: <50579C5F.5040004@jhuapl.edu>
	<20120917224619.GO5110@type.youpi.perso.aquilenet.fr>
	<506F209E.2040902@jhuapl.edu>
	<20121008080500.GA5985@type.bordeaux.inria.fr>
In-Reply-To: <20121008080500.GA5985@type.bordeaux.inria.fr>
X-Enigmail-Version: 1.4.4
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 2/8] add posix
	io to blkfront
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============4453656654419012687=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============4453656654419012687==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090708060107090700090408"

This is a cryptographically signed message in MIME format.

--------------ms090708060107090700090408
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

The math done by blkfront doesn't always work if your use
BLKIF_MAX_SEGMENTS_PER_REQUEST (11).

Where you do:
ASSERT(n <=3D BLKIF_MAX_SEGMENTS_PER_REQUEST);

Sometimes n comes out to be BLKIF_MAX_SEGEMENTS_PER_REQUEST +1. This
happens when your buffer address is sector aligned (512k), but not page
aligned (4096k). So we can either optimize yet again if address is page
aligned or use BLKIF_MAX_SEGMENTS_PER_REQUEST-1;

Is the page math being done above that assertion correct?


On 10/08/2012 04:05 AM, Samuel Thibault wrote:
> Matthew Fioravante, le Fri 05 Oct 2012 14:02:06 -0400, a =E9crit :
>> See latest v2 patch
> It looks good, except why BLKIF_MAX_SEGMENTS_PER_REQUEST-1 and not
> BLKIF_MAX_SEGMENTS_PER_REQUEST?
>
> Samuel



--------------ms090708060107090700090408
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMTAwODE0MzQyNFowIwYJKoZIhvcNAQkEMRYEFNHmNxgSIVYT8kLV
zq1pCsyeKyIVMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBAho8zILIpt3/0vl7lCo/PtuyGzdyGj+z1
7dCqG1S5fh0NNa/dQ3ftj5tR7wr5AytHhVz7lt8sdAz2QUxnGsxrmAOsVNx4rLl0BSI0v7IJ
3vcDvBkj/QFGYDbVU9dNSjIPf7Q/i63KcZIj3DGDrdCNaIovP7QDr9WBZB9N7IH6bAAAAAAA
AA==
--------------ms090708060107090700090408--


--===============4453656654419012687==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4453656654419012687==--


From xen-devel-bounces@lists.xen.org Mon Oct 08 14:39:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 14:39:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLEU0-0005Qm-7q; Mon, 08 Oct 2012 14:39:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLETy-0005Qh-3r
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 14:38:58 +0000
Received: from [85.158.137.99:27665] by server-4.bemta-3.messagelabs.com id
	AC/0E-14155-185E2705; Mon, 08 Oct 2012 14:38:57 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-13.tower-217.messagelabs.com!1349707134!20752314!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20612 invoked from network); 8 Oct 2012 14:38:55 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-13.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Oct 2012 14:38:55 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.154524002;
	Mon, 08 Oct 2012 10:38:47 -0400
Message-ID: <5072E524.9020808@jhuapl.edu>
Date: Mon, 08 Oct 2012 10:37:24 -0400
From: Matthew Fioravante 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell 
References: <1349460077-13770-1-git-send-email-matthew.fioravante@jhuapl.edu>
	<1349696888.18008.126.camel@zakaz.uk.xensource.com>
In-Reply-To: <1349696888.18008.126.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.4
Cc: "samuel.thibault@ens-lyons.org" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH vtpm v2 01/12] Add ioread/iowrite functions
	to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============7216392594615517205=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============7216392594615517205==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010400060301090801020305"

This is a cryptographically signed message in MIME format.

--------------ms010400060301090801020305
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I actually came across a lot of build errors in stubdom even without my
patches applied. To build a c stubdom to test I commented out the libxc
and lwip bits from the stubdom makefile.

On 10/08/2012 07:48 AM, Ian Campbell wrote:
> I was about to apply nos. 1 & 3-7 but there was a build error:
>         In file included from mini-os.c:23:
>         ../grub-upstream/netboot/etherboot.h:526: error: conflicting ty=
pes for =E2=80=98inet_aton=E2=80=99
>         /local/scratch/ianc/devel/committer.git/stubdom/lwip-x86_64/src=
/include/ipv4/lwip/inet.h:44: note: previous declaration of =E2=80=98inet=
_aton=E2=80=99 was here
>         mini-os.c: In function =E2=80=98load_module=E2=80=99:
>         mini-os.c:244: warning: statement with no effect
>         mini-os.c: In function =E2=80=98main=E2=80=99:
>         mini-os.c:747: warning: cast from pointer to integer of differe=
nt size
>         make[2]: *** [/local/scratch/ianc/devel/committer.git/stubdom/g=
rub-x86_64/mini-os.o] Error 1
>         make[2]: *** Waiting for unfinished jobs....
>
> There was also a slew of warnings -- but I think many of them might be
> normal for a stubdom build (I'll have to check).
>
> BTW I was skipping, this time round:
>
> #2 because Samuel seemed to have some additional thoughts this morning.=

>
> #8 because I wanted to have another quick read through before I applied=

> it.
>
> #9 and #10 are already applied.
>
> #11 hasn't been acked, although I see George has reviewed it at least
> somewhat. Hopefully one or the other of us (or someone else) will find
> the time shortly.
>
> #12 is already applied
>
> Ian.
>
> On Fri, 2012-10-05 at 19:01 +0100, Matthew Fioravante wrote:
>> This patch adds iowritexx() and ioreadxx() functions for interacting
>> with hardware memory to mini-os. The functions are available in a head=
er
>> iorw.h
>>
>> Signed-off-by: Matthew Fioravante 
>> Acked-by: Samuel Thibault 
>> Reviewed-by: George Dunlap 
>>
>> diff --git a/extras/mini-os/arch/x86/iorw.c b/extras/mini-os/arch/x86/=
iorw.c
>> new file mode 100644
>> index 0000000..3080769
>> --- /dev/null
>> +++ b/extras/mini-os/arch/x86/iorw.c
>> @@ -0,0 +1,35 @@
>> +#include 
>> +
>> +void iowrite8(volatile void* addr, uint8_t val)
>> +{
>> +   *((volatile uint8_t*)addr) =3D val;
>> +}
>> +void iowrite16(volatile void* addr, uint16_t val)
>> +{
>> +   *((volatile uint16_t*)addr) =3D val;
>> +}
>> +void iowrite32(volatile void* addr, uint32_t val)
>> +{
>> +   *((volatile uint32_t*)addr) =3D val;
>> +}
>> +void iowrite64(volatile void* addr, uint64_t val)
>> +{
>> +   *((volatile uint64_t*)addr) =3D val;
>> +}
>> +
>> +uint8_t ioread8(volatile void* addr)
>> +{
>> +   return *((volatile uint8_t*) addr);
>> +}
>> +uint16_t ioread16(volatile void* addr)
>> +{
>> +   return *((volatile uint16_t*) addr);
>> +}
>> +uint32_t ioread32(volatile void* addr)
>> +{
>> +   return *((volatile uint32_t*) addr);
>> +}
>> +uint64_t ioread64(volatile void* addr)
>> +{
>> +   return *((volatile uint64_t*) addr);
>> +}
>> diff --git a/extras/mini-os/include/iorw.h b/extras/mini-os/include/io=
rw.h
>> new file mode 100644
>> index 0000000..d5ec065
>> --- /dev/null
>> +++ b/extras/mini-os/include/iorw.h
>> @@ -0,0 +1,16 @@
>> +#ifndef MINIOS_IORW_H
>> +#define MINIOS_IORW_H
>> +
>> +#include 
>> +
>> +void iowrite8(volatile void* addr, uint8_t val);
>> +void iowrite16(volatile void* addr, uint16_t val);
>> +void iowrite32(volatile void* addr, uint32_t val);
>> +void iowrite64(volatile void* addr, uint64_t val);
>> +
>> +uint8_t ioread8(volatile void* addr);
>> +uint16_t ioread16(volatile void* addr);
>> +uint32_t ioread32(volatile void* addr);
>> +uint64_t ioread64(volatile void* addr);
>> +
>> +#endif
>



--------------ms010400060301090801020305
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMTAwODE0MzcyNFowIwYJKoZIhvcNAQkEMRYEFN3MV5MhzcKpSZM7
6FnrKR3/DXGkMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBFt58Sf/Fy0QGiLg1STq+H8dkarEKBn2Tx
jifhfgrBygdkttNV759QZezDWgBxksXCJwuu+2bJHtpQkniDi5Q5IGzchA+lRubgHDfckCuV
i7LEA1ouxaz0mW5B9k2JSAfddRJIgRkKIsM0cjkPpOhAzrwR6hlycx9Z4JVD5HOaXgAAAAAA
AA==
--------------ms010400060301090801020305--


--===============7216392594615517205==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7216392594615517205==--


From xen-devel-bounces@lists.xen.org Mon Oct 08 14:39:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 14:39:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLEU0-0005Qm-7q; Mon, 08 Oct 2012 14:39:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLETy-0005Qh-3r
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 14:38:58 +0000
Received: from [85.158.137.99:27665] by server-4.bemta-3.messagelabs.com id
	AC/0E-14155-185E2705; Mon, 08 Oct 2012 14:38:57 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-13.tower-217.messagelabs.com!1349707134!20752314!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20612 invoked from network); 8 Oct 2012 14:38:55 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-13.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Oct 2012 14:38:55 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.154524002;
	Mon, 08 Oct 2012 10:38:47 -0400
Message-ID: <5072E524.9020808@jhuapl.edu>
Date: Mon, 08 Oct 2012 10:37:24 -0400
From: Matthew Fioravante 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell 
References: <1349460077-13770-1-git-send-email-matthew.fioravante@jhuapl.edu>
	<1349696888.18008.126.camel@zakaz.uk.xensource.com>
In-Reply-To: <1349696888.18008.126.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.4
Cc: "samuel.thibault@ens-lyons.org" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH vtpm v2 01/12] Add ioread/iowrite functions
	to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============7216392594615517205=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============7216392594615517205==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010400060301090801020305"

This is a cryptographically signed message in MIME format.

--------------ms010400060301090801020305
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I actually came across a lot of build errors in stubdom even without my
patches applied. To build a c stubdom to test I commented out the libxc
and lwip bits from the stubdom makefile.

On 10/08/2012 07:48 AM, Ian Campbell wrote:
> I was about to apply nos. 1 & 3-7 but there was a build error:
>         In file included from mini-os.c:23:
>         ../grub-upstream/netboot/etherboot.h:526: error: conflicting ty=
pes for =E2=80=98inet_aton=E2=80=99
>         /local/scratch/ianc/devel/committer.git/stubdom/lwip-x86_64/src=
/include/ipv4/lwip/inet.h:44: note: previous declaration of =E2=80=98inet=
_aton=E2=80=99 was here
>         mini-os.c: In function =E2=80=98load_module=E2=80=99:
>         mini-os.c:244: warning: statement with no effect
>         mini-os.c: In function =E2=80=98main=E2=80=99:
>         mini-os.c:747: warning: cast from pointer to integer of differe=
nt size
>         make[2]: *** [/local/scratch/ianc/devel/committer.git/stubdom/g=
rub-x86_64/mini-os.o] Error 1
>         make[2]: *** Waiting for unfinished jobs....
>
> There was also a slew of warnings -- but I think many of them might be
> normal for a stubdom build (I'll have to check).
>
> BTW I was skipping, this time round:
>
> #2 because Samuel seemed to have some additional thoughts this morning.=

>
> #8 because I wanted to have another quick read through before I applied=

> it.
>
> #9 and #10 are already applied.
>
> #11 hasn't been acked, although I see George has reviewed it at least
> somewhat. Hopefully one or the other of us (or someone else) will find
> the time shortly.
>
> #12 is already applied
>
> Ian.
>
> On Fri, 2012-10-05 at 19:01 +0100, Matthew Fioravante wrote:
>> This patch adds iowritexx() and ioreadxx() functions for interacting
>> with hardware memory to mini-os. The functions are available in a head=
er
>> iorw.h
>>
>> Signed-off-by: Matthew Fioravante 
>> Acked-by: Samuel Thibault 
>> Reviewed-by: George Dunlap 
>>
>> diff --git a/extras/mini-os/arch/x86/iorw.c b/extras/mini-os/arch/x86/=
iorw.c
>> new file mode 100644
>> index 0000000..3080769
>> --- /dev/null
>> +++ b/extras/mini-os/arch/x86/iorw.c
>> @@ -0,0 +1,35 @@
>> +#include 
>> +
>> +void iowrite8(volatile void* addr, uint8_t val)
>> +{
>> +   *((volatile uint8_t*)addr) =3D val;
>> +}
>> +void iowrite16(volatile void* addr, uint16_t val)
>> +{
>> +   *((volatile uint16_t*)addr) =3D val;
>> +}
>> +void iowrite32(volatile void* addr, uint32_t val)
>> +{
>> +   *((volatile uint32_t*)addr) =3D val;
>> +}
>> +void iowrite64(volatile void* addr, uint64_t val)
>> +{
>> +   *((volatile uint64_t*)addr) =3D val;
>> +}
>> +
>> +uint8_t ioread8(volatile void* addr)
>> +{
>> +   return *((volatile uint8_t*) addr);
>> +}
>> +uint16_t ioread16(volatile void* addr)
>> +{
>> +   return *((volatile uint16_t*) addr);
>> +}
>> +uint32_t ioread32(volatile void* addr)
>> +{
>> +   return *((volatile uint32_t*) addr);
>> +}
>> +uint64_t ioread64(volatile void* addr)
>> +{
>> +   return *((volatile uint64_t*) addr);
>> +}
>> diff --git a/extras/mini-os/include/iorw.h b/extras/mini-os/include/io=
rw.h
>> new file mode 100644
>> index 0000000..d5ec065
>> --- /dev/null
>> +++ b/extras/mini-os/include/iorw.h
>> @@ -0,0 +1,16 @@
>> +#ifndef MINIOS_IORW_H
>> +#define MINIOS_IORW_H
>> +
>> +#include 
>> +
>> +void iowrite8(volatile void* addr, uint8_t val);
>> +void iowrite16(volatile void* addr, uint16_t val);
>> +void iowrite32(volatile void* addr, uint32_t val);
>> +void iowrite64(volatile void* addr, uint64_t val);
>> +
>> +uint8_t ioread8(volatile void* addr);
>> +uint16_t ioread16(volatile void* addr);
>> +uint32_t ioread32(volatile void* addr);
>> +uint64_t ioread64(volatile void* addr);
>> +
>> +#endif
>



--------------ms010400060301090801020305
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMTAwODE0MzcyNFowIwYJKoZIhvcNAQkEMRYEFN3MV5MhzcKpSZM7
6FnrKR3/DXGkMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBFt58Sf/Fy0QGiLg1STq+H8dkarEKBn2Tx
jifhfgrBygdkttNV759QZezDWgBxksXCJwuu+2bJHtpQkniDi5Q5IGzchA+lRubgHDfckCuV
i7LEA1ouxaz0mW5B9k2JSAfddRJIgRkKIsM0cjkPpOhAzrwR6hlycx9Z4JVD5HOaXgAAAAAA
AA==
--------------ms010400060301090801020305--


--===============7216392594615517205==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7216392594615517205==--


From xen-devel-bounces@lists.xen.org Mon Oct 08 14:45:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 14:45:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLEZL-0005ca-3q; Mon, 08 Oct 2012 14:44:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLEZK-0005cV-Ek
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 14:44:30 +0000
Received: from [85.158.143.99:31763] by server-2.bemta-4.messagelabs.com id
	F8/0A-06610-DC6E2705; Mon, 08 Oct 2012 14:44:29 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1349707462!26863355!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzA4Nzg3\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18308 invoked from network); 8 Oct 2012 14:44:23 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-10.tower-216.messagelabs.com with SMTP;
	8 Oct 2012 14:44:23 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 08 Oct 2012 07:44:21 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,554,1344236400"; d="scan'208";a="202964692"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by orsmga001.jf.intel.com with ESMTP; 08 Oct 2012 07:44:20 -0700
Received: from FMSMSX110.amr.corp.intel.com (10.19.9.29) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 8 Oct 2012 07:44:20 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	fmsmsx110.amr.corp.intel.com (10.19.9.29) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 8 Oct 2012 07:44:20 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.162]) with mapi id
	14.01.0355.002; Mon, 8 Oct 2012 22:44:03 +0800
From: "Liu, Jinsong" 
To: "Ian.Campbell@citrix.com" , Ian Jackson
	, "xen-devel@lists.xensource.com"
	
Thread-Topic: Patch review: vMCE patches 4/5 and 5/5
Thread-Index: Ac2bqOKLxDZSgggOQfiF3hPIJjEB6gJulikg
Date: Mon, 8 Oct 2012 14:44:02 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "Liu, Jinsong" ,
	Christoph Egger ,
	"keir@xen.org" , Jan Beulich 
Subject: Re: [Xen-devel] Patch review: vMCE patches 4/5 and 5/5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ping?

Thanks,
Jinsong

Liu, Jinsong wrote:
> Hi,
> 
> Attached are 2 patches of Xen vMCE, it mainly handle vMCE when live
> migrate. 
> Patch4/5 used to handle vMCE while live migrate.
> Patch5/5 used handle vMCE before live migrate.
> 
> These 2 patches involves some tools logic, would you please kindly
> help me to review them? 
> 
> Thanks,
> Jinsong


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 14:45:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 14:45:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLEZL-0005ca-3q; Mon, 08 Oct 2012 14:44:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLEZK-0005cV-Ek
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 14:44:30 +0000
Received: from [85.158.143.99:31763] by server-2.bemta-4.messagelabs.com id
	F8/0A-06610-DC6E2705; Mon, 08 Oct 2012 14:44:29 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1349707462!26863355!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzA4Nzg3\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18308 invoked from network); 8 Oct 2012 14:44:23 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-10.tower-216.messagelabs.com with SMTP;
	8 Oct 2012 14:44:23 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 08 Oct 2012 07:44:21 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,554,1344236400"; d="scan'208";a="202964692"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by orsmga001.jf.intel.com with ESMTP; 08 Oct 2012 07:44:20 -0700
Received: from FMSMSX110.amr.corp.intel.com (10.19.9.29) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 8 Oct 2012 07:44:20 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	fmsmsx110.amr.corp.intel.com (10.19.9.29) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 8 Oct 2012 07:44:20 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.162]) with mapi id
	14.01.0355.002; Mon, 8 Oct 2012 22:44:03 +0800
From: "Liu, Jinsong" 
To: "Ian.Campbell@citrix.com" , Ian Jackson
	, "xen-devel@lists.xensource.com"
	
Thread-Topic: Patch review: vMCE patches 4/5 and 5/5
Thread-Index: Ac2bqOKLxDZSgggOQfiF3hPIJjEB6gJulikg
Date: Mon, 8 Oct 2012 14:44:02 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "Liu, Jinsong" ,
	Christoph Egger ,
	"keir@xen.org" , Jan Beulich 
Subject: Re: [Xen-devel] Patch review: vMCE patches 4/5 and 5/5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ping?

Thanks,
Jinsong

Liu, Jinsong wrote:
> Hi,
> 
> Attached are 2 patches of Xen vMCE, it mainly handle vMCE when live
> migrate. 
> Patch4/5 used to handle vMCE while live migrate.
> Patch5/5 used handle vMCE before live migrate.
> 
> These 2 patches involves some tools logic, would you please kindly
> help me to review them? 
> 
> Thanks,
> Jinsong


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 15:01:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 15:01:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLEoz-0005p5-Mo; Mon, 08 Oct 2012 15:00:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLEox-0005p0-RR
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 15:00:40 +0000
Received: from [85.158.139.211:41575] by server-16.bemta-5.messagelabs.com id
	18/B3-21637-79AE2705; Mon, 08 Oct 2012 15:00:39 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1349708432!21493699!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzA4Nzg3\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5956 invoked from network); 8 Oct 2012 15:00:35 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-3.tower-206.messagelabs.com with SMTP;
	8 Oct 2012 15:00:35 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 08 Oct 2012 08:00:31 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,554,1344236400"; d="scan'208";a="202972025"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by orsmga001.jf.intel.com with ESMTP; 08 Oct 2012 08:00:22 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 8 Oct 2012 08:00:21 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.162]) with mapi id
	14.01.0355.002; Mon, 8 Oct 2012 23:00:20 +0800
From: "Liu, Jinsong" 
To: "Ian.Campbell@citrix.com" , Ian Jackson
	, "xen-devel@lists.xensource.com"
	
Thread-Topic: Patch review: vMCE patches 4/5 and 5/5
Thread-Index: Ac2bqOKLxDZSgggOQfiF3hPIJjEB6gJulikgAAB76CA=
Date: Mon, 8 Oct 2012 15:00:19 +0000
Message-ID: 
References: 
	
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_003_DE8DF0795D48FD4CA783C40EC82923353471B5SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "Liu, Jinsong" ,
	Christoph Egger ,
	"keir@xen.org" , Jan Beulich 
Subject: Re: [Xen-devel] Patch review: vMCE patches 4/5 and 5/5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_003_DE8DF0795D48FD4CA783C40EC82923353471B5SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Sorry, forget to attach patches 4/5 and 5/5.

Thanks,
Jinsong

Liu, Jinsong wrote:
> Ping?
>=20
> Thanks,
> Jinsong
>=20
> Liu, Jinsong wrote:
>> Hi,
>>=20
>> Attached are 2 patches of Xen vMCE, it mainly handle vMCE when live
>> migrate. Patch4/5 used to handle vMCE while live migrate.
>> Patch5/5 used handle vMCE before live migrate.
>>=20
>> These 2 patches involves some tools logic, would you please kindly
>> help me to review them?=20
>>=20
>> Thanks,
>> Jinsong


--_003_DE8DF0795D48FD4CA783C40EC82923353471B5SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="4_vmce_when_migrate.patch"
Content-Description: 4_vmce_when_migrate.patch
Content-Disposition: attachment; filename="4_vmce_when_migrate.patch";
	size=7729; creation-date="Wed, 26 Sep 2012 03:09:24 GMT";
	modification-date="Wed, 19 Sep 2012 16:00:18 GMT"
Content-Transfer-Encoding: base64

WGVuL01DRTogQWJvcnQgbGl2ZSBtaWdyYXRpb24gd2hlbiB2TUNFIG9jY3VyCgpUaGlzIHBhdGNo
IG1vbml0b3IgdGhlIGNyaXRpY2FsIGFyZWEgb2YgbGl2ZSBtaWdyYXRpb24gKGZyb20gdk1DRSBw
b2ludCBvZiB2aWV3LAp0aGUgY29weXBhZ2VzIHN0YWdlIG9mIG1pZ3JhdGlvbiBpcyB0aGUgY3Jp
dGljYWwgYXJlYSB3aGlsZSBvdGhlciBhcmVhcyBhcmUgbm90KS4KCklmIGEgdk1DRSBvY2N1ciBh
dCB0aGUgY3JpdGljYWwgYXJlYSBvZiBsaXZlIG1pZ3JhdGlvbiwgYWJvcnQgYW5kIHRyeSBtaWdy
YXRpb24gbGF0ZXIuCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGlu
dGVsLmNvbT4KCmRpZmYgLXIgZTcxYzRiZGNjMDVhIHRvb2xzL2xpYnhjL3hjX2RvbWFpbi5jCi0t
LSBhL3Rvb2xzL2xpYnhjL3hjX2RvbWFpbi5jCVdlZCBTZXAgMTkgMjM6Mjc6NDAgMjAxMiArMDgw
MAorKysgYi90b29scy9saWJ4Yy94Y19kb21haW4uYwlUaHUgU2VwIDIwIDAwOjAwOjE3IDIwMTIg
KzA4MDAKQEAgLTI4Myw2ICsyODMsMzcgQEAKICAgICByZXR1cm4gcmV0OwogfQogCisvKiBTdGFy
dCB2bWNlIG1vbml0b3IgKi8KK2ludCB4Y19kb21haW5fdm1jZV9tb25pdG9yX3N0YXJ0KHhjX2lu
dGVyZmFjZSAqeGNoLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3Qg
ZG9taWQpCit7CisgICAgaW50IHJldDsKKyAgICBERUNMQVJFX0RPTUNUTDsKKworICAgIGRvbWN0
bC5jbWQgPSBYRU5fRE9NQ1RMX3ZtY2VfbW9uaXRvcl9zdGFydDsKKyAgICBkb21jdGwuZG9tYWlu
ID0gKGRvbWlkX3QpZG9taWQ7CisgICAgcmV0ID0gZG9fZG9tY3RsKHhjaCwgJmRvbWN0bCk7CisK
KyAgICByZXR1cm4gcmV0ID8gLTEgOiAwOworfQorCisvKiBFbmQgdm1jZSBtb25pdG9yICovCitp
bnQgeGNfZG9tYWluX3ZtY2VfbW9uaXRvcl9lbmQoeGNfaW50ZXJmYWNlICp4Y2gsCisgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZG9taWQsCisgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgc2lnbmVkIGNoYXIgKnZtY2Vfd2hpbGVfbW9uaXRvcikKK3sKKyAgICBp
bnQgcmV0OworICAgIERFQ0xBUkVfRE9NQ1RMOworCisgICAgZG9tY3RsLmNtZCA9IFhFTl9ET01D
VExfdm1jZV9tb25pdG9yX2VuZDsKKyAgICBkb21jdGwuZG9tYWluID0gKGRvbWlkX3QpZG9taWQ7
CisgICAgcmV0ID0gZG9fZG9tY3RsKHhjaCwgJmRvbWN0bCk7CisgICAgaWYgKCAhcmV0ICkKKyAg
ICAgICAgKnZtY2Vfd2hpbGVfbW9uaXRvciA9IGRvbWN0bC51LnZtY2VfbW9uaXRvci52bWNlX3do
aWxlX21vbml0b3I7CisKKyAgICByZXR1cm4gcmV0ID8gLTEgOiAwOworfQorCiAvKiBnZXQgaW5m
byBmcm9tIGh2bSBndWVzdCBmb3Igc2F2ZSAqLwogaW50IHhjX2RvbWFpbl9odm1fZ2V0Y29udGV4
dCh4Y19pbnRlcmZhY2UgKnhjaCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMy
X3QgZG9taWQsCmRpZmYgLXIgZTcxYzRiZGNjMDVhIHRvb2xzL2xpYnhjL3hjX2RvbWFpbl9zYXZl
LmMKLS0tIGEvdG9vbHMvbGlieGMveGNfZG9tYWluX3NhdmUuYwlXZWQgU2VwIDE5IDIzOjI3OjQw
IDIwMTIgKzA4MDAKKysrIGIvdG9vbHMvbGlieGMveGNfZG9tYWluX3NhdmUuYwlUaHUgU2VwIDIw
IDAwOjAwOjE3IDIwMTIgKzA4MDAKQEAgLTg5NSw2ICs4OTUsOCBAQAogICAgICAqLwogICAgIGlu
dCBjb21wcmVzc2luZyA9IDA7CiAKKyAgICBzaWduZWQgY2hhciB2bWNlX3doaWxlX21vbml0b3Ig
PSAwOworCiAgICAgaW50IGNvbXBsZXRlZCA9IDA7CiAKICAgICBpZiAoIGh2bSAmJiAhY2FsbGJh
Y2tzLT5zd2l0Y2hfcWVtdV9sb2dkaXJ0eSApCkBAIC0xMTA5LDYgKzExMTEsMTIgQEAKICAgICAg
ICAgZ290byBvdXQ7CiAgICAgfQogCisgICAgaWYgKCB4Y19kb21haW5fdm1jZV9tb25pdG9yX3N0
YXJ0KHhjaCwgZG9tKSApCisgICAgeworICAgICAgICBQRVJST1IoIkVycm9yIHdoZW4gc3RhcnQg
dm1jZSBtb25pdG9yXG4iKTsKKyAgICAgICAgZ290byBvdXQ7CisgICAgfQorCiAgIGNvcHlwYWdl
czoKICNkZWZpbmUgd3JleGFjdChmZCwgYnVmLCBsZW4pIHdyaXRlX2J1ZmZlcih4Y2gsIGxhc3Rf
aXRlciwgb2IsIChmZCksIChidWYpLCAobGVuKSkKICNkZWZpbmUgd3J1bmNhY2hlZChmZCwgbGl2
ZSwgYnVmLCBsZW4pIHdyaXRlX3VuY2FjaGVkKHhjaCwgbGFzdF9pdGVyLCBvYiwgKGZkKSwgKGJ1
ZiksIChsZW4pKQpAQCAtMTU3MSw2ICsxNTc5LDE3IEBACiAKICAgICBEUFJJTlRGKCJBbGwgbWVt
b3J5IGlzIHNhdmVkXG4iKTsKIAorICAgIGlmICggeGNfZG9tYWluX3ZtY2VfbW9uaXRvcl9lbmQo
eGNoLCBkb20sICZ2bWNlX3doaWxlX21vbml0b3IpICkKKyAgICB7CisgICAgICAgIFBFUlJPUigi
RXJyb3Igd2hlbiBlbmQgdm1jZSBtb25pdG9yXG4iKTsKKyAgICAgICAgZ290byBvdXQ7CisgICAg
fQorICAgIGVsc2UgaWYgKCB2bWNlX3doaWxlX21vbml0b3IgPT0gLTEgKQorICAgIHsKKyAgICAg
ICAgZnByaW50ZihzdGRlcnIsICJ2TUNFIG9jY3VycmVkLCBhYm9ydCB0aGlzIHRpbWUgYW5kIHRy
eSBsYXRlci5cbiIpOworICAgICAgICBnb3RvIG91dDsKKyAgICB9CisKICAgICAvKiBBZnRlciBs
YXN0X2l0ZXIsIGJ1ZmZlciB0aGUgcmVzdCBvZiBwYWdlYnVmICYgdGFpbGJ1ZiBkYXRhIGludG8g
YQogICAgICAqIHNlcGFyYXRlIG91dHB1dCBidWZmZXIgYW5kIGZsdXNoIGl0IGFmdGVyIHRoZSBj
b21wcmVzc2VkIHBhZ2UgY2h1bmtzLgogICAgICAqLwpkaWZmIC1yIGU3MWM0YmRjYzA1YSB0b29s
cy9saWJ4Yy94ZW5jdHJsLmgKLS0tIGEvdG9vbHMvbGlieGMveGVuY3RybC5oCVdlZCBTZXAgMTkg
MjM6Mjc6NDAgMjAxMiArMDgwMAorKysgYi90b29scy9saWJ4Yy94ZW5jdHJsLmgJVGh1IFNlcCAy
MCAwMDowMDoxNyAyMDEyICswODAwCkBAIC01NzUsNiArNTc1LDI2IEBACiAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHhjX2RvbWFpbmluZm9fdCAqaW5mbyk7CiAKIC8qKgorICogVGhpcyBmdW5j
dGlvbiBzdGFydCBtb25pdG9yIHZtY2UgZXZlbnQuCisgKiBAcGFybSB4Y2ggYSBoYW5kbGUgdG8g
YW4gb3BlbiBoeXBlcnZpc29yIGludGVyZmFjZQorICogQHBhcm0gZG9taWQgdGhlIGRvbWFpbiBp
ZCBtb25pdG9yZWQKKyAqIEByZXR1cm4gMCBvbiBzdWNjZXNzLCAtMSBvbiBmYWlsdXJlCisgKi8K
K2ludCB4Y19kb21haW5fdm1jZV9tb25pdG9yX3N0YXJ0KHhjX2ludGVyZmFjZSAqeGNoLAorICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZG9taWQpOworCisvKioKKyAq
IFRoaXMgZnVuY3Rpb24gZW5kIG1vbml0b3Igdm1jZSBldmVudAorICogQHBhcm0geGNoIGEgaGFu
ZGxlIHRvIGFuIG9wZW4gaHlwZXJ2aXNvciBpbnRlcmZhY2UKKyAqIEBwYXJtIGRvbWlkIHRoZSBk
b21haW4gaWQgbW9uaXRvcmVkCisgKiBAcGFybSB2bWNlX3doaWxlX21pZ3JhdGUgYSBwb2ludGVy
IHJldHVybiB3aGV0aGVyIHZNQ0Ugb2NjdXIgd2hlbiBtaWdyYXRlIAorICogQHJldHVybiAwIG9u
IHN1Y2Nlc3MsIC0xIG9uIGZhaWx1cmUKKyAqLworaW50IHhjX2RvbWFpbl92bWNlX21vbml0b3Jf
ZW5kKHhjX2ludGVyZmFjZSAqeGNoLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVp
bnQzMl90IGRvbWlkLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNpZ25lZCBjaGFy
ICp2bWNlX3doaWxlX21vbml0b3IpOworCisvKioKICAqIFRoaXMgZnVuY3Rpb24gcmV0dXJucyBp
bmZvcm1hdGlvbiBhYm91dCB0aGUgY29udGV4dCBvZiBhIGh2bSBkb21haW4KICAqIEBwYXJtIHhj
aCBhIGhhbmRsZSB0byBhbiBvcGVuIGh5cGVydmlzb3IgaW50ZXJmYWNlCiAgKiBAcGFybSBkb21p
ZCB0aGUgZG9tYWluIHRvIGdldCBpbmZvcm1hdGlvbiBmcm9tCmRpZmYgLXIgZTcxYzRiZGNjMDVh
IHhlbi9hcmNoL3g4Ni9jcHUvbWNoZWNrL21jZV9pbnRlbC5jCi0tLSBhL3hlbi9hcmNoL3g4Ni9j
cHUvbWNoZWNrL21jZV9pbnRlbC5jCVdlZCBTZXAgMTkgMjM6Mjc6NDAgMjAxMiArMDgwMAorKysg
Yi94ZW4vYXJjaC94ODYvY3B1L21jaGVjay9tY2VfaW50ZWwuYwlUaHUgU2VwIDIwIDAwOjAwOjE3
IDIwMTIgKzA4MDAKQEAgLTM1OCw2ICszNTgsMTIgQEAKICAgICAgICAgICAgICAgICAgICAgZ290
byB2bWNlX2ZhaWxlZDsKICAgICAgICAgICAgICAgICB9CiAKKyAgICAgICAgICAgICAgICBpZiAo
IHVubGlrZWx5KGQtPmFyY2gudm1jZV9tb25pdG9yKSApCisgICAgICAgICAgICAgICAgeworICAg
ICAgICAgICAgICAgICAgICAvKiB2TUNFIG9jY3VyIHdoZW4gZ3Vlc3QgbWlncmF0aW9uICovCisg
ICAgICAgICAgICAgICAgICAgIGQtPmFyY2gudm1jZV9tb25pdG9yID0gLTE7CisgICAgICAgICAg
ICAgICAgfQorCiAgICAgICAgICAgICAgICAgLyogV2Ugd2lsbCBpbmplY3Qgdk1DRSB0byBET01V
Ki8KICAgICAgICAgICAgICAgICBpZiAoIGluamVjdF92bWNlKGQpIDwgMCApCiAgICAgICAgICAg
ICAgICAgewpkaWZmIC1yIGU3MWM0YmRjYzA1YSB4ZW4vYXJjaC94ODYvZG9tY3RsLmMKLS0tIGEv
eGVuL2FyY2gveDg2L2RvbWN0bC5jCVdlZCBTZXAgMTkgMjM6Mjc6NDAgMjAxMiArMDgwMAorKysg
Yi94ZW4vYXJjaC94ODYvZG9tY3RsLmMJVGh1IFNlcCAyMCAwMDowMDoxNyAyMDEyICswODAwCkBA
IC0xNTE0LDYgKzE1MTQsNDAgQEAKICAgICB9CiAgICAgYnJlYWs7CiAKKyAgICBjYXNlIFhFTl9E
T01DVExfdm1jZV9tb25pdG9yX3N0YXJ0OgorICAgIHsKKyAgICAgICAgc3RydWN0IGRvbWFpbiAq
ZDsKKworICAgICAgICBkID0gcmN1X2xvY2tfZG9tYWluX2J5X2lkKGRvbWN0bC0+ZG9tYWluKTsK
KyAgICAgICAgaWYgKCBkICE9IE5VTEwgKQorICAgICAgICB7CisgICAgICAgICAgICBkLT5hcmNo
LnZtY2VfbW9uaXRvciA9IDE7CisgICAgICAgICAgICByY3VfdW5sb2NrX2RvbWFpbihkKTsKKyAg
ICAgICAgfQorICAgICAgICBlbHNlCisgICAgICAgICAgICByZXQgPSAtRVNSQ0g7CisgICAgfQor
ICAgIGJyZWFrOworCisgICAgY2FzZSBYRU5fRE9NQ1RMX3ZtY2VfbW9uaXRvcl9lbmQ6CisgICAg
eworICAgICAgICBzdHJ1Y3QgZG9tYWluICpkOworCisgICAgICAgIGQgPSByY3VfbG9ja19kb21h
aW5fYnlfaWQoZG9tY3RsLT5kb21haW4pOworICAgICAgICBpZiAoIGQgIT0gTlVMTCkKKyAgICAg
ICAgeworICAgICAgICAgICAgZG9tY3RsLT51LnZtY2VfbW9uaXRvci52bWNlX3doaWxlX21vbml0
b3IgPQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkLT5hcmNoLnZtY2Vf
bW9uaXRvcjsKKyAgICAgICAgICAgIGQtPmFyY2gudm1jZV9tb25pdG9yID0gMDsKKyAgICAgICAg
ICAgIHJjdV91bmxvY2tfZG9tYWluKGQpOworICAgICAgICAgICAgaWYgKCBjb3B5X3RvX2d1ZXN0
KHVfZG9tY3RsLCBkb21jdGwsIDEpICkKKyAgICAgICAgICAgICAgICByZXQgPSAtRUZBVUxUOwor
ICAgICAgICB9CisgICAgICAgIGVsc2UKKyAgICAgICAgICAgIHJldCA9IC1FU1JDSDsKKyAgICB9
CisgICAgYnJlYWs7CisKICAgICBkZWZhdWx0OgogICAgICAgICByZXQgPSBpb21tdV9kb19kb21j
dGwoZG9tY3RsLCB1X2RvbWN0bCk7CiAgICAgICAgIGJyZWFrOwpkaWZmIC1yIGU3MWM0YmRjYzA1
YSB4ZW4vaW5jbHVkZS9hc20teDg2L2RvbWFpbi5oCi0tLSBhL3hlbi9pbmNsdWRlL2FzbS14ODYv
ZG9tYWluLmgJV2VkIFNlcCAxOSAyMzoyNzo0MCAyMDEyICswODAwCisrKyBiL3hlbi9pbmNsdWRl
L2FzbS14ODYvZG9tYWluLmgJVGh1IFNlcCAyMCAwMDowMDoxNyAyMDEyICswODAwCkBAIC0yNzks
NiArMjc5LDExIEBACiAgICAgYm9vbF90IGhhc18zMmJpdF9zaGluZm87CiAgICAgLyogRG9tYWlu
IGNhbm5vdCBoYW5kbGUgc3B1cmlvdXMgcGFnZSBmYXVsdHM/ICovCiAgICAgYm9vbF90IHN1cHBy
ZXNzX3NwdXJpb3VzX3BhZ2VfZmF1bHRzOworICAgIC8qIE1vbml0b3JpbmcgZ3Vlc3QgbWVtb3J5
IGNvcHkgb2YgbWlncmF0aW9uCisgICAgICogPSAwIC0gbm90IG1vbml0b3JpbmcKKyAgICAgKiA+
IDAgLSBtb25pdG9yaW5nCisgICAgICogPCAwIC0gdk1DRSBvY2N1cnJlZCB3aGlsZSBtb25pdG9y
aW5nICovCisgICAgczggdm1jZV9tb25pdG9yOwogCiAgICAgLyogQ29udGludWFibGUgZG9tYWlu
X3JlbGlucXVpc2hfcmVzb3VyY2VzKCkuICovCiAgICAgZW51bSB7CmRpZmYgLXIgZTcxYzRiZGNj
MDVhIHhlbi9pbmNsdWRlL3B1YmxpYy9kb21jdGwuaAotLS0gYS94ZW4vaW5jbHVkZS9wdWJsaWMv
ZG9tY3RsLmgJV2VkIFNlcCAxOSAyMzoyNzo0MCAyMDEyICswODAwCisrKyBiL3hlbi9pbmNsdWRl
L3B1YmxpYy9kb21jdGwuaAlUaHUgU2VwIDIwIDAwOjAwOjE3IDIwMTIgKzA4MDAKQEAgLTgyOCw2
ICs4MjgsMTIgQEAKIHR5cGVkZWYgc3RydWN0IHhlbl9kb21jdGxfc2V0X2FjY2Vzc19yZXF1aXJl
ZCB4ZW5fZG9tY3RsX3NldF9hY2Nlc3NfcmVxdWlyZWRfdDsKIERFRklORV9YRU5fR1VFU1RfSEFO
RExFKHhlbl9kb21jdGxfc2V0X2FjY2Vzc19yZXF1aXJlZF90KTsKIAorc3RydWN0IHhlbl9kb21j
dGxfdm1jZV9tb25pdG9yIHsKKyAgICBzaWduZWQgY2hhciB2bWNlX3doaWxlX21vbml0b3I7Cit9
OwordHlwZWRlZiBzdHJ1Y3QgeGVuX2RvbWN0bF92bWNlX21vbml0b3IgeGVuX2RvbWN0bF92bWNl
X21vbml0b3JfdDsKK0RFRklORV9YRU5fR1VFU1RfSEFORExFKHhlbl9kb21jdGxfdm1jZV9tb25p
dG9yX3QpOworCiBzdHJ1Y3QgeGVuX2RvbWN0bCB7CiAgICAgdWludDMyX3QgY21kOwogI2RlZmlu
ZSBYRU5fRE9NQ1RMX2NyZWF0ZWRvbWFpbiAgICAgICAgICAgICAgICAgICAxCkBAIC04OTMsNiAr
ODk5LDggQEAKICNkZWZpbmUgWEVOX0RPTUNUTF9zZXRfYWNjZXNzX3JlcXVpcmVkICAgICAgICAg
ICA2NAogI2RlZmluZSBYRU5fRE9NQ1RMX2F1ZGl0X3AybSAgICAgICAgICAgICAgICAgICAgIDY1
CiAjZGVmaW5lIFhFTl9ET01DVExfc2V0X3ZpcnFfaGFuZGxlciAgICAgICAgICAgICAgNjYKKyNk
ZWZpbmUgWEVOX0RPTUNUTF92bWNlX21vbml0b3Jfc3RhcnQgICAgICAgICAgICA2NworI2RlZmlu
ZSBYRU5fRE9NQ1RMX3ZtY2VfbW9uaXRvcl9lbmQgICAgICAgICAgICAgIDY4CiAjZGVmaW5lIFhF
Tl9ET01DVExfZ2Ric3hfZ3Vlc3RtZW1pbyAgICAgICAgICAgIDEwMDAKICNkZWZpbmUgWEVOX0RP
TUNUTF9nZGJzeF9wYXVzZXZjcHUgICAgICAgICAgICAgMTAwMQogI2RlZmluZSBYRU5fRE9NQ1RM
X2dkYnN4X3VucGF1c2V2Y3B1ICAgICAgICAgICAxMDAyCkBAIC05NDcsNiArOTU1LDcgQEAKICAg
ICAgICAgc3RydWN0IHhlbl9kb21jdGxfc2V0X2FjY2Vzc19yZXF1aXJlZCBhY2Nlc3NfcmVxdWly
ZWQ7CiAgICAgICAgIHN0cnVjdCB4ZW5fZG9tY3RsX2F1ZGl0X3AybSAgICAgICAgIGF1ZGl0X3Ay
bTsKICAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfc2V0X3ZpcnFfaGFuZGxlciAgc2V0X3ZpcnFf
aGFuZGxlcjsKKyAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfdm1jZV9tb25pdG9yICAgICAgdm1j
ZV9tb25pdG9yOwogICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF9nZGJzeF9tZW1pbyAgICAgICBn
ZGJzeF9ndWVzdF9tZW1pbzsKICAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfZ2Ric3hfcGF1c2V1
bnBfdmNwdSBnZGJzeF9wYXVzZXVucF92Y3B1OwogICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF9n
ZGJzeF9kb21zdGF0dXMgICBnZGJzeF9kb21zdGF0dXM7Cg==

--_003_DE8DF0795D48FD4CA783C40EC82923353471B5SHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="5_vmce_migration_pfntype_broken.patch"
Content-Description: 5_vmce_migration_pfntype_broken.patch
Content-Disposition: attachment;
	filename="5_vmce_migration_pfntype_broken.patch"; size=8499;
	creation-date="Wed, 26 Sep 2012 03:09:24 GMT";
	modification-date="Wed, 19 Sep 2012 15:27:52 GMT"
Content-Transfer-Encoding: base64

WDg2L3ZNQ0U6IGd1ZXN0IGJyb2tlbiBwYWdlIGhhbmRsaW5nIHdoZW4gbWlncmF0aW9uCgpUaGlz
IHBhdGNoIGlzIHVzZWQgdG8gaGFuZGxlIGd1ZXN0IGJyb2tlbiBwYWdlIHdoZW4gbWlncmF0aW9u
LgoKQXQgc2VuZGVyLCB0aGUgYnJva2VuIHBhZ2Ugd291bGQgbm90IGJlIG1hcHBlZCwgYW5kIHRo
ZSBlcnJvciBwYWdlCmNvbnRlbnQgd291bGQgbm90IGJlIGNvcGllZCB0byB0YXJnZXQsIG90aGVy
d2lzZSBpdCBtYXkgdHJpZ2dlciBtb3JlCnNlcmlvdXMgZXJyb3IgKGkuZS4gU1JBUiBlcnJvciku
IFdoaWxlIGl0cyBwZm5fdHlwZSBhbmQgcGZuIG51bWJlcgp3b3VsZCBiZSB0cmFuc2ZlcnJlZCB0
byB0YXJnZXQgc28gdGhhdCB0YXJnZXQgdGFrZSBhcHByb3ByaWF0ZSBhY3Rpb24uCgpBdCB0YXJn
ZXQsIGl0IHdvdWxkIHNldCBwMm0gYXMgcDJtX3JhbV9icm9rZW4gZm9yIGJyb2tlbiBwYWdlLCBz
byB0aGF0CmlmIGd1ZXN0IGFjY2VzcyB0aGUgYnJva2VuIHBhZ2UgYWdhaW4sIGl0IHdvdWxkIGtp
bGwgZ3Vlc3QgYXMgZXhwZWN0ZWQuCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNv
bmcubGl1QGludGVsLmNvbT4KCmRpZmYgLXIgYTFkMTA2ZDFhZWM4IHRvb2xzL2xpYnhjL3hjX2Rv
bWFpbi5jCi0tLSBhL3Rvb2xzL2xpYnhjL3hjX2RvbWFpbi5jCVdlZCBTZXAgMTkgMDM6MzE6MzEg
MjAxMiArMDgwMAorKysgYi90b29scy9saWJ4Yy94Y19kb21haW4uYwlXZWQgU2VwIDE5IDA0OjIy
OjI2IDIwMTIgKzA4MDAKQEAgLTMxNCw2ICszMTQsMjIgQEAKICAgICByZXR1cm4gcmV0ID8gLTEg
OiAwOwogfQogCisvKiBzZXQgYnJva2VuIHBhZ2UgcDJtICovCitpbnQgeGNfc2V0X2Jyb2tlbl9w
YWdlX3AybSh4Y19pbnRlcmZhY2UgKnhjaCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgIHVp
bnQzMl90IGRvbWlkLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgdW5zaWduZWQgbG9uZyBw
Zm4pCit7CisgICAgaW50IHJldDsKKyAgICBERUNMQVJFX0RPTUNUTDsKKworICAgIGRvbWN0bC5j
bWQgPSBYRU5fRE9NQ1RMX3NldF9icm9rZW5fcGFnZV9wMm07CisgICAgZG9tY3RsLmRvbWFpbiA9
IChkb21pZF90KWRvbWlkOworICAgIGRvbWN0bC51LnNldF9icm9rZW5fcGFnZV9wMm0ucGZuID0g
cGZuOworICAgIHJldCA9IGRvX2RvbWN0bCh4Y2gsICZkb21jdGwpOworCisgICAgcmV0dXJuIHJl
dCA/IC0xIDogMDsKK30KKwogLyogZ2V0IGluZm8gZnJvbSBodm0gZ3Vlc3QgZm9yIHNhdmUgKi8K
IGludCB4Y19kb21haW5faHZtX2dldGNvbnRleHQoeGNfaW50ZXJmYWNlICp4Y2gsCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IGRvbWlkLApkaWZmIC1yIGExZDEwNmQxYWVj
OCB0b29scy9saWJ4Yy94Y19kb21haW5fcmVzdG9yZS5jCi0tLSBhL3Rvb2xzL2xpYnhjL3hjX2Rv
bWFpbl9yZXN0b3JlLmMJV2VkIFNlcCAxOSAwMzozMTozMSAyMDEyICswODAwCisrKyBiL3Rvb2xz
L2xpYnhjL3hjX2RvbWFpbl9yZXN0b3JlLmMJV2VkIFNlcCAxOSAwNDoyMjoyNiAyMDEyICswODAw
CkBAIC05NjIsOSArOTYyLDE1IEBACiAKICAgICBjb3VudHBhZ2VzID0gY291bnQ7CiAgICAgZm9y
IChpID0gb2xkY291bnQ7IGkgPCBidWYtPm5yX3BhZ2VzOyArK2kpCi0gICAgICAgIGlmICgoYnVm
LT5wZm5fdHlwZXNbaV0gJiBYRU5fRE9NQ1RMX1BGSU5GT19MVEFCX01BU0spID09IFhFTl9ET01D
VExfUEZJTkZPX1hUQUIKLSAgICAgICAgICAgIHx8KGJ1Zi0+cGZuX3R5cGVzW2ldICYgWEVOX0RP
TUNUTF9QRklORk9fTFRBQl9NQVNLKSA9PSBYRU5fRE9NQ1RMX1BGSU5GT19YQUxMT0MpCisgICAg
eworICAgICAgICB1bnNpZ25lZCBsb25nIHBhZ2V0eXBlOworCisgICAgICAgIHBhZ2V0eXBlID0g
YnVmLT5wZm5fdHlwZXNbaV0gJiBYRU5fRE9NQ1RMX1BGSU5GT19MVEFCX01BU0s7CisgICAgICAg
IGlmICggcGFnZXR5cGUgPT0gWEVOX0RPTUNUTF9QRklORk9fWFRBQiB8fAorICAgICAgICAgICAg
IHBhZ2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX0JST0tFTiB8fAorICAgICAgICAgICAgIHBh
Z2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX1hBTExPQyApCiAgICAgICAgICAgICAtLWNvdW50
cGFnZXM7CisgICAgfQogCiAgICAgaWYgKCFjb3VudHBhZ2VzKQogICAgICAgICByZXR1cm4gY291
bnQ7CkBAIC0xMjAwLDYgKzEyMDYsMTcgQEAKICAgICAgICAgICAgIC8qIGEgYm9ndXMvdW5tYXBw
ZWQvYWxsb2NhdGUtb25seSBwYWdlOiBza2lwIGl0ICovCiAgICAgICAgICAgICBjb250aW51ZTsK
IAorICAgICAgICBpZiAoIHBhZ2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX0JST0tFTiApCisg
ICAgICAgIHsKKyAgICAgICAgICAgIGlmICggeGNfc2V0X2Jyb2tlbl9wYWdlX3AybSh4Y2gsIGRv
bSwgcGZuKSApCisgICAgICAgICAgICB7CisgICAgICAgICAgICAgICAgRVJST1IoIlNldCBwMm0g
Zm9yIGJyb2tlbiBwYWdlIGZhaWwsICIKKyAgICAgICAgICAgICAgICAgICAgICAiZG9tPSVkLCBw
Zm49JWx4XG4iLCBkb20sIHBmbik7CisgICAgICAgICAgICAgICAgZ290byBlcnJfbWFwcGVkOwor
ICAgICAgICAgICAgfQorICAgICAgICAgICAgY29udGludWU7CisgICAgICAgIH0KKwogICAgICAg
ICBpZiAocGZuX2VycltpXSkKICAgICAgICAgewogICAgICAgICAgICAgRVJST1IoInVuZXhwZWN0
ZWQgUEZOIG1hcHBpbmcgZmFpbHVyZSBwZm4gJWx4IG1hcF9tZm4gJWx4IHAybV9tZm4gJWx4IiwK
ZGlmZiAtciBhMWQxMDZkMWFlYzggdG9vbHMvbGlieGMveGNfZG9tYWluX3NhdmUuYwotLS0gYS90
b29scy9saWJ4Yy94Y19kb21haW5fc2F2ZS5jCVdlZCBTZXAgMTkgMDM6MzE6MzEgMjAxMiArMDgw
MAorKysgYi90b29scy9saWJ4Yy94Y19kb21haW5fc2F2ZS5jCVdlZCBTZXAgMTkgMDQ6MjI6MjYg
MjAxMiArMDgwMApAQCAtMTI4NSw2ICsxMjg1LDEzIEBACiAgICAgICAgICAgICAgICAgaWYgKCAh
aHZtICkKICAgICAgICAgICAgICAgICAgICAgZ21mbiA9IHBmbl90b19tZm4oZ21mbik7CiAKKyAg
ICAgICAgICAgICAgICBpZiAoIHBmbl90eXBlW2pdID09IFhFTl9ET01DVExfUEZJTkZPX0JST0tF
TiApCisgICAgICAgICAgICAgICAgeworICAgICAgICAgICAgICAgICAgICBwZm5fdHlwZVtqXSB8
PSBwZm5fYmF0Y2hbal07CisgICAgICAgICAgICAgICAgICAgICsrcnVuOworICAgICAgICAgICAg
ICAgICAgICBjb250aW51ZTsKKyAgICAgICAgICAgICAgICB9CisKICAgICAgICAgICAgICAgICBp
ZiAoIHBmbl9lcnJbal0gKQogICAgICAgICAgICAgICAgIHsKICAgICAgICAgICAgICAgICAgICAg
aWYgKCBwZm5fdHlwZVtqXSA9PSBYRU5fRE9NQ1RMX1BGSU5GT19YVEFCICkKQEAgLTEzNzksOCAr
MTM4NiwxMiBAQAogICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAgfQogCi0g
ICAgICAgICAgICAgICAgLyogc2tpcCBwYWdlcyB0aGF0IGFyZW4ndCBwcmVzZW50IG9yIGFyZSBh
bGxvYy1vbmx5ICovCisgICAgICAgICAgICAgICAgLyoKKyAgICAgICAgICAgICAgICAgKiBza2lw
IHBhZ2VzIHRoYXQgYXJlbid0IHByZXNlbnQsCisgICAgICAgICAgICAgICAgICogb3IgYXJlIGJy
b2tlbiwgb3IgYXJlIGFsbG9jLW9ubHkKKyAgICAgICAgICAgICAgICAgKi8KICAgICAgICAgICAg
ICAgICBpZiAoIHBhZ2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX1hUQUIKKyAgICAgICAgICAg
ICAgICAgICAgfHwgcGFnZXR5cGUgPT0gWEVOX0RPTUNUTF9QRklORk9fQlJPS0VOCiAgICAgICAg
ICAgICAgICAgICAgIHx8IHBhZ2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX1hBTExPQyApCiAg
ICAgICAgICAgICAgICAgICAgIGNvbnRpbnVlOwogCmRpZmYgLXIgYTFkMTA2ZDFhZWM4IHRvb2xz
L2xpYnhjL3hlbmN0cmwuaAotLS0gYS90b29scy9saWJ4Yy94ZW5jdHJsLmgJV2VkIFNlcCAxOSAw
MzozMTozMSAyMDEyICswODAwCisrKyBiL3Rvb2xzL2xpYnhjL3hlbmN0cmwuaAlXZWQgU2VwIDE5
IDA0OjIyOjI2IDIwMTIgKzA4MDAKQEAgLTU5MSw2ICs1OTEsMTcgQEAKICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBzaWduZWQgY2hhciAqdm1jZV93aGlsZV9tb25pdG9yKTsKIAogLyoq
CisgKiBUaGlzIGZ1bmN0aW9uIHNldCBwMm0gZm9yIGJyb2tlbiBwYWdlCisgKiAmcGFybSB4Y2gg
YSBoYW5kbGUgdG8gYW4gb3BlbiBoeXBlcnZpc29yIGludGVyZmFjZQorICogQHBhcm0gZG9taWQg
dGhlIGRvbWFpbiBpZCB3aGljaCBicm9rZW4gcGFnZSBiZWxvbmcgdG8KKyAqIEBwYXJtIHBmbiB0
aGUgcGZuIG51bWJlciBvZiB0aGUgYnJva2VuIHBhZ2UKKyAqIEByZXR1cm4gMCBvbiBzdWNjZXNz
LCAtMSBvbiBmYWlsdXJlCisgKi8KK2ludCB4Y19zZXRfYnJva2VuX3BhZ2VfcDJtKHhjX2ludGVy
ZmFjZSAqeGNoLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZG9taWQsCisg
ICAgICAgICAgICAgICAgICAgICAgICAgICB1bnNpZ25lZCBsb25nIHBmbik7CisKKy8qKgogICog
VGhpcyBmdW5jdGlvbiByZXR1cm5zIGluZm9ybWF0aW9uIGFib3V0IHRoZSBjb250ZXh0IG9mIGEg
aHZtIGRvbWFpbgogICogQHBhcm0geGNoIGEgaGFuZGxlIHRvIGFuIG9wZW4gaHlwZXJ2aXNvciBp
bnRlcmZhY2UKICAqIEBwYXJtIGRvbWlkIHRoZSBkb21haW4gdG8gZ2V0IGluZm9ybWF0aW9uIGZy
b20KZGlmZiAtciBhMWQxMDZkMWFlYzggeGVuL2FyY2gveDg2L2RvbWN0bC5jCi0tLSBhL3hlbi9h
cmNoL3g4Ni9kb21jdGwuYwlXZWQgU2VwIDE5IDAzOjMxOjMxIDIwMTIgKzA4MDAKKysrIGIveGVu
L2FyY2gveDg2L2RvbWN0bC5jCVdlZCBTZXAgMTkgMDQ6MjI6MjYgMjAxMiArMDgwMApAQCAtMjA5
LDEyICsyMDksMTggQEAKICAgICAgICAgICAgICAgICBmb3IgKCBqID0gMDsgaiA8IGs7IGorKyAp
CiAgICAgICAgICAgICAgICAgewogICAgICAgICAgICAgICAgICAgICB1bnNpZ25lZCBsb25nIHR5
cGUgPSAwOworICAgICAgICAgICAgICAgICAgICBwMm1fdHlwZV90IHQ7CiAKLSAgICAgICAgICAg
ICAgICAgICAgcGFnZSA9IGdldF9wYWdlX2Zyb21fZ2ZuKGQsIGFycltqXSwgTlVMTCwgUDJNX0FM
TE9DKTsKKyAgICAgICAgICAgICAgICAgICAgcGFnZSA9IGdldF9wYWdlX2Zyb21fZ2ZuKGQsIGFy
cltqXSwgJnQsIFAyTV9BTExPQyk7CiAKICAgICAgICAgICAgICAgICAgICAgaWYgKCB1bmxpa2Vs
eSghcGFnZSkgfHwKICAgICAgICAgICAgICAgICAgICAgICAgICB1bmxpa2VseShpc194ZW5faGVh
cF9wYWdlKHBhZ2UpKSApCi0gICAgICAgICAgICAgICAgICAgICAgICB0eXBlID0gWEVOX0RPTUNU
TF9QRklORk9fWFRBQjsKKyAgICAgICAgICAgICAgICAgICAgeworICAgICAgICAgICAgICAgICAg
ICAgICAgaWYgKCBwMm1faXNfYnJva2VuKHQpICkKKyAgICAgICAgICAgICAgICAgICAgICAgICAg
ICB0eXBlID0gWEVOX0RPTUNUTF9QRklORk9fQlJPS0VOOworICAgICAgICAgICAgICAgICAgICAg
ICAgZWxzZQorICAgICAgICAgICAgICAgICAgICAgICAgICAgIHR5cGUgPSBYRU5fRE9NQ1RMX1BG
SU5GT19YVEFCOworICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAgICAgIGVs
c2UKICAgICAgICAgICAgICAgICAgICAgewogICAgICAgICAgICAgICAgICAgICAgICAgc3dpdGNo
KCBwYWdlLT51LmludXNlLnR5cGVfaW5mbyAmIFBHVF90eXBlX21hc2sgKQpAQCAtMjM1LDYgKzI0
MSw5IEBACiAKICAgICAgICAgICAgICAgICAgICAgICAgIGlmICggcGFnZS0+dS5pbnVzZS50eXBl
X2luZm8gJiBQR1RfcGlubmVkICkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0eXBlIHw9
IFhFTl9ET01DVExfUEZJTkZPX0xQSU5UQUI7CisKKyAgICAgICAgICAgICAgICAgICAgICAgIGlm
ICggcGFnZS0+Y291bnRfaW5mbyAmIFBHQ19icm9rZW4gKQorICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHR5cGUgPSBYRU5fRE9NQ1RMX1BGSU5GT19CUk9LRU47CiAgICAgICAgICAgICAgICAg
ICAgIH0KIAogICAgICAgICAgICAgICAgICAgICBpZiAoIHBhZ2UgKQpAQCAtMTU0OCw2ICsxNTU3
LDI4IEBACiAgICAgfQogICAgIGJyZWFrOwogCisgICAgY2FzZSBYRU5fRE9NQ1RMX3NldF9icm9r
ZW5fcGFnZV9wMm06CisgICAgeworICAgICAgICBzdHJ1Y3QgZG9tYWluICpkOworICAgICAgICBw
Mm1fdHlwZV90IHB0OworICAgICAgICB1bnNpZ25lZCBsb25nIHBmbjsKKworICAgICAgICBkID0g
cmN1X2xvY2tfZG9tYWluX2J5X2lkKGRvbWN0bC0+ZG9tYWluKTsKKyAgICAgICAgaWYgKCBkICE9
IE5VTEwgKQorICAgICAgICB7CisgICAgICAgICAgICBwZm4gPSBkb21jdGwtPnUuc2V0X2Jyb2tl
bl9wYWdlX3AybS5wZm47CisKKyAgICAgICAgICAgIGdldF9nZm5fcXVlcnkoZCwgcGZuLCAmcHQp
OworICAgICAgICAgICAgcDJtX2NoYW5nZV90eXBlKGQsIHBmbiwgcHQsIHAybV9yYW1fYnJva2Vu
KTsKKyAgICAgICAgICAgIHB1dF9nZm4oZCwgcGZuKTsKKworICAgICAgICAgICAgcmN1X3VubG9j
a19kb21haW4oZCk7CisgICAgICAgIH0KKyAgICAgICAgZWxzZQorICAgICAgICAgICAgcmV0ID0g
LUVTUkNIOworICAgIH0KKyAgICBicmVhazsKKwogICAgIGRlZmF1bHQ6CiAgICAgICAgIHJldCA9
IGlvbW11X2RvX2RvbWN0bChkb21jdGwsIHVfZG9tY3RsKTsKICAgICAgICAgYnJlYWs7CmRpZmYg
LXIgYTFkMTA2ZDFhZWM4IHhlbi9pbmNsdWRlL3B1YmxpYy9kb21jdGwuaAotLS0gYS94ZW4vaW5j
bHVkZS9wdWJsaWMvZG9tY3RsLmgJV2VkIFNlcCAxOSAwMzozMTozMSAyMDEyICswODAwCisrKyBi
L3hlbi9pbmNsdWRlL3B1YmxpYy9kb21jdGwuaAlXZWQgU2VwIDE5IDA0OjIyOjI2IDIwMTIgKzA4
MDAKQEAgLTEzNiw2ICsxMzYsNyBAQAogI2RlZmluZSBYRU5fRE9NQ1RMX1BGSU5GT19MUElOVEFC
ICgweDFVPDwzMSkKICNkZWZpbmUgWEVOX0RPTUNUTF9QRklORk9fWFRBQiAgICAoMHhmVTw8Mjgp
IC8qIGludmFsaWQgcGFnZSAqLwogI2RlZmluZSBYRU5fRE9NQ1RMX1BGSU5GT19YQUxMT0MgICgw
eGVVPDwyOCkgLyogYWxsb2NhdGUtb25seSBwYWdlICovCisjZGVmaW5lIFhFTl9ET01DVExfUEZJ
TkZPX0JST0tFTiAgKDB4ZFU8PDI4KSAvKiBicm9rZW4gcGFnZSAqLwogI2RlZmluZSBYRU5fRE9N
Q1RMX1BGSU5GT19QQUdFRFRBQiAoMHg4VTw8MjgpCiAjZGVmaW5lIFhFTl9ET01DVExfUEZJTkZP
X0xUQUJfTUFTSyAoMHhmVTw8MjgpCiAKQEAgLTgzNCw2ICs4MzUsMTIgQEAKIHR5cGVkZWYgc3Ry
dWN0IHhlbl9kb21jdGxfdm1jZV9tb25pdG9yIHhlbl9kb21jdGxfdm1jZV9tb25pdG9yX3Q7CiBE
RUZJTkVfWEVOX0dVRVNUX0hBTkRMRSh4ZW5fZG9tY3RsX3ZtY2VfbW9uaXRvcl90KTsKIAorc3Ry
dWN0IHhlbl9kb21jdGxfc2V0X2Jyb2tlbl9wYWdlX3AybSB7CisgICAgdWludDY0X3QgcGZuOwor
fTsKK3R5cGVkZWYgc3RydWN0IHhlbl9kb21jdGxfc2V0X2Jyb2tlbl9wYWdlX3AybSB4ZW5fZG9t
Y3RsX3NldF9icm9rZW5fcGFnZV9wMm1fdDsKK0RFRklORV9YRU5fR1VFU1RfSEFORExFKHhlbl9k
b21jdGxfc2V0X2Jyb2tlbl9wYWdlX3AybV90KTsKKwogc3RydWN0IHhlbl9kb21jdGwgewogICAg
IHVpbnQzMl90IGNtZDsKICNkZWZpbmUgWEVOX0RPTUNUTF9jcmVhdGVkb21haW4gICAgICAgICAg
ICAgICAgICAgMQpAQCAtOTAxLDYgKzkwOCw3IEBACiAjZGVmaW5lIFhFTl9ET01DVExfc2V0X3Zp
cnFfaGFuZGxlciAgICAgICAgICAgICAgNjYKICNkZWZpbmUgWEVOX0RPTUNUTF92bWNlX21vbml0
b3Jfc3RhcnQgICAgICAgICAgICA2NwogI2RlZmluZSBYRU5fRE9NQ1RMX3ZtY2VfbW9uaXRvcl9l
bmQgICAgICAgICAgICAgIDY4CisjZGVmaW5lIFhFTl9ET01DVExfc2V0X2Jyb2tlbl9wYWdlX3Ay
bSAgICAgICAgICAgNjkKICNkZWZpbmUgWEVOX0RPTUNUTF9nZGJzeF9ndWVzdG1lbWlvICAgICAg
ICAgICAgMTAwMAogI2RlZmluZSBYRU5fRE9NQ1RMX2dkYnN4X3BhdXNldmNwdSAgICAgICAgICAg
ICAxMDAxCiAjZGVmaW5lIFhFTl9ET01DVExfZ2Ric3hfdW5wYXVzZXZjcHUgICAgICAgICAgIDEw
MDIKQEAgLTk1Nyw2ICs5NjUsNyBAQAogICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF9zZXRfdmly
cV9oYW5kbGVyICBzZXRfdmlycV9oYW5kbGVyOwogICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF92
bWNlX21vbml0b3IgICAgICB2bWNlX21vbml0b3I7CiAgICAgICAgIHN0cnVjdCB4ZW5fZG9tY3Rs
X2dkYnN4X21lbWlvICAgICAgIGdkYnN4X2d1ZXN0X21lbWlvOworICAgICAgICBzdHJ1Y3QgeGVu
X2RvbWN0bF9zZXRfYnJva2VuX3BhZ2VfcDJtIHNldF9icm9rZW5fcGFnZV9wMm07CiAgICAgICAg
IHN0cnVjdCB4ZW5fZG9tY3RsX2dkYnN4X3BhdXNldW5wX3ZjcHUgZ2Ric3hfcGF1c2V1bnBfdmNw
dTsKICAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfZ2Ric3hfZG9tc3RhdHVzICAgZ2Ric3hfZG9t
c3RhdHVzOwogICAgICAgICB1aW50OF90ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwYWRb
MTI4XTsK

--_003_DE8DF0795D48FD4CA783C40EC82923353471B5SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_003_DE8DF0795D48FD4CA783C40EC82923353471B5SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Mon Oct 08 15:01:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 15:01:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLEoz-0005p5-Mo; Mon, 08 Oct 2012 15:00:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLEox-0005p0-RR
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 15:00:40 +0000
Received: from [85.158.139.211:41575] by server-16.bemta-5.messagelabs.com id
	18/B3-21637-79AE2705; Mon, 08 Oct 2012 15:00:39 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1349708432!21493699!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzA4Nzg3\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5956 invoked from network); 8 Oct 2012 15:00:35 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-3.tower-206.messagelabs.com with SMTP;
	8 Oct 2012 15:00:35 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 08 Oct 2012 08:00:31 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,554,1344236400"; d="scan'208";a="202972025"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by orsmga001.jf.intel.com with ESMTP; 08 Oct 2012 08:00:22 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 8 Oct 2012 08:00:21 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.162]) with mapi id
	14.01.0355.002; Mon, 8 Oct 2012 23:00:20 +0800
From: "Liu, Jinsong" 
To: "Ian.Campbell@citrix.com" , Ian Jackson
	, "xen-devel@lists.xensource.com"
	
Thread-Topic: Patch review: vMCE patches 4/5 and 5/5
Thread-Index: Ac2bqOKLxDZSgggOQfiF3hPIJjEB6gJulikgAAB76CA=
Date: Mon, 8 Oct 2012 15:00:19 +0000
Message-ID: 
References: 
	
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_003_DE8DF0795D48FD4CA783C40EC82923353471B5SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "Liu, Jinsong" ,
	Christoph Egger ,
	"keir@xen.org" , Jan Beulich 
Subject: Re: [Xen-devel] Patch review: vMCE patches 4/5 and 5/5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_003_DE8DF0795D48FD4CA783C40EC82923353471B5SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Sorry, forget to attach patches 4/5 and 5/5.

Thanks,
Jinsong

Liu, Jinsong wrote:
> Ping?
>=20
> Thanks,
> Jinsong
>=20
> Liu, Jinsong wrote:
>> Hi,
>>=20
>> Attached are 2 patches of Xen vMCE, it mainly handle vMCE when live
>> migrate. Patch4/5 used to handle vMCE while live migrate.
>> Patch5/5 used handle vMCE before live migrate.
>>=20
>> These 2 patches involves some tools logic, would you please kindly
>> help me to review them?=20
>>=20
>> Thanks,
>> Jinsong


--_003_DE8DF0795D48FD4CA783C40EC82923353471B5SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="4_vmce_when_migrate.patch"
Content-Description: 4_vmce_when_migrate.patch
Content-Disposition: attachment; filename="4_vmce_when_migrate.patch";
	size=7729; creation-date="Wed, 26 Sep 2012 03:09:24 GMT";
	modification-date="Wed, 19 Sep 2012 16:00:18 GMT"
Content-Transfer-Encoding: base64

WGVuL01DRTogQWJvcnQgbGl2ZSBtaWdyYXRpb24gd2hlbiB2TUNFIG9jY3VyCgpUaGlzIHBhdGNo
IG1vbml0b3IgdGhlIGNyaXRpY2FsIGFyZWEgb2YgbGl2ZSBtaWdyYXRpb24gKGZyb20gdk1DRSBw
b2ludCBvZiB2aWV3LAp0aGUgY29weXBhZ2VzIHN0YWdlIG9mIG1pZ3JhdGlvbiBpcyB0aGUgY3Jp
dGljYWwgYXJlYSB3aGlsZSBvdGhlciBhcmVhcyBhcmUgbm90KS4KCklmIGEgdk1DRSBvY2N1ciBh
dCB0aGUgY3JpdGljYWwgYXJlYSBvZiBsaXZlIG1pZ3JhdGlvbiwgYWJvcnQgYW5kIHRyeSBtaWdy
YXRpb24gbGF0ZXIuCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGlu
dGVsLmNvbT4KCmRpZmYgLXIgZTcxYzRiZGNjMDVhIHRvb2xzL2xpYnhjL3hjX2RvbWFpbi5jCi0t
LSBhL3Rvb2xzL2xpYnhjL3hjX2RvbWFpbi5jCVdlZCBTZXAgMTkgMjM6Mjc6NDAgMjAxMiArMDgw
MAorKysgYi90b29scy9saWJ4Yy94Y19kb21haW4uYwlUaHUgU2VwIDIwIDAwOjAwOjE3IDIwMTIg
KzA4MDAKQEAgLTI4Myw2ICsyODMsMzcgQEAKICAgICByZXR1cm4gcmV0OwogfQogCisvKiBTdGFy
dCB2bWNlIG1vbml0b3IgKi8KK2ludCB4Y19kb21haW5fdm1jZV9tb25pdG9yX3N0YXJ0KHhjX2lu
dGVyZmFjZSAqeGNoLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3Qg
ZG9taWQpCit7CisgICAgaW50IHJldDsKKyAgICBERUNMQVJFX0RPTUNUTDsKKworICAgIGRvbWN0
bC5jbWQgPSBYRU5fRE9NQ1RMX3ZtY2VfbW9uaXRvcl9zdGFydDsKKyAgICBkb21jdGwuZG9tYWlu
ID0gKGRvbWlkX3QpZG9taWQ7CisgICAgcmV0ID0gZG9fZG9tY3RsKHhjaCwgJmRvbWN0bCk7CisK
KyAgICByZXR1cm4gcmV0ID8gLTEgOiAwOworfQorCisvKiBFbmQgdm1jZSBtb25pdG9yICovCitp
bnQgeGNfZG9tYWluX3ZtY2VfbW9uaXRvcl9lbmQoeGNfaW50ZXJmYWNlICp4Y2gsCisgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZG9taWQsCisgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgc2lnbmVkIGNoYXIgKnZtY2Vfd2hpbGVfbW9uaXRvcikKK3sKKyAgICBp
bnQgcmV0OworICAgIERFQ0xBUkVfRE9NQ1RMOworCisgICAgZG9tY3RsLmNtZCA9IFhFTl9ET01D
VExfdm1jZV9tb25pdG9yX2VuZDsKKyAgICBkb21jdGwuZG9tYWluID0gKGRvbWlkX3QpZG9taWQ7
CisgICAgcmV0ID0gZG9fZG9tY3RsKHhjaCwgJmRvbWN0bCk7CisgICAgaWYgKCAhcmV0ICkKKyAg
ICAgICAgKnZtY2Vfd2hpbGVfbW9uaXRvciA9IGRvbWN0bC51LnZtY2VfbW9uaXRvci52bWNlX3do
aWxlX21vbml0b3I7CisKKyAgICByZXR1cm4gcmV0ID8gLTEgOiAwOworfQorCiAvKiBnZXQgaW5m
byBmcm9tIGh2bSBndWVzdCBmb3Igc2F2ZSAqLwogaW50IHhjX2RvbWFpbl9odm1fZ2V0Y29udGV4
dCh4Y19pbnRlcmZhY2UgKnhjaCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMy
X3QgZG9taWQsCmRpZmYgLXIgZTcxYzRiZGNjMDVhIHRvb2xzL2xpYnhjL3hjX2RvbWFpbl9zYXZl
LmMKLS0tIGEvdG9vbHMvbGlieGMveGNfZG9tYWluX3NhdmUuYwlXZWQgU2VwIDE5IDIzOjI3OjQw
IDIwMTIgKzA4MDAKKysrIGIvdG9vbHMvbGlieGMveGNfZG9tYWluX3NhdmUuYwlUaHUgU2VwIDIw
IDAwOjAwOjE3IDIwMTIgKzA4MDAKQEAgLTg5NSw2ICs4OTUsOCBAQAogICAgICAqLwogICAgIGlu
dCBjb21wcmVzc2luZyA9IDA7CiAKKyAgICBzaWduZWQgY2hhciB2bWNlX3doaWxlX21vbml0b3Ig
PSAwOworCiAgICAgaW50IGNvbXBsZXRlZCA9IDA7CiAKICAgICBpZiAoIGh2bSAmJiAhY2FsbGJh
Y2tzLT5zd2l0Y2hfcWVtdV9sb2dkaXJ0eSApCkBAIC0xMTA5LDYgKzExMTEsMTIgQEAKICAgICAg
ICAgZ290byBvdXQ7CiAgICAgfQogCisgICAgaWYgKCB4Y19kb21haW5fdm1jZV9tb25pdG9yX3N0
YXJ0KHhjaCwgZG9tKSApCisgICAgeworICAgICAgICBQRVJST1IoIkVycm9yIHdoZW4gc3RhcnQg
dm1jZSBtb25pdG9yXG4iKTsKKyAgICAgICAgZ290byBvdXQ7CisgICAgfQorCiAgIGNvcHlwYWdl
czoKICNkZWZpbmUgd3JleGFjdChmZCwgYnVmLCBsZW4pIHdyaXRlX2J1ZmZlcih4Y2gsIGxhc3Rf
aXRlciwgb2IsIChmZCksIChidWYpLCAobGVuKSkKICNkZWZpbmUgd3J1bmNhY2hlZChmZCwgbGl2
ZSwgYnVmLCBsZW4pIHdyaXRlX3VuY2FjaGVkKHhjaCwgbGFzdF9pdGVyLCBvYiwgKGZkKSwgKGJ1
ZiksIChsZW4pKQpAQCAtMTU3MSw2ICsxNTc5LDE3IEBACiAKICAgICBEUFJJTlRGKCJBbGwgbWVt
b3J5IGlzIHNhdmVkXG4iKTsKIAorICAgIGlmICggeGNfZG9tYWluX3ZtY2VfbW9uaXRvcl9lbmQo
eGNoLCBkb20sICZ2bWNlX3doaWxlX21vbml0b3IpICkKKyAgICB7CisgICAgICAgIFBFUlJPUigi
RXJyb3Igd2hlbiBlbmQgdm1jZSBtb25pdG9yXG4iKTsKKyAgICAgICAgZ290byBvdXQ7CisgICAg
fQorICAgIGVsc2UgaWYgKCB2bWNlX3doaWxlX21vbml0b3IgPT0gLTEgKQorICAgIHsKKyAgICAg
ICAgZnByaW50ZihzdGRlcnIsICJ2TUNFIG9jY3VycmVkLCBhYm9ydCB0aGlzIHRpbWUgYW5kIHRy
eSBsYXRlci5cbiIpOworICAgICAgICBnb3RvIG91dDsKKyAgICB9CisKICAgICAvKiBBZnRlciBs
YXN0X2l0ZXIsIGJ1ZmZlciB0aGUgcmVzdCBvZiBwYWdlYnVmICYgdGFpbGJ1ZiBkYXRhIGludG8g
YQogICAgICAqIHNlcGFyYXRlIG91dHB1dCBidWZmZXIgYW5kIGZsdXNoIGl0IGFmdGVyIHRoZSBj
b21wcmVzc2VkIHBhZ2UgY2h1bmtzLgogICAgICAqLwpkaWZmIC1yIGU3MWM0YmRjYzA1YSB0b29s
cy9saWJ4Yy94ZW5jdHJsLmgKLS0tIGEvdG9vbHMvbGlieGMveGVuY3RybC5oCVdlZCBTZXAgMTkg
MjM6Mjc6NDAgMjAxMiArMDgwMAorKysgYi90b29scy9saWJ4Yy94ZW5jdHJsLmgJVGh1IFNlcCAy
MCAwMDowMDoxNyAyMDEyICswODAwCkBAIC01NzUsNiArNTc1LDI2IEBACiAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHhjX2RvbWFpbmluZm9fdCAqaW5mbyk7CiAKIC8qKgorICogVGhpcyBmdW5j
dGlvbiBzdGFydCBtb25pdG9yIHZtY2UgZXZlbnQuCisgKiBAcGFybSB4Y2ggYSBoYW5kbGUgdG8g
YW4gb3BlbiBoeXBlcnZpc29yIGludGVyZmFjZQorICogQHBhcm0gZG9taWQgdGhlIGRvbWFpbiBp
ZCBtb25pdG9yZWQKKyAqIEByZXR1cm4gMCBvbiBzdWNjZXNzLCAtMSBvbiBmYWlsdXJlCisgKi8K
K2ludCB4Y19kb21haW5fdm1jZV9tb25pdG9yX3N0YXJ0KHhjX2ludGVyZmFjZSAqeGNoLAorICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZG9taWQpOworCisvKioKKyAq
IFRoaXMgZnVuY3Rpb24gZW5kIG1vbml0b3Igdm1jZSBldmVudAorICogQHBhcm0geGNoIGEgaGFu
ZGxlIHRvIGFuIG9wZW4gaHlwZXJ2aXNvciBpbnRlcmZhY2UKKyAqIEBwYXJtIGRvbWlkIHRoZSBk
b21haW4gaWQgbW9uaXRvcmVkCisgKiBAcGFybSB2bWNlX3doaWxlX21pZ3JhdGUgYSBwb2ludGVy
IHJldHVybiB3aGV0aGVyIHZNQ0Ugb2NjdXIgd2hlbiBtaWdyYXRlIAorICogQHJldHVybiAwIG9u
IHN1Y2Nlc3MsIC0xIG9uIGZhaWx1cmUKKyAqLworaW50IHhjX2RvbWFpbl92bWNlX21vbml0b3Jf
ZW5kKHhjX2ludGVyZmFjZSAqeGNoLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVp
bnQzMl90IGRvbWlkLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNpZ25lZCBjaGFy
ICp2bWNlX3doaWxlX21vbml0b3IpOworCisvKioKICAqIFRoaXMgZnVuY3Rpb24gcmV0dXJucyBp
bmZvcm1hdGlvbiBhYm91dCB0aGUgY29udGV4dCBvZiBhIGh2bSBkb21haW4KICAqIEBwYXJtIHhj
aCBhIGhhbmRsZSB0byBhbiBvcGVuIGh5cGVydmlzb3IgaW50ZXJmYWNlCiAgKiBAcGFybSBkb21p
ZCB0aGUgZG9tYWluIHRvIGdldCBpbmZvcm1hdGlvbiBmcm9tCmRpZmYgLXIgZTcxYzRiZGNjMDVh
IHhlbi9hcmNoL3g4Ni9jcHUvbWNoZWNrL21jZV9pbnRlbC5jCi0tLSBhL3hlbi9hcmNoL3g4Ni9j
cHUvbWNoZWNrL21jZV9pbnRlbC5jCVdlZCBTZXAgMTkgMjM6Mjc6NDAgMjAxMiArMDgwMAorKysg
Yi94ZW4vYXJjaC94ODYvY3B1L21jaGVjay9tY2VfaW50ZWwuYwlUaHUgU2VwIDIwIDAwOjAwOjE3
IDIwMTIgKzA4MDAKQEAgLTM1OCw2ICszNTgsMTIgQEAKICAgICAgICAgICAgICAgICAgICAgZ290
byB2bWNlX2ZhaWxlZDsKICAgICAgICAgICAgICAgICB9CiAKKyAgICAgICAgICAgICAgICBpZiAo
IHVubGlrZWx5KGQtPmFyY2gudm1jZV9tb25pdG9yKSApCisgICAgICAgICAgICAgICAgeworICAg
ICAgICAgICAgICAgICAgICAvKiB2TUNFIG9jY3VyIHdoZW4gZ3Vlc3QgbWlncmF0aW9uICovCisg
ICAgICAgICAgICAgICAgICAgIGQtPmFyY2gudm1jZV9tb25pdG9yID0gLTE7CisgICAgICAgICAg
ICAgICAgfQorCiAgICAgICAgICAgICAgICAgLyogV2Ugd2lsbCBpbmplY3Qgdk1DRSB0byBET01V
Ki8KICAgICAgICAgICAgICAgICBpZiAoIGluamVjdF92bWNlKGQpIDwgMCApCiAgICAgICAgICAg
ICAgICAgewpkaWZmIC1yIGU3MWM0YmRjYzA1YSB4ZW4vYXJjaC94ODYvZG9tY3RsLmMKLS0tIGEv
eGVuL2FyY2gveDg2L2RvbWN0bC5jCVdlZCBTZXAgMTkgMjM6Mjc6NDAgMjAxMiArMDgwMAorKysg
Yi94ZW4vYXJjaC94ODYvZG9tY3RsLmMJVGh1IFNlcCAyMCAwMDowMDoxNyAyMDEyICswODAwCkBA
IC0xNTE0LDYgKzE1MTQsNDAgQEAKICAgICB9CiAgICAgYnJlYWs7CiAKKyAgICBjYXNlIFhFTl9E
T01DVExfdm1jZV9tb25pdG9yX3N0YXJ0OgorICAgIHsKKyAgICAgICAgc3RydWN0IGRvbWFpbiAq
ZDsKKworICAgICAgICBkID0gcmN1X2xvY2tfZG9tYWluX2J5X2lkKGRvbWN0bC0+ZG9tYWluKTsK
KyAgICAgICAgaWYgKCBkICE9IE5VTEwgKQorICAgICAgICB7CisgICAgICAgICAgICBkLT5hcmNo
LnZtY2VfbW9uaXRvciA9IDE7CisgICAgICAgICAgICByY3VfdW5sb2NrX2RvbWFpbihkKTsKKyAg
ICAgICAgfQorICAgICAgICBlbHNlCisgICAgICAgICAgICByZXQgPSAtRVNSQ0g7CisgICAgfQor
ICAgIGJyZWFrOworCisgICAgY2FzZSBYRU5fRE9NQ1RMX3ZtY2VfbW9uaXRvcl9lbmQ6CisgICAg
eworICAgICAgICBzdHJ1Y3QgZG9tYWluICpkOworCisgICAgICAgIGQgPSByY3VfbG9ja19kb21h
aW5fYnlfaWQoZG9tY3RsLT5kb21haW4pOworICAgICAgICBpZiAoIGQgIT0gTlVMTCkKKyAgICAg
ICAgeworICAgICAgICAgICAgZG9tY3RsLT51LnZtY2VfbW9uaXRvci52bWNlX3doaWxlX21vbml0
b3IgPQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkLT5hcmNoLnZtY2Vf
bW9uaXRvcjsKKyAgICAgICAgICAgIGQtPmFyY2gudm1jZV9tb25pdG9yID0gMDsKKyAgICAgICAg
ICAgIHJjdV91bmxvY2tfZG9tYWluKGQpOworICAgICAgICAgICAgaWYgKCBjb3B5X3RvX2d1ZXN0
KHVfZG9tY3RsLCBkb21jdGwsIDEpICkKKyAgICAgICAgICAgICAgICByZXQgPSAtRUZBVUxUOwor
ICAgICAgICB9CisgICAgICAgIGVsc2UKKyAgICAgICAgICAgIHJldCA9IC1FU1JDSDsKKyAgICB9
CisgICAgYnJlYWs7CisKICAgICBkZWZhdWx0OgogICAgICAgICByZXQgPSBpb21tdV9kb19kb21j
dGwoZG9tY3RsLCB1X2RvbWN0bCk7CiAgICAgICAgIGJyZWFrOwpkaWZmIC1yIGU3MWM0YmRjYzA1
YSB4ZW4vaW5jbHVkZS9hc20teDg2L2RvbWFpbi5oCi0tLSBhL3hlbi9pbmNsdWRlL2FzbS14ODYv
ZG9tYWluLmgJV2VkIFNlcCAxOSAyMzoyNzo0MCAyMDEyICswODAwCisrKyBiL3hlbi9pbmNsdWRl
L2FzbS14ODYvZG9tYWluLmgJVGh1IFNlcCAyMCAwMDowMDoxNyAyMDEyICswODAwCkBAIC0yNzks
NiArMjc5LDExIEBACiAgICAgYm9vbF90IGhhc18zMmJpdF9zaGluZm87CiAgICAgLyogRG9tYWlu
IGNhbm5vdCBoYW5kbGUgc3B1cmlvdXMgcGFnZSBmYXVsdHM/ICovCiAgICAgYm9vbF90IHN1cHBy
ZXNzX3NwdXJpb3VzX3BhZ2VfZmF1bHRzOworICAgIC8qIE1vbml0b3JpbmcgZ3Vlc3QgbWVtb3J5
IGNvcHkgb2YgbWlncmF0aW9uCisgICAgICogPSAwIC0gbm90IG1vbml0b3JpbmcKKyAgICAgKiA+
IDAgLSBtb25pdG9yaW5nCisgICAgICogPCAwIC0gdk1DRSBvY2N1cnJlZCB3aGlsZSBtb25pdG9y
aW5nICovCisgICAgczggdm1jZV9tb25pdG9yOwogCiAgICAgLyogQ29udGludWFibGUgZG9tYWlu
X3JlbGlucXVpc2hfcmVzb3VyY2VzKCkuICovCiAgICAgZW51bSB7CmRpZmYgLXIgZTcxYzRiZGNj
MDVhIHhlbi9pbmNsdWRlL3B1YmxpYy9kb21jdGwuaAotLS0gYS94ZW4vaW5jbHVkZS9wdWJsaWMv
ZG9tY3RsLmgJV2VkIFNlcCAxOSAyMzoyNzo0MCAyMDEyICswODAwCisrKyBiL3hlbi9pbmNsdWRl
L3B1YmxpYy9kb21jdGwuaAlUaHUgU2VwIDIwIDAwOjAwOjE3IDIwMTIgKzA4MDAKQEAgLTgyOCw2
ICs4MjgsMTIgQEAKIHR5cGVkZWYgc3RydWN0IHhlbl9kb21jdGxfc2V0X2FjY2Vzc19yZXF1aXJl
ZCB4ZW5fZG9tY3RsX3NldF9hY2Nlc3NfcmVxdWlyZWRfdDsKIERFRklORV9YRU5fR1VFU1RfSEFO
RExFKHhlbl9kb21jdGxfc2V0X2FjY2Vzc19yZXF1aXJlZF90KTsKIAorc3RydWN0IHhlbl9kb21j
dGxfdm1jZV9tb25pdG9yIHsKKyAgICBzaWduZWQgY2hhciB2bWNlX3doaWxlX21vbml0b3I7Cit9
OwordHlwZWRlZiBzdHJ1Y3QgeGVuX2RvbWN0bF92bWNlX21vbml0b3IgeGVuX2RvbWN0bF92bWNl
X21vbml0b3JfdDsKK0RFRklORV9YRU5fR1VFU1RfSEFORExFKHhlbl9kb21jdGxfdm1jZV9tb25p
dG9yX3QpOworCiBzdHJ1Y3QgeGVuX2RvbWN0bCB7CiAgICAgdWludDMyX3QgY21kOwogI2RlZmlu
ZSBYRU5fRE9NQ1RMX2NyZWF0ZWRvbWFpbiAgICAgICAgICAgICAgICAgICAxCkBAIC04OTMsNiAr
ODk5LDggQEAKICNkZWZpbmUgWEVOX0RPTUNUTF9zZXRfYWNjZXNzX3JlcXVpcmVkICAgICAgICAg
ICA2NAogI2RlZmluZSBYRU5fRE9NQ1RMX2F1ZGl0X3AybSAgICAgICAgICAgICAgICAgICAgIDY1
CiAjZGVmaW5lIFhFTl9ET01DVExfc2V0X3ZpcnFfaGFuZGxlciAgICAgICAgICAgICAgNjYKKyNk
ZWZpbmUgWEVOX0RPTUNUTF92bWNlX21vbml0b3Jfc3RhcnQgICAgICAgICAgICA2NworI2RlZmlu
ZSBYRU5fRE9NQ1RMX3ZtY2VfbW9uaXRvcl9lbmQgICAgICAgICAgICAgIDY4CiAjZGVmaW5lIFhF
Tl9ET01DVExfZ2Ric3hfZ3Vlc3RtZW1pbyAgICAgICAgICAgIDEwMDAKICNkZWZpbmUgWEVOX0RP
TUNUTF9nZGJzeF9wYXVzZXZjcHUgICAgICAgICAgICAgMTAwMQogI2RlZmluZSBYRU5fRE9NQ1RM
X2dkYnN4X3VucGF1c2V2Y3B1ICAgICAgICAgICAxMDAyCkBAIC05NDcsNiArOTU1LDcgQEAKICAg
ICAgICAgc3RydWN0IHhlbl9kb21jdGxfc2V0X2FjY2Vzc19yZXF1aXJlZCBhY2Nlc3NfcmVxdWly
ZWQ7CiAgICAgICAgIHN0cnVjdCB4ZW5fZG9tY3RsX2F1ZGl0X3AybSAgICAgICAgIGF1ZGl0X3Ay
bTsKICAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfc2V0X3ZpcnFfaGFuZGxlciAgc2V0X3ZpcnFf
aGFuZGxlcjsKKyAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfdm1jZV9tb25pdG9yICAgICAgdm1j
ZV9tb25pdG9yOwogICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF9nZGJzeF9tZW1pbyAgICAgICBn
ZGJzeF9ndWVzdF9tZW1pbzsKICAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfZ2Ric3hfcGF1c2V1
bnBfdmNwdSBnZGJzeF9wYXVzZXVucF92Y3B1OwogICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF9n
ZGJzeF9kb21zdGF0dXMgICBnZGJzeF9kb21zdGF0dXM7Cg==

--_003_DE8DF0795D48FD4CA783C40EC82923353471B5SHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="5_vmce_migration_pfntype_broken.patch"
Content-Description: 5_vmce_migration_pfntype_broken.patch
Content-Disposition: attachment;
	filename="5_vmce_migration_pfntype_broken.patch"; size=8499;
	creation-date="Wed, 26 Sep 2012 03:09:24 GMT";
	modification-date="Wed, 19 Sep 2012 15:27:52 GMT"
Content-Transfer-Encoding: base64

WDg2L3ZNQ0U6IGd1ZXN0IGJyb2tlbiBwYWdlIGhhbmRsaW5nIHdoZW4gbWlncmF0aW9uCgpUaGlz
IHBhdGNoIGlzIHVzZWQgdG8gaGFuZGxlIGd1ZXN0IGJyb2tlbiBwYWdlIHdoZW4gbWlncmF0aW9u
LgoKQXQgc2VuZGVyLCB0aGUgYnJva2VuIHBhZ2Ugd291bGQgbm90IGJlIG1hcHBlZCwgYW5kIHRo
ZSBlcnJvciBwYWdlCmNvbnRlbnQgd291bGQgbm90IGJlIGNvcGllZCB0byB0YXJnZXQsIG90aGVy
d2lzZSBpdCBtYXkgdHJpZ2dlciBtb3JlCnNlcmlvdXMgZXJyb3IgKGkuZS4gU1JBUiBlcnJvciku
IFdoaWxlIGl0cyBwZm5fdHlwZSBhbmQgcGZuIG51bWJlcgp3b3VsZCBiZSB0cmFuc2ZlcnJlZCB0
byB0YXJnZXQgc28gdGhhdCB0YXJnZXQgdGFrZSBhcHByb3ByaWF0ZSBhY3Rpb24uCgpBdCB0YXJn
ZXQsIGl0IHdvdWxkIHNldCBwMm0gYXMgcDJtX3JhbV9icm9rZW4gZm9yIGJyb2tlbiBwYWdlLCBz
byB0aGF0CmlmIGd1ZXN0IGFjY2VzcyB0aGUgYnJva2VuIHBhZ2UgYWdhaW4sIGl0IHdvdWxkIGtp
bGwgZ3Vlc3QgYXMgZXhwZWN0ZWQuCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNv
bmcubGl1QGludGVsLmNvbT4KCmRpZmYgLXIgYTFkMTA2ZDFhZWM4IHRvb2xzL2xpYnhjL3hjX2Rv
bWFpbi5jCi0tLSBhL3Rvb2xzL2xpYnhjL3hjX2RvbWFpbi5jCVdlZCBTZXAgMTkgMDM6MzE6MzEg
MjAxMiArMDgwMAorKysgYi90b29scy9saWJ4Yy94Y19kb21haW4uYwlXZWQgU2VwIDE5IDA0OjIy
OjI2IDIwMTIgKzA4MDAKQEAgLTMxNCw2ICszMTQsMjIgQEAKICAgICByZXR1cm4gcmV0ID8gLTEg
OiAwOwogfQogCisvKiBzZXQgYnJva2VuIHBhZ2UgcDJtICovCitpbnQgeGNfc2V0X2Jyb2tlbl9w
YWdlX3AybSh4Y19pbnRlcmZhY2UgKnhjaCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgIHVp
bnQzMl90IGRvbWlkLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgdW5zaWduZWQgbG9uZyBw
Zm4pCit7CisgICAgaW50IHJldDsKKyAgICBERUNMQVJFX0RPTUNUTDsKKworICAgIGRvbWN0bC5j
bWQgPSBYRU5fRE9NQ1RMX3NldF9icm9rZW5fcGFnZV9wMm07CisgICAgZG9tY3RsLmRvbWFpbiA9
IChkb21pZF90KWRvbWlkOworICAgIGRvbWN0bC51LnNldF9icm9rZW5fcGFnZV9wMm0ucGZuID0g
cGZuOworICAgIHJldCA9IGRvX2RvbWN0bCh4Y2gsICZkb21jdGwpOworCisgICAgcmV0dXJuIHJl
dCA/IC0xIDogMDsKK30KKwogLyogZ2V0IGluZm8gZnJvbSBodm0gZ3Vlc3QgZm9yIHNhdmUgKi8K
IGludCB4Y19kb21haW5faHZtX2dldGNvbnRleHQoeGNfaW50ZXJmYWNlICp4Y2gsCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IGRvbWlkLApkaWZmIC1yIGExZDEwNmQxYWVj
OCB0b29scy9saWJ4Yy94Y19kb21haW5fcmVzdG9yZS5jCi0tLSBhL3Rvb2xzL2xpYnhjL3hjX2Rv
bWFpbl9yZXN0b3JlLmMJV2VkIFNlcCAxOSAwMzozMTozMSAyMDEyICswODAwCisrKyBiL3Rvb2xz
L2xpYnhjL3hjX2RvbWFpbl9yZXN0b3JlLmMJV2VkIFNlcCAxOSAwNDoyMjoyNiAyMDEyICswODAw
CkBAIC05NjIsOSArOTYyLDE1IEBACiAKICAgICBjb3VudHBhZ2VzID0gY291bnQ7CiAgICAgZm9y
IChpID0gb2xkY291bnQ7IGkgPCBidWYtPm5yX3BhZ2VzOyArK2kpCi0gICAgICAgIGlmICgoYnVm
LT5wZm5fdHlwZXNbaV0gJiBYRU5fRE9NQ1RMX1BGSU5GT19MVEFCX01BU0spID09IFhFTl9ET01D
VExfUEZJTkZPX1hUQUIKLSAgICAgICAgICAgIHx8KGJ1Zi0+cGZuX3R5cGVzW2ldICYgWEVOX0RP
TUNUTF9QRklORk9fTFRBQl9NQVNLKSA9PSBYRU5fRE9NQ1RMX1BGSU5GT19YQUxMT0MpCisgICAg
eworICAgICAgICB1bnNpZ25lZCBsb25nIHBhZ2V0eXBlOworCisgICAgICAgIHBhZ2V0eXBlID0g
YnVmLT5wZm5fdHlwZXNbaV0gJiBYRU5fRE9NQ1RMX1BGSU5GT19MVEFCX01BU0s7CisgICAgICAg
IGlmICggcGFnZXR5cGUgPT0gWEVOX0RPTUNUTF9QRklORk9fWFRBQiB8fAorICAgICAgICAgICAg
IHBhZ2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX0JST0tFTiB8fAorICAgICAgICAgICAgIHBh
Z2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX1hBTExPQyApCiAgICAgICAgICAgICAtLWNvdW50
cGFnZXM7CisgICAgfQogCiAgICAgaWYgKCFjb3VudHBhZ2VzKQogICAgICAgICByZXR1cm4gY291
bnQ7CkBAIC0xMjAwLDYgKzEyMDYsMTcgQEAKICAgICAgICAgICAgIC8qIGEgYm9ndXMvdW5tYXBw
ZWQvYWxsb2NhdGUtb25seSBwYWdlOiBza2lwIGl0ICovCiAgICAgICAgICAgICBjb250aW51ZTsK
IAorICAgICAgICBpZiAoIHBhZ2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX0JST0tFTiApCisg
ICAgICAgIHsKKyAgICAgICAgICAgIGlmICggeGNfc2V0X2Jyb2tlbl9wYWdlX3AybSh4Y2gsIGRv
bSwgcGZuKSApCisgICAgICAgICAgICB7CisgICAgICAgICAgICAgICAgRVJST1IoIlNldCBwMm0g
Zm9yIGJyb2tlbiBwYWdlIGZhaWwsICIKKyAgICAgICAgICAgICAgICAgICAgICAiZG9tPSVkLCBw
Zm49JWx4XG4iLCBkb20sIHBmbik7CisgICAgICAgICAgICAgICAgZ290byBlcnJfbWFwcGVkOwor
ICAgICAgICAgICAgfQorICAgICAgICAgICAgY29udGludWU7CisgICAgICAgIH0KKwogICAgICAg
ICBpZiAocGZuX2VycltpXSkKICAgICAgICAgewogICAgICAgICAgICAgRVJST1IoInVuZXhwZWN0
ZWQgUEZOIG1hcHBpbmcgZmFpbHVyZSBwZm4gJWx4IG1hcF9tZm4gJWx4IHAybV9tZm4gJWx4IiwK
ZGlmZiAtciBhMWQxMDZkMWFlYzggdG9vbHMvbGlieGMveGNfZG9tYWluX3NhdmUuYwotLS0gYS90
b29scy9saWJ4Yy94Y19kb21haW5fc2F2ZS5jCVdlZCBTZXAgMTkgMDM6MzE6MzEgMjAxMiArMDgw
MAorKysgYi90b29scy9saWJ4Yy94Y19kb21haW5fc2F2ZS5jCVdlZCBTZXAgMTkgMDQ6MjI6MjYg
MjAxMiArMDgwMApAQCAtMTI4NSw2ICsxMjg1LDEzIEBACiAgICAgICAgICAgICAgICAgaWYgKCAh
aHZtICkKICAgICAgICAgICAgICAgICAgICAgZ21mbiA9IHBmbl90b19tZm4oZ21mbik7CiAKKyAg
ICAgICAgICAgICAgICBpZiAoIHBmbl90eXBlW2pdID09IFhFTl9ET01DVExfUEZJTkZPX0JST0tF
TiApCisgICAgICAgICAgICAgICAgeworICAgICAgICAgICAgICAgICAgICBwZm5fdHlwZVtqXSB8
PSBwZm5fYmF0Y2hbal07CisgICAgICAgICAgICAgICAgICAgICsrcnVuOworICAgICAgICAgICAg
ICAgICAgICBjb250aW51ZTsKKyAgICAgICAgICAgICAgICB9CisKICAgICAgICAgICAgICAgICBp
ZiAoIHBmbl9lcnJbal0gKQogICAgICAgICAgICAgICAgIHsKICAgICAgICAgICAgICAgICAgICAg
aWYgKCBwZm5fdHlwZVtqXSA9PSBYRU5fRE9NQ1RMX1BGSU5GT19YVEFCICkKQEAgLTEzNzksOCAr
MTM4NiwxMiBAQAogICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAgfQogCi0g
ICAgICAgICAgICAgICAgLyogc2tpcCBwYWdlcyB0aGF0IGFyZW4ndCBwcmVzZW50IG9yIGFyZSBh
bGxvYy1vbmx5ICovCisgICAgICAgICAgICAgICAgLyoKKyAgICAgICAgICAgICAgICAgKiBza2lw
IHBhZ2VzIHRoYXQgYXJlbid0IHByZXNlbnQsCisgICAgICAgICAgICAgICAgICogb3IgYXJlIGJy
b2tlbiwgb3IgYXJlIGFsbG9jLW9ubHkKKyAgICAgICAgICAgICAgICAgKi8KICAgICAgICAgICAg
ICAgICBpZiAoIHBhZ2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX1hUQUIKKyAgICAgICAgICAg
ICAgICAgICAgfHwgcGFnZXR5cGUgPT0gWEVOX0RPTUNUTF9QRklORk9fQlJPS0VOCiAgICAgICAg
ICAgICAgICAgICAgIHx8IHBhZ2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX1hBTExPQyApCiAg
ICAgICAgICAgICAgICAgICAgIGNvbnRpbnVlOwogCmRpZmYgLXIgYTFkMTA2ZDFhZWM4IHRvb2xz
L2xpYnhjL3hlbmN0cmwuaAotLS0gYS90b29scy9saWJ4Yy94ZW5jdHJsLmgJV2VkIFNlcCAxOSAw
MzozMTozMSAyMDEyICswODAwCisrKyBiL3Rvb2xzL2xpYnhjL3hlbmN0cmwuaAlXZWQgU2VwIDE5
IDA0OjIyOjI2IDIwMTIgKzA4MDAKQEAgLTU5MSw2ICs1OTEsMTcgQEAKICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBzaWduZWQgY2hhciAqdm1jZV93aGlsZV9tb25pdG9yKTsKIAogLyoq
CisgKiBUaGlzIGZ1bmN0aW9uIHNldCBwMm0gZm9yIGJyb2tlbiBwYWdlCisgKiAmcGFybSB4Y2gg
YSBoYW5kbGUgdG8gYW4gb3BlbiBoeXBlcnZpc29yIGludGVyZmFjZQorICogQHBhcm0gZG9taWQg
dGhlIGRvbWFpbiBpZCB3aGljaCBicm9rZW4gcGFnZSBiZWxvbmcgdG8KKyAqIEBwYXJtIHBmbiB0
aGUgcGZuIG51bWJlciBvZiB0aGUgYnJva2VuIHBhZ2UKKyAqIEByZXR1cm4gMCBvbiBzdWNjZXNz
LCAtMSBvbiBmYWlsdXJlCisgKi8KK2ludCB4Y19zZXRfYnJva2VuX3BhZ2VfcDJtKHhjX2ludGVy
ZmFjZSAqeGNoLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZG9taWQsCisg
ICAgICAgICAgICAgICAgICAgICAgICAgICB1bnNpZ25lZCBsb25nIHBmbik7CisKKy8qKgogICog
VGhpcyBmdW5jdGlvbiByZXR1cm5zIGluZm9ybWF0aW9uIGFib3V0IHRoZSBjb250ZXh0IG9mIGEg
aHZtIGRvbWFpbgogICogQHBhcm0geGNoIGEgaGFuZGxlIHRvIGFuIG9wZW4gaHlwZXJ2aXNvciBp
bnRlcmZhY2UKICAqIEBwYXJtIGRvbWlkIHRoZSBkb21haW4gdG8gZ2V0IGluZm9ybWF0aW9uIGZy
b20KZGlmZiAtciBhMWQxMDZkMWFlYzggeGVuL2FyY2gveDg2L2RvbWN0bC5jCi0tLSBhL3hlbi9h
cmNoL3g4Ni9kb21jdGwuYwlXZWQgU2VwIDE5IDAzOjMxOjMxIDIwMTIgKzA4MDAKKysrIGIveGVu
L2FyY2gveDg2L2RvbWN0bC5jCVdlZCBTZXAgMTkgMDQ6MjI6MjYgMjAxMiArMDgwMApAQCAtMjA5
LDEyICsyMDksMTggQEAKICAgICAgICAgICAgICAgICBmb3IgKCBqID0gMDsgaiA8IGs7IGorKyAp
CiAgICAgICAgICAgICAgICAgewogICAgICAgICAgICAgICAgICAgICB1bnNpZ25lZCBsb25nIHR5
cGUgPSAwOworICAgICAgICAgICAgICAgICAgICBwMm1fdHlwZV90IHQ7CiAKLSAgICAgICAgICAg
ICAgICAgICAgcGFnZSA9IGdldF9wYWdlX2Zyb21fZ2ZuKGQsIGFycltqXSwgTlVMTCwgUDJNX0FM
TE9DKTsKKyAgICAgICAgICAgICAgICAgICAgcGFnZSA9IGdldF9wYWdlX2Zyb21fZ2ZuKGQsIGFy
cltqXSwgJnQsIFAyTV9BTExPQyk7CiAKICAgICAgICAgICAgICAgICAgICAgaWYgKCB1bmxpa2Vs
eSghcGFnZSkgfHwKICAgICAgICAgICAgICAgICAgICAgICAgICB1bmxpa2VseShpc194ZW5faGVh
cF9wYWdlKHBhZ2UpKSApCi0gICAgICAgICAgICAgICAgICAgICAgICB0eXBlID0gWEVOX0RPTUNU
TF9QRklORk9fWFRBQjsKKyAgICAgICAgICAgICAgICAgICAgeworICAgICAgICAgICAgICAgICAg
ICAgICAgaWYgKCBwMm1faXNfYnJva2VuKHQpICkKKyAgICAgICAgICAgICAgICAgICAgICAgICAg
ICB0eXBlID0gWEVOX0RPTUNUTF9QRklORk9fQlJPS0VOOworICAgICAgICAgICAgICAgICAgICAg
ICAgZWxzZQorICAgICAgICAgICAgICAgICAgICAgICAgICAgIHR5cGUgPSBYRU5fRE9NQ1RMX1BG
SU5GT19YVEFCOworICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAgICAgIGVs
c2UKICAgICAgICAgICAgICAgICAgICAgewogICAgICAgICAgICAgICAgICAgICAgICAgc3dpdGNo
KCBwYWdlLT51LmludXNlLnR5cGVfaW5mbyAmIFBHVF90eXBlX21hc2sgKQpAQCAtMjM1LDYgKzI0
MSw5IEBACiAKICAgICAgICAgICAgICAgICAgICAgICAgIGlmICggcGFnZS0+dS5pbnVzZS50eXBl
X2luZm8gJiBQR1RfcGlubmVkICkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0eXBlIHw9
IFhFTl9ET01DVExfUEZJTkZPX0xQSU5UQUI7CisKKyAgICAgICAgICAgICAgICAgICAgICAgIGlm
ICggcGFnZS0+Y291bnRfaW5mbyAmIFBHQ19icm9rZW4gKQorICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHR5cGUgPSBYRU5fRE9NQ1RMX1BGSU5GT19CUk9LRU47CiAgICAgICAgICAgICAgICAg
ICAgIH0KIAogICAgICAgICAgICAgICAgICAgICBpZiAoIHBhZ2UgKQpAQCAtMTU0OCw2ICsxNTU3
LDI4IEBACiAgICAgfQogICAgIGJyZWFrOwogCisgICAgY2FzZSBYRU5fRE9NQ1RMX3NldF9icm9r
ZW5fcGFnZV9wMm06CisgICAgeworICAgICAgICBzdHJ1Y3QgZG9tYWluICpkOworICAgICAgICBw
Mm1fdHlwZV90IHB0OworICAgICAgICB1bnNpZ25lZCBsb25nIHBmbjsKKworICAgICAgICBkID0g
cmN1X2xvY2tfZG9tYWluX2J5X2lkKGRvbWN0bC0+ZG9tYWluKTsKKyAgICAgICAgaWYgKCBkICE9
IE5VTEwgKQorICAgICAgICB7CisgICAgICAgICAgICBwZm4gPSBkb21jdGwtPnUuc2V0X2Jyb2tl
bl9wYWdlX3AybS5wZm47CisKKyAgICAgICAgICAgIGdldF9nZm5fcXVlcnkoZCwgcGZuLCAmcHQp
OworICAgICAgICAgICAgcDJtX2NoYW5nZV90eXBlKGQsIHBmbiwgcHQsIHAybV9yYW1fYnJva2Vu
KTsKKyAgICAgICAgICAgIHB1dF9nZm4oZCwgcGZuKTsKKworICAgICAgICAgICAgcmN1X3VubG9j
a19kb21haW4oZCk7CisgICAgICAgIH0KKyAgICAgICAgZWxzZQorICAgICAgICAgICAgcmV0ID0g
LUVTUkNIOworICAgIH0KKyAgICBicmVhazsKKwogICAgIGRlZmF1bHQ6CiAgICAgICAgIHJldCA9
IGlvbW11X2RvX2RvbWN0bChkb21jdGwsIHVfZG9tY3RsKTsKICAgICAgICAgYnJlYWs7CmRpZmYg
LXIgYTFkMTA2ZDFhZWM4IHhlbi9pbmNsdWRlL3B1YmxpYy9kb21jdGwuaAotLS0gYS94ZW4vaW5j
bHVkZS9wdWJsaWMvZG9tY3RsLmgJV2VkIFNlcCAxOSAwMzozMTozMSAyMDEyICswODAwCisrKyBi
L3hlbi9pbmNsdWRlL3B1YmxpYy9kb21jdGwuaAlXZWQgU2VwIDE5IDA0OjIyOjI2IDIwMTIgKzA4
MDAKQEAgLTEzNiw2ICsxMzYsNyBAQAogI2RlZmluZSBYRU5fRE9NQ1RMX1BGSU5GT19MUElOVEFC
ICgweDFVPDwzMSkKICNkZWZpbmUgWEVOX0RPTUNUTF9QRklORk9fWFRBQiAgICAoMHhmVTw8Mjgp
IC8qIGludmFsaWQgcGFnZSAqLwogI2RlZmluZSBYRU5fRE9NQ1RMX1BGSU5GT19YQUxMT0MgICgw
eGVVPDwyOCkgLyogYWxsb2NhdGUtb25seSBwYWdlICovCisjZGVmaW5lIFhFTl9ET01DVExfUEZJ
TkZPX0JST0tFTiAgKDB4ZFU8PDI4KSAvKiBicm9rZW4gcGFnZSAqLwogI2RlZmluZSBYRU5fRE9N
Q1RMX1BGSU5GT19QQUdFRFRBQiAoMHg4VTw8MjgpCiAjZGVmaW5lIFhFTl9ET01DVExfUEZJTkZP
X0xUQUJfTUFTSyAoMHhmVTw8MjgpCiAKQEAgLTgzNCw2ICs4MzUsMTIgQEAKIHR5cGVkZWYgc3Ry
dWN0IHhlbl9kb21jdGxfdm1jZV9tb25pdG9yIHhlbl9kb21jdGxfdm1jZV9tb25pdG9yX3Q7CiBE
RUZJTkVfWEVOX0dVRVNUX0hBTkRMRSh4ZW5fZG9tY3RsX3ZtY2VfbW9uaXRvcl90KTsKIAorc3Ry
dWN0IHhlbl9kb21jdGxfc2V0X2Jyb2tlbl9wYWdlX3AybSB7CisgICAgdWludDY0X3QgcGZuOwor
fTsKK3R5cGVkZWYgc3RydWN0IHhlbl9kb21jdGxfc2V0X2Jyb2tlbl9wYWdlX3AybSB4ZW5fZG9t
Y3RsX3NldF9icm9rZW5fcGFnZV9wMm1fdDsKK0RFRklORV9YRU5fR1VFU1RfSEFORExFKHhlbl9k
b21jdGxfc2V0X2Jyb2tlbl9wYWdlX3AybV90KTsKKwogc3RydWN0IHhlbl9kb21jdGwgewogICAg
IHVpbnQzMl90IGNtZDsKICNkZWZpbmUgWEVOX0RPTUNUTF9jcmVhdGVkb21haW4gICAgICAgICAg
ICAgICAgICAgMQpAQCAtOTAxLDYgKzkwOCw3IEBACiAjZGVmaW5lIFhFTl9ET01DVExfc2V0X3Zp
cnFfaGFuZGxlciAgICAgICAgICAgICAgNjYKICNkZWZpbmUgWEVOX0RPTUNUTF92bWNlX21vbml0
b3Jfc3RhcnQgICAgICAgICAgICA2NwogI2RlZmluZSBYRU5fRE9NQ1RMX3ZtY2VfbW9uaXRvcl9l
bmQgICAgICAgICAgICAgIDY4CisjZGVmaW5lIFhFTl9ET01DVExfc2V0X2Jyb2tlbl9wYWdlX3Ay
bSAgICAgICAgICAgNjkKICNkZWZpbmUgWEVOX0RPTUNUTF9nZGJzeF9ndWVzdG1lbWlvICAgICAg
ICAgICAgMTAwMAogI2RlZmluZSBYRU5fRE9NQ1RMX2dkYnN4X3BhdXNldmNwdSAgICAgICAgICAg
ICAxMDAxCiAjZGVmaW5lIFhFTl9ET01DVExfZ2Ric3hfdW5wYXVzZXZjcHUgICAgICAgICAgIDEw
MDIKQEAgLTk1Nyw2ICs5NjUsNyBAQAogICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF9zZXRfdmly
cV9oYW5kbGVyICBzZXRfdmlycV9oYW5kbGVyOwogICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF92
bWNlX21vbml0b3IgICAgICB2bWNlX21vbml0b3I7CiAgICAgICAgIHN0cnVjdCB4ZW5fZG9tY3Rs
X2dkYnN4X21lbWlvICAgICAgIGdkYnN4X2d1ZXN0X21lbWlvOworICAgICAgICBzdHJ1Y3QgeGVu
X2RvbWN0bF9zZXRfYnJva2VuX3BhZ2VfcDJtIHNldF9icm9rZW5fcGFnZV9wMm07CiAgICAgICAg
IHN0cnVjdCB4ZW5fZG9tY3RsX2dkYnN4X3BhdXNldW5wX3ZjcHUgZ2Ric3hfcGF1c2V1bnBfdmNw
dTsKICAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfZ2Ric3hfZG9tc3RhdHVzICAgZ2Ric3hfZG9t
c3RhdHVzOwogICAgICAgICB1aW50OF90ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwYWRb
MTI4XTsK

--_003_DE8DF0795D48FD4CA783C40EC82923353471B5SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_003_DE8DF0795D48FD4CA783C40EC82923353471B5SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Mon Oct 08 15:49:35 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 15:49:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLFZq-0006LW-KZ; Mon, 08 Oct 2012 15:49:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLFZo-0006LP-W9
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 15:49:05 +0000
Received: from [85.158.143.99:21100] by server-3.bemta-4.messagelabs.com id
	38/8A-10986-0F5F2705; Mon, 08 Oct 2012 15:49:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1349711343!27192637!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMzNDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25668 invoked from network); 8 Oct 2012 15:49:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 15:49:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,554,1344211200"; d="scan'208";a="15006760"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 15:49:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Mon, 8 Oct 2012 16:49:03 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TLFZm-0000mY-Tw;
	Mon, 08 Oct 2012 15:49:02 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TLFZm-0001jx-7U;
	Mon, 08 Oct 2012 16:49:02 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Mon, 8 Oct 2012 16:49:02 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13932: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13932 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13932/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13931
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13931
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13931
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13931

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  099589002239
baseline version:
 xen                  3eb9a891889a

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD 
  Ian Campbell 
  Ian Jackson 
  Matthew Fioravante 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=099589002239
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 099589002239
+ branch=xen-unstable
+ revision=099589002239
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 099589002239 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 11 changesets with 16 changes to 6 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 15:49:35 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 15:49:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLFZq-0006LW-KZ; Mon, 08 Oct 2012 15:49:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLFZo-0006LP-W9
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 15:49:05 +0000
Received: from [85.158.143.99:21100] by server-3.bemta-4.messagelabs.com id
	38/8A-10986-0F5F2705; Mon, 08 Oct 2012 15:49:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1349711343!27192637!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMzNDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25668 invoked from network); 8 Oct 2012 15:49:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 15:49:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,554,1344211200"; d="scan'208";a="15006760"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 15:49:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Mon, 8 Oct 2012 16:49:03 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TLFZm-0000mY-Tw;
	Mon, 08 Oct 2012 15:49:02 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TLFZm-0001jx-7U;
	Mon, 08 Oct 2012 16:49:02 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Mon, 8 Oct 2012 16:49:02 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13932: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13932 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13932/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13931
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13931
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13931
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13931

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  099589002239
baseline version:
 xen                  3eb9a891889a

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD 
  Ian Campbell 
  Ian Jackson 
  Matthew Fioravante 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=099589002239
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 099589002239
+ branch=xen-unstable
+ revision=099589002239
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 099589002239 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 11 changesets with 16 changes to 6 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 16:18:38 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 16:18:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLG1x-0007eR-N4; Mon, 08 Oct 2012 16:18:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLG1x-0007eM-1F
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 16:18:09 +0000
Received: from [85.158.143.99:9857] by server-3.bemta-4.messagelabs.com id
	83/2C-10986-0CCF2705; Mon, 08 Oct 2012 16:18:08 +0000
X-Env-Sender: afaerber@suse.de
X-Msg-Ref: server-2.tower-216.messagelabs.com!1349713086!25128624!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17620 invoked from network); 8 Oct 2012 16:18:06 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 16:18:06 -0000
Received: from relay2.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id ECE01A3421;
	Mon,  8 Oct 2012 18:18:04 +0200 (CEST)
Message-ID: <5072FCB9.80606@suse.de>
Date: Mon, 08 Oct 2012 18:18:01 +0200
From: =?ISO-8859-15?Q?Andreas_F=E4rber?= 
Organization: SUSE LINUX Products GmbH
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120825 Thunderbird/15.0
MIME-Version: 1.0
To: Alexander Graf 
References: <1349699033-6703-1-git-send-email-agraf@suse.de>
In-Reply-To: <1349699033-6703-1-git-send-email-agraf@suse.de>
X-Enigmail-Version: 1.4.4
Cc: Anthony Liguori , xen-devel@lists.xensource.com,
	Stefano Stabellini ,
	qemu-devel qemu-devel ,
	"qemu-ppc@nongnu.org List" ,
	Avi Kivity , Scott Wood ,
	David Gibson 
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 00/14] Remove old_portio users
 for memory region PIO mapping
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Am 08.10.2012 14:23, schrieb Alexander Graf:
> When running on PowerPC, we don't have native PIO support. There are a fe=
w hacks
> around to enable PIO access on PowerPC nevertheless.
> =

> The most typical one is the isa-mmio device. It takes MMIO requests and c=
onverts
> them to PIO requests on the (QEMU internal) PIO bus.
> =

> This however is not how real hardware works and it limits us in the abili=
ty to
> spawn eventfd's on PIO ports which doesn't work with this approach.  Inst=
ead,
> let's model it more easily. Let's just map the PIO memory region into MMIO
> space.
> =

> For this to work, we need to get rid of all old_portio struct users, as t=
hey
> break with this approach. This is what this patch set does.

Looks sensible to me as far as reviewed, but I'm missing a patch 13 that
actually rips out old_portio afterwards. :)

Andreas

> It also converts
> the e500 machines and sPAPR to the new memory region model.
> =

> =

> Alex

-- =

SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnberg

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 16:18:38 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 16:18:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLG1x-0007eR-N4; Mon, 08 Oct 2012 16:18:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLG1x-0007eM-1F
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 16:18:09 +0000
Received: from [85.158.143.99:9857] by server-3.bemta-4.messagelabs.com id
	83/2C-10986-0CCF2705; Mon, 08 Oct 2012 16:18:08 +0000
X-Env-Sender: afaerber@suse.de
X-Msg-Ref: server-2.tower-216.messagelabs.com!1349713086!25128624!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17620 invoked from network); 8 Oct 2012 16:18:06 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 16:18:06 -0000
Received: from relay2.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id ECE01A3421;
	Mon,  8 Oct 2012 18:18:04 +0200 (CEST)
Message-ID: <5072FCB9.80606@suse.de>
Date: Mon, 08 Oct 2012 18:18:01 +0200
From: =?ISO-8859-15?Q?Andreas_F=E4rber?= 
Organization: SUSE LINUX Products GmbH
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120825 Thunderbird/15.0
MIME-Version: 1.0
To: Alexander Graf 
References: <1349699033-6703-1-git-send-email-agraf@suse.de>
In-Reply-To: <1349699033-6703-1-git-send-email-agraf@suse.de>
X-Enigmail-Version: 1.4.4
Cc: Anthony Liguori , xen-devel@lists.xensource.com,
	Stefano Stabellini ,
	qemu-devel qemu-devel ,
	"qemu-ppc@nongnu.org List" ,
	Avi Kivity , Scott Wood ,
	David Gibson 
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 00/14] Remove old_portio users
 for memory region PIO mapping
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Am 08.10.2012 14:23, schrieb Alexander Graf:
> When running on PowerPC, we don't have native PIO support. There are a fe=
w hacks
> around to enable PIO access on PowerPC nevertheless.
> =

> The most typical one is the isa-mmio device. It takes MMIO requests and c=
onverts
> them to PIO requests on the (QEMU internal) PIO bus.
> =

> This however is not how real hardware works and it limits us in the abili=
ty to
> spawn eventfd's on PIO ports which doesn't work with this approach.  Inst=
ead,
> let's model it more easily. Let's just map the PIO memory region into MMIO
> space.
> =

> For this to work, we need to get rid of all old_portio struct users, as t=
hey
> break with this approach. This is what this patch set does.

Looks sensible to me as far as reviewed, but I'm missing a patch 13 that
actually rips out old_portio afterwards. :)

Andreas

> It also converts
> the e500 machines and sPAPR to the new memory region model.
> =

> =

> Alex

-- =

SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnberg

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 16:32:34 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 16:32:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLGFY-0007uc-ON; Mon, 08 Oct 2012 16:32:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLGFW-0007uT-M7
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 16:32:10 +0000
Received: from [85.158.143.35:65044] by server-1.bemta-4.messagelabs.com id
	51/8B-05684-90003705; Mon, 08 Oct 2012 16:32:09 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-2.tower-21.messagelabs.com!1349713928!10478620!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.2 required=7.0 tests=MIME_QP_LONG_LINE
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28129 invoked from network); 8 Oct 2012 16:32:08 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 16:32:08 -0000
Received: from relay2.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id B8023927A5;
	Mon,  8 Oct 2012 18:32:05 +0200 (CEST)
References: <1349699033-6703-1-git-send-email-agraf@suse.de>
	<5072FCB9.80606@suse.de>
In-Reply-To: <5072FCB9.80606@suse.de>
Mime-Version: 1.0 (1.0)
Message-Id: 
X-Mailer: iPhone Mail (9B206)
From: Alexander Graf 
Date: Mon, 8 Oct 2012 18:32:27 +0200
To: =?utf-8?Q?Andreas_F=C3=A4rber?= 
Cc: Anthony Liguori ,
	"xen-devel@lists.xensource.com" ,
	Stefano Stabellini ,
	qemu-devel qemu-devel ,
	"qemu-ppc@nongnu.org List" ,
	Avi Kivity , Scott Wood ,
	David Gibson 
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 00/14] Remove old_portio users
	for memory region PIO mapping
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

CgpPbiAwOC4xMC4yMDEyLCBhdCAxODoxOCwgQW5kcmVhcyBGw6RyYmVyIDxhZmFlcmJlckBzdXNl
LmRlPiB3cm90ZToKCj4gQW0gMDguMTAuMjAxMiAxNDoyMywgc2NocmllYiBBbGV4YW5kZXIgR3Jh
ZjoKPj4gV2hlbiBydW5uaW5nIG9uIFBvd2VyUEMsIHdlIGRvbid0IGhhdmUgbmF0aXZlIFBJTyBz
dXBwb3J0LiBUaGVyZSBhcmUgYSBmZXcgaGFja3MKPj4gYXJvdW5kIHRvIGVuYWJsZSBQSU8gYWNj
ZXNzIG9uIFBvd2VyUEMgbmV2ZXJ0aGVsZXNzLgo+PiAKPj4gVGhlIG1vc3QgdHlwaWNhbCBvbmUg
aXMgdGhlIGlzYS1tbWlvIGRldmljZS4gSXQgdGFrZXMgTU1JTyByZXF1ZXN0cyBhbmQgY29udmVy
dHMKPj4gdGhlbSB0byBQSU8gcmVxdWVzdHMgb24gdGhlIChRRU1VIGludGVybmFsKSBQSU8gYnVz
Lgo+PiAKPj4gVGhpcyBob3dldmVyIGlzIG5vdCBob3cgcmVhbCBoYXJkd2FyZSB3b3JrcyBhbmQg
aXQgbGltaXRzIHVzIGluIHRoZSBhYmlsaXR5IHRvCj4+IHNwYXduIGV2ZW50ZmQncyBvbiBQSU8g
cG9ydHMgd2hpY2ggZG9lc24ndCB3b3JrIHdpdGggdGhpcyBhcHByb2FjaC4gIEluc3RlYWQsCj4+
IGxldCdzIG1vZGVsIGl0IG1vcmUgZWFzaWx5LiBMZXQncyBqdXN0IG1hcCB0aGUgUElPIG1lbW9y
eSByZWdpb24gaW50byBNTUlPCj4+IHNwYWNlLgo+PiAKPj4gRm9yIHRoaXMgdG8gd29yaywgd2Ug
bmVlZCB0byBnZXQgcmlkIG9mIGFsbCBvbGRfcG9ydGlvIHN0cnVjdCB1c2VycywgYXMgdGhleQo+
PiBicmVhayB3aXRoIHRoaXMgYXBwcm9hY2guIFRoaXMgaXMgd2hhdCB0aGlzIHBhdGNoIHNldCBk
b2VzLgo+IAo+IExvb2tzIHNlbnNpYmxlIHRvIG1lIGFzIGZhciBhcyByZXZpZXdlZCwgYnV0IEkn
bSBtaXNzaW5nIGEgcGF0Y2ggMTMgdGhhdAo+IGFjdHVhbGx5IHJpcHMgb3V0IG9sZF9wb3J0aW8g
YWZ0ZXJ3YXJkcy4gOikKCkknbGwgbGVhdmUgdGhhdCBhcyBhbiBleGVyY2lzZSBmb3IgdGhlIHJl
YWRlciA6KQoKQWxleAoKPiAKPiBBbmRyZWFzCj4gCj4+IEl0IGFsc28gY29udmVydHMKPj4gdGhl
IGU1MDAgbWFjaGluZXMgYW5kIHNQQVBSIHRvIHRoZSBuZXcgbWVtb3J5IHJlZ2lvbiBtb2RlbC4K
Pj4gCj4+IAo+PiBBbGV4Cj4gCj4gLS0gCj4gU1VTRSBMSU5VWCBQcm9kdWN0cyBHbWJILCBNYXhm
ZWxkc3RyLiA1LCA5MDQwOSBOw7xybmJlcmcsIEdlcm1hbnkKPiBHRjogSmVmZiBIYXduLCBKZW5u
aWZlciBHdWlsZCwgRmVsaXggSW1lbmTDtnJmZmVyOyBIUkIgMTY3NDYgQUcgTsO8cm5iZXJnCgpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwg
bWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3Jn
L3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Mon Oct 08 16:32:34 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 16:32:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLGFY-0007uc-ON; Mon, 08 Oct 2012 16:32:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLGFW-0007uT-M7
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 16:32:10 +0000
Received: from [85.158.143.35:65044] by server-1.bemta-4.messagelabs.com id
	51/8B-05684-90003705; Mon, 08 Oct 2012 16:32:09 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-2.tower-21.messagelabs.com!1349713928!10478620!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.2 required=7.0 tests=MIME_QP_LONG_LINE
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28129 invoked from network); 8 Oct 2012 16:32:08 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 16:32:08 -0000
Received: from relay2.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id B8023927A5;
	Mon,  8 Oct 2012 18:32:05 +0200 (CEST)
References: <1349699033-6703-1-git-send-email-agraf@suse.de>
	<5072FCB9.80606@suse.de>
In-Reply-To: <5072FCB9.80606@suse.de>
Mime-Version: 1.0 (1.0)
Message-Id: 
X-Mailer: iPhone Mail (9B206)
From: Alexander Graf 
Date: Mon, 8 Oct 2012 18:32:27 +0200
To: =?utf-8?Q?Andreas_F=C3=A4rber?= 
Cc: Anthony Liguori ,
	"xen-devel@lists.xensource.com" ,
	Stefano Stabellini ,
	qemu-devel qemu-devel ,
	"qemu-ppc@nongnu.org List" ,
	Avi Kivity , Scott Wood ,
	David Gibson 
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 00/14] Remove old_portio users
	for memory region PIO mapping
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

CgpPbiAwOC4xMC4yMDEyLCBhdCAxODoxOCwgQW5kcmVhcyBGw6RyYmVyIDxhZmFlcmJlckBzdXNl
LmRlPiB3cm90ZToKCj4gQW0gMDguMTAuMjAxMiAxNDoyMywgc2NocmllYiBBbGV4YW5kZXIgR3Jh
ZjoKPj4gV2hlbiBydW5uaW5nIG9uIFBvd2VyUEMsIHdlIGRvbid0IGhhdmUgbmF0aXZlIFBJTyBz
dXBwb3J0LiBUaGVyZSBhcmUgYSBmZXcgaGFja3MKPj4gYXJvdW5kIHRvIGVuYWJsZSBQSU8gYWNj
ZXNzIG9uIFBvd2VyUEMgbmV2ZXJ0aGVsZXNzLgo+PiAKPj4gVGhlIG1vc3QgdHlwaWNhbCBvbmUg
aXMgdGhlIGlzYS1tbWlvIGRldmljZS4gSXQgdGFrZXMgTU1JTyByZXF1ZXN0cyBhbmQgY29udmVy
dHMKPj4gdGhlbSB0byBQSU8gcmVxdWVzdHMgb24gdGhlIChRRU1VIGludGVybmFsKSBQSU8gYnVz
Lgo+PiAKPj4gVGhpcyBob3dldmVyIGlzIG5vdCBob3cgcmVhbCBoYXJkd2FyZSB3b3JrcyBhbmQg
aXQgbGltaXRzIHVzIGluIHRoZSBhYmlsaXR5IHRvCj4+IHNwYXduIGV2ZW50ZmQncyBvbiBQSU8g
cG9ydHMgd2hpY2ggZG9lc24ndCB3b3JrIHdpdGggdGhpcyBhcHByb2FjaC4gIEluc3RlYWQsCj4+
IGxldCdzIG1vZGVsIGl0IG1vcmUgZWFzaWx5LiBMZXQncyBqdXN0IG1hcCB0aGUgUElPIG1lbW9y
eSByZWdpb24gaW50byBNTUlPCj4+IHNwYWNlLgo+PiAKPj4gRm9yIHRoaXMgdG8gd29yaywgd2Ug
bmVlZCB0byBnZXQgcmlkIG9mIGFsbCBvbGRfcG9ydGlvIHN0cnVjdCB1c2VycywgYXMgdGhleQo+
PiBicmVhayB3aXRoIHRoaXMgYXBwcm9hY2guIFRoaXMgaXMgd2hhdCB0aGlzIHBhdGNoIHNldCBk
b2VzLgo+IAo+IExvb2tzIHNlbnNpYmxlIHRvIG1lIGFzIGZhciBhcyByZXZpZXdlZCwgYnV0IEkn
bSBtaXNzaW5nIGEgcGF0Y2ggMTMgdGhhdAo+IGFjdHVhbGx5IHJpcHMgb3V0IG9sZF9wb3J0aW8g
YWZ0ZXJ3YXJkcy4gOikKCkknbGwgbGVhdmUgdGhhdCBhcyBhbiBleGVyY2lzZSBmb3IgdGhlIHJl
YWRlciA6KQoKQWxleAoKPiAKPiBBbmRyZWFzCj4gCj4+IEl0IGFsc28gY29udmVydHMKPj4gdGhl
IGU1MDAgbWFjaGluZXMgYW5kIHNQQVBSIHRvIHRoZSBuZXcgbWVtb3J5IHJlZ2lvbiBtb2RlbC4K
Pj4gCj4+IAo+PiBBbGV4Cj4gCj4gLS0gCj4gU1VTRSBMSU5VWCBQcm9kdWN0cyBHbWJILCBNYXhm
ZWxkc3RyLiA1LCA5MDQwOSBOw7xybmJlcmcsIEdlcm1hbnkKPiBHRjogSmVmZiBIYXduLCBKZW5u
aWZlciBHdWlsZCwgRmVsaXggSW1lbmTDtnJmZmVyOyBIUkIgMTY3NDYgQUcgTsO8cm5iZXJnCgpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwg
bWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3Jn
L3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Mon Oct 08 16:44:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 16:44:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLGRL-0000FX-L8; Mon, 08 Oct 2012 16:44:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLGRK-0000FP-Fx
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 16:44:22 +0000
Received: from [85.158.137.99:26237] by server-4.bemta-3.messagelabs.com id
	21/0D-14155-5E203705; Mon, 08 Oct 2012 16:44:21 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1349714659!20731365!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20350 invoked from network); 8 Oct 2012 16:44:20 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 16:44:20 -0000
Received: by mail-ie0-f173.google.com with SMTP id 17so250423iea.32
	for ; Mon, 08 Oct 2012 09:44:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=jJZ2fBenpmHg8Q9/e26AYx/R2HwFP5OF6Xuuu3eZUkc=;
	b=xM/451om8OhMS6JDCjxbXbbW/sSPOYj0XWzjGpdhXMC43vYBegQQeuFG5xAuZjhP6v
	W1yzPrepsJI+VZn7VGIC2v9zIHe7TwgWe7jpQ+wqD5K+fLeWTiekEV/HPwjv9/6HjgLY
	a+WpD8dSFvegGdE+gSeW3HUHhyy7j079/JOtIolcQnVK7D9CnENG6QKzTziHtsYGAntX
	KkkxmOIHxCuQFTV/W+olAAFrxYHxj+whVU5mATw6jP00WAF/4tjv61m+yzyP4TWKqtq5
	hnZJIOO4jrxxyhylpaZbhVLcJfbh4NvN2WzfJAV9erHc8XBZaJshnHUcMHar7yzOkzo1
	ta1A==
Received: by 10.43.97.8 with SMTP id ci8mr13520903icc.28.1349714658887; Mon,
	08 Oct 2012 09:44:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.97.164 with HTTP; Mon, 8 Oct 2012 09:43:48 -0700 (PDT)
In-Reply-To: 
References: <1343061718-6911-1-git-send-email-anthony.perard@citrix.com>
	
From: Anthony PERARD 
Date: Mon, 8 Oct 2012 17:43:48 +0100
X-Google-Sender-Auth: utSvcIelVNvPAvfun2k-xyOGZAw
Message-ID: 
To: Ian Jackson 
Cc: Stefano Stabellini ,
	Xen Devel 
Subject: Re: [Xen-devel] [PATCH V2] qemu-xen-traditionnal,
 Fix dirty logging during migration.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

This patch have never been applied.

Regards,

On Tue, Jul 24, 2012 at 11:19 AM, Stefano Stabellini
 wrote:
> On Mon, 23 Jul 2012, Anthony PERARD wrote:
>> This moves the xen_modified_memory call from cpu_physical_memory_map to
>> cpu_physical_memory_unmap because the memory could be migrated before the
>> device model have written to it.
>>
>> But because we need to know the guest address and to avoid rewriting a new
>> function, the call is moved to qemu_invalidate_entry. So this later has to new
>> parameters, the length of the mapping and if it was a write.
>>
>> Signed-off-by: Anthony PERARD 
>
>
> Acked-by: Stefano Stabellini 
>
>
>> Change since first version:
>>   - No more extra function to get the guest address from a pointer.
>>   > The xc_hvm_modied_memory is moved to qemu_invalidate_entry
>>
>>  hw/xen_machine_fv.c |   16 ++++++++++++++--
>>  i386-dm/exec-dm.c   |    6 +-----
>>  qemu-xen.h          |    2 +-
>>  3 files changed, 16 insertions(+), 8 deletions(-)
>>
>> diff --git a/hw/xen_machine_fv.c b/hw/xen_machine_fv.c
>> index fdad42a..2bb44e0 100644
>> --- a/hw/xen_machine_fv.c
>> +++ b/hw/xen_machine_fv.c
>> @@ -174,7 +174,8 @@ uint8_t *qemu_map_cache(target_phys_addr_t phys_addr, uint8_t lock)
>>      return last_address_vaddr + address_offset;
>>  }
>>
>> -void qemu_invalidate_entry(uint8_t *buffer)
>> +void qemu_invalidate_entry(uint8_t *buffer, target_phys_addr_t access_len,
>> +                           int was_written)
>>  {
>>      struct map_cache *entry = NULL, *pentry = NULL;
>>      struct map_cache_rev *reventry;
>> @@ -210,6 +211,17 @@ void qemu_invalidate_entry(uint8_t *buffer)
>>          fprintf(logfile, "Trying to unmap address %p that is not in the mapcache!\n", buffer);
>>          return;
>>      }
>> +    if (xen_logdirty_enable && was_written) {
>> +        unsigned long addr = (paddr_index << MCACHE_BUCKET_SHIFT)
>> +            + ((unsigned long)buffer) - ((unsigned long)entry->vaddr_base);
>> +        if (access_len == 0)
>> +            access_len = TARGET_PAGE_SIZE;
>> +        xc_hvm_modified_memory(xc_handle, domid,
>> +            addr >> TARGET_PAGE_BITS,
>> +            ((addr + access_len + TARGET_PAGE_SIZE - 1) >> TARGET_PAGE_BITS)
>> +            - (addr >> TARGET_PAGE_BITS));
>> +    }
>> +
>>      entry->lock--;
>>      if (entry->lock > 0 || pentry == NULL)
>>          return;
>> @@ -265,7 +277,7 @@ uint8_t *qemu_map_cache(target_phys_addr_t phys_addr, uint8_t lock)
>>
>>  void qemu_invalidate_map_cache(void) {};
>>
>> -void qemu_invalidate_entry(uint8_t *buffer) {};
>> +void qemu_invalidate_entry(uint8_t *buffer, target_phys_addr_t len, int w) {};
>>
>>  #endif /* defined(MAPCACHE) */
>>
>> diff --git a/i386-dm/exec-dm.c b/i386-dm/exec-dm.c
>> index 96274d9..493146b 100644
>> --- a/i386-dm/exec-dm.c
>> +++ b/i386-dm/exec-dm.c
>> @@ -820,10 +820,6 @@ void *cpu_physical_memory_map(target_phys_addr_t addr,
>>      if ((*plen) > l)
>>          *plen = l;
>>  #endif
>> -    if (xen_logdirty_enable)
>> -        xc_hvm_modified_memory(xc_handle, domid, addr >> TARGET_PAGE_BITS,
>> -                ((addr + l + TARGET_PAGE_SIZE - 1) >> TARGET_PAGE_BITS)
>> -                    - (addr >> TARGET_PAGE_BITS));
>>
>>      return qemu_map_cache(addr, 1);
>>  }
>> @@ -835,6 +831,6 @@ void *cpu_physical_memory_map(target_phys_addr_t addr,
>>  void cpu_physical_memory_unmap(void *buffer, target_phys_addr_t len,
>>                                 int is_write, target_phys_addr_t access_len)
>>  {
>> -    qemu_invalidate_entry(buffer);
>> +    qemu_invalidate_entry(buffer, access_len, is_write);
>>      cpu_notify_map_clients();
>>  }
>> diff --git a/qemu-xen.h b/qemu-xen.h
>> index d50c89f..54159bf 100644
>> --- a/qemu-xen.h
>> +++ b/qemu-xen.h
>> @@ -28,7 +28,7 @@ extern int vga_ram_size;
>>  #endif
>>
>>  uint8_t *qemu_map_cache(target_phys_addr_t phys_addr, uint8_t lock);
>> -void     qemu_invalidate_entry(uint8_t *buffer);
>> +void     qemu_invalidate_entry(uint8_t *buffer, target_phys_addr_t len, int w);
>>  void     qemu_invalidate_map_cache(void);
>>
>>  #define mapcache_lock()   ((void)0)
>> --
>> Anthony PERARD
>>


-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 16:44:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 16:44:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLGRL-0000FX-L8; Mon, 08 Oct 2012 16:44:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLGRK-0000FP-Fx
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 16:44:22 +0000
Received: from [85.158.137.99:26237] by server-4.bemta-3.messagelabs.com id
	21/0D-14155-5E203705; Mon, 08 Oct 2012 16:44:21 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1349714659!20731365!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20350 invoked from network); 8 Oct 2012 16:44:20 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 16:44:20 -0000
Received: by mail-ie0-f173.google.com with SMTP id 17so250423iea.32
	for ; Mon, 08 Oct 2012 09:44:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=jJZ2fBenpmHg8Q9/e26AYx/R2HwFP5OF6Xuuu3eZUkc=;
	b=xM/451om8OhMS6JDCjxbXbbW/sSPOYj0XWzjGpdhXMC43vYBegQQeuFG5xAuZjhP6v
	W1yzPrepsJI+VZn7VGIC2v9zIHe7TwgWe7jpQ+wqD5K+fLeWTiekEV/HPwjv9/6HjgLY
	a+WpD8dSFvegGdE+gSeW3HUHhyy7j079/JOtIolcQnVK7D9CnENG6QKzTziHtsYGAntX
	KkkxmOIHxCuQFTV/W+olAAFrxYHxj+whVU5mATw6jP00WAF/4tjv61m+yzyP4TWKqtq5
	hnZJIOO4jrxxyhylpaZbhVLcJfbh4NvN2WzfJAV9erHc8XBZaJshnHUcMHar7yzOkzo1
	ta1A==
Received: by 10.43.97.8 with SMTP id ci8mr13520903icc.28.1349714658887; Mon,
	08 Oct 2012 09:44:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.97.164 with HTTP; Mon, 8 Oct 2012 09:43:48 -0700 (PDT)
In-Reply-To: 
References: <1343061718-6911-1-git-send-email-anthony.perard@citrix.com>
	
From: Anthony PERARD 
Date: Mon, 8 Oct 2012 17:43:48 +0100
X-Google-Sender-Auth: utSvcIelVNvPAvfun2k-xyOGZAw
Message-ID: 
To: Ian Jackson 
Cc: Stefano Stabellini ,
	Xen Devel 
Subject: Re: [Xen-devel] [PATCH V2] qemu-xen-traditionnal,
 Fix dirty logging during migration.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

This patch have never been applied.

Regards,

On Tue, Jul 24, 2012 at 11:19 AM, Stefano Stabellini
 wrote:
> On Mon, 23 Jul 2012, Anthony PERARD wrote:
>> This moves the xen_modified_memory call from cpu_physical_memory_map to
>> cpu_physical_memory_unmap because the memory could be migrated before the
>> device model have written to it.
>>
>> But because we need to know the guest address and to avoid rewriting a new
>> function, the call is moved to qemu_invalidate_entry. So this later has to new
>> parameters, the length of the mapping and if it was a write.
>>
>> Signed-off-by: Anthony PERARD 
>
>
> Acked-by: Stefano Stabellini 
>
>
>> Change since first version:
>>   - No more extra function to get the guest address from a pointer.
>>   > The xc_hvm_modied_memory is moved to qemu_invalidate_entry
>>
>>  hw/xen_machine_fv.c |   16 ++++++++++++++--
>>  i386-dm/exec-dm.c   |    6 +-----
>>  qemu-xen.h          |    2 +-
>>  3 files changed, 16 insertions(+), 8 deletions(-)
>>
>> diff --git a/hw/xen_machine_fv.c b/hw/xen_machine_fv.c
>> index fdad42a..2bb44e0 100644
>> --- a/hw/xen_machine_fv.c
>> +++ b/hw/xen_machine_fv.c
>> @@ -174,7 +174,8 @@ uint8_t *qemu_map_cache(target_phys_addr_t phys_addr, uint8_t lock)
>>      return last_address_vaddr + address_offset;
>>  }
>>
>> -void qemu_invalidate_entry(uint8_t *buffer)
>> +void qemu_invalidate_entry(uint8_t *buffer, target_phys_addr_t access_len,
>> +                           int was_written)
>>  {
>>      struct map_cache *entry = NULL, *pentry = NULL;
>>      struct map_cache_rev *reventry;
>> @@ -210,6 +211,17 @@ void qemu_invalidate_entry(uint8_t *buffer)
>>          fprintf(logfile, "Trying to unmap address %p that is not in the mapcache!\n", buffer);
>>          return;
>>      }
>> +    if (xen_logdirty_enable && was_written) {
>> +        unsigned long addr = (paddr_index << MCACHE_BUCKET_SHIFT)
>> +            + ((unsigned long)buffer) - ((unsigned long)entry->vaddr_base);
>> +        if (access_len == 0)
>> +            access_len = TARGET_PAGE_SIZE;
>> +        xc_hvm_modified_memory(xc_handle, domid,
>> +            addr >> TARGET_PAGE_BITS,
>> +            ((addr + access_len + TARGET_PAGE_SIZE - 1) >> TARGET_PAGE_BITS)
>> +            - (addr >> TARGET_PAGE_BITS));
>> +    }
>> +
>>      entry->lock--;
>>      if (entry->lock > 0 || pentry == NULL)
>>          return;
>> @@ -265,7 +277,7 @@ uint8_t *qemu_map_cache(target_phys_addr_t phys_addr, uint8_t lock)
>>
>>  void qemu_invalidate_map_cache(void) {};
>>
>> -void qemu_invalidate_entry(uint8_t *buffer) {};
>> +void qemu_invalidate_entry(uint8_t *buffer, target_phys_addr_t len, int w) {};
>>
>>  #endif /* defined(MAPCACHE) */
>>
>> diff --git a/i386-dm/exec-dm.c b/i386-dm/exec-dm.c
>> index 96274d9..493146b 100644
>> --- a/i386-dm/exec-dm.c
>> +++ b/i386-dm/exec-dm.c
>> @@ -820,10 +820,6 @@ void *cpu_physical_memory_map(target_phys_addr_t addr,
>>      if ((*plen) > l)
>>          *plen = l;
>>  #endif
>> -    if (xen_logdirty_enable)
>> -        xc_hvm_modified_memory(xc_handle, domid, addr >> TARGET_PAGE_BITS,
>> -                ((addr + l + TARGET_PAGE_SIZE - 1) >> TARGET_PAGE_BITS)
>> -                    - (addr >> TARGET_PAGE_BITS));
>>
>>      return qemu_map_cache(addr, 1);
>>  }
>> @@ -835,6 +831,6 @@ void *cpu_physical_memory_map(target_phys_addr_t addr,
>>  void cpu_physical_memory_unmap(void *buffer, target_phys_addr_t len,
>>                                 int is_write, target_phys_addr_t access_len)
>>  {
>> -    qemu_invalidate_entry(buffer);
>> +    qemu_invalidate_entry(buffer, access_len, is_write);
>>      cpu_notify_map_clients();
>>  }
>> diff --git a/qemu-xen.h b/qemu-xen.h
>> index d50c89f..54159bf 100644
>> --- a/qemu-xen.h
>> +++ b/qemu-xen.h
>> @@ -28,7 +28,7 @@ extern int vga_ram_size;
>>  #endif
>>
>>  uint8_t *qemu_map_cache(target_phys_addr_t phys_addr, uint8_t lock);
>> -void     qemu_invalidate_entry(uint8_t *buffer);
>> +void     qemu_invalidate_entry(uint8_t *buffer, target_phys_addr_t len, int w);
>>  void     qemu_invalidate_map_cache(void);
>>
>>  #define mapcache_lock()   ((void)0)
>> --
>> Anthony PERARD
>>


-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 16:59:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 16:59:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLGfQ-0000XZ-D3; Mon, 08 Oct 2012 16:58:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLGfO-0000XU-72
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 16:58:54 +0000
Received: from [85.158.139.211:64590] by server-14.bemta-5.messagelabs.com id
	DD/C2-31065-D4603705; Mon, 08 Oct 2012 16:58:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1349715532!21478584!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMzNDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16096 invoked from network); 8 Oct 2012 16:58:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 16:58:52 -0000
X-IronPort-AV: E=Sophos;i="4.80,555,1344211200"; d="scan'208";a="15008177"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 16:58:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Mon, 8 Oct 2012 17:58:52 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TLGfM-0001hD-1V;
	Mon, 08 Oct 2012 16:58:52 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TLGfL-00021z-UW;
	Mon, 08 Oct 2012 17:58:51 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Mon, 8 Oct 2012 17:58:51 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 13933: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13933 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13933/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 13915

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13915
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13915

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 linux                24e842ae6cb8179126246ebcbfc477b36a7b8719
baseline version:
 linux                b9a7985a8d9ca00d8ce977756fde1306c9ab1e41

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 24e842ae6cb8179126246ebcbfc477b36a7b8719
Author: Greg Kroah-Hartman 
Date:   Sun Oct 7 08:28:29 2012 -0700

    Linux 3.0.45

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 16:59:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 16:59:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLGfQ-0000XZ-D3; Mon, 08 Oct 2012 16:58:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLGfO-0000XU-72
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 16:58:54 +0000
Received: from [85.158.139.211:64590] by server-14.bemta-5.messagelabs.com id
	DD/C2-31065-D4603705; Mon, 08 Oct 2012 16:58:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1349715532!21478584!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMzNDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16096 invoked from network); 8 Oct 2012 16:58:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 16:58:52 -0000
X-IronPort-AV: E=Sophos;i="4.80,555,1344211200"; d="scan'208";a="15008177"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 16:58:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Mon, 8 Oct 2012 17:58:52 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TLGfM-0001hD-1V;
	Mon, 08 Oct 2012 16:58:52 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TLGfL-00021z-UW;
	Mon, 08 Oct 2012 17:58:51 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Mon, 8 Oct 2012 17:58:51 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 13933: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13933 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13933/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 13915

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13915
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13915

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 linux                24e842ae6cb8179126246ebcbfc477b36a7b8719
baseline version:
 linux                b9a7985a8d9ca00d8ce977756fde1306c9ab1e41

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 24e842ae6cb8179126246ebcbfc477b36a7b8719
Author: Greg Kroah-Hartman 
Date:   Sun Oct 7 08:28:29 2012 -0700

    Linux 3.0.45

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 17:10:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 17:10:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLGqG-0000wz-Qt; Mon, 08 Oct 2012 17:10:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLGqF-0000ws-GY
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 17:10:07 +0000
Received: from [85.158.138.51:42708] by server-6.bemta-3.messagelabs.com id
	06/2E-11085-EE803705; Mon, 08 Oct 2012 17:10:06 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-7.tower-174.messagelabs.com!1349716205!24674973!1
X-Originating-IP: [192.134.164.82]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8473 invoked from network); 8 Oct 2012 17:10:05 -0000
Received: from mail1-relais-roc.national.inria.fr (HELO
	mail1-relais-roc.national.inria.fr) (192.134.164.82)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 17:10:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,555,1344204000"; d="scan'208";a="176325472"
Received: from unknown (HELO type.ipv6) ([193.50.110.124])
	by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA;
	08 Oct 2012 19:10:04 +0200
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from )
	id 1TLGqC-0008S1-Cg; Mon, 08 Oct 2012 19:10:04 +0200
Date: Mon, 8 Oct 2012 19:10:04 +0200
From: Samuel Thibault 
To: Matthew Fioravante 
Message-ID: <20121008171004.GH5985@type.bordeaux.inria.fr>
Mail-Followup-To: Samuel Thibault ,
	Matthew Fioravante ,
	"xen-devel@lists.xensource.com" 
References: <50579C5F.5040004@jhuapl.edu>
	<20120917224619.GO5110@type.youpi.perso.aquilenet.fr>
	<506F209E.2040902@jhuapl.edu>
	<20121008080500.GA5985@type.bordeaux.inria.fr>
	<5072E470.1060404@jhuapl.edu>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5072E470.1060404@jhuapl.edu>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 2/8] add posix
 io to blkfront
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Matthew Fioravante, le Mon 08 Oct 2012 10:34:24 -0400, a =E9crit :
> Sometimes n comes out to be BLKIF_MAX_SEGEMENTS_PER_REQUEST +1.
> =

> This happens when your buffer address is sector aligned (512k), but
> not page aligned (4096k).
> So we can either optimize yet again if address is page
> aligned

Ah, right. Well, I'd say it's worth making the effort to test against
that, i.e. (untested)

else {
	if (count >=3D BLKIF_MAX_SEGMENTS_PER_REQUEST*PAGE_SIZE
	    && (!(buf & ~(PAGE_SIZE-1))))
	    	/* page-aligned */
		bytes =3D BLKIF_MAX_SEGMENTS_PER_REQUEST*PAGE_SIZE;
	else if (count >=3D (BLKIF_MAX_SEGMENTS_PER_REQUEST-1)*PAGE_SIZE)
	    	/* only sector-aligned, will have to realign */
		bytes =3D (BLKIF_MAX_SEGMENTS_PER_REQUEST-1)*PAGE_SIZE;
	else
		bytes =3D count & ~(blocksize - 1);
    }
}

> Is the page math being done above that assertion correct?

I believe so.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 17:10:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 17:10:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLGqG-0000wz-Qt; Mon, 08 Oct 2012 17:10:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLGqF-0000ws-GY
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 17:10:07 +0000
Received: from [85.158.138.51:42708] by server-6.bemta-3.messagelabs.com id
	06/2E-11085-EE803705; Mon, 08 Oct 2012 17:10:06 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-7.tower-174.messagelabs.com!1349716205!24674973!1
X-Originating-IP: [192.134.164.82]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8473 invoked from network); 8 Oct 2012 17:10:05 -0000
Received: from mail1-relais-roc.national.inria.fr (HELO
	mail1-relais-roc.national.inria.fr) (192.134.164.82)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 17:10:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,555,1344204000"; d="scan'208";a="176325472"
Received: from unknown (HELO type.ipv6) ([193.50.110.124])
	by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA;
	08 Oct 2012 19:10:04 +0200
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from )
	id 1TLGqC-0008S1-Cg; Mon, 08 Oct 2012 19:10:04 +0200
Date: Mon, 8 Oct 2012 19:10:04 +0200
From: Samuel Thibault 
To: Matthew Fioravante 
Message-ID: <20121008171004.GH5985@type.bordeaux.inria.fr>
Mail-Followup-To: Samuel Thibault ,
	Matthew Fioravante ,
	"xen-devel@lists.xensource.com" 
References: <50579C5F.5040004@jhuapl.edu>
	<20120917224619.GO5110@type.youpi.perso.aquilenet.fr>
	<506F209E.2040902@jhuapl.edu>
	<20121008080500.GA5985@type.bordeaux.inria.fr>
	<5072E470.1060404@jhuapl.edu>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5072E470.1060404@jhuapl.edu>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 2/8] add posix
 io to blkfront
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Matthew Fioravante, le Mon 08 Oct 2012 10:34:24 -0400, a =E9crit :
> Sometimes n comes out to be BLKIF_MAX_SEGEMENTS_PER_REQUEST +1.
> =

> This happens when your buffer address is sector aligned (512k), but
> not page aligned (4096k).
> So we can either optimize yet again if address is page
> aligned

Ah, right. Well, I'd say it's worth making the effort to test against
that, i.e. (untested)

else {
	if (count >=3D BLKIF_MAX_SEGMENTS_PER_REQUEST*PAGE_SIZE
	    && (!(buf & ~(PAGE_SIZE-1))))
	    	/* page-aligned */
		bytes =3D BLKIF_MAX_SEGMENTS_PER_REQUEST*PAGE_SIZE;
	else if (count >=3D (BLKIF_MAX_SEGMENTS_PER_REQUEST-1)*PAGE_SIZE)
	    	/* only sector-aligned, will have to realign */
		bytes =3D (BLKIF_MAX_SEGMENTS_PER_REQUEST-1)*PAGE_SIZE;
	else
		bytes =3D count & ~(blocksize - 1);
    }
}

> Is the page math being done above that assertion correct?

I believe so.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 17:16:44 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 17:16:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLGwM-00017t-M4; Mon, 08 Oct 2012 17:16:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLGwK-00017o-9o
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 17:16:24 +0000
Received: from [85.158.137.99:61403] by server-6.bemta-3.messagelabs.com id
	4D/26-11085-76A03705; Mon, 08 Oct 2012 17:16:23 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-15.tower-217.messagelabs.com!1349716581!18379514!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2831 invoked from network); 8 Oct 2012 17:16:22 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-15.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Oct 2012 17:16:22 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.154537995;
	Mon, 08 Oct 2012 13:16:06 -0400
Message-ID: <50730A02.2020208@jhuapl.edu>
Date: Mon, 08 Oct 2012 13:14:42 -0400
From: Matthew Fioravante 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell 
References: <1349460077-13770-1-git-send-email-matthew.fioravante@jhuapl.edu>
	<1349696888.18008.126.camel@zakaz.uk.xensource.com>
	<1349703379.21847.9.camel@zakaz.uk.xensource.com>
In-Reply-To: <1349703379.21847.9.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.4
Cc: "samuel.thibault@ens-lyons.org" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH vtpm v2 01/12] Add ioread/iowrite functions
 to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0550747992294590187=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============0550747992294590187==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010800000208070407050807"

This is a cryptographically signed message in MIME format.

--------------ms010800000208070407050807
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 10/08/2012 09:36 AM, Ian Campbell wrote:
> On Mon, 2012-10-08 at 12:48 +0100, Ian Campbell wrote:
>> I was about to apply nos. 1 & 3-7 but there was a build error:
>>         In file included from mini-os.c:23:
>>         ../grub-upstream/netboot/etherboot.h:526: error: conflicting t=
ypes for =E2=80=98inet_aton=E2=80=99
>>         /local/scratch/ianc/devel/committer.git/stubdom/lwip-x86_64/sr=
c/include/ipv4/lwip/inet.h:44: note: previous declaration of =E2=80=98ine=
t_aton=E2=80=99 was here
>>         mini-os.c: In function =E2=80=98load_module=E2=80=99:
>>         mini-os.c:244: warning: statement with no effect
>>         mini-os.c: In function =E2=80=98main=E2=80=99:
>>         mini-os.c:747: warning: cast from pointer to integer of differ=
ent size
>>         make[2]: *** [/local/scratch/ianc/devel/committer.git/stubdom/=
grub-x86_64/mini-os.o] Error 1
>>         make[2]: *** Waiting for unfinished jobs....
> This was down to #6 "minios: add select definition to sys/time.h when
> HAVE_LIBC is defined" -- which I guess caused an indirect inclusion of
> the problematic header? I'm compiling on Debian Squeeze BTW.
It looks like this is happening because
extras/mini-os/include/posix/sys/select.h does a #include .

lwip.sockets.h defines struct timeval if LWIP_TIMEVAL_PRIVATE is 1,
which in extra/mini-os/include/lwipopts.h is set to 0. So the result is
we always use the struct timeval in extras/mini-os/sys/time.h and the
lwip/sockets.h include is redundant.

I think the correct solution is to remove the lwip include. Unless for
some reason people want to allow for setting LWIP_TIMEVAL_PRIVATE to 1
mini-os, but if we want to allow that case then extras/sys/time.h needs
to also be patched.

I tested removing it and the build error goes away. I'll send a patch
shortly.
>
> So I have gone ahead and committed 1, 3-5 & 7, IOW:
> minios: setup fpu and sse in mini-os
> minios: add CONFIG_XC conditional
> minios: Disable the mfn_is_ram() check, it doesn't work correctly on al=
l
> minios: Add endian, byteswap, and wordsize macros to mini-os
> minios: Add ioread/iowrite functions to mini-os
>
>> There was also a slew of warnings -- but I think many of them might be=

>> normal for a stubdom build (I'll have to check).
> These turned out to be pre-existing.
>
>> BTW I was skipping, this time round:
>>
>> #2 because Samuel seemed to have some additional thoughts this morning=
=2E
>>
>> #8 because I wanted to have another quick read through before I applie=
d
>> it.
>>
>> #9 and #10 are already applied.
>>
>> #11 hasn't been acked, although I see George has reviewed it at least
>> somewhat. Hopefully one or the other of us (or someone else) will find=

>> the time shortly.
>>
>> #12 is already applied
>>
>> Ian.
>>
>> On Fri, 2012-10-05 at 19:01 +0100, Matthew Fioravante wrote:
>>> This patch adds iowritexx() and ioreadxx() functions for interacting
>>> with hardware memory to mini-os. The functions are available in a hea=
der
>>> iorw.h
>>>
>>> Signed-off-by: Matthew Fioravante 
>>> Acked-by: Samuel Thibault 
>>> Reviewed-by: George Dunlap 
>>>
>>> diff --git a/extras/mini-os/arch/x86/iorw.c b/extras/mini-os/arch/x86=
/iorw.c
>>> new file mode 100644
>>> index 0000000..3080769
>>> --- /dev/null
>>> +++ b/extras/mini-os/arch/x86/iorw.c
>>> @@ -0,0 +1,35 @@
>>> +#include 
>>> +
>>> +void iowrite8(volatile void* addr, uint8_t val)
>>> +{
>>> +   *((volatile uint8_t*)addr) =3D val;
>>> +}
>>> +void iowrite16(volatile void* addr, uint16_t val)
>>> +{
>>> +   *((volatile uint16_t*)addr) =3D val;
>>> +}
>>> +void iowrite32(volatile void* addr, uint32_t val)
>>> +{
>>> +   *((volatile uint32_t*)addr) =3D val;
>>> +}
>>> +void iowrite64(volatile void* addr, uint64_t val)
>>> +{
>>> +   *((volatile uint64_t*)addr) =3D val;
>>> +}
>>> +
>>> +uint8_t ioread8(volatile void* addr)
>>> +{
>>> +   return *((volatile uint8_t*) addr);
>>> +}
>>> +uint16_t ioread16(volatile void* addr)
>>> +{
>>> +   return *((volatile uint16_t*) addr);
>>> +}
>>> +uint32_t ioread32(volatile void* addr)
>>> +{
>>> +   return *((volatile uint32_t*) addr);
>>> +}
>>> +uint64_t ioread64(volatile void* addr)
>>> +{
>>> +   return *((volatile uint64_t*) addr);
>>> +}
>>> diff --git a/extras/mini-os/include/iorw.h b/extras/mini-os/include/i=
orw.h
>>> new file mode 100644
>>> index 0000000..d5ec065
>>> --- /dev/null
>>> +++ b/extras/mini-os/include/iorw.h
>>> @@ -0,0 +1,16 @@
>>> +#ifndef MINIOS_IORW_H
>>> +#define MINIOS_IORW_H
>>> +
>>> +#include 
>>> +
>>> +void iowrite8(volatile void* addr, uint8_t val);
>>> +void iowrite16(volatile void* addr, uint16_t val);
>>> +void iowrite32(volatile void* addr, uint32_t val);
>>> +void iowrite64(volatile void* addr, uint64_t val);
>>> +
>>> +uint8_t ioread8(volatile void* addr);
>>> +uint16_t ioread16(volatile void* addr);
>>> +uint32_t ioread32(volatile void* addr);
>>> +uint64_t ioread64(volatile void* addr);
>>> +
>>> +#endif
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>



--------------ms010800000208070407050807
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMTAwODE3MTQ0MlowIwYJKoZIhvcNAQkEMRYEFA8uQuLZrgrCkDG2
QqKS+jR1X89rMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBa9DIYdVS29IxDRAR1lbtoufxVWNVKJ745
QWg8DEt1JtTJsrsnZ7LokFFhw4y3+hwOkGyJkgSo58iFjv76DucRe69/suEBgfMv7kY2Uv8Y
zziD+/t4pNamXt9ncbh7/7d4HyE4FVBsPLVhYhmicu1CgbGzicMqwmxONqmv4E2yEgAAAAAA
AA==
--------------ms010800000208070407050807--


--===============0550747992294590187==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0550747992294590187==--


From xen-devel-bounces@lists.xen.org Mon Oct 08 17:16:44 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 17:16:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLGwM-00017t-M4; Mon, 08 Oct 2012 17:16:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLGwK-00017o-9o
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 17:16:24 +0000
Received: from [85.158.137.99:61403] by server-6.bemta-3.messagelabs.com id
	4D/26-11085-76A03705; Mon, 08 Oct 2012 17:16:23 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-15.tower-217.messagelabs.com!1349716581!18379514!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2831 invoked from network); 8 Oct 2012 17:16:22 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-15.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Oct 2012 17:16:22 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.154537995;
	Mon, 08 Oct 2012 13:16:06 -0400
Message-ID: <50730A02.2020208@jhuapl.edu>
Date: Mon, 08 Oct 2012 13:14:42 -0400
From: Matthew Fioravante 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell 
References: <1349460077-13770-1-git-send-email-matthew.fioravante@jhuapl.edu>
	<1349696888.18008.126.camel@zakaz.uk.xensource.com>
	<1349703379.21847.9.camel@zakaz.uk.xensource.com>
In-Reply-To: <1349703379.21847.9.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.4
Cc: "samuel.thibault@ens-lyons.org" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH vtpm v2 01/12] Add ioread/iowrite functions
 to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0550747992294590187=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============0550747992294590187==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010800000208070407050807"

This is a cryptographically signed message in MIME format.

--------------ms010800000208070407050807
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 10/08/2012 09:36 AM, Ian Campbell wrote:
> On Mon, 2012-10-08 at 12:48 +0100, Ian Campbell wrote:
>> I was about to apply nos. 1 & 3-7 but there was a build error:
>>         In file included from mini-os.c:23:
>>         ../grub-upstream/netboot/etherboot.h:526: error: conflicting t=
ypes for =E2=80=98inet_aton=E2=80=99
>>         /local/scratch/ianc/devel/committer.git/stubdom/lwip-x86_64/sr=
c/include/ipv4/lwip/inet.h:44: note: previous declaration of =E2=80=98ine=
t_aton=E2=80=99 was here
>>         mini-os.c: In function =E2=80=98load_module=E2=80=99:
>>         mini-os.c:244: warning: statement with no effect
>>         mini-os.c: In function =E2=80=98main=E2=80=99:
>>         mini-os.c:747: warning: cast from pointer to integer of differ=
ent size
>>         make[2]: *** [/local/scratch/ianc/devel/committer.git/stubdom/=
grub-x86_64/mini-os.o] Error 1
>>         make[2]: *** Waiting for unfinished jobs....
> This was down to #6 "minios: add select definition to sys/time.h when
> HAVE_LIBC is defined" -- which I guess caused an indirect inclusion of
> the problematic header? I'm compiling on Debian Squeeze BTW.
It looks like this is happening because
extras/mini-os/include/posix/sys/select.h does a #include .

lwip.sockets.h defines struct timeval if LWIP_TIMEVAL_PRIVATE is 1,
which in extra/mini-os/include/lwipopts.h is set to 0. So the result is
we always use the struct timeval in extras/mini-os/sys/time.h and the
lwip/sockets.h include is redundant.

I think the correct solution is to remove the lwip include. Unless for
some reason people want to allow for setting LWIP_TIMEVAL_PRIVATE to 1
mini-os, but if we want to allow that case then extras/sys/time.h needs
to also be patched.

I tested removing it and the build error goes away. I'll send a patch
shortly.
>
> So I have gone ahead and committed 1, 3-5 & 7, IOW:
> minios: setup fpu and sse in mini-os
> minios: add CONFIG_XC conditional
> minios: Disable the mfn_is_ram() check, it doesn't work correctly on al=
l
> minios: Add endian, byteswap, and wordsize macros to mini-os
> minios: Add ioread/iowrite functions to mini-os
>
>> There was also a slew of warnings -- but I think many of them might be=

>> normal for a stubdom build (I'll have to check).
> These turned out to be pre-existing.
>
>> BTW I was skipping, this time round:
>>
>> #2 because Samuel seemed to have some additional thoughts this morning=
=2E
>>
>> #8 because I wanted to have another quick read through before I applie=
d
>> it.
>>
>> #9 and #10 are already applied.
>>
>> #11 hasn't been acked, although I see George has reviewed it at least
>> somewhat. Hopefully one or the other of us (or someone else) will find=

>> the time shortly.
>>
>> #12 is already applied
>>
>> Ian.
>>
>> On Fri, 2012-10-05 at 19:01 +0100, Matthew Fioravante wrote:
>>> This patch adds iowritexx() and ioreadxx() functions for interacting
>>> with hardware memory to mini-os. The functions are available in a hea=
der
>>> iorw.h
>>>
>>> Signed-off-by: Matthew Fioravante 
>>> Acked-by: Samuel Thibault 
>>> Reviewed-by: George Dunlap 
>>>
>>> diff --git a/extras/mini-os/arch/x86/iorw.c b/extras/mini-os/arch/x86=
/iorw.c
>>> new file mode 100644
>>> index 0000000..3080769
>>> --- /dev/null
>>> +++ b/extras/mini-os/arch/x86/iorw.c
>>> @@ -0,0 +1,35 @@
>>> +#include 
>>> +
>>> +void iowrite8(volatile void* addr, uint8_t val)
>>> +{
>>> +   *((volatile uint8_t*)addr) =3D val;
>>> +}
>>> +void iowrite16(volatile void* addr, uint16_t val)
>>> +{
>>> +   *((volatile uint16_t*)addr) =3D val;
>>> +}
>>> +void iowrite32(volatile void* addr, uint32_t val)
>>> +{
>>> +   *((volatile uint32_t*)addr) =3D val;
>>> +}
>>> +void iowrite64(volatile void* addr, uint64_t val)
>>> +{
>>> +   *((volatile uint64_t*)addr) =3D val;
>>> +}
>>> +
>>> +uint8_t ioread8(volatile void* addr)
>>> +{
>>> +   return *((volatile uint8_t*) addr);
>>> +}
>>> +uint16_t ioread16(volatile void* addr)
>>> +{
>>> +   return *((volatile uint16_t*) addr);
>>> +}
>>> +uint32_t ioread32(volatile void* addr)
>>> +{
>>> +   return *((volatile uint32_t*) addr);
>>> +}
>>> +uint64_t ioread64(volatile void* addr)
>>> +{
>>> +   return *((volatile uint64_t*) addr);
>>> +}
>>> diff --git a/extras/mini-os/include/iorw.h b/extras/mini-os/include/i=
orw.h
>>> new file mode 100644
>>> index 0000000..d5ec065
>>> --- /dev/null
>>> +++ b/extras/mini-os/include/iorw.h
>>> @@ -0,0 +1,16 @@
>>> +#ifndef MINIOS_IORW_H
>>> +#define MINIOS_IORW_H
>>> +
>>> +#include 
>>> +
>>> +void iowrite8(volatile void* addr, uint8_t val);
>>> +void iowrite16(volatile void* addr, uint16_t val);
>>> +void iowrite32(volatile void* addr, uint32_t val);
>>> +void iowrite64(volatile void* addr, uint64_t val);
>>> +
>>> +uint8_t ioread8(volatile void* addr);
>>> +uint16_t ioread16(volatile void* addr);
>>> +uint32_t ioread32(volatile void* addr);
>>> +uint64_t ioread64(volatile void* addr);
>>> +
>>> +#endif
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>



--------------ms010800000208070407050807
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMTAwODE3MTQ0MlowIwYJKoZIhvcNAQkEMRYEFA8uQuLZrgrCkDG2
QqKS+jR1X89rMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBa9DIYdVS29IxDRAR1lbtoufxVWNVKJ745
QWg8DEt1JtTJsrsnZ7LokFFhw4y3+hwOkGyJkgSo58iFjv76DucRe69/suEBgfMv7kY2Uv8Y
zziD+/t4pNamXt9ncbh7/7d4HyE4FVBsPLVhYhmicu1CgbGzicMqwmxONqmv4E2yEgAAAAAA
AA==
--------------ms010800000208070407050807--


--===============0550747992294590187==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0550747992294590187==--


From xen-devel-bounces@lists.xen.org Mon Oct 08 17:17:57 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 17:17:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLGxa-0001Bt-5K; Mon, 08 Oct 2012 17:17:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLGxZ-0001Bl-Ct
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 17:17:41 +0000
Received: from [85.158.137.99:2741] by server-15.bemta-3.messagelabs.com id
	1A/81-11584-4BA03705; Mon, 08 Oct 2012 17:17:40 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-217.messagelabs.com!1349716660!20763499!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NDUzNjQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NDUzNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 889 invoked from network); 8 Oct 2012 17:17:40 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-4.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 17:17:40 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk287sE5w=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-092-071.pools.arcor-ip.net [84.57.92.71])
	by smtp.strato.de (jored mo2) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id Z0639bo98GwHFL
	for ; Mon, 8 Oct 2012 19:17:40 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 41D6E183A7
	for ; Mon,  8 Oct 2012 19:17:39 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: de76ea76418f19248fd3e5541344a51c38c716ae
Message-Id: 
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 08 Oct 2012 19:17:38 +0200
From: Olaf Hering 
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] pygrub: correct typo in --args assignment
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering 
# Date 1349716567 -7200
# Node ID de76ea76418f19248fd3e5541344a51c38c716ae
# Parent  c9f621893a05e3e447ba6770f8ae912721712569
pygrub: correct typo in --args assignment

If pygrub was called with --args="some thing", then this string should
be append to the kernel command line.  But the last changeset
25941:795c493fe561 contained a typo, it assigns 'args' instead of 'arg'.

Rename the local variable which holds the string from the domain config
file to avoid further confusion.

Signed-off-by: Olaf Hering 

diff -r c9f621893a05 -r de76ea76418f tools/pygrub/src/pygrub
--- a/tools/pygrub/src/pygrub
+++ b/tools/pygrub/src/pygrub
@@ -585,7 +585,7 @@ def get_entry_idx(cf, entry):
 
     return None
 
-def run_grub(file, entry, fs, arg):
+def run_grub(file, entry, fs, cfg_args):
     global g
     global sel
 
@@ -622,8 +622,8 @@ def run_grub(file, entry, fs, arg):
         grubcfg["ramdisk"] = img.initrd[1]
     if img.args:
         grubcfg["args"] += img.args
-    if arg:
-        grubcfg["args"] += " " + args
+    if cfg_args:
+        grubcfg["args"] += " " + cfg_args
 
     return grubcfg
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 17:17:57 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 17:17:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLGxa-0001Bt-5K; Mon, 08 Oct 2012 17:17:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLGxZ-0001Bl-Ct
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 17:17:41 +0000
Received: from [85.158.137.99:2741] by server-15.bemta-3.messagelabs.com id
	1A/81-11584-4BA03705; Mon, 08 Oct 2012 17:17:40 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-217.messagelabs.com!1349716660!20763499!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NDUzNjQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NDUzNjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 889 invoked from network); 8 Oct 2012 17:17:40 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-4.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 17:17:40 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk287sE5w=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-092-071.pools.arcor-ip.net [84.57.92.71])
	by smtp.strato.de (jored mo2) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id Z0639bo98GwHFL
	for ; Mon, 8 Oct 2012 19:17:40 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 41D6E183A7
	for ; Mon,  8 Oct 2012 19:17:39 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: de76ea76418f19248fd3e5541344a51c38c716ae
Message-Id: 
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 08 Oct 2012 19:17:38 +0200
From: Olaf Hering 
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] pygrub: correct typo in --args assignment
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering 
# Date 1349716567 -7200
# Node ID de76ea76418f19248fd3e5541344a51c38c716ae
# Parent  c9f621893a05e3e447ba6770f8ae912721712569
pygrub: correct typo in --args assignment

If pygrub was called with --args="some thing", then this string should
be append to the kernel command line.  But the last changeset
25941:795c493fe561 contained a typo, it assigns 'args' instead of 'arg'.

Rename the local variable which holds the string from the domain config
file to avoid further confusion.

Signed-off-by: Olaf Hering 

diff -r c9f621893a05 -r de76ea76418f tools/pygrub/src/pygrub
--- a/tools/pygrub/src/pygrub
+++ b/tools/pygrub/src/pygrub
@@ -585,7 +585,7 @@ def get_entry_idx(cf, entry):
 
     return None
 
-def run_grub(file, entry, fs, arg):
+def run_grub(file, entry, fs, cfg_args):
     global g
     global sel
 
@@ -622,8 +622,8 @@ def run_grub(file, entry, fs, arg):
         grubcfg["ramdisk"] = img.initrd[1]
     if img.args:
         grubcfg["args"] += img.args
-    if arg:
-        grubcfg["args"] += " " + args
+    if cfg_args:
+        grubcfg["args"] += " " + cfg_args
 
     return grubcfg
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 17:36:23 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 17:36:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLHFN-0001S3-SQ; Mon, 08 Oct 2012 17:36:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLHFM-0001Ry-1u
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 17:36:04 +0000
Received: from [85.158.143.99:17096] by server-3.bemta-4.messagelabs.com id
	90/AC-10986-30F03705; Mon, 08 Oct 2012 17:36:03 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-15.tower-216.messagelabs.com!1349717761!33307478!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY,
	UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22054 invoked from network); 8 Oct 2012 17:36:02 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Oct 2012 17:36:02 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.154539685;
	Mon, 08 Oct 2012 13:35:45 -0400
Message-ID: <50730E9D.4010300@jhuapl.edu>
Date: Mon, 08 Oct 2012 13:34:21 -0400
From: Matthew Fioravante 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Samuel Thibault , 
	"xen-devel@lists.xensource.com" 
References: <50579C5F.5040004@jhuapl.edu>
	<20120917224619.GO5110@type.youpi.perso.aquilenet.fr>
	<506F209E.2040902@jhuapl.edu>
	<20121008080500.GA5985@type.bordeaux.inria.fr>
	<5072E470.1060404@jhuapl.edu>
	<20121008171004.GH5985@type.bordeaux.inria.fr>
In-Reply-To: <20121008171004.GH5985@type.bordeaux.inria.fr>
X-Enigmail-Version: 1.4.4
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 2/8] add posix
	io to blkfront
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============6196714826199672668=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============6196714826199672668==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060902020906080007040909"

This is a cryptographically signed message in MIME format.

--------------ms060902020906080007040909
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 10/08/2012 01:10 PM, Samuel Thibault wrote:
> Matthew Fioravante, le Mon 08 Oct 2012 10:34:24 -0400, a =E9crit :
>> Sometimes n comes out to be BLKIF_MAX_SEGEMENTS_PER_REQUEST +1.
>>
>> This happens when your buffer address is sector aligned (512k), but
>> not page aligned (4096k).
>> So we can either optimize yet again if address is page
>> aligned
> Ah, right. Well, I'd say it's worth making the effort to test against
> that, i.e. (untested)
>
> else {
> 	if (count >=3D BLKIF_MAX_SEGMENTS_PER_REQUEST*PAGE_SIZE
> 	    && (!(buf & ~(PAGE_SIZE-1))))
> 	    	/* page-aligned */
> 		bytes =3D BLKIF_MAX_SEGMENTS_PER_REQUEST*PAGE_SIZE;
> 	else if (count >=3D (BLKIF_MAX_SEGMENTS_PER_REQUEST-1)*PAGE_SIZE)
> 	    	/* only sector-aligned, will have to realign */
> 		bytes =3D (BLKIF_MAX_SEGMENTS_PER_REQUEST-1)*PAGE_SIZE;
> 	else
> 		bytes =3D count & ~(blocksize - 1);
>     }
> }
I tested and you can do BLKIF_MAX_SEGEMENTS_PER_REQUEST if the buffer is
page aligned. I'm sending a new patch with this optimization.
>
>> Is the page math being done above that assertion correct?
> I believe so.
>
> Samuel



--------------ms060902020906080007040909
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMTAwODE3MzQyMVowIwYJKoZIhvcNAQkEMRYEFCeiPyb4SNVJGtSd
yShb0GUNDD7fMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAE1BfAi6hiBVaIWTESYmlNkz/FKdK6gkfC
Jk3ZMjGr+oG0LRsZm9xP2F4ZY1tKrb+r2Hq+NtEmFxtWgSpabWp1lqKYQtR/tgq4bc162j8p
SyNQMOIIU6zkmlg7Su6A5DRCWa+gSv+uNY4uyikVHHHJ3zIAMuHmCoEIF429gs6RowAAAAAA
AA==
--------------ms060902020906080007040909--


--===============6196714826199672668==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6196714826199672668==--


From xen-devel-bounces@lists.xen.org Mon Oct 08 17:36:23 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 17:36:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLHFN-0001S3-SQ; Mon, 08 Oct 2012 17:36:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLHFM-0001Ry-1u
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 17:36:04 +0000
Received: from [85.158.143.99:17096] by server-3.bemta-4.messagelabs.com id
	90/AC-10986-30F03705; Mon, 08 Oct 2012 17:36:03 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-15.tower-216.messagelabs.com!1349717761!33307478!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY,
	UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22054 invoked from network); 8 Oct 2012 17:36:02 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Oct 2012 17:36:02 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.154539685;
	Mon, 08 Oct 2012 13:35:45 -0400
Message-ID: <50730E9D.4010300@jhuapl.edu>
Date: Mon, 08 Oct 2012 13:34:21 -0400
From: Matthew Fioravante 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Samuel Thibault , 
	"xen-devel@lists.xensource.com" 
References: <50579C5F.5040004@jhuapl.edu>
	<20120917224619.GO5110@type.youpi.perso.aquilenet.fr>
	<506F209E.2040902@jhuapl.edu>
	<20121008080500.GA5985@type.bordeaux.inria.fr>
	<5072E470.1060404@jhuapl.edu>
	<20121008171004.GH5985@type.bordeaux.inria.fr>
In-Reply-To: <20121008171004.GH5985@type.bordeaux.inria.fr>
X-Enigmail-Version: 1.4.4
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 2/8] add posix
	io to blkfront
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============6196714826199672668=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============6196714826199672668==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060902020906080007040909"

This is a cryptographically signed message in MIME format.

--------------ms060902020906080007040909
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 10/08/2012 01:10 PM, Samuel Thibault wrote:
> Matthew Fioravante, le Mon 08 Oct 2012 10:34:24 -0400, a =E9crit :
>> Sometimes n comes out to be BLKIF_MAX_SEGEMENTS_PER_REQUEST +1.
>>
>> This happens when your buffer address is sector aligned (512k), but
>> not page aligned (4096k).
>> So we can either optimize yet again if address is page
>> aligned
> Ah, right. Well, I'd say it's worth making the effort to test against
> that, i.e. (untested)
>
> else {
> 	if (count >=3D BLKIF_MAX_SEGMENTS_PER_REQUEST*PAGE_SIZE
> 	    && (!(buf & ~(PAGE_SIZE-1))))
> 	    	/* page-aligned */
> 		bytes =3D BLKIF_MAX_SEGMENTS_PER_REQUEST*PAGE_SIZE;
> 	else if (count >=3D (BLKIF_MAX_SEGMENTS_PER_REQUEST-1)*PAGE_SIZE)
> 	    	/* only sector-aligned, will have to realign */
> 		bytes =3D (BLKIF_MAX_SEGMENTS_PER_REQUEST-1)*PAGE_SIZE;
> 	else
> 		bytes =3D count & ~(blocksize - 1);
>     }
> }
I tested and you can do BLKIF_MAX_SEGEMENTS_PER_REQUEST if the buffer is
page aligned. I'm sending a new patch with this optimization.
>
>> Is the page math being done above that assertion correct?
> I believe so.
>
> Samuel



--------------ms060902020906080007040909
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMTAwODE3MzQyMVowIwYJKoZIhvcNAQkEMRYEFCeiPyb4SNVJGtSd
yShb0GUNDD7fMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAE1BfAi6hiBVaIWTESYmlNkz/FKdK6gkfC
Jk3ZMjGr+oG0LRsZm9xP2F4ZY1tKrb+r2Hq+NtEmFxtWgSpabWp1lqKYQtR/tgq4bc162j8p
SyNQMOIIU6zkmlg7Su6A5DRCWa+gSv+uNY4uyikVHHHJ3zIAMuHmCoEIF429gs6RowAAAAAA
AA==
--------------ms060902020906080007040909--


--===============6196714826199672668==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6196714826199672668==--


From xen-devel-bounces@lists.xen.org Mon Oct 08 17:43:28 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 17:43:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLHMF-0001cE-Or; Mon, 08 Oct 2012 17:43:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLHMD-0001c6-N0
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 17:43:09 +0000
Received: from [85.158.137.99:40058] by server-13.bemta-3.messagelabs.com id
	BD/CC-28885-CA013705; Mon, 08 Oct 2012 17:43:08 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-2.tower-217.messagelabs.com!1349718187!20632605!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10765 invoked from network); 8 Oct 2012 17:43:08 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-2.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 17:43:08 -0000
Received: from ([128.244.207.97])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.154540780;
	Mon, 08 Oct 2012 13:42:48 -0400
From: Matthew Fioravante 
To: xen-devel@lists.xen.org, ian.campbell@citrix.com,
	samuel.thibault@ens-lyon.org
Date: Mon,  8 Oct 2012 13:42:32 -0400
Message-Id: <1349718153-14487-1-git-send-email-matthew.fioravante@jhuapl.edu>
X-Mailer: git-send-email 1.7.4.4
Cc: Matthew Fioravante 
Subject: [Xen-devel] [vtpm v3 06/12] add select definition to sys/time.h
	when HAVE_LIBC is defined
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch adds the select function to sys/time.h when HAVE_LIBC is
defined, which is according to standard (see the select() manpage).
It also removes a redudant lwip include from posix/sys/select.h.

Signed-off-by: Matthew Fioravante 

diff --git a/extras/mini-os/include/posix/sys/select.h b/extras/mini-os/include/posix/sys/select.h
index a9337be..5132c51 100644
--- a/extras/mini-os/include/posix/sys/select.h
+++ b/extras/mini-os/include/posix/sys/select.h
@@ -2,7 +2,6 @@
 #define _POSIX_SELECT_H
 
 #include 
-#include 
 int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);
 
 #endif /* _POSIX_SELECT_H */
diff --git a/extras/mini-os/include/sys/time.h b/extras/mini-os/include/sys/time.h
index d6623a4..3be3653 100644
--- a/extras/mini-os/include/sys/time.h
+++ b/extras/mini-os/include/sys/time.h
@@ -22,6 +22,7 @@
 
 #ifdef HAVE_LIBC
 #include_next 
+
 #else
 struct timespec {
     time_t      tv_sec;
@@ -37,6 +38,10 @@ struct timeval {
 };
 
 int      gettimeofday(struct timeval *tv, void *tz);
+
+#endif
+#ifdef HAVE_LIBC
+#include 
 #endif
 
 #endif /* _MINIOS_SYS_TIME_H_ */
-- 
1.7.4.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 17:43:28 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 17:43:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLHMF-0001cE-Or; Mon, 08 Oct 2012 17:43:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLHMD-0001c6-N0
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 17:43:09 +0000
Received: from [85.158.137.99:40058] by server-13.bemta-3.messagelabs.com id
	BD/CC-28885-CA013705; Mon, 08 Oct 2012 17:43:08 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-2.tower-217.messagelabs.com!1349718187!20632605!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10765 invoked from network); 8 Oct 2012 17:43:08 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-2.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 17:43:08 -0000
Received: from ([128.244.207.97])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.154540780;
	Mon, 08 Oct 2012 13:42:48 -0400
From: Matthew Fioravante 
To: xen-devel@lists.xen.org, ian.campbell@citrix.com,
	samuel.thibault@ens-lyon.org
Date: Mon,  8 Oct 2012 13:42:32 -0400
Message-Id: <1349718153-14487-1-git-send-email-matthew.fioravante@jhuapl.edu>
X-Mailer: git-send-email 1.7.4.4
Cc: Matthew Fioravante 
Subject: [Xen-devel] [vtpm v3 06/12] add select definition to sys/time.h
	when HAVE_LIBC is defined
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch adds the select function to sys/time.h when HAVE_LIBC is
defined, which is according to standard (see the select() manpage).
It also removes a redudant lwip include from posix/sys/select.h.

Signed-off-by: Matthew Fioravante 

diff --git a/extras/mini-os/include/posix/sys/select.h b/extras/mini-os/include/posix/sys/select.h
index a9337be..5132c51 100644
--- a/extras/mini-os/include/posix/sys/select.h
+++ b/extras/mini-os/include/posix/sys/select.h
@@ -2,7 +2,6 @@
 #define _POSIX_SELECT_H
 
 #include 
-#include 
 int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);
 
 #endif /* _POSIX_SELECT_H */
diff --git a/extras/mini-os/include/sys/time.h b/extras/mini-os/include/sys/time.h
index d6623a4..3be3653 100644
--- a/extras/mini-os/include/sys/time.h
+++ b/extras/mini-os/include/sys/time.h
@@ -22,6 +22,7 @@
 
 #ifdef HAVE_LIBC
 #include_next 
+
 #else
 struct timespec {
     time_t      tv_sec;
@@ -37,6 +38,10 @@ struct timeval {
 };
 
 int      gettimeofday(struct timeval *tv, void *tz);
+
+#endif
+#ifdef HAVE_LIBC
+#include 
 #endif
 
 #endif /* _MINIOS_SYS_TIME_H_ */
-- 
1.7.4.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 17:43:46 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 17:43:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLHMV-0001cx-5P; Mon, 08 Oct 2012 17:43:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLHMU-0001cq-5S
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 17:43:26 +0000
Received: from [85.158.143.35:64205] by server-3.bemta-4.messagelabs.com id
	1F/12-10986-DB013705; Mon, 08 Oct 2012 17:43:25 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-15.tower-21.messagelabs.com!1349718203!14174414!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD,UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18410 invoked from network); 8 Oct 2012 17:43:24 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 17:43:24 -0000
Received: from ([128.244.207.97])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.154540811;
	Mon, 08 Oct 2012 13:42:48 -0400
From: Matthew Fioravante 
To: xen-devel@lists.xen.org, ian.campbell@citrix.com,
	samuel.thibault@ens-lyon.org
Date: Mon,  8 Oct 2012 13:42:33 -0400
Message-Id: <1349718153-14487-2-git-send-email-matthew.fioravante@jhuapl.edu>
X-Mailer: git-send-email 1.7.4.4
In-Reply-To: <1349718153-14487-1-git-send-email-matthew.fioravante@jhuapl.edu>
References: <1349718153-14487-1-git-send-email-matthew.fioravante@jhuapl.edu>
Cc: Matthew Fioravante 
Subject: [Xen-devel] [vtpm v3 02/12] add posix io for blkfront
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch adds posix io support (read,write,lseek) to block devices
using blkfront.

Signed-off-by: Matthew Fioravante 
Acked-by: Samuel Thibault 

diff --git a/extras/mini-os/blkfront.c b/extras/mini-os/blkfront.c
index 74b8b26..f4283a9 100644
--- a/extras/mini-os/blkfront.c
+++ b/extras/mini-os/blkfront.c
@@ -392,6 +392,7 @@ void blkfront_aio(struct blkfront_aiocb *aiocbp, int write)
 static void blkfront_aio_cb(struct blkfront_aiocb *aiocbp, int ret)
 {
     aiocbp->data = (void*) 1;
+    aiocbp->aio_cb = NULL;
 }
 
 void blkfront_io(struct blkfront_aiocb *aiocbp, int write)
@@ -547,9 +548,177 @@ moretodo:
 #ifdef HAVE_LIBC
 int blkfront_open(struct blkfront_dev *dev)
 {
+    /* Silently prevent multiple opens */
+    if(dev->fd != -1) {
+       return dev->fd;
+    }
     dev->fd = alloc_fd(FTYPE_BLK);
     printk("blk_open(%s) -> %d\n", dev->nodename, dev->fd);
     files[dev->fd].blk.dev = dev;
+    files[dev->fd].blk.offset = 0;
     return dev->fd;
 }
+
+int blkfront_posix_rwop(int fd, uint8_t* buf, size_t count, int write)
+{
+   struct blkfront_dev* dev = files[fd].blk.dev;
+   off_t offset = files[fd].blk.offset;
+   struct blkfront_aiocb aiocb;
+   unsigned long long disksize = dev->info.sectors * dev->info.sector_size;
+   unsigned int blocksize = dev->info.sector_size;
+
+   int blknum;
+   int blkoff;
+   size_t bytes;
+   int rc = 0;
+   int alignedbuf = 0;
+   uint8_t* copybuf = NULL;
+
+   /* RW 0 bytes is just a NOP */
+   if(count == 0) {
+      return 0;
+   }
+   /* Check for NULL buffer */
+   if( buf == NULL ) {
+      errno = EFAULT;
+      return -1;
+   }
+
+   /* Write mode checks */
+   if(write) {
+      /*Make sure we have write permission */
+      if(dev->info.info & VDISK_READONLY 
+            || (dev->info.mode != O_RDWR  && dev->info.mode !=  O_WRONLY)) {
+         errno = EACCES;
+         return -1;
+      }
+      /*Make sure disk is big enough for this write */
+      if(offset + count > disksize) {
+         errno = ENOSPC;
+         return -1;
+      }
+   }
+   /* Read mode checks */
+   else
+   {
+      /* Reading past the disk? Just return 0 */
+      if(offset >= disksize) {
+         return 0;
+      }
+
+      /*If the requested read is bigger than the disk, just
+       * read as much as we can until the end */
+      if(offset + count > disksize) {
+         count = disksize - offset;
+      }
+   }
+   /* Determine which block to start at and at which offset inside of it */
+   blknum = offset / blocksize;
+   blkoff = offset % blocksize;
+
+   /* Optimization: We need to check if buf is aligned to the sector size.
+    * This is somewhat tricky code. We have to add the blocksize - block offset
+    * because the first block may be a partial block and then for every subsequent
+    * block rw the buffer will be offset.*/
+   if(!((uintptr_t) (buf +(blocksize -  blkoff)) & (dev->info.sector_size-1))) {
+      alignedbuf = 1;
+   }
+
+   /* Setup aiocb block object */
+   aiocb.aio_dev = dev;
+   aiocb.aio_offset = blknum * blocksize;
+   aiocb.aio_cb = NULL;
+   aiocb.data = NULL;
+
+   /* If our buffer is unaligned or its aligned but we will need to rw a partial block
+    * then a copy will have to be done */
+   if(!alignedbuf || blkoff != 0 || count % blocksize != 0) {
+      copybuf = _xmalloc(blocksize, dev->info.sector_size);
+   }
+
+   rc = count;
+   while(count > 0) {
+      /* determine how many bytes to read/write from/to the current block buffer */
+      if(!alignedbuf || blkoff != 0 || count < blocksize) {
+         /* This is the case for unaligned R/W or partial block */
+         bytes = count < blocksize - blkoff ? count : blocksize - blkoff;
+         aiocb.aio_nbytes = blocksize;
+      } else {
+         /* We can optimize further if buffer is page aligned */
+         int not_page_aligned = 0;
+         if(((uintptr_t)buf) & (PAGE_SIZE -1)) {
+            not_page_aligned = 1;
+         }
+
+         /* For an aligned R/W we can read up to the maximum transfer size */
+         bytes = count > (BLKIF_MAX_SEGMENTS_PER_REQUEST-not_page_aligned)*PAGE_SIZE 
+            ? (BLKIF_MAX_SEGMENTS_PER_REQUEST-not_page_aligned)*PAGE_SIZE
+            : count & ~(blocksize -1);
+         aiocb.aio_nbytes = bytes;
+      }
+
+      /* read operation */
+      if(!write) {
+         if (alignedbuf && bytes >= blocksize) {
+            /* If aligned and were reading a whole block, just read right into buf */
+            aiocb.aio_buf = buf;
+            blkfront_read(&aiocb);
+         } else {
+            /* If not then we have to do a copy */
+            aiocb.aio_buf = copybuf;
+            blkfront_read(&aiocb);
+            memcpy(buf, ©buf[blkoff], bytes);
+         }
+      }
+      /* Write operation */
+      else {
+         if(alignedbuf && bytes >= blocksize) {
+            /* If aligned and were writing a whole block, just write directly from buf */
+            aiocb.aio_buf = buf;
+            blkfront_write(&aiocb);
+         } else {
+            /* If not then we have to do a copy. */
+            aiocb.aio_buf = copybuf;
+            /* If we're writing a partial block, we need to read the current contents first
+             * so we don't overwrite the extra bits with garbage */
+            if(blkoff != 0 || bytes < blocksize) {
+               blkfront_read(&aiocb);
+            }
+            memcpy(©buf[blkoff], buf, bytes);
+            blkfront_write(&aiocb);
+         }
+      }
+      /* Will start at beginning of all remaining blocks */
+      blkoff = 0;
+
+      /* Increment counters and continue */
+      count -= bytes;
+      buf += bytes;
+      if(bytes < blocksize) {
+         //At minimum we read one block
+         aiocb.aio_offset += blocksize;
+      } else {
+         //If we read more than a block, was a multiple of blocksize
+         aiocb.aio_offset += bytes;
+      }
+   }
+
+   free(copybuf);
+   files[fd].blk.offset += rc;
+   return rc;
+
+}
+
+int blkfront_posix_fstat(int fd, struct stat* buf)
+{
+   struct blkfront_dev* dev = files[fd].blk.dev;
+
+   buf->st_mode = dev->info.mode;
+   buf->st_uid = 0;
+   buf->st_gid = 0;
+   buf->st_size = dev->info.sectors * dev->info.sector_size;
+   buf->st_atime = buf->st_mtime = buf->st_ctime = time(NULL);
+
+   return 0;
+}
 #endif
diff --git a/extras/mini-os/include/blkfront.h b/extras/mini-os/include/blkfront.h
index 724137e..3528af9 100644
--- a/extras/mini-os/include/blkfront.h
+++ b/extras/mini-os/include/blkfront.h
@@ -28,7 +28,17 @@ struct blkfront_info
 };
 struct blkfront_dev *init_blkfront(char *nodename, struct blkfront_info *info);
 #ifdef HAVE_LIBC
+#include 
+/* POSIX IO functions:
+ * use blkfront_open() to get a file descriptor to the block device
+ * Don't use the other blkfront posix functions here directly, instead use
+ * read(), write(), lseek() and fstat() on the file descriptor
+ */
 int blkfront_open(struct blkfront_dev *dev);
+int blkfront_posix_rwop(int fd, uint8_t* buf, size_t count, int write);
+#define blkfront_posix_write(fd, buf, count) blkfront_posix_rwop(fd, (uint8_t*)buf, count, 1)
+#define blkfront_posix_read(fd, buf, count) blkfront_posix_rwop(fd, (uint8_t*)buf, count, 0)
+int blkfront_posix_fstat(int fd, struct stat* buf);
 #endif
 void blkfront_aio(struct blkfront_aiocb *aiocbp, int write);
 #define blkfront_aio_read(aiocbp) blkfront_aio(aiocbp, 0)
diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h
index 1af2717..d4641b6 100644
--- a/extras/mini-os/include/lib.h
+++ b/extras/mini-os/include/lib.h
@@ -174,6 +174,7 @@ extern struct file {
 	} tap;
 	struct {
 	    struct blkfront_dev *dev;
+            off_t offset;
 	} blk;
 	struct {
 	    struct kbdfront_dev *dev;
diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
index a7d35d6..7ddbbf8 100644
--- a/extras/mini-os/lib/sys.c
+++ b/extras/mini-os/lib/sys.c
@@ -289,6 +289,11 @@ int read(int fd, void *buf, size_t nbytes)
 	    return ret * sizeof(union xenfb_in_event);
         }
 #endif
+#ifdef CONFIG_BLKFRONT
+        case FTYPE_BLK: {
+	    return blkfront_posix_read(fd, buf, nbytes);
+        }
+#endif
 	default:
 	    break;
     }
@@ -321,6 +326,10 @@ int write(int fd, const void *buf, size_t nbytes)
 	    netfront_xmit(files[fd].tap.dev, (void*) buf, nbytes);
 	    return nbytes;
 #endif
+#ifdef CONFIG_BLKFRONT
+	case FTYPE_BLK:
+	    return blkfront_posix_write(fd, buf, nbytes);
+#endif
 	default:
 	    break;
     }
@@ -331,8 +340,37 @@ int write(int fd, const void *buf, size_t nbytes)
 
 off_t lseek(int fd, off_t offset, int whence)
 {
-    errno = ESPIPE;
-    return (off_t) -1;
+    switch(files[fd].type) {
+#ifdef CONFIG_BLKFRONT
+       case FTYPE_BLK:
+	  switch (whence) {
+	     case SEEK_SET:
+		files[fd].file.offset = offset;
+		break;
+	     case SEEK_CUR:
+		files[fd].file.offset += offset;
+		break;
+	     case SEEK_END:
+		{
+		   struct stat st;
+		   int ret;
+		   ret = fstat(fd, &st);
+		   if (ret)
+		      return -1;
+		   files[fd].file.offset = st.st_size + offset;
+		   break;
+		}
+	     default:
+		errno = EINVAL;
+		return -1;
+	  }
+	  return files[fd].file.offset;
+	  break;
+#endif
+       default: /* Not implemented on this FTYPE */
+	  errno = ESPIPE;
+	  return (off_t) -1;
+    }
 }
 
 int fsync(int fd) {
@@ -445,6 +483,10 @@ int fstat(int fd, struct stat *buf)
 	    buf->st_ctime = time(NULL);
 	    return 0;
 	}
+#ifdef CONFIG_BLKFRONT
+	case FTYPE_BLK:
+	   return blkfront_posix_fstat(fd, buf);
+#endif
 	default:
 	    break;
     }
-- 
1.7.4.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 17:43:46 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 17:43:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLHMV-0001cx-5P; Mon, 08 Oct 2012 17:43:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLHMU-0001cq-5S
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 17:43:26 +0000
Received: from [85.158.143.35:64205] by server-3.bemta-4.messagelabs.com id
	1F/12-10986-DB013705; Mon, 08 Oct 2012 17:43:25 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-15.tower-21.messagelabs.com!1349718203!14174414!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD,UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18410 invoked from network); 8 Oct 2012 17:43:24 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 17:43:24 -0000
Received: from ([128.244.207.97])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.154540811;
	Mon, 08 Oct 2012 13:42:48 -0400
From: Matthew Fioravante 
To: xen-devel@lists.xen.org, ian.campbell@citrix.com,
	samuel.thibault@ens-lyon.org
Date: Mon,  8 Oct 2012 13:42:33 -0400
Message-Id: <1349718153-14487-2-git-send-email-matthew.fioravante@jhuapl.edu>
X-Mailer: git-send-email 1.7.4.4
In-Reply-To: <1349718153-14487-1-git-send-email-matthew.fioravante@jhuapl.edu>
References: <1349718153-14487-1-git-send-email-matthew.fioravante@jhuapl.edu>
Cc: Matthew Fioravante 
Subject: [Xen-devel] [vtpm v3 02/12] add posix io for blkfront
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch adds posix io support (read,write,lseek) to block devices
using blkfront.

Signed-off-by: Matthew Fioravante 
Acked-by: Samuel Thibault 

diff --git a/extras/mini-os/blkfront.c b/extras/mini-os/blkfront.c
index 74b8b26..f4283a9 100644
--- a/extras/mini-os/blkfront.c
+++ b/extras/mini-os/blkfront.c
@@ -392,6 +392,7 @@ void blkfront_aio(struct blkfront_aiocb *aiocbp, int write)
 static void blkfront_aio_cb(struct blkfront_aiocb *aiocbp, int ret)
 {
     aiocbp->data = (void*) 1;
+    aiocbp->aio_cb = NULL;
 }
 
 void blkfront_io(struct blkfront_aiocb *aiocbp, int write)
@@ -547,9 +548,177 @@ moretodo:
 #ifdef HAVE_LIBC
 int blkfront_open(struct blkfront_dev *dev)
 {
+    /* Silently prevent multiple opens */
+    if(dev->fd != -1) {
+       return dev->fd;
+    }
     dev->fd = alloc_fd(FTYPE_BLK);
     printk("blk_open(%s) -> %d\n", dev->nodename, dev->fd);
     files[dev->fd].blk.dev = dev;
+    files[dev->fd].blk.offset = 0;
     return dev->fd;
 }
+
+int blkfront_posix_rwop(int fd, uint8_t* buf, size_t count, int write)
+{
+   struct blkfront_dev* dev = files[fd].blk.dev;
+   off_t offset = files[fd].blk.offset;
+   struct blkfront_aiocb aiocb;
+   unsigned long long disksize = dev->info.sectors * dev->info.sector_size;
+   unsigned int blocksize = dev->info.sector_size;
+
+   int blknum;
+   int blkoff;
+   size_t bytes;
+   int rc = 0;
+   int alignedbuf = 0;
+   uint8_t* copybuf = NULL;
+
+   /* RW 0 bytes is just a NOP */
+   if(count == 0) {
+      return 0;
+   }
+   /* Check for NULL buffer */
+   if( buf == NULL ) {
+      errno = EFAULT;
+      return -1;
+   }
+
+   /* Write mode checks */
+   if(write) {
+      /*Make sure we have write permission */
+      if(dev->info.info & VDISK_READONLY 
+            || (dev->info.mode != O_RDWR  && dev->info.mode !=  O_WRONLY)) {
+         errno = EACCES;
+         return -1;
+      }
+      /*Make sure disk is big enough for this write */
+      if(offset + count > disksize) {
+         errno = ENOSPC;
+         return -1;
+      }
+   }
+   /* Read mode checks */
+   else
+   {
+      /* Reading past the disk? Just return 0 */
+      if(offset >= disksize) {
+         return 0;
+      }
+
+      /*If the requested read is bigger than the disk, just
+       * read as much as we can until the end */
+      if(offset + count > disksize) {
+         count = disksize - offset;
+      }
+   }
+   /* Determine which block to start at and at which offset inside of it */
+   blknum = offset / blocksize;
+   blkoff = offset % blocksize;
+
+   /* Optimization: We need to check if buf is aligned to the sector size.
+    * This is somewhat tricky code. We have to add the blocksize - block offset
+    * because the first block may be a partial block and then for every subsequent
+    * block rw the buffer will be offset.*/
+   if(!((uintptr_t) (buf +(blocksize -  blkoff)) & (dev->info.sector_size-1))) {
+      alignedbuf = 1;
+   }
+
+   /* Setup aiocb block object */
+   aiocb.aio_dev = dev;
+   aiocb.aio_offset = blknum * blocksize;
+   aiocb.aio_cb = NULL;
+   aiocb.data = NULL;
+
+   /* If our buffer is unaligned or its aligned but we will need to rw a partial block
+    * then a copy will have to be done */
+   if(!alignedbuf || blkoff != 0 || count % blocksize != 0) {
+      copybuf = _xmalloc(blocksize, dev->info.sector_size);
+   }
+
+   rc = count;
+   while(count > 0) {
+      /* determine how many bytes to read/write from/to the current block buffer */
+      if(!alignedbuf || blkoff != 0 || count < blocksize) {
+         /* This is the case for unaligned R/W or partial block */
+         bytes = count < blocksize - blkoff ? count : blocksize - blkoff;
+         aiocb.aio_nbytes = blocksize;
+      } else {
+         /* We can optimize further if buffer is page aligned */
+         int not_page_aligned = 0;
+         if(((uintptr_t)buf) & (PAGE_SIZE -1)) {
+            not_page_aligned = 1;
+         }
+
+         /* For an aligned R/W we can read up to the maximum transfer size */
+         bytes = count > (BLKIF_MAX_SEGMENTS_PER_REQUEST-not_page_aligned)*PAGE_SIZE 
+            ? (BLKIF_MAX_SEGMENTS_PER_REQUEST-not_page_aligned)*PAGE_SIZE
+            : count & ~(blocksize -1);
+         aiocb.aio_nbytes = bytes;
+      }
+
+      /* read operation */
+      if(!write) {
+         if (alignedbuf && bytes >= blocksize) {
+            /* If aligned and were reading a whole block, just read right into buf */
+            aiocb.aio_buf = buf;
+            blkfront_read(&aiocb);
+         } else {
+            /* If not then we have to do a copy */
+            aiocb.aio_buf = copybuf;
+            blkfront_read(&aiocb);
+            memcpy(buf, ©buf[blkoff], bytes);
+         }
+      }
+      /* Write operation */
+      else {
+         if(alignedbuf && bytes >= blocksize) {
+            /* If aligned and were writing a whole block, just write directly from buf */
+            aiocb.aio_buf = buf;
+            blkfront_write(&aiocb);
+         } else {
+            /* If not then we have to do a copy. */
+            aiocb.aio_buf = copybuf;
+            /* If we're writing a partial block, we need to read the current contents first
+             * so we don't overwrite the extra bits with garbage */
+            if(blkoff != 0 || bytes < blocksize) {
+               blkfront_read(&aiocb);
+            }
+            memcpy(©buf[blkoff], buf, bytes);
+            blkfront_write(&aiocb);
+         }
+      }
+      /* Will start at beginning of all remaining blocks */
+      blkoff = 0;
+
+      /* Increment counters and continue */
+      count -= bytes;
+      buf += bytes;
+      if(bytes < blocksize) {
+         //At minimum we read one block
+         aiocb.aio_offset += blocksize;
+      } else {
+         //If we read more than a block, was a multiple of blocksize
+         aiocb.aio_offset += bytes;
+      }
+   }
+
+   free(copybuf);
+   files[fd].blk.offset += rc;
+   return rc;
+
+}
+
+int blkfront_posix_fstat(int fd, struct stat* buf)
+{
+   struct blkfront_dev* dev = files[fd].blk.dev;
+
+   buf->st_mode = dev->info.mode;
+   buf->st_uid = 0;
+   buf->st_gid = 0;
+   buf->st_size = dev->info.sectors * dev->info.sector_size;
+   buf->st_atime = buf->st_mtime = buf->st_ctime = time(NULL);
+
+   return 0;
+}
 #endif
diff --git a/extras/mini-os/include/blkfront.h b/extras/mini-os/include/blkfront.h
index 724137e..3528af9 100644
--- a/extras/mini-os/include/blkfront.h
+++ b/extras/mini-os/include/blkfront.h
@@ -28,7 +28,17 @@ struct blkfront_info
 };
 struct blkfront_dev *init_blkfront(char *nodename, struct blkfront_info *info);
 #ifdef HAVE_LIBC
+#include 
+/* POSIX IO functions:
+ * use blkfront_open() to get a file descriptor to the block device
+ * Don't use the other blkfront posix functions here directly, instead use
+ * read(), write(), lseek() and fstat() on the file descriptor
+ */
 int blkfront_open(struct blkfront_dev *dev);
+int blkfront_posix_rwop(int fd, uint8_t* buf, size_t count, int write);
+#define blkfront_posix_write(fd, buf, count) blkfront_posix_rwop(fd, (uint8_t*)buf, count, 1)
+#define blkfront_posix_read(fd, buf, count) blkfront_posix_rwop(fd, (uint8_t*)buf, count, 0)
+int blkfront_posix_fstat(int fd, struct stat* buf);
 #endif
 void blkfront_aio(struct blkfront_aiocb *aiocbp, int write);
 #define blkfront_aio_read(aiocbp) blkfront_aio(aiocbp, 0)
diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h
index 1af2717..d4641b6 100644
--- a/extras/mini-os/include/lib.h
+++ b/extras/mini-os/include/lib.h
@@ -174,6 +174,7 @@ extern struct file {
 	} tap;
 	struct {
 	    struct blkfront_dev *dev;
+            off_t offset;
 	} blk;
 	struct {
 	    struct kbdfront_dev *dev;
diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
index a7d35d6..7ddbbf8 100644
--- a/extras/mini-os/lib/sys.c
+++ b/extras/mini-os/lib/sys.c
@@ -289,6 +289,11 @@ int read(int fd, void *buf, size_t nbytes)
 	    return ret * sizeof(union xenfb_in_event);
         }
 #endif
+#ifdef CONFIG_BLKFRONT
+        case FTYPE_BLK: {
+	    return blkfront_posix_read(fd, buf, nbytes);
+        }
+#endif
 	default:
 	    break;
     }
@@ -321,6 +326,10 @@ int write(int fd, const void *buf, size_t nbytes)
 	    netfront_xmit(files[fd].tap.dev, (void*) buf, nbytes);
 	    return nbytes;
 #endif
+#ifdef CONFIG_BLKFRONT
+	case FTYPE_BLK:
+	    return blkfront_posix_write(fd, buf, nbytes);
+#endif
 	default:
 	    break;
     }
@@ -331,8 +340,37 @@ int write(int fd, const void *buf, size_t nbytes)
 
 off_t lseek(int fd, off_t offset, int whence)
 {
-    errno = ESPIPE;
-    return (off_t) -1;
+    switch(files[fd].type) {
+#ifdef CONFIG_BLKFRONT
+       case FTYPE_BLK:
+	  switch (whence) {
+	     case SEEK_SET:
+		files[fd].file.offset = offset;
+		break;
+	     case SEEK_CUR:
+		files[fd].file.offset += offset;
+		break;
+	     case SEEK_END:
+		{
+		   struct stat st;
+		   int ret;
+		   ret = fstat(fd, &st);
+		   if (ret)
+		      return -1;
+		   files[fd].file.offset = st.st_size + offset;
+		   break;
+		}
+	     default:
+		errno = EINVAL;
+		return -1;
+	  }
+	  return files[fd].file.offset;
+	  break;
+#endif
+       default: /* Not implemented on this FTYPE */
+	  errno = ESPIPE;
+	  return (off_t) -1;
+    }
 }
 
 int fsync(int fd) {
@@ -445,6 +483,10 @@ int fstat(int fd, struct stat *buf)
 	    buf->st_ctime = time(NULL);
 	    return 0;
 	}
+#ifdef CONFIG_BLKFRONT
+	case FTYPE_BLK:
+	   return blkfront_posix_fstat(fd, buf);
+#endif
 	default:
 	    break;
     }
-- 
1.7.4.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 18:16:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 18:16:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLHse-00024b-GV; Mon, 08 Oct 2012 18:16:40 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLHsc-00023l-Op
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 18:16:38 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1349720190!9076004!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ5NjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9729 invoked from network); 8 Oct 2012 18:16:32 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 18:16:32 -0000
X-IronPort-AV: E=Sophos;i="4.80,555,1344211200"; d="scan'208";a="40490110"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 18:16:17 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 8 Oct 2012 14:16:16 -0400
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TLHsG-0000Ol-Eb;
	Mon, 08 Oct 2012 19:16:16 +0100
MIME-Version: 1.0
X-Mercurial-Node: 0a1a3f35f56a1a2b3b8f17483ccd0010733d3e53
Message-ID: <0a1a3f35f56a1a2b3b8f.1349720163@andrewcoop.uk.xensource.com>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.3.1
Date: Mon, 8 Oct 2012 19:16:03 +0100
From: Andrew Cooper 
To: 
Cc: Keir Fraser , Jan Beulich 
Subject: [Xen-devel] [PATCH 3 of 3] xen/debug: Introduce ASSERT_RUN()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a variant of ASSERT() which takes a predicate, a function an
argument for the function.  It is designed for debugging in situations
where ASSERT_PRINTK() is perhaps not powerful enough.

It will run the given function with the given argument before the BUG()
which kills Xen.

Signed-off-by: Andrew Cooper 

diff -r 477ccdb9870e -r 0a1a3f35f56a xen/include/xen/lib.h
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -48,6 +48,16 @@ do {                                    
 } while (0)
 #endif /* assert_printk_failed */
 
+#ifndef assert_run_failed
+#define assert_run_failed(p, func, arg)                         \
+do {                                                            \
+    printk("Assertion '%s' failed, line %d, file %s\n", p ,     \
+                   __LINE__, __FILE__);                         \
+    (func)((arg));                                              \
+    BUG();                                                      \
+} while (0)
+#endif /* assert_run_failed */
+
 #ifdef CONFIG_ASSERTS
 #define ASSERT(p) \
     do { if ( unlikely(!(p)) ) assert_failed(#p); } while (0)
@@ -55,9 +65,15 @@ do {                                    
 #define ASSERT_PRINTK(p, ...)                                   \
     do { if ( unlikely(!(p)) )                                  \
             assert_printk_failed(#p, __VA_ARGS__); } while (0)
+
+/* func expected to be void, taking a single void * argument */
+#define ASSERT_RUN(p, func, arg)                                \
+    do { if ( unlikely(!(p)) )                                  \
+            assert_run_failed(#p, func, arg); } while (0)
 #else
 #define ASSERT(p) do { if ( 0 && (p) ); } while (0)
 #define ASSERT_PRINTK(p, ...) do { if ( 0 && (p) ); } while (0)
+#define ASSERT_RUN(p, func, arg) do { if ( 0 && (p) ); } while (0)
 #endif
 
 #define ABS(_x) ({                              \

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 18:16:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 18:16:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLHse-00024b-GV; Mon, 08 Oct 2012 18:16:40 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLHsc-00023l-Op
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 18:16:38 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1349720190!9076004!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ5NjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9729 invoked from network); 8 Oct 2012 18:16:32 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 18:16:32 -0000
X-IronPort-AV: E=Sophos;i="4.80,555,1344211200"; d="scan'208";a="40490110"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 18:16:17 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 8 Oct 2012 14:16:16 -0400
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TLHsG-0000Ol-Eb;
	Mon, 08 Oct 2012 19:16:16 +0100
MIME-Version: 1.0
X-Mercurial-Node: 0a1a3f35f56a1a2b3b8f17483ccd0010733d3e53
Message-ID: <0a1a3f35f56a1a2b3b8f.1349720163@andrewcoop.uk.xensource.com>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.3.1
Date: Mon, 8 Oct 2012 19:16:03 +0100
From: Andrew Cooper 
To: 
Cc: Keir Fraser , Jan Beulich 
Subject: [Xen-devel] [PATCH 3 of 3] xen/debug: Introduce ASSERT_RUN()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a variant of ASSERT() which takes a predicate, a function an
argument for the function.  It is designed for debugging in situations
where ASSERT_PRINTK() is perhaps not powerful enough.

It will run the given function with the given argument before the BUG()
which kills Xen.

Signed-off-by: Andrew Cooper 

diff -r 477ccdb9870e -r 0a1a3f35f56a xen/include/xen/lib.h
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -48,6 +48,16 @@ do {                                    
 } while (0)
 #endif /* assert_printk_failed */
 
+#ifndef assert_run_failed
+#define assert_run_failed(p, func, arg)                         \
+do {                                                            \
+    printk("Assertion '%s' failed, line %d, file %s\n", p ,     \
+                   __LINE__, __FILE__);                         \
+    (func)((arg));                                              \
+    BUG();                                                      \
+} while (0)
+#endif /* assert_run_failed */
+
 #ifdef CONFIG_ASSERTS
 #define ASSERT(p) \
     do { if ( unlikely(!(p)) ) assert_failed(#p); } while (0)
@@ -55,9 +65,15 @@ do {                                    
 #define ASSERT_PRINTK(p, ...)                                   \
     do { if ( unlikely(!(p)) )                                  \
             assert_printk_failed(#p, __VA_ARGS__); } while (0)
+
+/* func expected to be void, taking a single void * argument */
+#define ASSERT_RUN(p, func, arg)                                \
+    do { if ( unlikely(!(p)) )                                  \
+            assert_run_failed(#p, func, arg); } while (0)
 #else
 #define ASSERT(p) do { if ( 0 && (p) ); } while (0)
 #define ASSERT_PRINTK(p, ...) do { if ( 0 && (p) ); } while (0)
+#define ASSERT_RUN(p, func, arg) do { if ( 0 && (p) ); } while (0)
 #endif
 
 #define ABS(_x) ({                              \

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 18:16:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 18:16:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLHsX-00023m-BE; Mon, 08 Oct 2012 18:16:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLHsV-00023X-Pd
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 18:16:31 +0000
Received: from [85.158.143.35:53244] by server-1.bemta-4.messagelabs.com id
	A3/8C-05684-F7813705; Mon, 08 Oct 2012 18:16:31 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1349720188!5542803!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ5NjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18587 invoked from network); 8 Oct 2012 18:16:30 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 18:16:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,555,1344211200"; d="scan'208";a="40490107"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 18:16:17 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 8 Oct 2012 14:16:16 -0400
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TLHsG-0000Ol-Cd;
	Mon, 08 Oct 2012 19:16:16 +0100
MIME-Version: 1.0
Message-ID: 
User-Agent: Mercurial-patchbomb/2.3.1
Date: Mon, 8 Oct 2012 19:16:00 +0100
From: Andrew Cooper 
To: 
Cc: Keir Fraser , Jan Beulich 
Subject: [Xen-devel] [PATCH 0 of 3] Introduce more debugging flexibility
 with ASSERT() macros
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The following three patches introduce several debugging macros I have
been using for a long time while debugging issues in Xen.

ASSERT_PRINK() is hopefully obvious, and ASSERT_RUN() is useful when
more complicated printing is required.

The final macro ASSERT_RUN_SINGLE() is not fit for upstream yet.  It is
designed to force all other PCPUs into a wait loop in an NMI context, so
the ASSERT()'ing processor can walk data structures without locks, and
without fear that values are changing under its feet.  I will work on
integrating this into the crash code (as it has a similar setup for the
start of the kexec_crash() path), and upstream when I have time.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 18:16:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 18:16:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLHsX-00023m-BE; Mon, 08 Oct 2012 18:16:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLHsV-00023X-Pd
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 18:16:31 +0000
Received: from [85.158.143.35:53244] by server-1.bemta-4.messagelabs.com id
	A3/8C-05684-F7813705; Mon, 08 Oct 2012 18:16:31 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1349720188!5542803!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ5NjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18587 invoked from network); 8 Oct 2012 18:16:30 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 18:16:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,555,1344211200"; d="scan'208";a="40490107"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 18:16:17 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 8 Oct 2012 14:16:16 -0400
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TLHsG-0000Ol-Cd;
	Mon, 08 Oct 2012 19:16:16 +0100
MIME-Version: 1.0
Message-ID: 
User-Agent: Mercurial-patchbomb/2.3.1
Date: Mon, 8 Oct 2012 19:16:00 +0100
From: Andrew Cooper 
To: 
Cc: Keir Fraser , Jan Beulich 
Subject: [Xen-devel] [PATCH 0 of 3] Introduce more debugging flexibility
 with ASSERT() macros
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The following three patches introduce several debugging macros I have
been using for a long time while debugging issues in Xen.

ASSERT_PRINK() is hopefully obvious, and ASSERT_RUN() is useful when
more complicated printing is required.

The final macro ASSERT_RUN_SINGLE() is not fit for upstream yet.  It is
designed to force all other PCPUs into a wait loop in an NMI context, so
the ASSERT()'ing processor can walk data structures without locks, and
without fear that values are changing under its feet.  I will work on
integrating this into the crash code (as it has a similar setup for the
start of the kexec_crash() path), and upstream when I have time.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 18:16:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 18:16:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLHsY-00023t-N6; Mon, 08 Oct 2012 18:16:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLHsW-00023c-La
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 18:16:32 +0000
Received: from [85.158.143.35:53318] by server-3.bemta-4.messagelabs.com id
	DA/0C-10986-F7813705; Mon, 08 Oct 2012 18:16:31 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1349720188!5542803!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ5NjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18623 invoked from network); 8 Oct 2012 18:16:31 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 18:16:31 -0000
X-IronPort-AV: E=Sophos;i="4.80,555,1344211200"; d="scan'208";a="40490108"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 18:16:17 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 8 Oct 2012 14:16:16 -0400
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TLHsG-0000Ol-DI;
	Mon, 08 Oct 2012 19:16:16 +0100
MIME-Version: 1.0
X-Mercurial-Node: 2927e18e9a7c9003c9acb39609a26e16794dda61
Message-ID: <2927e18e9a7c9003c9ac.1349720161@andrewcoop.uk.xensource.com>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.3.1
Date: Mon, 8 Oct 2012 19:16:01 +0100
From: Andrew Cooper 
To: 
Cc: Keir Fraser , Jan Beulich 
Subject: [Xen-devel] [PATCH 1 of 3] xen/debug: Allow ASSERT() to be enabled
 in a non-debug build
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

There are times when debugging that assertions are useful, without all
the other implications of a debug build.

Allow ASSERT() to be independently controlled, but defaults to the same
as $(debug)

Signed-off-by: Andrew Cooper 

diff -r 5fbdbf585f5f -r 2927e18e9a7c Config.mk
--- a/Config.mk
+++ b/Config.mk
@@ -12,6 +12,7 @@ realpath = $(wildcard $(foreach file,$(1
 # A debug build of Xen and tools?
 debug ?= y
 debug_symbols ?= $(debug)
+asserts ?= $(debug)
 
 XEN_COMPILE_ARCH    ?= $(shell uname -m | sed -e s/i.86/x86_32/ \
                          -e s/i86pc/x86_32/ -e s/amd64/x86_64/ -e s/arm.*/arm/)
diff -r 5fbdbf585f5f -r 2927e18e9a7c xen/Rules.mk
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -25,6 +25,10 @@ ifeq ($(perfc_arrays),y)
 perfc := y
 endif
 
+ifeq ($(asserts),y)
+CFLAGS += -DCONFIG_ASSERTS
+endif
+
 # Set ARCH/SUBARCH appropriately.
 override TARGET_SUBARCH  := $(XEN_TARGET_ARCH)
 override TARGET_ARCH     := $(shell echo $(XEN_TARGET_ARCH) | \
diff -r 5fbdbf585f5f -r 2927e18e9a7c xen/include/xen/lib.h
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -38,7 +38,7 @@ do {                                    
 } while (0)
 #endif
 
-#ifndef NDEBUG
+#ifdef CONFIG_ASSERTS
 #define ASSERT(p) \
     do { if ( unlikely(!(p)) ) assert_failed(#p); } while (0)
 #else

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 18:16:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 18:16:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLHsY-00023t-N6; Mon, 08 Oct 2012 18:16:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLHsW-00023c-La
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 18:16:32 +0000
Received: from [85.158.143.35:53318] by server-3.bemta-4.messagelabs.com id
	DA/0C-10986-F7813705; Mon, 08 Oct 2012 18:16:31 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1349720188!5542803!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ5NjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18623 invoked from network); 8 Oct 2012 18:16:31 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 18:16:31 -0000
X-IronPort-AV: E=Sophos;i="4.80,555,1344211200"; d="scan'208";a="40490108"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 18:16:17 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 8 Oct 2012 14:16:16 -0400
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TLHsG-0000Ol-DI;
	Mon, 08 Oct 2012 19:16:16 +0100
MIME-Version: 1.0
X-Mercurial-Node: 2927e18e9a7c9003c9acb39609a26e16794dda61
Message-ID: <2927e18e9a7c9003c9ac.1349720161@andrewcoop.uk.xensource.com>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.3.1
Date: Mon, 8 Oct 2012 19:16:01 +0100
From: Andrew Cooper 
To: 
Cc: Keir Fraser , Jan Beulich 
Subject: [Xen-devel] [PATCH 1 of 3] xen/debug: Allow ASSERT() to be enabled
 in a non-debug build
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

There are times when debugging that assertions are useful, without all
the other implications of a debug build.

Allow ASSERT() to be independently controlled, but defaults to the same
as $(debug)

Signed-off-by: Andrew Cooper 

diff -r 5fbdbf585f5f -r 2927e18e9a7c Config.mk
--- a/Config.mk
+++ b/Config.mk
@@ -12,6 +12,7 @@ realpath = $(wildcard $(foreach file,$(1
 # A debug build of Xen and tools?
 debug ?= y
 debug_symbols ?= $(debug)
+asserts ?= $(debug)
 
 XEN_COMPILE_ARCH    ?= $(shell uname -m | sed -e s/i.86/x86_32/ \
                          -e s/i86pc/x86_32/ -e s/amd64/x86_64/ -e s/arm.*/arm/)
diff -r 5fbdbf585f5f -r 2927e18e9a7c xen/Rules.mk
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -25,6 +25,10 @@ ifeq ($(perfc_arrays),y)
 perfc := y
 endif
 
+ifeq ($(asserts),y)
+CFLAGS += -DCONFIG_ASSERTS
+endif
+
 # Set ARCH/SUBARCH appropriately.
 override TARGET_SUBARCH  := $(XEN_TARGET_ARCH)
 override TARGET_ARCH     := $(shell echo $(XEN_TARGET_ARCH) | \
diff -r 5fbdbf585f5f -r 2927e18e9a7c xen/include/xen/lib.h
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -38,7 +38,7 @@ do {                                    
 } while (0)
 #endif
 
-#ifndef NDEBUG
+#ifdef CONFIG_ASSERTS
 #define ASSERT(p) \
     do { if ( unlikely(!(p)) ) assert_failed(#p); } while (0)
 #else

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 18:16:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 18:16:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLHsZ-000240-32; Mon, 08 Oct 2012 18:16:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLHsX-00023c-4H
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 18:16:33 +0000
Received: from [85.158.143.35:63361] by server-3.bemta-4.messagelabs.com id
	2E/0C-10986-08813705; Mon, 08 Oct 2012 18:16:32 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1349720188!5542803!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ5NjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18654 invoked from network); 8 Oct 2012 18:16:31 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 18:16:31 -0000
X-IronPort-AV: E=Sophos;i="4.80,555,1344211200"; d="scan'208";a="40490109"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 18:16:17 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 8 Oct 2012 14:16:16 -0400
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TLHsG-0000Ol-Dy;
	Mon, 08 Oct 2012 19:16:16 +0100
MIME-Version: 1.0
X-Mercurial-Node: 477ccdb9870ed68e33c52921d02bb2918a2bb9b4
Message-ID: <477ccdb9870ed68e33c5.1349720162@andrewcoop.uk.xensource.com>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.3.1
Date: Mon, 8 Oct 2012 19:16:02 +0100
From: Andrew Cooper 
To: 
Cc: Keir Fraser , Jan Beulich 
Subject: [Xen-devel] [PATCH 2 of 3] xen/debug: Introduce ASSERT_PRINTK()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a variant of ASSERT() which takes a predicate, and a variable
number of arguments which get fed to prink() before the BUG().

Signed-off-by: Andrew Cooper 

--
This does use C99 varadic macros, but given that we use other C99
features without #ifdef guards, I felt it not necessary to guard this as
well.

diff -r 2927e18e9a7c -r 477ccdb9870e xen/include/xen/lib.h
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -38,11 +38,26 @@ do {                                    
 } while (0)
 #endif
 
+#ifndef assert_printk_failed
+#define assert_printk_failed(p, ...)                            \
+do {                                                            \
+    printk("Assertion '%s' failed, line %d, file %s\n", p ,     \
+                   __LINE__, __FILE__);                         \
+    printk(__VA_ARGS__);                                        \
+    BUG();                                                      \
+} while (0)
+#endif /* assert_printk_failed */
+
 #ifdef CONFIG_ASSERTS
 #define ASSERT(p) \
     do { if ( unlikely(!(p)) ) assert_failed(#p); } while (0)
+
+#define ASSERT_PRINTK(p, ...)                                   \
+    do { if ( unlikely(!(p)) )                                  \
+            assert_printk_failed(#p, __VA_ARGS__); } while (0)
 #else
 #define ASSERT(p) do { if ( 0 && (p) ); } while (0)
+#define ASSERT_PRINTK(p, ...) do { if ( 0 && (p) ); } while (0)
 #endif
 
 #define ABS(_x) ({                              \

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 18:16:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 18:16:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLHsZ-000240-32; Mon, 08 Oct 2012 18:16:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLHsX-00023c-4H
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 18:16:33 +0000
Received: from [85.158.143.35:63361] by server-3.bemta-4.messagelabs.com id
	2E/0C-10986-08813705; Mon, 08 Oct 2012 18:16:32 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1349720188!5542803!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ5NjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18654 invoked from network); 8 Oct 2012 18:16:31 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 18:16:31 -0000
X-IronPort-AV: E=Sophos;i="4.80,555,1344211200"; d="scan'208";a="40490109"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 18:16:17 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 8 Oct 2012 14:16:16 -0400
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TLHsG-0000Ol-Dy;
	Mon, 08 Oct 2012 19:16:16 +0100
MIME-Version: 1.0
X-Mercurial-Node: 477ccdb9870ed68e33c52921d02bb2918a2bb9b4
Message-ID: <477ccdb9870ed68e33c5.1349720162@andrewcoop.uk.xensource.com>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.3.1
Date: Mon, 8 Oct 2012 19:16:02 +0100
From: Andrew Cooper 
To: 
Cc: Keir Fraser , Jan Beulich 
Subject: [Xen-devel] [PATCH 2 of 3] xen/debug: Introduce ASSERT_PRINTK()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a variant of ASSERT() which takes a predicate, and a variable
number of arguments which get fed to prink() before the BUG().

Signed-off-by: Andrew Cooper 

--
This does use C99 varadic macros, but given that we use other C99
features without #ifdef guards, I felt it not necessary to guard this as
well.

diff -r 2927e18e9a7c -r 477ccdb9870e xen/include/xen/lib.h
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -38,11 +38,26 @@ do {                                    
 } while (0)
 #endif
 
+#ifndef assert_printk_failed
+#define assert_printk_failed(p, ...)                            \
+do {                                                            \
+    printk("Assertion '%s' failed, line %d, file %s\n", p ,     \
+                   __LINE__, __FILE__);                         \
+    printk(__VA_ARGS__);                                        \
+    BUG();                                                      \
+} while (0)
+#endif /* assert_printk_failed */
+
 #ifdef CONFIG_ASSERTS
 #define ASSERT(p) \
     do { if ( unlikely(!(p)) ) assert_failed(#p); } while (0)
+
+#define ASSERT_PRINTK(p, ...)                                   \
+    do { if ( unlikely(!(p)) )                                  \
+            assert_printk_failed(#p, __VA_ARGS__); } while (0)
 #else
 #define ASSERT(p) do { if ( 0 && (p) ); } while (0)
+#define ASSERT_PRINTK(p, ...) do { if ( 0 && (p) ); } while (0)
 #endif
 
 #define ABS(_x) ({                              \

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 18:32:18 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 18:32:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLI7T-0002cB-0C; Mon, 08 Oct 2012 18:31:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLI7Q-0002c6-P9
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 18:31:57 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1349721110!13869361!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1600 invoked from network); 8 Oct 2012 18:31:50 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 18:31:50 -0000
Received: by mail-wg0-f51.google.com with SMTP id ed3so2404956wgb.32
	for ; Mon, 08 Oct 2012 11:31:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=hEe2wEy1z8fYCKAoQsFacmTYMf2MtfWv//8ETYJMhus=;
	b=koJXbiIMvAu1gslHNVGVYv319ZATQFJJuymWF/LtE1s2Uac1Rnx9uFHTIOb9Tk6wQW
	nJ9i+Ii1v6cxzMjAZDfO50n6kE9rCn9Fx9w6q6wOUSnDDgAhIjsw+zu8gkUYPKa1BITh
	eSGWBfepNQ1Z0jGILF12mjP+jNfDcf1B6gcPBrw8N8+6wSZty03fb2dYyq2Y1+cSQyjv
	VcDVjdOWypa9UuEoZPyUzFAfgcM6IUHyQfxMfipinv8cisI54Id/isqc+rp4NijbTAFT
	VGnIWInjVokv3LHbfP+3MbNcO7BCsayRs0KpBlbbCDbF1C3XDDlHMMqsFpxIaJCvnqbJ
	U0ug==
Received: by 10.216.197.104 with SMTP id s82mr10066725wen.62.1349721109896;
	Mon, 08 Oct 2012 11:31:49 -0700 (PDT)
Received: from [192.168.1.69]
	(host86-183-156-141.range86-183.btcentralplus.com. [86.183.156.141])
	by mx.google.com with ESMTPS id ei1sm23227886wid.7.2012.10.08.11.31.47
	(version=SSLv3 cipher=OTHER); Mon, 08 Oct 2012 11:31:49 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 08 Oct 2012 19:31:40 +0100
From: Keir Fraser 
To: Andrew Cooper ,
	
Message-ID: 
Thread-Topic: [PATCH 0 of 3] Introduce more debugging flexibility with
	ASSERT() macros
Thread-Index: Ac2lgyhbHBZxfqihB0u1/+C0BJiNkA==
In-Reply-To: 
Mime-version: 1.0
Cc: Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 0 of 3] Introduce more debugging flexibility
 with ASSERT() macros
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 08/10/2012 19:16, "Andrew Cooper"  wrote:

> The following three patches introduce several debugging macros I have
> been using for a long time while debugging issues in Xen.
> 
> ASSERT_PRINK() is hopefully obvious, and ASSERT_RUN() is useful when
> more complicated printing is required.

Are these going to get enough use to be worthwhile, rather than open-coding
them where necessary? In many places we may not care about being able to
disable the check-and-crash, so avoiding ifdefs is not necessarily a good
argument.

 -- Keir

> The final macro ASSERT_RUN_SINGLE() is not fit for upstream yet.  It is
> designed to force all other PCPUs into a wait loop in an NMI context, so
> the ASSERT()'ing processor can walk data structures without locks, and
> without fear that values are changing under its feet.  I will work on
> integrating this into the crash code (as it has a similar setup for the
> start of the kexec_crash() path), and upstream when I have time.
> 
> ~Andrew



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 18:32:18 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 18:32:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLI7T-0002cB-0C; Mon, 08 Oct 2012 18:31:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLI7Q-0002c6-P9
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 18:31:57 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1349721110!13869361!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1600 invoked from network); 8 Oct 2012 18:31:50 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 18:31:50 -0000
Received: by mail-wg0-f51.google.com with SMTP id ed3so2404956wgb.32
	for ; Mon, 08 Oct 2012 11:31:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=hEe2wEy1z8fYCKAoQsFacmTYMf2MtfWv//8ETYJMhus=;
	b=koJXbiIMvAu1gslHNVGVYv319ZATQFJJuymWF/LtE1s2Uac1Rnx9uFHTIOb9Tk6wQW
	nJ9i+Ii1v6cxzMjAZDfO50n6kE9rCn9Fx9w6q6wOUSnDDgAhIjsw+zu8gkUYPKa1BITh
	eSGWBfepNQ1Z0jGILF12mjP+jNfDcf1B6gcPBrw8N8+6wSZty03fb2dYyq2Y1+cSQyjv
	VcDVjdOWypa9UuEoZPyUzFAfgcM6IUHyQfxMfipinv8cisI54Id/isqc+rp4NijbTAFT
	VGnIWInjVokv3LHbfP+3MbNcO7BCsayRs0KpBlbbCDbF1C3XDDlHMMqsFpxIaJCvnqbJ
	U0ug==
Received: by 10.216.197.104 with SMTP id s82mr10066725wen.62.1349721109896;
	Mon, 08 Oct 2012 11:31:49 -0700 (PDT)
Received: from [192.168.1.69]
	(host86-183-156-141.range86-183.btcentralplus.com. [86.183.156.141])
	by mx.google.com with ESMTPS id ei1sm23227886wid.7.2012.10.08.11.31.47
	(version=SSLv3 cipher=OTHER); Mon, 08 Oct 2012 11:31:49 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 08 Oct 2012 19:31:40 +0100
From: Keir Fraser 
To: Andrew Cooper ,
	
Message-ID: 
Thread-Topic: [PATCH 0 of 3] Introduce more debugging flexibility with
	ASSERT() macros
Thread-Index: Ac2lgyhbHBZxfqihB0u1/+C0BJiNkA==
In-Reply-To: 
Mime-version: 1.0
Cc: Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 0 of 3] Introduce more debugging flexibility
 with ASSERT() macros
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 08/10/2012 19:16, "Andrew Cooper"  wrote:

> The following three patches introduce several debugging macros I have
> been using for a long time while debugging issues in Xen.
> 
> ASSERT_PRINK() is hopefully obvious, and ASSERT_RUN() is useful when
> more complicated printing is required.

Are these going to get enough use to be worthwhile, rather than open-coding
them where necessary? In many places we may not care about being able to
disable the check-and-crash, so avoiding ifdefs is not necessarily a good
argument.

 -- Keir

> The final macro ASSERT_RUN_SINGLE() is not fit for upstream yet.  It is
> designed to force all other PCPUs into a wait loop in an NMI context, so
> the ASSERT()'ing processor can walk data structures without locks, and
> without fear that values are changing under its feet.  I will work on
> integrating this into the crash code (as it has a similar setup for the
> start of the kexec_crash() path), and upstream when I have time.
> 
> ~Andrew



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 18:56:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 18:56:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLIUF-0002oT-5l; Mon, 08 Oct 2012 18:55:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLIUD-0002o0-KJ
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 18:55:29 +0000
Received: from [85.158.137.99:60732] by server-15.bemta-3.messagelabs.com id
	74/F6-11584-0A123705; Mon, 08 Oct 2012 18:55:28 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1349722524!15959420!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ5NjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20158 invoked from network); 8 Oct 2012 18:55:28 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 18:55:28 -0000
X-IronPort-AV: E=Sophos;i="4.80,555,1344211200"; d="scan'208";a="40494763"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 18:55:24 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 8 Oct 2012 14:55:23 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TLIU7-0000wn-Fw;
	Mon, 08 Oct 2012 19:55:23 +0100
From: Anthony PERARD 
To: Xen Devel 
Date: Mon, 8 Oct 2012 19:55:19 +0100
Message-ID: <1349722522-25748-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12.2
MIME-Version: 1.0
Cc: Anthony PERARD ,
	Ian Jackson ,
	Ian Campbell 
Subject: [Xen-devel] [PATCH V2 0/3] libxl cd-insert/eject with qemu-xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch series provides the facility to eject and insert a cdrom when the
used device-model is qemu-xen. The only difference between both device-model is
a call to a QMP command as `xl cd-insert ...` will still update xenstore, even
if it's not used by QEMU.


Change since v1:
  - Update first patch to use new facilities introduce by my previous applied series.
  - Use the disk dev number instead of the vdev string as on id for the cdrom.


Anthony PERARD (3):
  libxl_qmp, Introduce libxl__qmp_insert_cdrom.
  libxl_dm: Set an id to cdrom drives with qemuu.
  libxl: Fix cd-insert with qemu-xen.

 tools/libxl/libxl.c          | 12 ++++++------
 tools/libxl/libxl_dm.c       |  7 ++++---
 tools/libxl/libxl_internal.h |  1 +
 tools/libxl/libxl_qmp.c      | 16 ++++++++++++++++
 4 files changed, 27 insertions(+), 9 deletions(-)

-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 18:56:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 18:56:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLIUF-0002oT-5l; Mon, 08 Oct 2012 18:55:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLIUD-0002o0-KJ
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 18:55:29 +0000
Received: from [85.158.137.99:60732] by server-15.bemta-3.messagelabs.com id
	74/F6-11584-0A123705; Mon, 08 Oct 2012 18:55:28 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1349722524!15959420!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ5NjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20158 invoked from network); 8 Oct 2012 18:55:28 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 18:55:28 -0000
X-IronPort-AV: E=Sophos;i="4.80,555,1344211200"; d="scan'208";a="40494763"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 18:55:24 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 8 Oct 2012 14:55:23 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TLIU7-0000wn-Fw;
	Mon, 08 Oct 2012 19:55:23 +0100
From: Anthony PERARD 
To: Xen Devel 
Date: Mon, 8 Oct 2012 19:55:19 +0100
Message-ID: <1349722522-25748-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12.2
MIME-Version: 1.0
Cc: Anthony PERARD ,
	Ian Jackson ,
	Ian Campbell 
Subject: [Xen-devel] [PATCH V2 0/3] libxl cd-insert/eject with qemu-xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch series provides the facility to eject and insert a cdrom when the
used device-model is qemu-xen. The only difference between both device-model is
a call to a QMP command as `xl cd-insert ...` will still update xenstore, even
if it's not used by QEMU.


Change since v1:
  - Update first patch to use new facilities introduce by my previous applied series.
  - Use the disk dev number instead of the vdev string as on id for the cdrom.


Anthony PERARD (3):
  libxl_qmp, Introduce libxl__qmp_insert_cdrom.
  libxl_dm: Set an id to cdrom drives with qemuu.
  libxl: Fix cd-insert with qemu-xen.

 tools/libxl/libxl.c          | 12 ++++++------
 tools/libxl/libxl_dm.c       |  7 ++++---
 tools/libxl/libxl_internal.h |  1 +
 tools/libxl/libxl_qmp.c      | 16 ++++++++++++++++
 4 files changed, 27 insertions(+), 9 deletions(-)

-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 18:56:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 18:56:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLIUE-0002oL-P8; Mon, 08 Oct 2012 18:55:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLIUD-0002nr-0b
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 18:55:29 +0000
Received: from [85.158.137.99:60716] by server-4.bemta-3.messagelabs.com id
	0E/04-14155-0A123705; Mon, 08 Oct 2012 18:55:28 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1349722524!15959420!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ5NjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20131 invoked from network); 8 Oct 2012 18:55:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 18:55:27 -0000
X-IronPort-AV: E=Sophos;i="4.80,555,1344211200"; d="scan'208";a="40494766"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 18:55:24 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 8 Oct 2012 14:55:23 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TLIU7-0000wn-Hi;
	Mon, 08 Oct 2012 19:55:23 +0100
From: Anthony PERARD 
To: Xen Devel 
Date: Mon, 8 Oct 2012 19:55:20 +0100
Message-ID: <1349722522-25748-2-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12.2
In-Reply-To: <1349722522-25748-1-git-send-email-anthony.perard@citrix.com>
References: <1349722522-25748-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD ,
	Ian Jackson ,
	Ian Campbell 
Subject: [Xen-devel] [PATCH V2 1/3] libxl_qmp,
	Introduce libxl__qmp_insert_cdrom.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This function can eject or change the CDROM for a guest that use qemu-xen as a
device-model.

Signed-off-by: Anthony PERARD 
---
 tools/libxl/libxl_internal.h |  1 +
 tools/libxl/libxl_qmp.c      | 16 ++++++++++++++++
 2 files changed, 17 insertions(+)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index afa36a7..4240ef2 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1406,6 +1406,7 @@ _hidden int libxl__qmp_resume(libxl__gc *gc, int domid);
 _hidden int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename);
 /* Set dirty bitmap logging status */
 _hidden int libxl__qmp_set_global_dirty_log(libxl__gc *gc, int domid, bool enable);
+_hidden int libxl__qmp_insert_cdrom(libxl__gc *gc, int domid, const libxl_device_disk *disk);
 /* close and free the QMP handler */
 _hidden void libxl__qmp_close(libxl__qmp_handler *qmp);
 /* remove the socket file, if the file has already been removed,
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 5fa0c65..7f1dd98 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -913,6 +913,22 @@ int libxl__qmp_set_global_dirty_log(libxl__gc *gc, int domid, bool enable)
                            NULL, NULL);
 }
 
+int libxl__qmp_insert_cdrom(libxl__gc *gc, int domid,
+                            const libxl_device_disk *disk)
+{
+    libxl__json_object *args = NULL;
+    int dev_number = libxl__device_disk_dev_number(disk->vdev, NULL, NULL);
+
+    QMP_PARAMETERS_SPRINTF(&args, "device", "ide-%i", dev_number);
+
+    if (disk->format == LIBXL_DISK_FORMAT_EMPTY) {
+        return qmp_run_command(gc, domid, "eject", args, NULL, NULL);
+    } else {
+        qmp_parameters_add_string(gc, &args, "target", disk->pdev_path);
+        return qmp_run_command(gc, domid, "change", args, NULL, NULL);
+    }
+}
+
 int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid,
                                const libxl_domain_config *guest_config)
 {
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 18:56:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 18:56:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLIUE-0002oL-P8; Mon, 08 Oct 2012 18:55:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLIUD-0002nr-0b
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 18:55:29 +0000
Received: from [85.158.137.99:60716] by server-4.bemta-3.messagelabs.com id
	0E/04-14155-0A123705; Mon, 08 Oct 2012 18:55:28 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1349722524!15959420!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ5NjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20131 invoked from network); 8 Oct 2012 18:55:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 18:55:27 -0000
X-IronPort-AV: E=Sophos;i="4.80,555,1344211200"; d="scan'208";a="40494766"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 18:55:24 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 8 Oct 2012 14:55:23 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TLIU7-0000wn-Hi;
	Mon, 08 Oct 2012 19:55:23 +0100
From: Anthony PERARD 
To: Xen Devel 
Date: Mon, 8 Oct 2012 19:55:20 +0100
Message-ID: <1349722522-25748-2-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12.2
In-Reply-To: <1349722522-25748-1-git-send-email-anthony.perard@citrix.com>
References: <1349722522-25748-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD ,
	Ian Jackson ,
	Ian Campbell 
Subject: [Xen-devel] [PATCH V2 1/3] libxl_qmp,
	Introduce libxl__qmp_insert_cdrom.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This function can eject or change the CDROM for a guest that use qemu-xen as a
device-model.

Signed-off-by: Anthony PERARD 
---
 tools/libxl/libxl_internal.h |  1 +
 tools/libxl/libxl_qmp.c      | 16 ++++++++++++++++
 2 files changed, 17 insertions(+)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index afa36a7..4240ef2 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1406,6 +1406,7 @@ _hidden int libxl__qmp_resume(libxl__gc *gc, int domid);
 _hidden int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename);
 /* Set dirty bitmap logging status */
 _hidden int libxl__qmp_set_global_dirty_log(libxl__gc *gc, int domid, bool enable);
+_hidden int libxl__qmp_insert_cdrom(libxl__gc *gc, int domid, const libxl_device_disk *disk);
 /* close and free the QMP handler */
 _hidden void libxl__qmp_close(libxl__qmp_handler *qmp);
 /* remove the socket file, if the file has already been removed,
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 5fa0c65..7f1dd98 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -913,6 +913,22 @@ int libxl__qmp_set_global_dirty_log(libxl__gc *gc, int domid, bool enable)
                            NULL, NULL);
 }
 
+int libxl__qmp_insert_cdrom(libxl__gc *gc, int domid,
+                            const libxl_device_disk *disk)
+{
+    libxl__json_object *args = NULL;
+    int dev_number = libxl__device_disk_dev_number(disk->vdev, NULL, NULL);
+
+    QMP_PARAMETERS_SPRINTF(&args, "device", "ide-%i", dev_number);
+
+    if (disk->format == LIBXL_DISK_FORMAT_EMPTY) {
+        return qmp_run_command(gc, domid, "eject", args, NULL, NULL);
+    } else {
+        qmp_parameters_add_string(gc, &args, "target", disk->pdev_path);
+        return qmp_run_command(gc, domid, "change", args, NULL, NULL);
+    }
+}
+
 int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid,
                                const libxl_domain_config *guest_config)
 {
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 18:56:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 18:56:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLIUD-0002nw-1I; Mon, 08 Oct 2012 18:55:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLIUB-0002nl-Im
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 18:55:27 +0000
Received: from [85.158.137.99:27473] by server-11.bemta-3.messagelabs.com id
	7B/D4-21460-E9123705; Mon, 08 Oct 2012 18:55:26 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1349722524!15959420!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ5NjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20064 invoked from network); 8 Oct 2012 18:55:26 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 18:55:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,555,1344211200"; d="scan'208";a="40494764"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 18:55:24 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 8 Oct 2012 14:55:24 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TLIU7-0000wn-IO;
	Mon, 08 Oct 2012 19:55:23 +0100
From: Anthony PERARD 
To: Xen Devel 
Date: Mon, 8 Oct 2012 19:55:22 +0100
Message-ID: <1349722522-25748-4-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12.2
In-Reply-To: <1349722522-25748-1-git-send-email-anthony.perard@citrix.com>
References: <1349722522-25748-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD ,
	Ian Jackson ,
	Ian Campbell 
Subject: [Xen-devel] [PATCH V2 3/3] libxl: Fix cd-insert with qemu-xen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

If qemu-xen is used as a device model, the command to insert, change or eject a
cdrom will go through QMP. XenStore is still updated even if QEMU will not read
from it.

Signed-off-by: Anthony PERARD 
---
 tools/libxl/libxl.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 0cf4768..3366ccf 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2141,12 +2141,6 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk,
         rc = ERROR_FAIL;
         goto out;
     }
-    if (dm_ver != LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL) {
-        LOG(ERROR, "cdrom-insert does not work with %s",
-            libxl_device_model_version_to_string(dm_ver));
-        rc = ERROR_INVAL;
-        goto out;
-    }
 
     disks = libxl_device_disk_list(ctx, domid, &num);
     for (i = 0; i < num; i++) {
@@ -2170,6 +2164,12 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk,
 
     rc = libxl__device_from_disk(gc, domid, disk, &device);
     if (rc) goto out;
+
+    if (dm_ver == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
+        rc = libxl__qmp_insert_cdrom(gc, domid, disk);
+        if (rc) goto out;
+    }
+
     path = libxl__device_backend_path(gc, &device);
 
     insert = flexarray_make(gc, 4, 1);
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 18:56:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 18:56:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLIUD-0002nw-1I; Mon, 08 Oct 2012 18:55:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLIUB-0002nl-Im
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 18:55:27 +0000
Received: from [85.158.137.99:27473] by server-11.bemta-3.messagelabs.com id
	7B/D4-21460-E9123705; Mon, 08 Oct 2012 18:55:26 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1349722524!15959420!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ5NjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20064 invoked from network); 8 Oct 2012 18:55:26 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 18:55:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,555,1344211200"; d="scan'208";a="40494764"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 18:55:24 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 8 Oct 2012 14:55:24 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TLIU7-0000wn-IO;
	Mon, 08 Oct 2012 19:55:23 +0100
From: Anthony PERARD 
To: Xen Devel 
Date: Mon, 8 Oct 2012 19:55:22 +0100
Message-ID: <1349722522-25748-4-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12.2
In-Reply-To: <1349722522-25748-1-git-send-email-anthony.perard@citrix.com>
References: <1349722522-25748-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD ,
	Ian Jackson ,
	Ian Campbell 
Subject: [Xen-devel] [PATCH V2 3/3] libxl: Fix cd-insert with qemu-xen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

If qemu-xen is used as a device model, the command to insert, change or eject a
cdrom will go through QMP. XenStore is still updated even if QEMU will not read
from it.

Signed-off-by: Anthony PERARD 
---
 tools/libxl/libxl.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 0cf4768..3366ccf 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2141,12 +2141,6 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk,
         rc = ERROR_FAIL;
         goto out;
     }
-    if (dm_ver != LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL) {
-        LOG(ERROR, "cdrom-insert does not work with %s",
-            libxl_device_model_version_to_string(dm_ver));
-        rc = ERROR_INVAL;
-        goto out;
-    }
 
     disks = libxl_device_disk_list(ctx, domid, &num);
     for (i = 0; i < num; i++) {
@@ -2170,6 +2164,12 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk,
 
     rc = libxl__device_from_disk(gc, domid, disk, &device);
     if (rc) goto out;
+
+    if (dm_ver == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
+        rc = libxl__qmp_insert_cdrom(gc, domid, disk);
+        if (rc) goto out;
+    }
+
     path = libxl__device_backend_path(gc, &device);
 
     insert = flexarray_make(gc, 4, 1);
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 18:56:44 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 18:56:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLIUD-0002o8-D2; Mon, 08 Oct 2012 18:55:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLIUC-0002nm-8Z
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 18:55:28 +0000
Received: from [85.158.137.99:27481] by server-10.bemta-3.messagelabs.com id
	AD/DA-02525-F9123705; Mon, 08 Oct 2012 18:55:27 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1349722524!15959420!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ5NjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20103 invoked from network); 8 Oct 2012 18:55:26 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 18:55:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,555,1344211200"; d="scan'208";a="40494765"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 18:55:24 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 8 Oct 2012 14:55:24 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TLIU7-0000wn-I3;
	Mon, 08 Oct 2012 19:55:23 +0100
From: Anthony PERARD 
To: Xen Devel 
Date: Mon, 8 Oct 2012 19:55:21 +0100
Message-ID: <1349722522-25748-3-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12.2
In-Reply-To: <1349722522-25748-1-git-send-email-anthony.perard@citrix.com>
References: <1349722522-25748-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD ,
	Ian Jackson ,
	Ian Campbell 
Subject: [Xen-devel] [PATCH V2 2/3] libxl_dm: Set an id to cdrom drives with
	qemuu.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In order to eject and change a cdrom when using qemu-xen, this patch adds an id
the cdrom driver when starting the device model.

Signed-off-by: Anthony PERARD 
---
 tools/libxl/libxl_dm.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 054da3e..c036dc1 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -544,11 +544,12 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
             if (disks[i].is_cdrom) {
                 if (disks[i].format == LIBXL_DISK_FORMAT_EMPTY)
                     drive = libxl__sprintf
-                        (gc, "if=ide,index=%d,media=cdrom,cache=writeback", disk);
+                        (gc, "if=ide,index=%d,media=cdrom,cache=writeback,id=ide-%i",
+                         disk, dev_number);
                 else
                     drive = libxl__sprintf
-                        (gc, "file=%s,if=ide,index=%d,media=cdrom,format=%s,cache=writeback",
-                         disks[i].pdev_path, disk, format);
+                        (gc, "file=%s,if=ide,index=%d,media=cdrom,format=%s,cache=writeback,id=ide-%i",
+                         disks[i].pdev_path, disk, format, dev_number);
             } else {
                 if (disks[i].format == LIBXL_DISK_FORMAT_EMPTY) {
                     LIBXL__LOG(ctx, LIBXL__LOG_WARNING, "cannot support"
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 18:56:44 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 18:56:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLIUD-0002o8-D2; Mon, 08 Oct 2012 18:55:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLIUC-0002nm-8Z
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 18:55:28 +0000
Received: from [85.158.137.99:27481] by server-10.bemta-3.messagelabs.com id
	AD/DA-02525-F9123705; Mon, 08 Oct 2012 18:55:27 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1349722524!15959420!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzQ5NjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20103 invoked from network); 8 Oct 2012 18:55:26 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 18:55:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,555,1344211200"; d="scan'208";a="40494765"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 18:55:24 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 8 Oct 2012 14:55:24 -0400
Received: from [10.80.3.61] (helo=perard.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TLIU7-0000wn-I3;
	Mon, 08 Oct 2012 19:55:23 +0100
From: Anthony PERARD 
To: Xen Devel 
Date: Mon, 8 Oct 2012 19:55:21 +0100
Message-ID: <1349722522-25748-3-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12.2
In-Reply-To: <1349722522-25748-1-git-send-email-anthony.perard@citrix.com>
References: <1349722522-25748-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD ,
	Ian Jackson ,
	Ian Campbell 
Subject: [Xen-devel] [PATCH V2 2/3] libxl_dm: Set an id to cdrom drives with
	qemuu.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In order to eject and change a cdrom when using qemu-xen, this patch adds an id
the cdrom driver when starting the device model.

Signed-off-by: Anthony PERARD 
---
 tools/libxl/libxl_dm.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 054da3e..c036dc1 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -544,11 +544,12 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
             if (disks[i].is_cdrom) {
                 if (disks[i].format == LIBXL_DISK_FORMAT_EMPTY)
                     drive = libxl__sprintf
-                        (gc, "if=ide,index=%d,media=cdrom,cache=writeback", disk);
+                        (gc, "if=ide,index=%d,media=cdrom,cache=writeback,id=ide-%i",
+                         disk, dev_number);
                 else
                     drive = libxl__sprintf
-                        (gc, "file=%s,if=ide,index=%d,media=cdrom,format=%s,cache=writeback",
-                         disks[i].pdev_path, disk, format);
+                        (gc, "file=%s,if=ide,index=%d,media=cdrom,format=%s,cache=writeback,id=ide-%i",
+                         disks[i].pdev_path, disk, format, dev_number);
             } else {
                 if (disks[i].format == LIBXL_DISK_FORMAT_EMPTY) {
                     LIBXL__LOG(ctx, LIBXL__LOG_WARNING, "cannot support"
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 19:07:22 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 19:07:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLIfV-0003RX-L6; Mon, 08 Oct 2012 19:07:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLIfU-0003RS-0z
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 19:07:08 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-5.tower-27.messagelabs.com!1349723220!7808293!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18191 invoked from network); 8 Oct 2012 19:07:01 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 19:07:01 -0000
Received: from ([128.244.207.97])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.154547830;
	Mon, 08 Oct 2012 15:06:44 -0400
From: Matthew Fioravante 
To: xen-devel@lists.xen.org, ian.campbell@citrix.com,
	samuel.thibault@ens-lyon.org
Date: Mon,  8 Oct 2012 15:06:41 -0400
Message-Id: <1349723202-14608-1-git-send-email-matthew.fioravante@jhuapl.edu>
X-Mailer: git-send-email 1.7.4.4
Cc: Matthew Fioravante 
Subject: [Xen-devel] [PATCH vtpm v3 06/12] add select definition to
	sys/time.h when HAVE_LIBC is defined
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch adds the select function to sys/time.h when HAVE_LIBC is
defined, which is according to standard (see the select() manpage).
It also removes a redudant lwip include from posix/sys/select.h.

Signed-off-by: Matthew Fioravante 

diff --git a/extras/mini-os/include/posix/sys/select.h b/extras/mini-os/include/posix/sys/select.h
index a9337be..5132c51 100644
--- a/extras/mini-os/include/posix/sys/select.h
+++ b/extras/mini-os/include/posix/sys/select.h
@@ -2,7 +2,6 @@
 #define _POSIX_SELECT_H
 
 #include 
-#include 
 int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);
 
 #endif /* _POSIX_SELECT_H */
diff --git a/extras/mini-os/include/sys/time.h b/extras/mini-os/include/sys/time.h
index d6623a4..3be3653 100644
--- a/extras/mini-os/include/sys/time.h
+++ b/extras/mini-os/include/sys/time.h
@@ -22,6 +22,7 @@
 
 #ifdef HAVE_LIBC
 #include_next 
+
 #else
 struct timespec {
     time_t      tv_sec;
@@ -37,6 +38,10 @@ struct timeval {
 };
 
 int      gettimeofday(struct timeval *tv, void *tz);
+
+#endif
+#ifdef HAVE_LIBC
+#include 
 #endif
 
 #endif /* _MINIOS_SYS_TIME_H_ */
-- 
1.7.4.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 19:07:22 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 19:07:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLIfV-0003RX-L6; Mon, 08 Oct 2012 19:07:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLIfU-0003RS-0z
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 19:07:08 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-5.tower-27.messagelabs.com!1349723220!7808293!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18191 invoked from network); 8 Oct 2012 19:07:01 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 19:07:01 -0000
Received: from ([128.244.207.97])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.154547830;
	Mon, 08 Oct 2012 15:06:44 -0400
From: Matthew Fioravante 
To: xen-devel@lists.xen.org, ian.campbell@citrix.com,
	samuel.thibault@ens-lyon.org
Date: Mon,  8 Oct 2012 15:06:41 -0400
Message-Id: <1349723202-14608-1-git-send-email-matthew.fioravante@jhuapl.edu>
X-Mailer: git-send-email 1.7.4.4
Cc: Matthew Fioravante 
Subject: [Xen-devel] [PATCH vtpm v3 06/12] add select definition to
	sys/time.h when HAVE_LIBC is defined
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch adds the select function to sys/time.h when HAVE_LIBC is
defined, which is according to standard (see the select() manpage).
It also removes a redudant lwip include from posix/sys/select.h.

Signed-off-by: Matthew Fioravante 

diff --git a/extras/mini-os/include/posix/sys/select.h b/extras/mini-os/include/posix/sys/select.h
index a9337be..5132c51 100644
--- a/extras/mini-os/include/posix/sys/select.h
+++ b/extras/mini-os/include/posix/sys/select.h
@@ -2,7 +2,6 @@
 #define _POSIX_SELECT_H
 
 #include 
-#include 
 int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);
 
 #endif /* _POSIX_SELECT_H */
diff --git a/extras/mini-os/include/sys/time.h b/extras/mini-os/include/sys/time.h
index d6623a4..3be3653 100644
--- a/extras/mini-os/include/sys/time.h
+++ b/extras/mini-os/include/sys/time.h
@@ -22,6 +22,7 @@
 
 #ifdef HAVE_LIBC
 #include_next 
+
 #else
 struct timespec {
     time_t      tv_sec;
@@ -37,6 +38,10 @@ struct timeval {
 };
 
 int      gettimeofday(struct timeval *tv, void *tz);
+
+#endif
+#ifdef HAVE_LIBC
+#include 
 #endif
 
 #endif /* _MINIOS_SYS_TIME_H_ */
-- 
1.7.4.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 19:11:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 19:11:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLIjQ-0003Z2-9t; Mon, 08 Oct 2012 19:11:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLIjO-0003Yt-Od
	for Xen-devel@lists.xensource.com; Mon, 08 Oct 2012 19:11:10 +0000
Received: from [85.158.138.51:19086] by server-4.bemta-3.messagelabs.com id
	3C/53-14155-D4523705; Mon, 08 Oct 2012 19:11:09 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1349723467!25532696!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc5OTA1Nw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22641 invoked from network); 8 Oct 2012 19:11:09 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 19:11:09 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q98JB1O9029239
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 8 Oct 2012 19:11:02 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q98JB1Mr000251
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 8 Oct 2012 19:11:01 GMT
Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q98JB0xc003526; Mon, 8 Oct 2012 14:11:00 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 08 Oct 2012 12:11:00 -0700
Date: Mon, 8 Oct 2012 12:10:59 -0700
From: Mukesh Rathor 
To: Ian Campbell 
Message-ID: <20121008121059.60094d43@mantra.us.oracle.com>
In-Reply-To: <1349688102.18008.34.camel@zakaz.uk.xensource.com>
References: <20120921122123.33489ce1@mantra.us.oracle.com>
	<1349270495.650.144.camel@zakaz.uk.xensource.com>
	<20121003153106.65237f07@mantra.us.oracle.com>
	<1349340642.650.227.camel@zakaz.uk.xensource.com>
	<20121004112048.53767720@mantra.us.oracle.com>
	<1349428878.20946.18.camel@zakaz.uk.xensource.com>
	<20121005142240.340815be@mantra.us.oracle.com>
	<1349688102.18008.34.camel@zakaz.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "Xen-devel@lists.xensource.com" ,
	Stefano Stabellini ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH v1 7/8]: PVH privcmd changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 8 Oct 2012 10:21:42 +0100
Ian Campbell  wrote:

> On Fri, 2012-10-05 at 22:22 +0100, Mukesh Rathor wrote:
> > On Fri, 5 Oct 2012 10:21:18 +0100
> > Ian Campbell  wrote:
> > 
> > > On Thu, 2012-10-04 at 19:20 +0100, Mukesh Rathor wrote:
> > > > On Thu, 4 Oct 2012 09:50:42 +0100
> > > > Ian Campbell  wrote:
> > > > 
> > > > > 
> > > > > Won't that break because on the second call you will pass in
> > > > > the freshly allocated pointer and overwrite the exiting
> > > > > (useful) one with it?
> > > > 
> > > > No, for xlate, I just check for NULL. I didn't think it was big 
> > > > deal to special case xlate in this case. We got so many if
> > > > xlate cases already thru the code. It leaves the semantics easy
> > > > to understand: NULL == avail. 1 == locked PV. PTR == Locked
> > > > PVH. I'll add a comment this time :).
> > > 
> > > The transition from NULL => Locked PVH still needs to be done
> > > atomically and without clobbering any existing non-NULL value,
> > > otherwise it doesn't actually protect against multiple mappings
> > > like it is supposed to.
> 
> > Ok, changed it to, and tested it:
> > 
> > static int privcmd_enforce_singleshot_mapping(struct vm_area_struct
> > *vma) {
> >         if (xen_feature(XENFEAT_auto_translated_physmap)) {
> >                 int sz = sizeof(vma->vm_private_data);
> >                 return (!__cmpxchg(&vma->vm_private_data, NULL,
> > NULL, sz));
> 
> Passing NULL for both old and new values can't be right, can it? Did
> you test with something which tries to map twice?

well, if it's already set to pointer, then __cmpxchg would leave the ptr 
alone and return it. The function would then return false which would 
fail the api. OTOH, if it's NULL, it would continue and get set later.


> Also using cmpxchg instead of __cmpxchg includes the sizeof bit for
> you automatically and IIRC Coding-Style doesn't like () around return
> values.
> 
> So, I think you want:
> 	return !cmpxchg(&vma->vm_private_data, NULL, 1);

This would work also, and is prob better than to special condition
xlated.

thanks
Mukesh



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 19:11:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 19:11:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLIjQ-0003Z2-9t; Mon, 08 Oct 2012 19:11:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLIjO-0003Yt-Od
	for Xen-devel@lists.xensource.com; Mon, 08 Oct 2012 19:11:10 +0000
Received: from [85.158.138.51:19086] by server-4.bemta-3.messagelabs.com id
	3C/53-14155-D4523705; Mon, 08 Oct 2012 19:11:09 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1349723467!25532696!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc5OTA1Nw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22641 invoked from network); 8 Oct 2012 19:11:09 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 19:11:09 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q98JB1O9029239
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 8 Oct 2012 19:11:02 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q98JB1Mr000251
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 8 Oct 2012 19:11:01 GMT
Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q98JB0xc003526; Mon, 8 Oct 2012 14:11:00 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 08 Oct 2012 12:11:00 -0700
Date: Mon, 8 Oct 2012 12:10:59 -0700
From: Mukesh Rathor 
To: Ian Campbell 
Message-ID: <20121008121059.60094d43@mantra.us.oracle.com>
In-Reply-To: <1349688102.18008.34.camel@zakaz.uk.xensource.com>
References: <20120921122123.33489ce1@mantra.us.oracle.com>
	<1349270495.650.144.camel@zakaz.uk.xensource.com>
	<20121003153106.65237f07@mantra.us.oracle.com>
	<1349340642.650.227.camel@zakaz.uk.xensource.com>
	<20121004112048.53767720@mantra.us.oracle.com>
	<1349428878.20946.18.camel@zakaz.uk.xensource.com>
	<20121005142240.340815be@mantra.us.oracle.com>
	<1349688102.18008.34.camel@zakaz.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "Xen-devel@lists.xensource.com" ,
	Stefano Stabellini ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH v1 7/8]: PVH privcmd changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 8 Oct 2012 10:21:42 +0100
Ian Campbell  wrote:

> On Fri, 2012-10-05 at 22:22 +0100, Mukesh Rathor wrote:
> > On Fri, 5 Oct 2012 10:21:18 +0100
> > Ian Campbell  wrote:
> > 
> > > On Thu, 2012-10-04 at 19:20 +0100, Mukesh Rathor wrote:
> > > > On Thu, 4 Oct 2012 09:50:42 +0100
> > > > Ian Campbell  wrote:
> > > > 
> > > > > 
> > > > > Won't that break because on the second call you will pass in
> > > > > the freshly allocated pointer and overwrite the exiting
> > > > > (useful) one with it?
> > > > 
> > > > No, for xlate, I just check for NULL. I didn't think it was big 
> > > > deal to special case xlate in this case. We got so many if
> > > > xlate cases already thru the code. It leaves the semantics easy
> > > > to understand: NULL == avail. 1 == locked PV. PTR == Locked
> > > > PVH. I'll add a comment this time :).
> > > 
> > > The transition from NULL => Locked PVH still needs to be done
> > > atomically and without clobbering any existing non-NULL value,
> > > otherwise it doesn't actually protect against multiple mappings
> > > like it is supposed to.
> 
> > Ok, changed it to, and tested it:
> > 
> > static int privcmd_enforce_singleshot_mapping(struct vm_area_struct
> > *vma) {
> >         if (xen_feature(XENFEAT_auto_translated_physmap)) {
> >                 int sz = sizeof(vma->vm_private_data);
> >                 return (!__cmpxchg(&vma->vm_private_data, NULL,
> > NULL, sz));
> 
> Passing NULL for both old and new values can't be right, can it? Did
> you test with something which tries to map twice?

well, if it's already set to pointer, then __cmpxchg would leave the ptr 
alone and return it. The function would then return false which would 
fail the api. OTOH, if it's NULL, it would continue and get set later.


> Also using cmpxchg instead of __cmpxchg includes the sizeof bit for
> you automatically and IIRC Coding-Style doesn't like () around return
> values.
> 
> So, I think you want:
> 	return !cmpxchg(&vma->vm_private_data, NULL, 1);

This would work also, and is prob better than to special condition
xlated.

thanks
Mukesh



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 19:22:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 19:22:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLIu3-0003jv-Iv; Mon, 08 Oct 2012 19:22:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLIu2-0003jn-Hv
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 19:22:10 +0000
Received: from [85.158.137.99:16274] by server-15.bemta-3.messagelabs.com id
	0F/41-11584-1E723705; Mon, 08 Oct 2012 19:22:09 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-11.tower-217.messagelabs.com!1349724126!19551069!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD,UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28791 invoked from network); 8 Oct 2012 19:22:07 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-11.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Oct 2012 19:22:07 -0000
Received: from ([128.244.207.97])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.154547832;
	Mon, 08 Oct 2012 15:06:44 -0400
From: Matthew Fioravante 
To: xen-devel@lists.xen.org, ian.campbell@citrix.com,
	samuel.thibault@ens-lyon.org
Date: Mon,  8 Oct 2012 15:06:42 -0400
Message-Id: <1349723202-14608-2-git-send-email-matthew.fioravante@jhuapl.edu>
X-Mailer: git-send-email 1.7.4.4
In-Reply-To: <1349723202-14608-1-git-send-email-matthew.fioravante@jhuapl.edu>
References: <1349723202-14608-1-git-send-email-matthew.fioravante@jhuapl.edu>
Cc: Matthew Fioravante 
Subject: [Xen-devel] [PATCH vtpm v3 02/12] add posix io for blkfront
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch adds posix io support (read,write,lseek) to block devices
using blkfront.

Signed-off-by: Matthew Fioravante 
Acked-by: Samuel Thibault 

diff --git a/extras/mini-os/blkfront.c b/extras/mini-os/blkfront.c
index 74b8b26..f4283a9 100644
--- a/extras/mini-os/blkfront.c
+++ b/extras/mini-os/blkfront.c
@@ -392,6 +392,7 @@ void blkfront_aio(struct blkfront_aiocb *aiocbp, int write)
 static void blkfront_aio_cb(struct blkfront_aiocb *aiocbp, int ret)
 {
     aiocbp->data = (void*) 1;
+    aiocbp->aio_cb = NULL;
 }
 
 void blkfront_io(struct blkfront_aiocb *aiocbp, int write)
@@ -547,9 +548,177 @@ moretodo:
 #ifdef HAVE_LIBC
 int blkfront_open(struct blkfront_dev *dev)
 {
+    /* Silently prevent multiple opens */
+    if(dev->fd != -1) {
+       return dev->fd;
+    }
     dev->fd = alloc_fd(FTYPE_BLK);
     printk("blk_open(%s) -> %d\n", dev->nodename, dev->fd);
     files[dev->fd].blk.dev = dev;
+    files[dev->fd].blk.offset = 0;
     return dev->fd;
 }
+
+int blkfront_posix_rwop(int fd, uint8_t* buf, size_t count, int write)
+{
+   struct blkfront_dev* dev = files[fd].blk.dev;
+   off_t offset = files[fd].blk.offset;
+   struct blkfront_aiocb aiocb;
+   unsigned long long disksize = dev->info.sectors * dev->info.sector_size;
+   unsigned int blocksize = dev->info.sector_size;
+
+   int blknum;
+   int blkoff;
+   size_t bytes;
+   int rc = 0;
+   int alignedbuf = 0;
+   uint8_t* copybuf = NULL;
+
+   /* RW 0 bytes is just a NOP */
+   if(count == 0) {
+      return 0;
+   }
+   /* Check for NULL buffer */
+   if( buf == NULL ) {
+      errno = EFAULT;
+      return -1;
+   }
+
+   /* Write mode checks */
+   if(write) {
+      /*Make sure we have write permission */
+      if(dev->info.info & VDISK_READONLY 
+            || (dev->info.mode != O_RDWR  && dev->info.mode !=  O_WRONLY)) {
+         errno = EACCES;
+         return -1;
+      }
+      /*Make sure disk is big enough for this write */
+      if(offset + count > disksize) {
+         errno = ENOSPC;
+         return -1;
+      }
+   }
+   /* Read mode checks */
+   else
+   {
+      /* Reading past the disk? Just return 0 */
+      if(offset >= disksize) {
+         return 0;
+      }
+
+      /*If the requested read is bigger than the disk, just
+       * read as much as we can until the end */
+      if(offset + count > disksize) {
+         count = disksize - offset;
+      }
+   }
+   /* Determine which block to start at and at which offset inside of it */
+   blknum = offset / blocksize;
+   blkoff = offset % blocksize;
+
+   /* Optimization: We need to check if buf is aligned to the sector size.
+    * This is somewhat tricky code. We have to add the blocksize - block offset
+    * because the first block may be a partial block and then for every subsequent
+    * block rw the buffer will be offset.*/
+   if(!((uintptr_t) (buf +(blocksize -  blkoff)) & (dev->info.sector_size-1))) {
+      alignedbuf = 1;
+   }
+
+   /* Setup aiocb block object */
+   aiocb.aio_dev = dev;
+   aiocb.aio_offset = blknum * blocksize;
+   aiocb.aio_cb = NULL;
+   aiocb.data = NULL;
+
+   /* If our buffer is unaligned or its aligned but we will need to rw a partial block
+    * then a copy will have to be done */
+   if(!alignedbuf || blkoff != 0 || count % blocksize != 0) {
+      copybuf = _xmalloc(blocksize, dev->info.sector_size);
+   }
+
+   rc = count;
+   while(count > 0) {
+      /* determine how many bytes to read/write from/to the current block buffer */
+      if(!alignedbuf || blkoff != 0 || count < blocksize) {
+         /* This is the case for unaligned R/W or partial block */
+         bytes = count < blocksize - blkoff ? count : blocksize - blkoff;
+         aiocb.aio_nbytes = blocksize;
+      } else {
+         /* We can optimize further if buffer is page aligned */
+         int not_page_aligned = 0;
+         if(((uintptr_t)buf) & (PAGE_SIZE -1)) {
+            not_page_aligned = 1;
+         }
+
+         /* For an aligned R/W we can read up to the maximum transfer size */
+         bytes = count > (BLKIF_MAX_SEGMENTS_PER_REQUEST-not_page_aligned)*PAGE_SIZE 
+            ? (BLKIF_MAX_SEGMENTS_PER_REQUEST-not_page_aligned)*PAGE_SIZE
+            : count & ~(blocksize -1);
+         aiocb.aio_nbytes = bytes;
+      }
+
+      /* read operation */
+      if(!write) {
+         if (alignedbuf && bytes >= blocksize) {
+            /* If aligned and were reading a whole block, just read right into buf */
+            aiocb.aio_buf = buf;
+            blkfront_read(&aiocb);
+         } else {
+            /* If not then we have to do a copy */
+            aiocb.aio_buf = copybuf;
+            blkfront_read(&aiocb);
+            memcpy(buf, ©buf[blkoff], bytes);
+         }
+      }
+      /* Write operation */
+      else {
+         if(alignedbuf && bytes >= blocksize) {
+            /* If aligned and were writing a whole block, just write directly from buf */
+            aiocb.aio_buf = buf;
+            blkfront_write(&aiocb);
+         } else {
+            /* If not then we have to do a copy. */
+            aiocb.aio_buf = copybuf;
+            /* If we're writing a partial block, we need to read the current contents first
+             * so we don't overwrite the extra bits with garbage */
+            if(blkoff != 0 || bytes < blocksize) {
+               blkfront_read(&aiocb);
+            }
+            memcpy(©buf[blkoff], buf, bytes);
+            blkfront_write(&aiocb);
+         }
+      }
+      /* Will start at beginning of all remaining blocks */
+      blkoff = 0;
+
+      /* Increment counters and continue */
+      count -= bytes;
+      buf += bytes;
+      if(bytes < blocksize) {
+         //At minimum we read one block
+         aiocb.aio_offset += blocksize;
+      } else {
+         //If we read more than a block, was a multiple of blocksize
+         aiocb.aio_offset += bytes;
+      }
+   }
+
+   free(copybuf);
+   files[fd].blk.offset += rc;
+   return rc;
+
+}
+
+int blkfront_posix_fstat(int fd, struct stat* buf)
+{
+   struct blkfront_dev* dev = files[fd].blk.dev;
+
+   buf->st_mode = dev->info.mode;
+   buf->st_uid = 0;
+   buf->st_gid = 0;
+   buf->st_size = dev->info.sectors * dev->info.sector_size;
+   buf->st_atime = buf->st_mtime = buf->st_ctime = time(NULL);
+
+   return 0;
+}
 #endif
diff --git a/extras/mini-os/include/blkfront.h b/extras/mini-os/include/blkfront.h
index 724137e..3528af9 100644
--- a/extras/mini-os/include/blkfront.h
+++ b/extras/mini-os/include/blkfront.h
@@ -28,7 +28,17 @@ struct blkfront_info
 };
 struct blkfront_dev *init_blkfront(char *nodename, struct blkfront_info *info);
 #ifdef HAVE_LIBC
+#include 
+/* POSIX IO functions:
+ * use blkfront_open() to get a file descriptor to the block device
+ * Don't use the other blkfront posix functions here directly, instead use
+ * read(), write(), lseek() and fstat() on the file descriptor
+ */
 int blkfront_open(struct blkfront_dev *dev);
+int blkfront_posix_rwop(int fd, uint8_t* buf, size_t count, int write);
+#define blkfront_posix_write(fd, buf, count) blkfront_posix_rwop(fd, (uint8_t*)buf, count, 1)
+#define blkfront_posix_read(fd, buf, count) blkfront_posix_rwop(fd, (uint8_t*)buf, count, 0)
+int blkfront_posix_fstat(int fd, struct stat* buf);
 #endif
 void blkfront_aio(struct blkfront_aiocb *aiocbp, int write);
 #define blkfront_aio_read(aiocbp) blkfront_aio(aiocbp, 0)
diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h
index 1af2717..d4641b6 100644
--- a/extras/mini-os/include/lib.h
+++ b/extras/mini-os/include/lib.h
@@ -174,6 +174,7 @@ extern struct file {
 	} tap;
 	struct {
 	    struct blkfront_dev *dev;
+            off_t offset;
 	} blk;
 	struct {
 	    struct kbdfront_dev *dev;
diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
index a7d35d6..7ddbbf8 100644
--- a/extras/mini-os/lib/sys.c
+++ b/extras/mini-os/lib/sys.c
@@ -289,6 +289,11 @@ int read(int fd, void *buf, size_t nbytes)
 	    return ret * sizeof(union xenfb_in_event);
         }
 #endif
+#ifdef CONFIG_BLKFRONT
+        case FTYPE_BLK: {
+	    return blkfront_posix_read(fd, buf, nbytes);
+        }
+#endif
 	default:
 	    break;
     }
@@ -321,6 +326,10 @@ int write(int fd, const void *buf, size_t nbytes)
 	    netfront_xmit(files[fd].tap.dev, (void*) buf, nbytes);
 	    return nbytes;
 #endif
+#ifdef CONFIG_BLKFRONT
+	case FTYPE_BLK:
+	    return blkfront_posix_write(fd, buf, nbytes);
+#endif
 	default:
 	    break;
     }
@@ -331,8 +340,37 @@ int write(int fd, const void *buf, size_t nbytes)
 
 off_t lseek(int fd, off_t offset, int whence)
 {
-    errno = ESPIPE;
-    return (off_t) -1;
+    switch(files[fd].type) {
+#ifdef CONFIG_BLKFRONT
+       case FTYPE_BLK:
+	  switch (whence) {
+	     case SEEK_SET:
+		files[fd].file.offset = offset;
+		break;
+	     case SEEK_CUR:
+		files[fd].file.offset += offset;
+		break;
+	     case SEEK_END:
+		{
+		   struct stat st;
+		   int ret;
+		   ret = fstat(fd, &st);
+		   if (ret)
+		      return -1;
+		   files[fd].file.offset = st.st_size + offset;
+		   break;
+		}
+	     default:
+		errno = EINVAL;
+		return -1;
+	  }
+	  return files[fd].file.offset;
+	  break;
+#endif
+       default: /* Not implemented on this FTYPE */
+	  errno = ESPIPE;
+	  return (off_t) -1;
+    }
 }
 
 int fsync(int fd) {
@@ -445,6 +483,10 @@ int fstat(int fd, struct stat *buf)
 	    buf->st_ctime = time(NULL);
 	    return 0;
 	}
+#ifdef CONFIG_BLKFRONT
+	case FTYPE_BLK:
+	   return blkfront_posix_fstat(fd, buf);
+#endif
 	default:
 	    break;
     }
-- 
1.7.4.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 19:22:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 19:22:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLIu3-0003jv-Iv; Mon, 08 Oct 2012 19:22:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLIu2-0003jn-Hv
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 19:22:10 +0000
Received: from [85.158.137.99:16274] by server-15.bemta-3.messagelabs.com id
	0F/41-11584-1E723705; Mon, 08 Oct 2012 19:22:09 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-11.tower-217.messagelabs.com!1349724126!19551069!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD,UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28791 invoked from network); 8 Oct 2012 19:22:07 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-11.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Oct 2012 19:22:07 -0000
Received: from ([128.244.207.97])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.154547832;
	Mon, 08 Oct 2012 15:06:44 -0400
From: Matthew Fioravante 
To: xen-devel@lists.xen.org, ian.campbell@citrix.com,
	samuel.thibault@ens-lyon.org
Date: Mon,  8 Oct 2012 15:06:42 -0400
Message-Id: <1349723202-14608-2-git-send-email-matthew.fioravante@jhuapl.edu>
X-Mailer: git-send-email 1.7.4.4
In-Reply-To: <1349723202-14608-1-git-send-email-matthew.fioravante@jhuapl.edu>
References: <1349723202-14608-1-git-send-email-matthew.fioravante@jhuapl.edu>
Cc: Matthew Fioravante 
Subject: [Xen-devel] [PATCH vtpm v3 02/12] add posix io for blkfront
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch adds posix io support (read,write,lseek) to block devices
using blkfront.

Signed-off-by: Matthew Fioravante 
Acked-by: Samuel Thibault 

diff --git a/extras/mini-os/blkfront.c b/extras/mini-os/blkfront.c
index 74b8b26..f4283a9 100644
--- a/extras/mini-os/blkfront.c
+++ b/extras/mini-os/blkfront.c
@@ -392,6 +392,7 @@ void blkfront_aio(struct blkfront_aiocb *aiocbp, int write)
 static void blkfront_aio_cb(struct blkfront_aiocb *aiocbp, int ret)
 {
     aiocbp->data = (void*) 1;
+    aiocbp->aio_cb = NULL;
 }
 
 void blkfront_io(struct blkfront_aiocb *aiocbp, int write)
@@ -547,9 +548,177 @@ moretodo:
 #ifdef HAVE_LIBC
 int blkfront_open(struct blkfront_dev *dev)
 {
+    /* Silently prevent multiple opens */
+    if(dev->fd != -1) {
+       return dev->fd;
+    }
     dev->fd = alloc_fd(FTYPE_BLK);
     printk("blk_open(%s) -> %d\n", dev->nodename, dev->fd);
     files[dev->fd].blk.dev = dev;
+    files[dev->fd].blk.offset = 0;
     return dev->fd;
 }
+
+int blkfront_posix_rwop(int fd, uint8_t* buf, size_t count, int write)
+{
+   struct blkfront_dev* dev = files[fd].blk.dev;
+   off_t offset = files[fd].blk.offset;
+   struct blkfront_aiocb aiocb;
+   unsigned long long disksize = dev->info.sectors * dev->info.sector_size;
+   unsigned int blocksize = dev->info.sector_size;
+
+   int blknum;
+   int blkoff;
+   size_t bytes;
+   int rc = 0;
+   int alignedbuf = 0;
+   uint8_t* copybuf = NULL;
+
+   /* RW 0 bytes is just a NOP */
+   if(count == 0) {
+      return 0;
+   }
+   /* Check for NULL buffer */
+   if( buf == NULL ) {
+      errno = EFAULT;
+      return -1;
+   }
+
+   /* Write mode checks */
+   if(write) {
+      /*Make sure we have write permission */
+      if(dev->info.info & VDISK_READONLY 
+            || (dev->info.mode != O_RDWR  && dev->info.mode !=  O_WRONLY)) {
+         errno = EACCES;
+         return -1;
+      }
+      /*Make sure disk is big enough for this write */
+      if(offset + count > disksize) {
+         errno = ENOSPC;
+         return -1;
+      }
+   }
+   /* Read mode checks */
+   else
+   {
+      /* Reading past the disk? Just return 0 */
+      if(offset >= disksize) {
+         return 0;
+      }
+
+      /*If the requested read is bigger than the disk, just
+       * read as much as we can until the end */
+      if(offset + count > disksize) {
+         count = disksize - offset;
+      }
+   }
+   /* Determine which block to start at and at which offset inside of it */
+   blknum = offset / blocksize;
+   blkoff = offset % blocksize;
+
+   /* Optimization: We need to check if buf is aligned to the sector size.
+    * This is somewhat tricky code. We have to add the blocksize - block offset
+    * because the first block may be a partial block and then for every subsequent
+    * block rw the buffer will be offset.*/
+   if(!((uintptr_t) (buf +(blocksize -  blkoff)) & (dev->info.sector_size-1))) {
+      alignedbuf = 1;
+   }
+
+   /* Setup aiocb block object */
+   aiocb.aio_dev = dev;
+   aiocb.aio_offset = blknum * blocksize;
+   aiocb.aio_cb = NULL;
+   aiocb.data = NULL;
+
+   /* If our buffer is unaligned or its aligned but we will need to rw a partial block
+    * then a copy will have to be done */
+   if(!alignedbuf || blkoff != 0 || count % blocksize != 0) {
+      copybuf = _xmalloc(blocksize, dev->info.sector_size);
+   }
+
+   rc = count;
+   while(count > 0) {
+      /* determine how many bytes to read/write from/to the current block buffer */
+      if(!alignedbuf || blkoff != 0 || count < blocksize) {
+         /* This is the case for unaligned R/W or partial block */
+         bytes = count < blocksize - blkoff ? count : blocksize - blkoff;
+         aiocb.aio_nbytes = blocksize;
+      } else {
+         /* We can optimize further if buffer is page aligned */
+         int not_page_aligned = 0;
+         if(((uintptr_t)buf) & (PAGE_SIZE -1)) {
+            not_page_aligned = 1;
+         }
+
+         /* For an aligned R/W we can read up to the maximum transfer size */
+         bytes = count > (BLKIF_MAX_SEGMENTS_PER_REQUEST-not_page_aligned)*PAGE_SIZE 
+            ? (BLKIF_MAX_SEGMENTS_PER_REQUEST-not_page_aligned)*PAGE_SIZE
+            : count & ~(blocksize -1);
+         aiocb.aio_nbytes = bytes;
+      }
+
+      /* read operation */
+      if(!write) {
+         if (alignedbuf && bytes >= blocksize) {
+            /* If aligned and were reading a whole block, just read right into buf */
+            aiocb.aio_buf = buf;
+            blkfront_read(&aiocb);
+         } else {
+            /* If not then we have to do a copy */
+            aiocb.aio_buf = copybuf;
+            blkfront_read(&aiocb);
+            memcpy(buf, ©buf[blkoff], bytes);
+         }
+      }
+      /* Write operation */
+      else {
+         if(alignedbuf && bytes >= blocksize) {
+            /* If aligned and were writing a whole block, just write directly from buf */
+            aiocb.aio_buf = buf;
+            blkfront_write(&aiocb);
+         } else {
+            /* If not then we have to do a copy. */
+            aiocb.aio_buf = copybuf;
+            /* If we're writing a partial block, we need to read the current contents first
+             * so we don't overwrite the extra bits with garbage */
+            if(blkoff != 0 || bytes < blocksize) {
+               blkfront_read(&aiocb);
+            }
+            memcpy(©buf[blkoff], buf, bytes);
+            blkfront_write(&aiocb);
+         }
+      }
+      /* Will start at beginning of all remaining blocks */
+      blkoff = 0;
+
+      /* Increment counters and continue */
+      count -= bytes;
+      buf += bytes;
+      if(bytes < blocksize) {
+         //At minimum we read one block
+         aiocb.aio_offset += blocksize;
+      } else {
+         //If we read more than a block, was a multiple of blocksize
+         aiocb.aio_offset += bytes;
+      }
+   }
+
+   free(copybuf);
+   files[fd].blk.offset += rc;
+   return rc;
+
+}
+
+int blkfront_posix_fstat(int fd, struct stat* buf)
+{
+   struct blkfront_dev* dev = files[fd].blk.dev;
+
+   buf->st_mode = dev->info.mode;
+   buf->st_uid = 0;
+   buf->st_gid = 0;
+   buf->st_size = dev->info.sectors * dev->info.sector_size;
+   buf->st_atime = buf->st_mtime = buf->st_ctime = time(NULL);
+
+   return 0;
+}
 #endif
diff --git a/extras/mini-os/include/blkfront.h b/extras/mini-os/include/blkfront.h
index 724137e..3528af9 100644
--- a/extras/mini-os/include/blkfront.h
+++ b/extras/mini-os/include/blkfront.h
@@ -28,7 +28,17 @@ struct blkfront_info
 };
 struct blkfront_dev *init_blkfront(char *nodename, struct blkfront_info *info);
 #ifdef HAVE_LIBC
+#include 
+/* POSIX IO functions:
+ * use blkfront_open() to get a file descriptor to the block device
+ * Don't use the other blkfront posix functions here directly, instead use
+ * read(), write(), lseek() and fstat() on the file descriptor
+ */
 int blkfront_open(struct blkfront_dev *dev);
+int blkfront_posix_rwop(int fd, uint8_t* buf, size_t count, int write);
+#define blkfront_posix_write(fd, buf, count) blkfront_posix_rwop(fd, (uint8_t*)buf, count, 1)
+#define blkfront_posix_read(fd, buf, count) blkfront_posix_rwop(fd, (uint8_t*)buf, count, 0)
+int blkfront_posix_fstat(int fd, struct stat* buf);
 #endif
 void blkfront_aio(struct blkfront_aiocb *aiocbp, int write);
 #define blkfront_aio_read(aiocbp) blkfront_aio(aiocbp, 0)
diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h
index 1af2717..d4641b6 100644
--- a/extras/mini-os/include/lib.h
+++ b/extras/mini-os/include/lib.h
@@ -174,6 +174,7 @@ extern struct file {
 	} tap;
 	struct {
 	    struct blkfront_dev *dev;
+            off_t offset;
 	} blk;
 	struct {
 	    struct kbdfront_dev *dev;
diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
index a7d35d6..7ddbbf8 100644
--- a/extras/mini-os/lib/sys.c
+++ b/extras/mini-os/lib/sys.c
@@ -289,6 +289,11 @@ int read(int fd, void *buf, size_t nbytes)
 	    return ret * sizeof(union xenfb_in_event);
         }
 #endif
+#ifdef CONFIG_BLKFRONT
+        case FTYPE_BLK: {
+	    return blkfront_posix_read(fd, buf, nbytes);
+        }
+#endif
 	default:
 	    break;
     }
@@ -321,6 +326,10 @@ int write(int fd, const void *buf, size_t nbytes)
 	    netfront_xmit(files[fd].tap.dev, (void*) buf, nbytes);
 	    return nbytes;
 #endif
+#ifdef CONFIG_BLKFRONT
+	case FTYPE_BLK:
+	    return blkfront_posix_write(fd, buf, nbytes);
+#endif
 	default:
 	    break;
     }
@@ -331,8 +340,37 @@ int write(int fd, const void *buf, size_t nbytes)
 
 off_t lseek(int fd, off_t offset, int whence)
 {
-    errno = ESPIPE;
-    return (off_t) -1;
+    switch(files[fd].type) {
+#ifdef CONFIG_BLKFRONT
+       case FTYPE_BLK:
+	  switch (whence) {
+	     case SEEK_SET:
+		files[fd].file.offset = offset;
+		break;
+	     case SEEK_CUR:
+		files[fd].file.offset += offset;
+		break;
+	     case SEEK_END:
+		{
+		   struct stat st;
+		   int ret;
+		   ret = fstat(fd, &st);
+		   if (ret)
+		      return -1;
+		   files[fd].file.offset = st.st_size + offset;
+		   break;
+		}
+	     default:
+		errno = EINVAL;
+		return -1;
+	  }
+	  return files[fd].file.offset;
+	  break;
+#endif
+       default: /* Not implemented on this FTYPE */
+	  errno = ESPIPE;
+	  return (off_t) -1;
+    }
 }
 
 int fsync(int fd) {
@@ -445,6 +483,10 @@ int fstat(int fd, struct stat *buf)
 	    buf->st_ctime = time(NULL);
 	    return 0;
 	}
+#ifdef CONFIG_BLKFRONT
+	case FTYPE_BLK:
+	   return blkfront_posix_fstat(fd, buf);
+#endif
 	default:
 	    break;
     }
-- 
1.7.4.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 19:27:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 19:27:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLIyY-0003rg-AV; Mon, 08 Oct 2012 19:26:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLIyW-0003rY-QZ
	for Xen-devel@lists.xensource.com; Mon, 08 Oct 2012 19:26:49 +0000
Received: from [85.158.139.211:62698] by server-9.bemta-5.messagelabs.com id
	36/4F-14846-7F823705; Mon, 08 Oct 2012 19:26:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1349724407!21511829!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMzNDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27907 invoked from network); 8 Oct 2012 19:26:47 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 19:26:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,555,1344211200"; d="scan'208";a="15010304"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 19:26:46 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 8 Oct 2012
	20:26:46 +0100
Message-ID: <1349724405.6952.53.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Mukesh Rathor 
Date: Mon, 8 Oct 2012 20:26:45 +0100
In-Reply-To: <20121008121059.60094d43@mantra.us.oracle.com>
References: <20120921122123.33489ce1@mantra.us.oracle.com>
	<1349270495.650.144.camel@zakaz.uk.xensource.com>
	<20121003153106.65237f07@mantra.us.oracle.com>
	<1349340642.650.227.camel@zakaz.uk.xensource.com>
	<20121004112048.53767720@mantra.us.oracle.com>
	<1349428878.20946.18.camel@zakaz.uk.xensource.com>
	<20121005142240.340815be@mantra.us.oracle.com>
	<1349688102.18008.34.camel@zakaz.uk.xensource.com>
	<20121008121059.60094d43@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" ,
	Stefano Stabellini ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH v1 7/8]: PVH privcmd changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-10-08 at 20:10 +0100, Mukesh Rathor wrote:
> On Mon, 8 Oct 2012 10:21:42 +0100
> Ian Campbell  wrote:
> 
> > On Fri, 2012-10-05 at 22:22 +0100, Mukesh Rathor wrote:
> > > On Fri, 5 Oct 2012 10:21:18 +0100
> > > Ian Campbell  wrote:
> > > 
> > > > On Thu, 2012-10-04 at 19:20 +0100, Mukesh Rathor wrote:
> > > > > On Thu, 4 Oct 2012 09:50:42 +0100
> > > > > Ian Campbell  wrote:
> > > > > 
> > > > > > 
> > > > > > Won't that break because on the second call you will pass in
> > > > > > the freshly allocated pointer and overwrite the exiting
> > > > > > (useful) one with it?
> > > > > 
> > > > > No, for xlate, I just check for NULL. I didn't think it was big 
> > > > > deal to special case xlate in this case. We got so many if
> > > > > xlate cases already thru the code. It leaves the semantics easy
> > > > > to understand: NULL == avail. 1 == locked PV. PTR == Locked
> > > > > PVH. I'll add a comment this time :).
> > > > 
> > > > The transition from NULL => Locked PVH still needs to be done
> > > > atomically and without clobbering any existing non-NULL value,
> > > > otherwise it doesn't actually protect against multiple mappings
> > > > like it is supposed to.
> > 
> > > Ok, changed it to, and tested it:
> > > 
> > > static int privcmd_enforce_singleshot_mapping(struct vm_area_struct
> > > *vma) {
> > >         if (xen_feature(XENFEAT_auto_translated_physmap)) {
> > >                 int sz = sizeof(vma->vm_private_data);
> > >                 return (!__cmpxchg(&vma->vm_private_data, NULL,
> > > NULL, sz));
> > 
> > Passing NULL for both old and new values can't be right, can it? Did
> > you test with something which tries to map twice?
> 
> well, if it's already set to pointer, then __cmpxchg would leave the ptr 
> alone and return it. The function would then return false which would 
> fail the api. OTOH, if it's NULL, it would continue and get set later.

What happens if a second thread tries to create a mapping while the
first is between the cmpxchg and the assignment? i.e. while the value is
still NULL.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 19:27:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 19:27:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLIyY-0003rg-AV; Mon, 08 Oct 2012 19:26:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLIyW-0003rY-QZ
	for Xen-devel@lists.xensource.com; Mon, 08 Oct 2012 19:26:49 +0000
Received: from [85.158.139.211:62698] by server-9.bemta-5.messagelabs.com id
	36/4F-14846-7F823705; Mon, 08 Oct 2012 19:26:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1349724407!21511829!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMzNDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27907 invoked from network); 8 Oct 2012 19:26:47 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 19:26:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,555,1344211200"; d="scan'208";a="15010304"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 19:26:46 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Mon, 8 Oct 2012
	20:26:46 +0100
Message-ID: <1349724405.6952.53.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Mukesh Rathor 
Date: Mon, 8 Oct 2012 20:26:45 +0100
In-Reply-To: <20121008121059.60094d43@mantra.us.oracle.com>
References: <20120921122123.33489ce1@mantra.us.oracle.com>
	<1349270495.650.144.camel@zakaz.uk.xensource.com>
	<20121003153106.65237f07@mantra.us.oracle.com>
	<1349340642.650.227.camel@zakaz.uk.xensource.com>
	<20121004112048.53767720@mantra.us.oracle.com>
	<1349428878.20946.18.camel@zakaz.uk.xensource.com>
	<20121005142240.340815be@mantra.us.oracle.com>
	<1349688102.18008.34.camel@zakaz.uk.xensource.com>
	<20121008121059.60094d43@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" ,
	Stefano Stabellini ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH v1 7/8]: PVH privcmd changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-10-08 at 20:10 +0100, Mukesh Rathor wrote:
> On Mon, 8 Oct 2012 10:21:42 +0100
> Ian Campbell  wrote:
> 
> > On Fri, 2012-10-05 at 22:22 +0100, Mukesh Rathor wrote:
> > > On Fri, 5 Oct 2012 10:21:18 +0100
> > > Ian Campbell  wrote:
> > > 
> > > > On Thu, 2012-10-04 at 19:20 +0100, Mukesh Rathor wrote:
> > > > > On Thu, 4 Oct 2012 09:50:42 +0100
> > > > > Ian Campbell  wrote:
> > > > > 
> > > > > > 
> > > > > > Won't that break because on the second call you will pass in
> > > > > > the freshly allocated pointer and overwrite the exiting
> > > > > > (useful) one with it?
> > > > > 
> > > > > No, for xlate, I just check for NULL. I didn't think it was big 
> > > > > deal to special case xlate in this case. We got so many if
> > > > > xlate cases already thru the code. It leaves the semantics easy
> > > > > to understand: NULL == avail. 1 == locked PV. PTR == Locked
> > > > > PVH. I'll add a comment this time :).
> > > > 
> > > > The transition from NULL => Locked PVH still needs to be done
> > > > atomically and without clobbering any existing non-NULL value,
> > > > otherwise it doesn't actually protect against multiple mappings
> > > > like it is supposed to.
> > 
> > > Ok, changed it to, and tested it:
> > > 
> > > static int privcmd_enforce_singleshot_mapping(struct vm_area_struct
> > > *vma) {
> > >         if (xen_feature(XENFEAT_auto_translated_physmap)) {
> > >                 int sz = sizeof(vma->vm_private_data);
> > >                 return (!__cmpxchg(&vma->vm_private_data, NULL,
> > > NULL, sz));
> > 
> > Passing NULL for both old and new values can't be right, can it? Did
> > you test with something which tries to map twice?
> 
> well, if it's already set to pointer, then __cmpxchg would leave the ptr 
> alone and return it. The function would then return false which would 
> fail the api. OTOH, if it's NULL, it would continue and get set later.

What happens if a second thread tries to create a mapping while the
first is between the cmpxchg and the assignment? i.e. while the value is
still NULL.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 19:44:03 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 19:44:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLJEq-00045E-TW; Mon, 08 Oct 2012 19:43:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLJEp-000459-7U
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 19:43:39 +0000
Received: from [85.158.139.83:6705] by server-8.bemta-5.messagelabs.com id
	12/C6-23193-AEC23705; Mon, 08 Oct 2012 19:43:38 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1349725416!29987482!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc5OTA1Nw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13211 invoked from network); 8 Oct 2012 19:43:37 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 19:43:37 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q98JhQCp026934
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 8 Oct 2012 19:43:26 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q98JhOxw028467
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 8 Oct 2012 19:43:25 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q98JhMDh023967; Mon, 8 Oct 2012 14:43:23 -0500
MIME-Version: 1.0
Message-ID: 
Date: Mon, 8 Oct 2012 12:43:19 -0700 (PDT)
From: Dan Magenheimer 
To: Dario Faggioli , xen-devel@lists.xen.org
References: 
In-Reply-To: 
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Marcus Granado ,
	Andre Przywara ,
	Ian Campbell ,
	Anil Madhavapeddy ,
	George Dunlap ,
	Andrew Cooper ,
	Juergen Gross ,
	Ian Jackson , Jan Beulich ,
	Daniel De Graaf , Matt Wilson 
Subject: Re: [Xen-devel] [PATCH 0 of 8] NUMA Awareness for the Credit
 Scheduler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Dario Faggioli [mailto:dario.faggioli@citrix.com]
> Sent: Friday, October 05, 2012 8:08 AM
> To: xen-devel@lists.xen.org
> Cc: Andre Przywara; Ian Campbell; Anil Madhavapeddy; George Dunlap; Andrew Cooper; Juergen Gross; Ian
> Jackson; Jan Beulich; Marcus Granado; Daniel De Graaf; Matt Wilson
> Subject: [Xen-devel] [PATCH 0 of 8] NUMA Awareness for the Credit Scheduler
> 
> Hi Everyone,
> 
> Here it comes a patch series instilling some NUMA awareness in the Credit
> scheduler.

Hi Dario --

Just wondering... is the NUMA information preserved on live migration?
I'm not saying that it necessarily should, but it may just work
due to the implementation (since migration is a form of domain creation).
In either case, it might be good to comment about live migration
on your wiki.

Thanks,
Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 19:44:03 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 19:44:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLJEq-00045E-TW; Mon, 08 Oct 2012 19:43:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLJEp-000459-7U
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 19:43:39 +0000
Received: from [85.158.139.83:6705] by server-8.bemta-5.messagelabs.com id
	12/C6-23193-AEC23705; Mon, 08 Oct 2012 19:43:38 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1349725416!29987482!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc5OTA1Nw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13211 invoked from network); 8 Oct 2012 19:43:37 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 19:43:37 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q98JhQCp026934
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 8 Oct 2012 19:43:26 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q98JhOxw028467
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 8 Oct 2012 19:43:25 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q98JhMDh023967; Mon, 8 Oct 2012 14:43:23 -0500
MIME-Version: 1.0
Message-ID: 
Date: Mon, 8 Oct 2012 12:43:19 -0700 (PDT)
From: Dan Magenheimer 
To: Dario Faggioli , xen-devel@lists.xen.org
References: 
In-Reply-To: 
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Marcus Granado ,
	Andre Przywara ,
	Ian Campbell ,
	Anil Madhavapeddy ,
	George Dunlap ,
	Andrew Cooper ,
	Juergen Gross ,
	Ian Jackson , Jan Beulich ,
	Daniel De Graaf , Matt Wilson 
Subject: Re: [Xen-devel] [PATCH 0 of 8] NUMA Awareness for the Credit
 Scheduler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Dario Faggioli [mailto:dario.faggioli@citrix.com]
> Sent: Friday, October 05, 2012 8:08 AM
> To: xen-devel@lists.xen.org
> Cc: Andre Przywara; Ian Campbell; Anil Madhavapeddy; George Dunlap; Andrew Cooper; Juergen Gross; Ian
> Jackson; Jan Beulich; Marcus Granado; Daniel De Graaf; Matt Wilson
> Subject: [Xen-devel] [PATCH 0 of 8] NUMA Awareness for the Credit Scheduler
> 
> Hi Everyone,
> 
> Here it comes a patch series instilling some NUMA awareness in the Credit
> scheduler.

Hi Dario --

Just wondering... is the NUMA information preserved on live migration?
I'm not saying that it necessarily should, but it may just work
due to the implementation (since migration is a form of domain creation).
In either case, it might be good to comment about live migration
on your wiki.

Thanks,
Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 19:49:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 19:49:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLJJt-0004FG-R1; Mon, 08 Oct 2012 19:48:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLJJt-0004F7-0Z
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 19:48:53 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1349725724!12495689!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc5OTA1Nw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4336 invoked from network); 8 Oct 2012 19:48:45 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 19:48:45 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q98Jmdbf031686
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 8 Oct 2012 19:48:40 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q98Jmcot012656
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 8 Oct 2012 19:48:38 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q98JmbcV005948; Mon, 8 Oct 2012 14:48:37 -0500
MIME-Version: 1.0
Message-ID: <2d303534-6274-4adb-bd45-92faf55a5027@default>
Date: Mon, 8 Oct 2012 12:48:35 -0700 (PDT)
From: Dan Magenheimer 
To: Olaf Hering , xen-devel@lists.xen.org
References: <65ab6762cd37d0f43ff0.1349458510@probook.site>
In-Reply-To: <65ab6762cd37d0f43ff0.1349458510@probook.site>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: Re: [Xen-devel] [PATCH] xenballoond.init: remove 4 from default
 runlevel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Olaf Hering [mailto:olaf@aepfle.de]
> Subject: [Xen-devel] [PATCH] xenballoond.init: remove 4 from default runlevel
> 
> # HG changeset patch
> # User Olaf Hering 
> # Date 1349458470 -7200
> # Node ID 65ab6762cd37d0f43ff031e00637d5a88514aadb
> # Parent  964fd4a693f940b5ae31d6d9021e0c89afaee703
> xenballoond.init: remove 4 from default runlevel
> 
> Remove 4 from default runlevel in xenballoond.init.

Hi Olaf --

No objection to the patch, but I was wondering...

Are you using xenballoond for something?  (e.g. your page-sharing
testing or a product implementation)

I stopped encouraging the use of userland selfballooning (which
is what xenballoond implements) years ago, when I saw
the impact of very sudden large workload increases...
thrashing can occur.  This observation is what led to
tmem persistent pools and to selfballooning built into
the Linux kernel.

If you were just scanning Xen system services and ran across
this issue, no problem.  But since it is somewhat related
to your page-sharing/host-swapping work, I thought I'd check.

Thanks,
Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 19:49:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 19:49:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLJJt-0004FG-R1; Mon, 08 Oct 2012 19:48:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLJJt-0004F7-0Z
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 19:48:53 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1349725724!12495689!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc5OTA1Nw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4336 invoked from network); 8 Oct 2012 19:48:45 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 19:48:45 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q98Jmdbf031686
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 8 Oct 2012 19:48:40 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q98Jmcot012656
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 8 Oct 2012 19:48:38 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q98JmbcV005948; Mon, 8 Oct 2012 14:48:37 -0500
MIME-Version: 1.0
Message-ID: <2d303534-6274-4adb-bd45-92faf55a5027@default>
Date: Mon, 8 Oct 2012 12:48:35 -0700 (PDT)
From: Dan Magenheimer 
To: Olaf Hering , xen-devel@lists.xen.org
References: <65ab6762cd37d0f43ff0.1349458510@probook.site>
In-Reply-To: <65ab6762cd37d0f43ff0.1349458510@probook.site>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: Re: [Xen-devel] [PATCH] xenballoond.init: remove 4 from default
 runlevel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Olaf Hering [mailto:olaf@aepfle.de]
> Subject: [Xen-devel] [PATCH] xenballoond.init: remove 4 from default runlevel
> 
> # HG changeset patch
> # User Olaf Hering 
> # Date 1349458470 -7200
> # Node ID 65ab6762cd37d0f43ff031e00637d5a88514aadb
> # Parent  964fd4a693f940b5ae31d6d9021e0c89afaee703
> xenballoond.init: remove 4 from default runlevel
> 
> Remove 4 from default runlevel in xenballoond.init.

Hi Olaf --

No objection to the patch, but I was wondering...

Are you using xenballoond for something?  (e.g. your page-sharing
testing or a product implementation)

I stopped encouraging the use of userland selfballooning (which
is what xenballoond implements) years ago, when I saw
the impact of very sudden large workload increases...
thrashing can occur.  This observation is what led to
tmem persistent pools and to selfballooning built into
the Linux kernel.

If you were just scanning Xen system services and ran across
this issue, no problem.  But since it is somewhat related
to your page-sharing/host-swapping work, I thought I'd check.

Thanks,
Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 19:55:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 19:55:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLJQ3-0004Og-LA; Mon, 08 Oct 2012 19:55:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLJQ2-0004Ob-Dy
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 19:55:14 +0000
Received: from [85.158.139.211:40634] by server-1.bemta-5.messagelabs.com id
	51/84-09825-1AF23705; Mon, 08 Oct 2012 19:55:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1349726112!17557911!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMzNDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5034 invoked from network); 8 Oct 2012 19:55:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 19:55:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,555,1344211200"; d="scan'208";a="15011067"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 19:55:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Mon, 8 Oct 2012 20:55:11 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TLJPz-0003wY-Hh;
	Mon, 08 Oct 2012 19:55:11 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TLJPz-00036e-G0;
	Mon, 08 Oct 2012 20:55:11 +0100
To: 
Message-ID: 
From: xen.org 
Date: Mon, 8 Oct 2012 20:55:11 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13934: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13934 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13934/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 13932
 build-i386                    4 xen-build                 fail REGR. vs. 13932
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 13932

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13932
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13932
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13932

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  c9f621893a05
baseline version:
 xen                  099589002239

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD 
  Ian Campbell 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Samuel Thibault 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26017:c9f621893a05
tag:         tip
user:        Matthew Fioravante 
date:        Mon Oct 08 14:36:31 2012 +0100
    
    minios: setup fpu and sse in mini-os
    
    This patch adds floating point and sse support to mini-os by
    initializing the floating point unit and the see unit during
    domain boot up.
    
    Signed-off-by: Matthew Fioravante 
    Acked-by: Samuel Thibault 
    Committed-by: Ian Campbell 
    
    
changeset:   26016:865626fc7004
user:        Matthew Fioravante 
date:        Mon Oct 08 14:36:31 2012 +0100
    
    minios: add CONFIG_XC conditional
    
    This patch adds a CONFIG_XC option to mini-os, to allow conditional
    support for libxc for mini-os domains.
    
    Signed-off-by: Matthew Fioravante 
    Acked-by: Samuel Thibault 
    Committed-by: Ian Campbell 
    
    
changeset:   26015:42ca0ed31aa6
user:        Matthew Fioravante 
date:        Mon Oct 08 14:36:30 2012 +0100
    
    minios: Disable the mfn_is_ram() check, it doesn't work correctly on all systems
    
    This patch disables the mfn_is_ram check in mini-os. The current check
    is insufficient and fails on some systems with larger than 4gb memory.
    
    Signed-off-by: Matthew Fioravante 
    Acked-by: Samuel Thibault 
    Committed-by: Ian Campbell 
    
    
changeset:   26014:8fdb8d464ece
user:        Matthew Fioravante 
date:        Mon Oct 08 14:36:29 2012 +0100
    
    minios: Add endian, byteswap, and wordsize macros to mini-os
    
    This patch addes byte swapping macros and endian support to mini-os.
    
    Signed-off-by: Matthew Fioravante 
    Acked-by: Samuel Thibault 
    Committed-by: Ian Campbell 
    
    
changeset:   26013:a797d59e1d29
user:        Matthew Fioravante 
date:        Mon Oct 08 14:36:28 2012 +0100
    
    minios: Add ioread/iowrite functions to mini-os
    
    This patch adds iowritexx() and ioreadxx() functions for interacting
    with hardware memory to mini-os. The functions are available in a header
    iorw.h
    
    Signed-off-by: Matthew Fioravante 
    Acked-by: Samuel Thibault 
    Reviewed-by: George Dunlap 
    Committed-by: Ian Campbell 
    
    
changeset:   26012:02e744da52c9
user:        Olaf Hering 
date:        Mon Oct 08 12:18:35 2012 +0100
    
    tools/configure.ac: fill PACKAGE_TARNAME in AC_INIT
    
    Upcoming changes may move DOCDIR from Config.mk to config/Tools.mk. To
    preserve the currently used path, which ends with /xen, specify a value
    for PACKAGE_TARNAME. Without this change the path would end with
    /xen-hypervisor.
    
    Please rerun autoconf after applying this.
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26011:b6fb4e63b946
user:        Olaf Hering 
date:        Mon Oct 08 12:18:34 2012 +0100
    
    stubdom: fix parallel build by expanding CROSS_MAKE
    
    Recently I changed my rpm xen.spec file from doing
    'make -C tools -j N && make stubdom' to 'make -j N stubdom' because
    stubdom depends on tools, so both get built.
    The result was the failure below.
    
    ....
    mkdir -p grub-x86_64
    CPPFLAGS="-isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include -D__MINIOS__ -DHAVE_LIBC -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include/posix -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../tools/xenstore  -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include/x86 -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include/x86/x86_64 -U __linux__ -U __FreeBSD__ -U __sun__ -nostdinc -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include/posix -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/cross-root-x86_64/x86_64-xen-elf/include -isystem /usr/lib64/gcc/x86_64-suse-linux/4.7/include -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/lwip-x86_64/src/include -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/lwip-x86_64/src/include/ipv4 -I/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/include -I/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../xen/include" CFLAGS="-mno-red-zone -O1 -fno-omit-frame-pointer  -m64 -mno-red-zone -fno-reorder-blocks -fno-asynchronous-unwind-tables -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable   -fno-stack-protector -fno-exceptions" make DESTDIR= -C grub OBJ_DIR=/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/grub-x86_64
    make[2]: Entering directory `/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/grub'
    make[2]: warning: jobserver unavailable: using -j1.  Add `+' to parent make rule.
    make[2]: *** INTERNAL: readdir: Bad file descriptor
    .  Stop.
    make[2]: Makefile: Field 'stem' not cached: Makefile
    
    make[2]: Leaving directory `/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/grub'
    make[1]: *** [grub] Error 2
    [ -d mini-os-x86_64-xenstore ] || \
    for i in $(cd /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os ; find . -type d) ; do \
                    mkdir -p mini-os-x86_64-xenstore/$i ; \
    done
    ....
    
    Expanding every occurrence of CROSS_MAKE avoids this error. It also has
    the nice side effect of actually enabling parallel build for stubdom.
    According to the GNU make documentation $(MAKE) gets its special meaning
    only if it appears directly in the recipe:
    
    http://www.gnu.org/software/make/manual/html_node/MAKE-Variable.html
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26010:cff10030c6ea
user:        Olaf Hering 
date:        Mon Oct 08 12:18:33 2012 +0100
    
    xend/pvscsi: update sysfs parser for Linux 3.0
    
    The sysfs parser for /sys/bus/scsi/devices understands only the layout
    of kernel version 2.6.16. This looks as follows:
    
    /sys/bus/scsi/devices/1:0:0:0/block:sda is a symlink to /sys/block/sda/
    /sys/bus/scsi/devices/1:0:0:0/scsi_generic:sg1 is a symlink to /sys/class/scsi_generic/sg1
    
    Both directories contain a 'dev' file with the major:minor information.
    This patch updates the used regex strings to match also the colon to
    make it more robust against possible future changes.
    
    In kernel version 3.0 the layout changed:
    /sys/bus/scsi/devices/ contains now additional symlinks to directories
    such as host1 and target1:0:0. This patch ignores these as they do not
    point to the desired scsi devices. They just clutter the devices array.
    
    The directory layout in '1:0:0:0' changed as well, the 'type:name'
    notation was replaced with 'type/name' directories:
    
    /sys/bus/scsi/devices/1:0:0:0/block/sda/
    /sys/bus/scsi/devices/1:0:0:0/scsi_generic/sg1/
    
    Both directories contain a 'dev' file with the major:minor information.
    This patch adds additional code to walk the subdir to find the 'dev'
    file to make sure the given subdirectory is really the kernel name.
    
    In addition this patch makes sure devname is not None.
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26009:2dbfa4d2e107
user:        Olaf Hering 
date:        Mon Oct 08 12:18:32 2012 +0100
    
    xend/pvscsi: fix usage of persistant device names for SCSI devices
    
    Currently the callers of vscsi_get_scsidevices() do not pass a mask
    string.  This will call "lsscsi -g '[]'", which causes a lsscsi syntax
    error. As a result the sysfs parser _vscsi_get_scsidevices() is used.
    But this parser is broken and the specified names in the config file are
    not found.
    
    Using a mask '*' if no mask was given will call lsscsi correctly and the
    following config is parsed correctly:
    
    vscsi=[
    	'/dev/sg3, 0:0:0:0',
    	'/dev/disk/by-id/wwn-0x600508b4000cf1c30000800000410000, 0:0:0:1'
    ]
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26008:eecb528583d7
user:        Olaf Hering 
date:        Mon Oct 08 12:18:31 2012 +0100
    
    xend/pvscsi: fix passing of SCSI control LUNs
    
    Currently pvscsi can not pass SCSI devices that have just a scsi_generic node.
    In the following example sg3 is a control LUN for the disk sdd.
    But vscsi=['4:0:2:0,0:0:0:0'] does not work because the internal 'devname'
    variable remains None. Later writing p-devname to xenstore fails because None
    is not a valid string variable.
    
    Since devname is used for just informational purpose use sg also as devname.
    
    carron:~ $ lsscsi -g
    [0:0:0:0]    disk    ATA      FK0032CAAZP      HPF2  /dev/sda   /dev/sg0
    [4:0:0:0]    disk    HP       P2000G3 FC/iSCSI T100  /dev/sdb   /dev/sg1
    [4:0:1:0]    disk    HP       P2000G3 FC/iSCSI T100  /dev/sdc   /dev/sg2
    [4:0:2:0]    storage HP       HSV400           0950  -         /dev/sg3
    [4:0:2:1]    disk    HP       HSV400           0950  /dev/sdd   /dev/sg4
    [4:0:3:0]    storage HP       HSV400           0950  -         /dev/sg5
    [4:0:3:1]    disk    HP       HSV400           0950  /dev/sde   /dev/sg6
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26007:fe756682cc7f
user:        Olaf Hering 
date:        Mon Oct 08 12:18:31 2012 +0100
    
    xenballoond.init: remove 4 from default runlevel
    
    Remove 4 from default runlevel in xenballoond.init.
    
    Similar to what changeset 24847:0900b1c905f1 does in xencommons, remove
    runlevel 4 from the other runlevel scripts. LSB defines runlevel 4 as
    reserved for local use, the local sysadmin is responsible for symlink
    creation in rc4.d.
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26006:8b6870d686d6
user:        Olaf Hering 
date:        Mon Oct 08 12:18:30 2012 +0100
    
    hotplug/Linux: Remove tracing (bash -x) from network-nat script
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26005:cdb48f1742f3
user:        Roger Pau Monne 
date:        Mon Oct 08 12:18:29 2012 +0100
    
    autoconf: add -Werror to libutil.h header check
    
    libutil.h is only needed on BSDs, but not in Linux. Debian package
    libbsd-dev-0.3.0-1 installed a libutil.h overlay that contains a
    
    Perform the libutil.h check with -Werror, so we don't include this
    bogus header.
    
    Signed-off-by: Roger Pau Monne 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26004:099589002239
user:        Anthony PERARD 
date:        Mon Oct 08 11:45:36 2012 +0100
    
    libxl: Allow migration with qemu-xen.
    
    Signed-off-by: Anthony PERARD 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 19:55:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 19:55:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLJQ3-0004Og-LA; Mon, 08 Oct 2012 19:55:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLJQ2-0004Ob-Dy
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 19:55:14 +0000
Received: from [85.158.139.211:40634] by server-1.bemta-5.messagelabs.com id
	51/84-09825-1AF23705; Mon, 08 Oct 2012 19:55:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1349726112!17557911!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMzNDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5034 invoked from network); 8 Oct 2012 19:55:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 19:55:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,555,1344211200"; d="scan'208";a="15011067"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 19:55:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Mon, 8 Oct 2012 20:55:11 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TLJPz-0003wY-Hh;
	Mon, 08 Oct 2012 19:55:11 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TLJPz-00036e-G0;
	Mon, 08 Oct 2012 20:55:11 +0100
To: 
Message-ID: 
From: xen.org 
Date: Mon, 8 Oct 2012 20:55:11 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13934: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13934 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13934/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 13932
 build-i386                    4 xen-build                 fail REGR. vs. 13932
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 13932

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13932
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13932
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13932

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  c9f621893a05
baseline version:
 xen                  099589002239

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD 
  Ian Campbell 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Samuel Thibault 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26017:c9f621893a05
tag:         tip
user:        Matthew Fioravante 
date:        Mon Oct 08 14:36:31 2012 +0100
    
    minios: setup fpu and sse in mini-os
    
    This patch adds floating point and sse support to mini-os by
    initializing the floating point unit and the see unit during
    domain boot up.
    
    Signed-off-by: Matthew Fioravante 
    Acked-by: Samuel Thibault 
    Committed-by: Ian Campbell 
    
    
changeset:   26016:865626fc7004
user:        Matthew Fioravante 
date:        Mon Oct 08 14:36:31 2012 +0100
    
    minios: add CONFIG_XC conditional
    
    This patch adds a CONFIG_XC option to mini-os, to allow conditional
    support for libxc for mini-os domains.
    
    Signed-off-by: Matthew Fioravante 
    Acked-by: Samuel Thibault 
    Committed-by: Ian Campbell 
    
    
changeset:   26015:42ca0ed31aa6
user:        Matthew Fioravante 
date:        Mon Oct 08 14:36:30 2012 +0100
    
    minios: Disable the mfn_is_ram() check, it doesn't work correctly on all systems
    
    This patch disables the mfn_is_ram check in mini-os. The current check
    is insufficient and fails on some systems with larger than 4gb memory.
    
    Signed-off-by: Matthew Fioravante 
    Acked-by: Samuel Thibault 
    Committed-by: Ian Campbell 
    
    
changeset:   26014:8fdb8d464ece
user:        Matthew Fioravante 
date:        Mon Oct 08 14:36:29 2012 +0100
    
    minios: Add endian, byteswap, and wordsize macros to mini-os
    
    This patch addes byte swapping macros and endian support to mini-os.
    
    Signed-off-by: Matthew Fioravante 
    Acked-by: Samuel Thibault 
    Committed-by: Ian Campbell 
    
    
changeset:   26013:a797d59e1d29
user:        Matthew Fioravante 
date:        Mon Oct 08 14:36:28 2012 +0100
    
    minios: Add ioread/iowrite functions to mini-os
    
    This patch adds iowritexx() and ioreadxx() functions for interacting
    with hardware memory to mini-os. The functions are available in a header
    iorw.h
    
    Signed-off-by: Matthew Fioravante 
    Acked-by: Samuel Thibault 
    Reviewed-by: George Dunlap 
    Committed-by: Ian Campbell 
    
    
changeset:   26012:02e744da52c9
user:        Olaf Hering 
date:        Mon Oct 08 12:18:35 2012 +0100
    
    tools/configure.ac: fill PACKAGE_TARNAME in AC_INIT
    
    Upcoming changes may move DOCDIR from Config.mk to config/Tools.mk. To
    preserve the currently used path, which ends with /xen, specify a value
    for PACKAGE_TARNAME. Without this change the path would end with
    /xen-hypervisor.
    
    Please rerun autoconf after applying this.
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26011:b6fb4e63b946
user:        Olaf Hering 
date:        Mon Oct 08 12:18:34 2012 +0100
    
    stubdom: fix parallel build by expanding CROSS_MAKE
    
    Recently I changed my rpm xen.spec file from doing
    'make -C tools -j N && make stubdom' to 'make -j N stubdom' because
    stubdom depends on tools, so both get built.
    The result was the failure below.
    
    ....
    mkdir -p grub-x86_64
    CPPFLAGS="-isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include -D__MINIOS__ -DHAVE_LIBC -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include/posix -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../tools/xenstore  -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include/x86 -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include/x86/x86_64 -U __linux__ -U __FreeBSD__ -U __sun__ -nostdinc -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include/posix -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/cross-root-x86_64/x86_64-xen-elf/include -isystem /usr/lib64/gcc/x86_64-suse-linux/4.7/include -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/lwip-x86_64/src/include -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/lwip-x86_64/src/include/ipv4 -I/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/include -I/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../xen/include" CFLAGS="-mno-red-zone -O1 -fno-omit-frame-pointer  -m64 -mno-red-zone -fno-reorder-blocks -fno-asynchronous-unwind-tables -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable   -fno-stack-protector -fno-exceptions" make DESTDIR= -C grub OBJ_DIR=/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/grub-x86_64
    make[2]: Entering directory `/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/grub'
    make[2]: warning: jobserver unavailable: using -j1.  Add `+' to parent make rule.
    make[2]: *** INTERNAL: readdir: Bad file descriptor
    .  Stop.
    make[2]: Makefile: Field 'stem' not cached: Makefile
    
    make[2]: Leaving directory `/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/grub'
    make[1]: *** [grub] Error 2
    [ -d mini-os-x86_64-xenstore ] || \
    for i in $(cd /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os ; find . -type d) ; do \
                    mkdir -p mini-os-x86_64-xenstore/$i ; \
    done
    ....
    
    Expanding every occurrence of CROSS_MAKE avoids this error. It also has
    the nice side effect of actually enabling parallel build for stubdom.
    According to the GNU make documentation $(MAKE) gets its special meaning
    only if it appears directly in the recipe:
    
    http://www.gnu.org/software/make/manual/html_node/MAKE-Variable.html
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26010:cff10030c6ea
user:        Olaf Hering 
date:        Mon Oct 08 12:18:33 2012 +0100
    
    xend/pvscsi: update sysfs parser for Linux 3.0
    
    The sysfs parser for /sys/bus/scsi/devices understands only the layout
    of kernel version 2.6.16. This looks as follows:
    
    /sys/bus/scsi/devices/1:0:0:0/block:sda is a symlink to /sys/block/sda/
    /sys/bus/scsi/devices/1:0:0:0/scsi_generic:sg1 is a symlink to /sys/class/scsi_generic/sg1
    
    Both directories contain a 'dev' file with the major:minor information.
    This patch updates the used regex strings to match also the colon to
    make it more robust against possible future changes.
    
    In kernel version 3.0 the layout changed:
    /sys/bus/scsi/devices/ contains now additional symlinks to directories
    such as host1 and target1:0:0. This patch ignores these as they do not
    point to the desired scsi devices. They just clutter the devices array.
    
    The directory layout in '1:0:0:0' changed as well, the 'type:name'
    notation was replaced with 'type/name' directories:
    
    /sys/bus/scsi/devices/1:0:0:0/block/sda/
    /sys/bus/scsi/devices/1:0:0:0/scsi_generic/sg1/
    
    Both directories contain a 'dev' file with the major:minor information.
    This patch adds additional code to walk the subdir to find the 'dev'
    file to make sure the given subdirectory is really the kernel name.
    
    In addition this patch makes sure devname is not None.
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26009:2dbfa4d2e107
user:        Olaf Hering 
date:        Mon Oct 08 12:18:32 2012 +0100
    
    xend/pvscsi: fix usage of persistant device names for SCSI devices
    
    Currently the callers of vscsi_get_scsidevices() do not pass a mask
    string.  This will call "lsscsi -g '[]'", which causes a lsscsi syntax
    error. As a result the sysfs parser _vscsi_get_scsidevices() is used.
    But this parser is broken and the specified names in the config file are
    not found.
    
    Using a mask '*' if no mask was given will call lsscsi correctly and the
    following config is parsed correctly:
    
    vscsi=[
    	'/dev/sg3, 0:0:0:0',
    	'/dev/disk/by-id/wwn-0x600508b4000cf1c30000800000410000, 0:0:0:1'
    ]
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26008:eecb528583d7
user:        Olaf Hering 
date:        Mon Oct 08 12:18:31 2012 +0100
    
    xend/pvscsi: fix passing of SCSI control LUNs
    
    Currently pvscsi can not pass SCSI devices that have just a scsi_generic node.
    In the following example sg3 is a control LUN for the disk sdd.
    But vscsi=['4:0:2:0,0:0:0:0'] does not work because the internal 'devname'
    variable remains None. Later writing p-devname to xenstore fails because None
    is not a valid string variable.
    
    Since devname is used for just informational purpose use sg also as devname.
    
    carron:~ $ lsscsi -g
    [0:0:0:0]    disk    ATA      FK0032CAAZP      HPF2  /dev/sda   /dev/sg0
    [4:0:0:0]    disk    HP       P2000G3 FC/iSCSI T100  /dev/sdb   /dev/sg1
    [4:0:1:0]    disk    HP       P2000G3 FC/iSCSI T100  /dev/sdc   /dev/sg2
    [4:0:2:0]    storage HP       HSV400           0950  -         /dev/sg3
    [4:0:2:1]    disk    HP       HSV400           0950  /dev/sdd   /dev/sg4
    [4:0:3:0]    storage HP       HSV400           0950  -         /dev/sg5
    [4:0:3:1]    disk    HP       HSV400           0950  /dev/sde   /dev/sg6
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26007:fe756682cc7f
user:        Olaf Hering 
date:        Mon Oct 08 12:18:31 2012 +0100
    
    xenballoond.init: remove 4 from default runlevel
    
    Remove 4 from default runlevel in xenballoond.init.
    
    Similar to what changeset 24847:0900b1c905f1 does in xencommons, remove
    runlevel 4 from the other runlevel scripts. LSB defines runlevel 4 as
    reserved for local use, the local sysadmin is responsible for symlink
    creation in rc4.d.
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26006:8b6870d686d6
user:        Olaf Hering 
date:        Mon Oct 08 12:18:30 2012 +0100
    
    hotplug/Linux: Remove tracing (bash -x) from network-nat script
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26005:cdb48f1742f3
user:        Roger Pau Monne 
date:        Mon Oct 08 12:18:29 2012 +0100
    
    autoconf: add -Werror to libutil.h header check
    
    libutil.h is only needed on BSDs, but not in Linux. Debian package
    libbsd-dev-0.3.0-1 installed a libutil.h overlay that contains a
    
    Perform the libutil.h check with -Werror, so we don't include this
    bogus header.
    
    Signed-off-by: Roger Pau Monne 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26004:099589002239
user:        Anthony PERARD 
date:        Mon Oct 08 11:45:36 2012 +0100
    
    libxl: Allow migration with qemu-xen.
    
    Signed-off-by: Anthony PERARD 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 20:47:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 20:47:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLKEN-0004jU-19; Mon, 08 Oct 2012 20:47:15 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLKEL-0004jM-H3
	for Xen-devel@lists.xensource.com; Mon, 08 Oct 2012 20:47:13 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1349729222!9291066!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc5OTA1Nw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5430 invoked from network); 8 Oct 2012 20:47:03 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 20:47:03 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q98KkufC021615
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 8 Oct 2012 20:46:57 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q98Kkurx013067
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 8 Oct 2012 20:46:56 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q98Kktij032593; Mon, 8 Oct 2012 15:46:55 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 08 Oct 2012 13:46:55 -0700
Date: Mon, 8 Oct 2012 13:46:54 -0700
From: Mukesh Rathor 
To: Ian Campbell 
Message-ID: <20121008134654.588b35ac@mantra.us.oracle.com>
In-Reply-To: <1349724405.6952.53.camel@dagon.hellion.org.uk>
References: <20120921122123.33489ce1@mantra.us.oracle.com>
	<1349270495.650.144.camel@zakaz.uk.xensource.com>
	<20121003153106.65237f07@mantra.us.oracle.com>
	<1349340642.650.227.camel@zakaz.uk.xensource.com>
	<20121004112048.53767720@mantra.us.oracle.com>
	<1349428878.20946.18.camel@zakaz.uk.xensource.com>
	<20121005142240.340815be@mantra.us.oracle.com>
	<1349688102.18008.34.camel@zakaz.uk.xensource.com>
	<20121008121059.60094d43@mantra.us.oracle.com>
	<1349724405.6952.53.camel@dagon.hellion.org.uk>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "Xen-devel@lists.xensource.com" ,
	Stefano Stabellini ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH v1 7/8]: PVH privcmd changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 8 Oct 2012 20:26:45 +0100
Ian Campbell  wrote:

> On Mon, 2012-10-08 at 20:10 +0100, Mukesh Rathor wrote:
> > On Mon, 8 Oct 2012 10:21:42 +0100
> > Ian Campbell  wrote:
> > 
> > > On Fri, 2012-10-05 at 22:22 +0100, Mukesh Rathor wrote:
> > > > On Fri, 5 Oct 2012 10:21:18 +0100
> > > > Ian Campbell  wrote:
> > > > 
> > > > > On Thu, 2012-10-04 at 19:20 +0100, Mukesh Rathor wrote:
> > > > > > On Thu, 4 Oct 2012 09:50:42 +0100
> > > >         if (xen_feature(XENFEAT_auto_translated_physmap)) {
> > > >                 int sz = sizeof(vma->vm_private_data);
> > > >                 return (!__cmpxchg(&vma->vm_private_data, NULL,
> > > > NULL, sz));
> > > 
> > > Passing NULL for both old and new values can't be right, can it?
> > > Did you test with something which tries to map twice?
> > 
> > well, if it's already set to pointer, then __cmpxchg would leave
> > the ptr alone and return it. The function would then return false
> > which would fail the api. OTOH, if it's NULL, it would continue and
> > get set later.
> 
> What happens if a second thread tries to create a mapping while the
> first is between the cmpxchg and the assignment? i.e. while the value
> is still NULL.

Ah, right, I forgot multi threaded... 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 20:47:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 20:47:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLKEN-0004jU-19; Mon, 08 Oct 2012 20:47:15 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLKEL-0004jM-H3
	for Xen-devel@lists.xensource.com; Mon, 08 Oct 2012 20:47:13 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1349729222!9291066!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc5OTA1Nw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5430 invoked from network); 8 Oct 2012 20:47:03 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 20:47:03 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q98KkufC021615
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 8 Oct 2012 20:46:57 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q98Kkurx013067
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 8 Oct 2012 20:46:56 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q98Kktij032593; Mon, 8 Oct 2012 15:46:55 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 08 Oct 2012 13:46:55 -0700
Date: Mon, 8 Oct 2012 13:46:54 -0700
From: Mukesh Rathor 
To: Ian Campbell 
Message-ID: <20121008134654.588b35ac@mantra.us.oracle.com>
In-Reply-To: <1349724405.6952.53.camel@dagon.hellion.org.uk>
References: <20120921122123.33489ce1@mantra.us.oracle.com>
	<1349270495.650.144.camel@zakaz.uk.xensource.com>
	<20121003153106.65237f07@mantra.us.oracle.com>
	<1349340642.650.227.camel@zakaz.uk.xensource.com>
	<20121004112048.53767720@mantra.us.oracle.com>
	<1349428878.20946.18.camel@zakaz.uk.xensource.com>
	<20121005142240.340815be@mantra.us.oracle.com>
	<1349688102.18008.34.camel@zakaz.uk.xensource.com>
	<20121008121059.60094d43@mantra.us.oracle.com>
	<1349724405.6952.53.camel@dagon.hellion.org.uk>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "Xen-devel@lists.xensource.com" ,
	Stefano Stabellini ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH v1 7/8]: PVH privcmd changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 8 Oct 2012 20:26:45 +0100
Ian Campbell  wrote:

> On Mon, 2012-10-08 at 20:10 +0100, Mukesh Rathor wrote:
> > On Mon, 8 Oct 2012 10:21:42 +0100
> > Ian Campbell  wrote:
> > 
> > > On Fri, 2012-10-05 at 22:22 +0100, Mukesh Rathor wrote:
> > > > On Fri, 5 Oct 2012 10:21:18 +0100
> > > > Ian Campbell  wrote:
> > > > 
> > > > > On Thu, 2012-10-04 at 19:20 +0100, Mukesh Rathor wrote:
> > > > > > On Thu, 4 Oct 2012 09:50:42 +0100
> > > >         if (xen_feature(XENFEAT_auto_translated_physmap)) {
> > > >                 int sz = sizeof(vma->vm_private_data);
> > > >                 return (!__cmpxchg(&vma->vm_private_data, NULL,
> > > > NULL, sz));
> > > 
> > > Passing NULL for both old and new values can't be right, can it?
> > > Did you test with something which tries to map twice?
> > 
> > well, if it's already set to pointer, then __cmpxchg would leave
> > the ptr alone and return it. The function would then return false
> > which would fail the api. OTOH, if it's NULL, it would continue and
> > get set later.
> 
> What happens if a second thread tries to create a mapping while the
> first is between the cmpxchg and the assignment? i.e. while the value
> is still NULL.

Ah, right, I forgot multi threaded... 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 20:49:26 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 20:49:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLKG4-0004od-4X; Mon, 08 Oct 2012 20:49:00 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLKG2-0004oI-JE
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 20:48:58 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-15.tower-27.messagelabs.com!1349729331!1918003!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15609 invoked from network); 8 Oct 2012 20:48:51 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 20:48:51 -0000
Received: from relay2.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id CEF43A2111;
	Mon,  8 Oct 2012 22:48:48 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Alexander Graf 
In-Reply-To: <1349727605.3721.2@snotra>
Date: Mon, 8 Oct 2012 22:48:42 +0200
Message-Id: <8FB35BE8-7239-4317-8CB3-420E5D4E2D68@suse.de>
References: <1349699033-6703-1-git-send-email-agraf@suse.de>
	<1349699033-6703-14-git-send-email-agraf@suse.de>
	<1349727605.3721.2@snotra>
To: Scott Wood 
X-Mailer: Apple Mail (2.1278)
Cc: Anthony Liguori , xen-devel@lists.xensource.com,
	Stefano Stabellini ,
	qemu-devel qemu-devel ,
	"qemu-ppc@nongnu.org List" ,
	Avi Kivity , malc ,
	David Gibson 
Subject: Re: [Xen-devel] [PATCH 13/14] PPC: e500: Map PIO space into core
	memory region
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 08.10.2012, at 22:20, Scott Wood wrote:

> On 10/08/2012 07:23:52 AM, Alexander Graf wrote:
>> On PPC, we don't have PIO. So usually PIO space behind a PCI bridge is
>> accessible via MMIO. Do this mapping explicitly by mapping the PIO space
>> of our PCI bus into a memory region that lives in memory space.
>> Signed-off-by: Alexander Graf 
>> ---
>> hw/ppc/e500.c    |    3 +--
>> hw/ppce500_pci.c |    9 +++++++--
>> 2 files changed, 8 insertions(+), 4 deletions(-)
>> diff --git a/hw/ppc/e500.c b/hw/ppc/e500.c
>> index d23f9b2..857d4dc 100644
>> --- a/hw/ppc/e500.c
>> +++ b/hw/ppc/e500.c
>> @@ -52,7 +52,6 @@
>> #define MPC8544_PCI_REGS_BASE      (MPC8544_CCSRBAR_BASE + 0x8000ULL)
>> #define MPC8544_PCI_REGS_SIZE      0x1000ULL
>> #define MPC8544_PCI_IO             0xE1000000ULL
>> -#define MPC8544_PCI_IOLEN          0x10000ULL
>> #define MPC8544_UTIL_BASE          (MPC8544_CCSRBAR_BASE + 0xe0000ULL)
>> #define MPC8544_SPIN_BASE          0xEF000000ULL
>> @@ -511,7 +510,7 @@ void ppce500_init(PPCE500Params *params)
>>     if (!pci_bus)
>>         printf("couldn't create PCI controller!\n");
>> -    isa_mmio_init(MPC8544_PCI_IO, MPC8544_PCI_IOLEN);
>> +    sysbus_mmio_map(sysbus_from_qdev(dev), 1, MPC8544_PCI_IO);
>>     if (pci_bus) {
>>         /* Register network interfaces. */
>> diff --git a/hw/ppce500_pci.c b/hw/ppce500_pci.c
>> index 92b1dc0..27c6d7d 100644
>> --- a/hw/ppce500_pci.c
>> +++ b/hw/ppce500_pci.c
>> @@ -31,6 +31,8 @@
>> #define PCIE500_ALL_SIZE      0x1000
>> #define PCIE500_REG_SIZE      (PCIE500_ALL_SIZE - PCIE500_REG_BASE)
>> +#define PCIE500_PCI_IOLEN     0x10000ULL
> 
> I don't think this belongs in ppce500_pci.c -- it's board config (or rather, a board-related default of something that is supposed to be software configurable), just like the base address.

Actually this one is fixed in PCI. There are only 64k PIO ports.

> Any chance of similarly constraining PCI MMIO to its proper window?

We can't distinguish between inbound and outbound right now. If we only need to restrict CPU -> PCI access, then yes.


Alex


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 20:49:26 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 20:49:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLKG4-0004od-4X; Mon, 08 Oct 2012 20:49:00 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLKG2-0004oI-JE
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 20:48:58 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-15.tower-27.messagelabs.com!1349729331!1918003!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15609 invoked from network); 8 Oct 2012 20:48:51 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 20:48:51 -0000
Received: from relay2.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id CEF43A2111;
	Mon,  8 Oct 2012 22:48:48 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Alexander Graf 
In-Reply-To: <1349727605.3721.2@snotra>
Date: Mon, 8 Oct 2012 22:48:42 +0200
Message-Id: <8FB35BE8-7239-4317-8CB3-420E5D4E2D68@suse.de>
References: <1349699033-6703-1-git-send-email-agraf@suse.de>
	<1349699033-6703-14-git-send-email-agraf@suse.de>
	<1349727605.3721.2@snotra>
To: Scott Wood 
X-Mailer: Apple Mail (2.1278)
Cc: Anthony Liguori , xen-devel@lists.xensource.com,
	Stefano Stabellini ,
	qemu-devel qemu-devel ,
	"qemu-ppc@nongnu.org List" ,
	Avi Kivity , malc ,
	David Gibson 
Subject: Re: [Xen-devel] [PATCH 13/14] PPC: e500: Map PIO space into core
	memory region
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 08.10.2012, at 22:20, Scott Wood wrote:

> On 10/08/2012 07:23:52 AM, Alexander Graf wrote:
>> On PPC, we don't have PIO. So usually PIO space behind a PCI bridge is
>> accessible via MMIO. Do this mapping explicitly by mapping the PIO space
>> of our PCI bus into a memory region that lives in memory space.
>> Signed-off-by: Alexander Graf 
>> ---
>> hw/ppc/e500.c    |    3 +--
>> hw/ppce500_pci.c |    9 +++++++--
>> 2 files changed, 8 insertions(+), 4 deletions(-)
>> diff --git a/hw/ppc/e500.c b/hw/ppc/e500.c
>> index d23f9b2..857d4dc 100644
>> --- a/hw/ppc/e500.c
>> +++ b/hw/ppc/e500.c
>> @@ -52,7 +52,6 @@
>> #define MPC8544_PCI_REGS_BASE      (MPC8544_CCSRBAR_BASE + 0x8000ULL)
>> #define MPC8544_PCI_REGS_SIZE      0x1000ULL
>> #define MPC8544_PCI_IO             0xE1000000ULL
>> -#define MPC8544_PCI_IOLEN          0x10000ULL
>> #define MPC8544_UTIL_BASE          (MPC8544_CCSRBAR_BASE + 0xe0000ULL)
>> #define MPC8544_SPIN_BASE          0xEF000000ULL
>> @@ -511,7 +510,7 @@ void ppce500_init(PPCE500Params *params)
>>     if (!pci_bus)
>>         printf("couldn't create PCI controller!\n");
>> -    isa_mmio_init(MPC8544_PCI_IO, MPC8544_PCI_IOLEN);
>> +    sysbus_mmio_map(sysbus_from_qdev(dev), 1, MPC8544_PCI_IO);
>>     if (pci_bus) {
>>         /* Register network interfaces. */
>> diff --git a/hw/ppce500_pci.c b/hw/ppce500_pci.c
>> index 92b1dc0..27c6d7d 100644
>> --- a/hw/ppce500_pci.c
>> +++ b/hw/ppce500_pci.c
>> @@ -31,6 +31,8 @@
>> #define PCIE500_ALL_SIZE      0x1000
>> #define PCIE500_REG_SIZE      (PCIE500_ALL_SIZE - PCIE500_REG_BASE)
>> +#define PCIE500_PCI_IOLEN     0x10000ULL
> 
> I don't think this belongs in ppce500_pci.c -- it's board config (or rather, a board-related default of something that is supposed to be software configurable), just like the base address.

Actually this one is fixed in PCI. There are only 64k PIO ports.

> Any chance of similarly constraining PCI MMIO to its proper window?

We can't distinguish between inbound and outbound right now. If we only need to restrict CPU -> PCI access, then yes.


Alex


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 21:08:59 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 21:08:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLKZ6-0005RH-6w; Mon, 08 Oct 2012 21:08:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLKZ4-0005RC-7l
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 21:08:38 +0000
Received: from [85.158.139.83:25298] by server-5.bemta-5.messagelabs.com id
	8E/B2-21075-5D043705; Mon, 08 Oct 2012 21:08:37 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-2.tower-182.messagelabs.com!1349730516!31097829!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12942 invoked from network); 8 Oct 2012 21:08:36 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 21:08:36 -0000
Received: from relay1.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id D8B76A24CA;
	Mon,  8 Oct 2012 23:08:35 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Alexander Graf 
In-Reply-To: <1349730318.3721.9@snotra>
Date: Mon, 8 Oct 2012 23:08:31 +0200
Message-Id: <11F10FDD-2CA3-4456-A77D-E45C249D8904@suse.de>
References: <1349730318.3721.9@snotra>
To: Scott Wood 
X-Mailer: Apple Mail (2.1278)
Cc: Anthony Liguori , xen-devel@lists.xensource.com,
	Stefano Stabellini ,
	qemu-devel qemu-devel ,
	"qemu-ppc@nongnu.org List" ,
	Avi Kivity , malc ,
	David Gibson 
Subject: Re: [Xen-devel] [PATCH 13/14] PPC: e500: Map PIO space into core
	memory region
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 08.10.2012, at 23:05, Scott Wood wrote:

> On 10/08/2012 03:48:42 PM, Alexander Graf wrote:
>> On 08.10.2012, at 22:20, Scott Wood wrote:
>> > On 10/08/2012 07:23:52 AM, Alexander Graf wrote:
>> >> On PPC, we don't have PIO. So usually PIO space behind a PCI bridge is
>> >> accessible via MMIO. Do this mapping explicitly by mapping the PIO space
>> >> of our PCI bus into a memory region that lives in memory space.
>> >> Signed-off-by: Alexander Graf 
>> >> ---
>> >> hw/ppc/e500.c    |    3 +--
>> >> hw/ppce500_pci.c |    9 +++++++--
>> >> 2 files changed, 8 insertions(+), 4 deletions(-)
>> >> diff --git a/hw/ppc/e500.c b/hw/ppc/e500.c
>> >> index d23f9b2..857d4dc 100644
>> >> --- a/hw/ppc/e500.c
>> >> +++ b/hw/ppc/e500.c
>> >> @@ -52,7 +52,6 @@
>> >> #define MPC8544_PCI_REGS_BASE      (MPC8544_CCSRBAR_BASE + 0x8000ULL)
>> >> #define MPC8544_PCI_REGS_SIZE      0x1000ULL
>> >> #define MPC8544_PCI_IO             0xE1000000ULL
>> >> -#define MPC8544_PCI_IOLEN          0x10000ULL
>> >> #define MPC8544_UTIL_BASE          (MPC8544_CCSRBAR_BASE + 0xe0000ULL)
>> >> #define MPC8544_SPIN_BASE          0xEF000000ULL
>> >> @@ -511,7 +510,7 @@ void ppce500_init(PPCE500Params *params)
>> >>     if (!pci_bus)
>> >>         printf("couldn't create PCI controller!\n");
>> >> -    isa_mmio_init(MPC8544_PCI_IO, MPC8544_PCI_IOLEN);
>> >> +    sysbus_mmio_map(sysbus_from_qdev(dev), 1, MPC8544_PCI_IO);
>> >>     if (pci_bus) {
>> >>         /* Register network interfaces. */
>> >> diff --git a/hw/ppce500_pci.c b/hw/ppce500_pci.c
>> >> index 92b1dc0..27c6d7d 100644
>> >> --- a/hw/ppce500_pci.c
>> >> +++ b/hw/ppce500_pci.c
>> >> @@ -31,6 +31,8 @@
>> >> #define PCIE500_ALL_SIZE      0x1000
>> >> #define PCIE500_REG_SIZE      (PCIE500_ALL_SIZE - PCIE500_REG_BASE)
>> >> +#define PCIE500_PCI_IOLEN     0x10000ULL
>> >
>> > I don't think this belongs in ppce500_pci.c -- it's board config (or rather, a board-related default of something that is supposed to be software configurable), just like the base address.
>> Actually this one is fixed in PCI. There are only 64k PIO ports.
> 
> Are you sure about that?  Certainly that's the limit on x86 due to the I/O instructions, and some (buggy?) PCI devices might have trouble with larger I/O addresses, but I didn't think it was actually illegal.  Some mpc85xx boards have default configs with larger I/O windows (though probably not for any good reason).

What sense would it make to model an ioport range that exceeds what x86 can do? I'm fairly sure if you'd ever start using that, you'll see a lot of PCI devices fail at you anyway.

> 
>> > Any chance of similarly constraining PCI MMIO to its proper window?
>> We can't distinguish between inbound and outbound right now. If we only need to restrict CPU -> PCI access, then yes.
> 
> Better than nothing. :-)

If you can point me to the part of the spec that specifies how that window should look like, I can cook up a patch. Or you can do it of course ;).


Alex


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 21:08:59 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 21:08:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLKZ6-0005RH-6w; Mon, 08 Oct 2012 21:08:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLKZ4-0005RC-7l
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 21:08:38 +0000
Received: from [85.158.139.83:25298] by server-5.bemta-5.messagelabs.com id
	8E/B2-21075-5D043705; Mon, 08 Oct 2012 21:08:37 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-2.tower-182.messagelabs.com!1349730516!31097829!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12942 invoked from network); 8 Oct 2012 21:08:36 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 21:08:36 -0000
Received: from relay1.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id D8B76A24CA;
	Mon,  8 Oct 2012 23:08:35 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Alexander Graf 
In-Reply-To: <1349730318.3721.9@snotra>
Date: Mon, 8 Oct 2012 23:08:31 +0200
Message-Id: <11F10FDD-2CA3-4456-A77D-E45C249D8904@suse.de>
References: <1349730318.3721.9@snotra>
To: Scott Wood 
X-Mailer: Apple Mail (2.1278)
Cc: Anthony Liguori , xen-devel@lists.xensource.com,
	Stefano Stabellini ,
	qemu-devel qemu-devel ,
	"qemu-ppc@nongnu.org List" ,
	Avi Kivity , malc ,
	David Gibson 
Subject: Re: [Xen-devel] [PATCH 13/14] PPC: e500: Map PIO space into core
	memory region
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 08.10.2012, at 23:05, Scott Wood wrote:

> On 10/08/2012 03:48:42 PM, Alexander Graf wrote:
>> On 08.10.2012, at 22:20, Scott Wood wrote:
>> > On 10/08/2012 07:23:52 AM, Alexander Graf wrote:
>> >> On PPC, we don't have PIO. So usually PIO space behind a PCI bridge is
>> >> accessible via MMIO. Do this mapping explicitly by mapping the PIO space
>> >> of our PCI bus into a memory region that lives in memory space.
>> >> Signed-off-by: Alexander Graf 
>> >> ---
>> >> hw/ppc/e500.c    |    3 +--
>> >> hw/ppce500_pci.c |    9 +++++++--
>> >> 2 files changed, 8 insertions(+), 4 deletions(-)
>> >> diff --git a/hw/ppc/e500.c b/hw/ppc/e500.c
>> >> index d23f9b2..857d4dc 100644
>> >> --- a/hw/ppc/e500.c
>> >> +++ b/hw/ppc/e500.c
>> >> @@ -52,7 +52,6 @@
>> >> #define MPC8544_PCI_REGS_BASE      (MPC8544_CCSRBAR_BASE + 0x8000ULL)
>> >> #define MPC8544_PCI_REGS_SIZE      0x1000ULL
>> >> #define MPC8544_PCI_IO             0xE1000000ULL
>> >> -#define MPC8544_PCI_IOLEN          0x10000ULL
>> >> #define MPC8544_UTIL_BASE          (MPC8544_CCSRBAR_BASE + 0xe0000ULL)
>> >> #define MPC8544_SPIN_BASE          0xEF000000ULL
>> >> @@ -511,7 +510,7 @@ void ppce500_init(PPCE500Params *params)
>> >>     if (!pci_bus)
>> >>         printf("couldn't create PCI controller!\n");
>> >> -    isa_mmio_init(MPC8544_PCI_IO, MPC8544_PCI_IOLEN);
>> >> +    sysbus_mmio_map(sysbus_from_qdev(dev), 1, MPC8544_PCI_IO);
>> >>     if (pci_bus) {
>> >>         /* Register network interfaces. */
>> >> diff --git a/hw/ppce500_pci.c b/hw/ppce500_pci.c
>> >> index 92b1dc0..27c6d7d 100644
>> >> --- a/hw/ppce500_pci.c
>> >> +++ b/hw/ppce500_pci.c
>> >> @@ -31,6 +31,8 @@
>> >> #define PCIE500_ALL_SIZE      0x1000
>> >> #define PCIE500_REG_SIZE      (PCIE500_ALL_SIZE - PCIE500_REG_BASE)
>> >> +#define PCIE500_PCI_IOLEN     0x10000ULL
>> >
>> > I don't think this belongs in ppce500_pci.c -- it's board config (or rather, a board-related default of something that is supposed to be software configurable), just like the base address.
>> Actually this one is fixed in PCI. There are only 64k PIO ports.
> 
> Are you sure about that?  Certainly that's the limit on x86 due to the I/O instructions, and some (buggy?) PCI devices might have trouble with larger I/O addresses, but I didn't think it was actually illegal.  Some mpc85xx boards have default configs with larger I/O windows (though probably not for any good reason).

What sense would it make to model an ioport range that exceeds what x86 can do? I'm fairly sure if you'd ever start using that, you'll see a lot of PCI devices fail at you anyway.

> 
>> > Any chance of similarly constraining PCI MMIO to its proper window?
>> We can't distinguish between inbound and outbound right now. If we only need to restrict CPU -> PCI access, then yes.
> 
> Better than nothing. :-)

If you can point me to the part of the spec that specifies how that window should look like, I can cook up a patch. Or you can do it of course ;).


Alex


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 21:13:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 21:13:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLKdf-0005Z8-Sm; Mon, 08 Oct 2012 21:13:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLKde-0005Z2-68
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 21:13:22 +0000
Received: from [85.158.138.51:46373] by server-15.bemta-3.messagelabs.com id
	68/E1-11584-1F143705; Mon, 08 Oct 2012 21:13:21 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-174.messagelabs.com!1349730800!33536701!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MzMyNzM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MzMyNzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27186 invoked from network); 8 Oct 2012 21:13:20 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 21:13:20 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk287sE5w=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-092-071.pools.arcor-ip.net [84.57.92.71])
	by smtp.strato.de (jored mo24) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id v06879o98H7YuJ ;
	Mon, 8 Oct 2012 23:13:18 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 5616618642; Mon,  8 Oct 2012 23:13:16 +0200 (CEST)
Date: Mon, 8 Oct 2012 23:13:16 +0200
From: Olaf Hering 
To: Dan Magenheimer 
Message-ID: <20121008211316.GA30282@aepfle.de>
References: <65ab6762cd37d0f43ff0.1349458510@probook.site>
	<2d303534-6274-4adb-bd45-92faf55a5027@default>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <2d303534-6274-4adb-bd45-92faf55a5027@default>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xenballoond.init: remove 4 from default
 runlevel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 08, Dan Magenheimer wrote:

> Are you using xenballoond for something?  (e.g. your page-sharing
> testing or a product implementation)

No, its just a result from code review.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 21:13:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 21:13:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLKdf-0005Z8-Sm; Mon, 08 Oct 2012 21:13:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLKde-0005Z2-68
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 21:13:22 +0000
Received: from [85.158.138.51:46373] by server-15.bemta-3.messagelabs.com id
	68/E1-11584-1F143705; Mon, 08 Oct 2012 21:13:21 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-174.messagelabs.com!1349730800!33536701!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MzMyNzM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MzMyNzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27186 invoked from network); 8 Oct 2012 21:13:20 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Oct 2012 21:13:20 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk287sE5w=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-092-071.pools.arcor-ip.net [84.57.92.71])
	by smtp.strato.de (jored mo24) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id v06879o98H7YuJ ;
	Mon, 8 Oct 2012 23:13:18 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 5616618642; Mon,  8 Oct 2012 23:13:16 +0200 (CEST)
Date: Mon, 8 Oct 2012 23:13:16 +0200
From: Olaf Hering 
To: Dan Magenheimer 
Message-ID: <20121008211316.GA30282@aepfle.de>
References: <65ab6762cd37d0f43ff0.1349458510@probook.site>
	<2d303534-6274-4adb-bd45-92faf55a5027@default>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <2d303534-6274-4adb-bd45-92faf55a5027@default>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xenballoond.init: remove 4 from default
 runlevel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 08, Dan Magenheimer wrote:

> Are you using xenballoond for something?  (e.g. your page-sharing
> testing or a product implementation)

No, its just a result from code review.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 21:14:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 21:14:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLKeG-0005cA-LW; Mon, 08 Oct 2012 21:14:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLKW2-0005Qc-Jn
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 21:05:30 +0000
Received: from [85.158.138.51:63135] by server-6.bemta-3.messagelabs.com id
	26/3E-11085-91043705; Mon, 08 Oct 2012 21:05:29 +0000
X-Env-Sender: B07421@freescale.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1349730328!25543051!1
X-Originating-IP: [213.199.154.206]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5859 invoked from network); 8 Oct 2012 21:05:29 -0000
Received: from am1ehsobe003.messaging.microsoft.com (HELO
	am1outboundpool.messaging.microsoft.com) (213.199.154.206)
	by server-6.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	8 Oct 2012 21:05:29 -0000
Received: from mail77-am1-R.bigfish.com (10.3.201.230) by
	AM1EHSOBE010.bigfish.com (10.3.204.30) with Microsoft SMTP Server id
	14.1.225.23; Mon, 8 Oct 2012 21:05:27 +0000
Received: from mail77-am1 (localhost [127.0.0.1])	by mail77-am1-R.bigfish.com
	(Postfix) with ESMTP id C22BD36012E;
	Mon,  8 Oct 2012 21:05:27 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:70.37.183.190; KIP:(null); UIP:(null); IPV:NLI;
	H:mail.freescale.net; RD:none; EFVD:NLI
X-SpamScore: -4
X-BigFish: VS-4(zzbb2dI98dI9371I1432Izz1202h1d1ah1d2ahzzz2dh2a8h668h839h944hd2bhf0ah107ah1288h12a5h12a9h12bdh137ah139eh13b6h1441h1155h)
Received: from mail77-am1 (localhost.localdomain [127.0.0.1]) by mail77-am1
	(MessageSwitch) id 1349730325841455_12664;
	Mon,  8 Oct 2012 21:05:25 +0000 (UTC)
Received: from AM1EHSMHS018.bigfish.com (unknown [10.3.201.251])	by
	mail77-am1.bigfish.com (Postfix) with ESMTP id BFAE41C0050;
	Mon,  8 Oct 2012 21:05:25 +0000 (UTC)
Received: from mail.freescale.net (70.37.183.190) by AM1EHSMHS018.bigfish.com
	(10.3.207.156) with Microsoft SMTP Server (TLS) id 14.1.225.23;
	Mon, 8 Oct 2012 21:05:22 +0000
Received: from az84smr01.freescale.net (10.64.34.197) by
	039-SN1MMR1-001.039d.mgd.msft.net (10.84.1.13) with Microsoft SMTP
	Server (TLS) id 14.2.309.3; Mon, 8 Oct 2012 21:05:20 +0000
Received: from snotra ([10.214.86.163])	by az84smr01.freescale.net
	(8.14.3/8.14.0) with ESMTP id q98L5IIq021784;
	Mon, 8 Oct 2012 14:05:18 -0700
Date: Mon, 8 Oct 2012 16:05:18 -0500
From: Scott Wood 
To: Alexander Graf 
In-Reply-To: <8FB35BE8-7239-4317-8CB3-420E5D4E2D68@suse.de> (from
	agraf@suse.de on Mon Oct  8 15:48:42 2012)
X-Mailer: Balsa 2.4.11
Message-ID: <1349730318.3721.9@snotra>
MIME-Version: 1.0
Content-Disposition: inline
X-OriginatorOrg: freescale.com
X-Mailman-Approved-At: Mon, 08 Oct 2012 21:13:59 +0000
Cc: Anthony Liguori , xen-devel@lists.xensource.com,
	Stefano Stabellini ,
	qemu-devel qemu-devel ,
	"qemu-ppc@nongnu.org List" ,
	Avi Kivity , malc ,
	David Gibson 
Subject: Re: [Xen-devel] [PATCH 13/14] PPC: e500: Map PIO space into core
	memory region
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="Flowed"; DelSp="Yes"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/08/2012 03:48:42 PM, Alexander Graf wrote:
> 
> On 08.10.2012, at 22:20, Scott Wood wrote:
> 
> > On 10/08/2012 07:23:52 AM, Alexander Graf wrote:
> >> On PPC, we don't have PIO. So usually PIO space behind a PCI  
> bridge is
> >> accessible via MMIO. Do this mapping explicitly by mapping the PIO  
> space
> >> of our PCI bus into a memory region that lives in memory space.
> >> Signed-off-by: Alexander Graf 
> >> ---
> >> hw/ppc/e500.c    |    3 +--
> >> hw/ppce500_pci.c |    9 +++++++--
> >> 2 files changed, 8 insertions(+), 4 deletions(-)
> >> diff --git a/hw/ppc/e500.c b/hw/ppc/e500.c
> >> index d23f9b2..857d4dc 100644
> >> --- a/hw/ppc/e500.c
> >> +++ b/hw/ppc/e500.c
> >> @@ -52,7 +52,6 @@
> >> #define MPC8544_PCI_REGS_BASE      (MPC8544_CCSRBAR_BASE +  
> 0x8000ULL)
> >> #define MPC8544_PCI_REGS_SIZE      0x1000ULL
> >> #define MPC8544_PCI_IO             0xE1000000ULL
> >> -#define MPC8544_PCI_IOLEN          0x10000ULL
> >> #define MPC8544_UTIL_BASE          (MPC8544_CCSRBAR_BASE +  
> 0xe0000ULL)
> >> #define MPC8544_SPIN_BASE          0xEF000000ULL
> >> @@ -511,7 +510,7 @@ void ppce500_init(PPCE500Params *params)
> >>     if (!pci_bus)
> >>         printf("couldn't create PCI controller!\n");
> >> -    isa_mmio_init(MPC8544_PCI_IO, MPC8544_PCI_IOLEN);
> >> +    sysbus_mmio_map(sysbus_from_qdev(dev), 1, MPC8544_PCI_IO);
> >>     if (pci_bus) {
> >>         /* Register network interfaces. */
> >> diff --git a/hw/ppce500_pci.c b/hw/ppce500_pci.c
> >> index 92b1dc0..27c6d7d 100644
> >> --- a/hw/ppce500_pci.c
> >> +++ b/hw/ppce500_pci.c
> >> @@ -31,6 +31,8 @@
> >> #define PCIE500_ALL_SIZE      0x1000
> >> #define PCIE500_REG_SIZE      (PCIE500_ALL_SIZE - PCIE500_REG_BASE)
> >> +#define PCIE500_PCI_IOLEN     0x10000ULL
> >
> > I don't think this belongs in ppce500_pci.c -- it's board config  
> (or rather, a board-related default of something that is supposed to  
> be software configurable), just like the base address.
> 
> Actually this one is fixed in PCI. There are only 64k PIO ports.

Are you sure about that?  Certainly that's the limit on x86 due to the  
I/O instructions, and some (buggy?) PCI devices might have trouble with  
larger I/O addresses, but I didn't think it was actually illegal.  Some  
mpc85xx boards have default configs with larger I/O windows (though  
probably not for any good reason).

> > Any chance of similarly constraining PCI MMIO to its proper window?
> 
> We can't distinguish between inbound and outbound right now. If we  
> only need to restrict CPU -> PCI access, then yes.

Better than nothing. :-)

-Scott

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 21:14:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 21:14:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLKeG-0005cA-LW; Mon, 08 Oct 2012 21:14:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLKW2-0005Qc-Jn
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 21:05:30 +0000
Received: from [85.158.138.51:63135] by server-6.bemta-3.messagelabs.com id
	26/3E-11085-91043705; Mon, 08 Oct 2012 21:05:29 +0000
X-Env-Sender: B07421@freescale.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1349730328!25543051!1
X-Originating-IP: [213.199.154.206]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5859 invoked from network); 8 Oct 2012 21:05:29 -0000
Received: from am1ehsobe003.messaging.microsoft.com (HELO
	am1outboundpool.messaging.microsoft.com) (213.199.154.206)
	by server-6.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	8 Oct 2012 21:05:29 -0000
Received: from mail77-am1-R.bigfish.com (10.3.201.230) by
	AM1EHSOBE010.bigfish.com (10.3.204.30) with Microsoft SMTP Server id
	14.1.225.23; Mon, 8 Oct 2012 21:05:27 +0000
Received: from mail77-am1 (localhost [127.0.0.1])	by mail77-am1-R.bigfish.com
	(Postfix) with ESMTP id C22BD36012E;
	Mon,  8 Oct 2012 21:05:27 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:70.37.183.190; KIP:(null); UIP:(null); IPV:NLI;
	H:mail.freescale.net; RD:none; EFVD:NLI
X-SpamScore: -4
X-BigFish: VS-4(zzbb2dI98dI9371I1432Izz1202h1d1ah1d2ahzzz2dh2a8h668h839h944hd2bhf0ah107ah1288h12a5h12a9h12bdh137ah139eh13b6h1441h1155h)
Received: from mail77-am1 (localhost.localdomain [127.0.0.1]) by mail77-am1
	(MessageSwitch) id 1349730325841455_12664;
	Mon,  8 Oct 2012 21:05:25 +0000 (UTC)
Received: from AM1EHSMHS018.bigfish.com (unknown [10.3.201.251])	by
	mail77-am1.bigfish.com (Postfix) with ESMTP id BFAE41C0050;
	Mon,  8 Oct 2012 21:05:25 +0000 (UTC)
Received: from mail.freescale.net (70.37.183.190) by AM1EHSMHS018.bigfish.com
	(10.3.207.156) with Microsoft SMTP Server (TLS) id 14.1.225.23;
	Mon, 8 Oct 2012 21:05:22 +0000
Received: from az84smr01.freescale.net (10.64.34.197) by
	039-SN1MMR1-001.039d.mgd.msft.net (10.84.1.13) with Microsoft SMTP
	Server (TLS) id 14.2.309.3; Mon, 8 Oct 2012 21:05:20 +0000
Received: from snotra ([10.214.86.163])	by az84smr01.freescale.net
	(8.14.3/8.14.0) with ESMTP id q98L5IIq021784;
	Mon, 8 Oct 2012 14:05:18 -0700
Date: Mon, 8 Oct 2012 16:05:18 -0500
From: Scott Wood 
To: Alexander Graf 
In-Reply-To: <8FB35BE8-7239-4317-8CB3-420E5D4E2D68@suse.de> (from
	agraf@suse.de on Mon Oct  8 15:48:42 2012)
X-Mailer: Balsa 2.4.11
Message-ID: <1349730318.3721.9@snotra>
MIME-Version: 1.0
Content-Disposition: inline
X-OriginatorOrg: freescale.com
X-Mailman-Approved-At: Mon, 08 Oct 2012 21:13:59 +0000
Cc: Anthony Liguori , xen-devel@lists.xensource.com,
	Stefano Stabellini ,
	qemu-devel qemu-devel ,
	"qemu-ppc@nongnu.org List" ,
	Avi Kivity , malc ,
	David Gibson 
Subject: Re: [Xen-devel] [PATCH 13/14] PPC: e500: Map PIO space into core
	memory region
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="Flowed"; DelSp="Yes"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/08/2012 03:48:42 PM, Alexander Graf wrote:
> 
> On 08.10.2012, at 22:20, Scott Wood wrote:
> 
> > On 10/08/2012 07:23:52 AM, Alexander Graf wrote:
> >> On PPC, we don't have PIO. So usually PIO space behind a PCI  
> bridge is
> >> accessible via MMIO. Do this mapping explicitly by mapping the PIO  
> space
> >> of our PCI bus into a memory region that lives in memory space.
> >> Signed-off-by: Alexander Graf 
> >> ---
> >> hw/ppc/e500.c    |    3 +--
> >> hw/ppce500_pci.c |    9 +++++++--
> >> 2 files changed, 8 insertions(+), 4 deletions(-)
> >> diff --git a/hw/ppc/e500.c b/hw/ppc/e500.c
> >> index d23f9b2..857d4dc 100644
> >> --- a/hw/ppc/e500.c
> >> +++ b/hw/ppc/e500.c
> >> @@ -52,7 +52,6 @@
> >> #define MPC8544_PCI_REGS_BASE      (MPC8544_CCSRBAR_BASE +  
> 0x8000ULL)
> >> #define MPC8544_PCI_REGS_SIZE      0x1000ULL
> >> #define MPC8544_PCI_IO             0xE1000000ULL
> >> -#define MPC8544_PCI_IOLEN          0x10000ULL
> >> #define MPC8544_UTIL_BASE          (MPC8544_CCSRBAR_BASE +  
> 0xe0000ULL)
> >> #define MPC8544_SPIN_BASE          0xEF000000ULL
> >> @@ -511,7 +510,7 @@ void ppce500_init(PPCE500Params *params)
> >>     if (!pci_bus)
> >>         printf("couldn't create PCI controller!\n");
> >> -    isa_mmio_init(MPC8544_PCI_IO, MPC8544_PCI_IOLEN);
> >> +    sysbus_mmio_map(sysbus_from_qdev(dev), 1, MPC8544_PCI_IO);
> >>     if (pci_bus) {
> >>         /* Register network interfaces. */
> >> diff --git a/hw/ppce500_pci.c b/hw/ppce500_pci.c
> >> index 92b1dc0..27c6d7d 100644
> >> --- a/hw/ppce500_pci.c
> >> +++ b/hw/ppce500_pci.c
> >> @@ -31,6 +31,8 @@
> >> #define PCIE500_ALL_SIZE      0x1000
> >> #define PCIE500_REG_SIZE      (PCIE500_ALL_SIZE - PCIE500_REG_BASE)
> >> +#define PCIE500_PCI_IOLEN     0x10000ULL
> >
> > I don't think this belongs in ppce500_pci.c -- it's board config  
> (or rather, a board-related default of something that is supposed to  
> be software configurable), just like the base address.
> 
> Actually this one is fixed in PCI. There are only 64k PIO ports.

Are you sure about that?  Certainly that's the limit on x86 due to the  
I/O instructions, and some (buggy?) PCI devices might have trouble with  
larger I/O addresses, but I didn't think it was actually illegal.  Some  
mpc85xx boards have default configs with larger I/O windows (though  
probably not for any good reason).

> > Any chance of similarly constraining PCI MMIO to its proper window?
> 
> We can't distinguish between inbound and outbound right now. If we  
> only need to restrict CPU -> PCI access, then yes.

Better than nothing. :-)

-Scott

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 21:14:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 21:14:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLKeG-0005c3-A3; Mon, 08 Oct 2012 21:14:00 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLJpF-0004fD-3N
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 20:21:17 +0000
X-Env-Sender: B07421@freescale.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1349727664!12498686!1
X-Originating-IP: [216.32.180.189]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22470 invoked from network); 8 Oct 2012 20:21:06 -0000
Received: from co1ehsobe006.messaging.microsoft.com (HELO
	co1outboundpool.messaging.microsoft.com) (216.32.180.189)
	by server-16.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	8 Oct 2012 20:21:06 -0000
Received: from mail139-co1-R.bigfish.com (10.243.78.229) by
	CO1EHSOBE003.bigfish.com (10.243.66.66) with Microsoft SMTP Server id
	14.1.225.23; Mon, 8 Oct 2012 20:21:03 +0000
Received: from mail139-co1 (localhost [127.0.0.1])	by
	mail139-co1-R.bigfish.com (Postfix) with ESMTP id 302564800A6;
	Mon,  8 Oct 2012 20:21:02 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:70.37.183.190; KIP:(null); UIP:(null); IPV:NLI;
	H:mail.freescale.net; RD:none; EFVD:NLI
X-SpamScore: -4
X-BigFish: VS-4(zzbb2dI98dI9371I1432Izz1202h1d1ah1d2ahzzz2dh2a8h668h839h944hd2bhf0ah107ah1288h12a5h12a9h12bdh137ah139eh13b6h1441h1155h)
Received: from mail139-co1 (localhost.localdomain [127.0.0.1]) by mail139-co1
	(MessageSwitch) id 1349727618313402_31959;
	Mon,  8 Oct 2012 20:20:18 +0000 (UTC)
Received: from CO1EHSMHS009.bigfish.com (unknown [10.243.78.248])	by
	mail139-co1.bigfish.com (Postfix) with ESMTP id 3EB27200045;
	Mon,  8 Oct 2012 20:20:18 +0000 (UTC)
Received: from mail.freescale.net (70.37.183.190) by CO1EHSMHS009.bigfish.com
	(10.243.66.19) with Microsoft SMTP Server (TLS) id 14.1.225.23;
	Mon, 8 Oct 2012 20:20:14 +0000
Received: from az84smr01.freescale.net (10.64.34.197) by
	039-SN1MMR1-001.039d.mgd.msft.net (10.84.1.13) with Microsoft SMTP
	Server (TLS) id 14.2.309.3; Mon, 8 Oct 2012 20:20:12 +0000
Received: from snotra ([10.214.86.163])	by az84smr01.freescale.net
	(8.14.3/8.14.0) with ESMTP id q98KK5Nu004057;
	Mon, 8 Oct 2012 13:20:05 -0700
Date: Mon, 8 Oct 2012 15:20:05 -0500
From: Scott Wood 
To: Alexander Graf 
References: <1349699033-6703-1-git-send-email-agraf@suse.de>
	<1349699033-6703-14-git-send-email-agraf@suse.de>
In-Reply-To: <1349699033-6703-14-git-send-email-agraf@suse.de> (from
	agraf@suse.de on Mon Oct  8 07:23:52 2012)
X-Mailer: Balsa 2.4.11
Message-ID: <1349727605.3721.2@snotra>
MIME-Version: 1.0
Content-Disposition: inline
X-OriginatorOrg: freescale.com
X-Mailman-Approved-At: Mon, 08 Oct 2012 21:13:59 +0000
Cc: Anthony Liguori , xen-devel@lists.xensource.com,
	Stefano Stabellini ,
	qemu-devel qemu-devel ,
	"qemu-ppc@nongnu.org List" ,
	Avi Kivity , malc ,
	David Gibson 
Subject: Re: [Xen-devel] [PATCH 13/14] PPC: e500: Map PIO space into core
	memory region
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="Flowed"; DelSp="Yes"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/08/2012 07:23:52 AM, Alexander Graf wrote:
> On PPC, we don't have PIO. So usually PIO space behind a PCI bridge is
> accessible via MMIO. Do this mapping explicitly by mapping the PIO  
> space
> of our PCI bus into a memory region that lives in memory space.
> 
> Signed-off-by: Alexander Graf 
> ---
>  hw/ppc/e500.c    |    3 +--
>  hw/ppce500_pci.c |    9 +++++++--
>  2 files changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/hw/ppc/e500.c b/hw/ppc/e500.c
> index d23f9b2..857d4dc 100644
> --- a/hw/ppc/e500.c
> +++ b/hw/ppc/e500.c
> @@ -52,7 +52,6 @@
>  #define MPC8544_PCI_REGS_BASE      (MPC8544_CCSRBAR_BASE + 0x8000ULL)
>  #define MPC8544_PCI_REGS_SIZE      0x1000ULL
>  #define MPC8544_PCI_IO             0xE1000000ULL
> -#define MPC8544_PCI_IOLEN          0x10000ULL
>  #define MPC8544_UTIL_BASE          (MPC8544_CCSRBAR_BASE +  
> 0xe0000ULL)
>  #define MPC8544_SPIN_BASE          0xEF000000ULL
> 
> @@ -511,7 +510,7 @@ void ppce500_init(PPCE500Params *params)
>      if (!pci_bus)
>          printf("couldn't create PCI controller!\n");
> 
> -    isa_mmio_init(MPC8544_PCI_IO, MPC8544_PCI_IOLEN);
> +    sysbus_mmio_map(sysbus_from_qdev(dev), 1, MPC8544_PCI_IO);
> 
>      if (pci_bus) {
>          /* Register network interfaces. */
> diff --git a/hw/ppce500_pci.c b/hw/ppce500_pci.c
> index 92b1dc0..27c6d7d 100644
> --- a/hw/ppce500_pci.c
> +++ b/hw/ppce500_pci.c
> @@ -31,6 +31,8 @@
>  #define PCIE500_ALL_SIZE      0x1000
>  #define PCIE500_REG_SIZE      (PCIE500_ALL_SIZE - PCIE500_REG_BASE)
> 
> +#define PCIE500_PCI_IOLEN     0x10000ULL

I don't think this belongs in ppce500_pci.c -- it's board config (or  
rather, a board-related default of something that is supposed to be  
software configurable), just like the base address.

Any chance of similarly constraining PCI MMIO to its proper window?

-Scott

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 21:14:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 21:14:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLKeG-0005c3-A3; Mon, 08 Oct 2012 21:14:00 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLJpF-0004fD-3N
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 20:21:17 +0000
X-Env-Sender: B07421@freescale.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1349727664!12498686!1
X-Originating-IP: [216.32.180.189]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22470 invoked from network); 8 Oct 2012 20:21:06 -0000
Received: from co1ehsobe006.messaging.microsoft.com (HELO
	co1outboundpool.messaging.microsoft.com) (216.32.180.189)
	by server-16.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	8 Oct 2012 20:21:06 -0000
Received: from mail139-co1-R.bigfish.com (10.243.78.229) by
	CO1EHSOBE003.bigfish.com (10.243.66.66) with Microsoft SMTP Server id
	14.1.225.23; Mon, 8 Oct 2012 20:21:03 +0000
Received: from mail139-co1 (localhost [127.0.0.1])	by
	mail139-co1-R.bigfish.com (Postfix) with ESMTP id 302564800A6;
	Mon,  8 Oct 2012 20:21:02 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:70.37.183.190; KIP:(null); UIP:(null); IPV:NLI;
	H:mail.freescale.net; RD:none; EFVD:NLI
X-SpamScore: -4
X-BigFish: VS-4(zzbb2dI98dI9371I1432Izz1202h1d1ah1d2ahzzz2dh2a8h668h839h944hd2bhf0ah107ah1288h12a5h12a9h12bdh137ah139eh13b6h1441h1155h)
Received: from mail139-co1 (localhost.localdomain [127.0.0.1]) by mail139-co1
	(MessageSwitch) id 1349727618313402_31959;
	Mon,  8 Oct 2012 20:20:18 +0000 (UTC)
Received: from CO1EHSMHS009.bigfish.com (unknown [10.243.78.248])	by
	mail139-co1.bigfish.com (Postfix) with ESMTP id 3EB27200045;
	Mon,  8 Oct 2012 20:20:18 +0000 (UTC)
Received: from mail.freescale.net (70.37.183.190) by CO1EHSMHS009.bigfish.com
	(10.243.66.19) with Microsoft SMTP Server (TLS) id 14.1.225.23;
	Mon, 8 Oct 2012 20:20:14 +0000
Received: from az84smr01.freescale.net (10.64.34.197) by
	039-SN1MMR1-001.039d.mgd.msft.net (10.84.1.13) with Microsoft SMTP
	Server (TLS) id 14.2.309.3; Mon, 8 Oct 2012 20:20:12 +0000
Received: from snotra ([10.214.86.163])	by az84smr01.freescale.net
	(8.14.3/8.14.0) with ESMTP id q98KK5Nu004057;
	Mon, 8 Oct 2012 13:20:05 -0700
Date: Mon, 8 Oct 2012 15:20:05 -0500
From: Scott Wood 
To: Alexander Graf 
References: <1349699033-6703-1-git-send-email-agraf@suse.de>
	<1349699033-6703-14-git-send-email-agraf@suse.de>
In-Reply-To: <1349699033-6703-14-git-send-email-agraf@suse.de> (from
	agraf@suse.de on Mon Oct  8 07:23:52 2012)
X-Mailer: Balsa 2.4.11
Message-ID: <1349727605.3721.2@snotra>
MIME-Version: 1.0
Content-Disposition: inline
X-OriginatorOrg: freescale.com
X-Mailman-Approved-At: Mon, 08 Oct 2012 21:13:59 +0000
Cc: Anthony Liguori , xen-devel@lists.xensource.com,
	Stefano Stabellini ,
	qemu-devel qemu-devel ,
	"qemu-ppc@nongnu.org List" ,
	Avi Kivity , malc ,
	David Gibson 
Subject: Re: [Xen-devel] [PATCH 13/14] PPC: e500: Map PIO space into core
	memory region
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="Flowed"; DelSp="Yes"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/08/2012 07:23:52 AM, Alexander Graf wrote:
> On PPC, we don't have PIO. So usually PIO space behind a PCI bridge is
> accessible via MMIO. Do this mapping explicitly by mapping the PIO  
> space
> of our PCI bus into a memory region that lives in memory space.
> 
> Signed-off-by: Alexander Graf 
> ---
>  hw/ppc/e500.c    |    3 +--
>  hw/ppce500_pci.c |    9 +++++++--
>  2 files changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/hw/ppc/e500.c b/hw/ppc/e500.c
> index d23f9b2..857d4dc 100644
> --- a/hw/ppc/e500.c
> +++ b/hw/ppc/e500.c
> @@ -52,7 +52,6 @@
>  #define MPC8544_PCI_REGS_BASE      (MPC8544_CCSRBAR_BASE + 0x8000ULL)
>  #define MPC8544_PCI_REGS_SIZE      0x1000ULL
>  #define MPC8544_PCI_IO             0xE1000000ULL
> -#define MPC8544_PCI_IOLEN          0x10000ULL
>  #define MPC8544_UTIL_BASE          (MPC8544_CCSRBAR_BASE +  
> 0xe0000ULL)
>  #define MPC8544_SPIN_BASE          0xEF000000ULL
> 
> @@ -511,7 +510,7 @@ void ppce500_init(PPCE500Params *params)
>      if (!pci_bus)
>          printf("couldn't create PCI controller!\n");
> 
> -    isa_mmio_init(MPC8544_PCI_IO, MPC8544_PCI_IOLEN);
> +    sysbus_mmio_map(sysbus_from_qdev(dev), 1, MPC8544_PCI_IO);
> 
>      if (pci_bus) {
>          /* Register network interfaces. */
> diff --git a/hw/ppce500_pci.c b/hw/ppce500_pci.c
> index 92b1dc0..27c6d7d 100644
> --- a/hw/ppce500_pci.c
> +++ b/hw/ppce500_pci.c
> @@ -31,6 +31,8 @@
>  #define PCIE500_ALL_SIZE      0x1000
>  #define PCIE500_REG_SIZE      (PCIE500_ALL_SIZE - PCIE500_REG_BASE)
> 
> +#define PCIE500_PCI_IOLEN     0x10000ULL

I don't think this belongs in ppce500_pci.c -- it's board config (or  
rather, a board-related default of something that is supposed to be  
software configurable), just like the base address.

Any chance of similarly constraining PCI MMIO to its proper window?

-Scott

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 21:30:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 21:30:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLKuA-00060W-CO; Mon, 08 Oct 2012 21:30:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLKu8-00060R-7w
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 21:30:24 +0000
Received: from [85.158.137.99:49841] by server-14.bemta-3.messagelabs.com id
	39/63-19528-FE543705; Mon, 08 Oct 2012 21:30:23 +0000
X-Env-Sender: B07421@freescale.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1349731820!15973569!1
X-Originating-IP: [216.32.180.184]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28400 invoked from network); 8 Oct 2012 21:30:22 -0000
Received: from co1ehsobe001.messaging.microsoft.com (HELO
	co1outboundpool.messaging.microsoft.com) (216.32.180.184)
	by server-7.tower-217.messagelabs.com with AES128-SHA encrypted SMTP;
	8 Oct 2012 21:30:22 -0000
Received: from mail7-co1-R.bigfish.com (10.243.78.231) by
	CO1EHSOBE003.bigfish.com (10.243.66.66) with Microsoft SMTP Server id
	14.1.225.23; Mon, 8 Oct 2012 21:30:20 +0000
Received: from mail7-co1 (localhost [127.0.0.1])	by mail7-co1-R.bigfish.com
	(Postfix) with ESMTP id 3059B80172;
	Mon,  8 Oct 2012 21:30:20 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:70.37.183.190; KIP:(null); UIP:(null); IPV:NLI;
	H:mail.freescale.net; RD:none; EFVD:NLI
X-SpamScore: -4
X-BigFish: VS-4(zzbb2dI98dI9371I1432Izz1202h1d1ah1d2ahzzz2dh2a8h668h839h944hd2bhf0ah107ah1288h12a5h12a9h12bdh137ah139eh13b6h1441h1155h)
Received: from mail7-co1 (localhost.localdomain [127.0.0.1]) by mail7-co1
	(MessageSwitch) id 1349731817239044_29303;
	Mon,  8 Oct 2012 21:30:17 +0000 (UTC)
Received: from CO1EHSMHS030.bigfish.com (unknown [10.243.78.225])	by
	mail7-co1.bigfish.com (Postfix) with ESMTP id 336EE180044;
	Mon,  8 Oct 2012 21:30:17 +0000 (UTC)
Received: from mail.freescale.net (70.37.183.190) by CO1EHSMHS030.bigfish.com
	(10.243.66.40) with Microsoft SMTP Server (TLS) id 14.1.225.23;
	Mon, 8 Oct 2012 21:30:16 +0000
Received: from az84smr01.freescale.net (10.64.34.197) by
	039-SN1MMR1-005.039d.mgd.msft.net (10.84.1.17) with Microsoft SMTP
	Server (TLS) id 14.2.309.3; Mon, 8 Oct 2012 21:30:15 +0000
Received: from snotra ([10.214.86.163])	by az84smr01.freescale.net
	(8.14.3/8.14.0) with ESMTP id q98LU4Ad031707;
	Mon, 8 Oct 2012 14:30:10 -0700
Date: Mon, 8 Oct 2012 16:30:04 -0500
From: Scott Wood 
To: Alexander Graf 
In-Reply-To: <11F10FDD-2CA3-4456-A77D-E45C249D8904@suse.de> (from
	agraf@suse.de on Mon Oct  8 16:08:31 2012)
X-Mailer: Balsa 2.4.11
Message-ID: <1349731804.3721.11@snotra>
MIME-Version: 1.0
Content-Disposition: inline
X-OriginatorOrg: freescale.com
Cc: Anthony Liguori , xen-devel@lists.xensource.com,
	Stefano Stabellini ,
	qemu-devel qemu-devel ,
	"qemu-ppc@nongnu.org List" ,
	Avi Kivity , malc ,
	David Gibson 
Subject: Re: [Xen-devel] [PATCH 13/14] PPC: e500: Map PIO space into core
	memory region
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="Flowed"; DelSp="Yes"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/08/2012 04:08:31 PM, Alexander Graf wrote:
> 
> On 08.10.2012, at 23:05, Scott Wood wrote:
> 
> > On 10/08/2012 03:48:42 PM, Alexander Graf wrote:
> >> On 08.10.2012, at 22:20, Scott Wood wrote:
> >> > On 10/08/2012 07:23:52 AM, Alexander Graf wrote:
> >> >> On PPC, we don't have PIO. So usually PIO space behind a PCI  
> bridge is
> >> >> accessible via MMIO. Do this mapping explicitly by mapping the  
> PIO space
> >> >> of our PCI bus into a memory region that lives in memory space.
> >> >> Signed-off-by: Alexander Graf 
> >> >> ---
> >> >> hw/ppc/e500.c    |    3 +--
> >> >> hw/ppce500_pci.c |    9 +++++++--
> >> >> 2 files changed, 8 insertions(+), 4 deletions(-)
> >> >> diff --git a/hw/ppc/e500.c b/hw/ppc/e500.c
> >> >> index d23f9b2..857d4dc 100644
> >> >> --- a/hw/ppc/e500.c
> >> >> +++ b/hw/ppc/e500.c
> >> >> @@ -52,7 +52,6 @@
> >> >> #define MPC8544_PCI_REGS_BASE      (MPC8544_CCSRBAR_BASE +  
> 0x8000ULL)
> >> >> #define MPC8544_PCI_REGS_SIZE      0x1000ULL
> >> >> #define MPC8544_PCI_IO             0xE1000000ULL
> >> >> -#define MPC8544_PCI_IOLEN          0x10000ULL
> >> >> #define MPC8544_UTIL_BASE          (MPC8544_CCSRBAR_BASE +  
> 0xe0000ULL)
> >> >> #define MPC8544_SPIN_BASE          0xEF000000ULL
> >> >> @@ -511,7 +510,7 @@ void ppce500_init(PPCE500Params *params)
> >> >>     if (!pci_bus)
> >> >>         printf("couldn't create PCI controller!\n");
> >> >> -    isa_mmio_init(MPC8544_PCI_IO, MPC8544_PCI_IOLEN);
> >> >> +    sysbus_mmio_map(sysbus_from_qdev(dev), 1, MPC8544_PCI_IO);
> >> >>     if (pci_bus) {
> >> >>         /* Register network interfaces. */
> >> >> diff --git a/hw/ppce500_pci.c b/hw/ppce500_pci.c
> >> >> index 92b1dc0..27c6d7d 100644
> >> >> --- a/hw/ppce500_pci.c
> >> >> +++ b/hw/ppce500_pci.c
> >> >> @@ -31,6 +31,8 @@
> >> >> #define PCIE500_ALL_SIZE      0x1000
> >> >> #define PCIE500_REG_SIZE      (PCIE500_ALL_SIZE -  
> PCIE500_REG_BASE)
> >> >> +#define PCIE500_PCI_IOLEN     0x10000ULL
> >> >
> >> > I don't think this belongs in ppce500_pci.c -- it's board config  
> (or rather, a board-related default of something that is supposed to  
> be software configurable), just like the base address.
> >> Actually this one is fixed in PCI. There are only 64k PIO ports.
> >
> > Are you sure about that?  Certainly that's the limit on x86 due to  
> the I/O instructions, and some (buggy?) PCI devices might have  
> trouble with larger I/O addresses, but I didn't think it was actually  
> illegal.  Some mpc85xx boards have default configs with larger I/O  
> windows (though probably not for any good reason).
> 
> What sense would it make to model an ioport range that exceeds what  
> x86 can do?

Well, as I said there's probably not a good reason for actually doing  
it, but if you want to more faithfully emulate the hardware...

That said, when I first complained I misread the constant and thought  
you were hardcoding 1M rather than 64K.

> >> > Any chance of similarly constraining PCI MMIO to its proper  
> window?
> >> We can't distinguish between inbound and outbound right now. If we  
> only need to restrict CPU -> PCI access, then yes.
> >
> > Better than nothing. :-)
> 
> If you can point me to the part of the spec that specifies how that  
> window should look like, I can cook up a patch. Or you can do it of  
> course ;).

Outbound windows are configured by PO*AR/PEXO*AR, and inbound by  
PI*AR/PEXI*AR (plus BAR0).  It's not a high priority, just curious what  
would be involved.

-Scott

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 21:30:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 21:30:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLKuA-00060W-CO; Mon, 08 Oct 2012 21:30:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLKu8-00060R-7w
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 21:30:24 +0000
Received: from [85.158.137.99:49841] by server-14.bemta-3.messagelabs.com id
	39/63-19528-FE543705; Mon, 08 Oct 2012 21:30:23 +0000
X-Env-Sender: B07421@freescale.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1349731820!15973569!1
X-Originating-IP: [216.32.180.184]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28400 invoked from network); 8 Oct 2012 21:30:22 -0000
Received: from co1ehsobe001.messaging.microsoft.com (HELO
	co1outboundpool.messaging.microsoft.com) (216.32.180.184)
	by server-7.tower-217.messagelabs.com with AES128-SHA encrypted SMTP;
	8 Oct 2012 21:30:22 -0000
Received: from mail7-co1-R.bigfish.com (10.243.78.231) by
	CO1EHSOBE003.bigfish.com (10.243.66.66) with Microsoft SMTP Server id
	14.1.225.23; Mon, 8 Oct 2012 21:30:20 +0000
Received: from mail7-co1 (localhost [127.0.0.1])	by mail7-co1-R.bigfish.com
	(Postfix) with ESMTP id 3059B80172;
	Mon,  8 Oct 2012 21:30:20 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:70.37.183.190; KIP:(null); UIP:(null); IPV:NLI;
	H:mail.freescale.net; RD:none; EFVD:NLI
X-SpamScore: -4
X-BigFish: VS-4(zzbb2dI98dI9371I1432Izz1202h1d1ah1d2ahzzz2dh2a8h668h839h944hd2bhf0ah107ah1288h12a5h12a9h12bdh137ah139eh13b6h1441h1155h)
Received: from mail7-co1 (localhost.localdomain [127.0.0.1]) by mail7-co1
	(MessageSwitch) id 1349731817239044_29303;
	Mon,  8 Oct 2012 21:30:17 +0000 (UTC)
Received: from CO1EHSMHS030.bigfish.com (unknown [10.243.78.225])	by
	mail7-co1.bigfish.com (Postfix) with ESMTP id 336EE180044;
	Mon,  8 Oct 2012 21:30:17 +0000 (UTC)
Received: from mail.freescale.net (70.37.183.190) by CO1EHSMHS030.bigfish.com
	(10.243.66.40) with Microsoft SMTP Server (TLS) id 14.1.225.23;
	Mon, 8 Oct 2012 21:30:16 +0000
Received: from az84smr01.freescale.net (10.64.34.197) by
	039-SN1MMR1-005.039d.mgd.msft.net (10.84.1.17) with Microsoft SMTP
	Server (TLS) id 14.2.309.3; Mon, 8 Oct 2012 21:30:15 +0000
Received: from snotra ([10.214.86.163])	by az84smr01.freescale.net
	(8.14.3/8.14.0) with ESMTP id q98LU4Ad031707;
	Mon, 8 Oct 2012 14:30:10 -0700
Date: Mon, 8 Oct 2012 16:30:04 -0500
From: Scott Wood 
To: Alexander Graf 
In-Reply-To: <11F10FDD-2CA3-4456-A77D-E45C249D8904@suse.de> (from
	agraf@suse.de on Mon Oct  8 16:08:31 2012)
X-Mailer: Balsa 2.4.11
Message-ID: <1349731804.3721.11@snotra>
MIME-Version: 1.0
Content-Disposition: inline
X-OriginatorOrg: freescale.com
Cc: Anthony Liguori , xen-devel@lists.xensource.com,
	Stefano Stabellini ,
	qemu-devel qemu-devel ,
	"qemu-ppc@nongnu.org List" ,
	Avi Kivity , malc ,
	David Gibson 
Subject: Re: [Xen-devel] [PATCH 13/14] PPC: e500: Map PIO space into core
	memory region
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="Flowed"; DelSp="Yes"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/08/2012 04:08:31 PM, Alexander Graf wrote:
> 
> On 08.10.2012, at 23:05, Scott Wood wrote:
> 
> > On 10/08/2012 03:48:42 PM, Alexander Graf wrote:
> >> On 08.10.2012, at 22:20, Scott Wood wrote:
> >> > On 10/08/2012 07:23:52 AM, Alexander Graf wrote:
> >> >> On PPC, we don't have PIO. So usually PIO space behind a PCI  
> bridge is
> >> >> accessible via MMIO. Do this mapping explicitly by mapping the  
> PIO space
> >> >> of our PCI bus into a memory region that lives in memory space.
> >> >> Signed-off-by: Alexander Graf 
> >> >> ---
> >> >> hw/ppc/e500.c    |    3 +--
> >> >> hw/ppce500_pci.c |    9 +++++++--
> >> >> 2 files changed, 8 insertions(+), 4 deletions(-)
> >> >> diff --git a/hw/ppc/e500.c b/hw/ppc/e500.c
> >> >> index d23f9b2..857d4dc 100644
> >> >> --- a/hw/ppc/e500.c
> >> >> +++ b/hw/ppc/e500.c
> >> >> @@ -52,7 +52,6 @@
> >> >> #define MPC8544_PCI_REGS_BASE      (MPC8544_CCSRBAR_BASE +  
> 0x8000ULL)
> >> >> #define MPC8544_PCI_REGS_SIZE      0x1000ULL
> >> >> #define MPC8544_PCI_IO             0xE1000000ULL
> >> >> -#define MPC8544_PCI_IOLEN          0x10000ULL
> >> >> #define MPC8544_UTIL_BASE          (MPC8544_CCSRBAR_BASE +  
> 0xe0000ULL)
> >> >> #define MPC8544_SPIN_BASE          0xEF000000ULL
> >> >> @@ -511,7 +510,7 @@ void ppce500_init(PPCE500Params *params)
> >> >>     if (!pci_bus)
> >> >>         printf("couldn't create PCI controller!\n");
> >> >> -    isa_mmio_init(MPC8544_PCI_IO, MPC8544_PCI_IOLEN);
> >> >> +    sysbus_mmio_map(sysbus_from_qdev(dev), 1, MPC8544_PCI_IO);
> >> >>     if (pci_bus) {
> >> >>         /* Register network interfaces. */
> >> >> diff --git a/hw/ppce500_pci.c b/hw/ppce500_pci.c
> >> >> index 92b1dc0..27c6d7d 100644
> >> >> --- a/hw/ppce500_pci.c
> >> >> +++ b/hw/ppce500_pci.c
> >> >> @@ -31,6 +31,8 @@
> >> >> #define PCIE500_ALL_SIZE      0x1000
> >> >> #define PCIE500_REG_SIZE      (PCIE500_ALL_SIZE -  
> PCIE500_REG_BASE)
> >> >> +#define PCIE500_PCI_IOLEN     0x10000ULL
> >> >
> >> > I don't think this belongs in ppce500_pci.c -- it's board config  
> (or rather, a board-related default of something that is supposed to  
> be software configurable), just like the base address.
> >> Actually this one is fixed in PCI. There are only 64k PIO ports.
> >
> > Are you sure about that?  Certainly that's the limit on x86 due to  
> the I/O instructions, and some (buggy?) PCI devices might have  
> trouble with larger I/O addresses, but I didn't think it was actually  
> illegal.  Some mpc85xx boards have default configs with larger I/O  
> windows (though probably not for any good reason).
> 
> What sense would it make to model an ioport range that exceeds what  
> x86 can do?

Well, as I said there's probably not a good reason for actually doing  
it, but if you want to more faithfully emulate the hardware...

That said, when I first complained I misread the constant and thought  
you were hardcoding 1M rather than 64K.

> >> > Any chance of similarly constraining PCI MMIO to its proper  
> window?
> >> We can't distinguish between inbound and outbound right now. If we  
> only need to restrict CPU -> PCI access, then yes.
> >
> > Better than nothing. :-)
> 
> If you can point me to the part of the spec that specifies how that  
> window should look like, I can cook up a patch. Or you can do it of  
> course ;).

Outbound windows are configured by PO*AR/PEXO*AR, and inbound by  
PI*AR/PEXI*AR (plus BAR0).  It's not a high priority, just curious what  
would be involved.

-Scott

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 22:28:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 22:28:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLLnf-0006J3-Sn; Mon, 08 Oct 2012 22:27:47 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLLne-0006Iv-T7
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 22:27:47 +0000
X-Env-Sender: george.shuklin@gmail.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1349735260!4621317!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3944 invoked from network); 8 Oct 2012 22:27:41 -0000
Received: from mail-la0-f43.google.com (HELO mail-la0-f43.google.com)
	(209.85.215.43)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 22:27:41 -0000
Received: by mail-la0-f43.google.com with SMTP id i5so3018290lah.30
	for ;
	Mon, 08 Oct 2012 15:27:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:subject
	:content-type:content-transfer-encoding;
	bh=h6/bU86Z85pBey5jP391ETNxqPBaX0iY0k6Qeztio8g=;
	b=IsC2cio4vhc+rveOkLGbOvi3Yi2gxnqKbEmP268lnI4QG7ms6G2ArWk/uixu0TytyN
	oEzaDVho7ImNvCadZcHJPwh99kYmluE+TieBg+IYyJJGYI7aZvSD2vMsmY1l9AeJTnsN
	PZ4v5n0ZYovAKFeGjc3lFEwIsT0QTdd9JiYnUjKLk7ZCpQ7WRqCQ7wxDursXkWwIDAtp
	bmNIJpcp2zZAih8YlsRKgK7RC7Vhnow/QzVHpxgEpJtwmpWQ0mK9twH9Fgymov4pSnef
	3MfhtbGI/bzs71qRbDZ2xed+CpO/Mk10Fz14ruuBEY/4ISH/PwAihXjJPjMrgVkJirWi
	SL3g==
Received: by 10.152.135.41 with SMTP id pp9mr14941177lab.7.1349735260121;
	Mon, 08 Oct 2012 15:27:40 -0700 (PDT)
Received: from home.desunote.ru ([2a00:11d8:1201:0:962b:18:e716:fb97])
	by mx.google.com with ESMTPS id j9sm1128675lbk.17.2012.10.08.15.27.38
	(version=SSLv3 cipher=OTHER); Mon, 08 Oct 2012 15:27:39 -0700 (PDT)
Message-ID: <50735360.2040502@gmail.com>
Date: Tue, 09 Oct 2012 02:27:44 +0400
From: George Shuklin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.7) Gecko/20120922 Icedove/10.0.7
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] event channel internals
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Good day.

I'm trying to dig inside xen, but I still not really understand all 
stuff about event channels. How exactly domain-to-domain communication 
looks?

Thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 22:28:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 22:28:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLLnf-0006J3-Sn; Mon, 08 Oct 2012 22:27:47 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLLne-0006Iv-T7
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 22:27:47 +0000
X-Env-Sender: george.shuklin@gmail.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1349735260!4621317!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3944 invoked from network); 8 Oct 2012 22:27:41 -0000
Received: from mail-la0-f43.google.com (HELO mail-la0-f43.google.com)
	(209.85.215.43)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 22:27:41 -0000
Received: by mail-la0-f43.google.com with SMTP id i5so3018290lah.30
	for ;
	Mon, 08 Oct 2012 15:27:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:subject
	:content-type:content-transfer-encoding;
	bh=h6/bU86Z85pBey5jP391ETNxqPBaX0iY0k6Qeztio8g=;
	b=IsC2cio4vhc+rveOkLGbOvi3Yi2gxnqKbEmP268lnI4QG7ms6G2ArWk/uixu0TytyN
	oEzaDVho7ImNvCadZcHJPwh99kYmluE+TieBg+IYyJJGYI7aZvSD2vMsmY1l9AeJTnsN
	PZ4v5n0ZYovAKFeGjc3lFEwIsT0QTdd9JiYnUjKLk7ZCpQ7WRqCQ7wxDursXkWwIDAtp
	bmNIJpcp2zZAih8YlsRKgK7RC7Vhnow/QzVHpxgEpJtwmpWQ0mK9twH9Fgymov4pSnef
	3MfhtbGI/bzs71qRbDZ2xed+CpO/Mk10Fz14ruuBEY/4ISH/PwAihXjJPjMrgVkJirWi
	SL3g==
Received: by 10.152.135.41 with SMTP id pp9mr14941177lab.7.1349735260121;
	Mon, 08 Oct 2012 15:27:40 -0700 (PDT)
Received: from home.desunote.ru ([2a00:11d8:1201:0:962b:18:e716:fb97])
	by mx.google.com with ESMTPS id j9sm1128675lbk.17.2012.10.08.15.27.38
	(version=SSLv3 cipher=OTHER); Mon, 08 Oct 2012 15:27:39 -0700 (PDT)
Message-ID: <50735360.2040502@gmail.com>
Date: Tue, 09 Oct 2012 02:27:44 +0400
From: George Shuklin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.7) Gecko/20120922 Icedove/10.0.7
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] event channel internals
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Good day.

I'm trying to dig inside xen, but I still not really understand all 
stuff about event channels. How exactly domain-to-domain communication 
looks?

Thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 22:34:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 22:34:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLLte-0006U3-T6; Mon, 08 Oct 2012 22:33:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLLtd-0006Tw-KZ
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 22:33:57 +0000
Received: from [85.158.139.211:53966] by server-12.bemta-5.messagelabs.com id
	9B/AB-19095-4D453705; Mon, 08 Oct 2012 22:33:56 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-13.tower-206.messagelabs.com!1349735635!17570480!1
X-Originating-IP: [140.77.166.68]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2090 invoked from network); 8 Oct 2012 22:33:56 -0000
Received: from toccata.ens-lyon.fr (HELO toccata.ens-lyon.org) (140.77.166.68)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Oct 2012 22:33:56 -0000
Received: from localhost (localhost [127.0.0.1])
	by toccata.ens-lyon.org (Postfix) with ESMTP id D6AD1840A7;
	Tue,  9 Oct 2012 00:33:53 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at toccata.ens-lyon.org
Received: from toccata.ens-lyon.org ([127.0.0.1])
	by localhost (toccata.ens-lyon.org [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 9vGMsdSHU2Zz; Tue,  9 Oct 2012 00:33:53 +0200 (CEST)
Received: from type.ipv6 (youpi.is-a-geek.org [80.67.176.89])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by toccata.ens-lyon.org (Postfix) with ESMTPSA id 862B38409C;
	Tue,  9 Oct 2012 00:33:53 +0200 (CEST)
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from )
	id 1TLLtY-0003i8-1g; Tue, 09 Oct 2012 00:33:52 +0200
Date: Tue, 9 Oct 2012 00:33:52 +0200
From: Samuel Thibault 
To: Matthew Fioravante 
Message-ID: <20121008223352.GX5681@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault ,
	Matthew Fioravante ,
	xen-devel@lists.xen.org, ian.campbell@citrix.com
References: <1349723202-14608-1-git-send-email-matthew.fioravante@jhuapl.edu>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1349723202-14608-1-git-send-email-matthew.fioravante@jhuapl.edu>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH vtpm v3 06/12] add select definition to
 sys/time.h when HAVE_LIBC is defined
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Matthew Fioravante, le Mon 08 Oct 2012 15:06:41 -0400, a =E9crit :
> This patch adds the select function to sys/time.h when HAVE_LIBC is
> defined, which is according to standard (see the select() manpage).
> It also removes a redudant lwip include from posix/sys/select.h.
> =

> Signed-off-by: Matthew Fioravante 

Acked-by: Samuel Thibault 

> diff --git a/extras/mini-os/include/posix/sys/select.h b/extras/mini-os/i=
nclude/posix/sys/select.h
> index a9337be..5132c51 100644
> --- a/extras/mini-os/include/posix/sys/select.h
> +++ b/extras/mini-os/include/posix/sys/select.h
> @@ -2,7 +2,6 @@
>  #define _POSIX_SELECT_H
>  =

>  #include 
> -#include 
>  int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfd=
s, struct timeval *timeout);
>  =

>  #endif /* _POSIX_SELECT_H */
> diff --git a/extras/mini-os/include/sys/time.h b/extras/mini-os/include/s=
ys/time.h
> index d6623a4..3be3653 100644
> --- a/extras/mini-os/include/sys/time.h
> +++ b/extras/mini-os/include/sys/time.h
> @@ -22,6 +22,7 @@
>  =

>  #ifdef HAVE_LIBC
>  #include_next 
> +
>  #else
>  struct timespec {
>      time_t      tv_sec;
> @@ -37,6 +38,10 @@ struct timeval {
>  };
>  =

>  int      gettimeofday(struct timeval *tv, void *tz);
> +
> +#endif
> +#ifdef HAVE_LIBC
> +#include 
>  #endif
>  =

>  #endif /* _MINIOS_SYS_TIME_H_ */
> -- =

> 1.7.4.4
> =


-- =

Samuel
 ben oui ce serait idiot, mais osb
  -+- m'en fous de faire un truc d=E9bile ! -+-

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 22:34:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 22:34:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLLte-0006U3-T6; Mon, 08 Oct 2012 22:33:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLLtd-0006Tw-KZ
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 22:33:57 +0000
Received: from [85.158.139.211:53966] by server-12.bemta-5.messagelabs.com id
	9B/AB-19095-4D453705; Mon, 08 Oct 2012 22:33:56 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-13.tower-206.messagelabs.com!1349735635!17570480!1
X-Originating-IP: [140.77.166.68]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2090 invoked from network); 8 Oct 2012 22:33:56 -0000
Received: from toccata.ens-lyon.fr (HELO toccata.ens-lyon.org) (140.77.166.68)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Oct 2012 22:33:56 -0000
Received: from localhost (localhost [127.0.0.1])
	by toccata.ens-lyon.org (Postfix) with ESMTP id D6AD1840A7;
	Tue,  9 Oct 2012 00:33:53 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at toccata.ens-lyon.org
Received: from toccata.ens-lyon.org ([127.0.0.1])
	by localhost (toccata.ens-lyon.org [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 9vGMsdSHU2Zz; Tue,  9 Oct 2012 00:33:53 +0200 (CEST)
Received: from type.ipv6 (youpi.is-a-geek.org [80.67.176.89])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by toccata.ens-lyon.org (Postfix) with ESMTPSA id 862B38409C;
	Tue,  9 Oct 2012 00:33:53 +0200 (CEST)
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from )
	id 1TLLtY-0003i8-1g; Tue, 09 Oct 2012 00:33:52 +0200
Date: Tue, 9 Oct 2012 00:33:52 +0200
From: Samuel Thibault 
To: Matthew Fioravante 
Message-ID: <20121008223352.GX5681@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault ,
	Matthew Fioravante ,
	xen-devel@lists.xen.org, ian.campbell@citrix.com
References: <1349723202-14608-1-git-send-email-matthew.fioravante@jhuapl.edu>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1349723202-14608-1-git-send-email-matthew.fioravante@jhuapl.edu>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH vtpm v3 06/12] add select definition to
 sys/time.h when HAVE_LIBC is defined
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Matthew Fioravante, le Mon 08 Oct 2012 15:06:41 -0400, a =E9crit :
> This patch adds the select function to sys/time.h when HAVE_LIBC is
> defined, which is according to standard (see the select() manpage).
> It also removes a redudant lwip include from posix/sys/select.h.
> =

> Signed-off-by: Matthew Fioravante 

Acked-by: Samuel Thibault 

> diff --git a/extras/mini-os/include/posix/sys/select.h b/extras/mini-os/i=
nclude/posix/sys/select.h
> index a9337be..5132c51 100644
> --- a/extras/mini-os/include/posix/sys/select.h
> +++ b/extras/mini-os/include/posix/sys/select.h
> @@ -2,7 +2,6 @@
>  #define _POSIX_SELECT_H
>  =

>  #include 
> -#include 
>  int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfd=
s, struct timeval *timeout);
>  =

>  #endif /* _POSIX_SELECT_H */
> diff --git a/extras/mini-os/include/sys/time.h b/extras/mini-os/include/s=
ys/time.h
> index d6623a4..3be3653 100644
> --- a/extras/mini-os/include/sys/time.h
> +++ b/extras/mini-os/include/sys/time.h
> @@ -22,6 +22,7 @@
>  =

>  #ifdef HAVE_LIBC
>  #include_next 
> +
>  #else
>  struct timespec {
>      time_t      tv_sec;
> @@ -37,6 +38,10 @@ struct timeval {
>  };
>  =

>  int      gettimeofday(struct timeval *tv, void *tz);
> +
> +#endif
> +#ifdef HAVE_LIBC
> +#include 
>  #endif
>  =

>  #endif /* _MINIOS_SYS_TIME_H_ */
> -- =

> 1.7.4.4
> =


-- =

Samuel
 ben oui ce serait idiot, mais osb
  -+- m'en fous de faire un truc d=E9bile ! -+-

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 22:35:33 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 22:35:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLLuo-0006YT-CC; Mon, 08 Oct 2012 22:35:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLLum-0006YE-5y
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 22:35:08 +0000
Received: from [85.158.138.51:42218] by server-7.bemta-3.messagelabs.com id
	65/94-15765-B1553705; Mon, 08 Oct 2012 22:35:07 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-15.tower-174.messagelabs.com!1349735705!31804181!1
X-Originating-IP: [140.77.166.68]
X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5390 invoked from network); 8 Oct 2012 22:35:05 -0000
Received: from toccata.ens-lyon.fr (HELO toccata.ens-lyon.org) (140.77.166.68)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Oct 2012 22:35:05 -0000
Received: from localhost (localhost [127.0.0.1])
	by toccata.ens-lyon.org (Postfix) with ESMTP id DF92A840A7;
	Tue,  9 Oct 2012 00:35:04 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at toccata.ens-lyon.org
Received: from toccata.ens-lyon.org ([127.0.0.1])
	by localhost (toccata.ens-lyon.org [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id EtcuAhtYVjr7; Tue,  9 Oct 2012 00:35:04 +0200 (CEST)
Received: from type.ipv6 (youpi.is-a-geek.org [80.67.176.89])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by toccata.ens-lyon.org (Postfix) with ESMTPSA id 2DAFB8409C;
	Tue,  9 Oct 2012 00:35:04 +0200 (CEST)
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from )
	id 1TLLug-0003in-OW; Tue, 09 Oct 2012 00:35:02 +0200
Date: Tue, 9 Oct 2012 00:35:02 +0200
From: Samuel Thibault 
To: Matthew Fioravante 
Message-ID: <20121008223502.GY5681@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault ,
	Matthew Fioravante ,
	xen-devel@lists.xen.org, ian.campbell@citrix.com
References: <1349723202-14608-1-git-send-email-matthew.fioravante@jhuapl.edu>
	<1349723202-14608-2-git-send-email-matthew.fioravante@jhuapl.edu>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1349723202-14608-2-git-send-email-matthew.fioravante@jhuapl.edu>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH vtpm v3 02/12] add posix io for blkfront
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Matthew Fioravante, le Mon 08 Oct 2012 15:06:42 -0400, a =E9crit :
> This patch adds posix io support (read,write,lseek) to block devices
> using blkfront.
> =

> Signed-off-by: Matthew Fioravante 
> Acked-by: Samuel Thibault 

Confirmed on this version.

> diff --git a/extras/mini-os/blkfront.c b/extras/mini-os/blkfront.c
> index 74b8b26..f4283a9 100644
> --- a/extras/mini-os/blkfront.c
> +++ b/extras/mini-os/blkfront.c
> @@ -392,6 +392,7 @@ void blkfront_aio(struct blkfront_aiocb *aiocbp, int =
write)
>  static void blkfront_aio_cb(struct blkfront_aiocb *aiocbp, int ret)
>  {
>      aiocbp->data =3D (void*) 1;
> +    aiocbp->aio_cb =3D NULL;
>  }
>  =

>  void blkfront_io(struct blkfront_aiocb *aiocbp, int write)
> @@ -547,9 +548,177 @@ moretodo:
>  #ifdef HAVE_LIBC
>  int blkfront_open(struct blkfront_dev *dev)
>  {
> +    /* Silently prevent multiple opens */
> +    if(dev->fd !=3D -1) {
> +       return dev->fd;
> +    }
>      dev->fd =3D alloc_fd(FTYPE_BLK);
>      printk("blk_open(%s) -> %d\n", dev->nodename, dev->fd);
>      files[dev->fd].blk.dev =3D dev;
> +    files[dev->fd].blk.offset =3D 0;
>      return dev->fd;
>  }
> +
> +int blkfront_posix_rwop(int fd, uint8_t* buf, size_t count, int write)
> +{
> +   struct blkfront_dev* dev =3D files[fd].blk.dev;
> +   off_t offset =3D files[fd].blk.offset;
> +   struct blkfront_aiocb aiocb;
> +   unsigned long long disksize =3D dev->info.sectors * dev->info.sector_=
size;
> +   unsigned int blocksize =3D dev->info.sector_size;
> +
> +   int blknum;
> +   int blkoff;
> +   size_t bytes;
> +   int rc =3D 0;
> +   int alignedbuf =3D 0;
> +   uint8_t* copybuf =3D NULL;
> +
> +   /* RW 0 bytes is just a NOP */
> +   if(count =3D=3D 0) {
> +      return 0;
> +   }
> +   /* Check for NULL buffer */
> +   if( buf =3D=3D NULL ) {
> +      errno =3D EFAULT;
> +      return -1;
> +   }
> +
> +   /* Write mode checks */
> +   if(write) {
> +      /*Make sure we have write permission */
> +      if(dev->info.info & VDISK_READONLY =

> +            || (dev->info.mode !=3D O_RDWR  && dev->info.mode !=3D  O_WR=
ONLY)) {
> +         errno =3D EACCES;
> +         return -1;
> +      }
> +      /*Make sure disk is big enough for this write */
> +      if(offset + count > disksize) {
> +         errno =3D ENOSPC;
> +         return -1;
> +      }
> +   }
> +   /* Read mode checks */
> +   else
> +   {
> +      /* Reading past the disk? Just return 0 */
> +      if(offset >=3D disksize) {
> +         return 0;
> +      }
> +
> +      /*If the requested read is bigger than the disk, just
> +       * read as much as we can until the end */
> +      if(offset + count > disksize) {
> +         count =3D disksize - offset;
> +      }
> +   }
> +   /* Determine which block to start at and at which offset inside of it=
 */
> +   blknum =3D offset / blocksize;
> +   blkoff =3D offset % blocksize;
> +
> +   /* Optimization: We need to check if buf is aligned to the sector siz=
e.
> +    * This is somewhat tricky code. We have to add the blocksize - block=
 offset
> +    * because the first block may be a partial block and then for every =
subsequent
> +    * block rw the buffer will be offset.*/
> +   if(!((uintptr_t) (buf +(blocksize -  blkoff)) & (dev->info.sector_siz=
e-1))) {
> +      alignedbuf =3D 1;
> +   }
> +
> +   /* Setup aiocb block object */
> +   aiocb.aio_dev =3D dev;
> +   aiocb.aio_offset =3D blknum * blocksize;
> +   aiocb.aio_cb =3D NULL;
> +   aiocb.data =3D NULL;
> +
> +   /* If our buffer is unaligned or its aligned but we will need to rw a=
 partial block
> +    * then a copy will have to be done */
> +   if(!alignedbuf || blkoff !=3D 0 || count % blocksize !=3D 0) {
> +      copybuf =3D _xmalloc(blocksize, dev->info.sector_size);
> +   }
> +
> +   rc =3D count;
> +   while(count > 0) {
> +      /* determine how many bytes to read/write from/to the current bloc=
k buffer */
> +      if(!alignedbuf || blkoff !=3D 0 || count < blocksize) {
> +         /* This is the case for unaligned R/W or partial block */
> +         bytes =3D count < blocksize - blkoff ? count : blocksize - blko=
ff;
> +         aiocb.aio_nbytes =3D blocksize;
> +      } else {
> +         /* We can optimize further if buffer is page aligned */
> +         int not_page_aligned =3D 0;
> +         if(((uintptr_t)buf) & (PAGE_SIZE -1)) {
> +            not_page_aligned =3D 1;
> +         }
> +
> +         /* For an aligned R/W we can read up to the maximum transfer si=
ze */
> +         bytes =3D count > (BLKIF_MAX_SEGMENTS_PER_REQUEST-not_page_alig=
ned)*PAGE_SIZE =

> +            ? (BLKIF_MAX_SEGMENTS_PER_REQUEST-not_page_aligned)*PAGE_SIZE
> +            : count & ~(blocksize -1);
> +         aiocb.aio_nbytes =3D bytes;
> +      }
> +
> +      /* read operation */
> +      if(!write) {
> +         if (alignedbuf && bytes >=3D blocksize) {
> +            /* If aligned and were reading a whole block, just read righ=
t into buf */
> +            aiocb.aio_buf =3D buf;
> +            blkfront_read(&aiocb);
> +         } else {
> +            /* If not then we have to do a copy */
> +            aiocb.aio_buf =3D copybuf;
> +            blkfront_read(&aiocb);
> +            memcpy(buf, ©buf[blkoff], bytes);
> +         }
> +      }
> +      /* Write operation */
> +      else {
> +         if(alignedbuf && bytes >=3D blocksize) {
> +            /* If aligned and were writing a whole block, just write dir=
ectly from buf */
> +            aiocb.aio_buf =3D buf;
> +            blkfront_write(&aiocb);
> +         } else {
> +            /* If not then we have to do a copy. */
> +            aiocb.aio_buf =3D copybuf;
> +            /* If we're writing a partial block, we need to read the cur=
rent contents first
> +             * so we don't overwrite the extra bits with garbage */
> +            if(blkoff !=3D 0 || bytes < blocksize) {
> +               blkfront_read(&aiocb);
> +            }
> +            memcpy(©buf[blkoff], buf, bytes);
> +            blkfront_write(&aiocb);
> +         }
> +      }
> +      /* Will start at beginning of all remaining blocks */
> +      blkoff =3D 0;
> +
> +      /* Increment counters and continue */
> +      count -=3D bytes;
> +      buf +=3D bytes;
> +      if(bytes < blocksize) {
> +         //At minimum we read one block
> +         aiocb.aio_offset +=3D blocksize;
> +      } else {
> +         //If we read more than a block, was a multiple of blocksize
> +         aiocb.aio_offset +=3D bytes;
> +      }
> +   }
> +
> +   free(copybuf);
> +   files[fd].blk.offset +=3D rc;
> +   return rc;
> +
> +}
> +
> +int blkfront_posix_fstat(int fd, struct stat* buf)
> +{
> +   struct blkfront_dev* dev =3D files[fd].blk.dev;
> +
> +   buf->st_mode =3D dev->info.mode;
> +   buf->st_uid =3D 0;
> +   buf->st_gid =3D 0;
> +   buf->st_size =3D dev->info.sectors * dev->info.sector_size;
> +   buf->st_atime =3D buf->st_mtime =3D buf->st_ctime =3D time(NULL);
> +
> +   return 0;
> +}
>  #endif
> diff --git a/extras/mini-os/include/blkfront.h b/extras/mini-os/include/b=
lkfront.h
> index 724137e..3528af9 100644
> --- a/extras/mini-os/include/blkfront.h
> +++ b/extras/mini-os/include/blkfront.h
> @@ -28,7 +28,17 @@ struct blkfront_info
>  };
>  struct blkfront_dev *init_blkfront(char *nodename, struct blkfront_info =
*info);
>  #ifdef HAVE_LIBC
> +#include 
> +/* POSIX IO functions:
> + * use blkfront_open() to get a file descriptor to the block device
> + * Don't use the other blkfront posix functions here directly, instead u=
se
> + * read(), write(), lseek() and fstat() on the file descriptor
> + */
>  int blkfront_open(struct blkfront_dev *dev);
> +int blkfront_posix_rwop(int fd, uint8_t* buf, size_t count, int write);
> +#define blkfront_posix_write(fd, buf, count) blkfront_posix_rwop(fd, (ui=
nt8_t*)buf, count, 1)
> +#define blkfront_posix_read(fd, buf, count) blkfront_posix_rwop(fd, (uin=
t8_t*)buf, count, 0)
> +int blkfront_posix_fstat(int fd, struct stat* buf);
>  #endif
>  void blkfront_aio(struct blkfront_aiocb *aiocbp, int write);
>  #define blkfront_aio_read(aiocbp) blkfront_aio(aiocbp, 0)
> diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h
> index 1af2717..d4641b6 100644
> --- a/extras/mini-os/include/lib.h
> +++ b/extras/mini-os/include/lib.h
> @@ -174,6 +174,7 @@ extern struct file {
>  	} tap;
>  	struct {
>  	    struct blkfront_dev *dev;
> +            off_t offset;
>  	} blk;
>  	struct {
>  	    struct kbdfront_dev *dev;
> diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
> index a7d35d6..7ddbbf8 100644
> --- a/extras/mini-os/lib/sys.c
> +++ b/extras/mini-os/lib/sys.c
> @@ -289,6 +289,11 @@ int read(int fd, void *buf, size_t nbytes)
>  	    return ret * sizeof(union xenfb_in_event);
>          }
>  #endif
> +#ifdef CONFIG_BLKFRONT
> +        case FTYPE_BLK: {
> +	    return blkfront_posix_read(fd, buf, nbytes);
> +        }
> +#endif
>  	default:
>  	    break;
>      }
> @@ -321,6 +326,10 @@ int write(int fd, const void *buf, size_t nbytes)
>  	    netfront_xmit(files[fd].tap.dev, (void*) buf, nbytes);
>  	    return nbytes;
>  #endif
> +#ifdef CONFIG_BLKFRONT
> +	case FTYPE_BLK:
> +	    return blkfront_posix_write(fd, buf, nbytes);
> +#endif
>  	default:
>  	    break;
>      }
> @@ -331,8 +340,37 @@ int write(int fd, const void *buf, size_t nbytes)
>  =

>  off_t lseek(int fd, off_t offset, int whence)
>  {
> -    errno =3D ESPIPE;
> -    return (off_t) -1;
> +    switch(files[fd].type) {
> +#ifdef CONFIG_BLKFRONT
> +       case FTYPE_BLK:
> +	  switch (whence) {
> +	     case SEEK_SET:
> +		files[fd].file.offset =3D offset;
> +		break;
> +	     case SEEK_CUR:
> +		files[fd].file.offset +=3D offset;
> +		break;
> +	     case SEEK_END:
> +		{
> +		   struct stat st;
> +		   int ret;
> +		   ret =3D fstat(fd, &st);
> +		   if (ret)
> +		      return -1;
> +		   files[fd].file.offset =3D st.st_size + offset;
> +		   break;
> +		}
> +	     default:
> +		errno =3D EINVAL;
> +		return -1;
> +	  }
> +	  return files[fd].file.offset;
> +	  break;
> +#endif
> +       default: /* Not implemented on this FTYPE */
> +	  errno =3D ESPIPE;
> +	  return (off_t) -1;
> +    }
>  }
>  =

>  int fsync(int fd) {
> @@ -445,6 +483,10 @@ int fstat(int fd, struct stat *buf)
>  	    buf->st_ctime =3D time(NULL);
>  	    return 0;
>  	}
> +#ifdef CONFIG_BLKFRONT
> +	case FTYPE_BLK:
> +	   return blkfront_posix_fstat(fd, buf);
> +#endif
>  	default:
>  	    break;
>      }
> -- =

> 1.7.4.4
> =


-- =

Samuel
 PS> Salut ! J'ai un sujet de philo =E0 vous soumettre : "Suffit-il
 PS> d'observer pour conna=EEtre" Id=E9es + plan Mer=E7i
 Oui, ya qu'a t'observer pour conna=EEtre le fait que tu es une feignasse.
 -+- FF in: Guide du Neuneu d'Usenet - Neuneu fait de la philo -+-

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 22:35:33 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 22:35:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLLuo-0006YT-CC; Mon, 08 Oct 2012 22:35:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLLum-0006YE-5y
	for xen-devel@lists.xen.org; Mon, 08 Oct 2012 22:35:08 +0000
Received: from [85.158.138.51:42218] by server-7.bemta-3.messagelabs.com id
	65/94-15765-B1553705; Mon, 08 Oct 2012 22:35:07 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-15.tower-174.messagelabs.com!1349735705!31804181!1
X-Originating-IP: [140.77.166.68]
X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5390 invoked from network); 8 Oct 2012 22:35:05 -0000
Received: from toccata.ens-lyon.fr (HELO toccata.ens-lyon.org) (140.77.166.68)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 8 Oct 2012 22:35:05 -0000
Received: from localhost (localhost [127.0.0.1])
	by toccata.ens-lyon.org (Postfix) with ESMTP id DF92A840A7;
	Tue,  9 Oct 2012 00:35:04 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at toccata.ens-lyon.org
Received: from toccata.ens-lyon.org ([127.0.0.1])
	by localhost (toccata.ens-lyon.org [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id EtcuAhtYVjr7; Tue,  9 Oct 2012 00:35:04 +0200 (CEST)
Received: from type.ipv6 (youpi.is-a-geek.org [80.67.176.89])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by toccata.ens-lyon.org (Postfix) with ESMTPSA id 2DAFB8409C;
	Tue,  9 Oct 2012 00:35:04 +0200 (CEST)
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from )
	id 1TLLug-0003in-OW; Tue, 09 Oct 2012 00:35:02 +0200
Date: Tue, 9 Oct 2012 00:35:02 +0200
From: Samuel Thibault 
To: Matthew Fioravante 
Message-ID: <20121008223502.GY5681@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault ,
	Matthew Fioravante ,
	xen-devel@lists.xen.org, ian.campbell@citrix.com
References: <1349723202-14608-1-git-send-email-matthew.fioravante@jhuapl.edu>
	<1349723202-14608-2-git-send-email-matthew.fioravante@jhuapl.edu>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1349723202-14608-2-git-send-email-matthew.fioravante@jhuapl.edu>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH vtpm v3 02/12] add posix io for blkfront
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Matthew Fioravante, le Mon 08 Oct 2012 15:06:42 -0400, a =E9crit :
> This patch adds posix io support (read,write,lseek) to block devices
> using blkfront.
> =

> Signed-off-by: Matthew Fioravante 
> Acked-by: Samuel Thibault 

Confirmed on this version.

> diff --git a/extras/mini-os/blkfront.c b/extras/mini-os/blkfront.c
> index 74b8b26..f4283a9 100644
> --- a/extras/mini-os/blkfront.c
> +++ b/extras/mini-os/blkfront.c
> @@ -392,6 +392,7 @@ void blkfront_aio(struct blkfront_aiocb *aiocbp, int =
write)
>  static void blkfront_aio_cb(struct blkfront_aiocb *aiocbp, int ret)
>  {
>      aiocbp->data =3D (void*) 1;
> +    aiocbp->aio_cb =3D NULL;
>  }
>  =

>  void blkfront_io(struct blkfront_aiocb *aiocbp, int write)
> @@ -547,9 +548,177 @@ moretodo:
>  #ifdef HAVE_LIBC
>  int blkfront_open(struct blkfront_dev *dev)
>  {
> +    /* Silently prevent multiple opens */
> +    if(dev->fd !=3D -1) {
> +       return dev->fd;
> +    }
>      dev->fd =3D alloc_fd(FTYPE_BLK);
>      printk("blk_open(%s) -> %d\n", dev->nodename, dev->fd);
>      files[dev->fd].blk.dev =3D dev;
> +    files[dev->fd].blk.offset =3D 0;
>      return dev->fd;
>  }
> +
> +int blkfront_posix_rwop(int fd, uint8_t* buf, size_t count, int write)
> +{
> +   struct blkfront_dev* dev =3D files[fd].blk.dev;
> +   off_t offset =3D files[fd].blk.offset;
> +   struct blkfront_aiocb aiocb;
> +   unsigned long long disksize =3D dev->info.sectors * dev->info.sector_=
size;
> +   unsigned int blocksize =3D dev->info.sector_size;
> +
> +   int blknum;
> +   int blkoff;
> +   size_t bytes;
> +   int rc =3D 0;
> +   int alignedbuf =3D 0;
> +   uint8_t* copybuf =3D NULL;
> +
> +   /* RW 0 bytes is just a NOP */
> +   if(count =3D=3D 0) {
> +      return 0;
> +   }
> +   /* Check for NULL buffer */
> +   if( buf =3D=3D NULL ) {
> +      errno =3D EFAULT;
> +      return -1;
> +   }
> +
> +   /* Write mode checks */
> +   if(write) {
> +      /*Make sure we have write permission */
> +      if(dev->info.info & VDISK_READONLY =

> +            || (dev->info.mode !=3D O_RDWR  && dev->info.mode !=3D  O_WR=
ONLY)) {
> +         errno =3D EACCES;
> +         return -1;
> +      }
> +      /*Make sure disk is big enough for this write */
> +      if(offset + count > disksize) {
> +         errno =3D ENOSPC;
> +         return -1;
> +      }
> +   }
> +   /* Read mode checks */
> +   else
> +   {
> +      /* Reading past the disk? Just return 0 */
> +      if(offset >=3D disksize) {
> +         return 0;
> +      }
> +
> +      /*If the requested read is bigger than the disk, just
> +       * read as much as we can until the end */
> +      if(offset + count > disksize) {
> +         count =3D disksize - offset;
> +      }
> +   }
> +   /* Determine which block to start at and at which offset inside of it=
 */
> +   blknum =3D offset / blocksize;
> +   blkoff =3D offset % blocksize;
> +
> +   /* Optimization: We need to check if buf is aligned to the sector siz=
e.
> +    * This is somewhat tricky code. We have to add the blocksize - block=
 offset
> +    * because the first block may be a partial block and then for every =
subsequent
> +    * block rw the buffer will be offset.*/
> +   if(!((uintptr_t) (buf +(blocksize -  blkoff)) & (dev->info.sector_siz=
e-1))) {
> +      alignedbuf =3D 1;
> +   }
> +
> +   /* Setup aiocb block object */
> +   aiocb.aio_dev =3D dev;
> +   aiocb.aio_offset =3D blknum * blocksize;
> +   aiocb.aio_cb =3D NULL;
> +   aiocb.data =3D NULL;
> +
> +   /* If our buffer is unaligned or its aligned but we will need to rw a=
 partial block
> +    * then a copy will have to be done */
> +   if(!alignedbuf || blkoff !=3D 0 || count % blocksize !=3D 0) {
> +      copybuf =3D _xmalloc(blocksize, dev->info.sector_size);
> +   }
> +
> +   rc =3D count;
> +   while(count > 0) {
> +      /* determine how many bytes to read/write from/to the current bloc=
k buffer */
> +      if(!alignedbuf || blkoff !=3D 0 || count < blocksize) {
> +         /* This is the case for unaligned R/W or partial block */
> +         bytes =3D count < blocksize - blkoff ? count : blocksize - blko=
ff;
> +         aiocb.aio_nbytes =3D blocksize;
> +      } else {
> +         /* We can optimize further if buffer is page aligned */
> +         int not_page_aligned =3D 0;
> +         if(((uintptr_t)buf) & (PAGE_SIZE -1)) {
> +            not_page_aligned =3D 1;
> +         }
> +
> +         /* For an aligned R/W we can read up to the maximum transfer si=
ze */
> +         bytes =3D count > (BLKIF_MAX_SEGMENTS_PER_REQUEST-not_page_alig=
ned)*PAGE_SIZE =

> +            ? (BLKIF_MAX_SEGMENTS_PER_REQUEST-not_page_aligned)*PAGE_SIZE
> +            : count & ~(blocksize -1);
> +         aiocb.aio_nbytes =3D bytes;
> +      }
> +
> +      /* read operation */
> +      if(!write) {
> +         if (alignedbuf && bytes >=3D blocksize) {
> +            /* If aligned and were reading a whole block, just read righ=
t into buf */
> +            aiocb.aio_buf =3D buf;
> +            blkfront_read(&aiocb);
> +         } else {
> +            /* If not then we have to do a copy */
> +            aiocb.aio_buf =3D copybuf;
> +            blkfront_read(&aiocb);
> +            memcpy(buf, ©buf[blkoff], bytes);
> +         }
> +      }
> +      /* Write operation */
> +      else {
> +         if(alignedbuf && bytes >=3D blocksize) {
> +            /* If aligned and were writing a whole block, just write dir=
ectly from buf */
> +            aiocb.aio_buf =3D buf;
> +            blkfront_write(&aiocb);
> +         } else {
> +            /* If not then we have to do a copy. */
> +            aiocb.aio_buf =3D copybuf;
> +            /* If we're writing a partial block, we need to read the cur=
rent contents first
> +             * so we don't overwrite the extra bits with garbage */
> +            if(blkoff !=3D 0 || bytes < blocksize) {
> +               blkfront_read(&aiocb);
> +            }
> +            memcpy(©buf[blkoff], buf, bytes);
> +            blkfront_write(&aiocb);
> +         }
> +      }
> +      /* Will start at beginning of all remaining blocks */
> +      blkoff =3D 0;
> +
> +      /* Increment counters and continue */
> +      count -=3D bytes;
> +      buf +=3D bytes;
> +      if(bytes < blocksize) {
> +         //At minimum we read one block
> +         aiocb.aio_offset +=3D blocksize;
> +      } else {
> +         //If we read more than a block, was a multiple of blocksize
> +         aiocb.aio_offset +=3D bytes;
> +      }
> +   }
> +
> +   free(copybuf);
> +   files[fd].blk.offset +=3D rc;
> +   return rc;
> +
> +}
> +
> +int blkfront_posix_fstat(int fd, struct stat* buf)
> +{
> +   struct blkfront_dev* dev =3D files[fd].blk.dev;
> +
> +   buf->st_mode =3D dev->info.mode;
> +   buf->st_uid =3D 0;
> +   buf->st_gid =3D 0;
> +   buf->st_size =3D dev->info.sectors * dev->info.sector_size;
> +   buf->st_atime =3D buf->st_mtime =3D buf->st_ctime =3D time(NULL);
> +
> +   return 0;
> +}
>  #endif
> diff --git a/extras/mini-os/include/blkfront.h b/extras/mini-os/include/b=
lkfront.h
> index 724137e..3528af9 100644
> --- a/extras/mini-os/include/blkfront.h
> +++ b/extras/mini-os/include/blkfront.h
> @@ -28,7 +28,17 @@ struct blkfront_info
>  };
>  struct blkfront_dev *init_blkfront(char *nodename, struct blkfront_info =
*info);
>  #ifdef HAVE_LIBC
> +#include 
> +/* POSIX IO functions:
> + * use blkfront_open() to get a file descriptor to the block device
> + * Don't use the other blkfront posix functions here directly, instead u=
se
> + * read(), write(), lseek() and fstat() on the file descriptor
> + */
>  int blkfront_open(struct blkfront_dev *dev);
> +int blkfront_posix_rwop(int fd, uint8_t* buf, size_t count, int write);
> +#define blkfront_posix_write(fd, buf, count) blkfront_posix_rwop(fd, (ui=
nt8_t*)buf, count, 1)
> +#define blkfront_posix_read(fd, buf, count) blkfront_posix_rwop(fd, (uin=
t8_t*)buf, count, 0)
> +int blkfront_posix_fstat(int fd, struct stat* buf);
>  #endif
>  void blkfront_aio(struct blkfront_aiocb *aiocbp, int write);
>  #define blkfront_aio_read(aiocbp) blkfront_aio(aiocbp, 0)
> diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h
> index 1af2717..d4641b6 100644
> --- a/extras/mini-os/include/lib.h
> +++ b/extras/mini-os/include/lib.h
> @@ -174,6 +174,7 @@ extern struct file {
>  	} tap;
>  	struct {
>  	    struct blkfront_dev *dev;
> +            off_t offset;
>  	} blk;
>  	struct {
>  	    struct kbdfront_dev *dev;
> diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
> index a7d35d6..7ddbbf8 100644
> --- a/extras/mini-os/lib/sys.c
> +++ b/extras/mini-os/lib/sys.c
> @@ -289,6 +289,11 @@ int read(int fd, void *buf, size_t nbytes)
>  	    return ret * sizeof(union xenfb_in_event);
>          }
>  #endif
> +#ifdef CONFIG_BLKFRONT
> +        case FTYPE_BLK: {
> +	    return blkfront_posix_read(fd, buf, nbytes);
> +        }
> +#endif
>  	default:
>  	    break;
>      }
> @@ -321,6 +326,10 @@ int write(int fd, const void *buf, size_t nbytes)
>  	    netfront_xmit(files[fd].tap.dev, (void*) buf, nbytes);
>  	    return nbytes;
>  #endif
> +#ifdef CONFIG_BLKFRONT
> +	case FTYPE_BLK:
> +	    return blkfront_posix_write(fd, buf, nbytes);
> +#endif
>  	default:
>  	    break;
>      }
> @@ -331,8 +340,37 @@ int write(int fd, const void *buf, size_t nbytes)
>  =

>  off_t lseek(int fd, off_t offset, int whence)
>  {
> -    errno =3D ESPIPE;
> -    return (off_t) -1;
> +    switch(files[fd].type) {
> +#ifdef CONFIG_BLKFRONT
> +       case FTYPE_BLK:
> +	  switch (whence) {
> +	     case SEEK_SET:
> +		files[fd].file.offset =3D offset;
> +		break;
> +	     case SEEK_CUR:
> +		files[fd].file.offset +=3D offset;
> +		break;
> +	     case SEEK_END:
> +		{
> +		   struct stat st;
> +		   int ret;
> +		   ret =3D fstat(fd, &st);
> +		   if (ret)
> +		      return -1;
> +		   files[fd].file.offset =3D st.st_size + offset;
> +		   break;
> +		}
> +	     default:
> +		errno =3D EINVAL;
> +		return -1;
> +	  }
> +	  return files[fd].file.offset;
> +	  break;
> +#endif
> +       default: /* Not implemented on this FTYPE */
> +	  errno =3D ESPIPE;
> +	  return (off_t) -1;
> +    }
>  }
>  =

>  int fsync(int fd) {
> @@ -445,6 +483,10 @@ int fstat(int fd, struct stat *buf)
>  	    buf->st_ctime =3D time(NULL);
>  	    return 0;
>  	}
> +#ifdef CONFIG_BLKFRONT
> +	case FTYPE_BLK:
> +	   return blkfront_posix_fstat(fd, buf);
> +#endif
>  	default:
>  	    break;
>      }
> -- =

> 1.7.4.4
> =


-- =

Samuel
 PS> Salut ! J'ai un sujet de philo =E0 vous soumettre : "Suffit-il
 PS> d'observer pour conna=EEtre" Id=E9es + plan Mer=E7i
 Oui, ya qu'a t'observer pour conna=EEtre le fait que tu es une feignasse.
 -+- FF in: Guide du Neuneu d'Usenet - Neuneu fait de la philo -+-

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 22:43:26 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 22:43:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLM2T-0006m6-Aa; Mon, 08 Oct 2012 22:43:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLM2S-0006m1-50
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 22:43:04 +0000
Received: from [85.158.139.211:57957] by server-11.bemta-5.messagelabs.com id
	67/2E-13866-7F653705; Mon, 08 Oct 2012 22:43:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1349736182!21574812!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMyNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7035 invoked from network); 8 Oct 2012 22:43:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 22:43:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,556,1344211200"; d="scan'208";a="15021396"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 22:43:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Mon, 8 Oct 2012 23:43:00 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TLM2O-0004wg-2w;
	Mon, 08 Oct 2012 22:43:00 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TLM2O-0005cq-2V;
	Mon, 08 Oct 2012 23:43:00 +0100
To: 
Message-ID: 
From: xen.org 
Date: Mon, 8 Oct 2012 23:43:00 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13936: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13936 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13936/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 13932
 build-i386                    4 xen-build                 fail REGR. vs. 13932

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13932
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13932
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13932
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13932

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  c9f621893a05
baseline version:
 xen                  099589002239

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD 
  Ian Campbell 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Samuel Thibault 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26017:c9f621893a05
tag:         tip
user:        Matthew Fioravante 
date:        Mon Oct 08 14:36:31 2012 +0100
    
    minios: setup fpu and sse in mini-os
    
    This patch adds floating point and sse support to mini-os by
    initializing the floating point unit and the see unit during
    domain boot up.
    
    Signed-off-by: Matthew Fioravante 
    Acked-by: Samuel Thibault 
    Committed-by: Ian Campbell 
    
    
changeset:   26016:865626fc7004
user:        Matthew Fioravante 
date:        Mon Oct 08 14:36:31 2012 +0100
    
    minios: add CONFIG_XC conditional
    
    This patch adds a CONFIG_XC option to mini-os, to allow conditional
    support for libxc for mini-os domains.
    
    Signed-off-by: Matthew Fioravante 
    Acked-by: Samuel Thibault 
    Committed-by: Ian Campbell 
    
    
changeset:   26015:42ca0ed31aa6
user:        Matthew Fioravante 
date:        Mon Oct 08 14:36:30 2012 +0100
    
    minios: Disable the mfn_is_ram() check, it doesn't work correctly on all systems
    
    This patch disables the mfn_is_ram check in mini-os. The current check
    is insufficient and fails on some systems with larger than 4gb memory.
    
    Signed-off-by: Matthew Fioravante 
    Acked-by: Samuel Thibault 
    Committed-by: Ian Campbell 
    
    
changeset:   26014:8fdb8d464ece
user:        Matthew Fioravante 
date:        Mon Oct 08 14:36:29 2012 +0100
    
    minios: Add endian, byteswap, and wordsize macros to mini-os
    
    This patch addes byte swapping macros and endian support to mini-os.
    
    Signed-off-by: Matthew Fioravante 
    Acked-by: Samuel Thibault 
    Committed-by: Ian Campbell 
    
    
changeset:   26013:a797d59e1d29
user:        Matthew Fioravante 
date:        Mon Oct 08 14:36:28 2012 +0100
    
    minios: Add ioread/iowrite functions to mini-os
    
    This patch adds iowritexx() and ioreadxx() functions for interacting
    with hardware memory to mini-os. The functions are available in a header
    iorw.h
    
    Signed-off-by: Matthew Fioravante 
    Acked-by: Samuel Thibault 
    Reviewed-by: George Dunlap 
    Committed-by: Ian Campbell 
    
    
changeset:   26012:02e744da52c9
user:        Olaf Hering 
date:        Mon Oct 08 12:18:35 2012 +0100
    
    tools/configure.ac: fill PACKAGE_TARNAME in AC_INIT
    
    Upcoming changes may move DOCDIR from Config.mk to config/Tools.mk. To
    preserve the currently used path, which ends with /xen, specify a value
    for PACKAGE_TARNAME. Without this change the path would end with
    /xen-hypervisor.
    
    Please rerun autoconf after applying this.
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26011:b6fb4e63b946
user:        Olaf Hering 
date:        Mon Oct 08 12:18:34 2012 +0100
    
    stubdom: fix parallel build by expanding CROSS_MAKE
    
    Recently I changed my rpm xen.spec file from doing
    'make -C tools -j N && make stubdom' to 'make -j N stubdom' because
    stubdom depends on tools, so both get built.
    The result was the failure below.
    
    ....
    mkdir -p grub-x86_64
    CPPFLAGS="-isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include -D__MINIOS__ -DHAVE_LIBC -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include/posix -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../tools/xenstore  -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include/x86 -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include/x86/x86_64 -U __linux__ -U __FreeBSD__ -U __sun__ -nostdinc -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include/posix -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/cross-root-x86_64/x86_64-xen-elf/include -isystem /usr/lib64/gcc/x86_64-suse-linux/4.7/include -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/lwip-x86_64/src/include -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/lwip-x86_64/src/include/ipv4 -I/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/include -I/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../xen/include" CFLAGS="-mno-red-zone -O1 -fno-omit-frame-pointer  -m64 -mno-red-zone -fno-reorder-blocks -fno-asynchronous-unwind-tables -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable   -fno-stack-protector -fno-exceptions" make DESTDIR= -C grub OBJ_DIR=/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/grub-x86_64
    make[2]: Entering directory `/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/grub'
    make[2]: warning: jobserver unavailable: using -j1.  Add `+' to parent make rule.
    make[2]: *** INTERNAL: readdir: Bad file descriptor
    .  Stop.
    make[2]: Makefile: Field 'stem' not cached: Makefile
    
    make[2]: Leaving directory `/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/grub'
    make[1]: *** [grub] Error 2
    [ -d mini-os-x86_64-xenstore ] || \
    for i in $(cd /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os ; find . -type d) ; do \
                    mkdir -p mini-os-x86_64-xenstore/$i ; \
    done
    ....
    
    Expanding every occurrence of CROSS_MAKE avoids this error. It also has
    the nice side effect of actually enabling parallel build for stubdom.
    According to the GNU make documentation $(MAKE) gets its special meaning
    only if it appears directly in the recipe:
    
    http://www.gnu.org/software/make/manual/html_node/MAKE-Variable.html
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26010:cff10030c6ea
user:        Olaf Hering 
date:        Mon Oct 08 12:18:33 2012 +0100
    
    xend/pvscsi: update sysfs parser for Linux 3.0
    
    The sysfs parser for /sys/bus/scsi/devices understands only the layout
    of kernel version 2.6.16. This looks as follows:
    
    /sys/bus/scsi/devices/1:0:0:0/block:sda is a symlink to /sys/block/sda/
    /sys/bus/scsi/devices/1:0:0:0/scsi_generic:sg1 is a symlink to /sys/class/scsi_generic/sg1
    
    Both directories contain a 'dev' file with the major:minor information.
    This patch updates the used regex strings to match also the colon to
    make it more robust against possible future changes.
    
    In kernel version 3.0 the layout changed:
    /sys/bus/scsi/devices/ contains now additional symlinks to directories
    such as host1 and target1:0:0. This patch ignores these as they do not
    point to the desired scsi devices. They just clutter the devices array.
    
    The directory layout in '1:0:0:0' changed as well, the 'type:name'
    notation was replaced with 'type/name' directories:
    
    /sys/bus/scsi/devices/1:0:0:0/block/sda/
    /sys/bus/scsi/devices/1:0:0:0/scsi_generic/sg1/
    
    Both directories contain a 'dev' file with the major:minor information.
    This patch adds additional code to walk the subdir to find the 'dev'
    file to make sure the given subdirectory is really the kernel name.
    
    In addition this patch makes sure devname is not None.
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26009:2dbfa4d2e107
user:        Olaf Hering 
date:        Mon Oct 08 12:18:32 2012 +0100
    
    xend/pvscsi: fix usage of persistant device names for SCSI devices
    
    Currently the callers of vscsi_get_scsidevices() do not pass a mask
    string.  This will call "lsscsi -g '[]'", which causes a lsscsi syntax
    error. As a result the sysfs parser _vscsi_get_scsidevices() is used.
    But this parser is broken and the specified names in the config file are
    not found.
    
    Using a mask '*' if no mask was given will call lsscsi correctly and the
    following config is parsed correctly:
    
    vscsi=[
    	'/dev/sg3, 0:0:0:0',
    	'/dev/disk/by-id/wwn-0x600508b4000cf1c30000800000410000, 0:0:0:1'
    ]
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26008:eecb528583d7
user:        Olaf Hering 
date:        Mon Oct 08 12:18:31 2012 +0100
    
    xend/pvscsi: fix passing of SCSI control LUNs
    
    Currently pvscsi can not pass SCSI devices that have just a scsi_generic node.
    In the following example sg3 is a control LUN for the disk sdd.
    But vscsi=['4:0:2:0,0:0:0:0'] does not work because the internal 'devname'
    variable remains None. Later writing p-devname to xenstore fails because None
    is not a valid string variable.
    
    Since devname is used for just informational purpose use sg also as devname.
    
    carron:~ $ lsscsi -g
    [0:0:0:0]    disk    ATA      FK0032CAAZP      HPF2  /dev/sda   /dev/sg0
    [4:0:0:0]    disk    HP       P2000G3 FC/iSCSI T100  /dev/sdb   /dev/sg1
    [4:0:1:0]    disk    HP       P2000G3 FC/iSCSI T100  /dev/sdc   /dev/sg2
    [4:0:2:0]    storage HP       HSV400           0950  -         /dev/sg3
    [4:0:2:1]    disk    HP       HSV400           0950  /dev/sdd   /dev/sg4
    [4:0:3:0]    storage HP       HSV400           0950  -         /dev/sg5
    [4:0:3:1]    disk    HP       HSV400           0950  /dev/sde   /dev/sg6
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26007:fe756682cc7f
user:        Olaf Hering 
date:        Mon Oct 08 12:18:31 2012 +0100
    
    xenballoond.init: remove 4 from default runlevel
    
    Remove 4 from default runlevel in xenballoond.init.
    
    Similar to what changeset 24847:0900b1c905f1 does in xencommons, remove
    runlevel 4 from the other runlevel scripts. LSB defines runlevel 4 as
    reserved for local use, the local sysadmin is responsible for symlink
    creation in rc4.d.
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26006:8b6870d686d6
user:        Olaf Hering 
date:        Mon Oct 08 12:18:30 2012 +0100
    
    hotplug/Linux: Remove tracing (bash -x) from network-nat script
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26005:cdb48f1742f3
user:        Roger Pau Monne 
date:        Mon Oct 08 12:18:29 2012 +0100
    
    autoconf: add -Werror to libutil.h header check
    
    libutil.h is only needed on BSDs, but not in Linux. Debian package
    libbsd-dev-0.3.0-1 installed a libutil.h overlay that contains a
    
    Perform the libutil.h check with -Werror, so we don't include this
    bogus header.
    
    Signed-off-by: Roger Pau Monne 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26004:099589002239
user:        Anthony PERARD 
date:        Mon Oct 08 11:45:36 2012 +0100
    
    libxl: Allow migration with qemu-xen.
    
    Signed-off-by: Anthony PERARD 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 08 22:43:26 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 08 Oct 2012 22:43:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLM2T-0006m6-Aa; Mon, 08 Oct 2012 22:43:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLM2S-0006m1-50
	for xen-devel@lists.xensource.com; Mon, 08 Oct 2012 22:43:04 +0000
Received: from [85.158.139.211:57957] by server-11.bemta-5.messagelabs.com id
	67/2E-13866-7F653705; Mon, 08 Oct 2012 22:43:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1349736182!21574812!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMyNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7035 invoked from network); 8 Oct 2012 22:43:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Oct 2012 22:43:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,556,1344211200"; d="scan'208";a="15021396"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Oct 2012 22:43:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Mon, 8 Oct 2012 23:43:00 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TLM2O-0004wg-2w;
	Mon, 08 Oct 2012 22:43:00 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TLM2O-0005cq-2V;
	Mon, 08 Oct 2012 23:43:00 +0100
To: 
Message-ID: 
From: xen.org 
Date: Mon, 8 Oct 2012 23:43:00 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13936: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13936 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13936/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 13932
 build-i386                    4 xen-build                 fail REGR. vs. 13932

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13932
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13932
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13932
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13932

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  c9f621893a05
baseline version:
 xen                  099589002239

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD 
  Ian Campbell 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Samuel Thibault 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26017:c9f621893a05
tag:         tip
user:        Matthew Fioravante 
date:        Mon Oct 08 14:36:31 2012 +0100
    
    minios: setup fpu and sse in mini-os
    
    This patch adds floating point and sse support to mini-os by
    initializing the floating point unit and the see unit during
    domain boot up.
    
    Signed-off-by: Matthew Fioravante 
    Acked-by: Samuel Thibault 
    Committed-by: Ian Campbell 
    
    
changeset:   26016:865626fc7004
user:        Matthew Fioravante 
date:        Mon Oct 08 14:36:31 2012 +0100
    
    minios: add CONFIG_XC conditional
    
    This patch adds a CONFIG_XC option to mini-os, to allow conditional
    support for libxc for mini-os domains.
    
    Signed-off-by: Matthew Fioravante 
    Acked-by: Samuel Thibault 
    Committed-by: Ian Campbell 
    
    
changeset:   26015:42ca0ed31aa6
user:        Matthew Fioravante 
date:        Mon Oct 08 14:36:30 2012 +0100
    
    minios: Disable the mfn_is_ram() check, it doesn't work correctly on all systems
    
    This patch disables the mfn_is_ram check in mini-os. The current check
    is insufficient and fails on some systems with larger than 4gb memory.
    
    Signed-off-by: Matthew Fioravante 
    Acked-by: Samuel Thibault 
    Committed-by: Ian Campbell 
    
    
changeset:   26014:8fdb8d464ece
user:        Matthew Fioravante 
date:        Mon Oct 08 14:36:29 2012 +0100
    
    minios: Add endian, byteswap, and wordsize macros to mini-os
    
    This patch addes byte swapping macros and endian support to mini-os.
    
    Signed-off-by: Matthew Fioravante 
    Acked-by: Samuel Thibault 
    Committed-by: Ian Campbell 
    
    
changeset:   26013:a797d59e1d29
user:        Matthew Fioravante 
date:        Mon Oct 08 14:36:28 2012 +0100
    
    minios: Add ioread/iowrite functions to mini-os
    
    This patch adds iowritexx() and ioreadxx() functions for interacting
    with hardware memory to mini-os. The functions are available in a header
    iorw.h
    
    Signed-off-by: Matthew Fioravante 
    Acked-by: Samuel Thibault 
    Reviewed-by: George Dunlap 
    Committed-by: Ian Campbell 
    
    
changeset:   26012:02e744da52c9
user:        Olaf Hering 
date:        Mon Oct 08 12:18:35 2012 +0100
    
    tools/configure.ac: fill PACKAGE_TARNAME in AC_INIT
    
    Upcoming changes may move DOCDIR from Config.mk to config/Tools.mk. To
    preserve the currently used path, which ends with /xen, specify a value
    for PACKAGE_TARNAME. Without this change the path would end with
    /xen-hypervisor.
    
    Please rerun autoconf after applying this.
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26011:b6fb4e63b946
user:        Olaf Hering 
date:        Mon Oct 08 12:18:34 2012 +0100
    
    stubdom: fix parallel build by expanding CROSS_MAKE
    
    Recently I changed my rpm xen.spec file from doing
    'make -C tools -j N && make stubdom' to 'make -j N stubdom' because
    stubdom depends on tools, so both get built.
    The result was the failure below.
    
    ....
    mkdir -p grub-x86_64
    CPPFLAGS="-isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include -D__MINIOS__ -DHAVE_LIBC -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include/posix -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../tools/xenstore  -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include/x86 -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include/x86/x86_64 -U __linux__ -U __FreeBSD__ -U __sun__ -nostdinc -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include/posix -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/cross-root-x86_64/x86_64-xen-elf/include -isystem /usr/lib64/gcc/x86_64-suse-linux/4.7/include -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/lwip-x86_64/src/include -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/lwip-x86_64/src/include/ipv4 -I/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/include -I/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../xen/include" CFLAGS="-mno-red-zone -O1 -fno-omit-frame-pointer  -m64 -mno-red-zone -fno-reorder-blocks -fno-asynchronous-unwind-tables -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable   -fno-stack-protector -fno-exceptions" make DESTDIR= -C grub OBJ_DIR=/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/grub-x86_64
    make[2]: Entering directory `/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/grub'
    make[2]: warning: jobserver unavailable: using -j1.  Add `+' to parent make rule.
    make[2]: *** INTERNAL: readdir: Bad file descriptor
    .  Stop.
    make[2]: Makefile: Field 'stem' not cached: Makefile
    
    make[2]: Leaving directory `/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/grub'
    make[1]: *** [grub] Error 2
    [ -d mini-os-x86_64-xenstore ] || \
    for i in $(cd /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os ; find . -type d) ; do \
                    mkdir -p mini-os-x86_64-xenstore/$i ; \
    done
    ....
    
    Expanding every occurrence of CROSS_MAKE avoids this error. It also has
    the nice side effect of actually enabling parallel build for stubdom.
    According to the GNU make documentation $(MAKE) gets its special meaning
    only if it appears directly in the recipe:
    
    http://www.gnu.org/software/make/manual/html_node/MAKE-Variable.html
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26010:cff10030c6ea
user:        Olaf Hering 
date:        Mon Oct 08 12:18:33 2012 +0100
    
    xend/pvscsi: update sysfs parser for Linux 3.0
    
    The sysfs parser for /sys/bus/scsi/devices understands only the layout
    of kernel version 2.6.16. This looks as follows:
    
    /sys/bus/scsi/devices/1:0:0:0/block:sda is a symlink to /sys/block/sda/
    /sys/bus/scsi/devices/1:0:0:0/scsi_generic:sg1 is a symlink to /sys/class/scsi_generic/sg1
    
    Both directories contain a 'dev' file with the major:minor information.
    This patch updates the used regex strings to match also the colon to
    make it more robust against possible future changes.
    
    In kernel version 3.0 the layout changed:
    /sys/bus/scsi/devices/ contains now additional symlinks to directories
    such as host1 and target1:0:0. This patch ignores these as they do not
    point to the desired scsi devices. They just clutter the devices array.
    
    The directory layout in '1:0:0:0' changed as well, the 'type:name'
    notation was replaced with 'type/name' directories:
    
    /sys/bus/scsi/devices/1:0:0:0/block/sda/
    /sys/bus/scsi/devices/1:0:0:0/scsi_generic/sg1/
    
    Both directories contain a 'dev' file with the major:minor information.
    This patch adds additional code to walk the subdir to find the 'dev'
    file to make sure the given subdirectory is really the kernel name.
    
    In addition this patch makes sure devname is not None.
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26009:2dbfa4d2e107
user:        Olaf Hering 
date:        Mon Oct 08 12:18:32 2012 +0100
    
    xend/pvscsi: fix usage of persistant device names for SCSI devices
    
    Currently the callers of vscsi_get_scsidevices() do not pass a mask
    string.  This will call "lsscsi -g '[]'", which causes a lsscsi syntax
    error. As a result the sysfs parser _vscsi_get_scsidevices() is used.
    But this parser is broken and the specified names in the config file are
    not found.
    
    Using a mask '*' if no mask was given will call lsscsi correctly and the
    following config is parsed correctly:
    
    vscsi=[
    	'/dev/sg3, 0:0:0:0',
    	'/dev/disk/by-id/wwn-0x600508b4000cf1c30000800000410000, 0:0:0:1'
    ]
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26008:eecb528583d7
user:        Olaf Hering 
date:        Mon Oct 08 12:18:31 2012 +0100
    
    xend/pvscsi: fix passing of SCSI control LUNs
    
    Currently pvscsi can not pass SCSI devices that have just a scsi_generic node.
    In the following example sg3 is a control LUN for the disk sdd.
    But vscsi=['4:0:2:0,0:0:0:0'] does not work because the internal 'devname'
    variable remains None. Later writing p-devname to xenstore fails because None
    is not a valid string variable.
    
    Since devname is used for just informational purpose use sg also as devname.
    
    carron:~ $ lsscsi -g
    [0:0:0:0]    disk    ATA      FK0032CAAZP      HPF2  /dev/sda   /dev/sg0
    [4:0:0:0]    disk    HP       P2000G3 FC/iSCSI T100  /dev/sdb   /dev/sg1
    [4:0:1:0]    disk    HP       P2000G3 FC/iSCSI T100  /dev/sdc   /dev/sg2
    [4:0:2:0]    storage HP       HSV400           0950  -         /dev/sg3
    [4:0:2:1]    disk    HP       HSV400           0950  /dev/sdd   /dev/sg4
    [4:0:3:0]    storage HP       HSV400           0950  -         /dev/sg5
    [4:0:3:1]    disk    HP       HSV400           0950  /dev/sde   /dev/sg6
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26007:fe756682cc7f
user:        Olaf Hering 
date:        Mon Oct 08 12:18:31 2012 +0100
    
    xenballoond.init: remove 4 from default runlevel
    
    Remove 4 from default runlevel in xenballoond.init.
    
    Similar to what changeset 24847:0900b1c905f1 does in xencommons, remove
    runlevel 4 from the other runlevel scripts. LSB defines runlevel 4 as
    reserved for local use, the local sysadmin is responsible for symlink
    creation in rc4.d.
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26006:8b6870d686d6
user:        Olaf Hering 
date:        Mon Oct 08 12:18:30 2012 +0100
    
    hotplug/Linux: Remove tracing (bash -x) from network-nat script
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26005:cdb48f1742f3
user:        Roger Pau Monne 
date:        Mon Oct 08 12:18:29 2012 +0100
    
    autoconf: add -Werror to libutil.h header check
    
    libutil.h is only needed on BSDs, but not in Linux. Debian package
    libbsd-dev-0.3.0-1 installed a libutil.h overlay that contains a
    
    Perform the libutil.h check with -Werror, so we don't include this
    bogus header.
    
    Signed-off-by: Roger Pau Monne 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26004:099589002239
user:        Anthony PERARD 
date:        Mon Oct 08 11:45:36 2012 +0100
    
    libxl: Allow migration with qemu-xen.
    
    Signed-off-by: Anthony PERARD 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 01:01:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 01:01:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLOBe-0005Zn-99; Tue, 09 Oct 2012 01:00:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLOBc-0005DC-9G
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 01:00:40 +0000
Received: from [85.158.139.83:36198] by server-6.bemta-5.messagelabs.com id
	88/68-14717-73773705; Tue, 09 Oct 2012 01:00:39 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1349744435!34248533!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc5OTA1Nw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24231 invoked from network); 9 Oct 2012 01:00:37 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Oct 2012 01:00:37 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9910RA5010868
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 9 Oct 2012 01:00:28 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9910Rmc000725
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 9 Oct 2012 01:00:27 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q990xQ8R019446; Mon, 8 Oct 2012 19:59:26 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 08 Oct 2012 17:59:26 -0700
Date: Mon, 8 Oct 2012 17:59:25 -0700
From: Mukesh Rathor 
To: Ian Campbell 
Message-ID: <20121008175925.105e78de@mantra.us.oracle.com>
In-Reply-To: <1349444550.20946.102.camel@zakaz.uk.xensource.com>
References: <1349363496.866.49.camel@zakaz.uk.xensource.com>
	<1349363515-26190-11-git-send-email-ian.campbell@citrix.com>
	
	<1349444550.20946.102.camel@zakaz.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Konrad Rzeszutek Wilk ,
	"xen-devel@lists.xen.org" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 11/14] arm: implement remap interfaces
 needed for privcmd mappings.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 5 Oct 2012 14:42:30 +0100
Ian Campbell  wrote:

> On Fri, 2012-10-05 at 14:36 +0100, Stefano Stabellini wrote:
> [... snip dozens of pointless lines -- please trim your quotes...]
> 
> > > -	return -ENOSYS;
> > > +	int err;
> > > +	struct remap_data data;
> > > +
> > > +	/* TBD: Batching, current sole caller only does page at
> > > a time */
> > > +	if (nr > 1)
> > > +		return -EINVAL;
> > 
> > It looks like that this implementation of
> > xen_remap_domain_mfn_range is capable of handling nr > 1, so why
> > this return -EINVAL?
> 
> Hrm, yes. I think I just blindly copied that from the pvh
> implementation.
> 
> [...]

PVH was using a different mechanism earlier, pfn from high up memory
address space. So it was doing one at a time. It can be removed now.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 01:01:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 01:01:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLOBe-0005Zn-99; Tue, 09 Oct 2012 01:00:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLOBc-0005DC-9G
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 01:00:40 +0000
Received: from [85.158.139.83:36198] by server-6.bemta-5.messagelabs.com id
	88/68-14717-73773705; Tue, 09 Oct 2012 01:00:39 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1349744435!34248533!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc5OTA1Nw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24231 invoked from network); 9 Oct 2012 01:00:37 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Oct 2012 01:00:37 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9910RA5010868
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 9 Oct 2012 01:00:28 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9910Rmc000725
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 9 Oct 2012 01:00:27 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q990xQ8R019446; Mon, 8 Oct 2012 19:59:26 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 08 Oct 2012 17:59:26 -0700
Date: Mon, 8 Oct 2012 17:59:25 -0700
From: Mukesh Rathor 
To: Ian Campbell 
Message-ID: <20121008175925.105e78de@mantra.us.oracle.com>
In-Reply-To: <1349444550.20946.102.camel@zakaz.uk.xensource.com>
References: <1349363496.866.49.camel@zakaz.uk.xensource.com>
	<1349363515-26190-11-git-send-email-ian.campbell@citrix.com>
	
	<1349444550.20946.102.camel@zakaz.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Konrad Rzeszutek Wilk ,
	"xen-devel@lists.xen.org" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 11/14] arm: implement remap interfaces
 needed for privcmd mappings.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 5 Oct 2012 14:42:30 +0100
Ian Campbell  wrote:

> On Fri, 2012-10-05 at 14:36 +0100, Stefano Stabellini wrote:
> [... snip dozens of pointless lines -- please trim your quotes...]
> 
> > > -	return -ENOSYS;
> > > +	int err;
> > > +	struct remap_data data;
> > > +
> > > +	/* TBD: Batching, current sole caller only does page at
> > > a time */
> > > +	if (nr > 1)
> > > +		return -EINVAL;
> > 
> > It looks like that this implementation of
> > xen_remap_domain_mfn_range is capable of handling nr > 1, so why
> > this return -EINVAL?
> 
> Hrm, yes. I think I just blindly copied that from the pvh
> implementation.
> 
> [...]

PVH was using a different mechanism earlier, pfn from high up memory
address space. So it was doing one at a time. It can be removed now.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 01:10:15 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 01:10:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLOKP-0003Mv-Fj; Tue, 09 Oct 2012 01:09:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLOKN-0003Mq-CY
	for Xen-devel@lists.xensource.com; Tue, 09 Oct 2012 01:09:44 +0000
Received: from [85.158.137.99:36548] by server-6.bemta-3.messagelabs.com id
	E6/D3-11085-65973705; Tue, 09 Oct 2012 01:09:42 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1349744980!15428001!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzkwNDA2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29475 invoked from network); 9 Oct 2012 01:09:41 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-8.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Oct 2012 01:09:41 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9919VBm005311
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 9 Oct 2012 01:09:32 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9919U7U017058
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 9 Oct 2012 01:09:31 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9917U68001836; Mon, 8 Oct 2012 20:07:30 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 08 Oct 2012 18:07:30 -0700
Date: Mon, 8 Oct 2012 18:07:28 -0700
From: Mukesh Rathor 
To: Konrad Rzeszutek Wilk 
Message-ID: <20121008180728.07893577@mantra.us.oracle.com>
In-Reply-To: <20121008124101.GB29650@localhost.localdomain>
References: <20120924154335.097d3fb9@mantra.us.oracle.com>
	
	<20120925180416.0137d61a@mantra.us.oracle.com>
	
	<20121002183619.70734b7a@mantra.us.oracle.com>
	<20121002190323.2e16f6ff@mantra.us.oracle.com>
	
	<1349265914.650.136.camel@zakaz.uk.xensource.com>
	<20121004183528.060416a0@mantra.us.oracle.com>
	<1349429005.20946.20.camel@zakaz.uk.xensource.com>
	<20121008124101.GB29650@localhost.localdomain>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "Xen-devel@lists.xensource.com" ,
	Ian Campbell ,
	Stefano Stabellini ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH v1 3/8]: PVH startup changes (enlighten.c)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 8 Oct 2012 08:41:02 -0400
Konrad Rzeszutek Wilk  wrote:

> On Fri, Oct 05, 2012 at 10:23:25AM +0100, Ian Campbell wrote:
> > On Fri, 2012-10-05 at 02:35 +0100, Mukesh Rathor wrote:
> > > On Wed, 3 Oct 2012 13:05:14 +0100
> > > Ian Campbell  wrote:
> > > 
> > > > On Wed, 2012-10-03 at 12:58 +0100, Stefano Stabellini wrote:
> > In the case where the ARM stuff I have built on this becomes ripe
> > first would it be OK with you guys if I were to cherry pick the
> > relevant bits of the PVH stuff into a series to go in sooner?
> 
> My plan right now was to wait for Mukesh to repost his series (which
> I hope will address all our review comments) and then I can shovel
> any other patches on top of that.
> 
> But if it makes sense to intermix Mukeshes's patchs, and yours.
> (or squash some together) I can do that too.

Ok, I'm all done with changes. Doing final testing now, and will have 
patches sent by Tues afternoon.

thanks,
Mukesh


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 01:10:15 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 01:10:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLOKP-0003Mv-Fj; Tue, 09 Oct 2012 01:09:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLOKN-0003Mq-CY
	for Xen-devel@lists.xensource.com; Tue, 09 Oct 2012 01:09:44 +0000
Received: from [85.158.137.99:36548] by server-6.bemta-3.messagelabs.com id
	E6/D3-11085-65973705; Tue, 09 Oct 2012 01:09:42 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1349744980!15428001!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzkwNDA2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29475 invoked from network); 9 Oct 2012 01:09:41 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-8.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Oct 2012 01:09:41 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9919VBm005311
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 9 Oct 2012 01:09:32 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9919U7U017058
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 9 Oct 2012 01:09:31 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9917U68001836; Mon, 8 Oct 2012 20:07:30 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 08 Oct 2012 18:07:30 -0700
Date: Mon, 8 Oct 2012 18:07:28 -0700
From: Mukesh Rathor 
To: Konrad Rzeszutek Wilk 
Message-ID: <20121008180728.07893577@mantra.us.oracle.com>
In-Reply-To: <20121008124101.GB29650@localhost.localdomain>
References: <20120924154335.097d3fb9@mantra.us.oracle.com>
	
	<20120925180416.0137d61a@mantra.us.oracle.com>
	
	<20121002183619.70734b7a@mantra.us.oracle.com>
	<20121002190323.2e16f6ff@mantra.us.oracle.com>
	
	<1349265914.650.136.camel@zakaz.uk.xensource.com>
	<20121004183528.060416a0@mantra.us.oracle.com>
	<1349429005.20946.20.camel@zakaz.uk.xensource.com>
	<20121008124101.GB29650@localhost.localdomain>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "Xen-devel@lists.xensource.com" ,
	Ian Campbell ,
	Stefano Stabellini ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH v1 3/8]: PVH startup changes (enlighten.c)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 8 Oct 2012 08:41:02 -0400
Konrad Rzeszutek Wilk  wrote:

> On Fri, Oct 05, 2012 at 10:23:25AM +0100, Ian Campbell wrote:
> > On Fri, 2012-10-05 at 02:35 +0100, Mukesh Rathor wrote:
> > > On Wed, 3 Oct 2012 13:05:14 +0100
> > > Ian Campbell  wrote:
> > > 
> > > > On Wed, 2012-10-03 at 12:58 +0100, Stefano Stabellini wrote:
> > In the case where the ARM stuff I have built on this becomes ripe
> > first would it be OK with you guys if I were to cherry pick the
> > relevant bits of the PVH stuff into a series to go in sooner?
> 
> My plan right now was to wait for Mukesh to repost his series (which
> I hope will address all our review comments) and then I can shovel
> any other patches on top of that.
> 
> But if it makes sense to intermix Mukeshes's patchs, and yours.
> (or squash some together) I can do that too.

Ok, I'm all done with changes. Doing final testing now, and will have 
patches sent by Tues afternoon.

thanks,
Mukesh


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 01:16:39 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 01:16:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLOQe-0003Vz-Ek; Tue, 09 Oct 2012 01:16:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLOQc-0003Vs-WA
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 01:16:11 +0000
Received: from [85.158.139.211:49266] by server-10.bemta-5.messagelabs.com id
	2A/5E-16911-ADA73705; Tue, 09 Oct 2012 01:16:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1349745369!21541162!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMyNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14373 invoked from network); 9 Oct 2012 01:16:09 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 01:16:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,556,1344211200"; d="scan'208";a="15024309"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 01:16:09 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 9 Oct 2012 02:16:09 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TLOQa-0005k6-VY;
	Tue, 09 Oct 2012 01:16:09 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TLOQa-0005gv-HG;
	Tue, 09 Oct 2012 02:16:08 +0100
To: 
Message-ID: 
From: xen.org 
Date: Tue, 9 Oct 2012 02:16:08 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13940: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13940 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13940/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 13932
 build-i386                    4 xen-build                 fail REGR. vs. 13932

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13932
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13932
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13932
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13932

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  c9f621893a05
baseline version:
 xen                  099589002239

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD 
  Ian Campbell 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Samuel Thibault 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26017:c9f621893a05
tag:         tip
user:        Matthew Fioravante 
date:        Mon Oct 08 14:36:31 2012 +0100
    
    minios: setup fpu and sse in mini-os
    
    This patch adds floating point and sse support to mini-os by
    initializing the floating point unit and the see unit during
    domain boot up.
    
    Signed-off-by: Matthew Fioravante 
    Acked-by: Samuel Thibault 
    Committed-by: Ian Campbell 
    
    
changeset:   26016:865626fc7004
user:        Matthew Fioravante 
date:        Mon Oct 08 14:36:31 2012 +0100
    
    minios: add CONFIG_XC conditional
    
    This patch adds a CONFIG_XC option to mini-os, to allow conditional
    support for libxc for mini-os domains.
    
    Signed-off-by: Matthew Fioravante 
    Acked-by: Samuel Thibault 
    Committed-by: Ian Campbell 
    
    
changeset:   26015:42ca0ed31aa6
user:        Matthew Fioravante 
date:        Mon Oct 08 14:36:30 2012 +0100
    
    minios: Disable the mfn_is_ram() check, it doesn't work correctly on all systems
    
    This patch disables the mfn_is_ram check in mini-os. The current check
    is insufficient and fails on some systems with larger than 4gb memory.
    
    Signed-off-by: Matthew Fioravante 
    Acked-by: Samuel Thibault 
    Committed-by: Ian Campbell 
    
    
changeset:   26014:8fdb8d464ece
user:        Matthew Fioravante 
date:        Mon Oct 08 14:36:29 2012 +0100
    
    minios: Add endian, byteswap, and wordsize macros to mini-os
    
    This patch addes byte swapping macros and endian support to mini-os.
    
    Signed-off-by: Matthew Fioravante 
    Acked-by: Samuel Thibault 
    Committed-by: Ian Campbell 
    
    
changeset:   26013:a797d59e1d29
user:        Matthew Fioravante 
date:        Mon Oct 08 14:36:28 2012 +0100
    
    minios: Add ioread/iowrite functions to mini-os
    
    This patch adds iowritexx() and ioreadxx() functions for interacting
    with hardware memory to mini-os. The functions are available in a header
    iorw.h
    
    Signed-off-by: Matthew Fioravante 
    Acked-by: Samuel Thibault 
    Reviewed-by: George Dunlap 
    Committed-by: Ian Campbell 
    
    
changeset:   26012:02e744da52c9
user:        Olaf Hering 
date:        Mon Oct 08 12:18:35 2012 +0100
    
    tools/configure.ac: fill PACKAGE_TARNAME in AC_INIT
    
    Upcoming changes may move DOCDIR from Config.mk to config/Tools.mk. To
    preserve the currently used path, which ends with /xen, specify a value
    for PACKAGE_TARNAME. Without this change the path would end with
    /xen-hypervisor.
    
    Please rerun autoconf after applying this.
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26011:b6fb4e63b946
user:        Olaf Hering 
date:        Mon Oct 08 12:18:34 2012 +0100
    
    stubdom: fix parallel build by expanding CROSS_MAKE
    
    Recently I changed my rpm xen.spec file from doing
    'make -C tools -j N && make stubdom' to 'make -j N stubdom' because
    stubdom depends on tools, so both get built.
    The result was the failure below.
    
    ....
    mkdir -p grub-x86_64
    CPPFLAGS="-isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include -D__MINIOS__ -DHAVE_LIBC -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include/posix -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../tools/xenstore  -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include/x86 -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include/x86/x86_64 -U __linux__ -U __FreeBSD__ -U __sun__ -nostdinc -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include/posix -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/cross-root-x86_64/x86_64-xen-elf/include -isystem /usr/lib64/gcc/x86_64-suse-linux/4.7/include -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/lwip-x86_64/src/include -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/lwip-x86_64/src/include/ipv4 -I/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/include -I/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../xen/include" CFLAGS="-mno-red-zone -O1 -fno-omit-frame-pointer  -m64 -mno-red-zone -fno-reorder-blocks -fno-asynchronous-unwind-tables -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable   -fno-stack-protector -fno-exceptions" make DESTDIR= -C grub OBJ_DIR=/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/grub-x86_64
    make[2]: Entering directory `/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/grub'
    make[2]: warning: jobserver unavailable: using -j1.  Add `+' to parent make rule.
    make[2]: *** INTERNAL: readdir: Bad file descriptor
    .  Stop.
    make[2]: Makefile: Field 'stem' not cached: Makefile
    
    make[2]: Leaving directory `/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/grub'
    make[1]: *** [grub] Error 2
    [ -d mini-os-x86_64-xenstore ] || \
    for i in $(cd /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os ; find . -type d) ; do \
                    mkdir -p mini-os-x86_64-xenstore/$i ; \
    done
    ....
    
    Expanding every occurrence of CROSS_MAKE avoids this error. It also has
    the nice side effect of actually enabling parallel build for stubdom.
    According to the GNU make documentation $(MAKE) gets its special meaning
    only if it appears directly in the recipe:
    
    http://www.gnu.org/software/make/manual/html_node/MAKE-Variable.html
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26010:cff10030c6ea
user:        Olaf Hering 
date:        Mon Oct 08 12:18:33 2012 +0100
    
    xend/pvscsi: update sysfs parser for Linux 3.0
    
    The sysfs parser for /sys/bus/scsi/devices understands only the layout
    of kernel version 2.6.16. This looks as follows:
    
    /sys/bus/scsi/devices/1:0:0:0/block:sda is a symlink to /sys/block/sda/
    /sys/bus/scsi/devices/1:0:0:0/scsi_generic:sg1 is a symlink to /sys/class/scsi_generic/sg1
    
    Both directories contain a 'dev' file with the major:minor information.
    This patch updates the used regex strings to match also the colon to
    make it more robust against possible future changes.
    
    In kernel version 3.0 the layout changed:
    /sys/bus/scsi/devices/ contains now additional symlinks to directories
    such as host1 and target1:0:0. This patch ignores these as they do not
    point to the desired scsi devices. They just clutter the devices array.
    
    The directory layout in '1:0:0:0' changed as well, the 'type:name'
    notation was replaced with 'type/name' directories:
    
    /sys/bus/scsi/devices/1:0:0:0/block/sda/
    /sys/bus/scsi/devices/1:0:0:0/scsi_generic/sg1/
    
    Both directories contain a 'dev' file with the major:minor information.
    This patch adds additional code to walk the subdir to find the 'dev'
    file to make sure the given subdirectory is really the kernel name.
    
    In addition this patch makes sure devname is not None.
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26009:2dbfa4d2e107
user:        Olaf Hering 
date:        Mon Oct 08 12:18:32 2012 +0100
    
    xend/pvscsi: fix usage of persistant device names for SCSI devices
    
    Currently the callers of vscsi_get_scsidevices() do not pass a mask
    string.  This will call "lsscsi -g '[]'", which causes a lsscsi syntax
    error. As a result the sysfs parser _vscsi_get_scsidevices() is used.
    But this parser is broken and the specified names in the config file are
    not found.
    
    Using a mask '*' if no mask was given will call lsscsi correctly and the
    following config is parsed correctly:
    
    vscsi=[
    	'/dev/sg3, 0:0:0:0',
    	'/dev/disk/by-id/wwn-0x600508b4000cf1c30000800000410000, 0:0:0:1'
    ]
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26008:eecb528583d7
user:        Olaf Hering 
date:        Mon Oct 08 12:18:31 2012 +0100
    
    xend/pvscsi: fix passing of SCSI control LUNs
    
    Currently pvscsi can not pass SCSI devices that have just a scsi_generic node.
    In the following example sg3 is a control LUN for the disk sdd.
    But vscsi=['4:0:2:0,0:0:0:0'] does not work because the internal 'devname'
    variable remains None. Later writing p-devname to xenstore fails because None
    is not a valid string variable.
    
    Since devname is used for just informational purpose use sg also as devname.
    
    carron:~ $ lsscsi -g
    [0:0:0:0]    disk    ATA      FK0032CAAZP      HPF2  /dev/sda   /dev/sg0
    [4:0:0:0]    disk    HP       P2000G3 FC/iSCSI T100  /dev/sdb   /dev/sg1
    [4:0:1:0]    disk    HP       P2000G3 FC/iSCSI T100  /dev/sdc   /dev/sg2
    [4:0:2:0]    storage HP       HSV400           0950  -         /dev/sg3
    [4:0:2:1]    disk    HP       HSV400           0950  /dev/sdd   /dev/sg4
    [4:0:3:0]    storage HP       HSV400           0950  -         /dev/sg5
    [4:0:3:1]    disk    HP       HSV400           0950  /dev/sde   /dev/sg6
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26007:fe756682cc7f
user:        Olaf Hering 
date:        Mon Oct 08 12:18:31 2012 +0100
    
    xenballoond.init: remove 4 from default runlevel
    
    Remove 4 from default runlevel in xenballoond.init.
    
    Similar to what changeset 24847:0900b1c905f1 does in xencommons, remove
    runlevel 4 from the other runlevel scripts. LSB defines runlevel 4 as
    reserved for local use, the local sysadmin is responsible for symlink
    creation in rc4.d.
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26006:8b6870d686d6
user:        Olaf Hering 
date:        Mon Oct 08 12:18:30 2012 +0100
    
    hotplug/Linux: Remove tracing (bash -x) from network-nat script
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26005:cdb48f1742f3
user:        Roger Pau Monne 
date:        Mon Oct 08 12:18:29 2012 +0100
    
    autoconf: add -Werror to libutil.h header check
    
    libutil.h is only needed on BSDs, but not in Linux. Debian package
    libbsd-dev-0.3.0-1 installed a libutil.h overlay that contains a
    
    Perform the libutil.h check with -Werror, so we don't include this
    bogus header.
    
    Signed-off-by: Roger Pau Monne 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26004:099589002239
user:        Anthony PERARD 
date:        Mon Oct 08 11:45:36 2012 +0100
    
    libxl: Allow migration with qemu-xen.
    
    Signed-off-by: Anthony PERARD 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 01:16:39 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 01:16:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLOQe-0003Vz-Ek; Tue, 09 Oct 2012 01:16:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLOQc-0003Vs-WA
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 01:16:11 +0000
Received: from [85.158.139.211:49266] by server-10.bemta-5.messagelabs.com id
	2A/5E-16911-ADA73705; Tue, 09 Oct 2012 01:16:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1349745369!21541162!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMyNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14373 invoked from network); 9 Oct 2012 01:16:09 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 01:16:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,556,1344211200"; d="scan'208";a="15024309"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 01:16:09 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 9 Oct 2012 02:16:09 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TLOQa-0005k6-VY;
	Tue, 09 Oct 2012 01:16:09 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TLOQa-0005gv-HG;
	Tue, 09 Oct 2012 02:16:08 +0100
To: 
Message-ID: 
From: xen.org 
Date: Tue, 9 Oct 2012 02:16:08 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13940: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13940 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13940/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 13932
 build-i386                    4 xen-build                 fail REGR. vs. 13932

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13932
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13932
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13932
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13932

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  c9f621893a05
baseline version:
 xen                  099589002239

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD 
  Ian Campbell 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Samuel Thibault 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26017:c9f621893a05
tag:         tip
user:        Matthew Fioravante 
date:        Mon Oct 08 14:36:31 2012 +0100
    
    minios: setup fpu and sse in mini-os
    
    This patch adds floating point and sse support to mini-os by
    initializing the floating point unit and the see unit during
    domain boot up.
    
    Signed-off-by: Matthew Fioravante 
    Acked-by: Samuel Thibault 
    Committed-by: Ian Campbell 
    
    
changeset:   26016:865626fc7004
user:        Matthew Fioravante 
date:        Mon Oct 08 14:36:31 2012 +0100
    
    minios: add CONFIG_XC conditional
    
    This patch adds a CONFIG_XC option to mini-os, to allow conditional
    support for libxc for mini-os domains.
    
    Signed-off-by: Matthew Fioravante 
    Acked-by: Samuel Thibault 
    Committed-by: Ian Campbell 
    
    
changeset:   26015:42ca0ed31aa6
user:        Matthew Fioravante 
date:        Mon Oct 08 14:36:30 2012 +0100
    
    minios: Disable the mfn_is_ram() check, it doesn't work correctly on all systems
    
    This patch disables the mfn_is_ram check in mini-os. The current check
    is insufficient and fails on some systems with larger than 4gb memory.
    
    Signed-off-by: Matthew Fioravante 
    Acked-by: Samuel Thibault 
    Committed-by: Ian Campbell 
    
    
changeset:   26014:8fdb8d464ece
user:        Matthew Fioravante 
date:        Mon Oct 08 14:36:29 2012 +0100
    
    minios: Add endian, byteswap, and wordsize macros to mini-os
    
    This patch addes byte swapping macros and endian support to mini-os.
    
    Signed-off-by: Matthew Fioravante 
    Acked-by: Samuel Thibault 
    Committed-by: Ian Campbell 
    
    
changeset:   26013:a797d59e1d29
user:        Matthew Fioravante 
date:        Mon Oct 08 14:36:28 2012 +0100
    
    minios: Add ioread/iowrite functions to mini-os
    
    This patch adds iowritexx() and ioreadxx() functions for interacting
    with hardware memory to mini-os. The functions are available in a header
    iorw.h
    
    Signed-off-by: Matthew Fioravante 
    Acked-by: Samuel Thibault 
    Reviewed-by: George Dunlap 
    Committed-by: Ian Campbell 
    
    
changeset:   26012:02e744da52c9
user:        Olaf Hering 
date:        Mon Oct 08 12:18:35 2012 +0100
    
    tools/configure.ac: fill PACKAGE_TARNAME in AC_INIT
    
    Upcoming changes may move DOCDIR from Config.mk to config/Tools.mk. To
    preserve the currently used path, which ends with /xen, specify a value
    for PACKAGE_TARNAME. Without this change the path would end with
    /xen-hypervisor.
    
    Please rerun autoconf after applying this.
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26011:b6fb4e63b946
user:        Olaf Hering 
date:        Mon Oct 08 12:18:34 2012 +0100
    
    stubdom: fix parallel build by expanding CROSS_MAKE
    
    Recently I changed my rpm xen.spec file from doing
    'make -C tools -j N && make stubdom' to 'make -j N stubdom' because
    stubdom depends on tools, so both get built.
    The result was the failure below.
    
    ....
    mkdir -p grub-x86_64
    CPPFLAGS="-isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include -D__MINIOS__ -DHAVE_LIBC -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include/posix -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../tools/xenstore  -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include/x86 -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include/x86/x86_64 -U __linux__ -U __FreeBSD__ -U __sun__ -nostdinc -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include/posix -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/cross-root-x86_64/x86_64-xen-elf/include -isystem /usr/lib64/gcc/x86_64-suse-linux/4.7/include -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/lwip-x86_64/src/include -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/lwip-x86_64/src/include/ipv4 -I/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/include -I/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../xen/include" CFLAGS="-mno-red-zone -O1 -fno-omit-frame-pointer  -m64 -mno-red-zone -fno-reorder-blocks -fno-asynchronous-unwind-tables -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable   -fno-stack-protector -fno-exceptions" make DESTDIR= -C grub OBJ_DIR=/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/grub-x86_64
    make[2]: Entering directory `/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/grub'
    make[2]: warning: jobserver unavailable: using -j1.  Add `+' to parent make rule.
    make[2]: *** INTERNAL: readdir: Bad file descriptor
    .  Stop.
    make[2]: Makefile: Field 'stem' not cached: Makefile
    
    make[2]: Leaving directory `/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/grub'
    make[1]: *** [grub] Error 2
    [ -d mini-os-x86_64-xenstore ] || \
    for i in $(cd /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os ; find . -type d) ; do \
                    mkdir -p mini-os-x86_64-xenstore/$i ; \
    done
    ....
    
    Expanding every occurrence of CROSS_MAKE avoids this error. It also has
    the nice side effect of actually enabling parallel build for stubdom.
    According to the GNU make documentation $(MAKE) gets its special meaning
    only if it appears directly in the recipe:
    
    http://www.gnu.org/software/make/manual/html_node/MAKE-Variable.html
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26010:cff10030c6ea
user:        Olaf Hering 
date:        Mon Oct 08 12:18:33 2012 +0100
    
    xend/pvscsi: update sysfs parser for Linux 3.0
    
    The sysfs parser for /sys/bus/scsi/devices understands only the layout
    of kernel version 2.6.16. This looks as follows:
    
    /sys/bus/scsi/devices/1:0:0:0/block:sda is a symlink to /sys/block/sda/
    /sys/bus/scsi/devices/1:0:0:0/scsi_generic:sg1 is a symlink to /sys/class/scsi_generic/sg1
    
    Both directories contain a 'dev' file with the major:minor information.
    This patch updates the used regex strings to match also the colon to
    make it more robust against possible future changes.
    
    In kernel version 3.0 the layout changed:
    /sys/bus/scsi/devices/ contains now additional symlinks to directories
    such as host1 and target1:0:0. This patch ignores these as they do not
    point to the desired scsi devices. They just clutter the devices array.
    
    The directory layout in '1:0:0:0' changed as well, the 'type:name'
    notation was replaced with 'type/name' directories:
    
    /sys/bus/scsi/devices/1:0:0:0/block/sda/
    /sys/bus/scsi/devices/1:0:0:0/scsi_generic/sg1/
    
    Both directories contain a 'dev' file with the major:minor information.
    This patch adds additional code to walk the subdir to find the 'dev'
    file to make sure the given subdirectory is really the kernel name.
    
    In addition this patch makes sure devname is not None.
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26009:2dbfa4d2e107
user:        Olaf Hering 
date:        Mon Oct 08 12:18:32 2012 +0100
    
    xend/pvscsi: fix usage of persistant device names for SCSI devices
    
    Currently the callers of vscsi_get_scsidevices() do not pass a mask
    string.  This will call "lsscsi -g '[]'", which causes a lsscsi syntax
    error. As a result the sysfs parser _vscsi_get_scsidevices() is used.
    But this parser is broken and the specified names in the config file are
    not found.
    
    Using a mask '*' if no mask was given will call lsscsi correctly and the
    following config is parsed correctly:
    
    vscsi=[
    	'/dev/sg3, 0:0:0:0',
    	'/dev/disk/by-id/wwn-0x600508b4000cf1c30000800000410000, 0:0:0:1'
    ]
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26008:eecb528583d7
user:        Olaf Hering 
date:        Mon Oct 08 12:18:31 2012 +0100
    
    xend/pvscsi: fix passing of SCSI control LUNs
    
    Currently pvscsi can not pass SCSI devices that have just a scsi_generic node.
    In the following example sg3 is a control LUN for the disk sdd.
    But vscsi=['4:0:2:0,0:0:0:0'] does not work because the internal 'devname'
    variable remains None. Later writing p-devname to xenstore fails because None
    is not a valid string variable.
    
    Since devname is used for just informational purpose use sg also as devname.
    
    carron:~ $ lsscsi -g
    [0:0:0:0]    disk    ATA      FK0032CAAZP      HPF2  /dev/sda   /dev/sg0
    [4:0:0:0]    disk    HP       P2000G3 FC/iSCSI T100  /dev/sdb   /dev/sg1
    [4:0:1:0]    disk    HP       P2000G3 FC/iSCSI T100  /dev/sdc   /dev/sg2
    [4:0:2:0]    storage HP       HSV400           0950  -         /dev/sg3
    [4:0:2:1]    disk    HP       HSV400           0950  /dev/sdd   /dev/sg4
    [4:0:3:0]    storage HP       HSV400           0950  -         /dev/sg5
    [4:0:3:1]    disk    HP       HSV400           0950  /dev/sde   /dev/sg6
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26007:fe756682cc7f
user:        Olaf Hering 
date:        Mon Oct 08 12:18:31 2012 +0100
    
    xenballoond.init: remove 4 from default runlevel
    
    Remove 4 from default runlevel in xenballoond.init.
    
    Similar to what changeset 24847:0900b1c905f1 does in xencommons, remove
    runlevel 4 from the other runlevel scripts. LSB defines runlevel 4 as
    reserved for local use, the local sysadmin is responsible for symlink
    creation in rc4.d.
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26006:8b6870d686d6
user:        Olaf Hering 
date:        Mon Oct 08 12:18:30 2012 +0100
    
    hotplug/Linux: Remove tracing (bash -x) from network-nat script
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26005:cdb48f1742f3
user:        Roger Pau Monne 
date:        Mon Oct 08 12:18:29 2012 +0100
    
    autoconf: add -Werror to libutil.h header check
    
    libutil.h is only needed on BSDs, but not in Linux. Debian package
    libbsd-dev-0.3.0-1 installed a libutil.h overlay that contains a
    
    Perform the libutil.h check with -Werror, so we don't include this
    bogus header.
    
    Signed-off-by: Roger Pau Monne 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26004:099589002239
user:        Anthony PERARD 
date:        Mon Oct 08 11:45:36 2012 +0100
    
    libxl: Allow migration with qemu-xen.
    
    Signed-off-by: Anthony PERARD 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 02:25:13 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 02:25:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLPUs-000486-LS; Tue, 09 Oct 2012 02:24:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLPUq-000481-H7
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 02:24:36 +0000
Received: from [85.158.138.51:33862] by server-2.bemta-3.messagelabs.com id
	4E/DF-16514-3EA83705; Tue, 09 Oct 2012 02:24:35 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-7.tower-174.messagelabs.com!1349749473!24719844!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11176 invoked from network); 9 Oct 2012 02:24:33 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-7.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	9 Oct 2012 02:24:33 -0000
Received: from 50-66-ftth.onsneteindhoven.nl ([88.159.66.50]:58791
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TLPW0-0006t2-OA; Tue, 09 Oct 2012 04:25:48 +0200
Date: Tue, 9 Oct 2012 04:24:24 +0200
From: Sander Eikelenboom 
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <120335733.20121009042424@eikelenboom.it>
To: Ian Campbell 
In-Reply-To: <1349686461.18008.18.camel@zakaz.uk.xensource.com>
References: 
	<729626082.20121006002054@eikelenboom.it>
	<20121007233444.GA26929@localhost.localdomain>
	<1349686461.18008.18.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk ,
	"xen-devel@lists.xensource.com" ,
	konrad 
Subject: Re: [Xen-devel] Kernel 3.7.0-pre-rc1 kernel BUG at
	drivers/net/xen-netback/netback.c:405 RIP:
	e030:[] []
	netbk_gop_frag_copy+0x379/0x380
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Monday, October 8, 2012, 10:54:21 AM, you wrote:

> On Mon, 2012-10-08 at 00:34 +0100, Konrad Rzeszutek Wilk wrote:
>> On Sat, Oct 06, 2012 at 12:20:54AM +0200, Sander Eikelenboom wrote:
>> > 
>> > Friday, October 5, 2012, 9:26:31 PM, you wrote:
>> > 
>> > > Sorry for top posting - on mobile.
>> > 
>> > > I saw it too yesterday but only on a specific hardware - AMD FX8. What type of CPU do you have?  Does xsave=off on Xen line help?
>> > 
>> > Nope the xsave=off doesn't help
>> > 
>> > > Sander Eikelenboom  wrote:
>> > 
>> > >>Hi Konrad,
>> > >>
>> > >>Just tested kernel 3.7.0-pre-rc1 but ran into a oops in netback on boot after starting some guests:
>> > >>
>> > >>[  402.723915] ------------[ cut here ]------------
>> > >>[  402.734629] kernel BUG at drivers/net/xen-netback/netback.c:405!
>> 
>> Looking at the code, this is what we get:
>> 
>>         /* Data must not cross a page boundary. */
>>         BUG_ON(size + offset > PAGE_SIZE);
>> 
>> Looking at the commits, the one recently added was:
>> commit c571898ffc24a1768e1b2dabeac0fc7dd4c14601
>> Author: Andres Lagar-Cavilla 
>> Date:   Fri Sep 14 14:26:59 2012 +0000
>> 
>>     xen/gndev: Xen backend support for paged out grant targets V4.
>>     
>> 
>> But after reverting it and trying the kernel I still got the crash.
>> 
>> So .. the weirdness is that this seems to be only happening on
>> certain AMD machines - for example on my AMD A8 box I did not see this.

> I took a look at this last week and can't repro.

> The code which calls this function is supposed to ensure that the buffer
> doesn't cross a page boundary.

> There are two places which call it, one is looping over the skb's frags,
> which just can't cross page boundaries and if they did it would be
> breaking left and right for everyone AFAICT (although I'm very behind on
> my LKML and netdev reading, so maybe it is ;-)).

> The other case is processing the SKB's linear data area, which can cross
> a page boundary but the code loops over it and processes it in chunks
> which fit in single pages. I was suspicious of this code so I pulled it
> out into a little userspace test harness and fed it some corner cases
> but it looked like it was doing the right thing.

> I speculated that this might be NIC rather than processor related
> (perhaps there's some weak correlation between certain NICs and certain
> processor manufacturers).

> Konrad seems to have an r8169 but the module list wasn't in Sander's
> output -- do you know what you have?

>> I fear that the next step is to do a bit off git bisection to
>> get an idea of which merge it might be. I am going to be AFK
>> on Monday so I won't get to this until Tuesday/Wednesay :-(
>> 
>> .. Thought to help speed this process, this looks like a
>> candidate:
>> 
>> commit 229993001282e128a49a59ec43d255614775703a
>> Merge: 7687b80 fd0f586
>> Author: Linus Torvalds 
>> Date:   Mon Oct 1 11:13:33 2012 -0700
>> 
>>     Merge branch 'x86-mm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
>>     
>>     Pull x86/mm changes from Ingo Molnar:
>>      "The biggest change is new TLB partial flushing code for AMD CPUs.
>>       (The v3.6 kernel had the Intel CPU side code, see commits
>>       e0ba94f14f74..effee4b9b3b.)

> Would be interesting to try although I don't think anything in this area
> is actively messing with page table mappings (that happens later, and
> doesn't effect the non-data bits of the skb like the sizes and offsets).

> Perhaps this debug patch might shed some light? PG_compound or THP might
> be an interesting case?

After applying the debug patch:

[  197.876304] netbk_gop_frag_copy failed: skb frag 0 page
[  197.884299] copying from offset 0, len 1628
[  197.892781] page:ffffea0000b18400 count:3 mapcount:0 mapping:          (null) index:0x0
[  197.900778] page flags: 0x40000000004000(head)
[  197.907074] ------------[ cut here ]------------
[  197.913345] kernel BUG at drivers/net/xen-netback/netback.c:546!
[  197.919626] invalid opcode: 0000 [#1] PREEMPT SMP 
[  197.921573] xen_bridge: port 10(vif10.0) entered forwarding state
[  197.932106] Modules linked in:
[  197.938370] CPU 0 
[  197.938420] Pid: 1180, comm: netback/0 Not tainted 3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)  
[  197.951203] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
[  197.957775] RSP: e02b:ffff880037911c20  EFLAGS: 00010282
[  197.964290] RAX: 0000000000000001 RBX: ffff880036862ee0 RCX: 0000000000000000
[  197.970956] RDX: 0000000000000001 RSI: 0000000000000001 RDI: ffff8800379102b0
[  197.977679] RBP: ffff880037911d50 R08: 0000000000000002 R09: 0000000000000000
[  197.984361] R10: 0000000000000001 R11: ffff880039925e40 R12: 0000000000000030
[  197.990958] R13: 0000000000000000 R14: ffff880031e71800 R15: 0000000000000001
[  197.997459] FS:  00007fb5dfcf7700(0000) GS:ffff88003f800000(0000) knlGS:0000000000000000
[  198.004123] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[  198.010827] CR2: 00007fb5d802d000 CR3: 0000000031fd3000 CR4: 0000000000000660
[  198.017534] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  198.024168] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  198.030717] Process netback/0 (pid: 1180, threadinfo ffff880037910000, task ffff88003997d190)
[  198.037326] Stack:
[  198.043817]  ffff880037911d1c ffff88003997d840 ffff880037911d00 ffff880037911c80
[  198.050573]  ffffffff00000001 0000000000000662 ffffc90010824bb8 ffffc90010820050
[  198.057413]  0000000001080083 ffffc90010820000 0000000000000000 ffff880031cf09c0
[  198.064228] Call Trace:
[  198.070887]  [] ? trace_hardirqs_on+0xd/0x10
[  198.077604]  [] xen_netbk_kthread+0xba/0xa90
[  198.084394]  [] ? try_to_wake_up+0x1b6/0x310
[  198.091109]  [] ? wake_up_bit+0x40/0x40
[  198.097726]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
[  198.104343]  [] kthread+0xd6/0xe0
[  198.111001]  [] kernel_thread_helper+0x4/0x10
[  198.117737]  [] ? retint_restore_args+0x13/0x13
[  198.124425]  [] ? gs_change+0x13/0x13
[  198.131008] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 46 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7 
[  198.145094] RIP  [] xen_netbk_rx_action+0x89a/0x910
[  198.152192]  RSP 
[  198.159344] ---[ end trace cbdd0e4e80268fa8 ]---
[  199.703539] tty_init_dev: 2 callbacks suppressed
[  200.712098] device vif12.0 entered promiscuous mode
[  201.010433] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
[  201.020644] xen_bridge: port 12(vif12.0) entered forwarding state
[  201.027833] xen_bridge: port 12(vif12.0) entered forwarding state
[  206.774576] netbk_gop_frag_copy failed: skb frag 0 page
[  206.777945] device vif13.0 entered promiscuous mode
[  206.788845] copying from offset 1ba4, len 2c1
[  206.795791] page:ffffea0000b18400 count:6 mapcount:0 mapping:          (null) index:0x0
[  206.802771] page flags: 0x40000000004000(head)
[  206.809619] ------------[ cut here ]------------
[  206.816498] kernel BUG at drivers/net/xen-netback/netback.c:546!
[  206.823465] invalid opcode: 0000 [#2] PREEMPT SMP 
[  206.830354] Modules linked in:
[  206.837176] CPU 3 
[  206.837234] Pid: 1183, comm: netback/3 Tainted: G      D      3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)  
[  206.850881] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
[  206.857935] RSP: e02b:ffff880037917c20  EFLAGS: 00010282
[  206.864972] RAX: 0000000000000001 RBX: ffff880003313ae0 RCX: 0000000000000000
[  206.872049] RDX: ffff88003997b0f0 RSI: 0000000000000001 RDI: ffff8800379102b0
[  206.879147] RBP: ffff880037917d50 R08: 0000000000000002 R09: 0000000000000000
[  206.886242] R10: 0000000000000001 R11: ffff880039925640 R12: 0000000000000030
[  206.893163] R13: 0000000000000000 R14: ffff88002c7c4400 R15: 0000000000000001
[  206.900041] FS:  00007f800341a700(0000) GS:ffff88003f8c0000(0000) knlGS:0000000000000000
[  206.907145] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[  206.914126] CR2: 00007f8002b31fb0 CR3: 0000000001c0b000 CR4: 0000000000000660
[  206.921181] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  206.927996] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  206.934711] Process netback/3 (pid: 1183, threadinfo ffff880037916000, task ffff88003997b0f0)
[  206.941494] Stack:
[  206.948105]  ffff880037917d1c ffff880037916010 ffff880037917d00 ffff880037917c80
[  206.955062]  ffffffff810800b5 00000000000000ba ffffc900108466e0 ffffc90010841b78
[  206.962007]  0000000101080083 ffffc90010841b28 0000000100000000 ffff88002c5bb9c0
[  206.968967] Call Trace:
[  206.975830]  [] ? __alloc_workqueue_key+0x265/0x5d0
[  206.982789]  [] ? trace_hardirqs_on+0xd/0x10
[  206.989662]  [] xen_netbk_kthread+0xba/0xa90
[  206.996570]  [] ? try_to_wake_up+0x1b6/0x310
[  207.003523]  [] ? wake_up_bit+0x40/0x40
[  207.010333]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
[  207.017171]  [] kthread+0xd6/0xe0
[  207.023890]  [] kernel_thread_helper+0x4/0x10
[  207.030540]  [] ? retint_restore_args+0x13/0x13
[  207.037275]  [] ? gs_change+0x13/0x13
[  207.043890] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 46 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7 
[  207.057976] RIP  [] xen_netbk_rx_action+0x89a/0x910
[  207.065064]  RSP 
[  207.072056] ---[ end trace cbdd0e4e80268fa9 ]---
[  207.079366] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
[  207.090256] vpn_bridge: port 1(vif13.0) entered forwarding state
[  207.097403] vpn_bridge: port 1(vif13.0) entered forwarding state
[  208.636257] xen_bridge: port 11(vif11.0) entered forwarding state
[  211.515779] netbk_gop_frag_copy failed: skb frag 0 page
[  211.522711] copying from offset 2126, len 2c1
[  211.529403] page:ffffea0000b18400 count:8 mapcount:0 mapping:          (null) index:0x0
[  211.536142] page flags: 0x40000000004000(head)
[  211.542942] ------------[ cut here ]------------
[  211.549664] kernel BUG at drivers/net/xen-netback/netback.c:546!
[  211.556408] invalid opcode: 0000 [#3] PREEMPT SMP 
[  211.563168] Modules linked in:
[  211.569739] CPU 4 
[  211.569789] Pid: 1184, comm: netback/4 Tainted: G      D      3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)  
[  211.583126] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
[  211.590041] RSP: e02b:ffff880037921c20  EFLAGS: 00010282
[  211.596868] RAX: 0000000000000001 RBX: ffff8800375bc4e0 RCX: 0000000000000000
[  211.603890] RDX: ffff88003997a0a0 RSI: 0000000000000001 RDI: ffff8800379202b0
[  211.610792] RBP: ffff880037921d50 R08: 0000000000000002 R09: 0000000000000000
[  211.617608] R10: 0000000000000001 R11: ffff8800399249e0 R12: 0000000000000030
[  211.624537] R13: 0000000000000000 R14: ffff88002b98d400 R15: 0000000000000001
[  211.631302] FS:  00007f332d735740(0000) GS:ffff88003f900000(0000) knlGS:0000000000000000
[  211.638090] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[  211.644965] CR2: 00007f1023d22000 CR3: 0000000031fba000 CR4: 0000000000000660
[  211.651894] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  211.658652] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  211.665288] Process netback/4 (pid: 1184, threadinfo ffff880037920000, task ffff88003997a0a0)
[  211.671884] Stack:
[  211.678376]  ffff880037921d1c ffff880037920010 ffff880037921d00 ffff880037921c80
[  211.685145]  ffffffff810800b5 00000000000000ba ffffc90010851a98 ffffc9001084cf30
[  211.691837]  0000000101080083 ffffc9001084cee0 0000000100000000 ffff88002c5bd9c0
[  211.698581] Call Trace:
[  211.705349]  [] ? __alloc_workqueue_key+0x265/0x5d0
[  211.712156]  [] ? trace_hardirqs_on+0xd/0x10
[  211.718907]  [] xen_netbk_kthread+0xba/0xa90
[  211.725654]  [] ? try_to_wake_up+0x1b6/0x310
[  211.732369]  [] ? wake_up_bit+0x40/0x40
[  211.739111]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
[  211.745858]  [] kthread+0xd6/0xe0
[  211.752449]  [] kernel_thread_helper+0x4/0x10
[  211.758975]  [] ? retint_restore_args+0x13/0x13
[  211.765575]  [] ? gs_change+0x13/0x13
[  211.772016] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 46 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7 
[  211.785816] RIP  [] xen_netbk_rx_action+0x89a/0x910
[  211.792586]  RSP 
[  211.799394] ---[ end trace cbdd0e4e80268faa ]---
[  212.852714] device vif14.0 entered promiscuous mode
[  213.234995] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
[  213.245054] xen_bridge: port 13(vif14.0) entered forwarding state
[  213.252087] xen_bridge: port 13(vif14.0) entered forwarding state
[  214.691532] netbk_gop_frag_copy failed: skb frag 0 page
[  214.698515] copying from offset 26a8, len 2c1
[  214.705472] page:ffffea0000b18400 count:10 mapcount:0 mapping:          (null) index:0x0
[  214.712415] page flags: 0x40000000004000(head)
[  214.719170] ------------[ cut here ]------------
[  214.725887] kernel BUG at drivers/net/xen-netback/netback.c:546!
[  214.732563] invalid opcode: 0000 [#4] PREEMPT SMP 
[  214.739221] Modules linked in:
[  214.745808] CPU 5 
[  214.745859] Pid: 1185, comm: netback/5 Tainted: G      D      3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)  
[  214.759156] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
[  214.766127] RSP: e02b:ffff880037923c20  EFLAGS: 00010282
[  214.773012] RAX: 0000000000000001 RBX: ffff8800379172e0 RCX: 0000000000000000
[  214.780010] RDX: ffff880039ac8000 RSI: 0000000000000001 RDI: ffff8800379202b0
[  214.786988] RBP: ffff880037923d50 R08: 0000000000000002 R09: 0000000000000000
[  214.793870] R10: 0000000000000001 R11: ffff880039924460 R12: 0000000000000030
[  214.800812] R13: 0000000000000000 R14: ffff88002b8b4800 R15: 0000000000000001
[  214.807668] FS:  00007f236d331700(0000) GS:ffff88003f940000(0000) knlGS:0000000000000000
[  214.814545] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[  214.821415] CR2: 00007f236c42b6b0 CR3: 0000000039275000 CR4: 0000000000000660
[  214.828435] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  214.835337] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  214.841963] Process netback/5 (pid: 1185, threadinfo ffff880037922000, task ffff880039ac8000)
[  214.848655] Stack:
[  214.855220]  ffff880037923d1c ffff880037922010 ffff880037923d00 ffff880037923c80
[  214.861945]  ffffffff810800b5 00000000000000ba ffffc9001085ce50 ffffc900108582e8
[  214.868699]  0000000101080083 ffffc90010858298 0000000100000000 ffff880031e939c0
[  214.875477] Call Trace:
[  214.882247]  [] ? __alloc_workqueue_key+0x265/0x5d0
[  214.889083]  [] ? trace_hardirqs_on+0xd/0x10
[  214.895851]  [] xen_netbk_kthread+0xba/0xa90
[  214.902612]  [] ? try_to_wake_up+0x1b6/0x310
[  214.909343]  [] ? wake_up_bit+0x40/0x40
[  214.916115]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
[  214.922856]  [] kthread+0xd6/0xe0
[  214.929527]  [] kernel_thread_helper+0x4/0x10
[  214.936178]  [] ? retint_restore_args+0x13/0x13
[  214.942781]  [] ? gs_change+0x13/0x13
[  214.949279] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 46 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7 
[  214.963107] RIP  [] xen_netbk_rx_action+0x89a/0x910
[  214.969952]  RSP 
[  214.976802] ---[ end trace cbdd0e4e80268fab ]---
[  216.045946] xen_bridge: port 12(vif12.0) entered forwarding state
[  220.405869] device vif15.0 entered promiscuous mode
[  220.607946] device vif15.0-emu entered promiscuous mode
[  220.625075] xen_bridge: port 15(vif15.0-emu) entered forwarding state
[  220.633333] xen_bridge: port 15(vif15.0-emu) entered forwarding state
[  220.890237] pciback 0000:06:00.0: restoring config space at offset 0x3c (was 0x100, writing 0x10a)
[  220.898814] pciback 0000:06:00.0: restoring config space at offset 0x10 (was 0x4, writing 0xf9a00004)
[  220.907406] pciback 0000:06:00.0: restoring config space at offset 0xc (was 0x0, writing 0x10)
[  222.122750] vpn_bridge: port 1(vif13.0) entered forwarding state
[  225.943971] tty_init_dev: 14 callbacks suppressed
[  226.654618] device vif16.0 entered promiscuous mode
[  226.775073] device vif16.0-emu entered promiscuous mode
[  226.784025] xen_bridge: port 17(vif16.0-emu) entered forwarding state
[  226.790188] xen_bridge: port 17(vif16.0-emu) entered forwarding state
[  228.253024] xen_bridge: port 13(vif14.0) entered forwarding state
[  229.788197] xen_bridge: port 15(vif15.0-emu) entered disabled state
[  229.796826] xen_bridge: port 15(vif15.0-emu) entered disabled state
[  229.805243] device vif15.0-emu left promiscuous mode
[  229.813385] xen_bridge: port 15(vif15.0-emu) entered disabled state
[  231.558329] xen-blkback:ring-ref 8, event-channel 25, protocol 1 (x86_64-abi)
[  231.569080] xen-blkback:ring-ref 9, event-channel 26, protocol 1 (x86_64-abi)
[  231.609663] xen_bridge: port 14(vif15.0) entered forwarding state
[  231.617943] xen_bridge: port 14(vif15.0) entered forwarding state
[  231.934347] tty_init_dev: 25 callbacks suppressed






> Ian.

> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index 05593d8..ca4c47d 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -386,7 +386,7 @@ static struct netbk_rx_meta *get_next_rx_buffer(struct xenvif *vif,
>   * Set up the grant operations for this fragment. If it's a flipping
>   * interface, we also set up the unmap request from here.
>   */
> -static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
> +static int netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
>                                 struct netrx_pending_operations *npo,
>                                 struct page *page, unsigned long size,
>                                 unsigned long offset, int *head)
> @@ -402,7 +402,8 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
>         unsigned long bytes;
>  
>         /* Data must not cross a page boundary. */
> -       BUG_ON(size + offset > PAGE_SIZE);
> +       if (size + offset > PAGE_SIZE)
> +               return -1;
>  
>         meta = npo->meta + npo->meta_prod - 1;
>  
> @@ -459,6 +460,7 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
>                 *head = 0; /* There must be something in this buffer now. */
>  
>         }
> +       return 0;
>  }
>  
>  /*
> @@ -517,17 +519,31 @@ static int netbk_gop_skb(struct sk_buff *skb,
>                 if (data + len > skb_tail_pointer(skb))
>                         len = skb_tail_pointer(skb) - data;
>  
> -               netbk_gop_frag_copy(vif, skb, npo,
> -                                   virt_to_page(data), len, offset, &head);
> +               if (netbk_gop_frag_copy(vif, skb, npo,
> +                               virt_to_page(data), len, offset, &head) < 0) {
> +printk(KERN_CRIT "netbk_gop_frag_copy failed: skb head %p-%p\n",
+       skb->>data, skb_tail_pointer);
> +printk(KERN_CRIT "copying from %p-%p, offset %x, len %x\n",
> +       data, data+len, offset, len);
> +dump_page(virt_to_page(data));
> +BUG();
> +               }
>                 data += len;
>         }
>  
>         for (i = 0; i < nr_frags; i++) {
> -               netbk_gop_frag_copy(vif, skb, npo,
> +               if (netbk_gop_frag_copy(vif, skb, npo,
>                                     skb_frag_page(&skb_shinfo(skb)->frags[i]),
>                                     skb_frag_size(&skb_shinfo(skb)->frags[i]),
>                                     skb_shinfo(skb)->frags[i].page_offset,
> -                                   &head);
> +                                   &head) < 0) {
> +printk(KERN_CRIT "netbk_gop_frag_copy failed: skb frag %d page\n", i);
> +printk(KERN_CRIT "copying from offset %x, len %x\n",
> +       skb_shinfo(skb)->frags[i].page_offset,
> +       skb_frag_size(&skb_shinfo(skb)->frags[i]));
> +dump_page(skb_frag_page(&skb_shinfo(skb)->frags[i]));
> +BUG();
> +               }
>         }
>  
>         return npo->meta_prod - old_meta_prod;





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 02:25:13 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 02:25:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLPUs-000486-LS; Tue, 09 Oct 2012 02:24:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLPUq-000481-H7
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 02:24:36 +0000
Received: from [85.158.138.51:33862] by server-2.bemta-3.messagelabs.com id
	4E/DF-16514-3EA83705; Tue, 09 Oct 2012 02:24:35 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-7.tower-174.messagelabs.com!1349749473!24719844!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11176 invoked from network); 9 Oct 2012 02:24:33 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-7.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	9 Oct 2012 02:24:33 -0000
Received: from 50-66-ftth.onsneteindhoven.nl ([88.159.66.50]:58791
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TLPW0-0006t2-OA; Tue, 09 Oct 2012 04:25:48 +0200
Date: Tue, 9 Oct 2012 04:24:24 +0200
From: Sander Eikelenboom 
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <120335733.20121009042424@eikelenboom.it>
To: Ian Campbell 
In-Reply-To: <1349686461.18008.18.camel@zakaz.uk.xensource.com>
References: 
	<729626082.20121006002054@eikelenboom.it>
	<20121007233444.GA26929@localhost.localdomain>
	<1349686461.18008.18.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk ,
	"xen-devel@lists.xensource.com" ,
	konrad 
Subject: Re: [Xen-devel] Kernel 3.7.0-pre-rc1 kernel BUG at
	drivers/net/xen-netback/netback.c:405 RIP:
	e030:[] []
	netbk_gop_frag_copy+0x379/0x380
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Monday, October 8, 2012, 10:54:21 AM, you wrote:

> On Mon, 2012-10-08 at 00:34 +0100, Konrad Rzeszutek Wilk wrote:
>> On Sat, Oct 06, 2012 at 12:20:54AM +0200, Sander Eikelenboom wrote:
>> > 
>> > Friday, October 5, 2012, 9:26:31 PM, you wrote:
>> > 
>> > > Sorry for top posting - on mobile.
>> > 
>> > > I saw it too yesterday but only on a specific hardware - AMD FX8. What type of CPU do you have?  Does xsave=off on Xen line help?
>> > 
>> > Nope the xsave=off doesn't help
>> > 
>> > > Sander Eikelenboom  wrote:
>> > 
>> > >>Hi Konrad,
>> > >>
>> > >>Just tested kernel 3.7.0-pre-rc1 but ran into a oops in netback on boot after starting some guests:
>> > >>
>> > >>[  402.723915] ------------[ cut here ]------------
>> > >>[  402.734629] kernel BUG at drivers/net/xen-netback/netback.c:405!
>> 
>> Looking at the code, this is what we get:
>> 
>>         /* Data must not cross a page boundary. */
>>         BUG_ON(size + offset > PAGE_SIZE);
>> 
>> Looking at the commits, the one recently added was:
>> commit c571898ffc24a1768e1b2dabeac0fc7dd4c14601
>> Author: Andres Lagar-Cavilla 
>> Date:   Fri Sep 14 14:26:59 2012 +0000
>> 
>>     xen/gndev: Xen backend support for paged out grant targets V4.
>>     
>> 
>> But after reverting it and trying the kernel I still got the crash.
>> 
>> So .. the weirdness is that this seems to be only happening on
>> certain AMD machines - for example on my AMD A8 box I did not see this.

> I took a look at this last week and can't repro.

> The code which calls this function is supposed to ensure that the buffer
> doesn't cross a page boundary.

> There are two places which call it, one is looping over the skb's frags,
> which just can't cross page boundaries and if they did it would be
> breaking left and right for everyone AFAICT (although I'm very behind on
> my LKML and netdev reading, so maybe it is ;-)).

> The other case is processing the SKB's linear data area, which can cross
> a page boundary but the code loops over it and processes it in chunks
> which fit in single pages. I was suspicious of this code so I pulled it
> out into a little userspace test harness and fed it some corner cases
> but it looked like it was doing the right thing.

> I speculated that this might be NIC rather than processor related
> (perhaps there's some weak correlation between certain NICs and certain
> processor manufacturers).

> Konrad seems to have an r8169 but the module list wasn't in Sander's
> output -- do you know what you have?

>> I fear that the next step is to do a bit off git bisection to
>> get an idea of which merge it might be. I am going to be AFK
>> on Monday so I won't get to this until Tuesday/Wednesay :-(
>> 
>> .. Thought to help speed this process, this looks like a
>> candidate:
>> 
>> commit 229993001282e128a49a59ec43d255614775703a
>> Merge: 7687b80 fd0f586
>> Author: Linus Torvalds 
>> Date:   Mon Oct 1 11:13:33 2012 -0700
>> 
>>     Merge branch 'x86-mm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
>>     
>>     Pull x86/mm changes from Ingo Molnar:
>>      "The biggest change is new TLB partial flushing code for AMD CPUs.
>>       (The v3.6 kernel had the Intel CPU side code, see commits
>>       e0ba94f14f74..effee4b9b3b.)

> Would be interesting to try although I don't think anything in this area
> is actively messing with page table mappings (that happens later, and
> doesn't effect the non-data bits of the skb like the sizes and offsets).

> Perhaps this debug patch might shed some light? PG_compound or THP might
> be an interesting case?

After applying the debug patch:

[  197.876304] netbk_gop_frag_copy failed: skb frag 0 page
[  197.884299] copying from offset 0, len 1628
[  197.892781] page:ffffea0000b18400 count:3 mapcount:0 mapping:          (null) index:0x0
[  197.900778] page flags: 0x40000000004000(head)
[  197.907074] ------------[ cut here ]------------
[  197.913345] kernel BUG at drivers/net/xen-netback/netback.c:546!
[  197.919626] invalid opcode: 0000 [#1] PREEMPT SMP 
[  197.921573] xen_bridge: port 10(vif10.0) entered forwarding state
[  197.932106] Modules linked in:
[  197.938370] CPU 0 
[  197.938420] Pid: 1180, comm: netback/0 Not tainted 3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)  
[  197.951203] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
[  197.957775] RSP: e02b:ffff880037911c20  EFLAGS: 00010282
[  197.964290] RAX: 0000000000000001 RBX: ffff880036862ee0 RCX: 0000000000000000
[  197.970956] RDX: 0000000000000001 RSI: 0000000000000001 RDI: ffff8800379102b0
[  197.977679] RBP: ffff880037911d50 R08: 0000000000000002 R09: 0000000000000000
[  197.984361] R10: 0000000000000001 R11: ffff880039925e40 R12: 0000000000000030
[  197.990958] R13: 0000000000000000 R14: ffff880031e71800 R15: 0000000000000001
[  197.997459] FS:  00007fb5dfcf7700(0000) GS:ffff88003f800000(0000) knlGS:0000000000000000
[  198.004123] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[  198.010827] CR2: 00007fb5d802d000 CR3: 0000000031fd3000 CR4: 0000000000000660
[  198.017534] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  198.024168] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  198.030717] Process netback/0 (pid: 1180, threadinfo ffff880037910000, task ffff88003997d190)
[  198.037326] Stack:
[  198.043817]  ffff880037911d1c ffff88003997d840 ffff880037911d00 ffff880037911c80
[  198.050573]  ffffffff00000001 0000000000000662 ffffc90010824bb8 ffffc90010820050
[  198.057413]  0000000001080083 ffffc90010820000 0000000000000000 ffff880031cf09c0
[  198.064228] Call Trace:
[  198.070887]  [] ? trace_hardirqs_on+0xd/0x10
[  198.077604]  [] xen_netbk_kthread+0xba/0xa90
[  198.084394]  [] ? try_to_wake_up+0x1b6/0x310
[  198.091109]  [] ? wake_up_bit+0x40/0x40
[  198.097726]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
[  198.104343]  [] kthread+0xd6/0xe0
[  198.111001]  [] kernel_thread_helper+0x4/0x10
[  198.117737]  [] ? retint_restore_args+0x13/0x13
[  198.124425]  [] ? gs_change+0x13/0x13
[  198.131008] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 46 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7 
[  198.145094] RIP  [] xen_netbk_rx_action+0x89a/0x910
[  198.152192]  RSP 
[  198.159344] ---[ end trace cbdd0e4e80268fa8 ]---
[  199.703539] tty_init_dev: 2 callbacks suppressed
[  200.712098] device vif12.0 entered promiscuous mode
[  201.010433] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
[  201.020644] xen_bridge: port 12(vif12.0) entered forwarding state
[  201.027833] xen_bridge: port 12(vif12.0) entered forwarding state
[  206.774576] netbk_gop_frag_copy failed: skb frag 0 page
[  206.777945] device vif13.0 entered promiscuous mode
[  206.788845] copying from offset 1ba4, len 2c1
[  206.795791] page:ffffea0000b18400 count:6 mapcount:0 mapping:          (null) index:0x0
[  206.802771] page flags: 0x40000000004000(head)
[  206.809619] ------------[ cut here ]------------
[  206.816498] kernel BUG at drivers/net/xen-netback/netback.c:546!
[  206.823465] invalid opcode: 0000 [#2] PREEMPT SMP 
[  206.830354] Modules linked in:
[  206.837176] CPU 3 
[  206.837234] Pid: 1183, comm: netback/3 Tainted: G      D      3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)  
[  206.850881] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
[  206.857935] RSP: e02b:ffff880037917c20  EFLAGS: 00010282
[  206.864972] RAX: 0000000000000001 RBX: ffff880003313ae0 RCX: 0000000000000000
[  206.872049] RDX: ffff88003997b0f0 RSI: 0000000000000001 RDI: ffff8800379102b0
[  206.879147] RBP: ffff880037917d50 R08: 0000000000000002 R09: 0000000000000000
[  206.886242] R10: 0000000000000001 R11: ffff880039925640 R12: 0000000000000030
[  206.893163] R13: 0000000000000000 R14: ffff88002c7c4400 R15: 0000000000000001
[  206.900041] FS:  00007f800341a700(0000) GS:ffff88003f8c0000(0000) knlGS:0000000000000000
[  206.907145] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[  206.914126] CR2: 00007f8002b31fb0 CR3: 0000000001c0b000 CR4: 0000000000000660
[  206.921181] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  206.927996] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  206.934711] Process netback/3 (pid: 1183, threadinfo ffff880037916000, task ffff88003997b0f0)
[  206.941494] Stack:
[  206.948105]  ffff880037917d1c ffff880037916010 ffff880037917d00 ffff880037917c80
[  206.955062]  ffffffff810800b5 00000000000000ba ffffc900108466e0 ffffc90010841b78
[  206.962007]  0000000101080083 ffffc90010841b28 0000000100000000 ffff88002c5bb9c0
[  206.968967] Call Trace:
[  206.975830]  [] ? __alloc_workqueue_key+0x265/0x5d0
[  206.982789]  [] ? trace_hardirqs_on+0xd/0x10
[  206.989662]  [] xen_netbk_kthread+0xba/0xa90
[  206.996570]  [] ? try_to_wake_up+0x1b6/0x310
[  207.003523]  [] ? wake_up_bit+0x40/0x40
[  207.010333]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
[  207.017171]  [] kthread+0xd6/0xe0
[  207.023890]  [] kernel_thread_helper+0x4/0x10
[  207.030540]  [] ? retint_restore_args+0x13/0x13
[  207.037275]  [] ? gs_change+0x13/0x13
[  207.043890] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 46 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7 
[  207.057976] RIP  [] xen_netbk_rx_action+0x89a/0x910
[  207.065064]  RSP 
[  207.072056] ---[ end trace cbdd0e4e80268fa9 ]---
[  207.079366] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
[  207.090256] vpn_bridge: port 1(vif13.0) entered forwarding state
[  207.097403] vpn_bridge: port 1(vif13.0) entered forwarding state
[  208.636257] xen_bridge: port 11(vif11.0) entered forwarding state
[  211.515779] netbk_gop_frag_copy failed: skb frag 0 page
[  211.522711] copying from offset 2126, len 2c1
[  211.529403] page:ffffea0000b18400 count:8 mapcount:0 mapping:          (null) index:0x0
[  211.536142] page flags: 0x40000000004000(head)
[  211.542942] ------------[ cut here ]------------
[  211.549664] kernel BUG at drivers/net/xen-netback/netback.c:546!
[  211.556408] invalid opcode: 0000 [#3] PREEMPT SMP 
[  211.563168] Modules linked in:
[  211.569739] CPU 4 
[  211.569789] Pid: 1184, comm: netback/4 Tainted: G      D      3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)  
[  211.583126] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
[  211.590041] RSP: e02b:ffff880037921c20  EFLAGS: 00010282
[  211.596868] RAX: 0000000000000001 RBX: ffff8800375bc4e0 RCX: 0000000000000000
[  211.603890] RDX: ffff88003997a0a0 RSI: 0000000000000001 RDI: ffff8800379202b0
[  211.610792] RBP: ffff880037921d50 R08: 0000000000000002 R09: 0000000000000000
[  211.617608] R10: 0000000000000001 R11: ffff8800399249e0 R12: 0000000000000030
[  211.624537] R13: 0000000000000000 R14: ffff88002b98d400 R15: 0000000000000001
[  211.631302] FS:  00007f332d735740(0000) GS:ffff88003f900000(0000) knlGS:0000000000000000
[  211.638090] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[  211.644965] CR2: 00007f1023d22000 CR3: 0000000031fba000 CR4: 0000000000000660
[  211.651894] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  211.658652] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  211.665288] Process netback/4 (pid: 1184, threadinfo ffff880037920000, task ffff88003997a0a0)
[  211.671884] Stack:
[  211.678376]  ffff880037921d1c ffff880037920010 ffff880037921d00 ffff880037921c80
[  211.685145]  ffffffff810800b5 00000000000000ba ffffc90010851a98 ffffc9001084cf30
[  211.691837]  0000000101080083 ffffc9001084cee0 0000000100000000 ffff88002c5bd9c0
[  211.698581] Call Trace:
[  211.705349]  [] ? __alloc_workqueue_key+0x265/0x5d0
[  211.712156]  [] ? trace_hardirqs_on+0xd/0x10
[  211.718907]  [] xen_netbk_kthread+0xba/0xa90
[  211.725654]  [] ? try_to_wake_up+0x1b6/0x310
[  211.732369]  [] ? wake_up_bit+0x40/0x40
[  211.739111]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
[  211.745858]  [] kthread+0xd6/0xe0
[  211.752449]  [] kernel_thread_helper+0x4/0x10
[  211.758975]  [] ? retint_restore_args+0x13/0x13
[  211.765575]  [] ? gs_change+0x13/0x13
[  211.772016] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 46 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7 
[  211.785816] RIP  [] xen_netbk_rx_action+0x89a/0x910
[  211.792586]  RSP 
[  211.799394] ---[ end trace cbdd0e4e80268faa ]---
[  212.852714] device vif14.0 entered promiscuous mode
[  213.234995] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
[  213.245054] xen_bridge: port 13(vif14.0) entered forwarding state
[  213.252087] xen_bridge: port 13(vif14.0) entered forwarding state
[  214.691532] netbk_gop_frag_copy failed: skb frag 0 page
[  214.698515] copying from offset 26a8, len 2c1
[  214.705472] page:ffffea0000b18400 count:10 mapcount:0 mapping:          (null) index:0x0
[  214.712415] page flags: 0x40000000004000(head)
[  214.719170] ------------[ cut here ]------------
[  214.725887] kernel BUG at drivers/net/xen-netback/netback.c:546!
[  214.732563] invalid opcode: 0000 [#4] PREEMPT SMP 
[  214.739221] Modules linked in:
[  214.745808] CPU 5 
[  214.745859] Pid: 1185, comm: netback/5 Tainted: G      D      3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)  
[  214.759156] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
[  214.766127] RSP: e02b:ffff880037923c20  EFLAGS: 00010282
[  214.773012] RAX: 0000000000000001 RBX: ffff8800379172e0 RCX: 0000000000000000
[  214.780010] RDX: ffff880039ac8000 RSI: 0000000000000001 RDI: ffff8800379202b0
[  214.786988] RBP: ffff880037923d50 R08: 0000000000000002 R09: 0000000000000000
[  214.793870] R10: 0000000000000001 R11: ffff880039924460 R12: 0000000000000030
[  214.800812] R13: 0000000000000000 R14: ffff88002b8b4800 R15: 0000000000000001
[  214.807668] FS:  00007f236d331700(0000) GS:ffff88003f940000(0000) knlGS:0000000000000000
[  214.814545] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[  214.821415] CR2: 00007f236c42b6b0 CR3: 0000000039275000 CR4: 0000000000000660
[  214.828435] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  214.835337] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  214.841963] Process netback/5 (pid: 1185, threadinfo ffff880037922000, task ffff880039ac8000)
[  214.848655] Stack:
[  214.855220]  ffff880037923d1c ffff880037922010 ffff880037923d00 ffff880037923c80
[  214.861945]  ffffffff810800b5 00000000000000ba ffffc9001085ce50 ffffc900108582e8
[  214.868699]  0000000101080083 ffffc90010858298 0000000100000000 ffff880031e939c0
[  214.875477] Call Trace:
[  214.882247]  [] ? __alloc_workqueue_key+0x265/0x5d0
[  214.889083]  [] ? trace_hardirqs_on+0xd/0x10
[  214.895851]  [] xen_netbk_kthread+0xba/0xa90
[  214.902612]  [] ? try_to_wake_up+0x1b6/0x310
[  214.909343]  [] ? wake_up_bit+0x40/0x40
[  214.916115]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
[  214.922856]  [] kthread+0xd6/0xe0
[  214.929527]  [] kernel_thread_helper+0x4/0x10
[  214.936178]  [] ? retint_restore_args+0x13/0x13
[  214.942781]  [] ? gs_change+0x13/0x13
[  214.949279] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 46 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7 
[  214.963107] RIP  [] xen_netbk_rx_action+0x89a/0x910
[  214.969952]  RSP 
[  214.976802] ---[ end trace cbdd0e4e80268fab ]---
[  216.045946] xen_bridge: port 12(vif12.0) entered forwarding state
[  220.405869] device vif15.0 entered promiscuous mode
[  220.607946] device vif15.0-emu entered promiscuous mode
[  220.625075] xen_bridge: port 15(vif15.0-emu) entered forwarding state
[  220.633333] xen_bridge: port 15(vif15.0-emu) entered forwarding state
[  220.890237] pciback 0000:06:00.0: restoring config space at offset 0x3c (was 0x100, writing 0x10a)
[  220.898814] pciback 0000:06:00.0: restoring config space at offset 0x10 (was 0x4, writing 0xf9a00004)
[  220.907406] pciback 0000:06:00.0: restoring config space at offset 0xc (was 0x0, writing 0x10)
[  222.122750] vpn_bridge: port 1(vif13.0) entered forwarding state
[  225.943971] tty_init_dev: 14 callbacks suppressed
[  226.654618] device vif16.0 entered promiscuous mode
[  226.775073] device vif16.0-emu entered promiscuous mode
[  226.784025] xen_bridge: port 17(vif16.0-emu) entered forwarding state
[  226.790188] xen_bridge: port 17(vif16.0-emu) entered forwarding state
[  228.253024] xen_bridge: port 13(vif14.0) entered forwarding state
[  229.788197] xen_bridge: port 15(vif15.0-emu) entered disabled state
[  229.796826] xen_bridge: port 15(vif15.0-emu) entered disabled state
[  229.805243] device vif15.0-emu left promiscuous mode
[  229.813385] xen_bridge: port 15(vif15.0-emu) entered disabled state
[  231.558329] xen-blkback:ring-ref 8, event-channel 25, protocol 1 (x86_64-abi)
[  231.569080] xen-blkback:ring-ref 9, event-channel 26, protocol 1 (x86_64-abi)
[  231.609663] xen_bridge: port 14(vif15.0) entered forwarding state
[  231.617943] xen_bridge: port 14(vif15.0) entered forwarding state
[  231.934347] tty_init_dev: 25 callbacks suppressed






> Ian.

> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index 05593d8..ca4c47d 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -386,7 +386,7 @@ static struct netbk_rx_meta *get_next_rx_buffer(struct xenvif *vif,
>   * Set up the grant operations for this fragment. If it's a flipping
>   * interface, we also set up the unmap request from here.
>   */
> -static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
> +static int netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
>                                 struct netrx_pending_operations *npo,
>                                 struct page *page, unsigned long size,
>                                 unsigned long offset, int *head)
> @@ -402,7 +402,8 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
>         unsigned long bytes;
>  
>         /* Data must not cross a page boundary. */
> -       BUG_ON(size + offset > PAGE_SIZE);
> +       if (size + offset > PAGE_SIZE)
> +               return -1;
>  
>         meta = npo->meta + npo->meta_prod - 1;
>  
> @@ -459,6 +460,7 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
>                 *head = 0; /* There must be something in this buffer now. */
>  
>         }
> +       return 0;
>  }
>  
>  /*
> @@ -517,17 +519,31 @@ static int netbk_gop_skb(struct sk_buff *skb,
>                 if (data + len > skb_tail_pointer(skb))
>                         len = skb_tail_pointer(skb) - data;
>  
> -               netbk_gop_frag_copy(vif, skb, npo,
> -                                   virt_to_page(data), len, offset, &head);
> +               if (netbk_gop_frag_copy(vif, skb, npo,
> +                               virt_to_page(data), len, offset, &head) < 0) {
> +printk(KERN_CRIT "netbk_gop_frag_copy failed: skb head %p-%p\n",
+       skb->>data, skb_tail_pointer);
> +printk(KERN_CRIT "copying from %p-%p, offset %x, len %x\n",
> +       data, data+len, offset, len);
> +dump_page(virt_to_page(data));
> +BUG();
> +               }
>                 data += len;
>         }
>  
>         for (i = 0; i < nr_frags; i++) {
> -               netbk_gop_frag_copy(vif, skb, npo,
> +               if (netbk_gop_frag_copy(vif, skb, npo,
>                                     skb_frag_page(&skb_shinfo(skb)->frags[i]),
>                                     skb_frag_size(&skb_shinfo(skb)->frags[i]),
>                                     skb_shinfo(skb)->frags[i].page_offset,
> -                                   &head);
> +                                   &head) < 0) {
> +printk(KERN_CRIT "netbk_gop_frag_copy failed: skb frag %d page\n", i);
> +printk(KERN_CRIT "copying from offset %x, len %x\n",
> +       skb_shinfo(skb)->frags[i].page_offset,
> +       skb_frag_size(&skb_shinfo(skb)->frags[i]));
> +dump_page(skb_frag_page(&skb_shinfo(skb)->frags[i]));
> +BUG();
> +               }
>         }
>  
>         return npo->meta_prod - old_meta_prod;





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 04:37:34 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 04:37:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLRYz-0004lG-K9; Tue, 09 Oct 2012 04:37:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLRYy-0004lB-8R
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 04:37:00 +0000
Received: from [85.158.143.35:5785] by server-2.bemta-4.messagelabs.com id
	0C/0F-06610-BE9A3705; Tue, 09 Oct 2012 04:36:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1349757418!14408237!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMyNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30742 invoked from network); 9 Oct 2012 04:36:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 04:36:58 -0000
X-IronPort-AV: E=Sophos;i="4.80,557,1344211200"; d="scan'208";a="15026149"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 04:36:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 9 Oct 2012 05:36:57 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TLRYv-0006lT-6F;
	Tue, 09 Oct 2012 04:36:57 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TLRYv-00082o-0o;
	Tue, 09 Oct 2012 05:36:57 +0100
To: 
Message-ID: 
From: xen.org 
Date: Tue, 9 Oct 2012 05:36:57 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13941: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13941 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13941/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 13932
 build-i386                    4 xen-build                 fail REGR. vs. 13932

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13932
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13932
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13932
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13932

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  c9f621893a05
baseline version:
 xen                  099589002239

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD 
  Ian Campbell 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Samuel Thibault 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26017:c9f621893a05
tag:         tip
user:        Matthew Fioravante 
date:        Mon Oct 08 14:36:31 2012 +0100
    
    minios: setup fpu and sse in mini-os
    
    This patch adds floating point and sse support to mini-os by
    initializing the floating point unit and the see unit during
    domain boot up.
    
    Signed-off-by: Matthew Fioravante 
    Acked-by: Samuel Thibault 
    Committed-by: Ian Campbell 
    
    
changeset:   26016:865626fc7004
user:        Matthew Fioravante 
date:        Mon Oct 08 14:36:31 2012 +0100
    
    minios: add CONFIG_XC conditional
    
    This patch adds a CONFIG_XC option to mini-os, to allow conditional
    support for libxc for mini-os domains.
    
    Signed-off-by: Matthew Fioravante 
    Acked-by: Samuel Thibault 
    Committed-by: Ian Campbell 
    
    
changeset:   26015:42ca0ed31aa6
user:        Matthew Fioravante 
date:        Mon Oct 08 14:36:30 2012 +0100
    
    minios: Disable the mfn_is_ram() check, it doesn't work correctly on all systems
    
    This patch disables the mfn_is_ram check in mini-os. The current check
    is insufficient and fails on some systems with larger than 4gb memory.
    
    Signed-off-by: Matthew Fioravante 
    Acked-by: Samuel Thibault 
    Committed-by: Ian Campbell 
    
    
changeset:   26014:8fdb8d464ece
user:        Matthew Fioravante 
date:        Mon Oct 08 14:36:29 2012 +0100
    
    minios: Add endian, byteswap, and wordsize macros to mini-os
    
    This patch addes byte swapping macros and endian support to mini-os.
    
    Signed-off-by: Matthew Fioravante 
    Acked-by: Samuel Thibault 
    Committed-by: Ian Campbell 
    
    
changeset:   26013:a797d59e1d29
user:        Matthew Fioravante 
date:        Mon Oct 08 14:36:28 2012 +0100
    
    minios: Add ioread/iowrite functions to mini-os
    
    This patch adds iowritexx() and ioreadxx() functions for interacting
    with hardware memory to mini-os. The functions are available in a header
    iorw.h
    
    Signed-off-by: Matthew Fioravante 
    Acked-by: Samuel Thibault 
    Reviewed-by: George Dunlap 
    Committed-by: Ian Campbell 
    
    
changeset:   26012:02e744da52c9
user:        Olaf Hering 
date:        Mon Oct 08 12:18:35 2012 +0100
    
    tools/configure.ac: fill PACKAGE_TARNAME in AC_INIT
    
    Upcoming changes may move DOCDIR from Config.mk to config/Tools.mk. To
    preserve the currently used path, which ends with /xen, specify a value
    for PACKAGE_TARNAME. Without this change the path would end with
    /xen-hypervisor.
    
    Please rerun autoconf after applying this.
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26011:b6fb4e63b946
user:        Olaf Hering 
date:        Mon Oct 08 12:18:34 2012 +0100
    
    stubdom: fix parallel build by expanding CROSS_MAKE
    
    Recently I changed my rpm xen.spec file from doing
    'make -C tools -j N && make stubdom' to 'make -j N stubdom' because
    stubdom depends on tools, so both get built.
    The result was the failure below.
    
    ....
    mkdir -p grub-x86_64
    CPPFLAGS="-isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include -D__MINIOS__ -DHAVE_LIBC -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include/posix -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../tools/xenstore  -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include/x86 -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include/x86/x86_64 -U __linux__ -U __FreeBSD__ -U __sun__ -nostdinc -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include/posix -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/cross-root-x86_64/x86_64-xen-elf/include -isystem /usr/lib64/gcc/x86_64-suse-linux/4.7/include -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/lwip-x86_64/src/include -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/lwip-x86_64/src/include/ipv4 -I/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/include -I/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../xen/include" CFLAGS="-mno-red-zone -O1 -fno-omit-frame-pointer  -m64 -mno-red-zone -fno-reorder-blocks -fno-asynchronous-unwind-tables -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable   -fno-stack-protector -fno-exceptions" make DESTDIR= -C grub OBJ_DIR=/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/grub-x86_64
    make[2]: Entering directory `/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/grub'
    make[2]: warning: jobserver unavailable: using -j1.  Add `+' to parent make rule.
    make[2]: *** INTERNAL: readdir: Bad file descriptor
    .  Stop.
    make[2]: Makefile: Field 'stem' not cached: Makefile
    
    make[2]: Leaving directory `/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/grub'
    make[1]: *** [grub] Error 2
    [ -d mini-os-x86_64-xenstore ] || \
    for i in $(cd /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os ; find . -type d) ; do \
                    mkdir -p mini-os-x86_64-xenstore/$i ; \
    done
    ....
    
    Expanding every occurrence of CROSS_MAKE avoids this error. It also has
    the nice side effect of actually enabling parallel build for stubdom.
    According to the GNU make documentation $(MAKE) gets its special meaning
    only if it appears directly in the recipe:
    
    http://www.gnu.org/software/make/manual/html_node/MAKE-Variable.html
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26010:cff10030c6ea
user:        Olaf Hering 
date:        Mon Oct 08 12:18:33 2012 +0100
    
    xend/pvscsi: update sysfs parser for Linux 3.0
    
    The sysfs parser for /sys/bus/scsi/devices understands only the layout
    of kernel version 2.6.16. This looks as follows:
    
    /sys/bus/scsi/devices/1:0:0:0/block:sda is a symlink to /sys/block/sda/
    /sys/bus/scsi/devices/1:0:0:0/scsi_generic:sg1 is a symlink to /sys/class/scsi_generic/sg1
    
    Both directories contain a 'dev' file with the major:minor information.
    This patch updates the used regex strings to match also the colon to
    make it more robust against possible future changes.
    
    In kernel version 3.0 the layout changed:
    /sys/bus/scsi/devices/ contains now additional symlinks to directories
    such as host1 and target1:0:0. This patch ignores these as they do not
    point to the desired scsi devices. They just clutter the devices array.
    
    The directory layout in '1:0:0:0' changed as well, the 'type:name'
    notation was replaced with 'type/name' directories:
    
    /sys/bus/scsi/devices/1:0:0:0/block/sda/
    /sys/bus/scsi/devices/1:0:0:0/scsi_generic/sg1/
    
    Both directories contain a 'dev' file with the major:minor information.
    This patch adds additional code to walk the subdir to find the 'dev'
    file to make sure the given subdirectory is really the kernel name.
    
    In addition this patch makes sure devname is not None.
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26009:2dbfa4d2e107
user:        Olaf Hering 
date:        Mon Oct 08 12:18:32 2012 +0100
    
    xend/pvscsi: fix usage of persistant device names for SCSI devices
    
    Currently the callers of vscsi_get_scsidevices() do not pass a mask
    string.  This will call "lsscsi -g '[]'", which causes a lsscsi syntax
    error. As a result the sysfs parser _vscsi_get_scsidevices() is used.
    But this parser is broken and the specified names in the config file are
    not found.
    
    Using a mask '*' if no mask was given will call lsscsi correctly and the
    following config is parsed correctly:
    
    vscsi=[
    	'/dev/sg3, 0:0:0:0',
    	'/dev/disk/by-id/wwn-0x600508b4000cf1c30000800000410000, 0:0:0:1'
    ]
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26008:eecb528583d7
user:        Olaf Hering 
date:        Mon Oct 08 12:18:31 2012 +0100
    
    xend/pvscsi: fix passing of SCSI control LUNs
    
    Currently pvscsi can not pass SCSI devices that have just a scsi_generic node.
    In the following example sg3 is a control LUN for the disk sdd.
    But vscsi=['4:0:2:0,0:0:0:0'] does not work because the internal 'devname'
    variable remains None. Later writing p-devname to xenstore fails because None
    is not a valid string variable.
    
    Since devname is used for just informational purpose use sg also as devname.
    
    carron:~ $ lsscsi -g
    [0:0:0:0]    disk    ATA      FK0032CAAZP      HPF2  /dev/sda   /dev/sg0
    [4:0:0:0]    disk    HP       P2000G3 FC/iSCSI T100  /dev/sdb   /dev/sg1
    [4:0:1:0]    disk    HP       P2000G3 FC/iSCSI T100  /dev/sdc   /dev/sg2
    [4:0:2:0]    storage HP       HSV400           0950  -         /dev/sg3
    [4:0:2:1]    disk    HP       HSV400           0950  /dev/sdd   /dev/sg4
    [4:0:3:0]    storage HP       HSV400           0950  -         /dev/sg5
    [4:0:3:1]    disk    HP       HSV400           0950  /dev/sde   /dev/sg6
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26007:fe756682cc7f
user:        Olaf Hering 
date:        Mon Oct 08 12:18:31 2012 +0100
    
    xenballoond.init: remove 4 from default runlevel
    
    Remove 4 from default runlevel in xenballoond.init.
    
    Similar to what changeset 24847:0900b1c905f1 does in xencommons, remove
    runlevel 4 from the other runlevel scripts. LSB defines runlevel 4 as
    reserved for local use, the local sysadmin is responsible for symlink
    creation in rc4.d.
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26006:8b6870d686d6
user:        Olaf Hering 
date:        Mon Oct 08 12:18:30 2012 +0100
    
    hotplug/Linux: Remove tracing (bash -x) from network-nat script
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26005:cdb48f1742f3
user:        Roger Pau Monne 
date:        Mon Oct 08 12:18:29 2012 +0100
    
    autoconf: add -Werror to libutil.h header check
    
    libutil.h is only needed on BSDs, but not in Linux. Debian package
    libbsd-dev-0.3.0-1 installed a libutil.h overlay that contains a
    
    Perform the libutil.h check with -Werror, so we don't include this
    bogus header.
    
    Signed-off-by: Roger Pau Monne 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26004:099589002239
user:        Anthony PERARD 
date:        Mon Oct 08 11:45:36 2012 +0100
    
    libxl: Allow migration with qemu-xen.
    
    Signed-off-by: Anthony PERARD 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 04:37:34 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 04:37:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLRYz-0004lG-K9; Tue, 09 Oct 2012 04:37:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLRYy-0004lB-8R
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 04:37:00 +0000
Received: from [85.158.143.35:5785] by server-2.bemta-4.messagelabs.com id
	0C/0F-06610-BE9A3705; Tue, 09 Oct 2012 04:36:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1349757418!14408237!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMyNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30742 invoked from network); 9 Oct 2012 04:36:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 04:36:58 -0000
X-IronPort-AV: E=Sophos;i="4.80,557,1344211200"; d="scan'208";a="15026149"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 04:36:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 9 Oct 2012 05:36:57 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TLRYv-0006lT-6F;
	Tue, 09 Oct 2012 04:36:57 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TLRYv-00082o-0o;
	Tue, 09 Oct 2012 05:36:57 +0100
To: 
Message-ID: 
From: xen.org 
Date: Tue, 9 Oct 2012 05:36:57 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13941: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13941 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13941/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 13932
 build-i386                    4 xen-build                 fail REGR. vs. 13932

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13932
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13932
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13932
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13932

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  c9f621893a05
baseline version:
 xen                  099589002239

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD 
  Ian Campbell 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Samuel Thibault 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26017:c9f621893a05
tag:         tip
user:        Matthew Fioravante 
date:        Mon Oct 08 14:36:31 2012 +0100
    
    minios: setup fpu and sse in mini-os
    
    This patch adds floating point and sse support to mini-os by
    initializing the floating point unit and the see unit during
    domain boot up.
    
    Signed-off-by: Matthew Fioravante 
    Acked-by: Samuel Thibault 
    Committed-by: Ian Campbell 
    
    
changeset:   26016:865626fc7004
user:        Matthew Fioravante 
date:        Mon Oct 08 14:36:31 2012 +0100
    
    minios: add CONFIG_XC conditional
    
    This patch adds a CONFIG_XC option to mini-os, to allow conditional
    support for libxc for mini-os domains.
    
    Signed-off-by: Matthew Fioravante 
    Acked-by: Samuel Thibault 
    Committed-by: Ian Campbell 
    
    
changeset:   26015:42ca0ed31aa6
user:        Matthew Fioravante 
date:        Mon Oct 08 14:36:30 2012 +0100
    
    minios: Disable the mfn_is_ram() check, it doesn't work correctly on all systems
    
    This patch disables the mfn_is_ram check in mini-os. The current check
    is insufficient and fails on some systems with larger than 4gb memory.
    
    Signed-off-by: Matthew Fioravante 
    Acked-by: Samuel Thibault 
    Committed-by: Ian Campbell 
    
    
changeset:   26014:8fdb8d464ece
user:        Matthew Fioravante 
date:        Mon Oct 08 14:36:29 2012 +0100
    
    minios: Add endian, byteswap, and wordsize macros to mini-os
    
    This patch addes byte swapping macros and endian support to mini-os.
    
    Signed-off-by: Matthew Fioravante 
    Acked-by: Samuel Thibault 
    Committed-by: Ian Campbell 
    
    
changeset:   26013:a797d59e1d29
user:        Matthew Fioravante 
date:        Mon Oct 08 14:36:28 2012 +0100
    
    minios: Add ioread/iowrite functions to mini-os
    
    This patch adds iowritexx() and ioreadxx() functions for interacting
    with hardware memory to mini-os. The functions are available in a header
    iorw.h
    
    Signed-off-by: Matthew Fioravante 
    Acked-by: Samuel Thibault 
    Reviewed-by: George Dunlap 
    Committed-by: Ian Campbell 
    
    
changeset:   26012:02e744da52c9
user:        Olaf Hering 
date:        Mon Oct 08 12:18:35 2012 +0100
    
    tools/configure.ac: fill PACKAGE_TARNAME in AC_INIT
    
    Upcoming changes may move DOCDIR from Config.mk to config/Tools.mk. To
    preserve the currently used path, which ends with /xen, specify a value
    for PACKAGE_TARNAME. Without this change the path would end with
    /xen-hypervisor.
    
    Please rerun autoconf after applying this.
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26011:b6fb4e63b946
user:        Olaf Hering 
date:        Mon Oct 08 12:18:34 2012 +0100
    
    stubdom: fix parallel build by expanding CROSS_MAKE
    
    Recently I changed my rpm xen.spec file from doing
    'make -C tools -j N && make stubdom' to 'make -j N stubdom' because
    stubdom depends on tools, so both get built.
    The result was the failure below.
    
    ....
    mkdir -p grub-x86_64
    CPPFLAGS="-isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include -D__MINIOS__ -DHAVE_LIBC -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include/posix -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../tools/xenstore  -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include/x86 -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include/x86/x86_64 -U __linux__ -U __FreeBSD__ -U __sun__ -nostdinc -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include/posix -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/cross-root-x86_64/x86_64-xen-elf/include -isystem /usr/lib64/gcc/x86_64-suse-linux/4.7/include -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/lwip-x86_64/src/include -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/lwip-x86_64/src/include/ipv4 -I/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/include -I/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../xen/include" CFLAGS="-mno-red-zone -O1 -fno-omit-frame-pointer  -m64 -mno-red-zone -fno-reorder-blocks -fno-asynchronous-unwind-tables -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable   -fno-stack-protector -fno-exceptions" make DESTDIR= -C grub OBJ_DIR=/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/grub-x86_64
    make[2]: Entering directory `/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/grub'
    make[2]: warning: jobserver unavailable: using -j1.  Add `+' to parent make rule.
    make[2]: *** INTERNAL: readdir: Bad file descriptor
    .  Stop.
    make[2]: Makefile: Field 'stem' not cached: Makefile
    
    make[2]: Leaving directory `/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/grub'
    make[1]: *** [grub] Error 2
    [ -d mini-os-x86_64-xenstore ] || \
    for i in $(cd /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os ; find . -type d) ; do \
                    mkdir -p mini-os-x86_64-xenstore/$i ; \
    done
    ....
    
    Expanding every occurrence of CROSS_MAKE avoids this error. It also has
    the nice side effect of actually enabling parallel build for stubdom.
    According to the GNU make documentation $(MAKE) gets its special meaning
    only if it appears directly in the recipe:
    
    http://www.gnu.org/software/make/manual/html_node/MAKE-Variable.html
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26010:cff10030c6ea
user:        Olaf Hering 
date:        Mon Oct 08 12:18:33 2012 +0100
    
    xend/pvscsi: update sysfs parser for Linux 3.0
    
    The sysfs parser for /sys/bus/scsi/devices understands only the layout
    of kernel version 2.6.16. This looks as follows:
    
    /sys/bus/scsi/devices/1:0:0:0/block:sda is a symlink to /sys/block/sda/
    /sys/bus/scsi/devices/1:0:0:0/scsi_generic:sg1 is a symlink to /sys/class/scsi_generic/sg1
    
    Both directories contain a 'dev' file with the major:minor information.
    This patch updates the used regex strings to match also the colon to
    make it more robust against possible future changes.
    
    In kernel version 3.0 the layout changed:
    /sys/bus/scsi/devices/ contains now additional symlinks to directories
    such as host1 and target1:0:0. This patch ignores these as they do not
    point to the desired scsi devices. They just clutter the devices array.
    
    The directory layout in '1:0:0:0' changed as well, the 'type:name'
    notation was replaced with 'type/name' directories:
    
    /sys/bus/scsi/devices/1:0:0:0/block/sda/
    /sys/bus/scsi/devices/1:0:0:0/scsi_generic/sg1/
    
    Both directories contain a 'dev' file with the major:minor information.
    This patch adds additional code to walk the subdir to find the 'dev'
    file to make sure the given subdirectory is really the kernel name.
    
    In addition this patch makes sure devname is not None.
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26009:2dbfa4d2e107
user:        Olaf Hering 
date:        Mon Oct 08 12:18:32 2012 +0100
    
    xend/pvscsi: fix usage of persistant device names for SCSI devices
    
    Currently the callers of vscsi_get_scsidevices() do not pass a mask
    string.  This will call "lsscsi -g '[]'", which causes a lsscsi syntax
    error. As a result the sysfs parser _vscsi_get_scsidevices() is used.
    But this parser is broken and the specified names in the config file are
    not found.
    
    Using a mask '*' if no mask was given will call lsscsi correctly and the
    following config is parsed correctly:
    
    vscsi=[
    	'/dev/sg3, 0:0:0:0',
    	'/dev/disk/by-id/wwn-0x600508b4000cf1c30000800000410000, 0:0:0:1'
    ]
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26008:eecb528583d7
user:        Olaf Hering 
date:        Mon Oct 08 12:18:31 2012 +0100
    
    xend/pvscsi: fix passing of SCSI control LUNs
    
    Currently pvscsi can not pass SCSI devices that have just a scsi_generic node.
    In the following example sg3 is a control LUN for the disk sdd.
    But vscsi=['4:0:2:0,0:0:0:0'] does not work because the internal 'devname'
    variable remains None. Later writing p-devname to xenstore fails because None
    is not a valid string variable.
    
    Since devname is used for just informational purpose use sg also as devname.
    
    carron:~ $ lsscsi -g
    [0:0:0:0]    disk    ATA      FK0032CAAZP      HPF2  /dev/sda   /dev/sg0
    [4:0:0:0]    disk    HP       P2000G3 FC/iSCSI T100  /dev/sdb   /dev/sg1
    [4:0:1:0]    disk    HP       P2000G3 FC/iSCSI T100  /dev/sdc   /dev/sg2
    [4:0:2:0]    storage HP       HSV400           0950  -         /dev/sg3
    [4:0:2:1]    disk    HP       HSV400           0950  /dev/sdd   /dev/sg4
    [4:0:3:0]    storage HP       HSV400           0950  -         /dev/sg5
    [4:0:3:1]    disk    HP       HSV400           0950  /dev/sde   /dev/sg6
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26007:fe756682cc7f
user:        Olaf Hering 
date:        Mon Oct 08 12:18:31 2012 +0100
    
    xenballoond.init: remove 4 from default runlevel
    
    Remove 4 from default runlevel in xenballoond.init.
    
    Similar to what changeset 24847:0900b1c905f1 does in xencommons, remove
    runlevel 4 from the other runlevel scripts. LSB defines runlevel 4 as
    reserved for local use, the local sysadmin is responsible for symlink
    creation in rc4.d.
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26006:8b6870d686d6
user:        Olaf Hering 
date:        Mon Oct 08 12:18:30 2012 +0100
    
    hotplug/Linux: Remove tracing (bash -x) from network-nat script
    
    Signed-off-by: Olaf Hering 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26005:cdb48f1742f3
user:        Roger Pau Monne 
date:        Mon Oct 08 12:18:29 2012 +0100
    
    autoconf: add -Werror to libutil.h header check
    
    libutil.h is only needed on BSDs, but not in Linux. Debian package
    libbsd-dev-0.3.0-1 installed a libutil.h overlay that contains a
    
    Perform the libutil.h check with -Werror, so we don't include this
    bogus header.
    
    Signed-off-by: Roger Pau Monne 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26004:099589002239
user:        Anthony PERARD 
date:        Mon Oct 08 11:45:36 2012 +0100
    
    libxl: Allow migration with qemu-xen.
    
    Signed-off-by: Anthony PERARD 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 07:51:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 07:51:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLUaE-0005m2-Ko; Tue, 09 Oct 2012 07:50:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLUaC-0005lx-Dv
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 07:50:28 +0000
Received: from [85.158.138.51:38817] by server-14.bemta-3.messagelabs.com id
	B8/04-19528-347D3705; Tue, 09 Oct 2012 07:50:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1349769026!25698410!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMyNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1801 invoked from network); 9 Oct 2012 07:50:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 07:50:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,558,1344211200"; d="scan'208";a="15028661"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 07:50:24 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	08:50:24 +0100
Message-ID: <1349769024.6952.64.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: "xen.org" 
Date: Tue, 9 Oct 2012 08:50:24 +0100
In-Reply-To: 
References: 
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [xen-unstable test] 13934: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-10-08 at 20:55 +0100, xen.org wrote:
> flight 13934 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13934/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-i386-oldkern            4 xen-build                 fail REGR. vs. 13932
>  build-i386                    4 xen-build                 fail REGR. vs. 13932

make[2]: Entering directory `/home/osstest/build.13934.build-i386/xen-unstable/docs/figs'
fig2dev -L png network-bridge.fig >network-bridge.png.tmp
/bin/sh: fig2dev: not found
make[2]: *** [network-bridge.png] Error 127

But the of this tool isn't new in this flight. 

But wait, this is 13932:
        make -C figs
        make[2]: Entering directory `/home/osstest/build.13932.build-i386/xen-unstable/docs/figs'
        fig2dev -L png network-bridge.fig >network-bridge.png.tmp
        /bin/sh: fig2dev: not found
        make[2]: *** [network-bridge.png] Error 127
        make[2]: Leaving directory `/home/osstest/build.13932.build-i386/xen-unstable/docs/figs'
        make[1]: *** [figs] Error 2
        make[1]: *** Waiting for unfinished jobs....

But the job seemed to pass! ???

I can't seem to see anything between xxx32 and xxx34 which would have
caused us to stop ignoring this error.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 07:51:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 07:51:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLUaE-0005m2-Ko; Tue, 09 Oct 2012 07:50:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLUaC-0005lx-Dv
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 07:50:28 +0000
Received: from [85.158.138.51:38817] by server-14.bemta-3.messagelabs.com id
	B8/04-19528-347D3705; Tue, 09 Oct 2012 07:50:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1349769026!25698410!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMyNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1801 invoked from network); 9 Oct 2012 07:50:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 07:50:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,558,1344211200"; d="scan'208";a="15028661"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 07:50:24 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	08:50:24 +0100
Message-ID: <1349769024.6952.64.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: "xen.org" 
Date: Tue, 9 Oct 2012 08:50:24 +0100
In-Reply-To: 
References: 
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [xen-unstable test] 13934: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-10-08 at 20:55 +0100, xen.org wrote:
> flight 13934 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13934/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-i386-oldkern            4 xen-build                 fail REGR. vs. 13932
>  build-i386                    4 xen-build                 fail REGR. vs. 13932

make[2]: Entering directory `/home/osstest/build.13934.build-i386/xen-unstable/docs/figs'
fig2dev -L png network-bridge.fig >network-bridge.png.tmp
/bin/sh: fig2dev: not found
make[2]: *** [network-bridge.png] Error 127

But the of this tool isn't new in this flight. 

But wait, this is 13932:
        make -C figs
        make[2]: Entering directory `/home/osstest/build.13932.build-i386/xen-unstable/docs/figs'
        fig2dev -L png network-bridge.fig >network-bridge.png.tmp
        /bin/sh: fig2dev: not found
        make[2]: *** [network-bridge.png] Error 127
        make[2]: Leaving directory `/home/osstest/build.13932.build-i386/xen-unstable/docs/figs'
        make[1]: *** [figs] Error 2
        make[1]: *** Waiting for unfinished jobs....

But the job seemed to pass! ???

I can't seem to see anything between xxx32 and xxx34 which would have
caused us to stop ignoring this error.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 08:07:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 08:07:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLUpl-0006OX-Oy; Tue, 09 Oct 2012 08:06:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLUpk-0006OS-7x
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 08:06:32 +0000
Received: from [85.158.139.211:49094] by server-10.bemta-5.messagelabs.com id
	2A/87-16911-70BD3705; Tue, 09 Oct 2012 08:06:31 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1349769990!21553968!1
X-Originating-IP: [213.199.154.141]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7221 invoked from network); 9 Oct 2012 08:06:30 -0000
Received: from db3ehsobe003.messaging.microsoft.com (HELO
	db3outboundpool.messaging.microsoft.com) (213.199.154.141)
	by server-10.tower-206.messagelabs.com with AES128-SHA encrypted SMTP;
	9 Oct 2012 08:06:30 -0000
Received: from mail15-db3-R.bigfish.com (10.3.81.237) by
	DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id
	14.1.225.23; Tue, 9 Oct 2012 08:06:30 +0000
Received: from mail15-db3 (localhost [127.0.0.1])	by mail15-db3-R.bigfish.com
	(Postfix) with ESMTP id 075F1480072;
	Tue,  9 Oct 2012 08:06:30 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzc85dhc857hzz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12bdh137ah1441h34h1155h)
Received: from mail15-db3 (localhost.localdomain [127.0.0.1]) by mail15-db3
	(MessageSwitch) id 1349769987560158_9797;
	Tue,  9 Oct 2012 08:06:27 +0000 (UTC)
Received: from DB3EHSMHS013.bigfish.com (unknown [10.3.81.234])	by
	mail15-db3.bigfish.com (Postfix) with ESMTP id 77A5A2E005E;
	Tue,  9 Oct 2012 08:06:27 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS013.bigfish.com (10.3.87.113) with Microsoft SMTP Server id
	14.1.225.23; Tue, 9 Oct 2012 08:06:25 +0000
X-WSS-ID: 0MBM96N-01-7LJ-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 21BFB102805F;	Tue,  9 Oct 2012 03:06:23 -0500 (CDT)
Received: from SAUSEXDAG05.amd.com (163.181.55.6) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 9 Oct 2012 03:06:57 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag05.amd.com
	(163.181.55.6) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Tue, 9 Oct 2012 03:06:23 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Tue, 9 Oct 2012
	04:06:21 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id F29CF49C1E6; Tue,  9 Oct 2012
	09:06:19 +0100 (BST)
Message-ID: <5073DAFB.4040004@amd.com>
Date: Tue, 9 Oct 2012 10:06:19 +0200
From: Wei Wang 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120421 Thunderbird/12.0
MIME-Version: 1.0
To: Jan Beulich , Keir Fraser ,
	"xen-devel@lists.xensource.com" 
Content-Type: multipart/mixed; boundary="------------060606020707020605050206"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] x86/amd: Fix xen_apic_write warnings in Dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------060606020707020605050206
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

Hi, this patch fixes a xen_apic_write warnings in Dom0

[    0.020294] ------------[ cut here ]------------
[    0.020311] WARNING: at arch/x86/xen/enlighten.c:730
xen_apic_write+0x15/0x17()
[    0.020318] Hardware name: empty
[    0.020323] Modules linked in:
[    0.020334] Pid: 1, comm: swapper/0 Not tainted 3.3.8 #7
[    0.020340] Call Trace:
[    0.020354]  [] warn_slowpath_common+0x80/0x98
[    0.020369]  [] warn_slowpath_null+0x15/0x17
[    0.020378]  [] xen_apic_write+0x15/0x17
[    0.020392]  [] perf_events_lapic_init+0x2e/0x30
[    0.020410]  [] init_hw_perf_events+0x250/0x407
[    0.020419]  [] ? check_bugs+0x2d/0x2d
[    0.020430]  [] do_one_initcall+0x7a/0x131
[    0.020444]  [] kernel_init+0x91/0x15d
[    0.020456]  [] kernel_thread_helper+0x4/0x10
[    0.020471]  [] ? retint_restore_args+0x5/0x6
[    0.020481]  [] ? gs_change+0x13/0x13
[    0.020500] ---[ end trace a7919e7f17c0a725 ]---

Kernel function check_hw_exists() writes 0xabcd to msr 0xc0010201 
(Performance Event Counter 0) and read it again to check if it is 
running as dom0. Early amd cpus does not reset perf counters during warm 
reboot. If the kernel is booted with bare metal and then as a dom0, the 
content of msr 0xc0010201 will stay and the checking will
pass and PMU will be enabled unexpectedly.

Signed-off-by: Wei Wang 

Thanks
Wei



--------------060606020707020605050206
Content-Type: text/plain; charset="UTF-8";
	name="0001-Fix-xen_apic_write-warnings-in-Dom0.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="0001-Fix-xen_apic_write-warnings-in-Dom0.patch"
Content-Description: 0001-Fix-xen_apic_write-warnings-in-Dom0.patch

>From 5cb3c3ed7db525ccb44660ed30890ffeb00b2ea8 Mon Sep 17 00:00:00 2001
From: Wei Wang 
Date: Mon, 8 Oct 2012 15:48:55 +0200
Subject: [PATCH] x86/amd: Fix xen_apic_write warnings in Dom0

[    0.020294] ------------[ cut here ]------------
[    0.020311] WARNING: at arch/x86/xen/enlighten.c:730
xen_apic_write+0x15/0x17()
[    0.020318] Hardware name: empty
[    0.020323] Modules linked in:
[    0.020334] Pid: 1, comm: swapper/0 Not tainted 3.3.8 #7
[    0.020340] Call Trace:
[    0.020354]  [] warn_slowpath_common+0x80/0x98
[    0.020369]  [] warn_slowpath_null+0x15/0x17
[    0.020378]  [] xen_apic_write+0x15/0x17
[    0.020392]  [] perf_events_lapic_init+0x2e/0x30
[    0.020410]  [] init_hw_perf_events+0x250/0x407
[    0.020419]  [] ? check_bugs+0x2d/0x2d
[    0.020430]  [] do_one_initcall+0x7a/0x131
[    0.020444]  [] kernel_init+0x91/0x15d
[    0.020456]  [] kernel_thread_helper+0x4/0x10
[    0.020471]  [] ? retint_restore_args+0x5/0x6
[    0.020481]  [] ? gs_change+0x13/0x13
[    0.020500] ---[ end trace a7919e7f17c0a725 ]---

Kernel function check_hw_exists() writes 0xabcd to msr 0xc0010201 (Performance Event
Counter 0) and read it again to check if it is running as dom0. Early amd cpus does
not reset perf counters during warm reboot. If the kernel is booted with bare metal
and then as a dom0, the content of msr 0xc0010201 will stay and the checking will
pass and PMU will be enabled unexpectedly.

Signed-off-by: Wei Wang 
---
 xen/arch/x86/cpu/amd.c |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
index c95349f..5909f8c 100644
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -485,6 +485,17 @@ static void __devinit init_amd(struct cpuinfo_x86 *c)
 	if (c->x86 > 0x11)
 		set_bit(X86_FEATURE_ARAT, c->x86_capability);
 
+	/* 
+	 * Prior to Family 0x14, perf counters are not reset during warm reboot.  
+	 * We have to reset them manually.
+	 */
+	if (c->x86 < 0x14) {
+		wrmsrl(MSR_K7_PERFCTR0, 0);
+		wrmsrl(MSR_K7_PERFCTR1, 0);
+		wrmsrl(MSR_K7_PERFCTR2, 0);
+		wrmsrl(MSR_K7_PERFCTR3, 0);
+	}
+
 	if (cpuid_edx(0x80000007) & (1 << 10)) {
 		rdmsr(MSR_K7_HWCR, l, h);
 		l |= (1 << 27); /* Enable read-only APERF/MPERF bit */
-- 
1.7.4


--------------060606020707020605050206
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------060606020707020605050206--


From xen-devel-bounces@lists.xen.org Tue Oct 09 08:07:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 08:07:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLUpl-0006OX-Oy; Tue, 09 Oct 2012 08:06:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLUpk-0006OS-7x
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 08:06:32 +0000
Received: from [85.158.139.211:49094] by server-10.bemta-5.messagelabs.com id
	2A/87-16911-70BD3705; Tue, 09 Oct 2012 08:06:31 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1349769990!21553968!1
X-Originating-IP: [213.199.154.141]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7221 invoked from network); 9 Oct 2012 08:06:30 -0000
Received: from db3ehsobe003.messaging.microsoft.com (HELO
	db3outboundpool.messaging.microsoft.com) (213.199.154.141)
	by server-10.tower-206.messagelabs.com with AES128-SHA encrypted SMTP;
	9 Oct 2012 08:06:30 -0000
Received: from mail15-db3-R.bigfish.com (10.3.81.237) by
	DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id
	14.1.225.23; Tue, 9 Oct 2012 08:06:30 +0000
Received: from mail15-db3 (localhost [127.0.0.1])	by mail15-db3-R.bigfish.com
	(Postfix) with ESMTP id 075F1480072;
	Tue,  9 Oct 2012 08:06:30 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzc85dhc857hzz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12bdh137ah1441h34h1155h)
Received: from mail15-db3 (localhost.localdomain [127.0.0.1]) by mail15-db3
	(MessageSwitch) id 1349769987560158_9797;
	Tue,  9 Oct 2012 08:06:27 +0000 (UTC)
Received: from DB3EHSMHS013.bigfish.com (unknown [10.3.81.234])	by
	mail15-db3.bigfish.com (Postfix) with ESMTP id 77A5A2E005E;
	Tue,  9 Oct 2012 08:06:27 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS013.bigfish.com (10.3.87.113) with Microsoft SMTP Server id
	14.1.225.23; Tue, 9 Oct 2012 08:06:25 +0000
X-WSS-ID: 0MBM96N-01-7LJ-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 21BFB102805F;	Tue,  9 Oct 2012 03:06:23 -0500 (CDT)
Received: from SAUSEXDAG05.amd.com (163.181.55.6) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 9 Oct 2012 03:06:57 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag05.amd.com
	(163.181.55.6) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Tue, 9 Oct 2012 03:06:23 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Tue, 9 Oct 2012
	04:06:21 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id F29CF49C1E6; Tue,  9 Oct 2012
	09:06:19 +0100 (BST)
Message-ID: <5073DAFB.4040004@amd.com>
Date: Tue, 9 Oct 2012 10:06:19 +0200
From: Wei Wang 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120421 Thunderbird/12.0
MIME-Version: 1.0
To: Jan Beulich , Keir Fraser ,
	"xen-devel@lists.xensource.com" 
Content-Type: multipart/mixed; boundary="------------060606020707020605050206"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] x86/amd: Fix xen_apic_write warnings in Dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------060606020707020605050206
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

Hi, this patch fixes a xen_apic_write warnings in Dom0

[    0.020294] ------------[ cut here ]------------
[    0.020311] WARNING: at arch/x86/xen/enlighten.c:730
xen_apic_write+0x15/0x17()
[    0.020318] Hardware name: empty
[    0.020323] Modules linked in:
[    0.020334] Pid: 1, comm: swapper/0 Not tainted 3.3.8 #7
[    0.020340] Call Trace:
[    0.020354]  [] warn_slowpath_common+0x80/0x98
[    0.020369]  [] warn_slowpath_null+0x15/0x17
[    0.020378]  [] xen_apic_write+0x15/0x17
[    0.020392]  [] perf_events_lapic_init+0x2e/0x30
[    0.020410]  [] init_hw_perf_events+0x250/0x407
[    0.020419]  [] ? check_bugs+0x2d/0x2d
[    0.020430]  [] do_one_initcall+0x7a/0x131
[    0.020444]  [] kernel_init+0x91/0x15d
[    0.020456]  [] kernel_thread_helper+0x4/0x10
[    0.020471]  [] ? retint_restore_args+0x5/0x6
[    0.020481]  [] ? gs_change+0x13/0x13
[    0.020500] ---[ end trace a7919e7f17c0a725 ]---

Kernel function check_hw_exists() writes 0xabcd to msr 0xc0010201 
(Performance Event Counter 0) and read it again to check if it is 
running as dom0. Early amd cpus does not reset perf counters during warm 
reboot. If the kernel is booted with bare metal and then as a dom0, the 
content of msr 0xc0010201 will stay and the checking will
pass and PMU will be enabled unexpectedly.

Signed-off-by: Wei Wang 

Thanks
Wei



--------------060606020707020605050206
Content-Type: text/plain; charset="UTF-8";
	name="0001-Fix-xen_apic_write-warnings-in-Dom0.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="0001-Fix-xen_apic_write-warnings-in-Dom0.patch"
Content-Description: 0001-Fix-xen_apic_write-warnings-in-Dom0.patch

>From 5cb3c3ed7db525ccb44660ed30890ffeb00b2ea8 Mon Sep 17 00:00:00 2001
From: Wei Wang 
Date: Mon, 8 Oct 2012 15:48:55 +0200
Subject: [PATCH] x86/amd: Fix xen_apic_write warnings in Dom0

[    0.020294] ------------[ cut here ]------------
[    0.020311] WARNING: at arch/x86/xen/enlighten.c:730
xen_apic_write+0x15/0x17()
[    0.020318] Hardware name: empty
[    0.020323] Modules linked in:
[    0.020334] Pid: 1, comm: swapper/0 Not tainted 3.3.8 #7
[    0.020340] Call Trace:
[    0.020354]  [] warn_slowpath_common+0x80/0x98
[    0.020369]  [] warn_slowpath_null+0x15/0x17
[    0.020378]  [] xen_apic_write+0x15/0x17
[    0.020392]  [] perf_events_lapic_init+0x2e/0x30
[    0.020410]  [] init_hw_perf_events+0x250/0x407
[    0.020419]  [] ? check_bugs+0x2d/0x2d
[    0.020430]  [] do_one_initcall+0x7a/0x131
[    0.020444]  [] kernel_init+0x91/0x15d
[    0.020456]  [] kernel_thread_helper+0x4/0x10
[    0.020471]  [] ? retint_restore_args+0x5/0x6
[    0.020481]  [] ? gs_change+0x13/0x13
[    0.020500] ---[ end trace a7919e7f17c0a725 ]---

Kernel function check_hw_exists() writes 0xabcd to msr 0xc0010201 (Performance Event
Counter 0) and read it again to check if it is running as dom0. Early amd cpus does
not reset perf counters during warm reboot. If the kernel is booted with bare metal
and then as a dom0, the content of msr 0xc0010201 will stay and the checking will
pass and PMU will be enabled unexpectedly.

Signed-off-by: Wei Wang 
---
 xen/arch/x86/cpu/amd.c |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
index c95349f..5909f8c 100644
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -485,6 +485,17 @@ static void __devinit init_amd(struct cpuinfo_x86 *c)
 	if (c->x86 > 0x11)
 		set_bit(X86_FEATURE_ARAT, c->x86_capability);
 
+	/* 
+	 * Prior to Family 0x14, perf counters are not reset during warm reboot.  
+	 * We have to reset them manually.
+	 */
+	if (c->x86 < 0x14) {
+		wrmsrl(MSR_K7_PERFCTR0, 0);
+		wrmsrl(MSR_K7_PERFCTR1, 0);
+		wrmsrl(MSR_K7_PERFCTR2, 0);
+		wrmsrl(MSR_K7_PERFCTR3, 0);
+	}
+
 	if (cpuid_edx(0x80000007) & (1 << 10)) {
 		rdmsr(MSR_K7_HWCR, l, h);
 		l |= (1 << 27); /* Enable read-only APERF/MPERF bit */
-- 
1.7.4


--------------060606020707020605050206
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------060606020707020605050206--


From xen-devel-bounces@lists.xen.org Tue Oct 09 08:10:13 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 08:10:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLUsb-0006Vk-Fv; Tue, 09 Oct 2012 08:09:29 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLUsa-0006Vb-0B
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 08:09:28 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-13.tower-27.messagelabs.com!1349770158!9254234!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19445 invoked from network); 9 Oct 2012 08:09:19 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Oct 2012 08:09:19 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id CD40540084B
	for ;
	Tue,  9 Oct 2012 10:09:17 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id b1sRkGA7b4mV for ;
	Tue,  9 Oct 2012 10:09:17 +0200 (CEST)
Received: from [192.168.178.50]
	(host51-78-dynamic.2-87-r.retail.telecomitalia.it [87.2.78.51])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id 396F040083A
	for ;
	Tue,  9 Oct 2012 10:09:17 +0200 (CEST)
Message-ID: <5073DBAA.8010509@tiscali.it>
Date: Tue, 09 Oct 2012 10:09:14 +0200
From: Fabio Fantoni 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: xen-devel 
Subject: [Xen-devel] Question about antispoofing and sys-flood protection on
	xen bridges
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============7943861595465365222=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============7943861595465365222==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090501080103000708070104"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms090501080103000708070104
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

I'm in doubt about antispoofing and sys-flood protection on dom0 and=20
their effect on xen bridges.
If I add these parameters on /etc/sysctl.conf:
net.ipv4.conf.default.rp_filter=3D1
net.ipv4.conf.all.rp_filter=3D1
net.ipv4.tcp_syncookies=3D1
Can they give problem on xen bridges and/or its performance?
Thanks for any reply


--------------ms090501080103000708070104
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Firma crittografica S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa
Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG
EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi
aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV
10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU
Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR
MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl
Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A
jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2
YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh
bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC
AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw
gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC
AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz
cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks
IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug
b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh
cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv
bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI
KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j
YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN
BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8
h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1
kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8
oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+
qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEyMTAwOTA4MDkxNFowIwYJKoZIhvcNAQkEMRYEFHVYzTCdkG/kD4zwgZHafAF4
yWu9MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAID1zO4FRsaVX4sALH3KYd4sO
FO6wT1E14/JzbDaNGrkVVWd16caRW89+W+/URVpeiy/R8scXNzuPtgENOLh8KZIQh3UKshEW
vJf9ssY4+3G1s8MsNT5p9Lmdwhk6SmOru1gjhG6kmSnZVeDY3FoLnQmd4Ch3n9T7f+SVBTfz
f7oxmBZx3ZwjHBa26JFth29Qahq4ks/OnMHvVAKNu2TxpkWSpflOAS7Up9mMtq/gjvK9Ov3W
ysWgezMUkawtS7lG74w6lXU/g2KE+pGnydx7apdd2MvQ5bEc/LHgiTpedJadmGMbZdDM8lCP
AfiFRe0+Sl6p3vY96WiDSVwzXDxg1AAAAAAAAA==
--------------ms090501080103000708070104--


--===============7943861595465365222==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7943861595465365222==--


From xen-devel-bounces@lists.xen.org Tue Oct 09 08:10:13 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 08:10:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLUsb-0006Vk-Fv; Tue, 09 Oct 2012 08:09:29 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLUsa-0006Vb-0B
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 08:09:28 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-13.tower-27.messagelabs.com!1349770158!9254234!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19445 invoked from network); 9 Oct 2012 08:09:19 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Oct 2012 08:09:19 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id CD40540084B
	for ;
	Tue,  9 Oct 2012 10:09:17 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id b1sRkGA7b4mV for ;
	Tue,  9 Oct 2012 10:09:17 +0200 (CEST)
Received: from [192.168.178.50]
	(host51-78-dynamic.2-87-r.retail.telecomitalia.it [87.2.78.51])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id 396F040083A
	for ;
	Tue,  9 Oct 2012 10:09:17 +0200 (CEST)
Message-ID: <5073DBAA.8010509@tiscali.it>
Date: Tue, 09 Oct 2012 10:09:14 +0200
From: Fabio Fantoni 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: xen-devel 
Subject: [Xen-devel] Question about antispoofing and sys-flood protection on
	xen bridges
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============7943861595465365222=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============7943861595465365222==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090501080103000708070104"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms090501080103000708070104
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

I'm in doubt about antispoofing and sys-flood protection on dom0 and=20
their effect on xen bridges.
If I add these parameters on /etc/sysctl.conf:
net.ipv4.conf.default.rp_filter=3D1
net.ipv4.conf.all.rp_filter=3D1
net.ipv4.tcp_syncookies=3D1
Can they give problem on xen bridges and/or its performance?
Thanks for any reply


--------------ms090501080103000708070104
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Firma crittografica S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa
Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG
EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi
aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV
10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU
Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR
MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl
Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A
jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2
YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh
bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC
AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw
gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC
AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz
cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks
IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug
b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh
cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv
bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI
KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j
YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN
BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8
h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1
kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8
oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+
qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEyMTAwOTA4MDkxNFowIwYJKoZIhvcNAQkEMRYEFHVYzTCdkG/kD4zwgZHafAF4
yWu9MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAID1zO4FRsaVX4sALH3KYd4sO
FO6wT1E14/JzbDaNGrkVVWd16caRW89+W+/URVpeiy/R8scXNzuPtgENOLh8KZIQh3UKshEW
vJf9ssY4+3G1s8MsNT5p9Lmdwhk6SmOru1gjhG6kmSnZVeDY3FoLnQmd4Ch3n9T7f+SVBTfz
f7oxmBZx3ZwjHBa26JFth29Qahq4ks/OnMHvVAKNu2TxpkWSpflOAS7Up9mMtq/gjvK9Ov3W
ysWgezMUkawtS7lG74w6lXU/g2KE+pGnydx7apdd2MvQ5bEc/LHgiTpedJadmGMbZdDM8lCP
AfiFRe0+Sl6p3vY96WiDSVwzXDxg1AAAAAAAAA==
--------------ms090501080103000708070104--


--===============7943861595465365222==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7943861595465365222==--


From xen-devel-bounces@lists.xen.org Tue Oct 09 08:14:57 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 08:14:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLUxF-0006gh-6U; Tue, 09 Oct 2012 08:14:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLUxE-0006gc-A3
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 08:14:16 +0000
Received: from [85.158.138.51:26145] by server-11.bemta-3.messagelabs.com id
	CC/4A-21460-7DCD3705; Tue, 09 Oct 2012 08:14:15 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1349770454!31941829!1
X-Originating-IP: [213.199.154.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 314 invoked from network); 9 Oct 2012 08:14:15 -0000
Received: from am1ehsobe004.messaging.microsoft.com (HELO
	am1outboundpool.messaging.microsoft.com) (213.199.154.207)
	by server-9.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	9 Oct 2012 08:14:15 -0000
Received: from mail16-am1-R.bigfish.com (10.3.201.238) by
	AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id
	14.1.225.23; Tue, 9 Oct 2012 08:14:14 +0000
Received: from mail16-am1 (localhost [127.0.0.1])	by mail16-am1-R.bigfish.com
	(Postfix) with ESMTP id 67F994402D2;
	Tue,  9 Oct 2012 08:14:14 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: -1
X-BigFish: VPS-1(zzbb2dI98dI9371I1432I853kzz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh137ah13b6h1441h1155h)
Received: from mail16-am1 (localhost.localdomain [127.0.0.1]) by mail16-am1
	(MessageSwitch) id 1349770453166559_32280;
	Tue,  9 Oct 2012 08:14:13 +0000 (UTC)
Received: from AM1EHSMHS010.bigfish.com (unknown [10.3.201.242])	by
	mail16-am1.bigfish.com (Postfix) with ESMTP id 1BE8436004B;
	Tue,  9 Oct 2012 08:14:13 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS010.bigfish.com (10.3.207.110) with Microsoft SMTP Server id
	14.1.225.23; Tue, 9 Oct 2012 08:14:12 +0000
X-WSS-ID: 0MBM9JK-02-207-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2005FC808B;	Tue,  9 Oct 2012 03:14:08 -0500 (CDT)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 9 Oct 2012 03:14:45 -0500
Received: from storexhtp01.amd.com (172.24.4.3) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Tue, 9 Oct 2012 03:14:10 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Tue, 9 Oct 2012
	04:14:09 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 377DA49C1E6; Tue,  9 Oct 2012
	09:14:06 +0100 (BST)
Message-ID: <5073DCCE.1000504@amd.com>
Date: Tue, 9 Oct 2012 10:14:06 +0200
From: Wei Wang 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120421 Thunderbird/12.0
MIME-Version: 1.0
To: Jan Beulich 
References: <506B1758020000780009F1CD@nat28.tlf.novell.com>
In-Reply-To: <506B1758020000780009F1CD@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: xen-devel 
Subject: Re: [Xen-devel] [PATCH] AMD IOMMU: fix find_iommu_from_bdf_cap()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Acked. Thanks.
Wei

On 10/02/2012 04:33 PM, Jan Beulich wrote:
> The arguments passed for the "cap_offset" parameter get read from 16-
> bit fields, so the parameter should also have (at least) 16 bits.
>
> While fixing this I also noticed that this was yet another case where
> PCI segment information wasn't properly propagated, so a respective
> first parameter gets added to the function at once.
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/drivers/passthrough/amd/iommu_acpi.c
> +++ b/xen/drivers/passthrough/amd/iommu_acpi.c
> @@ -86,12 +86,13 @@ static void __init add_ivrs_mapping_entr
>   }
>
>   static struct amd_iommu * __init find_iommu_from_bdf_cap(
> -    u16 bdf, u8 cap_offset)
> +    u16 seg, u16 bdf, u16 cap_offset)
>   {
>       struct amd_iommu *iommu;
>
>       for_each_amd_iommu ( iommu )
> -        if ( (iommu->bdf == bdf)&&  (iommu->cap_offset == cap_offset) )
> +        if ( (iommu->seg == seg)&&  (iommu->bdf == bdf)&&
> +             (iommu->cap_offset == cap_offset) )
>               return iommu;
>
>       return NULL;
> @@ -319,10 +320,11 @@ static int __init parse_ivmd_device_iomm
>       const struct acpi_ivrs_memory *ivmd_block,
>       unsigned long base, unsigned long limit, u8 iw, u8 ir)
>   {
> +    int seg = 0; /* XXX */
>       struct amd_iommu *iommu;
>
>       /* find target IOMMU */
> -    iommu = find_iommu_from_bdf_cap(ivmd_block->header.device_id,
> +    iommu = find_iommu_from_bdf_cap(seg, ivmd_block->header.device_id,
>                                       ivmd_block->aux_data);
>       if ( !iommu )
>       {
> @@ -669,7 +671,8 @@ static int __init parse_ivhd_block(const
>           return -ENODEV;
>       }
>
> -    iommu = find_iommu_from_bdf_cap(ivhd_block->header.device_id,
> +    iommu = find_iommu_from_bdf_cap(ivhd_block->pci_segment_group,
> +                                    ivhd_block->header.device_id,
>                                       ivhd_block->capability_offset);
>       if ( !iommu )
>       {
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 08:14:57 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 08:14:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLUxF-0006gh-6U; Tue, 09 Oct 2012 08:14:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLUxE-0006gc-A3
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 08:14:16 +0000
Received: from [85.158.138.51:26145] by server-11.bemta-3.messagelabs.com id
	CC/4A-21460-7DCD3705; Tue, 09 Oct 2012 08:14:15 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1349770454!31941829!1
X-Originating-IP: [213.199.154.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 314 invoked from network); 9 Oct 2012 08:14:15 -0000
Received: from am1ehsobe004.messaging.microsoft.com (HELO
	am1outboundpool.messaging.microsoft.com) (213.199.154.207)
	by server-9.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	9 Oct 2012 08:14:15 -0000
Received: from mail16-am1-R.bigfish.com (10.3.201.238) by
	AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id
	14.1.225.23; Tue, 9 Oct 2012 08:14:14 +0000
Received: from mail16-am1 (localhost [127.0.0.1])	by mail16-am1-R.bigfish.com
	(Postfix) with ESMTP id 67F994402D2;
	Tue,  9 Oct 2012 08:14:14 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: -1
X-BigFish: VPS-1(zzbb2dI98dI9371I1432I853kzz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh137ah13b6h1441h1155h)
Received: from mail16-am1 (localhost.localdomain [127.0.0.1]) by mail16-am1
	(MessageSwitch) id 1349770453166559_32280;
	Tue,  9 Oct 2012 08:14:13 +0000 (UTC)
Received: from AM1EHSMHS010.bigfish.com (unknown [10.3.201.242])	by
	mail16-am1.bigfish.com (Postfix) with ESMTP id 1BE8436004B;
	Tue,  9 Oct 2012 08:14:13 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS010.bigfish.com (10.3.207.110) with Microsoft SMTP Server id
	14.1.225.23; Tue, 9 Oct 2012 08:14:12 +0000
X-WSS-ID: 0MBM9JK-02-207-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2005FC808B;	Tue,  9 Oct 2012 03:14:08 -0500 (CDT)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 9 Oct 2012 03:14:45 -0500
Received: from storexhtp01.amd.com (172.24.4.3) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Tue, 9 Oct 2012 03:14:10 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Tue, 9 Oct 2012
	04:14:09 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 377DA49C1E6; Tue,  9 Oct 2012
	09:14:06 +0100 (BST)
Message-ID: <5073DCCE.1000504@amd.com>
Date: Tue, 9 Oct 2012 10:14:06 +0200
From: Wei Wang 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120421 Thunderbird/12.0
MIME-Version: 1.0
To: Jan Beulich 
References: <506B1758020000780009F1CD@nat28.tlf.novell.com>
In-Reply-To: <506B1758020000780009F1CD@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: xen-devel 
Subject: Re: [Xen-devel] [PATCH] AMD IOMMU: fix find_iommu_from_bdf_cap()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Acked. Thanks.
Wei

On 10/02/2012 04:33 PM, Jan Beulich wrote:
> The arguments passed for the "cap_offset" parameter get read from 16-
> bit fields, so the parameter should also have (at least) 16 bits.
>
> While fixing this I also noticed that this was yet another case where
> PCI segment information wasn't properly propagated, so a respective
> first parameter gets added to the function at once.
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/drivers/passthrough/amd/iommu_acpi.c
> +++ b/xen/drivers/passthrough/amd/iommu_acpi.c
> @@ -86,12 +86,13 @@ static void __init add_ivrs_mapping_entr
>   }
>
>   static struct amd_iommu * __init find_iommu_from_bdf_cap(
> -    u16 bdf, u8 cap_offset)
> +    u16 seg, u16 bdf, u16 cap_offset)
>   {
>       struct amd_iommu *iommu;
>
>       for_each_amd_iommu ( iommu )
> -        if ( (iommu->bdf == bdf)&&  (iommu->cap_offset == cap_offset) )
> +        if ( (iommu->seg == seg)&&  (iommu->bdf == bdf)&&
> +             (iommu->cap_offset == cap_offset) )
>               return iommu;
>
>       return NULL;
> @@ -319,10 +320,11 @@ static int __init parse_ivmd_device_iomm
>       const struct acpi_ivrs_memory *ivmd_block,
>       unsigned long base, unsigned long limit, u8 iw, u8 ir)
>   {
> +    int seg = 0; /* XXX */
>       struct amd_iommu *iommu;
>
>       /* find target IOMMU */
> -    iommu = find_iommu_from_bdf_cap(ivmd_block->header.device_id,
> +    iommu = find_iommu_from_bdf_cap(seg, ivmd_block->header.device_id,
>                                       ivmd_block->aux_data);
>       if ( !iommu )
>       {
> @@ -669,7 +671,8 @@ static int __init parse_ivhd_block(const
>           return -ENODEV;
>       }
>
> -    iommu = find_iommu_from_bdf_cap(ivhd_block->header.device_id,
> +    iommu = find_iommu_from_bdf_cap(ivhd_block->pci_segment_group,
> +                                    ivhd_block->header.device_id,
>                                       ivhd_block->capability_offset);
>       if ( !iommu )
>       {
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 08:20:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 08:20:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLV2K-0006qw-VT; Tue, 09 Oct 2012 08:19:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLV2J-0006qr-7H
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 08:19:31 +0000
Received: from [85.158.139.83:17649] by server-12.bemta-5.messagelabs.com id
	1E/54-19095-21ED3705; Tue, 09 Oct 2012 08:19:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1349770769!33343456!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMyNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 845 invoked from network); 9 Oct 2012 08:19:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 08:19:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,558,1344211200"; d="scan'208";a="15029394"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 08:19:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	09:19:29 +0100
Message-ID: <1349770768.21847.67.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Olaf Hering 
Date: Tue, 9 Oct 2012 09:19:28 +0100
In-Reply-To: 
References: 
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] pygrub: correct typo in --args assignment
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-10-08 at 18:17 +0100, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering 
> # Date 1349716567 -7200
> # Node ID de76ea76418f19248fd3e5541344a51c38c716ae
> # Parent  c9f621893a05e3e447ba6770f8ae912721712569
> pygrub: correct typo in --args assignment
> 
> If pygrub was called with --args="some thing", then this string should
> be append to the kernel command line.  But the last changeset
> 25941:795c493fe561 contained a typo, it assigns 'args' instead of 'arg'.
> 
> Rename the local variable which holds the string from the domain config
> file to avoid further confusion.
> 
> Signed-off-by: Olaf Hering 

Acked and committed, thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 08:20:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 08:20:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLV2K-0006qw-VT; Tue, 09 Oct 2012 08:19:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLV2J-0006qr-7H
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 08:19:31 +0000
Received: from [85.158.139.83:17649] by server-12.bemta-5.messagelabs.com id
	1E/54-19095-21ED3705; Tue, 09 Oct 2012 08:19:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1349770769!33343456!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMyNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 845 invoked from network); 9 Oct 2012 08:19:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 08:19:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,558,1344211200"; d="scan'208";a="15029394"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 08:19:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	09:19:29 +0100
Message-ID: <1349770768.21847.67.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Olaf Hering 
Date: Tue, 9 Oct 2012 09:19:28 +0100
In-Reply-To: 
References: 
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] pygrub: correct typo in --args assignment
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-10-08 at 18:17 +0100, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering 
> # Date 1349716567 -7200
> # Node ID de76ea76418f19248fd3e5541344a51c38c716ae
> # Parent  c9f621893a05e3e447ba6770f8ae912721712569
> pygrub: correct typo in --args assignment
> 
> If pygrub was called with --args="some thing", then this string should
> be append to the kernel command line.  But the last changeset
> 25941:795c493fe561 contained a typo, it assigns 'args' instead of 'arg'.
> 
> Rename the local variable which holds the string from the domain config
> file to avoid further confusion.
> 
> Signed-off-by: Olaf Hering 

Acked and committed, thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 09:22:21 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 09:22:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLW0L-0007Qe-AD; Tue, 09 Oct 2012 09:21:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLW0K-0007QZ-7i
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 09:21:32 +0000
Received: from [85.158.139.211:21704] by server-3.bemta-5.messagelabs.com id
	9F/D4-16108-B9CE3705; Tue, 09 Oct 2012 09:21:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1349774490!20090952!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMyNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1937 invoked from network); 9 Oct 2012 09:21:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 09:21:31 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15031193"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 09:21:30 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	10:21:30 +0100
Message-ID: <1349774489.21847.102.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: George Shuklin 
Date: Tue, 9 Oct 2012 10:21:29 +0100
In-Reply-To: <50735360.2040502@gmail.com>
References: <50735360.2040502@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] event channel internals
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-10-08 at 23:27 +0100, George Shuklin wrote:
> Good day.
> 
> I'm trying to dig inside xen, but I still not really understand all 
> stuff about event channels. How exactly domain-to-domain communication 
> looks?

I'm afraid that's a rather open ended question.
http://wiki.xen.org/wiki/Asking_Xen_Devel_Questions might help you to
formulate something we can answer.

To help you get started the event channel hypercall interface is
http://xenbits.xen.org/docs/unstable/hypercall/include,public,event_channel.h.html
there is also some documentation in
http://xenbits.xen.org/docs/unstable/hypercall/include,public,xen.h.html#Struct_shared_info

You can find the kernel side in drivers/xen/events.c (mostly).

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 09:22:21 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 09:22:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLW0L-0007Qe-AD; Tue, 09 Oct 2012 09:21:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLW0K-0007QZ-7i
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 09:21:32 +0000
Received: from [85.158.139.211:21704] by server-3.bemta-5.messagelabs.com id
	9F/D4-16108-B9CE3705; Tue, 09 Oct 2012 09:21:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1349774490!20090952!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMyNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1937 invoked from network); 9 Oct 2012 09:21:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 09:21:31 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15031193"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 09:21:30 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	10:21:30 +0100
Message-ID: <1349774489.21847.102.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: George Shuklin 
Date: Tue, 9 Oct 2012 10:21:29 +0100
In-Reply-To: <50735360.2040502@gmail.com>
References: <50735360.2040502@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] event channel internals
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-10-08 at 23:27 +0100, George Shuklin wrote:
> Good day.
> 
> I'm trying to dig inside xen, but I still not really understand all 
> stuff about event channels. How exactly domain-to-domain communication 
> looks?

I'm afraid that's a rather open ended question.
http://wiki.xen.org/wiki/Asking_Xen_Devel_Questions might help you to
formulate something we can answer.

To help you get started the event channel hypercall interface is
http://xenbits.xen.org/docs/unstable/hypercall/include,public,event_channel.h.html
there is also some documentation in
http://xenbits.xen.org/docs/unstable/hypercall/include,public,xen.h.html#Struct_shared_info

You can find the kernel side in drivers/xen/events.c (mostly).

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 09:24:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 09:24:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLW30-0007Yb-0Q; Tue, 09 Oct 2012 09:24:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLW2x-0007YR-Qa
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 09:24:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1349774605!10646511!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMyNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7134 invoked from network); 9 Oct 2012 09:23:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 09:23:27 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15031283"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 09:23:10 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	10:23:09 +0100
Message-ID: <1349774588.21847.105.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Sander Eikelenboom 
Date: Tue, 9 Oct 2012 10:23:08 +0100
In-Reply-To: <120335733.20121009042424@eikelenboom.it>
References: 
	<729626082.20121006002054@eikelenboom.it>
	<20121007233444.GA26929@localhost.localdomain>
	<1349686461.18008.18.camel@zakaz.uk.xensource.com>
	<120335733.20121009042424@eikelenboom.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk ,
	"xen-devel@lists.xensource.com" ,
	konrad 
Subject: Re: [Xen-devel] Kernel 3.7.0-pre-rc1 kernel BUG at
 drivers/net/xen-netback/netback.c:405 RIP: e030:[]
 [] netbk_gop_frag_copy+0x379/0x380
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-09 at 03:24 +0100, Sander Eikelenboom wrote:

> >> Looking at the code, this is what we get:
> >>
> >>         /* Data must not cross a page boundary. */
> >>         BUG_ON(size + offset > PAGE_SIZE);
> >>[...]
> After applying the debug patch:
> 
> [  197.876304] netbk_gop_frag_copy failed: skb frag 0 page
> [  197.884299] copying from offset 0, len 1628

WTF! This turns into BUG_ON(0 + 1628 > PAGE_SIZE) (where PAGE_SIZE is
4096) which simply should not be triggering.

Perhaps I screwed up the debugging patch... investigates... no I don't
think so, but someone should definitely check my working.

For belt and braces can you change, in netbk_gop_frag_copy:
	/* Data must not cross a page boundary. */
	if (size + offset > PAGE_SIZE)
		return -1;
into:
	/* Data must not cross a page boundary. */
	if (size + offset > PAGE_SIZE) {
		printk(KERN_CRIT "netbk_gop_frag_copy: size %lx offset %lx\n => %lx > %lx\n",
		       size, offset, size + offset, PAGE_SIZE);
		return -1;
	}

This made me notice that offset and len in the caller are variously
unsigned int, u16 or u32 while gop_frag_copy takes them as unsigned
longs. None of the numbers involved here are anywhere big enough to
cause any sort of overflow related error though.

> [  197.892781] page:ffffea0000b18400 count:3 mapcount:0 mapping:          (null) index:0x0
> [  197.900778] page flags: 0x40000000004000(head)
> [  197.907074] ------------[ cut here ]------------
> [  197.913345] kernel BUG at drivers/net/xen-netback/netback.c:546!
> [  197.919626] invalid opcode: 0000 [#1] PREEMPT SMP
> [  197.921573] xen_bridge: port 10(vif10.0) entered forwarding state
> [  197.932106] Modules linked in:
> [  197.938370] CPU 0
> [  197.938420] Pid: 1180, comm: netback/0 Not tainted 3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)
> [  197.951203] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
> [  197.957775] RSP: e02b:ffff880037911c20  EFLAGS: 00010282
> [  197.964290] RAX: 0000000000000001 RBX: ffff880036862ee0 RCX: 0000000000000000
> [  197.970956] RDX: 0000000000000001 RSI: 0000000000000001 RDI: ffff8800379102b0
> [  197.977679] RBP: ffff880037911d50 R08: 0000000000000002 R09: 0000000000000000
> [  197.984361] R10: 0000000000000001 R11: ffff880039925e40 R12: 0000000000000030
> [  197.990958] R13: 0000000000000000 R14: ffff880031e71800 R15: 0000000000000001
> [  197.997459] FS:  00007fb5dfcf7700(0000) GS:ffff88003f800000(0000) knlGS:0000000000000000
> [  198.004123] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> [  198.010827] CR2: 00007fb5d802d000 CR3: 0000000031fd3000 CR4: 0000000000000660
> [  198.017534] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [  198.024168] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [  198.030717] Process netback/0 (pid: 1180, threadinfo ffff880037910000, task ffff88003997d190)
> [  198.037326] Stack:
> [  198.043817]  ffff880037911d1c ffff88003997d840 ffff880037911d00 ffff880037911c80
> [  198.050573]  ffffffff00000001 0000000000000662 ffffc90010824bb8 ffffc90010820050
> [  198.057413]  0000000001080083 ffffc90010820000 0000000000000000 ffff880031cf09c0
> [  198.064228] Call Trace:
> [  198.070887]  [] ? trace_hardirqs_on+0xd/0x10
> [  198.077604]  [] xen_netbk_kthread+0xba/0xa90
> [  198.084394]  [] ? try_to_wake_up+0x1b6/0x310
> [  198.091109]  [] ? wake_up_bit+0x40/0x40
> [  198.097726]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
> [  198.104343]  [] kthread+0xd6/0xe0
> [  198.111001]  [] kernel_thread_helper+0x4/0x10
> [  198.117737]  [] ? retint_restore_args+0x13/0x13
> [  198.124425]  [] ? gs_change+0x13/0x13
> [  198.131008] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 46 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7
> [  198.145094] RIP  [] xen_netbk_rx_action+0x89a/0x910
> [  198.152192]  RSP 
> [  198.159344] ---[ end trace cbdd0e4e80268fa8 ]---
> [  199.703539] tty_init_dev: 2 callbacks suppressed
> [  200.712098] device vif12.0 entered promiscuous mode
> [  201.010433] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
> [  201.020644] xen_bridge: port 12(vif12.0) entered forwarding state
> [  201.027833] xen_bridge: port 12(vif12.0) entered forwarding state
> [  206.774576] netbk_gop_frag_copy failed: skb frag 0 page
> [  206.777945] device vif13.0 entered promiscuous mode
> [  206.788845] copying from offset 1ba4, len 2c1
> [  206.795791] page:ffffea0000b18400 count:6 mapcount:0 mapping:          (null) index:0x0
> [  206.802771] page flags: 0x40000000004000(head)
> [  206.809619] ------------[ cut here ]------------
> [  206.816498] kernel BUG at drivers/net/xen-netback/netback.c:546!
> [  206.823465] invalid opcode: 0000 [#2] PREEMPT SMP
> [  206.830354] Modules linked in:
> [  206.837176] CPU 3
> [  206.837234] Pid: 1183, comm: netback/3 Tainted: G      D      3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)
> [  206.850881] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
> [  206.857935] RSP: e02b:ffff880037917c20  EFLAGS: 00010282
> [  206.864972] RAX: 0000000000000001 RBX: ffff880003313ae0 RCX: 0000000000000000
> [  206.872049] RDX: ffff88003997b0f0 RSI: 0000000000000001 RDI: ffff8800379102b0
> [  206.879147] RBP: ffff880037917d50 R08: 0000000000000002 R09: 0000000000000000
> [  206.886242] R10: 0000000000000001 R11: ffff880039925640 R12: 0000000000000030
> [  206.893163] R13: 0000000000000000 R14: ffff88002c7c4400 R15: 0000000000000001
> [  206.900041] FS:  00007f800341a700(0000) GS:ffff88003f8c0000(0000) knlGS:0000000000000000
> [  206.907145] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> [  206.914126] CR2: 00007f8002b31fb0 CR3: 0000000001c0b000 CR4: 0000000000000660
> [  206.921181] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [  206.927996] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [  206.934711] Process netback/3 (pid: 1183, threadinfo ffff880037916000, task ffff88003997b0f0)
> [  206.941494] Stack:
> [  206.948105]  ffff880037917d1c ffff880037916010 ffff880037917d00 ffff880037917c80
> [  206.955062]  ffffffff810800b5 00000000000000ba ffffc900108466e0 ffffc90010841b78
> [  206.962007]  0000000101080083 ffffc90010841b28 0000000100000000 ffff88002c5bb9c0
> [  206.968967] Call Trace:
> [  206.975830]  [] ? __alloc_workqueue_key+0x265/0x5d0
> [  206.982789]  [] ? trace_hardirqs_on+0xd/0x10
> [  206.989662]  [] xen_netbk_kthread+0xba/0xa90
> [  206.996570]  [] ? try_to_wake_up+0x1b6/0x310
> [  207.003523]  [] ? wake_up_bit+0x40/0x40
> [  207.010333]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
> [  207.017171]  [] kthread+0xd6/0xe0
> [  207.023890]  [] kernel_thread_helper+0x4/0x10
> [  207.030540]  [] ? retint_restore_args+0x13/0x13
> [  207.037275]  [] ? gs_change+0x13/0x13
> [  207.043890] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 46 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7
> [  207.057976] RIP  [] xen_netbk_rx_action+0x89a/0x910
> [  207.065064]  RSP 
> [  207.072056] ---[ end trace cbdd0e4e80268fa9 ]---
> [  207.079366] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
> [  207.090256] vpn_bridge: port 1(vif13.0) entered forwarding state
> [  207.097403] vpn_bridge: port 1(vif13.0) entered forwarding state
> [  208.636257] xen_bridge: port 11(vif11.0) entered forwarding state
> [  211.515779] netbk_gop_frag_copy failed: skb frag 0 page
> [  211.522711] copying from offset 2126, len 2c1
> [  211.529403] page:ffffea0000b18400 count:8 mapcount:0 mapping:          (null) index:0x0
> [  211.536142] page flags: 0x40000000004000(head)
> [  211.542942] ------------[ cut here ]------------
> [  211.549664] kernel BUG at drivers/net/xen-netback/netback.c:546!
> [  211.556408] invalid opcode: 0000 [#3] PREEMPT SMP
> [  211.563168] Modules linked in:
> [  211.569739] CPU 4
> [  211.569789] Pid: 1184, comm: netback/4 Tainted: G      D      3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)
> [  211.583126] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
> [  211.590041] RSP: e02b:ffff880037921c20  EFLAGS: 00010282
> [  211.596868] RAX: 0000000000000001 RBX: ffff8800375bc4e0 RCX: 0000000000000000
> [  211.603890] RDX: ffff88003997a0a0 RSI: 0000000000000001 RDI: ffff8800379202b0
> [  211.610792] RBP: ffff880037921d50 R08: 0000000000000002 R09: 0000000000000000
> [  211.617608] R10: 0000000000000001 R11: ffff8800399249e0 R12: 0000000000000030
> [  211.624537] R13: 0000000000000000 R14: ffff88002b98d400 R15: 0000000000000001
> [  211.631302] FS:  00007f332d735740(0000) GS:ffff88003f900000(0000) knlGS:0000000000000000
> [  211.638090] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> [  211.644965] CR2: 00007f1023d22000 CR3: 0000000031fba000 CR4: 0000000000000660
> [  211.651894] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [  211.658652] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [  211.665288] Process netback/4 (pid: 1184, threadinfo ffff880037920000, task ffff88003997a0a0)
> [  211.671884] Stack:
> [  211.678376]  ffff880037921d1c ffff880037920010 ffff880037921d00 ffff880037921c80
> [  211.685145]  ffffffff810800b5 00000000000000ba ffffc90010851a98 ffffc9001084cf30
> [  211.691837]  0000000101080083 ffffc9001084cee0 0000000100000000 ffff88002c5bd9c0
> [  211.698581] Call Trace:
> [  211.705349]  [] ? __alloc_workqueue_key+0x265/0x5d0
> [  211.712156]  [] ? trace_hardirqs_on+0xd/0x10
> [  211.718907]  [] xen_netbk_kthread+0xba/0xa90
> [  211.725654]  [] ? try_to_wake_up+0x1b6/0x310
> [  211.732369]  [] ? wake_up_bit+0x40/0x40
> [  211.739111]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
> [  211.745858]  [] kthread+0xd6/0xe0
> [  211.752449]  [] kernel_thread_helper+0x4/0x10
> [  211.758975]  [] ? retint_restore_args+0x13/0x13
> [  211.765575]  [] ? gs_change+0x13/0x13
> [  211.772016] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 46 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7
> [  211.785816] RIP  [] xen_netbk_rx_action+0x89a/0x910
> [  211.792586]  RSP 
> [  211.799394] ---[ end trace cbdd0e4e80268faa ]---
> [  212.852714] device vif14.0 entered promiscuous mode
> [  213.234995] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
> [  213.245054] xen_bridge: port 13(vif14.0) entered forwarding state
> [  213.252087] xen_bridge: port 13(vif14.0) entered forwarding state
> [  214.691532] netbk_gop_frag_copy failed: skb frag 0 page
> [  214.698515] copying from offset 26a8, len 2c1
> [  214.705472] page:ffffea0000b18400 count:10 mapcount:0 mapping:          (null) index:0x0
> [  214.712415] page flags: 0x40000000004000(head)
> [  214.719170] ------------[ cut here ]------------
> [  214.725887] kernel BUG at drivers/net/xen-netback/netback.c:546!
> [  214.732563] invalid opcode: 0000 [#4] PREEMPT SMP
> [  214.739221] Modules linked in:
> [  214.745808] CPU 5
> [  214.745859] Pid: 1185, comm: netback/5 Tainted: G      D      3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)
> [  214.759156] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
> [  214.766127] RSP: e02b:ffff880037923c20  EFLAGS: 00010282
> [  214.773012] RAX: 0000000000000001 RBX: ffff8800379172e0 RCX: 0000000000000000
> [  214.780010] RDX: ffff880039ac8000 RSI: 0000000000000001 RDI: ffff8800379202b0
> [  214.786988] RBP: ffff880037923d50 R08: 0000000000000002 R09: 0000000000000000
> [  214.793870] R10: 0000000000000001 R11: ffff880039924460 R12: 0000000000000030
> [  214.800812] R13: 0000000000000000 R14: ffff88002b8b4800 R15: 0000000000000001
> [  214.807668] FS:  00007f236d331700(0000) GS:ffff88003f940000(0000) knlGS:0000000000000000
> [  214.814545] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> [  214.821415] CR2: 00007f236c42b6b0 CR3: 0000000039275000 CR4: 0000000000000660
> [  214.828435] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [  214.835337] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [  214.841963] Process netback/5 (pid: 1185, threadinfo ffff880037922000, task ffff880039ac8000)
> [  214.848655] Stack:
> [  214.855220]  ffff880037923d1c ffff880037922010 ffff880037923d00 ffff880037923c80
> [  214.861945]  ffffffff810800b5 00000000000000ba ffffc9001085ce50 ffffc900108582e8
> [  214.868699]  0000000101080083 ffffc90010858298 0000000100000000 ffff880031e939c0
> [  214.875477] Call Trace:
> [  214.882247]  [] ? __alloc_workqueue_key+0x265/0x5d0
> [  214.889083]  [] ? trace_hardirqs_on+0xd/0x10
> [  214.895851]  [] xen_netbk_kthread+0xba/0xa90
> [  214.902612]  [] ? try_to_wake_up+0x1b6/0x310
> [  214.909343]  [] ? wake_up_bit+0x40/0x40
> [  214.916115]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
> [  214.922856]  [] kthread+0xd6/0xe0
> [  214.929527]  [] kernel_thread_helper+0x4/0x10
> [  214.936178]  [] ? retint_restore_args+0x13/0x13
> [  214.942781]  [] ? gs_change+0x13/0x13
> [  214.949279] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 46 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7
> [  214.963107] RIP  [] xen_netbk_rx_action+0x89a/0x910
> [  214.969952]  RSP 
> [  214.976802] ---[ end trace cbdd0e4e80268fab ]---
> [  216.045946] xen_bridge: port 12(vif12.0) entered forwarding state
> [  220.405869] device vif15.0 entered promiscuous mode
> [  220.607946] device vif15.0-emu entered promiscuous mode
> [  220.625075] xen_bridge: port 15(vif15.0-emu) entered forwarding state
> [  220.633333] xen_bridge: port 15(vif15.0-emu) entered forwarding state
> [  220.890237] pciback 0000:06:00.0: restoring config space at offset 0x3c (was 0x100, writing 0x10a)
> [  220.898814] pciback 0000:06:00.0: restoring config space at offset 0x10 (was 0x4, writing 0xf9a00004)
> [  220.907406] pciback 0000:06:00.0: restoring config space at offset 0xc (was 0x0, writing 0x10)
> [  222.122750] vpn_bridge: port 1(vif13.0) entered forwarding state
> [  225.943971] tty_init_dev: 14 callbacks suppressed
> [  226.654618] device vif16.0 entered promiscuous mode
> [  226.775073] device vif16.0-emu entered promiscuous mode
> [  226.784025] xen_bridge: port 17(vif16.0-emu) entered forwarding state
> [  226.790188] xen_bridge: port 17(vif16.0-emu) entered forwarding state
> [  228.253024] xen_bridge: port 13(vif14.0) entered forwarding state
> [  229.788197] xen_bridge: port 15(vif15.0-emu) entered disabled state
> [  229.796826] xen_bridge: port 15(vif15.0-emu) entered disabled state
> [  229.805243] device vif15.0-emu left promiscuous mode
> [  229.813385] xen_bridge: port 15(vif15.0-emu) entered disabled state
> [  231.558329] xen-blkback:ring-ref 8, event-channel 25, protocol 1 (x86_64-abi)
> [  231.569080] xen-blkback:ring-ref 9, event-channel 26, protocol 1 (x86_64-abi)
> [  231.609663] xen_bridge: port 14(vif15.0) entered forwarding state
> [  231.617943] xen_bridge: port 14(vif15.0) entered forwarding state
> [  231.934347] tty_init_dev: 25 callbacks suppressed
> 
> 
> 
> 
> 
> 
> > Ian.
> 
> > diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> > index 05593d8..ca4c47d 100644
> > --- a/drivers/net/xen-netback/netback.c
> > +++ b/drivers/net/xen-netback/netback.c
> > @@ -386,7 +386,7 @@ static struct netbk_rx_meta *get_next_rx_buffer(struct xenvif *vif,
> >   * Set up the grant operations for this fragment. If it's a flipping
> >   * interface, we also set up the unmap request from here.
> >   */
> > -static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
> > +static int netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
> >                                 struct netrx_pending_operations *npo,
> >                                 struct page *page, unsigned long size,
> >                                 unsigned long offset, int *head)
> > @@ -402,7 +402,8 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
> >         unsigned long bytes;
> >
> >         /* Data must not cross a page boundary. */
> > -       BUG_ON(size + offset > PAGE_SIZE);
> > +       if (size + offset > PAGE_SIZE)
> > +               return -1;
> >
> >         meta = npo->meta + npo->meta_prod - 1;
> >
> > @@ -459,6 +460,7 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
> >                 *head = 0; /* There must be something in this buffer now. */
> >
> >         }
> > +       return 0;
> >  }
> >
> >  /*
> > @@ -517,17 +519,31 @@ static int netbk_gop_skb(struct sk_buff *skb,
> >                 if (data + len > skb_tail_pointer(skb))
> >                         len = skb_tail_pointer(skb) - data;
> >
> > -               netbk_gop_frag_copy(vif, skb, npo,
> > -                                   virt_to_page(data), len, offset, &head);
> > +               if (netbk_gop_frag_copy(vif, skb, npo,
> > +                               virt_to_page(data), len, offset, &head) < 0) {
> > +printk(KERN_CRIT "netbk_gop_frag_copy failed: skb head %p-%p\n",
> +       skb->>data, skb_tail_pointer);
> > +printk(KERN_CRIT "copying from %p-%p, offset %x, len %x\n",
> > +       data, data+len, offset, len);
> > +dump_page(virt_to_page(data));
> > +BUG();
> > +               }
> >                 data += len;
> >         }
> >
> >         for (i = 0; i < nr_frags; i++) {
> > -               netbk_gop_frag_copy(vif, skb, npo,
> > +               if (netbk_gop_frag_copy(vif, skb, npo,
> >                                     skb_frag_page(&skb_shinfo(skb)->frags[i]),
> >                                     skb_frag_size(&skb_shinfo(skb)->frags[i]),
> >                                     skb_shinfo(skb)->frags[i].page_offset,
> > -                                   &head);
> > +                                   &head) < 0) {
> > +printk(KERN_CRIT "netbk_gop_frag_copy failed: skb frag %d page\n", i);
> > +printk(KERN_CRIT "copying from offset %x, len %x\n",
> > +       skb_shinfo(skb)->frags[i].page_offset,
> > +       skb_frag_size(&skb_shinfo(skb)->frags[i]));
> > +dump_page(skb_frag_page(&skb_shinfo(skb)->frags[i]));
> > +BUG();
> > +               }
> >         }
> >
> >         return npo->meta_prod - old_meta_prod;
> 
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 09:24:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 09:24:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLW30-0007Yb-0Q; Tue, 09 Oct 2012 09:24:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLW2x-0007YR-Qa
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 09:24:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1349774605!10646511!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMyNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7134 invoked from network); 9 Oct 2012 09:23:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 09:23:27 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15031283"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 09:23:10 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	10:23:09 +0100
Message-ID: <1349774588.21847.105.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Sander Eikelenboom 
Date: Tue, 9 Oct 2012 10:23:08 +0100
In-Reply-To: <120335733.20121009042424@eikelenboom.it>
References: 
	<729626082.20121006002054@eikelenboom.it>
	<20121007233444.GA26929@localhost.localdomain>
	<1349686461.18008.18.camel@zakaz.uk.xensource.com>
	<120335733.20121009042424@eikelenboom.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk ,
	"xen-devel@lists.xensource.com" ,
	konrad 
Subject: Re: [Xen-devel] Kernel 3.7.0-pre-rc1 kernel BUG at
 drivers/net/xen-netback/netback.c:405 RIP: e030:[]
 [] netbk_gop_frag_copy+0x379/0x380
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-09 at 03:24 +0100, Sander Eikelenboom wrote:

> >> Looking at the code, this is what we get:
> >>
> >>         /* Data must not cross a page boundary. */
> >>         BUG_ON(size + offset > PAGE_SIZE);
> >>[...]
> After applying the debug patch:
> 
> [  197.876304] netbk_gop_frag_copy failed: skb frag 0 page
> [  197.884299] copying from offset 0, len 1628

WTF! This turns into BUG_ON(0 + 1628 > PAGE_SIZE) (where PAGE_SIZE is
4096) which simply should not be triggering.

Perhaps I screwed up the debugging patch... investigates... no I don't
think so, but someone should definitely check my working.

For belt and braces can you change, in netbk_gop_frag_copy:
	/* Data must not cross a page boundary. */
	if (size + offset > PAGE_SIZE)
		return -1;
into:
	/* Data must not cross a page boundary. */
	if (size + offset > PAGE_SIZE) {
		printk(KERN_CRIT "netbk_gop_frag_copy: size %lx offset %lx\n => %lx > %lx\n",
		       size, offset, size + offset, PAGE_SIZE);
		return -1;
	}

This made me notice that offset and len in the caller are variously
unsigned int, u16 or u32 while gop_frag_copy takes them as unsigned
longs. None of the numbers involved here are anywhere big enough to
cause any sort of overflow related error though.

> [  197.892781] page:ffffea0000b18400 count:3 mapcount:0 mapping:          (null) index:0x0
> [  197.900778] page flags: 0x40000000004000(head)
> [  197.907074] ------------[ cut here ]------------
> [  197.913345] kernel BUG at drivers/net/xen-netback/netback.c:546!
> [  197.919626] invalid opcode: 0000 [#1] PREEMPT SMP
> [  197.921573] xen_bridge: port 10(vif10.0) entered forwarding state
> [  197.932106] Modules linked in:
> [  197.938370] CPU 0
> [  197.938420] Pid: 1180, comm: netback/0 Not tainted 3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)
> [  197.951203] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
> [  197.957775] RSP: e02b:ffff880037911c20  EFLAGS: 00010282
> [  197.964290] RAX: 0000000000000001 RBX: ffff880036862ee0 RCX: 0000000000000000
> [  197.970956] RDX: 0000000000000001 RSI: 0000000000000001 RDI: ffff8800379102b0
> [  197.977679] RBP: ffff880037911d50 R08: 0000000000000002 R09: 0000000000000000
> [  197.984361] R10: 0000000000000001 R11: ffff880039925e40 R12: 0000000000000030
> [  197.990958] R13: 0000000000000000 R14: ffff880031e71800 R15: 0000000000000001
> [  197.997459] FS:  00007fb5dfcf7700(0000) GS:ffff88003f800000(0000) knlGS:0000000000000000
> [  198.004123] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> [  198.010827] CR2: 00007fb5d802d000 CR3: 0000000031fd3000 CR4: 0000000000000660
> [  198.017534] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [  198.024168] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [  198.030717] Process netback/0 (pid: 1180, threadinfo ffff880037910000, task ffff88003997d190)
> [  198.037326] Stack:
> [  198.043817]  ffff880037911d1c ffff88003997d840 ffff880037911d00 ffff880037911c80
> [  198.050573]  ffffffff00000001 0000000000000662 ffffc90010824bb8 ffffc90010820050
> [  198.057413]  0000000001080083 ffffc90010820000 0000000000000000 ffff880031cf09c0
> [  198.064228] Call Trace:
> [  198.070887]  [] ? trace_hardirqs_on+0xd/0x10
> [  198.077604]  [] xen_netbk_kthread+0xba/0xa90
> [  198.084394]  [] ? try_to_wake_up+0x1b6/0x310
> [  198.091109]  [] ? wake_up_bit+0x40/0x40
> [  198.097726]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
> [  198.104343]  [] kthread+0xd6/0xe0
> [  198.111001]  [] kernel_thread_helper+0x4/0x10
> [  198.117737]  [] ? retint_restore_args+0x13/0x13
> [  198.124425]  [] ? gs_change+0x13/0x13
> [  198.131008] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 46 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7
> [  198.145094] RIP  [] xen_netbk_rx_action+0x89a/0x910
> [  198.152192]  RSP 
> [  198.159344] ---[ end trace cbdd0e4e80268fa8 ]---
> [  199.703539] tty_init_dev: 2 callbacks suppressed
> [  200.712098] device vif12.0 entered promiscuous mode
> [  201.010433] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
> [  201.020644] xen_bridge: port 12(vif12.0) entered forwarding state
> [  201.027833] xen_bridge: port 12(vif12.0) entered forwarding state
> [  206.774576] netbk_gop_frag_copy failed: skb frag 0 page
> [  206.777945] device vif13.0 entered promiscuous mode
> [  206.788845] copying from offset 1ba4, len 2c1
> [  206.795791] page:ffffea0000b18400 count:6 mapcount:0 mapping:          (null) index:0x0
> [  206.802771] page flags: 0x40000000004000(head)
> [  206.809619] ------------[ cut here ]------------
> [  206.816498] kernel BUG at drivers/net/xen-netback/netback.c:546!
> [  206.823465] invalid opcode: 0000 [#2] PREEMPT SMP
> [  206.830354] Modules linked in:
> [  206.837176] CPU 3
> [  206.837234] Pid: 1183, comm: netback/3 Tainted: G      D      3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)
> [  206.850881] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
> [  206.857935] RSP: e02b:ffff880037917c20  EFLAGS: 00010282
> [  206.864972] RAX: 0000000000000001 RBX: ffff880003313ae0 RCX: 0000000000000000
> [  206.872049] RDX: ffff88003997b0f0 RSI: 0000000000000001 RDI: ffff8800379102b0
> [  206.879147] RBP: ffff880037917d50 R08: 0000000000000002 R09: 0000000000000000
> [  206.886242] R10: 0000000000000001 R11: ffff880039925640 R12: 0000000000000030
> [  206.893163] R13: 0000000000000000 R14: ffff88002c7c4400 R15: 0000000000000001
> [  206.900041] FS:  00007f800341a700(0000) GS:ffff88003f8c0000(0000) knlGS:0000000000000000
> [  206.907145] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> [  206.914126] CR2: 00007f8002b31fb0 CR3: 0000000001c0b000 CR4: 0000000000000660
> [  206.921181] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [  206.927996] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [  206.934711] Process netback/3 (pid: 1183, threadinfo ffff880037916000, task ffff88003997b0f0)
> [  206.941494] Stack:
> [  206.948105]  ffff880037917d1c ffff880037916010 ffff880037917d00 ffff880037917c80
> [  206.955062]  ffffffff810800b5 00000000000000ba ffffc900108466e0 ffffc90010841b78
> [  206.962007]  0000000101080083 ffffc90010841b28 0000000100000000 ffff88002c5bb9c0
> [  206.968967] Call Trace:
> [  206.975830]  [] ? __alloc_workqueue_key+0x265/0x5d0
> [  206.982789]  [] ? trace_hardirqs_on+0xd/0x10
> [  206.989662]  [] xen_netbk_kthread+0xba/0xa90
> [  206.996570]  [] ? try_to_wake_up+0x1b6/0x310
> [  207.003523]  [] ? wake_up_bit+0x40/0x40
> [  207.010333]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
> [  207.017171]  [] kthread+0xd6/0xe0
> [  207.023890]  [] kernel_thread_helper+0x4/0x10
> [  207.030540]  [] ? retint_restore_args+0x13/0x13
> [  207.037275]  [] ? gs_change+0x13/0x13
> [  207.043890] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 46 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7
> [  207.057976] RIP  [] xen_netbk_rx_action+0x89a/0x910
> [  207.065064]  RSP 
> [  207.072056] ---[ end trace cbdd0e4e80268fa9 ]---
> [  207.079366] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
> [  207.090256] vpn_bridge: port 1(vif13.0) entered forwarding state
> [  207.097403] vpn_bridge: port 1(vif13.0) entered forwarding state
> [  208.636257] xen_bridge: port 11(vif11.0) entered forwarding state
> [  211.515779] netbk_gop_frag_copy failed: skb frag 0 page
> [  211.522711] copying from offset 2126, len 2c1
> [  211.529403] page:ffffea0000b18400 count:8 mapcount:0 mapping:          (null) index:0x0
> [  211.536142] page flags: 0x40000000004000(head)
> [  211.542942] ------------[ cut here ]------------
> [  211.549664] kernel BUG at drivers/net/xen-netback/netback.c:546!
> [  211.556408] invalid opcode: 0000 [#3] PREEMPT SMP
> [  211.563168] Modules linked in:
> [  211.569739] CPU 4
> [  211.569789] Pid: 1184, comm: netback/4 Tainted: G      D      3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)
> [  211.583126] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
> [  211.590041] RSP: e02b:ffff880037921c20  EFLAGS: 00010282
> [  211.596868] RAX: 0000000000000001 RBX: ffff8800375bc4e0 RCX: 0000000000000000
> [  211.603890] RDX: ffff88003997a0a0 RSI: 0000000000000001 RDI: ffff8800379202b0
> [  211.610792] RBP: ffff880037921d50 R08: 0000000000000002 R09: 0000000000000000
> [  211.617608] R10: 0000000000000001 R11: ffff8800399249e0 R12: 0000000000000030
> [  211.624537] R13: 0000000000000000 R14: ffff88002b98d400 R15: 0000000000000001
> [  211.631302] FS:  00007f332d735740(0000) GS:ffff88003f900000(0000) knlGS:0000000000000000
> [  211.638090] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> [  211.644965] CR2: 00007f1023d22000 CR3: 0000000031fba000 CR4: 0000000000000660
> [  211.651894] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [  211.658652] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [  211.665288] Process netback/4 (pid: 1184, threadinfo ffff880037920000, task ffff88003997a0a0)
> [  211.671884] Stack:
> [  211.678376]  ffff880037921d1c ffff880037920010 ffff880037921d00 ffff880037921c80
> [  211.685145]  ffffffff810800b5 00000000000000ba ffffc90010851a98 ffffc9001084cf30
> [  211.691837]  0000000101080083 ffffc9001084cee0 0000000100000000 ffff88002c5bd9c0
> [  211.698581] Call Trace:
> [  211.705349]  [] ? __alloc_workqueue_key+0x265/0x5d0
> [  211.712156]  [] ? trace_hardirqs_on+0xd/0x10
> [  211.718907]  [] xen_netbk_kthread+0xba/0xa90
> [  211.725654]  [] ? try_to_wake_up+0x1b6/0x310
> [  211.732369]  [] ? wake_up_bit+0x40/0x40
> [  211.739111]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
> [  211.745858]  [] kthread+0xd6/0xe0
> [  211.752449]  [] kernel_thread_helper+0x4/0x10
> [  211.758975]  [] ? retint_restore_args+0x13/0x13
> [  211.765575]  [] ? gs_change+0x13/0x13
> [  211.772016] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 46 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7
> [  211.785816] RIP  [] xen_netbk_rx_action+0x89a/0x910
> [  211.792586]  RSP 
> [  211.799394] ---[ end trace cbdd0e4e80268faa ]---
> [  212.852714] device vif14.0 entered promiscuous mode
> [  213.234995] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
> [  213.245054] xen_bridge: port 13(vif14.0) entered forwarding state
> [  213.252087] xen_bridge: port 13(vif14.0) entered forwarding state
> [  214.691532] netbk_gop_frag_copy failed: skb frag 0 page
> [  214.698515] copying from offset 26a8, len 2c1
> [  214.705472] page:ffffea0000b18400 count:10 mapcount:0 mapping:          (null) index:0x0
> [  214.712415] page flags: 0x40000000004000(head)
> [  214.719170] ------------[ cut here ]------------
> [  214.725887] kernel BUG at drivers/net/xen-netback/netback.c:546!
> [  214.732563] invalid opcode: 0000 [#4] PREEMPT SMP
> [  214.739221] Modules linked in:
> [  214.745808] CPU 5
> [  214.745859] Pid: 1185, comm: netback/5 Tainted: G      D      3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)
> [  214.759156] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
> [  214.766127] RSP: e02b:ffff880037923c20  EFLAGS: 00010282
> [  214.773012] RAX: 0000000000000001 RBX: ffff8800379172e0 RCX: 0000000000000000
> [  214.780010] RDX: ffff880039ac8000 RSI: 0000000000000001 RDI: ffff8800379202b0
> [  214.786988] RBP: ffff880037923d50 R08: 0000000000000002 R09: 0000000000000000
> [  214.793870] R10: 0000000000000001 R11: ffff880039924460 R12: 0000000000000030
> [  214.800812] R13: 0000000000000000 R14: ffff88002b8b4800 R15: 0000000000000001
> [  214.807668] FS:  00007f236d331700(0000) GS:ffff88003f940000(0000) knlGS:0000000000000000
> [  214.814545] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> [  214.821415] CR2: 00007f236c42b6b0 CR3: 0000000039275000 CR4: 0000000000000660
> [  214.828435] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [  214.835337] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [  214.841963] Process netback/5 (pid: 1185, threadinfo ffff880037922000, task ffff880039ac8000)
> [  214.848655] Stack:
> [  214.855220]  ffff880037923d1c ffff880037922010 ffff880037923d00 ffff880037923c80
> [  214.861945]  ffffffff810800b5 00000000000000ba ffffc9001085ce50 ffffc900108582e8
> [  214.868699]  0000000101080083 ffffc90010858298 0000000100000000 ffff880031e939c0
> [  214.875477] Call Trace:
> [  214.882247]  [] ? __alloc_workqueue_key+0x265/0x5d0
> [  214.889083]  [] ? trace_hardirqs_on+0xd/0x10
> [  214.895851]  [] xen_netbk_kthread+0xba/0xa90
> [  214.902612]  [] ? try_to_wake_up+0x1b6/0x310
> [  214.909343]  [] ? wake_up_bit+0x40/0x40
> [  214.916115]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
> [  214.922856]  [] kthread+0xd6/0xe0
> [  214.929527]  [] kernel_thread_helper+0x4/0x10
> [  214.936178]  [] ? retint_restore_args+0x13/0x13
> [  214.942781]  [] ? gs_change+0x13/0x13
> [  214.949279] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 46 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7
> [  214.963107] RIP  [] xen_netbk_rx_action+0x89a/0x910
> [  214.969952]  RSP 
> [  214.976802] ---[ end trace cbdd0e4e80268fab ]---
> [  216.045946] xen_bridge: port 12(vif12.0) entered forwarding state
> [  220.405869] device vif15.0 entered promiscuous mode
> [  220.607946] device vif15.0-emu entered promiscuous mode
> [  220.625075] xen_bridge: port 15(vif15.0-emu) entered forwarding state
> [  220.633333] xen_bridge: port 15(vif15.0-emu) entered forwarding state
> [  220.890237] pciback 0000:06:00.0: restoring config space at offset 0x3c (was 0x100, writing 0x10a)
> [  220.898814] pciback 0000:06:00.0: restoring config space at offset 0x10 (was 0x4, writing 0xf9a00004)
> [  220.907406] pciback 0000:06:00.0: restoring config space at offset 0xc (was 0x0, writing 0x10)
> [  222.122750] vpn_bridge: port 1(vif13.0) entered forwarding state
> [  225.943971] tty_init_dev: 14 callbacks suppressed
> [  226.654618] device vif16.0 entered promiscuous mode
> [  226.775073] device vif16.0-emu entered promiscuous mode
> [  226.784025] xen_bridge: port 17(vif16.0-emu) entered forwarding state
> [  226.790188] xen_bridge: port 17(vif16.0-emu) entered forwarding state
> [  228.253024] xen_bridge: port 13(vif14.0) entered forwarding state
> [  229.788197] xen_bridge: port 15(vif15.0-emu) entered disabled state
> [  229.796826] xen_bridge: port 15(vif15.0-emu) entered disabled state
> [  229.805243] device vif15.0-emu left promiscuous mode
> [  229.813385] xen_bridge: port 15(vif15.0-emu) entered disabled state
> [  231.558329] xen-blkback:ring-ref 8, event-channel 25, protocol 1 (x86_64-abi)
> [  231.569080] xen-blkback:ring-ref 9, event-channel 26, protocol 1 (x86_64-abi)
> [  231.609663] xen_bridge: port 14(vif15.0) entered forwarding state
> [  231.617943] xen_bridge: port 14(vif15.0) entered forwarding state
> [  231.934347] tty_init_dev: 25 callbacks suppressed
> 
> 
> 
> 
> 
> 
> > Ian.
> 
> > diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> > index 05593d8..ca4c47d 100644
> > --- a/drivers/net/xen-netback/netback.c
> > +++ b/drivers/net/xen-netback/netback.c
> > @@ -386,7 +386,7 @@ static struct netbk_rx_meta *get_next_rx_buffer(struct xenvif *vif,
> >   * Set up the grant operations for this fragment. If it's a flipping
> >   * interface, we also set up the unmap request from here.
> >   */
> > -static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
> > +static int netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
> >                                 struct netrx_pending_operations *npo,
> >                                 struct page *page, unsigned long size,
> >                                 unsigned long offset, int *head)
> > @@ -402,7 +402,8 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
> >         unsigned long bytes;
> >
> >         /* Data must not cross a page boundary. */
> > -       BUG_ON(size + offset > PAGE_SIZE);
> > +       if (size + offset > PAGE_SIZE)
> > +               return -1;
> >
> >         meta = npo->meta + npo->meta_prod - 1;
> >
> > @@ -459,6 +460,7 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
> >                 *head = 0; /* There must be something in this buffer now. */
> >
> >         }
> > +       return 0;
> >  }
> >
> >  /*
> > @@ -517,17 +519,31 @@ static int netbk_gop_skb(struct sk_buff *skb,
> >                 if (data + len > skb_tail_pointer(skb))
> >                         len = skb_tail_pointer(skb) - data;
> >
> > -               netbk_gop_frag_copy(vif, skb, npo,
> > -                                   virt_to_page(data), len, offset, &head);
> > +               if (netbk_gop_frag_copy(vif, skb, npo,
> > +                               virt_to_page(data), len, offset, &head) < 0) {
> > +printk(KERN_CRIT "netbk_gop_frag_copy failed: skb head %p-%p\n",
> +       skb->>data, skb_tail_pointer);
> > +printk(KERN_CRIT "copying from %p-%p, offset %x, len %x\n",
> > +       data, data+len, offset, len);
> > +dump_page(virt_to_page(data));
> > +BUG();
> > +               }
> >                 data += len;
> >         }
> >
> >         for (i = 0; i < nr_frags; i++) {
> > -               netbk_gop_frag_copy(vif, skb, npo,
> > +               if (netbk_gop_frag_copy(vif, skb, npo,
> >                                     skb_frag_page(&skb_shinfo(skb)->frags[i]),
> >                                     skb_frag_size(&skb_shinfo(skb)->frags[i]),
> >                                     skb_shinfo(skb)->frags[i].page_offset,
> > -                                   &head);
> > +                                   &head) < 0) {
> > +printk(KERN_CRIT "netbk_gop_frag_copy failed: skb frag %d page\n", i);
> > +printk(KERN_CRIT "copying from offset %x, len %x\n",
> > +       skb_shinfo(skb)->frags[i].page_offset,
> > +       skb_frag_size(&skb_shinfo(skb)->frags[i]));
> > +dump_page(skb_frag_page(&skb_shinfo(skb)->frags[i]));
> > +BUG();
> > +               }
> >         }
> >
> >         return npo->meta_prod - old_meta_prod;
> 
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 09:27:22 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 09:27:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLW5H-0007jc-Pj; Tue, 09 Oct 2012 09:26:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLW5F-0007jM-LB
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 09:26:37 +0000
Received: from [85.158.143.99:5082] by server-2.bemta-4.messagelabs.com id
	DE/94-06610-DCDE3705; Tue, 09 Oct 2012 09:26:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1349774796!33382009!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMyNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 878 invoked from network); 9 Oct 2012 09:26:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 09:26:36 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15031393"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 09:26:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 9 Oct 2012 10:26:35 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TLW5D-0008PS-Fy; Tue, 09 Oct 2012 09:26:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TLW5D-0003qi-BR;
	Tue, 09 Oct 2012 10:26:35 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20595.60875.258078.801716@mariner.uk.xensource.com>
Date: Tue, 9 Oct 2012 10:26:35 +0100
To: Ian Campbell 
In-Reply-To: <1349769024.6952.64.camel@dagon.hellion.org.uk>
References: 
	<1349769024.6952.64.camel@dagon.hellion.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [xen-unstable test] 13934: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 13934: regressions - FAIL"):
> But the job seemed to pass! ???

This is indeed quite odd.

The build rune is this:

  set -xe
          LC_ALL=C; export LC_ALL
          PATH=/usr/lib/ccache:$PATH:/usr/lib/git-core
          exec &1 &&             touch ../build-ok-stamp
          ) |tee ../build-log
          test -f ../build-ok-stamp

          echo ok.

As you can see the core of that is:

    make -j4 2>&1 && touch ../build-ok-stamp

And at the bottom of the transcript we see:

    + touch ../build-ok-stamp

There are no other unrelated occurrences of "build-ok-stamp" in the
log (the other runes have their own stamp files).  So either the shell
is buggy or make returned status 0.

This means the bug is in make or in the makefiles.  Let me investigate
further...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 09:27:22 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 09:27:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLW5H-0007jc-Pj; Tue, 09 Oct 2012 09:26:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLW5F-0007jM-LB
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 09:26:37 +0000
Received: from [85.158.143.99:5082] by server-2.bemta-4.messagelabs.com id
	DE/94-06610-DCDE3705; Tue, 09 Oct 2012 09:26:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1349774796!33382009!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTMyNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 878 invoked from network); 9 Oct 2012 09:26:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 09:26:36 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15031393"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 09:26:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 9 Oct 2012 10:26:35 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TLW5D-0008PS-Fy; Tue, 09 Oct 2012 09:26:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TLW5D-0003qi-BR;
	Tue, 09 Oct 2012 10:26:35 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20595.60875.258078.801716@mariner.uk.xensource.com>
Date: Tue, 9 Oct 2012 10:26:35 +0100
To: Ian Campbell 
In-Reply-To: <1349769024.6952.64.camel@dagon.hellion.org.uk>
References: 
	<1349769024.6952.64.camel@dagon.hellion.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [xen-unstable test] 13934: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 13934: regressions - FAIL"):
> But the job seemed to pass! ???

This is indeed quite odd.

The build rune is this:

  set -xe
          LC_ALL=C; export LC_ALL
          PATH=/usr/lib/ccache:$PATH:/usr/lib/git-core
          exec &1 &&             touch ../build-ok-stamp
          ) |tee ../build-log
          test -f ../build-ok-stamp

          echo ok.

As you can see the core of that is:

    make -j4 2>&1 && touch ../build-ok-stamp

And at the bottom of the transcript we see:

    + touch ../build-ok-stamp

There are no other unrelated occurrences of "build-ok-stamp" in the
log (the other runes have their own stamp files).  So either the shell
is buggy or make returned status 0.

This means the bug is in make or in the makefiles.  Let me investigate
further...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 09:33:03 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 09:33:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLWAo-00080V-M1; Tue, 09 Oct 2012 09:32:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLVZq-00074W-B6
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 08:54:11 +0000
Received: from [85.158.143.99:8758] by server-3.bemta-4.messagelabs.com id
	2A/8B-10986-136E3705; Tue, 09 Oct 2012 08:54:09 +0000
X-Env-Sender: zhenzhong.duan@oracle.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1349772845!23781541!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzkwNDA2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20941 invoked from network); 9 Oct 2012 08:54:06 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Oct 2012 08:54:06 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q998rwIQ016710
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 9 Oct 2012 08:53:59 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q998ruEK016558
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 9 Oct 2012 08:53:56 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q998rt2W004074; Tue, 9 Oct 2012 03:53:56 -0500
Received: from zhenzhong2.localdomain (/10.182.39.88)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 09 Oct 2012 01:53:52 -0700
Message-ID: <5073E61B.1010305@oracle.com>
Date: Tue, 09 Oct 2012 16:53:47 +0800
From: DuanZhenzhong 
Organization: Oracle Corporation
User-Agent: Thunderbird 2.0.0.24 (X11/20101209)
MIME-Version: 1.0
To: Ian Jackson 
References: <505C3647.1030003@oracle.com>	<20120921143430.GA3522@phenom.dumpdata.com>	<5062C16A.1020306@oracle.com>	<20120926123534.GF7356@phenom.dumpdata.com>	<5063EAFB.1070307@oracle.com>	<20120927115918.GE8832@phenom.dumpdata.com>	<50657D4B.9040303@oracle.com>	<20120928140109.GA7483@localhost.localdomain>	<20581.45245.846208.289785@mariner.uk.xensource.com>	<5065B82B.8080003@oracle.com>
	<20587.342.66210.677204@mariner.uk.xensource.com>
In-Reply-To: <20587.342.66210.677204@mariner.uk.xensource.com>
Content-Type: multipart/mixed; boundary="------------030802060607050703070201"
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-Mailman-Approved-At: Tue, 09 Oct 2012 09:32:21 +0000
Cc: Konrad Rzeszutek Wilk ,
	Dan Magenheimer ,
	Konrad Rzeszutek Wilk ,
	Feng Jin , xen-devel 
Subject: Re: [Xen-devel] Is: Contention in block script when doing guest
 saving. Was:Re: an issue with 'xm save'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--------------030802060607050703070201
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ian Jackson wrote:
> Zhenzhong Duan writes ("Re: [Xen-devel] Is: Contention in block script when doing guest saving. Was:Re: an issue with 'xm save'"):
>   
>> Attachment is part of xen-hotplug.log that will show the spin.
>> Original file is nearly 7G big. I fetch first 1000 lines.
>>     
>
> Thanks.  This is quite mystifying to me.
>
>
> Picking a representative example, and translating it to what I think
> the syscalls would be:
>
>   
>> + eval 'exec 200>>/var/run/xen-hotplug/block'
>> ++ exec
>>     
>
>   fd = open("/var/run/xen-hotplug/block", O_WRONLY|O_APPEND|O_CREAT, 0666);
>   dup2(fd, 200);
>   close(fd);
>
>   
>> + flock -x 200
>>     
>
>   flock(200, LOCK_EX);
>
>   
>> ++ perl -e '
>>             open STDIN, "<&200" or die $!;
>>     
>
>   dup2(200, 0);
>
>   
>>             my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
>>     
>
>   fstat(0, &stdin_stat);
>
>   
>>             my $file_inum = (stat $ARGV[0])[1];
>>     
>
>   stat("/var/run/xen-hotplug/block", &file_stat);
>
>   
>>             print "y\n" if $fd_inum eq $file_inum;
>>     
>
>   if (stdin_stat.st_ino == file_stat.st_ino)
>       puts("y");
>
>   
>>                              ' /var/run/xen-hotplug/block
>> + rightfile=
>>     
>
> And here we see that perl didn't print "y" so the two files must be
> different.
>
>
> Let's try something else: can you strace it ?  That is, get it to the
> point where it's spinning, find the pid of the relevant shell process,
> and
>    strace -f -vvs500 -ooutput.strace PID
> where PID is the pid in question ?
>
> Let that run for a fraction of a second and then ^C it.
>
> The output may shed some light.
>
> Thanks,
> Ian.
>   
Hi Ian,
Sorry for late, just back from vocation today.
Your requested strace info attached, any info you need, let me know.

-- 
Regards
zhenzhong
--
Oracle Building, No.24 Building, Zhongguancun Software Park
Haidian District, Beijing 100193, China


--------------030802060607050703070201
Content-Type: text/plain;
 name="output.strace"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline;
 filename="output.strace"

27813 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], 0, NULL) =3D=
 26268
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, 0x7fffb0100a24, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0xffffffffffffffff)  =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 pipe([3, 4])                      =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26269
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {0=
x436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26269 close(255 
27813 close(4 
26269 <... close resumed> )             =3D 0
27813 <... close resumed> )             =3D 0
27813 read(3,  
26269 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26269 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26269 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26269 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26269 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26269 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26269 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26269 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {S=
IG_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26269 rt_sigaction(SIGINT, {0x4481f0, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26269 dup2(4, 1)                        =3D 1
26269 close(4)                          =3D 0
26269 close(3)                          =3D 0
26269 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26269 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26269 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26269 write(2, "++ perl -e '\n            open STDIN, \"<&200\" or die $!=
;\n            my $fd_inum =3D (stat STDIN)[1]; die $! unless defined $fd=
_inum;\n            my $file_inum =3D (stat $ARGV[0])[1];\n            pr=
int \"y\\n\" if $fd_inum eq $file_inum;\n", 230) =3D 230
26269 write(2, "                             ' /var/run/xen-hotplug/block=
\n", 58) =3D 58
26269 stat(".", {st_dev=3Dmakedev(8, 2), st_ino=3D2, st_mode=3DS_IFDIR|07=
55, st_nlink=3D24, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
8, st_size=3D4096, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2012/10/08-=
11:13:38, st_ctime=3D2012/10/08-11:13:38}) =3D 0
26269 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26269 access("/usr/bin/perl", X_OK)     =3D 0
26269 access("/usr/bin/perl", R_OK)     =3D 0
26269 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26269 access("/usr/bin/perl", X_OK)     =3D 0
26269 access("/usr/bin/perl", R_OK)     =3D 0
26269 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
481f0, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26269 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26269 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26269 execve("/usr/bin/perl", ["perl", "-e", "\n            open STDIN, \=
"<&200\" or die $!;\n            my $fd_inum =3D (stat STDIN)[1]; die $! =
unless defined $fd_inum;\n            my $file_inum =3D (stat $ARGV[0])[1=
];\n            print \"y\\n\" if $fd_inum eq $file_inum;\n              =
               ", "/var/run/xen-hotplug/block"], ["SUBSYSTEM=3Dxen-backen=
d", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D/usr/b=
in:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:/usr/s=
bin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dxen-bac=
kend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3Dback=
end/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "SHLVL=
=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/perl"]) =3D 0
26269 brk(0)                            =3D 0x1a99000
26269 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fdb21f8b000
26269 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fdb21f8a000
26269 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26269 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64/libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26269 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64", 0x7fffced48b50) =3D -1 ENOENT (No such file or directory)
26269 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/lib=
perl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26269 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls", 0=
x7fffced48b50) =3D -1 ENOENT (No such file or directory)
26269 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64/=
libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26269 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64"=
, 0x7fffced48b50) =3D -1 ENOENT (No such file or directory)
26269 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl=
=2Eso", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26269 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE", 0x7ff=
fced48b50) =3D -1 ENOENT (No such file or directory)
26269 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26269 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26269 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7fdb21f70000=

26269 close(3)                          =3D 0
26269 open("/usr/lib64/libperl.so", O_RDONLY) =3D 3
26269 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\34\203%=
4\0\0\0@\0\0\0\0\0\0\0\360;\23\0\0\0\0\0\0\0\0\0@\0008\0\5\0@\0\35\0\34\0=
\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\200%4\0\0\0\0\0\200%4\0\0\0T\260\22\=
0\0\0\0\0T\260\22\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0X\260\22\0\0\0\=
0\0X\260\262%4\0\0\0X\260\262%4\0\0\0\250\201\0\0\0\0\0\0\350\242\0\0\0\0=
\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\265\22\0\0\0\0\0\370\265\262%4\0\=
0\0\370\265\262%4\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\=
0\0P\345td\4\0\0\0\250u\21\0\0\0\0\0\250u\221%4\0\0\0\250u\221%4\0\0\0D@\=
0\0\0\0\0\0D@\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\7\4\0\0\360\0\0\0\0\1\0\0\16\0\0\0\0\0\0@\0\200\203\200\225\1\22\=
264\3\31\200l\0\32\0 \5\201\0\240\3\2B\0\200\21R \0\22\0\0\16P\20#\10\216=
\334\30\211\"\0\10 \200\3B\220@\0\1\206\20\30\2\3\21\203$!\312A0\224Y\200=
\27\0\242\26\10\24R@\10\200\220\20A\10\0\220\1\200\206\2\10\304\30i\0\220=
\1\1\202\200\22\20\0\n\1H\0\n\2001J \6\31@L\207\20\10\0000\10(\200\2\0\4\=
251t\"\262\310!\212\240\320\"\0\t"..., 832) =3D 832
26269 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2839671, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D2480, st_size=3D1262384, st_atime=3D2012/10/09-12:04:35, st_mtime=3D=
2012/09/11-12:45:05, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26269 mmap(0x3425800000, 3363648, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425800000
26269 mprotect(0x342592c000, 2093056, PROT_NONE) =3D 0
26269 mmap(0x3425b2b000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x12b000) =3D 0x3425b2b000
26269 mmap(0x3425b34000, 4928, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3425b34000
26269 close(3)                          =3D 0
26269 open("/lib64/libresolv.so.2", O_RDONLY) =3D 3
26269 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\2402\0'4\0\=
0\0@\0\0\0\0\0\0\0@a\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\5\0=
\0\0@\0\0\0\0\0\0\0@\0\0'4\0\0\0@\0\0'4\0\0\0\370\1\0\0\0\0\0\0\370\1\0\0=
\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \361\0\0\0\0\0\0 \361\0'4\0\0\0=
 \361\0'4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\=
0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0'4\0\0\0\0\0\0'4\0\0\0$\10\1\0\0\0\0\0$\10=
\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\24\1\0\0\0\0\0\340\24!'4\=
0\0\0\340\24!'4\0\0\0\340\r\0\0\0\0\0\0\0106\0\0\0\0\0\0\0\0 \0\0\0\0\0\2=
\0\0\0\6\0\0\0\350\35\1\0\0\0\0\0\350\35!'4\0\0\0\350\35!'4\0\0\0\300\1\0=
\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\=
0\0\0008\2\0'4\0\0\0008\2\0'4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0=
\0\0\0\0P\345td\4\0\0\0<\361\0\0\0\0\0\0<\361\0'4\0\0\0<\361\0'4\0\0\0,\3=
\0\0\0\0\0\0,\3\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 8=
32
26269 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148119, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D192, st_size=3D92736, st_atime=3D2012/10/09-11:16:43, st_mtime=3D201=
0/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:42}) =3D 0
26269 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fdb21f6f000
26269 mmap(0x3427000000, 2181864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3427000000
26269 mprotect(0x3427011000, 2097152, PROT_NONE) =3D 0
26269 mmap(0x3427211000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x11000) =3D 0x3427211000
26269 mmap(0x3427213000, 6888, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3427213000
26269 close(3)                          =3D 0
26269 open("/lib64/libnsl.so.1", O_RDONLY) =3D 3
26269 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240@\340\35=
10\0\0\0@\0\0\0\0\0\0\0\360\265\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0=
\6\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\340\3510\0\0\0@\0\340\3510\0\0\0\370\1=
\0\0\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \33\1\0\0=
\0\0\0 \33\341\3510\0\0\0 \33\341\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\=
0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\340\3510\0\0\0=
\0\0\340\3510\0\0\0\310@\1\0\0\0\0\0\310@\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\=
0\0\6\0\0\0xM\1\0\0\0\0\0xM\1\3520\0\0\0xM\1\3520\0\0\0\310\5\0\0\0\0\0\0=
008-\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250M\1\0\0\0\0\0\250M\1\3=
520\0\0\0\250M\1\3520\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\340\3510\0\0\0008\2\340\351=
0\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0<\33\=
1\0\0\0\0\0<\33\341\3510\0\0\0<\33\341\3510\0\0\0\\\5\0\0\0\0\0\0\\\5\0\0=
\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26269 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147206, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D232, st_size=3D114352, st_atime=3D2012/10/09-12:01:01, st_mtime=3D20=
10/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:44}) =3D 0
26269 mmap(0x30e9e00000, 2194096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9e00000
26269 mprotect(0x30e9e15000, 2093056, PROT_NONE) =3D 0
26269 mmap(0x30ea014000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x14000) =3D 0x30ea014000
26269 mmap(0x30ea016000, 6832, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x30ea016000
26269 close(3)                          =3D 0
26269 open("/lib64/libdl.so.2", O_RDONLY) =3D 3
26269 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\16`\3500=
\0\0\0@\0\0\0\0\0\0\0@R\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0`\3500\0\0\0@\0`\3500\0\0\0\370\1\0\0\0\0\0\0\37=
0\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\300\32\0\0\0\0\0\0\300\3=
2`\3500\0\0\0\300\32`\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0`\3500\0\0\0\0\0`\3500\0\0\=
0\224\37\0\0\0\0\0\0\224\37\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0`-\=
0\0\0\0\0\0`-\200\3500\0\0\0`-\200\3500\0\0\0 \3\0\0\0\0\0\0\240\3\0\0\0\=
0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\240-\0\0\0\0\0\0\240-\200\3500\0\0\0=
\240-\200\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0=
\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2`\3500\0\0\0008\2`\3500\0\0\0 \0\0\=
0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\334\32\0\0\0\0\0\=
0\334\32`\3500\0\0\0\334\32`\3500\0\0\0\264\0\0\0\0\0\0\0\264\0\0\0\0\0\0=
\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26269 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147322, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D48, st_size=3D23360, st_atime=3D2012/10/09-11:13:54, st_mtime=3D2010=
/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26269 mmap(0x30e8600000, 2109696, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8600000
26269 mprotect(0x30e8602000, 2097152, PROT_NONE) =3D 0
26269 mmap(0x30e8802000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x2000) =3D 0x30e8802000
26269 close(3)                          =3D 0
26269 open("/lib64/libm.so.6", O_RDONLY) =3D 3
26269 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`>\240\3510\=
0\0\0@\0\0\0\0\0\0\0\240X\t\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0)\0(\0\6\0\0\=
0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3510\0\0\0@\0\240\3510\0\0\0\370\1\0\0\0\=
0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\360\303\7\0\0\0\=
0\0\360\303\247\3510\0\0\0\360\303\247\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0=
\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3510\=
0\0\0\0\0\240\3510\0\0\0000\22\10\0\0\0\0\0000\22\10\0\0\0\0\0\0\0 \0\0\0=
\0\0\1\0\0\0\6\0\0\0\270\35\10\0\0\0\0\0\270\35\310\3510\0\0\0\270\35\310=
\3510\0\0\0\320\2\0\0\0\0\0\0 \3\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0=
\0\350\35\10\0\0\0\0\0\350\35\310\3510\0\0\0\350\35\310\3510\0\0\0\300\1\=
0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0=
\0\0\0008\2\240\3510\0\0\0008\2\240\3510\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\f\304\7\0\0\0\0\0\f\304\247\3510\0\0\0=
\f\304\247\3510\0\0\0\374\r\0\0\0\0\0\0\374\r\0\0\0\0\0\0\4\0\0\0\0\0\0\0=
Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0"..., 832) =3D 832
26269 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147337, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D1216, st_size=3D615136, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2=
010/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26269 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fdb21f6e000
26269 mmap(0x30e9a00000, 2629848, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9a00000
26269 mprotect(0x30e9a82000, 2093056, PROT_NONE) =3D 0
26269 mmap(0x30e9c81000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x81000) =3D 0x30e9c81000
26269 close(3)                          =3D 0
26269 open("/lib64/libcrypt.so.1", O_RDONLY) =3D 3
26269 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\t\300%4=
\0\0\0@\0\0\0\0\0\0\0\30\265\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\=
0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\300%4\0\0\0@\0\300%4\0\0\0\370\1\0\0\0\0\=
0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340}\0\0\0\0\0\0\3=
40}\300%4\0\0\0\340}\300%4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\300%4\0\0\0\0\0\300%4\0\0\=
0\4\205\0\0\0\0\0\0\4\205\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\310\=
215\0\0\0\0\0\0\310\215\340%4\0\0\0\310\215\340%4\0\0\0\250\2\0\0\0\0\0\0=
\370\343\2\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\215\0\0\0\0\0\0\3=
70\215\340%4\0\0\0\370\215\340%4\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\=
0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\300%4\0\0\0008\2=
\300%4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0=
\374}\0\0\0\0\0\0\374}\300%4\0\0\0\374}\300%4\0\0\0\34\1\0\0\0\0\0\0\34\1=
\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26269 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148123, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D96, st_size=3D48600, st_atime=3D2012/10/09-12:01:01, st_mtime=3D2010=
/07/28-03:52:39, st_ctime=3D2012/09/11-14:53:52}) =3D 0
26269 mmap(0x3425c00000, 2322880, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425c00000
26269 mprotect(0x3425c09000, 2093056, PROT_NONE) =3D 0
26269 mmap(0x3425e08000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x8000) =3D 0x3425e08000
26269 mmap(0x3425e0a000, 184768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FI=
XED|MAP_ANONYMOUS, -1, 0) =3D 0x3425e0a000
26269 close(3)                          =3D 0
26269 open("/lib64/libutil.so.1", O_RDONLY) =3D 3
26269 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\16\0(4\=
0\0\0@\0\0\0\0\0\0\0(>\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0\0(4\0\0\0@\0\0(4\0\0\0\370\1\0\0\0\0\0\0\370\1\=
0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340\26\0\0\0\0\0\0\340\26\0(=
4\0\0\0\340\26\0(4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0=
\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0(4\0\0\0\0\0\0(4\0\0\0P\32\0\0\0\=
0\0\0P\32\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\35\0\0\0\0\0\0\3=
40\35 (4\0\0\0\340\35 (4\0\0\0 \3\0\0\0\0\0\0000\3\0\0\0\0\0\0\0\0 \0\0\0=
\0\0\2\0\0\0\6\0\0\0\20\36\0\0\0\0\0\0\20\36 (4\0\0\0\20\36 (4\0\0\0\300\=
1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0=
\0\0\0\0008\2\0(4\0\0\0008\2\0(4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\=
0\0\0\0\0\0P\345td\4\0\0\0\374\26\0\0\0\0\0\0\374\26\0(4\0\0\0\374\26\0(4=
\0\0\0D\0\0\0\0\0\0\0D\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8=
32) =3D 832
26269 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147063, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D40, st_size=3D18152, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2010=
/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:49}) =3D 0
26269 mmap(0x3428000000, 2105616, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3428000000
26269 mprotect(0x3428002000, 2093056, PROT_NONE) =3D 0
26269 mmap(0x3428201000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x1000) =3D 0x3428201000
26269 close(3)                          =3D 0
26269 open("/lib64/libpthread.so.0", O_RDONLY) =3D 3
26269 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240W\240\35=
00\0\0\0@\0\0\0\0\0\0\0\340/\2\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0'\0&\0\6\0=
\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3500\0\0\0@\0\240\3500\0\0\0\370\1\0\0=
\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\240\t\1\0\0\0=
\0\0\240\t\241\3500\0\0\0\240\t\241\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\=
0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3500\0\0=
\0\0\0\240\3500\0\0\0pZ\1\0\0\0\0\0pZ\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\=
6\0\0\0\270[\1\0\0\0\0\0\270[\301\3500\0\0\0\270[\301\3500\0\0\0\230\6\0\=
0\0\0\0\0\270G\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250]\1\0\0\0\0\=
0\250]\301\3500\0\0\0\250]\301\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0=
\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\240\3500\0\0\=
0008\2\240\3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345t=
d\4\0\0\0\274\t\1\0\0\0\0\0\274\t\241\3500\0\0\0\274\t\241\3500\0\0\0\344=
\t\0\0\0\0\0\0\344\t\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =
=3D 832
26269 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147328, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D296, st_size=3D145824, st_atime=3D2012/10/09-11:16:43, st_mtime=3D20=
10/07/28-03:52:41, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26269 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fdb21f6d000
26269 mmap(0x30e8a00000, 2204528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8a00000
26269 mprotect(0x30e8a16000, 2093056, PROT_NONE) =3D 0
26269 mmap(0x30e8c15000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x15000) =3D 0x30e8c15000
26269 mmap(0x30e8c17000, 13168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8c17000
26269 close(3)                          =3D 0
26269 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26269 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26269 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26269 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26269 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26269 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26269 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26269 close(3)                          =3D 0
26269 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fdb21f6c000
26269 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fdb21f6b000
26269 arch_prctl(ARCH_SET_FS, 0x7fdb21f6b6e0) =3D 0
26269 mprotect(0x3427211000, 4096, PROT_READ) =3D 0
26269 mprotect(0x30ea014000, 4096, PROT_READ) =3D 0
26269 mprotect(0x30e8802000, 4096, PROT_READ) =3D 0
26269 mprotect(0x30e9c81000, 4096, PROT_READ) =3D 0
26269 mprotect(0x3425e08000, 4096, PROT_READ) =3D 0
26269 mprotect(0x3428201000, 4096, PROT_READ) =3D 0
26269 mprotect(0x30e8c15000, 4096, PROT_READ) =3D 0
26269 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26269 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26269 munmap(0x7fdb21f70000, 103979)    =3D 0
26269 set_tid_address(0x7fdb21f6b770)   =3D 26269
26269 set_robust_list(0x7fdb21f6b780, 0x18) =3D 0
26269 futex(0x7fffced4967c, FUTEX_WAKE_PRIVATE, 1) =3D 0
26269 rt_sigaction(SIGRTMIN, {0x30e8a05380, [], SA_RESTORER|SA_SIGINFO, 0=
x30e8a0eb10}, NULL, 8) =3D 0
26269 rt_sigaction(SIGRT_1, {0x30e8a052b0, [], SA_RESTORER|SA_RESTART|SA_=
SIGINFO, 0x30e8a0eb10}, NULL, 8) =3D 0
26269 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) =3D 0
26269 getrlimit(RLIMIT_STACK, {rlim_cur=3D8192*1024, rlim_max=3DRLIM_INFI=
NITY}) =3D 0
26269 rt_sigaction(SIGFPE, {0x1, [FPE], SA_RESTORER|SA_RESTART, 0x30e8230=
2d0}, {SIG_DFL, [], 0}, 8) =3D 0
26269 brk(0)                            =3D 0x1a99000
26269 brk(0x1abb000)                    =3D 0x1abb000
26269 getuid()                          =3D 0
26269 geteuid()                         =3D 0
26269 getgid()                          =3D 0
26269 getegid()                         =3D 0
26269 mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,=
 -1, 0) =3D 0x7fdb21f4a000
26269 open("/dev/urandom", O_RDONLY)    =3D 3
26269 read(3, "\323\277\205\337", 4)    =3D 4
26269 close(3)                          =3D 0
26269 stat("/usr/lib64/perl5/site_perl/5.8.7/x86_64-linux-thread-multi", =
0x7fffced49330) =3D -1 ENOENT (No such file or directory)
26269 stat("/usr/lib/perl5/site_perl/5.8.7", 0x7fffced49330) =3D -1 ENOEN=
T (No such file or directory)
26269 stat("/usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi", =
0x7fffced49330) =3D -1 ENOENT (No such file or directory)
26269 stat("/usr/lib/perl5/site_perl/5.8.6", 0x7fffced49330) =3D -1 ENOEN=
T (No such file or directory)
26269 stat("/usr/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi", =
0x7fffced49330) =3D -1 ENOENT (No such file or directory)
26269 stat("/usr/lib/perl5/site_perl/5.8.5", 0x7fffced49330) =3D -1 ENOEN=
T (No such file or directory)
26269 stat("/usr/lib64/perl5/vendor_perl/5.8.7/x86_64-linux-thread-multi"=
, 0x7fffced49330) =3D -1 ENOENT (No such file or directory)
26269 stat("/usr/lib/perl5/vendor_perl/5.8.7", 0x7fffced49330) =3D -1 ENO=
ENT (No such file or directory)
26269 stat("/usr/lib64/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi"=
, 0x7fffced49330) =3D -1 ENOENT (No such file or directory)
26269 stat("/usr/lib/perl5/vendor_perl/5.8.6", 0x7fffced49330) =3D -1 ENO=
ENT (No such file or directory)
26269 stat("/usr/lib64/perl5/vendor_perl/5.8.5/x86_64-linux-thread-multi"=
, 0x7fffced49330) =3D -1 ENOENT (No such file or directory)
26269 stat("/usr/lib/perl5/vendor_perl/5.8.5", 0x7fffced49330) =3D -1 ENO=
ENT (No such file or directory)
26269 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffced490f0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26269 lseek(0, 0, SEEK_CUR)             =3D 0
26269 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffced490f0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26269 lseek(1, 0, SEEK_CUR)             =3D -1 ESPIPE (Illegal seek)
26269 ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffced49100) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26269 lseek(2, 0, SEEK_CUR)             =3D 593655951
26269 open("/dev/null", O_RDONLY)       =3D 3
26269 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffced49200) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26269 lseek(3, 0, SEEK_CUR)             =3D 0
26269 fcntl(3, F_SETFD, FD_CLOEXEC)     =3D 0
26269 fstat(3, {st_dev=3Dmakedev(0, 16), st_ino=3D584, st_mode=3DS_IFCHR|=
0666, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
0, st_rdev=3Dmakedev(1, 3), st_atime=3D2012/10/08-11:13:26, st_mtime=3D20=
12/10/08-11:13:26, st_ctime=3D2012/10/08-11:13:27}) =3D 0
26269 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) =3D 0
26269 readlink("/proc/self/exe", "/usr/bin/perl"..., 4095) =3D 13
26269 brk(0x1adc000)                    =3D 0x1adc000
26269 close(3)                          =3D 0
26269 dup(200)                          =3D 3
26269 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffced490d0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26269 lseek(3, 0, SEEK_CUR)             =3D 0
26269 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26269 dup2(3, 0)                        =3D 0
26269 close(3)                          =3D 0
26269 fcntl(0, F_SETFD, 0)              =3D 0
26269 fstat(0, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26269 stat("/var/run/xen-hotplug/block", {st_dev=3Dmakedev(8, 2), st_ino=3D=
2801738, st_mode=3DS_IFREG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st=
_blksize=3D4096, st_blocks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:=
24, st_mtime=3D2012/10/09-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D =
0
26269 exit_group(0)                     =3D ?
27813 <... read resumed> "", 128)       =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], WNOHANG, NUL=
L) =3D 26269
27813 wait4(-1, 0x7fffb0100a64, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0)                   =3D 0
27813 close(3)                          =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 write(2, "+ rightfile=3D\n", 13)    =3D 13
27813 write(2, "+ '[' x =3D xy ']'\n", 17) =3D 17
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ true\n", 7)           =3D 7
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ eval 'exec 200>>/var/run/xen-hotplug/block'\n", 46) =3D=
 46
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 write(2, "++ exec\n", 8)          =3D 8
27813 open("/var/run/xen-hotplug/block", O_WRONLY|O_CREAT|O_APPEND, 0666)=
 =3D 3
27813 fcntl(200, F_GETFD)               =3D 0
27813 fcntl(200, F_DUPFD, 10)           =3D 10
27813 fcntl(200, F_GETFD)               =3D 0
27813 dup2(3, 200)                      =3D 200
27813 close(3)                          =3D 0
27813 dup2(10, 200)                     =3D 200
27813 fcntl(10, F_GETFD)                =3D 0
27813 close(10)                         =3D 0
27813 write(2, "+ flock -x 200\n", 15)  =3D 15
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [INT CHLD], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [INT CHLD], NULL, 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26270
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26270 close(255 
27813 rt_sigprocmask(SIG_BLOCK, [CHLD],  
26270 <... close resumed> )             =3D 0
27813 <... rt_sigprocmask resumed> [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [],  
26270 rt_sigprocmask(SIG_SETMASK, [],  
27813 <... rt_sigprocmask resumed> NULL, 8) =3D 0
26270 <... rt_sigprocmask resumed> NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
26270 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0},  
26270 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
27813 <... rt_sigaction resumed> {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}=
, 8) =3D 0
26270 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 wait4(-1,  
26270 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
26270 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26270 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26270 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26270 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26270 execve("/usr/bin/flock", ["flock", "-x", "200"], ["SUBSYSTEM=3Dxen-=
backend", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D=
/usr/bin:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:=
/usr/sbin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dx=
en-backend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3D=
backend/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "S=
HLVL=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/flock"]) =3D 0=

26270 brk(0)                            =3D 0x1531000
26270 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f585c9c2000
26270 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f585c9c1000
26270 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26270 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26270 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26270 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7f585c9a7000=

26270 close(3)                          =3D 0
26270 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26270 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26270 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26270 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26270 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26270 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26270 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26270 close(3)                          =3D 0
26270 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f585c9a6000
26270 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f585c9a5000
26270 arch_prctl(ARCH_SET_FS, 0x7f585c9a56e0) =3D 0
26270 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26270 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26270 munmap(0x7f585c9a7000, 103979)    =3D 0
26270 flock(200, LOCK_EX)               =3D 0
26270 exit_group(0)                     =3D ?
27813 <... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], 0,=
 NULL) =3D 26270
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, 0x7fffb0100a24, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0xffffffffffffffff)  =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 pipe([3, 4])                      =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26271
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {0=
x436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26271 close(255 
27813 close(4 
26271 <... close resumed> )             =3D 0
27813 <... close resumed> )             =3D 0
27813 read(3,  
26271 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26271 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26271 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26271 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26271 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26271 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26271 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26271 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {S=
IG_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26271 rt_sigaction(SIGINT, {0x4481f0, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26271 dup2(4, 1)                        =3D 1
26271 close(4)                          =3D 0
26271 close(3)                          =3D 0
26271 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26271 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26271 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26271 write(2, "++ perl -e '\n            open STDIN, \"<&200\" or die $!=
;\n            my $fd_inum =3D (stat STDIN)[1]; die $! unless defined $fd=
_inum;\n            my $file_inum =3D (stat $ARGV[0])[1];\n            pr=
int \"y\\n\" if $fd_inum eq $file_inum;\n", 230) =3D 230
26271 write(2, "                             ' /var/run/xen-hotplug/block=
\n", 58) =3D 58
26271 stat(".", {st_dev=3Dmakedev(8, 2), st_ino=3D2, st_mode=3DS_IFDIR|07=
55, st_nlink=3D24, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
8, st_size=3D4096, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2012/10/08-=
11:13:38, st_ctime=3D2012/10/08-11:13:38}) =3D 0
26271 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26271 access("/usr/bin/perl", X_OK)     =3D 0
26271 access("/usr/bin/perl", R_OK)     =3D 0
26271 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26271 access("/usr/bin/perl", X_OK)     =3D 0
26271 access("/usr/bin/perl", R_OK)     =3D 0
26271 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
481f0, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26271 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26271 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26271 execve("/usr/bin/perl", ["perl", "-e", "\n            open STDIN, \=
"<&200\" or die $!;\n            my $fd_inum =3D (stat STDIN)[1]; die $! =
unless defined $fd_inum;\n            my $file_inum =3D (stat $ARGV[0])[1=
];\n            print \"y\\n\" if $fd_inum eq $file_inum;\n              =
               ", "/var/run/xen-hotplug/block"], ["SUBSYSTEM=3Dxen-backen=
d", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D/usr/b=
in:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:/usr/s=
bin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dxen-bac=
kend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3Dback=
end/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "SHLVL=
=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/perl"]) =3D 0
26271 brk(0)                            =3D 0x217e000
26271 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f9f8a879000
26271 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f9f8a878000
26271 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26271 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64/libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26271 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64", 0x7fff8dbaff30) =3D -1 ENOENT (No such file or directory)
26271 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/lib=
perl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26271 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls", 0=
x7fff8dbaff30) =3D -1 ENOENT (No such file or directory)
26271 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64/=
libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26271 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64"=
, 0x7fff8dbaff30) =3D -1 ENOENT (No such file or directory)
26271 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl=
=2Eso", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26271 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE", 0x7ff=
f8dbaff30) =3D -1 ENOENT (No such file or directory)
26271 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26271 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26271 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7f9f8a85e000=

26271 close(3)                          =3D 0
26271 open("/usr/lib64/libperl.so", O_RDONLY) =3D 3
26271 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\34\203%=
4\0\0\0@\0\0\0\0\0\0\0\360;\23\0\0\0\0\0\0\0\0\0@\0008\0\5\0@\0\35\0\34\0=
\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\200%4\0\0\0\0\0\200%4\0\0\0T\260\22\=
0\0\0\0\0T\260\22\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0X\260\22\0\0\0\=
0\0X\260\262%4\0\0\0X\260\262%4\0\0\0\250\201\0\0\0\0\0\0\350\242\0\0\0\0=
\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\265\22\0\0\0\0\0\370\265\262%4\0\=
0\0\370\265\262%4\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\=
0\0P\345td\4\0\0\0\250u\21\0\0\0\0\0\250u\221%4\0\0\0\250u\221%4\0\0\0D@\=
0\0\0\0\0\0D@\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\7\4\0\0\360\0\0\0\0\1\0\0\16\0\0\0\0\0\0@\0\200\203\200\225\1\22\=
264\3\31\200l\0\32\0 \5\201\0\240\3\2B\0\200\21R \0\22\0\0\16P\20#\10\216=
\334\30\211\"\0\10 \200\3B\220@\0\1\206\20\30\2\3\21\203$!\312A0\224Y\200=
\27\0\242\26\10\24R@\10\200\220\20A\10\0\220\1\200\206\2\10\304\30i\0\220=
\1\1\202\200\22\20\0\n\1H\0\n\2001J \6\31@L\207\20\10\0000\10(\200\2\0\4\=
251t\"\262\310!\212\240\320\"\0\t"..., 832) =3D 832
26271 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2839671, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D2480, st_size=3D1262384, st_atime=3D2012/10/09-12:04:35, st_mtime=3D=
2012/09/11-12:45:05, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26271 mmap(0x3425800000, 3363648, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425800000
26271 mprotect(0x342592c000, 2093056, PROT_NONE) =3D 0
26271 mmap(0x3425b2b000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x12b000) =3D 0x3425b2b000
26271 mmap(0x3425b34000, 4928, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3425b34000
26271 close(3)                          =3D 0
26271 open("/lib64/libresolv.so.2", O_RDONLY) =3D 3
26271 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\2402\0'4\0\=
0\0@\0\0\0\0\0\0\0@a\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\5\0=
\0\0@\0\0\0\0\0\0\0@\0\0'4\0\0\0@\0\0'4\0\0\0\370\1\0\0\0\0\0\0\370\1\0\0=
\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \361\0\0\0\0\0\0 \361\0'4\0\0\0=
 \361\0'4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\=
0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0'4\0\0\0\0\0\0'4\0\0\0$\10\1\0\0\0\0\0$\10=
\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\24\1\0\0\0\0\0\340\24!'4\=
0\0\0\340\24!'4\0\0\0\340\r\0\0\0\0\0\0\0106\0\0\0\0\0\0\0\0 \0\0\0\0\0\2=
\0\0\0\6\0\0\0\350\35\1\0\0\0\0\0\350\35!'4\0\0\0\350\35!'4\0\0\0\300\1\0=
\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\=
0\0\0008\2\0'4\0\0\0008\2\0'4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0=
\0\0\0\0P\345td\4\0\0\0<\361\0\0\0\0\0\0<\361\0'4\0\0\0<\361\0'4\0\0\0,\3=
\0\0\0\0\0\0,\3\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 8=
32
26271 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148119, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D192, st_size=3D92736, st_atime=3D2012/10/09-11:16:43, st_mtime=3D201=
0/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:42}) =3D 0
26271 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f9f8a85d000
26271 mmap(0x3427000000, 2181864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3427000000
26271 mprotect(0x3427011000, 2097152, PROT_NONE) =3D 0
26271 mmap(0x3427211000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x11000) =3D 0x3427211000
26271 mmap(0x3427213000, 6888, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3427213000
26271 close(3)                          =3D 0
26271 open("/lib64/libnsl.so.1", O_RDONLY) =3D 3
26271 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240@\340\35=
10\0\0\0@\0\0\0\0\0\0\0\360\265\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0=
\6\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\340\3510\0\0\0@\0\340\3510\0\0\0\370\1=
\0\0\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \33\1\0\0=
\0\0\0 \33\341\3510\0\0\0 \33\341\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\=
0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\340\3510\0\0\0=
\0\0\340\3510\0\0\0\310@\1\0\0\0\0\0\310@\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\=
0\0\6\0\0\0xM\1\0\0\0\0\0xM\1\3520\0\0\0xM\1\3520\0\0\0\310\5\0\0\0\0\0\0=
008-\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250M\1\0\0\0\0\0\250M\1\3=
520\0\0\0\250M\1\3520\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\340\3510\0\0\0008\2\340\351=
0\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0<\33\=
1\0\0\0\0\0<\33\341\3510\0\0\0<\33\341\3510\0\0\0\\\5\0\0\0\0\0\0\\\5\0\0=
\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26271 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147206, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D232, st_size=3D114352, st_atime=3D2012/10/09-12:01:01, st_mtime=3D20=
10/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:44}) =3D 0
26271 mmap(0x30e9e00000, 2194096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9e00000
26271 mprotect(0x30e9e15000, 2093056, PROT_NONE) =3D 0
26271 mmap(0x30ea014000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x14000) =3D 0x30ea014000
26271 mmap(0x30ea016000, 6832, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x30ea016000
26271 close(3)                          =3D 0
26271 open("/lib64/libdl.so.2", O_RDONLY) =3D 3
26271 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\16`\3500=
\0\0\0@\0\0\0\0\0\0\0@R\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0`\3500\0\0\0@\0`\3500\0\0\0\370\1\0\0\0\0\0\0\37=
0\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\300\32\0\0\0\0\0\0\300\3=
2`\3500\0\0\0\300\32`\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0`\3500\0\0\0\0\0`\3500\0\0\=
0\224\37\0\0\0\0\0\0\224\37\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0`-\=
0\0\0\0\0\0`-\200\3500\0\0\0`-\200\3500\0\0\0 \3\0\0\0\0\0\0\240\3\0\0\0\=
0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\240-\0\0\0\0\0\0\240-\200\3500\0\0\0=
\240-\200\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0=
\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2`\3500\0\0\0008\2`\3500\0\0\0 \0\0\=
0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\334\32\0\0\0\0\0\=
0\334\32`\3500\0\0\0\334\32`\3500\0\0\0\264\0\0\0\0\0\0\0\264\0\0\0\0\0\0=
\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26271 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147322, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D48, st_size=3D23360, st_atime=3D2012/10/09-11:13:54, st_mtime=3D2010=
/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26271 mmap(0x30e8600000, 2109696, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8600000
26271 mprotect(0x30e8602000, 2097152, PROT_NONE) =3D 0
26271 mmap(0x30e8802000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x2000) =3D 0x30e8802000
26271 close(3)                          =3D 0
26271 open("/lib64/libm.so.6", O_RDONLY) =3D 3
26271 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`>\240\3510\=
0\0\0@\0\0\0\0\0\0\0\240X\t\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0)\0(\0\6\0\0\=
0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3510\0\0\0@\0\240\3510\0\0\0\370\1\0\0\0\=
0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\360\303\7\0\0\0\=
0\0\360\303\247\3510\0\0\0\360\303\247\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0=
\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3510\=
0\0\0\0\0\240\3510\0\0\0000\22\10\0\0\0\0\0000\22\10\0\0\0\0\0\0\0 \0\0\0=
\0\0\1\0\0\0\6\0\0\0\270\35\10\0\0\0\0\0\270\35\310\3510\0\0\0\270\35\310=
\3510\0\0\0\320\2\0\0\0\0\0\0 \3\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0=
\0\350\35\10\0\0\0\0\0\350\35\310\3510\0\0\0\350\35\310\3510\0\0\0\300\1\=
0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0=
\0\0\0008\2\240\3510\0\0\0008\2\240\3510\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\f\304\7\0\0\0\0\0\f\304\247\3510\0\0\0=
\f\304\247\3510\0\0\0\374\r\0\0\0\0\0\0\374\r\0\0\0\0\0\0\4\0\0\0\0\0\0\0=
Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0"..., 832) =3D 832
26271 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147337, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D1216, st_size=3D615136, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2=
010/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26271 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f9f8a85c000
26271 mmap(0x30e9a00000, 2629848, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9a00000
26271 mprotect(0x30e9a82000, 2093056, PROT_NONE) =3D 0
26271 mmap(0x30e9c81000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x81000) =3D 0x30e9c81000
26271 close(3)                          =3D 0
26271 open("/lib64/libcrypt.so.1", O_RDONLY) =3D 3
26271 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\t\300%4=
\0\0\0@\0\0\0\0\0\0\0\30\265\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\=
0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\300%4\0\0\0@\0\300%4\0\0\0\370\1\0\0\0\0\=
0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340}\0\0\0\0\0\0\3=
40}\300%4\0\0\0\340}\300%4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\300%4\0\0\0\0\0\300%4\0\0\=
0\4\205\0\0\0\0\0\0\4\205\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\310\=
215\0\0\0\0\0\0\310\215\340%4\0\0\0\310\215\340%4\0\0\0\250\2\0\0\0\0\0\0=
\370\343\2\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\215\0\0\0\0\0\0\3=
70\215\340%4\0\0\0\370\215\340%4\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\=
0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\300%4\0\0\0008\2=
\300%4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0=
\374}\0\0\0\0\0\0\374}\300%4\0\0\0\374}\300%4\0\0\0\34\1\0\0\0\0\0\0\34\1=
\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26271 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148123, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D96, st_size=3D48600, st_atime=3D2012/10/09-12:01:01, st_mtime=3D2010=
/07/28-03:52:39, st_ctime=3D2012/09/11-14:53:52}) =3D 0
26271 mmap(0x3425c00000, 2322880, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425c00000
26271 mprotect(0x3425c09000, 2093056, PROT_NONE) =3D 0
26271 mmap(0x3425e08000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x8000) =3D 0x3425e08000
26271 mmap(0x3425e0a000, 184768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FI=
XED|MAP_ANONYMOUS, -1, 0) =3D 0x3425e0a000
26271 close(3)                          =3D 0
26271 open("/lib64/libutil.so.1", O_RDONLY) =3D 3
26271 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\16\0(4\=
0\0\0@\0\0\0\0\0\0\0(>\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0\0(4\0\0\0@\0\0(4\0\0\0\370\1\0\0\0\0\0\0\370\1\=
0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340\26\0\0\0\0\0\0\340\26\0(=
4\0\0\0\340\26\0(4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0=
\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0(4\0\0\0\0\0\0(4\0\0\0P\32\0\0\0\=
0\0\0P\32\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\35\0\0\0\0\0\0\3=
40\35 (4\0\0\0\340\35 (4\0\0\0 \3\0\0\0\0\0\0000\3\0\0\0\0\0\0\0\0 \0\0\0=
\0\0\2\0\0\0\6\0\0\0\20\36\0\0\0\0\0\0\20\36 (4\0\0\0\20\36 (4\0\0\0\300\=
1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0=
\0\0\0\0008\2\0(4\0\0\0008\2\0(4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\=
0\0\0\0\0\0P\345td\4\0\0\0\374\26\0\0\0\0\0\0\374\26\0(4\0\0\0\374\26\0(4=
\0\0\0D\0\0\0\0\0\0\0D\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8=
32) =3D 832
26271 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147063, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D40, st_size=3D18152, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2010=
/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:49}) =3D 0
26271 mmap(0x3428000000, 2105616, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3428000000
26271 mprotect(0x3428002000, 2093056, PROT_NONE) =3D 0
26271 mmap(0x3428201000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x1000) =3D 0x3428201000
26271 close(3)                          =3D 0
26271 open("/lib64/libpthread.so.0", O_RDONLY) =3D 3
26271 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240W\240\35=
00\0\0\0@\0\0\0\0\0\0\0\340/\2\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0'\0&\0\6\0=
\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3500\0\0\0@\0\240\3500\0\0\0\370\1\0\0=
\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\240\t\1\0\0\0=
\0\0\240\t\241\3500\0\0\0\240\t\241\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\=
0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3500\0\0=
\0\0\0\240\3500\0\0\0pZ\1\0\0\0\0\0pZ\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\=
6\0\0\0\270[\1\0\0\0\0\0\270[\301\3500\0\0\0\270[\301\3500\0\0\0\230\6\0\=
0\0\0\0\0\270G\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250]\1\0\0\0\0\=
0\250]\301\3500\0\0\0\250]\301\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0=
\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\240\3500\0\0\=
0008\2\240\3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345t=
d\4\0\0\0\274\t\1\0\0\0\0\0\274\t\241\3500\0\0\0\274\t\241\3500\0\0\0\344=
\t\0\0\0\0\0\0\344\t\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =
=3D 832
26271 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147328, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D296, st_size=3D145824, st_atime=3D2012/10/09-11:16:43, st_mtime=3D20=
10/07/28-03:52:41, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26271 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f9f8a85b000
26271 mmap(0x30e8a00000, 2204528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8a00000
26271 mprotect(0x30e8a16000, 2093056, PROT_NONE) =3D 0
26271 mmap(0x30e8c15000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x15000) =3D 0x30e8c15000
26271 mmap(0x30e8c17000, 13168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8c17000
26271 close(3)                          =3D 0
26271 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26271 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26271 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26271 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26271 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26271 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26271 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26271 close(3)                          =3D 0
26271 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f9f8a85a000
26271 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f9f8a859000
26271 arch_prctl(ARCH_SET_FS, 0x7f9f8a8596e0) =3D 0
26271 mprotect(0x3427211000, 4096, PROT_READ) =3D 0
26271 mprotect(0x30ea014000, 4096, PROT_READ) =3D 0
26271 mprotect(0x30e8802000, 4096, PROT_READ) =3D 0
26271 mprotect(0x30e9c81000, 4096, PROT_READ) =3D 0
26271 mprotect(0x3425e08000, 4096, PROT_READ) =3D 0
26271 mprotect(0x3428201000, 4096, PROT_READ) =3D 0
26271 mprotect(0x30e8c15000, 4096, PROT_READ) =3D 0
26271 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26271 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26271 munmap(0x7f9f8a85e000, 103979)    =3D 0
26271 set_tid_address(0x7f9f8a859770)   =3D 26271
26271 set_robust_list(0x7f9f8a859780, 0x18) =3D 0
26271 futex(0x7fff8dbb0a5c, FUTEX_WAKE_PRIVATE, 1) =3D 0
26271 rt_sigaction(SIGRTMIN, {0x30e8a05380, [], SA_RESTORER|SA_SIGINFO, 0=
x30e8a0eb10}, NULL, 8) =3D 0
26271 rt_sigaction(SIGRT_1, {0x30e8a052b0, [], SA_RESTORER|SA_RESTART|SA_=
SIGINFO, 0x30e8a0eb10}, NULL, 8) =3D 0
26271 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) =3D 0
26271 getrlimit(RLIMIT_STACK, {rlim_cur=3D8192*1024, rlim_max=3DRLIM_INFI=
NITY}) =3D 0
26271 rt_sigaction(SIGFPE, {0x1, [FPE], SA_RESTORER|SA_RESTART, 0x30e8230=
2d0}, {SIG_DFL, [], 0}, 8) =3D 0
26271 brk(0)                            =3D 0x217e000
26271 brk(0x21a0000)                    =3D 0x21a0000
26271 getuid()                          =3D 0
26271 geteuid()                         =3D 0
26271 getgid()                          =3D 0
26271 getegid()                         =3D 0
26271 mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,=
 -1, 0) =3D 0x7f9f8a838000
26271 open("/dev/urandom", O_RDONLY)    =3D 3
26271 read(3, "\25\300\34\374", 4)      =3D 4
26271 close(3)                          =3D 0
26271 stat("/usr/lib64/perl5/site_perl/5.8.7/x86_64-linux-thread-multi", =
0x7fff8dbb0710) =3D -1 ENOENT (No such file or directory)
26271 stat("/usr/lib/perl5/site_perl/5.8.7", 0x7fff8dbb0710) =3D -1 ENOEN=
T (No such file or directory)
26271 stat("/usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi", =
0x7fff8dbb0710) =3D -1 ENOENT (No such file or directory)
26271 stat("/usr/lib/perl5/site_perl/5.8.6", 0x7fff8dbb0710) =3D -1 ENOEN=
T (No such file or directory)
26271 stat("/usr/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi", =
0x7fff8dbb0710) =3D -1 ENOENT (No such file or directory)
26271 stat("/usr/lib/perl5/site_perl/5.8.5", 0x7fff8dbb0710) =3D -1 ENOEN=
T (No such file or directory)
26271 stat("/usr/lib64/perl5/vendor_perl/5.8.7/x86_64-linux-thread-multi"=
, 0x7fff8dbb0710) =3D -1 ENOENT (No such file or directory)
26271 stat("/usr/lib/perl5/vendor_perl/5.8.7", 0x7fff8dbb0710) =3D -1 ENO=
ENT (No such file or directory)
26271 stat("/usr/lib64/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi"=
, 0x7fff8dbb0710) =3D -1 ENOENT (No such file or directory)
26271 stat("/usr/lib/perl5/vendor_perl/5.8.6", 0x7fff8dbb0710) =3D -1 ENO=
ENT (No such file or directory)
26271 stat("/usr/lib64/perl5/vendor_perl/5.8.5/x86_64-linux-thread-multi"=
, 0x7fff8dbb0710) =3D -1 ENOENT (No such file or directory)
26271 stat("/usr/lib/perl5/vendor_perl/5.8.5", 0x7fff8dbb0710) =3D -1 ENO=
ENT (No such file or directory)
26271 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff8dbb04d0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26271 lseek(0, 0, SEEK_CUR)             =3D 0
26271 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff8dbb04d0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26271 lseek(1, 0, SEEK_CUR)             =3D -1 ESPIPE (Illegal seek)
26271 ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff8dbb04e0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26271 lseek(2, 0, SEEK_CUR)             =3D 593656345
26271 open("/dev/null", O_RDONLY)       =3D 3
26271 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff8dbb05e0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26271 lseek(3, 0, SEEK_CUR)             =3D 0
26271 fcntl(3, F_SETFD, FD_CLOEXEC)     =3D 0
26271 fstat(3, {st_dev=3Dmakedev(0, 16), st_ino=3D584, st_mode=3DS_IFCHR|=
0666, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
0, st_rdev=3Dmakedev(1, 3), st_atime=3D2012/10/08-11:13:26, st_mtime=3D20=
12/10/08-11:13:26, st_ctime=3D2012/10/08-11:13:27}) =3D 0
26271 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) =3D 0
26271 readlink("/proc/self/exe", "/usr/bin/perl"..., 4095) =3D 13
26271 brk(0x21c1000)                    =3D 0x21c1000
26271 close(3)                          =3D 0
26271 dup(200)                          =3D 3
26271 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff8dbb04b0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26271 lseek(3, 0, SEEK_CUR)             =3D 0
26271 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26271 dup2(3, 0)                        =3D 0
26271 close(3)                          =3D 0
26271 fcntl(0, F_SETFD, 0)              =3D 0
26271 fstat(0, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26271 stat("/var/run/xen-hotplug/block", {st_dev=3Dmakedev(8, 2), st_ino=3D=
2801738, st_mode=3DS_IFREG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st=
_blksize=3D4096, st_blocks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:=
24, st_mtime=3D2012/10/09-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D =
0
26271 exit_group(0)                     =3D ?
27813 <... read resumed> "", 128)       =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], WNOHANG, NUL=
L) =3D 26271
27813 wait4(-1, 0x7fffb0100a64, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0)                   =3D 0
27813 close(3)                          =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 write(2, "+ rightfile=3D\n", 13)    =3D 13
27813 write(2, "+ '[' x =3D xy ']'\n", 17) =3D 17
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ true\n", 7)           =3D 7
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ eval 'exec 200>>/var/run/xen-hotplug/block'\n", 46) =3D=
 46
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 write(2, "++ exec\n", 8)          =3D 8
27813 open("/var/run/xen-hotplug/block", O_WRONLY|O_CREAT|O_APPEND, 0666)=
 =3D 3
27813 fcntl(200, F_GETFD)               =3D 0
27813 fcntl(200, F_DUPFD, 10)           =3D 10
27813 fcntl(200, F_GETFD)               =3D 0
27813 dup2(3, 200)                      =3D 200
27813 close(3)                          =3D 0
27813 dup2(10, 200)                     =3D 200
27813 fcntl(10, F_GETFD)                =3D 0
27813 close(10)                         =3D 0
27813 write(2, "+ flock -x 200\n", 15)  =3D 15
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [INT CHLD], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [INT CHLD], NULL, 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26272
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26272 close(255 
27813 rt_sigprocmask(SIG_BLOCK, [CHLD],  
26272 <... close resumed> )             =3D 0
27813 <... rt_sigprocmask resumed> [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [],  
26272 rt_sigprocmask(SIG_SETMASK, [],  
27813 <... rt_sigprocmask resumed> NULL, 8) =3D 0
26272 <... rt_sigprocmask resumed> NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
26272 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0},  
26272 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
27813 <... rt_sigaction resumed> {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}=
, 8) =3D 0
26272 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 wait4(-1,  
26272 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
26272 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26272 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26272 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26272 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26272 execve("/usr/bin/flock", ["flock", "-x", "200"], ["SUBSYSTEM=3Dxen-=
backend", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D=
/usr/bin:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:=
/usr/sbin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dx=
en-backend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3D=
backend/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "S=
HLVL=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/flock"]) =3D 0=

26272 brk(0)                            =3D 0x1746000
26272 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fad826e0000
26272 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fad826df000
26272 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26272 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26272 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26272 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7fad826c5000=

26272 close(3)                          =3D 0
26272 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26272 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26272 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26272 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26272 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26272 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26272 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26272 close(3)                          =3D 0
26272 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fad826c4000
26272 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fad826c3000
26272 arch_prctl(ARCH_SET_FS, 0x7fad826c36e0) =3D 0
26272 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26272 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26272 munmap(0x7fad826c5000, 103979)    =3D 0
26272 flock(200, LOCK_EX)               =3D 0
26272 exit_group(0)                     =3D ?
27813 <... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], 0,=
 NULL) =3D 26272
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, 0x7fffb0100a24, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0xffffffffffffffff)  =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 pipe([3, 4])                      =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26273
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {0=
x436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26273 close(255 
27813 close(4 
26273 <... close resumed> )             =3D 0
27813 <... close resumed> )             =3D 0
27813 read(3,  
26273 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26273 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26273 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26273 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26273 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26273 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26273 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26273 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {S=
IG_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26273 rt_sigaction(SIGINT, {0x4481f0, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26273 dup2(4, 1)                        =3D 1
26273 close(4)                          =3D 0
26273 close(3)                          =3D 0
26273 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26273 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26273 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26273 write(2, "++ perl -e '\n            open STDIN, \"<&200\" or die $!=
;\n            my $fd_inum =3D (stat STDIN)[1]; die $! unless defined $fd=
_inum;\n            my $file_inum =3D (stat $ARGV[0])[1];\n            pr=
int \"y\\n\" if $fd_inum eq $file_inum;\n", 230) =3D 230
26273 write(2, "                             ' /var/run/xen-hotplug/block=
\n", 58) =3D 58
26273 stat(".", {st_dev=3Dmakedev(8, 2), st_ino=3D2, st_mode=3DS_IFDIR|07=
55, st_nlink=3D24, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
8, st_size=3D4096, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2012/10/08-=
11:13:38, st_ctime=3D2012/10/08-11:13:38}) =3D 0
26273 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26273 access("/usr/bin/perl", X_OK)     =3D 0
26273 access("/usr/bin/perl", R_OK)     =3D 0
26273 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26273 access("/usr/bin/perl", X_OK)     =3D 0
26273 access("/usr/bin/perl", R_OK)     =3D 0
26273 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
481f0, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26273 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26273 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26273 execve("/usr/bin/perl", ["perl", "-e", "\n            open STDIN, \=
"<&200\" or die $!;\n            my $fd_inum =3D (stat STDIN)[1]; die $! =
unless defined $fd_inum;\n            my $file_inum =3D (stat $ARGV[0])[1=
];\n            print \"y\\n\" if $fd_inum eq $file_inum;\n              =
               ", "/var/run/xen-hotplug/block"], ["SUBSYSTEM=3Dxen-backen=
d", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D/usr/b=
in:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:/usr/s=
bin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dxen-bac=
kend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3Dback=
end/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "SHLVL=
=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/perl"]) =3D 0
26273 brk(0)                            =3D 0xd7d000
26273 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f085a389000
26273 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f085a388000
26273 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26273 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64/libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26273 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64", 0x7fff7446cc60) =3D -1 ENOENT (No such file or directory)
26273 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/lib=
perl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26273 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls", 0=
x7fff7446cc60) =3D -1 ENOENT (No such file or directory)
26273 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64/=
libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26273 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64"=
, 0x7fff7446cc60) =3D -1 ENOENT (No such file or directory)
26273 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl=
=2Eso", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26273 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE", 0x7ff=
f7446cc60) =3D -1 ENOENT (No such file or directory)
26273 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26273 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26273 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7f085a36e000=

26273 close(3)                          =3D 0
26273 open("/usr/lib64/libperl.so", O_RDONLY) =3D 3
26273 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\34\203%=
4\0\0\0@\0\0\0\0\0\0\0\360;\23\0\0\0\0\0\0\0\0\0@\0008\0\5\0@\0\35\0\34\0=
\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\200%4\0\0\0\0\0\200%4\0\0\0T\260\22\=
0\0\0\0\0T\260\22\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0X\260\22\0\0\0\=
0\0X\260\262%4\0\0\0X\260\262%4\0\0\0\250\201\0\0\0\0\0\0\350\242\0\0\0\0=
\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\265\22\0\0\0\0\0\370\265\262%4\0\=
0\0\370\265\262%4\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\=
0\0P\345td\4\0\0\0\250u\21\0\0\0\0\0\250u\221%4\0\0\0\250u\221%4\0\0\0D@\=
0\0\0\0\0\0D@\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\7\4\0\0\360\0\0\0\0\1\0\0\16\0\0\0\0\0\0@\0\200\203\200\225\1\22\=
264\3\31\200l\0\32\0 \5\201\0\240\3\2B\0\200\21R \0\22\0\0\16P\20#\10\216=
\334\30\211\"\0\10 \200\3B\220@\0\1\206\20\30\2\3\21\203$!\312A0\224Y\200=
\27\0\242\26\10\24R@\10\200\220\20A\10\0\220\1\200\206\2\10\304\30i\0\220=
\1\1\202\200\22\20\0\n\1H\0\n\2001J \6\31@L\207\20\10\0000\10(\200\2\0\4\=
251t\"\262\310!\212\240\320\"\0\t"..., 832) =3D 832
26273 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2839671, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D2480, st_size=3D1262384, st_atime=3D2012/10/09-12:04:35, st_mtime=3D=
2012/09/11-12:45:05, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26273 mmap(0x3425800000, 3363648, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425800000
26273 mprotect(0x342592c000, 2093056, PROT_NONE) =3D 0
26273 mmap(0x3425b2b000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x12b000) =3D 0x3425b2b000
26273 mmap(0x3425b34000, 4928, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3425b34000
26273 close(3)                          =3D 0
26273 open("/lib64/libresolv.so.2", O_RDONLY) =3D 3
26273 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\2402\0'4\0\=
0\0@\0\0\0\0\0\0\0@a\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\5\0=
\0\0@\0\0\0\0\0\0\0@\0\0'4\0\0\0@\0\0'4\0\0\0\370\1\0\0\0\0\0\0\370\1\0\0=
\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \361\0\0\0\0\0\0 \361\0'4\0\0\0=
 \361\0'4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\=
0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0'4\0\0\0\0\0\0'4\0\0\0$\10\1\0\0\0\0\0$\10=
\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\24\1\0\0\0\0\0\340\24!'4\=
0\0\0\340\24!'4\0\0\0\340\r\0\0\0\0\0\0\0106\0\0\0\0\0\0\0\0 \0\0\0\0\0\2=
\0\0\0\6\0\0\0\350\35\1\0\0\0\0\0\350\35!'4\0\0\0\350\35!'4\0\0\0\300\1\0=
\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\=
0\0\0008\2\0'4\0\0\0008\2\0'4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0=
\0\0\0\0P\345td\4\0\0\0<\361\0\0\0\0\0\0<\361\0'4\0\0\0<\361\0'4\0\0\0,\3=
\0\0\0\0\0\0,\3\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 8=
32
26273 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148119, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D192, st_size=3D92736, st_atime=3D2012/10/09-11:16:43, st_mtime=3D201=
0/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:42}) =3D 0
26273 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f085a36d000
26273 mmap(0x3427000000, 2181864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3427000000
26273 mprotect(0x3427011000, 2097152, PROT_NONE) =3D 0
26273 mmap(0x3427211000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x11000) =3D 0x3427211000
26273 mmap(0x3427213000, 6888, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3427213000
26273 close(3)                          =3D 0
26273 open("/lib64/libnsl.so.1", O_RDONLY) =3D 3
26273 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240@\340\35=
10\0\0\0@\0\0\0\0\0\0\0\360\265\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0=
\6\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\340\3510\0\0\0@\0\340\3510\0\0\0\370\1=
\0\0\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \33\1\0\0=
\0\0\0 \33\341\3510\0\0\0 \33\341\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\=
0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\340\3510\0\0\0=
\0\0\340\3510\0\0\0\310@\1\0\0\0\0\0\310@\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\=
0\0\6\0\0\0xM\1\0\0\0\0\0xM\1\3520\0\0\0xM\1\3520\0\0\0\310\5\0\0\0\0\0\0=
008-\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250M\1\0\0\0\0\0\250M\1\3=
520\0\0\0\250M\1\3520\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\340\3510\0\0\0008\2\340\351=
0\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0<\33\=
1\0\0\0\0\0<\33\341\3510\0\0\0<\33\341\3510\0\0\0\\\5\0\0\0\0\0\0\\\5\0\0=
\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26273 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147206, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D232, st_size=3D114352, st_atime=3D2012/10/09-12:01:01, st_mtime=3D20=
10/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:44}) =3D 0
26273 mmap(0x30e9e00000, 2194096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9e00000
26273 mprotect(0x30e9e15000, 2093056, PROT_NONE) =3D 0
26273 mmap(0x30ea014000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x14000) =3D 0x30ea014000
26273 mmap(0x30ea016000, 6832, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x30ea016000
26273 close(3)                          =3D 0
26273 open("/lib64/libdl.so.2", O_RDONLY) =3D 3
26273 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\16`\3500=
\0\0\0@\0\0\0\0\0\0\0@R\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0`\3500\0\0\0@\0`\3500\0\0\0\370\1\0\0\0\0\0\0\37=
0\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\300\32\0\0\0\0\0\0\300\3=
2`\3500\0\0\0\300\32`\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0`\3500\0\0\0\0\0`\3500\0\0\=
0\224\37\0\0\0\0\0\0\224\37\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0`-\=
0\0\0\0\0\0`-\200\3500\0\0\0`-\200\3500\0\0\0 \3\0\0\0\0\0\0\240\3\0\0\0\=
0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\240-\0\0\0\0\0\0\240-\200\3500\0\0\0=
\240-\200\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0=
\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2`\3500\0\0\0008\2`\3500\0\0\0 \0\0\=
0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\334\32\0\0\0\0\0\=
0\334\32`\3500\0\0\0\334\32`\3500\0\0\0\264\0\0\0\0\0\0\0\264\0\0\0\0\0\0=
\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26273 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147322, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D48, st_size=3D23360, st_atime=3D2012/10/09-11:13:54, st_mtime=3D2010=
/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26273 mmap(0x30e8600000, 2109696, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8600000
26273 mprotect(0x30e8602000, 2097152, PROT_NONE) =3D 0
26273 mmap(0x30e8802000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x2000) =3D 0x30e8802000
26273 close(3)                          =3D 0
26273 open("/lib64/libm.so.6", O_RDONLY) =3D 3
26273 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`>\240\3510\=
0\0\0@\0\0\0\0\0\0\0\240X\t\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0)\0(\0\6\0\0\=
0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3510\0\0\0@\0\240\3510\0\0\0\370\1\0\0\0\=
0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\360\303\7\0\0\0\=
0\0\360\303\247\3510\0\0\0\360\303\247\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0=
\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3510\=
0\0\0\0\0\240\3510\0\0\0000\22\10\0\0\0\0\0000\22\10\0\0\0\0\0\0\0 \0\0\0=
\0\0\1\0\0\0\6\0\0\0\270\35\10\0\0\0\0\0\270\35\310\3510\0\0\0\270\35\310=
\3510\0\0\0\320\2\0\0\0\0\0\0 \3\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0=
\0\350\35\10\0\0\0\0\0\350\35\310\3510\0\0\0\350\35\310\3510\0\0\0\300\1\=
0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0=
\0\0\0008\2\240\3510\0\0\0008\2\240\3510\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\f\304\7\0\0\0\0\0\f\304\247\3510\0\0\0=
\f\304\247\3510\0\0\0\374\r\0\0\0\0\0\0\374\r\0\0\0\0\0\0\4\0\0\0\0\0\0\0=
Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0"..., 832) =3D 832
26273 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147337, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D1216, st_size=3D615136, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2=
010/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26273 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f085a36c000
26273 mmap(0x30e9a00000, 2629848, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9a00000
26273 mprotect(0x30e9a82000, 2093056, PROT_NONE) =3D 0
26273 mmap(0x30e9c81000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x81000) =3D 0x30e9c81000
26273 close(3)                          =3D 0
26273 open("/lib64/libcrypt.so.1", O_RDONLY) =3D 3
26273 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\t\300%4=
\0\0\0@\0\0\0\0\0\0\0\30\265\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\=
0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\300%4\0\0\0@\0\300%4\0\0\0\370\1\0\0\0\0\=
0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340}\0\0\0\0\0\0\3=
40}\300%4\0\0\0\340}\300%4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\300%4\0\0\0\0\0\300%4\0\0\=
0\4\205\0\0\0\0\0\0\4\205\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\310\=
215\0\0\0\0\0\0\310\215\340%4\0\0\0\310\215\340%4\0\0\0\250\2\0\0\0\0\0\0=
\370\343\2\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\215\0\0\0\0\0\0\3=
70\215\340%4\0\0\0\370\215\340%4\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\=
0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\300%4\0\0\0008\2=
\300%4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0=
\374}\0\0\0\0\0\0\374}\300%4\0\0\0\374}\300%4\0\0\0\34\1\0\0\0\0\0\0\34\1=
\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26273 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148123, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D96, st_size=3D48600, st_atime=3D2012/10/09-12:01:01, st_mtime=3D2010=
/07/28-03:52:39, st_ctime=3D2012/09/11-14:53:52}) =3D 0
26273 mmap(0x3425c00000, 2322880, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425c00000
26273 mprotect(0x3425c09000, 2093056, PROT_NONE) =3D 0
26273 mmap(0x3425e08000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x8000) =3D 0x3425e08000
26273 mmap(0x3425e0a000, 184768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FI=
XED|MAP_ANONYMOUS, -1, 0) =3D 0x3425e0a000
26273 close(3)                          =3D 0
26273 open("/lib64/libutil.so.1", O_RDONLY) =3D 3
26273 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\16\0(4\=
0\0\0@\0\0\0\0\0\0\0(>\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0\0(4\0\0\0@\0\0(4\0\0\0\370\1\0\0\0\0\0\0\370\1\=
0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340\26\0\0\0\0\0\0\340\26\0(=
4\0\0\0\340\26\0(4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0=
\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0(4\0\0\0\0\0\0(4\0\0\0P\32\0\0\0\=
0\0\0P\32\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\35\0\0\0\0\0\0\3=
40\35 (4\0\0\0\340\35 (4\0\0\0 \3\0\0\0\0\0\0000\3\0\0\0\0\0\0\0\0 \0\0\0=
\0\0\2\0\0\0\6\0\0\0\20\36\0\0\0\0\0\0\20\36 (4\0\0\0\20\36 (4\0\0\0\300\=
1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0=
\0\0\0\0008\2\0(4\0\0\0008\2\0(4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\=
0\0\0\0\0\0P\345td\4\0\0\0\374\26\0\0\0\0\0\0\374\26\0(4\0\0\0\374\26\0(4=
\0\0\0D\0\0\0\0\0\0\0D\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8=
32) =3D 832
26273 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147063, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D40, st_size=3D18152, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2010=
/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:49}) =3D 0
26273 mmap(0x3428000000, 2105616, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3428000000
26273 mprotect(0x3428002000, 2093056, PROT_NONE) =3D 0
26273 mmap(0x3428201000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x1000) =3D 0x3428201000
26273 close(3)                          =3D 0
26273 open("/lib64/libpthread.so.0", O_RDONLY) =3D 3
26273 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240W\240\35=
00\0\0\0@\0\0\0\0\0\0\0\340/\2\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0'\0&\0\6\0=
\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3500\0\0\0@\0\240\3500\0\0\0\370\1\0\0=
\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\240\t\1\0\0\0=
\0\0\240\t\241\3500\0\0\0\240\t\241\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\=
0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3500\0\0=
\0\0\0\240\3500\0\0\0pZ\1\0\0\0\0\0pZ\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\=
6\0\0\0\270[\1\0\0\0\0\0\270[\301\3500\0\0\0\270[\301\3500\0\0\0\230\6\0\=
0\0\0\0\0\270G\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250]\1\0\0\0\0\=
0\250]\301\3500\0\0\0\250]\301\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0=
\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\240\3500\0\0\=
0008\2\240\3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345t=
d\4\0\0\0\274\t\1\0\0\0\0\0\274\t\241\3500\0\0\0\274\t\241\3500\0\0\0\344=
\t\0\0\0\0\0\0\344\t\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =
=3D 832
26273 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147328, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D296, st_size=3D145824, st_atime=3D2012/10/09-11:16:43, st_mtime=3D20=
10/07/28-03:52:41, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26273 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f085a36b000
26273 mmap(0x30e8a00000, 2204528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8a00000
26273 mprotect(0x30e8a16000, 2093056, PROT_NONE) =3D 0
26273 mmap(0x30e8c15000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x15000) =3D 0x30e8c15000
26273 mmap(0x30e8c17000, 13168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8c17000
26273 close(3)                          =3D 0
26273 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26273 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26273 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26273 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26273 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26273 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26273 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26273 close(3)                          =3D 0
26273 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f085a36a000
26273 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f085a369000
26273 arch_prctl(ARCH_SET_FS, 0x7f085a3696e0) =3D 0
26273 mprotect(0x3427211000, 4096, PROT_READ) =3D 0
26273 mprotect(0x30ea014000, 4096, PROT_READ) =3D 0
26273 mprotect(0x30e8802000, 4096, PROT_READ) =3D 0
26273 mprotect(0x30e9c81000, 4096, PROT_READ) =3D 0
26273 mprotect(0x3425e08000, 4096, PROT_READ) =3D 0
26273 mprotect(0x3428201000, 4096, PROT_READ) =3D 0
26273 mprotect(0x30e8c15000, 4096, PROT_READ) =3D 0
26273 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26273 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26273 munmap(0x7f085a36e000, 103979)    =3D 0
26273 set_tid_address(0x7f085a369770)   =3D 26273
26273 set_robust_list(0x7f085a369780, 0x18) =3D 0
26273 futex(0x7fff7446d78c, FUTEX_WAKE_PRIVATE, 1) =3D 0
26273 rt_sigaction(SIGRTMIN, {0x30e8a05380, [], SA_RESTORER|SA_SIGINFO, 0=
x30e8a0eb10}, NULL, 8) =3D 0
26273 rt_sigaction(SIGRT_1, {0x30e8a052b0, [], SA_RESTORER|SA_RESTART|SA_=
SIGINFO, 0x30e8a0eb10}, NULL, 8) =3D 0
26273 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) =3D 0
26273 getrlimit(RLIMIT_STACK, {rlim_cur=3D8192*1024, rlim_max=3DRLIM_INFI=
NITY}) =3D 0
26273 rt_sigaction(SIGFPE, {0x1, [FPE], SA_RESTORER|SA_RESTART, 0x30e8230=
2d0}, {SIG_DFL, [], 0}, 8) =3D 0
26273 brk(0)                            =3D 0xd7d000
26273 brk(0xd9f000)                     =3D 0xd9f000
26273 getuid()                          =3D 0
26273 geteuid()                         =3D 0
26273 getgid()                          =3D 0
26273 getegid()                         =3D 0
26273 mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,=
 -1, 0) =3D 0x7f085a348000
26273 open("/dev/urandom", O_RDONLY)    =3D 3
26273 read(3, "\245\"\234\327", 4)      =3D 4
26273 close(3)                          =3D 0
26273 stat("/usr/lib64/perl5/site_perl/5.8.7/x86_64-linux-thread-multi", =
0x7fff7446d440) =3D -1 ENOENT (No such file or directory)
26273 stat("/usr/lib/perl5/site_perl/5.8.7", 0x7fff7446d440) =3D -1 ENOEN=
T (No such file or directory)
26273 stat("/usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi", =
0x7fff7446d440) =3D -1 ENOENT (No such file or directory)
26273 stat("/usr/lib/perl5/site_perl/5.8.6", 0x7fff7446d440) =3D -1 ENOEN=
T (No such file or directory)
26273 stat("/usr/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi", =
0x7fff7446d440) =3D -1 ENOENT (No such file or directory)
26273 stat("/usr/lib/perl5/site_perl/5.8.5", 0x7fff7446d440) =3D -1 ENOEN=
T (No such file or directory)
26273 stat("/usr/lib64/perl5/vendor_perl/5.8.7/x86_64-linux-thread-multi"=
, 0x7fff7446d440) =3D -1 ENOENT (No such file or directory)
26273 stat("/usr/lib/perl5/vendor_perl/5.8.7", 0x7fff7446d440) =3D -1 ENO=
ENT (No such file or directory)
26273 stat("/usr/lib64/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi"=
, 0x7fff7446d440) =3D -1 ENOENT (No such file or directory)
26273 stat("/usr/lib/perl5/vendor_perl/5.8.6", 0x7fff7446d440) =3D -1 ENO=
ENT (No such file or directory)
26273 stat("/usr/lib64/perl5/vendor_perl/5.8.5/x86_64-linux-thread-multi"=
, 0x7fff7446d440) =3D -1 ENOENT (No such file or directory)
26273 stat("/usr/lib/perl5/vendor_perl/5.8.5", 0x7fff7446d440) =3D -1 ENO=
ENT (No such file or directory)
26273 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff7446d200) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26273 lseek(0, 0, SEEK_CUR)             =3D 0
26273 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff7446d200) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26273 lseek(1, 0, SEEK_CUR)             =3D -1 ESPIPE (Illegal seek)
26273 ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff7446d210) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26273 lseek(2, 0, SEEK_CUR)             =3D 593656739
26273 open("/dev/null", O_RDONLY)       =3D 3
26273 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff7446d310) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26273 lseek(3, 0, SEEK_CUR)             =3D 0
26273 fcntl(3, F_SETFD, FD_CLOEXEC)     =3D 0
26273 fstat(3, {st_dev=3Dmakedev(0, 16), st_ino=3D584, st_mode=3DS_IFCHR|=
0666, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
0, st_rdev=3Dmakedev(1, 3), st_atime=3D2012/10/08-11:13:26, st_mtime=3D20=
12/10/08-11:13:26, st_ctime=3D2012/10/08-11:13:27}) =3D 0
26273 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) =3D 0
26273 readlink("/proc/self/exe", "/usr/bin/perl"..., 4095) =3D 13
26273 brk(0xdc0000)                     =3D 0xdc0000
26273 close(3)                          =3D 0
26273 dup(200)                          =3D 3
26273 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff7446d1e0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26273 lseek(3, 0, SEEK_CUR)             =3D 0
26273 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26273 dup2(3, 0)                        =3D 0
26273 close(3)                          =3D 0
26273 fcntl(0, F_SETFD, 0)              =3D 0
26273 fstat(0, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26273 stat("/var/run/xen-hotplug/block", {st_dev=3Dmakedev(8, 2), st_ino=3D=
2801738, st_mode=3DS_IFREG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st=
_blksize=3D4096, st_blocks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:=
24, st_mtime=3D2012/10/09-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D =
0
26273 exit_group(0)                     =3D ?
27813 <... read resumed> "", 128)       =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], WNOHANG, NUL=
L) =3D 26273
27813 wait4(-1, 0x7fffb0100a64, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0)                   =3D 0
27813 close(3)                          =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 write(2, "+ rightfile=3D\n", 13)    =3D 13
27813 write(2, "+ '[' x =3D xy ']'\n", 17) =3D 17
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ true\n", 7)           =3D 7
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ eval 'exec 200>>/var/run/xen-hotplug/block'\n", 46) =3D=
 46
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 write(2, "++ exec\n", 8)          =3D 8
27813 open("/var/run/xen-hotplug/block", O_WRONLY|O_CREAT|O_APPEND, 0666)=
 =3D 3
27813 fcntl(200, F_GETFD)               =3D 0
27813 fcntl(200, F_DUPFD, 10)           =3D 10
27813 fcntl(200, F_GETFD)               =3D 0
27813 dup2(3, 200)                      =3D 200
27813 close(3)                          =3D 0
27813 dup2(10, 200)                     =3D 200
27813 fcntl(10, F_GETFD)                =3D 0
27813 close(10)                         =3D 0
27813 write(2, "+ flock -x 200\n", 15)  =3D 15
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [INT CHLD], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [INT CHLD], NULL, 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26274
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26274 close(255 
27813 rt_sigprocmask(SIG_BLOCK, [CHLD],  
26274 <... close resumed> )             =3D 0
27813 <... rt_sigprocmask resumed> [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [],  
26274 rt_sigprocmask(SIG_SETMASK, [],  
27813 <... rt_sigprocmask resumed> NULL, 8) =3D 0
26274 <... rt_sigprocmask resumed> NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
26274 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0},  
26274 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
27813 <... rt_sigaction resumed> {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}=
, 8) =3D 0
26274 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 wait4(-1,  
26274 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
26274 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26274 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26274 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26274 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26274 execve("/usr/bin/flock", ["flock", "-x", "200"], ["SUBSYSTEM=3Dxen-=
backend", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D=
/usr/bin:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:=
/usr/sbin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dx=
en-backend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3D=
backend/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "S=
HLVL=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/flock"]) =3D 0=

26274 brk(0)                            =3D 0x1a9e000
26274 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fda76a0b000
26274 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fda76a0a000
26274 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26274 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26274 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26274 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7fda769f0000=

26274 close(3)                          =3D 0
26274 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26274 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26274 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26274 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26274 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26274 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26274 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26274 close(3)                          =3D 0
26274 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fda769ef000
26274 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fda769ee000
26274 arch_prctl(ARCH_SET_FS, 0x7fda769ee6e0) =3D 0
26274 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26274 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26274 munmap(0x7fda769f0000, 103979)    =3D 0
26274 flock(200, LOCK_EX)               =3D 0
26274 exit_group(0)                     =3D ?
27813 <... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], 0,=
 NULL) =3D 26274
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, 0x7fffb0100a24, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0xffffffffffffffff)  =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 pipe([3, 4])                      =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26275
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {0=
x436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26275 close(255 
27813 close(4 
26275 <... close resumed> )             =3D 0
27813 <... close resumed> )             =3D 0
27813 read(3,  
26275 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26275 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26275 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26275 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26275 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26275 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26275 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26275 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {S=
IG_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26275 rt_sigaction(SIGINT, {0x4481f0, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26275 dup2(4, 1)                        =3D 1
26275 close(4)                          =3D 0
26275 close(3)                          =3D 0
26275 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26275 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26275 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26275 write(2, "++ perl -e '\n            open STDIN, \"<&200\" or die $!=
;\n            my $fd_inum =3D (stat STDIN)[1]; die $! unless defined $fd=
_inum;\n            my $file_inum =3D (stat $ARGV[0])[1];\n            pr=
int \"y\\n\" if $fd_inum eq $file_inum;\n", 230) =3D 230
26275 write(2, "                             ' /var/run/xen-hotplug/block=
\n", 58) =3D 58
26275 stat(".", {st_dev=3Dmakedev(8, 2), st_ino=3D2, st_mode=3DS_IFDIR|07=
55, st_nlink=3D24, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
8, st_size=3D4096, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2012/10/08-=
11:13:38, st_ctime=3D2012/10/08-11:13:38}) =3D 0
26275 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26275 access("/usr/bin/perl", X_OK)     =3D 0
26275 access("/usr/bin/perl", R_OK)     =3D 0
26275 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26275 access("/usr/bin/perl", X_OK)     =3D 0
26275 access("/usr/bin/perl", R_OK)     =3D 0
26275 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
481f0, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26275 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26275 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26275 execve("/usr/bin/perl", ["perl", "-e", "\n            open STDIN, \=
"<&200\" or die $!;\n            my $fd_inum =3D (stat STDIN)[1]; die $! =
unless defined $fd_inum;\n            my $file_inum =3D (stat $ARGV[0])[1=
];\n            print \"y\\n\" if $fd_inum eq $file_inum;\n              =
               ", "/var/run/xen-hotplug/block"], ["SUBSYSTEM=3Dxen-backen=
d", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D/usr/b=
in:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:/usr/s=
bin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dxen-bac=
kend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3Dback=
end/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "SHLVL=
=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/perl"]) =3D 0
26275 brk(0)                            =3D 0x1f94000
26275 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f60ea136000
26275 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f60ea135000
26275 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26275 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64/libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26275 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64", 0x7fff7127c790) =3D -1 ENOENT (No such file or directory)
26275 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/lib=
perl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26275 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls", 0=
x7fff7127c790) =3D -1 ENOENT (No such file or directory)
26275 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64/=
libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26275 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64"=
, 0x7fff7127c790) =3D -1 ENOENT (No such file or directory)
26275 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl=
=2Eso", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26275 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE", 0x7ff=
f7127c790) =3D -1 ENOENT (No such file or directory)
26275 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26275 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26275 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7f60ea11b000=

26275 close(3)                          =3D 0
26275 open("/usr/lib64/libperl.so", O_RDONLY) =3D 3
26275 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\34\203%=
4\0\0\0@\0\0\0\0\0\0\0\360;\23\0\0\0\0\0\0\0\0\0@\0008\0\5\0@\0\35\0\34\0=
\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\200%4\0\0\0\0\0\200%4\0\0\0T\260\22\=
0\0\0\0\0T\260\22\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0X\260\22\0\0\0\=
0\0X\260\262%4\0\0\0X\260\262%4\0\0\0\250\201\0\0\0\0\0\0\350\242\0\0\0\0=
\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\265\22\0\0\0\0\0\370\265\262%4\0\=
0\0\370\265\262%4\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\=
0\0P\345td\4\0\0\0\250u\21\0\0\0\0\0\250u\221%4\0\0\0\250u\221%4\0\0\0D@\=
0\0\0\0\0\0D@\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\7\4\0\0\360\0\0\0\0\1\0\0\16\0\0\0\0\0\0@\0\200\203\200\225\1\22\=
264\3\31\200l\0\32\0 \5\201\0\240\3\2B\0\200\21R \0\22\0\0\16P\20#\10\216=
\334\30\211\"\0\10 \200\3B\220@\0\1\206\20\30\2\3\21\203$!\312A0\224Y\200=
\27\0\242\26\10\24R@\10\200\220\20A\10\0\220\1\200\206\2\10\304\30i\0\220=
\1\1\202\200\22\20\0\n\1H\0\n\2001J \6\31@L\207\20\10\0000\10(\200\2\0\4\=
251t\"\262\310!\212\240\320\"\0\t"..., 832) =3D 832
26275 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2839671, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D2480, st_size=3D1262384, st_atime=3D2012/10/09-12:04:35, st_mtime=3D=
2012/09/11-12:45:05, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26275 mmap(0x3425800000, 3363648, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425800000
26275 mprotect(0x342592c000, 2093056, PROT_NONE) =3D 0
26275 mmap(0x3425b2b000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x12b000) =3D 0x3425b2b000
26275 mmap(0x3425b34000, 4928, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3425b34000
26275 close(3)                          =3D 0
26275 open("/lib64/libresolv.so.2", O_RDONLY) =3D 3
26275 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\2402\0'4\0\=
0\0@\0\0\0\0\0\0\0@a\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\5\0=
\0\0@\0\0\0\0\0\0\0@\0\0'4\0\0\0@\0\0'4\0\0\0\370\1\0\0\0\0\0\0\370\1\0\0=
\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \361\0\0\0\0\0\0 \361\0'4\0\0\0=
 \361\0'4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\=
0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0'4\0\0\0\0\0\0'4\0\0\0$\10\1\0\0\0\0\0$\10=
\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\24\1\0\0\0\0\0\340\24!'4\=
0\0\0\340\24!'4\0\0\0\340\r\0\0\0\0\0\0\0106\0\0\0\0\0\0\0\0 \0\0\0\0\0\2=
\0\0\0\6\0\0\0\350\35\1\0\0\0\0\0\350\35!'4\0\0\0\350\35!'4\0\0\0\300\1\0=
\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\=
0\0\0008\2\0'4\0\0\0008\2\0'4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0=
\0\0\0\0P\345td\4\0\0\0<\361\0\0\0\0\0\0<\361\0'4\0\0\0<\361\0'4\0\0\0,\3=
\0\0\0\0\0\0,\3\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 8=
32
26275 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148119, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D192, st_size=3D92736, st_atime=3D2012/10/09-11:16:43, st_mtime=3D201=
0/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:42}) =3D 0
26275 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f60ea11a000
26275 mmap(0x3427000000, 2181864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3427000000
26275 mprotect(0x3427011000, 2097152, PROT_NONE) =3D 0
26275 mmap(0x3427211000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x11000) =3D 0x3427211000
26275 mmap(0x3427213000, 6888, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3427213000
26275 close(3)                          =3D 0
26275 open("/lib64/libnsl.so.1", O_RDONLY) =3D 3
26275 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240@\340\35=
10\0\0\0@\0\0\0\0\0\0\0\360\265\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0=
\6\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\340\3510\0\0\0@\0\340\3510\0\0\0\370\1=
\0\0\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \33\1\0\0=
\0\0\0 \33\341\3510\0\0\0 \33\341\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\=
0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\340\3510\0\0\0=
\0\0\340\3510\0\0\0\310@\1\0\0\0\0\0\310@\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\=
0\0\6\0\0\0xM\1\0\0\0\0\0xM\1\3520\0\0\0xM\1\3520\0\0\0\310\5\0\0\0\0\0\0=
008-\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250M\1\0\0\0\0\0\250M\1\3=
520\0\0\0\250M\1\3520\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\340\3510\0\0\0008\2\340\351=
0\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0<\33\=
1\0\0\0\0\0<\33\341\3510\0\0\0<\33\341\3510\0\0\0\\\5\0\0\0\0\0\0\\\5\0\0=
\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26275 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147206, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D232, st_size=3D114352, st_atime=3D2012/10/09-12:01:01, st_mtime=3D20=
10/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:44}) =3D 0
26275 mmap(0x30e9e00000, 2194096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9e00000
26275 mprotect(0x30e9e15000, 2093056, PROT_NONE) =3D 0
26275 mmap(0x30ea014000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x14000) =3D 0x30ea014000
26275 mmap(0x30ea016000, 6832, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x30ea016000
26275 close(3)                          =3D 0
26275 open("/lib64/libdl.so.2", O_RDONLY) =3D 3
26275 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\16`\3500=
\0\0\0@\0\0\0\0\0\0\0@R\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0`\3500\0\0\0@\0`\3500\0\0\0\370\1\0\0\0\0\0\0\37=
0\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\300\32\0\0\0\0\0\0\300\3=
2`\3500\0\0\0\300\32`\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0`\3500\0\0\0\0\0`\3500\0\0\=
0\224\37\0\0\0\0\0\0\224\37\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0`-\=
0\0\0\0\0\0`-\200\3500\0\0\0`-\200\3500\0\0\0 \3\0\0\0\0\0\0\240\3\0\0\0\=
0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\240-\0\0\0\0\0\0\240-\200\3500\0\0\0=
\240-\200\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0=
\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2`\3500\0\0\0008\2`\3500\0\0\0 \0\0\=
0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\334\32\0\0\0\0\0\=
0\334\32`\3500\0\0\0\334\32`\3500\0\0\0\264\0\0\0\0\0\0\0\264\0\0\0\0\0\0=
\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26275 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147322, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D48, st_size=3D23360, st_atime=3D2012/10/09-11:13:54, st_mtime=3D2010=
/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26275 mmap(0x30e8600000, 2109696, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8600000
26275 mprotect(0x30e8602000, 2097152, PROT_NONE) =3D 0
26275 mmap(0x30e8802000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x2000) =3D 0x30e8802000
26275 close(3)                          =3D 0
26275 open("/lib64/libm.so.6", O_RDONLY) =3D 3
26275 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`>\240\3510\=
0\0\0@\0\0\0\0\0\0\0\240X\t\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0)\0(\0\6\0\0\=
0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3510\0\0\0@\0\240\3510\0\0\0\370\1\0\0\0\=
0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\360\303\7\0\0\0\=
0\0\360\303\247\3510\0\0\0\360\303\247\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0=
\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3510\=
0\0\0\0\0\240\3510\0\0\0000\22\10\0\0\0\0\0000\22\10\0\0\0\0\0\0\0 \0\0\0=
\0\0\1\0\0\0\6\0\0\0\270\35\10\0\0\0\0\0\270\35\310\3510\0\0\0\270\35\310=
\3510\0\0\0\320\2\0\0\0\0\0\0 \3\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0=
\0\350\35\10\0\0\0\0\0\350\35\310\3510\0\0\0\350\35\310\3510\0\0\0\300\1\=
0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0=
\0\0\0008\2\240\3510\0\0\0008\2\240\3510\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\f\304\7\0\0\0\0\0\f\304\247\3510\0\0\0=
\f\304\247\3510\0\0\0\374\r\0\0\0\0\0\0\374\r\0\0\0\0\0\0\4\0\0\0\0\0\0\0=
Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0"..., 832) =3D 832
26275 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147337, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D1216, st_size=3D615136, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2=
010/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26275 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f60ea119000
26275 mmap(0x30e9a00000, 2629848, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9a00000
26275 mprotect(0x30e9a82000, 2093056, PROT_NONE) =3D 0
26275 mmap(0x30e9c81000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x81000) =3D 0x30e9c81000
26275 close(3)                          =3D 0
26275 open("/lib64/libcrypt.so.1", O_RDONLY) =3D 3
26275 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\t\300%4=
\0\0\0@\0\0\0\0\0\0\0\30\265\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\=
0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\300%4\0\0\0@\0\300%4\0\0\0\370\1\0\0\0\0\=
0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340}\0\0\0\0\0\0\3=
40}\300%4\0\0\0\340}\300%4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\300%4\0\0\0\0\0\300%4\0\0\=
0\4\205\0\0\0\0\0\0\4\205\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\310\=
215\0\0\0\0\0\0\310\215\340%4\0\0\0\310\215\340%4\0\0\0\250\2\0\0\0\0\0\0=
\370\343\2\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\215\0\0\0\0\0\0\3=
70\215\340%4\0\0\0\370\215\340%4\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\=
0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\300%4\0\0\0008\2=
\300%4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0=
\374}\0\0\0\0\0\0\374}\300%4\0\0\0\374}\300%4\0\0\0\34\1\0\0\0\0\0\0\34\1=
\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26275 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148123, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D96, st_size=3D48600, st_atime=3D2012/10/09-12:01:01, st_mtime=3D2010=
/07/28-03:52:39, st_ctime=3D2012/09/11-14:53:52}) =3D 0
26275 mmap(0x3425c00000, 2322880, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425c00000
26275 mprotect(0x3425c09000, 2093056, PROT_NONE) =3D 0
26275 mmap(0x3425e08000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x8000) =3D 0x3425e08000
26275 mmap(0x3425e0a000, 184768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FI=
XED|MAP_ANONYMOUS, -1, 0) =3D 0x3425e0a000
26275 close(3)                          =3D 0
26275 open("/lib64/libutil.so.1", O_RDONLY) =3D 3
26275 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\16\0(4\=
0\0\0@\0\0\0\0\0\0\0(>\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0\0(4\0\0\0@\0\0(4\0\0\0\370\1\0\0\0\0\0\0\370\1\=
0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340\26\0\0\0\0\0\0\340\26\0(=
4\0\0\0\340\26\0(4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0=
\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0(4\0\0\0\0\0\0(4\0\0\0P\32\0\0\0\=
0\0\0P\32\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\35\0\0\0\0\0\0\3=
40\35 (4\0\0\0\340\35 (4\0\0\0 \3\0\0\0\0\0\0000\3\0\0\0\0\0\0\0\0 \0\0\0=
\0\0\2\0\0\0\6\0\0\0\20\36\0\0\0\0\0\0\20\36 (4\0\0\0\20\36 (4\0\0\0\300\=
1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0=
\0\0\0\0008\2\0(4\0\0\0008\2\0(4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\=
0\0\0\0\0\0P\345td\4\0\0\0\374\26\0\0\0\0\0\0\374\26\0(4\0\0\0\374\26\0(4=
\0\0\0D\0\0\0\0\0\0\0D\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8=
32) =3D 832
26275 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147063, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D40, st_size=3D18152, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2010=
/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:49}) =3D 0
26275 mmap(0x3428000000, 2105616, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3428000000
26275 mprotect(0x3428002000, 2093056, PROT_NONE) =3D 0
26275 mmap(0x3428201000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x1000) =3D 0x3428201000
26275 close(3)                          =3D 0
26275 open("/lib64/libpthread.so.0", O_RDONLY) =3D 3
26275 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240W\240\35=
00\0\0\0@\0\0\0\0\0\0\0\340/\2\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0'\0&\0\6\0=
\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3500\0\0\0@\0\240\3500\0\0\0\370\1\0\0=
\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\240\t\1\0\0\0=
\0\0\240\t\241\3500\0\0\0\240\t\241\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\=
0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3500\0\0=
\0\0\0\240\3500\0\0\0pZ\1\0\0\0\0\0pZ\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\=
6\0\0\0\270[\1\0\0\0\0\0\270[\301\3500\0\0\0\270[\301\3500\0\0\0\230\6\0\=
0\0\0\0\0\270G\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250]\1\0\0\0\0\=
0\250]\301\3500\0\0\0\250]\301\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0=
\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\240\3500\0\0\=
0008\2\240\3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345t=
d\4\0\0\0\274\t\1\0\0\0\0\0\274\t\241\3500\0\0\0\274\t\241\3500\0\0\0\344=
\t\0\0\0\0\0\0\344\t\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =
=3D 832
26275 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147328, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D296, st_size=3D145824, st_atime=3D2012/10/09-11:16:43, st_mtime=3D20=
10/07/28-03:52:41, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26275 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f60ea118000
26275 mmap(0x30e8a00000, 2204528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8a00000
26275 mprotect(0x30e8a16000, 2093056, PROT_NONE) =3D 0
26275 mmap(0x30e8c15000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x15000) =3D 0x30e8c15000
26275 mmap(0x30e8c17000, 13168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8c17000
26275 close(3)                          =3D 0
26275 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26275 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26275 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26275 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26275 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26275 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26275 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26275 close(3)                          =3D 0
26275 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f60ea117000
26275 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f60ea116000
26275 arch_prctl(ARCH_SET_FS, 0x7f60ea1166e0) =3D 0
26275 mprotect(0x3427211000, 4096, PROT_READ) =3D 0
26275 mprotect(0x30ea014000, 4096, PROT_READ) =3D 0
26275 mprotect(0x30e8802000, 4096, PROT_READ) =3D 0
26275 mprotect(0x30e9c81000, 4096, PROT_READ) =3D 0
26275 mprotect(0x3425e08000, 4096, PROT_READ) =3D 0
26275 mprotect(0x3428201000, 4096, PROT_READ) =3D 0
26275 mprotect(0x30e8c15000, 4096, PROT_READ) =3D 0
26275 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26275 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26275 munmap(0x7f60ea11b000, 103979)    =3D 0
26275 set_tid_address(0x7f60ea116770)   =3D 26275
26275 set_robust_list(0x7f60ea116780, 0x18) =3D 0
26275 futex(0x7fff7127d2bc, FUTEX_WAKE_PRIVATE, 1) =3D 0
26275 rt_sigaction(SIGRTMIN, {0x30e8a05380, [], SA_RESTORER|SA_SIGINFO, 0=
x30e8a0eb10}, NULL, 8) =3D 0
26275 rt_sigaction(SIGRT_1, {0x30e8a052b0, [], SA_RESTORER|SA_RESTART|SA_=
SIGINFO, 0x30e8a0eb10}, NULL, 8) =3D 0
26275 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) =3D 0
26275 getrlimit(RLIMIT_STACK, {rlim_cur=3D8192*1024, rlim_max=3DRLIM_INFI=
NITY}) =3D 0
26275 rt_sigaction(SIGFPE, {0x1, [FPE], SA_RESTORER|SA_RESTART, 0x30e8230=
2d0}, {SIG_DFL, [], 0}, 8) =3D 0
26275 brk(0)                            =3D 0x1f94000
26275 brk(0x1fb6000)                    =3D 0x1fb6000
26275 getuid()                          =3D 0
26275 geteuid()                         =3D 0
26275 getgid()                          =3D 0
26275 getegid()                         =3D 0
26275 mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,=
 -1, 0) =3D 0x7f60ea0f5000
26275 open("/dev/urandom", O_RDONLY)    =3D 3
26275 read(3, "\247\203\340\225", 4)    =3D 4
26275 close(3)                          =3D 0
26275 stat("/usr/lib64/perl5/site_perl/5.8.7/x86_64-linux-thread-multi", =
0x7fff7127cf70) =3D -1 ENOENT (No such file or directory)
26275 stat("/usr/lib/perl5/site_perl/5.8.7", 0x7fff7127cf70) =3D -1 ENOEN=
T (No such file or directory)
26275 stat("/usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi", =
0x7fff7127cf70) =3D -1 ENOENT (No such file or directory)
26275 stat("/usr/lib/perl5/site_perl/5.8.6", 0x7fff7127cf70) =3D -1 ENOEN=
T (No such file or directory)
26275 stat("/usr/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi", =
0x7fff7127cf70) =3D -1 ENOENT (No such file or directory)
26275 stat("/usr/lib/perl5/site_perl/5.8.5", 0x7fff7127cf70) =3D -1 ENOEN=
T (No such file or directory)
26275 stat("/usr/lib64/perl5/vendor_perl/5.8.7/x86_64-linux-thread-multi"=
, 0x7fff7127cf70) =3D -1 ENOENT (No such file or directory)
26275 stat("/usr/lib/perl5/vendor_perl/5.8.7", 0x7fff7127cf70) =3D -1 ENO=
ENT (No such file or directory)
26275 stat("/usr/lib64/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi"=
, 0x7fff7127cf70) =3D -1 ENOENT (No such file or directory)
26275 stat("/usr/lib/perl5/vendor_perl/5.8.6", 0x7fff7127cf70) =3D -1 ENO=
ENT (No such file or directory)
26275 stat("/usr/lib64/perl5/vendor_perl/5.8.5/x86_64-linux-thread-multi"=
, 0x7fff7127cf70) =3D -1 ENOENT (No such file or directory)
26275 stat("/usr/lib/perl5/vendor_perl/5.8.5", 0x7fff7127cf70) =3D -1 ENO=
ENT (No such file or directory)
26275 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff7127cd30) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26275 lseek(0, 0, SEEK_CUR)             =3D 0
26275 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff7127cd30) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26275 lseek(1, 0, SEEK_CUR)             =3D -1 ESPIPE (Illegal seek)
26275 ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff7127cd40) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26275 lseek(2, 0, SEEK_CUR)             =3D 593657133
26275 open("/dev/null", O_RDONLY)       =3D 3
26275 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff7127ce40) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26275 lseek(3, 0, SEEK_CUR)             =3D 0
26275 fcntl(3, F_SETFD, FD_CLOEXEC)     =3D 0
26275 fstat(3, {st_dev=3Dmakedev(0, 16), st_ino=3D584, st_mode=3DS_IFCHR|=
0666, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
0, st_rdev=3Dmakedev(1, 3), st_atime=3D2012/10/08-11:13:26, st_mtime=3D20=
12/10/08-11:13:26, st_ctime=3D2012/10/08-11:13:27}) =3D 0
26275 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) =3D 0
26275 readlink("/proc/self/exe", "/usr/bin/perl"..., 4095) =3D 13
26275 brk(0x1fd7000)                    =3D 0x1fd7000
26275 close(3)                          =3D 0
26275 dup(200)                          =3D 3
26275 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff7127cd10) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26275 lseek(3, 0, SEEK_CUR)             =3D 0
26275 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26275 dup2(3, 0)                        =3D 0
26275 close(3)                          =3D 0
26275 fcntl(0, F_SETFD, 0)              =3D 0
26275 fstat(0, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26275 stat("/var/run/xen-hotplug/block", {st_dev=3Dmakedev(8, 2), st_ino=3D=
2801738, st_mode=3DS_IFREG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st=
_blksize=3D4096, st_blocks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:=
24, st_mtime=3D2012/10/09-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D =
0
26275 exit_group(0)                     =3D ?
27813 <... read resumed> "", 128)       =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], WNOHANG, NUL=
L) =3D 26275
27813 wait4(-1, 0x7fffb0100a64, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0)                   =3D 0
27813 close(3)                          =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 write(2, "+ rightfile=3D\n", 13)    =3D 13
27813 write(2, "+ '[' x =3D xy ']'\n", 17) =3D 17
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ true\n", 7)           =3D 7
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ eval 'exec 200>>/var/run/xen-hotplug/block'\n", 46) =3D=
 46
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 write(2, "++ exec\n", 8)          =3D 8
27813 open("/var/run/xen-hotplug/block", O_WRONLY|O_CREAT|O_APPEND, 0666)=
 =3D 3
27813 fcntl(200, F_GETFD)               =3D 0
27813 fcntl(200, F_DUPFD, 10)           =3D 10
27813 fcntl(200, F_GETFD)               =3D 0
27813 dup2(3, 200)                      =3D 200
27813 close(3)                          =3D 0
27813 dup2(10, 200)                     =3D 200
27813 fcntl(10, F_GETFD)                =3D 0
27813 close(10)                         =3D 0
27813 write(2, "+ flock -x 200\n", 15)  =3D 15
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [INT CHLD], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [INT CHLD], NULL, 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26276
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26276 close(255 
27813 rt_sigprocmask(SIG_BLOCK, [CHLD],  
26276 <... close resumed> )             =3D 0
27813 <... rt_sigprocmask resumed> [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [],  
26276 rt_sigprocmask(SIG_SETMASK, [],  
27813 <... rt_sigprocmask resumed> NULL, 8) =3D 0
26276 <... rt_sigprocmask resumed> NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
26276 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0},  
26276 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
27813 <... rt_sigaction resumed> {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}=
, 8) =3D 0
26276 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 wait4(-1,  
26276 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
26276 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26276 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26276 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26276 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26276 execve("/usr/bin/flock", ["flock", "-x", "200"], ["SUBSYSTEM=3Dxen-=
backend", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D=
/usr/bin:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:=
/usr/sbin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dx=
en-backend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3D=
backend/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "S=
HLVL=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/flock"]) =3D 0=

26276 brk(0)                            =3D 0x1b6a000
26276 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fae88652000
26276 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fae88651000
26276 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26276 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26276 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26276 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7fae88637000=

26276 close(3)                          =3D 0
26276 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26276 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26276 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26276 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26276 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26276 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26276 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26276 close(3)                          =3D 0
26276 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fae88636000
26276 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fae88635000
26276 arch_prctl(ARCH_SET_FS, 0x7fae886356e0) =3D 0
26276 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26276 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26276 munmap(0x7fae88637000, 103979)    =3D 0
26276 flock(200, LOCK_EX)               =3D 0
26276 exit_group(0)                     =3D ?
27813 <... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], 0,=
 NULL) =3D 26276
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, 0x7fffb0100a24, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0xffffffffffffffff)  =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 pipe([3, 4])                      =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26277
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {0=
x436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26277 close(255 
27813 close(4 
26277 <... close resumed> )             =3D 0
27813 <... close resumed> )             =3D 0
27813 read(3,  
26277 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26277 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26277 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26277 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26277 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26277 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26277 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26277 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {S=
IG_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26277 rt_sigaction(SIGINT, {0x4481f0, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26277 dup2(4, 1)                        =3D 1
26277 close(4)                          =3D 0
26277 close(3)                          =3D 0
26277 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26277 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26277 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26277 write(2, "++ perl -e '\n            open STDIN, \"<&200\" or die $!=
;\n            my $fd_inum =3D (stat STDIN)[1]; die $! unless defined $fd=
_inum;\n            my $file_inum =3D (stat $ARGV[0])[1];\n            pr=
int \"y\\n\" if $fd_inum eq $file_inum;\n", 230) =3D 230
26277 write(2, "                             ' /var/run/xen-hotplug/block=
\n", 58) =3D 58
26277 stat(".", {st_dev=3Dmakedev(8, 2), st_ino=3D2, st_mode=3DS_IFDIR|07=
55, st_nlink=3D24, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
8, st_size=3D4096, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2012/10/08-=
11:13:38, st_ctime=3D2012/10/08-11:13:38}) =3D 0
26277 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26277 access("/usr/bin/perl", X_OK)     =3D 0
26277 access("/usr/bin/perl", R_OK)     =3D 0
26277 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26277 access("/usr/bin/perl", X_OK)     =3D 0
26277 access("/usr/bin/perl", R_OK)     =3D 0
26277 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
481f0, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26277 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26277 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26277 execve("/usr/bin/perl", ["perl", "-e", "\n            open STDIN, \=
"<&200\" or die $!;\n            my $fd_inum =3D (stat STDIN)[1]; die $! =
unless defined $fd_inum;\n            my $file_inum =3D (stat $ARGV[0])[1=
];\n            print \"y\\n\" if $fd_inum eq $file_inum;\n              =
               ", "/var/run/xen-hotplug/block"], ["SUBSYSTEM=3Dxen-backen=
d", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D/usr/b=
in:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:/usr/s=
bin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dxen-bac=
kend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3Dback=
end/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "SHLVL=
=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/perl"]) =3D 0
26277 brk(0)                            =3D 0x1f39000
26277 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f78e8785000
26277 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f78e8784000
26277 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26277 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64/libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26277 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64", 0x7fffe81dbe70) =3D -1 ENOENT (No such file or directory)
26277 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/lib=
perl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26277 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls", 0=
x7fffe81dbe70) =3D -1 ENOENT (No such file or directory)
26277 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64/=
libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26277 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64"=
, 0x7fffe81dbe70) =3D -1 ENOENT (No such file or directory)
26277 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl=
=2Eso", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26277 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE", 0x7ff=
fe81dbe70) =3D -1 ENOENT (No such file or directory)
26277 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26277 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26277 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7f78e876a000=

26277 close(3)                          =3D 0
26277 open("/usr/lib64/libperl.so", O_RDONLY) =3D 3
26277 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\34\203%=
4\0\0\0@\0\0\0\0\0\0\0\360;\23\0\0\0\0\0\0\0\0\0@\0008\0\5\0@\0\35\0\34\0=
\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\200%4\0\0\0\0\0\200%4\0\0\0T\260\22\=
0\0\0\0\0T\260\22\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0X\260\22\0\0\0\=
0\0X\260\262%4\0\0\0X\260\262%4\0\0\0\250\201\0\0\0\0\0\0\350\242\0\0\0\0=
\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\265\22\0\0\0\0\0\370\265\262%4\0\=
0\0\370\265\262%4\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\=
0\0P\345td\4\0\0\0\250u\21\0\0\0\0\0\250u\221%4\0\0\0\250u\221%4\0\0\0D@\=
0\0\0\0\0\0D@\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\7\4\0\0\360\0\0\0\0\1\0\0\16\0\0\0\0\0\0@\0\200\203\200\225\1\22\=
264\3\31\200l\0\32\0 \5\201\0\240\3\2B\0\200\21R \0\22\0\0\16P\20#\10\216=
\334\30\211\"\0\10 \200\3B\220@\0\1\206\20\30\2\3\21\203$!\312A0\224Y\200=
\27\0\242\26\10\24R@\10\200\220\20A\10\0\220\1\200\206\2\10\304\30i\0\220=
\1\1\202\200\22\20\0\n\1H\0\n\2001J \6\31@L\207\20\10\0000\10(\200\2\0\4\=
251t\"\262\310!\212\240\320\"\0\t"..., 832) =3D 832
26277 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2839671, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D2480, st_size=3D1262384, st_atime=3D2012/10/09-12:04:35, st_mtime=3D=
2012/09/11-12:45:05, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26277 mmap(0x3425800000, 3363648, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425800000
26277 mprotect(0x342592c000, 2093056, PROT_NONE) =3D 0
26277 mmap(0x3425b2b000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x12b000) =3D 0x3425b2b000
26277 mmap(0x3425b34000, 4928, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3425b34000
26277 close(3)                          =3D 0
26277 open("/lib64/libresolv.so.2", O_RDONLY) =3D 3
26277 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\2402\0'4\0\=
0\0@\0\0\0\0\0\0\0@a\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\5\0=
\0\0@\0\0\0\0\0\0\0@\0\0'4\0\0\0@\0\0'4\0\0\0\370\1\0\0\0\0\0\0\370\1\0\0=
\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \361\0\0\0\0\0\0 \361\0'4\0\0\0=
 \361\0'4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\=
0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0'4\0\0\0\0\0\0'4\0\0\0$\10\1\0\0\0\0\0$\10=
\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\24\1\0\0\0\0\0\340\24!'4\=
0\0\0\340\24!'4\0\0\0\340\r\0\0\0\0\0\0\0106\0\0\0\0\0\0\0\0 \0\0\0\0\0\2=
\0\0\0\6\0\0\0\350\35\1\0\0\0\0\0\350\35!'4\0\0\0\350\35!'4\0\0\0\300\1\0=
\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\=
0\0\0008\2\0'4\0\0\0008\2\0'4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0=
\0\0\0\0P\345td\4\0\0\0<\361\0\0\0\0\0\0<\361\0'4\0\0\0<\361\0'4\0\0\0,\3=
\0\0\0\0\0\0,\3\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 8=
32
26277 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148119, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D192, st_size=3D92736, st_atime=3D2012/10/09-11:16:43, st_mtime=3D201=
0/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:42}) =3D 0
26277 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f78e8769000
26277 mmap(0x3427000000, 2181864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3427000000
26277 mprotect(0x3427011000, 2097152, PROT_NONE) =3D 0
26277 mmap(0x3427211000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x11000) =3D 0x3427211000
26277 mmap(0x3427213000, 6888, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3427213000
26277 close(3)                          =3D 0
26277 open("/lib64/libnsl.so.1", O_RDONLY) =3D 3
26277 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240@\340\35=
10\0\0\0@\0\0\0\0\0\0\0\360\265\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0=
\6\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\340\3510\0\0\0@\0\340\3510\0\0\0\370\1=
\0\0\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \33\1\0\0=
\0\0\0 \33\341\3510\0\0\0 \33\341\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\=
0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\340\3510\0\0\0=
\0\0\340\3510\0\0\0\310@\1\0\0\0\0\0\310@\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\=
0\0\6\0\0\0xM\1\0\0\0\0\0xM\1\3520\0\0\0xM\1\3520\0\0\0\310\5\0\0\0\0\0\0=
008-\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250M\1\0\0\0\0\0\250M\1\3=
520\0\0\0\250M\1\3520\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\340\3510\0\0\0008\2\340\351=
0\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0<\33\=
1\0\0\0\0\0<\33\341\3510\0\0\0<\33\341\3510\0\0\0\\\5\0\0\0\0\0\0\\\5\0\0=
\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26277 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147206, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D232, st_size=3D114352, st_atime=3D2012/10/09-12:01:01, st_mtime=3D20=
10/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:44}) =3D 0
26277 mmap(0x30e9e00000, 2194096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9e00000
26277 mprotect(0x30e9e15000, 2093056, PROT_NONE) =3D 0
26277 mmap(0x30ea014000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x14000) =3D 0x30ea014000
26277 mmap(0x30ea016000, 6832, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x30ea016000
26277 close(3)                          =3D 0
26277 open("/lib64/libdl.so.2", O_RDONLY) =3D 3
26277 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\16`\3500=
\0\0\0@\0\0\0\0\0\0\0@R\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0`\3500\0\0\0@\0`\3500\0\0\0\370\1\0\0\0\0\0\0\37=
0\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\300\32\0\0\0\0\0\0\300\3=
2`\3500\0\0\0\300\32`\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0`\3500\0\0\0\0\0`\3500\0\0\=
0\224\37\0\0\0\0\0\0\224\37\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0`-\=
0\0\0\0\0\0`-\200\3500\0\0\0`-\200\3500\0\0\0 \3\0\0\0\0\0\0\240\3\0\0\0\=
0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\240-\0\0\0\0\0\0\240-\200\3500\0\0\0=
\240-\200\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0=
\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2`\3500\0\0\0008\2`\3500\0\0\0 \0\0\=
0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\334\32\0\0\0\0\0\=
0\334\32`\3500\0\0\0\334\32`\3500\0\0\0\264\0\0\0\0\0\0\0\264\0\0\0\0\0\0=
\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26277 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147322, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D48, st_size=3D23360, st_atime=3D2012/10/09-11:13:54, st_mtime=3D2010=
/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26277 mmap(0x30e8600000, 2109696, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8600000
26277 mprotect(0x30e8602000, 2097152, PROT_NONE) =3D 0
26277 mmap(0x30e8802000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x2000) =3D 0x30e8802000
26277 close(3)                          =3D 0
26277 open("/lib64/libm.so.6", O_RDONLY) =3D 3
26277 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`>\240\3510\=
0\0\0@\0\0\0\0\0\0\0\240X\t\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0)\0(\0\6\0\0\=
0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3510\0\0\0@\0\240\3510\0\0\0\370\1\0\0\0\=
0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\360\303\7\0\0\0\=
0\0\360\303\247\3510\0\0\0\360\303\247\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0=
\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3510\=
0\0\0\0\0\240\3510\0\0\0000\22\10\0\0\0\0\0000\22\10\0\0\0\0\0\0\0 \0\0\0=
\0\0\1\0\0\0\6\0\0\0\270\35\10\0\0\0\0\0\270\35\310\3510\0\0\0\270\35\310=
\3510\0\0\0\320\2\0\0\0\0\0\0 \3\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0=
\0\350\35\10\0\0\0\0\0\350\35\310\3510\0\0\0\350\35\310\3510\0\0\0\300\1\=
0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0=
\0\0\0008\2\240\3510\0\0\0008\2\240\3510\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\f\304\7\0\0\0\0\0\f\304\247\3510\0\0\0=
\f\304\247\3510\0\0\0\374\r\0\0\0\0\0\0\374\r\0\0\0\0\0\0\4\0\0\0\0\0\0\0=
Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0"..., 832) =3D 832
26277 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147337, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D1216, st_size=3D615136, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2=
010/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26277 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f78e8768000
26277 mmap(0x30e9a00000, 2629848, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9a00000
26277 mprotect(0x30e9a82000, 2093056, PROT_NONE) =3D 0
26277 mmap(0x30e9c81000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x81000) =3D 0x30e9c81000
26277 close(3)                          =3D 0
26277 open("/lib64/libcrypt.so.1", O_RDONLY) =3D 3
26277 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\t\300%4=
\0\0\0@\0\0\0\0\0\0\0\30\265\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\=
0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\300%4\0\0\0@\0\300%4\0\0\0\370\1\0\0\0\0\=
0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340}\0\0\0\0\0\0\3=
40}\300%4\0\0\0\340}\300%4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\300%4\0\0\0\0\0\300%4\0\0\=
0\4\205\0\0\0\0\0\0\4\205\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\310\=
215\0\0\0\0\0\0\310\215\340%4\0\0\0\310\215\340%4\0\0\0\250\2\0\0\0\0\0\0=
\370\343\2\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\215\0\0\0\0\0\0\3=
70\215\340%4\0\0\0\370\215\340%4\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\=
0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\300%4\0\0\0008\2=
\300%4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0=
\374}\0\0\0\0\0\0\374}\300%4\0\0\0\374}\300%4\0\0\0\34\1\0\0\0\0\0\0\34\1=
\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26277 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148123, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D96, st_size=3D48600, st_atime=3D2012/10/09-12:01:01, st_mtime=3D2010=
/07/28-03:52:39, st_ctime=3D2012/09/11-14:53:52}) =3D 0
26277 mmap(0x3425c00000, 2322880, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425c00000
26277 mprotect(0x3425c09000, 2093056, PROT_NONE) =3D 0
26277 mmap(0x3425e08000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x8000) =3D 0x3425e08000
26277 mmap(0x3425e0a000, 184768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FI=
XED|MAP_ANONYMOUS, -1, 0) =3D 0x3425e0a000
26277 close(3)                          =3D 0
26277 open("/lib64/libutil.so.1", O_RDONLY) =3D 3
26277 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\16\0(4\=
0\0\0@\0\0\0\0\0\0\0(>\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0\0(4\0\0\0@\0\0(4\0\0\0\370\1\0\0\0\0\0\0\370\1\=
0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340\26\0\0\0\0\0\0\340\26\0(=
4\0\0\0\340\26\0(4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0=
\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0(4\0\0\0\0\0\0(4\0\0\0P\32\0\0\0\=
0\0\0P\32\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\35\0\0\0\0\0\0\3=
40\35 (4\0\0\0\340\35 (4\0\0\0 \3\0\0\0\0\0\0000\3\0\0\0\0\0\0\0\0 \0\0\0=
\0\0\2\0\0\0\6\0\0\0\20\36\0\0\0\0\0\0\20\36 (4\0\0\0\20\36 (4\0\0\0\300\=
1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0=
\0\0\0\0008\2\0(4\0\0\0008\2\0(4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\=
0\0\0\0\0\0P\345td\4\0\0\0\374\26\0\0\0\0\0\0\374\26\0(4\0\0\0\374\26\0(4=
\0\0\0D\0\0\0\0\0\0\0D\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8=
32) =3D 832
26277 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147063, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D40, st_size=3D18152, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2010=
/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:49}) =3D 0
26277 mmap(0x3428000000, 2105616, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3428000000
26277 mprotect(0x3428002000, 2093056, PROT_NONE) =3D 0
26277 mmap(0x3428201000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x1000) =3D 0x3428201000
26277 close(3)                          =3D 0
26277 open("/lib64/libpthread.so.0", O_RDONLY) =3D 3
26277 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240W\240\35=
00\0\0\0@\0\0\0\0\0\0\0\340/\2\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0'\0&\0\6\0=
\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3500\0\0\0@\0\240\3500\0\0\0\370\1\0\0=
\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\240\t\1\0\0\0=
\0\0\240\t\241\3500\0\0\0\240\t\241\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\=
0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3500\0\0=
\0\0\0\240\3500\0\0\0pZ\1\0\0\0\0\0pZ\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\=
6\0\0\0\270[\1\0\0\0\0\0\270[\301\3500\0\0\0\270[\301\3500\0\0\0\230\6\0\=
0\0\0\0\0\270G\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250]\1\0\0\0\0\=
0\250]\301\3500\0\0\0\250]\301\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0=
\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\240\3500\0\0\=
0008\2\240\3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345t=
d\4\0\0\0\274\t\1\0\0\0\0\0\274\t\241\3500\0\0\0\274\t\241\3500\0\0\0\344=
\t\0\0\0\0\0\0\344\t\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =
=3D 832
26277 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147328, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D296, st_size=3D145824, st_atime=3D2012/10/09-11:16:43, st_mtime=3D20=
10/07/28-03:52:41, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26277 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f78e8767000
26277 mmap(0x30e8a00000, 2204528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8a00000
26277 mprotect(0x30e8a16000, 2093056, PROT_NONE) =3D 0
26277 mmap(0x30e8c15000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x15000) =3D 0x30e8c15000
26277 mmap(0x30e8c17000, 13168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8c17000
26277 close(3)                          =3D 0
26277 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26277 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26277 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26277 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26277 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26277 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26277 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26277 close(3)                          =3D 0
26277 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f78e8766000
26277 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f78e8765000
26277 arch_prctl(ARCH_SET_FS, 0x7f78e87656e0) =3D 0
26277 mprotect(0x3427211000, 4096, PROT_READ) =3D 0
26277 mprotect(0x30ea014000, 4096, PROT_READ) =3D 0
26277 mprotect(0x30e8802000, 4096, PROT_READ) =3D 0
26277 mprotect(0x30e9c81000, 4096, PROT_READ) =3D 0
26277 mprotect(0x3425e08000, 4096, PROT_READ) =3D 0
26277 mprotect(0x3428201000, 4096, PROT_READ) =3D 0
26277 mprotect(0x30e8c15000, 4096, PROT_READ) =3D 0
26277 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26277 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26277 munmap(0x7f78e876a000, 103979)    =3D 0
26277 set_tid_address(0x7f78e8765770)   =3D 26277
26277 set_robust_list(0x7f78e8765780, 0x18) =3D 0
26277 futex(0x7fffe81dc99c, FUTEX_WAKE_PRIVATE, 1) =3D 0
26277 rt_sigaction(SIGRTMIN, {0x30e8a05380, [], SA_RESTORER|SA_SIGINFO, 0=
x30e8a0eb10}, NULL, 8) =3D 0
26277 rt_sigaction(SIGRT_1, {0x30e8a052b0, [], SA_RESTORER|SA_RESTART|SA_=
SIGINFO, 0x30e8a0eb10}, NULL, 8) =3D 0
26277 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) =3D 0
26277 getrlimit(RLIMIT_STACK, {rlim_cur=3D8192*1024, rlim_max=3DRLIM_INFI=
NITY}) =3D 0
26277 rt_sigaction(SIGFPE, {0x1, [FPE], SA_RESTORER|SA_RESTART, 0x30e8230=
2d0}, {SIG_DFL, [], 0}, 8) =3D 0
26277 brk(0)                            =3D 0x1f39000
26277 brk(0x1f5b000)                    =3D 0x1f5b000
26277 getuid()                          =3D 0
26277 geteuid()                         =3D 0
26277 getgid()                          =3D 0
26277 getegid()                         =3D 0
26277 mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,=
 -1, 0) =3D 0x7f78e8744000
26277 open("/dev/urandom", O_RDONLY)    =3D 3
26277 read(3, "\344\32\254\372", 4)     =3D 4
26277 close(3)                          =3D 0
26277 stat("/usr/lib64/perl5/site_perl/5.8.7/x86_64-linux-thread-multi", =
0x7fffe81dc650) =3D -1 ENOENT (No such file or directory)
26277 stat("/usr/lib/perl5/site_perl/5.8.7", 0x7fffe81dc650) =3D -1 ENOEN=
T (No such file or directory)
26277 stat("/usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi", =
0x7fffe81dc650) =3D -1 ENOENT (No such file or directory)
26277 stat("/usr/lib/perl5/site_perl/5.8.6", 0x7fffe81dc650) =3D -1 ENOEN=
T (No such file or directory)
26277 stat("/usr/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi", =
0x7fffe81dc650) =3D -1 ENOENT (No such file or directory)
26277 stat("/usr/lib/perl5/site_perl/5.8.5", 0x7fffe81dc650) =3D -1 ENOEN=
T (No such file or directory)
26277 stat("/usr/lib64/perl5/vendor_perl/5.8.7/x86_64-linux-thread-multi"=
, 0x7fffe81dc650) =3D -1 ENOENT (No such file or directory)
26277 stat("/usr/lib/perl5/vendor_perl/5.8.7", 0x7fffe81dc650) =3D -1 ENO=
ENT (No such file or directory)
26277 stat("/usr/lib64/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi"=
, 0x7fffe81dc650) =3D -1 ENOENT (No such file or directory)
26277 stat("/usr/lib/perl5/vendor_perl/5.8.6", 0x7fffe81dc650) =3D -1 ENO=
ENT (No such file or directory)
26277 stat("/usr/lib64/perl5/vendor_perl/5.8.5/x86_64-linux-thread-multi"=
, 0x7fffe81dc650) =3D -1 ENOENT (No such file or directory)
26277 stat("/usr/lib/perl5/vendor_perl/5.8.5", 0x7fffe81dc650) =3D -1 ENO=
ENT (No such file or directory)
26277 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffe81dc410) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26277 lseek(0, 0, SEEK_CUR)             =3D 0
26277 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffe81dc410) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26277 lseek(1, 0, SEEK_CUR)             =3D -1 ESPIPE (Illegal seek)
26277 ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffe81dc420) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26277 lseek(2, 0, SEEK_CUR)             =3D 593657527
26277 open("/dev/null", O_RDONLY)       =3D 3
26277 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffe81dc520) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26277 lseek(3, 0, SEEK_CUR)             =3D 0
26277 fcntl(3, F_SETFD, FD_CLOEXEC)     =3D 0
26277 fstat(3, {st_dev=3Dmakedev(0, 16), st_ino=3D584, st_mode=3DS_IFCHR|=
0666, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
0, st_rdev=3Dmakedev(1, 3), st_atime=3D2012/10/08-11:13:26, st_mtime=3D20=
12/10/08-11:13:26, st_ctime=3D2012/10/08-11:13:27}) =3D 0
26277 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) =3D 0
26277 readlink("/proc/self/exe", "/usr/bin/perl"..., 4095) =3D 13
26277 brk(0x1f7c000)                    =3D 0x1f7c000
26277 close(3)                          =3D 0
26277 dup(200)                          =3D 3
26277 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffe81dc3f0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26277 lseek(3, 0, SEEK_CUR)             =3D 0
26277 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26277 dup2(3, 0)                        =3D 0
26277 close(3)                          =3D 0
26277 fcntl(0, F_SETFD, 0)              =3D 0
26277 fstat(0, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26277 stat("/var/run/xen-hotplug/block", {st_dev=3Dmakedev(8, 2), st_ino=3D=
2801738, st_mode=3DS_IFREG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st=
_blksize=3D4096, st_blocks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:=
24, st_mtime=3D2012/10/09-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D =
0
26277 exit_group(0)                     =3D ?
27813 <... read resumed> "", 128)       =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], WNOHANG, NUL=
L) =3D 26277
27813 wait4(-1, 0x7fffb0100a64, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0)                   =3D 0
27813 close(3)                          =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 write(2, "+ rightfile=3D\n", 13)    =3D 13
27813 write(2, "+ '[' x =3D xy ']'\n", 17) =3D 17
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ true\n", 7)           =3D 7
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ eval 'exec 200>>/var/run/xen-hotplug/block'\n", 46) =3D=
 46
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 write(2, "++ exec\n", 8)          =3D 8
27813 open("/var/run/xen-hotplug/block", O_WRONLY|O_CREAT|O_APPEND, 0666)=
 =3D 3
27813 fcntl(200, F_GETFD)               =3D 0
27813 fcntl(200, F_DUPFD, 10)           =3D 10
27813 fcntl(200, F_GETFD)               =3D 0
27813 dup2(3, 200)                      =3D 200
27813 close(3)                          =3D 0
27813 dup2(10, 200)                     =3D 200
27813 fcntl(10, F_GETFD)                =3D 0
27813 close(10)                         =3D 0
27813 write(2, "+ flock -x 200\n", 15)  =3D 15
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [INT CHLD], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [INT CHLD], NULL, 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26278
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26278 close(255 
27813 rt_sigprocmask(SIG_BLOCK, [CHLD],  
26278 <... close resumed> )             =3D 0
27813 <... rt_sigprocmask resumed> [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [],  
26278 rt_sigprocmask(SIG_SETMASK, [],  
27813 <... rt_sigprocmask resumed> NULL, 8) =3D 0
26278 <... rt_sigprocmask resumed> NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
26278 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0},  
26278 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
27813 <... rt_sigaction resumed> {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}=
, 8) =3D 0
26278 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 wait4(-1,  
26278 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
26278 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26278 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26278 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26278 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26278 execve("/usr/bin/flock", ["flock", "-x", "200"], ["SUBSYSTEM=3Dxen-=
backend", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D=
/usr/bin:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:=
/usr/sbin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dx=
en-backend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3D=
backend/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "S=
HLVL=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/flock"]) =3D 0=

26278 brk(0)                            =3D 0x119d000
26278 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f0519d76000
26278 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f0519d75000
26278 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26278 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26278 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26278 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7f0519d5b000=

26278 close(3)                          =3D 0
26278 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26278 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26278 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26278 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26278 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26278 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26278 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26278 close(3)                          =3D 0
26278 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f0519d5a000
26278 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f0519d59000
26278 arch_prctl(ARCH_SET_FS, 0x7f0519d596e0) =3D 0
26278 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26278 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26278 munmap(0x7f0519d5b000, 103979)    =3D 0
26278 flock(200, LOCK_EX)               =3D 0
26278 exit_group(0)                     =3D ?
27813 <... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], 0,=
 NULL) =3D 26278
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, 0x7fffb0100a24, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0xffffffffffffffff)  =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 pipe([3, 4])                      =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26279
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {0=
x436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26279 close(255 
27813 close(4 
26279 <... close resumed> )             =3D 0
27813 <... close resumed> )             =3D 0
27813 read(3,  
26279 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26279 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26279 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26279 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26279 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26279 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26279 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26279 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {S=
IG_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26279 rt_sigaction(SIGINT, {0x4481f0, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26279 dup2(4, 1)                        =3D 1
26279 close(4)                          =3D 0
26279 close(3)                          =3D 0
26279 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26279 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26279 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26279 write(2, "++ perl -e '\n            open STDIN, \"<&200\" or die $!=
;\n            my $fd_inum =3D (stat STDIN)[1]; die $! unless defined $fd=
_inum;\n            my $file_inum =3D (stat $ARGV[0])[1];\n            pr=
int \"y\\n\" if $fd_inum eq $file_inum;\n", 230) =3D 230
26279 write(2, "                             ' /var/run/xen-hotplug/block=
\n", 58) =3D 58
26279 stat(".", {st_dev=3Dmakedev(8, 2), st_ino=3D2, st_mode=3DS_IFDIR|07=
55, st_nlink=3D24, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
8, st_size=3D4096, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2012/10/08-=
11:13:38, st_ctime=3D2012/10/08-11:13:38}) =3D 0
26279 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26279 access("/usr/bin/perl", X_OK)     =3D 0
26279 access("/usr/bin/perl", R_OK)     =3D 0
26279 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26279 access("/usr/bin/perl", X_OK)     =3D 0
26279 access("/usr/bin/perl", R_OK)     =3D 0
26279 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
481f0, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26279 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26279 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26279 execve("/usr/bin/perl", ["perl", "-e", "\n            open STDIN, \=
"<&200\" or die $!;\n            my $fd_inum =3D (stat STDIN)[1]; die $! =
unless defined $fd_inum;\n            my $file_inum =3D (stat $ARGV[0])[1=
];\n            print \"y\\n\" if $fd_inum eq $file_inum;\n              =
               ", "/var/run/xen-hotplug/block"], ["SUBSYSTEM=3Dxen-backen=
d", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D/usr/b=
in:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:/usr/s=
bin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dxen-bac=
kend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3Dback=
end/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "SHLVL=
=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/perl"]) =3D 0
26279 brk(0)                            =3D 0x1d51000
26279 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f5d16cfe000
26279 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f5d16cfd000
26279 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26279 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64/libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26279 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64", 0x7fffeaa9f0e0) =3D -1 ENOENT (No such file or directory)
26279 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/lib=
perl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26279 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls", 0=
x7fffeaa9f0e0) =3D -1 ENOENT (No such file or directory)
26279 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64/=
libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26279 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64"=
, 0x7fffeaa9f0e0) =3D -1 ENOENT (No such file or directory)
26279 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl=
=2Eso", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26279 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE", 0x7ff=
feaa9f0e0) =3D -1 ENOENT (No such file or directory)
26279 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26279 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26279 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7f5d16ce3000=

26279 close(3)                          =3D 0
26279 open("/usr/lib64/libperl.so", O_RDONLY) =3D 3
26279 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\34\203%=
4\0\0\0@\0\0\0\0\0\0\0\360;\23\0\0\0\0\0\0\0\0\0@\0008\0\5\0@\0\35\0\34\0=
\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\200%4\0\0\0\0\0\200%4\0\0\0T\260\22\=
0\0\0\0\0T\260\22\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0X\260\22\0\0\0\=
0\0X\260\262%4\0\0\0X\260\262%4\0\0\0\250\201\0\0\0\0\0\0\350\242\0\0\0\0=
\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\265\22\0\0\0\0\0\370\265\262%4\0\=
0\0\370\265\262%4\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\=
0\0P\345td\4\0\0\0\250u\21\0\0\0\0\0\250u\221%4\0\0\0\250u\221%4\0\0\0D@\=
0\0\0\0\0\0D@\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\7\4\0\0\360\0\0\0\0\1\0\0\16\0\0\0\0\0\0@\0\200\203\200\225\1\22\=
264\3\31\200l\0\32\0 \5\201\0\240\3\2B\0\200\21R \0\22\0\0\16P\20#\10\216=
\334\30\211\"\0\10 \200\3B\220@\0\1\206\20\30\2\3\21\203$!\312A0\224Y\200=
\27\0\242\26\10\24R@\10\200\220\20A\10\0\220\1\200\206\2\10\304\30i\0\220=
\1\1\202\200\22\20\0\n\1H\0\n\2001J \6\31@L\207\20\10\0000\10(\200\2\0\4\=
251t\"\262\310!\212\240\320\"\0\t"..., 832) =3D 832
26279 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2839671, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D2480, st_size=3D1262384, st_atime=3D2012/10/09-12:04:35, st_mtime=3D=
2012/09/11-12:45:05, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26279 mmap(0x3425800000, 3363648, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425800000
26279 mprotect(0x342592c000, 2093056, PROT_NONE) =3D 0
26279 mmap(0x3425b2b000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x12b000) =3D 0x3425b2b000
26279 mmap(0x3425b34000, 4928, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3425b34000
26279 close(3)                          =3D 0
26279 open("/lib64/libresolv.so.2", O_RDONLY) =3D 3
26279 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\2402\0'4\0\=
0\0@\0\0\0\0\0\0\0@a\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\5\0=
\0\0@\0\0\0\0\0\0\0@\0\0'4\0\0\0@\0\0'4\0\0\0\370\1\0\0\0\0\0\0\370\1\0\0=
\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \361\0\0\0\0\0\0 \361\0'4\0\0\0=
 \361\0'4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\=
0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0'4\0\0\0\0\0\0'4\0\0\0$\10\1\0\0\0\0\0$\10=
\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\24\1\0\0\0\0\0\340\24!'4\=
0\0\0\340\24!'4\0\0\0\340\r\0\0\0\0\0\0\0106\0\0\0\0\0\0\0\0 \0\0\0\0\0\2=
\0\0\0\6\0\0\0\350\35\1\0\0\0\0\0\350\35!'4\0\0\0\350\35!'4\0\0\0\300\1\0=
\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\=
0\0\0008\2\0'4\0\0\0008\2\0'4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0=
\0\0\0\0P\345td\4\0\0\0<\361\0\0\0\0\0\0<\361\0'4\0\0\0<\361\0'4\0\0\0,\3=
\0\0\0\0\0\0,\3\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 8=
32
26279 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148119, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D192, st_size=3D92736, st_atime=3D2012/10/09-11:16:43, st_mtime=3D201=
0/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:42}) =3D 0
26279 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f5d16ce2000
26279 mmap(0x3427000000, 2181864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3427000000
26279 mprotect(0x3427011000, 2097152, PROT_NONE) =3D 0
26279 mmap(0x3427211000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x11000) =3D 0x3427211000
26279 mmap(0x3427213000, 6888, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3427213000
26279 close(3)                          =3D 0
26279 open("/lib64/libnsl.so.1", O_RDONLY) =3D 3
26279 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240@\340\35=
10\0\0\0@\0\0\0\0\0\0\0\360\265\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0=
\6\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\340\3510\0\0\0@\0\340\3510\0\0\0\370\1=
\0\0\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \33\1\0\0=
\0\0\0 \33\341\3510\0\0\0 \33\341\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\=
0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\340\3510\0\0\0=
\0\0\340\3510\0\0\0\310@\1\0\0\0\0\0\310@\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\=
0\0\6\0\0\0xM\1\0\0\0\0\0xM\1\3520\0\0\0xM\1\3520\0\0\0\310\5\0\0\0\0\0\0=
008-\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250M\1\0\0\0\0\0\250M\1\3=
520\0\0\0\250M\1\3520\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\340\3510\0\0\0008\2\340\351=
0\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0<\33\=
1\0\0\0\0\0<\33\341\3510\0\0\0<\33\341\3510\0\0\0\\\5\0\0\0\0\0\0\\\5\0\0=
\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26279 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147206, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D232, st_size=3D114352, st_atime=3D2012/10/09-12:01:01, st_mtime=3D20=
10/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:44}) =3D 0
26279 mmap(0x30e9e00000, 2194096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9e00000
26279 mprotect(0x30e9e15000, 2093056, PROT_NONE) =3D 0
26279 mmap(0x30ea014000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x14000) =3D 0x30ea014000
26279 mmap(0x30ea016000, 6832, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x30ea016000
26279 close(3)                          =3D 0
26279 open("/lib64/libdl.so.2", O_RDONLY) =3D 3
26279 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\16`\3500=
\0\0\0@\0\0\0\0\0\0\0@R\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0`\3500\0\0\0@\0`\3500\0\0\0\370\1\0\0\0\0\0\0\37=
0\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\300\32\0\0\0\0\0\0\300\3=
2`\3500\0\0\0\300\32`\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0`\3500\0\0\0\0\0`\3500\0\0\=
0\224\37\0\0\0\0\0\0\224\37\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0`-\=
0\0\0\0\0\0`-\200\3500\0\0\0`-\200\3500\0\0\0 \3\0\0\0\0\0\0\240\3\0\0\0\=
0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\240-\0\0\0\0\0\0\240-\200\3500\0\0\0=
\240-\200\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0=
\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2`\3500\0\0\0008\2`\3500\0\0\0 \0\0\=
0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\334\32\0\0\0\0\0\=
0\334\32`\3500\0\0\0\334\32`\3500\0\0\0\264\0\0\0\0\0\0\0\264\0\0\0\0\0\0=
\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26279 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147322, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D48, st_size=3D23360, st_atime=3D2012/10/09-11:13:54, st_mtime=3D2010=
/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26279 mmap(0x30e8600000, 2109696, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8600000
26279 mprotect(0x30e8602000, 2097152, PROT_NONE) =3D 0
26279 mmap(0x30e8802000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x2000) =3D 0x30e8802000
26279 close(3)                          =3D 0
26279 open("/lib64/libm.so.6", O_RDONLY) =3D 3
26279 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`>\240\3510\=
0\0\0@\0\0\0\0\0\0\0\240X\t\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0)\0(\0\6\0\0\=
0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3510\0\0\0@\0\240\3510\0\0\0\370\1\0\0\0\=
0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\360\303\7\0\0\0\=
0\0\360\303\247\3510\0\0\0\360\303\247\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0=
\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3510\=
0\0\0\0\0\240\3510\0\0\0000\22\10\0\0\0\0\0000\22\10\0\0\0\0\0\0\0 \0\0\0=
\0\0\1\0\0\0\6\0\0\0\270\35\10\0\0\0\0\0\270\35\310\3510\0\0\0\270\35\310=
\3510\0\0\0\320\2\0\0\0\0\0\0 \3\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0=
\0\350\35\10\0\0\0\0\0\350\35\310\3510\0\0\0\350\35\310\3510\0\0\0\300\1\=
0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0=
\0\0\0008\2\240\3510\0\0\0008\2\240\3510\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\f\304\7\0\0\0\0\0\f\304\247\3510\0\0\0=
\f\304\247\3510\0\0\0\374\r\0\0\0\0\0\0\374\r\0\0\0\0\0\0\4\0\0\0\0\0\0\0=
Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0"..., 832) =3D 832
26279 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147337, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D1216, st_size=3D615136, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2=
010/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26279 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f5d16ce1000
26279 mmap(0x30e9a00000, 2629848, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9a00000
26279 mprotect(0x30e9a82000, 2093056, PROT_NONE) =3D 0
26279 mmap(0x30e9c81000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x81000) =3D 0x30e9c81000
26279 close(3)                          =3D 0
26279 open("/lib64/libcrypt.so.1", O_RDONLY) =3D 3
26279 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\t\300%4=
\0\0\0@\0\0\0\0\0\0\0\30\265\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\=
0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\300%4\0\0\0@\0\300%4\0\0\0\370\1\0\0\0\0\=
0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340}\0\0\0\0\0\0\3=
40}\300%4\0\0\0\340}\300%4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\300%4\0\0\0\0\0\300%4\0\0\=
0\4\205\0\0\0\0\0\0\4\205\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\310\=
215\0\0\0\0\0\0\310\215\340%4\0\0\0\310\215\340%4\0\0\0\250\2\0\0\0\0\0\0=
\370\343\2\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\215\0\0\0\0\0\0\3=
70\215\340%4\0\0\0\370\215\340%4\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\=
0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\300%4\0\0\0008\2=
\300%4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0=
\374}\0\0\0\0\0\0\374}\300%4\0\0\0\374}\300%4\0\0\0\34\1\0\0\0\0\0\0\34\1=
\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26279 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148123, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D96, st_size=3D48600, st_atime=3D2012/10/09-12:01:01, st_mtime=3D2010=
/07/28-03:52:39, st_ctime=3D2012/09/11-14:53:52}) =3D 0
26279 mmap(0x3425c00000, 2322880, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425c00000
26279 mprotect(0x3425c09000, 2093056, PROT_NONE) =3D 0
26279 mmap(0x3425e08000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x8000) =3D 0x3425e08000
26279 mmap(0x3425e0a000, 184768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FI=
XED|MAP_ANONYMOUS, -1, 0) =3D 0x3425e0a000
26279 close(3)                          =3D 0
26279 open("/lib64/libutil.so.1", O_RDONLY) =3D 3
26279 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\16\0(4\=
0\0\0@\0\0\0\0\0\0\0(>\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0\0(4\0\0\0@\0\0(4\0\0\0\370\1\0\0\0\0\0\0\370\1\=
0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340\26\0\0\0\0\0\0\340\26\0(=
4\0\0\0\340\26\0(4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0=
\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0(4\0\0\0\0\0\0(4\0\0\0P\32\0\0\0\=
0\0\0P\32\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\35\0\0\0\0\0\0\3=
40\35 (4\0\0\0\340\35 (4\0\0\0 \3\0\0\0\0\0\0000\3\0\0\0\0\0\0\0\0 \0\0\0=
\0\0\2\0\0\0\6\0\0\0\20\36\0\0\0\0\0\0\20\36 (4\0\0\0\20\36 (4\0\0\0\300\=
1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0=
\0\0\0\0008\2\0(4\0\0\0008\2\0(4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\=
0\0\0\0\0\0P\345td\4\0\0\0\374\26\0\0\0\0\0\0\374\26\0(4\0\0\0\374\26\0(4=
\0\0\0D\0\0\0\0\0\0\0D\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8=
32) =3D 832
26279 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147063, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D40, st_size=3D18152, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2010=
/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:49}) =3D 0
26279 mmap(0x3428000000, 2105616, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3428000000
26279 mprotect(0x3428002000, 2093056, PROT_NONE) =3D 0
26279 mmap(0x3428201000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x1000) =3D 0x3428201000
26279 close(3)                          =3D 0
26279 open("/lib64/libpthread.so.0", O_RDONLY) =3D 3
26279 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240W\240\35=
00\0\0\0@\0\0\0\0\0\0\0\340/\2\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0'\0&\0\6\0=
\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3500\0\0\0@\0\240\3500\0\0\0\370\1\0\0=
\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\240\t\1\0\0\0=
\0\0\240\t\241\3500\0\0\0\240\t\241\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\=
0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3500\0\0=
\0\0\0\240\3500\0\0\0pZ\1\0\0\0\0\0pZ\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\=
6\0\0\0\270[\1\0\0\0\0\0\270[\301\3500\0\0\0\270[\301\3500\0\0\0\230\6\0\=
0\0\0\0\0\270G\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250]\1\0\0\0\0\=
0\250]\301\3500\0\0\0\250]\301\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0=
\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\240\3500\0\0\=
0008\2\240\3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345t=
d\4\0\0\0\274\t\1\0\0\0\0\0\274\t\241\3500\0\0\0\274\t\241\3500\0\0\0\344=
\t\0\0\0\0\0\0\344\t\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =
=3D 832
26279 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147328, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D296, st_size=3D145824, st_atime=3D2012/10/09-11:16:43, st_mtime=3D20=
10/07/28-03:52:41, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26279 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f5d16ce0000
26279 mmap(0x30e8a00000, 2204528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8a00000
26279 mprotect(0x30e8a16000, 2093056, PROT_NONE) =3D 0
26279 mmap(0x30e8c15000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x15000) =3D 0x30e8c15000
26279 mmap(0x30e8c17000, 13168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8c17000
26279 close(3)                          =3D 0
26279 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26279 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26279 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26279 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26279 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26279 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26279 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26279 close(3)                          =3D 0
26279 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f5d16cdf000
26279 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f5d16cde000
26279 arch_prctl(ARCH_SET_FS, 0x7f5d16cde6e0) =3D 0
26279 mprotect(0x3427211000, 4096, PROT_READ) =3D 0
26279 mprotect(0x30ea014000, 4096, PROT_READ) =3D 0
26279 mprotect(0x30e8802000, 4096, PROT_READ) =3D 0
26279 mprotect(0x30e9c81000, 4096, PROT_READ) =3D 0
26279 mprotect(0x3425e08000, 4096, PROT_READ) =3D 0
26279 mprotect(0x3428201000, 4096, PROT_READ) =3D 0
26279 mprotect(0x30e8c15000, 4096, PROT_READ) =3D 0
26279 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26279 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26279 munmap(0x7f5d16ce3000, 103979)    =3D 0
26279 set_tid_address(0x7f5d16cde770)   =3D 26279
26279 set_robust_list(0x7f5d16cde780, 0x18) =3D 0
26279 futex(0x7fffeaa9fc0c, FUTEX_WAKE_PRIVATE, 1) =3D 0
26279 rt_sigaction(SIGRTMIN, {0x30e8a05380, [], SA_RESTORER|SA_SIGINFO, 0=
x30e8a0eb10}, NULL, 8) =3D 0
26279 rt_sigaction(SIGRT_1, {0x30e8a052b0, [], SA_RESTORER|SA_RESTART|SA_=
SIGINFO, 0x30e8a0eb10}, NULL, 8) =3D 0
26279 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) =3D 0
26279 getrlimit(RLIMIT_STACK, {rlim_cur=3D8192*1024, rlim_max=3DRLIM_INFI=
NITY}) =3D 0
26279 rt_sigaction(SIGFPE, {0x1, [FPE], SA_RESTORER|SA_RESTART, 0x30e8230=
2d0}, {SIG_DFL, [], 0}, 8) =3D 0
26279 brk(0)                            =3D 0x1d51000
26279 brk(0x1d73000)                    =3D 0x1d73000
26279 getuid()                          =3D 0
26279 geteuid()                         =3D 0
26279 getgid()                          =3D 0
26279 getegid()                         =3D 0
26279 mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,=
 -1, 0) =3D 0x7f5d16cbd000
26279 open("/dev/urandom", O_RDONLY)    =3D 3
26279 read(3, "<\377\35_", 4)           =3D 4
26279 close(3)                          =3D 0
26279 stat("/usr/lib64/perl5/site_perl/5.8.7/x86_64-linux-thread-multi", =
0x7fffeaa9f8c0) =3D -1 ENOENT (No such file or directory)
26279 stat("/usr/lib/perl5/site_perl/5.8.7", 0x7fffeaa9f8c0) =3D -1 ENOEN=
T (No such file or directory)
26279 stat("/usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi", =
0x7fffeaa9f8c0) =3D -1 ENOENT (No such file or directory)
26279 stat("/usr/lib/perl5/site_perl/5.8.6", 0x7fffeaa9f8c0) =3D -1 ENOEN=
T (No such file or directory)
26279 stat("/usr/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi", =
0x7fffeaa9f8c0) =3D -1 ENOENT (No such file or directory)
26279 stat("/usr/lib/perl5/site_perl/5.8.5", 0x7fffeaa9f8c0) =3D -1 ENOEN=
T (No such file or directory)
26279 stat("/usr/lib64/perl5/vendor_perl/5.8.7/x86_64-linux-thread-multi"=
, 0x7fffeaa9f8c0) =3D -1 ENOENT (No such file or directory)
26279 stat("/usr/lib/perl5/vendor_perl/5.8.7", 0x7fffeaa9f8c0) =3D -1 ENO=
ENT (No such file or directory)
26279 stat("/usr/lib64/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi"=
, 0x7fffeaa9f8c0) =3D -1 ENOENT (No such file or directory)
26279 stat("/usr/lib/perl5/vendor_perl/5.8.6", 0x7fffeaa9f8c0) =3D -1 ENO=
ENT (No such file or directory)
26279 stat("/usr/lib64/perl5/vendor_perl/5.8.5/x86_64-linux-thread-multi"=
, 0x7fffeaa9f8c0) =3D -1 ENOENT (No such file or directory)
26279 stat("/usr/lib/perl5/vendor_perl/5.8.5", 0x7fffeaa9f8c0) =3D -1 ENO=
ENT (No such file or directory)
26279 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffeaa9f680) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26279 lseek(0, 0, SEEK_CUR)             =3D 0
26279 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffeaa9f680) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26279 lseek(1, 0, SEEK_CUR)             =3D -1 ESPIPE (Illegal seek)
26279 ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffeaa9f690) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26279 lseek(2, 0, SEEK_CUR)             =3D 593657921
26279 open("/dev/null", O_RDONLY)       =3D 3
26279 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffeaa9f790) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26279 lseek(3, 0, SEEK_CUR)             =3D 0
26279 fcntl(3, F_SETFD, FD_CLOEXEC)     =3D 0
26279 fstat(3, {st_dev=3Dmakedev(0, 16), st_ino=3D584, st_mode=3DS_IFCHR|=
0666, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
0, st_rdev=3Dmakedev(1, 3), st_atime=3D2012/10/08-11:13:26, st_mtime=3D20=
12/10/08-11:13:26, st_ctime=3D2012/10/08-11:13:27}) =3D 0
26279 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) =3D 0
26279 readlink("/proc/self/exe", "/usr/bin/perl"..., 4095) =3D 13
26279 brk(0x1d94000)                    =3D 0x1d94000
26279 close(3)                          =3D 0
26279 dup(200)                          =3D 3
26279 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffeaa9f660) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26279 lseek(3, 0, SEEK_CUR)             =3D 0
26279 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26279 dup2(3, 0)                        =3D 0
26279 close(3)                          =3D 0
26279 fcntl(0, F_SETFD, 0)              =3D 0
26279 fstat(0, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26279 stat("/var/run/xen-hotplug/block", {st_dev=3Dmakedev(8, 2), st_ino=3D=
2801738, st_mode=3DS_IFREG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st=
_blksize=3D4096, st_blocks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:=
24, st_mtime=3D2012/10/09-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D =
0
26279 exit_group(0)                     =3D ?
27813 <... read resumed> "", 128)       =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], WNOHANG, NUL=
L) =3D 26279
27813 wait4(-1, 0x7fffb0100a64, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0)                   =3D 0
27813 close(3)                          =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 write(2, "+ rightfile=3D\n", 13)    =3D 13
27813 write(2, "+ '[' x =3D xy ']'\n", 17) =3D 17
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ true\n", 7)           =3D 7
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ eval 'exec 200>>/var/run/xen-hotplug/block'\n", 46) =3D=
 46
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 write(2, "++ exec\n", 8)          =3D 8
27813 open("/var/run/xen-hotplug/block", O_WRONLY|O_CREAT|O_APPEND, 0666)=
 =3D 3
27813 fcntl(200, F_GETFD)               =3D 0
27813 fcntl(200, F_DUPFD, 10)           =3D 10
27813 fcntl(200, F_GETFD)               =3D 0
27813 dup2(3, 200)                      =3D 200
27813 close(3)                          =3D 0
27813 dup2(10, 200)                     =3D 200
27813 fcntl(10, F_GETFD)                =3D 0
27813 close(10)                         =3D 0
27813 write(2, "+ flock -x 200\n", 15)  =3D 15
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [INT CHLD], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [INT CHLD], NULL, 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26280
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26280 close(255 
27813 rt_sigprocmask(SIG_BLOCK, [CHLD],  
26280 <... close resumed> )             =3D 0
27813 <... rt_sigprocmask resumed> [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [],  
26280 rt_sigprocmask(SIG_SETMASK, [],  
27813 <... rt_sigprocmask resumed> NULL, 8) =3D 0
26280 <... rt_sigprocmask resumed> NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
26280 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0},  
26280 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
27813 <... rt_sigaction resumed> {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}=
, 8) =3D 0
26280 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 wait4(-1,  
26280 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
26280 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26280 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26280 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26280 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26280 execve("/usr/bin/flock", ["flock", "-x", "200"], ["SUBSYSTEM=3Dxen-=
backend", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D=
/usr/bin:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:=
/usr/sbin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dx=
en-backend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3D=
backend/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "S=
HLVL=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/flock"]) =3D 0=

26280 brk(0)                            =3D 0x1b9e000
26280 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f73852d4000
26280 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f73852d3000
26280 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26280 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26280 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26280 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7f73852b9000=

26280 close(3)                          =3D 0
26280 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26280 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26280 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26280 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26280 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26280 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26280 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26280 close(3)                          =3D 0
26280 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f73852b8000
26280 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f73852b7000
26280 arch_prctl(ARCH_SET_FS, 0x7f73852b76e0) =3D 0
26280 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26280 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26280 munmap(0x7f73852b9000, 103979)    =3D 0
26280 flock(200, LOCK_EX)               =3D 0
26280 exit_group(0)                     =3D ?
27813 <... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], 0,=
 NULL) =3D 26280
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, 0x7fffb0100a24, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0xffffffffffffffff)  =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 pipe([3, 4])                      =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26281
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {0=
x436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26281 close(255 
27813 close(4 
26281 <... close resumed> )             =3D 0
27813 <... close resumed> )             =3D 0
27813 read(3,  
26281 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26281 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26281 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26281 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26281 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26281 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26281 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26281 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {S=
IG_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26281 rt_sigaction(SIGINT, {0x4481f0, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26281 dup2(4, 1)                        =3D 1
26281 close(4)                          =3D 0
26281 close(3)                          =3D 0
26281 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26281 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26281 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26281 write(2, "++ perl -e '\n            open STDIN, \"<&200\" or die $!=
;\n            my $fd_inum =3D (stat STDIN)[1]; die $! unless defined $fd=
_inum;\n            my $file_inum =3D (stat $ARGV[0])[1];\n            pr=
int \"y\\n\" if $fd_inum eq $file_inum;\n", 230) =3D 230
26281 write(2, "                             ' /var/run/xen-hotplug/block=
\n", 58) =3D 58
26281 stat(".", {st_dev=3Dmakedev(8, 2), st_ino=3D2, st_mode=3DS_IFDIR|07=
55, st_nlink=3D24, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
8, st_size=3D4096, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2012/10/08-=
11:13:38, st_ctime=3D2012/10/08-11:13:38}) =3D 0
26281 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26281 access("/usr/bin/perl", X_OK)     =3D 0
26281 access("/usr/bin/perl", R_OK)     =3D 0
26281 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26281 access("/usr/bin/perl", X_OK)     =3D 0
26281 access("/usr/bin/perl", R_OK)     =3D 0
26281 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
481f0, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26281 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26281 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26281 execve("/usr/bin/perl", ["perl", "-e", "\n            open STDIN, \=
"<&200\" or die $!;\n            my $fd_inum =3D (stat STDIN)[1]; die $! =
unless defined $fd_inum;\n            my $file_inum =3D (stat $ARGV[0])[1=
];\n            print \"y\\n\" if $fd_inum eq $file_inum;\n              =
               ", "/var/run/xen-hotplug/block"], ["SUBSYSTEM=3Dxen-backen=
d", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D/usr/b=
in:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:/usr/s=
bin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dxen-bac=
kend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3Dback=
end/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "SHLVL=
=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/perl"]) =3D 0
26281 brk(0)                            =3D 0x2557000
26281 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f7035a3e000
26281 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f7035a3d000
26281 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26281 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64/libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26281 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64", 0x7fffb80966e0) =3D -1 ENOENT (No such file or directory)
26281 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/lib=
perl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26281 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls", 0=
x7fffb80966e0) =3D -1 ENOENT (No such file or directory)
26281 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64/=
libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26281 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64"=
, 0x7fffb80966e0) =3D -1 ENOENT (No such file or directory)
26281 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl=
=2Eso", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26281 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE", 0x7ff=
fb80966e0) =3D -1 ENOENT (No such file or directory)
26281 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26281 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26281 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7f7035a23000=

26281 close(3)                          =3D 0
26281 open("/usr/lib64/libperl.so", O_RDONLY) =3D 3
26281 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\34\203%=
4\0\0\0@\0\0\0\0\0\0\0\360;\23\0\0\0\0\0\0\0\0\0@\0008\0\5\0@\0\35\0\34\0=
\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\200%4\0\0\0\0\0\200%4\0\0\0T\260\22\=
0\0\0\0\0T\260\22\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0X\260\22\0\0\0\=
0\0X\260\262%4\0\0\0X\260\262%4\0\0\0\250\201\0\0\0\0\0\0\350\242\0\0\0\0=
\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\265\22\0\0\0\0\0\370\265\262%4\0\=
0\0\370\265\262%4\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\=
0\0P\345td\4\0\0\0\250u\21\0\0\0\0\0\250u\221%4\0\0\0\250u\221%4\0\0\0D@\=
0\0\0\0\0\0D@\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\7\4\0\0\360\0\0\0\0\1\0\0\16\0\0\0\0\0\0@\0\200\203\200\225\1\22\=
264\3\31\200l\0\32\0 \5\201\0\240\3\2B\0\200\21R \0\22\0\0\16P\20#\10\216=
\334\30\211\"\0\10 \200\3B\220@\0\1\206\20\30\2\3\21\203$!\312A0\224Y\200=
\27\0\242\26\10\24R@\10\200\220\20A\10\0\220\1\200\206\2\10\304\30i\0\220=
\1\1\202\200\22\20\0\n\1H\0\n\2001J \6\31@L\207\20\10\0000\10(\200\2\0\4\=
251t\"\262\310!\212\240\320\"\0\t"..., 832) =3D 832
26281 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2839671, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D2480, st_size=3D1262384, st_atime=3D2012/10/09-12:04:35, st_mtime=3D=
2012/09/11-12:45:05, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26281 mmap(0x3425800000, 3363648, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425800000
26281 mprotect(0x342592c000, 2093056, PROT_NONE) =3D 0
26281 mmap(0x3425b2b000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x12b000) =3D 0x3425b2b000
26281 mmap(0x3425b34000, 4928, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3425b34000
26281 close(3)                          =3D 0
26281 open("/lib64/libresolv.so.2", O_RDONLY) =3D 3
26281 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\2402\0'4\0\=
0\0@\0\0\0\0\0\0\0@a\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\5\0=
\0\0@\0\0\0\0\0\0\0@\0\0'4\0\0\0@\0\0'4\0\0\0\370\1\0\0\0\0\0\0\370\1\0\0=
\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \361\0\0\0\0\0\0 \361\0'4\0\0\0=
 \361\0'4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\=
0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0'4\0\0\0\0\0\0'4\0\0\0$\10\1\0\0\0\0\0$\10=
\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\24\1\0\0\0\0\0\340\24!'4\=
0\0\0\340\24!'4\0\0\0\340\r\0\0\0\0\0\0\0106\0\0\0\0\0\0\0\0 \0\0\0\0\0\2=
\0\0\0\6\0\0\0\350\35\1\0\0\0\0\0\350\35!'4\0\0\0\350\35!'4\0\0\0\300\1\0=
\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\=
0\0\0008\2\0'4\0\0\0008\2\0'4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0=
\0\0\0\0P\345td\4\0\0\0<\361\0\0\0\0\0\0<\361\0'4\0\0\0<\361\0'4\0\0\0,\3=
\0\0\0\0\0\0,\3\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 8=
32
26281 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148119, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D192, st_size=3D92736, st_atime=3D2012/10/09-11:16:43, st_mtime=3D201=
0/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:42}) =3D 0
26281 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f7035a22000
26281 mmap(0x3427000000, 2181864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3427000000
26281 mprotect(0x3427011000, 2097152, PROT_NONE) =3D 0
26281 mmap(0x3427211000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x11000) =3D 0x3427211000
26281 mmap(0x3427213000, 6888, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3427213000
26281 close(3)                          =3D 0
26281 open("/lib64/libnsl.so.1", O_RDONLY) =3D 3
26281 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240@\340\35=
10\0\0\0@\0\0\0\0\0\0\0\360\265\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0=
\6\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\340\3510\0\0\0@\0\340\3510\0\0\0\370\1=
\0\0\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \33\1\0\0=
\0\0\0 \33\341\3510\0\0\0 \33\341\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\=
0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\340\3510\0\0\0=
\0\0\340\3510\0\0\0\310@\1\0\0\0\0\0\310@\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\=
0\0\6\0\0\0xM\1\0\0\0\0\0xM\1\3520\0\0\0xM\1\3520\0\0\0\310\5\0\0\0\0\0\0=
008-\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250M\1\0\0\0\0\0\250M\1\3=
520\0\0\0\250M\1\3520\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\340\3510\0\0\0008\2\340\351=
0\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0<\33\=
1\0\0\0\0\0<\33\341\3510\0\0\0<\33\341\3510\0\0\0\\\5\0\0\0\0\0\0\\\5\0\0=
\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26281 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147206, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D232, st_size=3D114352, st_atime=3D2012/10/09-12:01:01, st_mtime=3D20=
10/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:44}) =3D 0
26281 mmap(0x30e9e00000, 2194096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9e00000
26281 mprotect(0x30e9e15000, 2093056, PROT_NONE) =3D 0
26281 mmap(0x30ea014000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x14000) =3D 0x30ea014000
26281 mmap(0x30ea016000, 6832, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x30ea016000
26281 close(3)                          =3D 0
26281 open("/lib64/libdl.so.2", O_RDONLY) =3D 3
26281 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\16`\3500=
\0\0\0@\0\0\0\0\0\0\0@R\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0`\3500\0\0\0@\0`\3500\0\0\0\370\1\0\0\0\0\0\0\37=
0\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\300\32\0\0\0\0\0\0\300\3=
2`\3500\0\0\0\300\32`\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0`\3500\0\0\0\0\0`\3500\0\0\=
0\224\37\0\0\0\0\0\0\224\37\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0`-\=
0\0\0\0\0\0`-\200\3500\0\0\0`-\200\3500\0\0\0 \3\0\0\0\0\0\0\240\3\0\0\0\=
0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\240-\0\0\0\0\0\0\240-\200\3500\0\0\0=
\240-\200\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0=
\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2`\3500\0\0\0008\2`\3500\0\0\0 \0\0\=
0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\334\32\0\0\0\0\0\=
0\334\32`\3500\0\0\0\334\32`\3500\0\0\0\264\0\0\0\0\0\0\0\264\0\0\0\0\0\0=
\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26281 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147322, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D48, st_size=3D23360, st_atime=3D2012/10/09-11:13:54, st_mtime=3D2010=
/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26281 mmap(0x30e8600000, 2109696, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8600000
26281 mprotect(0x30e8602000, 2097152, PROT_NONE) =3D 0
26281 mmap(0x30e8802000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x2000) =3D 0x30e8802000
26281 close(3)                          =3D 0
26281 open("/lib64/libm.so.6", O_RDONLY) =3D 3
26281 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`>\240\3510\=
0\0\0@\0\0\0\0\0\0\0\240X\t\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0)\0(\0\6\0\0\=
0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3510\0\0\0@\0\240\3510\0\0\0\370\1\0\0\0\=
0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\360\303\7\0\0\0\=
0\0\360\303\247\3510\0\0\0\360\303\247\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0=
\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3510\=
0\0\0\0\0\240\3510\0\0\0000\22\10\0\0\0\0\0000\22\10\0\0\0\0\0\0\0 \0\0\0=
\0\0\1\0\0\0\6\0\0\0\270\35\10\0\0\0\0\0\270\35\310\3510\0\0\0\270\35\310=
\3510\0\0\0\320\2\0\0\0\0\0\0 \3\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0=
\0\350\35\10\0\0\0\0\0\350\35\310\3510\0\0\0\350\35\310\3510\0\0\0\300\1\=
0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0=
\0\0\0008\2\240\3510\0\0\0008\2\240\3510\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\f\304\7\0\0\0\0\0\f\304\247\3510\0\0\0=
\f\304\247\3510\0\0\0\374\r\0\0\0\0\0\0\374\r\0\0\0\0\0\0\4\0\0\0\0\0\0\0=
Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0"..., 832) =3D 832
26281 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147337, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D1216, st_size=3D615136, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2=
010/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26281 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f7035a21000
26281 mmap(0x30e9a00000, 2629848, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9a00000
26281 mprotect(0x30e9a82000, 2093056, PROT_NONE) =3D 0
26281 mmap(0x30e9c81000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x81000) =3D 0x30e9c81000
26281 close(3)                          =3D 0
26281 open("/lib64/libcrypt.so.1", O_RDONLY) =3D 3
26281 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\t\300%4=
\0\0\0@\0\0\0\0\0\0\0\30\265\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\=
0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\300%4\0\0\0@\0\300%4\0\0\0\370\1\0\0\0\0\=
0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340}\0\0\0\0\0\0\3=
40}\300%4\0\0\0\340}\300%4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\300%4\0\0\0\0\0\300%4\0\0\=
0\4\205\0\0\0\0\0\0\4\205\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\310\=
215\0\0\0\0\0\0\310\215\340%4\0\0\0\310\215\340%4\0\0\0\250\2\0\0\0\0\0\0=
\370\343\2\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\215\0\0\0\0\0\0\3=
70\215\340%4\0\0\0\370\215\340%4\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\=
0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\300%4\0\0\0008\2=
\300%4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0=
\374}\0\0\0\0\0\0\374}\300%4\0\0\0\374}\300%4\0\0\0\34\1\0\0\0\0\0\0\34\1=
\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26281 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148123, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D96, st_size=3D48600, st_atime=3D2012/10/09-12:01:01, st_mtime=3D2010=
/07/28-03:52:39, st_ctime=3D2012/09/11-14:53:52}) =3D 0
26281 mmap(0x3425c00000, 2322880, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425c00000
26281 mprotect(0x3425c09000, 2093056, PROT_NONE) =3D 0
26281 mmap(0x3425e08000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x8000) =3D 0x3425e08000
26281 mmap(0x3425e0a000, 184768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FI=
XED|MAP_ANONYMOUS, -1, 0) =3D 0x3425e0a000
26281 close(3)                          =3D 0
26281 open("/lib64/libutil.so.1", O_RDONLY) =3D 3
26281 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\16\0(4\=
0\0\0@\0\0\0\0\0\0\0(>\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0\0(4\0\0\0@\0\0(4\0\0\0\370\1\0\0\0\0\0\0\370\1\=
0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340\26\0\0\0\0\0\0\340\26\0(=
4\0\0\0\340\26\0(4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0=
\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0(4\0\0\0\0\0\0(4\0\0\0P\32\0\0\0\=
0\0\0P\32\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\35\0\0\0\0\0\0\3=
40\35 (4\0\0\0\340\35 (4\0\0\0 \3\0\0\0\0\0\0000\3\0\0\0\0\0\0\0\0 \0\0\0=
\0\0\2\0\0\0\6\0\0\0\20\36\0\0\0\0\0\0\20\36 (4\0\0\0\20\36 (4\0\0\0\300\=
1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0=
\0\0\0\0008\2\0(4\0\0\0008\2\0(4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\=
0\0\0\0\0\0P\345td\4\0\0\0\374\26\0\0\0\0\0\0\374\26\0(4\0\0\0\374\26\0(4=
\0\0\0D\0\0\0\0\0\0\0D\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8=
32) =3D 832
26281 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147063, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D40, st_size=3D18152, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2010=
/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:49}) =3D 0
26281 mmap(0x3428000000, 2105616, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3428000000
26281 mprotect(0x3428002000, 2093056, PROT_NONE) =3D 0
26281 mmap(0x3428201000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x1000) =3D 0x3428201000
26281 close(3)                          =3D 0
26281 open("/lib64/libpthread.so.0", O_RDONLY) =3D 3
26281 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240W\240\35=
00\0\0\0@\0\0\0\0\0\0\0\340/\2\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0'\0&\0\6\0=
\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3500\0\0\0@\0\240\3500\0\0\0\370\1\0\0=
\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\240\t\1\0\0\0=
\0\0\240\t\241\3500\0\0\0\240\t\241\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\=
0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3500\0\0=
\0\0\0\240\3500\0\0\0pZ\1\0\0\0\0\0pZ\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\=
6\0\0\0\270[\1\0\0\0\0\0\270[\301\3500\0\0\0\270[\301\3500\0\0\0\230\6\0\=
0\0\0\0\0\270G\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250]\1\0\0\0\0\=
0\250]\301\3500\0\0\0\250]\301\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0=
\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\240\3500\0\0\=
0008\2\240\3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345t=
d\4\0\0\0\274\t\1\0\0\0\0\0\274\t\241\3500\0\0\0\274\t\241\3500\0\0\0\344=
\t\0\0\0\0\0\0\344\t\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =
=3D 832
26281 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147328, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D296, st_size=3D145824, st_atime=3D2012/10/09-11:16:43, st_mtime=3D20=
10/07/28-03:52:41, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26281 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f7035a20000
26281 mmap(0x30e8a00000, 2204528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8a00000
26281 mprotect(0x30e8a16000, 2093056, PROT_NONE) =3D 0
26281 mmap(0x30e8c15000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x15000) =3D 0x30e8c15000
26281 mmap(0x30e8c17000, 13168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8c17000
26281 close(3)                          =3D 0
26281 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26281 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26281 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26281 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26281 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26281 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26281 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26281 close(3)                          =3D 0
26281 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f7035a1f000
26281 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f7035a1e000
26281 arch_prctl(ARCH_SET_FS, 0x7f7035a1e6e0) =3D 0
26281 mprotect(0x3427211000, 4096, PROT_READ) =3D 0
26281 mprotect(0x30ea014000, 4096, PROT_READ) =3D 0
26281 mprotect(0x30e8802000, 4096, PROT_READ) =3D 0
26281 mprotect(0x30e9c81000, 4096, PROT_READ) =3D 0
26281 mprotect(0x3425e08000, 4096, PROT_READ) =3D 0
26281 mprotect(0x3428201000, 4096, PROT_READ) =3D 0
26281 mprotect(0x30e8c15000, 4096, PROT_READ) =3D 0
26281 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26281 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26281 munmap(0x7f7035a23000, 103979)    =3D 0
26281 set_tid_address(0x7f7035a1e770)   =3D 26281
26281 set_robust_list(0x7f7035a1e780, 0x18) =3D 0
26281 futex(0x7fffb809720c, FUTEX_WAKE_PRIVATE, 1) =3D 0
26281 rt_sigaction(SIGRTMIN, {0x30e8a05380, [], SA_RESTORER|SA_SIGINFO, 0=
x30e8a0eb10}, NULL, 8) =3D 0
26281 rt_sigaction(SIGRT_1, {0x30e8a052b0, [], SA_RESTORER|SA_RESTART|SA_=
SIGINFO, 0x30e8a0eb10}, NULL, 8) =3D 0
26281 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) =3D 0
26281 getrlimit(RLIMIT_STACK, {rlim_cur=3D8192*1024, rlim_max=3DRLIM_INFI=
NITY}) =3D 0
26281 rt_sigaction(SIGFPE, {0x1, [FPE], SA_RESTORER|SA_RESTART, 0x30e8230=
2d0}, {SIG_DFL, [], 0}, 8) =3D 0
26281 brk(0)                            =3D 0x2557000
26281 brk(0x2579000)                    =3D 0x2579000
26281 getuid()                          =3D 0
26281 geteuid()                         =3D 0
26281 getgid()                          =3D 0
26281 getegid()                         =3D 0
26281 mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,=
 -1, 0) =3D 0x7f70359fd000
26281 open("/dev/urandom", O_RDONLY)    =3D 3
26281 read(3, "\226:\377$", 4)          =3D 4
26281 close(3)                          =3D 0
26281 stat("/usr/lib64/perl5/site_perl/5.8.7/x86_64-linux-thread-multi", =
0x7fffb8096ec0) =3D -1 ENOENT (No such file or directory)
26281 stat("/usr/lib/perl5/site_perl/5.8.7", 0x7fffb8096ec0) =3D -1 ENOEN=
T (No such file or directory)
26281 stat("/usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi", =
0x7fffb8096ec0) =3D -1 ENOENT (No such file or directory)
26281 stat("/usr/lib/perl5/site_perl/5.8.6", 0x7fffb8096ec0) =3D -1 ENOEN=
T (No such file or directory)
26281 stat("/usr/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi", =
0x7fffb8096ec0) =3D -1 ENOENT (No such file or directory)
26281 stat("/usr/lib/perl5/site_perl/5.8.5", 0x7fffb8096ec0) =3D -1 ENOEN=
T (No such file or directory)
26281 stat("/usr/lib64/perl5/vendor_perl/5.8.7/x86_64-linux-thread-multi"=
, 0x7fffb8096ec0) =3D -1 ENOENT (No such file or directory)
26281 stat("/usr/lib/perl5/vendor_perl/5.8.7", 0x7fffb8096ec0) =3D -1 ENO=
ENT (No such file or directory)
26281 stat("/usr/lib64/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi"=
, 0x7fffb8096ec0) =3D -1 ENOENT (No such file or directory)
26281 stat("/usr/lib/perl5/vendor_perl/5.8.6", 0x7fffb8096ec0) =3D -1 ENO=
ENT (No such file or directory)
26281 stat("/usr/lib64/perl5/vendor_perl/5.8.5/x86_64-linux-thread-multi"=
, 0x7fffb8096ec0) =3D -1 ENOENT (No such file or directory)
26281 stat("/usr/lib/perl5/vendor_perl/5.8.5", 0x7fffb8096ec0) =3D -1 ENO=
ENT (No such file or directory)
26281 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffb8096c80) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26281 lseek(0, 0, SEEK_CUR)             =3D 0
26281 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffb8096c80) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26281 lseek(1, 0, SEEK_CUR)             =3D -1 ESPIPE (Illegal seek)
26281 ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffb8096c90) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26281 lseek(2, 0, SEEK_CUR)             =3D 593658315
26281 open("/dev/null", O_RDONLY)       =3D 3
26281 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffb8096d90) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26281 lseek(3, 0, SEEK_CUR)             =3D 0
26281 fcntl(3, F_SETFD, FD_CLOEXEC)     =3D 0
26281 fstat(3, {st_dev=3Dmakedev(0, 16), st_ino=3D584, st_mode=3DS_IFCHR|=
0666, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
0, st_rdev=3Dmakedev(1, 3), st_atime=3D2012/10/08-11:13:26, st_mtime=3D20=
12/10/08-11:13:26, st_ctime=3D2012/10/08-11:13:27}) =3D 0
26281 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) =3D 0
26281 readlink("/proc/self/exe", "/usr/bin/perl"..., 4095) =3D 13
26281 brk(0x259a000)                    =3D 0x259a000
26281 close(3)                          =3D 0
26281 dup(200)                          =3D 3
26281 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffb8096c60) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26281 lseek(3, 0, SEEK_CUR)             =3D 0
26281 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26281 dup2(3, 0)                        =3D 0
26281 close(3)                          =3D 0
26281 fcntl(0, F_SETFD, 0)              =3D 0
26281 fstat(0, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26281 stat("/var/run/xen-hotplug/block", {st_dev=3Dmakedev(8, 2), st_ino=3D=
2801738, st_mode=3DS_IFREG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st=
_blksize=3D4096, st_blocks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:=
24, st_mtime=3D2012/10/09-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D =
0
26281 exit_group(0)                     =3D ?
27813 <... read resumed> "", 128)       =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], WNOHANG, NUL=
L) =3D 26281
27813 wait4(-1, 0x7fffb0100a64, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0)                   =3D 0
27813 close(3)                          =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 write(2, "+ rightfile=3D\n", 13)    =3D 13
27813 write(2, "+ '[' x =3D xy ']'\n", 17) =3D 17
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ true\n", 7)           =3D 7
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ eval 'exec 200>>/var/run/xen-hotplug/block'\n", 46) =3D=
 46
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 write(2, "++ exec\n", 8)          =3D 8
27813 open("/var/run/xen-hotplug/block", O_WRONLY|O_CREAT|O_APPEND, 0666)=
 =3D 3
27813 fcntl(200, F_GETFD)               =3D 0
27813 fcntl(200, F_DUPFD, 10)           =3D 10
27813 fcntl(200, F_GETFD)               =3D 0
27813 dup2(3, 200)                      =3D 200
27813 close(3)                          =3D 0
27813 dup2(10, 200)                     =3D 200
27813 fcntl(10, F_GETFD)                =3D 0
27813 close(10)                         =3D 0
27813 write(2, "+ flock -x 200\n", 15)  =3D 15
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [INT CHLD], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [INT CHLD], NULL, 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26282
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26282 close(255 
27813 rt_sigprocmask(SIG_BLOCK, [CHLD],  
26282 <... close resumed> )             =3D 0
27813 <... rt_sigprocmask resumed> [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [],  
26282 rt_sigprocmask(SIG_SETMASK, [],  
27813 <... rt_sigprocmask resumed> NULL, 8) =3D 0
26282 <... rt_sigprocmask resumed> NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
26282 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0},  
26282 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
27813 <... rt_sigaction resumed> {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}=
, 8) =3D 0
26282 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 wait4(-1,  
26282 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
26282 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26282 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26282 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26282 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26282 execve("/usr/bin/flock", ["flock", "-x", "200"], ["SUBSYSTEM=3Dxen-=
backend", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D=
/usr/bin:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:=
/usr/sbin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dx=
en-backend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3D=
backend/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "S=
HLVL=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/flock"]) =3D 0=

26282 brk(0)                            =3D 0x1020000
26282 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f428ce90000
26282 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f428ce8f000
26282 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26282 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26282 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26282 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7f428ce75000=

26282 close(3)                          =3D 0
26282 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26282 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26282 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26282 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26282 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26282 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26282 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26282 close(3)                          =3D 0
26282 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f428ce74000
26282 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f428ce73000
26282 arch_prctl(ARCH_SET_FS, 0x7f428ce736e0) =3D 0
26282 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26282 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26282 munmap(0x7f428ce75000, 103979)    =3D 0
26282 flock(200, LOCK_EX)               =3D 0
26282 exit_group(0)                     =3D ?
27813 <... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], 0,=
 NULL) =3D 26282
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, 0x7fffb0100a24, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0xffffffffffffffff)  =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 pipe([3, 4])                      =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26283
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {0=
x436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26283 close(255 
27813 close(4 
26283 <... close resumed> )             =3D 0
27813 <... close resumed> )             =3D 0
27813 read(3,  
26283 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26283 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26283 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26283 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26283 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26283 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26283 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26283 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {S=
IG_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26283 rt_sigaction(SIGINT, {0x4481f0, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26283 dup2(4, 1)                        =3D 1
26283 close(4)                          =3D 0
26283 close(3)                          =3D 0
26283 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26283 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26283 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26283 write(2, "++ perl -e '\n            open STDIN, \"<&200\" or die $!=
;\n            my $fd_inum =3D (stat STDIN)[1]; die $! unless defined $fd=
_inum;\n            my $file_inum =3D (stat $ARGV[0])[1];\n            pr=
int \"y\\n\" if $fd_inum eq $file_inum;\n", 230) =3D 230
26283 write(2, "                             ' /var/run/xen-hotplug/block=
\n", 58) =3D 58
26283 stat(".", {st_dev=3Dmakedev(8, 2), st_ino=3D2, st_mode=3DS_IFDIR|07=
55, st_nlink=3D24, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
8, st_size=3D4096, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2012/10/08-=
11:13:38, st_ctime=3D2012/10/08-11:13:38}) =3D 0
26283 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26283 access("/usr/bin/perl", X_OK)     =3D 0
26283 access("/usr/bin/perl", R_OK)     =3D 0
26283 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26283 access("/usr/bin/perl", X_OK)     =3D 0
26283 access("/usr/bin/perl", R_OK)     =3D 0
26283 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
481f0, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26283 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26283 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26283 execve("/usr/bin/perl", ["perl", "-e", "\n            open STDIN, \=
"<&200\" or die $!;\n            my $fd_inum =3D (stat STDIN)[1]; die $! =
unless defined $fd_inum;\n            my $file_inum =3D (stat $ARGV[0])[1=
];\n            print \"y\\n\" if $fd_inum eq $file_inum;\n              =
               ", "/var/run/xen-hotplug/block"], ["SUBSYSTEM=3Dxen-backen=
d", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D/usr/b=
in:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:/usr/s=
bin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dxen-bac=
kend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3Dback=
end/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "SHLVL=
=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/perl"]) =3D 0
26283 brk(0)                            =3D 0x2076000
26283 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f11224aa000
26283 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f11224a9000
26283 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26283 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64/libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26283 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64", 0x7fffe22c6ee0) =3D -1 ENOENT (No such file or directory)
26283 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/lib=
perl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26283 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls", 0=
x7fffe22c6ee0) =3D -1 ENOENT (No such file or directory)
26283 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64/=
libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26283 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64"=
, 0x7fffe22c6ee0) =3D -1 ENOENT (No such file or directory)
26283 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl=
=2Eso", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26283 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE", 0x7ff=
fe22c6ee0) =3D -1 ENOENT (No such file or directory)
26283 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26283 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26283 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7f112248f000=

26283 close(3)                          =3D 0
26283 open("/usr/lib64/libperl.so", O_RDONLY) =3D 3
26283 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\34\203%=
4\0\0\0@\0\0\0\0\0\0\0\360;\23\0\0\0\0\0\0\0\0\0@\0008\0\5\0@\0\35\0\34\0=
\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\200%4\0\0\0\0\0\200%4\0\0\0T\260\22\=
0\0\0\0\0T\260\22\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0X\260\22\0\0\0\=
0\0X\260\262%4\0\0\0X\260\262%4\0\0\0\250\201\0\0\0\0\0\0\350\242\0\0\0\0=
\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\265\22\0\0\0\0\0\370\265\262%4\0\=
0\0\370\265\262%4\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\=
0\0P\345td\4\0\0\0\250u\21\0\0\0\0\0\250u\221%4\0\0\0\250u\221%4\0\0\0D@\=
0\0\0\0\0\0D@\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\7\4\0\0\360\0\0\0\0\1\0\0\16\0\0\0\0\0\0@\0\200\203\200\225\1\22\=
264\3\31\200l\0\32\0 \5\201\0\240\3\2B\0\200\21R \0\22\0\0\16P\20#\10\216=
\334\30\211\"\0\10 \200\3B\220@\0\1\206\20\30\2\3\21\203$!\312A0\224Y\200=
\27\0\242\26\10\24R@\10\200\220\20A\10\0\220\1\200\206\2\10\304\30i\0\220=
\1\1\202\200\22\20\0\n\1H\0\n\2001J \6\31@L\207\20\10\0000\10(\200\2\0\4\=
251t\"\262\310!\212\240\320\"\0\t"..., 832) =3D 832
26283 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2839671, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D2480, st_size=3D1262384, st_atime=3D2012/10/09-12:04:35, st_mtime=3D=
2012/09/11-12:45:05, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26283 mmap(0x3425800000, 3363648, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425800000
26283 mprotect(0x342592c000, 2093056, PROT_NONE) =3D 0
26283 mmap(0x3425b2b000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x12b000) =3D 0x3425b2b000
26283 mmap(0x3425b34000, 4928, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3425b34000
26283 close(3)                          =3D 0
26283 open("/lib64/libresolv.so.2", O_RDONLY) =3D 3
26283 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\2402\0'4\0\=
0\0@\0\0\0\0\0\0\0@a\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\5\0=
\0\0@\0\0\0\0\0\0\0@\0\0'4\0\0\0@\0\0'4\0\0\0\370\1\0\0\0\0\0\0\370\1\0\0=
\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \361\0\0\0\0\0\0 \361\0'4\0\0\0=
 \361\0'4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\=
0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0'4\0\0\0\0\0\0'4\0\0\0$\10\1\0\0\0\0\0$\10=
\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\24\1\0\0\0\0\0\340\24!'4\=
0\0\0\340\24!'4\0\0\0\340\r\0\0\0\0\0\0\0106\0\0\0\0\0\0\0\0 \0\0\0\0\0\2=
\0\0\0\6\0\0\0\350\35\1\0\0\0\0\0\350\35!'4\0\0\0\350\35!'4\0\0\0\300\1\0=
\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\=
0\0\0008\2\0'4\0\0\0008\2\0'4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0=
\0\0\0\0P\345td\4\0\0\0<\361\0\0\0\0\0\0<\361\0'4\0\0\0<\361\0'4\0\0\0,\3=
\0\0\0\0\0\0,\3\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 8=
32
26283 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148119, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D192, st_size=3D92736, st_atime=3D2012/10/09-11:16:43, st_mtime=3D201=
0/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:42}) =3D 0
26283 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f112248e000
26283 mmap(0x3427000000, 2181864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3427000000
26283 mprotect(0x3427011000, 2097152, PROT_NONE) =3D 0
26283 mmap(0x3427211000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x11000) =3D 0x3427211000
26283 mmap(0x3427213000, 6888, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3427213000
26283 close(3)                          =3D 0
26283 open("/lib64/libnsl.so.1", O_RDONLY) =3D 3
26283 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240@\340\35=
10\0\0\0@\0\0\0\0\0\0\0\360\265\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0=
\6\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\340\3510\0\0\0@\0\340\3510\0\0\0\370\1=
\0\0\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \33\1\0\0=
\0\0\0 \33\341\3510\0\0\0 \33\341\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\=
0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\340\3510\0\0\0=
\0\0\340\3510\0\0\0\310@\1\0\0\0\0\0\310@\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\=
0\0\6\0\0\0xM\1\0\0\0\0\0xM\1\3520\0\0\0xM\1\3520\0\0\0\310\5\0\0\0\0\0\0=
008-\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250M\1\0\0\0\0\0\250M\1\3=
520\0\0\0\250M\1\3520\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\340\3510\0\0\0008\2\340\351=
0\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0<\33\=
1\0\0\0\0\0<\33\341\3510\0\0\0<\33\341\3510\0\0\0\\\5\0\0\0\0\0\0\\\5\0\0=
\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26283 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147206, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D232, st_size=3D114352, st_atime=3D2012/10/09-12:01:01, st_mtime=3D20=
10/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:44}) =3D 0
26283 mmap(0x30e9e00000, 2194096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9e00000
26283 mprotect(0x30e9e15000, 2093056, PROT_NONE) =3D 0
26283 mmap(0x30ea014000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x14000) =3D 0x30ea014000
26283 mmap(0x30ea016000, 6832, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x30ea016000
26283 close(3)                          =3D 0
26283 open("/lib64/libdl.so.2", O_RDONLY) =3D 3
26283 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\16`\3500=
\0\0\0@\0\0\0\0\0\0\0@R\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0`\3500\0\0\0@\0`\3500\0\0\0\370\1\0\0\0\0\0\0\37=
0\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\300\32\0\0\0\0\0\0\300\3=
2`\3500\0\0\0\300\32`\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0`\3500\0\0\0\0\0`\3500\0\0\=
0\224\37\0\0\0\0\0\0\224\37\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0`-\=
0\0\0\0\0\0`-\200\3500\0\0\0`-\200\3500\0\0\0 \3\0\0\0\0\0\0\240\3\0\0\0\=
0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\240-\0\0\0\0\0\0\240-\200\3500\0\0\0=
\240-\200\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0=
\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2`\3500\0\0\0008\2`\3500\0\0\0 \0\0\=
0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\334\32\0\0\0\0\0\=
0\334\32`\3500\0\0\0\334\32`\3500\0\0\0\264\0\0\0\0\0\0\0\264\0\0\0\0\0\0=
\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26283 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147322, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D48, st_size=3D23360, st_atime=3D2012/10/09-11:13:54, st_mtime=3D2010=
/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26283 mmap(0x30e8600000, 2109696, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8600000
26283 mprotect(0x30e8602000, 2097152, PROT_NONE) =3D 0
26283 mmap(0x30e8802000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x2000) =3D 0x30e8802000
26283 close(3)                          =3D 0
26283 open("/lib64/libm.so.6", O_RDONLY) =3D 3
26283 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`>\240\3510\=
0\0\0@\0\0\0\0\0\0\0\240X\t\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0)\0(\0\6\0\0\=
0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3510\0\0\0@\0\240\3510\0\0\0\370\1\0\0\0\=
0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\360\303\7\0\0\0\=
0\0\360\303\247\3510\0\0\0\360\303\247\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0=
\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3510\=
0\0\0\0\0\240\3510\0\0\0000\22\10\0\0\0\0\0000\22\10\0\0\0\0\0\0\0 \0\0\0=
\0\0\1\0\0\0\6\0\0\0\270\35\10\0\0\0\0\0\270\35\310\3510\0\0\0\270\35\310=
\3510\0\0\0\320\2\0\0\0\0\0\0 \3\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0=
\0\350\35\10\0\0\0\0\0\350\35\310\3510\0\0\0\350\35\310\3510\0\0\0\300\1\=
0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0=
\0\0\0008\2\240\3510\0\0\0008\2\240\3510\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\f\304\7\0\0\0\0\0\f\304\247\3510\0\0\0=
\f\304\247\3510\0\0\0\374\r\0\0\0\0\0\0\374\r\0\0\0\0\0\0\4\0\0\0\0\0\0\0=
Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0"..., 832) =3D 832
26283 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147337, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D1216, st_size=3D615136, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2=
010/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26283 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f112248d000
26283 mmap(0x30e9a00000, 2629848, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9a00000
26283 mprotect(0x30e9a82000, 2093056, PROT_NONE) =3D 0
26283 mmap(0x30e9c81000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x81000) =3D 0x30e9c81000
26283 close(3)                          =3D 0
26283 open("/lib64/libcrypt.so.1", O_RDONLY) =3D 3
26283 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\t\300%4=
\0\0\0@\0\0\0\0\0\0\0\30\265\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\=
0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\300%4\0\0\0@\0\300%4\0\0\0\370\1\0\0\0\0\=
0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340}\0\0\0\0\0\0\3=
40}\300%4\0\0\0\340}\300%4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\300%4\0\0\0\0\0\300%4\0\0\=
0\4\205\0\0\0\0\0\0\4\205\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\310\=
215\0\0\0\0\0\0\310\215\340%4\0\0\0\310\215\340%4\0\0\0\250\2\0\0\0\0\0\0=
\370\343\2\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\215\0\0\0\0\0\0\3=
70\215\340%4\0\0\0\370\215\340%4\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\=
0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\300%4\0\0\0008\2=
\300%4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0=
\374}\0\0\0\0\0\0\374}\300%4\0\0\0\374}\300%4\0\0\0\34\1\0\0\0\0\0\0\34\1=
\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26283 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148123, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D96, st_size=3D48600, st_atime=3D2012/10/09-12:01:01, st_mtime=3D2010=
/07/28-03:52:39, st_ctime=3D2012/09/11-14:53:52}) =3D 0
26283 mmap(0x3425c00000, 2322880, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425c00000
26283 mprotect(0x3425c09000, 2093056, PROT_NONE) =3D 0
26283 mmap(0x3425e08000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x8000) =3D 0x3425e08000
26283 mmap(0x3425e0a000, 184768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FI=
XED|MAP_ANONYMOUS, -1, 0) =3D 0x3425e0a000
26283 close(3)                          =3D 0
26283 open("/lib64/libutil.so.1", O_RDONLY) =3D 3
26283 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\16\0(4\=
0\0\0@\0\0\0\0\0\0\0(>\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0\0(4\0\0\0@\0\0(4\0\0\0\370\1\0\0\0\0\0\0\370\1\=
0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340\26\0\0\0\0\0\0\340\26\0(=
4\0\0\0\340\26\0(4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0=
\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0(4\0\0\0\0\0\0(4\0\0\0P\32\0\0\0\=
0\0\0P\32\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\35\0\0\0\0\0\0\3=
40\35 (4\0\0\0\340\35 (4\0\0\0 \3\0\0\0\0\0\0000\3\0\0\0\0\0\0\0\0 \0\0\0=
\0\0\2\0\0\0\6\0\0\0\20\36\0\0\0\0\0\0\20\36 (4\0\0\0\20\36 (4\0\0\0\300\=
1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0=
\0\0\0\0008\2\0(4\0\0\0008\2\0(4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\=
0\0\0\0\0\0P\345td\4\0\0\0\374\26\0\0\0\0\0\0\374\26\0(4\0\0\0\374\26\0(4=
\0\0\0D\0\0\0\0\0\0\0D\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8=
32) =3D 832
26283 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147063, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D40, st_size=3D18152, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2010=
/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:49}) =3D 0
26283 mmap(0x3428000000, 2105616, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3428000000
26283 mprotect(0x3428002000, 2093056, PROT_NONE) =3D 0
26283 mmap(0x3428201000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x1000) =3D 0x3428201000
26283 close(3)                          =3D 0
26283 open("/lib64/libpthread.so.0", O_RDONLY) =3D 3
26283 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240W\240\35=
00\0\0\0@\0\0\0\0\0\0\0\340/\2\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0'\0&\0\6\0=
\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3500\0\0\0@\0\240\3500\0\0\0\370\1\0\0=
\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\240\t\1\0\0\0=
\0\0\240\t\241\3500\0\0\0\240\t\241\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\=
0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3500\0\0=
\0\0\0\240\3500\0\0\0pZ\1\0\0\0\0\0pZ\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\=
6\0\0\0\270[\1\0\0\0\0\0\270[\301\3500\0\0\0\270[\301\3500\0\0\0\230\6\0\=
0\0\0\0\0\270G\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250]\1\0\0\0\0\=
0\250]\301\3500\0\0\0\250]\301\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0=
\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\240\3500\0\0\=
0008\2\240\3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345t=
d\4\0\0\0\274\t\1\0\0\0\0\0\274\t\241\3500\0\0\0\274\t\241\3500\0\0\0\344=
\t\0\0\0\0\0\0\344\t\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =
=3D 832
26283 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147328, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D296, st_size=3D145824, st_atime=3D2012/10/09-11:16:43, st_mtime=3D20=
10/07/28-03:52:41, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26283 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f112248c000
26283 mmap(0x30e8a00000, 2204528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8a00000
26283 mprotect(0x30e8a16000, 2093056, PROT_NONE) =3D 0
26283 mmap(0x30e8c15000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x15000) =3D 0x30e8c15000
26283 mmap(0x30e8c17000, 13168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8c17000
26283 close(3)                          =3D 0
26283 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26283 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26283 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26283 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26283 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26283 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26283 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26283 close(3)                          =3D 0
26283 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f112248b000
26283 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f112248a000
26283 arch_prctl(ARCH_SET_FS, 0x7f112248a6e0) =3D 0
26283 mprotect(0x3427211000, 4096, PROT_READ) =3D 0
26283 mprotect(0x30ea014000, 4096, PROT_READ) =3D 0
26283 mprotect(0x30e8802000, 4096, PROT_READ) =3D 0
26283 mprotect(0x30e9c81000, 4096, PROT_READ) =3D 0
26283 mprotect(0x3425e08000, 4096, PROT_READ) =3D 0
26283 mprotect(0x3428201000, 4096, PROT_READ) =3D 0
26283 mprotect(0x30e8c15000, 4096, PROT_READ) =3D 0
26283 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26283 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26283 munmap(0x7f112248f000, 103979)    =3D 0
26283 set_tid_address(0x7f112248a770)   =3D 26283
26283 set_robust_list(0x7f112248a780, 0x18) =3D 0
26283 futex(0x7fffe22c7a0c, FUTEX_WAKE_PRIVATE, 1) =3D 0
26283 rt_sigaction(SIGRTMIN, {0x30e8a05380, [], SA_RESTORER|SA_SIGINFO, 0=
x30e8a0eb10}, NULL, 8) =3D 0
26283 rt_sigaction(SIGRT_1, {0x30e8a052b0, [], SA_RESTORER|SA_RESTART|SA_=
SIGINFO, 0x30e8a0eb10}, NULL, 8) =3D 0
26283 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) =3D 0
26283 getrlimit(RLIMIT_STACK, {rlim_cur=3D8192*1024, rlim_max=3DRLIM_INFI=
NITY}) =3D 0
26283 rt_sigaction(SIGFPE, {0x1, [FPE], SA_RESTORER|SA_RESTART, 0x30e8230=
2d0}, {SIG_DFL, [], 0}, 8) =3D 0
26283 brk(0)                            =3D 0x2076000
26283 brk(0x2098000)                    =3D 0x2098000
26283 getuid()                          =3D 0
26283 geteuid()                         =3D 0
26283 getgid()                          =3D 0
26283 getegid()                         =3D 0
26283 mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,=
 -1, 0) =3D 0x7f1122469000
26283 open("/dev/urandom", O_RDONLY)    =3D 3
26283 read(3, "\3I\211\1", 4)           =3D 4
26283 close(3)                          =3D 0
26283 stat("/usr/lib64/perl5/site_perl/5.8.7/x86_64-linux-thread-multi", =
0x7fffe22c76c0) =3D -1 ENOENT (No such file or directory)
26283 stat("/usr/lib/perl5/site_perl/5.8.7", 0x7fffe22c76c0) =3D -1 ENOEN=
T (No such file or directory)
26283 stat("/usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi", =
0x7fffe22c76c0) =3D -1 ENOENT (No such file or directory)
26283 stat("/usr/lib/perl5/site_perl/5.8.6", 0x7fffe22c76c0) =3D -1 ENOEN=
T (No such file or directory)
26283 stat("/usr/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi", =
0x7fffe22c76c0) =3D -1 ENOENT (No such file or directory)
26283 stat("/usr/lib/perl5/site_perl/5.8.5", 0x7fffe22c76c0) =3D -1 ENOEN=
T (No such file or directory)
26283 stat("/usr/lib64/perl5/vendor_perl/5.8.7/x86_64-linux-thread-multi"=
, 0x7fffe22c76c0) =3D -1 ENOENT (No such file or directory)
26283 stat("/usr/lib/perl5/vendor_perl/5.8.7", 0x7fffe22c76c0) =3D -1 ENO=
ENT (No such file or directory)
26283 stat("/usr/lib64/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi"=
, 0x7fffe22c76c0) =3D -1 ENOENT (No such file or directory)
26283 stat("/usr/lib/perl5/vendor_perl/5.8.6", 0x7fffe22c76c0) =3D -1 ENO=
ENT (No such file or directory)
26283 stat("/usr/lib64/perl5/vendor_perl/5.8.5/x86_64-linux-thread-multi"=
, 0x7fffe22c76c0) =3D -1 ENOENT (No such file or directory)
26283 stat("/usr/lib/perl5/vendor_perl/5.8.5", 0x7fffe22c76c0) =3D -1 ENO=
ENT (No such file or directory)
26283 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffe22c7480) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26283 lseek(0, 0, SEEK_CUR)             =3D 0
26283 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffe22c7480) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26283 lseek(1, 0, SEEK_CUR)             =3D -1 ESPIPE (Illegal seek)
26283 ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffe22c7490) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26283 lseek(2, 0, SEEK_CUR)             =3D 593658709
26283 open("/dev/null", O_RDONLY)       =3D 3
26283 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffe22c7590) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26283 lseek(3, 0, SEEK_CUR)             =3D 0
26283 fcntl(3, F_SETFD, FD_CLOEXEC)     =3D 0
26283 fstat(3, {st_dev=3Dmakedev(0, 16), st_ino=3D584, st_mode=3DS_IFCHR|=
0666, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
0, st_rdev=3Dmakedev(1, 3), st_atime=3D2012/10/08-11:13:26, st_mtime=3D20=
12/10/08-11:13:26, st_ctime=3D2012/10/08-11:13:27}) =3D 0
26283 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) =3D 0
26283 readlink("/proc/self/exe", "/usr/bin/perl"..., 4095) =3D 13
26283 brk(0x20b9000)                    =3D 0x20b9000
26283 close(3)                          =3D 0
26283 dup(200)                          =3D 3
26283 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffe22c7460) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26283 lseek(3, 0, SEEK_CUR)             =3D 0
26283 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26283 dup2(3, 0)                        =3D 0
26283 close(3)                          =3D 0
26283 fcntl(0, F_SETFD, 0)              =3D 0
26283 fstat(0, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26283 stat("/var/run/xen-hotplug/block", {st_dev=3Dmakedev(8, 2), st_ino=3D=
2801738, st_mode=3DS_IFREG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st=
_blksize=3D4096, st_blocks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:=
24, st_mtime=3D2012/10/09-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D =
0
26283 exit_group(0)                     =3D ?
27813 <... read resumed> "", 128)       =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], WNOHANG, NUL=
L) =3D 26283
27813 wait4(-1, 0x7fffb0100a64, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0)                   =3D 0
27813 close(3)                          =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 write(2, "+ rightfile=3D\n", 13)    =3D 13
27813 write(2, "+ '[' x =3D xy ']'\n", 17) =3D 17
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ true\n", 7)           =3D 7
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ eval 'exec 200>>/var/run/xen-hotplug/block'\n", 46) =3D=
 46
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 write(2, "++ exec\n", 8)          =3D 8
27813 open("/var/run/xen-hotplug/block", O_WRONLY|O_CREAT|O_APPEND, 0666)=
 =3D 3
27813 fcntl(200, F_GETFD)               =3D 0
27813 fcntl(200, F_DUPFD, 10)           =3D 10
27813 fcntl(200, F_GETFD)               =3D 0
27813 dup2(3, 200)                      =3D 200
27813 close(3)                          =3D 0
27813 dup2(10, 200)                     =3D 200
27813 fcntl(10, F_GETFD)                =3D 0
27813 close(10)                         =3D 0
27813 write(2, "+ flock -x 200\n", 15)  =3D 15
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [INT CHLD], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [INT CHLD], NULL, 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26284
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26284 close(255 
27813 rt_sigprocmask(SIG_BLOCK, [CHLD],  
26284 <... close resumed> )             =3D 0
27813 <... rt_sigprocmask resumed> [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [],  
26284 rt_sigprocmask(SIG_SETMASK, [],  
27813 <... rt_sigprocmask resumed> NULL, 8) =3D 0
26284 <... rt_sigprocmask resumed> NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
26284 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0},  
26284 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
27813 <... rt_sigaction resumed> {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}=
, 8) =3D 0
26284 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 wait4(-1,  
26284 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
26284 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26284 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26284 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26284 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26284 execve("/usr/bin/flock", ["flock", "-x", "200"], ["SUBSYSTEM=3Dxen-=
backend", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D=
/usr/bin:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:=
/usr/sbin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dx=
en-backend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3D=
backend/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "S=
HLVL=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/flock"]) =3D 0=

26284 brk(0)                            =3D 0x20cf000
26284 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fc09b672000
26284 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fc09b671000
26284 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26284 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26284 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26284 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7fc09b657000=

26284 close(3)                          =3D 0
26284 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26284 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26284 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26284 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26284 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26284 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26284 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26284 close(3)                          =3D 0
26284 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fc09b656000
26284 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fc09b655000
26284 arch_prctl(ARCH_SET_FS, 0x7fc09b6556e0) =3D 0
26284 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26284 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26284 munmap(0x7fc09b657000, 103979)    =3D 0
26284 flock(200, LOCK_EX)               =3D 0
26284 exit_group(0)                     =3D ?
27813 <... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], 0,=
 NULL) =3D 26284
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, 0x7fffb0100a24, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0xffffffffffffffff)  =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 pipe([3, 4])                      =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26285
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {0=
x436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26285 close(255 
27813 close(4 
26285 <... close resumed> )             =3D 0
27813 <... close resumed> )             =3D 0
27813 read(3,  
26285 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26285 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26285 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26285 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26285 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26285 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26285 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26285 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {S=
IG_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26285 rt_sigaction(SIGINT, {0x4481f0, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26285 dup2(4, 1)                        =3D 1
26285 close(4)                          =3D 0
26285 close(3)                          =3D 0
26285 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26285 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26285 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26285 write(2, "++ perl -e '\n            open STDIN, \"<&200\" or die $!=
;\n            my $fd_inum =3D (stat STDIN)[1]; die $! unless defined $fd=
_inum;\n            my $file_inum =3D (stat $ARGV[0])[1];\n            pr=
int \"y\\n\" if $fd_inum eq $file_inum;\n", 230) =3D 230
26285 write(2, "                             ' /var/run/xen-hotplug/block=
\n", 58) =3D 58
26285 stat(".", {st_dev=3Dmakedev(8, 2), st_ino=3D2, st_mode=3DS_IFDIR|07=
55, st_nlink=3D24, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
8, st_size=3D4096, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2012/10/08-=
11:13:38, st_ctime=3D2012/10/08-11:13:38}) =3D 0
26285 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26285 access("/usr/bin/perl", X_OK)     =3D 0
26285 access("/usr/bin/perl", R_OK)     =3D 0
26285 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26285 access("/usr/bin/perl", X_OK)     =3D 0
26285 access("/usr/bin/perl", R_OK)     =3D 0
26285 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
481f0, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26285 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26285 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26285 execve("/usr/bin/perl", ["perl", "-e", "\n            open STDIN, \=
"<&200\" or die $!;\n            my $fd_inum =3D (stat STDIN)[1]; die $! =
unless defined $fd_inum;\n            my $file_inum =3D (stat $ARGV[0])[1=
];\n            print \"y\\n\" if $fd_inum eq $file_inum;\n              =
               ", "/var/run/xen-hotplug/block"], ["SUBSYSTEM=3Dxen-backen=
d", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D/usr/b=
in:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:/usr/s=
bin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dxen-bac=
kend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3Dback=
end/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "SHLVL=
=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/perl"]) =3D 0
26285 brk(0)                            =3D 0x2572000
26285 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f07e80ef000
26285 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f07e80ee000
26285 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26285 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64/libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26285 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64", 0x7fffd33be470) =3D -1 ENOENT (No such file or directory)
26285 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/lib=
perl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26285 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls", 0=
x7fffd33be470) =3D -1 ENOENT (No such file or directory)
26285 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64/=
libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26285 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64"=
, 0x7fffd33be470) =3D -1 ENOENT (No such file or directory)
26285 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl=
=2Eso", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26285 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE", 0x7ff=
fd33be470) =3D -1 ENOENT (No such file or directory)
26285 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26285 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26285 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7f07e80d4000=

26285 close(3)                          =3D 0
26285 open("/usr/lib64/libperl.so", O_RDONLY) =3D 3
26285 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\34\203%=
4\0\0\0@\0\0\0\0\0\0\0\360;\23\0\0\0\0\0\0\0\0\0@\0008\0\5\0@\0\35\0\34\0=
\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\200%4\0\0\0\0\0\200%4\0\0\0T\260\22\=
0\0\0\0\0T\260\22\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0X\260\22\0\0\0\=
0\0X\260\262%4\0\0\0X\260\262%4\0\0\0\250\201\0\0\0\0\0\0\350\242\0\0\0\0=
\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\265\22\0\0\0\0\0\370\265\262%4\0\=
0\0\370\265\262%4\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\=
0\0P\345td\4\0\0\0\250u\21\0\0\0\0\0\250u\221%4\0\0\0\250u\221%4\0\0\0D@\=
0\0\0\0\0\0D@\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\7\4\0\0\360\0\0\0\0\1\0\0\16\0\0\0\0\0\0@\0\200\203\200\225\1\22\=
264\3\31\200l\0\32\0 \5\201\0\240\3\2B\0\200\21R \0\22\0\0\16P\20#\10\216=
\334\30\211\"\0\10 \200\3B\220@\0\1\206\20\30\2\3\21\203$!\312A0\224Y\200=
\27\0\242\26\10\24R@\10\200\220\20A\10\0\220\1\200\206\2\10\304\30i\0\220=
\1\1\202\200\22\20\0\n\1H\0\n\2001J \6\31@L\207\20\10\0000\10(\200\2\0\4\=
251t\"\262\310!\212\240\320\"\0\t"..., 832) =3D 832
26285 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2839671, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D2480, st_size=3D1262384, st_atime=3D2012/10/09-12:04:35, st_mtime=3D=
2012/09/11-12:45:05, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26285 mmap(0x3425800000, 3363648, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425800000
26285 mprotect(0x342592c000, 2093056, PROT_NONE) =3D 0
26285 mmap(0x3425b2b000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x12b000) =3D 0x3425b2b000
26285 mmap(0x3425b34000, 4928, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3425b34000
26285 close(3)                          =3D 0
26285 open("/lib64/libresolv.so.2", O_RDONLY) =3D 3
26285 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\2402\0'4\0\=
0\0@\0\0\0\0\0\0\0@a\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\5\0=
\0\0@\0\0\0\0\0\0\0@\0\0'4\0\0\0@\0\0'4\0\0\0\370\1\0\0\0\0\0\0\370\1\0\0=
\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \361\0\0\0\0\0\0 \361\0'4\0\0\0=
 \361\0'4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\=
0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0'4\0\0\0\0\0\0'4\0\0\0$\10\1\0\0\0\0\0$\10=
\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\24\1\0\0\0\0\0\340\24!'4\=
0\0\0\340\24!'4\0\0\0\340\r\0\0\0\0\0\0\0106\0\0\0\0\0\0\0\0 \0\0\0\0\0\2=
\0\0\0\6\0\0\0\350\35\1\0\0\0\0\0\350\35!'4\0\0\0\350\35!'4\0\0\0\300\1\0=
\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\=
0\0\0008\2\0'4\0\0\0008\2\0'4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0=
\0\0\0\0P\345td\4\0\0\0<\361\0\0\0\0\0\0<\361\0'4\0\0\0<\361\0'4\0\0\0,\3=
\0\0\0\0\0\0,\3\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 8=
32
26285 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148119, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D192, st_size=3D92736, st_atime=3D2012/10/09-11:16:43, st_mtime=3D201=
0/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:42}) =3D 0
26285 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f07e80d3000
26285 mmap(0x3427000000, 2181864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3427000000
26285 mprotect(0x3427011000, 2097152, PROT_NONE) =3D 0
26285 mmap(0x3427211000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x11000) =3D 0x3427211000
26285 mmap(0x3427213000, 6888, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3427213000
26285 close(3)                          =3D 0
26285 open("/lib64/libnsl.so.1", O_RDONLY) =3D 3
26285 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240@\340\35=
10\0\0\0@\0\0\0\0\0\0\0\360\265\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0=
\6\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\340\3510\0\0\0@\0\340\3510\0\0\0\370\1=
\0\0\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \33\1\0\0=
\0\0\0 \33\341\3510\0\0\0 \33\341\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\=
0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\340\3510\0\0\0=
\0\0\340\3510\0\0\0\310@\1\0\0\0\0\0\310@\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\=
0\0\6\0\0\0xM\1\0\0\0\0\0xM\1\3520\0\0\0xM\1\3520\0\0\0\310\5\0\0\0\0\0\0=
008-\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250M\1\0\0\0\0\0\250M\1\3=
520\0\0\0\250M\1\3520\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\340\3510\0\0\0008\2\340\351=
0\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0<\33\=
1\0\0\0\0\0<\33\341\3510\0\0\0<\33\341\3510\0\0\0\\\5\0\0\0\0\0\0\\\5\0\0=
\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26285 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147206, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D232, st_size=3D114352, st_atime=3D2012/10/09-12:01:01, st_mtime=3D20=
10/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:44}) =3D 0
26285 mmap(0x30e9e00000, 2194096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9e00000
26285 mprotect(0x30e9e15000, 2093056, PROT_NONE) =3D 0
26285 mmap(0x30ea014000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x14000) =3D 0x30ea014000
26285 mmap(0x30ea016000, 6832, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x30ea016000
26285 close(3)                          =3D 0
26285 open("/lib64/libdl.so.2", O_RDONLY) =3D 3
26285 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\16`\3500=
\0\0\0@\0\0\0\0\0\0\0@R\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0`\3500\0\0\0@\0`\3500\0\0\0\370\1\0\0\0\0\0\0\37=
0\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\300\32\0\0\0\0\0\0\300\3=
2`\3500\0\0\0\300\32`\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0`\3500\0\0\0\0\0`\3500\0\0\=
0\224\37\0\0\0\0\0\0\224\37\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0`-\=
0\0\0\0\0\0`-\200\3500\0\0\0`-\200\3500\0\0\0 \3\0\0\0\0\0\0\240\3\0\0\0\=
0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\240-\0\0\0\0\0\0\240-\200\3500\0\0\0=
\240-\200\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0=
\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2`\3500\0\0\0008\2`\3500\0\0\0 \0\0\=
0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\334\32\0\0\0\0\0\=
0\334\32`\3500\0\0\0\334\32`\3500\0\0\0\264\0\0\0\0\0\0\0\264\0\0\0\0\0\0=
\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26285 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147322, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D48, st_size=3D23360, st_atime=3D2012/10/09-11:13:54, st_mtime=3D2010=
/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26285 mmap(0x30e8600000, 2109696, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8600000
26285 mprotect(0x30e8602000, 2097152, PROT_NONE) =3D 0
26285 mmap(0x30e8802000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x2000) =3D 0x30e8802000
26285 close(3)                          =3D 0
26285 open("/lib64/libm.so.6", O_RDONLY) =3D 3
26285 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`>\240\3510\=
0\0\0@\0\0\0\0\0\0\0\240X\t\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0)\0(\0\6\0\0\=
0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3510\0\0\0@\0\240\3510\0\0\0\370\1\0\0\0\=
0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\360\303\7\0\0\0\=
0\0\360\303\247\3510\0\0\0\360\303\247\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0=
\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3510\=
0\0\0\0\0\240\3510\0\0\0000\22\10\0\0\0\0\0000\22\10\0\0\0\0\0\0\0 \0\0\0=
\0\0\1\0\0\0\6\0\0\0\270\35\10\0\0\0\0\0\270\35\310\3510\0\0\0\270\35\310=
\3510\0\0\0\320\2\0\0\0\0\0\0 \3\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0=
\0\350\35\10\0\0\0\0\0\350\35\310\3510\0\0\0\350\35\310\3510\0\0\0\300\1\=
0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0=
\0\0\0008\2\240\3510\0\0\0008\2\240\3510\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\f\304\7\0\0\0\0\0\f\304\247\3510\0\0\0=
\f\304\247\3510\0\0\0\374\r\0\0\0\0\0\0\374\r\0\0\0\0\0\0\4\0\0\0\0\0\0\0=
Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0"..., 832) =3D 832
26285 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147337, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D1216, st_size=3D615136, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2=
010/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26285 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f07e80d2000
26285 mmap(0x30e9a00000, 2629848, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9a00000
26285 mprotect(0x30e9a82000, 2093056, PROT_NONE) =3D 0
26285 mmap(0x30e9c81000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x81000) =3D 0x30e9c81000
26285 close(3)                          =3D 0
26285 open("/lib64/libcrypt.so.1", O_RDONLY) =3D 3
26285 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\t\300%4=
\0\0\0@\0\0\0\0\0\0\0\30\265\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\=
0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\300%4\0\0\0@\0\300%4\0\0\0\370\1\0\0\0\0\=
0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340}\0\0\0\0\0\0\3=
40}\300%4\0\0\0\340}\300%4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\300%4\0\0\0\0\0\300%4\0\0\=
0\4\205\0\0\0\0\0\0\4\205\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\310\=
215\0\0\0\0\0\0\310\215\340%4\0\0\0\310\215\340%4\0\0\0\250\2\0\0\0\0\0\0=
\370\343\2\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\215\0\0\0\0\0\0\3=
70\215\340%4\0\0\0\370\215\340%4\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\=
0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\300%4\0\0\0008\2=
\300%4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0=
\374}\0\0\0\0\0\0\374}\300%4\0\0\0\374}\300%4\0\0\0\34\1\0\0\0\0\0\0\34\1=
\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26285 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148123, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D96, st_size=3D48600, st_atime=3D2012/10/09-12:01:01, st_mtime=3D2010=
/07/28-03:52:39, st_ctime=3D2012/09/11-14:53:52}) =3D 0
26285 mmap(0x3425c00000, 2322880, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425c00000
26285 mprotect(0x3425c09000, 2093056, PROT_NONE) =3D 0
26285 mmap(0x3425e08000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x8000) =3D 0x3425e08000
26285 mmap(0x3425e0a000, 184768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FI=
XED|MAP_ANONYMOUS, -1, 0) =3D 0x3425e0a000
26285 close(3)                          =3D 0
26285 open("/lib64/libutil.so.1", O_RDONLY) =3D 3
26285 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\16\0(4\=
0\0\0@\0\0\0\0\0\0\0(>\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0\0(4\0\0\0@\0\0(4\0\0\0\370\1\0\0\0\0\0\0\370\1\=
0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340\26\0\0\0\0\0\0\340\26\0(=
4\0\0\0\340\26\0(4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0=
\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0(4\0\0\0\0\0\0(4\0\0\0P\32\0\0\0\=
0\0\0P\32\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\35\0\0\0\0\0\0\3=
40\35 (4\0\0\0\340\35 (4\0\0\0 \3\0\0\0\0\0\0000\3\0\0\0\0\0\0\0\0 \0\0\0=
\0\0\2\0\0\0\6\0\0\0\20\36\0\0\0\0\0\0\20\36 (4\0\0\0\20\36 (4\0\0\0\300\=
1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0=
\0\0\0\0008\2\0(4\0\0\0008\2\0(4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\=
0\0\0\0\0\0P\345td\4\0\0\0\374\26\0\0\0\0\0\0\374\26\0(4\0\0\0\374\26\0(4=
\0\0\0D\0\0\0\0\0\0\0D\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8=
32) =3D 832
26285 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147063, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D40, st_size=3D18152, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2010=
/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:49}) =3D 0
26285 mmap(0x3428000000, 2105616, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3428000000
26285 mprotect(0x3428002000, 2093056, PROT_NONE) =3D 0
26285 mmap(0x3428201000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x1000) =3D 0x3428201000
26285 close(3)                          =3D 0
26285 open("/lib64/libpthread.so.0", O_RDONLY) =3D 3
26285 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240W\240\35=
00\0\0\0@\0\0\0\0\0\0\0\340/\2\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0'\0&\0\6\0=
\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3500\0\0\0@\0\240\3500\0\0\0\370\1\0\0=
\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\240\t\1\0\0\0=
\0\0\240\t\241\3500\0\0\0\240\t\241\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\=
0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3500\0\0=
\0\0\0\240\3500\0\0\0pZ\1\0\0\0\0\0pZ\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\=
6\0\0\0\270[\1\0\0\0\0\0\270[\301\3500\0\0\0\270[\301\3500\0\0\0\230\6\0\=
0\0\0\0\0\270G\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250]\1\0\0\0\0\=
0\250]\301\3500\0\0\0\250]\301\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0=
\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\240\3500\0\0\=
0008\2\240\3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345t=
d\4\0\0\0\274\t\1\0\0\0\0\0\274\t\241\3500\0\0\0\274\t\241\3500\0\0\0\344=
\t\0\0\0\0\0\0\344\t\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =
=3D 832
26285 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147328, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D296, st_size=3D145824, st_atime=3D2012/10/09-11:16:43, st_mtime=3D20=
10/07/28-03:52:41, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26285 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f07e80d1000
26285 mmap(0x30e8a00000, 2204528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8a00000
26285 mprotect(0x30e8a16000, 2093056, PROT_NONE) =3D 0
26285 mmap(0x30e8c15000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x15000) =3D 0x30e8c15000
26285 mmap(0x30e8c17000, 13168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8c17000
26285 close(3)                          =3D 0
26285 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26285 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26285 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26285 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26285 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26285 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26285 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26285 close(3)                          =3D 0
26285 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f07e80d0000
26285 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f07e80cf000
26285 arch_prctl(ARCH_SET_FS, 0x7f07e80cf6e0) =3D 0
26285 mprotect(0x3427211000, 4096, PROT_READ) =3D 0
26285 mprotect(0x30ea014000, 4096, PROT_READ) =3D 0
26285 mprotect(0x30e8802000, 4096, PROT_READ) =3D 0
26285 mprotect(0x30e9c81000, 4096, PROT_READ) =3D 0
26285 mprotect(0x3425e08000, 4096, PROT_READ) =3D 0
26285 mprotect(0x3428201000, 4096, PROT_READ) =3D 0
26285 mprotect(0x30e8c15000, 4096, PROT_READ) =3D 0
26285 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26285 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26285 munmap(0x7f07e80d4000, 103979)    =3D 0
26285 set_tid_address(0x7f07e80cf770)   =3D 26285
26285 set_robust_list(0x7f07e80cf780, 0x18) =3D 0
26285 futex(0x7fffd33bef9c, FUTEX_WAKE_PRIVATE, 1) =3D 0
26285 rt_sigaction(SIGRTMIN, {0x30e8a05380, [], SA_RESTORER|SA_SIGINFO, 0=
x30e8a0eb10}, NULL, 8) =3D 0
26285 rt_sigaction(SIGRT_1, {0x30e8a052b0, [], SA_RESTORER|SA_RESTART|SA_=
SIGINFO, 0x30e8a0eb10}, NULL, 8) =3D 0
26285 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) =3D 0
26285 getrlimit(RLIMIT_STACK, {rlim_cur=3D8192*1024, rlim_max=3DRLIM_INFI=
NITY}) =3D 0
26285 rt_sigaction(SIGFPE, {0x1, [FPE], SA_RESTORER|SA_RESTART, 0x30e8230=
2d0}, {SIG_DFL, [], 0}, 8) =3D 0
26285 brk(0)                            =3D 0x2572000
26285 brk(0x2594000)                    =3D 0x2594000
26285 getuid()                          =3D 0
26285 geteuid()                         =3D 0
26285 getgid()                          =3D 0
26285 getegid()                         =3D 0
26285 mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,=
 -1, 0) =3D 0x7f07e80ae000
26285 open("/dev/urandom", O_RDONLY)    =3D 3
26285 read(3, "\246)iQ", 4)             =3D 4
26285 close(3)                          =3D 0
26285 stat("/usr/lib64/perl5/site_perl/5.8.7/x86_64-linux-thread-multi", =
0x7fffd33bec50) =3D -1 ENOENT (No such file or directory)
26285 stat("/usr/lib/perl5/site_perl/5.8.7", 0x7fffd33bec50) =3D -1 ENOEN=
T (No such file or directory)
26285 stat("/usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi", =
0x7fffd33bec50) =3D -1 ENOENT (No such file or directory)
26285 stat("/usr/lib/perl5/site_perl/5.8.6", 0x7fffd33bec50) =3D -1 ENOEN=
T (No such file or directory)
26285 stat("/usr/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi", =
0x7fffd33bec50) =3D -1 ENOENT (No such file or directory)
26285 stat("/usr/lib/perl5/site_perl/5.8.5", 0x7fffd33bec50) =3D -1 ENOEN=
T (No such file or directory)
26285 stat("/usr/lib64/perl5/vendor_perl/5.8.7/x86_64-linux-thread-multi"=
, 0x7fffd33bec50) =3D -1 ENOENT (No such file or directory)
26285 stat("/usr/lib/perl5/vendor_perl/5.8.7", 0x7fffd33bec50) =3D -1 ENO=
ENT (No such file or directory)
26285 stat("/usr/lib64/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi"=
, 0x7fffd33bec50) =3D -1 ENOENT (No such file or directory)
26285 stat("/usr/lib/perl5/vendor_perl/5.8.6", 0x7fffd33bec50) =3D -1 ENO=
ENT (No such file or directory)
26285 stat("/usr/lib64/perl5/vendor_perl/5.8.5/x86_64-linux-thread-multi"=
, 0x7fffd33bec50) =3D -1 ENOENT (No such file or directory)
26285 stat("/usr/lib/perl5/vendor_perl/5.8.5", 0x7fffd33bec50) =3D -1 ENO=
ENT (No such file or directory)
26285 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffd33bea10) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26285 lseek(0, 0, SEEK_CUR)             =3D 0
26285 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffd33bea10) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26285 lseek(1, 0, SEEK_CUR)             =3D -1 ESPIPE (Illegal seek)
26285 ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffd33bea20) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26285 lseek(2, 0, SEEK_CUR)             =3D 593659103
26285 open("/dev/null", O_RDONLY)       =3D 3
26285 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffd33beb20) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26285 lseek(3, 0, SEEK_CUR)             =3D 0
26285 fcntl(3, F_SETFD, FD_CLOEXEC)     =3D 0
26285 fstat(3, {st_dev=3Dmakedev(0, 16), st_ino=3D584, st_mode=3DS_IFCHR|=
0666, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
0, st_rdev=3Dmakedev(1, 3), st_atime=3D2012/10/08-11:13:26, st_mtime=3D20=
12/10/08-11:13:26, st_ctime=3D2012/10/08-11:13:27}) =3D 0
26285 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) =3D 0
26285 readlink("/proc/self/exe", "/usr/bin/perl"..., 4095) =3D 13
26285 brk(0x25b5000)                    =3D 0x25b5000
26285 close(3)                          =3D 0
26285 dup(200)                          =3D 3
26285 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffd33be9f0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26285 lseek(3, 0, SEEK_CUR)             =3D 0
26285 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26285 dup2(3, 0)                        =3D 0
26285 close(3)                          =3D 0
26285 fcntl(0, F_SETFD, 0)              =3D 0
26285 fstat(0, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26285 stat("/var/run/xen-hotplug/block", {st_dev=3Dmakedev(8, 2), st_ino=3D=
2801738, st_mode=3DS_IFREG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st=
_blksize=3D4096, st_blocks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:=
24, st_mtime=3D2012/10/09-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D =
0
26285 exit_group(0)                     =3D ?
27813 <... read resumed> "", 128)       =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], WNOHANG, NUL=
L) =3D 26285
27813 wait4(-1, 0x7fffb0100a64, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0)                   =3D 0
27813 close(3)                          =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 write(2, "+ rightfile=3D\n", 13)    =3D 13
27813 write(2, "+ '[' x =3D xy ']'\n", 17) =3D 17
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ true\n", 7)           =3D 7
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ eval 'exec 200>>/var/run/xen-hotplug/block'\n", 46) =3D=
 46
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 write(2, "++ exec\n", 8)          =3D 8
27813 open("/var/run/xen-hotplug/block", O_WRONLY|O_CREAT|O_APPEND, 0666)=
 =3D 3
27813 fcntl(200, F_GETFD)               =3D 0
27813 fcntl(200, F_DUPFD, 10)           =3D 10
27813 fcntl(200, F_GETFD)               =3D 0
27813 dup2(3, 200)                      =3D 200
27813 close(3)                          =3D 0
27813 dup2(10, 200)                     =3D 200
27813 fcntl(10, F_GETFD)                =3D 0
27813 close(10)                         =3D 0
27813 write(2, "+ flock -x 200\n", 15)  =3D 15
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [INT CHLD], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [INT CHLD], NULL, 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26286
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26286 close(255 
27813 rt_sigprocmask(SIG_BLOCK, [CHLD],  
26286 <... close resumed> )             =3D 0
27813 <... rt_sigprocmask resumed> [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [],  
26286 rt_sigprocmask(SIG_SETMASK, [],  
27813 <... rt_sigprocmask resumed> NULL, 8) =3D 0
26286 <... rt_sigprocmask resumed> NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
26286 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0},  
26286 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
27813 <... rt_sigaction resumed> {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}=
, 8) =3D 0
26286 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 wait4(-1,  
26286 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
26286 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26286 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26286 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26286 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26286 execve("/usr/bin/flock", ["flock", "-x", "200"], ["SUBSYSTEM=3Dxen-=
backend", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D=
/usr/bin:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:=
/usr/sbin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dx=
en-backend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3D=
backend/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "S=
HLVL=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/flock"]) =3D 0=

26286 brk(0)                            =3D 0x1bb0000
26286 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fafdc01b000
26286 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fafdc01a000
26286 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26286 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26286 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26286 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7fafdc000000=

26286 close(3)                          =3D 0
26286 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26286 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26286 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26286 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26286 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26286 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26286 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26286 close(3)                          =3D 0
26286 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fafdbfff000
26286 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fafdbffe000
26286 arch_prctl(ARCH_SET_FS, 0x7fafdbffe6e0) =3D 0
26286 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26286 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26286 munmap(0x7fafdc000000, 103979)    =3D 0
26286 flock(200, LOCK_EX)               =3D 0
26286 exit_group(0)                     =3D ?
27813 <... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], 0,=
 NULL) =3D 26286
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, 0x7fffb0100a24, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0xffffffffffffffff)  =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 pipe([3, 4])                      =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26287
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {0=
x436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26287 close(255 
27813 close(4 
26287 <... close resumed> )             =3D 0
27813 <... close resumed> )             =3D 0
27813 read(3,  
26287 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26287 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26287 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26287 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26287 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26287 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26287 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26287 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {S=
IG_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26287 rt_sigaction(SIGINT, {0x4481f0, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26287 dup2(4, 1)                        =3D 1
26287 close(4)                          =3D 0
26287 close(3)                          =3D 0
26287 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26287 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26287 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26287 write(2, "++ perl -e '\n            open STDIN, \"<&200\" or die $!=
;\n            my $fd_inum =3D (stat STDIN)[1]; die $! unless defined $fd=
_inum;\n            my $file_inum =3D (stat $ARGV[0])[1];\n            pr=
int \"y\\n\" if $fd_inum eq $file_inum;\n", 230) =3D 230
26287 write(2, "                             ' /var/run/xen-hotplug/block=
\n", 58) =3D 58
26287 stat(".", {st_dev=3Dmakedev(8, 2), st_ino=3D2, st_mode=3DS_IFDIR|07=
55, st_nlink=3D24, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
8, st_size=3D4096, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2012/10/08-=
11:13:38, st_ctime=3D2012/10/08-11:13:38}) =3D 0
26287 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26287 access("/usr/bin/perl", X_OK)     =3D 0
26287 access("/usr/bin/perl", R_OK)     =3D 0
26287 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26287 access("/usr/bin/perl", X_OK)     =3D 0
26287 access("/usr/bin/perl", R_OK)     =3D 0
26287 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
481f0, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26287 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26287 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26287 execve("/usr/bin/perl", ["perl", "-e", "\n            open STDIN, \=
"<&200\" or die $!;\n            my $fd_inum =3D (stat STDIN)[1]; die $! =
unless defined $fd_inum;\n            my $file_inum =3D (stat $ARGV[0])[1=
];\n            print \"y\\n\" if $fd_inum eq $file_inum;\n              =
               ", "/var/run/xen-hotplug/block"], ["SUBSYSTEM=3Dxen-backen=
d", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D/usr/b=
in:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:/usr/s=
bin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dxen-bac=
kend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3Dback=
end/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "SHLVL=
=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/perl"]) =3D 0
26287 brk(0)                            =3D 0x16fd000
26287 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f2da8f22000
26287 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f2da8f21000
26287 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26287 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64/libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26287 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64", 0x7fffb5e66d10) =3D -1 ENOENT (No such file or directory)
26287 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/lib=
perl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26287 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls", 0=
x7fffb5e66d10) =3D -1 ENOENT (No such file or directory)
26287 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64/=
libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26287 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64"=
, 0x7fffb5e66d10) =3D -1 ENOENT (No such file or directory)
26287 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl=
=2Eso", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26287 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE", 0x7ff=
fb5e66d10) =3D -1 ENOENT (No such file or directory)
26287 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26287 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26287 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7f2da8f07000=

26287 close(3)                          =3D 0
26287 open("/usr/lib64/libperl.so", O_RDONLY) =3D 3
26287 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\34\203%=
4\0\0\0@\0\0\0\0\0\0\0\360;\23\0\0\0\0\0\0\0\0\0@\0008\0\5\0@\0\35\0\34\0=
\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\200%4\0\0\0\0\0\200%4\0\0\0T\260\22\=
0\0\0\0\0T\260\22\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0X\260\22\0\0\0\=
0\0X\260\262%4\0\0\0X\260\262%4\0\0\0\250\201\0\0\0\0\0\0\350\242\0\0\0\0=
\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\265\22\0\0\0\0\0\370\265\262%4\0\=
0\0\370\265\262%4\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\=
0\0P\345td\4\0\0\0\250u\21\0\0\0\0\0\250u\221%4\0\0\0\250u\221%4\0\0\0D@\=
0\0\0\0\0\0D@\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\7\4\0\0\360\0\0\0\0\1\0\0\16\0\0\0\0\0\0@\0\200\203\200\225\1\22\=
264\3\31\200l\0\32\0 \5\201\0\240\3\2B\0\200\21R \0\22\0\0\16P\20#\10\216=
\334\30\211\"\0\10 \200\3B\220@\0\1\206\20\30\2\3\21\203$!\312A0\224Y\200=
\27\0\242\26\10\24R@\10\200\220\20A\10\0\220\1\200\206\2\10\304\30i\0\220=
\1\1\202\200\22\20\0\n\1H\0\n\2001J \6\31@L\207\20\10\0000\10(\200\2\0\4\=
251t\"\262\310!\212\240\320\"\0\t"..., 832) =3D 832
26287 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2839671, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D2480, st_size=3D1262384, st_atime=3D2012/10/09-12:04:35, st_mtime=3D=
2012/09/11-12:45:05, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26287 mmap(0x3425800000, 3363648, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425800000
26287 mprotect(0x342592c000, 2093056, PROT_NONE) =3D 0
26287 mmap(0x3425b2b000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x12b000) =3D 0x3425b2b000
26287 mmap(0x3425b34000, 4928, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3425b34000
26287 close(3)                          =3D 0
26287 open("/lib64/libresolv.so.2", O_RDONLY) =3D 3
26287 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\2402\0'4\0\=
0\0@\0\0\0\0\0\0\0@a\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\5\0=
\0\0@\0\0\0\0\0\0\0@\0\0'4\0\0\0@\0\0'4\0\0\0\370\1\0\0\0\0\0\0\370\1\0\0=
\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \361\0\0\0\0\0\0 \361\0'4\0\0\0=
 \361\0'4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\=
0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0'4\0\0\0\0\0\0'4\0\0\0$\10\1\0\0\0\0\0$\10=
\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\24\1\0\0\0\0\0\340\24!'4\=
0\0\0\340\24!'4\0\0\0\340\r\0\0\0\0\0\0\0106\0\0\0\0\0\0\0\0 \0\0\0\0\0\2=
\0\0\0\6\0\0\0\350\35\1\0\0\0\0\0\350\35!'4\0\0\0\350\35!'4\0\0\0\300\1\0=
\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\=
0\0\0008\2\0'4\0\0\0008\2\0'4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0=
\0\0\0\0P\345td\4\0\0\0<\361\0\0\0\0\0\0<\361\0'4\0\0\0<\361\0'4\0\0\0,\3=
\0\0\0\0\0\0,\3\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 8=
32
26287 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148119, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D192, st_size=3D92736, st_atime=3D2012/10/09-11:16:43, st_mtime=3D201=
0/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:42}) =3D 0
26287 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f2da8f06000
26287 mmap(0x3427000000, 2181864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3427000000
26287 mprotect(0x3427011000, 2097152, PROT_NONE) =3D 0
26287 mmap(0x3427211000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x11000) =3D 0x3427211000
26287 mmap(0x3427213000, 6888, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3427213000
26287 close(3)                          =3D 0
26287 open("/lib64/libnsl.so.1", O_RDONLY) =3D 3
26287 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240@\340\35=
10\0\0\0@\0\0\0\0\0\0\0\360\265\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0=
\6\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\340\3510\0\0\0@\0\340\3510\0\0\0\370\1=
\0\0\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \33\1\0\0=
\0\0\0 \33\341\3510\0\0\0 \33\341\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\=
0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\340\3510\0\0\0=
\0\0\340\3510\0\0\0\310@\1\0\0\0\0\0\310@\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\=
0\0\6\0\0\0xM\1\0\0\0\0\0xM\1\3520\0\0\0xM\1\3520\0\0\0\310\5\0\0\0\0\0\0=
008-\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250M\1\0\0\0\0\0\250M\1\3=
520\0\0\0\250M\1\3520\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\340\3510\0\0\0008\2\340\351=
0\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0<\33\=
1\0\0\0\0\0<\33\341\3510\0\0\0<\33\341\3510\0\0\0\\\5\0\0\0\0\0\0\\\5\0\0=
\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26287 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147206, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D232, st_size=3D114352, st_atime=3D2012/10/09-12:01:01, st_mtime=3D20=
10/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:44}) =3D 0
26287 mmap(0x30e9e00000, 2194096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9e00000
26287 mprotect(0x30e9e15000, 2093056, PROT_NONE) =3D 0
26287 mmap(0x30ea014000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x14000) =3D 0x30ea014000
26287 mmap(0x30ea016000, 6832, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x30ea016000
26287 close(3)                          =3D 0
26287 open("/lib64/libdl.so.2", O_RDONLY) =3D 3
26287 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\16`\3500=
\0\0\0@\0\0\0\0\0\0\0@R\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0`\3500\0\0\0@\0`\3500\0\0\0\370\1\0\0\0\0\0\0\37=
0\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\300\32\0\0\0\0\0\0\300\3=
2`\3500\0\0\0\300\32`\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0`\3500\0\0\0\0\0`\3500\0\0\=
0\224\37\0\0\0\0\0\0\224\37\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0`-\=
0\0\0\0\0\0`-\200\3500\0\0\0`-\200\3500\0\0\0 \3\0\0\0\0\0\0\240\3\0\0\0\=
0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\240-\0\0\0\0\0\0\240-\200\3500\0\0\0=
\240-\200\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0=
\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2`\3500\0\0\0008\2`\3500\0\0\0 \0\0\=
0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\334\32\0\0\0\0\0\=
0\334\32`\3500\0\0\0\334\32`\3500\0\0\0\264\0\0\0\0\0\0\0\264\0\0\0\0\0\0=
\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26287 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147322, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D48, st_size=3D23360, st_atime=3D2012/10/09-11:13:54, st_mtime=3D2010=
/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26287 mmap(0x30e8600000, 2109696, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8600000
26287 mprotect(0x30e8602000, 2097152, PROT_NONE) =3D 0
26287 mmap(0x30e8802000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x2000) =3D 0x30e8802000
26287 close(3)                          =3D 0
26287 open("/lib64/libm.so.6", O_RDONLY) =3D 3
26287 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`>\240\3510\=
0\0\0@\0\0\0\0\0\0\0\240X\t\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0)\0(\0\6\0\0\=
0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3510\0\0\0@\0\240\3510\0\0\0\370\1\0\0\0\=
0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\360\303\7\0\0\0\=
0\0\360\303\247\3510\0\0\0\360\303\247\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0=
\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3510\=
0\0\0\0\0\240\3510\0\0\0000\22\10\0\0\0\0\0000\22\10\0\0\0\0\0\0\0 \0\0\0=
\0\0\1\0\0\0\6\0\0\0\270\35\10\0\0\0\0\0\270\35\310\3510\0\0\0\270\35\310=
\3510\0\0\0\320\2\0\0\0\0\0\0 \3\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0=
\0\350\35\10\0\0\0\0\0\350\35\310\3510\0\0\0\350\35\310\3510\0\0\0\300\1\=
0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0=
\0\0\0008\2\240\3510\0\0\0008\2\240\3510\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\f\304\7\0\0\0\0\0\f\304\247\3510\0\0\0=
\f\304\247\3510\0\0\0\374\r\0\0\0\0\0\0\374\r\0\0\0\0\0\0\4\0\0\0\0\0\0\0=
Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0"..., 832) =3D 832
26287 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147337, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D1216, st_size=3D615136, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2=
010/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26287 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f2da8f05000
26287 mmap(0x30e9a00000, 2629848, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9a00000
26287 mprotect(0x30e9a82000, 2093056, PROT_NONE) =3D 0
26287 mmap(0x30e9c81000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x81000) =3D 0x30e9c81000
26287 close(3)                          =3D 0
26287 open("/lib64/libcrypt.so.1", O_RDONLY) =3D 3
26287 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\t\300%4=
\0\0\0@\0\0\0\0\0\0\0\30\265\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\=
0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\300%4\0\0\0@\0\300%4\0\0\0\370\1\0\0\0\0\=
0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340}\0\0\0\0\0\0\3=
40}\300%4\0\0\0\340}\300%4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\300%4\0\0\0\0\0\300%4\0\0\=
0\4\205\0\0\0\0\0\0\4\205\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\310\=
215\0\0\0\0\0\0\310\215\340%4\0\0\0\310\215\340%4\0\0\0\250\2\0\0\0\0\0\0=
\370\343\2\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\215\0\0\0\0\0\0\3=
70\215\340%4\0\0\0\370\215\340%4\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\=
0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\300%4\0\0\0008\2=
\300%4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0=
\374}\0\0\0\0\0\0\374}\300%4\0\0\0\374}\300%4\0\0\0\34\1\0\0\0\0\0\0\34\1=
\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26287 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148123, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D96, st_size=3D48600, st_atime=3D2012/10/09-12:01:01, st_mtime=3D2010=
/07/28-03:52:39, st_ctime=3D2012/09/11-14:53:52}) =3D 0
26287 mmap(0x3425c00000, 2322880, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425c00000
26287 mprotect(0x3425c09000, 2093056, PROT_NONE) =3D 0
26287 mmap(0x3425e08000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x8000) =3D 0x3425e08000
26287 mmap(0x3425e0a000, 184768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FI=
XED|MAP_ANONYMOUS, -1, 0) =3D 0x3425e0a000
26287 close(3)                          =3D 0
26287 open("/lib64/libutil.so.1", O_RDONLY) =3D 3
26287 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\16\0(4\=
0\0\0@\0\0\0\0\0\0\0(>\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0\0(4\0\0\0@\0\0(4\0\0\0\370\1\0\0\0\0\0\0\370\1\=
0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340\26\0\0\0\0\0\0\340\26\0(=
4\0\0\0\340\26\0(4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0=
\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0(4\0\0\0\0\0\0(4\0\0\0P\32\0\0\0\=
0\0\0P\32\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\35\0\0\0\0\0\0\3=
40\35 (4\0\0\0\340\35 (4\0\0\0 \3\0\0\0\0\0\0000\3\0\0\0\0\0\0\0\0 \0\0\0=
\0\0\2\0\0\0\6\0\0\0\20\36\0\0\0\0\0\0\20\36 (4\0\0\0\20\36 (4\0\0\0\300\=
1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0=
\0\0\0\0008\2\0(4\0\0\0008\2\0(4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\=
0\0\0\0\0\0P\345td\4\0\0\0\374\26\0\0\0\0\0\0\374\26\0(4\0\0\0\374\26\0(4=
\0\0\0D\0\0\0\0\0\0\0D\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8=
32) =3D 832
26287 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147063, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D40, st_size=3D18152, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2010=
/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:49}) =3D 0
26287 mmap(0x3428000000, 2105616, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3428000000
26287 mprotect(0x3428002000, 2093056, PROT_NONE) =3D 0
26287 mmap(0x3428201000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x1000) =3D 0x3428201000
26287 close(3)                          =3D 0
26287 open("/lib64/libpthread.so.0", O_RDONLY) =3D 3
26287 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240W\240\35=
00\0\0\0@\0\0\0\0\0\0\0\340/\2\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0'\0&\0\6\0=
\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3500\0\0\0@\0\240\3500\0\0\0\370\1\0\0=
\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\240\t\1\0\0\0=
\0\0\240\t\241\3500\0\0\0\240\t\241\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\=
0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3500\0\0=
\0\0\0\240\3500\0\0\0pZ\1\0\0\0\0\0pZ\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\=
6\0\0\0\270[\1\0\0\0\0\0\270[\301\3500\0\0\0\270[\301\3500\0\0\0\230\6\0\=
0\0\0\0\0\270G\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250]\1\0\0\0\0\=
0\250]\301\3500\0\0\0\250]\301\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0=
\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\240\3500\0\0\=
0008\2\240\3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345t=
d\4\0\0\0\274\t\1\0\0\0\0\0\274\t\241\3500\0\0\0\274\t\241\3500\0\0\0\344=
\t\0\0\0\0\0\0\344\t\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =
=3D 832
26287 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147328, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D296, st_size=3D145824, st_atime=3D2012/10/09-11:16:43, st_mtime=3D20=
10/07/28-03:52:41, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26287 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f2da8f04000
26287 mmap(0x30e8a00000, 2204528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8a00000
26287 mprotect(0x30e8a16000, 2093056, PROT_NONE) =3D 0
26287 mmap(0x30e8c15000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x15000) =3D 0x30e8c15000
26287 mmap(0x30e8c17000, 13168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8c17000
26287 close(3)                          =3D 0
26287 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26287 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26287 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26287 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26287 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26287 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26287 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26287 close(3)                          =3D 0
26287 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f2da8f03000
26287 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f2da8f02000
26287 arch_prctl(ARCH_SET_FS, 0x7f2da8f026e0) =3D 0
26287 mprotect(0x3427211000, 4096, PROT_READ) =3D 0
26287 mprotect(0x30ea014000, 4096, PROT_READ) =3D 0
26287 mprotect(0x30e8802000, 4096, PROT_READ) =3D 0
26287 mprotect(0x30e9c81000, 4096, PROT_READ) =3D 0
26287 mprotect(0x3425e08000, 4096, PROT_READ) =3D 0
26287 mprotect(0x3428201000, 4096, PROT_READ) =3D 0
26287 mprotect(0x30e8c15000, 4096, PROT_READ) =3D 0
26287 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26287 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26287 munmap(0x7f2da8f07000, 103979)    =3D 0
26287 set_tid_address(0x7f2da8f02770)   =3D 26287
26287 set_robust_list(0x7f2da8f02780, 0x18) =3D 0
26287 futex(0x7fffb5e6783c, FUTEX_WAKE_PRIVATE, 1) =3D 0
26287 rt_sigaction(SIGRTMIN, {0x30e8a05380, [], SA_RESTORER|SA_SIGINFO, 0=
x30e8a0eb10}, NULL, 8) =3D 0
26287 rt_sigaction(SIGRT_1, {0x30e8a052b0, [], SA_RESTORER|SA_RESTART|SA_=
SIGINFO, 0x30e8a0eb10}, NULL, 8) =3D 0
26287 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) =3D 0
26287 getrlimit(RLIMIT_STACK, {rlim_cur=3D8192*1024, rlim_max=3DRLIM_INFI=
NITY}) =3D 0
26287 rt_sigaction(SIGFPE, {0x1, [FPE], SA_RESTORER|SA_RESTART, 0x30e8230=
2d0}, {SIG_DFL, [], 0}, 8) =3D 0
26287 brk(0)                            =3D 0x16fd000
26287 brk(0x171f000)                    =3D 0x171f000
26287 getuid()                          =3D 0
26287 geteuid()                         =3D 0
26287 getgid()                          =3D 0
26287 getegid()                         =3D 0
26287 mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,=
 -1, 0) =3D 0x7f2da8ee1000
26287 open("/dev/urandom", O_RDONLY)    =3D 3
26287 read(3, "\37z\37{", 4)            =3D 4
26287 close(3)                          =3D 0
26287 stat("/usr/lib64/perl5/site_perl/5.8.7/x86_64-linux-thread-multi", =
0x7fffb5e674f0) =3D -1 ENOENT (No such file or directory)
26287 stat("/usr/lib/perl5/site_perl/5.8.7", 0x7fffb5e674f0) =3D -1 ENOEN=
T (No such file or directory)
26287 stat("/usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi", =
0x7fffb5e674f0) =3D -1 ENOENT (No such file or directory)
26287 stat("/usr/lib/perl5/site_perl/5.8.6", 0x7fffb5e674f0) =3D -1 ENOEN=
T (No such file or directory)
26287 stat("/usr/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi", =
0x7fffb5e674f0) =3D -1 ENOENT (No such file or directory)
26287 stat("/usr/lib/perl5/site_perl/5.8.5", 0x7fffb5e674f0) =3D -1 ENOEN=
T (No such file or directory)
26287 stat("/usr/lib64/perl5/vendor_perl/5.8.7/x86_64-linux-thread-multi"=
, 0x7fffb5e674f0) =3D -1 ENOENT (No such file or directory)
26287 stat("/usr/lib/perl5/vendor_perl/5.8.7", 0x7fffb5e674f0) =3D -1 ENO=
ENT (No such file or directory)
26287 stat("/usr/lib64/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi"=
, 0x7fffb5e674f0) =3D -1 ENOENT (No such file or directory)
26287 stat("/usr/lib/perl5/vendor_perl/5.8.6", 0x7fffb5e674f0) =3D -1 ENO=
ENT (No such file or directory)
26287 stat("/usr/lib64/perl5/vendor_perl/5.8.5/x86_64-linux-thread-multi"=
, 0x7fffb5e674f0) =3D -1 ENOENT (No such file or directory)
26287 stat("/usr/lib/perl5/vendor_perl/5.8.5", 0x7fffb5e674f0) =3D -1 ENO=
ENT (No such file or directory)
26287 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffb5e672b0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26287 lseek(0, 0, SEEK_CUR)             =3D 0
26287 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffb5e672b0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26287 lseek(1, 0, SEEK_CUR)             =3D -1 ESPIPE (Illegal seek)
26287 ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffb5e672c0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26287 lseek(2, 0, SEEK_CUR)             =3D 593659497
26287 open("/dev/null", O_RDONLY)       =3D 3
26287 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffb5e673c0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26287 lseek(3, 0, SEEK_CUR)             =3D 0
26287 fcntl(3, F_SETFD, FD_CLOEXEC)     =3D 0
26287 fstat(3, {st_dev=3Dmakedev(0, 16), st_ino=3D584, st_mode=3DS_IFCHR|=
0666, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
0, st_rdev=3Dmakedev(1, 3), st_atime=3D2012/10/08-11:13:26, st_mtime=3D20=
12/10/08-11:13:26, st_ctime=3D2012/10/08-11:13:27}) =3D 0
26287 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) =3D 0
26287 readlink("/proc/self/exe", "/usr/bin/perl"..., 4095) =3D 13
26287 brk(0x1740000)                    =3D 0x1740000
26287 close(3)                          =3D 0
26287 dup(200)                          =3D 3
26287 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffb5e67290) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26287 lseek(3, 0, SEEK_CUR)             =3D 0
26287 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26287 dup2(3, 0)                        =3D 0
26287 close(3)                          =3D 0
26287 fcntl(0, F_SETFD, 0)              =3D 0
26287 fstat(0, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26287 stat("/var/run/xen-hotplug/block", {st_dev=3Dmakedev(8, 2), st_ino=3D=
2801738, st_mode=3DS_IFREG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st=
_blksize=3D4096, st_blocks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:=
24, st_mtime=3D2012/10/09-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D =
0
26287 exit_group(0)                     =3D ?
27813 <... read resumed> "", 128)       =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], WNOHANG, NUL=
L) =3D 26287
27813 wait4(-1, 0x7fffb0100a64, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0)                   =3D 0
27813 close(3)                          =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 write(2, "+ rightfile=3D\n", 13)    =3D 13
27813 write(2, "+ '[' x =3D xy ']'\n", 17) =3D 17
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ true\n", 7)           =3D 7
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ eval 'exec 200>>/var/run/xen-hotplug/block'\n", 46) =3D=
 46
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 write(2, "++ exec\n", 8)          =3D 8
27813 open("/var/run/xen-hotplug/block", O_WRONLY|O_CREAT|O_APPEND, 0666)=
 =3D 3
27813 fcntl(200, F_GETFD)               =3D 0
27813 fcntl(200, F_DUPFD, 10)           =3D 10
27813 fcntl(200, F_GETFD)               =3D 0
27813 dup2(3, 200)                      =3D 200
27813 close(3)                          =3D 0
27813 dup2(10, 200)                     =3D 200
27813 fcntl(10, F_GETFD)                =3D 0
27813 close(10)                         =3D 0
27813 write(2, "+ flock -x 200\n", 15)  =3D 15
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [INT CHLD], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [INT CHLD], NULL, 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26288
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26288 close(255 
27813 rt_sigprocmask(SIG_BLOCK, [CHLD],  
26288 <... close resumed> )             =3D 0
27813 <... rt_sigprocmask resumed> [], 8) =3D 0
26288 rt_sigprocmask(SIG_SETMASK, [],  
27813 rt_sigprocmask(SIG_SETMASK, [],  
26288 <... rt_sigprocmask resumed> NULL, 8) =3D 0
27813 <... rt_sigprocmask resumed> NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD],  
26288 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 <... rt_sigprocmask resumed> [], 8) =3D 0
26288 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0},  
26288 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 <... rt_sigaction resumed> {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}=
, 8) =3D 0
26288 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
27813 wait4(-1,  
26288 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26288 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26288 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26288 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26288 execve("/usr/bin/flock", ["flock", "-x", "200"], ["SUBSYSTEM=3Dxen-=
backend", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D=
/usr/bin:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:=
/usr/sbin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dx=
en-backend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3D=
backend/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "S=
HLVL=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/flock"]) =3D 0=

26288 brk(0)                            =3D 0x22d3000
26288 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f6874a70000
26288 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f6874a6f000
26288 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26288 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26288 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26288 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7f6874a55000=

26288 close(3)                          =3D 0
26288 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26288 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26288 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26288 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26288 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26288 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26288 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26288 close(3)                          =3D 0
26288 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f6874a54000
26288 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f6874a53000
26288 arch_prctl(ARCH_SET_FS, 0x7f6874a536e0) =3D 0
26288 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26288 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26288 munmap(0x7f6874a55000, 103979)    =3D 0
26288 flock(200, LOCK_EX)               =3D 0
26288 exit_group(0)                     =3D ?
27813 <... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], 0,=
 NULL) =3D 26288
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, 0x7fffb0100a24, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0xffffffffffffffff)  =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 pipe([3, 4])                      =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26289
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {0=
x436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26289 close(255 
27813 close(4 
26289 <... close resumed> )             =3D 0
27813 <... close resumed> )             =3D 0
27813 read(3,  
26289 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26289 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26289 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26289 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26289 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26289 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26289 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26289 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {S=
IG_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26289 rt_sigaction(SIGINT, {0x4481f0, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26289 dup2(4, 1)                        =3D 1
26289 close(4)                          =3D 0
26289 close(3)                          =3D 0
26289 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26289 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26289 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26289 write(2, "++ perl -e '\n            open STDIN, \"<&200\" or die $!=
;\n            my $fd_inum =3D (stat STDIN)[1]; die $! unless defined $fd=
_inum;\n            my $file_inum =3D (stat $ARGV[0])[1];\n            pr=
int \"y\\n\" if $fd_inum eq $file_inum;\n", 230) =3D 230
26289 write(2, "                             ' /var/run/xen-hotplug/block=
\n", 58) =3D 58
26289 stat(".", {st_dev=3Dmakedev(8, 2), st_ino=3D2, st_mode=3DS_IFDIR|07=
55, st_nlink=3D24, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
8, st_size=3D4096, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2012/10/08-=
11:13:38, st_ctime=3D2012/10/08-11:13:38}) =3D 0
26289 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26289 access("/usr/bin/perl", X_OK)     =3D 0
26289 access("/usr/bin/perl", R_OK)     =3D 0
26289 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26289 access("/usr/bin/perl", X_OK)     =3D 0
26289 access("/usr/bin/perl", R_OK)     =3D 0
26289 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
481f0, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26289 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26289 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26289 execve("/usr/bin/perl", ["perl", "-e", "\n            open STDIN, \=
"<&200\" or die $!;\n            my $fd_inum =3D (stat STDIN)[1]; die $! =
unless defined $fd_inum;\n            my $file_inum =3D (stat $ARGV[0])[1=
];\n            print \"y\\n\" if $fd_inum eq $file_inum;\n              =
               ", "/var/run/xen-hotplug/block"], ["SUBSYSTEM=3Dxen-backen=
d", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D/usr/b=
in:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:/usr/s=
bin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dxen-bac=
kend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3Dback=
end/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "SHLVL=
=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/perl"]) =3D 0
26289 brk(0)                            =3D 0xf52000
26289 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f8e69db2000
26289 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f8e69db1000
26289 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26289 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64/libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26289 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64", 0x7fffd8ac45f0) =3D -1 ENOENT (No such file or directory)
26289 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/lib=
perl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26289 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls", 0=
x7fffd8ac45f0) =3D -1 ENOENT (No such file or directory)
26289 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64/=
libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26289 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64"=
, 0x7fffd8ac45f0) =3D -1 ENOENT (No such file or directory)
26289 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl=
=2Eso", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26289 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE", 0x7ff=
fd8ac45f0) =3D -1 ENOENT (No such file or directory)
26289 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26289 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26289 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7f8e69d97000=

26289 close(3)                          =3D 0
26289 open("/usr/lib64/libperl.so", O_RDONLY) =3D 3
26289 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\34\203%=
4\0\0\0@\0\0\0\0\0\0\0\360;\23\0\0\0\0\0\0\0\0\0@\0008\0\5\0@\0\35\0\34\0=
\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\200%4\0\0\0\0\0\200%4\0\0\0T\260\22\=
0\0\0\0\0T\260\22\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0X\260\22\0\0\0\=
0\0X\260\262%4\0\0\0X\260\262%4\0\0\0\250\201\0\0\0\0\0\0\350\242\0\0\0\0=
\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\265\22\0\0\0\0\0\370\265\262%4\0\=
0\0\370\265\262%4\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\=
0\0P\345td\4\0\0\0\250u\21\0\0\0\0\0\250u\221%4\0\0\0\250u\221%4\0\0\0D@\=
0\0\0\0\0\0D@\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\7\4\0\0\360\0\0\0\0\1\0\0\16\0\0\0\0\0\0@\0\200\203\200\225\1\22\=
264\3\31\200l\0\32\0 \5\201\0\240\3\2B\0\200\21R \0\22\0\0\16P\20#\10\216=
\334\30\211\"\0\10 \200\3B\220@\0\1\206\20\30\2\3\21\203$!\312A0\224Y\200=
\27\0\242\26\10\24R@\10\200\220\20A\10\0\220\1\200\206\2\10\304\30i\0\220=
\1\1\202\200\22\20\0\n\1H\0\n\2001J \6\31@L\207\20\10\0000\10(\200\2\0\4\=
251t\"\262\310!\212\240\320\"\0\t"..., 832) =3D 832
26289 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2839671, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D2480, st_size=3D1262384, st_atime=3D2012/10/09-12:04:35, st_mtime=3D=
2012/09/11-12:45:05, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26289 mmap(0x3425800000, 3363648, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425800000
26289 mprotect(0x342592c000, 2093056, PROT_NONE) =3D 0
26289 mmap(0x3425b2b000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x12b000) =3D 0x3425b2b000
26289 mmap(0x3425b34000, 4928, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3425b34000
26289 close(3)                          =3D 0
26289 open("/lib64/libresolv.so.2", O_RDONLY) =3D 3
26289 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\2402\0'4\0\=
0\0@\0\0\0\0\0\0\0@a\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\5\0=
\0\0@\0\0\0\0\0\0\0@\0\0'4\0\0\0@\0\0'4\0\0\0\370\1\0\0\0\0\0\0\370\1\0\0=
\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \361\0\0\0\0\0\0 \361\0'4\0\0\0=
 \361\0'4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\=
0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0'4\0\0\0\0\0\0'4\0\0\0$\10\1\0\0\0\0\0$\10=
\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\24\1\0\0\0\0\0\340\24!'4\=
0\0\0\340\24!'4\0\0\0\340\r\0\0\0\0\0\0\0106\0\0\0\0\0\0\0\0 \0\0\0\0\0\2=
\0\0\0\6\0\0\0\350\35\1\0\0\0\0\0\350\35!'4\0\0\0\350\35!'4\0\0\0\300\1\0=
\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\=
0\0\0008\2\0'4\0\0\0008\2\0'4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0=
\0\0\0\0P\345td\4\0\0\0<\361\0\0\0\0\0\0<\361\0'4\0\0\0<\361\0'4\0\0\0,\3=
\0\0\0\0\0\0,\3\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 8=
32
26289 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148119, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D192, st_size=3D92736, st_atime=3D2012/10/09-11:16:43, st_mtime=3D201=
0/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:42}) =3D 0
26289 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f8e69d96000
26289 mmap(0x3427000000, 2181864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3427000000
26289 mprotect(0x3427011000, 2097152, PROT_NONE) =3D 0
26289 mmap(0x3427211000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x11000) =3D 0x3427211000
26289 mmap(0x3427213000, 6888, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3427213000
26289 close(3)                          =3D 0
26289 open("/lib64/libnsl.so.1", O_RDONLY) =3D 3
26289 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240@\340\35=
10\0\0\0@\0\0\0\0\0\0\0\360\265\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0=
\6\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\340\3510\0\0\0@\0\340\3510\0\0\0\370\1=
\0\0\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \33\1\0\0=
\0\0\0 \33\341\3510\0\0\0 \33\341\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\=
0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\340\3510\0\0\0=
\0\0\340\3510\0\0\0\310@\1\0\0\0\0\0\310@\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\=
0\0\6\0\0\0xM\1\0\0\0\0\0xM\1\3520\0\0\0xM\1\3520\0\0\0\310\5\0\0\0\0\0\0=
008-\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250M\1\0\0\0\0\0\250M\1\3=
520\0\0\0\250M\1\3520\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\340\3510\0\0\0008\2\340\351=
0\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0<\33\=
1\0\0\0\0\0<\33\341\3510\0\0\0<\33\341\3510\0\0\0\\\5\0\0\0\0\0\0\\\5\0\0=
\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26289 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147206, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D232, st_size=3D114352, st_atime=3D2012/10/09-12:01:01, st_mtime=3D20=
10/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:44}) =3D 0
26289 mmap(0x30e9e00000, 2194096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9e00000
26289 mprotect(0x30e9e15000, 2093056, PROT_NONE) =3D 0
26289 mmap(0x30ea014000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x14000) =3D 0x30ea014000
26289 mmap(0x30ea016000, 6832, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x30ea016000
26289 close(3)                          =3D 0
26289 open("/lib64/libdl.so.2", O_RDONLY) =3D 3
26289 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\16`\3500=
\0\0\0@\0\0\0\0\0\0\0@R\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0`\3500\0\0\0@\0`\3500\0\0\0\370\1\0\0\0\0\0\0\37=
0\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\300\32\0\0\0\0\0\0\300\3=
2`\3500\0\0\0\300\32`\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0`\3500\0\0\0\0\0`\3500\0\0\=
0\224\37\0\0\0\0\0\0\224\37\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0`-\=
0\0\0\0\0\0`-\200\3500\0\0\0`-\200\3500\0\0\0 \3\0\0\0\0\0\0\240\3\0\0\0\=
0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\240-\0\0\0\0\0\0\240-\200\3500\0\0\0=
\240-\200\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0=
\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2`\3500\0\0\0008\2`\3500\0\0\0 \0\0\=
0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\334\32\0\0\0\0\0\=
0\334\32`\3500\0\0\0\334\32`\3500\0\0\0\264\0\0\0\0\0\0\0\264\0\0\0\0\0\0=
\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26289 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147322, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D48, st_size=3D23360, st_atime=3D2012/10/09-11:13:54, st_mtime=3D2010=
/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26289 mmap(0x30e8600000, 2109696, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8600000
26289 mprotect(0x30e8602000, 2097152, PROT_NONE) =3D 0
26289 mmap(0x30e8802000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x2000) =3D 0x30e8802000
26289 close(3)                          =3D 0
26289 open("/lib64/libm.so.6", O_RDONLY) =3D 3
26289 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`>\240\3510\=
0\0\0@\0\0\0\0\0\0\0\240X\t\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0)\0(\0\6\0\0\=
0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3510\0\0\0@\0\240\3510\0\0\0\370\1\0\0\0\=
0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\360\303\7\0\0\0\=
0\0\360\303\247\3510\0\0\0\360\303\247\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0=
\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3510\=
0\0\0\0\0\240\3510\0\0\0000\22\10\0\0\0\0\0000\22\10\0\0\0\0\0\0\0 \0\0\0=
\0\0\1\0\0\0\6\0\0\0\270\35\10\0\0\0\0\0\270\35\310\3510\0\0\0\270\35\310=
\3510\0\0\0\320\2\0\0\0\0\0\0 \3\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0=
\0\350\35\10\0\0\0\0\0\350\35\310\3510\0\0\0\350\35\310\3510\0\0\0\300\1\=
0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0=
\0\0\0008\2\240\3510\0\0\0008\2\240\3510\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\f\304\7\0\0\0\0\0\f\304\247\3510\0\0\0=
\f\304\247\3510\0\0\0\374\r\0\0\0\0\0\0\374\r\0\0\0\0\0\0\4\0\0\0\0\0\0\0=
Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0"..., 832) =3D 832
26289 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147337, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D1216, st_size=3D615136, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2=
010/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26289 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f8e69d95000
26289 mmap(0x30e9a00000, 2629848, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9a00000
26289 mprotect(0x30e9a82000, 2093056, PROT_NONE) =3D 0
26289 mmap(0x30e9c81000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x81000) =3D 0x30e9c81000
26289 close(3)                          =3D 0
26289 open("/lib64/libcrypt.so.1", O_RDONLY) =3D 3
26289 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\t\300%4=
\0\0\0@\0\0\0\0\0\0\0\30\265\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\=
0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\300%4\0\0\0@\0\300%4\0\0\0\370\1\0\0\0\0\=
0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340}\0\0\0\0\0\0\3=
40}\300%4\0\0\0\340}\300%4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\300%4\0\0\0\0\0\300%4\0\0\=
0\4\205\0\0\0\0\0\0\4\205\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\310\=
215\0\0\0\0\0\0\310\215\340%4\0\0\0\310\215\340%4\0\0\0\250\2\0\0\0\0\0\0=
\370\343\2\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\215\0\0\0\0\0\0\3=
70\215\340%4\0\0\0\370\215\340%4\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\=
0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\300%4\0\0\0008\2=
\300%4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0=
\374}\0\0\0\0\0\0\374}\300%4\0\0\0\374}\300%4\0\0\0\34\1\0\0\0\0\0\0\34\1=
\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26289 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148123, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D96, st_size=3D48600, st_atime=3D2012/10/09-12:01:01, st_mtime=3D2010=
/07/28-03:52:39, st_ctime=3D2012/09/11-14:53:52}) =3D 0
26289 mmap(0x3425c00000, 2322880, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425c00000
26289 mprotect(0x3425c09000, 2093056, PROT_NONE) =3D 0
26289 mmap(0x3425e08000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x8000) =3D 0x3425e08000
26289 mmap(0x3425e0a000, 184768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FI=
XED|MAP_ANONYMOUS, -1, 0) =3D 0x3425e0a000
26289 close(3)                          =3D 0
26289 open("/lib64/libutil.so.1", O_RDONLY) =3D 3
26289 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\16\0(4\=
0\0\0@\0\0\0\0\0\0\0(>\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0\0(4\0\0\0@\0\0(4\0\0\0\370\1\0\0\0\0\0\0\370\1\=
0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340\26\0\0\0\0\0\0\340\26\0(=
4\0\0\0\340\26\0(4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0=
\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0(4\0\0\0\0\0\0(4\0\0\0P\32\0\0\0\=
0\0\0P\32\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\35\0\0\0\0\0\0\3=
40\35 (4\0\0\0\340\35 (4\0\0\0 \3\0\0\0\0\0\0000\3\0\0\0\0\0\0\0\0 \0\0\0=
\0\0\2\0\0\0\6\0\0\0\20\36\0\0\0\0\0\0\20\36 (4\0\0\0\20\36 (4\0\0\0\300\=
1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0=
\0\0\0\0008\2\0(4\0\0\0008\2\0(4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\=
0\0\0\0\0\0P\345td\4\0\0\0\374\26\0\0\0\0\0\0\374\26\0(4\0\0\0\374\26\0(4=
\0\0\0D\0\0\0\0\0\0\0D\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8=
32) =3D 832
26289 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147063, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D40, st_size=3D18152, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2010=
/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:49}) =3D 0
26289 mmap(0x3428000000, 2105616, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3428000000
26289 mprotect(0x3428002000, 2093056, PROT_NONE) =3D 0
26289 mmap(0x3428201000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x1000) =3D 0x3428201000
26289 close(3)                          =3D 0
26289 open("/lib64/libpthread.so.0", O_RDONLY) =3D 3
26289 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240W\240\35=
00\0\0\0@\0\0\0\0\0\0\0\340/\2\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0'\0&\0\6\0=
\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3500\0\0\0@\0\240\3500\0\0\0\370\1\0\0=
\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\240\t\1\0\0\0=
\0\0\240\t\241\3500\0\0\0\240\t\241\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\=
0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3500\0\0=
\0\0\0\240\3500\0\0\0pZ\1\0\0\0\0\0pZ\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\=
6\0\0\0\270[\1\0\0\0\0\0\270[\301\3500\0\0\0\270[\301\3500\0\0\0\230\6\0\=
0\0\0\0\0\270G\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250]\1\0\0\0\0\=
0\250]\301\3500\0\0\0\250]\301\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0=
\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\240\3500\0\0\=
0008\2\240\3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345t=
d\4\0\0\0\274\t\1\0\0\0\0\0\274\t\241\3500\0\0\0\274\t\241\3500\0\0\0\344=
\t\0\0\0\0\0\0\344\t\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =
=3D 832
26289 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147328, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D296, st_size=3D145824, st_atime=3D2012/10/09-11:16:43, st_mtime=3D20=
10/07/28-03:52:41, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26289 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f8e69d94000
26289 mmap(0x30e8a00000, 2204528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8a00000
26289 mprotect(0x30e8a16000, 2093056, PROT_NONE) =3D 0
26289 mmap(0x30e8c15000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x15000) =3D 0x30e8c15000
26289 mmap(0x30e8c17000, 13168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8c17000
26289 close(3)                          =3D 0
26289 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26289 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26289 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26289 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26289 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26289 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26289 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26289 close(3)                          =3D 0
26289 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f8e69d93000
26289 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f8e69d92000
26289 arch_prctl(ARCH_SET_FS, 0x7f8e69d926e0) =3D 0
26289 mprotect(0x3427211000, 4096, PROT_READ) =3D 0
26289 mprotect(0x30ea014000, 4096, PROT_READ) =3D 0
26289 mprotect(0x30e8802000, 4096, PROT_READ) =3D 0
26289 mprotect(0x30e9c81000, 4096, PROT_READ) =3D 0
26289 mprotect(0x3425e08000, 4096, PROT_READ) =3D 0
26289 mprotect(0x3428201000, 4096, PROT_READ) =3D 0
26289 mprotect(0x30e8c15000, 4096, PROT_READ) =3D 0
26289 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26289 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26289 munmap(0x7f8e69d97000, 103979)    =3D 0
26289 set_tid_address(0x7f8e69d92770)   =3D 26289
26289 set_robust_list(0x7f8e69d92780, 0x18) =3D 0
26289 futex(0x7fffd8ac511c, FUTEX_WAKE_PRIVATE, 1) =3D 0
26289 rt_sigaction(SIGRTMIN, {0x30e8a05380, [], SA_RESTORER|SA_SIGINFO, 0=
x30e8a0eb10}, NULL, 8) =3D 0
26289 rt_sigaction(SIGRT_1, {0x30e8a052b0, [], SA_RESTORER|SA_RESTART|SA_=
SIGINFO, 0x30e8a0eb10}, NULL, 8) =3D 0
26289 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) =3D 0
26289 getrlimit(RLIMIT_STACK, {rlim_cur=3D8192*1024, rlim_max=3DRLIM_INFI=
NITY}) =3D 0
26289 rt_sigaction(SIGFPE, {0x1, [FPE], SA_RESTORER|SA_RESTART, 0x30e8230=
2d0}, {SIG_DFL, [], 0}, 8) =3D 0
26289 brk(0)                            =3D 0xf52000
26289 brk(0xf74000)                     =3D 0xf74000
26289 getuid()                          =3D 0
26289 geteuid()                         =3D 0
26289 getgid()                          =3D 0
26289 getegid()                         =3D 0
26289 mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,=
 -1, 0) =3D 0x7f8e69d71000
26289 open("/dev/urandom", O_RDONLY)    =3D 3
26289 read(3, "\340\re*", 4)            =3D 4
26289 close(3)                          =3D 0
26289 stat("/usr/lib64/perl5/site_perl/5.8.7/x86_64-linux-thread-multi", =
0x7fffd8ac4dd0) =3D -1 ENOENT (No such file or directory)
26289 stat("/usr/lib/perl5/site_perl/5.8.7", 0x7fffd8ac4dd0) =3D -1 ENOEN=
T (No such file or directory)
26289 stat("/usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi", =
0x7fffd8ac4dd0) =3D -1 ENOENT (No such file or directory)
26289 stat("/usr/lib/perl5/site_perl/5.8.6", 0x7fffd8ac4dd0) =3D -1 ENOEN=
T (No such file or directory)
26289 stat("/usr/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi", =
0x7fffd8ac4dd0) =3D -1 ENOENT (No such file or directory)
26289 stat("/usr/lib/perl5/site_perl/5.8.5", 0x7fffd8ac4dd0) =3D -1 ENOEN=
T (No such file or directory)
26289 stat("/usr/lib64/perl5/vendor_perl/5.8.7/x86_64-linux-thread-multi"=
, 0x7fffd8ac4dd0) =3D -1 ENOENT (No such file or directory)
26289 stat("/usr/lib/perl5/vendor_perl/5.8.7", 0x7fffd8ac4dd0) =3D -1 ENO=
ENT (No such file or directory)
26289 stat("/usr/lib64/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi"=
, 0x7fffd8ac4dd0) =3D -1 ENOENT (No such file or directory)
26289 stat("/usr/lib/perl5/vendor_perl/5.8.6", 0x7fffd8ac4dd0) =3D -1 ENO=
ENT (No such file or directory)
26289 stat("/usr/lib64/perl5/vendor_perl/5.8.5/x86_64-linux-thread-multi"=
, 0x7fffd8ac4dd0) =3D -1 ENOENT (No such file or directory)
26289 stat("/usr/lib/perl5/vendor_perl/5.8.5", 0x7fffd8ac4dd0) =3D -1 ENO=
ENT (No such file or directory)
26289 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffd8ac4b90) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26289 lseek(0, 0, SEEK_CUR)             =3D 0
26289 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffd8ac4b90) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26289 lseek(1, 0, SEEK_CUR)             =3D -1 ESPIPE (Illegal seek)
26289 ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffd8ac4ba0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26289 lseek(2, 0, SEEK_CUR)             =3D 593659891
26289 open("/dev/null", O_RDONLY)       =3D 3
26289 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffd8ac4ca0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26289 lseek(3, 0, SEEK_CUR)             =3D 0
26289 fcntl(3, F_SETFD, FD_CLOEXEC)     =3D 0
26289 fstat(3, {st_dev=3Dmakedev(0, 16), st_ino=3D584, st_mode=3DS_IFCHR|=
0666, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
0, st_rdev=3Dmakedev(1, 3), st_atime=3D2012/10/08-11:13:26, st_mtime=3D20=
12/10/08-11:13:26, st_ctime=3D2012/10/08-11:13:27}) =3D 0
26289 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) =3D 0
26289 readlink("/proc/self/exe", "/usr/bin/perl"..., 4095) =3D 13
26289 brk(0xf95000)                     =3D 0xf95000
26289 close(3)                          =3D 0
26289 dup(200)                          =3D 3
26289 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffd8ac4b70) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26289 lseek(3, 0, SEEK_CUR)             =3D 0
26289 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26289 dup2(3, 0)                        =3D 0
26289 close(3)                          =3D 0
26289 fcntl(0, F_SETFD, 0)              =3D 0
26289 fstat(0, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26289 stat("/var/run/xen-hotplug/block", {st_dev=3Dmakedev(8, 2), st_ino=3D=
2801738, st_mode=3DS_IFREG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st=
_blksize=3D4096, st_blocks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:=
24, st_mtime=3D2012/10/09-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D =
0
26289 exit_group(0)                     =3D ?
27813 <... read resumed> "", 128)       =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], WNOHANG, NUL=
L) =3D 26289
27813 wait4(-1, 0x7fffb0100a64, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0)                   =3D 0
27813 close(3)                          =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 write(2, "+ rightfile=3D\n", 13)    =3D 13
27813 write(2, "+ '[' x =3D xy ']'\n", 17) =3D 17
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ true\n", 7)           =3D 7
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ eval 'exec 200>>/var/run/xen-hotplug/block'\n", 46) =3D=
 46
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 write(2, "++ exec\n", 8)          =3D 8
27813 open("/var/run/xen-hotplug/block", O_WRONLY|O_CREAT|O_APPEND, 0666)=
 =3D 3
27813 fcntl(200, F_GETFD)               =3D 0
27813 fcntl(200, F_DUPFD, 10)           =3D 10
27813 fcntl(200, F_GETFD)               =3D 0
27813 dup2(3, 200)                      =3D 200
27813 close(3)                          =3D 0
27813 dup2(10, 200)                     =3D 200
27813 fcntl(10, F_GETFD)                =3D 0
27813 close(10)                         =3D 0
27813 write(2, "+ flock -x 200\n", 15)  =3D 15
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [INT CHLD], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [INT CHLD], NULL, 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26290
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26290 close(255 
27813 rt_sigprocmask(SIG_BLOCK, [CHLD],  
26290 <... close resumed> )             =3D 0
27813 <... rt_sigprocmask resumed> [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [],  
26290 rt_sigprocmask(SIG_SETMASK, [],  
27813 <... rt_sigprocmask resumed> NULL, 8) =3D 0
26290 <... rt_sigprocmask resumed> NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
26290 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0},  
26290 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
27813 <... rt_sigaction resumed> {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}=
, 8) =3D 0
26290 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 wait4(-1,  
26290 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
26290 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26290 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26290 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26290 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26290 execve("/usr/bin/flock", ["flock", "-x", "200"], ["SUBSYSTEM=3Dxen-=
backend", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D=
/usr/bin:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:=
/usr/sbin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dx=
en-backend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3D=
backend/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "S=
HLVL=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/flock"]) =3D 0=

26290 brk(0)                            =3D 0x1672000
26290 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f9f578cc000
26290 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f9f578cb000
26290 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26290 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26290 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26290 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7f9f578b1000=

26290 close(3)                          =3D 0
26290 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26290 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26290 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26290 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26290 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26290 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26290 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26290 close(3)                          =3D 0
26290 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f9f578b0000
26290 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f9f578af000
26290 arch_prctl(ARCH_SET_FS, 0x7f9f578af6e0) =3D 0
26290 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26290 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26290 munmap(0x7f9f578b1000, 103979)    =3D 0
26290 flock(200, LOCK_EX)               =3D 0
26290 exit_group(0)                     =3D ?
27813 <... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], 0,=
 NULL) =3D 26290
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, 0x7fffb0100a24, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0xffffffffffffffff)  =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 pipe([3, 4])                      =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26291
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {0=
x436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26291 close(255 
27813 close(4 
26291 <... close resumed> )             =3D 0
27813 <... close resumed> )             =3D 0
27813 read(3,  
26291 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26291 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26291 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26291 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26291 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26291 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26291 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26291 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {S=
IG_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26291 rt_sigaction(SIGINT, {0x4481f0, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26291 dup2(4, 1)                        =3D 1
26291 close(4)                          =3D 0
26291 close(3)                          =3D 0
26291 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26291 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26291 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26291 write(2, "++ perl -e '\n            open STDIN, \"<&200\" or die $!=
;\n            my $fd_inum =3D (stat STDIN)[1]; die $! unless defined $fd=
_inum;\n            my $file_inum =3D (stat $ARGV[0])[1];\n            pr=
int \"y\\n\" if $fd_inum eq $file_inum;\n", 230) =3D 230
26291 write(2, "                             ' /var/run/xen-hotplug/block=
\n", 58) =3D 58
26291 stat(".", {st_dev=3Dmakedev(8, 2), st_ino=3D2, st_mode=3DS_IFDIR|07=
55, st_nlink=3D24, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
8, st_size=3D4096, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2012/10/08-=
11:13:38, st_ctime=3D2012/10/08-11:13:38}) =3D 0
26291 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26291 access("/usr/bin/perl", X_OK)     =3D 0
26291 access("/usr/bin/perl", R_OK)     =3D 0
26291 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26291 access("/usr/bin/perl", X_OK)     =3D 0
26291 access("/usr/bin/perl", R_OK)     =3D 0
26291 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
481f0, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26291 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26291 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26291 execve("/usr/bin/perl", ["perl", "-e", "\n            open STDIN, \=
"<&200\" or die $!;\n            my $fd_inum =3D (stat STDIN)[1]; die $! =
unless defined $fd_inum;\n            my $file_inum =3D (stat $ARGV[0])[1=
];\n            print \"y\\n\" if $fd_inum eq $file_inum;\n              =
               ", "/var/run/xen-hotplug/block"], ["SUBSYSTEM=3Dxen-backen=
d", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D/usr/b=
in:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:/usr/s=
bin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dxen-bac=
kend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3Dback=
end/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "SHLVL=
=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/perl"]) =3D 0
26291 brk(0)                            =3D 0x1cbc000
26291 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f2692cc7000
26291 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f2692cc6000
26291 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26291 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64/libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26291 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64", 0x7fffcf663710) =3D -1 ENOENT (No such file or directory)
26291 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/lib=
perl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26291 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls", 0=
x7fffcf663710) =3D -1 ENOENT (No such file or directory)
26291 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64/=
libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26291 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64"=
, 0x7fffcf663710) =3D -1 ENOENT (No such file or directory)
26291 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl=
=2Eso", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26291 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE", 0x7ff=
fcf663710) =3D -1 ENOENT (No such file or directory)
26291 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26291 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26291 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7f2692cac000=

26291 close(3)                          =3D 0
26291 open("/usr/lib64/libperl.so", O_RDONLY) =3D 3
26291 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\34\203%=
4\0\0\0@\0\0\0\0\0\0\0\360;\23\0\0\0\0\0\0\0\0\0@\0008\0\5\0@\0\35\0\34\0=
\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\200%4\0\0\0\0\0\200%4\0\0\0T\260\22\=
0\0\0\0\0T\260\22\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0X\260\22\0\0\0\=
0\0X\260\262%4\0\0\0X\260\262%4\0\0\0\250\201\0\0\0\0\0\0\350\242\0\0\0\0=
\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\265\22\0\0\0\0\0\370\265\262%4\0\=
0\0\370\265\262%4\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\=
0\0P\345td\4\0\0\0\250u\21\0\0\0\0\0\250u\221%4\0\0\0\250u\221%4\0\0\0D@\=
0\0\0\0\0\0D@\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\7\4\0\0\360\0\0\0\0\1\0\0\16\0\0\0\0\0\0@\0\200\203\200\225\1\22\=
264\3\31\200l\0\32\0 \5\201\0\240\3\2B\0\200\21R \0\22\0\0\16P\20#\10\216=
\334\30\211\"\0\10 \200\3B\220@\0\1\206\20\30\2\3\21\203$!\312A0\224Y\200=
\27\0\242\26\10\24R@\10\200\220\20A\10\0\220\1\200\206\2\10\304\30i\0\220=
\1\1\202\200\22\20\0\n\1H\0\n\2001J \6\31@L\207\20\10\0000\10(\200\2\0\4\=
251t\"\262\310!\212\240\320\"\0\t"..., 832) =3D 832
26291 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2839671, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D2480, st_size=3D1262384, st_atime=3D2012/10/09-12:04:35, st_mtime=3D=
2012/09/11-12:45:05, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26291 mmap(0x3425800000, 3363648, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425800000
26291 mprotect(0x342592c000, 2093056, PROT_NONE) =3D 0
26291 mmap(0x3425b2b000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x12b000) =3D 0x3425b2b000
26291 mmap(0x3425b34000, 4928, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3425b34000
26291 close(3)                          =3D 0
26291 open("/lib64/libresolv.so.2", O_RDONLY) =3D 3
26291 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\2402\0'4\0\=
0\0@\0\0\0\0\0\0\0@a\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\5\0=
\0\0@\0\0\0\0\0\0\0@\0\0'4\0\0\0@\0\0'4\0\0\0\370\1\0\0\0\0\0\0\370\1\0\0=
\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \361\0\0\0\0\0\0 \361\0'4\0\0\0=
 \361\0'4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\=
0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0'4\0\0\0\0\0\0'4\0\0\0$\10\1\0\0\0\0\0$\10=
\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\24\1\0\0\0\0\0\340\24!'4\=
0\0\0\340\24!'4\0\0\0\340\r\0\0\0\0\0\0\0106\0\0\0\0\0\0\0\0 \0\0\0\0\0\2=
\0\0\0\6\0\0\0\350\35\1\0\0\0\0\0\350\35!'4\0\0\0\350\35!'4\0\0\0\300\1\0=
\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\=
0\0\0008\2\0'4\0\0\0008\2\0'4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0=
\0\0\0\0P\345td\4\0\0\0<\361\0\0\0\0\0\0<\361\0'4\0\0\0<\361\0'4\0\0\0,\3=
\0\0\0\0\0\0,\3\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 8=
32
26291 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148119, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D192, st_size=3D92736, st_atime=3D2012/10/09-11:16:43, st_mtime=3D201=
0/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:42}) =3D 0
26291 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f2692cab000
26291 mmap(0x3427000000, 2181864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3427000000
26291 mprotect(0x3427011000, 2097152, PROT_NONE) =3D 0
26291 mmap(0x3427211000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x11000) =3D 0x3427211000
26291 mmap(0x3427213000, 6888, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3427213000
26291 close(3)                          =3D 0
26291 open("/lib64/libnsl.so.1", O_RDONLY) =3D 3
26291 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240@\340\35=
10\0\0\0@\0\0\0\0\0\0\0\360\265\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0=
\6\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\340\3510\0\0\0@\0\340\3510\0\0\0\370\1=
\0\0\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \33\1\0\0=
\0\0\0 \33\341\3510\0\0\0 \33\341\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\=
0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\340\3510\0\0\0=
\0\0\340\3510\0\0\0\310@\1\0\0\0\0\0\310@\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\=
0\0\6\0\0\0xM\1\0\0\0\0\0xM\1\3520\0\0\0xM\1\3520\0\0\0\310\5\0\0\0\0\0\0=
008-\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250M\1\0\0\0\0\0\250M\1\3=
520\0\0\0\250M\1\3520\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\340\3510\0\0\0008\2\340\351=
0\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0<\33\=
1\0\0\0\0\0<\33\341\3510\0\0\0<\33\341\3510\0\0\0\\\5\0\0\0\0\0\0\\\5\0\0=
\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26291 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147206, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D232, st_size=3D114352, st_atime=3D2012/10/09-12:01:01, st_mtime=3D20=
10/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:44}) =3D 0
26291 mmap(0x30e9e00000, 2194096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9e00000
26291 mprotect(0x30e9e15000, 2093056, PROT_NONE) =3D 0
26291 mmap(0x30ea014000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x14000) =3D 0x30ea014000
26291 mmap(0x30ea016000, 6832, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x30ea016000
26291 close(3)                          =3D 0
26291 open("/lib64/libdl.so.2", O_RDONLY) =3D 3
26291 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\16`\3500=
\0\0\0@\0\0\0\0\0\0\0@R\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0`\3500\0\0\0@\0`\3500\0\0\0\370\1\0\0\0\0\0\0\37=
0\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\300\32\0\0\0\0\0\0\300\3=
2`\3500\0\0\0\300\32`\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0`\3500\0\0\0\0\0`\3500\0\0\=
0\224\37\0\0\0\0\0\0\224\37\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0`-\=
0\0\0\0\0\0`-\200\3500\0\0\0`-\200\3500\0\0\0 \3\0\0\0\0\0\0\240\3\0\0\0\=
0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\240-\0\0\0\0\0\0\240-\200\3500\0\0\0=
\240-\200\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0=
\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2`\3500\0\0\0008\2`\3500\0\0\0 \0\0\=
0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\334\32\0\0\0\0\0\=
0\334\32`\3500\0\0\0\334\32`\3500\0\0\0\264\0\0\0\0\0\0\0\264\0\0\0\0\0\0=
\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26291 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147322, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D48, st_size=3D23360, st_atime=3D2012/10/09-11:13:54, st_mtime=3D2010=
/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26291 mmap(0x30e8600000, 2109696, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8600000
26291 mprotect(0x30e8602000, 2097152, PROT_NONE) =3D 0
26291 mmap(0x30e8802000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x2000) =3D 0x30e8802000
26291 close(3)                          =3D 0
26291 open("/lib64/libm.so.6", O_RDONLY) =3D 3
26291 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`>\240\3510\=
0\0\0@\0\0\0\0\0\0\0\240X\t\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0)\0(\0\6\0\0\=
0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3510\0\0\0@\0\240\3510\0\0\0\370\1\0\0\0\=
0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\360\303\7\0\0\0\=
0\0\360\303\247\3510\0\0\0\360\303\247\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0=
\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3510\=
0\0\0\0\0\240\3510\0\0\0000\22\10\0\0\0\0\0000\22\10\0\0\0\0\0\0\0 \0\0\0=
\0\0\1\0\0\0\6\0\0\0\270\35\10\0\0\0\0\0\270\35\310\3510\0\0\0\270\35\310=
\3510\0\0\0\320\2\0\0\0\0\0\0 \3\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0=
\0\350\35\10\0\0\0\0\0\350\35\310\3510\0\0\0\350\35\310\3510\0\0\0\300\1\=
0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0=
\0\0\0008\2\240\3510\0\0\0008\2\240\3510\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\f\304\7\0\0\0\0\0\f\304\247\3510\0\0\0=
\f\304\247\3510\0\0\0\374\r\0\0\0\0\0\0\374\r\0\0\0\0\0\0\4\0\0\0\0\0\0\0=
Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0"..., 832) =3D 832
26291 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147337, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D1216, st_size=3D615136, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2=
010/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26291 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f2692caa000
26291 mmap(0x30e9a00000, 2629848, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9a00000
26291 mprotect(0x30e9a82000, 2093056, PROT_NONE) =3D 0
26291 mmap(0x30e9c81000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x81000) =3D 0x30e9c81000
26291 close(3)                          =3D 0
26291 open("/lib64/libcrypt.so.1", O_RDONLY) =3D 3
26291 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\t\300%4=
\0\0\0@\0\0\0\0\0\0\0\30\265\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\=
0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\300%4\0\0\0@\0\300%4\0\0\0\370\1\0\0\0\0\=
0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340}\0\0\0\0\0\0\3=
40}\300%4\0\0\0\340}\300%4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\300%4\0\0\0\0\0\300%4\0\0\=
0\4\205\0\0\0\0\0\0\4\205\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\310\=
215\0\0\0\0\0\0\310\215\340%4\0\0\0\310\215\340%4\0\0\0\250\2\0\0\0\0\0\0=
\370\343\2\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\215\0\0\0\0\0\0\3=
70\215\340%4\0\0\0\370\215\340%4\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\=
0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\300%4\0\0\0008\2=
\300%4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0=
\374}\0\0\0\0\0\0\374}\300%4\0\0\0\374}\300%4\0\0\0\34\1\0\0\0\0\0\0\34\1=
\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26291 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148123, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D96, st_size=3D48600, st_atime=3D2012/10/09-12:01:01, st_mtime=3D2010=
/07/28-03:52:39, st_ctime=3D2012/09/11-14:53:52}) =3D 0
26291 mmap(0x3425c00000, 2322880, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425c00000
26291 mprotect(0x3425c09000, 2093056, PROT_NONE) =3D 0
26291 mmap(0x3425e08000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x8000) =3D 0x3425e08000
26291 mmap(0x3425e0a000, 184768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FI=
XED|MAP_ANONYMOUS, -1, 0) =3D 0x3425e0a000
26291 close(3)                          =3D 0
26291 open("/lib64/libutil.so.1", O_RDONLY) =3D 3
26291 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\16\0(4\=
0\0\0@\0\0\0\0\0\0\0(>\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0\0(4\0\0\0@\0\0(4\0\0\0\370\1\0\0\0\0\0\0\370\1\=
0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340\26\0\0\0\0\0\0\340\26\0(=
4\0\0\0\340\26\0(4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0=
\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0(4\0\0\0\0\0\0(4\0\0\0P\32\0\0\0\=
0\0\0P\32\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\35\0\0\0\0\0\0\3=
40\35 (4\0\0\0\340\35 (4\0\0\0 \3\0\0\0\0\0\0000\3\0\0\0\0\0\0\0\0 \0\0\0=
\0\0\2\0\0\0\6\0\0\0\20\36\0\0\0\0\0\0\20\36 (4\0\0\0\20\36 (4\0\0\0\300\=
1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0=
\0\0\0\0008\2\0(4\0\0\0008\2\0(4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\=
0\0\0\0\0\0P\345td\4\0\0\0\374\26\0\0\0\0\0\0\374\26\0(4\0\0\0\374\26\0(4=
\0\0\0D\0\0\0\0\0\0\0D\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8=
32) =3D 832
26291 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147063, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D40, st_size=3D18152, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2010=
/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:49}) =3D 0
26291 mmap(0x3428000000, 2105616, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3428000000
26291 mprotect(0x3428002000, 2093056, PROT_NONE) =3D 0
26291 mmap(0x3428201000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x1000) =3D 0x3428201000
26291 close(3)                          =3D 0
26291 open("/lib64/libpthread.so.0", O_RDONLY) =3D 3
26291 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240W\240\35=
00\0\0\0@\0\0\0\0\0\0\0\340/\2\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0'\0&\0\6\0=
\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3500\0\0\0@\0\240\3500\0\0\0\370\1\0\0=
\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\240\t\1\0\0\0=
\0\0\240\t\241\3500\0\0\0\240\t\241\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\=
0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3500\0\0=
\0\0\0\240\3500\0\0\0pZ\1\0\0\0\0\0pZ\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\=
6\0\0\0\270[\1\0\0\0\0\0\270[\301\3500\0\0\0\270[\301\3500\0\0\0\230\6\0\=
0\0\0\0\0\270G\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250]\1\0\0\0\0\=
0\250]\301\3500\0\0\0\250]\301\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0=
\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\240\3500\0\0\=
0008\2\240\3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345t=
d\4\0\0\0\274\t\1\0\0\0\0\0\274\t\241\3500\0\0\0\274\t\241\3500\0\0\0\344=
\t\0\0\0\0\0\0\344\t\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =
=3D 832
26291 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147328, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D296, st_size=3D145824, st_atime=3D2012/10/09-11:16:43, st_mtime=3D20=
10/07/28-03:52:41, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26291 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f2692ca9000
26291 mmap(0x30e8a00000, 2204528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8a00000
26291 mprotect(0x30e8a16000, 2093056, PROT_NONE) =3D 0
26291 mmap(0x30e8c15000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x15000) =3D 0x30e8c15000
26291 mmap(0x30e8c17000, 13168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8c17000
26291 close(3)                          =3D 0
26291 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26291 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26291 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26291 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26291 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26291 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26291 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26291 close(3)                          =3D 0
26291 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f2692ca8000
26291 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f2692ca7000
26291 arch_prctl(ARCH_SET_FS, 0x7f2692ca76e0) =3D 0
26291 mprotect(0x3427211000, 4096, PROT_READ) =3D 0
26291 mprotect(0x30ea014000, 4096, PROT_READ) =3D 0
26291 mprotect(0x30e8802000, 4096, PROT_READ) =3D 0
26291 mprotect(0x30e9c81000, 4096, PROT_READ) =3D 0
26291 mprotect(0x3425e08000, 4096, PROT_READ) =3D 0
26291 mprotect(0x3428201000, 4096, PROT_READ) =3D 0
26291 mprotect(0x30e8c15000, 4096, PROT_READ) =3D 0
26291 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26291 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26291 munmap(0x7f2692cac000, 103979)    =3D 0
26291 set_tid_address(0x7f2692ca7770)   =3D 26291
26291 set_robust_list(0x7f2692ca7780, 0x18) =3D 0
26291 futex(0x7fffcf66423c, FUTEX_WAKE_PRIVATE, 1) =3D 0
26291 rt_sigaction(SIGRTMIN, {0x30e8a05380, [], SA_RESTORER|SA_SIGINFO, 0=
x30e8a0eb10}, NULL, 8) =3D 0
26291 rt_sigaction(SIGRT_1, {0x30e8a052b0, [], SA_RESTORER|SA_RESTART|SA_=
SIGINFO, 0x30e8a0eb10}, NULL, 8) =3D 0
26291 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) =3D 0
26291 getrlimit(RLIMIT_STACK, {rlim_cur=3D8192*1024, rlim_max=3DRLIM_INFI=
NITY}) =3D 0
26291 rt_sigaction(SIGFPE, {0x1, [FPE], SA_RESTORER|SA_RESTART, 0x30e8230=
2d0}, {SIG_DFL, [], 0}, 8) =3D 0
26291 brk(0)                            =3D 0x1cbc000
26291 brk(0x1cde000)                    =3D 0x1cde000
26291 getuid()                          =3D 0
26291 geteuid()                         =3D 0
26291 getgid()                          =3D 0
26291 getegid()                         =3D 0
26291 mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,=
 -1, 0) =3D 0x7f2692c86000
26291 open("/dev/urandom", O_RDONLY)    =3D 3
26291 read(3, "\317\226\355\210", 4)    =3D 4
26291 close(3)                          =3D 0
26291 stat("/usr/lib64/perl5/site_perl/5.8.7/x86_64-linux-thread-multi", =
0x7fffcf663ef0) =3D -1 ENOENT (No such file or directory)
26291 stat("/usr/lib/perl5/site_perl/5.8.7", 0x7fffcf663ef0) =3D -1 ENOEN=
T (No such file or directory)
26291 stat("/usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi", =
0x7fffcf663ef0) =3D -1 ENOENT (No such file or directory)
26291 stat("/usr/lib/perl5/site_perl/5.8.6", 0x7fffcf663ef0) =3D -1 ENOEN=
T (No such file or directory)
26291 stat("/usr/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi", =
0x7fffcf663ef0) =3D -1 ENOENT (No such file or directory)
26291 stat("/usr/lib/perl5/site_perl/5.8.5", 0x7fffcf663ef0) =3D -1 ENOEN=
T (No such file or directory)
26291 stat("/usr/lib64/perl5/vendor_perl/5.8.7/x86_64-linux-thread-multi"=
, 0x7fffcf663ef0) =3D -1 ENOENT (No such file or directory)
26291 stat("/usr/lib/perl5/vendor_perl/5.8.7", 0x7fffcf663ef0) =3D -1 ENO=
ENT (No such file or directory)
26291 stat("/usr/lib64/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi"=
, 0x7fffcf663ef0) =3D -1 ENOENT (No such file or directory)
26291 stat("/usr/lib/perl5/vendor_perl/5.8.6", 0x7fffcf663ef0) =3D -1 ENO=
ENT (No such file or directory)
26291 stat("/usr/lib64/perl5/vendor_perl/5.8.5/x86_64-linux-thread-multi"=
, 0x7fffcf663ef0) =3D -1 ENOENT (No such file or directory)
26291 stat("/usr/lib/perl5/vendor_perl/5.8.5", 0x7fffcf663ef0) =3D -1 ENO=
ENT (No such file or directory)
26291 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffcf663cb0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26291 lseek(0, 0, SEEK_CUR)             =3D 0
26291 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffcf663cb0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26291 lseek(1, 0, SEEK_CUR)             =3D -1 ESPIPE (Illegal seek)
26291 ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffcf663cc0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26291 lseek(2, 0, SEEK_CUR)             =3D 593660285
26291 open("/dev/null", O_RDONLY)       =3D 3
26291 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffcf663dc0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26291 lseek(3, 0, SEEK_CUR)             =3D 0
26291 fcntl(3, F_SETFD, FD_CLOEXEC)     =3D 0
26291 fstat(3, {st_dev=3Dmakedev(0, 16), st_ino=3D584, st_mode=3DS_IFCHR|=
0666, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
0, st_rdev=3Dmakedev(1, 3), st_atime=3D2012/10/08-11:13:26, st_mtime=3D20=
12/10/08-11:13:26, st_ctime=3D2012/10/08-11:13:27}) =3D 0
26291 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) =3D 0
26291 readlink("/proc/self/exe", "/usr/bin/perl"..., 4095) =3D 13
26291 brk(0x1cff000)                    =3D 0x1cff000
26291 close(3)                          =3D 0
26291 dup(200)                          =3D 3
26291 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffcf663c90) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26291 lseek(3, 0, SEEK_CUR)             =3D 0
26291 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26291 dup2(3, 0)                        =3D 0
26291 close(3)                          =3D 0
26291 fcntl(0, F_SETFD, 0)              =3D 0
26291 fstat(0, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26291 stat("/var/run/xen-hotplug/block", {st_dev=3Dmakedev(8, 2), st_ino=3D=
2801738, st_mode=3DS_IFREG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st=
_blksize=3D4096, st_blocks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:=
24, st_mtime=3D2012/10/09-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D =
0
26291 exit_group(0)                     =3D ?
27813 <... read resumed> "", 128)       =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], WNOHANG, NUL=
L) =3D 26291
27813 wait4(-1, 0x7fffb0100a64, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0)                   =3D 0
27813 close(3)                          =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 write(2, "+ rightfile=3D\n", 13)    =3D 13
27813 write(2, "+ '[' x =3D xy ']'\n", 17) =3D 17
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ true\n", 7)           =3D 7
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ eval 'exec 200>>/var/run/xen-hotplug/block'\n", 46) =3D=
 46
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 write(2, "++ exec\n", 8)          =3D 8
27813 open("/var/run/xen-hotplug/block", O_WRONLY|O_CREAT|O_APPEND, 0666)=
 =3D 3
27813 fcntl(200, F_GETFD)               =3D 0
27813 fcntl(200, F_DUPFD, 10)           =3D 10
27813 fcntl(200, F_GETFD)               =3D 0
27813 dup2(3, 200)                      =3D 200
27813 close(3)                          =3D 0
27813 dup2(10, 200)                     =3D 200
27813 fcntl(10, F_GETFD)                =3D 0
27813 close(10)                         =3D 0
27813 write(2, "+ flock -x 200\n", 15)  =3D 15
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [INT CHLD], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [INT CHLD], NULL, 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26292
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26292 close(255 
27813 rt_sigprocmask(SIG_BLOCK, [CHLD],  
26292 <... close resumed> )             =3D 0
27813 <... rt_sigprocmask resumed> [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [],  
26292 rt_sigprocmask(SIG_SETMASK, [],  
27813 <... rt_sigprocmask resumed> NULL, 8) =3D 0
26292 <... rt_sigprocmask resumed> NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
26292 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0},  
26292 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
27813 <... rt_sigaction resumed> {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}=
, 8) =3D 0
26292 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 wait4(-1,  
26292 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
26292 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26292 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26292 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26292 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26292 execve("/usr/bin/flock", ["flock", "-x", "200"], ["SUBSYSTEM=3Dxen-=
backend", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D=
/usr/bin:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:=
/usr/sbin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dx=
en-backend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3D=
backend/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "S=
HLVL=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/flock"]) =3D 0=

26292 brk(0)                            =3D 0xba0000
26292 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f1f1f9ee000
26292 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f1f1f9ed000
26292 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26292 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26292 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26292 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7f1f1f9d3000=

26292 close(3)                          =3D 0
26292 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26292 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26292 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26292 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26292 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26292 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26292 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26292 close(3)                          =3D 0
26292 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f1f1f9d2000
26292 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f1f1f9d1000
26292 arch_prctl(ARCH_SET_FS, 0x7f1f1f9d16e0) =3D 0
26292 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26292 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26292 munmap(0x7f1f1f9d3000, 103979)    =3D 0
26292 flock(200, LOCK_EX)               =3D 0
26292 exit_group(0)                     =3D ?
27813 <... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], 0,=
 NULL) =3D 26292
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, 0x7fffb0100a24, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0xffffffffffffffff)  =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 pipe([3, 4])                      =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26293
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {0=
x436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26293 close(255 
27813 close(4 
26293 <... close resumed> )             =3D 0
27813 <... close resumed> )             =3D 0
27813 read(3,  
26293 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26293 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26293 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26293 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26293 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26293 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26293 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26293 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {S=
IG_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26293 rt_sigaction(SIGINT, {0x4481f0, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26293 dup2(4, 1)                        =3D 1
26293 close(4)                          =3D 0
26293 close(3)                          =3D 0
26293 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26293 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26293 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26293 write(2, "++ perl -e '\n            open STDIN, \"<&200\" or die $!=
;\n            my $fd_inum =3D (stat STDIN)[1]; die $! unless defined $fd=
_inum;\n            my $file_inum =3D (stat $ARGV[0])[1];\n            pr=
int \"y\\n\" if $fd_inum eq $file_inum;\n", 230) =3D 230
26293 write(2, "                             ' /var/run/xen-hotplug/block=
\n", 58) =3D 58
26293 stat(".", {st_dev=3Dmakedev(8, 2), st_ino=3D2, st_mode=3DS_IFDIR|07=
55, st_nlink=3D24, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
8, st_size=3D4096, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2012/10/08-=
11:13:38, st_ctime=3D2012/10/08-11:13:38}) =3D 0
26293 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26293 access("/usr/bin/perl", X_OK)     =3D 0
26293 access("/usr/bin/perl", R_OK)     =3D 0
26293 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26293 access("/usr/bin/perl", X_OK)     =3D 0
26293 access("/usr/bin/perl", R_OK)     =3D 0
26293 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
481f0, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26293 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26293 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26293 execve("/usr/bin/perl", ["perl", "-e", "\n            open STDIN, \=
"<&200\" or die $!;\n            my $fd_inum =3D (stat STDIN)[1]; die $! =
unless defined $fd_inum;\n            my $file_inum =3D (stat $ARGV[0])[1=
];\n            print \"y\\n\" if $fd_inum eq $file_inum;\n              =
               ", "/var/run/xen-hotplug/block"], ["SUBSYSTEM=3Dxen-backen=
d", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D/usr/b=
in:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:/usr/s=
bin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dxen-bac=
kend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3Dback=
end/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "SHLVL=
=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/perl"]) =3D 0
26293 brk(0)                            =3D 0xef5000
26293 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f61c9c69000
26293 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f61c9c68000
26293 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26293 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64/libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26293 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64", 0x7fff9164f390) =3D -1 ENOENT (No such file or directory)
26293 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/lib=
perl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26293 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls", 0=
x7fff9164f390) =3D -1 ENOENT (No such file or directory)
26293 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64/=
libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26293 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64"=
, 0x7fff9164f390) =3D -1 ENOENT (No such file or directory)
26293 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl=
=2Eso", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26293 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE", 0x7ff=
f9164f390) =3D -1 ENOENT (No such file or directory)
26293 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26293 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26293 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7f61c9c4e000=

26293 close(3)                          =3D 0
26293 open("/usr/lib64/libperl.so", O_RDONLY) =3D 3
26293 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\34\203%=
4\0\0\0@\0\0\0\0\0\0\0\360;\23\0\0\0\0\0\0\0\0\0@\0008\0\5\0@\0\35\0\34\0=
\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\200%4\0\0\0\0\0\200%4\0\0\0T\260\22\=
0\0\0\0\0T\260\22\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0X\260\22\0\0\0\=
0\0X\260\262%4\0\0\0X\260\262%4\0\0\0\250\201\0\0\0\0\0\0\350\242\0\0\0\0=
\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\265\22\0\0\0\0\0\370\265\262%4\0\=
0\0\370\265\262%4\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\=
0\0P\345td\4\0\0\0\250u\21\0\0\0\0\0\250u\221%4\0\0\0\250u\221%4\0\0\0D@\=
0\0\0\0\0\0D@\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\7\4\0\0\360\0\0\0\0\1\0\0\16\0\0\0\0\0\0@\0\200\203\200\225\1\22\=
264\3\31\200l\0\32\0 \5\201\0\240\3\2B\0\200\21R \0\22\0\0\16P\20#\10\216=
\334\30\211\"\0\10 \200\3B\220@\0\1\206\20\30\2\3\21\203$!\312A0\224Y\200=
\27\0\242\26\10\24R@\10\200\220\20A\10\0\220\1\200\206\2\10\304\30i\0\220=
\1\1\202\200\22\20\0\n\1H\0\n\2001J \6\31@L\207\20\10\0000\10(\200\2\0\4\=
251t\"\262\310!\212\240\320\"\0\t"..., 832) =3D 832
26293 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2839671, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D2480, st_size=3D1262384, st_atime=3D2012/10/09-12:04:35, st_mtime=3D=
2012/09/11-12:45:05, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26293 mmap(0x3425800000, 3363648, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425800000
26293 mprotect(0x342592c000, 2093056, PROT_NONE) =3D 0
26293 mmap(0x3425b2b000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x12b000) =3D 0x3425b2b000
26293 mmap(0x3425b34000, 4928, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3425b34000
26293 close(3)                          =3D 0
26293 open("/lib64/libresolv.so.2", O_RDONLY) =3D 3
26293 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\2402\0'4\0\=
0\0@\0\0\0\0\0\0\0@a\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\5\0=
\0\0@\0\0\0\0\0\0\0@\0\0'4\0\0\0@\0\0'4\0\0\0\370\1\0\0\0\0\0\0\370\1\0\0=
\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \361\0\0\0\0\0\0 \361\0'4\0\0\0=
 \361\0'4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\=
0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0'4\0\0\0\0\0\0'4\0\0\0$\10\1\0\0\0\0\0$\10=
\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\24\1\0\0\0\0\0\340\24!'4\=
0\0\0\340\24!'4\0\0\0\340\r\0\0\0\0\0\0\0106\0\0\0\0\0\0\0\0 \0\0\0\0\0\2=
\0\0\0\6\0\0\0\350\35\1\0\0\0\0\0\350\35!'4\0\0\0\350\35!'4\0\0\0\300\1\0=
\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\=
0\0\0008\2\0'4\0\0\0008\2\0'4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0=
\0\0\0\0P\345td\4\0\0\0<\361\0\0\0\0\0\0<\361\0'4\0\0\0<\361\0'4\0\0\0,\3=
\0\0\0\0\0\0,\3\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 8=
32
26293 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148119, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D192, st_size=3D92736, st_atime=3D2012/10/09-11:16:43, st_mtime=3D201=
0/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:42}) =3D 0
26293 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f61c9c4d000
26293 mmap(0x3427000000, 2181864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3427000000
26293 mprotect(0x3427011000, 2097152, PROT_NONE) =3D 0
26293 mmap(0x3427211000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x11000) =3D 0x3427211000
26293 mmap(0x3427213000, 6888, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3427213000
26293 close(3)                          =3D 0
26293 open("/lib64/libnsl.so.1", O_RDONLY) =3D 3
26293 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240@\340\35=
10\0\0\0@\0\0\0\0\0\0\0\360\265\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0=
\6\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\340\3510\0\0\0@\0\340\3510\0\0\0\370\1=
\0\0\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \33\1\0\0=
\0\0\0 \33\341\3510\0\0\0 \33\341\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\=
0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\340\3510\0\0\0=
\0\0\340\3510\0\0\0\310@\1\0\0\0\0\0\310@\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\=
0\0\6\0\0\0xM\1\0\0\0\0\0xM\1\3520\0\0\0xM\1\3520\0\0\0\310\5\0\0\0\0\0\0=
008-\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250M\1\0\0\0\0\0\250M\1\3=
520\0\0\0\250M\1\3520\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\340\3510\0\0\0008\2\340\351=
0\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0<\33\=
1\0\0\0\0\0<\33\341\3510\0\0\0<\33\341\3510\0\0\0\\\5\0\0\0\0\0\0\\\5\0\0=
\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26293 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147206, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D232, st_size=3D114352, st_atime=3D2012/10/09-12:01:01, st_mtime=3D20=
10/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:44}) =3D 0
26293 mmap(0x30e9e00000, 2194096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9e00000
26293 mprotect(0x30e9e15000, 2093056, PROT_NONE) =3D 0
26293 mmap(0x30ea014000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x14000) =3D 0x30ea014000
26293 mmap(0x30ea016000, 6832, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x30ea016000
26293 close(3)                          =3D 0
26293 open("/lib64/libdl.so.2", O_RDONLY) =3D 3
26293 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\16`\3500=
\0\0\0@\0\0\0\0\0\0\0@R\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0`\3500\0\0\0@\0`\3500\0\0\0\370\1\0\0\0\0\0\0\37=
0\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\300\32\0\0\0\0\0\0\300\3=
2`\3500\0\0\0\300\32`\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0`\3500\0\0\0\0\0`\3500\0\0\=
0\224\37\0\0\0\0\0\0\224\37\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0`-\=
0\0\0\0\0\0`-\200\3500\0\0\0`-\200\3500\0\0\0 \3\0\0\0\0\0\0\240\3\0\0\0\=
0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\240-\0\0\0\0\0\0\240-\200\3500\0\0\0=
\240-\200\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0=
\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2`\3500\0\0\0008\2`\3500\0\0\0 \0\0\=
0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\334\32\0\0\0\0\0\=
0\334\32`\3500\0\0\0\334\32`\3500\0\0\0\264\0\0\0\0\0\0\0\264\0\0\0\0\0\0=
\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26293 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147322, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D48, st_size=3D23360, st_atime=3D2012/10/09-11:13:54, st_mtime=3D2010=
/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26293 mmap(0x30e8600000, 2109696, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8600000
26293 mprotect(0x30e8602000, 2097152, PROT_NONE) =3D 0
26293 mmap(0x30e8802000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x2000) =3D 0x30e8802000
26293 close(3)                          =3D 0
26293 open("/lib64/libm.so.6", O_RDONLY) =3D 3
26293 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`>\240\3510\=
0\0\0@\0\0\0\0\0\0\0\240X\t\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0)\0(\0\6\0\0\=
0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3510\0\0\0@\0\240\3510\0\0\0\370\1\0\0\0\=
0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\360\303\7\0\0\0\=
0\0\360\303\247\3510\0\0\0\360\303\247\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0=
\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3510\=
0\0\0\0\0\240\3510\0\0\0000\22\10\0\0\0\0\0000\22\10\0\0\0\0\0\0\0 \0\0\0=
\0\0\1\0\0\0\6\0\0\0\270\35\10\0\0\0\0\0\270\35\310\3510\0\0\0\270\35\310=
\3510\0\0\0\320\2\0\0\0\0\0\0 \3\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0=
\0\350\35\10\0\0\0\0\0\350\35\310\3510\0\0\0\350\35\310\3510\0\0\0\300\1\=
0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0=
\0\0\0008\2\240\3510\0\0\0008\2\240\3510\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\f\304\7\0\0\0\0\0\f\304\247\3510\0\0\0=
\f\304\247\3510\0\0\0\374\r\0\0\0\0\0\0\374\r\0\0\0\0\0\0\4\0\0\0\0\0\0\0=
Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0"..., 832) =3D 832
26293 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147337, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D1216, st_size=3D615136, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2=
010/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26293 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f61c9c4c000
26293 mmap(0x30e9a00000, 2629848, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9a00000
26293 mprotect(0x30e9a82000, 2093056, PROT_NONE) =3D 0
26293 mmap(0x30e9c81000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x81000) =3D 0x30e9c81000
26293 close(3)                          =3D 0
26293 open("/lib64/libcrypt.so.1", O_RDONLY) =3D 3
26293 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\t\300%4=
\0\0\0@\0\0\0\0\0\0\0\30\265\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\=
0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\300%4\0\0\0@\0\300%4\0\0\0\370\1\0\0\0\0\=
0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340}\0\0\0\0\0\0\3=
40}\300%4\0\0\0\340}\300%4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\300%4\0\0\0\0\0\300%4\0\0\=
0\4\205\0\0\0\0\0\0\4\205\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\310\=
215\0\0\0\0\0\0\310\215\340%4\0\0\0\310\215\340%4\0\0\0\250\2\0\0\0\0\0\0=
\370\343\2\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\215\0\0\0\0\0\0\3=
70\215\340%4\0\0\0\370\215\340%4\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\=
0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\300%4\0\0\0008\2=
\300%4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0=
\374}\0\0\0\0\0\0\374}\300%4\0\0\0\374}\300%4\0\0\0\34\1\0\0\0\0\0\0\34\1=
\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26293 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148123, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D96, st_size=3D48600, st_atime=3D2012/10/09-12:01:01, st_mtime=3D2010=
/07/28-03:52:39, st_ctime=3D2012/09/11-14:53:52}) =3D 0
26293 mmap(0x3425c00000, 2322880, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425c00000
26293 mprotect(0x3425c09000, 2093056, PROT_NONE) =3D 0
26293 mmap(0x3425e08000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x8000) =3D 0x3425e08000
26293 mmap(0x3425e0a000, 184768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FI=
XED|MAP_ANONYMOUS, -1, 0) =3D 0x3425e0a000
26293 close(3)                          =3D 0
26293 open("/lib64/libutil.so.1", O_RDONLY) =3D 3
26293 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\16\0(4\=
0\0\0@\0\0\0\0\0\0\0(>\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0\0(4\0\0\0@\0\0(4\0\0\0\370\1\0\0\0\0\0\0\370\1\=
0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340\26\0\0\0\0\0\0\340\26\0(=
4\0\0\0\340\26\0(4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0=
\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0(4\0\0\0\0\0\0(4\0\0\0P\32\0\0\0\=
0\0\0P\32\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\35\0\0\0\0\0\0\3=
40\35 (4\0\0\0\340\35 (4\0\0\0 \3\0\0\0\0\0\0000\3\0\0\0\0\0\0\0\0 \0\0\0=
\0\0\2\0\0\0\6\0\0\0\20\36\0\0\0\0\0\0\20\36 (4\0\0\0\20\36 (4\0\0\0\300\=
1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0=
\0\0\0\0008\2\0(4\0\0\0008\2\0(4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\=
0\0\0\0\0\0P\345td\4\0\0\0\374\26\0\0\0\0\0\0\374\26\0(4\0\0\0\374\26\0(4=
\0\0\0D\0\0\0\0\0\0\0D\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8=
32) =3D 832
26293 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147063, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D40, st_size=3D18152, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2010=
/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:49}) =3D 0
26293 mmap(0x3428000000, 2105616, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3428000000
26293 mprotect(0x3428002000, 2093056, PROT_NONE) =3D 0
26293 mmap(0x3428201000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x1000) =3D 0x3428201000
26293 close(3)                          =3D 0
26293 open("/lib64/libpthread.so.0", O_RDONLY) =3D 3
26293 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240W\240\35=
00\0\0\0@\0\0\0\0\0\0\0\340/\2\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0'\0&\0\6\0=
\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3500\0\0\0@\0\240\3500\0\0\0\370\1\0\0=
\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\240\t\1\0\0\0=
\0\0\240\t\241\3500\0\0\0\240\t\241\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\=
0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3500\0\0=
\0\0\0\240\3500\0\0\0pZ\1\0\0\0\0\0pZ\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\=
6\0\0\0\270[\1\0\0\0\0\0\270[\301\3500\0\0\0\270[\301\3500\0\0\0\230\6\0\=
0\0\0\0\0\270G\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250]\1\0\0\0\0\=
0\250]\301\3500\0\0\0\250]\301\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0=
\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\240\3500\0\0\=
0008\2\240\3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345t=
d\4\0\0\0\274\t\1\0\0\0\0\0\274\t\241\3500\0\0\0\274\t\241\3500\0\0\0\344=
\t\0\0\0\0\0\0\344\t\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =
=3D 832
26293 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147328, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D296, st_size=3D145824, st_atime=3D2012/10/09-11:16:43, st_mtime=3D20=
10/07/28-03:52:41, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26293 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f61c9c4b000
26293 mmap(0x30e8a00000, 2204528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8a00000
26293 mprotect(0x30e8a16000, 2093056, PROT_NONE) =3D 0
26293 mmap(0x30e8c15000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x15000) =3D 0x30e8c15000
26293 mmap(0x30e8c17000, 13168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8c17000
26293 close(3)                          =3D 0
26293 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26293 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26293 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26293 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26293 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26293 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26293 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26293 close(3)                          =3D 0
26293 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f61c9c4a000
26293 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f61c9c49000
26293 arch_prctl(ARCH_SET_FS, 0x7f61c9c496e0) =3D 0
26293 mprotect(0x3427211000, 4096, PROT_READ) =3D 0
26293 mprotect(0x30ea014000, 4096, PROT_READ) =3D 0
26293 mprotect(0x30e8802000, 4096, PROT_READ) =3D 0
26293 mprotect(0x30e9c81000, 4096, PROT_READ) =3D 0
26293 mprotect(0x3425e08000, 4096, PROT_READ) =3D 0
26293 mprotect(0x3428201000, 4096, PROT_READ) =3D 0
26293 mprotect(0x30e8c15000, 4096, PROT_READ) =3D 0
26293 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26293 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26293 munmap(0x7f61c9c4e000, 103979)    =3D 0
26293 set_tid_address(0x7f61c9c49770)   =3D 26293
26293 set_robust_list(0x7f61c9c49780, 0x18) =3D 0
26293 futex(0x7fff9164febc, FUTEX_WAKE_PRIVATE, 1) =3D 0
26293 rt_sigaction(SIGRTMIN, {0x30e8a05380, [], SA_RESTORER|SA_SIGINFO, 0=
x30e8a0eb10}, NULL, 8) =3D 0
26293 rt_sigaction(SIGRT_1, {0x30e8a052b0, [], SA_RESTORER|SA_RESTART|SA_=
SIGINFO, 0x30e8a0eb10}, NULL, 8) =3D 0
26293 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) =3D 0
26293 getrlimit(RLIMIT_STACK, {rlim_cur=3D8192*1024, rlim_max=3DRLIM_INFI=
NITY}) =3D 0
26293 rt_sigaction(SIGFPE, {0x1, [FPE], SA_RESTORER|SA_RESTART, 0x30e8230=
2d0}, {SIG_DFL, [], 0}, 8) =3D 0
26293 brk(0)                            =3D 0xef5000
26293 brk(0xf17000)                     =3D 0xf17000
26293 getuid()                          =3D 0
26293 geteuid()                         =3D 0
26293 getgid()                          =3D 0
26293 getegid()                         =3D 0
26293 mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,=
 -1, 0) =3D 0x7f61c9c28000
26293 open("/dev/urandom", O_RDONLY)    =3D 3
26293 read(3, "\2753\222B", 4)          =3D 4
26293 close(3)                          =3D 0
26293 stat("/usr/lib64/perl5/site_perl/5.8.7/x86_64-linux-thread-multi", =
0x7fff9164fb70) =3D -1 ENOENT (No such file or directory)
26293 stat("/usr/lib/perl5/site_perl/5.8.7", 0x7fff9164fb70) =3D -1 ENOEN=
T (No such file or directory)
26293 stat("/usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi", =
0x7fff9164fb70) =3D -1 ENOENT (No such file or directory)
26293 stat("/usr/lib/perl5/site_perl/5.8.6", 0x7fff9164fb70) =3D -1 ENOEN=
T (No such file or directory)
26293 stat("/usr/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi", =
0x7fff9164fb70) =3D -1 ENOENT (No such file or directory)
26293 stat("/usr/lib/perl5/site_perl/5.8.5", 0x7fff9164fb70) =3D -1 ENOEN=
T (No such file or directory)
26293 stat("/usr/lib64/perl5/vendor_perl/5.8.7/x86_64-linux-thread-multi"=
, 0x7fff9164fb70) =3D -1 ENOENT (No such file or directory)
26293 stat("/usr/lib/perl5/vendor_perl/5.8.7", 0x7fff9164fb70) =3D -1 ENO=
ENT (No such file or directory)
26293 stat("/usr/lib64/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi"=
, 0x7fff9164fb70) =3D -1 ENOENT (No such file or directory)
26293 stat("/usr/lib/perl5/vendor_perl/5.8.6", 0x7fff9164fb70) =3D -1 ENO=
ENT (No such file or directory)
26293 stat("/usr/lib64/perl5/vendor_perl/5.8.5/x86_64-linux-thread-multi"=
, 0x7fff9164fb70) =3D -1 ENOENT (No such file or directory)
26293 stat("/usr/lib/perl5/vendor_perl/5.8.5", 0x7fff9164fb70) =3D -1 ENO=
ENT (No such file or directory)
26293 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff9164f930) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26293 lseek(0, 0, SEEK_CUR)             =3D 0
26293 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff9164f930) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26293 lseek(1, 0, SEEK_CUR)             =3D -1 ESPIPE (Illegal seek)
26293 ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff9164f940) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26293 lseek(2, 0, SEEK_CUR)             =3D 593660679
26293 open("/dev/null", O_RDONLY)       =3D 3
26293 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff9164fa40) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26293 lseek(3, 0, SEEK_CUR)             =3D 0
26293 fcntl(3, F_SETFD, FD_CLOEXEC)     =3D 0
26293 fstat(3, {st_dev=3Dmakedev(0, 16), st_ino=3D584, st_mode=3DS_IFCHR|=
0666, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
0, st_rdev=3Dmakedev(1, 3), st_atime=3D2012/10/08-11:13:26, st_mtime=3D20=
12/10/08-11:13:26, st_ctime=3D2012/10/08-11:13:27}) =3D 0
26293 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) =3D 0
26293 readlink("/proc/self/exe", "/usr/bin/perl"..., 4095) =3D 13
26293 brk(0xf38000)                     =3D 0xf38000
26293 close(3)                          =3D 0
26293 dup(200)                          =3D 3
26293 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff9164f910) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26293 lseek(3, 0, SEEK_CUR)             =3D 0
26293 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26293 dup2(3, 0)                        =3D 0
26293 close(3)                          =3D 0
26293 fcntl(0, F_SETFD, 0)              =3D 0
26293 fstat(0, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26293 stat("/var/run/xen-hotplug/block", {st_dev=3Dmakedev(8, 2), st_ino=3D=
2801738, st_mode=3DS_IFREG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st=
_blksize=3D4096, st_blocks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:=
24, st_mtime=3D2012/10/09-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D =
0
26293 exit_group(0)                     =3D ?
27813 <... read resumed> "", 128)       =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], WNOHANG, NUL=
L) =3D 26293
27813 wait4(-1, 0x7fffb0100a64, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0)                   =3D 0
27813 close(3)                          =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 write(2, "+ rightfile=3D\n", 13)    =3D 13
27813 write(2, "+ '[' x =3D xy ']'\n", 17) =3D 17
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ true\n", 7)           =3D 7
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ eval 'exec 200>>/var/run/xen-hotplug/block'\n", 46) =3D=
 46
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 write(2, "++ exec\n", 8)          =3D 8
27813 open("/var/run/xen-hotplug/block", O_WRONLY|O_CREAT|O_APPEND, 0666)=
 =3D 3
27813 fcntl(200, F_GETFD)               =3D 0
27813 fcntl(200, F_DUPFD, 10)           =3D 10
27813 fcntl(200, F_GETFD)               =3D 0
27813 dup2(3, 200)                      =3D 200
27813 close(3)                          =3D 0
27813 dup2(10, 200)                     =3D 200
27813 fcntl(10, F_GETFD)                =3D 0
27813 close(10)                         =3D 0
27813 write(2, "+ flock -x 200\n", 15)  =3D 15
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [INT CHLD], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [INT CHLD], NULL, 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26294
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26294 close(255 
27813 rt_sigprocmask(SIG_BLOCK, [CHLD],  
26294 <... close resumed> )             =3D 0
27813 <... rt_sigprocmask resumed> [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [],  
26294 rt_sigprocmask(SIG_SETMASK, [],  
27813 <... rt_sigprocmask resumed> NULL, 8) =3D 0
26294 <... rt_sigprocmask resumed> NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
26294 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0},  
26294 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
27813 <... rt_sigaction resumed> {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}=
, 8) =3D 0
26294 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 wait4(-1,  
26294 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
26294 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26294 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26294 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26294 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26294 execve("/usr/bin/flock", ["flock", "-x", "200"], ["SUBSYSTEM=3Dxen-=
backend", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D=
/usr/bin:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:=
/usr/sbin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dx=
en-backend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3D=
backend/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "S=
HLVL=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/flock"]) =3D 0=

26294 brk(0)                            =3D 0x1445000
26294 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f9db81e1000
26294 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f9db81e0000
26294 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26294 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26294 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26294 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7f9db81c6000=

26294 close(3)                          =3D 0
26294 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26294 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26294 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26294 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26294 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26294 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26294 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26294 close(3)                          =3D 0
26294 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f9db81c5000
26294 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f9db81c4000
26294 arch_prctl(ARCH_SET_FS, 0x7f9db81c46e0) =3D 0
26294 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26294 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26294 munmap(0x7f9db81c6000, 103979)    =3D 0
26294 flock(200, LOCK_EX)               =3D 0
26294 exit_group(0)                     =3D ?
27813 <... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], 0,=
 NULL) =3D 26294
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, 0x7fffb0100a24, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0xffffffffffffffff)  =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 pipe([3, 4])                      =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26295
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {0=
x436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26295 close(255 
27813 close(4 
26295 <... close resumed> )             =3D 0
27813 <... close resumed> )             =3D 0
27813 read(3,  
26295 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26295 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26295 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26295 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26295 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26295 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26295 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26295 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {S=
IG_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26295 rt_sigaction(SIGINT, {0x4481f0, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26295 dup2(4, 1)                        =3D 1
26295 close(4)                          =3D 0
26295 close(3)                          =3D 0
26295 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26295 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26295 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26295 write(2, "++ perl -e '\n            open STDIN, \"<&200\" or die $!=
;\n            my $fd_inum =3D (stat STDIN)[1]; die $! unless defined $fd=
_inum;\n            my $file_inum =3D (stat $ARGV[0])[1];\n            pr=
int \"y\\n\" if $fd_inum eq $file_inum;\n", 230) =3D 230
26295 write(2, "                             ' /var/run/xen-hotplug/block=
\n", 58) =3D 58
26295 stat(".", {st_dev=3Dmakedev(8, 2), st_ino=3D2, st_mode=3DS_IFDIR|07=
55, st_nlink=3D24, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
8, st_size=3D4096, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2012/10/08-=
11:13:38, st_ctime=3D2012/10/08-11:13:38}) =3D 0
26295 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26295 access("/usr/bin/perl", X_OK)     =3D 0
26295 access("/usr/bin/perl", R_OK)     =3D 0
26295 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26295 access("/usr/bin/perl", X_OK)     =3D 0
26295 access("/usr/bin/perl", R_OK)     =3D 0
26295 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
481f0, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26295 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26295 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26295 execve("/usr/bin/perl", ["perl", "-e", "\n            open STDIN, \=
"<&200\" or die $!;\n            my $fd_inum =3D (stat STDIN)[1]; die $! =
unless defined $fd_inum;\n            my $file_inum =3D (stat $ARGV[0])[1=
];\n            print \"y\\n\" if $fd_inum eq $file_inum;\n              =
               ", "/var/run/xen-hotplug/block"], ["SUBSYSTEM=3Dxen-backen=
d", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D/usr/b=
in:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:/usr/s=
bin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dxen-bac=
kend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3Dback=
end/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "SHLVL=
=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/perl"]) =3D 0
26295 brk(0)                            =3D 0x2269000
26295 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f364e6f9000
26295 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f364e6f8000
26295 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26295 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64/libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26295 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64", 0x7fff40215ad0) =3D -1 ENOENT (No such file or directory)
26295 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/lib=
perl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26295 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls", 0=
x7fff40215ad0) =3D -1 ENOENT (No such file or directory)
26295 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64/=
libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26295 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64"=
, 0x7fff40215ad0) =3D -1 ENOENT (No such file or directory)
26295 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl=
=2Eso", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26295 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE", 0x7ff=
f40215ad0) =3D -1 ENOENT (No such file or directory)
26295 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26295 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26295 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7f364e6de000=

26295 close(3)                          =3D 0
26295 open("/usr/lib64/libperl.so", O_RDONLY) =3D 3
26295 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\34\203%=
4\0\0\0@\0\0\0\0\0\0\0\360;\23\0\0\0\0\0\0\0\0\0@\0008\0\5\0@\0\35\0\34\0=
\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\200%4\0\0\0\0\0\200%4\0\0\0T\260\22\=
0\0\0\0\0T\260\22\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0X\260\22\0\0\0\=
0\0X\260\262%4\0\0\0X\260\262%4\0\0\0\250\201\0\0\0\0\0\0\350\242\0\0\0\0=
\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\265\22\0\0\0\0\0\370\265\262%4\0\=
0\0\370\265\262%4\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\=
0\0P\345td\4\0\0\0\250u\21\0\0\0\0\0\250u\221%4\0\0\0\250u\221%4\0\0\0D@\=
0\0\0\0\0\0D@\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\7\4\0\0\360\0\0\0\0\1\0\0\16\0\0\0\0\0\0@\0\200\203\200\225\1\22\=
264\3\31\200l\0\32\0 \5\201\0\240\3\2B\0\200\21R \0\22\0\0\16P\20#\10\216=
\334\30\211\"\0\10 \200\3B\220@\0\1\206\20\30\2\3\21\203$!\312A0\224Y\200=
\27\0\242\26\10\24R@\10\200\220\20A\10\0\220\1\200\206\2\10\304\30i\0\220=
\1\1\202\200\22\20\0\n\1H\0\n\2001J \6\31@L\207\20\10\0000\10(\200\2\0\4\=
251t\"\262\310!\212\240\320\"\0\t"..., 832) =3D 832
26295 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2839671, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D2480, st_size=3D1262384, st_atime=3D2012/10/09-12:04:35, st_mtime=3D=
2012/09/11-12:45:05, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26295 mmap(0x3425800000, 3363648, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425800000
26295 mprotect(0x342592c000, 2093056, PROT_NONE) =3D 0
26295 mmap(0x3425b2b000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x12b000) =3D 0x3425b2b000
26295 mmap(0x3425b34000, 4928, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3425b34000
26295 close(3)                          =3D 0
26295 open("/lib64/libresolv.so.2", O_RDONLY) =3D 3
26295 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\2402\0'4\0\=
0\0@\0\0\0\0\0\0\0@a\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\5\0=
\0\0@\0\0\0\0\0\0\0@\0\0'4\0\0\0@\0\0'4\0\0\0\370\1\0\0\0\0\0\0\370\1\0\0=
\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \361\0\0\0\0\0\0 \361\0'4\0\0\0=
 \361\0'4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\=
0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0'4\0\0\0\0\0\0'4\0\0\0$\10\1\0\0\0\0\0$\10=
\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\24\1\0\0\0\0\0\340\24!'4\=
0\0\0\340\24!'4\0\0\0\340\r\0\0\0\0\0\0\0106\0\0\0\0\0\0\0\0 \0\0\0\0\0\2=
\0\0\0\6\0\0\0\350\35\1\0\0\0\0\0\350\35!'4\0\0\0\350\35!'4\0\0\0\300\1\0=
\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\=
0\0\0008\2\0'4\0\0\0008\2\0'4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0=
\0\0\0\0P\345td\4\0\0\0<\361\0\0\0\0\0\0<\361\0'4\0\0\0<\361\0'4\0\0\0,\3=
\0\0\0\0\0\0,\3\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 8=
32
26295 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148119, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D192, st_size=3D92736, st_atime=3D2012/10/09-11:16:43, st_mtime=3D201=
0/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:42}) =3D 0
26295 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f364e6dd000
26295 mmap(0x3427000000, 2181864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3427000000
26295 mprotect(0x3427011000, 2097152, PROT_NONE) =3D 0
26295 mmap(0x3427211000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x11000) =3D 0x3427211000
26295 mmap(0x3427213000, 6888, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3427213000
26295 close(3)                          =3D 0
26295 open("/lib64/libnsl.so.1", O_RDONLY) =3D 3
26295 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240@\340\35=
10\0\0\0@\0\0\0\0\0\0\0\360\265\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0=
\6\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\340\3510\0\0\0@\0\340\3510\0\0\0\370\1=
\0\0\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \33\1\0\0=
\0\0\0 \33\341\3510\0\0\0 \33\341\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\=
0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\340\3510\0\0\0=
\0\0\340\3510\0\0\0\310@\1\0\0\0\0\0\310@\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\=
0\0\6\0\0\0xM\1\0\0\0\0\0xM\1\3520\0\0\0xM\1\3520\0\0\0\310\5\0\0\0\0\0\0=
008-\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250M\1\0\0\0\0\0\250M\1\3=
520\0\0\0\250M\1\3520\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\340\3510\0\0\0008\2\340\351=
0\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0<\33\=
1\0\0\0\0\0<\33\341\3510\0\0\0<\33\341\3510\0\0\0\\\5\0\0\0\0\0\0\\\5\0\0=
\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26295 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147206, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D232, st_size=3D114352, st_atime=3D2012/10/09-12:01:01, st_mtime=3D20=
10/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:44}) =3D 0
26295 mmap(0x30e9e00000, 2194096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9e00000
26295 mprotect(0x30e9e15000, 2093056, PROT_NONE) =3D 0
26295 mmap(0x30ea014000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x14000) =3D 0x30ea014000
26295 mmap(0x30ea016000, 6832, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x30ea016000
26295 close(3)                          =3D 0
26295 open("/lib64/libdl.so.2", O_RDONLY) =3D 3
26295 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\16`\3500=
\0\0\0@\0\0\0\0\0\0\0@R\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0`\3500\0\0\0@\0`\3500\0\0\0\370\1\0\0\0\0\0\0\37=
0\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\300\32\0\0\0\0\0\0\300\3=
2`\3500\0\0\0\300\32`\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0`\3500\0\0\0\0\0`\3500\0\0\=
0\224\37\0\0\0\0\0\0\224\37\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0`-\=
0\0\0\0\0\0`-\200\3500\0\0\0`-\200\3500\0\0\0 \3\0\0\0\0\0\0\240\3\0\0\0\=
0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\240-\0\0\0\0\0\0\240-\200\3500\0\0\0=
\240-\200\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0=
\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2`\3500\0\0\0008\2`\3500\0\0\0 \0\0\=
0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\334\32\0\0\0\0\0\=
0\334\32`\3500\0\0\0\334\32`\3500\0\0\0\264\0\0\0\0\0\0\0\264\0\0\0\0\0\0=
\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26295 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147322, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D48, st_size=3D23360, st_atime=3D2012/10/09-11:13:54, st_mtime=3D2010=
/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26295 mmap(0x30e8600000, 2109696, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8600000
26295 mprotect(0x30e8602000, 2097152, PROT_NONE) =3D 0
26295 mmap(0x30e8802000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x2000) =3D 0x30e8802000
26295 close(3)                          =3D 0
26295 open("/lib64/libm.so.6", O_RDONLY) =3D 3
26295 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`>\240\3510\=
0\0\0@\0\0\0\0\0\0\0\240X\t\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0)\0(\0\6\0\0\=
0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3510\0\0\0@\0\240\3510\0\0\0\370\1\0\0\0\=
0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\360\303\7\0\0\0\=
0\0\360\303\247\3510\0\0\0\360\303\247\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0=
\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3510\=
0\0\0\0\0\240\3510\0\0\0000\22\10\0\0\0\0\0000\22\10\0\0\0\0\0\0\0 \0\0\0=
\0\0\1\0\0\0\6\0\0\0\270\35\10\0\0\0\0\0\270\35\310\3510\0\0\0\270\35\310=
\3510\0\0\0\320\2\0\0\0\0\0\0 \3\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0=
\0\350\35\10\0\0\0\0\0\350\35\310\3510\0\0\0\350\35\310\3510\0\0\0\300\1\=
0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0=
\0\0\0008\2\240\3510\0\0\0008\2\240\3510\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\f\304\7\0\0\0\0\0\f\304\247\3510\0\0\0=
\f\304\247\3510\0\0\0\374\r\0\0\0\0\0\0\374\r\0\0\0\0\0\0\4\0\0\0\0\0\0\0=
Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0"..., 832) =3D 832
26295 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147337, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D1216, st_size=3D615136, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2=
010/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26295 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f364e6dc000
26295 mmap(0x30e9a00000, 2629848, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9a00000
26295 mprotect(0x30e9a82000, 2093056, PROT_NONE) =3D 0
26295 mmap(0x30e9c81000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x81000) =3D 0x30e9c81000
26295 close(3)                          =3D 0
26295 open("/lib64/libcrypt.so.1", O_RDONLY) =3D 3
26295 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\t\300%4=
\0\0\0@\0\0\0\0\0\0\0\30\265\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\=
0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\300%4\0\0\0@\0\300%4\0\0\0\370\1\0\0\0\0\=
0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340}\0\0\0\0\0\0\3=
40}\300%4\0\0\0\340}\300%4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\300%4\0\0\0\0\0\300%4\0\0\=
0\4\205\0\0\0\0\0\0\4\205\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\310\=
215\0\0\0\0\0\0\310\215\340%4\0\0\0\310\215\340%4\0\0\0\250\2\0\0\0\0\0\0=
\370\343\2\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\215\0\0\0\0\0\0\3=
70\215\340%4\0\0\0\370\215\340%4\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\=
0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\300%4\0\0\0008\2=
\300%4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0=
\374}\0\0\0\0\0\0\374}\300%4\0\0\0\374}\300%4\0\0\0\34\1\0\0\0\0\0\0\34\1=
\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26295 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148123, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D96, st_size=3D48600, st_atime=3D2012/10/09-12:01:01, st_mtime=3D2010=
/07/28-03:52:39, st_ctime=3D2012/09/11-14:53:52}) =3D 0
26295 mmap(0x3425c00000, 2322880, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425c00000
26295 mprotect(0x3425c09000, 2093056, PROT_NONE) =3D 0
26295 mmap(0x3425e08000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x8000) =3D 0x3425e08000
26295 mmap(0x3425e0a000, 184768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FI=
XED|MAP_ANONYMOUS, -1, 0) =3D 0x3425e0a000
26295 close(3)                          =3D 0
26295 open("/lib64/libutil.so.1", O_RDONLY) =3D 3
26295 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\16\0(4\=
0\0\0@\0\0\0\0\0\0\0(>\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0\0(4\0\0\0@\0\0(4\0\0\0\370\1\0\0\0\0\0\0\370\1\=
0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340\26\0\0\0\0\0\0\340\26\0(=
4\0\0\0\340\26\0(4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0=
\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0(4\0\0\0\0\0\0(4\0\0\0P\32\0\0\0\=
0\0\0P\32\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\35\0\0\0\0\0\0\3=
40\35 (4\0\0\0\340\35 (4\0\0\0 \3\0\0\0\0\0\0000\3\0\0\0\0\0\0\0\0 \0\0\0=
\0\0\2\0\0\0\6\0\0\0\20\36\0\0\0\0\0\0\20\36 (4\0\0\0\20\36 (4\0\0\0\300\=
1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0=
\0\0\0\0008\2\0(4\0\0\0008\2\0(4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\=
0\0\0\0\0\0P\345td\4\0\0\0\374\26\0\0\0\0\0\0\374\26\0(4\0\0\0\374\26\0(4=
\0\0\0D\0\0\0\0\0\0\0D\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8=
32) =3D 832
26295 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147063, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D40, st_size=3D18152, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2010=
/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:49}) =3D 0
26295 mmap(0x3428000000, 2105616, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3428000000
26295 mprotect(0x3428002000, 2093056, PROT_NONE) =3D 0
26295 mmap(0x3428201000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x1000) =3D 0x3428201000
26295 close(3)                          =3D 0
26295 open("/lib64/libpthread.so.0", O_RDONLY) =3D 3
26295 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240W\240\35=
00\0\0\0@\0\0\0\0\0\0\0\340/\2\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0'\0&\0\6\0=
\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3500\0\0\0@\0\240\3500\0\0\0\370\1\0\0=
\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\240\t\1\0\0\0=
\0\0\240\t\241\3500\0\0\0\240\t\241\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\=
0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3500\0\0=
\0\0\0\240\3500\0\0\0pZ\1\0\0\0\0\0pZ\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\=
6\0\0\0\270[\1\0\0\0\0\0\270[\301\3500\0\0\0\270[\301\3500\0\0\0\230\6\0\=
0\0\0\0\0\270G\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250]\1\0\0\0\0\=
0\250]\301\3500\0\0\0\250]\301\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0=
\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\240\3500\0\0\=
0008\2\240\3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345t=
d\4\0\0\0\274\t\1\0\0\0\0\0\274\t\241\3500\0\0\0\274\t\241\3500\0\0\0\344=
\t\0\0\0\0\0\0\344\t\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =
=3D 832
26295 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147328, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D296, st_size=3D145824, st_atime=3D2012/10/09-11:16:43, st_mtime=3D20=
10/07/28-03:52:41, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26295 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f364e6db000
26295 mmap(0x30e8a00000, 2204528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8a00000
26295 mprotect(0x30e8a16000, 2093056, PROT_NONE) =3D 0
26295 mmap(0x30e8c15000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x15000) =3D 0x30e8c15000
26295 mmap(0x30e8c17000, 13168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8c17000
26295 close(3)                          =3D 0
26295 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26295 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26295 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26295 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26295 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26295 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26295 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26295 close(3)                          =3D 0
26295 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f364e6da000
26295 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f364e6d9000
26295 arch_prctl(ARCH_SET_FS, 0x7f364e6d96e0) =3D 0
26295 mprotect(0x3427211000, 4096, PROT_READ) =3D 0
26295 mprotect(0x30ea014000, 4096, PROT_READ) =3D 0
26295 mprotect(0x30e8802000, 4096, PROT_READ) =3D 0
26295 mprotect(0x30e9c81000, 4096, PROT_READ) =3D 0
26295 mprotect(0x3425e08000, 4096, PROT_READ) =3D 0
26295 mprotect(0x3428201000, 4096, PROT_READ) =3D 0
26295 mprotect(0x30e8c15000, 4096, PROT_READ) =3D 0
26295 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26295 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26295 munmap(0x7f364e6de000, 103979)    =3D 0
26295 set_tid_address(0x7f364e6d9770)   =3D 26295
26295 set_robust_list(0x7f364e6d9780, 0x18) =3D 0
26295 futex(0x7fff402165fc, FUTEX_WAKE_PRIVATE, 1) =3D 0
26295 rt_sigaction(SIGRTMIN, {0x30e8a05380, [], SA_RESTORER|SA_SIGINFO, 0=
x30e8a0eb10}, NULL, 8) =3D 0
26295 rt_sigaction(SIGRT_1, {0x30e8a052b0, [], SA_RESTORER|SA_RESTART|SA_=
SIGINFO, 0x30e8a0eb10}, NULL, 8) =3D 0
26295 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) =3D 0
26295 getrlimit(RLIMIT_STACK, {rlim_cur=3D8192*1024, rlim_max=3DRLIM_INFI=
NITY}) =3D 0
26295 rt_sigaction(SIGFPE, {0x1, [FPE], SA_RESTORER|SA_RESTART, 0x30e8230=
2d0}, {SIG_DFL, [], 0}, 8) =3D 0
26295 brk(0)                            =3D 0x2269000
26295 brk(0x228b000)                    =3D 0x228b000
26295 getuid()                          =3D 0
26295 geteuid()                         =3D 0
26295 getgid()                          =3D 0
26295 getegid()                         =3D 0
26295 mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,=
 -1, 0) =3D 0x7f364e6b8000
26295 open("/dev/urandom", O_RDONLY)    =3D 3
26295 read(3, "\361\r9\204", 4)         =3D 4
26295 close(3)                          =3D 0
26295 stat("/usr/lib64/perl5/site_perl/5.8.7/x86_64-linux-thread-multi", =
0x7fff402162b0) =3D -1 ENOENT (No such file or directory)
26295 stat("/usr/lib/perl5/site_perl/5.8.7", 0x7fff402162b0) =3D -1 ENOEN=
T (No such file or directory)
26295 stat("/usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi", =
0x7fff402162b0) =3D -1 ENOENT (No such file or directory)
26295 stat("/usr/lib/perl5/site_perl/5.8.6", 0x7fff402162b0) =3D -1 ENOEN=
T (No such file or directory)
26295 stat("/usr/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi", =
0x7fff402162b0) =3D -1 ENOENT (No such file or directory)
26295 stat("/usr/lib/perl5/site_perl/5.8.5", 0x7fff402162b0) =3D -1 ENOEN=
T (No such file or directory)
26295 stat("/usr/lib64/perl5/vendor_perl/5.8.7/x86_64-linux-thread-multi"=
, 0x7fff402162b0) =3D -1 ENOENT (No such file or directory)
26295 stat("/usr/lib/perl5/vendor_perl/5.8.7", 0x7fff402162b0) =3D -1 ENO=
ENT (No such file or directory)
26295 stat("/usr/lib64/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi"=
, 0x7fff402162b0) =3D -1 ENOENT (No such file or directory)
26295 stat("/usr/lib/perl5/vendor_perl/5.8.6", 0x7fff402162b0) =3D -1 ENO=
ENT (No such file or directory)
26295 stat("/usr/lib64/perl5/vendor_perl/5.8.5/x86_64-linux-thread-multi"=
, 0x7fff402162b0) =3D -1 ENOENT (No such file or directory)
26295 stat("/usr/lib/perl5/vendor_perl/5.8.5", 0x7fff402162b0) =3D -1 ENO=
ENT (No such file or directory)
26295 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff40216070) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26295 lseek(0, 0, SEEK_CUR)             =3D 0
26295 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff40216070) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26295 lseek(1, 0, SEEK_CUR)             =3D -1 ESPIPE (Illegal seek)
26295 ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff40216080) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26295 lseek(2, 0, SEEK_CUR)             =3D 593661073
26295 open("/dev/null", O_RDONLY)       =3D 3
26295 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff40216180) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26295 lseek(3, 0, SEEK_CUR)             =3D 0
26295 fcntl(3, F_SETFD, FD_CLOEXEC)     =3D 0
26295 fstat(3, {st_dev=3Dmakedev(0, 16), st_ino=3D584, st_mode=3DS_IFCHR|=
0666, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
0, st_rdev=3Dmakedev(1, 3), st_atime=3D2012/10/08-11:13:26, st_mtime=3D20=
12/10/08-11:13:26, st_ctime=3D2012/10/08-11:13:27}) =3D 0
26295 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) =3D 0
26295 readlink("/proc/self/exe", "/usr/bin/perl"..., 4095) =3D 13
26295 brk(0x22ac000)                    =3D 0x22ac000
26295 close(3)                          =3D 0
26295 dup(200)                          =3D 3
26295 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff40216050) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26295 lseek(3, 0, SEEK_CUR)             =3D 0
26295 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26295 dup2(3, 0)                        =3D 0
26295 close(3)                          =3D 0
26295 fcntl(0, F_SETFD, 0)              =3D 0
26295 fstat(0, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26295 stat("/var/run/xen-hotplug/block", {st_dev=3Dmakedev(8, 2), st_ino=3D=
2801738, st_mode=3DS_IFREG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st=
_blksize=3D4096, st_blocks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:=
24, st_mtime=3D2012/10/09-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D =
0
26295 exit_group(0)                     =3D ?
27813 <... read resumed> "", 128)       =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], WNOHANG, NUL=
L) =3D 26295
27813 wait4(-1, 0x7fffb0100a64, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0)                   =3D 0
27813 close(3)                          =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 write(2, "+ rightfile=3D\n", 13)    =3D 13
27813 write(2, "+ '[' x =3D xy ']'\n", 17) =3D 17
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ true\n", 7)           =3D 7
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ eval 'exec 200>>/var/run/xen-hotplug/block'\n", 46) =3D=
 46
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 write(2, "++ exec\n", 8)          =3D 8
27813 open("/var/run/xen-hotplug/block", O_WRONLY|O_CREAT|O_APPEND, 0666)=
 =3D 3
27813 fcntl(200, F_GETFD)               =3D 0
27813 fcntl(200, F_DUPFD, 10)           =3D 10
27813 fcntl(200, F_GETFD)               =3D 0
27813 dup2(3, 200)                      =3D 200
27813 close(3)                          =3D 0
27813 dup2(10, 200)                     =3D 200
27813 fcntl(10, F_GETFD)                =3D 0
27813 close(10)                         =3D 0
27813 write(2, "+ flock -x 200\n", 15)  =3D 15
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [INT CHLD], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [INT CHLD], NULL, 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26296
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26296 close(255 
27813 rt_sigprocmask(SIG_BLOCK, [CHLD],  
26296 <... close resumed> )             =3D 0
27813 <... rt_sigprocmask resumed> [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [],  
26296 rt_sigprocmask(SIG_SETMASK, [],  
27813 <... rt_sigprocmask resumed> NULL, 8) =3D 0
26296 <... rt_sigprocmask resumed> NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
26296 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0},  
26296 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
27813 <... rt_sigaction resumed> {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}=
, 8) =3D 0
26296 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 wait4(-1,  
26296 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
26296 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26296 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26296 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26296 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26296 execve("/usr/bin/flock", ["flock", "-x", "200"], ["SUBSYSTEM=3Dxen-=
backend", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D=
/usr/bin:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:=
/usr/sbin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dx=
en-backend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3D=
backend/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "S=
HLVL=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/flock"]) =3D 0=

26296 brk(0)                            =3D 0x7fd000
26296 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fab26b69000
26296 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fab26b68000
26296 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26296 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26296 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26296 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7fab26b4e000=

26296 close(3)                          =3D 0
26296 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26296 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26296 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26296 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26296 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26296 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26296 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26296 close(3)                          =3D 0
26296 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fab26b4d000
26296 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fab26b4c000
26296 arch_prctl(ARCH_SET_FS, 0x7fab26b4c6e0) =3D 0
26296 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26296 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26296 munmap(0x7fab26b4e000, 103979)    =3D 0
26296 flock(200, LOCK_EX)               =3D 0
26296 exit_group(0)                     =3D ?
27813 <... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], 0,=
 NULL) =3D 26296
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, 0x7fffb0100a24, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0xffffffffffffffff)  =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 pipe([3, 4])                      =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26297
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {0=
x436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26297 close(255 
27813 close(4 
26297 <... close resumed> )             =3D 0
27813 <... close resumed> )             =3D 0
27813 read(3,  
26297 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26297 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26297 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26297 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26297 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26297 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26297 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26297 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {S=
IG_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26297 rt_sigaction(SIGINT, {0x4481f0, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26297 dup2(4, 1)                        =3D 1
26297 close(4)                          =3D 0
26297 close(3)                          =3D 0
26297 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26297 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26297 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26297 write(2, "++ perl -e '\n            open STDIN, \"<&200\" or die $!=
;\n            my $fd_inum =3D (stat STDIN)[1]; die $! unless defined $fd=
_inum;\n            my $file_inum =3D (stat $ARGV[0])[1];\n            pr=
int \"y\\n\" if $fd_inum eq $file_inum;\n", 230) =3D 230
26297 write(2, "                             ' /var/run/xen-hotplug/block=
\n", 58) =3D 58
26297 stat(".", {st_dev=3Dmakedev(8, 2), st_ino=3D2, st_mode=3DS_IFDIR|07=
55, st_nlink=3D24, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
8, st_size=3D4096, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2012/10/08-=
11:13:38, st_ctime=3D2012/10/08-11:13:38}) =3D 0
26297 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26297 access("/usr/bin/perl", X_OK)     =3D 0
26297 access("/usr/bin/perl", R_OK)     =3D 0
26297 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26297 access("/usr/bin/perl", X_OK)     =3D 0
26297 access("/usr/bin/perl", R_OK)     =3D 0
26297 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
481f0, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26297 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26297 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26297 execve("/usr/bin/perl", ["perl", "-e", "\n            open STDIN, \=
"<&200\" or die $!;\n            my $fd_inum =3D (stat STDIN)[1]; die $! =
unless defined $fd_inum;\n            my $file_inum =3D (stat $ARGV[0])[1=
];\n            print \"y\\n\" if $fd_inum eq $file_inum;\n              =
               ", "/var/run/xen-hotplug/block"], ["SUBSYSTEM=3Dxen-backen=
d", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D/usr/b=
in:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:/usr/s=
bin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dxen-bac=
kend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3Dback=
end/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "SHLVL=
=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/perl"]) =3D 0
26297 brk(0)                            =3D 0x23d6000
26297 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fad691c1000
26297 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fad691c0000
26297 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26297 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64/libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26297 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64", 0x7fff8c5a4d10) =3D -1 ENOENT (No such file or directory)
26297 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/lib=
perl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26297 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls", 0=
x7fff8c5a4d10) =3D -1 ENOENT (No such file or directory)
26297 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64/=
libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26297 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64"=
, 0x7fff8c5a4d10) =3D -1 ENOENT (No such file or directory)
26297 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl=
=2Eso", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26297 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE", 0x7ff=
f8c5a4d10) =3D -1 ENOENT (No such file or directory)
26297 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26297 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26297 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7fad691a6000=

26297 close(3)                          =3D 0
26297 open("/usr/lib64/libperl.so", O_RDONLY) =3D 3
26297 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\34\203%=
4\0\0\0@\0\0\0\0\0\0\0\360;\23\0\0\0\0\0\0\0\0\0@\0008\0\5\0@\0\35\0\34\0=
\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\200%4\0\0\0\0\0\200%4\0\0\0T\260\22\=
0\0\0\0\0T\260\22\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0X\260\22\0\0\0\=
0\0X\260\262%4\0\0\0X\260\262%4\0\0\0\250\201\0\0\0\0\0\0\350\242\0\0\0\0=
\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\265\22\0\0\0\0\0\370\265\262%4\0\=
0\0\370\265\262%4\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\=
0\0P\345td\4\0\0\0\250u\21\0\0\0\0\0\250u\221%4\0\0\0\250u\221%4\0\0\0D@\=
0\0\0\0\0\0D@\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\7\4\0\0\360\0\0\0\0\1\0\0\16\0\0\0\0\0\0@\0\200\203\200\225\1\22\=
264\3\31\200l\0\32\0 \5\201\0\240\3\2B\0\200\21R \0\22\0\0\16P\20#\10\216=
\334\30\211\"\0\10 \200\3B\220@\0\1\206\20\30\2\3\21\203$!\312A0\224Y\200=
\27\0\242\26\10\24R@\10\200\220\20A\10\0\220\1\200\206\2\10\304\30i\0\220=
\1\1\202\200\22\20\0\n\1H\0\n\2001J \6\31@L\207\20\10\0000\10(\200\2\0\4\=
251t\"\262\310!\212\240\320\"\0\t"..., 832) =3D 832
26297 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2839671, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D2480, st_size=3D1262384, st_atime=3D2012/10/09-12:04:35, st_mtime=3D=
2012/09/11-12:45:05, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26297 mmap(0x3425800000, 3363648, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425800000
26297 mprotect(0x342592c000, 2093056, PROT_NONE) =3D 0
26297 mmap(0x3425b2b000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x12b000) =3D 0x3425b2b000
26297 mmap(0x3425b34000, 4928, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3425b34000
26297 close(3)                          =3D 0
26297 open("/lib64/libresolv.so.2", O_RDONLY) =3D 3
26297 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\2402\0'4\0\=
0\0@\0\0\0\0\0\0\0@a\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\5\0=
\0\0@\0\0\0\0\0\0\0@\0\0'4\0\0\0@\0\0'4\0\0\0\370\1\0\0\0\0\0\0\370\1\0\0=
\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \361\0\0\0\0\0\0 \361\0'4\0\0\0=
 \361\0'4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\=
0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0'4\0\0\0\0\0\0'4\0\0\0$\10\1\0\0\0\0\0$\10=
\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\24\1\0\0\0\0\0\340\24!'4\=
0\0\0\340\24!'4\0\0\0\340\r\0\0\0\0\0\0\0106\0\0\0\0\0\0\0\0 \0\0\0\0\0\2=
\0\0\0\6\0\0\0\350\35\1\0\0\0\0\0\350\35!'4\0\0\0\350\35!'4\0\0\0\300\1\0=
\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\=
0\0\0008\2\0'4\0\0\0008\2\0'4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0=
\0\0\0\0P\345td\4\0\0\0<\361\0\0\0\0\0\0<\361\0'4\0\0\0<\361\0'4\0\0\0,\3=
\0\0\0\0\0\0,\3\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 8=
32
26297 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148119, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D192, st_size=3D92736, st_atime=3D2012/10/09-11:16:43, st_mtime=3D201=
0/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:42}) =3D 0
26297 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fad691a5000
26297 mmap(0x3427000000, 2181864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3427000000
26297 mprotect(0x3427011000, 2097152, PROT_NONE) =3D 0
26297 mmap(0x3427211000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x11000) =3D 0x3427211000
26297 mmap(0x3427213000, 6888, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3427213000
26297 close(3)                          =3D 0
26297 open("/lib64/libnsl.so.1", O_RDONLY) =3D 3
26297 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240@\340\35=
10\0\0\0@\0\0\0\0\0\0\0\360\265\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0=
\6\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\340\3510\0\0\0@\0\340\3510\0\0\0\370\1=
\0\0\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \33\1\0\0=
\0\0\0 \33\341\3510\0\0\0 \33\341\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\=
0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\340\3510\0\0\0=
\0\0\340\3510\0\0\0\310@\1\0\0\0\0\0\310@\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\=
0\0\6\0\0\0xM\1\0\0\0\0\0xM\1\3520\0\0\0xM\1\3520\0\0\0\310\5\0\0\0\0\0\0=
008-\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250M\1\0\0\0\0\0\250M\1\3=
520\0\0\0\250M\1\3520\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\340\3510\0\0\0008\2\340\351=
0\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0<\33\=
1\0\0\0\0\0<\33\341\3510\0\0\0<\33\341\3510\0\0\0\\\5\0\0\0\0\0\0\\\5\0\0=
\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26297 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147206, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D232, st_size=3D114352, st_atime=3D2012/10/09-12:01:01, st_mtime=3D20=
10/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:44}) =3D 0
26297 mmap(0x30e9e00000, 2194096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9e00000
26297 mprotect(0x30e9e15000, 2093056, PROT_NONE) =3D 0
26297 mmap(0x30ea014000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x14000) =3D 0x30ea014000
26297 mmap(0x30ea016000, 6832, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x30ea016000
26297 close(3)                          =3D 0
26297 open("/lib64/libdl.so.2", O_RDONLY) =3D 3
26297 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\16`\3500=
\0\0\0@\0\0\0\0\0\0\0@R\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0`\3500\0\0\0@\0`\3500\0\0\0\370\1\0\0\0\0\0\0\37=
0\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\300\32\0\0\0\0\0\0\300\3=
2`\3500\0\0\0\300\32`\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0`\3500\0\0\0\0\0`\3500\0\0\=
0\224\37\0\0\0\0\0\0\224\37\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0`-\=
0\0\0\0\0\0`-\200\3500\0\0\0`-\200\3500\0\0\0 \3\0\0\0\0\0\0\240\3\0\0\0\=
0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\240-\0\0\0\0\0\0\240-\200\3500\0\0\0=
\240-\200\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0=
\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2`\3500\0\0\0008\2`\3500\0\0\0 \0\0\=
0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\334\32\0\0\0\0\0\=
0\334\32`\3500\0\0\0\334\32`\3500\0\0\0\264\0\0\0\0\0\0\0\264\0\0\0\0\0\0=
\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26297 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147322, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D48, st_size=3D23360, st_atime=3D2012/10/09-11:13:54, st_mtime=3D2010=
/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26297 mmap(0x30e8600000, 2109696, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8600000
26297 mprotect(0x30e8602000, 2097152, PROT_NONE) =3D 0
26297 mmap(0x30e8802000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x2000) =3D 0x30e8802000
26297 close(3)                          =3D 0
26297 open("/lib64/libm.so.6", O_RDONLY) =3D 3
26297 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`>\240\3510\=
0\0\0@\0\0\0\0\0\0\0\240X\t\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0)\0(\0\6\0\0\=
0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3510\0\0\0@\0\240\3510\0\0\0\370\1\0\0\0\=
0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\360\303\7\0\0\0\=
0\0\360\303\247\3510\0\0\0\360\303\247\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0=
\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3510\=
0\0\0\0\0\240\3510\0\0\0000\22\10\0\0\0\0\0000\22\10\0\0\0\0\0\0\0 \0\0\0=
\0\0\1\0\0\0\6\0\0\0\270\35\10\0\0\0\0\0\270\35\310\3510\0\0\0\270\35\310=
\3510\0\0\0\320\2\0\0\0\0\0\0 \3\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0=
\0\350\35\10\0\0\0\0\0\350\35\310\3510\0\0\0\350\35\310\3510\0\0\0\300\1\=
0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0=
\0\0\0008\2\240\3510\0\0\0008\2\240\3510\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\f\304\7\0\0\0\0\0\f\304\247\3510\0\0\0=
\f\304\247\3510\0\0\0\374\r\0\0\0\0\0\0\374\r\0\0\0\0\0\0\4\0\0\0\0\0\0\0=
Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0"..., 832) =3D 832
26297 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147337, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D1216, st_size=3D615136, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2=
010/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26297 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fad691a4000
26297 mmap(0x30e9a00000, 2629848, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9a00000
26297 mprotect(0x30e9a82000, 2093056, PROT_NONE) =3D 0
26297 mmap(0x30e9c81000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x81000) =3D 0x30e9c81000
26297 close(3)                          =3D 0
26297 open("/lib64/libcrypt.so.1", O_RDONLY) =3D 3
26297 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\t\300%4=
\0\0\0@\0\0\0\0\0\0\0\30\265\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\=
0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\300%4\0\0\0@\0\300%4\0\0\0\370\1\0\0\0\0\=
0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340}\0\0\0\0\0\0\3=
40}\300%4\0\0\0\340}\300%4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\300%4\0\0\0\0\0\300%4\0\0\=
0\4\205\0\0\0\0\0\0\4\205\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\310\=
215\0\0\0\0\0\0\310\215\340%4\0\0\0\310\215\340%4\0\0\0\250\2\0\0\0\0\0\0=
\370\343\2\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\215\0\0\0\0\0\0\3=
70\215\340%4\0\0\0\370\215\340%4\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\=
0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\300%4\0\0\0008\2=
\300%4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0=
\374}\0\0\0\0\0\0\374}\300%4\0\0\0\374}\300%4\0\0\0\34\1\0\0\0\0\0\0\34\1=
\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26297 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148123, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D96, st_size=3D48600, st_atime=3D2012/10/09-12:01:01, st_mtime=3D2010=
/07/28-03:52:39, st_ctime=3D2012/09/11-14:53:52}) =3D 0
26297 mmap(0x3425c00000, 2322880, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425c00000
26297 mprotect(0x3425c09000, 2093056, PROT_NONE) =3D 0
26297 mmap(0x3425e08000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x8000) =3D 0x3425e08000
26297 mmap(0x3425e0a000, 184768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FI=
XED|MAP_ANONYMOUS, -1, 0) =3D 0x3425e0a000
26297 close(3)                          =3D 0
26297 open("/lib64/libutil.so.1", O_RDONLY) =3D 3
26297 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\16\0(4\=
0\0\0@\0\0\0\0\0\0\0(>\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0\0(4\0\0\0@\0\0(4\0\0\0\370\1\0\0\0\0\0\0\370\1\=
0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340\26\0\0\0\0\0\0\340\26\0(=
4\0\0\0\340\26\0(4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0=
\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0(4\0\0\0\0\0\0(4\0\0\0P\32\0\0\0\=
0\0\0P\32\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\35\0\0\0\0\0\0\3=
40\35 (4\0\0\0\340\35 (4\0\0\0 \3\0\0\0\0\0\0000\3\0\0\0\0\0\0\0\0 \0\0\0=
\0\0\2\0\0\0\6\0\0\0\20\36\0\0\0\0\0\0\20\36 (4\0\0\0\20\36 (4\0\0\0\300\=
1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0=
\0\0\0\0008\2\0(4\0\0\0008\2\0(4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\=
0\0\0\0\0\0P\345td\4\0\0\0\374\26\0\0\0\0\0\0\374\26\0(4\0\0\0\374\26\0(4=
\0\0\0D\0\0\0\0\0\0\0D\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8=
32) =3D 832
26297 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147063, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D40, st_size=3D18152, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2010=
/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:49}) =3D 0
26297 mmap(0x3428000000, 2105616, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3428000000
26297 mprotect(0x3428002000, 2093056, PROT_NONE) =3D 0
26297 mmap(0x3428201000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x1000) =3D 0x3428201000
26297 close(3)                          =3D 0
26297 open("/lib64/libpthread.so.0", O_RDONLY) =3D 3
26297 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240W\240\35=
00\0\0\0@\0\0\0\0\0\0\0\340/\2\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0'\0&\0\6\0=
\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3500\0\0\0@\0\240\3500\0\0\0\370\1\0\0=
\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\240\t\1\0\0\0=
\0\0\240\t\241\3500\0\0\0\240\t\241\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\=
0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3500\0\0=
\0\0\0\240\3500\0\0\0pZ\1\0\0\0\0\0pZ\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\=
6\0\0\0\270[\1\0\0\0\0\0\270[\301\3500\0\0\0\270[\301\3500\0\0\0\230\6\0\=
0\0\0\0\0\270G\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250]\1\0\0\0\0\=
0\250]\301\3500\0\0\0\250]\301\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0=
\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\240\3500\0\0\=
0008\2\240\3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345t=
d\4\0\0\0\274\t\1\0\0\0\0\0\274\t\241\3500\0\0\0\274\t\241\3500\0\0\0\344=
\t\0\0\0\0\0\0\344\t\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =
=3D 832
26297 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147328, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D296, st_size=3D145824, st_atime=3D2012/10/09-11:16:43, st_mtime=3D20=
10/07/28-03:52:41, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26297 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fad691a3000
26297 mmap(0x30e8a00000, 2204528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8a00000
26297 mprotect(0x30e8a16000, 2093056, PROT_NONE) =3D 0
26297 mmap(0x30e8c15000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x15000) =3D 0x30e8c15000
26297 mmap(0x30e8c17000, 13168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8c17000
26297 close(3)                          =3D 0
26297 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26297 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26297 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26297 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26297 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26297 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26297 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26297 close(3)                          =3D 0
26297 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fad691a2000
26297 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fad691a1000
26297 arch_prctl(ARCH_SET_FS, 0x7fad691a16e0) =3D 0
26297 mprotect(0x3427211000, 4096, PROT_READ) =3D 0
26297 mprotect(0x30ea014000, 4096, PROT_READ) =3D 0
26297 mprotect(0x30e8802000, 4096, PROT_READ) =3D 0
26297 mprotect(0x30e9c81000, 4096, PROT_READ) =3D 0
26297 mprotect(0x3425e08000, 4096, PROT_READ) =3D 0
26297 mprotect(0x3428201000, 4096, PROT_READ) =3D 0
26297 mprotect(0x30e8c15000, 4096, PROT_READ) =3D 0
26297 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26297 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26297 munmap(0x7fad691a6000, 103979)    =3D 0
26297 set_tid_address(0x7fad691a1770)   =3D 26297
26297 set_robust_list(0x7fad691a1780, 0x18) =3D 0
26297 futex(0x7fff8c5a583c, FUTEX_WAKE_PRIVATE, 1) =3D 0
26297 rt_sigaction(SIGRTMIN, {0x30e8a05380, [], SA_RESTORER|SA_SIGINFO, 0=
x30e8a0eb10}, NULL, 8) =3D 0
26297 rt_sigaction(SIGRT_1, {0x30e8a052b0, [], SA_RESTORER|SA_RESTART|SA_=
SIGINFO, 0x30e8a0eb10}, NULL, 8) =3D 0
26297 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) =3D 0
26297 getrlimit(RLIMIT_STACK, {rlim_cur=3D8192*1024, rlim_max=3DRLIM_INFI=
NITY}) =3D 0
26297 rt_sigaction(SIGFPE, {0x1, [FPE], SA_RESTORER|SA_RESTART, 0x30e8230=
2d0}, {SIG_DFL, [], 0}, 8) =3D 0
26297 brk(0)                            =3D 0x23d6000
26297 brk(0x23f8000)                    =3D 0x23f8000
26297 getuid()                          =3D 0
26297 geteuid()                         =3D 0
26297 getgid()                          =3D 0
26297 getegid()                         =3D 0
26297 mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,=
 -1, 0) =3D 0x7fad69180000
26297 open("/dev/urandom", O_RDONLY)    =3D 3
26297 read(3, "*\214J\323", 4)          =3D 4
26297 close(3)                          =3D 0
26297 stat("/usr/lib64/perl5/site_perl/5.8.7/x86_64-linux-thread-multi", =
0x7fff8c5a54f0) =3D -1 ENOENT (No such file or directory)
26297 stat("/usr/lib/perl5/site_perl/5.8.7", 0x7fff8c5a54f0) =3D -1 ENOEN=
T (No such file or directory)
26297 stat("/usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi", =
0x7fff8c5a54f0) =3D -1 ENOENT (No such file or directory)
26297 stat("/usr/lib/perl5/site_perl/5.8.6", 0x7fff8c5a54f0) =3D -1 ENOEN=
T (No such file or directory)
26297 stat("/usr/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi", =
0x7fff8c5a54f0) =3D -1 ENOENT (No such file or directory)
26297 stat("/usr/lib/perl5/site_perl/5.8.5", 0x7fff8c5a54f0) =3D -1 ENOEN=
T (No such file or directory)
26297 stat("/usr/lib64/perl5/vendor_perl/5.8.7/x86_64-linux-thread-multi"=
, 0x7fff8c5a54f0) =3D -1 ENOENT (No such file or directory)
26297 stat("/usr/lib/perl5/vendor_perl/5.8.7", 0x7fff8c5a54f0) =3D -1 ENO=
ENT (No such file or directory)
26297 stat("/usr/lib64/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi"=
, 0x7fff8c5a54f0) =3D -1 ENOENT (No such file or directory)
26297 stat("/usr/lib/perl5/vendor_perl/5.8.6", 0x7fff8c5a54f0) =3D -1 ENO=
ENT (No such file or directory)
26297 stat("/usr/lib64/perl5/vendor_perl/5.8.5/x86_64-linux-thread-multi"=
, 0x7fff8c5a54f0) =3D -1 ENOENT (No such file or directory)
26297 stat("/usr/lib/perl5/vendor_perl/5.8.5", 0x7fff8c5a54f0) =3D -1 ENO=
ENT (No such file or directory)
26297 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff8c5a52b0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26297 lseek(0, 0, SEEK_CUR)             =3D 0
26297 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff8c5a52b0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26297 lseek(1, 0, SEEK_CUR)             =3D -1 ESPIPE (Illegal seek)
26297 ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff8c5a52c0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26297 lseek(2, 0, SEEK_CUR)             =3D 593661467
26297 open("/dev/null", O_RDONLY)       =3D 3
26297 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff8c5a53c0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26297 lseek(3, 0, SEEK_CUR)             =3D 0
26297 fcntl(3, F_SETFD, FD_CLOEXEC)     =3D 0
26297 fstat(3, {st_dev=3Dmakedev(0, 16), st_ino=3D584, st_mode=3DS_IFCHR|=
0666, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
0, st_rdev=3Dmakedev(1, 3), st_atime=3D2012/10/08-11:13:26, st_mtime=3D20=
12/10/08-11:13:26, st_ctime=3D2012/10/08-11:13:27}) =3D 0
26297 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) =3D 0
26297 readlink("/proc/self/exe", "/usr/bin/perl"..., 4095) =3D 13
26297 brk(0x2419000)                    =3D 0x2419000
26297 close(3)                          =3D 0
26297 dup(200)                          =3D 3
26297 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff8c5a5290) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26297 lseek(3, 0, SEEK_CUR)             =3D 0
26297 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26297 dup2(3, 0)                        =3D 0
26297 close(3)                          =3D 0
26297 fcntl(0, F_SETFD, 0)              =3D 0
26297 fstat(0, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26297 stat("/var/run/xen-hotplug/block", {st_dev=3Dmakedev(8, 2), st_ino=3D=
2801738, st_mode=3DS_IFREG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st=
_blksize=3D4096, st_blocks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:=
24, st_mtime=3D2012/10/09-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D =
0
26297 exit_group(0)                     =3D ?
27813 <... read resumed> "", 128)       =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], WNOHANG, NUL=
L) =3D 26297
27813 wait4(-1, 0x7fffb0100a64, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0)                   =3D 0
27813 close(3)                          =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 write(2, "+ rightfile=3D\n", 13)    =3D 13
27813 write(2, "+ '[' x =3D xy ']'\n", 17) =3D 17
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ true\n", 7)           =3D 7
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ eval 'exec 200>>/var/run/xen-hotplug/block'\n", 46) =3D=
 46
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 write(2, "++ exec\n", 8)          =3D 8
27813 open("/var/run/xen-hotplug/block", O_WRONLY|O_CREAT|O_APPEND, 0666)=
 =3D 3
27813 fcntl(200, F_GETFD)               =3D 0
27813 fcntl(200, F_DUPFD, 10)           =3D 10
27813 fcntl(200, F_GETFD)               =3D 0
27813 dup2(3, 200)                      =3D 200
27813 close(3)                          =3D 0
27813 dup2(10, 200)                     =3D 200
27813 fcntl(10, F_GETFD)                =3D 0
27813 close(10)                         =3D 0
27813 write(2, "+ flock -x 200\n", 15)  =3D 15
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [INT CHLD], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [INT CHLD], NULL, 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26298
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26298 close(255 
27813 rt_sigprocmask(SIG_BLOCK, [CHLD],  
26298 <... close resumed> )             =3D 0
27813 <... rt_sigprocmask resumed> [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [],  
26298 rt_sigprocmask(SIG_SETMASK, [],  
27813 <... rt_sigprocmask resumed> NULL, 8) =3D 0
26298 <... rt_sigprocmask resumed> NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
26298 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0},  
26298 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
27813 <... rt_sigaction resumed> {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}=
, 8) =3D 0
26298 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 wait4(-1,  
26298 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
26298 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26298 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26298 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26298 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26298 execve("/usr/bin/flock", ["flock", "-x", "200"], ["SUBSYSTEM=3Dxen-=
backend", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D=
/usr/bin:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:=
/usr/sbin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dx=
en-backend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3D=
backend/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "S=
HLVL=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/flock"]) =3D 0=

26298 brk(0)                            =3D 0x631000
26298 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f5c60887000
26298 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f5c60886000
26298 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26298 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26298 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26298 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7f5c6086c000=

26298 close(3)                          =3D 0
26298 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26298 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26298 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26298 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26298 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26298 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26298 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26298 close(3)                          =3D 0
26298 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f5c6086b000
26298 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f5c6086a000
26298 arch_prctl(ARCH_SET_FS, 0x7f5c6086a6e0) =3D 0
26298 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26298 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26298 munmap(0x7f5c6086c000, 103979)    =3D 0
26298 flock(200, LOCK_EX)               =3D 0
26298 exit_group(0)                     =3D ?
27813 <... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], 0,=
 NULL) =3D 26298
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, 0x7fffb0100a24, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0xffffffffffffffff)  =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 pipe([3, 4])                      =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26299
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {0=
x436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26299 close(255 
27813 close(4 
26299 <... close resumed> )             =3D 0
27813 <... close resumed> )             =3D 0
27813 read(3,  
26299 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26299 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26299 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26299 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26299 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26299 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26299 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26299 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {S=
IG_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26299 rt_sigaction(SIGINT, {0x4481f0, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26299 dup2(4, 1)                        =3D 1
26299 close(4)                          =3D 0
26299 close(3)                          =3D 0
26299 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26299 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26299 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26299 write(2, "++ perl -e '\n            open STDIN, \"<&200\" or die $!=
;\n            my $fd_inum =3D (stat STDIN)[1]; die $! unless defined $fd=
_inum;\n            my $file_inum =3D (stat $ARGV[0])[1];\n            pr=
int \"y\\n\" if $fd_inum eq $file_inum;\n", 230) =3D 230
26299 write(2, "                             ' /var/run/xen-hotplug/block=
\n", 58) =3D 58
26299 stat(".", {st_dev=3Dmakedev(8, 2), st_ino=3D2, st_mode=3DS_IFDIR|07=
55, st_nlink=3D24, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
8, st_size=3D4096, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2012/10/08-=
11:13:38, st_ctime=3D2012/10/08-11:13:38}) =3D 0
26299 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26299 access("/usr/bin/perl", X_OK)     =3D 0
26299 access("/usr/bin/perl", R_OK)     =3D 0
26299 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26299 access("/usr/bin/perl", X_OK)     =3D 0
26299 access("/usr/bin/perl", R_OK)     =3D 0
26299 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
481f0, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26299 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26299 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26299 execve("/usr/bin/perl", ["perl", "-e", "\n            open STDIN, \=
"<&200\" or die $!;\n            my $fd_inum =3D (stat STDIN)[1]; die $! =
unless defined $fd_inum;\n            my $file_inum =3D (stat $ARGV[0])[1=
];\n            print \"y\\n\" if $fd_inum eq $file_inum;\n              =
               ", "/var/run/xen-hotplug/block"], ["SUBSYSTEM=3Dxen-backen=
d", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D/usr/b=
in:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:/usr/s=
bin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dxen-bac=
kend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3Dback=
end/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "SHLVL=
=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/perl"]) =3D 0
26299 brk(0)                            =3D 0x1993000
26299 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fed82c4e000
26299 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fed82c4d000
26299 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26299 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64/libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26299 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64", 0x7fff439ada50) =3D -1 ENOENT (No such file or directory)
26299 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/lib=
perl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26299 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls", 0=
x7fff439ada50) =3D -1 ENOENT (No such file or directory)
26299 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64/=
libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26299 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64"=
, 0x7fff439ada50) =3D -1 ENOENT (No such file or directory)
26299 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl=
=2Eso", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26299 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE", 0x7ff=
f439ada50) =3D -1 ENOENT (No such file or directory)
26299 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26299 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26299 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7fed82c33000=

26299 close(3)                          =3D 0
26299 open("/usr/lib64/libperl.so", O_RDONLY) =3D 3
26299 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\34\203%=
4\0\0\0@\0\0\0\0\0\0\0\360;\23\0\0\0\0\0\0\0\0\0@\0008\0\5\0@\0\35\0\34\0=
\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\200%4\0\0\0\0\0\200%4\0\0\0T\260\22\=
0\0\0\0\0T\260\22\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0X\260\22\0\0\0\=
0\0X\260\262%4\0\0\0X\260\262%4\0\0\0\250\201\0\0\0\0\0\0\350\242\0\0\0\0=
\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\265\22\0\0\0\0\0\370\265\262%4\0\=
0\0\370\265\262%4\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\=
0\0P\345td\4\0\0\0\250u\21\0\0\0\0\0\250u\221%4\0\0\0\250u\221%4\0\0\0D@\=
0\0\0\0\0\0D@\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\7\4\0\0\360\0\0\0\0\1\0\0\16\0\0\0\0\0\0@\0\200\203\200\225\1\22\=
264\3\31\200l\0\32\0 \5\201\0\240\3\2B\0\200\21R \0\22\0\0\16P\20#\10\216=
\334\30\211\"\0\10 \200\3B\220@\0\1\206\20\30\2\3\21\203$!\312A0\224Y\200=
\27\0\242\26\10\24R@\10\200\220\20A\10\0\220\1\200\206\2\10\304\30i\0\220=
\1\1\202\200\22\20\0\n\1H\0\n\2001J \6\31@L\207\20\10\0000\10(\200\2\0\4\=
251t\"\262\310!\212\240\320\"\0\t"..., 832) =3D 832
26299 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2839671, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D2480, st_size=3D1262384, st_atime=3D2012/10/09-12:04:35, st_mtime=3D=
2012/09/11-12:45:05, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26299 mmap(0x3425800000, 3363648, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425800000
26299 mprotect(0x342592c000, 2093056, PROT_NONE) =3D 0
26299 mmap(0x3425b2b000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x12b000) =3D 0x3425b2b000
26299 mmap(0x3425b34000, 4928, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3425b34000
26299 close(3)                          =3D 0
26299 open("/lib64/libresolv.so.2", O_RDONLY) =3D 3
26299 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\2402\0'4\0\=
0\0@\0\0\0\0\0\0\0@a\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\5\0=
\0\0@\0\0\0\0\0\0\0@\0\0'4\0\0\0@\0\0'4\0\0\0\370\1\0\0\0\0\0\0\370\1\0\0=
\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \361\0\0\0\0\0\0 \361\0'4\0\0\0=
 \361\0'4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\=
0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0'4\0\0\0\0\0\0'4\0\0\0$\10\1\0\0\0\0\0$\10=
\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\24\1\0\0\0\0\0\340\24!'4\=
0\0\0\340\24!'4\0\0\0\340\r\0\0\0\0\0\0\0106\0\0\0\0\0\0\0\0 \0\0\0\0\0\2=
\0\0\0\6\0\0\0\350\35\1\0\0\0\0\0\350\35!'4\0\0\0\350\35!'4\0\0\0\300\1\0=
\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\=
0\0\0008\2\0'4\0\0\0008\2\0'4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0=
\0\0\0\0P\345td\4\0\0\0<\361\0\0\0\0\0\0<\361\0'4\0\0\0<\361\0'4\0\0\0,\3=
\0\0\0\0\0\0,\3\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 8=
32
26299 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148119, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D192, st_size=3D92736, st_atime=3D2012/10/09-11:16:43, st_mtime=3D201=
0/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:42}) =3D 0
26299 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fed82c32000
26299 mmap(0x3427000000, 2181864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3427000000
26299 mprotect(0x3427011000, 2097152, PROT_NONE) =3D 0
26299 mmap(0x3427211000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x11000) =3D 0x3427211000
26299 mmap(0x3427213000, 6888, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3427213000
26299 close(3)                          =3D 0
26299 open("/lib64/libnsl.so.1", O_RDONLY) =3D 3
26299 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240@\340\35=
10\0\0\0@\0\0\0\0\0\0\0\360\265\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0=
\6\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\340\3510\0\0\0@\0\340\3510\0\0\0\370\1=
\0\0\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \33\1\0\0=
\0\0\0 \33\341\3510\0\0\0 \33\341\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\=
0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\340\3510\0\0\0=
\0\0\340\3510\0\0\0\310@\1\0\0\0\0\0\310@\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\=
0\0\6\0\0\0xM\1\0\0\0\0\0xM\1\3520\0\0\0xM\1\3520\0\0\0\310\5\0\0\0\0\0\0=
008-\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250M\1\0\0\0\0\0\250M\1\3=
520\0\0\0\250M\1\3520\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\340\3510\0\0\0008\2\340\351=
0\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0<\33\=
1\0\0\0\0\0<\33\341\3510\0\0\0<\33\341\3510\0\0\0\\\5\0\0\0\0\0\0\\\5\0\0=
\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26299 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147206, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D232, st_size=3D114352, st_atime=3D2012/10/09-12:01:01, st_mtime=3D20=
10/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:44}) =3D 0
26299 mmap(0x30e9e00000, 2194096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9e00000
26299 mprotect(0x30e9e15000, 2093056, PROT_NONE) =3D 0
26299 mmap(0x30ea014000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x14000) =3D 0x30ea014000
26299 mmap(0x30ea016000, 6832, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x30ea016000
26299 close(3)                          =3D 0
26299 open("/lib64/libdl.so.2", O_RDONLY) =3D 3
26299 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\16`\3500=
\0\0\0@\0\0\0\0\0\0\0@R\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0`\3500\0\0\0@\0`\3500\0\0\0\370\1\0\0\0\0\0\0\37=
0\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\300\32\0\0\0\0\0\0\300\3=
2`\3500\0\0\0\300\32`\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0`\3500\0\0\0\0\0`\3500\0\0\=
0\224\37\0\0\0\0\0\0\224\37\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0`-\=
0\0\0\0\0\0`-\200\3500\0\0\0`-\200\3500\0\0\0 \3\0\0\0\0\0\0\240\3\0\0\0\=
0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\240-\0\0\0\0\0\0\240-\200\3500\0\0\0=
\240-\200\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0=
\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2`\3500\0\0\0008\2`\3500\0\0\0 \0\0\=
0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\334\32\0\0\0\0\0\=
0\334\32`\3500\0\0\0\334\32`\3500\0\0\0\264\0\0\0\0\0\0\0\264\0\0\0\0\0\0=
\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26299 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147322, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D48, st_size=3D23360, st_atime=3D2012/10/09-11:13:54, st_mtime=3D2010=
/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26299 mmap(0x30e8600000, 2109696, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8600000
26299 mprotect(0x30e8602000, 2097152, PROT_NONE) =3D 0
26299 mmap(0x30e8802000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x2000) =3D 0x30e8802000
26299 close(3)                          =3D 0
26299 open("/lib64/libm.so.6", O_RDONLY) =3D 3
26299 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`>\240\3510\=
0\0\0@\0\0\0\0\0\0\0\240X\t\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0)\0(\0\6\0\0\=
0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3510\0\0\0@\0\240\3510\0\0\0\370\1\0\0\0\=
0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\360\303\7\0\0\0\=
0\0\360\303\247\3510\0\0\0\360\303\247\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0=
\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3510\=
0\0\0\0\0\240\3510\0\0\0000\22\10\0\0\0\0\0000\22\10\0\0\0\0\0\0\0 \0\0\0=
\0\0\1\0\0\0\6\0\0\0\270\35\10\0\0\0\0\0\270\35\310\3510\0\0\0\270\35\310=
\3510\0\0\0\320\2\0\0\0\0\0\0 \3\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0=
\0\350\35\10\0\0\0\0\0\350\35\310\3510\0\0\0\350\35\310\3510\0\0\0\300\1\=
0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0=
\0\0\0008\2\240\3510\0\0\0008\2\240\3510\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\f\304\7\0\0\0\0\0\f\304\247\3510\0\0\0=
\f\304\247\3510\0\0\0\374\r\0\0\0\0\0\0\374\r\0\0\0\0\0\0\4\0\0\0\0\0\0\0=
Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0"..., 832) =3D 832
26299 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147337, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D1216, st_size=3D615136, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2=
010/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26299 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fed82c31000
26299 mmap(0x30e9a00000, 2629848, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9a00000
26299 mprotect(0x30e9a82000, 2093056, PROT_NONE) =3D 0
26299 mmap(0x30e9c81000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x81000) =3D 0x30e9c81000
26299 close(3)                          =3D 0
26299 open("/lib64/libcrypt.so.1", O_RDONLY) =3D 3
26299 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\t\300%4=
\0\0\0@\0\0\0\0\0\0\0\30\265\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\=
0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\300%4\0\0\0@\0\300%4\0\0\0\370\1\0\0\0\0\=
0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340}\0\0\0\0\0\0\3=
40}\300%4\0\0\0\340}\300%4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\300%4\0\0\0\0\0\300%4\0\0\=
0\4\205\0\0\0\0\0\0\4\205\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\310\=
215\0\0\0\0\0\0\310\215\340%4\0\0\0\310\215\340%4\0\0\0\250\2\0\0\0\0\0\0=
\370\343\2\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\215\0\0\0\0\0\0\3=
70\215\340%4\0\0\0\370\215\340%4\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\=
0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\300%4\0\0\0008\2=
\300%4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0=
\374}\0\0\0\0\0\0\374}\300%4\0\0\0\374}\300%4\0\0\0\34\1\0\0\0\0\0\0\34\1=
\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26299 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148123, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D96, st_size=3D48600, st_atime=3D2012/10/09-12:01:01, st_mtime=3D2010=
/07/28-03:52:39, st_ctime=3D2012/09/11-14:53:52}) =3D 0
26299 mmap(0x3425c00000, 2322880, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425c00000
26299 mprotect(0x3425c09000, 2093056, PROT_NONE) =3D 0
26299 mmap(0x3425e08000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x8000) =3D 0x3425e08000
26299 mmap(0x3425e0a000, 184768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FI=
XED|MAP_ANONYMOUS, -1, 0) =3D 0x3425e0a000
26299 close(3)                          =3D 0
26299 open("/lib64/libutil.so.1", O_RDONLY) =3D 3
26299 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\16\0(4\=
0\0\0@\0\0\0\0\0\0\0(>\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0\0(4\0\0\0@\0\0(4\0\0\0\370\1\0\0\0\0\0\0\370\1\=
0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340\26\0\0\0\0\0\0\340\26\0(=
4\0\0\0\340\26\0(4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0=
\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0(4\0\0\0\0\0\0(4\0\0\0P\32\0\0\0\=
0\0\0P\32\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\35\0\0\0\0\0\0\3=
40\35 (4\0\0\0\340\35 (4\0\0\0 \3\0\0\0\0\0\0000\3\0\0\0\0\0\0\0\0 \0\0\0=
\0\0\2\0\0\0\6\0\0\0\20\36\0\0\0\0\0\0\20\36 (4\0\0\0\20\36 (4\0\0\0\300\=
1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0=
\0\0\0\0008\2\0(4\0\0\0008\2\0(4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\=
0\0\0\0\0\0P\345td\4\0\0\0\374\26\0\0\0\0\0\0\374\26\0(4\0\0\0\374\26\0(4=
\0\0\0D\0\0\0\0\0\0\0D\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8=
32) =3D 832
26299 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147063, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D40, st_size=3D18152, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2010=
/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:49}) =3D 0
26299 mmap(0x3428000000, 2105616, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3428000000
26299 mprotect(0x3428002000, 2093056, PROT_NONE) =3D 0
26299 mmap(0x3428201000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x1000) =3D 0x3428201000
26299 close(3)                          =3D 0
26299 open("/lib64/libpthread.so.0", O_RDONLY) =3D 3
26299 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240W\240\35=
00\0\0\0@\0\0\0\0\0\0\0\340/\2\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0'\0&\0\6\0=
\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3500\0\0\0@\0\240\3500\0\0\0\370\1\0\0=
\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\240\t\1\0\0\0=
\0\0\240\t\241\3500\0\0\0\240\t\241\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\=
0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3500\0\0=
\0\0\0\240\3500\0\0\0pZ\1\0\0\0\0\0pZ\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\=
6\0\0\0\270[\1\0\0\0\0\0\270[\301\3500\0\0\0\270[\301\3500\0\0\0\230\6\0\=
0\0\0\0\0\270G\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250]\1\0\0\0\0\=
0\250]\301\3500\0\0\0\250]\301\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0=
\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\240\3500\0\0\=
0008\2\240\3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345t=
d\4\0\0\0\274\t\1\0\0\0\0\0\274\t\241\3500\0\0\0\274\t\241\3500\0\0\0\344=
\t\0\0\0\0\0\0\344\t\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =
=3D 832
26299 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147328, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D296, st_size=3D145824, st_atime=3D2012/10/09-11:16:43, st_mtime=3D20=
10/07/28-03:52:41, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26299 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fed82c30000
26299 mmap(0x30e8a00000, 2204528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8a00000
26299 mprotect(0x30e8a16000, 2093056, PROT_NONE) =3D 0
26299 mmap(0x30e8c15000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x15000) =3D 0x30e8c15000
26299 mmap(0x30e8c17000, 13168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8c17000
26299 close(3)                          =3D 0
26299 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26299 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26299 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26299 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26299 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26299 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26299 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26299 close(3)                          =3D 0
26299 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fed82c2f000
26299 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fed82c2e000
26299 arch_prctl(ARCH_SET_FS, 0x7fed82c2e6e0) =3D 0
26299 mprotect(0x3427211000, 4096, PROT_READ) =3D 0
26299 mprotect(0x30ea014000, 4096, PROT_READ) =3D 0
26299 mprotect(0x30e8802000, 4096, PROT_READ) =3D 0
26299 mprotect(0x30e9c81000, 4096, PROT_READ) =3D 0
26299 mprotect(0x3425e08000, 4096, PROT_READ) =3D 0
26299 mprotect(0x3428201000, 4096, PROT_READ) =3D 0
26299 mprotect(0x30e8c15000, 4096, PROT_READ) =3D 0
26299 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26299 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26299 munmap(0x7fed82c33000, 103979)    =3D 0
26299 set_tid_address(0x7fed82c2e770)   =3D 26299
26299 set_robust_list(0x7fed82c2e780, 0x18) =3D 0
26299 futex(0x7fff439ae57c, FUTEX_WAKE_PRIVATE, 1) =3D 0
26299 rt_sigaction(SIGRTMIN, {0x30e8a05380, [], SA_RESTORER|SA_SIGINFO, 0=
x30e8a0eb10}, NULL, 8) =3D 0
26299 rt_sigaction(SIGRT_1, {0x30e8a052b0, [], SA_RESTORER|SA_RESTART|SA_=
SIGINFO, 0x30e8a0eb10}, NULL, 8) =3D 0
26299 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) =3D 0
26299 getrlimit(RLIMIT_STACK, {rlim_cur=3D8192*1024, rlim_max=3DRLIM_INFI=
NITY}) =3D 0
26299 rt_sigaction(SIGFPE, {0x1, [FPE], SA_RESTORER|SA_RESTART, 0x30e8230=
2d0}, {SIG_DFL, [], 0}, 8) =3D 0
26299 brk(0)                            =3D 0x1993000
26299 brk(0x19b5000)                    =3D 0x19b5000
26299 getuid()                          =3D 0
26299 geteuid()                         =3D 0
26299 getgid()                          =3D 0
26299 getegid()                         =3D 0
26299 mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,=
 -1, 0) =3D 0x7fed82c0d000
26299 open("/dev/urandom", O_RDONLY)    =3D 3
26299 read(3, "\371\n\f&", 4)           =3D 4
26299 close(3)                          =3D 0
26299 stat("/usr/lib64/perl5/site_perl/5.8.7/x86_64-linux-thread-multi", =
0x7fff439ae230) =3D -1 ENOENT (No such file or directory)
26299 stat("/usr/lib/perl5/site_perl/5.8.7", 0x7fff439ae230) =3D -1 ENOEN=
T (No such file or directory)
26299 stat("/usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi", =
0x7fff439ae230) =3D -1 ENOENT (No such file or directory)
26299 stat("/usr/lib/perl5/site_perl/5.8.6", 0x7fff439ae230) =3D -1 ENOEN=
T (No such file or directory)
26299 stat("/usr/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi", =
0x7fff439ae230) =3D -1 ENOENT (No such file or directory)
26299 stat("/usr/lib/perl5/site_perl/5.8.5", 0x7fff439ae230) =3D -1 ENOEN=
T (No such file or directory)
26299 stat("/usr/lib64/perl5/vendor_perl/5.8.7/x86_64-linux-thread-multi"=
, 0x7fff439ae230) =3D -1 ENOENT (No such file or directory)
26299 stat("/usr/lib/perl5/vendor_perl/5.8.7", 0x7fff439ae230) =3D -1 ENO=
ENT (No such file or directory)
26299 stat("/usr/lib64/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi"=
, 0x7fff439ae230) =3D -1 ENOENT (No such file or directory)
26299 stat("/usr/lib/perl5/vendor_perl/5.8.6", 0x7fff439ae230) =3D -1 ENO=
ENT (No such file or directory)
26299 stat("/usr/lib64/perl5/vendor_perl/5.8.5/x86_64-linux-thread-multi"=
, 0x7fff439ae230) =3D -1 ENOENT (No such file or directory)
26299 stat("/usr/lib/perl5/vendor_perl/5.8.5", 0x7fff439ae230) =3D -1 ENO=
ENT (No such file or directory)
26299 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff439adff0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26299 lseek(0, 0, SEEK_CUR)             =3D 0
26299 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff439adff0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26299 lseek(1, 0, SEEK_CUR)             =3D -1 ESPIPE (Illegal seek)
26299 ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff439ae000) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26299 lseek(2, 0, SEEK_CUR)             =3D 593661861
26299 open("/dev/null", O_RDONLY)       =3D 3
26299 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff439ae100) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26299 lseek(3, 0, SEEK_CUR)             =3D 0
26299 fcntl(3, F_SETFD, FD_CLOEXEC)     =3D 0
26299 fstat(3, {st_dev=3Dmakedev(0, 16), st_ino=3D584, st_mode=3DS_IFCHR|=
0666, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
0, st_rdev=3Dmakedev(1, 3), st_atime=3D2012/10/08-11:13:26, st_mtime=3D20=
12/10/08-11:13:26, st_ctime=3D2012/10/08-11:13:27}) =3D 0
26299 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) =3D 0
26299 readlink("/proc/self/exe", "/usr/bin/perl"..., 4095) =3D 13
26299 brk(0x19d6000)                    =3D 0x19d6000
26299 close(3)                          =3D 0
26299 dup(200)                          =3D 3
26299 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff439adfd0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26299 lseek(3, 0, SEEK_CUR)             =3D 0
26299 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26299 dup2(3, 0)                        =3D 0
26299 close(3)                          =3D 0
26299 fcntl(0, F_SETFD, 0)              =3D 0
26299 fstat(0, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26299 stat("/var/run/xen-hotplug/block", {st_dev=3Dmakedev(8, 2), st_ino=3D=
2801738, st_mode=3DS_IFREG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st=
_blksize=3D4096, st_blocks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:=
24, st_mtime=3D2012/10/09-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D =
0
26299 exit_group(0)                     =3D ?
27813 <... read resumed> "", 128)       =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], WNOHANG, NUL=
L) =3D 26299
27813 wait4(-1, 0x7fffb0100a64, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0)                   =3D 0
27813 close(3)                          =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 write(2, "+ rightfile=3D\n", 13)    =3D 13
27813 write(2, "+ '[' x =3D xy ']'\n", 17) =3D 17
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ true\n", 7)           =3D 7
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ eval 'exec 200>>/var/run/xen-hotplug/block'\n", 46) =3D=
 46
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 write(2, "++ exec\n", 8)          =3D 8
27813 open("/var/run/xen-hotplug/block", O_WRONLY|O_CREAT|O_APPEND, 0666)=
 =3D 3
27813 fcntl(200, F_GETFD)               =3D 0
27813 fcntl(200, F_DUPFD, 10)           =3D 10
27813 fcntl(200, F_GETFD)               =3D 0
27813 dup2(3, 200)                      =3D 200
27813 close(3)                          =3D 0
27813 dup2(10, 200)                     =3D 200
27813 fcntl(10, F_GETFD)                =3D 0
27813 close(10)                         =3D 0
27813 write(2, "+ flock -x 200\n", 15)  =3D 15
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [INT CHLD], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [INT CHLD], NULL, 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26300
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26300 close(255 
27813 rt_sigprocmask(SIG_BLOCK, [CHLD],  
26300 <... close resumed> )             =3D 0
27813 <... rt_sigprocmask resumed> [], 8) =3D 0
26300 rt_sigprocmask(SIG_SETMASK, [],  
27813 rt_sigprocmask(SIG_SETMASK, [],  
26300 <... rt_sigprocmask resumed> NULL, 8) =3D 0
27813 <... rt_sigprocmask resumed> NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD],  
26300 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 <... rt_sigprocmask resumed> [], 8) =3D 0
26300 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0},  
26300 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 <... rt_sigaction resumed> {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}=
, 8) =3D 0
26300 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
27813 wait4(-1,  
26300 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26300 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26300 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26300 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26300 execve("/usr/bin/flock", ["flock", "-x", "200"], ["SUBSYSTEM=3Dxen-=
backend", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D=
/usr/bin:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:=
/usr/sbin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dx=
en-backend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3D=
backend/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "S=
HLVL=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/flock"]) =3D 0=

26300 brk(0)                            =3D 0x1e53000
26300 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f5293893000
26300 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f5293892000
26300 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26300 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26300 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26300 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7f5293878000=

26300 close(3)                          =3D 0
26300 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26300 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26300 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26300 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26300 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26300 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26300 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26300 close(3)                          =3D 0
26300 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f5293877000
26300 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f5293876000
26300 arch_prctl(ARCH_SET_FS, 0x7f52938766e0) =3D 0
26300 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26300 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26300 munmap(0x7f5293878000, 103979)    =3D 0
26300 flock(200, LOCK_EX)               =3D 0
26300 exit_group(0)                     =3D ?
27813 <... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], 0,=
 NULL) =3D 26300
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, 0x7fffb0100a24, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0xffffffffffffffff)  =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 pipe([3, 4])                      =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26301
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {0=
x436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26301 close(255 
27813 close(4 
26301 <... close resumed> )             =3D 0
27813 <... close resumed> )             =3D 0
27813 read(3,  
26301 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26301 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26301 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26301 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26301 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26301 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26301 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26301 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {S=
IG_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26301 rt_sigaction(SIGINT, {0x4481f0, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26301 dup2(4, 1)                        =3D 1
26301 close(4)                          =3D 0
26301 close(3)                          =3D 0
26301 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26301 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26301 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26301 write(2, "++ perl -e '\n            open STDIN, \"<&200\" or die $!=
;\n            my $fd_inum =3D (stat STDIN)[1]; die $! unless defined $fd=
_inum;\n            my $file_inum =3D (stat $ARGV[0])[1];\n            pr=
int \"y\\n\" if $fd_inum eq $file_inum;\n", 230) =3D 230
26301 write(2, "                             ' /var/run/xen-hotplug/block=
\n", 58) =3D 58
26301 stat(".", {st_dev=3Dmakedev(8, 2), st_ino=3D2, st_mode=3DS_IFDIR|07=
55, st_nlink=3D24, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
8, st_size=3D4096, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2012/10/08-=
11:13:38, st_ctime=3D2012/10/08-11:13:38}) =3D 0
26301 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26301 access("/usr/bin/perl", X_OK)     =3D 0
26301 access("/usr/bin/perl", R_OK)     =3D 0
26301 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26301 access("/usr/bin/perl", X_OK)     =3D 0
26301 access("/usr/bin/perl", R_OK)     =3D 0
26301 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
481f0, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26301 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26301 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26301 execve("/usr/bin/perl", ["perl", "-e", "\n            open STDIN, \=
"<&200\" or die $!;\n            my $fd_inum =3D (stat STDIN)[1]; die $! =
unless defined $fd_inum;\n            my $file_inum =3D (stat $ARGV[0])[1=
];\n            print \"y\\n\" if $fd_inum eq $file_inum;\n              =
               ", "/var/run/xen-hotplug/block"], ["SUBSYSTEM=3Dxen-backen=
d", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D/usr/b=
in:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:/usr/s=
bin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dxen-bac=
kend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3Dback=
end/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "SHLVL=
=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/perl"]) =3D 0
26301 brk(0)                            =3D 0x1c9b000
26301 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f022f061000
26301 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f022f060000
26301 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26301 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64/libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26301 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64", 0x7fffca5d8230) =3D -1 ENOENT (No such file or directory)
26301 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/lib=
perl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26301 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls", 0=
x7fffca5d8230) =3D -1 ENOENT (No such file or directory)
26301 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64/=
libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26301 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64"=
, 0x7fffca5d8230) =3D -1 ENOENT (No such file or directory)
26301 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl=
=2Eso", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26301 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE", 0x7ff=
fca5d8230) =3D -1 ENOENT (No such file or directory)
26301 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26301 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26301 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7f022f046000=

26301 close(3)                          =3D 0
26301 open("/usr/lib64/libperl.so", O_RDONLY) =3D 3
26301 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\34\203%=
4\0\0\0@\0\0\0\0\0\0\0\360;\23\0\0\0\0\0\0\0\0\0@\0008\0\5\0@\0\35\0\34\0=
\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\200%4\0\0\0\0\0\200%4\0\0\0T\260\22\=
0\0\0\0\0T\260\22\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0X\260\22\0\0\0\=
0\0X\260\262%4\0\0\0X\260\262%4\0\0\0\250\201\0\0\0\0\0\0\350\242\0\0\0\0=
\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\265\22\0\0\0\0\0\370\265\262%4\0\=
0\0\370\265\262%4\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\=
0\0P\345td\4\0\0\0\250u\21\0\0\0\0\0\250u\221%4\0\0\0\250u\221%4\0\0\0D@\=
0\0\0\0\0\0D@\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\7\4\0\0\360\0\0\0\0\1\0\0\16\0\0\0\0\0\0@\0\200\203\200\225\1\22\=
264\3\31\200l\0\32\0 \5\201\0\240\3\2B\0\200\21R \0\22\0\0\16P\20#\10\216=
\334\30\211\"\0\10 \200\3B\220@\0\1\206\20\30\2\3\21\203$!\312A0\224Y\200=
\27\0\242\26\10\24R@\10\200\220\20A\10\0\220\1\200\206\2\10\304\30i\0\220=
\1\1\202\200\22\20\0\n\1H\0\n\2001J \6\31@L\207\20\10\0000\10(\200\2\0\4\=
251t\"\262\310!\212\240\320\"\0\t"..., 832) =3D 832
26301 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2839671, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D2480, st_size=3D1262384, st_atime=3D2012/10/09-12:04:35, st_mtime=3D=
2012/09/11-12:45:05, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26301 mmap(0x3425800000, 3363648, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425800000
26301 mprotect(0x342592c000, 2093056, PROT_NONE) =3D 0
26301 mmap(0x3425b2b000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x12b000) =3D 0x3425b2b000
26301 mmap(0x3425b34000, 4928, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3425b34000
26301 close(3)                          =3D 0
26301 open("/lib64/libresolv.so.2", O_RDONLY) =3D 3
26301 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\2402\0'4\0\=
0\0@\0\0\0\0\0\0\0@a\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\5\0=
\0\0@\0\0\0\0\0\0\0@\0\0'4\0\0\0@\0\0'4\0\0\0\370\1\0\0\0\0\0\0\370\1\0\0=
\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \361\0\0\0\0\0\0 \361\0'4\0\0\0=
 \361\0'4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\=
0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0'4\0\0\0\0\0\0'4\0\0\0$\10\1\0\0\0\0\0$\10=
\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\24\1\0\0\0\0\0\340\24!'4\=
0\0\0\340\24!'4\0\0\0\340\r\0\0\0\0\0\0\0106\0\0\0\0\0\0\0\0 \0\0\0\0\0\2=
\0\0\0\6\0\0\0\350\35\1\0\0\0\0\0\350\35!'4\0\0\0\350\35!'4\0\0\0\300\1\0=
\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\=
0\0\0008\2\0'4\0\0\0008\2\0'4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0=
\0\0\0\0P\345td\4\0\0\0<\361\0\0\0\0\0\0<\361\0'4\0\0\0<\361\0'4\0\0\0,\3=
\0\0\0\0\0\0,\3\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 8=
32
26301 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148119, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D192, st_size=3D92736, st_atime=3D2012/10/09-11:16:43, st_mtime=3D201=
0/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:42}) =3D 0
26301 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f022f045000
26301 mmap(0x3427000000, 2181864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3427000000
26301 mprotect(0x3427011000, 2097152, PROT_NONE) =3D 0
26301 mmap(0x3427211000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x11000) =3D 0x3427211000
26301 mmap(0x3427213000, 6888, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3427213000
26301 close(3)                          =3D 0
26301 open("/lib64/libnsl.so.1", O_RDONLY) =3D 3
26301 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240@\340\35=
10\0\0\0@\0\0\0\0\0\0\0\360\265\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0=
\6\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\340\3510\0\0\0@\0\340\3510\0\0\0\370\1=
\0\0\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \33\1\0\0=
\0\0\0 \33\341\3510\0\0\0 \33\341\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\=
0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\340\3510\0\0\0=
\0\0\340\3510\0\0\0\310@\1\0\0\0\0\0\310@\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\=
0\0\6\0\0\0xM\1\0\0\0\0\0xM\1\3520\0\0\0xM\1\3520\0\0\0\310\5\0\0\0\0\0\0=
008-\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250M\1\0\0\0\0\0\250M\1\3=
520\0\0\0\250M\1\3520\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\340\3510\0\0\0008\2\340\351=
0\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0<\33\=
1\0\0\0\0\0<\33\341\3510\0\0\0<\33\341\3510\0\0\0\\\5\0\0\0\0\0\0\\\5\0\0=
\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26301 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147206, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D232, st_size=3D114352, st_atime=3D2012/10/09-12:01:01, st_mtime=3D20=
10/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:44}) =3D 0
26301 mmap(0x30e9e00000, 2194096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9e00000
26301 mprotect(0x30e9e15000, 2093056, PROT_NONE) =3D 0
26301 mmap(0x30ea014000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x14000) =3D 0x30ea014000
26301 mmap(0x30ea016000, 6832, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x30ea016000
26301 close(3)                          =3D 0
26301 open("/lib64/libdl.so.2", O_RDONLY) =3D 3
26301 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\16`\3500=
\0\0\0@\0\0\0\0\0\0\0@R\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0`\3500\0\0\0@\0`\3500\0\0\0\370\1\0\0\0\0\0\0\37=
0\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\300\32\0\0\0\0\0\0\300\3=
2`\3500\0\0\0\300\32`\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0`\3500\0\0\0\0\0`\3500\0\0\=
0\224\37\0\0\0\0\0\0\224\37\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0`-\=
0\0\0\0\0\0`-\200\3500\0\0\0`-\200\3500\0\0\0 \3\0\0\0\0\0\0\240\3\0\0\0\=
0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\240-\0\0\0\0\0\0\240-\200\3500\0\0\0=
\240-\200\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0=
\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2`\3500\0\0\0008\2`\3500\0\0\0 \0\0\=
0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\334\32\0\0\0\0\0\=
0\334\32`\3500\0\0\0\334\32`\3500\0\0\0\264\0\0\0\0\0\0\0\264\0\0\0\0\0\0=
\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26301 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147322, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D48, st_size=3D23360, st_atime=3D2012/10/09-11:13:54, st_mtime=3D2010=
/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26301 mmap(0x30e8600000, 2109696, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8600000
26301 mprotect(0x30e8602000, 2097152, PROT_NONE) =3D 0
26301 mmap(0x30e8802000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x2000) =3D 0x30e8802000
26301 close(3)                          =3D 0
26301 open("/lib64/libm.so.6", O_RDONLY) =3D 3
26301 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`>\240\3510\=
0\0\0@\0\0\0\0\0\0\0\240X\t\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0)\0(\0\6\0\0\=
0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3510\0\0\0@\0\240\3510\0\0\0\370\1\0\0\0\=
0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\360\303\7\0\0\0\=
0\0\360\303\247\3510\0\0\0\360\303\247\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0=
\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3510\=
0\0\0\0\0\240\3510\0\0\0000\22\10\0\0\0\0\0000\22\10\0\0\0\0\0\0\0 \0\0\0=
\0\0\1\0\0\0\6\0\0\0\270\35\10\0\0\0\0\0\270\35\310\3510\0\0\0\270\35\310=
\3510\0\0\0\320\2\0\0\0\0\0\0 \3\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0=
\0\350\35\10\0\0\0\0\0\350\35\310\3510\0\0\0\350\35\310\3510\0\0\0\300\1\=
0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0=
\0\0\0008\2\240\3510\0\0\0008\2\240\3510\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\f\304\7\0\0\0\0\0\f\304\247\3510\0\0\0=
\f\304\247\3510\0\0\0\374\r\0\0\0\0\0\0\374\r\0\0\0\0\0\0\4\0\0\0\0\0\0\0=
Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0"..., 832) =3D 832
26301 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147337, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D1216, st_size=3D615136, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2=
010/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26301 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f022f044000
26301 mmap(0x30e9a00000, 2629848, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9a00000
26301 mprotect(0x30e9a82000, 2093056, PROT_NONE) =3D 0
26301 mmap(0x30e9c81000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x81000) =3D 0x30e9c81000
26301 close(3)                          =3D 0
26301 open("/lib64/libcrypt.so.1", O_RDONLY) =3D 3
26301 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\t\300%4=
\0\0\0@\0\0\0\0\0\0\0\30\265\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\=
0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\300%4\0\0\0@\0\300%4\0\0\0\370\1\0\0\0\0\=
0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340}\0\0\0\0\0\0\3=
40}\300%4\0\0\0\340}\300%4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\300%4\0\0\0\0\0\300%4\0\0\=
0\4\205\0\0\0\0\0\0\4\205\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\310\=
215\0\0\0\0\0\0\310\215\340%4\0\0\0\310\215\340%4\0\0\0\250\2\0\0\0\0\0\0=
\370\343\2\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\215\0\0\0\0\0\0\3=
70\215\340%4\0\0\0\370\215\340%4\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\=
0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\300%4\0\0\0008\2=
\300%4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0=
\374}\0\0\0\0\0\0\374}\300%4\0\0\0\374}\300%4\0\0\0\34\1\0\0\0\0\0\0\34\1=
\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26301 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148123, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D96, st_size=3D48600, st_atime=3D2012/10/09-12:01:01, st_mtime=3D2010=
/07/28-03:52:39, st_ctime=3D2012/09/11-14:53:52}) =3D 0
26301 mmap(0x3425c00000, 2322880, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425c00000
26301 mprotect(0x3425c09000, 2093056, PROT_NONE) =3D 0
26301 mmap(0x3425e08000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x8000) =3D 0x3425e08000
26301 mmap(0x3425e0a000, 184768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FI=
XED|MAP_ANONYMOUS, -1, 0) =3D 0x3425e0a000
26301 close(3)                          =3D 0
26301 open("/lib64/libutil.so.1", O_RDONLY) =3D 3
26301 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\16\0(4\=
0\0\0@\0\0\0\0\0\0\0(>\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0\0(4\0\0\0@\0\0(4\0\0\0\370\1\0\0\0\0\0\0\370\1\=
0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340\26\0\0\0\0\0\0\340\26\0(=
4\0\0\0\340\26\0(4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0=
\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0(4\0\0\0\0\0\0(4\0\0\0P\32\0\0\0\=
0\0\0P\32\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\35\0\0\0\0\0\0\3=
40\35 (4\0\0\0\340\35 (4\0\0\0 \3\0\0\0\0\0\0000\3\0\0\0\0\0\0\0\0 \0\0\0=
\0\0\2\0\0\0\6\0\0\0\20\36\0\0\0\0\0\0\20\36 (4\0\0\0\20\36 (4\0\0\0\300\=
1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0=
\0\0\0\0008\2\0(4\0\0\0008\2\0(4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\=
0\0\0\0\0\0P\345td\4\0\0\0\374\26\0\0\0\0\0\0\374\26\0(4\0\0\0\374\26\0(4=
\0\0\0D\0\0\0\0\0\0\0D\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8=
32) =3D 832

--------------030802060607050703070201
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------030802060607050703070201--


From xen-devel-bounces@lists.xen.org Tue Oct 09 09:33:03 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 09:33:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLWAo-00080V-M1; Tue, 09 Oct 2012 09:32:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLVZq-00074W-B6
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 08:54:11 +0000
Received: from [85.158.143.99:8758] by server-3.bemta-4.messagelabs.com id
	2A/8B-10986-136E3705; Tue, 09 Oct 2012 08:54:09 +0000
X-Env-Sender: zhenzhong.duan@oracle.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1349772845!23781541!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzkwNDA2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20941 invoked from network); 9 Oct 2012 08:54:06 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Oct 2012 08:54:06 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q998rwIQ016710
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 9 Oct 2012 08:53:59 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q998ruEK016558
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 9 Oct 2012 08:53:56 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q998rt2W004074; Tue, 9 Oct 2012 03:53:56 -0500
Received: from zhenzhong2.localdomain (/10.182.39.88)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 09 Oct 2012 01:53:52 -0700
Message-ID: <5073E61B.1010305@oracle.com>
Date: Tue, 09 Oct 2012 16:53:47 +0800
From: DuanZhenzhong 
Organization: Oracle Corporation
User-Agent: Thunderbird 2.0.0.24 (X11/20101209)
MIME-Version: 1.0
To: Ian Jackson 
References: <505C3647.1030003@oracle.com>	<20120921143430.GA3522@phenom.dumpdata.com>	<5062C16A.1020306@oracle.com>	<20120926123534.GF7356@phenom.dumpdata.com>	<5063EAFB.1070307@oracle.com>	<20120927115918.GE8832@phenom.dumpdata.com>	<50657D4B.9040303@oracle.com>	<20120928140109.GA7483@localhost.localdomain>	<20581.45245.846208.289785@mariner.uk.xensource.com>	<5065B82B.8080003@oracle.com>
	<20587.342.66210.677204@mariner.uk.xensource.com>
In-Reply-To: <20587.342.66210.677204@mariner.uk.xensource.com>
Content-Type: multipart/mixed; boundary="------------030802060607050703070201"
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-Mailman-Approved-At: Tue, 09 Oct 2012 09:32:21 +0000
Cc: Konrad Rzeszutek Wilk ,
	Dan Magenheimer ,
	Konrad Rzeszutek Wilk ,
	Feng Jin , xen-devel 
Subject: Re: [Xen-devel] Is: Contention in block script when doing guest
 saving. Was:Re: an issue with 'xm save'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--------------030802060607050703070201
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ian Jackson wrote:
> Zhenzhong Duan writes ("Re: [Xen-devel] Is: Contention in block script when doing guest saving. Was:Re: an issue with 'xm save'"):
>   
>> Attachment is part of xen-hotplug.log that will show the spin.
>> Original file is nearly 7G big. I fetch first 1000 lines.
>>     
>
> Thanks.  This is quite mystifying to me.
>
>
> Picking a representative example, and translating it to what I think
> the syscalls would be:
>
>   
>> + eval 'exec 200>>/var/run/xen-hotplug/block'
>> ++ exec
>>     
>
>   fd = open("/var/run/xen-hotplug/block", O_WRONLY|O_APPEND|O_CREAT, 0666);
>   dup2(fd, 200);
>   close(fd);
>
>   
>> + flock -x 200
>>     
>
>   flock(200, LOCK_EX);
>
>   
>> ++ perl -e '
>>             open STDIN, "<&200" or die $!;
>>     
>
>   dup2(200, 0);
>
>   
>>             my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
>>     
>
>   fstat(0, &stdin_stat);
>
>   
>>             my $file_inum = (stat $ARGV[0])[1];
>>     
>
>   stat("/var/run/xen-hotplug/block", &file_stat);
>
>   
>>             print "y\n" if $fd_inum eq $file_inum;
>>     
>
>   if (stdin_stat.st_ino == file_stat.st_ino)
>       puts("y");
>
>   
>>                              ' /var/run/xen-hotplug/block
>> + rightfile=
>>     
>
> And here we see that perl didn't print "y" so the two files must be
> different.
>
>
> Let's try something else: can you strace it ?  That is, get it to the
> point where it's spinning, find the pid of the relevant shell process,
> and
>    strace -f -vvs500 -ooutput.strace PID
> where PID is the pid in question ?
>
> Let that run for a fraction of a second and then ^C it.
>
> The output may shed some light.
>
> Thanks,
> Ian.
>   
Hi Ian,
Sorry for late, just back from vocation today.
Your requested strace info attached, any info you need, let me know.

-- 
Regards
zhenzhong
--
Oracle Building, No.24 Building, Zhongguancun Software Park
Haidian District, Beijing 100193, China


--------------030802060607050703070201
Content-Type: text/plain;
 name="output.strace"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline;
 filename="output.strace"

27813 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], 0, NULL) =3D=
 26268
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, 0x7fffb0100a24, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0xffffffffffffffff)  =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 pipe([3, 4])                      =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26269
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {0=
x436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26269 close(255 
27813 close(4 
26269 <... close resumed> )             =3D 0
27813 <... close resumed> )             =3D 0
27813 read(3,  
26269 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26269 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26269 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26269 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26269 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26269 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26269 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26269 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {S=
IG_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26269 rt_sigaction(SIGINT, {0x4481f0, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26269 dup2(4, 1)                        =3D 1
26269 close(4)                          =3D 0
26269 close(3)                          =3D 0
26269 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26269 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26269 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26269 write(2, "++ perl -e '\n            open STDIN, \"<&200\" or die $!=
;\n            my $fd_inum =3D (stat STDIN)[1]; die $! unless defined $fd=
_inum;\n            my $file_inum =3D (stat $ARGV[0])[1];\n            pr=
int \"y\\n\" if $fd_inum eq $file_inum;\n", 230) =3D 230
26269 write(2, "                             ' /var/run/xen-hotplug/block=
\n", 58) =3D 58
26269 stat(".", {st_dev=3Dmakedev(8, 2), st_ino=3D2, st_mode=3DS_IFDIR|07=
55, st_nlink=3D24, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
8, st_size=3D4096, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2012/10/08-=
11:13:38, st_ctime=3D2012/10/08-11:13:38}) =3D 0
26269 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26269 access("/usr/bin/perl", X_OK)     =3D 0
26269 access("/usr/bin/perl", R_OK)     =3D 0
26269 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26269 access("/usr/bin/perl", X_OK)     =3D 0
26269 access("/usr/bin/perl", R_OK)     =3D 0
26269 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
481f0, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26269 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26269 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26269 execve("/usr/bin/perl", ["perl", "-e", "\n            open STDIN, \=
"<&200\" or die $!;\n            my $fd_inum =3D (stat STDIN)[1]; die $! =
unless defined $fd_inum;\n            my $file_inum =3D (stat $ARGV[0])[1=
];\n            print \"y\\n\" if $fd_inum eq $file_inum;\n              =
               ", "/var/run/xen-hotplug/block"], ["SUBSYSTEM=3Dxen-backen=
d", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D/usr/b=
in:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:/usr/s=
bin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dxen-bac=
kend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3Dback=
end/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "SHLVL=
=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/perl"]) =3D 0
26269 brk(0)                            =3D 0x1a99000
26269 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fdb21f8b000
26269 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fdb21f8a000
26269 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26269 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64/libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26269 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64", 0x7fffced48b50) =3D -1 ENOENT (No such file or directory)
26269 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/lib=
perl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26269 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls", 0=
x7fffced48b50) =3D -1 ENOENT (No such file or directory)
26269 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64/=
libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26269 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64"=
, 0x7fffced48b50) =3D -1 ENOENT (No such file or directory)
26269 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl=
=2Eso", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26269 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE", 0x7ff=
fced48b50) =3D -1 ENOENT (No such file or directory)
26269 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26269 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26269 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7fdb21f70000=

26269 close(3)                          =3D 0
26269 open("/usr/lib64/libperl.so", O_RDONLY) =3D 3
26269 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\34\203%=
4\0\0\0@\0\0\0\0\0\0\0\360;\23\0\0\0\0\0\0\0\0\0@\0008\0\5\0@\0\35\0\34\0=
\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\200%4\0\0\0\0\0\200%4\0\0\0T\260\22\=
0\0\0\0\0T\260\22\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0X\260\22\0\0\0\=
0\0X\260\262%4\0\0\0X\260\262%4\0\0\0\250\201\0\0\0\0\0\0\350\242\0\0\0\0=
\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\265\22\0\0\0\0\0\370\265\262%4\0\=
0\0\370\265\262%4\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\=
0\0P\345td\4\0\0\0\250u\21\0\0\0\0\0\250u\221%4\0\0\0\250u\221%4\0\0\0D@\=
0\0\0\0\0\0D@\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\7\4\0\0\360\0\0\0\0\1\0\0\16\0\0\0\0\0\0@\0\200\203\200\225\1\22\=
264\3\31\200l\0\32\0 \5\201\0\240\3\2B\0\200\21R \0\22\0\0\16P\20#\10\216=
\334\30\211\"\0\10 \200\3B\220@\0\1\206\20\30\2\3\21\203$!\312A0\224Y\200=
\27\0\242\26\10\24R@\10\200\220\20A\10\0\220\1\200\206\2\10\304\30i\0\220=
\1\1\202\200\22\20\0\n\1H\0\n\2001J \6\31@L\207\20\10\0000\10(\200\2\0\4\=
251t\"\262\310!\212\240\320\"\0\t"..., 832) =3D 832
26269 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2839671, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D2480, st_size=3D1262384, st_atime=3D2012/10/09-12:04:35, st_mtime=3D=
2012/09/11-12:45:05, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26269 mmap(0x3425800000, 3363648, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425800000
26269 mprotect(0x342592c000, 2093056, PROT_NONE) =3D 0
26269 mmap(0x3425b2b000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x12b000) =3D 0x3425b2b000
26269 mmap(0x3425b34000, 4928, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3425b34000
26269 close(3)                          =3D 0
26269 open("/lib64/libresolv.so.2", O_RDONLY) =3D 3
26269 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\2402\0'4\0\=
0\0@\0\0\0\0\0\0\0@a\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\5\0=
\0\0@\0\0\0\0\0\0\0@\0\0'4\0\0\0@\0\0'4\0\0\0\370\1\0\0\0\0\0\0\370\1\0\0=
\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \361\0\0\0\0\0\0 \361\0'4\0\0\0=
 \361\0'4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\=
0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0'4\0\0\0\0\0\0'4\0\0\0$\10\1\0\0\0\0\0$\10=
\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\24\1\0\0\0\0\0\340\24!'4\=
0\0\0\340\24!'4\0\0\0\340\r\0\0\0\0\0\0\0106\0\0\0\0\0\0\0\0 \0\0\0\0\0\2=
\0\0\0\6\0\0\0\350\35\1\0\0\0\0\0\350\35!'4\0\0\0\350\35!'4\0\0\0\300\1\0=
\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\=
0\0\0008\2\0'4\0\0\0008\2\0'4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0=
\0\0\0\0P\345td\4\0\0\0<\361\0\0\0\0\0\0<\361\0'4\0\0\0<\361\0'4\0\0\0,\3=
\0\0\0\0\0\0,\3\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 8=
32
26269 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148119, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D192, st_size=3D92736, st_atime=3D2012/10/09-11:16:43, st_mtime=3D201=
0/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:42}) =3D 0
26269 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fdb21f6f000
26269 mmap(0x3427000000, 2181864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3427000000
26269 mprotect(0x3427011000, 2097152, PROT_NONE) =3D 0
26269 mmap(0x3427211000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x11000) =3D 0x3427211000
26269 mmap(0x3427213000, 6888, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3427213000
26269 close(3)                          =3D 0
26269 open("/lib64/libnsl.so.1", O_RDONLY) =3D 3
26269 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240@\340\35=
10\0\0\0@\0\0\0\0\0\0\0\360\265\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0=
\6\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\340\3510\0\0\0@\0\340\3510\0\0\0\370\1=
\0\0\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \33\1\0\0=
\0\0\0 \33\341\3510\0\0\0 \33\341\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\=
0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\340\3510\0\0\0=
\0\0\340\3510\0\0\0\310@\1\0\0\0\0\0\310@\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\=
0\0\6\0\0\0xM\1\0\0\0\0\0xM\1\3520\0\0\0xM\1\3520\0\0\0\310\5\0\0\0\0\0\0=
008-\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250M\1\0\0\0\0\0\250M\1\3=
520\0\0\0\250M\1\3520\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\340\3510\0\0\0008\2\340\351=
0\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0<\33\=
1\0\0\0\0\0<\33\341\3510\0\0\0<\33\341\3510\0\0\0\\\5\0\0\0\0\0\0\\\5\0\0=
\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26269 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147206, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D232, st_size=3D114352, st_atime=3D2012/10/09-12:01:01, st_mtime=3D20=
10/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:44}) =3D 0
26269 mmap(0x30e9e00000, 2194096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9e00000
26269 mprotect(0x30e9e15000, 2093056, PROT_NONE) =3D 0
26269 mmap(0x30ea014000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x14000) =3D 0x30ea014000
26269 mmap(0x30ea016000, 6832, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x30ea016000
26269 close(3)                          =3D 0
26269 open("/lib64/libdl.so.2", O_RDONLY) =3D 3
26269 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\16`\3500=
\0\0\0@\0\0\0\0\0\0\0@R\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0`\3500\0\0\0@\0`\3500\0\0\0\370\1\0\0\0\0\0\0\37=
0\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\300\32\0\0\0\0\0\0\300\3=
2`\3500\0\0\0\300\32`\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0`\3500\0\0\0\0\0`\3500\0\0\=
0\224\37\0\0\0\0\0\0\224\37\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0`-\=
0\0\0\0\0\0`-\200\3500\0\0\0`-\200\3500\0\0\0 \3\0\0\0\0\0\0\240\3\0\0\0\=
0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\240-\0\0\0\0\0\0\240-\200\3500\0\0\0=
\240-\200\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0=
\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2`\3500\0\0\0008\2`\3500\0\0\0 \0\0\=
0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\334\32\0\0\0\0\0\=
0\334\32`\3500\0\0\0\334\32`\3500\0\0\0\264\0\0\0\0\0\0\0\264\0\0\0\0\0\0=
\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26269 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147322, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D48, st_size=3D23360, st_atime=3D2012/10/09-11:13:54, st_mtime=3D2010=
/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26269 mmap(0x30e8600000, 2109696, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8600000
26269 mprotect(0x30e8602000, 2097152, PROT_NONE) =3D 0
26269 mmap(0x30e8802000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x2000) =3D 0x30e8802000
26269 close(3)                          =3D 0
26269 open("/lib64/libm.so.6", O_RDONLY) =3D 3
26269 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`>\240\3510\=
0\0\0@\0\0\0\0\0\0\0\240X\t\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0)\0(\0\6\0\0\=
0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3510\0\0\0@\0\240\3510\0\0\0\370\1\0\0\0\=
0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\360\303\7\0\0\0\=
0\0\360\303\247\3510\0\0\0\360\303\247\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0=
\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3510\=
0\0\0\0\0\240\3510\0\0\0000\22\10\0\0\0\0\0000\22\10\0\0\0\0\0\0\0 \0\0\0=
\0\0\1\0\0\0\6\0\0\0\270\35\10\0\0\0\0\0\270\35\310\3510\0\0\0\270\35\310=
\3510\0\0\0\320\2\0\0\0\0\0\0 \3\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0=
\0\350\35\10\0\0\0\0\0\350\35\310\3510\0\0\0\350\35\310\3510\0\0\0\300\1\=
0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0=
\0\0\0008\2\240\3510\0\0\0008\2\240\3510\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\f\304\7\0\0\0\0\0\f\304\247\3510\0\0\0=
\f\304\247\3510\0\0\0\374\r\0\0\0\0\0\0\374\r\0\0\0\0\0\0\4\0\0\0\0\0\0\0=
Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0"..., 832) =3D 832
26269 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147337, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D1216, st_size=3D615136, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2=
010/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26269 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fdb21f6e000
26269 mmap(0x30e9a00000, 2629848, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9a00000
26269 mprotect(0x30e9a82000, 2093056, PROT_NONE) =3D 0
26269 mmap(0x30e9c81000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x81000) =3D 0x30e9c81000
26269 close(3)                          =3D 0
26269 open("/lib64/libcrypt.so.1", O_RDONLY) =3D 3
26269 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\t\300%4=
\0\0\0@\0\0\0\0\0\0\0\30\265\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\=
0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\300%4\0\0\0@\0\300%4\0\0\0\370\1\0\0\0\0\=
0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340}\0\0\0\0\0\0\3=
40}\300%4\0\0\0\340}\300%4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\300%4\0\0\0\0\0\300%4\0\0\=
0\4\205\0\0\0\0\0\0\4\205\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\310\=
215\0\0\0\0\0\0\310\215\340%4\0\0\0\310\215\340%4\0\0\0\250\2\0\0\0\0\0\0=
\370\343\2\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\215\0\0\0\0\0\0\3=
70\215\340%4\0\0\0\370\215\340%4\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\=
0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\300%4\0\0\0008\2=
\300%4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0=
\374}\0\0\0\0\0\0\374}\300%4\0\0\0\374}\300%4\0\0\0\34\1\0\0\0\0\0\0\34\1=
\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26269 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148123, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D96, st_size=3D48600, st_atime=3D2012/10/09-12:01:01, st_mtime=3D2010=
/07/28-03:52:39, st_ctime=3D2012/09/11-14:53:52}) =3D 0
26269 mmap(0x3425c00000, 2322880, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425c00000
26269 mprotect(0x3425c09000, 2093056, PROT_NONE) =3D 0
26269 mmap(0x3425e08000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x8000) =3D 0x3425e08000
26269 mmap(0x3425e0a000, 184768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FI=
XED|MAP_ANONYMOUS, -1, 0) =3D 0x3425e0a000
26269 close(3)                          =3D 0
26269 open("/lib64/libutil.so.1", O_RDONLY) =3D 3
26269 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\16\0(4\=
0\0\0@\0\0\0\0\0\0\0(>\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0\0(4\0\0\0@\0\0(4\0\0\0\370\1\0\0\0\0\0\0\370\1\=
0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340\26\0\0\0\0\0\0\340\26\0(=
4\0\0\0\340\26\0(4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0=
\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0(4\0\0\0\0\0\0(4\0\0\0P\32\0\0\0\=
0\0\0P\32\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\35\0\0\0\0\0\0\3=
40\35 (4\0\0\0\340\35 (4\0\0\0 \3\0\0\0\0\0\0000\3\0\0\0\0\0\0\0\0 \0\0\0=
\0\0\2\0\0\0\6\0\0\0\20\36\0\0\0\0\0\0\20\36 (4\0\0\0\20\36 (4\0\0\0\300\=
1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0=
\0\0\0\0008\2\0(4\0\0\0008\2\0(4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\=
0\0\0\0\0\0P\345td\4\0\0\0\374\26\0\0\0\0\0\0\374\26\0(4\0\0\0\374\26\0(4=
\0\0\0D\0\0\0\0\0\0\0D\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8=
32) =3D 832
26269 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147063, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D40, st_size=3D18152, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2010=
/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:49}) =3D 0
26269 mmap(0x3428000000, 2105616, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3428000000
26269 mprotect(0x3428002000, 2093056, PROT_NONE) =3D 0
26269 mmap(0x3428201000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x1000) =3D 0x3428201000
26269 close(3)                          =3D 0
26269 open("/lib64/libpthread.so.0", O_RDONLY) =3D 3
26269 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240W\240\35=
00\0\0\0@\0\0\0\0\0\0\0\340/\2\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0'\0&\0\6\0=
\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3500\0\0\0@\0\240\3500\0\0\0\370\1\0\0=
\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\240\t\1\0\0\0=
\0\0\240\t\241\3500\0\0\0\240\t\241\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\=
0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3500\0\0=
\0\0\0\240\3500\0\0\0pZ\1\0\0\0\0\0pZ\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\=
6\0\0\0\270[\1\0\0\0\0\0\270[\301\3500\0\0\0\270[\301\3500\0\0\0\230\6\0\=
0\0\0\0\0\270G\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250]\1\0\0\0\0\=
0\250]\301\3500\0\0\0\250]\301\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0=
\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\240\3500\0\0\=
0008\2\240\3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345t=
d\4\0\0\0\274\t\1\0\0\0\0\0\274\t\241\3500\0\0\0\274\t\241\3500\0\0\0\344=
\t\0\0\0\0\0\0\344\t\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =
=3D 832
26269 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147328, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D296, st_size=3D145824, st_atime=3D2012/10/09-11:16:43, st_mtime=3D20=
10/07/28-03:52:41, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26269 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fdb21f6d000
26269 mmap(0x30e8a00000, 2204528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8a00000
26269 mprotect(0x30e8a16000, 2093056, PROT_NONE) =3D 0
26269 mmap(0x30e8c15000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x15000) =3D 0x30e8c15000
26269 mmap(0x30e8c17000, 13168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8c17000
26269 close(3)                          =3D 0
26269 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26269 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26269 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26269 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26269 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26269 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26269 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26269 close(3)                          =3D 0
26269 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fdb21f6c000
26269 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fdb21f6b000
26269 arch_prctl(ARCH_SET_FS, 0x7fdb21f6b6e0) =3D 0
26269 mprotect(0x3427211000, 4096, PROT_READ) =3D 0
26269 mprotect(0x30ea014000, 4096, PROT_READ) =3D 0
26269 mprotect(0x30e8802000, 4096, PROT_READ) =3D 0
26269 mprotect(0x30e9c81000, 4096, PROT_READ) =3D 0
26269 mprotect(0x3425e08000, 4096, PROT_READ) =3D 0
26269 mprotect(0x3428201000, 4096, PROT_READ) =3D 0
26269 mprotect(0x30e8c15000, 4096, PROT_READ) =3D 0
26269 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26269 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26269 munmap(0x7fdb21f70000, 103979)    =3D 0
26269 set_tid_address(0x7fdb21f6b770)   =3D 26269
26269 set_robust_list(0x7fdb21f6b780, 0x18) =3D 0
26269 futex(0x7fffced4967c, FUTEX_WAKE_PRIVATE, 1) =3D 0
26269 rt_sigaction(SIGRTMIN, {0x30e8a05380, [], SA_RESTORER|SA_SIGINFO, 0=
x30e8a0eb10}, NULL, 8) =3D 0
26269 rt_sigaction(SIGRT_1, {0x30e8a052b0, [], SA_RESTORER|SA_RESTART|SA_=
SIGINFO, 0x30e8a0eb10}, NULL, 8) =3D 0
26269 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) =3D 0
26269 getrlimit(RLIMIT_STACK, {rlim_cur=3D8192*1024, rlim_max=3DRLIM_INFI=
NITY}) =3D 0
26269 rt_sigaction(SIGFPE, {0x1, [FPE], SA_RESTORER|SA_RESTART, 0x30e8230=
2d0}, {SIG_DFL, [], 0}, 8) =3D 0
26269 brk(0)                            =3D 0x1a99000
26269 brk(0x1abb000)                    =3D 0x1abb000
26269 getuid()                          =3D 0
26269 geteuid()                         =3D 0
26269 getgid()                          =3D 0
26269 getegid()                         =3D 0
26269 mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,=
 -1, 0) =3D 0x7fdb21f4a000
26269 open("/dev/urandom", O_RDONLY)    =3D 3
26269 read(3, "\323\277\205\337", 4)    =3D 4
26269 close(3)                          =3D 0
26269 stat("/usr/lib64/perl5/site_perl/5.8.7/x86_64-linux-thread-multi", =
0x7fffced49330) =3D -1 ENOENT (No such file or directory)
26269 stat("/usr/lib/perl5/site_perl/5.8.7", 0x7fffced49330) =3D -1 ENOEN=
T (No such file or directory)
26269 stat("/usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi", =
0x7fffced49330) =3D -1 ENOENT (No such file or directory)
26269 stat("/usr/lib/perl5/site_perl/5.8.6", 0x7fffced49330) =3D -1 ENOEN=
T (No such file or directory)
26269 stat("/usr/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi", =
0x7fffced49330) =3D -1 ENOENT (No such file or directory)
26269 stat("/usr/lib/perl5/site_perl/5.8.5", 0x7fffced49330) =3D -1 ENOEN=
T (No such file or directory)
26269 stat("/usr/lib64/perl5/vendor_perl/5.8.7/x86_64-linux-thread-multi"=
, 0x7fffced49330) =3D -1 ENOENT (No such file or directory)
26269 stat("/usr/lib/perl5/vendor_perl/5.8.7", 0x7fffced49330) =3D -1 ENO=
ENT (No such file or directory)
26269 stat("/usr/lib64/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi"=
, 0x7fffced49330) =3D -1 ENOENT (No such file or directory)
26269 stat("/usr/lib/perl5/vendor_perl/5.8.6", 0x7fffced49330) =3D -1 ENO=
ENT (No such file or directory)
26269 stat("/usr/lib64/perl5/vendor_perl/5.8.5/x86_64-linux-thread-multi"=
, 0x7fffced49330) =3D -1 ENOENT (No such file or directory)
26269 stat("/usr/lib/perl5/vendor_perl/5.8.5", 0x7fffced49330) =3D -1 ENO=
ENT (No such file or directory)
26269 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffced490f0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26269 lseek(0, 0, SEEK_CUR)             =3D 0
26269 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffced490f0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26269 lseek(1, 0, SEEK_CUR)             =3D -1 ESPIPE (Illegal seek)
26269 ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffced49100) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26269 lseek(2, 0, SEEK_CUR)             =3D 593655951
26269 open("/dev/null", O_RDONLY)       =3D 3
26269 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffced49200) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26269 lseek(3, 0, SEEK_CUR)             =3D 0
26269 fcntl(3, F_SETFD, FD_CLOEXEC)     =3D 0
26269 fstat(3, {st_dev=3Dmakedev(0, 16), st_ino=3D584, st_mode=3DS_IFCHR|=
0666, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
0, st_rdev=3Dmakedev(1, 3), st_atime=3D2012/10/08-11:13:26, st_mtime=3D20=
12/10/08-11:13:26, st_ctime=3D2012/10/08-11:13:27}) =3D 0
26269 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) =3D 0
26269 readlink("/proc/self/exe", "/usr/bin/perl"..., 4095) =3D 13
26269 brk(0x1adc000)                    =3D 0x1adc000
26269 close(3)                          =3D 0
26269 dup(200)                          =3D 3
26269 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffced490d0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26269 lseek(3, 0, SEEK_CUR)             =3D 0
26269 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26269 dup2(3, 0)                        =3D 0
26269 close(3)                          =3D 0
26269 fcntl(0, F_SETFD, 0)              =3D 0
26269 fstat(0, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26269 stat("/var/run/xen-hotplug/block", {st_dev=3Dmakedev(8, 2), st_ino=3D=
2801738, st_mode=3DS_IFREG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st=
_blksize=3D4096, st_blocks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:=
24, st_mtime=3D2012/10/09-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D =
0
26269 exit_group(0)                     =3D ?
27813 <... read resumed> "", 128)       =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], WNOHANG, NUL=
L) =3D 26269
27813 wait4(-1, 0x7fffb0100a64, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0)                   =3D 0
27813 close(3)                          =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 write(2, "+ rightfile=3D\n", 13)    =3D 13
27813 write(2, "+ '[' x =3D xy ']'\n", 17) =3D 17
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ true\n", 7)           =3D 7
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ eval 'exec 200>>/var/run/xen-hotplug/block'\n", 46) =3D=
 46
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 write(2, "++ exec\n", 8)          =3D 8
27813 open("/var/run/xen-hotplug/block", O_WRONLY|O_CREAT|O_APPEND, 0666)=
 =3D 3
27813 fcntl(200, F_GETFD)               =3D 0
27813 fcntl(200, F_DUPFD, 10)           =3D 10
27813 fcntl(200, F_GETFD)               =3D 0
27813 dup2(3, 200)                      =3D 200
27813 close(3)                          =3D 0
27813 dup2(10, 200)                     =3D 200
27813 fcntl(10, F_GETFD)                =3D 0
27813 close(10)                         =3D 0
27813 write(2, "+ flock -x 200\n", 15)  =3D 15
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [INT CHLD], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [INT CHLD], NULL, 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26270
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26270 close(255 
27813 rt_sigprocmask(SIG_BLOCK, [CHLD],  
26270 <... close resumed> )             =3D 0
27813 <... rt_sigprocmask resumed> [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [],  
26270 rt_sigprocmask(SIG_SETMASK, [],  
27813 <... rt_sigprocmask resumed> NULL, 8) =3D 0
26270 <... rt_sigprocmask resumed> NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
26270 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0},  
26270 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
27813 <... rt_sigaction resumed> {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}=
, 8) =3D 0
26270 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 wait4(-1,  
26270 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
26270 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26270 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26270 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26270 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26270 execve("/usr/bin/flock", ["flock", "-x", "200"], ["SUBSYSTEM=3Dxen-=
backend", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D=
/usr/bin:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:=
/usr/sbin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dx=
en-backend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3D=
backend/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "S=
HLVL=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/flock"]) =3D 0=

26270 brk(0)                            =3D 0x1531000
26270 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f585c9c2000
26270 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f585c9c1000
26270 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26270 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26270 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26270 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7f585c9a7000=

26270 close(3)                          =3D 0
26270 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26270 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26270 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26270 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26270 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26270 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26270 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26270 close(3)                          =3D 0
26270 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f585c9a6000
26270 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f585c9a5000
26270 arch_prctl(ARCH_SET_FS, 0x7f585c9a56e0) =3D 0
26270 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26270 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26270 munmap(0x7f585c9a7000, 103979)    =3D 0
26270 flock(200, LOCK_EX)               =3D 0
26270 exit_group(0)                     =3D ?
27813 <... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], 0,=
 NULL) =3D 26270
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, 0x7fffb0100a24, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0xffffffffffffffff)  =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 pipe([3, 4])                      =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26271
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {0=
x436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26271 close(255 
27813 close(4 
26271 <... close resumed> )             =3D 0
27813 <... close resumed> )             =3D 0
27813 read(3,  
26271 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26271 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26271 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26271 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26271 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26271 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26271 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26271 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {S=
IG_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26271 rt_sigaction(SIGINT, {0x4481f0, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26271 dup2(4, 1)                        =3D 1
26271 close(4)                          =3D 0
26271 close(3)                          =3D 0
26271 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26271 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26271 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26271 write(2, "++ perl -e '\n            open STDIN, \"<&200\" or die $!=
;\n            my $fd_inum =3D (stat STDIN)[1]; die $! unless defined $fd=
_inum;\n            my $file_inum =3D (stat $ARGV[0])[1];\n            pr=
int \"y\\n\" if $fd_inum eq $file_inum;\n", 230) =3D 230
26271 write(2, "                             ' /var/run/xen-hotplug/block=
\n", 58) =3D 58
26271 stat(".", {st_dev=3Dmakedev(8, 2), st_ino=3D2, st_mode=3DS_IFDIR|07=
55, st_nlink=3D24, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
8, st_size=3D4096, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2012/10/08-=
11:13:38, st_ctime=3D2012/10/08-11:13:38}) =3D 0
26271 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26271 access("/usr/bin/perl", X_OK)     =3D 0
26271 access("/usr/bin/perl", R_OK)     =3D 0
26271 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26271 access("/usr/bin/perl", X_OK)     =3D 0
26271 access("/usr/bin/perl", R_OK)     =3D 0
26271 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
481f0, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26271 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26271 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26271 execve("/usr/bin/perl", ["perl", "-e", "\n            open STDIN, \=
"<&200\" or die $!;\n            my $fd_inum =3D (stat STDIN)[1]; die $! =
unless defined $fd_inum;\n            my $file_inum =3D (stat $ARGV[0])[1=
];\n            print \"y\\n\" if $fd_inum eq $file_inum;\n              =
               ", "/var/run/xen-hotplug/block"], ["SUBSYSTEM=3Dxen-backen=
d", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D/usr/b=
in:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:/usr/s=
bin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dxen-bac=
kend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3Dback=
end/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "SHLVL=
=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/perl"]) =3D 0
26271 brk(0)                            =3D 0x217e000
26271 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f9f8a879000
26271 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f9f8a878000
26271 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26271 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64/libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26271 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64", 0x7fff8dbaff30) =3D -1 ENOENT (No such file or directory)
26271 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/lib=
perl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26271 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls", 0=
x7fff8dbaff30) =3D -1 ENOENT (No such file or directory)
26271 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64/=
libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26271 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64"=
, 0x7fff8dbaff30) =3D -1 ENOENT (No such file or directory)
26271 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl=
=2Eso", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26271 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE", 0x7ff=
f8dbaff30) =3D -1 ENOENT (No such file or directory)
26271 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26271 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26271 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7f9f8a85e000=

26271 close(3)                          =3D 0
26271 open("/usr/lib64/libperl.so", O_RDONLY) =3D 3
26271 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\34\203%=
4\0\0\0@\0\0\0\0\0\0\0\360;\23\0\0\0\0\0\0\0\0\0@\0008\0\5\0@\0\35\0\34\0=
\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\200%4\0\0\0\0\0\200%4\0\0\0T\260\22\=
0\0\0\0\0T\260\22\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0X\260\22\0\0\0\=
0\0X\260\262%4\0\0\0X\260\262%4\0\0\0\250\201\0\0\0\0\0\0\350\242\0\0\0\0=
\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\265\22\0\0\0\0\0\370\265\262%4\0\=
0\0\370\265\262%4\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\=
0\0P\345td\4\0\0\0\250u\21\0\0\0\0\0\250u\221%4\0\0\0\250u\221%4\0\0\0D@\=
0\0\0\0\0\0D@\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\7\4\0\0\360\0\0\0\0\1\0\0\16\0\0\0\0\0\0@\0\200\203\200\225\1\22\=
264\3\31\200l\0\32\0 \5\201\0\240\3\2B\0\200\21R \0\22\0\0\16P\20#\10\216=
\334\30\211\"\0\10 \200\3B\220@\0\1\206\20\30\2\3\21\203$!\312A0\224Y\200=
\27\0\242\26\10\24R@\10\200\220\20A\10\0\220\1\200\206\2\10\304\30i\0\220=
\1\1\202\200\22\20\0\n\1H\0\n\2001J \6\31@L\207\20\10\0000\10(\200\2\0\4\=
251t\"\262\310!\212\240\320\"\0\t"..., 832) =3D 832
26271 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2839671, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D2480, st_size=3D1262384, st_atime=3D2012/10/09-12:04:35, st_mtime=3D=
2012/09/11-12:45:05, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26271 mmap(0x3425800000, 3363648, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425800000
26271 mprotect(0x342592c000, 2093056, PROT_NONE) =3D 0
26271 mmap(0x3425b2b000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x12b000) =3D 0x3425b2b000
26271 mmap(0x3425b34000, 4928, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3425b34000
26271 close(3)                          =3D 0
26271 open("/lib64/libresolv.so.2", O_RDONLY) =3D 3
26271 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\2402\0'4\0\=
0\0@\0\0\0\0\0\0\0@a\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\5\0=
\0\0@\0\0\0\0\0\0\0@\0\0'4\0\0\0@\0\0'4\0\0\0\370\1\0\0\0\0\0\0\370\1\0\0=
\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \361\0\0\0\0\0\0 \361\0'4\0\0\0=
 \361\0'4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\=
0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0'4\0\0\0\0\0\0'4\0\0\0$\10\1\0\0\0\0\0$\10=
\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\24\1\0\0\0\0\0\340\24!'4\=
0\0\0\340\24!'4\0\0\0\340\r\0\0\0\0\0\0\0106\0\0\0\0\0\0\0\0 \0\0\0\0\0\2=
\0\0\0\6\0\0\0\350\35\1\0\0\0\0\0\350\35!'4\0\0\0\350\35!'4\0\0\0\300\1\0=
\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\=
0\0\0008\2\0'4\0\0\0008\2\0'4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0=
\0\0\0\0P\345td\4\0\0\0<\361\0\0\0\0\0\0<\361\0'4\0\0\0<\361\0'4\0\0\0,\3=
\0\0\0\0\0\0,\3\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 8=
32
26271 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148119, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D192, st_size=3D92736, st_atime=3D2012/10/09-11:16:43, st_mtime=3D201=
0/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:42}) =3D 0
26271 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f9f8a85d000
26271 mmap(0x3427000000, 2181864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3427000000
26271 mprotect(0x3427011000, 2097152, PROT_NONE) =3D 0
26271 mmap(0x3427211000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x11000) =3D 0x3427211000
26271 mmap(0x3427213000, 6888, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3427213000
26271 close(3)                          =3D 0
26271 open("/lib64/libnsl.so.1", O_RDONLY) =3D 3
26271 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240@\340\35=
10\0\0\0@\0\0\0\0\0\0\0\360\265\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0=
\6\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\340\3510\0\0\0@\0\340\3510\0\0\0\370\1=
\0\0\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \33\1\0\0=
\0\0\0 \33\341\3510\0\0\0 \33\341\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\=
0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\340\3510\0\0\0=
\0\0\340\3510\0\0\0\310@\1\0\0\0\0\0\310@\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\=
0\0\6\0\0\0xM\1\0\0\0\0\0xM\1\3520\0\0\0xM\1\3520\0\0\0\310\5\0\0\0\0\0\0=
008-\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250M\1\0\0\0\0\0\250M\1\3=
520\0\0\0\250M\1\3520\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\340\3510\0\0\0008\2\340\351=
0\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0<\33\=
1\0\0\0\0\0<\33\341\3510\0\0\0<\33\341\3510\0\0\0\\\5\0\0\0\0\0\0\\\5\0\0=
\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26271 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147206, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D232, st_size=3D114352, st_atime=3D2012/10/09-12:01:01, st_mtime=3D20=
10/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:44}) =3D 0
26271 mmap(0x30e9e00000, 2194096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9e00000
26271 mprotect(0x30e9e15000, 2093056, PROT_NONE) =3D 0
26271 mmap(0x30ea014000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x14000) =3D 0x30ea014000
26271 mmap(0x30ea016000, 6832, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x30ea016000
26271 close(3)                          =3D 0
26271 open("/lib64/libdl.so.2", O_RDONLY) =3D 3
26271 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\16`\3500=
\0\0\0@\0\0\0\0\0\0\0@R\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0`\3500\0\0\0@\0`\3500\0\0\0\370\1\0\0\0\0\0\0\37=
0\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\300\32\0\0\0\0\0\0\300\3=
2`\3500\0\0\0\300\32`\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0`\3500\0\0\0\0\0`\3500\0\0\=
0\224\37\0\0\0\0\0\0\224\37\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0`-\=
0\0\0\0\0\0`-\200\3500\0\0\0`-\200\3500\0\0\0 \3\0\0\0\0\0\0\240\3\0\0\0\=
0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\240-\0\0\0\0\0\0\240-\200\3500\0\0\0=
\240-\200\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0=
\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2`\3500\0\0\0008\2`\3500\0\0\0 \0\0\=
0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\334\32\0\0\0\0\0\=
0\334\32`\3500\0\0\0\334\32`\3500\0\0\0\264\0\0\0\0\0\0\0\264\0\0\0\0\0\0=
\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26271 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147322, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D48, st_size=3D23360, st_atime=3D2012/10/09-11:13:54, st_mtime=3D2010=
/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26271 mmap(0x30e8600000, 2109696, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8600000
26271 mprotect(0x30e8602000, 2097152, PROT_NONE) =3D 0
26271 mmap(0x30e8802000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x2000) =3D 0x30e8802000
26271 close(3)                          =3D 0
26271 open("/lib64/libm.so.6", O_RDONLY) =3D 3
26271 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`>\240\3510\=
0\0\0@\0\0\0\0\0\0\0\240X\t\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0)\0(\0\6\0\0\=
0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3510\0\0\0@\0\240\3510\0\0\0\370\1\0\0\0\=
0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\360\303\7\0\0\0\=
0\0\360\303\247\3510\0\0\0\360\303\247\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0=
\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3510\=
0\0\0\0\0\240\3510\0\0\0000\22\10\0\0\0\0\0000\22\10\0\0\0\0\0\0\0 \0\0\0=
\0\0\1\0\0\0\6\0\0\0\270\35\10\0\0\0\0\0\270\35\310\3510\0\0\0\270\35\310=
\3510\0\0\0\320\2\0\0\0\0\0\0 \3\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0=
\0\350\35\10\0\0\0\0\0\350\35\310\3510\0\0\0\350\35\310\3510\0\0\0\300\1\=
0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0=
\0\0\0008\2\240\3510\0\0\0008\2\240\3510\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\f\304\7\0\0\0\0\0\f\304\247\3510\0\0\0=
\f\304\247\3510\0\0\0\374\r\0\0\0\0\0\0\374\r\0\0\0\0\0\0\4\0\0\0\0\0\0\0=
Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0"..., 832) =3D 832
26271 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147337, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D1216, st_size=3D615136, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2=
010/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26271 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f9f8a85c000
26271 mmap(0x30e9a00000, 2629848, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9a00000
26271 mprotect(0x30e9a82000, 2093056, PROT_NONE) =3D 0
26271 mmap(0x30e9c81000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x81000) =3D 0x30e9c81000
26271 close(3)                          =3D 0
26271 open("/lib64/libcrypt.so.1", O_RDONLY) =3D 3
26271 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\t\300%4=
\0\0\0@\0\0\0\0\0\0\0\30\265\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\=
0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\300%4\0\0\0@\0\300%4\0\0\0\370\1\0\0\0\0\=
0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340}\0\0\0\0\0\0\3=
40}\300%4\0\0\0\340}\300%4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\300%4\0\0\0\0\0\300%4\0\0\=
0\4\205\0\0\0\0\0\0\4\205\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\310\=
215\0\0\0\0\0\0\310\215\340%4\0\0\0\310\215\340%4\0\0\0\250\2\0\0\0\0\0\0=
\370\343\2\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\215\0\0\0\0\0\0\3=
70\215\340%4\0\0\0\370\215\340%4\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\=
0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\300%4\0\0\0008\2=
\300%4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0=
\374}\0\0\0\0\0\0\374}\300%4\0\0\0\374}\300%4\0\0\0\34\1\0\0\0\0\0\0\34\1=
\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26271 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148123, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D96, st_size=3D48600, st_atime=3D2012/10/09-12:01:01, st_mtime=3D2010=
/07/28-03:52:39, st_ctime=3D2012/09/11-14:53:52}) =3D 0
26271 mmap(0x3425c00000, 2322880, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425c00000
26271 mprotect(0x3425c09000, 2093056, PROT_NONE) =3D 0
26271 mmap(0x3425e08000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x8000) =3D 0x3425e08000
26271 mmap(0x3425e0a000, 184768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FI=
XED|MAP_ANONYMOUS, -1, 0) =3D 0x3425e0a000
26271 close(3)                          =3D 0
26271 open("/lib64/libutil.so.1", O_RDONLY) =3D 3
26271 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\16\0(4\=
0\0\0@\0\0\0\0\0\0\0(>\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0\0(4\0\0\0@\0\0(4\0\0\0\370\1\0\0\0\0\0\0\370\1\=
0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340\26\0\0\0\0\0\0\340\26\0(=
4\0\0\0\340\26\0(4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0=
\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0(4\0\0\0\0\0\0(4\0\0\0P\32\0\0\0\=
0\0\0P\32\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\35\0\0\0\0\0\0\3=
40\35 (4\0\0\0\340\35 (4\0\0\0 \3\0\0\0\0\0\0000\3\0\0\0\0\0\0\0\0 \0\0\0=
\0\0\2\0\0\0\6\0\0\0\20\36\0\0\0\0\0\0\20\36 (4\0\0\0\20\36 (4\0\0\0\300\=
1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0=
\0\0\0\0008\2\0(4\0\0\0008\2\0(4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\=
0\0\0\0\0\0P\345td\4\0\0\0\374\26\0\0\0\0\0\0\374\26\0(4\0\0\0\374\26\0(4=
\0\0\0D\0\0\0\0\0\0\0D\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8=
32) =3D 832
26271 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147063, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D40, st_size=3D18152, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2010=
/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:49}) =3D 0
26271 mmap(0x3428000000, 2105616, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3428000000
26271 mprotect(0x3428002000, 2093056, PROT_NONE) =3D 0
26271 mmap(0x3428201000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x1000) =3D 0x3428201000
26271 close(3)                          =3D 0
26271 open("/lib64/libpthread.so.0", O_RDONLY) =3D 3
26271 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240W\240\35=
00\0\0\0@\0\0\0\0\0\0\0\340/\2\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0'\0&\0\6\0=
\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3500\0\0\0@\0\240\3500\0\0\0\370\1\0\0=
\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\240\t\1\0\0\0=
\0\0\240\t\241\3500\0\0\0\240\t\241\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\=
0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3500\0\0=
\0\0\0\240\3500\0\0\0pZ\1\0\0\0\0\0pZ\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\=
6\0\0\0\270[\1\0\0\0\0\0\270[\301\3500\0\0\0\270[\301\3500\0\0\0\230\6\0\=
0\0\0\0\0\270G\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250]\1\0\0\0\0\=
0\250]\301\3500\0\0\0\250]\301\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0=
\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\240\3500\0\0\=
0008\2\240\3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345t=
d\4\0\0\0\274\t\1\0\0\0\0\0\274\t\241\3500\0\0\0\274\t\241\3500\0\0\0\344=
\t\0\0\0\0\0\0\344\t\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =
=3D 832
26271 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147328, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D296, st_size=3D145824, st_atime=3D2012/10/09-11:16:43, st_mtime=3D20=
10/07/28-03:52:41, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26271 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f9f8a85b000
26271 mmap(0x30e8a00000, 2204528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8a00000
26271 mprotect(0x30e8a16000, 2093056, PROT_NONE) =3D 0
26271 mmap(0x30e8c15000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x15000) =3D 0x30e8c15000
26271 mmap(0x30e8c17000, 13168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8c17000
26271 close(3)                          =3D 0
26271 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26271 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26271 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26271 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26271 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26271 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26271 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26271 close(3)                          =3D 0
26271 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f9f8a85a000
26271 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f9f8a859000
26271 arch_prctl(ARCH_SET_FS, 0x7f9f8a8596e0) =3D 0
26271 mprotect(0x3427211000, 4096, PROT_READ) =3D 0
26271 mprotect(0x30ea014000, 4096, PROT_READ) =3D 0
26271 mprotect(0x30e8802000, 4096, PROT_READ) =3D 0
26271 mprotect(0x30e9c81000, 4096, PROT_READ) =3D 0
26271 mprotect(0x3425e08000, 4096, PROT_READ) =3D 0
26271 mprotect(0x3428201000, 4096, PROT_READ) =3D 0
26271 mprotect(0x30e8c15000, 4096, PROT_READ) =3D 0
26271 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26271 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26271 munmap(0x7f9f8a85e000, 103979)    =3D 0
26271 set_tid_address(0x7f9f8a859770)   =3D 26271
26271 set_robust_list(0x7f9f8a859780, 0x18) =3D 0
26271 futex(0x7fff8dbb0a5c, FUTEX_WAKE_PRIVATE, 1) =3D 0
26271 rt_sigaction(SIGRTMIN, {0x30e8a05380, [], SA_RESTORER|SA_SIGINFO, 0=
x30e8a0eb10}, NULL, 8) =3D 0
26271 rt_sigaction(SIGRT_1, {0x30e8a052b0, [], SA_RESTORER|SA_RESTART|SA_=
SIGINFO, 0x30e8a0eb10}, NULL, 8) =3D 0
26271 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) =3D 0
26271 getrlimit(RLIMIT_STACK, {rlim_cur=3D8192*1024, rlim_max=3DRLIM_INFI=
NITY}) =3D 0
26271 rt_sigaction(SIGFPE, {0x1, [FPE], SA_RESTORER|SA_RESTART, 0x30e8230=
2d0}, {SIG_DFL, [], 0}, 8) =3D 0
26271 brk(0)                            =3D 0x217e000
26271 brk(0x21a0000)                    =3D 0x21a0000
26271 getuid()                          =3D 0
26271 geteuid()                         =3D 0
26271 getgid()                          =3D 0
26271 getegid()                         =3D 0
26271 mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,=
 -1, 0) =3D 0x7f9f8a838000
26271 open("/dev/urandom", O_RDONLY)    =3D 3
26271 read(3, "\25\300\34\374", 4)      =3D 4
26271 close(3)                          =3D 0
26271 stat("/usr/lib64/perl5/site_perl/5.8.7/x86_64-linux-thread-multi", =
0x7fff8dbb0710) =3D -1 ENOENT (No such file or directory)
26271 stat("/usr/lib/perl5/site_perl/5.8.7", 0x7fff8dbb0710) =3D -1 ENOEN=
T (No such file or directory)
26271 stat("/usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi", =
0x7fff8dbb0710) =3D -1 ENOENT (No such file or directory)
26271 stat("/usr/lib/perl5/site_perl/5.8.6", 0x7fff8dbb0710) =3D -1 ENOEN=
T (No such file or directory)
26271 stat("/usr/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi", =
0x7fff8dbb0710) =3D -1 ENOENT (No such file or directory)
26271 stat("/usr/lib/perl5/site_perl/5.8.5", 0x7fff8dbb0710) =3D -1 ENOEN=
T (No such file or directory)
26271 stat("/usr/lib64/perl5/vendor_perl/5.8.7/x86_64-linux-thread-multi"=
, 0x7fff8dbb0710) =3D -1 ENOENT (No such file or directory)
26271 stat("/usr/lib/perl5/vendor_perl/5.8.7", 0x7fff8dbb0710) =3D -1 ENO=
ENT (No such file or directory)
26271 stat("/usr/lib64/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi"=
, 0x7fff8dbb0710) =3D -1 ENOENT (No such file or directory)
26271 stat("/usr/lib/perl5/vendor_perl/5.8.6", 0x7fff8dbb0710) =3D -1 ENO=
ENT (No such file or directory)
26271 stat("/usr/lib64/perl5/vendor_perl/5.8.5/x86_64-linux-thread-multi"=
, 0x7fff8dbb0710) =3D -1 ENOENT (No such file or directory)
26271 stat("/usr/lib/perl5/vendor_perl/5.8.5", 0x7fff8dbb0710) =3D -1 ENO=
ENT (No such file or directory)
26271 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff8dbb04d0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26271 lseek(0, 0, SEEK_CUR)             =3D 0
26271 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff8dbb04d0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26271 lseek(1, 0, SEEK_CUR)             =3D -1 ESPIPE (Illegal seek)
26271 ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff8dbb04e0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26271 lseek(2, 0, SEEK_CUR)             =3D 593656345
26271 open("/dev/null", O_RDONLY)       =3D 3
26271 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff8dbb05e0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26271 lseek(3, 0, SEEK_CUR)             =3D 0
26271 fcntl(3, F_SETFD, FD_CLOEXEC)     =3D 0
26271 fstat(3, {st_dev=3Dmakedev(0, 16), st_ino=3D584, st_mode=3DS_IFCHR|=
0666, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
0, st_rdev=3Dmakedev(1, 3), st_atime=3D2012/10/08-11:13:26, st_mtime=3D20=
12/10/08-11:13:26, st_ctime=3D2012/10/08-11:13:27}) =3D 0
26271 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) =3D 0
26271 readlink("/proc/self/exe", "/usr/bin/perl"..., 4095) =3D 13
26271 brk(0x21c1000)                    =3D 0x21c1000
26271 close(3)                          =3D 0
26271 dup(200)                          =3D 3
26271 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff8dbb04b0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26271 lseek(3, 0, SEEK_CUR)             =3D 0
26271 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26271 dup2(3, 0)                        =3D 0
26271 close(3)                          =3D 0
26271 fcntl(0, F_SETFD, 0)              =3D 0
26271 fstat(0, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26271 stat("/var/run/xen-hotplug/block", {st_dev=3Dmakedev(8, 2), st_ino=3D=
2801738, st_mode=3DS_IFREG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st=
_blksize=3D4096, st_blocks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:=
24, st_mtime=3D2012/10/09-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D =
0
26271 exit_group(0)                     =3D ?
27813 <... read resumed> "", 128)       =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], WNOHANG, NUL=
L) =3D 26271
27813 wait4(-1, 0x7fffb0100a64, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0)                   =3D 0
27813 close(3)                          =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 write(2, "+ rightfile=3D\n", 13)    =3D 13
27813 write(2, "+ '[' x =3D xy ']'\n", 17) =3D 17
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ true\n", 7)           =3D 7
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ eval 'exec 200>>/var/run/xen-hotplug/block'\n", 46) =3D=
 46
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 write(2, "++ exec\n", 8)          =3D 8
27813 open("/var/run/xen-hotplug/block", O_WRONLY|O_CREAT|O_APPEND, 0666)=
 =3D 3
27813 fcntl(200, F_GETFD)               =3D 0
27813 fcntl(200, F_DUPFD, 10)           =3D 10
27813 fcntl(200, F_GETFD)               =3D 0
27813 dup2(3, 200)                      =3D 200
27813 close(3)                          =3D 0
27813 dup2(10, 200)                     =3D 200
27813 fcntl(10, F_GETFD)                =3D 0
27813 close(10)                         =3D 0
27813 write(2, "+ flock -x 200\n", 15)  =3D 15
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [INT CHLD], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [INT CHLD], NULL, 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26272
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26272 close(255 
27813 rt_sigprocmask(SIG_BLOCK, [CHLD],  
26272 <... close resumed> )             =3D 0
27813 <... rt_sigprocmask resumed> [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [],  
26272 rt_sigprocmask(SIG_SETMASK, [],  
27813 <... rt_sigprocmask resumed> NULL, 8) =3D 0
26272 <... rt_sigprocmask resumed> NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
26272 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0},  
26272 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
27813 <... rt_sigaction resumed> {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}=
, 8) =3D 0
26272 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 wait4(-1,  
26272 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
26272 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26272 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26272 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26272 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26272 execve("/usr/bin/flock", ["flock", "-x", "200"], ["SUBSYSTEM=3Dxen-=
backend", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D=
/usr/bin:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:=
/usr/sbin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dx=
en-backend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3D=
backend/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "S=
HLVL=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/flock"]) =3D 0=

26272 brk(0)                            =3D 0x1746000
26272 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fad826e0000
26272 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fad826df000
26272 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26272 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26272 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26272 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7fad826c5000=

26272 close(3)                          =3D 0
26272 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26272 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26272 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26272 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26272 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26272 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26272 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26272 close(3)                          =3D 0
26272 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fad826c4000
26272 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fad826c3000
26272 arch_prctl(ARCH_SET_FS, 0x7fad826c36e0) =3D 0
26272 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26272 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26272 munmap(0x7fad826c5000, 103979)    =3D 0
26272 flock(200, LOCK_EX)               =3D 0
26272 exit_group(0)                     =3D ?
27813 <... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], 0,=
 NULL) =3D 26272
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, 0x7fffb0100a24, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0xffffffffffffffff)  =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 pipe([3, 4])                      =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26273
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {0=
x436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26273 close(255 
27813 close(4 
26273 <... close resumed> )             =3D 0
27813 <... close resumed> )             =3D 0
27813 read(3,  
26273 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26273 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26273 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26273 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26273 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26273 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26273 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26273 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {S=
IG_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26273 rt_sigaction(SIGINT, {0x4481f0, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26273 dup2(4, 1)                        =3D 1
26273 close(4)                          =3D 0
26273 close(3)                          =3D 0
26273 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26273 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26273 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26273 write(2, "++ perl -e '\n            open STDIN, \"<&200\" or die $!=
;\n            my $fd_inum =3D (stat STDIN)[1]; die $! unless defined $fd=
_inum;\n            my $file_inum =3D (stat $ARGV[0])[1];\n            pr=
int \"y\\n\" if $fd_inum eq $file_inum;\n", 230) =3D 230
26273 write(2, "                             ' /var/run/xen-hotplug/block=
\n", 58) =3D 58
26273 stat(".", {st_dev=3Dmakedev(8, 2), st_ino=3D2, st_mode=3DS_IFDIR|07=
55, st_nlink=3D24, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
8, st_size=3D4096, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2012/10/08-=
11:13:38, st_ctime=3D2012/10/08-11:13:38}) =3D 0
26273 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26273 access("/usr/bin/perl", X_OK)     =3D 0
26273 access("/usr/bin/perl", R_OK)     =3D 0
26273 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26273 access("/usr/bin/perl", X_OK)     =3D 0
26273 access("/usr/bin/perl", R_OK)     =3D 0
26273 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
481f0, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26273 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26273 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26273 execve("/usr/bin/perl", ["perl", "-e", "\n            open STDIN, \=
"<&200\" or die $!;\n            my $fd_inum =3D (stat STDIN)[1]; die $! =
unless defined $fd_inum;\n            my $file_inum =3D (stat $ARGV[0])[1=
];\n            print \"y\\n\" if $fd_inum eq $file_inum;\n              =
               ", "/var/run/xen-hotplug/block"], ["SUBSYSTEM=3Dxen-backen=
d", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D/usr/b=
in:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:/usr/s=
bin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dxen-bac=
kend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3Dback=
end/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "SHLVL=
=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/perl"]) =3D 0
26273 brk(0)                            =3D 0xd7d000
26273 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f085a389000
26273 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f085a388000
26273 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26273 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64/libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26273 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64", 0x7fff7446cc60) =3D -1 ENOENT (No such file or directory)
26273 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/lib=
perl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26273 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls", 0=
x7fff7446cc60) =3D -1 ENOENT (No such file or directory)
26273 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64/=
libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26273 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64"=
, 0x7fff7446cc60) =3D -1 ENOENT (No such file or directory)
26273 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl=
=2Eso", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26273 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE", 0x7ff=
f7446cc60) =3D -1 ENOENT (No such file or directory)
26273 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26273 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26273 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7f085a36e000=

26273 close(3)                          =3D 0
26273 open("/usr/lib64/libperl.so", O_RDONLY) =3D 3
26273 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\34\203%=
4\0\0\0@\0\0\0\0\0\0\0\360;\23\0\0\0\0\0\0\0\0\0@\0008\0\5\0@\0\35\0\34\0=
\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\200%4\0\0\0\0\0\200%4\0\0\0T\260\22\=
0\0\0\0\0T\260\22\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0X\260\22\0\0\0\=
0\0X\260\262%4\0\0\0X\260\262%4\0\0\0\250\201\0\0\0\0\0\0\350\242\0\0\0\0=
\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\265\22\0\0\0\0\0\370\265\262%4\0\=
0\0\370\265\262%4\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\=
0\0P\345td\4\0\0\0\250u\21\0\0\0\0\0\250u\221%4\0\0\0\250u\221%4\0\0\0D@\=
0\0\0\0\0\0D@\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\7\4\0\0\360\0\0\0\0\1\0\0\16\0\0\0\0\0\0@\0\200\203\200\225\1\22\=
264\3\31\200l\0\32\0 \5\201\0\240\3\2B\0\200\21R \0\22\0\0\16P\20#\10\216=
\334\30\211\"\0\10 \200\3B\220@\0\1\206\20\30\2\3\21\203$!\312A0\224Y\200=
\27\0\242\26\10\24R@\10\200\220\20A\10\0\220\1\200\206\2\10\304\30i\0\220=
\1\1\202\200\22\20\0\n\1H\0\n\2001J \6\31@L\207\20\10\0000\10(\200\2\0\4\=
251t\"\262\310!\212\240\320\"\0\t"..., 832) =3D 832
26273 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2839671, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D2480, st_size=3D1262384, st_atime=3D2012/10/09-12:04:35, st_mtime=3D=
2012/09/11-12:45:05, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26273 mmap(0x3425800000, 3363648, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425800000
26273 mprotect(0x342592c000, 2093056, PROT_NONE) =3D 0
26273 mmap(0x3425b2b000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x12b000) =3D 0x3425b2b000
26273 mmap(0x3425b34000, 4928, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3425b34000
26273 close(3)                          =3D 0
26273 open("/lib64/libresolv.so.2", O_RDONLY) =3D 3
26273 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\2402\0'4\0\=
0\0@\0\0\0\0\0\0\0@a\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\5\0=
\0\0@\0\0\0\0\0\0\0@\0\0'4\0\0\0@\0\0'4\0\0\0\370\1\0\0\0\0\0\0\370\1\0\0=
\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \361\0\0\0\0\0\0 \361\0'4\0\0\0=
 \361\0'4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\=
0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0'4\0\0\0\0\0\0'4\0\0\0$\10\1\0\0\0\0\0$\10=
\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\24\1\0\0\0\0\0\340\24!'4\=
0\0\0\340\24!'4\0\0\0\340\r\0\0\0\0\0\0\0106\0\0\0\0\0\0\0\0 \0\0\0\0\0\2=
\0\0\0\6\0\0\0\350\35\1\0\0\0\0\0\350\35!'4\0\0\0\350\35!'4\0\0\0\300\1\0=
\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\=
0\0\0008\2\0'4\0\0\0008\2\0'4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0=
\0\0\0\0P\345td\4\0\0\0<\361\0\0\0\0\0\0<\361\0'4\0\0\0<\361\0'4\0\0\0,\3=
\0\0\0\0\0\0,\3\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 8=
32
26273 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148119, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D192, st_size=3D92736, st_atime=3D2012/10/09-11:16:43, st_mtime=3D201=
0/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:42}) =3D 0
26273 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f085a36d000
26273 mmap(0x3427000000, 2181864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3427000000
26273 mprotect(0x3427011000, 2097152, PROT_NONE) =3D 0
26273 mmap(0x3427211000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x11000) =3D 0x3427211000
26273 mmap(0x3427213000, 6888, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3427213000
26273 close(3)                          =3D 0
26273 open("/lib64/libnsl.so.1", O_RDONLY) =3D 3
26273 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240@\340\35=
10\0\0\0@\0\0\0\0\0\0\0\360\265\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0=
\6\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\340\3510\0\0\0@\0\340\3510\0\0\0\370\1=
\0\0\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \33\1\0\0=
\0\0\0 \33\341\3510\0\0\0 \33\341\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\=
0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\340\3510\0\0\0=
\0\0\340\3510\0\0\0\310@\1\0\0\0\0\0\310@\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\=
0\0\6\0\0\0xM\1\0\0\0\0\0xM\1\3520\0\0\0xM\1\3520\0\0\0\310\5\0\0\0\0\0\0=
008-\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250M\1\0\0\0\0\0\250M\1\3=
520\0\0\0\250M\1\3520\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\340\3510\0\0\0008\2\340\351=
0\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0<\33\=
1\0\0\0\0\0<\33\341\3510\0\0\0<\33\341\3510\0\0\0\\\5\0\0\0\0\0\0\\\5\0\0=
\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26273 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147206, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D232, st_size=3D114352, st_atime=3D2012/10/09-12:01:01, st_mtime=3D20=
10/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:44}) =3D 0
26273 mmap(0x30e9e00000, 2194096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9e00000
26273 mprotect(0x30e9e15000, 2093056, PROT_NONE) =3D 0
26273 mmap(0x30ea014000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x14000) =3D 0x30ea014000
26273 mmap(0x30ea016000, 6832, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x30ea016000
26273 close(3)                          =3D 0
26273 open("/lib64/libdl.so.2", O_RDONLY) =3D 3
26273 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\16`\3500=
\0\0\0@\0\0\0\0\0\0\0@R\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0`\3500\0\0\0@\0`\3500\0\0\0\370\1\0\0\0\0\0\0\37=
0\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\300\32\0\0\0\0\0\0\300\3=
2`\3500\0\0\0\300\32`\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0`\3500\0\0\0\0\0`\3500\0\0\=
0\224\37\0\0\0\0\0\0\224\37\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0`-\=
0\0\0\0\0\0`-\200\3500\0\0\0`-\200\3500\0\0\0 \3\0\0\0\0\0\0\240\3\0\0\0\=
0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\240-\0\0\0\0\0\0\240-\200\3500\0\0\0=
\240-\200\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0=
\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2`\3500\0\0\0008\2`\3500\0\0\0 \0\0\=
0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\334\32\0\0\0\0\0\=
0\334\32`\3500\0\0\0\334\32`\3500\0\0\0\264\0\0\0\0\0\0\0\264\0\0\0\0\0\0=
\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26273 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147322, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D48, st_size=3D23360, st_atime=3D2012/10/09-11:13:54, st_mtime=3D2010=
/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26273 mmap(0x30e8600000, 2109696, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8600000
26273 mprotect(0x30e8602000, 2097152, PROT_NONE) =3D 0
26273 mmap(0x30e8802000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x2000) =3D 0x30e8802000
26273 close(3)                          =3D 0
26273 open("/lib64/libm.so.6", O_RDONLY) =3D 3
26273 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`>\240\3510\=
0\0\0@\0\0\0\0\0\0\0\240X\t\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0)\0(\0\6\0\0\=
0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3510\0\0\0@\0\240\3510\0\0\0\370\1\0\0\0\=
0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\360\303\7\0\0\0\=
0\0\360\303\247\3510\0\0\0\360\303\247\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0=
\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3510\=
0\0\0\0\0\240\3510\0\0\0000\22\10\0\0\0\0\0000\22\10\0\0\0\0\0\0\0 \0\0\0=
\0\0\1\0\0\0\6\0\0\0\270\35\10\0\0\0\0\0\270\35\310\3510\0\0\0\270\35\310=
\3510\0\0\0\320\2\0\0\0\0\0\0 \3\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0=
\0\350\35\10\0\0\0\0\0\350\35\310\3510\0\0\0\350\35\310\3510\0\0\0\300\1\=
0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0=
\0\0\0008\2\240\3510\0\0\0008\2\240\3510\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\f\304\7\0\0\0\0\0\f\304\247\3510\0\0\0=
\f\304\247\3510\0\0\0\374\r\0\0\0\0\0\0\374\r\0\0\0\0\0\0\4\0\0\0\0\0\0\0=
Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0"..., 832) =3D 832
26273 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147337, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D1216, st_size=3D615136, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2=
010/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26273 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f085a36c000
26273 mmap(0x30e9a00000, 2629848, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9a00000
26273 mprotect(0x30e9a82000, 2093056, PROT_NONE) =3D 0
26273 mmap(0x30e9c81000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x81000) =3D 0x30e9c81000
26273 close(3)                          =3D 0
26273 open("/lib64/libcrypt.so.1", O_RDONLY) =3D 3
26273 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\t\300%4=
\0\0\0@\0\0\0\0\0\0\0\30\265\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\=
0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\300%4\0\0\0@\0\300%4\0\0\0\370\1\0\0\0\0\=
0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340}\0\0\0\0\0\0\3=
40}\300%4\0\0\0\340}\300%4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\300%4\0\0\0\0\0\300%4\0\0\=
0\4\205\0\0\0\0\0\0\4\205\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\310\=
215\0\0\0\0\0\0\310\215\340%4\0\0\0\310\215\340%4\0\0\0\250\2\0\0\0\0\0\0=
\370\343\2\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\215\0\0\0\0\0\0\3=
70\215\340%4\0\0\0\370\215\340%4\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\=
0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\300%4\0\0\0008\2=
\300%4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0=
\374}\0\0\0\0\0\0\374}\300%4\0\0\0\374}\300%4\0\0\0\34\1\0\0\0\0\0\0\34\1=
\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26273 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148123, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D96, st_size=3D48600, st_atime=3D2012/10/09-12:01:01, st_mtime=3D2010=
/07/28-03:52:39, st_ctime=3D2012/09/11-14:53:52}) =3D 0
26273 mmap(0x3425c00000, 2322880, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425c00000
26273 mprotect(0x3425c09000, 2093056, PROT_NONE) =3D 0
26273 mmap(0x3425e08000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x8000) =3D 0x3425e08000
26273 mmap(0x3425e0a000, 184768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FI=
XED|MAP_ANONYMOUS, -1, 0) =3D 0x3425e0a000
26273 close(3)                          =3D 0
26273 open("/lib64/libutil.so.1", O_RDONLY) =3D 3
26273 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\16\0(4\=
0\0\0@\0\0\0\0\0\0\0(>\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0\0(4\0\0\0@\0\0(4\0\0\0\370\1\0\0\0\0\0\0\370\1\=
0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340\26\0\0\0\0\0\0\340\26\0(=
4\0\0\0\340\26\0(4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0=
\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0(4\0\0\0\0\0\0(4\0\0\0P\32\0\0\0\=
0\0\0P\32\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\35\0\0\0\0\0\0\3=
40\35 (4\0\0\0\340\35 (4\0\0\0 \3\0\0\0\0\0\0000\3\0\0\0\0\0\0\0\0 \0\0\0=
\0\0\2\0\0\0\6\0\0\0\20\36\0\0\0\0\0\0\20\36 (4\0\0\0\20\36 (4\0\0\0\300\=
1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0=
\0\0\0\0008\2\0(4\0\0\0008\2\0(4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\=
0\0\0\0\0\0P\345td\4\0\0\0\374\26\0\0\0\0\0\0\374\26\0(4\0\0\0\374\26\0(4=
\0\0\0D\0\0\0\0\0\0\0D\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8=
32) =3D 832
26273 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147063, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D40, st_size=3D18152, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2010=
/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:49}) =3D 0
26273 mmap(0x3428000000, 2105616, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3428000000
26273 mprotect(0x3428002000, 2093056, PROT_NONE) =3D 0
26273 mmap(0x3428201000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x1000) =3D 0x3428201000
26273 close(3)                          =3D 0
26273 open("/lib64/libpthread.so.0", O_RDONLY) =3D 3
26273 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240W\240\35=
00\0\0\0@\0\0\0\0\0\0\0\340/\2\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0'\0&\0\6\0=
\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3500\0\0\0@\0\240\3500\0\0\0\370\1\0\0=
\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\240\t\1\0\0\0=
\0\0\240\t\241\3500\0\0\0\240\t\241\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\=
0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3500\0\0=
\0\0\0\240\3500\0\0\0pZ\1\0\0\0\0\0pZ\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\=
6\0\0\0\270[\1\0\0\0\0\0\270[\301\3500\0\0\0\270[\301\3500\0\0\0\230\6\0\=
0\0\0\0\0\270G\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250]\1\0\0\0\0\=
0\250]\301\3500\0\0\0\250]\301\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0=
\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\240\3500\0\0\=
0008\2\240\3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345t=
d\4\0\0\0\274\t\1\0\0\0\0\0\274\t\241\3500\0\0\0\274\t\241\3500\0\0\0\344=
\t\0\0\0\0\0\0\344\t\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =
=3D 832
26273 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147328, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D296, st_size=3D145824, st_atime=3D2012/10/09-11:16:43, st_mtime=3D20=
10/07/28-03:52:41, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26273 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f085a36b000
26273 mmap(0x30e8a00000, 2204528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8a00000
26273 mprotect(0x30e8a16000, 2093056, PROT_NONE) =3D 0
26273 mmap(0x30e8c15000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x15000) =3D 0x30e8c15000
26273 mmap(0x30e8c17000, 13168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8c17000
26273 close(3)                          =3D 0
26273 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26273 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26273 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26273 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26273 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26273 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26273 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26273 close(3)                          =3D 0
26273 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f085a36a000
26273 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f085a369000
26273 arch_prctl(ARCH_SET_FS, 0x7f085a3696e0) =3D 0
26273 mprotect(0x3427211000, 4096, PROT_READ) =3D 0
26273 mprotect(0x30ea014000, 4096, PROT_READ) =3D 0
26273 mprotect(0x30e8802000, 4096, PROT_READ) =3D 0
26273 mprotect(0x30e9c81000, 4096, PROT_READ) =3D 0
26273 mprotect(0x3425e08000, 4096, PROT_READ) =3D 0
26273 mprotect(0x3428201000, 4096, PROT_READ) =3D 0
26273 mprotect(0x30e8c15000, 4096, PROT_READ) =3D 0
26273 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26273 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26273 munmap(0x7f085a36e000, 103979)    =3D 0
26273 set_tid_address(0x7f085a369770)   =3D 26273
26273 set_robust_list(0x7f085a369780, 0x18) =3D 0
26273 futex(0x7fff7446d78c, FUTEX_WAKE_PRIVATE, 1) =3D 0
26273 rt_sigaction(SIGRTMIN, {0x30e8a05380, [], SA_RESTORER|SA_SIGINFO, 0=
x30e8a0eb10}, NULL, 8) =3D 0
26273 rt_sigaction(SIGRT_1, {0x30e8a052b0, [], SA_RESTORER|SA_RESTART|SA_=
SIGINFO, 0x30e8a0eb10}, NULL, 8) =3D 0
26273 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) =3D 0
26273 getrlimit(RLIMIT_STACK, {rlim_cur=3D8192*1024, rlim_max=3DRLIM_INFI=
NITY}) =3D 0
26273 rt_sigaction(SIGFPE, {0x1, [FPE], SA_RESTORER|SA_RESTART, 0x30e8230=
2d0}, {SIG_DFL, [], 0}, 8) =3D 0
26273 brk(0)                            =3D 0xd7d000
26273 brk(0xd9f000)                     =3D 0xd9f000
26273 getuid()                          =3D 0
26273 geteuid()                         =3D 0
26273 getgid()                          =3D 0
26273 getegid()                         =3D 0
26273 mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,=
 -1, 0) =3D 0x7f085a348000
26273 open("/dev/urandom", O_RDONLY)    =3D 3
26273 read(3, "\245\"\234\327", 4)      =3D 4
26273 close(3)                          =3D 0
26273 stat("/usr/lib64/perl5/site_perl/5.8.7/x86_64-linux-thread-multi", =
0x7fff7446d440) =3D -1 ENOENT (No such file or directory)
26273 stat("/usr/lib/perl5/site_perl/5.8.7", 0x7fff7446d440) =3D -1 ENOEN=
T (No such file or directory)
26273 stat("/usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi", =
0x7fff7446d440) =3D -1 ENOENT (No such file or directory)
26273 stat("/usr/lib/perl5/site_perl/5.8.6", 0x7fff7446d440) =3D -1 ENOEN=
T (No such file or directory)
26273 stat("/usr/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi", =
0x7fff7446d440) =3D -1 ENOENT (No such file or directory)
26273 stat("/usr/lib/perl5/site_perl/5.8.5", 0x7fff7446d440) =3D -1 ENOEN=
T (No such file or directory)
26273 stat("/usr/lib64/perl5/vendor_perl/5.8.7/x86_64-linux-thread-multi"=
, 0x7fff7446d440) =3D -1 ENOENT (No such file or directory)
26273 stat("/usr/lib/perl5/vendor_perl/5.8.7", 0x7fff7446d440) =3D -1 ENO=
ENT (No such file or directory)
26273 stat("/usr/lib64/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi"=
, 0x7fff7446d440) =3D -1 ENOENT (No such file or directory)
26273 stat("/usr/lib/perl5/vendor_perl/5.8.6", 0x7fff7446d440) =3D -1 ENO=
ENT (No such file or directory)
26273 stat("/usr/lib64/perl5/vendor_perl/5.8.5/x86_64-linux-thread-multi"=
, 0x7fff7446d440) =3D -1 ENOENT (No such file or directory)
26273 stat("/usr/lib/perl5/vendor_perl/5.8.5", 0x7fff7446d440) =3D -1 ENO=
ENT (No such file or directory)
26273 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff7446d200) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26273 lseek(0, 0, SEEK_CUR)             =3D 0
26273 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff7446d200) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26273 lseek(1, 0, SEEK_CUR)             =3D -1 ESPIPE (Illegal seek)
26273 ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff7446d210) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26273 lseek(2, 0, SEEK_CUR)             =3D 593656739
26273 open("/dev/null", O_RDONLY)       =3D 3
26273 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff7446d310) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26273 lseek(3, 0, SEEK_CUR)             =3D 0
26273 fcntl(3, F_SETFD, FD_CLOEXEC)     =3D 0
26273 fstat(3, {st_dev=3Dmakedev(0, 16), st_ino=3D584, st_mode=3DS_IFCHR|=
0666, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
0, st_rdev=3Dmakedev(1, 3), st_atime=3D2012/10/08-11:13:26, st_mtime=3D20=
12/10/08-11:13:26, st_ctime=3D2012/10/08-11:13:27}) =3D 0
26273 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) =3D 0
26273 readlink("/proc/self/exe", "/usr/bin/perl"..., 4095) =3D 13
26273 brk(0xdc0000)                     =3D 0xdc0000
26273 close(3)                          =3D 0
26273 dup(200)                          =3D 3
26273 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff7446d1e0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26273 lseek(3, 0, SEEK_CUR)             =3D 0
26273 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26273 dup2(3, 0)                        =3D 0
26273 close(3)                          =3D 0
26273 fcntl(0, F_SETFD, 0)              =3D 0
26273 fstat(0, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26273 stat("/var/run/xen-hotplug/block", {st_dev=3Dmakedev(8, 2), st_ino=3D=
2801738, st_mode=3DS_IFREG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st=
_blksize=3D4096, st_blocks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:=
24, st_mtime=3D2012/10/09-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D =
0
26273 exit_group(0)                     =3D ?
27813 <... read resumed> "", 128)       =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], WNOHANG, NUL=
L) =3D 26273
27813 wait4(-1, 0x7fffb0100a64, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0)                   =3D 0
27813 close(3)                          =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 write(2, "+ rightfile=3D\n", 13)    =3D 13
27813 write(2, "+ '[' x =3D xy ']'\n", 17) =3D 17
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ true\n", 7)           =3D 7
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ eval 'exec 200>>/var/run/xen-hotplug/block'\n", 46) =3D=
 46
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 write(2, "++ exec\n", 8)          =3D 8
27813 open("/var/run/xen-hotplug/block", O_WRONLY|O_CREAT|O_APPEND, 0666)=
 =3D 3
27813 fcntl(200, F_GETFD)               =3D 0
27813 fcntl(200, F_DUPFD, 10)           =3D 10
27813 fcntl(200, F_GETFD)               =3D 0
27813 dup2(3, 200)                      =3D 200
27813 close(3)                          =3D 0
27813 dup2(10, 200)                     =3D 200
27813 fcntl(10, F_GETFD)                =3D 0
27813 close(10)                         =3D 0
27813 write(2, "+ flock -x 200\n", 15)  =3D 15
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [INT CHLD], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [INT CHLD], NULL, 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26274
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26274 close(255 
27813 rt_sigprocmask(SIG_BLOCK, [CHLD],  
26274 <... close resumed> )             =3D 0
27813 <... rt_sigprocmask resumed> [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [],  
26274 rt_sigprocmask(SIG_SETMASK, [],  
27813 <... rt_sigprocmask resumed> NULL, 8) =3D 0
26274 <... rt_sigprocmask resumed> NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
26274 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0},  
26274 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
27813 <... rt_sigaction resumed> {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}=
, 8) =3D 0
26274 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 wait4(-1,  
26274 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
26274 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26274 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26274 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26274 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26274 execve("/usr/bin/flock", ["flock", "-x", "200"], ["SUBSYSTEM=3Dxen-=
backend", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D=
/usr/bin:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:=
/usr/sbin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dx=
en-backend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3D=
backend/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "S=
HLVL=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/flock"]) =3D 0=

26274 brk(0)                            =3D 0x1a9e000
26274 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fda76a0b000
26274 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fda76a0a000
26274 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26274 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26274 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26274 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7fda769f0000=

26274 close(3)                          =3D 0
26274 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26274 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26274 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26274 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26274 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26274 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26274 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26274 close(3)                          =3D 0
26274 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fda769ef000
26274 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fda769ee000
26274 arch_prctl(ARCH_SET_FS, 0x7fda769ee6e0) =3D 0
26274 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26274 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26274 munmap(0x7fda769f0000, 103979)    =3D 0
26274 flock(200, LOCK_EX)               =3D 0
26274 exit_group(0)                     =3D ?
27813 <... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], 0,=
 NULL) =3D 26274
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, 0x7fffb0100a24, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0xffffffffffffffff)  =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 pipe([3, 4])                      =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26275
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {0=
x436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26275 close(255 
27813 close(4 
26275 <... close resumed> )             =3D 0
27813 <... close resumed> )             =3D 0
27813 read(3,  
26275 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26275 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26275 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26275 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26275 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26275 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26275 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26275 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {S=
IG_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26275 rt_sigaction(SIGINT, {0x4481f0, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26275 dup2(4, 1)                        =3D 1
26275 close(4)                          =3D 0
26275 close(3)                          =3D 0
26275 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26275 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26275 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26275 write(2, "++ perl -e '\n            open STDIN, \"<&200\" or die $!=
;\n            my $fd_inum =3D (stat STDIN)[1]; die $! unless defined $fd=
_inum;\n            my $file_inum =3D (stat $ARGV[0])[1];\n            pr=
int \"y\\n\" if $fd_inum eq $file_inum;\n", 230) =3D 230
26275 write(2, "                             ' /var/run/xen-hotplug/block=
\n", 58) =3D 58
26275 stat(".", {st_dev=3Dmakedev(8, 2), st_ino=3D2, st_mode=3DS_IFDIR|07=
55, st_nlink=3D24, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
8, st_size=3D4096, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2012/10/08-=
11:13:38, st_ctime=3D2012/10/08-11:13:38}) =3D 0
26275 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26275 access("/usr/bin/perl", X_OK)     =3D 0
26275 access("/usr/bin/perl", R_OK)     =3D 0
26275 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26275 access("/usr/bin/perl", X_OK)     =3D 0
26275 access("/usr/bin/perl", R_OK)     =3D 0
26275 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
481f0, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26275 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26275 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26275 execve("/usr/bin/perl", ["perl", "-e", "\n            open STDIN, \=
"<&200\" or die $!;\n            my $fd_inum =3D (stat STDIN)[1]; die $! =
unless defined $fd_inum;\n            my $file_inum =3D (stat $ARGV[0])[1=
];\n            print \"y\\n\" if $fd_inum eq $file_inum;\n              =
               ", "/var/run/xen-hotplug/block"], ["SUBSYSTEM=3Dxen-backen=
d", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D/usr/b=
in:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:/usr/s=
bin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dxen-bac=
kend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3Dback=
end/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "SHLVL=
=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/perl"]) =3D 0
26275 brk(0)                            =3D 0x1f94000
26275 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f60ea136000
26275 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f60ea135000
26275 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26275 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64/libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26275 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64", 0x7fff7127c790) =3D -1 ENOENT (No such file or directory)
26275 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/lib=
perl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26275 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls", 0=
x7fff7127c790) =3D -1 ENOENT (No such file or directory)
26275 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64/=
libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26275 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64"=
, 0x7fff7127c790) =3D -1 ENOENT (No such file or directory)
26275 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl=
=2Eso", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26275 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE", 0x7ff=
f7127c790) =3D -1 ENOENT (No such file or directory)
26275 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26275 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26275 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7f60ea11b000=

26275 close(3)                          =3D 0
26275 open("/usr/lib64/libperl.so", O_RDONLY) =3D 3
26275 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\34\203%=
4\0\0\0@\0\0\0\0\0\0\0\360;\23\0\0\0\0\0\0\0\0\0@\0008\0\5\0@\0\35\0\34\0=
\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\200%4\0\0\0\0\0\200%4\0\0\0T\260\22\=
0\0\0\0\0T\260\22\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0X\260\22\0\0\0\=
0\0X\260\262%4\0\0\0X\260\262%4\0\0\0\250\201\0\0\0\0\0\0\350\242\0\0\0\0=
\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\265\22\0\0\0\0\0\370\265\262%4\0\=
0\0\370\265\262%4\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\=
0\0P\345td\4\0\0\0\250u\21\0\0\0\0\0\250u\221%4\0\0\0\250u\221%4\0\0\0D@\=
0\0\0\0\0\0D@\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\7\4\0\0\360\0\0\0\0\1\0\0\16\0\0\0\0\0\0@\0\200\203\200\225\1\22\=
264\3\31\200l\0\32\0 \5\201\0\240\3\2B\0\200\21R \0\22\0\0\16P\20#\10\216=
\334\30\211\"\0\10 \200\3B\220@\0\1\206\20\30\2\3\21\203$!\312A0\224Y\200=
\27\0\242\26\10\24R@\10\200\220\20A\10\0\220\1\200\206\2\10\304\30i\0\220=
\1\1\202\200\22\20\0\n\1H\0\n\2001J \6\31@L\207\20\10\0000\10(\200\2\0\4\=
251t\"\262\310!\212\240\320\"\0\t"..., 832) =3D 832
26275 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2839671, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D2480, st_size=3D1262384, st_atime=3D2012/10/09-12:04:35, st_mtime=3D=
2012/09/11-12:45:05, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26275 mmap(0x3425800000, 3363648, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425800000
26275 mprotect(0x342592c000, 2093056, PROT_NONE) =3D 0
26275 mmap(0x3425b2b000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x12b000) =3D 0x3425b2b000
26275 mmap(0x3425b34000, 4928, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3425b34000
26275 close(3)                          =3D 0
26275 open("/lib64/libresolv.so.2", O_RDONLY) =3D 3
26275 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\2402\0'4\0\=
0\0@\0\0\0\0\0\0\0@a\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\5\0=
\0\0@\0\0\0\0\0\0\0@\0\0'4\0\0\0@\0\0'4\0\0\0\370\1\0\0\0\0\0\0\370\1\0\0=
\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \361\0\0\0\0\0\0 \361\0'4\0\0\0=
 \361\0'4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\=
0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0'4\0\0\0\0\0\0'4\0\0\0$\10\1\0\0\0\0\0$\10=
\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\24\1\0\0\0\0\0\340\24!'4\=
0\0\0\340\24!'4\0\0\0\340\r\0\0\0\0\0\0\0106\0\0\0\0\0\0\0\0 \0\0\0\0\0\2=
\0\0\0\6\0\0\0\350\35\1\0\0\0\0\0\350\35!'4\0\0\0\350\35!'4\0\0\0\300\1\0=
\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\=
0\0\0008\2\0'4\0\0\0008\2\0'4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0=
\0\0\0\0P\345td\4\0\0\0<\361\0\0\0\0\0\0<\361\0'4\0\0\0<\361\0'4\0\0\0,\3=
\0\0\0\0\0\0,\3\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 8=
32
26275 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148119, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D192, st_size=3D92736, st_atime=3D2012/10/09-11:16:43, st_mtime=3D201=
0/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:42}) =3D 0
26275 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f60ea11a000
26275 mmap(0x3427000000, 2181864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3427000000
26275 mprotect(0x3427011000, 2097152, PROT_NONE) =3D 0
26275 mmap(0x3427211000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x11000) =3D 0x3427211000
26275 mmap(0x3427213000, 6888, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3427213000
26275 close(3)                          =3D 0
26275 open("/lib64/libnsl.so.1", O_RDONLY) =3D 3
26275 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240@\340\35=
10\0\0\0@\0\0\0\0\0\0\0\360\265\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0=
\6\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\340\3510\0\0\0@\0\340\3510\0\0\0\370\1=
\0\0\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \33\1\0\0=
\0\0\0 \33\341\3510\0\0\0 \33\341\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\=
0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\340\3510\0\0\0=
\0\0\340\3510\0\0\0\310@\1\0\0\0\0\0\310@\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\=
0\0\6\0\0\0xM\1\0\0\0\0\0xM\1\3520\0\0\0xM\1\3520\0\0\0\310\5\0\0\0\0\0\0=
008-\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250M\1\0\0\0\0\0\250M\1\3=
520\0\0\0\250M\1\3520\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\340\3510\0\0\0008\2\340\351=
0\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0<\33\=
1\0\0\0\0\0<\33\341\3510\0\0\0<\33\341\3510\0\0\0\\\5\0\0\0\0\0\0\\\5\0\0=
\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26275 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147206, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D232, st_size=3D114352, st_atime=3D2012/10/09-12:01:01, st_mtime=3D20=
10/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:44}) =3D 0
26275 mmap(0x30e9e00000, 2194096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9e00000
26275 mprotect(0x30e9e15000, 2093056, PROT_NONE) =3D 0
26275 mmap(0x30ea014000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x14000) =3D 0x30ea014000
26275 mmap(0x30ea016000, 6832, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x30ea016000
26275 close(3)                          =3D 0
26275 open("/lib64/libdl.so.2", O_RDONLY) =3D 3
26275 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\16`\3500=
\0\0\0@\0\0\0\0\0\0\0@R\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0`\3500\0\0\0@\0`\3500\0\0\0\370\1\0\0\0\0\0\0\37=
0\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\300\32\0\0\0\0\0\0\300\3=
2`\3500\0\0\0\300\32`\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0`\3500\0\0\0\0\0`\3500\0\0\=
0\224\37\0\0\0\0\0\0\224\37\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0`-\=
0\0\0\0\0\0`-\200\3500\0\0\0`-\200\3500\0\0\0 \3\0\0\0\0\0\0\240\3\0\0\0\=
0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\240-\0\0\0\0\0\0\240-\200\3500\0\0\0=
\240-\200\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0=
\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2`\3500\0\0\0008\2`\3500\0\0\0 \0\0\=
0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\334\32\0\0\0\0\0\=
0\334\32`\3500\0\0\0\334\32`\3500\0\0\0\264\0\0\0\0\0\0\0\264\0\0\0\0\0\0=
\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26275 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147322, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D48, st_size=3D23360, st_atime=3D2012/10/09-11:13:54, st_mtime=3D2010=
/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26275 mmap(0x30e8600000, 2109696, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8600000
26275 mprotect(0x30e8602000, 2097152, PROT_NONE) =3D 0
26275 mmap(0x30e8802000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x2000) =3D 0x30e8802000
26275 close(3)                          =3D 0
26275 open("/lib64/libm.so.6", O_RDONLY) =3D 3
26275 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`>\240\3510\=
0\0\0@\0\0\0\0\0\0\0\240X\t\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0)\0(\0\6\0\0\=
0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3510\0\0\0@\0\240\3510\0\0\0\370\1\0\0\0\=
0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\360\303\7\0\0\0\=
0\0\360\303\247\3510\0\0\0\360\303\247\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0=
\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3510\=
0\0\0\0\0\240\3510\0\0\0000\22\10\0\0\0\0\0000\22\10\0\0\0\0\0\0\0 \0\0\0=
\0\0\1\0\0\0\6\0\0\0\270\35\10\0\0\0\0\0\270\35\310\3510\0\0\0\270\35\310=
\3510\0\0\0\320\2\0\0\0\0\0\0 \3\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0=
\0\350\35\10\0\0\0\0\0\350\35\310\3510\0\0\0\350\35\310\3510\0\0\0\300\1\=
0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0=
\0\0\0008\2\240\3510\0\0\0008\2\240\3510\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\f\304\7\0\0\0\0\0\f\304\247\3510\0\0\0=
\f\304\247\3510\0\0\0\374\r\0\0\0\0\0\0\374\r\0\0\0\0\0\0\4\0\0\0\0\0\0\0=
Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0"..., 832) =3D 832
26275 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147337, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D1216, st_size=3D615136, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2=
010/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26275 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f60ea119000
26275 mmap(0x30e9a00000, 2629848, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9a00000
26275 mprotect(0x30e9a82000, 2093056, PROT_NONE) =3D 0
26275 mmap(0x30e9c81000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x81000) =3D 0x30e9c81000
26275 close(3)                          =3D 0
26275 open("/lib64/libcrypt.so.1", O_RDONLY) =3D 3
26275 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\t\300%4=
\0\0\0@\0\0\0\0\0\0\0\30\265\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\=
0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\300%4\0\0\0@\0\300%4\0\0\0\370\1\0\0\0\0\=
0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340}\0\0\0\0\0\0\3=
40}\300%4\0\0\0\340}\300%4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\300%4\0\0\0\0\0\300%4\0\0\=
0\4\205\0\0\0\0\0\0\4\205\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\310\=
215\0\0\0\0\0\0\310\215\340%4\0\0\0\310\215\340%4\0\0\0\250\2\0\0\0\0\0\0=
\370\343\2\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\215\0\0\0\0\0\0\3=
70\215\340%4\0\0\0\370\215\340%4\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\=
0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\300%4\0\0\0008\2=
\300%4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0=
\374}\0\0\0\0\0\0\374}\300%4\0\0\0\374}\300%4\0\0\0\34\1\0\0\0\0\0\0\34\1=
\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26275 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148123, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D96, st_size=3D48600, st_atime=3D2012/10/09-12:01:01, st_mtime=3D2010=
/07/28-03:52:39, st_ctime=3D2012/09/11-14:53:52}) =3D 0
26275 mmap(0x3425c00000, 2322880, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425c00000
26275 mprotect(0x3425c09000, 2093056, PROT_NONE) =3D 0
26275 mmap(0x3425e08000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x8000) =3D 0x3425e08000
26275 mmap(0x3425e0a000, 184768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FI=
XED|MAP_ANONYMOUS, -1, 0) =3D 0x3425e0a000
26275 close(3)                          =3D 0
26275 open("/lib64/libutil.so.1", O_RDONLY) =3D 3
26275 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\16\0(4\=
0\0\0@\0\0\0\0\0\0\0(>\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0\0(4\0\0\0@\0\0(4\0\0\0\370\1\0\0\0\0\0\0\370\1\=
0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340\26\0\0\0\0\0\0\340\26\0(=
4\0\0\0\340\26\0(4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0=
\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0(4\0\0\0\0\0\0(4\0\0\0P\32\0\0\0\=
0\0\0P\32\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\35\0\0\0\0\0\0\3=
40\35 (4\0\0\0\340\35 (4\0\0\0 \3\0\0\0\0\0\0000\3\0\0\0\0\0\0\0\0 \0\0\0=
\0\0\2\0\0\0\6\0\0\0\20\36\0\0\0\0\0\0\20\36 (4\0\0\0\20\36 (4\0\0\0\300\=
1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0=
\0\0\0\0008\2\0(4\0\0\0008\2\0(4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\=
0\0\0\0\0\0P\345td\4\0\0\0\374\26\0\0\0\0\0\0\374\26\0(4\0\0\0\374\26\0(4=
\0\0\0D\0\0\0\0\0\0\0D\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8=
32) =3D 832
26275 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147063, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D40, st_size=3D18152, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2010=
/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:49}) =3D 0
26275 mmap(0x3428000000, 2105616, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3428000000
26275 mprotect(0x3428002000, 2093056, PROT_NONE) =3D 0
26275 mmap(0x3428201000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x1000) =3D 0x3428201000
26275 close(3)                          =3D 0
26275 open("/lib64/libpthread.so.0", O_RDONLY) =3D 3
26275 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240W\240\35=
00\0\0\0@\0\0\0\0\0\0\0\340/\2\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0'\0&\0\6\0=
\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3500\0\0\0@\0\240\3500\0\0\0\370\1\0\0=
\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\240\t\1\0\0\0=
\0\0\240\t\241\3500\0\0\0\240\t\241\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\=
0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3500\0\0=
\0\0\0\240\3500\0\0\0pZ\1\0\0\0\0\0pZ\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\=
6\0\0\0\270[\1\0\0\0\0\0\270[\301\3500\0\0\0\270[\301\3500\0\0\0\230\6\0\=
0\0\0\0\0\270G\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250]\1\0\0\0\0\=
0\250]\301\3500\0\0\0\250]\301\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0=
\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\240\3500\0\0\=
0008\2\240\3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345t=
d\4\0\0\0\274\t\1\0\0\0\0\0\274\t\241\3500\0\0\0\274\t\241\3500\0\0\0\344=
\t\0\0\0\0\0\0\344\t\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =
=3D 832
26275 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147328, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D296, st_size=3D145824, st_atime=3D2012/10/09-11:16:43, st_mtime=3D20=
10/07/28-03:52:41, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26275 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f60ea118000
26275 mmap(0x30e8a00000, 2204528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8a00000
26275 mprotect(0x30e8a16000, 2093056, PROT_NONE) =3D 0
26275 mmap(0x30e8c15000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x15000) =3D 0x30e8c15000
26275 mmap(0x30e8c17000, 13168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8c17000
26275 close(3)                          =3D 0
26275 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26275 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26275 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26275 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26275 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26275 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26275 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26275 close(3)                          =3D 0
26275 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f60ea117000
26275 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f60ea116000
26275 arch_prctl(ARCH_SET_FS, 0x7f60ea1166e0) =3D 0
26275 mprotect(0x3427211000, 4096, PROT_READ) =3D 0
26275 mprotect(0x30ea014000, 4096, PROT_READ) =3D 0
26275 mprotect(0x30e8802000, 4096, PROT_READ) =3D 0
26275 mprotect(0x30e9c81000, 4096, PROT_READ) =3D 0
26275 mprotect(0x3425e08000, 4096, PROT_READ) =3D 0
26275 mprotect(0x3428201000, 4096, PROT_READ) =3D 0
26275 mprotect(0x30e8c15000, 4096, PROT_READ) =3D 0
26275 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26275 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26275 munmap(0x7f60ea11b000, 103979)    =3D 0
26275 set_tid_address(0x7f60ea116770)   =3D 26275
26275 set_robust_list(0x7f60ea116780, 0x18) =3D 0
26275 futex(0x7fff7127d2bc, FUTEX_WAKE_PRIVATE, 1) =3D 0
26275 rt_sigaction(SIGRTMIN, {0x30e8a05380, [], SA_RESTORER|SA_SIGINFO, 0=
x30e8a0eb10}, NULL, 8) =3D 0
26275 rt_sigaction(SIGRT_1, {0x30e8a052b0, [], SA_RESTORER|SA_RESTART|SA_=
SIGINFO, 0x30e8a0eb10}, NULL, 8) =3D 0
26275 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) =3D 0
26275 getrlimit(RLIMIT_STACK, {rlim_cur=3D8192*1024, rlim_max=3DRLIM_INFI=
NITY}) =3D 0
26275 rt_sigaction(SIGFPE, {0x1, [FPE], SA_RESTORER|SA_RESTART, 0x30e8230=
2d0}, {SIG_DFL, [], 0}, 8) =3D 0
26275 brk(0)                            =3D 0x1f94000
26275 brk(0x1fb6000)                    =3D 0x1fb6000
26275 getuid()                          =3D 0
26275 geteuid()                         =3D 0
26275 getgid()                          =3D 0
26275 getegid()                         =3D 0
26275 mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,=
 -1, 0) =3D 0x7f60ea0f5000
26275 open("/dev/urandom", O_RDONLY)    =3D 3
26275 read(3, "\247\203\340\225", 4)    =3D 4
26275 close(3)                          =3D 0
26275 stat("/usr/lib64/perl5/site_perl/5.8.7/x86_64-linux-thread-multi", =
0x7fff7127cf70) =3D -1 ENOENT (No such file or directory)
26275 stat("/usr/lib/perl5/site_perl/5.8.7", 0x7fff7127cf70) =3D -1 ENOEN=
T (No such file or directory)
26275 stat("/usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi", =
0x7fff7127cf70) =3D -1 ENOENT (No such file or directory)
26275 stat("/usr/lib/perl5/site_perl/5.8.6", 0x7fff7127cf70) =3D -1 ENOEN=
T (No such file or directory)
26275 stat("/usr/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi", =
0x7fff7127cf70) =3D -1 ENOENT (No such file or directory)
26275 stat("/usr/lib/perl5/site_perl/5.8.5", 0x7fff7127cf70) =3D -1 ENOEN=
T (No such file or directory)
26275 stat("/usr/lib64/perl5/vendor_perl/5.8.7/x86_64-linux-thread-multi"=
, 0x7fff7127cf70) =3D -1 ENOENT (No such file or directory)
26275 stat("/usr/lib/perl5/vendor_perl/5.8.7", 0x7fff7127cf70) =3D -1 ENO=
ENT (No such file or directory)
26275 stat("/usr/lib64/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi"=
, 0x7fff7127cf70) =3D -1 ENOENT (No such file or directory)
26275 stat("/usr/lib/perl5/vendor_perl/5.8.6", 0x7fff7127cf70) =3D -1 ENO=
ENT (No such file or directory)
26275 stat("/usr/lib64/perl5/vendor_perl/5.8.5/x86_64-linux-thread-multi"=
, 0x7fff7127cf70) =3D -1 ENOENT (No such file or directory)
26275 stat("/usr/lib/perl5/vendor_perl/5.8.5", 0x7fff7127cf70) =3D -1 ENO=
ENT (No such file or directory)
26275 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff7127cd30) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26275 lseek(0, 0, SEEK_CUR)             =3D 0
26275 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff7127cd30) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26275 lseek(1, 0, SEEK_CUR)             =3D -1 ESPIPE (Illegal seek)
26275 ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff7127cd40) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26275 lseek(2, 0, SEEK_CUR)             =3D 593657133
26275 open("/dev/null", O_RDONLY)       =3D 3
26275 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff7127ce40) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26275 lseek(3, 0, SEEK_CUR)             =3D 0
26275 fcntl(3, F_SETFD, FD_CLOEXEC)     =3D 0
26275 fstat(3, {st_dev=3Dmakedev(0, 16), st_ino=3D584, st_mode=3DS_IFCHR|=
0666, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
0, st_rdev=3Dmakedev(1, 3), st_atime=3D2012/10/08-11:13:26, st_mtime=3D20=
12/10/08-11:13:26, st_ctime=3D2012/10/08-11:13:27}) =3D 0
26275 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) =3D 0
26275 readlink("/proc/self/exe", "/usr/bin/perl"..., 4095) =3D 13
26275 brk(0x1fd7000)                    =3D 0x1fd7000
26275 close(3)                          =3D 0
26275 dup(200)                          =3D 3
26275 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff7127cd10) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26275 lseek(3, 0, SEEK_CUR)             =3D 0
26275 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26275 dup2(3, 0)                        =3D 0
26275 close(3)                          =3D 0
26275 fcntl(0, F_SETFD, 0)              =3D 0
26275 fstat(0, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26275 stat("/var/run/xen-hotplug/block", {st_dev=3Dmakedev(8, 2), st_ino=3D=
2801738, st_mode=3DS_IFREG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st=
_blksize=3D4096, st_blocks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:=
24, st_mtime=3D2012/10/09-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D =
0
26275 exit_group(0)                     =3D ?
27813 <... read resumed> "", 128)       =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], WNOHANG, NUL=
L) =3D 26275
27813 wait4(-1, 0x7fffb0100a64, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0)                   =3D 0
27813 close(3)                          =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 write(2, "+ rightfile=3D\n", 13)    =3D 13
27813 write(2, "+ '[' x =3D xy ']'\n", 17) =3D 17
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ true\n", 7)           =3D 7
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ eval 'exec 200>>/var/run/xen-hotplug/block'\n", 46) =3D=
 46
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 write(2, "++ exec\n", 8)          =3D 8
27813 open("/var/run/xen-hotplug/block", O_WRONLY|O_CREAT|O_APPEND, 0666)=
 =3D 3
27813 fcntl(200, F_GETFD)               =3D 0
27813 fcntl(200, F_DUPFD, 10)           =3D 10
27813 fcntl(200, F_GETFD)               =3D 0
27813 dup2(3, 200)                      =3D 200
27813 close(3)                          =3D 0
27813 dup2(10, 200)                     =3D 200
27813 fcntl(10, F_GETFD)                =3D 0
27813 close(10)                         =3D 0
27813 write(2, "+ flock -x 200\n", 15)  =3D 15
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [INT CHLD], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [INT CHLD], NULL, 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26276
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26276 close(255 
27813 rt_sigprocmask(SIG_BLOCK, [CHLD],  
26276 <... close resumed> )             =3D 0
27813 <... rt_sigprocmask resumed> [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [],  
26276 rt_sigprocmask(SIG_SETMASK, [],  
27813 <... rt_sigprocmask resumed> NULL, 8) =3D 0
26276 <... rt_sigprocmask resumed> NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
26276 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0},  
26276 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
27813 <... rt_sigaction resumed> {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}=
, 8) =3D 0
26276 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 wait4(-1,  
26276 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
26276 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26276 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26276 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26276 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26276 execve("/usr/bin/flock", ["flock", "-x", "200"], ["SUBSYSTEM=3Dxen-=
backend", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D=
/usr/bin:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:=
/usr/sbin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dx=
en-backend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3D=
backend/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "S=
HLVL=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/flock"]) =3D 0=

26276 brk(0)                            =3D 0x1b6a000
26276 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fae88652000
26276 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fae88651000
26276 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26276 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26276 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26276 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7fae88637000=

26276 close(3)                          =3D 0
26276 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26276 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26276 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26276 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26276 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26276 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26276 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26276 close(3)                          =3D 0
26276 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fae88636000
26276 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fae88635000
26276 arch_prctl(ARCH_SET_FS, 0x7fae886356e0) =3D 0
26276 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26276 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26276 munmap(0x7fae88637000, 103979)    =3D 0
26276 flock(200, LOCK_EX)               =3D 0
26276 exit_group(0)                     =3D ?
27813 <... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], 0,=
 NULL) =3D 26276
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, 0x7fffb0100a24, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0xffffffffffffffff)  =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 pipe([3, 4])                      =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26277
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {0=
x436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26277 close(255 
27813 close(4 
26277 <... close resumed> )             =3D 0
27813 <... close resumed> )             =3D 0
27813 read(3,  
26277 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26277 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26277 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26277 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26277 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26277 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26277 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26277 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {S=
IG_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26277 rt_sigaction(SIGINT, {0x4481f0, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26277 dup2(4, 1)                        =3D 1
26277 close(4)                          =3D 0
26277 close(3)                          =3D 0
26277 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26277 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26277 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26277 write(2, "++ perl -e '\n            open STDIN, \"<&200\" or die $!=
;\n            my $fd_inum =3D (stat STDIN)[1]; die $! unless defined $fd=
_inum;\n            my $file_inum =3D (stat $ARGV[0])[1];\n            pr=
int \"y\\n\" if $fd_inum eq $file_inum;\n", 230) =3D 230
26277 write(2, "                             ' /var/run/xen-hotplug/block=
\n", 58) =3D 58
26277 stat(".", {st_dev=3Dmakedev(8, 2), st_ino=3D2, st_mode=3DS_IFDIR|07=
55, st_nlink=3D24, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
8, st_size=3D4096, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2012/10/08-=
11:13:38, st_ctime=3D2012/10/08-11:13:38}) =3D 0
26277 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26277 access("/usr/bin/perl", X_OK)     =3D 0
26277 access("/usr/bin/perl", R_OK)     =3D 0
26277 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26277 access("/usr/bin/perl", X_OK)     =3D 0
26277 access("/usr/bin/perl", R_OK)     =3D 0
26277 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
481f0, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26277 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26277 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26277 execve("/usr/bin/perl", ["perl", "-e", "\n            open STDIN, \=
"<&200\" or die $!;\n            my $fd_inum =3D (stat STDIN)[1]; die $! =
unless defined $fd_inum;\n            my $file_inum =3D (stat $ARGV[0])[1=
];\n            print \"y\\n\" if $fd_inum eq $file_inum;\n              =
               ", "/var/run/xen-hotplug/block"], ["SUBSYSTEM=3Dxen-backen=
d", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D/usr/b=
in:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:/usr/s=
bin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dxen-bac=
kend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3Dback=
end/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "SHLVL=
=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/perl"]) =3D 0
26277 brk(0)                            =3D 0x1f39000
26277 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f78e8785000
26277 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f78e8784000
26277 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26277 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64/libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26277 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64", 0x7fffe81dbe70) =3D -1 ENOENT (No such file or directory)
26277 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/lib=
perl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26277 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls", 0=
x7fffe81dbe70) =3D -1 ENOENT (No such file or directory)
26277 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64/=
libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26277 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64"=
, 0x7fffe81dbe70) =3D -1 ENOENT (No such file or directory)
26277 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl=
=2Eso", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26277 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE", 0x7ff=
fe81dbe70) =3D -1 ENOENT (No such file or directory)
26277 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26277 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26277 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7f78e876a000=

26277 close(3)                          =3D 0
26277 open("/usr/lib64/libperl.so", O_RDONLY) =3D 3
26277 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\34\203%=
4\0\0\0@\0\0\0\0\0\0\0\360;\23\0\0\0\0\0\0\0\0\0@\0008\0\5\0@\0\35\0\34\0=
\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\200%4\0\0\0\0\0\200%4\0\0\0T\260\22\=
0\0\0\0\0T\260\22\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0X\260\22\0\0\0\=
0\0X\260\262%4\0\0\0X\260\262%4\0\0\0\250\201\0\0\0\0\0\0\350\242\0\0\0\0=
\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\265\22\0\0\0\0\0\370\265\262%4\0\=
0\0\370\265\262%4\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\=
0\0P\345td\4\0\0\0\250u\21\0\0\0\0\0\250u\221%4\0\0\0\250u\221%4\0\0\0D@\=
0\0\0\0\0\0D@\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\7\4\0\0\360\0\0\0\0\1\0\0\16\0\0\0\0\0\0@\0\200\203\200\225\1\22\=
264\3\31\200l\0\32\0 \5\201\0\240\3\2B\0\200\21R \0\22\0\0\16P\20#\10\216=
\334\30\211\"\0\10 \200\3B\220@\0\1\206\20\30\2\3\21\203$!\312A0\224Y\200=
\27\0\242\26\10\24R@\10\200\220\20A\10\0\220\1\200\206\2\10\304\30i\0\220=
\1\1\202\200\22\20\0\n\1H\0\n\2001J \6\31@L\207\20\10\0000\10(\200\2\0\4\=
251t\"\262\310!\212\240\320\"\0\t"..., 832) =3D 832
26277 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2839671, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D2480, st_size=3D1262384, st_atime=3D2012/10/09-12:04:35, st_mtime=3D=
2012/09/11-12:45:05, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26277 mmap(0x3425800000, 3363648, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425800000
26277 mprotect(0x342592c000, 2093056, PROT_NONE) =3D 0
26277 mmap(0x3425b2b000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x12b000) =3D 0x3425b2b000
26277 mmap(0x3425b34000, 4928, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3425b34000
26277 close(3)                          =3D 0
26277 open("/lib64/libresolv.so.2", O_RDONLY) =3D 3
26277 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\2402\0'4\0\=
0\0@\0\0\0\0\0\0\0@a\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\5\0=
\0\0@\0\0\0\0\0\0\0@\0\0'4\0\0\0@\0\0'4\0\0\0\370\1\0\0\0\0\0\0\370\1\0\0=
\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \361\0\0\0\0\0\0 \361\0'4\0\0\0=
 \361\0'4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\=
0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0'4\0\0\0\0\0\0'4\0\0\0$\10\1\0\0\0\0\0$\10=
\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\24\1\0\0\0\0\0\340\24!'4\=
0\0\0\340\24!'4\0\0\0\340\r\0\0\0\0\0\0\0106\0\0\0\0\0\0\0\0 \0\0\0\0\0\2=
\0\0\0\6\0\0\0\350\35\1\0\0\0\0\0\350\35!'4\0\0\0\350\35!'4\0\0\0\300\1\0=
\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\=
0\0\0008\2\0'4\0\0\0008\2\0'4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0=
\0\0\0\0P\345td\4\0\0\0<\361\0\0\0\0\0\0<\361\0'4\0\0\0<\361\0'4\0\0\0,\3=
\0\0\0\0\0\0,\3\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 8=
32
26277 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148119, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D192, st_size=3D92736, st_atime=3D2012/10/09-11:16:43, st_mtime=3D201=
0/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:42}) =3D 0
26277 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f78e8769000
26277 mmap(0x3427000000, 2181864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3427000000
26277 mprotect(0x3427011000, 2097152, PROT_NONE) =3D 0
26277 mmap(0x3427211000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x11000) =3D 0x3427211000
26277 mmap(0x3427213000, 6888, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3427213000
26277 close(3)                          =3D 0
26277 open("/lib64/libnsl.so.1", O_RDONLY) =3D 3
26277 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240@\340\35=
10\0\0\0@\0\0\0\0\0\0\0\360\265\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0=
\6\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\340\3510\0\0\0@\0\340\3510\0\0\0\370\1=
\0\0\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \33\1\0\0=
\0\0\0 \33\341\3510\0\0\0 \33\341\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\=
0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\340\3510\0\0\0=
\0\0\340\3510\0\0\0\310@\1\0\0\0\0\0\310@\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\=
0\0\6\0\0\0xM\1\0\0\0\0\0xM\1\3520\0\0\0xM\1\3520\0\0\0\310\5\0\0\0\0\0\0=
008-\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250M\1\0\0\0\0\0\250M\1\3=
520\0\0\0\250M\1\3520\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\340\3510\0\0\0008\2\340\351=
0\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0<\33\=
1\0\0\0\0\0<\33\341\3510\0\0\0<\33\341\3510\0\0\0\\\5\0\0\0\0\0\0\\\5\0\0=
\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26277 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147206, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D232, st_size=3D114352, st_atime=3D2012/10/09-12:01:01, st_mtime=3D20=
10/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:44}) =3D 0
26277 mmap(0x30e9e00000, 2194096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9e00000
26277 mprotect(0x30e9e15000, 2093056, PROT_NONE) =3D 0
26277 mmap(0x30ea014000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x14000) =3D 0x30ea014000
26277 mmap(0x30ea016000, 6832, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x30ea016000
26277 close(3)                          =3D 0
26277 open("/lib64/libdl.so.2", O_RDONLY) =3D 3
26277 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\16`\3500=
\0\0\0@\0\0\0\0\0\0\0@R\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0`\3500\0\0\0@\0`\3500\0\0\0\370\1\0\0\0\0\0\0\37=
0\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\300\32\0\0\0\0\0\0\300\3=
2`\3500\0\0\0\300\32`\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0`\3500\0\0\0\0\0`\3500\0\0\=
0\224\37\0\0\0\0\0\0\224\37\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0`-\=
0\0\0\0\0\0`-\200\3500\0\0\0`-\200\3500\0\0\0 \3\0\0\0\0\0\0\240\3\0\0\0\=
0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\240-\0\0\0\0\0\0\240-\200\3500\0\0\0=
\240-\200\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0=
\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2`\3500\0\0\0008\2`\3500\0\0\0 \0\0\=
0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\334\32\0\0\0\0\0\=
0\334\32`\3500\0\0\0\334\32`\3500\0\0\0\264\0\0\0\0\0\0\0\264\0\0\0\0\0\0=
\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26277 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147322, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D48, st_size=3D23360, st_atime=3D2012/10/09-11:13:54, st_mtime=3D2010=
/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26277 mmap(0x30e8600000, 2109696, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8600000
26277 mprotect(0x30e8602000, 2097152, PROT_NONE) =3D 0
26277 mmap(0x30e8802000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x2000) =3D 0x30e8802000
26277 close(3)                          =3D 0
26277 open("/lib64/libm.so.6", O_RDONLY) =3D 3
26277 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`>\240\3510\=
0\0\0@\0\0\0\0\0\0\0\240X\t\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0)\0(\0\6\0\0\=
0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3510\0\0\0@\0\240\3510\0\0\0\370\1\0\0\0\=
0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\360\303\7\0\0\0\=
0\0\360\303\247\3510\0\0\0\360\303\247\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0=
\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3510\=
0\0\0\0\0\240\3510\0\0\0000\22\10\0\0\0\0\0000\22\10\0\0\0\0\0\0\0 \0\0\0=
\0\0\1\0\0\0\6\0\0\0\270\35\10\0\0\0\0\0\270\35\310\3510\0\0\0\270\35\310=
\3510\0\0\0\320\2\0\0\0\0\0\0 \3\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0=
\0\350\35\10\0\0\0\0\0\350\35\310\3510\0\0\0\350\35\310\3510\0\0\0\300\1\=
0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0=
\0\0\0008\2\240\3510\0\0\0008\2\240\3510\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\f\304\7\0\0\0\0\0\f\304\247\3510\0\0\0=
\f\304\247\3510\0\0\0\374\r\0\0\0\0\0\0\374\r\0\0\0\0\0\0\4\0\0\0\0\0\0\0=
Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0"..., 832) =3D 832
26277 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147337, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D1216, st_size=3D615136, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2=
010/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26277 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f78e8768000
26277 mmap(0x30e9a00000, 2629848, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9a00000
26277 mprotect(0x30e9a82000, 2093056, PROT_NONE) =3D 0
26277 mmap(0x30e9c81000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x81000) =3D 0x30e9c81000
26277 close(3)                          =3D 0
26277 open("/lib64/libcrypt.so.1", O_RDONLY) =3D 3
26277 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\t\300%4=
\0\0\0@\0\0\0\0\0\0\0\30\265\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\=
0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\300%4\0\0\0@\0\300%4\0\0\0\370\1\0\0\0\0\=
0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340}\0\0\0\0\0\0\3=
40}\300%4\0\0\0\340}\300%4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\300%4\0\0\0\0\0\300%4\0\0\=
0\4\205\0\0\0\0\0\0\4\205\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\310\=
215\0\0\0\0\0\0\310\215\340%4\0\0\0\310\215\340%4\0\0\0\250\2\0\0\0\0\0\0=
\370\343\2\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\215\0\0\0\0\0\0\3=
70\215\340%4\0\0\0\370\215\340%4\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\=
0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\300%4\0\0\0008\2=
\300%4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0=
\374}\0\0\0\0\0\0\374}\300%4\0\0\0\374}\300%4\0\0\0\34\1\0\0\0\0\0\0\34\1=
\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26277 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148123, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D96, st_size=3D48600, st_atime=3D2012/10/09-12:01:01, st_mtime=3D2010=
/07/28-03:52:39, st_ctime=3D2012/09/11-14:53:52}) =3D 0
26277 mmap(0x3425c00000, 2322880, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425c00000
26277 mprotect(0x3425c09000, 2093056, PROT_NONE) =3D 0
26277 mmap(0x3425e08000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x8000) =3D 0x3425e08000
26277 mmap(0x3425e0a000, 184768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FI=
XED|MAP_ANONYMOUS, -1, 0) =3D 0x3425e0a000
26277 close(3)                          =3D 0
26277 open("/lib64/libutil.so.1", O_RDONLY) =3D 3
26277 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\16\0(4\=
0\0\0@\0\0\0\0\0\0\0(>\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0\0(4\0\0\0@\0\0(4\0\0\0\370\1\0\0\0\0\0\0\370\1\=
0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340\26\0\0\0\0\0\0\340\26\0(=
4\0\0\0\340\26\0(4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0=
\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0(4\0\0\0\0\0\0(4\0\0\0P\32\0\0\0\=
0\0\0P\32\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\35\0\0\0\0\0\0\3=
40\35 (4\0\0\0\340\35 (4\0\0\0 \3\0\0\0\0\0\0000\3\0\0\0\0\0\0\0\0 \0\0\0=
\0\0\2\0\0\0\6\0\0\0\20\36\0\0\0\0\0\0\20\36 (4\0\0\0\20\36 (4\0\0\0\300\=
1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0=
\0\0\0\0008\2\0(4\0\0\0008\2\0(4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\=
0\0\0\0\0\0P\345td\4\0\0\0\374\26\0\0\0\0\0\0\374\26\0(4\0\0\0\374\26\0(4=
\0\0\0D\0\0\0\0\0\0\0D\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8=
32) =3D 832
26277 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147063, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D40, st_size=3D18152, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2010=
/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:49}) =3D 0
26277 mmap(0x3428000000, 2105616, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3428000000
26277 mprotect(0x3428002000, 2093056, PROT_NONE) =3D 0
26277 mmap(0x3428201000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x1000) =3D 0x3428201000
26277 close(3)                          =3D 0
26277 open("/lib64/libpthread.so.0", O_RDONLY) =3D 3
26277 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240W\240\35=
00\0\0\0@\0\0\0\0\0\0\0\340/\2\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0'\0&\0\6\0=
\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3500\0\0\0@\0\240\3500\0\0\0\370\1\0\0=
\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\240\t\1\0\0\0=
\0\0\240\t\241\3500\0\0\0\240\t\241\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\=
0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3500\0\0=
\0\0\0\240\3500\0\0\0pZ\1\0\0\0\0\0pZ\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\=
6\0\0\0\270[\1\0\0\0\0\0\270[\301\3500\0\0\0\270[\301\3500\0\0\0\230\6\0\=
0\0\0\0\0\270G\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250]\1\0\0\0\0\=
0\250]\301\3500\0\0\0\250]\301\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0=
\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\240\3500\0\0\=
0008\2\240\3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345t=
d\4\0\0\0\274\t\1\0\0\0\0\0\274\t\241\3500\0\0\0\274\t\241\3500\0\0\0\344=
\t\0\0\0\0\0\0\344\t\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =
=3D 832
26277 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147328, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D296, st_size=3D145824, st_atime=3D2012/10/09-11:16:43, st_mtime=3D20=
10/07/28-03:52:41, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26277 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f78e8767000
26277 mmap(0x30e8a00000, 2204528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8a00000
26277 mprotect(0x30e8a16000, 2093056, PROT_NONE) =3D 0
26277 mmap(0x30e8c15000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x15000) =3D 0x30e8c15000
26277 mmap(0x30e8c17000, 13168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8c17000
26277 close(3)                          =3D 0
26277 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26277 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26277 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26277 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26277 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26277 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26277 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26277 close(3)                          =3D 0
26277 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f78e8766000
26277 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f78e8765000
26277 arch_prctl(ARCH_SET_FS, 0x7f78e87656e0) =3D 0
26277 mprotect(0x3427211000, 4096, PROT_READ) =3D 0
26277 mprotect(0x30ea014000, 4096, PROT_READ) =3D 0
26277 mprotect(0x30e8802000, 4096, PROT_READ) =3D 0
26277 mprotect(0x30e9c81000, 4096, PROT_READ) =3D 0
26277 mprotect(0x3425e08000, 4096, PROT_READ) =3D 0
26277 mprotect(0x3428201000, 4096, PROT_READ) =3D 0
26277 mprotect(0x30e8c15000, 4096, PROT_READ) =3D 0
26277 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26277 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26277 munmap(0x7f78e876a000, 103979)    =3D 0
26277 set_tid_address(0x7f78e8765770)   =3D 26277
26277 set_robust_list(0x7f78e8765780, 0x18) =3D 0
26277 futex(0x7fffe81dc99c, FUTEX_WAKE_PRIVATE, 1) =3D 0
26277 rt_sigaction(SIGRTMIN, {0x30e8a05380, [], SA_RESTORER|SA_SIGINFO, 0=
x30e8a0eb10}, NULL, 8) =3D 0
26277 rt_sigaction(SIGRT_1, {0x30e8a052b0, [], SA_RESTORER|SA_RESTART|SA_=
SIGINFO, 0x30e8a0eb10}, NULL, 8) =3D 0
26277 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) =3D 0
26277 getrlimit(RLIMIT_STACK, {rlim_cur=3D8192*1024, rlim_max=3DRLIM_INFI=
NITY}) =3D 0
26277 rt_sigaction(SIGFPE, {0x1, [FPE], SA_RESTORER|SA_RESTART, 0x30e8230=
2d0}, {SIG_DFL, [], 0}, 8) =3D 0
26277 brk(0)                            =3D 0x1f39000
26277 brk(0x1f5b000)                    =3D 0x1f5b000
26277 getuid()                          =3D 0
26277 geteuid()                         =3D 0
26277 getgid()                          =3D 0
26277 getegid()                         =3D 0
26277 mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,=
 -1, 0) =3D 0x7f78e8744000
26277 open("/dev/urandom", O_RDONLY)    =3D 3
26277 read(3, "\344\32\254\372", 4)     =3D 4
26277 close(3)                          =3D 0
26277 stat("/usr/lib64/perl5/site_perl/5.8.7/x86_64-linux-thread-multi", =
0x7fffe81dc650) =3D -1 ENOENT (No such file or directory)
26277 stat("/usr/lib/perl5/site_perl/5.8.7", 0x7fffe81dc650) =3D -1 ENOEN=
T (No such file or directory)
26277 stat("/usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi", =
0x7fffe81dc650) =3D -1 ENOENT (No such file or directory)
26277 stat("/usr/lib/perl5/site_perl/5.8.6", 0x7fffe81dc650) =3D -1 ENOEN=
T (No such file or directory)
26277 stat("/usr/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi", =
0x7fffe81dc650) =3D -1 ENOENT (No such file or directory)
26277 stat("/usr/lib/perl5/site_perl/5.8.5", 0x7fffe81dc650) =3D -1 ENOEN=
T (No such file or directory)
26277 stat("/usr/lib64/perl5/vendor_perl/5.8.7/x86_64-linux-thread-multi"=
, 0x7fffe81dc650) =3D -1 ENOENT (No such file or directory)
26277 stat("/usr/lib/perl5/vendor_perl/5.8.7", 0x7fffe81dc650) =3D -1 ENO=
ENT (No such file or directory)
26277 stat("/usr/lib64/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi"=
, 0x7fffe81dc650) =3D -1 ENOENT (No such file or directory)
26277 stat("/usr/lib/perl5/vendor_perl/5.8.6", 0x7fffe81dc650) =3D -1 ENO=
ENT (No such file or directory)
26277 stat("/usr/lib64/perl5/vendor_perl/5.8.5/x86_64-linux-thread-multi"=
, 0x7fffe81dc650) =3D -1 ENOENT (No such file or directory)
26277 stat("/usr/lib/perl5/vendor_perl/5.8.5", 0x7fffe81dc650) =3D -1 ENO=
ENT (No such file or directory)
26277 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffe81dc410) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26277 lseek(0, 0, SEEK_CUR)             =3D 0
26277 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffe81dc410) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26277 lseek(1, 0, SEEK_CUR)             =3D -1 ESPIPE (Illegal seek)
26277 ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffe81dc420) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26277 lseek(2, 0, SEEK_CUR)             =3D 593657527
26277 open("/dev/null", O_RDONLY)       =3D 3
26277 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffe81dc520) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26277 lseek(3, 0, SEEK_CUR)             =3D 0
26277 fcntl(3, F_SETFD, FD_CLOEXEC)     =3D 0
26277 fstat(3, {st_dev=3Dmakedev(0, 16), st_ino=3D584, st_mode=3DS_IFCHR|=
0666, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
0, st_rdev=3Dmakedev(1, 3), st_atime=3D2012/10/08-11:13:26, st_mtime=3D20=
12/10/08-11:13:26, st_ctime=3D2012/10/08-11:13:27}) =3D 0
26277 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) =3D 0
26277 readlink("/proc/self/exe", "/usr/bin/perl"..., 4095) =3D 13
26277 brk(0x1f7c000)                    =3D 0x1f7c000
26277 close(3)                          =3D 0
26277 dup(200)                          =3D 3
26277 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffe81dc3f0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26277 lseek(3, 0, SEEK_CUR)             =3D 0
26277 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26277 dup2(3, 0)                        =3D 0
26277 close(3)                          =3D 0
26277 fcntl(0, F_SETFD, 0)              =3D 0
26277 fstat(0, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26277 stat("/var/run/xen-hotplug/block", {st_dev=3Dmakedev(8, 2), st_ino=3D=
2801738, st_mode=3DS_IFREG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st=
_blksize=3D4096, st_blocks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:=
24, st_mtime=3D2012/10/09-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D =
0
26277 exit_group(0)                     =3D ?
27813 <... read resumed> "", 128)       =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], WNOHANG, NUL=
L) =3D 26277
27813 wait4(-1, 0x7fffb0100a64, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0)                   =3D 0
27813 close(3)                          =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 write(2, "+ rightfile=3D\n", 13)    =3D 13
27813 write(2, "+ '[' x =3D xy ']'\n", 17) =3D 17
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ true\n", 7)           =3D 7
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ eval 'exec 200>>/var/run/xen-hotplug/block'\n", 46) =3D=
 46
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 write(2, "++ exec\n", 8)          =3D 8
27813 open("/var/run/xen-hotplug/block", O_WRONLY|O_CREAT|O_APPEND, 0666)=
 =3D 3
27813 fcntl(200, F_GETFD)               =3D 0
27813 fcntl(200, F_DUPFD, 10)           =3D 10
27813 fcntl(200, F_GETFD)               =3D 0
27813 dup2(3, 200)                      =3D 200
27813 close(3)                          =3D 0
27813 dup2(10, 200)                     =3D 200
27813 fcntl(10, F_GETFD)                =3D 0
27813 close(10)                         =3D 0
27813 write(2, "+ flock -x 200\n", 15)  =3D 15
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [INT CHLD], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [INT CHLD], NULL, 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26278
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26278 close(255 
27813 rt_sigprocmask(SIG_BLOCK, [CHLD],  
26278 <... close resumed> )             =3D 0
27813 <... rt_sigprocmask resumed> [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [],  
26278 rt_sigprocmask(SIG_SETMASK, [],  
27813 <... rt_sigprocmask resumed> NULL, 8) =3D 0
26278 <... rt_sigprocmask resumed> NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
26278 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0},  
26278 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
27813 <... rt_sigaction resumed> {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}=
, 8) =3D 0
26278 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 wait4(-1,  
26278 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
26278 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26278 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26278 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26278 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26278 execve("/usr/bin/flock", ["flock", "-x", "200"], ["SUBSYSTEM=3Dxen-=
backend", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D=
/usr/bin:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:=
/usr/sbin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dx=
en-backend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3D=
backend/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "S=
HLVL=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/flock"]) =3D 0=

26278 brk(0)                            =3D 0x119d000
26278 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f0519d76000
26278 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f0519d75000
26278 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26278 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26278 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26278 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7f0519d5b000=

26278 close(3)                          =3D 0
26278 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26278 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26278 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26278 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26278 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26278 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26278 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26278 close(3)                          =3D 0
26278 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f0519d5a000
26278 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f0519d59000
26278 arch_prctl(ARCH_SET_FS, 0x7f0519d596e0) =3D 0
26278 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26278 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26278 munmap(0x7f0519d5b000, 103979)    =3D 0
26278 flock(200, LOCK_EX)               =3D 0
26278 exit_group(0)                     =3D ?
27813 <... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], 0,=
 NULL) =3D 26278
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, 0x7fffb0100a24, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0xffffffffffffffff)  =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 pipe([3, 4])                      =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26279
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {0=
x436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26279 close(255 
27813 close(4 
26279 <... close resumed> )             =3D 0
27813 <... close resumed> )             =3D 0
27813 read(3,  
26279 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26279 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26279 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26279 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26279 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26279 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26279 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26279 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {S=
IG_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26279 rt_sigaction(SIGINT, {0x4481f0, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26279 dup2(4, 1)                        =3D 1
26279 close(4)                          =3D 0
26279 close(3)                          =3D 0
26279 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26279 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26279 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26279 write(2, "++ perl -e '\n            open STDIN, \"<&200\" or die $!=
;\n            my $fd_inum =3D (stat STDIN)[1]; die $! unless defined $fd=
_inum;\n            my $file_inum =3D (stat $ARGV[0])[1];\n            pr=
int \"y\\n\" if $fd_inum eq $file_inum;\n", 230) =3D 230
26279 write(2, "                             ' /var/run/xen-hotplug/block=
\n", 58) =3D 58
26279 stat(".", {st_dev=3Dmakedev(8, 2), st_ino=3D2, st_mode=3DS_IFDIR|07=
55, st_nlink=3D24, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
8, st_size=3D4096, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2012/10/08-=
11:13:38, st_ctime=3D2012/10/08-11:13:38}) =3D 0
26279 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26279 access("/usr/bin/perl", X_OK)     =3D 0
26279 access("/usr/bin/perl", R_OK)     =3D 0
26279 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26279 access("/usr/bin/perl", X_OK)     =3D 0
26279 access("/usr/bin/perl", R_OK)     =3D 0
26279 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
481f0, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26279 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26279 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26279 execve("/usr/bin/perl", ["perl", "-e", "\n            open STDIN, \=
"<&200\" or die $!;\n            my $fd_inum =3D (stat STDIN)[1]; die $! =
unless defined $fd_inum;\n            my $file_inum =3D (stat $ARGV[0])[1=
];\n            print \"y\\n\" if $fd_inum eq $file_inum;\n              =
               ", "/var/run/xen-hotplug/block"], ["SUBSYSTEM=3Dxen-backen=
d", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D/usr/b=
in:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:/usr/s=
bin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dxen-bac=
kend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3Dback=
end/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "SHLVL=
=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/perl"]) =3D 0
26279 brk(0)                            =3D 0x1d51000
26279 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f5d16cfe000
26279 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f5d16cfd000
26279 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26279 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64/libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26279 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64", 0x7fffeaa9f0e0) =3D -1 ENOENT (No such file or directory)
26279 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/lib=
perl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26279 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls", 0=
x7fffeaa9f0e0) =3D -1 ENOENT (No such file or directory)
26279 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64/=
libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26279 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64"=
, 0x7fffeaa9f0e0) =3D -1 ENOENT (No such file or directory)
26279 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl=
=2Eso", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26279 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE", 0x7ff=
feaa9f0e0) =3D -1 ENOENT (No such file or directory)
26279 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26279 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26279 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7f5d16ce3000=

26279 close(3)                          =3D 0
26279 open("/usr/lib64/libperl.so", O_RDONLY) =3D 3
26279 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\34\203%=
4\0\0\0@\0\0\0\0\0\0\0\360;\23\0\0\0\0\0\0\0\0\0@\0008\0\5\0@\0\35\0\34\0=
\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\200%4\0\0\0\0\0\200%4\0\0\0T\260\22\=
0\0\0\0\0T\260\22\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0X\260\22\0\0\0\=
0\0X\260\262%4\0\0\0X\260\262%4\0\0\0\250\201\0\0\0\0\0\0\350\242\0\0\0\0=
\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\265\22\0\0\0\0\0\370\265\262%4\0\=
0\0\370\265\262%4\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\=
0\0P\345td\4\0\0\0\250u\21\0\0\0\0\0\250u\221%4\0\0\0\250u\221%4\0\0\0D@\=
0\0\0\0\0\0D@\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\7\4\0\0\360\0\0\0\0\1\0\0\16\0\0\0\0\0\0@\0\200\203\200\225\1\22\=
264\3\31\200l\0\32\0 \5\201\0\240\3\2B\0\200\21R \0\22\0\0\16P\20#\10\216=
\334\30\211\"\0\10 \200\3B\220@\0\1\206\20\30\2\3\21\203$!\312A0\224Y\200=
\27\0\242\26\10\24R@\10\200\220\20A\10\0\220\1\200\206\2\10\304\30i\0\220=
\1\1\202\200\22\20\0\n\1H\0\n\2001J \6\31@L\207\20\10\0000\10(\200\2\0\4\=
251t\"\262\310!\212\240\320\"\0\t"..., 832) =3D 832
26279 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2839671, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D2480, st_size=3D1262384, st_atime=3D2012/10/09-12:04:35, st_mtime=3D=
2012/09/11-12:45:05, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26279 mmap(0x3425800000, 3363648, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425800000
26279 mprotect(0x342592c000, 2093056, PROT_NONE) =3D 0
26279 mmap(0x3425b2b000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x12b000) =3D 0x3425b2b000
26279 mmap(0x3425b34000, 4928, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3425b34000
26279 close(3)                          =3D 0
26279 open("/lib64/libresolv.so.2", O_RDONLY) =3D 3
26279 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\2402\0'4\0\=
0\0@\0\0\0\0\0\0\0@a\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\5\0=
\0\0@\0\0\0\0\0\0\0@\0\0'4\0\0\0@\0\0'4\0\0\0\370\1\0\0\0\0\0\0\370\1\0\0=
\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \361\0\0\0\0\0\0 \361\0'4\0\0\0=
 \361\0'4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\=
0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0'4\0\0\0\0\0\0'4\0\0\0$\10\1\0\0\0\0\0$\10=
\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\24\1\0\0\0\0\0\340\24!'4\=
0\0\0\340\24!'4\0\0\0\340\r\0\0\0\0\0\0\0106\0\0\0\0\0\0\0\0 \0\0\0\0\0\2=
\0\0\0\6\0\0\0\350\35\1\0\0\0\0\0\350\35!'4\0\0\0\350\35!'4\0\0\0\300\1\0=
\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\=
0\0\0008\2\0'4\0\0\0008\2\0'4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0=
\0\0\0\0P\345td\4\0\0\0<\361\0\0\0\0\0\0<\361\0'4\0\0\0<\361\0'4\0\0\0,\3=
\0\0\0\0\0\0,\3\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 8=
32
26279 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148119, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D192, st_size=3D92736, st_atime=3D2012/10/09-11:16:43, st_mtime=3D201=
0/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:42}) =3D 0
26279 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f5d16ce2000
26279 mmap(0x3427000000, 2181864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3427000000
26279 mprotect(0x3427011000, 2097152, PROT_NONE) =3D 0
26279 mmap(0x3427211000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x11000) =3D 0x3427211000
26279 mmap(0x3427213000, 6888, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3427213000
26279 close(3)                          =3D 0
26279 open("/lib64/libnsl.so.1", O_RDONLY) =3D 3
26279 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240@\340\35=
10\0\0\0@\0\0\0\0\0\0\0\360\265\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0=
\6\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\340\3510\0\0\0@\0\340\3510\0\0\0\370\1=
\0\0\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \33\1\0\0=
\0\0\0 \33\341\3510\0\0\0 \33\341\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\=
0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\340\3510\0\0\0=
\0\0\340\3510\0\0\0\310@\1\0\0\0\0\0\310@\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\=
0\0\6\0\0\0xM\1\0\0\0\0\0xM\1\3520\0\0\0xM\1\3520\0\0\0\310\5\0\0\0\0\0\0=
008-\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250M\1\0\0\0\0\0\250M\1\3=
520\0\0\0\250M\1\3520\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\340\3510\0\0\0008\2\340\351=
0\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0<\33\=
1\0\0\0\0\0<\33\341\3510\0\0\0<\33\341\3510\0\0\0\\\5\0\0\0\0\0\0\\\5\0\0=
\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26279 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147206, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D232, st_size=3D114352, st_atime=3D2012/10/09-12:01:01, st_mtime=3D20=
10/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:44}) =3D 0
26279 mmap(0x30e9e00000, 2194096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9e00000
26279 mprotect(0x30e9e15000, 2093056, PROT_NONE) =3D 0
26279 mmap(0x30ea014000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x14000) =3D 0x30ea014000
26279 mmap(0x30ea016000, 6832, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x30ea016000
26279 close(3)                          =3D 0
26279 open("/lib64/libdl.so.2", O_RDONLY) =3D 3
26279 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\16`\3500=
\0\0\0@\0\0\0\0\0\0\0@R\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0`\3500\0\0\0@\0`\3500\0\0\0\370\1\0\0\0\0\0\0\37=
0\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\300\32\0\0\0\0\0\0\300\3=
2`\3500\0\0\0\300\32`\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0`\3500\0\0\0\0\0`\3500\0\0\=
0\224\37\0\0\0\0\0\0\224\37\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0`-\=
0\0\0\0\0\0`-\200\3500\0\0\0`-\200\3500\0\0\0 \3\0\0\0\0\0\0\240\3\0\0\0\=
0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\240-\0\0\0\0\0\0\240-\200\3500\0\0\0=
\240-\200\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0=
\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2`\3500\0\0\0008\2`\3500\0\0\0 \0\0\=
0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\334\32\0\0\0\0\0\=
0\334\32`\3500\0\0\0\334\32`\3500\0\0\0\264\0\0\0\0\0\0\0\264\0\0\0\0\0\0=
\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26279 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147322, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D48, st_size=3D23360, st_atime=3D2012/10/09-11:13:54, st_mtime=3D2010=
/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26279 mmap(0x30e8600000, 2109696, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8600000
26279 mprotect(0x30e8602000, 2097152, PROT_NONE) =3D 0
26279 mmap(0x30e8802000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x2000) =3D 0x30e8802000
26279 close(3)                          =3D 0
26279 open("/lib64/libm.so.6", O_RDONLY) =3D 3
26279 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`>\240\3510\=
0\0\0@\0\0\0\0\0\0\0\240X\t\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0)\0(\0\6\0\0\=
0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3510\0\0\0@\0\240\3510\0\0\0\370\1\0\0\0\=
0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\360\303\7\0\0\0\=
0\0\360\303\247\3510\0\0\0\360\303\247\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0=
\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3510\=
0\0\0\0\0\240\3510\0\0\0000\22\10\0\0\0\0\0000\22\10\0\0\0\0\0\0\0 \0\0\0=
\0\0\1\0\0\0\6\0\0\0\270\35\10\0\0\0\0\0\270\35\310\3510\0\0\0\270\35\310=
\3510\0\0\0\320\2\0\0\0\0\0\0 \3\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0=
\0\350\35\10\0\0\0\0\0\350\35\310\3510\0\0\0\350\35\310\3510\0\0\0\300\1\=
0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0=
\0\0\0008\2\240\3510\0\0\0008\2\240\3510\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\f\304\7\0\0\0\0\0\f\304\247\3510\0\0\0=
\f\304\247\3510\0\0\0\374\r\0\0\0\0\0\0\374\r\0\0\0\0\0\0\4\0\0\0\0\0\0\0=
Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0"..., 832) =3D 832
26279 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147337, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D1216, st_size=3D615136, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2=
010/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26279 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f5d16ce1000
26279 mmap(0x30e9a00000, 2629848, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9a00000
26279 mprotect(0x30e9a82000, 2093056, PROT_NONE) =3D 0
26279 mmap(0x30e9c81000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x81000) =3D 0x30e9c81000
26279 close(3)                          =3D 0
26279 open("/lib64/libcrypt.so.1", O_RDONLY) =3D 3
26279 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\t\300%4=
\0\0\0@\0\0\0\0\0\0\0\30\265\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\=
0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\300%4\0\0\0@\0\300%4\0\0\0\370\1\0\0\0\0\=
0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340}\0\0\0\0\0\0\3=
40}\300%4\0\0\0\340}\300%4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\300%4\0\0\0\0\0\300%4\0\0\=
0\4\205\0\0\0\0\0\0\4\205\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\310\=
215\0\0\0\0\0\0\310\215\340%4\0\0\0\310\215\340%4\0\0\0\250\2\0\0\0\0\0\0=
\370\343\2\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\215\0\0\0\0\0\0\3=
70\215\340%4\0\0\0\370\215\340%4\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\=
0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\300%4\0\0\0008\2=
\300%4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0=
\374}\0\0\0\0\0\0\374}\300%4\0\0\0\374}\300%4\0\0\0\34\1\0\0\0\0\0\0\34\1=
\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26279 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148123, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D96, st_size=3D48600, st_atime=3D2012/10/09-12:01:01, st_mtime=3D2010=
/07/28-03:52:39, st_ctime=3D2012/09/11-14:53:52}) =3D 0
26279 mmap(0x3425c00000, 2322880, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425c00000
26279 mprotect(0x3425c09000, 2093056, PROT_NONE) =3D 0
26279 mmap(0x3425e08000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x8000) =3D 0x3425e08000
26279 mmap(0x3425e0a000, 184768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FI=
XED|MAP_ANONYMOUS, -1, 0) =3D 0x3425e0a000
26279 close(3)                          =3D 0
26279 open("/lib64/libutil.so.1", O_RDONLY) =3D 3
26279 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\16\0(4\=
0\0\0@\0\0\0\0\0\0\0(>\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0\0(4\0\0\0@\0\0(4\0\0\0\370\1\0\0\0\0\0\0\370\1\=
0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340\26\0\0\0\0\0\0\340\26\0(=
4\0\0\0\340\26\0(4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0=
\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0(4\0\0\0\0\0\0(4\0\0\0P\32\0\0\0\=
0\0\0P\32\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\35\0\0\0\0\0\0\3=
40\35 (4\0\0\0\340\35 (4\0\0\0 \3\0\0\0\0\0\0000\3\0\0\0\0\0\0\0\0 \0\0\0=
\0\0\2\0\0\0\6\0\0\0\20\36\0\0\0\0\0\0\20\36 (4\0\0\0\20\36 (4\0\0\0\300\=
1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0=
\0\0\0\0008\2\0(4\0\0\0008\2\0(4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\=
0\0\0\0\0\0P\345td\4\0\0\0\374\26\0\0\0\0\0\0\374\26\0(4\0\0\0\374\26\0(4=
\0\0\0D\0\0\0\0\0\0\0D\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8=
32) =3D 832
26279 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147063, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D40, st_size=3D18152, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2010=
/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:49}) =3D 0
26279 mmap(0x3428000000, 2105616, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3428000000
26279 mprotect(0x3428002000, 2093056, PROT_NONE) =3D 0
26279 mmap(0x3428201000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x1000) =3D 0x3428201000
26279 close(3)                          =3D 0
26279 open("/lib64/libpthread.so.0", O_RDONLY) =3D 3
26279 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240W\240\35=
00\0\0\0@\0\0\0\0\0\0\0\340/\2\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0'\0&\0\6\0=
\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3500\0\0\0@\0\240\3500\0\0\0\370\1\0\0=
\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\240\t\1\0\0\0=
\0\0\240\t\241\3500\0\0\0\240\t\241\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\=
0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3500\0\0=
\0\0\0\240\3500\0\0\0pZ\1\0\0\0\0\0pZ\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\=
6\0\0\0\270[\1\0\0\0\0\0\270[\301\3500\0\0\0\270[\301\3500\0\0\0\230\6\0\=
0\0\0\0\0\270G\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250]\1\0\0\0\0\=
0\250]\301\3500\0\0\0\250]\301\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0=
\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\240\3500\0\0\=
0008\2\240\3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345t=
d\4\0\0\0\274\t\1\0\0\0\0\0\274\t\241\3500\0\0\0\274\t\241\3500\0\0\0\344=
\t\0\0\0\0\0\0\344\t\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =
=3D 832
26279 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147328, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D296, st_size=3D145824, st_atime=3D2012/10/09-11:16:43, st_mtime=3D20=
10/07/28-03:52:41, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26279 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f5d16ce0000
26279 mmap(0x30e8a00000, 2204528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8a00000
26279 mprotect(0x30e8a16000, 2093056, PROT_NONE) =3D 0
26279 mmap(0x30e8c15000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x15000) =3D 0x30e8c15000
26279 mmap(0x30e8c17000, 13168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8c17000
26279 close(3)                          =3D 0
26279 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26279 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26279 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26279 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26279 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26279 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26279 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26279 close(3)                          =3D 0
26279 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f5d16cdf000
26279 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f5d16cde000
26279 arch_prctl(ARCH_SET_FS, 0x7f5d16cde6e0) =3D 0
26279 mprotect(0x3427211000, 4096, PROT_READ) =3D 0
26279 mprotect(0x30ea014000, 4096, PROT_READ) =3D 0
26279 mprotect(0x30e8802000, 4096, PROT_READ) =3D 0
26279 mprotect(0x30e9c81000, 4096, PROT_READ) =3D 0
26279 mprotect(0x3425e08000, 4096, PROT_READ) =3D 0
26279 mprotect(0x3428201000, 4096, PROT_READ) =3D 0
26279 mprotect(0x30e8c15000, 4096, PROT_READ) =3D 0
26279 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26279 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26279 munmap(0x7f5d16ce3000, 103979)    =3D 0
26279 set_tid_address(0x7f5d16cde770)   =3D 26279
26279 set_robust_list(0x7f5d16cde780, 0x18) =3D 0
26279 futex(0x7fffeaa9fc0c, FUTEX_WAKE_PRIVATE, 1) =3D 0
26279 rt_sigaction(SIGRTMIN, {0x30e8a05380, [], SA_RESTORER|SA_SIGINFO, 0=
x30e8a0eb10}, NULL, 8) =3D 0
26279 rt_sigaction(SIGRT_1, {0x30e8a052b0, [], SA_RESTORER|SA_RESTART|SA_=
SIGINFO, 0x30e8a0eb10}, NULL, 8) =3D 0
26279 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) =3D 0
26279 getrlimit(RLIMIT_STACK, {rlim_cur=3D8192*1024, rlim_max=3DRLIM_INFI=
NITY}) =3D 0
26279 rt_sigaction(SIGFPE, {0x1, [FPE], SA_RESTORER|SA_RESTART, 0x30e8230=
2d0}, {SIG_DFL, [], 0}, 8) =3D 0
26279 brk(0)                            =3D 0x1d51000
26279 brk(0x1d73000)                    =3D 0x1d73000
26279 getuid()                          =3D 0
26279 geteuid()                         =3D 0
26279 getgid()                          =3D 0
26279 getegid()                         =3D 0
26279 mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,=
 -1, 0) =3D 0x7f5d16cbd000
26279 open("/dev/urandom", O_RDONLY)    =3D 3
26279 read(3, "<\377\35_", 4)           =3D 4
26279 close(3)                          =3D 0
26279 stat("/usr/lib64/perl5/site_perl/5.8.7/x86_64-linux-thread-multi", =
0x7fffeaa9f8c0) =3D -1 ENOENT (No such file or directory)
26279 stat("/usr/lib/perl5/site_perl/5.8.7", 0x7fffeaa9f8c0) =3D -1 ENOEN=
T (No such file or directory)
26279 stat("/usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi", =
0x7fffeaa9f8c0) =3D -1 ENOENT (No such file or directory)
26279 stat("/usr/lib/perl5/site_perl/5.8.6", 0x7fffeaa9f8c0) =3D -1 ENOEN=
T (No such file or directory)
26279 stat("/usr/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi", =
0x7fffeaa9f8c0) =3D -1 ENOENT (No such file or directory)
26279 stat("/usr/lib/perl5/site_perl/5.8.5", 0x7fffeaa9f8c0) =3D -1 ENOEN=
T (No such file or directory)
26279 stat("/usr/lib64/perl5/vendor_perl/5.8.7/x86_64-linux-thread-multi"=
, 0x7fffeaa9f8c0) =3D -1 ENOENT (No such file or directory)
26279 stat("/usr/lib/perl5/vendor_perl/5.8.7", 0x7fffeaa9f8c0) =3D -1 ENO=
ENT (No such file or directory)
26279 stat("/usr/lib64/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi"=
, 0x7fffeaa9f8c0) =3D -1 ENOENT (No such file or directory)
26279 stat("/usr/lib/perl5/vendor_perl/5.8.6", 0x7fffeaa9f8c0) =3D -1 ENO=
ENT (No such file or directory)
26279 stat("/usr/lib64/perl5/vendor_perl/5.8.5/x86_64-linux-thread-multi"=
, 0x7fffeaa9f8c0) =3D -1 ENOENT (No such file or directory)
26279 stat("/usr/lib/perl5/vendor_perl/5.8.5", 0x7fffeaa9f8c0) =3D -1 ENO=
ENT (No such file or directory)
26279 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffeaa9f680) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26279 lseek(0, 0, SEEK_CUR)             =3D 0
26279 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffeaa9f680) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26279 lseek(1, 0, SEEK_CUR)             =3D -1 ESPIPE (Illegal seek)
26279 ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffeaa9f690) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26279 lseek(2, 0, SEEK_CUR)             =3D 593657921
26279 open("/dev/null", O_RDONLY)       =3D 3
26279 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffeaa9f790) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26279 lseek(3, 0, SEEK_CUR)             =3D 0
26279 fcntl(3, F_SETFD, FD_CLOEXEC)     =3D 0
26279 fstat(3, {st_dev=3Dmakedev(0, 16), st_ino=3D584, st_mode=3DS_IFCHR|=
0666, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
0, st_rdev=3Dmakedev(1, 3), st_atime=3D2012/10/08-11:13:26, st_mtime=3D20=
12/10/08-11:13:26, st_ctime=3D2012/10/08-11:13:27}) =3D 0
26279 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) =3D 0
26279 readlink("/proc/self/exe", "/usr/bin/perl"..., 4095) =3D 13
26279 brk(0x1d94000)                    =3D 0x1d94000
26279 close(3)                          =3D 0
26279 dup(200)                          =3D 3
26279 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffeaa9f660) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26279 lseek(3, 0, SEEK_CUR)             =3D 0
26279 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26279 dup2(3, 0)                        =3D 0
26279 close(3)                          =3D 0
26279 fcntl(0, F_SETFD, 0)              =3D 0
26279 fstat(0, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26279 stat("/var/run/xen-hotplug/block", {st_dev=3Dmakedev(8, 2), st_ino=3D=
2801738, st_mode=3DS_IFREG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st=
_blksize=3D4096, st_blocks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:=
24, st_mtime=3D2012/10/09-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D =
0
26279 exit_group(0)                     =3D ?
27813 <... read resumed> "", 128)       =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], WNOHANG, NUL=
L) =3D 26279
27813 wait4(-1, 0x7fffb0100a64, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0)                   =3D 0
27813 close(3)                          =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 write(2, "+ rightfile=3D\n", 13)    =3D 13
27813 write(2, "+ '[' x =3D xy ']'\n", 17) =3D 17
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ true\n", 7)           =3D 7
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ eval 'exec 200>>/var/run/xen-hotplug/block'\n", 46) =3D=
 46
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 write(2, "++ exec\n", 8)          =3D 8
27813 open("/var/run/xen-hotplug/block", O_WRONLY|O_CREAT|O_APPEND, 0666)=
 =3D 3
27813 fcntl(200, F_GETFD)               =3D 0
27813 fcntl(200, F_DUPFD, 10)           =3D 10
27813 fcntl(200, F_GETFD)               =3D 0
27813 dup2(3, 200)                      =3D 200
27813 close(3)                          =3D 0
27813 dup2(10, 200)                     =3D 200
27813 fcntl(10, F_GETFD)                =3D 0
27813 close(10)                         =3D 0
27813 write(2, "+ flock -x 200\n", 15)  =3D 15
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [INT CHLD], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [INT CHLD], NULL, 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26280
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26280 close(255 
27813 rt_sigprocmask(SIG_BLOCK, [CHLD],  
26280 <... close resumed> )             =3D 0
27813 <... rt_sigprocmask resumed> [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [],  
26280 rt_sigprocmask(SIG_SETMASK, [],  
27813 <... rt_sigprocmask resumed> NULL, 8) =3D 0
26280 <... rt_sigprocmask resumed> NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
26280 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0},  
26280 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
27813 <... rt_sigaction resumed> {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}=
, 8) =3D 0
26280 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 wait4(-1,  
26280 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
26280 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26280 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26280 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26280 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26280 execve("/usr/bin/flock", ["flock", "-x", "200"], ["SUBSYSTEM=3Dxen-=
backend", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D=
/usr/bin:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:=
/usr/sbin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dx=
en-backend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3D=
backend/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "S=
HLVL=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/flock"]) =3D 0=

26280 brk(0)                            =3D 0x1b9e000
26280 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f73852d4000
26280 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f73852d3000
26280 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26280 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26280 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26280 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7f73852b9000=

26280 close(3)                          =3D 0
26280 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26280 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26280 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26280 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26280 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26280 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26280 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26280 close(3)                          =3D 0
26280 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f73852b8000
26280 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f73852b7000
26280 arch_prctl(ARCH_SET_FS, 0x7f73852b76e0) =3D 0
26280 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26280 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26280 munmap(0x7f73852b9000, 103979)    =3D 0
26280 flock(200, LOCK_EX)               =3D 0
26280 exit_group(0)                     =3D ?
27813 <... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], 0,=
 NULL) =3D 26280
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, 0x7fffb0100a24, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0xffffffffffffffff)  =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 pipe([3, 4])                      =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26281
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {0=
x436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26281 close(255 
27813 close(4 
26281 <... close resumed> )             =3D 0
27813 <... close resumed> )             =3D 0
27813 read(3,  
26281 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26281 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26281 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26281 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26281 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26281 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26281 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26281 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {S=
IG_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26281 rt_sigaction(SIGINT, {0x4481f0, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26281 dup2(4, 1)                        =3D 1
26281 close(4)                          =3D 0
26281 close(3)                          =3D 0
26281 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26281 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26281 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26281 write(2, "++ perl -e '\n            open STDIN, \"<&200\" or die $!=
;\n            my $fd_inum =3D (stat STDIN)[1]; die $! unless defined $fd=
_inum;\n            my $file_inum =3D (stat $ARGV[0])[1];\n            pr=
int \"y\\n\" if $fd_inum eq $file_inum;\n", 230) =3D 230
26281 write(2, "                             ' /var/run/xen-hotplug/block=
\n", 58) =3D 58
26281 stat(".", {st_dev=3Dmakedev(8, 2), st_ino=3D2, st_mode=3DS_IFDIR|07=
55, st_nlink=3D24, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
8, st_size=3D4096, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2012/10/08-=
11:13:38, st_ctime=3D2012/10/08-11:13:38}) =3D 0
26281 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26281 access("/usr/bin/perl", X_OK)     =3D 0
26281 access("/usr/bin/perl", R_OK)     =3D 0
26281 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26281 access("/usr/bin/perl", X_OK)     =3D 0
26281 access("/usr/bin/perl", R_OK)     =3D 0
26281 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
481f0, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26281 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26281 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26281 execve("/usr/bin/perl", ["perl", "-e", "\n            open STDIN, \=
"<&200\" or die $!;\n            my $fd_inum =3D (stat STDIN)[1]; die $! =
unless defined $fd_inum;\n            my $file_inum =3D (stat $ARGV[0])[1=
];\n            print \"y\\n\" if $fd_inum eq $file_inum;\n              =
               ", "/var/run/xen-hotplug/block"], ["SUBSYSTEM=3Dxen-backen=
d", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D/usr/b=
in:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:/usr/s=
bin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dxen-bac=
kend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3Dback=
end/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "SHLVL=
=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/perl"]) =3D 0
26281 brk(0)                            =3D 0x2557000
26281 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f7035a3e000
26281 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f7035a3d000
26281 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26281 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64/libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26281 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64", 0x7fffb80966e0) =3D -1 ENOENT (No such file or directory)
26281 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/lib=
perl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26281 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls", 0=
x7fffb80966e0) =3D -1 ENOENT (No such file or directory)
26281 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64/=
libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26281 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64"=
, 0x7fffb80966e0) =3D -1 ENOENT (No such file or directory)
26281 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl=
=2Eso", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26281 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE", 0x7ff=
fb80966e0) =3D -1 ENOENT (No such file or directory)
26281 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26281 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26281 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7f7035a23000=

26281 close(3)                          =3D 0
26281 open("/usr/lib64/libperl.so", O_RDONLY) =3D 3
26281 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\34\203%=
4\0\0\0@\0\0\0\0\0\0\0\360;\23\0\0\0\0\0\0\0\0\0@\0008\0\5\0@\0\35\0\34\0=
\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\200%4\0\0\0\0\0\200%4\0\0\0T\260\22\=
0\0\0\0\0T\260\22\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0X\260\22\0\0\0\=
0\0X\260\262%4\0\0\0X\260\262%4\0\0\0\250\201\0\0\0\0\0\0\350\242\0\0\0\0=
\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\265\22\0\0\0\0\0\370\265\262%4\0\=
0\0\370\265\262%4\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\=
0\0P\345td\4\0\0\0\250u\21\0\0\0\0\0\250u\221%4\0\0\0\250u\221%4\0\0\0D@\=
0\0\0\0\0\0D@\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\7\4\0\0\360\0\0\0\0\1\0\0\16\0\0\0\0\0\0@\0\200\203\200\225\1\22\=
264\3\31\200l\0\32\0 \5\201\0\240\3\2B\0\200\21R \0\22\0\0\16P\20#\10\216=
\334\30\211\"\0\10 \200\3B\220@\0\1\206\20\30\2\3\21\203$!\312A0\224Y\200=
\27\0\242\26\10\24R@\10\200\220\20A\10\0\220\1\200\206\2\10\304\30i\0\220=
\1\1\202\200\22\20\0\n\1H\0\n\2001J \6\31@L\207\20\10\0000\10(\200\2\0\4\=
251t\"\262\310!\212\240\320\"\0\t"..., 832) =3D 832
26281 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2839671, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D2480, st_size=3D1262384, st_atime=3D2012/10/09-12:04:35, st_mtime=3D=
2012/09/11-12:45:05, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26281 mmap(0x3425800000, 3363648, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425800000
26281 mprotect(0x342592c000, 2093056, PROT_NONE) =3D 0
26281 mmap(0x3425b2b000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x12b000) =3D 0x3425b2b000
26281 mmap(0x3425b34000, 4928, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3425b34000
26281 close(3)                          =3D 0
26281 open("/lib64/libresolv.so.2", O_RDONLY) =3D 3
26281 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\2402\0'4\0\=
0\0@\0\0\0\0\0\0\0@a\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\5\0=
\0\0@\0\0\0\0\0\0\0@\0\0'4\0\0\0@\0\0'4\0\0\0\370\1\0\0\0\0\0\0\370\1\0\0=
\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \361\0\0\0\0\0\0 \361\0'4\0\0\0=
 \361\0'4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\=
0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0'4\0\0\0\0\0\0'4\0\0\0$\10\1\0\0\0\0\0$\10=
\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\24\1\0\0\0\0\0\340\24!'4\=
0\0\0\340\24!'4\0\0\0\340\r\0\0\0\0\0\0\0106\0\0\0\0\0\0\0\0 \0\0\0\0\0\2=
\0\0\0\6\0\0\0\350\35\1\0\0\0\0\0\350\35!'4\0\0\0\350\35!'4\0\0\0\300\1\0=
\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\=
0\0\0008\2\0'4\0\0\0008\2\0'4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0=
\0\0\0\0P\345td\4\0\0\0<\361\0\0\0\0\0\0<\361\0'4\0\0\0<\361\0'4\0\0\0,\3=
\0\0\0\0\0\0,\3\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 8=
32
26281 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148119, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D192, st_size=3D92736, st_atime=3D2012/10/09-11:16:43, st_mtime=3D201=
0/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:42}) =3D 0
26281 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f7035a22000
26281 mmap(0x3427000000, 2181864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3427000000
26281 mprotect(0x3427011000, 2097152, PROT_NONE) =3D 0
26281 mmap(0x3427211000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x11000) =3D 0x3427211000
26281 mmap(0x3427213000, 6888, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3427213000
26281 close(3)                          =3D 0
26281 open("/lib64/libnsl.so.1", O_RDONLY) =3D 3
26281 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240@\340\35=
10\0\0\0@\0\0\0\0\0\0\0\360\265\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0=
\6\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\340\3510\0\0\0@\0\340\3510\0\0\0\370\1=
\0\0\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \33\1\0\0=
\0\0\0 \33\341\3510\0\0\0 \33\341\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\=
0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\340\3510\0\0\0=
\0\0\340\3510\0\0\0\310@\1\0\0\0\0\0\310@\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\=
0\0\6\0\0\0xM\1\0\0\0\0\0xM\1\3520\0\0\0xM\1\3520\0\0\0\310\5\0\0\0\0\0\0=
008-\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250M\1\0\0\0\0\0\250M\1\3=
520\0\0\0\250M\1\3520\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\340\3510\0\0\0008\2\340\351=
0\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0<\33\=
1\0\0\0\0\0<\33\341\3510\0\0\0<\33\341\3510\0\0\0\\\5\0\0\0\0\0\0\\\5\0\0=
\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26281 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147206, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D232, st_size=3D114352, st_atime=3D2012/10/09-12:01:01, st_mtime=3D20=
10/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:44}) =3D 0
26281 mmap(0x30e9e00000, 2194096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9e00000
26281 mprotect(0x30e9e15000, 2093056, PROT_NONE) =3D 0
26281 mmap(0x30ea014000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x14000) =3D 0x30ea014000
26281 mmap(0x30ea016000, 6832, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x30ea016000
26281 close(3)                          =3D 0
26281 open("/lib64/libdl.so.2", O_RDONLY) =3D 3
26281 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\16`\3500=
\0\0\0@\0\0\0\0\0\0\0@R\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0`\3500\0\0\0@\0`\3500\0\0\0\370\1\0\0\0\0\0\0\37=
0\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\300\32\0\0\0\0\0\0\300\3=
2`\3500\0\0\0\300\32`\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0`\3500\0\0\0\0\0`\3500\0\0\=
0\224\37\0\0\0\0\0\0\224\37\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0`-\=
0\0\0\0\0\0`-\200\3500\0\0\0`-\200\3500\0\0\0 \3\0\0\0\0\0\0\240\3\0\0\0\=
0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\240-\0\0\0\0\0\0\240-\200\3500\0\0\0=
\240-\200\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0=
\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2`\3500\0\0\0008\2`\3500\0\0\0 \0\0\=
0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\334\32\0\0\0\0\0\=
0\334\32`\3500\0\0\0\334\32`\3500\0\0\0\264\0\0\0\0\0\0\0\264\0\0\0\0\0\0=
\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26281 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147322, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D48, st_size=3D23360, st_atime=3D2012/10/09-11:13:54, st_mtime=3D2010=
/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26281 mmap(0x30e8600000, 2109696, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8600000
26281 mprotect(0x30e8602000, 2097152, PROT_NONE) =3D 0
26281 mmap(0x30e8802000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x2000) =3D 0x30e8802000
26281 close(3)                          =3D 0
26281 open("/lib64/libm.so.6", O_RDONLY) =3D 3
26281 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`>\240\3510\=
0\0\0@\0\0\0\0\0\0\0\240X\t\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0)\0(\0\6\0\0\=
0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3510\0\0\0@\0\240\3510\0\0\0\370\1\0\0\0\=
0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\360\303\7\0\0\0\=
0\0\360\303\247\3510\0\0\0\360\303\247\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0=
\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3510\=
0\0\0\0\0\240\3510\0\0\0000\22\10\0\0\0\0\0000\22\10\0\0\0\0\0\0\0 \0\0\0=
\0\0\1\0\0\0\6\0\0\0\270\35\10\0\0\0\0\0\270\35\310\3510\0\0\0\270\35\310=
\3510\0\0\0\320\2\0\0\0\0\0\0 \3\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0=
\0\350\35\10\0\0\0\0\0\350\35\310\3510\0\0\0\350\35\310\3510\0\0\0\300\1\=
0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0=
\0\0\0008\2\240\3510\0\0\0008\2\240\3510\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\f\304\7\0\0\0\0\0\f\304\247\3510\0\0\0=
\f\304\247\3510\0\0\0\374\r\0\0\0\0\0\0\374\r\0\0\0\0\0\0\4\0\0\0\0\0\0\0=
Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0"..., 832) =3D 832
26281 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147337, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D1216, st_size=3D615136, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2=
010/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26281 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f7035a21000
26281 mmap(0x30e9a00000, 2629848, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9a00000
26281 mprotect(0x30e9a82000, 2093056, PROT_NONE) =3D 0
26281 mmap(0x30e9c81000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x81000) =3D 0x30e9c81000
26281 close(3)                          =3D 0
26281 open("/lib64/libcrypt.so.1", O_RDONLY) =3D 3
26281 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\t\300%4=
\0\0\0@\0\0\0\0\0\0\0\30\265\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\=
0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\300%4\0\0\0@\0\300%4\0\0\0\370\1\0\0\0\0\=
0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340}\0\0\0\0\0\0\3=
40}\300%4\0\0\0\340}\300%4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\300%4\0\0\0\0\0\300%4\0\0\=
0\4\205\0\0\0\0\0\0\4\205\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\310\=
215\0\0\0\0\0\0\310\215\340%4\0\0\0\310\215\340%4\0\0\0\250\2\0\0\0\0\0\0=
\370\343\2\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\215\0\0\0\0\0\0\3=
70\215\340%4\0\0\0\370\215\340%4\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\=
0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\300%4\0\0\0008\2=
\300%4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0=
\374}\0\0\0\0\0\0\374}\300%4\0\0\0\374}\300%4\0\0\0\34\1\0\0\0\0\0\0\34\1=
\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26281 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148123, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D96, st_size=3D48600, st_atime=3D2012/10/09-12:01:01, st_mtime=3D2010=
/07/28-03:52:39, st_ctime=3D2012/09/11-14:53:52}) =3D 0
26281 mmap(0x3425c00000, 2322880, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425c00000
26281 mprotect(0x3425c09000, 2093056, PROT_NONE) =3D 0
26281 mmap(0x3425e08000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x8000) =3D 0x3425e08000
26281 mmap(0x3425e0a000, 184768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FI=
XED|MAP_ANONYMOUS, -1, 0) =3D 0x3425e0a000
26281 close(3)                          =3D 0
26281 open("/lib64/libutil.so.1", O_RDONLY) =3D 3
26281 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\16\0(4\=
0\0\0@\0\0\0\0\0\0\0(>\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0\0(4\0\0\0@\0\0(4\0\0\0\370\1\0\0\0\0\0\0\370\1\=
0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340\26\0\0\0\0\0\0\340\26\0(=
4\0\0\0\340\26\0(4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0=
\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0(4\0\0\0\0\0\0(4\0\0\0P\32\0\0\0\=
0\0\0P\32\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\35\0\0\0\0\0\0\3=
40\35 (4\0\0\0\340\35 (4\0\0\0 \3\0\0\0\0\0\0000\3\0\0\0\0\0\0\0\0 \0\0\0=
\0\0\2\0\0\0\6\0\0\0\20\36\0\0\0\0\0\0\20\36 (4\0\0\0\20\36 (4\0\0\0\300\=
1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0=
\0\0\0\0008\2\0(4\0\0\0008\2\0(4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\=
0\0\0\0\0\0P\345td\4\0\0\0\374\26\0\0\0\0\0\0\374\26\0(4\0\0\0\374\26\0(4=
\0\0\0D\0\0\0\0\0\0\0D\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8=
32) =3D 832
26281 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147063, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D40, st_size=3D18152, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2010=
/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:49}) =3D 0
26281 mmap(0x3428000000, 2105616, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3428000000
26281 mprotect(0x3428002000, 2093056, PROT_NONE) =3D 0
26281 mmap(0x3428201000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x1000) =3D 0x3428201000
26281 close(3)                          =3D 0
26281 open("/lib64/libpthread.so.0", O_RDONLY) =3D 3
26281 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240W\240\35=
00\0\0\0@\0\0\0\0\0\0\0\340/\2\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0'\0&\0\6\0=
\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3500\0\0\0@\0\240\3500\0\0\0\370\1\0\0=
\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\240\t\1\0\0\0=
\0\0\240\t\241\3500\0\0\0\240\t\241\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\=
0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3500\0\0=
\0\0\0\240\3500\0\0\0pZ\1\0\0\0\0\0pZ\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\=
6\0\0\0\270[\1\0\0\0\0\0\270[\301\3500\0\0\0\270[\301\3500\0\0\0\230\6\0\=
0\0\0\0\0\270G\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250]\1\0\0\0\0\=
0\250]\301\3500\0\0\0\250]\301\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0=
\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\240\3500\0\0\=
0008\2\240\3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345t=
d\4\0\0\0\274\t\1\0\0\0\0\0\274\t\241\3500\0\0\0\274\t\241\3500\0\0\0\344=
\t\0\0\0\0\0\0\344\t\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =
=3D 832
26281 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147328, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D296, st_size=3D145824, st_atime=3D2012/10/09-11:16:43, st_mtime=3D20=
10/07/28-03:52:41, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26281 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f7035a20000
26281 mmap(0x30e8a00000, 2204528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8a00000
26281 mprotect(0x30e8a16000, 2093056, PROT_NONE) =3D 0
26281 mmap(0x30e8c15000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x15000) =3D 0x30e8c15000
26281 mmap(0x30e8c17000, 13168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8c17000
26281 close(3)                          =3D 0
26281 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26281 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26281 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26281 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26281 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26281 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26281 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26281 close(3)                          =3D 0
26281 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f7035a1f000
26281 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f7035a1e000
26281 arch_prctl(ARCH_SET_FS, 0x7f7035a1e6e0) =3D 0
26281 mprotect(0x3427211000, 4096, PROT_READ) =3D 0
26281 mprotect(0x30ea014000, 4096, PROT_READ) =3D 0
26281 mprotect(0x30e8802000, 4096, PROT_READ) =3D 0
26281 mprotect(0x30e9c81000, 4096, PROT_READ) =3D 0
26281 mprotect(0x3425e08000, 4096, PROT_READ) =3D 0
26281 mprotect(0x3428201000, 4096, PROT_READ) =3D 0
26281 mprotect(0x30e8c15000, 4096, PROT_READ) =3D 0
26281 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26281 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26281 munmap(0x7f7035a23000, 103979)    =3D 0
26281 set_tid_address(0x7f7035a1e770)   =3D 26281
26281 set_robust_list(0x7f7035a1e780, 0x18) =3D 0
26281 futex(0x7fffb809720c, FUTEX_WAKE_PRIVATE, 1) =3D 0
26281 rt_sigaction(SIGRTMIN, {0x30e8a05380, [], SA_RESTORER|SA_SIGINFO, 0=
x30e8a0eb10}, NULL, 8) =3D 0
26281 rt_sigaction(SIGRT_1, {0x30e8a052b0, [], SA_RESTORER|SA_RESTART|SA_=
SIGINFO, 0x30e8a0eb10}, NULL, 8) =3D 0
26281 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) =3D 0
26281 getrlimit(RLIMIT_STACK, {rlim_cur=3D8192*1024, rlim_max=3DRLIM_INFI=
NITY}) =3D 0
26281 rt_sigaction(SIGFPE, {0x1, [FPE], SA_RESTORER|SA_RESTART, 0x30e8230=
2d0}, {SIG_DFL, [], 0}, 8) =3D 0
26281 brk(0)                            =3D 0x2557000
26281 brk(0x2579000)                    =3D 0x2579000
26281 getuid()                          =3D 0
26281 geteuid()                         =3D 0
26281 getgid()                          =3D 0
26281 getegid()                         =3D 0
26281 mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,=
 -1, 0) =3D 0x7f70359fd000
26281 open("/dev/urandom", O_RDONLY)    =3D 3
26281 read(3, "\226:\377$", 4)          =3D 4
26281 close(3)                          =3D 0
26281 stat("/usr/lib64/perl5/site_perl/5.8.7/x86_64-linux-thread-multi", =
0x7fffb8096ec0) =3D -1 ENOENT (No such file or directory)
26281 stat("/usr/lib/perl5/site_perl/5.8.7", 0x7fffb8096ec0) =3D -1 ENOEN=
T (No such file or directory)
26281 stat("/usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi", =
0x7fffb8096ec0) =3D -1 ENOENT (No such file or directory)
26281 stat("/usr/lib/perl5/site_perl/5.8.6", 0x7fffb8096ec0) =3D -1 ENOEN=
T (No such file or directory)
26281 stat("/usr/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi", =
0x7fffb8096ec0) =3D -1 ENOENT (No such file or directory)
26281 stat("/usr/lib/perl5/site_perl/5.8.5", 0x7fffb8096ec0) =3D -1 ENOEN=
T (No such file or directory)
26281 stat("/usr/lib64/perl5/vendor_perl/5.8.7/x86_64-linux-thread-multi"=
, 0x7fffb8096ec0) =3D -1 ENOENT (No such file or directory)
26281 stat("/usr/lib/perl5/vendor_perl/5.8.7", 0x7fffb8096ec0) =3D -1 ENO=
ENT (No such file or directory)
26281 stat("/usr/lib64/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi"=
, 0x7fffb8096ec0) =3D -1 ENOENT (No such file or directory)
26281 stat("/usr/lib/perl5/vendor_perl/5.8.6", 0x7fffb8096ec0) =3D -1 ENO=
ENT (No such file or directory)
26281 stat("/usr/lib64/perl5/vendor_perl/5.8.5/x86_64-linux-thread-multi"=
, 0x7fffb8096ec0) =3D -1 ENOENT (No such file or directory)
26281 stat("/usr/lib/perl5/vendor_perl/5.8.5", 0x7fffb8096ec0) =3D -1 ENO=
ENT (No such file or directory)
26281 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffb8096c80) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26281 lseek(0, 0, SEEK_CUR)             =3D 0
26281 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffb8096c80) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26281 lseek(1, 0, SEEK_CUR)             =3D -1 ESPIPE (Illegal seek)
26281 ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffb8096c90) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26281 lseek(2, 0, SEEK_CUR)             =3D 593658315
26281 open("/dev/null", O_RDONLY)       =3D 3
26281 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffb8096d90) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26281 lseek(3, 0, SEEK_CUR)             =3D 0
26281 fcntl(3, F_SETFD, FD_CLOEXEC)     =3D 0
26281 fstat(3, {st_dev=3Dmakedev(0, 16), st_ino=3D584, st_mode=3DS_IFCHR|=
0666, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
0, st_rdev=3Dmakedev(1, 3), st_atime=3D2012/10/08-11:13:26, st_mtime=3D20=
12/10/08-11:13:26, st_ctime=3D2012/10/08-11:13:27}) =3D 0
26281 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) =3D 0
26281 readlink("/proc/self/exe", "/usr/bin/perl"..., 4095) =3D 13
26281 brk(0x259a000)                    =3D 0x259a000
26281 close(3)                          =3D 0
26281 dup(200)                          =3D 3
26281 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffb8096c60) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26281 lseek(3, 0, SEEK_CUR)             =3D 0
26281 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26281 dup2(3, 0)                        =3D 0
26281 close(3)                          =3D 0
26281 fcntl(0, F_SETFD, 0)              =3D 0
26281 fstat(0, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26281 stat("/var/run/xen-hotplug/block", {st_dev=3Dmakedev(8, 2), st_ino=3D=
2801738, st_mode=3DS_IFREG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st=
_blksize=3D4096, st_blocks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:=
24, st_mtime=3D2012/10/09-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D =
0
26281 exit_group(0)                     =3D ?
27813 <... read resumed> "", 128)       =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], WNOHANG, NUL=
L) =3D 26281
27813 wait4(-1, 0x7fffb0100a64, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0)                   =3D 0
27813 close(3)                          =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 write(2, "+ rightfile=3D\n", 13)    =3D 13
27813 write(2, "+ '[' x =3D xy ']'\n", 17) =3D 17
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ true\n", 7)           =3D 7
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ eval 'exec 200>>/var/run/xen-hotplug/block'\n", 46) =3D=
 46
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 write(2, "++ exec\n", 8)          =3D 8
27813 open("/var/run/xen-hotplug/block", O_WRONLY|O_CREAT|O_APPEND, 0666)=
 =3D 3
27813 fcntl(200, F_GETFD)               =3D 0
27813 fcntl(200, F_DUPFD, 10)           =3D 10
27813 fcntl(200, F_GETFD)               =3D 0
27813 dup2(3, 200)                      =3D 200
27813 close(3)                          =3D 0
27813 dup2(10, 200)                     =3D 200
27813 fcntl(10, F_GETFD)                =3D 0
27813 close(10)                         =3D 0
27813 write(2, "+ flock -x 200\n", 15)  =3D 15
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [INT CHLD], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [INT CHLD], NULL, 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26282
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26282 close(255 
27813 rt_sigprocmask(SIG_BLOCK, [CHLD],  
26282 <... close resumed> )             =3D 0
27813 <... rt_sigprocmask resumed> [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [],  
26282 rt_sigprocmask(SIG_SETMASK, [],  
27813 <... rt_sigprocmask resumed> NULL, 8) =3D 0
26282 <... rt_sigprocmask resumed> NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
26282 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0},  
26282 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
27813 <... rt_sigaction resumed> {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}=
, 8) =3D 0
26282 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 wait4(-1,  
26282 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
26282 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26282 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26282 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26282 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26282 execve("/usr/bin/flock", ["flock", "-x", "200"], ["SUBSYSTEM=3Dxen-=
backend", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D=
/usr/bin:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:=
/usr/sbin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dx=
en-backend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3D=
backend/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "S=
HLVL=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/flock"]) =3D 0=

26282 brk(0)                            =3D 0x1020000
26282 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f428ce90000
26282 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f428ce8f000
26282 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26282 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26282 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26282 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7f428ce75000=

26282 close(3)                          =3D 0
26282 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26282 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26282 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26282 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26282 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26282 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26282 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26282 close(3)                          =3D 0
26282 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f428ce74000
26282 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f428ce73000
26282 arch_prctl(ARCH_SET_FS, 0x7f428ce736e0) =3D 0
26282 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26282 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26282 munmap(0x7f428ce75000, 103979)    =3D 0
26282 flock(200, LOCK_EX)               =3D 0
26282 exit_group(0)                     =3D ?
27813 <... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], 0,=
 NULL) =3D 26282
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, 0x7fffb0100a24, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0xffffffffffffffff)  =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 pipe([3, 4])                      =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26283
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {0=
x436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26283 close(255 
27813 close(4 
26283 <... close resumed> )             =3D 0
27813 <... close resumed> )             =3D 0
27813 read(3,  
26283 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26283 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26283 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26283 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26283 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26283 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26283 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26283 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {S=
IG_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26283 rt_sigaction(SIGINT, {0x4481f0, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26283 dup2(4, 1)                        =3D 1
26283 close(4)                          =3D 0
26283 close(3)                          =3D 0
26283 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26283 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26283 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26283 write(2, "++ perl -e '\n            open STDIN, \"<&200\" or die $!=
;\n            my $fd_inum =3D (stat STDIN)[1]; die $! unless defined $fd=
_inum;\n            my $file_inum =3D (stat $ARGV[0])[1];\n            pr=
int \"y\\n\" if $fd_inum eq $file_inum;\n", 230) =3D 230
26283 write(2, "                             ' /var/run/xen-hotplug/block=
\n", 58) =3D 58
26283 stat(".", {st_dev=3Dmakedev(8, 2), st_ino=3D2, st_mode=3DS_IFDIR|07=
55, st_nlink=3D24, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
8, st_size=3D4096, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2012/10/08-=
11:13:38, st_ctime=3D2012/10/08-11:13:38}) =3D 0
26283 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26283 access("/usr/bin/perl", X_OK)     =3D 0
26283 access("/usr/bin/perl", R_OK)     =3D 0
26283 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26283 access("/usr/bin/perl", X_OK)     =3D 0
26283 access("/usr/bin/perl", R_OK)     =3D 0
26283 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
481f0, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26283 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26283 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26283 execve("/usr/bin/perl", ["perl", "-e", "\n            open STDIN, \=
"<&200\" or die $!;\n            my $fd_inum =3D (stat STDIN)[1]; die $! =
unless defined $fd_inum;\n            my $file_inum =3D (stat $ARGV[0])[1=
];\n            print \"y\\n\" if $fd_inum eq $file_inum;\n              =
               ", "/var/run/xen-hotplug/block"], ["SUBSYSTEM=3Dxen-backen=
d", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D/usr/b=
in:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:/usr/s=
bin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dxen-bac=
kend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3Dback=
end/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "SHLVL=
=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/perl"]) =3D 0
26283 brk(0)                            =3D 0x2076000
26283 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f11224aa000
26283 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f11224a9000
26283 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26283 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64/libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26283 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64", 0x7fffe22c6ee0) =3D -1 ENOENT (No such file or directory)
26283 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/lib=
perl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26283 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls", 0=
x7fffe22c6ee0) =3D -1 ENOENT (No such file or directory)
26283 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64/=
libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26283 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64"=
, 0x7fffe22c6ee0) =3D -1 ENOENT (No such file or directory)
26283 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl=
=2Eso", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26283 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE", 0x7ff=
fe22c6ee0) =3D -1 ENOENT (No such file or directory)
26283 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26283 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26283 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7f112248f000=

26283 close(3)                          =3D 0
26283 open("/usr/lib64/libperl.so", O_RDONLY) =3D 3
26283 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\34\203%=
4\0\0\0@\0\0\0\0\0\0\0\360;\23\0\0\0\0\0\0\0\0\0@\0008\0\5\0@\0\35\0\34\0=
\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\200%4\0\0\0\0\0\200%4\0\0\0T\260\22\=
0\0\0\0\0T\260\22\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0X\260\22\0\0\0\=
0\0X\260\262%4\0\0\0X\260\262%4\0\0\0\250\201\0\0\0\0\0\0\350\242\0\0\0\0=
\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\265\22\0\0\0\0\0\370\265\262%4\0\=
0\0\370\265\262%4\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\=
0\0P\345td\4\0\0\0\250u\21\0\0\0\0\0\250u\221%4\0\0\0\250u\221%4\0\0\0D@\=
0\0\0\0\0\0D@\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\7\4\0\0\360\0\0\0\0\1\0\0\16\0\0\0\0\0\0@\0\200\203\200\225\1\22\=
264\3\31\200l\0\32\0 \5\201\0\240\3\2B\0\200\21R \0\22\0\0\16P\20#\10\216=
\334\30\211\"\0\10 \200\3B\220@\0\1\206\20\30\2\3\21\203$!\312A0\224Y\200=
\27\0\242\26\10\24R@\10\200\220\20A\10\0\220\1\200\206\2\10\304\30i\0\220=
\1\1\202\200\22\20\0\n\1H\0\n\2001J \6\31@L\207\20\10\0000\10(\200\2\0\4\=
251t\"\262\310!\212\240\320\"\0\t"..., 832) =3D 832
26283 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2839671, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D2480, st_size=3D1262384, st_atime=3D2012/10/09-12:04:35, st_mtime=3D=
2012/09/11-12:45:05, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26283 mmap(0x3425800000, 3363648, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425800000
26283 mprotect(0x342592c000, 2093056, PROT_NONE) =3D 0
26283 mmap(0x3425b2b000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x12b000) =3D 0x3425b2b000
26283 mmap(0x3425b34000, 4928, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3425b34000
26283 close(3)                          =3D 0
26283 open("/lib64/libresolv.so.2", O_RDONLY) =3D 3
26283 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\2402\0'4\0\=
0\0@\0\0\0\0\0\0\0@a\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\5\0=
\0\0@\0\0\0\0\0\0\0@\0\0'4\0\0\0@\0\0'4\0\0\0\370\1\0\0\0\0\0\0\370\1\0\0=
\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \361\0\0\0\0\0\0 \361\0'4\0\0\0=
 \361\0'4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\=
0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0'4\0\0\0\0\0\0'4\0\0\0$\10\1\0\0\0\0\0$\10=
\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\24\1\0\0\0\0\0\340\24!'4\=
0\0\0\340\24!'4\0\0\0\340\r\0\0\0\0\0\0\0106\0\0\0\0\0\0\0\0 \0\0\0\0\0\2=
\0\0\0\6\0\0\0\350\35\1\0\0\0\0\0\350\35!'4\0\0\0\350\35!'4\0\0\0\300\1\0=
\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\=
0\0\0008\2\0'4\0\0\0008\2\0'4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0=
\0\0\0\0P\345td\4\0\0\0<\361\0\0\0\0\0\0<\361\0'4\0\0\0<\361\0'4\0\0\0,\3=
\0\0\0\0\0\0,\3\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 8=
32
26283 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148119, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D192, st_size=3D92736, st_atime=3D2012/10/09-11:16:43, st_mtime=3D201=
0/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:42}) =3D 0
26283 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f112248e000
26283 mmap(0x3427000000, 2181864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3427000000
26283 mprotect(0x3427011000, 2097152, PROT_NONE) =3D 0
26283 mmap(0x3427211000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x11000) =3D 0x3427211000
26283 mmap(0x3427213000, 6888, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3427213000
26283 close(3)                          =3D 0
26283 open("/lib64/libnsl.so.1", O_RDONLY) =3D 3
26283 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240@\340\35=
10\0\0\0@\0\0\0\0\0\0\0\360\265\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0=
\6\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\340\3510\0\0\0@\0\340\3510\0\0\0\370\1=
\0\0\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \33\1\0\0=
\0\0\0 \33\341\3510\0\0\0 \33\341\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\=
0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\340\3510\0\0\0=
\0\0\340\3510\0\0\0\310@\1\0\0\0\0\0\310@\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\=
0\0\6\0\0\0xM\1\0\0\0\0\0xM\1\3520\0\0\0xM\1\3520\0\0\0\310\5\0\0\0\0\0\0=
008-\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250M\1\0\0\0\0\0\250M\1\3=
520\0\0\0\250M\1\3520\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\340\3510\0\0\0008\2\340\351=
0\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0<\33\=
1\0\0\0\0\0<\33\341\3510\0\0\0<\33\341\3510\0\0\0\\\5\0\0\0\0\0\0\\\5\0\0=
\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26283 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147206, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D232, st_size=3D114352, st_atime=3D2012/10/09-12:01:01, st_mtime=3D20=
10/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:44}) =3D 0
26283 mmap(0x30e9e00000, 2194096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9e00000
26283 mprotect(0x30e9e15000, 2093056, PROT_NONE) =3D 0
26283 mmap(0x30ea014000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x14000) =3D 0x30ea014000
26283 mmap(0x30ea016000, 6832, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x30ea016000
26283 close(3)                          =3D 0
26283 open("/lib64/libdl.so.2", O_RDONLY) =3D 3
26283 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\16`\3500=
\0\0\0@\0\0\0\0\0\0\0@R\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0`\3500\0\0\0@\0`\3500\0\0\0\370\1\0\0\0\0\0\0\37=
0\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\300\32\0\0\0\0\0\0\300\3=
2`\3500\0\0\0\300\32`\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0`\3500\0\0\0\0\0`\3500\0\0\=
0\224\37\0\0\0\0\0\0\224\37\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0`-\=
0\0\0\0\0\0`-\200\3500\0\0\0`-\200\3500\0\0\0 \3\0\0\0\0\0\0\240\3\0\0\0\=
0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\240-\0\0\0\0\0\0\240-\200\3500\0\0\0=
\240-\200\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0=
\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2`\3500\0\0\0008\2`\3500\0\0\0 \0\0\=
0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\334\32\0\0\0\0\0\=
0\334\32`\3500\0\0\0\334\32`\3500\0\0\0\264\0\0\0\0\0\0\0\264\0\0\0\0\0\0=
\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26283 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147322, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D48, st_size=3D23360, st_atime=3D2012/10/09-11:13:54, st_mtime=3D2010=
/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26283 mmap(0x30e8600000, 2109696, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8600000
26283 mprotect(0x30e8602000, 2097152, PROT_NONE) =3D 0
26283 mmap(0x30e8802000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x2000) =3D 0x30e8802000
26283 close(3)                          =3D 0
26283 open("/lib64/libm.so.6", O_RDONLY) =3D 3
26283 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`>\240\3510\=
0\0\0@\0\0\0\0\0\0\0\240X\t\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0)\0(\0\6\0\0\=
0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3510\0\0\0@\0\240\3510\0\0\0\370\1\0\0\0\=
0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\360\303\7\0\0\0\=
0\0\360\303\247\3510\0\0\0\360\303\247\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0=
\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3510\=
0\0\0\0\0\240\3510\0\0\0000\22\10\0\0\0\0\0000\22\10\0\0\0\0\0\0\0 \0\0\0=
\0\0\1\0\0\0\6\0\0\0\270\35\10\0\0\0\0\0\270\35\310\3510\0\0\0\270\35\310=
\3510\0\0\0\320\2\0\0\0\0\0\0 \3\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0=
\0\350\35\10\0\0\0\0\0\350\35\310\3510\0\0\0\350\35\310\3510\0\0\0\300\1\=
0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0=
\0\0\0008\2\240\3510\0\0\0008\2\240\3510\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\f\304\7\0\0\0\0\0\f\304\247\3510\0\0\0=
\f\304\247\3510\0\0\0\374\r\0\0\0\0\0\0\374\r\0\0\0\0\0\0\4\0\0\0\0\0\0\0=
Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0"..., 832) =3D 832
26283 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147337, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D1216, st_size=3D615136, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2=
010/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26283 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f112248d000
26283 mmap(0x30e9a00000, 2629848, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9a00000
26283 mprotect(0x30e9a82000, 2093056, PROT_NONE) =3D 0
26283 mmap(0x30e9c81000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x81000) =3D 0x30e9c81000
26283 close(3)                          =3D 0
26283 open("/lib64/libcrypt.so.1", O_RDONLY) =3D 3
26283 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\t\300%4=
\0\0\0@\0\0\0\0\0\0\0\30\265\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\=
0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\300%4\0\0\0@\0\300%4\0\0\0\370\1\0\0\0\0\=
0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340}\0\0\0\0\0\0\3=
40}\300%4\0\0\0\340}\300%4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\300%4\0\0\0\0\0\300%4\0\0\=
0\4\205\0\0\0\0\0\0\4\205\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\310\=
215\0\0\0\0\0\0\310\215\340%4\0\0\0\310\215\340%4\0\0\0\250\2\0\0\0\0\0\0=
\370\343\2\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\215\0\0\0\0\0\0\3=
70\215\340%4\0\0\0\370\215\340%4\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\=
0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\300%4\0\0\0008\2=
\300%4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0=
\374}\0\0\0\0\0\0\374}\300%4\0\0\0\374}\300%4\0\0\0\34\1\0\0\0\0\0\0\34\1=
\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26283 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148123, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D96, st_size=3D48600, st_atime=3D2012/10/09-12:01:01, st_mtime=3D2010=
/07/28-03:52:39, st_ctime=3D2012/09/11-14:53:52}) =3D 0
26283 mmap(0x3425c00000, 2322880, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425c00000
26283 mprotect(0x3425c09000, 2093056, PROT_NONE) =3D 0
26283 mmap(0x3425e08000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x8000) =3D 0x3425e08000
26283 mmap(0x3425e0a000, 184768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FI=
XED|MAP_ANONYMOUS, -1, 0) =3D 0x3425e0a000
26283 close(3)                          =3D 0
26283 open("/lib64/libutil.so.1", O_RDONLY) =3D 3
26283 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\16\0(4\=
0\0\0@\0\0\0\0\0\0\0(>\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0\0(4\0\0\0@\0\0(4\0\0\0\370\1\0\0\0\0\0\0\370\1\=
0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340\26\0\0\0\0\0\0\340\26\0(=
4\0\0\0\340\26\0(4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0=
\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0(4\0\0\0\0\0\0(4\0\0\0P\32\0\0\0\=
0\0\0P\32\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\35\0\0\0\0\0\0\3=
40\35 (4\0\0\0\340\35 (4\0\0\0 \3\0\0\0\0\0\0000\3\0\0\0\0\0\0\0\0 \0\0\0=
\0\0\2\0\0\0\6\0\0\0\20\36\0\0\0\0\0\0\20\36 (4\0\0\0\20\36 (4\0\0\0\300\=
1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0=
\0\0\0\0008\2\0(4\0\0\0008\2\0(4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\=
0\0\0\0\0\0P\345td\4\0\0\0\374\26\0\0\0\0\0\0\374\26\0(4\0\0\0\374\26\0(4=
\0\0\0D\0\0\0\0\0\0\0D\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8=
32) =3D 832
26283 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147063, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D40, st_size=3D18152, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2010=
/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:49}) =3D 0
26283 mmap(0x3428000000, 2105616, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3428000000
26283 mprotect(0x3428002000, 2093056, PROT_NONE) =3D 0
26283 mmap(0x3428201000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x1000) =3D 0x3428201000
26283 close(3)                          =3D 0
26283 open("/lib64/libpthread.so.0", O_RDONLY) =3D 3
26283 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240W\240\35=
00\0\0\0@\0\0\0\0\0\0\0\340/\2\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0'\0&\0\6\0=
\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3500\0\0\0@\0\240\3500\0\0\0\370\1\0\0=
\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\240\t\1\0\0\0=
\0\0\240\t\241\3500\0\0\0\240\t\241\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\=
0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3500\0\0=
\0\0\0\240\3500\0\0\0pZ\1\0\0\0\0\0pZ\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\=
6\0\0\0\270[\1\0\0\0\0\0\270[\301\3500\0\0\0\270[\301\3500\0\0\0\230\6\0\=
0\0\0\0\0\270G\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250]\1\0\0\0\0\=
0\250]\301\3500\0\0\0\250]\301\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0=
\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\240\3500\0\0\=
0008\2\240\3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345t=
d\4\0\0\0\274\t\1\0\0\0\0\0\274\t\241\3500\0\0\0\274\t\241\3500\0\0\0\344=
\t\0\0\0\0\0\0\344\t\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =
=3D 832
26283 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147328, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D296, st_size=3D145824, st_atime=3D2012/10/09-11:16:43, st_mtime=3D20=
10/07/28-03:52:41, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26283 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f112248c000
26283 mmap(0x30e8a00000, 2204528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8a00000
26283 mprotect(0x30e8a16000, 2093056, PROT_NONE) =3D 0
26283 mmap(0x30e8c15000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x15000) =3D 0x30e8c15000
26283 mmap(0x30e8c17000, 13168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8c17000
26283 close(3)                          =3D 0
26283 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26283 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26283 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26283 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26283 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26283 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26283 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26283 close(3)                          =3D 0
26283 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f112248b000
26283 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f112248a000
26283 arch_prctl(ARCH_SET_FS, 0x7f112248a6e0) =3D 0
26283 mprotect(0x3427211000, 4096, PROT_READ) =3D 0
26283 mprotect(0x30ea014000, 4096, PROT_READ) =3D 0
26283 mprotect(0x30e8802000, 4096, PROT_READ) =3D 0
26283 mprotect(0x30e9c81000, 4096, PROT_READ) =3D 0
26283 mprotect(0x3425e08000, 4096, PROT_READ) =3D 0
26283 mprotect(0x3428201000, 4096, PROT_READ) =3D 0
26283 mprotect(0x30e8c15000, 4096, PROT_READ) =3D 0
26283 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26283 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26283 munmap(0x7f112248f000, 103979)    =3D 0
26283 set_tid_address(0x7f112248a770)   =3D 26283
26283 set_robust_list(0x7f112248a780, 0x18) =3D 0
26283 futex(0x7fffe22c7a0c, FUTEX_WAKE_PRIVATE, 1) =3D 0
26283 rt_sigaction(SIGRTMIN, {0x30e8a05380, [], SA_RESTORER|SA_SIGINFO, 0=
x30e8a0eb10}, NULL, 8) =3D 0
26283 rt_sigaction(SIGRT_1, {0x30e8a052b0, [], SA_RESTORER|SA_RESTART|SA_=
SIGINFO, 0x30e8a0eb10}, NULL, 8) =3D 0
26283 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) =3D 0
26283 getrlimit(RLIMIT_STACK, {rlim_cur=3D8192*1024, rlim_max=3DRLIM_INFI=
NITY}) =3D 0
26283 rt_sigaction(SIGFPE, {0x1, [FPE], SA_RESTORER|SA_RESTART, 0x30e8230=
2d0}, {SIG_DFL, [], 0}, 8) =3D 0
26283 brk(0)                            =3D 0x2076000
26283 brk(0x2098000)                    =3D 0x2098000
26283 getuid()                          =3D 0
26283 geteuid()                         =3D 0
26283 getgid()                          =3D 0
26283 getegid()                         =3D 0
26283 mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,=
 -1, 0) =3D 0x7f1122469000
26283 open("/dev/urandom", O_RDONLY)    =3D 3
26283 read(3, "\3I\211\1", 4)           =3D 4
26283 close(3)                          =3D 0
26283 stat("/usr/lib64/perl5/site_perl/5.8.7/x86_64-linux-thread-multi", =
0x7fffe22c76c0) =3D -1 ENOENT (No such file or directory)
26283 stat("/usr/lib/perl5/site_perl/5.8.7", 0x7fffe22c76c0) =3D -1 ENOEN=
T (No such file or directory)
26283 stat("/usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi", =
0x7fffe22c76c0) =3D -1 ENOENT (No such file or directory)
26283 stat("/usr/lib/perl5/site_perl/5.8.6", 0x7fffe22c76c0) =3D -1 ENOEN=
T (No such file or directory)
26283 stat("/usr/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi", =
0x7fffe22c76c0) =3D -1 ENOENT (No such file or directory)
26283 stat("/usr/lib/perl5/site_perl/5.8.5", 0x7fffe22c76c0) =3D -1 ENOEN=
T (No such file or directory)
26283 stat("/usr/lib64/perl5/vendor_perl/5.8.7/x86_64-linux-thread-multi"=
, 0x7fffe22c76c0) =3D -1 ENOENT (No such file or directory)
26283 stat("/usr/lib/perl5/vendor_perl/5.8.7", 0x7fffe22c76c0) =3D -1 ENO=
ENT (No such file or directory)
26283 stat("/usr/lib64/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi"=
, 0x7fffe22c76c0) =3D -1 ENOENT (No such file or directory)
26283 stat("/usr/lib/perl5/vendor_perl/5.8.6", 0x7fffe22c76c0) =3D -1 ENO=
ENT (No such file or directory)
26283 stat("/usr/lib64/perl5/vendor_perl/5.8.5/x86_64-linux-thread-multi"=
, 0x7fffe22c76c0) =3D -1 ENOENT (No such file or directory)
26283 stat("/usr/lib/perl5/vendor_perl/5.8.5", 0x7fffe22c76c0) =3D -1 ENO=
ENT (No such file or directory)
26283 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffe22c7480) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26283 lseek(0, 0, SEEK_CUR)             =3D 0
26283 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffe22c7480) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26283 lseek(1, 0, SEEK_CUR)             =3D -1 ESPIPE (Illegal seek)
26283 ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffe22c7490) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26283 lseek(2, 0, SEEK_CUR)             =3D 593658709
26283 open("/dev/null", O_RDONLY)       =3D 3
26283 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffe22c7590) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26283 lseek(3, 0, SEEK_CUR)             =3D 0
26283 fcntl(3, F_SETFD, FD_CLOEXEC)     =3D 0
26283 fstat(3, {st_dev=3Dmakedev(0, 16), st_ino=3D584, st_mode=3DS_IFCHR|=
0666, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
0, st_rdev=3Dmakedev(1, 3), st_atime=3D2012/10/08-11:13:26, st_mtime=3D20=
12/10/08-11:13:26, st_ctime=3D2012/10/08-11:13:27}) =3D 0
26283 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) =3D 0
26283 readlink("/proc/self/exe", "/usr/bin/perl"..., 4095) =3D 13
26283 brk(0x20b9000)                    =3D 0x20b9000
26283 close(3)                          =3D 0
26283 dup(200)                          =3D 3
26283 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffe22c7460) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26283 lseek(3, 0, SEEK_CUR)             =3D 0
26283 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26283 dup2(3, 0)                        =3D 0
26283 close(3)                          =3D 0
26283 fcntl(0, F_SETFD, 0)              =3D 0
26283 fstat(0, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26283 stat("/var/run/xen-hotplug/block", {st_dev=3Dmakedev(8, 2), st_ino=3D=
2801738, st_mode=3DS_IFREG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st=
_blksize=3D4096, st_blocks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:=
24, st_mtime=3D2012/10/09-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D =
0
26283 exit_group(0)                     =3D ?
27813 <... read resumed> "", 128)       =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], WNOHANG, NUL=
L) =3D 26283
27813 wait4(-1, 0x7fffb0100a64, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0)                   =3D 0
27813 close(3)                          =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 write(2, "+ rightfile=3D\n", 13)    =3D 13
27813 write(2, "+ '[' x =3D xy ']'\n", 17) =3D 17
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ true\n", 7)           =3D 7
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ eval 'exec 200>>/var/run/xen-hotplug/block'\n", 46) =3D=
 46
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 write(2, "++ exec\n", 8)          =3D 8
27813 open("/var/run/xen-hotplug/block", O_WRONLY|O_CREAT|O_APPEND, 0666)=
 =3D 3
27813 fcntl(200, F_GETFD)               =3D 0
27813 fcntl(200, F_DUPFD, 10)           =3D 10
27813 fcntl(200, F_GETFD)               =3D 0
27813 dup2(3, 200)                      =3D 200
27813 close(3)                          =3D 0
27813 dup2(10, 200)                     =3D 200
27813 fcntl(10, F_GETFD)                =3D 0
27813 close(10)                         =3D 0
27813 write(2, "+ flock -x 200\n", 15)  =3D 15
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [INT CHLD], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [INT CHLD], NULL, 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26284
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26284 close(255 
27813 rt_sigprocmask(SIG_BLOCK, [CHLD],  
26284 <... close resumed> )             =3D 0
27813 <... rt_sigprocmask resumed> [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [],  
26284 rt_sigprocmask(SIG_SETMASK, [],  
27813 <... rt_sigprocmask resumed> NULL, 8) =3D 0
26284 <... rt_sigprocmask resumed> NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
26284 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0},  
26284 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
27813 <... rt_sigaction resumed> {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}=
, 8) =3D 0
26284 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 wait4(-1,  
26284 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
26284 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26284 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26284 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26284 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26284 execve("/usr/bin/flock", ["flock", "-x", "200"], ["SUBSYSTEM=3Dxen-=
backend", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D=
/usr/bin:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:=
/usr/sbin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dx=
en-backend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3D=
backend/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "S=
HLVL=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/flock"]) =3D 0=

26284 brk(0)                            =3D 0x20cf000
26284 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fc09b672000
26284 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fc09b671000
26284 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26284 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26284 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26284 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7fc09b657000=

26284 close(3)                          =3D 0
26284 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26284 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26284 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26284 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26284 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26284 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26284 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26284 close(3)                          =3D 0
26284 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fc09b656000
26284 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fc09b655000
26284 arch_prctl(ARCH_SET_FS, 0x7fc09b6556e0) =3D 0
26284 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26284 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26284 munmap(0x7fc09b657000, 103979)    =3D 0
26284 flock(200, LOCK_EX)               =3D 0
26284 exit_group(0)                     =3D ?
27813 <... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], 0,=
 NULL) =3D 26284
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, 0x7fffb0100a24, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0xffffffffffffffff)  =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 pipe([3, 4])                      =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26285
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {0=
x436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26285 close(255 
27813 close(4 
26285 <... close resumed> )             =3D 0
27813 <... close resumed> )             =3D 0
27813 read(3,  
26285 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26285 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26285 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26285 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26285 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26285 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26285 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26285 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {S=
IG_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26285 rt_sigaction(SIGINT, {0x4481f0, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26285 dup2(4, 1)                        =3D 1
26285 close(4)                          =3D 0
26285 close(3)                          =3D 0
26285 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26285 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26285 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26285 write(2, "++ perl -e '\n            open STDIN, \"<&200\" or die $!=
;\n            my $fd_inum =3D (stat STDIN)[1]; die $! unless defined $fd=
_inum;\n            my $file_inum =3D (stat $ARGV[0])[1];\n            pr=
int \"y\\n\" if $fd_inum eq $file_inum;\n", 230) =3D 230
26285 write(2, "                             ' /var/run/xen-hotplug/block=
\n", 58) =3D 58
26285 stat(".", {st_dev=3Dmakedev(8, 2), st_ino=3D2, st_mode=3DS_IFDIR|07=
55, st_nlink=3D24, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
8, st_size=3D4096, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2012/10/08-=
11:13:38, st_ctime=3D2012/10/08-11:13:38}) =3D 0
26285 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26285 access("/usr/bin/perl", X_OK)     =3D 0
26285 access("/usr/bin/perl", R_OK)     =3D 0
26285 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26285 access("/usr/bin/perl", X_OK)     =3D 0
26285 access("/usr/bin/perl", R_OK)     =3D 0
26285 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
481f0, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26285 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26285 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26285 execve("/usr/bin/perl", ["perl", "-e", "\n            open STDIN, \=
"<&200\" or die $!;\n            my $fd_inum =3D (stat STDIN)[1]; die $! =
unless defined $fd_inum;\n            my $file_inum =3D (stat $ARGV[0])[1=
];\n            print \"y\\n\" if $fd_inum eq $file_inum;\n              =
               ", "/var/run/xen-hotplug/block"], ["SUBSYSTEM=3Dxen-backen=
d", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D/usr/b=
in:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:/usr/s=
bin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dxen-bac=
kend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3Dback=
end/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "SHLVL=
=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/perl"]) =3D 0
26285 brk(0)                            =3D 0x2572000
26285 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f07e80ef000
26285 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f07e80ee000
26285 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26285 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64/libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26285 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64", 0x7fffd33be470) =3D -1 ENOENT (No such file or directory)
26285 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/lib=
perl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26285 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls", 0=
x7fffd33be470) =3D -1 ENOENT (No such file or directory)
26285 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64/=
libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26285 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64"=
, 0x7fffd33be470) =3D -1 ENOENT (No such file or directory)
26285 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl=
=2Eso", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26285 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE", 0x7ff=
fd33be470) =3D -1 ENOENT (No such file or directory)
26285 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26285 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26285 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7f07e80d4000=

26285 close(3)                          =3D 0
26285 open("/usr/lib64/libperl.so", O_RDONLY) =3D 3
26285 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\34\203%=
4\0\0\0@\0\0\0\0\0\0\0\360;\23\0\0\0\0\0\0\0\0\0@\0008\0\5\0@\0\35\0\34\0=
\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\200%4\0\0\0\0\0\200%4\0\0\0T\260\22\=
0\0\0\0\0T\260\22\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0X\260\22\0\0\0\=
0\0X\260\262%4\0\0\0X\260\262%4\0\0\0\250\201\0\0\0\0\0\0\350\242\0\0\0\0=
\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\265\22\0\0\0\0\0\370\265\262%4\0\=
0\0\370\265\262%4\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\=
0\0P\345td\4\0\0\0\250u\21\0\0\0\0\0\250u\221%4\0\0\0\250u\221%4\0\0\0D@\=
0\0\0\0\0\0D@\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\7\4\0\0\360\0\0\0\0\1\0\0\16\0\0\0\0\0\0@\0\200\203\200\225\1\22\=
264\3\31\200l\0\32\0 \5\201\0\240\3\2B\0\200\21R \0\22\0\0\16P\20#\10\216=
\334\30\211\"\0\10 \200\3B\220@\0\1\206\20\30\2\3\21\203$!\312A0\224Y\200=
\27\0\242\26\10\24R@\10\200\220\20A\10\0\220\1\200\206\2\10\304\30i\0\220=
\1\1\202\200\22\20\0\n\1H\0\n\2001J \6\31@L\207\20\10\0000\10(\200\2\0\4\=
251t\"\262\310!\212\240\320\"\0\t"..., 832) =3D 832
26285 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2839671, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D2480, st_size=3D1262384, st_atime=3D2012/10/09-12:04:35, st_mtime=3D=
2012/09/11-12:45:05, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26285 mmap(0x3425800000, 3363648, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425800000
26285 mprotect(0x342592c000, 2093056, PROT_NONE) =3D 0
26285 mmap(0x3425b2b000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x12b000) =3D 0x3425b2b000
26285 mmap(0x3425b34000, 4928, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3425b34000
26285 close(3)                          =3D 0
26285 open("/lib64/libresolv.so.2", O_RDONLY) =3D 3
26285 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\2402\0'4\0\=
0\0@\0\0\0\0\0\0\0@a\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\5\0=
\0\0@\0\0\0\0\0\0\0@\0\0'4\0\0\0@\0\0'4\0\0\0\370\1\0\0\0\0\0\0\370\1\0\0=
\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \361\0\0\0\0\0\0 \361\0'4\0\0\0=
 \361\0'4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\=
0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0'4\0\0\0\0\0\0'4\0\0\0$\10\1\0\0\0\0\0$\10=
\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\24\1\0\0\0\0\0\340\24!'4\=
0\0\0\340\24!'4\0\0\0\340\r\0\0\0\0\0\0\0106\0\0\0\0\0\0\0\0 \0\0\0\0\0\2=
\0\0\0\6\0\0\0\350\35\1\0\0\0\0\0\350\35!'4\0\0\0\350\35!'4\0\0\0\300\1\0=
\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\=
0\0\0008\2\0'4\0\0\0008\2\0'4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0=
\0\0\0\0P\345td\4\0\0\0<\361\0\0\0\0\0\0<\361\0'4\0\0\0<\361\0'4\0\0\0,\3=
\0\0\0\0\0\0,\3\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 8=
32
26285 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148119, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D192, st_size=3D92736, st_atime=3D2012/10/09-11:16:43, st_mtime=3D201=
0/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:42}) =3D 0
26285 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f07e80d3000
26285 mmap(0x3427000000, 2181864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3427000000
26285 mprotect(0x3427011000, 2097152, PROT_NONE) =3D 0
26285 mmap(0x3427211000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x11000) =3D 0x3427211000
26285 mmap(0x3427213000, 6888, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3427213000
26285 close(3)                          =3D 0
26285 open("/lib64/libnsl.so.1", O_RDONLY) =3D 3
26285 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240@\340\35=
10\0\0\0@\0\0\0\0\0\0\0\360\265\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0=
\6\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\340\3510\0\0\0@\0\340\3510\0\0\0\370\1=
\0\0\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \33\1\0\0=
\0\0\0 \33\341\3510\0\0\0 \33\341\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\=
0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\340\3510\0\0\0=
\0\0\340\3510\0\0\0\310@\1\0\0\0\0\0\310@\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\=
0\0\6\0\0\0xM\1\0\0\0\0\0xM\1\3520\0\0\0xM\1\3520\0\0\0\310\5\0\0\0\0\0\0=
008-\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250M\1\0\0\0\0\0\250M\1\3=
520\0\0\0\250M\1\3520\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\340\3510\0\0\0008\2\340\351=
0\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0<\33\=
1\0\0\0\0\0<\33\341\3510\0\0\0<\33\341\3510\0\0\0\\\5\0\0\0\0\0\0\\\5\0\0=
\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26285 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147206, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D232, st_size=3D114352, st_atime=3D2012/10/09-12:01:01, st_mtime=3D20=
10/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:44}) =3D 0
26285 mmap(0x30e9e00000, 2194096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9e00000
26285 mprotect(0x30e9e15000, 2093056, PROT_NONE) =3D 0
26285 mmap(0x30ea014000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x14000) =3D 0x30ea014000
26285 mmap(0x30ea016000, 6832, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x30ea016000
26285 close(3)                          =3D 0
26285 open("/lib64/libdl.so.2", O_RDONLY) =3D 3
26285 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\16`\3500=
\0\0\0@\0\0\0\0\0\0\0@R\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0`\3500\0\0\0@\0`\3500\0\0\0\370\1\0\0\0\0\0\0\37=
0\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\300\32\0\0\0\0\0\0\300\3=
2`\3500\0\0\0\300\32`\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0`\3500\0\0\0\0\0`\3500\0\0\=
0\224\37\0\0\0\0\0\0\224\37\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0`-\=
0\0\0\0\0\0`-\200\3500\0\0\0`-\200\3500\0\0\0 \3\0\0\0\0\0\0\240\3\0\0\0\=
0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\240-\0\0\0\0\0\0\240-\200\3500\0\0\0=
\240-\200\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0=
\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2`\3500\0\0\0008\2`\3500\0\0\0 \0\0\=
0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\334\32\0\0\0\0\0\=
0\334\32`\3500\0\0\0\334\32`\3500\0\0\0\264\0\0\0\0\0\0\0\264\0\0\0\0\0\0=
\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26285 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147322, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D48, st_size=3D23360, st_atime=3D2012/10/09-11:13:54, st_mtime=3D2010=
/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26285 mmap(0x30e8600000, 2109696, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8600000
26285 mprotect(0x30e8602000, 2097152, PROT_NONE) =3D 0
26285 mmap(0x30e8802000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x2000) =3D 0x30e8802000
26285 close(3)                          =3D 0
26285 open("/lib64/libm.so.6", O_RDONLY) =3D 3
26285 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`>\240\3510\=
0\0\0@\0\0\0\0\0\0\0\240X\t\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0)\0(\0\6\0\0\=
0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3510\0\0\0@\0\240\3510\0\0\0\370\1\0\0\0\=
0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\360\303\7\0\0\0\=
0\0\360\303\247\3510\0\0\0\360\303\247\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0=
\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3510\=
0\0\0\0\0\240\3510\0\0\0000\22\10\0\0\0\0\0000\22\10\0\0\0\0\0\0\0 \0\0\0=
\0\0\1\0\0\0\6\0\0\0\270\35\10\0\0\0\0\0\270\35\310\3510\0\0\0\270\35\310=
\3510\0\0\0\320\2\0\0\0\0\0\0 \3\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0=
\0\350\35\10\0\0\0\0\0\350\35\310\3510\0\0\0\350\35\310\3510\0\0\0\300\1\=
0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0=
\0\0\0008\2\240\3510\0\0\0008\2\240\3510\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\f\304\7\0\0\0\0\0\f\304\247\3510\0\0\0=
\f\304\247\3510\0\0\0\374\r\0\0\0\0\0\0\374\r\0\0\0\0\0\0\4\0\0\0\0\0\0\0=
Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0"..., 832) =3D 832
26285 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147337, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D1216, st_size=3D615136, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2=
010/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26285 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f07e80d2000
26285 mmap(0x30e9a00000, 2629848, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9a00000
26285 mprotect(0x30e9a82000, 2093056, PROT_NONE) =3D 0
26285 mmap(0x30e9c81000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x81000) =3D 0x30e9c81000
26285 close(3)                          =3D 0
26285 open("/lib64/libcrypt.so.1", O_RDONLY) =3D 3
26285 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\t\300%4=
\0\0\0@\0\0\0\0\0\0\0\30\265\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\=
0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\300%4\0\0\0@\0\300%4\0\0\0\370\1\0\0\0\0\=
0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340}\0\0\0\0\0\0\3=
40}\300%4\0\0\0\340}\300%4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\300%4\0\0\0\0\0\300%4\0\0\=
0\4\205\0\0\0\0\0\0\4\205\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\310\=
215\0\0\0\0\0\0\310\215\340%4\0\0\0\310\215\340%4\0\0\0\250\2\0\0\0\0\0\0=
\370\343\2\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\215\0\0\0\0\0\0\3=
70\215\340%4\0\0\0\370\215\340%4\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\=
0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\300%4\0\0\0008\2=
\300%4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0=
\374}\0\0\0\0\0\0\374}\300%4\0\0\0\374}\300%4\0\0\0\34\1\0\0\0\0\0\0\34\1=
\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26285 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148123, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D96, st_size=3D48600, st_atime=3D2012/10/09-12:01:01, st_mtime=3D2010=
/07/28-03:52:39, st_ctime=3D2012/09/11-14:53:52}) =3D 0
26285 mmap(0x3425c00000, 2322880, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425c00000
26285 mprotect(0x3425c09000, 2093056, PROT_NONE) =3D 0
26285 mmap(0x3425e08000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x8000) =3D 0x3425e08000
26285 mmap(0x3425e0a000, 184768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FI=
XED|MAP_ANONYMOUS, -1, 0) =3D 0x3425e0a000
26285 close(3)                          =3D 0
26285 open("/lib64/libutil.so.1", O_RDONLY) =3D 3
26285 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\16\0(4\=
0\0\0@\0\0\0\0\0\0\0(>\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0\0(4\0\0\0@\0\0(4\0\0\0\370\1\0\0\0\0\0\0\370\1\=
0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340\26\0\0\0\0\0\0\340\26\0(=
4\0\0\0\340\26\0(4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0=
\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0(4\0\0\0\0\0\0(4\0\0\0P\32\0\0\0\=
0\0\0P\32\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\35\0\0\0\0\0\0\3=
40\35 (4\0\0\0\340\35 (4\0\0\0 \3\0\0\0\0\0\0000\3\0\0\0\0\0\0\0\0 \0\0\0=
\0\0\2\0\0\0\6\0\0\0\20\36\0\0\0\0\0\0\20\36 (4\0\0\0\20\36 (4\0\0\0\300\=
1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0=
\0\0\0\0008\2\0(4\0\0\0008\2\0(4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\=
0\0\0\0\0\0P\345td\4\0\0\0\374\26\0\0\0\0\0\0\374\26\0(4\0\0\0\374\26\0(4=
\0\0\0D\0\0\0\0\0\0\0D\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8=
32) =3D 832
26285 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147063, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D40, st_size=3D18152, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2010=
/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:49}) =3D 0
26285 mmap(0x3428000000, 2105616, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3428000000
26285 mprotect(0x3428002000, 2093056, PROT_NONE) =3D 0
26285 mmap(0x3428201000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x1000) =3D 0x3428201000
26285 close(3)                          =3D 0
26285 open("/lib64/libpthread.so.0", O_RDONLY) =3D 3
26285 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240W\240\35=
00\0\0\0@\0\0\0\0\0\0\0\340/\2\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0'\0&\0\6\0=
\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3500\0\0\0@\0\240\3500\0\0\0\370\1\0\0=
\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\240\t\1\0\0\0=
\0\0\240\t\241\3500\0\0\0\240\t\241\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\=
0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3500\0\0=
\0\0\0\240\3500\0\0\0pZ\1\0\0\0\0\0pZ\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\=
6\0\0\0\270[\1\0\0\0\0\0\270[\301\3500\0\0\0\270[\301\3500\0\0\0\230\6\0\=
0\0\0\0\0\270G\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250]\1\0\0\0\0\=
0\250]\301\3500\0\0\0\250]\301\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0=
\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\240\3500\0\0\=
0008\2\240\3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345t=
d\4\0\0\0\274\t\1\0\0\0\0\0\274\t\241\3500\0\0\0\274\t\241\3500\0\0\0\344=
\t\0\0\0\0\0\0\344\t\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =
=3D 832
26285 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147328, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D296, st_size=3D145824, st_atime=3D2012/10/09-11:16:43, st_mtime=3D20=
10/07/28-03:52:41, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26285 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f07e80d1000
26285 mmap(0x30e8a00000, 2204528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8a00000
26285 mprotect(0x30e8a16000, 2093056, PROT_NONE) =3D 0
26285 mmap(0x30e8c15000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x15000) =3D 0x30e8c15000
26285 mmap(0x30e8c17000, 13168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8c17000
26285 close(3)                          =3D 0
26285 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26285 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26285 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26285 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26285 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26285 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26285 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26285 close(3)                          =3D 0
26285 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f07e80d0000
26285 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f07e80cf000
26285 arch_prctl(ARCH_SET_FS, 0x7f07e80cf6e0) =3D 0
26285 mprotect(0x3427211000, 4096, PROT_READ) =3D 0
26285 mprotect(0x30ea014000, 4096, PROT_READ) =3D 0
26285 mprotect(0x30e8802000, 4096, PROT_READ) =3D 0
26285 mprotect(0x30e9c81000, 4096, PROT_READ) =3D 0
26285 mprotect(0x3425e08000, 4096, PROT_READ) =3D 0
26285 mprotect(0x3428201000, 4096, PROT_READ) =3D 0
26285 mprotect(0x30e8c15000, 4096, PROT_READ) =3D 0
26285 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26285 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26285 munmap(0x7f07e80d4000, 103979)    =3D 0
26285 set_tid_address(0x7f07e80cf770)   =3D 26285
26285 set_robust_list(0x7f07e80cf780, 0x18) =3D 0
26285 futex(0x7fffd33bef9c, FUTEX_WAKE_PRIVATE, 1) =3D 0
26285 rt_sigaction(SIGRTMIN, {0x30e8a05380, [], SA_RESTORER|SA_SIGINFO, 0=
x30e8a0eb10}, NULL, 8) =3D 0
26285 rt_sigaction(SIGRT_1, {0x30e8a052b0, [], SA_RESTORER|SA_RESTART|SA_=
SIGINFO, 0x30e8a0eb10}, NULL, 8) =3D 0
26285 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) =3D 0
26285 getrlimit(RLIMIT_STACK, {rlim_cur=3D8192*1024, rlim_max=3DRLIM_INFI=
NITY}) =3D 0
26285 rt_sigaction(SIGFPE, {0x1, [FPE], SA_RESTORER|SA_RESTART, 0x30e8230=
2d0}, {SIG_DFL, [], 0}, 8) =3D 0
26285 brk(0)                            =3D 0x2572000
26285 brk(0x2594000)                    =3D 0x2594000
26285 getuid()                          =3D 0
26285 geteuid()                         =3D 0
26285 getgid()                          =3D 0
26285 getegid()                         =3D 0
26285 mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,=
 -1, 0) =3D 0x7f07e80ae000
26285 open("/dev/urandom", O_RDONLY)    =3D 3
26285 read(3, "\246)iQ", 4)             =3D 4
26285 close(3)                          =3D 0
26285 stat("/usr/lib64/perl5/site_perl/5.8.7/x86_64-linux-thread-multi", =
0x7fffd33bec50) =3D -1 ENOENT (No such file or directory)
26285 stat("/usr/lib/perl5/site_perl/5.8.7", 0x7fffd33bec50) =3D -1 ENOEN=
T (No such file or directory)
26285 stat("/usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi", =
0x7fffd33bec50) =3D -1 ENOENT (No such file or directory)
26285 stat("/usr/lib/perl5/site_perl/5.8.6", 0x7fffd33bec50) =3D -1 ENOEN=
T (No such file or directory)
26285 stat("/usr/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi", =
0x7fffd33bec50) =3D -1 ENOENT (No such file or directory)
26285 stat("/usr/lib/perl5/site_perl/5.8.5", 0x7fffd33bec50) =3D -1 ENOEN=
T (No such file or directory)
26285 stat("/usr/lib64/perl5/vendor_perl/5.8.7/x86_64-linux-thread-multi"=
, 0x7fffd33bec50) =3D -1 ENOENT (No such file or directory)
26285 stat("/usr/lib/perl5/vendor_perl/5.8.7", 0x7fffd33bec50) =3D -1 ENO=
ENT (No such file or directory)
26285 stat("/usr/lib64/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi"=
, 0x7fffd33bec50) =3D -1 ENOENT (No such file or directory)
26285 stat("/usr/lib/perl5/vendor_perl/5.8.6", 0x7fffd33bec50) =3D -1 ENO=
ENT (No such file or directory)
26285 stat("/usr/lib64/perl5/vendor_perl/5.8.5/x86_64-linux-thread-multi"=
, 0x7fffd33bec50) =3D -1 ENOENT (No such file or directory)
26285 stat("/usr/lib/perl5/vendor_perl/5.8.5", 0x7fffd33bec50) =3D -1 ENO=
ENT (No such file or directory)
26285 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffd33bea10) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26285 lseek(0, 0, SEEK_CUR)             =3D 0
26285 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffd33bea10) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26285 lseek(1, 0, SEEK_CUR)             =3D -1 ESPIPE (Illegal seek)
26285 ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffd33bea20) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26285 lseek(2, 0, SEEK_CUR)             =3D 593659103
26285 open("/dev/null", O_RDONLY)       =3D 3
26285 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffd33beb20) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26285 lseek(3, 0, SEEK_CUR)             =3D 0
26285 fcntl(3, F_SETFD, FD_CLOEXEC)     =3D 0
26285 fstat(3, {st_dev=3Dmakedev(0, 16), st_ino=3D584, st_mode=3DS_IFCHR|=
0666, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
0, st_rdev=3Dmakedev(1, 3), st_atime=3D2012/10/08-11:13:26, st_mtime=3D20=
12/10/08-11:13:26, st_ctime=3D2012/10/08-11:13:27}) =3D 0
26285 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) =3D 0
26285 readlink("/proc/self/exe", "/usr/bin/perl"..., 4095) =3D 13
26285 brk(0x25b5000)                    =3D 0x25b5000
26285 close(3)                          =3D 0
26285 dup(200)                          =3D 3
26285 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffd33be9f0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26285 lseek(3, 0, SEEK_CUR)             =3D 0
26285 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26285 dup2(3, 0)                        =3D 0
26285 close(3)                          =3D 0
26285 fcntl(0, F_SETFD, 0)              =3D 0
26285 fstat(0, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26285 stat("/var/run/xen-hotplug/block", {st_dev=3Dmakedev(8, 2), st_ino=3D=
2801738, st_mode=3DS_IFREG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st=
_blksize=3D4096, st_blocks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:=
24, st_mtime=3D2012/10/09-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D =
0
26285 exit_group(0)                     =3D ?
27813 <... read resumed> "", 128)       =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], WNOHANG, NUL=
L) =3D 26285
27813 wait4(-1, 0x7fffb0100a64, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0)                   =3D 0
27813 close(3)                          =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 write(2, "+ rightfile=3D\n", 13)    =3D 13
27813 write(2, "+ '[' x =3D xy ']'\n", 17) =3D 17
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ true\n", 7)           =3D 7
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ eval 'exec 200>>/var/run/xen-hotplug/block'\n", 46) =3D=
 46
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 write(2, "++ exec\n", 8)          =3D 8
27813 open("/var/run/xen-hotplug/block", O_WRONLY|O_CREAT|O_APPEND, 0666)=
 =3D 3
27813 fcntl(200, F_GETFD)               =3D 0
27813 fcntl(200, F_DUPFD, 10)           =3D 10
27813 fcntl(200, F_GETFD)               =3D 0
27813 dup2(3, 200)                      =3D 200
27813 close(3)                          =3D 0
27813 dup2(10, 200)                     =3D 200
27813 fcntl(10, F_GETFD)                =3D 0
27813 close(10)                         =3D 0
27813 write(2, "+ flock -x 200\n", 15)  =3D 15
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [INT CHLD], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [INT CHLD], NULL, 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26286
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26286 close(255 
27813 rt_sigprocmask(SIG_BLOCK, [CHLD],  
26286 <... close resumed> )             =3D 0
27813 <... rt_sigprocmask resumed> [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [],  
26286 rt_sigprocmask(SIG_SETMASK, [],  
27813 <... rt_sigprocmask resumed> NULL, 8) =3D 0
26286 <... rt_sigprocmask resumed> NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
26286 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0},  
26286 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
27813 <... rt_sigaction resumed> {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}=
, 8) =3D 0
26286 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 wait4(-1,  
26286 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
26286 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26286 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26286 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26286 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26286 execve("/usr/bin/flock", ["flock", "-x", "200"], ["SUBSYSTEM=3Dxen-=
backend", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D=
/usr/bin:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:=
/usr/sbin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dx=
en-backend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3D=
backend/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "S=
HLVL=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/flock"]) =3D 0=

26286 brk(0)                            =3D 0x1bb0000
26286 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fafdc01b000
26286 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fafdc01a000
26286 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26286 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26286 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26286 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7fafdc000000=

26286 close(3)                          =3D 0
26286 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26286 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26286 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26286 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26286 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26286 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26286 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26286 close(3)                          =3D 0
26286 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fafdbfff000
26286 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fafdbffe000
26286 arch_prctl(ARCH_SET_FS, 0x7fafdbffe6e0) =3D 0
26286 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26286 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26286 munmap(0x7fafdc000000, 103979)    =3D 0
26286 flock(200, LOCK_EX)               =3D 0
26286 exit_group(0)                     =3D ?
27813 <... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], 0,=
 NULL) =3D 26286
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, 0x7fffb0100a24, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0xffffffffffffffff)  =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 pipe([3, 4])                      =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26287
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {0=
x436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26287 close(255 
27813 close(4 
26287 <... close resumed> )             =3D 0
27813 <... close resumed> )             =3D 0
27813 read(3,  
26287 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26287 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26287 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26287 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26287 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26287 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26287 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26287 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {S=
IG_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26287 rt_sigaction(SIGINT, {0x4481f0, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26287 dup2(4, 1)                        =3D 1
26287 close(4)                          =3D 0
26287 close(3)                          =3D 0
26287 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26287 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26287 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26287 write(2, "++ perl -e '\n            open STDIN, \"<&200\" or die $!=
;\n            my $fd_inum =3D (stat STDIN)[1]; die $! unless defined $fd=
_inum;\n            my $file_inum =3D (stat $ARGV[0])[1];\n            pr=
int \"y\\n\" if $fd_inum eq $file_inum;\n", 230) =3D 230
26287 write(2, "                             ' /var/run/xen-hotplug/block=
\n", 58) =3D 58
26287 stat(".", {st_dev=3Dmakedev(8, 2), st_ino=3D2, st_mode=3DS_IFDIR|07=
55, st_nlink=3D24, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
8, st_size=3D4096, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2012/10/08-=
11:13:38, st_ctime=3D2012/10/08-11:13:38}) =3D 0
26287 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26287 access("/usr/bin/perl", X_OK)     =3D 0
26287 access("/usr/bin/perl", R_OK)     =3D 0
26287 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26287 access("/usr/bin/perl", X_OK)     =3D 0
26287 access("/usr/bin/perl", R_OK)     =3D 0
26287 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
481f0, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26287 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26287 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26287 execve("/usr/bin/perl", ["perl", "-e", "\n            open STDIN, \=
"<&200\" or die $!;\n            my $fd_inum =3D (stat STDIN)[1]; die $! =
unless defined $fd_inum;\n            my $file_inum =3D (stat $ARGV[0])[1=
];\n            print \"y\\n\" if $fd_inum eq $file_inum;\n              =
               ", "/var/run/xen-hotplug/block"], ["SUBSYSTEM=3Dxen-backen=
d", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D/usr/b=
in:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:/usr/s=
bin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dxen-bac=
kend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3Dback=
end/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "SHLVL=
=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/perl"]) =3D 0
26287 brk(0)                            =3D 0x16fd000
26287 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f2da8f22000
26287 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f2da8f21000
26287 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26287 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64/libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26287 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64", 0x7fffb5e66d10) =3D -1 ENOENT (No such file or directory)
26287 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/lib=
perl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26287 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls", 0=
x7fffb5e66d10) =3D -1 ENOENT (No such file or directory)
26287 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64/=
libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26287 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64"=
, 0x7fffb5e66d10) =3D -1 ENOENT (No such file or directory)
26287 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl=
=2Eso", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26287 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE", 0x7ff=
fb5e66d10) =3D -1 ENOENT (No such file or directory)
26287 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26287 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26287 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7f2da8f07000=

26287 close(3)                          =3D 0
26287 open("/usr/lib64/libperl.so", O_RDONLY) =3D 3
26287 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\34\203%=
4\0\0\0@\0\0\0\0\0\0\0\360;\23\0\0\0\0\0\0\0\0\0@\0008\0\5\0@\0\35\0\34\0=
\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\200%4\0\0\0\0\0\200%4\0\0\0T\260\22\=
0\0\0\0\0T\260\22\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0X\260\22\0\0\0\=
0\0X\260\262%4\0\0\0X\260\262%4\0\0\0\250\201\0\0\0\0\0\0\350\242\0\0\0\0=
\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\265\22\0\0\0\0\0\370\265\262%4\0\=
0\0\370\265\262%4\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\=
0\0P\345td\4\0\0\0\250u\21\0\0\0\0\0\250u\221%4\0\0\0\250u\221%4\0\0\0D@\=
0\0\0\0\0\0D@\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\7\4\0\0\360\0\0\0\0\1\0\0\16\0\0\0\0\0\0@\0\200\203\200\225\1\22\=
264\3\31\200l\0\32\0 \5\201\0\240\3\2B\0\200\21R \0\22\0\0\16P\20#\10\216=
\334\30\211\"\0\10 \200\3B\220@\0\1\206\20\30\2\3\21\203$!\312A0\224Y\200=
\27\0\242\26\10\24R@\10\200\220\20A\10\0\220\1\200\206\2\10\304\30i\0\220=
\1\1\202\200\22\20\0\n\1H\0\n\2001J \6\31@L\207\20\10\0000\10(\200\2\0\4\=
251t\"\262\310!\212\240\320\"\0\t"..., 832) =3D 832
26287 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2839671, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D2480, st_size=3D1262384, st_atime=3D2012/10/09-12:04:35, st_mtime=3D=
2012/09/11-12:45:05, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26287 mmap(0x3425800000, 3363648, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425800000
26287 mprotect(0x342592c000, 2093056, PROT_NONE) =3D 0
26287 mmap(0x3425b2b000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x12b000) =3D 0x3425b2b000
26287 mmap(0x3425b34000, 4928, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3425b34000
26287 close(3)                          =3D 0
26287 open("/lib64/libresolv.so.2", O_RDONLY) =3D 3
26287 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\2402\0'4\0\=
0\0@\0\0\0\0\0\0\0@a\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\5\0=
\0\0@\0\0\0\0\0\0\0@\0\0'4\0\0\0@\0\0'4\0\0\0\370\1\0\0\0\0\0\0\370\1\0\0=
\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \361\0\0\0\0\0\0 \361\0'4\0\0\0=
 \361\0'4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\=
0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0'4\0\0\0\0\0\0'4\0\0\0$\10\1\0\0\0\0\0$\10=
\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\24\1\0\0\0\0\0\340\24!'4\=
0\0\0\340\24!'4\0\0\0\340\r\0\0\0\0\0\0\0106\0\0\0\0\0\0\0\0 \0\0\0\0\0\2=
\0\0\0\6\0\0\0\350\35\1\0\0\0\0\0\350\35!'4\0\0\0\350\35!'4\0\0\0\300\1\0=
\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\=
0\0\0008\2\0'4\0\0\0008\2\0'4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0=
\0\0\0\0P\345td\4\0\0\0<\361\0\0\0\0\0\0<\361\0'4\0\0\0<\361\0'4\0\0\0,\3=
\0\0\0\0\0\0,\3\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 8=
32
26287 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148119, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D192, st_size=3D92736, st_atime=3D2012/10/09-11:16:43, st_mtime=3D201=
0/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:42}) =3D 0
26287 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f2da8f06000
26287 mmap(0x3427000000, 2181864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3427000000
26287 mprotect(0x3427011000, 2097152, PROT_NONE) =3D 0
26287 mmap(0x3427211000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x11000) =3D 0x3427211000
26287 mmap(0x3427213000, 6888, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3427213000
26287 close(3)                          =3D 0
26287 open("/lib64/libnsl.so.1", O_RDONLY) =3D 3
26287 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240@\340\35=
10\0\0\0@\0\0\0\0\0\0\0\360\265\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0=
\6\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\340\3510\0\0\0@\0\340\3510\0\0\0\370\1=
\0\0\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \33\1\0\0=
\0\0\0 \33\341\3510\0\0\0 \33\341\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\=
0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\340\3510\0\0\0=
\0\0\340\3510\0\0\0\310@\1\0\0\0\0\0\310@\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\=
0\0\6\0\0\0xM\1\0\0\0\0\0xM\1\3520\0\0\0xM\1\3520\0\0\0\310\5\0\0\0\0\0\0=
008-\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250M\1\0\0\0\0\0\250M\1\3=
520\0\0\0\250M\1\3520\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\340\3510\0\0\0008\2\340\351=
0\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0<\33\=
1\0\0\0\0\0<\33\341\3510\0\0\0<\33\341\3510\0\0\0\\\5\0\0\0\0\0\0\\\5\0\0=
\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26287 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147206, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D232, st_size=3D114352, st_atime=3D2012/10/09-12:01:01, st_mtime=3D20=
10/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:44}) =3D 0
26287 mmap(0x30e9e00000, 2194096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9e00000
26287 mprotect(0x30e9e15000, 2093056, PROT_NONE) =3D 0
26287 mmap(0x30ea014000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x14000) =3D 0x30ea014000
26287 mmap(0x30ea016000, 6832, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x30ea016000
26287 close(3)                          =3D 0
26287 open("/lib64/libdl.so.2", O_RDONLY) =3D 3
26287 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\16`\3500=
\0\0\0@\0\0\0\0\0\0\0@R\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0`\3500\0\0\0@\0`\3500\0\0\0\370\1\0\0\0\0\0\0\37=
0\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\300\32\0\0\0\0\0\0\300\3=
2`\3500\0\0\0\300\32`\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0`\3500\0\0\0\0\0`\3500\0\0\=
0\224\37\0\0\0\0\0\0\224\37\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0`-\=
0\0\0\0\0\0`-\200\3500\0\0\0`-\200\3500\0\0\0 \3\0\0\0\0\0\0\240\3\0\0\0\=
0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\240-\0\0\0\0\0\0\240-\200\3500\0\0\0=
\240-\200\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0=
\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2`\3500\0\0\0008\2`\3500\0\0\0 \0\0\=
0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\334\32\0\0\0\0\0\=
0\334\32`\3500\0\0\0\334\32`\3500\0\0\0\264\0\0\0\0\0\0\0\264\0\0\0\0\0\0=
\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26287 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147322, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D48, st_size=3D23360, st_atime=3D2012/10/09-11:13:54, st_mtime=3D2010=
/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26287 mmap(0x30e8600000, 2109696, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8600000
26287 mprotect(0x30e8602000, 2097152, PROT_NONE) =3D 0
26287 mmap(0x30e8802000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x2000) =3D 0x30e8802000
26287 close(3)                          =3D 0
26287 open("/lib64/libm.so.6", O_RDONLY) =3D 3
26287 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`>\240\3510\=
0\0\0@\0\0\0\0\0\0\0\240X\t\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0)\0(\0\6\0\0\=
0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3510\0\0\0@\0\240\3510\0\0\0\370\1\0\0\0\=
0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\360\303\7\0\0\0\=
0\0\360\303\247\3510\0\0\0\360\303\247\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0=
\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3510\=
0\0\0\0\0\240\3510\0\0\0000\22\10\0\0\0\0\0000\22\10\0\0\0\0\0\0\0 \0\0\0=
\0\0\1\0\0\0\6\0\0\0\270\35\10\0\0\0\0\0\270\35\310\3510\0\0\0\270\35\310=
\3510\0\0\0\320\2\0\0\0\0\0\0 \3\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0=
\0\350\35\10\0\0\0\0\0\350\35\310\3510\0\0\0\350\35\310\3510\0\0\0\300\1\=
0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0=
\0\0\0008\2\240\3510\0\0\0008\2\240\3510\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\f\304\7\0\0\0\0\0\f\304\247\3510\0\0\0=
\f\304\247\3510\0\0\0\374\r\0\0\0\0\0\0\374\r\0\0\0\0\0\0\4\0\0\0\0\0\0\0=
Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0"..., 832) =3D 832
26287 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147337, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D1216, st_size=3D615136, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2=
010/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26287 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f2da8f05000
26287 mmap(0x30e9a00000, 2629848, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9a00000
26287 mprotect(0x30e9a82000, 2093056, PROT_NONE) =3D 0
26287 mmap(0x30e9c81000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x81000) =3D 0x30e9c81000
26287 close(3)                          =3D 0
26287 open("/lib64/libcrypt.so.1", O_RDONLY) =3D 3
26287 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\t\300%4=
\0\0\0@\0\0\0\0\0\0\0\30\265\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\=
0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\300%4\0\0\0@\0\300%4\0\0\0\370\1\0\0\0\0\=
0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340}\0\0\0\0\0\0\3=
40}\300%4\0\0\0\340}\300%4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\300%4\0\0\0\0\0\300%4\0\0\=
0\4\205\0\0\0\0\0\0\4\205\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\310\=
215\0\0\0\0\0\0\310\215\340%4\0\0\0\310\215\340%4\0\0\0\250\2\0\0\0\0\0\0=
\370\343\2\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\215\0\0\0\0\0\0\3=
70\215\340%4\0\0\0\370\215\340%4\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\=
0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\300%4\0\0\0008\2=
\300%4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0=
\374}\0\0\0\0\0\0\374}\300%4\0\0\0\374}\300%4\0\0\0\34\1\0\0\0\0\0\0\34\1=
\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26287 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148123, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D96, st_size=3D48600, st_atime=3D2012/10/09-12:01:01, st_mtime=3D2010=
/07/28-03:52:39, st_ctime=3D2012/09/11-14:53:52}) =3D 0
26287 mmap(0x3425c00000, 2322880, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425c00000
26287 mprotect(0x3425c09000, 2093056, PROT_NONE) =3D 0
26287 mmap(0x3425e08000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x8000) =3D 0x3425e08000
26287 mmap(0x3425e0a000, 184768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FI=
XED|MAP_ANONYMOUS, -1, 0) =3D 0x3425e0a000
26287 close(3)                          =3D 0
26287 open("/lib64/libutil.so.1", O_RDONLY) =3D 3
26287 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\16\0(4\=
0\0\0@\0\0\0\0\0\0\0(>\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0\0(4\0\0\0@\0\0(4\0\0\0\370\1\0\0\0\0\0\0\370\1\=
0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340\26\0\0\0\0\0\0\340\26\0(=
4\0\0\0\340\26\0(4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0=
\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0(4\0\0\0\0\0\0(4\0\0\0P\32\0\0\0\=
0\0\0P\32\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\35\0\0\0\0\0\0\3=
40\35 (4\0\0\0\340\35 (4\0\0\0 \3\0\0\0\0\0\0000\3\0\0\0\0\0\0\0\0 \0\0\0=
\0\0\2\0\0\0\6\0\0\0\20\36\0\0\0\0\0\0\20\36 (4\0\0\0\20\36 (4\0\0\0\300\=
1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0=
\0\0\0\0008\2\0(4\0\0\0008\2\0(4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\=
0\0\0\0\0\0P\345td\4\0\0\0\374\26\0\0\0\0\0\0\374\26\0(4\0\0\0\374\26\0(4=
\0\0\0D\0\0\0\0\0\0\0D\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8=
32) =3D 832
26287 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147063, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D40, st_size=3D18152, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2010=
/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:49}) =3D 0
26287 mmap(0x3428000000, 2105616, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3428000000
26287 mprotect(0x3428002000, 2093056, PROT_NONE) =3D 0
26287 mmap(0x3428201000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x1000) =3D 0x3428201000
26287 close(3)                          =3D 0
26287 open("/lib64/libpthread.so.0", O_RDONLY) =3D 3
26287 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240W\240\35=
00\0\0\0@\0\0\0\0\0\0\0\340/\2\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0'\0&\0\6\0=
\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3500\0\0\0@\0\240\3500\0\0\0\370\1\0\0=
\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\240\t\1\0\0\0=
\0\0\240\t\241\3500\0\0\0\240\t\241\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\=
0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3500\0\0=
\0\0\0\240\3500\0\0\0pZ\1\0\0\0\0\0pZ\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\=
6\0\0\0\270[\1\0\0\0\0\0\270[\301\3500\0\0\0\270[\301\3500\0\0\0\230\6\0\=
0\0\0\0\0\270G\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250]\1\0\0\0\0\=
0\250]\301\3500\0\0\0\250]\301\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0=
\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\240\3500\0\0\=
0008\2\240\3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345t=
d\4\0\0\0\274\t\1\0\0\0\0\0\274\t\241\3500\0\0\0\274\t\241\3500\0\0\0\344=
\t\0\0\0\0\0\0\344\t\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =
=3D 832
26287 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147328, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D296, st_size=3D145824, st_atime=3D2012/10/09-11:16:43, st_mtime=3D20=
10/07/28-03:52:41, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26287 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f2da8f04000
26287 mmap(0x30e8a00000, 2204528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8a00000
26287 mprotect(0x30e8a16000, 2093056, PROT_NONE) =3D 0
26287 mmap(0x30e8c15000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x15000) =3D 0x30e8c15000
26287 mmap(0x30e8c17000, 13168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8c17000
26287 close(3)                          =3D 0
26287 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26287 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26287 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26287 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26287 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26287 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26287 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26287 close(3)                          =3D 0
26287 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f2da8f03000
26287 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f2da8f02000
26287 arch_prctl(ARCH_SET_FS, 0x7f2da8f026e0) =3D 0
26287 mprotect(0x3427211000, 4096, PROT_READ) =3D 0
26287 mprotect(0x30ea014000, 4096, PROT_READ) =3D 0
26287 mprotect(0x30e8802000, 4096, PROT_READ) =3D 0
26287 mprotect(0x30e9c81000, 4096, PROT_READ) =3D 0
26287 mprotect(0x3425e08000, 4096, PROT_READ) =3D 0
26287 mprotect(0x3428201000, 4096, PROT_READ) =3D 0
26287 mprotect(0x30e8c15000, 4096, PROT_READ) =3D 0
26287 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26287 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26287 munmap(0x7f2da8f07000, 103979)    =3D 0
26287 set_tid_address(0x7f2da8f02770)   =3D 26287
26287 set_robust_list(0x7f2da8f02780, 0x18) =3D 0
26287 futex(0x7fffb5e6783c, FUTEX_WAKE_PRIVATE, 1) =3D 0
26287 rt_sigaction(SIGRTMIN, {0x30e8a05380, [], SA_RESTORER|SA_SIGINFO, 0=
x30e8a0eb10}, NULL, 8) =3D 0
26287 rt_sigaction(SIGRT_1, {0x30e8a052b0, [], SA_RESTORER|SA_RESTART|SA_=
SIGINFO, 0x30e8a0eb10}, NULL, 8) =3D 0
26287 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) =3D 0
26287 getrlimit(RLIMIT_STACK, {rlim_cur=3D8192*1024, rlim_max=3DRLIM_INFI=
NITY}) =3D 0
26287 rt_sigaction(SIGFPE, {0x1, [FPE], SA_RESTORER|SA_RESTART, 0x30e8230=
2d0}, {SIG_DFL, [], 0}, 8) =3D 0
26287 brk(0)                            =3D 0x16fd000
26287 brk(0x171f000)                    =3D 0x171f000
26287 getuid()                          =3D 0
26287 geteuid()                         =3D 0
26287 getgid()                          =3D 0
26287 getegid()                         =3D 0
26287 mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,=
 -1, 0) =3D 0x7f2da8ee1000
26287 open("/dev/urandom", O_RDONLY)    =3D 3
26287 read(3, "\37z\37{", 4)            =3D 4
26287 close(3)                          =3D 0
26287 stat("/usr/lib64/perl5/site_perl/5.8.7/x86_64-linux-thread-multi", =
0x7fffb5e674f0) =3D -1 ENOENT (No such file or directory)
26287 stat("/usr/lib/perl5/site_perl/5.8.7", 0x7fffb5e674f0) =3D -1 ENOEN=
T (No such file or directory)
26287 stat("/usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi", =
0x7fffb5e674f0) =3D -1 ENOENT (No such file or directory)
26287 stat("/usr/lib/perl5/site_perl/5.8.6", 0x7fffb5e674f0) =3D -1 ENOEN=
T (No such file or directory)
26287 stat("/usr/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi", =
0x7fffb5e674f0) =3D -1 ENOENT (No such file or directory)
26287 stat("/usr/lib/perl5/site_perl/5.8.5", 0x7fffb5e674f0) =3D -1 ENOEN=
T (No such file or directory)
26287 stat("/usr/lib64/perl5/vendor_perl/5.8.7/x86_64-linux-thread-multi"=
, 0x7fffb5e674f0) =3D -1 ENOENT (No such file or directory)
26287 stat("/usr/lib/perl5/vendor_perl/5.8.7", 0x7fffb5e674f0) =3D -1 ENO=
ENT (No such file or directory)
26287 stat("/usr/lib64/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi"=
, 0x7fffb5e674f0) =3D -1 ENOENT (No such file or directory)
26287 stat("/usr/lib/perl5/vendor_perl/5.8.6", 0x7fffb5e674f0) =3D -1 ENO=
ENT (No such file or directory)
26287 stat("/usr/lib64/perl5/vendor_perl/5.8.5/x86_64-linux-thread-multi"=
, 0x7fffb5e674f0) =3D -1 ENOENT (No such file or directory)
26287 stat("/usr/lib/perl5/vendor_perl/5.8.5", 0x7fffb5e674f0) =3D -1 ENO=
ENT (No such file or directory)
26287 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffb5e672b0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26287 lseek(0, 0, SEEK_CUR)             =3D 0
26287 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffb5e672b0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26287 lseek(1, 0, SEEK_CUR)             =3D -1 ESPIPE (Illegal seek)
26287 ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffb5e672c0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26287 lseek(2, 0, SEEK_CUR)             =3D 593659497
26287 open("/dev/null", O_RDONLY)       =3D 3
26287 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffb5e673c0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26287 lseek(3, 0, SEEK_CUR)             =3D 0
26287 fcntl(3, F_SETFD, FD_CLOEXEC)     =3D 0
26287 fstat(3, {st_dev=3Dmakedev(0, 16), st_ino=3D584, st_mode=3DS_IFCHR|=
0666, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
0, st_rdev=3Dmakedev(1, 3), st_atime=3D2012/10/08-11:13:26, st_mtime=3D20=
12/10/08-11:13:26, st_ctime=3D2012/10/08-11:13:27}) =3D 0
26287 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) =3D 0
26287 readlink("/proc/self/exe", "/usr/bin/perl"..., 4095) =3D 13
26287 brk(0x1740000)                    =3D 0x1740000
26287 close(3)                          =3D 0
26287 dup(200)                          =3D 3
26287 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffb5e67290) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26287 lseek(3, 0, SEEK_CUR)             =3D 0
26287 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26287 dup2(3, 0)                        =3D 0
26287 close(3)                          =3D 0
26287 fcntl(0, F_SETFD, 0)              =3D 0
26287 fstat(0, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26287 stat("/var/run/xen-hotplug/block", {st_dev=3Dmakedev(8, 2), st_ino=3D=
2801738, st_mode=3DS_IFREG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st=
_blksize=3D4096, st_blocks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:=
24, st_mtime=3D2012/10/09-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D =
0
26287 exit_group(0)                     =3D ?
27813 <... read resumed> "", 128)       =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], WNOHANG, NUL=
L) =3D 26287
27813 wait4(-1, 0x7fffb0100a64, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0)                   =3D 0
27813 close(3)                          =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 write(2, "+ rightfile=3D\n", 13)    =3D 13
27813 write(2, "+ '[' x =3D xy ']'\n", 17) =3D 17
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ true\n", 7)           =3D 7
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ eval 'exec 200>>/var/run/xen-hotplug/block'\n", 46) =3D=
 46
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 write(2, "++ exec\n", 8)          =3D 8
27813 open("/var/run/xen-hotplug/block", O_WRONLY|O_CREAT|O_APPEND, 0666)=
 =3D 3
27813 fcntl(200, F_GETFD)               =3D 0
27813 fcntl(200, F_DUPFD, 10)           =3D 10
27813 fcntl(200, F_GETFD)               =3D 0
27813 dup2(3, 200)                      =3D 200
27813 close(3)                          =3D 0
27813 dup2(10, 200)                     =3D 200
27813 fcntl(10, F_GETFD)                =3D 0
27813 close(10)                         =3D 0
27813 write(2, "+ flock -x 200\n", 15)  =3D 15
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [INT CHLD], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [INT CHLD], NULL, 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26288
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26288 close(255 
27813 rt_sigprocmask(SIG_BLOCK, [CHLD],  
26288 <... close resumed> )             =3D 0
27813 <... rt_sigprocmask resumed> [], 8) =3D 0
26288 rt_sigprocmask(SIG_SETMASK, [],  
27813 rt_sigprocmask(SIG_SETMASK, [],  
26288 <... rt_sigprocmask resumed> NULL, 8) =3D 0
27813 <... rt_sigprocmask resumed> NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD],  
26288 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 <... rt_sigprocmask resumed> [], 8) =3D 0
26288 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0},  
26288 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 <... rt_sigaction resumed> {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}=
, 8) =3D 0
26288 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
27813 wait4(-1,  
26288 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26288 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26288 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26288 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26288 execve("/usr/bin/flock", ["flock", "-x", "200"], ["SUBSYSTEM=3Dxen-=
backend", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D=
/usr/bin:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:=
/usr/sbin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dx=
en-backend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3D=
backend/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "S=
HLVL=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/flock"]) =3D 0=

26288 brk(0)                            =3D 0x22d3000
26288 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f6874a70000
26288 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f6874a6f000
26288 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26288 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26288 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26288 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7f6874a55000=

26288 close(3)                          =3D 0
26288 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26288 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26288 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26288 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26288 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26288 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26288 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26288 close(3)                          =3D 0
26288 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f6874a54000
26288 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f6874a53000
26288 arch_prctl(ARCH_SET_FS, 0x7f6874a536e0) =3D 0
26288 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26288 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26288 munmap(0x7f6874a55000, 103979)    =3D 0
26288 flock(200, LOCK_EX)               =3D 0
26288 exit_group(0)                     =3D ?
27813 <... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], 0,=
 NULL) =3D 26288
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, 0x7fffb0100a24, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0xffffffffffffffff)  =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 pipe([3, 4])                      =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26289
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {0=
x436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26289 close(255 
27813 close(4 
26289 <... close resumed> )             =3D 0
27813 <... close resumed> )             =3D 0
27813 read(3,  
26289 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26289 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26289 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26289 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26289 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26289 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26289 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26289 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {S=
IG_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26289 rt_sigaction(SIGINT, {0x4481f0, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26289 dup2(4, 1)                        =3D 1
26289 close(4)                          =3D 0
26289 close(3)                          =3D 0
26289 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26289 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26289 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26289 write(2, "++ perl -e '\n            open STDIN, \"<&200\" or die $!=
;\n            my $fd_inum =3D (stat STDIN)[1]; die $! unless defined $fd=
_inum;\n            my $file_inum =3D (stat $ARGV[0])[1];\n            pr=
int \"y\\n\" if $fd_inum eq $file_inum;\n", 230) =3D 230
26289 write(2, "                             ' /var/run/xen-hotplug/block=
\n", 58) =3D 58
26289 stat(".", {st_dev=3Dmakedev(8, 2), st_ino=3D2, st_mode=3DS_IFDIR|07=
55, st_nlink=3D24, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
8, st_size=3D4096, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2012/10/08-=
11:13:38, st_ctime=3D2012/10/08-11:13:38}) =3D 0
26289 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26289 access("/usr/bin/perl", X_OK)     =3D 0
26289 access("/usr/bin/perl", R_OK)     =3D 0
26289 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26289 access("/usr/bin/perl", X_OK)     =3D 0
26289 access("/usr/bin/perl", R_OK)     =3D 0
26289 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
481f0, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26289 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26289 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26289 execve("/usr/bin/perl", ["perl", "-e", "\n            open STDIN, \=
"<&200\" or die $!;\n            my $fd_inum =3D (stat STDIN)[1]; die $! =
unless defined $fd_inum;\n            my $file_inum =3D (stat $ARGV[0])[1=
];\n            print \"y\\n\" if $fd_inum eq $file_inum;\n              =
               ", "/var/run/xen-hotplug/block"], ["SUBSYSTEM=3Dxen-backen=
d", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D/usr/b=
in:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:/usr/s=
bin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dxen-bac=
kend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3Dback=
end/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "SHLVL=
=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/perl"]) =3D 0
26289 brk(0)                            =3D 0xf52000
26289 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f8e69db2000
26289 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f8e69db1000
26289 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26289 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64/libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26289 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64", 0x7fffd8ac45f0) =3D -1 ENOENT (No such file or directory)
26289 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/lib=
perl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26289 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls", 0=
x7fffd8ac45f0) =3D -1 ENOENT (No such file or directory)
26289 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64/=
libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26289 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64"=
, 0x7fffd8ac45f0) =3D -1 ENOENT (No such file or directory)
26289 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl=
=2Eso", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26289 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE", 0x7ff=
fd8ac45f0) =3D -1 ENOENT (No such file or directory)
26289 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26289 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26289 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7f8e69d97000=

26289 close(3)                          =3D 0
26289 open("/usr/lib64/libperl.so", O_RDONLY) =3D 3
26289 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\34\203%=
4\0\0\0@\0\0\0\0\0\0\0\360;\23\0\0\0\0\0\0\0\0\0@\0008\0\5\0@\0\35\0\34\0=
\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\200%4\0\0\0\0\0\200%4\0\0\0T\260\22\=
0\0\0\0\0T\260\22\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0X\260\22\0\0\0\=
0\0X\260\262%4\0\0\0X\260\262%4\0\0\0\250\201\0\0\0\0\0\0\350\242\0\0\0\0=
\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\265\22\0\0\0\0\0\370\265\262%4\0\=
0\0\370\265\262%4\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\=
0\0P\345td\4\0\0\0\250u\21\0\0\0\0\0\250u\221%4\0\0\0\250u\221%4\0\0\0D@\=
0\0\0\0\0\0D@\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\7\4\0\0\360\0\0\0\0\1\0\0\16\0\0\0\0\0\0@\0\200\203\200\225\1\22\=
264\3\31\200l\0\32\0 \5\201\0\240\3\2B\0\200\21R \0\22\0\0\16P\20#\10\216=
\334\30\211\"\0\10 \200\3B\220@\0\1\206\20\30\2\3\21\203$!\312A0\224Y\200=
\27\0\242\26\10\24R@\10\200\220\20A\10\0\220\1\200\206\2\10\304\30i\0\220=
\1\1\202\200\22\20\0\n\1H\0\n\2001J \6\31@L\207\20\10\0000\10(\200\2\0\4\=
251t\"\262\310!\212\240\320\"\0\t"..., 832) =3D 832
26289 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2839671, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D2480, st_size=3D1262384, st_atime=3D2012/10/09-12:04:35, st_mtime=3D=
2012/09/11-12:45:05, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26289 mmap(0x3425800000, 3363648, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425800000
26289 mprotect(0x342592c000, 2093056, PROT_NONE) =3D 0
26289 mmap(0x3425b2b000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x12b000) =3D 0x3425b2b000
26289 mmap(0x3425b34000, 4928, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3425b34000
26289 close(3)                          =3D 0
26289 open("/lib64/libresolv.so.2", O_RDONLY) =3D 3
26289 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\2402\0'4\0\=
0\0@\0\0\0\0\0\0\0@a\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\5\0=
\0\0@\0\0\0\0\0\0\0@\0\0'4\0\0\0@\0\0'4\0\0\0\370\1\0\0\0\0\0\0\370\1\0\0=
\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \361\0\0\0\0\0\0 \361\0'4\0\0\0=
 \361\0'4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\=
0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0'4\0\0\0\0\0\0'4\0\0\0$\10\1\0\0\0\0\0$\10=
\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\24\1\0\0\0\0\0\340\24!'4\=
0\0\0\340\24!'4\0\0\0\340\r\0\0\0\0\0\0\0106\0\0\0\0\0\0\0\0 \0\0\0\0\0\2=
\0\0\0\6\0\0\0\350\35\1\0\0\0\0\0\350\35!'4\0\0\0\350\35!'4\0\0\0\300\1\0=
\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\=
0\0\0008\2\0'4\0\0\0008\2\0'4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0=
\0\0\0\0P\345td\4\0\0\0<\361\0\0\0\0\0\0<\361\0'4\0\0\0<\361\0'4\0\0\0,\3=
\0\0\0\0\0\0,\3\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 8=
32
26289 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148119, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D192, st_size=3D92736, st_atime=3D2012/10/09-11:16:43, st_mtime=3D201=
0/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:42}) =3D 0
26289 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f8e69d96000
26289 mmap(0x3427000000, 2181864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3427000000
26289 mprotect(0x3427011000, 2097152, PROT_NONE) =3D 0
26289 mmap(0x3427211000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x11000) =3D 0x3427211000
26289 mmap(0x3427213000, 6888, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3427213000
26289 close(3)                          =3D 0
26289 open("/lib64/libnsl.so.1", O_RDONLY) =3D 3
26289 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240@\340\35=
10\0\0\0@\0\0\0\0\0\0\0\360\265\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0=
\6\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\340\3510\0\0\0@\0\340\3510\0\0\0\370\1=
\0\0\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \33\1\0\0=
\0\0\0 \33\341\3510\0\0\0 \33\341\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\=
0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\340\3510\0\0\0=
\0\0\340\3510\0\0\0\310@\1\0\0\0\0\0\310@\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\=
0\0\6\0\0\0xM\1\0\0\0\0\0xM\1\3520\0\0\0xM\1\3520\0\0\0\310\5\0\0\0\0\0\0=
008-\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250M\1\0\0\0\0\0\250M\1\3=
520\0\0\0\250M\1\3520\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\340\3510\0\0\0008\2\340\351=
0\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0<\33\=
1\0\0\0\0\0<\33\341\3510\0\0\0<\33\341\3510\0\0\0\\\5\0\0\0\0\0\0\\\5\0\0=
\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26289 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147206, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D232, st_size=3D114352, st_atime=3D2012/10/09-12:01:01, st_mtime=3D20=
10/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:44}) =3D 0
26289 mmap(0x30e9e00000, 2194096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9e00000
26289 mprotect(0x30e9e15000, 2093056, PROT_NONE) =3D 0
26289 mmap(0x30ea014000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x14000) =3D 0x30ea014000
26289 mmap(0x30ea016000, 6832, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x30ea016000
26289 close(3)                          =3D 0
26289 open("/lib64/libdl.so.2", O_RDONLY) =3D 3
26289 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\16`\3500=
\0\0\0@\0\0\0\0\0\0\0@R\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0`\3500\0\0\0@\0`\3500\0\0\0\370\1\0\0\0\0\0\0\37=
0\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\300\32\0\0\0\0\0\0\300\3=
2`\3500\0\0\0\300\32`\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0`\3500\0\0\0\0\0`\3500\0\0\=
0\224\37\0\0\0\0\0\0\224\37\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0`-\=
0\0\0\0\0\0`-\200\3500\0\0\0`-\200\3500\0\0\0 \3\0\0\0\0\0\0\240\3\0\0\0\=
0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\240-\0\0\0\0\0\0\240-\200\3500\0\0\0=
\240-\200\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0=
\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2`\3500\0\0\0008\2`\3500\0\0\0 \0\0\=
0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\334\32\0\0\0\0\0\=
0\334\32`\3500\0\0\0\334\32`\3500\0\0\0\264\0\0\0\0\0\0\0\264\0\0\0\0\0\0=
\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26289 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147322, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D48, st_size=3D23360, st_atime=3D2012/10/09-11:13:54, st_mtime=3D2010=
/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26289 mmap(0x30e8600000, 2109696, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8600000
26289 mprotect(0x30e8602000, 2097152, PROT_NONE) =3D 0
26289 mmap(0x30e8802000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x2000) =3D 0x30e8802000
26289 close(3)                          =3D 0
26289 open("/lib64/libm.so.6", O_RDONLY) =3D 3
26289 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`>\240\3510\=
0\0\0@\0\0\0\0\0\0\0\240X\t\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0)\0(\0\6\0\0\=
0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3510\0\0\0@\0\240\3510\0\0\0\370\1\0\0\0\=
0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\360\303\7\0\0\0\=
0\0\360\303\247\3510\0\0\0\360\303\247\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0=
\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3510\=
0\0\0\0\0\240\3510\0\0\0000\22\10\0\0\0\0\0000\22\10\0\0\0\0\0\0\0 \0\0\0=
\0\0\1\0\0\0\6\0\0\0\270\35\10\0\0\0\0\0\270\35\310\3510\0\0\0\270\35\310=
\3510\0\0\0\320\2\0\0\0\0\0\0 \3\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0=
\0\350\35\10\0\0\0\0\0\350\35\310\3510\0\0\0\350\35\310\3510\0\0\0\300\1\=
0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0=
\0\0\0008\2\240\3510\0\0\0008\2\240\3510\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\f\304\7\0\0\0\0\0\f\304\247\3510\0\0\0=
\f\304\247\3510\0\0\0\374\r\0\0\0\0\0\0\374\r\0\0\0\0\0\0\4\0\0\0\0\0\0\0=
Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0"..., 832) =3D 832
26289 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147337, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D1216, st_size=3D615136, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2=
010/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26289 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f8e69d95000
26289 mmap(0x30e9a00000, 2629848, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9a00000
26289 mprotect(0x30e9a82000, 2093056, PROT_NONE) =3D 0
26289 mmap(0x30e9c81000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x81000) =3D 0x30e9c81000
26289 close(3)                          =3D 0
26289 open("/lib64/libcrypt.so.1", O_RDONLY) =3D 3
26289 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\t\300%4=
\0\0\0@\0\0\0\0\0\0\0\30\265\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\=
0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\300%4\0\0\0@\0\300%4\0\0\0\370\1\0\0\0\0\=
0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340}\0\0\0\0\0\0\3=
40}\300%4\0\0\0\340}\300%4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\300%4\0\0\0\0\0\300%4\0\0\=
0\4\205\0\0\0\0\0\0\4\205\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\310\=
215\0\0\0\0\0\0\310\215\340%4\0\0\0\310\215\340%4\0\0\0\250\2\0\0\0\0\0\0=
\370\343\2\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\215\0\0\0\0\0\0\3=
70\215\340%4\0\0\0\370\215\340%4\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\=
0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\300%4\0\0\0008\2=
\300%4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0=
\374}\0\0\0\0\0\0\374}\300%4\0\0\0\374}\300%4\0\0\0\34\1\0\0\0\0\0\0\34\1=
\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26289 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148123, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D96, st_size=3D48600, st_atime=3D2012/10/09-12:01:01, st_mtime=3D2010=
/07/28-03:52:39, st_ctime=3D2012/09/11-14:53:52}) =3D 0
26289 mmap(0x3425c00000, 2322880, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425c00000
26289 mprotect(0x3425c09000, 2093056, PROT_NONE) =3D 0
26289 mmap(0x3425e08000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x8000) =3D 0x3425e08000
26289 mmap(0x3425e0a000, 184768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FI=
XED|MAP_ANONYMOUS, -1, 0) =3D 0x3425e0a000
26289 close(3)                          =3D 0
26289 open("/lib64/libutil.so.1", O_RDONLY) =3D 3
26289 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\16\0(4\=
0\0\0@\0\0\0\0\0\0\0(>\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0\0(4\0\0\0@\0\0(4\0\0\0\370\1\0\0\0\0\0\0\370\1\=
0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340\26\0\0\0\0\0\0\340\26\0(=
4\0\0\0\340\26\0(4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0=
\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0(4\0\0\0\0\0\0(4\0\0\0P\32\0\0\0\=
0\0\0P\32\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\35\0\0\0\0\0\0\3=
40\35 (4\0\0\0\340\35 (4\0\0\0 \3\0\0\0\0\0\0000\3\0\0\0\0\0\0\0\0 \0\0\0=
\0\0\2\0\0\0\6\0\0\0\20\36\0\0\0\0\0\0\20\36 (4\0\0\0\20\36 (4\0\0\0\300\=
1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0=
\0\0\0\0008\2\0(4\0\0\0008\2\0(4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\=
0\0\0\0\0\0P\345td\4\0\0\0\374\26\0\0\0\0\0\0\374\26\0(4\0\0\0\374\26\0(4=
\0\0\0D\0\0\0\0\0\0\0D\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8=
32) =3D 832
26289 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147063, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D40, st_size=3D18152, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2010=
/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:49}) =3D 0
26289 mmap(0x3428000000, 2105616, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3428000000
26289 mprotect(0x3428002000, 2093056, PROT_NONE) =3D 0
26289 mmap(0x3428201000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x1000) =3D 0x3428201000
26289 close(3)                          =3D 0
26289 open("/lib64/libpthread.so.0", O_RDONLY) =3D 3
26289 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240W\240\35=
00\0\0\0@\0\0\0\0\0\0\0\340/\2\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0'\0&\0\6\0=
\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3500\0\0\0@\0\240\3500\0\0\0\370\1\0\0=
\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\240\t\1\0\0\0=
\0\0\240\t\241\3500\0\0\0\240\t\241\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\=
0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3500\0\0=
\0\0\0\240\3500\0\0\0pZ\1\0\0\0\0\0pZ\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\=
6\0\0\0\270[\1\0\0\0\0\0\270[\301\3500\0\0\0\270[\301\3500\0\0\0\230\6\0\=
0\0\0\0\0\270G\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250]\1\0\0\0\0\=
0\250]\301\3500\0\0\0\250]\301\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0=
\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\240\3500\0\0\=
0008\2\240\3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345t=
d\4\0\0\0\274\t\1\0\0\0\0\0\274\t\241\3500\0\0\0\274\t\241\3500\0\0\0\344=
\t\0\0\0\0\0\0\344\t\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =
=3D 832
26289 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147328, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D296, st_size=3D145824, st_atime=3D2012/10/09-11:16:43, st_mtime=3D20=
10/07/28-03:52:41, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26289 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f8e69d94000
26289 mmap(0x30e8a00000, 2204528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8a00000
26289 mprotect(0x30e8a16000, 2093056, PROT_NONE) =3D 0
26289 mmap(0x30e8c15000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x15000) =3D 0x30e8c15000
26289 mmap(0x30e8c17000, 13168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8c17000
26289 close(3)                          =3D 0
26289 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26289 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26289 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26289 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26289 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26289 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26289 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26289 close(3)                          =3D 0
26289 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f8e69d93000
26289 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f8e69d92000
26289 arch_prctl(ARCH_SET_FS, 0x7f8e69d926e0) =3D 0
26289 mprotect(0x3427211000, 4096, PROT_READ) =3D 0
26289 mprotect(0x30ea014000, 4096, PROT_READ) =3D 0
26289 mprotect(0x30e8802000, 4096, PROT_READ) =3D 0
26289 mprotect(0x30e9c81000, 4096, PROT_READ) =3D 0
26289 mprotect(0x3425e08000, 4096, PROT_READ) =3D 0
26289 mprotect(0x3428201000, 4096, PROT_READ) =3D 0
26289 mprotect(0x30e8c15000, 4096, PROT_READ) =3D 0
26289 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26289 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26289 munmap(0x7f8e69d97000, 103979)    =3D 0
26289 set_tid_address(0x7f8e69d92770)   =3D 26289
26289 set_robust_list(0x7f8e69d92780, 0x18) =3D 0
26289 futex(0x7fffd8ac511c, FUTEX_WAKE_PRIVATE, 1) =3D 0
26289 rt_sigaction(SIGRTMIN, {0x30e8a05380, [], SA_RESTORER|SA_SIGINFO, 0=
x30e8a0eb10}, NULL, 8) =3D 0
26289 rt_sigaction(SIGRT_1, {0x30e8a052b0, [], SA_RESTORER|SA_RESTART|SA_=
SIGINFO, 0x30e8a0eb10}, NULL, 8) =3D 0
26289 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) =3D 0
26289 getrlimit(RLIMIT_STACK, {rlim_cur=3D8192*1024, rlim_max=3DRLIM_INFI=
NITY}) =3D 0
26289 rt_sigaction(SIGFPE, {0x1, [FPE], SA_RESTORER|SA_RESTART, 0x30e8230=
2d0}, {SIG_DFL, [], 0}, 8) =3D 0
26289 brk(0)                            =3D 0xf52000
26289 brk(0xf74000)                     =3D 0xf74000
26289 getuid()                          =3D 0
26289 geteuid()                         =3D 0
26289 getgid()                          =3D 0
26289 getegid()                         =3D 0
26289 mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,=
 -1, 0) =3D 0x7f8e69d71000
26289 open("/dev/urandom", O_RDONLY)    =3D 3
26289 read(3, "\340\re*", 4)            =3D 4
26289 close(3)                          =3D 0
26289 stat("/usr/lib64/perl5/site_perl/5.8.7/x86_64-linux-thread-multi", =
0x7fffd8ac4dd0) =3D -1 ENOENT (No such file or directory)
26289 stat("/usr/lib/perl5/site_perl/5.8.7", 0x7fffd8ac4dd0) =3D -1 ENOEN=
T (No such file or directory)
26289 stat("/usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi", =
0x7fffd8ac4dd0) =3D -1 ENOENT (No such file or directory)
26289 stat("/usr/lib/perl5/site_perl/5.8.6", 0x7fffd8ac4dd0) =3D -1 ENOEN=
T (No such file or directory)
26289 stat("/usr/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi", =
0x7fffd8ac4dd0) =3D -1 ENOENT (No such file or directory)
26289 stat("/usr/lib/perl5/site_perl/5.8.5", 0x7fffd8ac4dd0) =3D -1 ENOEN=
T (No such file or directory)
26289 stat("/usr/lib64/perl5/vendor_perl/5.8.7/x86_64-linux-thread-multi"=
, 0x7fffd8ac4dd0) =3D -1 ENOENT (No such file or directory)
26289 stat("/usr/lib/perl5/vendor_perl/5.8.7", 0x7fffd8ac4dd0) =3D -1 ENO=
ENT (No such file or directory)
26289 stat("/usr/lib64/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi"=
, 0x7fffd8ac4dd0) =3D -1 ENOENT (No such file or directory)
26289 stat("/usr/lib/perl5/vendor_perl/5.8.6", 0x7fffd8ac4dd0) =3D -1 ENO=
ENT (No such file or directory)
26289 stat("/usr/lib64/perl5/vendor_perl/5.8.5/x86_64-linux-thread-multi"=
, 0x7fffd8ac4dd0) =3D -1 ENOENT (No such file or directory)
26289 stat("/usr/lib/perl5/vendor_perl/5.8.5", 0x7fffd8ac4dd0) =3D -1 ENO=
ENT (No such file or directory)
26289 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffd8ac4b90) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26289 lseek(0, 0, SEEK_CUR)             =3D 0
26289 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffd8ac4b90) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26289 lseek(1, 0, SEEK_CUR)             =3D -1 ESPIPE (Illegal seek)
26289 ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffd8ac4ba0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26289 lseek(2, 0, SEEK_CUR)             =3D 593659891
26289 open("/dev/null", O_RDONLY)       =3D 3
26289 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffd8ac4ca0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26289 lseek(3, 0, SEEK_CUR)             =3D 0
26289 fcntl(3, F_SETFD, FD_CLOEXEC)     =3D 0
26289 fstat(3, {st_dev=3Dmakedev(0, 16), st_ino=3D584, st_mode=3DS_IFCHR|=
0666, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
0, st_rdev=3Dmakedev(1, 3), st_atime=3D2012/10/08-11:13:26, st_mtime=3D20=
12/10/08-11:13:26, st_ctime=3D2012/10/08-11:13:27}) =3D 0
26289 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) =3D 0
26289 readlink("/proc/self/exe", "/usr/bin/perl"..., 4095) =3D 13
26289 brk(0xf95000)                     =3D 0xf95000
26289 close(3)                          =3D 0
26289 dup(200)                          =3D 3
26289 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffd8ac4b70) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26289 lseek(3, 0, SEEK_CUR)             =3D 0
26289 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26289 dup2(3, 0)                        =3D 0
26289 close(3)                          =3D 0
26289 fcntl(0, F_SETFD, 0)              =3D 0
26289 fstat(0, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26289 stat("/var/run/xen-hotplug/block", {st_dev=3Dmakedev(8, 2), st_ino=3D=
2801738, st_mode=3DS_IFREG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st=
_blksize=3D4096, st_blocks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:=
24, st_mtime=3D2012/10/09-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D =
0
26289 exit_group(0)                     =3D ?
27813 <... read resumed> "", 128)       =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], WNOHANG, NUL=
L) =3D 26289
27813 wait4(-1, 0x7fffb0100a64, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0)                   =3D 0
27813 close(3)                          =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 write(2, "+ rightfile=3D\n", 13)    =3D 13
27813 write(2, "+ '[' x =3D xy ']'\n", 17) =3D 17
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ true\n", 7)           =3D 7
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ eval 'exec 200>>/var/run/xen-hotplug/block'\n", 46) =3D=
 46
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 write(2, "++ exec\n", 8)          =3D 8
27813 open("/var/run/xen-hotplug/block", O_WRONLY|O_CREAT|O_APPEND, 0666)=
 =3D 3
27813 fcntl(200, F_GETFD)               =3D 0
27813 fcntl(200, F_DUPFD, 10)           =3D 10
27813 fcntl(200, F_GETFD)               =3D 0
27813 dup2(3, 200)                      =3D 200
27813 close(3)                          =3D 0
27813 dup2(10, 200)                     =3D 200
27813 fcntl(10, F_GETFD)                =3D 0
27813 close(10)                         =3D 0
27813 write(2, "+ flock -x 200\n", 15)  =3D 15
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [INT CHLD], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [INT CHLD], NULL, 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26290
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26290 close(255 
27813 rt_sigprocmask(SIG_BLOCK, [CHLD],  
26290 <... close resumed> )             =3D 0
27813 <... rt_sigprocmask resumed> [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [],  
26290 rt_sigprocmask(SIG_SETMASK, [],  
27813 <... rt_sigprocmask resumed> NULL, 8) =3D 0
26290 <... rt_sigprocmask resumed> NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
26290 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0},  
26290 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
27813 <... rt_sigaction resumed> {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}=
, 8) =3D 0
26290 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 wait4(-1,  
26290 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
26290 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26290 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26290 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26290 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26290 execve("/usr/bin/flock", ["flock", "-x", "200"], ["SUBSYSTEM=3Dxen-=
backend", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D=
/usr/bin:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:=
/usr/sbin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dx=
en-backend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3D=
backend/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "S=
HLVL=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/flock"]) =3D 0=

26290 brk(0)                            =3D 0x1672000
26290 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f9f578cc000
26290 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f9f578cb000
26290 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26290 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26290 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26290 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7f9f578b1000=

26290 close(3)                          =3D 0
26290 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26290 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26290 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26290 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26290 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26290 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26290 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26290 close(3)                          =3D 0
26290 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f9f578b0000
26290 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f9f578af000
26290 arch_prctl(ARCH_SET_FS, 0x7f9f578af6e0) =3D 0
26290 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26290 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26290 munmap(0x7f9f578b1000, 103979)    =3D 0
26290 flock(200, LOCK_EX)               =3D 0
26290 exit_group(0)                     =3D ?
27813 <... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], 0,=
 NULL) =3D 26290
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, 0x7fffb0100a24, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0xffffffffffffffff)  =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 pipe([3, 4])                      =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26291
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {0=
x436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26291 close(255 
27813 close(4 
26291 <... close resumed> )             =3D 0
27813 <... close resumed> )             =3D 0
27813 read(3,  
26291 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26291 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26291 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26291 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26291 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26291 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26291 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26291 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {S=
IG_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26291 rt_sigaction(SIGINT, {0x4481f0, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26291 dup2(4, 1)                        =3D 1
26291 close(4)                          =3D 0
26291 close(3)                          =3D 0
26291 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26291 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26291 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26291 write(2, "++ perl -e '\n            open STDIN, \"<&200\" or die $!=
;\n            my $fd_inum =3D (stat STDIN)[1]; die $! unless defined $fd=
_inum;\n            my $file_inum =3D (stat $ARGV[0])[1];\n            pr=
int \"y\\n\" if $fd_inum eq $file_inum;\n", 230) =3D 230
26291 write(2, "                             ' /var/run/xen-hotplug/block=
\n", 58) =3D 58
26291 stat(".", {st_dev=3Dmakedev(8, 2), st_ino=3D2, st_mode=3DS_IFDIR|07=
55, st_nlink=3D24, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
8, st_size=3D4096, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2012/10/08-=
11:13:38, st_ctime=3D2012/10/08-11:13:38}) =3D 0
26291 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26291 access("/usr/bin/perl", X_OK)     =3D 0
26291 access("/usr/bin/perl", R_OK)     =3D 0
26291 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26291 access("/usr/bin/perl", X_OK)     =3D 0
26291 access("/usr/bin/perl", R_OK)     =3D 0
26291 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
481f0, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26291 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26291 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26291 execve("/usr/bin/perl", ["perl", "-e", "\n            open STDIN, \=
"<&200\" or die $!;\n            my $fd_inum =3D (stat STDIN)[1]; die $! =
unless defined $fd_inum;\n            my $file_inum =3D (stat $ARGV[0])[1=
];\n            print \"y\\n\" if $fd_inum eq $file_inum;\n              =
               ", "/var/run/xen-hotplug/block"], ["SUBSYSTEM=3Dxen-backen=
d", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D/usr/b=
in:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:/usr/s=
bin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dxen-bac=
kend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3Dback=
end/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "SHLVL=
=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/perl"]) =3D 0
26291 brk(0)                            =3D 0x1cbc000
26291 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f2692cc7000
26291 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f2692cc6000
26291 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26291 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64/libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26291 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64", 0x7fffcf663710) =3D -1 ENOENT (No such file or directory)
26291 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/lib=
perl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26291 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls", 0=
x7fffcf663710) =3D -1 ENOENT (No such file or directory)
26291 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64/=
libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26291 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64"=
, 0x7fffcf663710) =3D -1 ENOENT (No such file or directory)
26291 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl=
=2Eso", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26291 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE", 0x7ff=
fcf663710) =3D -1 ENOENT (No such file or directory)
26291 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26291 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26291 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7f2692cac000=

26291 close(3)                          =3D 0
26291 open("/usr/lib64/libperl.so", O_RDONLY) =3D 3
26291 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\34\203%=
4\0\0\0@\0\0\0\0\0\0\0\360;\23\0\0\0\0\0\0\0\0\0@\0008\0\5\0@\0\35\0\34\0=
\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\200%4\0\0\0\0\0\200%4\0\0\0T\260\22\=
0\0\0\0\0T\260\22\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0X\260\22\0\0\0\=
0\0X\260\262%4\0\0\0X\260\262%4\0\0\0\250\201\0\0\0\0\0\0\350\242\0\0\0\0=
\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\265\22\0\0\0\0\0\370\265\262%4\0\=
0\0\370\265\262%4\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\=
0\0P\345td\4\0\0\0\250u\21\0\0\0\0\0\250u\221%4\0\0\0\250u\221%4\0\0\0D@\=
0\0\0\0\0\0D@\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\7\4\0\0\360\0\0\0\0\1\0\0\16\0\0\0\0\0\0@\0\200\203\200\225\1\22\=
264\3\31\200l\0\32\0 \5\201\0\240\3\2B\0\200\21R \0\22\0\0\16P\20#\10\216=
\334\30\211\"\0\10 \200\3B\220@\0\1\206\20\30\2\3\21\203$!\312A0\224Y\200=
\27\0\242\26\10\24R@\10\200\220\20A\10\0\220\1\200\206\2\10\304\30i\0\220=
\1\1\202\200\22\20\0\n\1H\0\n\2001J \6\31@L\207\20\10\0000\10(\200\2\0\4\=
251t\"\262\310!\212\240\320\"\0\t"..., 832) =3D 832
26291 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2839671, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D2480, st_size=3D1262384, st_atime=3D2012/10/09-12:04:35, st_mtime=3D=
2012/09/11-12:45:05, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26291 mmap(0x3425800000, 3363648, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425800000
26291 mprotect(0x342592c000, 2093056, PROT_NONE) =3D 0
26291 mmap(0x3425b2b000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x12b000) =3D 0x3425b2b000
26291 mmap(0x3425b34000, 4928, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3425b34000
26291 close(3)                          =3D 0
26291 open("/lib64/libresolv.so.2", O_RDONLY) =3D 3
26291 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\2402\0'4\0\=
0\0@\0\0\0\0\0\0\0@a\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\5\0=
\0\0@\0\0\0\0\0\0\0@\0\0'4\0\0\0@\0\0'4\0\0\0\370\1\0\0\0\0\0\0\370\1\0\0=
\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \361\0\0\0\0\0\0 \361\0'4\0\0\0=
 \361\0'4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\=
0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0'4\0\0\0\0\0\0'4\0\0\0$\10\1\0\0\0\0\0$\10=
\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\24\1\0\0\0\0\0\340\24!'4\=
0\0\0\340\24!'4\0\0\0\340\r\0\0\0\0\0\0\0106\0\0\0\0\0\0\0\0 \0\0\0\0\0\2=
\0\0\0\6\0\0\0\350\35\1\0\0\0\0\0\350\35!'4\0\0\0\350\35!'4\0\0\0\300\1\0=
\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\=
0\0\0008\2\0'4\0\0\0008\2\0'4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0=
\0\0\0\0P\345td\4\0\0\0<\361\0\0\0\0\0\0<\361\0'4\0\0\0<\361\0'4\0\0\0,\3=
\0\0\0\0\0\0,\3\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 8=
32
26291 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148119, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D192, st_size=3D92736, st_atime=3D2012/10/09-11:16:43, st_mtime=3D201=
0/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:42}) =3D 0
26291 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f2692cab000
26291 mmap(0x3427000000, 2181864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3427000000
26291 mprotect(0x3427011000, 2097152, PROT_NONE) =3D 0
26291 mmap(0x3427211000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x11000) =3D 0x3427211000
26291 mmap(0x3427213000, 6888, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3427213000
26291 close(3)                          =3D 0
26291 open("/lib64/libnsl.so.1", O_RDONLY) =3D 3
26291 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240@\340\35=
10\0\0\0@\0\0\0\0\0\0\0\360\265\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0=
\6\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\340\3510\0\0\0@\0\340\3510\0\0\0\370\1=
\0\0\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \33\1\0\0=
\0\0\0 \33\341\3510\0\0\0 \33\341\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\=
0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\340\3510\0\0\0=
\0\0\340\3510\0\0\0\310@\1\0\0\0\0\0\310@\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\=
0\0\6\0\0\0xM\1\0\0\0\0\0xM\1\3520\0\0\0xM\1\3520\0\0\0\310\5\0\0\0\0\0\0=
008-\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250M\1\0\0\0\0\0\250M\1\3=
520\0\0\0\250M\1\3520\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\340\3510\0\0\0008\2\340\351=
0\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0<\33\=
1\0\0\0\0\0<\33\341\3510\0\0\0<\33\341\3510\0\0\0\\\5\0\0\0\0\0\0\\\5\0\0=
\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26291 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147206, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D232, st_size=3D114352, st_atime=3D2012/10/09-12:01:01, st_mtime=3D20=
10/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:44}) =3D 0
26291 mmap(0x30e9e00000, 2194096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9e00000
26291 mprotect(0x30e9e15000, 2093056, PROT_NONE) =3D 0
26291 mmap(0x30ea014000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x14000) =3D 0x30ea014000
26291 mmap(0x30ea016000, 6832, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x30ea016000
26291 close(3)                          =3D 0
26291 open("/lib64/libdl.so.2", O_RDONLY) =3D 3
26291 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\16`\3500=
\0\0\0@\0\0\0\0\0\0\0@R\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0`\3500\0\0\0@\0`\3500\0\0\0\370\1\0\0\0\0\0\0\37=
0\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\300\32\0\0\0\0\0\0\300\3=
2`\3500\0\0\0\300\32`\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0`\3500\0\0\0\0\0`\3500\0\0\=
0\224\37\0\0\0\0\0\0\224\37\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0`-\=
0\0\0\0\0\0`-\200\3500\0\0\0`-\200\3500\0\0\0 \3\0\0\0\0\0\0\240\3\0\0\0\=
0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\240-\0\0\0\0\0\0\240-\200\3500\0\0\0=
\240-\200\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0=
\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2`\3500\0\0\0008\2`\3500\0\0\0 \0\0\=
0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\334\32\0\0\0\0\0\=
0\334\32`\3500\0\0\0\334\32`\3500\0\0\0\264\0\0\0\0\0\0\0\264\0\0\0\0\0\0=
\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26291 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147322, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D48, st_size=3D23360, st_atime=3D2012/10/09-11:13:54, st_mtime=3D2010=
/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26291 mmap(0x30e8600000, 2109696, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8600000
26291 mprotect(0x30e8602000, 2097152, PROT_NONE) =3D 0
26291 mmap(0x30e8802000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x2000) =3D 0x30e8802000
26291 close(3)                          =3D 0
26291 open("/lib64/libm.so.6", O_RDONLY) =3D 3
26291 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`>\240\3510\=
0\0\0@\0\0\0\0\0\0\0\240X\t\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0)\0(\0\6\0\0\=
0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3510\0\0\0@\0\240\3510\0\0\0\370\1\0\0\0\=
0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\360\303\7\0\0\0\=
0\0\360\303\247\3510\0\0\0\360\303\247\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0=
\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3510\=
0\0\0\0\0\240\3510\0\0\0000\22\10\0\0\0\0\0000\22\10\0\0\0\0\0\0\0 \0\0\0=
\0\0\1\0\0\0\6\0\0\0\270\35\10\0\0\0\0\0\270\35\310\3510\0\0\0\270\35\310=
\3510\0\0\0\320\2\0\0\0\0\0\0 \3\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0=
\0\350\35\10\0\0\0\0\0\350\35\310\3510\0\0\0\350\35\310\3510\0\0\0\300\1\=
0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0=
\0\0\0008\2\240\3510\0\0\0008\2\240\3510\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\f\304\7\0\0\0\0\0\f\304\247\3510\0\0\0=
\f\304\247\3510\0\0\0\374\r\0\0\0\0\0\0\374\r\0\0\0\0\0\0\4\0\0\0\0\0\0\0=
Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0"..., 832) =3D 832
26291 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147337, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D1216, st_size=3D615136, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2=
010/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26291 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f2692caa000
26291 mmap(0x30e9a00000, 2629848, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9a00000
26291 mprotect(0x30e9a82000, 2093056, PROT_NONE) =3D 0
26291 mmap(0x30e9c81000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x81000) =3D 0x30e9c81000
26291 close(3)                          =3D 0
26291 open("/lib64/libcrypt.so.1", O_RDONLY) =3D 3
26291 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\t\300%4=
\0\0\0@\0\0\0\0\0\0\0\30\265\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\=
0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\300%4\0\0\0@\0\300%4\0\0\0\370\1\0\0\0\0\=
0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340}\0\0\0\0\0\0\3=
40}\300%4\0\0\0\340}\300%4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\300%4\0\0\0\0\0\300%4\0\0\=
0\4\205\0\0\0\0\0\0\4\205\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\310\=
215\0\0\0\0\0\0\310\215\340%4\0\0\0\310\215\340%4\0\0\0\250\2\0\0\0\0\0\0=
\370\343\2\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\215\0\0\0\0\0\0\3=
70\215\340%4\0\0\0\370\215\340%4\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\=
0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\300%4\0\0\0008\2=
\300%4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0=
\374}\0\0\0\0\0\0\374}\300%4\0\0\0\374}\300%4\0\0\0\34\1\0\0\0\0\0\0\34\1=
\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26291 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148123, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D96, st_size=3D48600, st_atime=3D2012/10/09-12:01:01, st_mtime=3D2010=
/07/28-03:52:39, st_ctime=3D2012/09/11-14:53:52}) =3D 0
26291 mmap(0x3425c00000, 2322880, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425c00000
26291 mprotect(0x3425c09000, 2093056, PROT_NONE) =3D 0
26291 mmap(0x3425e08000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x8000) =3D 0x3425e08000
26291 mmap(0x3425e0a000, 184768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FI=
XED|MAP_ANONYMOUS, -1, 0) =3D 0x3425e0a000
26291 close(3)                          =3D 0
26291 open("/lib64/libutil.so.1", O_RDONLY) =3D 3
26291 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\16\0(4\=
0\0\0@\0\0\0\0\0\0\0(>\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0\0(4\0\0\0@\0\0(4\0\0\0\370\1\0\0\0\0\0\0\370\1\=
0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340\26\0\0\0\0\0\0\340\26\0(=
4\0\0\0\340\26\0(4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0=
\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0(4\0\0\0\0\0\0(4\0\0\0P\32\0\0\0\=
0\0\0P\32\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\35\0\0\0\0\0\0\3=
40\35 (4\0\0\0\340\35 (4\0\0\0 \3\0\0\0\0\0\0000\3\0\0\0\0\0\0\0\0 \0\0\0=
\0\0\2\0\0\0\6\0\0\0\20\36\0\0\0\0\0\0\20\36 (4\0\0\0\20\36 (4\0\0\0\300\=
1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0=
\0\0\0\0008\2\0(4\0\0\0008\2\0(4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\=
0\0\0\0\0\0P\345td\4\0\0\0\374\26\0\0\0\0\0\0\374\26\0(4\0\0\0\374\26\0(4=
\0\0\0D\0\0\0\0\0\0\0D\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8=
32) =3D 832
26291 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147063, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D40, st_size=3D18152, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2010=
/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:49}) =3D 0
26291 mmap(0x3428000000, 2105616, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3428000000
26291 mprotect(0x3428002000, 2093056, PROT_NONE) =3D 0
26291 mmap(0x3428201000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x1000) =3D 0x3428201000
26291 close(3)                          =3D 0
26291 open("/lib64/libpthread.so.0", O_RDONLY) =3D 3
26291 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240W\240\35=
00\0\0\0@\0\0\0\0\0\0\0\340/\2\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0'\0&\0\6\0=
\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3500\0\0\0@\0\240\3500\0\0\0\370\1\0\0=
\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\240\t\1\0\0\0=
\0\0\240\t\241\3500\0\0\0\240\t\241\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\=
0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3500\0\0=
\0\0\0\240\3500\0\0\0pZ\1\0\0\0\0\0pZ\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\=
6\0\0\0\270[\1\0\0\0\0\0\270[\301\3500\0\0\0\270[\301\3500\0\0\0\230\6\0\=
0\0\0\0\0\270G\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250]\1\0\0\0\0\=
0\250]\301\3500\0\0\0\250]\301\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0=
\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\240\3500\0\0\=
0008\2\240\3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345t=
d\4\0\0\0\274\t\1\0\0\0\0\0\274\t\241\3500\0\0\0\274\t\241\3500\0\0\0\344=
\t\0\0\0\0\0\0\344\t\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =
=3D 832
26291 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147328, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D296, st_size=3D145824, st_atime=3D2012/10/09-11:16:43, st_mtime=3D20=
10/07/28-03:52:41, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26291 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f2692ca9000
26291 mmap(0x30e8a00000, 2204528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8a00000
26291 mprotect(0x30e8a16000, 2093056, PROT_NONE) =3D 0
26291 mmap(0x30e8c15000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x15000) =3D 0x30e8c15000
26291 mmap(0x30e8c17000, 13168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8c17000
26291 close(3)                          =3D 0
26291 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26291 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26291 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26291 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26291 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26291 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26291 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26291 close(3)                          =3D 0
26291 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f2692ca8000
26291 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f2692ca7000
26291 arch_prctl(ARCH_SET_FS, 0x7f2692ca76e0) =3D 0
26291 mprotect(0x3427211000, 4096, PROT_READ) =3D 0
26291 mprotect(0x30ea014000, 4096, PROT_READ) =3D 0
26291 mprotect(0x30e8802000, 4096, PROT_READ) =3D 0
26291 mprotect(0x30e9c81000, 4096, PROT_READ) =3D 0
26291 mprotect(0x3425e08000, 4096, PROT_READ) =3D 0
26291 mprotect(0x3428201000, 4096, PROT_READ) =3D 0
26291 mprotect(0x30e8c15000, 4096, PROT_READ) =3D 0
26291 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26291 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26291 munmap(0x7f2692cac000, 103979)    =3D 0
26291 set_tid_address(0x7f2692ca7770)   =3D 26291
26291 set_robust_list(0x7f2692ca7780, 0x18) =3D 0
26291 futex(0x7fffcf66423c, FUTEX_WAKE_PRIVATE, 1) =3D 0
26291 rt_sigaction(SIGRTMIN, {0x30e8a05380, [], SA_RESTORER|SA_SIGINFO, 0=
x30e8a0eb10}, NULL, 8) =3D 0
26291 rt_sigaction(SIGRT_1, {0x30e8a052b0, [], SA_RESTORER|SA_RESTART|SA_=
SIGINFO, 0x30e8a0eb10}, NULL, 8) =3D 0
26291 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) =3D 0
26291 getrlimit(RLIMIT_STACK, {rlim_cur=3D8192*1024, rlim_max=3DRLIM_INFI=
NITY}) =3D 0
26291 rt_sigaction(SIGFPE, {0x1, [FPE], SA_RESTORER|SA_RESTART, 0x30e8230=
2d0}, {SIG_DFL, [], 0}, 8) =3D 0
26291 brk(0)                            =3D 0x1cbc000
26291 brk(0x1cde000)                    =3D 0x1cde000
26291 getuid()                          =3D 0
26291 geteuid()                         =3D 0
26291 getgid()                          =3D 0
26291 getegid()                         =3D 0
26291 mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,=
 -1, 0) =3D 0x7f2692c86000
26291 open("/dev/urandom", O_RDONLY)    =3D 3
26291 read(3, "\317\226\355\210", 4)    =3D 4
26291 close(3)                          =3D 0
26291 stat("/usr/lib64/perl5/site_perl/5.8.7/x86_64-linux-thread-multi", =
0x7fffcf663ef0) =3D -1 ENOENT (No such file or directory)
26291 stat("/usr/lib/perl5/site_perl/5.8.7", 0x7fffcf663ef0) =3D -1 ENOEN=
T (No such file or directory)
26291 stat("/usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi", =
0x7fffcf663ef0) =3D -1 ENOENT (No such file or directory)
26291 stat("/usr/lib/perl5/site_perl/5.8.6", 0x7fffcf663ef0) =3D -1 ENOEN=
T (No such file or directory)
26291 stat("/usr/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi", =
0x7fffcf663ef0) =3D -1 ENOENT (No such file or directory)
26291 stat("/usr/lib/perl5/site_perl/5.8.5", 0x7fffcf663ef0) =3D -1 ENOEN=
T (No such file or directory)
26291 stat("/usr/lib64/perl5/vendor_perl/5.8.7/x86_64-linux-thread-multi"=
, 0x7fffcf663ef0) =3D -1 ENOENT (No such file or directory)
26291 stat("/usr/lib/perl5/vendor_perl/5.8.7", 0x7fffcf663ef0) =3D -1 ENO=
ENT (No such file or directory)
26291 stat("/usr/lib64/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi"=
, 0x7fffcf663ef0) =3D -1 ENOENT (No such file or directory)
26291 stat("/usr/lib/perl5/vendor_perl/5.8.6", 0x7fffcf663ef0) =3D -1 ENO=
ENT (No such file or directory)
26291 stat("/usr/lib64/perl5/vendor_perl/5.8.5/x86_64-linux-thread-multi"=
, 0x7fffcf663ef0) =3D -1 ENOENT (No such file or directory)
26291 stat("/usr/lib/perl5/vendor_perl/5.8.5", 0x7fffcf663ef0) =3D -1 ENO=
ENT (No such file or directory)
26291 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffcf663cb0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26291 lseek(0, 0, SEEK_CUR)             =3D 0
26291 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffcf663cb0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26291 lseek(1, 0, SEEK_CUR)             =3D -1 ESPIPE (Illegal seek)
26291 ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffcf663cc0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26291 lseek(2, 0, SEEK_CUR)             =3D 593660285
26291 open("/dev/null", O_RDONLY)       =3D 3
26291 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffcf663dc0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26291 lseek(3, 0, SEEK_CUR)             =3D 0
26291 fcntl(3, F_SETFD, FD_CLOEXEC)     =3D 0
26291 fstat(3, {st_dev=3Dmakedev(0, 16), st_ino=3D584, st_mode=3DS_IFCHR|=
0666, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
0, st_rdev=3Dmakedev(1, 3), st_atime=3D2012/10/08-11:13:26, st_mtime=3D20=
12/10/08-11:13:26, st_ctime=3D2012/10/08-11:13:27}) =3D 0
26291 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) =3D 0
26291 readlink("/proc/self/exe", "/usr/bin/perl"..., 4095) =3D 13
26291 brk(0x1cff000)                    =3D 0x1cff000
26291 close(3)                          =3D 0
26291 dup(200)                          =3D 3
26291 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffcf663c90) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26291 lseek(3, 0, SEEK_CUR)             =3D 0
26291 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26291 dup2(3, 0)                        =3D 0
26291 close(3)                          =3D 0
26291 fcntl(0, F_SETFD, 0)              =3D 0
26291 fstat(0, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26291 stat("/var/run/xen-hotplug/block", {st_dev=3Dmakedev(8, 2), st_ino=3D=
2801738, st_mode=3DS_IFREG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st=
_blksize=3D4096, st_blocks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:=
24, st_mtime=3D2012/10/09-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D =
0
26291 exit_group(0)                     =3D ?
27813 <... read resumed> "", 128)       =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], WNOHANG, NUL=
L) =3D 26291
27813 wait4(-1, 0x7fffb0100a64, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0)                   =3D 0
27813 close(3)                          =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 write(2, "+ rightfile=3D\n", 13)    =3D 13
27813 write(2, "+ '[' x =3D xy ']'\n", 17) =3D 17
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ true\n", 7)           =3D 7
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ eval 'exec 200>>/var/run/xen-hotplug/block'\n", 46) =3D=
 46
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 write(2, "++ exec\n", 8)          =3D 8
27813 open("/var/run/xen-hotplug/block", O_WRONLY|O_CREAT|O_APPEND, 0666)=
 =3D 3
27813 fcntl(200, F_GETFD)               =3D 0
27813 fcntl(200, F_DUPFD, 10)           =3D 10
27813 fcntl(200, F_GETFD)               =3D 0
27813 dup2(3, 200)                      =3D 200
27813 close(3)                          =3D 0
27813 dup2(10, 200)                     =3D 200
27813 fcntl(10, F_GETFD)                =3D 0
27813 close(10)                         =3D 0
27813 write(2, "+ flock -x 200\n", 15)  =3D 15
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [INT CHLD], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [INT CHLD], NULL, 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26292
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26292 close(255 
27813 rt_sigprocmask(SIG_BLOCK, [CHLD],  
26292 <... close resumed> )             =3D 0
27813 <... rt_sigprocmask resumed> [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [],  
26292 rt_sigprocmask(SIG_SETMASK, [],  
27813 <... rt_sigprocmask resumed> NULL, 8) =3D 0
26292 <... rt_sigprocmask resumed> NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
26292 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0},  
26292 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
27813 <... rt_sigaction resumed> {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}=
, 8) =3D 0
26292 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 wait4(-1,  
26292 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
26292 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26292 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26292 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26292 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26292 execve("/usr/bin/flock", ["flock", "-x", "200"], ["SUBSYSTEM=3Dxen-=
backend", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D=
/usr/bin:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:=
/usr/sbin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dx=
en-backend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3D=
backend/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "S=
HLVL=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/flock"]) =3D 0=

26292 brk(0)                            =3D 0xba0000
26292 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f1f1f9ee000
26292 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f1f1f9ed000
26292 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26292 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26292 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26292 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7f1f1f9d3000=

26292 close(3)                          =3D 0
26292 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26292 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26292 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26292 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26292 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26292 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26292 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26292 close(3)                          =3D 0
26292 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f1f1f9d2000
26292 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f1f1f9d1000
26292 arch_prctl(ARCH_SET_FS, 0x7f1f1f9d16e0) =3D 0
26292 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26292 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26292 munmap(0x7f1f1f9d3000, 103979)    =3D 0
26292 flock(200, LOCK_EX)               =3D 0
26292 exit_group(0)                     =3D ?
27813 <... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], 0,=
 NULL) =3D 26292
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, 0x7fffb0100a24, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0xffffffffffffffff)  =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 pipe([3, 4])                      =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26293
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {0=
x436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26293 close(255 
27813 close(4 
26293 <... close resumed> )             =3D 0
27813 <... close resumed> )             =3D 0
27813 read(3,  
26293 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26293 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26293 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26293 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26293 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26293 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26293 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26293 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {S=
IG_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26293 rt_sigaction(SIGINT, {0x4481f0, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26293 dup2(4, 1)                        =3D 1
26293 close(4)                          =3D 0
26293 close(3)                          =3D 0
26293 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26293 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26293 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26293 write(2, "++ perl -e '\n            open STDIN, \"<&200\" or die $!=
;\n            my $fd_inum =3D (stat STDIN)[1]; die $! unless defined $fd=
_inum;\n            my $file_inum =3D (stat $ARGV[0])[1];\n            pr=
int \"y\\n\" if $fd_inum eq $file_inum;\n", 230) =3D 230
26293 write(2, "                             ' /var/run/xen-hotplug/block=
\n", 58) =3D 58
26293 stat(".", {st_dev=3Dmakedev(8, 2), st_ino=3D2, st_mode=3DS_IFDIR|07=
55, st_nlink=3D24, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
8, st_size=3D4096, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2012/10/08-=
11:13:38, st_ctime=3D2012/10/08-11:13:38}) =3D 0
26293 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26293 access("/usr/bin/perl", X_OK)     =3D 0
26293 access("/usr/bin/perl", R_OK)     =3D 0
26293 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26293 access("/usr/bin/perl", X_OK)     =3D 0
26293 access("/usr/bin/perl", R_OK)     =3D 0
26293 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
481f0, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26293 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26293 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26293 execve("/usr/bin/perl", ["perl", "-e", "\n            open STDIN, \=
"<&200\" or die $!;\n            my $fd_inum =3D (stat STDIN)[1]; die $! =
unless defined $fd_inum;\n            my $file_inum =3D (stat $ARGV[0])[1=
];\n            print \"y\\n\" if $fd_inum eq $file_inum;\n              =
               ", "/var/run/xen-hotplug/block"], ["SUBSYSTEM=3Dxen-backen=
d", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D/usr/b=
in:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:/usr/s=
bin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dxen-bac=
kend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3Dback=
end/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "SHLVL=
=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/perl"]) =3D 0
26293 brk(0)                            =3D 0xef5000
26293 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f61c9c69000
26293 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f61c9c68000
26293 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26293 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64/libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26293 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64", 0x7fff9164f390) =3D -1 ENOENT (No such file or directory)
26293 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/lib=
perl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26293 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls", 0=
x7fff9164f390) =3D -1 ENOENT (No such file or directory)
26293 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64/=
libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26293 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64"=
, 0x7fff9164f390) =3D -1 ENOENT (No such file or directory)
26293 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl=
=2Eso", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26293 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE", 0x7ff=
f9164f390) =3D -1 ENOENT (No such file or directory)
26293 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26293 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26293 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7f61c9c4e000=

26293 close(3)                          =3D 0
26293 open("/usr/lib64/libperl.so", O_RDONLY) =3D 3
26293 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\34\203%=
4\0\0\0@\0\0\0\0\0\0\0\360;\23\0\0\0\0\0\0\0\0\0@\0008\0\5\0@\0\35\0\34\0=
\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\200%4\0\0\0\0\0\200%4\0\0\0T\260\22\=
0\0\0\0\0T\260\22\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0X\260\22\0\0\0\=
0\0X\260\262%4\0\0\0X\260\262%4\0\0\0\250\201\0\0\0\0\0\0\350\242\0\0\0\0=
\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\265\22\0\0\0\0\0\370\265\262%4\0\=
0\0\370\265\262%4\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\=
0\0P\345td\4\0\0\0\250u\21\0\0\0\0\0\250u\221%4\0\0\0\250u\221%4\0\0\0D@\=
0\0\0\0\0\0D@\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\7\4\0\0\360\0\0\0\0\1\0\0\16\0\0\0\0\0\0@\0\200\203\200\225\1\22\=
264\3\31\200l\0\32\0 \5\201\0\240\3\2B\0\200\21R \0\22\0\0\16P\20#\10\216=
\334\30\211\"\0\10 \200\3B\220@\0\1\206\20\30\2\3\21\203$!\312A0\224Y\200=
\27\0\242\26\10\24R@\10\200\220\20A\10\0\220\1\200\206\2\10\304\30i\0\220=
\1\1\202\200\22\20\0\n\1H\0\n\2001J \6\31@L\207\20\10\0000\10(\200\2\0\4\=
251t\"\262\310!\212\240\320\"\0\t"..., 832) =3D 832
26293 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2839671, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D2480, st_size=3D1262384, st_atime=3D2012/10/09-12:04:35, st_mtime=3D=
2012/09/11-12:45:05, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26293 mmap(0x3425800000, 3363648, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425800000
26293 mprotect(0x342592c000, 2093056, PROT_NONE) =3D 0
26293 mmap(0x3425b2b000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x12b000) =3D 0x3425b2b000
26293 mmap(0x3425b34000, 4928, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3425b34000
26293 close(3)                          =3D 0
26293 open("/lib64/libresolv.so.2", O_RDONLY) =3D 3
26293 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\2402\0'4\0\=
0\0@\0\0\0\0\0\0\0@a\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\5\0=
\0\0@\0\0\0\0\0\0\0@\0\0'4\0\0\0@\0\0'4\0\0\0\370\1\0\0\0\0\0\0\370\1\0\0=
\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \361\0\0\0\0\0\0 \361\0'4\0\0\0=
 \361\0'4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\=
0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0'4\0\0\0\0\0\0'4\0\0\0$\10\1\0\0\0\0\0$\10=
\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\24\1\0\0\0\0\0\340\24!'4\=
0\0\0\340\24!'4\0\0\0\340\r\0\0\0\0\0\0\0106\0\0\0\0\0\0\0\0 \0\0\0\0\0\2=
\0\0\0\6\0\0\0\350\35\1\0\0\0\0\0\350\35!'4\0\0\0\350\35!'4\0\0\0\300\1\0=
\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\=
0\0\0008\2\0'4\0\0\0008\2\0'4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0=
\0\0\0\0P\345td\4\0\0\0<\361\0\0\0\0\0\0<\361\0'4\0\0\0<\361\0'4\0\0\0,\3=
\0\0\0\0\0\0,\3\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 8=
32
26293 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148119, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D192, st_size=3D92736, st_atime=3D2012/10/09-11:16:43, st_mtime=3D201=
0/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:42}) =3D 0
26293 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f61c9c4d000
26293 mmap(0x3427000000, 2181864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3427000000
26293 mprotect(0x3427011000, 2097152, PROT_NONE) =3D 0
26293 mmap(0x3427211000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x11000) =3D 0x3427211000
26293 mmap(0x3427213000, 6888, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3427213000
26293 close(3)                          =3D 0
26293 open("/lib64/libnsl.so.1", O_RDONLY) =3D 3
26293 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240@\340\35=
10\0\0\0@\0\0\0\0\0\0\0\360\265\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0=
\6\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\340\3510\0\0\0@\0\340\3510\0\0\0\370\1=
\0\0\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \33\1\0\0=
\0\0\0 \33\341\3510\0\0\0 \33\341\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\=
0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\340\3510\0\0\0=
\0\0\340\3510\0\0\0\310@\1\0\0\0\0\0\310@\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\=
0\0\6\0\0\0xM\1\0\0\0\0\0xM\1\3520\0\0\0xM\1\3520\0\0\0\310\5\0\0\0\0\0\0=
008-\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250M\1\0\0\0\0\0\250M\1\3=
520\0\0\0\250M\1\3520\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\340\3510\0\0\0008\2\340\351=
0\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0<\33\=
1\0\0\0\0\0<\33\341\3510\0\0\0<\33\341\3510\0\0\0\\\5\0\0\0\0\0\0\\\5\0\0=
\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26293 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147206, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D232, st_size=3D114352, st_atime=3D2012/10/09-12:01:01, st_mtime=3D20=
10/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:44}) =3D 0
26293 mmap(0x30e9e00000, 2194096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9e00000
26293 mprotect(0x30e9e15000, 2093056, PROT_NONE) =3D 0
26293 mmap(0x30ea014000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x14000) =3D 0x30ea014000
26293 mmap(0x30ea016000, 6832, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x30ea016000
26293 close(3)                          =3D 0
26293 open("/lib64/libdl.so.2", O_RDONLY) =3D 3
26293 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\16`\3500=
\0\0\0@\0\0\0\0\0\0\0@R\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0`\3500\0\0\0@\0`\3500\0\0\0\370\1\0\0\0\0\0\0\37=
0\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\300\32\0\0\0\0\0\0\300\3=
2`\3500\0\0\0\300\32`\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0`\3500\0\0\0\0\0`\3500\0\0\=
0\224\37\0\0\0\0\0\0\224\37\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0`-\=
0\0\0\0\0\0`-\200\3500\0\0\0`-\200\3500\0\0\0 \3\0\0\0\0\0\0\240\3\0\0\0\=
0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\240-\0\0\0\0\0\0\240-\200\3500\0\0\0=
\240-\200\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0=
\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2`\3500\0\0\0008\2`\3500\0\0\0 \0\0\=
0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\334\32\0\0\0\0\0\=
0\334\32`\3500\0\0\0\334\32`\3500\0\0\0\264\0\0\0\0\0\0\0\264\0\0\0\0\0\0=
\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26293 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147322, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D48, st_size=3D23360, st_atime=3D2012/10/09-11:13:54, st_mtime=3D2010=
/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26293 mmap(0x30e8600000, 2109696, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8600000
26293 mprotect(0x30e8602000, 2097152, PROT_NONE) =3D 0
26293 mmap(0x30e8802000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x2000) =3D 0x30e8802000
26293 close(3)                          =3D 0
26293 open("/lib64/libm.so.6", O_RDONLY) =3D 3
26293 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`>\240\3510\=
0\0\0@\0\0\0\0\0\0\0\240X\t\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0)\0(\0\6\0\0\=
0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3510\0\0\0@\0\240\3510\0\0\0\370\1\0\0\0\=
0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\360\303\7\0\0\0\=
0\0\360\303\247\3510\0\0\0\360\303\247\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0=
\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3510\=
0\0\0\0\0\240\3510\0\0\0000\22\10\0\0\0\0\0000\22\10\0\0\0\0\0\0\0 \0\0\0=
\0\0\1\0\0\0\6\0\0\0\270\35\10\0\0\0\0\0\270\35\310\3510\0\0\0\270\35\310=
\3510\0\0\0\320\2\0\0\0\0\0\0 \3\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0=
\0\350\35\10\0\0\0\0\0\350\35\310\3510\0\0\0\350\35\310\3510\0\0\0\300\1\=
0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0=
\0\0\0008\2\240\3510\0\0\0008\2\240\3510\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\f\304\7\0\0\0\0\0\f\304\247\3510\0\0\0=
\f\304\247\3510\0\0\0\374\r\0\0\0\0\0\0\374\r\0\0\0\0\0\0\4\0\0\0\0\0\0\0=
Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0"..., 832) =3D 832
26293 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147337, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D1216, st_size=3D615136, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2=
010/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26293 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f61c9c4c000
26293 mmap(0x30e9a00000, 2629848, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9a00000
26293 mprotect(0x30e9a82000, 2093056, PROT_NONE) =3D 0
26293 mmap(0x30e9c81000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x81000) =3D 0x30e9c81000
26293 close(3)                          =3D 0
26293 open("/lib64/libcrypt.so.1", O_RDONLY) =3D 3
26293 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\t\300%4=
\0\0\0@\0\0\0\0\0\0\0\30\265\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\=
0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\300%4\0\0\0@\0\300%4\0\0\0\370\1\0\0\0\0\=
0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340}\0\0\0\0\0\0\3=
40}\300%4\0\0\0\340}\300%4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\300%4\0\0\0\0\0\300%4\0\0\=
0\4\205\0\0\0\0\0\0\4\205\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\310\=
215\0\0\0\0\0\0\310\215\340%4\0\0\0\310\215\340%4\0\0\0\250\2\0\0\0\0\0\0=
\370\343\2\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\215\0\0\0\0\0\0\3=
70\215\340%4\0\0\0\370\215\340%4\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\=
0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\300%4\0\0\0008\2=
\300%4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0=
\374}\0\0\0\0\0\0\374}\300%4\0\0\0\374}\300%4\0\0\0\34\1\0\0\0\0\0\0\34\1=
\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26293 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148123, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D96, st_size=3D48600, st_atime=3D2012/10/09-12:01:01, st_mtime=3D2010=
/07/28-03:52:39, st_ctime=3D2012/09/11-14:53:52}) =3D 0
26293 mmap(0x3425c00000, 2322880, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425c00000
26293 mprotect(0x3425c09000, 2093056, PROT_NONE) =3D 0
26293 mmap(0x3425e08000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x8000) =3D 0x3425e08000
26293 mmap(0x3425e0a000, 184768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FI=
XED|MAP_ANONYMOUS, -1, 0) =3D 0x3425e0a000
26293 close(3)                          =3D 0
26293 open("/lib64/libutil.so.1", O_RDONLY) =3D 3
26293 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\16\0(4\=
0\0\0@\0\0\0\0\0\0\0(>\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0\0(4\0\0\0@\0\0(4\0\0\0\370\1\0\0\0\0\0\0\370\1\=
0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340\26\0\0\0\0\0\0\340\26\0(=
4\0\0\0\340\26\0(4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0=
\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0(4\0\0\0\0\0\0(4\0\0\0P\32\0\0\0\=
0\0\0P\32\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\35\0\0\0\0\0\0\3=
40\35 (4\0\0\0\340\35 (4\0\0\0 \3\0\0\0\0\0\0000\3\0\0\0\0\0\0\0\0 \0\0\0=
\0\0\2\0\0\0\6\0\0\0\20\36\0\0\0\0\0\0\20\36 (4\0\0\0\20\36 (4\0\0\0\300\=
1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0=
\0\0\0\0008\2\0(4\0\0\0008\2\0(4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\=
0\0\0\0\0\0P\345td\4\0\0\0\374\26\0\0\0\0\0\0\374\26\0(4\0\0\0\374\26\0(4=
\0\0\0D\0\0\0\0\0\0\0D\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8=
32) =3D 832
26293 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147063, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D40, st_size=3D18152, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2010=
/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:49}) =3D 0
26293 mmap(0x3428000000, 2105616, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3428000000
26293 mprotect(0x3428002000, 2093056, PROT_NONE) =3D 0
26293 mmap(0x3428201000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x1000) =3D 0x3428201000
26293 close(3)                          =3D 0
26293 open("/lib64/libpthread.so.0", O_RDONLY) =3D 3
26293 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240W\240\35=
00\0\0\0@\0\0\0\0\0\0\0\340/\2\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0'\0&\0\6\0=
\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3500\0\0\0@\0\240\3500\0\0\0\370\1\0\0=
\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\240\t\1\0\0\0=
\0\0\240\t\241\3500\0\0\0\240\t\241\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\=
0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3500\0\0=
\0\0\0\240\3500\0\0\0pZ\1\0\0\0\0\0pZ\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\=
6\0\0\0\270[\1\0\0\0\0\0\270[\301\3500\0\0\0\270[\301\3500\0\0\0\230\6\0\=
0\0\0\0\0\270G\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250]\1\0\0\0\0\=
0\250]\301\3500\0\0\0\250]\301\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0=
\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\240\3500\0\0\=
0008\2\240\3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345t=
d\4\0\0\0\274\t\1\0\0\0\0\0\274\t\241\3500\0\0\0\274\t\241\3500\0\0\0\344=
\t\0\0\0\0\0\0\344\t\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =
=3D 832
26293 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147328, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D296, st_size=3D145824, st_atime=3D2012/10/09-11:16:43, st_mtime=3D20=
10/07/28-03:52:41, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26293 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f61c9c4b000
26293 mmap(0x30e8a00000, 2204528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8a00000
26293 mprotect(0x30e8a16000, 2093056, PROT_NONE) =3D 0
26293 mmap(0x30e8c15000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x15000) =3D 0x30e8c15000
26293 mmap(0x30e8c17000, 13168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8c17000
26293 close(3)                          =3D 0
26293 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26293 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26293 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26293 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26293 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26293 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26293 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26293 close(3)                          =3D 0
26293 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f61c9c4a000
26293 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f61c9c49000
26293 arch_prctl(ARCH_SET_FS, 0x7f61c9c496e0) =3D 0
26293 mprotect(0x3427211000, 4096, PROT_READ) =3D 0
26293 mprotect(0x30ea014000, 4096, PROT_READ) =3D 0
26293 mprotect(0x30e8802000, 4096, PROT_READ) =3D 0
26293 mprotect(0x30e9c81000, 4096, PROT_READ) =3D 0
26293 mprotect(0x3425e08000, 4096, PROT_READ) =3D 0
26293 mprotect(0x3428201000, 4096, PROT_READ) =3D 0
26293 mprotect(0x30e8c15000, 4096, PROT_READ) =3D 0
26293 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26293 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26293 munmap(0x7f61c9c4e000, 103979)    =3D 0
26293 set_tid_address(0x7f61c9c49770)   =3D 26293
26293 set_robust_list(0x7f61c9c49780, 0x18) =3D 0
26293 futex(0x7fff9164febc, FUTEX_WAKE_PRIVATE, 1) =3D 0
26293 rt_sigaction(SIGRTMIN, {0x30e8a05380, [], SA_RESTORER|SA_SIGINFO, 0=
x30e8a0eb10}, NULL, 8) =3D 0
26293 rt_sigaction(SIGRT_1, {0x30e8a052b0, [], SA_RESTORER|SA_RESTART|SA_=
SIGINFO, 0x30e8a0eb10}, NULL, 8) =3D 0
26293 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) =3D 0
26293 getrlimit(RLIMIT_STACK, {rlim_cur=3D8192*1024, rlim_max=3DRLIM_INFI=
NITY}) =3D 0
26293 rt_sigaction(SIGFPE, {0x1, [FPE], SA_RESTORER|SA_RESTART, 0x30e8230=
2d0}, {SIG_DFL, [], 0}, 8) =3D 0
26293 brk(0)                            =3D 0xef5000
26293 brk(0xf17000)                     =3D 0xf17000
26293 getuid()                          =3D 0
26293 geteuid()                         =3D 0
26293 getgid()                          =3D 0
26293 getegid()                         =3D 0
26293 mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,=
 -1, 0) =3D 0x7f61c9c28000
26293 open("/dev/urandom", O_RDONLY)    =3D 3
26293 read(3, "\2753\222B", 4)          =3D 4
26293 close(3)                          =3D 0
26293 stat("/usr/lib64/perl5/site_perl/5.8.7/x86_64-linux-thread-multi", =
0x7fff9164fb70) =3D -1 ENOENT (No such file or directory)
26293 stat("/usr/lib/perl5/site_perl/5.8.7", 0x7fff9164fb70) =3D -1 ENOEN=
T (No such file or directory)
26293 stat("/usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi", =
0x7fff9164fb70) =3D -1 ENOENT (No such file or directory)
26293 stat("/usr/lib/perl5/site_perl/5.8.6", 0x7fff9164fb70) =3D -1 ENOEN=
T (No such file or directory)
26293 stat("/usr/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi", =
0x7fff9164fb70) =3D -1 ENOENT (No such file or directory)
26293 stat("/usr/lib/perl5/site_perl/5.8.5", 0x7fff9164fb70) =3D -1 ENOEN=
T (No such file or directory)
26293 stat("/usr/lib64/perl5/vendor_perl/5.8.7/x86_64-linux-thread-multi"=
, 0x7fff9164fb70) =3D -1 ENOENT (No such file or directory)
26293 stat("/usr/lib/perl5/vendor_perl/5.8.7", 0x7fff9164fb70) =3D -1 ENO=
ENT (No such file or directory)
26293 stat("/usr/lib64/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi"=
, 0x7fff9164fb70) =3D -1 ENOENT (No such file or directory)
26293 stat("/usr/lib/perl5/vendor_perl/5.8.6", 0x7fff9164fb70) =3D -1 ENO=
ENT (No such file or directory)
26293 stat("/usr/lib64/perl5/vendor_perl/5.8.5/x86_64-linux-thread-multi"=
, 0x7fff9164fb70) =3D -1 ENOENT (No such file or directory)
26293 stat("/usr/lib/perl5/vendor_perl/5.8.5", 0x7fff9164fb70) =3D -1 ENO=
ENT (No such file or directory)
26293 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff9164f930) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26293 lseek(0, 0, SEEK_CUR)             =3D 0
26293 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff9164f930) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26293 lseek(1, 0, SEEK_CUR)             =3D -1 ESPIPE (Illegal seek)
26293 ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff9164f940) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26293 lseek(2, 0, SEEK_CUR)             =3D 593660679
26293 open("/dev/null", O_RDONLY)       =3D 3
26293 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff9164fa40) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26293 lseek(3, 0, SEEK_CUR)             =3D 0
26293 fcntl(3, F_SETFD, FD_CLOEXEC)     =3D 0
26293 fstat(3, {st_dev=3Dmakedev(0, 16), st_ino=3D584, st_mode=3DS_IFCHR|=
0666, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
0, st_rdev=3Dmakedev(1, 3), st_atime=3D2012/10/08-11:13:26, st_mtime=3D20=
12/10/08-11:13:26, st_ctime=3D2012/10/08-11:13:27}) =3D 0
26293 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) =3D 0
26293 readlink("/proc/self/exe", "/usr/bin/perl"..., 4095) =3D 13
26293 brk(0xf38000)                     =3D 0xf38000
26293 close(3)                          =3D 0
26293 dup(200)                          =3D 3
26293 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff9164f910) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26293 lseek(3, 0, SEEK_CUR)             =3D 0
26293 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26293 dup2(3, 0)                        =3D 0
26293 close(3)                          =3D 0
26293 fcntl(0, F_SETFD, 0)              =3D 0
26293 fstat(0, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26293 stat("/var/run/xen-hotplug/block", {st_dev=3Dmakedev(8, 2), st_ino=3D=
2801738, st_mode=3DS_IFREG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st=
_blksize=3D4096, st_blocks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:=
24, st_mtime=3D2012/10/09-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D =
0
26293 exit_group(0)                     =3D ?
27813 <... read resumed> "", 128)       =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], WNOHANG, NUL=
L) =3D 26293
27813 wait4(-1, 0x7fffb0100a64, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0)                   =3D 0
27813 close(3)                          =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 write(2, "+ rightfile=3D\n", 13)    =3D 13
27813 write(2, "+ '[' x =3D xy ']'\n", 17) =3D 17
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ true\n", 7)           =3D 7
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ eval 'exec 200>>/var/run/xen-hotplug/block'\n", 46) =3D=
 46
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 write(2, "++ exec\n", 8)          =3D 8
27813 open("/var/run/xen-hotplug/block", O_WRONLY|O_CREAT|O_APPEND, 0666)=
 =3D 3
27813 fcntl(200, F_GETFD)               =3D 0
27813 fcntl(200, F_DUPFD, 10)           =3D 10
27813 fcntl(200, F_GETFD)               =3D 0
27813 dup2(3, 200)                      =3D 200
27813 close(3)                          =3D 0
27813 dup2(10, 200)                     =3D 200
27813 fcntl(10, F_GETFD)                =3D 0
27813 close(10)                         =3D 0
27813 write(2, "+ flock -x 200\n", 15)  =3D 15
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [INT CHLD], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [INT CHLD], NULL, 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26294
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26294 close(255 
27813 rt_sigprocmask(SIG_BLOCK, [CHLD],  
26294 <... close resumed> )             =3D 0
27813 <... rt_sigprocmask resumed> [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [],  
26294 rt_sigprocmask(SIG_SETMASK, [],  
27813 <... rt_sigprocmask resumed> NULL, 8) =3D 0
26294 <... rt_sigprocmask resumed> NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
26294 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0},  
26294 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
27813 <... rt_sigaction resumed> {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}=
, 8) =3D 0
26294 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 wait4(-1,  
26294 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
26294 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26294 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26294 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26294 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26294 execve("/usr/bin/flock", ["flock", "-x", "200"], ["SUBSYSTEM=3Dxen-=
backend", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D=
/usr/bin:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:=
/usr/sbin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dx=
en-backend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3D=
backend/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "S=
HLVL=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/flock"]) =3D 0=

26294 brk(0)                            =3D 0x1445000
26294 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f9db81e1000
26294 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f9db81e0000
26294 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26294 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26294 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26294 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7f9db81c6000=

26294 close(3)                          =3D 0
26294 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26294 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26294 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26294 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26294 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26294 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26294 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26294 close(3)                          =3D 0
26294 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f9db81c5000
26294 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f9db81c4000
26294 arch_prctl(ARCH_SET_FS, 0x7f9db81c46e0) =3D 0
26294 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26294 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26294 munmap(0x7f9db81c6000, 103979)    =3D 0
26294 flock(200, LOCK_EX)               =3D 0
26294 exit_group(0)                     =3D ?
27813 <... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], 0,=
 NULL) =3D 26294
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, 0x7fffb0100a24, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0xffffffffffffffff)  =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 pipe([3, 4])                      =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26295
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {0=
x436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26295 close(255 
27813 close(4 
26295 <... close resumed> )             =3D 0
27813 <... close resumed> )             =3D 0
27813 read(3,  
26295 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26295 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26295 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26295 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26295 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26295 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26295 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26295 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {S=
IG_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26295 rt_sigaction(SIGINT, {0x4481f0, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26295 dup2(4, 1)                        =3D 1
26295 close(4)                          =3D 0
26295 close(3)                          =3D 0
26295 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26295 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26295 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26295 write(2, "++ perl -e '\n            open STDIN, \"<&200\" or die $!=
;\n            my $fd_inum =3D (stat STDIN)[1]; die $! unless defined $fd=
_inum;\n            my $file_inum =3D (stat $ARGV[0])[1];\n            pr=
int \"y\\n\" if $fd_inum eq $file_inum;\n", 230) =3D 230
26295 write(2, "                             ' /var/run/xen-hotplug/block=
\n", 58) =3D 58
26295 stat(".", {st_dev=3Dmakedev(8, 2), st_ino=3D2, st_mode=3DS_IFDIR|07=
55, st_nlink=3D24, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
8, st_size=3D4096, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2012/10/08-=
11:13:38, st_ctime=3D2012/10/08-11:13:38}) =3D 0
26295 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26295 access("/usr/bin/perl", X_OK)     =3D 0
26295 access("/usr/bin/perl", R_OK)     =3D 0
26295 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26295 access("/usr/bin/perl", X_OK)     =3D 0
26295 access("/usr/bin/perl", R_OK)     =3D 0
26295 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
481f0, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26295 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26295 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26295 execve("/usr/bin/perl", ["perl", "-e", "\n            open STDIN, \=
"<&200\" or die $!;\n            my $fd_inum =3D (stat STDIN)[1]; die $! =
unless defined $fd_inum;\n            my $file_inum =3D (stat $ARGV[0])[1=
];\n            print \"y\\n\" if $fd_inum eq $file_inum;\n              =
               ", "/var/run/xen-hotplug/block"], ["SUBSYSTEM=3Dxen-backen=
d", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D/usr/b=
in:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:/usr/s=
bin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dxen-bac=
kend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3Dback=
end/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "SHLVL=
=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/perl"]) =3D 0
26295 brk(0)                            =3D 0x2269000
26295 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f364e6f9000
26295 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f364e6f8000
26295 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26295 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64/libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26295 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64", 0x7fff40215ad0) =3D -1 ENOENT (No such file or directory)
26295 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/lib=
perl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26295 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls", 0=
x7fff40215ad0) =3D -1 ENOENT (No such file or directory)
26295 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64/=
libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26295 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64"=
, 0x7fff40215ad0) =3D -1 ENOENT (No such file or directory)
26295 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl=
=2Eso", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26295 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE", 0x7ff=
f40215ad0) =3D -1 ENOENT (No such file or directory)
26295 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26295 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26295 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7f364e6de000=

26295 close(3)                          =3D 0
26295 open("/usr/lib64/libperl.so", O_RDONLY) =3D 3
26295 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\34\203%=
4\0\0\0@\0\0\0\0\0\0\0\360;\23\0\0\0\0\0\0\0\0\0@\0008\0\5\0@\0\35\0\34\0=
\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\200%4\0\0\0\0\0\200%4\0\0\0T\260\22\=
0\0\0\0\0T\260\22\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0X\260\22\0\0\0\=
0\0X\260\262%4\0\0\0X\260\262%4\0\0\0\250\201\0\0\0\0\0\0\350\242\0\0\0\0=
\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\265\22\0\0\0\0\0\370\265\262%4\0\=
0\0\370\265\262%4\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\=
0\0P\345td\4\0\0\0\250u\21\0\0\0\0\0\250u\221%4\0\0\0\250u\221%4\0\0\0D@\=
0\0\0\0\0\0D@\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\7\4\0\0\360\0\0\0\0\1\0\0\16\0\0\0\0\0\0@\0\200\203\200\225\1\22\=
264\3\31\200l\0\32\0 \5\201\0\240\3\2B\0\200\21R \0\22\0\0\16P\20#\10\216=
\334\30\211\"\0\10 \200\3B\220@\0\1\206\20\30\2\3\21\203$!\312A0\224Y\200=
\27\0\242\26\10\24R@\10\200\220\20A\10\0\220\1\200\206\2\10\304\30i\0\220=
\1\1\202\200\22\20\0\n\1H\0\n\2001J \6\31@L\207\20\10\0000\10(\200\2\0\4\=
251t\"\262\310!\212\240\320\"\0\t"..., 832) =3D 832
26295 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2839671, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D2480, st_size=3D1262384, st_atime=3D2012/10/09-12:04:35, st_mtime=3D=
2012/09/11-12:45:05, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26295 mmap(0x3425800000, 3363648, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425800000
26295 mprotect(0x342592c000, 2093056, PROT_NONE) =3D 0
26295 mmap(0x3425b2b000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x12b000) =3D 0x3425b2b000
26295 mmap(0x3425b34000, 4928, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3425b34000
26295 close(3)                          =3D 0
26295 open("/lib64/libresolv.so.2", O_RDONLY) =3D 3
26295 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\2402\0'4\0\=
0\0@\0\0\0\0\0\0\0@a\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\5\0=
\0\0@\0\0\0\0\0\0\0@\0\0'4\0\0\0@\0\0'4\0\0\0\370\1\0\0\0\0\0\0\370\1\0\0=
\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \361\0\0\0\0\0\0 \361\0'4\0\0\0=
 \361\0'4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\=
0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0'4\0\0\0\0\0\0'4\0\0\0$\10\1\0\0\0\0\0$\10=
\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\24\1\0\0\0\0\0\340\24!'4\=
0\0\0\340\24!'4\0\0\0\340\r\0\0\0\0\0\0\0106\0\0\0\0\0\0\0\0 \0\0\0\0\0\2=
\0\0\0\6\0\0\0\350\35\1\0\0\0\0\0\350\35!'4\0\0\0\350\35!'4\0\0\0\300\1\0=
\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\=
0\0\0008\2\0'4\0\0\0008\2\0'4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0=
\0\0\0\0P\345td\4\0\0\0<\361\0\0\0\0\0\0<\361\0'4\0\0\0<\361\0'4\0\0\0,\3=
\0\0\0\0\0\0,\3\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 8=
32
26295 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148119, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D192, st_size=3D92736, st_atime=3D2012/10/09-11:16:43, st_mtime=3D201=
0/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:42}) =3D 0
26295 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f364e6dd000
26295 mmap(0x3427000000, 2181864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3427000000
26295 mprotect(0x3427011000, 2097152, PROT_NONE) =3D 0
26295 mmap(0x3427211000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x11000) =3D 0x3427211000
26295 mmap(0x3427213000, 6888, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3427213000
26295 close(3)                          =3D 0
26295 open("/lib64/libnsl.so.1", O_RDONLY) =3D 3
26295 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240@\340\35=
10\0\0\0@\0\0\0\0\0\0\0\360\265\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0=
\6\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\340\3510\0\0\0@\0\340\3510\0\0\0\370\1=
\0\0\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \33\1\0\0=
\0\0\0 \33\341\3510\0\0\0 \33\341\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\=
0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\340\3510\0\0\0=
\0\0\340\3510\0\0\0\310@\1\0\0\0\0\0\310@\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\=
0\0\6\0\0\0xM\1\0\0\0\0\0xM\1\3520\0\0\0xM\1\3520\0\0\0\310\5\0\0\0\0\0\0=
008-\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250M\1\0\0\0\0\0\250M\1\3=
520\0\0\0\250M\1\3520\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\340\3510\0\0\0008\2\340\351=
0\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0<\33\=
1\0\0\0\0\0<\33\341\3510\0\0\0<\33\341\3510\0\0\0\\\5\0\0\0\0\0\0\\\5\0\0=
\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26295 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147206, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D232, st_size=3D114352, st_atime=3D2012/10/09-12:01:01, st_mtime=3D20=
10/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:44}) =3D 0
26295 mmap(0x30e9e00000, 2194096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9e00000
26295 mprotect(0x30e9e15000, 2093056, PROT_NONE) =3D 0
26295 mmap(0x30ea014000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x14000) =3D 0x30ea014000
26295 mmap(0x30ea016000, 6832, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x30ea016000
26295 close(3)                          =3D 0
26295 open("/lib64/libdl.so.2", O_RDONLY) =3D 3
26295 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\16`\3500=
\0\0\0@\0\0\0\0\0\0\0@R\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0`\3500\0\0\0@\0`\3500\0\0\0\370\1\0\0\0\0\0\0\37=
0\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\300\32\0\0\0\0\0\0\300\3=
2`\3500\0\0\0\300\32`\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0`\3500\0\0\0\0\0`\3500\0\0\=
0\224\37\0\0\0\0\0\0\224\37\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0`-\=
0\0\0\0\0\0`-\200\3500\0\0\0`-\200\3500\0\0\0 \3\0\0\0\0\0\0\240\3\0\0\0\=
0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\240-\0\0\0\0\0\0\240-\200\3500\0\0\0=
\240-\200\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0=
\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2`\3500\0\0\0008\2`\3500\0\0\0 \0\0\=
0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\334\32\0\0\0\0\0\=
0\334\32`\3500\0\0\0\334\32`\3500\0\0\0\264\0\0\0\0\0\0\0\264\0\0\0\0\0\0=
\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26295 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147322, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D48, st_size=3D23360, st_atime=3D2012/10/09-11:13:54, st_mtime=3D2010=
/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26295 mmap(0x30e8600000, 2109696, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8600000
26295 mprotect(0x30e8602000, 2097152, PROT_NONE) =3D 0
26295 mmap(0x30e8802000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x2000) =3D 0x30e8802000
26295 close(3)                          =3D 0
26295 open("/lib64/libm.so.6", O_RDONLY) =3D 3
26295 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`>\240\3510\=
0\0\0@\0\0\0\0\0\0\0\240X\t\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0)\0(\0\6\0\0\=
0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3510\0\0\0@\0\240\3510\0\0\0\370\1\0\0\0\=
0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\360\303\7\0\0\0\=
0\0\360\303\247\3510\0\0\0\360\303\247\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0=
\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3510\=
0\0\0\0\0\240\3510\0\0\0000\22\10\0\0\0\0\0000\22\10\0\0\0\0\0\0\0 \0\0\0=
\0\0\1\0\0\0\6\0\0\0\270\35\10\0\0\0\0\0\270\35\310\3510\0\0\0\270\35\310=
\3510\0\0\0\320\2\0\0\0\0\0\0 \3\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0=
\0\350\35\10\0\0\0\0\0\350\35\310\3510\0\0\0\350\35\310\3510\0\0\0\300\1\=
0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0=
\0\0\0008\2\240\3510\0\0\0008\2\240\3510\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\f\304\7\0\0\0\0\0\f\304\247\3510\0\0\0=
\f\304\247\3510\0\0\0\374\r\0\0\0\0\0\0\374\r\0\0\0\0\0\0\4\0\0\0\0\0\0\0=
Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0"..., 832) =3D 832
26295 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147337, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D1216, st_size=3D615136, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2=
010/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26295 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f364e6dc000
26295 mmap(0x30e9a00000, 2629848, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9a00000
26295 mprotect(0x30e9a82000, 2093056, PROT_NONE) =3D 0
26295 mmap(0x30e9c81000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x81000) =3D 0x30e9c81000
26295 close(3)                          =3D 0
26295 open("/lib64/libcrypt.so.1", O_RDONLY) =3D 3
26295 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\t\300%4=
\0\0\0@\0\0\0\0\0\0\0\30\265\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\=
0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\300%4\0\0\0@\0\300%4\0\0\0\370\1\0\0\0\0\=
0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340}\0\0\0\0\0\0\3=
40}\300%4\0\0\0\340}\300%4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\300%4\0\0\0\0\0\300%4\0\0\=
0\4\205\0\0\0\0\0\0\4\205\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\310\=
215\0\0\0\0\0\0\310\215\340%4\0\0\0\310\215\340%4\0\0\0\250\2\0\0\0\0\0\0=
\370\343\2\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\215\0\0\0\0\0\0\3=
70\215\340%4\0\0\0\370\215\340%4\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\=
0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\300%4\0\0\0008\2=
\300%4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0=
\374}\0\0\0\0\0\0\374}\300%4\0\0\0\374}\300%4\0\0\0\34\1\0\0\0\0\0\0\34\1=
\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26295 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148123, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D96, st_size=3D48600, st_atime=3D2012/10/09-12:01:01, st_mtime=3D2010=
/07/28-03:52:39, st_ctime=3D2012/09/11-14:53:52}) =3D 0
26295 mmap(0x3425c00000, 2322880, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425c00000
26295 mprotect(0x3425c09000, 2093056, PROT_NONE) =3D 0
26295 mmap(0x3425e08000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x8000) =3D 0x3425e08000
26295 mmap(0x3425e0a000, 184768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FI=
XED|MAP_ANONYMOUS, -1, 0) =3D 0x3425e0a000
26295 close(3)                          =3D 0
26295 open("/lib64/libutil.so.1", O_RDONLY) =3D 3
26295 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\16\0(4\=
0\0\0@\0\0\0\0\0\0\0(>\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0\0(4\0\0\0@\0\0(4\0\0\0\370\1\0\0\0\0\0\0\370\1\=
0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340\26\0\0\0\0\0\0\340\26\0(=
4\0\0\0\340\26\0(4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0=
\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0(4\0\0\0\0\0\0(4\0\0\0P\32\0\0\0\=
0\0\0P\32\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\35\0\0\0\0\0\0\3=
40\35 (4\0\0\0\340\35 (4\0\0\0 \3\0\0\0\0\0\0000\3\0\0\0\0\0\0\0\0 \0\0\0=
\0\0\2\0\0\0\6\0\0\0\20\36\0\0\0\0\0\0\20\36 (4\0\0\0\20\36 (4\0\0\0\300\=
1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0=
\0\0\0\0008\2\0(4\0\0\0008\2\0(4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\=
0\0\0\0\0\0P\345td\4\0\0\0\374\26\0\0\0\0\0\0\374\26\0(4\0\0\0\374\26\0(4=
\0\0\0D\0\0\0\0\0\0\0D\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8=
32) =3D 832
26295 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147063, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D40, st_size=3D18152, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2010=
/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:49}) =3D 0
26295 mmap(0x3428000000, 2105616, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3428000000
26295 mprotect(0x3428002000, 2093056, PROT_NONE) =3D 0
26295 mmap(0x3428201000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x1000) =3D 0x3428201000
26295 close(3)                          =3D 0
26295 open("/lib64/libpthread.so.0", O_RDONLY) =3D 3
26295 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240W\240\35=
00\0\0\0@\0\0\0\0\0\0\0\340/\2\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0'\0&\0\6\0=
\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3500\0\0\0@\0\240\3500\0\0\0\370\1\0\0=
\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\240\t\1\0\0\0=
\0\0\240\t\241\3500\0\0\0\240\t\241\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\=
0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3500\0\0=
\0\0\0\240\3500\0\0\0pZ\1\0\0\0\0\0pZ\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\=
6\0\0\0\270[\1\0\0\0\0\0\270[\301\3500\0\0\0\270[\301\3500\0\0\0\230\6\0\=
0\0\0\0\0\270G\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250]\1\0\0\0\0\=
0\250]\301\3500\0\0\0\250]\301\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0=
\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\240\3500\0\0\=
0008\2\240\3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345t=
d\4\0\0\0\274\t\1\0\0\0\0\0\274\t\241\3500\0\0\0\274\t\241\3500\0\0\0\344=
\t\0\0\0\0\0\0\344\t\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =
=3D 832
26295 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147328, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D296, st_size=3D145824, st_atime=3D2012/10/09-11:16:43, st_mtime=3D20=
10/07/28-03:52:41, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26295 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f364e6db000
26295 mmap(0x30e8a00000, 2204528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8a00000
26295 mprotect(0x30e8a16000, 2093056, PROT_NONE) =3D 0
26295 mmap(0x30e8c15000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x15000) =3D 0x30e8c15000
26295 mmap(0x30e8c17000, 13168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8c17000
26295 close(3)                          =3D 0
26295 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26295 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26295 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26295 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26295 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26295 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26295 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26295 close(3)                          =3D 0
26295 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f364e6da000
26295 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f364e6d9000
26295 arch_prctl(ARCH_SET_FS, 0x7f364e6d96e0) =3D 0
26295 mprotect(0x3427211000, 4096, PROT_READ) =3D 0
26295 mprotect(0x30ea014000, 4096, PROT_READ) =3D 0
26295 mprotect(0x30e8802000, 4096, PROT_READ) =3D 0
26295 mprotect(0x30e9c81000, 4096, PROT_READ) =3D 0
26295 mprotect(0x3425e08000, 4096, PROT_READ) =3D 0
26295 mprotect(0x3428201000, 4096, PROT_READ) =3D 0
26295 mprotect(0x30e8c15000, 4096, PROT_READ) =3D 0
26295 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26295 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26295 munmap(0x7f364e6de000, 103979)    =3D 0
26295 set_tid_address(0x7f364e6d9770)   =3D 26295
26295 set_robust_list(0x7f364e6d9780, 0x18) =3D 0
26295 futex(0x7fff402165fc, FUTEX_WAKE_PRIVATE, 1) =3D 0
26295 rt_sigaction(SIGRTMIN, {0x30e8a05380, [], SA_RESTORER|SA_SIGINFO, 0=
x30e8a0eb10}, NULL, 8) =3D 0
26295 rt_sigaction(SIGRT_1, {0x30e8a052b0, [], SA_RESTORER|SA_RESTART|SA_=
SIGINFO, 0x30e8a0eb10}, NULL, 8) =3D 0
26295 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) =3D 0
26295 getrlimit(RLIMIT_STACK, {rlim_cur=3D8192*1024, rlim_max=3DRLIM_INFI=
NITY}) =3D 0
26295 rt_sigaction(SIGFPE, {0x1, [FPE], SA_RESTORER|SA_RESTART, 0x30e8230=
2d0}, {SIG_DFL, [], 0}, 8) =3D 0
26295 brk(0)                            =3D 0x2269000
26295 brk(0x228b000)                    =3D 0x228b000
26295 getuid()                          =3D 0
26295 geteuid()                         =3D 0
26295 getgid()                          =3D 0
26295 getegid()                         =3D 0
26295 mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,=
 -1, 0) =3D 0x7f364e6b8000
26295 open("/dev/urandom", O_RDONLY)    =3D 3
26295 read(3, "\361\r9\204", 4)         =3D 4
26295 close(3)                          =3D 0
26295 stat("/usr/lib64/perl5/site_perl/5.8.7/x86_64-linux-thread-multi", =
0x7fff402162b0) =3D -1 ENOENT (No such file or directory)
26295 stat("/usr/lib/perl5/site_perl/5.8.7", 0x7fff402162b0) =3D -1 ENOEN=
T (No such file or directory)
26295 stat("/usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi", =
0x7fff402162b0) =3D -1 ENOENT (No such file or directory)
26295 stat("/usr/lib/perl5/site_perl/5.8.6", 0x7fff402162b0) =3D -1 ENOEN=
T (No such file or directory)
26295 stat("/usr/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi", =
0x7fff402162b0) =3D -1 ENOENT (No such file or directory)
26295 stat("/usr/lib/perl5/site_perl/5.8.5", 0x7fff402162b0) =3D -1 ENOEN=
T (No such file or directory)
26295 stat("/usr/lib64/perl5/vendor_perl/5.8.7/x86_64-linux-thread-multi"=
, 0x7fff402162b0) =3D -1 ENOENT (No such file or directory)
26295 stat("/usr/lib/perl5/vendor_perl/5.8.7", 0x7fff402162b0) =3D -1 ENO=
ENT (No such file or directory)
26295 stat("/usr/lib64/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi"=
, 0x7fff402162b0) =3D -1 ENOENT (No such file or directory)
26295 stat("/usr/lib/perl5/vendor_perl/5.8.6", 0x7fff402162b0) =3D -1 ENO=
ENT (No such file or directory)
26295 stat("/usr/lib64/perl5/vendor_perl/5.8.5/x86_64-linux-thread-multi"=
, 0x7fff402162b0) =3D -1 ENOENT (No such file or directory)
26295 stat("/usr/lib/perl5/vendor_perl/5.8.5", 0x7fff402162b0) =3D -1 ENO=
ENT (No such file or directory)
26295 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff40216070) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26295 lseek(0, 0, SEEK_CUR)             =3D 0
26295 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff40216070) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26295 lseek(1, 0, SEEK_CUR)             =3D -1 ESPIPE (Illegal seek)
26295 ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff40216080) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26295 lseek(2, 0, SEEK_CUR)             =3D 593661073
26295 open("/dev/null", O_RDONLY)       =3D 3
26295 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff40216180) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26295 lseek(3, 0, SEEK_CUR)             =3D 0
26295 fcntl(3, F_SETFD, FD_CLOEXEC)     =3D 0
26295 fstat(3, {st_dev=3Dmakedev(0, 16), st_ino=3D584, st_mode=3DS_IFCHR|=
0666, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
0, st_rdev=3Dmakedev(1, 3), st_atime=3D2012/10/08-11:13:26, st_mtime=3D20=
12/10/08-11:13:26, st_ctime=3D2012/10/08-11:13:27}) =3D 0
26295 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) =3D 0
26295 readlink("/proc/self/exe", "/usr/bin/perl"..., 4095) =3D 13
26295 brk(0x22ac000)                    =3D 0x22ac000
26295 close(3)                          =3D 0
26295 dup(200)                          =3D 3
26295 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff40216050) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26295 lseek(3, 0, SEEK_CUR)             =3D 0
26295 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26295 dup2(3, 0)                        =3D 0
26295 close(3)                          =3D 0
26295 fcntl(0, F_SETFD, 0)              =3D 0
26295 fstat(0, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26295 stat("/var/run/xen-hotplug/block", {st_dev=3Dmakedev(8, 2), st_ino=3D=
2801738, st_mode=3DS_IFREG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st=
_blksize=3D4096, st_blocks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:=
24, st_mtime=3D2012/10/09-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D =
0
26295 exit_group(0)                     =3D ?
27813 <... read resumed> "", 128)       =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], WNOHANG, NUL=
L) =3D 26295
27813 wait4(-1, 0x7fffb0100a64, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0)                   =3D 0
27813 close(3)                          =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 write(2, "+ rightfile=3D\n", 13)    =3D 13
27813 write(2, "+ '[' x =3D xy ']'\n", 17) =3D 17
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ true\n", 7)           =3D 7
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ eval 'exec 200>>/var/run/xen-hotplug/block'\n", 46) =3D=
 46
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 write(2, "++ exec\n", 8)          =3D 8
27813 open("/var/run/xen-hotplug/block", O_WRONLY|O_CREAT|O_APPEND, 0666)=
 =3D 3
27813 fcntl(200, F_GETFD)               =3D 0
27813 fcntl(200, F_DUPFD, 10)           =3D 10
27813 fcntl(200, F_GETFD)               =3D 0
27813 dup2(3, 200)                      =3D 200
27813 close(3)                          =3D 0
27813 dup2(10, 200)                     =3D 200
27813 fcntl(10, F_GETFD)                =3D 0
27813 close(10)                         =3D 0
27813 write(2, "+ flock -x 200\n", 15)  =3D 15
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [INT CHLD], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [INT CHLD], NULL, 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26296
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26296 close(255 
27813 rt_sigprocmask(SIG_BLOCK, [CHLD],  
26296 <... close resumed> )             =3D 0
27813 <... rt_sigprocmask resumed> [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [],  
26296 rt_sigprocmask(SIG_SETMASK, [],  
27813 <... rt_sigprocmask resumed> NULL, 8) =3D 0
26296 <... rt_sigprocmask resumed> NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
26296 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0},  
26296 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
27813 <... rt_sigaction resumed> {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}=
, 8) =3D 0
26296 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 wait4(-1,  
26296 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
26296 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26296 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26296 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26296 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26296 execve("/usr/bin/flock", ["flock", "-x", "200"], ["SUBSYSTEM=3Dxen-=
backend", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D=
/usr/bin:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:=
/usr/sbin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dx=
en-backend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3D=
backend/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "S=
HLVL=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/flock"]) =3D 0=

26296 brk(0)                            =3D 0x7fd000
26296 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fab26b69000
26296 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fab26b68000
26296 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26296 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26296 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26296 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7fab26b4e000=

26296 close(3)                          =3D 0
26296 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26296 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26296 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26296 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26296 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26296 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26296 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26296 close(3)                          =3D 0
26296 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fab26b4d000
26296 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fab26b4c000
26296 arch_prctl(ARCH_SET_FS, 0x7fab26b4c6e0) =3D 0
26296 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26296 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26296 munmap(0x7fab26b4e000, 103979)    =3D 0
26296 flock(200, LOCK_EX)               =3D 0
26296 exit_group(0)                     =3D ?
27813 <... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], 0,=
 NULL) =3D 26296
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, 0x7fffb0100a24, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0xffffffffffffffff)  =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 pipe([3, 4])                      =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26297
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {0=
x436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26297 close(255 
27813 close(4 
26297 <... close resumed> )             =3D 0
27813 <... close resumed> )             =3D 0
27813 read(3,  
26297 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26297 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26297 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26297 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26297 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26297 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26297 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26297 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {S=
IG_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26297 rt_sigaction(SIGINT, {0x4481f0, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26297 dup2(4, 1)                        =3D 1
26297 close(4)                          =3D 0
26297 close(3)                          =3D 0
26297 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26297 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26297 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26297 write(2, "++ perl -e '\n            open STDIN, \"<&200\" or die $!=
;\n            my $fd_inum =3D (stat STDIN)[1]; die $! unless defined $fd=
_inum;\n            my $file_inum =3D (stat $ARGV[0])[1];\n            pr=
int \"y\\n\" if $fd_inum eq $file_inum;\n", 230) =3D 230
26297 write(2, "                             ' /var/run/xen-hotplug/block=
\n", 58) =3D 58
26297 stat(".", {st_dev=3Dmakedev(8, 2), st_ino=3D2, st_mode=3DS_IFDIR|07=
55, st_nlink=3D24, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
8, st_size=3D4096, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2012/10/08-=
11:13:38, st_ctime=3D2012/10/08-11:13:38}) =3D 0
26297 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26297 access("/usr/bin/perl", X_OK)     =3D 0
26297 access("/usr/bin/perl", R_OK)     =3D 0
26297 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26297 access("/usr/bin/perl", X_OK)     =3D 0
26297 access("/usr/bin/perl", R_OK)     =3D 0
26297 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
481f0, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26297 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26297 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26297 execve("/usr/bin/perl", ["perl", "-e", "\n            open STDIN, \=
"<&200\" or die $!;\n            my $fd_inum =3D (stat STDIN)[1]; die $! =
unless defined $fd_inum;\n            my $file_inum =3D (stat $ARGV[0])[1=
];\n            print \"y\\n\" if $fd_inum eq $file_inum;\n              =
               ", "/var/run/xen-hotplug/block"], ["SUBSYSTEM=3Dxen-backen=
d", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D/usr/b=
in:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:/usr/s=
bin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dxen-bac=
kend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3Dback=
end/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "SHLVL=
=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/perl"]) =3D 0
26297 brk(0)                            =3D 0x23d6000
26297 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fad691c1000
26297 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fad691c0000
26297 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26297 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64/libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26297 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64", 0x7fff8c5a4d10) =3D -1 ENOENT (No such file or directory)
26297 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/lib=
perl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26297 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls", 0=
x7fff8c5a4d10) =3D -1 ENOENT (No such file or directory)
26297 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64/=
libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26297 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64"=
, 0x7fff8c5a4d10) =3D -1 ENOENT (No such file or directory)
26297 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl=
=2Eso", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26297 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE", 0x7ff=
f8c5a4d10) =3D -1 ENOENT (No such file or directory)
26297 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26297 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26297 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7fad691a6000=

26297 close(3)                          =3D 0
26297 open("/usr/lib64/libperl.so", O_RDONLY) =3D 3
26297 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\34\203%=
4\0\0\0@\0\0\0\0\0\0\0\360;\23\0\0\0\0\0\0\0\0\0@\0008\0\5\0@\0\35\0\34\0=
\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\200%4\0\0\0\0\0\200%4\0\0\0T\260\22\=
0\0\0\0\0T\260\22\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0X\260\22\0\0\0\=
0\0X\260\262%4\0\0\0X\260\262%4\0\0\0\250\201\0\0\0\0\0\0\350\242\0\0\0\0=
\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\265\22\0\0\0\0\0\370\265\262%4\0\=
0\0\370\265\262%4\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\=
0\0P\345td\4\0\0\0\250u\21\0\0\0\0\0\250u\221%4\0\0\0\250u\221%4\0\0\0D@\=
0\0\0\0\0\0D@\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\7\4\0\0\360\0\0\0\0\1\0\0\16\0\0\0\0\0\0@\0\200\203\200\225\1\22\=
264\3\31\200l\0\32\0 \5\201\0\240\3\2B\0\200\21R \0\22\0\0\16P\20#\10\216=
\334\30\211\"\0\10 \200\3B\220@\0\1\206\20\30\2\3\21\203$!\312A0\224Y\200=
\27\0\242\26\10\24R@\10\200\220\20A\10\0\220\1\200\206\2\10\304\30i\0\220=
\1\1\202\200\22\20\0\n\1H\0\n\2001J \6\31@L\207\20\10\0000\10(\200\2\0\4\=
251t\"\262\310!\212\240\320\"\0\t"..., 832) =3D 832
26297 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2839671, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D2480, st_size=3D1262384, st_atime=3D2012/10/09-12:04:35, st_mtime=3D=
2012/09/11-12:45:05, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26297 mmap(0x3425800000, 3363648, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425800000
26297 mprotect(0x342592c000, 2093056, PROT_NONE) =3D 0
26297 mmap(0x3425b2b000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x12b000) =3D 0x3425b2b000
26297 mmap(0x3425b34000, 4928, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3425b34000
26297 close(3)                          =3D 0
26297 open("/lib64/libresolv.so.2", O_RDONLY) =3D 3
26297 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\2402\0'4\0\=
0\0@\0\0\0\0\0\0\0@a\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\5\0=
\0\0@\0\0\0\0\0\0\0@\0\0'4\0\0\0@\0\0'4\0\0\0\370\1\0\0\0\0\0\0\370\1\0\0=
\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \361\0\0\0\0\0\0 \361\0'4\0\0\0=
 \361\0'4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\=
0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0'4\0\0\0\0\0\0'4\0\0\0$\10\1\0\0\0\0\0$\10=
\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\24\1\0\0\0\0\0\340\24!'4\=
0\0\0\340\24!'4\0\0\0\340\r\0\0\0\0\0\0\0106\0\0\0\0\0\0\0\0 \0\0\0\0\0\2=
\0\0\0\6\0\0\0\350\35\1\0\0\0\0\0\350\35!'4\0\0\0\350\35!'4\0\0\0\300\1\0=
\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\=
0\0\0008\2\0'4\0\0\0008\2\0'4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0=
\0\0\0\0P\345td\4\0\0\0<\361\0\0\0\0\0\0<\361\0'4\0\0\0<\361\0'4\0\0\0,\3=
\0\0\0\0\0\0,\3\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 8=
32
26297 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148119, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D192, st_size=3D92736, st_atime=3D2012/10/09-11:16:43, st_mtime=3D201=
0/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:42}) =3D 0
26297 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fad691a5000
26297 mmap(0x3427000000, 2181864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3427000000
26297 mprotect(0x3427011000, 2097152, PROT_NONE) =3D 0
26297 mmap(0x3427211000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x11000) =3D 0x3427211000
26297 mmap(0x3427213000, 6888, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3427213000
26297 close(3)                          =3D 0
26297 open("/lib64/libnsl.so.1", O_RDONLY) =3D 3
26297 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240@\340\35=
10\0\0\0@\0\0\0\0\0\0\0\360\265\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0=
\6\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\340\3510\0\0\0@\0\340\3510\0\0\0\370\1=
\0\0\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \33\1\0\0=
\0\0\0 \33\341\3510\0\0\0 \33\341\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\=
0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\340\3510\0\0\0=
\0\0\340\3510\0\0\0\310@\1\0\0\0\0\0\310@\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\=
0\0\6\0\0\0xM\1\0\0\0\0\0xM\1\3520\0\0\0xM\1\3520\0\0\0\310\5\0\0\0\0\0\0=
008-\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250M\1\0\0\0\0\0\250M\1\3=
520\0\0\0\250M\1\3520\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\340\3510\0\0\0008\2\340\351=
0\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0<\33\=
1\0\0\0\0\0<\33\341\3510\0\0\0<\33\341\3510\0\0\0\\\5\0\0\0\0\0\0\\\5\0\0=
\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26297 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147206, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D232, st_size=3D114352, st_atime=3D2012/10/09-12:01:01, st_mtime=3D20=
10/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:44}) =3D 0
26297 mmap(0x30e9e00000, 2194096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9e00000
26297 mprotect(0x30e9e15000, 2093056, PROT_NONE) =3D 0
26297 mmap(0x30ea014000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x14000) =3D 0x30ea014000
26297 mmap(0x30ea016000, 6832, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x30ea016000
26297 close(3)                          =3D 0
26297 open("/lib64/libdl.so.2", O_RDONLY) =3D 3
26297 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\16`\3500=
\0\0\0@\0\0\0\0\0\0\0@R\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0`\3500\0\0\0@\0`\3500\0\0\0\370\1\0\0\0\0\0\0\37=
0\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\300\32\0\0\0\0\0\0\300\3=
2`\3500\0\0\0\300\32`\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0`\3500\0\0\0\0\0`\3500\0\0\=
0\224\37\0\0\0\0\0\0\224\37\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0`-\=
0\0\0\0\0\0`-\200\3500\0\0\0`-\200\3500\0\0\0 \3\0\0\0\0\0\0\240\3\0\0\0\=
0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\240-\0\0\0\0\0\0\240-\200\3500\0\0\0=
\240-\200\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0=
\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2`\3500\0\0\0008\2`\3500\0\0\0 \0\0\=
0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\334\32\0\0\0\0\0\=
0\334\32`\3500\0\0\0\334\32`\3500\0\0\0\264\0\0\0\0\0\0\0\264\0\0\0\0\0\0=
\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26297 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147322, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D48, st_size=3D23360, st_atime=3D2012/10/09-11:13:54, st_mtime=3D2010=
/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26297 mmap(0x30e8600000, 2109696, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8600000
26297 mprotect(0x30e8602000, 2097152, PROT_NONE) =3D 0
26297 mmap(0x30e8802000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x2000) =3D 0x30e8802000
26297 close(3)                          =3D 0
26297 open("/lib64/libm.so.6", O_RDONLY) =3D 3
26297 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`>\240\3510\=
0\0\0@\0\0\0\0\0\0\0\240X\t\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0)\0(\0\6\0\0\=
0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3510\0\0\0@\0\240\3510\0\0\0\370\1\0\0\0\=
0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\360\303\7\0\0\0\=
0\0\360\303\247\3510\0\0\0\360\303\247\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0=
\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3510\=
0\0\0\0\0\240\3510\0\0\0000\22\10\0\0\0\0\0000\22\10\0\0\0\0\0\0\0 \0\0\0=
\0\0\1\0\0\0\6\0\0\0\270\35\10\0\0\0\0\0\270\35\310\3510\0\0\0\270\35\310=
\3510\0\0\0\320\2\0\0\0\0\0\0 \3\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0=
\0\350\35\10\0\0\0\0\0\350\35\310\3510\0\0\0\350\35\310\3510\0\0\0\300\1\=
0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0=
\0\0\0008\2\240\3510\0\0\0008\2\240\3510\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\f\304\7\0\0\0\0\0\f\304\247\3510\0\0\0=
\f\304\247\3510\0\0\0\374\r\0\0\0\0\0\0\374\r\0\0\0\0\0\0\4\0\0\0\0\0\0\0=
Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0"..., 832) =3D 832
26297 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147337, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D1216, st_size=3D615136, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2=
010/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26297 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fad691a4000
26297 mmap(0x30e9a00000, 2629848, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9a00000
26297 mprotect(0x30e9a82000, 2093056, PROT_NONE) =3D 0
26297 mmap(0x30e9c81000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x81000) =3D 0x30e9c81000
26297 close(3)                          =3D 0
26297 open("/lib64/libcrypt.so.1", O_RDONLY) =3D 3
26297 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\t\300%4=
\0\0\0@\0\0\0\0\0\0\0\30\265\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\=
0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\300%4\0\0\0@\0\300%4\0\0\0\370\1\0\0\0\0\=
0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340}\0\0\0\0\0\0\3=
40}\300%4\0\0\0\340}\300%4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\300%4\0\0\0\0\0\300%4\0\0\=
0\4\205\0\0\0\0\0\0\4\205\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\310\=
215\0\0\0\0\0\0\310\215\340%4\0\0\0\310\215\340%4\0\0\0\250\2\0\0\0\0\0\0=
\370\343\2\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\215\0\0\0\0\0\0\3=
70\215\340%4\0\0\0\370\215\340%4\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\=
0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\300%4\0\0\0008\2=
\300%4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0=
\374}\0\0\0\0\0\0\374}\300%4\0\0\0\374}\300%4\0\0\0\34\1\0\0\0\0\0\0\34\1=
\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26297 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148123, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D96, st_size=3D48600, st_atime=3D2012/10/09-12:01:01, st_mtime=3D2010=
/07/28-03:52:39, st_ctime=3D2012/09/11-14:53:52}) =3D 0
26297 mmap(0x3425c00000, 2322880, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425c00000
26297 mprotect(0x3425c09000, 2093056, PROT_NONE) =3D 0
26297 mmap(0x3425e08000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x8000) =3D 0x3425e08000
26297 mmap(0x3425e0a000, 184768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FI=
XED|MAP_ANONYMOUS, -1, 0) =3D 0x3425e0a000
26297 close(3)                          =3D 0
26297 open("/lib64/libutil.so.1", O_RDONLY) =3D 3
26297 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\16\0(4\=
0\0\0@\0\0\0\0\0\0\0(>\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0\0(4\0\0\0@\0\0(4\0\0\0\370\1\0\0\0\0\0\0\370\1\=
0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340\26\0\0\0\0\0\0\340\26\0(=
4\0\0\0\340\26\0(4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0=
\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0(4\0\0\0\0\0\0(4\0\0\0P\32\0\0\0\=
0\0\0P\32\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\35\0\0\0\0\0\0\3=
40\35 (4\0\0\0\340\35 (4\0\0\0 \3\0\0\0\0\0\0000\3\0\0\0\0\0\0\0\0 \0\0\0=
\0\0\2\0\0\0\6\0\0\0\20\36\0\0\0\0\0\0\20\36 (4\0\0\0\20\36 (4\0\0\0\300\=
1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0=
\0\0\0\0008\2\0(4\0\0\0008\2\0(4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\=
0\0\0\0\0\0P\345td\4\0\0\0\374\26\0\0\0\0\0\0\374\26\0(4\0\0\0\374\26\0(4=
\0\0\0D\0\0\0\0\0\0\0D\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8=
32) =3D 832
26297 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147063, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D40, st_size=3D18152, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2010=
/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:49}) =3D 0
26297 mmap(0x3428000000, 2105616, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3428000000
26297 mprotect(0x3428002000, 2093056, PROT_NONE) =3D 0
26297 mmap(0x3428201000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x1000) =3D 0x3428201000
26297 close(3)                          =3D 0
26297 open("/lib64/libpthread.so.0", O_RDONLY) =3D 3
26297 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240W\240\35=
00\0\0\0@\0\0\0\0\0\0\0\340/\2\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0'\0&\0\6\0=
\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3500\0\0\0@\0\240\3500\0\0\0\370\1\0\0=
\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\240\t\1\0\0\0=
\0\0\240\t\241\3500\0\0\0\240\t\241\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\=
0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3500\0\0=
\0\0\0\240\3500\0\0\0pZ\1\0\0\0\0\0pZ\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\=
6\0\0\0\270[\1\0\0\0\0\0\270[\301\3500\0\0\0\270[\301\3500\0\0\0\230\6\0\=
0\0\0\0\0\270G\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250]\1\0\0\0\0\=
0\250]\301\3500\0\0\0\250]\301\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0=
\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\240\3500\0\0\=
0008\2\240\3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345t=
d\4\0\0\0\274\t\1\0\0\0\0\0\274\t\241\3500\0\0\0\274\t\241\3500\0\0\0\344=
\t\0\0\0\0\0\0\344\t\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =
=3D 832
26297 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147328, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D296, st_size=3D145824, st_atime=3D2012/10/09-11:16:43, st_mtime=3D20=
10/07/28-03:52:41, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26297 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fad691a3000
26297 mmap(0x30e8a00000, 2204528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8a00000
26297 mprotect(0x30e8a16000, 2093056, PROT_NONE) =3D 0
26297 mmap(0x30e8c15000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x15000) =3D 0x30e8c15000
26297 mmap(0x30e8c17000, 13168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8c17000
26297 close(3)                          =3D 0
26297 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26297 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26297 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26297 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26297 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26297 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26297 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26297 close(3)                          =3D 0
26297 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fad691a2000
26297 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fad691a1000
26297 arch_prctl(ARCH_SET_FS, 0x7fad691a16e0) =3D 0
26297 mprotect(0x3427211000, 4096, PROT_READ) =3D 0
26297 mprotect(0x30ea014000, 4096, PROT_READ) =3D 0
26297 mprotect(0x30e8802000, 4096, PROT_READ) =3D 0
26297 mprotect(0x30e9c81000, 4096, PROT_READ) =3D 0
26297 mprotect(0x3425e08000, 4096, PROT_READ) =3D 0
26297 mprotect(0x3428201000, 4096, PROT_READ) =3D 0
26297 mprotect(0x30e8c15000, 4096, PROT_READ) =3D 0
26297 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26297 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26297 munmap(0x7fad691a6000, 103979)    =3D 0
26297 set_tid_address(0x7fad691a1770)   =3D 26297
26297 set_robust_list(0x7fad691a1780, 0x18) =3D 0
26297 futex(0x7fff8c5a583c, FUTEX_WAKE_PRIVATE, 1) =3D 0
26297 rt_sigaction(SIGRTMIN, {0x30e8a05380, [], SA_RESTORER|SA_SIGINFO, 0=
x30e8a0eb10}, NULL, 8) =3D 0
26297 rt_sigaction(SIGRT_1, {0x30e8a052b0, [], SA_RESTORER|SA_RESTART|SA_=
SIGINFO, 0x30e8a0eb10}, NULL, 8) =3D 0
26297 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) =3D 0
26297 getrlimit(RLIMIT_STACK, {rlim_cur=3D8192*1024, rlim_max=3DRLIM_INFI=
NITY}) =3D 0
26297 rt_sigaction(SIGFPE, {0x1, [FPE], SA_RESTORER|SA_RESTART, 0x30e8230=
2d0}, {SIG_DFL, [], 0}, 8) =3D 0
26297 brk(0)                            =3D 0x23d6000
26297 brk(0x23f8000)                    =3D 0x23f8000
26297 getuid()                          =3D 0
26297 geteuid()                         =3D 0
26297 getgid()                          =3D 0
26297 getegid()                         =3D 0
26297 mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,=
 -1, 0) =3D 0x7fad69180000
26297 open("/dev/urandom", O_RDONLY)    =3D 3
26297 read(3, "*\214J\323", 4)          =3D 4
26297 close(3)                          =3D 0
26297 stat("/usr/lib64/perl5/site_perl/5.8.7/x86_64-linux-thread-multi", =
0x7fff8c5a54f0) =3D -1 ENOENT (No such file or directory)
26297 stat("/usr/lib/perl5/site_perl/5.8.7", 0x7fff8c5a54f0) =3D -1 ENOEN=
T (No such file or directory)
26297 stat("/usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi", =
0x7fff8c5a54f0) =3D -1 ENOENT (No such file or directory)
26297 stat("/usr/lib/perl5/site_perl/5.8.6", 0x7fff8c5a54f0) =3D -1 ENOEN=
T (No such file or directory)
26297 stat("/usr/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi", =
0x7fff8c5a54f0) =3D -1 ENOENT (No such file or directory)
26297 stat("/usr/lib/perl5/site_perl/5.8.5", 0x7fff8c5a54f0) =3D -1 ENOEN=
T (No such file or directory)
26297 stat("/usr/lib64/perl5/vendor_perl/5.8.7/x86_64-linux-thread-multi"=
, 0x7fff8c5a54f0) =3D -1 ENOENT (No such file or directory)
26297 stat("/usr/lib/perl5/vendor_perl/5.8.7", 0x7fff8c5a54f0) =3D -1 ENO=
ENT (No such file or directory)
26297 stat("/usr/lib64/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi"=
, 0x7fff8c5a54f0) =3D -1 ENOENT (No such file or directory)
26297 stat("/usr/lib/perl5/vendor_perl/5.8.6", 0x7fff8c5a54f0) =3D -1 ENO=
ENT (No such file or directory)
26297 stat("/usr/lib64/perl5/vendor_perl/5.8.5/x86_64-linux-thread-multi"=
, 0x7fff8c5a54f0) =3D -1 ENOENT (No such file or directory)
26297 stat("/usr/lib/perl5/vendor_perl/5.8.5", 0x7fff8c5a54f0) =3D -1 ENO=
ENT (No such file or directory)
26297 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff8c5a52b0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26297 lseek(0, 0, SEEK_CUR)             =3D 0
26297 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff8c5a52b0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26297 lseek(1, 0, SEEK_CUR)             =3D -1 ESPIPE (Illegal seek)
26297 ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff8c5a52c0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26297 lseek(2, 0, SEEK_CUR)             =3D 593661467
26297 open("/dev/null", O_RDONLY)       =3D 3
26297 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff8c5a53c0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26297 lseek(3, 0, SEEK_CUR)             =3D 0
26297 fcntl(3, F_SETFD, FD_CLOEXEC)     =3D 0
26297 fstat(3, {st_dev=3Dmakedev(0, 16), st_ino=3D584, st_mode=3DS_IFCHR|=
0666, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
0, st_rdev=3Dmakedev(1, 3), st_atime=3D2012/10/08-11:13:26, st_mtime=3D20=
12/10/08-11:13:26, st_ctime=3D2012/10/08-11:13:27}) =3D 0
26297 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) =3D 0
26297 readlink("/proc/self/exe", "/usr/bin/perl"..., 4095) =3D 13
26297 brk(0x2419000)                    =3D 0x2419000
26297 close(3)                          =3D 0
26297 dup(200)                          =3D 3
26297 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff8c5a5290) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26297 lseek(3, 0, SEEK_CUR)             =3D 0
26297 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26297 dup2(3, 0)                        =3D 0
26297 close(3)                          =3D 0
26297 fcntl(0, F_SETFD, 0)              =3D 0
26297 fstat(0, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26297 stat("/var/run/xen-hotplug/block", {st_dev=3Dmakedev(8, 2), st_ino=3D=
2801738, st_mode=3DS_IFREG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st=
_blksize=3D4096, st_blocks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:=
24, st_mtime=3D2012/10/09-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D =
0
26297 exit_group(0)                     =3D ?
27813 <... read resumed> "", 128)       =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], WNOHANG, NUL=
L) =3D 26297
27813 wait4(-1, 0x7fffb0100a64, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0)                   =3D 0
27813 close(3)                          =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 write(2, "+ rightfile=3D\n", 13)    =3D 13
27813 write(2, "+ '[' x =3D xy ']'\n", 17) =3D 17
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ true\n", 7)           =3D 7
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ eval 'exec 200>>/var/run/xen-hotplug/block'\n", 46) =3D=
 46
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 write(2, "++ exec\n", 8)          =3D 8
27813 open("/var/run/xen-hotplug/block", O_WRONLY|O_CREAT|O_APPEND, 0666)=
 =3D 3
27813 fcntl(200, F_GETFD)               =3D 0
27813 fcntl(200, F_DUPFD, 10)           =3D 10
27813 fcntl(200, F_GETFD)               =3D 0
27813 dup2(3, 200)                      =3D 200
27813 close(3)                          =3D 0
27813 dup2(10, 200)                     =3D 200
27813 fcntl(10, F_GETFD)                =3D 0
27813 close(10)                         =3D 0
27813 write(2, "+ flock -x 200\n", 15)  =3D 15
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [INT CHLD], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [INT CHLD], NULL, 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26298
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26298 close(255 
27813 rt_sigprocmask(SIG_BLOCK, [CHLD],  
26298 <... close resumed> )             =3D 0
27813 <... rt_sigprocmask resumed> [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [],  
26298 rt_sigprocmask(SIG_SETMASK, [],  
27813 <... rt_sigprocmask resumed> NULL, 8) =3D 0
26298 <... rt_sigprocmask resumed> NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
26298 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0},  
26298 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
27813 <... rt_sigaction resumed> {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}=
, 8) =3D 0
26298 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 wait4(-1,  
26298 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
26298 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26298 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26298 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26298 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26298 execve("/usr/bin/flock", ["flock", "-x", "200"], ["SUBSYSTEM=3Dxen-=
backend", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D=
/usr/bin:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:=
/usr/sbin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dx=
en-backend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3D=
backend/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "S=
HLVL=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/flock"]) =3D 0=

26298 brk(0)                            =3D 0x631000
26298 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f5c60887000
26298 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f5c60886000
26298 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26298 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26298 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26298 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7f5c6086c000=

26298 close(3)                          =3D 0
26298 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26298 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26298 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26298 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26298 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26298 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26298 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26298 close(3)                          =3D 0
26298 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f5c6086b000
26298 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f5c6086a000
26298 arch_prctl(ARCH_SET_FS, 0x7f5c6086a6e0) =3D 0
26298 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26298 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26298 munmap(0x7f5c6086c000, 103979)    =3D 0
26298 flock(200, LOCK_EX)               =3D 0
26298 exit_group(0)                     =3D ?
27813 <... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], 0,=
 NULL) =3D 26298
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, 0x7fffb0100a24, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0xffffffffffffffff)  =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 pipe([3, 4])                      =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26299
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {0=
x436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26299 close(255 
27813 close(4 
26299 <... close resumed> )             =3D 0
27813 <... close resumed> )             =3D 0
27813 read(3,  
26299 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26299 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26299 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26299 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26299 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26299 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26299 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26299 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {S=
IG_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26299 rt_sigaction(SIGINT, {0x4481f0, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26299 dup2(4, 1)                        =3D 1
26299 close(4)                          =3D 0
26299 close(3)                          =3D 0
26299 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26299 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26299 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26299 write(2, "++ perl -e '\n            open STDIN, \"<&200\" or die $!=
;\n            my $fd_inum =3D (stat STDIN)[1]; die $! unless defined $fd=
_inum;\n            my $file_inum =3D (stat $ARGV[0])[1];\n            pr=
int \"y\\n\" if $fd_inum eq $file_inum;\n", 230) =3D 230
26299 write(2, "                             ' /var/run/xen-hotplug/block=
\n", 58) =3D 58
26299 stat(".", {st_dev=3Dmakedev(8, 2), st_ino=3D2, st_mode=3DS_IFDIR|07=
55, st_nlink=3D24, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
8, st_size=3D4096, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2012/10/08-=
11:13:38, st_ctime=3D2012/10/08-11:13:38}) =3D 0
26299 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26299 access("/usr/bin/perl", X_OK)     =3D 0
26299 access("/usr/bin/perl", R_OK)     =3D 0
26299 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26299 access("/usr/bin/perl", X_OK)     =3D 0
26299 access("/usr/bin/perl", R_OK)     =3D 0
26299 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
481f0, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26299 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26299 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26299 execve("/usr/bin/perl", ["perl", "-e", "\n            open STDIN, \=
"<&200\" or die $!;\n            my $fd_inum =3D (stat STDIN)[1]; die $! =
unless defined $fd_inum;\n            my $file_inum =3D (stat $ARGV[0])[1=
];\n            print \"y\\n\" if $fd_inum eq $file_inum;\n              =
               ", "/var/run/xen-hotplug/block"], ["SUBSYSTEM=3Dxen-backen=
d", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D/usr/b=
in:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:/usr/s=
bin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dxen-bac=
kend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3Dback=
end/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "SHLVL=
=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/perl"]) =3D 0
26299 brk(0)                            =3D 0x1993000
26299 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fed82c4e000
26299 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fed82c4d000
26299 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26299 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64/libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26299 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64", 0x7fff439ada50) =3D -1 ENOENT (No such file or directory)
26299 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/lib=
perl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26299 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls", 0=
x7fff439ada50) =3D -1 ENOENT (No such file or directory)
26299 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64/=
libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26299 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64"=
, 0x7fff439ada50) =3D -1 ENOENT (No such file or directory)
26299 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl=
=2Eso", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26299 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE", 0x7ff=
f439ada50) =3D -1 ENOENT (No such file or directory)
26299 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26299 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26299 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7fed82c33000=

26299 close(3)                          =3D 0
26299 open("/usr/lib64/libperl.so", O_RDONLY) =3D 3
26299 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\34\203%=
4\0\0\0@\0\0\0\0\0\0\0\360;\23\0\0\0\0\0\0\0\0\0@\0008\0\5\0@\0\35\0\34\0=
\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\200%4\0\0\0\0\0\200%4\0\0\0T\260\22\=
0\0\0\0\0T\260\22\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0X\260\22\0\0\0\=
0\0X\260\262%4\0\0\0X\260\262%4\0\0\0\250\201\0\0\0\0\0\0\350\242\0\0\0\0=
\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\265\22\0\0\0\0\0\370\265\262%4\0\=
0\0\370\265\262%4\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\=
0\0P\345td\4\0\0\0\250u\21\0\0\0\0\0\250u\221%4\0\0\0\250u\221%4\0\0\0D@\=
0\0\0\0\0\0D@\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\7\4\0\0\360\0\0\0\0\1\0\0\16\0\0\0\0\0\0@\0\200\203\200\225\1\22\=
264\3\31\200l\0\32\0 \5\201\0\240\3\2B\0\200\21R \0\22\0\0\16P\20#\10\216=
\334\30\211\"\0\10 \200\3B\220@\0\1\206\20\30\2\3\21\203$!\312A0\224Y\200=
\27\0\242\26\10\24R@\10\200\220\20A\10\0\220\1\200\206\2\10\304\30i\0\220=
\1\1\202\200\22\20\0\n\1H\0\n\2001J \6\31@L\207\20\10\0000\10(\200\2\0\4\=
251t\"\262\310!\212\240\320\"\0\t"..., 832) =3D 832
26299 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2839671, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D2480, st_size=3D1262384, st_atime=3D2012/10/09-12:04:35, st_mtime=3D=
2012/09/11-12:45:05, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26299 mmap(0x3425800000, 3363648, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425800000
26299 mprotect(0x342592c000, 2093056, PROT_NONE) =3D 0
26299 mmap(0x3425b2b000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x12b000) =3D 0x3425b2b000
26299 mmap(0x3425b34000, 4928, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3425b34000
26299 close(3)                          =3D 0
26299 open("/lib64/libresolv.so.2", O_RDONLY) =3D 3
26299 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\2402\0'4\0\=
0\0@\0\0\0\0\0\0\0@a\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\5\0=
\0\0@\0\0\0\0\0\0\0@\0\0'4\0\0\0@\0\0'4\0\0\0\370\1\0\0\0\0\0\0\370\1\0\0=
\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \361\0\0\0\0\0\0 \361\0'4\0\0\0=
 \361\0'4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\=
0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0'4\0\0\0\0\0\0'4\0\0\0$\10\1\0\0\0\0\0$\10=
\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\24\1\0\0\0\0\0\340\24!'4\=
0\0\0\340\24!'4\0\0\0\340\r\0\0\0\0\0\0\0106\0\0\0\0\0\0\0\0 \0\0\0\0\0\2=
\0\0\0\6\0\0\0\350\35\1\0\0\0\0\0\350\35!'4\0\0\0\350\35!'4\0\0\0\300\1\0=
\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\=
0\0\0008\2\0'4\0\0\0008\2\0'4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0=
\0\0\0\0P\345td\4\0\0\0<\361\0\0\0\0\0\0<\361\0'4\0\0\0<\361\0'4\0\0\0,\3=
\0\0\0\0\0\0,\3\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 8=
32
26299 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148119, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D192, st_size=3D92736, st_atime=3D2012/10/09-11:16:43, st_mtime=3D201=
0/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:42}) =3D 0
26299 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fed82c32000
26299 mmap(0x3427000000, 2181864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3427000000
26299 mprotect(0x3427011000, 2097152, PROT_NONE) =3D 0
26299 mmap(0x3427211000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x11000) =3D 0x3427211000
26299 mmap(0x3427213000, 6888, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3427213000
26299 close(3)                          =3D 0
26299 open("/lib64/libnsl.so.1", O_RDONLY) =3D 3
26299 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240@\340\35=
10\0\0\0@\0\0\0\0\0\0\0\360\265\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0=
\6\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\340\3510\0\0\0@\0\340\3510\0\0\0\370\1=
\0\0\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \33\1\0\0=
\0\0\0 \33\341\3510\0\0\0 \33\341\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\=
0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\340\3510\0\0\0=
\0\0\340\3510\0\0\0\310@\1\0\0\0\0\0\310@\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\=
0\0\6\0\0\0xM\1\0\0\0\0\0xM\1\3520\0\0\0xM\1\3520\0\0\0\310\5\0\0\0\0\0\0=
008-\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250M\1\0\0\0\0\0\250M\1\3=
520\0\0\0\250M\1\3520\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\340\3510\0\0\0008\2\340\351=
0\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0<\33\=
1\0\0\0\0\0<\33\341\3510\0\0\0<\33\341\3510\0\0\0\\\5\0\0\0\0\0\0\\\5\0\0=
\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26299 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147206, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D232, st_size=3D114352, st_atime=3D2012/10/09-12:01:01, st_mtime=3D20=
10/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:44}) =3D 0
26299 mmap(0x30e9e00000, 2194096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9e00000
26299 mprotect(0x30e9e15000, 2093056, PROT_NONE) =3D 0
26299 mmap(0x30ea014000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x14000) =3D 0x30ea014000
26299 mmap(0x30ea016000, 6832, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x30ea016000
26299 close(3)                          =3D 0
26299 open("/lib64/libdl.so.2", O_RDONLY) =3D 3
26299 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\16`\3500=
\0\0\0@\0\0\0\0\0\0\0@R\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0`\3500\0\0\0@\0`\3500\0\0\0\370\1\0\0\0\0\0\0\37=
0\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\300\32\0\0\0\0\0\0\300\3=
2`\3500\0\0\0\300\32`\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0`\3500\0\0\0\0\0`\3500\0\0\=
0\224\37\0\0\0\0\0\0\224\37\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0`-\=
0\0\0\0\0\0`-\200\3500\0\0\0`-\200\3500\0\0\0 \3\0\0\0\0\0\0\240\3\0\0\0\=
0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\240-\0\0\0\0\0\0\240-\200\3500\0\0\0=
\240-\200\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0=
\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2`\3500\0\0\0008\2`\3500\0\0\0 \0\0\=
0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\334\32\0\0\0\0\0\=
0\334\32`\3500\0\0\0\334\32`\3500\0\0\0\264\0\0\0\0\0\0\0\264\0\0\0\0\0\0=
\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26299 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147322, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D48, st_size=3D23360, st_atime=3D2012/10/09-11:13:54, st_mtime=3D2010=
/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26299 mmap(0x30e8600000, 2109696, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8600000
26299 mprotect(0x30e8602000, 2097152, PROT_NONE) =3D 0
26299 mmap(0x30e8802000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x2000) =3D 0x30e8802000
26299 close(3)                          =3D 0
26299 open("/lib64/libm.so.6", O_RDONLY) =3D 3
26299 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`>\240\3510\=
0\0\0@\0\0\0\0\0\0\0\240X\t\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0)\0(\0\6\0\0\=
0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3510\0\0\0@\0\240\3510\0\0\0\370\1\0\0\0\=
0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\360\303\7\0\0\0\=
0\0\360\303\247\3510\0\0\0\360\303\247\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0=
\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3510\=
0\0\0\0\0\240\3510\0\0\0000\22\10\0\0\0\0\0000\22\10\0\0\0\0\0\0\0 \0\0\0=
\0\0\1\0\0\0\6\0\0\0\270\35\10\0\0\0\0\0\270\35\310\3510\0\0\0\270\35\310=
\3510\0\0\0\320\2\0\0\0\0\0\0 \3\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0=
\0\350\35\10\0\0\0\0\0\350\35\310\3510\0\0\0\350\35\310\3510\0\0\0\300\1\=
0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0=
\0\0\0008\2\240\3510\0\0\0008\2\240\3510\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\f\304\7\0\0\0\0\0\f\304\247\3510\0\0\0=
\f\304\247\3510\0\0\0\374\r\0\0\0\0\0\0\374\r\0\0\0\0\0\0\4\0\0\0\0\0\0\0=
Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0"..., 832) =3D 832
26299 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147337, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D1216, st_size=3D615136, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2=
010/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26299 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fed82c31000
26299 mmap(0x30e9a00000, 2629848, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9a00000
26299 mprotect(0x30e9a82000, 2093056, PROT_NONE) =3D 0
26299 mmap(0x30e9c81000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x81000) =3D 0x30e9c81000
26299 close(3)                          =3D 0
26299 open("/lib64/libcrypt.so.1", O_RDONLY) =3D 3
26299 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\t\300%4=
\0\0\0@\0\0\0\0\0\0\0\30\265\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\=
0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\300%4\0\0\0@\0\300%4\0\0\0\370\1\0\0\0\0\=
0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340}\0\0\0\0\0\0\3=
40}\300%4\0\0\0\340}\300%4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\300%4\0\0\0\0\0\300%4\0\0\=
0\4\205\0\0\0\0\0\0\4\205\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\310\=
215\0\0\0\0\0\0\310\215\340%4\0\0\0\310\215\340%4\0\0\0\250\2\0\0\0\0\0\0=
\370\343\2\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\215\0\0\0\0\0\0\3=
70\215\340%4\0\0\0\370\215\340%4\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\=
0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\300%4\0\0\0008\2=
\300%4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0=
\374}\0\0\0\0\0\0\374}\300%4\0\0\0\374}\300%4\0\0\0\34\1\0\0\0\0\0\0\34\1=
\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26299 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148123, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D96, st_size=3D48600, st_atime=3D2012/10/09-12:01:01, st_mtime=3D2010=
/07/28-03:52:39, st_ctime=3D2012/09/11-14:53:52}) =3D 0
26299 mmap(0x3425c00000, 2322880, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425c00000
26299 mprotect(0x3425c09000, 2093056, PROT_NONE) =3D 0
26299 mmap(0x3425e08000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x8000) =3D 0x3425e08000
26299 mmap(0x3425e0a000, 184768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FI=
XED|MAP_ANONYMOUS, -1, 0) =3D 0x3425e0a000
26299 close(3)                          =3D 0
26299 open("/lib64/libutil.so.1", O_RDONLY) =3D 3
26299 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\16\0(4\=
0\0\0@\0\0\0\0\0\0\0(>\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0\0(4\0\0\0@\0\0(4\0\0\0\370\1\0\0\0\0\0\0\370\1\=
0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340\26\0\0\0\0\0\0\340\26\0(=
4\0\0\0\340\26\0(4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0=
\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0(4\0\0\0\0\0\0(4\0\0\0P\32\0\0\0\=
0\0\0P\32\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\35\0\0\0\0\0\0\3=
40\35 (4\0\0\0\340\35 (4\0\0\0 \3\0\0\0\0\0\0000\3\0\0\0\0\0\0\0\0 \0\0\0=
\0\0\2\0\0\0\6\0\0\0\20\36\0\0\0\0\0\0\20\36 (4\0\0\0\20\36 (4\0\0\0\300\=
1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0=
\0\0\0\0008\2\0(4\0\0\0008\2\0(4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\=
0\0\0\0\0\0P\345td\4\0\0\0\374\26\0\0\0\0\0\0\374\26\0(4\0\0\0\374\26\0(4=
\0\0\0D\0\0\0\0\0\0\0D\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8=
32) =3D 832
26299 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147063, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D40, st_size=3D18152, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2010=
/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:49}) =3D 0
26299 mmap(0x3428000000, 2105616, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3428000000
26299 mprotect(0x3428002000, 2093056, PROT_NONE) =3D 0
26299 mmap(0x3428201000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x1000) =3D 0x3428201000
26299 close(3)                          =3D 0
26299 open("/lib64/libpthread.so.0", O_RDONLY) =3D 3
26299 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240W\240\35=
00\0\0\0@\0\0\0\0\0\0\0\340/\2\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0'\0&\0\6\0=
\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3500\0\0\0@\0\240\3500\0\0\0\370\1\0\0=
\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\240\t\1\0\0\0=
\0\0\240\t\241\3500\0\0\0\240\t\241\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\=
0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3500\0\0=
\0\0\0\240\3500\0\0\0pZ\1\0\0\0\0\0pZ\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\=
6\0\0\0\270[\1\0\0\0\0\0\270[\301\3500\0\0\0\270[\301\3500\0\0\0\230\6\0\=
0\0\0\0\0\270G\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250]\1\0\0\0\0\=
0\250]\301\3500\0\0\0\250]\301\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0=
\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\240\3500\0\0\=
0008\2\240\3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345t=
d\4\0\0\0\274\t\1\0\0\0\0\0\274\t\241\3500\0\0\0\274\t\241\3500\0\0\0\344=
\t\0\0\0\0\0\0\344\t\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =
=3D 832
26299 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147328, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D296, st_size=3D145824, st_atime=3D2012/10/09-11:16:43, st_mtime=3D20=
10/07/28-03:52:41, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26299 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fed82c30000
26299 mmap(0x30e8a00000, 2204528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8a00000
26299 mprotect(0x30e8a16000, 2093056, PROT_NONE) =3D 0
26299 mmap(0x30e8c15000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x15000) =3D 0x30e8c15000
26299 mmap(0x30e8c17000, 13168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8c17000
26299 close(3)                          =3D 0
26299 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26299 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26299 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26299 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26299 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26299 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26299 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26299 close(3)                          =3D 0
26299 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fed82c2f000
26299 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7fed82c2e000
26299 arch_prctl(ARCH_SET_FS, 0x7fed82c2e6e0) =3D 0
26299 mprotect(0x3427211000, 4096, PROT_READ) =3D 0
26299 mprotect(0x30ea014000, 4096, PROT_READ) =3D 0
26299 mprotect(0x30e8802000, 4096, PROT_READ) =3D 0
26299 mprotect(0x30e9c81000, 4096, PROT_READ) =3D 0
26299 mprotect(0x3425e08000, 4096, PROT_READ) =3D 0
26299 mprotect(0x3428201000, 4096, PROT_READ) =3D 0
26299 mprotect(0x30e8c15000, 4096, PROT_READ) =3D 0
26299 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26299 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26299 munmap(0x7fed82c33000, 103979)    =3D 0
26299 set_tid_address(0x7fed82c2e770)   =3D 26299
26299 set_robust_list(0x7fed82c2e780, 0x18) =3D 0
26299 futex(0x7fff439ae57c, FUTEX_WAKE_PRIVATE, 1) =3D 0
26299 rt_sigaction(SIGRTMIN, {0x30e8a05380, [], SA_RESTORER|SA_SIGINFO, 0=
x30e8a0eb10}, NULL, 8) =3D 0
26299 rt_sigaction(SIGRT_1, {0x30e8a052b0, [], SA_RESTORER|SA_RESTART|SA_=
SIGINFO, 0x30e8a0eb10}, NULL, 8) =3D 0
26299 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) =3D 0
26299 getrlimit(RLIMIT_STACK, {rlim_cur=3D8192*1024, rlim_max=3DRLIM_INFI=
NITY}) =3D 0
26299 rt_sigaction(SIGFPE, {0x1, [FPE], SA_RESTORER|SA_RESTART, 0x30e8230=
2d0}, {SIG_DFL, [], 0}, 8) =3D 0
26299 brk(0)                            =3D 0x1993000
26299 brk(0x19b5000)                    =3D 0x19b5000
26299 getuid()                          =3D 0
26299 geteuid()                         =3D 0
26299 getgid()                          =3D 0
26299 getegid()                         =3D 0
26299 mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,=
 -1, 0) =3D 0x7fed82c0d000
26299 open("/dev/urandom", O_RDONLY)    =3D 3
26299 read(3, "\371\n\f&", 4)           =3D 4
26299 close(3)                          =3D 0
26299 stat("/usr/lib64/perl5/site_perl/5.8.7/x86_64-linux-thread-multi", =
0x7fff439ae230) =3D -1 ENOENT (No such file or directory)
26299 stat("/usr/lib/perl5/site_perl/5.8.7", 0x7fff439ae230) =3D -1 ENOEN=
T (No such file or directory)
26299 stat("/usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi", =
0x7fff439ae230) =3D -1 ENOENT (No such file or directory)
26299 stat("/usr/lib/perl5/site_perl/5.8.6", 0x7fff439ae230) =3D -1 ENOEN=
T (No such file or directory)
26299 stat("/usr/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi", =
0x7fff439ae230) =3D -1 ENOENT (No such file or directory)
26299 stat("/usr/lib/perl5/site_perl/5.8.5", 0x7fff439ae230) =3D -1 ENOEN=
T (No such file or directory)
26299 stat("/usr/lib64/perl5/vendor_perl/5.8.7/x86_64-linux-thread-multi"=
, 0x7fff439ae230) =3D -1 ENOENT (No such file or directory)
26299 stat("/usr/lib/perl5/vendor_perl/5.8.7", 0x7fff439ae230) =3D -1 ENO=
ENT (No such file or directory)
26299 stat("/usr/lib64/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi"=
, 0x7fff439ae230) =3D -1 ENOENT (No such file or directory)
26299 stat("/usr/lib/perl5/vendor_perl/5.8.6", 0x7fff439ae230) =3D -1 ENO=
ENT (No such file or directory)
26299 stat("/usr/lib64/perl5/vendor_perl/5.8.5/x86_64-linux-thread-multi"=
, 0x7fff439ae230) =3D -1 ENOENT (No such file or directory)
26299 stat("/usr/lib/perl5/vendor_perl/5.8.5", 0x7fff439ae230) =3D -1 ENO=
ENT (No such file or directory)
26299 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff439adff0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26299 lseek(0, 0, SEEK_CUR)             =3D 0
26299 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff439adff0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26299 lseek(1, 0, SEEK_CUR)             =3D -1 ESPIPE (Illegal seek)
26299 ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff439ae000) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26299 lseek(2, 0, SEEK_CUR)             =3D 593661861
26299 open("/dev/null", O_RDONLY)       =3D 3
26299 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff439ae100) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26299 lseek(3, 0, SEEK_CUR)             =3D 0
26299 fcntl(3, F_SETFD, FD_CLOEXEC)     =3D 0
26299 fstat(3, {st_dev=3Dmakedev(0, 16), st_ino=3D584, st_mode=3DS_IFCHR|=
0666, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
0, st_rdev=3Dmakedev(1, 3), st_atime=3D2012/10/08-11:13:26, st_mtime=3D20=
12/10/08-11:13:26, st_ctime=3D2012/10/08-11:13:27}) =3D 0
26299 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) =3D 0
26299 readlink("/proc/self/exe", "/usr/bin/perl"..., 4095) =3D 13
26299 brk(0x19d6000)                    =3D 0x19d6000
26299 close(3)                          =3D 0
26299 dup(200)                          =3D 3
26299 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff439adfd0) =3D -1 ENOT=
TY (Inappropriate ioctl for device)
26299 lseek(3, 0, SEEK_CUR)             =3D 0
26299 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26299 dup2(3, 0)                        =3D 0
26299 close(3)                          =3D 0
26299 fcntl(0, F_SETFD, 0)              =3D 0
26299 fstat(0, {st_dev=3Dmakedev(8, 2), st_ino=3D2801701, st_mode=3DS_IFR=
EG|0644, st_nlink=3D0, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:24, st_mtime=3D2012/10/0=
9-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D 0
26299 stat("/var/run/xen-hotplug/block", {st_dev=3Dmakedev(8, 2), st_ino=3D=
2801738, st_mode=3DS_IFREG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st=
_blksize=3D4096, st_blocks=3D0, st_size=3D0, st_atime=3D2012/10/09-16:25:=
24, st_mtime=3D2012/10/09-16:25:24, st_ctime=3D2012/10/09-16:25:24}) =3D =
0
26299 exit_group(0)                     =3D ?
27813 <... read resumed> "", 128)       =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], WNOHANG, NUL=
L) =3D 26299
27813 wait4(-1, 0x7fffb0100a64, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0)                   =3D 0
27813 close(3)                          =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 write(2, "+ rightfile=3D\n", 13)    =3D 13
27813 write(2, "+ '[' x =3D xy ']'\n", 17) =3D 17
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ true\n", 7)           =3D 7
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 write(2, "+ eval 'exec 200>>/var/run/xen-hotplug/block'\n", 46) =3D=
 46
27813 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
27813 write(2, "++ exec\n", 8)          =3D 8
27813 open("/var/run/xen-hotplug/block", O_WRONLY|O_CREAT|O_APPEND, 0666)=
 =3D 3
27813 fcntl(200, F_GETFD)               =3D 0
27813 fcntl(200, F_DUPFD, 10)           =3D 10
27813 fcntl(200, F_GETFD)               =3D 0
27813 dup2(3, 200)                      =3D 200
27813 close(3)                          =3D 0
27813 dup2(10, 200)                     =3D 200
27813 fcntl(10, F_GETFD)                =3D 0
27813 close(10)                         =3D 0
27813 write(2, "+ flock -x 200\n", 15)  =3D 15
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [INT CHLD], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [INT CHLD], NULL, 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26300
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26300 close(255 
27813 rt_sigprocmask(SIG_BLOCK, [CHLD],  
26300 <... close resumed> )             =3D 0
27813 <... rt_sigprocmask resumed> [], 8) =3D 0
26300 rt_sigprocmask(SIG_SETMASK, [],  
27813 rt_sigprocmask(SIG_SETMASK, [],  
26300 <... rt_sigprocmask resumed> NULL, 8) =3D 0
27813 <... rt_sigprocmask resumed> NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD],  
26300 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 <... rt_sigprocmask resumed> [], 8) =3D 0
26300 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
27813 rt_sigaction(SIGINT, {0x436c60, [], SA_RESTORER, 0x30e82302d0},  
26300 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0},  
27813 <... rt_sigaction resumed> {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}=
, 8) =3D 0
26300 <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) =3D 0
27813 wait4(-1,  
26300 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26300 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26300 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26300 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26300 execve("/usr/bin/flock", ["flock", "-x", "200"], ["SUBSYSTEM=3Dxen-=
backend", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D=
/usr/bin:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:=
/usr/sbin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dx=
en-backend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3D=
backend/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "S=
HLVL=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/flock"]) =3D 0=

26300 brk(0)                            =3D 0x1e53000
26300 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f5293893000
26300 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f5293892000
26300 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26300 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26300 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26300 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7f5293878000=

26300 close(3)                          =3D 0
26300 open("/lib64/libc.so.6", O_RDONLY) =3D 3
26300 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332!\35=
00\0\0\0@\0\0\0\0\0\0\0\350\"\32\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6=
\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0 \3500\0\0\0@\0 \3500\0\0\0000\2\0\0\0\0\=
0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0`9\22\0\0\0\0\0`92\3=
500\0\0\0`92\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\=
0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0 \3500\0\0\0\0\0 \3500\0\0\0h\320\24=
\0\0\0\0\0h\320\24\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0h\327\24\0\0\0=
\0\0h\327T\3500\0\0\0h\327T\3500\0\0\0000F\0\0\0\0\0\0\360\211\0\0\0\0\0\=
0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\v\25\0\0\0\0\0`\vU\3500\0\0\0`\vU\3500\=
0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\=
0p\2\0\0\0\0\0\0p\2 \3500\0\0\0p\2 \3500\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0h\327\24\0\0\0\0\0h\327T\3500\0\0\0h\3=
27T\3500\0\0\0\20\0\0\0\0\0\0\0`\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\=
0\0\0|9\22\0\0\0\0\0|92\3500\0\0\0|92\3500\0\0\0D_\0\0\0\0\0\0D_\0\0"...,=
 832) =3D 832
26300 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147321, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D3368, st_size=3D1717800, st_atime=3D2012/10/09-11:13:54, st_mtime=3D=
2010/07/28-03:52:39, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26300 mmap(0x30e8200000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8200000
26300 mprotect(0x30e834e000, 2093056, PROT_NONE) =3D 0
26300 mmap(0x30e854d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x14d000) =3D 0x30e854d000
26300 mmap(0x30e8552000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_ANONYMOUS, -1, 0) =3D 0x30e8552000
26300 close(3)                          =3D 0
26300 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f5293877000
26300 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f5293876000
26300 arch_prctl(ARCH_SET_FS, 0x7f52938766e0) =3D 0
26300 mprotect(0x30e854d000, 16384, PROT_READ) =3D 0
26300 mprotect(0x30e7c1b000, 4096, PROT_READ) =3D 0
26300 munmap(0x7f5293878000, 103979)    =3D 0
26300 flock(200, LOCK_EX)               =3D 0
26300 exit_group(0)                     =3D ?
27813 <... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], 0,=
 NULL) =3D 26300
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 --- SIGCHLD (Child exited) @ 0 (0) ---
27813 wait4(-1, 0x7fffb0100a24, WNOHANG, NULL) =3D -1 ECHILD (No child pr=
ocesses)
27813 rt_sigreturn(0xffffffffffffffff)  =3D 0
27813 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
36c60, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
27813 pipe([3, 4])                      =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) =3D 0
27813 clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SET=
TID|SIGCHLD, child_tidptr=3D0x7f88becfb770) =3D 26301
27813 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
27813 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {0=
x436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26301 close(255 
27813 close(4 
26301 <... close resumed> )             =3D 0
27813 <... close resumed> )             =3D 0
27813 read(3,  
26301 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0
26301 rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26301 rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26301 rt_sigaction(SIGTTOU, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], 0}, 8) =3D 0
26301 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SIG=
_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26301 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
1, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26301 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26301 rt_sigaction(SIGCHLD, {0x436080, [], SA_RESTORER, 0x30e82302d0}, {S=
IG_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26301 rt_sigaction(SIGINT, {0x4481f0, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26301 dup2(4, 1)                        =3D 1
26301 close(4)                          =3D 0
26301 close(3)                          =3D 0
26301 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26301 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26301 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) =3D 0
26301 write(2, "++ perl -e '\n            open STDIN, \"<&200\" or die $!=
;\n            my $fd_inum =3D (stat STDIN)[1]; die $! unless defined $fd=
_inum;\n            my $file_inum =3D (stat $ARGV[0])[1];\n            pr=
int \"y\\n\" if $fd_inum eq $file_inum;\n", 230) =3D 230
26301 write(2, "                             ' /var/run/xen-hotplug/block=
\n", 58) =3D 58
26301 stat(".", {st_dev=3Dmakedev(8, 2), st_ino=3D2, st_mode=3DS_IFDIR|07=
55, st_nlink=3D24, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_blocks=3D=
8, st_size=3D4096, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2012/10/08-=
11:13:38, st_ctime=3D2012/10/08-11:13:38}) =3D 0
26301 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26301 access("/usr/bin/perl", X_OK)     =3D 0
26301 access("/usr/bin/perl", R_OK)     =3D 0
26301 stat("/usr/bin/perl", {st_dev=3Dmakedev(8, 2), st_ino=3D2841664, st=
_mode=3DS_IFREG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D=
4096, st_blocks=3D40, st_size=3D19208, st_atime=3D2012/10/09-16:16:51, st=
_mtime=3D2012/09/11-12:33:19, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26301 access("/usr/bin/perl", X_OK)     =3D 0
26301 access("/usr/bin/perl", R_OK)     =3D 0
26301 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x4=
481f0, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26301 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {SI=
G_DFL, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26301 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x30e82302d0}, {0x=
436080, [], SA_RESTORER, 0x30e82302d0}, 8) =3D 0
26301 execve("/usr/bin/perl", ["perl", "-e", "\n            open STDIN, \=
"<&200\" or die $!;\n            my $fd_inum =3D (stat STDIN)[1]; die $! =
unless defined $fd_inum;\n            my $file_inum =3D (stat $ARGV[0])[1=
];\n            print \"y\\n\" if $fd_inum eq $file_inum;\n              =
               ", "/var/run/xen-hotplug/block"], ["SUBSYSTEM=3Dxen-backen=
d", "XENBUS_TYPE=3Dvbd", "DEVPATH=3D/devices/vbd-2-51712", "PATH=3D/usr/b=
in:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:/usr/s=
bin:/usr/local/bin:/bin:/usr/bin", "ACTION=3Dremove", "MODALIAS=3Dxen-bac=
kend:vbd", "PWD=3D/", "UDEV_LOG=3D3", "LANG=3DPOSIX", "XENBUS_PATH=3Dback=
end/vbd/2/51712", "UDEVD_EVENT=3D1", "XENBUS_BASE_PATH=3Dbackend", "SHLVL=
=3D1", "UDEV_CALL=3D1", "SEQNUM=3D1423", "_=3D/usr/bin/perl"]) =3D 0
26301 brk(0)                            =3D 0x1c9b000
26301 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f022f061000
26301 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f022f060000
26301 access("/etc/ld.so.preload", R_OK) =3D -1 ENOENT (No such file or d=
irectory)
26301 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64/libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26301 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/x86=
_64", 0x7fffca5d8230) =3D -1 ENOENT (No such file or directory)
26301 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls/lib=
perl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26301 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/tls", 0=
x7fffca5d8230) =3D -1 ENOENT (No such file or directory)
26301 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64/=
libperl.so", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26301 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/x86_64"=
, 0x7fffca5d8230) =3D -1 ENOENT (No such file or directory)
26301 open("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl=
=2Eso", O_RDONLY) =3D -1 ENOENT (No such file or directory)
26301 stat("/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE", 0x7ff=
fca5d8230) =3D -1 ENOENT (No such file or directory)
26301 open("/etc/ld.so.cache", O_RDONLY) =3D 3
26301 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D3975107, st_mode=3DS_IFR=
EG|0644, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D216, st_size=3D103979, st_atime=3D2012/10/09-11:13:54, st_mtime=3D20=
12/09/11-12:48:34, st_ctime=3D2012/09/11-12:48:34}) =3D 0
26301 mmap(NULL, 103979, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x7f022f046000=

26301 close(3)                          =3D 0
26301 open("/usr/lib64/libperl.so", O_RDONLY) =3D 3
26301 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\34\203%=
4\0\0\0@\0\0\0\0\0\0\0\360;\23\0\0\0\0\0\0\0\0\0@\0008\0\5\0@\0\35\0\34\0=
\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\200%4\0\0\0\0\0\200%4\0\0\0T\260\22\=
0\0\0\0\0T\260\22\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0X\260\22\0\0\0\=
0\0X\260\262%4\0\0\0X\260\262%4\0\0\0\250\201\0\0\0\0\0\0\350\242\0\0\0\0=
\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\265\22\0\0\0\0\0\370\265\262%4\0\=
0\0\370\265\262%4\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\=
0\0P\345td\4\0\0\0\250u\21\0\0\0\0\0\250u\221%4\0\0\0\250u\221%4\0\0\0D@\=
0\0\0\0\0\0D@\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\7\4\0\0\360\0\0\0\0\1\0\0\16\0\0\0\0\0\0@\0\200\203\200\225\1\22\=
264\3\31\200l\0\32\0 \5\201\0\240\3\2B\0\200\21R \0\22\0\0\16P\20#\10\216=
\334\30\211\"\0\10 \200\3B\220@\0\1\206\20\30\2\3\21\203$!\312A0\224Y\200=
\27\0\242\26\10\24R@\10\200\220\20A\10\0\220\1\200\206\2\10\304\30i\0\220=
\1\1\202\200\22\20\0\n\1H\0\n\2001J \6\31@L\207\20\10\0000\10(\200\2\0\4\=
251t\"\262\310!\212\240\320\"\0\t"..., 832) =3D 832
26301 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D2839671, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D2480, st_size=3D1262384, st_atime=3D2012/10/09-12:04:35, st_mtime=3D=
2012/09/11-12:45:05, st_ctime=3D2012/09/11-14:54:00}) =3D 0
26301 mmap(0x3425800000, 3363648, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425800000
26301 mprotect(0x342592c000, 2093056, PROT_NONE) =3D 0
26301 mmap(0x3425b2b000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIX=
ED|MAP_DENYWRITE, 3, 0x12b000) =3D 0x3425b2b000
26301 mmap(0x3425b34000, 4928, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3425b34000
26301 close(3)                          =3D 0
26301 open("/lib64/libresolv.so.2", O_RDONLY) =3D 3
26301 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\2402\0'4\0\=
0\0@\0\0\0\0\0\0\0@a\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\5\0=
\0\0@\0\0\0\0\0\0\0@\0\0'4\0\0\0@\0\0'4\0\0\0\370\1\0\0\0\0\0\0\370\1\0\0=
\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \361\0\0\0\0\0\0 \361\0'4\0\0\0=
 \361\0'4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\=
0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0'4\0\0\0\0\0\0'4\0\0\0$\10\1\0\0\0\0\0$\10=
\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\24\1\0\0\0\0\0\340\24!'4\=
0\0\0\340\24!'4\0\0\0\340\r\0\0\0\0\0\0\0106\0\0\0\0\0\0\0\0 \0\0\0\0\0\2=
\0\0\0\6\0\0\0\350\35\1\0\0\0\0\0\350\35!'4\0\0\0\350\35!'4\0\0\0\300\1\0=
\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\=
0\0\0008\2\0'4\0\0\0008\2\0'4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0=
\0\0\0\0P\345td\4\0\0\0<\361\0\0\0\0\0\0<\361\0'4\0\0\0<\361\0'4\0\0\0,\3=
\0\0\0\0\0\0,\3\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\=
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 8=
32
26301 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148119, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D192, st_size=3D92736, st_atime=3D2012/10/09-11:16:43, st_mtime=3D201=
0/07/28-03:52:41, st_ctime=3D2012/09/11-14:53:42}) =3D 0
26301 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f022f045000
26301 mmap(0x3427000000, 2181864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3427000000
26301 mprotect(0x3427011000, 2097152, PROT_NONE) =3D 0
26301 mmap(0x3427211000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x11000) =3D 0x3427211000
26301 mmap(0x3427213000, 6888, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x3427213000
26301 close(3)                          =3D 0
26301 open("/lib64/libnsl.so.1", O_RDONLY) =3D 3
26301 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240@\340\35=
10\0\0\0@\0\0\0\0\0\0\0\360\265\1\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0=
\6\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\340\3510\0\0\0@\0\340\3510\0\0\0\370\1=
\0\0\0\0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0 \33\1\0\0=
\0\0\0 \33\341\3510\0\0\0 \33\341\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\=
0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\340\3510\0\0\0=
\0\0\340\3510\0\0\0\310@\1\0\0\0\0\0\310@\1\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\=
0\0\6\0\0\0xM\1\0\0\0\0\0xM\1\3520\0\0\0xM\1\3520\0\0\0\310\5\0\0\0\0\0\0=
008-\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\250M\1\0\0\0\0\0\250M\1\3=
520\0\0\0\250M\1\3520\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\=
0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\340\3510\0\0\0008\2\340\351=
0\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0<\33\=
1\0\0\0\0\0<\33\341\3510\0\0\0<\33\341\3510\0\0\0\\\5\0\0\0\0\0\0\\\5\0\0=
\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26301 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147206, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D232, st_size=3D114352, st_atime=3D2012/10/09-12:01:01, st_mtime=3D20=
10/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:44}) =3D 0
26301 mmap(0x30e9e00000, 2194096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9e00000
26301 mprotect(0x30e9e15000, 2093056, PROT_NONE) =3D 0
26301 mmap(0x30ea014000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x14000) =3D 0x30ea014000
26301 mmap(0x30ea016000, 6832, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_ANONYMOUS, -1, 0) =3D 0x30ea016000
26301 close(3)                          =3D 0
26301 open("/lib64/libdl.so.2", O_RDONLY) =3D 3
26301 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\16`\3500=
\0\0\0@\0\0\0\0\0\0\0@R\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0$\0#\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0`\3500\0\0\0@\0`\3500\0\0\0\370\1\0\0\0\0\0\0\37=
0\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\300\32\0\0\0\0\0\0\300\3=
2`\3500\0\0\0\300\32`\3500\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0`\3500\0\0\0\0\0`\3500\0\0\=
0\224\37\0\0\0\0\0\0\224\37\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0`-\=
0\0\0\0\0\0`-\200\3500\0\0\0`-\200\3500\0\0\0 \3\0\0\0\0\0\0\240\3\0\0\0\=
0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\240-\0\0\0\0\0\0\240-\200\3500\0\0\0=
\240-\200\3500\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0=
\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2`\3500\0\0\0008\2`\3500\0\0\0 \0\0\=
0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\334\32\0\0\0\0\0\=
0\334\32`\3500\0\0\0\334\32`\3500\0\0\0\264\0\0\0\0\0\0\0\264\0\0\0\0\0\0=
\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26301 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147322, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D48, st_size=3D23360, st_atime=3D2012/10/09-11:13:54, st_mtime=3D2010=
/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26301 mmap(0x30e8600000, 2109696, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e8600000
26301 mprotect(0x30e8602000, 2097152, PROT_NONE) =3D 0
26301 mmap(0x30e8802000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x2000) =3D 0x30e8802000
26301 close(3)                          =3D 0
26301 open("/lib64/libm.so.6", O_RDONLY) =3D 3
26301 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`>\240\3510\=
0\0\0@\0\0\0\0\0\0\0\240X\t\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0)\0(\0\6\0\0\=
0\5\0\0\0@\0\0\0\0\0\0\0@\0\240\3510\0\0\0@\0\240\3510\0\0\0\370\1\0\0\0\=
0\0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\360\303\7\0\0\0\=
0\0\360\303\247\3510\0\0\0\360\303\247\3510\0\0\0\34\0\0\0\0\0\0\0\34\0\0=
\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\240\3510\=
0\0\0\0\0\240\3510\0\0\0000\22\10\0\0\0\0\0000\22\10\0\0\0\0\0\0\0 \0\0\0=
\0\0\1\0\0\0\6\0\0\0\270\35\10\0\0\0\0\0\270\35\310\3510\0\0\0\270\35\310=
\3510\0\0\0\320\2\0\0\0\0\0\0 \3\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0=
\0\350\35\10\0\0\0\0\0\350\35\310\3510\0\0\0\350\35\310\3510\0\0\0\300\1\=
0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0=
\0\0\0008\2\240\3510\0\0\0008\2\240\3510\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\=
0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0\f\304\7\0\0\0\0\0\f\304\247\3510\0\0\0=
\f\304\247\3510\0\0\0\374\r\0\0\0\0\0\0\374\r\0\0\0\0\0\0\4\0\0\0\0\0\0\0=
Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0"..., 832) =3D 832
26301 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5147337, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D1216, st_size=3D615136, st_atime=3D2012/10/09-11:16:43, st_mtime=3D2=
010/07/28-03:52:40, st_ctime=3D2012/07/03-12:30:43}) =3D 0
26301 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -=
1, 0) =3D 0x7f022f044000
26301 mmap(0x30e9a00000, 2629848, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x30e9a00000
26301 mprotect(0x30e9a82000, 2093056, PROT_NONE) =3D 0
26301 mmap(0x30e9c81000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x81000) =3D 0x30e9c81000
26301 close(3)                          =3D 0
26301 open("/lib64/libcrypt.so.1", O_RDONLY) =3D 3
26301 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\t\300%4=
\0\0\0@\0\0\0\0\0\0\0\30\265\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\=
0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\300%4\0\0\0@\0\300%4\0\0\0\370\1\0\0\0\0\=
0\0\370\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340}\0\0\0\0\0\0\3=
40}\300%4\0\0\0\340}\300%4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0=
\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\300%4\0\0\0\0\0\300%4\0\0\=
0\4\205\0\0\0\0\0\0\4\205\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\310\=
215\0\0\0\0\0\0\310\215\340%4\0\0\0\310\215\340%4\0\0\0\250\2\0\0\0\0\0\0=
\370\343\2\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\370\215\0\0\0\0\0\0\3=
70\215\340%4\0\0\0\370\215\340%4\0\0\0\300\1\0\0\0\0\0\0\300\1\0\0\0\0\0\=
0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0\0\0\0\0008\2\300%4\0\0\0008\2=
\300%4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0P\345td\4\0\0\0=
\374}\0\0\0\0\0\0\374}\300%4\0\0\0\374}\300%4\0\0\0\34\1\0\0\0\0\0\0\34\1=
\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 832) =3D 832
26301 fstat(3, {st_dev=3Dmakedev(8, 2), st_ino=3D5148123, st_mode=3DS_IFR=
EG|0755, st_nlink=3D1, st_uid=3D0, st_gid=3D0, st_blksize=3D4096, st_bloc=
ks=3D96, st_size=3D48600, st_atime=3D2012/10/09-12:01:01, st_mtime=3D2010=
/07/28-03:52:39, st_ctime=3D2012/09/11-14:53:52}) =3D 0
26301 mmap(0x3425c00000, 2322880, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DE=
NYWRITE, 3, 0) =3D 0x3425c00000
26301 mprotect(0x3425c09000, 2093056, PROT_NONE) =3D 0
26301 mmap(0x3425e08000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXE=
D|MAP_DENYWRITE, 3, 0x8000) =3D 0x3425e08000
26301 mmap(0x3425e0a000, 184768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FI=
XED|MAP_ANONYMOUS, -1, 0) =3D 0x3425e0a000
26301 close(3)                          =3D 0
26301 open("/lib64/libutil.so.1", O_RDONLY) =3D 3
26301 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\16\0(4\=
0\0\0@\0\0\0\0\0\0\0(>\0\0\0\0\0\0\0\0\0\0@\0008\0\t\0@\0#\0\"\0\6\0\0\0\=
5\0\0\0@\0\0\0\0\0\0\0@\0\0(4\0\0\0@\0\0(4\0\0\0\370\1\0\0\0\0\0\0\370\1\=
0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\340\26\0\0\0\0\0\0\340\26\0(=
4\0\0\0\340\26\0(4\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0=
\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0(4\0\0\0\0\0\0(4\0\0\0P\32\0\0\0\=
0\0\0P\32\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\340\35\0\0\0\0\0\0\3=
40\35 (4\0\0\0\340\35 (4\0\0\0 \3\0\0\0\0\0\0000\3\0\0\0\0\0\0\0\0 \0\0\0=
\0\0\2\0\0\0\6\0\0\0\20\36\0\0\0\0\0\0\20\36 (4\0\0\0\20\36 (4\0\0\0\300\=
1\0\0\0\0\0\0\300\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0008\2\0\0=
\0\0\0\0008\2\0(4\0\0\0008\2\0(4\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\=
0\0\0\0\0\0P\345td\4\0\0\0\374\26\0\0\0\0\0\0\374\26\0(4\0\0\0\374\26\0(4=
\0\0\0D\0\0\0\0\0\0\0D\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0=
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8=
32) =3D 832

--------------030802060607050703070201
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------030802060607050703070201--


From xen-devel-bounces@lists.xen.org Tue Oct 09 09:36:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 09:36:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLWE3-00088n-Up; Tue, 09 Oct 2012 09:35:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLWE2-00088h-DN
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 09:35:42 +0000
Received: from [85.158.139.211:12456] by server-12.bemta-5.messagelabs.com id
	6C/A4-19095-DEFE3705; Tue, 09 Oct 2012 09:35:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1349775340!20592219!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12567 invoked from network); 9 Oct 2012 09:35:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 09:35:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15031768"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 09:35:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 9 Oct 2012 10:35:40 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TLWE0-0008SW-HY; Tue, 09 Oct 2012 09:35:40 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TLWE0-0003rL-Dd;
	Tue, 09 Oct 2012 10:35:40 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20595.61420.34064.705987@mariner.uk.xensource.com>
Date: Tue, 9 Oct 2012 10:35:40 +0100
To: Ian Campbell , "xen-devel@lists.xensource.com"
	
In-Reply-To: <20595.60875.258078.801716@mariner.uk.xensource.com>
References: 
	<1349769024.6952.64.camel@dagon.hellion.org.uk>
	<20595.60875.258078.801716@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [xen-unstable test] 13934: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson writes ("Re: [Xen-devel] [xen-unstable test] 13934: regressions - FAIL"):
> This means the bug is in make or in the makefiles.  Let me investigate
> further...

Subject: [PATCH] build, docs: Do not ignore install-docs errors

In the toplevel Makefile "install-docs" (depended on by "install" and
hence "dist"), but not "build", ignores errors.

This was inherited from before 24563:4271634e4c86, prior to which the
||true seems intended to handle failures of check_pkgs.  Nowadays we
handle docs tools individually in the docs makefiles so there is no
need for this ||true here.

Signed-off-by: Ian Jackson 

diff -r 87bf99fad7a9 Makefile
--- a/Makefile	Tue Oct 02 12:14:00 2012 +0200
+++ b/Makefile	Tue Oct 09 10:29:42 2012 +0100
@@ -103,7 +103,7 @@ tools/firmware/seabios-dir-force-update:
 
 .PHONY: install-docs
 install-docs:
-	$(MAKE) -C docs install || true
+	$(MAKE) -C docs install
 
 .PHONY: dev-docs
 dev-docs:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 09:36:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 09:36:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLWE3-00088n-Up; Tue, 09 Oct 2012 09:35:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLWE2-00088h-DN
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 09:35:42 +0000
Received: from [85.158.139.211:12456] by server-12.bemta-5.messagelabs.com id
	6C/A4-19095-DEFE3705; Tue, 09 Oct 2012 09:35:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1349775340!20592219!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12567 invoked from network); 9 Oct 2012 09:35:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 09:35:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15031768"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 09:35:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 9 Oct 2012 10:35:40 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TLWE0-0008SW-HY; Tue, 09 Oct 2012 09:35:40 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TLWE0-0003rL-Dd;
	Tue, 09 Oct 2012 10:35:40 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20595.61420.34064.705987@mariner.uk.xensource.com>
Date: Tue, 9 Oct 2012 10:35:40 +0100
To: Ian Campbell , "xen-devel@lists.xensource.com"
	
In-Reply-To: <20595.60875.258078.801716@mariner.uk.xensource.com>
References: 
	<1349769024.6952.64.camel@dagon.hellion.org.uk>
	<20595.60875.258078.801716@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [xen-unstable test] 13934: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson writes ("Re: [Xen-devel] [xen-unstable test] 13934: regressions - FAIL"):
> This means the bug is in make or in the makefiles.  Let me investigate
> further...

Subject: [PATCH] build, docs: Do not ignore install-docs errors

In the toplevel Makefile "install-docs" (depended on by "install" and
hence "dist"), but not "build", ignores errors.

This was inherited from before 24563:4271634e4c86, prior to which the
||true seems intended to handle failures of check_pkgs.  Nowadays we
handle docs tools individually in the docs makefiles so there is no
need for this ||true here.

Signed-off-by: Ian Jackson 

diff -r 87bf99fad7a9 Makefile
--- a/Makefile	Tue Oct 02 12:14:00 2012 +0200
+++ b/Makefile	Tue Oct 09 10:29:42 2012 +0100
@@ -103,7 +103,7 @@ tools/firmware/seabios-dir-force-update:
 
 .PHONY: install-docs
 install-docs:
-	$(MAKE) -C docs install || true
+	$(MAKE) -C docs install
 
 .PHONY: dev-docs
 dev-docs:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 09:40:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 09:40:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLWIG-0008J2-0b; Tue, 09 Oct 2012 09:40:04 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLWIE-0008IT-2T
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 09:40:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1349775593!12010773!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6383 invoked from network); 9 Oct 2012 09:39:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 09:39:56 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15031909"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 09:39:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	10:39:56 +0100
Message-ID: <1349775594.21847.109.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Samuel Thibault 
Date: Tue, 9 Oct 2012 10:39:54 +0100
In-Reply-To: <20121008223502.GY5681@type.youpi.perso.aquilenet.fr>
References: <1349723202-14608-1-git-send-email-matthew.fioravante@jhuapl.edu>
	<1349723202-14608-2-git-send-email-matthew.fioravante@jhuapl.edu>
	<20121008223502.GY5681@type.youpi.perso.aquilenet.fr>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Matthew Fioravante ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH vtpm v3 02/12] add posix io for blkfront
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gTW9uLCAyMDEyLTEwLTA4IGF0IDIzOjM1ICswMTAwLCBTYW11ZWwgVGhpYmF1bHQgd3JvdGU6
Cj4gTWF0dGhldyBGaW9yYXZhbnRlLCBsZSBNb24gMDggT2N0IDIwMTIgMTU6MDY6NDIgLTA0MDAs
IGEgw6ljcml0IDoKPiA+IFRoaXMgcGF0Y2ggYWRkcyBwb3NpeCBpbyBzdXBwb3J0IChyZWFkLHdy
aXRlLGxzZWVrKSB0byBibG9jayBkZXZpY2VzCj4gPiB1c2luZyBibGtmcm9udC4KPiA+IAo+ID4g
U2lnbmVkLW9mZi1ieTogTWF0dGhldyBGaW9yYXZhbnRlIDxtYXR0aGV3LmZpb3JhdmFudGVAamh1
YXBsLmVkdT4KPiA+IEFja2VkLWJ5OiBTYW11ZWwgVGhpYmF1bHQgPHNhbXVlbC50aGliYXVsdEBl
bnMtbHlvbnMub3JnPgo+IAo+IENvbmZpcm1lZCBvbiB0aGlzIHZlcnNpb24uCgpBbmQgYXBwbGll
ZCwgdGhhbmtzLgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6
Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Oct 09 09:40:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 09:40:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLWIG-0008J2-0b; Tue, 09 Oct 2012 09:40:04 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLWIE-0008IT-2T
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 09:40:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1349775593!12010773!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6383 invoked from network); 9 Oct 2012 09:39:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 09:39:56 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15031909"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 09:39:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	10:39:56 +0100
Message-ID: <1349775594.21847.109.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Samuel Thibault 
Date: Tue, 9 Oct 2012 10:39:54 +0100
In-Reply-To: <20121008223502.GY5681@type.youpi.perso.aquilenet.fr>
References: <1349723202-14608-1-git-send-email-matthew.fioravante@jhuapl.edu>
	<1349723202-14608-2-git-send-email-matthew.fioravante@jhuapl.edu>
	<20121008223502.GY5681@type.youpi.perso.aquilenet.fr>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Matthew Fioravante ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH vtpm v3 02/12] add posix io for blkfront
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gTW9uLCAyMDEyLTEwLTA4IGF0IDIzOjM1ICswMTAwLCBTYW11ZWwgVGhpYmF1bHQgd3JvdGU6
Cj4gTWF0dGhldyBGaW9yYXZhbnRlLCBsZSBNb24gMDggT2N0IDIwMTIgMTU6MDY6NDIgLTA0MDAs
IGEgw6ljcml0IDoKPiA+IFRoaXMgcGF0Y2ggYWRkcyBwb3NpeCBpbyBzdXBwb3J0IChyZWFkLHdy
aXRlLGxzZWVrKSB0byBibG9jayBkZXZpY2VzCj4gPiB1c2luZyBibGtmcm9udC4KPiA+IAo+ID4g
U2lnbmVkLW9mZi1ieTogTWF0dGhldyBGaW9yYXZhbnRlIDxtYXR0aGV3LmZpb3JhdmFudGVAamh1
YXBsLmVkdT4KPiA+IEFja2VkLWJ5OiBTYW11ZWwgVGhpYmF1bHQgPHNhbXVlbC50aGliYXVsdEBl
bnMtbHlvbnMub3JnPgo+IAo+IENvbmZpcm1lZCBvbiB0aGlzIHZlcnNpb24uCgpBbmQgYXBwbGll
ZCwgdGhhbmtzLgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6
Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Oct 09 09:40:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 09:40:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLWIC-0008Ic-KO; Tue, 09 Oct 2012 09:40:00 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLWIB-0008IO-Oo
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 09:39:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1349775593!12010773!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6081 invoked from network); 9 Oct 2012 09:39:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 09:39:53 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15031905"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 09:39:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	10:39:53 +0100
Message-ID: <1349775591.21847.108.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Samuel Thibault 
Date: Tue, 9 Oct 2012 10:39:51 +0100
In-Reply-To: <20121008223352.GX5681@type.youpi.perso.aquilenet.fr>
References: <1349723202-14608-1-git-send-email-matthew.fioravante@jhuapl.edu>
	<20121008223352.GX5681@type.youpi.perso.aquilenet.fr>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Matthew Fioravante ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH vtpm v3 06/12] add select definition to
 sys/time.h when HAVE_LIBC is defined
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gTW9uLCAyMDEyLTEwLTA4IGF0IDIzOjMzICswMTAwLCBTYW11ZWwgVGhpYmF1bHQgd3JvdGU6
Cj4gTWF0dGhldyBGaW9yYXZhbnRlLCBsZSBNb24gMDggT2N0IDIwMTIgMTU6MDY6NDEgLTA0MDAs
IGEgw6ljcml0IDoKPiA+IFRoaXMgcGF0Y2ggYWRkcyB0aGUgc2VsZWN0IGZ1bmN0aW9uIHRvIHN5
cy90aW1lLmggd2hlbiBIQVZFX0xJQkMgaXMKPiA+IGRlZmluZWQsIHdoaWNoIGlzIGFjY29yZGlu
ZyB0byBzdGFuZGFyZCAoc2VlIHRoZSBzZWxlY3QoKSBtYW5wYWdlKS4KPiA+IEl0IGFsc28gcmVt
b3ZlcyBhIHJlZHVkYW50IGx3aXAgaW5jbHVkZSBmcm9tIHBvc2l4L3N5cy9zZWxlY3QuaC4KPiA+
IAo+ID4gU2lnbmVkLW9mZi1ieTogTWF0dGhldyBGaW9yYXZhbnRlIDxtYXR0aGV3LmZpb3JhdmFu
dGVAamh1YXBsLmVkdT4KPiAKPiBBY2tlZC1ieTogU2FtdWVsIFRoaWJhdWx0IDxzYW11ZWwudGhp
YmF1bHRAZW5zLWx5b24ub3JnPgoKYW5kIGFwcGxpZWQsIHRoYW5rcy4KCj4gCj4gPiBkaWZmIC0t
Z2l0IGEvZXh0cmFzL21pbmktb3MvaW5jbHVkZS9wb3NpeC9zeXMvc2VsZWN0LmggYi9leHRyYXMv
bWluaS1vcy9pbmNsdWRlL3Bvc2l4L3N5cy9zZWxlY3QuaAo+ID4gaW5kZXggYTkzMzdiZS4uNTEz
MmM1MSAxMDA2NDQKPiA+IC0tLSBhL2V4dHJhcy9taW5pLW9zL2luY2x1ZGUvcG9zaXgvc3lzL3Nl
bGVjdC5oCj4gPiArKysgYi9leHRyYXMvbWluaS1vcy9pbmNsdWRlL3Bvc2l4L3N5cy9zZWxlY3Qu
aAo+ID4gQEAgLTIsNyArMiw2IEBACj4gPiAgI2RlZmluZSBfUE9TSVhfU0VMRUNUX0gKPiA+ICAK
PiA+ICAjaW5jbHVkZSA8c3lzL3RpbWUuaD4KPiA+IC0jaW5jbHVkZSA8bHdpcC9zb2NrZXRzLmg+
Cj4gPiAgaW50IHNlbGVjdChpbnQgbmZkcywgZmRfc2V0ICpyZWFkZmRzLCBmZF9zZXQgKndyaXRl
ZmRzLCBmZF9zZXQgKmV4Y2VwdGZkcywgc3RydWN0IHRpbWV2YWwgKnRpbWVvdXQpOwo+ID4gIAo+
ID4gICNlbmRpZiAvKiBfUE9TSVhfU0VMRUNUX0ggKi8KPiA+IGRpZmYgLS1naXQgYS9leHRyYXMv
bWluaS1vcy9pbmNsdWRlL3N5cy90aW1lLmggYi9leHRyYXMvbWluaS1vcy9pbmNsdWRlL3N5cy90
aW1lLmgKPiA+IGluZGV4IGQ2NjIzYTQuLjNiZTM2NTMgMTAwNjQ0Cj4gPiAtLS0gYS9leHRyYXMv
bWluaS1vcy9pbmNsdWRlL3N5cy90aW1lLmgKPiA+ICsrKyBiL2V4dHJhcy9taW5pLW9zL2luY2x1
ZGUvc3lzL3RpbWUuaAo+ID4gQEAgLTIyLDYgKzIyLDcgQEAKPiA+ICAKPiA+ICAjaWZkZWYgSEFW
RV9MSUJDCj4gPiAgI2luY2x1ZGVfbmV4dCA8c3lzL3RpbWUuaD4KPiA+ICsKPiA+ICAjZWxzZQo+
ID4gIHN0cnVjdCB0aW1lc3BlYyB7Cj4gPiAgICAgIHRpbWVfdCAgICAgIHR2X3NlYzsKPiA+IEBA
IC0zNyw2ICszOCwxMCBAQCBzdHJ1Y3QgdGltZXZhbCB7Cj4gPiAgfTsKPiA+ICAKPiA+ICBpbnQg
ICAgICBnZXR0aW1lb2ZkYXkoc3RydWN0IHRpbWV2YWwgKnR2LCB2b2lkICp0eik7Cj4gPiArCj4g
PiArI2VuZGlmCj4gPiArI2lmZGVmIEhBVkVfTElCQwo+ID4gKyNpbmNsdWRlIDxzeXMvc2VsZWN0
Lmg+Cj4gPiAgI2VuZGlmCj4gPiAgCj4gPiAgI2VuZGlmIC8qIF9NSU5JT1NfU1lTX1RJTUVfSF8g
Ki8KPiA+IC0tIAo+ID4gMS43LjQuNAo+ID4gCj4gCgoKCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVs
QGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Oct 09 09:40:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 09:40:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLWIC-0008Ic-KO; Tue, 09 Oct 2012 09:40:00 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLWIB-0008IO-Oo
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 09:39:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1349775593!12010773!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6081 invoked from network); 9 Oct 2012 09:39:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 09:39:53 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15031905"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 09:39:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	10:39:53 +0100
Message-ID: <1349775591.21847.108.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Samuel Thibault 
Date: Tue, 9 Oct 2012 10:39:51 +0100
In-Reply-To: <20121008223352.GX5681@type.youpi.perso.aquilenet.fr>
References: <1349723202-14608-1-git-send-email-matthew.fioravante@jhuapl.edu>
	<20121008223352.GX5681@type.youpi.perso.aquilenet.fr>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Matthew Fioravante ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH vtpm v3 06/12] add select definition to
 sys/time.h when HAVE_LIBC is defined
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gTW9uLCAyMDEyLTEwLTA4IGF0IDIzOjMzICswMTAwLCBTYW11ZWwgVGhpYmF1bHQgd3JvdGU6
Cj4gTWF0dGhldyBGaW9yYXZhbnRlLCBsZSBNb24gMDggT2N0IDIwMTIgMTU6MDY6NDEgLTA0MDAs
IGEgw6ljcml0IDoKPiA+IFRoaXMgcGF0Y2ggYWRkcyB0aGUgc2VsZWN0IGZ1bmN0aW9uIHRvIHN5
cy90aW1lLmggd2hlbiBIQVZFX0xJQkMgaXMKPiA+IGRlZmluZWQsIHdoaWNoIGlzIGFjY29yZGlu
ZyB0byBzdGFuZGFyZCAoc2VlIHRoZSBzZWxlY3QoKSBtYW5wYWdlKS4KPiA+IEl0IGFsc28gcmVt
b3ZlcyBhIHJlZHVkYW50IGx3aXAgaW5jbHVkZSBmcm9tIHBvc2l4L3N5cy9zZWxlY3QuaC4KPiA+
IAo+ID4gU2lnbmVkLW9mZi1ieTogTWF0dGhldyBGaW9yYXZhbnRlIDxtYXR0aGV3LmZpb3JhdmFu
dGVAamh1YXBsLmVkdT4KPiAKPiBBY2tlZC1ieTogU2FtdWVsIFRoaWJhdWx0IDxzYW11ZWwudGhp
YmF1bHRAZW5zLWx5b24ub3JnPgoKYW5kIGFwcGxpZWQsIHRoYW5rcy4KCj4gCj4gPiBkaWZmIC0t
Z2l0IGEvZXh0cmFzL21pbmktb3MvaW5jbHVkZS9wb3NpeC9zeXMvc2VsZWN0LmggYi9leHRyYXMv
bWluaS1vcy9pbmNsdWRlL3Bvc2l4L3N5cy9zZWxlY3QuaAo+ID4gaW5kZXggYTkzMzdiZS4uNTEz
MmM1MSAxMDA2NDQKPiA+IC0tLSBhL2V4dHJhcy9taW5pLW9zL2luY2x1ZGUvcG9zaXgvc3lzL3Nl
bGVjdC5oCj4gPiArKysgYi9leHRyYXMvbWluaS1vcy9pbmNsdWRlL3Bvc2l4L3N5cy9zZWxlY3Qu
aAo+ID4gQEAgLTIsNyArMiw2IEBACj4gPiAgI2RlZmluZSBfUE9TSVhfU0VMRUNUX0gKPiA+ICAK
PiA+ICAjaW5jbHVkZSA8c3lzL3RpbWUuaD4KPiA+IC0jaW5jbHVkZSA8bHdpcC9zb2NrZXRzLmg+
Cj4gPiAgaW50IHNlbGVjdChpbnQgbmZkcywgZmRfc2V0ICpyZWFkZmRzLCBmZF9zZXQgKndyaXRl
ZmRzLCBmZF9zZXQgKmV4Y2VwdGZkcywgc3RydWN0IHRpbWV2YWwgKnRpbWVvdXQpOwo+ID4gIAo+
ID4gICNlbmRpZiAvKiBfUE9TSVhfU0VMRUNUX0ggKi8KPiA+IGRpZmYgLS1naXQgYS9leHRyYXMv
bWluaS1vcy9pbmNsdWRlL3N5cy90aW1lLmggYi9leHRyYXMvbWluaS1vcy9pbmNsdWRlL3N5cy90
aW1lLmgKPiA+IGluZGV4IGQ2NjIzYTQuLjNiZTM2NTMgMTAwNjQ0Cj4gPiAtLS0gYS9leHRyYXMv
bWluaS1vcy9pbmNsdWRlL3N5cy90aW1lLmgKPiA+ICsrKyBiL2V4dHJhcy9taW5pLW9zL2luY2x1
ZGUvc3lzL3RpbWUuaAo+ID4gQEAgLTIyLDYgKzIyLDcgQEAKPiA+ICAKPiA+ICAjaWZkZWYgSEFW
RV9MSUJDCj4gPiAgI2luY2x1ZGVfbmV4dCA8c3lzL3RpbWUuaD4KPiA+ICsKPiA+ICAjZWxzZQo+
ID4gIHN0cnVjdCB0aW1lc3BlYyB7Cj4gPiAgICAgIHRpbWVfdCAgICAgIHR2X3NlYzsKPiA+IEBA
IC0zNyw2ICszOCwxMCBAQCBzdHJ1Y3QgdGltZXZhbCB7Cj4gPiAgfTsKPiA+ICAKPiA+ICBpbnQg
ICAgICBnZXR0aW1lb2ZkYXkoc3RydWN0IHRpbWV2YWwgKnR2LCB2b2lkICp0eik7Cj4gPiArCj4g
PiArI2VuZGlmCj4gPiArI2lmZGVmIEhBVkVfTElCQwo+ID4gKyNpbmNsdWRlIDxzeXMvc2VsZWN0
Lmg+Cj4gPiAgI2VuZGlmCj4gPiAgCj4gPiAgI2VuZGlmIC8qIF9NSU5JT1NfU1lTX1RJTUVfSF8g
Ki8KPiA+IC0tIAo+ID4gMS43LjQuNAo+ID4gCj4gCgoKCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVs
QGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Oct 09 09:49:03 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 09:49:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLWQP-0000Bd-HA; Tue, 09 Oct 2012 09:48:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLWQO-0000BY-3R
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 09:48:28 +0000
Received: from [85.158.139.211:30647] by server-10.bemta-5.messagelabs.com id
	4A/04-16911-BE2F3705; Tue, 09 Oct 2012 09:48:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1349776106!21541486!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9946 invoked from network); 9 Oct 2012 09:48:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 09:48:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15032147"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 09:48:26 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	10:48:26 +0100
Message-ID: <1349776105.21847.112.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Ian Jackson 
Date: Tue, 9 Oct 2012 10:48:25 +0100
In-Reply-To: <20595.61420.34064.705987@mariner.uk.xensource.com>
References: 
	<1349769024.6952.64.camel@dagon.hellion.org.uk>
	<20595.60875.258078.801716@mariner.uk.xensource.com>
	<20595.61420.34064.705987@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [xen-unstable test] 13934: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-09 at 10:35 +0100, Ian Jackson wrote:
> Ian Jackson writes ("Re: [Xen-devel] [xen-unstable test] 13934: regressions - FAIL"):
> > This means the bug is in make or in the makefiles.  Let me investigate
> > further...
> 
> Subject: [PATCH] build, docs: Do not ignore install-docs errors
> 
> In the toplevel Makefile "install-docs" (depended on by "install" and
> hence "dist"), but not "build", ignores errors.
> 
> This was inherited from before 24563:4271634e4c86, prior to which the
> ||true seems intended to handle failures of check_pkgs.  Nowadays we
> handle docs tools individually in the docs makefiles so there is no
> need for this ||true here.

The docs/fig/Makefile doesn't seem to gracefully handle the absence of
fig2dev, I don't think we want this as an unconditional build dep do we?

It looks like we've inadvertently added an unconditional dependency on
pod2text too.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 09:49:03 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 09:49:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLWQP-0000Bd-HA; Tue, 09 Oct 2012 09:48:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLWQO-0000BY-3R
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 09:48:28 +0000
Received: from [85.158.139.211:30647] by server-10.bemta-5.messagelabs.com id
	4A/04-16911-BE2F3705; Tue, 09 Oct 2012 09:48:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1349776106!21541486!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9946 invoked from network); 9 Oct 2012 09:48:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 09:48:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15032147"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 09:48:26 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	10:48:26 +0100
Message-ID: <1349776105.21847.112.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Ian Jackson 
Date: Tue, 9 Oct 2012 10:48:25 +0100
In-Reply-To: <20595.61420.34064.705987@mariner.uk.xensource.com>
References: 
	<1349769024.6952.64.camel@dagon.hellion.org.uk>
	<20595.60875.258078.801716@mariner.uk.xensource.com>
	<20595.61420.34064.705987@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [xen-unstable test] 13934: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-09 at 10:35 +0100, Ian Jackson wrote:
> Ian Jackson writes ("Re: [Xen-devel] [xen-unstable test] 13934: regressions - FAIL"):
> > This means the bug is in make or in the makefiles.  Let me investigate
> > further...
> 
> Subject: [PATCH] build, docs: Do not ignore install-docs errors
> 
> In the toplevel Makefile "install-docs" (depended on by "install" and
> hence "dist"), but not "build", ignores errors.
> 
> This was inherited from before 24563:4271634e4c86, prior to which the
> ||true seems intended to handle failures of check_pkgs.  Nowadays we
> handle docs tools individually in the docs makefiles so there is no
> need for this ||true here.

The docs/fig/Makefile doesn't seem to gracefully handle the absence of
fig2dev, I don't think we want this as an unconditional build dep do we?

It looks like we've inadvertently added an unconditional dependency on
pod2text too.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 09:54:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 09:54:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLWVi-0000L4-8K; Tue, 09 Oct 2012 09:53:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLWVg-0000Ky-77
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 09:53:56 +0000
Received: from [85.158.139.83:24846] by server-7.bemta-5.messagelabs.com id
	2E/A3-00431-334F3705; Tue, 09 Oct 2012 09:53:55 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1349776434!26811607!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDI1NDQ5OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14352 invoked from network); 9 Oct 2012 09:53:54 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Oct 2012 09:53:54 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Message-ID:Date:From:Organization:
	User-Agent:MIME-Version:To:CC:Subject:References:
	In-Reply-To:Content-Type:Content-Transfer-Encoding;
	b=eUlCHhFM+ATt1m0c89vLVGRRO/fqrc+3QqfGnIej2LczY5BPSoksk8ki
	qDsbGlS1MU4e9U8tLgTFwQu/h20MXMBj/ZsL4LKyE6qW0Z2/su/t2jv3h
	MxOPEW5EIcfYPXQ8k1LgW4cQkVIgTI+UfwYC1lCYbk9wYJL6C16Ys79d6
	mvwZklZPRVrsUMSoKYEekBZuThqafJWmb6V+5imeQiHZeYvFreuZQVTmR
	XjtSYe1cY0wfqktZRKMur1bQ2d7I0;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=@ts.fujitsu.com; q=dns/txt;
	s=s1536b; t=1349776435; x=1381312435;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=PG3Kf8uZoNBM4WdpYBcSrl+VxUyLwR5zV8HfoJmNFTU=;
	b=k7RzTg6cx7JDpFBpNRWogOy0PyXiyYWHk6ukQ4LEl8yeEjHEqZsvroil
	w8ffRxc78n5N0GILRcQXU/CBj2Vvgi/lJoVEoWw81kFusFD6IkQgrkPDk
	oEK5TNROvhakH/0YKhijqbxUJAkB/DutwEh/QdHQiyxUUutM4CNVWYWYK
	atL8yDXouU5/Mgu3Z1Wx5F4lA9J68WaVtvNbOTYG5aQpGqcD9+WBdiGbx
	Si6/E+XyJwEubj3NvYJ9fWvIj9vxd;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.80,560,1344204000"; d="scan'208";a="124700273"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 09 Oct 2012 11:53:54 +0200
X-IronPort-AV: E=Sophos;i="4.80,558,1344204000"; d="scan'208";a="147005391"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 09 Oct 2012 11:53:53 +0200
Received: from [172.17.21.50] (verdon.osd.mch.fsc.net [172.17.21.50])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id ABD0196B161;
	Tue,  9 Oct 2012 11:53:53 +0200 (CEST)
Message-ID: <5073F431.1020500@ts.fujitsu.com>
Date: Tue, 09 Oct 2012 11:53:53 +0200
From: Juergen Gross 
Organization: Fujitsu Technology Solutions GmbH
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120724 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Dario Faggioli 
References: 
	
In-Reply-To: 
Cc: Marcus Granado ,
	Andre Przywara ,
	Ian Campbell ,
	Anil Madhavapeddy ,
	George Dunlap ,
	Andrew Cooper ,
	Ian Jackson , xen-devel@lists.xen.org,
	Jan Beulich , Daniel De Graaf ,
	Matt Wilson 
Subject: Re: [Xen-devel] [PATCH 3 of 8] xen: let the (credit) scheduler know
 about `node affinity`
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Am 05.10.2012 16:08, schrieb Dario Faggioli:
> As vcpu-affinity tells where vcpus can run, node-affinity tells
> where a domain's vcpus prefer to run. Respecting vcpu-affinity is
> the primary concern, but honouring node-affinity will likely
> result in some performances benefit.
>
> This change modifies the vcpu load balancing algorithm (for the
> credit scheduler only), introducing a two steps logic.
> During the first step, we use the node-affinity mask. The aim is
> giving precedence to the CPUs where it is known to be preferrable
> for the domain to run. If that fails in finding a valid CPU, the
> node-affinity is just ignored and, in the second step, we fall
> back to using cpu-affinity only.
>
> Signed-off-by: Dario Faggioli
>
> diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
> --- a/xen/common/sched_credit.c
> +++ b/xen/common/sched_credit.c
...
>   static int
>   _csched_cpu_pick(const struct scheduler *ops, struct vcpu *vc, bool_t commit)
>   {
> -    cpumask_t cpus;
> +    cpumask_t cpus, start_cpus;
>       cpumask_t idlers;
>       cpumask_t *online;
> +    struct csched_dom *sdom = CSCHED_DOM(vc->domain);
>       struct csched_pcpu *spc = NULL;
>       int cpu;
>
>       /*
> -     * Pick from online CPUs in VCPU's affinity mask, giving a
> -     * preference to its current processor if it's in there.
> +     * Pick an online CPU from the&&  of vcpu-affinity and node-affinity
> +     * masks (if not empty, in which case only the vcpu-affinity mask is
> +     * used). Also, try to give a preference to its current processor if
> +     * it's in there.
>        */
>       online = cpupool_scheduler_cpumask(vc->domain->cpupool);
>       cpumask_and(&cpus, online, vc->cpu_affinity);
> -    cpu = cpumask_test_cpu(vc->processor,&cpus)
> +    cpumask_and(&start_cpus,&cpus, sdom->node_affinity_cpumask);
> +    if ( unlikely(cpumask_empty(&start_cpus)) )
> +        cpumask_copy(&start_cpus,&cpus);
> +    cpu = cpumask_test_cpu(vc->processor,&start_cpus)
>               ? vc->processor
> -            : cpumask_cycle(vc->processor,&cpus);
> +            : cpumask_cycle(vc->processor,&start_cpus);
>       ASSERT( !cpumask_empty(&cpus)&&  cpumask_test_cpu(cpu,&cpus) );

Shouldn't the ASSERT be changed to start_cpus, too?


Juergen

-- 
Juergen Gross                 Principal Developer Operating Systems
PBG PDG ES&S SWE OS6                   Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujitsu.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 09:54:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 09:54:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLWVi-0000L4-8K; Tue, 09 Oct 2012 09:53:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLWVg-0000Ky-77
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 09:53:56 +0000
Received: from [85.158.139.83:24846] by server-7.bemta-5.messagelabs.com id
	2E/A3-00431-334F3705; Tue, 09 Oct 2012 09:53:55 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1349776434!26811607!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDI1NDQ5OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14352 invoked from network); 9 Oct 2012 09:53:54 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Oct 2012 09:53:54 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Message-ID:Date:From:Organization:
	User-Agent:MIME-Version:To:CC:Subject:References:
	In-Reply-To:Content-Type:Content-Transfer-Encoding;
	b=eUlCHhFM+ATt1m0c89vLVGRRO/fqrc+3QqfGnIej2LczY5BPSoksk8ki
	qDsbGlS1MU4e9U8tLgTFwQu/h20MXMBj/ZsL4LKyE6qW0Z2/su/t2jv3h
	MxOPEW5EIcfYPXQ8k1LgW4cQkVIgTI+UfwYC1lCYbk9wYJL6C16Ys79d6
	mvwZklZPRVrsUMSoKYEekBZuThqafJWmb6V+5imeQiHZeYvFreuZQVTmR
	XjtSYe1cY0wfqktZRKMur1bQ2d7I0;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=@ts.fujitsu.com; q=dns/txt;
	s=s1536b; t=1349776435; x=1381312435;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=PG3Kf8uZoNBM4WdpYBcSrl+VxUyLwR5zV8HfoJmNFTU=;
	b=k7RzTg6cx7JDpFBpNRWogOy0PyXiyYWHk6ukQ4LEl8yeEjHEqZsvroil
	w8ffRxc78n5N0GILRcQXU/CBj2Vvgi/lJoVEoWw81kFusFD6IkQgrkPDk
	oEK5TNROvhakH/0YKhijqbxUJAkB/DutwEh/QdHQiyxUUutM4CNVWYWYK
	atL8yDXouU5/Mgu3Z1Wx5F4lA9J68WaVtvNbOTYG5aQpGqcD9+WBdiGbx
	Si6/E+XyJwEubj3NvYJ9fWvIj9vxd;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.80,560,1344204000"; d="scan'208";a="124700273"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 09 Oct 2012 11:53:54 +0200
X-IronPort-AV: E=Sophos;i="4.80,558,1344204000"; d="scan'208";a="147005391"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 09 Oct 2012 11:53:53 +0200
Received: from [172.17.21.50] (verdon.osd.mch.fsc.net [172.17.21.50])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id ABD0196B161;
	Tue,  9 Oct 2012 11:53:53 +0200 (CEST)
Message-ID: <5073F431.1020500@ts.fujitsu.com>
Date: Tue, 09 Oct 2012 11:53:53 +0200
From: Juergen Gross 
Organization: Fujitsu Technology Solutions GmbH
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120724 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Dario Faggioli 
References: 
	
In-Reply-To: 
Cc: Marcus Granado ,
	Andre Przywara ,
	Ian Campbell ,
	Anil Madhavapeddy ,
	George Dunlap ,
	Andrew Cooper ,
	Ian Jackson , xen-devel@lists.xen.org,
	Jan Beulich , Daniel De Graaf ,
	Matt Wilson 
Subject: Re: [Xen-devel] [PATCH 3 of 8] xen: let the (credit) scheduler know
 about `node affinity`
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Am 05.10.2012 16:08, schrieb Dario Faggioli:
> As vcpu-affinity tells where vcpus can run, node-affinity tells
> where a domain's vcpus prefer to run. Respecting vcpu-affinity is
> the primary concern, but honouring node-affinity will likely
> result in some performances benefit.
>
> This change modifies the vcpu load balancing algorithm (for the
> credit scheduler only), introducing a two steps logic.
> During the first step, we use the node-affinity mask. The aim is
> giving precedence to the CPUs where it is known to be preferrable
> for the domain to run. If that fails in finding a valid CPU, the
> node-affinity is just ignored and, in the second step, we fall
> back to using cpu-affinity only.
>
> Signed-off-by: Dario Faggioli
>
> diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
> --- a/xen/common/sched_credit.c
> +++ b/xen/common/sched_credit.c
...
>   static int
>   _csched_cpu_pick(const struct scheduler *ops, struct vcpu *vc, bool_t commit)
>   {
> -    cpumask_t cpus;
> +    cpumask_t cpus, start_cpus;
>       cpumask_t idlers;
>       cpumask_t *online;
> +    struct csched_dom *sdom = CSCHED_DOM(vc->domain);
>       struct csched_pcpu *spc = NULL;
>       int cpu;
>
>       /*
> -     * Pick from online CPUs in VCPU's affinity mask, giving a
> -     * preference to its current processor if it's in there.
> +     * Pick an online CPU from the&&  of vcpu-affinity and node-affinity
> +     * masks (if not empty, in which case only the vcpu-affinity mask is
> +     * used). Also, try to give a preference to its current processor if
> +     * it's in there.
>        */
>       online = cpupool_scheduler_cpumask(vc->domain->cpupool);
>       cpumask_and(&cpus, online, vc->cpu_affinity);
> -    cpu = cpumask_test_cpu(vc->processor,&cpus)
> +    cpumask_and(&start_cpus,&cpus, sdom->node_affinity_cpumask);
> +    if ( unlikely(cpumask_empty(&start_cpus)) )
> +        cpumask_copy(&start_cpus,&cpus);
> +    cpu = cpumask_test_cpu(vc->processor,&start_cpus)
>               ? vc->processor
> -            : cpumask_cycle(vc->processor,&cpus);
> +            : cpumask_cycle(vc->processor,&start_cpus);
>       ASSERT( !cpumask_empty(&cpus)&&  cpumask_test_cpu(cpu,&cpus) );

Shouldn't the ASSERT be changed to start_cpus, too?


Juergen

-- 
Juergen Gross                 Principal Developer Operating Systems
PBG PDG ES&S SWE OS6                   Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujitsu.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 09:56:20 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 09:56:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLWXn-0000R4-Og; Tue, 09 Oct 2012 09:56:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLWXm-0000Qy-Kx
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 09:56:06 +0000
Received: from [85.158.143.35:57984] by server-3.bemta-4.messagelabs.com id
	5E/92-10986-6B4F3705; Tue, 09 Oct 2012 09:56:06 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1349776549!14750034!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzUyMTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23903 invoked from network); 9 Oct 2012 09:55:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 09:55:51 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="40567300"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 09:55:43 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 9 Oct 2012 05:55:43 -0400
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TLWXO-0005SP-Oe;
	Tue, 09 Oct 2012 10:55:42 +0100
Message-ID: <5073F49E.3020204@citrix.com>
Date: Tue, 9 Oct 2012 10:55:42 +0100
From: Andrew Cooper 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: Keir Fraser 
References: 
In-Reply-To: 
X-Enigmail-Version: 1.4.4
Cc: Jan Beulich ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 0 of 3] Introduce more debugging flexibility
 with ASSERT() macros
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 08/10/12 19:31, Keir Fraser wrote:
> On 08/10/2012 19:16, "Andrew Cooper"  wrote:
>
>> The following three patches introduce several debugging macros I have
>> been using for a long time while debugging issues in Xen.
>>
>> ASSERT_PRINK() is hopefully obvious, and ASSERT_RUN() is useful when
>> more complicated printing is required.
> Are these going to get enough use to be worthwhile, rather than open-coding
> them where necessary? In many places we may not care about being able to
> disable the check-and-crash, so avoiding ifdefs is not necessarily a good
> argument.
>
>  -- Keir

I hope that ASSERT_PRINTK() will start seeing quite a lot of use,
especially with compound conditional statements where is is impossible
from crash to see which of the individual conditionals failed.

ASSERT_RUN() perhaps not so, but having it available means one less
thing to opencode when debugging.


I had not considered the case for {WARN,BUG}_PRINTK() which have the
same argument as ASSERT_PRINTK().  Would you like to see them introduced
as well?

~Andrew

>
>> The final macro ASSERT_RUN_SINGLE() is not fit for upstream yet.  It is
>> designed to force all other PCPUs into a wait loop in an NMI context, so
>> the ASSERT()'ing processor can walk data structures without locks, and
>> without fear that values are changing under its feet.  I will work on
>> integrating this into the crash code (as it has a similar setup for the
>> start of the kexec_crash() path), and upstream when I have time.
>>
>> ~Andrew
>

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 09:56:20 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 09:56:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLWXn-0000R4-Og; Tue, 09 Oct 2012 09:56:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLWXm-0000Qy-Kx
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 09:56:06 +0000
Received: from [85.158.143.35:57984] by server-3.bemta-4.messagelabs.com id
	5E/92-10986-6B4F3705; Tue, 09 Oct 2012 09:56:06 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1349776549!14750034!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzUyMTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23903 invoked from network); 9 Oct 2012 09:55:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 09:55:51 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="40567300"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 09:55:43 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 9 Oct 2012 05:55:43 -0400
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TLWXO-0005SP-Oe;
	Tue, 09 Oct 2012 10:55:42 +0100
Message-ID: <5073F49E.3020204@citrix.com>
Date: Tue, 9 Oct 2012 10:55:42 +0100
From: Andrew Cooper 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: Keir Fraser 
References: 
In-Reply-To: 
X-Enigmail-Version: 1.4.4
Cc: Jan Beulich ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 0 of 3] Introduce more debugging flexibility
 with ASSERT() macros
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 08/10/12 19:31, Keir Fraser wrote:
> On 08/10/2012 19:16, "Andrew Cooper"  wrote:
>
>> The following three patches introduce several debugging macros I have
>> been using for a long time while debugging issues in Xen.
>>
>> ASSERT_PRINK() is hopefully obvious, and ASSERT_RUN() is useful when
>> more complicated printing is required.
> Are these going to get enough use to be worthwhile, rather than open-coding
> them where necessary? In many places we may not care about being able to
> disable the check-and-crash, so avoiding ifdefs is not necessarily a good
> argument.
>
>  -- Keir

I hope that ASSERT_PRINTK() will start seeing quite a lot of use,
especially with compound conditional statements where is is impossible
from crash to see which of the individual conditionals failed.

ASSERT_RUN() perhaps not so, but having it available means one less
thing to opencode when debugging.


I had not considered the case for {WARN,BUG}_PRINTK() which have the
same argument as ASSERT_PRINTK().  Would you like to see them introduced
as well?

~Andrew

>
>> The final macro ASSERT_RUN_SINGLE() is not fit for upstream yet.  It is
>> designed to force all other PCPUs into a wait loop in an NMI context, so
>> the ASSERT()'ing processor can walk data structures without locks, and
>> without fear that values are changing under its feet.  I will work on
>> integrating this into the crash code (as it has a similar setup for the
>> start of the kexec_crash() path), and upstream when I have time.
>>
>> ~Andrew
>

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 10:02:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 10:02:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLWdX-0000h7-I8; Tue, 09 Oct 2012 10:02:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLWdW-0000h1-7O
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 10:02:02 +0000
Received: from [85.158.139.83:52561] by server-1.bemta-5.messagelabs.com id
	B5/8C-09825-916F3705; Tue, 09 Oct 2012 10:02:01 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1349776920!29747978!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDI1NDQ5OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12886 invoked from network); 9 Oct 2012 10:02:00 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Oct 2012 10:02:00 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Message-ID:Date:From:Organization:
	User-Agent:MIME-Version:To:CC:Subject:References:
	In-Reply-To:Content-Type:Content-Transfer-Encoding;
	b=s0YxwfsQYUmNpa+HanAsErz9FPlJ36AfR1WFmiIoZDNpVB7s1/LwiaV2
	6VQ1NML35SxN4jgnJA9RQwzPx3eoeBqIu/SQjH05oEwcjIUbeYuoBbzyg
	RrQPOwt6kuIaDapW91wVFvaLk9GBaaH4iC2AHSONs0NnMFi2PEFOYt94X
	WoxJLpbrX37oH7bSLNtEhV49BZ1j2qtnQ8DWOZQ/ctJ/rUDXLLENPT7+u
	+Uw0Z0ANICSjGMMBUtSe7d8+R1VEV;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=@ts.fujitsu.com; q=dns/txt;
	s=s1536b; t=1349776921; x=1381312921;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=u5MgRrTCuYgJ4i9DS20yUcVY3UqPk+tsb/eILzP9lK0=;
	b=QvSGFFNsDzehNgLFNJNtSD7TifBgtufp4pXJjjS1x+xIwH7MRaDclQyI
	QkJ+w4qDAX5K4d8a70jXn4qgL4DehEWVw0iliQ9SqMaNb3fWhLoyeiEM7
	9D5kWXA9lIlf3kExnEyuwqfUTyyVLFcEbNac+2IZszwFgSkiDwX9nPjxW
	UmMHcT9g2gCEeiJDGJh8k3SVw4Rq9KoF87k3Wlnr9DvwQFHOqiSJomCoe
	CcdX9JrpBnSUEGhdzmtbt4hUroQ1C;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.80,560,1344204000"; d="scan'208";a="124702115"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 09 Oct 2012 12:02:00 +0200
X-IronPort-AV: E=Sophos;i="4.80,560,1344204000"; d="scan'208";a="147006255"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 09 Oct 2012 12:02:00 +0200
Received: from [172.17.21.50] (verdon.osd.mch.fsc.net [172.17.21.50])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 6556C9694A7;
	Tue,  9 Oct 2012 12:02:00 +0200 (CEST)
Message-ID: <5073F618.7020709@ts.fujitsu.com>
Date: Tue, 09 Oct 2012 12:02:00 +0200
From: Juergen Gross 
Organization: Fujitsu Technology Solutions GmbH
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120724 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Dario Faggioli 
References: 
In-Reply-To: 
Cc: Marcus Granado ,
	Andre Przywara ,
	Ian Campbell ,
	Anil Madhavapeddy ,
	George Dunlap ,
	Andrew Cooper ,
	Ian Jackson , xen-devel@lists.xen.org,
	Jan Beulich , Daniel De Graaf ,
	Matt Wilson 
Subject: Re: [Xen-devel] [PATCH 0 of 8] NUMA Awareness for the Credit
	Scheduler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Am 05.10.2012 16:08, schrieb Dario Faggioli:
> Hi Everyone,
>
> Here it comes a patch series instilling some NUMA awareness in the Credit
> scheduler.
>
> What the patches do is teaching the Xen's scheduler how to try maximizing
> performances on a NUMA host, taking advantage of the information coming from
> the automatic NUMA placement we have in libxl.  Right now, the
> placement algorithm runs and selects a node (or a set of nodes) where it is best
> to put a new domain on. Then, all the memory for the new domain is allocated
> from those node(s) and all the vCPUs of the new domain are pinned to the pCPUs
> of those node(s). What we do here is, instead of statically pinning the domain's
> vCPUs to the nodes' pCPUs, have the (Credit) scheduler _prefer_ running them
> there. That enables most of the performances benefits of "real" pinning, but
> without its intrinsic lack of flexibility.
>
> The above happens by extending to the scheduler the knowledge of a domain's
> node-affinity. We then ask it to first try to run the domain's vCPUs on one of
> the nodes the domain has affinity with. Of course, if that turns out to be
> impossible, it falls back on the old behaviour (i.e., considering vcpu-affinity
> only).
>
> Just allow me to mention that NUMA aware scheduling not only is one of the item
> of the NUMA roadmap I'm trying to maintain here
> http://wiki.xen.org/wiki/Xen_NUMA_Roadmap. It is also one of the features we
> decided we want for Xen 4.3 (and thus it is part of the list of such features
> that George is maintaining).
>
> Up to now, I've been able to thoroughly test this only on my 2 NUMA nodes
> testbox, by running the SpecJBB2005 benchmark concurrently on multiple VMs, and
> the results looks really nice.  A full set of what I got can be found inside my
> presentation from last XenSummit, which is available here:
>
>   http://www.slideshare.net/xen_com_mgr/numa-and-virtualization-the-case-of-xen?ref=http://www.xen.org/xensummit/xs12na_talks/T9.html
>
> However, I rerun some of the tests in these last days (since I changed some
> bits of the implementation) and here's what I got:
>
> -------------------------------------------------------
>   SpecJBB2005 Total Aggregate Throughput
> -------------------------------------------------------
> #VMs       No NUMA affinity     NUMA affinity&    +/- %
>                                    scheduling
> -------------------------------------------------------
>     2            34653.273          40243.015    +16.13%
>     4            29883.057          35526.807    +18.88%
>     6            23512.926          27015.786    +14.89%
>     8            19120.243          21825.818    +14.15%
>    10            15676.675          17701.472    +12.91%
>
> Basically, results are consistent with what is shown in the super-nice graphs I
> have in the slides above! :-) As said, this looks nice to me, especially
> considering that my test machine is quite small, i.e., its 2 nodes are very
> close to each others from a latency point of view. I really expect more
> improvement on bigger hardware, where much greater NUMA effect is to be
> expected.  Of course, I myself will continue benchmarking (hopefully, on
> systems with more than 2 nodes too), but should anyone want to run its own
> testing, that would be great, so feel free to do that and report results to me
> and/or to the list!
>
> A little bit more about the series:
>
>   1/8 xen, libxc: rename xenctl_cpumap to xenctl_bitmap
>   2/8 xen, libxc: introduce node maps and masks
>
> Is some preparation work.
>
>   3/8 xen: let the (credit) scheduler know about `node affinity`
>
> Is where the vcpu load balancing logic of the credit scheduler is modified to
> support node-affinity.
>
>   4/8 xen: allow for explicitly specifying node-affinity
>   5/8 libxc: allow for explicitly specifying node-affinity
>   6/8 libxl: allow for explicitly specifying node-affinity
>   7/8 libxl: automatic placement deals with node-affinity
>
> Is what wires the in-scheduler node-affinity support with the external world.
> Please, note that patch 4 touches XSM and Flask, which is the area with which I
> have less experience and less chance to test properly. So, If Daniel and/or
> anyone interested in that could take a look and comment, that would be awesome.
>
>   8/8 xl: report node-affinity for domains
>
> Is just some small output enhancement.

Apart from the minor comment to Patch 3:

Acked-by: Juergen Gross 


-- 
Juergen Gross                 Principal Developer Operating Systems
PBG PDG ES&S SWE OS6                   Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujitsu.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 10:02:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 10:02:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLWdX-0000h7-I8; Tue, 09 Oct 2012 10:02:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLWdW-0000h1-7O
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 10:02:02 +0000
Received: from [85.158.139.83:52561] by server-1.bemta-5.messagelabs.com id
	B5/8C-09825-916F3705; Tue, 09 Oct 2012 10:02:01 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1349776920!29747978!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDI1NDQ5OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12886 invoked from network); 9 Oct 2012 10:02:00 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Oct 2012 10:02:00 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Message-ID:Date:From:Organization:
	User-Agent:MIME-Version:To:CC:Subject:References:
	In-Reply-To:Content-Type:Content-Transfer-Encoding;
	b=s0YxwfsQYUmNpa+HanAsErz9FPlJ36AfR1WFmiIoZDNpVB7s1/LwiaV2
	6VQ1NML35SxN4jgnJA9RQwzPx3eoeBqIu/SQjH05oEwcjIUbeYuoBbzyg
	RrQPOwt6kuIaDapW91wVFvaLk9GBaaH4iC2AHSONs0NnMFi2PEFOYt94X
	WoxJLpbrX37oH7bSLNtEhV49BZ1j2qtnQ8DWOZQ/ctJ/rUDXLLENPT7+u
	+Uw0Z0ANICSjGMMBUtSe7d8+R1VEV;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=@ts.fujitsu.com; q=dns/txt;
	s=s1536b; t=1349776921; x=1381312921;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=u5MgRrTCuYgJ4i9DS20yUcVY3UqPk+tsb/eILzP9lK0=;
	b=QvSGFFNsDzehNgLFNJNtSD7TifBgtufp4pXJjjS1x+xIwH7MRaDclQyI
	QkJ+w4qDAX5K4d8a70jXn4qgL4DehEWVw0iliQ9SqMaNb3fWhLoyeiEM7
	9D5kWXA9lIlf3kExnEyuwqfUTyyVLFcEbNac+2IZszwFgSkiDwX9nPjxW
	UmMHcT9g2gCEeiJDGJh8k3SVw4Rq9KoF87k3Wlnr9DvwQFHOqiSJomCoe
	CcdX9JrpBnSUEGhdzmtbt4hUroQ1C;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.80,560,1344204000"; d="scan'208";a="124702115"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 09 Oct 2012 12:02:00 +0200
X-IronPort-AV: E=Sophos;i="4.80,560,1344204000"; d="scan'208";a="147006255"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 09 Oct 2012 12:02:00 +0200
Received: from [172.17.21.50] (verdon.osd.mch.fsc.net [172.17.21.50])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 6556C9694A7;
	Tue,  9 Oct 2012 12:02:00 +0200 (CEST)
Message-ID: <5073F618.7020709@ts.fujitsu.com>
Date: Tue, 09 Oct 2012 12:02:00 +0200
From: Juergen Gross 
Organization: Fujitsu Technology Solutions GmbH
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120724 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Dario Faggioli 
References: 
In-Reply-To: 
Cc: Marcus Granado ,
	Andre Przywara ,
	Ian Campbell ,
	Anil Madhavapeddy ,
	George Dunlap ,
	Andrew Cooper ,
	Ian Jackson , xen-devel@lists.xen.org,
	Jan Beulich , Daniel De Graaf ,
	Matt Wilson 
Subject: Re: [Xen-devel] [PATCH 0 of 8] NUMA Awareness for the Credit
	Scheduler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Am 05.10.2012 16:08, schrieb Dario Faggioli:
> Hi Everyone,
>
> Here it comes a patch series instilling some NUMA awareness in the Credit
> scheduler.
>
> What the patches do is teaching the Xen's scheduler how to try maximizing
> performances on a NUMA host, taking advantage of the information coming from
> the automatic NUMA placement we have in libxl.  Right now, the
> placement algorithm runs and selects a node (or a set of nodes) where it is best
> to put a new domain on. Then, all the memory for the new domain is allocated
> from those node(s) and all the vCPUs of the new domain are pinned to the pCPUs
> of those node(s). What we do here is, instead of statically pinning the domain's
> vCPUs to the nodes' pCPUs, have the (Credit) scheduler _prefer_ running them
> there. That enables most of the performances benefits of "real" pinning, but
> without its intrinsic lack of flexibility.
>
> The above happens by extending to the scheduler the knowledge of a domain's
> node-affinity. We then ask it to first try to run the domain's vCPUs on one of
> the nodes the domain has affinity with. Of course, if that turns out to be
> impossible, it falls back on the old behaviour (i.e., considering vcpu-affinity
> only).
>
> Just allow me to mention that NUMA aware scheduling not only is one of the item
> of the NUMA roadmap I'm trying to maintain here
> http://wiki.xen.org/wiki/Xen_NUMA_Roadmap. It is also one of the features we
> decided we want for Xen 4.3 (and thus it is part of the list of such features
> that George is maintaining).
>
> Up to now, I've been able to thoroughly test this only on my 2 NUMA nodes
> testbox, by running the SpecJBB2005 benchmark concurrently on multiple VMs, and
> the results looks really nice.  A full set of what I got can be found inside my
> presentation from last XenSummit, which is available here:
>
>   http://www.slideshare.net/xen_com_mgr/numa-and-virtualization-the-case-of-xen?ref=http://www.xen.org/xensummit/xs12na_talks/T9.html
>
> However, I rerun some of the tests in these last days (since I changed some
> bits of the implementation) and here's what I got:
>
> -------------------------------------------------------
>   SpecJBB2005 Total Aggregate Throughput
> -------------------------------------------------------
> #VMs       No NUMA affinity     NUMA affinity&    +/- %
>                                    scheduling
> -------------------------------------------------------
>     2            34653.273          40243.015    +16.13%
>     4            29883.057          35526.807    +18.88%
>     6            23512.926          27015.786    +14.89%
>     8            19120.243          21825.818    +14.15%
>    10            15676.675          17701.472    +12.91%
>
> Basically, results are consistent with what is shown in the super-nice graphs I
> have in the slides above! :-) As said, this looks nice to me, especially
> considering that my test machine is quite small, i.e., its 2 nodes are very
> close to each others from a latency point of view. I really expect more
> improvement on bigger hardware, where much greater NUMA effect is to be
> expected.  Of course, I myself will continue benchmarking (hopefully, on
> systems with more than 2 nodes too), but should anyone want to run its own
> testing, that would be great, so feel free to do that and report results to me
> and/or to the list!
>
> A little bit more about the series:
>
>   1/8 xen, libxc: rename xenctl_cpumap to xenctl_bitmap
>   2/8 xen, libxc: introduce node maps and masks
>
> Is some preparation work.
>
>   3/8 xen: let the (credit) scheduler know about `node affinity`
>
> Is where the vcpu load balancing logic of the credit scheduler is modified to
> support node-affinity.
>
>   4/8 xen: allow for explicitly specifying node-affinity
>   5/8 libxc: allow for explicitly specifying node-affinity
>   6/8 libxl: allow for explicitly specifying node-affinity
>   7/8 libxl: automatic placement deals with node-affinity
>
> Is what wires the in-scheduler node-affinity support with the external world.
> Please, note that patch 4 touches XSM and Flask, which is the area with which I
> have less experience and less chance to test properly. So, If Daniel and/or
> anyone interested in that could take a look and comment, that would be awesome.
>
>   8/8 xl: report node-affinity for domains
>
> Is just some small output enhancement.

Apart from the minor comment to Patch 3:

Acked-by: Juergen Gross 


-- 
Juergen Gross                 Principal Developer Operating Systems
PBG PDG ES&S SWE OS6                   Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujitsu.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 10:22:23 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 10:22:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLWwd-0000vA-J4; Tue, 09 Oct 2012 10:21:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLWwb-0000v4-PC
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 10:21:46 +0000
Received: from [85.158.138.51:11822] by server-8.bemta-3.messagelabs.com id
	DD/2F-16337-9BAF3705; Tue, 09 Oct 2012 10:21:45 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1349778104!27323065!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22812 invoked from network); 9 Oct 2012 10:21:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 10:21:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; 
	d="asc'?scan'208";a="15033156"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 10:21:43 +0000
Received: from [IPv6:::1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	11:21:43 +0100
Message-ID: <1349778102.3610.55.camel@Abyss>
From: Dario Faggioli 
To: Juergen Gross 
Date: Tue, 9 Oct 2012 11:21:42 +0100
In-Reply-To: <5073F431.1020500@ts.fujitsu.com>
References: 
	
	<5073F431.1020500@ts.fujitsu.com>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
MIME-Version: 1.0
Cc: Marcus Granado ,
	Andre Przywara ,
	Ian Campbell , Anil
	Madhavapeddy ,
	George Dunlap ,
	Andrew Cooper ,
	Ian Jackson , xen-devel@lists.xen.org,
	Jan Beulich , Daniel De Graaf ,
	Matt Wilson 
Subject: Re: [Xen-devel] [PATCH 3 of 8] xen: let the (credit) scheduler know
 about `node affinity`
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============2116320985017608953=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2116320985017608953==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-ncrXDeHAw5vv2oIqgQGO"

--=-ncrXDeHAw5vv2oIqgQGO
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2012-10-09 at 11:53 +0200, Juergen Gross wrote:=20
> > diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
> > --- a/xen/common/sched_credit.c
> > +++ b/xen/common/sched_credit.c
> ...
> >   static int
> >   _csched_cpu_pick(const struct scheduler *ops, struct vcpu *vc, bool_t=
 commit)
> >   {
> > -    cpumask_t cpus;
> > +    cpumask_t cpus, start_cpus;
> >       cpumask_t idlers;
> >       cpumask_t *online;
> > +    struct csched_dom *sdom =3D CSCHED_DOM(vc->domain);
> >       struct csched_pcpu *spc =3D NULL;
> >       int cpu;
> >
> >       /*
> > -     * Pick from online CPUs in VCPU's affinity mask, giving a
> > -     * preference to its current processor if it's in there.
> > +     * Pick an online CPU from the&&  of vcpu-affinity and node-affini=
ty
> > +     * masks (if not empty, in which case only the vcpu-affinity mask =
is
> > +     * used). Also, try to give a preference to its current processor =
if
> > +     * it's in there.
> >        */
> >       online =3D cpupool_scheduler_cpumask(vc->domain->cpupool);
> >       cpumask_and(&cpus, online, vc->cpu_affinity);
> > -    cpu =3D cpumask_test_cpu(vc->processor,&cpus)
> > +    cpumask_and(&start_cpus,&cpus, sdom->node_affinity_cpumask);
> > +    if ( unlikely(cpumask_empty(&start_cpus)) )
> > +        cpumask_copy(&start_cpus,&cpus);
> > +    cpu =3D cpumask_test_cpu(vc->processor,&start_cpus)
> >               ? vc->processor
> > -            : cpumask_cycle(vc->processor,&cpus);
> > +            : cpumask_cycle(vc->processor,&start_cpus);
> >       ASSERT( !cpumask_empty(&cpus)&&  cpumask_test_cpu(cpu,&cpus) );
>=20
> Shouldn't the ASSERT be changed to start_cpus, too?
>=20
Well, it seems it definitely should, and I seem to have missed that!=20

Thanks a lot,
Dario

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-ncrXDeHAw5vv2oIqgQGO
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEUEABECAAYFAlBz+rYACgkQk4XaBE3IOsRtngCgo3DRGWzjJ4jicURE71BfNpNN
cTcAmMNAw4PxuAgNK/hWDTxDzmrHizQ=
=Xt9i
-----END PGP SIGNATURE-----

--=-ncrXDeHAw5vv2oIqgQGO--


--===============2116320985017608953==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2116320985017608953==--


From xen-devel-bounces@lists.xen.org Tue Oct 09 10:22:23 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 10:22:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLWwd-0000vA-J4; Tue, 09 Oct 2012 10:21:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLWwb-0000v4-PC
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 10:21:46 +0000
Received: from [85.158.138.51:11822] by server-8.bemta-3.messagelabs.com id
	DD/2F-16337-9BAF3705; Tue, 09 Oct 2012 10:21:45 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1349778104!27323065!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22812 invoked from network); 9 Oct 2012 10:21:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 10:21:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; 
	d="asc'?scan'208";a="15033156"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 10:21:43 +0000
Received: from [IPv6:::1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	11:21:43 +0100
Message-ID: <1349778102.3610.55.camel@Abyss>
From: Dario Faggioli 
To: Juergen Gross 
Date: Tue, 9 Oct 2012 11:21:42 +0100
In-Reply-To: <5073F431.1020500@ts.fujitsu.com>
References: 
	
	<5073F431.1020500@ts.fujitsu.com>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
MIME-Version: 1.0
Cc: Marcus Granado ,
	Andre Przywara ,
	Ian Campbell , Anil
	Madhavapeddy ,
	George Dunlap ,
	Andrew Cooper ,
	Ian Jackson , xen-devel@lists.xen.org,
	Jan Beulich , Daniel De Graaf ,
	Matt Wilson 
Subject: Re: [Xen-devel] [PATCH 3 of 8] xen: let the (credit) scheduler know
 about `node affinity`
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============2116320985017608953=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2116320985017608953==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-ncrXDeHAw5vv2oIqgQGO"

--=-ncrXDeHAw5vv2oIqgQGO
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2012-10-09 at 11:53 +0200, Juergen Gross wrote:=20
> > diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
> > --- a/xen/common/sched_credit.c
> > +++ b/xen/common/sched_credit.c
> ...
> >   static int
> >   _csched_cpu_pick(const struct scheduler *ops, struct vcpu *vc, bool_t=
 commit)
> >   {
> > -    cpumask_t cpus;
> > +    cpumask_t cpus, start_cpus;
> >       cpumask_t idlers;
> >       cpumask_t *online;
> > +    struct csched_dom *sdom =3D CSCHED_DOM(vc->domain);
> >       struct csched_pcpu *spc =3D NULL;
> >       int cpu;
> >
> >       /*
> > -     * Pick from online CPUs in VCPU's affinity mask, giving a
> > -     * preference to its current processor if it's in there.
> > +     * Pick an online CPU from the&&  of vcpu-affinity and node-affini=
ty
> > +     * masks (if not empty, in which case only the vcpu-affinity mask =
is
> > +     * used). Also, try to give a preference to its current processor =
if
> > +     * it's in there.
> >        */
> >       online =3D cpupool_scheduler_cpumask(vc->domain->cpupool);
> >       cpumask_and(&cpus, online, vc->cpu_affinity);
> > -    cpu =3D cpumask_test_cpu(vc->processor,&cpus)
> > +    cpumask_and(&start_cpus,&cpus, sdom->node_affinity_cpumask);
> > +    if ( unlikely(cpumask_empty(&start_cpus)) )
> > +        cpumask_copy(&start_cpus,&cpus);
> > +    cpu =3D cpumask_test_cpu(vc->processor,&start_cpus)
> >               ? vc->processor
> > -            : cpumask_cycle(vc->processor,&cpus);
> > +            : cpumask_cycle(vc->processor,&start_cpus);
> >       ASSERT( !cpumask_empty(&cpus)&&  cpumask_test_cpu(cpu,&cpus) );
>=20
> Shouldn't the ASSERT be changed to start_cpus, too?
>=20
Well, it seems it definitely should, and I seem to have missed that!=20

Thanks a lot,
Dario

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-ncrXDeHAw5vv2oIqgQGO
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEUEABECAAYFAlBz+rYACgkQk4XaBE3IOsRtngCgo3DRGWzjJ4jicURE71BfNpNN
cTcAmMNAw4PxuAgNK/hWDTxDzmrHizQ=
=Xt9i
-----END PGP SIGNATURE-----

--=-ncrXDeHAw5vv2oIqgQGO--


--===============2116320985017608953==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2116320985017608953==--


From xen-devel-bounces@lists.xen.org Tue Oct 09 10:30:12 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 10:30:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLX47-00014Z-HK; Tue, 09 Oct 2012 10:29:31 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLX46-00014N-6i
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 10:29:30 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1349778561!6297500!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24653 invoked from network); 9 Oct 2012 10:29:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 10:29:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; 
	d="asc'?scan'208";a="15033351"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 10:29:01 +0000
Received: from [IPv6:::1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	11:29:01 +0100
Message-ID: <1349778541.3610.62.camel@Abyss>
From: Dario Faggioli 
To: Jan Beulich 
Date: Tue, 9 Oct 2012 11:29:01 +0100
In-Reply-To: <506F0A1602000078000A00F4@nat28.tlf.novell.com>
References: 
	
	<506F0A1602000078000A00F4@nat28.tlf.novell.com>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
MIME-Version: 1.0
Cc: Andre Przywara ,
	Ian Campbell ,
	Marcus Granado ,
	George Dunlap ,
	Andrew Cooper ,
	Juergen Gross ,
	Anil Madhavapeddy ,
	Ian Jackson , xen-devel@lists.xen.org,
	Matt Wilson , Daniel De Graaf 
Subject: Re: [Xen-devel] [PATCH 3 of 8] xen: let the (credit) scheduler know
 about `node affinity`
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============3493500228190797503=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3493500228190797503==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-Tqz0G30cTLhy8/z7osPg"

--=-Tqz0G30cTLhy8/z7osPg
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-10-05 at 15:25 +0100, Jan Beulich wrote:=20
> >>> On 05.10.12 at 16:08, Dario Faggioli  wrot=
e:
> > @@ -287,22 +344,26 @@ static inline void
> >          }
> >          else
> >          {
> > -            cpumask_t idle_mask;
> > +            cpumask_t idle_mask, balance_mask;
>=20
> Be _very_ careful about adding on-stack CPU mask variables
> (also further below): each one of them grows the stack frame
> by 512 bytes (when building for the current maximum of 4095
> CPUs), which is generally too much; you may want to consider
> pre-allocated scratch space instead.
>=20
I see your point, and I think you're right... I wasn't "thinking that
big". :-)

I'll look into all of these situations and see if I can move the masks
off the stack. Any preference between global variables and members of
one of the scheduler's data structures?

Thanks and Regards,
Dario

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-Tqz0G30cTLhy8/z7osPg
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlBz/G0ACgkQk4XaBE3IOsRUbQCdG+9/3A4DQmUssU1RPuaOZuZA
aUgAnAx8uh7oRGVggL5/2eJzHzFpQAOJ
=9cMO
-----END PGP SIGNATURE-----

--=-Tqz0G30cTLhy8/z7osPg--


--===============3493500228190797503==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3493500228190797503==--


From xen-devel-bounces@lists.xen.org Tue Oct 09 10:30:12 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 10:30:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLX47-00014Z-HK; Tue, 09 Oct 2012 10:29:31 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLX46-00014N-6i
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 10:29:30 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1349778561!6297500!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24653 invoked from network); 9 Oct 2012 10:29:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 10:29:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; 
	d="asc'?scan'208";a="15033351"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 10:29:01 +0000
Received: from [IPv6:::1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	11:29:01 +0100
Message-ID: <1349778541.3610.62.camel@Abyss>
From: Dario Faggioli 
To: Jan Beulich 
Date: Tue, 9 Oct 2012 11:29:01 +0100
In-Reply-To: <506F0A1602000078000A00F4@nat28.tlf.novell.com>
References: 
	
	<506F0A1602000078000A00F4@nat28.tlf.novell.com>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
MIME-Version: 1.0
Cc: Andre Przywara ,
	Ian Campbell ,
	Marcus Granado ,
	George Dunlap ,
	Andrew Cooper ,
	Juergen Gross ,
	Anil Madhavapeddy ,
	Ian Jackson , xen-devel@lists.xen.org,
	Matt Wilson , Daniel De Graaf 
Subject: Re: [Xen-devel] [PATCH 3 of 8] xen: let the (credit) scheduler know
 about `node affinity`
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============3493500228190797503=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3493500228190797503==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-Tqz0G30cTLhy8/z7osPg"

--=-Tqz0G30cTLhy8/z7osPg
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-10-05 at 15:25 +0100, Jan Beulich wrote:=20
> >>> On 05.10.12 at 16:08, Dario Faggioli  wrot=
e:
> > @@ -287,22 +344,26 @@ static inline void
> >          }
> >          else
> >          {
> > -            cpumask_t idle_mask;
> > +            cpumask_t idle_mask, balance_mask;
>=20
> Be _very_ careful about adding on-stack CPU mask variables
> (also further below): each one of them grows the stack frame
> by 512 bytes (when building for the current maximum of 4095
> CPUs), which is generally too much; you may want to consider
> pre-allocated scratch space instead.
>=20
I see your point, and I think you're right... I wasn't "thinking that
big". :-)

I'll look into all of these situations and see if I can move the masks
off the stack. Any preference between global variables and members of
one of the scheduler's data structures?

Thanks and Regards,
Dario

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-Tqz0G30cTLhy8/z7osPg
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlBz/G0ACgkQk4XaBE3IOsRUbQCdG+9/3A4DQmUssU1RPuaOZuZA
aUgAnAx8uh7oRGVggL5/2eJzHzFpQAOJ
=9cMO
-----END PGP SIGNATURE-----

--=-Tqz0G30cTLhy8/z7osPg--


--===============3493500228190797503==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3493500228190797503==--


From xen-devel-bounces@lists.xen.org Tue Oct 09 10:33:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 10:33:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLX7U-0001BY-50; Tue, 09 Oct 2012 10:33:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLX7S-0001BJ-BO
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 10:32:58 +0000
Received: from [85.158.138.51:35210] by server-6.bemta-3.messagelabs.com id
	51/1F-11085-95DF3705; Tue, 09 Oct 2012 10:32:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1349778776!24777651!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6351 invoked from network); 9 Oct 2012 10:32:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 10:32:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15033457"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 10:32:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	11:32:56 +0100
Message-ID: <1349778775.21847.132.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Matthew Fioravante 
Date: Tue, 9 Oct 2012 11:32:55 +0100
In-Reply-To: <1349460132-13853-3-git-send-email-matthew.fioravante@jhuapl.edu>
References: <1349460132-13853-1-git-send-email-matthew.fioravante@jhuapl.edu>
	<1349460132-13853-3-git-send-email-matthew.fioravante@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH vtpm v2 11/12] add vtpm support to libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

IIRC you are reworking the vtpm stuff to only support the stub domaun
model and not the process model -- does this mean this patch will change
or is this already only doing stub stuff?

> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 1606eb1..17094ca 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -1726,6 +1726,246 @@ out:
>  }
> 
>  /******************************************************************************/
> +int libxl__device_vtpm_setdefault(libxl__gc *gc, libxl_device_vtpm *vtpm)
> +{
> +   if(libxl_uuid_is_nil(&vtpm->uuid)) {
> +      libxl_uuid_generate(&vtpm->uuid);
> +   }
> +   return 0;
> +}
> +
> +static int libxl__device_from_vtpm(libxl__gc *gc, uint32_t domid,
> +                                   libxl_device_vtpm *vtpm,
> +                                   libxl__device *device)
> +{
> +   device->backend_devid   = vtpm->devid;
> +   device->backend_domid   = vtpm->backend_domid;
> +   device->backend_kind    = LIBXL__DEVICE_KIND_VTPM;
> +   device->devid           = vtpm->devid;
> +   device->domid           = domid;
> +   device->kind            = LIBXL__DEVICE_KIND_VTPM;
> +
> +   return 0;
> +}
> +
> +void libxl__device_vtpm_add(libxl__egc *egc, uint32_t domid,
> +                           libxl_device_vtpm *vtpm,
> +                           libxl__ao_device *aodev)
> +{
> +    STATE_AO_GC(aodev->ao);
> +    flexarray_t *front;
> +    flexarray_t *back;
> +    libxl__device *device;
> +    char *dompath, **l;
> +    unsigned int nb, rc;
> +
> +    rc = libxl__device_vtpm_setdefault(gc, vtpm);
> +    if (rc) goto out;
> +
> +    front = flexarray_make(16, 1);

Sorry but in the meantime the flexarray interface has changed, it now
accepts a gc -- see commit 25991:5c6b72b62bd7.


> +    if (!front) {
> +        rc = ERROR_NOMEM;
> +        goto out;
> +    }
> +    back = flexarray_make(16, 1);
> +    if (!back) {
> +        rc = ERROR_NOMEM;
> +        goto out;
> +    }
> +
> +    if(vtpm->devid == -1) {
> +        if (!(dompath = libxl__xs_get_dompath(gc, domid))) {
> +            rc = ERROR_FAIL;
> +            goto out_free;
> +        }
> +        l = libxl__xs_directory(gc, XBT_NULL, libxl__sprintf(gc, "%s/device/vtpm", dompath), &nb);

You have some very long lines in this patch. Can you try and keep it to
75-80 characters please.

There are various helper macros like GCSPRINTF which can help to reduce
the length of lines. Also you might find the LOG* macros useful instead
of the more verbose LIBXL__LOG*.

[...]

> +    flexarray_append(back, "instance"); /* MAYBE CAN GET RID OF THIS */
> +    flexarray_append(back, "0");
> +    flexarray_append(back, "pref_instance"); /* MAYBE CAN GET RID OF THIS */
> +    flexarray_append(back, "0");
> +    flexarray_append(back, "resume");
> +    flexarray_append(back, "False");
> +    flexarray_append(back, "ready"); /* MAYBE CAN GET RID OF THIS */
> +    flexarray_append(back, "1");

Can we decide now or is this a future work thing?

Not a lot of existing code uses it but we have flexarray_append_pair
which can clarify the pairing of keys and values if you would like to
use it.

> +static void libxl__device_vtpm_from_xs_fe(libxl__gc *gc,
> +                                          const char* fe_path,
> +                                          libxl_device_vtpm *vtpm)
> 

Other devices have from_xs_be not fe. This is because we "trust" the be
to be less malicious.

> +{
> [...]
> +   tmp = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/uuid", fe_path));
> +   if(tmp) {
> +      libxl_uuid_from_string(&(vtpm->uuid), tmp);
> +   }
> +}
> [...]
> +int libxl_device_vtpm_getinfo(libxl_ctx *ctx, uint32_t domid,
> +                               libxl_device_vtpm *vtpm, libxl_vtpminfo *vtpminfo)
> +{
> [...]
> +    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/uuid", vtpminfo->backend));
> +    if(val == NULL) {
> +       LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s/uuid does not exist!\n", vtpminfo->backend);
> +       goto err;
> +    }
> +    if(libxl_uuid_from_string(&(vtpminfo->uuid), val)) {
> +       LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s/uuid is a malformed uuid?? (%s) Probably a bug!\n", vtpminfo->backend, val);
> +       goto err;

This is fatal here but not in from_xs_fe?

> +static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multidev *multidev, int ret) {

brace on next line please.

> +   libxl__domain_create_state *dcs = CONTAINER_OF(multidev, *dcs, multidev);
> +   STATE_AO_GC(dcs->ao);
> +   int domid = dcs->guest_domid;
> +
> +   libxl_domain_config* const d_config = dcs->guest_config;
> +
> +   if(ret) {
> +      LOG(ERROR, "unable to add nic devices");
> +      goto error_out;
> +   }

Four space indents above please.

> +    /* Plug vtpm devices */
> +    if (d_config->num_vtpms > 0) {
> +        /* Attach vtpms */
> +        libxl__multidev_begin(ao, &dcs->multidev);
> +        dcs->multidev.callback = domcreate_attach_pci;
> +        libxl__add_vtpms(egc, ao, domid, d_config, &dcs->multidev);
> +        libxl__multidev_prepared(egc, &dcs->multidev, 0);
> +        return;
> +    }

This indent is ok.

> +
> +   domcreate_attach_pci(egc, multidev, 0);
> +   return;
> +
> +error_out:
> +   assert(ret);
> +   domcreate_complete(egc, dcs, ret);

But here we've gone back to 3 spaces again.

> diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
> index 55cd299..73a158a 100644
> --- a/tools/libxl/libxl_utils.c
> +++ b/tools/libxl/libxl_utils.c
> @@ -463,6 +463,35 @@ int libxl_pipe(libxl_ctx *ctx, int pipes[2])
>      return 0;
>  }
> 
> +int libxl_uuid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid,
> +                            libxl_uuid* uuid, libxl_device_vtpm *vtpm)
> +{
> +    libxl_device_vtpm *vtpms;
> +    int nb, i;
> +    int rc;
> +
> +    vtpms = libxl_device_vtpm_list(ctx, domid, &nb);
> +    if (!vtpms)
> +        return ERROR_FAIL;
> +
> +    memset(vtpm, 0, sizeof (libxl_device_vtpm));
> +    rc = 1;
> +    for (i = 0; i < nb; ++i) {
> +        if(!libxl_uuid_compare(uuid, &vtpms[i].uuid)) {
> +            vtpm->backend_domid = vtpms[i].backend_domid;
> +            vtpm->devid = vtpms[i].devid;
> +            libxl_uuid_copy(&vtpm->uuid, &vtpms[i].uuid);
> +            rc = 0;
> +            break;
> +        }
> +    }
> +
> +    for (i=0; i +        libxl_device_vtpm_dispose(&vtpms[i]);
> +    free(vtpms);

I think I saw this a few times (probably copied from elsewhere) but the
modern alternative is to define libxl_THING_list_free and use that to
free the result of libxl_THING_list.

We just didn't go back and change all the existing instances when we did
this.


> diff --git a/tools/libxl/xl_cmdtable.c b/tools/libxl/xl_cmdtable.c
> index 85ea768..7c018eb 100644
> --- a/tools/libxl/xl_cmdtable.c
> +++ b/tools/libxl/xl_cmdtable.c
> @@ -338,6 +338,21 @@ struct cmd_spec cmd_table[] = {
>        "Destroy a domain's virtual block device",
>        " ",
>      },
> +    { "vtpm-attach",
> +      &main_vtpmattach, 0, 1,
> +      "Create a new virtual TPM device",
> +      " [uuid=] [backend=]",
> +    },
> +    { "vtpm-list",
> +      &main_vtpmlist, 0, 0,

I think you want the first 0 to be 1 since you do support dry run in
this command

> +      "List virtual TPM devices for a domain",
> +      "",
> +    },
> +    { "vtpm-detach",
> +      &main_vtpmdetach, 0, 1,
> +      "Destroy a domain's virtual TPM device",
> +      " ",
> +    },
>      { "uptime",
>        &main_uptime, 0, 0,
>        "Print uptime for all/some domains",
> --
> 1.7.4.4
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 10:33:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 10:33:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLX7U-0001BY-50; Tue, 09 Oct 2012 10:33:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLX7S-0001BJ-BO
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 10:32:58 +0000
Received: from [85.158.138.51:35210] by server-6.bemta-3.messagelabs.com id
	51/1F-11085-95DF3705; Tue, 09 Oct 2012 10:32:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1349778776!24777651!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6351 invoked from network); 9 Oct 2012 10:32:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 10:32:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15033457"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 10:32:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	11:32:56 +0100
Message-ID: <1349778775.21847.132.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Matthew Fioravante 
Date: Tue, 9 Oct 2012 11:32:55 +0100
In-Reply-To: <1349460132-13853-3-git-send-email-matthew.fioravante@jhuapl.edu>
References: <1349460132-13853-1-git-send-email-matthew.fioravante@jhuapl.edu>
	<1349460132-13853-3-git-send-email-matthew.fioravante@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH vtpm v2 11/12] add vtpm support to libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

IIRC you are reworking the vtpm stuff to only support the stub domaun
model and not the process model -- does this mean this patch will change
or is this already only doing stub stuff?

> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 1606eb1..17094ca 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -1726,6 +1726,246 @@ out:
>  }
> 
>  /******************************************************************************/
> +int libxl__device_vtpm_setdefault(libxl__gc *gc, libxl_device_vtpm *vtpm)
> +{
> +   if(libxl_uuid_is_nil(&vtpm->uuid)) {
> +      libxl_uuid_generate(&vtpm->uuid);
> +   }
> +   return 0;
> +}
> +
> +static int libxl__device_from_vtpm(libxl__gc *gc, uint32_t domid,
> +                                   libxl_device_vtpm *vtpm,
> +                                   libxl__device *device)
> +{
> +   device->backend_devid   = vtpm->devid;
> +   device->backend_domid   = vtpm->backend_domid;
> +   device->backend_kind    = LIBXL__DEVICE_KIND_VTPM;
> +   device->devid           = vtpm->devid;
> +   device->domid           = domid;
> +   device->kind            = LIBXL__DEVICE_KIND_VTPM;
> +
> +   return 0;
> +}
> +
> +void libxl__device_vtpm_add(libxl__egc *egc, uint32_t domid,
> +                           libxl_device_vtpm *vtpm,
> +                           libxl__ao_device *aodev)
> +{
> +    STATE_AO_GC(aodev->ao);
> +    flexarray_t *front;
> +    flexarray_t *back;
> +    libxl__device *device;
> +    char *dompath, **l;
> +    unsigned int nb, rc;
> +
> +    rc = libxl__device_vtpm_setdefault(gc, vtpm);
> +    if (rc) goto out;
> +
> +    front = flexarray_make(16, 1);

Sorry but in the meantime the flexarray interface has changed, it now
accepts a gc -- see commit 25991:5c6b72b62bd7.


> +    if (!front) {
> +        rc = ERROR_NOMEM;
> +        goto out;
> +    }
> +    back = flexarray_make(16, 1);
> +    if (!back) {
> +        rc = ERROR_NOMEM;
> +        goto out;
> +    }
> +
> +    if(vtpm->devid == -1) {
> +        if (!(dompath = libxl__xs_get_dompath(gc, domid))) {
> +            rc = ERROR_FAIL;
> +            goto out_free;
> +        }
> +        l = libxl__xs_directory(gc, XBT_NULL, libxl__sprintf(gc, "%s/device/vtpm", dompath), &nb);

You have some very long lines in this patch. Can you try and keep it to
75-80 characters please.

There are various helper macros like GCSPRINTF which can help to reduce
the length of lines. Also you might find the LOG* macros useful instead
of the more verbose LIBXL__LOG*.

[...]

> +    flexarray_append(back, "instance"); /* MAYBE CAN GET RID OF THIS */
> +    flexarray_append(back, "0");
> +    flexarray_append(back, "pref_instance"); /* MAYBE CAN GET RID OF THIS */
> +    flexarray_append(back, "0");
> +    flexarray_append(back, "resume");
> +    flexarray_append(back, "False");
> +    flexarray_append(back, "ready"); /* MAYBE CAN GET RID OF THIS */
> +    flexarray_append(back, "1");

Can we decide now or is this a future work thing?

Not a lot of existing code uses it but we have flexarray_append_pair
which can clarify the pairing of keys and values if you would like to
use it.

> +static void libxl__device_vtpm_from_xs_fe(libxl__gc *gc,
> +                                          const char* fe_path,
> +                                          libxl_device_vtpm *vtpm)
> 

Other devices have from_xs_be not fe. This is because we "trust" the be
to be less malicious.

> +{
> [...]
> +   tmp = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/uuid", fe_path));
> +   if(tmp) {
> +      libxl_uuid_from_string(&(vtpm->uuid), tmp);
> +   }
> +}
> [...]
> +int libxl_device_vtpm_getinfo(libxl_ctx *ctx, uint32_t domid,
> +                               libxl_device_vtpm *vtpm, libxl_vtpminfo *vtpminfo)
> +{
> [...]
> +    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/uuid", vtpminfo->backend));
> +    if(val == NULL) {
> +       LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s/uuid does not exist!\n", vtpminfo->backend);
> +       goto err;
> +    }
> +    if(libxl_uuid_from_string(&(vtpminfo->uuid), val)) {
> +       LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s/uuid is a malformed uuid?? (%s) Probably a bug!\n", vtpminfo->backend, val);
> +       goto err;

This is fatal here but not in from_xs_fe?

> +static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multidev *multidev, int ret) {

brace on next line please.

> +   libxl__domain_create_state *dcs = CONTAINER_OF(multidev, *dcs, multidev);
> +   STATE_AO_GC(dcs->ao);
> +   int domid = dcs->guest_domid;
> +
> +   libxl_domain_config* const d_config = dcs->guest_config;
> +
> +   if(ret) {
> +      LOG(ERROR, "unable to add nic devices");
> +      goto error_out;
> +   }

Four space indents above please.

> +    /* Plug vtpm devices */
> +    if (d_config->num_vtpms > 0) {
> +        /* Attach vtpms */
> +        libxl__multidev_begin(ao, &dcs->multidev);
> +        dcs->multidev.callback = domcreate_attach_pci;
> +        libxl__add_vtpms(egc, ao, domid, d_config, &dcs->multidev);
> +        libxl__multidev_prepared(egc, &dcs->multidev, 0);
> +        return;
> +    }

This indent is ok.

> +
> +   domcreate_attach_pci(egc, multidev, 0);
> +   return;
> +
> +error_out:
> +   assert(ret);
> +   domcreate_complete(egc, dcs, ret);

But here we've gone back to 3 spaces again.

> diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
> index 55cd299..73a158a 100644
> --- a/tools/libxl/libxl_utils.c
> +++ b/tools/libxl/libxl_utils.c
> @@ -463,6 +463,35 @@ int libxl_pipe(libxl_ctx *ctx, int pipes[2])
>      return 0;
>  }
> 
> +int libxl_uuid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid,
> +                            libxl_uuid* uuid, libxl_device_vtpm *vtpm)
> +{
> +    libxl_device_vtpm *vtpms;
> +    int nb, i;
> +    int rc;
> +
> +    vtpms = libxl_device_vtpm_list(ctx, domid, &nb);
> +    if (!vtpms)
> +        return ERROR_FAIL;
> +
> +    memset(vtpm, 0, sizeof (libxl_device_vtpm));
> +    rc = 1;
> +    for (i = 0; i < nb; ++i) {
> +        if(!libxl_uuid_compare(uuid, &vtpms[i].uuid)) {
> +            vtpm->backend_domid = vtpms[i].backend_domid;
> +            vtpm->devid = vtpms[i].devid;
> +            libxl_uuid_copy(&vtpm->uuid, &vtpms[i].uuid);
> +            rc = 0;
> +            break;
> +        }
> +    }
> +
> +    for (i=0; i +        libxl_device_vtpm_dispose(&vtpms[i]);
> +    free(vtpms);

I think I saw this a few times (probably copied from elsewhere) but the
modern alternative is to define libxl_THING_list_free and use that to
free the result of libxl_THING_list.

We just didn't go back and change all the existing instances when we did
this.


> diff --git a/tools/libxl/xl_cmdtable.c b/tools/libxl/xl_cmdtable.c
> index 85ea768..7c018eb 100644
> --- a/tools/libxl/xl_cmdtable.c
> +++ b/tools/libxl/xl_cmdtable.c
> @@ -338,6 +338,21 @@ struct cmd_spec cmd_table[] = {
>        "Destroy a domain's virtual block device",
>        " ",
>      },
> +    { "vtpm-attach",
> +      &main_vtpmattach, 0, 1,
> +      "Create a new virtual TPM device",
> +      " [uuid=] [backend=]",
> +    },
> +    { "vtpm-list",
> +      &main_vtpmlist, 0, 0,

I think you want the first 0 to be 1 since you do support dry run in
this command

> +      "List virtual TPM devices for a domain",
> +      "",
> +    },
> +    { "vtpm-detach",
> +      &main_vtpmdetach, 0, 1,
> +      "Destroy a domain's virtual TPM device",
> +      " ",
> +    },
>      { "uptime",
>        &main_uptime, 0, 0,
>        "Print uptime for all/some domains",
> --
> 1.7.4.4
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 10:35:26 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 10:35:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLX9H-0001Ie-Ld; Tue, 09 Oct 2012 10:34:51 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLX9G-0001IT-3I
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 10:34:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1349778883!2143604!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18597 invoked from network); 9 Oct 2012 10:34:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 10:34:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15033498"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 10:34:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	11:34:44 +0100
Message-ID: <1349778882.21847.135.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Anthony PERARD 
Date: Tue, 9 Oct 2012 11:34:42 +0100
In-Reply-To: <1349722522-25748-1-git-send-email-anthony.perard@citrix.com>
References: <1349722522-25748-1-git-send-email-anthony.perard@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson ,
	Xen Devel 
Subject: Re: [Xen-devel] [PATCH V2 0/3] libxl cd-insert/eject with qemu-xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-10-08 at 19:55 +0100, Anthony PERARD wrote:
> This patch series provides the facility to eject and insert a cdrom when the
> used device-model is qemu-xen. The only difference between both device-model is
> a call to a QMP command as `xl cd-insert ...` will still update xenstore, even
> if it's not used by QEMU.

All: 
Acked-by: Ian Campbell 

And applied.

> 
> 
> Change since v1:
>   - Update first patch to use new facilities introduce by my previous applied series.
>   - Use the disk dev number instead of the vdev string as on id for the cdrom.
> 
> 
> Anthony PERARD (3):
>   libxl_qmp, Introduce libxl__qmp_insert_cdrom.
>   libxl_dm: Set an id to cdrom drives with qemuu.
>   libxl: Fix cd-insert with qemu-xen.
> 
>  tools/libxl/libxl.c          | 12 ++++++------
>  tools/libxl/libxl_dm.c       |  7 ++++---
>  tools/libxl/libxl_internal.h |  1 +
>  tools/libxl/libxl_qmp.c      | 16 ++++++++++++++++
>  4 files changed, 27 insertions(+), 9 deletions(-)
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 10:35:26 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 10:35:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLX9H-0001Ie-Ld; Tue, 09 Oct 2012 10:34:51 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLX9G-0001IT-3I
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 10:34:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1349778883!2143604!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18597 invoked from network); 9 Oct 2012 10:34:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 10:34:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15033498"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 10:34:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	11:34:44 +0100
Message-ID: <1349778882.21847.135.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Anthony PERARD 
Date: Tue, 9 Oct 2012 11:34:42 +0100
In-Reply-To: <1349722522-25748-1-git-send-email-anthony.perard@citrix.com>
References: <1349722522-25748-1-git-send-email-anthony.perard@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson ,
	Xen Devel 
Subject: Re: [Xen-devel] [PATCH V2 0/3] libxl cd-insert/eject with qemu-xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-10-08 at 19:55 +0100, Anthony PERARD wrote:
> This patch series provides the facility to eject and insert a cdrom when the
> used device-model is qemu-xen. The only difference between both device-model is
> a call to a QMP command as `xl cd-insert ...` will still update xenstore, even
> if it's not used by QEMU.

All: 
Acked-by: Ian Campbell 

And applied.

> 
> 
> Change since v1:
>   - Update first patch to use new facilities introduce by my previous applied series.
>   - Use the disk dev number instead of the vdev string as on id for the cdrom.
> 
> 
> Anthony PERARD (3):
>   libxl_qmp, Introduce libxl__qmp_insert_cdrom.
>   libxl_dm: Set an id to cdrom drives with qemuu.
>   libxl: Fix cd-insert with qemu-xen.
> 
>  tools/libxl/libxl.c          | 12 ++++++------
>  tools/libxl/libxl_dm.c       |  7 ++++---
>  tools/libxl/libxl_internal.h |  1 +
>  tools/libxl/libxl_qmp.c      | 16 ++++++++++++++++
>  4 files changed, 27 insertions(+), 9 deletions(-)
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 10:46:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 10:46:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLXK0-0001WG-4X; Tue, 09 Oct 2012 10:45:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLXJy-0001WB-8b
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 10:45:54 +0000
Received: from [85.158.138.51:7515] by server-7.bemta-3.messagelabs.com id
	90/B8-15765-F5004705; Tue, 09 Oct 2012 10:45:51 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1349779550!14964423!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13802 invoked from network); 9 Oct 2012 10:45:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 10:45:50 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; 
	d="asc'?scan'208";a="15033739"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 10:45:50 +0000
Received: from [IPv6:::1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	11:45:50 +0100
Message-ID: <1349779549.3610.79.camel@Abyss>
From: Dario Faggioli 
To: Dan Magenheimer 
Date: Tue, 9 Oct 2012 11:45:49 +0100
In-Reply-To: 
References: 
	
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
MIME-Version: 1.0
Cc: Marcus Granado ,
	Andre Przywara ,
	Ian Campbell ,
	Anil Madhavapeddy , George
	Dunlap ,
	Andrew Cooper ,
	Juergen Gross ,
	Ian Jackson , xen-devel@lists.xen.org,
	Jan Beulich , Daniel De Graaf ,
	Matt Wilson 
Subject: Re: [Xen-devel] [PATCH 0 of 8] NUMA Awareness for the Credit
 Scheduler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============6474399870298097468=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6474399870298097468==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-w+aA4+pB88wxPdPKsjx3"

--=-w+aA4+pB88wxPdPKsjx3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2012-10-08 at 12:43 -0700, Dan Magenheimer wrote:=20
> Just wondering... is the NUMA information preserved on live migration?
> I'm not saying that it necessarily should, but it may just work
> due to the implementation (since migration is a form of domain creation).
>
What could I say... yes, but "preserved" is not the right word. :-)

In fact, something happens when you migrate a VM. As you said, migration
is a special case of domain creation, so the placement algorithm will
trigger as a part of the process of creating the target VM (unless you
override the relevant options in the config file during migration
itself). That means the target VM will be placed on one (some) node(s)
of the target host, and it's node-affinity will be set accordingly.

_However_, there is right now no guarantee for the final decision from
the placing algorithm on the target machine to be "compatible" with the
one made on the source machine at initial VM creation time. For
instance, if your VM fits in just one node and is placed there on
machine A, it well could end up being split on two or more nodes when
migrated on machine B (and, of course, the vice versa).

Whether, that is acceptable or not, is of course debatable, and we had a
bit of this discussion already (although no real conclusion has been
reached yet).
My take is that, right now, since we do not yet expose any virtual NUMA
topology to the VM itself, the behaviour described above is fine. As
soon as we'll have some guest NUMA awareness, than it might be
worthwhile to try to preserve it, at least to some extent.

Oh, and BTW, I'm of course talking about migration with xl and libxl. If
you use other toolstacks, then the hypervisor will default to his
current (_without_ this series) behaviour, and it all will depend on who
and when calls xc_domain_node_setaffinity() or, perhaps,
XEN_DOMCTL_setnodeaffinity directly.

> In either case, it might be good to comment about live migration
> on your wiki.
>=20
That is definitely a good point, I will put something there about
migration and the behaviour described above.

Thanks and Regards,
Dario

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-w+aA4+pB88wxPdPKsjx3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlB0AF0ACgkQk4XaBE3IOsQccwCeNYFklEwDYJzDOLh+qPLqOMge
f7MAoJSguSDFpKUDce3ddERuWPfkRqVX
=pacC
-----END PGP SIGNATURE-----

--=-w+aA4+pB88wxPdPKsjx3--


--===============6474399870298097468==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6474399870298097468==--


From xen-devel-bounces@lists.xen.org Tue Oct 09 10:46:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 10:46:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLXK0-0001WG-4X; Tue, 09 Oct 2012 10:45:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLXJy-0001WB-8b
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 10:45:54 +0000
Received: from [85.158.138.51:7515] by server-7.bemta-3.messagelabs.com id
	90/B8-15765-F5004705; Tue, 09 Oct 2012 10:45:51 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1349779550!14964423!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13802 invoked from network); 9 Oct 2012 10:45:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 10:45:50 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; 
	d="asc'?scan'208";a="15033739"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 10:45:50 +0000
Received: from [IPv6:::1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	11:45:50 +0100
Message-ID: <1349779549.3610.79.camel@Abyss>
From: Dario Faggioli 
To: Dan Magenheimer 
Date: Tue, 9 Oct 2012 11:45:49 +0100
In-Reply-To: 
References: 
	
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
MIME-Version: 1.0
Cc: Marcus Granado ,
	Andre Przywara ,
	Ian Campbell ,
	Anil Madhavapeddy , George
	Dunlap ,
	Andrew Cooper ,
	Juergen Gross ,
	Ian Jackson , xen-devel@lists.xen.org,
	Jan Beulich , Daniel De Graaf ,
	Matt Wilson 
Subject: Re: [Xen-devel] [PATCH 0 of 8] NUMA Awareness for the Credit
 Scheduler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============6474399870298097468=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6474399870298097468==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-w+aA4+pB88wxPdPKsjx3"

--=-w+aA4+pB88wxPdPKsjx3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2012-10-08 at 12:43 -0700, Dan Magenheimer wrote:=20
> Just wondering... is the NUMA information preserved on live migration?
> I'm not saying that it necessarily should, but it may just work
> due to the implementation (since migration is a form of domain creation).
>
What could I say... yes, but "preserved" is not the right word. :-)

In fact, something happens when you migrate a VM. As you said, migration
is a special case of domain creation, so the placement algorithm will
trigger as a part of the process of creating the target VM (unless you
override the relevant options in the config file during migration
itself). That means the target VM will be placed on one (some) node(s)
of the target host, and it's node-affinity will be set accordingly.

_However_, there is right now no guarantee for the final decision from
the placing algorithm on the target machine to be "compatible" with the
one made on the source machine at initial VM creation time. For
instance, if your VM fits in just one node and is placed there on
machine A, it well could end up being split on two or more nodes when
migrated on machine B (and, of course, the vice versa).

Whether, that is acceptable or not, is of course debatable, and we had a
bit of this discussion already (although no real conclusion has been
reached yet).
My take is that, right now, since we do not yet expose any virtual NUMA
topology to the VM itself, the behaviour described above is fine. As
soon as we'll have some guest NUMA awareness, than it might be
worthwhile to try to preserve it, at least to some extent.

Oh, and BTW, I'm of course talking about migration with xl and libxl. If
you use other toolstacks, then the hypervisor will default to his
current (_without_ this series) behaviour, and it all will depend on who
and when calls xc_domain_node_setaffinity() or, perhaps,
XEN_DOMCTL_setnodeaffinity directly.

> In either case, it might be good to comment about live migration
> on your wiki.
>=20
That is definitely a good point, I will put something there about
migration and the behaviour described above.

Thanks and Regards,
Dario

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-w+aA4+pB88wxPdPKsjx3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlB0AF0ACgkQk4XaBE3IOsQccwCeNYFklEwDYJzDOLh+qPLqOMge
f7MAoJSguSDFpKUDce3ddERuWPfkRqVX
=pacC
-----END PGP SIGNATURE-----

--=-w+aA4+pB88wxPdPKsjx3--


--===============6474399870298097468==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6474399870298097468==--


From xen-devel-bounces@lists.xen.org Tue Oct 09 10:55:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 10:55:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLXT2-0001fR-5w; Tue, 09 Oct 2012 10:55:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLXT0-0001fM-TS
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 10:55:15 +0000
Received: from [85.158.137.99:14227] by server-12.bemta-3.messagelabs.com id
	8C/3B-23730-29204705; Tue, 09 Oct 2012 10:55:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1349780113!15495969!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24751 invoked from network); 9 Oct 2012 10:55:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 10:55:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15033956"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 10:55:12 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	11:55:12 +0100
Message-ID: <1349780111.21847.146.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Tue, 9 Oct 2012 11:55:11 +0100
In-Reply-To: 
References: <1343057360.5797.59.camel@zakaz.uk.xensource.com>
	<1343057475-9258-2-git-send-email-ian.campbell@citrix.com>
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" , David Vrabel ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH V2 2/3] libxc: add ARM support to xc_dom (PV
 domain building)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-07-26 at 17:30 +0100, Stefano Stabellini wrote:
> On Mon, 23 Jul 2012, Ian Campbell wrote:
> > Includes ARM zImage support.
> >
> > Signed-off-by: Ian Campbell 
> > ---
> > v2:
> >  - add comments for rambase_pfn and p2m_host to clarify usage
> >  - remove opencoded guest base address of 0x80000000 (still hardcoded, but now
> >    with a comment!).
> >  - comments around Linux boot protocol setup.
> 
> It looks better now.
> I think we should take it as is, and then replace ntohl with
> be32_to_cpu when we have it.

Can I take that as an Ack of the reposted version in
<1349433507-21148-2-git-send-email-ian.campbell@citrix.com> 
?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 10:55:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 10:55:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLXT2-0001fR-5w; Tue, 09 Oct 2012 10:55:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLXT0-0001fM-TS
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 10:55:15 +0000
Received: from [85.158.137.99:14227] by server-12.bemta-3.messagelabs.com id
	8C/3B-23730-29204705; Tue, 09 Oct 2012 10:55:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1349780113!15495969!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24751 invoked from network); 9 Oct 2012 10:55:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 10:55:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15033956"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 10:55:12 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	11:55:12 +0100
Message-ID: <1349780111.21847.146.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Tue, 9 Oct 2012 11:55:11 +0100
In-Reply-To: 
References: <1343057360.5797.59.camel@zakaz.uk.xensource.com>
	<1343057475-9258-2-git-send-email-ian.campbell@citrix.com>
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" , David Vrabel ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH V2 2/3] libxc: add ARM support to xc_dom (PV
 domain building)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-07-26 at 17:30 +0100, Stefano Stabellini wrote:
> On Mon, 23 Jul 2012, Ian Campbell wrote:
> > Includes ARM zImage support.
> >
> > Signed-off-by: Ian Campbell 
> > ---
> > v2:
> >  - add comments for rambase_pfn and p2m_host to clarify usage
> >  - remove opencoded guest base address of 0x80000000 (still hardcoded, but now
> >    with a comment!).
> >  - comments around Linux boot protocol setup.
> 
> It looks better now.
> I think we should take it as is, and then replace ntohl with
> be32_to_cpu when we have it.

Can I take that as an Ack of the reposted version in
<1349433507-21148-2-git-send-email-ian.campbell@citrix.com> 
?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 11:08:22 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 11:08:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLXf7-0001tK-Je; Tue, 09 Oct 2012 11:07:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLXf5-0001tF-UC
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 11:07:44 +0000
Received: from [85.158.143.35:56154] by server-2.bemta-4.messagelabs.com id
	EB/90-06610-F7504705; Tue, 09 Oct 2012 11:07:43 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-10.tower-21.messagelabs.com!1349780860!10727386!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17219 invoked from network); 9 Oct 2012 11:07:40 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-10.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	9 Oct 2012 11:07:40 -0000
Received: from 50-66-ftth.onsneteindhoven.nl ([88.159.66.50]:55334
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TLXgI-0003oo-O1; Tue, 09 Oct 2012 13:08:58 +0200
Date: Tue, 9 Oct 2012 13:07:33 +0200
From: Sander Eikelenboom 
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1305237695.20121009130733@eikelenboom.it>
To: Ian Campbell 
In-Reply-To: <1349774588.21847.105.camel@zakaz.uk.xensource.com>
References: 
	<729626082.20121006002054@eikelenboom.it>
	<20121007233444.GA26929@localhost.localdomain>
	<1349686461.18008.18.camel@zakaz.uk.xensource.com>
	<120335733.20121009042424@eikelenboom.it>
	<1349774588.21847.105.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk ,
	"xen-devel@lists.xensource.com" ,
	konrad 
Subject: Re: [Xen-devel] Kernel 3.7.0-pre-rc1 kernel BUG at
	drivers/net/xen-netback/netback.c:405 RIP:
	e030:[] []
	netbk_gop_frag_copy+0x379/0x380
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Tuesday, October 9, 2012, 11:23:08 AM, you wrote:

> On Tue, 2012-10-09 at 03:24 +0100, Sander Eikelenboom wrote:

>> >> Looking at the code, this is what we get:
>> >>
>> >>         /* Data must not cross a page boundary. */
>> >>         BUG_ON(size + offset > PAGE_SIZE);
>> >>[...]
>> After applying the debug patch:
>> 
>> [  197.876304] netbk_gop_frag_copy failed: skb frag 0 page
>> [  197.884299] copying from offset 0, len 1628

> WTF! This turns into BUG_ON(0 + 1628 > PAGE_SIZE) (where PAGE_SIZE is
> 4096) which simply should not be triggering.

> Perhaps I screwed up the debugging patch... investigates... no I don't
> think so, but someone should definitely check my working.

> For belt and braces can you change, in netbk_gop_frag_copy:
>         /* Data must not cross a page boundary. */
>         if (size + offset > PAGE_SIZE)
>                 return -1;
> into:
>         /* Data must not cross a page boundary. */
>         if (size + offset > PAGE_SIZE) {
>                 printk(KERN_CRIT "netbk_gop_frag_copy: size %lx offset %lx\n => %lx > %lx\n",
>                        size, offset, size + offset, PAGE_SIZE);
>                 return -1;
>         }

Done:

[  199.342570] netbk_gop_frag_copy: size 5a8 offset 7102
[  199.342570]  => 76aa > 1000
[  199.354626] netbk_gop_frag_copy failed: skb frag 0 page
[  199.360930] copying from offset 7102, len 5a8
[  199.366887] page:ffffea0000b0aa00 count:3 mapcount:0 mapping:          (null) index:0x7f40fec00
[  199.373008] page flags: 0x40000000004000(head)
[  199.379252] ------------[ cut here ]------------
[  199.385247] kernel BUG at drivers/net/xen-netback/netback.c:548!
[  199.391334] invalid opcode: 0000 [#1] PREEMPT SMP 
[  199.397446] Modules linked in:
[  199.403450] CPU 4 
[  199.403500] Pid: 1183, comm: netback/4 Not tainted 3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)  
[  199.415401] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
[  199.421690] RSP: e02b:ffff88003792bc20  EFLAGS: 00010282
[  199.428048] RAX: 0000000000000001 RBX: ffff88003197c600 RCX: 0000000000000000
[  199.434358] RDX: 0000000000000001 RSI: 0000000000000001 RDI: ffff8800379202b0
[  199.440582] RBP: ffff88003792bd50 R08: 0000000000000002 R09: 0000000000000000
[  199.446740] R10: 0000000000000001 R11: ffff88003a26c000 R12: 0000000000000030
[  199.452965] R13: 0000000000000000 R14: ffff88002c2ae900 R15: 0000000000000001
[  199.459203] FS:  00007fcec7740700(0000) GS:ffff88003f900000(0000) knlGS:0000000000000000
[  199.465527] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[  199.471735] CR2: 00007fff5f59c000 CR3: 0000000001c0b000 CR4: 0000000000000660
[  199.477961] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  199.484102] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  199.490274] Process netback/4 (pid: 1183, threadinfo ffff88003792a000, task ffff880037cec140)
[  199.496631] Stack:
[  199.502834]  ffff88003792bd1c ffff880037cec7f0 ffff88003792bd00 ffff88003792bc80
[  199.509198]  ffffffff00000001 00000000000005ea ffffc90010851a98 ffffc9001084cf30
[  199.515579]  0000000001080083 ffffc9001084cee0 0000000000000000 ffff880032b449c0
[  199.521944] Call Trace:
[  199.528243]  [] ? trace_hardirqs_on+0xd/0x10
[  199.534566]  [] xen_netbk_kthread+0xba/0xa90
[  199.540826]  [] ? try_to_wake_up+0x1b6/0x310
[  199.547193]  [] ? wake_up_bit+0x40/0x40
[  199.553450]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
[  199.559683]  [] kthread+0xd6/0xe0
[  199.565827]  [] kernel_thread_helper+0x4/0x10
[  199.572086]  [] ? retint_restore_args+0x13/0x13
[  199.578268]  [] ? gs_change+0x13/0x13
[  199.584344] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 36 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7 
[  199.597406] RIP  [] xen_netbk_rx_action+0x89a/0x910
[  199.604013]  RSP 
[  199.610610] ---[ end trace 03f82ac72747fb5a ]---
[  199.990340] device vif11.0 entered promiscuous mode
[  200.466710] xen-blkback:ring-ref 9, event-channel 10, protocol 1 (x86_64-abi)
[  200.476634] xen_bridge: port 11(vif11.0) entered forwarding state
[  200.483621] xen_bridge: port 11(vif11.0) entered forwarding state
[  200.653782] pciback 0000:03:06.0: enabling device (0000 -> 0001)
[  200.661499] xen: registering gsi 22 triggering 0 polarity 1
[  200.669003] Already setup the GSI :22
[  200.677345] pciback 0000:03:06.0: enabling bus mastering
[  201.267297] xen_bridge: port 9(vif9.0) entered forwarding state
[  205.151290] tty_init_dev: 2 callbacks suppressed
[  206.534137] device vif12.0 entered promiscuous mode
[  206.867366] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
[  206.877552] xen_bridge: port 12(vif12.0) entered forwarding state
[  206.884869] xen_bridge: port 12(vif12.0) entered forwarding state
[  208.574036] xen_bridge: port 10(vif10.0) entered forwarding state
[  209.979799] netbk_gop_frag_copy: size 1080 offset 0
[  209.979799]  => 1080 > 1000
[  209.994252] netbk_gop_frag_copy failed: skb frag 0 page
[  210.001191] copying from offset 0, len 1080
[  210.008121] page:ffffea0000b0a800 count:3 mapcount:0 mapping:          (null) index:0x7f40fec00
[  210.015124] page flags: 0x40000000004000(head)
[  210.022122] ------------[ cut here ]------------
[  210.029035] kernel BUG at drivers/net/xen-netback/netback.c:548!
[  210.035973] invalid opcode: 0000 [#2] PREEMPT SMP 
[  210.042819] Modules linked in:
[  210.049467] CPU 0 
[  210.049518] Pid: 1179, comm: netback/0 Tainted: G      D      3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)  
[  210.062788] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
[  210.069740] RSP: e02b:ffff880037923c20  EFLAGS: 00010282
[  210.076711] RAX: 0000000000000001 RBX: ffff880031993ae0 RCX: 0000000000000000
[  210.083744] RDX: ffff8800398a61e0 RSI: 0000000000000001 RDI: ffff8800379202b0
[  210.090801] RBP: ffff880037923d50 R08: 0000000000000002 R09: 0000000000000000
[  210.097787] R10: 0000000000000001 R11: ffff88003a26b330 R12: 0000000000000030
[  210.104759] R13: 0000000000000000 R14: ffff88002b4d8800 R15: 0000000000000001
[  210.111611] FS:  00007f695df80700(0000) GS:ffff88003f800000(0000) knlGS:0000000000000000
[  210.118570] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[  210.125586] CR2: 00007f695402e000 CR3: 0000000032a8f000 CR4: 0000000000000660
[  210.132677] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  210.139560] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  210.146350] Process netback/0 (pid: 1179, threadinfo ffff880037922000, task ffff8800398a61e0)
[  210.153213] Stack:
[  210.159974]  ffff880037923d1c ffff880037922010 ffff880037923d00 ffff880037923c80
[  210.166905]  ffffffff810800b5 0000000000000662 ffffc90010824bb8 ffffc90010820050
[  210.173802]  0000000001080083 ffffc90010820000 0000000000000000 ffff8800375849c0
[  210.180780] Call Trace:
[  210.187656]  [] ? __alloc_workqueue_key+0x265/0x5d0
[  210.194674]  [] ? trace_hardirqs_on+0xd/0x10
[  210.201690]  [] xen_netbk_kthread+0xba/0xa90
[  210.208659]  [] ? try_to_wake_up+0x1b6/0x310
[  210.215688]  [] ? wake_up_bit+0x40/0x40
[  210.222665]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
[  210.229651]  [] kthread+0xd6/0xe0
[  210.236455]  [] kernel_thread_helper+0x4/0x10
[  210.243111]  [] ? retint_restore_args+0x13/0x13
[  210.249687]  [] ? gs_change+0x13/0x13
[  210.256195] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 36 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7 
[  210.270166] RIP  [] xen_netbk_rx_action+0x89a/0x910
[  210.276925]  RSP 
[  210.284112] ---[ end trace 03f82ac72747fb5b ]---
[  213.634083] device vif13.0 entered promiscuous mode
[  213.911267] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
[  213.920749] vpn_bridge: port 1(vif13.0) entered forwarding state
[  213.927480] vpn_bridge: port 1(vif13.0) entered forwarding state
[  215.509632] xen_bridge: port 11(vif11.0) entered forwarding state
[  215.825483] netbk_gop_frag_copy: size 2c1 offset 12d6
[  215.825483]  => 1597 > 1000
[  215.838666] netbk_gop_frag_copy failed: skb frag 0 page
[  215.845265] copying from offset 12d6, len 2c1
[  215.851790] page:ffffea0000b0a800 count:6 mapcount:0 mapping:          (null) index:0x7f40fec00
[  215.858389] page flags: 0x40000000004000(head)
[  215.864925] ------------[ cut here ]------------
[  215.871426] kernel BUG at drivers/net/xen-netback/netback.c:548!
[  215.878069] invalid opcode: 0000 [#3] PREEMPT SMP 
[  215.884696] Modules linked in:
[  215.891258] CPU 3 
[  215.891308] Pid: 1182, comm: netback/3 Tainted: G      D      3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)  
[  215.904613] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
[  215.911538] RSP: e02b:ffff880037929c20  EFLAGS: 00010282
[  215.918336] RAX: 0000000000000001 RBX: ffff88002c361ee0 RCX: 0000000000000000
[  215.925236] RDX: ffff880037ced190 RSI: 0000000000000001 RDI: ffff8800379202b0
[  215.932144] RBP: ffff880037929d50 R08: 0000000000000002 R09: 0000000000000000
[  215.938988] R10: 0000000000000001 R11: ffff88003a26aca0 R12: 0000000000000030
[  215.945835] R13: 0000000000000000 R14: ffff88002b49b400 R15: 0000000000000001
[  215.952652] FS:  00007f695c355700(0000) GS:ffff88003f8c0000(0000) knlGS:0000000000000000
[  215.959476] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[  215.966165] CR2: 00007faa79583000 CR3: 0000000032a8f000 CR4: 0000000000000660
[  215.972789] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  215.979339] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  215.985844] Process netback/3 (pid: 1182, threadinfo ffff880037928000, task ffff880037ced190)
[  215.992486] Stack:
[  215.999085]  ffff880037929d1c ffff880037928010 ffff880037929d00 ffff880037929c80
[  216.005896]  ffffffff810800b5 00000000000000ba ffffc900108466e0 ffffc90010841b78
[  216.012651]  0000000101080083 ffffc90010841b28 0000000100000000 ffff880031a869c0
[  216.019386] Call Trace:
[  216.026026]  [] ? __alloc_workqueue_key+0x265/0x5d0
[  216.032830]  [] ? trace_hardirqs_on+0xd/0x10
[  216.039668]  [] xen_netbk_kthread+0xba/0xa90
[  216.046435]  [] ? try_to_wake_up+0x1b6/0x310
[  216.053094]  [] ? wake_up_bit+0x40/0x40
[  216.059670]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
[  216.066279]  [] kthread+0xd6/0xe0
[  216.072817]  [] kernel_thread_helper+0x4/0x10
[  216.079308]  [] ? retint_restore_args+0x13/0x13
[  216.085783]  [] ? gs_change+0x13/0x13
[  216.092234] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 36 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7 
[  216.106108] RIP  [] xen_netbk_rx_action+0x89a/0x910
[  216.113118]  RSP 
[  216.120011] ---[ end trace 03f82ac72747fb5c ]---
[  219.765094] device vif14.0 entered promiscuous mode
[  220.062152] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
[  220.072238] xen_bridge: port 13(vif14.0) entered forwarding state
[  220.079416] xen_bridge: port 13(vif14.0) entered forwarding state
[  221.912781] xen_bridge: port 12(vif12.0) entered forwarding state
[  222.876167] netbk_gop_frag_copy: size 2c1 offset 1858
[  222.876167]  => 1b19 > 1000
[  222.889279] netbk_gop_frag_copy failed: skb frag 0 page
[  222.895959] copying from offset 1858, len 2c1
[  222.902484] page:ffffea0000b0a800 count:8 mapcount:0 mapping:          (null) index:0x7f40fec00
[  222.909119] page flags: 0x40000000004000(head)
[  222.915711] ------------[ cut here ]------------
[  222.922307] kernel BUG at drivers/net/xen-netback/netback.c:548!
[  222.928950] invalid opcode: 0000 [#4] PREEMPT SMP 
[  222.935546] Modules linked in:
[  222.942110] CPU 5 
[  222.942161] Pid: 1184, comm: netback/5 Tainted: G      D      3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)  
[  222.955415] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
[  222.962350] RSP: e02b:ffff88003792dc20  EFLAGS: 00010282
[  222.969198] RAX: 0000000000000001 RBX: ffff88002b4f4ce0 RCX: 0000000000000000
[  222.976119] RDX: ffff880037ceb0f0 RSI: 0000000000000001 RDI: ffff8800379202b0
[  222.982987] RBP: ffff88003792dd50 R08: 0000000000000002 R09: 0000000000000000
[  222.989869] R10: 0000000000000001 R11: ffff88003a26b380 R12: 0000000000000030
[  222.996658] R13: 0000000000000000 R14: ffff88002b5a7800 R15: 0000000000000001
[  223.003490] FS:  00007f71c6ce2740(0000) GS:ffff88003f940000(0000) knlGS:0000000000000000
[  223.010257] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[  223.016868] CR2: 00007f71c66b4d15 CR3: 0000000031f46000 CR4: 0000000000000660
[  223.023470] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  223.029999] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  223.036478] Process netback/5 (pid: 1184, threadinfo ffff88003792c000, task ffff880037ceb0f0)
[  223.043095] Stack:
[  223.049616]  ffff88003792dd1c ffff88003792c010 ffff88003792dd00 ffff88003792dc80
[  223.056404]  ffffffff810800b5 00000000000000ba ffffc9001085ce50 ffffc900108582e8
[  223.063150]  0000000101080083 ffffc90010858298 0000000100000000 ffff88002c38d9c0
[  223.069955] Call Trace:
[  223.076591]  [] ? __alloc_workqueue_key+0x265/0x5d0
[  223.083426]  [] ? trace_hardirqs_on+0xd/0x10
[  223.090261]  [] xen_netbk_kthread+0xba/0xa90
[  223.096990]  [] ? try_to_wake_up+0x1b6/0x310
[  223.103620]  [] ? wake_up_bit+0x40/0x40
[  223.110195]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
[  223.116768]  [] kthread+0xd6/0xe0
[  223.123312]  [] kernel_thread_helper+0x4/0x10
[  223.129794]  [] ? retint_restore_args+0x13/0x13
[  223.136217]  [] ? gs_change+0x13/0x13
[  223.142658] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 36 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7 
[  223.156486] RIP  [] xen_netbk_rx_action+0x89a/0x910
[  223.163337]  RSP 
[  223.170212] ---[ end trace 03f82ac72747fb5d ]---
[  228.705439] device vif15.0 entered promiscuous mode
[  228.880399] device vif15.0-emu entered promiscuous mode
[  228.889286] xen_bridge: port 15(vif15.0-emu) entered forwarding state
[  228.895546] xen_bridge: port 15(vif15.0-emu) entered forwarding state
[  228.956267] vpn_bridge: port 1(vif13.0) entered forwarding state
[  229.119709] pciback 0000:06:00.0: restoring config space at offset 0x3c (was 0x100, writing 0x10a)
[  229.126644] pciback 0000:06:00.0: restoring config space at offset 0x10 (was 0x4, writing 0xf9a00004)
[  229.133434] pciback 0000:06:00.0: restoring config space at offset 0xc (was 0x0, writing 0x10)
[  234.170536] tty_init_dev: 15 callbacks suppressed
[  235.092664] xen_bridge: port 13(vif14.0) entered forwarding state
[  235.684229] device vif16.0 entered promiscuous mode
[  235.805155] device vif16.0-emu entered promiscuous mode
[  235.813948] xen_bridge: port 17(vif16.0-emu) entered forwarding state
[  235.820242] xen_bridge: port 17(vif16.0-emu) entered forwarding state
[  239.632852] xen_bridge: port 15(vif15.0-emu) entered disabled state
[  239.641629] xen_bridge: port 15(vif15.0-emu) entered disabled state
[  239.650288] device vif15.0-emu left promiscuous mode
[  239.658618] xen_bridge: port 15(vif15.0-emu) entered disabled state
[  240.982436] tty_init_dev: 15 callbacks suppressed
[  241.386562] xen-blkback:ring-ref 8, event-channel 25, protocol 1 (x86_64-abi)
[  241.400247] xen-blkback:ring-ref 9, event-channel 26, protocol 1 (x86_64-abi)
[  241.454701] xen_bridge: port 14(vif15.0) entered forwarding state
[  241.463330] xen_bridge: port 14(vif15.0) entered forwarding state
[  246.690393] xen_bridge: port 17(vif16.0-emu) entered disabled state
[  246.699042] xen_bridge: port 17(vif16.0-emu) entered disabled state
[  246.708731] device vif16.0-emu left promiscuous mode
[  246.717465] xen_bridge: port 17(vif16.0-emu) entered disabled state
[  249.449321] xen-blkback:ring-ref 8, event-channel 25, protocol 1 (x86_64-abi)
[  249.619531] xen_bridge: port 16(vif16.0) entered forwarding state
[  249.628307] xen_bridge: port 16(vif16.0) entered forwarding state
[  256.489967] xen_bridge: port 14(vif15.0) entered forwarding state
[  264.654183] xen_bridge: port 16(vif16.0) entered forwarding state
[  414.296535] tty_init_dev: 16 callbacks suppressed
[  458.898093] netbk_gop_frag_copy: size 5a8 offset 3602
[  458.898093]  => 3baa > 1000
[  458.920252] netbk_gop_frag_copy failed: skb frag 0 page
[  458.928746] copying from offset 3602, len 5a8
[  458.937114] page:ffffea0000ada800 count:32749 mapcount:0 mapping:          (null) index:0xffff88002b6a6100
[  458.945813] page flags: 0x40000000004000(head)
[  458.954314] ------------[ cut here ]------------
[  458.962655] kernel BUG at drivers/net/xen-netback/netback.c:548!
[  458.970929] invalid opcode: 0000 [#5] PREEMPT SMP 
[  458.979113] Modules linked in:
[  458.987128] CPU 1 
[  458.987178] Pid: 1180, comm: netback/1 Tainted: G      D      3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)  
[  459.003052] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
[  459.011121] RSP: e02b:ffff880037925c20  EFLAGS: 00010282
[  459.019135] RAX: 0000000000000001 RBX: ffff88002ab0bf00 RCX: 0000000000000000
[  459.027199] RDX: ffff8800398a30f0 RSI: 0000000000000001 RDI: ffff8800379202b0
[  459.035081] RBP: ffff880037925d50 R08: 0000000000000002 R09: 0000000000000000
[  459.042816] R10: 0000000000000001 R11: ffff88003a26bdb0 R12: 0000000000000030
[  459.050308] R13: 0000000000000000 R14: ffff88002b6a2e00 R15: 0000000000000001
[  459.057725] FS:  00007f8e25af5760(0000) GS:ffff88003f840000(0000) knlGS:0000000000000000
[  459.065052] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[  459.072248] CR2: 00007fe6b4d12fb0 CR3: 000000002c2f6000 CR4: 0000000000000660
[  459.079480] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  459.086512] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  459.093386] Process netback/1 (pid: 1180, threadinfo ffff880037924000, task ffff8800398a30f0)
[  459.100357] Stack:
[  459.107071]  ffff880037925d1c ffff880037924010 ffff880037925d00 ffff880037925c80
[  459.113808]  ffffffff810800b5 000000000000042a ffffc9001082ff70 ffffc9001082b408
[  459.120494]  0000000001080083 ffffc9001082b3b8 0000000000000000 ffff8800329249c0
[  459.127129] Call Trace:
[  459.133509]  [] ? __alloc_workqueue_key+0x265/0x5d0
[  459.140118]  [] ? trace_hardirqs_on+0xd/0x10
[  459.146604]  [] xen_netbk_kthread+0xba/0xa90
[  459.153504]  [] ? try_to_wake_up+0x1b6/0x310
[  459.159949]  [] ? wake_up_bit+0x40/0x40
[  459.166431]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
[  459.172778]  [] kthread+0xd6/0xe0
[  459.179018]  [] kernel_thread_helper+0x4/0x10
[  459.185291]  [] ? retint_restore_args+0x13/0x13
[  459.191523]  [] ? gs_change+0x13/0x13
[  459.197862] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 36 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7 
[  459.211184] RIP  [] xen_netbk_rx_action+0x89a/0x910
[  459.217785]  RSP 
[  459.224501] ---[ end trace 03f82ac72747fb5e ]---




> This made me notice that offset and len in the caller are variously
> unsigned int, u16 or u32 while gop_frag_copy takes them as unsigned
> longs. None of the numbers involved here are anywhere big enough to
> cause any sort of overflow related error though.

>> [  197.892781] page:ffffea0000b18400 count:3 mapcount:0 mapping:          (null) index:0x0
>> [  197.900778] page flags: 0x40000000004000(head)
>> [  197.907074] ------------[ cut here ]------------
>> [  197.913345] kernel BUG at drivers/net/xen-netback/netback.c:546!
>> [  197.919626] invalid opcode: 0000 [#1] PREEMPT SMP
>> [  197.921573] xen_bridge: port 10(vif10.0) entered forwarding state
>> [  197.932106] Modules linked in:
>> [  197.938370] CPU 0
>> [  197.938420] Pid: 1180, comm: netback/0 Not tainted 3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)
>> [  197.951203] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
>> [  197.957775] RSP: e02b:ffff880037911c20  EFLAGS: 00010282
>> [  197.964290] RAX: 0000000000000001 RBX: ffff880036862ee0 RCX: 0000000000000000
>> [  197.970956] RDX: 0000000000000001 RSI: 0000000000000001 RDI: ffff8800379102b0
>> [  197.977679] RBP: ffff880037911d50 R08: 0000000000000002 R09: 0000000000000000
>> [  197.984361] R10: 0000000000000001 R11: ffff880039925e40 R12: 0000000000000030
>> [  197.990958] R13: 0000000000000000 R14: ffff880031e71800 R15: 0000000000000001
>> [  197.997459] FS:  00007fb5dfcf7700(0000) GS:ffff88003f800000(0000) knlGS:0000000000000000
>> [  198.004123] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
>> [  198.010827] CR2: 00007fb5d802d000 CR3: 0000000031fd3000 CR4: 0000000000000660
>> [  198.017534] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> [  198.024168] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>> [  198.030717] Process netback/0 (pid: 1180, threadinfo ffff880037910000, task ffff88003997d190)
>> [  198.037326] Stack:
>> [  198.043817]  ffff880037911d1c ffff88003997d840 ffff880037911d00 ffff880037911c80
>> [  198.050573]  ffffffff00000001 0000000000000662 ffffc90010824bb8 ffffc90010820050
>> [  198.057413]  0000000001080083 ffffc90010820000 0000000000000000 ffff880031cf09c0
>> [  198.064228] Call Trace:
>> [  198.070887]  [] ? trace_hardirqs_on+0xd/0x10
>> [  198.077604]  [] xen_netbk_kthread+0xba/0xa90
>> [  198.084394]  [] ? try_to_wake_up+0x1b6/0x310
>> [  198.091109]  [] ? wake_up_bit+0x40/0x40
>> [  198.097726]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
>> [  198.104343]  [] kthread+0xd6/0xe0
>> [  198.111001]  [] kernel_thread_helper+0x4/0x10
>> [  198.117737]  [] ? retint_restore_args+0x13/0x13
>> [  198.124425]  [] ? gs_change+0x13/0x13
>> [  198.131008] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 46 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7
>> [  198.145094] RIP  [] xen_netbk_rx_action+0x89a/0x910
>> [  198.152192]  RSP 
>> [  198.159344] ---[ end trace cbdd0e4e80268fa8 ]---
>> [  199.703539] tty_init_dev: 2 callbacks suppressed
>> [  200.712098] device vif12.0 entered promiscuous mode
>> [  201.010433] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
>> [  201.020644] xen_bridge: port 12(vif12.0) entered forwarding state
>> [  201.027833] xen_bridge: port 12(vif12.0) entered forwarding state
>> [  206.774576] netbk_gop_frag_copy failed: skb frag 0 page
>> [  206.777945] device vif13.0 entered promiscuous mode
>> [  206.788845] copying from offset 1ba4, len 2c1
>> [  206.795791] page:ffffea0000b18400 count:6 mapcount:0 mapping:          (null) index:0x0
>> [  206.802771] page flags: 0x40000000004000(head)
>> [  206.809619] ------------[ cut here ]------------
>> [  206.816498] kernel BUG at drivers/net/xen-netback/netback.c:546!
>> [  206.823465] invalid opcode: 0000 [#2] PREEMPT SMP
>> [  206.830354] Modules linked in:
>> [  206.837176] CPU 3
>> [  206.837234] Pid: 1183, comm: netback/3 Tainted: G      D      3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)
>> [  206.850881] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
>> [  206.857935] RSP: e02b:ffff880037917c20  EFLAGS: 00010282
>> [  206.864972] RAX: 0000000000000001 RBX: ffff880003313ae0 RCX: 0000000000000000
>> [  206.872049] RDX: ffff88003997b0f0 RSI: 0000000000000001 RDI: ffff8800379102b0
>> [  206.879147] RBP: ffff880037917d50 R08: 0000000000000002 R09: 0000000000000000
>> [  206.886242] R10: 0000000000000001 R11: ffff880039925640 R12: 0000000000000030
>> [  206.893163] R13: 0000000000000000 R14: ffff88002c7c4400 R15: 0000000000000001
>> [  206.900041] FS:  00007f800341a700(0000) GS:ffff88003f8c0000(0000) knlGS:0000000000000000
>> [  206.907145] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
>> [  206.914126] CR2: 00007f8002b31fb0 CR3: 0000000001c0b000 CR4: 0000000000000660
>> [  206.921181] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> [  206.927996] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>> [  206.934711] Process netback/3 (pid: 1183, threadinfo ffff880037916000, task ffff88003997b0f0)
>> [  206.941494] Stack:
>> [  206.948105]  ffff880037917d1c ffff880037916010 ffff880037917d00 ffff880037917c80
>> [  206.955062]  ffffffff810800b5 00000000000000ba ffffc900108466e0 ffffc90010841b78
>> [  206.962007]  0000000101080083 ffffc90010841b28 0000000100000000 ffff88002c5bb9c0
>> [  206.968967] Call Trace:
>> [  206.975830]  [] ? __alloc_workqueue_key+0x265/0x5d0
>> [  206.982789]  [] ? trace_hardirqs_on+0xd/0x10
>> [  206.989662]  [] xen_netbk_kthread+0xba/0xa90
>> [  206.996570]  [] ? try_to_wake_up+0x1b6/0x310
>> [  207.003523]  [] ? wake_up_bit+0x40/0x40
>> [  207.010333]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
>> [  207.017171]  [] kthread+0xd6/0xe0
>> [  207.023890]  [] kernel_thread_helper+0x4/0x10
>> [  207.030540]  [] ? retint_restore_args+0x13/0x13
>> [  207.037275]  [] ? gs_change+0x13/0x13
>> [  207.043890] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 46 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7
>> [  207.057976] RIP  [] xen_netbk_rx_action+0x89a/0x910
>> [  207.065064]  RSP 
>> [  207.072056] ---[ end trace cbdd0e4e80268fa9 ]---
>> [  207.079366] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
>> [  207.090256] vpn_bridge: port 1(vif13.0) entered forwarding state
>> [  207.097403] vpn_bridge: port 1(vif13.0) entered forwarding state
>> [  208.636257] xen_bridge: port 11(vif11.0) entered forwarding state
>> [  211.515779] netbk_gop_frag_copy failed: skb frag 0 page
>> [  211.522711] copying from offset 2126, len 2c1
>> [  211.529403] page:ffffea0000b18400 count:8 mapcount:0 mapping:          (null) index:0x0
>> [  211.536142] page flags: 0x40000000004000(head)
>> [  211.542942] ------------[ cut here ]------------
>> [  211.549664] kernel BUG at drivers/net/xen-netback/netback.c:546!
>> [  211.556408] invalid opcode: 0000 [#3] PREEMPT SMP
>> [  211.563168] Modules linked in:
>> [  211.569739] CPU 4
>> [  211.569789] Pid: 1184, comm: netback/4 Tainted: G      D      3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)
>> [  211.583126] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
>> [  211.590041] RSP: e02b:ffff880037921c20  EFLAGS: 00010282
>> [  211.596868] RAX: 0000000000000001 RBX: ffff8800375bc4e0 RCX: 0000000000000000
>> [  211.603890] RDX: ffff88003997a0a0 RSI: 0000000000000001 RDI: ffff8800379202b0
>> [  211.610792] RBP: ffff880037921d50 R08: 0000000000000002 R09: 0000000000000000
>> [  211.617608] R10: 0000000000000001 R11: ffff8800399249e0 R12: 0000000000000030
>> [  211.624537] R13: 0000000000000000 R14: ffff88002b98d400 R15: 0000000000000001
>> [  211.631302] FS:  00007f332d735740(0000) GS:ffff88003f900000(0000) knlGS:0000000000000000
>> [  211.638090] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
>> [  211.644965] CR2: 00007f1023d22000 CR3: 0000000031fba000 CR4: 0000000000000660
>> [  211.651894] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> [  211.658652] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>> [  211.665288] Process netback/4 (pid: 1184, threadinfo ffff880037920000, task ffff88003997a0a0)
>> [  211.671884] Stack:
>> [  211.678376]  ffff880037921d1c ffff880037920010 ffff880037921d00 ffff880037921c80
>> [  211.685145]  ffffffff810800b5 00000000000000ba ffffc90010851a98 ffffc9001084cf30
>> [  211.691837]  0000000101080083 ffffc9001084cee0 0000000100000000 ffff88002c5bd9c0
>> [  211.698581] Call Trace:
>> [  211.705349]  [] ? __alloc_workqueue_key+0x265/0x5d0
>> [  211.712156]  [] ? trace_hardirqs_on+0xd/0x10
>> [  211.718907]  [] xen_netbk_kthread+0xba/0xa90
>> [  211.725654]  [] ? try_to_wake_up+0x1b6/0x310
>> [  211.732369]  [] ? wake_up_bit+0x40/0x40
>> [  211.739111]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
>> [  211.745858]  [] kthread+0xd6/0xe0
>> [  211.752449]  [] kernel_thread_helper+0x4/0x10
>> [  211.758975]  [] ? retint_restore_args+0x13/0x13
>> [  211.765575]  [] ? gs_change+0x13/0x13
>> [  211.772016] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 46 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7
>> [  211.785816] RIP  [] xen_netbk_rx_action+0x89a/0x910
>> [  211.792586]  RSP 
>> [  211.799394] ---[ end trace cbdd0e4e80268faa ]---
>> [  212.852714] device vif14.0 entered promiscuous mode
>> [  213.234995] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
>> [  213.245054] xen_bridge: port 13(vif14.0) entered forwarding state
>> [  213.252087] xen_bridge: port 13(vif14.0) entered forwarding state
>> [  214.691532] netbk_gop_frag_copy failed: skb frag 0 page
>> [  214.698515] copying from offset 26a8, len 2c1
>> [  214.705472] page:ffffea0000b18400 count:10 mapcount:0 mapping:          (null) index:0x0
>> [  214.712415] page flags: 0x40000000004000(head)
>> [  214.719170] ------------[ cut here ]------------
>> [  214.725887] kernel BUG at drivers/net/xen-netback/netback.c:546!
>> [  214.732563] invalid opcode: 0000 [#4] PREEMPT SMP
>> [  214.739221] Modules linked in:
>> [  214.745808] CPU 5
>> [  214.745859] Pid: 1185, comm: netback/5 Tainted: G      D      3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)
>> [  214.759156] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
>> [  214.766127] RSP: e02b:ffff880037923c20  EFLAGS: 00010282
>> [  214.773012] RAX: 0000000000000001 RBX: ffff8800379172e0 RCX: 0000000000000000
>> [  214.780010] RDX: ffff880039ac8000 RSI: 0000000000000001 RDI: ffff8800379202b0
>> [  214.786988] RBP: ffff880037923d50 R08: 0000000000000002 R09: 0000000000000000
>> [  214.793870] R10: 0000000000000001 R11: ffff880039924460 R12: 0000000000000030
>> [  214.800812] R13: 0000000000000000 R14: ffff88002b8b4800 R15: 0000000000000001
>> [  214.807668] FS:  00007f236d331700(0000) GS:ffff88003f940000(0000) knlGS:0000000000000000
>> [  214.814545] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
>> [  214.821415] CR2: 00007f236c42b6b0 CR3: 0000000039275000 CR4: 0000000000000660
>> [  214.828435] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> [  214.835337] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>> [  214.841963] Process netback/5 (pid: 1185, threadinfo ffff880037922000, task ffff880039ac8000)
>> [  214.848655] Stack:
>> [  214.855220]  ffff880037923d1c ffff880037922010 ffff880037923d00 ffff880037923c80
>> [  214.861945]  ffffffff810800b5 00000000000000ba ffffc9001085ce50 ffffc900108582e8
>> [  214.868699]  0000000101080083 ffffc90010858298 0000000100000000 ffff880031e939c0
>> [  214.875477] Call Trace:
>> [  214.882247]  [] ? __alloc_workqueue_key+0x265/0x5d0
>> [  214.889083]  [] ? trace_hardirqs_on+0xd/0x10
>> [  214.895851]  [] xen_netbk_kthread+0xba/0xa90
>> [  214.902612]  [] ? try_to_wake_up+0x1b6/0x310
>> [  214.909343]  [] ? wake_up_bit+0x40/0x40
>> [  214.916115]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
>> [  214.922856]  [] kthread+0xd6/0xe0
>> [  214.929527]  [] kernel_thread_helper+0x4/0x10
>> [  214.936178]  [] ? retint_restore_args+0x13/0x13
>> [  214.942781]  [] ? gs_change+0x13/0x13
>> [  214.949279] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 46 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7
>> [  214.963107] RIP  [] xen_netbk_rx_action+0x89a/0x910
>> [  214.969952]  RSP 
>> [  214.976802] ---[ end trace cbdd0e4e80268fab ]---
>> [  216.045946] xen_bridge: port 12(vif12.0) entered forwarding state
>> [  220.405869] device vif15.0 entered promiscuous mode
>> [  220.607946] device vif15.0-emu entered promiscuous mode
>> [  220.625075] xen_bridge: port 15(vif15.0-emu) entered forwarding state
>> [  220.633333] xen_bridge: port 15(vif15.0-emu) entered forwarding state
>> [  220.890237] pciback 0000:06:00.0: restoring config space at offset 0x3c (was 0x100, writing 0x10a)
>> [  220.898814] pciback 0000:06:00.0: restoring config space at offset 0x10 (was 0x4, writing 0xf9a00004)
>> [  220.907406] pciback 0000:06:00.0: restoring config space at offset 0xc (was 0x0, writing 0x10)
>> [  222.122750] vpn_bridge: port 1(vif13.0) entered forwarding state
>> [  225.943971] tty_init_dev: 14 callbacks suppressed
>> [  226.654618] device vif16.0 entered promiscuous mode
>> [  226.775073] device vif16.0-emu entered promiscuous mode
>> [  226.784025] xen_bridge: port 17(vif16.0-emu) entered forwarding state
>> [  226.790188] xen_bridge: port 17(vif16.0-emu) entered forwarding state
>> [  228.253024] xen_bridge: port 13(vif14.0) entered forwarding state
>> [  229.788197] xen_bridge: port 15(vif15.0-emu) entered disabled state
>> [  229.796826] xen_bridge: port 15(vif15.0-emu) entered disabled state
>> [  229.805243] device vif15.0-emu left promiscuous mode
>> [  229.813385] xen_bridge: port 15(vif15.0-emu) entered disabled state
>> [  231.558329] xen-blkback:ring-ref 8, event-channel 25, protocol 1 (x86_64-abi)
>> [  231.569080] xen-blkback:ring-ref 9, event-channel 26, protocol 1 (x86_64-abi)
>> [  231.609663] xen_bridge: port 14(vif15.0) entered forwarding state
>> [  231.617943] xen_bridge: port 14(vif15.0) entered forwarding state
>> [  231.934347] tty_init_dev: 25 callbacks suppressed
>> 
>> 
>> 
>> 
>> 
>> 
>> > Ian.
>> 
>> > diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
>> > index 05593d8..ca4c47d 100644
>> > --- a/drivers/net/xen-netback/netback.c
>> > +++ b/drivers/net/xen-netback/netback.c
>> > @@ -386,7 +386,7 @@ static struct netbk_rx_meta *get_next_rx_buffer(struct xenvif *vif,
>> >   * Set up the grant operations for this fragment. If it's a flipping
>> >   * interface, we also set up the unmap request from here.
>> >   */
>> > -static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
>> > +static int netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
>> >                                 struct netrx_pending_operations *npo,
>> >                                 struct page *page, unsigned long size,
>> >                                 unsigned long offset, int *head)
>> > @@ -402,7 +402,8 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
>> >         unsigned long bytes;
>> >
>> >         /* Data must not cross a page boundary. */
>> > -       BUG_ON(size + offset > PAGE_SIZE);
>> > +       if (size + offset > PAGE_SIZE)
>> > +               return -1;
>> >
>> >         meta = npo->meta + npo->meta_prod - 1;
>> >
>> > @@ -459,6 +460,7 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
>> >                 *head = 0; /* There must be something in this buffer now. */
>> >
>> >         }
>> > +       return 0;
>> >  }
>> >
>> >  /*
>> > @@ -517,17 +519,31 @@ static int netbk_gop_skb(struct sk_buff *skb,
>> >                 if (data + len > skb_tail_pointer(skb))
>> >                         len = skb_tail_pointer(skb) - data;
>> >
>> > -               netbk_gop_frag_copy(vif, skb, npo,
>> > -                                   virt_to_page(data), len, offset, &head);
>> > +               if (netbk_gop_frag_copy(vif, skb, npo,
>> > +                               virt_to_page(data), len, offset, &head) < 0) {
>> > +printk(KERN_CRIT "netbk_gop_frag_copy failed: skb head %p-%p\n",
>> +       skb->>data, skb_tail_pointer);
>> > +printk(KERN_CRIT "copying from %p-%p, offset %x, len %x\n",
>> > +       data, data+len, offset, len);
>> > +dump_page(virt_to_page(data));
>> > +BUG();
>> > +               }
>> >                 data += len;
>> >         }
>> >
>> >         for (i = 0; i < nr_frags; i++) {
>> > -               netbk_gop_frag_copy(vif, skb, npo,
>> > +               if (netbk_gop_frag_copy(vif, skb, npo,
>> >                                     skb_frag_page(&skb_shinfo(skb)->frags[i]),
>> >                                     skb_frag_size(&skb_shinfo(skb)->frags[i]),
>> >                                     skb_shinfo(skb)->frags[i].page_offset,
>> > -                                   &head);
>> > +                                   &head) < 0) {
>> > +printk(KERN_CRIT "netbk_gop_frag_copy failed: skb frag %d page\n", i);
>> > +printk(KERN_CRIT "copying from offset %x, len %x\n",
>> > +       skb_shinfo(skb)->frags[i].page_offset,
>> > +       skb_frag_size(&skb_shinfo(skb)->frags[i]));
>> > +dump_page(skb_frag_page(&skb_shinfo(skb)->frags[i]));
>> > +BUG();
>> > +               }
>> >         }
>> >
>> >         return npo->meta_prod - old_meta_prod;
>> 
>> 
>> 
>> 





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 11:08:22 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 11:08:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLXf7-0001tK-Je; Tue, 09 Oct 2012 11:07:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLXf5-0001tF-UC
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 11:07:44 +0000
Received: from [85.158.143.35:56154] by server-2.bemta-4.messagelabs.com id
	EB/90-06610-F7504705; Tue, 09 Oct 2012 11:07:43 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-10.tower-21.messagelabs.com!1349780860!10727386!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17219 invoked from network); 9 Oct 2012 11:07:40 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-10.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	9 Oct 2012 11:07:40 -0000
Received: from 50-66-ftth.onsneteindhoven.nl ([88.159.66.50]:55334
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TLXgI-0003oo-O1; Tue, 09 Oct 2012 13:08:58 +0200
Date: Tue, 9 Oct 2012 13:07:33 +0200
From: Sander Eikelenboom 
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1305237695.20121009130733@eikelenboom.it>
To: Ian Campbell 
In-Reply-To: <1349774588.21847.105.camel@zakaz.uk.xensource.com>
References: 
	<729626082.20121006002054@eikelenboom.it>
	<20121007233444.GA26929@localhost.localdomain>
	<1349686461.18008.18.camel@zakaz.uk.xensource.com>
	<120335733.20121009042424@eikelenboom.it>
	<1349774588.21847.105.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk ,
	"xen-devel@lists.xensource.com" ,
	konrad 
Subject: Re: [Xen-devel] Kernel 3.7.0-pre-rc1 kernel BUG at
	drivers/net/xen-netback/netback.c:405 RIP:
	e030:[] []
	netbk_gop_frag_copy+0x379/0x380
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Tuesday, October 9, 2012, 11:23:08 AM, you wrote:

> On Tue, 2012-10-09 at 03:24 +0100, Sander Eikelenboom wrote:

>> >> Looking at the code, this is what we get:
>> >>
>> >>         /* Data must not cross a page boundary. */
>> >>         BUG_ON(size + offset > PAGE_SIZE);
>> >>[...]
>> After applying the debug patch:
>> 
>> [  197.876304] netbk_gop_frag_copy failed: skb frag 0 page
>> [  197.884299] copying from offset 0, len 1628

> WTF! This turns into BUG_ON(0 + 1628 > PAGE_SIZE) (where PAGE_SIZE is
> 4096) which simply should not be triggering.

> Perhaps I screwed up the debugging patch... investigates... no I don't
> think so, but someone should definitely check my working.

> For belt and braces can you change, in netbk_gop_frag_copy:
>         /* Data must not cross a page boundary. */
>         if (size + offset > PAGE_SIZE)
>                 return -1;
> into:
>         /* Data must not cross a page boundary. */
>         if (size + offset > PAGE_SIZE) {
>                 printk(KERN_CRIT "netbk_gop_frag_copy: size %lx offset %lx\n => %lx > %lx\n",
>                        size, offset, size + offset, PAGE_SIZE);
>                 return -1;
>         }

Done:

[  199.342570] netbk_gop_frag_copy: size 5a8 offset 7102
[  199.342570]  => 76aa > 1000
[  199.354626] netbk_gop_frag_copy failed: skb frag 0 page
[  199.360930] copying from offset 7102, len 5a8
[  199.366887] page:ffffea0000b0aa00 count:3 mapcount:0 mapping:          (null) index:0x7f40fec00
[  199.373008] page flags: 0x40000000004000(head)
[  199.379252] ------------[ cut here ]------------
[  199.385247] kernel BUG at drivers/net/xen-netback/netback.c:548!
[  199.391334] invalid opcode: 0000 [#1] PREEMPT SMP 
[  199.397446] Modules linked in:
[  199.403450] CPU 4 
[  199.403500] Pid: 1183, comm: netback/4 Not tainted 3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)  
[  199.415401] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
[  199.421690] RSP: e02b:ffff88003792bc20  EFLAGS: 00010282
[  199.428048] RAX: 0000000000000001 RBX: ffff88003197c600 RCX: 0000000000000000
[  199.434358] RDX: 0000000000000001 RSI: 0000000000000001 RDI: ffff8800379202b0
[  199.440582] RBP: ffff88003792bd50 R08: 0000000000000002 R09: 0000000000000000
[  199.446740] R10: 0000000000000001 R11: ffff88003a26c000 R12: 0000000000000030
[  199.452965] R13: 0000000000000000 R14: ffff88002c2ae900 R15: 0000000000000001
[  199.459203] FS:  00007fcec7740700(0000) GS:ffff88003f900000(0000) knlGS:0000000000000000
[  199.465527] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[  199.471735] CR2: 00007fff5f59c000 CR3: 0000000001c0b000 CR4: 0000000000000660
[  199.477961] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  199.484102] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  199.490274] Process netback/4 (pid: 1183, threadinfo ffff88003792a000, task ffff880037cec140)
[  199.496631] Stack:
[  199.502834]  ffff88003792bd1c ffff880037cec7f0 ffff88003792bd00 ffff88003792bc80
[  199.509198]  ffffffff00000001 00000000000005ea ffffc90010851a98 ffffc9001084cf30
[  199.515579]  0000000001080083 ffffc9001084cee0 0000000000000000 ffff880032b449c0
[  199.521944] Call Trace:
[  199.528243]  [] ? trace_hardirqs_on+0xd/0x10
[  199.534566]  [] xen_netbk_kthread+0xba/0xa90
[  199.540826]  [] ? try_to_wake_up+0x1b6/0x310
[  199.547193]  [] ? wake_up_bit+0x40/0x40
[  199.553450]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
[  199.559683]  [] kthread+0xd6/0xe0
[  199.565827]  [] kernel_thread_helper+0x4/0x10
[  199.572086]  [] ? retint_restore_args+0x13/0x13
[  199.578268]  [] ? gs_change+0x13/0x13
[  199.584344] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 36 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7 
[  199.597406] RIP  [] xen_netbk_rx_action+0x89a/0x910
[  199.604013]  RSP 
[  199.610610] ---[ end trace 03f82ac72747fb5a ]---
[  199.990340] device vif11.0 entered promiscuous mode
[  200.466710] xen-blkback:ring-ref 9, event-channel 10, protocol 1 (x86_64-abi)
[  200.476634] xen_bridge: port 11(vif11.0) entered forwarding state
[  200.483621] xen_bridge: port 11(vif11.0) entered forwarding state
[  200.653782] pciback 0000:03:06.0: enabling device (0000 -> 0001)
[  200.661499] xen: registering gsi 22 triggering 0 polarity 1
[  200.669003] Already setup the GSI :22
[  200.677345] pciback 0000:03:06.0: enabling bus mastering
[  201.267297] xen_bridge: port 9(vif9.0) entered forwarding state
[  205.151290] tty_init_dev: 2 callbacks suppressed
[  206.534137] device vif12.0 entered promiscuous mode
[  206.867366] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
[  206.877552] xen_bridge: port 12(vif12.0) entered forwarding state
[  206.884869] xen_bridge: port 12(vif12.0) entered forwarding state
[  208.574036] xen_bridge: port 10(vif10.0) entered forwarding state
[  209.979799] netbk_gop_frag_copy: size 1080 offset 0
[  209.979799]  => 1080 > 1000
[  209.994252] netbk_gop_frag_copy failed: skb frag 0 page
[  210.001191] copying from offset 0, len 1080
[  210.008121] page:ffffea0000b0a800 count:3 mapcount:0 mapping:          (null) index:0x7f40fec00
[  210.015124] page flags: 0x40000000004000(head)
[  210.022122] ------------[ cut here ]------------
[  210.029035] kernel BUG at drivers/net/xen-netback/netback.c:548!
[  210.035973] invalid opcode: 0000 [#2] PREEMPT SMP 
[  210.042819] Modules linked in:
[  210.049467] CPU 0 
[  210.049518] Pid: 1179, comm: netback/0 Tainted: G      D      3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)  
[  210.062788] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
[  210.069740] RSP: e02b:ffff880037923c20  EFLAGS: 00010282
[  210.076711] RAX: 0000000000000001 RBX: ffff880031993ae0 RCX: 0000000000000000
[  210.083744] RDX: ffff8800398a61e0 RSI: 0000000000000001 RDI: ffff8800379202b0
[  210.090801] RBP: ffff880037923d50 R08: 0000000000000002 R09: 0000000000000000
[  210.097787] R10: 0000000000000001 R11: ffff88003a26b330 R12: 0000000000000030
[  210.104759] R13: 0000000000000000 R14: ffff88002b4d8800 R15: 0000000000000001
[  210.111611] FS:  00007f695df80700(0000) GS:ffff88003f800000(0000) knlGS:0000000000000000
[  210.118570] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[  210.125586] CR2: 00007f695402e000 CR3: 0000000032a8f000 CR4: 0000000000000660
[  210.132677] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  210.139560] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  210.146350] Process netback/0 (pid: 1179, threadinfo ffff880037922000, task ffff8800398a61e0)
[  210.153213] Stack:
[  210.159974]  ffff880037923d1c ffff880037922010 ffff880037923d00 ffff880037923c80
[  210.166905]  ffffffff810800b5 0000000000000662 ffffc90010824bb8 ffffc90010820050
[  210.173802]  0000000001080083 ffffc90010820000 0000000000000000 ffff8800375849c0
[  210.180780] Call Trace:
[  210.187656]  [] ? __alloc_workqueue_key+0x265/0x5d0
[  210.194674]  [] ? trace_hardirqs_on+0xd/0x10
[  210.201690]  [] xen_netbk_kthread+0xba/0xa90
[  210.208659]  [] ? try_to_wake_up+0x1b6/0x310
[  210.215688]  [] ? wake_up_bit+0x40/0x40
[  210.222665]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
[  210.229651]  [] kthread+0xd6/0xe0
[  210.236455]  [] kernel_thread_helper+0x4/0x10
[  210.243111]  [] ? retint_restore_args+0x13/0x13
[  210.249687]  [] ? gs_change+0x13/0x13
[  210.256195] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 36 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7 
[  210.270166] RIP  [] xen_netbk_rx_action+0x89a/0x910
[  210.276925]  RSP 
[  210.284112] ---[ end trace 03f82ac72747fb5b ]---
[  213.634083] device vif13.0 entered promiscuous mode
[  213.911267] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
[  213.920749] vpn_bridge: port 1(vif13.0) entered forwarding state
[  213.927480] vpn_bridge: port 1(vif13.0) entered forwarding state
[  215.509632] xen_bridge: port 11(vif11.0) entered forwarding state
[  215.825483] netbk_gop_frag_copy: size 2c1 offset 12d6
[  215.825483]  => 1597 > 1000
[  215.838666] netbk_gop_frag_copy failed: skb frag 0 page
[  215.845265] copying from offset 12d6, len 2c1
[  215.851790] page:ffffea0000b0a800 count:6 mapcount:0 mapping:          (null) index:0x7f40fec00
[  215.858389] page flags: 0x40000000004000(head)
[  215.864925] ------------[ cut here ]------------
[  215.871426] kernel BUG at drivers/net/xen-netback/netback.c:548!
[  215.878069] invalid opcode: 0000 [#3] PREEMPT SMP 
[  215.884696] Modules linked in:
[  215.891258] CPU 3 
[  215.891308] Pid: 1182, comm: netback/3 Tainted: G      D      3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)  
[  215.904613] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
[  215.911538] RSP: e02b:ffff880037929c20  EFLAGS: 00010282
[  215.918336] RAX: 0000000000000001 RBX: ffff88002c361ee0 RCX: 0000000000000000
[  215.925236] RDX: ffff880037ced190 RSI: 0000000000000001 RDI: ffff8800379202b0
[  215.932144] RBP: ffff880037929d50 R08: 0000000000000002 R09: 0000000000000000
[  215.938988] R10: 0000000000000001 R11: ffff88003a26aca0 R12: 0000000000000030
[  215.945835] R13: 0000000000000000 R14: ffff88002b49b400 R15: 0000000000000001
[  215.952652] FS:  00007f695c355700(0000) GS:ffff88003f8c0000(0000) knlGS:0000000000000000
[  215.959476] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[  215.966165] CR2: 00007faa79583000 CR3: 0000000032a8f000 CR4: 0000000000000660
[  215.972789] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  215.979339] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  215.985844] Process netback/3 (pid: 1182, threadinfo ffff880037928000, task ffff880037ced190)
[  215.992486] Stack:
[  215.999085]  ffff880037929d1c ffff880037928010 ffff880037929d00 ffff880037929c80
[  216.005896]  ffffffff810800b5 00000000000000ba ffffc900108466e0 ffffc90010841b78
[  216.012651]  0000000101080083 ffffc90010841b28 0000000100000000 ffff880031a869c0
[  216.019386] Call Trace:
[  216.026026]  [] ? __alloc_workqueue_key+0x265/0x5d0
[  216.032830]  [] ? trace_hardirqs_on+0xd/0x10
[  216.039668]  [] xen_netbk_kthread+0xba/0xa90
[  216.046435]  [] ? try_to_wake_up+0x1b6/0x310
[  216.053094]  [] ? wake_up_bit+0x40/0x40
[  216.059670]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
[  216.066279]  [] kthread+0xd6/0xe0
[  216.072817]  [] kernel_thread_helper+0x4/0x10
[  216.079308]  [] ? retint_restore_args+0x13/0x13
[  216.085783]  [] ? gs_change+0x13/0x13
[  216.092234] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 36 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7 
[  216.106108] RIP  [] xen_netbk_rx_action+0x89a/0x910
[  216.113118]  RSP 
[  216.120011] ---[ end trace 03f82ac72747fb5c ]---
[  219.765094] device vif14.0 entered promiscuous mode
[  220.062152] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
[  220.072238] xen_bridge: port 13(vif14.0) entered forwarding state
[  220.079416] xen_bridge: port 13(vif14.0) entered forwarding state
[  221.912781] xen_bridge: port 12(vif12.0) entered forwarding state
[  222.876167] netbk_gop_frag_copy: size 2c1 offset 1858
[  222.876167]  => 1b19 > 1000
[  222.889279] netbk_gop_frag_copy failed: skb frag 0 page
[  222.895959] copying from offset 1858, len 2c1
[  222.902484] page:ffffea0000b0a800 count:8 mapcount:0 mapping:          (null) index:0x7f40fec00
[  222.909119] page flags: 0x40000000004000(head)
[  222.915711] ------------[ cut here ]------------
[  222.922307] kernel BUG at drivers/net/xen-netback/netback.c:548!
[  222.928950] invalid opcode: 0000 [#4] PREEMPT SMP 
[  222.935546] Modules linked in:
[  222.942110] CPU 5 
[  222.942161] Pid: 1184, comm: netback/5 Tainted: G      D      3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)  
[  222.955415] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
[  222.962350] RSP: e02b:ffff88003792dc20  EFLAGS: 00010282
[  222.969198] RAX: 0000000000000001 RBX: ffff88002b4f4ce0 RCX: 0000000000000000
[  222.976119] RDX: ffff880037ceb0f0 RSI: 0000000000000001 RDI: ffff8800379202b0
[  222.982987] RBP: ffff88003792dd50 R08: 0000000000000002 R09: 0000000000000000
[  222.989869] R10: 0000000000000001 R11: ffff88003a26b380 R12: 0000000000000030
[  222.996658] R13: 0000000000000000 R14: ffff88002b5a7800 R15: 0000000000000001
[  223.003490] FS:  00007f71c6ce2740(0000) GS:ffff88003f940000(0000) knlGS:0000000000000000
[  223.010257] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[  223.016868] CR2: 00007f71c66b4d15 CR3: 0000000031f46000 CR4: 0000000000000660
[  223.023470] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  223.029999] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  223.036478] Process netback/5 (pid: 1184, threadinfo ffff88003792c000, task ffff880037ceb0f0)
[  223.043095] Stack:
[  223.049616]  ffff88003792dd1c ffff88003792c010 ffff88003792dd00 ffff88003792dc80
[  223.056404]  ffffffff810800b5 00000000000000ba ffffc9001085ce50 ffffc900108582e8
[  223.063150]  0000000101080083 ffffc90010858298 0000000100000000 ffff88002c38d9c0
[  223.069955] Call Trace:
[  223.076591]  [] ? __alloc_workqueue_key+0x265/0x5d0
[  223.083426]  [] ? trace_hardirqs_on+0xd/0x10
[  223.090261]  [] xen_netbk_kthread+0xba/0xa90
[  223.096990]  [] ? try_to_wake_up+0x1b6/0x310
[  223.103620]  [] ? wake_up_bit+0x40/0x40
[  223.110195]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
[  223.116768]  [] kthread+0xd6/0xe0
[  223.123312]  [] kernel_thread_helper+0x4/0x10
[  223.129794]  [] ? retint_restore_args+0x13/0x13
[  223.136217]  [] ? gs_change+0x13/0x13
[  223.142658] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 36 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7 
[  223.156486] RIP  [] xen_netbk_rx_action+0x89a/0x910
[  223.163337]  RSP 
[  223.170212] ---[ end trace 03f82ac72747fb5d ]---
[  228.705439] device vif15.0 entered promiscuous mode
[  228.880399] device vif15.0-emu entered promiscuous mode
[  228.889286] xen_bridge: port 15(vif15.0-emu) entered forwarding state
[  228.895546] xen_bridge: port 15(vif15.0-emu) entered forwarding state
[  228.956267] vpn_bridge: port 1(vif13.0) entered forwarding state
[  229.119709] pciback 0000:06:00.0: restoring config space at offset 0x3c (was 0x100, writing 0x10a)
[  229.126644] pciback 0000:06:00.0: restoring config space at offset 0x10 (was 0x4, writing 0xf9a00004)
[  229.133434] pciback 0000:06:00.0: restoring config space at offset 0xc (was 0x0, writing 0x10)
[  234.170536] tty_init_dev: 15 callbacks suppressed
[  235.092664] xen_bridge: port 13(vif14.0) entered forwarding state
[  235.684229] device vif16.0 entered promiscuous mode
[  235.805155] device vif16.0-emu entered promiscuous mode
[  235.813948] xen_bridge: port 17(vif16.0-emu) entered forwarding state
[  235.820242] xen_bridge: port 17(vif16.0-emu) entered forwarding state
[  239.632852] xen_bridge: port 15(vif15.0-emu) entered disabled state
[  239.641629] xen_bridge: port 15(vif15.0-emu) entered disabled state
[  239.650288] device vif15.0-emu left promiscuous mode
[  239.658618] xen_bridge: port 15(vif15.0-emu) entered disabled state
[  240.982436] tty_init_dev: 15 callbacks suppressed
[  241.386562] xen-blkback:ring-ref 8, event-channel 25, protocol 1 (x86_64-abi)
[  241.400247] xen-blkback:ring-ref 9, event-channel 26, protocol 1 (x86_64-abi)
[  241.454701] xen_bridge: port 14(vif15.0) entered forwarding state
[  241.463330] xen_bridge: port 14(vif15.0) entered forwarding state
[  246.690393] xen_bridge: port 17(vif16.0-emu) entered disabled state
[  246.699042] xen_bridge: port 17(vif16.0-emu) entered disabled state
[  246.708731] device vif16.0-emu left promiscuous mode
[  246.717465] xen_bridge: port 17(vif16.0-emu) entered disabled state
[  249.449321] xen-blkback:ring-ref 8, event-channel 25, protocol 1 (x86_64-abi)
[  249.619531] xen_bridge: port 16(vif16.0) entered forwarding state
[  249.628307] xen_bridge: port 16(vif16.0) entered forwarding state
[  256.489967] xen_bridge: port 14(vif15.0) entered forwarding state
[  264.654183] xen_bridge: port 16(vif16.0) entered forwarding state
[  414.296535] tty_init_dev: 16 callbacks suppressed
[  458.898093] netbk_gop_frag_copy: size 5a8 offset 3602
[  458.898093]  => 3baa > 1000
[  458.920252] netbk_gop_frag_copy failed: skb frag 0 page
[  458.928746] copying from offset 3602, len 5a8
[  458.937114] page:ffffea0000ada800 count:32749 mapcount:0 mapping:          (null) index:0xffff88002b6a6100
[  458.945813] page flags: 0x40000000004000(head)
[  458.954314] ------------[ cut here ]------------
[  458.962655] kernel BUG at drivers/net/xen-netback/netback.c:548!
[  458.970929] invalid opcode: 0000 [#5] PREEMPT SMP 
[  458.979113] Modules linked in:
[  458.987128] CPU 1 
[  458.987178] Pid: 1180, comm: netback/1 Tainted: G      D      3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)  
[  459.003052] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
[  459.011121] RSP: e02b:ffff880037925c20  EFLAGS: 00010282
[  459.019135] RAX: 0000000000000001 RBX: ffff88002ab0bf00 RCX: 0000000000000000
[  459.027199] RDX: ffff8800398a30f0 RSI: 0000000000000001 RDI: ffff8800379202b0
[  459.035081] RBP: ffff880037925d50 R08: 0000000000000002 R09: 0000000000000000
[  459.042816] R10: 0000000000000001 R11: ffff88003a26bdb0 R12: 0000000000000030
[  459.050308] R13: 0000000000000000 R14: ffff88002b6a2e00 R15: 0000000000000001
[  459.057725] FS:  00007f8e25af5760(0000) GS:ffff88003f840000(0000) knlGS:0000000000000000
[  459.065052] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[  459.072248] CR2: 00007fe6b4d12fb0 CR3: 000000002c2f6000 CR4: 0000000000000660
[  459.079480] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  459.086512] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  459.093386] Process netback/1 (pid: 1180, threadinfo ffff880037924000, task ffff8800398a30f0)
[  459.100357] Stack:
[  459.107071]  ffff880037925d1c ffff880037924010 ffff880037925d00 ffff880037925c80
[  459.113808]  ffffffff810800b5 000000000000042a ffffc9001082ff70 ffffc9001082b408
[  459.120494]  0000000001080083 ffffc9001082b3b8 0000000000000000 ffff8800329249c0
[  459.127129] Call Trace:
[  459.133509]  [] ? __alloc_workqueue_key+0x265/0x5d0
[  459.140118]  [] ? trace_hardirqs_on+0xd/0x10
[  459.146604]  [] xen_netbk_kthread+0xba/0xa90
[  459.153504]  [] ? try_to_wake_up+0x1b6/0x310
[  459.159949]  [] ? wake_up_bit+0x40/0x40
[  459.166431]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
[  459.172778]  [] kthread+0xd6/0xe0
[  459.179018]  [] kernel_thread_helper+0x4/0x10
[  459.185291]  [] ? retint_restore_args+0x13/0x13
[  459.191523]  [] ? gs_change+0x13/0x13
[  459.197862] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 36 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7 
[  459.211184] RIP  [] xen_netbk_rx_action+0x89a/0x910
[  459.217785]  RSP 
[  459.224501] ---[ end trace 03f82ac72747fb5e ]---




> This made me notice that offset and len in the caller are variously
> unsigned int, u16 or u32 while gop_frag_copy takes them as unsigned
> longs. None of the numbers involved here are anywhere big enough to
> cause any sort of overflow related error though.

>> [  197.892781] page:ffffea0000b18400 count:3 mapcount:0 mapping:          (null) index:0x0
>> [  197.900778] page flags: 0x40000000004000(head)
>> [  197.907074] ------------[ cut here ]------------
>> [  197.913345] kernel BUG at drivers/net/xen-netback/netback.c:546!
>> [  197.919626] invalid opcode: 0000 [#1] PREEMPT SMP
>> [  197.921573] xen_bridge: port 10(vif10.0) entered forwarding state
>> [  197.932106] Modules linked in:
>> [  197.938370] CPU 0
>> [  197.938420] Pid: 1180, comm: netback/0 Not tainted 3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)
>> [  197.951203] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
>> [  197.957775] RSP: e02b:ffff880037911c20  EFLAGS: 00010282
>> [  197.964290] RAX: 0000000000000001 RBX: ffff880036862ee0 RCX: 0000000000000000
>> [  197.970956] RDX: 0000000000000001 RSI: 0000000000000001 RDI: ffff8800379102b0
>> [  197.977679] RBP: ffff880037911d50 R08: 0000000000000002 R09: 0000000000000000
>> [  197.984361] R10: 0000000000000001 R11: ffff880039925e40 R12: 0000000000000030
>> [  197.990958] R13: 0000000000000000 R14: ffff880031e71800 R15: 0000000000000001
>> [  197.997459] FS:  00007fb5dfcf7700(0000) GS:ffff88003f800000(0000) knlGS:0000000000000000
>> [  198.004123] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
>> [  198.010827] CR2: 00007fb5d802d000 CR3: 0000000031fd3000 CR4: 0000000000000660
>> [  198.017534] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> [  198.024168] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>> [  198.030717] Process netback/0 (pid: 1180, threadinfo ffff880037910000, task ffff88003997d190)
>> [  198.037326] Stack:
>> [  198.043817]  ffff880037911d1c ffff88003997d840 ffff880037911d00 ffff880037911c80
>> [  198.050573]  ffffffff00000001 0000000000000662 ffffc90010824bb8 ffffc90010820050
>> [  198.057413]  0000000001080083 ffffc90010820000 0000000000000000 ffff880031cf09c0
>> [  198.064228] Call Trace:
>> [  198.070887]  [] ? trace_hardirqs_on+0xd/0x10
>> [  198.077604]  [] xen_netbk_kthread+0xba/0xa90
>> [  198.084394]  [] ? try_to_wake_up+0x1b6/0x310
>> [  198.091109]  [] ? wake_up_bit+0x40/0x40
>> [  198.097726]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
>> [  198.104343]  [] kthread+0xd6/0xe0
>> [  198.111001]  [] kernel_thread_helper+0x4/0x10
>> [  198.117737]  [] ? retint_restore_args+0x13/0x13
>> [  198.124425]  [] ? gs_change+0x13/0x13
>> [  198.131008] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 46 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7
>> [  198.145094] RIP  [] xen_netbk_rx_action+0x89a/0x910
>> [  198.152192]  RSP 
>> [  198.159344] ---[ end trace cbdd0e4e80268fa8 ]---
>> [  199.703539] tty_init_dev: 2 callbacks suppressed
>> [  200.712098] device vif12.0 entered promiscuous mode
>> [  201.010433] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
>> [  201.020644] xen_bridge: port 12(vif12.0) entered forwarding state
>> [  201.027833] xen_bridge: port 12(vif12.0) entered forwarding state
>> [  206.774576] netbk_gop_frag_copy failed: skb frag 0 page
>> [  206.777945] device vif13.0 entered promiscuous mode
>> [  206.788845] copying from offset 1ba4, len 2c1
>> [  206.795791] page:ffffea0000b18400 count:6 mapcount:0 mapping:          (null) index:0x0
>> [  206.802771] page flags: 0x40000000004000(head)
>> [  206.809619] ------------[ cut here ]------------
>> [  206.816498] kernel BUG at drivers/net/xen-netback/netback.c:546!
>> [  206.823465] invalid opcode: 0000 [#2] PREEMPT SMP
>> [  206.830354] Modules linked in:
>> [  206.837176] CPU 3
>> [  206.837234] Pid: 1183, comm: netback/3 Tainted: G      D      3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)
>> [  206.850881] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
>> [  206.857935] RSP: e02b:ffff880037917c20  EFLAGS: 00010282
>> [  206.864972] RAX: 0000000000000001 RBX: ffff880003313ae0 RCX: 0000000000000000
>> [  206.872049] RDX: ffff88003997b0f0 RSI: 0000000000000001 RDI: ffff8800379102b0
>> [  206.879147] RBP: ffff880037917d50 R08: 0000000000000002 R09: 0000000000000000
>> [  206.886242] R10: 0000000000000001 R11: ffff880039925640 R12: 0000000000000030
>> [  206.893163] R13: 0000000000000000 R14: ffff88002c7c4400 R15: 0000000000000001
>> [  206.900041] FS:  00007f800341a700(0000) GS:ffff88003f8c0000(0000) knlGS:0000000000000000
>> [  206.907145] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
>> [  206.914126] CR2: 00007f8002b31fb0 CR3: 0000000001c0b000 CR4: 0000000000000660
>> [  206.921181] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> [  206.927996] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>> [  206.934711] Process netback/3 (pid: 1183, threadinfo ffff880037916000, task ffff88003997b0f0)
>> [  206.941494] Stack:
>> [  206.948105]  ffff880037917d1c ffff880037916010 ffff880037917d00 ffff880037917c80
>> [  206.955062]  ffffffff810800b5 00000000000000ba ffffc900108466e0 ffffc90010841b78
>> [  206.962007]  0000000101080083 ffffc90010841b28 0000000100000000 ffff88002c5bb9c0
>> [  206.968967] Call Trace:
>> [  206.975830]  [] ? __alloc_workqueue_key+0x265/0x5d0
>> [  206.982789]  [] ? trace_hardirqs_on+0xd/0x10
>> [  206.989662]  [] xen_netbk_kthread+0xba/0xa90
>> [  206.996570]  [] ? try_to_wake_up+0x1b6/0x310
>> [  207.003523]  [] ? wake_up_bit+0x40/0x40
>> [  207.010333]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
>> [  207.017171]  [] kthread+0xd6/0xe0
>> [  207.023890]  [] kernel_thread_helper+0x4/0x10
>> [  207.030540]  [] ? retint_restore_args+0x13/0x13
>> [  207.037275]  [] ? gs_change+0x13/0x13
>> [  207.043890] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 46 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7
>> [  207.057976] RIP  [] xen_netbk_rx_action+0x89a/0x910
>> [  207.065064]  RSP 
>> [  207.072056] ---[ end trace cbdd0e4e80268fa9 ]---
>> [  207.079366] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
>> [  207.090256] vpn_bridge: port 1(vif13.0) entered forwarding state
>> [  207.097403] vpn_bridge: port 1(vif13.0) entered forwarding state
>> [  208.636257] xen_bridge: port 11(vif11.0) entered forwarding state
>> [  211.515779] netbk_gop_frag_copy failed: skb frag 0 page
>> [  211.522711] copying from offset 2126, len 2c1
>> [  211.529403] page:ffffea0000b18400 count:8 mapcount:0 mapping:          (null) index:0x0
>> [  211.536142] page flags: 0x40000000004000(head)
>> [  211.542942] ------------[ cut here ]------------
>> [  211.549664] kernel BUG at drivers/net/xen-netback/netback.c:546!
>> [  211.556408] invalid opcode: 0000 [#3] PREEMPT SMP
>> [  211.563168] Modules linked in:
>> [  211.569739] CPU 4
>> [  211.569789] Pid: 1184, comm: netback/4 Tainted: G      D      3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)
>> [  211.583126] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
>> [  211.590041] RSP: e02b:ffff880037921c20  EFLAGS: 00010282
>> [  211.596868] RAX: 0000000000000001 RBX: ffff8800375bc4e0 RCX: 0000000000000000
>> [  211.603890] RDX: ffff88003997a0a0 RSI: 0000000000000001 RDI: ffff8800379202b0
>> [  211.610792] RBP: ffff880037921d50 R08: 0000000000000002 R09: 0000000000000000
>> [  211.617608] R10: 0000000000000001 R11: ffff8800399249e0 R12: 0000000000000030
>> [  211.624537] R13: 0000000000000000 R14: ffff88002b98d400 R15: 0000000000000001
>> [  211.631302] FS:  00007f332d735740(0000) GS:ffff88003f900000(0000) knlGS:0000000000000000
>> [  211.638090] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
>> [  211.644965] CR2: 00007f1023d22000 CR3: 0000000031fba000 CR4: 0000000000000660
>> [  211.651894] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> [  211.658652] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>> [  211.665288] Process netback/4 (pid: 1184, threadinfo ffff880037920000, task ffff88003997a0a0)
>> [  211.671884] Stack:
>> [  211.678376]  ffff880037921d1c ffff880037920010 ffff880037921d00 ffff880037921c80
>> [  211.685145]  ffffffff810800b5 00000000000000ba ffffc90010851a98 ffffc9001084cf30
>> [  211.691837]  0000000101080083 ffffc9001084cee0 0000000100000000 ffff88002c5bd9c0
>> [  211.698581] Call Trace:
>> [  211.705349]  [] ? __alloc_workqueue_key+0x265/0x5d0
>> [  211.712156]  [] ? trace_hardirqs_on+0xd/0x10
>> [  211.718907]  [] xen_netbk_kthread+0xba/0xa90
>> [  211.725654]  [] ? try_to_wake_up+0x1b6/0x310
>> [  211.732369]  [] ? wake_up_bit+0x40/0x40
>> [  211.739111]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
>> [  211.745858]  [] kthread+0xd6/0xe0
>> [  211.752449]  [] kernel_thread_helper+0x4/0x10
>> [  211.758975]  [] ? retint_restore_args+0x13/0x13
>> [  211.765575]  [] ? gs_change+0x13/0x13
>> [  211.772016] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 46 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7
>> [  211.785816] RIP  [] xen_netbk_rx_action+0x89a/0x910
>> [  211.792586]  RSP 
>> [  211.799394] ---[ end trace cbdd0e4e80268faa ]---
>> [  212.852714] device vif14.0 entered promiscuous mode
>> [  213.234995] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
>> [  213.245054] xen_bridge: port 13(vif14.0) entered forwarding state
>> [  213.252087] xen_bridge: port 13(vif14.0) entered forwarding state
>> [  214.691532] netbk_gop_frag_copy failed: skb frag 0 page
>> [  214.698515] copying from offset 26a8, len 2c1
>> [  214.705472] page:ffffea0000b18400 count:10 mapcount:0 mapping:          (null) index:0x0
>> [  214.712415] page flags: 0x40000000004000(head)
>> [  214.719170] ------------[ cut here ]------------
>> [  214.725887] kernel BUG at drivers/net/xen-netback/netback.c:546!
>> [  214.732563] invalid opcode: 0000 [#4] PREEMPT SMP
>> [  214.739221] Modules linked in:
>> [  214.745808] CPU 5
>> [  214.745859] Pid: 1185, comm: netback/5 Tainted: G      D      3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)
>> [  214.759156] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
>> [  214.766127] RSP: e02b:ffff880037923c20  EFLAGS: 00010282
>> [  214.773012] RAX: 0000000000000001 RBX: ffff8800379172e0 RCX: 0000000000000000
>> [  214.780010] RDX: ffff880039ac8000 RSI: 0000000000000001 RDI: ffff8800379202b0
>> [  214.786988] RBP: ffff880037923d50 R08: 0000000000000002 R09: 0000000000000000
>> [  214.793870] R10: 0000000000000001 R11: ffff880039924460 R12: 0000000000000030
>> [  214.800812] R13: 0000000000000000 R14: ffff88002b8b4800 R15: 0000000000000001
>> [  214.807668] FS:  00007f236d331700(0000) GS:ffff88003f940000(0000) knlGS:0000000000000000
>> [  214.814545] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
>> [  214.821415] CR2: 00007f236c42b6b0 CR3: 0000000039275000 CR4: 0000000000000660
>> [  214.828435] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> [  214.835337] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>> [  214.841963] Process netback/5 (pid: 1185, threadinfo ffff880037922000, task ffff880039ac8000)
>> [  214.848655] Stack:
>> [  214.855220]  ffff880037923d1c ffff880037922010 ffff880037923d00 ffff880037923c80
>> [  214.861945]  ffffffff810800b5 00000000000000ba ffffc9001085ce50 ffffc900108582e8
>> [  214.868699]  0000000101080083 ffffc90010858298 0000000100000000 ffff880031e939c0
>> [  214.875477] Call Trace:
>> [  214.882247]  [] ? __alloc_workqueue_key+0x265/0x5d0
>> [  214.889083]  [] ? trace_hardirqs_on+0xd/0x10
>> [  214.895851]  [] xen_netbk_kthread+0xba/0xa90
>> [  214.902612]  [] ? try_to_wake_up+0x1b6/0x310
>> [  214.909343]  [] ? wake_up_bit+0x40/0x40
>> [  214.916115]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
>> [  214.922856]  [] kthread+0xd6/0xe0
>> [  214.929527]  [] kernel_thread_helper+0x4/0x10
>> [  214.936178]  [] ? retint_restore_args+0x13/0x13
>> [  214.942781]  [] ? gs_change+0x13/0x13
>> [  214.949279] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 46 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7
>> [  214.963107] RIP  [] xen_netbk_rx_action+0x89a/0x910
>> [  214.969952]  RSP 
>> [  214.976802] ---[ end trace cbdd0e4e80268fab ]---
>> [  216.045946] xen_bridge: port 12(vif12.0) entered forwarding state
>> [  220.405869] device vif15.0 entered promiscuous mode
>> [  220.607946] device vif15.0-emu entered promiscuous mode
>> [  220.625075] xen_bridge: port 15(vif15.0-emu) entered forwarding state
>> [  220.633333] xen_bridge: port 15(vif15.0-emu) entered forwarding state
>> [  220.890237] pciback 0000:06:00.0: restoring config space at offset 0x3c (was 0x100, writing 0x10a)
>> [  220.898814] pciback 0000:06:00.0: restoring config space at offset 0x10 (was 0x4, writing 0xf9a00004)
>> [  220.907406] pciback 0000:06:00.0: restoring config space at offset 0xc (was 0x0, writing 0x10)
>> [  222.122750] vpn_bridge: port 1(vif13.0) entered forwarding state
>> [  225.943971] tty_init_dev: 14 callbacks suppressed
>> [  226.654618] device vif16.0 entered promiscuous mode
>> [  226.775073] device vif16.0-emu entered promiscuous mode
>> [  226.784025] xen_bridge: port 17(vif16.0-emu) entered forwarding state
>> [  226.790188] xen_bridge: port 17(vif16.0-emu) entered forwarding state
>> [  228.253024] xen_bridge: port 13(vif14.0) entered forwarding state
>> [  229.788197] xen_bridge: port 15(vif15.0-emu) entered disabled state
>> [  229.796826] xen_bridge: port 15(vif15.0-emu) entered disabled state
>> [  229.805243] device vif15.0-emu left promiscuous mode
>> [  229.813385] xen_bridge: port 15(vif15.0-emu) entered disabled state
>> [  231.558329] xen-blkback:ring-ref 8, event-channel 25, protocol 1 (x86_64-abi)
>> [  231.569080] xen-blkback:ring-ref 9, event-channel 26, protocol 1 (x86_64-abi)
>> [  231.609663] xen_bridge: port 14(vif15.0) entered forwarding state
>> [  231.617943] xen_bridge: port 14(vif15.0) entered forwarding state
>> [  231.934347] tty_init_dev: 25 callbacks suppressed
>> 
>> 
>> 
>> 
>> 
>> 
>> > Ian.
>> 
>> > diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
>> > index 05593d8..ca4c47d 100644
>> > --- a/drivers/net/xen-netback/netback.c
>> > +++ b/drivers/net/xen-netback/netback.c
>> > @@ -386,7 +386,7 @@ static struct netbk_rx_meta *get_next_rx_buffer(struct xenvif *vif,
>> >   * Set up the grant operations for this fragment. If it's a flipping
>> >   * interface, we also set up the unmap request from here.
>> >   */
>> > -static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
>> > +static int netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
>> >                                 struct netrx_pending_operations *npo,
>> >                                 struct page *page, unsigned long size,
>> >                                 unsigned long offset, int *head)
>> > @@ -402,7 +402,8 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
>> >         unsigned long bytes;
>> >
>> >         /* Data must not cross a page boundary. */
>> > -       BUG_ON(size + offset > PAGE_SIZE);
>> > +       if (size + offset > PAGE_SIZE)
>> > +               return -1;
>> >
>> >         meta = npo->meta + npo->meta_prod - 1;
>> >
>> > @@ -459,6 +460,7 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
>> >                 *head = 0; /* There must be something in this buffer now. */
>> >
>> >         }
>> > +       return 0;
>> >  }
>> >
>> >  /*
>> > @@ -517,17 +519,31 @@ static int netbk_gop_skb(struct sk_buff *skb,
>> >                 if (data + len > skb_tail_pointer(skb))
>> >                         len = skb_tail_pointer(skb) - data;
>> >
>> > -               netbk_gop_frag_copy(vif, skb, npo,
>> > -                                   virt_to_page(data), len, offset, &head);
>> > +               if (netbk_gop_frag_copy(vif, skb, npo,
>> > +                               virt_to_page(data), len, offset, &head) < 0) {
>> > +printk(KERN_CRIT "netbk_gop_frag_copy failed: skb head %p-%p\n",
>> +       skb->>data, skb_tail_pointer);
>> > +printk(KERN_CRIT "copying from %p-%p, offset %x, len %x\n",
>> > +       data, data+len, offset, len);
>> > +dump_page(virt_to_page(data));
>> > +BUG();
>> > +               }
>> >                 data += len;
>> >         }
>> >
>> >         for (i = 0; i < nr_frags; i++) {
>> > -               netbk_gop_frag_copy(vif, skb, npo,
>> > +               if (netbk_gop_frag_copy(vif, skb, npo,
>> >                                     skb_frag_page(&skb_shinfo(skb)->frags[i]),
>> >                                     skb_frag_size(&skb_shinfo(skb)->frags[i]),
>> >                                     skb_shinfo(skb)->frags[i].page_offset,
>> > -                                   &head);
>> > +                                   &head) < 0) {
>> > +printk(KERN_CRIT "netbk_gop_frag_copy failed: skb frag %d page\n", i);
>> > +printk(KERN_CRIT "copying from offset %x, len %x\n",
>> > +       skb_shinfo(skb)->frags[i].page_offset,
>> > +       skb_frag_size(&skb_shinfo(skb)->frags[i]));
>> > +dump_page(skb_frag_page(&skb_shinfo(skb)->frags[i]));
>> > +BUG();
>> > +               }
>> >         }
>> >
>> >         return npo->meta_prod - old_meta_prod;
>> 
>> 
>> 
>> 





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 11:09:22 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 11:09:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLXg9-0001xF-8S; Tue, 09 Oct 2012 11:08:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLXg7-0001x3-Pb
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 11:08:47 +0000
Received: from [85.158.143.35:28155] by server-1.bemta-4.messagelabs.com id
	A0/E9-05684-FB504705; Tue, 09 Oct 2012 11:08:47 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1349780875!4521946!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21625 invoked from network); 9 Oct 2012 11:07:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 11:07:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; 
	d="asc'?scan'208";a="15034332"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 11:07:54 +0000
Received: from [IPv6:::1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	12:07:54 +0100
Message-ID: <1349780874.3610.89.camel@Abyss>
From: Dario Faggioli 
To: Ian Jackson 
Date: Tue, 9 Oct 2012 12:07:54 +0100
In-Reply-To: <20591.3218.46221.931473@mariner.uk.xensource.com>
References: 
	<7fba2d9044e720770c25.1349446106@Solace>
	<20591.3218.46221.931473@mariner.uk.xensource.com>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
MIME-Version: 1.0
Cc: Marcus Granado ,
	Andre Przywara ,
	Ian Campbell ,
	Anil Madhavapeddy , George
	Dunlap ,
	Andrew Cooper ,
	Juergen Gross ,
	"xen-devel@lists.xen.org" ,
	Jan Beulich , Daniel
	De Graaf , Matt Wilson 
Subject: Re: [Xen-devel] [PATCH 8 of 8] xl: add node-affinity to the output
 of `xl list`
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============7314791512416051730=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7314791512416051730==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-RUZDGG5sN6M8BCPTQXOQ"

--=-RUZDGG5sN6M8BCPTQXOQ
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-10-05 at 17:36 +0100, Ian Jackson wrote:=20
> > +static void print_bitmap(uint8_t *map, int maplen, FILE *stream, int c=
pu_node)
> > +{
> > +    int i;
> > +    uint8_t pmap =3D 0, bitmask =3D 0;
> > +    int firstset =3D 0, state =3D 0;
> > +
> > ...
>=20
> Is this business with a state variable really the least opaque way of
> writing this ?  Oh I see you're just moving it about.  Oh well..
>=20
I don't think it's any opaque and, yes, I'm mostly moving that
print_bitmap function up in the file, but the new status variable is
mine (guilty ass charge :-D).

Honestly, despite the fact that the function is called print_bitmap(),
it contains the following code:

        case 1:
            if (firstset =3D=3D 0) {
                fprintf(stream, "any cpu");
                break;
            }
        case 3:

Which is what made me thinking that opacity was not its first concern in
the first place, and that turning it into being opaque was none of this
change's business. :-)

However, I see your point... Perhaps I can add two functions (something
like print_{cpumap,nodemap}()), both calling the original
print_bitmap(), and deal with the "any {cpu,node}" case within them...=20

Do you like that better?

Thanks and Regards,
Dario

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-RUZDGG5sN6M8BCPTQXOQ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlB0BYoACgkQk4XaBE3IOsSAJQCeKtmCmYrjv1iWZGwtmCmEnb+A
Qj8An0eYRng5YrJK/T+ITiE/OJSNyxeS
=cMWj
-----END PGP SIGNATURE-----

--=-RUZDGG5sN6M8BCPTQXOQ--


--===============7314791512416051730==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7314791512416051730==--


From xen-devel-bounces@lists.xen.org Tue Oct 09 11:09:22 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 11:09:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLXg9-0001xF-8S; Tue, 09 Oct 2012 11:08:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLXg7-0001x3-Pb
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 11:08:47 +0000
Received: from [85.158.143.35:28155] by server-1.bemta-4.messagelabs.com id
	A0/E9-05684-FB504705; Tue, 09 Oct 2012 11:08:47 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1349780875!4521946!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21625 invoked from network); 9 Oct 2012 11:07:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 11:07:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; 
	d="asc'?scan'208";a="15034332"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 11:07:54 +0000
Received: from [IPv6:::1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	12:07:54 +0100
Message-ID: <1349780874.3610.89.camel@Abyss>
From: Dario Faggioli 
To: Ian Jackson 
Date: Tue, 9 Oct 2012 12:07:54 +0100
In-Reply-To: <20591.3218.46221.931473@mariner.uk.xensource.com>
References: 
	<7fba2d9044e720770c25.1349446106@Solace>
	<20591.3218.46221.931473@mariner.uk.xensource.com>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
MIME-Version: 1.0
Cc: Marcus Granado ,
	Andre Przywara ,
	Ian Campbell ,
	Anil Madhavapeddy , George
	Dunlap ,
	Andrew Cooper ,
	Juergen Gross ,
	"xen-devel@lists.xen.org" ,
	Jan Beulich , Daniel
	De Graaf , Matt Wilson 
Subject: Re: [Xen-devel] [PATCH 8 of 8] xl: add node-affinity to the output
 of `xl list`
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============7314791512416051730=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7314791512416051730==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-RUZDGG5sN6M8BCPTQXOQ"

--=-RUZDGG5sN6M8BCPTQXOQ
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-10-05 at 17:36 +0100, Ian Jackson wrote:=20
> > +static void print_bitmap(uint8_t *map, int maplen, FILE *stream, int c=
pu_node)
> > +{
> > +    int i;
> > +    uint8_t pmap =3D 0, bitmask =3D 0;
> > +    int firstset =3D 0, state =3D 0;
> > +
> > ...
>=20
> Is this business with a state variable really the least opaque way of
> writing this ?  Oh I see you're just moving it about.  Oh well..
>=20
I don't think it's any opaque and, yes, I'm mostly moving that
print_bitmap function up in the file, but the new status variable is
mine (guilty ass charge :-D).

Honestly, despite the fact that the function is called print_bitmap(),
it contains the following code:

        case 1:
            if (firstset =3D=3D 0) {
                fprintf(stream, "any cpu");
                break;
            }
        case 3:

Which is what made me thinking that opacity was not its first concern in
the first place, and that turning it into being opaque was none of this
change's business. :-)

However, I see your point... Perhaps I can add two functions (something
like print_{cpumap,nodemap}()), both calling the original
print_bitmap(), and deal with the "any {cpu,node}" case within them...=20

Do you like that better?

Thanks and Regards,
Dario

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-RUZDGG5sN6M8BCPTQXOQ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlB0BYoACgkQk4XaBE3IOsSAJQCeKtmCmYrjv1iWZGwtmCmEnb+A
Qj8An0eYRng5YrJK/T+ITiE/OJSNyxeS
=cMWj
-----END PGP SIGNATURE-----

--=-RUZDGG5sN6M8BCPTQXOQ--


--===============7314791512416051730==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7314791512416051730==--


From xen-devel-bounces@lists.xen.org Tue Oct 09 11:11:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 11:11:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLXi7-00025t-P1; Tue, 09 Oct 2012 11:10:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLXi6-00025n-KO
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 11:10:50 +0000
Received: from [85.158.138.51:7089] by server-5.bemta-3.messagelabs.com id
	B0/D5-00589-93604705; Tue, 09 Oct 2012 11:10:49 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1349781048!33649514!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9353 invoked from network); 9 Oct 2012 11:10:49 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 11:10:49 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so3654178eek.32
	for ; Tue, 09 Oct 2012 04:10:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=jKNuodYzSxlyH0KJHhl/mbWHMjnG0FlfFSRwqqHc/LM=;
	b=WfbF2r50xoRiJZBzgxwGygTlrrPEzxDZHp9mT5/U4/05vWt5hcTatac7OM+GHo8J24
	Km7KT3CRNb88buEZoce4G5h0stqj1LSJeNo/HOB78Negm1PKLb7xlYgbk+Jmkd392vqy
	jxCou+URZ+nD1xwfPYhw0KomkolzQdy6qVakcF2iVQL+LbcP3+3z6bDXTDMSjVfbjIC0
	75ezbERxdzACq7EbPnjJVUMl0Ow84viEV0ZrTYmUJuHATJRCf7VPecLe9SNL0fw5oA9B
	MscQca1eLSMHNSmN0f1WsNnCzDsXiYirG5h4aPmIiemagR4QeDlQafC6gB+ocV5DsHi/
	tQ/w==
Received: by 10.14.0.68 with SMTP id 44mr5896151eea.1.1349781048791;
	Tue, 09 Oct 2012 04:10:48 -0700 (PDT)
Received: from [192.168.1.69]
	(host86-183-156-141.range86-183.btcentralplus.com. [86.183.156.141])
	by mx.google.com with ESMTPS id c6sm33760379eep.17.2012.10.09.04.10.39
	(version=SSLv3 cipher=OTHER); Tue, 09 Oct 2012 04:10:47 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 09 Oct 2012 12:10:37 +0100
From: Keir Fraser 
To: Dario Faggioli , Jan Beulich 
Message-ID: 
Thread-Topic: [Xen-devel] [PATCH 3 of 8] xen: let the (credit) scheduler know
	about `node affinity`
Thread-Index: Ac2mDrWX1ZrpbUzY9UWZ3qdpj5ffCA==
In-Reply-To: <1349778541.3610.62.camel@Abyss>
Mime-version: 1.0
Cc: Andre Przywara ,
	Ian Campbell ,
	Marcus Granado ,
	George Dunlap ,
	Andrew Cooper ,
	Juergen Gross ,
	Anil Madhavapeddy ,
	Ian Jackson , xen-devel@lists.xen.org,
	Matt Wilson , Daniel De Graaf 
Subject: Re: [Xen-devel] [PATCH 3 of 8] xen: let the (credit) scheduler know
 about `node affinity`
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/10/2012 11:29, "Dario Faggioli"  wrote:

> On Fri, 2012-10-05 at 15:25 +0100, Jan Beulich wrote:
>>>>> On 05.10.12 at 16:08, Dario Faggioli  wrote:
>>> @@ -287,22 +344,26 @@ static inline void
>>>          }
>>>          else
>>>          {
>>> -            cpumask_t idle_mask;
>>> +            cpumask_t idle_mask, balance_mask;
>> 
>> Be _very_ careful about adding on-stack CPU mask variables
>> (also further below): each one of them grows the stack frame
>> by 512 bytes (when building for the current maximum of 4095
>> CPUs), which is generally too much; you may want to consider
>> pre-allocated scratch space instead.
>> 
> I see your point, and I think you're right... I wasn't "thinking that
> big". :-)
> 
> I'll look into all of these situations and see if I can move the masks
> off the stack. Any preference between global variables and members of
> one of the scheduler's data structures?

Since multiple instances of the scheduler can be active, across multiple cpu
pools, surely they have to be allocated in the per-scheduler-instance
structures? Or dynamically xmalloc'ed just in the scope they are needed.

 -- Keir

> Thanks and Regards,
> Dario



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 11:11:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 11:11:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLXi7-00025t-P1; Tue, 09 Oct 2012 11:10:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLXi6-00025n-KO
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 11:10:50 +0000
Received: from [85.158.138.51:7089] by server-5.bemta-3.messagelabs.com id
	B0/D5-00589-93604705; Tue, 09 Oct 2012 11:10:49 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1349781048!33649514!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9353 invoked from network); 9 Oct 2012 11:10:49 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 11:10:49 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so3654178eek.32
	for ; Tue, 09 Oct 2012 04:10:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=jKNuodYzSxlyH0KJHhl/mbWHMjnG0FlfFSRwqqHc/LM=;
	b=WfbF2r50xoRiJZBzgxwGygTlrrPEzxDZHp9mT5/U4/05vWt5hcTatac7OM+GHo8J24
	Km7KT3CRNb88buEZoce4G5h0stqj1LSJeNo/HOB78Negm1PKLb7xlYgbk+Jmkd392vqy
	jxCou+URZ+nD1xwfPYhw0KomkolzQdy6qVakcF2iVQL+LbcP3+3z6bDXTDMSjVfbjIC0
	75ezbERxdzACq7EbPnjJVUMl0Ow84viEV0ZrTYmUJuHATJRCf7VPecLe9SNL0fw5oA9B
	MscQca1eLSMHNSmN0f1WsNnCzDsXiYirG5h4aPmIiemagR4QeDlQafC6gB+ocV5DsHi/
	tQ/w==
Received: by 10.14.0.68 with SMTP id 44mr5896151eea.1.1349781048791;
	Tue, 09 Oct 2012 04:10:48 -0700 (PDT)
Received: from [192.168.1.69]
	(host86-183-156-141.range86-183.btcentralplus.com. [86.183.156.141])
	by mx.google.com with ESMTPS id c6sm33760379eep.17.2012.10.09.04.10.39
	(version=SSLv3 cipher=OTHER); Tue, 09 Oct 2012 04:10:47 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 09 Oct 2012 12:10:37 +0100
From: Keir Fraser 
To: Dario Faggioli , Jan Beulich 
Message-ID: 
Thread-Topic: [Xen-devel] [PATCH 3 of 8] xen: let the (credit) scheduler know
	about `node affinity`
Thread-Index: Ac2mDrWX1ZrpbUzY9UWZ3qdpj5ffCA==
In-Reply-To: <1349778541.3610.62.camel@Abyss>
Mime-version: 1.0
Cc: Andre Przywara ,
	Ian Campbell ,
	Marcus Granado ,
	George Dunlap ,
	Andrew Cooper ,
	Juergen Gross ,
	Anil Madhavapeddy ,
	Ian Jackson , xen-devel@lists.xen.org,
	Matt Wilson , Daniel De Graaf 
Subject: Re: [Xen-devel] [PATCH 3 of 8] xen: let the (credit) scheduler know
 about `node affinity`
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/10/2012 11:29, "Dario Faggioli"  wrote:

> On Fri, 2012-10-05 at 15:25 +0100, Jan Beulich wrote:
>>>>> On 05.10.12 at 16:08, Dario Faggioli  wrote:
>>> @@ -287,22 +344,26 @@ static inline void
>>>          }
>>>          else
>>>          {
>>> -            cpumask_t idle_mask;
>>> +            cpumask_t idle_mask, balance_mask;
>> 
>> Be _very_ careful about adding on-stack CPU mask variables
>> (also further below): each one of them grows the stack frame
>> by 512 bytes (when building for the current maximum of 4095
>> CPUs), which is generally too much; you may want to consider
>> pre-allocated scratch space instead.
>> 
> I see your point, and I think you're right... I wasn't "thinking that
> big". :-)
> 
> I'll look into all of these situations and see if I can move the masks
> off the stack. Any preference between global variables and members of
> one of the scheduler's data structures?

Since multiple instances of the scheduler can be active, across multiple cpu
pools, surely they have to be allocated in the per-scheduler-instance
structures? Or dynamically xmalloc'ed just in the scope they are needed.

 -- Keir

> Thanks and Regards,
> Dario



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 11:30:21 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 11:30:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLY0i-0002MW-Im; Tue, 09 Oct 2012 11:30:04 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLY0h-0002MR-95
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 11:30:03 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1349782197!9288066!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 908 invoked from network); 9 Oct 2012 11:29:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 11:29:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15034884"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 11:29:42 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 9 Oct 2012 12:29:42 +0100
Date: Tue, 9 Oct 2012 12:28:37 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1349780111.21847.146.camel@zakaz.uk.xensource.com>
Message-ID: 
References: <1343057360.5797.59.camel@zakaz.uk.xensource.com>
	<1343057475-9258-2-git-send-email-ian.campbell@citrix.com>
	
	<1349780111.21847.146.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" ,
	"Tim \(Xen.org\)" , David Vrabel ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH V2 2/3] libxc: add ARM support to xc_dom (PV
 domain building)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 9 Oct 2012, Ian Campbell wrote:
> On Thu, 2012-07-26 at 17:30 +0100, Stefano Stabellini wrote:
> > On Mon, 23 Jul 2012, Ian Campbell wrote:
> > > Includes ARM zImage support.
> > >
> > > Signed-off-by: Ian Campbell 
> > > ---
> > > v2:
> > >  - add comments for rambase_pfn and p2m_host to clarify usage
> > >  - remove opencoded guest base address of 0x80000000 (still hardcoded, but now
> > >    with a comment!).
> > >  - comments around Linux boot protocol setup.
> > 
> > It looks better now.
> > I think we should take it as is, and then replace ntohl with
> > be32_to_cpu when we have it.
> 
> Can I take that as an Ack of the reposted version in
> <1349433507-21148-2-git-send-email-ian.campbell@citrix.com> 
> ?

yes

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 11:30:21 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 11:30:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLY0i-0002MW-Im; Tue, 09 Oct 2012 11:30:04 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLY0h-0002MR-95
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 11:30:03 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1349782197!9288066!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 908 invoked from network); 9 Oct 2012 11:29:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 11:29:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15034884"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 11:29:42 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 9 Oct 2012 12:29:42 +0100
Date: Tue, 9 Oct 2012 12:28:37 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1349780111.21847.146.camel@zakaz.uk.xensource.com>
Message-ID: 
References: <1343057360.5797.59.camel@zakaz.uk.xensource.com>
	<1343057475-9258-2-git-send-email-ian.campbell@citrix.com>
	
	<1349780111.21847.146.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" ,
	"Tim \(Xen.org\)" , David Vrabel ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH V2 2/3] libxc: add ARM support to xc_dom (PV
 domain building)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 9 Oct 2012, Ian Campbell wrote:
> On Thu, 2012-07-26 at 17:30 +0100, Stefano Stabellini wrote:
> > On Mon, 23 Jul 2012, Ian Campbell wrote:
> > > Includes ARM zImage support.
> > >
> > > Signed-off-by: Ian Campbell 
> > > ---
> > > v2:
> > >  - add comments for rambase_pfn and p2m_host to clarify usage
> > >  - remove opencoded guest base address of 0x80000000 (still hardcoded, but now
> > >    with a comment!).
> > >  - comments around Linux boot protocol setup.
> > 
> > It looks better now.
> > I think we should take it as is, and then replace ntohl with
> > be32_to_cpu when we have it.
> 
> Can I take that as an Ack of the reposted version in
> <1349433507-21148-2-git-send-email-ian.campbell@citrix.com> 
> ?

yes

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 11:45:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 11:45:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLYFD-0002Xe-27; Tue, 09 Oct 2012 11:45:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLYFB-0002XZ-SD
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 11:45:02 +0000
Received: from [85.158.143.99:15320] by server-2.bemta-4.messagelabs.com id
	E6/8A-06610-D3E04705; Tue, 09 Oct 2012 11:45:01 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1349783100!33458299!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 678 invoked from network); 9 Oct 2012 11:45:00 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 11:45:00 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so3678721eek.32
	for ; Tue, 09 Oct 2012 04:45:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=yJ8yEDoNNxXaIeQ+zKAjfTbgM/MVBNYPhpJYWzN1D0o=;
	b=dYodkj0Hqk9kZCgYy3GQoUerLpQ2q4K0JKKFf+YxvtusKmqWj8JLREb58/7PXfyfv3
	L2tebZUo3ZOuwQvSU5AmBCNfb+SxydERvE/d7AMoBESxgvTSAg+QC4L5idBmCZzqdMon
	S/xPZYHgkXDz33h2FMJ0p3UrBzf3eYqcJDoVX6YExG1uymHMP0jgjD71oz582gCpUT6E
	10HIdfI5885TB3JzDEKzNqsHmxlrnQZt+hBQjevjSuJ6D4Kn8DOT0K6urL2Nx4jDNbOs
	hy4J2UCPgwOh6izXvYB24JuFYUF9fvTtq+T89FHckFrthfpcoW5m09RP6iIy+1fTAq50
	LOPQ==
Received: by 10.14.193.129 with SMTP id k1mr26837677een.13.1349783100283;
	Tue, 09 Oct 2012 04:45:00 -0700 (PDT)
Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com.
	[86.183.156.141])
	by mx.google.com with ESMTPS id g5sm33904623eem.4.2012.10.09.04.44.58
	(version=SSLv3 cipher=OTHER); Tue, 09 Oct 2012 04:44:59 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Tue, 09 Oct 2012 12:44:56 +0100
From: Keir Fraser 
To: Andrew Cooper ,
	
Message-ID: 
Thread-Topic: [PATCH] irq: Remove irqaction.free_on_release
Thread-Index: Ac2mE4DauDWTSClw80K3Msj1WL6NEA==
In-Reply-To: <37f1afbec80b0f052aec.1349701772@andrewcoop.uk.xensource.com>
Mime-version: 1.0
Cc: Ian Campbell , Jan Beulich ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH] irq: Remove irqaction.free_on_release
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

But reasoning behind c/s 20153, which introduced it, still applies? Callers
using setup_irq() don't want their passed-in irqaction to be xfree()ed?

 -- Keir

On 08/10/2012 14:09, "Andrew Cooper"  wrote:

> It is always set to 1, and only checked on some of the codepaths which free an
> irqaction.
> 
> Signed-off-by: Andrew Cooper 
> 
> --
> This patch does touch common code as well as x86 and arm architectures,
> so probably needs quite a few acks.
> 
> diff -r 5fbdbf585f5f -r 37f1afbec80b xen/arch/arm/gic.c
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -373,7 +373,7 @@ void __init release_irq(unsigned int irq
>      /* Wait to make sure it's not being used on another CPU */
>      do { smp_mb(); } while ( desc->status & IRQ_INPROGRESS );
>  
> -    if (action && action->free_on_release)
> +    if ( action )
>          xfree(action);
>  }
>  
> diff -r 5fbdbf585f5f -r 37f1afbec80b xen/arch/arm/irq.c
> --- a/xen/arch/arm/irq.c
> +++ b/xen/arch/arm/irq.c
> @@ -97,7 +97,6 @@ int __init request_irq(unsigned int irq,
>      action->handler = handler;
>      action->name = devname;
>      action->dev_id = dev_id;
> -    action->free_on_release = 1;
>  
>      retval = setup_irq(irq, action);
>      if (retval)
> diff -r 5fbdbf585f5f -r 37f1afbec80b xen/arch/x86/irq.c
> --- a/xen/arch/x86/irq.c
> +++ b/xen/arch/x86/irq.c
> @@ -952,7 +952,6 @@ int __init request_irq(unsigned int irq,
>      action->handler = handler;
>      action->name = devname;
>      action->dev_id = dev_id;
> -    action->free_on_release = 1;
>  
>      retval = setup_irq(irq, action);
>      if (retval)
> @@ -979,7 +978,7 @@ void __init release_irq(unsigned int irq
>      /* Wait to make sure it's not being used on another CPU */
>      do { smp_mb(); } while ( desc->status & IRQ_INPROGRESS );
>  
> -    if (action && action->free_on_release)
> +    if ( action )
>          xfree(action);
>  }
>  
> diff -r 5fbdbf585f5f -r 37f1afbec80b xen/include/xen/irq.h
> --- a/xen/include/xen/irq.h
> +++ b/xen/include/xen/irq.h
> @@ -13,7 +13,6 @@ struct irqaction {
>      void (*handler)(int, void *, struct cpu_user_regs *);
>      const char *name;
>      void *dev_id;
> -    bool_t free_on_release;
>  };
>  
>  /*



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 11:45:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 11:45:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLYFD-0002Xe-27; Tue, 09 Oct 2012 11:45:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLYFB-0002XZ-SD
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 11:45:02 +0000
Received: from [85.158.143.99:15320] by server-2.bemta-4.messagelabs.com id
	E6/8A-06610-D3E04705; Tue, 09 Oct 2012 11:45:01 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1349783100!33458299!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 678 invoked from network); 9 Oct 2012 11:45:00 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 11:45:00 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so3678721eek.32
	for ; Tue, 09 Oct 2012 04:45:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=yJ8yEDoNNxXaIeQ+zKAjfTbgM/MVBNYPhpJYWzN1D0o=;
	b=dYodkj0Hqk9kZCgYy3GQoUerLpQ2q4K0JKKFf+YxvtusKmqWj8JLREb58/7PXfyfv3
	L2tebZUo3ZOuwQvSU5AmBCNfb+SxydERvE/d7AMoBESxgvTSAg+QC4L5idBmCZzqdMon
	S/xPZYHgkXDz33h2FMJ0p3UrBzf3eYqcJDoVX6YExG1uymHMP0jgjD71oz582gCpUT6E
	10HIdfI5885TB3JzDEKzNqsHmxlrnQZt+hBQjevjSuJ6D4Kn8DOT0K6urL2Nx4jDNbOs
	hy4J2UCPgwOh6izXvYB24JuFYUF9fvTtq+T89FHckFrthfpcoW5m09RP6iIy+1fTAq50
	LOPQ==
Received: by 10.14.193.129 with SMTP id k1mr26837677een.13.1349783100283;
	Tue, 09 Oct 2012 04:45:00 -0700 (PDT)
Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com.
	[86.183.156.141])
	by mx.google.com with ESMTPS id g5sm33904623eem.4.2012.10.09.04.44.58
	(version=SSLv3 cipher=OTHER); Tue, 09 Oct 2012 04:44:59 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Tue, 09 Oct 2012 12:44:56 +0100
From: Keir Fraser 
To: Andrew Cooper ,
	
Message-ID: 
Thread-Topic: [PATCH] irq: Remove irqaction.free_on_release
Thread-Index: Ac2mE4DauDWTSClw80K3Msj1WL6NEA==
In-Reply-To: <37f1afbec80b0f052aec.1349701772@andrewcoop.uk.xensource.com>
Mime-version: 1.0
Cc: Ian Campbell , Jan Beulich ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH] irq: Remove irqaction.free_on_release
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

But reasoning behind c/s 20153, which introduced it, still applies? Callers
using setup_irq() don't want their passed-in irqaction to be xfree()ed?

 -- Keir

On 08/10/2012 14:09, "Andrew Cooper"  wrote:

> It is always set to 1, and only checked on some of the codepaths which free an
> irqaction.
> 
> Signed-off-by: Andrew Cooper 
> 
> --
> This patch does touch common code as well as x86 and arm architectures,
> so probably needs quite a few acks.
> 
> diff -r 5fbdbf585f5f -r 37f1afbec80b xen/arch/arm/gic.c
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -373,7 +373,7 @@ void __init release_irq(unsigned int irq
>      /* Wait to make sure it's not being used on another CPU */
>      do { smp_mb(); } while ( desc->status & IRQ_INPROGRESS );
>  
> -    if (action && action->free_on_release)
> +    if ( action )
>          xfree(action);
>  }
>  
> diff -r 5fbdbf585f5f -r 37f1afbec80b xen/arch/arm/irq.c
> --- a/xen/arch/arm/irq.c
> +++ b/xen/arch/arm/irq.c
> @@ -97,7 +97,6 @@ int __init request_irq(unsigned int irq,
>      action->handler = handler;
>      action->name = devname;
>      action->dev_id = dev_id;
> -    action->free_on_release = 1;
>  
>      retval = setup_irq(irq, action);
>      if (retval)
> diff -r 5fbdbf585f5f -r 37f1afbec80b xen/arch/x86/irq.c
> --- a/xen/arch/x86/irq.c
> +++ b/xen/arch/x86/irq.c
> @@ -952,7 +952,6 @@ int __init request_irq(unsigned int irq,
>      action->handler = handler;
>      action->name = devname;
>      action->dev_id = dev_id;
> -    action->free_on_release = 1;
>  
>      retval = setup_irq(irq, action);
>      if (retval)
> @@ -979,7 +978,7 @@ void __init release_irq(unsigned int irq
>      /* Wait to make sure it's not being used on another CPU */
>      do { smp_mb(); } while ( desc->status & IRQ_INPROGRESS );
>  
> -    if (action && action->free_on_release)
> +    if ( action )
>          xfree(action);
>  }
>  
> diff -r 5fbdbf585f5f -r 37f1afbec80b xen/include/xen/irq.h
> --- a/xen/include/xen/irq.h
> +++ b/xen/include/xen/irq.h
> @@ -13,7 +13,6 @@ struct irqaction {
>      void (*handler)(int, void *, struct cpu_user_regs *);
>      const char *name;
>      void *dev_id;
> -    bool_t free_on_release;
>  };
>  
>  /*



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 12:32:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 12:32:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLYz1-0003Hw-IF; Tue, 09 Oct 2012 12:32:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLYz0-0003Hr-EB
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 12:32:22 +0000
Received: from [85.158.138.51:24817] by server-1.bemta-3.messagelabs.com id
	28/C6-16425-55914705; Tue, 09 Oct 2012 12:32:21 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1349785940!33168744!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13522 invoked from network); 9 Oct 2012 12:32:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 12:32:20 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15036613"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 12:32:19 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 9 Oct 2012 13:32:20 +0100
Date: Tue, 9 Oct 2012 13:31:14 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1349453467.20946.142.camel@zakaz.uk.xensource.com>
Message-ID: 
References: <1349363496.866.49.camel@zakaz.uk.xensource.com>
	<1349363515-26190-5-git-send-email-ian.campbell@citrix.com>
	
	<1349440338.20946.83.camel@zakaz.uk.xensource.com> 
	
	<1349447625.20946.130.camel@zakaz.uk.xensource.com>
	<1349453467.20946.142.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" ,
	Konrad Rzeszutek Wilk ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 05/14] xen: balloon: use correct type for
 frame_list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 5 Oct 2012, Ian Campbell wrote:
> On Fri, 2012-10-05 at 15:33 +0100, Ian Campbell wrote:
> > The issue you describe could only happen for a 32 bit HAP guest if the
> > guests was given > 16GB (2^(32+PAGE_SHIFT) bytes) of RAM and it was
> > explicitly trying to balloon memory over that limit, but in order for
> > that to even be possible it would already need to have made its concept
> > of a pfn larger than 32 bits.
> 
> The one place this might matter is in the privcmd
> IOCTL_PRIVCMD_MMAPBATCH interface for the *foreign* pfn (since a small
> dom0 needs to be able to build a big domU). Luckily that interface
> already uses xen_pfn_t, we just need to be a bit careful in the
> xen_remap_domain_mfn_range case, which Konrad tried to tell me already
> and he was right...
> 
> On ARM that meant the following (built but not executed) patch, I
> suspect the PVH variant needs similar treatment.

I think you are right


> 
> diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
> index ae05e56..ad87917 100644
> --- a/arch/arm/include/asm/xen/interface.h
> +++ b/arch/arm/include/asm/xen/interface.h
> @@ -43,6 +43,7 @@ DEFINE_GUEST_HANDLE(void);
>  DEFINE_GUEST_HANDLE(uint64_t);
>  DEFINE_GUEST_HANDLE(uint32_t);
>  DEFINE_GUEST_HANDLE(xen_pfn_t);
> +DEFINE_GUEST_HANDLE(xen_ulong_t);
>  
>  /* Maximum number of virtual CPUs in multi-processor guests. */
>  #define MAX_VIRT_CPUS 1
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index a9946aa..1d64c02 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -57,7 +57,7 @@ static int map_foreign_page(unsigned long lpfn, unsigned long fgmfn,
>  		.size = 1,
>  		.space = XENMAPSPACE_gmfn_foreign,
>  	};
> -	unsigned long idx = fgmfn;
> +	xen_ulong_t idx = fgmfn;
>  	xen_pfn_t gpfn = lpfn;
>  
>  	set_xen_guest_handle(xatp.idxs, &idx);
> @@ -73,7 +73,7 @@ static int map_foreign_page(unsigned long lpfn, unsigned long fgmfn,
>  }
>  
>  struct remap_data {
> -	unsigned long fgmfn; /* foreign domain's gmfn */
> +	xen_pfn_t fgmfn; /* foreign domain's gmfn */
>  	pgprot_t prot;
>  	domid_t  domid;
>  	struct vm_area_struct *vma;
> @@ -98,7 +98,7 @@ static int remap_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr,
>  
>  int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
>  			       unsigned long addr,
> -			       unsigned long mfn, int nr,
> +			       xen_pfn_t mfn, int nr,
>  			       pgprot_t prot, unsigned domid,
>  			       struct xen_remap_mfn_info *info)
>  {
> diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
> index 250c254..d67f3c6 100644
> --- a/arch/x86/include/asm/xen/interface.h
> +++ b/arch/x86/include/asm/xen/interface.h
> @@ -63,6 +63,7 @@ DEFINE_GUEST_HANDLE(void);
>  DEFINE_GUEST_HANDLE(uint64_t);
>  DEFINE_GUEST_HANDLE(uint32_t);
>  DEFINE_GUEST_HANDLE(xen_pfn_t);
> +DEFINE_GUEST_HANDLE(xen_ulong_t);
>  #endif
>  
>  #ifndef HYPERVISOR_VIRT_START
> diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
> index e5675bc..24e5731 100644
> --- a/include/xen/interface/memory.h
> +++ b/include/xen/interface/memory.h
> @@ -199,7 +199,7 @@ struct xen_add_to_physmap_range {
>      domid_t foreign_domid; /* IFF gmfn_foreign */
>  
>      /* Indexes into space being mapped. */
> -    GUEST_HANDLE(ulong) idxs;
> +    GUEST_HANDLE(xen_ulong_t) idxs;
>  
>      /* GPFN in domid where the source mapping page should appear. */
>      GUEST_HANDLE(xen_pfn_t) gpfns;
> diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
> index 2f3cb06..59309f3 100644
> --- a/include/xen/xen-ops.h
> +++ b/include/xen/xen-ops.h
> @@ -27,7 +27,7 @@ struct vm_area_struct;
>  struct xen_remap_mfn_info;
>  int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
>  			       unsigned long addr,
> -			       unsigned long mfn, int nr,
> +			       xen_pfn_t mfn, int nr,
>  			       pgprot_t prot, unsigned domid,
>  			       struct xen_remap_mfn_info *pvhp);
>  int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 12:32:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 12:32:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLYz1-0003Hw-IF; Tue, 09 Oct 2012 12:32:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLYz0-0003Hr-EB
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 12:32:22 +0000
Received: from [85.158.138.51:24817] by server-1.bemta-3.messagelabs.com id
	28/C6-16425-55914705; Tue, 09 Oct 2012 12:32:21 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1349785940!33168744!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13522 invoked from network); 9 Oct 2012 12:32:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 12:32:20 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15036613"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 12:32:19 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 9 Oct 2012 13:32:20 +0100
Date: Tue, 9 Oct 2012 13:31:14 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1349453467.20946.142.camel@zakaz.uk.xensource.com>
Message-ID: 
References: <1349363496.866.49.camel@zakaz.uk.xensource.com>
	<1349363515-26190-5-git-send-email-ian.campbell@citrix.com>
	
	<1349440338.20946.83.camel@zakaz.uk.xensource.com> 
	
	<1349447625.20946.130.camel@zakaz.uk.xensource.com>
	<1349453467.20946.142.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" ,
	Konrad Rzeszutek Wilk ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 05/14] xen: balloon: use correct type for
 frame_list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 5 Oct 2012, Ian Campbell wrote:
> On Fri, 2012-10-05 at 15:33 +0100, Ian Campbell wrote:
> > The issue you describe could only happen for a 32 bit HAP guest if the
> > guests was given > 16GB (2^(32+PAGE_SHIFT) bytes) of RAM and it was
> > explicitly trying to balloon memory over that limit, but in order for
> > that to even be possible it would already need to have made its concept
> > of a pfn larger than 32 bits.
> 
> The one place this might matter is in the privcmd
> IOCTL_PRIVCMD_MMAPBATCH interface for the *foreign* pfn (since a small
> dom0 needs to be able to build a big domU). Luckily that interface
> already uses xen_pfn_t, we just need to be a bit careful in the
> xen_remap_domain_mfn_range case, which Konrad tried to tell me already
> and he was right...
> 
> On ARM that meant the following (built but not executed) patch, I
> suspect the PVH variant needs similar treatment.

I think you are right


> 
> diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
> index ae05e56..ad87917 100644
> --- a/arch/arm/include/asm/xen/interface.h
> +++ b/arch/arm/include/asm/xen/interface.h
> @@ -43,6 +43,7 @@ DEFINE_GUEST_HANDLE(void);
>  DEFINE_GUEST_HANDLE(uint64_t);
>  DEFINE_GUEST_HANDLE(uint32_t);
>  DEFINE_GUEST_HANDLE(xen_pfn_t);
> +DEFINE_GUEST_HANDLE(xen_ulong_t);
>  
>  /* Maximum number of virtual CPUs in multi-processor guests. */
>  #define MAX_VIRT_CPUS 1
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index a9946aa..1d64c02 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -57,7 +57,7 @@ static int map_foreign_page(unsigned long lpfn, unsigned long fgmfn,
>  		.size = 1,
>  		.space = XENMAPSPACE_gmfn_foreign,
>  	};
> -	unsigned long idx = fgmfn;
> +	xen_ulong_t idx = fgmfn;
>  	xen_pfn_t gpfn = lpfn;
>  
>  	set_xen_guest_handle(xatp.idxs, &idx);
> @@ -73,7 +73,7 @@ static int map_foreign_page(unsigned long lpfn, unsigned long fgmfn,
>  }
>  
>  struct remap_data {
> -	unsigned long fgmfn; /* foreign domain's gmfn */
> +	xen_pfn_t fgmfn; /* foreign domain's gmfn */
>  	pgprot_t prot;
>  	domid_t  domid;
>  	struct vm_area_struct *vma;
> @@ -98,7 +98,7 @@ static int remap_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr,
>  
>  int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
>  			       unsigned long addr,
> -			       unsigned long mfn, int nr,
> +			       xen_pfn_t mfn, int nr,
>  			       pgprot_t prot, unsigned domid,
>  			       struct xen_remap_mfn_info *info)
>  {
> diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
> index 250c254..d67f3c6 100644
> --- a/arch/x86/include/asm/xen/interface.h
> +++ b/arch/x86/include/asm/xen/interface.h
> @@ -63,6 +63,7 @@ DEFINE_GUEST_HANDLE(void);
>  DEFINE_GUEST_HANDLE(uint64_t);
>  DEFINE_GUEST_HANDLE(uint32_t);
>  DEFINE_GUEST_HANDLE(xen_pfn_t);
> +DEFINE_GUEST_HANDLE(xen_ulong_t);
>  #endif
>  
>  #ifndef HYPERVISOR_VIRT_START
> diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
> index e5675bc..24e5731 100644
> --- a/include/xen/interface/memory.h
> +++ b/include/xen/interface/memory.h
> @@ -199,7 +199,7 @@ struct xen_add_to_physmap_range {
>      domid_t foreign_domid; /* IFF gmfn_foreign */
>  
>      /* Indexes into space being mapped. */
> -    GUEST_HANDLE(ulong) idxs;
> +    GUEST_HANDLE(xen_ulong_t) idxs;
>  
>      /* GPFN in domid where the source mapping page should appear. */
>      GUEST_HANDLE(xen_pfn_t) gpfns;
> diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
> index 2f3cb06..59309f3 100644
> --- a/include/xen/xen-ops.h
> +++ b/include/xen/xen-ops.h
> @@ -27,7 +27,7 @@ struct vm_area_struct;
>  struct xen_remap_mfn_info;
>  int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
>  			       unsigned long addr,
> -			       unsigned long mfn, int nr,
> +			       xen_pfn_t mfn, int nr,
>  			       pgprot_t prot, unsigned domid,
>  			       struct xen_remap_mfn_info *pvhp);
>  int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 12:41:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 12:41:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLZ7H-0003S7-Ip; Tue, 09 Oct 2012 12:40:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLZ7F-0003S2-II
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 12:40:53 +0000
Received: from [85.158.143.99:60515] by server-1.bemta-4.messagelabs.com id
	62/07-05684-45B14705; Tue, 09 Oct 2012 12:40:52 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1349786451!26423775!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19306 invoked from network); 9 Oct 2012 12:40:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 12:40:52 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15036855"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 12:40:51 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 9 Oct 2012 13:40:51 +0100
Date: Tue, 9 Oct 2012 13:39:45 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1349453297.20946.141.camel@zakaz.uk.xensource.com>
Message-ID: 
References: <1349433418.20946.46.camel@zakaz.uk.xensource.com>
	<1349433507-21148-17-git-send-email-ian.campbell@citrix.com>
	<1349453297.20946.141.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" ,
	Stefano Stabellini , "Tim
	\(Xen.org\)" ,
	"xen-devel@lists.xen.org" ,
	"JBeulich@suse.com" ,
	"stefano.stabelini@citrix.com" 
Subject: Re: [Xen-devel] [PATCH 17/21] xen: xen_ulong_t substitution
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 5 Oct 2012, Ian Campbell wrote:
> On Fri, 2012-10-05 at 11:38 +0100, Ian Campbell wrote:
> > From: Stefano Stabellini 
> > 
> > There is still an unwanted unsigned long in the xen public interface:
> > replace it with xen_ulong_t.
> > 
> > Also typedef xen_ulong_t to uint64_t on ARM.
> 
> Should this change be applied to the uses of XEN_GUEST_HANDLE(ulong)
> too? My main concern is the one in struct gnttab_setup_table but there
> are a few others.
> 
> I suspect XEN_GUEST_HANDLE(ulong) needs to be removed entirely,
> everywhere it is used should be XEN_GUEST_HANDLE(xen_ulong_t) instead?

It is not necessary, because all the XEN_GUEST_HANDLE(ulong) are already
64 bit on ARM. A 32 bit guest is going to pass a 32 bit unsigned long in a
64 bit field, while a 64 bit guest is going to pass a 64 bit unsigned
long in a 64 bit field. Either way it will work.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 12:41:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 12:41:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLZ7H-0003S7-Ip; Tue, 09 Oct 2012 12:40:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLZ7F-0003S2-II
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 12:40:53 +0000
Received: from [85.158.143.99:60515] by server-1.bemta-4.messagelabs.com id
	62/07-05684-45B14705; Tue, 09 Oct 2012 12:40:52 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1349786451!26423775!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19306 invoked from network); 9 Oct 2012 12:40:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 12:40:52 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15036855"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 12:40:51 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 9 Oct 2012 13:40:51 +0100
Date: Tue, 9 Oct 2012 13:39:45 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1349453297.20946.141.camel@zakaz.uk.xensource.com>
Message-ID: 
References: <1349433418.20946.46.camel@zakaz.uk.xensource.com>
	<1349433507-21148-17-git-send-email-ian.campbell@citrix.com>
	<1349453297.20946.141.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" ,
	Stefano Stabellini , "Tim
	\(Xen.org\)" ,
	"xen-devel@lists.xen.org" ,
	"JBeulich@suse.com" ,
	"stefano.stabelini@citrix.com" 
Subject: Re: [Xen-devel] [PATCH 17/21] xen: xen_ulong_t substitution
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 5 Oct 2012, Ian Campbell wrote:
> On Fri, 2012-10-05 at 11:38 +0100, Ian Campbell wrote:
> > From: Stefano Stabellini 
> > 
> > There is still an unwanted unsigned long in the xen public interface:
> > replace it with xen_ulong_t.
> > 
> > Also typedef xen_ulong_t to uint64_t on ARM.
> 
> Should this change be applied to the uses of XEN_GUEST_HANDLE(ulong)
> too? My main concern is the one in struct gnttab_setup_table but there
> are a few others.
> 
> I suspect XEN_GUEST_HANDLE(ulong) needs to be removed entirely,
> everywhere it is used should be XEN_GUEST_HANDLE(xen_ulong_t) instead?

It is not necessary, because all the XEN_GUEST_HANDLE(ulong) are already
64 bit on ARM. A 32 bit guest is going to pass a 32 bit unsigned long in a
64 bit field, while a 64 bit guest is going to pass a 64 bit unsigned
long in a 64 bit field. Either way it will work.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 12:50:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 12:50:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLZGD-0003bK-JZ; Tue, 09 Oct 2012 12:50:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLZGC-0003bF-5S
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 12:50:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1349786998!6319983!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26126 invoked from network); 9 Oct 2012 12:50:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 12:50:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15037102"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 12:49:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	13:49:58 +0100
Message-ID: <1349786996.21847.153.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Tue, 9 Oct 2012 13:49:56 +0100
In-Reply-To: 
References: <1349433418.20946.46.camel@zakaz.uk.xensource.com>
	<1349433507-21148-17-git-send-email-ian.campbell@citrix.com>
	<1349453297.20946.141.camel@zakaz.uk.xensource.com>
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" ,
	"stefano.stabelini@citrix.com" ,
	"Keir \(Xen.org\)" , "JBeulich@suse.com" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 17/21] xen: xen_ulong_t substitution
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-09 at 13:39 +0100, Stefano Stabellini wrote:
> On Fri, 5 Oct 2012, Ian Campbell wrote:
> > On Fri, 2012-10-05 at 11:38 +0100, Ian Campbell wrote:
> > > From: Stefano Stabellini 
> > > 
> > > There is still an unwanted unsigned long in the xen public interface:
> > > replace it with xen_ulong_t.
> > > 
> > > Also typedef xen_ulong_t to uint64_t on ARM.
> > 
> > Should this change be applied to the uses of XEN_GUEST_HANDLE(ulong)
> > too? My main concern is the one in struct gnttab_setup_table but there
> > are a few others.
> > 
> > I suspect XEN_GUEST_HANDLE(ulong) needs to be removed entirely,
> > everywhere it is used should be XEN_GUEST_HANDLE(xen_ulong_t) instead?
> 
> It is not necessary, because all the XEN_GUEST_HANDLE(ulong) are already
> 64 bit on ARM. A 32 bit guest is going to pass a 32 bit unsigned long in a
> 64 bit field, while a 64 bit guest is going to pass a 64 bit unsigned
> long in a 64 bit field. Either way it will work.

XEN_GUEST_HANDLE(ulong) is unsigned long on all platforms, see
xen/include/public/xen.h:
        __DEFINE_XEN_GUEST_HANDLE(ulong, unsigned long);

The existence of this handle is dangerous since it contains a type which
varies in size but it is (slightly) opaque so you might not notice.

The ulong handle is only really usable/desirable on x86 where retaining
the ABI requires us to use unsigned long for some fields, but we have
already defined xen_ulong_t which has the correct semantics on both ARM
and x86.

I propose the following.

8<---------------------------------------------------

>From 9090354c816216d6b9cc462e3e8c380e0001c554 Mon Sep 17 00:00:00 2001
From: Ian Campbell 
Date: Fri, 5 Oct 2012 16:32:56 +0000
Subject: [PATCH] xen: remove XEN_GUEST_HANDLE(ulong)

Having both this and XEN_GUEST_HANDLE(xen_ulong_t) is confusing and
error prone.

Replace the two remaining uses of the ulong handle, in grant set and
x86 set_gdt hypercalls, with xen_ulong_t.

This correctly sizes the grant frame entry as 64 bit on ARM but
leaves it as unsigned long on x86 (therefore no intended change on
x86). Likewise in set_gdt there is no actual change.

Signed-off-by: Ian Campbell 
---
 xen/arch/x86/mm.c                |    3 ++-
 xen/common/grant_table.c         |    2 +-
 xen/include/asm-x86/hypercall.h  |    2 +-
 xen/include/public/grant_table.h |    2 +-
 xen/include/public/xen.h         |    2 --
 5 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index f9a41fd..3a11af0 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4100,7 +4100,8 @@ long set_gdt(struct vcpu *v,
 }
 
 
-long do_set_gdt(XEN_GUEST_HANDLE_PARAM(ulong) frame_list, unsigned int entries)
+long do_set_gdt(XEN_GUEST_HANDLE_PARAM(xen_ulong_t) frame_list,
+                unsigned int entries)
 {
     int nr_pages = (entries + 511) / 512;
     unsigned long frames[16];
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index f4ae9ee..7912769 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -1322,7 +1322,7 @@ gnttab_setup_table(
     struct domain *d;
     struct grant_table *gt;
     int            i;
-    unsigned long  gmfn;
+    xen_pfn_t  gmfn;
 
     if ( count != 1 )
         return -EINVAL;
diff --git a/xen/include/asm-x86/hypercall.h b/xen/include/asm-x86/hypercall.h
index bd14220..afa8ba9 100644
--- a/xen/include/asm-x86/hypercall.h
+++ b/xen/include/asm-x86/hypercall.h
@@ -33,7 +33,7 @@ do_mmu_update(
 
 extern long
 do_set_gdt(
-    XEN_GUEST_HANDLE_PARAM(ulong) frame_list,
+    XEN_GUEST_HANDLE_PARAM(xen_ulong_t) frame_list,
     unsigned int entries);
 
 extern long
diff --git a/xen/include/public/grant_table.h b/xen/include/public/grant_table.h
index 28d9476..13cc559 100644
--- a/xen/include/public/grant_table.h
+++ b/xen/include/public/grant_table.h
@@ -385,7 +385,7 @@ struct gnttab_setup_table {
     uint32_t nr_frames;
     /* OUT parameters. */
     int16_t  status;              /* => enum grant_status */
-    XEN_GUEST_HANDLE(ulong) frame_list;
+    XEN_GUEST_HANDLE(xen_pfn_t) frame_list;
 };
 typedef struct gnttab_setup_table gnttab_setup_table_t;
 DEFINE_XEN_GUEST_HANDLE(gnttab_setup_table_t);
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index e42d01f..9a5b394 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -43,8 +43,6 @@ DEFINE_XEN_GUEST_HANDLE(char);
 __DEFINE_XEN_GUEST_HANDLE(uchar, unsigned char);
 DEFINE_XEN_GUEST_HANDLE(int);
 __DEFINE_XEN_GUEST_HANDLE(uint,  unsigned int);
-DEFINE_XEN_GUEST_HANDLE(long);
-__DEFINE_XEN_GUEST_HANDLE(ulong, unsigned long);
 DEFINE_XEN_GUEST_HANDLE(void);
 
 DEFINE_XEN_GUEST_HANDLE(uint64_t);
-- 
1.7.9.1




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 12:50:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 12:50:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLZGD-0003bK-JZ; Tue, 09 Oct 2012 12:50:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLZGC-0003bF-5S
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 12:50:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1349786998!6319983!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26126 invoked from network); 9 Oct 2012 12:50:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 12:50:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15037102"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 12:49:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	13:49:58 +0100
Message-ID: <1349786996.21847.153.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Tue, 9 Oct 2012 13:49:56 +0100
In-Reply-To: 
References: <1349433418.20946.46.camel@zakaz.uk.xensource.com>
	<1349433507-21148-17-git-send-email-ian.campbell@citrix.com>
	<1349453297.20946.141.camel@zakaz.uk.xensource.com>
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" ,
	"stefano.stabelini@citrix.com" ,
	"Keir \(Xen.org\)" , "JBeulich@suse.com" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 17/21] xen: xen_ulong_t substitution
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-09 at 13:39 +0100, Stefano Stabellini wrote:
> On Fri, 5 Oct 2012, Ian Campbell wrote:
> > On Fri, 2012-10-05 at 11:38 +0100, Ian Campbell wrote:
> > > From: Stefano Stabellini 
> > > 
> > > There is still an unwanted unsigned long in the xen public interface:
> > > replace it with xen_ulong_t.
> > > 
> > > Also typedef xen_ulong_t to uint64_t on ARM.
> > 
> > Should this change be applied to the uses of XEN_GUEST_HANDLE(ulong)
> > too? My main concern is the one in struct gnttab_setup_table but there
> > are a few others.
> > 
> > I suspect XEN_GUEST_HANDLE(ulong) needs to be removed entirely,
> > everywhere it is used should be XEN_GUEST_HANDLE(xen_ulong_t) instead?
> 
> It is not necessary, because all the XEN_GUEST_HANDLE(ulong) are already
> 64 bit on ARM. A 32 bit guest is going to pass a 32 bit unsigned long in a
> 64 bit field, while a 64 bit guest is going to pass a 64 bit unsigned
> long in a 64 bit field. Either way it will work.

XEN_GUEST_HANDLE(ulong) is unsigned long on all platforms, see
xen/include/public/xen.h:
        __DEFINE_XEN_GUEST_HANDLE(ulong, unsigned long);

The existence of this handle is dangerous since it contains a type which
varies in size but it is (slightly) opaque so you might not notice.

The ulong handle is only really usable/desirable on x86 where retaining
the ABI requires us to use unsigned long for some fields, but we have
already defined xen_ulong_t which has the correct semantics on both ARM
and x86.

I propose the following.

8<---------------------------------------------------

>From 9090354c816216d6b9cc462e3e8c380e0001c554 Mon Sep 17 00:00:00 2001
From: Ian Campbell 
Date: Fri, 5 Oct 2012 16:32:56 +0000
Subject: [PATCH] xen: remove XEN_GUEST_HANDLE(ulong)

Having both this and XEN_GUEST_HANDLE(xen_ulong_t) is confusing and
error prone.

Replace the two remaining uses of the ulong handle, in grant set and
x86 set_gdt hypercalls, with xen_ulong_t.

This correctly sizes the grant frame entry as 64 bit on ARM but
leaves it as unsigned long on x86 (therefore no intended change on
x86). Likewise in set_gdt there is no actual change.

Signed-off-by: Ian Campbell 
---
 xen/arch/x86/mm.c                |    3 ++-
 xen/common/grant_table.c         |    2 +-
 xen/include/asm-x86/hypercall.h  |    2 +-
 xen/include/public/grant_table.h |    2 +-
 xen/include/public/xen.h         |    2 --
 5 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index f9a41fd..3a11af0 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4100,7 +4100,8 @@ long set_gdt(struct vcpu *v,
 }
 
 
-long do_set_gdt(XEN_GUEST_HANDLE_PARAM(ulong) frame_list, unsigned int entries)
+long do_set_gdt(XEN_GUEST_HANDLE_PARAM(xen_ulong_t) frame_list,
+                unsigned int entries)
 {
     int nr_pages = (entries + 511) / 512;
     unsigned long frames[16];
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index f4ae9ee..7912769 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -1322,7 +1322,7 @@ gnttab_setup_table(
     struct domain *d;
     struct grant_table *gt;
     int            i;
-    unsigned long  gmfn;
+    xen_pfn_t  gmfn;
 
     if ( count != 1 )
         return -EINVAL;
diff --git a/xen/include/asm-x86/hypercall.h b/xen/include/asm-x86/hypercall.h
index bd14220..afa8ba9 100644
--- a/xen/include/asm-x86/hypercall.h
+++ b/xen/include/asm-x86/hypercall.h
@@ -33,7 +33,7 @@ do_mmu_update(
 
 extern long
 do_set_gdt(
-    XEN_GUEST_HANDLE_PARAM(ulong) frame_list,
+    XEN_GUEST_HANDLE_PARAM(xen_ulong_t) frame_list,
     unsigned int entries);
 
 extern long
diff --git a/xen/include/public/grant_table.h b/xen/include/public/grant_table.h
index 28d9476..13cc559 100644
--- a/xen/include/public/grant_table.h
+++ b/xen/include/public/grant_table.h
@@ -385,7 +385,7 @@ struct gnttab_setup_table {
     uint32_t nr_frames;
     /* OUT parameters. */
     int16_t  status;              /* => enum grant_status */
-    XEN_GUEST_HANDLE(ulong) frame_list;
+    XEN_GUEST_HANDLE(xen_pfn_t) frame_list;
 };
 typedef struct gnttab_setup_table gnttab_setup_table_t;
 DEFINE_XEN_GUEST_HANDLE(gnttab_setup_table_t);
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index e42d01f..9a5b394 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -43,8 +43,6 @@ DEFINE_XEN_GUEST_HANDLE(char);
 __DEFINE_XEN_GUEST_HANDLE(uchar, unsigned char);
 DEFINE_XEN_GUEST_HANDLE(int);
 __DEFINE_XEN_GUEST_HANDLE(uint,  unsigned int);
-DEFINE_XEN_GUEST_HANDLE(long);
-__DEFINE_XEN_GUEST_HANDLE(ulong, unsigned long);
 DEFINE_XEN_GUEST_HANDLE(void);
 
 DEFINE_XEN_GUEST_HANDLE(uint64_t);
-- 
1.7.9.1




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 12:53:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 12:53:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLZJ6-0003h2-6J; Tue, 09 Oct 2012 12:53:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLZJ4-0003gx-UT
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 12:53:07 +0000
Received: from [85.158.143.99:64180] by server-3.bemta-4.messagelabs.com id
	1A/F7-10986-23E14705; Tue, 09 Oct 2012 12:53:06 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1349787185!26989836!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4937 invoked from network); 9 Oct 2012 12:53:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 12:53:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15037288"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 12:53:05 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 9 Oct 2012 13:53:05 +0100
Date: Tue, 9 Oct 2012 13:51:59 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1349786996.21847.153.camel@zakaz.uk.xensource.com>
Message-ID: 
References: <1349433418.20946.46.camel@zakaz.uk.xensource.com>
	<1349433507-21148-17-git-send-email-ian.campbell@citrix.com>
	<1349453297.20946.141.camel@zakaz.uk.xensource.com>
	
	<1349786996.21847.153.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" ,
	Stefano Stabellini ,
	"Tim \(Xen.org\)" ,
	"xen-devel@lists.xen.org" ,
	"JBeulich@suse.com" ,
	"stefano.stabelini@citrix.com" 
Subject: Re: [Xen-devel] [PATCH 17/21] xen: xen_ulong_t substitution
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 9 Oct 2012, Ian Campbell wrote:
> On Tue, 2012-10-09 at 13:39 +0100, Stefano Stabellini wrote:
> > On Fri, 5 Oct 2012, Ian Campbell wrote:
> > > On Fri, 2012-10-05 at 11:38 +0100, Ian Campbell wrote:
> > > > From: Stefano Stabellini 
> > > > 
> > > > There is still an unwanted unsigned long in the xen public interface:
> > > > replace it with xen_ulong_t.
> > > > 
> > > > Also typedef xen_ulong_t to uint64_t on ARM.
> > > 
> > > Should this change be applied to the uses of XEN_GUEST_HANDLE(ulong)
> > > too? My main concern is the one in struct gnttab_setup_table but there
> > > are a few others.
> > > 
> > > I suspect XEN_GUEST_HANDLE(ulong) needs to be removed entirely,
> > > everywhere it is used should be XEN_GUEST_HANDLE(xen_ulong_t) instead?
> > 
> > It is not necessary, because all the XEN_GUEST_HANDLE(ulong) are already
> > 64 bit on ARM. A 32 bit guest is going to pass a 32 bit unsigned long in a
> > 64 bit field, while a 64 bit guest is going to pass a 64 bit unsigned
> > long in a 64 bit field. Either way it will work.
> 
> XEN_GUEST_HANDLE(ulong) is unsigned long on all platforms, see
> xen/include/public/xen.h:
>         __DEFINE_XEN_GUEST_HANDLE(ulong, unsigned long);
> 
> The existence of this handle is dangerous since it contains a type which
> varies in size but it is (slightly) opaque so you might not notice.
> 
> The ulong handle is only really usable/desirable on x86 where retaining
> the ABI requires us to use unsigned long for some fields, but we have
> already defined xen_ulong_t which has the correct semantics on both ARM
> and x86.
> 
> I propose the following.

It is certainly an improvement. Also I didn't notice the
XEN_GUEST_HANDLE_PARAM(ulong): that is actually an error.
We also need a corresponding patch for Linux.


> 8<---------------------------------------------------
> 
> From 9090354c816216d6b9cc462e3e8c380e0001c554 Mon Sep 17 00:00:00 2001
> From: Ian Campbell 
> Date: Fri, 5 Oct 2012 16:32:56 +0000
> Subject: [PATCH] xen: remove XEN_GUEST_HANDLE(ulong)
> 
> Having both this and XEN_GUEST_HANDLE(xen_ulong_t) is confusing and
> error prone.
> 
> Replace the two remaining uses of the ulong handle, in grant set and
> x86 set_gdt hypercalls, with xen_ulong_t.
> 
> This correctly sizes the grant frame entry as 64 bit on ARM but
> leaves it as unsigned long on x86 (therefore no intended change on
> x86). Likewise in set_gdt there is no actual change.
> 
> Signed-off-by: Ian Campbell 
> ---
>  xen/arch/x86/mm.c                |    3 ++-
>  xen/common/grant_table.c         |    2 +-
>  xen/include/asm-x86/hypercall.h  |    2 +-
>  xen/include/public/grant_table.h |    2 +-
>  xen/include/public/xen.h         |    2 --
>  5 files changed, 5 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> index f9a41fd..3a11af0 100644
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -4100,7 +4100,8 @@ long set_gdt(struct vcpu *v,
>  }
>  
>  
> -long do_set_gdt(XEN_GUEST_HANDLE_PARAM(ulong) frame_list, unsigned int entries)
> +long do_set_gdt(XEN_GUEST_HANDLE_PARAM(xen_ulong_t) frame_list,
> +                unsigned int entries)
>  {
>      int nr_pages = (entries + 511) / 512;
>      unsigned long frames[16];
> diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
> index f4ae9ee..7912769 100644
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -1322,7 +1322,7 @@ gnttab_setup_table(
>      struct domain *d;
>      struct grant_table *gt;
>      int            i;
> -    unsigned long  gmfn;
> +    xen_pfn_t  gmfn;
>  
>      if ( count != 1 )
>          return -EINVAL;
> diff --git a/xen/include/asm-x86/hypercall.h b/xen/include/asm-x86/hypercall.h
> index bd14220..afa8ba9 100644
> --- a/xen/include/asm-x86/hypercall.h
> +++ b/xen/include/asm-x86/hypercall.h
> @@ -33,7 +33,7 @@ do_mmu_update(
>  
>  extern long
>  do_set_gdt(
> -    XEN_GUEST_HANDLE_PARAM(ulong) frame_list,
> +    XEN_GUEST_HANDLE_PARAM(xen_ulong_t) frame_list,
>      unsigned int entries);
>  
>  extern long
> diff --git a/xen/include/public/grant_table.h b/xen/include/public/grant_table.h
> index 28d9476..13cc559 100644
> --- a/xen/include/public/grant_table.h
> +++ b/xen/include/public/grant_table.h
> @@ -385,7 +385,7 @@ struct gnttab_setup_table {
>      uint32_t nr_frames;
>      /* OUT parameters. */
>      int16_t  status;              /* => enum grant_status */
> -    XEN_GUEST_HANDLE(ulong) frame_list;
> +    XEN_GUEST_HANDLE(xen_pfn_t) frame_list;
>  };
>  typedef struct gnttab_setup_table gnttab_setup_table_t;
>  DEFINE_XEN_GUEST_HANDLE(gnttab_setup_table_t);
> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> index e42d01f..9a5b394 100644
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -43,8 +43,6 @@ DEFINE_XEN_GUEST_HANDLE(char);
>  __DEFINE_XEN_GUEST_HANDLE(uchar, unsigned char);
>  DEFINE_XEN_GUEST_HANDLE(int);
>  __DEFINE_XEN_GUEST_HANDLE(uint,  unsigned int);
> -DEFINE_XEN_GUEST_HANDLE(long);
> -__DEFINE_XEN_GUEST_HANDLE(ulong, unsigned long);
>  DEFINE_XEN_GUEST_HANDLE(void);
>  
>  DEFINE_XEN_GUEST_HANDLE(uint64_t);
> -- 
> 1.7.9.1
> 
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 12:53:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 12:53:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLZJ6-0003h2-6J; Tue, 09 Oct 2012 12:53:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLZJ4-0003gx-UT
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 12:53:07 +0000
Received: from [85.158.143.99:64180] by server-3.bemta-4.messagelabs.com id
	1A/F7-10986-23E14705; Tue, 09 Oct 2012 12:53:06 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1349787185!26989836!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4937 invoked from network); 9 Oct 2012 12:53:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 12:53:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15037288"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 12:53:05 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 9 Oct 2012 13:53:05 +0100
Date: Tue, 9 Oct 2012 13:51:59 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1349786996.21847.153.camel@zakaz.uk.xensource.com>
Message-ID: 
References: <1349433418.20946.46.camel@zakaz.uk.xensource.com>
	<1349433507-21148-17-git-send-email-ian.campbell@citrix.com>
	<1349453297.20946.141.camel@zakaz.uk.xensource.com>
	
	<1349786996.21847.153.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" ,
	Stefano Stabellini ,
	"Tim \(Xen.org\)" ,
	"xen-devel@lists.xen.org" ,
	"JBeulich@suse.com" ,
	"stefano.stabelini@citrix.com" 
Subject: Re: [Xen-devel] [PATCH 17/21] xen: xen_ulong_t substitution
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 9 Oct 2012, Ian Campbell wrote:
> On Tue, 2012-10-09 at 13:39 +0100, Stefano Stabellini wrote:
> > On Fri, 5 Oct 2012, Ian Campbell wrote:
> > > On Fri, 2012-10-05 at 11:38 +0100, Ian Campbell wrote:
> > > > From: Stefano Stabellini 
> > > > 
> > > > There is still an unwanted unsigned long in the xen public interface:
> > > > replace it with xen_ulong_t.
> > > > 
> > > > Also typedef xen_ulong_t to uint64_t on ARM.
> > > 
> > > Should this change be applied to the uses of XEN_GUEST_HANDLE(ulong)
> > > too? My main concern is the one in struct gnttab_setup_table but there
> > > are a few others.
> > > 
> > > I suspect XEN_GUEST_HANDLE(ulong) needs to be removed entirely,
> > > everywhere it is used should be XEN_GUEST_HANDLE(xen_ulong_t) instead?
> > 
> > It is not necessary, because all the XEN_GUEST_HANDLE(ulong) are already
> > 64 bit on ARM. A 32 bit guest is going to pass a 32 bit unsigned long in a
> > 64 bit field, while a 64 bit guest is going to pass a 64 bit unsigned
> > long in a 64 bit field. Either way it will work.
> 
> XEN_GUEST_HANDLE(ulong) is unsigned long on all platforms, see
> xen/include/public/xen.h:
>         __DEFINE_XEN_GUEST_HANDLE(ulong, unsigned long);
> 
> The existence of this handle is dangerous since it contains a type which
> varies in size but it is (slightly) opaque so you might not notice.
> 
> The ulong handle is only really usable/desirable on x86 where retaining
> the ABI requires us to use unsigned long for some fields, but we have
> already defined xen_ulong_t which has the correct semantics on both ARM
> and x86.
> 
> I propose the following.

It is certainly an improvement. Also I didn't notice the
XEN_GUEST_HANDLE_PARAM(ulong): that is actually an error.
We also need a corresponding patch for Linux.


> 8<---------------------------------------------------
> 
> From 9090354c816216d6b9cc462e3e8c380e0001c554 Mon Sep 17 00:00:00 2001
> From: Ian Campbell 
> Date: Fri, 5 Oct 2012 16:32:56 +0000
> Subject: [PATCH] xen: remove XEN_GUEST_HANDLE(ulong)
> 
> Having both this and XEN_GUEST_HANDLE(xen_ulong_t) is confusing and
> error prone.
> 
> Replace the two remaining uses of the ulong handle, in grant set and
> x86 set_gdt hypercalls, with xen_ulong_t.
> 
> This correctly sizes the grant frame entry as 64 bit on ARM but
> leaves it as unsigned long on x86 (therefore no intended change on
> x86). Likewise in set_gdt there is no actual change.
> 
> Signed-off-by: Ian Campbell 
> ---
>  xen/arch/x86/mm.c                |    3 ++-
>  xen/common/grant_table.c         |    2 +-
>  xen/include/asm-x86/hypercall.h  |    2 +-
>  xen/include/public/grant_table.h |    2 +-
>  xen/include/public/xen.h         |    2 --
>  5 files changed, 5 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> index f9a41fd..3a11af0 100644
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -4100,7 +4100,8 @@ long set_gdt(struct vcpu *v,
>  }
>  
>  
> -long do_set_gdt(XEN_GUEST_HANDLE_PARAM(ulong) frame_list, unsigned int entries)
> +long do_set_gdt(XEN_GUEST_HANDLE_PARAM(xen_ulong_t) frame_list,
> +                unsigned int entries)
>  {
>      int nr_pages = (entries + 511) / 512;
>      unsigned long frames[16];
> diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
> index f4ae9ee..7912769 100644
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -1322,7 +1322,7 @@ gnttab_setup_table(
>      struct domain *d;
>      struct grant_table *gt;
>      int            i;
> -    unsigned long  gmfn;
> +    xen_pfn_t  gmfn;
>  
>      if ( count != 1 )
>          return -EINVAL;
> diff --git a/xen/include/asm-x86/hypercall.h b/xen/include/asm-x86/hypercall.h
> index bd14220..afa8ba9 100644
> --- a/xen/include/asm-x86/hypercall.h
> +++ b/xen/include/asm-x86/hypercall.h
> @@ -33,7 +33,7 @@ do_mmu_update(
>  
>  extern long
>  do_set_gdt(
> -    XEN_GUEST_HANDLE_PARAM(ulong) frame_list,
> +    XEN_GUEST_HANDLE_PARAM(xen_ulong_t) frame_list,
>      unsigned int entries);
>  
>  extern long
> diff --git a/xen/include/public/grant_table.h b/xen/include/public/grant_table.h
> index 28d9476..13cc559 100644
> --- a/xen/include/public/grant_table.h
> +++ b/xen/include/public/grant_table.h
> @@ -385,7 +385,7 @@ struct gnttab_setup_table {
>      uint32_t nr_frames;
>      /* OUT parameters. */
>      int16_t  status;              /* => enum grant_status */
> -    XEN_GUEST_HANDLE(ulong) frame_list;
> +    XEN_GUEST_HANDLE(xen_pfn_t) frame_list;
>  };
>  typedef struct gnttab_setup_table gnttab_setup_table_t;
>  DEFINE_XEN_GUEST_HANDLE(gnttab_setup_table_t);
> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> index e42d01f..9a5b394 100644
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -43,8 +43,6 @@ DEFINE_XEN_GUEST_HANDLE(char);
>  __DEFINE_XEN_GUEST_HANDLE(uchar, unsigned char);
>  DEFINE_XEN_GUEST_HANDLE(int);
>  __DEFINE_XEN_GUEST_HANDLE(uint,  unsigned int);
> -DEFINE_XEN_GUEST_HANDLE(long);
> -__DEFINE_XEN_GUEST_HANDLE(ulong, unsigned long);
>  DEFINE_XEN_GUEST_HANDLE(void);
>  
>  DEFINE_XEN_GUEST_HANDLE(uint64_t);
> -- 
> 1.7.9.1
> 
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 12:59:45 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 12:59:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLZOs-0003se-WC; Tue, 09 Oct 2012 12:59:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLZOr-0003sZ-9k
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 12:59:05 +0000
Received: from [85.158.139.211:22395] by server-12.bemta-5.messagelabs.com id
	73/79-19095-89F14705; Tue, 09 Oct 2012 12:59:04 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1349787543!21621553!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5285 invoked from network); 9 Oct 2012 12:59:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 12:59:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15037454"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 12:59:03 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 9 Oct 2012 13:59:03 +0100
Date: Tue, 9 Oct 2012 13:58:08 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1349444670.20946.105.camel@zakaz.uk.xensource.com>
Message-ID: 
References: 
	<20581.58276.573643.315620@mariner.uk.xensource.com>
	<1349444670.20946.105.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	Ian Jackson ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH v2] libxl/qemu-xen: use cache=writeback for
 IDE and SCSI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 5 Oct 2012, Ian Campbell wrote:
> On Fri, 2012-09-28 at 18:51 +0100, Ian Jackson wrote:
> > Stefano Stabellini writes ("[Xen-devel] [PATCH v2] libxl/qemu-xen: use cache=writeback for IDE and SCSI"):
> > > Change caching mode from writethrough to writeback for upstream QEMU.
> > > 
> > > After a lengthy discussion, we came up with the conclusion that
> > > WRITEBACK is OK for IDE.
> > > See: http://marc.info/?l=xen-devel&m=133311527009773
> > > 
> > > Given that the same reasons apply to SCSI as well, change to writeback
> > > for SCSI too.
> > 
> > Acked-by: Ian Jackson 
> 
> Acked + applied.
> 
> Are the performance benefits of this patch worthy of a 4.2 backport,
> even though qemu-xen is not the default?

I think they are: QEMU should be more than twice as fast with that
patch.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 12:59:45 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 12:59:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLZOs-0003se-WC; Tue, 09 Oct 2012 12:59:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLZOr-0003sZ-9k
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 12:59:05 +0000
Received: from [85.158.139.211:22395] by server-12.bemta-5.messagelabs.com id
	73/79-19095-89F14705; Tue, 09 Oct 2012 12:59:04 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1349787543!21621553!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5285 invoked from network); 9 Oct 2012 12:59:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 12:59:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15037454"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 12:59:03 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 9 Oct 2012 13:59:03 +0100
Date: Tue, 9 Oct 2012 13:58:08 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1349444670.20946.105.camel@zakaz.uk.xensource.com>
Message-ID: 
References: 
	<20581.58276.573643.315620@mariner.uk.xensource.com>
	<1349444670.20946.105.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	Ian Jackson ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH v2] libxl/qemu-xen: use cache=writeback for
 IDE and SCSI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 5 Oct 2012, Ian Campbell wrote:
> On Fri, 2012-09-28 at 18:51 +0100, Ian Jackson wrote:
> > Stefano Stabellini writes ("[Xen-devel] [PATCH v2] libxl/qemu-xen: use cache=writeback for IDE and SCSI"):
> > > Change caching mode from writethrough to writeback for upstream QEMU.
> > > 
> > > After a lengthy discussion, we came up with the conclusion that
> > > WRITEBACK is OK for IDE.
> > > See: http://marc.info/?l=xen-devel&m=133311527009773
> > > 
> > > Given that the same reasons apply to SCSI as well, change to writeback
> > > for SCSI too.
> > 
> > Acked-by: Ian Jackson 
> 
> Acked + applied.
> 
> Are the performance benefits of this patch worthy of a 4.2 backport,
> even though qemu-xen is not the default?

I think they are: QEMU should be more than twice as fast with that
patch.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 13:04:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 13:04:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLZUB-00043l-O7; Tue, 09 Oct 2012 13:04:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLZU9-00043e-MH
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 13:04:33 +0000
Received: from [85.158.143.35:16128] by server-2.bemta-4.messagelabs.com id
	E2/85-06610-0E024705; Tue, 09 Oct 2012 13:04:32 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-21.messagelabs.com!1349787871!4541385!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MjU2MjE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MjU2MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3928 invoked from network); 9 Oct 2012 13:04:31 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Oct 2012 13:04:31 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk287sE5w=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-092-071.pools.arcor-ip.net [84.57.92.71])
	by smtp.strato.de (josoe mo42) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id J032e2o99CwxEa
	for ; Tue, 9 Oct 2012 15:04:31 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id A9B54183A7
	for ; Tue,  9 Oct 2012 15:04:30 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 384714804b9b2a9742cc45dffaa43b749b85513b
Message-Id: <384714804b9b2a9742cc.1349787869@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Tue, 09 Oct 2012 15:04:29 +0200
From: Olaf Hering 
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] stubdom: fix error assignment in
	grub:load_module
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering 
# Date 1349787855 -7200
# Node ID 384714804b9b2a9742cc45dffaa43b749b85513b
# Parent  142e4577f5a9b95832b82f7b6d31fde1697cbe76
stubdom: fix error assignment in grub:load_module

[ 1333s] mini-os.c: In function 'load_module':
[ 1333s] mini-os.c:244: warning: statement with no effect

Signed-off-by: Olaf Hering 

diff -r 142e4577f5a9 -r 384714804b9b stubdom/grub/mini-os.c
--- a/stubdom/grub/mini-os.c
+++ b/stubdom/grub/mini-os.c
@@ -241,7 +241,7 @@ load_module (char *module, char *arg)
 
     if ((void*) (multiboot_next_module_header+1) - module_image > PAGE_SIZE) {
         /* Too many modules */
-        ERR_WONT_FIT;
+        errnum = ERR_WONT_FIT;
         return 0;
     }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 13:04:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 13:04:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLZUB-00043l-O7; Tue, 09 Oct 2012 13:04:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLZU9-00043e-MH
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 13:04:33 +0000
Received: from [85.158.143.35:16128] by server-2.bemta-4.messagelabs.com id
	E2/85-06610-0E024705; Tue, 09 Oct 2012 13:04:32 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-21.messagelabs.com!1349787871!4541385!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MjU2MjE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MjU2MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3928 invoked from network); 9 Oct 2012 13:04:31 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Oct 2012 13:04:31 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk287sE5w=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-092-071.pools.arcor-ip.net [84.57.92.71])
	by smtp.strato.de (josoe mo42) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id J032e2o99CwxEa
	for ; Tue, 9 Oct 2012 15:04:31 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id A9B54183A7
	for ; Tue,  9 Oct 2012 15:04:30 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 384714804b9b2a9742cc45dffaa43b749b85513b
Message-Id: <384714804b9b2a9742cc.1349787869@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Tue, 09 Oct 2012 15:04:29 +0200
From: Olaf Hering 
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] stubdom: fix error assignment in
	grub:load_module
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering 
# Date 1349787855 -7200
# Node ID 384714804b9b2a9742cc45dffaa43b749b85513b
# Parent  142e4577f5a9b95832b82f7b6d31fde1697cbe76
stubdom: fix error assignment in grub:load_module

[ 1333s] mini-os.c: In function 'load_module':
[ 1333s] mini-os.c:244: warning: statement with no effect

Signed-off-by: Olaf Hering 

diff -r 142e4577f5a9 -r 384714804b9b stubdom/grub/mini-os.c
--- a/stubdom/grub/mini-os.c
+++ b/stubdom/grub/mini-os.c
@@ -241,7 +241,7 @@ load_module (char *module, char *arg)
 
     if ((void*) (multiboot_next_module_header+1) - module_image > PAGE_SIZE) {
         /* Too many modules */
-        ERR_WONT_FIT;
+        errnum = ERR_WONT_FIT;
         return 0;
     }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 13:06:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 13:06:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLZVL-00048u-BQ; Tue, 09 Oct 2012 13:05:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLZVJ-00048l-CW
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 13:05:45 +0000
Received: from [85.158.139.83:62992] by server-4.bemta-5.messagelabs.com id
	7B/FB-20767-82124705; Tue, 09 Oct 2012 13:05:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1349787943!28451886!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26194 invoked from network); 9 Oct 2012 13:05:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 13:05:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15037684"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 13:05:41 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	14:05:41 +0100
Message-ID: <1349787938.21847.161.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Tue, 9 Oct 2012 14:05:38 +0100
In-Reply-To: 
References: <1349433418.20946.46.camel@zakaz.uk.xensource.com>
	<1349433507-21148-17-git-send-email-ian.campbell@citrix.com>
	<1349453297.20946.141.camel@zakaz.uk.xensource.com>
	
	<1349786996.21847.153.camel@zakaz.uk.xensource.com>
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" ,
	"stefano.stabelini@citrix.com" ,
	"Keir \(Xen.org\)" , "JBeulich@suse.com" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 17/21] xen: xen_ulong_t substitution
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-09 at 13:51 +0100, Stefano Stabellini wrote:
> On Tue, 9 Oct 2012, Ian Campbell wrote:
> > On Tue, 2012-10-09 at 13:39 +0100, Stefano Stabellini wrote:
> > > On Fri, 5 Oct 2012, Ian Campbell wrote:
> > > > On Fri, 2012-10-05 at 11:38 +0100, Ian Campbell wrote:
> > > > > From: Stefano Stabellini 
> > > > > 
> > > > > There is still an unwanted unsigned long in the xen public interface:
> > > > > replace it with xen_ulong_t.
> > > > > 
> > > > > Also typedef xen_ulong_t to uint64_t on ARM.
> > > > 
> > > > Should this change be applied to the uses of XEN_GUEST_HANDLE(ulong)
> > > > too? My main concern is the one in struct gnttab_setup_table but there
> > > > are a few others.
> > > > 
> > > > I suspect XEN_GUEST_HANDLE(ulong) needs to be removed entirely,
> > > > everywhere it is used should be XEN_GUEST_HANDLE(xen_ulong_t) instead?
> > > 
> > > It is not necessary, because all the XEN_GUEST_HANDLE(ulong) are already
> > > 64 bit on ARM. A 32 bit guest is going to pass a 32 bit unsigned long in a
> > > 64 bit field, while a 64 bit guest is going to pass a 64 bit unsigned
> > > long in a 64 bit field. Either way it will work.
> > 
> > XEN_GUEST_HANDLE(ulong) is unsigned long on all platforms, see
> > xen/include/public/xen.h:
> >         __DEFINE_XEN_GUEST_HANDLE(ulong, unsigned long);
> > 
> > The existence of this handle is dangerous since it contains a type which
> > varies in size but it is (slightly) opaque so you might not notice.
> > 
> > The ulong handle is only really usable/desirable on x86 where retaining
> > the ABI requires us to use unsigned long for some fields, but we have
> > already defined xen_ulong_t which has the correct semantics on both ARM
> > and x86.
> > 
> > I propose the following.
> 
> It is certainly an improvement. Also I didn't notice the
> XEN_GUEST_HANDLE_PARAM(ulong): that is actually an error.
> We also need a corresponding patch for Linux.

I need to tesdt both this and the h/v side a bit more but here it is.

8<---------------------------

>From c55591bbe3b1d5164641075b95f3c95418bcdf79 Mon Sep 17 00:00:00 2001
From: Ian Campbell 
Date: Fri, 5 Oct 2012 17:39:19 +0100
Subject: [PATCH] xen: grant: use xen_pfn_t type for frame_list.

This correctly sizes it as 64 bit on ARM but leaves it as unsigned
long on x86 (therefore no intended change on x86).

The long and ulong guest handles are now unused (and a bit dangerous)
so remove them.

Signed-off-by: Ian Campbell 
---
 arch/arm/include/asm/xen/interface.h |    2 --
 arch/x86/include/asm/xen/interface.h |    2 --
 include/xen/interface/grant_table.h  |    2 +-
 3 files changed, 1 insertions(+), 5 deletions(-)

diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
index ad87917..9ac9f4e 100644
--- a/arch/arm/include/asm/xen/interface.h
+++ b/arch/arm/include/asm/xen/interface.h
@@ -35,10 +35,8 @@ typedef uint64_t xen_ulong_t;
 /* Guest handles for primitive C types. */
 __DEFINE_GUEST_HANDLE(uchar, unsigned char);
 __DEFINE_GUEST_HANDLE(uint,  unsigned int);
-__DEFINE_GUEST_HANDLE(ulong, unsigned long);
 DEFINE_GUEST_HANDLE(char);
 DEFINE_GUEST_HANDLE(int);
-DEFINE_GUEST_HANDLE(long);
 DEFINE_GUEST_HANDLE(void);
 DEFINE_GUEST_HANDLE(uint64_t);
 DEFINE_GUEST_HANDLE(uint32_t);
diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
index d67f3c6..ed602f8 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -55,10 +55,8 @@ typedef unsigned long xen_ulong_t;
 /* Guest handles for primitive C types. */
 __DEFINE_GUEST_HANDLE(uchar, unsigned char);
 __DEFINE_GUEST_HANDLE(uint,  unsigned int);
-__DEFINE_GUEST_HANDLE(ulong, unsigned long);
 DEFINE_GUEST_HANDLE(char);
 DEFINE_GUEST_HANDLE(int);
-DEFINE_GUEST_HANDLE(long);
 DEFINE_GUEST_HANDLE(void);
 DEFINE_GUEST_HANDLE(uint64_t);
 DEFINE_GUEST_HANDLE(uint32_t);
diff --git a/include/xen/interface/grant_table.h b/include/xen/interface/grant_table.h
index f9f8b97..e40fae9 100644
--- a/include/xen/interface/grant_table.h
+++ b/include/xen/interface/grant_table.h
@@ -310,7 +310,7 @@ struct gnttab_setup_table {
     uint32_t nr_frames;
     /* OUT parameters. */
     int16_t  status;              /* GNTST_* */
-    GUEST_HANDLE(ulong) frame_list;
+    GUEST_HANDLE(xen_pfn_t) frame_list;
 };
 DEFINE_GUEST_HANDLE_STRUCT(gnttab_setup_table);
 
-- 
1.7.2.5




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 13:06:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 13:06:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLZVL-00048u-BQ; Tue, 09 Oct 2012 13:05:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLZVJ-00048l-CW
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 13:05:45 +0000
Received: from [85.158.139.83:62992] by server-4.bemta-5.messagelabs.com id
	7B/FB-20767-82124705; Tue, 09 Oct 2012 13:05:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1349787943!28451886!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26194 invoked from network); 9 Oct 2012 13:05:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 13:05:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15037684"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 13:05:41 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	14:05:41 +0100
Message-ID: <1349787938.21847.161.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Tue, 9 Oct 2012 14:05:38 +0100
In-Reply-To: 
References: <1349433418.20946.46.camel@zakaz.uk.xensource.com>
	<1349433507-21148-17-git-send-email-ian.campbell@citrix.com>
	<1349453297.20946.141.camel@zakaz.uk.xensource.com>
	
	<1349786996.21847.153.camel@zakaz.uk.xensource.com>
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" ,
	"stefano.stabelini@citrix.com" ,
	"Keir \(Xen.org\)" , "JBeulich@suse.com" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 17/21] xen: xen_ulong_t substitution
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-09 at 13:51 +0100, Stefano Stabellini wrote:
> On Tue, 9 Oct 2012, Ian Campbell wrote:
> > On Tue, 2012-10-09 at 13:39 +0100, Stefano Stabellini wrote:
> > > On Fri, 5 Oct 2012, Ian Campbell wrote:
> > > > On Fri, 2012-10-05 at 11:38 +0100, Ian Campbell wrote:
> > > > > From: Stefano Stabellini 
> > > > > 
> > > > > There is still an unwanted unsigned long in the xen public interface:
> > > > > replace it with xen_ulong_t.
> > > > > 
> > > > > Also typedef xen_ulong_t to uint64_t on ARM.
> > > > 
> > > > Should this change be applied to the uses of XEN_GUEST_HANDLE(ulong)
> > > > too? My main concern is the one in struct gnttab_setup_table but there
> > > > are a few others.
> > > > 
> > > > I suspect XEN_GUEST_HANDLE(ulong) needs to be removed entirely,
> > > > everywhere it is used should be XEN_GUEST_HANDLE(xen_ulong_t) instead?
> > > 
> > > It is not necessary, because all the XEN_GUEST_HANDLE(ulong) are already
> > > 64 bit on ARM. A 32 bit guest is going to pass a 32 bit unsigned long in a
> > > 64 bit field, while a 64 bit guest is going to pass a 64 bit unsigned
> > > long in a 64 bit field. Either way it will work.
> > 
> > XEN_GUEST_HANDLE(ulong) is unsigned long on all platforms, see
> > xen/include/public/xen.h:
> >         __DEFINE_XEN_GUEST_HANDLE(ulong, unsigned long);
> > 
> > The existence of this handle is dangerous since it contains a type which
> > varies in size but it is (slightly) opaque so you might not notice.
> > 
> > The ulong handle is only really usable/desirable on x86 where retaining
> > the ABI requires us to use unsigned long for some fields, but we have
> > already defined xen_ulong_t which has the correct semantics on both ARM
> > and x86.
> > 
> > I propose the following.
> 
> It is certainly an improvement. Also I didn't notice the
> XEN_GUEST_HANDLE_PARAM(ulong): that is actually an error.
> We also need a corresponding patch for Linux.

I need to tesdt both this and the h/v side a bit more but here it is.

8<---------------------------

>From c55591bbe3b1d5164641075b95f3c95418bcdf79 Mon Sep 17 00:00:00 2001
From: Ian Campbell 
Date: Fri, 5 Oct 2012 17:39:19 +0100
Subject: [PATCH] xen: grant: use xen_pfn_t type for frame_list.

This correctly sizes it as 64 bit on ARM but leaves it as unsigned
long on x86 (therefore no intended change on x86).

The long and ulong guest handles are now unused (and a bit dangerous)
so remove them.

Signed-off-by: Ian Campbell 
---
 arch/arm/include/asm/xen/interface.h |    2 --
 arch/x86/include/asm/xen/interface.h |    2 --
 include/xen/interface/grant_table.h  |    2 +-
 3 files changed, 1 insertions(+), 5 deletions(-)

diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
index ad87917..9ac9f4e 100644
--- a/arch/arm/include/asm/xen/interface.h
+++ b/arch/arm/include/asm/xen/interface.h
@@ -35,10 +35,8 @@ typedef uint64_t xen_ulong_t;
 /* Guest handles for primitive C types. */
 __DEFINE_GUEST_HANDLE(uchar, unsigned char);
 __DEFINE_GUEST_HANDLE(uint,  unsigned int);
-__DEFINE_GUEST_HANDLE(ulong, unsigned long);
 DEFINE_GUEST_HANDLE(char);
 DEFINE_GUEST_HANDLE(int);
-DEFINE_GUEST_HANDLE(long);
 DEFINE_GUEST_HANDLE(void);
 DEFINE_GUEST_HANDLE(uint64_t);
 DEFINE_GUEST_HANDLE(uint32_t);
diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
index d67f3c6..ed602f8 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -55,10 +55,8 @@ typedef unsigned long xen_ulong_t;
 /* Guest handles for primitive C types. */
 __DEFINE_GUEST_HANDLE(uchar, unsigned char);
 __DEFINE_GUEST_HANDLE(uint,  unsigned int);
-__DEFINE_GUEST_HANDLE(ulong, unsigned long);
 DEFINE_GUEST_HANDLE(char);
 DEFINE_GUEST_HANDLE(int);
-DEFINE_GUEST_HANDLE(long);
 DEFINE_GUEST_HANDLE(void);
 DEFINE_GUEST_HANDLE(uint64_t);
 DEFINE_GUEST_HANDLE(uint32_t);
diff --git a/include/xen/interface/grant_table.h b/include/xen/interface/grant_table.h
index f9f8b97..e40fae9 100644
--- a/include/xen/interface/grant_table.h
+++ b/include/xen/interface/grant_table.h
@@ -310,7 +310,7 @@ struct gnttab_setup_table {
     uint32_t nr_frames;
     /* OUT parameters. */
     int16_t  status;              /* GNTST_* */
-    GUEST_HANDLE(ulong) frame_list;
+    GUEST_HANDLE(xen_pfn_t) frame_list;
 };
 DEFINE_GUEST_HANDLE_STRUCT(gnttab_setup_table);
 
-- 
1.7.2.5




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 13:16:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 13:16:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLZfP-0004OB-PG; Tue, 09 Oct 2012 13:16:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLZfN-0004NY-LW
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 13:16:09 +0000
Received: from [85.158.143.35:33584] by server-2.bemta-4.messagelabs.com id
	2F/E8-06610-89324705; Tue, 09 Oct 2012 13:16:08 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1349788565!13236207!1
X-Originating-IP: [209.85.217.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10398 invoked from network); 9 Oct 2012 13:16:06 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 13:16:06 -0000
Received: by mail-lb0-f173.google.com with SMTP id gj3so4529952lbb.32
	for ; Tue, 09 Oct 2012 06:16:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:to
	:subject:content-type:content-transfer-encoding;
	bh=a0l2GpvISfkqvk0uhCq1pCK8eGqDjO/z6bjNcOTfqR8=;
	b=CPY1gJkbiQQ6Iy2RFQbVfQR1mbyvxLQ5X8vDgmK8o/dzPLMWBi0FlW5NiKEXBCnRjG
	S/MM4IvAMtuchwpsaXeOZvLIfuhBWOG5zg2tA7t+xpUdS1VDQmAW6zm0Cw//j6rPNJuv
	GnJipc/xXhModfi3lqSlP9nBCUMREJVr+e2IwB3C+u8QVyMmdmFZ4FX3m/CKsFn9I+KO
	o8CFLR2bWVkywZKUtRTZ0LHZJVO30HJIhT1NfyJFk8lFxEWmq+PCSBUF94XFSFOBZ8Ww
	k2VVUShSLgGro5fVFtHNOuACaU1V87eSLZPKAZonYdAKgs0xEkesZ0zvi92zStLksCci
	osew==
Received: by 10.112.23.36 with SMTP id j4mr8064984lbf.71.1349788564682;
	Tue, 09 Oct 2012 06:16:04 -0700 (PDT)
Received: from [172.16.26.11] (b0fb2d09.bb.sky.com. [176.251.45.9])
	by mx.google.com with ESMTPS id jk8sm6335975lab.7.2012.10.09.06.16.03
	(version=SSLv3 cipher=OTHER); Tue, 09 Oct 2012 06:16:03 -0700 (PDT)
Message-ID: <50742391.2000505@xen.org>
Date: Tue, 09 Oct 2012 14:16:01 +0100
From: Lars Kurth 
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" , 
	"xen-api@lists.xen.org" ,
	xen-users@lists.xen.org, xen-arm@lists.xen.org
Subject: [Xen-devel] Xen Day Barcelona 2012, Nov 8th @ LinuxCon
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: lars.kurth@xen.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dear Communoity Members,

we are arranging a 1/2 meeting for Xen and XCP Users and Developers 
alongside LinuxCon Europe in Barcelona. The event goes from 9:00 - 13:00 
and is free. You will NOT need to register for LinuxCon to attend, but 
we do ask to register at 
http://www.xen.org/polls/xendaybarcelona2012_reg.html as space is very 
limited.

For more information see 
http://www.xen.org/community/events/xendaybarcelona2012.html

Topics that will be covered include:
* Virtualization in the Cloud: Featuring Xen and XCP
* Xen on ARM Cortex A15
* Xen 4.2 and xl
* Xen Benchmarks
* Meet the Xen Developers

Best Regards
Lars

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 13:16:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 13:16:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLZfP-0004OB-PG; Tue, 09 Oct 2012 13:16:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLZfN-0004NY-LW
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 13:16:09 +0000
Received: from [85.158.143.35:33584] by server-2.bemta-4.messagelabs.com id
	2F/E8-06610-89324705; Tue, 09 Oct 2012 13:16:08 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1349788565!13236207!1
X-Originating-IP: [209.85.217.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10398 invoked from network); 9 Oct 2012 13:16:06 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 13:16:06 -0000
Received: by mail-lb0-f173.google.com with SMTP id gj3so4529952lbb.32
	for ; Tue, 09 Oct 2012 06:16:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:to
	:subject:content-type:content-transfer-encoding;
	bh=a0l2GpvISfkqvk0uhCq1pCK8eGqDjO/z6bjNcOTfqR8=;
	b=CPY1gJkbiQQ6Iy2RFQbVfQR1mbyvxLQ5X8vDgmK8o/dzPLMWBi0FlW5NiKEXBCnRjG
	S/MM4IvAMtuchwpsaXeOZvLIfuhBWOG5zg2tA7t+xpUdS1VDQmAW6zm0Cw//j6rPNJuv
	GnJipc/xXhModfi3lqSlP9nBCUMREJVr+e2IwB3C+u8QVyMmdmFZ4FX3m/CKsFn9I+KO
	o8CFLR2bWVkywZKUtRTZ0LHZJVO30HJIhT1NfyJFk8lFxEWmq+PCSBUF94XFSFOBZ8Ww
	k2VVUShSLgGro5fVFtHNOuACaU1V87eSLZPKAZonYdAKgs0xEkesZ0zvi92zStLksCci
	osew==
Received: by 10.112.23.36 with SMTP id j4mr8064984lbf.71.1349788564682;
	Tue, 09 Oct 2012 06:16:04 -0700 (PDT)
Received: from [172.16.26.11] (b0fb2d09.bb.sky.com. [176.251.45.9])
	by mx.google.com with ESMTPS id jk8sm6335975lab.7.2012.10.09.06.16.03
	(version=SSLv3 cipher=OTHER); Tue, 09 Oct 2012 06:16:03 -0700 (PDT)
Message-ID: <50742391.2000505@xen.org>
Date: Tue, 09 Oct 2012 14:16:01 +0100
From: Lars Kurth 
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" , 
	"xen-api@lists.xen.org" ,
	xen-users@lists.xen.org, xen-arm@lists.xen.org
Subject: [Xen-devel] Xen Day Barcelona 2012, Nov 8th @ LinuxCon
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: lars.kurth@xen.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dear Communoity Members,

we are arranging a 1/2 meeting for Xen and XCP Users and Developers 
alongside LinuxCon Europe in Barcelona. The event goes from 9:00 - 13:00 
and is free. You will NOT need to register for LinuxCon to attend, but 
we do ask to register at 
http://www.xen.org/polls/xendaybarcelona2012_reg.html as space is very 
limited.

For more information see 
http://www.xen.org/community/events/xendaybarcelona2012.html

Topics that will be covered include:
* Virtualization in the Cloud: Featuring Xen and XCP
* Xen on ARM Cortex A15
* Xen 4.2 and xl
* Xen Benchmarks
* Meet the Xen Developers

Best Regards
Lars

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 13:17:15 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 13:17:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLZgG-0004VT-1W; Tue, 09 Oct 2012 13:17:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLZgE-0004V8-Ea
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 13:17:02 +0000
Received: from [85.158.139.83:31294] by server-13.bemta-5.messagelabs.com id
	0F/B6-06496-DC324705; Tue, 09 Oct 2012 13:17:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1349788620!29538369!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4121 invoked from network); 9 Oct 2012 13:17:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 13:17:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15038125"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 13:17:00 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	14:17:00 +0100
Message-ID: <1349788618.21847.170.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Sander Eikelenboom 
Date: Tue, 9 Oct 2012 14:16:58 +0100
In-Reply-To: <1305237695.20121009130733@eikelenboom.it>
References: 
	<729626082.20121006002054@eikelenboom.it>
	<20121007233444.GA26929@localhost.localdomain>
	<1349686461.18008.18.camel@zakaz.uk.xensource.com>
	<120335733.20121009042424@eikelenboom.it>
	<1349774588.21847.105.camel@zakaz.uk.xensource.com>
	<1305237695.20121009130733@eikelenboom.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk ,
	"xen-devel@lists.xensource.com" ,
	konrad 
Subject: Re: [Xen-devel] Kernel 3.7.0-pre-rc1 kernel BUG at
 drivers/net/xen-netback/netback.c:405 RIP: e030:[]
 [] netbk_gop_frag_copy+0x379/0x380
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-09 at 12:07 +0100, Sander Eikelenboom wrote:
> [  199.342570] netbk_gop_frag_copy: size 5a8 offset 7102
> [  199.342570]  => 76aa > 1000
> [  199.354626] netbk_gop_frag_copy failed: skb frag 0 page
> [  199.360930] copying from offset 7102, len 5a8

OK, this is now at least a real error. Making that last change
(belt&braces) you made shouldn't really have changed anything though :-(

> [  199.366887] page:ffffea0000b0aa00 count:3 mapcount:0 mapping:          (null) index:0x7f40fec00
> [  199.373008] page flags: 0x40000000004000(head)

The final 0x4000 is indeed PG_head as described, which makes this is a
compound page. This could arise either from the use of transparent huge
pages or via explicit __GFP_comp. It seems that the core networking
stuff can generate these after
69b08f62e174 "net: use bigger pages in __netdev_alloc_frag".

It's not clear to me that the r8169 driver uses those interfaces though,
seems like only tg3 does currently.

In any case it's not obvious how this interacts with bridging and
forwarding, since even if a receiving driver can handle this sort of
thing there's no guarantee that the resending driver can do so (e.g.
netback can't!).

This is one for netdev@ I think. I'll post there and CC you guys.

> [  199.379252] ------------[ cut here ]------------
> [  199.385247] kernel BUG at drivers/net/xen-netback/netback.c:548!
> [  199.391334] invalid opcode: 0000 [#1] PREEMPT SMP
> [  199.397446] Modules linked in:
> [  199.403450] CPU 4
> [  199.403500] Pid: 1183, comm: netback/4 Not tainted 3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)
> [  199.415401] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
> [  199.421690] RSP: e02b:ffff88003792bc20  EFLAGS: 00010282
> [  199.428048] RAX: 0000000000000001 RBX: ffff88003197c600 RCX: 0000000000000000
> [  199.434358] RDX: 0000000000000001 RSI: 0000000000000001 RDI: ffff8800379202b0
> [  199.440582] RBP: ffff88003792bd50 R08: 0000000000000002 R09: 0000000000000000
> [  199.446740] R10: 0000000000000001 R11: ffff88003a26c000 R12: 0000000000000030
> [  199.452965] R13: 0000000000000000 R14: ffff88002c2ae900 R15: 0000000000000001
> [  199.459203] FS:  00007fcec7740700(0000) GS:ffff88003f900000(0000) knlGS:0000000000000000
> [  199.465527] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> [  199.471735] CR2: 00007fff5f59c000 CR3: 0000000001c0b000 CR4: 0000000000000660
> [  199.477961] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [  199.484102] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [  199.490274] Process netback/4 (pid: 1183, threadinfo ffff88003792a000, task ffff880037cec140)
> [  199.496631] Stack:
> [  199.502834]  ffff88003792bd1c ffff880037cec7f0 ffff88003792bd00 ffff88003792bc80
> [  199.509198]  ffffffff00000001 00000000000005ea ffffc90010851a98 ffffc9001084cf30
> [  199.515579]  0000000001080083 ffffc9001084cee0 0000000000000000 ffff880032b449c0
> [  199.521944] Call Trace:
> [  199.528243]  [] ? trace_hardirqs_on+0xd/0x10
> [  199.534566]  [] xen_netbk_kthread+0xba/0xa90
> [  199.540826]  [] ? try_to_wake_up+0x1b6/0x310
> [  199.547193]  [] ? wake_up_bit+0x40/0x40
> [  199.553450]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
> [  199.559683]  [] kthread+0xd6/0xe0
> [  199.565827]  [] kernel_thread_helper+0x4/0x10
> [  199.572086]  [] ? retint_restore_args+0x13/0x13
> [  199.578268]  [] ? gs_change+0x13/0x13
> [  199.584344] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 36 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7
> [  199.597406] RIP  [] xen_netbk_rx_action+0x89a/0x910
> [  199.604013]  RSP 
> [  199.610610] ---[ end trace 03f82ac72747fb5a ]---
> [  199.990340] device vif11.0 entered promiscuous mode
> [  200.466710] xen-blkback:ring-ref 9, event-channel 10, protocol 1 (x86_64-abi)
> [  200.476634] xen_bridge: port 11(vif11.0) entered forwarding state
> [  200.483621] xen_bridge: port 11(vif11.0) entered forwarding state
> [  200.653782] pciback 0000:03:06.0: enabling device (0000 -> 0001)
> [  200.661499] xen: registering gsi 22 triggering 0 polarity 1
> [  200.669003] Already setup the GSI :22
> [  200.677345] pciback 0000:03:06.0: enabling bus mastering
> [  201.267297] xen_bridge: port 9(vif9.0) entered forwarding state
> [  205.151290] tty_init_dev: 2 callbacks suppressed
> [  206.534137] device vif12.0 entered promiscuous mode
> [  206.867366] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
> [  206.877552] xen_bridge: port 12(vif12.0) entered forwarding state
> [  206.884869] xen_bridge: port 12(vif12.0) entered forwarding state
> [  208.574036] xen_bridge: port 10(vif10.0) entered forwarding state
> [  209.979799] netbk_gop_frag_copy: size 1080 offset 0
> [  209.979799]  => 1080 > 1000
> [  209.994252] netbk_gop_frag_copy failed: skb frag 0 page
> [  210.001191] copying from offset 0, len 1080
> [  210.008121] page:ffffea0000b0a800 count:3 mapcount:0 mapping:          (null) index:0x7f40fec00
> [  210.015124] page flags: 0x40000000004000(head)
> [  210.022122] ------------[ cut here ]------------
> [  210.029035] kernel BUG at drivers/net/xen-netback/netback.c:548!
> [  210.035973] invalid opcode: 0000 [#2] PREEMPT SMP
> [  210.042819] Modules linked in:
> [  210.049467] CPU 0
> [  210.049518] Pid: 1179, comm: netback/0 Tainted: G      D      3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)
> [  210.062788] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
> [  210.069740] RSP: e02b:ffff880037923c20  EFLAGS: 00010282
> [  210.076711] RAX: 0000000000000001 RBX: ffff880031993ae0 RCX: 0000000000000000
> [  210.083744] RDX: ffff8800398a61e0 RSI: 0000000000000001 RDI: ffff8800379202b0
> [  210.090801] RBP: ffff880037923d50 R08: 0000000000000002 R09: 0000000000000000
> [  210.097787] R10: 0000000000000001 R11: ffff88003a26b330 R12: 0000000000000030
> [  210.104759] R13: 0000000000000000 R14: ffff88002b4d8800 R15: 0000000000000001
> [  210.111611] FS:  00007f695df80700(0000) GS:ffff88003f800000(0000) knlGS:0000000000000000
> [  210.118570] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> [  210.125586] CR2: 00007f695402e000 CR3: 0000000032a8f000 CR4: 0000000000000660
> [  210.132677] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [  210.139560] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [  210.146350] Process netback/0 (pid: 1179, threadinfo ffff880037922000, task ffff8800398a61e0)
> [  210.153213] Stack:
> [  210.159974]  ffff880037923d1c ffff880037922010 ffff880037923d00 ffff880037923c80
> [  210.166905]  ffffffff810800b5 0000000000000662 ffffc90010824bb8 ffffc90010820050
> [  210.173802]  0000000001080083 ffffc90010820000 0000000000000000 ffff8800375849c0
> [  210.180780] Call Trace:
> [  210.187656]  [] ? __alloc_workqueue_key+0x265/0x5d0
> [  210.194674]  [] ? trace_hardirqs_on+0xd/0x10
> [  210.201690]  [] xen_netbk_kthread+0xba/0xa90
> [  210.208659]  [] ? try_to_wake_up+0x1b6/0x310
> [  210.215688]  [] ? wake_up_bit+0x40/0x40
> [  210.222665]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
> [  210.229651]  [] kthread+0xd6/0xe0
> [  210.236455]  [] kernel_thread_helper+0x4/0x10
> [  210.243111]  [] ? retint_restore_args+0x13/0x13
> [  210.249687]  [] ? gs_change+0x13/0x13
> [  210.256195] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 36 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7
> [  210.270166] RIP  [] xen_netbk_rx_action+0x89a/0x910
> [  210.276925]  RSP 
> [  210.284112] ---[ end trace 03f82ac72747fb5b ]---
> [  213.634083] device vif13.0 entered promiscuous mode
> [  213.911267] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
> [  213.920749] vpn_bridge: port 1(vif13.0) entered forwarding state
> [  213.927480] vpn_bridge: port 1(vif13.0) entered forwarding state
> [  215.509632] xen_bridge: port 11(vif11.0) entered forwarding state
> [  215.825483] netbk_gop_frag_copy: size 2c1 offset 12d6
> [  215.825483]  => 1597 > 1000
> [  215.838666] netbk_gop_frag_copy failed: skb frag 0 page
> [  215.845265] copying from offset 12d6, len 2c1
> [  215.851790] page:ffffea0000b0a800 count:6 mapcount:0 mapping:          (null) index:0x7f40fec00
> [  215.858389] page flags: 0x40000000004000(head)
> [  215.864925] ------------[ cut here ]------------
> [  215.871426] kernel BUG at drivers/net/xen-netback/netback.c:548!
> [  215.878069] invalid opcode: 0000 [#3] PREEMPT SMP
> [  215.884696] Modules linked in:
> [  215.891258] CPU 3
> [  215.891308] Pid: 1182, comm: netback/3 Tainted: G      D      3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)
> [  215.904613] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
> [  215.911538] RSP: e02b:ffff880037929c20  EFLAGS: 00010282
> [  215.918336] RAX: 0000000000000001 RBX: ffff88002c361ee0 RCX: 0000000000000000
> [  215.925236] RDX: ffff880037ced190 RSI: 0000000000000001 RDI: ffff8800379202b0
> [  215.932144] RBP: ffff880037929d50 R08: 0000000000000002 R09: 0000000000000000
> [  215.938988] R10: 0000000000000001 R11: ffff88003a26aca0 R12: 0000000000000030
> [  215.945835] R13: 0000000000000000 R14: ffff88002b49b400 R15: 0000000000000001
> [  215.952652] FS:  00007f695c355700(0000) GS:ffff88003f8c0000(0000) knlGS:0000000000000000
> [  215.959476] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> [  215.966165] CR2: 00007faa79583000 CR3: 0000000032a8f000 CR4: 0000000000000660
> [  215.972789] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [  215.979339] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [  215.985844] Process netback/3 (pid: 1182, threadinfo ffff880037928000, task ffff880037ced190)
> [  215.992486] Stack:
> [  215.999085]  ffff880037929d1c ffff880037928010 ffff880037929d00 ffff880037929c80
> [  216.005896]  ffffffff810800b5 00000000000000ba ffffc900108466e0 ffffc90010841b78
> [  216.012651]  0000000101080083 ffffc90010841b28 0000000100000000 ffff880031a869c0
> [  216.019386] Call Trace:
> [  216.026026]  [] ? __alloc_workqueue_key+0x265/0x5d0
> [  216.032830]  [] ? trace_hardirqs_on+0xd/0x10
> [  216.039668]  [] xen_netbk_kthread+0xba/0xa90
> [  216.046435]  [] ? try_to_wake_up+0x1b6/0x310
> [  216.053094]  [] ? wake_up_bit+0x40/0x40
> [  216.059670]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
> [  216.066279]  [] kthread+0xd6/0xe0
> [  216.072817]  [] kernel_thread_helper+0x4/0x10
> [  216.079308]  [] ? retint_restore_args+0x13/0x13
> [  216.085783]  [] ? gs_change+0x13/0x13
> [  216.092234] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 36 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7
> [  216.106108] RIP  [] xen_netbk_rx_action+0x89a/0x910
> [  216.113118]  RSP 
> [  216.120011] ---[ end trace 03f82ac72747fb5c ]---
> [  219.765094] device vif14.0 entered promiscuous mode
> [  220.062152] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
> [  220.072238] xen_bridge: port 13(vif14.0) entered forwarding state
> [  220.079416] xen_bridge: port 13(vif14.0) entered forwarding state
> [  221.912781] xen_bridge: port 12(vif12.0) entered forwarding state
> [  222.876167] netbk_gop_frag_copy: size 2c1 offset 1858
> [  222.876167]  => 1b19 > 1000
> [  222.889279] netbk_gop_frag_copy failed: skb frag 0 page
> [  222.895959] copying from offset 1858, len 2c1
> [  222.902484] page:ffffea0000b0a800 count:8 mapcount:0 mapping:          (null) index:0x7f40fec00
> [  222.909119] page flags: 0x40000000004000(head)
> [  222.915711] ------------[ cut here ]------------
> [  222.922307] kernel BUG at drivers/net/xen-netback/netback.c:548!
> [  222.928950] invalid opcode: 0000 [#4] PREEMPT SMP
> [  222.935546] Modules linked in:
> [  222.942110] CPU 5
> [  222.942161] Pid: 1184, comm: netback/5 Tainted: G      D      3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)
> [  222.955415] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
> [  222.962350] RSP: e02b:ffff88003792dc20  EFLAGS: 00010282
> [  222.969198] RAX: 0000000000000001 RBX: ffff88002b4f4ce0 RCX: 0000000000000000
> [  222.976119] RDX: ffff880037ceb0f0 RSI: 0000000000000001 RDI: ffff8800379202b0
> [  222.982987] RBP: ffff88003792dd50 R08: 0000000000000002 R09: 0000000000000000
> [  222.989869] R10: 0000000000000001 R11: ffff88003a26b380 R12: 0000000000000030
> [  222.996658] R13: 0000000000000000 R14: ffff88002b5a7800 R15: 0000000000000001
> [  223.003490] FS:  00007f71c6ce2740(0000) GS:ffff88003f940000(0000) knlGS:0000000000000000
> [  223.010257] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> [  223.016868] CR2: 00007f71c66b4d15 CR3: 0000000031f46000 CR4: 0000000000000660
> [  223.023470] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [  223.029999] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [  223.036478] Process netback/5 (pid: 1184, threadinfo ffff88003792c000, task ffff880037ceb0f0)
> [  223.043095] Stack:
> [  223.049616]  ffff88003792dd1c ffff88003792c010 ffff88003792dd00 ffff88003792dc80
> [  223.056404]  ffffffff810800b5 00000000000000ba ffffc9001085ce50 ffffc900108582e8
> [  223.063150]  0000000101080083 ffffc90010858298 0000000100000000 ffff88002c38d9c0
> [  223.069955] Call Trace:
> [  223.076591]  [] ? __alloc_workqueue_key+0x265/0x5d0
> [  223.083426]  [] ? trace_hardirqs_on+0xd/0x10
> [  223.090261]  [] xen_netbk_kthread+0xba/0xa90
> [  223.096990]  [] ? try_to_wake_up+0x1b6/0x310
> [  223.103620]  [] ? wake_up_bit+0x40/0x40
> [  223.110195]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
> [  223.116768]  [] kthread+0xd6/0xe0
> [  223.123312]  [] kernel_thread_helper+0x4/0x10
> [  223.129794]  [] ? retint_restore_args+0x13/0x13
> [  223.136217]  [] ? gs_change+0x13/0x13
> [  223.142658] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 36 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7
> [  223.156486] RIP  [] xen_netbk_rx_action+0x89a/0x910
> [  223.163337]  RSP 
> [  223.170212] ---[ end trace 03f82ac72747fb5d ]---
> [  228.705439] device vif15.0 entered promiscuous mode
> [  228.880399] device vif15.0-emu entered promiscuous mode
> [  228.889286] xen_bridge: port 15(vif15.0-emu) entered forwarding state
> [  228.895546] xen_bridge: port 15(vif15.0-emu) entered forwarding state
> [  228.956267] vpn_bridge: port 1(vif13.0) entered forwarding state
> [  229.119709] pciback 0000:06:00.0: restoring config space at offset 0x3c (was 0x100, writing 0x10a)
> [  229.126644] pciback 0000:06:00.0: restoring config space at offset 0x10 (was 0x4, writing 0xf9a00004)
> [  229.133434] pciback 0000:06:00.0: restoring config space at offset 0xc (was 0x0, writing 0x10)
> [  234.170536] tty_init_dev: 15 callbacks suppressed
> [  235.092664] xen_bridge: port 13(vif14.0) entered forwarding state
> [  235.684229] device vif16.0 entered promiscuous mode
> [  235.805155] device vif16.0-emu entered promiscuous mode
> [  235.813948] xen_bridge: port 17(vif16.0-emu) entered forwarding state
> [  235.820242] xen_bridge: port 17(vif16.0-emu) entered forwarding state
> [  239.632852] xen_bridge: port 15(vif15.0-emu) entered disabled state
> [  239.641629] xen_bridge: port 15(vif15.0-emu) entered disabled state
> [  239.650288] device vif15.0-emu left promiscuous mode
> [  239.658618] xen_bridge: port 15(vif15.0-emu) entered disabled state
> [  240.982436] tty_init_dev: 15 callbacks suppressed
> [  241.386562] xen-blkback:ring-ref 8, event-channel 25, protocol 1 (x86_64-abi)
> [  241.400247] xen-blkback:ring-ref 9, event-channel 26, protocol 1 (x86_64-abi)
> [  241.454701] xen_bridge: port 14(vif15.0) entered forwarding state
> [  241.463330] xen_bridge: port 14(vif15.0) entered forwarding state
> [  246.690393] xen_bridge: port 17(vif16.0-emu) entered disabled state
> [  246.699042] xen_bridge: port 17(vif16.0-emu) entered disabled state
> [  246.708731] device vif16.0-emu left promiscuous mode
> [  246.717465] xen_bridge: port 17(vif16.0-emu) entered disabled state
> [  249.449321] xen-blkback:ring-ref 8, event-channel 25, protocol 1 (x86_64-abi)
> [  249.619531] xen_bridge: port 16(vif16.0) entered forwarding state
> [  249.628307] xen_bridge: port 16(vif16.0) entered forwarding state
> [  256.489967] xen_bridge: port 14(vif15.0) entered forwarding state
> [  264.654183] xen_bridge: port 16(vif16.0) entered forwarding state
> [  414.296535] tty_init_dev: 16 callbacks suppressed
> [  458.898093] netbk_gop_frag_copy: size 5a8 offset 3602
> [  458.898093]  => 3baa > 1000
> [  458.920252] netbk_gop_frag_copy failed: skb frag 0 page
> [  458.928746] copying from offset 3602, len 5a8
> [  458.937114] page:ffffea0000ada800 count:32749 mapcount:0 mapping:          (null) index:0xffff88002b6a6100
> [  458.945813] page flags: 0x40000000004000(head)
> [  458.954314] ------------[ cut here ]------------
> [  458.962655] kernel BUG at drivers/net/xen-netback/netback.c:548!
> [  458.970929] invalid opcode: 0000 [#5] PREEMPT SMP
> [  458.979113] Modules linked in:
> [  458.987128] CPU 1
> [  458.987178] Pid: 1180, comm: netback/1 Tainted: G      D      3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)
> [  459.003052] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
> [  459.011121] RSP: e02b:ffff880037925c20  EFLAGS: 00010282
> [  459.019135] RAX: 0000000000000001 RBX: ffff88002ab0bf00 RCX: 0000000000000000
> [  459.027199] RDX: ffff8800398a30f0 RSI: 0000000000000001 RDI: ffff8800379202b0
> [  459.035081] RBP: ffff880037925d50 R08: 0000000000000002 R09: 0000000000000000
> [  459.042816] R10: 0000000000000001 R11: ffff88003a26bdb0 R12: 0000000000000030
> [  459.050308] R13: 0000000000000000 R14: ffff88002b6a2e00 R15: 0000000000000001
> [  459.057725] FS:  00007f8e25af5760(0000) GS:ffff88003f840000(0000) knlGS:0000000000000000
> [  459.065052] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> [  459.072248] CR2: 00007fe6b4d12fb0 CR3: 000000002c2f6000 CR4: 0000000000000660
> [  459.079480] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [  459.086512] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [  459.093386] Process netback/1 (pid: 1180, threadinfo ffff880037924000, task ffff8800398a30f0)
> [  459.100357] Stack:
> [  459.107071]  ffff880037925d1c ffff880037924010 ffff880037925d00 ffff880037925c80
> [  459.113808]  ffffffff810800b5 000000000000042a ffffc9001082ff70 ffffc9001082b408
> [  459.120494]  0000000001080083 ffffc9001082b3b8 0000000000000000 ffff8800329249c0
> [  459.127129] Call Trace:
> [  459.133509]  [] ? __alloc_workqueue_key+0x265/0x5d0
> [  459.140118]  [] ? trace_hardirqs_on+0xd/0x10
> [  459.146604]  [] xen_netbk_kthread+0xba/0xa90
> [  459.153504]  [] ? try_to_wake_up+0x1b6/0x310
> [  459.159949]  [] ? wake_up_bit+0x40/0x40
> [  459.166431]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
> [  459.172778]  [] kthread+0xd6/0xe0
> [  459.179018]  [] kernel_thread_helper+0x4/0x10
> [  459.185291]  [] ? retint_restore_args+0x13/0x13
> [  459.191523]  [] ? gs_change+0x13/0x13
> [  459.197862] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 36 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7
> [  459.211184] RIP  [] xen_netbk_rx_action+0x89a/0x910
> [  459.217785]  RSP 
> [  459.224501] ---[ end trace 03f82ac72747fb5e ]---
> 
> 
> 
> 
> > This made me notice that offset and len in the caller are variously
> > unsigned int, u16 or u32 while gop_frag_copy takes them as unsigned
> > longs. None of the numbers involved here are anywhere big enough to
> > cause any sort of overflow related error though.
> 
> >> [  197.892781] page:ffffea0000b18400 count:3 mapcount:0 mapping:          (null) index:0x0
> >> [  197.900778] page flags: 0x40000000004000(head)
> >> [  197.907074] ------------[ cut here ]------------
> >> [  197.913345] kernel BUG at drivers/net/xen-netback/netback.c:546!
> >> [  197.919626] invalid opcode: 0000 [#1] PREEMPT SMP
> >> [  197.921573] xen_bridge: port 10(vif10.0) entered forwarding state
> >> [  197.932106] Modules linked in:
> >> [  197.938370] CPU 0
> >> [  197.938420] Pid: 1180, comm: netback/0 Not tainted 3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)
> >> [  197.951203] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
> >> [  197.957775] RSP: e02b:ffff880037911c20  EFLAGS: 00010282
> >> [  197.964290] RAX: 0000000000000001 RBX: ffff880036862ee0 RCX: 0000000000000000
> >> [  197.970956] RDX: 0000000000000001 RSI: 0000000000000001 RDI: ffff8800379102b0
> >> [  197.977679] RBP: ffff880037911d50 R08: 0000000000000002 R09: 0000000000000000
> >> [  197.984361] R10: 0000000000000001 R11: ffff880039925e40 R12: 0000000000000030
> >> [  197.990958] R13: 0000000000000000 R14: ffff880031e71800 R15: 0000000000000001
> >> [  197.997459] FS:  00007fb5dfcf7700(0000) GS:ffff88003f800000(0000) knlGS:0000000000000000
> >> [  198.004123] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> >> [  198.010827] CR2: 00007fb5d802d000 CR3: 0000000031fd3000 CR4: 0000000000000660
> >> [  198.017534] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> >> [  198.024168] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> >> [  198.030717] Process netback/0 (pid: 1180, threadinfo ffff880037910000, task ffff88003997d190)
> >> [  198.037326] Stack:
> >> [  198.043817]  ffff880037911d1c ffff88003997d840 ffff880037911d00 ffff880037911c80
> >> [  198.050573]  ffffffff00000001 0000000000000662 ffffc90010824bb8 ffffc90010820050
> >> [  198.057413]  0000000001080083 ffffc90010820000 0000000000000000 ffff880031cf09c0
> >> [  198.064228] Call Trace:
> >> [  198.070887]  [] ? trace_hardirqs_on+0xd/0x10
> >> [  198.077604]  [] xen_netbk_kthread+0xba/0xa90
> >> [  198.084394]  [] ? try_to_wake_up+0x1b6/0x310
> >> [  198.091109]  [] ? wake_up_bit+0x40/0x40
> >> [  198.097726]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
> >> [  198.104343]  [] kthread+0xd6/0xe0
> >> [  198.111001]  [] kernel_thread_helper+0x4/0x10
> >> [  198.117737]  [] ? retint_restore_args+0x13/0x13
> >> [  198.124425]  [] ? gs_change+0x13/0x13
> >> [  198.131008] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 46 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7
> >> [  198.145094] RIP  [] xen_netbk_rx_action+0x89a/0x910
> >> [  198.152192]  RSP 
> >> [  198.159344] ---[ end trace cbdd0e4e80268fa8 ]---
> >> [  199.703539] tty_init_dev: 2 callbacks suppressed
> >> [  200.712098] device vif12.0 entered promiscuous mode
> >> [  201.010433] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
> >> [  201.020644] xen_bridge: port 12(vif12.0) entered forwarding state
> >> [  201.027833] xen_bridge: port 12(vif12.0) entered forwarding state
> >> [  206.774576] netbk_gop_frag_copy failed: skb frag 0 page
> >> [  206.777945] device vif13.0 entered promiscuous mode
> >> [  206.788845] copying from offset 1ba4, len 2c1
> >> [  206.795791] page:ffffea0000b18400 count:6 mapcount:0 mapping:          (null) index:0x0
> >> [  206.802771] page flags: 0x40000000004000(head)
> >> [  206.809619] ------------[ cut here ]------------
> >> [  206.816498] kernel BUG at drivers/net/xen-netback/netback.c:546!
> >> [  206.823465] invalid opcode: 0000 [#2] PREEMPT SMP
> >> [  206.830354] Modules linked in:
> >> [  206.837176] CPU 3
> >> [  206.837234] Pid: 1183, comm: netback/3 Tainted: G      D      3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)
> >> [  206.850881] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
> >> [  206.857935] RSP: e02b:ffff880037917c20  EFLAGS: 00010282
> >> [  206.864972] RAX: 0000000000000001 RBX: ffff880003313ae0 RCX: 0000000000000000
> >> [  206.872049] RDX: ffff88003997b0f0 RSI: 0000000000000001 RDI: ffff8800379102b0
> >> [  206.879147] RBP: ffff880037917d50 R08: 0000000000000002 R09: 0000000000000000
> >> [  206.886242] R10: 0000000000000001 R11: ffff880039925640 R12: 0000000000000030
> >> [  206.893163] R13: 0000000000000000 R14: ffff88002c7c4400 R15: 0000000000000001
> >> [  206.900041] FS:  00007f800341a700(0000) GS:ffff88003f8c0000(0000) knlGS:0000000000000000
> >> [  206.907145] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> >> [  206.914126] CR2: 00007f8002b31fb0 CR3: 0000000001c0b000 CR4: 0000000000000660
> >> [  206.921181] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> >> [  206.927996] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> >> [  206.934711] Process netback/3 (pid: 1183, threadinfo ffff880037916000, task ffff88003997b0f0)
> >> [  206.941494] Stack:
> >> [  206.948105]  ffff880037917d1c ffff880037916010 ffff880037917d00 ffff880037917c80
> >> [  206.955062]  ffffffff810800b5 00000000000000ba ffffc900108466e0 ffffc90010841b78
> >> [  206.962007]  0000000101080083 ffffc90010841b28 0000000100000000 ffff88002c5bb9c0
> >> [  206.968967] Call Trace:
> >> [  206.975830]  [] ? __alloc_workqueue_key+0x265/0x5d0
> >> [  206.982789]  [] ? trace_hardirqs_on+0xd/0x10
> >> [  206.989662]  [] xen_netbk_kthread+0xba/0xa90
> >> [  206.996570]  [] ? try_to_wake_up+0x1b6/0x310
> >> [  207.003523]  [] ? wake_up_bit+0x40/0x40
> >> [  207.010333]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
> >> [  207.017171]  [] kthread+0xd6/0xe0
> >> [  207.023890]  [] kernel_thread_helper+0x4/0x10
> >> [  207.030540]  [] ? retint_restore_args+0x13/0x13
> >> [  207.037275]  [] ? gs_change+0x13/0x13
> >> [  207.043890] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 46 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7
> >> [  207.057976] RIP  [] xen_netbk_rx_action+0x89a/0x910
> >> [  207.065064]  RSP 
> >> [  207.072056] ---[ end trace cbdd0e4e80268fa9 ]---
> >> [  207.079366] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
> >> [  207.090256] vpn_bridge: port 1(vif13.0) entered forwarding state
> >> [  207.097403] vpn_bridge: port 1(vif13.0) entered forwarding state
> >> [  208.636257] xen_bridge: port 11(vif11.0) entered forwarding state
> >> [  211.515779] netbk_gop_frag_copy failed: skb frag 0 page
> >> [  211.522711] copying from offset 2126, len 2c1
> >> [  211.529403] page:ffffea0000b18400 count:8 mapcount:0 mapping:          (null) index:0x0
> >> [  211.536142] page flags: 0x40000000004000(head)
> >> [  211.542942] ------------[ cut here ]------------
> >> [  211.549664] kernel BUG at drivers/net/xen-netback/netback.c:546!
> >> [  211.556408] invalid opcode: 0000 [#3] PREEMPT SMP
> >> [  211.563168] Modules linked in:
> >> [  211.569739] CPU 4
> >> [  211.569789] Pid: 1184, comm: netback/4 Tainted: G      D      3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)
> >> [  211.583126] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
> >> [  211.590041] RSP: e02b:ffff880037921c20  EFLAGS: 00010282
> >> [  211.596868] RAX: 0000000000000001 RBX: ffff8800375bc4e0 RCX: 0000000000000000
> >> [  211.603890] RDX: ffff88003997a0a0 RSI: 0000000000000001 RDI: ffff8800379202b0
> >> [  211.610792] RBP: ffff880037921d50 R08: 0000000000000002 R09: 0000000000000000
> >> [  211.617608] R10: 0000000000000001 R11: ffff8800399249e0 R12: 0000000000000030
> >> [  211.624537] R13: 0000000000000000 R14: ffff88002b98d400 R15: 0000000000000001
> >> [  211.631302] FS:  00007f332d735740(0000) GS:ffff88003f900000(0000) knlGS:0000000000000000
> >> [  211.638090] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> >> [  211.644965] CR2: 00007f1023d22000 CR3: 0000000031fba000 CR4: 0000000000000660
> >> [  211.651894] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> >> [  211.658652] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> >> [  211.665288] Process netback/4 (pid: 1184, threadinfo ffff880037920000, task ffff88003997a0a0)
> >> [  211.671884] Stack:
> >> [  211.678376]  ffff880037921d1c ffff880037920010 ffff880037921d00 ffff880037921c80
> >> [  211.685145]  ffffffff810800b5 00000000000000ba ffffc90010851a98 ffffc9001084cf30
> >> [  211.691837]  0000000101080083 ffffc9001084cee0 0000000100000000 ffff88002c5bd9c0
> >> [  211.698581] Call Trace:
> >> [  211.705349]  [] ? __alloc_workqueue_key+0x265/0x5d0
> >> [  211.712156]  [] ? trace_hardirqs_on+0xd/0x10
> >> [  211.718907]  [] xen_netbk_kthread+0xba/0xa90
> >> [  211.725654]  [] ? try_to_wake_up+0x1b6/0x310
> >> [  211.732369]  [] ? wake_up_bit+0x40/0x40
> >> [  211.739111]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
> >> [  211.745858]  [] kthread+0xd6/0xe0
> >> [  211.752449]  [] kernel_thread_helper+0x4/0x10
> >> [  211.758975]  [] ? retint_restore_args+0x13/0x13
> >> [  211.765575]  [] ? gs_change+0x13/0x13
> >> [  211.772016] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 46 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7
> >> [  211.785816] RIP  [] xen_netbk_rx_action+0x89a/0x910
> >> [  211.792586]  RSP 
> >> [  211.799394] ---[ end trace cbdd0e4e80268faa ]---
> >> [  212.852714] device vif14.0 entered promiscuous mode
> >> [  213.234995] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
> >> [  213.245054] xen_bridge: port 13(vif14.0) entered forwarding state
> >> [  213.252087] xen_bridge: port 13(vif14.0) entered forwarding state
> >> [  214.691532] netbk_gop_frag_copy failed: skb frag 0 page
> >> [  214.698515] copying from offset 26a8, len 2c1
> >> [  214.705472] page:ffffea0000b18400 count:10 mapcount:0 mapping:          (null) index:0x0
> >> [  214.712415] page flags: 0x40000000004000(head)
> >> [  214.719170] ------------[ cut here ]------------
> >> [  214.725887] kernel BUG at drivers/net/xen-netback/netback.c:546!
> >> [  214.732563] invalid opcode: 0000 [#4] PREEMPT SMP
> >> [  214.739221] Modules linked in:
> >> [  214.745808] CPU 5
> >> [  214.745859] Pid: 1185, comm: netback/5 Tainted: G      D      3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)
> >> [  214.759156] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
> >> [  214.766127] RSP: e02b:ffff880037923c20  EFLAGS: 00010282
> >> [  214.773012] RAX: 0000000000000001 RBX: ffff8800379172e0 RCX: 0000000000000000
> >> [  214.780010] RDX: ffff880039ac8000 RSI: 0000000000000001 RDI: ffff8800379202b0
> >> [  214.786988] RBP: ffff880037923d50 R08: 0000000000000002 R09: 0000000000000000
> >> [  214.793870] R10: 0000000000000001 R11: ffff880039924460 R12: 0000000000000030
> >> [  214.800812] R13: 0000000000000000 R14: ffff88002b8b4800 R15: 0000000000000001
> >> [  214.807668] FS:  00007f236d331700(0000) GS:ffff88003f940000(0000) knlGS:0000000000000000
> >> [  214.814545] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> >> [  214.821415] CR2: 00007f236c42b6b0 CR3: 0000000039275000 CR4: 0000000000000660
> >> [  214.828435] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> >> [  214.835337] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> >> [  214.841963] Process netback/5 (pid: 1185, threadinfo ffff880037922000, task ffff880039ac8000)
> >> [  214.848655] Stack:
> >> [  214.855220]  ffff880037923d1c ffff880037922010 ffff880037923d00 ffff880037923c80
> >> [  214.861945]  ffffffff810800b5 00000000000000ba ffffc9001085ce50 ffffc900108582e8
> >> [  214.868699]  0000000101080083 ffffc90010858298 0000000100000000 ffff880031e939c0
> >> [  214.875477] Call Trace:
> >> [  214.882247]  [] ? __alloc_workqueue_key+0x265/0x5d0
> >> [  214.889083]  [] ? trace_hardirqs_on+0xd/0x10
> >> [  214.895851]  [] xen_netbk_kthread+0xba/0xa90
> >> [  214.902612]  [] ? try_to_wake_up+0x1b6/0x310
> >> [  214.909343]  [] ? wake_up_bit+0x40/0x40
> >> [  214.916115]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
> >> [  214.922856]  [] kthread+0xd6/0xe0
> >> [  214.929527]  [] kernel_thread_helper+0x4/0x10
> >> [  214.936178]  [] ? retint_restore_args+0x13/0x13
> >> [  214.942781]  [] ? gs_change+0x13/0x13
> >> [  214.949279] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 46 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7
> >> [  214.963107] RIP  [] xen_netbk_rx_action+0x89a/0x910
> >> [  214.969952]  RSP 
> >> [  214.976802] ---[ end trace cbdd0e4e80268fab ]---
> >> [  216.045946] xen_bridge: port 12(vif12.0) entered forwarding state
> >> [  220.405869] device vif15.0 entered promiscuous mode
> >> [  220.607946] device vif15.0-emu entered promiscuous mode
> >> [  220.625075] xen_bridge: port 15(vif15.0-emu) entered forwarding state
> >> [  220.633333] xen_bridge: port 15(vif15.0-emu) entered forwarding state
> >> [  220.890237] pciback 0000:06:00.0: restoring config space at offset 0x3c (was 0x100, writing 0x10a)
> >> [  220.898814] pciback 0000:06:00.0: restoring config space at offset 0x10 (was 0x4, writing 0xf9a00004)
> >> [  220.907406] pciback 0000:06:00.0: restoring config space at offset 0xc (was 0x0, writing 0x10)
> >> [  222.122750] vpn_bridge: port 1(vif13.0) entered forwarding state
> >> [  225.943971] tty_init_dev: 14 callbacks suppressed
> >> [  226.654618] device vif16.0 entered promiscuous mode
> >> [  226.775073] device vif16.0-emu entered promiscuous mode
> >> [  226.784025] xen_bridge: port 17(vif16.0-emu) entered forwarding state
> >> [  226.790188] xen_bridge: port 17(vif16.0-emu) entered forwarding state
> >> [  228.253024] xen_bridge: port 13(vif14.0) entered forwarding state
> >> [  229.788197] xen_bridge: port 15(vif15.0-emu) entered disabled state
> >> [  229.796826] xen_bridge: port 15(vif15.0-emu) entered disabled state
> >> [  229.805243] device vif15.0-emu left promiscuous mode
> >> [  229.813385] xen_bridge: port 15(vif15.0-emu) entered disabled state
> >> [  231.558329] xen-blkback:ring-ref 8, event-channel 25, protocol 1 (x86_64-abi)
> >> [  231.569080] xen-blkback:ring-ref 9, event-channel 26, protocol 1 (x86_64-abi)
> >> [  231.609663] xen_bridge: port 14(vif15.0) entered forwarding state
> >> [  231.617943] xen_bridge: port 14(vif15.0) entered forwarding state
> >> [  231.934347] tty_init_dev: 25 callbacks suppressed
> >>
> >>
> >>
> >>
> >>
> >>
> >> > Ian.
> >>
> >> > diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> >> > index 05593d8..ca4c47d 100644
> >> > --- a/drivers/net/xen-netback/netback.c
> >> > +++ b/drivers/net/xen-netback/netback.c
> >> > @@ -386,7 +386,7 @@ static struct netbk_rx_meta *get_next_rx_buffer(struct xenvif *vif,
> >> >   * Set up the grant operations for this fragment. If it's a flipping
> >> >   * interface, we also set up the unmap request from here.
> >> >   */
> >> > -static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
> >> > +static int netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
> >> >                                 struct netrx_pending_operations *npo,
> >> >                                 struct page *page, unsigned long size,
> >> >                                 unsigned long offset, int *head)
> >> > @@ -402,7 +402,8 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
> >> >         unsigned long bytes;
> >> >
> >> >         /* Data must not cross a page boundary. */
> >> > -       BUG_ON(size + offset > PAGE_SIZE);
> >> > +       if (size + offset > PAGE_SIZE)
> >> > +               return -1;
> >> >
> >> >         meta = npo->meta + npo->meta_prod - 1;
> >> >
> >> > @@ -459,6 +460,7 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
> >> >                 *head = 0; /* There must be something in this buffer now. */
> >> >
> >> >         }
> >> > +       return 0;
> >> >  }
> >> >
> >> >  /*
> >> > @@ -517,17 +519,31 @@ static int netbk_gop_skb(struct sk_buff *skb,
> >> >                 if (data + len > skb_tail_pointer(skb))
> >> >                         len = skb_tail_pointer(skb) - data;
> >> >
> >> > -               netbk_gop_frag_copy(vif, skb, npo,
> >> > -                                   virt_to_page(data), len, offset, &head);
> >> > +               if (netbk_gop_frag_copy(vif, skb, npo,
> >> > +                               virt_to_page(data), len, offset, &head) < 0) {
> >> > +printk(KERN_CRIT "netbk_gop_frag_copy failed: skb head %p-%p\n",
> >> +       skb->>data, skb_tail_pointer);
> >> > +printk(KERN_CRIT "copying from %p-%p, offset %x, len %x\n",
> >> > +       data, data+len, offset, len);
> >> > +dump_page(virt_to_page(data));
> >> > +BUG();
> >> > +               }
> >> >                 data += len;
> >> >         }
> >> >
> >> >         for (i = 0; i < nr_frags; i++) {
> >> > -               netbk_gop_frag_copy(vif, skb, npo,
> >> > +               if (netbk_gop_frag_copy(vif, skb, npo,
> >> >                                     skb_frag_page(&skb_shinfo(skb)->frags[i]),
> >> >                                     skb_frag_size(&skb_shinfo(skb)->frags[i]),
> >> >                                     skb_shinfo(skb)->frags[i].page_offset,
> >> > -                                   &head);
> >> > +                                   &head) < 0) {
> >> > +printk(KERN_CRIT "netbk_gop_frag_copy failed: skb frag %d page\n", i);
> >> > +printk(KERN_CRIT "copying from offset %x, len %x\n",
> >> > +       skb_shinfo(skb)->frags[i].page_offset,
> >> > +       skb_frag_size(&skb_shinfo(skb)->frags[i]));
> >> > +dump_page(skb_frag_page(&skb_shinfo(skb)->frags[i]));
> >> > +BUG();
> >> > +               }
> >> >         }
> >> >
> >> >         return npo->meta_prod - old_meta_prod;
> >>
> >>
> >>
> >>
> 
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 13:17:15 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 13:17:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLZgG-0004VT-1W; Tue, 09 Oct 2012 13:17:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLZgE-0004V8-Ea
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 13:17:02 +0000
Received: from [85.158.139.83:31294] by server-13.bemta-5.messagelabs.com id
	0F/B6-06496-DC324705; Tue, 09 Oct 2012 13:17:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1349788620!29538369!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4121 invoked from network); 9 Oct 2012 13:17:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 13:17:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15038125"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 13:17:00 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	14:17:00 +0100
Message-ID: <1349788618.21847.170.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Sander Eikelenboom 
Date: Tue, 9 Oct 2012 14:16:58 +0100
In-Reply-To: <1305237695.20121009130733@eikelenboom.it>
References: 
	<729626082.20121006002054@eikelenboom.it>
	<20121007233444.GA26929@localhost.localdomain>
	<1349686461.18008.18.camel@zakaz.uk.xensource.com>
	<120335733.20121009042424@eikelenboom.it>
	<1349774588.21847.105.camel@zakaz.uk.xensource.com>
	<1305237695.20121009130733@eikelenboom.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk ,
	"xen-devel@lists.xensource.com" ,
	konrad 
Subject: Re: [Xen-devel] Kernel 3.7.0-pre-rc1 kernel BUG at
 drivers/net/xen-netback/netback.c:405 RIP: e030:[]
 [] netbk_gop_frag_copy+0x379/0x380
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-09 at 12:07 +0100, Sander Eikelenboom wrote:
> [  199.342570] netbk_gop_frag_copy: size 5a8 offset 7102
> [  199.342570]  => 76aa > 1000
> [  199.354626] netbk_gop_frag_copy failed: skb frag 0 page
> [  199.360930] copying from offset 7102, len 5a8

OK, this is now at least a real error. Making that last change
(belt&braces) you made shouldn't really have changed anything though :-(

> [  199.366887] page:ffffea0000b0aa00 count:3 mapcount:0 mapping:          (null) index:0x7f40fec00
> [  199.373008] page flags: 0x40000000004000(head)

The final 0x4000 is indeed PG_head as described, which makes this is a
compound page. This could arise either from the use of transparent huge
pages or via explicit __GFP_comp. It seems that the core networking
stuff can generate these after
69b08f62e174 "net: use bigger pages in __netdev_alloc_frag".

It's not clear to me that the r8169 driver uses those interfaces though,
seems like only tg3 does currently.

In any case it's not obvious how this interacts with bridging and
forwarding, since even if a receiving driver can handle this sort of
thing there's no guarantee that the resending driver can do so (e.g.
netback can't!).

This is one for netdev@ I think. I'll post there and CC you guys.

> [  199.379252] ------------[ cut here ]------------
> [  199.385247] kernel BUG at drivers/net/xen-netback/netback.c:548!
> [  199.391334] invalid opcode: 0000 [#1] PREEMPT SMP
> [  199.397446] Modules linked in:
> [  199.403450] CPU 4
> [  199.403500] Pid: 1183, comm: netback/4 Not tainted 3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)
> [  199.415401] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
> [  199.421690] RSP: e02b:ffff88003792bc20  EFLAGS: 00010282
> [  199.428048] RAX: 0000000000000001 RBX: ffff88003197c600 RCX: 0000000000000000
> [  199.434358] RDX: 0000000000000001 RSI: 0000000000000001 RDI: ffff8800379202b0
> [  199.440582] RBP: ffff88003792bd50 R08: 0000000000000002 R09: 0000000000000000
> [  199.446740] R10: 0000000000000001 R11: ffff88003a26c000 R12: 0000000000000030
> [  199.452965] R13: 0000000000000000 R14: ffff88002c2ae900 R15: 0000000000000001
> [  199.459203] FS:  00007fcec7740700(0000) GS:ffff88003f900000(0000) knlGS:0000000000000000
> [  199.465527] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> [  199.471735] CR2: 00007fff5f59c000 CR3: 0000000001c0b000 CR4: 0000000000000660
> [  199.477961] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [  199.484102] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [  199.490274] Process netback/4 (pid: 1183, threadinfo ffff88003792a000, task ffff880037cec140)
> [  199.496631] Stack:
> [  199.502834]  ffff88003792bd1c ffff880037cec7f0 ffff88003792bd00 ffff88003792bc80
> [  199.509198]  ffffffff00000001 00000000000005ea ffffc90010851a98 ffffc9001084cf30
> [  199.515579]  0000000001080083 ffffc9001084cee0 0000000000000000 ffff880032b449c0
> [  199.521944] Call Trace:
> [  199.528243]  [] ? trace_hardirqs_on+0xd/0x10
> [  199.534566]  [] xen_netbk_kthread+0xba/0xa90
> [  199.540826]  [] ? try_to_wake_up+0x1b6/0x310
> [  199.547193]  [] ? wake_up_bit+0x40/0x40
> [  199.553450]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
> [  199.559683]  [] kthread+0xd6/0xe0
> [  199.565827]  [] kernel_thread_helper+0x4/0x10
> [  199.572086]  [] ? retint_restore_args+0x13/0x13
> [  199.578268]  [] ? gs_change+0x13/0x13
> [  199.584344] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 36 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7
> [  199.597406] RIP  [] xen_netbk_rx_action+0x89a/0x910
> [  199.604013]  RSP 
> [  199.610610] ---[ end trace 03f82ac72747fb5a ]---
> [  199.990340] device vif11.0 entered promiscuous mode
> [  200.466710] xen-blkback:ring-ref 9, event-channel 10, protocol 1 (x86_64-abi)
> [  200.476634] xen_bridge: port 11(vif11.0) entered forwarding state
> [  200.483621] xen_bridge: port 11(vif11.0) entered forwarding state
> [  200.653782] pciback 0000:03:06.0: enabling device (0000 -> 0001)
> [  200.661499] xen: registering gsi 22 triggering 0 polarity 1
> [  200.669003] Already setup the GSI :22
> [  200.677345] pciback 0000:03:06.0: enabling bus mastering
> [  201.267297] xen_bridge: port 9(vif9.0) entered forwarding state
> [  205.151290] tty_init_dev: 2 callbacks suppressed
> [  206.534137] device vif12.0 entered promiscuous mode
> [  206.867366] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
> [  206.877552] xen_bridge: port 12(vif12.0) entered forwarding state
> [  206.884869] xen_bridge: port 12(vif12.0) entered forwarding state
> [  208.574036] xen_bridge: port 10(vif10.0) entered forwarding state
> [  209.979799] netbk_gop_frag_copy: size 1080 offset 0
> [  209.979799]  => 1080 > 1000
> [  209.994252] netbk_gop_frag_copy failed: skb frag 0 page
> [  210.001191] copying from offset 0, len 1080
> [  210.008121] page:ffffea0000b0a800 count:3 mapcount:0 mapping:          (null) index:0x7f40fec00
> [  210.015124] page flags: 0x40000000004000(head)
> [  210.022122] ------------[ cut here ]------------
> [  210.029035] kernel BUG at drivers/net/xen-netback/netback.c:548!
> [  210.035973] invalid opcode: 0000 [#2] PREEMPT SMP
> [  210.042819] Modules linked in:
> [  210.049467] CPU 0
> [  210.049518] Pid: 1179, comm: netback/0 Tainted: G      D      3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)
> [  210.062788] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
> [  210.069740] RSP: e02b:ffff880037923c20  EFLAGS: 00010282
> [  210.076711] RAX: 0000000000000001 RBX: ffff880031993ae0 RCX: 0000000000000000
> [  210.083744] RDX: ffff8800398a61e0 RSI: 0000000000000001 RDI: ffff8800379202b0
> [  210.090801] RBP: ffff880037923d50 R08: 0000000000000002 R09: 0000000000000000
> [  210.097787] R10: 0000000000000001 R11: ffff88003a26b330 R12: 0000000000000030
> [  210.104759] R13: 0000000000000000 R14: ffff88002b4d8800 R15: 0000000000000001
> [  210.111611] FS:  00007f695df80700(0000) GS:ffff88003f800000(0000) knlGS:0000000000000000
> [  210.118570] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> [  210.125586] CR2: 00007f695402e000 CR3: 0000000032a8f000 CR4: 0000000000000660
> [  210.132677] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [  210.139560] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [  210.146350] Process netback/0 (pid: 1179, threadinfo ffff880037922000, task ffff8800398a61e0)
> [  210.153213] Stack:
> [  210.159974]  ffff880037923d1c ffff880037922010 ffff880037923d00 ffff880037923c80
> [  210.166905]  ffffffff810800b5 0000000000000662 ffffc90010824bb8 ffffc90010820050
> [  210.173802]  0000000001080083 ffffc90010820000 0000000000000000 ffff8800375849c0
> [  210.180780] Call Trace:
> [  210.187656]  [] ? __alloc_workqueue_key+0x265/0x5d0
> [  210.194674]  [] ? trace_hardirqs_on+0xd/0x10
> [  210.201690]  [] xen_netbk_kthread+0xba/0xa90
> [  210.208659]  [] ? try_to_wake_up+0x1b6/0x310
> [  210.215688]  [] ? wake_up_bit+0x40/0x40
> [  210.222665]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
> [  210.229651]  [] kthread+0xd6/0xe0
> [  210.236455]  [] kernel_thread_helper+0x4/0x10
> [  210.243111]  [] ? retint_restore_args+0x13/0x13
> [  210.249687]  [] ? gs_change+0x13/0x13
> [  210.256195] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 36 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7
> [  210.270166] RIP  [] xen_netbk_rx_action+0x89a/0x910
> [  210.276925]  RSP 
> [  210.284112] ---[ end trace 03f82ac72747fb5b ]---
> [  213.634083] device vif13.0 entered promiscuous mode
> [  213.911267] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
> [  213.920749] vpn_bridge: port 1(vif13.0) entered forwarding state
> [  213.927480] vpn_bridge: port 1(vif13.0) entered forwarding state
> [  215.509632] xen_bridge: port 11(vif11.0) entered forwarding state
> [  215.825483] netbk_gop_frag_copy: size 2c1 offset 12d6
> [  215.825483]  => 1597 > 1000
> [  215.838666] netbk_gop_frag_copy failed: skb frag 0 page
> [  215.845265] copying from offset 12d6, len 2c1
> [  215.851790] page:ffffea0000b0a800 count:6 mapcount:0 mapping:          (null) index:0x7f40fec00
> [  215.858389] page flags: 0x40000000004000(head)
> [  215.864925] ------------[ cut here ]------------
> [  215.871426] kernel BUG at drivers/net/xen-netback/netback.c:548!
> [  215.878069] invalid opcode: 0000 [#3] PREEMPT SMP
> [  215.884696] Modules linked in:
> [  215.891258] CPU 3
> [  215.891308] Pid: 1182, comm: netback/3 Tainted: G      D      3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)
> [  215.904613] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
> [  215.911538] RSP: e02b:ffff880037929c20  EFLAGS: 00010282
> [  215.918336] RAX: 0000000000000001 RBX: ffff88002c361ee0 RCX: 0000000000000000
> [  215.925236] RDX: ffff880037ced190 RSI: 0000000000000001 RDI: ffff8800379202b0
> [  215.932144] RBP: ffff880037929d50 R08: 0000000000000002 R09: 0000000000000000
> [  215.938988] R10: 0000000000000001 R11: ffff88003a26aca0 R12: 0000000000000030
> [  215.945835] R13: 0000000000000000 R14: ffff88002b49b400 R15: 0000000000000001
> [  215.952652] FS:  00007f695c355700(0000) GS:ffff88003f8c0000(0000) knlGS:0000000000000000
> [  215.959476] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> [  215.966165] CR2: 00007faa79583000 CR3: 0000000032a8f000 CR4: 0000000000000660
> [  215.972789] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [  215.979339] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [  215.985844] Process netback/3 (pid: 1182, threadinfo ffff880037928000, task ffff880037ced190)
> [  215.992486] Stack:
> [  215.999085]  ffff880037929d1c ffff880037928010 ffff880037929d00 ffff880037929c80
> [  216.005896]  ffffffff810800b5 00000000000000ba ffffc900108466e0 ffffc90010841b78
> [  216.012651]  0000000101080083 ffffc90010841b28 0000000100000000 ffff880031a869c0
> [  216.019386] Call Trace:
> [  216.026026]  [] ? __alloc_workqueue_key+0x265/0x5d0
> [  216.032830]  [] ? trace_hardirqs_on+0xd/0x10
> [  216.039668]  [] xen_netbk_kthread+0xba/0xa90
> [  216.046435]  [] ? try_to_wake_up+0x1b6/0x310
> [  216.053094]  [] ? wake_up_bit+0x40/0x40
> [  216.059670]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
> [  216.066279]  [] kthread+0xd6/0xe0
> [  216.072817]  [] kernel_thread_helper+0x4/0x10
> [  216.079308]  [] ? retint_restore_args+0x13/0x13
> [  216.085783]  [] ? gs_change+0x13/0x13
> [  216.092234] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 36 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7
> [  216.106108] RIP  [] xen_netbk_rx_action+0x89a/0x910
> [  216.113118]  RSP 
> [  216.120011] ---[ end trace 03f82ac72747fb5c ]---
> [  219.765094] device vif14.0 entered promiscuous mode
> [  220.062152] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
> [  220.072238] xen_bridge: port 13(vif14.0) entered forwarding state
> [  220.079416] xen_bridge: port 13(vif14.0) entered forwarding state
> [  221.912781] xen_bridge: port 12(vif12.0) entered forwarding state
> [  222.876167] netbk_gop_frag_copy: size 2c1 offset 1858
> [  222.876167]  => 1b19 > 1000
> [  222.889279] netbk_gop_frag_copy failed: skb frag 0 page
> [  222.895959] copying from offset 1858, len 2c1
> [  222.902484] page:ffffea0000b0a800 count:8 mapcount:0 mapping:          (null) index:0x7f40fec00
> [  222.909119] page flags: 0x40000000004000(head)
> [  222.915711] ------------[ cut here ]------------
> [  222.922307] kernel BUG at drivers/net/xen-netback/netback.c:548!
> [  222.928950] invalid opcode: 0000 [#4] PREEMPT SMP
> [  222.935546] Modules linked in:
> [  222.942110] CPU 5
> [  222.942161] Pid: 1184, comm: netback/5 Tainted: G      D      3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)
> [  222.955415] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
> [  222.962350] RSP: e02b:ffff88003792dc20  EFLAGS: 00010282
> [  222.969198] RAX: 0000000000000001 RBX: ffff88002b4f4ce0 RCX: 0000000000000000
> [  222.976119] RDX: ffff880037ceb0f0 RSI: 0000000000000001 RDI: ffff8800379202b0
> [  222.982987] RBP: ffff88003792dd50 R08: 0000000000000002 R09: 0000000000000000
> [  222.989869] R10: 0000000000000001 R11: ffff88003a26b380 R12: 0000000000000030
> [  222.996658] R13: 0000000000000000 R14: ffff88002b5a7800 R15: 0000000000000001
> [  223.003490] FS:  00007f71c6ce2740(0000) GS:ffff88003f940000(0000) knlGS:0000000000000000
> [  223.010257] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> [  223.016868] CR2: 00007f71c66b4d15 CR3: 0000000031f46000 CR4: 0000000000000660
> [  223.023470] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [  223.029999] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [  223.036478] Process netback/5 (pid: 1184, threadinfo ffff88003792c000, task ffff880037ceb0f0)
> [  223.043095] Stack:
> [  223.049616]  ffff88003792dd1c ffff88003792c010 ffff88003792dd00 ffff88003792dc80
> [  223.056404]  ffffffff810800b5 00000000000000ba ffffc9001085ce50 ffffc900108582e8
> [  223.063150]  0000000101080083 ffffc90010858298 0000000100000000 ffff88002c38d9c0
> [  223.069955] Call Trace:
> [  223.076591]  [] ? __alloc_workqueue_key+0x265/0x5d0
> [  223.083426]  [] ? trace_hardirqs_on+0xd/0x10
> [  223.090261]  [] xen_netbk_kthread+0xba/0xa90
> [  223.096990]  [] ? try_to_wake_up+0x1b6/0x310
> [  223.103620]  [] ? wake_up_bit+0x40/0x40
> [  223.110195]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
> [  223.116768]  [] kthread+0xd6/0xe0
> [  223.123312]  [] kernel_thread_helper+0x4/0x10
> [  223.129794]  [] ? retint_restore_args+0x13/0x13
> [  223.136217]  [] ? gs_change+0x13/0x13
> [  223.142658] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 36 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7
> [  223.156486] RIP  [] xen_netbk_rx_action+0x89a/0x910
> [  223.163337]  RSP 
> [  223.170212] ---[ end trace 03f82ac72747fb5d ]---
> [  228.705439] device vif15.0 entered promiscuous mode
> [  228.880399] device vif15.0-emu entered promiscuous mode
> [  228.889286] xen_bridge: port 15(vif15.0-emu) entered forwarding state
> [  228.895546] xen_bridge: port 15(vif15.0-emu) entered forwarding state
> [  228.956267] vpn_bridge: port 1(vif13.0) entered forwarding state
> [  229.119709] pciback 0000:06:00.0: restoring config space at offset 0x3c (was 0x100, writing 0x10a)
> [  229.126644] pciback 0000:06:00.0: restoring config space at offset 0x10 (was 0x4, writing 0xf9a00004)
> [  229.133434] pciback 0000:06:00.0: restoring config space at offset 0xc (was 0x0, writing 0x10)
> [  234.170536] tty_init_dev: 15 callbacks suppressed
> [  235.092664] xen_bridge: port 13(vif14.0) entered forwarding state
> [  235.684229] device vif16.0 entered promiscuous mode
> [  235.805155] device vif16.0-emu entered promiscuous mode
> [  235.813948] xen_bridge: port 17(vif16.0-emu) entered forwarding state
> [  235.820242] xen_bridge: port 17(vif16.0-emu) entered forwarding state
> [  239.632852] xen_bridge: port 15(vif15.0-emu) entered disabled state
> [  239.641629] xen_bridge: port 15(vif15.0-emu) entered disabled state
> [  239.650288] device vif15.0-emu left promiscuous mode
> [  239.658618] xen_bridge: port 15(vif15.0-emu) entered disabled state
> [  240.982436] tty_init_dev: 15 callbacks suppressed
> [  241.386562] xen-blkback:ring-ref 8, event-channel 25, protocol 1 (x86_64-abi)
> [  241.400247] xen-blkback:ring-ref 9, event-channel 26, protocol 1 (x86_64-abi)
> [  241.454701] xen_bridge: port 14(vif15.0) entered forwarding state
> [  241.463330] xen_bridge: port 14(vif15.0) entered forwarding state
> [  246.690393] xen_bridge: port 17(vif16.0-emu) entered disabled state
> [  246.699042] xen_bridge: port 17(vif16.0-emu) entered disabled state
> [  246.708731] device vif16.0-emu left promiscuous mode
> [  246.717465] xen_bridge: port 17(vif16.0-emu) entered disabled state
> [  249.449321] xen-blkback:ring-ref 8, event-channel 25, protocol 1 (x86_64-abi)
> [  249.619531] xen_bridge: port 16(vif16.0) entered forwarding state
> [  249.628307] xen_bridge: port 16(vif16.0) entered forwarding state
> [  256.489967] xen_bridge: port 14(vif15.0) entered forwarding state
> [  264.654183] xen_bridge: port 16(vif16.0) entered forwarding state
> [  414.296535] tty_init_dev: 16 callbacks suppressed
> [  458.898093] netbk_gop_frag_copy: size 5a8 offset 3602
> [  458.898093]  => 3baa > 1000
> [  458.920252] netbk_gop_frag_copy failed: skb frag 0 page
> [  458.928746] copying from offset 3602, len 5a8
> [  458.937114] page:ffffea0000ada800 count:32749 mapcount:0 mapping:          (null) index:0xffff88002b6a6100
> [  458.945813] page flags: 0x40000000004000(head)
> [  458.954314] ------------[ cut here ]------------
> [  458.962655] kernel BUG at drivers/net/xen-netback/netback.c:548!
> [  458.970929] invalid opcode: 0000 [#5] PREEMPT SMP
> [  458.979113] Modules linked in:
> [  458.987128] CPU 1
> [  458.987178] Pid: 1180, comm: netback/1 Tainted: G      D      3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)
> [  459.003052] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
> [  459.011121] RSP: e02b:ffff880037925c20  EFLAGS: 00010282
> [  459.019135] RAX: 0000000000000001 RBX: ffff88002ab0bf00 RCX: 0000000000000000
> [  459.027199] RDX: ffff8800398a30f0 RSI: 0000000000000001 RDI: ffff8800379202b0
> [  459.035081] RBP: ffff880037925d50 R08: 0000000000000002 R09: 0000000000000000
> [  459.042816] R10: 0000000000000001 R11: ffff88003a26bdb0 R12: 0000000000000030
> [  459.050308] R13: 0000000000000000 R14: ffff88002b6a2e00 R15: 0000000000000001
> [  459.057725] FS:  00007f8e25af5760(0000) GS:ffff88003f840000(0000) knlGS:0000000000000000
> [  459.065052] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> [  459.072248] CR2: 00007fe6b4d12fb0 CR3: 000000002c2f6000 CR4: 0000000000000660
> [  459.079480] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [  459.086512] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [  459.093386] Process netback/1 (pid: 1180, threadinfo ffff880037924000, task ffff8800398a30f0)
> [  459.100357] Stack:
> [  459.107071]  ffff880037925d1c ffff880037924010 ffff880037925d00 ffff880037925c80
> [  459.113808]  ffffffff810800b5 000000000000042a ffffc9001082ff70 ffffc9001082b408
> [  459.120494]  0000000001080083 ffffc9001082b3b8 0000000000000000 ffff8800329249c0
> [  459.127129] Call Trace:
> [  459.133509]  [] ? __alloc_workqueue_key+0x265/0x5d0
> [  459.140118]  [] ? trace_hardirqs_on+0xd/0x10
> [  459.146604]  [] xen_netbk_kthread+0xba/0xa90
> [  459.153504]  [] ? try_to_wake_up+0x1b6/0x310
> [  459.159949]  [] ? wake_up_bit+0x40/0x40
> [  459.166431]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
> [  459.172778]  [] kthread+0xd6/0xe0
> [  459.179018]  [] kernel_thread_helper+0x4/0x10
> [  459.185291]  [] ? retint_restore_args+0x13/0x13
> [  459.191523]  [] ? gs_change+0x13/0x13
> [  459.197862] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 36 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7
> [  459.211184] RIP  [] xen_netbk_rx_action+0x89a/0x910
> [  459.217785]  RSP 
> [  459.224501] ---[ end trace 03f82ac72747fb5e ]---
> 
> 
> 
> 
> > This made me notice that offset and len in the caller are variously
> > unsigned int, u16 or u32 while gop_frag_copy takes them as unsigned
> > longs. None of the numbers involved here are anywhere big enough to
> > cause any sort of overflow related error though.
> 
> >> [  197.892781] page:ffffea0000b18400 count:3 mapcount:0 mapping:          (null) index:0x0
> >> [  197.900778] page flags: 0x40000000004000(head)
> >> [  197.907074] ------------[ cut here ]------------
> >> [  197.913345] kernel BUG at drivers/net/xen-netback/netback.c:546!
> >> [  197.919626] invalid opcode: 0000 [#1] PREEMPT SMP
> >> [  197.921573] xen_bridge: port 10(vif10.0) entered forwarding state
> >> [  197.932106] Modules linked in:
> >> [  197.938370] CPU 0
> >> [  197.938420] Pid: 1180, comm: netback/0 Not tainted 3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)
> >> [  197.951203] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
> >> [  197.957775] RSP: e02b:ffff880037911c20  EFLAGS: 00010282
> >> [  197.964290] RAX: 0000000000000001 RBX: ffff880036862ee0 RCX: 0000000000000000
> >> [  197.970956] RDX: 0000000000000001 RSI: 0000000000000001 RDI: ffff8800379102b0
> >> [  197.977679] RBP: ffff880037911d50 R08: 0000000000000002 R09: 0000000000000000
> >> [  197.984361] R10: 0000000000000001 R11: ffff880039925e40 R12: 0000000000000030
> >> [  197.990958] R13: 0000000000000000 R14: ffff880031e71800 R15: 0000000000000001
> >> [  197.997459] FS:  00007fb5dfcf7700(0000) GS:ffff88003f800000(0000) knlGS:0000000000000000
> >> [  198.004123] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> >> [  198.010827] CR2: 00007fb5d802d000 CR3: 0000000031fd3000 CR4: 0000000000000660
> >> [  198.017534] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> >> [  198.024168] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> >> [  198.030717] Process netback/0 (pid: 1180, threadinfo ffff880037910000, task ffff88003997d190)
> >> [  198.037326] Stack:
> >> [  198.043817]  ffff880037911d1c ffff88003997d840 ffff880037911d00 ffff880037911c80
> >> [  198.050573]  ffffffff00000001 0000000000000662 ffffc90010824bb8 ffffc90010820050
> >> [  198.057413]  0000000001080083 ffffc90010820000 0000000000000000 ffff880031cf09c0
> >> [  198.064228] Call Trace:
> >> [  198.070887]  [] ? trace_hardirqs_on+0xd/0x10
> >> [  198.077604]  [] xen_netbk_kthread+0xba/0xa90
> >> [  198.084394]  [] ? try_to_wake_up+0x1b6/0x310
> >> [  198.091109]  [] ? wake_up_bit+0x40/0x40
> >> [  198.097726]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
> >> [  198.104343]  [] kthread+0xd6/0xe0
> >> [  198.111001]  [] kernel_thread_helper+0x4/0x10
> >> [  198.117737]  [] ? retint_restore_args+0x13/0x13
> >> [  198.124425]  [] ? gs_change+0x13/0x13
> >> [  198.131008] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 46 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7
> >> [  198.145094] RIP  [] xen_netbk_rx_action+0x89a/0x910
> >> [  198.152192]  RSP 
> >> [  198.159344] ---[ end trace cbdd0e4e80268fa8 ]---
> >> [  199.703539] tty_init_dev: 2 callbacks suppressed
> >> [  200.712098] device vif12.0 entered promiscuous mode
> >> [  201.010433] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
> >> [  201.020644] xen_bridge: port 12(vif12.0) entered forwarding state
> >> [  201.027833] xen_bridge: port 12(vif12.0) entered forwarding state
> >> [  206.774576] netbk_gop_frag_copy failed: skb frag 0 page
> >> [  206.777945] device vif13.0 entered promiscuous mode
> >> [  206.788845] copying from offset 1ba4, len 2c1
> >> [  206.795791] page:ffffea0000b18400 count:6 mapcount:0 mapping:          (null) index:0x0
> >> [  206.802771] page flags: 0x40000000004000(head)
> >> [  206.809619] ------------[ cut here ]------------
> >> [  206.816498] kernel BUG at drivers/net/xen-netback/netback.c:546!
> >> [  206.823465] invalid opcode: 0000 [#2] PREEMPT SMP
> >> [  206.830354] Modules linked in:
> >> [  206.837176] CPU 3
> >> [  206.837234] Pid: 1183, comm: netback/3 Tainted: G      D      3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)
> >> [  206.850881] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
> >> [  206.857935] RSP: e02b:ffff880037917c20  EFLAGS: 00010282
> >> [  206.864972] RAX: 0000000000000001 RBX: ffff880003313ae0 RCX: 0000000000000000
> >> [  206.872049] RDX: ffff88003997b0f0 RSI: 0000000000000001 RDI: ffff8800379102b0
> >> [  206.879147] RBP: ffff880037917d50 R08: 0000000000000002 R09: 0000000000000000
> >> [  206.886242] R10: 0000000000000001 R11: ffff880039925640 R12: 0000000000000030
> >> [  206.893163] R13: 0000000000000000 R14: ffff88002c7c4400 R15: 0000000000000001
> >> [  206.900041] FS:  00007f800341a700(0000) GS:ffff88003f8c0000(0000) knlGS:0000000000000000
> >> [  206.907145] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> >> [  206.914126] CR2: 00007f8002b31fb0 CR3: 0000000001c0b000 CR4: 0000000000000660
> >> [  206.921181] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> >> [  206.927996] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> >> [  206.934711] Process netback/3 (pid: 1183, threadinfo ffff880037916000, task ffff88003997b0f0)
> >> [  206.941494] Stack:
> >> [  206.948105]  ffff880037917d1c ffff880037916010 ffff880037917d00 ffff880037917c80
> >> [  206.955062]  ffffffff810800b5 00000000000000ba ffffc900108466e0 ffffc90010841b78
> >> [  206.962007]  0000000101080083 ffffc90010841b28 0000000100000000 ffff88002c5bb9c0
> >> [  206.968967] Call Trace:
> >> [  206.975830]  [] ? __alloc_workqueue_key+0x265/0x5d0
> >> [  206.982789]  [] ? trace_hardirqs_on+0xd/0x10
> >> [  206.989662]  [] xen_netbk_kthread+0xba/0xa90
> >> [  206.996570]  [] ? try_to_wake_up+0x1b6/0x310
> >> [  207.003523]  [] ? wake_up_bit+0x40/0x40
> >> [  207.010333]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
> >> [  207.017171]  [] kthread+0xd6/0xe0
> >> [  207.023890]  [] kernel_thread_helper+0x4/0x10
> >> [  207.030540]  [] ? retint_restore_args+0x13/0x13
> >> [  207.037275]  [] ? gs_change+0x13/0x13
> >> [  207.043890] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 46 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7
> >> [  207.057976] RIP  [] xen_netbk_rx_action+0x89a/0x910
> >> [  207.065064]  RSP 
> >> [  207.072056] ---[ end trace cbdd0e4e80268fa9 ]---
> >> [  207.079366] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
> >> [  207.090256] vpn_bridge: port 1(vif13.0) entered forwarding state
> >> [  207.097403] vpn_bridge: port 1(vif13.0) entered forwarding state
> >> [  208.636257] xen_bridge: port 11(vif11.0) entered forwarding state
> >> [  211.515779] netbk_gop_frag_copy failed: skb frag 0 page
> >> [  211.522711] copying from offset 2126, len 2c1
> >> [  211.529403] page:ffffea0000b18400 count:8 mapcount:0 mapping:          (null) index:0x0
> >> [  211.536142] page flags: 0x40000000004000(head)
> >> [  211.542942] ------------[ cut here ]------------
> >> [  211.549664] kernel BUG at drivers/net/xen-netback/netback.c:546!
> >> [  211.556408] invalid opcode: 0000 [#3] PREEMPT SMP
> >> [  211.563168] Modules linked in:
> >> [  211.569739] CPU 4
> >> [  211.569789] Pid: 1184, comm: netback/4 Tainted: G      D      3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)
> >> [  211.583126] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
> >> [  211.590041] RSP: e02b:ffff880037921c20  EFLAGS: 00010282
> >> [  211.596868] RAX: 0000000000000001 RBX: ffff8800375bc4e0 RCX: 0000000000000000
> >> [  211.603890] RDX: ffff88003997a0a0 RSI: 0000000000000001 RDI: ffff8800379202b0
> >> [  211.610792] RBP: ffff880037921d50 R08: 0000000000000002 R09: 0000000000000000
> >> [  211.617608] R10: 0000000000000001 R11: ffff8800399249e0 R12: 0000000000000030
> >> [  211.624537] R13: 0000000000000000 R14: ffff88002b98d400 R15: 0000000000000001
> >> [  211.631302] FS:  00007f332d735740(0000) GS:ffff88003f900000(0000) knlGS:0000000000000000
> >> [  211.638090] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> >> [  211.644965] CR2: 00007f1023d22000 CR3: 0000000031fba000 CR4: 0000000000000660
> >> [  211.651894] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> >> [  211.658652] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> >> [  211.665288] Process netback/4 (pid: 1184, threadinfo ffff880037920000, task ffff88003997a0a0)
> >> [  211.671884] Stack:
> >> [  211.678376]  ffff880037921d1c ffff880037920010 ffff880037921d00 ffff880037921c80
> >> [  211.685145]  ffffffff810800b5 00000000000000ba ffffc90010851a98 ffffc9001084cf30
> >> [  211.691837]  0000000101080083 ffffc9001084cee0 0000000100000000 ffff88002c5bd9c0
> >> [  211.698581] Call Trace:
> >> [  211.705349]  [] ? __alloc_workqueue_key+0x265/0x5d0
> >> [  211.712156]  [] ? trace_hardirqs_on+0xd/0x10
> >> [  211.718907]  [] xen_netbk_kthread+0xba/0xa90
> >> [  211.725654]  [] ? try_to_wake_up+0x1b6/0x310
> >> [  211.732369]  [] ? wake_up_bit+0x40/0x40
> >> [  211.739111]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
> >> [  211.745858]  [] kthread+0xd6/0xe0
> >> [  211.752449]  [] kernel_thread_helper+0x4/0x10
> >> [  211.758975]  [] ? retint_restore_args+0x13/0x13
> >> [  211.765575]  [] ? gs_change+0x13/0x13
> >> [  211.772016] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 46 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7
> >> [  211.785816] RIP  [] xen_netbk_rx_action+0x89a/0x910
> >> [  211.792586]  RSP 
> >> [  211.799394] ---[ end trace cbdd0e4e80268faa ]---
> >> [  212.852714] device vif14.0 entered promiscuous mode
> >> [  213.234995] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
> >> [  213.245054] xen_bridge: port 13(vif14.0) entered forwarding state
> >> [  213.252087] xen_bridge: port 13(vif14.0) entered forwarding state
> >> [  214.691532] netbk_gop_frag_copy failed: skb frag 0 page
> >> [  214.698515] copying from offset 26a8, len 2c1
> >> [  214.705472] page:ffffea0000b18400 count:10 mapcount:0 mapping:          (null) index:0x0
> >> [  214.712415] page flags: 0x40000000004000(head)
> >> [  214.719170] ------------[ cut here ]------------
> >> [  214.725887] kernel BUG at drivers/net/xen-netback/netback.c:546!
> >> [  214.732563] invalid opcode: 0000 [#4] PREEMPT SMP
> >> [  214.739221] Modules linked in:
> >> [  214.745808] CPU 5
> >> [  214.745859] Pid: 1185, comm: netback/5 Tainted: G      D      3.6.0pre-rc1-20121008bisect #1 MSI MS-7640/890FXA-GD70 (MS-7640)
> >> [  214.759156] RIP: e030:[]  [] xen_netbk_rx_action+0x89a/0x910
> >> [  214.766127] RSP: e02b:ffff880037923c20  EFLAGS: 00010282
> >> [  214.773012] RAX: 0000000000000001 RBX: ffff8800379172e0 RCX: 0000000000000000
> >> [  214.780010] RDX: ffff880039ac8000 RSI: 0000000000000001 RDI: ffff8800379202b0
> >> [  214.786988] RBP: ffff880037923d50 R08: 0000000000000002 R09: 0000000000000000
> >> [  214.793870] R10: 0000000000000001 R11: ffff880039924460 R12: 0000000000000030
> >> [  214.800812] R13: 0000000000000000 R14: ffff88002b8b4800 R15: 0000000000000001
> >> [  214.807668] FS:  00007f236d331700(0000) GS:ffff88003f940000(0000) knlGS:0000000000000000
> >> [  214.814545] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> >> [  214.821415] CR2: 00007f236c42b6b0 CR3: 0000000039275000 CR4: 0000000000000660
> >> [  214.828435] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> >> [  214.835337] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> >> [  214.841963] Process netback/5 (pid: 1185, threadinfo ffff880037922000, task ffff880039ac8000)
> >> [  214.848655] Stack:
> >> [  214.855220]  ffff880037923d1c ffff880037922010 ffff880037923d00 ffff880037923c80
> >> [  214.861945]  ffffffff810800b5 00000000000000ba ffffc9001085ce50 ffffc900108582e8
> >> [  214.868699]  0000000101080083 ffffc90010858298 0000000100000000 ffff880031e939c0
> >> [  214.875477] Call Trace:
> >> [  214.882247]  [] ? __alloc_workqueue_key+0x265/0x5d0
> >> [  214.889083]  [] ? trace_hardirqs_on+0xd/0x10
> >> [  214.895851]  [] xen_netbk_kthread+0xba/0xa90
> >> [  214.902612]  [] ? try_to_wake_up+0x1b6/0x310
> >> [  214.909343]  [] ? wake_up_bit+0x40/0x40
> >> [  214.916115]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
> >> [  214.922856]  [] kthread+0xd6/0xe0
> >> [  214.929527]  [] kernel_thread_helper+0x4/0x10
> >> [  214.936178]  [] ? retint_restore_args+0x13/0x13
> >> [  214.942781]  [] ? gs_change+0x13/0x13
> >> [  214.949279] Code: 00 00 00 42 8b 54 30 3c 41 8b 74 04 08 31 c0 e8 e5 37 2d 00 8b 83 c4 00 00 00 4c 03 b3 c8 00 00 00 4a 8b 7c 30 30 e8 46 24 c8 ff <0f> 0b eb fe 48 8b b3 d0 00 00 00 48 c7 c2 c0 36 47 81 48 c7 c7
> >> [  214.963107] RIP  [] xen_netbk_rx_action+0x89a/0x910
> >> [  214.969952]  RSP 
> >> [  214.976802] ---[ end trace cbdd0e4e80268fab ]---
> >> [  216.045946] xen_bridge: port 12(vif12.0) entered forwarding state
> >> [  220.405869] device vif15.0 entered promiscuous mode
> >> [  220.607946] device vif15.0-emu entered promiscuous mode
> >> [  220.625075] xen_bridge: port 15(vif15.0-emu) entered forwarding state
> >> [  220.633333] xen_bridge: port 15(vif15.0-emu) entered forwarding state
> >> [  220.890237] pciback 0000:06:00.0: restoring config space at offset 0x3c (was 0x100, writing 0x10a)
> >> [  220.898814] pciback 0000:06:00.0: restoring config space at offset 0x10 (was 0x4, writing 0xf9a00004)
> >> [  220.907406] pciback 0000:06:00.0: restoring config space at offset 0xc (was 0x0, writing 0x10)
> >> [  222.122750] vpn_bridge: port 1(vif13.0) entered forwarding state
> >> [  225.943971] tty_init_dev: 14 callbacks suppressed
> >> [  226.654618] device vif16.0 entered promiscuous mode
> >> [  226.775073] device vif16.0-emu entered promiscuous mode
> >> [  226.784025] xen_bridge: port 17(vif16.0-emu) entered forwarding state
> >> [  226.790188] xen_bridge: port 17(vif16.0-emu) entered forwarding state
> >> [  228.253024] xen_bridge: port 13(vif14.0) entered forwarding state
> >> [  229.788197] xen_bridge: port 15(vif15.0-emu) entered disabled state
> >> [  229.796826] xen_bridge: port 15(vif15.0-emu) entered disabled state
> >> [  229.805243] device vif15.0-emu left promiscuous mode
> >> [  229.813385] xen_bridge: port 15(vif15.0-emu) entered disabled state
> >> [  231.558329] xen-blkback:ring-ref 8, event-channel 25, protocol 1 (x86_64-abi)
> >> [  231.569080] xen-blkback:ring-ref 9, event-channel 26, protocol 1 (x86_64-abi)
> >> [  231.609663] xen_bridge: port 14(vif15.0) entered forwarding state
> >> [  231.617943] xen_bridge: port 14(vif15.0) entered forwarding state
> >> [  231.934347] tty_init_dev: 25 callbacks suppressed
> >>
> >>
> >>
> >>
> >>
> >>
> >> > Ian.
> >>
> >> > diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> >> > index 05593d8..ca4c47d 100644
> >> > --- a/drivers/net/xen-netback/netback.c
> >> > +++ b/drivers/net/xen-netback/netback.c
> >> > @@ -386,7 +386,7 @@ static struct netbk_rx_meta *get_next_rx_buffer(struct xenvif *vif,
> >> >   * Set up the grant operations for this fragment. If it's a flipping
> >> >   * interface, we also set up the unmap request from here.
> >> >   */
> >> > -static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
> >> > +static int netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
> >> >                                 struct netrx_pending_operations *npo,
> >> >                                 struct page *page, unsigned long size,
> >> >                                 unsigned long offset, int *head)
> >> > @@ -402,7 +402,8 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
> >> >         unsigned long bytes;
> >> >
> >> >         /* Data must not cross a page boundary. */
> >> > -       BUG_ON(size + offset > PAGE_SIZE);
> >> > +       if (size + offset > PAGE_SIZE)
> >> > +               return -1;
> >> >
> >> >         meta = npo->meta + npo->meta_prod - 1;
> >> >
> >> > @@ -459,6 +460,7 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
> >> >                 *head = 0; /* There must be something in this buffer now. */
> >> >
> >> >         }
> >> > +       return 0;
> >> >  }
> >> >
> >> >  /*
> >> > @@ -517,17 +519,31 @@ static int netbk_gop_skb(struct sk_buff *skb,
> >> >                 if (data + len > skb_tail_pointer(skb))
> >> >                         len = skb_tail_pointer(skb) - data;
> >> >
> >> > -               netbk_gop_frag_copy(vif, skb, npo,
> >> > -                                   virt_to_page(data), len, offset, &head);
> >> > +               if (netbk_gop_frag_copy(vif, skb, npo,
> >> > +                               virt_to_page(data), len, offset, &head) < 0) {
> >> > +printk(KERN_CRIT "netbk_gop_frag_copy failed: skb head %p-%p\n",
> >> +       skb->>data, skb_tail_pointer);
> >> > +printk(KERN_CRIT "copying from %p-%p, offset %x, len %x\n",
> >> > +       data, data+len, offset, len);
> >> > +dump_page(virt_to_page(data));
> >> > +BUG();
> >> > +               }
> >> >                 data += len;
> >> >         }
> >> >
> >> >         for (i = 0; i < nr_frags; i++) {
> >> > -               netbk_gop_frag_copy(vif, skb, npo,
> >> > +               if (netbk_gop_frag_copy(vif, skb, npo,
> >> >                                     skb_frag_page(&skb_shinfo(skb)->frags[i]),
> >> >                                     skb_frag_size(&skb_shinfo(skb)->frags[i]),
> >> >                                     skb_shinfo(skb)->frags[i].page_offset,
> >> > -                                   &head);
> >> > +                                   &head) < 0) {
> >> > +printk(KERN_CRIT "netbk_gop_frag_copy failed: skb frag %d page\n", i);
> >> > +printk(KERN_CRIT "copying from offset %x, len %x\n",
> >> > +       skb_shinfo(skb)->frags[i].page_offset,
> >> > +       skb_frag_size(&skb_shinfo(skb)->frags[i]));
> >> > +dump_page(skb_frag_page(&skb_shinfo(skb)->frags[i]));
> >> > +BUG();
> >> > +               }
> >> >         }
> >> >
> >> >         return npo->meta_prod - old_meta_prod;
> >>
> >>
> >>
> >>
> 
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 13:34:00 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 13:34:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLZw3-0005D4-UQ; Tue, 09 Oct 2012 13:33:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLZtl-0005B6-6O
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 13:31:01 +0000
Received: from [85.158.139.83:28091] by server-10.bemta-5.messagelabs.com id
	CA/92-16911-41724705; Tue, 09 Oct 2012 13:31:00 +0000
X-Env-Sender: dhowells@redhat.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1349789459!19994396!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTc1NzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29067 invoked from network); 9 Oct 2012 13:30:59 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-8.tower-182.messagelabs.com with SMTP;
	9 Oct 2012 13:30:59 -0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q99DUuux024399
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 9 Oct 2012 09:30:56 -0400
Received: from warthog.procyon.org.uk (ovpn-113-58.phx2.redhat.com
	[10.3.113.58])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q99DUqAm025291; Tue, 9 Oct 2012 09:30:53 -0400
From: David Howells 
To: konrad.wilk@oracle.com
Date: Tue, 09 Oct 2012 14:30:52 +0100
Message-ID: <30773.1349789452@warthog.procyon.org.uk>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
X-Mailman-Approved-At: Tue, 09 Oct 2012 13:33:23 +0000
Cc: dhowells@redhat.com, jeremy@goop.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Subject: [Xen-devel] [GIT PULL] Disintegrate UAPI for xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Can you merge the following branch into the xen tree please.

This is to complete part of the Userspace API (UAPI) disintegration for which
the preparatory patches were pulled recently.  After these patches, userspace
headers will be segregated into:

	include/uapi/linux/.../foo.h

for the userspace interface stuff, and:

	include/linux/.../foo.h

for the strictly kernel internal stuff.

---
The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8:

  Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900)

are available in the git repository at:


  git://git.infradead.org/users/dhowells/linux-headers.git tags/disintegrate-xen-20121009

for you to fetch changes up to 72503791edffe516848d0f01d377fa9cd0711970:

  UAPI: (Scripted) Disintegrate include/xen (2012-10-09 09:49:15 +0100)

----------------------------------------------------------------
UAPI Disintegration 2012-10-09

----------------------------------------------------------------
David Howells (1):
      UAPI: (Scripted) Disintegrate include/xen

 include/uapi/xen/Kbuild          | 2 ++
 include/{ => uapi}/xen/evtchn.h  | 0
 include/{ => uapi}/xen/privcmd.h | 0
 include/xen/Kbuild               | 2 --
 4 files changed, 2 insertions(+), 2 deletions(-)
 rename include/{ => uapi}/xen/evtchn.h (100%)
 rename include/{ => uapi}/xen/privcmd.h (100%)
.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 13:34:00 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 13:34:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLZw3-0005D4-UQ; Tue, 09 Oct 2012 13:33:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLZtl-0005B6-6O
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 13:31:01 +0000
Received: from [85.158.139.83:28091] by server-10.bemta-5.messagelabs.com id
	CA/92-16911-41724705; Tue, 09 Oct 2012 13:31:00 +0000
X-Env-Sender: dhowells@redhat.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1349789459!19994396!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTc1NzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29067 invoked from network); 9 Oct 2012 13:30:59 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-8.tower-182.messagelabs.com with SMTP;
	9 Oct 2012 13:30:59 -0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q99DUuux024399
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 9 Oct 2012 09:30:56 -0400
Received: from warthog.procyon.org.uk (ovpn-113-58.phx2.redhat.com
	[10.3.113.58])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q99DUqAm025291; Tue, 9 Oct 2012 09:30:53 -0400
From: David Howells 
To: konrad.wilk@oracle.com
Date: Tue, 09 Oct 2012 14:30:52 +0100
Message-ID: <30773.1349789452@warthog.procyon.org.uk>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
X-Mailman-Approved-At: Tue, 09 Oct 2012 13:33:23 +0000
Cc: dhowells@redhat.com, jeremy@goop.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Subject: [Xen-devel] [GIT PULL] Disintegrate UAPI for xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Can you merge the following branch into the xen tree please.

This is to complete part of the Userspace API (UAPI) disintegration for which
the preparatory patches were pulled recently.  After these patches, userspace
headers will be segregated into:

	include/uapi/linux/.../foo.h

for the userspace interface stuff, and:

	include/linux/.../foo.h

for the strictly kernel internal stuff.

---
The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8:

  Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900)

are available in the git repository at:


  git://git.infradead.org/users/dhowells/linux-headers.git tags/disintegrate-xen-20121009

for you to fetch changes up to 72503791edffe516848d0f01d377fa9cd0711970:

  UAPI: (Scripted) Disintegrate include/xen (2012-10-09 09:49:15 +0100)

----------------------------------------------------------------
UAPI Disintegration 2012-10-09

----------------------------------------------------------------
David Howells (1):
      UAPI: (Scripted) Disintegrate include/xen

 include/uapi/xen/Kbuild          | 2 ++
 include/{ => uapi}/xen/evtchn.h  | 0
 include/{ => uapi}/xen/privcmd.h | 0
 include/xen/Kbuild               | 2 --
 4 files changed, 2 insertions(+), 2 deletions(-)
 rename include/{ => uapi}/xen/evtchn.h (100%)
 rename include/{ => uapi}/xen/privcmd.h (100%)
.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 13:38:23 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 13:38:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLa0L-0005LD-Jr; Tue, 09 Oct 2012 13:37:49 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLa0K-0005L4-LN
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 13:37:48 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-15.tower-27.messagelabs.com!1349789860!2021842!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4203 invoked from network); 9 Oct 2012 13:37:42 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Oct 2012 13:37:42 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.154599885;
	Tue, 09 Oct 2012 09:37:34 -0400
Message-ID: <5074284B.1050402@jhuapl.edu>
Date: Tue, 09 Oct 2012 09:36:11 -0400
From: Matthew Fioravante 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell 
References: <1349460132-13853-1-git-send-email-matthew.fioravante@jhuapl.edu>
	<1349460132-13853-3-git-send-email-matthew.fioravante@jhuapl.edu>
	<1349778775.21847.132.camel@zakaz.uk.xensource.com>
In-Reply-To: <1349778775.21847.132.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.4
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH vtpm v2 11/12] add vtpm support to libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============5187726707256683994=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============5187726707256683994==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080806030800010400010107"

This is a cryptographically signed message in MIME format.

--------------ms080806030800010400010107
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 10/09/2012 06:32 AM, Ian Campbell wrote:
> IIRC you are reworking the vtpm stuff to only support the stub domaun
> model and not the process model -- does this mean this patch will chang=
e
> or is this already only doing stub stuff?
Since I'm not removing the process model, its possible that this. the
tpm mini-os drivers, and the linux vtpm drivers might change slightly.
Would you prefer I held off on these last 2 patches until the changes
are finalized?
>
>> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
>> index 1606eb1..17094ca 100644
>> --- a/tools/libxl/libxl.c
>> +++ b/tools/libxl/libxl.c
>> @@ -1726,6 +1726,246 @@ out:
>>  }
>>
>>  /********************************************************************=
**********/
>> +int libxl__device_vtpm_setdefault(libxl__gc *gc, libxl_device_vtpm *v=
tpm)
>> +{
>> +   if(libxl_uuid_is_nil(&vtpm->uuid)) {
>> +      libxl_uuid_generate(&vtpm->uuid);
>> +   }
>> +   return 0;
>> +}
>> +
>> +static int libxl__device_from_vtpm(libxl__gc *gc, uint32_t domid,
>> +                                   libxl_device_vtpm *vtpm,
>> +                                   libxl__device *device)
>> +{
>> +   device->backend_devid   =3D vtpm->devid;
>> +   device->backend_domid   =3D vtpm->backend_domid;
>> +   device->backend_kind    =3D LIBXL__DEVICE_KIND_VTPM;
>> +   device->devid           =3D vtpm->devid;
>> +   device->domid           =3D domid;
>> +   device->kind            =3D LIBXL__DEVICE_KIND_VTPM;
>> +
>> +   return 0;
>> +}
>> +
>> +void libxl__device_vtpm_add(libxl__egc *egc, uint32_t domid,
>> +                           libxl_device_vtpm *vtpm,
>> +                           libxl__ao_device *aodev)
>> +{
>> +    STATE_AO_GC(aodev->ao);
>> +    flexarray_t *front;
>> +    flexarray_t *back;
>> +    libxl__device *device;
>> +    char *dompath, **l;
>> +    unsigned int nb, rc;
>> +
>> +    rc =3D libxl__device_vtpm_setdefault(gc, vtpm);
>> +    if (rc) goto out;
>> +
>> +    front =3D flexarray_make(16, 1);
> Sorry but in the meantime the flexarray interface has changed, it now
> accepts a gc -- see commit 25991:5c6b72b62bd7.
Will fix
>
>
>> +    if (!front) {
>> +        rc =3D ERROR_NOMEM;
>> +        goto out;
>> +    }
>> +    back =3D flexarray_make(16, 1);
>> +    if (!back) {
>> +        rc =3D ERROR_NOMEM;
>> +        goto out;
>> +    }
>> +
>> +    if(vtpm->devid =3D=3D -1) {
>> +        if (!(dompath =3D libxl__xs_get_dompath(gc, domid))) {
>> +            rc =3D ERROR_FAIL;
>> +            goto out_free;
>> +        }
>> +        l =3D libxl__xs_directory(gc, XBT_NULL, libxl__sprintf(gc, "%=
s/device/vtpm", dompath), &nb);
> You have some very long lines in this patch. Can you try and keep it to=

> 75-80 characters please.
>
> There are various helper macros like GCSPRINTF which can help to reduce=

> the length of lines. Also you might find the LOG* macros useful instead=

> of the more verbose LIBXL__LOG*.
noted
>
> [...]
>
>> +    flexarray_append(back, "instance"); /* MAYBE CAN GET RID OF THIS =
*/
>> +    flexarray_append(back, "0");
>> +    flexarray_append(back, "pref_instance"); /* MAYBE CAN GET RID OF =
THIS */
>> +    flexarray_append(back, "0");
>> +    flexarray_append(back, "resume");
>> +    flexarray_append(back, "False");
>> +    flexarray_append(back, "ready"); /* MAYBE CAN GET RID OF THIS */
>> +    flexarray_append(back, "1");
> Can we decide now or is this a future work thing?
These will probably be removed from the driver now that the process
model is gone.
>
> Not a lot of existing code uses it but we have flexarray_append_pair
> which can clarify the pairing of keys and values if you would like to
> use it.
Probably makes code a little more readable, ill look into it.
>
>> +static void libxl__device_vtpm_from_xs_fe(libxl__gc *gc,
>> +                                          const char* fe_path,
>> +                                          libxl_device_vtpm *vtpm)
>>
> Other devices have from_xs_be not fe. This is because we "trust" the be=

> to be less malicious.
will rework
>
>> +{
>> [...]
>> +   tmp =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/uuid",=
 fe_path));
>> +   if(tmp) {
>> +      libxl_uuid_from_string(&(vtpm->uuid), tmp);
>> +   }
>> +}
>> [...]
>> +int libxl_device_vtpm_getinfo(libxl_ctx *ctx, uint32_t domid,
>> +                               libxl_device_vtpm *vtpm, libxl_vtpminf=
o *vtpminfo)
>> +{
>> [...]
>> +    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/uuid"=
, vtpminfo->backend));
>> +    if(val =3D=3D NULL) {
>> +       LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s/uuid does not exist!\n",=
 vtpminfo->backend);
>> +       goto err;
>> +    }
>> +    if(libxl_uuid_from_string(&(vtpminfo->uuid), val)) {
>> +       LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s/uuid is a malformed uuid=
?? (%s) Probably a bug!\n", vtpminfo->backend, val);
>> +       goto err;
> This is fatal here but not in from_xs_fe?
>
>> +static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multidev *=
multidev, int ret) {
> brace on next line please.
>
>> +   libxl__domain_create_state *dcs =3D CONTAINER_OF(multidev, *dcs, m=
ultidev);
>> +   STATE_AO_GC(dcs->ao);
>> +   int domid =3D dcs->guest_domid;
>> +
>> +   libxl_domain_config* const d_config =3D dcs->guest_config;
>> +
>> +   if(ret) {
>> +      LOG(ERROR, "unable to add nic devices");
>> +      goto error_out;
>> +   }
> Four space indents above please.
>
>> +    /* Plug vtpm devices */
>> +    if (d_config->num_vtpms > 0) {
>> +        /* Attach vtpms */
>> +        libxl__multidev_begin(ao, &dcs->multidev);
>> +        dcs->multidev.callback =3D domcreate_attach_pci;
>> +        libxl__add_vtpms(egc, ao, domid, d_config, &dcs->multidev);
>> +        libxl__multidev_prepared(egc, &dcs->multidev, 0);
>> +        return;
>> +    }
> This indent is ok.
>
>> +
>> +   domcreate_attach_pci(egc, multidev, 0);
>> +   return;
>> +
>> +error_out:
>> +   assert(ret);
>> +   domcreate_complete(egc, dcs, ret);
> But here we've gone back to 3 spaces again.
>
>> diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
>> index 55cd299..73a158a 100644
>> --- a/tools/libxl/libxl_utils.c
>> +++ b/tools/libxl/libxl_utils.c
>> @@ -463,6 +463,35 @@ int libxl_pipe(libxl_ctx *ctx, int pipes[2])
>>      return 0;
>>  }
>>
>> +int libxl_uuid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid,
>> +                            libxl_uuid* uuid, libxl_device_vtpm *vtpm=
)
>> +{
>> +    libxl_device_vtpm *vtpms;
>> +    int nb, i;
>> +    int rc;
>> +
>> +    vtpms =3D libxl_device_vtpm_list(ctx, domid, &nb);
>> +    if (!vtpms)
>> +        return ERROR_FAIL;
>> +
>> +    memset(vtpm, 0, sizeof (libxl_device_vtpm));
>> +    rc =3D 1;
>> +    for (i =3D 0; i < nb; ++i) {
>> +        if(!libxl_uuid_compare(uuid, &vtpms[i].uuid)) {
>> +            vtpm->backend_domid =3D vtpms[i].backend_domid;
>> +            vtpm->devid =3D vtpms[i].devid;
>> +            libxl_uuid_copy(&vtpm->uuid, &vtpms[i].uuid);
>> +            rc =3D 0;
>> +            break;
>> +        }
>> +    }
>> +
>> +    for (i=3D0; i> +        libxl_device_vtpm_dispose(&vtpms[i]);
>> +    free(vtpms);
> I think I saw this a few times (probably copied from elsewhere) but the=

> modern alternative is to define libxl_THING_list_free and use that to
> free the result of libxl_THING_list.
>
> We just didn't go back and change all the existing instances when we di=
d
> this.
>
>
>> diff --git a/tools/libxl/xl_cmdtable.c b/tools/libxl/xl_cmdtable.c
>> index 85ea768..7c018eb 100644
>> --- a/tools/libxl/xl_cmdtable.c
>> +++ b/tools/libxl/xl_cmdtable.c
>> @@ -338,6 +338,21 @@ struct cmd_spec cmd_table[] =3D {
>>        "Destroy a domain's virtual block device",
>>        " ",
>>      },
>> +    { "vtpm-attach",
>> +      &main_vtpmattach, 0, 1,
>> +      "Create a new virtual TPM device",
>> +      " [uuid=3D] [backend=3D]",
>> +    },
>> +    { "vtpm-list",
>> +      &main_vtpmlist, 0, 0,
> I think you want the first 0 to be 1 since you do support dry run in
> this command
agreed, must have been a typo
>
>> +      "List virtual TPM devices for a domain",
>> +      "",
>> +    },
>> +    { "vtpm-detach",
>> +      &main_vtpmdetach, 0, 1,
>> +      "Destroy a domain's virtual TPM device",
>> +      " ",
>> +    },
>>      { "uptime",
>>        &main_uptime, 0, 0,
>>        "Print uptime for all/some domains",
>> --
>> 1.7.4.4
>>
>



--------------ms080806030800010400010107
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMTAwOTEzMzYxMVowIwYJKoZIhvcNAQkEMRYEFCXQoBS5LZBmK9eg
PtEnGzrStFJBMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAnnBk4lXZOgBgkbnbRGb8wSPyDwLjWm/AR
V3lpPeEgplIZBAJcmstAbBdK/e60AagPMcuDJV6716kwzlYfuZRyPeGxxQSee3XUPOBar6/5
Svxemu3447pCYfE/DfqP/L+WlGcuNFH2utRmdIQpnc4RaH/6pj+gvp9Dvf4RA+im5wAAAAAA
AA==
--------------ms080806030800010400010107--


--===============5187726707256683994==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5187726707256683994==--


From xen-devel-bounces@lists.xen.org Tue Oct 09 13:38:23 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 13:38:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLa0L-0005LD-Jr; Tue, 09 Oct 2012 13:37:49 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLa0K-0005L4-LN
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 13:37:48 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-15.tower-27.messagelabs.com!1349789860!2021842!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4203 invoked from network); 9 Oct 2012 13:37:42 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Oct 2012 13:37:42 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.154599885;
	Tue, 09 Oct 2012 09:37:34 -0400
Message-ID: <5074284B.1050402@jhuapl.edu>
Date: Tue, 09 Oct 2012 09:36:11 -0400
From: Matthew Fioravante 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell 
References: <1349460132-13853-1-git-send-email-matthew.fioravante@jhuapl.edu>
	<1349460132-13853-3-git-send-email-matthew.fioravante@jhuapl.edu>
	<1349778775.21847.132.camel@zakaz.uk.xensource.com>
In-Reply-To: <1349778775.21847.132.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.4
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH vtpm v2 11/12] add vtpm support to libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============5187726707256683994=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============5187726707256683994==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080806030800010400010107"

This is a cryptographically signed message in MIME format.

--------------ms080806030800010400010107
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 10/09/2012 06:32 AM, Ian Campbell wrote:
> IIRC you are reworking the vtpm stuff to only support the stub domaun
> model and not the process model -- does this mean this patch will chang=
e
> or is this already only doing stub stuff?
Since I'm not removing the process model, its possible that this. the
tpm mini-os drivers, and the linux vtpm drivers might change slightly.
Would you prefer I held off on these last 2 patches until the changes
are finalized?
>
>> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
>> index 1606eb1..17094ca 100644
>> --- a/tools/libxl/libxl.c
>> +++ b/tools/libxl/libxl.c
>> @@ -1726,6 +1726,246 @@ out:
>>  }
>>
>>  /********************************************************************=
**********/
>> +int libxl__device_vtpm_setdefault(libxl__gc *gc, libxl_device_vtpm *v=
tpm)
>> +{
>> +   if(libxl_uuid_is_nil(&vtpm->uuid)) {
>> +      libxl_uuid_generate(&vtpm->uuid);
>> +   }
>> +   return 0;
>> +}
>> +
>> +static int libxl__device_from_vtpm(libxl__gc *gc, uint32_t domid,
>> +                                   libxl_device_vtpm *vtpm,
>> +                                   libxl__device *device)
>> +{
>> +   device->backend_devid   =3D vtpm->devid;
>> +   device->backend_domid   =3D vtpm->backend_domid;
>> +   device->backend_kind    =3D LIBXL__DEVICE_KIND_VTPM;
>> +   device->devid           =3D vtpm->devid;
>> +   device->domid           =3D domid;
>> +   device->kind            =3D LIBXL__DEVICE_KIND_VTPM;
>> +
>> +   return 0;
>> +}
>> +
>> +void libxl__device_vtpm_add(libxl__egc *egc, uint32_t domid,
>> +                           libxl_device_vtpm *vtpm,
>> +                           libxl__ao_device *aodev)
>> +{
>> +    STATE_AO_GC(aodev->ao);
>> +    flexarray_t *front;
>> +    flexarray_t *back;
>> +    libxl__device *device;
>> +    char *dompath, **l;
>> +    unsigned int nb, rc;
>> +
>> +    rc =3D libxl__device_vtpm_setdefault(gc, vtpm);
>> +    if (rc) goto out;
>> +
>> +    front =3D flexarray_make(16, 1);
> Sorry but in the meantime the flexarray interface has changed, it now
> accepts a gc -- see commit 25991:5c6b72b62bd7.
Will fix
>
>
>> +    if (!front) {
>> +        rc =3D ERROR_NOMEM;
>> +        goto out;
>> +    }
>> +    back =3D flexarray_make(16, 1);
>> +    if (!back) {
>> +        rc =3D ERROR_NOMEM;
>> +        goto out;
>> +    }
>> +
>> +    if(vtpm->devid =3D=3D -1) {
>> +        if (!(dompath =3D libxl__xs_get_dompath(gc, domid))) {
>> +            rc =3D ERROR_FAIL;
>> +            goto out_free;
>> +        }
>> +        l =3D libxl__xs_directory(gc, XBT_NULL, libxl__sprintf(gc, "%=
s/device/vtpm", dompath), &nb);
> You have some very long lines in this patch. Can you try and keep it to=

> 75-80 characters please.
>
> There are various helper macros like GCSPRINTF which can help to reduce=

> the length of lines. Also you might find the LOG* macros useful instead=

> of the more verbose LIBXL__LOG*.
noted
>
> [...]
>
>> +    flexarray_append(back, "instance"); /* MAYBE CAN GET RID OF THIS =
*/
>> +    flexarray_append(back, "0");
>> +    flexarray_append(back, "pref_instance"); /* MAYBE CAN GET RID OF =
THIS */
>> +    flexarray_append(back, "0");
>> +    flexarray_append(back, "resume");
>> +    flexarray_append(back, "False");
>> +    flexarray_append(back, "ready"); /* MAYBE CAN GET RID OF THIS */
>> +    flexarray_append(back, "1");
> Can we decide now or is this a future work thing?
These will probably be removed from the driver now that the process
model is gone.
>
> Not a lot of existing code uses it but we have flexarray_append_pair
> which can clarify the pairing of keys and values if you would like to
> use it.
Probably makes code a little more readable, ill look into it.
>
>> +static void libxl__device_vtpm_from_xs_fe(libxl__gc *gc,
>> +                                          const char* fe_path,
>> +                                          libxl_device_vtpm *vtpm)
>>
> Other devices have from_xs_be not fe. This is because we "trust" the be=

> to be less malicious.
will rework
>
>> +{
>> [...]
>> +   tmp =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/uuid",=
 fe_path));
>> +   if(tmp) {
>> +      libxl_uuid_from_string(&(vtpm->uuid), tmp);
>> +   }
>> +}
>> [...]
>> +int libxl_device_vtpm_getinfo(libxl_ctx *ctx, uint32_t domid,
>> +                               libxl_device_vtpm *vtpm, libxl_vtpminf=
o *vtpminfo)
>> +{
>> [...]
>> +    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/uuid"=
, vtpminfo->backend));
>> +    if(val =3D=3D NULL) {
>> +       LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s/uuid does not exist!\n",=
 vtpminfo->backend);
>> +       goto err;
>> +    }
>> +    if(libxl_uuid_from_string(&(vtpminfo->uuid), val)) {
>> +       LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s/uuid is a malformed uuid=
?? (%s) Probably a bug!\n", vtpminfo->backend, val);
>> +       goto err;
> This is fatal here but not in from_xs_fe?
>
>> +static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multidev *=
multidev, int ret) {
> brace on next line please.
>
>> +   libxl__domain_create_state *dcs =3D CONTAINER_OF(multidev, *dcs, m=
ultidev);
>> +   STATE_AO_GC(dcs->ao);
>> +   int domid =3D dcs->guest_domid;
>> +
>> +   libxl_domain_config* const d_config =3D dcs->guest_config;
>> +
>> +   if(ret) {
>> +      LOG(ERROR, "unable to add nic devices");
>> +      goto error_out;
>> +   }
> Four space indents above please.
>
>> +    /* Plug vtpm devices */
>> +    if (d_config->num_vtpms > 0) {
>> +        /* Attach vtpms */
>> +        libxl__multidev_begin(ao, &dcs->multidev);
>> +        dcs->multidev.callback =3D domcreate_attach_pci;
>> +        libxl__add_vtpms(egc, ao, domid, d_config, &dcs->multidev);
>> +        libxl__multidev_prepared(egc, &dcs->multidev, 0);
>> +        return;
>> +    }
> This indent is ok.
>
>> +
>> +   domcreate_attach_pci(egc, multidev, 0);
>> +   return;
>> +
>> +error_out:
>> +   assert(ret);
>> +   domcreate_complete(egc, dcs, ret);
> But here we've gone back to 3 spaces again.
>
>> diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
>> index 55cd299..73a158a 100644
>> --- a/tools/libxl/libxl_utils.c
>> +++ b/tools/libxl/libxl_utils.c
>> @@ -463,6 +463,35 @@ int libxl_pipe(libxl_ctx *ctx, int pipes[2])
>>      return 0;
>>  }
>>
>> +int libxl_uuid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid,
>> +                            libxl_uuid* uuid, libxl_device_vtpm *vtpm=
)
>> +{
>> +    libxl_device_vtpm *vtpms;
>> +    int nb, i;
>> +    int rc;
>> +
>> +    vtpms =3D libxl_device_vtpm_list(ctx, domid, &nb);
>> +    if (!vtpms)
>> +        return ERROR_FAIL;
>> +
>> +    memset(vtpm, 0, sizeof (libxl_device_vtpm));
>> +    rc =3D 1;
>> +    for (i =3D 0; i < nb; ++i) {
>> +        if(!libxl_uuid_compare(uuid, &vtpms[i].uuid)) {
>> +            vtpm->backend_domid =3D vtpms[i].backend_domid;
>> +            vtpm->devid =3D vtpms[i].devid;
>> +            libxl_uuid_copy(&vtpm->uuid, &vtpms[i].uuid);
>> +            rc =3D 0;
>> +            break;
>> +        }
>> +    }
>> +
>> +    for (i=3D0; i> +        libxl_device_vtpm_dispose(&vtpms[i]);
>> +    free(vtpms);
> I think I saw this a few times (probably copied from elsewhere) but the=

> modern alternative is to define libxl_THING_list_free and use that to
> free the result of libxl_THING_list.
>
> We just didn't go back and change all the existing instances when we di=
d
> this.
>
>
>> diff --git a/tools/libxl/xl_cmdtable.c b/tools/libxl/xl_cmdtable.c
>> index 85ea768..7c018eb 100644
>> --- a/tools/libxl/xl_cmdtable.c
>> +++ b/tools/libxl/xl_cmdtable.c
>> @@ -338,6 +338,21 @@ struct cmd_spec cmd_table[] =3D {
>>        "Destroy a domain's virtual block device",
>>        " ",
>>      },
>> +    { "vtpm-attach",
>> +      &main_vtpmattach, 0, 1,
>> +      "Create a new virtual TPM device",
>> +      " [uuid=3D] [backend=3D]",
>> +    },
>> +    { "vtpm-list",
>> +      &main_vtpmlist, 0, 0,
> I think you want the first 0 to be 1 since you do support dry run in
> this command
agreed, must have been a typo
>
>> +      "List virtual TPM devices for a domain",
>> +      "",
>> +    },
>> +    { "vtpm-detach",
>> +      &main_vtpmdetach, 0, 1,
>> +      "Destroy a domain's virtual TPM device",
>> +      " ",
>> +    },
>>      { "uptime",
>>        &main_uptime, 0, 0,
>>        "Print uptime for all/some domains",
>> --
>> 1.7.4.4
>>
>



--------------ms080806030800010400010107
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMTAwOTEzMzYxMVowIwYJKoZIhvcNAQkEMRYEFCXQoBS5LZBmK9eg
PtEnGzrStFJBMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAnnBk4lXZOgBgkbnbRGb8wSPyDwLjWm/AR
V3lpPeEgplIZBAJcmstAbBdK/e60AagPMcuDJV6716kwzlYfuZRyPeGxxQSee3XUPOBar6/5
Svxemu3447pCYfE/DfqP/L+WlGcuNFH2utRmdIQpnc4RaH/6pj+gvp9Dvf4RA+im5wAAAAAA
AA==
--------------ms080806030800010400010107--


--===============5187726707256683994==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5187726707256683994==--


From xen-devel-bounces@lists.xen.org Tue Oct 09 13:43:07 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 13:43:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLa59-0005WL-Hz; Tue, 09 Oct 2012 13:42:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLa57-0005WD-Le
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 13:42:45 +0000
Received: from [85.158.139.83:10607] by server-15.bemta-5.messagelabs.com id
	3A/D6-06905-4D924705; Tue, 09 Oct 2012 13:42:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1349790160!26855694!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26701 invoked from network); 9 Oct 2012 13:42:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 13:42:40 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15038994"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 13:42:40 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	14:42:39 +0100
Message-ID: <1349790158.21847.183.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Matthew Fioravante 
Date: Tue, 9 Oct 2012 14:42:38 +0100
In-Reply-To: <5074284B.1050402@jhuapl.edu>
References: <1349460132-13853-1-git-send-email-matthew.fioravante@jhuapl.edu>
	<1349460132-13853-3-git-send-email-matthew.fioravante@jhuapl.edu>
	<1349778775.21847.132.camel@zakaz.uk.xensource.com>
	<5074284B.1050402@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH vtpm v2 11/12] add vtpm support to libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-09 at 14:36 +0100, Matthew Fioravante wrote:
> On 10/09/2012 06:32 AM, Ian Campbell wrote:
> > IIRC you are reworking the vtpm stuff to only support the stub domaun
> > model and not the process model -- does this mean this patch will change
> > or is this already only doing stub stuff?
> Since I'm not removing the process model, its possible that this. the
> tpm mini-os drivers, and the linux vtpm drivers might change slightly.
> Would you prefer I held off on these last 2 patches until the changes
> are finalized?

Might be easiest if you just resent the whole lot when you are ready?

I think I've applied everything which might be plausibly independent to
this -- if there's remaining stuff you think could go in now and not be
affected by this please point me at it.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 13:43:07 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 13:43:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLa59-0005WL-Hz; Tue, 09 Oct 2012 13:42:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLa57-0005WD-Le
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 13:42:45 +0000
Received: from [85.158.139.83:10607] by server-15.bemta-5.messagelabs.com id
	3A/D6-06905-4D924705; Tue, 09 Oct 2012 13:42:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1349790160!26855694!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26701 invoked from network); 9 Oct 2012 13:42:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 13:42:40 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15038994"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 13:42:40 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	14:42:39 +0100
Message-ID: <1349790158.21847.183.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Matthew Fioravante 
Date: Tue, 9 Oct 2012 14:42:38 +0100
In-Reply-To: <5074284B.1050402@jhuapl.edu>
References: <1349460132-13853-1-git-send-email-matthew.fioravante@jhuapl.edu>
	<1349460132-13853-3-git-send-email-matthew.fioravante@jhuapl.edu>
	<1349778775.21847.132.camel@zakaz.uk.xensource.com>
	<5074284B.1050402@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH vtpm v2 11/12] add vtpm support to libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-09 at 14:36 +0100, Matthew Fioravante wrote:
> On 10/09/2012 06:32 AM, Ian Campbell wrote:
> > IIRC you are reworking the vtpm stuff to only support the stub domaun
> > model and not the process model -- does this mean this patch will change
> > or is this already only doing stub stuff?
> Since I'm not removing the process model, its possible that this. the
> tpm mini-os drivers, and the linux vtpm drivers might change slightly.
> Would you prefer I held off on these last 2 patches until the changes
> are finalized?

Might be easiest if you just resent the whole lot when you are ready?

I think I've applied everything which might be plausibly independent to
this -- if there's remaining stuff you think could go in now and not be
affected by this please point me at it.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 13:44:22 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 13:44:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLa68-0005cH-0b; Tue, 09 Oct 2012 13:43:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLa66-0005c7-3z
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 13:43:46 +0000
Received: from [85.158.143.99:20674] by server-1.bemta-4.messagelabs.com id
	99/8F-05684-11A24705; Tue, 09 Oct 2012 13:43:45 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-14.tower-216.messagelabs.com!1349790223!23828685!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11672 invoked from network); 9 Oct 2012 13:43:44 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Oct 2012 13:43:44 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.154600497;
	Tue, 09 Oct 2012 09:43:38 -0400
Message-ID: <507429B6.6020008@jhuapl.edu>
Date: Tue, 09 Oct 2012 09:42:14 -0400
From: Matthew Fioravante 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell 
References: <1349460132-13853-1-git-send-email-matthew.fioravante@jhuapl.edu>
	<1349460132-13853-3-git-send-email-matthew.fioravante@jhuapl.edu>
	<1349778775.21847.132.camel@zakaz.uk.xensource.com>
	<5074284B.1050402@jhuapl.edu>
In-Reply-To: <5074284B.1050402@jhuapl.edu>
X-Enigmail-Version: 1.4.4
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH vtpm v2 11/12] add vtpm support to libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============8615713508135530041=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============8615713508135530041==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060507000301080509020503"

This is a cryptographically signed message in MIME format.

--------------ms060507000301080509020503
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 10/09/2012 09:36 AM, Matthew Fioravante wrote:
> On 10/09/2012 06:32 AM, Ian Campbell wrote:
>> IIRC you are reworking the vtpm stuff to only support the stub domaun
>> model and not the process model -- does this mean this patch will chan=
ge
>> or is this already only doing stub stuff?
> Since I'm not removing the process model, its possible that this. the
> tpm mini-os drivers, and the linux vtpm drivers might change slightly.
> Would you prefer I held off on these last 2 patches until the changes
> are finalized?
Sorry typo *since I am removing the process model*
>>> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
>>> index 1606eb1..17094ca 100644
>>> --- a/tools/libxl/libxl.c
>>> +++ b/tools/libxl/libxl.c
>>> @@ -1726,6 +1726,246 @@ out:
>>>  }
>>>
>>>  /*******************************************************************=
***********/
>>> +int libxl__device_vtpm_setdefault(libxl__gc *gc, libxl_device_vtpm *=
vtpm)
>>> +{
>>> +   if(libxl_uuid_is_nil(&vtpm->uuid)) {
>>> +      libxl_uuid_generate(&vtpm->uuid);
>>> +   }
>>> +   return 0;
>>> +}
>>> +
>>> +static int libxl__device_from_vtpm(libxl__gc *gc, uint32_t domid,
>>> +                                   libxl_device_vtpm *vtpm,
>>> +                                   libxl__device *device)
>>> +{
>>> +   device->backend_devid   =3D vtpm->devid;
>>> +   device->backend_domid   =3D vtpm->backend_domid;
>>> +   device->backend_kind    =3D LIBXL__DEVICE_KIND_VTPM;
>>> +   device->devid           =3D vtpm->devid;
>>> +   device->domid           =3D domid;
>>> +   device->kind            =3D LIBXL__DEVICE_KIND_VTPM;
>>> +
>>> +   return 0;
>>> +}
>>> +
>>> +void libxl__device_vtpm_add(libxl__egc *egc, uint32_t domid,
>>> +                           libxl_device_vtpm *vtpm,
>>> +                           libxl__ao_device *aodev)
>>> +{
>>> +    STATE_AO_GC(aodev->ao);
>>> +    flexarray_t *front;
>>> +    flexarray_t *back;
>>> +    libxl__device *device;
>>> +    char *dompath, **l;
>>> +    unsigned int nb, rc;
>>> +
>>> +    rc =3D libxl__device_vtpm_setdefault(gc, vtpm);
>>> +    if (rc) goto out;
>>> +
>>> +    front =3D flexarray_make(16, 1);
>> Sorry but in the meantime the flexarray interface has changed, it now
>> accepts a gc -- see commit 25991:5c6b72b62bd7.
> Will fix
>>
>>> +    if (!front) {
>>> +        rc =3D ERROR_NOMEM;
>>> +        goto out;
>>> +    }
>>> +    back =3D flexarray_make(16, 1);
>>> +    if (!back) {
>>> +        rc =3D ERROR_NOMEM;
>>> +        goto out;
>>> +    }
>>> +
>>> +    if(vtpm->devid =3D=3D -1) {
>>> +        if (!(dompath =3D libxl__xs_get_dompath(gc, domid))) {
>>> +            rc =3D ERROR_FAIL;
>>> +            goto out_free;
>>> +        }
>>> +        l =3D libxl__xs_directory(gc, XBT_NULL, libxl__sprintf(gc, "=
%s/device/vtpm", dompath), &nb);
>> You have some very long lines in this patch. Can you try and keep it t=
o
>> 75-80 characters please.
>>
>> There are various helper macros like GCSPRINTF which can help to reduc=
e
>> the length of lines. Also you might find the LOG* macros useful instea=
d
>> of the more verbose LIBXL__LOG*.
> noted
>> [...]
>>
>>> +    flexarray_append(back, "instance"); /* MAYBE CAN GET RID OF THIS=
 */
>>> +    flexarray_append(back, "0");
>>> +    flexarray_append(back, "pref_instance"); /* MAYBE CAN GET RID OF=
 THIS */
>>> +    flexarray_append(back, "0");
>>> +    flexarray_append(back, "resume");
>>> +    flexarray_append(back, "False");
>>> +    flexarray_append(back, "ready"); /* MAYBE CAN GET RID OF THIS */=

>>> +    flexarray_append(back, "1");
>> Can we decide now or is this a future work thing?
> These will probably be removed from the driver now that the process
> model is gone.
>> Not a lot of existing code uses it but we have flexarray_append_pair
>> which can clarify the pairing of keys and values if you would like to
>> use it.
> Probably makes code a little more readable, ill look into it.
>>> +static void libxl__device_vtpm_from_xs_fe(libxl__gc *gc,
>>> +                                          const char* fe_path,
>>> +                                          libxl_device_vtpm *vtpm)
>>>
>> Other devices have from_xs_be not fe. This is because we "trust" the b=
e
>> to be less malicious.
> will rework
>>> +{
>>> [...]
>>> +   tmp =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/uuid"=
, fe_path));
>>> +   if(tmp) {
>>> +      libxl_uuid_from_string(&(vtpm->uuid), tmp);
>>> +   }
>>> +}
>>> [...]
>>> +int libxl_device_vtpm_getinfo(libxl_ctx *ctx, uint32_t domid,
>>> +                               libxl_device_vtpm *vtpm, libxl_vtpmin=
fo *vtpminfo)
>>> +{
>>> [...]
>>> +    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/uuid=
", vtpminfo->backend));
>>> +    if(val =3D=3D NULL) {
>>> +       LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s/uuid does not exist!\n"=
, vtpminfo->backend);
>>> +       goto err;
>>> +    }
>>> +    if(libxl_uuid_from_string(&(vtpminfo->uuid), val)) {
>>> +       LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s/uuid is a malformed uui=
d?? (%s) Probably a bug!\n", vtpminfo->backend, val);
>>> +       goto err;
>> This is fatal here but not in from_xs_fe?
>>
>>> +static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multidev =
*multidev, int ret) {
>> brace on next line please.
>>
>>> +   libxl__domain_create_state *dcs =3D CONTAINER_OF(multidev, *dcs, =
multidev);
>>> +   STATE_AO_GC(dcs->ao);
>>> +   int domid =3D dcs->guest_domid;
>>> +
>>> +   libxl_domain_config* const d_config =3D dcs->guest_config;
>>> +
>>> +   if(ret) {
>>> +      LOG(ERROR, "unable to add nic devices");
>>> +      goto error_out;
>>> +   }
>> Four space indents above please.
>>
>>> +    /* Plug vtpm devices */
>>> +    if (d_config->num_vtpms > 0) {
>>> +        /* Attach vtpms */
>>> +        libxl__multidev_begin(ao, &dcs->multidev);
>>> +        dcs->multidev.callback =3D domcreate_attach_pci;
>>> +        libxl__add_vtpms(egc, ao, domid, d_config, &dcs->multidev);
>>> +        libxl__multidev_prepared(egc, &dcs->multidev, 0);
>>> +        return;
>>> +    }
>> This indent is ok.
>>
>>> +
>>> +   domcreate_attach_pci(egc, multidev, 0);
>>> +   return;
>>> +
>>> +error_out:
>>> +   assert(ret);
>>> +   domcreate_complete(egc, dcs, ret);
>> But here we've gone back to 3 spaces again.
>>
>>> diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
>>> index 55cd299..73a158a 100644
>>> --- a/tools/libxl/libxl_utils.c
>>> +++ b/tools/libxl/libxl_utils.c
>>> @@ -463,6 +463,35 @@ int libxl_pipe(libxl_ctx *ctx, int pipes[2])
>>>      return 0;
>>>  }
>>>
>>> +int libxl_uuid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid,
>>> +                            libxl_uuid* uuid, libxl_device_vtpm *vtp=
m)
>>> +{
>>> +    libxl_device_vtpm *vtpms;
>>> +    int nb, i;
>>> +    int rc;
>>> +
>>> +    vtpms =3D libxl_device_vtpm_list(ctx, domid, &nb);
>>> +    if (!vtpms)
>>> +        return ERROR_FAIL;
>>> +
>>> +    memset(vtpm, 0, sizeof (libxl_device_vtpm));
>>> +    rc =3D 1;
>>> +    for (i =3D 0; i < nb; ++i) {
>>> +        if(!libxl_uuid_compare(uuid, &vtpms[i].uuid)) {
>>> +            vtpm->backend_domid =3D vtpms[i].backend_domid;
>>> +            vtpm->devid =3D vtpms[i].devid;
>>> +            libxl_uuid_copy(&vtpm->uuid, &vtpms[i].uuid);
>>> +            rc =3D 0;
>>> +            break;
>>> +        }
>>> +    }
>>> +
>>> +    for (i=3D0; i>> +        libxl_device_vtpm_dispose(&vtpms[i]);
>>> +    free(vtpms);
>> I think I saw this a few times (probably copied from elsewhere) but th=
e
>> modern alternative is to define libxl_THING_list_free and use that to
>> free the result of libxl_THING_list.
>>
>> We just didn't go back and change all the existing instances when we d=
id
>> this.
>>
>>
>>> diff --git a/tools/libxl/xl_cmdtable.c b/tools/libxl/xl_cmdtable.c
>>> index 85ea768..7c018eb 100644
>>> --- a/tools/libxl/xl_cmdtable.c
>>> +++ b/tools/libxl/xl_cmdtable.c
>>> @@ -338,6 +338,21 @@ struct cmd_spec cmd_table[] =3D {
>>>        "Destroy a domain's virtual block device",
>>>        " ",
>>>      },
>>> +    { "vtpm-attach",
>>> +      &main_vtpmattach, 0, 1,
>>> +      "Create a new virtual TPM device",
>>> +      " [uuid=3D] [backend=3D]",
>>> +    },
>>> +    { "vtpm-list",
>>> +      &main_vtpmlist, 0, 0,
>> I think you want the first 0 to be 1 since you do support dry run in
>> this command
> agreed, must have been a typo
>>> +      "List virtual TPM devices for a domain",
>>> +      "",
>>> +    },
>>> +    { "vtpm-detach",
>>> +      &main_vtpmdetach, 0, 1,
>>> +      "Destroy a domain's virtual TPM device",
>>> +      " ",
>>> +    },
>>>      { "uptime",
>>>        &main_uptime, 0, 0,
>>>        "Print uptime for all/some domains",
>>> --
>>> 1.7.4.4
>>>
>



--------------ms060507000301080509020503
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMTAwOTEzNDIxNFowIwYJKoZIhvcNAQkEMRYEFBKaXg3PQfrqIR+W
Szl3ib8ZNhS5MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBL9w/kvh7VX3+1aSJKchPp2efYsruOc08S
EBrNXKT0sm90uMod7bOxLkDbBiOApZG9VBb5GkWAM4niqhEatDxn7wwU7LJ1+3v2fKdmh/qt
NHWzBNSaqDGwlWzjWsVeUPCBKuQ1ddBdfV3WZsgtZSDD1wahIZNb3WdSUOTQAake+wAAAAAA
AA==
--------------ms060507000301080509020503--


--===============8615713508135530041==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8615713508135530041==--


From xen-devel-bounces@lists.xen.org Tue Oct 09 13:44:22 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 13:44:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLa68-0005cH-0b; Tue, 09 Oct 2012 13:43:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLa66-0005c7-3z
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 13:43:46 +0000
Received: from [85.158.143.99:20674] by server-1.bemta-4.messagelabs.com id
	99/8F-05684-11A24705; Tue, 09 Oct 2012 13:43:45 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-14.tower-216.messagelabs.com!1349790223!23828685!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11672 invoked from network); 9 Oct 2012 13:43:44 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Oct 2012 13:43:44 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.154600497;
	Tue, 09 Oct 2012 09:43:38 -0400
Message-ID: <507429B6.6020008@jhuapl.edu>
Date: Tue, 09 Oct 2012 09:42:14 -0400
From: Matthew Fioravante 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell 
References: <1349460132-13853-1-git-send-email-matthew.fioravante@jhuapl.edu>
	<1349460132-13853-3-git-send-email-matthew.fioravante@jhuapl.edu>
	<1349778775.21847.132.camel@zakaz.uk.xensource.com>
	<5074284B.1050402@jhuapl.edu>
In-Reply-To: <5074284B.1050402@jhuapl.edu>
X-Enigmail-Version: 1.4.4
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH vtpm v2 11/12] add vtpm support to libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============8615713508135530041=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============8615713508135530041==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060507000301080509020503"

This is a cryptographically signed message in MIME format.

--------------ms060507000301080509020503
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 10/09/2012 09:36 AM, Matthew Fioravante wrote:
> On 10/09/2012 06:32 AM, Ian Campbell wrote:
>> IIRC you are reworking the vtpm stuff to only support the stub domaun
>> model and not the process model -- does this mean this patch will chan=
ge
>> or is this already only doing stub stuff?
> Since I'm not removing the process model, its possible that this. the
> tpm mini-os drivers, and the linux vtpm drivers might change slightly.
> Would you prefer I held off on these last 2 patches until the changes
> are finalized?
Sorry typo *since I am removing the process model*
>>> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
>>> index 1606eb1..17094ca 100644
>>> --- a/tools/libxl/libxl.c
>>> +++ b/tools/libxl/libxl.c
>>> @@ -1726,6 +1726,246 @@ out:
>>>  }
>>>
>>>  /*******************************************************************=
***********/
>>> +int libxl__device_vtpm_setdefault(libxl__gc *gc, libxl_device_vtpm *=
vtpm)
>>> +{
>>> +   if(libxl_uuid_is_nil(&vtpm->uuid)) {
>>> +      libxl_uuid_generate(&vtpm->uuid);
>>> +   }
>>> +   return 0;
>>> +}
>>> +
>>> +static int libxl__device_from_vtpm(libxl__gc *gc, uint32_t domid,
>>> +                                   libxl_device_vtpm *vtpm,
>>> +                                   libxl__device *device)
>>> +{
>>> +   device->backend_devid   =3D vtpm->devid;
>>> +   device->backend_domid   =3D vtpm->backend_domid;
>>> +   device->backend_kind    =3D LIBXL__DEVICE_KIND_VTPM;
>>> +   device->devid           =3D vtpm->devid;
>>> +   device->domid           =3D domid;
>>> +   device->kind            =3D LIBXL__DEVICE_KIND_VTPM;
>>> +
>>> +   return 0;
>>> +}
>>> +
>>> +void libxl__device_vtpm_add(libxl__egc *egc, uint32_t domid,
>>> +                           libxl_device_vtpm *vtpm,
>>> +                           libxl__ao_device *aodev)
>>> +{
>>> +    STATE_AO_GC(aodev->ao);
>>> +    flexarray_t *front;
>>> +    flexarray_t *back;
>>> +    libxl__device *device;
>>> +    char *dompath, **l;
>>> +    unsigned int nb, rc;
>>> +
>>> +    rc =3D libxl__device_vtpm_setdefault(gc, vtpm);
>>> +    if (rc) goto out;
>>> +
>>> +    front =3D flexarray_make(16, 1);
>> Sorry but in the meantime the flexarray interface has changed, it now
>> accepts a gc -- see commit 25991:5c6b72b62bd7.
> Will fix
>>
>>> +    if (!front) {
>>> +        rc =3D ERROR_NOMEM;
>>> +        goto out;
>>> +    }
>>> +    back =3D flexarray_make(16, 1);
>>> +    if (!back) {
>>> +        rc =3D ERROR_NOMEM;
>>> +        goto out;
>>> +    }
>>> +
>>> +    if(vtpm->devid =3D=3D -1) {
>>> +        if (!(dompath =3D libxl__xs_get_dompath(gc, domid))) {
>>> +            rc =3D ERROR_FAIL;
>>> +            goto out_free;
>>> +        }
>>> +        l =3D libxl__xs_directory(gc, XBT_NULL, libxl__sprintf(gc, "=
%s/device/vtpm", dompath), &nb);
>> You have some very long lines in this patch. Can you try and keep it t=
o
>> 75-80 characters please.
>>
>> There are various helper macros like GCSPRINTF which can help to reduc=
e
>> the length of lines. Also you might find the LOG* macros useful instea=
d
>> of the more verbose LIBXL__LOG*.
> noted
>> [...]
>>
>>> +    flexarray_append(back, "instance"); /* MAYBE CAN GET RID OF THIS=
 */
>>> +    flexarray_append(back, "0");
>>> +    flexarray_append(back, "pref_instance"); /* MAYBE CAN GET RID OF=
 THIS */
>>> +    flexarray_append(back, "0");
>>> +    flexarray_append(back, "resume");
>>> +    flexarray_append(back, "False");
>>> +    flexarray_append(back, "ready"); /* MAYBE CAN GET RID OF THIS */=

>>> +    flexarray_append(back, "1");
>> Can we decide now or is this a future work thing?
> These will probably be removed from the driver now that the process
> model is gone.
>> Not a lot of existing code uses it but we have flexarray_append_pair
>> which can clarify the pairing of keys and values if you would like to
>> use it.
> Probably makes code a little more readable, ill look into it.
>>> +static void libxl__device_vtpm_from_xs_fe(libxl__gc *gc,
>>> +                                          const char* fe_path,
>>> +                                          libxl_device_vtpm *vtpm)
>>>
>> Other devices have from_xs_be not fe. This is because we "trust" the b=
e
>> to be less malicious.
> will rework
>>> +{
>>> [...]
>>> +   tmp =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/uuid"=
, fe_path));
>>> +   if(tmp) {
>>> +      libxl_uuid_from_string(&(vtpm->uuid), tmp);
>>> +   }
>>> +}
>>> [...]
>>> +int libxl_device_vtpm_getinfo(libxl_ctx *ctx, uint32_t domid,
>>> +                               libxl_device_vtpm *vtpm, libxl_vtpmin=
fo *vtpminfo)
>>> +{
>>> [...]
>>> +    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/uuid=
", vtpminfo->backend));
>>> +    if(val =3D=3D NULL) {
>>> +       LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s/uuid does not exist!\n"=
, vtpminfo->backend);
>>> +       goto err;
>>> +    }
>>> +    if(libxl_uuid_from_string(&(vtpminfo->uuid), val)) {
>>> +       LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s/uuid is a malformed uui=
d?? (%s) Probably a bug!\n", vtpminfo->backend, val);
>>> +       goto err;
>> This is fatal here but not in from_xs_fe?
>>
>>> +static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multidev =
*multidev, int ret) {
>> brace on next line please.
>>
>>> +   libxl__domain_create_state *dcs =3D CONTAINER_OF(multidev, *dcs, =
multidev);
>>> +   STATE_AO_GC(dcs->ao);
>>> +   int domid =3D dcs->guest_domid;
>>> +
>>> +   libxl_domain_config* const d_config =3D dcs->guest_config;
>>> +
>>> +   if(ret) {
>>> +      LOG(ERROR, "unable to add nic devices");
>>> +      goto error_out;
>>> +   }
>> Four space indents above please.
>>
>>> +    /* Plug vtpm devices */
>>> +    if (d_config->num_vtpms > 0) {
>>> +        /* Attach vtpms */
>>> +        libxl__multidev_begin(ao, &dcs->multidev);
>>> +        dcs->multidev.callback =3D domcreate_attach_pci;
>>> +        libxl__add_vtpms(egc, ao, domid, d_config, &dcs->multidev);
>>> +        libxl__multidev_prepared(egc, &dcs->multidev, 0);
>>> +        return;
>>> +    }
>> This indent is ok.
>>
>>> +
>>> +   domcreate_attach_pci(egc, multidev, 0);
>>> +   return;
>>> +
>>> +error_out:
>>> +   assert(ret);
>>> +   domcreate_complete(egc, dcs, ret);
>> But here we've gone back to 3 spaces again.
>>
>>> diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
>>> index 55cd299..73a158a 100644
>>> --- a/tools/libxl/libxl_utils.c
>>> +++ b/tools/libxl/libxl_utils.c
>>> @@ -463,6 +463,35 @@ int libxl_pipe(libxl_ctx *ctx, int pipes[2])
>>>      return 0;
>>>  }
>>>
>>> +int libxl_uuid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid,
>>> +                            libxl_uuid* uuid, libxl_device_vtpm *vtp=
m)
>>> +{
>>> +    libxl_device_vtpm *vtpms;
>>> +    int nb, i;
>>> +    int rc;
>>> +
>>> +    vtpms =3D libxl_device_vtpm_list(ctx, domid, &nb);
>>> +    if (!vtpms)
>>> +        return ERROR_FAIL;
>>> +
>>> +    memset(vtpm, 0, sizeof (libxl_device_vtpm));
>>> +    rc =3D 1;
>>> +    for (i =3D 0; i < nb; ++i) {
>>> +        if(!libxl_uuid_compare(uuid, &vtpms[i].uuid)) {
>>> +            vtpm->backend_domid =3D vtpms[i].backend_domid;
>>> +            vtpm->devid =3D vtpms[i].devid;
>>> +            libxl_uuid_copy(&vtpm->uuid, &vtpms[i].uuid);
>>> +            rc =3D 0;
>>> +            break;
>>> +        }
>>> +    }
>>> +
>>> +    for (i=3D0; i>> +        libxl_device_vtpm_dispose(&vtpms[i]);
>>> +    free(vtpms);
>> I think I saw this a few times (probably copied from elsewhere) but th=
e
>> modern alternative is to define libxl_THING_list_free and use that to
>> free the result of libxl_THING_list.
>>
>> We just didn't go back and change all the existing instances when we d=
id
>> this.
>>
>>
>>> diff --git a/tools/libxl/xl_cmdtable.c b/tools/libxl/xl_cmdtable.c
>>> index 85ea768..7c018eb 100644
>>> --- a/tools/libxl/xl_cmdtable.c
>>> +++ b/tools/libxl/xl_cmdtable.c
>>> @@ -338,6 +338,21 @@ struct cmd_spec cmd_table[] =3D {
>>>        "Destroy a domain's virtual block device",
>>>        " ",
>>>      },
>>> +    { "vtpm-attach",
>>> +      &main_vtpmattach, 0, 1,
>>> +      "Create a new virtual TPM device",
>>> +      " [uuid=3D] [backend=3D]",
>>> +    },
>>> +    { "vtpm-list",
>>> +      &main_vtpmlist, 0, 0,
>> I think you want the first 0 to be 1 since you do support dry run in
>> this command
> agreed, must have been a typo
>>> +      "List virtual TPM devices for a domain",
>>> +      "",
>>> +    },
>>> +    { "vtpm-detach",
>>> +      &main_vtpmdetach, 0, 1,
>>> +      "Destroy a domain's virtual TPM device",
>>> +      " ",
>>> +    },
>>>      { "uptime",
>>>        &main_uptime, 0, 0,
>>>        "Print uptime for all/some domains",
>>> --
>>> 1.7.4.4
>>>
>



--------------ms060507000301080509020503
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMTAwOTEzNDIxNFowIwYJKoZIhvcNAQkEMRYEFBKaXg3PQfrqIR+W
Szl3ib8ZNhS5MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBL9w/kvh7VX3+1aSJKchPp2efYsruOc08S
EBrNXKT0sm90uMod7bOxLkDbBiOApZG9VBb5GkWAM4niqhEatDxn7wwU7LJ1+3v2fKdmh/qt
NHWzBNSaqDGwlWzjWsVeUPCBKuQ1ddBdfV3WZsgtZSDD1wahIZNb3WdSUOTQAake+wAAAAAA
AA==
--------------ms060507000301080509020503--


--===============8615713508135530041==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8615713508135530041==--


From xen-devel-bounces@lists.xen.org Tue Oct 09 13:47:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 13:47:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLa95-0005oX-Uu; Tue, 09 Oct 2012 13:46:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLa94-0005oM-L9
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 13:46:50 +0000
Received: from [85.158.139.83:43311] by server-15.bemta-5.messagelabs.com id
	12/E0-06905-9CA24705; Tue, 09 Oct 2012 13:46:49 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-12.tower-182.messagelabs.com!1349790409!33904729!1
X-Originating-IP: [192.134.164.105]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9454 invoked from network); 9 Oct 2012 13:46:49 -0000
Received: from mail4-relais-sop.national.inria.fr (HELO
	mail4-relais-sop.national.inria.fr) (192.134.164.105)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 13:46:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344204000"; d="scan'208";a="158423114"
Received: from unknown (HELO type.ipv6) ([193.50.110.124])
	by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA;
	09 Oct 2012 15:46:48 +0200
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from )
	id 1TLa92-0001mQ-J1; Tue, 09 Oct 2012 15:46:48 +0200
Date: Tue, 9 Oct 2012 15:46:48 +0200
From: Samuel Thibault 
To: Olaf Hering 
Message-ID: <20121009134648.GN6113@type.bordeaux.inria.fr>
Mail-Followup-To: Samuel Thibault ,
	Olaf Hering , xen-devel@lists.xen.org
References: <384714804b9b2a9742cc.1349787869@probook.site>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <384714804b9b2a9742cc.1349787869@probook.site>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] stubdom: fix error assignment in
 grub:load_module
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering, le Tue 09 Oct 2012 15:04:29 +0200, a =E9crit :
> # HG changeset patch
> # User Olaf Hering 
> # Date 1349787855 -7200
> # Node ID 384714804b9b2a9742cc45dffaa43b749b85513b
> # Parent  142e4577f5a9b95832b82f7b6d31fde1697cbe76
> stubdom: fix error assignment in grub:load_module
> =

> [ 1333s] mini-os.c: In function 'load_module':
> [ 1333s] mini-os.c:244: warning: statement with no effect
> =

> Signed-off-by: Olaf Hering 

Acked-by: Samuel Thibault 

> diff -r 142e4577f5a9 -r 384714804b9b stubdom/grub/mini-os.c
> --- a/stubdom/grub/mini-os.c
> +++ b/stubdom/grub/mini-os.c
> @@ -241,7 +241,7 @@ load_module (char *module, char *arg)
>  =

>      if ((void*) (multiboot_next_module_header+1) - module_image > PAGE_S=
IZE) {
>          /* Too many modules */
> -        ERR_WONT_FIT;
> +        errnum =3D ERR_WONT_FIT;
>          return 0;
>      }
>  =

> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> =


-- =

Samuel
/* Halley */

	(Halley's comment.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 13:47:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 13:47:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLa95-0005oX-Uu; Tue, 09 Oct 2012 13:46:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLa94-0005oM-L9
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 13:46:50 +0000
Received: from [85.158.139.83:43311] by server-15.bemta-5.messagelabs.com id
	12/E0-06905-9CA24705; Tue, 09 Oct 2012 13:46:49 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-12.tower-182.messagelabs.com!1349790409!33904729!1
X-Originating-IP: [192.134.164.105]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9454 invoked from network); 9 Oct 2012 13:46:49 -0000
Received: from mail4-relais-sop.national.inria.fr (HELO
	mail4-relais-sop.national.inria.fr) (192.134.164.105)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 13:46:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344204000"; d="scan'208";a="158423114"
Received: from unknown (HELO type.ipv6) ([193.50.110.124])
	by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA;
	09 Oct 2012 15:46:48 +0200
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from )
	id 1TLa92-0001mQ-J1; Tue, 09 Oct 2012 15:46:48 +0200
Date: Tue, 9 Oct 2012 15:46:48 +0200
From: Samuel Thibault 
To: Olaf Hering 
Message-ID: <20121009134648.GN6113@type.bordeaux.inria.fr>
Mail-Followup-To: Samuel Thibault ,
	Olaf Hering , xen-devel@lists.xen.org
References: <384714804b9b2a9742cc.1349787869@probook.site>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <384714804b9b2a9742cc.1349787869@probook.site>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] stubdom: fix error assignment in
 grub:load_module
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering, le Tue 09 Oct 2012 15:04:29 +0200, a =E9crit :
> # HG changeset patch
> # User Olaf Hering 
> # Date 1349787855 -7200
> # Node ID 384714804b9b2a9742cc45dffaa43b749b85513b
> # Parent  142e4577f5a9b95832b82f7b6d31fde1697cbe76
> stubdom: fix error assignment in grub:load_module
> =

> [ 1333s] mini-os.c: In function 'load_module':
> [ 1333s] mini-os.c:244: warning: statement with no effect
> =

> Signed-off-by: Olaf Hering 

Acked-by: Samuel Thibault 

> diff -r 142e4577f5a9 -r 384714804b9b stubdom/grub/mini-os.c
> --- a/stubdom/grub/mini-os.c
> +++ b/stubdom/grub/mini-os.c
> @@ -241,7 +241,7 @@ load_module (char *module, char *arg)
>  =

>      if ((void*) (multiboot_next_module_header+1) - module_image > PAGE_S=
IZE) {
>          /* Too many modules */
> -        ERR_WONT_FIT;
> +        errnum =3D ERR_WONT_FIT;
>          return 0;
>      }
>  =

> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> =


-- =

Samuel
/* Halley */

	(Halley's comment.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 13:48:23 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 13:48:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLaA4-0005u2-Cx; Tue, 09 Oct 2012 13:47:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLaA2-0005tp-Mw
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 13:47:50 +0000
Received: from [85.158.139.211:42941] by server-7.bemta-5.messagelabs.com id
	15/92-00431-50B24705; Tue, 09 Oct 2012 13:47:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1349790469!21673498!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31738 invoked from network); 9 Oct 2012 13:47:49 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 13:47:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15039125"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 13:47:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	14:47:48 +0100
Message-ID: <1349790467.21847.185.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Eric Dumazet 
Date: Tue, 9 Oct 2012 14:47:47 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: netdev@vger.kernel.org, Sander Eikelenboom , Konrad
	Rzeszutek Wilk , xen-devel 
Subject: [Xen-devel] compound skb frag pages appearing in start_xmit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Eric,

Sander has discovered an issue where xen-netback is given a compound
page as one of the skb frag pages to transmit. Currently netback can
only handle PAGE_SIZE'd frags and bugs out.

I suspect this is something to do with 69b08f62e174 "net: use bigger
pages in __netdev_alloc_frag", although perhaps not because it looks
like only tg3 uses it and Sander has an r8169. Also tg3 seems to only
call netdev_alloc_frag for sizes < PAGE_SIZE. I'm probably missing
something.

Are all net drivers expected to be able to handle compound pages in the
frags? Obviously it is to their benefit to do so, so it is something
I'll want to look into for netback.

I expect the main factor here is bridging/forwarding, since the
receiving NIC and its driver appear to support compound pages but the
outgoing NIC (netback in this case) does not.

I guess my question is should I be rushing to fix netback ASAP or should
I rather be looking for a bug somewhere which caused a frag of this type
to get as far as netback's start_xmit in the first place?

Or am I just barking up the wrong tree to start with?

Thanks,
Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 13:48:23 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 13:48:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLaA4-0005u2-Cx; Tue, 09 Oct 2012 13:47:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLaA2-0005tp-Mw
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 13:47:50 +0000
Received: from [85.158.139.211:42941] by server-7.bemta-5.messagelabs.com id
	15/92-00431-50B24705; Tue, 09 Oct 2012 13:47:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1349790469!21673498!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31738 invoked from network); 9 Oct 2012 13:47:49 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 13:47:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15039125"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 13:47:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	14:47:48 +0100
Message-ID: <1349790467.21847.185.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Eric Dumazet 
Date: Tue, 9 Oct 2012 14:47:47 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: netdev@vger.kernel.org, Sander Eikelenboom , Konrad
	Rzeszutek Wilk , xen-devel 
Subject: [Xen-devel] compound skb frag pages appearing in start_xmit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Eric,

Sander has discovered an issue where xen-netback is given a compound
page as one of the skb frag pages to transmit. Currently netback can
only handle PAGE_SIZE'd frags and bugs out.

I suspect this is something to do with 69b08f62e174 "net: use bigger
pages in __netdev_alloc_frag", although perhaps not because it looks
like only tg3 uses it and Sander has an r8169. Also tg3 seems to only
call netdev_alloc_frag for sizes < PAGE_SIZE. I'm probably missing
something.

Are all net drivers expected to be able to handle compound pages in the
frags? Obviously it is to their benefit to do so, so it is something
I'll want to look into for netback.

I expect the main factor here is bridging/forwarding, since the
receiving NIC and its driver appear to support compound pages but the
outgoing NIC (netback in this case) does not.

I guess my question is should I be rushing to fix netback ASAP or should
I rather be looking for a bug somewhere which caused a frag of this type
to get as far as netback's start_xmit in the first place?

Or am I just barking up the wrong tree to start with?

Thanks,
Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 13:49:38 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 13:49:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLaBF-00060M-Rq; Tue, 09 Oct 2012 13:49:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLaBE-00060A-O9
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 13:49:04 +0000
Received: from [85.158.138.51:11853] by server-12.bemta-3.messagelabs.com id
	CE/85-23730-05B24705; Tue, 09 Oct 2012 13:49:04 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-12.tower-174.messagelabs.com!1349790541!25762829!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9476 invoked from network); 9 Oct 2012 13:49:03 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Oct 2012 13:49:03 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.154600997;
	Tue, 09 Oct 2012 09:48:56 -0400
Message-ID: <50742AF4.1010500@jhuapl.edu>
Date: Tue, 09 Oct 2012 09:47:32 -0400
From: Matthew Fioravante 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell 
References: <1349460132-13853-1-git-send-email-matthew.fioravante@jhuapl.edu>
	<1349460132-13853-3-git-send-email-matthew.fioravante@jhuapl.edu>
	<1349778775.21847.132.camel@zakaz.uk.xensource.com>
	<5074284B.1050402@jhuapl.edu>
	<1349790158.21847.183.camel@zakaz.uk.xensource.com>
In-Reply-To: <1349790158.21847.183.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.4
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH vtpm v2 11/12] add vtpm support to libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============7093361185897078526=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============7093361185897078526==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070605000008080608000104"

This is a cryptographically signed message in MIME format.

--------------ms070605000008080608000104
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 10/09/2012 09:42 AM, Ian Campbell wrote:
> On Tue, 2012-10-09 at 14:36 +0100, Matthew Fioravante wrote:
>> On 10/09/2012 06:32 AM, Ian Campbell wrote:
>>> IIRC you are reworking the vtpm stuff to only support the stub domaun=

>>> model and not the process model -- does this mean this patch will cha=
nge
>>> or is this already only doing stub stuff?
>> Since I'm not removing the process model, its possible that this. the
>> tpm mini-os drivers, and the linux vtpm drivers might change slightly.=

>> Would you prefer I held off on these last 2 patches until the changes
>> are finalized?
> Might be easiest if you just resent the whole lot when you are ready?
>
> I think I've applied everything which might be plausibly independent to=

> this -- if there's remaining stuff you think could go in now and not be=

> affected by this please point me at it.
>
> Ian.
>
>
I think we can hold off on patches 8 (tpm drivers) and 11 (libxl vtpm)
for now. I'll resend them with the next batch. All of the independent
mini-so enhancements and the xl devid/iomem patches can be commited.
Those will not change and might be useful for someone doing something els=
e.

The next and final set of patches will include patches 8 and 11 from
here, removal of the vtpm process model, vtpm-stubdom, vtpmmgrdom, and a
few new libraries for stubdom that they require. I'll need a little time
to rework and test them, but they will be coming soon.


--------------ms070605000008080608000104
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMTAwOTEzNDczMlowIwYJKoZIhvcNAQkEMRYEFEG/RAOPubNfXlnV
XKhB9DuijXFlMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAxlx4Per7RtrYg8OXUQvxnTUiCI3kflU8H
O9bKc/y7ya2RpURagRsWxp3PMorWoDLYIbDWMrbQeCVvxAki/RM/wV+VTl1PvASXGVKDkCFi
k3yUHKAbElyi8Eil5O6XXlo8XbCRqXbP6LkcEez5rIaU1dysT29sznneheLzljumoQAAAAAA
AA==
--------------ms070605000008080608000104--


--===============7093361185897078526==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7093361185897078526==--


From xen-devel-bounces@lists.xen.org Tue Oct 09 13:49:38 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 13:49:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLaBF-00060M-Rq; Tue, 09 Oct 2012 13:49:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLaBE-00060A-O9
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 13:49:04 +0000
Received: from [85.158.138.51:11853] by server-12.bemta-3.messagelabs.com id
	CE/85-23730-05B24705; Tue, 09 Oct 2012 13:49:04 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-12.tower-174.messagelabs.com!1349790541!25762829!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9476 invoked from network); 9 Oct 2012 13:49:03 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Oct 2012 13:49:03 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.154600997;
	Tue, 09 Oct 2012 09:48:56 -0400
Message-ID: <50742AF4.1010500@jhuapl.edu>
Date: Tue, 09 Oct 2012 09:47:32 -0400
From: Matthew Fioravante 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell 
References: <1349460132-13853-1-git-send-email-matthew.fioravante@jhuapl.edu>
	<1349460132-13853-3-git-send-email-matthew.fioravante@jhuapl.edu>
	<1349778775.21847.132.camel@zakaz.uk.xensource.com>
	<5074284B.1050402@jhuapl.edu>
	<1349790158.21847.183.camel@zakaz.uk.xensource.com>
In-Reply-To: <1349790158.21847.183.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.4
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH vtpm v2 11/12] add vtpm support to libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============7093361185897078526=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============7093361185897078526==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070605000008080608000104"

This is a cryptographically signed message in MIME format.

--------------ms070605000008080608000104
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 10/09/2012 09:42 AM, Ian Campbell wrote:
> On Tue, 2012-10-09 at 14:36 +0100, Matthew Fioravante wrote:
>> On 10/09/2012 06:32 AM, Ian Campbell wrote:
>>> IIRC you are reworking the vtpm stuff to only support the stub domaun=

>>> model and not the process model -- does this mean this patch will cha=
nge
>>> or is this already only doing stub stuff?
>> Since I'm not removing the process model, its possible that this. the
>> tpm mini-os drivers, and the linux vtpm drivers might change slightly.=

>> Would you prefer I held off on these last 2 patches until the changes
>> are finalized?
> Might be easiest if you just resent the whole lot when you are ready?
>
> I think I've applied everything which might be plausibly independent to=

> this -- if there's remaining stuff you think could go in now and not be=

> affected by this please point me at it.
>
> Ian.
>
>
I think we can hold off on patches 8 (tpm drivers) and 11 (libxl vtpm)
for now. I'll resend them with the next batch. All of the independent
mini-so enhancements and the xl devid/iomem patches can be commited.
Those will not change and might be useful for someone doing something els=
e.

The next and final set of patches will include patches 8 and 11 from
here, removal of the vtpm process model, vtpm-stubdom, vtpmmgrdom, and a
few new libraries for stubdom that they require. I'll need a little time
to rework and test them, but they will be coming soon.


--------------ms070605000008080608000104
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMTAwOTEzNDczMlowIwYJKoZIhvcNAQkEMRYEFEG/RAOPubNfXlnV
XKhB9DuijXFlMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAxlx4Per7RtrYg8OXUQvxnTUiCI3kflU8H
O9bKc/y7ya2RpURagRsWxp3PMorWoDLYIbDWMrbQeCVvxAki/RM/wV+VTl1PvASXGVKDkCFi
k3yUHKAbElyi8Eil5O6XXlo8XbCRqXbP6LkcEez5rIaU1dysT29sznneheLzljumoQAAAAAA
AA==
--------------ms070605000008080608000104--


--===============7093361185897078526==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7093361185897078526==--


From xen-devel-bounces@lists.xen.org Tue Oct 09 13:51:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 13:51:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLaCf-00068k-Bl; Tue, 09 Oct 2012 13:50:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLaCe-00068a-3A
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 13:50:32 +0000
Received: from [85.158.138.51:2463] by server-5.bemta-3.messagelabs.com id
	32/F8-00589-7AB24705; Tue, 09 Oct 2012 13:50:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1349790629!27357403!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2458 invoked from network); 9 Oct 2012 13:50:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 13:50:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15039257"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 13:50:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	14:50:29 +0100
Message-ID: <1349790627.21847.186.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Matthew Fioravante 
Date: Tue, 9 Oct 2012 14:50:27 +0100
In-Reply-To: <50742AF4.1010500@jhuapl.edu>
References: <1349460132-13853-1-git-send-email-matthew.fioravante@jhuapl.edu>
	<1349460132-13853-3-git-send-email-matthew.fioravante@jhuapl.edu>
	<1349778775.21847.132.camel@zakaz.uk.xensource.com>
	<5074284B.1050402@jhuapl.edu>
	<1349790158.21847.183.camel@zakaz.uk.xensource.com>
	<50742AF4.1010500@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH vtpm v2 11/12] add vtpm support to libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-09 at 14:47 +0100, Matthew Fioravante wrote:
> On 10/09/2012 09:42 AM, Ian Campbell wrote:
> > On Tue, 2012-10-09 at 14:36 +0100, Matthew Fioravante wrote:
> >> On 10/09/2012 06:32 AM, Ian Campbell wrote:
> >>> IIRC you are reworking the vtpm stuff to only support the stub domaun
> >>> model and not the process model -- does this mean this patch will change
> >>> or is this already only doing stub stuff?
> >> Since I'm not removing the process model, its possible that this. the
> >> tpm mini-os drivers, and the linux vtpm drivers might change slightly.
> >> Would you prefer I held off on these last 2 patches until the changes
> >> are finalized?
> > Might be easiest if you just resent the whole lot when you are ready?
> >
> > I think I've applied everything which might be plausibly independent to
> > this -- if there's remaining stuff you think could go in now and not be
> > affected by this please point me at it.
> >
> > Ian.
> >
> >
> I think we can hold off on patches 8 (tpm drivers) and 11 (libxl vtpm)
> for now. I'll resend them with the next batch. All of the independent
> mini-so enhancements and the xl devid/iomem patches can be commited.
> Those will not change and might be useful for someone doing something else.

I think these are all in now, please let me know if I've missed one.

> The next and final set of patches will include patches 8 and 11 from
> here, removal of the vtpm process model, vtpm-stubdom, vtpmmgrdom, and a
> few new libraries for stubdom that they require. I'll need a little time
> to rework and test them, but they will be coming soon.

Great, thanks.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 13:51:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 13:51:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLaCf-00068k-Bl; Tue, 09 Oct 2012 13:50:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLaCe-00068a-3A
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 13:50:32 +0000
Received: from [85.158.138.51:2463] by server-5.bemta-3.messagelabs.com id
	32/F8-00589-7AB24705; Tue, 09 Oct 2012 13:50:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1349790629!27357403!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2458 invoked from network); 9 Oct 2012 13:50:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 13:50:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15039257"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 13:50:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	14:50:29 +0100
Message-ID: <1349790627.21847.186.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Matthew Fioravante 
Date: Tue, 9 Oct 2012 14:50:27 +0100
In-Reply-To: <50742AF4.1010500@jhuapl.edu>
References: <1349460132-13853-1-git-send-email-matthew.fioravante@jhuapl.edu>
	<1349460132-13853-3-git-send-email-matthew.fioravante@jhuapl.edu>
	<1349778775.21847.132.camel@zakaz.uk.xensource.com>
	<5074284B.1050402@jhuapl.edu>
	<1349790158.21847.183.camel@zakaz.uk.xensource.com>
	<50742AF4.1010500@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH vtpm v2 11/12] add vtpm support to libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-09 at 14:47 +0100, Matthew Fioravante wrote:
> On 10/09/2012 09:42 AM, Ian Campbell wrote:
> > On Tue, 2012-10-09 at 14:36 +0100, Matthew Fioravante wrote:
> >> On 10/09/2012 06:32 AM, Ian Campbell wrote:
> >>> IIRC you are reworking the vtpm stuff to only support the stub domaun
> >>> model and not the process model -- does this mean this patch will change
> >>> or is this already only doing stub stuff?
> >> Since I'm not removing the process model, its possible that this. the
> >> tpm mini-os drivers, and the linux vtpm drivers might change slightly.
> >> Would you prefer I held off on these last 2 patches until the changes
> >> are finalized?
> > Might be easiest if you just resent the whole lot when you are ready?
> >
> > I think I've applied everything which might be plausibly independent to
> > this -- if there's remaining stuff you think could go in now and not be
> > affected by this please point me at it.
> >
> > Ian.
> >
> >
> I think we can hold off on patches 8 (tpm drivers) and 11 (libxl vtpm)
> for now. I'll resend them with the next batch. All of the independent
> mini-so enhancements and the xl devid/iomem patches can be commited.
> Those will not change and might be useful for someone doing something else.

I think these are all in now, please let me know if I've missed one.

> The next and final set of patches will include patches 8 and 11 from
> here, removal of the vtpm process model, vtpm-stubdom, vtpmmgrdom, and a
> few new libraries for stubdom that they require. I'll need a little time
> to rework and test them, but they will be coming soon.

Great, thanks.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 13:55:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 13:55:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLaGU-0006Oo-14; Tue, 09 Oct 2012 13:54:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLaGS-0006Oe-Gq
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 13:54:28 +0000
Received: from [85.158.138.51:51900] by server-2.bemta-3.messagelabs.com id
	7F/DD-16514-39C24705; Tue, 09 Oct 2012 13:54:27 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1349790866!33183722!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22565 invoked from network); 9 Oct 2012 13:54:27 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 13:54:27 -0000
Received: by mail-bk0-f45.google.com with SMTP id jf3so2554907bkc.32
	for ; Tue, 09 Oct 2012 06:54:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:from:to:cc:in-reply-to:references:content-type:date
	:message-id:mime-version:x-mailer:content-transfer-encoding;
	bh=wtTdIDR3+aFpLqVRbUDMe6qDm44eY1D0hV3yCPbEcPc=;
	b=B3yUr3YDAkbm7BU9y/23BXG1guel45HLsz0N97TQ23gGUeZnp4/mlukXiYsPzwQUMl
	RePbTBMRGpL1tT/wMA8Kcs5GA78gRIlewWM5EnHb/o02WtIsckGMun5/P0j8XRgWYksu
	aTwySrALt3sj6DDIazjlZTXWkdYqfMUCrAxH5zlUcc/bRnStEXcBe802oMiIQMgvo1DF
	R+wndMBR+TbhO1z212aqdOnxnqMQTRZE1K9M5K8QpTaxKxwrStCmHePWf+ZQA5rlk5ui
	GJgPwPMUBhxXrGthor6rhw2xguz1tTGnyH57e1PDQaVk8PIf5vsT99PftrweufFIW04F
	0/2w==
Received: by 10.205.137.7 with SMTP id im7mr6469613bkc.25.1349790866687;
	Tue, 09 Oct 2012 06:54:26 -0700 (PDT)
Received: from [172.28.90.230] ([172.28.90.230])
	by mx.google.com with ESMTPS id j24sm14815014bkv.0.2012.10.09.06.54.24
	(version=SSLv3 cipher=OTHER); Tue, 09 Oct 2012 06:54:25 -0700 (PDT)
From: Eric Dumazet 
To: Ian Campbell 
In-Reply-To: <1349790467.21847.185.camel@zakaz.uk.xensource.com>
References: <1349790467.21847.185.camel@zakaz.uk.xensource.com>
Date: Tue, 09 Oct 2012 15:54:23 +0200
Message-ID: <1349790863.21172.4406.camel@edumazet-glaptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: netdev@vger.kernel.org, Eric Dumazet ,
	Sander Eikelenboom ,
	Konrad Rzeszutek Wilk ,
	xen-devel 
Subject: Re: [Xen-devel] compound skb frag pages appearing in start_xmit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-09 at 14:47 +0100, Ian Campbell wrote:
> Hi Eric,
> 

Hi Ian

> Sander has discovered an issue where xen-netback is given a compound
> page as one of the skb frag pages to transmit. Currently netback can
> only handle PAGE_SIZE'd frags and bugs out.
> 
> I suspect this is something to do with 69b08f62e174 "net: use bigger
> pages in __netdev_alloc_frag", although perhaps not because it looks
> like only tg3 uses it and Sander has an r8169. Also tg3 seems to only
> call netdev_alloc_frag for sizes < PAGE_SIZE. I'm probably missing
> something.


Its not the commit you want ;)

> 
> Are all net drivers expected to be able to handle compound pages in the
> frags? Obviously it is to their benefit to do so, so it is something
> I'll want to look into for netback.
> 

Not sure why a net driver would care of COMPOUND page at all ?

a Fragment has a struct page *, and a size.

a page can be order-0, order-1, order-2, order-3, ...

> I expect the main factor here is bridging/forwarding, since the
> receiving NIC and its driver appear to support compound pages but the
> outgoing NIC (netback in this case) does not.
> 
> I guess my question is should I be rushing to fix netback ASAP or should
> I rather be looking for a bug somewhere which caused a frag of this type
> to get as far as netback's start_xmit in the first place?
> 
> Or am I just barking up the wrong tree to start with?



The problem comes because of 

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=5640f7685831e088fe6c2e1f863a6805962f8e81

And yes, we must find a way to cope with this problem in your driver,
because you can also benefit from increase of performance once fixed ;)

And yes I can certainly help, as I am the author of this patch ;)

Thanks



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 13:55:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 13:55:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLaGU-0006Oo-14; Tue, 09 Oct 2012 13:54:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLaGS-0006Oe-Gq
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 13:54:28 +0000
Received: from [85.158.138.51:51900] by server-2.bemta-3.messagelabs.com id
	7F/DD-16514-39C24705; Tue, 09 Oct 2012 13:54:27 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1349790866!33183722!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22565 invoked from network); 9 Oct 2012 13:54:27 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 13:54:27 -0000
Received: by mail-bk0-f45.google.com with SMTP id jf3so2554907bkc.32
	for ; Tue, 09 Oct 2012 06:54:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:from:to:cc:in-reply-to:references:content-type:date
	:message-id:mime-version:x-mailer:content-transfer-encoding;
	bh=wtTdIDR3+aFpLqVRbUDMe6qDm44eY1D0hV3yCPbEcPc=;
	b=B3yUr3YDAkbm7BU9y/23BXG1guel45HLsz0N97TQ23gGUeZnp4/mlukXiYsPzwQUMl
	RePbTBMRGpL1tT/wMA8Kcs5GA78gRIlewWM5EnHb/o02WtIsckGMun5/P0j8XRgWYksu
	aTwySrALt3sj6DDIazjlZTXWkdYqfMUCrAxH5zlUcc/bRnStEXcBe802oMiIQMgvo1DF
	R+wndMBR+TbhO1z212aqdOnxnqMQTRZE1K9M5K8QpTaxKxwrStCmHePWf+ZQA5rlk5ui
	GJgPwPMUBhxXrGthor6rhw2xguz1tTGnyH57e1PDQaVk8PIf5vsT99PftrweufFIW04F
	0/2w==
Received: by 10.205.137.7 with SMTP id im7mr6469613bkc.25.1349790866687;
	Tue, 09 Oct 2012 06:54:26 -0700 (PDT)
Received: from [172.28.90.230] ([172.28.90.230])
	by mx.google.com with ESMTPS id j24sm14815014bkv.0.2012.10.09.06.54.24
	(version=SSLv3 cipher=OTHER); Tue, 09 Oct 2012 06:54:25 -0700 (PDT)
From: Eric Dumazet 
To: Ian Campbell 
In-Reply-To: <1349790467.21847.185.camel@zakaz.uk.xensource.com>
References: <1349790467.21847.185.camel@zakaz.uk.xensource.com>
Date: Tue, 09 Oct 2012 15:54:23 +0200
Message-ID: <1349790863.21172.4406.camel@edumazet-glaptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: netdev@vger.kernel.org, Eric Dumazet ,
	Sander Eikelenboom ,
	Konrad Rzeszutek Wilk ,
	xen-devel 
Subject: Re: [Xen-devel] compound skb frag pages appearing in start_xmit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-09 at 14:47 +0100, Ian Campbell wrote:
> Hi Eric,
> 

Hi Ian

> Sander has discovered an issue where xen-netback is given a compound
> page as one of the skb frag pages to transmit. Currently netback can
> only handle PAGE_SIZE'd frags and bugs out.
> 
> I suspect this is something to do with 69b08f62e174 "net: use bigger
> pages in __netdev_alloc_frag", although perhaps not because it looks
> like only tg3 uses it and Sander has an r8169. Also tg3 seems to only
> call netdev_alloc_frag for sizes < PAGE_SIZE. I'm probably missing
> something.


Its not the commit you want ;)

> 
> Are all net drivers expected to be able to handle compound pages in the
> frags? Obviously it is to their benefit to do so, so it is something
> I'll want to look into for netback.
> 

Not sure why a net driver would care of COMPOUND page at all ?

a Fragment has a struct page *, and a size.

a page can be order-0, order-1, order-2, order-3, ...

> I expect the main factor here is bridging/forwarding, since the
> receiving NIC and its driver appear to support compound pages but the
> outgoing NIC (netback in this case) does not.
> 
> I guess my question is should I be rushing to fix netback ASAP or should
> I rather be looking for a bug somewhere which caused a frag of this type
> to get as far as netback's start_xmit in the first place?
> 
> Or am I just barking up the wrong tree to start with?



The problem comes because of 

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=5640f7685831e088fe6c2e1f863a6805962f8e81

And yes, we must find a way to cope with this problem in your driver,
because you can also benefit from increase of performance once fixed ;)

And yes I can certainly help, as I am the author of this patch ;)

Thanks



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 14:03:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 14:03:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLaOd-0006dd-1W; Tue, 09 Oct 2012 14:02:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLaOb-0006dY-IR
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 14:02:53 +0000
Received: from [85.158.143.99:60682] by server-1.bemta-4.messagelabs.com id
	A2/1E-05684-C8E24705; Tue, 09 Oct 2012 14:02:52 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1349791371!25258424!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12420 invoked from network); 9 Oct 2012 14:02:52 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 14:02:52 -0000
Received: by mail-bk0-f45.google.com with SMTP id jf3so2560654bkc.32
	for ; Tue, 09 Oct 2012 07:02:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:from:to:cc:in-reply-to:references:content-type:date
	:message-id:mime-version:x-mailer:content-transfer-encoding;
	bh=/Wr8EXYGAImHWLj+1UqKSx4FviuJaPiz1ON8weqxqeg=;
	b=siO1vUwj0CtIBQWXtP59U9XE4sx9fgMdIhRD4pIeyweyyIqwGjsOWNXrbJtSHT2LvJ
	bHF6chGgwlh3OKrBl6tY1zObm+/Oflpqj/B4irARwCckKvvbe8GJnTFCm0WC8nC513Q3
	C6pG2MjV7R8KsAxKGE/GWH2et5Vz/XFKTQkgREPNi7zLNEDq8eaRMHQ00/qw9vREH2oI
	i9IvJ7b6EpgrElkHu2MNQwCvH2hv4bIu984X3HKb2JEGaJV5XCyJ78cHZhM9IH6h6Ax8
	vbjo1hY5NZIWLBrTmoXJcDT50OsIh9AcRDIYrd8aScULDq+b7PXJvtSJSOjt+vnMC2A6
	Qn5g==
Received: by 10.204.13.25 with SMTP id z25mr6731454bkz.119.1349791371674;
	Tue, 09 Oct 2012 07:02:51 -0700 (PDT)
Received: from [172.28.90.230] ([172.28.90.230])
	by mx.google.com with ESMTPS id e13sm14894944bkw.12.2012.10.09.07.01.46
	(version=SSLv3 cipher=OTHER); Tue, 09 Oct 2012 07:02:21 -0700 (PDT)
From: Eric Dumazet 
To: Ian Campbell 
In-Reply-To: <1349790863.21172.4406.camel@edumazet-glaptop>
References: <1349790467.21847.185.camel@zakaz.uk.xensource.com>
	<1349790863.21172.4406.camel@edumazet-glaptop>
Date: Tue, 09 Oct 2012 16:01:45 +0200
Message-ID: <1349791305.21172.4425.camel@edumazet-glaptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: netdev@vger.kernel.org, Eric Dumazet ,
	Sander Eikelenboom ,
	Konrad Rzeszutek Wilk ,
	xen-devel 
Subject: Re: [Xen-devel] compound skb frag pages appearing in start_xmit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-09 at 15:54 +0200, Eric Dumazet wrote:
> On Tue, 2012-10-09 at 14:47 +0100, Ian Campbell wrote:
> > Hi Eric,
> > 
> 
> Hi Ian
> 
> > Sander has discovered an issue where xen-netback is given a compound
> > page as one of the skb frag pages to transmit. Currently netback can
> > only handle PAGE_SIZE'd frags and bugs out.
> > 
> > I suspect this is something to do with 69b08f62e174 "net: use bigger
> > pages in __netdev_alloc_frag", although perhaps not because it looks
> > like only tg3 uses it and Sander has an r8169. Also tg3 seems to only
> > call netdev_alloc_frag for sizes < PAGE_SIZE. I'm probably missing
> > something.
> 
> 
> Its not the commit you want ;)

Hmm, I take it back. It also can give you the same problem :

We use this allocator for rx path of drivers : 

 __netdev_alloc_skb() 

So its now absolutely possible that one skb->head is backed by a order-3
page.

Is the problem coming from xen_netbk_count_skb_slots() ?

Give me more information if you want me to help.






_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 14:03:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 14:03:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLaOd-0006dd-1W; Tue, 09 Oct 2012 14:02:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLaOb-0006dY-IR
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 14:02:53 +0000
Received: from [85.158.143.99:60682] by server-1.bemta-4.messagelabs.com id
	A2/1E-05684-C8E24705; Tue, 09 Oct 2012 14:02:52 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1349791371!25258424!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12420 invoked from network); 9 Oct 2012 14:02:52 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 14:02:52 -0000
Received: by mail-bk0-f45.google.com with SMTP id jf3so2560654bkc.32
	for ; Tue, 09 Oct 2012 07:02:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:from:to:cc:in-reply-to:references:content-type:date
	:message-id:mime-version:x-mailer:content-transfer-encoding;
	bh=/Wr8EXYGAImHWLj+1UqKSx4FviuJaPiz1ON8weqxqeg=;
	b=siO1vUwj0CtIBQWXtP59U9XE4sx9fgMdIhRD4pIeyweyyIqwGjsOWNXrbJtSHT2LvJ
	bHF6chGgwlh3OKrBl6tY1zObm+/Oflpqj/B4irARwCckKvvbe8GJnTFCm0WC8nC513Q3
	C6pG2MjV7R8KsAxKGE/GWH2et5Vz/XFKTQkgREPNi7zLNEDq8eaRMHQ00/qw9vREH2oI
	i9IvJ7b6EpgrElkHu2MNQwCvH2hv4bIu984X3HKb2JEGaJV5XCyJ78cHZhM9IH6h6Ax8
	vbjo1hY5NZIWLBrTmoXJcDT50OsIh9AcRDIYrd8aScULDq+b7PXJvtSJSOjt+vnMC2A6
	Qn5g==
Received: by 10.204.13.25 with SMTP id z25mr6731454bkz.119.1349791371674;
	Tue, 09 Oct 2012 07:02:51 -0700 (PDT)
Received: from [172.28.90.230] ([172.28.90.230])
	by mx.google.com with ESMTPS id e13sm14894944bkw.12.2012.10.09.07.01.46
	(version=SSLv3 cipher=OTHER); Tue, 09 Oct 2012 07:02:21 -0700 (PDT)
From: Eric Dumazet 
To: Ian Campbell 
In-Reply-To: <1349790863.21172.4406.camel@edumazet-glaptop>
References: <1349790467.21847.185.camel@zakaz.uk.xensource.com>
	<1349790863.21172.4406.camel@edumazet-glaptop>
Date: Tue, 09 Oct 2012 16:01:45 +0200
Message-ID: <1349791305.21172.4425.camel@edumazet-glaptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: netdev@vger.kernel.org, Eric Dumazet ,
	Sander Eikelenboom ,
	Konrad Rzeszutek Wilk ,
	xen-devel 
Subject: Re: [Xen-devel] compound skb frag pages appearing in start_xmit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-09 at 15:54 +0200, Eric Dumazet wrote:
> On Tue, 2012-10-09 at 14:47 +0100, Ian Campbell wrote:
> > Hi Eric,
> > 
> 
> Hi Ian
> 
> > Sander has discovered an issue where xen-netback is given a compound
> > page as one of the skb frag pages to transmit. Currently netback can
> > only handle PAGE_SIZE'd frags and bugs out.
> > 
> > I suspect this is something to do with 69b08f62e174 "net: use bigger
> > pages in __netdev_alloc_frag", although perhaps not because it looks
> > like only tg3 uses it and Sander has an r8169. Also tg3 seems to only
> > call netdev_alloc_frag for sizes < PAGE_SIZE. I'm probably missing
> > something.
> 
> 
> Its not the commit you want ;)

Hmm, I take it back. It also can give you the same problem :

We use this allocator for rx path of drivers : 

 __netdev_alloc_skb() 

So its now absolutely possible that one skb->head is backed by a order-3
page.

Is the problem coming from xen_netbk_count_skb_slots() ?

Give me more information if you want me to help.






_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 14:03:38 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 14:03:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLaOp-0006f4-IJ; Tue, 09 Oct 2012 14:03:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLaOo-0006ei-PV
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 14:03:07 +0000
Received: from [85.158.139.211:43827] by server-9.bemta-5.messagelabs.com id
	6E/5C-14846-A9E24705; Tue, 09 Oct 2012 14:03:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1349791383!17671552!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6317 invoked from network); 9 Oct 2012 14:03:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 14:03:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15039838"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 14:02:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 9 Oct 2012 15:02:39 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TLaON-0002VL-Mi;
	Tue, 09 Oct 2012 14:02:39 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TLaON-0007kb-AL;
	Tue, 09 Oct 2012 15:02:39 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Tue, 9 Oct 2012 15:02:39 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13942: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13942 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13942/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 13932
 build-i386                    4 xen-build                 fail REGR. vs. 13932

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13932
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13932
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13932
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13932

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  d0b03667c922
baseline version:
 xen                  099589002239

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD 
  Ian Campbell 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Samuel Thibault 
  Samuel Thibault 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 370 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 14:03:38 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 14:03:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLaOp-0006f4-IJ; Tue, 09 Oct 2012 14:03:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLaOo-0006ei-PV
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 14:03:07 +0000
Received: from [85.158.139.211:43827] by server-9.bemta-5.messagelabs.com id
	6E/5C-14846-A9E24705; Tue, 09 Oct 2012 14:03:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1349791383!17671552!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6317 invoked from network); 9 Oct 2012 14:03:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 14:03:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15039838"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 14:02:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 9 Oct 2012 15:02:39 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TLaON-0002VL-Mi;
	Tue, 09 Oct 2012 14:02:39 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TLaON-0007kb-AL;
	Tue, 09 Oct 2012 15:02:39 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Tue, 9 Oct 2012 15:02:39 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13942: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13942 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13942/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 13932
 build-i386                    4 xen-build                 fail REGR. vs. 13932

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13932
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13932
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13932
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13932

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  d0b03667c922
baseline version:
 xen                  099589002239

------------------------------------------------------------
People who touched revisions under test:
  Anthony PERARD 
  Ian Campbell 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Samuel Thibault 
  Samuel Thibault 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 370 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 14:08:03 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 14:08:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLaT5-0006xA-E7; Tue, 09 Oct 2012 14:07:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLaT3-0006x0-Oo
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 14:07:29 +0000
Received: from [85.158.138.51:25097] by server-10.bemta-3.messagelabs.com id
	03/C7-02525-1AF24705; Tue, 09 Oct 2012 14:07:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1349791647!33606946!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21863 invoked from network); 9 Oct 2012 14:07:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 14:07:28 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15040006"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 14:06:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	15:06:53 +0100
Message-ID: <1349791612.21847.195.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: "Tim (Xen.org)" 
Date: Tue, 9 Oct 2012 15:06:52 +0100
In-Reply-To: <1349433418.20946.46.camel@zakaz.uk.xensource.com>
References: <1349433418.20946.46.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel , "Keir \(Xen.org\)" ,
	Jan Beulich ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 00/21] Sweep through arm-for-4.3 branch + a
 bit extra
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-05 at 11:36 +0100, Ian Campbell wrote:

[...]
> 02   B	libxc: add ARM support to xc_dom (PV domain building)
> 03  AB	arm: implement VGCF_online
> 04  AB	xen/arm: implement page reference and gnttab functions needed by grant_table.c
> 05  AB	xen/arm: implement get/put_page_type
> 06  AB	xen/arm: create_p2m_entries should not call free_domheap_page
[...]
> 08   B	arm: kill a guest which uses hvc with an immediate operand != XEN_HYPERCALL_TAG
> 09  AB	libxc/arm: allocate xenstore and console pages
> 10  AB	arm: disable distributor delivery on boot CPU only
> 11  AB	xen/arm: protect LR registers and lr_mask changes with spin_lock_irq
> 12  AB	xen/arm: introduce __lshrdi3 and __aeabi_llsr
> 13  AB	arm: don't bother setting up vtimer, vgic etc on idle CPUs
> 14  AB	arm/vtimer: convert result to ticks when reading CNTPCT register
> 15  AB	arm: Use per-CPU irq_desc for PPIs and SGIs

Stefano acked #2 so I've applied this subset of the series.

I skipped #1 (add_to_physmap_range) which is not yet acked and #7
because it depends on #1 and #16 onwards.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 14:08:03 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 14:08:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLaT5-0006xA-E7; Tue, 09 Oct 2012 14:07:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLaT3-0006x0-Oo
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 14:07:29 +0000
Received: from [85.158.138.51:25097] by server-10.bemta-3.messagelabs.com id
	03/C7-02525-1AF24705; Tue, 09 Oct 2012 14:07:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1349791647!33606946!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21863 invoked from network); 9 Oct 2012 14:07:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 14:07:28 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15040006"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 14:06:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	15:06:53 +0100
Message-ID: <1349791612.21847.195.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: "Tim (Xen.org)" 
Date: Tue, 9 Oct 2012 15:06:52 +0100
In-Reply-To: <1349433418.20946.46.camel@zakaz.uk.xensource.com>
References: <1349433418.20946.46.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel , "Keir \(Xen.org\)" ,
	Jan Beulich ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 00/21] Sweep through arm-for-4.3 branch + a
 bit extra
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-05 at 11:36 +0100, Ian Campbell wrote:

[...]
> 02   B	libxc: add ARM support to xc_dom (PV domain building)
> 03  AB	arm: implement VGCF_online
> 04  AB	xen/arm: implement page reference and gnttab functions needed by grant_table.c
> 05  AB	xen/arm: implement get/put_page_type
> 06  AB	xen/arm: create_p2m_entries should not call free_domheap_page
[...]
> 08   B	arm: kill a guest which uses hvc with an immediate operand != XEN_HYPERCALL_TAG
> 09  AB	libxc/arm: allocate xenstore and console pages
> 10  AB	arm: disable distributor delivery on boot CPU only
> 11  AB	xen/arm: protect LR registers and lr_mask changes with spin_lock_irq
> 12  AB	xen/arm: introduce __lshrdi3 and __aeabi_llsr
> 13  AB	arm: don't bother setting up vtimer, vgic etc on idle CPUs
> 14  AB	arm/vtimer: convert result to ticks when reading CNTPCT register
> 15  AB	arm: Use per-CPU irq_desc for PPIs and SGIs

Stefano acked #2 so I've applied this subset of the series.

I skipped #1 (add_to_physmap_range) which is not yet acked and #7
because it depends on #1 and #16 onwards.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 14:11:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 14:11:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLaWp-000798-LI; Tue, 09 Oct 2012 14:11:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLaWo-000771-9j
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 14:11:22 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1349791876!7927139!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28847 invoked from network); 9 Oct 2012 14:11:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 14:11:16 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15040117"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 14:11:16 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 9 Oct 2012 15:11:15 +0100
Date: Tue, 9 Oct 2012 15:10:10 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1349428386.20946.15.camel@zakaz.uk.xensource.com>
Message-ID: 
References: 
	<1345633688-31684-4-git-send-email-stefano.stabellini@eu.citrix.com>
	<1349428386.20946.15.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="1342847746-615481255-1349791585=:29539"
Content-ID: 
Cc: "xen-devel@lists.xensource.com" ,
	"Tim \(Xen.org\)" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH v4 4/6] xen: introduce XEN_GUEST_HANDLE_PARAM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--1342847746-615481255-1349791585=:29539
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
Content-ID: 

On Fri, 5 Oct 2012, Ian Campbell wrote:
> On Wed, 2012-08-22 at 12:08 +0100, Stefano Stabellini wrote:
> > diff --git a/xen/include/asm-arm/guest_access.h b/xen/include/asm-arm/guest_access.h
> > index 0fceae6..5686217 100644
> > --- a/xen/include/asm-arm/guest_access.h
> > +++ b/xen/include/asm-arm/guest_access.h
> > @@ -27,16 +27,40 @@ unsigned long raw_clear_guest(void *to, unsigned len);
> >  #define guest_handle_add_offset(hnd, nr) ((hnd).p += (nr))
> >  #define guest_handle_subtract_offset(hnd, nr) ((hnd).p -= (nr))
> >  
> > -/* Cast a guest handle to the specified type of handle. */
> > +/* Cast a guest handle (either XEN_GUEST_HANDLE or XEN_GUEST_HANDLE_PARAM)
> > + * to the specified type of XEN_GUEST_HANDLE_PARAM. */
> >  #define guest_handle_cast(hnd, type) ({         \
> >      type *_x = (hnd).p;                         \
> > -    (XEN_GUEST_HANDLE(type)) { _x };            \
> > +    (XEN_GUEST_HANDLE_PARAM(type)) { _x };            \
> [...]
> >  #define guest_handle_from_ptr(ptr, type)        \
> > -    ((XEN_GUEST_HANDLE(type)) { (type *)ptr })
> > +    ((XEN_GUEST_HANDLE_PARAM(type)) { (type *)ptr })
> >  #define const_guest_handle_from_ptr(ptr, type)  \
> > -    ((XEN_GUEST_HANDLE(const_##type)) { (const type *)ptr })
> > +    ((XEN_GUEST_HANDLE_PARAM(const_##type)) { (const type *)ptr })
> 
> These little bits cause build breakage if you only apply to this point
> in the series (i.e. breaks bisectability):
>         grant_table.c: In function ‘do_grant_table_op’:
>         grant_table.c:2449:13: error: invalid initializer
>         grant_table.c:2456:17: error: incompatible types when assigning to type ‘__guest_handle_64_void’ from type ‘__guest_handle_void’
>         [lots more of the same]
> 
> I think this is because you have changed guest_handle_cast but you
> haven't yet changed the type of the parameter.
> 
> I haven't tried x86 but I can't see why the same problem wouldn't exist
> there also.
> 
> The obvious answer is to move these hunks into the next patch, but I
> think because of the split into patches 5/6 and 6/6 this will still
> cause problems. I'll try it though but I suspect we might end up having
> to squash 5+6 together?

You are right, I realize now that the series is not bisectable :(
It makes sense to squash 4, 5 and 6 together, the only reason why I kept
them separate is for readability.
--1342847746-615481255-1349791585=:29539
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--1342847746-615481255-1349791585=:29539--


From xen-devel-bounces@lists.xen.org Tue Oct 09 14:11:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 14:11:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLaWp-000798-LI; Tue, 09 Oct 2012 14:11:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLaWo-000771-9j
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 14:11:22 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1349791876!7927139!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28847 invoked from network); 9 Oct 2012 14:11:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 14:11:16 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15040117"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 14:11:16 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 9 Oct 2012 15:11:15 +0100
Date: Tue, 9 Oct 2012 15:10:10 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1349428386.20946.15.camel@zakaz.uk.xensource.com>
Message-ID: 
References: 
	<1345633688-31684-4-git-send-email-stefano.stabellini@eu.citrix.com>
	<1349428386.20946.15.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="1342847746-615481255-1349791585=:29539"
Content-ID: 
Cc: "xen-devel@lists.xensource.com" ,
	"Tim \(Xen.org\)" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH v4 4/6] xen: introduce XEN_GUEST_HANDLE_PARAM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--1342847746-615481255-1349791585=:29539
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
Content-ID: 

On Fri, 5 Oct 2012, Ian Campbell wrote:
> On Wed, 2012-08-22 at 12:08 +0100, Stefano Stabellini wrote:
> > diff --git a/xen/include/asm-arm/guest_access.h b/xen/include/asm-arm/guest_access.h
> > index 0fceae6..5686217 100644
> > --- a/xen/include/asm-arm/guest_access.h
> > +++ b/xen/include/asm-arm/guest_access.h
> > @@ -27,16 +27,40 @@ unsigned long raw_clear_guest(void *to, unsigned len);
> >  #define guest_handle_add_offset(hnd, nr) ((hnd).p += (nr))
> >  #define guest_handle_subtract_offset(hnd, nr) ((hnd).p -= (nr))
> >  
> > -/* Cast a guest handle to the specified type of handle. */
> > +/* Cast a guest handle (either XEN_GUEST_HANDLE or XEN_GUEST_HANDLE_PARAM)
> > + * to the specified type of XEN_GUEST_HANDLE_PARAM. */
> >  #define guest_handle_cast(hnd, type) ({         \
> >      type *_x = (hnd).p;                         \
> > -    (XEN_GUEST_HANDLE(type)) { _x };            \
> > +    (XEN_GUEST_HANDLE_PARAM(type)) { _x };            \
> [...]
> >  #define guest_handle_from_ptr(ptr, type)        \
> > -    ((XEN_GUEST_HANDLE(type)) { (type *)ptr })
> > +    ((XEN_GUEST_HANDLE_PARAM(type)) { (type *)ptr })
> >  #define const_guest_handle_from_ptr(ptr, type)  \
> > -    ((XEN_GUEST_HANDLE(const_##type)) { (const type *)ptr })
> > +    ((XEN_GUEST_HANDLE_PARAM(const_##type)) { (const type *)ptr })
> 
> These little bits cause build breakage if you only apply to this point
> in the series (i.e. breaks bisectability):
>         grant_table.c: In function ‘do_grant_table_op’:
>         grant_table.c:2449:13: error: invalid initializer
>         grant_table.c:2456:17: error: incompatible types when assigning to type ‘__guest_handle_64_void’ from type ‘__guest_handle_void’
>         [lots more of the same]
> 
> I think this is because you have changed guest_handle_cast but you
> haven't yet changed the type of the parameter.
> 
> I haven't tried x86 but I can't see why the same problem wouldn't exist
> there also.
> 
> The obvious answer is to move these hunks into the next patch, but I
> think because of the split into patches 5/6 and 6/6 this will still
> cause problems. I'll try it though but I suspect we might end up having
> to squash 5+6 together?

You are right, I realize now that the series is not bisectable :(
It makes sense to squash 4, 5 and 6 together, the only reason why I kept
them separate is for readability.
--1342847746-615481255-1349791585=:29539
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--1342847746-615481255-1349791585=:29539--


From xen-devel-bounces@lists.xen.org Tue Oct 09 14:18:48 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 14:18:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLadS-0007Ot-MK; Tue, 09 Oct 2012 14:18:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLadR-0007Oo-Do
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 14:18:13 +0000
Received: from [85.158.139.83:65278] by server-12.bemta-5.messagelabs.com id
	23/4A-19095-42234705; Tue, 09 Oct 2012 14:18:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1349792292!29549811!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11235 invoked from network); 9 Oct 2012 14:18:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 14:18:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15040369"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 14:17:23 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	15:17:23 +0100
Message-ID: <1349792241.21847.199.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Eric Dumazet 
Date: Tue, 9 Oct 2012 15:17:21 +0100
In-Reply-To: <1349790863.21172.4406.camel@edumazet-glaptop>
References: <1349790467.21847.185.camel@zakaz.uk.xensource.com>
	<1349790863.21172.4406.camel@edumazet-glaptop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" ,
	Eric Dumazet ,
	Sander Eikelenboom ,
	Konrad Rzeszutek Wilk ,
	xen-devel 
Subject: Re: [Xen-devel] compound skb frag pages appearing in start_xmit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-09 at 14:54 +0100, Eric Dumazet wrote:
> On Tue, 2012-10-09 at 14:47 +0100, Ian Campbell wrote:
> > Hi Eric,
> > 
> 
> Hi Ian
> 
> > Sander has discovered an issue where xen-netback is given a compound
> > page as one of the skb frag pages to transmit. Currently netback can
> > only handle PAGE_SIZE'd frags and bugs out.
> > 
> > I suspect this is something to do with 69b08f62e174 "net: use bigger
> > pages in __netdev_alloc_frag", although perhaps not because it looks
> > like only tg3 uses it and Sander has an r8169. Also tg3 seems to only
> > call netdev_alloc_frag for sizes < PAGE_SIZE. I'm probably missing
> > something.
> 
> 
> Its not the commit you want ;)
> 
> > 
> > Are all net drivers expected to be able to handle compound pages in the
> > frags? Obviously it is to their benefit to do so, so it is something
> > I'll want to look into for netback.
> > 
> 
> Not sure why a net driver would care of COMPOUND page at all ?
> 
> a Fragment has a struct page *, and a size.
> 
> a page can be order-0, order-1, order-2, order-3, ...

I keep falling into this trap that a struct page * can be order > 0.

The Xen PV interfaces deal in order-0 pages only. Also things which are
contiguous in physical space may not be contiguous in DMA space (which
we call "machine memory" in Xen terminology).

The first is probably a specific quirk of Xen, but I thought there were
other architectures where physical and DMA space we not necessarily
contiguous and which would therefore need special handling (I guess
those platforms all have IOMMUs)

> > I expect the main factor here is bridging/forwarding, since the
> > receiving NIC and its driver appear to support compound pages but the
> > outgoing NIC (netback in this case) does not.
> > 
> > I guess my question is should I be rushing to fix netback ASAP or should
> > I rather be looking for a bug somewhere which caused a frag of this type
> > to get as far as netback's start_xmit in the first place?
> > 
> > Or am I just barking up the wrong tree to start with?
> 
> 
> 
> The problem comes because of 
> 
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=5640f7685831e088fe6c2e1f863a6805962f8e81
> 
> And yes, we must find a way to cope with this problem in your driver,
> because you can also benefit from increase of performance once fixed ;)
> 
> And yes I can certainly help, as I am the author of this patch ;)

I think I can mostly deal with this in the same way netback deals with
large skb heads i.e. by busting the multipage page into individual 4096
page chunks.

Does the higher order pages effectively reduce the number of frags which
are in use? e.g if MAX_SKB_FRAGS is 16, then for order-0 pages you could
have 64K worth of frag data.

If we switch to order-3 pages everywhere then can the skb contain 512K
of data, or does the effective maximum number of frags in an skb reduce
to 2?

If it's the latter then I think fixing netback is simple, if it's the
former then I might need to think a bit harder.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 14:18:48 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 14:18:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLadS-0007Ot-MK; Tue, 09 Oct 2012 14:18:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLadR-0007Oo-Do
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 14:18:13 +0000
Received: from [85.158.139.83:65278] by server-12.bemta-5.messagelabs.com id
	23/4A-19095-42234705; Tue, 09 Oct 2012 14:18:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1349792292!29549811!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11235 invoked from network); 9 Oct 2012 14:18:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 14:18:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15040369"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 14:17:23 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	15:17:23 +0100
Message-ID: <1349792241.21847.199.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Eric Dumazet 
Date: Tue, 9 Oct 2012 15:17:21 +0100
In-Reply-To: <1349790863.21172.4406.camel@edumazet-glaptop>
References: <1349790467.21847.185.camel@zakaz.uk.xensource.com>
	<1349790863.21172.4406.camel@edumazet-glaptop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" ,
	Eric Dumazet ,
	Sander Eikelenboom ,
	Konrad Rzeszutek Wilk ,
	xen-devel 
Subject: Re: [Xen-devel] compound skb frag pages appearing in start_xmit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-09 at 14:54 +0100, Eric Dumazet wrote:
> On Tue, 2012-10-09 at 14:47 +0100, Ian Campbell wrote:
> > Hi Eric,
> > 
> 
> Hi Ian
> 
> > Sander has discovered an issue where xen-netback is given a compound
> > page as one of the skb frag pages to transmit. Currently netback can
> > only handle PAGE_SIZE'd frags and bugs out.
> > 
> > I suspect this is something to do with 69b08f62e174 "net: use bigger
> > pages in __netdev_alloc_frag", although perhaps not because it looks
> > like only tg3 uses it and Sander has an r8169. Also tg3 seems to only
> > call netdev_alloc_frag for sizes < PAGE_SIZE. I'm probably missing
> > something.
> 
> 
> Its not the commit you want ;)
> 
> > 
> > Are all net drivers expected to be able to handle compound pages in the
> > frags? Obviously it is to their benefit to do so, so it is something
> > I'll want to look into for netback.
> > 
> 
> Not sure why a net driver would care of COMPOUND page at all ?
> 
> a Fragment has a struct page *, and a size.
> 
> a page can be order-0, order-1, order-2, order-3, ...

I keep falling into this trap that a struct page * can be order > 0.

The Xen PV interfaces deal in order-0 pages only. Also things which are
contiguous in physical space may not be contiguous in DMA space (which
we call "machine memory" in Xen terminology).

The first is probably a specific quirk of Xen, but I thought there were
other architectures where physical and DMA space we not necessarily
contiguous and which would therefore need special handling (I guess
those platforms all have IOMMUs)

> > I expect the main factor here is bridging/forwarding, since the
> > receiving NIC and its driver appear to support compound pages but the
> > outgoing NIC (netback in this case) does not.
> > 
> > I guess my question is should I be rushing to fix netback ASAP or should
> > I rather be looking for a bug somewhere which caused a frag of this type
> > to get as far as netback's start_xmit in the first place?
> > 
> > Or am I just barking up the wrong tree to start with?
> 
> 
> 
> The problem comes because of 
> 
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=5640f7685831e088fe6c2e1f863a6805962f8e81
> 
> And yes, we must find a way to cope with this problem in your driver,
> because you can also benefit from increase of performance once fixed ;)
> 
> And yes I can certainly help, as I am the author of this patch ;)

I think I can mostly deal with this in the same way netback deals with
large skb heads i.e. by busting the multipage page into individual 4096
page chunks.

Does the higher order pages effectively reduce the number of frags which
are in use? e.g if MAX_SKB_FRAGS is 16, then for order-0 pages you could
have 64K worth of frag data.

If we switch to order-3 pages everywhere then can the skb contain 512K
of data, or does the effective maximum number of frags in an skb reduce
to 2?

If it's the latter then I think fixing netback is simple, if it's the
former then I might need to think a bit harder.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 14:23:56 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 14:23:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLaik-0007XQ-ES; Tue, 09 Oct 2012 14:23:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLaii-0007XJ-LS
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 14:23:40 +0000
Received: from [85.158.139.83:48637] by server-14.bemta-5.messagelabs.com id
	5E/B1-31065-B6334705; Tue, 09 Oct 2012 14:23:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1349792618!33544863!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21986 invoked from network); 9 Oct 2012 14:23:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 14:23:39 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15040734"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 14:23:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	15:23:38 +0100
Message-ID: <1349792617.21847.205.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Eric Dumazet 
Date: Tue, 9 Oct 2012 15:23:37 +0100
In-Reply-To: <1349791305.21172.4425.camel@edumazet-glaptop>
References: <1349790467.21847.185.camel@zakaz.uk.xensource.com>
	<1349790863.21172.4406.camel@edumazet-glaptop>
	<1349791305.21172.4425.camel@edumazet-glaptop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" ,
	Eric Dumazet ,
	Sander Eikelenboom ,
	Konrad Rzeszutek Wilk ,
	xen-devel 
Subject: Re: [Xen-devel] compound skb frag pages appearing in start_xmit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-09 at 15:01 +0100, Eric Dumazet wrote:
> On Tue, 2012-10-09 at 15:54 +0200, Eric Dumazet wrote:
> > On Tue, 2012-10-09 at 14:47 +0100, Ian Campbell wrote:
> > > Hi Eric,
> > > 
> > 
> > Hi Ian
> > 
> > > Sander has discovered an issue where xen-netback is given a compound
> > > page as one of the skb frag pages to transmit. Currently netback can
> > > only handle PAGE_SIZE'd frags and bugs out.
> > > 
> > > I suspect this is something to do with 69b08f62e174 "net: use bigger
> > > pages in __netdev_alloc_frag", although perhaps not because it looks
> > > like only tg3 uses it and Sander has an r8169. Also tg3 seems to only
> > > call netdev_alloc_frag for sizes < PAGE_SIZE. I'm probably missing
> > > something.
> > 
> > 
> > Its not the commit you want ;)
> 
> Hmm, I take it back. It also can give you the same problem :
> 
> We use this allocator for rx path of drivers : 
> 
>  __netdev_alloc_skb() 
> 
> So its now absolutely possible that one skb->head is backed by a order-3
> page.
> 
> Is the problem coming from xen_netbk_count_skb_slots() ?
> 
> Give me more information if you want me to help.

The interesting code is in netbk_gop_skb(), specifically the two calls
to netbk_gop_frag_copy.

netbk_gop_frag_copy can only copy order-0 pages to the peer since they
go over a shared ring transport which can only deal in order-0 pages.

For the SKB head there is a loop which handles order>0 heads, I suspect
we just need something similar for the frag case.

Although see my question in the other response about the maximum number
of frags we can have when order is > 0 since if using larger pages
causes us to end up with a much larger number of order-0 pages once
we've broken them up then we have a problem and I need to put my
thinking cap on a bit (perhaps substantially) tighter.

Konrad, it looks like netfront has a similar issue in
xennet_make_frags() since it doesn't shatter large order mappings
either.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 14:23:56 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 14:23:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLaik-0007XQ-ES; Tue, 09 Oct 2012 14:23:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLaii-0007XJ-LS
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 14:23:40 +0000
Received: from [85.158.139.83:48637] by server-14.bemta-5.messagelabs.com id
	5E/B1-31065-B6334705; Tue, 09 Oct 2012 14:23:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1349792618!33544863!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21986 invoked from network); 9 Oct 2012 14:23:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 14:23:39 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15040734"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 14:23:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	15:23:38 +0100
Message-ID: <1349792617.21847.205.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Eric Dumazet 
Date: Tue, 9 Oct 2012 15:23:37 +0100
In-Reply-To: <1349791305.21172.4425.camel@edumazet-glaptop>
References: <1349790467.21847.185.camel@zakaz.uk.xensource.com>
	<1349790863.21172.4406.camel@edumazet-glaptop>
	<1349791305.21172.4425.camel@edumazet-glaptop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" ,
	Eric Dumazet ,
	Sander Eikelenboom ,
	Konrad Rzeszutek Wilk ,
	xen-devel 
Subject: Re: [Xen-devel] compound skb frag pages appearing in start_xmit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-09 at 15:01 +0100, Eric Dumazet wrote:
> On Tue, 2012-10-09 at 15:54 +0200, Eric Dumazet wrote:
> > On Tue, 2012-10-09 at 14:47 +0100, Ian Campbell wrote:
> > > Hi Eric,
> > > 
> > 
> > Hi Ian
> > 
> > > Sander has discovered an issue where xen-netback is given a compound
> > > page as one of the skb frag pages to transmit. Currently netback can
> > > only handle PAGE_SIZE'd frags and bugs out.
> > > 
> > > I suspect this is something to do with 69b08f62e174 "net: use bigger
> > > pages in __netdev_alloc_frag", although perhaps not because it looks
> > > like only tg3 uses it and Sander has an r8169. Also tg3 seems to only
> > > call netdev_alloc_frag for sizes < PAGE_SIZE. I'm probably missing
> > > something.
> > 
> > 
> > Its not the commit you want ;)
> 
> Hmm, I take it back. It also can give you the same problem :
> 
> We use this allocator for rx path of drivers : 
> 
>  __netdev_alloc_skb() 
> 
> So its now absolutely possible that one skb->head is backed by a order-3
> page.
> 
> Is the problem coming from xen_netbk_count_skb_slots() ?
> 
> Give me more information if you want me to help.

The interesting code is in netbk_gop_skb(), specifically the two calls
to netbk_gop_frag_copy.

netbk_gop_frag_copy can only copy order-0 pages to the peer since they
go over a shared ring transport which can only deal in order-0 pages.

For the SKB head there is a loop which handles order>0 heads, I suspect
we just need something similar for the frag case.

Although see my question in the other response about the maximum number
of frags we can have when order is > 0 since if using larger pages
causes us to end up with a much larger number of order-0 pages once
we've broken them up then we have a problem and I need to put my
thinking cap on a bit (perhaps substantially) tighter.

Konrad, it looks like netfront has a similar issue in
xennet_make_frags() since it doesn't shatter large order mappings
either.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 14:29:15 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 14:29:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLand-0007oj-3k; Tue, 09 Oct 2012 14:28:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLanb-0007oZ-Hc
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 14:28:43 +0000
Received: from [85.158.143.35:42378] by server-2.bemta-4.messagelabs.com id
	A6/11-06610-A9434705; Tue, 09 Oct 2012 14:28:42 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1349792857!5908110!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27199 invoked from network); 9 Oct 2012 14:27:42 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 14:27:42 -0000
Received: by mail-bk0-f45.google.com with SMTP id jf3so2578444bkc.32
	for ; Tue, 09 Oct 2012 07:27:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:from:to:cc:in-reply-to:references:content-type:date
	:message-id:mime-version:x-mailer:content-transfer-encoding;
	bh=xyX77H0i2tnsrSCs1N+j57Nlh9DhK4awCHS9TeR1mPg=;
	b=I+52NkYU0Bd7Z91kVMvsViWsqXSxDAMBwIxTPXMp6uqT3G9iwioMWcgb1tMTn5qSfT
	8hfnydY1uYmFzqoNfA3OnicorBW0uGGJry/+18ixQcYgRhX0E3l+K4KQExDhwRIqyjwv
	RsVyyXAXZcXbAL/3TKuknOkgG2s4kmtSYTSYSdxmeH6LHGQj13Un7mkTq75DzvDg6wjI
	bcvRSslYPmApxe8Nmjp58S6o3a2l6eGdzFd0HMttkyoc0b5ogqGTh9lTI2fJcwI0HHVe
	qhlDLtZyFmGbtgB40foSUgxaGFAXOCOkRXf1uxhx7PlKMbEwlIXY8qTsOpQh8rP6VgTw
	D95Q==
Received: by 10.204.5.204 with SMTP id 12mr6745910bkw.89.1349792851340;
	Tue, 09 Oct 2012 07:27:31 -0700 (PDT)
Received: from [172.28.90.230] ([172.28.90.230])
	by mx.google.com with ESMTPS id z22sm14935598bkw.2.2012.10.09.07.27.28
	(version=SSLv3 cipher=OTHER); Tue, 09 Oct 2012 07:27:30 -0700 (PDT)
From: Eric Dumazet 
To: Ian Campbell 
In-Reply-To: <1349792241.21847.199.camel@zakaz.uk.xensource.com>
References: <1349790467.21847.185.camel@zakaz.uk.xensource.com>
	<1349790863.21172.4406.camel@edumazet-glaptop>
	<1349792241.21847.199.camel@zakaz.uk.xensource.com>
Date: Tue, 09 Oct 2012 16:27:27 +0200
Message-ID: <1349792847.21172.4479.camel@edumazet-glaptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: "netdev@vger.kernel.org" ,
	Eric Dumazet ,
	Sander Eikelenboom ,
	Konrad Rzeszutek Wilk ,
	xen-devel 
Subject: Re: [Xen-devel] compound skb frag pages appearing in start_xmit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-09 at 15:17 +0100, Ian Campbell wrote:

> Does the higher order pages effectively reduce the number of frags which
> are in use? e.g if MAX_SKB_FRAGS is 16, then for order-0 pages you could
> have 64K worth of frag data.
> 
> If we switch to order-3 pages everywhere then can the skb contain 512K
> of data, or does the effective maximum number of frags in an skb reduce
> to 2?

effective number of frags reduce to 2 or 3

(We still limit GSO packets to ~63536 bytes)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 14:29:15 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 14:29:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLand-0007oj-3k; Tue, 09 Oct 2012 14:28:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLanb-0007oZ-Hc
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 14:28:43 +0000
Received: from [85.158.143.35:42378] by server-2.bemta-4.messagelabs.com id
	A6/11-06610-A9434705; Tue, 09 Oct 2012 14:28:42 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1349792857!5908110!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27199 invoked from network); 9 Oct 2012 14:27:42 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 14:27:42 -0000
Received: by mail-bk0-f45.google.com with SMTP id jf3so2578444bkc.32
	for ; Tue, 09 Oct 2012 07:27:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:from:to:cc:in-reply-to:references:content-type:date
	:message-id:mime-version:x-mailer:content-transfer-encoding;
	bh=xyX77H0i2tnsrSCs1N+j57Nlh9DhK4awCHS9TeR1mPg=;
	b=I+52NkYU0Bd7Z91kVMvsViWsqXSxDAMBwIxTPXMp6uqT3G9iwioMWcgb1tMTn5qSfT
	8hfnydY1uYmFzqoNfA3OnicorBW0uGGJry/+18ixQcYgRhX0E3l+K4KQExDhwRIqyjwv
	RsVyyXAXZcXbAL/3TKuknOkgG2s4kmtSYTSYSdxmeH6LHGQj13Un7mkTq75DzvDg6wjI
	bcvRSslYPmApxe8Nmjp58S6o3a2l6eGdzFd0HMttkyoc0b5ogqGTh9lTI2fJcwI0HHVe
	qhlDLtZyFmGbtgB40foSUgxaGFAXOCOkRXf1uxhx7PlKMbEwlIXY8qTsOpQh8rP6VgTw
	D95Q==
Received: by 10.204.5.204 with SMTP id 12mr6745910bkw.89.1349792851340;
	Tue, 09 Oct 2012 07:27:31 -0700 (PDT)
Received: from [172.28.90.230] ([172.28.90.230])
	by mx.google.com with ESMTPS id z22sm14935598bkw.2.2012.10.09.07.27.28
	(version=SSLv3 cipher=OTHER); Tue, 09 Oct 2012 07:27:30 -0700 (PDT)
From: Eric Dumazet 
To: Ian Campbell 
In-Reply-To: <1349792241.21847.199.camel@zakaz.uk.xensource.com>
References: <1349790467.21847.185.camel@zakaz.uk.xensource.com>
	<1349790863.21172.4406.camel@edumazet-glaptop>
	<1349792241.21847.199.camel@zakaz.uk.xensource.com>
Date: Tue, 09 Oct 2012 16:27:27 +0200
Message-ID: <1349792847.21172.4479.camel@edumazet-glaptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: "netdev@vger.kernel.org" ,
	Eric Dumazet ,
	Sander Eikelenboom ,
	Konrad Rzeszutek Wilk ,
	xen-devel 
Subject: Re: [Xen-devel] compound skb frag pages appearing in start_xmit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-09 at 15:17 +0100, Ian Campbell wrote:

> Does the higher order pages effectively reduce the number of frags which
> are in use? e.g if MAX_SKB_FRAGS is 16, then for order-0 pages you could
> have 64K worth of frag data.
> 
> If we switch to order-3 pages everywhere then can the skb contain 512K
> of data, or does the effective maximum number of frags in an skb reduce
> to 2?

effective number of frags reduce to 2 or 3

(We still limit GSO packets to ~63536 bytes)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 14:34:23 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 14:34:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLasW-00080d-RL; Tue, 09 Oct 2012 14:33:48 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLasV-0007zp-KA
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 14:33:47 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1349793221!2030789!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10648 invoked from network); 9 Oct 2012 14:33:41 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 14:33:41 -0000
Received: by mail-bk0-f45.google.com with SMTP id jf3so2582926bkc.32
	for ; Tue, 09 Oct 2012 07:33:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:from:to:cc:in-reply-to:references:content-type:date
	:message-id:mime-version:x-mailer:content-transfer-encoding;
	bh=Z1P8ZMDA+BQrso9pHww1MKWHwehFg1/3JSqQmYTNKw4=;
	b=D2hwHJVhVINrS6CtqizqgxYFdawvgGpBOeDT6tsjz72GmqIZCsCgAopC+Du5wQuCcY
	KAm4PyF6GpP4mfVDoh/CH/R+YCkSwpNd1bcEnLGtRre3zT5ao4QrCE6tFmi1OM2IzApM
	dQZxH1tIfEIwQsM+XAQ+bA9PZywwVo/902e2oRJmuppTyZ/kKRP/7ZlRPFSh2ONlhGxm
	0ZkVd9dpj0gbCLZXSM3SlRID0ukOiwDxErl4/m3ItIKKDwlzT1g+ymlQ+K78NlT6Es4p
	GiExOcufpn4lXNSbbhTlD0ft/1tffIZkWkiuuAwQ6vqZW/t6AOyluPjtJE5D85+LTWqg
	nrZQ==
Received: by 10.205.122.137 with SMTP id gg9mr6741029bkc.34.1349793221039;
	Tue, 09 Oct 2012 07:33:41 -0700 (PDT)
Received: from [172.28.90.230] ([172.28.90.230])
	by mx.google.com with ESMTPS id 1sm12258448bks.3.2012.10.09.07.33.38
	(version=SSLv3 cipher=OTHER); Tue, 09 Oct 2012 07:33:39 -0700 (PDT)
From: Eric Dumazet 
To: Ian Campbell 
In-Reply-To: <1349792617.21847.205.camel@zakaz.uk.xensource.com>
References: <1349790467.21847.185.camel@zakaz.uk.xensource.com>
	<1349790863.21172.4406.camel@edumazet-glaptop>
	<1349791305.21172.4425.camel@edumazet-glaptop>
	<1349792617.21847.205.camel@zakaz.uk.xensource.com>
Date: Tue, 09 Oct 2012 16:33:37 +0200
Message-ID: <1349793217.21172.4497.camel@edumazet-glaptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: "netdev@vger.kernel.org" ,
	Eric Dumazet ,
	Sander Eikelenboom ,
	Konrad Rzeszutek Wilk ,
	xen-devel 
Subject: Re: [Xen-devel] compound skb frag pages appearing in start_xmit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-09 at 15:23 +0100, Ian Campbell wrote:
> On Tue, 2012-10-09 at 15:01 +0100, Eric Dumazet wrote:
> > On Tue, 2012-10-09 at 15:54 +0200, Eric Dumazet wrote:
> > > On Tue, 2012-10-09 at 14:47 +0100, Ian Campbell wrote:
> > > > Hi Eric,
> > > > 
> > > 
> > > Hi Ian
> > > 
> > > > Sander has discovered an issue where xen-netback is given a compound
> > > > page as one of the skb frag pages to transmit. Currently netback can
> > > > only handle PAGE_SIZE'd frags and bugs out.
> > > > 
> > > > I suspect this is something to do with 69b08f62e174 "net: use bigger
> > > > pages in __netdev_alloc_frag", although perhaps not because it looks
> > > > like only tg3 uses it and Sander has an r8169. Also tg3 seems to only
> > > > call netdev_alloc_frag for sizes < PAGE_SIZE. I'm probably missing
> > > > something.
> > > 
> > > 
> > > Its not the commit you want ;)
> > 
> > Hmm, I take it back. It also can give you the same problem :
> > 
> > We use this allocator for rx path of drivers : 
> > 
> >  __netdev_alloc_skb() 
> > 
> > So its now absolutely possible that one skb->head is backed by a order-3
> > page.
> > 
> > Is the problem coming from xen_netbk_count_skb_slots() ?
> > 
> > Give me more information if you want me to help.
> 
> The interesting code is in netbk_gop_skb(), specifically the two calls
> to netbk_gop_frag_copy.
> 
> netbk_gop_frag_copy can only copy order-0 pages to the peer since they
> go over a shared ring transport which can only deal in order-0 pages.
> 
> For the SKB head there is a loop which handles order>0 heads, I suspect
> we just need something similar for the frag case.
> 
> Although see my question in the other response about the maximum number
> of frags we can have when order is > 0 since if using larger pages
> causes us to end up with a much larger number of order-0 pages once
> we've broken them up then we have a problem and I need to put my
> thinking cap on a bit (perhaps substantially) tighter.
> 
> Konrad, it looks like netfront has a similar issue in
> xennet_make_frags() since it doesn't shatter large order mappings
> either.

Hmm...

In theory, if a skb has 16+1 frags backed by compound pages, you could
need ~48 order-0 frags.

(4098 bytes could need 1-4096-1 (3 frags))

In practice, it should be around ~17 order-0 frags as before.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 14:34:23 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 14:34:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLasW-00080d-RL; Tue, 09 Oct 2012 14:33:48 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLasV-0007zp-KA
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 14:33:47 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1349793221!2030789!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10648 invoked from network); 9 Oct 2012 14:33:41 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 14:33:41 -0000
Received: by mail-bk0-f45.google.com with SMTP id jf3so2582926bkc.32
	for ; Tue, 09 Oct 2012 07:33:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:from:to:cc:in-reply-to:references:content-type:date
	:message-id:mime-version:x-mailer:content-transfer-encoding;
	bh=Z1P8ZMDA+BQrso9pHww1MKWHwehFg1/3JSqQmYTNKw4=;
	b=D2hwHJVhVINrS6CtqizqgxYFdawvgGpBOeDT6tsjz72GmqIZCsCgAopC+Du5wQuCcY
	KAm4PyF6GpP4mfVDoh/CH/R+YCkSwpNd1bcEnLGtRre3zT5ao4QrCE6tFmi1OM2IzApM
	dQZxH1tIfEIwQsM+XAQ+bA9PZywwVo/902e2oRJmuppTyZ/kKRP/7ZlRPFSh2ONlhGxm
	0ZkVd9dpj0gbCLZXSM3SlRID0ukOiwDxErl4/m3ItIKKDwlzT1g+ymlQ+K78NlT6Es4p
	GiExOcufpn4lXNSbbhTlD0ft/1tffIZkWkiuuAwQ6vqZW/t6AOyluPjtJE5D85+LTWqg
	nrZQ==
Received: by 10.205.122.137 with SMTP id gg9mr6741029bkc.34.1349793221039;
	Tue, 09 Oct 2012 07:33:41 -0700 (PDT)
Received: from [172.28.90.230] ([172.28.90.230])
	by mx.google.com with ESMTPS id 1sm12258448bks.3.2012.10.09.07.33.38
	(version=SSLv3 cipher=OTHER); Tue, 09 Oct 2012 07:33:39 -0700 (PDT)
From: Eric Dumazet 
To: Ian Campbell 
In-Reply-To: <1349792617.21847.205.camel@zakaz.uk.xensource.com>
References: <1349790467.21847.185.camel@zakaz.uk.xensource.com>
	<1349790863.21172.4406.camel@edumazet-glaptop>
	<1349791305.21172.4425.camel@edumazet-glaptop>
	<1349792617.21847.205.camel@zakaz.uk.xensource.com>
Date: Tue, 09 Oct 2012 16:33:37 +0200
Message-ID: <1349793217.21172.4497.camel@edumazet-glaptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: "netdev@vger.kernel.org" ,
	Eric Dumazet ,
	Sander Eikelenboom ,
	Konrad Rzeszutek Wilk ,
	xen-devel 
Subject: Re: [Xen-devel] compound skb frag pages appearing in start_xmit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-09 at 15:23 +0100, Ian Campbell wrote:
> On Tue, 2012-10-09 at 15:01 +0100, Eric Dumazet wrote:
> > On Tue, 2012-10-09 at 15:54 +0200, Eric Dumazet wrote:
> > > On Tue, 2012-10-09 at 14:47 +0100, Ian Campbell wrote:
> > > > Hi Eric,
> > > > 
> > > 
> > > Hi Ian
> > > 
> > > > Sander has discovered an issue where xen-netback is given a compound
> > > > page as one of the skb frag pages to transmit. Currently netback can
> > > > only handle PAGE_SIZE'd frags and bugs out.
> > > > 
> > > > I suspect this is something to do with 69b08f62e174 "net: use bigger
> > > > pages in __netdev_alloc_frag", although perhaps not because it looks
> > > > like only tg3 uses it and Sander has an r8169. Also tg3 seems to only
> > > > call netdev_alloc_frag for sizes < PAGE_SIZE. I'm probably missing
> > > > something.
> > > 
> > > 
> > > Its not the commit you want ;)
> > 
> > Hmm, I take it back. It also can give you the same problem :
> > 
> > We use this allocator for rx path of drivers : 
> > 
> >  __netdev_alloc_skb() 
> > 
> > So its now absolutely possible that one skb->head is backed by a order-3
> > page.
> > 
> > Is the problem coming from xen_netbk_count_skb_slots() ?
> > 
> > Give me more information if you want me to help.
> 
> The interesting code is in netbk_gop_skb(), specifically the two calls
> to netbk_gop_frag_copy.
> 
> netbk_gop_frag_copy can only copy order-0 pages to the peer since they
> go over a shared ring transport which can only deal in order-0 pages.
> 
> For the SKB head there is a loop which handles order>0 heads, I suspect
> we just need something similar for the frag case.
> 
> Although see my question in the other response about the maximum number
> of frags we can have when order is > 0 since if using larger pages
> causes us to end up with a much larger number of order-0 pages once
> we've broken them up then we have a problem and I need to put my
> thinking cap on a bit (perhaps substantially) tighter.
> 
> Konrad, it looks like netfront has a similar issue in
> xennet_make_frags() since it doesn't shatter large order mappings
> either.

Hmm...

In theory, if a skb has 16+1 frags backed by compound pages, you could
need ~48 order-0 frags.

(4098 bytes could need 1-4096-1 (3 frags))

In practice, it should be around ~17 order-0 frags as before.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 14:39:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 14:39:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLaxX-0008EW-6k; Tue, 09 Oct 2012 14:38:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLaxV-0008EF-J8
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 14:38:57 +0000
Received: from [85.158.139.83:54962] by server-16.bemta-5.messagelabs.com id
	88/B5-21637-00734705; Tue, 09 Oct 2012 14:38:56 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1349793534!20007941!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzUyMTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27680 invoked from network); 9 Oct 2012 14:38:56 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 14:38:56 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="40600456"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 14:38:54 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 9 Oct 2012 10:38:54 -0400
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TLaxR-0001BU-Mb;
	Tue, 09 Oct 2012 15:38:53 +0100
Message-ID: <507436FD.5000700@citrix.com>
Date: Tue, 9 Oct 2012 15:38:53 +0100
From: Andrew Cooper 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: Keir Fraser 
References: 
In-Reply-To: 
X-Enigmail-Version: 1.4.4
Cc: Stefano Stabellini ,
	Ian Campbell , Jan Beulich ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] irq: Remove irqaction.free_on_release
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/10/12 12:44, Keir Fraser wrote:
> But reasoning behind c/s 20153, which introduced it, still applies? Callers
> using setup_irq() don't want their passed-in irqaction to be xfree()ed?
>
>  -- Keir

Yikes - yes it does.  My original reading of the code was that it was
being set, hence the patch, but upon closer reading I am wrong.

As for grep'ing, it is only ever implicitly set to 0 by compound struct
initialisation with { 0 }

Furthermore, there is now a case where an ns16550 uart->irq can be set
higher than nr_irqs_gsi, although it is unclear whether this will
actually cause a problem and hit the unconditional xfree(action) in
dynamic_irq_cleanip(), which is only protected by BUG()'ing if the irq
index is within the gsi range.

~Andrew

>
> On 08/10/2012 14:09, "Andrew Cooper"  wrote:
>
>> It is always set to 1, and only checked on some of the codepaths which free an
>> irqaction.
>>
>> Signed-off-by: Andrew Cooper 
>>
>> --
>> This patch does touch common code as well as x86 and arm architectures,
>> so probably needs quite a few acks.
>>
>> diff -r 5fbdbf585f5f -r 37f1afbec80b xen/arch/arm/gic.c
>> --- a/xen/arch/arm/gic.c
>> +++ b/xen/arch/arm/gic.c
>> @@ -373,7 +373,7 @@ void __init release_irq(unsigned int irq
>>      /* Wait to make sure it's not being used on another CPU */
>>      do { smp_mb(); } while ( desc->status & IRQ_INPROGRESS );
>>  
>> -    if (action && action->free_on_release)
>> +    if ( action )
>>          xfree(action);
>>  }
>>  
>> diff -r 5fbdbf585f5f -r 37f1afbec80b xen/arch/arm/irq.c
>> --- a/xen/arch/arm/irq.c
>> +++ b/xen/arch/arm/irq.c
>> @@ -97,7 +97,6 @@ int __init request_irq(unsigned int irq,
>>      action->handler = handler;
>>      action->name = devname;
>>      action->dev_id = dev_id;
>> -    action->free_on_release = 1;
>>  
>>      retval = setup_irq(irq, action);
>>      if (retval)
>> diff -r 5fbdbf585f5f -r 37f1afbec80b xen/arch/x86/irq.c
>> --- a/xen/arch/x86/irq.c
>> +++ b/xen/arch/x86/irq.c
>> @@ -952,7 +952,6 @@ int __init request_irq(unsigned int irq,
>>      action->handler = handler;
>>      action->name = devname;
>>      action->dev_id = dev_id;
>> -    action->free_on_release = 1;
>>  
>>      retval = setup_irq(irq, action);
>>      if (retval)
>> @@ -979,7 +978,7 @@ void __init release_irq(unsigned int irq
>>      /* Wait to make sure it's not being used on another CPU */
>>      do { smp_mb(); } while ( desc->status & IRQ_INPROGRESS );
>>  
>> -    if (action && action->free_on_release)
>> +    if ( action )
>>          xfree(action);
>>  }
>>  
>> diff -r 5fbdbf585f5f -r 37f1afbec80b xen/include/xen/irq.h
>> --- a/xen/include/xen/irq.h
>> +++ b/xen/include/xen/irq.h
>> @@ -13,7 +13,6 @@ struct irqaction {
>>      void (*handler)(int, void *, struct cpu_user_regs *);
>>      const char *name;
>>      void *dev_id;
>> -    bool_t free_on_release;
>>  };
>>  
>>  /*
>

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 14:39:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 14:39:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLaxX-0008EW-6k; Tue, 09 Oct 2012 14:38:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLaxV-0008EF-J8
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 14:38:57 +0000
Received: from [85.158.139.83:54962] by server-16.bemta-5.messagelabs.com id
	88/B5-21637-00734705; Tue, 09 Oct 2012 14:38:56 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1349793534!20007941!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzUyMTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27680 invoked from network); 9 Oct 2012 14:38:56 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 14:38:56 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="40600456"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 14:38:54 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 9 Oct 2012 10:38:54 -0400
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TLaxR-0001BU-Mb;
	Tue, 09 Oct 2012 15:38:53 +0100
Message-ID: <507436FD.5000700@citrix.com>
Date: Tue, 9 Oct 2012 15:38:53 +0100
From: Andrew Cooper 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: Keir Fraser 
References: 
In-Reply-To: 
X-Enigmail-Version: 1.4.4
Cc: Stefano Stabellini ,
	Ian Campbell , Jan Beulich ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] irq: Remove irqaction.free_on_release
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/10/12 12:44, Keir Fraser wrote:
> But reasoning behind c/s 20153, which introduced it, still applies? Callers
> using setup_irq() don't want their passed-in irqaction to be xfree()ed?
>
>  -- Keir

Yikes - yes it does.  My original reading of the code was that it was
being set, hence the patch, but upon closer reading I am wrong.

As for grep'ing, it is only ever implicitly set to 0 by compound struct
initialisation with { 0 }

Furthermore, there is now a case where an ns16550 uart->irq can be set
higher than nr_irqs_gsi, although it is unclear whether this will
actually cause a problem and hit the unconditional xfree(action) in
dynamic_irq_cleanip(), which is only protected by BUG()'ing if the irq
index is within the gsi range.

~Andrew

>
> On 08/10/2012 14:09, "Andrew Cooper"  wrote:
>
>> It is always set to 1, and only checked on some of the codepaths which free an
>> irqaction.
>>
>> Signed-off-by: Andrew Cooper 
>>
>> --
>> This patch does touch common code as well as x86 and arm architectures,
>> so probably needs quite a few acks.
>>
>> diff -r 5fbdbf585f5f -r 37f1afbec80b xen/arch/arm/gic.c
>> --- a/xen/arch/arm/gic.c
>> +++ b/xen/arch/arm/gic.c
>> @@ -373,7 +373,7 @@ void __init release_irq(unsigned int irq
>>      /* Wait to make sure it's not being used on another CPU */
>>      do { smp_mb(); } while ( desc->status & IRQ_INPROGRESS );
>>  
>> -    if (action && action->free_on_release)
>> +    if ( action )
>>          xfree(action);
>>  }
>>  
>> diff -r 5fbdbf585f5f -r 37f1afbec80b xen/arch/arm/irq.c
>> --- a/xen/arch/arm/irq.c
>> +++ b/xen/arch/arm/irq.c
>> @@ -97,7 +97,6 @@ int __init request_irq(unsigned int irq,
>>      action->handler = handler;
>>      action->name = devname;
>>      action->dev_id = dev_id;
>> -    action->free_on_release = 1;
>>  
>>      retval = setup_irq(irq, action);
>>      if (retval)
>> diff -r 5fbdbf585f5f -r 37f1afbec80b xen/arch/x86/irq.c
>> --- a/xen/arch/x86/irq.c
>> +++ b/xen/arch/x86/irq.c
>> @@ -952,7 +952,6 @@ int __init request_irq(unsigned int irq,
>>      action->handler = handler;
>>      action->name = devname;
>>      action->dev_id = dev_id;
>> -    action->free_on_release = 1;
>>  
>>      retval = setup_irq(irq, action);
>>      if (retval)
>> @@ -979,7 +978,7 @@ void __init release_irq(unsigned int irq
>>      /* Wait to make sure it's not being used on another CPU */
>>      do { smp_mb(); } while ( desc->status & IRQ_INPROGRESS );
>>  
>> -    if (action && action->free_on_release)
>> +    if ( action )
>>          xfree(action);
>>  }
>>  
>> diff -r 5fbdbf585f5f -r 37f1afbec80b xen/include/xen/irq.h
>> --- a/xen/include/xen/irq.h
>> +++ b/xen/include/xen/irq.h
>> @@ -13,7 +13,6 @@ struct irqaction {
>>      void (*handler)(int, void *, struct cpu_user_regs *);
>>      const char *name;
>>      void *dev_id;
>> -    bool_t free_on_release;
>>  };
>>  
>>  /*
>

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 14:40:50 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 14:40:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLaz6-0008Qu-0w; Tue, 09 Oct 2012 14:40:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLaz5-0008Qi-4J
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 14:40:35 +0000
Received: from [85.158.137.99:55462] by server-9.bemta-3.messagelabs.com id
	35/17-20338-26734705; Tue, 09 Oct 2012 14:40:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1349793632!16095117!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32366 invoked from network); 9 Oct 2012 14:40:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 14:40:33 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15041392"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 14:40:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	15:40:32 +0100
Message-ID: <1349793630.21847.208.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Eric Dumazet 
Date: Tue, 9 Oct 2012 15:40:30 +0100
In-Reply-To: <1349792847.21172.4479.camel@edumazet-glaptop>
References: <1349790467.21847.185.camel@zakaz.uk.xensource.com>
	<1349790863.21172.4406.camel@edumazet-glaptop>
	<1349792241.21847.199.camel@zakaz.uk.xensource.com>
	<1349792847.21172.4479.camel@edumazet-glaptop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" ,
	Eric Dumazet ,
	Sander Eikelenboom ,
	Konrad Rzeszutek Wilk ,
	xen-devel 
Subject: Re: [Xen-devel] compound skb frag pages appearing in start_xmit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-09 at 15:27 +0100, Eric Dumazet wrote:
> On Tue, 2012-10-09 at 15:17 +0100, Ian Campbell wrote:
> 
> > Does the higher order pages effectively reduce the number of frags which
> > are in use? e.g if MAX_SKB_FRAGS is 16, then for order-0 pages you could
> > have 64K worth of frag data.
> > 
> > If we switch to order-3 pages everywhere then can the skb contain 512K
> > of data, or does the effective maximum number of frags in an skb reduce
> > to 2?
> 
> effective number of frags reduce to 2 or 3
> 
> (We still limit GSO packets to ~63536 bytes)

Great! Then I think the fix is more/less trivial...

As an aside, when the skb head is < 4096 bytes is that necessarily a
compound page or might it just be a large kmalloc area?

Only really relevant since it impacts the possibility for code sharing
between the head and the frags sending.

Ian



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 14:40:50 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 14:40:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLaz6-0008Qu-0w; Tue, 09 Oct 2012 14:40:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLaz5-0008Qi-4J
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 14:40:35 +0000
Received: from [85.158.137.99:55462] by server-9.bemta-3.messagelabs.com id
	35/17-20338-26734705; Tue, 09 Oct 2012 14:40:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1349793632!16095117!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32366 invoked from network); 9 Oct 2012 14:40:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 14:40:33 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15041392"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 14:40:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	15:40:32 +0100
Message-ID: <1349793630.21847.208.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Eric Dumazet 
Date: Tue, 9 Oct 2012 15:40:30 +0100
In-Reply-To: <1349792847.21172.4479.camel@edumazet-glaptop>
References: <1349790467.21847.185.camel@zakaz.uk.xensource.com>
	<1349790863.21172.4406.camel@edumazet-glaptop>
	<1349792241.21847.199.camel@zakaz.uk.xensource.com>
	<1349792847.21172.4479.camel@edumazet-glaptop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" ,
	Eric Dumazet ,
	Sander Eikelenboom ,
	Konrad Rzeszutek Wilk ,
	xen-devel 
Subject: Re: [Xen-devel] compound skb frag pages appearing in start_xmit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-09 at 15:27 +0100, Eric Dumazet wrote:
> On Tue, 2012-10-09 at 15:17 +0100, Ian Campbell wrote:
> 
> > Does the higher order pages effectively reduce the number of frags which
> > are in use? e.g if MAX_SKB_FRAGS is 16, then for order-0 pages you could
> > have 64K worth of frag data.
> > 
> > If we switch to order-3 pages everywhere then can the skb contain 512K
> > of data, or does the effective maximum number of frags in an skb reduce
> > to 2?
> 
> effective number of frags reduce to 2 or 3
> 
> (We still limit GSO packets to ~63536 bytes)

Great! Then I think the fix is more/less trivial...

As an aside, when the skb head is < 4096 bytes is that necessarily a
compound page or might it just be a large kmalloc area?

Only really relevant since it impacts the possibility for code sharing
between the head and the frags sending.

Ian



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 14:54:59 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 14:54:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLbCi-0000z8-Nx; Tue, 09 Oct 2012 14:54:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLbCg-0000yz-SL
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 14:54:39 +0000
Received: from [85.158.143.99:38335] by server-3.bemta-4.messagelabs.com id
	43/76-10986-EAA34705; Tue, 09 Oct 2012 14:54:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1349794476!25327546!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18619 invoked from network); 9 Oct 2012 14:54:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 14:54:37 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15041815"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 14:54:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	15:54:35 +0100
Message-ID: <1349794474.21847.215.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Eric Dumazet 
Date: Tue, 9 Oct 2012 15:54:34 +0100
In-Reply-To: <1349793217.21172.4497.camel@edumazet-glaptop>
References: <1349790467.21847.185.camel@zakaz.uk.xensource.com>
	<1349790863.21172.4406.camel@edumazet-glaptop>
	<1349791305.21172.4425.camel@edumazet-glaptop>
	<1349792617.21847.205.camel@zakaz.uk.xensource.com>
	<1349793217.21172.4497.camel@edumazet-glaptop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" ,
	Eric Dumazet ,
	Sander Eikelenboom ,
	Konrad Rzeszutek Wilk ,
	xen-devel 
Subject: Re: [Xen-devel] compound skb frag pages appearing in start_xmit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-09 at 15:33 +0100, Eric Dumazet wrote:
> On Tue, 2012-10-09 at 15:23 +0100, Ian Campbell wrote:
> > On Tue, 2012-10-09 at 15:01 +0100, Eric Dumazet wrote:
> > > On Tue, 2012-10-09 at 15:54 +0200, Eric Dumazet wrote:
> > > > On Tue, 2012-10-09 at 14:47 +0100, Ian Campbell wrote:
> > > > > Hi Eric,
> > > > > 
> > > > 
> > > > Hi Ian
> > > > 
> > > > > Sander has discovered an issue where xen-netback is given a compound
> > > > > page as one of the skb frag pages to transmit. Currently netback can
> > > > > only handle PAGE_SIZE'd frags and bugs out.
> > > > > 
> > > > > I suspect this is something to do with 69b08f62e174 "net: use bigger
> > > > > pages in __netdev_alloc_frag", although perhaps not because it looks
> > > > > like only tg3 uses it and Sander has an r8169. Also tg3 seems to only
> > > > > call netdev_alloc_frag for sizes < PAGE_SIZE. I'm probably missing
> > > > > something.
> > > > 
> > > > 
> > > > Its not the commit you want ;)
> > > 
> > > Hmm, I take it back. It also can give you the same problem :
> > > 
> > > We use this allocator for rx path of drivers : 
> > > 
> > >  __netdev_alloc_skb() 
> > > 
> > > So its now absolutely possible that one skb->head is backed by a order-3
> > > page.
> > > 
> > > Is the problem coming from xen_netbk_count_skb_slots() ?
> > > 
> > > Give me more information if you want me to help.
> > 
> > The interesting code is in netbk_gop_skb(), specifically the two calls
> > to netbk_gop_frag_copy.
> > 
> > netbk_gop_frag_copy can only copy order-0 pages to the peer since they
> > go over a shared ring transport which can only deal in order-0 pages.
> > 
> > For the SKB head there is a loop which handles order>0 heads, I suspect
> > we just need something similar for the frag case.
> > 
> > Although see my question in the other response about the maximum number
> > of frags we can have when order is > 0 since if using larger pages
> > causes us to end up with a much larger number of order-0 pages once
> > we've broken them up then we have a problem and I need to put my
> > thinking cap on a bit (perhaps substantially) tighter.
> > 
> > Konrad, it looks like netfront has a similar issue in
> > xennet_make_frags() since it doesn't shatter large order mappings
> > either.
> 
> Hmm...
> 
> In theory, if a skb has 16+1 frags backed by compound pages, you could
> need ~48 order-0 frags.
> 
> (4098 bytes could need 1-4096-1 (3 frags))
> 
> In practice, it should be around ~17 order-0 frags as before.

Right, thanks. I think I can cope with that without needing to change
the PV protocol in any way.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 14:54:59 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 14:54:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLbCi-0000z8-Nx; Tue, 09 Oct 2012 14:54:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLbCg-0000yz-SL
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 14:54:39 +0000
Received: from [85.158.143.99:38335] by server-3.bemta-4.messagelabs.com id
	43/76-10986-EAA34705; Tue, 09 Oct 2012 14:54:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1349794476!25327546!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18619 invoked from network); 9 Oct 2012 14:54:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 14:54:37 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15041815"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 14:54:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	15:54:35 +0100
Message-ID: <1349794474.21847.215.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Eric Dumazet 
Date: Tue, 9 Oct 2012 15:54:34 +0100
In-Reply-To: <1349793217.21172.4497.camel@edumazet-glaptop>
References: <1349790467.21847.185.camel@zakaz.uk.xensource.com>
	<1349790863.21172.4406.camel@edumazet-glaptop>
	<1349791305.21172.4425.camel@edumazet-glaptop>
	<1349792617.21847.205.camel@zakaz.uk.xensource.com>
	<1349793217.21172.4497.camel@edumazet-glaptop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" ,
	Eric Dumazet ,
	Sander Eikelenboom ,
	Konrad Rzeszutek Wilk ,
	xen-devel 
Subject: Re: [Xen-devel] compound skb frag pages appearing in start_xmit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-09 at 15:33 +0100, Eric Dumazet wrote:
> On Tue, 2012-10-09 at 15:23 +0100, Ian Campbell wrote:
> > On Tue, 2012-10-09 at 15:01 +0100, Eric Dumazet wrote:
> > > On Tue, 2012-10-09 at 15:54 +0200, Eric Dumazet wrote:
> > > > On Tue, 2012-10-09 at 14:47 +0100, Ian Campbell wrote:
> > > > > Hi Eric,
> > > > > 
> > > > 
> > > > Hi Ian
> > > > 
> > > > > Sander has discovered an issue where xen-netback is given a compound
> > > > > page as one of the skb frag pages to transmit. Currently netback can
> > > > > only handle PAGE_SIZE'd frags and bugs out.
> > > > > 
> > > > > I suspect this is something to do with 69b08f62e174 "net: use bigger
> > > > > pages in __netdev_alloc_frag", although perhaps not because it looks
> > > > > like only tg3 uses it and Sander has an r8169. Also tg3 seems to only
> > > > > call netdev_alloc_frag for sizes < PAGE_SIZE. I'm probably missing
> > > > > something.
> > > > 
> > > > 
> > > > Its not the commit you want ;)
> > > 
> > > Hmm, I take it back. It also can give you the same problem :
> > > 
> > > We use this allocator for rx path of drivers : 
> > > 
> > >  __netdev_alloc_skb() 
> > > 
> > > So its now absolutely possible that one skb->head is backed by a order-3
> > > page.
> > > 
> > > Is the problem coming from xen_netbk_count_skb_slots() ?
> > > 
> > > Give me more information if you want me to help.
> > 
> > The interesting code is in netbk_gop_skb(), specifically the two calls
> > to netbk_gop_frag_copy.
> > 
> > netbk_gop_frag_copy can only copy order-0 pages to the peer since they
> > go over a shared ring transport which can only deal in order-0 pages.
> > 
> > For the SKB head there is a loop which handles order>0 heads, I suspect
> > we just need something similar for the frag case.
> > 
> > Although see my question in the other response about the maximum number
> > of frags we can have when order is > 0 since if using larger pages
> > causes us to end up with a much larger number of order-0 pages once
> > we've broken them up then we have a problem and I need to put my
> > thinking cap on a bit (perhaps substantially) tighter.
> > 
> > Konrad, it looks like netfront has a similar issue in
> > xennet_make_frags() since it doesn't shatter large order mappings
> > either.
> 
> Hmm...
> 
> In theory, if a skb has 16+1 frags backed by compound pages, you could
> need ~48 order-0 frags.
> 
> (4098 bytes could need 1-4096-1 (3 frags))
> 
> In practice, it should be around ~17 order-0 frags as before.

Right, thanks. I think I can cope with that without needing to change
the PV protocol in any way.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 14:58:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 14:58:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLbGM-0001Ax-Im; Tue, 09 Oct 2012 14:58:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLbGL-0001Al-5c
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 14:58:25 +0000
Received: from [85.158.137.99:11517] by server-3.bemta-3.messagelabs.com id
	63/54-25962-09B34705; Tue, 09 Oct 2012 14:58:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1349794702!20776989!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22126 invoked from network); 9 Oct 2012 14:58:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 14:58:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15041899"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 14:58:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 9 Oct 2012 15:58:06 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TLbG2-00032k-8B;
	Tue, 09 Oct 2012 14:58:06 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TLbG2-0002Dq-6j;
	Tue, 09 Oct 2012 15:58:06 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Tue, 9 Oct 2012 15:58:06 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 13943: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13943 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13943/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386                    4 xen-build                 fail REGR. vs. 13915

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13915
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13915

Tests which did not succeed, but are not blocking:
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 linux                24e842ae6cb8179126246ebcbfc477b36a7b8719
baseline version:
 linux                b9a7985a8d9ca00d8ce977756fde1306c9ab1e41

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 24e842ae6cb8179126246ebcbfc477b36a7b8719
Author: Greg Kroah-Hartman 
Date:   Sun Oct 7 08:28:29 2012 -0700

    Linux 3.0.45

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 14:58:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 14:58:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLbGM-0001Ax-Im; Tue, 09 Oct 2012 14:58:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLbGL-0001Al-5c
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 14:58:25 +0000
Received: from [85.158.137.99:11517] by server-3.bemta-3.messagelabs.com id
	63/54-25962-09B34705; Tue, 09 Oct 2012 14:58:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1349794702!20776989!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22126 invoked from network); 9 Oct 2012 14:58:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 14:58:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15041899"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 14:58:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 9 Oct 2012 15:58:06 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TLbG2-00032k-8B;
	Tue, 09 Oct 2012 14:58:06 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TLbG2-0002Dq-6j;
	Tue, 09 Oct 2012 15:58:06 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Tue, 9 Oct 2012 15:58:06 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 13943: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13943 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13943/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386                    4 xen-build                 fail REGR. vs. 13915

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13915
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13915

Tests which did not succeed, but are not blocking:
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 linux                24e842ae6cb8179126246ebcbfc477b36a7b8719
baseline version:
 linux                b9a7985a8d9ca00d8ce977756fde1306c9ab1e41

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 24e842ae6cb8179126246ebcbfc477b36a7b8719
Author: Greg Kroah-Hartman 
Date:   Sun Oct 7 08:28:29 2012 -0700

    Linux 3.0.45

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 15:04:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 15:04:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLbLV-0001Vf-Li; Tue, 09 Oct 2012 15:03:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLbLU-0001VV-4w
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 15:03:44 +0000
Received: from [85.158.139.83:12412] by server-4.bemta-5.messagelabs.com id
	0A/1A-20767-FCC34705; Tue, 09 Oct 2012 15:03:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1349795022!28474715!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14067 invoked from network); 9 Oct 2012 15:03:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 15:03:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15042085"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 15:03:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 9 Oct 2012 16:03:29 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TLbLF-000368-33; Tue, 09 Oct 2012 15:03:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TLbLE-00047b-UH;
	Tue, 09 Oct 2012 16:03:28 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20596.15552.595313.80971@mariner.uk.xensource.com>
Date: Tue, 9 Oct 2012 16:03:28 +0100
To: Dario Faggioli 
In-Reply-To: <1349780874.3610.89.camel@Abyss>
References: 
	<7fba2d9044e720770c25.1349446106@Solace>
	<20591.3218.46221.931473@mariner.uk.xensource.com>
	<1349780874.3610.89.camel@Abyss>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Marcus Granado ,
	Andre Przywara ,
	Ian Campbell ,
	Anil Madhavapeddy ,
	George Dunlap ,
	Andrew Cooper ,
	Juergen Gross ,
	"xen-devel@lists.xen.org" ,
	Jan Beulich , Daniel De Graaf ,
	Matt Wilson 
Subject: Re: [Xen-devel] [PATCH 8 of 8] xl: add node-affinity to the output
 of `xl list`
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dario Faggioli writes ("Re: [Xen-devel] [PATCH 8 of 8] xl: add node-affinity to the output of `xl list`"):
> Honestly, despite the fact that the function is called print_bitmap(),
> it contains the following code:
> 
>         case 1:
>             if (firstset == 0) {
>                 fprintf(stream, "any cpu");
>                 break;
>             }
>         case 3:

Uh, yes, I see what you mean.

> Which is what made me thinking that opacity was not its first concern in
> the first place, and that turning it into being opaque was none of this
> change's business. :-)

You are right that since you're just moving the code, it's not a
problem for this patch.

> However, I see your point... Perhaps I can add two functions (something
> like print_{cpumap,nodemap}()), both calling the original
> print_bitmap(), and deal with the "any {cpu,node}" case within them... 
> 
> Do you like that better?

That would indeed be an improvement.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 15:04:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 15:04:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLbLV-0001Vf-Li; Tue, 09 Oct 2012 15:03:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLbLU-0001VV-4w
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 15:03:44 +0000
Received: from [85.158.139.83:12412] by server-4.bemta-5.messagelabs.com id
	0A/1A-20767-FCC34705; Tue, 09 Oct 2012 15:03:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1349795022!28474715!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14067 invoked from network); 9 Oct 2012 15:03:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 15:03:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15042085"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 15:03:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 9 Oct 2012 16:03:29 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TLbLF-000368-33; Tue, 09 Oct 2012 15:03:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TLbLE-00047b-UH;
	Tue, 09 Oct 2012 16:03:28 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20596.15552.595313.80971@mariner.uk.xensource.com>
Date: Tue, 9 Oct 2012 16:03:28 +0100
To: Dario Faggioli 
In-Reply-To: <1349780874.3610.89.camel@Abyss>
References: 
	<7fba2d9044e720770c25.1349446106@Solace>
	<20591.3218.46221.931473@mariner.uk.xensource.com>
	<1349780874.3610.89.camel@Abyss>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Marcus Granado ,
	Andre Przywara ,
	Ian Campbell ,
	Anil Madhavapeddy ,
	George Dunlap ,
	Andrew Cooper ,
	Juergen Gross ,
	"xen-devel@lists.xen.org" ,
	Jan Beulich , Daniel De Graaf ,
	Matt Wilson 
Subject: Re: [Xen-devel] [PATCH 8 of 8] xl: add node-affinity to the output
 of `xl list`
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dario Faggioli writes ("Re: [Xen-devel] [PATCH 8 of 8] xl: add node-affinity to the output of `xl list`"):
> Honestly, despite the fact that the function is called print_bitmap(),
> it contains the following code:
> 
>         case 1:
>             if (firstset == 0) {
>                 fprintf(stream, "any cpu");
>                 break;
>             }
>         case 3:

Uh, yes, I see what you mean.

> Which is what made me thinking that opacity was not its first concern in
> the first place, and that turning it into being opaque was none of this
> change's business. :-)

You are right that since you're just moving the code, it's not a
problem for this patch.

> However, I see your point... Perhaps I can add two functions (something
> like print_{cpumap,nodemap}()), both calling the original
> print_bitmap(), and deal with the "any {cpu,node}" case within them... 
> 
> Do you like that better?

That would indeed be an improvement.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 15:24:26 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 15:24:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLbfF-0001nx-Gy; Tue, 09 Oct 2012 15:24:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLbfD-0001ns-E9
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 15:24:07 +0000
Received: from [85.158.139.211:40323] by server-11.bemta-5.messagelabs.com id
	56/44-13866-69144705; Tue, 09 Oct 2012 15:24:06 +0000
X-Env-Sender: arnd@arndb.de
X-Msg-Ref: server-4.tower-206.messagelabs.com!1349796245!21673152!1
X-Originating-IP: [212.227.126.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xNzEgPT4gNjcwMDM=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xNzEgPT4gNjcwMDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3606 invoked from network); 9 Oct 2012 15:24:05 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.126.171)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 15:24:05 -0000
Received: from klappe2.boeblingen.de.ibm.com
	(deibp9eh1--blueice3n2.emea.ibm.com [195.212.29.180])
	by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis)
	id 0MEnBC-1TBDeL0U7G-00FVp7; Tue, 09 Oct 2012 17:23:23 +0200
From: Arnd Bergmann 
To: Russell King 
Date: Tue,  9 Oct 2012 17:22:54 +0200
Message-Id: <1349796183-30648-1-git-send-email-arnd@arndb.de>
X-Mailer: git-send-email 1.7.10
X-Provags-ID: V02:K0:yDMisN99TU4omIRjUsuBeYvP0ndX8ZwpmCJoiA1Icfb
	s6WI3MDb1Oma4n4DC2WHiHX27dk9zISJUPesd649uL9K0NZs9g
	VNy8ymUAIDGpIQVTGyiqpX7fpyAYXfxUBpUJa86jV1uz9ZsVqr
	cIw1FdzWOm7yu7W6DlIH+CBwT6e40ajLABdif3C9gnljBGWycz
	vqz4paDR3JWWnDm0hui6oCxD7w+ALiIbglDFaa8YRfyXdIWkQa
	l1ibAnENHmwmBw+DpQe7TL2Hc4I8p7fXUizhQCecDXK+S2BaLS
	8TyiKrvFvEM7QvllO30lB6ZpKM5xRcmSf6mFNeO/GlX9yNvUes
	gtQJNPOnhN6Q9JoA7kGDSURBRoRdx7SUvdhGOoGLjKzM5Eqmll
	cnghweeL4359x6wzTzH9kwlOVaTwqRd7zk=
Cc: mmarek@suse.cz, dave.martin@linaro.org, xen-devel@lists.xensource.com,
	jonathan.austin@arm.com, arnd@arndb.de, konrad.wilk@oracle.com,
	catalin.marinas@arm.com, linus.walleij@linaro.org,
	stefano.stabellini@eu.citrix.com, sboyd@codeaurora.org,
	linux-kernel@vger.kernel.org, will.deacon@arm.com, rjw@sisk.pl,
	damm@opensource.se, jeremy@goop.org, bryan.wu@canonical.com,
	tglx@linutronix.de, leif.lindholm@arm.com,
	linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [GIT PULL 0/9] ARM architecture fixes for 3.7
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: 

Hi Russell,

Here are some patches that belong into your domain, I hope you can
just send the lot to Linus the next time you send other patches.

These bug fixes all address problems found with automated build testing.
Some of them have been around for a long time, other bugs are
regressions since the merge window.

	Arnd

The following changes since commit 0e51793e162ca432fc5f04178cf82b80a92c2659:

  Merge branch 'for-linus' of git://git.linaro.org/people/rmk/linux-arm (2012-10-07 21:20:57 +0900)

are available in the git repository at:

 git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/fixes-for-rmk

for you to fetch changes up to 93c6cee8e966ceb78a08e6a69a3afc948b74d254:

  ARM: warnings in arch/arm/include/asm/uaccess.h (2012-10-09 17:07:44 +0200)

----------------------------------------------------------------
Arnd Bergmann (9):
      ARM: kprobes: make more tests conditional
      ARM: export set_irq_flags
      ARM: Fix another build warning in arch/arm/mm/alignment.c
      ARM: export default read_current_timer
      ARM: Xen: fix initial build problems:
      ARM: pass -marm to gcc by default for both C and assembler
      ARM: be really quiet when building with 'make -s'
      ARM: binfmt_flat: unused variable 'persistent'
      ARM: warnings in arch/arm/include/asm/uaccess.h

 arch/arm/Kconfig                   |    1 +
 arch/arm/Makefile                  |   13 +++++++------
 arch/arm/boot/Makefile             |   10 +++++-----
 arch/arm/include/asm/flat.h        |    2 +-
 arch/arm/include/asm/uaccess.h     |    4 ++--
 arch/arm/kernel/irq.c              |    2 ++
 arch/arm/kernel/kprobes-test-arm.c |    4 ++++
 arch/arm/lib/delay.c               |    1 +
 arch/arm/mm/alignment.c            |    4 +++-
 arch/arm/tools/Makefile            |    2 +-
 drivers/xen/Kconfig                |    2 ++
 drivers/xen/sys-hypervisor.c       |    1 +
 12 files changed, 30 insertions(+), 16 deletions(-)

Cc: bryan.wu@canonical.com
Cc: catalin.marinas@arm.com
Cc: dave.martin@linaro.org
Cc: jeremy@goop.org
Cc: jonathan.austin@arm.com
Cc: konrad.wilk@oracle.com
Cc: leif.lindholm@arm.com
Cc: linus.walleij@linaro.org
Cc: damm@opensource.se
Cc: mmarek@suse.cz
Cc: rjw@sisk.pl
Cc: rmk+kernel@arm.linux.org.uk
Cc: stefano.stabellini@eu.citrix.com
Cc: sboyd@codeaurora.org
Cc: tglx@linutronix.de
Cc: will.deacon@arm.com
Cc: xen-devel@lists.xensource.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 15:24:26 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 15:24:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLbfF-0001nx-Gy; Tue, 09 Oct 2012 15:24:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLbfD-0001ns-E9
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 15:24:07 +0000
Received: from [85.158.139.211:40323] by server-11.bemta-5.messagelabs.com id
	56/44-13866-69144705; Tue, 09 Oct 2012 15:24:06 +0000
X-Env-Sender: arnd@arndb.de
X-Msg-Ref: server-4.tower-206.messagelabs.com!1349796245!21673152!1
X-Originating-IP: [212.227.126.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xNzEgPT4gNjcwMDM=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xNzEgPT4gNjcwMDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3606 invoked from network); 9 Oct 2012 15:24:05 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.126.171)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 15:24:05 -0000
Received: from klappe2.boeblingen.de.ibm.com
	(deibp9eh1--blueice3n2.emea.ibm.com [195.212.29.180])
	by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis)
	id 0MEnBC-1TBDeL0U7G-00FVp7; Tue, 09 Oct 2012 17:23:23 +0200
From: Arnd Bergmann 
To: Russell King 
Date: Tue,  9 Oct 2012 17:22:54 +0200
Message-Id: <1349796183-30648-1-git-send-email-arnd@arndb.de>
X-Mailer: git-send-email 1.7.10
X-Provags-ID: V02:K0:yDMisN99TU4omIRjUsuBeYvP0ndX8ZwpmCJoiA1Icfb
	s6WI3MDb1Oma4n4DC2WHiHX27dk9zISJUPesd649uL9K0NZs9g
	VNy8ymUAIDGpIQVTGyiqpX7fpyAYXfxUBpUJa86jV1uz9ZsVqr
	cIw1FdzWOm7yu7W6DlIH+CBwT6e40ajLABdif3C9gnljBGWycz
	vqz4paDR3JWWnDm0hui6oCxD7w+ALiIbglDFaa8YRfyXdIWkQa
	l1ibAnENHmwmBw+DpQe7TL2Hc4I8p7fXUizhQCecDXK+S2BaLS
	8TyiKrvFvEM7QvllO30lB6ZpKM5xRcmSf6mFNeO/GlX9yNvUes
	gtQJNPOnhN6Q9JoA7kGDSURBRoRdx7SUvdhGOoGLjKzM5Eqmll
	cnghweeL4359x6wzTzH9kwlOVaTwqRd7zk=
Cc: mmarek@suse.cz, dave.martin@linaro.org, xen-devel@lists.xensource.com,
	jonathan.austin@arm.com, arnd@arndb.de, konrad.wilk@oracle.com,
	catalin.marinas@arm.com, linus.walleij@linaro.org,
	stefano.stabellini@eu.citrix.com, sboyd@codeaurora.org,
	linux-kernel@vger.kernel.org, will.deacon@arm.com, rjw@sisk.pl,
	damm@opensource.se, jeremy@goop.org, bryan.wu@canonical.com,
	tglx@linutronix.de, leif.lindholm@arm.com,
	linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [GIT PULL 0/9] ARM architecture fixes for 3.7
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: 

Hi Russell,

Here are some patches that belong into your domain, I hope you can
just send the lot to Linus the next time you send other patches.

These bug fixes all address problems found with automated build testing.
Some of them have been around for a long time, other bugs are
regressions since the merge window.

	Arnd

The following changes since commit 0e51793e162ca432fc5f04178cf82b80a92c2659:

  Merge branch 'for-linus' of git://git.linaro.org/people/rmk/linux-arm (2012-10-07 21:20:57 +0900)

are available in the git repository at:

 git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/fixes-for-rmk

for you to fetch changes up to 93c6cee8e966ceb78a08e6a69a3afc948b74d254:

  ARM: warnings in arch/arm/include/asm/uaccess.h (2012-10-09 17:07:44 +0200)

----------------------------------------------------------------
Arnd Bergmann (9):
      ARM: kprobes: make more tests conditional
      ARM: export set_irq_flags
      ARM: Fix another build warning in arch/arm/mm/alignment.c
      ARM: export default read_current_timer
      ARM: Xen: fix initial build problems:
      ARM: pass -marm to gcc by default for both C and assembler
      ARM: be really quiet when building with 'make -s'
      ARM: binfmt_flat: unused variable 'persistent'
      ARM: warnings in arch/arm/include/asm/uaccess.h

 arch/arm/Kconfig                   |    1 +
 arch/arm/Makefile                  |   13 +++++++------
 arch/arm/boot/Makefile             |   10 +++++-----
 arch/arm/include/asm/flat.h        |    2 +-
 arch/arm/include/asm/uaccess.h     |    4 ++--
 arch/arm/kernel/irq.c              |    2 ++
 arch/arm/kernel/kprobes-test-arm.c |    4 ++++
 arch/arm/lib/delay.c               |    1 +
 arch/arm/mm/alignment.c            |    4 +++-
 arch/arm/tools/Makefile            |    2 +-
 drivers/xen/Kconfig                |    2 ++
 drivers/xen/sys-hypervisor.c       |    1 +
 12 files changed, 30 insertions(+), 16 deletions(-)

Cc: bryan.wu@canonical.com
Cc: catalin.marinas@arm.com
Cc: dave.martin@linaro.org
Cc: jeremy@goop.org
Cc: jonathan.austin@arm.com
Cc: konrad.wilk@oracle.com
Cc: leif.lindholm@arm.com
Cc: linus.walleij@linaro.org
Cc: damm@opensource.se
Cc: mmarek@suse.cz
Cc: rjw@sisk.pl
Cc: rmk+kernel@arm.linux.org.uk
Cc: stefano.stabellini@eu.citrix.com
Cc: sboyd@codeaurora.org
Cc: tglx@linutronix.de
Cc: will.deacon@arm.com
Cc: xen-devel@lists.xensource.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 15:26:00 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 15:26:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLbgT-0001r1-VY; Tue, 09 Oct 2012 15:25:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLbgT-0001qs-2Q
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 15:25:25 +0000
Received: from [85.158.139.211:50501] by server-14.bemta-5.messagelabs.com id
	8C/C9-31065-4E144705; Tue, 09 Oct 2012 15:25:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1349796322!21662620!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 481 invoked from network); 9 Oct 2012 15:25:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 15:25:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15042804"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 15:23:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 9 Oct 2012 16:23:34 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TLbeg-0003H7-BJ; Tue, 09 Oct 2012 15:23:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TLbeg-00048U-7U;
	Tue, 09 Oct 2012 16:23:34 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20596.16757.874363.819950@mariner.uk.xensource.com>
Date: Tue, 9 Oct 2012 16:23:33 +0100
To: Daniel De Graaf 
In-Reply-To: <1346864713-28732-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1346400260.27277.93.camel@zakaz.uk.xensource.com>
	<1346864713-28732-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH v2] libxl: Support backend domain ID for
	disks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Daniel De Graaf writes ("[PATCH v2] libxl: Support backend domain ID for disks"):
> Allow specification of backend domains for disks, either in the config
> file or via xl block-attach. This functionality was supported in xend
> (via an optional command line parameter to block-attach), so should also
> be supported with libxl.
> 
> In order to support named backend domains like network-attach, a valid
> libxl_ctx must now be passed to xlu_cfg_init.

I've been thinking about this and I'm afraid I've come to the
conclusion that the way your new API specifies backend domains is not
the way I think it should be done.

In particular, I think translating the config file from a source text
into an idl configuration structure shouldn't depend on looking up
information like domids.  (The same would be true of DNS names, or
other runtime lookups.)  So I think the backend domain _name_ should
be in the IDL structure.

But of course it should also be possible to specify a domid.

I can think of three (at least superficially) plausible ways to define
this API:

1. The backend domain is specified as a string.  If specifying a domid
   is desired, the string is the domid number in ascii.  Domains whose
   names are entirely valid numbers according to strtoul(,,0) cannot
   be specified as backends by name (or should perhaps be prohibited
   entirely - xl can't handle them anyway).

2. The IDL contains both a string and a number.  If the string is
   provided, it is used; otherwise the number is used.

3. The IDL contains a variadic "domspec" structure which allows the
   domain to be specified (a) not at all (b) as a domid (c) as a
   domain name (d) as a uuid.

Of these I think 3 is probably overkill and either 1 or 2 is
acceptable and I have a marginal preference for 2.

Before you implement any of this I think we should agree whether my
qualm about domain name lookups during config parsing is justified,
and what the right API is.

NB that this complaint does seem perhaps contrary to my intent to add
a libxl context to libxlu parsing calls.  But, having thought about
it, this libxl context should be a "dummy" one which can be used for
memory allocation and logging but which does not support actual Xen
functionality.

Thanks, and sorry to block your useful new functionality on cans of
works.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 15:26:00 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 15:26:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLbgT-0001r1-VY; Tue, 09 Oct 2012 15:25:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLbgT-0001qs-2Q
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 15:25:25 +0000
Received: from [85.158.139.211:50501] by server-14.bemta-5.messagelabs.com id
	8C/C9-31065-4E144705; Tue, 09 Oct 2012 15:25:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1349796322!21662620!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 481 invoked from network); 9 Oct 2012 15:25:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 15:25:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15042804"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 15:23:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 9 Oct 2012 16:23:34 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TLbeg-0003H7-BJ; Tue, 09 Oct 2012 15:23:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TLbeg-00048U-7U;
	Tue, 09 Oct 2012 16:23:34 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20596.16757.874363.819950@mariner.uk.xensource.com>
Date: Tue, 9 Oct 2012 16:23:33 +0100
To: Daniel De Graaf 
In-Reply-To: <1346864713-28732-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1346400260.27277.93.camel@zakaz.uk.xensource.com>
	<1346864713-28732-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH v2] libxl: Support backend domain ID for
	disks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Daniel De Graaf writes ("[PATCH v2] libxl: Support backend domain ID for disks"):
> Allow specification of backend domains for disks, either in the config
> file or via xl block-attach. This functionality was supported in xend
> (via an optional command line parameter to block-attach), so should also
> be supported with libxl.
> 
> In order to support named backend domains like network-attach, a valid
> libxl_ctx must now be passed to xlu_cfg_init.

I've been thinking about this and I'm afraid I've come to the
conclusion that the way your new API specifies backend domains is not
the way I think it should be done.

In particular, I think translating the config file from a source text
into an idl configuration structure shouldn't depend on looking up
information like domids.  (The same would be true of DNS names, or
other runtime lookups.)  So I think the backend domain _name_ should
be in the IDL structure.

But of course it should also be possible to specify a domid.

I can think of three (at least superficially) plausible ways to define
this API:

1. The backend domain is specified as a string.  If specifying a domid
   is desired, the string is the domid number in ascii.  Domains whose
   names are entirely valid numbers according to strtoul(,,0) cannot
   be specified as backends by name (or should perhaps be prohibited
   entirely - xl can't handle them anyway).

2. The IDL contains both a string and a number.  If the string is
   provided, it is used; otherwise the number is used.

3. The IDL contains a variadic "domspec" structure which allows the
   domain to be specified (a) not at all (b) as a domid (c) as a
   domain name (d) as a uuid.

Of these I think 3 is probably overkill and either 1 or 2 is
acceptable and I have a marginal preference for 2.

Before you implement any of this I think we should agree whether my
qualm about domain name lookups during config parsing is justified,
and what the right API is.

NB that this complaint does seem perhaps contrary to my intent to add
a libxl context to libxlu parsing calls.  But, having thought about
it, this libxl context should be a "dummy" one which can be used for
memory allocation and logging but which does not support actual Xen
functionality.

Thanks, and sorry to block your useful new functionality on cans of
works.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 15:27:46 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 15:27:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLbiD-0001z6-Ku; Tue, 09 Oct 2012 15:27:13 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLbiC-0001yX-5J
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 15:27:12 +0000
X-Env-Sender: arnd@arndb.de
X-Msg-Ref: server-3.tower-27.messagelabs.com!1349796228!12063237!1
X-Originating-IP: [212.227.17.8]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjE3LjggPT4gODE4ODA=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjE3LjggPT4gODE4ODA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12481 invoked from network); 9 Oct 2012 15:23:49 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.17.8)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 15:23:49 -0000
Received: from klappe2.boeblingen.de.ibm.com
	(deibp9eh1--blueice3n2.emea.ibm.com [195.212.29.180])
	by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis)
	id 0LsR2m-1TWiXd187U-012XkF; Tue, 09 Oct 2012 17:23:25 +0200
From: Arnd Bergmann 
To: Russell King 
Date: Tue,  9 Oct 2012 17:22:59 +0200
Message-Id: <1349796183-30648-6-git-send-email-arnd@arndb.de>
X-Mailer: git-send-email 1.7.10
In-Reply-To: <1349796183-30648-1-git-send-email-arnd@arndb.de>
References: <1349796183-30648-1-git-send-email-arnd@arndb.de>
X-Provags-ID: V02:K0:wonDB4PQGnkIHpBIToFyQGOp1BxaQQhDbrVUFMu/jE5
	pNfF+A9qryJ8vA8tLb8bX050UC/Nh+SdwRV6rix6YT7TcQfjp0
	vytJUOciR4R3OiSpqvVHvxhrI1QM2wN7Hojj/IQOeHywzX45Tf
	43io2aZlRHPDxc+A0v92bGE+ID5aeMEr53kIhG+k3nxbnfqggN
	NOGuM03fOP7vq8mrmswr2QhoujxlnX/Hd7UkyPfda4Soo3lj8W
	xfpCu8rc69bNblqBoU95vGZuQeG5zlvgChMfaDbcL3ovOn/UxJ
	8g1uHTdOpWKPjrtFpbJvhxGgLrgceK6EkJ+TvazCc2jPj5LBPq
	9R+/wh2L7o1t2rPc4YVbHAyYUkfU5hlB11488mtebOsdG8iU6v
	hs7faw/ByjL17NguB8J83HtolqglKXg72s=
Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com,
	Arnd Bergmann ,
	Konrad Rzeszutek Wilk ,
	Stefano Stabellini ,
	linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

* The XEN_BALLOON code requires the balloon infrastructure that is not
  getting built on ARM.

* The tmem hypercall is not available on ARM

* ARMv6 does not support cmpxchg on 16-bit words that are used in the

* sys-hypervisor.c needs to include linux/err.h in order to use the
  IS_ERR/PTR_ERR/ERR_PTR family of functions.

Signed-off-by: Arnd Bergmann 
Cc: Stefano Stabellini 
Cc: Konrad Rzeszutek Wilk 
Cc: Jeremy Fitzhardinge 
Cc: xen-devel@lists.xensource.com
---
 arch/arm/Kconfig             |    1 +
 drivers/xen/Kconfig          |    2 ++
 drivers/xen/sys-hypervisor.c |    1 +
 3 files changed, 4 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 6d2f7f5..85eaac3 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1846,6 +1846,7 @@ config XEN_DOM0
 config XEN
 	bool "Xen guest support on ARM (EXPERIMENTAL)"
 	depends on EXPERIMENTAL && ARM && OF
+	depends on !CPU_V6
 	help
 	  Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
 
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index d4dffcd..126d8ce 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -3,6 +3,7 @@ menu "Xen driver support"
 
 config XEN_BALLOON
 	bool "Xen memory balloon driver"
+	depends on !ARM
 	default y
 	help
 	  The balloon driver allows the Xen domain to request more memory from
@@ -145,6 +146,7 @@ config SWIOTLB_XEN
 
 config XEN_TMEM
 	bool
+	depends on !ARM
 	default y if (CLEANCACHE || FRONTSWAP)
 	help
 	  Shim to interface in-kernel Transcendent Memory hooks
diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c
index 5e5ad7e..66a0a14 100644
--- a/drivers/xen/sys-hypervisor.c
+++ b/drivers/xen/sys-hypervisor.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
-- 
1.7.10


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 15:27:46 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 15:27:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLbiD-0001z6-Ku; Tue, 09 Oct 2012 15:27:13 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLbiC-0001yX-5J
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 15:27:12 +0000
X-Env-Sender: arnd@arndb.de
X-Msg-Ref: server-3.tower-27.messagelabs.com!1349796228!12063237!1
X-Originating-IP: [212.227.17.8]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjE3LjggPT4gODE4ODA=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjE3LjggPT4gODE4ODA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12481 invoked from network); 9 Oct 2012 15:23:49 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.17.8)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 15:23:49 -0000
Received: from klappe2.boeblingen.de.ibm.com
	(deibp9eh1--blueice3n2.emea.ibm.com [195.212.29.180])
	by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis)
	id 0LsR2m-1TWiXd187U-012XkF; Tue, 09 Oct 2012 17:23:25 +0200
From: Arnd Bergmann 
To: Russell King 
Date: Tue,  9 Oct 2012 17:22:59 +0200
Message-Id: <1349796183-30648-6-git-send-email-arnd@arndb.de>
X-Mailer: git-send-email 1.7.10
In-Reply-To: <1349796183-30648-1-git-send-email-arnd@arndb.de>
References: <1349796183-30648-1-git-send-email-arnd@arndb.de>
X-Provags-ID: V02:K0:wonDB4PQGnkIHpBIToFyQGOp1BxaQQhDbrVUFMu/jE5
	pNfF+A9qryJ8vA8tLb8bX050UC/Nh+SdwRV6rix6YT7TcQfjp0
	vytJUOciR4R3OiSpqvVHvxhrI1QM2wN7Hojj/IQOeHywzX45Tf
	43io2aZlRHPDxc+A0v92bGE+ID5aeMEr53kIhG+k3nxbnfqggN
	NOGuM03fOP7vq8mrmswr2QhoujxlnX/Hd7UkyPfda4Soo3lj8W
	xfpCu8rc69bNblqBoU95vGZuQeG5zlvgChMfaDbcL3ovOn/UxJ
	8g1uHTdOpWKPjrtFpbJvhxGgLrgceK6EkJ+TvazCc2jPj5LBPq
	9R+/wh2L7o1t2rPc4YVbHAyYUkfU5hlB11488mtebOsdG8iU6v
	hs7faw/ByjL17NguB8J83HtolqglKXg72s=
Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com,
	Arnd Bergmann ,
	Konrad Rzeszutek Wilk ,
	Stefano Stabellini ,
	linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

* The XEN_BALLOON code requires the balloon infrastructure that is not
  getting built on ARM.

* The tmem hypercall is not available on ARM

* ARMv6 does not support cmpxchg on 16-bit words that are used in the

* sys-hypervisor.c needs to include linux/err.h in order to use the
  IS_ERR/PTR_ERR/ERR_PTR family of functions.

Signed-off-by: Arnd Bergmann 
Cc: Stefano Stabellini 
Cc: Konrad Rzeszutek Wilk 
Cc: Jeremy Fitzhardinge 
Cc: xen-devel@lists.xensource.com
---
 arch/arm/Kconfig             |    1 +
 drivers/xen/Kconfig          |    2 ++
 drivers/xen/sys-hypervisor.c |    1 +
 3 files changed, 4 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 6d2f7f5..85eaac3 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1846,6 +1846,7 @@ config XEN_DOM0
 config XEN
 	bool "Xen guest support on ARM (EXPERIMENTAL)"
 	depends on EXPERIMENTAL && ARM && OF
+	depends on !CPU_V6
 	help
 	  Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
 
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index d4dffcd..126d8ce 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -3,6 +3,7 @@ menu "Xen driver support"
 
 config XEN_BALLOON
 	bool "Xen memory balloon driver"
+	depends on !ARM
 	default y
 	help
 	  The balloon driver allows the Xen domain to request more memory from
@@ -145,6 +146,7 @@ config SWIOTLB_XEN
 
 config XEN_TMEM
 	bool
+	depends on !ARM
 	default y if (CLEANCACHE || FRONTSWAP)
 	help
 	  Shim to interface in-kernel Transcendent Memory hooks
diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c
index 5e5ad7e..66a0a14 100644
--- a/drivers/xen/sys-hypervisor.c
+++ b/drivers/xen/sys-hypervisor.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
-- 
1.7.10


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 15:29:28 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 15:29:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLbjp-00027l-4Q; Tue, 09 Oct 2012 15:28:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLbjm-00027S-Rq
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 15:28:51 +0000
Received: from [85.158.139.211:38475] by server-10.bemta-5.messagelabs.com id
	E6/B9-16911-2B244705; Tue, 09 Oct 2012 15:28:50 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1349796529!21647039!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 746 invoked from network); 9 Oct 2012 15:28:49 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 15:28:49 -0000
Received: by mail-bk0-f45.google.com with SMTP id jf3so2622718bkc.32
	for ; Tue, 09 Oct 2012 08:28:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:from:to:cc:in-reply-to:references:content-type:date
	:message-id:mime-version:x-mailer:content-transfer-encoding;
	bh=jceL2rhoVjuTbbVlbMY3V2yvfraeoYXi0cJpTSDgmAk=;
	b=Oh3uCHSBEHqjDjQdjqC648452VuUQCi3+HZ7TFEmTgLY8U24zNqIMa1zXyfwlTbCe3
	tdGTp9591D3ykZB7Z454sBZ1CJYlM6dFfTnPgJs+O8z1HPrtaLaJ/keO03m0jnABGyF6
	2wrPB7zJyrJ8d6UNlGh7uw2uO9n2JE2ShDhDria+jMBmUO20y6jlWCj7H1JvOZJ/oB3H
	Gwfktc/qIPOK6gzX+2cWxa20DTaIpHc9G38NwHf3VwVpZ7OR9oBCJSWHK+1V+xo2oQXF
	pTONS5Q4L3tRrOkSdiGS+TknaB94HRWHjFffncMK0qkQDQjz9o3a568Xq+4xAG95fvtG
	ji+g==
Received: by 10.204.152.25 with SMTP id e25mr6851175bkw.70.1349796529224;
	Tue, 09 Oct 2012 08:28:49 -0700 (PDT)
Received: from [172.28.90.230] ([172.28.90.230])
	by mx.google.com with ESMTPS id k21sm15128147bkv.1.2012.10.09.08.28.31
	(version=SSLv3 cipher=OTHER); Tue, 09 Oct 2012 08:28:40 -0700 (PDT)
From: Eric Dumazet 
To: Ian Campbell 
In-Reply-To: <1349793630.21847.208.camel@zakaz.uk.xensource.com>
References: <1349790467.21847.185.camel@zakaz.uk.xensource.com>
	<1349790863.21172.4406.camel@edumazet-glaptop>
	<1349792241.21847.199.camel@zakaz.uk.xensource.com>
	<1349792847.21172.4479.camel@edumazet-glaptop>
	<1349793630.21847.208.camel@zakaz.uk.xensource.com>
Date: Tue, 09 Oct 2012 16:51:40 +0200
Message-ID: <1349794300.21172.4536.camel@edumazet-glaptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: "netdev@vger.kernel.org" ,
	Eric Dumazet ,
	Sander Eikelenboom ,
	Konrad Rzeszutek Wilk ,
	xen-devel 
Subject: Re: [Xen-devel] compound skb frag pages appearing in start_xmit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-09 at 15:40 +0100, Ian Campbell wrote:
> On Tue, 2012-10-09 at 15:27 +0100, Eric Dumazet wrote:
> > On Tue, 2012-10-09 at 15:17 +0100, Ian Campbell wrote:
> > 
> > > Does the higher order pages effectively reduce the number of frags which
> > > are in use? e.g if MAX_SKB_FRAGS is 16, then for order-0 pages you could
> > > have 64K worth of frag data.
> > > 
> > > If we switch to order-3 pages everywhere then can the skb contain 512K
> > > of data, or does the effective maximum number of frags in an skb reduce
> > > to 2?
> > 
> > effective number of frags reduce to 2 or 3
> > 
> > (We still limit GSO packets to ~63536 bytes)
> 
> Great! Then I think the fix is more/less trivial...
> 
> As an aside, when the skb head is < 4096 bytes is that necessarily a
> compound page or might it just be a large kmalloc area?
> 

skb->head can be either allocated by kmalloc() (standard alloc_skb()) or
a page frag (if allocated in rx path)

Not sure its related to headlen/size...




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 15:29:28 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 15:29:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLbjp-00027l-4Q; Tue, 09 Oct 2012 15:28:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLbjm-00027S-Rq
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 15:28:51 +0000
Received: from [85.158.139.211:38475] by server-10.bemta-5.messagelabs.com id
	E6/B9-16911-2B244705; Tue, 09 Oct 2012 15:28:50 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1349796529!21647039!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 746 invoked from network); 9 Oct 2012 15:28:49 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 15:28:49 -0000
Received: by mail-bk0-f45.google.com with SMTP id jf3so2622718bkc.32
	for ; Tue, 09 Oct 2012 08:28:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:from:to:cc:in-reply-to:references:content-type:date
	:message-id:mime-version:x-mailer:content-transfer-encoding;
	bh=jceL2rhoVjuTbbVlbMY3V2yvfraeoYXi0cJpTSDgmAk=;
	b=Oh3uCHSBEHqjDjQdjqC648452VuUQCi3+HZ7TFEmTgLY8U24zNqIMa1zXyfwlTbCe3
	tdGTp9591D3ykZB7Z454sBZ1CJYlM6dFfTnPgJs+O8z1HPrtaLaJ/keO03m0jnABGyF6
	2wrPB7zJyrJ8d6UNlGh7uw2uO9n2JE2ShDhDria+jMBmUO20y6jlWCj7H1JvOZJ/oB3H
	Gwfktc/qIPOK6gzX+2cWxa20DTaIpHc9G38NwHf3VwVpZ7OR9oBCJSWHK+1V+xo2oQXF
	pTONS5Q4L3tRrOkSdiGS+TknaB94HRWHjFffncMK0qkQDQjz9o3a568Xq+4xAG95fvtG
	ji+g==
Received: by 10.204.152.25 with SMTP id e25mr6851175bkw.70.1349796529224;
	Tue, 09 Oct 2012 08:28:49 -0700 (PDT)
Received: from [172.28.90.230] ([172.28.90.230])
	by mx.google.com with ESMTPS id k21sm15128147bkv.1.2012.10.09.08.28.31
	(version=SSLv3 cipher=OTHER); Tue, 09 Oct 2012 08:28:40 -0700 (PDT)
From: Eric Dumazet 
To: Ian Campbell 
In-Reply-To: <1349793630.21847.208.camel@zakaz.uk.xensource.com>
References: <1349790467.21847.185.camel@zakaz.uk.xensource.com>
	<1349790863.21172.4406.camel@edumazet-glaptop>
	<1349792241.21847.199.camel@zakaz.uk.xensource.com>
	<1349792847.21172.4479.camel@edumazet-glaptop>
	<1349793630.21847.208.camel@zakaz.uk.xensource.com>
Date: Tue, 09 Oct 2012 16:51:40 +0200
Message-ID: <1349794300.21172.4536.camel@edumazet-glaptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: "netdev@vger.kernel.org" ,
	Eric Dumazet ,
	Sander Eikelenboom ,
	Konrad Rzeszutek Wilk ,
	xen-devel 
Subject: Re: [Xen-devel] compound skb frag pages appearing in start_xmit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-09 at 15:40 +0100, Ian Campbell wrote:
> On Tue, 2012-10-09 at 15:27 +0100, Eric Dumazet wrote:
> > On Tue, 2012-10-09 at 15:17 +0100, Ian Campbell wrote:
> > 
> > > Does the higher order pages effectively reduce the number of frags which
> > > are in use? e.g if MAX_SKB_FRAGS is 16, then for order-0 pages you could
> > > have 64K worth of frag data.
> > > 
> > > If we switch to order-3 pages everywhere then can the skb contain 512K
> > > of data, or does the effective maximum number of frags in an skb reduce
> > > to 2?
> > 
> > effective number of frags reduce to 2 or 3
> > 
> > (We still limit GSO packets to ~63536 bytes)
> 
> Great! Then I think the fix is more/less trivial...
> 
> As an aside, when the skb head is < 4096 bytes is that necessarily a
> compound page or might it just be a large kmalloc area?
> 

skb->head can be either allocated by kmalloc() (standard alloc_skb()) or
a page frag (if allocated in rx path)

Not sure its related to headlen/size...




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 15:36:26 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 15:36:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLbqr-0002Qj-1G; Tue, 09 Oct 2012 15:36:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLbqq-0002Qe-5C
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 15:36:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1349796960!4735797!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8482 invoked from network); 9 Oct 2012 15:36:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 15:36:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15043536"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 15:36:00 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	16:36:00 +0100
Message-ID: <1349796958.21847.219.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Arnd Bergmann 
Date: Tue, 9 Oct 2012 16:35:58 +0100
In-Reply-To: <1349796183-30648-6-git-send-email-arnd@arndb.de>
References: <1349796183-30648-1-git-send-email-arnd@arndb.de>
	<1349796183-30648-6-git-send-email-arnd@arndb.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge ,
	"xen-devel@lists.xensource.com" ,
	Stefano Stabellini ,
	Konrad Rzeszutek Wilk ,
	"linux-kernel@vger.kernel.org" ,
	Russell King ,
	"linux-arm-kernel@lists.infradead.org"
	
Subject: Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-09 at 16:22 +0100, Arnd Bergmann wrote:
> * The XEN_BALLOON code requires the balloon infrastructure that is not
>   getting built on ARM.

I've got patches to enable this, but not for 3.7 so this looks good for
now.

> * The tmem hypercall is not available on ARM
> 
> * ARMv6 does not support cmpxchg on 16-bit words that are used in the

missing the end of this sentence?

> * sys-hypervisor.c needs to include linux/err.h in order to use the
>   IS_ERR/PTR_ERR/ERR_PTR family of functions.

I tripped over this too. Not sure where that patch got to though.

> Signed-off-by: Arnd Bergmann 

Acked-by: Ian Campbell 

> Cc: Stefano Stabellini 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Jeremy Fitzhardinge 
> Cc: xen-devel@lists.xensource.com
> ---
>  arch/arm/Kconfig             |    1 +
>  drivers/xen/Kconfig          |    2 ++
>  drivers/xen/sys-hypervisor.c |    1 +
>  3 files changed, 4 insertions(+)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 6d2f7f5..85eaac3 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1846,6 +1846,7 @@ config XEN_DOM0
>  config XEN
>  	bool "Xen guest support on ARM (EXPERIMENTAL)"
>  	depends on EXPERIMENTAL && ARM && OF
> +	depends on !CPU_V6
>  	help
>  	  Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
>  
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index d4dffcd..126d8ce 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -3,6 +3,7 @@ menu "Xen driver support"
>  
>  config XEN_BALLOON
>  	bool "Xen memory balloon driver"
> +	depends on !ARM
>  	default y
>  	help
>  	  The balloon driver allows the Xen domain to request more memory from
> @@ -145,6 +146,7 @@ config SWIOTLB_XEN
>  
>  config XEN_TMEM
>  	bool
> +	depends on !ARM
>  	default y if (CLEANCACHE || FRONTSWAP)
>  	help
>  	  Shim to interface in-kernel Transcendent Memory hooks
> diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c
> index 5e5ad7e..66a0a14 100644
> --- a/drivers/xen/sys-hypervisor.c
> +++ b/drivers/xen/sys-hypervisor.c
> @@ -11,6 +11,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 15:36:26 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 15:36:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLbqr-0002Qj-1G; Tue, 09 Oct 2012 15:36:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLbqq-0002Qe-5C
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 15:36:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1349796960!4735797!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8482 invoked from network); 9 Oct 2012 15:36:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 15:36:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15043536"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 15:36:00 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	16:36:00 +0100
Message-ID: <1349796958.21847.219.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Arnd Bergmann 
Date: Tue, 9 Oct 2012 16:35:58 +0100
In-Reply-To: <1349796183-30648-6-git-send-email-arnd@arndb.de>
References: <1349796183-30648-1-git-send-email-arnd@arndb.de>
	<1349796183-30648-6-git-send-email-arnd@arndb.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge ,
	"xen-devel@lists.xensource.com" ,
	Stefano Stabellini ,
	Konrad Rzeszutek Wilk ,
	"linux-kernel@vger.kernel.org" ,
	Russell King ,
	"linux-arm-kernel@lists.infradead.org"
	
Subject: Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-09 at 16:22 +0100, Arnd Bergmann wrote:
> * The XEN_BALLOON code requires the balloon infrastructure that is not
>   getting built on ARM.

I've got patches to enable this, but not for 3.7 so this looks good for
now.

> * The tmem hypercall is not available on ARM
> 
> * ARMv6 does not support cmpxchg on 16-bit words that are used in the

missing the end of this sentence?

> * sys-hypervisor.c needs to include linux/err.h in order to use the
>   IS_ERR/PTR_ERR/ERR_PTR family of functions.

I tripped over this too. Not sure where that patch got to though.

> Signed-off-by: Arnd Bergmann 

Acked-by: Ian Campbell 

> Cc: Stefano Stabellini 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Jeremy Fitzhardinge 
> Cc: xen-devel@lists.xensource.com
> ---
>  arch/arm/Kconfig             |    1 +
>  drivers/xen/Kconfig          |    2 ++
>  drivers/xen/sys-hypervisor.c |    1 +
>  3 files changed, 4 insertions(+)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 6d2f7f5..85eaac3 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1846,6 +1846,7 @@ config XEN_DOM0
>  config XEN
>  	bool "Xen guest support on ARM (EXPERIMENTAL)"
>  	depends on EXPERIMENTAL && ARM && OF
> +	depends on !CPU_V6
>  	help
>  	  Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
>  
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index d4dffcd..126d8ce 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -3,6 +3,7 @@ menu "Xen driver support"
>  
>  config XEN_BALLOON
>  	bool "Xen memory balloon driver"
> +	depends on !ARM
>  	default y
>  	help
>  	  The balloon driver allows the Xen domain to request more memory from
> @@ -145,6 +146,7 @@ config SWIOTLB_XEN
>  
>  config XEN_TMEM
>  	bool
> +	depends on !ARM
>  	default y if (CLEANCACHE || FRONTSWAP)
>  	help
>  	  Shim to interface in-kernel Transcendent Memory hooks
> diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c
> index 5e5ad7e..66a0a14 100644
> --- a/drivers/xen/sys-hypervisor.c
> +++ b/drivers/xen/sys-hypervisor.c
> @@ -11,6 +11,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 15:38:56 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 15:38:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLbsn-0002WD-I1; Tue, 09 Oct 2012 15:38:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLbsm-0002W5-9k
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 15:38:08 +0000
Received: from [85.158.139.83:16242] by server-11.bemta-5.messagelabs.com id
	18/C3-13866-FD444705; Tue, 09 Oct 2012 15:38:07 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1349797086!26760402!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10419 invoked from network); 9 Oct 2012 15:38:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 15:38:07 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15043731"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 15:38:06 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 9 Oct 2012 16:38:06 +0100
Date: Tue, 9 Oct 2012 16:37:01 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Arnd Bergmann 
In-Reply-To: <1349796183-30648-6-git-send-email-arnd@arndb.de>
Message-ID: 
References: <1349796183-30648-1-git-send-email-arnd@arndb.de>
	<1349796183-30648-6-git-send-email-arnd@arndb.de>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge ,
	"xen-devel@lists.xensource.com" ,
	Konrad Rzeszutek Wilk ,
	Stefano Stabellini ,
	"linux-kernel@vger.kernel.org" ,
	Russell King ,
	"linux-arm-kernel@lists.infradead.org"
	
Subject: Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thanks for the patch and sorry for the build breakage!

On Tue, 9 Oct 2012, Arnd Bergmann wrote:
> * The XEN_BALLOON code requires the balloon infrastructure that is not
>   getting built on ARM.
> 
> * The tmem hypercall is not available on ARM
> 
> * ARMv6 does not support cmpxchg on 16-bit words that are used in the
> 
> * sys-hypervisor.c needs to include linux/err.h in order to use the
>   IS_ERR/PTR_ERR/ERR_PTR family of functions.
> 
> Signed-off-by: Arnd Bergmann 
> Cc: Stefano Stabellini 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Jeremy Fitzhardinge 
> Cc: xen-devel@lists.xensource.com
> ---
>  arch/arm/Kconfig             |    1 +
>  drivers/xen/Kconfig          |    2 ++
>  drivers/xen/sys-hypervisor.c |    1 +
>  3 files changed, 4 insertions(+)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 6d2f7f5..85eaac3 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1846,6 +1846,7 @@ config XEN_DOM0
>  config XEN
>  	bool "Xen guest support on ARM (EXPERIMENTAL)"
>  	depends on EXPERIMENTAL && ARM && OF
> +	depends on !CPU_V6
>  	help
>  	  Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.

Considering that we rely on the virtualization extensions, this one can
be:

    depends on CPU_V7

The rest looks fine. I can submit a second patch to change !CPU_V6 into
CPU_V7 later, if you prefer.


> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index d4dffcd..126d8ce 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -3,6 +3,7 @@ menu "Xen driver support"
>  
>  config XEN_BALLOON
>  	bool "Xen memory balloon driver"
> +	depends on !ARM
>  	default y
>  	help
>  	  The balloon driver allows the Xen domain to request more memory from
> @@ -145,6 +146,7 @@ config SWIOTLB_XEN
>  
>  config XEN_TMEM
>  	bool
> +	depends on !ARM
>  	default y if (CLEANCACHE || FRONTSWAP)
>  	help
>  	  Shim to interface in-kernel Transcendent Memory hooks
>
> diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c
> index 5e5ad7e..66a0a14 100644
> --- a/drivers/xen/sys-hypervisor.c
> +++ b/drivers/xen/sys-hypervisor.c
> @@ -11,6 +11,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> -- 
> 1.7.10
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 15:38:56 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 15:38:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLbsn-0002WD-I1; Tue, 09 Oct 2012 15:38:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLbsm-0002W5-9k
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 15:38:08 +0000
Received: from [85.158.139.83:16242] by server-11.bemta-5.messagelabs.com id
	18/C3-13866-FD444705; Tue, 09 Oct 2012 15:38:07 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1349797086!26760402!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10419 invoked from network); 9 Oct 2012 15:38:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 15:38:07 -0000
X-IronPort-AV: E=Sophos;i="4.80,560,1344211200"; d="scan'208";a="15043731"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 15:38:06 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 9 Oct 2012 16:38:06 +0100
Date: Tue, 9 Oct 2012 16:37:01 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Arnd Bergmann 
In-Reply-To: <1349796183-30648-6-git-send-email-arnd@arndb.de>
Message-ID: 
References: <1349796183-30648-1-git-send-email-arnd@arndb.de>
	<1349796183-30648-6-git-send-email-arnd@arndb.de>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge ,
	"xen-devel@lists.xensource.com" ,
	Konrad Rzeszutek Wilk ,
	Stefano Stabellini ,
	"linux-kernel@vger.kernel.org" ,
	Russell King ,
	"linux-arm-kernel@lists.infradead.org"
	
Subject: Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thanks for the patch and sorry for the build breakage!

On Tue, 9 Oct 2012, Arnd Bergmann wrote:
> * The XEN_BALLOON code requires the balloon infrastructure that is not
>   getting built on ARM.
> 
> * The tmem hypercall is not available on ARM
> 
> * ARMv6 does not support cmpxchg on 16-bit words that are used in the
> 
> * sys-hypervisor.c needs to include linux/err.h in order to use the
>   IS_ERR/PTR_ERR/ERR_PTR family of functions.
> 
> Signed-off-by: Arnd Bergmann 
> Cc: Stefano Stabellini 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Jeremy Fitzhardinge 
> Cc: xen-devel@lists.xensource.com
> ---
>  arch/arm/Kconfig             |    1 +
>  drivers/xen/Kconfig          |    2 ++
>  drivers/xen/sys-hypervisor.c |    1 +
>  3 files changed, 4 insertions(+)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 6d2f7f5..85eaac3 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1846,6 +1846,7 @@ config XEN_DOM0
>  config XEN
>  	bool "Xen guest support on ARM (EXPERIMENTAL)"
>  	depends on EXPERIMENTAL && ARM && OF
> +	depends on !CPU_V6
>  	help
>  	  Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.

Considering that we rely on the virtualization extensions, this one can
be:

    depends on CPU_V7

The rest looks fine. I can submit a second patch to change !CPU_V6 into
CPU_V7 later, if you prefer.


> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index d4dffcd..126d8ce 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -3,6 +3,7 @@ menu "Xen driver support"
>  
>  config XEN_BALLOON
>  	bool "Xen memory balloon driver"
> +	depends on !ARM
>  	default y
>  	help
>  	  The balloon driver allows the Xen domain to request more memory from
> @@ -145,6 +146,7 @@ config SWIOTLB_XEN
>  
>  config XEN_TMEM
>  	bool
> +	depends on !ARM
>  	default y if (CLEANCACHE || FRONTSWAP)
>  	help
>  	  Shim to interface in-kernel Transcendent Memory hooks
>
> diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c
> index 5e5ad7e..66a0a14 100644
> --- a/drivers/xen/sys-hypervisor.c
> +++ b/drivers/xen/sys-hypervisor.c
> @@ -11,6 +11,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> -- 
> 1.7.10
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 15:40:33 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 15:40:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLbue-0002dg-1j; Tue, 09 Oct 2012 15:40:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLbuc-0002dY-DR
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 15:40:02 +0000
Received: from [85.158.143.99:29316] by server-1.bemta-4.messagelabs.com id
	F7/B0-05684-15544705; Tue, 09 Oct 2012 15:40:01 +0000
X-Env-Sender: arnd@arndb.de
X-Msg-Ref: server-4.tower-216.messagelabs.com!1349797201!28169851!1
X-Originating-IP: [212.227.126.187]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xODcgPT4gODI1MTE=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xODcgPT4gODI1MTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1017 invoked from network); 9 Oct 2012 15:40:01 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.126.187)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 15:40:01 -0000
Received: from klappe2.localnet (deibp9eh1--blueice3n2.emea.ibm.com
	[195.212.29.180])
	by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis)
	id 0Mg0KT-1SyjJ81nq1-00NKD9; Tue, 09 Oct 2012 17:39:48 +0200
From: Arnd Bergmann 
To: Ian Campbell 
Date: Tue, 9 Oct 2012 15:39:46 +0000
User-Agent: KMail/1.12.2 (Linux/3.5.0; KDE/4.3.2; x86_64; ; )
References: <1349796183-30648-1-git-send-email-arnd@arndb.de>
	<1349796183-30648-6-git-send-email-arnd@arndb.de>
	<1349796958.21847.219.camel@zakaz.uk.xensource.com>
In-Reply-To: <1349796958.21847.219.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Message-Id: <201210091539.46274.arnd@arndb.de>
X-Provags-ID: V02:K0:ylQy+x6C8LRb8TrpfZWsuR/2ncIEiXNIYup01oRekDA
	0hiMb9q2+PlL3QEfRgTycAeNB0cLZKk0nV2eK1r/NE+UOysiA5
	i1wf7jBOltB6j2RHNx01dUKGuFnk5OJUjjEL8/WmwJ4jj2PvrW
	0LbwsqTCi9egWG7U1Xkx9IzfUIzo0KNiOJXBG7GXF0EcnDUrIR
	bSAxzJGAnOBEArPFdeUREDK1CYvhvaZ6r0xm4ax85Q/exReJfY
	XfmWWnsEuTQ27iuvazUmEoPen1LXf+XSfiJ+TDPxQ/9Kd1FV1k
	eiRu+Vf6w5oaI5AZ8Oy8RUqDQzwxIs0EkQmESJUqOkakQRupl0
	qxyUD262gMytNUOp6j2s=
Cc: Jeremy Fitzhardinge ,
	"xen-devel@lists.xensource.com" ,
	Stefano Stabellini ,
	Konrad Rzeszutek Wilk ,
	"linux-kernel@vger.kernel.org" ,
	Russell King ,
	"linux-arm-kernel@lists.infradead.org"
	
Subject: Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tuesday 09 October 2012, Ian Campbell wrote:
> > * The tmem hypercall is not available on ARM
> > 
> > * ARMv6 does not support cmpxchg on 16-bit words that are used in the
> 
> missing the end of this sentence?

Right, I meant to say 

* ARMv6 does not support cmpxchg on 16-bit words that are used in the
  Xen grant table code, so we must ensure that Xen support is only built
  on ARMv7-only kernels not combined ARMv6/v7 kernels.

This should be fixed differently in the future.

	Arnd

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 15:40:33 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 15:40:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLbue-0002dg-1j; Tue, 09 Oct 2012 15:40:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLbuc-0002dY-DR
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 15:40:02 +0000
Received: from [85.158.143.99:29316] by server-1.bemta-4.messagelabs.com id
	F7/B0-05684-15544705; Tue, 09 Oct 2012 15:40:01 +0000
X-Env-Sender: arnd@arndb.de
X-Msg-Ref: server-4.tower-216.messagelabs.com!1349797201!28169851!1
X-Originating-IP: [212.227.126.187]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xODcgPT4gODI1MTE=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xODcgPT4gODI1MTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1017 invoked from network); 9 Oct 2012 15:40:01 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.126.187)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 15:40:01 -0000
Received: from klappe2.localnet (deibp9eh1--blueice3n2.emea.ibm.com
	[195.212.29.180])
	by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis)
	id 0Mg0KT-1SyjJ81nq1-00NKD9; Tue, 09 Oct 2012 17:39:48 +0200
From: Arnd Bergmann 
To: Ian Campbell 
Date: Tue, 9 Oct 2012 15:39:46 +0000
User-Agent: KMail/1.12.2 (Linux/3.5.0; KDE/4.3.2; x86_64; ; )
References: <1349796183-30648-1-git-send-email-arnd@arndb.de>
	<1349796183-30648-6-git-send-email-arnd@arndb.de>
	<1349796958.21847.219.camel@zakaz.uk.xensource.com>
In-Reply-To: <1349796958.21847.219.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Message-Id: <201210091539.46274.arnd@arndb.de>
X-Provags-ID: V02:K0:ylQy+x6C8LRb8TrpfZWsuR/2ncIEiXNIYup01oRekDA
	0hiMb9q2+PlL3QEfRgTycAeNB0cLZKk0nV2eK1r/NE+UOysiA5
	i1wf7jBOltB6j2RHNx01dUKGuFnk5OJUjjEL8/WmwJ4jj2PvrW
	0LbwsqTCi9egWG7U1Xkx9IzfUIzo0KNiOJXBG7GXF0EcnDUrIR
	bSAxzJGAnOBEArPFdeUREDK1CYvhvaZ6r0xm4ax85Q/exReJfY
	XfmWWnsEuTQ27iuvazUmEoPen1LXf+XSfiJ+TDPxQ/9Kd1FV1k
	eiRu+Vf6w5oaI5AZ8Oy8RUqDQzwxIs0EkQmESJUqOkakQRupl0
	qxyUD262gMytNUOp6j2s=
Cc: Jeremy Fitzhardinge ,
	"xen-devel@lists.xensource.com" ,
	Stefano Stabellini ,
	Konrad Rzeszutek Wilk ,
	"linux-kernel@vger.kernel.org" ,
	Russell King ,
	"linux-arm-kernel@lists.infradead.org"
	
Subject: Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tuesday 09 October 2012, Ian Campbell wrote:
> > * The tmem hypercall is not available on ARM
> > 
> > * ARMv6 does not support cmpxchg on 16-bit words that are used in the
> 
> missing the end of this sentence?

Right, I meant to say 

* ARMv6 does not support cmpxchg on 16-bit words that are used in the
  Xen grant table code, so we must ensure that Xen support is only built
  on ARMv7-only kernels not combined ARMv6/v7 kernels.

This should be fixed differently in the future.

	Arnd

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 15:59:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 15:59:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLcD9-00033W-ES; Tue, 09 Oct 2012 15:59:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLcD7-00033R-6i
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 15:59:09 +0000
Received: from [85.158.139.83:42651] by server-6.bemta-5.messagelabs.com id
	31/B5-14717-CC944705; Tue, 09 Oct 2012 15:59:08 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1349798346!33926658!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12063 invoked from network); 9 Oct 2012 15:59:07 -0000
Received: from mail-ea0-f173.google.com (HELO mail-ea0-f173.google.com)
	(209.85.215.173)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 15:59:07 -0000
Received: by mail-ea0-f173.google.com with SMTP id a1so371618eaa.32
	for ; Tue, 09 Oct 2012 08:59:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=A0VW9B9a2Ff47Rwrt/JaqGnnyT1K0AjEFB7ZX3/xa3Y=;
	b=plhLj40gcGRQBxUOUMrxOOb6tMQtqjn3IJaZzFUa+8dUROJUfdMqs4+ujyLwNq9CF9
	9H6Ans03SQq6w1ZpUPv8if7VL8G+ob0Cisnh2bofXp9jOV/xhDYwfLiJbdj/try1ttEY
	OPCcToTQJUnSeSXx0XC9WhhONjwYTmnoYWzTsM8+Tbpin2Fay/LVV4SJC195gnLTfMZd
	+ypWIFDGWw7TSq9LINdvT7wTbWDmqeZxJKhZQ8lE6tRbR5JV1f1G137Pr6UGk7Pcxl9R
	wcrdZuQFYxJsrgTi0OgCrN1olDw2Jg4c945iPBIfy3u7+2qqYDFvVRYpiQgDlCdIB5lS
	oRJw==
MIME-Version: 1.0
Received: by 10.14.223.199 with SMTP id v47mr1431268eep.45.1349798346784; Tue,
	09 Oct 2012 08:59:06 -0700 (PDT)
Received: by 10.14.215.195 with HTTP; Tue, 9 Oct 2012 08:59:06 -0700 (PDT)
In-Reply-To: 
References: 
	
Date: Tue, 9 Oct 2012 16:59:06 +0100
X-Google-Sender-Auth: HBL51sekv4HHsnbN0P0u-rTpaxo
Message-ID: 
From: George Dunlap 
To: Dario Faggioli 
Cc: Marcus Granado ,
	Andre Przywara ,
	Ian Campbell ,
	Anil Madhavapeddy ,
	Andrew Cooper ,
	Juergen Gross ,
	Ian Jackson , xen-devel@lists.xen.org,
	Jan Beulich , Daniel De Graaf ,
	Matt Wilson 
Subject: Re: [Xen-devel] [PATCH 1 of 8] xen,
	libxc: rename xenctl_cpumap to xenctl_bitmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 5, 2012 at 3:08 PM, Dario Faggioli
 wrote:
> More specifically:
>  1. replaces xenctl_cpumap with xenctl_bitmap
>  2. provides bitmap_to_xenctl_bitmap and the reverse;
>  3. re-implement cpumask_to_xenctl_bitmap with
>     bitmap_to_xenctl_bitmap and the reverse;
>
> Other than #3, no functional changes. Interface only slightly
> afected.
>
> This is in preparation of introducing NUMA node-affinity maps.
>
> Signed-off-by: Dario Faggioli 

Acked-by: George Dunlap 

>
> diff --git a/tools/libxc/xc_cpupool.c b/tools/libxc/xc_cpupool.c
> --- a/tools/libxc/xc_cpupool.c
> +++ b/tools/libxc/xc_cpupool.c
> @@ -90,7 +90,7 @@ xc_cpupoolinfo_t *xc_cpupool_getinfo(xc_
>      sysctl.u.cpupool_op.op = XEN_SYSCTL_CPUPOOL_OP_INFO;
>      sysctl.u.cpupool_op.cpupool_id = poolid;
>      set_xen_guest_handle(sysctl.u.cpupool_op.cpumap.bitmap, local);
> -    sysctl.u.cpupool_op.cpumap.nr_cpus = local_size * 8;
> +    sysctl.u.cpupool_op.cpumap.nr_elems = local_size * 8;
>
>      err = do_sysctl_save(xch, &sysctl);
>
> @@ -184,7 +184,7 @@ xc_cpumap_t xc_cpupool_freeinfo(xc_inter
>      sysctl.cmd = XEN_SYSCTL_cpupool_op;
>      sysctl.u.cpupool_op.op = XEN_SYSCTL_CPUPOOL_OP_FREEINFO;
>      set_xen_guest_handle(sysctl.u.cpupool_op.cpumap.bitmap, local);
> -    sysctl.u.cpupool_op.cpumap.nr_cpus = mapsize * 8;
> +    sysctl.u.cpupool_op.cpumap.nr_elems = mapsize * 8;
>
>      err = do_sysctl_save(xch, &sysctl);
>
> diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
> --- a/tools/libxc/xc_domain.c
> +++ b/tools/libxc/xc_domain.c
> @@ -142,7 +142,7 @@ int xc_vcpu_setaffinity(xc_interface *xc
>
>      set_xen_guest_handle(domctl.u.vcpuaffinity.cpumap.bitmap, local);
>
> -    domctl.u.vcpuaffinity.cpumap.nr_cpus = cpusize * 8;
> +    domctl.u.vcpuaffinity.cpumap.nr_elems = cpusize * 8;
>
>      ret = do_domctl(xch, &domctl);
>
> @@ -182,7 +182,7 @@ int xc_vcpu_getaffinity(xc_interface *xc
>      domctl.u.vcpuaffinity.vcpu = vcpu;
>
>      set_xen_guest_handle(domctl.u.vcpuaffinity.cpumap.bitmap, local);
> -    domctl.u.vcpuaffinity.cpumap.nr_cpus = cpusize * 8;
> +    domctl.u.vcpuaffinity.cpumap.nr_elems = cpusize * 8;
>
>      ret = do_domctl(xch, &domctl);
>
> diff --git a/tools/libxc/xc_tbuf.c b/tools/libxc/xc_tbuf.c
> --- a/tools/libxc/xc_tbuf.c
> +++ b/tools/libxc/xc_tbuf.c
> @@ -134,7 +134,7 @@ int xc_tbuf_set_cpu_mask(xc_interface *x
>      bitmap_64_to_byte(bytemap, &mask64, sizeof (mask64) * 8);
>
>      set_xen_guest_handle(sysctl.u.tbuf_op.cpu_mask.bitmap, bytemap);
> -    sysctl.u.tbuf_op.cpu_mask.nr_cpus = sizeof(bytemap) * 8;
> +    sysctl.u.tbuf_op.cpu_mask.nr_elems = sizeof(bytemap) * 8;
>
>      ret = do_sysctl(xch, &sysctl);
>
> diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
> --- a/xen/arch/x86/cpu/mcheck/mce.c
> +++ b/xen/arch/x86/cpu/mcheck/mce.c
> @@ -1474,8 +1474,7 @@ long do_mca(XEN_GUEST_HANDLE(xen_mc_t) u
>              cpumap = &cpu_online_map;
>          else
>          {
> -            ret = xenctl_cpumap_to_cpumask(&cmv,
> -                                           &op->u.mc_inject_v2.cpumap);
> +            ret = xenctl_bitmap_to_cpumask(&cmv, &op->u.mc_inject_v2.cpumap);
>              if ( ret )
>                  break;
>              cpumap = cmv;
> diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hypercall.c
> --- a/xen/arch/x86/platform_hypercall.c
> +++ b/xen/arch/x86/platform_hypercall.c
> @@ -371,7 +371,7 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
>      {
>          uint32_t cpu;
>          uint64_t idletime, now = NOW();
> -        struct xenctl_cpumap ctlmap;
> +        struct xenctl_bitmap ctlmap;
>          cpumask_var_t cpumap;
>          XEN_GUEST_HANDLE(uint8) cpumap_bitmap;
>          XEN_GUEST_HANDLE(uint64) idletimes;
> @@ -384,11 +384,11 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
>          if ( cpufreq_controller != FREQCTL_dom0_kernel )
>              break;
>
> -        ctlmap.nr_cpus  = op->u.getidletime.cpumap_nr_cpus;
> +        ctlmap.nr_elems  = op->u.getidletime.cpumap_nr_cpus;
>          guest_from_compat_handle(cpumap_bitmap,
>                                   op->u.getidletime.cpumap_bitmap);
>          ctlmap.bitmap.p = cpumap_bitmap.p; /* handle -> handle_64 conversion */
> -        if ( (ret = xenctl_cpumap_to_cpumask(&cpumap, &ctlmap)) != 0 )
> +        if ( (ret = xenctl_bitmap_to_cpumask(&cpumap, &ctlmap)) != 0 )
>              goto out;
>          guest_from_compat_handle(idletimes, op->u.getidletime.idletime);
>
> @@ -407,7 +407,7 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
>
>          op->u.getidletime.now = now;
>          if ( ret == 0 )
> -            ret = cpumask_to_xenctl_cpumap(&ctlmap, cpumap);
> +            ret = cpumask_to_xenctl_bitmap(&ctlmap, cpumap);
>          free_cpumask_var(cpumap);
>
>          if ( ret == 0 && copy_to_guest(u_xenpf_op, op, 1) )
> diff --git a/xen/common/cpupool.c b/xen/common/cpupool.c
> --- a/xen/common/cpupool.c
> +++ b/xen/common/cpupool.c
> @@ -493,7 +493,7 @@ int cpupool_do_sysctl(struct xen_sysctl_
>          op->cpupool_id = c->cpupool_id;
>          op->sched_id = c->sched->sched_id;
>          op->n_dom = c->n_dom;
> -        ret = cpumask_to_xenctl_cpumap(&op->cpumap, c->cpu_valid);
> +        ret = cpumask_to_xenctl_bitmap(&op->cpumap, c->cpu_valid);
>          cpupool_put(c);
>      }
>      break;
> @@ -588,7 +588,7 @@ int cpupool_do_sysctl(struct xen_sysctl_
>
>      case XEN_SYSCTL_CPUPOOL_OP_FREEINFO:
>      {
> -        ret = cpumask_to_xenctl_cpumap(
> +        ret = cpumask_to_xenctl_bitmap(
>              &op->cpumap, &cpupool_free_cpus);
>      }
>      break;
> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -32,28 +32,29 @@
>  static DEFINE_SPINLOCK(domctl_lock);
>  DEFINE_SPINLOCK(vcpu_alloc_lock);
>
> -int cpumask_to_xenctl_cpumap(
> -    struct xenctl_cpumap *xenctl_cpumap, const cpumask_t *cpumask)
> +int bitmap_to_xenctl_bitmap(struct xenctl_bitmap *xenctl_bitmap,
> +                            const unsigned long *bitmap,
> +                            unsigned int nbits)
>  {
>      unsigned int guest_bytes, copy_bytes, i;
>      uint8_t zero = 0;
>      int err = 0;
> -    uint8_t *bytemap = xmalloc_array(uint8_t, (nr_cpu_ids + 7) / 8);
> +    uint8_t *bytemap = xmalloc_array(uint8_t, (nbits + 7) / 8);
>
>      if ( !bytemap )
>          return -ENOMEM;
>
> -    guest_bytes = (xenctl_cpumap->nr_cpus + 7) / 8;
> -    copy_bytes  = min_t(unsigned int, guest_bytes, (nr_cpu_ids + 7) / 8);
> +    guest_bytes = (xenctl_bitmap->nr_elems + 7) / 8;
> +    copy_bytes  = min_t(unsigned int, guest_bytes, (nbits + 7) / 8);
>
> -    bitmap_long_to_byte(bytemap, cpumask_bits(cpumask), nr_cpu_ids);
> +    bitmap_long_to_byte(bytemap, bitmap, nbits);
>
>      if ( copy_bytes != 0 )
> -        if ( copy_to_guest(xenctl_cpumap->bitmap, bytemap, copy_bytes) )
> +        if ( copy_to_guest(xenctl_bitmap->bitmap, bytemap, copy_bytes) )
>              err = -EFAULT;
>
>      for ( i = copy_bytes; !err && i < guest_bytes; i++ )
> -        if ( copy_to_guest_offset(xenctl_cpumap->bitmap, i, &zero, 1) )
> +        if ( copy_to_guest_offset(xenctl_bitmap->bitmap, i, &zero, 1) )
>              err = -EFAULT;
>
>      xfree(bytemap);
> @@ -61,36 +62,59 @@ int cpumask_to_xenctl_cpumap(
>      return err;
>  }
>
> -int xenctl_cpumap_to_cpumask(
> -    cpumask_var_t *cpumask, const struct xenctl_cpumap *xenctl_cpumap)
> +int xenctl_bitmap_to_bitmap(unsigned long *bitmap,
> +                            const struct xenctl_bitmap *xenctl_bitmap,
> +                            unsigned int nbits)
>  {
>      unsigned int guest_bytes, copy_bytes;
>      int err = 0;
> -    uint8_t *bytemap = xzalloc_array(uint8_t, (nr_cpu_ids + 7) / 8);
> +    uint8_t *bytemap = xzalloc_array(uint8_t, (nbits + 7) / 8);
>
>      if ( !bytemap )
>          return -ENOMEM;
>
> -    guest_bytes = (xenctl_cpumap->nr_cpus + 7) / 8;
> -    copy_bytes  = min_t(unsigned int, guest_bytes, (nr_cpu_ids + 7) / 8);
> +    guest_bytes = (xenctl_bitmap->nr_elems + 7) / 8;
> +    copy_bytes  = min_t(unsigned int, guest_bytes, (nbits + 7) / 8);
>
>      if ( copy_bytes != 0 )
>      {
> -        if ( copy_from_guest(bytemap, xenctl_cpumap->bitmap, copy_bytes) )
> +        if ( copy_from_guest(bytemap, xenctl_bitmap->bitmap, copy_bytes) )
>              err = -EFAULT;
> -        if ( (xenctl_cpumap->nr_cpus & 7) && (guest_bytes <= sizeof(bytemap)) )
> -            bytemap[guest_bytes-1] &= ~(0xff << (xenctl_cpumap->nr_cpus & 7));
> +        if ( (xenctl_bitmap->nr_elems & 7) &&
> +             (guest_bytes <= sizeof(bytemap)) )
> +            bytemap[guest_bytes-1] &= ~(0xff << (xenctl_bitmap->nr_elems & 7));
>      }
>
> -    if ( err )
> -        /* nothing */;
> -    else if ( alloc_cpumask_var(cpumask) )
> -        bitmap_byte_to_long(cpumask_bits(*cpumask), bytemap, nr_cpu_ids);
> +    if ( !err )
> +        bitmap_byte_to_long(bitmap, bytemap, nbits);
> +
> +    xfree(bytemap);
> +
> +    return err;
> +}
> +
> +int cpumask_to_xenctl_bitmap(struct xenctl_bitmap *xenctl_cpumap,
> +                             const cpumask_t *cpumask)
> +{
> +    return bitmap_to_xenctl_bitmap(xenctl_cpumap, cpumask_bits(cpumask),
> +                                   nr_cpu_ids);
> +}
> +
> +int xenctl_bitmap_to_cpumask(cpumask_var_t *cpumask,
> +                             const struct xenctl_bitmap *xenctl_cpumap)
> +{
> +    int err = 0;
> +
> +    if ( alloc_cpumask_var(cpumask) ) {
> +        err = xenctl_bitmap_to_bitmap(cpumask_bits(*cpumask), xenctl_cpumap,
> +                                      nr_cpu_ids);
> +        /* In case of error, cleanup is up to us, as the caller won't care! */
> +        if ( err )
> +            free_cpumask_var(*cpumask);
> +    }
>      else
>          err = -ENOMEM;
>
> -    xfree(bytemap);
> -
>      return err;
>  }
>
> @@ -621,7 +645,7 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
>          {
>              cpumask_var_t new_affinity;
>
> -            ret = xenctl_cpumap_to_cpumask(
> +            ret = xenctl_bitmap_to_cpumask(
>                  &new_affinity, &op->u.vcpuaffinity.cpumap);
>              if ( !ret )
>              {
> @@ -631,7 +655,7 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
>          }
>          else
>          {
> -            ret = cpumask_to_xenctl_cpumap(
> +            ret = cpumask_to_xenctl_bitmap(
>                  &op->u.vcpuaffinity.cpumap, v->cpu_affinity);
>          }
>
> diff --git a/xen/common/trace.c b/xen/common/trace.c
> --- a/xen/common/trace.c
> +++ b/xen/common/trace.c
> @@ -384,7 +384,7 @@ int tb_control(xen_sysctl_tbuf_op_t *tbc
>      {
>          cpumask_var_t mask;
>
> -        rc = xenctl_cpumap_to_cpumask(&mask, &tbc->cpu_mask);
> +        rc = xenctl_bitmap_to_cpumask(&mask, &tbc->cpu_mask);
>          if ( !rc )
>          {
>              cpumask_copy(&tb_cpu_mask, mask);
> diff --git a/xen/include/public/arch-x86/xen-mca.h b/xen/include/public/arch-x86/xen-mca.h
> --- a/xen/include/public/arch-x86/xen-mca.h
> +++ b/xen/include/public/arch-x86/xen-mca.h
> @@ -414,7 +414,7 @@ struct xen_mc_mceinject {
>
>  struct xen_mc_inject_v2 {
>         uint32_t flags;
> -       struct xenctl_cpumap cpumap;
> +       struct xenctl_bitmap cpumap;
>  };
>  #endif
>
> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -284,7 +284,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_getvc
>  /* XEN_DOMCTL_getvcpuaffinity */
>  struct xen_domctl_vcpuaffinity {
>      uint32_t  vcpu;              /* IN */
> -    struct xenctl_cpumap cpumap; /* IN/OUT */
> +    struct xenctl_bitmap cpumap; /* IN/OUT */
>  };
>  typedef struct xen_domctl_vcpuaffinity xen_domctl_vcpuaffinity_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_domctl_vcpuaffinity_t);
> diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
> --- a/xen/include/public/sysctl.h
> +++ b/xen/include/public/sysctl.h
> @@ -71,7 +71,7 @@ struct xen_sysctl_tbuf_op {
>  #define XEN_SYSCTL_TBUFOP_disable      5
>      uint32_t cmd;
>      /* IN/OUT variables */
> -    struct xenctl_cpumap cpu_mask;
> +    struct xenctl_bitmap cpu_mask;
>      uint32_t             evt_mask;
>      /* OUT variables */
>      uint64_aligned_t buffer_mfn;
> @@ -532,7 +532,7 @@ struct xen_sysctl_cpupool_op {
>      uint32_t domid;       /* IN: M              */
>      uint32_t cpu;         /* IN: AR             */
>      uint32_t n_dom;       /*            OUT: I  */
> -    struct xenctl_cpumap cpumap; /*     OUT: IF */
> +    struct xenctl_bitmap cpumap; /*     OUT: IF */
>  };
>  typedef struct xen_sysctl_cpupool_op xen_sysctl_cpupool_op_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_sysctl_cpupool_op_t);
> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -820,9 +820,9 @@ typedef uint8_t xen_domain_handle_t[16];
>  #endif
>
>  #ifndef __ASSEMBLY__
> -struct xenctl_cpumap {
> +struct xenctl_bitmap {
>      XEN_GUEST_HANDLE_64(uint8) bitmap;
> -    uint32_t nr_cpus;
> +    uint32_t nr_elems;
>  };
>  #endif
>
> diff --git a/xen/include/xen/cpumask.h b/xen/include/xen/cpumask.h
> --- a/xen/include/xen/cpumask.h
> +++ b/xen/include/xen/cpumask.h
> @@ -424,8 +424,8 @@ extern cpumask_t cpu_present_map;
>  #define for_each_present_cpu(cpu)  for_each_cpu(cpu, &cpu_present_map)
>
>  /* Copy to/from cpumap provided by control tools. */
> -struct xenctl_cpumap;
> -int cpumask_to_xenctl_cpumap(struct xenctl_cpumap *, const cpumask_t *);
> -int xenctl_cpumap_to_cpumask(cpumask_var_t *, const struct xenctl_cpumap *);
> +struct xenctl_bitmap;
> +int cpumask_to_xenctl_bitmap(struct xenctl_bitmap *, const cpumask_t *);
> +int xenctl_bitmap_to_cpumask(cpumask_var_t *, const struct xenctl_bitmap *);
>
>  #endif /* __XEN_CPUMASK_H */
> diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
> --- a/xen/include/xlat.lst
> +++ b/xen/include/xlat.lst
> @@ -2,7 +2,7 @@
>  # ! - needs translation
>  # ? - needs checking
>  ?      dom0_vga_console_info           xen.h
> -?      xenctl_cpumap                   xen.h
> +?      xenctl_bitmap                   xen.h
>  ?      mmu_update                      xen.h
>  !      mmuext_op                       xen.h
>  !      start_info                      xen.h
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 15:59:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 15:59:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLcD9-00033W-ES; Tue, 09 Oct 2012 15:59:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLcD7-00033R-6i
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 15:59:09 +0000
Received: from [85.158.139.83:42651] by server-6.bemta-5.messagelabs.com id
	31/B5-14717-CC944705; Tue, 09 Oct 2012 15:59:08 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1349798346!33926658!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12063 invoked from network); 9 Oct 2012 15:59:07 -0000
Received: from mail-ea0-f173.google.com (HELO mail-ea0-f173.google.com)
	(209.85.215.173)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 15:59:07 -0000
Received: by mail-ea0-f173.google.com with SMTP id a1so371618eaa.32
	for ; Tue, 09 Oct 2012 08:59:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=A0VW9B9a2Ff47Rwrt/JaqGnnyT1K0AjEFB7ZX3/xa3Y=;
	b=plhLj40gcGRQBxUOUMrxOOb6tMQtqjn3IJaZzFUa+8dUROJUfdMqs4+ujyLwNq9CF9
	9H6Ans03SQq6w1ZpUPv8if7VL8G+ob0Cisnh2bofXp9jOV/xhDYwfLiJbdj/try1ttEY
	OPCcToTQJUnSeSXx0XC9WhhONjwYTmnoYWzTsM8+Tbpin2Fay/LVV4SJC195gnLTfMZd
	+ypWIFDGWw7TSq9LINdvT7wTbWDmqeZxJKhZQ8lE6tRbR5JV1f1G137Pr6UGk7Pcxl9R
	wcrdZuQFYxJsrgTi0OgCrN1olDw2Jg4c945iPBIfy3u7+2qqYDFvVRYpiQgDlCdIB5lS
	oRJw==
MIME-Version: 1.0
Received: by 10.14.223.199 with SMTP id v47mr1431268eep.45.1349798346784; Tue,
	09 Oct 2012 08:59:06 -0700 (PDT)
Received: by 10.14.215.195 with HTTP; Tue, 9 Oct 2012 08:59:06 -0700 (PDT)
In-Reply-To: 
References: 
	
Date: Tue, 9 Oct 2012 16:59:06 +0100
X-Google-Sender-Auth: HBL51sekv4HHsnbN0P0u-rTpaxo
Message-ID: 
From: George Dunlap 
To: Dario Faggioli 
Cc: Marcus Granado ,
	Andre Przywara ,
	Ian Campbell ,
	Anil Madhavapeddy ,
	Andrew Cooper ,
	Juergen Gross ,
	Ian Jackson , xen-devel@lists.xen.org,
	Jan Beulich , Daniel De Graaf ,
	Matt Wilson 
Subject: Re: [Xen-devel] [PATCH 1 of 8] xen,
	libxc: rename xenctl_cpumap to xenctl_bitmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 5, 2012 at 3:08 PM, Dario Faggioli
 wrote:
> More specifically:
>  1. replaces xenctl_cpumap with xenctl_bitmap
>  2. provides bitmap_to_xenctl_bitmap and the reverse;
>  3. re-implement cpumask_to_xenctl_bitmap with
>     bitmap_to_xenctl_bitmap and the reverse;
>
> Other than #3, no functional changes. Interface only slightly
> afected.
>
> This is in preparation of introducing NUMA node-affinity maps.
>
> Signed-off-by: Dario Faggioli 

Acked-by: George Dunlap 

>
> diff --git a/tools/libxc/xc_cpupool.c b/tools/libxc/xc_cpupool.c
> --- a/tools/libxc/xc_cpupool.c
> +++ b/tools/libxc/xc_cpupool.c
> @@ -90,7 +90,7 @@ xc_cpupoolinfo_t *xc_cpupool_getinfo(xc_
>      sysctl.u.cpupool_op.op = XEN_SYSCTL_CPUPOOL_OP_INFO;
>      sysctl.u.cpupool_op.cpupool_id = poolid;
>      set_xen_guest_handle(sysctl.u.cpupool_op.cpumap.bitmap, local);
> -    sysctl.u.cpupool_op.cpumap.nr_cpus = local_size * 8;
> +    sysctl.u.cpupool_op.cpumap.nr_elems = local_size * 8;
>
>      err = do_sysctl_save(xch, &sysctl);
>
> @@ -184,7 +184,7 @@ xc_cpumap_t xc_cpupool_freeinfo(xc_inter
>      sysctl.cmd = XEN_SYSCTL_cpupool_op;
>      sysctl.u.cpupool_op.op = XEN_SYSCTL_CPUPOOL_OP_FREEINFO;
>      set_xen_guest_handle(sysctl.u.cpupool_op.cpumap.bitmap, local);
> -    sysctl.u.cpupool_op.cpumap.nr_cpus = mapsize * 8;
> +    sysctl.u.cpupool_op.cpumap.nr_elems = mapsize * 8;
>
>      err = do_sysctl_save(xch, &sysctl);
>
> diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
> --- a/tools/libxc/xc_domain.c
> +++ b/tools/libxc/xc_domain.c
> @@ -142,7 +142,7 @@ int xc_vcpu_setaffinity(xc_interface *xc
>
>      set_xen_guest_handle(domctl.u.vcpuaffinity.cpumap.bitmap, local);
>
> -    domctl.u.vcpuaffinity.cpumap.nr_cpus = cpusize * 8;
> +    domctl.u.vcpuaffinity.cpumap.nr_elems = cpusize * 8;
>
>      ret = do_domctl(xch, &domctl);
>
> @@ -182,7 +182,7 @@ int xc_vcpu_getaffinity(xc_interface *xc
>      domctl.u.vcpuaffinity.vcpu = vcpu;
>
>      set_xen_guest_handle(domctl.u.vcpuaffinity.cpumap.bitmap, local);
> -    domctl.u.vcpuaffinity.cpumap.nr_cpus = cpusize * 8;
> +    domctl.u.vcpuaffinity.cpumap.nr_elems = cpusize * 8;
>
>      ret = do_domctl(xch, &domctl);
>
> diff --git a/tools/libxc/xc_tbuf.c b/tools/libxc/xc_tbuf.c
> --- a/tools/libxc/xc_tbuf.c
> +++ b/tools/libxc/xc_tbuf.c
> @@ -134,7 +134,7 @@ int xc_tbuf_set_cpu_mask(xc_interface *x
>      bitmap_64_to_byte(bytemap, &mask64, sizeof (mask64) * 8);
>
>      set_xen_guest_handle(sysctl.u.tbuf_op.cpu_mask.bitmap, bytemap);
> -    sysctl.u.tbuf_op.cpu_mask.nr_cpus = sizeof(bytemap) * 8;
> +    sysctl.u.tbuf_op.cpu_mask.nr_elems = sizeof(bytemap) * 8;
>
>      ret = do_sysctl(xch, &sysctl);
>
> diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
> --- a/xen/arch/x86/cpu/mcheck/mce.c
> +++ b/xen/arch/x86/cpu/mcheck/mce.c
> @@ -1474,8 +1474,7 @@ long do_mca(XEN_GUEST_HANDLE(xen_mc_t) u
>              cpumap = &cpu_online_map;
>          else
>          {
> -            ret = xenctl_cpumap_to_cpumask(&cmv,
> -                                           &op->u.mc_inject_v2.cpumap);
> +            ret = xenctl_bitmap_to_cpumask(&cmv, &op->u.mc_inject_v2.cpumap);
>              if ( ret )
>                  break;
>              cpumap = cmv;
> diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hypercall.c
> --- a/xen/arch/x86/platform_hypercall.c
> +++ b/xen/arch/x86/platform_hypercall.c
> @@ -371,7 +371,7 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
>      {
>          uint32_t cpu;
>          uint64_t idletime, now = NOW();
> -        struct xenctl_cpumap ctlmap;
> +        struct xenctl_bitmap ctlmap;
>          cpumask_var_t cpumap;
>          XEN_GUEST_HANDLE(uint8) cpumap_bitmap;
>          XEN_GUEST_HANDLE(uint64) idletimes;
> @@ -384,11 +384,11 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
>          if ( cpufreq_controller != FREQCTL_dom0_kernel )
>              break;
>
> -        ctlmap.nr_cpus  = op->u.getidletime.cpumap_nr_cpus;
> +        ctlmap.nr_elems  = op->u.getidletime.cpumap_nr_cpus;
>          guest_from_compat_handle(cpumap_bitmap,
>                                   op->u.getidletime.cpumap_bitmap);
>          ctlmap.bitmap.p = cpumap_bitmap.p; /* handle -> handle_64 conversion */
> -        if ( (ret = xenctl_cpumap_to_cpumask(&cpumap, &ctlmap)) != 0 )
> +        if ( (ret = xenctl_bitmap_to_cpumask(&cpumap, &ctlmap)) != 0 )
>              goto out;
>          guest_from_compat_handle(idletimes, op->u.getidletime.idletime);
>
> @@ -407,7 +407,7 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
>
>          op->u.getidletime.now = now;
>          if ( ret == 0 )
> -            ret = cpumask_to_xenctl_cpumap(&ctlmap, cpumap);
> +            ret = cpumask_to_xenctl_bitmap(&ctlmap, cpumap);
>          free_cpumask_var(cpumap);
>
>          if ( ret == 0 && copy_to_guest(u_xenpf_op, op, 1) )
> diff --git a/xen/common/cpupool.c b/xen/common/cpupool.c
> --- a/xen/common/cpupool.c
> +++ b/xen/common/cpupool.c
> @@ -493,7 +493,7 @@ int cpupool_do_sysctl(struct xen_sysctl_
>          op->cpupool_id = c->cpupool_id;
>          op->sched_id = c->sched->sched_id;
>          op->n_dom = c->n_dom;
> -        ret = cpumask_to_xenctl_cpumap(&op->cpumap, c->cpu_valid);
> +        ret = cpumask_to_xenctl_bitmap(&op->cpumap, c->cpu_valid);
>          cpupool_put(c);
>      }
>      break;
> @@ -588,7 +588,7 @@ int cpupool_do_sysctl(struct xen_sysctl_
>
>      case XEN_SYSCTL_CPUPOOL_OP_FREEINFO:
>      {
> -        ret = cpumask_to_xenctl_cpumap(
> +        ret = cpumask_to_xenctl_bitmap(
>              &op->cpumap, &cpupool_free_cpus);
>      }
>      break;
> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -32,28 +32,29 @@
>  static DEFINE_SPINLOCK(domctl_lock);
>  DEFINE_SPINLOCK(vcpu_alloc_lock);
>
> -int cpumask_to_xenctl_cpumap(
> -    struct xenctl_cpumap *xenctl_cpumap, const cpumask_t *cpumask)
> +int bitmap_to_xenctl_bitmap(struct xenctl_bitmap *xenctl_bitmap,
> +                            const unsigned long *bitmap,
> +                            unsigned int nbits)
>  {
>      unsigned int guest_bytes, copy_bytes, i;
>      uint8_t zero = 0;
>      int err = 0;
> -    uint8_t *bytemap = xmalloc_array(uint8_t, (nr_cpu_ids + 7) / 8);
> +    uint8_t *bytemap = xmalloc_array(uint8_t, (nbits + 7) / 8);
>
>      if ( !bytemap )
>          return -ENOMEM;
>
> -    guest_bytes = (xenctl_cpumap->nr_cpus + 7) / 8;
> -    copy_bytes  = min_t(unsigned int, guest_bytes, (nr_cpu_ids + 7) / 8);
> +    guest_bytes = (xenctl_bitmap->nr_elems + 7) / 8;
> +    copy_bytes  = min_t(unsigned int, guest_bytes, (nbits + 7) / 8);
>
> -    bitmap_long_to_byte(bytemap, cpumask_bits(cpumask), nr_cpu_ids);
> +    bitmap_long_to_byte(bytemap, bitmap, nbits);
>
>      if ( copy_bytes != 0 )
> -        if ( copy_to_guest(xenctl_cpumap->bitmap, bytemap, copy_bytes) )
> +        if ( copy_to_guest(xenctl_bitmap->bitmap, bytemap, copy_bytes) )
>              err = -EFAULT;
>
>      for ( i = copy_bytes; !err && i < guest_bytes; i++ )
> -        if ( copy_to_guest_offset(xenctl_cpumap->bitmap, i, &zero, 1) )
> +        if ( copy_to_guest_offset(xenctl_bitmap->bitmap, i, &zero, 1) )
>              err = -EFAULT;
>
>      xfree(bytemap);
> @@ -61,36 +62,59 @@ int cpumask_to_xenctl_cpumap(
>      return err;
>  }
>
> -int xenctl_cpumap_to_cpumask(
> -    cpumask_var_t *cpumask, const struct xenctl_cpumap *xenctl_cpumap)
> +int xenctl_bitmap_to_bitmap(unsigned long *bitmap,
> +                            const struct xenctl_bitmap *xenctl_bitmap,
> +                            unsigned int nbits)
>  {
>      unsigned int guest_bytes, copy_bytes;
>      int err = 0;
> -    uint8_t *bytemap = xzalloc_array(uint8_t, (nr_cpu_ids + 7) / 8);
> +    uint8_t *bytemap = xzalloc_array(uint8_t, (nbits + 7) / 8);
>
>      if ( !bytemap )
>          return -ENOMEM;
>
> -    guest_bytes = (xenctl_cpumap->nr_cpus + 7) / 8;
> -    copy_bytes  = min_t(unsigned int, guest_bytes, (nr_cpu_ids + 7) / 8);
> +    guest_bytes = (xenctl_bitmap->nr_elems + 7) / 8;
> +    copy_bytes  = min_t(unsigned int, guest_bytes, (nbits + 7) / 8);
>
>      if ( copy_bytes != 0 )
>      {
> -        if ( copy_from_guest(bytemap, xenctl_cpumap->bitmap, copy_bytes) )
> +        if ( copy_from_guest(bytemap, xenctl_bitmap->bitmap, copy_bytes) )
>              err = -EFAULT;
> -        if ( (xenctl_cpumap->nr_cpus & 7) && (guest_bytes <= sizeof(bytemap)) )
> -            bytemap[guest_bytes-1] &= ~(0xff << (xenctl_cpumap->nr_cpus & 7));
> +        if ( (xenctl_bitmap->nr_elems & 7) &&
> +             (guest_bytes <= sizeof(bytemap)) )
> +            bytemap[guest_bytes-1] &= ~(0xff << (xenctl_bitmap->nr_elems & 7));
>      }
>
> -    if ( err )
> -        /* nothing */;
> -    else if ( alloc_cpumask_var(cpumask) )
> -        bitmap_byte_to_long(cpumask_bits(*cpumask), bytemap, nr_cpu_ids);
> +    if ( !err )
> +        bitmap_byte_to_long(bitmap, bytemap, nbits);
> +
> +    xfree(bytemap);
> +
> +    return err;
> +}
> +
> +int cpumask_to_xenctl_bitmap(struct xenctl_bitmap *xenctl_cpumap,
> +                             const cpumask_t *cpumask)
> +{
> +    return bitmap_to_xenctl_bitmap(xenctl_cpumap, cpumask_bits(cpumask),
> +                                   nr_cpu_ids);
> +}
> +
> +int xenctl_bitmap_to_cpumask(cpumask_var_t *cpumask,
> +                             const struct xenctl_bitmap *xenctl_cpumap)
> +{
> +    int err = 0;
> +
> +    if ( alloc_cpumask_var(cpumask) ) {
> +        err = xenctl_bitmap_to_bitmap(cpumask_bits(*cpumask), xenctl_cpumap,
> +                                      nr_cpu_ids);
> +        /* In case of error, cleanup is up to us, as the caller won't care! */
> +        if ( err )
> +            free_cpumask_var(*cpumask);
> +    }
>      else
>          err = -ENOMEM;
>
> -    xfree(bytemap);
> -
>      return err;
>  }
>
> @@ -621,7 +645,7 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
>          {
>              cpumask_var_t new_affinity;
>
> -            ret = xenctl_cpumap_to_cpumask(
> +            ret = xenctl_bitmap_to_cpumask(
>                  &new_affinity, &op->u.vcpuaffinity.cpumap);
>              if ( !ret )
>              {
> @@ -631,7 +655,7 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
>          }
>          else
>          {
> -            ret = cpumask_to_xenctl_cpumap(
> +            ret = cpumask_to_xenctl_bitmap(
>                  &op->u.vcpuaffinity.cpumap, v->cpu_affinity);
>          }
>
> diff --git a/xen/common/trace.c b/xen/common/trace.c
> --- a/xen/common/trace.c
> +++ b/xen/common/trace.c
> @@ -384,7 +384,7 @@ int tb_control(xen_sysctl_tbuf_op_t *tbc
>      {
>          cpumask_var_t mask;
>
> -        rc = xenctl_cpumap_to_cpumask(&mask, &tbc->cpu_mask);
> +        rc = xenctl_bitmap_to_cpumask(&mask, &tbc->cpu_mask);
>          if ( !rc )
>          {
>              cpumask_copy(&tb_cpu_mask, mask);
> diff --git a/xen/include/public/arch-x86/xen-mca.h b/xen/include/public/arch-x86/xen-mca.h
> --- a/xen/include/public/arch-x86/xen-mca.h
> +++ b/xen/include/public/arch-x86/xen-mca.h
> @@ -414,7 +414,7 @@ struct xen_mc_mceinject {
>
>  struct xen_mc_inject_v2 {
>         uint32_t flags;
> -       struct xenctl_cpumap cpumap;
> +       struct xenctl_bitmap cpumap;
>  };
>  #endif
>
> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -284,7 +284,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_getvc
>  /* XEN_DOMCTL_getvcpuaffinity */
>  struct xen_domctl_vcpuaffinity {
>      uint32_t  vcpu;              /* IN */
> -    struct xenctl_cpumap cpumap; /* IN/OUT */
> +    struct xenctl_bitmap cpumap; /* IN/OUT */
>  };
>  typedef struct xen_domctl_vcpuaffinity xen_domctl_vcpuaffinity_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_domctl_vcpuaffinity_t);
> diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
> --- a/xen/include/public/sysctl.h
> +++ b/xen/include/public/sysctl.h
> @@ -71,7 +71,7 @@ struct xen_sysctl_tbuf_op {
>  #define XEN_SYSCTL_TBUFOP_disable      5
>      uint32_t cmd;
>      /* IN/OUT variables */
> -    struct xenctl_cpumap cpu_mask;
> +    struct xenctl_bitmap cpu_mask;
>      uint32_t             evt_mask;
>      /* OUT variables */
>      uint64_aligned_t buffer_mfn;
> @@ -532,7 +532,7 @@ struct xen_sysctl_cpupool_op {
>      uint32_t domid;       /* IN: M              */
>      uint32_t cpu;         /* IN: AR             */
>      uint32_t n_dom;       /*            OUT: I  */
> -    struct xenctl_cpumap cpumap; /*     OUT: IF */
> +    struct xenctl_bitmap cpumap; /*     OUT: IF */
>  };
>  typedef struct xen_sysctl_cpupool_op xen_sysctl_cpupool_op_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_sysctl_cpupool_op_t);
> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -820,9 +820,9 @@ typedef uint8_t xen_domain_handle_t[16];
>  #endif
>
>  #ifndef __ASSEMBLY__
> -struct xenctl_cpumap {
> +struct xenctl_bitmap {
>      XEN_GUEST_HANDLE_64(uint8) bitmap;
> -    uint32_t nr_cpus;
> +    uint32_t nr_elems;
>  };
>  #endif
>
> diff --git a/xen/include/xen/cpumask.h b/xen/include/xen/cpumask.h
> --- a/xen/include/xen/cpumask.h
> +++ b/xen/include/xen/cpumask.h
> @@ -424,8 +424,8 @@ extern cpumask_t cpu_present_map;
>  #define for_each_present_cpu(cpu)  for_each_cpu(cpu, &cpu_present_map)
>
>  /* Copy to/from cpumap provided by control tools. */
> -struct xenctl_cpumap;
> -int cpumask_to_xenctl_cpumap(struct xenctl_cpumap *, const cpumask_t *);
> -int xenctl_cpumap_to_cpumask(cpumask_var_t *, const struct xenctl_cpumap *);
> +struct xenctl_bitmap;
> +int cpumask_to_xenctl_bitmap(struct xenctl_bitmap *, const cpumask_t *);
> +int xenctl_bitmap_to_cpumask(cpumask_var_t *, const struct xenctl_bitmap *);
>
>  #endif /* __XEN_CPUMASK_H */
> diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
> --- a/xen/include/xlat.lst
> +++ b/xen/include/xlat.lst
> @@ -2,7 +2,7 @@
>  # ! - needs translation
>  # ? - needs checking
>  ?      dom0_vga_console_info           xen.h
> -?      xenctl_cpumap                   xen.h
> +?      xenctl_bitmap                   xen.h
>  ?      mmu_update                      xen.h
>  !      mmuext_op                       xen.h
>  !      start_info                      xen.h
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 16:00:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 16:00:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLcDc-00035s-Vx; Tue, 09 Oct 2012 15:59:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLcDb-00035f-TB
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 15:59:40 +0000
Received: from [85.158.143.99:59099] by server-3.bemta-4.messagelabs.com id
	FB/72-10986-BE944705; Tue, 09 Oct 2012 15:59:39 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1349798378!33497995!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29728 invoked from network); 9 Oct 2012 15:59:38 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 15:59:38 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so3904517eek.32
	for ; Tue, 09 Oct 2012 08:59:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=Pgu/7tPvtLjoN8KQE2iMAHOcjnaOz/Chu7jQ13WcY3s=;
	b=1JKHFnQfSXxW2+gFV6Ah9KDdb/4QrPhMtqEldfukh3X9M0X5aScwDpmtaAvQ3Sb+/4
	d5A+X9CuWSvYhofhhr1iCO/8n31NdLvSp2QyfiTVomHEJ9wpa425dccc22e9nUuvZnQr
	zR3gvMywcwG1cDZbV05zKaKBhwFjOwGgxX5Dlh0npGeDOwBcP2cjR8B6cu8sjbXhWYja
	06EKxQyF0THQJ8jPpPz5iSBKs8HFkW/CYiFCFUL94Uu7AAp77eih6aMfBOCcpCg/lzSS
	CbjppS3SP7MNZi3JrrG6wV8tlWCKCVzFV4H9T6Nymrku+NKR0Czuvesv/BqxI4IGw90O
	47Qw==
MIME-Version: 1.0
Received: by 10.14.4.201 with SMTP id 49mr28299297eej.0.1349798378233; Tue, 09
	Oct 2012 08:59:38 -0700 (PDT)
Received: by 10.14.215.195 with HTTP; Tue, 9 Oct 2012 08:59:38 -0700 (PDT)
In-Reply-To: <9e7d4c414d9566832d52.1349446100@Solace>
References: 
	<9e7d4c414d9566832d52.1349446100@Solace>
Date: Tue, 9 Oct 2012 16:59:38 +0100
X-Google-Sender-Auth: Ghl69S3xTRuGUkTzjKREAXFN0Xg
Message-ID: 
From: George Dunlap 
To: Dario Faggioli 
Cc: Marcus Granado ,
	Andre Przywara ,
	Ian Campbell ,
	Anil Madhavapeddy ,
	Andrew Cooper ,
	Juergen Gross ,
	Ian Jackson , xen-devel@lists.xen.org,
	Jan Beulich , Daniel De Graaf ,
	Matt Wilson 
Subject: Re: [Xen-devel] [PATCH 2 of 8] xen,
	libxc: introduce node maps and masks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 5, 2012 at 3:08 PM, Dario Faggioli
 wrote:
> Following suit from cpumap and cpumask implementations.
>
> Signed-off-by: Dario Faggioli 

Acked-by: George Dunlap 

>
> diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
> --- a/tools/libxc/xc_misc.c
> +++ b/tools/libxc/xc_misc.c
> @@ -54,6 +54,11 @@ int xc_get_cpumap_size(xc_interface *xch
>      return (xc_get_max_cpus(xch) + 7) / 8;
>  }
>
> +int xc_get_nodemap_size(xc_interface *xch)
> +{
> +    return (xc_get_max_nodes(xch) + 7) / 8;
> +}
> +
>  xc_cpumap_t xc_cpumap_alloc(xc_interface *xch)
>  {
>      int sz;
> @@ -64,6 +69,16 @@ xc_cpumap_t xc_cpumap_alloc(xc_interface
>      return calloc(1, sz);
>  }
>
> +xc_nodemap_t xc_nodemap_alloc(xc_interface *xch)
> +{
> +    int sz;
> +
> +    sz = xc_get_nodemap_size(xch);
> +    if (sz == 0)
> +        return NULL;
> +    return calloc(1, sz);
> +}
> +
>  int xc_readconsolering(xc_interface *xch,
>                         char *buffer,
>                         unsigned int *pnr_chars,
> diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
> --- a/tools/libxc/xenctrl.h
> +++ b/tools/libxc/xenctrl.h
> @@ -330,12 +330,20 @@ int xc_get_cpumap_size(xc_interface *xch
>  /* allocate a cpumap */
>  xc_cpumap_t xc_cpumap_alloc(xc_interface *xch);
>
> - /*
> +/*
>   * NODEMAP handling
>   */
> +typedef uint8_t *xc_nodemap_t;
> +
>  /* return maximum number of NUMA nodes the hypervisor supports */
>  int xc_get_max_nodes(xc_interface *xch);
>
> +/* return array size for nodemap */
> +int xc_get_nodemap_size(xc_interface *xch);
> +
> +/* allocate a nodemap */
> +xc_nodemap_t xc_nodemap_alloc(xc_interface *xch);
> +
>  /*
>   * DOMAIN DEBUGGING FUNCTIONS
>   */
> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -118,6 +118,30 @@ int xenctl_bitmap_to_cpumask(cpumask_var
>      return err;
>  }
>
> +int nodemask_to_xenctl_bitmap(struct xenctl_bitmap *xenctl_nodemap,
> +                              const nodemask_t *nodemask)
> +{
> +    return bitmap_to_xenctl_bitmap(xenctl_nodemap, cpumask_bits(nodemask),
> +                                   MAX_NUMNODES);
> +}
> +
> +int xenctl_bitmap_to_nodemask(nodemask_t *nodemask,
> +                              const struct xenctl_bitmap *xenctl_nodemap)
> +{
> +    int err = 0;
> +
> +    if ( alloc_nodemask_var(nodemask) ) {
> +        err = xenctl_bitmap_to_bitmap(nodes_addr(*nodemask), xenctl_nodemap,
> +                                      MAX_NUMNODES);
> +        if ( err )
> +            free_nodemask_var(*nodemask);
> +    }
> +    else
> +        err = -ENOMEM;
> +
> +    return err;
> +}
> +
>  static inline int is_free_domid(domid_t dom)
>  {
>      struct domain *d;
> diff --git a/xen/include/xen/nodemask.h b/xen/include/xen/nodemask.h
> --- a/xen/include/xen/nodemask.h
> +++ b/xen/include/xen/nodemask.h
> @@ -298,6 +298,53 @@ static inline int __nodemask_parse(const
>  }
>  #endif
>
> +/*
> + * nodemask_var_t: struct nodemask for stack usage.
> + *
> + * See definition of cpumask_var_t in include/xen//cpumask.h.
> + */
> +#if MAX_NUMNODES > 2 * BITS_PER_LONG
> +#include 
> +
> +typedef nodemask_t *nodemask_var_t;
> +
> +#define nr_nodemask_bits (BITS_TO_LONGS(MAX_NUMNODES) * BITS_PER_LONG)
> +
> +static inline bool_t alloc_nodemask_var(nodemask_var_t *mask)
> +{
> +       *(void **)mask = _xmalloc(nr_nodemask_bits / 8, sizeof(long));
> +       return *mask != NULL;
> +}
> +
> +static inline bool_t zalloc_nodemask_var(nodemask_var_t *mask)
> +{
> +       *(void **)mask = _xzalloc(nr_nodemask_bits / 8, sizeof(long));
> +       return *mask != NULL;
> +}
> +
> +static inline void free_nodemask_var(nodemask_var_t mask)
> +{
> +       xfree(mask);
> +}
> +#else
> +typedef nodemask_t nodemask_var_t;
> +
> +static inline bool_t alloc_nodemask_var(nodemask_var_t *mask)
> +{
> +       return 1;
> +}
> +
> +static inline bool_t zalloc_nodemask_var(nodemask_var_t *mask)
> +{
> +       nodes_clear(*mask);
> +       return 1;
> +}
> +
> +static inline void free_nodemask_var(nodemask_var_t mask)
> +{
> +}
> +#endif
> +
>  #if MAX_NUMNODES > 1
>  #define for_each_node_mask(node, mask)                 \
>         for ((node) = first_node(mask);                 \
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 16:00:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 16:00:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLcDc-00035s-Vx; Tue, 09 Oct 2012 15:59:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLcDb-00035f-TB
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 15:59:40 +0000
Received: from [85.158.143.99:59099] by server-3.bemta-4.messagelabs.com id
	FB/72-10986-BE944705; Tue, 09 Oct 2012 15:59:39 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1349798378!33497995!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29728 invoked from network); 9 Oct 2012 15:59:38 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 15:59:38 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so3904517eek.32
	for ; Tue, 09 Oct 2012 08:59:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=Pgu/7tPvtLjoN8KQE2iMAHOcjnaOz/Chu7jQ13WcY3s=;
	b=1JKHFnQfSXxW2+gFV6Ah9KDdb/4QrPhMtqEldfukh3X9M0X5aScwDpmtaAvQ3Sb+/4
	d5A+X9CuWSvYhofhhr1iCO/8n31NdLvSp2QyfiTVomHEJ9wpa425dccc22e9nUuvZnQr
	zR3gvMywcwG1cDZbV05zKaKBhwFjOwGgxX5Dlh0npGeDOwBcP2cjR8B6cu8sjbXhWYja
	06EKxQyF0THQJ8jPpPz5iSBKs8HFkW/CYiFCFUL94Uu7AAp77eih6aMfBOCcpCg/lzSS
	CbjppS3SP7MNZi3JrrG6wV8tlWCKCVzFV4H9T6Nymrku+NKR0Czuvesv/BqxI4IGw90O
	47Qw==
MIME-Version: 1.0
Received: by 10.14.4.201 with SMTP id 49mr28299297eej.0.1349798378233; Tue, 09
	Oct 2012 08:59:38 -0700 (PDT)
Received: by 10.14.215.195 with HTTP; Tue, 9 Oct 2012 08:59:38 -0700 (PDT)
In-Reply-To: <9e7d4c414d9566832d52.1349446100@Solace>
References: 
	<9e7d4c414d9566832d52.1349446100@Solace>
Date: Tue, 9 Oct 2012 16:59:38 +0100
X-Google-Sender-Auth: Ghl69S3xTRuGUkTzjKREAXFN0Xg
Message-ID: 
From: George Dunlap 
To: Dario Faggioli 
Cc: Marcus Granado ,
	Andre Przywara ,
	Ian Campbell ,
	Anil Madhavapeddy ,
	Andrew Cooper ,
	Juergen Gross ,
	Ian Jackson , xen-devel@lists.xen.org,
	Jan Beulich , Daniel De Graaf ,
	Matt Wilson 
Subject: Re: [Xen-devel] [PATCH 2 of 8] xen,
	libxc: introduce node maps and masks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 5, 2012 at 3:08 PM, Dario Faggioli
 wrote:
> Following suit from cpumap and cpumask implementations.
>
> Signed-off-by: Dario Faggioli 

Acked-by: George Dunlap 

>
> diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
> --- a/tools/libxc/xc_misc.c
> +++ b/tools/libxc/xc_misc.c
> @@ -54,6 +54,11 @@ int xc_get_cpumap_size(xc_interface *xch
>      return (xc_get_max_cpus(xch) + 7) / 8;
>  }
>
> +int xc_get_nodemap_size(xc_interface *xch)
> +{
> +    return (xc_get_max_nodes(xch) + 7) / 8;
> +}
> +
>  xc_cpumap_t xc_cpumap_alloc(xc_interface *xch)
>  {
>      int sz;
> @@ -64,6 +69,16 @@ xc_cpumap_t xc_cpumap_alloc(xc_interface
>      return calloc(1, sz);
>  }
>
> +xc_nodemap_t xc_nodemap_alloc(xc_interface *xch)
> +{
> +    int sz;
> +
> +    sz = xc_get_nodemap_size(xch);
> +    if (sz == 0)
> +        return NULL;
> +    return calloc(1, sz);
> +}
> +
>  int xc_readconsolering(xc_interface *xch,
>                         char *buffer,
>                         unsigned int *pnr_chars,
> diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
> --- a/tools/libxc/xenctrl.h
> +++ b/tools/libxc/xenctrl.h
> @@ -330,12 +330,20 @@ int xc_get_cpumap_size(xc_interface *xch
>  /* allocate a cpumap */
>  xc_cpumap_t xc_cpumap_alloc(xc_interface *xch);
>
> - /*
> +/*
>   * NODEMAP handling
>   */
> +typedef uint8_t *xc_nodemap_t;
> +
>  /* return maximum number of NUMA nodes the hypervisor supports */
>  int xc_get_max_nodes(xc_interface *xch);
>
> +/* return array size for nodemap */
> +int xc_get_nodemap_size(xc_interface *xch);
> +
> +/* allocate a nodemap */
> +xc_nodemap_t xc_nodemap_alloc(xc_interface *xch);
> +
>  /*
>   * DOMAIN DEBUGGING FUNCTIONS
>   */
> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -118,6 +118,30 @@ int xenctl_bitmap_to_cpumask(cpumask_var
>      return err;
>  }
>
> +int nodemask_to_xenctl_bitmap(struct xenctl_bitmap *xenctl_nodemap,
> +                              const nodemask_t *nodemask)
> +{
> +    return bitmap_to_xenctl_bitmap(xenctl_nodemap, cpumask_bits(nodemask),
> +                                   MAX_NUMNODES);
> +}
> +
> +int xenctl_bitmap_to_nodemask(nodemask_t *nodemask,
> +                              const struct xenctl_bitmap *xenctl_nodemap)
> +{
> +    int err = 0;
> +
> +    if ( alloc_nodemask_var(nodemask) ) {
> +        err = xenctl_bitmap_to_bitmap(nodes_addr(*nodemask), xenctl_nodemap,
> +                                      MAX_NUMNODES);
> +        if ( err )
> +            free_nodemask_var(*nodemask);
> +    }
> +    else
> +        err = -ENOMEM;
> +
> +    return err;
> +}
> +
>  static inline int is_free_domid(domid_t dom)
>  {
>      struct domain *d;
> diff --git a/xen/include/xen/nodemask.h b/xen/include/xen/nodemask.h
> --- a/xen/include/xen/nodemask.h
> +++ b/xen/include/xen/nodemask.h
> @@ -298,6 +298,53 @@ static inline int __nodemask_parse(const
>  }
>  #endif
>
> +/*
> + * nodemask_var_t: struct nodemask for stack usage.
> + *
> + * See definition of cpumask_var_t in include/xen//cpumask.h.
> + */
> +#if MAX_NUMNODES > 2 * BITS_PER_LONG
> +#include 
> +
> +typedef nodemask_t *nodemask_var_t;
> +
> +#define nr_nodemask_bits (BITS_TO_LONGS(MAX_NUMNODES) * BITS_PER_LONG)
> +
> +static inline bool_t alloc_nodemask_var(nodemask_var_t *mask)
> +{
> +       *(void **)mask = _xmalloc(nr_nodemask_bits / 8, sizeof(long));
> +       return *mask != NULL;
> +}
> +
> +static inline bool_t zalloc_nodemask_var(nodemask_var_t *mask)
> +{
> +       *(void **)mask = _xzalloc(nr_nodemask_bits / 8, sizeof(long));
> +       return *mask != NULL;
> +}
> +
> +static inline void free_nodemask_var(nodemask_var_t mask)
> +{
> +       xfree(mask);
> +}
> +#else
> +typedef nodemask_t nodemask_var_t;
> +
> +static inline bool_t alloc_nodemask_var(nodemask_var_t *mask)
> +{
> +       return 1;
> +}
> +
> +static inline bool_t zalloc_nodemask_var(nodemask_var_t *mask)
> +{
> +       nodes_clear(*mask);
> +       return 1;
> +}
> +
> +static inline void free_nodemask_var(nodemask_var_t mask)
> +{
> +}
> +#endif
> +
>  #if MAX_NUMNODES > 1
>  #define for_each_node_mask(node, mask)                 \
>         for ((node) = first_node(mask);                 \
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 16:08:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 16:08:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLcME-0003pq-05; Tue, 09 Oct 2012 16:08:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLcMC-0003pl-SR
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 16:08:33 +0000
Received: from [85.158.139.83:46163] by server-16.bemta-5.messagelabs.com id
	E2/51-21637-00C44705; Tue, 09 Oct 2012 16:08:32 +0000
X-Env-Sender: linux+xen-devel=lists.xensource.com@arm.linux.org.uk
X-Msg-Ref: server-12.tower-182.messagelabs.com!1349798910!33928113!1
X-Originating-IP: [78.32.30.218]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19763 invoked from network); 9 Oct 2012 16:08:31 -0000
Received: from caramon.arm.linux.org.uk (HELO caramon.arm.linux.org.uk)
	(78.32.30.218)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Oct 2012 16:08:31 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=arm.linux.org.uk; s=caramon; 
	h=Sender:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date;
	bh=MucZu0HoK5jsd9s0lBp91a0ejWpMbXcxqjK3gDJnmY0=; 
	b=dIr4e5RT3Ralxn3ip9KzQnXbppk5KsMrnYY8gpFL82Oa5h3el+wk3IReZ2aBcErHCXS5sLxj7tQk53pkS37bzRmQoJXsrne+ZpS9qRHZPAKWMs+RdwgGoi6eT7PC9DKhVYF1AKLfgL/eJa+tLocq7nLamQjjnfqNaJvlw0tAeqA=;
Received: from n2100.arm.linux.org.uk
	([2002:4e20:1eda:1:214:fdff:fe10:4f86]:37380)
	by caramon.arm.linux.org.uk with esmtpsa (TLSv1:AES256-SHA:256)
	(Exim 4.76) (envelope-from )
	id 1TLcIU-0002Qb-Vm; Tue, 09 Oct 2012 17:04:43 +0100
Received: from linux by n2100.arm.linux.org.uk with local (Exim 4.76)
	(envelope-from )
	id 1TLcIT-000713-RJ; Tue, 09 Oct 2012 17:04:41 +0100
Date: Tue, 9 Oct 2012 17:04:41 +0100
From: Russell King - ARM Linux 
To: Arnd Bergmann 
Message-ID: <20121009160441.GF4625@n2100.arm.linux.org.uk>
References: <1349796183-30648-1-git-send-email-arnd@arndb.de>
	<1349796183-30648-6-git-send-email-arnd@arndb.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1349796183-30648-6-git-send-email-arnd@arndb.de>
User-Agent: Mutt/1.5.19 (2009-01-05)
Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk ,
	Stefano Stabellini ,
	linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 09, 2012 at 05:22:59PM +0200, Arnd Bergmann wrote:
> * The XEN_BALLOON code requires the balloon infrastructure that is not
>   getting built on ARM.
> 
> * The tmem hypercall is not available on ARM
> 
> * ARMv6 does not support cmpxchg on 16-bit words that are used in the

"in the" what?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 16:08:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 16:08:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLcME-0003pq-05; Tue, 09 Oct 2012 16:08:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLcMC-0003pl-SR
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 16:08:33 +0000
Received: from [85.158.139.83:46163] by server-16.bemta-5.messagelabs.com id
	E2/51-21637-00C44705; Tue, 09 Oct 2012 16:08:32 +0000
X-Env-Sender: linux+xen-devel=lists.xensource.com@arm.linux.org.uk
X-Msg-Ref: server-12.tower-182.messagelabs.com!1349798910!33928113!1
X-Originating-IP: [78.32.30.218]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19763 invoked from network); 9 Oct 2012 16:08:31 -0000
Received: from caramon.arm.linux.org.uk (HELO caramon.arm.linux.org.uk)
	(78.32.30.218)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Oct 2012 16:08:31 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=arm.linux.org.uk; s=caramon; 
	h=Sender:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date;
	bh=MucZu0HoK5jsd9s0lBp91a0ejWpMbXcxqjK3gDJnmY0=; 
	b=dIr4e5RT3Ralxn3ip9KzQnXbppk5KsMrnYY8gpFL82Oa5h3el+wk3IReZ2aBcErHCXS5sLxj7tQk53pkS37bzRmQoJXsrne+ZpS9qRHZPAKWMs+RdwgGoi6eT7PC9DKhVYF1AKLfgL/eJa+tLocq7nLamQjjnfqNaJvlw0tAeqA=;
Received: from n2100.arm.linux.org.uk
	([2002:4e20:1eda:1:214:fdff:fe10:4f86]:37380)
	by caramon.arm.linux.org.uk with esmtpsa (TLSv1:AES256-SHA:256)
	(Exim 4.76) (envelope-from )
	id 1TLcIU-0002Qb-Vm; Tue, 09 Oct 2012 17:04:43 +0100
Received: from linux by n2100.arm.linux.org.uk with local (Exim 4.76)
	(envelope-from )
	id 1TLcIT-000713-RJ; Tue, 09 Oct 2012 17:04:41 +0100
Date: Tue, 9 Oct 2012 17:04:41 +0100
From: Russell King - ARM Linux 
To: Arnd Bergmann 
Message-ID: <20121009160441.GF4625@n2100.arm.linux.org.uk>
References: <1349796183-30648-1-git-send-email-arnd@arndb.de>
	<1349796183-30648-6-git-send-email-arnd@arndb.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1349796183-30648-6-git-send-email-arnd@arndb.de>
User-Agent: Mutt/1.5.19 (2009-01-05)
Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk ,
	Stefano Stabellini ,
	linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 09, 2012 at 05:22:59PM +0200, Arnd Bergmann wrote:
> * The XEN_BALLOON code requires the balloon infrastructure that is not
>   getting built on ARM.
> 
> * The tmem hypercall is not available on ARM
> 
> * ARMv6 does not support cmpxchg on 16-bit words that are used in the

"in the" what?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 16:10:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 16:10:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLcNd-0003tm-Fg; Tue, 09 Oct 2012 16:10:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLcNb-0003ta-TQ
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 16:10:00 +0000
Received: from [85.158.138.51:64899] by server-8.bemta-3.messagelabs.com id
	FB/C9-16337-65C44705; Tue, 09 Oct 2012 16:09:58 +0000
X-Env-Sender: linux+xen-devel=lists.xensource.com@arm.linux.org.uk
X-Msg-Ref: server-14.tower-174.messagelabs.com!1349798997!27378036!1
X-Originating-IP: [78.32.30.218]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1232 invoked from network); 9 Oct 2012 16:09:58 -0000
Received: from caramon.arm.linux.org.uk (HELO caramon.arm.linux.org.uk)
	(78.32.30.218)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Oct 2012 16:09:58 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=arm.linux.org.uk; s=caramon; 
	h=Sender:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date;
	bh=nny92G0s+bk3DFEADmDEj+V/vz42tnKO+8/HI1p9nl8=; 
	b=emDAZwf55MggFJrUmP8ZLYqKeY/hcguONbPcBr41bDDgoZh4fitWRnXvVRVt/RBPbhyeY8E+iiu2EKiFHME2ZE3K60NgiI2HPdyN3YivxbZeaXLe3kIB/02hZaPm2URD2Qb7u7PpWhavWxQm4zqZibpY8COmKeJAzxaHAYf+1ag=;
Received: from n2100.arm.linux.org.uk
	([2002:4e20:1eda:1:214:fdff:fe10:4f86]:49065)
	by caramon.arm.linux.org.uk with esmtpsa (TLSv1:AES256-SHA:256)
	(Exim 4.76) (envelope-from )
	id 1TLcLw-0002R7-OB; Tue, 09 Oct 2012 17:08:17 +0100
Received: from linux by n2100.arm.linux.org.uk with local (Exim 4.76)
	(envelope-from )
	id 1TLcLv-000738-4z; Tue, 09 Oct 2012 17:08:15 +0100
Date: Tue, 9 Oct 2012 17:08:14 +0100
From: Russell King - ARM Linux 
To: Arnd Bergmann 
Message-ID: <20121009160814.GH4625@n2100.arm.linux.org.uk>
References: <1349796183-30648-1-git-send-email-arnd@arndb.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1349796183-30648-1-git-send-email-arnd@arndb.de>
User-Agent: Mutt/1.5.19 (2009-01-05)
Cc: mmarek@suse.cz, dave.martin@linaro.org, xen-devel@lists.xensource.com,
	jonathan.austin@arm.com, konrad.wilk@oracle.com,
	catalin.marinas@arm.com, linus.walleij@linaro.org,
	stefano.stabellini@eu.citrix.com, sboyd@codeaurora.org,
	jeremy@goop.org, will.deacon@arm.com,
	linux-kernel@vger.kernel.org, rjw@sisk.pl, damm@opensource.se,
	bryan.wu@canonical.com, tglx@linutronix.de,
	leif.lindholm@arm.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [GIT PULL 0/9] ARM architecture fixes for 3.7
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 09, 2012 at 05:22:54PM +0200, Arnd Bergmann wrote:
> Here are some patches that belong into your domain, I hope you can
> just send the lot to Linus the next time you send other patches.
> 
> These bug fixes all address problems found with automated build testing.
> Some of them have been around for a long time, other bugs are
> regressions since the merge window.

Apart from the sliced off comment in one commit (which XEN people need
to confirm they're happy with the final version), I think these are
otherwise fine... I'll hold off pulling them until that can be fixed.

Thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 16:10:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 16:10:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLcNd-0003tm-Fg; Tue, 09 Oct 2012 16:10:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLcNb-0003ta-TQ
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 16:10:00 +0000
Received: from [85.158.138.51:64899] by server-8.bemta-3.messagelabs.com id
	FB/C9-16337-65C44705; Tue, 09 Oct 2012 16:09:58 +0000
X-Env-Sender: linux+xen-devel=lists.xensource.com@arm.linux.org.uk
X-Msg-Ref: server-14.tower-174.messagelabs.com!1349798997!27378036!1
X-Originating-IP: [78.32.30.218]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1232 invoked from network); 9 Oct 2012 16:09:58 -0000
Received: from caramon.arm.linux.org.uk (HELO caramon.arm.linux.org.uk)
	(78.32.30.218)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Oct 2012 16:09:58 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=arm.linux.org.uk; s=caramon; 
	h=Sender:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date;
	bh=nny92G0s+bk3DFEADmDEj+V/vz42tnKO+8/HI1p9nl8=; 
	b=emDAZwf55MggFJrUmP8ZLYqKeY/hcguONbPcBr41bDDgoZh4fitWRnXvVRVt/RBPbhyeY8E+iiu2EKiFHME2ZE3K60NgiI2HPdyN3YivxbZeaXLe3kIB/02hZaPm2URD2Qb7u7PpWhavWxQm4zqZibpY8COmKeJAzxaHAYf+1ag=;
Received: from n2100.arm.linux.org.uk
	([2002:4e20:1eda:1:214:fdff:fe10:4f86]:49065)
	by caramon.arm.linux.org.uk with esmtpsa (TLSv1:AES256-SHA:256)
	(Exim 4.76) (envelope-from )
	id 1TLcLw-0002R7-OB; Tue, 09 Oct 2012 17:08:17 +0100
Received: from linux by n2100.arm.linux.org.uk with local (Exim 4.76)
	(envelope-from )
	id 1TLcLv-000738-4z; Tue, 09 Oct 2012 17:08:15 +0100
Date: Tue, 9 Oct 2012 17:08:14 +0100
From: Russell King - ARM Linux 
To: Arnd Bergmann 
Message-ID: <20121009160814.GH4625@n2100.arm.linux.org.uk>
References: <1349796183-30648-1-git-send-email-arnd@arndb.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1349796183-30648-1-git-send-email-arnd@arndb.de>
User-Agent: Mutt/1.5.19 (2009-01-05)
Cc: mmarek@suse.cz, dave.martin@linaro.org, xen-devel@lists.xensource.com,
	jonathan.austin@arm.com, konrad.wilk@oracle.com,
	catalin.marinas@arm.com, linus.walleij@linaro.org,
	stefano.stabellini@eu.citrix.com, sboyd@codeaurora.org,
	jeremy@goop.org, will.deacon@arm.com,
	linux-kernel@vger.kernel.org, rjw@sisk.pl, damm@opensource.se,
	bryan.wu@canonical.com, tglx@linutronix.de,
	leif.lindholm@arm.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [GIT PULL 0/9] ARM architecture fixes for 3.7
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 09, 2012 at 05:22:54PM +0200, Arnd Bergmann wrote:
> Here are some patches that belong into your domain, I hope you can
> just send the lot to Linus the next time you send other patches.
> 
> These bug fixes all address problems found with automated build testing.
> Some of them have been around for a long time, other bugs are
> regressions since the merge window.

Apart from the sliced off comment in one commit (which XEN people need
to confirm they're happy with the final version), I think these are
otherwise fine... I'll hold off pulling them until that can be fixed.

Thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 16:10:59 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 16:10:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLcOJ-0003xR-Tu; Tue, 09 Oct 2012 16:10:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLcOI-0003xA-2C
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 16:10:42 +0000
Received: from [85.158.138.51:20459] by server-14.bemta-3.messagelabs.com id
	5F/1F-19528-18C44705; Tue, 09 Oct 2012 16:10:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1349799037!33204714!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29815 invoked from network); 9 Oct 2012 16:10:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 16:10:37 -0000
X-IronPort-AV: E=Sophos;i="4.80,561,1344211200"; d="scan'208";a="15044977"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 16:10:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	17:10:37 +0100
Message-ID: <1349799035.21847.222.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Arnd Bergmann 
Date: Tue, 9 Oct 2012 17:10:35 +0100
In-Reply-To: <201210091539.46274.arnd@arndb.de>
References: <1349796183-30648-1-git-send-email-arnd@arndb.de>
	<1349796183-30648-6-git-send-email-arnd@arndb.de>
	<1349796958.21847.219.camel@zakaz.uk.xensource.com>
	<201210091539.46274.arnd@arndb.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge ,
	"xen-devel@lists.xensource.com" ,
	Stefano Stabellini ,
	Konrad Rzeszutek Wilk ,
	"linux-kernel@vger.kernel.org" ,
	Russell King ,
	"linux-arm-kernel@lists.infradead.org"
	
Subject: Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-09 at 16:39 +0100, Arnd Bergmann wrote:
> On Tuesday 09 October 2012, Ian Campbell wrote:
> > > * The tmem hypercall is not available on ARM
> > > 
> > > * ARMv6 does not support cmpxchg on 16-bit words that are used in the
> > 
> > missing the end of this sentence?
> 
> Right, I meant to say 
> 
> * ARMv6 does not support cmpxchg on 16-bit words that are used in the
>   Xen grant table code, so we must ensure that Xen support is only built
>   on ARMv7-only kernels not combined ARMv6/v7 kernels.
> 
> This should be fixed differently in the future.

Is this is a build time failure because gcc/gas/etc refuses to generate
these instructions if it is configured for v6?

I ask because if it is only a runtime issue then we can reason that if
we are running Xen specific grant table code, then we must be running on
Xen and therefore must necessarily be running on a v7 (because Xen only
support v7+virt extensions) even if the kernel happens to be capable of
running on v6 too.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 16:10:59 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 16:10:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLcOJ-0003xR-Tu; Tue, 09 Oct 2012 16:10:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLcOI-0003xA-2C
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 16:10:42 +0000
Received: from [85.158.138.51:20459] by server-14.bemta-3.messagelabs.com id
	5F/1F-19528-18C44705; Tue, 09 Oct 2012 16:10:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1349799037!33204714!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29815 invoked from network); 9 Oct 2012 16:10:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 16:10:37 -0000
X-IronPort-AV: E=Sophos;i="4.80,561,1344211200"; d="scan'208";a="15044977"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 16:10:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	17:10:37 +0100
Message-ID: <1349799035.21847.222.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Arnd Bergmann 
Date: Tue, 9 Oct 2012 17:10:35 +0100
In-Reply-To: <201210091539.46274.arnd@arndb.de>
References: <1349796183-30648-1-git-send-email-arnd@arndb.de>
	<1349796183-30648-6-git-send-email-arnd@arndb.de>
	<1349796958.21847.219.camel@zakaz.uk.xensource.com>
	<201210091539.46274.arnd@arndb.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge ,
	"xen-devel@lists.xensource.com" ,
	Stefano Stabellini ,
	Konrad Rzeszutek Wilk ,
	"linux-kernel@vger.kernel.org" ,
	Russell King ,
	"linux-arm-kernel@lists.infradead.org"
	
Subject: Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-09 at 16:39 +0100, Arnd Bergmann wrote:
> On Tuesday 09 October 2012, Ian Campbell wrote:
> > > * The tmem hypercall is not available on ARM
> > > 
> > > * ARMv6 does not support cmpxchg on 16-bit words that are used in the
> > 
> > missing the end of this sentence?
> 
> Right, I meant to say 
> 
> * ARMv6 does not support cmpxchg on 16-bit words that are used in the
>   Xen grant table code, so we must ensure that Xen support is only built
>   on ARMv7-only kernels not combined ARMv6/v7 kernels.
> 
> This should be fixed differently in the future.

Is this is a build time failure because gcc/gas/etc refuses to generate
these instructions if it is configured for v6?

I ask because if it is only a runtime issue then we can reason that if
we are running Xen specific grant table code, then we must be running on
Xen and therefore must necessarily be running on a v7 (because Xen only
support v7+virt extensions) even if the kernel happens to be capable of
running on v6 too.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 16:28:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 16:28:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLceo-0004GS-HY; Tue, 09 Oct 2012 16:27:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLcen-0004GI-ML
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 16:27:45 +0000
Received: from [85.158.139.211:63907] by server-8.bemta-5.messagelabs.com id
	EB/A3-23193-F7054705; Tue, 09 Oct 2012 16:27:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1349800062!21715296!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1481 invoked from network); 9 Oct 2012 16:27:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 16:27:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,561,1344211200"; d="scan'208";a="15045616"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 16:27:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 9 Oct 2012 17:27:41 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TLcej-00040p-LI; Tue, 09 Oct 2012 16:27:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TLcej-0004s4-Fq;
	Tue, 09 Oct 2012 17:27:41 +0100
From: Ian Jackson 
To: xen-devel@lists.xensource.com
Date: Tue, 9 Oct 2012 17:27:36 +0100
Message-ID: <1349800059-18689-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1349776105.21847.112.camel@zakaz.uk.xensource.com>
References: <1349776105.21847.112.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH v2 0/3] docs,
	build: Do not ignore install-docs errors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Changes in v2: new patches to tolerate missing fig2dev and pod2text,
which is necessary to avoid turning the failure to find fig2dev from
an error ignored in the wrong way into a fatal error.  So this is now
a 3-patch series.  3/3 is the unchanged patch from before.

 1/3 docs, build: Tolerate missing fig2dev
 2/3 docs, build: Tolerate missing pod2text
 3/3 docs, build: Do not ignore install-docs errors


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 16:28:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 16:28:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLceo-0004GS-HY; Tue, 09 Oct 2012 16:27:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLcen-0004GI-ML
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 16:27:45 +0000
Received: from [85.158.139.211:63907] by server-8.bemta-5.messagelabs.com id
	EB/A3-23193-F7054705; Tue, 09 Oct 2012 16:27:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1349800062!21715296!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1481 invoked from network); 9 Oct 2012 16:27:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 16:27:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,561,1344211200"; d="scan'208";a="15045616"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 16:27:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 9 Oct 2012 17:27:41 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TLcej-00040p-LI; Tue, 09 Oct 2012 16:27:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TLcej-0004s4-Fq;
	Tue, 09 Oct 2012 17:27:41 +0100
From: Ian Jackson 
To: xen-devel@lists.xensource.com
Date: Tue, 9 Oct 2012 17:27:36 +0100
Message-ID: <1349800059-18689-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1349776105.21847.112.camel@zakaz.uk.xensource.com>
References: <1349776105.21847.112.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH v2 0/3] docs,
	build: Do not ignore install-docs errors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Changes in v2: new patches to tolerate missing fig2dev and pod2text,
which is necessary to avoid turning the failure to find fig2dev from
an error ignored in the wrong way into a fatal error.  So this is now
a 3-patch series.  3/3 is the unchanged patch from before.

 1/3 docs, build: Tolerate missing fig2dev
 2/3 docs, build: Tolerate missing pod2text
 3/3 docs, build: Do not ignore install-docs errors


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 16:28:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 16:28:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLceo-0004GZ-Sq; Tue, 09 Oct 2012 16:27:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLcen-0004GJ-ME
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 16:27:45 +0000
Received: from [85.158.139.211:26241] by server-13.bemta-5.messagelabs.com id
	0D/CC-06496-18054705; Tue, 09 Oct 2012 16:27:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1349800062!21715296!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1674 invoked from network); 9 Oct 2012 16:27:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 16:27:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,561,1344211200"; d="scan'208";a="15045618"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 16:27:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 9 Oct 2012 17:27:44 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TLcem-00040s-59; Tue, 09 Oct 2012 16:27:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TLcem-0004sE-0E;
	Tue, 09 Oct 2012 17:27:44 +0100
From: Ian Jackson 
To: 
Date: Tue, 9 Oct 2012 17:27:37 +0100
Message-ID: <1349800059-18689-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1349776105.21847.112.camel@zakaz.uk.xensource.com>
References: <1349776105.21847.112.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson 
Subject: [Xen-devel] [PATCH 1/3] docs, build: Tolerate missing fig2dev
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Jackson 
---
 docs/Makefile |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/docs/Makefile b/docs/Makefile
index 8806990..e9f6c20 100644
--- a/docs/Makefile
+++ b/docs/Makefile
@@ -42,7 +42,9 @@ txt: $(DOC_TXT)
 
 .PHONY: figs
 figs:
-	$(MAKE) -C figs
+	@set -e ; if which $(FIG2DEV) 1>/dev/null 2>/dev/null; then \
+	set -x; $(MAKE) -C figs ; else                   \
+	echo "fig2dev (transfig) not installed; skipping figs."; fi
 
 .PHONY: python-dev-docs
 python-dev-docs:
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 16:28:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 16:28:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLceo-0004GZ-Sq; Tue, 09 Oct 2012 16:27:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLcen-0004GJ-ME
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 16:27:45 +0000
Received: from [85.158.139.211:26241] by server-13.bemta-5.messagelabs.com id
	0D/CC-06496-18054705; Tue, 09 Oct 2012 16:27:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1349800062!21715296!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1674 invoked from network); 9 Oct 2012 16:27:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 16:27:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,561,1344211200"; d="scan'208";a="15045618"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 16:27:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 9 Oct 2012 17:27:44 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TLcem-00040s-59; Tue, 09 Oct 2012 16:27:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TLcem-0004sE-0E;
	Tue, 09 Oct 2012 17:27:44 +0100
From: Ian Jackson 
To: 
Date: Tue, 9 Oct 2012 17:27:37 +0100
Message-ID: <1349800059-18689-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1349776105.21847.112.camel@zakaz.uk.xensource.com>
References: <1349776105.21847.112.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson 
Subject: [Xen-devel] [PATCH 1/3] docs, build: Tolerate missing fig2dev
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Jackson 
---
 docs/Makefile |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/docs/Makefile b/docs/Makefile
index 8806990..e9f6c20 100644
--- a/docs/Makefile
+++ b/docs/Makefile
@@ -42,7 +42,9 @@ txt: $(DOC_TXT)
 
 .PHONY: figs
 figs:
-	$(MAKE) -C figs
+	@set -e ; if which $(FIG2DEV) 1>/dev/null 2>/dev/null; then \
+	set -x; $(MAKE) -C figs ; else                   \
+	echo "fig2dev (transfig) not installed; skipping figs."; fi
 
 .PHONY: python-dev-docs
 python-dev-docs:
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 16:28:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 16:28:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLces-0004Gt-90; Tue, 09 Oct 2012 16:27:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLceq-0004Gg-Nq
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 16:27:48 +0000
Received: from [85.158.139.211:64190] by server-12.bemta-5.messagelabs.com id
	DA/07-19095-38054705; Tue, 09 Oct 2012 16:27:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1349800062!21715296!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1919 invoked from network); 9 Oct 2012 16:27:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 16:27:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,561,1344211200"; d="scan'208";a="15045621"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 16:27:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 9 Oct 2012 17:27:47 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TLcep-00040v-EM; Tue, 09 Oct 2012 16:27:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TLcep-0004sI-A0;
	Tue, 09 Oct 2012 17:27:47 +0100
From: Ian Jackson 
To: 
Date: Tue, 9 Oct 2012 17:27:38 +0100
Message-ID: <1349800059-18689-3-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1349776105.21847.112.camel@zakaz.uk.xensource.com>
References: <1349776105.21847.112.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson 
Subject: [Xen-devel] [PATCH 2/3] docs, build: Tolerate missing pod2text
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We gate the whole of the "txt" target on pod2text.  I think this is
better than gating only the pod-generated outputs; it avoids a partial
output tree.

Signed-off-by: Ian Jackson 
---
 docs/Makefile |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/docs/Makefile b/docs/Makefile
index e9f6c20..03f141a 100644
--- a/docs/Makefile
+++ b/docs/Makefile
@@ -38,7 +38,10 @@ dev-docs: python-dev-docs
 html: $(DOC_HTML) html/index.html
 
 .PHONY: txt
-txt: $(DOC_TXT)
+txt:
+	@if which $(POD2TEXT) 1>/dev/null 2>/dev/null; then \
+	$(MAKE) $(DOC_TXT); else              \
+	echo "pod2text not installed; skipping text outputs."; fi
 
 .PHONY: figs
 figs:
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 16:28:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 16:28:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLces-0004Gt-90; Tue, 09 Oct 2012 16:27:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLceq-0004Gg-Nq
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 16:27:48 +0000
Received: from [85.158.139.211:64190] by server-12.bemta-5.messagelabs.com id
	DA/07-19095-38054705; Tue, 09 Oct 2012 16:27:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1349800062!21715296!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1919 invoked from network); 9 Oct 2012 16:27:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 16:27:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,561,1344211200"; d="scan'208";a="15045621"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 16:27:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 9 Oct 2012 17:27:47 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TLcep-00040v-EM; Tue, 09 Oct 2012 16:27:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TLcep-0004sI-A0;
	Tue, 09 Oct 2012 17:27:47 +0100
From: Ian Jackson 
To: 
Date: Tue, 9 Oct 2012 17:27:38 +0100
Message-ID: <1349800059-18689-3-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1349776105.21847.112.camel@zakaz.uk.xensource.com>
References: <1349776105.21847.112.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson 
Subject: [Xen-devel] [PATCH 2/3] docs, build: Tolerate missing pod2text
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We gate the whole of the "txt" target on pod2text.  I think this is
better than gating only the pod-generated outputs; it avoids a partial
output tree.

Signed-off-by: Ian Jackson 
---
 docs/Makefile |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/docs/Makefile b/docs/Makefile
index e9f6c20..03f141a 100644
--- a/docs/Makefile
+++ b/docs/Makefile
@@ -38,7 +38,10 @@ dev-docs: python-dev-docs
 html: $(DOC_HTML) html/index.html
 
 .PHONY: txt
-txt: $(DOC_TXT)
+txt:
+	@if which $(POD2TEXT) 1>/dev/null 2>/dev/null; then \
+	$(MAKE) $(DOC_TXT); else              \
+	echo "pod2text not installed; skipping text outputs."; fi
 
 .PHONY: figs
 figs:
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 16:28:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 16:28:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLcey-0004Hy-La; Tue, 09 Oct 2012 16:27:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLcex-0004Hf-DX
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 16:27:55 +0000
Received: from [85.158.143.99:49011] by server-3.bemta-4.messagelabs.com id
	75/32-10986-A8054705; Tue, 09 Oct 2012 16:27:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1349800074!25340711!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24928 invoked from network); 9 Oct 2012 16:27:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 16:27:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,561,1344211200"; d="scan'208";a="15045627"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 16:27:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 9 Oct 2012 17:27:53 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TLcev-000410-8u; Tue, 09 Oct 2012 16:27:53 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TLcev-0004sR-4L;
	Tue, 09 Oct 2012 17:27:53 +0100
From: Ian Jackson 
To: 
Date: Tue, 9 Oct 2012 17:27:39 +0100
Message-ID: <1349800059-18689-4-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1349776105.21847.112.camel@zakaz.uk.xensource.com>
References: <1349776105.21847.112.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson 
Subject: [Xen-devel] [PATCH 3/3] docs,
	build: Do not ignore install-docs errors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In the toplevel Makefile "install-docs" (depended on by "install" and
hence "dist"), but not "build", ignores errors.

This was inherited from before 24563:4271634e4c86, prior to which the
||true seems intended to handle failures of check_pkgs.  Nowadays we
handle docs tools individually in the docs makefiles so there is no
need for this ||true here.

Signed-off-by: Ian Jackson 
---
 Makefile |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/Makefile b/Makefile
index 373ca19..b54cfbf 100644
--- a/Makefile
+++ b/Makefile
@@ -103,7 +103,7 @@ tools/firmware/seabios-dir-force-update:
 
 .PHONY: install-docs
 install-docs:
-	$(MAKE) -C docs install || true
+	$(MAKE) -C docs install
 
 .PHONY: dev-docs
 dev-docs:
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 16:28:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 16:28:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLcey-0004Hy-La; Tue, 09 Oct 2012 16:27:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLcex-0004Hf-DX
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 16:27:55 +0000
Received: from [85.158.143.99:49011] by server-3.bemta-4.messagelabs.com id
	75/32-10986-A8054705; Tue, 09 Oct 2012 16:27:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1349800074!25340711!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24928 invoked from network); 9 Oct 2012 16:27:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 16:27:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,561,1344211200"; d="scan'208";a="15045627"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 16:27:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 9 Oct 2012 17:27:53 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TLcev-000410-8u; Tue, 09 Oct 2012 16:27:53 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TLcev-0004sR-4L;
	Tue, 09 Oct 2012 17:27:53 +0100
From: Ian Jackson 
To: 
Date: Tue, 9 Oct 2012 17:27:39 +0100
Message-ID: <1349800059-18689-4-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1349776105.21847.112.camel@zakaz.uk.xensource.com>
References: <1349776105.21847.112.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson 
Subject: [Xen-devel] [PATCH 3/3] docs,
	build: Do not ignore install-docs errors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In the toplevel Makefile "install-docs" (depended on by "install" and
hence "dist"), but not "build", ignores errors.

This was inherited from before 24563:4271634e4c86, prior to which the
||true seems intended to handle failures of check_pkgs.  Nowadays we
handle docs tools individually in the docs makefiles so there is no
need for this ||true here.

Signed-off-by: Ian Jackson 
---
 Makefile |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/Makefile b/Makefile
index 373ca19..b54cfbf 100644
--- a/Makefile
+++ b/Makefile
@@ -103,7 +103,7 @@ tools/firmware/seabios-dir-force-update:
 
 .PHONY: install-docs
 install-docs:
-	$(MAKE) -C docs install || true
+	$(MAKE) -C docs install
 
 .PHONY: dev-docs
 dev-docs:
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 16:30:06 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 16:30:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLcgv-0004cG-EJ; Tue, 09 Oct 2012 16:29:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLcgu-0004c7-1h
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 16:29:56 +0000
Received: from [85.158.143.99:58132] by server-3.bemta-4.messagelabs.com id
	6F/64-10986-30154705; Tue, 09 Oct 2012 16:29:55 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1349800194!32855271!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4973 invoked from network); 9 Oct 2012 16:29:54 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 16:29:54 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so3930518eek.32
	for ; Tue, 09 Oct 2012 09:29:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=Zb6hap+5o2yXd2INS3A01P4EwPDDoNUWklBuX8YJCC8=;
	b=lvohqtAP/DHiuj8IjPDv/QJWv/ZnVhAp7MlAyKPd8TSuZD3yyVPxXfFiCzJgZNVZf9
	JcbKp1nhaZFZPgalCanZ9OwkQA+iQeCFLHloigRUSyA/XVzFfzPM+J0mDGRsTbEeMGZj
	yGpyjDEFNZ4e4pvd8/MjSue9z18YgfSWXbr2sOmaw8/Jh4qA1iSXOIIdrPtqhtM2Nvkw
	HBfYA8hZoKtGy3w9892bi8NLHSVkl1McMBzAPVtLzAKWIH54ToauaJyOfxW42Xfb7AJB
	+r3UuVssBR3AC6548+V724P8Z10+7Q9avBANVMAMLS1N31sbrxGQG2/LDil7jBWaYyw9
	E6tw==
MIME-Version: 1.0
Received: by 10.14.212.72 with SMTP id x48mr27962213eeo.40.1349800194231; Tue,
	09 Oct 2012 09:29:54 -0700 (PDT)
Received: by 10.14.215.195 with HTTP; Tue, 9 Oct 2012 09:29:54 -0700 (PDT)
In-Reply-To: 
References: 
	
Date: Tue, 9 Oct 2012 17:29:54 +0100
X-Google-Sender-Auth: Oyki3ZuIqUyr9wy2syy-o4P0fR0
Message-ID: 
From: George Dunlap 
To: Dario Faggioli 
Cc: Marcus Granado ,
	Andre Przywara ,
	Ian Campbell ,
	Anil Madhavapeddy ,
	Andrew Cooper ,
	Juergen Gross ,
	Ian Jackson , xen-devel@lists.xen.org,
	Jan Beulich , Daniel De Graaf ,
	Matt Wilson 
Subject: Re: [Xen-devel] [PATCH 3 of 8] xen: let the (credit) scheduler know
 about `node affinity`
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 5, 2012 at 3:08 PM, Dario Faggioli
 wrote:
> As vcpu-affinity tells where vcpus can run, node-affinity tells
> where a domain's vcpus prefer to run. Respecting vcpu-affinity is
> the primary concern, but honouring node-affinity will likely
> result in some performances benefit.
>
> This change modifies the vcpu load balancing algorithm (for the
> credit scheduler only), introducing a two steps logic.
> During the first step, we use the node-affinity mask. The aim is
> giving precedence to the CPUs where it is known to be preferrable
> for the domain to run. If that fails in finding a valid CPU, the
> node-affinity is just ignored and, in the second step, we fall
> back to using cpu-affinity only.
>
> Signed-off-by: Dario Faggioli 

Looking at the load-balancing code, it makes me think that there is
probably some interesting work to do there in the future; but I think
this patch can go in as it is for now.  So

(Once others' comments are addressed)
Acked-by: George Dunlap 

Do scroll down to read my comments on load balancing...

> @@ -1211,30 +1289,48 @@ csched_runq_steal(int peer_cpu, int cpu,
>       */
>      if ( peer_pcpu != NULL && !is_idle_vcpu(peer_vcpu) )
>      {
> -        list_for_each( iter, &peer_pcpu->runq )
> +        int balance_step;
> +
> +        /*
> +         * Take node-affinity into account. That means, for all the vcpus
> +         * in peer_pcpu's runq, check _first_ if their node-affinity allows
> +         * them to run on cpu. If not, retry the loop considering plain
> +         * vcpu-affinity. Also, notice that as soon as one vcpu is found,
> +         * balancing is considered done, and the vcpu is returned to the
> +         * caller.
> +         */
> +        for_each_csched_balance_step(balance_step)
>          {
> -            speer = __runq_elem(iter);
> +            list_for_each( iter, &peer_pcpu->runq )
> +            {
> +                cpumask_t balance_mask;
>
> -            /*
> -             * If next available VCPU here is not of strictly higher
> -             * priority than ours, this PCPU is useless to us.
> -             */
> -            if ( speer->pri <= pri )
> -                break;
> +                speer = __runq_elem(iter);
>
> -            /* Is this VCPU is runnable on our PCPU? */
> -            vc = speer->vcpu;
> -            BUG_ON( is_idle_vcpu(vc) );
> +                /*
> +                 * If next available VCPU here is not of strictly higher
> +                 * priority than ours, this PCPU is useless to us.
> +                 */
> +                if ( speer->pri <= pri )
> +                    break;
>
> -            if (__csched_vcpu_is_migrateable(vc, cpu))
> -            {
> -                /* We got a candidate. Grab it! */
> -                CSCHED_VCPU_STAT_CRANK(speer, migrate_q);
> -                CSCHED_STAT_CRANK(migrate_queued);
> -                WARN_ON(vc->is_urgent);
> -                __runq_remove(speer);
> -                vc->processor = cpu;
> -                return speer;
> +                /* Is this VCPU runnable on our PCPU? */
> +                vc = speer->vcpu;
> +                BUG_ON( is_idle_vcpu(vc) );
> +
> +                if ( csched_balance_cpumask(vc, balance_step, &balance_mask) )
> +                    continue;

This will have the effect that a vcpu with any node affinity at all
will be stolen before a vcpu with no node affinity: i.e., if you have
a system with 4 nodes, and one vcpu has an affinity to nodes 1-2-3,
another has affinity with only 1, and another has an affinity to all
4, the one which has an affinity to all 4 will be passed over the
first round, while either of the first ones might be nabbed (depending
on what pcpu they're on).

Furthermore, the effect of this whole thing (if I'm reading it right)
will be to go through *each runqueue* twice, rather than checking all
cpus for vcpus with good node affinity, and then all cpus for vcpus
with good cpumasks.

It seems like it would be better to check:
* This node for node-affine work to steal
* Other nodes for node-affine work to steal
* All nodes for cpu-affine work to steal.

Ideally, the search would terminate fairly quickly with the first set,
meaning that in the common case we never even check other nodes.

Going through the cpu list twice means trying to grab the scheduler
lock for each cpu twice; but hopefully that would be made up for by
having a shorter list.

Thoughts?

Like I said, I think this is something to put on our to-do list; this
patch should go in so we can start testing it as soon as possible.

 -George

> +
> +                if (__csched_vcpu_is_migrateable(vc, cpu, &balance_mask))
> +                {
> +                    /* We got a candidate. Grab it! */
> +                    CSCHED_VCPU_STAT_CRANK(speer, migrate_q);
> +                    CSCHED_STAT_CRANK(migrate_queued);
> +                    WARN_ON(vc->is_urgent);
> +                    __runq_remove(speer);
> +                    vc->processor = cpu;
> +                    return speer;
> +                }
>              }
>          }
>      }
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 16:30:06 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 16:30:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLcgv-0004cG-EJ; Tue, 09 Oct 2012 16:29:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLcgu-0004c7-1h
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 16:29:56 +0000
Received: from [85.158.143.99:58132] by server-3.bemta-4.messagelabs.com id
	6F/64-10986-30154705; Tue, 09 Oct 2012 16:29:55 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1349800194!32855271!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4973 invoked from network); 9 Oct 2012 16:29:54 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 16:29:54 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so3930518eek.32
	for ; Tue, 09 Oct 2012 09:29:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=Zb6hap+5o2yXd2INS3A01P4EwPDDoNUWklBuX8YJCC8=;
	b=lvohqtAP/DHiuj8IjPDv/QJWv/ZnVhAp7MlAyKPd8TSuZD3yyVPxXfFiCzJgZNVZf9
	JcbKp1nhaZFZPgalCanZ9OwkQA+iQeCFLHloigRUSyA/XVzFfzPM+J0mDGRsTbEeMGZj
	yGpyjDEFNZ4e4pvd8/MjSue9z18YgfSWXbr2sOmaw8/Jh4qA1iSXOIIdrPtqhtM2Nvkw
	HBfYA8hZoKtGy3w9892bi8NLHSVkl1McMBzAPVtLzAKWIH54ToauaJyOfxW42Xfb7AJB
	+r3UuVssBR3AC6548+V724P8Z10+7Q9avBANVMAMLS1N31sbrxGQG2/LDil7jBWaYyw9
	E6tw==
MIME-Version: 1.0
Received: by 10.14.212.72 with SMTP id x48mr27962213eeo.40.1349800194231; Tue,
	09 Oct 2012 09:29:54 -0700 (PDT)
Received: by 10.14.215.195 with HTTP; Tue, 9 Oct 2012 09:29:54 -0700 (PDT)
In-Reply-To: 
References: 
	
Date: Tue, 9 Oct 2012 17:29:54 +0100
X-Google-Sender-Auth: Oyki3ZuIqUyr9wy2syy-o4P0fR0
Message-ID: 
From: George Dunlap 
To: Dario Faggioli 
Cc: Marcus Granado ,
	Andre Przywara ,
	Ian Campbell ,
	Anil Madhavapeddy ,
	Andrew Cooper ,
	Juergen Gross ,
	Ian Jackson , xen-devel@lists.xen.org,
	Jan Beulich , Daniel De Graaf ,
	Matt Wilson 
Subject: Re: [Xen-devel] [PATCH 3 of 8] xen: let the (credit) scheduler know
 about `node affinity`
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 5, 2012 at 3:08 PM, Dario Faggioli
 wrote:
> As vcpu-affinity tells where vcpus can run, node-affinity tells
> where a domain's vcpus prefer to run. Respecting vcpu-affinity is
> the primary concern, but honouring node-affinity will likely
> result in some performances benefit.
>
> This change modifies the vcpu load balancing algorithm (for the
> credit scheduler only), introducing a two steps logic.
> During the first step, we use the node-affinity mask. The aim is
> giving precedence to the CPUs where it is known to be preferrable
> for the domain to run. If that fails in finding a valid CPU, the
> node-affinity is just ignored and, in the second step, we fall
> back to using cpu-affinity only.
>
> Signed-off-by: Dario Faggioli 

Looking at the load-balancing code, it makes me think that there is
probably some interesting work to do there in the future; but I think
this patch can go in as it is for now.  So

(Once others' comments are addressed)
Acked-by: George Dunlap 

Do scroll down to read my comments on load balancing...

> @@ -1211,30 +1289,48 @@ csched_runq_steal(int peer_cpu, int cpu,
>       */
>      if ( peer_pcpu != NULL && !is_idle_vcpu(peer_vcpu) )
>      {
> -        list_for_each( iter, &peer_pcpu->runq )
> +        int balance_step;
> +
> +        /*
> +         * Take node-affinity into account. That means, for all the vcpus
> +         * in peer_pcpu's runq, check _first_ if their node-affinity allows
> +         * them to run on cpu. If not, retry the loop considering plain
> +         * vcpu-affinity. Also, notice that as soon as one vcpu is found,
> +         * balancing is considered done, and the vcpu is returned to the
> +         * caller.
> +         */
> +        for_each_csched_balance_step(balance_step)
>          {
> -            speer = __runq_elem(iter);
> +            list_for_each( iter, &peer_pcpu->runq )
> +            {
> +                cpumask_t balance_mask;
>
> -            /*
> -             * If next available VCPU here is not of strictly higher
> -             * priority than ours, this PCPU is useless to us.
> -             */
> -            if ( speer->pri <= pri )
> -                break;
> +                speer = __runq_elem(iter);
>
> -            /* Is this VCPU is runnable on our PCPU? */
> -            vc = speer->vcpu;
> -            BUG_ON( is_idle_vcpu(vc) );
> +                /*
> +                 * If next available VCPU here is not of strictly higher
> +                 * priority than ours, this PCPU is useless to us.
> +                 */
> +                if ( speer->pri <= pri )
> +                    break;
>
> -            if (__csched_vcpu_is_migrateable(vc, cpu))
> -            {
> -                /* We got a candidate. Grab it! */
> -                CSCHED_VCPU_STAT_CRANK(speer, migrate_q);
> -                CSCHED_STAT_CRANK(migrate_queued);
> -                WARN_ON(vc->is_urgent);
> -                __runq_remove(speer);
> -                vc->processor = cpu;
> -                return speer;
> +                /* Is this VCPU runnable on our PCPU? */
> +                vc = speer->vcpu;
> +                BUG_ON( is_idle_vcpu(vc) );
> +
> +                if ( csched_balance_cpumask(vc, balance_step, &balance_mask) )
> +                    continue;

This will have the effect that a vcpu with any node affinity at all
will be stolen before a vcpu with no node affinity: i.e., if you have
a system with 4 nodes, and one vcpu has an affinity to nodes 1-2-3,
another has affinity with only 1, and another has an affinity to all
4, the one which has an affinity to all 4 will be passed over the
first round, while either of the first ones might be nabbed (depending
on what pcpu they're on).

Furthermore, the effect of this whole thing (if I'm reading it right)
will be to go through *each runqueue* twice, rather than checking all
cpus for vcpus with good node affinity, and then all cpus for vcpus
with good cpumasks.

It seems like it would be better to check:
* This node for node-affine work to steal
* Other nodes for node-affine work to steal
* All nodes for cpu-affine work to steal.

Ideally, the search would terminate fairly quickly with the first set,
meaning that in the common case we never even check other nodes.

Going through the cpu list twice means trying to grab the scheduler
lock for each cpu twice; but hopefully that would be made up for by
having a shorter list.

Thoughts?

Like I said, I think this is something to put on our to-do list; this
patch should go in so we can start testing it as soon as possible.

 -George

> +
> +                if (__csched_vcpu_is_migrateable(vc, cpu, &balance_mask))
> +                {
> +                    /* We got a candidate. Grab it! */
> +                    CSCHED_VCPU_STAT_CRANK(speer, migrate_q);
> +                    CSCHED_STAT_CRANK(migrate_queued);
> +                    WARN_ON(vc->is_urgent);
> +                    __runq_remove(speer);
> +                    vc->processor = cpu;
> +                    return speer;
> +                }
>              }
>          }
>      }
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 16:39:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 16:39:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLcq7-000517-HJ; Tue, 09 Oct 2012 16:39:27 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLcq6-000512-7S
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 16:39:26 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1349800760!2894118!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9553 invoked from network); 9 Oct 2012 16:39:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 16:39:20 -0000
X-IronPort-AV: E=Sophos;i="4.80,561,1344211200"; d="scan'208";a="15046111"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 16:39:20 +0000
Received: from [192.168.1.140] (10.31.3.235) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	17:39:19 +0100
Message-ID: <50745336.5080101@citrix.com>
Date: Tue, 9 Oct 2012 18:39:18 +0200
From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Jan Beulich 
References: <1348242767-23732-1-git-send-email-oliver.chick@citrix.com>
	<506061E6020000780009D4AB@nat28.tlf.novell.com>
In-Reply-To: <506061E6020000780009D4AB@nat28.tlf.novell.com>
Cc: "Oliver Chick \(Intern\)" ,
	"xen-devel@lists.xen.org" ,
	"linux-kernel@vger.kernel.org" ,
	"konrad.wilk@oracle.com" 
Subject: Re: [Xen-devel] [PATCH v2] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 24/09/12 13:36, Jan Beulich wrote:
>>>> On 21.09.12 at 17:52, Oliver Chick  wrote:
>> Changes since v1:
>>
>>  * Maximum number of persistent grants per device now 64, rather than
>>    256, as this is the actual maxmimum request in a (1 page) ring.
> 
> As said previously, I don't see why this needs to have a separate
> #define at all - it's simply __RING_SIZE(). No adding this would
> also imply that - apart from perhaps documenting the new xenstore
> nodes - io/blkif.h would need changing at all (which otherwise would
> require a hypervisor side patch to be submitted too).

I've been working on this a little bit more, and __RING_SIZE returns 32
for all ring types (blkif, blkif_x86_32 and blkif_x86_64), any specific
reason to choose __RING_SIZE()*2?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 16:39:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 16:39:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLcq7-000517-HJ; Tue, 09 Oct 2012 16:39:27 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLcq6-000512-7S
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 16:39:26 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1349800760!2894118!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9553 invoked from network); 9 Oct 2012 16:39:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 16:39:20 -0000
X-IronPort-AV: E=Sophos;i="4.80,561,1344211200"; d="scan'208";a="15046111"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 16:39:20 +0000
Received: from [192.168.1.140] (10.31.3.235) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	17:39:19 +0100
Message-ID: <50745336.5080101@citrix.com>
Date: Tue, 9 Oct 2012 18:39:18 +0200
From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Jan Beulich 
References: <1348242767-23732-1-git-send-email-oliver.chick@citrix.com>
	<506061E6020000780009D4AB@nat28.tlf.novell.com>
In-Reply-To: <506061E6020000780009D4AB@nat28.tlf.novell.com>
Cc: "Oliver Chick \(Intern\)" ,
	"xen-devel@lists.xen.org" ,
	"linux-kernel@vger.kernel.org" ,
	"konrad.wilk@oracle.com" 
Subject: Re: [Xen-devel] [PATCH v2] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 24/09/12 13:36, Jan Beulich wrote:
>>>> On 21.09.12 at 17:52, Oliver Chick  wrote:
>> Changes since v1:
>>
>>  * Maximum number of persistent grants per device now 64, rather than
>>    256, as this is the actual maxmimum request in a (1 page) ring.
> 
> As said previously, I don't see why this needs to have a separate
> #define at all - it's simply __RING_SIZE(). No adding this would
> also imply that - apart from perhaps documenting the new xenstore
> nodes - io/blkif.h would need changing at all (which otherwise would
> require a hypervisor side patch to be submitted too).

I've been working on this a little bit more, and __RING_SIZE returns 32
for all ring types (blkif, blkif_x86_32 and blkif_x86_64), any specific
reason to choose __RING_SIZE()*2?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 16:42:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 16:42:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLcsr-00057P-3R; Tue, 09 Oct 2012 16:42:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLcsp-00057F-LT
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 16:42:15 +0000
Received: from [85.158.139.211:63335] by server-9.bemta-5.messagelabs.com id
	F1/50-14846-6E354705; Tue, 09 Oct 2012 16:42:14 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1349800932!20658842!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgwMTY3NA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4067 invoked from network); 9 Oct 2012 16:42:14 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Oct 2012 16:42:14 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q99Gg9qT017216
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 9 Oct 2012 16:42:10 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q99Gg8bj020213
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 9 Oct 2012 16:42:09 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q99Gg8gN032201; Tue, 9 Oct 2012 11:42:08 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 09 Oct 2012 09:42:08 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 465364031E; Tue,  9 Oct 2012 12:30:23 -0400 (EDT)
Date: Tue, 9 Oct 2012 12:30:23 -0400
From: Konrad Rzeszutek Wilk 
To: David Vrabel 
Message-ID: <20121009163023.GG31499@phenom.dumpdata.com>
References: <1348243464-15903-1-git-send-email-david.vrabel@citrix.com>
	<1348243464-15903-3-git-send-email-david.vrabel@citrix.com>
	<5061EFB2.1080407@citrix.com> <5069D097.60606@citrix.com>
	<20121002200255.GA668@phenom.dumpdata.com>
	<506EC79D.5080206@citrix.com>
	<506EE6CD020000780009FF4E@nat28.tlf.novell.com>
	<506F0370.6050905@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <506F0370.6050905@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 2/6] xen-blkfront: handle backend CLOSED
	without CLOSING
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 05, 2012 at 04:57:36PM +0100, David Vrabel wrote:
> On 05/10/12 12:55, Jan Beulich wrote:
> >>>> On 05.10.12 at 13:42, David Vrabel  wrote:
> >> On 02/10/12 21:02, Konrad Rzeszutek Wilk wrote:
> >>> On Mon, Oct 01, 2012 at 06:19:19PM +0100, David Vrabel wrote:
> >>>> On 25/09/12 18:53, David Vrabel wrote:
> >>>>> On 21/09/12 17:04, David Vrabel wrote:
> >>>>>> From: David Vrabel 
> >>>>>>
> >>>>>> Backend drivers shouldn't transistion to CLOSED unless the frontend is
> >>>>>> CLOSED.  If a backend does transition to CLOSED too soon then the
> >>>>>> frontend may not see the CLOSING state and will not properly shutdown.
> >>>>>>
> >>>>>> So, treat an unexpected backend CLOSED state the same as CLOSING.
> >>>>>
> >>>>> Didn't handle the frontend block device being mounted. Updated patch here.
> >>>>
> >>>> Konrad, can you ack this updated patch if you're happy with it.
> >>>
> >>> Acked-by: Konrad Rzeszutek Wilk 
> >>>
> >>> Or should I just carry it in my for-jens-3.7 bug-fixes queue and ask
> >>> Jen to pull it once rc0 is out?
> >>
> >> This seems easiest, if Jan is happy with the patch.
> > 
> > I see the point of your explanation yesterday, but am still not
> > convinced that the early cleanup in spite of active users of the
> > disk can't cause any problems (like dangling pointers or NULL
> > dereferences).
> 
> I tested it some more and it is broken.  Please apply the first version
> instead.

OK, can we do this once more - can you repost the patches, but CC the
invidiual maintainers? The FB and KBD need to go through Florian I think?

> 
> blkfront needs to cancel and complete with an error requests that are
> are still on the ring after the backend has disconnected and it needs to
> complete with an error all requests submitted while disconnected.
> Otherwise, if there is outstanding requests or new requests then
> del_gendisk() blocks waiting for the I/O to complete.
> 
> David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 16:42:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 16:42:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLcsr-00057P-3R; Tue, 09 Oct 2012 16:42:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLcsp-00057F-LT
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 16:42:15 +0000
Received: from [85.158.139.211:63335] by server-9.bemta-5.messagelabs.com id
	F1/50-14846-6E354705; Tue, 09 Oct 2012 16:42:14 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1349800932!20658842!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgwMTY3NA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4067 invoked from network); 9 Oct 2012 16:42:14 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Oct 2012 16:42:14 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q99Gg9qT017216
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 9 Oct 2012 16:42:10 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q99Gg8bj020213
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 9 Oct 2012 16:42:09 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q99Gg8gN032201; Tue, 9 Oct 2012 11:42:08 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 09 Oct 2012 09:42:08 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 465364031E; Tue,  9 Oct 2012 12:30:23 -0400 (EDT)
Date: Tue, 9 Oct 2012 12:30:23 -0400
From: Konrad Rzeszutek Wilk 
To: David Vrabel 
Message-ID: <20121009163023.GG31499@phenom.dumpdata.com>
References: <1348243464-15903-1-git-send-email-david.vrabel@citrix.com>
	<1348243464-15903-3-git-send-email-david.vrabel@citrix.com>
	<5061EFB2.1080407@citrix.com> <5069D097.60606@citrix.com>
	<20121002200255.GA668@phenom.dumpdata.com>
	<506EC79D.5080206@citrix.com>
	<506EE6CD020000780009FF4E@nat28.tlf.novell.com>
	<506F0370.6050905@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <506F0370.6050905@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 2/6] xen-blkfront: handle backend CLOSED
	without CLOSING
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 05, 2012 at 04:57:36PM +0100, David Vrabel wrote:
> On 05/10/12 12:55, Jan Beulich wrote:
> >>>> On 05.10.12 at 13:42, David Vrabel  wrote:
> >> On 02/10/12 21:02, Konrad Rzeszutek Wilk wrote:
> >>> On Mon, Oct 01, 2012 at 06:19:19PM +0100, David Vrabel wrote:
> >>>> On 25/09/12 18:53, David Vrabel wrote:
> >>>>> On 21/09/12 17:04, David Vrabel wrote:
> >>>>>> From: David Vrabel 
> >>>>>>
> >>>>>> Backend drivers shouldn't transistion to CLOSED unless the frontend is
> >>>>>> CLOSED.  If a backend does transition to CLOSED too soon then the
> >>>>>> frontend may not see the CLOSING state and will not properly shutdown.
> >>>>>>
> >>>>>> So, treat an unexpected backend CLOSED state the same as CLOSING.
> >>>>>
> >>>>> Didn't handle the frontend block device being mounted. Updated patch here.
> >>>>
> >>>> Konrad, can you ack this updated patch if you're happy with it.
> >>>
> >>> Acked-by: Konrad Rzeszutek Wilk 
> >>>
> >>> Or should I just carry it in my for-jens-3.7 bug-fixes queue and ask
> >>> Jen to pull it once rc0 is out?
> >>
> >> This seems easiest, if Jan is happy with the patch.
> > 
> > I see the point of your explanation yesterday, but am still not
> > convinced that the early cleanup in spite of active users of the
> > disk can't cause any problems (like dangling pointers or NULL
> > dereferences).
> 
> I tested it some more and it is broken.  Please apply the first version
> instead.

OK, can we do this once more - can you repost the patches, but CC the
invidiual maintainers? The FB and KBD need to go through Florian I think?

> 
> blkfront needs to cancel and complete with an error requests that are
> are still on the ring after the backend has disconnected and it needs to
> complete with an error all requests submitted while disconnected.
> Otherwise, if there is outstanding requests or new requests then
> del_gendisk() blocks waiting for the I/O to complete.
> 
> David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 16:43:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 16:43:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLctf-0005Bn-Hd; Tue, 09 Oct 2012 16:43:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLctd-0005Ba-U9
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 16:43:06 +0000
Received: from [85.158.137.99:60887] by server-2.bemta-3.messagelabs.com id
	FD/51-16514-91454705; Tue, 09 Oct 2012 16:43:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1349800984!20897509!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27119 invoked from network); 9 Oct 2012 16:43:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 16:43:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,561,1344211200"; d="scan'208";a="15046190"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 16:43:03 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	17:43:03 +0100
Message-ID: <1349800982.21847.226.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Ian Jackson 
Date: Tue, 9 Oct 2012 17:43:02 +0100
In-Reply-To: <1349800059-18689-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1349776105.21847.112.camel@zakaz.uk.xensource.com>
	<1349800059-18689-1-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH v2 0/3] docs,
 build: Do not ignore install-docs errors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-09 at 17:27 +0100, Ian Jackson wrote:
> Changes in v2: new patches to tolerate missing fig2dev and pod2text,
> which is necessary to avoid turning the failure to find fig2dev from
> an error ignored in the wrong way into a fatal error.  So this is now
> a 3-patch series.  3/3 is the unchanged patch from before.

All three:
Acked-by: Ian Campbell 

I am running them all through my usual pre-commit tests then I'll push,
hopefully we should then get staging push overnight.

Ian.
> 
>  1/3 docs, build: Tolerate missing fig2dev
>  2/3 docs, build: Tolerate missing pod2text
>  3/3 docs, build: Do not ignore install-docs errors
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 16:43:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 16:43:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLctf-0005Bn-Hd; Tue, 09 Oct 2012 16:43:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLctd-0005Ba-U9
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 16:43:06 +0000
Received: from [85.158.137.99:60887] by server-2.bemta-3.messagelabs.com id
	FD/51-16514-91454705; Tue, 09 Oct 2012 16:43:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1349800984!20897509!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27119 invoked from network); 9 Oct 2012 16:43:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 16:43:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,561,1344211200"; d="scan'208";a="15046190"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 16:43:03 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	17:43:03 +0100
Message-ID: <1349800982.21847.226.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Ian Jackson 
Date: Tue, 9 Oct 2012 17:43:02 +0100
In-Reply-To: <1349800059-18689-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1349776105.21847.112.camel@zakaz.uk.xensource.com>
	<1349800059-18689-1-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH v2 0/3] docs,
 build: Do not ignore install-docs errors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-09 at 17:27 +0100, Ian Jackson wrote:
> Changes in v2: new patches to tolerate missing fig2dev and pod2text,
> which is necessary to avoid turning the failure to find fig2dev from
> an error ignored in the wrong way into a fatal error.  So this is now
> a 3-patch series.  3/3 is the unchanged patch from before.

All three:
Acked-by: Ian Campbell 

I am running them all through my usual pre-commit tests then I'll push,
hopefully we should then get staging push overnight.

Ian.
> 
>  1/3 docs, build: Tolerate missing fig2dev
>  2/3 docs, build: Tolerate missing pod2text
>  3/3 docs, build: Do not ignore install-docs errors
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 16:44:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 16:44:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLcuW-0005HG-Vi; Tue, 09 Oct 2012 16:44:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLcuV-0005H1-K1
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 16:43:59 +0000
Received: from [85.158.139.83:14390] by server-9.bemta-5.messagelabs.com id
	64/92-14846-E4454705; Tue, 09 Oct 2012 16:43:58 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1349801036!31905807!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzUyMTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10324 invoked from network); 9 Oct 2012 16:43:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 16:43:58 -0000
X-IronPort-AV: E=Sophos;i="4.80,561,1344211200"; d="scan'208";a="40622671"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 16:43:50 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 9 Oct 2012 12:43:50 -0400
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TLcuL-0003YE-TN;
	Tue, 09 Oct 2012 17:43:49 +0100
Message-ID: <50745445.3090007@citrix.com>
Date: Tue, 9 Oct 2012 17:43:49 +0100
From: Andrew Cooper 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" , 
	Ian Campbell 
X-Enigmail-Version: 1.4.4
Content-Type: multipart/mixed; boundary="------------050101020306000705080509"
Subject: [Xen-devel] docs/version [4.2 only] Correct version string
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------050101020306000705080509
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

This is the minimal fix to correct 4.2.  I will submit a separate patch
for unstable

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------050101020306000705080509
Content-Type: text/x-patch; name="docs-version.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="docs-version.patch"

# HG changeset patch
# Parent 5fbdbf585f5f2ee9a3e3c75a8a9f9f2cc6eda65c
docs/version: Correct docs version for 4.2

Signed-off-by: Andrew Cooper 

diff -r 5fbdbf585f5f docs/Makefile
--- a/docs/Makefile
+++ b/docs/Makefile
@@ -4,7 +4,7 @@ XEN_ROOT=$(CURDIR)/..
 include $(XEN_ROOT)/Config.mk
 include $(XEN_ROOT)/docs/Docs.mk
 
-VERSION		= xen-unstable
+VERSION		= xen-4.2
 
 DOC_MAN5SRC	:= $(wildcard man/*.pod.5)
 DOC_MAN1SRC	:= $(wildcard man/*.pod.1)

--------------050101020306000705080509
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------050101020306000705080509--


From xen-devel-bounces@lists.xen.org Tue Oct 09 16:44:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 16:44:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLcuW-0005HG-Vi; Tue, 09 Oct 2012 16:44:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLcuV-0005H1-K1
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 16:43:59 +0000
Received: from [85.158.139.83:14390] by server-9.bemta-5.messagelabs.com id
	64/92-14846-E4454705; Tue, 09 Oct 2012 16:43:58 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1349801036!31905807!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzUyMTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10324 invoked from network); 9 Oct 2012 16:43:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 16:43:58 -0000
X-IronPort-AV: E=Sophos;i="4.80,561,1344211200"; d="scan'208";a="40622671"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 16:43:50 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 9 Oct 2012 12:43:50 -0400
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TLcuL-0003YE-TN;
	Tue, 09 Oct 2012 17:43:49 +0100
Message-ID: <50745445.3090007@citrix.com>
Date: Tue, 9 Oct 2012 17:43:49 +0100
From: Andrew Cooper 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" , 
	Ian Campbell 
X-Enigmail-Version: 1.4.4
Content-Type: multipart/mixed; boundary="------------050101020306000705080509"
Subject: [Xen-devel] docs/version [4.2 only] Correct version string
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------050101020306000705080509
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

This is the minimal fix to correct 4.2.  I will submit a separate patch
for unstable

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------050101020306000705080509
Content-Type: text/x-patch; name="docs-version.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="docs-version.patch"

# HG changeset patch
# Parent 5fbdbf585f5f2ee9a3e3c75a8a9f9f2cc6eda65c
docs/version: Correct docs version for 4.2

Signed-off-by: Andrew Cooper 

diff -r 5fbdbf585f5f docs/Makefile
--- a/docs/Makefile
+++ b/docs/Makefile
@@ -4,7 +4,7 @@ XEN_ROOT=$(CURDIR)/..
 include $(XEN_ROOT)/Config.mk
 include $(XEN_ROOT)/docs/Docs.mk
 
-VERSION		= xen-unstable
+VERSION		= xen-4.2
 
 DOC_MAN5SRC	:= $(wildcard man/*.pod.5)
 DOC_MAN1SRC	:= $(wildcard man/*.pod.1)

--------------050101020306000705080509
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------050101020306000705080509--


From xen-devel-bounces@lists.xen.org Tue Oct 09 16:47:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 16:47:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLcxq-0005Xl-9e; Tue, 09 Oct 2012 16:47:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLcxo-0005Xf-DJ
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 16:47:24 +0000
Received: from [85.158.139.83:44863] by server-16.bemta-5.messagelabs.com id
	04/7D-21637-B1554705; Tue, 09 Oct 2012 16:47:23 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1349801242!26770246!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30460 invoked from network); 9 Oct 2012 16:47:22 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 16:47:22 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so3945568eek.32
	for ; Tue, 09 Oct 2012 09:47:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=7fuUyL+niK+HQ5/qorW6uUo5ZBmBy+BjIPYXvt35vDI=;
	b=DsFlJyEnBBlUcC/7rXgCs8riwpIo1qqYTip2We9cKbGKeeiJNI3ETTKgCjhP/nsgSW
	15lkyVlf3uisJnq7360eFXrN9W2ggm0kexK3JNquAj33xFS9C+Z+g695+o2Vui/2IFKq
	yVVPkVBjn93g5nme1p4sYCKN2F5RXFFuDAUzIy0cgXAXOP4GqrR2XBiK8YE0O1jZQygT
	b9IqdKD/kh2yMZd5MRVBXDE3SX0TZShsf8RR3ayZV1uS5Szlm1TMnoHjvKCuDv5nD+vo
	Z00CdQBCuxTvfdmwAFIKFftLgiLiTPklrKZ2rULNxjXrYS44HJcBfZLeHrHexfg3OmDP
	32tw==
MIME-Version: 1.0
Received: by 10.14.223.199 with SMTP id v47mr1649604eep.45.1349801242165; Tue,
	09 Oct 2012 09:47:22 -0700 (PDT)
Received: by 10.14.215.195 with HTTP; Tue, 9 Oct 2012 09:47:22 -0700 (PDT)
In-Reply-To: <12134421b216e9c8eef6.1349446102@Solace>
References: 
	<12134421b216e9c8eef6.1349446102@Solace>
Date: Tue, 9 Oct 2012 17:47:22 +0100
X-Google-Sender-Auth: knK9h9-jYz6gDZ00wI6jCsnBbqs
Message-ID: 
From: George Dunlap 
To: Dario Faggioli 
Cc: Marcus Granado ,
	Andre Przywara ,
	Ian Campbell ,
	Anil Madhavapeddy ,
	Andrew Cooper ,
	Juergen Gross ,
	Ian Jackson , xen-devel@lists.xen.org,
	Jan Beulich , Daniel De Graaf ,
	Matt Wilson 
Subject: Re: [Xen-devel] [PATCH 4 of 8] xen: allow for explicitly specifying
	node-affinity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 5, 2012 at 3:08 PM, Dario Faggioli
 wrote:
> Make it possible to pass the node-affinity of a domain to the hypervisor
> from the upper layers, instead of always being computed automatically.
>
> Note that this also required generalizing the Flask hooks for setting
> and getting the affinity, so that they now deal with both vcpu and
> node affinity.
>
> Signed-off-by: Dario Faggioli 
>
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -222,6 +222,7 @@ struct domain *domain_create(
>
>      spin_lock_init(&d->node_affinity_lock);
>      d->node_affinity = NODE_MASK_ALL;
> +    d->auto_node_affinity = 1;
>
>      spin_lock_init(&d->shutdown_lock);
>      d->shutdown_code = -1;
> @@ -362,11 +363,26 @@ void domain_update_node_affinity(struct
>          cpumask_or(cpumask, cpumask, online_affinity);
>      }
>
> -    for_each_online_node ( node )
> -        if ( cpumask_intersects(&node_to_cpumask(node), cpumask) )
> -            node_set(node, nodemask);
> +    if ( d->auto_node_affinity )
> +    {
> +        /* Node-affinity is automaically computed from all vcpu-affinities */
> +        for_each_online_node ( node )
> +            if ( cpumask_intersects(&node_to_cpumask(node), cpumask) )
> +                node_set(node, nodemask);
>
> -    d->node_affinity = nodemask;
> +        d->node_affinity = nodemask;
> +    }
> +    else
> +    {
> +        /* Node-affinity is provided by someone else, just filter out cpus
> +         * that are either offline or not in the affinity of any vcpus. */
> +        for_each_node_mask ( node, d->node_affinity )
> +            if ( !cpumask_intersects(&node_to_cpumask(node), cpumask) )
> +                node_clear(node, d->node_affinity);
> +    }
> +
> +    sched_set_node_affinity(d, &d->node_affinity);
> +
>      spin_unlock(&d->node_affinity_lock);
>
>      free_cpumask_var(online_affinity);
> @@ -374,6 +390,36 @@ void domain_update_node_affinity(struct
>  }
>
>
> +int domain_set_node_affinity(struct domain *d, const nodemask_t *affinity)
> +{
> +    /* Being affine with no nodes is just wrong */
> +    if ( nodes_empty(*affinity) )
> +        return -EINVAL;
> +
> +    spin_lock(&d->node_affinity_lock);
> +
> +    /*
> +     * Being/becoming explicitly affine to all nodes is not particularly
> +     * useful. Let's take it as the `reset node affinity` command.
> +     */
> +    if ( nodes_full(*affinity) )
> +    {
> +        d->auto_node_affinity = 1;
> +        goto out;
> +    }
> +
> +    d->auto_node_affinity = 0;
> +    d->node_affinity = *affinity;
> +
> +out:
> +    spin_unlock(&d->node_affinity_lock);
> +
> +    domain_update_node_affinity(d);
> +
> +    return 0;
> +}
> +
> +
>  struct domain *get_domain_by_id(domid_t dom)
>  {
>      struct domain *d;
> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -642,6 +642,40 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
>      }
>      break;
>
> +    case XEN_DOMCTL_setnodeaffinity:
> +    case XEN_DOMCTL_getnodeaffinity:
> +    {
> +        domid_t dom = op->domain;
> +        struct domain *d = rcu_lock_domain_by_id(dom);
> +
> +        ret = -ESRCH;
> +        if ( d == NULL )
> +            break;
> +
> +        ret = xsm_nodeaffinity(op->cmd, d);
> +        if ( ret )
> +            goto nodeaffinity_out;
> +
> +        if ( op->cmd == XEN_DOMCTL_setnodeaffinity )
> +        {
> +            nodemask_t new_affinity;
> +
> +            ret = xenctl_bitmap_to_nodemask(&new_affinity,
> +                                            &op->u.nodeaffinity.nodemap);
> +            if ( !ret )
> +                ret = domain_set_node_affinity(d, &new_affinity);
> +        }
> +        else
> +        {
> +            ret = nodemask_to_xenctl_bitmap(&op->u.nodeaffinity.nodemap,
> +                                            &d->node_affinity);
> +        }
> +
> +    nodeaffinity_out:
> +        rcu_unlock_domain(d);
> +    }
> +    break;
> +
>      case XEN_DOMCTL_setvcpuaffinity:
>      case XEN_DOMCTL_getvcpuaffinity:
>      {
> diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
> --- a/xen/common/keyhandler.c
> +++ b/xen/common/keyhandler.c
> @@ -217,6 +217,14 @@ static void cpuset_print(char *set, int
>      *set++ = '\0';
>  }
>
> +static void nodeset_print(char *set, int size, const nodemask_t *mask)
> +{
> +    *set++ = '[';
> +    set += nodelist_scnprintf(set, size-2, mask);
> +    *set++ = ']';
> +    *set++ = '\0';
> +}
> +
>  static void periodic_timer_print(char *str, int size, uint64_t period)
>  {
>      if ( period == 0 )
> @@ -272,6 +280,9 @@ static void dump_domains(unsigned char k
>
>          dump_pageframe_info(d);
>
> +        nodeset_print(tmpstr, sizeof(tmpstr), &d->node_affinity);
> +        printk("NODE affinity for domain %d: %s\n", d->domain_id, tmpstr);
> +
>          printk("VCPU information and callbacks for domain %u:\n",
>                 d->domain_id);
>          for_each_vcpu ( d, v )
> diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
> --- a/xen/common/sched_credit.c
> +++ b/xen/common/sched_credit.c
> @@ -238,6 +238,33 @@ static inline void
>      list_del_init(&svc->runq_elem);
>  }
>
> +/*
> + * Translates node-affinity mask into a cpumask, so that we can use it during
> + * actual scheduling. That of course will contain all the cpus from all the
> + * set nodes in the original node-affinity mask.
> + *
> + * Note that any serialization needed to access mask safely is complete
> + * responsibility of the caller of this function/hook.
> + */
> +static void csched_set_node_affinity(
> +    const struct scheduler *ops,
> +    struct domain *d,
> +    nodemask_t *mask)
> +{
> +    struct csched_dom *sdom;
> +    int node;
> +
> +    /* Skip idle domain since it doesn't even have a node_affinity_cpumask */
> +    if ( unlikely(is_idle_domain(d)) )
> +        return;
> +
> +    sdom = CSCHED_DOM(d);
> +    cpumask_clear(sdom->node_affinity_cpumask);
> +    for_each_node_mask( node, *mask )
> +        cpumask_or(sdom->node_affinity_cpumask, sdom->node_affinity_cpumask,
> +                   &node_to_cpumask(node));
> +}
> +
>  #define for_each_csched_balance_step(__step) \
>      for ( (__step) = CSCHED_BALANCE_LAST; (__step) >= 0; (__step)-- )
>
> @@ -260,7 +287,8 @@ csched_balance_cpumask(const struct vcpu
>          struct domain *d = vc->domain;
>          struct csched_dom *sdom = CSCHED_DOM(d);
>
> -        if ( cpumask_full(sdom->node_affinity_cpumask) )
> +        if ( cpumask_full(sdom->node_affinity_cpumask) ||
> +             d->auto_node_affinity == 1 )
>              return -1;
>
>          cpumask_and(mask, sdom->node_affinity_cpumask, vc->cpu_affinity);
> @@ -1786,6 +1814,8 @@ const struct scheduler sched_credit_def
>      .adjust         = csched_dom_cntl,
>      .adjust_global  = csched_sys_cntl,
>
> +    .set_node_affinity  = csched_set_node_affinity,
> +
>      .pick_cpu       = csched_cpu_pick,
>      .do_schedule    = csched_schedule,
>
> diff --git a/xen/common/schedule.c b/xen/common/schedule.c
> --- a/xen/common/schedule.c
> +++ b/xen/common/schedule.c
> @@ -588,6 +588,11 @@ int cpu_disable_scheduler(unsigned int c
>      return ret;
>  }
>
> +void sched_set_node_affinity(struct domain *d, nodemask_t *mask)
> +{
> +    SCHED_OP(DOM2OP(d), set_node_affinity, d, mask);
> +}
> +
>  int vcpu_set_affinity(struct vcpu *v, const cpumask_t *affinity)
>  {
>      cpumask_t online_affinity;
> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -279,6 +279,16 @@ typedef struct xen_domctl_getvcpuinfo xe
>  DEFINE_XEN_GUEST_HANDLE(xen_domctl_getvcpuinfo_t);
>
>
> +/* Get/set the NUMA node(s) with which the guest has affinity with. */
> +/* XEN_DOMCTL_setnodeaffinity */
> +/* XEN_DOMCTL_getnodeaffinity */
> +struct xen_domctl_nodeaffinity {
> +    struct xenctl_bitmap nodemap;/* IN */
> +};
> +typedef struct xen_domctl_nodeaffinity xen_domctl_nodeaffinity_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_domctl_nodeaffinity_t);
> +
> +
>  /* Get/set which physical cpus a vcpu can execute on. */
>  /* XEN_DOMCTL_setvcpuaffinity */
>  /* XEN_DOMCTL_getvcpuaffinity */
> @@ -900,6 +910,8 @@ struct xen_domctl {
>  #define XEN_DOMCTL_set_access_required           64
>  #define XEN_DOMCTL_audit_p2m                     65
>  #define XEN_DOMCTL_set_virq_handler              66
> +#define XEN_DOMCTL_setnodeaffinity               67
> +#define XEN_DOMCTL_getnodeaffinity               68
>  #define XEN_DOMCTL_gdbsx_guestmemio            1000
>  #define XEN_DOMCTL_gdbsx_pausevcpu             1001
>  #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
> @@ -913,6 +925,7 @@ struct xen_domctl {
>          struct xen_domctl_getpageframeinfo  getpageframeinfo;
>          struct xen_domctl_getpageframeinfo2 getpageframeinfo2;
>          struct xen_domctl_getpageframeinfo3 getpageframeinfo3;
> +        struct xen_domctl_nodeaffinity      nodeaffinity;
>          struct xen_domctl_vcpuaffinity      vcpuaffinity;
>          struct xen_domctl_shadow_op         shadow_op;
>          struct xen_domctl_max_mem           max_mem;
> diff --git a/xen/include/xen/nodemask.h b/xen/include/xen/nodemask.h
> --- a/xen/include/xen/nodemask.h
> +++ b/xen/include/xen/nodemask.h
> @@ -8,8 +8,9 @@
>   * See detailed comments in the file linux/bitmap.h describing the
>   * data type on which these nodemasks are based.
>   *
> - * For details of nodemask_scnprintf() and nodemask_parse(),
> - * see bitmap_scnprintf() and bitmap_parse() in lib/bitmap.c.
> + * For details of nodemask_scnprintf(), nodelist_scnpintf() and
> + * nodemask_parse(), see bitmap_scnprintf() and bitmap_parse()
> + * in lib/bitmap.c.
>   *
>   * The available nodemask operations are:
>   *
> @@ -48,6 +49,7 @@
>   * unsigned long *nodes_addr(mask)     Array of unsigned long's in mask
>   *
>   * int nodemask_scnprintf(buf, len, mask) Format nodemask for printing
> + * int nodelist_scnprintf(buf, len, mask) Format nodemask as a list for printing
>   * int nodemask_parse(ubuf, ulen, mask)        Parse ascii string as nodemask
>   *
>   * for_each_node_mask(node, mask)      for-loop node over mask
> @@ -280,6 +282,14 @@ static inline int __first_unset_node(con
>
>  #define nodes_addr(src) ((src).bits)
>
> +#define nodelist_scnprintf(buf, len, src) \
> +                       __nodelist_scnprintf((buf), (len), (src), MAX_NUMNODES)
> +static inline int __nodelist_scnprintf(char *buf, int len,
> +                                       const nodemask_t *srcp, int nbits)
> +{
> +       return bitmap_scnlistprintf(buf, len, srcp->bits, nbits);
> +}
> +
>  #if 0
>  #define nodemask_scnprintf(buf, len, src) \
>                         __nodemask_scnprintf((buf), (len), &(src), MAX_NUMNODES)
> diff --git a/xen/include/xen/sched-if.h b/xen/include/xen/sched-if.h
> --- a/xen/include/xen/sched-if.h
> +++ b/xen/include/xen/sched-if.h
> @@ -182,6 +182,8 @@ struct scheduler {
>                                      struct xen_domctl_scheduler_op *);
>      int          (*adjust_global)  (const struct scheduler *,
>                                      struct xen_sysctl_scheduler_op *);
> +    void         (*set_node_affinity) (const struct scheduler *,
> +                                       struct domain *, nodemask_t *);
>      void         (*dump_settings)  (const struct scheduler *);
>      void         (*dump_cpu_state) (const struct scheduler *, int);
>
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -346,8 +346,12 @@ struct domain
>      /* Various mem_events */
>      struct mem_event_per_domain *mem_event;
>
> -    /* Currently computed from union of all vcpu cpu-affinity masks. */
> +    /*
> +     * Can be specified by the user. If that is not the case, it is
> +     * computed from the union of all the vcpu cpu-affinity masks.
> +     */
>      nodemask_t node_affinity;
> +    int auto_node_affinity;
>      unsigned int last_alloc_node;
>      spinlock_t node_affinity_lock;
>  };
> @@ -416,6 +420,7 @@ static inline void get_knownalive_domain
>      ASSERT(!(atomic_read(&d->refcnt) & DOMAIN_DESTROYED));
>  }
>
> +int domain_set_node_affinity(struct domain *d, const nodemask_t *affinity);
>  void domain_update_node_affinity(struct domain *d);
>
>  struct domain *domain_create(
> @@ -519,6 +524,7 @@ void sched_destroy_domain(struct domain
>  int sched_move_domain(struct domain *d, struct cpupool *c);
>  long sched_adjust(struct domain *, struct xen_domctl_scheduler_op *);
>  long sched_adjust_global(struct xen_sysctl_scheduler_op *);
> +void sched_set_node_affinity(struct domain *, nodemask_t *);
>  int  sched_id(void);
>  void sched_tick_suspend(void);
>  void sched_tick_resume(void);
> diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
> --- a/xen/include/xsm/xsm.h
> +++ b/xen/include/xsm/xsm.h
> @@ -56,6 +56,7 @@ struct xsm_operations {
>      int (*domain_create) (struct domain *d, u32 ssidref);
>      int (*max_vcpus) (struct domain *d);
>      int (*destroydomain) (struct domain *d);
> +    int (*nodeaffinity) (int cmd, struct domain *d);
>      int (*vcpuaffinity) (int cmd, struct domain *d);
>      int (*scheduler) (struct domain *d);
>      int (*getdomaininfo) (struct domain *d);
> @@ -229,6 +230,11 @@ static inline int xsm_destroydomain (str
>      return xsm_call(destroydomain(d));
>  }
>
> +static inline int xsm_nodeaffinity (int cmd, struct domain *d)
> +{
> +    return xsm_call(nodeaffinity(cmd, d));
> +}
> +
>  static inline int xsm_vcpuaffinity (int cmd, struct domain *d)
>  {
>      return xsm_call(vcpuaffinity(cmd, d));
> diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
> --- a/xen/xsm/dummy.c
> +++ b/xen/xsm/dummy.c
> @@ -634,6 +634,7 @@ void xsm_fixup_ops (struct xsm_operation
>      set_to_dummy_if_null(ops, domain_create);
>      set_to_dummy_if_null(ops, max_vcpus);
>      set_to_dummy_if_null(ops, destroydomain);
> +    set_to_dummy_if_null(ops, nodeaffinity);
>      set_to_dummy_if_null(ops, vcpuaffinity);
>      set_to_dummy_if_null(ops, scheduler);
>      set_to_dummy_if_null(ops, getdomaininfo);
> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -521,17 +521,19 @@ static int flask_destroydomain(struct do
>                             DOMAIN__DESTROY);
>  }
>
> -static int flask_vcpuaffinity(int cmd, struct domain *d)
> +static int flask_affinity(int cmd, struct domain *d)
>  {
>      u32 perm;
>
>      switch ( cmd )
>      {
>      case XEN_DOMCTL_setvcpuaffinity:
> -        perm = DOMAIN__SETVCPUAFFINITY;
> +    case XEN_DOMCTL_setnodeaffinity:
> +        perm = DOMAIN__SETAFFINITY;
>          break;
>      case XEN_DOMCTL_getvcpuaffinity:
> -        perm = DOMAIN__GETVCPUAFFINITY;
> +    case XEN_DOMCTL_getnodeaffinity:
> +        perm = DOMAIN__GETAFFINITY;
>          break;
>      default:
>          return -EPERM;
> @@ -1473,7 +1475,8 @@ static struct xsm_operations flask_ops =
>      .domain_create = flask_domain_create,
>      .max_vcpus = flask_max_vcpus,
>      .destroydomain = flask_destroydomain,
> -    .vcpuaffinity = flask_vcpuaffinity,
> +    .nodeaffinity = flask_affinity,
> +    .vcpuaffinity = flask_affinity,
>      .scheduler = flask_scheduler,
>      .getdomaininfo = flask_getdomaininfo,
>      .getvcpucontext = flask_getvcpucontext,
> diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
> --- a/xen/xsm/flask/include/av_perm_to_string.h
> +++ b/xen/xsm/flask/include/av_perm_to_string.h
> @@ -37,8 +37,8 @@
>     S_(SECCLASS_DOMAIN, DOMAIN__TRANSITION, "transition")
>     S_(SECCLASS_DOMAIN, DOMAIN__MAX_VCPUS, "max_vcpus")
>     S_(SECCLASS_DOMAIN, DOMAIN__DESTROY, "destroy")
> -   S_(SECCLASS_DOMAIN, DOMAIN__SETVCPUAFFINITY, "setvcpuaffinity")
> -   S_(SECCLASS_DOMAIN, DOMAIN__GETVCPUAFFINITY, "getvcpuaffinity")
> +   S_(SECCLASS_DOMAIN, DOMAIN__SETAFFINITY, "setaffinity")
> +   S_(SECCLASS_DOMAIN, DOMAIN__GETAFFINITY, "getaffinity")

The top of this file says, "This file is automatically generated. Do
not edit."  I didn't see any files that might have been modified to
effect these changes -- did I miss them?  Or is the comment a lie?  Or
should you find that file and edit it instead? :-)

>     S_(SECCLASS_DOMAIN, DOMAIN__SCHEDULER, "scheduler")
>     S_(SECCLASS_DOMAIN, DOMAIN__GETDOMAININFO, "getdomaininfo")
>     S_(SECCLASS_DOMAIN, DOMAIN__GETVCPUINFO, "getvcpuinfo")
> diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
> --- a/xen/xsm/flask/include/av_permissions.h
> +++ b/xen/xsm/flask/include/av_permissions.h
> @@ -38,8 +38,8 @@
>  #define DOMAIN__TRANSITION                        0x00000020UL
>  #define DOMAIN__MAX_VCPUS                         0x00000040UL
>  #define DOMAIN__DESTROY                           0x00000080UL
> -#define DOMAIN__SETVCPUAFFINITY                   0x00000100UL
> -#define DOMAIN__GETVCPUAFFINITY                   0x00000200UL
> +#define DOMAIN__SETAFFINITY                       0x00000100UL
> +#define DOMAIN__GETAFFINITY                       0x00000200UL

Same thing here.

Other than that, looks good!

 -George

>  #define DOMAIN__SCHEDULER                         0x00000400UL
>  #define DOMAIN__GETDOMAININFO                     0x00000800UL
>  #define DOMAIN__GETVCPUINFO                       0x00001000UL
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 16:47:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 16:47:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLcxq-0005Xl-9e; Tue, 09 Oct 2012 16:47:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLcxo-0005Xf-DJ
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 16:47:24 +0000
Received: from [85.158.139.83:44863] by server-16.bemta-5.messagelabs.com id
	04/7D-21637-B1554705; Tue, 09 Oct 2012 16:47:23 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1349801242!26770246!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30460 invoked from network); 9 Oct 2012 16:47:22 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 16:47:22 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so3945568eek.32
	for ; Tue, 09 Oct 2012 09:47:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=7fuUyL+niK+HQ5/qorW6uUo5ZBmBy+BjIPYXvt35vDI=;
	b=DsFlJyEnBBlUcC/7rXgCs8riwpIo1qqYTip2We9cKbGKeeiJNI3ETTKgCjhP/nsgSW
	15lkyVlf3uisJnq7360eFXrN9W2ggm0kexK3JNquAj33xFS9C+Z+g695+o2Vui/2IFKq
	yVVPkVBjn93g5nme1p4sYCKN2F5RXFFuDAUzIy0cgXAXOP4GqrR2XBiK8YE0O1jZQygT
	b9IqdKD/kh2yMZd5MRVBXDE3SX0TZShsf8RR3ayZV1uS5Szlm1TMnoHjvKCuDv5nD+vo
	Z00CdQBCuxTvfdmwAFIKFftLgiLiTPklrKZ2rULNxjXrYS44HJcBfZLeHrHexfg3OmDP
	32tw==
MIME-Version: 1.0
Received: by 10.14.223.199 with SMTP id v47mr1649604eep.45.1349801242165; Tue,
	09 Oct 2012 09:47:22 -0700 (PDT)
Received: by 10.14.215.195 with HTTP; Tue, 9 Oct 2012 09:47:22 -0700 (PDT)
In-Reply-To: <12134421b216e9c8eef6.1349446102@Solace>
References: 
	<12134421b216e9c8eef6.1349446102@Solace>
Date: Tue, 9 Oct 2012 17:47:22 +0100
X-Google-Sender-Auth: knK9h9-jYz6gDZ00wI6jCsnBbqs
Message-ID: 
From: George Dunlap 
To: Dario Faggioli 
Cc: Marcus Granado ,
	Andre Przywara ,
	Ian Campbell ,
	Anil Madhavapeddy ,
	Andrew Cooper ,
	Juergen Gross ,
	Ian Jackson , xen-devel@lists.xen.org,
	Jan Beulich , Daniel De Graaf ,
	Matt Wilson 
Subject: Re: [Xen-devel] [PATCH 4 of 8] xen: allow for explicitly specifying
	node-affinity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 5, 2012 at 3:08 PM, Dario Faggioli
 wrote:
> Make it possible to pass the node-affinity of a domain to the hypervisor
> from the upper layers, instead of always being computed automatically.
>
> Note that this also required generalizing the Flask hooks for setting
> and getting the affinity, so that they now deal with both vcpu and
> node affinity.
>
> Signed-off-by: Dario Faggioli 
>
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -222,6 +222,7 @@ struct domain *domain_create(
>
>      spin_lock_init(&d->node_affinity_lock);
>      d->node_affinity = NODE_MASK_ALL;
> +    d->auto_node_affinity = 1;
>
>      spin_lock_init(&d->shutdown_lock);
>      d->shutdown_code = -1;
> @@ -362,11 +363,26 @@ void domain_update_node_affinity(struct
>          cpumask_or(cpumask, cpumask, online_affinity);
>      }
>
> -    for_each_online_node ( node )
> -        if ( cpumask_intersects(&node_to_cpumask(node), cpumask) )
> -            node_set(node, nodemask);
> +    if ( d->auto_node_affinity )
> +    {
> +        /* Node-affinity is automaically computed from all vcpu-affinities */
> +        for_each_online_node ( node )
> +            if ( cpumask_intersects(&node_to_cpumask(node), cpumask) )
> +                node_set(node, nodemask);
>
> -    d->node_affinity = nodemask;
> +        d->node_affinity = nodemask;
> +    }
> +    else
> +    {
> +        /* Node-affinity is provided by someone else, just filter out cpus
> +         * that are either offline or not in the affinity of any vcpus. */
> +        for_each_node_mask ( node, d->node_affinity )
> +            if ( !cpumask_intersects(&node_to_cpumask(node), cpumask) )
> +                node_clear(node, d->node_affinity);
> +    }
> +
> +    sched_set_node_affinity(d, &d->node_affinity);
> +
>      spin_unlock(&d->node_affinity_lock);
>
>      free_cpumask_var(online_affinity);
> @@ -374,6 +390,36 @@ void domain_update_node_affinity(struct
>  }
>
>
> +int domain_set_node_affinity(struct domain *d, const nodemask_t *affinity)
> +{
> +    /* Being affine with no nodes is just wrong */
> +    if ( nodes_empty(*affinity) )
> +        return -EINVAL;
> +
> +    spin_lock(&d->node_affinity_lock);
> +
> +    /*
> +     * Being/becoming explicitly affine to all nodes is not particularly
> +     * useful. Let's take it as the `reset node affinity` command.
> +     */
> +    if ( nodes_full(*affinity) )
> +    {
> +        d->auto_node_affinity = 1;
> +        goto out;
> +    }
> +
> +    d->auto_node_affinity = 0;
> +    d->node_affinity = *affinity;
> +
> +out:
> +    spin_unlock(&d->node_affinity_lock);
> +
> +    domain_update_node_affinity(d);
> +
> +    return 0;
> +}
> +
> +
>  struct domain *get_domain_by_id(domid_t dom)
>  {
>      struct domain *d;
> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -642,6 +642,40 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
>      }
>      break;
>
> +    case XEN_DOMCTL_setnodeaffinity:
> +    case XEN_DOMCTL_getnodeaffinity:
> +    {
> +        domid_t dom = op->domain;
> +        struct domain *d = rcu_lock_domain_by_id(dom);
> +
> +        ret = -ESRCH;
> +        if ( d == NULL )
> +            break;
> +
> +        ret = xsm_nodeaffinity(op->cmd, d);
> +        if ( ret )
> +            goto nodeaffinity_out;
> +
> +        if ( op->cmd == XEN_DOMCTL_setnodeaffinity )
> +        {
> +            nodemask_t new_affinity;
> +
> +            ret = xenctl_bitmap_to_nodemask(&new_affinity,
> +                                            &op->u.nodeaffinity.nodemap);
> +            if ( !ret )
> +                ret = domain_set_node_affinity(d, &new_affinity);
> +        }
> +        else
> +        {
> +            ret = nodemask_to_xenctl_bitmap(&op->u.nodeaffinity.nodemap,
> +                                            &d->node_affinity);
> +        }
> +
> +    nodeaffinity_out:
> +        rcu_unlock_domain(d);
> +    }
> +    break;
> +
>      case XEN_DOMCTL_setvcpuaffinity:
>      case XEN_DOMCTL_getvcpuaffinity:
>      {
> diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
> --- a/xen/common/keyhandler.c
> +++ b/xen/common/keyhandler.c
> @@ -217,6 +217,14 @@ static void cpuset_print(char *set, int
>      *set++ = '\0';
>  }
>
> +static void nodeset_print(char *set, int size, const nodemask_t *mask)
> +{
> +    *set++ = '[';
> +    set += nodelist_scnprintf(set, size-2, mask);
> +    *set++ = ']';
> +    *set++ = '\0';
> +}
> +
>  static void periodic_timer_print(char *str, int size, uint64_t period)
>  {
>      if ( period == 0 )
> @@ -272,6 +280,9 @@ static void dump_domains(unsigned char k
>
>          dump_pageframe_info(d);
>
> +        nodeset_print(tmpstr, sizeof(tmpstr), &d->node_affinity);
> +        printk("NODE affinity for domain %d: %s\n", d->domain_id, tmpstr);
> +
>          printk("VCPU information and callbacks for domain %u:\n",
>                 d->domain_id);
>          for_each_vcpu ( d, v )
> diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
> --- a/xen/common/sched_credit.c
> +++ b/xen/common/sched_credit.c
> @@ -238,6 +238,33 @@ static inline void
>      list_del_init(&svc->runq_elem);
>  }
>
> +/*
> + * Translates node-affinity mask into a cpumask, so that we can use it during
> + * actual scheduling. That of course will contain all the cpus from all the
> + * set nodes in the original node-affinity mask.
> + *
> + * Note that any serialization needed to access mask safely is complete
> + * responsibility of the caller of this function/hook.
> + */
> +static void csched_set_node_affinity(
> +    const struct scheduler *ops,
> +    struct domain *d,
> +    nodemask_t *mask)
> +{
> +    struct csched_dom *sdom;
> +    int node;
> +
> +    /* Skip idle domain since it doesn't even have a node_affinity_cpumask */
> +    if ( unlikely(is_idle_domain(d)) )
> +        return;
> +
> +    sdom = CSCHED_DOM(d);
> +    cpumask_clear(sdom->node_affinity_cpumask);
> +    for_each_node_mask( node, *mask )
> +        cpumask_or(sdom->node_affinity_cpumask, sdom->node_affinity_cpumask,
> +                   &node_to_cpumask(node));
> +}
> +
>  #define for_each_csched_balance_step(__step) \
>      for ( (__step) = CSCHED_BALANCE_LAST; (__step) >= 0; (__step)-- )
>
> @@ -260,7 +287,8 @@ csched_balance_cpumask(const struct vcpu
>          struct domain *d = vc->domain;
>          struct csched_dom *sdom = CSCHED_DOM(d);
>
> -        if ( cpumask_full(sdom->node_affinity_cpumask) )
> +        if ( cpumask_full(sdom->node_affinity_cpumask) ||
> +             d->auto_node_affinity == 1 )
>              return -1;
>
>          cpumask_and(mask, sdom->node_affinity_cpumask, vc->cpu_affinity);
> @@ -1786,6 +1814,8 @@ const struct scheduler sched_credit_def
>      .adjust         = csched_dom_cntl,
>      .adjust_global  = csched_sys_cntl,
>
> +    .set_node_affinity  = csched_set_node_affinity,
> +
>      .pick_cpu       = csched_cpu_pick,
>      .do_schedule    = csched_schedule,
>
> diff --git a/xen/common/schedule.c b/xen/common/schedule.c
> --- a/xen/common/schedule.c
> +++ b/xen/common/schedule.c
> @@ -588,6 +588,11 @@ int cpu_disable_scheduler(unsigned int c
>      return ret;
>  }
>
> +void sched_set_node_affinity(struct domain *d, nodemask_t *mask)
> +{
> +    SCHED_OP(DOM2OP(d), set_node_affinity, d, mask);
> +}
> +
>  int vcpu_set_affinity(struct vcpu *v, const cpumask_t *affinity)
>  {
>      cpumask_t online_affinity;
> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -279,6 +279,16 @@ typedef struct xen_domctl_getvcpuinfo xe
>  DEFINE_XEN_GUEST_HANDLE(xen_domctl_getvcpuinfo_t);
>
>
> +/* Get/set the NUMA node(s) with which the guest has affinity with. */
> +/* XEN_DOMCTL_setnodeaffinity */
> +/* XEN_DOMCTL_getnodeaffinity */
> +struct xen_domctl_nodeaffinity {
> +    struct xenctl_bitmap nodemap;/* IN */
> +};
> +typedef struct xen_domctl_nodeaffinity xen_domctl_nodeaffinity_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_domctl_nodeaffinity_t);
> +
> +
>  /* Get/set which physical cpus a vcpu can execute on. */
>  /* XEN_DOMCTL_setvcpuaffinity */
>  /* XEN_DOMCTL_getvcpuaffinity */
> @@ -900,6 +910,8 @@ struct xen_domctl {
>  #define XEN_DOMCTL_set_access_required           64
>  #define XEN_DOMCTL_audit_p2m                     65
>  #define XEN_DOMCTL_set_virq_handler              66
> +#define XEN_DOMCTL_setnodeaffinity               67
> +#define XEN_DOMCTL_getnodeaffinity               68
>  #define XEN_DOMCTL_gdbsx_guestmemio            1000
>  #define XEN_DOMCTL_gdbsx_pausevcpu             1001
>  #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
> @@ -913,6 +925,7 @@ struct xen_domctl {
>          struct xen_domctl_getpageframeinfo  getpageframeinfo;
>          struct xen_domctl_getpageframeinfo2 getpageframeinfo2;
>          struct xen_domctl_getpageframeinfo3 getpageframeinfo3;
> +        struct xen_domctl_nodeaffinity      nodeaffinity;
>          struct xen_domctl_vcpuaffinity      vcpuaffinity;
>          struct xen_domctl_shadow_op         shadow_op;
>          struct xen_domctl_max_mem           max_mem;
> diff --git a/xen/include/xen/nodemask.h b/xen/include/xen/nodemask.h
> --- a/xen/include/xen/nodemask.h
> +++ b/xen/include/xen/nodemask.h
> @@ -8,8 +8,9 @@
>   * See detailed comments in the file linux/bitmap.h describing the
>   * data type on which these nodemasks are based.
>   *
> - * For details of nodemask_scnprintf() and nodemask_parse(),
> - * see bitmap_scnprintf() and bitmap_parse() in lib/bitmap.c.
> + * For details of nodemask_scnprintf(), nodelist_scnpintf() and
> + * nodemask_parse(), see bitmap_scnprintf() and bitmap_parse()
> + * in lib/bitmap.c.
>   *
>   * The available nodemask operations are:
>   *
> @@ -48,6 +49,7 @@
>   * unsigned long *nodes_addr(mask)     Array of unsigned long's in mask
>   *
>   * int nodemask_scnprintf(buf, len, mask) Format nodemask for printing
> + * int nodelist_scnprintf(buf, len, mask) Format nodemask as a list for printing
>   * int nodemask_parse(ubuf, ulen, mask)        Parse ascii string as nodemask
>   *
>   * for_each_node_mask(node, mask)      for-loop node over mask
> @@ -280,6 +282,14 @@ static inline int __first_unset_node(con
>
>  #define nodes_addr(src) ((src).bits)
>
> +#define nodelist_scnprintf(buf, len, src) \
> +                       __nodelist_scnprintf((buf), (len), (src), MAX_NUMNODES)
> +static inline int __nodelist_scnprintf(char *buf, int len,
> +                                       const nodemask_t *srcp, int nbits)
> +{
> +       return bitmap_scnlistprintf(buf, len, srcp->bits, nbits);
> +}
> +
>  #if 0
>  #define nodemask_scnprintf(buf, len, src) \
>                         __nodemask_scnprintf((buf), (len), &(src), MAX_NUMNODES)
> diff --git a/xen/include/xen/sched-if.h b/xen/include/xen/sched-if.h
> --- a/xen/include/xen/sched-if.h
> +++ b/xen/include/xen/sched-if.h
> @@ -182,6 +182,8 @@ struct scheduler {
>                                      struct xen_domctl_scheduler_op *);
>      int          (*adjust_global)  (const struct scheduler *,
>                                      struct xen_sysctl_scheduler_op *);
> +    void         (*set_node_affinity) (const struct scheduler *,
> +                                       struct domain *, nodemask_t *);
>      void         (*dump_settings)  (const struct scheduler *);
>      void         (*dump_cpu_state) (const struct scheduler *, int);
>
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -346,8 +346,12 @@ struct domain
>      /* Various mem_events */
>      struct mem_event_per_domain *mem_event;
>
> -    /* Currently computed from union of all vcpu cpu-affinity masks. */
> +    /*
> +     * Can be specified by the user. If that is not the case, it is
> +     * computed from the union of all the vcpu cpu-affinity masks.
> +     */
>      nodemask_t node_affinity;
> +    int auto_node_affinity;
>      unsigned int last_alloc_node;
>      spinlock_t node_affinity_lock;
>  };
> @@ -416,6 +420,7 @@ static inline void get_knownalive_domain
>      ASSERT(!(atomic_read(&d->refcnt) & DOMAIN_DESTROYED));
>  }
>
> +int domain_set_node_affinity(struct domain *d, const nodemask_t *affinity);
>  void domain_update_node_affinity(struct domain *d);
>
>  struct domain *domain_create(
> @@ -519,6 +524,7 @@ void sched_destroy_domain(struct domain
>  int sched_move_domain(struct domain *d, struct cpupool *c);
>  long sched_adjust(struct domain *, struct xen_domctl_scheduler_op *);
>  long sched_adjust_global(struct xen_sysctl_scheduler_op *);
> +void sched_set_node_affinity(struct domain *, nodemask_t *);
>  int  sched_id(void);
>  void sched_tick_suspend(void);
>  void sched_tick_resume(void);
> diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
> --- a/xen/include/xsm/xsm.h
> +++ b/xen/include/xsm/xsm.h
> @@ -56,6 +56,7 @@ struct xsm_operations {
>      int (*domain_create) (struct domain *d, u32 ssidref);
>      int (*max_vcpus) (struct domain *d);
>      int (*destroydomain) (struct domain *d);
> +    int (*nodeaffinity) (int cmd, struct domain *d);
>      int (*vcpuaffinity) (int cmd, struct domain *d);
>      int (*scheduler) (struct domain *d);
>      int (*getdomaininfo) (struct domain *d);
> @@ -229,6 +230,11 @@ static inline int xsm_destroydomain (str
>      return xsm_call(destroydomain(d));
>  }
>
> +static inline int xsm_nodeaffinity (int cmd, struct domain *d)
> +{
> +    return xsm_call(nodeaffinity(cmd, d));
> +}
> +
>  static inline int xsm_vcpuaffinity (int cmd, struct domain *d)
>  {
>      return xsm_call(vcpuaffinity(cmd, d));
> diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
> --- a/xen/xsm/dummy.c
> +++ b/xen/xsm/dummy.c
> @@ -634,6 +634,7 @@ void xsm_fixup_ops (struct xsm_operation
>      set_to_dummy_if_null(ops, domain_create);
>      set_to_dummy_if_null(ops, max_vcpus);
>      set_to_dummy_if_null(ops, destroydomain);
> +    set_to_dummy_if_null(ops, nodeaffinity);
>      set_to_dummy_if_null(ops, vcpuaffinity);
>      set_to_dummy_if_null(ops, scheduler);
>      set_to_dummy_if_null(ops, getdomaininfo);
> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -521,17 +521,19 @@ static int flask_destroydomain(struct do
>                             DOMAIN__DESTROY);
>  }
>
> -static int flask_vcpuaffinity(int cmd, struct domain *d)
> +static int flask_affinity(int cmd, struct domain *d)
>  {
>      u32 perm;
>
>      switch ( cmd )
>      {
>      case XEN_DOMCTL_setvcpuaffinity:
> -        perm = DOMAIN__SETVCPUAFFINITY;
> +    case XEN_DOMCTL_setnodeaffinity:
> +        perm = DOMAIN__SETAFFINITY;
>          break;
>      case XEN_DOMCTL_getvcpuaffinity:
> -        perm = DOMAIN__GETVCPUAFFINITY;
> +    case XEN_DOMCTL_getnodeaffinity:
> +        perm = DOMAIN__GETAFFINITY;
>          break;
>      default:
>          return -EPERM;
> @@ -1473,7 +1475,8 @@ static struct xsm_operations flask_ops =
>      .domain_create = flask_domain_create,
>      .max_vcpus = flask_max_vcpus,
>      .destroydomain = flask_destroydomain,
> -    .vcpuaffinity = flask_vcpuaffinity,
> +    .nodeaffinity = flask_affinity,
> +    .vcpuaffinity = flask_affinity,
>      .scheduler = flask_scheduler,
>      .getdomaininfo = flask_getdomaininfo,
>      .getvcpucontext = flask_getvcpucontext,
> diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
> --- a/xen/xsm/flask/include/av_perm_to_string.h
> +++ b/xen/xsm/flask/include/av_perm_to_string.h
> @@ -37,8 +37,8 @@
>     S_(SECCLASS_DOMAIN, DOMAIN__TRANSITION, "transition")
>     S_(SECCLASS_DOMAIN, DOMAIN__MAX_VCPUS, "max_vcpus")
>     S_(SECCLASS_DOMAIN, DOMAIN__DESTROY, "destroy")
> -   S_(SECCLASS_DOMAIN, DOMAIN__SETVCPUAFFINITY, "setvcpuaffinity")
> -   S_(SECCLASS_DOMAIN, DOMAIN__GETVCPUAFFINITY, "getvcpuaffinity")
> +   S_(SECCLASS_DOMAIN, DOMAIN__SETAFFINITY, "setaffinity")
> +   S_(SECCLASS_DOMAIN, DOMAIN__GETAFFINITY, "getaffinity")

The top of this file says, "This file is automatically generated. Do
not edit."  I didn't see any files that might have been modified to
effect these changes -- did I miss them?  Or is the comment a lie?  Or
should you find that file and edit it instead? :-)

>     S_(SECCLASS_DOMAIN, DOMAIN__SCHEDULER, "scheduler")
>     S_(SECCLASS_DOMAIN, DOMAIN__GETDOMAININFO, "getdomaininfo")
>     S_(SECCLASS_DOMAIN, DOMAIN__GETVCPUINFO, "getvcpuinfo")
> diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
> --- a/xen/xsm/flask/include/av_permissions.h
> +++ b/xen/xsm/flask/include/av_permissions.h
> @@ -38,8 +38,8 @@
>  #define DOMAIN__TRANSITION                        0x00000020UL
>  #define DOMAIN__MAX_VCPUS                         0x00000040UL
>  #define DOMAIN__DESTROY                           0x00000080UL
> -#define DOMAIN__SETVCPUAFFINITY                   0x00000100UL
> -#define DOMAIN__GETVCPUAFFINITY                   0x00000200UL
> +#define DOMAIN__SETAFFINITY                       0x00000100UL
> +#define DOMAIN__GETAFFINITY                       0x00000200UL

Same thing here.

Other than that, looks good!

 -George

>  #define DOMAIN__SCHEDULER                         0x00000400UL
>  #define DOMAIN__GETDOMAININFO                     0x00000800UL
>  #define DOMAIN__GETVCPUINFO                       0x00001000UL
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 16:53:01 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 16:53:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLd34-0005jC-7I; Tue, 09 Oct 2012 16:52:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLd33-0005j6-7h
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 16:52:49 +0000
Received: from [85.158.143.35:22088] by server-2.bemta-4.messagelabs.com id
	52/56-06610-06654705; Tue, 09 Oct 2012 16:52:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1349801567!13969499!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3294 invoked from network); 9 Oct 2012 16:52:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 16:52:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,561,1344211200"; d="scan'208";a="15046494"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 16:52:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	17:52:46 +0100
Message-ID: <1349801565.21847.228.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: George Dunlap 
Date: Tue, 9 Oct 2012 17:52:45 +0100
In-Reply-To: 
References: 
	<12134421b216e9c8eef6.1349446102@Solace>
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Marcus Granado ,
	Andre Przywara , Matt Wilson , Anil
	Madhavapeddy , Andrew Cooper ,
	Dario Faggioli ,
	Ian Jackson ,
	"xen-devel@lists.xen.org" ,
	Jan Beulich , Daniel De Graaf ,
	Juergen Gross 
Subject: Re: [Xen-devel] [PATCH 4 of 8] xen: allow for explicitly specifying
 node-affinity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Could you trim your quotes please?

> > diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
> > --- a/xen/xsm/flask/include/av_perm_to_string.h
> > +++ b/xen/xsm/flask/include/av_perm_to_string.h
> > @@ -37,8 +37,8 @@
> >     S_(SECCLASS_DOMAIN, DOMAIN__TRANSITION, "transition")
> >     S_(SECCLASS_DOMAIN, DOMAIN__MAX_VCPUS, "max_vcpus")
> >     S_(SECCLASS_DOMAIN, DOMAIN__DESTROY, "destroy")
> > -   S_(SECCLASS_DOMAIN, DOMAIN__SETVCPUAFFINITY, "setvcpuaffinity")
> > -   S_(SECCLASS_DOMAIN, DOMAIN__GETVCPUAFFINITY, "getvcpuaffinity")
> > +   S_(SECCLASS_DOMAIN, DOMAIN__SETAFFINITY, "setaffinity")
> > +   S_(SECCLASS_DOMAIN, DOMAIN__GETAFFINITY, "getaffinity")
> 
> The top of this file says, "This file is automatically generated. Do
> not edit."  I didn't see any files that might have been modified to
> effect these changes -- did I miss them?  Or is the comment a lie?  Or
> should you find that file and edit it instead? :-)

Also, in that case why is this file checked in?

Usually the reason is if the generating tool is not widely available,
but in this case it seems to be
tools/flask/policy/policy/flask/mkflask.sh which depends on awk and not
a lot else -- so I think we can rely on it being available.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 16:53:01 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 16:53:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLd34-0005jC-7I; Tue, 09 Oct 2012 16:52:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLd33-0005j6-7h
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 16:52:49 +0000
Received: from [85.158.143.35:22088] by server-2.bemta-4.messagelabs.com id
	52/56-06610-06654705; Tue, 09 Oct 2012 16:52:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1349801567!13969499!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3294 invoked from network); 9 Oct 2012 16:52:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 16:52:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,561,1344211200"; d="scan'208";a="15046494"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 16:52:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	17:52:46 +0100
Message-ID: <1349801565.21847.228.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: George Dunlap 
Date: Tue, 9 Oct 2012 17:52:45 +0100
In-Reply-To: 
References: 
	<12134421b216e9c8eef6.1349446102@Solace>
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Marcus Granado ,
	Andre Przywara , Matt Wilson , Anil
	Madhavapeddy , Andrew Cooper ,
	Dario Faggioli ,
	Ian Jackson ,
	"xen-devel@lists.xen.org" ,
	Jan Beulich , Daniel De Graaf ,
	Juergen Gross 
Subject: Re: [Xen-devel] [PATCH 4 of 8] xen: allow for explicitly specifying
 node-affinity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Could you trim your quotes please?

> > diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
> > --- a/xen/xsm/flask/include/av_perm_to_string.h
> > +++ b/xen/xsm/flask/include/av_perm_to_string.h
> > @@ -37,8 +37,8 @@
> >     S_(SECCLASS_DOMAIN, DOMAIN__TRANSITION, "transition")
> >     S_(SECCLASS_DOMAIN, DOMAIN__MAX_VCPUS, "max_vcpus")
> >     S_(SECCLASS_DOMAIN, DOMAIN__DESTROY, "destroy")
> > -   S_(SECCLASS_DOMAIN, DOMAIN__SETVCPUAFFINITY, "setvcpuaffinity")
> > -   S_(SECCLASS_DOMAIN, DOMAIN__GETVCPUAFFINITY, "getvcpuaffinity")
> > +   S_(SECCLASS_DOMAIN, DOMAIN__SETAFFINITY, "setaffinity")
> > +   S_(SECCLASS_DOMAIN, DOMAIN__GETAFFINITY, "getaffinity")
> 
> The top of this file says, "This file is automatically generated. Do
> not edit."  I didn't see any files that might have been modified to
> effect these changes -- did I miss them?  Or is the comment a lie?  Or
> should you find that file and edit it instead? :-)

Also, in that case why is this file checked in?

Usually the reason is if the generating tool is not widely available,
but in this case it seems to be
tools/flask/policy/policy/flask/mkflask.sh which depends on awk and not
a lot else -- so I think we can rely on it being available.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 17:08:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 17:08:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLdHn-0005yZ-PP; Tue, 09 Oct 2012 17:08:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLdHk-0005yU-7D
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 17:08:02 +0000
Received: from [85.158.139.83:12412] by server-6.bemta-5.messagelabs.com id
	6A/21-14717-FE954705; Tue, 09 Oct 2012 17:07:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1349802478!30154927!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25340 invoked from network); 9 Oct 2012 17:07:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 17:07:58 -0000
X-IronPort-AV: E=Sophos;i="4.80,561,1344211200"; d="scan'208";a="15046837"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 17:07:58 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 9 Oct 2012 18:07:58 +0100
Date: Tue, 9 Oct 2012 18:06:52 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Russell King - ARM Linux 
In-Reply-To: <20121009160814.GH4625@n2100.arm.linux.org.uk>
Message-ID: 
References: <1349796183-30648-1-git-send-email-arnd@arndb.de>
	<20121009160814.GH4625@n2100.arm.linux.org.uk>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "mmarek@suse.cz" ,
	"dave.martin@linaro.org" ,
	"xen-devel@lists.xensource.com" ,
	"jonathan.austin@arm.com" ,
	Arnd Bergmann ,
	"konrad.wilk@oracle.com" ,
	"catalin.marinas@arm.com" ,
	"linus.walleij@linaro.org" ,
	Stefano Stabellini ,
	"sboyd@codeaurora.org" ,
	"linux-kernel@vger.kernel.org" ,
	"will.deacon@arm.com" , "rjw@sisk.pl" ,
	"damm@opensource.se" ,
	"jeremy@goop.org" ,
	"bryan.wu@canonical.com" ,
	"tglx@linutronix.de" ,
	"leif.lindholm@arm.com" ,
	"linux-arm-kernel@lists.infradead.org"
	
Subject: Re: [Xen-devel] [GIT PULL 0/9] ARM architecture fixes for 3.7
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 9 Oct 2012, Russell King - ARM Linux wrote:
> On Tue, Oct 09, 2012 at 05:22:54PM +0200, Arnd Bergmann wrote:
> > Here are some patches that belong into your domain, I hope you can
> > just send the lot to Linus the next time you send other patches.
> > 
> > These bug fixes all address problems found with automated build testing.
> > Some of them have been around for a long time, other bugs are
> > regressions since the merge window.
> 
> Apart from the sliced off comment in one commit (which XEN people need
> to confirm they're happy with the final version), I think these are
> otherwise fine... I'll hold off pulling them until that can be fixed.

I am OK with the comment being truncated.

I am going to submit a better fix for the Kconfig issues separately
anyway, on top of this patch.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 17:08:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 17:08:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLdHn-0005yZ-PP; Tue, 09 Oct 2012 17:08:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLdHk-0005yU-7D
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 17:08:02 +0000
Received: from [85.158.139.83:12412] by server-6.bemta-5.messagelabs.com id
	6A/21-14717-FE954705; Tue, 09 Oct 2012 17:07:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1349802478!30154927!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25340 invoked from network); 9 Oct 2012 17:07:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 17:07:58 -0000
X-IronPort-AV: E=Sophos;i="4.80,561,1344211200"; d="scan'208";a="15046837"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 17:07:58 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 9 Oct 2012 18:07:58 +0100
Date: Tue, 9 Oct 2012 18:06:52 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Russell King - ARM Linux 
In-Reply-To: <20121009160814.GH4625@n2100.arm.linux.org.uk>
Message-ID: 
References: <1349796183-30648-1-git-send-email-arnd@arndb.de>
	<20121009160814.GH4625@n2100.arm.linux.org.uk>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "mmarek@suse.cz" ,
	"dave.martin@linaro.org" ,
	"xen-devel@lists.xensource.com" ,
	"jonathan.austin@arm.com" ,
	Arnd Bergmann ,
	"konrad.wilk@oracle.com" ,
	"catalin.marinas@arm.com" ,
	"linus.walleij@linaro.org" ,
	Stefano Stabellini ,
	"sboyd@codeaurora.org" ,
	"linux-kernel@vger.kernel.org" ,
	"will.deacon@arm.com" , "rjw@sisk.pl" ,
	"damm@opensource.se" ,
	"jeremy@goop.org" ,
	"bryan.wu@canonical.com" ,
	"tglx@linutronix.de" ,
	"leif.lindholm@arm.com" ,
	"linux-arm-kernel@lists.infradead.org"
	
Subject: Re: [Xen-devel] [GIT PULL 0/9] ARM architecture fixes for 3.7
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 9 Oct 2012, Russell King - ARM Linux wrote:
> On Tue, Oct 09, 2012 at 05:22:54PM +0200, Arnd Bergmann wrote:
> > Here are some patches that belong into your domain, I hope you can
> > just send the lot to Linus the next time you send other patches.
> > 
> > These bug fixes all address problems found with automated build testing.
> > Some of them have been around for a long time, other bugs are
> > regressions since the merge window.
> 
> Apart from the sliced off comment in one commit (which XEN people need
> to confirm they're happy with the final version), I think these are
> otherwise fine... I'll hold off pulling them until that can be fixed.

I am OK with the comment being truncated.

I am going to submit a better fix for the Kconfig issues separately
anyway, on top of this patch.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 17:18:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 17:18:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLdRF-00069D-Ve; Tue, 09 Oct 2012 17:17:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLdRE-000696-CK
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 17:17:48 +0000
Received: from [85.158.137.99:47683] by server-14.bemta-3.messagelabs.com id
	B9/9E-19528-B3C54705; Tue, 09 Oct 2012 17:17:47 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1349803066!20926291!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13253 invoked from network); 9 Oct 2012 17:17:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 17:17:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,561,1344211200"; 
	d="asc'?scan'208";a="15047037"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 17:17:46 +0000
Received: from [IPv6:::1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	18:17:46 +0100
Message-ID: <1349803065.3610.127.camel@Abyss>
From: Dario Faggioli 
To: George Dunlap 
Date: Tue, 9 Oct 2012 18:17:45 +0100
In-Reply-To: 
References: 
	<12134421b216e9c8eef6.1349446102@Solace>
	
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
MIME-Version: 1.0
Cc: Marcus Granado ,
	Andre Przywara ,
	Ian Campbell ,
	Anil Madhavapeddy ,
	Andrew Cooper ,
	Juergen Gross ,
	Ian Jackson ,
	"xen-devel@lists.xen.org" ,
	Jan Beulich , Daniel De Graaf ,
	Matt Wilson 
Subject: Re: [Xen-devel] [PATCH 4 of 8] xen: allow for explicitly specifying
 node-affinity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============3836060114923075532=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3836060114923075532==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-lK7RcqNs6on7YFILBAHr"

--=-lK7RcqNs6on7YFILBAHr
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2012-10-09 at 17:47 +0100, George Dunlap wrote:=20
> > diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/=
include/av_perm_to_string.h
> > --- a/xen/xsm/flask/include/av_perm_to_string.h
> > +++ b/xen/xsm/flask/include/av_perm_to_string.h
> > @@ -37,8 +37,8 @@
> >     S_(SECCLASS_DOMAIN, DOMAIN__TRANSITION, "transition")
> >     S_(SECCLASS_DOMAIN, DOMAIN__MAX_VCPUS, "max_vcpus")
> >     S_(SECCLASS_DOMAIN, DOMAIN__DESTROY, "destroy")
> > -   S_(SECCLASS_DOMAIN, DOMAIN__SETVCPUAFFINITY, "setvcpuaffinity")
> > -   S_(SECCLASS_DOMAIN, DOMAIN__GETVCPUAFFINITY, "getvcpuaffinity")
> > +   S_(SECCLASS_DOMAIN, DOMAIN__SETAFFINITY, "setaffinity")
> > +   S_(SECCLASS_DOMAIN, DOMAIN__GETAFFINITY, "getaffinity")
>=20
> The top of this file says, "This file is automatically generated. Do
> not edit."  I didn't see any files that might have been modified to
> effect these changes -- did I miss them?  Or is the comment a lie?  Or
> should you find that file and edit it instead? :-)
>=20
Wow! I said I have very poor knowledge of this security hook thing, but
that is something quite big that I appear to have missed!! :-P

Thanks for pointing that out, and sorry for that. I'll definitely have
to take a look at the generator, and will do while resending.

Thanks again and Regards,
Dario

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-lK7RcqNs6on7YFILBAHr
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlB0XDoACgkQk4XaBE3IOsSNQwCgnwuUtwaqRsR74neqTHXJvQ86
MfYAoISWSaHqtvO1RPWfC5ane2t+819V
=a+JY
-----END PGP SIGNATURE-----

--=-lK7RcqNs6on7YFILBAHr--


--===============3836060114923075532==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3836060114923075532==--


From xen-devel-bounces@lists.xen.org Tue Oct 09 17:18:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 17:18:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLdRF-00069D-Ve; Tue, 09 Oct 2012 17:17:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLdRE-000696-CK
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 17:17:48 +0000
Received: from [85.158.137.99:47683] by server-14.bemta-3.messagelabs.com id
	B9/9E-19528-B3C54705; Tue, 09 Oct 2012 17:17:47 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1349803066!20926291!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13253 invoked from network); 9 Oct 2012 17:17:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 17:17:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,561,1344211200"; 
	d="asc'?scan'208";a="15047037"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 17:17:46 +0000
Received: from [IPv6:::1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012
	18:17:46 +0100
Message-ID: <1349803065.3610.127.camel@Abyss>
From: Dario Faggioli 
To: George Dunlap 
Date: Tue, 9 Oct 2012 18:17:45 +0100
In-Reply-To: 
References: 
	<12134421b216e9c8eef6.1349446102@Solace>
	
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
MIME-Version: 1.0
Cc: Marcus Granado ,
	Andre Przywara ,
	Ian Campbell ,
	Anil Madhavapeddy ,
	Andrew Cooper ,
	Juergen Gross ,
	Ian Jackson ,
	"xen-devel@lists.xen.org" ,
	Jan Beulich , Daniel De Graaf ,
	Matt Wilson 
Subject: Re: [Xen-devel] [PATCH 4 of 8] xen: allow for explicitly specifying
 node-affinity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============3836060114923075532=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3836060114923075532==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-lK7RcqNs6on7YFILBAHr"

--=-lK7RcqNs6on7YFILBAHr
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2012-10-09 at 17:47 +0100, George Dunlap wrote:=20
> > diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/=
include/av_perm_to_string.h
> > --- a/xen/xsm/flask/include/av_perm_to_string.h
> > +++ b/xen/xsm/flask/include/av_perm_to_string.h
> > @@ -37,8 +37,8 @@
> >     S_(SECCLASS_DOMAIN, DOMAIN__TRANSITION, "transition")
> >     S_(SECCLASS_DOMAIN, DOMAIN__MAX_VCPUS, "max_vcpus")
> >     S_(SECCLASS_DOMAIN, DOMAIN__DESTROY, "destroy")
> > -   S_(SECCLASS_DOMAIN, DOMAIN__SETVCPUAFFINITY, "setvcpuaffinity")
> > -   S_(SECCLASS_DOMAIN, DOMAIN__GETVCPUAFFINITY, "getvcpuaffinity")
> > +   S_(SECCLASS_DOMAIN, DOMAIN__SETAFFINITY, "setaffinity")
> > +   S_(SECCLASS_DOMAIN, DOMAIN__GETAFFINITY, "getaffinity")
>=20
> The top of this file says, "This file is automatically generated. Do
> not edit."  I didn't see any files that might have been modified to
> effect these changes -- did I miss them?  Or is the comment a lie?  Or
> should you find that file and edit it instead? :-)
>=20
Wow! I said I have very poor knowledge of this security hook thing, but
that is something quite big that I appear to have missed!! :-P

Thanks for pointing that out, and sorry for that. I'll definitely have
to take a look at the generator, and will do while resending.

Thanks again and Regards,
Dario

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-lK7RcqNs6on7YFILBAHr
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlB0XDoACgkQk4XaBE3IOsSNQwCgnwuUtwaqRsR74neqTHXJvQ86
MfYAoISWSaHqtvO1RPWfC5ane2t+819V
=a+JY
-----END PGP SIGNATURE-----

--=-lK7RcqNs6on7YFILBAHr--


--===============3836060114923075532==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3836060114923075532==--


From xen-devel-bounces@lists.xen.org Tue Oct 09 17:33:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 17:33:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLdfc-0006JN-EN; Tue, 09 Oct 2012 17:32:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLdfa-0006JI-PR
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 17:32:39 +0000
Received: from [85.158.139.211:14807] by server-4.bemta-5.messagelabs.com id
	0C/0D-20767-5BF54705; Tue, 09 Oct 2012 17:32:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1349803957!21661945!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17113 invoked from network); 9 Oct 2012 17:32:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 17:32:37 -0000
X-IronPort-AV: E=Sophos;i="4.80,561,1344211200"; d="scan'208";a="15047226"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 17:32:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 9 Oct 2012 18:32:36 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TLdfY-0005Cv-K3;
	Tue, 09 Oct 2012 17:32:36 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TLdfY-0002Nm-4D;
	Tue, 09 Oct 2012 18:32:36 +0100
To: 
Message-ID: 
From: xen.org 
Date: Tue, 9 Oct 2012 18:32:36 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13944: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13944 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13944/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 13932
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 13932
 build-i386                    4 xen-build                 fail REGR. vs. 13932

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13932
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13932
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13932
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13932

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  142e4577f5a9
baseline version:
 xen                  099589002239

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper 
  Anthony PERARD 
  Christoph Egger 
  David Vrabel 
  Ian Campbell 
  Keir Fraser 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Samuel Thibault 
  Samuel Thibault 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 413 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 17:33:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 17:33:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLdfc-0006JN-EN; Tue, 09 Oct 2012 17:32:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLdfa-0006JI-PR
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 17:32:39 +0000
Received: from [85.158.139.211:14807] by server-4.bemta-5.messagelabs.com id
	0C/0D-20767-5BF54705; Tue, 09 Oct 2012 17:32:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1349803957!21661945!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17113 invoked from network); 9 Oct 2012 17:32:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 17:32:37 -0000
X-IronPort-AV: E=Sophos;i="4.80,561,1344211200"; d="scan'208";a="15047226"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 17:32:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 9 Oct 2012 18:32:36 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TLdfY-0005Cv-K3;
	Tue, 09 Oct 2012 17:32:36 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TLdfY-0002Nm-4D;
	Tue, 09 Oct 2012 18:32:36 +0100
To: 
Message-ID: 
From: xen.org 
Date: Tue, 9 Oct 2012 18:32:36 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13944: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13944 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13944/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 13932
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 13932
 build-i386                    4 xen-build                 fail REGR. vs. 13932

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13932
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13932
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13932
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13932

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  142e4577f5a9
baseline version:
 xen                  099589002239

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper 
  Anthony PERARD 
  Christoph Egger 
  David Vrabel 
  Ian Campbell 
  Keir Fraser 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Samuel Thibault 
  Samuel Thibault 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 413 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 17:46:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 17:46:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLdt2-0006Ua-Rk; Tue, 09 Oct 2012 17:46:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLdt1-0006UV-CT
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 17:46:31 +0000
Received: from [85.158.139.83:17925] by server-16.bemta-5.messagelabs.com id
	87/6D-21637-6F264705; Tue, 09 Oct 2012 17:46:30 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1349804788!31263856!1
X-Originating-IP: [65.55.88.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 425 invoked from network); 9 Oct 2012 17:46:30 -0000
Received: from tx2ehsobe005.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.15)
	by server-2.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	9 Oct 2012 17:46:30 -0000
Received: from mail59-tx2-R.bigfish.com (10.9.14.239) by
	TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id
	14.1.225.23; Tue, 9 Oct 2012 17:46:28 +0000
Received: from mail59-tx2 (localhost [127.0.0.1])	by mail59-tx2-R.bigfish.com
	(Postfix) with ESMTP id 503D0360103;
	Tue,  9 Oct 2012 17:46:28 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh137ah13b6h1441h1155h)
Received: from mail59-tx2 (localhost.localdomain [127.0.0.1]) by mail59-tx2
	(MessageSwitch) id 1349804785866703_17699;
	Tue,  9 Oct 2012 17:46:25 +0000 (UTC)
Received: from TX2EHSMHS008.bigfish.com (unknown [10.9.14.242])	by
	mail59-tx2.bigfish.com (Postfix) with ESMTP id C811B2A0084;
	Tue,  9 Oct 2012 17:46:25 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS008.bigfish.com (10.9.99.108) with Microsoft SMTP Server id
	14.1.225.23; Tue, 9 Oct 2012 17:46:23 +0000
X-WSS-ID: 0MBN01A-01-66H-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2F80F1028064;	Tue,  9 Oct 2012 12:46:22 -0500 (CDT)
Received: from SAUSEXDAG06.amd.com (163.181.55.7) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 9 Oct 2012 12:46:57 -0500
Received: from [10.234.222.82] (163.181.55.254) by sausexdag06.amd.com
	(163.181.55.7) with Microsoft SMTP Server id 14.1.323.3; Tue, 9 Oct 2012
	12:46:21 -0500
Message-ID: <507462ED.2000203@amd.com>
Date: Tue, 9 Oct 2012 13:46:21 -0400
From: Boris Ostrovsky 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120825 Thunderbird/15.0
MIME-Version: 1.0
To: 
X-OriginatorOrg: amd.com
Cc: xen-devel 
Subject: [Xen-devel] [PATCH] xenalyze: Use correct length when copying
	record into buffer
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Boris Ostrovsky 
# Date 1349350810 14400
# Node ID ba18ab77da8ebe3c81ebf2c78c735cfcd40ea031
# Parent  4d47a8934b40556dd98428361c482be419c643be
xenalyze: Use correct length when copying record into buffer

mread64() calculates number of bytes to copied to avoid overrunning
target buffer but then doesn't use the calculated value.

Signed-off-by: Boris Ostrovsky 

diff -r 4d47a8934b40 -r ba18ab77da8e mread.c
--- a/mread.c	Wed Jun 20 16:54:17 2012 +0100
+++ b/mread.c	Thu Oct 04 07:40:10 2012 -0400
@@ -143,7 +143,7 @@ copy:
      dprintf(warn, " Using index %d, buffer at %p, buffer offset %llx 
len %d\n",
              bind, b, boffset, bsize);

-    bcopy(b+boffset, rec, len);
+    bcopy(b+boffset, rec, bsize);

      /* Handle the boundary case; make sure this is after doing anything
       * with the static variables*/


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 17:46:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 17:46:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLdt2-0006Ua-Rk; Tue, 09 Oct 2012 17:46:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLdt1-0006UV-CT
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 17:46:31 +0000
Received: from [85.158.139.83:17925] by server-16.bemta-5.messagelabs.com id
	87/6D-21637-6F264705; Tue, 09 Oct 2012 17:46:30 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1349804788!31263856!1
X-Originating-IP: [65.55.88.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 425 invoked from network); 9 Oct 2012 17:46:30 -0000
Received: from tx2ehsobe005.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.15)
	by server-2.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	9 Oct 2012 17:46:30 -0000
Received: from mail59-tx2-R.bigfish.com (10.9.14.239) by
	TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id
	14.1.225.23; Tue, 9 Oct 2012 17:46:28 +0000
Received: from mail59-tx2 (localhost [127.0.0.1])	by mail59-tx2-R.bigfish.com
	(Postfix) with ESMTP id 503D0360103;
	Tue,  9 Oct 2012 17:46:28 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh137ah13b6h1441h1155h)
Received: from mail59-tx2 (localhost.localdomain [127.0.0.1]) by mail59-tx2
	(MessageSwitch) id 1349804785866703_17699;
	Tue,  9 Oct 2012 17:46:25 +0000 (UTC)
Received: from TX2EHSMHS008.bigfish.com (unknown [10.9.14.242])	by
	mail59-tx2.bigfish.com (Postfix) with ESMTP id C811B2A0084;
	Tue,  9 Oct 2012 17:46:25 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS008.bigfish.com (10.9.99.108) with Microsoft SMTP Server id
	14.1.225.23; Tue, 9 Oct 2012 17:46:23 +0000
X-WSS-ID: 0MBN01A-01-66H-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2F80F1028064;	Tue,  9 Oct 2012 12:46:22 -0500 (CDT)
Received: from SAUSEXDAG06.amd.com (163.181.55.7) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 9 Oct 2012 12:46:57 -0500
Received: from [10.234.222.82] (163.181.55.254) by sausexdag06.amd.com
	(163.181.55.7) with Microsoft SMTP Server id 14.1.323.3; Tue, 9 Oct 2012
	12:46:21 -0500
Message-ID: <507462ED.2000203@amd.com>
Date: Tue, 9 Oct 2012 13:46:21 -0400
From: Boris Ostrovsky 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120825 Thunderbird/15.0
MIME-Version: 1.0
To: 
X-OriginatorOrg: amd.com
Cc: xen-devel 
Subject: [Xen-devel] [PATCH] xenalyze: Use correct length when copying
	record into buffer
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Boris Ostrovsky 
# Date 1349350810 14400
# Node ID ba18ab77da8ebe3c81ebf2c78c735cfcd40ea031
# Parent  4d47a8934b40556dd98428361c482be419c643be
xenalyze: Use correct length when copying record into buffer

mread64() calculates number of bytes to copied to avoid overrunning
target buffer but then doesn't use the calculated value.

Signed-off-by: Boris Ostrovsky 

diff -r 4d47a8934b40 -r ba18ab77da8e mread.c
--- a/mread.c	Wed Jun 20 16:54:17 2012 +0100
+++ b/mread.c	Thu Oct 04 07:40:10 2012 -0400
@@ -143,7 +143,7 @@ copy:
      dprintf(warn, " Using index %d, buffer at %p, buffer offset %llx 
len %d\n",
              bind, b, boffset, bsize);

-    bcopy(b+boffset, rec, len);
+    bcopy(b+boffset, rec, bsize);

      /* Handle the boundary case; make sure this is after doing anything
       * with the static variables*/


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 18:01:21 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 18:01:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLe72-0006iO-9k; Tue, 09 Oct 2012 18:01:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLe70-0006iJ-Le
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 18:00:58 +0000
Received: from [85.158.139.211:6455] by server-9.bemta-5.messagelabs.com id
	39/0B-31466-95664705; Tue, 09 Oct 2012 18:00:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1349805656!21646733!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15066 invoked from network); 9 Oct 2012 18:00:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 18:00:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,561,1344211200"; d="scan'208";a="15047542"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 18:00:56 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 9 Oct 2012 19:00:56 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TLe6y-0005No-8r; Tue, 09 Oct 2012 18:00:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TLe6y-000502-4B;
	Tue, 09 Oct 2012 19:00:56 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20596.26200.30125.482942@mariner.uk.xensource.com>
Date: Tue, 9 Oct 2012 19:00:56 +0100
To: xen.org 
In-Reply-To: 
References: 
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [xen-unstable test] 13944: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

xen.org writes ("[xen-unstable test] 13944: regressions - FAIL"):
> flight 13944 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13944/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
...
>  build-i386                    4 xen-build            fail REGR. vs. 13932

This is this:

fatal: Out of memory? mmap failed: Cannot allocate memory
fatal: The remote end hung up unexpectedly
make[1]: *** [qemu-xen-dir-find] Error 128

On gall-mite:

root@gall-mite:~# free -m
             total       used       free     shared    buffers     cached
Mem:          8102       2059       6042          0        650       1286
-/+ buffers/cache:        122       7980
Swap:        12143          0      12143
root@gall-mite:~# 

So it has 8G of RAM and 12G of swap.

I wonder if the git object cache is too big.  I will clear gall-mite's
and see if it helps.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 18:01:21 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 18:01:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLe72-0006iO-9k; Tue, 09 Oct 2012 18:01:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLe70-0006iJ-Le
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 18:00:58 +0000
Received: from [85.158.139.211:6455] by server-9.bemta-5.messagelabs.com id
	39/0B-31466-95664705; Tue, 09 Oct 2012 18:00:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1349805656!21646733!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15066 invoked from network); 9 Oct 2012 18:00:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 18:00:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,561,1344211200"; d="scan'208";a="15047542"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Oct 2012 18:00:56 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 9 Oct 2012 19:00:56 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TLe6y-0005No-8r; Tue, 09 Oct 2012 18:00:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TLe6y-000502-4B;
	Tue, 09 Oct 2012 19:00:56 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20596.26200.30125.482942@mariner.uk.xensource.com>
Date: Tue, 9 Oct 2012 19:00:56 +0100
To: xen.org 
In-Reply-To: 
References: 
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [xen-unstable test] 13944: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

xen.org writes ("[xen-unstable test] 13944: regressions - FAIL"):
> flight 13944 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13944/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
...
>  build-i386                    4 xen-build            fail REGR. vs. 13932

This is this:

fatal: Out of memory? mmap failed: Cannot allocate memory
fatal: The remote end hung up unexpectedly
make[1]: *** [qemu-xen-dir-find] Error 128

On gall-mite:

root@gall-mite:~# free -m
             total       used       free     shared    buffers     cached
Mem:          8102       2059       6042          0        650       1286
-/+ buffers/cache:        122       7980
Swap:        12143          0      12143
root@gall-mite:~# 

So it has 8G of RAM and 12G of swap.

I wonder if the git object cache is too big.  I will clear gall-mite's
and see if it helps.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 18:20:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 18:20:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLePW-0006wc-8p; Tue, 09 Oct 2012 18:20:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLePU-0006wX-KL
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 18:20:04 +0000
Received: from [85.158.143.35:16192] by server-3.bemta-4.messagelabs.com id
	D5/55-10986-3DA64705; Tue, 09 Oct 2012 18:20:03 +0000
X-Env-Sender: arnd@arndb.de
X-Msg-Ref: server-7.tower-21.messagelabs.com!1349806803!13002583!1
X-Originating-IP: [212.227.17.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjEyLjIyNy4xNy4xMCA9PiA4NzAxNA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18451 invoked from network); 9 Oct 2012 18:20:03 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.17.10)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 18:20:03 -0000
Received: from klappe2.localnet
	(HSI-KBW-149-172-5-253.hsi13.kabel-badenwuerttemberg.de
	[149.172.5.253])
	by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis)
	id 0MPXk1-1THXnU0R6n-005IKW; Tue, 09 Oct 2012 20:19:37 +0200
From: Arnd Bergmann 
To: Ian Campbell 
Date: Tue, 9 Oct 2012 18:19:34 +0000
User-Agent: KMail/1.12.2 (Linux/3.5.0; KDE/4.3.2; x86_64; ; )
References: <1349796183-30648-1-git-send-email-arnd@arndb.de>
	<201210091539.46274.arnd@arndb.de>
	<1349799035.21847.222.camel@zakaz.uk.xensource.com>
In-Reply-To: <1349799035.21847.222.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Message-Id: <201210091819.34310.arnd@arndb.de>
X-Provags-ID: V02:K0:npXf8fVpImnJ1kySbqNOiwZiZgnNQDHa+u/cVdVwT7H
	Gs6djRiK1bvnKytiWm8Lm+x8AcUYF6H3Qd9OFcSKqacjIJVBR4
	/XbpoyX2s8231kNHi5M+QFDtYL24IEpaw627Q9zJ4TZwk1UpJP
	1b1FJBgLEiwU1GooIEduJIg9r0kV+lEKAbs76ENoFdHGME89R7
	+j0xZ2AOkRy4m3FZosy1p075ND3AQ+ApTLSUX7cOUnpeE2JuDv
	ZjIOt11DKdwPYthzSFr/oSg52pgVZHa1M3DUp26BbeR6PE8Th2
	C5wC8Fzarlldibrq1/mntAq6JVHmNBd0TQnC+fFW8Z1RljyI3l
	SOFGZCEHMHymEjXagWvU=
Cc: Jeremy Fitzhardinge ,
	"xen-devel@lists.xensource.com" ,
	Stefano Stabellini ,
	Konrad Rzeszutek Wilk ,
	"linux-kernel@vger.kernel.org" ,
	Russell King ,
	"linux-arm-kernel@lists.infradead.org"
	
Subject: Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tuesday 09 October 2012, Ian Campbell wrote:
> On Tue, 2012-10-09 at 16:39 +0100, Arnd Bergmann wrote:
> > On Tuesday 09 October 2012, Ian Campbell wrote:
> > > > * The tmem hypercall is not available on ARM
> > > > 
> > > > * ARMv6 does not support cmpxchg on 16-bit words that are used in the
> > > 
> > > missing the end of this sentence?
> > 
> > Right, I meant to say 
> > 
> > * ARMv6 does not support cmpxchg on 16-bit words that are used in the
> >   Xen grant table code, so we must ensure that Xen support is only built
> >   on ARMv7-only kernels not combined ARMv6/v7 kernels.
> > 
> > This should be fixed differently in the future.
> 
> Is this is a build time failure because gcc/gas/etc refuses to generate
> these instructions if it is configured for v6?
> 
> I ask because if it is only a runtime issue then we can reason that if
> we are running Xen specific grant table code, then we must be running on
> Xen and therefore must necessarily be running on a v7 (because Xen only
> support v7+virt extensions) even if the kernel happens to be capable of
> running on v6 too.

The underlying reason of course is that ARMv6 doesn't have those
instructions. The symptom you see is a link error because gcc emits
a reference to the (intentionally missing) __bad_cmpxchg() function
from

static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old,
                                      unsigned long new, int size)
{
        unsigned long oldval, res;

        switch (size) {
#ifndef CONFIG_CPU_V6   /* min ARCH >= ARMv6K */
        case 1:
		...
                break;
        case 2:
		...
                break;
#endif
        case 4:
		...
                break;
        default:
                __bad_cmpxchg(ptr, size);
                oldval = 0;
        }
        return oldval;
}

The possible solutions I can see for this are:

* change the grant table format to use 32 bits for the flags on ARM
* change the code to always cmpxchg the entire 32 bit word including the flags.
* implement your own cmpxchg wrapper that may be implemented using a spinlock
  rather than cmpxchg if ARMv6 is enabled.

	Arnd

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 18:20:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 18:20:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLePW-0006wc-8p; Tue, 09 Oct 2012 18:20:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLePU-0006wX-KL
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 18:20:04 +0000
Received: from [85.158.143.35:16192] by server-3.bemta-4.messagelabs.com id
	D5/55-10986-3DA64705; Tue, 09 Oct 2012 18:20:03 +0000
X-Env-Sender: arnd@arndb.de
X-Msg-Ref: server-7.tower-21.messagelabs.com!1349806803!13002583!1
X-Originating-IP: [212.227.17.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjEyLjIyNy4xNy4xMCA9PiA4NzAxNA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18451 invoked from network); 9 Oct 2012 18:20:03 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.17.10)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 18:20:03 -0000
Received: from klappe2.localnet
	(HSI-KBW-149-172-5-253.hsi13.kabel-badenwuerttemberg.de
	[149.172.5.253])
	by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis)
	id 0MPXk1-1THXnU0R6n-005IKW; Tue, 09 Oct 2012 20:19:37 +0200
From: Arnd Bergmann 
To: Ian Campbell 
Date: Tue, 9 Oct 2012 18:19:34 +0000
User-Agent: KMail/1.12.2 (Linux/3.5.0; KDE/4.3.2; x86_64; ; )
References: <1349796183-30648-1-git-send-email-arnd@arndb.de>
	<201210091539.46274.arnd@arndb.de>
	<1349799035.21847.222.camel@zakaz.uk.xensource.com>
In-Reply-To: <1349799035.21847.222.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Message-Id: <201210091819.34310.arnd@arndb.de>
X-Provags-ID: V02:K0:npXf8fVpImnJ1kySbqNOiwZiZgnNQDHa+u/cVdVwT7H
	Gs6djRiK1bvnKytiWm8Lm+x8AcUYF6H3Qd9OFcSKqacjIJVBR4
	/XbpoyX2s8231kNHi5M+QFDtYL24IEpaw627Q9zJ4TZwk1UpJP
	1b1FJBgLEiwU1GooIEduJIg9r0kV+lEKAbs76ENoFdHGME89R7
	+j0xZ2AOkRy4m3FZosy1p075ND3AQ+ApTLSUX7cOUnpeE2JuDv
	ZjIOt11DKdwPYthzSFr/oSg52pgVZHa1M3DUp26BbeR6PE8Th2
	C5wC8Fzarlldibrq1/mntAq6JVHmNBd0TQnC+fFW8Z1RljyI3l
	SOFGZCEHMHymEjXagWvU=
Cc: Jeremy Fitzhardinge ,
	"xen-devel@lists.xensource.com" ,
	Stefano Stabellini ,
	Konrad Rzeszutek Wilk ,
	"linux-kernel@vger.kernel.org" ,
	Russell King ,
	"linux-arm-kernel@lists.infradead.org"
	
Subject: Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tuesday 09 October 2012, Ian Campbell wrote:
> On Tue, 2012-10-09 at 16:39 +0100, Arnd Bergmann wrote:
> > On Tuesday 09 October 2012, Ian Campbell wrote:
> > > > * The tmem hypercall is not available on ARM
> > > > 
> > > > * ARMv6 does not support cmpxchg on 16-bit words that are used in the
> > > 
> > > missing the end of this sentence?
> > 
> > Right, I meant to say 
> > 
> > * ARMv6 does not support cmpxchg on 16-bit words that are used in the
> >   Xen grant table code, so we must ensure that Xen support is only built
> >   on ARMv7-only kernels not combined ARMv6/v7 kernels.
> > 
> > This should be fixed differently in the future.
> 
> Is this is a build time failure because gcc/gas/etc refuses to generate
> these instructions if it is configured for v6?
> 
> I ask because if it is only a runtime issue then we can reason that if
> we are running Xen specific grant table code, then we must be running on
> Xen and therefore must necessarily be running on a v7 (because Xen only
> support v7+virt extensions) even if the kernel happens to be capable of
> running on v6 too.

The underlying reason of course is that ARMv6 doesn't have those
instructions. The symptom you see is a link error because gcc emits
a reference to the (intentionally missing) __bad_cmpxchg() function
from

static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old,
                                      unsigned long new, int size)
{
        unsigned long oldval, res;

        switch (size) {
#ifndef CONFIG_CPU_V6   /* min ARCH >= ARMv6K */
        case 1:
		...
                break;
        case 2:
		...
                break;
#endif
        case 4:
		...
                break;
        default:
                __bad_cmpxchg(ptr, size);
                oldval = 0;
        }
        return oldval;
}

The possible solutions I can see for this are:

* change the grant table format to use 32 bits for the flags on ARM
* change the code to always cmpxchg the entire 32 bit word including the flags.
* implement your own cmpxchg wrapper that may be implemented using a spinlock
  rather than cmpxchg if ARMv6 is enabled.

	Arnd

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 18:22:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 18:22:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLeR6-00070V-OM; Tue, 09 Oct 2012 18:21:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLeR5-00070J-3r
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 18:21:43 +0000
Received: from [85.158.143.99:50239] by server-3.bemta-4.messagelabs.com id
	F2/76-10986-63B64705; Tue, 09 Oct 2012 18:21:42 +0000
X-Env-Sender: arnd@arndb.de
X-Msg-Ref: server-13.tower-216.messagelabs.com!1349806901!27221170!1
X-Originating-IP: [212.227.126.186]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xODYgPT4gNzQ0NzU=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xODYgPT4gNzQ0NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8131 invoked from network); 9 Oct 2012 18:21:41 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.126.186)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 18:21:41 -0000
Received: from klappe2.localnet
	(HSI-KBW-149-172-5-253.hsi13.kabel-badenwuerttemberg.de
	[149.172.5.253])
	by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis)
	id 0LaHLm-1TnnRH2Tss-00mDUZ; Tue, 09 Oct 2012 20:21:29 +0200
From: Arnd Bergmann 
To: Stefano Stabellini 
Date: Tue, 9 Oct 2012 18:21:27 +0000
User-Agent: KMail/1.12.2 (Linux/3.5.0; KDE/4.3.2; x86_64; ; )
References: <1349796183-30648-1-git-send-email-arnd@arndb.de>
	<1349796183-30648-6-git-send-email-arnd@arndb.de>
	
In-Reply-To: 
MIME-Version: 1.0
Message-Id: <201210091821.27818.arnd@arndb.de>
X-Provags-ID: V02:K0:pCU5eG1EXLHqk6USjSHpl/m9oAwRb8hRm5yQB99/6NF
	14PqehjUA9zfcpNKKQZH+zBDwp097p0bhbKCk9SETw1wadY3C+
	3MHtkqDzGLRJLoZTuOP2eHNUtZkswuqj78FFb8Io3LEvZaYw3z
	uKno/HJlLxqqfb0iuH58nfpjkQO4Zm8h8rPzwKuGaM+FMCt18+
	xKiaC1gOCu1Kzp+kjaQUiD/JvP8N7YoeV011nu/0DhBHanfv27
	HESRbHGFyXe3ZkeGzMQKkMSiYqJTgPmsSiezpMlgS8i50sNOCs
	s4unFVIx875znTPAbMCJAnGALPkwRyw7lhs3T/dKaaTfCRbxXZ
	sqRy/NGT3Wvq8WC6T4ZY=
Cc: Jeremy Fitzhardinge ,
	"xen-devel@lists.xensource.com" ,
	Konrad Rzeszutek Wilk ,
	"linux-kernel@vger.kernel.org" ,
	Russell King ,
	"linux-arm-kernel@lists.infradead.org"
	
Subject: Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tuesday 09 October 2012, Stefano Stabellini wrote:
> >  config XEN
> >       bool "Xen guest support on ARM (EXPERIMENTAL)"
> >       depends on EXPERIMENTAL && ARM && OF
> > +     depends on !CPU_V6
> >       help
> >         Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
> 
> Considering that we rely on the virtualization extensions, this one can
> be:
> 
>     depends on CPU_V7
> 
> The rest looks fine. I can submit a second patch to change !CPU_V6 into
> CPU_V7 later, if you prefer.

CPU_V6 and CPU_V7 are not exclusive, I saw the problem when building a
combined kernel for both V6 and V7. The code also needs to depend on ARMv7
with virtualization extensions, but that is a different issue. We don't
actually have a configuration symbol for that yet, as far as I can tell.

	Arnd

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 18:22:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 18:22:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLeR6-00070V-OM; Tue, 09 Oct 2012 18:21:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLeR5-00070J-3r
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 18:21:43 +0000
Received: from [85.158.143.99:50239] by server-3.bemta-4.messagelabs.com id
	F2/76-10986-63B64705; Tue, 09 Oct 2012 18:21:42 +0000
X-Env-Sender: arnd@arndb.de
X-Msg-Ref: server-13.tower-216.messagelabs.com!1349806901!27221170!1
X-Originating-IP: [212.227.126.186]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xODYgPT4gNzQ0NzU=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xODYgPT4gNzQ0NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8131 invoked from network); 9 Oct 2012 18:21:41 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.126.186)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 18:21:41 -0000
Received: from klappe2.localnet
	(HSI-KBW-149-172-5-253.hsi13.kabel-badenwuerttemberg.de
	[149.172.5.253])
	by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis)
	id 0LaHLm-1TnnRH2Tss-00mDUZ; Tue, 09 Oct 2012 20:21:29 +0200
From: Arnd Bergmann 
To: Stefano Stabellini 
Date: Tue, 9 Oct 2012 18:21:27 +0000
User-Agent: KMail/1.12.2 (Linux/3.5.0; KDE/4.3.2; x86_64; ; )
References: <1349796183-30648-1-git-send-email-arnd@arndb.de>
	<1349796183-30648-6-git-send-email-arnd@arndb.de>
	
In-Reply-To: 
MIME-Version: 1.0
Message-Id: <201210091821.27818.arnd@arndb.de>
X-Provags-ID: V02:K0:pCU5eG1EXLHqk6USjSHpl/m9oAwRb8hRm5yQB99/6NF
	14PqehjUA9zfcpNKKQZH+zBDwp097p0bhbKCk9SETw1wadY3C+
	3MHtkqDzGLRJLoZTuOP2eHNUtZkswuqj78FFb8Io3LEvZaYw3z
	uKno/HJlLxqqfb0iuH58nfpjkQO4Zm8h8rPzwKuGaM+FMCt18+
	xKiaC1gOCu1Kzp+kjaQUiD/JvP8N7YoeV011nu/0DhBHanfv27
	HESRbHGFyXe3ZkeGzMQKkMSiYqJTgPmsSiezpMlgS8i50sNOCs
	s4unFVIx875znTPAbMCJAnGALPkwRyw7lhs3T/dKaaTfCRbxXZ
	sqRy/NGT3Wvq8WC6T4ZY=
Cc: Jeremy Fitzhardinge ,
	"xen-devel@lists.xensource.com" ,
	Konrad Rzeszutek Wilk ,
	"linux-kernel@vger.kernel.org" ,
	Russell King ,
	"linux-arm-kernel@lists.infradead.org"
	
Subject: Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tuesday 09 October 2012, Stefano Stabellini wrote:
> >  config XEN
> >       bool "Xen guest support on ARM (EXPERIMENTAL)"
> >       depends on EXPERIMENTAL && ARM && OF
> > +     depends on !CPU_V6
> >       help
> >         Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
> 
> Considering that we rely on the virtualization extensions, this one can
> be:
> 
>     depends on CPU_V7
> 
> The rest looks fine. I can submit a second patch to change !CPU_V6 into
> CPU_V7 later, if you prefer.

CPU_V6 and CPU_V7 are not exclusive, I saw the problem when building a
combined kernel for both V6 and V7. The code also needs to depend on ARMv7
with virtualization extensions, but that is a different issue. We don't
actually have a configuration symbol for that yet, as far as I can tell.

	Arnd

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 18:32:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 18:32:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLebH-0007EP-Ry; Tue, 09 Oct 2012 18:32:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLebG-0007EK-20
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 18:32:14 +0000
Received: from [85.158.143.99:40393] by server-1.bemta-4.messagelabs.com id
	98/D1-05684-DAD64705; Tue, 09 Oct 2012 18:32:13 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-11.tower-216.messagelabs.com!1349807530!25946856!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6419 invoked from network); 9 Oct 2012 18:32:11 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-11.tower-216.messagelabs.com with SMTP;
	9 Oct 2012 18:32:11 -0000
X-TM-IMSS-Message-ID: 
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1;
	TLSv1/SSLv3 DHE-RSA-AES256-SHA (256/256)) id c577aa4300004cda ;
	Tue, 9 Oct 2012 14:32:04 -0400
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q99IW8No005541; 
	Tue, 9 Oct 2012 14:32:08 -0400
From: Daniel De Graaf 
To: Ian Campbell ,
	Dario Faggioli 
Date: Tue,  9 Oct 2012 14:31:53 -0400
Message-Id: <1349807513-10923-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1349801565.21847.228.camel@zakaz.uk.xensource.com>
References: <1349801565.21847.228.camel@zakaz.uk.xensource.com>
Cc: Marcus.Granado@eu.citrix.com, andre.przywara@amd.com, msw@amazon.com,
	anil@recoil.org, George.Dunlap@eu.citrix.com,
	Andrew.Cooper3@citrix.com, juergen.gross@ts.fujitsu.com,
	Ian.Jackson@eu.citrix.com, xen-devel@lists.xen.org,
	JBeulich@suse.com, Daniel De Graaf 
Subject: [Xen-devel] [PATCH RFC] flask: move policy header sources into
	hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell wrote:
[...]
>>> +++ b/xen/xsm/flask/include/av_perm_to_string.h
> Also, in that case why is this file checked in?

This patch fixes the autogenerated files, but doesn't fully wire them in
to things like "make clean" or .{git,hg}ignore. I don't see an obvious
way to clean generated header files in Xen's build system; perhaps
someone who knows the build system better can point out the right way to
wire this up.

--------------------------------------->8----------------------------

Rather than keeping around headers that are autogenerated in order to
avoid adding build dependencies from xen/ to files in tools/, move the
relevant parts of the FLASK policy into the hypervisor tree and generate
the headers as part of the hypervisor's build.

Signed-off-by: Daniel De Graaf 
---
 tools/flask/policy/Makefile                        |   2 +-
 tools/flask/policy/policy/flask/Makefile           |  41 ------
 xen/xsm/flask/Makefile                             |  21 +++
 xen/xsm/flask/include/av_perm_to_string.h          | 147 -------------------
 xen/xsm/flask/include/av_permissions.h             | 157 ---------------------
 xen/xsm/flask/include/class_to_string.h            |  15 --
 xen/xsm/flask/include/flask.h                      |  35 -----
 xen/xsm/flask/include/initial_sid_to_string.h      |  16 ---
 .../flask => xen/xsm/flask/policy}/access_vectors  |   0
 .../flask => xen/xsm/flask/policy}/initial_sids    |   0
 .../xsm/flask/policy}/mkaccess_vector.sh           |   4 +-
 .../flask => xen/xsm/flask/policy}/mkflask.sh      |   6 +-
 .../xsm/flask/policy}/security_classes             |   0
 13 files changed, 27 insertions(+), 417 deletions(-)
 delete mode 100644 tools/flask/policy/policy/flask/Makefile
 delete mode 100644 xen/xsm/flask/include/av_perm_to_string.h
 delete mode 100644 xen/xsm/flask/include/av_permissions.h
 delete mode 100644 xen/xsm/flask/include/class_to_string.h
 delete mode 100644 xen/xsm/flask/include/flask.h
 delete mode 100644 xen/xsm/flask/include/initial_sid_to_string.h
 rename {tools/flask/policy/policy/flask => xen/xsm/flask/policy}/access_vectors (100%)
 rename {tools/flask/policy/policy/flask => xen/xsm/flask/policy}/initial_sids (100%)
 rename {tools/flask/policy/policy/flask => xen/xsm/flask/policy}/mkaccess_vector.sh (97%)
 rename {tools/flask/policy/policy/flask => xen/xsm/flask/policy}/mkflask.sh (95%)
 rename {tools/flask/policy/policy/flask => xen/xsm/flask/policy}/security_classes (100%)

diff --git a/tools/flask/policy/Makefile b/tools/flask/policy/Makefile
index 5c25cbe..3f5aa38 100644
--- a/tools/flask/policy/Makefile
+++ b/tools/flask/policy/Makefile
@@ -61,7 +61,7 @@ LOADPOLICY := $(SBINDIR)/flask-loadpolicy
 # policy source layout
 POLDIR := policy
 MODDIR := $(POLDIR)/modules
-FLASKDIR := $(POLDIR)/flask
+FLASKDIR := ../../../xen/xsm/flask/policy
 SECCLASS := $(FLASKDIR)/security_classes
 ISIDS := $(FLASKDIR)/initial_sids
 AVS := $(FLASKDIR)/access_vectors
diff --git a/tools/flask/policy/policy/flask/Makefile b/tools/flask/policy/policy/flask/Makefile
deleted file mode 100644
index 5f57e88..0000000
--- a/tools/flask/policy/policy/flask/Makefile
+++ /dev/null
@@ -1,41 +0,0 @@
-# flask needs to know where to export the libselinux headers.
-LIBSEL ?= ../../libselinux
-
-# flask needs to know where to export the kernel headers.
-LINUXDIR ?= ../../../linux-2.6
-
-AWK = awk
-
-CONFIG_SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; \
-          else if [ -x /bin/bash ]; then echo /bin/bash; \
-          else echo sh; fi ; fi)
-
-FLASK_H_DEPEND = security_classes initial_sids
-AV_H_DEPEND = access_vectors
-
-FLASK_H_FILES = class_to_string.h flask.h initial_sid_to_string.h
-AV_H_FILES = av_perm_to_string.h av_permissions.h
-ALL_H_FILES = $(FLASK_H_FILES) $(AV_H_FILES)
-
-all:  $(ALL_H_FILES)
-
-$(FLASK_H_FILES): $(FLASK_H_DEPEND)
-	$(CONFIG_SHELL) mkflask.sh $(AWK) $(FLASK_H_DEPEND)
-
-$(AV_H_FILES): $(AV_H_DEPEND)
-	$(CONFIG_SHELL) mkaccess_vector.sh $(AWK) $(AV_H_DEPEND)
-
-tolib: all
-	install -m 644 flask.h av_permissions.h $(LIBSEL)/include/selinux
-	install -m 644 class_to_string.h av_inherit.h common_perm_to_string.h av_perm_to_string.h $(LIBSEL)/src
-
-tokern: all
-	install -m 644 $(ALL_H_FILES) $(LINUXDIR)/security/selinux/include
-
-install: all
-
-relabel:
-
-clean:  
-	rm -f $(FLASK_H_FILES)
-	rm -f $(AV_H_FILES)
diff --git a/xen/xsm/flask/Makefile b/xen/xsm/flask/Makefile
index 92fb410..238495a 100644
--- a/xen/xsm/flask/Makefile
+++ b/xen/xsm/flask/Makefile
@@ -5,3 +5,24 @@ obj-y += flask_op.o
 subdir-y += ss
 
 CFLAGS += -I./include
+
+AWK = awk
+
+CONFIG_SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; \
+          else if [ -x /bin/bash ]; then echo /bin/bash; \
+          else echo sh; fi ; fi)
+
+FLASK_H_DEPEND = policy/security_classes policy/initial_sids
+AV_H_DEPEND = policy/access_vectors
+
+FLASK_H_FILES = include/flask.h include/class_to_string.h include/initial_sid_to_string.h
+AV_H_FILES = include/av_perm_to_string.h include/av_permissions.h
+ALL_H_FILES = $(FLASK_H_FILES) $(AV_H_FILES)
+
+$(obj-y) ss/built_in.o: $(ALL_H_FILES)
+
+$(FLASK_H_FILES): $(FLASK_H_DEPEND)
+	$(CONFIG_SHELL) policy/mkflask.sh $(AWK) $(FLASK_H_DEPEND)
+
+$(AV_H_FILES): $(AV_H_DEPEND)
+	$(CONFIG_SHELL) policy/mkaccess_vector.sh $(AWK) $(AV_H_DEPEND)
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
deleted file mode 100644
index c3f2370..0000000
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ /dev/null
@@ -1,147 +0,0 @@
-/* This file is automatically generated.  Do not edit. */
-   S_(SECCLASS_XEN, XEN__SCHEDULER, "scheduler")
-   S_(SECCLASS_XEN, XEN__SETTIME, "settime")
-   S_(SECCLASS_XEN, XEN__TBUFCONTROL, "tbufcontrol")
-   S_(SECCLASS_XEN, XEN__READCONSOLE, "readconsole")
-   S_(SECCLASS_XEN, XEN__CLEARCONSOLE, "clearconsole")
-   S_(SECCLASS_XEN, XEN__PERFCONTROL, "perfcontrol")
-   S_(SECCLASS_XEN, XEN__MTRR_ADD, "mtrr_add")
-   S_(SECCLASS_XEN, XEN__MTRR_DEL, "mtrr_del")
-   S_(SECCLASS_XEN, XEN__MTRR_READ, "mtrr_read")
-   S_(SECCLASS_XEN, XEN__MICROCODE, "microcode")
-   S_(SECCLASS_XEN, XEN__PHYSINFO, "physinfo")
-   S_(SECCLASS_XEN, XEN__QUIRK, "quirk")
-   S_(SECCLASS_XEN, XEN__WRITECONSOLE, "writeconsole")
-   S_(SECCLASS_XEN, XEN__READAPIC, "readapic")
-   S_(SECCLASS_XEN, XEN__WRITEAPIC, "writeapic")
-   S_(SECCLASS_XEN, XEN__PRIVPROFILE, "privprofile")
-   S_(SECCLASS_XEN, XEN__NONPRIVPROFILE, "nonprivprofile")
-   S_(SECCLASS_XEN, XEN__KEXEC, "kexec")
-   S_(SECCLASS_XEN, XEN__FIRMWARE, "firmware")
-   S_(SECCLASS_XEN, XEN__SLEEP, "sleep")
-   S_(SECCLASS_XEN, XEN__FREQUENCY, "frequency")
-   S_(SECCLASS_XEN, XEN__GETIDLE, "getidle")
-   S_(SECCLASS_XEN, XEN__DEBUG, "debug")
-   S_(SECCLASS_XEN, XEN__GETCPUINFO, "getcpuinfo")
-   S_(SECCLASS_XEN, XEN__HEAP, "heap")
-   S_(SECCLASS_XEN, XEN__PM_OP, "pm_op")
-   S_(SECCLASS_XEN, XEN__MCA_OP, "mca_op")
-   S_(SECCLASS_XEN, XEN__LOCKPROF, "lockprof")
-   S_(SECCLASS_XEN, XEN__CPUPOOL_OP, "cpupool_op")
-   S_(SECCLASS_XEN, XEN__SCHED_OP, "sched_op")
-   S_(SECCLASS_XEN, XEN__TMEM_OP, "tmem_op")
-   S_(SECCLASS_XEN, XEN__TMEM_CONTROL, "tmem_control")
-   S_(SECCLASS_DOMAIN, DOMAIN__SETVCPUCONTEXT, "setvcpucontext")
-   S_(SECCLASS_DOMAIN, DOMAIN__PAUSE, "pause")
-   S_(SECCLASS_DOMAIN, DOMAIN__UNPAUSE, "unpause")
-   S_(SECCLASS_DOMAIN, DOMAIN__RESUME, "resume")
-   S_(SECCLASS_DOMAIN, DOMAIN__CREATE, "create")
-   S_(SECCLASS_DOMAIN, DOMAIN__TRANSITION, "transition")
-   S_(SECCLASS_DOMAIN, DOMAIN__MAX_VCPUS, "max_vcpus")
-   S_(SECCLASS_DOMAIN, DOMAIN__DESTROY, "destroy")
-   S_(SECCLASS_DOMAIN, DOMAIN__SETVCPUAFFINITY, "setvcpuaffinity")
-   S_(SECCLASS_DOMAIN, DOMAIN__GETVCPUAFFINITY, "getvcpuaffinity")
-   S_(SECCLASS_DOMAIN, DOMAIN__SCHEDULER, "scheduler")
-   S_(SECCLASS_DOMAIN, DOMAIN__GETDOMAININFO, "getdomaininfo")
-   S_(SECCLASS_DOMAIN, DOMAIN__GETVCPUINFO, "getvcpuinfo")
-   S_(SECCLASS_DOMAIN, DOMAIN__GETVCPUCONTEXT, "getvcpucontext")
-   S_(SECCLASS_DOMAIN, DOMAIN__SETDOMAINMAXMEM, "setdomainmaxmem")
-   S_(SECCLASS_DOMAIN, DOMAIN__SETDOMAINHANDLE, "setdomainhandle")
-   S_(SECCLASS_DOMAIN, DOMAIN__SETDEBUGGING, "setdebugging")
-   S_(SECCLASS_DOMAIN, DOMAIN__HYPERCALL, "hypercall")
-   S_(SECCLASS_DOMAIN, DOMAIN__SETTIME, "settime")
-   S_(SECCLASS_DOMAIN, DOMAIN__SET_TARGET, "set_target")
-   S_(SECCLASS_DOMAIN, DOMAIN__SHUTDOWN, "shutdown")
-   S_(SECCLASS_DOMAIN, DOMAIN__SETADDRSIZE, "setaddrsize")
-   S_(SECCLASS_DOMAIN, DOMAIN__GETADDRSIZE, "getaddrsize")
-   S_(SECCLASS_DOMAIN, DOMAIN__TRIGGER, "trigger")
-   S_(SECCLASS_DOMAIN, DOMAIN__GETEXTVCPUCONTEXT, "getextvcpucontext")
-   S_(SECCLASS_DOMAIN, DOMAIN__SETEXTVCPUCONTEXT, "setextvcpucontext")
-   S_(SECCLASS_DOMAIN, DOMAIN__GETVCPUEXTSTATE, "getvcpuextstate")
-   S_(SECCLASS_DOMAIN, DOMAIN__SETVCPUEXTSTATE, "setvcpuextstate")
-   S_(SECCLASS_DOMAIN, DOMAIN__GETPODTARGET, "getpodtarget")
-   S_(SECCLASS_DOMAIN, DOMAIN__SETPODTARGET, "setpodtarget")
-   S_(SECCLASS_DOMAIN, DOMAIN__SET_MISC_INFO, "set_misc_info")
-   S_(SECCLASS_DOMAIN, DOMAIN__SET_VIRQ_HANDLER, "set_virq_handler")
-   S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELFROM, "relabelfrom")
-   S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELTO, "relabelto")
-   S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELSELF, "relabelself")
-   S_(SECCLASS_DOMAIN2, DOMAIN2__MAKE_PRIV_FOR, "make_priv_for")
-   S_(SECCLASS_DOMAIN2, DOMAIN2__SET_AS_TARGET, "set_as_target")
-   S_(SECCLASS_DOMAIN2, DOMAIN2__SET_CPUID, "set_cpuid")
-   S_(SECCLASS_DOMAIN2, DOMAIN2__GETTSC, "gettsc")
-   S_(SECCLASS_DOMAIN2, DOMAIN2__SETTSC, "settsc")
-   S_(SECCLASS_HVM, HVM__SETHVMC, "sethvmc")
-   S_(SECCLASS_HVM, HVM__GETHVMC, "gethvmc")
-   S_(SECCLASS_HVM, HVM__SETPARAM, "setparam")
-   S_(SECCLASS_HVM, HVM__GETPARAM, "getparam")
-   S_(SECCLASS_HVM, HVM__PCILEVEL, "pcilevel")
-   S_(SECCLASS_HVM, HVM__IRQLEVEL, "irqlevel")
-   S_(SECCLASS_HVM, HVM__PCIROUTE, "pciroute")
-   S_(SECCLASS_HVM, HVM__BIND_IRQ, "bind_irq")
-   S_(SECCLASS_HVM, HVM__CACHEATTR, "cacheattr")
-   S_(SECCLASS_HVM, HVM__TRACKDIRTYVRAM, "trackdirtyvram")
-   S_(SECCLASS_HVM, HVM__HVMCTL, "hvmctl")
-   S_(SECCLASS_HVM, HVM__MEM_EVENT, "mem_event")
-   S_(SECCLASS_HVM, HVM__MEM_SHARING, "mem_sharing")
-   S_(SECCLASS_HVM, HVM__AUDIT_P2M, "audit_p2m")
-   S_(SECCLASS_HVM, HVM__SEND_IRQ, "send_irq")
-   S_(SECCLASS_HVM, HVM__SHARE_MEM, "share_mem")
-   S_(SECCLASS_EVENT, EVENT__BIND, "bind")
-   S_(SECCLASS_EVENT, EVENT__SEND, "send")
-   S_(SECCLASS_EVENT, EVENT__STATUS, "status")
-   S_(SECCLASS_EVENT, EVENT__NOTIFY, "notify")
-   S_(SECCLASS_EVENT, EVENT__CREATE, "create")
-   S_(SECCLASS_EVENT, EVENT__RESET, "reset")
-   S_(SECCLASS_GRANT, GRANT__MAP_READ, "map_read")
-   S_(SECCLASS_GRANT, GRANT__MAP_WRITE, "map_write")
-   S_(SECCLASS_GRANT, GRANT__UNMAP, "unmap")
-   S_(SECCLASS_GRANT, GRANT__TRANSFER, "transfer")
-   S_(SECCLASS_GRANT, GRANT__SETUP, "setup")
-   S_(SECCLASS_GRANT, GRANT__COPY, "copy")
-   S_(SECCLASS_GRANT, GRANT__QUERY, "query")
-   S_(SECCLASS_MMU, MMU__MAP_READ, "map_read")
-   S_(SECCLASS_MMU, MMU__MAP_WRITE, "map_write")
-   S_(SECCLASS_MMU, MMU__PAGEINFO, "pageinfo")
-   S_(SECCLASS_MMU, MMU__PAGELIST, "pagelist")
-   S_(SECCLASS_MMU, MMU__ADJUST, "adjust")
-   S_(SECCLASS_MMU, MMU__STAT, "stat")
-   S_(SECCLASS_MMU, MMU__TRANSLATEGP, "translategp")
-   S_(SECCLASS_MMU, MMU__UPDATEMP, "updatemp")
-   S_(SECCLASS_MMU, MMU__PHYSMAP, "physmap")
-   S_(SECCLASS_MMU, MMU__PINPAGE, "pinpage")
-   S_(SECCLASS_MMU, MMU__MFNLIST, "mfnlist")
-   S_(SECCLASS_MMU, MMU__MEMORYMAP, "memorymap")
-   S_(SECCLASS_MMU, MMU__REMOTE_REMAP, "remote_remap")
-   S_(SECCLASS_MMU, MMU__MMUEXT_OP, "mmuext_op")
-   S_(SECCLASS_MMU, MMU__EXCHANGE, "exchange")
-   S_(SECCLASS_SHADOW, SHADOW__DISABLE, "disable")
-   S_(SECCLASS_SHADOW, SHADOW__ENABLE, "enable")
-   S_(SECCLASS_SHADOW, SHADOW__LOGDIRTY, "logdirty")
-   S_(SECCLASS_RESOURCE, RESOURCE__ADD, "add")
-   S_(SECCLASS_RESOURCE, RESOURCE__REMOVE, "remove")
-   S_(SECCLASS_RESOURCE, RESOURCE__USE, "use")
-   S_(SECCLASS_RESOURCE, RESOURCE__ADD_IRQ, "add_irq")
-   S_(SECCLASS_RESOURCE, RESOURCE__REMOVE_IRQ, "remove_irq")
-   S_(SECCLASS_RESOURCE, RESOURCE__ADD_IOPORT, "add_ioport")
-   S_(SECCLASS_RESOURCE, RESOURCE__REMOVE_IOPORT, "remove_ioport")
-   S_(SECCLASS_RESOURCE, RESOURCE__ADD_IOMEM, "add_iomem")
-   S_(SECCLASS_RESOURCE, RESOURCE__REMOVE_IOMEM, "remove_iomem")
-   S_(SECCLASS_RESOURCE, RESOURCE__STAT_DEVICE, "stat_device")
-   S_(SECCLASS_RESOURCE, RESOURCE__ADD_DEVICE, "add_device")
-   S_(SECCLASS_RESOURCE, RESOURCE__REMOVE_DEVICE, "remove_device")
-   S_(SECCLASS_RESOURCE, RESOURCE__PLUG, "plug")
-   S_(SECCLASS_RESOURCE, RESOURCE__UNPLUG, "unplug")
-   S_(SECCLASS_RESOURCE, RESOURCE__SETUP, "setup")
-   S_(SECCLASS_SECURITY, SECURITY__COMPUTE_AV, "compute_av")
-   S_(SECCLASS_SECURITY, SECURITY__COMPUTE_CREATE, "compute_create")
-   S_(SECCLASS_SECURITY, SECURITY__COMPUTE_MEMBER, "compute_member")
-   S_(SECCLASS_SECURITY, SECURITY__CHECK_CONTEXT, "check_context")
-   S_(SECCLASS_SECURITY, SECURITY__LOAD_POLICY, "load_policy")
-   S_(SECCLASS_SECURITY, SECURITY__COMPUTE_RELABEL, "compute_relabel")
-   S_(SECCLASS_SECURITY, SECURITY__COMPUTE_USER, "compute_user")
-   S_(SECCLASS_SECURITY, SECURITY__SETENFORCE, "setenforce")
-   S_(SECCLASS_SECURITY, SECURITY__SETBOOL, "setbool")
-   S_(SECCLASS_SECURITY, SECURITY__SETSECPARAM, "setsecparam")
-   S_(SECCLASS_SECURITY, SECURITY__ADD_OCONTEXT, "add_ocontext")
-   S_(SECCLASS_SECURITY, SECURITY__DEL_OCONTEXT, "del_ocontext")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
deleted file mode 100644
index 65302e8..0000000
--- a/xen/xsm/flask/include/av_permissions.h
+++ /dev/null
@@ -1,157 +0,0 @@
-/* This file is automatically generated.  Do not edit. */
-#define XEN__SCHEDULER                            0x00000001UL
-#define XEN__SETTIME                              0x00000002UL
-#define XEN__TBUFCONTROL                          0x00000004UL
-#define XEN__READCONSOLE                          0x00000008UL
-#define XEN__CLEARCONSOLE                         0x00000010UL
-#define XEN__PERFCONTROL                          0x00000020UL
-#define XEN__MTRR_ADD                             0x00000040UL
-#define XEN__MTRR_DEL                             0x00000080UL
-#define XEN__MTRR_READ                            0x00000100UL
-#define XEN__MICROCODE                            0x00000200UL
-#define XEN__PHYSINFO                             0x00000400UL
-#define XEN__QUIRK                                0x00000800UL
-#define XEN__WRITECONSOLE                         0x00001000UL
-#define XEN__READAPIC                             0x00002000UL
-#define XEN__WRITEAPIC                            0x00004000UL
-#define XEN__PRIVPROFILE                          0x00008000UL
-#define XEN__NONPRIVPROFILE                       0x00010000UL
-#define XEN__KEXEC                                0x00020000UL
-#define XEN__FIRMWARE                             0x00040000UL
-#define XEN__SLEEP                                0x00080000UL
-#define XEN__FREQUENCY                            0x00100000UL
-#define XEN__GETIDLE                              0x00200000UL
-#define XEN__DEBUG                                0x00400000UL
-#define XEN__GETCPUINFO                           0x00800000UL
-#define XEN__HEAP                                 0x01000000UL
-#define XEN__PM_OP                                0x02000000UL
-#define XEN__MCA_OP                               0x04000000UL
-#define XEN__LOCKPROF                             0x08000000UL
-#define XEN__CPUPOOL_OP                           0x10000000UL
-#define XEN__SCHED_OP                             0x20000000UL
-#define XEN__TMEM_OP                              0x40000000UL
-#define XEN__TMEM_CONTROL                         0x80000000UL
-
-#define DOMAIN__SETVCPUCONTEXT                    0x00000001UL
-#define DOMAIN__PAUSE                             0x00000002UL
-#define DOMAIN__UNPAUSE                           0x00000004UL
-#define DOMAIN__RESUME                            0x00000008UL
-#define DOMAIN__CREATE                            0x00000010UL
-#define DOMAIN__TRANSITION                        0x00000020UL
-#define DOMAIN__MAX_VCPUS                         0x00000040UL
-#define DOMAIN__DESTROY                           0x00000080UL
-#define DOMAIN__SETVCPUAFFINITY                   0x00000100UL
-#define DOMAIN__GETVCPUAFFINITY                   0x00000200UL
-#define DOMAIN__SCHEDULER                         0x00000400UL
-#define DOMAIN__GETDOMAININFO                     0x00000800UL
-#define DOMAIN__GETVCPUINFO                       0x00001000UL
-#define DOMAIN__GETVCPUCONTEXT                    0x00002000UL
-#define DOMAIN__SETDOMAINMAXMEM                   0x00004000UL
-#define DOMAIN__SETDOMAINHANDLE                   0x00008000UL
-#define DOMAIN__SETDEBUGGING                      0x00010000UL
-#define DOMAIN__HYPERCALL                         0x00020000UL
-#define DOMAIN__SETTIME                           0x00040000UL
-#define DOMAIN__SET_TARGET                        0x00080000UL
-#define DOMAIN__SHUTDOWN                          0x00100000UL
-#define DOMAIN__SETADDRSIZE                       0x00200000UL
-#define DOMAIN__GETADDRSIZE                       0x00400000UL
-#define DOMAIN__TRIGGER                           0x00800000UL
-#define DOMAIN__GETEXTVCPUCONTEXT                 0x01000000UL
-#define DOMAIN__SETEXTVCPUCONTEXT                 0x02000000UL
-#define DOMAIN__GETVCPUEXTSTATE                   0x04000000UL
-#define DOMAIN__SETVCPUEXTSTATE                   0x08000000UL
-#define DOMAIN__GETPODTARGET                      0x10000000UL
-#define DOMAIN__SETPODTARGET                      0x20000000UL
-#define DOMAIN__SET_MISC_INFO                     0x40000000UL
-#define DOMAIN__SET_VIRQ_HANDLER                  0x80000000UL
-
-#define DOMAIN2__RELABELFROM                      0x00000001UL
-#define DOMAIN2__RELABELTO                        0x00000002UL
-#define DOMAIN2__RELABELSELF                      0x00000004UL
-#define DOMAIN2__MAKE_PRIV_FOR                    0x00000008UL
-#define DOMAIN2__SET_AS_TARGET                    0x00000010UL
-#define DOMAIN2__SET_CPUID                        0x00000020UL
-#define DOMAIN2__GETTSC                           0x00000040UL
-#define DOMAIN2__SETTSC                           0x00000080UL
-
-#define HVM__SETHVMC                              0x00000001UL
-#define HVM__GETHVMC                              0x00000002UL
-#define HVM__SETPARAM                             0x00000004UL
-#define HVM__GETPARAM                             0x00000008UL
-#define HVM__PCILEVEL                             0x00000010UL
-#define HVM__IRQLEVEL                             0x00000020UL
-#define HVM__PCIROUTE                             0x00000040UL
-#define HVM__BIND_IRQ                             0x00000080UL
-#define HVM__CACHEATTR                            0x00000100UL
-#define HVM__TRACKDIRTYVRAM                       0x00000200UL
-#define HVM__HVMCTL                               0x00000400UL
-#define HVM__MEM_EVENT                            0x00000800UL
-#define HVM__MEM_SHARING                          0x00001000UL
-#define HVM__AUDIT_P2M                            0x00002000UL
-#define HVM__SEND_IRQ                             0x00004000UL
-#define HVM__SHARE_MEM                            0x00008000UL
-
-#define EVENT__BIND                               0x00000001UL
-#define EVENT__SEND                               0x00000002UL
-#define EVENT__STATUS                             0x00000004UL
-#define EVENT__NOTIFY                             0x00000008UL
-#define EVENT__CREATE                             0x00000010UL
-#define EVENT__RESET                              0x00000020UL
-
-#define GRANT__MAP_READ                           0x00000001UL
-#define GRANT__MAP_WRITE                          0x00000002UL
-#define GRANT__UNMAP                              0x00000004UL
-#define GRANT__TRANSFER                           0x00000008UL
-#define GRANT__SETUP                              0x00000010UL
-#define GRANT__COPY                               0x00000020UL
-#define GRANT__QUERY                              0x00000040UL
-
-#define MMU__MAP_READ                             0x00000001UL
-#define MMU__MAP_WRITE                            0x00000002UL
-#define MMU__PAGEINFO                             0x00000004UL
-#define MMU__PAGELIST                             0x00000008UL
-#define MMU__ADJUST                               0x00000010UL
-#define MMU__STAT                                 0x00000020UL
-#define MMU__TRANSLATEGP                          0x00000040UL
-#define MMU__UPDATEMP                             0x00000080UL
-#define MMU__PHYSMAP                              0x00000100UL
-#define MMU__PINPAGE                              0x00000200UL
-#define MMU__MFNLIST                              0x00000400UL
-#define MMU__MEMORYMAP                            0x00000800UL
-#define MMU__REMOTE_REMAP                         0x00001000UL
-#define MMU__MMUEXT_OP                            0x00002000UL
-#define MMU__EXCHANGE                             0x00004000UL
-
-#define SHADOW__DISABLE                           0x00000001UL
-#define SHADOW__ENABLE                            0x00000002UL
-#define SHADOW__LOGDIRTY                          0x00000004UL
-
-#define RESOURCE__ADD                             0x00000001UL
-#define RESOURCE__REMOVE                          0x00000002UL
-#define RESOURCE__USE                             0x00000004UL
-#define RESOURCE__ADD_IRQ                         0x00000008UL
-#define RESOURCE__REMOVE_IRQ                      0x00000010UL
-#define RESOURCE__ADD_IOPORT                      0x00000020UL
-#define RESOURCE__REMOVE_IOPORT                   0x00000040UL
-#define RESOURCE__ADD_IOMEM                       0x00000080UL
-#define RESOURCE__REMOVE_IOMEM                    0x00000100UL
-#define RESOURCE__STAT_DEVICE                     0x00000200UL
-#define RESOURCE__ADD_DEVICE                      0x00000400UL
-#define RESOURCE__REMOVE_DEVICE                   0x00000800UL
-#define RESOURCE__PLUG                            0x00001000UL
-#define RESOURCE__UNPLUG                          0x00002000UL
-#define RESOURCE__SETUP                           0x00004000UL
-
-#define SECURITY__COMPUTE_AV                      0x00000001UL
-#define SECURITY__COMPUTE_CREATE                  0x00000002UL
-#define SECURITY__COMPUTE_MEMBER                  0x00000004UL
-#define SECURITY__CHECK_CONTEXT                   0x00000008UL
-#define SECURITY__LOAD_POLICY                     0x00000010UL
-#define SECURITY__COMPUTE_RELABEL                 0x00000020UL
-#define SECURITY__COMPUTE_USER                    0x00000040UL
-#define SECURITY__SETENFORCE                      0x00000080UL
-#define SECURITY__SETBOOL                         0x00000100UL
-#define SECURITY__SETSECPARAM                     0x00000200UL
-#define SECURITY__ADD_OCONTEXT                    0x00000400UL
-#define SECURITY__DEL_OCONTEXT                    0x00000800UL
-
diff --git a/xen/xsm/flask/include/class_to_string.h b/xen/xsm/flask/include/class_to_string.h
deleted file mode 100644
index 7716645..0000000
--- a/xen/xsm/flask/include/class_to_string.h
+++ /dev/null
@@ -1,15 +0,0 @@
-/* This file is automatically generated.  Do not edit. */
-/*
- * Security object class definitions
- */
-    S_("null")
-    S_("xen")
-    S_("domain")
-    S_("domain2")
-    S_("hvm")
-    S_("mmu")
-    S_("resource")
-    S_("shadow")
-    S_("event")
-    S_("grant")
-    S_("security")
diff --git a/xen/xsm/flask/include/flask.h b/xen/xsm/flask/include/flask.h
deleted file mode 100644
index 3bff998..0000000
--- a/xen/xsm/flask/include/flask.h
+++ /dev/null
@@ -1,35 +0,0 @@
-/* This file is automatically generated.  Do not edit. */
-#ifndef _SELINUX_FLASK_H_
-#define _SELINUX_FLASK_H_
-
-/*
- * Security object class definitions
- */
-#define SECCLASS_XEN                                     1
-#define SECCLASS_DOMAIN                                  2
-#define SECCLASS_DOMAIN2                                 3
-#define SECCLASS_HVM                                     4
-#define SECCLASS_MMU                                     5
-#define SECCLASS_RESOURCE                                6
-#define SECCLASS_SHADOW                                  7
-#define SECCLASS_EVENT                                   8
-#define SECCLASS_GRANT                                   9
-#define SECCLASS_SECURITY                                10
-
-/*
- * Security identifier indices for initial entities
- */
-#define SECINITSID_XEN                                  1
-#define SECINITSID_DOM0                                 2
-#define SECINITSID_DOMIO                                3
-#define SECINITSID_DOMXEN                               4
-#define SECINITSID_UNLABELED                            5
-#define SECINITSID_SECURITY                             6
-#define SECINITSID_IOPORT                               7
-#define SECINITSID_IOMEM                                8
-#define SECINITSID_IRQ                                  9
-#define SECINITSID_DEVICE                               10
-
-#define SECINITSID_NUM                                  10
-
-#endif
diff --git a/xen/xsm/flask/include/initial_sid_to_string.h b/xen/xsm/flask/include/initial_sid_to_string.h
deleted file mode 100644
index 814f4bf..0000000
--- a/xen/xsm/flask/include/initial_sid_to_string.h
+++ /dev/null
@@ -1,16 +0,0 @@
-/* This file is automatically generated.  Do not edit. */
-static char *initial_sid_to_string[] =
-{
-    "null",
-    "xen",
-    "dom0",
-    "domio",
-    "domxen",
-    "unlabeled",
-    "security",
-    "ioport",
-    "iomem",
-    "irq",
-    "device",
-};
-
diff --git a/tools/flask/policy/policy/flask/access_vectors b/xen/xsm/flask/policy/access_vectors
similarity index 100%
rename from tools/flask/policy/policy/flask/access_vectors
rename to xen/xsm/flask/policy/access_vectors
diff --git a/tools/flask/policy/policy/flask/initial_sids b/xen/xsm/flask/policy/initial_sids
similarity index 100%
rename from tools/flask/policy/policy/flask/initial_sids
rename to xen/xsm/flask/policy/initial_sids
diff --git a/tools/flask/policy/policy/flask/mkaccess_vector.sh b/xen/xsm/flask/policy/mkaccess_vector.sh
similarity index 97%
rename from tools/flask/policy/policy/flask/mkaccess_vector.sh
rename to xen/xsm/flask/policy/mkaccess_vector.sh
index 43a60a7..8ec87f7 100644
--- a/tools/flask/policy/policy/flask/mkaccess_vector.sh
+++ b/xen/xsm/flask/policy/mkaccess_vector.sh
@@ -9,8 +9,8 @@ awk=$1
 shift
 
 # output files
-av_permissions="av_permissions.h"
-av_perm_to_string="av_perm_to_string.h"
+av_permissions="include/av_permissions.h"
+av_perm_to_string="include/av_perm_to_string.h"
 
 cat $* | $awk "
 BEGIN	{
diff --git a/tools/flask/policy/policy/flask/mkflask.sh b/xen/xsm/flask/policy/mkflask.sh
similarity index 95%
rename from tools/flask/policy/policy/flask/mkflask.sh
rename to xen/xsm/flask/policy/mkflask.sh
index 9c84754..e8d8fb5 100644
--- a/tools/flask/policy/policy/flask/mkflask.sh
+++ b/xen/xsm/flask/policy/mkflask.sh
@@ -9,9 +9,9 @@ awk=$1
 shift 1
 
 # output file
-output_file="flask.h"
-debug_file="class_to_string.h"
-debug_file2="initial_sid_to_string.h"
+output_file="include/flask.h"
+debug_file="include/class_to_string.h"
+debug_file2="include/initial_sid_to_string.h"
 
 cat $* | $awk "
 BEGIN	{
diff --git a/tools/flask/policy/policy/flask/security_classes b/xen/xsm/flask/policy/security_classes
similarity index 100%
rename from tools/flask/policy/policy/flask/security_classes
rename to xen/xsm/flask/policy/security_classes
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 18:32:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 18:32:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLebH-0007EP-Ry; Tue, 09 Oct 2012 18:32:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLebG-0007EK-20
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 18:32:14 +0000
Received: from [85.158.143.99:40393] by server-1.bemta-4.messagelabs.com id
	98/D1-05684-DAD64705; Tue, 09 Oct 2012 18:32:13 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-11.tower-216.messagelabs.com!1349807530!25946856!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6419 invoked from network); 9 Oct 2012 18:32:11 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-11.tower-216.messagelabs.com with SMTP;
	9 Oct 2012 18:32:11 -0000
X-TM-IMSS-Message-ID: 
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1;
	TLSv1/SSLv3 DHE-RSA-AES256-SHA (256/256)) id c577aa4300004cda ;
	Tue, 9 Oct 2012 14:32:04 -0400
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q99IW8No005541; 
	Tue, 9 Oct 2012 14:32:08 -0400
From: Daniel De Graaf 
To: Ian Campbell ,
	Dario Faggioli 
Date: Tue,  9 Oct 2012 14:31:53 -0400
Message-Id: <1349807513-10923-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1349801565.21847.228.camel@zakaz.uk.xensource.com>
References: <1349801565.21847.228.camel@zakaz.uk.xensource.com>
Cc: Marcus.Granado@eu.citrix.com, andre.przywara@amd.com, msw@amazon.com,
	anil@recoil.org, George.Dunlap@eu.citrix.com,
	Andrew.Cooper3@citrix.com, juergen.gross@ts.fujitsu.com,
	Ian.Jackson@eu.citrix.com, xen-devel@lists.xen.org,
	JBeulich@suse.com, Daniel De Graaf 
Subject: [Xen-devel] [PATCH RFC] flask: move policy header sources into
	hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell wrote:
[...]
>>> +++ b/xen/xsm/flask/include/av_perm_to_string.h
> Also, in that case why is this file checked in?

This patch fixes the autogenerated files, but doesn't fully wire them in
to things like "make clean" or .{git,hg}ignore. I don't see an obvious
way to clean generated header files in Xen's build system; perhaps
someone who knows the build system better can point out the right way to
wire this up.

--------------------------------------->8----------------------------

Rather than keeping around headers that are autogenerated in order to
avoid adding build dependencies from xen/ to files in tools/, move the
relevant parts of the FLASK policy into the hypervisor tree and generate
the headers as part of the hypervisor's build.

Signed-off-by: Daniel De Graaf 
---
 tools/flask/policy/Makefile                        |   2 +-
 tools/flask/policy/policy/flask/Makefile           |  41 ------
 xen/xsm/flask/Makefile                             |  21 +++
 xen/xsm/flask/include/av_perm_to_string.h          | 147 -------------------
 xen/xsm/flask/include/av_permissions.h             | 157 ---------------------
 xen/xsm/flask/include/class_to_string.h            |  15 --
 xen/xsm/flask/include/flask.h                      |  35 -----
 xen/xsm/flask/include/initial_sid_to_string.h      |  16 ---
 .../flask => xen/xsm/flask/policy}/access_vectors  |   0
 .../flask => xen/xsm/flask/policy}/initial_sids    |   0
 .../xsm/flask/policy}/mkaccess_vector.sh           |   4 +-
 .../flask => xen/xsm/flask/policy}/mkflask.sh      |   6 +-
 .../xsm/flask/policy}/security_classes             |   0
 13 files changed, 27 insertions(+), 417 deletions(-)
 delete mode 100644 tools/flask/policy/policy/flask/Makefile
 delete mode 100644 xen/xsm/flask/include/av_perm_to_string.h
 delete mode 100644 xen/xsm/flask/include/av_permissions.h
 delete mode 100644 xen/xsm/flask/include/class_to_string.h
 delete mode 100644 xen/xsm/flask/include/flask.h
 delete mode 100644 xen/xsm/flask/include/initial_sid_to_string.h
 rename {tools/flask/policy/policy/flask => xen/xsm/flask/policy}/access_vectors (100%)
 rename {tools/flask/policy/policy/flask => xen/xsm/flask/policy}/initial_sids (100%)
 rename {tools/flask/policy/policy/flask => xen/xsm/flask/policy}/mkaccess_vector.sh (97%)
 rename {tools/flask/policy/policy/flask => xen/xsm/flask/policy}/mkflask.sh (95%)
 rename {tools/flask/policy/policy/flask => xen/xsm/flask/policy}/security_classes (100%)

diff --git a/tools/flask/policy/Makefile b/tools/flask/policy/Makefile
index 5c25cbe..3f5aa38 100644
--- a/tools/flask/policy/Makefile
+++ b/tools/flask/policy/Makefile
@@ -61,7 +61,7 @@ LOADPOLICY := $(SBINDIR)/flask-loadpolicy
 # policy source layout
 POLDIR := policy
 MODDIR := $(POLDIR)/modules
-FLASKDIR := $(POLDIR)/flask
+FLASKDIR := ../../../xen/xsm/flask/policy
 SECCLASS := $(FLASKDIR)/security_classes
 ISIDS := $(FLASKDIR)/initial_sids
 AVS := $(FLASKDIR)/access_vectors
diff --git a/tools/flask/policy/policy/flask/Makefile b/tools/flask/policy/policy/flask/Makefile
deleted file mode 100644
index 5f57e88..0000000
--- a/tools/flask/policy/policy/flask/Makefile
+++ /dev/null
@@ -1,41 +0,0 @@
-# flask needs to know where to export the libselinux headers.
-LIBSEL ?= ../../libselinux
-
-# flask needs to know where to export the kernel headers.
-LINUXDIR ?= ../../../linux-2.6
-
-AWK = awk
-
-CONFIG_SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; \
-          else if [ -x /bin/bash ]; then echo /bin/bash; \
-          else echo sh; fi ; fi)
-
-FLASK_H_DEPEND = security_classes initial_sids
-AV_H_DEPEND = access_vectors
-
-FLASK_H_FILES = class_to_string.h flask.h initial_sid_to_string.h
-AV_H_FILES = av_perm_to_string.h av_permissions.h
-ALL_H_FILES = $(FLASK_H_FILES) $(AV_H_FILES)
-
-all:  $(ALL_H_FILES)
-
-$(FLASK_H_FILES): $(FLASK_H_DEPEND)
-	$(CONFIG_SHELL) mkflask.sh $(AWK) $(FLASK_H_DEPEND)
-
-$(AV_H_FILES): $(AV_H_DEPEND)
-	$(CONFIG_SHELL) mkaccess_vector.sh $(AWK) $(AV_H_DEPEND)
-
-tolib: all
-	install -m 644 flask.h av_permissions.h $(LIBSEL)/include/selinux
-	install -m 644 class_to_string.h av_inherit.h common_perm_to_string.h av_perm_to_string.h $(LIBSEL)/src
-
-tokern: all
-	install -m 644 $(ALL_H_FILES) $(LINUXDIR)/security/selinux/include
-
-install: all
-
-relabel:
-
-clean:  
-	rm -f $(FLASK_H_FILES)
-	rm -f $(AV_H_FILES)
diff --git a/xen/xsm/flask/Makefile b/xen/xsm/flask/Makefile
index 92fb410..238495a 100644
--- a/xen/xsm/flask/Makefile
+++ b/xen/xsm/flask/Makefile
@@ -5,3 +5,24 @@ obj-y += flask_op.o
 subdir-y += ss
 
 CFLAGS += -I./include
+
+AWK = awk
+
+CONFIG_SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; \
+          else if [ -x /bin/bash ]; then echo /bin/bash; \
+          else echo sh; fi ; fi)
+
+FLASK_H_DEPEND = policy/security_classes policy/initial_sids
+AV_H_DEPEND = policy/access_vectors
+
+FLASK_H_FILES = include/flask.h include/class_to_string.h include/initial_sid_to_string.h
+AV_H_FILES = include/av_perm_to_string.h include/av_permissions.h
+ALL_H_FILES = $(FLASK_H_FILES) $(AV_H_FILES)
+
+$(obj-y) ss/built_in.o: $(ALL_H_FILES)
+
+$(FLASK_H_FILES): $(FLASK_H_DEPEND)
+	$(CONFIG_SHELL) policy/mkflask.sh $(AWK) $(FLASK_H_DEPEND)
+
+$(AV_H_FILES): $(AV_H_DEPEND)
+	$(CONFIG_SHELL) policy/mkaccess_vector.sh $(AWK) $(AV_H_DEPEND)
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
deleted file mode 100644
index c3f2370..0000000
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ /dev/null
@@ -1,147 +0,0 @@
-/* This file is automatically generated.  Do not edit. */
-   S_(SECCLASS_XEN, XEN__SCHEDULER, "scheduler")
-   S_(SECCLASS_XEN, XEN__SETTIME, "settime")
-   S_(SECCLASS_XEN, XEN__TBUFCONTROL, "tbufcontrol")
-   S_(SECCLASS_XEN, XEN__READCONSOLE, "readconsole")
-   S_(SECCLASS_XEN, XEN__CLEARCONSOLE, "clearconsole")
-   S_(SECCLASS_XEN, XEN__PERFCONTROL, "perfcontrol")
-   S_(SECCLASS_XEN, XEN__MTRR_ADD, "mtrr_add")
-   S_(SECCLASS_XEN, XEN__MTRR_DEL, "mtrr_del")
-   S_(SECCLASS_XEN, XEN__MTRR_READ, "mtrr_read")
-   S_(SECCLASS_XEN, XEN__MICROCODE, "microcode")
-   S_(SECCLASS_XEN, XEN__PHYSINFO, "physinfo")
-   S_(SECCLASS_XEN, XEN__QUIRK, "quirk")
-   S_(SECCLASS_XEN, XEN__WRITECONSOLE, "writeconsole")
-   S_(SECCLASS_XEN, XEN__READAPIC, "readapic")
-   S_(SECCLASS_XEN, XEN__WRITEAPIC, "writeapic")
-   S_(SECCLASS_XEN, XEN__PRIVPROFILE, "privprofile")
-   S_(SECCLASS_XEN, XEN__NONPRIVPROFILE, "nonprivprofile")
-   S_(SECCLASS_XEN, XEN__KEXEC, "kexec")
-   S_(SECCLASS_XEN, XEN__FIRMWARE, "firmware")
-   S_(SECCLASS_XEN, XEN__SLEEP, "sleep")
-   S_(SECCLASS_XEN, XEN__FREQUENCY, "frequency")
-   S_(SECCLASS_XEN, XEN__GETIDLE, "getidle")
-   S_(SECCLASS_XEN, XEN__DEBUG, "debug")
-   S_(SECCLASS_XEN, XEN__GETCPUINFO, "getcpuinfo")
-   S_(SECCLASS_XEN, XEN__HEAP, "heap")
-   S_(SECCLASS_XEN, XEN__PM_OP, "pm_op")
-   S_(SECCLASS_XEN, XEN__MCA_OP, "mca_op")
-   S_(SECCLASS_XEN, XEN__LOCKPROF, "lockprof")
-   S_(SECCLASS_XEN, XEN__CPUPOOL_OP, "cpupool_op")
-   S_(SECCLASS_XEN, XEN__SCHED_OP, "sched_op")
-   S_(SECCLASS_XEN, XEN__TMEM_OP, "tmem_op")
-   S_(SECCLASS_XEN, XEN__TMEM_CONTROL, "tmem_control")
-   S_(SECCLASS_DOMAIN, DOMAIN__SETVCPUCONTEXT, "setvcpucontext")
-   S_(SECCLASS_DOMAIN, DOMAIN__PAUSE, "pause")
-   S_(SECCLASS_DOMAIN, DOMAIN__UNPAUSE, "unpause")
-   S_(SECCLASS_DOMAIN, DOMAIN__RESUME, "resume")
-   S_(SECCLASS_DOMAIN, DOMAIN__CREATE, "create")
-   S_(SECCLASS_DOMAIN, DOMAIN__TRANSITION, "transition")
-   S_(SECCLASS_DOMAIN, DOMAIN__MAX_VCPUS, "max_vcpus")
-   S_(SECCLASS_DOMAIN, DOMAIN__DESTROY, "destroy")
-   S_(SECCLASS_DOMAIN, DOMAIN__SETVCPUAFFINITY, "setvcpuaffinity")
-   S_(SECCLASS_DOMAIN, DOMAIN__GETVCPUAFFINITY, "getvcpuaffinity")
-   S_(SECCLASS_DOMAIN, DOMAIN__SCHEDULER, "scheduler")
-   S_(SECCLASS_DOMAIN, DOMAIN__GETDOMAININFO, "getdomaininfo")
-   S_(SECCLASS_DOMAIN, DOMAIN__GETVCPUINFO, "getvcpuinfo")
-   S_(SECCLASS_DOMAIN, DOMAIN__GETVCPUCONTEXT, "getvcpucontext")
-   S_(SECCLASS_DOMAIN, DOMAIN__SETDOMAINMAXMEM, "setdomainmaxmem")
-   S_(SECCLASS_DOMAIN, DOMAIN__SETDOMAINHANDLE, "setdomainhandle")
-   S_(SECCLASS_DOMAIN, DOMAIN__SETDEBUGGING, "setdebugging")
-   S_(SECCLASS_DOMAIN, DOMAIN__HYPERCALL, "hypercall")
-   S_(SECCLASS_DOMAIN, DOMAIN__SETTIME, "settime")
-   S_(SECCLASS_DOMAIN, DOMAIN__SET_TARGET, "set_target")
-   S_(SECCLASS_DOMAIN, DOMAIN__SHUTDOWN, "shutdown")
-   S_(SECCLASS_DOMAIN, DOMAIN__SETADDRSIZE, "setaddrsize")
-   S_(SECCLASS_DOMAIN, DOMAIN__GETADDRSIZE, "getaddrsize")
-   S_(SECCLASS_DOMAIN, DOMAIN__TRIGGER, "trigger")
-   S_(SECCLASS_DOMAIN, DOMAIN__GETEXTVCPUCONTEXT, "getextvcpucontext")
-   S_(SECCLASS_DOMAIN, DOMAIN__SETEXTVCPUCONTEXT, "setextvcpucontext")
-   S_(SECCLASS_DOMAIN, DOMAIN__GETVCPUEXTSTATE, "getvcpuextstate")
-   S_(SECCLASS_DOMAIN, DOMAIN__SETVCPUEXTSTATE, "setvcpuextstate")
-   S_(SECCLASS_DOMAIN, DOMAIN__GETPODTARGET, "getpodtarget")
-   S_(SECCLASS_DOMAIN, DOMAIN__SETPODTARGET, "setpodtarget")
-   S_(SECCLASS_DOMAIN, DOMAIN__SET_MISC_INFO, "set_misc_info")
-   S_(SECCLASS_DOMAIN, DOMAIN__SET_VIRQ_HANDLER, "set_virq_handler")
-   S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELFROM, "relabelfrom")
-   S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELTO, "relabelto")
-   S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELSELF, "relabelself")
-   S_(SECCLASS_DOMAIN2, DOMAIN2__MAKE_PRIV_FOR, "make_priv_for")
-   S_(SECCLASS_DOMAIN2, DOMAIN2__SET_AS_TARGET, "set_as_target")
-   S_(SECCLASS_DOMAIN2, DOMAIN2__SET_CPUID, "set_cpuid")
-   S_(SECCLASS_DOMAIN2, DOMAIN2__GETTSC, "gettsc")
-   S_(SECCLASS_DOMAIN2, DOMAIN2__SETTSC, "settsc")
-   S_(SECCLASS_HVM, HVM__SETHVMC, "sethvmc")
-   S_(SECCLASS_HVM, HVM__GETHVMC, "gethvmc")
-   S_(SECCLASS_HVM, HVM__SETPARAM, "setparam")
-   S_(SECCLASS_HVM, HVM__GETPARAM, "getparam")
-   S_(SECCLASS_HVM, HVM__PCILEVEL, "pcilevel")
-   S_(SECCLASS_HVM, HVM__IRQLEVEL, "irqlevel")
-   S_(SECCLASS_HVM, HVM__PCIROUTE, "pciroute")
-   S_(SECCLASS_HVM, HVM__BIND_IRQ, "bind_irq")
-   S_(SECCLASS_HVM, HVM__CACHEATTR, "cacheattr")
-   S_(SECCLASS_HVM, HVM__TRACKDIRTYVRAM, "trackdirtyvram")
-   S_(SECCLASS_HVM, HVM__HVMCTL, "hvmctl")
-   S_(SECCLASS_HVM, HVM__MEM_EVENT, "mem_event")
-   S_(SECCLASS_HVM, HVM__MEM_SHARING, "mem_sharing")
-   S_(SECCLASS_HVM, HVM__AUDIT_P2M, "audit_p2m")
-   S_(SECCLASS_HVM, HVM__SEND_IRQ, "send_irq")
-   S_(SECCLASS_HVM, HVM__SHARE_MEM, "share_mem")
-   S_(SECCLASS_EVENT, EVENT__BIND, "bind")
-   S_(SECCLASS_EVENT, EVENT__SEND, "send")
-   S_(SECCLASS_EVENT, EVENT__STATUS, "status")
-   S_(SECCLASS_EVENT, EVENT__NOTIFY, "notify")
-   S_(SECCLASS_EVENT, EVENT__CREATE, "create")
-   S_(SECCLASS_EVENT, EVENT__RESET, "reset")
-   S_(SECCLASS_GRANT, GRANT__MAP_READ, "map_read")
-   S_(SECCLASS_GRANT, GRANT__MAP_WRITE, "map_write")
-   S_(SECCLASS_GRANT, GRANT__UNMAP, "unmap")
-   S_(SECCLASS_GRANT, GRANT__TRANSFER, "transfer")
-   S_(SECCLASS_GRANT, GRANT__SETUP, "setup")
-   S_(SECCLASS_GRANT, GRANT__COPY, "copy")
-   S_(SECCLASS_GRANT, GRANT__QUERY, "query")
-   S_(SECCLASS_MMU, MMU__MAP_READ, "map_read")
-   S_(SECCLASS_MMU, MMU__MAP_WRITE, "map_write")
-   S_(SECCLASS_MMU, MMU__PAGEINFO, "pageinfo")
-   S_(SECCLASS_MMU, MMU__PAGELIST, "pagelist")
-   S_(SECCLASS_MMU, MMU__ADJUST, "adjust")
-   S_(SECCLASS_MMU, MMU__STAT, "stat")
-   S_(SECCLASS_MMU, MMU__TRANSLATEGP, "translategp")
-   S_(SECCLASS_MMU, MMU__UPDATEMP, "updatemp")
-   S_(SECCLASS_MMU, MMU__PHYSMAP, "physmap")
-   S_(SECCLASS_MMU, MMU__PINPAGE, "pinpage")
-   S_(SECCLASS_MMU, MMU__MFNLIST, "mfnlist")
-   S_(SECCLASS_MMU, MMU__MEMORYMAP, "memorymap")
-   S_(SECCLASS_MMU, MMU__REMOTE_REMAP, "remote_remap")
-   S_(SECCLASS_MMU, MMU__MMUEXT_OP, "mmuext_op")
-   S_(SECCLASS_MMU, MMU__EXCHANGE, "exchange")
-   S_(SECCLASS_SHADOW, SHADOW__DISABLE, "disable")
-   S_(SECCLASS_SHADOW, SHADOW__ENABLE, "enable")
-   S_(SECCLASS_SHADOW, SHADOW__LOGDIRTY, "logdirty")
-   S_(SECCLASS_RESOURCE, RESOURCE__ADD, "add")
-   S_(SECCLASS_RESOURCE, RESOURCE__REMOVE, "remove")
-   S_(SECCLASS_RESOURCE, RESOURCE__USE, "use")
-   S_(SECCLASS_RESOURCE, RESOURCE__ADD_IRQ, "add_irq")
-   S_(SECCLASS_RESOURCE, RESOURCE__REMOVE_IRQ, "remove_irq")
-   S_(SECCLASS_RESOURCE, RESOURCE__ADD_IOPORT, "add_ioport")
-   S_(SECCLASS_RESOURCE, RESOURCE__REMOVE_IOPORT, "remove_ioport")
-   S_(SECCLASS_RESOURCE, RESOURCE__ADD_IOMEM, "add_iomem")
-   S_(SECCLASS_RESOURCE, RESOURCE__REMOVE_IOMEM, "remove_iomem")
-   S_(SECCLASS_RESOURCE, RESOURCE__STAT_DEVICE, "stat_device")
-   S_(SECCLASS_RESOURCE, RESOURCE__ADD_DEVICE, "add_device")
-   S_(SECCLASS_RESOURCE, RESOURCE__REMOVE_DEVICE, "remove_device")
-   S_(SECCLASS_RESOURCE, RESOURCE__PLUG, "plug")
-   S_(SECCLASS_RESOURCE, RESOURCE__UNPLUG, "unplug")
-   S_(SECCLASS_RESOURCE, RESOURCE__SETUP, "setup")
-   S_(SECCLASS_SECURITY, SECURITY__COMPUTE_AV, "compute_av")
-   S_(SECCLASS_SECURITY, SECURITY__COMPUTE_CREATE, "compute_create")
-   S_(SECCLASS_SECURITY, SECURITY__COMPUTE_MEMBER, "compute_member")
-   S_(SECCLASS_SECURITY, SECURITY__CHECK_CONTEXT, "check_context")
-   S_(SECCLASS_SECURITY, SECURITY__LOAD_POLICY, "load_policy")
-   S_(SECCLASS_SECURITY, SECURITY__COMPUTE_RELABEL, "compute_relabel")
-   S_(SECCLASS_SECURITY, SECURITY__COMPUTE_USER, "compute_user")
-   S_(SECCLASS_SECURITY, SECURITY__SETENFORCE, "setenforce")
-   S_(SECCLASS_SECURITY, SECURITY__SETBOOL, "setbool")
-   S_(SECCLASS_SECURITY, SECURITY__SETSECPARAM, "setsecparam")
-   S_(SECCLASS_SECURITY, SECURITY__ADD_OCONTEXT, "add_ocontext")
-   S_(SECCLASS_SECURITY, SECURITY__DEL_OCONTEXT, "del_ocontext")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
deleted file mode 100644
index 65302e8..0000000
--- a/xen/xsm/flask/include/av_permissions.h
+++ /dev/null
@@ -1,157 +0,0 @@
-/* This file is automatically generated.  Do not edit. */
-#define XEN__SCHEDULER                            0x00000001UL
-#define XEN__SETTIME                              0x00000002UL
-#define XEN__TBUFCONTROL                          0x00000004UL
-#define XEN__READCONSOLE                          0x00000008UL
-#define XEN__CLEARCONSOLE                         0x00000010UL
-#define XEN__PERFCONTROL                          0x00000020UL
-#define XEN__MTRR_ADD                             0x00000040UL
-#define XEN__MTRR_DEL                             0x00000080UL
-#define XEN__MTRR_READ                            0x00000100UL
-#define XEN__MICROCODE                            0x00000200UL
-#define XEN__PHYSINFO                             0x00000400UL
-#define XEN__QUIRK                                0x00000800UL
-#define XEN__WRITECONSOLE                         0x00001000UL
-#define XEN__READAPIC                             0x00002000UL
-#define XEN__WRITEAPIC                            0x00004000UL
-#define XEN__PRIVPROFILE                          0x00008000UL
-#define XEN__NONPRIVPROFILE                       0x00010000UL
-#define XEN__KEXEC                                0x00020000UL
-#define XEN__FIRMWARE                             0x00040000UL
-#define XEN__SLEEP                                0x00080000UL
-#define XEN__FREQUENCY                            0x00100000UL
-#define XEN__GETIDLE                              0x00200000UL
-#define XEN__DEBUG                                0x00400000UL
-#define XEN__GETCPUINFO                           0x00800000UL
-#define XEN__HEAP                                 0x01000000UL
-#define XEN__PM_OP                                0x02000000UL
-#define XEN__MCA_OP                               0x04000000UL
-#define XEN__LOCKPROF                             0x08000000UL
-#define XEN__CPUPOOL_OP                           0x10000000UL
-#define XEN__SCHED_OP                             0x20000000UL
-#define XEN__TMEM_OP                              0x40000000UL
-#define XEN__TMEM_CONTROL                         0x80000000UL
-
-#define DOMAIN__SETVCPUCONTEXT                    0x00000001UL
-#define DOMAIN__PAUSE                             0x00000002UL
-#define DOMAIN__UNPAUSE                           0x00000004UL
-#define DOMAIN__RESUME                            0x00000008UL
-#define DOMAIN__CREATE                            0x00000010UL
-#define DOMAIN__TRANSITION                        0x00000020UL
-#define DOMAIN__MAX_VCPUS                         0x00000040UL
-#define DOMAIN__DESTROY                           0x00000080UL
-#define DOMAIN__SETVCPUAFFINITY                   0x00000100UL
-#define DOMAIN__GETVCPUAFFINITY                   0x00000200UL
-#define DOMAIN__SCHEDULER                         0x00000400UL
-#define DOMAIN__GETDOMAININFO                     0x00000800UL
-#define DOMAIN__GETVCPUINFO                       0x00001000UL
-#define DOMAIN__GETVCPUCONTEXT                    0x00002000UL
-#define DOMAIN__SETDOMAINMAXMEM                   0x00004000UL
-#define DOMAIN__SETDOMAINHANDLE                   0x00008000UL
-#define DOMAIN__SETDEBUGGING                      0x00010000UL
-#define DOMAIN__HYPERCALL                         0x00020000UL
-#define DOMAIN__SETTIME                           0x00040000UL
-#define DOMAIN__SET_TARGET                        0x00080000UL
-#define DOMAIN__SHUTDOWN                          0x00100000UL
-#define DOMAIN__SETADDRSIZE                       0x00200000UL
-#define DOMAIN__GETADDRSIZE                       0x00400000UL
-#define DOMAIN__TRIGGER                           0x00800000UL
-#define DOMAIN__GETEXTVCPUCONTEXT                 0x01000000UL
-#define DOMAIN__SETEXTVCPUCONTEXT                 0x02000000UL
-#define DOMAIN__GETVCPUEXTSTATE                   0x04000000UL
-#define DOMAIN__SETVCPUEXTSTATE                   0x08000000UL
-#define DOMAIN__GETPODTARGET                      0x10000000UL
-#define DOMAIN__SETPODTARGET                      0x20000000UL
-#define DOMAIN__SET_MISC_INFO                     0x40000000UL
-#define DOMAIN__SET_VIRQ_HANDLER                  0x80000000UL
-
-#define DOMAIN2__RELABELFROM                      0x00000001UL
-#define DOMAIN2__RELABELTO                        0x00000002UL
-#define DOMAIN2__RELABELSELF                      0x00000004UL
-#define DOMAIN2__MAKE_PRIV_FOR                    0x00000008UL
-#define DOMAIN2__SET_AS_TARGET                    0x00000010UL
-#define DOMAIN2__SET_CPUID                        0x00000020UL
-#define DOMAIN2__GETTSC                           0x00000040UL
-#define DOMAIN2__SETTSC                           0x00000080UL
-
-#define HVM__SETHVMC                              0x00000001UL
-#define HVM__GETHVMC                              0x00000002UL
-#define HVM__SETPARAM                             0x00000004UL
-#define HVM__GETPARAM                             0x00000008UL
-#define HVM__PCILEVEL                             0x00000010UL
-#define HVM__IRQLEVEL                             0x00000020UL
-#define HVM__PCIROUTE                             0x00000040UL
-#define HVM__BIND_IRQ                             0x00000080UL
-#define HVM__CACHEATTR                            0x00000100UL
-#define HVM__TRACKDIRTYVRAM                       0x00000200UL
-#define HVM__HVMCTL                               0x00000400UL
-#define HVM__MEM_EVENT                            0x00000800UL
-#define HVM__MEM_SHARING                          0x00001000UL
-#define HVM__AUDIT_P2M                            0x00002000UL
-#define HVM__SEND_IRQ                             0x00004000UL
-#define HVM__SHARE_MEM                            0x00008000UL
-
-#define EVENT__BIND                               0x00000001UL
-#define EVENT__SEND                               0x00000002UL
-#define EVENT__STATUS                             0x00000004UL
-#define EVENT__NOTIFY                             0x00000008UL
-#define EVENT__CREATE                             0x00000010UL
-#define EVENT__RESET                              0x00000020UL
-
-#define GRANT__MAP_READ                           0x00000001UL
-#define GRANT__MAP_WRITE                          0x00000002UL
-#define GRANT__UNMAP                              0x00000004UL
-#define GRANT__TRANSFER                           0x00000008UL
-#define GRANT__SETUP                              0x00000010UL
-#define GRANT__COPY                               0x00000020UL
-#define GRANT__QUERY                              0x00000040UL
-
-#define MMU__MAP_READ                             0x00000001UL
-#define MMU__MAP_WRITE                            0x00000002UL
-#define MMU__PAGEINFO                             0x00000004UL
-#define MMU__PAGELIST                             0x00000008UL
-#define MMU__ADJUST                               0x00000010UL
-#define MMU__STAT                                 0x00000020UL
-#define MMU__TRANSLATEGP                          0x00000040UL
-#define MMU__UPDATEMP                             0x00000080UL
-#define MMU__PHYSMAP                              0x00000100UL
-#define MMU__PINPAGE                              0x00000200UL
-#define MMU__MFNLIST                              0x00000400UL
-#define MMU__MEMORYMAP                            0x00000800UL
-#define MMU__REMOTE_REMAP                         0x00001000UL
-#define MMU__MMUEXT_OP                            0x00002000UL
-#define MMU__EXCHANGE                             0x00004000UL
-
-#define SHADOW__DISABLE                           0x00000001UL
-#define SHADOW__ENABLE                            0x00000002UL
-#define SHADOW__LOGDIRTY                          0x00000004UL
-
-#define RESOURCE__ADD                             0x00000001UL
-#define RESOURCE__REMOVE                          0x00000002UL
-#define RESOURCE__USE                             0x00000004UL
-#define RESOURCE__ADD_IRQ                         0x00000008UL
-#define RESOURCE__REMOVE_IRQ                      0x00000010UL
-#define RESOURCE__ADD_IOPORT                      0x00000020UL
-#define RESOURCE__REMOVE_IOPORT                   0x00000040UL
-#define RESOURCE__ADD_IOMEM                       0x00000080UL
-#define RESOURCE__REMOVE_IOMEM                    0x00000100UL
-#define RESOURCE__STAT_DEVICE                     0x00000200UL
-#define RESOURCE__ADD_DEVICE                      0x00000400UL
-#define RESOURCE__REMOVE_DEVICE                   0x00000800UL
-#define RESOURCE__PLUG                            0x00001000UL
-#define RESOURCE__UNPLUG                          0x00002000UL
-#define RESOURCE__SETUP                           0x00004000UL
-
-#define SECURITY__COMPUTE_AV                      0x00000001UL
-#define SECURITY__COMPUTE_CREATE                  0x00000002UL
-#define SECURITY__COMPUTE_MEMBER                  0x00000004UL
-#define SECURITY__CHECK_CONTEXT                   0x00000008UL
-#define SECURITY__LOAD_POLICY                     0x00000010UL
-#define SECURITY__COMPUTE_RELABEL                 0x00000020UL
-#define SECURITY__COMPUTE_USER                    0x00000040UL
-#define SECURITY__SETENFORCE                      0x00000080UL
-#define SECURITY__SETBOOL                         0x00000100UL
-#define SECURITY__SETSECPARAM                     0x00000200UL
-#define SECURITY__ADD_OCONTEXT                    0x00000400UL
-#define SECURITY__DEL_OCONTEXT                    0x00000800UL
-
diff --git a/xen/xsm/flask/include/class_to_string.h b/xen/xsm/flask/include/class_to_string.h
deleted file mode 100644
index 7716645..0000000
--- a/xen/xsm/flask/include/class_to_string.h
+++ /dev/null
@@ -1,15 +0,0 @@
-/* This file is automatically generated.  Do not edit. */
-/*
- * Security object class definitions
- */
-    S_("null")
-    S_("xen")
-    S_("domain")
-    S_("domain2")
-    S_("hvm")
-    S_("mmu")
-    S_("resource")
-    S_("shadow")
-    S_("event")
-    S_("grant")
-    S_("security")
diff --git a/xen/xsm/flask/include/flask.h b/xen/xsm/flask/include/flask.h
deleted file mode 100644
index 3bff998..0000000
--- a/xen/xsm/flask/include/flask.h
+++ /dev/null
@@ -1,35 +0,0 @@
-/* This file is automatically generated.  Do not edit. */
-#ifndef _SELINUX_FLASK_H_
-#define _SELINUX_FLASK_H_
-
-/*
- * Security object class definitions
- */
-#define SECCLASS_XEN                                     1
-#define SECCLASS_DOMAIN                                  2
-#define SECCLASS_DOMAIN2                                 3
-#define SECCLASS_HVM                                     4
-#define SECCLASS_MMU                                     5
-#define SECCLASS_RESOURCE                                6
-#define SECCLASS_SHADOW                                  7
-#define SECCLASS_EVENT                                   8
-#define SECCLASS_GRANT                                   9
-#define SECCLASS_SECURITY                                10
-
-/*
- * Security identifier indices for initial entities
- */
-#define SECINITSID_XEN                                  1
-#define SECINITSID_DOM0                                 2
-#define SECINITSID_DOMIO                                3
-#define SECINITSID_DOMXEN                               4
-#define SECINITSID_UNLABELED                            5
-#define SECINITSID_SECURITY                             6
-#define SECINITSID_IOPORT                               7
-#define SECINITSID_IOMEM                                8
-#define SECINITSID_IRQ                                  9
-#define SECINITSID_DEVICE                               10
-
-#define SECINITSID_NUM                                  10
-
-#endif
diff --git a/xen/xsm/flask/include/initial_sid_to_string.h b/xen/xsm/flask/include/initial_sid_to_string.h
deleted file mode 100644
index 814f4bf..0000000
--- a/xen/xsm/flask/include/initial_sid_to_string.h
+++ /dev/null
@@ -1,16 +0,0 @@
-/* This file is automatically generated.  Do not edit. */
-static char *initial_sid_to_string[] =
-{
-    "null",
-    "xen",
-    "dom0",
-    "domio",
-    "domxen",
-    "unlabeled",
-    "security",
-    "ioport",
-    "iomem",
-    "irq",
-    "device",
-};
-
diff --git a/tools/flask/policy/policy/flask/access_vectors b/xen/xsm/flask/policy/access_vectors
similarity index 100%
rename from tools/flask/policy/policy/flask/access_vectors
rename to xen/xsm/flask/policy/access_vectors
diff --git a/tools/flask/policy/policy/flask/initial_sids b/xen/xsm/flask/policy/initial_sids
similarity index 100%
rename from tools/flask/policy/policy/flask/initial_sids
rename to xen/xsm/flask/policy/initial_sids
diff --git a/tools/flask/policy/policy/flask/mkaccess_vector.sh b/xen/xsm/flask/policy/mkaccess_vector.sh
similarity index 97%
rename from tools/flask/policy/policy/flask/mkaccess_vector.sh
rename to xen/xsm/flask/policy/mkaccess_vector.sh
index 43a60a7..8ec87f7 100644
--- a/tools/flask/policy/policy/flask/mkaccess_vector.sh
+++ b/xen/xsm/flask/policy/mkaccess_vector.sh
@@ -9,8 +9,8 @@ awk=$1
 shift
 
 # output files
-av_permissions="av_permissions.h"
-av_perm_to_string="av_perm_to_string.h"
+av_permissions="include/av_permissions.h"
+av_perm_to_string="include/av_perm_to_string.h"
 
 cat $* | $awk "
 BEGIN	{
diff --git a/tools/flask/policy/policy/flask/mkflask.sh b/xen/xsm/flask/policy/mkflask.sh
similarity index 95%
rename from tools/flask/policy/policy/flask/mkflask.sh
rename to xen/xsm/flask/policy/mkflask.sh
index 9c84754..e8d8fb5 100644
--- a/tools/flask/policy/policy/flask/mkflask.sh
+++ b/xen/xsm/flask/policy/mkflask.sh
@@ -9,9 +9,9 @@ awk=$1
 shift 1
 
 # output file
-output_file="flask.h"
-debug_file="class_to_string.h"
-debug_file2="initial_sid_to_string.h"
+output_file="include/flask.h"
+debug_file="include/class_to_string.h"
+debug_file2="include/initial_sid_to_string.h"
 
 cat $* | $awk "
 BEGIN	{
diff --git a/tools/flask/policy/policy/flask/security_classes b/xen/xsm/flask/policy/security_classes
similarity index 100%
rename from tools/flask/policy/policy/flask/security_classes
rename to xen/xsm/flask/policy/security_classes
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 18:41:01 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 18:41:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLejW-0007Qh-0Y; Tue, 09 Oct 2012 18:40:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLejU-0007Qc-7J
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 18:40:44 +0000
Received: from [85.158.139.83:17198] by server-12.bemta-5.messagelabs.com id
	62/1C-19095-BAF64705; Tue, 09 Oct 2012 18:40:43 +0000
X-Env-Sender: arnd@arndb.de
X-Msg-Ref: server-16.tower-182.messagelabs.com!1349808042!26783462!1
X-Originating-IP: [212.227.126.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xNzEgPT4gNjcwMDM=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xNzEgPT4gNjcwMDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28924 invoked from network); 9 Oct 2012 18:40:42 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.126.171)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 18:40:42 -0000
Received: from klappe2.localnet
	(HSI-KBW-149-172-5-253.hsi13.kabel-badenwuerttemberg.de
	[149.172.5.253])
	by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis)
	id 0M25gB-1TgKuG3Opf-00tRCc; Tue, 09 Oct 2012 20:40:28 +0200
From: Arnd Bergmann 
To: "Russell King - ARM Linux" 
Date: Tue, 9 Oct 2012 18:40:24 +0000
User-Agent: KMail/1.12.2 (Linux/3.5.0; KDE/4.3.2; x86_64; ; )
References: <1349796183-30648-1-git-send-email-arnd@arndb.de>
	<20121009160814.GH4625@n2100.arm.linux.org.uk>
In-Reply-To: <20121009160814.GH4625@n2100.arm.linux.org.uk>
MIME-Version: 1.0
Message-Id: <201210091840.25176.arnd@arndb.de>
X-Provags-ID: V02:K0:tQdb119hD1lk6ulXNiENdiLDqdWK/FAQrWwrghUJAUO
	5NMhcRJjjTc1UdVC9C8i/FmD0RT/cdXbn1CdeultGF5EOstsmc
	r36AosL3F2tDKmwsAgJwnX6aT5Hio++SUcH5dfTSecqCNYu0lP
	kAdAyyNw/FsKv+4hLIE3pQ+FndrwyRWze9DH3UkvkALMhZoraK
	Cxcgp/y+x+RV0ogWM7GnTuhK5haGe0aTDQw3FUsGvVkne7NaXy
	sZMk4cbWevaS/dtTxCDDK/uKVtvtcoiy/mPEBGWFPXCUDwQY7c
	CeoSpgg8fdVCikihUNybIDBE2x7ckjEbtM9NPKlE49+xKJmrM1
	SM3DwFCGlNFKHx/AQLvI=
Cc: mmarek@suse.cz, dave.martin@linaro.org, xen-devel@lists.xensource.com,
	jonathan.austin@arm.com, konrad.wilk@oracle.com,
	catalin.marinas@arm.com, linus.walleij@linaro.org,
	stefano.stabellini@eu.citrix.com, sboyd@codeaurora.org,
	jeremy@goop.org, will.deacon@arm.com,
	linux-kernel@vger.kernel.org, rjw@sisk.pl, damm@opensource.se,
	bryan.wu@canonical.com, tglx@linutronix.de,
	leif.lindholm@arm.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [GIT PULL 0/9] ARM architecture fixes for 3.7
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tuesday 09 October 2012, Russell King - ARM Linux wrote:
> 
> On Tue, Oct 09, 2012 at 05:22:54PM +0200, Arnd Bergmann wrote:
> > Here are some patches that belong into your domain, I hope you can
> > just send the lot to Linus the next time you send other patches.
> > 
> > These bug fixes all address problems found with automated build testing.
> > Some of them have been around for a long time, other bugs are
> > regressions since the merge window.
> 
> Apart from the sliced off comment in one commit (which XEN people need
> to confirm they're happy with the final version), I think these are
> otherwise fine... I'll hold off pulling them until that can be fixed.

Fixed that now, and I also added the Acks that I got in the meantime,
changed the dependency from Xen on (CPU_v7 && !CPU_V6), and edited the
description for patch 6 as Dave suggested.

	Arnd

8<---
The following changes since commit 0e51793e162ca432fc5f04178cf82b80a92c2659:

  Merge branch 'for-linus' of git://git.linaro.org/people/rmk/linux-arm (2012-10-07 21:20:57 +0900)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/fixes-for-rmk

for you to fetch changes up to 8e7fc18b5eacc37b6e6fcf486ec4eafbfef91738:

  ARM: warnings in arch/arm/include/asm/uaccess.h (2012-10-09 20:29:07 +0200)

----------------------------------------------------------------
These bug fixes all address problems found with automated build testing.
Some of them have been around for a long time, other bugs are
regressions since the merge window.

----------------------------------------------------------------
Arnd Bergmann (9):
      ARM: kprobes: make more tests conditional
      ARM: export set_irq_flags
      ARM: Fix another build warning in arch/arm/mm/alignment.c
      ARM: export default read_current_timer
      ARM: Xen: fix initial build problems
      ARM: pass -marm to gcc by default for both C and assembler
      ARM: be really quiet when building with 'make -s'
      ARM: binfmt_flat: unused variable 'persistent'
      ARM: warnings in arch/arm/include/asm/uaccess.h

 arch/arm/Kconfig                   |    1 +
 arch/arm/Makefile                  |   13 +++++++------
 arch/arm/boot/Makefile             |   10 +++++-----
 arch/arm/include/asm/flat.h        |    2 +-
 arch/arm/include/asm/uaccess.h     |    4 ++--
 arch/arm/kernel/irq.c              |    2 ++
 arch/arm/kernel/kprobes-test-arm.c |    4 ++++
 arch/arm/lib/delay.c               |    1 +
 arch/arm/mm/alignment.c            |    4 +++-
 arch/arm/tools/Makefile            |    2 +-
 drivers/xen/Kconfig                |    2 ++
 drivers/xen/sys-hypervisor.c       |    1 +
 12 files changed, 30 insertions(+), 16 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 18:41:01 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 18:41:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLejW-0007Qh-0Y; Tue, 09 Oct 2012 18:40:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLejU-0007Qc-7J
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 18:40:44 +0000
Received: from [85.158.139.83:17198] by server-12.bemta-5.messagelabs.com id
	62/1C-19095-BAF64705; Tue, 09 Oct 2012 18:40:43 +0000
X-Env-Sender: arnd@arndb.de
X-Msg-Ref: server-16.tower-182.messagelabs.com!1349808042!26783462!1
X-Originating-IP: [212.227.126.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xNzEgPT4gNjcwMDM=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xNzEgPT4gNjcwMDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28924 invoked from network); 9 Oct 2012 18:40:42 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.126.171)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 18:40:42 -0000
Received: from klappe2.localnet
	(HSI-KBW-149-172-5-253.hsi13.kabel-badenwuerttemberg.de
	[149.172.5.253])
	by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis)
	id 0M25gB-1TgKuG3Opf-00tRCc; Tue, 09 Oct 2012 20:40:28 +0200
From: Arnd Bergmann 
To: "Russell King - ARM Linux" 
Date: Tue, 9 Oct 2012 18:40:24 +0000
User-Agent: KMail/1.12.2 (Linux/3.5.0; KDE/4.3.2; x86_64; ; )
References: <1349796183-30648-1-git-send-email-arnd@arndb.de>
	<20121009160814.GH4625@n2100.arm.linux.org.uk>
In-Reply-To: <20121009160814.GH4625@n2100.arm.linux.org.uk>
MIME-Version: 1.0
Message-Id: <201210091840.25176.arnd@arndb.de>
X-Provags-ID: V02:K0:tQdb119hD1lk6ulXNiENdiLDqdWK/FAQrWwrghUJAUO
	5NMhcRJjjTc1UdVC9C8i/FmD0RT/cdXbn1CdeultGF5EOstsmc
	r36AosL3F2tDKmwsAgJwnX6aT5Hio++SUcH5dfTSecqCNYu0lP
	kAdAyyNw/FsKv+4hLIE3pQ+FndrwyRWze9DH3UkvkALMhZoraK
	Cxcgp/y+x+RV0ogWM7GnTuhK5haGe0aTDQw3FUsGvVkne7NaXy
	sZMk4cbWevaS/dtTxCDDK/uKVtvtcoiy/mPEBGWFPXCUDwQY7c
	CeoSpgg8fdVCikihUNybIDBE2x7ckjEbtM9NPKlE49+xKJmrM1
	SM3DwFCGlNFKHx/AQLvI=
Cc: mmarek@suse.cz, dave.martin@linaro.org, xen-devel@lists.xensource.com,
	jonathan.austin@arm.com, konrad.wilk@oracle.com,
	catalin.marinas@arm.com, linus.walleij@linaro.org,
	stefano.stabellini@eu.citrix.com, sboyd@codeaurora.org,
	jeremy@goop.org, will.deacon@arm.com,
	linux-kernel@vger.kernel.org, rjw@sisk.pl, damm@opensource.se,
	bryan.wu@canonical.com, tglx@linutronix.de,
	leif.lindholm@arm.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [GIT PULL 0/9] ARM architecture fixes for 3.7
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tuesday 09 October 2012, Russell King - ARM Linux wrote:
> 
> On Tue, Oct 09, 2012 at 05:22:54PM +0200, Arnd Bergmann wrote:
> > Here are some patches that belong into your domain, I hope you can
> > just send the lot to Linus the next time you send other patches.
> > 
> > These bug fixes all address problems found with automated build testing.
> > Some of them have been around for a long time, other bugs are
> > regressions since the merge window.
> 
> Apart from the sliced off comment in one commit (which XEN people need
> to confirm they're happy with the final version), I think these are
> otherwise fine... I'll hold off pulling them until that can be fixed.

Fixed that now, and I also added the Acks that I got in the meantime,
changed the dependency from Xen on (CPU_v7 && !CPU_V6), and edited the
description for patch 6 as Dave suggested.

	Arnd

8<---
The following changes since commit 0e51793e162ca432fc5f04178cf82b80a92c2659:

  Merge branch 'for-linus' of git://git.linaro.org/people/rmk/linux-arm (2012-10-07 21:20:57 +0900)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/fixes-for-rmk

for you to fetch changes up to 8e7fc18b5eacc37b6e6fcf486ec4eafbfef91738:

  ARM: warnings in arch/arm/include/asm/uaccess.h (2012-10-09 20:29:07 +0200)

----------------------------------------------------------------
These bug fixes all address problems found with automated build testing.
Some of them have been around for a long time, other bugs are
regressions since the merge window.

----------------------------------------------------------------
Arnd Bergmann (9):
      ARM: kprobes: make more tests conditional
      ARM: export set_irq_flags
      ARM: Fix another build warning in arch/arm/mm/alignment.c
      ARM: export default read_current_timer
      ARM: Xen: fix initial build problems
      ARM: pass -marm to gcc by default for both C and assembler
      ARM: be really quiet when building with 'make -s'
      ARM: binfmt_flat: unused variable 'persistent'
      ARM: warnings in arch/arm/include/asm/uaccess.h

 arch/arm/Kconfig                   |    1 +
 arch/arm/Makefile                  |   13 +++++++------
 arch/arm/boot/Makefile             |   10 +++++-----
 arch/arm/include/asm/flat.h        |    2 +-
 arch/arm/include/asm/uaccess.h     |    4 ++--
 arch/arm/kernel/irq.c              |    2 ++
 arch/arm/kernel/kprobes-test-arm.c |    4 ++++
 arch/arm/lib/delay.c               |    1 +
 arch/arm/mm/alignment.c            |    4 +++-
 arch/arm/tools/Makefile            |    2 +-
 drivers/xen/Kconfig                |    2 ++
 drivers/xen/sys-hypervisor.c       |    1 +
 12 files changed, 30 insertions(+), 16 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 18:41:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 18:41:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLekA-0007T5-E7; Tue, 09 Oct 2012 18:41:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLek8-0007St-D2
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 18:41:24 +0000
Received: from [85.158.143.99:6171] by server-2.bemta-4.messagelabs.com id
	CA/1C-06610-3DF64705; Tue, 09 Oct 2012 18:41:23 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-216.messagelabs.com!1349808082!32868409!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20047 invoked from network); 9 Oct 2012 18:41:22 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-3.tower-216.messagelabs.com with SMTP;
	9 Oct 2012 18:41:22 -0000
X-TM-IMSS-Message-ID: 
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1;
	TLSv1/SSLv3 DHE-RSA-AES256-SHA (256/256)) id c58005bb00004f7f ;
	Tue, 9 Oct 2012 14:41:12 -0400
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q99IfGpY006028; 
	Tue, 9 Oct 2012 14:41:16 -0400
Message-ID: <50746FCC.9020705@tycho.nsa.gov>
Date: Tue, 09 Oct 2012 14:41:16 -0400
From: Daniel De Graaf 
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120911 Thunderbird/15.0.1
MIME-Version: 1.0
To: Ian Jackson 
References: <1346400260.27277.93.camel@zakaz.uk.xensource.com>
	<1346864713-28732-1-git-send-email-dgdegra@tycho.nsa.gov>
	<20596.16757.874363.819950@mariner.uk.xensource.com>
In-Reply-To: <20596.16757.874363.819950@mariner.uk.xensource.com>
Cc: Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH v2] libxl: Support backend domain ID for
	disks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/09/2012 11:23 AM, Ian Jackson wrote:
> Daniel De Graaf writes ("[PATCH v2] libxl: Support backend domain ID for disks"):
>> Allow specification of backend domains for disks, either in the config
>> file or via xl block-attach. This functionality was supported in xend
>> (via an optional command line parameter to block-attach), so should also
>> be supported with libxl.
>>
>> In order to support named backend domains like network-attach, a valid
>> libxl_ctx must now be passed to xlu_cfg_init.
> 
> I've been thinking about this and I'm afraid I've come to the
> conclusion that the way your new API specifies backend domains is not
> the way I think it should be done.
> 
> In particular, I think translating the config file from a source text
> into an idl configuration structure shouldn't depend on looking up
> information like domids.  (The same would be true of DNS names, or
> other runtime lookups.)  So I think the backend domain _name_ should
> be in the IDL structure.
> 
> But of course it should also be possible to specify a domid.
> 
> I can think of three (at least superficially) plausible ways to define
> this API:
> 
> 1. The backend domain is specified as a string.  If specifying a domid
>    is desired, the string is the domid number in ascii.  Domains whose
>    names are entirely valid numbers according to strtoul(,,0) cannot
>    be specified as backends by name (or should perhaps be prohibited
>    entirely - xl can't handle them anyway).
> 
> 2. The IDL contains both a string and a number.  If the string is
>    provided, it is used; otherwise the number is used.
> 
> 3. The IDL contains a variadic "domspec" structure which allows the
>    domain to be specified (a) not at all (b) as a domid (c) as a
>    domain name (d) as a uuid.
> 
> Of these I think 3 is probably overkill and either 1 or 2 is
> acceptable and I have a marginal preference for 2.
> 
> Before you implement any of this I think we should agree whether my
> qualm about domain name lookups during config parsing is justified,
> and what the right API is.
> 
> NB that this complaint does seem perhaps contrary to my intent to add
> a libxl context to libxlu parsing calls.  But, having thought about
> it, this libxl context should be a "dummy" one which can be used for
> memory allocation and logging but which does not support actual Xen
> functionality.
> 
> Thanks, and sorry to block your useful new functionality on cans of
> works.
> 
> Ian.
> 

I assume that this change would also apply to vfb, vkb, nic, and any new
devices that allow backend domains to be specified (i.e. vtpm). Currently,
the domains have to be specified by name in xl's config file, but I think
that allowing domid there in addition is a good idea.

Method (2) is also simpler for backwards compatibility as it allows the
existing backend_domid fields to remain, supplemented by an entry like
backend_name - so that's my preference.

-- 
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 18:41:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 18:41:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLekA-0007T5-E7; Tue, 09 Oct 2012 18:41:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLek8-0007St-D2
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 18:41:24 +0000
Received: from [85.158.143.99:6171] by server-2.bemta-4.messagelabs.com id
	CA/1C-06610-3DF64705; Tue, 09 Oct 2012 18:41:23 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-216.messagelabs.com!1349808082!32868409!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20047 invoked from network); 9 Oct 2012 18:41:22 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-3.tower-216.messagelabs.com with SMTP;
	9 Oct 2012 18:41:22 -0000
X-TM-IMSS-Message-ID: 
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1;
	TLSv1/SSLv3 DHE-RSA-AES256-SHA (256/256)) id c58005bb00004f7f ;
	Tue, 9 Oct 2012 14:41:12 -0400
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q99IfGpY006028; 
	Tue, 9 Oct 2012 14:41:16 -0400
Message-ID: <50746FCC.9020705@tycho.nsa.gov>
Date: Tue, 09 Oct 2012 14:41:16 -0400
From: Daniel De Graaf 
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120911 Thunderbird/15.0.1
MIME-Version: 1.0
To: Ian Jackson 
References: <1346400260.27277.93.camel@zakaz.uk.xensource.com>
	<1346864713-28732-1-git-send-email-dgdegra@tycho.nsa.gov>
	<20596.16757.874363.819950@mariner.uk.xensource.com>
In-Reply-To: <20596.16757.874363.819950@mariner.uk.xensource.com>
Cc: Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH v2] libxl: Support backend domain ID for
	disks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/09/2012 11:23 AM, Ian Jackson wrote:
> Daniel De Graaf writes ("[PATCH v2] libxl: Support backend domain ID for disks"):
>> Allow specification of backend domains for disks, either in the config
>> file or via xl block-attach. This functionality was supported in xend
>> (via an optional command line parameter to block-attach), so should also
>> be supported with libxl.
>>
>> In order to support named backend domains like network-attach, a valid
>> libxl_ctx must now be passed to xlu_cfg_init.
> 
> I've been thinking about this and I'm afraid I've come to the
> conclusion that the way your new API specifies backend domains is not
> the way I think it should be done.
> 
> In particular, I think translating the config file from a source text
> into an idl configuration structure shouldn't depend on looking up
> information like domids.  (The same would be true of DNS names, or
> other runtime lookups.)  So I think the backend domain _name_ should
> be in the IDL structure.
> 
> But of course it should also be possible to specify a domid.
> 
> I can think of three (at least superficially) plausible ways to define
> this API:
> 
> 1. The backend domain is specified as a string.  If specifying a domid
>    is desired, the string is the domid number in ascii.  Domains whose
>    names are entirely valid numbers according to strtoul(,,0) cannot
>    be specified as backends by name (or should perhaps be prohibited
>    entirely - xl can't handle them anyway).
> 
> 2. The IDL contains both a string and a number.  If the string is
>    provided, it is used; otherwise the number is used.
> 
> 3. The IDL contains a variadic "domspec" structure which allows the
>    domain to be specified (a) not at all (b) as a domid (c) as a
>    domain name (d) as a uuid.
> 
> Of these I think 3 is probably overkill and either 1 or 2 is
> acceptable and I have a marginal preference for 2.
> 
> Before you implement any of this I think we should agree whether my
> qualm about domain name lookups during config parsing is justified,
> and what the right API is.
> 
> NB that this complaint does seem perhaps contrary to my intent to add
> a libxl context to libxlu parsing calls.  But, having thought about
> it, this libxl context should be a "dummy" one which can be used for
> memory allocation and logging but which does not support actual Xen
> functionality.
> 
> Thanks, and sorry to block your useful new functionality on cans of
> works.
> 
> Ian.
> 

I assume that this change would also apply to vfb, vkb, nic, and any new
devices that allow backend domains to be specified (i.e. vtpm). Currently,
the domains have to be specified by name in xl's config file, but I think
that allowing domid there in addition is a good idea.

Method (2) is also simpler for backwards compatibility as it allows the
existing backend_domid fields to remain, supplemented by an entry like
backend_name - so that's my preference.

-- 
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 18:44:18 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 18:44:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLemd-0007dL-Vr; Tue, 09 Oct 2012 18:43:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLemb-0007d2-Mc
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 18:43:57 +0000
Received: from [85.158.138.51:40114] by server-16.bemta-3.messagelabs.com id
	F6/AD-04167-C6074705; Tue, 09 Oct 2012 18:43:56 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1349808234!33808816!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzkxNzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27020 invoked from network); 9 Oct 2012 18:43:56 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Oct 2012 18:43:56 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q99Ihq3S001806
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 9 Oct 2012 18:43:53 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q99Ihp9m009012
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 9 Oct 2012 18:43:51 GMT
Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q99IhpXh027496; Tue, 9 Oct 2012 13:43:51 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 09 Oct 2012 11:43:51 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9C8BB4031E; Tue,  9 Oct 2012 14:32:06 -0400 (EDT)
Date: Tue, 9 Oct 2012 14:32:06 -0400
From: Konrad Rzeszutek Wilk 
To: David Howells 
Message-ID: <20121009183206.GA26104@phenom.dumpdata.com>
References: <30773.1349789452@warthog.procyon.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <30773.1349789452@warthog.procyon.org.uk>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [GIT PULL] Disintegrate UAPI for xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 09, 2012 at 02:30:52PM +0100, David Howells wrote:
> Can you merge the following branch into the xen tree please.

What is up with your key?

UAPI Disintegration 2012-10-09
# gpg: Signature made Tue 09 Oct 2012 04:54:52 AM EDT using RSA key ID 044B2B3B
# gpg: requesting key 044B2B3B from hkp server pgp.mit.edu
# gpg: no valid OpenPGP data found.
# gpg: Total number processed: 0
# gpg: Can't check signature: public key not found

> 
> This is to complete part of the Userspace API (UAPI) disintegration for which
> the preparatory patches were pulled recently.  After these patches, userspace
> headers will be segregated into:
> 
> 	include/uapi/linux/.../foo.h
> 
> for the userspace interface stuff, and:
> 
> 	include/linux/.../foo.h
> 
> for the strictly kernel internal stuff.
> 
> ---
> The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8:
> 
>   Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900)
> 
> are available in the git repository at:
> 
> 
>   git://git.infradead.org/users/dhowells/linux-headers.git tags/disintegrate-xen-20121009
> 
> for you to fetch changes up to 72503791edffe516848d0f01d377fa9cd0711970:
> 
>   UAPI: (Scripted) Disintegrate include/xen (2012-10-09 09:49:15 +0100)
> 
> ----------------------------------------------------------------
> UAPI Disintegration 2012-10-09
> 
> ----------------------------------------------------------------
> David Howells (1):
>       UAPI: (Scripted) Disintegrate include/xen
> 
>  include/uapi/xen/Kbuild          | 2 ++
>  include/{ => uapi}/xen/evtchn.h  | 0
>  include/{ => uapi}/xen/privcmd.h | 0
>  include/xen/Kbuild               | 2 --
>  4 files changed, 2 insertions(+), 2 deletions(-)
>  rename include/{ => uapi}/xen/evtchn.h (100%)
>  rename include/{ => uapi}/xen/privcmd.h (100%)
> .

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 18:44:18 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 18:44:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLemd-0007dL-Vr; Tue, 09 Oct 2012 18:43:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLemb-0007d2-Mc
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 18:43:57 +0000
Received: from [85.158.138.51:40114] by server-16.bemta-3.messagelabs.com id
	F6/AD-04167-C6074705; Tue, 09 Oct 2012 18:43:56 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1349808234!33808816!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzkxNzQ2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27020 invoked from network); 9 Oct 2012 18:43:56 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Oct 2012 18:43:56 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q99Ihq3S001806
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 9 Oct 2012 18:43:53 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q99Ihp9m009012
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 9 Oct 2012 18:43:51 GMT
Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q99IhpXh027496; Tue, 9 Oct 2012 13:43:51 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 09 Oct 2012 11:43:51 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9C8BB4031E; Tue,  9 Oct 2012 14:32:06 -0400 (EDT)
Date: Tue, 9 Oct 2012 14:32:06 -0400
From: Konrad Rzeszutek Wilk 
To: David Howells 
Message-ID: <20121009183206.GA26104@phenom.dumpdata.com>
References: <30773.1349789452@warthog.procyon.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <30773.1349789452@warthog.procyon.org.uk>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [GIT PULL] Disintegrate UAPI for xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 09, 2012 at 02:30:52PM +0100, David Howells wrote:
> Can you merge the following branch into the xen tree please.

What is up with your key?

UAPI Disintegration 2012-10-09
# gpg: Signature made Tue 09 Oct 2012 04:54:52 AM EDT using RSA key ID 044B2B3B
# gpg: requesting key 044B2B3B from hkp server pgp.mit.edu
# gpg: no valid OpenPGP data found.
# gpg: Total number processed: 0
# gpg: Can't check signature: public key not found

> 
> This is to complete part of the Userspace API (UAPI) disintegration for which
> the preparatory patches were pulled recently.  After these patches, userspace
> headers will be segregated into:
> 
> 	include/uapi/linux/.../foo.h
> 
> for the userspace interface stuff, and:
> 
> 	include/linux/.../foo.h
> 
> for the strictly kernel internal stuff.
> 
> ---
> The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8:
> 
>   Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900)
> 
> are available in the git repository at:
> 
> 
>   git://git.infradead.org/users/dhowells/linux-headers.git tags/disintegrate-xen-20121009
> 
> for you to fetch changes up to 72503791edffe516848d0f01d377fa9cd0711970:
> 
>   UAPI: (Scripted) Disintegrate include/xen (2012-10-09 09:49:15 +0100)
> 
> ----------------------------------------------------------------
> UAPI Disintegration 2012-10-09
> 
> ----------------------------------------------------------------
> David Howells (1):
>       UAPI: (Scripted) Disintegrate include/xen
> 
>  include/uapi/xen/Kbuild          | 2 ++
>  include/{ => uapi}/xen/evtchn.h  | 0
>  include/{ => uapi}/xen/privcmd.h | 0
>  include/xen/Kbuild               | 2 --
>  4 files changed, 2 insertions(+), 2 deletions(-)
>  rename include/{ => uapi}/xen/evtchn.h (100%)
>  rename include/{ => uapi}/xen/privcmd.h (100%)
> .

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 19:25:03 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 19:25:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLfQ0-0007z2-LV; Tue, 09 Oct 2012 19:24:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLfPz-0007yx-NT
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 19:24:39 +0000
Received: from [85.158.143.99:4726] by server-1.bemta-4.messagelabs.com id
	61/0F-05684-7F974705; Tue, 09 Oct 2012 19:24:39 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1349810677!33519454!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgwMTY3NA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13808 invoked from network); 9 Oct 2012 19:24:38 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Oct 2012 19:24:38 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q99JOTEI016246
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 9 Oct 2012 19:24:30 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q99JORm7019282
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 9 Oct 2012 19:24:28 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q99JOQtW026069; Tue, 9 Oct 2012 14:24:26 -0500
MIME-Version: 1.0
Message-ID: <34a52050-5de8-4a4d-91b5-a0a8d5a41710@default>
Date: Tue, 9 Oct 2012 12:24:22 -0700 (PDT)
From: Dan Magenheimer 
To: Ian Campbell , Jeremy Fitzhardinge
	, Stefano Stabellini ,
	Konrad Wilk 
References: <1349796183-30648-1-git-send-email-arnd@arndb.de>
	<1349796183-30648-6-git-send-email-arnd@arndb.de>
	<1349796958.21847.219.camel@zakaz.uk.xensource.com>
In-Reply-To: <1349796958.21847.219.camel@zakaz.uk.xensource.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> Sent: Tuesday, October 09, 2012 9:36 AM
> To: Arnd Bergmann
> Cc: Jeremy Fitzhardinge; xen-devel@lists.xensource.com; Stefano Stabellini; Konrad Rzeszutek Wilk;
> linux-kernel@vger.kernel.org; Russell King; linux-arm-kernel@lists.infradead.org
> Subject: Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
> 
> On Tue, 2012-10-09 at 16:22 +0100, Arnd Bergmann wrote:
> > * The XEN_BALLOON code requires the balloon infrastructure that is not
> >   getting built on ARM.
> 
> I've got patches to enable this, but not for 3.7 so this looks good for
> now.
> 
> > * The tmem hypercall is not available on ARM

[reduced cc list to just us Xen chickens]

Any reason that the tmem hypercall is not available on ARM?
At a minimum, it should be available, but always return failure.
Then an ARM Linux kernel can be ready for the Xen implementation
when the Xen hypervisor supports it.

Ballooning also... why disable it rather than just have
the hypervisor fail all calls?

Wondering if it just has never been tried/tested, or if there
are known problems since everything should have been coded
quite portably.  (I do recall some arch-specific code in
the hypervisor, now that I think of it, but it was pretty small.)

I haven't been plugged in to Xen/ARM, so I don't know the
target market, but I do know that some
Android distros have been using the in-kernel tmem version
(called zcache) even though it is still a Linux staging driver,
so there probably will be demand for Xen tmem too.

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 19:25:03 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 19:25:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLfQ0-0007z2-LV; Tue, 09 Oct 2012 19:24:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLfPz-0007yx-NT
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 19:24:39 +0000
Received: from [85.158.143.99:4726] by server-1.bemta-4.messagelabs.com id
	61/0F-05684-7F974705; Tue, 09 Oct 2012 19:24:39 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1349810677!33519454!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgwMTY3NA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13808 invoked from network); 9 Oct 2012 19:24:38 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Oct 2012 19:24:38 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q99JOTEI016246
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 9 Oct 2012 19:24:30 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q99JORm7019282
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 9 Oct 2012 19:24:28 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q99JOQtW026069; Tue, 9 Oct 2012 14:24:26 -0500
MIME-Version: 1.0
Message-ID: <34a52050-5de8-4a4d-91b5-a0a8d5a41710@default>
Date: Tue, 9 Oct 2012 12:24:22 -0700 (PDT)
From: Dan Magenheimer 
To: Ian Campbell , Jeremy Fitzhardinge
	, Stefano Stabellini ,
	Konrad Wilk 
References: <1349796183-30648-1-git-send-email-arnd@arndb.de>
	<1349796183-30648-6-git-send-email-arnd@arndb.de>
	<1349796958.21847.219.camel@zakaz.uk.xensource.com>
In-Reply-To: <1349796958.21847.219.camel@zakaz.uk.xensource.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> Sent: Tuesday, October 09, 2012 9:36 AM
> To: Arnd Bergmann
> Cc: Jeremy Fitzhardinge; xen-devel@lists.xensource.com; Stefano Stabellini; Konrad Rzeszutek Wilk;
> linux-kernel@vger.kernel.org; Russell King; linux-arm-kernel@lists.infradead.org
> Subject: Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
> 
> On Tue, 2012-10-09 at 16:22 +0100, Arnd Bergmann wrote:
> > * The XEN_BALLOON code requires the balloon infrastructure that is not
> >   getting built on ARM.
> 
> I've got patches to enable this, but not for 3.7 so this looks good for
> now.
> 
> > * The tmem hypercall is not available on ARM

[reduced cc list to just us Xen chickens]

Any reason that the tmem hypercall is not available on ARM?
At a minimum, it should be available, but always return failure.
Then an ARM Linux kernel can be ready for the Xen implementation
when the Xen hypervisor supports it.

Ballooning also... why disable it rather than just have
the hypervisor fail all calls?

Wondering if it just has never been tried/tested, or if there
are known problems since everything should have been coded
quite portably.  (I do recall some arch-specific code in
the hypervisor, now that I think of it, but it was pretty small.)

I haven't been plugged in to Xen/ARM, so I don't know the
target market, but I do know that some
Android distros have been using the in-kernel tmem version
(called zcache) even though it is still a Linux staging driver,
so there probably will be demand for Xen tmem too.

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 19:34:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 19:34:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLfZ6-0008EE-2P; Tue, 09 Oct 2012 19:34:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLfZ4-0008E9-KE
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 19:34:02 +0000
Received: from [85.158.139.211:49554] by server-8.bemta-5.messagelabs.com id
	E7/D4-23193-92C74705; Tue, 09 Oct 2012 19:34:01 +0000
X-Env-Sender: dhowells@redhat.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1349811240!21654461!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTc1NzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9494 invoked from network); 9 Oct 2012 19:34:00 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-10.tower-206.messagelabs.com with SMTP;
	9 Oct 2012 19:34:00 -0000
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
	(int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q99JXvLQ025451
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 9 Oct 2012 15:33:57 -0400
Received: from warthog.procyon.org.uk (ovpn-113-58.phx2.redhat.com
	[10.3.113.58])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q99JXtZ4023570; Tue, 9 Oct 2012 15:33:56 -0400
Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley
	Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United
	Kingdom.
	Registered in England and Wales under Company Registration No. 3798903
From: David Howells 
In-Reply-To: <20121009183206.GA26104@phenom.dumpdata.com>
References: <20121009183206.GA26104@phenom.dumpdata.com>
	<30773.1349789452@warthog.procyon.org.uk>
To: Konrad Rzeszutek Wilk 
Date: Tue, 09 Oct 2012 20:33:55 +0100
Message-ID: <7035.1349811235@warthog.procyon.org.uk>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: dhowells@redhat.com, jeremy@goop.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [GIT PULL] Disintegrate UAPI for xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad Rzeszutek Wilk  wrote:

> What is up with your key?

I'm using a time-limited subkey to sign git tags with, so you may have to pull
my key again to get it.

	warthog>gpg --recv-keys 044B2B3B
	gpg: requesting key 044B2B3B from hkp server pgp.mit.edu
	gpg: key A7CB0B6B: "David Howells " not changed
	gpg: Total number processed: 1
	gpg:              unchanged: 1

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 19:34:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 19:34:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLfZ6-0008EE-2P; Tue, 09 Oct 2012 19:34:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLfZ4-0008E9-KE
	for xen-devel@lists.xensource.com; Tue, 09 Oct 2012 19:34:02 +0000
Received: from [85.158.139.211:49554] by server-8.bemta-5.messagelabs.com id
	E7/D4-23193-92C74705; Tue, 09 Oct 2012 19:34:01 +0000
X-Env-Sender: dhowells@redhat.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1349811240!21654461!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTc1NzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9494 invoked from network); 9 Oct 2012 19:34:00 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-10.tower-206.messagelabs.com with SMTP;
	9 Oct 2012 19:34:00 -0000
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
	(int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q99JXvLQ025451
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 9 Oct 2012 15:33:57 -0400
Received: from warthog.procyon.org.uk (ovpn-113-58.phx2.redhat.com
	[10.3.113.58])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q99JXtZ4023570; Tue, 9 Oct 2012 15:33:56 -0400
Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley
	Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United
	Kingdom.
	Registered in England and Wales under Company Registration No. 3798903
From: David Howells 
In-Reply-To: <20121009183206.GA26104@phenom.dumpdata.com>
References: <20121009183206.GA26104@phenom.dumpdata.com>
	<30773.1349789452@warthog.procyon.org.uk>
To: Konrad Rzeszutek Wilk 
Date: Tue, 09 Oct 2012 20:33:55 +0100
Message-ID: <7035.1349811235@warthog.procyon.org.uk>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: dhowells@redhat.com, jeremy@goop.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [GIT PULL] Disintegrate UAPI for xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad Rzeszutek Wilk  wrote:

> What is up with your key?

I'm using a time-limited subkey to sign git tags with, so you may have to pull
my key again to get it.

	warthog>gpg --recv-keys 044B2B3B
	gpg: requesting key 044B2B3B from hkp server pgp.mit.edu
	gpg: key A7CB0B6B: "David Howells " not changed
	gpg: Total number processed: 1
	gpg:              unchanged: 1

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 20:53:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 20:53:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLgnH-0000O9-Lh; Tue, 09 Oct 2012 20:52:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLgnF-0000O3-TB
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 20:52:46 +0000
Received: from [85.158.139.83:8122] by server-5.bemta-5.messagelabs.com id
	64/53-19238-D9E84705; Tue, 09 Oct 2012 20:52:45 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1349815962!30177933!1
X-Originating-IP: [72.21.196.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk2LjI1ID0+IDEzNzgzOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23699 invoked from network); 9 Oct 2012 20:52:44 -0000
Received: from smtp-fw-2101.amazon.com (HELO smtp-fw-2101.amazon.com)
	(72.21.196.25)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 20:52:44 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt;
	s=amazon201209; t=1349815964; x=1381351964;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=md/2nFu1f/YjeOXr2rV8pLWDhI1Wdq1/NdcRDkfh3yo=;
	b=gq8kj1+x03udPXMpfwNFvlrM15DLcrdIJFFhA3FsGblcZ11WXSdcDe92
	/GJRdj2QkPP6DWvDCYMh7Vhn2Jlewhmek4AKzTbPhsUk9u8by6afRuBa4
	8mu3BIJZUUbglUbmYmSFfJ/qkmXhVMdIBqhWjzGY+Kz0fPJNTVG4B2dKu k=;
X-IronPort-AV: E=Sophos;i="4.80,562,1344211200"; d="scan'208";a="451583811"
Received: from smtp-in-31001.sea31.amazon.com ([10.184.168.27])
	by smtp-border-fw-out-2101.iad2.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Oct 2012 20:20:46 +0000
Received: from ex10-hub-9001.ant.amazon.com (ex10-hub-9001.ant.amazon.com
	[10.185.137.58])
	by smtp-in-31001.sea31.amazon.com (8.13.8/8.13.8) with ESMTP id
	q99KKh1U023319
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Tue, 9 Oct 2012 20:20:44 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.42) by
	ex10-hub-9001.ant.amazon.com (10.185.137.58) with Microsoft SMTP Server
	id 14.2.247.3; Tue, 9 Oct 2012 13:20:21 -0700
Received: by u002268147cd4502c336d.ant.amazon.com (sSMTP sendmail emulation); 
	Tue, 09 Oct 2012 13:20:19 -0700
Date: Tue, 9 Oct 2012 13:20:19 -0700
From: Matt Wilson 
To: Dario Faggioli 
Message-ID: <20121009202001.GA24955@u002268147cd4502c336d.ant.amazon.com>
References: 
	
	<1349779549.3610.79.camel@Abyss>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1349779549.3610.79.camel@Abyss>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Marcus Granado ,
	Dan Magenheimer ,
	Andre Przywara ,
	Ian Campbell ,
	Anil Madhavapeddy ,
	George Dunlap ,
	Andrew Cooper ,
	Juergen Gross ,
	Ian Jackson , xen-devel@lists.xen.org,
	Jan Beulich , Daniel De Graaf 
Subject: Re: [Xen-devel] [PATCH 0 of 8] NUMA Awareness for the Credit
 Scheduler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 09, 2012 at 11:45:49AM +0100, Dario Faggioli wrote:
> 
> Whether, that is acceptable or not, is of course debatable, and we had a
> bit of this discussion already (although no real conclusion has been
> reached yet).
> My take is that, right now, since we do not yet expose any virtual NUMA
> topology to the VM itself, the behaviour described above is fine. As
> soon as we'll have some guest NUMA awareness, than it might be
> worthwhile to try to preserve it, at least to some extent.

For what it's worth, under VMware all bets are off if a vNUMA enabled
guest is migrated via vMotion. See "Performance Best Practices for
VMware vSphere 5.0" [1] page 40. There is also a good deal of
information in a paper published by VMware labs on HPC workloads [2]
and a blog post on NUMA load balancing [3].

Matt

[1] http://www.vmware.com/pdf/Perf_Best_Practices_vSphere5.0.pdf
[2] http://labs.vmware.com/publications/performance-evaluation-of-hpc-benchmarks-on-vmwares-esxi-server
[3] http://blogs.vmware.com/vsphere/2012/02/vspherenuma-loadbalancing.htmlvnu




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 09 20:53:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 09 Oct 2012 20:53:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLgnH-0000O9-Lh; Tue, 09 Oct 2012 20:52:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLgnF-0000O3-TB
	for xen-devel@lists.xen.org; Tue, 09 Oct 2012 20:52:46 +0000
Received: from [85.158.139.83:8122] by server-5.bemta-5.messagelabs.com id
	64/53-19238-D9E84705; Tue, 09 Oct 2012 20:52:45 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1349815962!30177933!1
X-Originating-IP: [72.21.196.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk2LjI1ID0+IDEzNzgzOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23699 invoked from network); 9 Oct 2012 20:52:44 -0000
Received: from smtp-fw-2101.amazon.com (HELO smtp-fw-2101.amazon.com)
	(72.21.196.25)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Oct 2012 20:52:44 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt;
	s=amazon201209; t=1349815964; x=1381351964;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=md/2nFu1f/YjeOXr2rV8pLWDhI1Wdq1/NdcRDkfh3yo=;
	b=gq8kj1+x03udPXMpfwNFvlrM15DLcrdIJFFhA3FsGblcZ11WXSdcDe92
	/GJRdj2QkPP6DWvDCYMh7Vhn2Jlewhmek4AKzTbPhsUk9u8by6afRuBa4
	8mu3BIJZUUbglUbmYmSFfJ/qkmXhVMdIBqhWjzGY+Kz0fPJNTVG4B2dKu k=;
X-IronPort-AV: E=Sophos;i="4.80,562,1344211200"; d="scan'208";a="451583811"
Received: from smtp-in-31001.sea31.amazon.com ([10.184.168.27])
	by smtp-border-fw-out-2101.iad2.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Oct 2012 20:20:46 +0000
Received: from ex10-hub-9001.ant.amazon.com (ex10-hub-9001.ant.amazon.com
	[10.185.137.58])
	by smtp-in-31001.sea31.amazon.com (8.13.8/8.13.8) with ESMTP id
	q99KKh1U023319
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Tue, 9 Oct 2012 20:20:44 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.42) by
	ex10-hub-9001.ant.amazon.com (10.185.137.58) with Microsoft SMTP Server
	id 14.2.247.3; Tue, 9 Oct 2012 13:20:21 -0700
Received: by u002268147cd4502c336d.ant.amazon.com (sSMTP sendmail emulation); 
	Tue, 09 Oct 2012 13:20:19 -0700
Date: Tue, 9 Oct 2012 13:20:19 -0700
From: Matt Wilson 
To: Dario Faggioli 
Message-ID: <20121009202001.GA24955@u002268147cd4502c336d.ant.amazon.com>
References: 
	
	<1349779549.3610.79.camel@Abyss>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1349779549.3610.79.camel@Abyss>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Marcus Granado ,
	Dan Magenheimer ,
	Andre Przywara ,
	Ian Campbell ,
	Anil Madhavapeddy ,
	George Dunlap ,
	Andrew Cooper ,
	Juergen Gross ,
	Ian Jackson , xen-devel@lists.xen.org,
	Jan Beulich , Daniel De Graaf 
Subject: Re: [Xen-devel] [PATCH 0 of 8] NUMA Awareness for the Credit
 Scheduler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 09, 2012 at 11:45:49AM +0100, Dario Faggioli wrote:
> 
> Whether, that is acceptable or not, is of course debatable, and we had a
> bit of this discussion already (although no real conclusion has been
> reached yet).
> My take is that, right now, since we do not yet expose any virtual NUMA
> topology to the VM itself, the behaviour described above is fine. As
> soon as we'll have some guest NUMA awareness, than it might be
> worthwhile to try to preserve it, at least to some extent.

For what it's worth, under VMware all bets are off if a vNUMA enabled
guest is migrated via vMotion. See "Performance Best Practices for
VMware vSphere 5.0" [1] page 40. There is also a good deal of
information in a paper published by VMware labs on HPC workloads [2]
and a blog post on NUMA load balancing [3].

Matt

[1] http://www.vmware.com/pdf/Perf_Best_Practices_vSphere5.0.pdf
[2] http://labs.vmware.com/publications/performance-evaluation-of-hpc-benchmarks-on-vmwares-esxi-server
[3] http://blogs.vmware.com/vsphere/2012/02/vspherenuma-loadbalancing.htmlvnu




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 05:16:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 05:16:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLodu-0007ow-57; Wed, 10 Oct 2012 05:15:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLods-0007on-FH
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 05:15:36 +0000
Received: from [85.158.143.99:24468] by server-3.bemta-4.messagelabs.com id
	A6/01-10986-77405705; Wed, 10 Oct 2012 05:15:35 +0000
X-Env-Sender: singapore.mr.teo.en.ming@gmail.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1349846132!25989585!1
X-Originating-IP: [209.85.220.45]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21750 invoked from network); 10 Oct 2012 05:15:33 -0000
Received: from mail-pa0-f45.google.com (HELO mail-pa0-f45.google.com)
	(209.85.220.45)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 05:15:33 -0000
Received: by mail-pa0-f45.google.com with SMTP id fb10so193926pad.32
	for ; Tue, 09 Oct 2012 22:15:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type;
	bh=cqiJTAp9+fRWvcCqTk7+rILtpiw5qXWdJrEKPtMsL0o=;
	b=fgQxfpX2sRzdphI4M8O6z5sz2h33P5fa7PyoBhBX5TY8u0pVEN4r7EL9PVug3xurgE
	pks511nsNbozev/bsdg3wiE2qHrV6ifjB9qhzSLIr9M1PsuSUOdENy0uYOv6GO/ACq9p
	efinvUo6l7tvjcgTAGUK/hORDkRntaT19S2l0hB4TbPRxx/GqsWBVFO/OJmfi8ifQkqd
	JekQUkbD8a/etECKEtmWY/mawcnsEhWj7y4Pq36EQBAic4sVBXLiVtoHjJF/TmofraRz
	OLORL1LqH0IRzFyn0wbITpb+B3Ooxp/0s2K0dpZA9t4ydw+a0NIURYZN5kHBoAFVPxIH
	lUdQ==
Received: by 10.68.235.68 with SMTP id uk4mr69892533pbc.52.1349846131431;
	Tue, 09 Oct 2012 22:15:31 -0700 (PDT)
Received: from [192.168.1.2] (cm152.gamma205.maxonline.com.sg.
	[202.156.205.152])
	by mx.google.com with ESMTPS id oi2sm438068pbb.62.2012.10.09.22.15.28
	(version=SSLv3 cipher=OTHER); Tue, 09 Oct 2012 22:15:30 -0700 (PDT)
Message-ID: <5075046F.5090900@gmail.com>
Date: Wed, 10 Oct 2012 13:15:27 +0800
From: "Teo En Ming (Zhang Enming)" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: "Teo En Ming (Zhang Enming)" 
References: <50706112.1030801@gmail.com>
	
	<50706848.9090104@gmail.com> <50706B5B.5050008@gmail.com>
In-Reply-To: <50706B5B.5050008@gmail.com>
Cc: "xen-users@lists.xen.org" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] I offer a reward of USD$50 + VGA card Giveaway to
 anyone who can solve my Xen VGA Passthrough Problem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0957683884909131142=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============0957683884909131142==
Content-Type: multipart/alternative;
 boundary="------------030908020606040802070607"

This is a multi-part message in MIME format.
--------------030908020606040802070607
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I just had Xen 4.3-unstable changeset 26004 compiled, installed and 
working, after applying Jean David Techer's revision 25240 patchset. 
BUT, as usual, I get the Windows HVM domU device manager error code 43 
and error code 10.

I have also migrated to Ubuntu 12.04.1 LTS SERVER Edition. My current 
Linux dom0 kernel is 3.6.1.

-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore



On 10/07/2012 01:33 AM, Teo En Ming (Zhang Enming) wrote:
> I just had Xen 4.3-unstable changeset 25993 compiled, installed and 
> working, after applying Jean David Techer's revision 25240 patchset. 
> BUT, as usual, I get the WIndows HVM domU device manager error code 43 
> and error code 10.
>
> Somebody please enlighten me!
> -- 
> Yours sincerely,
>
> Mr. Teo En Ming (Zhang Enming)
> Singapore
>
> On 07/10/2012 01:20, Teo En Ming (Zhang Enming) wrote:
>> LOL. My Xen VGA Passthrough problem is long overdue. I have been 
>> trying to fix the problem since March 2012.
>>
>> -- 
>> Yours sincerely,
>>
>> Mr. Teo En Ming (Zhang Enming)
>> Singapore
>>
>>
>> On 07/10/2012 00:56, chris wrote:
>>>
>>> Sounds like someone is jealous of all the recent success reports :)
>>>
>>> On Oct 6, 2012 12:51 PM, "Teo En Ming (Zhang Enming)" 
>>> >> > wrote:
>>>
>>>     _History_
>>>
>>>     I have 100% success in Xen VGA Passthrough with Xen 3.5-unstable
>>>     with my first Palit NVIDIA Geforce 8400 GS VGA card in 2009,
>>>     which is 3 years ago. Then my first Palit NVIDIA Geforce 8400 GS
>>>     VGA card overheated and malfunctioned. So I bought a 2nd Palit
>>>     NVIDIA Geforce 8400 GS VGA card several months ago in March 2012
>>>     for S$44, to replace the first card. At that point in time, Xen
>>>     was already of version 4.2-unstable. I have tried to passthrough
>>>     my 2nd Palit NVIDIA Geforce 8400 GS, which is only partially
>>>     working, or partial success. _In Windows 8 HVM domU, you will
>>>     see a yellow triangle with exclamation mark and error code 43 in
>>>     Device Manager for the 2nd Palit NVIDIA Geforce 8400 GS. In
>>>     Windows XP Home Edition HVM domU, you will see a yellow circle
>>>     with exclamation mark and error code 10 in Device Manager for
>>>     the 2nd Palit NVIDIA Geforce 8400 GS._
>>>
>>>     Then I noticed Jean David Techer uses a Geforce 560 Ti for his
>>>     Xen VGA Passthrough. So 1-2 weeks ago I bought a EVGA Geforce
>>>     GTX 560 1 GB GDDR5 for S$269. Same thing. Xen VGA Passthrough is
>>>     only partially working or partial success. So I went back to the
>>>     computer shop and exchanged my EVGA Geforce GTX 560 with a
>>>     Gigabyte Geforce GTX 560 1 GB GDDR5, which costs S$289. Again,
>>>     Xen VGA Passthrough is only partially working or partial
>>>     success. _In Windows 8 HVM domU, you will see a yellow triangle
>>>     with exclamation mark and error code 43 in Device Manager for
>>>     the Gigabyte Geforce GTX 560. In Windows XP Home Edition HVM
>>>     domU, you will see a yellow circle with exclamation mark and
>>>     error code 10 in Device Manager for the Gigabyte Geforce GTX 560._
>>>
>>>     _The Challenge_
>>>
>>>     My computer hardware specifications:
>>>
>>>     Processor: Intel Pentium Dual Core E2300 @ 2.8 GHz
>>>     Motherboard: Intel DQ45CB Desktop Board with VT-d enabled
>>>     VGA Card: Gigabyte Geforce GTX 560 1 GB GDDR5
>>>     Memory: 6 GB
>>>
>>>     My computer software specifications:
>>>
>>>     Host operating system: Ubuntu 12.04.1 LTS Desktop Linux
>>>     Xen Hypervisor version: (a) Xen 4.2-unstable Changeset 25099 (b)
>>>     Xen 4.2.1-pre (c) Xen 4.3-unstable Changeset 25993
>>>     Linux Dom0 Kernel: (a) 3.5.4 (b) 3.6.0-rc7
>>>     Windows HVM domU: (a) Windows XP Home Edition SP3 (b) Windows 8
>>>     Release Preview 64-bit
>>>
>>>     Manuals which I have followed in getting Xen VGA Passthrough done:
>>>
>>>     (1)
>>>     http://wiki.xen.org/wiki/Building_and_Installing_Xen_4.x_and_Linux_Kernel_3.x_on_Ubuntu_and_Debian_Linux
>>>
>>>     (2)
>>>     http://wiki.xen.org/wiki/Xen_VGA_Passthrough_to_Windows_8_with_Xen_4.2-unstable
>>>
>>>     The above 2 are manuals which I have written myself, after
>>>     studying several Xen Wiki Pages and Jean David Techer's notes.
>>>
>>>     Now, the above 2 manuals are the same manuals which I have used
>>>     to obtain 100% success in Xen VGA Passthrough for Frank Lyon's
>>>     NVIDIA Quadro 6000. Yes, 100% success. Absolutely no yellow
>>>     triangle with exclamation mark and error code 43 in Windows 7
>>>     and Windows 8 HVM domU. It is an irony and a joke that, with the
>>>     same set of manuals which I have written, I cannot get 100%
>>>     success in Xen VGA Passthrough with my very own display cards.
>>>     Frank Lyon's NVIDIA Quadro 6000 costs S$6000++, and I can't
>>>     afford it.
>>>
>>>     So now, the problem stands. I get a yellow triangle with
>>>     exclamation mark and error code 43 in device manager for
>>>     Gigabyte Geforce GTX 560 in Windows 8 HVM domU and a yellow
>>>     circle with exclamation mark and error code 10 in device manager
>>>     for Gigabyte Geforce GTX 560 in Windows XP Home Edition HVM domU.
>>>
>>>     _The Reward_
>>>
>>>     1. USD$50 in cash
>>>     2. Palit NVIDIA Geforce 8400 GS PCI Express x16 VGA card (costs
>>>     S$44)
>>>
>>>     _How to Get the Reward_
>>>
>>>     If I can say that you have solved my Xen VGA Passthrough problem
>>>     100%, you get the reward! Basically, the idea is to get rid of
>>>     the yellow triangle with exclamation mark and error code 43 in
>>>     Windows 8 HVM domU and the yellow circle with exclamation mark
>>>     and error code 10 in Windows XP HVM domU.
>>>
>>>     Hence,
>>>
>>>     (1) If you can tell me off-hand the solution which leads to my
>>>     Xen VGA Passthrough problem being solved 100%, you get the
>>>     reward. OR
>>>
>>>     (2) You have spotted mistakes or errors in the manuals which I
>>>     have written, leading to my Xen VGA Passthrough problem being
>>>     solved 100%. You get the reward. OR
>>>
>>>     (3) You have a VT-d capable motherboard and processor, and a
>>>     compatible NVIDIA Geforce GTX 560 like mine, and follows the 2
>>>     manuals which I have written for your Xen VGA Passthrough needs.
>>>     If you can obtain 100% success, please tell me the mistakes or
>>>     errors in my manuals, which leads to my Xen VGA Passthrough
>>>     problem being solved 100%. You get the reward.
>>>
>>>     *_100% success means no error code 43 and no error code 10._*
>>>
>>>     For a start, you may follow the thread series "*Help Needed from
>>>     Xen Developers: Nasty Yellow Triangle with Exclamation Mark and
>>>     Error Code 43 in Device Manager in Windows 8 HVM domU
>>>     "
>>>     in the xen-users and xen-devel mailing lists.*
>>>
>>>     Please note that the prize money of US$50 is guaranteed and
>>>     there is only one winner. There is no closing date for this
>>>     challenge.
>>>
>>>
>>>     -- 
>>>     Yours sincerely,
>>>
>>>     Mr. Teo En Ming (Zhang Enming)
>>>     Singapore
>>>
>>>
>>>     _______________________________________________
>>>     Xen-devel mailing list
>>>     Xen-devel@lists.xen.org 
>>>     http://lists.xen.org/xen-devel
>>>
>>
>>
>
>



--------------030908020606040802070607
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
I just had Xen 4.3-unstable changeset
      26004 compiled, installed and working, after applying Jean David
      Techer's revision 25240 patchset. BUT, as usual, I get the Windows
      HVM domU device manager error code 43 and error code 10.

      

      I have also migrated to Ubuntu 12.04.1 LTS SERVER Edition. My
      current Linux dom0 kernel is 3.6.1.

      

      
-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore

      

      

      On 10/07/2012 01:33 AM, Teo En Ming (Zhang Enming) wrote:

    

    

      
      
I just had Xen 4.3-unstable changeset
        25993 compiled, installed and working, after applying Jean David
        Techer's revision 25240 patchset. BUT, as usual, I get the
        WIndows HVM domU device manager error code 43 and error code 10.

        

        Somebody please enlighten me!

        
-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore

        

        On 07/10/2012 01:20, Teo En Ming (Zhang Enming) wrote:

      

      

        
        
LOL. My Xen VGA Passthrough problem
          is long overdue. I have been trying to fix the problem since
          March 2012.

          

          
-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore

          

          

          On 07/10/2012 00:56, chris wrote:

        

        

          
Sounds like someone is jealous of all the recent
            success reports :)

          
On Oct 6, 2012 12:51 PM, "Teo En Ming
            (Zhang Enming)" <singapore.mr.teo.en.ming@gmail.com>


            wrote:

            

              
 History

                

                I have 100% success in Xen VGA Passthrough with Xen
                3.5-unstable with my first Palit NVIDIA Geforce 8400 GS
                VGA card in 2009, which is 3 years ago. Then my first
                Palit NVIDIA Geforce 8400 GS VGA card overheated and
                malfunctioned. So I bought a 2nd Palit NVIDIA Geforce
                8400 GS VGA card several months ago in March 2012 for
                S$44, to replace the first card. At that point in time,
                Xen was already of version 4.2-unstable. I have tried to
                passthrough my 2nd Palit NVIDIA Geforce 8400 GS, which
                is only partially working, or partial success. In
                  Windows 8 HVM domU, you will see a yellow triangle
                  with exclamation mark and error code 43 in Device
                  Manager for the 2nd Palit NVIDIA Geforce 8400 GS. In
                  Windows XP Home Edition HVM domU, you will see a
                  yellow circle with exclamation mark and error code 10
                  in Device Manager for the 2nd Palit NVIDIA Geforce
                  8400 GS.

                

                Then I noticed Jean David Techer uses a Geforce 560 Ti
                for his Xen VGA Passthrough. So 1-2 weeks ago I bought a
                EVGA Geforce GTX 560 1 GB GDDR5 for S$269. Same thing.
                Xen VGA Passthrough is only partially working or partial
                success. So I went back to the computer shop and
                exchanged my EVGA Geforce GTX 560 with a Gigabyte
                Geforce GTX 560 1 GB GDDR5, which costs S$289. Again,
                Xen VGA Passthrough is only partially working or partial
                success. In Windows 8 HVM domU, you will see a
                  yellow triangle with exclamation mark and error code
                  43 in Device Manager for the Gigabyte Geforce GTX 560.
                  In Windows XP Home Edition HVM domU, you will see a
                  yellow circle with exclamation mark and error code 10
                  in Device Manager for the Gigabyte Geforce GTX 560.

                

                The Challenge

                

                My computer hardware specifications:

                

                Processor: Intel Pentium Dual Core E2300 @ 2.8 GHz

                Motherboard: Intel DQ45CB Desktop Board with VT-d
                enabled

                VGA Card: Gigabyte Geforce GTX 560 1 GB GDDR5

                Memory: 6 GB

                

                My computer software specifications:

                

                Host operating system: Ubuntu 12.04.1 LTS Desktop Linux

                Xen Hypervisor version: (a) Xen 4.2-unstable Changeset
                25099 (b) Xen 4.2.1-pre (c) Xen 4.3-unstable Changeset
                25993

                Linux Dom0 Kernel: (a) 3.5.4 (b) 3.6.0-rc7

                Windows HVM domU: (a) Windows XP Home Edition SP3 (b)
                Windows 8 Release Preview 64-bit

                

                Manuals which I have followed in getting Xen VGA
                Passthrough done:

                

                (1) http://wiki.xen.org/wiki/Building_and_Installing_Xen_4.x_and_Linux_Kernel_3.x_on_Ubuntu_and_Debian_Linux

                

                (2) http://wiki.xen.org/wiki/Xen_VGA_Passthrough_to_Windows_8_with_Xen_4.2-unstable

                

                The above 2 are manuals which I have written myself,
                after studying several Xen Wiki Pages and Jean David
                Techer's notes.

                

                Now, the above 2 manuals are the same manuals which I
                have used to obtain 100% success in Xen VGA Passthrough
                for Frank Lyon's NVIDIA Quadro 6000. Yes, 100% success.
                Absolutely no yellow triangle with exclamation mark and
                error code 43 in Windows 7 and Windows 8 HVM domU. It is
                an irony and a joke that, with the same set of manuals
                which I have written, I cannot get 100% success in Xen
                VGA Passthrough with my very own display cards. Frank
                Lyon's NVIDIA Quadro 6000 costs S$6000++, and I can't
                afford it. 

                

                So now, the problem stands. I get a yellow triangle with
                exclamation mark and error code 43 in device manager for
                Gigabyte Geforce GTX 560 in Windows 8 HVM domU and a
                yellow circle with exclamation mark and error code 10 in
                device manager for Gigabyte Geforce GTX 560 in Windows
                XP Home Edition HVM domU.

                

                The Reward

                

                1. USD$50 in cash

                2. Palit NVIDIA Geforce 8400 GS PCI Express x16 VGA card
                (costs S$44)

                

                How to Get the Reward

                

                If I can say that you have solved my Xen VGA Passthrough
                problem 100%, you get the reward! Basically, the idea is
                to get rid of the yellow triangle with exclamation mark
                and error code 43 in Windows 8 HVM domU and the yellow
                circle with exclamation mark and error code 10 in
                Windows XP HVM domU.

                

                Hence,

                

                (1) If you can tell me off-hand the solution which leads
                to my Xen VGA Passthrough problem being solved 100%, you
                get the reward. OR

                

                (2) You have spotted mistakes or errors in the manuals
                which I have written, leading to my Xen VGA Passthrough
                problem being solved 100%. You get the reward. OR

                

                (3) You have a VT-d capable motherboard and processor,
                and a compatible NVIDIA Geforce GTX 560 like mine, and
                follows the 2 manuals which I have written for your Xen
                VGA Passthrough needs. If you can obtain 100% success,
                please tell me the mistakes or errors in my manuals,
                which leads to my Xen VGA Passthrough problem being
                solved 100%. You get the reward.

                

                100% success means no error code 43 and no error
                    code 10.

                

                For a start, you may follow the thread series "Help Needed from Xen Developers:
                    Nasty Yellow Triangle with Exclamation Mark and
                    Error Code 43 in Device Manager in Windows 8 HVM
                    domU" in the xen-users and xen-devel mailing
                  lists.

                

                Please note that the prize money of US$50 is guaranteed
                and there is only one winner. There is no closing date
                for this challenge.

                

                

                
-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore

              

              

              _______________________________________________

              Xen-devel mailing list

              Xen-devel@lists.xen.org

              http://lists.xen.org/xen-devel

              

            

          

        

        

        

      

      

      

    

    

    

    

  


--------------030908020606040802070607--


--===============0957683884909131142==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0957683884909131142==--


From xen-devel-bounces@lists.xen.org Wed Oct 10 05:16:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 05:16:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLodu-0007ow-57; Wed, 10 Oct 2012 05:15:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLods-0007on-FH
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 05:15:36 +0000
Received: from [85.158.143.99:24468] by server-3.bemta-4.messagelabs.com id
	A6/01-10986-77405705; Wed, 10 Oct 2012 05:15:35 +0000
X-Env-Sender: singapore.mr.teo.en.ming@gmail.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1349846132!25989585!1
X-Originating-IP: [209.85.220.45]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21750 invoked from network); 10 Oct 2012 05:15:33 -0000
Received: from mail-pa0-f45.google.com (HELO mail-pa0-f45.google.com)
	(209.85.220.45)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 05:15:33 -0000
Received: by mail-pa0-f45.google.com with SMTP id fb10so193926pad.32
	for ; Tue, 09 Oct 2012 22:15:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type;
	bh=cqiJTAp9+fRWvcCqTk7+rILtpiw5qXWdJrEKPtMsL0o=;
	b=fgQxfpX2sRzdphI4M8O6z5sz2h33P5fa7PyoBhBX5TY8u0pVEN4r7EL9PVug3xurgE
	pks511nsNbozev/bsdg3wiE2qHrV6ifjB9qhzSLIr9M1PsuSUOdENy0uYOv6GO/ACq9p
	efinvUo6l7tvjcgTAGUK/hORDkRntaT19S2l0hB4TbPRxx/GqsWBVFO/OJmfi8ifQkqd
	JekQUkbD8a/etECKEtmWY/mawcnsEhWj7y4Pq36EQBAic4sVBXLiVtoHjJF/TmofraRz
	OLORL1LqH0IRzFyn0wbITpb+B3Ooxp/0s2K0dpZA9t4ydw+a0NIURYZN5kHBoAFVPxIH
	lUdQ==
Received: by 10.68.235.68 with SMTP id uk4mr69892533pbc.52.1349846131431;
	Tue, 09 Oct 2012 22:15:31 -0700 (PDT)
Received: from [192.168.1.2] (cm152.gamma205.maxonline.com.sg.
	[202.156.205.152])
	by mx.google.com with ESMTPS id oi2sm438068pbb.62.2012.10.09.22.15.28
	(version=SSLv3 cipher=OTHER); Tue, 09 Oct 2012 22:15:30 -0700 (PDT)
Message-ID: <5075046F.5090900@gmail.com>
Date: Wed, 10 Oct 2012 13:15:27 +0800
From: "Teo En Ming (Zhang Enming)" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: "Teo En Ming (Zhang Enming)" 
References: <50706112.1030801@gmail.com>
	
	<50706848.9090104@gmail.com> <50706B5B.5050008@gmail.com>
In-Reply-To: <50706B5B.5050008@gmail.com>
Cc: "xen-users@lists.xen.org" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] I offer a reward of USD$50 + VGA card Giveaway to
 anyone who can solve my Xen VGA Passthrough Problem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0957683884909131142=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============0957683884909131142==
Content-Type: multipart/alternative;
 boundary="------------030908020606040802070607"

This is a multi-part message in MIME format.
--------------030908020606040802070607
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I just had Xen 4.3-unstable changeset 26004 compiled, installed and 
working, after applying Jean David Techer's revision 25240 patchset. 
BUT, as usual, I get the Windows HVM domU device manager error code 43 
and error code 10.

I have also migrated to Ubuntu 12.04.1 LTS SERVER Edition. My current 
Linux dom0 kernel is 3.6.1.

-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore



On 10/07/2012 01:33 AM, Teo En Ming (Zhang Enming) wrote:
> I just had Xen 4.3-unstable changeset 25993 compiled, installed and 
> working, after applying Jean David Techer's revision 25240 patchset. 
> BUT, as usual, I get the WIndows HVM domU device manager error code 43 
> and error code 10.
>
> Somebody please enlighten me!
> -- 
> Yours sincerely,
>
> Mr. Teo En Ming (Zhang Enming)
> Singapore
>
> On 07/10/2012 01:20, Teo En Ming (Zhang Enming) wrote:
>> LOL. My Xen VGA Passthrough problem is long overdue. I have been 
>> trying to fix the problem since March 2012.
>>
>> -- 
>> Yours sincerely,
>>
>> Mr. Teo En Ming (Zhang Enming)
>> Singapore
>>
>>
>> On 07/10/2012 00:56, chris wrote:
>>>
>>> Sounds like someone is jealous of all the recent success reports :)
>>>
>>> On Oct 6, 2012 12:51 PM, "Teo En Ming (Zhang Enming)" 
>>> >> > wrote:
>>>
>>>     _History_
>>>
>>>     I have 100% success in Xen VGA Passthrough with Xen 3.5-unstable
>>>     with my first Palit NVIDIA Geforce 8400 GS VGA card in 2009,
>>>     which is 3 years ago. Then my first Palit NVIDIA Geforce 8400 GS
>>>     VGA card overheated and malfunctioned. So I bought a 2nd Palit
>>>     NVIDIA Geforce 8400 GS VGA card several months ago in March 2012
>>>     for S$44, to replace the first card. At that point in time, Xen
>>>     was already of version 4.2-unstable. I have tried to passthrough
>>>     my 2nd Palit NVIDIA Geforce 8400 GS, which is only partially
>>>     working, or partial success. _In Windows 8 HVM domU, you will
>>>     see a yellow triangle with exclamation mark and error code 43 in
>>>     Device Manager for the 2nd Palit NVIDIA Geforce 8400 GS. In
>>>     Windows XP Home Edition HVM domU, you will see a yellow circle
>>>     with exclamation mark and error code 10 in Device Manager for
>>>     the 2nd Palit NVIDIA Geforce 8400 GS._
>>>
>>>     Then I noticed Jean David Techer uses a Geforce 560 Ti for his
>>>     Xen VGA Passthrough. So 1-2 weeks ago I bought a EVGA Geforce
>>>     GTX 560 1 GB GDDR5 for S$269. Same thing. Xen VGA Passthrough is
>>>     only partially working or partial success. So I went back to the
>>>     computer shop and exchanged my EVGA Geforce GTX 560 with a
>>>     Gigabyte Geforce GTX 560 1 GB GDDR5, which costs S$289. Again,
>>>     Xen VGA Passthrough is only partially working or partial
>>>     success. _In Windows 8 HVM domU, you will see a yellow triangle
>>>     with exclamation mark and error code 43 in Device Manager for
>>>     the Gigabyte Geforce GTX 560. In Windows XP Home Edition HVM
>>>     domU, you will see a yellow circle with exclamation mark and
>>>     error code 10 in Device Manager for the Gigabyte Geforce GTX 560._
>>>
>>>     _The Challenge_
>>>
>>>     My computer hardware specifications:
>>>
>>>     Processor: Intel Pentium Dual Core E2300 @ 2.8 GHz
>>>     Motherboard: Intel DQ45CB Desktop Board with VT-d enabled
>>>     VGA Card: Gigabyte Geforce GTX 560 1 GB GDDR5
>>>     Memory: 6 GB
>>>
>>>     My computer software specifications:
>>>
>>>     Host operating system: Ubuntu 12.04.1 LTS Desktop Linux
>>>     Xen Hypervisor version: (a) Xen 4.2-unstable Changeset 25099 (b)
>>>     Xen 4.2.1-pre (c) Xen 4.3-unstable Changeset 25993
>>>     Linux Dom0 Kernel: (a) 3.5.4 (b) 3.6.0-rc7
>>>     Windows HVM domU: (a) Windows XP Home Edition SP3 (b) Windows 8
>>>     Release Preview 64-bit
>>>
>>>     Manuals which I have followed in getting Xen VGA Passthrough done:
>>>
>>>     (1)
>>>     http://wiki.xen.org/wiki/Building_and_Installing_Xen_4.x_and_Linux_Kernel_3.x_on_Ubuntu_and_Debian_Linux
>>>
>>>     (2)
>>>     http://wiki.xen.org/wiki/Xen_VGA_Passthrough_to_Windows_8_with_Xen_4.2-unstable
>>>
>>>     The above 2 are manuals which I have written myself, after
>>>     studying several Xen Wiki Pages and Jean David Techer's notes.
>>>
>>>     Now, the above 2 manuals are the same manuals which I have used
>>>     to obtain 100% success in Xen VGA Passthrough for Frank Lyon's
>>>     NVIDIA Quadro 6000. Yes, 100% success. Absolutely no yellow
>>>     triangle with exclamation mark and error code 43 in Windows 7
>>>     and Windows 8 HVM domU. It is an irony and a joke that, with the
>>>     same set of manuals which I have written, I cannot get 100%
>>>     success in Xen VGA Passthrough with my very own display cards.
>>>     Frank Lyon's NVIDIA Quadro 6000 costs S$6000++, and I can't
>>>     afford it.
>>>
>>>     So now, the problem stands. I get a yellow triangle with
>>>     exclamation mark and error code 43 in device manager for
>>>     Gigabyte Geforce GTX 560 in Windows 8 HVM domU and a yellow
>>>     circle with exclamation mark and error code 10 in device manager
>>>     for Gigabyte Geforce GTX 560 in Windows XP Home Edition HVM domU.
>>>
>>>     _The Reward_
>>>
>>>     1. USD$50 in cash
>>>     2. Palit NVIDIA Geforce 8400 GS PCI Express x16 VGA card (costs
>>>     S$44)
>>>
>>>     _How to Get the Reward_
>>>
>>>     If I can say that you have solved my Xen VGA Passthrough problem
>>>     100%, you get the reward! Basically, the idea is to get rid of
>>>     the yellow triangle with exclamation mark and error code 43 in
>>>     Windows 8 HVM domU and the yellow circle with exclamation mark
>>>     and error code 10 in Windows XP HVM domU.
>>>
>>>     Hence,
>>>
>>>     (1) If you can tell me off-hand the solution which leads to my
>>>     Xen VGA Passthrough problem being solved 100%, you get the
>>>     reward. OR
>>>
>>>     (2) You have spotted mistakes or errors in the manuals which I
>>>     have written, leading to my Xen VGA Passthrough problem being
>>>     solved 100%. You get the reward. OR
>>>
>>>     (3) You have a VT-d capable motherboard and processor, and a
>>>     compatible NVIDIA Geforce GTX 560 like mine, and follows the 2
>>>     manuals which I have written for your Xen VGA Passthrough needs.
>>>     If you can obtain 100% success, please tell me the mistakes or
>>>     errors in my manuals, which leads to my Xen VGA Passthrough
>>>     problem being solved 100%. You get the reward.
>>>
>>>     *_100% success means no error code 43 and no error code 10._*
>>>
>>>     For a start, you may follow the thread series "*Help Needed from
>>>     Xen Developers: Nasty Yellow Triangle with Exclamation Mark and
>>>     Error Code 43 in Device Manager in Windows 8 HVM domU
>>>     "
>>>     in the xen-users and xen-devel mailing lists.*
>>>
>>>     Please note that the prize money of US$50 is guaranteed and
>>>     there is only one winner. There is no closing date for this
>>>     challenge.
>>>
>>>
>>>     -- 
>>>     Yours sincerely,
>>>
>>>     Mr. Teo En Ming (Zhang Enming)
>>>     Singapore
>>>
>>>
>>>     _______________________________________________
>>>     Xen-devel mailing list
>>>     Xen-devel@lists.xen.org 
>>>     http://lists.xen.org/xen-devel
>>>
>>
>>
>
>



--------------030908020606040802070607
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
I just had Xen 4.3-unstable changeset
      26004 compiled, installed and working, after applying Jean David
      Techer's revision 25240 patchset. BUT, as usual, I get the Windows
      HVM domU device manager error code 43 and error code 10.

      

      I have also migrated to Ubuntu 12.04.1 LTS SERVER Edition. My
      current Linux dom0 kernel is 3.6.1.

      

      
-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore

      

      

      On 10/07/2012 01:33 AM, Teo En Ming (Zhang Enming) wrote:

    

    

      
      
I just had Xen 4.3-unstable changeset
        25993 compiled, installed and working, after applying Jean David
        Techer's revision 25240 patchset. BUT, as usual, I get the
        WIndows HVM domU device manager error code 43 and error code 10.

        

        Somebody please enlighten me!

        
-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore

        

        On 07/10/2012 01:20, Teo En Ming (Zhang Enming) wrote:

      

      

        
        
LOL. My Xen VGA Passthrough problem
          is long overdue. I have been trying to fix the problem since
          March 2012.

          

          
-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore

          

          

          On 07/10/2012 00:56, chris wrote:

        

        

          
Sounds like someone is jealous of all the recent
            success reports :)

          
On Oct 6, 2012 12:51 PM, "Teo En Ming
            (Zhang Enming)" <singapore.mr.teo.en.ming@gmail.com>


            wrote:

            

              
 History

                

                I have 100% success in Xen VGA Passthrough with Xen
                3.5-unstable with my first Palit NVIDIA Geforce 8400 GS
                VGA card in 2009, which is 3 years ago. Then my first
                Palit NVIDIA Geforce 8400 GS VGA card overheated and
                malfunctioned. So I bought a 2nd Palit NVIDIA Geforce
                8400 GS VGA card several months ago in March 2012 for
                S$44, to replace the first card. At that point in time,
                Xen was already of version 4.2-unstable. I have tried to
                passthrough my 2nd Palit NVIDIA Geforce 8400 GS, which
                is only partially working, or partial success. In
                  Windows 8 HVM domU, you will see a yellow triangle
                  with exclamation mark and error code 43 in Device
                  Manager for the 2nd Palit NVIDIA Geforce 8400 GS. In
                  Windows XP Home Edition HVM domU, you will see a
                  yellow circle with exclamation mark and error code 10
                  in Device Manager for the 2nd Palit NVIDIA Geforce
                  8400 GS.

                

                Then I noticed Jean David Techer uses a Geforce 560 Ti
                for his Xen VGA Passthrough. So 1-2 weeks ago I bought a
                EVGA Geforce GTX 560 1 GB GDDR5 for S$269. Same thing.
                Xen VGA Passthrough is only partially working or partial
                success. So I went back to the computer shop and
                exchanged my EVGA Geforce GTX 560 with a Gigabyte
                Geforce GTX 560 1 GB GDDR5, which costs S$289. Again,
                Xen VGA Passthrough is only partially working or partial
                success. In Windows 8 HVM domU, you will see a
                  yellow triangle with exclamation mark and error code
                  43 in Device Manager for the Gigabyte Geforce GTX 560.
                  In Windows XP Home Edition HVM domU, you will see a
                  yellow circle with exclamation mark and error code 10
                  in Device Manager for the Gigabyte Geforce GTX 560.

                

                The Challenge

                

                My computer hardware specifications:

                

                Processor: Intel Pentium Dual Core E2300 @ 2.8 GHz

                Motherboard: Intel DQ45CB Desktop Board with VT-d
                enabled

                VGA Card: Gigabyte Geforce GTX 560 1 GB GDDR5

                Memory: 6 GB

                

                My computer software specifications:

                

                Host operating system: Ubuntu 12.04.1 LTS Desktop Linux

                Xen Hypervisor version: (a) Xen 4.2-unstable Changeset
                25099 (b) Xen 4.2.1-pre (c) Xen 4.3-unstable Changeset
                25993

                Linux Dom0 Kernel: (a) 3.5.4 (b) 3.6.0-rc7

                Windows HVM domU: (a) Windows XP Home Edition SP3 (b)
                Windows 8 Release Preview 64-bit

                

                Manuals which I have followed in getting Xen VGA
                Passthrough done:

                

                (1) http://wiki.xen.org/wiki/Building_and_Installing_Xen_4.x_and_Linux_Kernel_3.x_on_Ubuntu_and_Debian_Linux

                

                (2) http://wiki.xen.org/wiki/Xen_VGA_Passthrough_to_Windows_8_with_Xen_4.2-unstable

                

                The above 2 are manuals which I have written myself,
                after studying several Xen Wiki Pages and Jean David
                Techer's notes.

                

                Now, the above 2 manuals are the same manuals which I
                have used to obtain 100% success in Xen VGA Passthrough
                for Frank Lyon's NVIDIA Quadro 6000. Yes, 100% success.
                Absolutely no yellow triangle with exclamation mark and
                error code 43 in Windows 7 and Windows 8 HVM domU. It is
                an irony and a joke that, with the same set of manuals
                which I have written, I cannot get 100% success in Xen
                VGA Passthrough with my very own display cards. Frank
                Lyon's NVIDIA Quadro 6000 costs S$6000++, and I can't
                afford it. 

                

                So now, the problem stands. I get a yellow triangle with
                exclamation mark and error code 43 in device manager for
                Gigabyte Geforce GTX 560 in Windows 8 HVM domU and a
                yellow circle with exclamation mark and error code 10 in
                device manager for Gigabyte Geforce GTX 560 in Windows
                XP Home Edition HVM domU.

                

                The Reward

                

                1. USD$50 in cash

                2. Palit NVIDIA Geforce 8400 GS PCI Express x16 VGA card
                (costs S$44)

                

                How to Get the Reward

                

                If I can say that you have solved my Xen VGA Passthrough
                problem 100%, you get the reward! Basically, the idea is
                to get rid of the yellow triangle with exclamation mark
                and error code 43 in Windows 8 HVM domU and the yellow
                circle with exclamation mark and error code 10 in
                Windows XP HVM domU.

                

                Hence,

                

                (1) If you can tell me off-hand the solution which leads
                to my Xen VGA Passthrough problem being solved 100%, you
                get the reward. OR

                

                (2) You have spotted mistakes or errors in the manuals
                which I have written, leading to my Xen VGA Passthrough
                problem being solved 100%. You get the reward. OR

                

                (3) You have a VT-d capable motherboard and processor,
                and a compatible NVIDIA Geforce GTX 560 like mine, and
                follows the 2 manuals which I have written for your Xen
                VGA Passthrough needs. If you can obtain 100% success,
                please tell me the mistakes or errors in my manuals,
                which leads to my Xen VGA Passthrough problem being
                solved 100%. You get the reward.

                

                100% success means no error code 43 and no error
                    code 10.

                

                For a start, you may follow the thread series "Help Needed from Xen Developers:
                    Nasty Yellow Triangle with Exclamation Mark and
                    Error Code 43 in Device Manager in Windows 8 HVM
                    domU" in the xen-users and xen-devel mailing
                  lists.

                

                Please note that the prize money of US$50 is guaranteed
                and there is only one winner. There is no closing date
                for this challenge.

                

                

                
-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore

              

              

              _______________________________________________

              Xen-devel mailing list

              Xen-devel@lists.xen.org

              http://lists.xen.org/xen-devel

              

            

          

        

        

        

      

      

      

    

    

    

    

  


--------------030908020606040802070607--


--===============0957683884909131142==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0957683884909131142==--


From xen-devel-bounces@lists.xen.org Wed Oct 10 07:54:53 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 07:54:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLr7D-0000SM-NP; Wed, 10 Oct 2012 07:54:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLr7B-0000SH-HY
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 07:54:01 +0000
Received: from [85.158.143.99:25617] by server-3.bemta-4.messagelabs.com id
	9D/25-10075-89925705; Wed, 10 Oct 2012 07:54:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1349855640!23758789!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM1ODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31455 invoked from network); 10 Oct 2012 07:54:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 07:54:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="15061267"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 07:53:06 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 10 Oct 2012 08:53:05 +0100
Message-ID: <1349855585.6952.73.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Dan Magenheimer 
Date: Wed, 10 Oct 2012 08:53:05 +0100
In-Reply-To: <34a52050-5de8-4a4d-91b5-a0a8d5a41710@default>
References: <1349796183-30648-1-git-send-email-arnd@arndb.de>
	<1349796183-30648-6-git-send-email-arnd@arndb.de>
	<1349796958.21847.219.camel@zakaz.uk.xensource.com>
	<34a52050-5de8-4a4d-91b5-a0a8d5a41710@default>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge , Konrad Wilk ,
	"xen-devel@lists.xensource.com" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-09 at 20:24 +0100, Dan Magenheimer wrote:
> > From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> > Sent: Tuesday, October 09, 2012 9:36 AM
> > To: Arnd Bergmann
> > Cc: Jeremy Fitzhardinge; xen-devel@lists.xensource.com; Stefano Stabellini; Konrad Rzeszutek Wilk;
> > linux-kernel@vger.kernel.org; Russell King; linux-arm-kernel@lists.infradead.org
> > Subject: Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
> > 
> > On Tue, 2012-10-09 at 16:22 +0100, Arnd Bergmann wrote:
> > > * The XEN_BALLOON code requires the balloon infrastructure that is not
> > >   getting built on ARM.
> > 
> > I've got patches to enable this, but not for 3.7 so this looks good for
> > now.
> > 
> > > * The tmem hypercall is not available on ARM
> 
> [reduced cc list to just us Xen chickens]
> 
> Any reason that the tmem hypercall is not available on ARM?
> At a minimum, it should be available, but always return failure.

The hypercall is available from a hypervisor point of view, although it
will return -Esomething since some of the required arch functions are
still stubs.

The issue Arnd is fixing is that the client code in the kernel doesn't
currently compile because we haven't added all the required per-arch
scaffolding yet. Or at least that is the case for ballooning, I haven't
tried building tmem myself but I assume Arnd wouldn't be sending the
patch if it built.

I posted a series to enable ballooning on ARM last week (see
<1349363496.866.49.camel@zakaz.uk.xensource.com>).

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 07:54:53 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 07:54:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLr7D-0000SM-NP; Wed, 10 Oct 2012 07:54:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLr7B-0000SH-HY
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 07:54:01 +0000
Received: from [85.158.143.99:25617] by server-3.bemta-4.messagelabs.com id
	9D/25-10075-89925705; Wed, 10 Oct 2012 07:54:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1349855640!23758789!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM1ODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31455 invoked from network); 10 Oct 2012 07:54:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 07:54:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="15061267"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 07:53:06 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 10 Oct 2012 08:53:05 +0100
Message-ID: <1349855585.6952.73.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Dan Magenheimer 
Date: Wed, 10 Oct 2012 08:53:05 +0100
In-Reply-To: <34a52050-5de8-4a4d-91b5-a0a8d5a41710@default>
References: <1349796183-30648-1-git-send-email-arnd@arndb.de>
	<1349796183-30648-6-git-send-email-arnd@arndb.de>
	<1349796958.21847.219.camel@zakaz.uk.xensource.com>
	<34a52050-5de8-4a4d-91b5-a0a8d5a41710@default>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge , Konrad Wilk ,
	"xen-devel@lists.xensource.com" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-09 at 20:24 +0100, Dan Magenheimer wrote:
> > From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> > Sent: Tuesday, October 09, 2012 9:36 AM
> > To: Arnd Bergmann
> > Cc: Jeremy Fitzhardinge; xen-devel@lists.xensource.com; Stefano Stabellini; Konrad Rzeszutek Wilk;
> > linux-kernel@vger.kernel.org; Russell King; linux-arm-kernel@lists.infradead.org
> > Subject: Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
> > 
> > On Tue, 2012-10-09 at 16:22 +0100, Arnd Bergmann wrote:
> > > * The XEN_BALLOON code requires the balloon infrastructure that is not
> > >   getting built on ARM.
> > 
> > I've got patches to enable this, but not for 3.7 so this looks good for
> > now.
> > 
> > > * The tmem hypercall is not available on ARM
> 
> [reduced cc list to just us Xen chickens]
> 
> Any reason that the tmem hypercall is not available on ARM?
> At a minimum, it should be available, but always return failure.

The hypercall is available from a hypervisor point of view, although it
will return -Esomething since some of the required arch functions are
still stubs.

The issue Arnd is fixing is that the client code in the kernel doesn't
currently compile because we haven't added all the required per-arch
scaffolding yet. Or at least that is the case for ballooning, I haven't
tried building tmem myself but I assume Arnd wouldn't be sending the
patch if it built.

I posted a series to enable ballooning on ARM last week (see
<1349363496.866.49.camel@zakaz.uk.xensource.com>).

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 07:55:40 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 07:55:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLr81-0000UX-5u; Wed, 10 Oct 2012 07:54:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLr7z-0000UF-V0
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 07:54:52 +0000
Received: from [85.158.143.99:29956] by server-1.bemta-4.messagelabs.com id
	EF/23-19551-BC925705; Wed, 10 Oct 2012 07:54:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1349855690!32926443!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM1ODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13424 invoked from network); 10 Oct 2012 07:54:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 07:54:50 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="15061345"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 07:54:48 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 10 Oct 2012 08:54:48 +0100
Message-ID: <1349855687.6952.75.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Arnd Bergmann 
Date: Wed, 10 Oct 2012 08:54:47 +0100
In-Reply-To: <201210091821.27818.arnd@arndb.de>
References: <1349796183-30648-1-git-send-email-arnd@arndb.de>
	<1349796183-30648-6-git-send-email-arnd@arndb.de>
	
	<201210091821.27818.arnd@arndb.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge ,
	"xen-devel@lists.xensource.com" ,
	Konrad Rzeszutek Wilk ,
	Stefano Stabellini ,
	"linux-kernel@vger.kernel.org" ,
	Russell King ,
	"linux-arm-kernel@lists.infradead.org"
	
Subject: Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-09 at 19:21 +0100, Arnd Bergmann wrote:
> On Tuesday 09 October 2012, Stefano Stabellini wrote:
> > >  config XEN
> > >       bool "Xen guest support on ARM (EXPERIMENTAL)"
> > >       depends on EXPERIMENTAL && ARM && OF
> > > +     depends on !CPU_V6
> > >       help
> > >         Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
> > 
> > Considering that we rely on the virtualization extensions, this one can
> > be:
> > 
> >     depends on CPU_V7
> > 
> > The rest looks fine. I can submit a second patch to change !CPU_V6 into
> > CPU_V7 later, if you prefer.
> 
> CPU_V6 and CPU_V7 are not exclusive, I saw the problem when building a
> combined kernel for both V6 and V7. The code also needs to depend on ARMv7
> with virtualization extensions, but that is a different issue. We don't
> actually have a configuration symbol for that yet, as far as I can tell.

I don't think the guest kernels (including dom0) need the extensions to
run under Xen, they are only need by Xen itself. The guests should just
see a relatively normal v7 processor. 

Stefano, does that sound right?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 07:55:40 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 07:55:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLr81-0000UX-5u; Wed, 10 Oct 2012 07:54:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLr7z-0000UF-V0
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 07:54:52 +0000
Received: from [85.158.143.99:29956] by server-1.bemta-4.messagelabs.com id
	EF/23-19551-BC925705; Wed, 10 Oct 2012 07:54:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1349855690!32926443!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM1ODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13424 invoked from network); 10 Oct 2012 07:54:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 07:54:50 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="15061345"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 07:54:48 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 10 Oct 2012 08:54:48 +0100
Message-ID: <1349855687.6952.75.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Arnd Bergmann 
Date: Wed, 10 Oct 2012 08:54:47 +0100
In-Reply-To: <201210091821.27818.arnd@arndb.de>
References: <1349796183-30648-1-git-send-email-arnd@arndb.de>
	<1349796183-30648-6-git-send-email-arnd@arndb.de>
	
	<201210091821.27818.arnd@arndb.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge ,
	"xen-devel@lists.xensource.com" ,
	Konrad Rzeszutek Wilk ,
	Stefano Stabellini ,
	"linux-kernel@vger.kernel.org" ,
	Russell King ,
	"linux-arm-kernel@lists.infradead.org"
	
Subject: Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-09 at 19:21 +0100, Arnd Bergmann wrote:
> On Tuesday 09 October 2012, Stefano Stabellini wrote:
> > >  config XEN
> > >       bool "Xen guest support on ARM (EXPERIMENTAL)"
> > >       depends on EXPERIMENTAL && ARM && OF
> > > +     depends on !CPU_V6
> > >       help
> > >         Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
> > 
> > Considering that we rely on the virtualization extensions, this one can
> > be:
> > 
> >     depends on CPU_V7
> > 
> > The rest looks fine. I can submit a second patch to change !CPU_V6 into
> > CPU_V7 later, if you prefer.
> 
> CPU_V6 and CPU_V7 are not exclusive, I saw the problem when building a
> combined kernel for both V6 and V7. The code also needs to depend on ARMv7
> with virtualization extensions, but that is a different issue. We don't
> actually have a configuration symbol for that yet, as far as I can tell.

I don't think the guest kernels (including dom0) need the extensions to
run under Xen, they are only need by Xen itself. The guests should just
see a relatively normal v7 processor. 

Stefano, does that sound right?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 08:39:47 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 08:39:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLroh-0001HU-Sk; Wed, 10 Oct 2012 08:38:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLrof-0001HP-Iy
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 08:38:58 +0000
Received: from [85.158.143.99:21401] by server-3.bemta-4.messagelabs.com id
	76/ED-10075-02435705; Wed, 10 Oct 2012 08:38:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1349858336!23766205!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM1ODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10895 invoked from network); 10 Oct 2012 08:38:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 08:38:56 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="15064526"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 08:38:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 10 Oct 2012 09:38:37 +0100
Message-ID: <1349858315.10070.7.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Daniel De Graaf 
Date: Wed, 10 Oct 2012 09:38:35 +0100
In-Reply-To: <1349807513-10923-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1349801565.21847.228.camel@zakaz.uk.xensource.com>
	<1349807513-10923-1-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Marcus Granado ,
	"andre.przywara@amd.com" ,
	"msw@amazon.com" , "anil@recoil.org" ,
	George Dunlap ,
	Andrew Cooper ,
	Dario Faggioli ,
	Ian Jackson ,
	"xen-devel@lists.xen.org" ,
	"JBeulich@suse.com" ,
	"juergen.gross@ts.fujitsu.com" 
Subject: Re: [Xen-devel] [PATCH RFC] flask: move policy header sources into
	hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-09 at 19:31 +0100, Daniel De Graaf wrote:
> Ian Campbell wrote:
> [...]
> >>> +++ b/xen/xsm/flask/include/av_perm_to_string.h
> > Also, in that case why is this file checked in?
> 
> This patch fixes the autogenerated files, but doesn't fully wire them in
> to things like "make clean" or .{git,hg}ignore. I don't see an obvious
> way to clean generated header files in Xen's build system; perhaps
> someone who knows the build system better can point out the right way to
> wire this up.

xen/arch/x86/Makefile has a clean:: rule which removes autogenerated
stuff like the asm-offsets files. Probably the right model to follow.

Ian.

> 
> --------------------------------------->8----------------------------
> 
> Rather than keeping around headers that are autogenerated in order to
> avoid adding build dependencies from xen/ to files in tools/, move the
> relevant parts of the FLASK policy into the hypervisor tree and generate
> the headers as part of the hypervisor's build.
> 
> Signed-off-by: Daniel De Graaf 
> ---
>  tools/flask/policy/Makefile                        |   2 +-
>  tools/flask/policy/policy/flask/Makefile           |  41 ------
>  xen/xsm/flask/Makefile                             |  21 +++
>  xen/xsm/flask/include/av_perm_to_string.h          | 147 -------------------
>  xen/xsm/flask/include/av_permissions.h             | 157 ---------------------
>  xen/xsm/flask/include/class_to_string.h            |  15 --
>  xen/xsm/flask/include/flask.h                      |  35 -----
>  xen/xsm/flask/include/initial_sid_to_string.h      |  16 ---
>  .../flask => xen/xsm/flask/policy}/access_vectors  |   0
>  .../flask => xen/xsm/flask/policy}/initial_sids    |   0
>  .../xsm/flask/policy}/mkaccess_vector.sh           |   4 +-
>  .../flask => xen/xsm/flask/policy}/mkflask.sh      |   6 +-
>  .../xsm/flask/policy}/security_classes             |   0
>  13 files changed, 27 insertions(+), 417 deletions(-)
>  delete mode 100644 tools/flask/policy/policy/flask/Makefile
>  delete mode 100644 xen/xsm/flask/include/av_perm_to_string.h
>  delete mode 100644 xen/xsm/flask/include/av_permissions.h
>  delete mode 100644 xen/xsm/flask/include/class_to_string.h
>  delete mode 100644 xen/xsm/flask/include/flask.h
>  delete mode 100644 xen/xsm/flask/include/initial_sid_to_string.h
>  rename {tools/flask/policy/policy/flask => xen/xsm/flask/policy}/access_vectors (100%)
>  rename {tools/flask/policy/policy/flask => xen/xsm/flask/policy}/initial_sids (100%)
>  rename {tools/flask/policy/policy/flask => xen/xsm/flask/policy}/mkaccess_vector.sh (97%)
>  rename {tools/flask/policy/policy/flask => xen/xsm/flask/policy}/mkflask.sh (95%)
>  rename {tools/flask/policy/policy/flask => xen/xsm/flask/policy}/security_classes (100%)
> 
> diff --git a/tools/flask/policy/Makefile b/tools/flask/policy/Makefile
> index 5c25cbe..3f5aa38 100644
> --- a/tools/flask/policy/Makefile
> +++ b/tools/flask/policy/Makefile
> @@ -61,7 +61,7 @@ LOADPOLICY := $(SBINDIR)/flask-loadpolicy
>  # policy source layout
>  POLDIR := policy
>  MODDIR := $(POLDIR)/modules
> -FLASKDIR := $(POLDIR)/flask
> +FLASKDIR := ../../../xen/xsm/flask/policy
>  SECCLASS := $(FLASKDIR)/security_classes
>  ISIDS := $(FLASKDIR)/initial_sids
>  AVS := $(FLASKDIR)/access_vectors
> diff --git a/tools/flask/policy/policy/flask/Makefile b/tools/flask/policy/policy/flask/Makefile
> deleted file mode 100644
> index 5f57e88..0000000
> --- a/tools/flask/policy/policy/flask/Makefile
> +++ /dev/null
> @@ -1,41 +0,0 @@
> -# flask needs to know where to export the libselinux headers.
> -LIBSEL ?= ../../libselinux
> -
> -# flask needs to know where to export the kernel headers.
> -LINUXDIR ?= ../../../linux-2.6
> -
> -AWK = awk
> -
> -CONFIG_SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; \
> -          else if [ -x /bin/bash ]; then echo /bin/bash; \
> -          else echo sh; fi ; fi)
> -
> -FLASK_H_DEPEND = security_classes initial_sids
> -AV_H_DEPEND = access_vectors
> -
> -FLASK_H_FILES = class_to_string.h flask.h initial_sid_to_string.h
> -AV_H_FILES = av_perm_to_string.h av_permissions.h
> -ALL_H_FILES = $(FLASK_H_FILES) $(AV_H_FILES)
> -
> -all:  $(ALL_H_FILES)
> -
> -$(FLASK_H_FILES): $(FLASK_H_DEPEND)
> -       $(CONFIG_SHELL) mkflask.sh $(AWK) $(FLASK_H_DEPEND)
> -
> -$(AV_H_FILES): $(AV_H_DEPEND)
> -       $(CONFIG_SHELL) mkaccess_vector.sh $(AWK) $(AV_H_DEPEND)
> -
> -tolib: all
> -       install -m 644 flask.h av_permissions.h $(LIBSEL)/include/selinux
> -       install -m 644 class_to_string.h av_inherit.h common_perm_to_string.h av_perm_to_string.h $(LIBSEL)/src
> -
> -tokern: all
> -       install -m 644 $(ALL_H_FILES) $(LINUXDIR)/security/selinux/include
> -
> -install: all
> -
> -relabel:
> -
> -clean:
> -       rm -f $(FLASK_H_FILES)
> -       rm -f $(AV_H_FILES)
> diff --git a/xen/xsm/flask/Makefile b/xen/xsm/flask/Makefile
> index 92fb410..238495a 100644
> --- a/xen/xsm/flask/Makefile
> +++ b/xen/xsm/flask/Makefile
> @@ -5,3 +5,24 @@ obj-y += flask_op.o
>  subdir-y += ss
> 
>  CFLAGS += -I./include
> +
> +AWK = awk
> +
> +CONFIG_SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; \
> +          else if [ -x /bin/bash ]; then echo /bin/bash; \
> +          else echo sh; fi ; fi)
> +
> +FLASK_H_DEPEND = policy/security_classes policy/initial_sids
> +AV_H_DEPEND = policy/access_vectors
> +
> +FLASK_H_FILES = include/flask.h include/class_to_string.h include/initial_sid_to_string.h
> +AV_H_FILES = include/av_perm_to_string.h include/av_permissions.h
> +ALL_H_FILES = $(FLASK_H_FILES) $(AV_H_FILES)
> +
> +$(obj-y) ss/built_in.o: $(ALL_H_FILES)
> +
> +$(FLASK_H_FILES): $(FLASK_H_DEPEND)
> +       $(CONFIG_SHELL) policy/mkflask.sh $(AWK) $(FLASK_H_DEPEND)
> +
> +$(AV_H_FILES): $(AV_H_DEPEND)
> +       $(CONFIG_SHELL) policy/mkaccess_vector.sh $(AWK) $(AV_H_DEPEND)
> diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
> deleted file mode 100644
> index c3f2370..0000000
> --- a/xen/xsm/flask/include/av_perm_to_string.h
> +++ /dev/null
> @@ -1,147 +0,0 @@
> -/* This file is automatically generated.  Do not edit. */
> -   S_(SECCLASS_XEN, XEN__SCHEDULER, "scheduler")
> -   S_(SECCLASS_XEN, XEN__SETTIME, "settime")
> -   S_(SECCLASS_XEN, XEN__TBUFCONTROL, "tbufcontrol")
> -   S_(SECCLASS_XEN, XEN__READCONSOLE, "readconsole")
> -   S_(SECCLASS_XEN, XEN__CLEARCONSOLE, "clearconsole")
> -   S_(SECCLASS_XEN, XEN__PERFCONTROL, "perfcontrol")
> -   S_(SECCLASS_XEN, XEN__MTRR_ADD, "mtrr_add")
> -   S_(SECCLASS_XEN, XEN__MTRR_DEL, "mtrr_del")
> -   S_(SECCLASS_XEN, XEN__MTRR_READ, "mtrr_read")
> -   S_(SECCLASS_XEN, XEN__MICROCODE, "microcode")
> -   S_(SECCLASS_XEN, XEN__PHYSINFO, "physinfo")
> -   S_(SECCLASS_XEN, XEN__QUIRK, "quirk")
> -   S_(SECCLASS_XEN, XEN__WRITECONSOLE, "writeconsole")
> -   S_(SECCLASS_XEN, XEN__READAPIC, "readapic")
> -   S_(SECCLASS_XEN, XEN__WRITEAPIC, "writeapic")
> -   S_(SECCLASS_XEN, XEN__PRIVPROFILE, "privprofile")
> -   S_(SECCLASS_XEN, XEN__NONPRIVPROFILE, "nonprivprofile")
> -   S_(SECCLASS_XEN, XEN__KEXEC, "kexec")
> -   S_(SECCLASS_XEN, XEN__FIRMWARE, "firmware")
> -   S_(SECCLASS_XEN, XEN__SLEEP, "sleep")
> -   S_(SECCLASS_XEN, XEN__FREQUENCY, "frequency")
> -   S_(SECCLASS_XEN, XEN__GETIDLE, "getidle")
> -   S_(SECCLASS_XEN, XEN__DEBUG, "debug")
> -   S_(SECCLASS_XEN, XEN__GETCPUINFO, "getcpuinfo")
> -   S_(SECCLASS_XEN, XEN__HEAP, "heap")
> -   S_(SECCLASS_XEN, XEN__PM_OP, "pm_op")
> -   S_(SECCLASS_XEN, XEN__MCA_OP, "mca_op")
> -   S_(SECCLASS_XEN, XEN__LOCKPROF, "lockprof")
> -   S_(SECCLASS_XEN, XEN__CPUPOOL_OP, "cpupool_op")
> -   S_(SECCLASS_XEN, XEN__SCHED_OP, "sched_op")
> -   S_(SECCLASS_XEN, XEN__TMEM_OP, "tmem_op")
> -   S_(SECCLASS_XEN, XEN__TMEM_CONTROL, "tmem_control")
> -   S_(SECCLASS_DOMAIN, DOMAIN__SETVCPUCONTEXT, "setvcpucontext")
> -   S_(SECCLASS_DOMAIN, DOMAIN__PAUSE, "pause")
> -   S_(SECCLASS_DOMAIN, DOMAIN__UNPAUSE, "unpause")
> -   S_(SECCLASS_DOMAIN, DOMAIN__RESUME, "resume")
> -   S_(SECCLASS_DOMAIN, DOMAIN__CREATE, "create")
> -   S_(SECCLASS_DOMAIN, DOMAIN__TRANSITION, "transition")
> -   S_(SECCLASS_DOMAIN, DOMAIN__MAX_VCPUS, "max_vcpus")
> -   S_(SECCLASS_DOMAIN, DOMAIN__DESTROY, "destroy")
> -   S_(SECCLASS_DOMAIN, DOMAIN__SETVCPUAFFINITY, "setvcpuaffinity")
> -   S_(SECCLASS_DOMAIN, DOMAIN__GETVCPUAFFINITY, "getvcpuaffinity")
> -   S_(SECCLASS_DOMAIN, DOMAIN__SCHEDULER, "scheduler")
> -   S_(SECCLASS_DOMAIN, DOMAIN__GETDOMAININFO, "getdomaininfo")
> -   S_(SECCLASS_DOMAIN, DOMAIN__GETVCPUINFO, "getvcpuinfo")
> -   S_(SECCLASS_DOMAIN, DOMAIN__GETVCPUCONTEXT, "getvcpucontext")
> -   S_(SECCLASS_DOMAIN, DOMAIN__SETDOMAINMAXMEM, "setdomainmaxmem")
> -   S_(SECCLASS_DOMAIN, DOMAIN__SETDOMAINHANDLE, "setdomainhandle")
> -   S_(SECCLASS_DOMAIN, DOMAIN__SETDEBUGGING, "setdebugging")
> -   S_(SECCLASS_DOMAIN, DOMAIN__HYPERCALL, "hypercall")
> -   S_(SECCLASS_DOMAIN, DOMAIN__SETTIME, "settime")
> -   S_(SECCLASS_DOMAIN, DOMAIN__SET_TARGET, "set_target")
> -   S_(SECCLASS_DOMAIN, DOMAIN__SHUTDOWN, "shutdown")
> -   S_(SECCLASS_DOMAIN, DOMAIN__SETADDRSIZE, "setaddrsize")
> -   S_(SECCLASS_DOMAIN, DOMAIN__GETADDRSIZE, "getaddrsize")
> -   S_(SECCLASS_DOMAIN, DOMAIN__TRIGGER, "trigger")
> -   S_(SECCLASS_DOMAIN, DOMAIN__GETEXTVCPUCONTEXT, "getextvcpucontext")
> -   S_(SECCLASS_DOMAIN, DOMAIN__SETEXTVCPUCONTEXT, "setextvcpucontext")
> -   S_(SECCLASS_DOMAIN, DOMAIN__GETVCPUEXTSTATE, "getvcpuextstate")
> -   S_(SECCLASS_DOMAIN, DOMAIN__SETVCPUEXTSTATE, "setvcpuextstate")
> -   S_(SECCLASS_DOMAIN, DOMAIN__GETPODTARGET, "getpodtarget")
> -   S_(SECCLASS_DOMAIN, DOMAIN__SETPODTARGET, "setpodtarget")
> -   S_(SECCLASS_DOMAIN, DOMAIN__SET_MISC_INFO, "set_misc_info")
> -   S_(SECCLASS_DOMAIN, DOMAIN__SET_VIRQ_HANDLER, "set_virq_handler")
> -   S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELFROM, "relabelfrom")
> -   S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELTO, "relabelto")
> -   S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELSELF, "relabelself")
> -   S_(SECCLASS_DOMAIN2, DOMAIN2__MAKE_PRIV_FOR, "make_priv_for")
> -   S_(SECCLASS_DOMAIN2, DOMAIN2__SET_AS_TARGET, "set_as_target")
> -   S_(SECCLASS_DOMAIN2, DOMAIN2__SET_CPUID, "set_cpuid")
> -   S_(SECCLASS_DOMAIN2, DOMAIN2__GETTSC, "gettsc")
> -   S_(SECCLASS_DOMAIN2, DOMAIN2__SETTSC, "settsc")
> -   S_(SECCLASS_HVM, HVM__SETHVMC, "sethvmc")
> -   S_(SECCLASS_HVM, HVM__GETHVMC, "gethvmc")
> -   S_(SECCLASS_HVM, HVM__SETPARAM, "setparam")
> -   S_(SECCLASS_HVM, HVM__GETPARAM, "getparam")
> -   S_(SECCLASS_HVM, HVM__PCILEVEL, "pcilevel")
> -   S_(SECCLASS_HVM, HVM__IRQLEVEL, "irqlevel")
> -   S_(SECCLASS_HVM, HVM__PCIROUTE, "pciroute")
> -   S_(SECCLASS_HVM, HVM__BIND_IRQ, "bind_irq")
> -   S_(SECCLASS_HVM, HVM__CACHEATTR, "cacheattr")
> -   S_(SECCLASS_HVM, HVM__TRACKDIRTYVRAM, "trackdirtyvram")
> -   S_(SECCLASS_HVM, HVM__HVMCTL, "hvmctl")
> -   S_(SECCLASS_HVM, HVM__MEM_EVENT, "mem_event")
> -   S_(SECCLASS_HVM, HVM__MEM_SHARING, "mem_sharing")
> -   S_(SECCLASS_HVM, HVM__AUDIT_P2M, "audit_p2m")
> -   S_(SECCLASS_HVM, HVM__SEND_IRQ, "send_irq")
> -   S_(SECCLASS_HVM, HVM__SHARE_MEM, "share_mem")
> -   S_(SECCLASS_EVENT, EVENT__BIND, "bind")
> -   S_(SECCLASS_EVENT, EVENT__SEND, "send")
> -   S_(SECCLASS_EVENT, EVENT__STATUS, "status")
> -   S_(SECCLASS_EVENT, EVENT__NOTIFY, "notify")
> -   S_(SECCLASS_EVENT, EVENT__CREATE, "create")
> -   S_(SECCLASS_EVENT, EVENT__RESET, "reset")
> -   S_(SECCLASS_GRANT, GRANT__MAP_READ, "map_read")
> -   S_(SECCLASS_GRANT, GRANT__MAP_WRITE, "map_write")
> -   S_(SECCLASS_GRANT, GRANT__UNMAP, "unmap")
> -   S_(SECCLASS_GRANT, GRANT__TRANSFER, "transfer")
> -   S_(SECCLASS_GRANT, GRANT__SETUP, "setup")
> -   S_(SECCLASS_GRANT, GRANT__COPY, "copy")
> -   S_(SECCLASS_GRANT, GRANT__QUERY, "query")
> -   S_(SECCLASS_MMU, MMU__MAP_READ, "map_read")
> -   S_(SECCLASS_MMU, MMU__MAP_WRITE, "map_write")
> -   S_(SECCLASS_MMU, MMU__PAGEINFO, "pageinfo")
> -   S_(SECCLASS_MMU, MMU__PAGELIST, "pagelist")
> -   S_(SECCLASS_MMU, MMU__ADJUST, "adjust")
> -   S_(SECCLASS_MMU, MMU__STAT, "stat")
> -   S_(SECCLASS_MMU, MMU__TRANSLATEGP, "translategp")
> -   S_(SECCLASS_MMU, MMU__UPDATEMP, "updatemp")
> -   S_(SECCLASS_MMU, MMU__PHYSMAP, "physmap")
> -   S_(SECCLASS_MMU, MMU__PINPAGE, "pinpage")
> -   S_(SECCLASS_MMU, MMU__MFNLIST, "mfnlist")
> -   S_(SECCLASS_MMU, MMU__MEMORYMAP, "memorymap")
> -   S_(SECCLASS_MMU, MMU__REMOTE_REMAP, "remote_remap")
> -   S_(SECCLASS_MMU, MMU__MMUEXT_OP, "mmuext_op")
> -   S_(SECCLASS_MMU, MMU__EXCHANGE, "exchange")
> -   S_(SECCLASS_SHADOW, SHADOW__DISABLE, "disable")
> -   S_(SECCLASS_SHADOW, SHADOW__ENABLE, "enable")
> -   S_(SECCLASS_SHADOW, SHADOW__LOGDIRTY, "logdirty")
> -   S_(SECCLASS_RESOURCE, RESOURCE__ADD, "add")
> -   S_(SECCLASS_RESOURCE, RESOURCE__REMOVE, "remove")
> -   S_(SECCLASS_RESOURCE, RESOURCE__USE, "use")
> -   S_(SECCLASS_RESOURCE, RESOURCE__ADD_IRQ, "add_irq")
> -   S_(SECCLASS_RESOURCE, RESOURCE__REMOVE_IRQ, "remove_irq")
> -   S_(SECCLASS_RESOURCE, RESOURCE__ADD_IOPORT, "add_ioport")
> -   S_(SECCLASS_RESOURCE, RESOURCE__REMOVE_IOPORT, "remove_ioport")
> -   S_(SECCLASS_RESOURCE, RESOURCE__ADD_IOMEM, "add_iomem")
> -   S_(SECCLASS_RESOURCE, RESOURCE__REMOVE_IOMEM, "remove_iomem")
> -   S_(SECCLASS_RESOURCE, RESOURCE__STAT_DEVICE, "stat_device")
> -   S_(SECCLASS_RESOURCE, RESOURCE__ADD_DEVICE, "add_device")
> -   S_(SECCLASS_RESOURCE, RESOURCE__REMOVE_DEVICE, "remove_device")
> -   S_(SECCLASS_RESOURCE, RESOURCE__PLUG, "plug")
> -   S_(SECCLASS_RESOURCE, RESOURCE__UNPLUG, "unplug")
> -   S_(SECCLASS_RESOURCE, RESOURCE__SETUP, "setup")
> -   S_(SECCLASS_SECURITY, SECURITY__COMPUTE_AV, "compute_av")
> -   S_(SECCLASS_SECURITY, SECURITY__COMPUTE_CREATE, "compute_create")
> -   S_(SECCLASS_SECURITY, SECURITY__COMPUTE_MEMBER, "compute_member")
> -   S_(SECCLASS_SECURITY, SECURITY__CHECK_CONTEXT, "check_context")
> -   S_(SECCLASS_SECURITY, SECURITY__LOAD_POLICY, "load_policy")
> -   S_(SECCLASS_SECURITY, SECURITY__COMPUTE_RELABEL, "compute_relabel")
> -   S_(SECCLASS_SECURITY, SECURITY__COMPUTE_USER, "compute_user")
> -   S_(SECCLASS_SECURITY, SECURITY__SETENFORCE, "setenforce")
> -   S_(SECCLASS_SECURITY, SECURITY__SETBOOL, "setbool")
> -   S_(SECCLASS_SECURITY, SECURITY__SETSECPARAM, "setsecparam")
> -   S_(SECCLASS_SECURITY, SECURITY__ADD_OCONTEXT, "add_ocontext")
> -   S_(SECCLASS_SECURITY, SECURITY__DEL_OCONTEXT, "del_ocontext")
> diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
> deleted file mode 100644
> index 65302e8..0000000
> --- a/xen/xsm/flask/include/av_permissions.h
> +++ /dev/null
> @@ -1,157 +0,0 @@
> -/* This file is automatically generated.  Do not edit. */
> -#define XEN__SCHEDULER                            0x00000001UL
> -#define XEN__SETTIME                              0x00000002UL
> -#define XEN__TBUFCONTROL                          0x00000004UL
> -#define XEN__READCONSOLE                          0x00000008UL
> -#define XEN__CLEARCONSOLE                         0x00000010UL
> -#define XEN__PERFCONTROL                          0x00000020UL
> -#define XEN__MTRR_ADD                             0x00000040UL
> -#define XEN__MTRR_DEL                             0x00000080UL
> -#define XEN__MTRR_READ                            0x00000100UL
> -#define XEN__MICROCODE                            0x00000200UL
> -#define XEN__PHYSINFO                             0x00000400UL
> -#define XEN__QUIRK                                0x00000800UL
> -#define XEN__WRITECONSOLE                         0x00001000UL
> -#define XEN__READAPIC                             0x00002000UL
> -#define XEN__WRITEAPIC                            0x00004000UL
> -#define XEN__PRIVPROFILE                          0x00008000UL
> -#define XEN__NONPRIVPROFILE                       0x00010000UL
> -#define XEN__KEXEC                                0x00020000UL
> -#define XEN__FIRMWARE                             0x00040000UL
> -#define XEN__SLEEP                                0x00080000UL
> -#define XEN__FREQUENCY                            0x00100000UL
> -#define XEN__GETIDLE                              0x00200000UL
> -#define XEN__DEBUG                                0x00400000UL
> -#define XEN__GETCPUINFO                           0x00800000UL
> -#define XEN__HEAP                                 0x01000000UL
> -#define XEN__PM_OP                                0x02000000UL
> -#define XEN__MCA_OP                               0x04000000UL
> -#define XEN__LOCKPROF                             0x08000000UL
> -#define XEN__CPUPOOL_OP                           0x10000000UL
> -#define XEN__SCHED_OP                             0x20000000UL
> -#define XEN__TMEM_OP                              0x40000000UL
> -#define XEN__TMEM_CONTROL                         0x80000000UL
> -
> -#define DOMAIN__SETVCPUCONTEXT                    0x00000001UL
> -#define DOMAIN__PAUSE                             0x00000002UL
> -#define DOMAIN__UNPAUSE                           0x00000004UL
> -#define DOMAIN__RESUME                            0x00000008UL
> -#define DOMAIN__CREATE                            0x00000010UL
> -#define DOMAIN__TRANSITION                        0x00000020UL
> -#define DOMAIN__MAX_VCPUS                         0x00000040UL
> -#define DOMAIN__DESTROY                           0x00000080UL
> -#define DOMAIN__SETVCPUAFFINITY                   0x00000100UL
> -#define DOMAIN__GETVCPUAFFINITY                   0x00000200UL
> -#define DOMAIN__SCHEDULER                         0x00000400UL
> -#define DOMAIN__GETDOMAININFO                     0x00000800UL
> -#define DOMAIN__GETVCPUINFO                       0x00001000UL
> -#define DOMAIN__GETVCPUCONTEXT                    0x00002000UL
> -#define DOMAIN__SETDOMAINMAXMEM                   0x00004000UL
> -#define DOMAIN__SETDOMAINHANDLE                   0x00008000UL
> -#define DOMAIN__SETDEBUGGING                      0x00010000UL
> -#define DOMAIN__HYPERCALL                         0x00020000UL
> -#define DOMAIN__SETTIME                           0x00040000UL
> -#define DOMAIN__SET_TARGET                        0x00080000UL
> -#define DOMAIN__SHUTDOWN                          0x00100000UL
> -#define DOMAIN__SETADDRSIZE                       0x00200000UL
> -#define DOMAIN__GETADDRSIZE                       0x00400000UL
> -#define DOMAIN__TRIGGER                           0x00800000UL
> -#define DOMAIN__GETEXTVCPUCONTEXT                 0x01000000UL
> -#define DOMAIN__SETEXTVCPUCONTEXT                 0x02000000UL
> -#define DOMAIN__GETVCPUEXTSTATE                   0x04000000UL
> -#define DOMAIN__SETVCPUEXTSTATE                   0x08000000UL
> -#define DOMAIN__GETPODTARGET                      0x10000000UL
> -#define DOMAIN__SETPODTARGET                      0x20000000UL
> -#define DOMAIN__SET_MISC_INFO                     0x40000000UL
> -#define DOMAIN__SET_VIRQ_HANDLER                  0x80000000UL
> -
> -#define DOMAIN2__RELABELFROM                      0x00000001UL
> -#define DOMAIN2__RELABELTO                        0x00000002UL
> -#define DOMAIN2__RELABELSELF                      0x00000004UL
> -#define DOMAIN2__MAKE_PRIV_FOR                    0x00000008UL
> -#define DOMAIN2__SET_AS_TARGET                    0x00000010UL
> -#define DOMAIN2__SET_CPUID                        0x00000020UL
> -#define DOMAIN2__GETTSC                           0x00000040UL
> -#define DOMAIN2__SETTSC                           0x00000080UL
> -
> -#define HVM__SETHVMC                              0x00000001UL
> -#define HVM__GETHVMC                              0x00000002UL
> -#define HVM__SETPARAM                             0x00000004UL
> -#define HVM__GETPARAM                             0x00000008UL
> -#define HVM__PCILEVEL                             0x00000010UL
> -#define HVM__IRQLEVEL                             0x00000020UL
> -#define HVM__PCIROUTE                             0x00000040UL
> -#define HVM__BIND_IRQ                             0x00000080UL
> -#define HVM__CACHEATTR                            0x00000100UL
> -#define HVM__TRACKDIRTYVRAM                       0x00000200UL
> -#define HVM__HVMCTL                               0x00000400UL
> -#define HVM__MEM_EVENT                            0x00000800UL
> -#define HVM__MEM_SHARING                          0x00001000UL
> -#define HVM__AUDIT_P2M                            0x00002000UL
> -#define HVM__SEND_IRQ                             0x00004000UL
> -#define HVM__SHARE_MEM                            0x00008000UL
> -
> -#define EVENT__BIND                               0x00000001UL
> -#define EVENT__SEND                               0x00000002UL
> -#define EVENT__STATUS                             0x00000004UL
> -#define EVENT__NOTIFY                             0x00000008UL
> -#define EVENT__CREATE                             0x00000010UL
> -#define EVENT__RESET                              0x00000020UL
> -
> -#define GRANT__MAP_READ                           0x00000001UL
> -#define GRANT__MAP_WRITE                          0x00000002UL
> -#define GRANT__UNMAP                              0x00000004UL
> -#define GRANT__TRANSFER                           0x00000008UL
> -#define GRANT__SETUP                              0x00000010UL
> -#define GRANT__COPY                               0x00000020UL
> -#define GRANT__QUERY                              0x00000040UL
> -
> -#define MMU__MAP_READ                             0x00000001UL
> -#define MMU__MAP_WRITE                            0x00000002UL
> -#define MMU__PAGEINFO                             0x00000004UL
> -#define MMU__PAGELIST                             0x00000008UL
> -#define MMU__ADJUST                               0x00000010UL
> -#define MMU__STAT                                 0x00000020UL
> -#define MMU__TRANSLATEGP                          0x00000040UL
> -#define MMU__UPDATEMP                             0x00000080UL
> -#define MMU__PHYSMAP                              0x00000100UL
> -#define MMU__PINPAGE                              0x00000200UL
> -#define MMU__MFNLIST                              0x00000400UL
> -#define MMU__MEMORYMAP                            0x00000800UL
> -#define MMU__REMOTE_REMAP                         0x00001000UL
> -#define MMU__MMUEXT_OP                            0x00002000UL
> -#define MMU__EXCHANGE                             0x00004000UL
> -
> -#define SHADOW__DISABLE                           0x00000001UL
> -#define SHADOW__ENABLE                            0x00000002UL
> -#define SHADOW__LOGDIRTY                          0x00000004UL
> -
> -#define RESOURCE__ADD                             0x00000001UL
> -#define RESOURCE__REMOVE                          0x00000002UL
> -#define RESOURCE__USE                             0x00000004UL
> -#define RESOURCE__ADD_IRQ                         0x00000008UL
> -#define RESOURCE__REMOVE_IRQ                      0x00000010UL
> -#define RESOURCE__ADD_IOPORT                      0x00000020UL
> -#define RESOURCE__REMOVE_IOPORT                   0x00000040UL
> -#define RESOURCE__ADD_IOMEM                       0x00000080UL
> -#define RESOURCE__REMOVE_IOMEM                    0x00000100UL
> -#define RESOURCE__STAT_DEVICE                     0x00000200UL
> -#define RESOURCE__ADD_DEVICE                      0x00000400UL
> -#define RESOURCE__REMOVE_DEVICE                   0x00000800UL
> -#define RESOURCE__PLUG                            0x00001000UL
> -#define RESOURCE__UNPLUG                          0x00002000UL
> -#define RESOURCE__SETUP                           0x00004000UL
> -
> -#define SECURITY__COMPUTE_AV                      0x00000001UL
> -#define SECURITY__COMPUTE_CREATE                  0x00000002UL
> -#define SECURITY__COMPUTE_MEMBER                  0x00000004UL
> -#define SECURITY__CHECK_CONTEXT                   0x00000008UL
> -#define SECURITY__LOAD_POLICY                     0x00000010UL
> -#define SECURITY__COMPUTE_RELABEL                 0x00000020UL
> -#define SECURITY__COMPUTE_USER                    0x00000040UL
> -#define SECURITY__SETENFORCE                      0x00000080UL
> -#define SECURITY__SETBOOL                         0x00000100UL
> -#define SECURITY__SETSECPARAM                     0x00000200UL
> -#define SECURITY__ADD_OCONTEXT                    0x00000400UL
> -#define SECURITY__DEL_OCONTEXT                    0x00000800UL
> -
> diff --git a/xen/xsm/flask/include/class_to_string.h b/xen/xsm/flask/include/class_to_string.h
> deleted file mode 100644
> index 7716645..0000000
> --- a/xen/xsm/flask/include/class_to_string.h
> +++ /dev/null
> @@ -1,15 +0,0 @@
> -/* This file is automatically generated.  Do not edit. */
> -/*
> - * Security object class definitions
> - */
> -    S_("null")
> -    S_("xen")
> -    S_("domain")
> -    S_("domain2")
> -    S_("hvm")
> -    S_("mmu")
> -    S_("resource")
> -    S_("shadow")
> -    S_("event")
> -    S_("grant")
> -    S_("security")
> diff --git a/xen/xsm/flask/include/flask.h b/xen/xsm/flask/include/flask.h
> deleted file mode 100644
> index 3bff998..0000000
> --- a/xen/xsm/flask/include/flask.h
> +++ /dev/null
> @@ -1,35 +0,0 @@
> -/* This file is automatically generated.  Do not edit. */
> -#ifndef _SELINUX_FLASK_H_
> -#define _SELINUX_FLASK_H_
> -
> -/*
> - * Security object class definitions
> - */
> -#define SECCLASS_XEN                                     1
> -#define SECCLASS_DOMAIN                                  2
> -#define SECCLASS_DOMAIN2                                 3
> -#define SECCLASS_HVM                                     4
> -#define SECCLASS_MMU                                     5
> -#define SECCLASS_RESOURCE                                6
> -#define SECCLASS_SHADOW                                  7
> -#define SECCLASS_EVENT                                   8
> -#define SECCLASS_GRANT                                   9
> -#define SECCLASS_SECURITY                                10
> -
> -/*
> - * Security identifier indices for initial entities
> - */
> -#define SECINITSID_XEN                                  1
> -#define SECINITSID_DOM0                                 2
> -#define SECINITSID_DOMIO                                3
> -#define SECINITSID_DOMXEN                               4
> -#define SECINITSID_UNLABELED                            5
> -#define SECINITSID_SECURITY                             6
> -#define SECINITSID_IOPORT                               7
> -#define SECINITSID_IOMEM                                8
> -#define SECINITSID_IRQ                                  9
> -#define SECINITSID_DEVICE                               10
> -
> -#define SECINITSID_NUM                                  10
> -
> -#endif
> diff --git a/xen/xsm/flask/include/initial_sid_to_string.h b/xen/xsm/flask/include/initial_sid_to_string.h
> deleted file mode 100644
> index 814f4bf..0000000
> --- a/xen/xsm/flask/include/initial_sid_to_string.h
> +++ /dev/null
> @@ -1,16 +0,0 @@
> -/* This file is automatically generated.  Do not edit. */
> -static char *initial_sid_to_string[] =
> -{
> -    "null",
> -    "xen",
> -    "dom0",
> -    "domio",
> -    "domxen",
> -    "unlabeled",
> -    "security",
> -    "ioport",
> -    "iomem",
> -    "irq",
> -    "device",
> -};
> -
> diff --git a/tools/flask/policy/policy/flask/access_vectors b/xen/xsm/flask/policy/access_vectors
> similarity index 100%
> rename from tools/flask/policy/policy/flask/access_vectors
> rename to xen/xsm/flask/policy/access_vectors
> diff --git a/tools/flask/policy/policy/flask/initial_sids b/xen/xsm/flask/policy/initial_sids
> similarity index 100%
> rename from tools/flask/policy/policy/flask/initial_sids
> rename to xen/xsm/flask/policy/initial_sids
> diff --git a/tools/flask/policy/policy/flask/mkaccess_vector.sh b/xen/xsm/flask/policy/mkaccess_vector.sh
> similarity index 97%
> rename from tools/flask/policy/policy/flask/mkaccess_vector.sh
> rename to xen/xsm/flask/policy/mkaccess_vector.sh
> index 43a60a7..8ec87f7 100644
> --- a/tools/flask/policy/policy/flask/mkaccess_vector.sh
> +++ b/xen/xsm/flask/policy/mkaccess_vector.sh
> @@ -9,8 +9,8 @@ awk=$1
>  shift
> 
>  # output files
> -av_permissions="av_permissions.h"
> -av_perm_to_string="av_perm_to_string.h"
> +av_permissions="include/av_permissions.h"
> +av_perm_to_string="include/av_perm_to_string.h"
> 
>  cat $* | $awk "
>  BEGIN  {
> diff --git a/tools/flask/policy/policy/flask/mkflask.sh b/xen/xsm/flask/policy/mkflask.sh
> similarity index 95%
> rename from tools/flask/policy/policy/flask/mkflask.sh
> rename to xen/xsm/flask/policy/mkflask.sh
> index 9c84754..e8d8fb5 100644
> --- a/tools/flask/policy/policy/flask/mkflask.sh
> +++ b/xen/xsm/flask/policy/mkflask.sh
> @@ -9,9 +9,9 @@ awk=$1
>  shift 1
> 
>  # output file
> -output_file="flask.h"
> -debug_file="class_to_string.h"
> -debug_file2="initial_sid_to_string.h"
> +output_file="include/flask.h"
> +debug_file="include/class_to_string.h"
> +debug_file2="include/initial_sid_to_string.h"
> 
>  cat $* | $awk "
>  BEGIN  {
> diff --git a/tools/flask/policy/policy/flask/security_classes b/xen/xsm/flask/policy/security_classes
> similarity index 100%
> rename from tools/flask/policy/policy/flask/security_classes
> rename to xen/xsm/flask/policy/security_classes
> --
> 1.7.11.4
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 08:39:47 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 08:39:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLroh-0001HU-Sk; Wed, 10 Oct 2012 08:38:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLrof-0001HP-Iy
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 08:38:58 +0000
Received: from [85.158.143.99:21401] by server-3.bemta-4.messagelabs.com id
	76/ED-10075-02435705; Wed, 10 Oct 2012 08:38:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1349858336!23766205!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM1ODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10895 invoked from network); 10 Oct 2012 08:38:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 08:38:56 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="15064526"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 08:38:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 10 Oct 2012 09:38:37 +0100
Message-ID: <1349858315.10070.7.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Daniel De Graaf 
Date: Wed, 10 Oct 2012 09:38:35 +0100
In-Reply-To: <1349807513-10923-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1349801565.21847.228.camel@zakaz.uk.xensource.com>
	<1349807513-10923-1-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Marcus Granado ,
	"andre.przywara@amd.com" ,
	"msw@amazon.com" , "anil@recoil.org" ,
	George Dunlap ,
	Andrew Cooper ,
	Dario Faggioli ,
	Ian Jackson ,
	"xen-devel@lists.xen.org" ,
	"JBeulich@suse.com" ,
	"juergen.gross@ts.fujitsu.com" 
Subject: Re: [Xen-devel] [PATCH RFC] flask: move policy header sources into
	hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-09 at 19:31 +0100, Daniel De Graaf wrote:
> Ian Campbell wrote:
> [...]
> >>> +++ b/xen/xsm/flask/include/av_perm_to_string.h
> > Also, in that case why is this file checked in?
> 
> This patch fixes the autogenerated files, but doesn't fully wire them in
> to things like "make clean" or .{git,hg}ignore. I don't see an obvious
> way to clean generated header files in Xen's build system; perhaps
> someone who knows the build system better can point out the right way to
> wire this up.

xen/arch/x86/Makefile has a clean:: rule which removes autogenerated
stuff like the asm-offsets files. Probably the right model to follow.

Ian.

> 
> --------------------------------------->8----------------------------
> 
> Rather than keeping around headers that are autogenerated in order to
> avoid adding build dependencies from xen/ to files in tools/, move the
> relevant parts of the FLASK policy into the hypervisor tree and generate
> the headers as part of the hypervisor's build.
> 
> Signed-off-by: Daniel De Graaf 
> ---
>  tools/flask/policy/Makefile                        |   2 +-
>  tools/flask/policy/policy/flask/Makefile           |  41 ------
>  xen/xsm/flask/Makefile                             |  21 +++
>  xen/xsm/flask/include/av_perm_to_string.h          | 147 -------------------
>  xen/xsm/flask/include/av_permissions.h             | 157 ---------------------
>  xen/xsm/flask/include/class_to_string.h            |  15 --
>  xen/xsm/flask/include/flask.h                      |  35 -----
>  xen/xsm/flask/include/initial_sid_to_string.h      |  16 ---
>  .../flask => xen/xsm/flask/policy}/access_vectors  |   0
>  .../flask => xen/xsm/flask/policy}/initial_sids    |   0
>  .../xsm/flask/policy}/mkaccess_vector.sh           |   4 +-
>  .../flask => xen/xsm/flask/policy}/mkflask.sh      |   6 +-
>  .../xsm/flask/policy}/security_classes             |   0
>  13 files changed, 27 insertions(+), 417 deletions(-)
>  delete mode 100644 tools/flask/policy/policy/flask/Makefile
>  delete mode 100644 xen/xsm/flask/include/av_perm_to_string.h
>  delete mode 100644 xen/xsm/flask/include/av_permissions.h
>  delete mode 100644 xen/xsm/flask/include/class_to_string.h
>  delete mode 100644 xen/xsm/flask/include/flask.h
>  delete mode 100644 xen/xsm/flask/include/initial_sid_to_string.h
>  rename {tools/flask/policy/policy/flask => xen/xsm/flask/policy}/access_vectors (100%)
>  rename {tools/flask/policy/policy/flask => xen/xsm/flask/policy}/initial_sids (100%)
>  rename {tools/flask/policy/policy/flask => xen/xsm/flask/policy}/mkaccess_vector.sh (97%)
>  rename {tools/flask/policy/policy/flask => xen/xsm/flask/policy}/mkflask.sh (95%)
>  rename {tools/flask/policy/policy/flask => xen/xsm/flask/policy}/security_classes (100%)
> 
> diff --git a/tools/flask/policy/Makefile b/tools/flask/policy/Makefile
> index 5c25cbe..3f5aa38 100644
> --- a/tools/flask/policy/Makefile
> +++ b/tools/flask/policy/Makefile
> @@ -61,7 +61,7 @@ LOADPOLICY := $(SBINDIR)/flask-loadpolicy
>  # policy source layout
>  POLDIR := policy
>  MODDIR := $(POLDIR)/modules
> -FLASKDIR := $(POLDIR)/flask
> +FLASKDIR := ../../../xen/xsm/flask/policy
>  SECCLASS := $(FLASKDIR)/security_classes
>  ISIDS := $(FLASKDIR)/initial_sids
>  AVS := $(FLASKDIR)/access_vectors
> diff --git a/tools/flask/policy/policy/flask/Makefile b/tools/flask/policy/policy/flask/Makefile
> deleted file mode 100644
> index 5f57e88..0000000
> --- a/tools/flask/policy/policy/flask/Makefile
> +++ /dev/null
> @@ -1,41 +0,0 @@
> -# flask needs to know where to export the libselinux headers.
> -LIBSEL ?= ../../libselinux
> -
> -# flask needs to know where to export the kernel headers.
> -LINUXDIR ?= ../../../linux-2.6
> -
> -AWK = awk
> -
> -CONFIG_SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; \
> -          else if [ -x /bin/bash ]; then echo /bin/bash; \
> -          else echo sh; fi ; fi)
> -
> -FLASK_H_DEPEND = security_classes initial_sids
> -AV_H_DEPEND = access_vectors
> -
> -FLASK_H_FILES = class_to_string.h flask.h initial_sid_to_string.h
> -AV_H_FILES = av_perm_to_string.h av_permissions.h
> -ALL_H_FILES = $(FLASK_H_FILES) $(AV_H_FILES)
> -
> -all:  $(ALL_H_FILES)
> -
> -$(FLASK_H_FILES): $(FLASK_H_DEPEND)
> -       $(CONFIG_SHELL) mkflask.sh $(AWK) $(FLASK_H_DEPEND)
> -
> -$(AV_H_FILES): $(AV_H_DEPEND)
> -       $(CONFIG_SHELL) mkaccess_vector.sh $(AWK) $(AV_H_DEPEND)
> -
> -tolib: all
> -       install -m 644 flask.h av_permissions.h $(LIBSEL)/include/selinux
> -       install -m 644 class_to_string.h av_inherit.h common_perm_to_string.h av_perm_to_string.h $(LIBSEL)/src
> -
> -tokern: all
> -       install -m 644 $(ALL_H_FILES) $(LINUXDIR)/security/selinux/include
> -
> -install: all
> -
> -relabel:
> -
> -clean:
> -       rm -f $(FLASK_H_FILES)
> -       rm -f $(AV_H_FILES)
> diff --git a/xen/xsm/flask/Makefile b/xen/xsm/flask/Makefile
> index 92fb410..238495a 100644
> --- a/xen/xsm/flask/Makefile
> +++ b/xen/xsm/flask/Makefile
> @@ -5,3 +5,24 @@ obj-y += flask_op.o
>  subdir-y += ss
> 
>  CFLAGS += -I./include
> +
> +AWK = awk
> +
> +CONFIG_SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; \
> +          else if [ -x /bin/bash ]; then echo /bin/bash; \
> +          else echo sh; fi ; fi)
> +
> +FLASK_H_DEPEND = policy/security_classes policy/initial_sids
> +AV_H_DEPEND = policy/access_vectors
> +
> +FLASK_H_FILES = include/flask.h include/class_to_string.h include/initial_sid_to_string.h
> +AV_H_FILES = include/av_perm_to_string.h include/av_permissions.h
> +ALL_H_FILES = $(FLASK_H_FILES) $(AV_H_FILES)
> +
> +$(obj-y) ss/built_in.o: $(ALL_H_FILES)
> +
> +$(FLASK_H_FILES): $(FLASK_H_DEPEND)
> +       $(CONFIG_SHELL) policy/mkflask.sh $(AWK) $(FLASK_H_DEPEND)
> +
> +$(AV_H_FILES): $(AV_H_DEPEND)
> +       $(CONFIG_SHELL) policy/mkaccess_vector.sh $(AWK) $(AV_H_DEPEND)
> diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
> deleted file mode 100644
> index c3f2370..0000000
> --- a/xen/xsm/flask/include/av_perm_to_string.h
> +++ /dev/null
> @@ -1,147 +0,0 @@
> -/* This file is automatically generated.  Do not edit. */
> -   S_(SECCLASS_XEN, XEN__SCHEDULER, "scheduler")
> -   S_(SECCLASS_XEN, XEN__SETTIME, "settime")
> -   S_(SECCLASS_XEN, XEN__TBUFCONTROL, "tbufcontrol")
> -   S_(SECCLASS_XEN, XEN__READCONSOLE, "readconsole")
> -   S_(SECCLASS_XEN, XEN__CLEARCONSOLE, "clearconsole")
> -   S_(SECCLASS_XEN, XEN__PERFCONTROL, "perfcontrol")
> -   S_(SECCLASS_XEN, XEN__MTRR_ADD, "mtrr_add")
> -   S_(SECCLASS_XEN, XEN__MTRR_DEL, "mtrr_del")
> -   S_(SECCLASS_XEN, XEN__MTRR_READ, "mtrr_read")
> -   S_(SECCLASS_XEN, XEN__MICROCODE, "microcode")
> -   S_(SECCLASS_XEN, XEN__PHYSINFO, "physinfo")
> -   S_(SECCLASS_XEN, XEN__QUIRK, "quirk")
> -   S_(SECCLASS_XEN, XEN__WRITECONSOLE, "writeconsole")
> -   S_(SECCLASS_XEN, XEN__READAPIC, "readapic")
> -   S_(SECCLASS_XEN, XEN__WRITEAPIC, "writeapic")
> -   S_(SECCLASS_XEN, XEN__PRIVPROFILE, "privprofile")
> -   S_(SECCLASS_XEN, XEN__NONPRIVPROFILE, "nonprivprofile")
> -   S_(SECCLASS_XEN, XEN__KEXEC, "kexec")
> -   S_(SECCLASS_XEN, XEN__FIRMWARE, "firmware")
> -   S_(SECCLASS_XEN, XEN__SLEEP, "sleep")
> -   S_(SECCLASS_XEN, XEN__FREQUENCY, "frequency")
> -   S_(SECCLASS_XEN, XEN__GETIDLE, "getidle")
> -   S_(SECCLASS_XEN, XEN__DEBUG, "debug")
> -   S_(SECCLASS_XEN, XEN__GETCPUINFO, "getcpuinfo")
> -   S_(SECCLASS_XEN, XEN__HEAP, "heap")
> -   S_(SECCLASS_XEN, XEN__PM_OP, "pm_op")
> -   S_(SECCLASS_XEN, XEN__MCA_OP, "mca_op")
> -   S_(SECCLASS_XEN, XEN__LOCKPROF, "lockprof")
> -   S_(SECCLASS_XEN, XEN__CPUPOOL_OP, "cpupool_op")
> -   S_(SECCLASS_XEN, XEN__SCHED_OP, "sched_op")
> -   S_(SECCLASS_XEN, XEN__TMEM_OP, "tmem_op")
> -   S_(SECCLASS_XEN, XEN__TMEM_CONTROL, "tmem_control")
> -   S_(SECCLASS_DOMAIN, DOMAIN__SETVCPUCONTEXT, "setvcpucontext")
> -   S_(SECCLASS_DOMAIN, DOMAIN__PAUSE, "pause")
> -   S_(SECCLASS_DOMAIN, DOMAIN__UNPAUSE, "unpause")
> -   S_(SECCLASS_DOMAIN, DOMAIN__RESUME, "resume")
> -   S_(SECCLASS_DOMAIN, DOMAIN__CREATE, "create")
> -   S_(SECCLASS_DOMAIN, DOMAIN__TRANSITION, "transition")
> -   S_(SECCLASS_DOMAIN, DOMAIN__MAX_VCPUS, "max_vcpus")
> -   S_(SECCLASS_DOMAIN, DOMAIN__DESTROY, "destroy")
> -   S_(SECCLASS_DOMAIN, DOMAIN__SETVCPUAFFINITY, "setvcpuaffinity")
> -   S_(SECCLASS_DOMAIN, DOMAIN__GETVCPUAFFINITY, "getvcpuaffinity")
> -   S_(SECCLASS_DOMAIN, DOMAIN__SCHEDULER, "scheduler")
> -   S_(SECCLASS_DOMAIN, DOMAIN__GETDOMAININFO, "getdomaininfo")
> -   S_(SECCLASS_DOMAIN, DOMAIN__GETVCPUINFO, "getvcpuinfo")
> -   S_(SECCLASS_DOMAIN, DOMAIN__GETVCPUCONTEXT, "getvcpucontext")
> -   S_(SECCLASS_DOMAIN, DOMAIN__SETDOMAINMAXMEM, "setdomainmaxmem")
> -   S_(SECCLASS_DOMAIN, DOMAIN__SETDOMAINHANDLE, "setdomainhandle")
> -   S_(SECCLASS_DOMAIN, DOMAIN__SETDEBUGGING, "setdebugging")
> -   S_(SECCLASS_DOMAIN, DOMAIN__HYPERCALL, "hypercall")
> -   S_(SECCLASS_DOMAIN, DOMAIN__SETTIME, "settime")
> -   S_(SECCLASS_DOMAIN, DOMAIN__SET_TARGET, "set_target")
> -   S_(SECCLASS_DOMAIN, DOMAIN__SHUTDOWN, "shutdown")
> -   S_(SECCLASS_DOMAIN, DOMAIN__SETADDRSIZE, "setaddrsize")
> -   S_(SECCLASS_DOMAIN, DOMAIN__GETADDRSIZE, "getaddrsize")
> -   S_(SECCLASS_DOMAIN, DOMAIN__TRIGGER, "trigger")
> -   S_(SECCLASS_DOMAIN, DOMAIN__GETEXTVCPUCONTEXT, "getextvcpucontext")
> -   S_(SECCLASS_DOMAIN, DOMAIN__SETEXTVCPUCONTEXT, "setextvcpucontext")
> -   S_(SECCLASS_DOMAIN, DOMAIN__GETVCPUEXTSTATE, "getvcpuextstate")
> -   S_(SECCLASS_DOMAIN, DOMAIN__SETVCPUEXTSTATE, "setvcpuextstate")
> -   S_(SECCLASS_DOMAIN, DOMAIN__GETPODTARGET, "getpodtarget")
> -   S_(SECCLASS_DOMAIN, DOMAIN__SETPODTARGET, "setpodtarget")
> -   S_(SECCLASS_DOMAIN, DOMAIN__SET_MISC_INFO, "set_misc_info")
> -   S_(SECCLASS_DOMAIN, DOMAIN__SET_VIRQ_HANDLER, "set_virq_handler")
> -   S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELFROM, "relabelfrom")
> -   S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELTO, "relabelto")
> -   S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELSELF, "relabelself")
> -   S_(SECCLASS_DOMAIN2, DOMAIN2__MAKE_PRIV_FOR, "make_priv_for")
> -   S_(SECCLASS_DOMAIN2, DOMAIN2__SET_AS_TARGET, "set_as_target")
> -   S_(SECCLASS_DOMAIN2, DOMAIN2__SET_CPUID, "set_cpuid")
> -   S_(SECCLASS_DOMAIN2, DOMAIN2__GETTSC, "gettsc")
> -   S_(SECCLASS_DOMAIN2, DOMAIN2__SETTSC, "settsc")
> -   S_(SECCLASS_HVM, HVM__SETHVMC, "sethvmc")
> -   S_(SECCLASS_HVM, HVM__GETHVMC, "gethvmc")
> -   S_(SECCLASS_HVM, HVM__SETPARAM, "setparam")
> -   S_(SECCLASS_HVM, HVM__GETPARAM, "getparam")
> -   S_(SECCLASS_HVM, HVM__PCILEVEL, "pcilevel")
> -   S_(SECCLASS_HVM, HVM__IRQLEVEL, "irqlevel")
> -   S_(SECCLASS_HVM, HVM__PCIROUTE, "pciroute")
> -   S_(SECCLASS_HVM, HVM__BIND_IRQ, "bind_irq")
> -   S_(SECCLASS_HVM, HVM__CACHEATTR, "cacheattr")
> -   S_(SECCLASS_HVM, HVM__TRACKDIRTYVRAM, "trackdirtyvram")
> -   S_(SECCLASS_HVM, HVM__HVMCTL, "hvmctl")
> -   S_(SECCLASS_HVM, HVM__MEM_EVENT, "mem_event")
> -   S_(SECCLASS_HVM, HVM__MEM_SHARING, "mem_sharing")
> -   S_(SECCLASS_HVM, HVM__AUDIT_P2M, "audit_p2m")
> -   S_(SECCLASS_HVM, HVM__SEND_IRQ, "send_irq")
> -   S_(SECCLASS_HVM, HVM__SHARE_MEM, "share_mem")
> -   S_(SECCLASS_EVENT, EVENT__BIND, "bind")
> -   S_(SECCLASS_EVENT, EVENT__SEND, "send")
> -   S_(SECCLASS_EVENT, EVENT__STATUS, "status")
> -   S_(SECCLASS_EVENT, EVENT__NOTIFY, "notify")
> -   S_(SECCLASS_EVENT, EVENT__CREATE, "create")
> -   S_(SECCLASS_EVENT, EVENT__RESET, "reset")
> -   S_(SECCLASS_GRANT, GRANT__MAP_READ, "map_read")
> -   S_(SECCLASS_GRANT, GRANT__MAP_WRITE, "map_write")
> -   S_(SECCLASS_GRANT, GRANT__UNMAP, "unmap")
> -   S_(SECCLASS_GRANT, GRANT__TRANSFER, "transfer")
> -   S_(SECCLASS_GRANT, GRANT__SETUP, "setup")
> -   S_(SECCLASS_GRANT, GRANT__COPY, "copy")
> -   S_(SECCLASS_GRANT, GRANT__QUERY, "query")
> -   S_(SECCLASS_MMU, MMU__MAP_READ, "map_read")
> -   S_(SECCLASS_MMU, MMU__MAP_WRITE, "map_write")
> -   S_(SECCLASS_MMU, MMU__PAGEINFO, "pageinfo")
> -   S_(SECCLASS_MMU, MMU__PAGELIST, "pagelist")
> -   S_(SECCLASS_MMU, MMU__ADJUST, "adjust")
> -   S_(SECCLASS_MMU, MMU__STAT, "stat")
> -   S_(SECCLASS_MMU, MMU__TRANSLATEGP, "translategp")
> -   S_(SECCLASS_MMU, MMU__UPDATEMP, "updatemp")
> -   S_(SECCLASS_MMU, MMU__PHYSMAP, "physmap")
> -   S_(SECCLASS_MMU, MMU__PINPAGE, "pinpage")
> -   S_(SECCLASS_MMU, MMU__MFNLIST, "mfnlist")
> -   S_(SECCLASS_MMU, MMU__MEMORYMAP, "memorymap")
> -   S_(SECCLASS_MMU, MMU__REMOTE_REMAP, "remote_remap")
> -   S_(SECCLASS_MMU, MMU__MMUEXT_OP, "mmuext_op")
> -   S_(SECCLASS_MMU, MMU__EXCHANGE, "exchange")
> -   S_(SECCLASS_SHADOW, SHADOW__DISABLE, "disable")
> -   S_(SECCLASS_SHADOW, SHADOW__ENABLE, "enable")
> -   S_(SECCLASS_SHADOW, SHADOW__LOGDIRTY, "logdirty")
> -   S_(SECCLASS_RESOURCE, RESOURCE__ADD, "add")
> -   S_(SECCLASS_RESOURCE, RESOURCE__REMOVE, "remove")
> -   S_(SECCLASS_RESOURCE, RESOURCE__USE, "use")
> -   S_(SECCLASS_RESOURCE, RESOURCE__ADD_IRQ, "add_irq")
> -   S_(SECCLASS_RESOURCE, RESOURCE__REMOVE_IRQ, "remove_irq")
> -   S_(SECCLASS_RESOURCE, RESOURCE__ADD_IOPORT, "add_ioport")
> -   S_(SECCLASS_RESOURCE, RESOURCE__REMOVE_IOPORT, "remove_ioport")
> -   S_(SECCLASS_RESOURCE, RESOURCE__ADD_IOMEM, "add_iomem")
> -   S_(SECCLASS_RESOURCE, RESOURCE__REMOVE_IOMEM, "remove_iomem")
> -   S_(SECCLASS_RESOURCE, RESOURCE__STAT_DEVICE, "stat_device")
> -   S_(SECCLASS_RESOURCE, RESOURCE__ADD_DEVICE, "add_device")
> -   S_(SECCLASS_RESOURCE, RESOURCE__REMOVE_DEVICE, "remove_device")
> -   S_(SECCLASS_RESOURCE, RESOURCE__PLUG, "plug")
> -   S_(SECCLASS_RESOURCE, RESOURCE__UNPLUG, "unplug")
> -   S_(SECCLASS_RESOURCE, RESOURCE__SETUP, "setup")
> -   S_(SECCLASS_SECURITY, SECURITY__COMPUTE_AV, "compute_av")
> -   S_(SECCLASS_SECURITY, SECURITY__COMPUTE_CREATE, "compute_create")
> -   S_(SECCLASS_SECURITY, SECURITY__COMPUTE_MEMBER, "compute_member")
> -   S_(SECCLASS_SECURITY, SECURITY__CHECK_CONTEXT, "check_context")
> -   S_(SECCLASS_SECURITY, SECURITY__LOAD_POLICY, "load_policy")
> -   S_(SECCLASS_SECURITY, SECURITY__COMPUTE_RELABEL, "compute_relabel")
> -   S_(SECCLASS_SECURITY, SECURITY__COMPUTE_USER, "compute_user")
> -   S_(SECCLASS_SECURITY, SECURITY__SETENFORCE, "setenforce")
> -   S_(SECCLASS_SECURITY, SECURITY__SETBOOL, "setbool")
> -   S_(SECCLASS_SECURITY, SECURITY__SETSECPARAM, "setsecparam")
> -   S_(SECCLASS_SECURITY, SECURITY__ADD_OCONTEXT, "add_ocontext")
> -   S_(SECCLASS_SECURITY, SECURITY__DEL_OCONTEXT, "del_ocontext")
> diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
> deleted file mode 100644
> index 65302e8..0000000
> --- a/xen/xsm/flask/include/av_permissions.h
> +++ /dev/null
> @@ -1,157 +0,0 @@
> -/* This file is automatically generated.  Do not edit. */
> -#define XEN__SCHEDULER                            0x00000001UL
> -#define XEN__SETTIME                              0x00000002UL
> -#define XEN__TBUFCONTROL                          0x00000004UL
> -#define XEN__READCONSOLE                          0x00000008UL
> -#define XEN__CLEARCONSOLE                         0x00000010UL
> -#define XEN__PERFCONTROL                          0x00000020UL
> -#define XEN__MTRR_ADD                             0x00000040UL
> -#define XEN__MTRR_DEL                             0x00000080UL
> -#define XEN__MTRR_READ                            0x00000100UL
> -#define XEN__MICROCODE                            0x00000200UL
> -#define XEN__PHYSINFO                             0x00000400UL
> -#define XEN__QUIRK                                0x00000800UL
> -#define XEN__WRITECONSOLE                         0x00001000UL
> -#define XEN__READAPIC                             0x00002000UL
> -#define XEN__WRITEAPIC                            0x00004000UL
> -#define XEN__PRIVPROFILE                          0x00008000UL
> -#define XEN__NONPRIVPROFILE                       0x00010000UL
> -#define XEN__KEXEC                                0x00020000UL
> -#define XEN__FIRMWARE                             0x00040000UL
> -#define XEN__SLEEP                                0x00080000UL
> -#define XEN__FREQUENCY                            0x00100000UL
> -#define XEN__GETIDLE                              0x00200000UL
> -#define XEN__DEBUG                                0x00400000UL
> -#define XEN__GETCPUINFO                           0x00800000UL
> -#define XEN__HEAP                                 0x01000000UL
> -#define XEN__PM_OP                                0x02000000UL
> -#define XEN__MCA_OP                               0x04000000UL
> -#define XEN__LOCKPROF                             0x08000000UL
> -#define XEN__CPUPOOL_OP                           0x10000000UL
> -#define XEN__SCHED_OP                             0x20000000UL
> -#define XEN__TMEM_OP                              0x40000000UL
> -#define XEN__TMEM_CONTROL                         0x80000000UL
> -
> -#define DOMAIN__SETVCPUCONTEXT                    0x00000001UL
> -#define DOMAIN__PAUSE                             0x00000002UL
> -#define DOMAIN__UNPAUSE                           0x00000004UL
> -#define DOMAIN__RESUME                            0x00000008UL
> -#define DOMAIN__CREATE                            0x00000010UL
> -#define DOMAIN__TRANSITION                        0x00000020UL
> -#define DOMAIN__MAX_VCPUS                         0x00000040UL
> -#define DOMAIN__DESTROY                           0x00000080UL
> -#define DOMAIN__SETVCPUAFFINITY                   0x00000100UL
> -#define DOMAIN__GETVCPUAFFINITY                   0x00000200UL
> -#define DOMAIN__SCHEDULER                         0x00000400UL
> -#define DOMAIN__GETDOMAININFO                     0x00000800UL
> -#define DOMAIN__GETVCPUINFO                       0x00001000UL
> -#define DOMAIN__GETVCPUCONTEXT                    0x00002000UL
> -#define DOMAIN__SETDOMAINMAXMEM                   0x00004000UL
> -#define DOMAIN__SETDOMAINHANDLE                   0x00008000UL
> -#define DOMAIN__SETDEBUGGING                      0x00010000UL
> -#define DOMAIN__HYPERCALL                         0x00020000UL
> -#define DOMAIN__SETTIME                           0x00040000UL
> -#define DOMAIN__SET_TARGET                        0x00080000UL
> -#define DOMAIN__SHUTDOWN                          0x00100000UL
> -#define DOMAIN__SETADDRSIZE                       0x00200000UL
> -#define DOMAIN__GETADDRSIZE                       0x00400000UL
> -#define DOMAIN__TRIGGER                           0x00800000UL
> -#define DOMAIN__GETEXTVCPUCONTEXT                 0x01000000UL
> -#define DOMAIN__SETEXTVCPUCONTEXT                 0x02000000UL
> -#define DOMAIN__GETVCPUEXTSTATE                   0x04000000UL
> -#define DOMAIN__SETVCPUEXTSTATE                   0x08000000UL
> -#define DOMAIN__GETPODTARGET                      0x10000000UL
> -#define DOMAIN__SETPODTARGET                      0x20000000UL
> -#define DOMAIN__SET_MISC_INFO                     0x40000000UL
> -#define DOMAIN__SET_VIRQ_HANDLER                  0x80000000UL
> -
> -#define DOMAIN2__RELABELFROM                      0x00000001UL
> -#define DOMAIN2__RELABELTO                        0x00000002UL
> -#define DOMAIN2__RELABELSELF                      0x00000004UL
> -#define DOMAIN2__MAKE_PRIV_FOR                    0x00000008UL
> -#define DOMAIN2__SET_AS_TARGET                    0x00000010UL
> -#define DOMAIN2__SET_CPUID                        0x00000020UL
> -#define DOMAIN2__GETTSC                           0x00000040UL
> -#define DOMAIN2__SETTSC                           0x00000080UL
> -
> -#define HVM__SETHVMC                              0x00000001UL
> -#define HVM__GETHVMC                              0x00000002UL
> -#define HVM__SETPARAM                             0x00000004UL
> -#define HVM__GETPARAM                             0x00000008UL
> -#define HVM__PCILEVEL                             0x00000010UL
> -#define HVM__IRQLEVEL                             0x00000020UL
> -#define HVM__PCIROUTE                             0x00000040UL
> -#define HVM__BIND_IRQ                             0x00000080UL
> -#define HVM__CACHEATTR                            0x00000100UL
> -#define HVM__TRACKDIRTYVRAM                       0x00000200UL
> -#define HVM__HVMCTL                               0x00000400UL
> -#define HVM__MEM_EVENT                            0x00000800UL
> -#define HVM__MEM_SHARING                          0x00001000UL
> -#define HVM__AUDIT_P2M                            0x00002000UL
> -#define HVM__SEND_IRQ                             0x00004000UL
> -#define HVM__SHARE_MEM                            0x00008000UL
> -
> -#define EVENT__BIND                               0x00000001UL
> -#define EVENT__SEND                               0x00000002UL
> -#define EVENT__STATUS                             0x00000004UL
> -#define EVENT__NOTIFY                             0x00000008UL
> -#define EVENT__CREATE                             0x00000010UL
> -#define EVENT__RESET                              0x00000020UL
> -
> -#define GRANT__MAP_READ                           0x00000001UL
> -#define GRANT__MAP_WRITE                          0x00000002UL
> -#define GRANT__UNMAP                              0x00000004UL
> -#define GRANT__TRANSFER                           0x00000008UL
> -#define GRANT__SETUP                              0x00000010UL
> -#define GRANT__COPY                               0x00000020UL
> -#define GRANT__QUERY                              0x00000040UL
> -
> -#define MMU__MAP_READ                             0x00000001UL
> -#define MMU__MAP_WRITE                            0x00000002UL
> -#define MMU__PAGEINFO                             0x00000004UL
> -#define MMU__PAGELIST                             0x00000008UL
> -#define MMU__ADJUST                               0x00000010UL
> -#define MMU__STAT                                 0x00000020UL
> -#define MMU__TRANSLATEGP                          0x00000040UL
> -#define MMU__UPDATEMP                             0x00000080UL
> -#define MMU__PHYSMAP                              0x00000100UL
> -#define MMU__PINPAGE                              0x00000200UL
> -#define MMU__MFNLIST                              0x00000400UL
> -#define MMU__MEMORYMAP                            0x00000800UL
> -#define MMU__REMOTE_REMAP                         0x00001000UL
> -#define MMU__MMUEXT_OP                            0x00002000UL
> -#define MMU__EXCHANGE                             0x00004000UL
> -
> -#define SHADOW__DISABLE                           0x00000001UL
> -#define SHADOW__ENABLE                            0x00000002UL
> -#define SHADOW__LOGDIRTY                          0x00000004UL
> -
> -#define RESOURCE__ADD                             0x00000001UL
> -#define RESOURCE__REMOVE                          0x00000002UL
> -#define RESOURCE__USE                             0x00000004UL
> -#define RESOURCE__ADD_IRQ                         0x00000008UL
> -#define RESOURCE__REMOVE_IRQ                      0x00000010UL
> -#define RESOURCE__ADD_IOPORT                      0x00000020UL
> -#define RESOURCE__REMOVE_IOPORT                   0x00000040UL
> -#define RESOURCE__ADD_IOMEM                       0x00000080UL
> -#define RESOURCE__REMOVE_IOMEM                    0x00000100UL
> -#define RESOURCE__STAT_DEVICE                     0x00000200UL
> -#define RESOURCE__ADD_DEVICE                      0x00000400UL
> -#define RESOURCE__REMOVE_DEVICE                   0x00000800UL
> -#define RESOURCE__PLUG                            0x00001000UL
> -#define RESOURCE__UNPLUG                          0x00002000UL
> -#define RESOURCE__SETUP                           0x00004000UL
> -
> -#define SECURITY__COMPUTE_AV                      0x00000001UL
> -#define SECURITY__COMPUTE_CREATE                  0x00000002UL
> -#define SECURITY__COMPUTE_MEMBER                  0x00000004UL
> -#define SECURITY__CHECK_CONTEXT                   0x00000008UL
> -#define SECURITY__LOAD_POLICY                     0x00000010UL
> -#define SECURITY__COMPUTE_RELABEL                 0x00000020UL
> -#define SECURITY__COMPUTE_USER                    0x00000040UL
> -#define SECURITY__SETENFORCE                      0x00000080UL
> -#define SECURITY__SETBOOL                         0x00000100UL
> -#define SECURITY__SETSECPARAM                     0x00000200UL
> -#define SECURITY__ADD_OCONTEXT                    0x00000400UL
> -#define SECURITY__DEL_OCONTEXT                    0x00000800UL
> -
> diff --git a/xen/xsm/flask/include/class_to_string.h b/xen/xsm/flask/include/class_to_string.h
> deleted file mode 100644
> index 7716645..0000000
> --- a/xen/xsm/flask/include/class_to_string.h
> +++ /dev/null
> @@ -1,15 +0,0 @@
> -/* This file is automatically generated.  Do not edit. */
> -/*
> - * Security object class definitions
> - */
> -    S_("null")
> -    S_("xen")
> -    S_("domain")
> -    S_("domain2")
> -    S_("hvm")
> -    S_("mmu")
> -    S_("resource")
> -    S_("shadow")
> -    S_("event")
> -    S_("grant")
> -    S_("security")
> diff --git a/xen/xsm/flask/include/flask.h b/xen/xsm/flask/include/flask.h
> deleted file mode 100644
> index 3bff998..0000000
> --- a/xen/xsm/flask/include/flask.h
> +++ /dev/null
> @@ -1,35 +0,0 @@
> -/* This file is automatically generated.  Do not edit. */
> -#ifndef _SELINUX_FLASK_H_
> -#define _SELINUX_FLASK_H_
> -
> -/*
> - * Security object class definitions
> - */
> -#define SECCLASS_XEN                                     1
> -#define SECCLASS_DOMAIN                                  2
> -#define SECCLASS_DOMAIN2                                 3
> -#define SECCLASS_HVM                                     4
> -#define SECCLASS_MMU                                     5
> -#define SECCLASS_RESOURCE                                6
> -#define SECCLASS_SHADOW                                  7
> -#define SECCLASS_EVENT                                   8
> -#define SECCLASS_GRANT                                   9
> -#define SECCLASS_SECURITY                                10
> -
> -/*
> - * Security identifier indices for initial entities
> - */
> -#define SECINITSID_XEN                                  1
> -#define SECINITSID_DOM0                                 2
> -#define SECINITSID_DOMIO                                3
> -#define SECINITSID_DOMXEN                               4
> -#define SECINITSID_UNLABELED                            5
> -#define SECINITSID_SECURITY                             6
> -#define SECINITSID_IOPORT                               7
> -#define SECINITSID_IOMEM                                8
> -#define SECINITSID_IRQ                                  9
> -#define SECINITSID_DEVICE                               10
> -
> -#define SECINITSID_NUM                                  10
> -
> -#endif
> diff --git a/xen/xsm/flask/include/initial_sid_to_string.h b/xen/xsm/flask/include/initial_sid_to_string.h
> deleted file mode 100644
> index 814f4bf..0000000
> --- a/xen/xsm/flask/include/initial_sid_to_string.h
> +++ /dev/null
> @@ -1,16 +0,0 @@
> -/* This file is automatically generated.  Do not edit. */
> -static char *initial_sid_to_string[] =
> -{
> -    "null",
> -    "xen",
> -    "dom0",
> -    "domio",
> -    "domxen",
> -    "unlabeled",
> -    "security",
> -    "ioport",
> -    "iomem",
> -    "irq",
> -    "device",
> -};
> -
> diff --git a/tools/flask/policy/policy/flask/access_vectors b/xen/xsm/flask/policy/access_vectors
> similarity index 100%
> rename from tools/flask/policy/policy/flask/access_vectors
> rename to xen/xsm/flask/policy/access_vectors
> diff --git a/tools/flask/policy/policy/flask/initial_sids b/xen/xsm/flask/policy/initial_sids
> similarity index 100%
> rename from tools/flask/policy/policy/flask/initial_sids
> rename to xen/xsm/flask/policy/initial_sids
> diff --git a/tools/flask/policy/policy/flask/mkaccess_vector.sh b/xen/xsm/flask/policy/mkaccess_vector.sh
> similarity index 97%
> rename from tools/flask/policy/policy/flask/mkaccess_vector.sh
> rename to xen/xsm/flask/policy/mkaccess_vector.sh
> index 43a60a7..8ec87f7 100644
> --- a/tools/flask/policy/policy/flask/mkaccess_vector.sh
> +++ b/xen/xsm/flask/policy/mkaccess_vector.sh
> @@ -9,8 +9,8 @@ awk=$1
>  shift
> 
>  # output files
> -av_permissions="av_permissions.h"
> -av_perm_to_string="av_perm_to_string.h"
> +av_permissions="include/av_permissions.h"
> +av_perm_to_string="include/av_perm_to_string.h"
> 
>  cat $* | $awk "
>  BEGIN  {
> diff --git a/tools/flask/policy/policy/flask/mkflask.sh b/xen/xsm/flask/policy/mkflask.sh
> similarity index 95%
> rename from tools/flask/policy/policy/flask/mkflask.sh
> rename to xen/xsm/flask/policy/mkflask.sh
> index 9c84754..e8d8fb5 100644
> --- a/tools/flask/policy/policy/flask/mkflask.sh
> +++ b/xen/xsm/flask/policy/mkflask.sh
> @@ -9,9 +9,9 @@ awk=$1
>  shift 1
> 
>  # output file
> -output_file="flask.h"
> -debug_file="class_to_string.h"
> -debug_file2="initial_sid_to_string.h"
> +output_file="include/flask.h"
> +debug_file="include/class_to_string.h"
> +debug_file2="include/initial_sid_to_string.h"
> 
>  cat $* | $awk "
>  BEGIN  {
> diff --git a/tools/flask/policy/policy/flask/security_classes b/xen/xsm/flask/policy/security_classes
> similarity index 100%
> rename from tools/flask/policy/policy/flask/security_classes
> rename to xen/xsm/flask/policy/security_classes
> --
> 1.7.11.4
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 08:45:49 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 08:45:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLruY-0001RV-Rc; Wed, 10 Oct 2012 08:45:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLruW-0001RP-V6
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 08:45:01 +0000
Received: from [85.158.137.99:34221] by server-4.bemta-3.messagelabs.com id
	90/4D-01405-C8535705; Wed, 10 Oct 2012 08:45:00 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1349858699!16250901!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM1ODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30705 invoked from network); 10 Oct 2012 08:44:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 08:44:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; 
	d="asc'?scan'208";a="15064923"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 08:44:56 +0000
Received: from [IPv6:::1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 10 Oct 2012 09:44:56 +0100
Message-ID: <1349858695.3610.158.camel@Abyss>
From: Dario Faggioli 
To: Daniel De Graaf 
Date: Wed, 10 Oct 2012 09:44:55 +0100
In-Reply-To: <1349807513-10923-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1349801565.21847.228.camel@zakaz.uk.xensource.com>
	<1349807513-10923-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
MIME-Version: 1.0
Cc: Marcus.Granado@eu.citrix.com, andre.przywara@amd.com,
	Ian Campbell , anil@recoil.org,
	George.Dunlap@eu.citrix.com, Andrew.Cooper3@citrix.com,
	juergen.gross@ts.fujitsu.com, Ian.Jackson@eu.citrix.com,
	xen-devel@lists.xen.org, JBeulich@suse.com, msw@amazon.com
Subject: Re: [Xen-devel] [PATCH RFC] flask: move policy header sources into
 hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============6672417874350135783=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6672417874350135783==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-xjQRejGfuMuFNdVyB1Vf"

--=-xjQRejGfuMuFNdVyB1Vf
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello Daniel,

On Tue, 2012-10-09 at 14:31 -0400, Daniel De Graaf wrote:=20
> Ian Campbell wrote:
> [...]
> >>> +++ b/xen/xsm/flask/include/av_perm_to_string.h
> > Also, in that case why is this file checked in?
>=20
> This patch fixes the autogenerated files, but doesn't fully wire them in
> to things like "make clean" or .{git,hg}ignore.=20
>
Forgive me for pushing but, while you're here, do you mind taking a look
and sharing your thoughts about the hunks of the patch touching XSM and
FLASK? As I said, I've very few experience with that part of Xen, and it
would be wonderful to know whether what I did looks sane, or I messed
something up! :-P

Thanks and Regards,
Dario

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-xjQRejGfuMuFNdVyB1Vf
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlB1NYcACgkQk4XaBE3IOsTmwwCgoAylvForeG5326cP2C57OIGR
DDAAnRw+yD5uy7JWWPtyesKd4OsXxBQe
=/cFd
-----END PGP SIGNATURE-----

--=-xjQRejGfuMuFNdVyB1Vf--


--===============6672417874350135783==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6672417874350135783==--


From xen-devel-bounces@lists.xen.org Wed Oct 10 08:45:49 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 08:45:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLruY-0001RV-Rc; Wed, 10 Oct 2012 08:45:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLruW-0001RP-V6
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 08:45:01 +0000
Received: from [85.158.137.99:34221] by server-4.bemta-3.messagelabs.com id
	90/4D-01405-C8535705; Wed, 10 Oct 2012 08:45:00 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1349858699!16250901!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM1ODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30705 invoked from network); 10 Oct 2012 08:44:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 08:44:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; 
	d="asc'?scan'208";a="15064923"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 08:44:56 +0000
Received: from [IPv6:::1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 10 Oct 2012 09:44:56 +0100
Message-ID: <1349858695.3610.158.camel@Abyss>
From: Dario Faggioli 
To: Daniel De Graaf 
Date: Wed, 10 Oct 2012 09:44:55 +0100
In-Reply-To: <1349807513-10923-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1349801565.21847.228.camel@zakaz.uk.xensource.com>
	<1349807513-10923-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
MIME-Version: 1.0
Cc: Marcus.Granado@eu.citrix.com, andre.przywara@amd.com,
	Ian Campbell , anil@recoil.org,
	George.Dunlap@eu.citrix.com, Andrew.Cooper3@citrix.com,
	juergen.gross@ts.fujitsu.com, Ian.Jackson@eu.citrix.com,
	xen-devel@lists.xen.org, JBeulich@suse.com, msw@amazon.com
Subject: Re: [Xen-devel] [PATCH RFC] flask: move policy header sources into
 hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============6672417874350135783=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6672417874350135783==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-xjQRejGfuMuFNdVyB1Vf"

--=-xjQRejGfuMuFNdVyB1Vf
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello Daniel,

On Tue, 2012-10-09 at 14:31 -0400, Daniel De Graaf wrote:=20
> Ian Campbell wrote:
> [...]
> >>> +++ b/xen/xsm/flask/include/av_perm_to_string.h
> > Also, in that case why is this file checked in?
>=20
> This patch fixes the autogenerated files, but doesn't fully wire them in
> to things like "make clean" or .{git,hg}ignore.=20
>
Forgive me for pushing but, while you're here, do you mind taking a look
and sharing your thoughts about the hunks of the patch touching XSM and
FLASK? As I said, I've very few experience with that part of Xen, and it
would be wonderful to know whether what I did looks sane, or I messed
something up! :-P

Thanks and Regards,
Dario

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-xjQRejGfuMuFNdVyB1Vf
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlB1NYcACgkQk4XaBE3IOsTmwwCgoAylvForeG5326cP2C57OIGR
DDAAnRw+yD5uy7JWWPtyesKd4OsXxBQe
=/cFd
-----END PGP SIGNATURE-----

--=-xjQRejGfuMuFNdVyB1Vf--


--===============6672417874350135783==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6672417874350135783==--


From xen-devel-bounces@lists.xen.org Wed Oct 10 08:48:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 08:48:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLrxj-0001YL-F2; Wed, 10 Oct 2012 08:48:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLrxi-0001YD-Qc
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 08:48:19 +0000
Received: from [85.158.139.83:63384] by server-9.bemta-5.messagelabs.com id
	E6/A1-31466-25635705; Wed, 10 Oct 2012 08:48:18 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1349858896!29664706!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM1ODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22998 invoked from network); 10 Oct 2012 08:48:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 08:48:17 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; 
	d="asc'?scan'208";a="15065058"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 08:46:57 +0000
Received: from [IPv6:::1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 10 Oct 2012 09:46:56 +0100
Message-ID: <1349858816.3610.160.camel@Abyss>
From: Dario Faggioli 
To: Ian Jackson 
Date: Wed, 10 Oct 2012 09:46:56 +0100
In-Reply-To: <20596.15552.595313.80971@mariner.uk.xensource.com>
References: 
	<7fba2d9044e720770c25.1349446106@Solace>
	<20591.3218.46221.931473@mariner.uk.xensource.com>
	<1349780874.3610.89.camel@Abyss>
	<20596.15552.595313.80971@mariner.uk.xensource.com>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
MIME-Version: 1.0
Cc: Marcus Granado ,
	Andre Przywara ,
	Ian Campbell , Anil
	Madhavapeddy ,
	George Dunlap ,
	Andrew Cooper ,
	Juergen Gross ,
	"xen-devel@lists.xen.org" ,
	Jan Beulich , Daniel De Graaf ,
	Matt Wilson 
Subject: Re: [Xen-devel] [PATCH 8 of 8] xl: add node-affinity to the output
 of `xl list`
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============4118309009238416473=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4118309009238416473==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-mL9Kb01ctuDQ/RQDhPnc"

--=-mL9Kb01ctuDQ/RQDhPnc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2012-10-09 at 16:03 +0100, Ian Jackson wrote:=20
> > Which is what made me thinking that opacity was not its first concern i=
n
> > the first place, and that turning it into being opaque was none of this
> > change's business. :-)
>=20
> You are right that since you're just moving the code, it's not a
> problem for this patch.
>=20
Ok.

> > However, I see your point... Perhaps I can add two functions (something
> > like print_{cpumap,nodemap}()), both calling the original
> > print_bitmap(), and deal with the "any {cpu,node}" case within them...=
=20
> >=20
> > Do you like that better?
>=20
> That would indeed be an improvement.
>=20
But I think I'll go for it then. It's a small effort, and I think the
final results would be better too.

Thanks and Regards,
Dario

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-mL9Kb01ctuDQ/RQDhPnc
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlB1NgAACgkQk4XaBE3IOsQutQCgj/gSDTvJMj5v0wQOfL5Jeuau
5AwAnAkAtQlVTsmyRR5ZTMgbmz1u05BI
=sP6m
-----END PGP SIGNATURE-----

--=-mL9Kb01ctuDQ/RQDhPnc--


--===============4118309009238416473==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4118309009238416473==--


From xen-devel-bounces@lists.xen.org Wed Oct 10 08:48:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 08:48:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLrxj-0001YL-F2; Wed, 10 Oct 2012 08:48:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLrxi-0001YD-Qc
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 08:48:19 +0000
Received: from [85.158.139.83:63384] by server-9.bemta-5.messagelabs.com id
	E6/A1-31466-25635705; Wed, 10 Oct 2012 08:48:18 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1349858896!29664706!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM1ODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22998 invoked from network); 10 Oct 2012 08:48:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 08:48:17 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; 
	d="asc'?scan'208";a="15065058"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 08:46:57 +0000
Received: from [IPv6:::1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 10 Oct 2012 09:46:56 +0100
Message-ID: <1349858816.3610.160.camel@Abyss>
From: Dario Faggioli 
To: Ian Jackson 
Date: Wed, 10 Oct 2012 09:46:56 +0100
In-Reply-To: <20596.15552.595313.80971@mariner.uk.xensource.com>
References: 
	<7fba2d9044e720770c25.1349446106@Solace>
	<20591.3218.46221.931473@mariner.uk.xensource.com>
	<1349780874.3610.89.camel@Abyss>
	<20596.15552.595313.80971@mariner.uk.xensource.com>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
MIME-Version: 1.0
Cc: Marcus Granado ,
	Andre Przywara ,
	Ian Campbell , Anil
	Madhavapeddy ,
	George Dunlap ,
	Andrew Cooper ,
	Juergen Gross ,
	"xen-devel@lists.xen.org" ,
	Jan Beulich , Daniel De Graaf ,
	Matt Wilson 
Subject: Re: [Xen-devel] [PATCH 8 of 8] xl: add node-affinity to the output
 of `xl list`
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============4118309009238416473=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4118309009238416473==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-mL9Kb01ctuDQ/RQDhPnc"

--=-mL9Kb01ctuDQ/RQDhPnc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2012-10-09 at 16:03 +0100, Ian Jackson wrote:=20
> > Which is what made me thinking that opacity was not its first concern i=
n
> > the first place, and that turning it into being opaque was none of this
> > change's business. :-)
>=20
> You are right that since you're just moving the code, it's not a
> problem for this patch.
>=20
Ok.

> > However, I see your point... Perhaps I can add two functions (something
> > like print_{cpumap,nodemap}()), both calling the original
> > print_bitmap(), and deal with the "any {cpu,node}" case within them...=
=20
> >=20
> > Do you like that better?
>=20
> That would indeed be an improvement.
>=20
But I think I'll go for it then. It's a small effort, and I think the
final results would be better too.

Thanks and Regards,
Dario

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-mL9Kb01ctuDQ/RQDhPnc
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlB1NgAACgkQk4XaBE3IOsQutQCgj/gSDTvJMj5v0wQOfL5Jeuau
5AwAnAkAtQlVTsmyRR5ZTMgbmz1u05BI
=sP6m
-----END PGP SIGNATURE-----

--=-mL9Kb01ctuDQ/RQDhPnc--


--===============4118309009238416473==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4118309009238416473==--


From xen-devel-bounces@lists.xen.org Wed Oct 10 09:11:26 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 09:11:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLsJg-0001qQ-EM; Wed, 10 Oct 2012 09:11:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLsJf-0001qL-Hb
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 09:10:59 +0000
Received: from [85.158.139.211:30583] by server-4.bemta-5.messagelabs.com id
	82/19-18688-2AB35705; Wed, 10 Oct 2012 09:10:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1349860256!21800418!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM3MzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6131 invoked from network); 10 Oct 2012 09:10:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 09:10:58 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="15066452"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 09:10:24 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 10 Oct 2012 10:10:19 +0100
Message-ID: <1349860218.10070.16.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: "Liu, Jinsong" 
Date: Wed, 10 Oct 2012 10:10:18 +0100
In-Reply-To: 
References: 
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration when vMCE
	occur
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-09-18 at 14:16 +0100, Liu, Jinsong wrote:
> Xen/MCE: Abort live migration when vMCE occur
> 
> This patch monitor the critical area of live migration (from vMCE point of view,
> the copypages stage of migration is the critical area while other areas are not).
> 
> If a vMCE occur at the critical area of live migration, abort and try migration later.

Can you elaborate a little on why it is necessary to abort and try
again?

> Signed-off-by: Liu, Jinsong 
> 
> diff -r f843ac6f93c9 tools/libxc/xc_domain.c
> --- a/tools/libxc/xc_domain.c	Wed Sep 19 01:21:18 2012 +0800
> +++ b/tools/libxc/xc_domain.c	Wed Sep 19 03:31:30 2012 +0800
> @@ -283,6 +283,37 @@
>      return ret;
>  }
>  
> +/* Start vmce monitor */
> +int xc_domain_vmce_monitor_strat(xc_interface *xch,

strat?

> +                                 uint32_t domid)
> +{
> +    int ret;
> +    DECLARE_DOMCTL;
> +
> +    domctl.cmd = XEN_DOMCTL_vmce_monitor_start;
> +    domctl.domain = (domid_t)domid;
> +    ret = do_domctl(xch, &domctl);
> +
> +    return ret ? -1 : 0;
> +}
> +
> +/* End vmce monitor */
> +int xc_domain_vmce_monitor_end(xc_interface *xch,
> +                               uint32_t domid,
> +                               signed char *vmce_while_monitor)
> +{
> +    int ret;
> +    DECLARE_DOMCTL;
> +
> +    domctl.cmd = XEN_DOMCTL_vmce_monitor_end;
> +    domctl.domain = (domid_t)domid;
> +    ret = do_domctl(xch, &domctl);
> +    if ( !ret )
> +        *vmce_while_monitor = domctl.u.vmce_monitor.vmce_while_monitor;

Any reason this is a char rather than an int?

> +    return ret ? -1 : 0;
> +}
> +
>  /* get info from hvm guest for save */
>  int xc_domain_hvm_getcontext(xc_interface *xch,
>                               uint32_t domid,
> [...]
> diff -r f843ac6f93c9 tools/libxc/xenctrl.h
> --- a/tools/libxc/xenctrl.h	Wed Sep 19 01:21:18 2012 +0800
> +++ b/tools/libxc/xenctrl.h	Wed Sep 19 03:31:30 2012 +0800
> @@ -571,6 +571,26 @@
>                            xc_domaininfo_t *info);
>  
>  /**
> + * This function start monitor vmce event.
> + * @parm xch a handle to an open hypervisor interface
> + * @parm domid the domain id monitored
> + * @return 0 on success, -1 on failure
> + */
> +int xc_domain_vmce_monitor_strat(xc_interface *xch,
> +                                 uint32_t domid);
> +
> +/**
> + * This function end monitor vmce event
> + * @parm xch a handle to an open hypervisor interface
> + * @parm domid the domain id monitored
> + * @parm vmce_while_migrate a pointer return whether vMCE occur when migrate 

This function isn't actually specific to migration (even if that happens
to be the only user currently), it just tracks whether a vMCE occurs
while monitoring was in progress AFAICT.

> + * @return 0 on success, -1 on failure
> + */
> +int xc_domain_vmce_monitor_end(xc_interface *xch,
> +                               uint32_t domid,
> +                               signed char *vmce_while_monitor);
> +
> +/**
>   * This function returns information about the context of a hvm domain
>   * @parm xch a handle to an open hypervisor interface
>   * @parm domid the domain to get information from
> diff -r f843ac6f93c9 xen/include/asm-x86/domain.h
> --- a/xen/include/asm-x86/domain.h	Wed Sep 19 01:21:18 2012 +0800
> +++ b/xen/include/asm-x86/domain.h	Wed Sep 19 03:31:30 2012 +0800
> @@ -279,6 +279,11 @@
>      bool_t has_32bit_shinfo;
>      /* Domain cannot handle spurious page faults? */
>      bool_t suppress_spurious_page_faults;
> +    /* Monitoring guest memory copy of migration
> +     * = 0 - not monitoring
> +     * > 0 - monitoring
> +     * < 0 - vMCE occurred while monitoring */
> +    s8 vmce_monitor;
>  
>      /* Continuable domain_relinquish_resources(). */
>      enum {
> diff -r f843ac6f93c9 xen/include/public/domctl.h
> --- a/xen/include/public/domctl.h	Wed Sep 19 01:21:18 2012 +0800
> +++ b/xen/include/public/domctl.h	Wed Sep 19 03:31:30 2012 +0800
> @@ -828,6 +828,12 @@
>  typedef struct xen_domctl_set_access_required xen_domctl_set_access_required_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_access_required_t);
>  
> +struct xen_domctl_vmce_monitor {
> +    signed char vmce_while_monitor;

You leak the semantics of the internal flag into this variable which
makes it rather clumsy to use (e.g. you have to check for <0). This
should just be a bool I think.

Calling vmce_monitor_end without a preceding monitor start should be an
error (-EINVAL?) and this value would be undefined in that case.

Do you actually need struct xen_domctl_vmce_monitor could the flag not
be part of the return value of XEN_DOMCTL_vmce_monitor_end? e.g. -ERRNO
on error, 0 if no vmce, 1 if vmce occurred?

Also calling vmce_monitor_start while monitoring is already in progress
should result in -EBUSY, otherwise multiple agents who try to monitor
will get unexpected/inconsistent results.

> +};
> +typedef struct xen_domctl_vmce_monitor xen_domctl_vmce_monitor_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_domctl_vmce_monitor_t);
> +
>  struct xen_domctl {
>      uint32_t cmd;
>  #define XEN_DOMCTL_createdomain                   1
> @@ -893,6 +899,8 @@
>  #define XEN_DOMCTL_set_access_required           64
>  #define XEN_DOMCTL_audit_p2m                     65
>  #define XEN_DOMCTL_set_virq_handler              66
> +#define XEN_DOMCTL_vmce_monitor_start            67
> +#define XEN_DOMCTL_vmce_monitor_end              68
>  #define XEN_DOMCTL_gdbsx_guestmemio            1000
>  #define XEN_DOMCTL_gdbsx_pausevcpu             1001
>  #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
> @@ -947,6 +955,7 @@
>          struct xen_domctl_set_access_required access_required;
>          struct xen_domctl_audit_p2m         audit_p2m;
>          struct xen_domctl_set_virq_handler  set_virq_handler;
> +        struct xen_domctl_vmce_monitor      vmce_monitor;
>          struct xen_domctl_gdbsx_memio       gdbsx_guest_memio;
>          struct xen_domctl_gdbsx_pauseunp_vcpu gdbsx_pauseunp_vcpu;
>          struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 09:11:26 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 09:11:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLsJg-0001qQ-EM; Wed, 10 Oct 2012 09:11:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLsJf-0001qL-Hb
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 09:10:59 +0000
Received: from [85.158.139.211:30583] by server-4.bemta-5.messagelabs.com id
	82/19-18688-2AB35705; Wed, 10 Oct 2012 09:10:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1349860256!21800418!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM3MzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6131 invoked from network); 10 Oct 2012 09:10:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 09:10:58 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="15066452"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 09:10:24 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 10 Oct 2012 10:10:19 +0100
Message-ID: <1349860218.10070.16.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: "Liu, Jinsong" 
Date: Wed, 10 Oct 2012 10:10:18 +0100
In-Reply-To: 
References: 
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration when vMCE
	occur
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-09-18 at 14:16 +0100, Liu, Jinsong wrote:
> Xen/MCE: Abort live migration when vMCE occur
> 
> This patch monitor the critical area of live migration (from vMCE point of view,
> the copypages stage of migration is the critical area while other areas are not).
> 
> If a vMCE occur at the critical area of live migration, abort and try migration later.

Can you elaborate a little on why it is necessary to abort and try
again?

> Signed-off-by: Liu, Jinsong 
> 
> diff -r f843ac6f93c9 tools/libxc/xc_domain.c
> --- a/tools/libxc/xc_domain.c	Wed Sep 19 01:21:18 2012 +0800
> +++ b/tools/libxc/xc_domain.c	Wed Sep 19 03:31:30 2012 +0800
> @@ -283,6 +283,37 @@
>      return ret;
>  }
>  
> +/* Start vmce monitor */
> +int xc_domain_vmce_monitor_strat(xc_interface *xch,

strat?

> +                                 uint32_t domid)
> +{
> +    int ret;
> +    DECLARE_DOMCTL;
> +
> +    domctl.cmd = XEN_DOMCTL_vmce_monitor_start;
> +    domctl.domain = (domid_t)domid;
> +    ret = do_domctl(xch, &domctl);
> +
> +    return ret ? -1 : 0;
> +}
> +
> +/* End vmce monitor */
> +int xc_domain_vmce_monitor_end(xc_interface *xch,
> +                               uint32_t domid,
> +                               signed char *vmce_while_monitor)
> +{
> +    int ret;
> +    DECLARE_DOMCTL;
> +
> +    domctl.cmd = XEN_DOMCTL_vmce_monitor_end;
> +    domctl.domain = (domid_t)domid;
> +    ret = do_domctl(xch, &domctl);
> +    if ( !ret )
> +        *vmce_while_monitor = domctl.u.vmce_monitor.vmce_while_monitor;

Any reason this is a char rather than an int?

> +    return ret ? -1 : 0;
> +}
> +
>  /* get info from hvm guest for save */
>  int xc_domain_hvm_getcontext(xc_interface *xch,
>                               uint32_t domid,
> [...]
> diff -r f843ac6f93c9 tools/libxc/xenctrl.h
> --- a/tools/libxc/xenctrl.h	Wed Sep 19 01:21:18 2012 +0800
> +++ b/tools/libxc/xenctrl.h	Wed Sep 19 03:31:30 2012 +0800
> @@ -571,6 +571,26 @@
>                            xc_domaininfo_t *info);
>  
>  /**
> + * This function start monitor vmce event.
> + * @parm xch a handle to an open hypervisor interface
> + * @parm domid the domain id monitored
> + * @return 0 on success, -1 on failure
> + */
> +int xc_domain_vmce_monitor_strat(xc_interface *xch,
> +                                 uint32_t domid);
> +
> +/**
> + * This function end monitor vmce event
> + * @parm xch a handle to an open hypervisor interface
> + * @parm domid the domain id monitored
> + * @parm vmce_while_migrate a pointer return whether vMCE occur when migrate 

This function isn't actually specific to migration (even if that happens
to be the only user currently), it just tracks whether a vMCE occurs
while monitoring was in progress AFAICT.

> + * @return 0 on success, -1 on failure
> + */
> +int xc_domain_vmce_monitor_end(xc_interface *xch,
> +                               uint32_t domid,
> +                               signed char *vmce_while_monitor);
> +
> +/**
>   * This function returns information about the context of a hvm domain
>   * @parm xch a handle to an open hypervisor interface
>   * @parm domid the domain to get information from
> diff -r f843ac6f93c9 xen/include/asm-x86/domain.h
> --- a/xen/include/asm-x86/domain.h	Wed Sep 19 01:21:18 2012 +0800
> +++ b/xen/include/asm-x86/domain.h	Wed Sep 19 03:31:30 2012 +0800
> @@ -279,6 +279,11 @@
>      bool_t has_32bit_shinfo;
>      /* Domain cannot handle spurious page faults? */
>      bool_t suppress_spurious_page_faults;
> +    /* Monitoring guest memory copy of migration
> +     * = 0 - not monitoring
> +     * > 0 - monitoring
> +     * < 0 - vMCE occurred while monitoring */
> +    s8 vmce_monitor;
>  
>      /* Continuable domain_relinquish_resources(). */
>      enum {
> diff -r f843ac6f93c9 xen/include/public/domctl.h
> --- a/xen/include/public/domctl.h	Wed Sep 19 01:21:18 2012 +0800
> +++ b/xen/include/public/domctl.h	Wed Sep 19 03:31:30 2012 +0800
> @@ -828,6 +828,12 @@
>  typedef struct xen_domctl_set_access_required xen_domctl_set_access_required_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_access_required_t);
>  
> +struct xen_domctl_vmce_monitor {
> +    signed char vmce_while_monitor;

You leak the semantics of the internal flag into this variable which
makes it rather clumsy to use (e.g. you have to check for <0). This
should just be a bool I think.

Calling vmce_monitor_end without a preceding monitor start should be an
error (-EINVAL?) and this value would be undefined in that case.

Do you actually need struct xen_domctl_vmce_monitor could the flag not
be part of the return value of XEN_DOMCTL_vmce_monitor_end? e.g. -ERRNO
on error, 0 if no vmce, 1 if vmce occurred?

Also calling vmce_monitor_start while monitoring is already in progress
should result in -EBUSY, otherwise multiple agents who try to monitor
will get unexpected/inconsistent results.

> +};
> +typedef struct xen_domctl_vmce_monitor xen_domctl_vmce_monitor_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_domctl_vmce_monitor_t);
> +
>  struct xen_domctl {
>      uint32_t cmd;
>  #define XEN_DOMCTL_createdomain                   1
> @@ -893,6 +899,8 @@
>  #define XEN_DOMCTL_set_access_required           64
>  #define XEN_DOMCTL_audit_p2m                     65
>  #define XEN_DOMCTL_set_virq_handler              66
> +#define XEN_DOMCTL_vmce_monitor_start            67
> +#define XEN_DOMCTL_vmce_monitor_end              68
>  #define XEN_DOMCTL_gdbsx_guestmemio            1000
>  #define XEN_DOMCTL_gdbsx_pausevcpu             1001
>  #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
> @@ -947,6 +955,7 @@
>          struct xen_domctl_set_access_required access_required;
>          struct xen_domctl_audit_p2m         audit_p2m;
>          struct xen_domctl_set_virq_handler  set_virq_handler;
> +        struct xen_domctl_vmce_monitor      vmce_monitor;
>          struct xen_domctl_gdbsx_memio       gdbsx_guest_memio;
>          struct xen_domctl_gdbsx_pauseunp_vcpu gdbsx_pauseunp_vcpu;
>          struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 09:22:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 09:22:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLsU5-00024F-Qt; Wed, 10 Oct 2012 09:21:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLsU4-00024A-31
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 09:21:44 +0000
Received: from [85.158.139.83:7241] by server-12.bemta-5.messagelabs.com id
	77/75-19095-72E35705; Wed, 10 Oct 2012 09:21:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1349860901!28587856!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM1ODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31162 invoked from network); 10 Oct 2012 09:21:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 09:21:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="15067014"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 09:21:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 10 Oct 2012 10:21:35 +0100
Message-ID: <1349860894.10070.21.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: "Liu, Jinsong" 
Date: Wed, 10 Oct 2012 10:21:34 +0100
In-Reply-To: 
References: 
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 5/5] X86/vMCE: guest broken page handling
	when migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-09-19 at 09:15 +0100, Liu, Jinsong wrote:
> X86/vMCE: guest broken page handling when migration
> 
> This patch is used to handle guest broken page when migration.
> 
> At sender, the broken page would not be mapped, and the error page
> content would not be copied to target, otherwise it may trigger more
> serious error (i.e. SRAR error). While its pfn_type and pfn number
> would be transferred to target so that target take appropriate action.
> 
> At target, it would set p2m as p2m_ram_broken for broken page, so that
> if guest access the broken page again, it would kill guest as expected.
> 
> Signed-off-by: Liu, Jinsong 
> 
> diff -r a1d106d1aec8 tools/libxc/xc_domain.c
> --- a/tools/libxc/xc_domain.c	Wed Sep 19 03:31:31 2012 +0800
> +++ b/tools/libxc/xc_domain.c	Wed Sep 19 04:22:26 2012 +0800
> @@ -314,6 +314,22 @@
>      return ret ? -1 : 0;
>  }
>  
> +/* set broken page p2m */
> +int xc_set_broken_page_p2m(xc_interface *xch,
> +                           uint32_t domid,
> +                           unsigned long pfn)
> +{
> +    int ret;
> +    DECLARE_DOMCTL;
> +
> +    domctl.cmd = XEN_DOMCTL_set_broken_page_p2m;
> +    domctl.domain = (domid_t)domid;
> +    domctl.u.set_broken_page_p2m.pfn = pfn;
> +    ret = do_domctl(xch, &domctl);
> +
> +    return ret ? -1 : 0;
> +}
> +
>  /* get info from hvm guest for save */
>  int xc_domain_hvm_getcontext(xc_interface *xch,
>                               uint32_t domid,
> diff -r a1d106d1aec8 tools/libxc/xc_domain_restore.c
> --- a/tools/libxc/xc_domain_restore.c	Wed Sep 19 03:31:31 2012 +0800
> +++ b/tools/libxc/xc_domain_restore.c	Wed Sep 19 04:22:26 2012 +0800
> @@ -962,9 +962,15 @@
>  
>      countpages = count;
>      for (i = oldcount; i < buf->nr_pages; ++i)
> -        if ((buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) == XEN_DOMCTL_PFINFO_XTAB
> -            ||(buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) == XEN_DOMCTL_PFINFO_XALLOC)
> +    {
> +        unsigned long pagetype;
> +
> +        pagetype = buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK;
> +        if ( pagetype == XEN_DOMCTL_PFINFO_XTAB ||
> +             pagetype == XEN_DOMCTL_PFINFO_BROKEN ||
> +             pagetype == XEN_DOMCTL_PFINFO_XALLOC )
>              --countpages;
> +    }
>  
>      if (!countpages)
>          return count;
> @@ -1200,6 +1206,17 @@
>              /* a bogus/unmapped/allocate-only page: skip it */
>              continue;
>  
> +        if ( pagetype == XEN_DOMCTL_PFINFO_BROKEN )
> +        {
> +            if ( xc_set_broken_page_p2m(xch, dom, pfn) )
> +            {
> +                ERROR("Set p2m for broken page fail, "

"failed"

> +                      "dom=%d, pfn=%lx\n", dom, pfn);
> +                goto err_mapped;
> +            }
> +            continue;
> +        }
> +
>          if (pfn_err[i])
>          {
>              ERROR("unexpected PFN mapping failure pfn %lx map_mfn %lx p2m_mfn %lx",
> diff -r a1d106d1aec8 xen/include/public/domctl.h
> --- a/xen/include/public/domctl.h	Wed Sep 19 03:31:31 2012 +0800
> +++ b/xen/include/public/domctl.h	Wed Sep 19 04:22:26 2012 +0800
> @@ -136,6 +136,7 @@
>  #define XEN_DOMCTL_PFINFO_LPINTAB (0x1U<<31)
>  #define XEN_DOMCTL_PFINFO_XTAB    (0xfU<<28) /* invalid page */
>  #define XEN_DOMCTL_PFINFO_XALLOC  (0xeU<<28) /* allocate-only page */
> +#define XEN_DOMCTL_PFINFO_BROKEN  (0xdU<<28) /* broken page */
>  #define XEN_DOMCTL_PFINFO_PAGEDTAB (0x8U<<28)
>  #define XEN_DOMCTL_PFINFO_LTAB_MASK (0xfU<<28)
>  
> @@ -834,6 +835,12 @@
>  typedef struct xen_domctl_vmce_monitor xen_domctl_vmce_monitor_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_domctl_vmce_monitor_t);
>  
> +struct xen_domctl_set_broken_page_p2m {
> +    uint64_t pfn;
> +};

why not xen_pfn_t? or uint64_aligned_t?

Is domctl the right interface for this? Seems like more of an add to
physmap thing?

> +typedef struct xen_domctl_set_broken_page_p2m xen_domctl_set_broken_page_p2m_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_broken_page_p2m_t);
> +
>  struct xen_domctl {
>      uint32_t cmd;
>  #define XEN_DOMCTL_createdomain                   1
> @@ -901,6 +908,7 @@
>  #define XEN_DOMCTL_set_virq_handler              66
>  #define XEN_DOMCTL_vmce_monitor_start            67
>  #define XEN_DOMCTL_vmce_monitor_end              68
> +#define XEN_DOMCTL_set_broken_page_p2m           69
>  #define XEN_DOMCTL_gdbsx_guestmemio            1000
>  #define XEN_DOMCTL_gdbsx_pausevcpu             1001
>  #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
> @@ -957,6 +965,7 @@
>          struct xen_domctl_set_virq_handler  set_virq_handler;
>          struct xen_domctl_vmce_monitor      vmce_monitor;
>          struct xen_domctl_gdbsx_memio       gdbsx_guest_memio;
> +        struct xen_domctl_set_broken_page_p2m set_broken_page_p2m;
>          struct xen_domctl_gdbsx_pauseunp_vcpu gdbsx_pauseunp_vcpu;
>          struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
>          uint8_t                             pad[128];



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 09:22:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 09:22:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLsU5-00024F-Qt; Wed, 10 Oct 2012 09:21:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLsU4-00024A-31
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 09:21:44 +0000
Received: from [85.158.139.83:7241] by server-12.bemta-5.messagelabs.com id
	77/75-19095-72E35705; Wed, 10 Oct 2012 09:21:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1349860901!28587856!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM1ODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31162 invoked from network); 10 Oct 2012 09:21:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 09:21:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="15067014"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 09:21:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 10 Oct 2012 10:21:35 +0100
Message-ID: <1349860894.10070.21.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: "Liu, Jinsong" 
Date: Wed, 10 Oct 2012 10:21:34 +0100
In-Reply-To: 
References: 
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 5/5] X86/vMCE: guest broken page handling
	when migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-09-19 at 09:15 +0100, Liu, Jinsong wrote:
> X86/vMCE: guest broken page handling when migration
> 
> This patch is used to handle guest broken page when migration.
> 
> At sender, the broken page would not be mapped, and the error page
> content would not be copied to target, otherwise it may trigger more
> serious error (i.e. SRAR error). While its pfn_type and pfn number
> would be transferred to target so that target take appropriate action.
> 
> At target, it would set p2m as p2m_ram_broken for broken page, so that
> if guest access the broken page again, it would kill guest as expected.
> 
> Signed-off-by: Liu, Jinsong 
> 
> diff -r a1d106d1aec8 tools/libxc/xc_domain.c
> --- a/tools/libxc/xc_domain.c	Wed Sep 19 03:31:31 2012 +0800
> +++ b/tools/libxc/xc_domain.c	Wed Sep 19 04:22:26 2012 +0800
> @@ -314,6 +314,22 @@
>      return ret ? -1 : 0;
>  }
>  
> +/* set broken page p2m */
> +int xc_set_broken_page_p2m(xc_interface *xch,
> +                           uint32_t domid,
> +                           unsigned long pfn)
> +{
> +    int ret;
> +    DECLARE_DOMCTL;
> +
> +    domctl.cmd = XEN_DOMCTL_set_broken_page_p2m;
> +    domctl.domain = (domid_t)domid;
> +    domctl.u.set_broken_page_p2m.pfn = pfn;
> +    ret = do_domctl(xch, &domctl);
> +
> +    return ret ? -1 : 0;
> +}
> +
>  /* get info from hvm guest for save */
>  int xc_domain_hvm_getcontext(xc_interface *xch,
>                               uint32_t domid,
> diff -r a1d106d1aec8 tools/libxc/xc_domain_restore.c
> --- a/tools/libxc/xc_domain_restore.c	Wed Sep 19 03:31:31 2012 +0800
> +++ b/tools/libxc/xc_domain_restore.c	Wed Sep 19 04:22:26 2012 +0800
> @@ -962,9 +962,15 @@
>  
>      countpages = count;
>      for (i = oldcount; i < buf->nr_pages; ++i)
> -        if ((buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) == XEN_DOMCTL_PFINFO_XTAB
> -            ||(buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) == XEN_DOMCTL_PFINFO_XALLOC)
> +    {
> +        unsigned long pagetype;
> +
> +        pagetype = buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK;
> +        if ( pagetype == XEN_DOMCTL_PFINFO_XTAB ||
> +             pagetype == XEN_DOMCTL_PFINFO_BROKEN ||
> +             pagetype == XEN_DOMCTL_PFINFO_XALLOC )
>              --countpages;
> +    }
>  
>      if (!countpages)
>          return count;
> @@ -1200,6 +1206,17 @@
>              /* a bogus/unmapped/allocate-only page: skip it */
>              continue;
>  
> +        if ( pagetype == XEN_DOMCTL_PFINFO_BROKEN )
> +        {
> +            if ( xc_set_broken_page_p2m(xch, dom, pfn) )
> +            {
> +                ERROR("Set p2m for broken page fail, "

"failed"

> +                      "dom=%d, pfn=%lx\n", dom, pfn);
> +                goto err_mapped;
> +            }
> +            continue;
> +        }
> +
>          if (pfn_err[i])
>          {
>              ERROR("unexpected PFN mapping failure pfn %lx map_mfn %lx p2m_mfn %lx",
> diff -r a1d106d1aec8 xen/include/public/domctl.h
> --- a/xen/include/public/domctl.h	Wed Sep 19 03:31:31 2012 +0800
> +++ b/xen/include/public/domctl.h	Wed Sep 19 04:22:26 2012 +0800
> @@ -136,6 +136,7 @@
>  #define XEN_DOMCTL_PFINFO_LPINTAB (0x1U<<31)
>  #define XEN_DOMCTL_PFINFO_XTAB    (0xfU<<28) /* invalid page */
>  #define XEN_DOMCTL_PFINFO_XALLOC  (0xeU<<28) /* allocate-only page */
> +#define XEN_DOMCTL_PFINFO_BROKEN  (0xdU<<28) /* broken page */
>  #define XEN_DOMCTL_PFINFO_PAGEDTAB (0x8U<<28)
>  #define XEN_DOMCTL_PFINFO_LTAB_MASK (0xfU<<28)
>  
> @@ -834,6 +835,12 @@
>  typedef struct xen_domctl_vmce_monitor xen_domctl_vmce_monitor_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_domctl_vmce_monitor_t);
>  
> +struct xen_domctl_set_broken_page_p2m {
> +    uint64_t pfn;
> +};

why not xen_pfn_t? or uint64_aligned_t?

Is domctl the right interface for this? Seems like more of an add to
physmap thing?

> +typedef struct xen_domctl_set_broken_page_p2m xen_domctl_set_broken_page_p2m_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_broken_page_p2m_t);
> +
>  struct xen_domctl {
>      uint32_t cmd;
>  #define XEN_DOMCTL_createdomain                   1
> @@ -901,6 +908,7 @@
>  #define XEN_DOMCTL_set_virq_handler              66
>  #define XEN_DOMCTL_vmce_monitor_start            67
>  #define XEN_DOMCTL_vmce_monitor_end              68
> +#define XEN_DOMCTL_set_broken_page_p2m           69
>  #define XEN_DOMCTL_gdbsx_guestmemio            1000
>  #define XEN_DOMCTL_gdbsx_pausevcpu             1001
>  #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
> @@ -957,6 +965,7 @@
>          struct xen_domctl_set_virq_handler  set_virq_handler;
>          struct xen_domctl_vmce_monitor      vmce_monitor;
>          struct xen_domctl_gdbsx_memio       gdbsx_guest_memio;
> +        struct xen_domctl_set_broken_page_p2m set_broken_page_p2m;
>          struct xen_domctl_gdbsx_pauseunp_vcpu gdbsx_pauseunp_vcpu;
>          struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
>          uint8_t                             pad[128];



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 09:47:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 09:47:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLssC-0002Fw-0i; Wed, 10 Oct 2012 09:46:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLss9-0002Fr-OF
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 09:46:37 +0000
Received: from [85.158.137.99:37683] by server-5.bemta-3.messagelabs.com id
	52/6B-12440-CF345705; Wed, 10 Oct 2012 09:46:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1349862395!20990986!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM3MzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21273 invoked from network); 10 Oct 2012 09:46:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 09:46:36 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="15068018"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 09:46:35 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 10 Oct 2012 10:46:35 +0100
Message-ID: <1349862394.10070.23.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Arnd Bergmann 
Date: Wed, 10 Oct 2012 10:46:34 +0100
In-Reply-To: <201210091819.34310.arnd@arndb.de>
References: <1349796183-30648-1-git-send-email-arnd@arndb.de>
	<201210091539.46274.arnd@arndb.de>
	<1349799035.21847.222.camel@zakaz.uk.xensource.com>
	<201210091819.34310.arnd@arndb.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge ,
	"xen-devel@lists.xensource.com" ,
	Stefano Stabellini ,
	Konrad Rzeszutek Wilk ,
	"linux-kernel@vger.kernel.org" ,
	Russell King ,
	"linux-arm-kernel@lists.infradead.org"
	
Subject: Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-09 at 19:19 +0100, Arnd Bergmann wrote:
> On Tuesday 09 October 2012, Ian Campbell wrote:
> > On Tue, 2012-10-09 at 16:39 +0100, Arnd Bergmann wrote:
> > > On Tuesday 09 October 2012, Ian Campbell wrote:
> > > > > * The tmem hypercall is not available on ARM
> > > > > 
> > > > > * ARMv6 does not support cmpxchg on 16-bit words that are used in the
> > > > 
> > > > missing the end of this sentence?
> > > 
> > > Right, I meant to say 
> > > 
> > > * ARMv6 does not support cmpxchg on 16-bit words that are used in the
> > >   Xen grant table code, so we must ensure that Xen support is only built
> > >   on ARMv7-only kernels not combined ARMv6/v7 kernels.
> > > 
> > > This should be fixed differently in the future.
> > 
> > Is this is a build time failure because gcc/gas/etc refuses to generate
> > these instructions if it is configured for v6?
> > 
> > I ask because if it is only a runtime issue then we can reason that if
> > we are running Xen specific grant table code, then we must be running on
> > Xen and therefore must necessarily be running on a v7 (because Xen only
> > support v7+virt extensions) even if the kernel happens to be capable of
> > running on v6 too.
> 
> The underlying reason of course is that ARMv6 doesn't have those
> instructions. The symptom you see is a link error because gcc emits
> a reference to the (intentionally missing) __bad_cmpxchg() function
> from

OK, then your fix is the best one for now.

> [...]
> The possible solutions I can see for this are:
> 
> * change the grant table format to use 32 bits for the flags on ARM
> * change the code to always cmpxchg the entire 32 bit word including the flags.

I'd need to check the grant table semantics to see if this will be
possible.

> * implement your own cmpxchg wrapper that may be implemented using a spinlock
>   rather than cmpxchg if ARMv6 is enabled.

Even if ARMv6 is enabled the grant table code will never be running on
one so so it might be ok to just have our own wrapper which
unconditionally uses the v7 instruction? That might upset gas though.

> 
> 	Arnd



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 09:47:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 09:47:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLssC-0002Fw-0i; Wed, 10 Oct 2012 09:46:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLss9-0002Fr-OF
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 09:46:37 +0000
Received: from [85.158.137.99:37683] by server-5.bemta-3.messagelabs.com id
	52/6B-12440-CF345705; Wed, 10 Oct 2012 09:46:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1349862395!20990986!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM3MzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21273 invoked from network); 10 Oct 2012 09:46:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 09:46:36 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="15068018"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 09:46:35 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 10 Oct 2012 10:46:35 +0100
Message-ID: <1349862394.10070.23.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Arnd Bergmann 
Date: Wed, 10 Oct 2012 10:46:34 +0100
In-Reply-To: <201210091819.34310.arnd@arndb.de>
References: <1349796183-30648-1-git-send-email-arnd@arndb.de>
	<201210091539.46274.arnd@arndb.de>
	<1349799035.21847.222.camel@zakaz.uk.xensource.com>
	<201210091819.34310.arnd@arndb.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge ,
	"xen-devel@lists.xensource.com" ,
	Stefano Stabellini ,
	Konrad Rzeszutek Wilk ,
	"linux-kernel@vger.kernel.org" ,
	Russell King ,
	"linux-arm-kernel@lists.infradead.org"
	
Subject: Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-09 at 19:19 +0100, Arnd Bergmann wrote:
> On Tuesday 09 October 2012, Ian Campbell wrote:
> > On Tue, 2012-10-09 at 16:39 +0100, Arnd Bergmann wrote:
> > > On Tuesday 09 October 2012, Ian Campbell wrote:
> > > > > * The tmem hypercall is not available on ARM
> > > > > 
> > > > > * ARMv6 does not support cmpxchg on 16-bit words that are used in the
> > > > 
> > > > missing the end of this sentence?
> > > 
> > > Right, I meant to say 
> > > 
> > > * ARMv6 does not support cmpxchg on 16-bit words that are used in the
> > >   Xen grant table code, so we must ensure that Xen support is only built
> > >   on ARMv7-only kernels not combined ARMv6/v7 kernels.
> > > 
> > > This should be fixed differently in the future.
> > 
> > Is this is a build time failure because gcc/gas/etc refuses to generate
> > these instructions if it is configured for v6?
> > 
> > I ask because if it is only a runtime issue then we can reason that if
> > we are running Xen specific grant table code, then we must be running on
> > Xen and therefore must necessarily be running on a v7 (because Xen only
> > support v7+virt extensions) even if the kernel happens to be capable of
> > running on v6 too.
> 
> The underlying reason of course is that ARMv6 doesn't have those
> instructions. The symptom you see is a link error because gcc emits
> a reference to the (intentionally missing) __bad_cmpxchg() function
> from

OK, then your fix is the best one for now.

> [...]
> The possible solutions I can see for this are:
> 
> * change the grant table format to use 32 bits for the flags on ARM
> * change the code to always cmpxchg the entire 32 bit word including the flags.

I'd need to check the grant table semantics to see if this will be
possible.

> * implement your own cmpxchg wrapper that may be implemented using a spinlock
>   rather than cmpxchg if ARMv6 is enabled.

Even if ARMv6 is enabled the grant table code will never be running on
one so so it might be ok to just have our own wrapper which
unconditionally uses the v7 instruction? That might upset gas though.

> 
> 	Arnd



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 10:13:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 10:13:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLtHs-0002Vp-BP; Wed, 10 Oct 2012 10:13:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLtHr-0002Vh-3a
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 10:13:11 +0000
Received: from [85.158.143.99:31967] by server-3.bemta-4.messagelabs.com id
	2E/C4-10075-53A45705; Wed, 10 Oct 2012 10:13:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1349863986!27303322!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM1ODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10251 invoked from network); 10 Oct 2012 10:13:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 10:13:06 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="15069136"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 10:13:06 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 10 Oct 2012 11:13:06 +0100
Message-ID: <1349863984.10070.26.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Eric Dumazet 
Date: Wed, 10 Oct 2012 11:13:04 +0100
In-Reply-To: <1349793630.21847.208.camel@zakaz.uk.xensource.com>
References: <1349790467.21847.185.camel@zakaz.uk.xensource.com>
	<1349790863.21172.4406.camel@edumazet-glaptop>
	<1349792241.21847.199.camel@zakaz.uk.xensource.com>
	<1349792847.21172.4479.camel@edumazet-glaptop>
	<1349793630.21847.208.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" ,
	Eric Dumazet ,
	xen-devel , Konrad
	Rzeszutek Wilk ,
	Sander Eikelenboom 
Subject: Re: [Xen-devel] compound skb frag pages appearing in start_xmit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-09 at 15:40 +0100, Ian Campbell wrote:
> On Tue, 2012-10-09 at 15:27 +0100, Eric Dumazet wrote:
> > On Tue, 2012-10-09 at 15:17 +0100, Ian Campbell wrote:
> > 
> > > Does the higher order pages effectively reduce the number of frags which
> > > are in use? e.g if MAX_SKB_FRAGS is 16, then for order-0 pages you could
> > > have 64K worth of frag data.
> > > 
> > > If we switch to order-3 pages everywhere then can the skb contain 512K
> > > of data, or does the effective maximum number of frags in an skb reduce
> > > to 2?
> > 
> > effective number of frags reduce to 2 or 3
> > 
> > (We still limit GSO packets to ~63536 bytes)
> 
> Great! Then I think the fix is more/less trivial...

The following seems to work for me.

I haven't tackled netfront yet.

8<--------------------------------------------------------------

>From 551e42e3dd203f2eb97cb082985013bb33b8f020 Mon Sep 17 00:00:00 2001
From: Ian Campbell 
Date: Tue, 9 Oct 2012 15:51:20 +0100
Subject: [PATCH] xen: netback: handle compound page fragments on transmit.

An SKB paged fragment can consist of a compound page with order > 0.
However the netchannel protocol deals only in PAGE_SIZE frames.

Handle this in netbk_gop_frag_copy and xen_netbk_count_skb_slots by
iterating over the frames which make up the page.

Signed-off-by: Ian Campbell 
Cc: Eric Dumazet 
Cc: Konrad Rzeszutek Wilk 
Cc: Sander Eikelenboom 
---
 drivers/net/xen-netback/netback.c |   40 ++++++++++++++++++++++++++++++++----
 1 files changed, 35 insertions(+), 5 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 4ebfcf3..d747e30 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -335,21 +335,35 @@ unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb)
 
 	for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
 		unsigned long size = skb_frag_size(&skb_shinfo(skb)->frags[i]);
+		unsigned long offset = skb_shinfo(skb)->frags[i].page_offset;
 		unsigned long bytes;
+
+		offset &= ~PAGE_MASK;
+
 		while (size > 0) {
+			BUG_ON(offset >= PAGE_SIZE);
 			BUG_ON(copy_off > MAX_BUFFER_OFFSET);
 
-			if (start_new_rx_buffer(copy_off, size, 0)) {
+			bytes = PAGE_SIZE - offset;
+
+			if (bytes > size)
+				bytes = size;
+
+			if (start_new_rx_buffer(copy_off, bytes, 0)) {
 				count++;
 				copy_off = 0;
 			}
 
-			bytes = size;
 			if (copy_off + bytes > MAX_BUFFER_OFFSET)
 				bytes = MAX_BUFFER_OFFSET - copy_off;
 
 			copy_off += bytes;
+
+			offset += bytes;
 			size -= bytes;
+
+			if (offset == PAGE_SIZE)
+				offset = 0;
 		}
 	}
 	return count;
@@ -403,14 +417,24 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 	unsigned long bytes;
 
 	/* Data must not cross a page boundary. */
-	BUG_ON(size + offset > PAGE_SIZE);
+	BUG_ON(size + offset > PAGE_SIZE<meta + npo->meta_prod - 1;
 
+	/* Skip unused frames from start of page */
+	page += offset >> PAGE_SHIFT;
+	offset &= ~PAGE_MASK;
+
 	while (size > 0) {
+		BUG_ON(offset >= PAGE_SIZE);
 		BUG_ON(npo->copy_off > MAX_BUFFER_OFFSET);
 
-		if (start_new_rx_buffer(npo->copy_off, size, *head)) {
+		bytes = PAGE_SIZE - offset;
+
+		if (bytes > size)
+			bytes = size;
+
+		if (start_new_rx_buffer(npo->copy_off, bytes, *head)) {
 			/*
 			 * Netfront requires there to be some data in the head
 			 * buffer.
@@ -420,7 +444,6 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 			meta = get_next_rx_buffer(vif, npo);
 		}
 
-		bytes = size;
 		if (npo->copy_off + bytes > MAX_BUFFER_OFFSET)
 			bytes = MAX_BUFFER_OFFSET - npo->copy_off;
 
@@ -453,6 +476,13 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 		offset += bytes;
 		size -= bytes;
 
+		/* Next frame */
+		if (offset == PAGE_SIZE) {
+			BUG_ON(!PageCompound(page));
+			page++;
+			offset = 0;
+		}
+
 		/* Leave a gap for the GSO descriptor. */
 		if (*head && skb_shinfo(skb)->gso_size && !vif->gso_prefix)
 			vif->rx.req_cons++;
-- 
1.7.2.5




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 10:13:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 10:13:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLtHs-0002Vp-BP; Wed, 10 Oct 2012 10:13:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLtHr-0002Vh-3a
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 10:13:11 +0000
Received: from [85.158.143.99:31967] by server-3.bemta-4.messagelabs.com id
	2E/C4-10075-53A45705; Wed, 10 Oct 2012 10:13:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1349863986!27303322!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM1ODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10251 invoked from network); 10 Oct 2012 10:13:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 10:13:06 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="15069136"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 10:13:06 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 10 Oct 2012 11:13:06 +0100
Message-ID: <1349863984.10070.26.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Eric Dumazet 
Date: Wed, 10 Oct 2012 11:13:04 +0100
In-Reply-To: <1349793630.21847.208.camel@zakaz.uk.xensource.com>
References: <1349790467.21847.185.camel@zakaz.uk.xensource.com>
	<1349790863.21172.4406.camel@edumazet-glaptop>
	<1349792241.21847.199.camel@zakaz.uk.xensource.com>
	<1349792847.21172.4479.camel@edumazet-glaptop>
	<1349793630.21847.208.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" ,
	Eric Dumazet ,
	xen-devel , Konrad
	Rzeszutek Wilk ,
	Sander Eikelenboom 
Subject: Re: [Xen-devel] compound skb frag pages appearing in start_xmit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-09 at 15:40 +0100, Ian Campbell wrote:
> On Tue, 2012-10-09 at 15:27 +0100, Eric Dumazet wrote:
> > On Tue, 2012-10-09 at 15:17 +0100, Ian Campbell wrote:
> > 
> > > Does the higher order pages effectively reduce the number of frags which
> > > are in use? e.g if MAX_SKB_FRAGS is 16, then for order-0 pages you could
> > > have 64K worth of frag data.
> > > 
> > > If we switch to order-3 pages everywhere then can the skb contain 512K
> > > of data, or does the effective maximum number of frags in an skb reduce
> > > to 2?
> > 
> > effective number of frags reduce to 2 or 3
> > 
> > (We still limit GSO packets to ~63536 bytes)
> 
> Great! Then I think the fix is more/less trivial...

The following seems to work for me.

I haven't tackled netfront yet.

8<--------------------------------------------------------------

>From 551e42e3dd203f2eb97cb082985013bb33b8f020 Mon Sep 17 00:00:00 2001
From: Ian Campbell 
Date: Tue, 9 Oct 2012 15:51:20 +0100
Subject: [PATCH] xen: netback: handle compound page fragments on transmit.

An SKB paged fragment can consist of a compound page with order > 0.
However the netchannel protocol deals only in PAGE_SIZE frames.

Handle this in netbk_gop_frag_copy and xen_netbk_count_skb_slots by
iterating over the frames which make up the page.

Signed-off-by: Ian Campbell 
Cc: Eric Dumazet 
Cc: Konrad Rzeszutek Wilk 
Cc: Sander Eikelenboom 
---
 drivers/net/xen-netback/netback.c |   40 ++++++++++++++++++++++++++++++++----
 1 files changed, 35 insertions(+), 5 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 4ebfcf3..d747e30 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -335,21 +335,35 @@ unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb)
 
 	for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
 		unsigned long size = skb_frag_size(&skb_shinfo(skb)->frags[i]);
+		unsigned long offset = skb_shinfo(skb)->frags[i].page_offset;
 		unsigned long bytes;
+
+		offset &= ~PAGE_MASK;
+
 		while (size > 0) {
+			BUG_ON(offset >= PAGE_SIZE);
 			BUG_ON(copy_off > MAX_BUFFER_OFFSET);
 
-			if (start_new_rx_buffer(copy_off, size, 0)) {
+			bytes = PAGE_SIZE - offset;
+
+			if (bytes > size)
+				bytes = size;
+
+			if (start_new_rx_buffer(copy_off, bytes, 0)) {
 				count++;
 				copy_off = 0;
 			}
 
-			bytes = size;
 			if (copy_off + bytes > MAX_BUFFER_OFFSET)
 				bytes = MAX_BUFFER_OFFSET - copy_off;
 
 			copy_off += bytes;
+
+			offset += bytes;
 			size -= bytes;
+
+			if (offset == PAGE_SIZE)
+				offset = 0;
 		}
 	}
 	return count;
@@ -403,14 +417,24 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 	unsigned long bytes;
 
 	/* Data must not cross a page boundary. */
-	BUG_ON(size + offset > PAGE_SIZE);
+	BUG_ON(size + offset > PAGE_SIZE<meta + npo->meta_prod - 1;
 
+	/* Skip unused frames from start of page */
+	page += offset >> PAGE_SHIFT;
+	offset &= ~PAGE_MASK;
+
 	while (size > 0) {
+		BUG_ON(offset >= PAGE_SIZE);
 		BUG_ON(npo->copy_off > MAX_BUFFER_OFFSET);
 
-		if (start_new_rx_buffer(npo->copy_off, size, *head)) {
+		bytes = PAGE_SIZE - offset;
+
+		if (bytes > size)
+			bytes = size;
+
+		if (start_new_rx_buffer(npo->copy_off, bytes, *head)) {
 			/*
 			 * Netfront requires there to be some data in the head
 			 * buffer.
@@ -420,7 +444,6 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 			meta = get_next_rx_buffer(vif, npo);
 		}
 
-		bytes = size;
 		if (npo->copy_off + bytes > MAX_BUFFER_OFFSET)
 			bytes = MAX_BUFFER_OFFSET - npo->copy_off;
 
@@ -453,6 +476,13 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 		offset += bytes;
 		size -= bytes;
 
+		/* Next frame */
+		if (offset == PAGE_SIZE) {
+			BUG_ON(!PageCompound(page));
+			page++;
+			offset = 0;
+		}
+
 		/* Leave a gap for the GSO descriptor. */
 		if (*head && skb_shinfo(skb)->gso_size && !vif->gso_prefix)
 			vif->rx.req_cons++;
-- 
1.7.2.5




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 10:56:20 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 10:56:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLtx3-0002lY-35; Wed, 10 Oct 2012 10:55:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLtx0-0002lT-RV
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 10:55:43 +0000
Received: from [85.158.137.99:8574] by server-7.bemta-3.messagelabs.com id
	D6/66-06991-E2455705; Wed, 10 Oct 2012 10:55:42 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1349866540!18647074!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22296 invoked from network); 10 Oct 2012 10:55:41 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 10:55:41 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so267873eek.32
	for ; Wed, 10 Oct 2012 03:55:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=yeUKcMZalgNNf98r5HmRRPR+yR9aIlBdgK5oCIGWzqY=;
	b=mj0O95m+5u/d1TGDKppBROag5GOVRkIchmfPcDgsqDRqLu/F30vsWq6u5BxKWKzFIf
	rQYxeiCUZDBaCFRLIIM8r3aXaEAdXJNvdIOBig5pRrKd+ryhbRparvFYuqhCvmrGIETR
	lT7QoMW3Rl2Dz3oWPfyq1hubDQGarWhiGgmT6DBiC+swHyuNOMAKoRWDG1/zEANyTiLn
	5IQxiDcnDjXgKgqr/ozTkTl1HXYKvyakIhonTKT+VeuLFXwTMFc9drL6z08qGMcPzkGn
	q4R+ZBBzo2J07fQo2jAEka80Y4pAwl+eUEdFaRFTtGmD9gjxhPSSwyJiQSnjxUi7PYDo
	Bxnw==
MIME-Version: 1.0
Received: by 10.14.4.201 with SMTP id 49mr32432396eej.0.1349866540483; Wed, 10
	Oct 2012 03:55:40 -0700 (PDT)
Received: by 10.14.134.10 with HTTP; Wed, 10 Oct 2012 03:55:40 -0700 (PDT)
In-Reply-To: 
References: 
	
Date: Wed, 10 Oct 2012 11:55:40 +0100
X-Google-Sender-Auth: 7mei6rATegx-JBiEASjECL_jKOQ
Message-ID: 
From: George Dunlap 
To: Dario Faggioli 
Cc: Marcus Granado ,
	Andre Przywara ,
	Ian Campbell ,
	Anil Madhavapeddy ,
	Andrew Cooper ,
	Juergen Gross ,
	Ian Jackson , xen-devel@lists.xen.org,
	Jan Beulich , Daniel De Graaf ,
	Matt Wilson 
Subject: Re: [Xen-devel] [PATCH 7 of 8] libxl: automatic placement deals
	with node-affinity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 5, 2012 at 3:08 PM, Dario Faggioli
 wrote:
> Which basically means the following two things:
>  1) during domain creation, it is the node-affinity of
>     the domain --rather than the vcpu-affinities of its
>     vcpus-- that is affected by automatic placement;
>  2) during automatic placement, when counting how many
>     vcpus are already "bound" to a placement candidate
>     (as part of the process of choosing the best
>     candidate), node-affinity is also considered,
>     together with vcpu-affinity.
>
> Signed-off-by: Dario Faggioli 

Acked-by: George Dunlap 

>
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -133,13 +133,13 @@ static int numa_place_domain(libxl__gc *
>  {
>      int found;
>      libxl__numa_candidate candidate;
> -    libxl_bitmap candidate_nodemap;
> +    libxl_bitmap cpupool_nodemap;
>      libxl_cpupoolinfo cpupool_info;
>      int i, cpupool, rc = 0;
>      uint32_t memkb;
>
>      libxl__numa_candidate_init(&candidate);
> -    libxl_bitmap_init(&candidate_nodemap);
> +    libxl_bitmap_init(&cpupool_nodemap);
>
>      /*
>       * Extract the cpumap from the cpupool the domain belong to. In fact,
> @@ -156,7 +156,7 @@ static int numa_place_domain(libxl__gc *
>      rc = libxl_domain_need_memory(CTX, info, &memkb);
>      if (rc)
>          goto out;
> -    if (libxl_node_bitmap_alloc(CTX, &candidate_nodemap, 0)) {
> +    if (libxl_node_bitmap_alloc(CTX, &cpupool_nodemap, 0)) {
>          rc = ERROR_FAIL;
>          goto out;
>      }
> @@ -174,17 +174,19 @@ static int numa_place_domain(libxl__gc *
>      if (found == 0)
>          goto out;
>
> -    /* Map the candidate's node map to the domain's info->cpumap */
> -    libxl__numa_candidate_get_nodemap(gc, &candidate, &candidate_nodemap);
> -    rc = libxl_nodemap_to_cpumap(CTX, &candidate_nodemap, &info->cpumap);
> +    /* Map the candidate's node map to the domain's info->nodemap */
> +    libxl__numa_candidate_get_nodemap(gc, &candidate, &info->nodemap);
> +
> +    /* Avoid trying to set the affinity to nodes that might be in the
> +     * candidate's nodemap but out of our cpupool. */
> +    rc = libxl_cpumap_to_nodemap(CTX, &cpupool_info.cpumap,
> +                                 &cpupool_nodemap);
>      if (rc)
>          goto out;
>
> -    /* Avoid trying to set the affinity to cpus that might be in the
> -     * nodemap but not in our cpupool. */
> -    libxl_for_each_set_bit(i, info->cpumap) {
> -        if (!libxl_bitmap_test(&cpupool_info.cpumap, i))
> -            libxl_bitmap_reset(&info->cpumap, i);
> +    libxl_for_each_set_bit(i, info->nodemap) {
> +        if (!libxl_bitmap_test(&cpupool_nodemap, i))
> +            libxl_bitmap_reset(&info->nodemap, i);
>      }
>
>      LOG(DETAIL, "NUMA placement candidate with %d nodes, %d cpus and "
> @@ -193,7 +195,7 @@ static int numa_place_domain(libxl__gc *
>
>   out:
>      libxl__numa_candidate_dispose(&candidate);
> -    libxl_bitmap_dispose(&candidate_nodemap);
> +    libxl_bitmap_dispose(&cpupool_nodemap);
>      libxl_cpupoolinfo_dispose(&cpupool_info);
>      return rc;
>  }
> @@ -211,10 +213,10 @@ int libxl__build_pre(libxl__gc *gc, uint
>      /*
>       * Check if the domain has any CPU affinity. If not, try to build
>       * up one. In case numa_place_domain() find at least a suitable
> -     * candidate, it will affect info->cpumap accordingly; if it
> +     * candidate, it will affect info->nodemap accordingly; if it
>       * does not, it just leaves it as it is. This means (unless
>       * some weird error manifests) the subsequent call to
> -     * libxl_set_vcpuaffinity_all() will do the actual placement,
> +     * libxl_domain_set_nodeaffinity() will do the actual placement,
>       * whatever that turns out to be.
>       */
>      if (libxl_defbool_val(info->numa_placement)) {
> diff --git a/tools/libxl/libxl_numa.c b/tools/libxl/libxl_numa.c
> --- a/tools/libxl/libxl_numa.c
> +++ b/tools/libxl/libxl_numa.c
> @@ -171,7 +171,7 @@ static int nodemap_to_nr_vcpus(libxl__gc
>                                 const libxl_bitmap *nodemap)
>  {
>      libxl_dominfo *dinfo = NULL;
> -    libxl_bitmap vcpu_nodemap;
> +    libxl_bitmap vcpu_nodemap, dom_nodemap;
>      int nr_doms, nr_cpus;
>      int nr_vcpus = 0;
>      int i, j, k;
> @@ -185,6 +185,12 @@ static int nodemap_to_nr_vcpus(libxl__gc
>          return ERROR_FAIL;
>      }
>
> +    if (libxl_node_bitmap_alloc(CTX, &dom_nodemap, 0) < 0) {
> +        libxl_dominfo_list_free(dinfo, nr_doms);
> +        libxl_bitmap_dispose(&vcpu_nodemap);
> +        return ERROR_FAIL;
> +    }
> +
>      for (i = 0; i < nr_doms; i++) {
>          libxl_vcpuinfo *vinfo;
>          int nr_dom_vcpus;
> @@ -193,6 +199,9 @@ static int nodemap_to_nr_vcpus(libxl__gc
>          if (vinfo == NULL)
>              continue;
>
> +        /* Retrieve the domain's node-affinity map (see below) */
> +        libxl_domain_get_nodeaffinity(CTX, dinfo[i].domid, &dom_nodemap);
> +
>          /* For each vcpu of each domain ... */
>          for (j = 0; j < nr_dom_vcpus; j++) {
>
> @@ -201,9 +210,17 @@ static int nodemap_to_nr_vcpus(libxl__gc
>              libxl_for_each_set_bit(k, vinfo[j].cpumap)
>                  libxl_bitmap_set(&vcpu_nodemap, tinfo[k].node);
>
> -            /* And check if that map has any intersection with our nodemap */
> +            /*
> +             * We now check whether the && of the vcpu's nodemap and the
> +             * domain's nodemap has any intersection with the nodemap of our
> +             * canidate.
> +             * Using both (vcpu's and domain's) nodemaps allows us to take
> +             * both vcpu-affinity and node-affinity into account when counting
> +             * the number of vcpus bound to the candidate.
> +             */
>              libxl_for_each_set_bit(k, vcpu_nodemap) {
> -                if (libxl_bitmap_test(nodemap, k)) {
> +                if (libxl_bitmap_test(&dom_nodemap, k) &&
> +                    libxl_bitmap_test(nodemap, k)) {
>                      nr_vcpus++;
>                      break;
>                  }
> @@ -213,6 +230,7 @@ static int nodemap_to_nr_vcpus(libxl__gc
>          libxl_vcpuinfo_list_free(vinfo, nr_dom_vcpus);
>      }
>
> +    libxl_bitmap_dispose(&dom_nodemap);
>      libxl_bitmap_dispose(&vcpu_nodemap);
>      libxl_dominfo_list_free(dinfo, nr_doms);
>      return nr_vcpus;
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 10:56:20 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 10:56:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLtx3-0002lY-35; Wed, 10 Oct 2012 10:55:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLtx0-0002lT-RV
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 10:55:43 +0000
Received: from [85.158.137.99:8574] by server-7.bemta-3.messagelabs.com id
	D6/66-06991-E2455705; Wed, 10 Oct 2012 10:55:42 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1349866540!18647074!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22296 invoked from network); 10 Oct 2012 10:55:41 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 10:55:41 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so267873eek.32
	for ; Wed, 10 Oct 2012 03:55:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=yeUKcMZalgNNf98r5HmRRPR+yR9aIlBdgK5oCIGWzqY=;
	b=mj0O95m+5u/d1TGDKppBROag5GOVRkIchmfPcDgsqDRqLu/F30vsWq6u5BxKWKzFIf
	rQYxeiCUZDBaCFRLIIM8r3aXaEAdXJNvdIOBig5pRrKd+ryhbRparvFYuqhCvmrGIETR
	lT7QoMW3Rl2Dz3oWPfyq1hubDQGarWhiGgmT6DBiC+swHyuNOMAKoRWDG1/zEANyTiLn
	5IQxiDcnDjXgKgqr/ozTkTl1HXYKvyakIhonTKT+VeuLFXwTMFc9drL6z08qGMcPzkGn
	q4R+ZBBzo2J07fQo2jAEka80Y4pAwl+eUEdFaRFTtGmD9gjxhPSSwyJiQSnjxUi7PYDo
	Bxnw==
MIME-Version: 1.0
Received: by 10.14.4.201 with SMTP id 49mr32432396eej.0.1349866540483; Wed, 10
	Oct 2012 03:55:40 -0700 (PDT)
Received: by 10.14.134.10 with HTTP; Wed, 10 Oct 2012 03:55:40 -0700 (PDT)
In-Reply-To: 
References: 
	
Date: Wed, 10 Oct 2012 11:55:40 +0100
X-Google-Sender-Auth: 7mei6rATegx-JBiEASjECL_jKOQ
Message-ID: 
From: George Dunlap 
To: Dario Faggioli 
Cc: Marcus Granado ,
	Andre Przywara ,
	Ian Campbell ,
	Anil Madhavapeddy ,
	Andrew Cooper ,
	Juergen Gross ,
	Ian Jackson , xen-devel@lists.xen.org,
	Jan Beulich , Daniel De Graaf ,
	Matt Wilson 
Subject: Re: [Xen-devel] [PATCH 7 of 8] libxl: automatic placement deals
	with node-affinity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 5, 2012 at 3:08 PM, Dario Faggioli
 wrote:
> Which basically means the following two things:
>  1) during domain creation, it is the node-affinity of
>     the domain --rather than the vcpu-affinities of its
>     vcpus-- that is affected by automatic placement;
>  2) during automatic placement, when counting how many
>     vcpus are already "bound" to a placement candidate
>     (as part of the process of choosing the best
>     candidate), node-affinity is also considered,
>     together with vcpu-affinity.
>
> Signed-off-by: Dario Faggioli 

Acked-by: George Dunlap 

>
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -133,13 +133,13 @@ static int numa_place_domain(libxl__gc *
>  {
>      int found;
>      libxl__numa_candidate candidate;
> -    libxl_bitmap candidate_nodemap;
> +    libxl_bitmap cpupool_nodemap;
>      libxl_cpupoolinfo cpupool_info;
>      int i, cpupool, rc = 0;
>      uint32_t memkb;
>
>      libxl__numa_candidate_init(&candidate);
> -    libxl_bitmap_init(&candidate_nodemap);
> +    libxl_bitmap_init(&cpupool_nodemap);
>
>      /*
>       * Extract the cpumap from the cpupool the domain belong to. In fact,
> @@ -156,7 +156,7 @@ static int numa_place_domain(libxl__gc *
>      rc = libxl_domain_need_memory(CTX, info, &memkb);
>      if (rc)
>          goto out;
> -    if (libxl_node_bitmap_alloc(CTX, &candidate_nodemap, 0)) {
> +    if (libxl_node_bitmap_alloc(CTX, &cpupool_nodemap, 0)) {
>          rc = ERROR_FAIL;
>          goto out;
>      }
> @@ -174,17 +174,19 @@ static int numa_place_domain(libxl__gc *
>      if (found == 0)
>          goto out;
>
> -    /* Map the candidate's node map to the domain's info->cpumap */
> -    libxl__numa_candidate_get_nodemap(gc, &candidate, &candidate_nodemap);
> -    rc = libxl_nodemap_to_cpumap(CTX, &candidate_nodemap, &info->cpumap);
> +    /* Map the candidate's node map to the domain's info->nodemap */
> +    libxl__numa_candidate_get_nodemap(gc, &candidate, &info->nodemap);
> +
> +    /* Avoid trying to set the affinity to nodes that might be in the
> +     * candidate's nodemap but out of our cpupool. */
> +    rc = libxl_cpumap_to_nodemap(CTX, &cpupool_info.cpumap,
> +                                 &cpupool_nodemap);
>      if (rc)
>          goto out;
>
> -    /* Avoid trying to set the affinity to cpus that might be in the
> -     * nodemap but not in our cpupool. */
> -    libxl_for_each_set_bit(i, info->cpumap) {
> -        if (!libxl_bitmap_test(&cpupool_info.cpumap, i))
> -            libxl_bitmap_reset(&info->cpumap, i);
> +    libxl_for_each_set_bit(i, info->nodemap) {
> +        if (!libxl_bitmap_test(&cpupool_nodemap, i))
> +            libxl_bitmap_reset(&info->nodemap, i);
>      }
>
>      LOG(DETAIL, "NUMA placement candidate with %d nodes, %d cpus and "
> @@ -193,7 +195,7 @@ static int numa_place_domain(libxl__gc *
>
>   out:
>      libxl__numa_candidate_dispose(&candidate);
> -    libxl_bitmap_dispose(&candidate_nodemap);
> +    libxl_bitmap_dispose(&cpupool_nodemap);
>      libxl_cpupoolinfo_dispose(&cpupool_info);
>      return rc;
>  }
> @@ -211,10 +213,10 @@ int libxl__build_pre(libxl__gc *gc, uint
>      /*
>       * Check if the domain has any CPU affinity. If not, try to build
>       * up one. In case numa_place_domain() find at least a suitable
> -     * candidate, it will affect info->cpumap accordingly; if it
> +     * candidate, it will affect info->nodemap accordingly; if it
>       * does not, it just leaves it as it is. This means (unless
>       * some weird error manifests) the subsequent call to
> -     * libxl_set_vcpuaffinity_all() will do the actual placement,
> +     * libxl_domain_set_nodeaffinity() will do the actual placement,
>       * whatever that turns out to be.
>       */
>      if (libxl_defbool_val(info->numa_placement)) {
> diff --git a/tools/libxl/libxl_numa.c b/tools/libxl/libxl_numa.c
> --- a/tools/libxl/libxl_numa.c
> +++ b/tools/libxl/libxl_numa.c
> @@ -171,7 +171,7 @@ static int nodemap_to_nr_vcpus(libxl__gc
>                                 const libxl_bitmap *nodemap)
>  {
>      libxl_dominfo *dinfo = NULL;
> -    libxl_bitmap vcpu_nodemap;
> +    libxl_bitmap vcpu_nodemap, dom_nodemap;
>      int nr_doms, nr_cpus;
>      int nr_vcpus = 0;
>      int i, j, k;
> @@ -185,6 +185,12 @@ static int nodemap_to_nr_vcpus(libxl__gc
>          return ERROR_FAIL;
>      }
>
> +    if (libxl_node_bitmap_alloc(CTX, &dom_nodemap, 0) < 0) {
> +        libxl_dominfo_list_free(dinfo, nr_doms);
> +        libxl_bitmap_dispose(&vcpu_nodemap);
> +        return ERROR_FAIL;
> +    }
> +
>      for (i = 0; i < nr_doms; i++) {
>          libxl_vcpuinfo *vinfo;
>          int nr_dom_vcpus;
> @@ -193,6 +199,9 @@ static int nodemap_to_nr_vcpus(libxl__gc
>          if (vinfo == NULL)
>              continue;
>
> +        /* Retrieve the domain's node-affinity map (see below) */
> +        libxl_domain_get_nodeaffinity(CTX, dinfo[i].domid, &dom_nodemap);
> +
>          /* For each vcpu of each domain ... */
>          for (j = 0; j < nr_dom_vcpus; j++) {
>
> @@ -201,9 +210,17 @@ static int nodemap_to_nr_vcpus(libxl__gc
>              libxl_for_each_set_bit(k, vinfo[j].cpumap)
>                  libxl_bitmap_set(&vcpu_nodemap, tinfo[k].node);
>
> -            /* And check if that map has any intersection with our nodemap */
> +            /*
> +             * We now check whether the && of the vcpu's nodemap and the
> +             * domain's nodemap has any intersection with the nodemap of our
> +             * canidate.
> +             * Using both (vcpu's and domain's) nodemaps allows us to take
> +             * both vcpu-affinity and node-affinity into account when counting
> +             * the number of vcpus bound to the candidate.
> +             */
>              libxl_for_each_set_bit(k, vcpu_nodemap) {
> -                if (libxl_bitmap_test(nodemap, k)) {
> +                if (libxl_bitmap_test(&dom_nodemap, k) &&
> +                    libxl_bitmap_test(nodemap, k)) {
>                      nr_vcpus++;
>                      break;
>                  }
> @@ -213,6 +230,7 @@ static int nodemap_to_nr_vcpus(libxl__gc
>          libxl_vcpuinfo_list_free(vinfo, nr_dom_vcpus);
>      }
>
> +    libxl_bitmap_dispose(&dom_nodemap);
>      libxl_bitmap_dispose(&vcpu_nodemap);
>      libxl_dominfo_list_free(dinfo, nr_doms);
>      return nr_vcpus;
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 11:00:39 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 11:00:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLu1L-0002uk-QS; Wed, 10 Oct 2012 11:00:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLu1K-0002uZ-U6
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 11:00:11 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1349866803!2995407!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6653 invoked from network); 10 Oct 2012 11:00:04 -0000
Received: from mail-ea0-f173.google.com (HELO mail-ea0-f173.google.com)
	(209.85.215.173)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 11:00:04 -0000
Received: by mail-ea0-f173.google.com with SMTP id a1so70257eaa.32
	for ; Wed, 10 Oct 2012 04:00:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=OShkhllbqaYjlT3HhlGZCPX6NN2i2QAl4yXzsg9PRtM=;
	b=mkXpwLNwey57afMELEbkh4OoG+d22y3QwWQKJgNT4MR0FlGYgQ+r7qrpwU7Fp680yP
	ckiJ4CJLRD2ldniwcgkPzRoT+kw8RO0Qbt1WdiB5mG5W7BlIrnjM4elp/cet0bAFRWX4
	LVv1OQxtnKtuVeD4f+IpQCXRAprxO62rNFvGxhmixlejaPJgpz+K7n/tZP5q+Mqb5w4J
	sjcWcLK+zucMYiH9ZPBTWAnvYGXum1egYAjYGwAs2MqBu/avfodVIgq+MqpxRZSgzlkE
	deIbtrlzQDEcij3L2DJ3IoEk2AIGq6pogIWgIYrf7uYrCXJ4USfKm8A70FPByOPlVUa3
	zs5g==
MIME-Version: 1.0
Received: by 10.14.4.201 with SMTP id 49mr32445781eej.0.1349866803846; Wed, 10
	Oct 2012 04:00:03 -0700 (PDT)
Received: by 10.14.134.10 with HTTP; Wed, 10 Oct 2012 04:00:03 -0700 (PDT)
In-Reply-To: 
References: 
Date: Wed, 10 Oct 2012 12:00:03 +0100
X-Google-Sender-Auth: gUImqhJhhLu0iHd_rYysLqZDMZE
Message-ID: 
From: George Dunlap 
To: Dario Faggioli 
Cc: Marcus Granado ,
	Andre Przywara ,
	Ian Campbell ,
	Anil Madhavapeddy ,
	Andrew Cooper ,
	Juergen Gross ,
	Ian Jackson , xen-devel@lists.xen.org,
	Jan Beulich , Daniel De Graaf ,
	Matt Wilson 
Subject: Re: [Xen-devel] [PATCH 0 of 8] NUMA Awareness for the Credit
	Scheduler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 5, 2012 at 3:08 PM, Dario Faggioli
 wrote:
> Hi Everyone,
>
> Here it comes a patch series instilling some NUMA awareness in the Credit
> scheduler.

Hey Dario -- I've looked through everything and acked everything I
felt I understood well enough / had the authority to ack.  Thanks for
the good work!

 -George

>
> What the patches do is teaching the Xen's scheduler how to try maximizing
> performances on a NUMA host, taking advantage of the information coming from
> the automatic NUMA placement we have in libxl.  Right now, the
> placement algorithm runs and selects a node (or a set of nodes) where it is best
> to put a new domain on. Then, all the memory for the new domain is allocated
> from those node(s) and all the vCPUs of the new domain are pinned to the pCPUs
> of those node(s). What we do here is, instead of statically pinning the domain's
> vCPUs to the nodes' pCPUs, have the (Credit) scheduler _prefer_ running them
> there. That enables most of the performances benefits of "real" pinning, but
> without its intrinsic lack of flexibility.
>
> The above happens by extending to the scheduler the knowledge of a domain's
> node-affinity. We then ask it to first try to run the domain's vCPUs on one of
> the nodes the domain has affinity with. Of course, if that turns out to be
> impossible, it falls back on the old behaviour (i.e., considering vcpu-affinity
> only).
>
> Just allow me to mention that NUMA aware scheduling not only is one of the item
> of the NUMA roadmap I'm trying to maintain here
> http://wiki.xen.org/wiki/Xen_NUMA_Roadmap. It is also one of the features we
> decided we want for Xen 4.3 (and thus it is part of the list of such features
> that George is maintaining).
>
> Up to now, I've been able to thoroughly test this only on my 2 NUMA nodes
> testbox, by running the SpecJBB2005 benchmark concurrently on multiple VMs, and
> the results looks really nice.  A full set of what I got can be found inside my
> presentation from last XenSummit, which is available here:
>
>  http://www.slideshare.net/xen_com_mgr/numa-and-virtualization-the-case-of-xen?ref=http://www.xen.org/xensummit/xs12na_talks/T9.html
>
> However, I rerun some of the tests in these last days (since I changed some
> bits of the implementation) and here's what I got:
>
> -------------------------------------------------------
>  SpecJBB2005 Total Aggregate Throughput
> -------------------------------------------------------
> #VMs       No NUMA affinity     NUMA affinity &   +/- %
>                                   scheduling
> -------------------------------------------------------
>    2            34653.273          40243.015    +16.13%
>    4            29883.057          35526.807    +18.88%
>    6            23512.926          27015.786    +14.89%
>    8            19120.243          21825.818    +14.15%
>   10            15676.675          17701.472    +12.91%
>
> Basically, results are consistent with what is shown in the super-nice graphs I
> have in the slides above! :-) As said, this looks nice to me, especially
> considering that my test machine is quite small, i.e., its 2 nodes are very
> close to each others from a latency point of view. I really expect more
> improvement on bigger hardware, where much greater NUMA effect is to be
> expected.  Of course, I myself will continue benchmarking (hopefully, on
> systems with more than 2 nodes too), but should anyone want to run its own
> testing, that would be great, so feel free to do that and report results to me
> and/or to the list!
>
> A little bit more about the series:
>
>  1/8 xen, libxc: rename xenctl_cpumap to xenctl_bitmap
>  2/8 xen, libxc: introduce node maps and masks
>
> Is some preparation work.
>
>  3/8 xen: let the (credit) scheduler know about `node affinity`
>
> Is where the vcpu load balancing logic of the credit scheduler is modified to
> support node-affinity.
>
>  4/8 xen: allow for explicitly specifying node-affinity
>  5/8 libxc: allow for explicitly specifying node-affinity
>  6/8 libxl: allow for explicitly specifying node-affinity
>  7/8 libxl: automatic placement deals with node-affinity
>
> Is what wires the in-scheduler node-affinity support with the external world.
> Please, note that patch 4 touches XSM and Flask, which is the area with which I
> have less experience and less chance to test properly. So, If Daniel and/or
> anyone interested in that could take a look and comment, that would be awesome.
>
>  8/8 xl: report node-affinity for domains
>
> Is just some small output enhancement.
>
> Thanks and Regards,
> Dario
>
> --
> <> (Raistlin Majere)
> -----------------------------------------------------------------
> Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
> Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 11:00:39 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 11:00:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLu1L-0002uk-QS; Wed, 10 Oct 2012 11:00:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLu1K-0002uZ-U6
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 11:00:11 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1349866803!2995407!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6653 invoked from network); 10 Oct 2012 11:00:04 -0000
Received: from mail-ea0-f173.google.com (HELO mail-ea0-f173.google.com)
	(209.85.215.173)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 11:00:04 -0000
Received: by mail-ea0-f173.google.com with SMTP id a1so70257eaa.32
	for ; Wed, 10 Oct 2012 04:00:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=OShkhllbqaYjlT3HhlGZCPX6NN2i2QAl4yXzsg9PRtM=;
	b=mkXpwLNwey57afMELEbkh4OoG+d22y3QwWQKJgNT4MR0FlGYgQ+r7qrpwU7Fp680yP
	ckiJ4CJLRD2ldniwcgkPzRoT+kw8RO0Qbt1WdiB5mG5W7BlIrnjM4elp/cet0bAFRWX4
	LVv1OQxtnKtuVeD4f+IpQCXRAprxO62rNFvGxhmixlejaPJgpz+K7n/tZP5q+Mqb5w4J
	sjcWcLK+zucMYiH9ZPBTWAnvYGXum1egYAjYGwAs2MqBu/avfodVIgq+MqpxRZSgzlkE
	deIbtrlzQDEcij3L2DJ3IoEk2AIGq6pogIWgIYrf7uYrCXJ4USfKm8A70FPByOPlVUa3
	zs5g==
MIME-Version: 1.0
Received: by 10.14.4.201 with SMTP id 49mr32445781eej.0.1349866803846; Wed, 10
	Oct 2012 04:00:03 -0700 (PDT)
Received: by 10.14.134.10 with HTTP; Wed, 10 Oct 2012 04:00:03 -0700 (PDT)
In-Reply-To: 
References: 
Date: Wed, 10 Oct 2012 12:00:03 +0100
X-Google-Sender-Auth: gUImqhJhhLu0iHd_rYysLqZDMZE
Message-ID: 
From: George Dunlap 
To: Dario Faggioli 
Cc: Marcus Granado ,
	Andre Przywara ,
	Ian Campbell ,
	Anil Madhavapeddy ,
	Andrew Cooper ,
	Juergen Gross ,
	Ian Jackson , xen-devel@lists.xen.org,
	Jan Beulich , Daniel De Graaf ,
	Matt Wilson 
Subject: Re: [Xen-devel] [PATCH 0 of 8] NUMA Awareness for the Credit
	Scheduler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 5, 2012 at 3:08 PM, Dario Faggioli
 wrote:
> Hi Everyone,
>
> Here it comes a patch series instilling some NUMA awareness in the Credit
> scheduler.

Hey Dario -- I've looked through everything and acked everything I
felt I understood well enough / had the authority to ack.  Thanks for
the good work!

 -George

>
> What the patches do is teaching the Xen's scheduler how to try maximizing
> performances on a NUMA host, taking advantage of the information coming from
> the automatic NUMA placement we have in libxl.  Right now, the
> placement algorithm runs and selects a node (or a set of nodes) where it is best
> to put a new domain on. Then, all the memory for the new domain is allocated
> from those node(s) and all the vCPUs of the new domain are pinned to the pCPUs
> of those node(s). What we do here is, instead of statically pinning the domain's
> vCPUs to the nodes' pCPUs, have the (Credit) scheduler _prefer_ running them
> there. That enables most of the performances benefits of "real" pinning, but
> without its intrinsic lack of flexibility.
>
> The above happens by extending to the scheduler the knowledge of a domain's
> node-affinity. We then ask it to first try to run the domain's vCPUs on one of
> the nodes the domain has affinity with. Of course, if that turns out to be
> impossible, it falls back on the old behaviour (i.e., considering vcpu-affinity
> only).
>
> Just allow me to mention that NUMA aware scheduling not only is one of the item
> of the NUMA roadmap I'm trying to maintain here
> http://wiki.xen.org/wiki/Xen_NUMA_Roadmap. It is also one of the features we
> decided we want for Xen 4.3 (and thus it is part of the list of such features
> that George is maintaining).
>
> Up to now, I've been able to thoroughly test this only on my 2 NUMA nodes
> testbox, by running the SpecJBB2005 benchmark concurrently on multiple VMs, and
> the results looks really nice.  A full set of what I got can be found inside my
> presentation from last XenSummit, which is available here:
>
>  http://www.slideshare.net/xen_com_mgr/numa-and-virtualization-the-case-of-xen?ref=http://www.xen.org/xensummit/xs12na_talks/T9.html
>
> However, I rerun some of the tests in these last days (since I changed some
> bits of the implementation) and here's what I got:
>
> -------------------------------------------------------
>  SpecJBB2005 Total Aggregate Throughput
> -------------------------------------------------------
> #VMs       No NUMA affinity     NUMA affinity &   +/- %
>                                   scheduling
> -------------------------------------------------------
>    2            34653.273          40243.015    +16.13%
>    4            29883.057          35526.807    +18.88%
>    6            23512.926          27015.786    +14.89%
>    8            19120.243          21825.818    +14.15%
>   10            15676.675          17701.472    +12.91%
>
> Basically, results are consistent with what is shown in the super-nice graphs I
> have in the slides above! :-) As said, this looks nice to me, especially
> considering that my test machine is quite small, i.e., its 2 nodes are very
> close to each others from a latency point of view. I really expect more
> improvement on bigger hardware, where much greater NUMA effect is to be
> expected.  Of course, I myself will continue benchmarking (hopefully, on
> systems with more than 2 nodes too), but should anyone want to run its own
> testing, that would be great, so feel free to do that and report results to me
> and/or to the list!
>
> A little bit more about the series:
>
>  1/8 xen, libxc: rename xenctl_cpumap to xenctl_bitmap
>  2/8 xen, libxc: introduce node maps and masks
>
> Is some preparation work.
>
>  3/8 xen: let the (credit) scheduler know about `node affinity`
>
> Is where the vcpu load balancing logic of the credit scheduler is modified to
> support node-affinity.
>
>  4/8 xen: allow for explicitly specifying node-affinity
>  5/8 libxc: allow for explicitly specifying node-affinity
>  6/8 libxl: allow for explicitly specifying node-affinity
>  7/8 libxl: automatic placement deals with node-affinity
>
> Is what wires the in-scheduler node-affinity support with the external world.
> Please, note that patch 4 touches XSM and Flask, which is the area with which I
> have less experience and less chance to test properly. So, If Daniel and/or
> anyone interested in that could take a look and comment, that would be awesome.
>
>  8/8 xl: report node-affinity for domains
>
> Is just some small output enhancement.
>
> Thanks and Regards,
> Dario
>
> --
> <> (Raistlin Majere)
> -----------------------------------------------------------------
> Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
> Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 11:08:22 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 11:08:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLu8t-00036g-T6; Wed, 10 Oct 2012 11:07:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLu8s-00036b-6Y
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 11:07:58 +0000
Received: from [85.158.138.51:56376] by server-11.bemta-3.messagelabs.com id
	2E/7F-24008-D0755705; Wed, 10 Oct 2012 11:07:57 +0000
X-Env-Sender: arnd@arndb.de
X-Msg-Ref: server-15.tower-174.messagelabs.com!1349867276!32035051!1
X-Originating-IP: [212.227.17.8]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjE3LjggPT4gODMxMDA=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjE3LjggPT4gODMxMDA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20082 invoked from network); 10 Oct 2012 11:07:57 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.17.8)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 11:07:57 -0000
Received: from klappe2.localnet (deibp9eh1--blueice3n2.emea.ibm.com
	[195.212.29.180])
	by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis)
	id 0MCMK5-1TCrb62x5F-009BDN; Wed, 10 Oct 2012 13:07:46 +0200
From: Arnd Bergmann 
To: Ian Campbell 
Date: Wed, 10 Oct 2012 11:07:40 +0000
User-Agent: KMail/1.12.2 (Linux/3.5.0; KDE/4.3.2; x86_64; ; )
References: <1349796183-30648-1-git-send-email-arnd@arndb.de>
	<201210091819.34310.arnd@arndb.de>
	<1349862394.10070.23.camel@zakaz.uk.xensource.com>
In-Reply-To: <1349862394.10070.23.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Message-Id: <201210101107.40898.arnd@arndb.de>
X-Provags-ID: V02:K0:aaiV5dVQme201i7ln3ZS3TKPHIZFk2TY4DQ7q5W6pMg
	tex9gueECDJL0or+GmpLToK6q8vSlf46K9XWZ4GEhNegs1eXFB
	offodrAEcv1iGNbLWChNzaCjtvls/pW3lfcCr8xwOzSiS4WE6g
	XYahKidD6XQeKBDzRI/Qaq+9jeobKXNCpglcC8dVS5Zo78QMlN
	MqK2ClDSmUdj8DV2ZJSVRaWmYKVQxuHWHyHoAhSV+09bf+unWZ
	/TvMhLpVsKf1Yeu1m2CRpl1knooJdJwvJeo0j6alV1HT8TE+tb
	2e11Ap0QZ6v2/Dh4tCdPYGVG9BZV712Wd19b2jCkautIEbkKOl
	nA2HhLb9fv+gnG01oDFk=
Cc: Jeremy Fitzhardinge ,
	"xen-devel@lists.xensource.com" ,
	Stefano Stabellini ,
	Konrad Rzeszutek Wilk ,
	"linux-kernel@vger.kernel.org" ,
	Russell King ,
	"linux-arm-kernel@lists.infradead.org"
	
Subject: Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wednesday 10 October 2012, Ian Campbell wrote:
> > * implement your own cmpxchg wrapper that may be implemented using a spinlock
> >   rather than cmpxchg if ARMv6 is enabled.
> 
> Even if ARMv6 is enabled the grant table code will never be running on
> one so so it might be ok to just have our own wrapper which
> unconditionally uses the v7 instruction? That might upset gas though.

Yes, that would be possible. You can tell gas to ignore the instruction
set in this case. If you do this, you can implement the update functions
more efficiently using direct ldrexh/strexh in assembler to avoid doing
two nested loops. I assume that you don't need the v1 grant table
code on ARM anyway, so the only code you need to look at is

        while (!((flags = *pflags) & GTF_transfer_committed)) {
                if (sync_cmpxchg(pflags, flags, 0) == flags)
                        return 0;
                cpu_relax();
        }

which should transform nicely into a few lines of inline assembly.

	Arnd

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 11:08:22 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 11:08:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLu8t-00036g-T6; Wed, 10 Oct 2012 11:07:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLu8s-00036b-6Y
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 11:07:58 +0000
Received: from [85.158.138.51:56376] by server-11.bemta-3.messagelabs.com id
	2E/7F-24008-D0755705; Wed, 10 Oct 2012 11:07:57 +0000
X-Env-Sender: arnd@arndb.de
X-Msg-Ref: server-15.tower-174.messagelabs.com!1349867276!32035051!1
X-Originating-IP: [212.227.17.8]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjE3LjggPT4gODMxMDA=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjE3LjggPT4gODMxMDA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20082 invoked from network); 10 Oct 2012 11:07:57 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.17.8)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 11:07:57 -0000
Received: from klappe2.localnet (deibp9eh1--blueice3n2.emea.ibm.com
	[195.212.29.180])
	by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis)
	id 0MCMK5-1TCrb62x5F-009BDN; Wed, 10 Oct 2012 13:07:46 +0200
From: Arnd Bergmann 
To: Ian Campbell 
Date: Wed, 10 Oct 2012 11:07:40 +0000
User-Agent: KMail/1.12.2 (Linux/3.5.0; KDE/4.3.2; x86_64; ; )
References: <1349796183-30648-1-git-send-email-arnd@arndb.de>
	<201210091819.34310.arnd@arndb.de>
	<1349862394.10070.23.camel@zakaz.uk.xensource.com>
In-Reply-To: <1349862394.10070.23.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Message-Id: <201210101107.40898.arnd@arndb.de>
X-Provags-ID: V02:K0:aaiV5dVQme201i7ln3ZS3TKPHIZFk2TY4DQ7q5W6pMg
	tex9gueECDJL0or+GmpLToK6q8vSlf46K9XWZ4GEhNegs1eXFB
	offodrAEcv1iGNbLWChNzaCjtvls/pW3lfcCr8xwOzSiS4WE6g
	XYahKidD6XQeKBDzRI/Qaq+9jeobKXNCpglcC8dVS5Zo78QMlN
	MqK2ClDSmUdj8DV2ZJSVRaWmYKVQxuHWHyHoAhSV+09bf+unWZ
	/TvMhLpVsKf1Yeu1m2CRpl1knooJdJwvJeo0j6alV1HT8TE+tb
	2e11Ap0QZ6v2/Dh4tCdPYGVG9BZV712Wd19b2jCkautIEbkKOl
	nA2HhLb9fv+gnG01oDFk=
Cc: Jeremy Fitzhardinge ,
	"xen-devel@lists.xensource.com" ,
	Stefano Stabellini ,
	Konrad Rzeszutek Wilk ,
	"linux-kernel@vger.kernel.org" ,
	Russell King ,
	"linux-arm-kernel@lists.infradead.org"
	
Subject: Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wednesday 10 October 2012, Ian Campbell wrote:
> > * implement your own cmpxchg wrapper that may be implemented using a spinlock
> >   rather than cmpxchg if ARMv6 is enabled.
> 
> Even if ARMv6 is enabled the grant table code will never be running on
> one so so it might be ok to just have our own wrapper which
> unconditionally uses the v7 instruction? That might upset gas though.

Yes, that would be possible. You can tell gas to ignore the instruction
set in this case. If you do this, you can implement the update functions
more efficiently using direct ldrexh/strexh in assembler to avoid doing
two nested loops. I assume that you don't need the v1 grant table
code on ARM anyway, so the only code you need to look at is

        while (!((flags = *pflags) & GTF_transfer_committed)) {
                if (sync_cmpxchg(pflags, flags, 0) == flags)
                        return 0;
                cpu_relax();
        }

which should transform nicely into a few lines of inline assembly.

	Arnd

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 11:22:59 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 11:22:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLuND-0003Wi-0t; Wed, 10 Oct 2012 11:22:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLuNB-0003Va-B9
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 11:22:45 +0000
Received: from [85.158.138.51:33429] by server-7.bemta-3.messagelabs.com id
	4C/43-06991-48A55705; Wed, 10 Oct 2012 11:22:44 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1349868161!33903641!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODEzOTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4702 invoked from network); 10 Oct 2012 11:22:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 11:22:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="210832189"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 11:22:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 10 Oct 2012 07:22:39 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TLuN4-0003aC-NT;
	Wed, 10 Oct 2012 12:22:38 +0100
MIME-Version: 1.0
X-Mercurial-Node: 344f6609af3335e1e27ef55c686c57ff33402d46
Message-ID: <344f6609af3335e1e27e.1349867853@elijah>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 10 Oct 2012 12:17:33 +0100
From: George Dunlap 
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 5 of 7] xenalzye: Also strip write bit when
 processing a generic event
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User George Dunlap 
# Date 1349262739 -3600
# Node ID 344f6609af3335e1e27ef55c686c57ff33402d46
# Parent  6e0e841283e5e68f03fe64d1c107942ab501846a
xenalzye: Also strip write bit when processing a generic event

Signed-off-by: George Dunlap 

diff --git a/xenalyze.c b/xenalyze.c
--- a/xenalyze.c
+++ b/xenalyze.c
@@ -4715,7 +4715,8 @@ void hvm_generic_postprocess(struct hvm_
     static unsigned registered[HVM_EVENT_HANDLER_MAX] = { 0 };
 
     if ( h->inflight.generic.event )
-        evt = (h->inflight.generic.event - TRC_HVM_HANDLER) & ~TRC_64_FLAG;
+        evt = (h->inflight.generic.event - TRC_HVM_HANDLER)
+            & ~(TRC_64_FLAG|HVM_IO_ASSIST_WRITE);
     else  {
         static unsigned warned[HVM_EXIT_REASON_MAX] = { 0 };
         /* Some exits we don't expect a handler; just return */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 11:22:59 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 11:22:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLuNC-0003WK-8W; Wed, 10 Oct 2012 11:22:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLuNA-0003VM-JJ
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 11:22:44 +0000
Received: from [85.158.138.51:19142] by server-12.bemta-3.messagelabs.com id
	17/13-27853-38A55705; Wed, 10 Oct 2012 11:22:43 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1349868161!33903641!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODEzOTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4585 invoked from network); 10 Oct 2012 11:22:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 11:22:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="210832187"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 11:22:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 10 Oct 2012 07:22:39 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TLuN4-0003aC-M4;
	Wed, 10 Oct 2012 12:22:38 +0100
MIME-Version: 1.0
X-Mercurial-Node: 3230041f50a54889784121579604412fdc260228
Message-ID: <3230041f50a548897841.1349867849@elijah>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 10 Oct 2012 12:17:29 +0100
From: George Dunlap 
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 1 of 7] xenalyze: Add HVM_EVENT_VLAPIC
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User George Dunlap 
# Date 1349261311 -3600
# Node ID 3230041f50a54889784121579604412fdc260228
# Parent  4d47a8934b40556dd98428361c482be419c643be
xenalyze: Add HVM_EVENT_VLAPIC

Signed-off-by: George Dunlap 

diff --git a/xenalyze.c b/xenalyze.c
--- a/xenalyze.c
+++ b/xenalyze.c
@@ -958,6 +958,7 @@ enum {
     HVM_EVENT_REALMODE_EMULATE,
     HVM_EVENT_TRAP,
     HVM_EVENT_TRAP_DEBUG,
+    HVM_EVENT_VLAPIC,
     HVM_EVENT_HANDLER_MAX
 };
 char * hvm_event_handler_name[HVM_EVENT_HANDLER_MAX] = {
@@ -993,6 +994,7 @@ char * hvm_event_handler_name[HVM_EVENT_
     "realmode_emulate",
     "trap",
     "trap_debug",
+    "vlapic"
 };
 
 enum {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 11:22:59 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 11:22:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLuND-0003Wi-0t; Wed, 10 Oct 2012 11:22:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLuNB-0003Va-B9
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 11:22:45 +0000
Received: from [85.158.138.51:33429] by server-7.bemta-3.messagelabs.com id
	4C/43-06991-48A55705; Wed, 10 Oct 2012 11:22:44 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1349868161!33903641!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODEzOTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4702 invoked from network); 10 Oct 2012 11:22:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 11:22:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="210832189"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 11:22:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 10 Oct 2012 07:22:39 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TLuN4-0003aC-NT;
	Wed, 10 Oct 2012 12:22:38 +0100
MIME-Version: 1.0
X-Mercurial-Node: 344f6609af3335e1e27ef55c686c57ff33402d46
Message-ID: <344f6609af3335e1e27e.1349867853@elijah>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 10 Oct 2012 12:17:33 +0100
From: George Dunlap 
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 5 of 7] xenalzye: Also strip write bit when
 processing a generic event
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User George Dunlap 
# Date 1349262739 -3600
# Node ID 344f6609af3335e1e27ef55c686c57ff33402d46
# Parent  6e0e841283e5e68f03fe64d1c107942ab501846a
xenalzye: Also strip write bit when processing a generic event

Signed-off-by: George Dunlap 

diff --git a/xenalyze.c b/xenalyze.c
--- a/xenalyze.c
+++ b/xenalyze.c
@@ -4715,7 +4715,8 @@ void hvm_generic_postprocess(struct hvm_
     static unsigned registered[HVM_EVENT_HANDLER_MAX] = { 0 };
 
     if ( h->inflight.generic.event )
-        evt = (h->inflight.generic.event - TRC_HVM_HANDLER) & ~TRC_64_FLAG;
+        evt = (h->inflight.generic.event - TRC_HVM_HANDLER)
+            & ~(TRC_64_FLAG|HVM_IO_ASSIST_WRITE);
     else  {
         static unsigned warned[HVM_EXIT_REASON_MAX] = { 0 };
         /* Some exits we don't expect a handler; just return */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 11:22:59 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 11:22:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLuNC-0003WU-L3; Wed, 10 Oct 2012 11:22:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLuNB-0003VV-4H
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 11:22:45 +0000
Received: from [85.158.138.51:33415] by server-16.bemta-3.messagelabs.com id
	61/57-02576-48A55705; Wed, 10 Oct 2012 11:22:44 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1349868159!27489693!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODEzOTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4277 invoked from network); 10 Oct 2012 11:22:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 11:22:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="210832188"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 11:22:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 10 Oct 2012 07:22:39 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TLuN4-0003aC-Mg;
	Wed, 10 Oct 2012 12:22:38 +0100
MIME-Version: 1.0
X-Mercurial-Node: 3aad48bd6ca3213c598d16c307ba531dc45d6240
Message-ID: <3aad48bd6ca3213c598d.1349867851@elijah>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 10 Oct 2012 12:17:31 +0100
From: George Dunlap 
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 3 of 7] xenalyze: Don't warn about switching
 paging levels unless verbosity>=6
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User George Dunlap 
# Date 1349261732 -3600
# Node ID 3aad48bd6ca3213c598d16c307ba531dc45d6240
# Parent  4ea8fb7197ff3fad82b224a65cdfbe86db66d6ab
xenalyze: Don't warn about switching paging levels unless verbosity>=6

During boot, the guest paging levels changes back and forth frequently,
leading to spam when your'e doing the analysis.  Don't print these messages
escept at verbosity level 6 (the default is 5).

Signed-off-by: George Dunlap 

diff --git a/xenalyze.c b/xenalyze.c
--- a/xenalyze.c
+++ b/xenalyze.c
@@ -5158,8 +5158,9 @@ void hvm_vmexit_process(struct record_in
     if(ri->event == TRC_HVM_VMEXIT64) {
         if(v->guest_paging_levels != 4)
         {
-            fprintf(warn, "%s: VMEXIT64, but guest_paging_levels %d.  Switching to 4.\n",
-                    __func__, v->guest_paging_levels);
+            if ( verbosity >= 6 )
+                fprintf(warn, "%s: VMEXIT64, but guest_paging_levels %d.  Switching to 4.\n",
+                        __func__, v->guest_paging_levels);
             v->guest_paging_levels = 4;
         }
         if(!is_valid_addr64(r->x64.rip))
@@ -5171,10 +5172,14 @@ void hvm_vmexit_process(struct record_in
         if(v->guest_paging_levels == 4)
         {
             int new_paging_levels = opt.default_guest_paging_levels;
+
             if(new_paging_levels == 4)
                 new_paging_levels = 2; /* Wild guess */
-            fprintf(warn, "%s: VMEXIT, but guest_paging_levels %d.  Switching to %d(default).\n",
-                    __func__, v->guest_paging_levels, new_paging_levels);
+
+            if ( verbosity >= 6 )
+                fprintf(warn, "%s: VMEXIT, but guest_paging_levels %d.  Switching to %d(default).\n",
+                        __func__, v->guest_paging_levels, new_paging_levels);
+
             v->guest_paging_levels = new_paging_levels;
         }
         h->rip = r->x32.eip;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 11:22:59 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 11:22:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLuNC-0003WU-L3; Wed, 10 Oct 2012 11:22:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLuNB-0003VV-4H
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 11:22:45 +0000
Received: from [85.158.138.51:33415] by server-16.bemta-3.messagelabs.com id
	61/57-02576-48A55705; Wed, 10 Oct 2012 11:22:44 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1349868159!27489693!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODEzOTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4277 invoked from network); 10 Oct 2012 11:22:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 11:22:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="210832188"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 11:22:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 10 Oct 2012 07:22:39 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TLuN4-0003aC-Mg;
	Wed, 10 Oct 2012 12:22:38 +0100
MIME-Version: 1.0
X-Mercurial-Node: 3aad48bd6ca3213c598d16c307ba531dc45d6240
Message-ID: <3aad48bd6ca3213c598d.1349867851@elijah>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 10 Oct 2012 12:17:31 +0100
From: George Dunlap 
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 3 of 7] xenalyze: Don't warn about switching
 paging levels unless verbosity>=6
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User George Dunlap 
# Date 1349261732 -3600
# Node ID 3aad48bd6ca3213c598d16c307ba531dc45d6240
# Parent  4ea8fb7197ff3fad82b224a65cdfbe86db66d6ab
xenalyze: Don't warn about switching paging levels unless verbosity>=6

During boot, the guest paging levels changes back and forth frequently,
leading to spam when your'e doing the analysis.  Don't print these messages
escept at verbosity level 6 (the default is 5).

Signed-off-by: George Dunlap 

diff --git a/xenalyze.c b/xenalyze.c
--- a/xenalyze.c
+++ b/xenalyze.c
@@ -5158,8 +5158,9 @@ void hvm_vmexit_process(struct record_in
     if(ri->event == TRC_HVM_VMEXIT64) {
         if(v->guest_paging_levels != 4)
         {
-            fprintf(warn, "%s: VMEXIT64, but guest_paging_levels %d.  Switching to 4.\n",
-                    __func__, v->guest_paging_levels);
+            if ( verbosity >= 6 )
+                fprintf(warn, "%s: VMEXIT64, but guest_paging_levels %d.  Switching to 4.\n",
+                        __func__, v->guest_paging_levels);
             v->guest_paging_levels = 4;
         }
         if(!is_valid_addr64(r->x64.rip))
@@ -5171,10 +5172,14 @@ void hvm_vmexit_process(struct record_in
         if(v->guest_paging_levels == 4)
         {
             int new_paging_levels = opt.default_guest_paging_levels;
+
             if(new_paging_levels == 4)
                 new_paging_levels = 2; /* Wild guess */
-            fprintf(warn, "%s: VMEXIT, but guest_paging_levels %d.  Switching to %d(default).\n",
-                    __func__, v->guest_paging_levels, new_paging_levels);
+
+            if ( verbosity >= 6 )
+                fprintf(warn, "%s: VMEXIT, but guest_paging_levels %d.  Switching to %d(default).\n",
+                        __func__, v->guest_paging_levels, new_paging_levels);
+
             v->guest_paging_levels = new_paging_levels;
         }
         h->rip = r->x32.eip;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 11:22:59 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 11:22:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLuNC-0003WK-8W; Wed, 10 Oct 2012 11:22:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLuNA-0003VM-JJ
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 11:22:44 +0000
Received: from [85.158.138.51:19142] by server-12.bemta-3.messagelabs.com id
	17/13-27853-38A55705; Wed, 10 Oct 2012 11:22:43 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1349868161!33903641!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODEzOTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4585 invoked from network); 10 Oct 2012 11:22:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 11:22:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="210832187"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 11:22:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 10 Oct 2012 07:22:39 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TLuN4-0003aC-M4;
	Wed, 10 Oct 2012 12:22:38 +0100
MIME-Version: 1.0
X-Mercurial-Node: 3230041f50a54889784121579604412fdc260228
Message-ID: <3230041f50a548897841.1349867849@elijah>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 10 Oct 2012 12:17:29 +0100
From: George Dunlap 
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 1 of 7] xenalyze: Add HVM_EVENT_VLAPIC
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User George Dunlap 
# Date 1349261311 -3600
# Node ID 3230041f50a54889784121579604412fdc260228
# Parent  4d47a8934b40556dd98428361c482be419c643be
xenalyze: Add HVM_EVENT_VLAPIC

Signed-off-by: George Dunlap 

diff --git a/xenalyze.c b/xenalyze.c
--- a/xenalyze.c
+++ b/xenalyze.c
@@ -958,6 +958,7 @@ enum {
     HVM_EVENT_REALMODE_EMULATE,
     HVM_EVENT_TRAP,
     HVM_EVENT_TRAP_DEBUG,
+    HVM_EVENT_VLAPIC,
     HVM_EVENT_HANDLER_MAX
 };
 char * hvm_event_handler_name[HVM_EVENT_HANDLER_MAX] = {
@@ -993,6 +994,7 @@ char * hvm_event_handler_name[HVM_EVENT_
     "realmode_emulate",
     "trap",
     "trap_debug",
+    "vlapic"
 };
 
 enum {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 11:22:59 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 11:22:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLuND-0003Ww-Eh; Wed, 10 Oct 2012 11:22:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLuNB-0003VV-Mf
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 11:22:45 +0000
Received: from [85.158.138.51:19267] by server-16.bemta-3.messagelabs.com id
	D5/57-02576-48A55705; Wed, 10 Oct 2012 11:22:44 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1349868159!27489693!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODEzOTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4358 invoked from network); 10 Oct 2012 11:22:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 11:22:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="210832190"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 11:22:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 10 Oct 2012 07:22:39 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TLuN4-0003aC-Nk;
	Wed, 10 Oct 2012 12:22:38 +0100
MIME-Version: 1.0
X-Mercurial-Node: 703cd2301a0a04934d30c7e4f7357df82ed12677
Message-ID: <703cd2301a0a04934d30.1349867854@elijah>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 10 Oct 2012 12:17:34 +0100
From: George Dunlap 
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 6 of 7] xenalyze: Handle 64-bit MMIO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User George Dunlap 
# Date 1349263139 -3600
# Node ID 703cd2301a0a04934d30c7e4f7357df82ed12677
# Parent  344f6609af3335e1e27ef55c686c57ff33402d46
xenalyze: Handle 64-bit MMIO

Also use "TRC_HVM_IOPORT_WRITE" rather than adding in the IO_ASSIST_WRITE flag.

Signed-off-by: George Dunlap 

diff --git a/xenalyze.c b/xenalyze.c
--- a/xenalyze.c
+++ b/xenalyze.c
@@ -4903,12 +4903,13 @@ needs_vmexit:
         hvm_pf_xen_process(ri, h);
         break;
     case TRC_HVM_IOPORT_READ:
-    case TRC_HVM_IOPORT_READ|HVM_IO_ASSIST_WRITE:
+    case TRC_HVM_IOPORT_WRITE:
         hvm_io_assist_process(ri, h);
         break;
     case TRC_HVM_IOMEM_READ:
-    case TRC_HVM_IOMEM_READ|HVM_IO_ASSIST_WRITE:
-        /* FIXME: 64-bit */
+    case TRC_HVM_IOMEM_WRITE:
+    case TRC_HVM_IOMEM_READ|TRC_64_FLAG:
+    case TRC_HVM_IOMEM_WRITE|TRC_64_FLAG:
         hvm_mmio_assist_process(ri, h);
         break;
     case TRC_HVM_CR_WRITE:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 11:22:59 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 11:22:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLuND-0003Ww-Eh; Wed, 10 Oct 2012 11:22:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLuNB-0003VV-Mf
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 11:22:45 +0000
Received: from [85.158.138.51:19267] by server-16.bemta-3.messagelabs.com id
	D5/57-02576-48A55705; Wed, 10 Oct 2012 11:22:44 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1349868159!27489693!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODEzOTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4358 invoked from network); 10 Oct 2012 11:22:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 11:22:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="210832190"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 11:22:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 10 Oct 2012 07:22:39 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TLuN4-0003aC-Nk;
	Wed, 10 Oct 2012 12:22:38 +0100
MIME-Version: 1.0
X-Mercurial-Node: 703cd2301a0a04934d30c7e4f7357df82ed12677
Message-ID: <703cd2301a0a04934d30.1349867854@elijah>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 10 Oct 2012 12:17:34 +0100
From: George Dunlap 
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 6 of 7] xenalyze: Handle 64-bit MMIO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User George Dunlap 
# Date 1349263139 -3600
# Node ID 703cd2301a0a04934d30c7e4f7357df82ed12677
# Parent  344f6609af3335e1e27ef55c686c57ff33402d46
xenalyze: Handle 64-bit MMIO

Also use "TRC_HVM_IOPORT_WRITE" rather than adding in the IO_ASSIST_WRITE flag.

Signed-off-by: George Dunlap 

diff --git a/xenalyze.c b/xenalyze.c
--- a/xenalyze.c
+++ b/xenalyze.c
@@ -4903,12 +4903,13 @@ needs_vmexit:
         hvm_pf_xen_process(ri, h);
         break;
     case TRC_HVM_IOPORT_READ:
-    case TRC_HVM_IOPORT_READ|HVM_IO_ASSIST_WRITE:
+    case TRC_HVM_IOPORT_WRITE:
         hvm_io_assist_process(ri, h);
         break;
     case TRC_HVM_IOMEM_READ:
-    case TRC_HVM_IOMEM_READ|HVM_IO_ASSIST_WRITE:
-        /* FIXME: 64-bit */
+    case TRC_HVM_IOMEM_WRITE:
+    case TRC_HVM_IOMEM_READ|TRC_64_FLAG:
+    case TRC_HVM_IOMEM_WRITE|TRC_64_FLAG:
         hvm_mmio_assist_process(ri, h);
         break;
     case TRC_HVM_CR_WRITE:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 11:22:59 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 11:22:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLuNB-0003Vn-GI; Wed, 10 Oct 2012 11:22:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLuN9-0003V8-Et
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 11:22:43 +0000
Received: from [85.158.138.51:19011] by server-14.bemta-3.messagelabs.com id
	D4/C7-17276-28A55705; Wed, 10 Oct 2012 11:22:42 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1349868159!27489693!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODEzOTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4161 invoked from network); 10 Oct 2012 11:22:42 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 11:22:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="210832185"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 11:22:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 10 Oct 2012 07:22:39 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TLuN4-0003aC-MN;
	Wed, 10 Oct 2012 12:22:38 +0100
MIME-Version: 1.0
X-Mercurial-Node: 4ea8fb7197ff3fad82b224a65cdfbe86db66d6ab
Message-ID: <4ea8fb7197ff3fad82b2.1349867850@elijah>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 10 Oct 2012 12:17:30 +0100
From: George Dunlap 
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 2 of 7] xenalyze: Process NPFs as generic for
	summary purposes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User George Dunlap 
# Date 1349261558 -3600
# Node ID 4ea8fb7197ff3fad82b224a65cdfbe86db66d6ab
# Parent  3230041f50a54889784121579604412fdc260228
xenalyze: Process NPFs as generic for summary purposes

Moves the "generic" post-processing initialization into a function,
and calls that function for NPF processes, so that we can get
summary information about NPF.

Signed-off-by: George Dunlap 

diff --git a/xenalyze.c b/xenalyze.c
--- a/xenalyze.c
+++ b/xenalyze.c
@@ -4640,6 +4640,8 @@ void hvm_pf_inject_process(struct record
     }
 }
 
+void hvm_generic_postprocess_init(struct record_info *ri, struct hvm_data *h);
+
 void hvm_npf_process(struct record_info *ri, struct hvm_data *h)
 {
     struct {
@@ -4654,6 +4656,9 @@ void hvm_npf_process(struct record_info 
                ri->dump_header,
                (unsigned long long)r->gpa, r->qualification,
                (unsigned long long)r->mfn, r->p2mt);
+
+    if ( opt.summary_info )
+        hvm_generic_postprocess_init(ri, h);
 }
 
 void hvm_rdtsc_process(struct record_info *ri, struct hvm_data *h)
@@ -4695,6 +4700,15 @@ void hvm_generic_summary(struct hvm_data
 
 }
 
+void hvm_generic_postprocess_init(struct record_info *ri, struct hvm_data *h)
+{
+    if ( h->post_process != hvm_generic_postprocess )
+        fprintf(warn, "%s: Strange, h->postprocess set!\n",
+                __func__);
+    h->inflight.generic.event = ri->event;
+    bcopy(h->d, h->inflight.generic.d, sizeof(unsigned int) * 4); 
+}
+
 void hvm_generic_postprocess(struct hvm_data *h)
 {
     long evt = 0;
@@ -4930,15 +4944,10 @@ needs_vmexit:
     case TRC_HVM_CR_READ:
     case TRC_HVM_CR_READ64:
     default:
-        if ( h->post_process != hvm_generic_postprocess )
-            fprintf(warn, "%s: Strange, h->postprocess set!\n",
-                __func__);
-        h->inflight.generic.event = ri->event;
-        bcopy(h->d, h->inflight.generic.d, sizeof(unsigned int) * 4); 
         if(opt.dump_all)
-        {
             hvm_generic_dump(ri, "]");
-        }
+        if(opt.summary_info)
+            hvm_generic_postprocess_init(ri, h);
         break;
     }
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 11:22:59 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 11:22:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLuNB-0003Vn-GI; Wed, 10 Oct 2012 11:22:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLuN9-0003V8-Et
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 11:22:43 +0000
Received: from [85.158.138.51:19011] by server-14.bemta-3.messagelabs.com id
	D4/C7-17276-28A55705; Wed, 10 Oct 2012 11:22:42 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1349868159!27489693!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODEzOTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4161 invoked from network); 10 Oct 2012 11:22:42 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 11:22:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="210832185"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 11:22:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 10 Oct 2012 07:22:39 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TLuN4-0003aC-MN;
	Wed, 10 Oct 2012 12:22:38 +0100
MIME-Version: 1.0
X-Mercurial-Node: 4ea8fb7197ff3fad82b224a65cdfbe86db66d6ab
Message-ID: <4ea8fb7197ff3fad82b2.1349867850@elijah>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 10 Oct 2012 12:17:30 +0100
From: George Dunlap 
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 2 of 7] xenalyze: Process NPFs as generic for
	summary purposes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User George Dunlap 
# Date 1349261558 -3600
# Node ID 4ea8fb7197ff3fad82b224a65cdfbe86db66d6ab
# Parent  3230041f50a54889784121579604412fdc260228
xenalyze: Process NPFs as generic for summary purposes

Moves the "generic" post-processing initialization into a function,
and calls that function for NPF processes, so that we can get
summary information about NPF.

Signed-off-by: George Dunlap 

diff --git a/xenalyze.c b/xenalyze.c
--- a/xenalyze.c
+++ b/xenalyze.c
@@ -4640,6 +4640,8 @@ void hvm_pf_inject_process(struct record
     }
 }
 
+void hvm_generic_postprocess_init(struct record_info *ri, struct hvm_data *h);
+
 void hvm_npf_process(struct record_info *ri, struct hvm_data *h)
 {
     struct {
@@ -4654,6 +4656,9 @@ void hvm_npf_process(struct record_info 
                ri->dump_header,
                (unsigned long long)r->gpa, r->qualification,
                (unsigned long long)r->mfn, r->p2mt);
+
+    if ( opt.summary_info )
+        hvm_generic_postprocess_init(ri, h);
 }
 
 void hvm_rdtsc_process(struct record_info *ri, struct hvm_data *h)
@@ -4695,6 +4700,15 @@ void hvm_generic_summary(struct hvm_data
 
 }
 
+void hvm_generic_postprocess_init(struct record_info *ri, struct hvm_data *h)
+{
+    if ( h->post_process != hvm_generic_postprocess )
+        fprintf(warn, "%s: Strange, h->postprocess set!\n",
+                __func__);
+    h->inflight.generic.event = ri->event;
+    bcopy(h->d, h->inflight.generic.d, sizeof(unsigned int) * 4); 
+}
+
 void hvm_generic_postprocess(struct hvm_data *h)
 {
     long evt = 0;
@@ -4930,15 +4944,10 @@ needs_vmexit:
     case TRC_HVM_CR_READ:
     case TRC_HVM_CR_READ64:
     default:
-        if ( h->post_process != hvm_generic_postprocess )
-            fprintf(warn, "%s: Strange, h->postprocess set!\n",
-                __func__);
-        h->inflight.generic.event = ri->event;
-        bcopy(h->d, h->inflight.generic.d, sizeof(unsigned int) * 4); 
         if(opt.dump_all)
-        {
             hvm_generic_dump(ri, "]");
-        }
+        if(opt.summary_info)
+            hvm_generic_postprocess_init(ri, h);
         break;
     }
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 11:22:59 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 11:22:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLuNB-0003W2-S2; Wed, 10 Oct 2012 11:22:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLuNA-0003VL-Cb
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 11:22:44 +0000
Received: from [85.158.138.51:33368] by server-9.bemta-3.messagelabs.com id
	A6/08-16841-38A55705; Wed, 10 Oct 2012 11:22:43 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1349868159!27489693!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODEzOTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4198 invoked from network); 10 Oct 2012 11:22:42 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 11:22:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="210832186"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 11:22:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 10 Oct 2012 07:22:39 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TLuN4-0003aC-N9;
	Wed, 10 Oct 2012 12:22:38 +0100
MIME-Version: 1.0
X-Mercurial-Node: 6e0e841283e5e68f03fe64d1c107942ab501846a
Message-ID: <6e0e841283e5e68f03fe.1349867852@elijah>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 10 Oct 2012 12:17:32 +0100
From: George Dunlap 
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 4 of 7] xenalyze: Make the warnigns in
 hvm_generic_postprocess more informative
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User George Dunlap 
# Date 1349262302 -3600
# Node ID 6e0e841283e5e68f03fe64d1c107942ab501846a
# Parent  3aad48bd6ca3213c598d16c307ba531dc45d6240
xenalyze: Make the warnigns in hvm_generic_postprocess more informative

Signed-off-by: George Dunlap 

diff --git a/xenalyze.c b/xenalyze.c
--- a/xenalyze.c
+++ b/xenalyze.c
@@ -4739,16 +4739,19 @@ void hvm_generic_postprocess(struct hvm_
         if ( !warned[h->exit_reason] )
         {
             /* If we aren't a known exception, warn and log results */
-            fprintf(warn, "%s: Strange, exit %x missing a handler\n",
-                    __func__, h->exit_reason);
+            fprintf(warn, "%s: Strange, exit %x(%s) missing a handler\n",
+                    __func__, h->exit_reason,
+                    (h->exit_reason > h->exit_reason_max)
+                      ? "[clipped]"
+                      : h->exit_reason_name[h->exit_reason]);
             warned[h->exit_reason]=1;
         }
     }
 
-    if ( evt > HVM_EVENT_HANDLER_MAX || evt < 0)
-    {
-        fprintf(warn, "%s: invalid hvm event %x\n",
-                __func__, h->inflight.generic.event);
+    if ( evt >= HVM_EVENT_HANDLER_MAX || evt < 0)
+    {
+        fprintf(warn, "%s: invalid hvm event %lx(%x)\n",
+                __func__, evt, h->inflight.generic.event);
         error(ERR_RECORD, NULL);
         return;
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 11:22:59 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 11:22:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLuNB-0003W2-S2; Wed, 10 Oct 2012 11:22:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLuNA-0003VL-Cb
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 11:22:44 +0000
Received: from [85.158.138.51:33368] by server-9.bemta-3.messagelabs.com id
	A6/08-16841-38A55705; Wed, 10 Oct 2012 11:22:43 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1349868159!27489693!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODEzOTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4198 invoked from network); 10 Oct 2012 11:22:42 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 11:22:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="210832186"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 11:22:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 10 Oct 2012 07:22:39 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TLuN4-0003aC-N9;
	Wed, 10 Oct 2012 12:22:38 +0100
MIME-Version: 1.0
X-Mercurial-Node: 6e0e841283e5e68f03fe64d1c107942ab501846a
Message-ID: <6e0e841283e5e68f03fe.1349867852@elijah>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 10 Oct 2012 12:17:32 +0100
From: George Dunlap 
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 4 of 7] xenalyze: Make the warnigns in
 hvm_generic_postprocess more informative
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User George Dunlap 
# Date 1349262302 -3600
# Node ID 6e0e841283e5e68f03fe64d1c107942ab501846a
# Parent  3aad48bd6ca3213c598d16c307ba531dc45d6240
xenalyze: Make the warnigns in hvm_generic_postprocess more informative

Signed-off-by: George Dunlap 

diff --git a/xenalyze.c b/xenalyze.c
--- a/xenalyze.c
+++ b/xenalyze.c
@@ -4739,16 +4739,19 @@ void hvm_generic_postprocess(struct hvm_
         if ( !warned[h->exit_reason] )
         {
             /* If we aren't a known exception, warn and log results */
-            fprintf(warn, "%s: Strange, exit %x missing a handler\n",
-                    __func__, h->exit_reason);
+            fprintf(warn, "%s: Strange, exit %x(%s) missing a handler\n",
+                    __func__, h->exit_reason,
+                    (h->exit_reason > h->exit_reason_max)
+                      ? "[clipped]"
+                      : h->exit_reason_name[h->exit_reason]);
             warned[h->exit_reason]=1;
         }
     }
 
-    if ( evt > HVM_EVENT_HANDLER_MAX || evt < 0)
-    {
-        fprintf(warn, "%s: invalid hvm event %x\n",
-                __func__, h->inflight.generic.event);
+    if ( evt >= HVM_EVENT_HANDLER_MAX || evt < 0)
+    {
+        fprintf(warn, "%s: invalid hvm event %lx(%x)\n",
+                __func__, evt, h->inflight.generic.event);
         error(ERR_RECORD, NULL);
         return;
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 11:23:00 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 11:23:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLuND-0003XD-RV; Wed, 10 Oct 2012 11:22:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLuNB-0003Va-Tj
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 11:22:46 +0000
Received: from [85.158.138.51:19300] by server-7.bemta-3.messagelabs.com id
	E1/53-06991-58A55705; Wed, 10 Oct 2012 11:22:45 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1349868161!33903641!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODEzOTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4956 invoked from network); 10 Oct 2012 11:22:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 11:22:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="210832191"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 11:22:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 10 Oct 2012 07:22:39 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TLuN4-0003aC-O3;
	Wed, 10 Oct 2012 12:22:38 +0100
MIME-Version: 1.0
X-Mercurial-Node: 393e0ead61a506f8bd1dea55ed7b3611ec4c7c1f
Message-ID: <393e0ead61a506f8bd1d.1349867855@elijah>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 10 Oct 2012 12:17:35 +0100
From: George Dunlap 
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 7 of 7] xenalyze: Analyze populate-on-demand
 reclamation patterns
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User George Dunlap 
# Date 1349264664 -3600
# Node ID 393e0ead61a506f8bd1dea55ed7b3611ec4c7c1f
# Parent  703cd2301a0a04934d30c7e4f7357df82ed12677
xenalyze: Analyze populate-on-demand reclamation patterns

This includes attempting to classify each reclamation to see if it was
the result of a fault or of ballooning, as well as tracking the order
of the pages reclaimed.

Signed-off-by: George Dunlap 

diff --git a/xenalyze.c b/xenalyze.c
--- a/xenalyze.c
+++ b/xenalyze.c
@@ -1723,6 +1723,21 @@ char * domain_runstate_name[] = {
     [DOMAIN_RUNSTATE_LOST]="lost",
 };
 
+enum {
+    POD_RECLAIM_CONTEXT_UNKNOWN=0,
+    POD_RECLAIM_CONTEXT_FAULT,
+    POD_RECLAIM_CONTEXT_BALLOON,
+    POD_RECLAIM_CONTEXT_MAX
+};
+
+char * pod_reclaim_context_name[] = {
+    [POD_RECLAIM_CONTEXT_UNKNOWN]="unknown",
+    [POD_RECLAIM_CONTEXT_FAULT]="fault",
+    [POD_RECLAIM_CONTEXT_BALLOON]="balloon",
+};
+
+#define POD_ORDER_MAX 4
+
 struct domain_data {
     struct domain_data *next;
     int did;
@@ -1747,6 +1762,14 @@ struct domain_data {
         int done_for[MEM_MAX];
         int done_for_interval[MEM_MAX];
     } memops;
+
+    struct {
+        int reclaim_order[POD_ORDER_MAX];
+        int reclaim_context[POD_RECLAIM_CONTEXT_MAX];
+        int reclaim_context_order[POD_RECLAIM_CONTEXT_MAX][POD_ORDER_MAX];
+        /* FIXME: Do a full cycle summary */
+        int populate_order[POD_ORDER_MAX];
+    } pod;
 };
 
 struct domain_data * domain_list=NULL;
@@ -7396,7 +7419,7 @@ void sched_process(struct pcpu_info *p)
 
 /* ---- Memory ---- */
 void mem_summary_domain(struct domain_data *d) {
-    int i;
+    int i, j;
 
     printf(" Grant table ops:\n");
 
@@ -7413,23 +7436,103 @@ void mem_summary_domain(struct domain_da
             printf("   %-14s: %d\n",
                    mem_name[i],
                    d->memops.done_for[i]);
+
+    printf(" Populate-on-demand:\n");
+    printf("  Populated:\n");
+    for(i=0; i<4; i++)
+    {
+        if ( d->pod.populate_order[i] )
+            printf("   [%d] %d\n", i,
+                   d->pod.populate_order[i]);
+    }
+    printf("  Reclaim order:\n");
+    for(i=0; i<4; i++)
+    {
+        if ( d->pod.reclaim_order[i] )
+            printf("   [%d] %d\n", i,
+                   d->pod.reclaim_order[i]);
+    }
+    printf("  Reclaim contexts:\n");
+    for(j=0; jpod.reclaim_context[j] )
+        {
+            printf("   * [%s] %d\n",
+                   pod_reclaim_context_name[j],
+                   d->pod.reclaim_context[j]);
+            for(i=0; i<4; i++)
+            {
+                if ( d->pod.reclaim_context_order[j][i] )
+                    printf("    [%d] %d\n", i,
+                           d->pod.reclaim_context_order[j][i]);
+            }
+        }
+    }
+}
+
+int p2m_canonical_order(int order)
+{
+    if ( order % 9
+         || (order / 9) > 2 )
+    {
+        fprintf(warn, "%s: Strange, non-canonical order %d\n",
+                __func__, order);
+        order = 4;
+    } else {
+        order /= 9;
+    }
+    return order;           
 }
 
 void mem_pod_zero_reclaim_process(struct pcpu_info *p)
 {
     struct record_info *ri = &p->ri;
+    int context = POD_RECLAIM_CONTEXT_UNKNOWN;
+    struct vcpu_data *v = p->current;
 
     struct {
         uint64_t gfn, mfn;
         int d:16,order:16;
     } *r = (typeof(r))ri->d;
 
+    if ( v && v->hvm.vmexit_valid )
+    {
+        switch(v->hvm.exit_reason)
+        {
+        case EXIT_REASON_EPT_VIOLATION:
+        case EXIT_REASON_EXCEPTION_NMI:
+            context = POD_RECLAIM_CONTEXT_FAULT;
+            break;
+        case EXIT_REASON_VMCALL:
+            context = POD_RECLAIM_CONTEXT_BALLOON;
+            break;
+        }
+    }
+
     if ( opt.dump_all )
     {
-        printf(" %s pod_zero_reclaim d%d o%d g %llx m %llx\n",
+        printf(" %s pod_zero_reclaim d%d o%d g %llx m %llx ctx %s\n",
                ri->dump_header,
                r->d, r->order,
-               (unsigned long long)r->gfn, (unsigned long long)r->mfn);
+               (unsigned long long)r->gfn, (unsigned long long)r->mfn,
+               pod_reclaim_context_name[context]);
+
+    }
+
+    if ( opt.summary_info )
+    {
+        struct domain_data *d;
+
+        if ( v && (d=v->d) )
+        {
+            int order;
+
+            order = p2m_canonical_order(r->order);
+
+            d->pod.reclaim_order[order]++;
+            d->pod.reclaim_context[context]++;
+            d->pod.reclaim_context_order[context][order]++;
+        }
     }
 }
 
@@ -7449,6 +7552,21 @@ void mem_pod_populate_process(struct pcp
                r->d, r->order,
                (unsigned long long)r->gfn, (unsigned long long)r->mfn);
     }
+
+    if ( opt.summary_info )
+    {
+        struct vcpu_data *v = p->current;
+        struct domain_data *d;
+
+        if ( v && (d=v->d) )
+        {
+            int order;
+
+            order = p2m_canonical_order(r->order);
+
+            d->pod.populate_order[order]++;
+        }        
+    }
 }
 
 void mem_pod_superpage_splinter_process(struct pcpu_info *p)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 11:23:00 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 11:23:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLuND-0003XD-RV; Wed, 10 Oct 2012 11:22:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLuNB-0003Va-Tj
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 11:22:46 +0000
Received: from [85.158.138.51:19300] by server-7.bemta-3.messagelabs.com id
	E1/53-06991-58A55705; Wed, 10 Oct 2012 11:22:45 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1349868161!33903641!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODEzOTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4956 invoked from network); 10 Oct 2012 11:22:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 11:22:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="210832191"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 11:22:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 10 Oct 2012 07:22:39 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TLuN4-0003aC-O3;
	Wed, 10 Oct 2012 12:22:38 +0100
MIME-Version: 1.0
X-Mercurial-Node: 393e0ead61a506f8bd1dea55ed7b3611ec4c7c1f
Message-ID: <393e0ead61a506f8bd1d.1349867855@elijah>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 10 Oct 2012 12:17:35 +0100
From: George Dunlap 
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 7 of 7] xenalyze: Analyze populate-on-demand
 reclamation patterns
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User George Dunlap 
# Date 1349264664 -3600
# Node ID 393e0ead61a506f8bd1dea55ed7b3611ec4c7c1f
# Parent  703cd2301a0a04934d30c7e4f7357df82ed12677
xenalyze: Analyze populate-on-demand reclamation patterns

This includes attempting to classify each reclamation to see if it was
the result of a fault or of ballooning, as well as tracking the order
of the pages reclaimed.

Signed-off-by: George Dunlap 

diff --git a/xenalyze.c b/xenalyze.c
--- a/xenalyze.c
+++ b/xenalyze.c
@@ -1723,6 +1723,21 @@ char * domain_runstate_name[] = {
     [DOMAIN_RUNSTATE_LOST]="lost",
 };
 
+enum {
+    POD_RECLAIM_CONTEXT_UNKNOWN=0,
+    POD_RECLAIM_CONTEXT_FAULT,
+    POD_RECLAIM_CONTEXT_BALLOON,
+    POD_RECLAIM_CONTEXT_MAX
+};
+
+char * pod_reclaim_context_name[] = {
+    [POD_RECLAIM_CONTEXT_UNKNOWN]="unknown",
+    [POD_RECLAIM_CONTEXT_FAULT]="fault",
+    [POD_RECLAIM_CONTEXT_BALLOON]="balloon",
+};
+
+#define POD_ORDER_MAX 4
+
 struct domain_data {
     struct domain_data *next;
     int did;
@@ -1747,6 +1762,14 @@ struct domain_data {
         int done_for[MEM_MAX];
         int done_for_interval[MEM_MAX];
     } memops;
+
+    struct {
+        int reclaim_order[POD_ORDER_MAX];
+        int reclaim_context[POD_RECLAIM_CONTEXT_MAX];
+        int reclaim_context_order[POD_RECLAIM_CONTEXT_MAX][POD_ORDER_MAX];
+        /* FIXME: Do a full cycle summary */
+        int populate_order[POD_ORDER_MAX];
+    } pod;
 };
 
 struct domain_data * domain_list=NULL;
@@ -7396,7 +7419,7 @@ void sched_process(struct pcpu_info *p)
 
 /* ---- Memory ---- */
 void mem_summary_domain(struct domain_data *d) {
-    int i;
+    int i, j;
 
     printf(" Grant table ops:\n");
 
@@ -7413,23 +7436,103 @@ void mem_summary_domain(struct domain_da
             printf("   %-14s: %d\n",
                    mem_name[i],
                    d->memops.done_for[i]);
+
+    printf(" Populate-on-demand:\n");
+    printf("  Populated:\n");
+    for(i=0; i<4; i++)
+    {
+        if ( d->pod.populate_order[i] )
+            printf("   [%d] %d\n", i,
+                   d->pod.populate_order[i]);
+    }
+    printf("  Reclaim order:\n");
+    for(i=0; i<4; i++)
+    {
+        if ( d->pod.reclaim_order[i] )
+            printf("   [%d] %d\n", i,
+                   d->pod.reclaim_order[i]);
+    }
+    printf("  Reclaim contexts:\n");
+    for(j=0; jpod.reclaim_context[j] )
+        {
+            printf("   * [%s] %d\n",
+                   pod_reclaim_context_name[j],
+                   d->pod.reclaim_context[j]);
+            for(i=0; i<4; i++)
+            {
+                if ( d->pod.reclaim_context_order[j][i] )
+                    printf("    [%d] %d\n", i,
+                           d->pod.reclaim_context_order[j][i]);
+            }
+        }
+    }
+}
+
+int p2m_canonical_order(int order)
+{
+    if ( order % 9
+         || (order / 9) > 2 )
+    {
+        fprintf(warn, "%s: Strange, non-canonical order %d\n",
+                __func__, order);
+        order = 4;
+    } else {
+        order /= 9;
+    }
+    return order;           
 }
 
 void mem_pod_zero_reclaim_process(struct pcpu_info *p)
 {
     struct record_info *ri = &p->ri;
+    int context = POD_RECLAIM_CONTEXT_UNKNOWN;
+    struct vcpu_data *v = p->current;
 
     struct {
         uint64_t gfn, mfn;
         int d:16,order:16;
     } *r = (typeof(r))ri->d;
 
+    if ( v && v->hvm.vmexit_valid )
+    {
+        switch(v->hvm.exit_reason)
+        {
+        case EXIT_REASON_EPT_VIOLATION:
+        case EXIT_REASON_EXCEPTION_NMI:
+            context = POD_RECLAIM_CONTEXT_FAULT;
+            break;
+        case EXIT_REASON_VMCALL:
+            context = POD_RECLAIM_CONTEXT_BALLOON;
+            break;
+        }
+    }
+
     if ( opt.dump_all )
     {
-        printf(" %s pod_zero_reclaim d%d o%d g %llx m %llx\n",
+        printf(" %s pod_zero_reclaim d%d o%d g %llx m %llx ctx %s\n",
                ri->dump_header,
                r->d, r->order,
-               (unsigned long long)r->gfn, (unsigned long long)r->mfn);
+               (unsigned long long)r->gfn, (unsigned long long)r->mfn,
+               pod_reclaim_context_name[context]);
+
+    }
+
+    if ( opt.summary_info )
+    {
+        struct domain_data *d;
+
+        if ( v && (d=v->d) )
+        {
+            int order;
+
+            order = p2m_canonical_order(r->order);
+
+            d->pod.reclaim_order[order]++;
+            d->pod.reclaim_context[context]++;
+            d->pod.reclaim_context_order[context][order]++;
+        }
     }
 }
 
@@ -7449,6 +7552,21 @@ void mem_pod_populate_process(struct pcp
                r->d, r->order,
                (unsigned long long)r->gfn, (unsigned long long)r->mfn);
     }
+
+    if ( opt.summary_info )
+    {
+        struct vcpu_data *v = p->current;
+        struct domain_data *d;
+
+        if ( v && (d=v->d) )
+        {
+            int order;
+
+            order = p2m_canonical_order(r->order);
+
+            d->pod.populate_order[order]++;
+        }        
+    }
 }
 
 void mem_pod_superpage_splinter_process(struct pcpu_info *p)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 11:23:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 11:23:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLuNA-0003VN-4L; Wed, 10 Oct 2012 11:22:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLuN8-0003V6-QW
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 11:22:43 +0000
Received: from [85.158.138.51:33186] by server-4.bemta-3.messagelabs.com id
	BA/56-01405-18A55705; Wed, 10 Oct 2012 11:22:41 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1349868159!27489693!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODEzOTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4116 invoked from network); 10 Oct 2012 11:22:41 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 11:22:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="210832184"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 11:22:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 10 Oct 2012 07:22:39 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TLuN4-0003aC-Lj;
	Wed, 10 Oct 2012 12:22:38 +0100
MIME-Version: 1.0
Message-ID: 
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 10 Oct 2012 12:17:28 +0100
From: George Dunlap 
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 0 of 7] Miscellaneous updates
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Clearing out my local queue of changes before applying other's.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 11:23:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 11:23:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLuNA-0003VN-4L; Wed, 10 Oct 2012 11:22:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLuN8-0003V6-QW
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 11:22:43 +0000
Received: from [85.158.138.51:33186] by server-4.bemta-3.messagelabs.com id
	BA/56-01405-18A55705; Wed, 10 Oct 2012 11:22:41 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1349868159!27489693!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODEzOTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4116 invoked from network); 10 Oct 2012 11:22:41 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 11:22:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="210832184"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 11:22:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 10 Oct 2012 07:22:39 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24] helo=[127.0.1.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TLuN4-0003aC-Lj;
	Wed, 10 Oct 2012 12:22:38 +0100
MIME-Version: 1.0
Message-ID: 
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 10 Oct 2012 12:17:28 +0100
From: George Dunlap 
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 0 of 7] Miscellaneous updates
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Clearing out my local queue of changes before applying other's.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 12:25:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 12:25:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLvLC-00056m-6v; Wed, 10 Oct 2012 12:24:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLvLA-00056h-F0
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 12:24:44 +0000
Received: from [85.158.143.99:27963] by server-3.bemta-4.messagelabs.com id
	5E/B1-10075-B0965705; Wed, 10 Oct 2012 12:24:43 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-14.tower-216.messagelabs.com!1349871882!23970956!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23929 invoked from network); 10 Oct 2012 12:24:42 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-14.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Oct 2012 12:24:42 -0000
Received: from 50-66-ftth.onsneteindhoven.nl ([88.159.66.50]:56001
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TLvML-000711-8b; Wed, 10 Oct 2012 14:25:57 +0200
Date: Wed, 10 Oct 2012 14:24:28 +0200
From: Sander Eikelenboom 
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1622789731.20121010142428@eikelenboom.it>
To: Ian Campbell 
In-Reply-To: <1349863984.10070.26.camel@zakaz.uk.xensource.com>
References: <1349790467.21847.185.camel@zakaz.uk.xensource.com>
	<1349790863.21172.4406.camel@edumazet-glaptop>
	<1349792241.21847.199.camel@zakaz.uk.xensource.com>
	<1349792847.21172.4479.camel@edumazet-glaptop>
	<1349793630.21847.208.camel@zakaz.uk.xensource.com>
	<1349863984.10070.26.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" ,
	Eric Dumazet , xen-devel ,
	Eric Dumazet ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] compound skb frag pages appearing in start_xmit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Wednesday, October 10, 2012, 12:13:04 PM, you wrote:

> On Tue, 2012-10-09 at 15:40 +0100, Ian Campbell wrote:
>> On Tue, 2012-10-09 at 15:27 +0100, Eric Dumazet wrote:
>> > On Tue, 2012-10-09 at 15:17 +0100, Ian Campbell wrote:
>> > 
>> > > Does the higher order pages effectively reduce the number of frags which
>> > > are in use? e.g if MAX_SKB_FRAGS is 16, then for order-0 pages you could
>> > > have 64K worth of frag data.
>> > > 
>> > > If we switch to order-3 pages everywhere then can the skb contain 512K
>> > > of data, or does the effective maximum number of frags in an skb reduce
>> > > to 2?
>> > 
>> > effective number of frags reduce to 2 or 3
>> > 
>> > (We still limit GSO packets to ~63536 bytes)
>> 
>> Great! Then I think the fix is more/less trivial...

> The following seems to work for me.

But it doesn't seem to work for me ... dmesg attached.

I don't know if the "mcelog:4359 map pfn expected mapping type write-back for [mem 0x0009f000-0x000a0fff], got uncached-minus"
is related, is shows up right after the nics get initialized ?

netback still fails with:

[  191.777994] ------------[ cut here ]------------
[  191.784245] kernel BUG at drivers/net/xen-netback/netback.c:481!
[  191.790423] invalid opcode: 0000 [#1] PREEMPT SMP 
[  191.796462] Modules linked in:
[  191.802315] CPU 1 
[  191.802367] Pid: 1177, comm: netback/1 Tainted: G        W    3.6.0pre-rc1-20121010 #1 MSI MS-7640/890FXA-GD70 (MS-7640)  
[  191.814043] RIP: e030:[]  [] netbk_gop_frag_copy+0x3f1/0x400
[  191.820171] RSP: e02b:ffff880037c6bb98  EFLAGS: 00010246
[  191.826271] RAX: 0000000000000244 RBX: ffffc90010827f98 RCX: ffff880031ed9880
[  191.832450] RDX: 00000000000000a8 RSI: ffff880037c6bd24 RDI: ffffea0000b03f80
[  191.838581] RBP: ffff880037c6bc28 R08: ffff8800319f8100 R09: 0000000000001000
[  191.844739] R10: 0000000000000000 R11: 0000000000000132 R12: 00000000000000a8
[  191.850785] R13: ffff880037c6bcd8 R14: 0000000000001000 R15: ffffc9001082cf70
[  191.856741] FS:  00007f9f3c944700(0000) GS:ffff88003f840000(0000) knlGS:0000000000000000
[  191.862841] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[  191.868901] CR2: 0000000001337ca0 CR3: 0000000032cec000 CR4: 0000000000000660
[  191.875053] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  191.881175] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  191.887247] Process netback/1 (pid: 1177, threadinfo ffff880037c6a000, task ffff880039984140)
[  191.893325] Stack:
[  191.899328]  ffff880037c6bd24 00000000000000a8 ffff8800319f8100 ffff880031ed9880
[  191.905534]  ffffc90000000000 0000000000001000 0000000000000000 0000000000000000
[  191.911742]  ffff880000000000 ffffffff817459f3 ffffc90010823420 ffffea0000b03f80
[  191.917898] Call Trace:
[  191.923939]  [] ? _raw_spin_unlock_irqrestore+0x53/0xa0
[  191.930141]  [] xen_netbk_rx_action+0x30b/0x830
[  191.936543]  [] ? trace_hardirqs_on+0xd/0x10
[  191.942942]  [] xen_netbk_kthread+0xba/0xa90
[  191.949147]  [] ? try_to_wake_up+0x1b6/0x310
[  191.955250]  [] ? wake_up_bit+0x40/0x40
[  191.961421]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
[  191.967660]  [] kthread+0xd6/0xe0
[  191.973834]  [] ? __init_kthread_worker+0x70/0x70
[  191.979953]  [] ret_from_fork+0x7c/0x90
[  191.986107]  [] ? __init_kthread_worker+0x70/0x70
[  191.992174] Code: b8 b3 00 00 48 8d 8c f1 60 01 00 00 48 3b 14 01 0f 85 72 fc ff ff e9 7a fc ff ff 0f 0b eb fe 0f 0b eb fe 0f 0b eb fe 0f 0b eb fe <0f> 0b eb fe 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 48 83 
[  192.005230] RIP  [] netbk_gop_frag_copy+0x3f1/0x400
[  192.011786]  RSP 
[  192.018402] ---[ end trace c51ab5e2c2c918fc ]---


--

Sander

> I haven't tackled netfront yet.

> 8<--------------------------------------------------------------

> From 551e42e3dd203f2eb97cb082985013bb33b8f020 Mon Sep 17 00:00:00 2001
> From: Ian Campbell 
> Date: Tue, 9 Oct 2012 15:51:20 +0100
> Subject: [PATCH] xen: netback: handle compound page fragments on transmit.

> An SKB paged fragment can consist of a compound page with order > 0.
> However the netchannel protocol deals only in PAGE_SIZE frames.

> Handle this in netbk_gop_frag_copy and xen_netbk_count_skb_slots by
> iterating over the frames which make up the page.

> Signed-off-by: Ian Campbell 
> Cc: Eric Dumazet 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Sander Eikelenboom 
> ---
>  drivers/net/xen-netback/netback.c |   40 ++++++++++++++++++++++++++++++++----
>  1 files changed, 35 insertions(+), 5 deletions(-)

> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index 4ebfcf3..d747e30 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -335,21 +335,35 @@ unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb)
>  
>         for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
>                 unsigned long size = skb_frag_size(&skb_shinfo(skb)->frags[i]);
> +               unsigned long offset = skb_shinfo(skb)->frags[i].page_offset;
>                 unsigned long bytes;
> +
> +               offset &= ~PAGE_MASK;
> +
>                 while (size > 0) {
> +                       BUG_ON(offset >= PAGE_SIZE);
>                         BUG_ON(copy_off > MAX_BUFFER_OFFSET);
>  
> -                       if (start_new_rx_buffer(copy_off, size, 0)) {
> +                       bytes = PAGE_SIZE - offset;
> +
> +                       if (bytes > size)
> +                               bytes = size;
> +
> +                       if (start_new_rx_buffer(copy_off, bytes, 0)) {
>                                 count++;
>                                 copy_off = 0;
>                         }
>  
> -                       bytes = size;
>                         if (copy_off + bytes > MAX_BUFFER_OFFSET)
>                                 bytes = MAX_BUFFER_OFFSET - copy_off;
>  
>                         copy_off += bytes;
> +
> +                       offset += bytes;
>                         size -= bytes;
> +
> +                       if (offset == PAGE_SIZE)
> +                               offset = 0;
>                 }
>         }
>         return count;
> @@ -403,14 +417,24 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
>         unsigned long bytes;
>  
>         /* Data must not cross a page boundary. */
> -       BUG_ON(size + offset > PAGE_SIZE);
> +       BUG_ON(size + offset > PAGE_SIZE<  
>         meta = npo->meta + npo->meta_prod - 1;
>  
> +       /* Skip unused frames from start of page */
> +       page += offset >> PAGE_SHIFT;
> +       offset &= ~PAGE_MASK;
> +
>         while (size > 0) {
> +               BUG_ON(offset >= PAGE_SIZE);
>                 BUG_ON(npo->copy_off > MAX_BUFFER_OFFSET);
>  
> -               if (start_new_rx_buffer(npo->copy_off, size, *head)) {
> +               bytes = PAGE_SIZE - offset;
> +
> +               if (bytes > size)
> +                       bytes = size;
> +
> +               if (start_new_rx_buffer(npo->copy_off, bytes, *head)) {
>                         /*
>                          * Netfront requires there to be some data in the head
>                          * buffer.
> @@ -420,7 +444,6 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
>                         meta = get_next_rx_buffer(vif, npo);
>                 }
>  
> -               bytes = size;
>                 if (npo->copy_off + bytes > MAX_BUFFER_OFFSET)
>                         bytes = MAX_BUFFER_OFFSET - npo->copy_off;
>  
> @@ -453,6 +476,13 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
>                 offset += bytes;
>                 size -= bytes;
>  
> +               /* Next frame */
> +               if (offset == PAGE_SIZE) {
> +                       BUG_ON(!PageCompound(page));
> +                       page++;
> +                       offset = 0;
> +               }
> +
>                 /* Leave a gap for the GSO descriptor. */
>                 if (*head && skb_shinfo(skb)->gso_size && !vif->gso_prefix)
>                         vif->rx.req_cons++;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 12:25:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 12:25:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLvLC-00056m-6v; Wed, 10 Oct 2012 12:24:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLvLA-00056h-F0
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 12:24:44 +0000
Received: from [85.158.143.99:27963] by server-3.bemta-4.messagelabs.com id
	5E/B1-10075-B0965705; Wed, 10 Oct 2012 12:24:43 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-14.tower-216.messagelabs.com!1349871882!23970956!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23929 invoked from network); 10 Oct 2012 12:24:42 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-14.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Oct 2012 12:24:42 -0000
Received: from 50-66-ftth.onsneteindhoven.nl ([88.159.66.50]:56001
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TLvML-000711-8b; Wed, 10 Oct 2012 14:25:57 +0200
Date: Wed, 10 Oct 2012 14:24:28 +0200
From: Sander Eikelenboom 
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1622789731.20121010142428@eikelenboom.it>
To: Ian Campbell 
In-Reply-To: <1349863984.10070.26.camel@zakaz.uk.xensource.com>
References: <1349790467.21847.185.camel@zakaz.uk.xensource.com>
	<1349790863.21172.4406.camel@edumazet-glaptop>
	<1349792241.21847.199.camel@zakaz.uk.xensource.com>
	<1349792847.21172.4479.camel@edumazet-glaptop>
	<1349793630.21847.208.camel@zakaz.uk.xensource.com>
	<1349863984.10070.26.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" ,
	Eric Dumazet , xen-devel ,
	Eric Dumazet ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] compound skb frag pages appearing in start_xmit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Wednesday, October 10, 2012, 12:13:04 PM, you wrote:

> On Tue, 2012-10-09 at 15:40 +0100, Ian Campbell wrote:
>> On Tue, 2012-10-09 at 15:27 +0100, Eric Dumazet wrote:
>> > On Tue, 2012-10-09 at 15:17 +0100, Ian Campbell wrote:
>> > 
>> > > Does the higher order pages effectively reduce the number of frags which
>> > > are in use? e.g if MAX_SKB_FRAGS is 16, then for order-0 pages you could
>> > > have 64K worth of frag data.
>> > > 
>> > > If we switch to order-3 pages everywhere then can the skb contain 512K
>> > > of data, or does the effective maximum number of frags in an skb reduce
>> > > to 2?
>> > 
>> > effective number of frags reduce to 2 or 3
>> > 
>> > (We still limit GSO packets to ~63536 bytes)
>> 
>> Great! Then I think the fix is more/less trivial...

> The following seems to work for me.

But it doesn't seem to work for me ... dmesg attached.

I don't know if the "mcelog:4359 map pfn expected mapping type write-back for [mem 0x0009f000-0x000a0fff], got uncached-minus"
is related, is shows up right after the nics get initialized ?

netback still fails with:

[  191.777994] ------------[ cut here ]------------
[  191.784245] kernel BUG at drivers/net/xen-netback/netback.c:481!
[  191.790423] invalid opcode: 0000 [#1] PREEMPT SMP 
[  191.796462] Modules linked in:
[  191.802315] CPU 1 
[  191.802367] Pid: 1177, comm: netback/1 Tainted: G        W    3.6.0pre-rc1-20121010 #1 MSI MS-7640/890FXA-GD70 (MS-7640)  
[  191.814043] RIP: e030:[]  [] netbk_gop_frag_copy+0x3f1/0x400
[  191.820171] RSP: e02b:ffff880037c6bb98  EFLAGS: 00010246
[  191.826271] RAX: 0000000000000244 RBX: ffffc90010827f98 RCX: ffff880031ed9880
[  191.832450] RDX: 00000000000000a8 RSI: ffff880037c6bd24 RDI: ffffea0000b03f80
[  191.838581] RBP: ffff880037c6bc28 R08: ffff8800319f8100 R09: 0000000000001000
[  191.844739] R10: 0000000000000000 R11: 0000000000000132 R12: 00000000000000a8
[  191.850785] R13: ffff880037c6bcd8 R14: 0000000000001000 R15: ffffc9001082cf70
[  191.856741] FS:  00007f9f3c944700(0000) GS:ffff88003f840000(0000) knlGS:0000000000000000
[  191.862841] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[  191.868901] CR2: 0000000001337ca0 CR3: 0000000032cec000 CR4: 0000000000000660
[  191.875053] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  191.881175] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  191.887247] Process netback/1 (pid: 1177, threadinfo ffff880037c6a000, task ffff880039984140)
[  191.893325] Stack:
[  191.899328]  ffff880037c6bd24 00000000000000a8 ffff8800319f8100 ffff880031ed9880
[  191.905534]  ffffc90000000000 0000000000001000 0000000000000000 0000000000000000
[  191.911742]  ffff880000000000 ffffffff817459f3 ffffc90010823420 ffffea0000b03f80
[  191.917898] Call Trace:
[  191.923939]  [] ? _raw_spin_unlock_irqrestore+0x53/0xa0
[  191.930141]  [] xen_netbk_rx_action+0x30b/0x830
[  191.936543]  [] ? trace_hardirqs_on+0xd/0x10
[  191.942942]  [] xen_netbk_kthread+0xba/0xa90
[  191.949147]  [] ? try_to_wake_up+0x1b6/0x310
[  191.955250]  [] ? wake_up_bit+0x40/0x40
[  191.961421]  [] ? xen_netbk_tx_build_gops+0xa70/0xa70
[  191.967660]  [] kthread+0xd6/0xe0
[  191.973834]  [] ? __init_kthread_worker+0x70/0x70
[  191.979953]  [] ret_from_fork+0x7c/0x90
[  191.986107]  [] ? __init_kthread_worker+0x70/0x70
[  191.992174] Code: b8 b3 00 00 48 8d 8c f1 60 01 00 00 48 3b 14 01 0f 85 72 fc ff ff e9 7a fc ff ff 0f 0b eb fe 0f 0b eb fe 0f 0b eb fe 0f 0b eb fe <0f> 0b eb fe 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 48 83 
[  192.005230] RIP  [] netbk_gop_frag_copy+0x3f1/0x400
[  192.011786]  RSP 
[  192.018402] ---[ end trace c51ab5e2c2c918fc ]---


--

Sander

> I haven't tackled netfront yet.

> 8<--------------------------------------------------------------

> From 551e42e3dd203f2eb97cb082985013bb33b8f020 Mon Sep 17 00:00:00 2001
> From: Ian Campbell 
> Date: Tue, 9 Oct 2012 15:51:20 +0100
> Subject: [PATCH] xen: netback: handle compound page fragments on transmit.

> An SKB paged fragment can consist of a compound page with order > 0.
> However the netchannel protocol deals only in PAGE_SIZE frames.

> Handle this in netbk_gop_frag_copy and xen_netbk_count_skb_slots by
> iterating over the frames which make up the page.

> Signed-off-by: Ian Campbell 
> Cc: Eric Dumazet 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Sander Eikelenboom 
> ---
>  drivers/net/xen-netback/netback.c |   40 ++++++++++++++++++++++++++++++++----
>  1 files changed, 35 insertions(+), 5 deletions(-)

> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index 4ebfcf3..d747e30 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -335,21 +335,35 @@ unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb)
>  
>         for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
>                 unsigned long size = skb_frag_size(&skb_shinfo(skb)->frags[i]);
> +               unsigned long offset = skb_shinfo(skb)->frags[i].page_offset;
>                 unsigned long bytes;
> +
> +               offset &= ~PAGE_MASK;
> +
>                 while (size > 0) {
> +                       BUG_ON(offset >= PAGE_SIZE);
>                         BUG_ON(copy_off > MAX_BUFFER_OFFSET);
>  
> -                       if (start_new_rx_buffer(copy_off, size, 0)) {
> +                       bytes = PAGE_SIZE - offset;
> +
> +                       if (bytes > size)
> +                               bytes = size;
> +
> +                       if (start_new_rx_buffer(copy_off, bytes, 0)) {
>                                 count++;
>                                 copy_off = 0;
>                         }
>  
> -                       bytes = size;
>                         if (copy_off + bytes > MAX_BUFFER_OFFSET)
>                                 bytes = MAX_BUFFER_OFFSET - copy_off;
>  
>                         copy_off += bytes;
> +
> +                       offset += bytes;
>                         size -= bytes;
> +
> +                       if (offset == PAGE_SIZE)
> +                               offset = 0;
>                 }
>         }
>         return count;
> @@ -403,14 +417,24 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
>         unsigned long bytes;
>  
>         /* Data must not cross a page boundary. */
> -       BUG_ON(size + offset > PAGE_SIZE);
> +       BUG_ON(size + offset > PAGE_SIZE<  
>         meta = npo->meta + npo->meta_prod - 1;
>  
> +       /* Skip unused frames from start of page */
> +       page += offset >> PAGE_SHIFT;
> +       offset &= ~PAGE_MASK;
> +
>         while (size > 0) {
> +               BUG_ON(offset >= PAGE_SIZE);
>                 BUG_ON(npo->copy_off > MAX_BUFFER_OFFSET);
>  
> -               if (start_new_rx_buffer(npo->copy_off, size, *head)) {
> +               bytes = PAGE_SIZE - offset;
> +
> +               if (bytes > size)
> +                       bytes = size;
> +
> +               if (start_new_rx_buffer(npo->copy_off, bytes, *head)) {
>                         /*
>                          * Netfront requires there to be some data in the head
>                          * buffer.
> @@ -420,7 +444,6 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
>                         meta = get_next_rx_buffer(vif, npo);
>                 }
>  
> -               bytes = size;
>                 if (npo->copy_off + bytes > MAX_BUFFER_OFFSET)
>                         bytes = MAX_BUFFER_OFFSET - npo->copy_off;
>  
> @@ -453,6 +476,13 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
>                 offset += bytes;
>                 size -= bytes;
>  
> +               /* Next frame */
> +               if (offset == PAGE_SIZE) {
> +                       BUG_ON(!PageCompound(page));
> +                       page++;
> +                       offset = 0;
> +               }
> +
>                 /* Leave a gap for the GSO descriptor. */
>                 if (*head && skb_shinfo(skb)->gso_size && !vif->gso_prefix)
>                         vif->rx.req_cons++;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 12:29:00 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 12:29:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLvOq-0005DV-TL; Wed, 10 Oct 2012 12:28:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLvOp-0005DP-HU
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 12:28:31 +0000
Received: from [85.158.139.211:51165] by server-16.bemta-5.messagelabs.com id
	9A/4E-10155-EE965705; Wed, 10 Oct 2012 12:28:30 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1349872109!20275160!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM3MzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9637 invoked from network); 10 Oct 2012 12:28:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 12:28:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; 
	d="asc'?scan'208";a="15073820"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 12:28:29 +0000
Received: from [IPv6:::1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 10 Oct 2012 13:28:29 +0100
Message-ID: <1349872108.3610.187.camel@Abyss>
From: Dario Faggioli 
To: George Dunlap 
Date: Wed, 10 Oct 2012 13:28:28 +0100
In-Reply-To: 
References: 
	
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
MIME-Version: 1.0
Cc: Marcus Granado ,
	Andre Przywara ,
	Ian Campbell , Anil
	Madhavapeddy , Andrew Cooper ,
	Juergen Gross ,
	Ian Jackson ,
	"xen-devel@lists.xen.org" ,
	Jan Beulich , Daniel De Graaf ,
	Matt Wilson 
Subject: Re: [Xen-devel] [PATCH 0 of 8] NUMA Awareness for the Credit
 Scheduler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============4012247455124123335=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4012247455124123335==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-fwcg0Kmo+eGuuz4T/5fI"

--=-fwcg0Kmo+eGuuz4T/5fI
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-10-10 at 12:00 +0100, George Dunlap wrote:=20
> On Fri, Oct 5, 2012 at 3:08 PM, Dario Faggioli
>  wrote:
> > Hi Everyone,
> >
> > Here it comes a patch series instilling some NUMA awareness in the Cred=
it
> > scheduler.
>=20
> Hey Dario --
>
Hi!

> I've looked through everything and acked everything I
> felt I understood well enough / had the authority to ack.
>
Yep, I've seen that. Thanks.

> Thanks for
> the good work!
>=20
Well, thanks to you for the good comments... And be prepared for next
round! :-P

Regards,
Dario

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-fwcg0Kmo+eGuuz4T/5fI
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlB1aewACgkQk4XaBE3IOsRfmwCgk5lyi6BFFrC8aQ9gadikiO+A
nIAAnjhkwpsV+y/pe5Zh+d9lxCdlO2jU
=YjLO
-----END PGP SIGNATURE-----

--=-fwcg0Kmo+eGuuz4T/5fI--


--===============4012247455124123335==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4012247455124123335==--


From xen-devel-bounces@lists.xen.org Wed Oct 10 12:29:00 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 12:29:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLvOq-0005DV-TL; Wed, 10 Oct 2012 12:28:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLvOp-0005DP-HU
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 12:28:31 +0000
Received: from [85.158.139.211:51165] by server-16.bemta-5.messagelabs.com id
	9A/4E-10155-EE965705; Wed, 10 Oct 2012 12:28:30 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1349872109!20275160!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM3MzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9637 invoked from network); 10 Oct 2012 12:28:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 12:28:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; 
	d="asc'?scan'208";a="15073820"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 12:28:29 +0000
Received: from [IPv6:::1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 10 Oct 2012 13:28:29 +0100
Message-ID: <1349872108.3610.187.camel@Abyss>
From: Dario Faggioli 
To: George Dunlap 
Date: Wed, 10 Oct 2012 13:28:28 +0100
In-Reply-To: 
References: 
	
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
MIME-Version: 1.0
Cc: Marcus Granado ,
	Andre Przywara ,
	Ian Campbell , Anil
	Madhavapeddy , Andrew Cooper ,
	Juergen Gross ,
	Ian Jackson ,
	"xen-devel@lists.xen.org" ,
	Jan Beulich , Daniel De Graaf ,
	Matt Wilson 
Subject: Re: [Xen-devel] [PATCH 0 of 8] NUMA Awareness for the Credit
 Scheduler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============4012247455124123335=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4012247455124123335==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-fwcg0Kmo+eGuuz4T/5fI"

--=-fwcg0Kmo+eGuuz4T/5fI
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-10-10 at 12:00 +0100, George Dunlap wrote:=20
> On Fri, Oct 5, 2012 at 3:08 PM, Dario Faggioli
>  wrote:
> > Hi Everyone,
> >
> > Here it comes a patch series instilling some NUMA awareness in the Cred=
it
> > scheduler.
>=20
> Hey Dario --
>
Hi!

> I've looked through everything and acked everything I
> felt I understood well enough / had the authority to ack.
>
Yep, I've seen that. Thanks.

> Thanks for
> the good work!
>=20
Well, thanks to you for the good comments... And be prepared for next
round! :-P

Regards,
Dario

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-fwcg0Kmo+eGuuz4T/5fI
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlB1aewACgkQk4XaBE3IOsRfmwCgk5lyi6BFFrC8aQ9gadikiO+A
nIAAnjhkwpsV+y/pe5Zh+d9lxCdlO2jU
=YjLO
-----END PGP SIGNATURE-----

--=-fwcg0Kmo+eGuuz4T/5fI--


--===============4012247455124123335==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4012247455124123335==--


From xen-devel-bounces@lists.xen.org Wed Oct 10 12:30:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 12:30:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLvPz-0005I2-Bi; Wed, 10 Oct 2012 12:29:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLvPy-0005Hw-Kk
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 12:29:42 +0000
Received: from [85.158.139.83:43893] by server-13.bemta-5.messagelabs.com id
	DE/5C-29905-53A65705; Wed, 10 Oct 2012 12:29:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1349872180!28625534!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM3MzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4314 invoked from network); 10 Oct 2012 12:29:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 12:29:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="15073845"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 12:29:10 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 10 Oct 2012 13:29:10 +0100
Message-ID: <1349872149.10070.31.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Sander Eikelenboom 
Date: Wed, 10 Oct 2012 13:29:09 +0100
In-Reply-To: <1622789731.20121010142428@eikelenboom.it>
References: <1349790467.21847.185.camel@zakaz.uk.xensource.com>
	<1349790863.21172.4406.camel@edumazet-glaptop>
	<1349792241.21847.199.camel@zakaz.uk.xensource.com>
	<1349792847.21172.4479.camel@edumazet-glaptop>
	<1349793630.21847.208.camel@zakaz.uk.xensource.com>
	<1349863984.10070.26.camel@zakaz.uk.xensource.com>
	<1622789731.20121010142428@eikelenboom.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" ,
	Eric Dumazet , xen-devel ,
	Eric Dumazet , Konrad
	Rzeszutek Wilk 
Subject: Re: [Xen-devel] compound skb frag pages appearing in start_xmit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-10 at 13:24 +0100, Sander Eikelenboom wrote:
> Wednesday, October 10, 2012, 12:13:04 PM, you wrote:
> 
> > On Tue, 2012-10-09 at 15:40 +0100, Ian Campbell wrote:
> >> On Tue, 2012-10-09 at 15:27 +0100, Eric Dumazet wrote:
> >> > On Tue, 2012-10-09 at 15:17 +0100, Ian Campbell wrote:
> >> > 
> >> > > Does the higher order pages effectively reduce the number of frags which
> >> > > are in use? e.g if MAX_SKB_FRAGS is 16, then for order-0 pages you could
> >> > > have 64K worth of frag data.
> >> > > 
> >> > > If we switch to order-3 pages everywhere then can the skb contain 512K
> >> > > of data, or does the effective maximum number of frags in an skb reduce
> >> > > to 2?
> >> > 
> >> > effective number of frags reduce to 2 or 3
> >> > 
> >> > (We still limit GSO packets to ~63536 bytes)
> >> 
> >> Great! Then I think the fix is more/less trivial...
> 
> > The following seems to work for me.
> 
> But it doesn't seem to work for me ... dmesg attached.

> [  191.777994] ------------[ cut here ]------------
> [  191.784245] kernel BUG at drivers/net/xen-netback/netback.c:481!

Looks like that BUG_ON is a little aggressive. It'll trigger if the data
happens to end on a frame boundary. Hopefully this will fix it for you:

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index d747e30..f2d6b78 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -477,7 +477,7 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 		size -= bytes;
 
 		/* Next frame */
-		if (offset == PAGE_SIZE) {
+		if (offset == PAGE_SIZE && size) {
 			BUG_ON(!PageCompound(page));
 			page++;
 			offset = 0;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 12:30:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 12:30:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLvPz-0005I2-Bi; Wed, 10 Oct 2012 12:29:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLvPy-0005Hw-Kk
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 12:29:42 +0000
Received: from [85.158.139.83:43893] by server-13.bemta-5.messagelabs.com id
	DE/5C-29905-53A65705; Wed, 10 Oct 2012 12:29:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1349872180!28625534!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM3MzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4314 invoked from network); 10 Oct 2012 12:29:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 12:29:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="15073845"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 12:29:10 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 10 Oct 2012 13:29:10 +0100
Message-ID: <1349872149.10070.31.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Sander Eikelenboom 
Date: Wed, 10 Oct 2012 13:29:09 +0100
In-Reply-To: <1622789731.20121010142428@eikelenboom.it>
References: <1349790467.21847.185.camel@zakaz.uk.xensource.com>
	<1349790863.21172.4406.camel@edumazet-glaptop>
	<1349792241.21847.199.camel@zakaz.uk.xensource.com>
	<1349792847.21172.4479.camel@edumazet-glaptop>
	<1349793630.21847.208.camel@zakaz.uk.xensource.com>
	<1349863984.10070.26.camel@zakaz.uk.xensource.com>
	<1622789731.20121010142428@eikelenboom.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" ,
	Eric Dumazet , xen-devel ,
	Eric Dumazet , Konrad
	Rzeszutek Wilk 
Subject: Re: [Xen-devel] compound skb frag pages appearing in start_xmit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-10 at 13:24 +0100, Sander Eikelenboom wrote:
> Wednesday, October 10, 2012, 12:13:04 PM, you wrote:
> 
> > On Tue, 2012-10-09 at 15:40 +0100, Ian Campbell wrote:
> >> On Tue, 2012-10-09 at 15:27 +0100, Eric Dumazet wrote:
> >> > On Tue, 2012-10-09 at 15:17 +0100, Ian Campbell wrote:
> >> > 
> >> > > Does the higher order pages effectively reduce the number of frags which
> >> > > are in use? e.g if MAX_SKB_FRAGS is 16, then for order-0 pages you could
> >> > > have 64K worth of frag data.
> >> > > 
> >> > > If we switch to order-3 pages everywhere then can the skb contain 512K
> >> > > of data, or does the effective maximum number of frags in an skb reduce
> >> > > to 2?
> >> > 
> >> > effective number of frags reduce to 2 or 3
> >> > 
> >> > (We still limit GSO packets to ~63536 bytes)
> >> 
> >> Great! Then I think the fix is more/less trivial...
> 
> > The following seems to work for me.
> 
> But it doesn't seem to work for me ... dmesg attached.

> [  191.777994] ------------[ cut here ]------------
> [  191.784245] kernel BUG at drivers/net/xen-netback/netback.c:481!

Looks like that BUG_ON is a little aggressive. It'll trigger if the data
happens to end on a frame boundary. Hopefully this will fix it for you:

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index d747e30..f2d6b78 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -477,7 +477,7 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 		size -= bytes;
 
 		/* Next frame */
-		if (offset == PAGE_SIZE) {
+		if (offset == PAGE_SIZE && size) {
 			BUG_ON(!PageCompound(page));
 			page++;
 			offset = 0;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 13:10:23 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 13:10:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLw30-00063e-IJ; Wed, 10 Oct 2012 13:10:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLw2z-00063U-65
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 13:10:01 +0000
Received: from [85.158.139.211:22555] by server-11.bemta-5.messagelabs.com id
	C3/55-15507-8A375705; Wed, 10 Oct 2012 13:10:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1349874599!21820821!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM3MzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21023 invoked from network); 10 Oct 2012 13:10:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 13:10:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="15075181"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 13:09:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 10 Oct 2012 14:09:59 +0100
Message-ID: <1349874598.10070.39.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Eric Dumazet 
Date: Wed, 10 Oct 2012 14:09:58 +0100
In-Reply-To: <1349863984.10070.26.camel@zakaz.uk.xensource.com>
References: <1349790467.21847.185.camel@zakaz.uk.xensource.com>
	<1349790863.21172.4406.camel@edumazet-glaptop>
	<1349792241.21847.199.camel@zakaz.uk.xensource.com>
	<1349792847.21172.4479.camel@edumazet-glaptop>
	<1349793630.21847.208.camel@zakaz.uk.xensource.com>
	<1349863984.10070.26.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" ,
	Eric Dumazet ,
	Sander Eikelenboom , Konrad
	Rzeszutek Wilk , xen-devel 
Subject: Re: [Xen-devel] compound skb frag pages appearing in start_xmit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-10 at 11:13 +0100, Ian Campbell wrote:
> I haven't tackled netfront yet. 

I seem to be totally unable to reproduce the equivalent issue on the
netfront xmit side, even though it seems like the loop in
xennet_make_frags ought to be obviously susceptible to it.

Konrad, Sander, are either of you able to repro, e.g. with:

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index b06ef81..8a3f770 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -462,6 +462,8 @@ static void xennet_make_frags(struct sk_buff *skb, struct net_device *dev,
 		ref = gnttab_claim_grant_reference(&np->gref_tx_head);
 		BUG_ON((signed short)ref < 0);
 
+		BUG_ON(PageCompound(skb_frag_page(frag)));
+
 		mfn = pfn_to_mfn(page_to_pfn(skb_frag_page(frag)));
 		gnttab_grant_foreign_access_ref(ref, np->xbdev->otherend_id,
 						mfn, GNTMAP_readonly);

My repro for netback was just to netcat a wodge of data from dom0->domU
but going the other way doesn't seem to trigger.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 13:10:23 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 13:10:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLw30-00063e-IJ; Wed, 10 Oct 2012 13:10:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLw2z-00063U-65
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 13:10:01 +0000
Received: from [85.158.139.211:22555] by server-11.bemta-5.messagelabs.com id
	C3/55-15507-8A375705; Wed, 10 Oct 2012 13:10:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1349874599!21820821!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM3MzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21023 invoked from network); 10 Oct 2012 13:10:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 13:10:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="15075181"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 13:09:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 10 Oct 2012 14:09:59 +0100
Message-ID: <1349874598.10070.39.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Eric Dumazet 
Date: Wed, 10 Oct 2012 14:09:58 +0100
In-Reply-To: <1349863984.10070.26.camel@zakaz.uk.xensource.com>
References: <1349790467.21847.185.camel@zakaz.uk.xensource.com>
	<1349790863.21172.4406.camel@edumazet-glaptop>
	<1349792241.21847.199.camel@zakaz.uk.xensource.com>
	<1349792847.21172.4479.camel@edumazet-glaptop>
	<1349793630.21847.208.camel@zakaz.uk.xensource.com>
	<1349863984.10070.26.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" ,
	Eric Dumazet ,
	Sander Eikelenboom , Konrad
	Rzeszutek Wilk , xen-devel 
Subject: Re: [Xen-devel] compound skb frag pages appearing in start_xmit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-10 at 11:13 +0100, Ian Campbell wrote:
> I haven't tackled netfront yet. 

I seem to be totally unable to reproduce the equivalent issue on the
netfront xmit side, even though it seems like the loop in
xennet_make_frags ought to be obviously susceptible to it.

Konrad, Sander, are either of you able to repro, e.g. with:

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index b06ef81..8a3f770 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -462,6 +462,8 @@ static void xennet_make_frags(struct sk_buff *skb, struct net_device *dev,
 		ref = gnttab_claim_grant_reference(&np->gref_tx_head);
 		BUG_ON((signed short)ref < 0);
 
+		BUG_ON(PageCompound(skb_frag_page(frag)));
+
 		mfn = pfn_to_mfn(page_to_pfn(skb_frag_page(frag)));
 		gnttab_grant_foreign_access_ref(ref, np->xbdev->otherend_id,
 						mfn, GNTMAP_readonly);

My repro for netback was just to netcat a wodge of data from dom0->domU
but going the other way doesn't seem to trigger.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 13:27:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 13:27:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLwJL-0006HM-8J; Wed, 10 Oct 2012 13:26:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLwJJ-0006HH-O3
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 13:26:54 +0000
Received: from [85.158.138.51:44514] by server-14.bemta-3.messagelabs.com id
	1C/7C-17276-C9775705; Wed, 10 Oct 2012 13:26:52 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1349875611!26234503!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1905 invoked from network); 10 Oct 2012 13:26:51 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 13:26:51 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so381218eek.32
	for ; Wed, 10 Oct 2012 06:26:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=TE51J+R0/bpHvmrc3xKj1vPfeoBl1e6o4hQNOcfdrU4=;
	b=nclkWtdab7Kq2YyoB4H6tLGBmDvQzNbiU9TQBuCUHiI0ntgyI9SSoSVdkkx/4K4r2O
	82YHfOgqv+qHRSQbFbgza+1VJn2hmzXv5Av53pHBMcgFw3psqF8xhTCgdJH7YdnWCepN
	PhTAUDqMt8Cb1F8sY3/6RyfYYmowSd0qOH8l4ZOl5h/a7HpDcvFPCn5hvi5C3jI5HOCE
	+ias4vPthIIeTSdPdmZoARs8o0uuIylmKwRo6QGana9ggxshOQUS8eO0ZlG+2+BWmvi/
	ICRf2wVAEPWMCsRxBG/DNMSlQM+n6ih8L3HQCM7q+vqSsL3bJ+lUzgUtPTO04pyM8Jyl
	koCw==
MIME-Version: 1.0
Received: by 10.14.225.73 with SMTP id y49mr17063990eep.25.1349875611510; Wed,
	10 Oct 2012 06:26:51 -0700 (PDT)
Received: by 10.14.134.10 with HTTP; Wed, 10 Oct 2012 06:26:51 -0700 (PDT)
In-Reply-To: 
References: 
	
Date: Wed, 10 Oct 2012 14:26:51 +0100
X-Google-Sender-Auth: SCaLkKrLAuom0nvi2lz2aM-j59M
Message-ID: 
From: George Dunlap 
To: David Vrabel 
Cc: George Dunlap , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1 of 2] xenalyze: decode PV_HYPERCALL_V2
	records
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Oct 4, 2012 at 1:28 PM, David Vrabel  wrote:
> Newer version of Xen produce TRC_PV_HYPERCALL_V2 records instead of
> the older TRC_PV_HYPERCALL format.  This updated format doesn't
> included the IP but it does include select hypercall arguments.
>
> Signed-off-by: David Vrabel 

You had a couple of stray SUBCALL things in this patch which cause it
to fail compilation; I moved them to the next patch and have committed
both patches.  Thanks.

 -George.

>
> diff --git a/analyze.h b/analyze.h
> --- a/analyze.h
> +++ b/analyze.h
> @@ -3,6 +3,8 @@
>
>  #include 
>
> +#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
> +
>  #define TRC_GEN_MAIN     0
>  #define TRC_SCHED_MAIN   1
>  #define TRC_DOM0OP_MAIN  2
> diff --git a/pv.h b/pv.h
> new file mode 100644
> --- /dev/null
> +++ b/pv.h
> @@ -0,0 +1,41 @@
> +/*
> + * PV event decoding.
> + *
> + * Copyright (C) 2012 Citrix Systems R&D Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + */
> +#ifndef __PV_H
> +
> +#include "analyze.h"
> +#include "trace.h"
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +#define ARG_MISSING 0x0
> +#define ARG_32BIT 0x1
> +#define ARG_64BIT 0x2
> +
> +#define MMU_UPDATE_PREEMPTED          (~(~0U>>1))
> +
> +static inline uint32_t pv_hypercall_op(const struct record_info *ri)
> +{
> +    return ri->d[0] & ~TRC_PV_HYPERCALL_V2_ARG_MASK;
> +}
> +
> +static inline int pv_hypercall_arg_present(const struct record_info *ri, int arg)
> +{
> +    return (ri->d[0] >> (20 + 2*arg)) & 0x3;
> +}
> +
> +void pv_hypercall_gather_args(const struct record_info *ri, uint64_t *args);
> +
> +#ifdef __cplusplus
> +} /* extern "C" */
> +#endif
> +
> +#endif
> diff --git a/xenalyze.c b/xenalyze.c
> --- a/xenalyze.c
> +++ b/xenalyze.c
> @@ -32,6 +32,7 @@
>  #include "trace.h"
>  #include "analyze.h"
>  #include "mread.h"
> +#include "pv.h"
>  #include 
>  #include 
>  #include 
> @@ -1485,6 +1486,7 @@ enum {
>      PV_GDT_LDT_MAPPING_FAULT,
>      PV_PTWR_EMULATION,
>      PV_PTWR_EMULATION_PAE,
> +    PV_HYPERCALL_V2 = 13,
>      PV_MAX
>  };
>
> @@ -1499,7 +1501,9 @@ char *pv_name[PV_MAX] = {
>      [PV_PAGING_FIXUP]="paging fixup",
>      [PV_GDT_LDT_MAPPING_FAULT]="gdt/ldt mapping fault",
>      [PV_PTWR_EMULATION]="ptwr",
> -    [PV_PTWR_EMULATION_PAE]="ptwr(pae)"
> +    [PV_PTWR_EMULATION_PAE]="ptwr(pae)",
> +    [PV_HYPERCALL_V2]="hypercall",
> +    [PV_HYPERCALL_SUBCALL]="hypercall (subcall)",
>  };
>
>  #define PV_HYPERCALL_MAX 56
> @@ -6500,10 +6504,20 @@ void pv_summary(struct pv_data *pv) {
>
>      printf("PV events:\n");
>      for(i=0; i -        if(pv->count[i])
> -            printf("  %s  %d\n", pv_name[i], pv->count[i]);
> +        int count;
> +
> +        count = pv->count[i];
> +        if (i == PV_HYPERCALL_V2)
> +            count += pv->count[PV_HYPERCALL_SUBCALL];
> +
> +        if (count == 0)
> +            continue;
> +
> +        printf("  %s  %d\n", pv_name[i], count);
> +
>          switch(i) {
>          case PV_HYPERCALL:
> +        case PV_HYPERCALL_V2:
>              for(j=0; j                  if(pv->hypercall_count[j])
>                      printf("    %-29s[%2d]: %6d\n",
> @@ -6523,6 +6537,145 @@ void pv_summary(struct pv_data *pv) {
>      }
>  }
>
> +static const char *grant_table_op_str[] = {
> +    "map_grant_ref", "unmap_grant_ref", "setup_table", "dump_table",
> +    "transfer", "copy", "query_size", "unmap_and_replace",
> +    "set_version", "get_status_frames", "get_version", "swap_grant_ref",
> +};
> +
> +static const char *vcpu_op_str[] = {
> +    "initialise", "up", "down", "is_up", "get_runstate_info",
> +    "register_runstate_memory_area", "set_periodic_timer",
> +    "stop_periodic_timer", "set_singleshot_timer", "stop_singleshot_timer",
> +    "register_vcpu_info", "send_nmi", "get_physid",
> +    "register_vcpu_time_memory_area",
> +};
> +
> +static const char *sched_op_str[] = {
> +    "yield", "block", "shutdown", "poll", "remote_shutdown", "shutdown_code",
> +    "watchdog",
> +};
> +
> +static const char *cmd_to_str(const char *strings[], size_t n, uint32_t cmd)
> +{
> +    static char buf[32];
> +
> +    if (cmd < n)
> +        return strings[cmd];
> +
> +    snprintf(buf, sizeof(buf), "unknown (%d)", cmd);
> +    return buf;
> +}
> +
> +#define CMD_TO_STR(op)                                                  \
> +    static const char * op ## _to_str(uint32_t cmd) {                   \
> +        return cmd_to_str(op ## _str, ARRAY_SIZE(op ## _str), cmd);     \
> +    }
> +
> +CMD_TO_STR(grant_table_op);
> +CMD_TO_STR(vcpu_op);
> +CMD_TO_STR(sched_op);
> +
> +void pv_hypercall_gather_args(const struct record_info *ri, uint64_t *args)
> +{
> +    int i, word;
> +
> +    /* Missing arguments are zeroed. */
> +    memset(args, 0, 6 * sizeof(uint64_t));
> +
> +    for (i = 0, word = 1; i < 6 && word < ri->extra_words; i++) {
> +        int present = pv_hypercall_arg_present(ri, i);
> +
> +        switch (present) {
> +        case ARG_32BIT:
> +            args[i] = ri->d[word];
> +            break;
> +        case ARG_64BIT:
> +            args[i] = ((uint64_t)ri->d[word + 1] << 32) | ri->d[word];
> +            break;
> +        }
> +
> +        /* Skip over any words for this argument. */
> +        word += present;
> +    }
> +}
> +
> +static void pv_hypercall_print_args(const struct record_info *ri)
> +{
> +    int i, word;
> +
> +    for (i = 0, word = 1; i < 6 && word < ri->extra_words; i++) {
> +        int present = pv_hypercall_arg_present(ri, i);
> +
> +        switch (present) {
> +        case ARG_MISSING:
> +            printf(" ??");
> +            break;
> +        case ARG_32BIT:
> +            printf(" %08x", ri->d[word]);
> +            break;
> +        case ARG_64BIT:
> +            printf(" %016"PRIu64"", ((uint64_t)ri->d[word + 1] << 32) | ri->d[word]);
> +            break;
> +        }
> +
> +        word += present;
> +    }
> +}
> +
> +void pv_hypercall_v2_process(struct record_info *ri, struct pv_data *pv)
> +{
> +    int op = pv_hypercall_op(ri);
> +
> +    if(opt.summary_info) {
> +        if(op < PV_HYPERCALL_MAX)
> +            pv->hypercall_count[op]++;
> +    }
> +
> +    if(opt.dump_all) {
> +        uint64_t args[6];
> +
> +        if(op < HYPERCALL_MAX)
> +            printf(" %s hypercall %2x (%s)",
> +                   ri->dump_header, op, hypercall_name[op]);
> +        else
> +            printf(" %s hypercall %2x",
> +                   ri->dump_header, op);
> +
> +        switch(op) {
> +        case HYPERCALL_mmu_update:
> +            pv_hypercall_gather_args(ri, args);
> +            printf(" %d updates%s", (uint32_t)args[1] & ~MMU_UPDATE_PREEMPTED,
> +                   (args[1] & MMU_UPDATE_PREEMPTED) ? " (preempted)" : "");
> +            break;
> +        case HYPERCALL_multicall:
> +            pv_hypercall_gather_args(ri, args);
> +            printf(" %d calls", (uint32_t)args[1]);
> +            break;
> +        case HYPERCALL_grant_table_op:
> +            pv_hypercall_gather_args(ri, args);
> +            printf(" %s %d ops", grant_table_op_to_str(args[0]), (uint32_t)args[2]);
> +            break;
> +        case HYPERCALL_vcpu_op:
> +            pv_hypercall_gather_args(ri, args);
> +            printf(" %s vcpu %d", vcpu_op_to_str(args[0]), (uint32_t)args[1]);
> +            break;
> +        case HYPERCALL_mmuext_op:
> +            pv_hypercall_gather_args(ri, args);
> +            printf(" %d ops", (uint32_t)args[1]);
> +            break;
> +        case HYPERCALL_sched_op:
> +            pv_hypercall_gather_args(ri, args);
> +            printf(" %s", sched_op_to_str(args[0]));
> +            break;
> +        default:
> +            pv_hypercall_print_args(ri);
> +            break;
> +        }
> +        printf("\n");
> +    }
> +}
> +
>  void pv_process(struct pcpu_info *p)
>  {
>      struct record_info *ri = &p->ri;
> @@ -6555,9 +6708,9 @@ void pv_process(struct pcpu_info *p)
>      case PV_PTWR_EMULATION_PAE:
>          pv_ptwr_emulation_process(ri, pv);
>          break;
> -    case PV_PAGE_FAULT:
> -        //pv_pf_process(ri, pv);
> -        //break;
> +    case PV_HYPERCALL_V2:
> +        pv_hypercall_v2_process(ri, pv);
> +        break;
>      default:
>          pv_generic_process(ri, pv);
>          break;
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 13:27:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 13:27:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLwJL-0006HM-8J; Wed, 10 Oct 2012 13:26:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLwJJ-0006HH-O3
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 13:26:54 +0000
Received: from [85.158.138.51:44514] by server-14.bemta-3.messagelabs.com id
	1C/7C-17276-C9775705; Wed, 10 Oct 2012 13:26:52 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1349875611!26234503!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1905 invoked from network); 10 Oct 2012 13:26:51 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 13:26:51 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so381218eek.32
	for ; Wed, 10 Oct 2012 06:26:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=TE51J+R0/bpHvmrc3xKj1vPfeoBl1e6o4hQNOcfdrU4=;
	b=nclkWtdab7Kq2YyoB4H6tLGBmDvQzNbiU9TQBuCUHiI0ntgyI9SSoSVdkkx/4K4r2O
	82YHfOgqv+qHRSQbFbgza+1VJn2hmzXv5Av53pHBMcgFw3psqF8xhTCgdJH7YdnWCepN
	PhTAUDqMt8Cb1F8sY3/6RyfYYmowSd0qOH8l4ZOl5h/a7HpDcvFPCn5hvi5C3jI5HOCE
	+ias4vPthIIeTSdPdmZoARs8o0uuIylmKwRo6QGana9ggxshOQUS8eO0ZlG+2+BWmvi/
	ICRf2wVAEPWMCsRxBG/DNMSlQM+n6ih8L3HQCM7q+vqSsL3bJ+lUzgUtPTO04pyM8Jyl
	koCw==
MIME-Version: 1.0
Received: by 10.14.225.73 with SMTP id y49mr17063990eep.25.1349875611510; Wed,
	10 Oct 2012 06:26:51 -0700 (PDT)
Received: by 10.14.134.10 with HTTP; Wed, 10 Oct 2012 06:26:51 -0700 (PDT)
In-Reply-To: 
References: 
	
Date: Wed, 10 Oct 2012 14:26:51 +0100
X-Google-Sender-Auth: SCaLkKrLAuom0nvi2lz2aM-j59M
Message-ID: 
From: George Dunlap 
To: David Vrabel 
Cc: George Dunlap , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1 of 2] xenalyze: decode PV_HYPERCALL_V2
	records
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Oct 4, 2012 at 1:28 PM, David Vrabel  wrote:
> Newer version of Xen produce TRC_PV_HYPERCALL_V2 records instead of
> the older TRC_PV_HYPERCALL format.  This updated format doesn't
> included the IP but it does include select hypercall arguments.
>
> Signed-off-by: David Vrabel 

You had a couple of stray SUBCALL things in this patch which cause it
to fail compilation; I moved them to the next patch and have committed
both patches.  Thanks.

 -George.

>
> diff --git a/analyze.h b/analyze.h
> --- a/analyze.h
> +++ b/analyze.h
> @@ -3,6 +3,8 @@
>
>  #include 
>
> +#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
> +
>  #define TRC_GEN_MAIN     0
>  #define TRC_SCHED_MAIN   1
>  #define TRC_DOM0OP_MAIN  2
> diff --git a/pv.h b/pv.h
> new file mode 100644
> --- /dev/null
> +++ b/pv.h
> @@ -0,0 +1,41 @@
> +/*
> + * PV event decoding.
> + *
> + * Copyright (C) 2012 Citrix Systems R&D Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + */
> +#ifndef __PV_H
> +
> +#include "analyze.h"
> +#include "trace.h"
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +#define ARG_MISSING 0x0
> +#define ARG_32BIT 0x1
> +#define ARG_64BIT 0x2
> +
> +#define MMU_UPDATE_PREEMPTED          (~(~0U>>1))
> +
> +static inline uint32_t pv_hypercall_op(const struct record_info *ri)
> +{
> +    return ri->d[0] & ~TRC_PV_HYPERCALL_V2_ARG_MASK;
> +}
> +
> +static inline int pv_hypercall_arg_present(const struct record_info *ri, int arg)
> +{
> +    return (ri->d[0] >> (20 + 2*arg)) & 0x3;
> +}
> +
> +void pv_hypercall_gather_args(const struct record_info *ri, uint64_t *args);
> +
> +#ifdef __cplusplus
> +} /* extern "C" */
> +#endif
> +
> +#endif
> diff --git a/xenalyze.c b/xenalyze.c
> --- a/xenalyze.c
> +++ b/xenalyze.c
> @@ -32,6 +32,7 @@
>  #include "trace.h"
>  #include "analyze.h"
>  #include "mread.h"
> +#include "pv.h"
>  #include 
>  #include 
>  #include 
> @@ -1485,6 +1486,7 @@ enum {
>      PV_GDT_LDT_MAPPING_FAULT,
>      PV_PTWR_EMULATION,
>      PV_PTWR_EMULATION_PAE,
> +    PV_HYPERCALL_V2 = 13,
>      PV_MAX
>  };
>
> @@ -1499,7 +1501,9 @@ char *pv_name[PV_MAX] = {
>      [PV_PAGING_FIXUP]="paging fixup",
>      [PV_GDT_LDT_MAPPING_FAULT]="gdt/ldt mapping fault",
>      [PV_PTWR_EMULATION]="ptwr",
> -    [PV_PTWR_EMULATION_PAE]="ptwr(pae)"
> +    [PV_PTWR_EMULATION_PAE]="ptwr(pae)",
> +    [PV_HYPERCALL_V2]="hypercall",
> +    [PV_HYPERCALL_SUBCALL]="hypercall (subcall)",
>  };
>
>  #define PV_HYPERCALL_MAX 56
> @@ -6500,10 +6504,20 @@ void pv_summary(struct pv_data *pv) {
>
>      printf("PV events:\n");
>      for(i=0; i -        if(pv->count[i])
> -            printf("  %s  %d\n", pv_name[i], pv->count[i]);
> +        int count;
> +
> +        count = pv->count[i];
> +        if (i == PV_HYPERCALL_V2)
> +            count += pv->count[PV_HYPERCALL_SUBCALL];
> +
> +        if (count == 0)
> +            continue;
> +
> +        printf("  %s  %d\n", pv_name[i], count);
> +
>          switch(i) {
>          case PV_HYPERCALL:
> +        case PV_HYPERCALL_V2:
>              for(j=0; j                  if(pv->hypercall_count[j])
>                      printf("    %-29s[%2d]: %6d\n",
> @@ -6523,6 +6537,145 @@ void pv_summary(struct pv_data *pv) {
>      }
>  }
>
> +static const char *grant_table_op_str[] = {
> +    "map_grant_ref", "unmap_grant_ref", "setup_table", "dump_table",
> +    "transfer", "copy", "query_size", "unmap_and_replace",
> +    "set_version", "get_status_frames", "get_version", "swap_grant_ref",
> +};
> +
> +static const char *vcpu_op_str[] = {
> +    "initialise", "up", "down", "is_up", "get_runstate_info",
> +    "register_runstate_memory_area", "set_periodic_timer",
> +    "stop_periodic_timer", "set_singleshot_timer", "stop_singleshot_timer",
> +    "register_vcpu_info", "send_nmi", "get_physid",
> +    "register_vcpu_time_memory_area",
> +};
> +
> +static const char *sched_op_str[] = {
> +    "yield", "block", "shutdown", "poll", "remote_shutdown", "shutdown_code",
> +    "watchdog",
> +};
> +
> +static const char *cmd_to_str(const char *strings[], size_t n, uint32_t cmd)
> +{
> +    static char buf[32];
> +
> +    if (cmd < n)
> +        return strings[cmd];
> +
> +    snprintf(buf, sizeof(buf), "unknown (%d)", cmd);
> +    return buf;
> +}
> +
> +#define CMD_TO_STR(op)                                                  \
> +    static const char * op ## _to_str(uint32_t cmd) {                   \
> +        return cmd_to_str(op ## _str, ARRAY_SIZE(op ## _str), cmd);     \
> +    }
> +
> +CMD_TO_STR(grant_table_op);
> +CMD_TO_STR(vcpu_op);
> +CMD_TO_STR(sched_op);
> +
> +void pv_hypercall_gather_args(const struct record_info *ri, uint64_t *args)
> +{
> +    int i, word;
> +
> +    /* Missing arguments are zeroed. */
> +    memset(args, 0, 6 * sizeof(uint64_t));
> +
> +    for (i = 0, word = 1; i < 6 && word < ri->extra_words; i++) {
> +        int present = pv_hypercall_arg_present(ri, i);
> +
> +        switch (present) {
> +        case ARG_32BIT:
> +            args[i] = ri->d[word];
> +            break;
> +        case ARG_64BIT:
> +            args[i] = ((uint64_t)ri->d[word + 1] << 32) | ri->d[word];
> +            break;
> +        }
> +
> +        /* Skip over any words for this argument. */
> +        word += present;
> +    }
> +}
> +
> +static void pv_hypercall_print_args(const struct record_info *ri)
> +{
> +    int i, word;
> +
> +    for (i = 0, word = 1; i < 6 && word < ri->extra_words; i++) {
> +        int present = pv_hypercall_arg_present(ri, i);
> +
> +        switch (present) {
> +        case ARG_MISSING:
> +            printf(" ??");
> +            break;
> +        case ARG_32BIT:
> +            printf(" %08x", ri->d[word]);
> +            break;
> +        case ARG_64BIT:
> +            printf(" %016"PRIu64"", ((uint64_t)ri->d[word + 1] << 32) | ri->d[word]);
> +            break;
> +        }
> +
> +        word += present;
> +    }
> +}
> +
> +void pv_hypercall_v2_process(struct record_info *ri, struct pv_data *pv)
> +{
> +    int op = pv_hypercall_op(ri);
> +
> +    if(opt.summary_info) {
> +        if(op < PV_HYPERCALL_MAX)
> +            pv->hypercall_count[op]++;
> +    }
> +
> +    if(opt.dump_all) {
> +        uint64_t args[6];
> +
> +        if(op < HYPERCALL_MAX)
> +            printf(" %s hypercall %2x (%s)",
> +                   ri->dump_header, op, hypercall_name[op]);
> +        else
> +            printf(" %s hypercall %2x",
> +                   ri->dump_header, op);
> +
> +        switch(op) {
> +        case HYPERCALL_mmu_update:
> +            pv_hypercall_gather_args(ri, args);
> +            printf(" %d updates%s", (uint32_t)args[1] & ~MMU_UPDATE_PREEMPTED,
> +                   (args[1] & MMU_UPDATE_PREEMPTED) ? " (preempted)" : "");
> +            break;
> +        case HYPERCALL_multicall:
> +            pv_hypercall_gather_args(ri, args);
> +            printf(" %d calls", (uint32_t)args[1]);
> +            break;
> +        case HYPERCALL_grant_table_op:
> +            pv_hypercall_gather_args(ri, args);
> +            printf(" %s %d ops", grant_table_op_to_str(args[0]), (uint32_t)args[2]);
> +            break;
> +        case HYPERCALL_vcpu_op:
> +            pv_hypercall_gather_args(ri, args);
> +            printf(" %s vcpu %d", vcpu_op_to_str(args[0]), (uint32_t)args[1]);
> +            break;
> +        case HYPERCALL_mmuext_op:
> +            pv_hypercall_gather_args(ri, args);
> +            printf(" %d ops", (uint32_t)args[1]);
> +            break;
> +        case HYPERCALL_sched_op:
> +            pv_hypercall_gather_args(ri, args);
> +            printf(" %s", sched_op_to_str(args[0]));
> +            break;
> +        default:
> +            pv_hypercall_print_args(ri);
> +            break;
> +        }
> +        printf("\n");
> +    }
> +}
> +
>  void pv_process(struct pcpu_info *p)
>  {
>      struct record_info *ri = &p->ri;
> @@ -6555,9 +6708,9 @@ void pv_process(struct pcpu_info *p)
>      case PV_PTWR_EMULATION_PAE:
>          pv_ptwr_emulation_process(ri, pv);
>          break;
> -    case PV_PAGE_FAULT:
> -        //pv_pf_process(ri, pv);
> -        //break;
> +    case PV_HYPERCALL_V2:
> +        pv_hypercall_v2_process(ri, pv);
> +        break;
>      default:
>          pv_generic_process(ri, pv);
>          break;
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 13:31:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 13:31:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLwNk-0006QP-7o; Wed, 10 Oct 2012 13:31:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLwNi-0006QJ-3z
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 13:31:26 +0000
Received: from [85.158.143.35:32031] by server-3.bemta-4.messagelabs.com id
	B5/7D-10075-DA875705; Wed, 10 Oct 2012 13:31:25 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-4.tower-21.messagelabs.com!1349875883!6060243!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22969 invoked from network); 10 Oct 2012 13:31:23 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-4.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Oct 2012 13:31:23 -0000
Received: from 50-66-ftth.onsneteindhoven.nl ([88.159.66.50]:57395
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TLwOz-0007Ny-F7; Wed, 10 Oct 2012 15:32:45 +0200
Date: Wed, 10 Oct 2012 15:31:16 +0200
From: Sander Eikelenboom 
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1709861450.20121010153116@eikelenboom.it>
To: Ian Campbell 
In-Reply-To: <1349872149.10070.31.camel@zakaz.uk.xensource.com>
References: <1349790467.21847.185.camel@zakaz.uk.xensource.com>
	<1349790863.21172.4406.camel@edumazet-glaptop>
	<1349792241.21847.199.camel@zakaz.uk.xensource.com>
	<1349792847.21172.4479.camel@edumazet-glaptop>
	<1349793630.21847.208.camel@zakaz.uk.xensource.com>
	<1349863984.10070.26.camel@zakaz.uk.xensource.com>
	<1622789731.20121010142428@eikelenboom.it>
	<1349872149.10070.31.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" ,
	Eric Dumazet , xen-devel ,
	Eric Dumazet ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] compound skb frag pages appearing in start_xmit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Wednesday, October 10, 2012, 2:29:09 PM, you wrote:

> On Wed, 2012-10-10 at 13:24 +0100, Sander Eikelenboom wrote:
>> Wednesday, October 10, 2012, 12:13:04 PM, you wrote:
>> 
>> > On Tue, 2012-10-09 at 15:40 +0100, Ian Campbell wrote:
>> >> On Tue, 2012-10-09 at 15:27 +0100, Eric Dumazet wrote:
>> >> > On Tue, 2012-10-09 at 15:17 +0100, Ian Campbell wrote:
>> >> > 
>> >> > > Does the higher order pages effectively reduce the number of frags which
>> >> > > are in use? e.g if MAX_SKB_FRAGS is 16, then for order-0 pages you could
>> >> > > have 64K worth of frag data.
>> >> > > 
>> >> > > If we switch to order-3 pages everywhere then can the skb contain 512K
>> >> > > of data, or does the effective maximum number of frags in an skb reduce
>> >> > > to 2?
>> >> > 
>> >> > effective number of frags reduce to 2 or 3
>> >> > 
>> >> > (We still limit GSO packets to ~63536 bytes)
>> >> 
>> >> Great! Then I think the fix is more/less trivial...
>> 
>> > The following seems to work for me.
>> 
>> But it doesn't seem to work for me ... dmesg attached.

>> [  191.777994] ------------[ cut here ]------------
>> [  191.784245] kernel BUG at drivers/net/xen-netback/netback.c:481!

> Looks like that BUG_ON is a little aggressive. It'll trigger if the data
> happens to end on a frame boundary. Hopefully this will fix it for you:

Yes it does !
Thanks .. will recompile and test the netfront case as well

--
Sander

> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index d747e30..f2d6b78 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -477,7 +477,7 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
>                 size -= bytes;
>  
>                 /* Next frame */
> -               if (offset == PAGE_SIZE) {
> +               if (offset == PAGE_SIZE && size) {
>                         BUG_ON(!PageCompound(page));
>                         page++;
>                         offset = 0;





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 13:31:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 13:31:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLwNk-0006QP-7o; Wed, 10 Oct 2012 13:31:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLwNi-0006QJ-3z
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 13:31:26 +0000
Received: from [85.158.143.35:32031] by server-3.bemta-4.messagelabs.com id
	B5/7D-10075-DA875705; Wed, 10 Oct 2012 13:31:25 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-4.tower-21.messagelabs.com!1349875883!6060243!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22969 invoked from network); 10 Oct 2012 13:31:23 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-4.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Oct 2012 13:31:23 -0000
Received: from 50-66-ftth.onsneteindhoven.nl ([88.159.66.50]:57395
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TLwOz-0007Ny-F7; Wed, 10 Oct 2012 15:32:45 +0200
Date: Wed, 10 Oct 2012 15:31:16 +0200
From: Sander Eikelenboom 
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1709861450.20121010153116@eikelenboom.it>
To: Ian Campbell 
In-Reply-To: <1349872149.10070.31.camel@zakaz.uk.xensource.com>
References: <1349790467.21847.185.camel@zakaz.uk.xensource.com>
	<1349790863.21172.4406.camel@edumazet-glaptop>
	<1349792241.21847.199.camel@zakaz.uk.xensource.com>
	<1349792847.21172.4479.camel@edumazet-glaptop>
	<1349793630.21847.208.camel@zakaz.uk.xensource.com>
	<1349863984.10070.26.camel@zakaz.uk.xensource.com>
	<1622789731.20121010142428@eikelenboom.it>
	<1349872149.10070.31.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" ,
	Eric Dumazet , xen-devel ,
	Eric Dumazet ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] compound skb frag pages appearing in start_xmit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Wednesday, October 10, 2012, 2:29:09 PM, you wrote:

> On Wed, 2012-10-10 at 13:24 +0100, Sander Eikelenboom wrote:
>> Wednesday, October 10, 2012, 12:13:04 PM, you wrote:
>> 
>> > On Tue, 2012-10-09 at 15:40 +0100, Ian Campbell wrote:
>> >> On Tue, 2012-10-09 at 15:27 +0100, Eric Dumazet wrote:
>> >> > On Tue, 2012-10-09 at 15:17 +0100, Ian Campbell wrote:
>> >> > 
>> >> > > Does the higher order pages effectively reduce the number of frags which
>> >> > > are in use? e.g if MAX_SKB_FRAGS is 16, then for order-0 pages you could
>> >> > > have 64K worth of frag data.
>> >> > > 
>> >> > > If we switch to order-3 pages everywhere then can the skb contain 512K
>> >> > > of data, or does the effective maximum number of frags in an skb reduce
>> >> > > to 2?
>> >> > 
>> >> > effective number of frags reduce to 2 or 3
>> >> > 
>> >> > (We still limit GSO packets to ~63536 bytes)
>> >> 
>> >> Great! Then I think the fix is more/less trivial...
>> 
>> > The following seems to work for me.
>> 
>> But it doesn't seem to work for me ... dmesg attached.

>> [  191.777994] ------------[ cut here ]------------
>> [  191.784245] kernel BUG at drivers/net/xen-netback/netback.c:481!

> Looks like that BUG_ON is a little aggressive. It'll trigger if the data
> happens to end on a frame boundary. Hopefully this will fix it for you:

Yes it does !
Thanks .. will recompile and test the netfront case as well

--
Sander

> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index d747e30..f2d6b78 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -477,7 +477,7 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
>                 size -= bytes;
>  
>                 /* Next frame */
> -               if (offset == PAGE_SIZE) {
> +               if (offset == PAGE_SIZE && size) {
>                         BUG_ON(!PageCompound(page));
>                         page++;
>                         offset = 0;





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 13:35:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 13:35:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLwQz-0006aV-R4; Wed, 10 Oct 2012 13:34:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLwQy-0006aL-5a
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 13:34:48 +0000
Received: from [85.158.137.99:4344] by server-9.bemta-3.messagelabs.com id
	6B/9D-16841-77975705; Wed, 10 Oct 2012 13:34:47 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1349876086!15905610!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11315 invoked from network); 10 Oct 2012 13:34:46 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 13:34:46 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so387709eek.32
	for ; Wed, 10 Oct 2012 06:34:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=tYT0vI9tBIw00u4Q5k4ahlhoJzPkcES2y2cKOvh0Ats=;
	b=gNH+xapHfu3FpD22cMHq7wuRgNuQHy3vR4Jui/ncN3rGSELvJXlXYpOgeQnXecXGHs
	Zc0gUvy4UdITkyhbP4qwvy/kAFqacliyoo4/2seDZPLhlVN+tsu+3I9N5nv0UyK0Ku+Y
	h5Jvwcffrwqkul4bIEMJyreWTtKi2Rjvkb3js0AM53/rVbs6eud5ktjwkawIiRNcfghW
	juJUl4eaV6x81ptDOb+G9J8XpWFJNlOaEm+kKG8PgK5xHMcodNX2FtDoNvlY495n5KZe
	6fMElhn+NEb8iFHbD2ZVMG2xPZOt8fLUMnbSuycFSaCYhAAeUVwLR8DwEbxDFawxXaEW
	8/WA==
MIME-Version: 1.0
Received: by 10.14.212.72 with SMTP id x48mr32619557eeo.40.1349876086397; Wed,
	10 Oct 2012 06:34:46 -0700 (PDT)
Received: by 10.14.134.10 with HTTP; Wed, 10 Oct 2012 06:34:46 -0700 (PDT)
In-Reply-To: <507462ED.2000203@amd.com>
References: <507462ED.2000203@amd.com>
Date: Wed, 10 Oct 2012 14:34:46 +0100
X-Google-Sender-Auth: dEJiBnQA8N7aNq8Q6bA4HgOe_bs
Message-ID: 
From: George Dunlap 
To: Boris Ostrovsky 
Cc: xen-devel 
Subject: Re: [Xen-devel] [PATCH] xenalyze: Use correct length when copying
 record into buffer
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 9, 2012 at 6:46 PM, Boris Ostrovsky  wrote:
> # HG changeset patch
> # User Boris Ostrovsky 
> # Date 1349350810 14400
> # Node ID ba18ab77da8ebe3c81ebf2c78c735cfcd40ea031
> # Parent  4d47a8934b40556dd98428361c482be419c643be
> xenalyze: Use correct length when copying record into buffer
>
> mread64() calculates number of bytes to copied to avoid overrunning
> target buffer but then doesn't use the calculated value.
>
> Signed-off-by: Boris Ostrovsky 

Good catch!  Thanks.  BTW, somehow this ended up with word-wrap and
whitespace damage -- I've fixed it and applied it anyway, but next
time can you try to use the mercurial patchbomb extension (hg email)?
(Making it an attachment is OK too, but setting up patchbomb is
definitely worth the effort.)

Thanks,
 -George

>
> diff -r 4d47a8934b40 -r ba18ab77da8e mread.c
> --- a/mread.c   Wed Jun 20 16:54:17 2012 +0100
> +++ b/mread.c   Thu Oct 04 07:40:10 2012 -0400
> @@ -143,7 +143,7 @@ copy:
>      dprintf(warn, " Using index %d, buffer at %p, buffer offset %llx len
> %d\n",
>              bind, b, boffset, bsize);
>
> -    bcopy(b+boffset, rec, len);
> +    bcopy(b+boffset, rec, bsize);
>
>      /* Handle the boundary case; make sure this is after doing anything
>       * with the static variables*/
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 13:35:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 13:35:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLwQz-0006aV-R4; Wed, 10 Oct 2012 13:34:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLwQy-0006aL-5a
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 13:34:48 +0000
Received: from [85.158.137.99:4344] by server-9.bemta-3.messagelabs.com id
	6B/9D-16841-77975705; Wed, 10 Oct 2012 13:34:47 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1349876086!15905610!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11315 invoked from network); 10 Oct 2012 13:34:46 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 13:34:46 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so387709eek.32
	for ; Wed, 10 Oct 2012 06:34:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=tYT0vI9tBIw00u4Q5k4ahlhoJzPkcES2y2cKOvh0Ats=;
	b=gNH+xapHfu3FpD22cMHq7wuRgNuQHy3vR4Jui/ncN3rGSELvJXlXYpOgeQnXecXGHs
	Zc0gUvy4UdITkyhbP4qwvy/kAFqacliyoo4/2seDZPLhlVN+tsu+3I9N5nv0UyK0Ku+Y
	h5Jvwcffrwqkul4bIEMJyreWTtKi2Rjvkb3js0AM53/rVbs6eud5ktjwkawIiRNcfghW
	juJUl4eaV6x81ptDOb+G9J8XpWFJNlOaEm+kKG8PgK5xHMcodNX2FtDoNvlY495n5KZe
	6fMElhn+NEb8iFHbD2ZVMG2xPZOt8fLUMnbSuycFSaCYhAAeUVwLR8DwEbxDFawxXaEW
	8/WA==
MIME-Version: 1.0
Received: by 10.14.212.72 with SMTP id x48mr32619557eeo.40.1349876086397; Wed,
	10 Oct 2012 06:34:46 -0700 (PDT)
Received: by 10.14.134.10 with HTTP; Wed, 10 Oct 2012 06:34:46 -0700 (PDT)
In-Reply-To: <507462ED.2000203@amd.com>
References: <507462ED.2000203@amd.com>
Date: Wed, 10 Oct 2012 14:34:46 +0100
X-Google-Sender-Auth: dEJiBnQA8N7aNq8Q6bA4HgOe_bs
Message-ID: 
From: George Dunlap 
To: Boris Ostrovsky 
Cc: xen-devel 
Subject: Re: [Xen-devel] [PATCH] xenalyze: Use correct length when copying
 record into buffer
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 9, 2012 at 6:46 PM, Boris Ostrovsky  wrote:
> # HG changeset patch
> # User Boris Ostrovsky 
> # Date 1349350810 14400
> # Node ID ba18ab77da8ebe3c81ebf2c78c735cfcd40ea031
> # Parent  4d47a8934b40556dd98428361c482be419c643be
> xenalyze: Use correct length when copying record into buffer
>
> mread64() calculates number of bytes to copied to avoid overrunning
> target buffer but then doesn't use the calculated value.
>
> Signed-off-by: Boris Ostrovsky 

Good catch!  Thanks.  BTW, somehow this ended up with word-wrap and
whitespace damage -- I've fixed it and applied it anyway, but next
time can you try to use the mercurial patchbomb extension (hg email)?
(Making it an attachment is OK too, but setting up patchbomb is
definitely worth the effort.)

Thanks,
 -George

>
> diff -r 4d47a8934b40 -r ba18ab77da8e mread.c
> --- a/mread.c   Wed Jun 20 16:54:17 2012 +0100
> +++ b/mread.c   Thu Oct 04 07:40:10 2012 -0400
> @@ -143,7 +143,7 @@ copy:
>      dprintf(warn, " Using index %d, buffer at %p, buffer offset %llx len
> %d\n",
>              bind, b, boffset, bsize);
>
> -    bcopy(b+boffset, rec, len);
> +    bcopy(b+boffset, rec, bsize);
>
>      /* Handle the boundary case; make sure this is after doing anything
>       * with the static variables*/
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 13:49:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 13:49:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLweY-0006mH-9P; Wed, 10 Oct 2012 13:48:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLweW-0006mA-LA
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 13:48:48 +0000
Received: from [85.158.143.99:12403] by server-2.bemta-4.messagelabs.com id
	4A/5C-25171-FBC75705; Wed, 10 Oct 2012 13:48:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1349876923!27336091!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODEzOTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2603 invoked from network); 10 Oct 2012 13:48:45 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 13:48:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="210838394"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 13:48:43 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 10 Oct 2012 09:48:43 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TLweQ-0005jZ-K7;
	Wed, 10 Oct 2012 14:48:42 +0100
From: Ian Campbell 
To: netdev@vger.kernel.org,
	xen-devel@lists.xen.org
Date: Wed, 10 Oct 2012 14:48:42 +0100
Message-ID: <1349876922-11907-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk ,
	Ian Campbell ,
	Eric Dumazet ,
	Sander Eikelenboom 
Subject: [Xen-devel] [PATCH V2] xen: netback: handle compound page fragments
	on transmit.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

An SKB paged fragment can consist of a compound page with order > 0.
However the netchannel protocol deals only in PAGE_SIZE frames.

Handle this in netbk_gop_frag_copy and xen_netbk_count_skb_slots by
iterating over the frames which make up the page.

Signed-off-by: Ian Campbell 
Cc: Eric Dumazet 
Cc: Konrad Rzeszutek Wilk 
Cc: Sander Eikelenboom 
---
v2: Only move to next frame if there is data remaining.
---
 drivers/net/xen-netback/netback.c |   40 ++++++++++++++++++++++++++++++++----
 1 files changed, 35 insertions(+), 5 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 4ebfcf3..f2d6b78 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -335,21 +335,35 @@ unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb)
 
 	for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
 		unsigned long size = skb_frag_size(&skb_shinfo(skb)->frags[i]);
+		unsigned long offset = skb_shinfo(skb)->frags[i].page_offset;
 		unsigned long bytes;
+
+		offset &= ~PAGE_MASK;
+
 		while (size > 0) {
+			BUG_ON(offset >= PAGE_SIZE);
 			BUG_ON(copy_off > MAX_BUFFER_OFFSET);
 
-			if (start_new_rx_buffer(copy_off, size, 0)) {
+			bytes = PAGE_SIZE - offset;
+
+			if (bytes > size)
+				bytes = size;
+
+			if (start_new_rx_buffer(copy_off, bytes, 0)) {
 				count++;
 				copy_off = 0;
 			}
 
-			bytes = size;
 			if (copy_off + bytes > MAX_BUFFER_OFFSET)
 				bytes = MAX_BUFFER_OFFSET - copy_off;
 
 			copy_off += bytes;
+
+			offset += bytes;
 			size -= bytes;
+
+			if (offset == PAGE_SIZE)
+				offset = 0;
 		}
 	}
 	return count;
@@ -403,14 +417,24 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 	unsigned long bytes;
 
 	/* Data must not cross a page boundary. */
-	BUG_ON(size + offset > PAGE_SIZE);
+	BUG_ON(size + offset > PAGE_SIZE<meta + npo->meta_prod - 1;
 
+	/* Skip unused frames from start of page */
+	page += offset >> PAGE_SHIFT;
+	offset &= ~PAGE_MASK;
+
 	while (size > 0) {
+		BUG_ON(offset >= PAGE_SIZE);
 		BUG_ON(npo->copy_off > MAX_BUFFER_OFFSET);
 
-		if (start_new_rx_buffer(npo->copy_off, size, *head)) {
+		bytes = PAGE_SIZE - offset;
+
+		if (bytes > size)
+			bytes = size;
+
+		if (start_new_rx_buffer(npo->copy_off, bytes, *head)) {
 			/*
 			 * Netfront requires there to be some data in the head
 			 * buffer.
@@ -420,7 +444,6 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 			meta = get_next_rx_buffer(vif, npo);
 		}
 
-		bytes = size;
 		if (npo->copy_off + bytes > MAX_BUFFER_OFFSET)
 			bytes = MAX_BUFFER_OFFSET - npo->copy_off;
 
@@ -453,6 +476,13 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 		offset += bytes;
 		size -= bytes;
 
+		/* Next frame */
+		if (offset == PAGE_SIZE && size) {
+			BUG_ON(!PageCompound(page));
+			page++;
+			offset = 0;
+		}
+
 		/* Leave a gap for the GSO descriptor. */
 		if (*head && skb_shinfo(skb)->gso_size && !vif->gso_prefix)
 			vif->rx.req_cons++;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 13:49:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 13:49:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLweY-0006mH-9P; Wed, 10 Oct 2012 13:48:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLweW-0006mA-LA
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 13:48:48 +0000
Received: from [85.158.143.99:12403] by server-2.bemta-4.messagelabs.com id
	4A/5C-25171-FBC75705; Wed, 10 Oct 2012 13:48:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1349876923!27336091!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODEzOTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2603 invoked from network); 10 Oct 2012 13:48:45 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 13:48:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="210838394"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 13:48:43 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 10 Oct 2012 09:48:43 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TLweQ-0005jZ-K7;
	Wed, 10 Oct 2012 14:48:42 +0100
From: Ian Campbell 
To: netdev@vger.kernel.org,
	xen-devel@lists.xen.org
Date: Wed, 10 Oct 2012 14:48:42 +0100
Message-ID: <1349876922-11907-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk ,
	Ian Campbell ,
	Eric Dumazet ,
	Sander Eikelenboom 
Subject: [Xen-devel] [PATCH V2] xen: netback: handle compound page fragments
	on transmit.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

An SKB paged fragment can consist of a compound page with order > 0.
However the netchannel protocol deals only in PAGE_SIZE frames.

Handle this in netbk_gop_frag_copy and xen_netbk_count_skb_slots by
iterating over the frames which make up the page.

Signed-off-by: Ian Campbell 
Cc: Eric Dumazet 
Cc: Konrad Rzeszutek Wilk 
Cc: Sander Eikelenboom 
---
v2: Only move to next frame if there is data remaining.
---
 drivers/net/xen-netback/netback.c |   40 ++++++++++++++++++++++++++++++++----
 1 files changed, 35 insertions(+), 5 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 4ebfcf3..f2d6b78 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -335,21 +335,35 @@ unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb)
 
 	for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
 		unsigned long size = skb_frag_size(&skb_shinfo(skb)->frags[i]);
+		unsigned long offset = skb_shinfo(skb)->frags[i].page_offset;
 		unsigned long bytes;
+
+		offset &= ~PAGE_MASK;
+
 		while (size > 0) {
+			BUG_ON(offset >= PAGE_SIZE);
 			BUG_ON(copy_off > MAX_BUFFER_OFFSET);
 
-			if (start_new_rx_buffer(copy_off, size, 0)) {
+			bytes = PAGE_SIZE - offset;
+
+			if (bytes > size)
+				bytes = size;
+
+			if (start_new_rx_buffer(copy_off, bytes, 0)) {
 				count++;
 				copy_off = 0;
 			}
 
-			bytes = size;
 			if (copy_off + bytes > MAX_BUFFER_OFFSET)
 				bytes = MAX_BUFFER_OFFSET - copy_off;
 
 			copy_off += bytes;
+
+			offset += bytes;
 			size -= bytes;
+
+			if (offset == PAGE_SIZE)
+				offset = 0;
 		}
 	}
 	return count;
@@ -403,14 +417,24 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 	unsigned long bytes;
 
 	/* Data must not cross a page boundary. */
-	BUG_ON(size + offset > PAGE_SIZE);
+	BUG_ON(size + offset > PAGE_SIZE<meta + npo->meta_prod - 1;
 
+	/* Skip unused frames from start of page */
+	page += offset >> PAGE_SHIFT;
+	offset &= ~PAGE_MASK;
+
 	while (size > 0) {
+		BUG_ON(offset >= PAGE_SIZE);
 		BUG_ON(npo->copy_off > MAX_BUFFER_OFFSET);
 
-		if (start_new_rx_buffer(npo->copy_off, size, *head)) {
+		bytes = PAGE_SIZE - offset;
+
+		if (bytes > size)
+			bytes = size;
+
+		if (start_new_rx_buffer(npo->copy_off, bytes, *head)) {
 			/*
 			 * Netfront requires there to be some data in the head
 			 * buffer.
@@ -420,7 +444,6 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 			meta = get_next_rx_buffer(vif, npo);
 		}
 
-		bytes = size;
 		if (npo->copy_off + bytes > MAX_BUFFER_OFFSET)
 			bytes = MAX_BUFFER_OFFSET - npo->copy_off;
 
@@ -453,6 +476,13 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 		offset += bytes;
 		size -= bytes;
 
+		/* Next frame */
+		if (offset == PAGE_SIZE && size) {
+			BUG_ON(!PageCompound(page));
+			page++;
+			offset = 0;
+		}
+
 		/* Leave a gap for the GSO descriptor. */
 		if (*head && skb_shinfo(skb)->gso_size && !vif->gso_prefix)
 			vif->rx.req_cons++;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 14:04:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 14:04:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLwtQ-000731-UH; Wed, 10 Oct 2012 14:04:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLwtP-00072w-EH
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 14:04:11 +0000
Received: from [85.158.139.211:28484] by server-16.bemta-5.messagelabs.com id
	55/CE-10155-A5085705; Wed, 10 Oct 2012 14:04:10 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-15.tower-206.messagelabs.com!1349877849!21847115!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17104 invoked from network); 10 Oct 2012 14:04:10 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-15.tower-206.messagelabs.com with SMTP;
	10 Oct 2012 14:04:10 -0000
X-TM-IMSS-Message-ID: 
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1;
	TLSv1/SSLv3 DHE-RSA-AES256-SHA (256/256)) id c9a7d5db0000d9bd ;
	Wed, 10 Oct 2012 10:06:42 -0400
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q9AE3abi029656; 
	Wed, 10 Oct 2012 10:03:36 -0400
Message-ID: <50758038.6050009@tycho.nsa.gov>
Date: Wed, 10 Oct 2012 10:03:36 -0400
From: Daniel De Graaf 
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120911 Thunderbird/15.0.1
MIME-Version: 1.0
To: Dario Faggioli 
References: <1349801565.21847.228.camel@zakaz.uk.xensource.com>
	<1349807513-10923-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1349858695.3610.158.camel@Abyss>
In-Reply-To: <1349858695.3610.158.camel@Abyss>
Cc: Marcus.Granado@eu.citrix.com, andre.przywara@amd.com,
	Ian Campbell , anil@recoil.org,
	George.Dunlap@eu.citrix.com, Andrew.Cooper3@citrix.com,
	juergen.gross@ts.fujitsu.com, Ian.Jackson@eu.citrix.com,
	xen-devel@lists.xen.org, JBeulich@suse.com, msw@amazon.com,
	Keir Fraser 
Subject: Re: [Xen-devel] [PATCH RFC] flask: move policy header sources into
 hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/10/2012 04:44 AM, Dario Faggioli wrote:
> Hello Daniel,
> 
> On Tue, 2012-10-09 at 14:31 -0400, Daniel De Graaf wrote: 
>> Ian Campbell wrote:
>> [...]
>>>>> +++ b/xen/xsm/flask/include/av_perm_to_string.h
>>> Also, in that case why is this file checked in?
>>
>> This patch fixes the autogenerated files, but doesn't fully wire them in
>> to things like "make clean" or .{git,hg}ignore. 
>>
> Forgive me for pushing but, while you're here, do you mind taking a look
> and sharing your thoughts about the hunks of the patch touching XSM and
> FLASK? As I said, I've very few experience with that part of Xen, and it
> would be wonderful to know whether what I did looks sane, or I messed
> something up! :-P
> 
> Thanks and Regards,
> Dario
> 

Ah, in my distraction with fixing the autogeneration I neglected to 
finish looking at the original patch. The XSM changes look good except
for a missing implementation of the dummy_nodeaffinity() function in
xen/xsm/dummy.c. However, since the implementation of xsm_nodeaffinity
and xsm_vcpuaffinity are identical, it may be simpler to just merge them
into a common xsm_affinity_domctl hook (as is implemented in
xsm/flask/hooks.c) - in that case, just renaming the existing dummy hook
will suffice.

A more general note on the topic of what XSM permissions to use: 
normally, each domctl has its own permission, and so adding new domctls
would be done by adding a new permission to the access_vectors file
(which is the source of av_perm_to_string.h). However, for this case, it
seems rather unlikely that one would want to allow access to vcpu
affinity and deny node affinity, so using the same permission for both 
accesses is the best solution.

When renaming a permission (such as getvcpuaffinity => getaffinity), the
FLASK policy also needs to be changed - you can normally just grep for
the permission being changed.

The dummy hook would be caught in a compilation with XSM enabled, but I
notice that current xen-unstable will not build due to a patch being
applied out of order (xsm/flask: add domain relabel support requires
rcu_lock_domain_by_any_id which was added in the prior patch). Adding
Keir to CC since he applied the patch.

-- 
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 14:04:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 14:04:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLwtQ-000731-UH; Wed, 10 Oct 2012 14:04:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLwtP-00072w-EH
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 14:04:11 +0000
Received: from [85.158.139.211:28484] by server-16.bemta-5.messagelabs.com id
	55/CE-10155-A5085705; Wed, 10 Oct 2012 14:04:10 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-15.tower-206.messagelabs.com!1349877849!21847115!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17104 invoked from network); 10 Oct 2012 14:04:10 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-15.tower-206.messagelabs.com with SMTP;
	10 Oct 2012 14:04:10 -0000
X-TM-IMSS-Message-ID: 
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1;
	TLSv1/SSLv3 DHE-RSA-AES256-SHA (256/256)) id c9a7d5db0000d9bd ;
	Wed, 10 Oct 2012 10:06:42 -0400
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q9AE3abi029656; 
	Wed, 10 Oct 2012 10:03:36 -0400
Message-ID: <50758038.6050009@tycho.nsa.gov>
Date: Wed, 10 Oct 2012 10:03:36 -0400
From: Daniel De Graaf 
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120911 Thunderbird/15.0.1
MIME-Version: 1.0
To: Dario Faggioli 
References: <1349801565.21847.228.camel@zakaz.uk.xensource.com>
	<1349807513-10923-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1349858695.3610.158.camel@Abyss>
In-Reply-To: <1349858695.3610.158.camel@Abyss>
Cc: Marcus.Granado@eu.citrix.com, andre.przywara@amd.com,
	Ian Campbell , anil@recoil.org,
	George.Dunlap@eu.citrix.com, Andrew.Cooper3@citrix.com,
	juergen.gross@ts.fujitsu.com, Ian.Jackson@eu.citrix.com,
	xen-devel@lists.xen.org, JBeulich@suse.com, msw@amazon.com,
	Keir Fraser 
Subject: Re: [Xen-devel] [PATCH RFC] flask: move policy header sources into
 hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/10/2012 04:44 AM, Dario Faggioli wrote:
> Hello Daniel,
> 
> On Tue, 2012-10-09 at 14:31 -0400, Daniel De Graaf wrote: 
>> Ian Campbell wrote:
>> [...]
>>>>> +++ b/xen/xsm/flask/include/av_perm_to_string.h
>>> Also, in that case why is this file checked in?
>>
>> This patch fixes the autogenerated files, but doesn't fully wire them in
>> to things like "make clean" or .{git,hg}ignore. 
>>
> Forgive me for pushing but, while you're here, do you mind taking a look
> and sharing your thoughts about the hunks of the patch touching XSM and
> FLASK? As I said, I've very few experience with that part of Xen, and it
> would be wonderful to know whether what I did looks sane, or I messed
> something up! :-P
> 
> Thanks and Regards,
> Dario
> 

Ah, in my distraction with fixing the autogeneration I neglected to 
finish looking at the original patch. The XSM changes look good except
for a missing implementation of the dummy_nodeaffinity() function in
xen/xsm/dummy.c. However, since the implementation of xsm_nodeaffinity
and xsm_vcpuaffinity are identical, it may be simpler to just merge them
into a common xsm_affinity_domctl hook (as is implemented in
xsm/flask/hooks.c) - in that case, just renaming the existing dummy hook
will suffice.

A more general note on the topic of what XSM permissions to use: 
normally, each domctl has its own permission, and so adding new domctls
would be done by adding a new permission to the access_vectors file
(which is the source of av_perm_to_string.h). However, for this case, it
seems rather unlikely that one would want to allow access to vcpu
affinity and deny node affinity, so using the same permission for both 
accesses is the best solution.

When renaming a permission (such as getvcpuaffinity => getaffinity), the
FLASK policy also needs to be changed - you can normally just grep for
the permission being changed.

The dummy hook would be caught in a compilation with XSM enabled, but I
notice that current xen-unstable will not build due to a patch being
applied out of order (xsm/flask: add domain relabel support requires
rcu_lock_domain_by_any_id which was added in the prior patch). Adding
Keir to CC since he applied the patch.

-- 
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 14:15:07 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 14:15:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLx3W-0007QR-OS; Wed, 10 Oct 2012 14:14:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLx3V-0007QM-7V
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 14:14:37 +0000
Received: from [85.158.138.51:60134] by server-14.bemta-3.messagelabs.com id
	D6/9F-17276-CC285705; Wed, 10 Oct 2012 14:14:36 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1349878474!25815178!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDM1MTAwNg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16176 invoked from network); 10 Oct 2012 14:14:35 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-6.tower-174.messagelabs.com with SMTP;
	10 Oct 2012 14:14:35 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 10 Oct 2012 07:14:33 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,564,1344236400"; d="scan'208";a="232993004"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by fmsmga002.fm.intel.com with ESMTP; 10 Oct 2012 07:14:33 -0700
Received: from FMSMSX110.amr.corp.intel.com (10.19.9.29) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 10 Oct 2012 07:14:32 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	fmsmsx110.amr.corp.intel.com (10.19.9.29) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 10 Oct 2012 07:14:32 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.162]) with mapi id
	14.01.0355.002; Wed, 10 Oct 2012 22:14:31 +0800
From: "Liu, Jinsong" 
To: Ian Campbell 
Thread-Topic: [PATCH 4/5] Xen/MCE: Abort live migration when vMCE occur
Thread-Index: AQHNpsdB0Ej8jZYQ4Um6iJZ1sX/krJeylWQg
Date: Wed, 10 Oct 2012 14:14:30 +0000
Message-ID: 
References: 
	<1349860218.10070.16.camel@zakaz.uk.xensource.com>
In-Reply-To: <1349860218.10070.16.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration when vMCE
	occur
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Updated, thanks! Will send out later.

Ian Campbell wrote:
> On Tue, 2012-09-18 at 14:16 +0100, Liu, Jinsong wrote:
>> Xen/MCE: Abort live migration when vMCE occur
>> 
>> This patch monitor the critical area of live migration (from vMCE
>> point of view, 
>> the copypages stage of migration is the critical area while other
>> areas are not). 
>> 
>> If a vMCE occur at the critical area of live migration, abort and
>> try migration later. 
> 
> Can you elaborate a little on why it is necessary to abort and try
> again?
> 
>> Signed-off-by: Liu, Jinsong 
>> 
>> diff -r f843ac6f93c9 tools/libxc/xc_domain.c
>> --- a/tools/libxc/xc_domain.c	Wed Sep 19 01:21:18 2012 +0800
>> +++ b/tools/libxc/xc_domain.c	Wed Sep 19 03:31:30 2012 +0800 @@
>>      -283,6 +283,37 @@ return ret;
>>  }
>> 
>> +/* Start vmce monitor */
>> +int xc_domain_vmce_monitor_strat(xc_interface *xch,
> 
> strat?
> 
>> +                                 uint32_t domid)
>> +{
>> +    int ret;
>> +    DECLARE_DOMCTL;
>> +
>> +    domctl.cmd = XEN_DOMCTL_vmce_monitor_start;
>> +    domctl.domain = (domid_t)domid;
>> +    ret = do_domctl(xch, &domctl);
>> +
>> +    return ret ? -1 : 0;
>> +}
>> +
>> +/* End vmce monitor */
>> +int xc_domain_vmce_monitor_end(xc_interface *xch,
>> +                               uint32_t domid,
>> +                               signed char *vmce_while_monitor) +{
>> +    int ret;
>> +    DECLARE_DOMCTL;
>> +
>> +    domctl.cmd = XEN_DOMCTL_vmce_monitor_end;
>> +    domctl.domain = (domid_t)domid;
>> +    ret = do_domctl(xch, &domctl);
>> +    if ( !ret )
>> +        *vmce_while_monitor =
>> domctl.u.vmce_monitor.vmce_while_monitor; 
> 
> Any reason this is a char rather than an int?
> 
>> +    return ret ? -1 : 0;
>> +}
>> +
>>  /* get info from hvm guest for save */
>>  int xc_domain_hvm_getcontext(xc_interface *xch,
>>                               uint32_t domid,
>> [...]
>> diff -r f843ac6f93c9 tools/libxc/xenctrl.h
>> --- a/tools/libxc/xenctrl.h	Wed Sep 19 01:21:18 2012 +0800
>> +++ b/tools/libxc/xenctrl.h	Wed Sep 19 03:31:30 2012 +0800 @@ -571,6
>>                            +571,26 @@ xc_domaininfo_t *info);
>> 
>>  /**
>> + * This function start monitor vmce event.
>> + * @parm xch a handle to an open hypervisor interface
>> + * @parm domid the domain id monitored
>> + * @return 0 on success, -1 on failure
>> + */
>> +int xc_domain_vmce_monitor_strat(xc_interface *xch,
>> +                                 uint32_t domid);
>> +
>> +/**
>> + * This function end monitor vmce event
>> + * @parm xch a handle to an open hypervisor interface
>> + * @parm domid the domain id monitored
>> + * @parm vmce_while_migrate a pointer return whether vMCE occur
>> when migrate 
> 
> This function isn't actually specific to migration (even if that
> happens to be the only user currently), it just tracks whether a vMCE
> occurs while monitoring was in progress AFAICT.
> 
>> + * @return 0 on success, -1 on failure
>> + */
>> +int xc_domain_vmce_monitor_end(xc_interface *xch,
>> +                               uint32_t domid,
>> +                               signed char *vmce_while_monitor); +
>> +/**
>>   * This function returns information about the context of a hvm
>> domain 
>>   * @parm xch a handle to an open hypervisor interface
>>   * @parm domid the domain to get information from
>> diff -r f843ac6f93c9 xen/include/asm-x86/domain.h
>> --- a/xen/include/asm-x86/domain.h	Wed Sep 19 01:21:18 2012 +0800
>> +++ b/xen/include/asm-x86/domain.h	Wed Sep 19 03:31:30 2012 +0800 @@
>>      -279,6 +279,11 @@ bool_t has_32bit_shinfo;
>>      /* Domain cannot handle spurious page faults? */
>>      bool_t suppress_spurious_page_faults;
>> +    /* Monitoring guest memory copy of migration
>> +     * = 0 - not monitoring
>> +     * > 0 - monitoring
>> +     * < 0 - vMCE occurred while monitoring */
>> +    s8 vmce_monitor;
>> 
>>      /* Continuable domain_relinquish_resources(). */      enum {
>> diff -r f843ac6f93c9 xen/include/public/domctl.h
>> --- a/xen/include/public/domctl.h	Wed Sep 19 01:21:18 2012 +0800
>> +++ b/xen/include/public/domctl.h	Wed Sep 19 03:31:30 2012 +0800 @@
>>  -828,6 +828,12 @@ typedef struct xen_domctl_set_access_required
>>  xen_domctl_set_access_required_t;
>> DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_access_required_t); 
>> 
>> +struct xen_domctl_vmce_monitor {
>> +    signed char vmce_while_monitor;
> 
> You leak the semantics of the internal flag into this variable which
> makes it rather clumsy to use (e.g. you have to check for <0). This
> should just be a bool I think.
> 
> Calling vmce_monitor_end without a preceding monitor start should be
> an error (-EINVAL?) and this value would be undefined in that case.
> 
> Do you actually need struct xen_domctl_vmce_monitor could the flag not
> be part of the return value of XEN_DOMCTL_vmce_monitor_end? e.g.
> -ERRNO on error, 0 if no vmce, 1 if vmce occurred?
> 
> Also calling vmce_monitor_start while monitoring is already in
> progress should result in -EBUSY, otherwise multiple agents who try
> to monitor will get unexpected/inconsistent results.
> 
>> +};
>> +typedef struct xen_domctl_vmce_monitor xen_domctl_vmce_monitor_t;
>> +DEFINE_XEN_GUEST_HANDLE(xen_domctl_vmce_monitor_t); +
>>  struct xen_domctl {
>>      uint32_t cmd;
>>  #define XEN_DOMCTL_createdomain                   1 @@ -893,6
>>  +899,8 @@ #define XEN_DOMCTL_set_access_required           64
>>  #define XEN_DOMCTL_audit_p2m                     65
>>  #define XEN_DOMCTL_set_virq_handler              66
>> +#define XEN_DOMCTL_vmce_monitor_start            67
>> +#define XEN_DOMCTL_vmce_monitor_end              68
>>  #define XEN_DOMCTL_gdbsx_guestmemio            1000
>>  #define XEN_DOMCTL_gdbsx_pausevcpu             1001
>>  #define XEN_DOMCTL_gdbsx_unpausevcpu           1002 @@ -947,6
>>          +955,7 @@ struct xen_domctl_set_access_required
>>          access_required; struct xen_domctl_audit_p2m        
>>          audit_p2m; struct xen_domctl_set_virq_handler 
>> set_virq_handler; +        struct xen_domctl_vmce_monitor     
>>          vmce_monitor; struct xen_domctl_gdbsx_memio      
>>          gdbsx_guest_memio; struct xen_domctl_gdbsx_pauseunp_vcpu
>>          gdbsx_pauseunp_vcpu; struct xen_domctl_gdbsx_domstatus  
>> gdbsx_domstatus; 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 14:15:07 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 14:15:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLx3W-0007QR-OS; Wed, 10 Oct 2012 14:14:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLx3V-0007QM-7V
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 14:14:37 +0000
Received: from [85.158.138.51:60134] by server-14.bemta-3.messagelabs.com id
	D6/9F-17276-CC285705; Wed, 10 Oct 2012 14:14:36 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1349878474!25815178!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDM1MTAwNg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16176 invoked from network); 10 Oct 2012 14:14:35 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-6.tower-174.messagelabs.com with SMTP;
	10 Oct 2012 14:14:35 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 10 Oct 2012 07:14:33 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,564,1344236400"; d="scan'208";a="232993004"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by fmsmga002.fm.intel.com with ESMTP; 10 Oct 2012 07:14:33 -0700
Received: from FMSMSX110.amr.corp.intel.com (10.19.9.29) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 10 Oct 2012 07:14:32 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	fmsmsx110.amr.corp.intel.com (10.19.9.29) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 10 Oct 2012 07:14:32 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.162]) with mapi id
	14.01.0355.002; Wed, 10 Oct 2012 22:14:31 +0800
From: "Liu, Jinsong" 
To: Ian Campbell 
Thread-Topic: [PATCH 4/5] Xen/MCE: Abort live migration when vMCE occur
Thread-Index: AQHNpsdB0Ej8jZYQ4Um6iJZ1sX/krJeylWQg
Date: Wed, 10 Oct 2012 14:14:30 +0000
Message-ID: 
References: 
	<1349860218.10070.16.camel@zakaz.uk.xensource.com>
In-Reply-To: <1349860218.10070.16.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration when vMCE
	occur
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Updated, thanks! Will send out later.

Ian Campbell wrote:
> On Tue, 2012-09-18 at 14:16 +0100, Liu, Jinsong wrote:
>> Xen/MCE: Abort live migration when vMCE occur
>> 
>> This patch monitor the critical area of live migration (from vMCE
>> point of view, 
>> the copypages stage of migration is the critical area while other
>> areas are not). 
>> 
>> If a vMCE occur at the critical area of live migration, abort and
>> try migration later. 
> 
> Can you elaborate a little on why it is necessary to abort and try
> again?
> 
>> Signed-off-by: Liu, Jinsong 
>> 
>> diff -r f843ac6f93c9 tools/libxc/xc_domain.c
>> --- a/tools/libxc/xc_domain.c	Wed Sep 19 01:21:18 2012 +0800
>> +++ b/tools/libxc/xc_domain.c	Wed Sep 19 03:31:30 2012 +0800 @@
>>      -283,6 +283,37 @@ return ret;
>>  }
>> 
>> +/* Start vmce monitor */
>> +int xc_domain_vmce_monitor_strat(xc_interface *xch,
> 
> strat?
> 
>> +                                 uint32_t domid)
>> +{
>> +    int ret;
>> +    DECLARE_DOMCTL;
>> +
>> +    domctl.cmd = XEN_DOMCTL_vmce_monitor_start;
>> +    domctl.domain = (domid_t)domid;
>> +    ret = do_domctl(xch, &domctl);
>> +
>> +    return ret ? -1 : 0;
>> +}
>> +
>> +/* End vmce monitor */
>> +int xc_domain_vmce_monitor_end(xc_interface *xch,
>> +                               uint32_t domid,
>> +                               signed char *vmce_while_monitor) +{
>> +    int ret;
>> +    DECLARE_DOMCTL;
>> +
>> +    domctl.cmd = XEN_DOMCTL_vmce_monitor_end;
>> +    domctl.domain = (domid_t)domid;
>> +    ret = do_domctl(xch, &domctl);
>> +    if ( !ret )
>> +        *vmce_while_monitor =
>> domctl.u.vmce_monitor.vmce_while_monitor; 
> 
> Any reason this is a char rather than an int?
> 
>> +    return ret ? -1 : 0;
>> +}
>> +
>>  /* get info from hvm guest for save */
>>  int xc_domain_hvm_getcontext(xc_interface *xch,
>>                               uint32_t domid,
>> [...]
>> diff -r f843ac6f93c9 tools/libxc/xenctrl.h
>> --- a/tools/libxc/xenctrl.h	Wed Sep 19 01:21:18 2012 +0800
>> +++ b/tools/libxc/xenctrl.h	Wed Sep 19 03:31:30 2012 +0800 @@ -571,6
>>                            +571,26 @@ xc_domaininfo_t *info);
>> 
>>  /**
>> + * This function start monitor vmce event.
>> + * @parm xch a handle to an open hypervisor interface
>> + * @parm domid the domain id monitored
>> + * @return 0 on success, -1 on failure
>> + */
>> +int xc_domain_vmce_monitor_strat(xc_interface *xch,
>> +                                 uint32_t domid);
>> +
>> +/**
>> + * This function end monitor vmce event
>> + * @parm xch a handle to an open hypervisor interface
>> + * @parm domid the domain id monitored
>> + * @parm vmce_while_migrate a pointer return whether vMCE occur
>> when migrate 
> 
> This function isn't actually specific to migration (even if that
> happens to be the only user currently), it just tracks whether a vMCE
> occurs while monitoring was in progress AFAICT.
> 
>> + * @return 0 on success, -1 on failure
>> + */
>> +int xc_domain_vmce_monitor_end(xc_interface *xch,
>> +                               uint32_t domid,
>> +                               signed char *vmce_while_monitor); +
>> +/**
>>   * This function returns information about the context of a hvm
>> domain 
>>   * @parm xch a handle to an open hypervisor interface
>>   * @parm domid the domain to get information from
>> diff -r f843ac6f93c9 xen/include/asm-x86/domain.h
>> --- a/xen/include/asm-x86/domain.h	Wed Sep 19 01:21:18 2012 +0800
>> +++ b/xen/include/asm-x86/domain.h	Wed Sep 19 03:31:30 2012 +0800 @@
>>      -279,6 +279,11 @@ bool_t has_32bit_shinfo;
>>      /* Domain cannot handle spurious page faults? */
>>      bool_t suppress_spurious_page_faults;
>> +    /* Monitoring guest memory copy of migration
>> +     * = 0 - not monitoring
>> +     * > 0 - monitoring
>> +     * < 0 - vMCE occurred while monitoring */
>> +    s8 vmce_monitor;
>> 
>>      /* Continuable domain_relinquish_resources(). */      enum {
>> diff -r f843ac6f93c9 xen/include/public/domctl.h
>> --- a/xen/include/public/domctl.h	Wed Sep 19 01:21:18 2012 +0800
>> +++ b/xen/include/public/domctl.h	Wed Sep 19 03:31:30 2012 +0800 @@
>>  -828,6 +828,12 @@ typedef struct xen_domctl_set_access_required
>>  xen_domctl_set_access_required_t;
>> DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_access_required_t); 
>> 
>> +struct xen_domctl_vmce_monitor {
>> +    signed char vmce_while_monitor;
> 
> You leak the semantics of the internal flag into this variable which
> makes it rather clumsy to use (e.g. you have to check for <0). This
> should just be a bool I think.
> 
> Calling vmce_monitor_end without a preceding monitor start should be
> an error (-EINVAL?) and this value would be undefined in that case.
> 
> Do you actually need struct xen_domctl_vmce_monitor could the flag not
> be part of the return value of XEN_DOMCTL_vmce_monitor_end? e.g.
> -ERRNO on error, 0 if no vmce, 1 if vmce occurred?
> 
> Also calling vmce_monitor_start while monitoring is already in
> progress should result in -EBUSY, otherwise multiple agents who try
> to monitor will get unexpected/inconsistent results.
> 
>> +};
>> +typedef struct xen_domctl_vmce_monitor xen_domctl_vmce_monitor_t;
>> +DEFINE_XEN_GUEST_HANDLE(xen_domctl_vmce_monitor_t); +
>>  struct xen_domctl {
>>      uint32_t cmd;
>>  #define XEN_DOMCTL_createdomain                   1 @@ -893,6
>>  +899,8 @@ #define XEN_DOMCTL_set_access_required           64
>>  #define XEN_DOMCTL_audit_p2m                     65
>>  #define XEN_DOMCTL_set_virq_handler              66
>> +#define XEN_DOMCTL_vmce_monitor_start            67
>> +#define XEN_DOMCTL_vmce_monitor_end              68
>>  #define XEN_DOMCTL_gdbsx_guestmemio            1000
>>  #define XEN_DOMCTL_gdbsx_pausevcpu             1001
>>  #define XEN_DOMCTL_gdbsx_unpausevcpu           1002 @@ -947,6
>>          +955,7 @@ struct xen_domctl_set_access_required
>>          access_required; struct xen_domctl_audit_p2m        
>>          audit_p2m; struct xen_domctl_set_virq_handler 
>> set_virq_handler; +        struct xen_domctl_vmce_monitor     
>>          vmce_monitor; struct xen_domctl_gdbsx_memio      
>>          gdbsx_guest_memio; struct xen_domctl_gdbsx_pauseunp_vcpu
>>          gdbsx_pauseunp_vcpu; struct xen_domctl_gdbsx_domstatus  
>> gdbsx_domstatus; 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 14:40:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 14:40:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLxSN-0008EK-Nr; Wed, 10 Oct 2012 14:40:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLxSL-0008EA-N3
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 14:40:17 +0000
Received: from [85.158.137.99:27860] by server-15.bemta-3.messagelabs.com id
	9A/88-10261-CC885705; Wed, 10 Oct 2012 14:40:12 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1349880010!21018971!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM3MzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12180 invoked from network); 10 Oct 2012 14:40:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 14:40:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; 
	d="asc'?scan'208";a="15077957"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 14:39:49 +0000
Received: from [IPv6:::1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 10 Oct 2012 15:39:49 +0100
Message-ID: <1349879988.3610.194.camel@Abyss>
From: Dario Faggioli 
To: Daniel De Graaf 
Date: Wed, 10 Oct 2012 15:39:48 +0100
In-Reply-To: <50758038.6050009@tycho.nsa.gov>
References: <1349801565.21847.228.camel@zakaz.uk.xensource.com>
	<1349807513-10923-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1349858695.3610.158.camel@Abyss> <50758038.6050009@tycho.nsa.gov>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
MIME-Version: 1.0
Cc: Marcus Granado ,
	"andre.przywara@amd.com" ,
	Ian Campbell ,
	"anil@recoil.org" ,
	George Dunlap ,
	Andrew Cooper ,
	"juergen.gross@ts.fujitsu.com" ,
	Ian Jackson ,
	"xen-devel@lists.xen.org" ,
	"JBeulich@suse.com" ,
	"msw@amazon.com" , "Keir \(Xen.org\)" 
Subject: Re: [Xen-devel] [PATCH RFC] flask: move policy header sources into
 hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============6714192692552890345=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6714192692552890345==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-RZPLawl4HIKX8ofqAOV5"

--=-RZPLawl4HIKX8ofqAOV5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-10-10 at 15:03 +0100, Daniel De Graaf wrote:=20
> Ah, in my distraction with fixing the autogeneration I neglected to=20
> finish looking at the original patch.
>
:-)

> The XSM changes look good except
> for a missing implementation of the dummy_nodeaffinity() function in
> xen/xsm/dummy.c. However, since the implementation of xsm_nodeaffinity
> and xsm_vcpuaffinity are identical, it may be simpler to just merge them
> into a common xsm_affinity_domctl hook (as is implemented in
> xsm/flask/hooks.c) - in that case, just renaming the existing dummy hook
> will suffice.
>=20
Ok, thanks. I will do that.

> A more general note on the topic of what XSM permissions to use:=20
> normally, each domctl has its own permission, and so adding new domctls
> would be done by adding a new permission to the access_vectors file
> (which is the source of av_perm_to_string.h). However, for this case, it
> seems rather unlikely that one would want to allow access to vcpu
> affinity and deny node affinity, so using the same permission for both=
=20
> accesses is the best solution.
>=20
Yes, exactly.

Moreover, looking at xen/xsm/flask/include/av_permissions.h where
DOMAIN__{GET,SET}VCPUAFFINITY are, I got thee impression that there is
no more space left for DOMAIN__* permissions, as they already go from
0x00000001UL to 0x80000000UL... Is that so?

> When renaming a permission (such as getvcpuaffinity =3D> getaffinity), th=
e
> FLASK policy also needs to be changed - you can normally just grep for
> the permission being changed.
>=20
Ok and thanks again. I will do that too...

> The dummy hook would be caught in a compilation with XSM enabled, but I
> notice that current xen-unstable will not build due to a patch being
> applied out of order (xsm/flask: add domain relabel support requires
> rcu_lock_domain_by_any_id which was added in the prior patch). Adding
> Keir to CC since he applied the patch.
>=20
... As well as I will try to check for this for next round (hoping that
by that time the issue you're describing here would be fixed :-)).

Thanks a lot and Regards,
Dario

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-RZPLawl4HIKX8ofqAOV5
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlB1iLQACgkQk4XaBE3IOsRI6gCePQEYE6oUPGBJWzUwCUyYv2uF
NBkAn3tq1BWef5CbWn4tOTEbueOh0/65
=oPcO
-----END PGP SIGNATURE-----

--=-RZPLawl4HIKX8ofqAOV5--


--===============6714192692552890345==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6714192692552890345==--


From xen-devel-bounces@lists.xen.org Wed Oct 10 14:40:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 14:40:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLxSN-0008EK-Nr; Wed, 10 Oct 2012 14:40:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLxSL-0008EA-N3
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 14:40:17 +0000
Received: from [85.158.137.99:27860] by server-15.bemta-3.messagelabs.com id
	9A/88-10261-CC885705; Wed, 10 Oct 2012 14:40:12 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1349880010!21018971!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM3MzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12180 invoked from network); 10 Oct 2012 14:40:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 14:40:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; 
	d="asc'?scan'208";a="15077957"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 14:39:49 +0000
Received: from [IPv6:::1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 10 Oct 2012 15:39:49 +0100
Message-ID: <1349879988.3610.194.camel@Abyss>
From: Dario Faggioli 
To: Daniel De Graaf 
Date: Wed, 10 Oct 2012 15:39:48 +0100
In-Reply-To: <50758038.6050009@tycho.nsa.gov>
References: <1349801565.21847.228.camel@zakaz.uk.xensource.com>
	<1349807513-10923-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1349858695.3610.158.camel@Abyss> <50758038.6050009@tycho.nsa.gov>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
MIME-Version: 1.0
Cc: Marcus Granado ,
	"andre.przywara@amd.com" ,
	Ian Campbell ,
	"anil@recoil.org" ,
	George Dunlap ,
	Andrew Cooper ,
	"juergen.gross@ts.fujitsu.com" ,
	Ian Jackson ,
	"xen-devel@lists.xen.org" ,
	"JBeulich@suse.com" ,
	"msw@amazon.com" , "Keir \(Xen.org\)" 
Subject: Re: [Xen-devel] [PATCH RFC] flask: move policy header sources into
 hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============6714192692552890345=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6714192692552890345==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-RZPLawl4HIKX8ofqAOV5"

--=-RZPLawl4HIKX8ofqAOV5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-10-10 at 15:03 +0100, Daniel De Graaf wrote:=20
> Ah, in my distraction with fixing the autogeneration I neglected to=20
> finish looking at the original patch.
>
:-)

> The XSM changes look good except
> for a missing implementation of the dummy_nodeaffinity() function in
> xen/xsm/dummy.c. However, since the implementation of xsm_nodeaffinity
> and xsm_vcpuaffinity are identical, it may be simpler to just merge them
> into a common xsm_affinity_domctl hook (as is implemented in
> xsm/flask/hooks.c) - in that case, just renaming the existing dummy hook
> will suffice.
>=20
Ok, thanks. I will do that.

> A more general note on the topic of what XSM permissions to use:=20
> normally, each domctl has its own permission, and so adding new domctls
> would be done by adding a new permission to the access_vectors file
> (which is the source of av_perm_to_string.h). However, for this case, it
> seems rather unlikely that one would want to allow access to vcpu
> affinity and deny node affinity, so using the same permission for both=
=20
> accesses is the best solution.
>=20
Yes, exactly.

Moreover, looking at xen/xsm/flask/include/av_permissions.h where
DOMAIN__{GET,SET}VCPUAFFINITY are, I got thee impression that there is
no more space left for DOMAIN__* permissions, as they already go from
0x00000001UL to 0x80000000UL... Is that so?

> When renaming a permission (such as getvcpuaffinity =3D> getaffinity), th=
e
> FLASK policy also needs to be changed - you can normally just grep for
> the permission being changed.
>=20
Ok and thanks again. I will do that too...

> The dummy hook would be caught in a compilation with XSM enabled, but I
> notice that current xen-unstable will not build due to a patch being
> applied out of order (xsm/flask: add domain relabel support requires
> rcu_lock_domain_by_any_id which was added in the prior patch). Adding
> Keir to CC since he applied the patch.
>=20
... As well as I will try to check for this for next round (hoping that
by that time the issue you're describing here would be fixed :-)).

Thanks a lot and Regards,
Dario

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-RZPLawl4HIKX8ofqAOV5
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlB1iLQACgkQk4XaBE3IOsRI6gCePQEYE6oUPGBJWzUwCUyYv2uF
NBkAn3tq1BWef5CbWn4tOTEbueOh0/65
=oPcO
-----END PGP SIGNATURE-----

--=-RZPLawl4HIKX8ofqAOV5--


--===============6714192692552890345==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6714192692552890345==--


From xen-devel-bounces@lists.xen.org Wed Oct 10 14:41:18 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 14:41:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLxT5-0008IT-A2; Wed, 10 Oct 2012 14:41:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLxT4-0008II-Qo
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 14:41:03 +0000
Received: from [85.158.143.35:40237] by server-2.bemta-4.messagelabs.com id
	9C/6F-25171-EF885705; Wed, 10 Oct 2012 14:41:02 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-21.messagelabs.com!1349880055!10771913!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0Mjc1MTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0Mjc1MTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1390 invoked from network); 10 Oct 2012 14:40:56 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Oct 2012 14:40:56 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0Kfg==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-004.pools.arcor-ip.net [88.65.70.4])
	by smtp.strato.de (jorabe mo47) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id K05ff0o9ADpHhp
	for ; Wed, 10 Oct 2012 16:40:54 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 4AFA6183A7
	for ; Wed, 10 Oct 2012 16:40:54 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: a74e22faa1c90a38345be8fdf333101c07166671
Message-Id: 
User-Agent: Mercurial-patchbomb/1.7.5
Date: Wed, 10 Oct 2012 16:40:53 +0200
From: Olaf Hering 
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] stubdom: fix compile errors in grub
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering 
# Date 1349880048 -7200
# Node ID a74e22faa1c90a38345be8fdf333101c07166671
# Parent  384714804b9b2a9742cc45dffaa43b749b85513b
stubdom: fix compile errors in grub

Building xen.rpm in SLES11 started to fail due to these compiler
warnings:

[ 1436s] ../grub-upstream/netboot/fsys_tftp.c:213: warning: operation on 'block' may be undefined
[ 1437s] ../grub-upstream/netboot/main.c:444: warning: operation on 'block' may be undefined

[ 1234s] E: xen sequence-point ../grub-upstream/netboot/fsys_tftp.c:213
[ 1234s] E: xen sequence-point ../grub-upstream/netboot/main.c:444

The reason for this is that the assignment is done twice:
 tp.u.ack.block = ((uint16_t)( (((uint16_t)((block = prevblock)) & (uint16_t)0x00ffU) << 8) | (((uint16_t)((block = prevblock)) & (uint16_t)0xff00U) >> 8)));

Fix this package build error by adding another patch for grub, which
moves the assignment out of the macro usage.

Signed-off-by: Olaf Hering 

diff -r 384714804b9b -r a74e22faa1c9 stubdom/grub.patches/70compiler_warnings.diff
--- /dev/null
+++ b/stubdom/grub.patches/70compiler_warnings.diff
@@ -0,0 +1,45 @@
+[ 1436s] ../grub-upstream/netboot/fsys_tftp.c:213: warning: operation on 'block' may be undefined
+[ 1437s] ../grub-upstream/netboot/main.c:444: warning: operation on 'block' may be undefined
+
+[ 1234s] E: xen sequence-point ../grub-upstream/netboot/fsys_tftp.c:213
+[ 1234s] E: xen sequence-point ../grub-upstream/netboot/main.c:444
+
+---
+ netboot/fsys_tftp.c |    5 ++++-
+ netboot/main.c      |    5 ++++-
+ 2 files changed, 8 insertions(+), 2 deletions(-)
+
+Index: grub-0.97/netboot/fsys_tftp.c
+===================================================================
+--- grub-0.97.orig/netboot/fsys_tftp.c
++++ grub-0.97/netboot/fsys_tftp.c
+@@ -209,8 +209,11 @@ buf_fill (int abort)
+ 	break;
+ 
+       if ((block || bcounter) && (block != prevblock + (unsigned short) 1))
++      {
++	      block = prevblock;
+ 	/* Block order should be continuous */
+-	tp.u.ack.block = htons (block = prevblock);
++	tp.u.ack.block = htons (block);
++      }
+       
+       /* Should be continuous.  */
+       tp.opcode = abort ? htons (TFTP_ERROR) : htons (TFTP_ACK);
+Index: grub-0.97/netboot/main.c
+===================================================================
+--- grub-0.97.orig/netboot/main.c
++++ grub-0.97/netboot/main.c
+@@ -440,8 +440,11 @@ tftp (const char *name, int (*fnc) (unsi
+ 	break;
+       
+       if ((block || bcounter) && (block != prevblock + 1))
++      {
++	      block = prevblock;
+ 	/* Block order should be continuous */
+-	tp.u.ack.block = htons (block = prevblock);
++	tp.u.ack.block = htons (block);
++      }
+       
+       /* Should be continuous.  */
+       tp.opcode = htons (TFTP_ACK);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 14:41:18 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 14:41:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLxT5-0008IT-A2; Wed, 10 Oct 2012 14:41:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLxT4-0008II-Qo
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 14:41:03 +0000
Received: from [85.158.143.35:40237] by server-2.bemta-4.messagelabs.com id
	9C/6F-25171-EF885705; Wed, 10 Oct 2012 14:41:02 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-21.messagelabs.com!1349880055!10771913!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0Mjc1MTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0Mjc1MTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1390 invoked from network); 10 Oct 2012 14:40:56 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Oct 2012 14:40:56 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0Kfg==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-004.pools.arcor-ip.net [88.65.70.4])
	by smtp.strato.de (jorabe mo47) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id K05ff0o9ADpHhp
	for ; Wed, 10 Oct 2012 16:40:54 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 4AFA6183A7
	for ; Wed, 10 Oct 2012 16:40:54 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: a74e22faa1c90a38345be8fdf333101c07166671
Message-Id: 
User-Agent: Mercurial-patchbomb/1.7.5
Date: Wed, 10 Oct 2012 16:40:53 +0200
From: Olaf Hering 
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] stubdom: fix compile errors in grub
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering 
# Date 1349880048 -7200
# Node ID a74e22faa1c90a38345be8fdf333101c07166671
# Parent  384714804b9b2a9742cc45dffaa43b749b85513b
stubdom: fix compile errors in grub

Building xen.rpm in SLES11 started to fail due to these compiler
warnings:

[ 1436s] ../grub-upstream/netboot/fsys_tftp.c:213: warning: operation on 'block' may be undefined
[ 1437s] ../grub-upstream/netboot/main.c:444: warning: operation on 'block' may be undefined

[ 1234s] E: xen sequence-point ../grub-upstream/netboot/fsys_tftp.c:213
[ 1234s] E: xen sequence-point ../grub-upstream/netboot/main.c:444

The reason for this is that the assignment is done twice:
 tp.u.ack.block = ((uint16_t)( (((uint16_t)((block = prevblock)) & (uint16_t)0x00ffU) << 8) | (((uint16_t)((block = prevblock)) & (uint16_t)0xff00U) >> 8)));

Fix this package build error by adding another patch for grub, which
moves the assignment out of the macro usage.

Signed-off-by: Olaf Hering 

diff -r 384714804b9b -r a74e22faa1c9 stubdom/grub.patches/70compiler_warnings.diff
--- /dev/null
+++ b/stubdom/grub.patches/70compiler_warnings.diff
@@ -0,0 +1,45 @@
+[ 1436s] ../grub-upstream/netboot/fsys_tftp.c:213: warning: operation on 'block' may be undefined
+[ 1437s] ../grub-upstream/netboot/main.c:444: warning: operation on 'block' may be undefined
+
+[ 1234s] E: xen sequence-point ../grub-upstream/netboot/fsys_tftp.c:213
+[ 1234s] E: xen sequence-point ../grub-upstream/netboot/main.c:444
+
+---
+ netboot/fsys_tftp.c |    5 ++++-
+ netboot/main.c      |    5 ++++-
+ 2 files changed, 8 insertions(+), 2 deletions(-)
+
+Index: grub-0.97/netboot/fsys_tftp.c
+===================================================================
+--- grub-0.97.orig/netboot/fsys_tftp.c
++++ grub-0.97/netboot/fsys_tftp.c
+@@ -209,8 +209,11 @@ buf_fill (int abort)
+ 	break;
+ 
+       if ((block || bcounter) && (block != prevblock + (unsigned short) 1))
++      {
++	      block = prevblock;
+ 	/* Block order should be continuous */
+-	tp.u.ack.block = htons (block = prevblock);
++	tp.u.ack.block = htons (block);
++      }
+       
+       /* Should be continuous.  */
+       tp.opcode = abort ? htons (TFTP_ERROR) : htons (TFTP_ACK);
+Index: grub-0.97/netboot/main.c
+===================================================================
+--- grub-0.97.orig/netboot/main.c
++++ grub-0.97/netboot/main.c
+@@ -440,8 +440,11 @@ tftp (const char *name, int (*fnc) (unsi
+ 	break;
+       
+       if ((block || bcounter) && (block != prevblock + 1))
++      {
++	      block = prevblock;
+ 	/* Block order should be continuous */
+-	tp.u.ack.block = htons (block = prevblock);
++	tp.u.ack.block = htons (block);
++      }
+       
+       /* Should be continuous.  */
+       tp.opcode = htons (TFTP_ACK);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 14:42:54 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 14:42:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLxUa-0008Sr-PQ; Wed, 10 Oct 2012 14:42:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLxUZ-0008Sa-Qg
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 14:42:36 +0000
Received: from [85.158.143.35:46821] by server-3.bemta-4.messagelabs.com id
	C8/F4-10075-B5985705; Wed, 10 Oct 2012 14:42:35 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1349880153!15329207!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDM1MTAwNg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12515 invoked from network); 10 Oct 2012 14:42:34 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-13.tower-21.messagelabs.com with SMTP;
	10 Oct 2012 14:42:34 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 10 Oct 2012 07:42:32 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,564,1344236400"; d="scan'208";a="232243059"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by fmsmga001.fm.intel.com with ESMTP; 10 Oct 2012 07:42:32 -0700
Received: from fmsmsx151.amr.corp.intel.com (10.19.17.220) by
	FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 10 Oct 2012 07:42:32 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX151.amr.corp.intel.com (10.19.17.220) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 10 Oct 2012 07:42:31 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Wed, 10 Oct 2012 22:42:30 +0800
From: "Liu, Jinsong" 
To: Ian Campbell 
Thread-Topic: [PATCH 5/5] X86/vMCE: guest broken page handling when migration
Thread-Index: AQHNpsiqcuuLNohtZEuHrJ7NiXQ39Zeymq3A
Date: Wed, 10 Oct 2012 14:42:30 +0000
Message-ID: 
References: 
	<1349860894.10070.21.camel@zakaz.uk.xensource.com>
In-Reply-To: <1349860894.10070.21.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 5/5] X86/vMCE: guest broken page handling
	when migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Updated, thanks! w/ some comments below, will send out later.

Ian Campbell wrote:
> On Wed, 2012-09-19 at 09:15 +0100, Liu, Jinsong wrote:
>> X86/vMCE: guest broken page handling when migration
>> 
>> This patch is used to handle guest broken page when migration.
>> 
>> At sender, the broken page would not be mapped, and the error page
>> content would not be copied to target, otherwise it may trigger more
>> serious error (i.e. SRAR error). While its pfn_type and pfn number
>> would be transferred to target so that target take appropriate
>> action. 
>> 
>> At target, it would set p2m as p2m_ram_broken for broken page, so
>> that 
>> if guest access the broken page again, it would kill guest as
>> expected. 
>> 
>> Signed-off-by: Liu, Jinsong 
>> 
>> diff -r a1d106d1aec8 tools/libxc/xc_domain.c
>> --- a/tools/libxc/xc_domain.c	Wed Sep 19 03:31:31 2012 +0800
>> +++ b/tools/libxc/xc_domain.c	Wed Sep 19 04:22:26 2012 +0800 @@
>>      -314,6 +314,22 @@ return ret ? -1 : 0;
>>  }
>> 
>> +/* set broken page p2m */
>> +int xc_set_broken_page_p2m(xc_interface *xch,
>> +                           uint32_t domid,
>> +                           unsigned long pfn)
>> +{
>> +    int ret;
>> +    DECLARE_DOMCTL;
>> +
>> +    domctl.cmd = XEN_DOMCTL_set_broken_page_p2m;
>> +    domctl.domain = (domid_t)domid;
>> +    domctl.u.set_broken_page_p2m.pfn = pfn;
>> +    ret = do_domctl(xch, &domctl);
>> +
>> +    return ret ? -1 : 0;
>> +}
>> +
>>  /* get info from hvm guest for save */
>>  int xc_domain_hvm_getcontext(xc_interface *xch,
>>                               uint32_t domid,
>> diff -r a1d106d1aec8 tools/libxc/xc_domain_restore.c
>> --- a/tools/libxc/xc_domain_restore.c	Wed Sep 19 03:31:31 2012 +0800
>> +++ b/tools/libxc/xc_domain_restore.c	Wed Sep 19 04:22:26 2012 +0800
>> @@ -962,9 +962,15 @@ 
>> 
>>      countpages = count;
>>      for (i = oldcount; i < buf->nr_pages; ++i)
>> -        if ((buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) ==
>> XEN_DOMCTL_PFINFO_XTAB 
>> -            ||(buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) ==
>> XEN_DOMCTL_PFINFO_XALLOC) +    { +        unsigned long pagetype;
>> +
>> +        pagetype = buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK;
>> +        if ( pagetype == XEN_DOMCTL_PFINFO_XTAB ||
>> +             pagetype == XEN_DOMCTL_PFINFO_BROKEN ||
>> +             pagetype == XEN_DOMCTL_PFINFO_XALLOC )             
>> --countpages; +    }
>> 
>>      if (!countpages)
>>          return count;
>> @@ -1200,6 +1206,17 @@
>>              /* a bogus/unmapped/allocate-only page: skip it */     
>> continue; 
>> 
>> +        if ( pagetype == XEN_DOMCTL_PFINFO_BROKEN ) +        {
>> +            if ( xc_set_broken_page_p2m(xch, dom, pfn) ) +         
>> { +                ERROR("Set p2m for broken page fail, "
> 
> "failed"
> 
>> +                      "dom=%d, pfn=%lx\n", dom, pfn);
>> +                goto err_mapped;
>> +            }
>> +            continue;
>> +        }
>> +
>>          if (pfn_err[i])
>>          {
>>              ERROR("unexpected PFN mapping failure pfn %lx map_mfn
>> %lx p2m_mfn %lx", 
>> diff -r a1d106d1aec8 xen/include/public/domctl.h
>> --- a/xen/include/public/domctl.h	Wed Sep 19 03:31:31 2012 +0800
>> +++ b/xen/include/public/domctl.h	Wed Sep 19 04:22:26 2012 +0800 @@
>>  -136,6 +136,7 @@ #define XEN_DOMCTL_PFINFO_LPINTAB (0x1U<<31)
>>  #define XEN_DOMCTL_PFINFO_XTAB    (0xfU<<28) /* invalid page */
>>  #define XEN_DOMCTL_PFINFO_XALLOC  (0xeU<<28) /* allocate-only page
>> */ +#define XEN_DOMCTL_PFINFO_BROKEN  (0xdU<<28) /* broken page */
>>  #define XEN_DOMCTL_PFINFO_PAGEDTAB (0x8U<<28)
>>  #define XEN_DOMCTL_PFINFO_LTAB_MASK (0xfU<<28)
>> 
>> @@ -834,6 +835,12 @@
>>  typedef struct xen_domctl_vmce_monitor xen_domctl_vmce_monitor_t;
>>  DEFINE_XEN_GUEST_HANDLE(xen_domctl_vmce_monitor_t);
>> 
>> +struct xen_domctl_set_broken_page_p2m {
>> +    uint64_t pfn;
>> +};
> 
> why not xen_pfn_t? or uint64_aligned_t?
> 
> Is domctl the right interface for this? Seems like more of an add to
> physmap thing?
> 

Hmm, broken page still belong to the domain so don't need touch physmap (like what mce handle broken page at sender side: just unmap p2m is OK). As for domctl, my thinking is, it's per domain staff (belong to the field of domain control/management), setting p2m entry for broken page of a domain.

Thanks,
Jinsong

>> +typedef struct xen_domctl_set_broken_page_p2m
>> xen_domctl_set_broken_page_p2m_t;
>>  +DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_broken_page_p2m_t); +
>>      struct xen_domctl { uint32_t cmd;
>>  #define XEN_DOMCTL_createdomain                   1 @@ -901,6
>>  +908,7 @@ #define XEN_DOMCTL_set_virq_handler              66
>>  #define XEN_DOMCTL_vmce_monitor_start            67
>>  #define XEN_DOMCTL_vmce_monitor_end              68
>> +#define XEN_DOMCTL_set_broken_page_p2m           69
>>  #define XEN_DOMCTL_gdbsx_guestmemio            1000
>>  #define XEN_DOMCTL_gdbsx_pausevcpu             1001
>>  #define XEN_DOMCTL_gdbsx_unpausevcpu           1002 @@ -957,6
>>          +965,7 @@ struct xen_domctl_set_virq_handler 
>>          set_virq_handler; struct xen_domctl_vmce_monitor     
>>          vmce_monitor; struct xen_domctl_gdbsx_memio      
>> gdbsx_guest_memio; +        struct xen_domctl_set_broken_page_p2m
>>          set_broken_page_p2m; struct xen_domctl_gdbsx_pauseunp_vcpu
>>          gdbsx_pauseunp_vcpu; struct xen_domctl_gdbsx_domstatus  
>>          gdbsx_domstatus; uint8_t                            
>> pad[128]; 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 14:42:54 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 14:42:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLxUa-0008Sr-PQ; Wed, 10 Oct 2012 14:42:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLxUZ-0008Sa-Qg
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 14:42:36 +0000
Received: from [85.158.143.35:46821] by server-3.bemta-4.messagelabs.com id
	C8/F4-10075-B5985705; Wed, 10 Oct 2012 14:42:35 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1349880153!15329207!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDM1MTAwNg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12515 invoked from network); 10 Oct 2012 14:42:34 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-13.tower-21.messagelabs.com with SMTP;
	10 Oct 2012 14:42:34 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 10 Oct 2012 07:42:32 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,564,1344236400"; d="scan'208";a="232243059"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by fmsmga001.fm.intel.com with ESMTP; 10 Oct 2012 07:42:32 -0700
Received: from fmsmsx151.amr.corp.intel.com (10.19.17.220) by
	FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 10 Oct 2012 07:42:32 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX151.amr.corp.intel.com (10.19.17.220) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 10 Oct 2012 07:42:31 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Wed, 10 Oct 2012 22:42:30 +0800
From: "Liu, Jinsong" 
To: Ian Campbell 
Thread-Topic: [PATCH 5/5] X86/vMCE: guest broken page handling when migration
Thread-Index: AQHNpsiqcuuLNohtZEuHrJ7NiXQ39Zeymq3A
Date: Wed, 10 Oct 2012 14:42:30 +0000
Message-ID: 
References: 
	<1349860894.10070.21.camel@zakaz.uk.xensource.com>
In-Reply-To: <1349860894.10070.21.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 5/5] X86/vMCE: guest broken page handling
	when migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Updated, thanks! w/ some comments below, will send out later.

Ian Campbell wrote:
> On Wed, 2012-09-19 at 09:15 +0100, Liu, Jinsong wrote:
>> X86/vMCE: guest broken page handling when migration
>> 
>> This patch is used to handle guest broken page when migration.
>> 
>> At sender, the broken page would not be mapped, and the error page
>> content would not be copied to target, otherwise it may trigger more
>> serious error (i.e. SRAR error). While its pfn_type and pfn number
>> would be transferred to target so that target take appropriate
>> action. 
>> 
>> At target, it would set p2m as p2m_ram_broken for broken page, so
>> that 
>> if guest access the broken page again, it would kill guest as
>> expected. 
>> 
>> Signed-off-by: Liu, Jinsong 
>> 
>> diff -r a1d106d1aec8 tools/libxc/xc_domain.c
>> --- a/tools/libxc/xc_domain.c	Wed Sep 19 03:31:31 2012 +0800
>> +++ b/tools/libxc/xc_domain.c	Wed Sep 19 04:22:26 2012 +0800 @@
>>      -314,6 +314,22 @@ return ret ? -1 : 0;
>>  }
>> 
>> +/* set broken page p2m */
>> +int xc_set_broken_page_p2m(xc_interface *xch,
>> +                           uint32_t domid,
>> +                           unsigned long pfn)
>> +{
>> +    int ret;
>> +    DECLARE_DOMCTL;
>> +
>> +    domctl.cmd = XEN_DOMCTL_set_broken_page_p2m;
>> +    domctl.domain = (domid_t)domid;
>> +    domctl.u.set_broken_page_p2m.pfn = pfn;
>> +    ret = do_domctl(xch, &domctl);
>> +
>> +    return ret ? -1 : 0;
>> +}
>> +
>>  /* get info from hvm guest for save */
>>  int xc_domain_hvm_getcontext(xc_interface *xch,
>>                               uint32_t domid,
>> diff -r a1d106d1aec8 tools/libxc/xc_domain_restore.c
>> --- a/tools/libxc/xc_domain_restore.c	Wed Sep 19 03:31:31 2012 +0800
>> +++ b/tools/libxc/xc_domain_restore.c	Wed Sep 19 04:22:26 2012 +0800
>> @@ -962,9 +962,15 @@ 
>> 
>>      countpages = count;
>>      for (i = oldcount; i < buf->nr_pages; ++i)
>> -        if ((buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) ==
>> XEN_DOMCTL_PFINFO_XTAB 
>> -            ||(buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) ==
>> XEN_DOMCTL_PFINFO_XALLOC) +    { +        unsigned long pagetype;
>> +
>> +        pagetype = buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK;
>> +        if ( pagetype == XEN_DOMCTL_PFINFO_XTAB ||
>> +             pagetype == XEN_DOMCTL_PFINFO_BROKEN ||
>> +             pagetype == XEN_DOMCTL_PFINFO_XALLOC )             
>> --countpages; +    }
>> 
>>      if (!countpages)
>>          return count;
>> @@ -1200,6 +1206,17 @@
>>              /* a bogus/unmapped/allocate-only page: skip it */     
>> continue; 
>> 
>> +        if ( pagetype == XEN_DOMCTL_PFINFO_BROKEN ) +        {
>> +            if ( xc_set_broken_page_p2m(xch, dom, pfn) ) +         
>> { +                ERROR("Set p2m for broken page fail, "
> 
> "failed"
> 
>> +                      "dom=%d, pfn=%lx\n", dom, pfn);
>> +                goto err_mapped;
>> +            }
>> +            continue;
>> +        }
>> +
>>          if (pfn_err[i])
>>          {
>>              ERROR("unexpected PFN mapping failure pfn %lx map_mfn
>> %lx p2m_mfn %lx", 
>> diff -r a1d106d1aec8 xen/include/public/domctl.h
>> --- a/xen/include/public/domctl.h	Wed Sep 19 03:31:31 2012 +0800
>> +++ b/xen/include/public/domctl.h	Wed Sep 19 04:22:26 2012 +0800 @@
>>  -136,6 +136,7 @@ #define XEN_DOMCTL_PFINFO_LPINTAB (0x1U<<31)
>>  #define XEN_DOMCTL_PFINFO_XTAB    (0xfU<<28) /* invalid page */
>>  #define XEN_DOMCTL_PFINFO_XALLOC  (0xeU<<28) /* allocate-only page
>> */ +#define XEN_DOMCTL_PFINFO_BROKEN  (0xdU<<28) /* broken page */
>>  #define XEN_DOMCTL_PFINFO_PAGEDTAB (0x8U<<28)
>>  #define XEN_DOMCTL_PFINFO_LTAB_MASK (0xfU<<28)
>> 
>> @@ -834,6 +835,12 @@
>>  typedef struct xen_domctl_vmce_monitor xen_domctl_vmce_monitor_t;
>>  DEFINE_XEN_GUEST_HANDLE(xen_domctl_vmce_monitor_t);
>> 
>> +struct xen_domctl_set_broken_page_p2m {
>> +    uint64_t pfn;
>> +};
> 
> why not xen_pfn_t? or uint64_aligned_t?
> 
> Is domctl the right interface for this? Seems like more of an add to
> physmap thing?
> 

Hmm, broken page still belong to the domain so don't need touch physmap (like what mce handle broken page at sender side: just unmap p2m is OK). As for domctl, my thinking is, it's per domain staff (belong to the field of domain control/management), setting p2m entry for broken page of a domain.

Thanks,
Jinsong

>> +typedef struct xen_domctl_set_broken_page_p2m
>> xen_domctl_set_broken_page_p2m_t;
>>  +DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_broken_page_p2m_t); +
>>      struct xen_domctl { uint32_t cmd;
>>  #define XEN_DOMCTL_createdomain                   1 @@ -901,6
>>  +908,7 @@ #define XEN_DOMCTL_set_virq_handler              66
>>  #define XEN_DOMCTL_vmce_monitor_start            67
>>  #define XEN_DOMCTL_vmce_monitor_end              68
>> +#define XEN_DOMCTL_set_broken_page_p2m           69
>>  #define XEN_DOMCTL_gdbsx_guestmemio            1000
>>  #define XEN_DOMCTL_gdbsx_pausevcpu             1001
>>  #define XEN_DOMCTL_gdbsx_unpausevcpu           1002 @@ -957,6
>>          +965,7 @@ struct xen_domctl_set_virq_handler 
>>          set_virq_handler; struct xen_domctl_vmce_monitor     
>>          vmce_monitor; struct xen_domctl_gdbsx_memio      
>> gdbsx_guest_memio; +        struct xen_domctl_set_broken_page_p2m
>>          set_broken_page_p2m; struct xen_domctl_gdbsx_pauseunp_vcpu
>>          gdbsx_pauseunp_vcpu; struct xen_domctl_gdbsx_domstatus  
>>          gdbsx_domstatus; uint8_t                            
>> pad[128]; 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 14:46:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 14:46:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLxYI-0000J7-EU; Wed, 10 Oct 2012 14:46:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLxYG-0000Iq-Aj
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 14:46:24 +0000
Received: from [85.158.139.83:55153] by server-16.bemta-5.messagelabs.com id
	EE/A1-10155-F3A85705; Wed, 10 Oct 2012 14:46:23 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1349880380!27051570!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjE2NDY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5429 invoked from network); 10 Oct 2012 14:46:21 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-11.tower-182.messagelabs.com with SMTP;
	10 Oct 2012 14:46:21 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 10 Oct 2012 07:46:19 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,564,1344236400"; d="scan'208";a="154635063"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by AZSMGA002.ch.intel.com with ESMTP; 10 Oct 2012 07:46:18 -0700
Received: from fmsmsx102.amr.corp.intel.com (10.19.9.53) by
	FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 10 Oct 2012 07:46:18 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX102.amr.corp.intel.com (10.19.9.53) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 10 Oct 2012 07:46:17 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Wed, 10 Oct 2012 22:46:16 +0800
From: "Liu, Jinsong" 
To: Ian Campbell , "xen-devel@lists.xensource.com"
	
Thread-Topic: [PATCH 4/5] Xen/MCE: Abort live migration when vMCE occur
Thread-Index: Ac2m9gA+ufJylTqUQruxPOzNlQzaHQ==
Date: Wed, 10 Oct 2012 14:46:16 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC829233534A62FSHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: Ian Jackson ,
	Christoph Egger ,
	"Keir \(Xen.org\)" , Jan Beulich 
Subject: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration when vMCE
	occur
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC829233534A62FSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Xen/MCE: Abort live migration when vMCE occur

This patch monitor the critical area of live migration (from vMCE point of =
view,
the copypages stage of migration is the critical area while other areas are=
 not).

If a vMCE occur at the critical area of live migration, there is risk that =
error
data may be copied to the target. Currently we don't have convenient way to=
 handle
this case, so for the sake of safe, we abort it and try migration later (at=
 that
time broken page would not be mapped and copied to the target).

Signed-off-by: Liu, Jinsong 

diff -r e27a6d53ac15 tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c	Thu Oct 11 01:52:33 2012 +0800
+++ b/tools/libxc/xc_domain.c	Thu Oct 11 05:12:48 2012 +0800
@@ -283,6 +283,30 @@
     return ret;
 }
=20
+/* Start vmce monitor */
+int xc_domain_vmce_monitor_start(xc_interface *xch,
+                                 uint32_t domid)
+{
+    DECLARE_DOMCTL;
+
+    domctl.cmd =3D XEN_DOMCTL_vmce_monitor_start;
+    domctl.domain =3D (domid_t)domid;
+
+    return do_domctl(xch, &domctl);
+}
+
+/* End vmce monitor */
+int xc_domain_vmce_monitor_end(xc_interface *xch,
+                               uint32_t domid)
+{
+    DECLARE_DOMCTL;
+
+    domctl.cmd =3D XEN_DOMCTL_vmce_monitor_end;
+    domctl.domain =3D (domid_t)domid;
+
+    return do_domctl(xch, &domctl);
+}
+
 /* get info from hvm guest for save */
 int xc_domain_hvm_getcontext(xc_interface *xch,
                              uint32_t domid,
diff -r e27a6d53ac15 tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Thu Oct 11 01:52:33 2012 +0800
+++ b/tools/libxc/xc_domain_save.c	Thu Oct 11 05:12:48 2012 +0800
@@ -895,6 +895,8 @@
      */
     int compressing =3D 0;
=20
+    int vmce_while_monitor =3D 0;
+
     int completed =3D 0;
=20
     if ( hvm && !callbacks->switch_qemu_logdirty )
@@ -1109,6 +1111,12 @@
         goto out;
     }
=20
+    if ( xc_domain_vmce_monitor_start(xch, dom) )
+    {
+        PERROR("Error when start vmce monitor\n");
+        goto out;
+    }
+
   copypages:
 #define wrexact(fd, buf, len) write_buffer(xch, last_iter, ob, (fd), (buf)=
, (len))
 #define wruncached(fd, live, buf, len) write_uncached(xch, last_iter, ob, =
(fd), (buf), (len))
@@ -1571,6 +1579,18 @@
=20
     DPRINTF("All memory is saved\n");
=20
+    vmce_while_monitor =3D xc_domain_vmce_monitor_end(xch, dom);
+    if ( vmce_while_monitor < 0 )
+    {
+        PERROR("Error when end vmce monitor\n");
+        goto out;
+    }
+    else if ( vmce_while_monitor > 0 )
+    {
+        fprintf(stderr, "vMCE occurred, abort this time and try later.\n")=
;
+        goto out;
+    }
+
     /* After last_iter, buffer the rest of pagebuf & tailbuf data into a
      * separate output buffer and flush it after the compressed page chunk=
s.
      */
diff -r e27a6d53ac15 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Thu Oct 11 01:52:33 2012 +0800
+++ b/tools/libxc/xenctrl.h	Thu Oct 11 05:12:48 2012 +0800
@@ -575,6 +575,26 @@
                           xc_domaininfo_t *info);
=20
 /**
+ * This function start monitor vmce event.
+ * @parm xch a handle to an open hypervisor interface
+ * @parm domid the domain id monitored
+ * @return <0 on failure, 0 on success
+ */
+int xc_domain_vmce_monitor_start(xc_interface *xch,
+                                 uint32_t domid);
+
+/**
+ * This function end monitor vmce event
+ * @parm xch a handle to an open hypervisor interface
+ * @parm domid the domain id monitored
+ * @return < 0 on failure, >=3D 0 on success while
+ *   =3D 0 on no vmce occurred
+ *   > 0 on vmce occurred
+ */
+int xc_domain_vmce_monitor_end(xc_interface *xch,
+                               uint32_t domid);
+
+/**
  * This function returns information about the context of a hvm domain
  * @parm xch a handle to an open hypervisor interface
  * @parm domid the domain to get information from
diff -r e27a6d53ac15 xen/arch/x86/cpu/mcheck/mce_intel.c
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c	Thu Oct 11 01:52:33 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c	Thu Oct 11 05:12:48 2012 +0800
@@ -359,6 +359,12 @@
                     goto vmce_failed;
                 }
=20
+                if ( unlikely(d->arch.vmce_monitor) )
+                {
+                    /* vMCE occur when guest migration */
+                    d->arch.vmce_monitor =3D 1;
+                }
+
                 /* We will inject vMCE to DOMU*/
                 if ( inject_vmce(d, VMCE_INJECT_BROADCAST) < 0 )
                 {
diff -r e27a6d53ac15 xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c	Thu Oct 11 01:52:33 2012 +0800
+++ b/xen/arch/x86/domctl.c	Thu Oct 11 05:12:48 2012 +0800
@@ -1568,6 +1568,47 @@
     }
     break;
=20
+    case XEN_DOMCTL_vmce_monitor_start:
+    {
+        struct domain *d;
+
+        d =3D rcu_lock_domain_by_id(domctl->domain);
+        if ( d !=3D NULL )
+        {
+            if ( d->arch.vmce_monitor )
+                ret =3D -EBUSY;
+            else
+                d->arch.vmce_monitor =3D -1;
+
+            rcu_unlock_domain(d);
+        }
+        else
+            ret =3D -ESRCH;
+    }
+    break;
+
+    case XEN_DOMCTL_vmce_monitor_end:
+    {
+        struct domain *d;
+
+        d =3D rcu_lock_domain_by_id(domctl->domain);
+        if ( d !=3D NULL)
+        {
+            if ( !d->arch.vmce_monitor )
+                ret =3D -EINVAL;
+            else
+            {
+                ret =3D d->arch.vmce_monitor > 0 ? 1 : 0;
+                d->arch.vmce_monitor =3D 0;
+            }
+
+            rcu_unlock_domain(d);
+        }
+        else
+            ret =3D -ESRCH;
+    }
+    break;
+
     default:
         ret =3D iommu_do_domctl(domctl, u_domctl);
         break;
diff -r e27a6d53ac15 xen/include/asm-x86/domain.h
--- a/xen/include/asm-x86/domain.h	Thu Oct 11 01:52:33 2012 +0800
+++ b/xen/include/asm-x86/domain.h	Thu Oct 11 05:12:48 2012 +0800
@@ -279,6 +279,11 @@
     bool_t has_32bit_shinfo;
     /* Domain cannot handle spurious page faults? */
     bool_t suppress_spurious_page_faults;
+    /* Monitoring guest memory copy of migration
+     * =3D 0 - not monitoring
+     * < 0 - monitoring
+     * > 0 - vMCE occurred while monitoring */
+    s8 vmce_monitor;
=20
     /* Continuable domain_relinquish_resources(). */
     enum {
diff -r e27a6d53ac15 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h	Thu Oct 11 01:52:33 2012 +0800
+++ b/xen/include/public/domctl.h	Thu Oct 11 05:12:48 2012 +0800
@@ -900,6 +900,8 @@
 #define XEN_DOMCTL_set_access_required           64
 #define XEN_DOMCTL_audit_p2m                     65
 #define XEN_DOMCTL_set_virq_handler              66
+#define XEN_DOMCTL_vmce_monitor_start            67
+#define XEN_DOMCTL_vmce_monitor_end              68
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002=

--_002_DE8DF0795D48FD4CA783C40EC829233534A62FSHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="4_vmce_when_migrate.patch"
Content-Description: 4_vmce_when_migrate.patch
Content-Disposition: attachment; filename="4_vmce_when_migrate.patch";
	size=6849; creation-date="Wed, 10 Oct 2012 14:32:13 GMT";
	modification-date="Wed, 10 Oct 2012 21:12:48 GMT"
Content-Transfer-Encoding: base64

WGVuL01DRTogQWJvcnQgbGl2ZSBtaWdyYXRpb24gd2hlbiB2TUNFIG9jY3VyCgpUaGlzIHBhdGNo
IG1vbml0b3IgdGhlIGNyaXRpY2FsIGFyZWEgb2YgbGl2ZSBtaWdyYXRpb24gKGZyb20gdk1DRSBw
b2ludCBvZiB2aWV3LAp0aGUgY29weXBhZ2VzIHN0YWdlIG9mIG1pZ3JhdGlvbiBpcyB0aGUgY3Jp
dGljYWwgYXJlYSB3aGlsZSBvdGhlciBhcmVhcyBhcmUgbm90KS4KCklmIGEgdk1DRSBvY2N1ciBh
dCB0aGUgY3JpdGljYWwgYXJlYSBvZiBsaXZlIG1pZ3JhdGlvbiwgdGhlcmUgaXMgcmlzayB0aGF0
IGVycm9yCmRhdGEgbWF5IGJlIGNvcGllZCB0byB0aGUgdGFyZ2V0LiBDdXJyZW50bHkgd2UgZG9u
J3QgaGF2ZSBjb252ZW5pZW50IHdheSB0byBoYW5kbGUKdGhpcyBjYXNlLCBzbyBmb3IgdGhlIHNh
a2Ugb2Ygc2FmZSwgd2UgYWJvcnQgaXQgYW5kIHRyeSBtaWdyYXRpb24gbGF0ZXIgKGF0IHRoYXQK
dGltZSBicm9rZW4gcGFnZSB3b3VsZCBub3QgYmUgbWFwcGVkIGFuZCBjb3BpZWQgdG8gdGhlIHRh
cmdldCkuCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNv
bT4KCmRpZmYgLXIgZTI3YTZkNTNhYzE1IHRvb2xzL2xpYnhjL3hjX2RvbWFpbi5jCi0tLSBhL3Rv
b2xzL2xpYnhjL3hjX2RvbWFpbi5jCVRodSBPY3QgMTEgMDE6NTI6MzMgMjAxMiArMDgwMAorKysg
Yi90b29scy9saWJ4Yy94Y19kb21haW4uYwlUaHUgT2N0IDExIDA1OjEyOjQ4IDIwMTIgKzA4MDAK
QEAgLTI4Myw2ICsyODMsMzAgQEAKICAgICByZXR1cm4gcmV0OwogfQogCisvKiBTdGFydCB2bWNl
IG1vbml0b3IgKi8KK2ludCB4Y19kb21haW5fdm1jZV9tb25pdG9yX3N0YXJ0KHhjX2ludGVyZmFj
ZSAqeGNoLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZG9taWQp
Cit7CisgICAgREVDTEFSRV9ET01DVEw7CisKKyAgICBkb21jdGwuY21kID0gWEVOX0RPTUNUTF92
bWNlX21vbml0b3Jfc3RhcnQ7CisgICAgZG9tY3RsLmRvbWFpbiA9IChkb21pZF90KWRvbWlkOwor
CisgICAgcmV0dXJuIGRvX2RvbWN0bCh4Y2gsICZkb21jdGwpOworfQorCisvKiBFbmQgdm1jZSBt
b25pdG9yICovCitpbnQgeGNfZG9tYWluX3ZtY2VfbW9uaXRvcl9lbmQoeGNfaW50ZXJmYWNlICp4
Y2gsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZG9taWQpCit7Cisg
ICAgREVDTEFSRV9ET01DVEw7CisKKyAgICBkb21jdGwuY21kID0gWEVOX0RPTUNUTF92bWNlX21v
bml0b3JfZW5kOworICAgIGRvbWN0bC5kb21haW4gPSAoZG9taWRfdClkb21pZDsKKworICAgIHJl
dHVybiBkb19kb21jdGwoeGNoLCAmZG9tY3RsKTsKK30KKwogLyogZ2V0IGluZm8gZnJvbSBodm0g
Z3Vlc3QgZm9yIHNhdmUgKi8KIGludCB4Y19kb21haW5faHZtX2dldGNvbnRleHQoeGNfaW50ZXJm
YWNlICp4Y2gsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IGRvbWlkLApk
aWZmIC1yIGUyN2E2ZDUzYWMxNSB0b29scy9saWJ4Yy94Y19kb21haW5fc2F2ZS5jCi0tLSBhL3Rv
b2xzL2xpYnhjL3hjX2RvbWFpbl9zYXZlLmMJVGh1IE9jdCAxMSAwMTo1MjozMyAyMDEyICswODAw
CisrKyBiL3Rvb2xzL2xpYnhjL3hjX2RvbWFpbl9zYXZlLmMJVGh1IE9jdCAxMSAwNToxMjo0OCAy
MDEyICswODAwCkBAIC04OTUsNiArODk1LDggQEAKICAgICAgKi8KICAgICBpbnQgY29tcHJlc3Np
bmcgPSAwOwogCisgICAgaW50IHZtY2Vfd2hpbGVfbW9uaXRvciA9IDA7CisKICAgICBpbnQgY29t
cGxldGVkID0gMDsKIAogICAgIGlmICggaHZtICYmICFjYWxsYmFja3MtPnN3aXRjaF9xZW11X2xv
Z2RpcnR5ICkKQEAgLTExMDksNiArMTExMSwxMiBAQAogICAgICAgICBnb3RvIG91dDsKICAgICB9
CiAKKyAgICBpZiAoIHhjX2RvbWFpbl92bWNlX21vbml0b3Jfc3RhcnQoeGNoLCBkb20pICkKKyAg
ICB7CisgICAgICAgIFBFUlJPUigiRXJyb3Igd2hlbiBzdGFydCB2bWNlIG1vbml0b3JcbiIpOwor
ICAgICAgICBnb3RvIG91dDsKKyAgICB9CisKICAgY29weXBhZ2VzOgogI2RlZmluZSB3cmV4YWN0
KGZkLCBidWYsIGxlbikgd3JpdGVfYnVmZmVyKHhjaCwgbGFzdF9pdGVyLCBvYiwgKGZkKSwgKGJ1
ZiksIChsZW4pKQogI2RlZmluZSB3cnVuY2FjaGVkKGZkLCBsaXZlLCBidWYsIGxlbikgd3JpdGVf
dW5jYWNoZWQoeGNoLCBsYXN0X2l0ZXIsIG9iLCAoZmQpLCAoYnVmKSwgKGxlbikpCkBAIC0xNTcx
LDYgKzE1NzksMTggQEAKIAogICAgIERQUklOVEYoIkFsbCBtZW1vcnkgaXMgc2F2ZWRcbiIpOwog
CisgICAgdm1jZV93aGlsZV9tb25pdG9yID0geGNfZG9tYWluX3ZtY2VfbW9uaXRvcl9lbmQoeGNo
LCBkb20pOworICAgIGlmICggdm1jZV93aGlsZV9tb25pdG9yIDwgMCApCisgICAgeworICAgICAg
ICBQRVJST1IoIkVycm9yIHdoZW4gZW5kIHZtY2UgbW9uaXRvclxuIik7CisgICAgICAgIGdvdG8g
b3V0OworICAgIH0KKyAgICBlbHNlIGlmICggdm1jZV93aGlsZV9tb25pdG9yID4gMCApCisgICAg
eworICAgICAgICBmcHJpbnRmKHN0ZGVyciwgInZNQ0Ugb2NjdXJyZWQsIGFib3J0IHRoaXMgdGlt
ZSBhbmQgdHJ5IGxhdGVyLlxuIik7CisgICAgICAgIGdvdG8gb3V0OworICAgIH0KKwogICAgIC8q
IEFmdGVyIGxhc3RfaXRlciwgYnVmZmVyIHRoZSByZXN0IG9mIHBhZ2VidWYgJiB0YWlsYnVmIGRh
dGEgaW50byBhCiAgICAgICogc2VwYXJhdGUgb3V0cHV0IGJ1ZmZlciBhbmQgZmx1c2ggaXQgYWZ0
ZXIgdGhlIGNvbXByZXNzZWQgcGFnZSBjaHVua3MuCiAgICAgICovCmRpZmYgLXIgZTI3YTZkNTNh
YzE1IHRvb2xzL2xpYnhjL3hlbmN0cmwuaAotLS0gYS90b29scy9saWJ4Yy94ZW5jdHJsLmgJVGh1
IE9jdCAxMSAwMTo1MjozMyAyMDEyICswODAwCisrKyBiL3Rvb2xzL2xpYnhjL3hlbmN0cmwuaAlU
aHUgT2N0IDExIDA1OjEyOjQ4IDIwMTIgKzA4MDAKQEAgLTU3NSw2ICs1NzUsMjYgQEAKICAgICAg
ICAgICAgICAgICAgICAgICAgICAgeGNfZG9tYWluaW5mb190ICppbmZvKTsKIAogLyoqCisgKiBU
aGlzIGZ1bmN0aW9uIHN0YXJ0IG1vbml0b3Igdm1jZSBldmVudC4KKyAqIEBwYXJtIHhjaCBhIGhh
bmRsZSB0byBhbiBvcGVuIGh5cGVydmlzb3IgaW50ZXJmYWNlCisgKiBAcGFybSBkb21pZCB0aGUg
ZG9tYWluIGlkIG1vbml0b3JlZAorICogQHJldHVybiA8MCBvbiBmYWlsdXJlLCAwIG9uIHN1Y2Nl
c3MKKyAqLworaW50IHhjX2RvbWFpbl92bWNlX21vbml0b3Jfc3RhcnQoeGNfaW50ZXJmYWNlICp4
Y2gsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJfdCBkb21pZCk7CisK
Ky8qKgorICogVGhpcyBmdW5jdGlvbiBlbmQgbW9uaXRvciB2bWNlIGV2ZW50CisgKiBAcGFybSB4
Y2ggYSBoYW5kbGUgdG8gYW4gb3BlbiBoeXBlcnZpc29yIGludGVyZmFjZQorICogQHBhcm0gZG9t
aWQgdGhlIGRvbWFpbiBpZCBtb25pdG9yZWQKKyAqIEByZXR1cm4gPCAwIG9uIGZhaWx1cmUsID49
IDAgb24gc3VjY2VzcyB3aGlsZQorICogICA9IDAgb24gbm8gdm1jZSBvY2N1cnJlZAorICogICA+
IDAgb24gdm1jZSBvY2N1cnJlZAorICovCitpbnQgeGNfZG9tYWluX3ZtY2VfbW9uaXRvcl9lbmQo
eGNfaW50ZXJmYWNlICp4Y2gsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMy
X3QgZG9taWQpOworCisvKioKICAqIFRoaXMgZnVuY3Rpb24gcmV0dXJucyBpbmZvcm1hdGlvbiBh
Ym91dCB0aGUgY29udGV4dCBvZiBhIGh2bSBkb21haW4KICAqIEBwYXJtIHhjaCBhIGhhbmRsZSB0
byBhbiBvcGVuIGh5cGVydmlzb3IgaW50ZXJmYWNlCiAgKiBAcGFybSBkb21pZCB0aGUgZG9tYWlu
IHRvIGdldCBpbmZvcm1hdGlvbiBmcm9tCmRpZmYgLXIgZTI3YTZkNTNhYzE1IHhlbi9hcmNoL3g4
Ni9jcHUvbWNoZWNrL21jZV9pbnRlbC5jCi0tLSBhL3hlbi9hcmNoL3g4Ni9jcHUvbWNoZWNrL21j
ZV9pbnRlbC5jCVRodSBPY3QgMTEgMDE6NTI6MzMgMjAxMiArMDgwMAorKysgYi94ZW4vYXJjaC94
ODYvY3B1L21jaGVjay9tY2VfaW50ZWwuYwlUaHUgT2N0IDExIDA1OjEyOjQ4IDIwMTIgKzA4MDAK
QEAgLTM1OSw2ICszNTksMTIgQEAKICAgICAgICAgICAgICAgICAgICAgZ290byB2bWNlX2ZhaWxl
ZDsKICAgICAgICAgICAgICAgICB9CiAKKyAgICAgICAgICAgICAgICBpZiAoIHVubGlrZWx5KGQt
PmFyY2gudm1jZV9tb25pdG9yKSApCisgICAgICAgICAgICAgICAgeworICAgICAgICAgICAgICAg
ICAgICAvKiB2TUNFIG9jY3VyIHdoZW4gZ3Vlc3QgbWlncmF0aW9uICovCisgICAgICAgICAgICAg
ICAgICAgIGQtPmFyY2gudm1jZV9tb25pdG9yID0gMTsKKyAgICAgICAgICAgICAgICB9CisKICAg
ICAgICAgICAgICAgICAvKiBXZSB3aWxsIGluamVjdCB2TUNFIHRvIERPTVUqLwogICAgICAgICAg
ICAgICAgIGlmICggaW5qZWN0X3ZtY2UoZCwgVk1DRV9JTkpFQ1RfQlJPQURDQVNUKSA8IDAgKQog
ICAgICAgICAgICAgICAgIHsKZGlmZiAtciBlMjdhNmQ1M2FjMTUgeGVuL2FyY2gveDg2L2RvbWN0
bC5jCi0tLSBhL3hlbi9hcmNoL3g4Ni9kb21jdGwuYwlUaHUgT2N0IDExIDAxOjUyOjMzIDIwMTIg
KzA4MDAKKysrIGIveGVuL2FyY2gveDg2L2RvbWN0bC5jCVRodSBPY3QgMTEgMDU6MTI6NDggMjAx
MiArMDgwMApAQCAtMTU2OCw2ICsxNTY4LDQ3IEBACiAgICAgfQogICAgIGJyZWFrOwogCisgICAg
Y2FzZSBYRU5fRE9NQ1RMX3ZtY2VfbW9uaXRvcl9zdGFydDoKKyAgICB7CisgICAgICAgIHN0cnVj
dCBkb21haW4gKmQ7CisKKyAgICAgICAgZCA9IHJjdV9sb2NrX2RvbWFpbl9ieV9pZChkb21jdGwt
PmRvbWFpbik7CisgICAgICAgIGlmICggZCAhPSBOVUxMICkKKyAgICAgICAgeworICAgICAgICAg
ICAgaWYgKCBkLT5hcmNoLnZtY2VfbW9uaXRvciApCisgICAgICAgICAgICAgICAgcmV0ID0gLUVC
VVNZOworICAgICAgICAgICAgZWxzZQorICAgICAgICAgICAgICAgIGQtPmFyY2gudm1jZV9tb25p
dG9yID0gLTE7CisKKyAgICAgICAgICAgIHJjdV91bmxvY2tfZG9tYWluKGQpOworICAgICAgICB9
CisgICAgICAgIGVsc2UKKyAgICAgICAgICAgIHJldCA9IC1FU1JDSDsKKyAgICB9CisgICAgYnJl
YWs7CisKKyAgICBjYXNlIFhFTl9ET01DVExfdm1jZV9tb25pdG9yX2VuZDoKKyAgICB7CisgICAg
ICAgIHN0cnVjdCBkb21haW4gKmQ7CisKKyAgICAgICAgZCA9IHJjdV9sb2NrX2RvbWFpbl9ieV9p
ZChkb21jdGwtPmRvbWFpbik7CisgICAgICAgIGlmICggZCAhPSBOVUxMKQorICAgICAgICB7Cisg
ICAgICAgICAgICBpZiAoICFkLT5hcmNoLnZtY2VfbW9uaXRvciApCisgICAgICAgICAgICAgICAg
cmV0ID0gLUVJTlZBTDsKKyAgICAgICAgICAgIGVsc2UKKyAgICAgICAgICAgIHsKKyAgICAgICAg
ICAgICAgICByZXQgPSBkLT5hcmNoLnZtY2VfbW9uaXRvciA+IDAgPyAxIDogMDsKKyAgICAgICAg
ICAgICAgICBkLT5hcmNoLnZtY2VfbW9uaXRvciA9IDA7CisgICAgICAgICAgICB9CisKKyAgICAg
ICAgICAgIHJjdV91bmxvY2tfZG9tYWluKGQpOworICAgICAgICB9CisgICAgICAgIGVsc2UKKyAg
ICAgICAgICAgIHJldCA9IC1FU1JDSDsKKyAgICB9CisgICAgYnJlYWs7CisKICAgICBkZWZhdWx0
OgogICAgICAgICByZXQgPSBpb21tdV9kb19kb21jdGwoZG9tY3RsLCB1X2RvbWN0bCk7CiAgICAg
ICAgIGJyZWFrOwpkaWZmIC1yIGUyN2E2ZDUzYWMxNSB4ZW4vaW5jbHVkZS9hc20teDg2L2RvbWFp
bi5oCi0tLSBhL3hlbi9pbmNsdWRlL2FzbS14ODYvZG9tYWluLmgJVGh1IE9jdCAxMSAwMTo1Mjoz
MyAyMDEyICswODAwCisrKyBiL3hlbi9pbmNsdWRlL2FzbS14ODYvZG9tYWluLmgJVGh1IE9jdCAx
MSAwNToxMjo0OCAyMDEyICswODAwCkBAIC0yNzksNiArMjc5LDExIEBACiAgICAgYm9vbF90IGhh
c18zMmJpdF9zaGluZm87CiAgICAgLyogRG9tYWluIGNhbm5vdCBoYW5kbGUgc3B1cmlvdXMgcGFn
ZSBmYXVsdHM/ICovCiAgICAgYm9vbF90IHN1cHByZXNzX3NwdXJpb3VzX3BhZ2VfZmF1bHRzOwor
ICAgIC8qIE1vbml0b3JpbmcgZ3Vlc3QgbWVtb3J5IGNvcHkgb2YgbWlncmF0aW9uCisgICAgICog
PSAwIC0gbm90IG1vbml0b3JpbmcKKyAgICAgKiA8IDAgLSBtb25pdG9yaW5nCisgICAgICogPiAw
IC0gdk1DRSBvY2N1cnJlZCB3aGlsZSBtb25pdG9yaW5nICovCisgICAgczggdm1jZV9tb25pdG9y
OwogCiAgICAgLyogQ29udGludWFibGUgZG9tYWluX3JlbGlucXVpc2hfcmVzb3VyY2VzKCkuICov
CiAgICAgZW51bSB7CmRpZmYgLXIgZTI3YTZkNTNhYzE1IHhlbi9pbmNsdWRlL3B1YmxpYy9kb21j
dGwuaAotLS0gYS94ZW4vaW5jbHVkZS9wdWJsaWMvZG9tY3RsLmgJVGh1IE9jdCAxMSAwMTo1Mjoz
MyAyMDEyICswODAwCisrKyBiL3hlbi9pbmNsdWRlL3B1YmxpYy9kb21jdGwuaAlUaHUgT2N0IDEx
IDA1OjEyOjQ4IDIwMTIgKzA4MDAKQEAgLTkwMCw2ICs5MDAsOCBAQAogI2RlZmluZSBYRU5fRE9N
Q1RMX3NldF9hY2Nlc3NfcmVxdWlyZWQgICAgICAgICAgIDY0CiAjZGVmaW5lIFhFTl9ET01DVExf
YXVkaXRfcDJtICAgICAgICAgICAgICAgICAgICAgNjUKICNkZWZpbmUgWEVOX0RPTUNUTF9zZXRf
dmlycV9oYW5kbGVyICAgICAgICAgICAgICA2NgorI2RlZmluZSBYRU5fRE9NQ1RMX3ZtY2VfbW9u
aXRvcl9zdGFydCAgICAgICAgICAgIDY3CisjZGVmaW5lIFhFTl9ET01DVExfdm1jZV9tb25pdG9y
X2VuZCAgICAgICAgICAgICAgNjgKICNkZWZpbmUgWEVOX0RPTUNUTF9nZGJzeF9ndWVzdG1lbWlv
ICAgICAgICAgICAgMTAwMAogI2RlZmluZSBYRU5fRE9NQ1RMX2dkYnN4X3BhdXNldmNwdSAgICAg
ICAgICAgICAxMDAxCiAjZGVmaW5lIFhFTl9ET01DVExfZ2Ric3hfdW5wYXVzZXZjcHUgICAgICAg
ICAgIDEwMDIK

--_002_DE8DF0795D48FD4CA783C40EC829233534A62FSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC829233534A62FSHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Wed Oct 10 14:46:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 14:46:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLxYI-0000J7-EU; Wed, 10 Oct 2012 14:46:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLxYG-0000Iq-Aj
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 14:46:24 +0000
Received: from [85.158.139.83:55153] by server-16.bemta-5.messagelabs.com id
	EE/A1-10155-F3A85705; Wed, 10 Oct 2012 14:46:23 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1349880380!27051570!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjE2NDY2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5429 invoked from network); 10 Oct 2012 14:46:21 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-11.tower-182.messagelabs.com with SMTP;
	10 Oct 2012 14:46:21 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 10 Oct 2012 07:46:19 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,564,1344236400"; d="scan'208";a="154635063"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by AZSMGA002.ch.intel.com with ESMTP; 10 Oct 2012 07:46:18 -0700
Received: from fmsmsx102.amr.corp.intel.com (10.19.9.53) by
	FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 10 Oct 2012 07:46:18 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX102.amr.corp.intel.com (10.19.9.53) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 10 Oct 2012 07:46:17 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Wed, 10 Oct 2012 22:46:16 +0800
From: "Liu, Jinsong" 
To: Ian Campbell , "xen-devel@lists.xensource.com"
	
Thread-Topic: [PATCH 4/5] Xen/MCE: Abort live migration when vMCE occur
Thread-Index: Ac2m9gA+ufJylTqUQruxPOzNlQzaHQ==
Date: Wed, 10 Oct 2012 14:46:16 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC829233534A62FSHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: Ian Jackson ,
	Christoph Egger ,
	"Keir \(Xen.org\)" , Jan Beulich 
Subject: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration when vMCE
	occur
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC829233534A62FSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Xen/MCE: Abort live migration when vMCE occur

This patch monitor the critical area of live migration (from vMCE point of =
view,
the copypages stage of migration is the critical area while other areas are=
 not).

If a vMCE occur at the critical area of live migration, there is risk that =
error
data may be copied to the target. Currently we don't have convenient way to=
 handle
this case, so for the sake of safe, we abort it and try migration later (at=
 that
time broken page would not be mapped and copied to the target).

Signed-off-by: Liu, Jinsong 

diff -r e27a6d53ac15 tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c	Thu Oct 11 01:52:33 2012 +0800
+++ b/tools/libxc/xc_domain.c	Thu Oct 11 05:12:48 2012 +0800
@@ -283,6 +283,30 @@
     return ret;
 }
=20
+/* Start vmce monitor */
+int xc_domain_vmce_monitor_start(xc_interface *xch,
+                                 uint32_t domid)
+{
+    DECLARE_DOMCTL;
+
+    domctl.cmd =3D XEN_DOMCTL_vmce_monitor_start;
+    domctl.domain =3D (domid_t)domid;
+
+    return do_domctl(xch, &domctl);
+}
+
+/* End vmce monitor */
+int xc_domain_vmce_monitor_end(xc_interface *xch,
+                               uint32_t domid)
+{
+    DECLARE_DOMCTL;
+
+    domctl.cmd =3D XEN_DOMCTL_vmce_monitor_end;
+    domctl.domain =3D (domid_t)domid;
+
+    return do_domctl(xch, &domctl);
+}
+
 /* get info from hvm guest for save */
 int xc_domain_hvm_getcontext(xc_interface *xch,
                              uint32_t domid,
diff -r e27a6d53ac15 tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Thu Oct 11 01:52:33 2012 +0800
+++ b/tools/libxc/xc_domain_save.c	Thu Oct 11 05:12:48 2012 +0800
@@ -895,6 +895,8 @@
      */
     int compressing =3D 0;
=20
+    int vmce_while_monitor =3D 0;
+
     int completed =3D 0;
=20
     if ( hvm && !callbacks->switch_qemu_logdirty )
@@ -1109,6 +1111,12 @@
         goto out;
     }
=20
+    if ( xc_domain_vmce_monitor_start(xch, dom) )
+    {
+        PERROR("Error when start vmce monitor\n");
+        goto out;
+    }
+
   copypages:
 #define wrexact(fd, buf, len) write_buffer(xch, last_iter, ob, (fd), (buf)=
, (len))
 #define wruncached(fd, live, buf, len) write_uncached(xch, last_iter, ob, =
(fd), (buf), (len))
@@ -1571,6 +1579,18 @@
=20
     DPRINTF("All memory is saved\n");
=20
+    vmce_while_monitor =3D xc_domain_vmce_monitor_end(xch, dom);
+    if ( vmce_while_monitor < 0 )
+    {
+        PERROR("Error when end vmce monitor\n");
+        goto out;
+    }
+    else if ( vmce_while_monitor > 0 )
+    {
+        fprintf(stderr, "vMCE occurred, abort this time and try later.\n")=
;
+        goto out;
+    }
+
     /* After last_iter, buffer the rest of pagebuf & tailbuf data into a
      * separate output buffer and flush it after the compressed page chunk=
s.
      */
diff -r e27a6d53ac15 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Thu Oct 11 01:52:33 2012 +0800
+++ b/tools/libxc/xenctrl.h	Thu Oct 11 05:12:48 2012 +0800
@@ -575,6 +575,26 @@
                           xc_domaininfo_t *info);
=20
 /**
+ * This function start monitor vmce event.
+ * @parm xch a handle to an open hypervisor interface
+ * @parm domid the domain id monitored
+ * @return <0 on failure, 0 on success
+ */
+int xc_domain_vmce_monitor_start(xc_interface *xch,
+                                 uint32_t domid);
+
+/**
+ * This function end monitor vmce event
+ * @parm xch a handle to an open hypervisor interface
+ * @parm domid the domain id monitored
+ * @return < 0 on failure, >=3D 0 on success while
+ *   =3D 0 on no vmce occurred
+ *   > 0 on vmce occurred
+ */
+int xc_domain_vmce_monitor_end(xc_interface *xch,
+                               uint32_t domid);
+
+/**
  * This function returns information about the context of a hvm domain
  * @parm xch a handle to an open hypervisor interface
  * @parm domid the domain to get information from
diff -r e27a6d53ac15 xen/arch/x86/cpu/mcheck/mce_intel.c
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c	Thu Oct 11 01:52:33 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c	Thu Oct 11 05:12:48 2012 +0800
@@ -359,6 +359,12 @@
                     goto vmce_failed;
                 }
=20
+                if ( unlikely(d->arch.vmce_monitor) )
+                {
+                    /* vMCE occur when guest migration */
+                    d->arch.vmce_monitor =3D 1;
+                }
+
                 /* We will inject vMCE to DOMU*/
                 if ( inject_vmce(d, VMCE_INJECT_BROADCAST) < 0 )
                 {
diff -r e27a6d53ac15 xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c	Thu Oct 11 01:52:33 2012 +0800
+++ b/xen/arch/x86/domctl.c	Thu Oct 11 05:12:48 2012 +0800
@@ -1568,6 +1568,47 @@
     }
     break;
=20
+    case XEN_DOMCTL_vmce_monitor_start:
+    {
+        struct domain *d;
+
+        d =3D rcu_lock_domain_by_id(domctl->domain);
+        if ( d !=3D NULL )
+        {
+            if ( d->arch.vmce_monitor )
+                ret =3D -EBUSY;
+            else
+                d->arch.vmce_monitor =3D -1;
+
+            rcu_unlock_domain(d);
+        }
+        else
+            ret =3D -ESRCH;
+    }
+    break;
+
+    case XEN_DOMCTL_vmce_monitor_end:
+    {
+        struct domain *d;
+
+        d =3D rcu_lock_domain_by_id(domctl->domain);
+        if ( d !=3D NULL)
+        {
+            if ( !d->arch.vmce_monitor )
+                ret =3D -EINVAL;
+            else
+            {
+                ret =3D d->arch.vmce_monitor > 0 ? 1 : 0;
+                d->arch.vmce_monitor =3D 0;
+            }
+
+            rcu_unlock_domain(d);
+        }
+        else
+            ret =3D -ESRCH;
+    }
+    break;
+
     default:
         ret =3D iommu_do_domctl(domctl, u_domctl);
         break;
diff -r e27a6d53ac15 xen/include/asm-x86/domain.h
--- a/xen/include/asm-x86/domain.h	Thu Oct 11 01:52:33 2012 +0800
+++ b/xen/include/asm-x86/domain.h	Thu Oct 11 05:12:48 2012 +0800
@@ -279,6 +279,11 @@
     bool_t has_32bit_shinfo;
     /* Domain cannot handle spurious page faults? */
     bool_t suppress_spurious_page_faults;
+    /* Monitoring guest memory copy of migration
+     * =3D 0 - not monitoring
+     * < 0 - monitoring
+     * > 0 - vMCE occurred while monitoring */
+    s8 vmce_monitor;
=20
     /* Continuable domain_relinquish_resources(). */
     enum {
diff -r e27a6d53ac15 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h	Thu Oct 11 01:52:33 2012 +0800
+++ b/xen/include/public/domctl.h	Thu Oct 11 05:12:48 2012 +0800
@@ -900,6 +900,8 @@
 #define XEN_DOMCTL_set_access_required           64
 #define XEN_DOMCTL_audit_p2m                     65
 #define XEN_DOMCTL_set_virq_handler              66
+#define XEN_DOMCTL_vmce_monitor_start            67
+#define XEN_DOMCTL_vmce_monitor_end              68
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002=

--_002_DE8DF0795D48FD4CA783C40EC829233534A62FSHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="4_vmce_when_migrate.patch"
Content-Description: 4_vmce_when_migrate.patch
Content-Disposition: attachment; filename="4_vmce_when_migrate.patch";
	size=6849; creation-date="Wed, 10 Oct 2012 14:32:13 GMT";
	modification-date="Wed, 10 Oct 2012 21:12:48 GMT"
Content-Transfer-Encoding: base64

WGVuL01DRTogQWJvcnQgbGl2ZSBtaWdyYXRpb24gd2hlbiB2TUNFIG9jY3VyCgpUaGlzIHBhdGNo
IG1vbml0b3IgdGhlIGNyaXRpY2FsIGFyZWEgb2YgbGl2ZSBtaWdyYXRpb24gKGZyb20gdk1DRSBw
b2ludCBvZiB2aWV3LAp0aGUgY29weXBhZ2VzIHN0YWdlIG9mIG1pZ3JhdGlvbiBpcyB0aGUgY3Jp
dGljYWwgYXJlYSB3aGlsZSBvdGhlciBhcmVhcyBhcmUgbm90KS4KCklmIGEgdk1DRSBvY2N1ciBh
dCB0aGUgY3JpdGljYWwgYXJlYSBvZiBsaXZlIG1pZ3JhdGlvbiwgdGhlcmUgaXMgcmlzayB0aGF0
IGVycm9yCmRhdGEgbWF5IGJlIGNvcGllZCB0byB0aGUgdGFyZ2V0LiBDdXJyZW50bHkgd2UgZG9u
J3QgaGF2ZSBjb252ZW5pZW50IHdheSB0byBoYW5kbGUKdGhpcyBjYXNlLCBzbyBmb3IgdGhlIHNh
a2Ugb2Ygc2FmZSwgd2UgYWJvcnQgaXQgYW5kIHRyeSBtaWdyYXRpb24gbGF0ZXIgKGF0IHRoYXQK
dGltZSBicm9rZW4gcGFnZSB3b3VsZCBub3QgYmUgbWFwcGVkIGFuZCBjb3BpZWQgdG8gdGhlIHRh
cmdldCkuCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNv
bT4KCmRpZmYgLXIgZTI3YTZkNTNhYzE1IHRvb2xzL2xpYnhjL3hjX2RvbWFpbi5jCi0tLSBhL3Rv
b2xzL2xpYnhjL3hjX2RvbWFpbi5jCVRodSBPY3QgMTEgMDE6NTI6MzMgMjAxMiArMDgwMAorKysg
Yi90b29scy9saWJ4Yy94Y19kb21haW4uYwlUaHUgT2N0IDExIDA1OjEyOjQ4IDIwMTIgKzA4MDAK
QEAgLTI4Myw2ICsyODMsMzAgQEAKICAgICByZXR1cm4gcmV0OwogfQogCisvKiBTdGFydCB2bWNl
IG1vbml0b3IgKi8KK2ludCB4Y19kb21haW5fdm1jZV9tb25pdG9yX3N0YXJ0KHhjX2ludGVyZmFj
ZSAqeGNoLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZG9taWQp
Cit7CisgICAgREVDTEFSRV9ET01DVEw7CisKKyAgICBkb21jdGwuY21kID0gWEVOX0RPTUNUTF92
bWNlX21vbml0b3Jfc3RhcnQ7CisgICAgZG9tY3RsLmRvbWFpbiA9IChkb21pZF90KWRvbWlkOwor
CisgICAgcmV0dXJuIGRvX2RvbWN0bCh4Y2gsICZkb21jdGwpOworfQorCisvKiBFbmQgdm1jZSBt
b25pdG9yICovCitpbnQgeGNfZG9tYWluX3ZtY2VfbW9uaXRvcl9lbmQoeGNfaW50ZXJmYWNlICp4
Y2gsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZG9taWQpCit7Cisg
ICAgREVDTEFSRV9ET01DVEw7CisKKyAgICBkb21jdGwuY21kID0gWEVOX0RPTUNUTF92bWNlX21v
bml0b3JfZW5kOworICAgIGRvbWN0bC5kb21haW4gPSAoZG9taWRfdClkb21pZDsKKworICAgIHJl
dHVybiBkb19kb21jdGwoeGNoLCAmZG9tY3RsKTsKK30KKwogLyogZ2V0IGluZm8gZnJvbSBodm0g
Z3Vlc3QgZm9yIHNhdmUgKi8KIGludCB4Y19kb21haW5faHZtX2dldGNvbnRleHQoeGNfaW50ZXJm
YWNlICp4Y2gsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IGRvbWlkLApk
aWZmIC1yIGUyN2E2ZDUzYWMxNSB0b29scy9saWJ4Yy94Y19kb21haW5fc2F2ZS5jCi0tLSBhL3Rv
b2xzL2xpYnhjL3hjX2RvbWFpbl9zYXZlLmMJVGh1IE9jdCAxMSAwMTo1MjozMyAyMDEyICswODAw
CisrKyBiL3Rvb2xzL2xpYnhjL3hjX2RvbWFpbl9zYXZlLmMJVGh1IE9jdCAxMSAwNToxMjo0OCAy
MDEyICswODAwCkBAIC04OTUsNiArODk1LDggQEAKICAgICAgKi8KICAgICBpbnQgY29tcHJlc3Np
bmcgPSAwOwogCisgICAgaW50IHZtY2Vfd2hpbGVfbW9uaXRvciA9IDA7CisKICAgICBpbnQgY29t
cGxldGVkID0gMDsKIAogICAgIGlmICggaHZtICYmICFjYWxsYmFja3MtPnN3aXRjaF9xZW11X2xv
Z2RpcnR5ICkKQEAgLTExMDksNiArMTExMSwxMiBAQAogICAgICAgICBnb3RvIG91dDsKICAgICB9
CiAKKyAgICBpZiAoIHhjX2RvbWFpbl92bWNlX21vbml0b3Jfc3RhcnQoeGNoLCBkb20pICkKKyAg
ICB7CisgICAgICAgIFBFUlJPUigiRXJyb3Igd2hlbiBzdGFydCB2bWNlIG1vbml0b3JcbiIpOwor
ICAgICAgICBnb3RvIG91dDsKKyAgICB9CisKICAgY29weXBhZ2VzOgogI2RlZmluZSB3cmV4YWN0
KGZkLCBidWYsIGxlbikgd3JpdGVfYnVmZmVyKHhjaCwgbGFzdF9pdGVyLCBvYiwgKGZkKSwgKGJ1
ZiksIChsZW4pKQogI2RlZmluZSB3cnVuY2FjaGVkKGZkLCBsaXZlLCBidWYsIGxlbikgd3JpdGVf
dW5jYWNoZWQoeGNoLCBsYXN0X2l0ZXIsIG9iLCAoZmQpLCAoYnVmKSwgKGxlbikpCkBAIC0xNTcx
LDYgKzE1NzksMTggQEAKIAogICAgIERQUklOVEYoIkFsbCBtZW1vcnkgaXMgc2F2ZWRcbiIpOwog
CisgICAgdm1jZV93aGlsZV9tb25pdG9yID0geGNfZG9tYWluX3ZtY2VfbW9uaXRvcl9lbmQoeGNo
LCBkb20pOworICAgIGlmICggdm1jZV93aGlsZV9tb25pdG9yIDwgMCApCisgICAgeworICAgICAg
ICBQRVJST1IoIkVycm9yIHdoZW4gZW5kIHZtY2UgbW9uaXRvclxuIik7CisgICAgICAgIGdvdG8g
b3V0OworICAgIH0KKyAgICBlbHNlIGlmICggdm1jZV93aGlsZV9tb25pdG9yID4gMCApCisgICAg
eworICAgICAgICBmcHJpbnRmKHN0ZGVyciwgInZNQ0Ugb2NjdXJyZWQsIGFib3J0IHRoaXMgdGlt
ZSBhbmQgdHJ5IGxhdGVyLlxuIik7CisgICAgICAgIGdvdG8gb3V0OworICAgIH0KKwogICAgIC8q
IEFmdGVyIGxhc3RfaXRlciwgYnVmZmVyIHRoZSByZXN0IG9mIHBhZ2VidWYgJiB0YWlsYnVmIGRh
dGEgaW50byBhCiAgICAgICogc2VwYXJhdGUgb3V0cHV0IGJ1ZmZlciBhbmQgZmx1c2ggaXQgYWZ0
ZXIgdGhlIGNvbXByZXNzZWQgcGFnZSBjaHVua3MuCiAgICAgICovCmRpZmYgLXIgZTI3YTZkNTNh
YzE1IHRvb2xzL2xpYnhjL3hlbmN0cmwuaAotLS0gYS90b29scy9saWJ4Yy94ZW5jdHJsLmgJVGh1
IE9jdCAxMSAwMTo1MjozMyAyMDEyICswODAwCisrKyBiL3Rvb2xzL2xpYnhjL3hlbmN0cmwuaAlU
aHUgT2N0IDExIDA1OjEyOjQ4IDIwMTIgKzA4MDAKQEAgLTU3NSw2ICs1NzUsMjYgQEAKICAgICAg
ICAgICAgICAgICAgICAgICAgICAgeGNfZG9tYWluaW5mb190ICppbmZvKTsKIAogLyoqCisgKiBU
aGlzIGZ1bmN0aW9uIHN0YXJ0IG1vbml0b3Igdm1jZSBldmVudC4KKyAqIEBwYXJtIHhjaCBhIGhh
bmRsZSB0byBhbiBvcGVuIGh5cGVydmlzb3IgaW50ZXJmYWNlCisgKiBAcGFybSBkb21pZCB0aGUg
ZG9tYWluIGlkIG1vbml0b3JlZAorICogQHJldHVybiA8MCBvbiBmYWlsdXJlLCAwIG9uIHN1Y2Nl
c3MKKyAqLworaW50IHhjX2RvbWFpbl92bWNlX21vbml0b3Jfc3RhcnQoeGNfaW50ZXJmYWNlICp4
Y2gsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJfdCBkb21pZCk7CisK
Ky8qKgorICogVGhpcyBmdW5jdGlvbiBlbmQgbW9uaXRvciB2bWNlIGV2ZW50CisgKiBAcGFybSB4
Y2ggYSBoYW5kbGUgdG8gYW4gb3BlbiBoeXBlcnZpc29yIGludGVyZmFjZQorICogQHBhcm0gZG9t
aWQgdGhlIGRvbWFpbiBpZCBtb25pdG9yZWQKKyAqIEByZXR1cm4gPCAwIG9uIGZhaWx1cmUsID49
IDAgb24gc3VjY2VzcyB3aGlsZQorICogICA9IDAgb24gbm8gdm1jZSBvY2N1cnJlZAorICogICA+
IDAgb24gdm1jZSBvY2N1cnJlZAorICovCitpbnQgeGNfZG9tYWluX3ZtY2VfbW9uaXRvcl9lbmQo
eGNfaW50ZXJmYWNlICp4Y2gsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMy
X3QgZG9taWQpOworCisvKioKICAqIFRoaXMgZnVuY3Rpb24gcmV0dXJucyBpbmZvcm1hdGlvbiBh
Ym91dCB0aGUgY29udGV4dCBvZiBhIGh2bSBkb21haW4KICAqIEBwYXJtIHhjaCBhIGhhbmRsZSB0
byBhbiBvcGVuIGh5cGVydmlzb3IgaW50ZXJmYWNlCiAgKiBAcGFybSBkb21pZCB0aGUgZG9tYWlu
IHRvIGdldCBpbmZvcm1hdGlvbiBmcm9tCmRpZmYgLXIgZTI3YTZkNTNhYzE1IHhlbi9hcmNoL3g4
Ni9jcHUvbWNoZWNrL21jZV9pbnRlbC5jCi0tLSBhL3hlbi9hcmNoL3g4Ni9jcHUvbWNoZWNrL21j
ZV9pbnRlbC5jCVRodSBPY3QgMTEgMDE6NTI6MzMgMjAxMiArMDgwMAorKysgYi94ZW4vYXJjaC94
ODYvY3B1L21jaGVjay9tY2VfaW50ZWwuYwlUaHUgT2N0IDExIDA1OjEyOjQ4IDIwMTIgKzA4MDAK
QEAgLTM1OSw2ICszNTksMTIgQEAKICAgICAgICAgICAgICAgICAgICAgZ290byB2bWNlX2ZhaWxl
ZDsKICAgICAgICAgICAgICAgICB9CiAKKyAgICAgICAgICAgICAgICBpZiAoIHVubGlrZWx5KGQt
PmFyY2gudm1jZV9tb25pdG9yKSApCisgICAgICAgICAgICAgICAgeworICAgICAgICAgICAgICAg
ICAgICAvKiB2TUNFIG9jY3VyIHdoZW4gZ3Vlc3QgbWlncmF0aW9uICovCisgICAgICAgICAgICAg
ICAgICAgIGQtPmFyY2gudm1jZV9tb25pdG9yID0gMTsKKyAgICAgICAgICAgICAgICB9CisKICAg
ICAgICAgICAgICAgICAvKiBXZSB3aWxsIGluamVjdCB2TUNFIHRvIERPTVUqLwogICAgICAgICAg
ICAgICAgIGlmICggaW5qZWN0X3ZtY2UoZCwgVk1DRV9JTkpFQ1RfQlJPQURDQVNUKSA8IDAgKQog
ICAgICAgICAgICAgICAgIHsKZGlmZiAtciBlMjdhNmQ1M2FjMTUgeGVuL2FyY2gveDg2L2RvbWN0
bC5jCi0tLSBhL3hlbi9hcmNoL3g4Ni9kb21jdGwuYwlUaHUgT2N0IDExIDAxOjUyOjMzIDIwMTIg
KzA4MDAKKysrIGIveGVuL2FyY2gveDg2L2RvbWN0bC5jCVRodSBPY3QgMTEgMDU6MTI6NDggMjAx
MiArMDgwMApAQCAtMTU2OCw2ICsxNTY4LDQ3IEBACiAgICAgfQogICAgIGJyZWFrOwogCisgICAg
Y2FzZSBYRU5fRE9NQ1RMX3ZtY2VfbW9uaXRvcl9zdGFydDoKKyAgICB7CisgICAgICAgIHN0cnVj
dCBkb21haW4gKmQ7CisKKyAgICAgICAgZCA9IHJjdV9sb2NrX2RvbWFpbl9ieV9pZChkb21jdGwt
PmRvbWFpbik7CisgICAgICAgIGlmICggZCAhPSBOVUxMICkKKyAgICAgICAgeworICAgICAgICAg
ICAgaWYgKCBkLT5hcmNoLnZtY2VfbW9uaXRvciApCisgICAgICAgICAgICAgICAgcmV0ID0gLUVC
VVNZOworICAgICAgICAgICAgZWxzZQorICAgICAgICAgICAgICAgIGQtPmFyY2gudm1jZV9tb25p
dG9yID0gLTE7CisKKyAgICAgICAgICAgIHJjdV91bmxvY2tfZG9tYWluKGQpOworICAgICAgICB9
CisgICAgICAgIGVsc2UKKyAgICAgICAgICAgIHJldCA9IC1FU1JDSDsKKyAgICB9CisgICAgYnJl
YWs7CisKKyAgICBjYXNlIFhFTl9ET01DVExfdm1jZV9tb25pdG9yX2VuZDoKKyAgICB7CisgICAg
ICAgIHN0cnVjdCBkb21haW4gKmQ7CisKKyAgICAgICAgZCA9IHJjdV9sb2NrX2RvbWFpbl9ieV9p
ZChkb21jdGwtPmRvbWFpbik7CisgICAgICAgIGlmICggZCAhPSBOVUxMKQorICAgICAgICB7Cisg
ICAgICAgICAgICBpZiAoICFkLT5hcmNoLnZtY2VfbW9uaXRvciApCisgICAgICAgICAgICAgICAg
cmV0ID0gLUVJTlZBTDsKKyAgICAgICAgICAgIGVsc2UKKyAgICAgICAgICAgIHsKKyAgICAgICAg
ICAgICAgICByZXQgPSBkLT5hcmNoLnZtY2VfbW9uaXRvciA+IDAgPyAxIDogMDsKKyAgICAgICAg
ICAgICAgICBkLT5hcmNoLnZtY2VfbW9uaXRvciA9IDA7CisgICAgICAgICAgICB9CisKKyAgICAg
ICAgICAgIHJjdV91bmxvY2tfZG9tYWluKGQpOworICAgICAgICB9CisgICAgICAgIGVsc2UKKyAg
ICAgICAgICAgIHJldCA9IC1FU1JDSDsKKyAgICB9CisgICAgYnJlYWs7CisKICAgICBkZWZhdWx0
OgogICAgICAgICByZXQgPSBpb21tdV9kb19kb21jdGwoZG9tY3RsLCB1X2RvbWN0bCk7CiAgICAg
ICAgIGJyZWFrOwpkaWZmIC1yIGUyN2E2ZDUzYWMxNSB4ZW4vaW5jbHVkZS9hc20teDg2L2RvbWFp
bi5oCi0tLSBhL3hlbi9pbmNsdWRlL2FzbS14ODYvZG9tYWluLmgJVGh1IE9jdCAxMSAwMTo1Mjoz
MyAyMDEyICswODAwCisrKyBiL3hlbi9pbmNsdWRlL2FzbS14ODYvZG9tYWluLmgJVGh1IE9jdCAx
MSAwNToxMjo0OCAyMDEyICswODAwCkBAIC0yNzksNiArMjc5LDExIEBACiAgICAgYm9vbF90IGhh
c18zMmJpdF9zaGluZm87CiAgICAgLyogRG9tYWluIGNhbm5vdCBoYW5kbGUgc3B1cmlvdXMgcGFn
ZSBmYXVsdHM/ICovCiAgICAgYm9vbF90IHN1cHByZXNzX3NwdXJpb3VzX3BhZ2VfZmF1bHRzOwor
ICAgIC8qIE1vbml0b3JpbmcgZ3Vlc3QgbWVtb3J5IGNvcHkgb2YgbWlncmF0aW9uCisgICAgICog
PSAwIC0gbm90IG1vbml0b3JpbmcKKyAgICAgKiA8IDAgLSBtb25pdG9yaW5nCisgICAgICogPiAw
IC0gdk1DRSBvY2N1cnJlZCB3aGlsZSBtb25pdG9yaW5nICovCisgICAgczggdm1jZV9tb25pdG9y
OwogCiAgICAgLyogQ29udGludWFibGUgZG9tYWluX3JlbGlucXVpc2hfcmVzb3VyY2VzKCkuICov
CiAgICAgZW51bSB7CmRpZmYgLXIgZTI3YTZkNTNhYzE1IHhlbi9pbmNsdWRlL3B1YmxpYy9kb21j
dGwuaAotLS0gYS94ZW4vaW5jbHVkZS9wdWJsaWMvZG9tY3RsLmgJVGh1IE9jdCAxMSAwMTo1Mjoz
MyAyMDEyICswODAwCisrKyBiL3hlbi9pbmNsdWRlL3B1YmxpYy9kb21jdGwuaAlUaHUgT2N0IDEx
IDA1OjEyOjQ4IDIwMTIgKzA4MDAKQEAgLTkwMCw2ICs5MDAsOCBAQAogI2RlZmluZSBYRU5fRE9N
Q1RMX3NldF9hY2Nlc3NfcmVxdWlyZWQgICAgICAgICAgIDY0CiAjZGVmaW5lIFhFTl9ET01DVExf
YXVkaXRfcDJtICAgICAgICAgICAgICAgICAgICAgNjUKICNkZWZpbmUgWEVOX0RPTUNUTF9zZXRf
dmlycV9oYW5kbGVyICAgICAgICAgICAgICA2NgorI2RlZmluZSBYRU5fRE9NQ1RMX3ZtY2VfbW9u
aXRvcl9zdGFydCAgICAgICAgICAgIDY3CisjZGVmaW5lIFhFTl9ET01DVExfdm1jZV9tb25pdG9y
X2VuZCAgICAgICAgICAgICAgNjgKICNkZWZpbmUgWEVOX0RPTUNUTF9nZGJzeF9ndWVzdG1lbWlv
ICAgICAgICAgICAgMTAwMAogI2RlZmluZSBYRU5fRE9NQ1RMX2dkYnN4X3BhdXNldmNwdSAgICAg
ICAgICAgICAxMDAxCiAjZGVmaW5lIFhFTl9ET01DVExfZ2Ric3hfdW5wYXVzZXZjcHUgICAgICAg
ICAgIDEwMDIK

--_002_DE8DF0795D48FD4CA783C40EC829233534A62FSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC829233534A62FSHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Wed Oct 10 14:47:56 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 14:47:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLxZX-0000Rm-3i; Wed, 10 Oct 2012 14:47:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLxZV-0000RY-Tr
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 14:47:42 +0000
Received: from [85.158.143.35:10684] by server-2.bemta-4.messagelabs.com id
	B6/79-25171-D8A85705; Wed, 10 Oct 2012 14:47:41 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1349880460!13797812!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM3MzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9881 invoked from network); 10 Oct 2012 14:47:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 14:47:40 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="15078191"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 14:47:39 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 10 Oct 2012 15:47:40 +0100
Date: Wed, 10 Oct 2012 15:47:23 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1349855687.6952.75.camel@dagon.hellion.org.uk>
Message-ID: 
References: <1349796183-30648-1-git-send-email-arnd@arndb.de>
	<1349796183-30648-6-git-send-email-arnd@arndb.de>
	
	<201210091821.27818.arnd@arndb.de>
	<1349855687.6952.75.camel@dagon.hellion.org.uk>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge ,
	"xen-devel@lists.xensource.com" ,
	Arnd Bergmann ,
	Konrad Rzeszutek Wilk ,
	Stefano Stabellini ,
	"linux-kernel@vger.kernel.org" ,
	Russell King ,
	"linux-arm-kernel@lists.infradead.org"
	
Subject: Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 10 Oct 2012, Ian Campbell wrote:
> On Tue, 2012-10-09 at 19:21 +0100, Arnd Bergmann wrote:
> > On Tuesday 09 October 2012, Stefano Stabellini wrote:
> > > >  config XEN
> > > >       bool "Xen guest support on ARM (EXPERIMENTAL)"
> > > >       depends on EXPERIMENTAL && ARM && OF
> > > > +     depends on !CPU_V6
> > > >       help
> > > >         Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
> > > 
> > > Considering that we rely on the virtualization extensions, this one can
> > > be:
> > > 
> > >     depends on CPU_V7
> > > 
> > > The rest looks fine. I can submit a second patch to change !CPU_V6 into
> > > CPU_V7 later, if you prefer.
> > 
> > CPU_V6 and CPU_V7 are not exclusive, I saw the problem when building a
> > combined kernel for both V6 and V7. The code also needs to depend on ARMv7
> > with virtualization extensions, but that is a different issue. We don't
> > actually have a configuration symbol for that yet, as far as I can tell.
> 
> I don't think the guest kernels (including dom0) need the extensions to
> run under Xen, they are only need by Xen itself. The guests should just
> see a relatively normal v7 processor. 
> 
> Stefano, does that sound right?

Keep in mind that we are using HVC to issue hypercalls, and HVC has been
introduced with the virtualization extensions, if I am not mistaken.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 14:47:56 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 14:47:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLxZX-0000Rm-3i; Wed, 10 Oct 2012 14:47:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLxZV-0000RY-Tr
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 14:47:42 +0000
Received: from [85.158.143.35:10684] by server-2.bemta-4.messagelabs.com id
	B6/79-25171-D8A85705; Wed, 10 Oct 2012 14:47:41 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1349880460!13797812!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM3MzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9881 invoked from network); 10 Oct 2012 14:47:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 14:47:40 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="15078191"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 14:47:39 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 10 Oct 2012 15:47:40 +0100
Date: Wed, 10 Oct 2012 15:47:23 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1349855687.6952.75.camel@dagon.hellion.org.uk>
Message-ID: 
References: <1349796183-30648-1-git-send-email-arnd@arndb.de>
	<1349796183-30648-6-git-send-email-arnd@arndb.de>
	
	<201210091821.27818.arnd@arndb.de>
	<1349855687.6952.75.camel@dagon.hellion.org.uk>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge ,
	"xen-devel@lists.xensource.com" ,
	Arnd Bergmann ,
	Konrad Rzeszutek Wilk ,
	Stefano Stabellini ,
	"linux-kernel@vger.kernel.org" ,
	Russell King ,
	"linux-arm-kernel@lists.infradead.org"
	
Subject: Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 10 Oct 2012, Ian Campbell wrote:
> On Tue, 2012-10-09 at 19:21 +0100, Arnd Bergmann wrote:
> > On Tuesday 09 October 2012, Stefano Stabellini wrote:
> > > >  config XEN
> > > >       bool "Xen guest support on ARM (EXPERIMENTAL)"
> > > >       depends on EXPERIMENTAL && ARM && OF
> > > > +     depends on !CPU_V6
> > > >       help
> > > >         Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
> > > 
> > > Considering that we rely on the virtualization extensions, this one can
> > > be:
> > > 
> > >     depends on CPU_V7
> > > 
> > > The rest looks fine. I can submit a second patch to change !CPU_V6 into
> > > CPU_V7 later, if you prefer.
> > 
> > CPU_V6 and CPU_V7 are not exclusive, I saw the problem when building a
> > combined kernel for both V6 and V7. The code also needs to depend on ARMv7
> > with virtualization extensions, but that is a different issue. We don't
> > actually have a configuration symbol for that yet, as far as I can tell.
> 
> I don't think the guest kernels (including dom0) need the extensions to
> run under Xen, they are only need by Xen itself. The guests should just
> see a relatively normal v7 processor. 
> 
> Stefano, does that sound right?

Keep in mind that we are using HVC to issue hypercalls, and HVC has been
introduced with the virtualization extensions, if I am not mistaken.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 14:48:12 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 14:48:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLxZo-0000Ub-Gq; Wed, 10 Oct 2012 14:48:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLxZm-0000U3-HK
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 14:47:58 +0000
Received: from [85.158.139.83:38806] by server-2.bemta-5.messagelabs.com id
	9E/B6-15820-D9A85705; Wed, 10 Oct 2012 14:47:57 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1349880474!27051901!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDM1MTAwNg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11643 invoked from network); 10 Oct 2012 14:47:55 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-11.tower-182.messagelabs.com with SMTP;
	10 Oct 2012 14:47:55 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 10 Oct 2012 07:47:54 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,564,1344236400"; d="scan'208";a="232248765"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by fmsmga001.fm.intel.com with ESMTP; 10 Oct 2012 07:47:53 -0700
Received: from fmsmsx153.amr.corp.intel.com (10.19.17.7) by
	FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 10 Oct 2012 07:47:52 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX153.amr.corp.intel.com (10.19.17.7) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 10 Oct 2012 07:47:51 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Wed, 10 Oct 2012 22:47:49 +0800
From: "Liu, Jinsong" 
To: Ian Campbell , "xen-devel@lists.xensource.com"
	
Thread-Topic: [PATCH 5/5] X86/vMCE: guest broken page handling when migration
Thread-Index: Ac2m9jfAoZM8E5DcSNaYfyzWUUgTXw==
Date: Wed, 10 Oct 2012 14:47:49 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC829233534A645SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: Ian Jackson ,
	Christoph Egger ,
	"Keir \(Xen.org\)" , Jan Beulich 
Subject: [Xen-devel] [PATCH 5/5] X86/vMCE: guest broken page handling when
	migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC829233534A645SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

X86/vMCE: guest broken page handling when migration

This patch is used to handle guest broken page when migration.

At sender, the broken page would not be mapped, and the error page
content would not be copied to target, otherwise it may trigger more
serious error (i.e. SRAR error). While its pfn_type and pfn number
would be transferred to target so that target take appropriate action.

At target, it would set p2m as p2m_ram_broken for broken page, so that
if guest access the broken page again, it would kill guest as expected.

Signed-off-by: Liu, Jinsong 

diff -r 090447c780db tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c	Thu Oct 11 05:12:48 2012 +0800
+++ b/tools/libxc/xc_domain.c	Thu Oct 11 05:49:39 2012 +0800
@@ -307,6 +307,22 @@
     return do_domctl(xch, &domctl);
 }
=20
+/* set broken page p2m */
+int xc_set_broken_page_p2m(xc_interface *xch,
+                           uint32_t domid,
+                           unsigned long pfn)
+{
+    int ret;
+    DECLARE_DOMCTL;
+
+    domctl.cmd =3D XEN_DOMCTL_set_broken_page_p2m;
+    domctl.domain =3D (domid_t)domid;
+    domctl.u.set_broken_page_p2m.pfn =3D pfn;
+    ret =3D do_domctl(xch, &domctl);
+
+    return ret ? -1 : 0;
+}
+
 /* get info from hvm guest for save */
 int xc_domain_hvm_getcontext(xc_interface *xch,
                              uint32_t domid,
diff -r 090447c780db tools/libxc/xc_domain_restore.c
--- a/tools/libxc/xc_domain_restore.c	Thu Oct 11 05:12:48 2012 +0800
+++ b/tools/libxc/xc_domain_restore.c	Thu Oct 11 05:49:39 2012 +0800
@@ -962,9 +962,15 @@
=20
     countpages =3D count;
     for (i =3D oldcount; i < buf->nr_pages; ++i)
-        if ((buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) =3D=3D XEN_D=
OMCTL_PFINFO_XTAB
-            ||(buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) =3D=3D XEN=
_DOMCTL_PFINFO_XALLOC)
+    {
+        unsigned long pagetype;
+
+        pagetype =3D buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK;
+        if ( pagetype =3D=3D XEN_DOMCTL_PFINFO_XTAB ||
+             pagetype =3D=3D XEN_DOMCTL_PFINFO_BROKEN ||
+             pagetype =3D=3D XEN_DOMCTL_PFINFO_XALLOC )
             --countpages;
+    }
=20
     if (!countpages)
         return count;
@@ -1200,6 +1206,17 @@
             /* a bogus/unmapped/allocate-only page: skip it */
             continue;
=20
+        if ( pagetype =3D=3D XEN_DOMCTL_PFINFO_BROKEN )
+        {
+            if ( xc_set_broken_page_p2m(xch, dom, pfn) )
+            {
+                ERROR("Set p2m for broken page failed, "
+                      "dom=3D%d, pfn=3D%lx\n", dom, pfn);
+                goto err_mapped;
+            }
+            continue;
+        }
+
         if (pfn_err[i])
         {
             ERROR("unexpected PFN mapping failure pfn %lx map_mfn %lx p2m_=
mfn %lx",
diff -r 090447c780db tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Thu Oct 11 05:12:48 2012 +0800
+++ b/tools/libxc/xc_domain_save.c	Thu Oct 11 05:49:39 2012 +0800
@@ -1285,6 +1285,13 @@
                 if ( !hvm )
                     gmfn =3D pfn_to_mfn(gmfn);
=20
+                if ( pfn_type[j] =3D=3D XEN_DOMCTL_PFINFO_BROKEN )
+                {
+                    pfn_type[j] |=3D pfn_batch[j];
+                    ++run;
+                    continue;
+                }
+
                 if ( pfn_err[j] )
                 {
                     if ( pfn_type[j] =3D=3D XEN_DOMCTL_PFINFO_XTAB )
@@ -1379,8 +1386,12 @@
                     }
                 }
=20
-                /* skip pages that aren't present or are alloc-only */
+                /*
+                 * skip pages that aren't present,
+                 * or are broken, or are alloc-only
+                 */
                 if ( pagetype =3D=3D XEN_DOMCTL_PFINFO_XTAB
+                    || pagetype =3D=3D XEN_DOMCTL_PFINFO_BROKEN
                     || pagetype =3D=3D XEN_DOMCTL_PFINFO_XALLOC )
                     continue;
=20
diff -r 090447c780db tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Thu Oct 11 05:12:48 2012 +0800
+++ b/tools/libxc/xenctrl.h	Thu Oct 11 05:49:39 2012 +0800
@@ -595,6 +595,17 @@
                                uint32_t domid);
=20
 /**
+ * This function set p2m for broken page
+ * &parm xch a handle to an open hypervisor interface
+ * @parm domid the domain id which broken page belong to
+ * @parm pfn the pfn number of the broken page
+ * @return 0 on success, -1 on failure
+ */
+int xc_set_broken_page_p2m(xc_interface *xch,
+                           uint32_t domid,
+                           unsigned long pfn);
+
+/**
  * This function returns information about the context of a hvm domain
  * @parm xch a handle to an open hypervisor interface
  * @parm domid the domain to get information from
diff -r 090447c780db xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c	Thu Oct 11 05:12:48 2012 +0800
+++ b/xen/arch/x86/domctl.c	Thu Oct 11 05:49:39 2012 +0800
@@ -209,12 +209,18 @@
                 for ( j =3D 0; j < k; j++ )
                 {
                     unsigned long type =3D 0;
+                    p2m_type_t t;
=20
-                    page =3D get_page_from_gfn(d, arr[j], NULL, P2M_ALLOC)=
;
+                    page =3D get_page_from_gfn(d, arr[j], &t, P2M_ALLOC);
=20
                     if ( unlikely(!page) ||
                          unlikely(is_xen_heap_page(page)) )
-                        type =3D XEN_DOMCTL_PFINFO_XTAB;
+                    {
+                        if ( p2m_is_broken(t) )
+                            type =3D XEN_DOMCTL_PFINFO_BROKEN;
+                        else
+                            type =3D XEN_DOMCTL_PFINFO_XTAB;
+                    }
                     else
                     {
                         switch( page->u.inuse.type_info & PGT_type_mask )
@@ -235,6 +241,9 @@
=20
                         if ( page->u.inuse.type_info & PGT_pinned )
                             type |=3D XEN_DOMCTL_PFINFO_LPINTAB;
+
+                        if ( page->count_info & PGC_broken )
+                            type =3D XEN_DOMCTL_PFINFO_BROKEN;
                     }
=20
                     if ( page )
@@ -1609,6 +1618,28 @@
     }
     break;
=20
+    case XEN_DOMCTL_set_broken_page_p2m:
+    {
+        struct domain *d;
+        p2m_type_t pt;
+        unsigned long pfn;
+
+        d =3D rcu_lock_domain_by_id(domctl->domain);
+        if ( d !=3D NULL )
+        {
+            pfn =3D domctl->u.set_broken_page_p2m.pfn;
+
+            get_gfn_query(d, pfn, &pt);
+            p2m_change_type(d, pfn, pt, p2m_ram_broken);
+            put_gfn(d, pfn);
+
+            rcu_unlock_domain(d);
+        }
+        else
+            ret =3D -ESRCH;
+    }
+    break;
+
     default:
         ret =3D iommu_do_domctl(domctl, u_domctl);
         break;
diff -r 090447c780db xen/include/public/domctl.h
--- a/xen/include/public/domctl.h	Thu Oct 11 05:12:48 2012 +0800
+++ b/xen/include/public/domctl.h	Thu Oct 11 05:49:39 2012 +0800
@@ -136,6 +136,7 @@
 #define XEN_DOMCTL_PFINFO_LPINTAB (0x1U<<31)
 #define XEN_DOMCTL_PFINFO_XTAB    (0xfU<<28) /* invalid page */
 #define XEN_DOMCTL_PFINFO_XALLOC  (0xeU<<28) /* allocate-only page */
+#define XEN_DOMCTL_PFINFO_BROKEN  (0xdU<<28) /* broken page */
 #define XEN_DOMCTL_PFINFO_PAGEDTAB (0x8U<<28)
 #define XEN_DOMCTL_PFINFO_LTAB_MASK (0xfU<<28)
=20
@@ -835,6 +836,12 @@
 typedef struct xen_domctl_set_access_required xen_domctl_set_access_requir=
ed_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_access_required_t);
=20
+struct xen_domctl_set_broken_page_p2m {
+    uint64_aligned_t pfn;
+};
+typedef struct xen_domctl_set_broken_page_p2m xen_domctl_set_broken_page_p=
2m_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_broken_page_p2m_t);
+
 struct xen_domctl {
     uint32_t cmd;
 #define XEN_DOMCTL_createdomain                   1
@@ -902,6 +909,7 @@
 #define XEN_DOMCTL_set_virq_handler              66
 #define XEN_DOMCTL_vmce_monitor_start            67
 #define XEN_DOMCTL_vmce_monitor_end              68
+#define XEN_DOMCTL_set_broken_page_p2m           69
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -957,6 +965,7 @@
         struct xen_domctl_audit_p2m         audit_p2m;
         struct xen_domctl_set_virq_handler  set_virq_handler;
         struct xen_domctl_gdbsx_memio       gdbsx_guest_memio;
+        struct xen_domctl_set_broken_page_p2m set_broken_page_p2m;
         struct xen_domctl_gdbsx_pauseunp_vcpu gdbsx_pauseunp_vcpu;
         struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
         uint8_t                             pad[128];=

--_002_DE8DF0795D48FD4CA783C40EC829233534A645SHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="5_vmce_migration_pfntype_broken.patch"
Content-Description: 5_vmce_migration_pfntype_broken.patch
Content-Disposition: attachment;
	filename="5_vmce_migration_pfntype_broken.patch"; size=8521;
	creation-date="Wed, 10 Oct 2012 14:32:13 GMT";
	modification-date="Wed, 10 Oct 2012 21:49:40 GMT"
Content-Transfer-Encoding: base64

WDg2L3ZNQ0U6IGd1ZXN0IGJyb2tlbiBwYWdlIGhhbmRsaW5nIHdoZW4gbWlncmF0aW9uCgpUaGlz
IHBhdGNoIGlzIHVzZWQgdG8gaGFuZGxlIGd1ZXN0IGJyb2tlbiBwYWdlIHdoZW4gbWlncmF0aW9u
LgoKQXQgc2VuZGVyLCB0aGUgYnJva2VuIHBhZ2Ugd291bGQgbm90IGJlIG1hcHBlZCwgYW5kIHRo
ZSBlcnJvciBwYWdlCmNvbnRlbnQgd291bGQgbm90IGJlIGNvcGllZCB0byB0YXJnZXQsIG90aGVy
d2lzZSBpdCBtYXkgdHJpZ2dlciBtb3JlCnNlcmlvdXMgZXJyb3IgKGkuZS4gU1JBUiBlcnJvciku
IFdoaWxlIGl0cyBwZm5fdHlwZSBhbmQgcGZuIG51bWJlcgp3b3VsZCBiZSB0cmFuc2ZlcnJlZCB0
byB0YXJnZXQgc28gdGhhdCB0YXJnZXQgdGFrZSBhcHByb3ByaWF0ZSBhY3Rpb24uCgpBdCB0YXJn
ZXQsIGl0IHdvdWxkIHNldCBwMm0gYXMgcDJtX3JhbV9icm9rZW4gZm9yIGJyb2tlbiBwYWdlLCBz
byB0aGF0CmlmIGd1ZXN0IGFjY2VzcyB0aGUgYnJva2VuIHBhZ2UgYWdhaW4sIGl0IHdvdWxkIGtp
bGwgZ3Vlc3QgYXMgZXhwZWN0ZWQuCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNv
bmcubGl1QGludGVsLmNvbT4KCmRpZmYgLXIgMDkwNDQ3Yzc4MGRiIHRvb2xzL2xpYnhjL3hjX2Rv
bWFpbi5jCi0tLSBhL3Rvb2xzL2xpYnhjL3hjX2RvbWFpbi5jCVRodSBPY3QgMTEgMDU6MTI6NDgg
MjAxMiArMDgwMAorKysgYi90b29scy9saWJ4Yy94Y19kb21haW4uYwlUaHUgT2N0IDExIDA1OjQ5
OjM5IDIwMTIgKzA4MDAKQEAgLTMwNyw2ICszMDcsMjIgQEAKICAgICByZXR1cm4gZG9fZG9tY3Rs
KHhjaCwgJmRvbWN0bCk7CiB9CiAKKy8qIHNldCBicm9rZW4gcGFnZSBwMm0gKi8KK2ludCB4Y19z
ZXRfYnJva2VuX3BhZ2VfcDJtKHhjX2ludGVyZmFjZSAqeGNoLAorICAgICAgICAgICAgICAgICAg
ICAgICAgICAgdWludDMyX3QgZG9taWQsCisgICAgICAgICAgICAgICAgICAgICAgICAgICB1bnNp
Z25lZCBsb25nIHBmbikKK3sKKyAgICBpbnQgcmV0OworICAgIERFQ0xBUkVfRE9NQ1RMOworCisg
ICAgZG9tY3RsLmNtZCA9IFhFTl9ET01DVExfc2V0X2Jyb2tlbl9wYWdlX3AybTsKKyAgICBkb21j
dGwuZG9tYWluID0gKGRvbWlkX3QpZG9taWQ7CisgICAgZG9tY3RsLnUuc2V0X2Jyb2tlbl9wYWdl
X3AybS5wZm4gPSBwZm47CisgICAgcmV0ID0gZG9fZG9tY3RsKHhjaCwgJmRvbWN0bCk7CisKKyAg
ICByZXR1cm4gcmV0ID8gLTEgOiAwOworfQorCiAvKiBnZXQgaW5mbyBmcm9tIGh2bSBndWVzdCBm
b3Igc2F2ZSAqLwogaW50IHhjX2RvbWFpbl9odm1fZ2V0Y29udGV4dCh4Y19pbnRlcmZhY2UgKnhj
aCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZG9taWQsCmRpZmYgLXIg
MDkwNDQ3Yzc4MGRiIHRvb2xzL2xpYnhjL3hjX2RvbWFpbl9yZXN0b3JlLmMKLS0tIGEvdG9vbHMv
bGlieGMveGNfZG9tYWluX3Jlc3RvcmUuYwlUaHUgT2N0IDExIDA1OjEyOjQ4IDIwMTIgKzA4MDAK
KysrIGIvdG9vbHMvbGlieGMveGNfZG9tYWluX3Jlc3RvcmUuYwlUaHUgT2N0IDExIDA1OjQ5OjM5
IDIwMTIgKzA4MDAKQEAgLTk2Miw5ICs5NjIsMTUgQEAKIAogICAgIGNvdW50cGFnZXMgPSBjb3Vu
dDsKICAgICBmb3IgKGkgPSBvbGRjb3VudDsgaSA8IGJ1Zi0+bnJfcGFnZXM7ICsraSkKLSAgICAg
ICAgaWYgKChidWYtPnBmbl90eXBlc1tpXSAmIFhFTl9ET01DVExfUEZJTkZPX0xUQUJfTUFTSykg
PT0gWEVOX0RPTUNUTF9QRklORk9fWFRBQgotICAgICAgICAgICAgfHwoYnVmLT5wZm5fdHlwZXNb
aV0gJiBYRU5fRE9NQ1RMX1BGSU5GT19MVEFCX01BU0spID09IFhFTl9ET01DVExfUEZJTkZPX1hB
TExPQykKKyAgICB7CisgICAgICAgIHVuc2lnbmVkIGxvbmcgcGFnZXR5cGU7CisKKyAgICAgICAg
cGFnZXR5cGUgPSBidWYtPnBmbl90eXBlc1tpXSAmIFhFTl9ET01DVExfUEZJTkZPX0xUQUJfTUFT
SzsKKyAgICAgICAgaWYgKCBwYWdldHlwZSA9PSBYRU5fRE9NQ1RMX1BGSU5GT19YVEFCIHx8Cisg
ICAgICAgICAgICAgcGFnZXR5cGUgPT0gWEVOX0RPTUNUTF9QRklORk9fQlJPS0VOIHx8CisgICAg
ICAgICAgICAgcGFnZXR5cGUgPT0gWEVOX0RPTUNUTF9QRklORk9fWEFMTE9DICkKICAgICAgICAg
ICAgIC0tY291bnRwYWdlczsKKyAgICB9CiAKICAgICBpZiAoIWNvdW50cGFnZXMpCiAgICAgICAg
IHJldHVybiBjb3VudDsKQEAgLTEyMDAsNiArMTIwNiwxNyBAQAogICAgICAgICAgICAgLyogYSBi
b2d1cy91bm1hcHBlZC9hbGxvY2F0ZS1vbmx5IHBhZ2U6IHNraXAgaXQgKi8KICAgICAgICAgICAg
IGNvbnRpbnVlOwogCisgICAgICAgIGlmICggcGFnZXR5cGUgPT0gWEVOX0RPTUNUTF9QRklORk9f
QlJPS0VOICkKKyAgICAgICAgeworICAgICAgICAgICAgaWYgKCB4Y19zZXRfYnJva2VuX3BhZ2Vf
cDJtKHhjaCwgZG9tLCBwZm4pICkKKyAgICAgICAgICAgIHsKKyAgICAgICAgICAgICAgICBFUlJP
UigiU2V0IHAybSBmb3IgYnJva2VuIHBhZ2UgZmFpbGVkLCAiCisgICAgICAgICAgICAgICAgICAg
ICAgImRvbT0lZCwgcGZuPSVseFxuIiwgZG9tLCBwZm4pOworICAgICAgICAgICAgICAgIGdvdG8g
ZXJyX21hcHBlZDsKKyAgICAgICAgICAgIH0KKyAgICAgICAgICAgIGNvbnRpbnVlOworICAgICAg
ICB9CisKICAgICAgICAgaWYgKHBmbl9lcnJbaV0pCiAgICAgICAgIHsKICAgICAgICAgICAgIEVS
Uk9SKCJ1bmV4cGVjdGVkIFBGTiBtYXBwaW5nIGZhaWx1cmUgcGZuICVseCBtYXBfbWZuICVseCBw
Mm1fbWZuICVseCIsCmRpZmYgLXIgMDkwNDQ3Yzc4MGRiIHRvb2xzL2xpYnhjL3hjX2RvbWFpbl9z
YXZlLmMKLS0tIGEvdG9vbHMvbGlieGMveGNfZG9tYWluX3NhdmUuYwlUaHUgT2N0IDExIDA1OjEy
OjQ4IDIwMTIgKzA4MDAKKysrIGIvdG9vbHMvbGlieGMveGNfZG9tYWluX3NhdmUuYwlUaHUgT2N0
IDExIDA1OjQ5OjM5IDIwMTIgKzA4MDAKQEAgLTEyODUsNiArMTI4NSwxMyBAQAogICAgICAgICAg
ICAgICAgIGlmICggIWh2bSApCiAgICAgICAgICAgICAgICAgICAgIGdtZm4gPSBwZm5fdG9fbWZu
KGdtZm4pOwogCisgICAgICAgICAgICAgICAgaWYgKCBwZm5fdHlwZVtqXSA9PSBYRU5fRE9NQ1RM
X1BGSU5GT19CUk9LRU4gKQorICAgICAgICAgICAgICAgIHsKKyAgICAgICAgICAgICAgICAgICAg
cGZuX3R5cGVbal0gfD0gcGZuX2JhdGNoW2pdOworICAgICAgICAgICAgICAgICAgICArK3J1bjsK
KyAgICAgICAgICAgICAgICAgICAgY29udGludWU7CisgICAgICAgICAgICAgICAgfQorCiAgICAg
ICAgICAgICAgICAgaWYgKCBwZm5fZXJyW2pdICkKICAgICAgICAgICAgICAgICB7CiAgICAgICAg
ICAgICAgICAgICAgIGlmICggcGZuX3R5cGVbal0gPT0gWEVOX0RPTUNUTF9QRklORk9fWFRBQiAp
CkBAIC0xMzc5LDggKzEzODYsMTIgQEAKICAgICAgICAgICAgICAgICAgICAgfQogICAgICAgICAg
ICAgICAgIH0KIAotICAgICAgICAgICAgICAgIC8qIHNraXAgcGFnZXMgdGhhdCBhcmVuJ3QgcHJl
c2VudCBvciBhcmUgYWxsb2Mtb25seSAqLworICAgICAgICAgICAgICAgIC8qCisgICAgICAgICAg
ICAgICAgICogc2tpcCBwYWdlcyB0aGF0IGFyZW4ndCBwcmVzZW50LAorICAgICAgICAgICAgICAg
ICAqIG9yIGFyZSBicm9rZW4sIG9yIGFyZSBhbGxvYy1vbmx5CisgICAgICAgICAgICAgICAgICov
CiAgICAgICAgICAgICAgICAgaWYgKCBwYWdldHlwZSA9PSBYRU5fRE9NQ1RMX1BGSU5GT19YVEFC
CisgICAgICAgICAgICAgICAgICAgIHx8IHBhZ2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX0JS
T0tFTgogICAgICAgICAgICAgICAgICAgICB8fCBwYWdldHlwZSA9PSBYRU5fRE9NQ1RMX1BGSU5G
T19YQUxMT0MgKQogICAgICAgICAgICAgICAgICAgICBjb250aW51ZTsKIApkaWZmIC1yIDA5MDQ0
N2M3ODBkYiB0b29scy9saWJ4Yy94ZW5jdHJsLmgKLS0tIGEvdG9vbHMvbGlieGMveGVuY3RybC5o
CVRodSBPY3QgMTEgMDU6MTI6NDggMjAxMiArMDgwMAorKysgYi90b29scy9saWJ4Yy94ZW5jdHJs
LmgJVGh1IE9jdCAxMSAwNTo0OTozOSAyMDEyICswODAwCkBAIC01OTUsNiArNTk1LDE3IEBACiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZG9taWQpOwogCiAvKioKKyAq
IFRoaXMgZnVuY3Rpb24gc2V0IHAybSBmb3IgYnJva2VuIHBhZ2UKKyAqICZwYXJtIHhjaCBhIGhh
bmRsZSB0byBhbiBvcGVuIGh5cGVydmlzb3IgaW50ZXJmYWNlCisgKiBAcGFybSBkb21pZCB0aGUg
ZG9tYWluIGlkIHdoaWNoIGJyb2tlbiBwYWdlIGJlbG9uZyB0bworICogQHBhcm0gcGZuIHRoZSBw
Zm4gbnVtYmVyIG9mIHRoZSBicm9rZW4gcGFnZQorICogQHJldHVybiAwIG9uIHN1Y2Nlc3MsIC0x
IG9uIGZhaWx1cmUKKyAqLworaW50IHhjX3NldF9icm9rZW5fcGFnZV9wMm0oeGNfaW50ZXJmYWNl
ICp4Y2gsCisgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJfdCBkb21pZCwKKyAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHVuc2lnbmVkIGxvbmcgcGZuKTsKKworLyoqCiAgKiBUaGlz
IGZ1bmN0aW9uIHJldHVybnMgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGNvbnRleHQgb2YgYSBodm0g
ZG9tYWluCiAgKiBAcGFybSB4Y2ggYSBoYW5kbGUgdG8gYW4gb3BlbiBoeXBlcnZpc29yIGludGVy
ZmFjZQogICogQHBhcm0gZG9taWQgdGhlIGRvbWFpbiB0byBnZXQgaW5mb3JtYXRpb24gZnJvbQpk
aWZmIC1yIDA5MDQ0N2M3ODBkYiB4ZW4vYXJjaC94ODYvZG9tY3RsLmMKLS0tIGEveGVuL2FyY2gv
eDg2L2RvbWN0bC5jCVRodSBPY3QgMTEgMDU6MTI6NDggMjAxMiArMDgwMAorKysgYi94ZW4vYXJj
aC94ODYvZG9tY3RsLmMJVGh1IE9jdCAxMSAwNTo0OTozOSAyMDEyICswODAwCkBAIC0yMDksMTIg
KzIwOSwxOCBAQAogICAgICAgICAgICAgICAgIGZvciAoIGogPSAwOyBqIDwgazsgaisrICkKICAg
ICAgICAgICAgICAgICB7CiAgICAgICAgICAgICAgICAgICAgIHVuc2lnbmVkIGxvbmcgdHlwZSA9
IDA7CisgICAgICAgICAgICAgICAgICAgIHAybV90eXBlX3QgdDsKIAotICAgICAgICAgICAgICAg
ICAgICBwYWdlID0gZ2V0X3BhZ2VfZnJvbV9nZm4oZCwgYXJyW2pdLCBOVUxMLCBQMk1fQUxMT0Mp
OworICAgICAgICAgICAgICAgICAgICBwYWdlID0gZ2V0X3BhZ2VfZnJvbV9nZm4oZCwgYXJyW2pd
LCAmdCwgUDJNX0FMTE9DKTsKIAogICAgICAgICAgICAgICAgICAgICBpZiAoIHVubGlrZWx5KCFw
YWdlKSB8fAogICAgICAgICAgICAgICAgICAgICAgICAgIHVubGlrZWx5KGlzX3hlbl9oZWFwX3Bh
Z2UocGFnZSkpICkKLSAgICAgICAgICAgICAgICAgICAgICAgIHR5cGUgPSBYRU5fRE9NQ1RMX1BG
SU5GT19YVEFCOworICAgICAgICAgICAgICAgICAgICB7CisgICAgICAgICAgICAgICAgICAgICAg
ICBpZiAoIHAybV9pc19icm9rZW4odCkgKQorICAgICAgICAgICAgICAgICAgICAgICAgICAgIHR5
cGUgPSBYRU5fRE9NQ1RMX1BGSU5GT19CUk9LRU47CisgICAgICAgICAgICAgICAgICAgICAgICBl
bHNlCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgdHlwZSA9IFhFTl9ET01DVExfUEZJTkZP
X1hUQUI7CisgICAgICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgICAgICAgICAgZWxzZQog
ICAgICAgICAgICAgICAgICAgICB7CiAgICAgICAgICAgICAgICAgICAgICAgICBzd2l0Y2goIHBh
Z2UtPnUuaW51c2UudHlwZV9pbmZvICYgUEdUX3R5cGVfbWFzayApCkBAIC0yMzUsNiArMjQxLDkg
QEAKIAogICAgICAgICAgICAgICAgICAgICAgICAgaWYgKCBwYWdlLT51LmludXNlLnR5cGVfaW5m
byAmIFBHVF9waW5uZWQgKQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIHR5cGUgfD0gWEVO
X0RPTUNUTF9QRklORk9fTFBJTlRBQjsKKworICAgICAgICAgICAgICAgICAgICAgICAgaWYgKCBw
YWdlLT5jb3VudF9pbmZvICYgUEdDX2Jyb2tlbiApCisgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgdHlwZSA9IFhFTl9ET01DVExfUEZJTkZPX0JST0tFTjsKICAgICAgICAgICAgICAgICAgICAg
fQogCiAgICAgICAgICAgICAgICAgICAgIGlmICggcGFnZSApCkBAIC0xNjA5LDYgKzE2MTgsMjgg
QEAKICAgICB9CiAgICAgYnJlYWs7CiAKKyAgICBjYXNlIFhFTl9ET01DVExfc2V0X2Jyb2tlbl9w
YWdlX3AybToKKyAgICB7CisgICAgICAgIHN0cnVjdCBkb21haW4gKmQ7CisgICAgICAgIHAybV90
eXBlX3QgcHQ7CisgICAgICAgIHVuc2lnbmVkIGxvbmcgcGZuOworCisgICAgICAgIGQgPSByY3Vf
bG9ja19kb21haW5fYnlfaWQoZG9tY3RsLT5kb21haW4pOworICAgICAgICBpZiAoIGQgIT0gTlVM
TCApCisgICAgICAgIHsKKyAgICAgICAgICAgIHBmbiA9IGRvbWN0bC0+dS5zZXRfYnJva2VuX3Bh
Z2VfcDJtLnBmbjsKKworICAgICAgICAgICAgZ2V0X2dmbl9xdWVyeShkLCBwZm4sICZwdCk7Cisg
ICAgICAgICAgICBwMm1fY2hhbmdlX3R5cGUoZCwgcGZuLCBwdCwgcDJtX3JhbV9icm9rZW4pOwor
ICAgICAgICAgICAgcHV0X2dmbihkLCBwZm4pOworCisgICAgICAgICAgICByY3VfdW5sb2NrX2Rv
bWFpbihkKTsKKyAgICAgICAgfQorICAgICAgICBlbHNlCisgICAgICAgICAgICByZXQgPSAtRVNS
Q0g7CisgICAgfQorICAgIGJyZWFrOworCiAgICAgZGVmYXVsdDoKICAgICAgICAgcmV0ID0gaW9t
bXVfZG9fZG9tY3RsKGRvbWN0bCwgdV9kb21jdGwpOwogICAgICAgICBicmVhazsKZGlmZiAtciAw
OTA0NDdjNzgwZGIgeGVuL2luY2x1ZGUvcHVibGljL2RvbWN0bC5oCi0tLSBhL3hlbi9pbmNsdWRl
L3B1YmxpYy9kb21jdGwuaAlUaHUgT2N0IDExIDA1OjEyOjQ4IDIwMTIgKzA4MDAKKysrIGIveGVu
L2luY2x1ZGUvcHVibGljL2RvbWN0bC5oCVRodSBPY3QgMTEgMDU6NDk6MzkgMjAxMiArMDgwMApA
QCAtMTM2LDYgKzEzNiw3IEBACiAjZGVmaW5lIFhFTl9ET01DVExfUEZJTkZPX0xQSU5UQUIgKDB4
MVU8PDMxKQogI2RlZmluZSBYRU5fRE9NQ1RMX1BGSU5GT19YVEFCICAgICgweGZVPDwyOCkgLyog
aW52YWxpZCBwYWdlICovCiAjZGVmaW5lIFhFTl9ET01DVExfUEZJTkZPX1hBTExPQyAgKDB4ZVU8
PDI4KSAvKiBhbGxvY2F0ZS1vbmx5IHBhZ2UgKi8KKyNkZWZpbmUgWEVOX0RPTUNUTF9QRklORk9f
QlJPS0VOICAoMHhkVTw8MjgpIC8qIGJyb2tlbiBwYWdlICovCiAjZGVmaW5lIFhFTl9ET01DVExf
UEZJTkZPX1BBR0VEVEFCICgweDhVPDwyOCkKICNkZWZpbmUgWEVOX0RPTUNUTF9QRklORk9fTFRB
Ql9NQVNLICgweGZVPDwyOCkKIApAQCAtODM1LDYgKzgzNiwxMiBAQAogdHlwZWRlZiBzdHJ1Y3Qg
eGVuX2RvbWN0bF9zZXRfYWNjZXNzX3JlcXVpcmVkIHhlbl9kb21jdGxfc2V0X2FjY2Vzc19yZXF1
aXJlZF90OwogREVGSU5FX1hFTl9HVUVTVF9IQU5ETEUoeGVuX2RvbWN0bF9zZXRfYWNjZXNzX3Jl
cXVpcmVkX3QpOwogCitzdHJ1Y3QgeGVuX2RvbWN0bF9zZXRfYnJva2VuX3BhZ2VfcDJtIHsKKyAg
ICB1aW50NjRfYWxpZ25lZF90IHBmbjsKK307Cit0eXBlZGVmIHN0cnVjdCB4ZW5fZG9tY3RsX3Nl
dF9icm9rZW5fcGFnZV9wMm0geGVuX2RvbWN0bF9zZXRfYnJva2VuX3BhZ2VfcDJtX3Q7CitERUZJ
TkVfWEVOX0dVRVNUX0hBTkRMRSh4ZW5fZG9tY3RsX3NldF9icm9rZW5fcGFnZV9wMm1fdCk7CisK
IHN0cnVjdCB4ZW5fZG9tY3RsIHsKICAgICB1aW50MzJfdCBjbWQ7CiAjZGVmaW5lIFhFTl9ET01D
VExfY3JlYXRlZG9tYWluICAgICAgICAgICAgICAgICAgIDEKQEAgLTkwMiw2ICs5MDksNyBAQAog
I2RlZmluZSBYRU5fRE9NQ1RMX3NldF92aXJxX2hhbmRsZXIgICAgICAgICAgICAgIDY2CiAjZGVm
aW5lIFhFTl9ET01DVExfdm1jZV9tb25pdG9yX3N0YXJ0ICAgICAgICAgICAgNjcKICNkZWZpbmUg
WEVOX0RPTUNUTF92bWNlX21vbml0b3JfZW5kICAgICAgICAgICAgICA2OAorI2RlZmluZSBYRU5f
RE9NQ1RMX3NldF9icm9rZW5fcGFnZV9wMm0gICAgICAgICAgIDY5CiAjZGVmaW5lIFhFTl9ET01D
VExfZ2Ric3hfZ3Vlc3RtZW1pbyAgICAgICAgICAgIDEwMDAKICNkZWZpbmUgWEVOX0RPTUNUTF9n
ZGJzeF9wYXVzZXZjcHUgICAgICAgICAgICAgMTAwMQogI2RlZmluZSBYRU5fRE9NQ1RMX2dkYnN4
X3VucGF1c2V2Y3B1ICAgICAgICAgICAxMDAyCkBAIC05NTcsNiArOTY1LDcgQEAKICAgICAgICAg
c3RydWN0IHhlbl9kb21jdGxfYXVkaXRfcDJtICAgICAgICAgYXVkaXRfcDJtOwogICAgICAgICBz
dHJ1Y3QgeGVuX2RvbWN0bF9zZXRfdmlycV9oYW5kbGVyICBzZXRfdmlycV9oYW5kbGVyOwogICAg
ICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF9nZGJzeF9tZW1pbyAgICAgICBnZGJzeF9ndWVzdF9tZW1p
bzsKKyAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfc2V0X2Jyb2tlbl9wYWdlX3AybSBzZXRfYnJv
a2VuX3BhZ2VfcDJtOwogICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF9nZGJzeF9wYXVzZXVucF92
Y3B1IGdkYnN4X3BhdXNldW5wX3ZjcHU7CiAgICAgICAgIHN0cnVjdCB4ZW5fZG9tY3RsX2dkYnN4
X2RvbXN0YXR1cyAgIGdkYnN4X2RvbXN0YXR1czsKICAgICAgICAgdWludDhfdCAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgcGFkWzEyOF07Cg==

--_002_DE8DF0795D48FD4CA783C40EC829233534A645SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC829233534A645SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Wed Oct 10 14:48:12 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 14:48:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLxZo-0000Ub-Gq; Wed, 10 Oct 2012 14:48:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLxZm-0000U3-HK
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 14:47:58 +0000
Received: from [85.158.139.83:38806] by server-2.bemta-5.messagelabs.com id
	9E/B6-15820-D9A85705; Wed, 10 Oct 2012 14:47:57 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1349880474!27051901!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDM1MTAwNg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11643 invoked from network); 10 Oct 2012 14:47:55 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-11.tower-182.messagelabs.com with SMTP;
	10 Oct 2012 14:47:55 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 10 Oct 2012 07:47:54 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,564,1344236400"; d="scan'208";a="232248765"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by fmsmga001.fm.intel.com with ESMTP; 10 Oct 2012 07:47:53 -0700
Received: from fmsmsx153.amr.corp.intel.com (10.19.17.7) by
	FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 10 Oct 2012 07:47:52 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX153.amr.corp.intel.com (10.19.17.7) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 10 Oct 2012 07:47:51 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Wed, 10 Oct 2012 22:47:49 +0800
From: "Liu, Jinsong" 
To: Ian Campbell , "xen-devel@lists.xensource.com"
	
Thread-Topic: [PATCH 5/5] X86/vMCE: guest broken page handling when migration
Thread-Index: Ac2m9jfAoZM8E5DcSNaYfyzWUUgTXw==
Date: Wed, 10 Oct 2012 14:47:49 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC829233534A645SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: Ian Jackson ,
	Christoph Egger ,
	"Keir \(Xen.org\)" , Jan Beulich 
Subject: [Xen-devel] [PATCH 5/5] X86/vMCE: guest broken page handling when
	migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC829233534A645SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

X86/vMCE: guest broken page handling when migration

This patch is used to handle guest broken page when migration.

At sender, the broken page would not be mapped, and the error page
content would not be copied to target, otherwise it may trigger more
serious error (i.e. SRAR error). While its pfn_type and pfn number
would be transferred to target so that target take appropriate action.

At target, it would set p2m as p2m_ram_broken for broken page, so that
if guest access the broken page again, it would kill guest as expected.

Signed-off-by: Liu, Jinsong 

diff -r 090447c780db tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c	Thu Oct 11 05:12:48 2012 +0800
+++ b/tools/libxc/xc_domain.c	Thu Oct 11 05:49:39 2012 +0800
@@ -307,6 +307,22 @@
     return do_domctl(xch, &domctl);
 }
=20
+/* set broken page p2m */
+int xc_set_broken_page_p2m(xc_interface *xch,
+                           uint32_t domid,
+                           unsigned long pfn)
+{
+    int ret;
+    DECLARE_DOMCTL;
+
+    domctl.cmd =3D XEN_DOMCTL_set_broken_page_p2m;
+    domctl.domain =3D (domid_t)domid;
+    domctl.u.set_broken_page_p2m.pfn =3D pfn;
+    ret =3D do_domctl(xch, &domctl);
+
+    return ret ? -1 : 0;
+}
+
 /* get info from hvm guest for save */
 int xc_domain_hvm_getcontext(xc_interface *xch,
                              uint32_t domid,
diff -r 090447c780db tools/libxc/xc_domain_restore.c
--- a/tools/libxc/xc_domain_restore.c	Thu Oct 11 05:12:48 2012 +0800
+++ b/tools/libxc/xc_domain_restore.c	Thu Oct 11 05:49:39 2012 +0800
@@ -962,9 +962,15 @@
=20
     countpages =3D count;
     for (i =3D oldcount; i < buf->nr_pages; ++i)
-        if ((buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) =3D=3D XEN_D=
OMCTL_PFINFO_XTAB
-            ||(buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) =3D=3D XEN=
_DOMCTL_PFINFO_XALLOC)
+    {
+        unsigned long pagetype;
+
+        pagetype =3D buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK;
+        if ( pagetype =3D=3D XEN_DOMCTL_PFINFO_XTAB ||
+             pagetype =3D=3D XEN_DOMCTL_PFINFO_BROKEN ||
+             pagetype =3D=3D XEN_DOMCTL_PFINFO_XALLOC )
             --countpages;
+    }
=20
     if (!countpages)
         return count;
@@ -1200,6 +1206,17 @@
             /* a bogus/unmapped/allocate-only page: skip it */
             continue;
=20
+        if ( pagetype =3D=3D XEN_DOMCTL_PFINFO_BROKEN )
+        {
+            if ( xc_set_broken_page_p2m(xch, dom, pfn) )
+            {
+                ERROR("Set p2m for broken page failed, "
+                      "dom=3D%d, pfn=3D%lx\n", dom, pfn);
+                goto err_mapped;
+            }
+            continue;
+        }
+
         if (pfn_err[i])
         {
             ERROR("unexpected PFN mapping failure pfn %lx map_mfn %lx p2m_=
mfn %lx",
diff -r 090447c780db tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Thu Oct 11 05:12:48 2012 +0800
+++ b/tools/libxc/xc_domain_save.c	Thu Oct 11 05:49:39 2012 +0800
@@ -1285,6 +1285,13 @@
                 if ( !hvm )
                     gmfn =3D pfn_to_mfn(gmfn);
=20
+                if ( pfn_type[j] =3D=3D XEN_DOMCTL_PFINFO_BROKEN )
+                {
+                    pfn_type[j] |=3D pfn_batch[j];
+                    ++run;
+                    continue;
+                }
+
                 if ( pfn_err[j] )
                 {
                     if ( pfn_type[j] =3D=3D XEN_DOMCTL_PFINFO_XTAB )
@@ -1379,8 +1386,12 @@
                     }
                 }
=20
-                /* skip pages that aren't present or are alloc-only */
+                /*
+                 * skip pages that aren't present,
+                 * or are broken, or are alloc-only
+                 */
                 if ( pagetype =3D=3D XEN_DOMCTL_PFINFO_XTAB
+                    || pagetype =3D=3D XEN_DOMCTL_PFINFO_BROKEN
                     || pagetype =3D=3D XEN_DOMCTL_PFINFO_XALLOC )
                     continue;
=20
diff -r 090447c780db tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Thu Oct 11 05:12:48 2012 +0800
+++ b/tools/libxc/xenctrl.h	Thu Oct 11 05:49:39 2012 +0800
@@ -595,6 +595,17 @@
                                uint32_t domid);
=20
 /**
+ * This function set p2m for broken page
+ * &parm xch a handle to an open hypervisor interface
+ * @parm domid the domain id which broken page belong to
+ * @parm pfn the pfn number of the broken page
+ * @return 0 on success, -1 on failure
+ */
+int xc_set_broken_page_p2m(xc_interface *xch,
+                           uint32_t domid,
+                           unsigned long pfn);
+
+/**
  * This function returns information about the context of a hvm domain
  * @parm xch a handle to an open hypervisor interface
  * @parm domid the domain to get information from
diff -r 090447c780db xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c	Thu Oct 11 05:12:48 2012 +0800
+++ b/xen/arch/x86/domctl.c	Thu Oct 11 05:49:39 2012 +0800
@@ -209,12 +209,18 @@
                 for ( j =3D 0; j < k; j++ )
                 {
                     unsigned long type =3D 0;
+                    p2m_type_t t;
=20
-                    page =3D get_page_from_gfn(d, arr[j], NULL, P2M_ALLOC)=
;
+                    page =3D get_page_from_gfn(d, arr[j], &t, P2M_ALLOC);
=20
                     if ( unlikely(!page) ||
                          unlikely(is_xen_heap_page(page)) )
-                        type =3D XEN_DOMCTL_PFINFO_XTAB;
+                    {
+                        if ( p2m_is_broken(t) )
+                            type =3D XEN_DOMCTL_PFINFO_BROKEN;
+                        else
+                            type =3D XEN_DOMCTL_PFINFO_XTAB;
+                    }
                     else
                     {
                         switch( page->u.inuse.type_info & PGT_type_mask )
@@ -235,6 +241,9 @@
=20
                         if ( page->u.inuse.type_info & PGT_pinned )
                             type |=3D XEN_DOMCTL_PFINFO_LPINTAB;
+
+                        if ( page->count_info & PGC_broken )
+                            type =3D XEN_DOMCTL_PFINFO_BROKEN;
                     }
=20
                     if ( page )
@@ -1609,6 +1618,28 @@
     }
     break;
=20
+    case XEN_DOMCTL_set_broken_page_p2m:
+    {
+        struct domain *d;
+        p2m_type_t pt;
+        unsigned long pfn;
+
+        d =3D rcu_lock_domain_by_id(domctl->domain);
+        if ( d !=3D NULL )
+        {
+            pfn =3D domctl->u.set_broken_page_p2m.pfn;
+
+            get_gfn_query(d, pfn, &pt);
+            p2m_change_type(d, pfn, pt, p2m_ram_broken);
+            put_gfn(d, pfn);
+
+            rcu_unlock_domain(d);
+        }
+        else
+            ret =3D -ESRCH;
+    }
+    break;
+
     default:
         ret =3D iommu_do_domctl(domctl, u_domctl);
         break;
diff -r 090447c780db xen/include/public/domctl.h
--- a/xen/include/public/domctl.h	Thu Oct 11 05:12:48 2012 +0800
+++ b/xen/include/public/domctl.h	Thu Oct 11 05:49:39 2012 +0800
@@ -136,6 +136,7 @@
 #define XEN_DOMCTL_PFINFO_LPINTAB (0x1U<<31)
 #define XEN_DOMCTL_PFINFO_XTAB    (0xfU<<28) /* invalid page */
 #define XEN_DOMCTL_PFINFO_XALLOC  (0xeU<<28) /* allocate-only page */
+#define XEN_DOMCTL_PFINFO_BROKEN  (0xdU<<28) /* broken page */
 #define XEN_DOMCTL_PFINFO_PAGEDTAB (0x8U<<28)
 #define XEN_DOMCTL_PFINFO_LTAB_MASK (0xfU<<28)
=20
@@ -835,6 +836,12 @@
 typedef struct xen_domctl_set_access_required xen_domctl_set_access_requir=
ed_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_access_required_t);
=20
+struct xen_domctl_set_broken_page_p2m {
+    uint64_aligned_t pfn;
+};
+typedef struct xen_domctl_set_broken_page_p2m xen_domctl_set_broken_page_p=
2m_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_broken_page_p2m_t);
+
 struct xen_domctl {
     uint32_t cmd;
 #define XEN_DOMCTL_createdomain                   1
@@ -902,6 +909,7 @@
 #define XEN_DOMCTL_set_virq_handler              66
 #define XEN_DOMCTL_vmce_monitor_start            67
 #define XEN_DOMCTL_vmce_monitor_end              68
+#define XEN_DOMCTL_set_broken_page_p2m           69
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -957,6 +965,7 @@
         struct xen_domctl_audit_p2m         audit_p2m;
         struct xen_domctl_set_virq_handler  set_virq_handler;
         struct xen_domctl_gdbsx_memio       gdbsx_guest_memio;
+        struct xen_domctl_set_broken_page_p2m set_broken_page_p2m;
         struct xen_domctl_gdbsx_pauseunp_vcpu gdbsx_pauseunp_vcpu;
         struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
         uint8_t                             pad[128];=

--_002_DE8DF0795D48FD4CA783C40EC829233534A645SHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="5_vmce_migration_pfntype_broken.patch"
Content-Description: 5_vmce_migration_pfntype_broken.patch
Content-Disposition: attachment;
	filename="5_vmce_migration_pfntype_broken.patch"; size=8521;
	creation-date="Wed, 10 Oct 2012 14:32:13 GMT";
	modification-date="Wed, 10 Oct 2012 21:49:40 GMT"
Content-Transfer-Encoding: base64

WDg2L3ZNQ0U6IGd1ZXN0IGJyb2tlbiBwYWdlIGhhbmRsaW5nIHdoZW4gbWlncmF0aW9uCgpUaGlz
IHBhdGNoIGlzIHVzZWQgdG8gaGFuZGxlIGd1ZXN0IGJyb2tlbiBwYWdlIHdoZW4gbWlncmF0aW9u
LgoKQXQgc2VuZGVyLCB0aGUgYnJva2VuIHBhZ2Ugd291bGQgbm90IGJlIG1hcHBlZCwgYW5kIHRo
ZSBlcnJvciBwYWdlCmNvbnRlbnQgd291bGQgbm90IGJlIGNvcGllZCB0byB0YXJnZXQsIG90aGVy
d2lzZSBpdCBtYXkgdHJpZ2dlciBtb3JlCnNlcmlvdXMgZXJyb3IgKGkuZS4gU1JBUiBlcnJvciku
IFdoaWxlIGl0cyBwZm5fdHlwZSBhbmQgcGZuIG51bWJlcgp3b3VsZCBiZSB0cmFuc2ZlcnJlZCB0
byB0YXJnZXQgc28gdGhhdCB0YXJnZXQgdGFrZSBhcHByb3ByaWF0ZSBhY3Rpb24uCgpBdCB0YXJn
ZXQsIGl0IHdvdWxkIHNldCBwMm0gYXMgcDJtX3JhbV9icm9rZW4gZm9yIGJyb2tlbiBwYWdlLCBz
byB0aGF0CmlmIGd1ZXN0IGFjY2VzcyB0aGUgYnJva2VuIHBhZ2UgYWdhaW4sIGl0IHdvdWxkIGtp
bGwgZ3Vlc3QgYXMgZXhwZWN0ZWQuCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNv
bmcubGl1QGludGVsLmNvbT4KCmRpZmYgLXIgMDkwNDQ3Yzc4MGRiIHRvb2xzL2xpYnhjL3hjX2Rv
bWFpbi5jCi0tLSBhL3Rvb2xzL2xpYnhjL3hjX2RvbWFpbi5jCVRodSBPY3QgMTEgMDU6MTI6NDgg
MjAxMiArMDgwMAorKysgYi90b29scy9saWJ4Yy94Y19kb21haW4uYwlUaHUgT2N0IDExIDA1OjQ5
OjM5IDIwMTIgKzA4MDAKQEAgLTMwNyw2ICszMDcsMjIgQEAKICAgICByZXR1cm4gZG9fZG9tY3Rs
KHhjaCwgJmRvbWN0bCk7CiB9CiAKKy8qIHNldCBicm9rZW4gcGFnZSBwMm0gKi8KK2ludCB4Y19z
ZXRfYnJva2VuX3BhZ2VfcDJtKHhjX2ludGVyZmFjZSAqeGNoLAorICAgICAgICAgICAgICAgICAg
ICAgICAgICAgdWludDMyX3QgZG9taWQsCisgICAgICAgICAgICAgICAgICAgICAgICAgICB1bnNp
Z25lZCBsb25nIHBmbikKK3sKKyAgICBpbnQgcmV0OworICAgIERFQ0xBUkVfRE9NQ1RMOworCisg
ICAgZG9tY3RsLmNtZCA9IFhFTl9ET01DVExfc2V0X2Jyb2tlbl9wYWdlX3AybTsKKyAgICBkb21j
dGwuZG9tYWluID0gKGRvbWlkX3QpZG9taWQ7CisgICAgZG9tY3RsLnUuc2V0X2Jyb2tlbl9wYWdl
X3AybS5wZm4gPSBwZm47CisgICAgcmV0ID0gZG9fZG9tY3RsKHhjaCwgJmRvbWN0bCk7CisKKyAg
ICByZXR1cm4gcmV0ID8gLTEgOiAwOworfQorCiAvKiBnZXQgaW5mbyBmcm9tIGh2bSBndWVzdCBm
b3Igc2F2ZSAqLwogaW50IHhjX2RvbWFpbl9odm1fZ2V0Y29udGV4dCh4Y19pbnRlcmZhY2UgKnhj
aCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZG9taWQsCmRpZmYgLXIg
MDkwNDQ3Yzc4MGRiIHRvb2xzL2xpYnhjL3hjX2RvbWFpbl9yZXN0b3JlLmMKLS0tIGEvdG9vbHMv
bGlieGMveGNfZG9tYWluX3Jlc3RvcmUuYwlUaHUgT2N0IDExIDA1OjEyOjQ4IDIwMTIgKzA4MDAK
KysrIGIvdG9vbHMvbGlieGMveGNfZG9tYWluX3Jlc3RvcmUuYwlUaHUgT2N0IDExIDA1OjQ5OjM5
IDIwMTIgKzA4MDAKQEAgLTk2Miw5ICs5NjIsMTUgQEAKIAogICAgIGNvdW50cGFnZXMgPSBjb3Vu
dDsKICAgICBmb3IgKGkgPSBvbGRjb3VudDsgaSA8IGJ1Zi0+bnJfcGFnZXM7ICsraSkKLSAgICAg
ICAgaWYgKChidWYtPnBmbl90eXBlc1tpXSAmIFhFTl9ET01DVExfUEZJTkZPX0xUQUJfTUFTSykg
PT0gWEVOX0RPTUNUTF9QRklORk9fWFRBQgotICAgICAgICAgICAgfHwoYnVmLT5wZm5fdHlwZXNb
aV0gJiBYRU5fRE9NQ1RMX1BGSU5GT19MVEFCX01BU0spID09IFhFTl9ET01DVExfUEZJTkZPX1hB
TExPQykKKyAgICB7CisgICAgICAgIHVuc2lnbmVkIGxvbmcgcGFnZXR5cGU7CisKKyAgICAgICAg
cGFnZXR5cGUgPSBidWYtPnBmbl90eXBlc1tpXSAmIFhFTl9ET01DVExfUEZJTkZPX0xUQUJfTUFT
SzsKKyAgICAgICAgaWYgKCBwYWdldHlwZSA9PSBYRU5fRE9NQ1RMX1BGSU5GT19YVEFCIHx8Cisg
ICAgICAgICAgICAgcGFnZXR5cGUgPT0gWEVOX0RPTUNUTF9QRklORk9fQlJPS0VOIHx8CisgICAg
ICAgICAgICAgcGFnZXR5cGUgPT0gWEVOX0RPTUNUTF9QRklORk9fWEFMTE9DICkKICAgICAgICAg
ICAgIC0tY291bnRwYWdlczsKKyAgICB9CiAKICAgICBpZiAoIWNvdW50cGFnZXMpCiAgICAgICAg
IHJldHVybiBjb3VudDsKQEAgLTEyMDAsNiArMTIwNiwxNyBAQAogICAgICAgICAgICAgLyogYSBi
b2d1cy91bm1hcHBlZC9hbGxvY2F0ZS1vbmx5IHBhZ2U6IHNraXAgaXQgKi8KICAgICAgICAgICAg
IGNvbnRpbnVlOwogCisgICAgICAgIGlmICggcGFnZXR5cGUgPT0gWEVOX0RPTUNUTF9QRklORk9f
QlJPS0VOICkKKyAgICAgICAgeworICAgICAgICAgICAgaWYgKCB4Y19zZXRfYnJva2VuX3BhZ2Vf
cDJtKHhjaCwgZG9tLCBwZm4pICkKKyAgICAgICAgICAgIHsKKyAgICAgICAgICAgICAgICBFUlJP
UigiU2V0IHAybSBmb3IgYnJva2VuIHBhZ2UgZmFpbGVkLCAiCisgICAgICAgICAgICAgICAgICAg
ICAgImRvbT0lZCwgcGZuPSVseFxuIiwgZG9tLCBwZm4pOworICAgICAgICAgICAgICAgIGdvdG8g
ZXJyX21hcHBlZDsKKyAgICAgICAgICAgIH0KKyAgICAgICAgICAgIGNvbnRpbnVlOworICAgICAg
ICB9CisKICAgICAgICAgaWYgKHBmbl9lcnJbaV0pCiAgICAgICAgIHsKICAgICAgICAgICAgIEVS
Uk9SKCJ1bmV4cGVjdGVkIFBGTiBtYXBwaW5nIGZhaWx1cmUgcGZuICVseCBtYXBfbWZuICVseCBw
Mm1fbWZuICVseCIsCmRpZmYgLXIgMDkwNDQ3Yzc4MGRiIHRvb2xzL2xpYnhjL3hjX2RvbWFpbl9z
YXZlLmMKLS0tIGEvdG9vbHMvbGlieGMveGNfZG9tYWluX3NhdmUuYwlUaHUgT2N0IDExIDA1OjEy
OjQ4IDIwMTIgKzA4MDAKKysrIGIvdG9vbHMvbGlieGMveGNfZG9tYWluX3NhdmUuYwlUaHUgT2N0
IDExIDA1OjQ5OjM5IDIwMTIgKzA4MDAKQEAgLTEyODUsNiArMTI4NSwxMyBAQAogICAgICAgICAg
ICAgICAgIGlmICggIWh2bSApCiAgICAgICAgICAgICAgICAgICAgIGdtZm4gPSBwZm5fdG9fbWZu
KGdtZm4pOwogCisgICAgICAgICAgICAgICAgaWYgKCBwZm5fdHlwZVtqXSA9PSBYRU5fRE9NQ1RM
X1BGSU5GT19CUk9LRU4gKQorICAgICAgICAgICAgICAgIHsKKyAgICAgICAgICAgICAgICAgICAg
cGZuX3R5cGVbal0gfD0gcGZuX2JhdGNoW2pdOworICAgICAgICAgICAgICAgICAgICArK3J1bjsK
KyAgICAgICAgICAgICAgICAgICAgY29udGludWU7CisgICAgICAgICAgICAgICAgfQorCiAgICAg
ICAgICAgICAgICAgaWYgKCBwZm5fZXJyW2pdICkKICAgICAgICAgICAgICAgICB7CiAgICAgICAg
ICAgICAgICAgICAgIGlmICggcGZuX3R5cGVbal0gPT0gWEVOX0RPTUNUTF9QRklORk9fWFRBQiAp
CkBAIC0xMzc5LDggKzEzODYsMTIgQEAKICAgICAgICAgICAgICAgICAgICAgfQogICAgICAgICAg
ICAgICAgIH0KIAotICAgICAgICAgICAgICAgIC8qIHNraXAgcGFnZXMgdGhhdCBhcmVuJ3QgcHJl
c2VudCBvciBhcmUgYWxsb2Mtb25seSAqLworICAgICAgICAgICAgICAgIC8qCisgICAgICAgICAg
ICAgICAgICogc2tpcCBwYWdlcyB0aGF0IGFyZW4ndCBwcmVzZW50LAorICAgICAgICAgICAgICAg
ICAqIG9yIGFyZSBicm9rZW4sIG9yIGFyZSBhbGxvYy1vbmx5CisgICAgICAgICAgICAgICAgICov
CiAgICAgICAgICAgICAgICAgaWYgKCBwYWdldHlwZSA9PSBYRU5fRE9NQ1RMX1BGSU5GT19YVEFC
CisgICAgICAgICAgICAgICAgICAgIHx8IHBhZ2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX0JS
T0tFTgogICAgICAgICAgICAgICAgICAgICB8fCBwYWdldHlwZSA9PSBYRU5fRE9NQ1RMX1BGSU5G
T19YQUxMT0MgKQogICAgICAgICAgICAgICAgICAgICBjb250aW51ZTsKIApkaWZmIC1yIDA5MDQ0
N2M3ODBkYiB0b29scy9saWJ4Yy94ZW5jdHJsLmgKLS0tIGEvdG9vbHMvbGlieGMveGVuY3RybC5o
CVRodSBPY3QgMTEgMDU6MTI6NDggMjAxMiArMDgwMAorKysgYi90b29scy9saWJ4Yy94ZW5jdHJs
LmgJVGh1IE9jdCAxMSAwNTo0OTozOSAyMDEyICswODAwCkBAIC01OTUsNiArNTk1LDE3IEBACiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZG9taWQpOwogCiAvKioKKyAq
IFRoaXMgZnVuY3Rpb24gc2V0IHAybSBmb3IgYnJva2VuIHBhZ2UKKyAqICZwYXJtIHhjaCBhIGhh
bmRsZSB0byBhbiBvcGVuIGh5cGVydmlzb3IgaW50ZXJmYWNlCisgKiBAcGFybSBkb21pZCB0aGUg
ZG9tYWluIGlkIHdoaWNoIGJyb2tlbiBwYWdlIGJlbG9uZyB0bworICogQHBhcm0gcGZuIHRoZSBw
Zm4gbnVtYmVyIG9mIHRoZSBicm9rZW4gcGFnZQorICogQHJldHVybiAwIG9uIHN1Y2Nlc3MsIC0x
IG9uIGZhaWx1cmUKKyAqLworaW50IHhjX3NldF9icm9rZW5fcGFnZV9wMm0oeGNfaW50ZXJmYWNl
ICp4Y2gsCisgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJfdCBkb21pZCwKKyAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHVuc2lnbmVkIGxvbmcgcGZuKTsKKworLyoqCiAgKiBUaGlz
IGZ1bmN0aW9uIHJldHVybnMgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGNvbnRleHQgb2YgYSBodm0g
ZG9tYWluCiAgKiBAcGFybSB4Y2ggYSBoYW5kbGUgdG8gYW4gb3BlbiBoeXBlcnZpc29yIGludGVy
ZmFjZQogICogQHBhcm0gZG9taWQgdGhlIGRvbWFpbiB0byBnZXQgaW5mb3JtYXRpb24gZnJvbQpk
aWZmIC1yIDA5MDQ0N2M3ODBkYiB4ZW4vYXJjaC94ODYvZG9tY3RsLmMKLS0tIGEveGVuL2FyY2gv
eDg2L2RvbWN0bC5jCVRodSBPY3QgMTEgMDU6MTI6NDggMjAxMiArMDgwMAorKysgYi94ZW4vYXJj
aC94ODYvZG9tY3RsLmMJVGh1IE9jdCAxMSAwNTo0OTozOSAyMDEyICswODAwCkBAIC0yMDksMTIg
KzIwOSwxOCBAQAogICAgICAgICAgICAgICAgIGZvciAoIGogPSAwOyBqIDwgazsgaisrICkKICAg
ICAgICAgICAgICAgICB7CiAgICAgICAgICAgICAgICAgICAgIHVuc2lnbmVkIGxvbmcgdHlwZSA9
IDA7CisgICAgICAgICAgICAgICAgICAgIHAybV90eXBlX3QgdDsKIAotICAgICAgICAgICAgICAg
ICAgICBwYWdlID0gZ2V0X3BhZ2VfZnJvbV9nZm4oZCwgYXJyW2pdLCBOVUxMLCBQMk1fQUxMT0Mp
OworICAgICAgICAgICAgICAgICAgICBwYWdlID0gZ2V0X3BhZ2VfZnJvbV9nZm4oZCwgYXJyW2pd
LCAmdCwgUDJNX0FMTE9DKTsKIAogICAgICAgICAgICAgICAgICAgICBpZiAoIHVubGlrZWx5KCFw
YWdlKSB8fAogICAgICAgICAgICAgICAgICAgICAgICAgIHVubGlrZWx5KGlzX3hlbl9oZWFwX3Bh
Z2UocGFnZSkpICkKLSAgICAgICAgICAgICAgICAgICAgICAgIHR5cGUgPSBYRU5fRE9NQ1RMX1BG
SU5GT19YVEFCOworICAgICAgICAgICAgICAgICAgICB7CisgICAgICAgICAgICAgICAgICAgICAg
ICBpZiAoIHAybV9pc19icm9rZW4odCkgKQorICAgICAgICAgICAgICAgICAgICAgICAgICAgIHR5
cGUgPSBYRU5fRE9NQ1RMX1BGSU5GT19CUk9LRU47CisgICAgICAgICAgICAgICAgICAgICAgICBl
bHNlCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgdHlwZSA9IFhFTl9ET01DVExfUEZJTkZP
X1hUQUI7CisgICAgICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgICAgICAgICAgZWxzZQog
ICAgICAgICAgICAgICAgICAgICB7CiAgICAgICAgICAgICAgICAgICAgICAgICBzd2l0Y2goIHBh
Z2UtPnUuaW51c2UudHlwZV9pbmZvICYgUEdUX3R5cGVfbWFzayApCkBAIC0yMzUsNiArMjQxLDkg
QEAKIAogICAgICAgICAgICAgICAgICAgICAgICAgaWYgKCBwYWdlLT51LmludXNlLnR5cGVfaW5m
byAmIFBHVF9waW5uZWQgKQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIHR5cGUgfD0gWEVO
X0RPTUNUTF9QRklORk9fTFBJTlRBQjsKKworICAgICAgICAgICAgICAgICAgICAgICAgaWYgKCBw
YWdlLT5jb3VudF9pbmZvICYgUEdDX2Jyb2tlbiApCisgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgdHlwZSA9IFhFTl9ET01DVExfUEZJTkZPX0JST0tFTjsKICAgICAgICAgICAgICAgICAgICAg
fQogCiAgICAgICAgICAgICAgICAgICAgIGlmICggcGFnZSApCkBAIC0xNjA5LDYgKzE2MTgsMjgg
QEAKICAgICB9CiAgICAgYnJlYWs7CiAKKyAgICBjYXNlIFhFTl9ET01DVExfc2V0X2Jyb2tlbl9w
YWdlX3AybToKKyAgICB7CisgICAgICAgIHN0cnVjdCBkb21haW4gKmQ7CisgICAgICAgIHAybV90
eXBlX3QgcHQ7CisgICAgICAgIHVuc2lnbmVkIGxvbmcgcGZuOworCisgICAgICAgIGQgPSByY3Vf
bG9ja19kb21haW5fYnlfaWQoZG9tY3RsLT5kb21haW4pOworICAgICAgICBpZiAoIGQgIT0gTlVM
TCApCisgICAgICAgIHsKKyAgICAgICAgICAgIHBmbiA9IGRvbWN0bC0+dS5zZXRfYnJva2VuX3Bh
Z2VfcDJtLnBmbjsKKworICAgICAgICAgICAgZ2V0X2dmbl9xdWVyeShkLCBwZm4sICZwdCk7Cisg
ICAgICAgICAgICBwMm1fY2hhbmdlX3R5cGUoZCwgcGZuLCBwdCwgcDJtX3JhbV9icm9rZW4pOwor
ICAgICAgICAgICAgcHV0X2dmbihkLCBwZm4pOworCisgICAgICAgICAgICByY3VfdW5sb2NrX2Rv
bWFpbihkKTsKKyAgICAgICAgfQorICAgICAgICBlbHNlCisgICAgICAgICAgICByZXQgPSAtRVNS
Q0g7CisgICAgfQorICAgIGJyZWFrOworCiAgICAgZGVmYXVsdDoKICAgICAgICAgcmV0ID0gaW9t
bXVfZG9fZG9tY3RsKGRvbWN0bCwgdV9kb21jdGwpOwogICAgICAgICBicmVhazsKZGlmZiAtciAw
OTA0NDdjNzgwZGIgeGVuL2luY2x1ZGUvcHVibGljL2RvbWN0bC5oCi0tLSBhL3hlbi9pbmNsdWRl
L3B1YmxpYy9kb21jdGwuaAlUaHUgT2N0IDExIDA1OjEyOjQ4IDIwMTIgKzA4MDAKKysrIGIveGVu
L2luY2x1ZGUvcHVibGljL2RvbWN0bC5oCVRodSBPY3QgMTEgMDU6NDk6MzkgMjAxMiArMDgwMApA
QCAtMTM2LDYgKzEzNiw3IEBACiAjZGVmaW5lIFhFTl9ET01DVExfUEZJTkZPX0xQSU5UQUIgKDB4
MVU8PDMxKQogI2RlZmluZSBYRU5fRE9NQ1RMX1BGSU5GT19YVEFCICAgICgweGZVPDwyOCkgLyog
aW52YWxpZCBwYWdlICovCiAjZGVmaW5lIFhFTl9ET01DVExfUEZJTkZPX1hBTExPQyAgKDB4ZVU8
PDI4KSAvKiBhbGxvY2F0ZS1vbmx5IHBhZ2UgKi8KKyNkZWZpbmUgWEVOX0RPTUNUTF9QRklORk9f
QlJPS0VOICAoMHhkVTw8MjgpIC8qIGJyb2tlbiBwYWdlICovCiAjZGVmaW5lIFhFTl9ET01DVExf
UEZJTkZPX1BBR0VEVEFCICgweDhVPDwyOCkKICNkZWZpbmUgWEVOX0RPTUNUTF9QRklORk9fTFRB
Ql9NQVNLICgweGZVPDwyOCkKIApAQCAtODM1LDYgKzgzNiwxMiBAQAogdHlwZWRlZiBzdHJ1Y3Qg
eGVuX2RvbWN0bF9zZXRfYWNjZXNzX3JlcXVpcmVkIHhlbl9kb21jdGxfc2V0X2FjY2Vzc19yZXF1
aXJlZF90OwogREVGSU5FX1hFTl9HVUVTVF9IQU5ETEUoeGVuX2RvbWN0bF9zZXRfYWNjZXNzX3Jl
cXVpcmVkX3QpOwogCitzdHJ1Y3QgeGVuX2RvbWN0bF9zZXRfYnJva2VuX3BhZ2VfcDJtIHsKKyAg
ICB1aW50NjRfYWxpZ25lZF90IHBmbjsKK307Cit0eXBlZGVmIHN0cnVjdCB4ZW5fZG9tY3RsX3Nl
dF9icm9rZW5fcGFnZV9wMm0geGVuX2RvbWN0bF9zZXRfYnJva2VuX3BhZ2VfcDJtX3Q7CitERUZJ
TkVfWEVOX0dVRVNUX0hBTkRMRSh4ZW5fZG9tY3RsX3NldF9icm9rZW5fcGFnZV9wMm1fdCk7CisK
IHN0cnVjdCB4ZW5fZG9tY3RsIHsKICAgICB1aW50MzJfdCBjbWQ7CiAjZGVmaW5lIFhFTl9ET01D
VExfY3JlYXRlZG9tYWluICAgICAgICAgICAgICAgICAgIDEKQEAgLTkwMiw2ICs5MDksNyBAQAog
I2RlZmluZSBYRU5fRE9NQ1RMX3NldF92aXJxX2hhbmRsZXIgICAgICAgICAgICAgIDY2CiAjZGVm
aW5lIFhFTl9ET01DVExfdm1jZV9tb25pdG9yX3N0YXJ0ICAgICAgICAgICAgNjcKICNkZWZpbmUg
WEVOX0RPTUNUTF92bWNlX21vbml0b3JfZW5kICAgICAgICAgICAgICA2OAorI2RlZmluZSBYRU5f
RE9NQ1RMX3NldF9icm9rZW5fcGFnZV9wMm0gICAgICAgICAgIDY5CiAjZGVmaW5lIFhFTl9ET01D
VExfZ2Ric3hfZ3Vlc3RtZW1pbyAgICAgICAgICAgIDEwMDAKICNkZWZpbmUgWEVOX0RPTUNUTF9n
ZGJzeF9wYXVzZXZjcHUgICAgICAgICAgICAgMTAwMQogI2RlZmluZSBYRU5fRE9NQ1RMX2dkYnN4
X3VucGF1c2V2Y3B1ICAgICAgICAgICAxMDAyCkBAIC05NTcsNiArOTY1LDcgQEAKICAgICAgICAg
c3RydWN0IHhlbl9kb21jdGxfYXVkaXRfcDJtICAgICAgICAgYXVkaXRfcDJtOwogICAgICAgICBz
dHJ1Y3QgeGVuX2RvbWN0bF9zZXRfdmlycV9oYW5kbGVyICBzZXRfdmlycV9oYW5kbGVyOwogICAg
ICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF9nZGJzeF9tZW1pbyAgICAgICBnZGJzeF9ndWVzdF9tZW1p
bzsKKyAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfc2V0X2Jyb2tlbl9wYWdlX3AybSBzZXRfYnJv
a2VuX3BhZ2VfcDJtOwogICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF9nZGJzeF9wYXVzZXVucF92
Y3B1IGdkYnN4X3BhdXNldW5wX3ZjcHU7CiAgICAgICAgIHN0cnVjdCB4ZW5fZG9tY3RsX2dkYnN4
X2RvbXN0YXR1cyAgIGdkYnN4X2RvbXN0YXR1czsKICAgICAgICAgdWludDhfdCAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgcGFkWzEyOF07Cg==

--_002_DE8DF0795D48FD4CA783C40EC829233534A645SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC829233534A645SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Wed Oct 10 14:50:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 14:50:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLxbl-0000hf-2Q; Wed, 10 Oct 2012 14:50:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLxbj-0000hT-Tb
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 14:50:00 +0000
Received: from [85.158.138.51:55528] by server-11.bemta-3.messagelabs.com id
	70/33-24008-71B85705; Wed, 10 Oct 2012 14:49:59 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-9.tower-174.messagelabs.com!1349880598!32164364!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30138 invoked from network); 10 Oct 2012 14:49:58 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-9.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Oct 2012 14:49:58 -0000
Received: from 50-66-ftth.onsneteindhoven.nl ([88.159.66.50]:58738
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TLxd0-0007nD-9M; Wed, 10 Oct 2012 16:51:18 +0200
Date: Wed, 10 Oct 2012 16:49:49 +0200
From: Sander Eikelenboom 
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <748966751.20121010164949@eikelenboom.it>
To: Ian Campbell 
In-Reply-To: <1349874598.10070.39.camel@zakaz.uk.xensource.com>
References: <1349790467.21847.185.camel@zakaz.uk.xensource.com>
	<1349790863.21172.4406.camel@edumazet-glaptop>
	<1349792241.21847.199.camel@zakaz.uk.xensource.com>
	<1349792847.21172.4479.camel@edumazet-glaptop>
	<1349793630.21847.208.camel@zakaz.uk.xensource.com>
	<1349863984.10070.26.camel@zakaz.uk.xensource.com>
	<1349874598.10070.39.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" ,
	Eric Dumazet ,
	Konrad Rzeszutek Wilk ,
	Eric Dumazet , xen-devel 
Subject: Re: [Xen-devel] compound skb frag pages appearing in start_xmit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Wednesday, October 10, 2012, 3:09:58 PM, you wrote:

> On Wed, 2012-10-10 at 11:13 +0100, Ian Campbell wrote:
>> I haven't tackled netfront yet. 

> I seem to be totally unable to reproduce the equivalent issue on the
> netfront xmit side, even though it seems like the loop in
> xennet_make_frags ought to be obviously susceptible to it.

> Konrad, Sander, are either of you able to repro, e.g. with:


Hmrrrmm i don't see any traces, only strange behaviour ..

- i can connect to guests by ssh, but it's sluggish, and sometimes stops working
- The guest seem to keep trying to connect to netback:

[  658.276719] xen_bridge: port 2(vif40.0) entered forwarding state
[  658.282258] xen_bridge: port 2(vif40.0) entered forwarding state
[  663.945964] xen_bridge: port 7(vif39.0) entered forwarding state
[  669.674277] xen_bridge: port 2(vif40.0) entered disabled state
[  669.680290] device vif40.0 left promiscuous mode
[  669.685464] xen_bridge: port 2(vif40.0) entered disabled state
[  672.857222] device vif41.0 entered promiscuous mode
[  673.166254] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
[  673.176368] xen_bridge: port 2(vif41.0) entered forwarding state
[  673.182042] xen_bridge: port 2(vif41.0) entered forwarding state
[  674.439725] xen_bridge: port 7(vif39.0) entered disabled state
[  674.445708] device vif39.0 left promiscuous mode
[  674.450955] xen_bridge: port 7(vif39.0) entered disabled state
[  677.726040] device vif42.0 entered promiscuous mode
[  678.053381] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
[  678.062804] xen_bridge: port 7(vif42.0) entered forwarding state
[  678.068433] xen_bridge: port 7(vif42.0) entered forwarding state
[  688.224736] xen_bridge: port 2(vif41.0) entered forwarding state
[  693.080557] xen_bridge: port 7(vif42.0) entered forwarding state
[  700.786276] xen_bridge: port 7(vif42.0) entered disabled state
[  700.792484] device vif42.0 left promiscuous mode
[  700.802409] xen_bridge: port 7(vif42.0) entered disabled state
[  704.133606] device vif43.0 entered promiscuous mode
[  704.460160] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
[  704.469800] xen_bridge: port 7(vif43.0) entered forwarding state
[  704.475303] xen_bridge: port 7(vif43.0) entered forwarding state
[  719.493788] xen_bridge: port 7(vif43.0) entered forwarding state
[  726.302456] xen_bridge: port 7(vif43.0) entered disabled state
[  726.308898] device vif43.0 left promiscuous mode
[  726.314029] xen_bridge: port 7(vif43.0) entered disabled state

All the guests are already up, but this keeps on going and going and going ....



> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> index b06ef81..8a3f770 100644
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -462,6 +462,8 @@ static void xennet_make_frags(struct sk_buff *skb, struct net_device *dev,
>                 ref = gnttab_claim_grant_reference(&np->gref_tx_head);
>                 BUG_ON((signed short)ref < 0);
>  
> +               BUG_ON(PageCompound(skb_frag_page(frag)));
> +
>                 mfn = pfn_to_mfn(page_to_pfn(skb_frag_page(frag)));
>                 gnttab_grant_foreign_access_ref(ref, np->xbdev->otherend_id,
>                                                 mfn, GNTMAP_readonly);

> My repro for netback was just to netcat a wodge of data from dom0->domU
> but going the other way doesn't seem to trigger.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 14:50:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 14:50:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLxbl-0000hf-2Q; Wed, 10 Oct 2012 14:50:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLxbj-0000hT-Tb
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 14:50:00 +0000
Received: from [85.158.138.51:55528] by server-11.bemta-3.messagelabs.com id
	70/33-24008-71B85705; Wed, 10 Oct 2012 14:49:59 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-9.tower-174.messagelabs.com!1349880598!32164364!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30138 invoked from network); 10 Oct 2012 14:49:58 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-9.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Oct 2012 14:49:58 -0000
Received: from 50-66-ftth.onsneteindhoven.nl ([88.159.66.50]:58738
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TLxd0-0007nD-9M; Wed, 10 Oct 2012 16:51:18 +0200
Date: Wed, 10 Oct 2012 16:49:49 +0200
From: Sander Eikelenboom 
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <748966751.20121010164949@eikelenboom.it>
To: Ian Campbell 
In-Reply-To: <1349874598.10070.39.camel@zakaz.uk.xensource.com>
References: <1349790467.21847.185.camel@zakaz.uk.xensource.com>
	<1349790863.21172.4406.camel@edumazet-glaptop>
	<1349792241.21847.199.camel@zakaz.uk.xensource.com>
	<1349792847.21172.4479.camel@edumazet-glaptop>
	<1349793630.21847.208.camel@zakaz.uk.xensource.com>
	<1349863984.10070.26.camel@zakaz.uk.xensource.com>
	<1349874598.10070.39.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" ,
	Eric Dumazet ,
	Konrad Rzeszutek Wilk ,
	Eric Dumazet , xen-devel 
Subject: Re: [Xen-devel] compound skb frag pages appearing in start_xmit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Wednesday, October 10, 2012, 3:09:58 PM, you wrote:

> On Wed, 2012-10-10 at 11:13 +0100, Ian Campbell wrote:
>> I haven't tackled netfront yet. 

> I seem to be totally unable to reproduce the equivalent issue on the
> netfront xmit side, even though it seems like the loop in
> xennet_make_frags ought to be obviously susceptible to it.

> Konrad, Sander, are either of you able to repro, e.g. with:


Hmrrrmm i don't see any traces, only strange behaviour ..

- i can connect to guests by ssh, but it's sluggish, and sometimes stops working
- The guest seem to keep trying to connect to netback:

[  658.276719] xen_bridge: port 2(vif40.0) entered forwarding state
[  658.282258] xen_bridge: port 2(vif40.0) entered forwarding state
[  663.945964] xen_bridge: port 7(vif39.0) entered forwarding state
[  669.674277] xen_bridge: port 2(vif40.0) entered disabled state
[  669.680290] device vif40.0 left promiscuous mode
[  669.685464] xen_bridge: port 2(vif40.0) entered disabled state
[  672.857222] device vif41.0 entered promiscuous mode
[  673.166254] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
[  673.176368] xen_bridge: port 2(vif41.0) entered forwarding state
[  673.182042] xen_bridge: port 2(vif41.0) entered forwarding state
[  674.439725] xen_bridge: port 7(vif39.0) entered disabled state
[  674.445708] device vif39.0 left promiscuous mode
[  674.450955] xen_bridge: port 7(vif39.0) entered disabled state
[  677.726040] device vif42.0 entered promiscuous mode
[  678.053381] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
[  678.062804] xen_bridge: port 7(vif42.0) entered forwarding state
[  678.068433] xen_bridge: port 7(vif42.0) entered forwarding state
[  688.224736] xen_bridge: port 2(vif41.0) entered forwarding state
[  693.080557] xen_bridge: port 7(vif42.0) entered forwarding state
[  700.786276] xen_bridge: port 7(vif42.0) entered disabled state
[  700.792484] device vif42.0 left promiscuous mode
[  700.802409] xen_bridge: port 7(vif42.0) entered disabled state
[  704.133606] device vif43.0 entered promiscuous mode
[  704.460160] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
[  704.469800] xen_bridge: port 7(vif43.0) entered forwarding state
[  704.475303] xen_bridge: port 7(vif43.0) entered forwarding state
[  719.493788] xen_bridge: port 7(vif43.0) entered forwarding state
[  726.302456] xen_bridge: port 7(vif43.0) entered disabled state
[  726.308898] device vif43.0 left promiscuous mode
[  726.314029] xen_bridge: port 7(vif43.0) entered disabled state

All the guests are already up, but this keeps on going and going and going ....



> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> index b06ef81..8a3f770 100644
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -462,6 +462,8 @@ static void xennet_make_frags(struct sk_buff *skb, struct net_device *dev,
>                 ref = gnttab_claim_grant_reference(&np->gref_tx_head);
>                 BUG_ON((signed short)ref < 0);
>  
> +               BUG_ON(PageCompound(skb_frag_page(frag)));
> +
>                 mfn = pfn_to_mfn(page_to_pfn(skb_frag_page(frag)));
>                 gnttab_grant_foreign_access_ref(ref, np->xbdev->otherend_id,
>                                                 mfn, GNTMAP_readonly);

> My repro for netback was just to netcat a wodge of data from dom0->domU
> but going the other way doesn't seem to trigger.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 14:52:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 14:52:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLxdq-0000w5-CS; Wed, 10 Oct 2012 14:52:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLxdo-0000vt-GV
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 14:52:08 +0000
Received: from [85.158.143.35:29143] by server-1.bemta-4.messagelabs.com id
	06/C9-19551-79B85705; Wed, 10 Oct 2012 14:52:07 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1349880724!14474145!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM3MzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16643 invoked from network); 10 Oct 2012 14:52:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 14:52:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="15078333"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 14:52:03 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 10 Oct 2012 15:52:04 +0100
Date: Wed, 10 Oct 2012 15:51:47 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1349855585.6952.73.camel@dagon.hellion.org.uk>
Message-ID: 
References: <1349796183-30648-1-git-send-email-arnd@arndb.de>
	<1349796183-30648-6-git-send-email-arnd@arndb.de>
	<1349796958.21847.219.camel@zakaz.uk.xensource.com>
	<34a52050-5de8-4a4d-91b5-a0a8d5a41710@default>
	<1349855585.6952.73.camel@dagon.hellion.org.uk>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	Dan Magenheimer ,
	Konrad Wilk ,
	Jeremy Fitzhardinge ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 10 Oct 2012, Ian Campbell wrote:
> On Tue, 2012-10-09 at 20:24 +0100, Dan Magenheimer wrote:
> > > From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> > > Sent: Tuesday, October 09, 2012 9:36 AM
> > > To: Arnd Bergmann
> > > Cc: Jeremy Fitzhardinge; xen-devel@lists.xensource.com; Stefano Stabellini; Konrad Rzeszutek Wilk;
> > > linux-kernel@vger.kernel.org; Russell King; linux-arm-kernel@lists.infradead.org
> > > Subject: Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
> > > 
> > > On Tue, 2012-10-09 at 16:22 +0100, Arnd Bergmann wrote:
> > > > * The XEN_BALLOON code requires the balloon infrastructure that is not
> > > >   getting built on ARM.
> > > 
> > > I've got patches to enable this, but not for 3.7 so this looks good for
> > > now.
> > > 
> > > > * The tmem hypercall is not available on ARM
> > 
> > [reduced cc list to just us Xen chickens]
> > 
> > Any reason that the tmem hypercall is not available on ARM?
> > At a minimum, it should be available, but always return failure.
> 
> The hypercall is available from a hypervisor point of view, although it
> will return -Esomething since some of the required arch functions are
> still stubs.

We are probably just missing the implementation of HYPERVISOR_tmem_op.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 14:52:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 14:52:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLxdq-0000w5-CS; Wed, 10 Oct 2012 14:52:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLxdo-0000vt-GV
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 14:52:08 +0000
Received: from [85.158.143.35:29143] by server-1.bemta-4.messagelabs.com id
	06/C9-19551-79B85705; Wed, 10 Oct 2012 14:52:07 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1349880724!14474145!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM3MzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16643 invoked from network); 10 Oct 2012 14:52:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 14:52:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="15078333"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 14:52:03 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 10 Oct 2012 15:52:04 +0100
Date: Wed, 10 Oct 2012 15:51:47 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1349855585.6952.73.camel@dagon.hellion.org.uk>
Message-ID: 
References: <1349796183-30648-1-git-send-email-arnd@arndb.de>
	<1349796183-30648-6-git-send-email-arnd@arndb.de>
	<1349796958.21847.219.camel@zakaz.uk.xensource.com>
	<34a52050-5de8-4a4d-91b5-a0a8d5a41710@default>
	<1349855585.6952.73.camel@dagon.hellion.org.uk>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	Dan Magenheimer ,
	Konrad Wilk ,
	Jeremy Fitzhardinge ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 10 Oct 2012, Ian Campbell wrote:
> On Tue, 2012-10-09 at 20:24 +0100, Dan Magenheimer wrote:
> > > From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> > > Sent: Tuesday, October 09, 2012 9:36 AM
> > > To: Arnd Bergmann
> > > Cc: Jeremy Fitzhardinge; xen-devel@lists.xensource.com; Stefano Stabellini; Konrad Rzeszutek Wilk;
> > > linux-kernel@vger.kernel.org; Russell King; linux-arm-kernel@lists.infradead.org
> > > Subject: Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
> > > 
> > > On Tue, 2012-10-09 at 16:22 +0100, Arnd Bergmann wrote:
> > > > * The XEN_BALLOON code requires the balloon infrastructure that is not
> > > >   getting built on ARM.
> > > 
> > > I've got patches to enable this, but not for 3.7 so this looks good for
> > > now.
> > > 
> > > > * The tmem hypercall is not available on ARM
> > 
> > [reduced cc list to just us Xen chickens]
> > 
> > Any reason that the tmem hypercall is not available on ARM?
> > At a minimum, it should be available, but always return failure.
> 
> The hypercall is available from a hypervisor point of view, although it
> will return -Esomething since some of the required arch functions are
> still stubs.

We are probably just missing the implementation of HYPERVISOR_tmem_op.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 14:54:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 14:54:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLxfw-00016Q-Su; Wed, 10 Oct 2012 14:54:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLxfu-00016H-MV
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 14:54:20 +0000
Received: from [85.158.143.99:38849] by server-3.bemta-4.messagelabs.com id
	4A/95-10075-A1C85705; Wed, 10 Oct 2012 14:54:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1349880828!23993638!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM3MzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23117 invoked from network); 10 Oct 2012 14:53:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 14:53:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="15078373"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 14:53:48 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 10 Oct 2012 15:53:48 +0100
Message-ID: <1349880826.10070.41.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Wed, 10 Oct 2012 15:53:46 +0100
In-Reply-To: 
References: <1349796183-30648-1-git-send-email-arnd@arndb.de>
	<1349796183-30648-6-git-send-email-arnd@arndb.de>
	
	<201210091821.27818.arnd@arndb.de>
	<1349855687.6952.75.camel@dagon.hellion.org.uk>
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge ,
	"xen-devel@lists.xensource.com" ,
	Arnd Bergmann , Konrad
	Rzeszutek Wilk ,
	"linux-kernel@vger.kernel.org" ,
	Russell King ,
	"linux-arm-kernel@lists.infradead.org"
	
Subject: Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-10 at 15:47 +0100, Stefano Stabellini wrote:
> On Wed, 10 Oct 2012, Ian Campbell wrote:
> > On Tue, 2012-10-09 at 19:21 +0100, Arnd Bergmann wrote:
> > > On Tuesday 09 October 2012, Stefano Stabellini wrote:
> > > > >  config XEN
> > > > >       bool "Xen guest support on ARM (EXPERIMENTAL)"
> > > > >       depends on EXPERIMENTAL && ARM && OF
> > > > > +     depends on !CPU_V6
> > > > >       help
> > > > >         Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
> > > > 
> > > > Considering that we rely on the virtualization extensions, this one can
> > > > be:
> > > > 
> > > >     depends on CPU_V7
> > > > 
> > > > The rest looks fine. I can submit a second patch to change !CPU_V6 into
> > > > CPU_V7 later, if you prefer.
> > > 
> > > CPU_V6 and CPU_V7 are not exclusive, I saw the problem when building a
> > > combined kernel for both V6 and V7. The code also needs to depend on ARMv7
> > > with virtualization extensions, but that is a different issue. We don't
> > > actually have a configuration symbol for that yet, as far as I can tell.
> > 
> > I don't think the guest kernels (including dom0) need the extensions to
> > run under Xen, they are only need by Xen itself. The guests should just
> > see a relatively normal v7 processor. 
> > 
> > Stefano, does that sound right?
> 
> Keep in mind that we are using HVC to issue hypercalls, and HVC has been
> introduced with the virtualization extensions, if I am not mistaken.

I think we can ignore that in this context since it is only used by bits
which are already virtualisation aware -- i.e. you wouldn't want to add
it to the Kconfig as a dependency for Xen.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 14:54:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 14:54:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLxfw-00016Q-Su; Wed, 10 Oct 2012 14:54:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLxfu-00016H-MV
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 14:54:20 +0000
Received: from [85.158.143.99:38849] by server-3.bemta-4.messagelabs.com id
	4A/95-10075-A1C85705; Wed, 10 Oct 2012 14:54:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1349880828!23993638!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM3MzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23117 invoked from network); 10 Oct 2012 14:53:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 14:53:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="15078373"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 14:53:48 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 10 Oct 2012 15:53:48 +0100
Message-ID: <1349880826.10070.41.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Wed, 10 Oct 2012 15:53:46 +0100
In-Reply-To: 
References: <1349796183-30648-1-git-send-email-arnd@arndb.de>
	<1349796183-30648-6-git-send-email-arnd@arndb.de>
	
	<201210091821.27818.arnd@arndb.de>
	<1349855687.6952.75.camel@dagon.hellion.org.uk>
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge ,
	"xen-devel@lists.xensource.com" ,
	Arnd Bergmann , Konrad
	Rzeszutek Wilk ,
	"linux-kernel@vger.kernel.org" ,
	Russell King ,
	"linux-arm-kernel@lists.infradead.org"
	
Subject: Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-10 at 15:47 +0100, Stefano Stabellini wrote:
> On Wed, 10 Oct 2012, Ian Campbell wrote:
> > On Tue, 2012-10-09 at 19:21 +0100, Arnd Bergmann wrote:
> > > On Tuesday 09 October 2012, Stefano Stabellini wrote:
> > > > >  config XEN
> > > > >       bool "Xen guest support on ARM (EXPERIMENTAL)"
> > > > >       depends on EXPERIMENTAL && ARM && OF
> > > > > +     depends on !CPU_V6
> > > > >       help
> > > > >         Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
> > > > 
> > > > Considering that we rely on the virtualization extensions, this one can
> > > > be:
> > > > 
> > > >     depends on CPU_V7
> > > > 
> > > > The rest looks fine. I can submit a second patch to change !CPU_V6 into
> > > > CPU_V7 later, if you prefer.
> > > 
> > > CPU_V6 and CPU_V7 are not exclusive, I saw the problem when building a
> > > combined kernel for both V6 and V7. The code also needs to depend on ARMv7
> > > with virtualization extensions, but that is a different issue. We don't
> > > actually have a configuration symbol for that yet, as far as I can tell.
> > 
> > I don't think the guest kernels (including dom0) need the extensions to
> > run under Xen, they are only need by Xen itself. The guests should just
> > see a relatively normal v7 processor. 
> > 
> > Stefano, does that sound right?
> 
> Keep in mind that we are using HVC to issue hypercalls, and HVC has been
> introduced with the virtualization extensions, if I am not mistaken.

I think we can ignore that in this context since it is only used by bits
which are already virtualisation aware -- i.e. you wouldn't want to add
it to the Kconfig as a dependency for Xen.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 14:59:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 14:59:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLxkS-0001J7-JW; Wed, 10 Oct 2012 14:59:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLxkQ-0001J1-Ti
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 14:58:59 +0000
Received: from [85.158.143.99:9089] by server-1.bemta-4.messagelabs.com id
	9B/F3-19551-23D85705; Wed, 10 Oct 2012 14:58:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1349881137!27163655!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM3MzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6226 invoked from network); 10 Oct 2012 14:58:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 14:58:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="15078552"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 14:58:57 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 10 Oct 2012 15:58:57 +0100
Date: Wed, 10 Oct 2012 15:58:40 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Arnd Bergmann 
In-Reply-To: <201210091840.25176.arnd@arndb.de>
Message-ID: 
References: <1349796183-30648-1-git-send-email-arnd@arndb.de>
	<20121009160814.GH4625@n2100.arm.linux.org.uk>
	<201210091840.25176.arnd@arndb.de>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "mmarek@suse.cz" ,
	"dave.martin@linaro.org" ,
	"xen-devel@lists.xensource.com" ,
	Russell King - ARM Linux ,
	"jonathan.austin@arm.com" ,
	"konrad.wilk@oracle.com" ,
	"catalin.marinas@arm.com" ,
	"linus.walleij@linaro.org" ,
	Stefano Stabellini ,
	"sboyd@codeaurora.org" ,
	"linux-kernel@vger.kernel.org" ,
	"will.deacon@arm.com" , "rjw@sisk.pl" ,
	"damm@opensource.se" ,
	"jeremy@goop.org" ,
	"bryan.wu@canonical.com" ,
	"tglx@linutronix.de" ,
	"leif.lindholm@arm.com" ,
	"linux-arm-kernel@lists.infradead.org"
	
Subject: Re: [Xen-devel] [GIT PULL 0/9] ARM architecture fixes for 3.7
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 9 Oct 2012, Arnd Bergmann wrote:
> On Tuesday 09 October 2012, Russell King - ARM Linux wrote:
> > 
> > On Tue, Oct 09, 2012 at 05:22:54PM +0200, Arnd Bergmann wrote:
> > > Here are some patches that belong into your domain, I hope you can
> > > just send the lot to Linus the next time you send other patches.
> > > 
> > > These bug fixes all address problems found with automated build testing.
> > > Some of them have been around for a long time, other bugs are
> > > regressions since the merge window.
> > 
> > Apart from the sliced off comment in one commit (which XEN people need
> > to confirm they're happy with the final version), I think these are
> > otherwise fine... I'll hold off pulling them until that can be fixed.
> 
> Fixed that now, and I also added the Acks that I got in the meantime,
> changed the dependency from Xen on (CPU_v7 && !CPU_V6), and edited the
> description for patch 6 as Dave suggested.

Thanks for the update, the new Xen patch is fine by me

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 14:59:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 14:59:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLxkS-0001J7-JW; Wed, 10 Oct 2012 14:59:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLxkQ-0001J1-Ti
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 14:58:59 +0000
Received: from [85.158.143.99:9089] by server-1.bemta-4.messagelabs.com id
	9B/F3-19551-23D85705; Wed, 10 Oct 2012 14:58:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1349881137!27163655!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM3MzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6226 invoked from network); 10 Oct 2012 14:58:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 14:58:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="15078552"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 14:58:57 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 10 Oct 2012 15:58:57 +0100
Date: Wed, 10 Oct 2012 15:58:40 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Arnd Bergmann 
In-Reply-To: <201210091840.25176.arnd@arndb.de>
Message-ID: 
References: <1349796183-30648-1-git-send-email-arnd@arndb.de>
	<20121009160814.GH4625@n2100.arm.linux.org.uk>
	<201210091840.25176.arnd@arndb.de>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "mmarek@suse.cz" ,
	"dave.martin@linaro.org" ,
	"xen-devel@lists.xensource.com" ,
	Russell King - ARM Linux ,
	"jonathan.austin@arm.com" ,
	"konrad.wilk@oracle.com" ,
	"catalin.marinas@arm.com" ,
	"linus.walleij@linaro.org" ,
	Stefano Stabellini ,
	"sboyd@codeaurora.org" ,
	"linux-kernel@vger.kernel.org" ,
	"will.deacon@arm.com" , "rjw@sisk.pl" ,
	"damm@opensource.se" ,
	"jeremy@goop.org" ,
	"bryan.wu@canonical.com" ,
	"tglx@linutronix.de" ,
	"leif.lindholm@arm.com" ,
	"linux-arm-kernel@lists.infradead.org"
	
Subject: Re: [Xen-devel] [GIT PULL 0/9] ARM architecture fixes for 3.7
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 9 Oct 2012, Arnd Bergmann wrote:
> On Tuesday 09 October 2012, Russell King - ARM Linux wrote:
> > 
> > On Tue, Oct 09, 2012 at 05:22:54PM +0200, Arnd Bergmann wrote:
> > > Here are some patches that belong into your domain, I hope you can
> > > just send the lot to Linus the next time you send other patches.
> > > 
> > > These bug fixes all address problems found with automated build testing.
> > > Some of them have been around for a long time, other bugs are
> > > regressions since the merge window.
> > 
> > Apart from the sliced off comment in one commit (which XEN people need
> > to confirm they're happy with the final version), I think these are
> > otherwise fine... I'll hold off pulling them until that can be fixed.
> 
> Fixed that now, and I also added the Acks that I got in the meantime,
> changed the dependency from Xen on (CPU_v7 && !CPU_V6), and edited the
> description for patch 6 as Dave suggested.

Thanks for the update, the new Xen patch is fine by me

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 15:08:38 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 15:08:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLxtY-0001Xa-LY; Wed, 10 Oct 2012 15:08:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLxtW-0001XV-OY
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 15:08:23 +0000
Received: from [85.158.143.99:22596] by server-3.bemta-4.messagelabs.com id
	7E/FB-10075-66F85705; Wed, 10 Oct 2012 15:08:22 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1349881699!23995954!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzU1MDA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19532 invoked from network); 10 Oct 2012 15:08:20 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 15:08:20 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208,217";a="40764034"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 15:00:46 +0000
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.210]) by
	FTLPMAILMX01.citrite.net ([10.13.107.65]) with mapi; Wed, 10 Oct 2012
	11:00:43 -0400
From: Ross Philipson 
To: Art Napor , "xen-devel@lists.xen.org"
	
Date: Wed, 10 Oct 2012 11:00:54 -0400
Thread-Topic: [Xen-devel]  [PATCH v3 01/04] HVM firmware passthrough HVM
Thread-Index: Ac2mWFO3s7pnKixmRTqQ/gvVPFA6jQAn1wrQ
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720A31C6A4C96@FTLPMAILBOX02.citrite.net>
References: <1346343064.91089.YahooMailNeo@web121001.mail.ne1.yahoo.com>
	<831D55AF5A11D64C9B4B43F59EEBF720A31BCC42AB@FTLPMAILBOX02.citrite.net>
	<1346437375.61994.YahooMailNeo@web121001.mail.ne1.yahoo.com>
	<831D55AF5A11D64C9B4B43F59EEBF720A31BCC442E@FTLPMAILBOX02.citrite.net>
	<1349805295.77475.YahooMailNeo@web121002.mail.ne1.yahoo.com>
	<831D55AF5A11D64C9B4B43F59EEBF720A31C4E5D51@FTLPMAILBOX02.citrite.net>
	<1349812653.76722.YahooMailNeo@web121001.mail.ne1.yahoo.com>
In-Reply-To: <1349812653.76722.YahooMailNeo@web121001.mail.ne1.yahoo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH v3 01/04] HVM firmware passthrough HVM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============3612128345330520971=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3612128345330520971==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_831D55AF5A11D64C9B4B43F59EEBF720A31C6A4C96FTLPMAILBOX02_"

--_000_831D55AF5A11D64C9B4B43F59EEBF720A31C6A4C96FTLPMAILBOX02_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

It looks like this thread fell off the xen-devel list - putting it back. I =
am not sure what you mean by hard-coded. Newer kernels expose the DMI/SMBIO=
S information in sysfs. I could send out some sample code that does this.

General question for xen-devel: Is it ok to forward sample code to the list=
? I am not sure what the rules of engagement are concerning that.

Thanks
Ross

From: Art Napor [mailto:artnapor@yahoo.com]
Sent: Tuesday, October 09, 2012 3:58 PM
To: Ross Philipson
Subject: Re: [Xen-devel] [PATCH v3 01/04] HVM firmware passthrough HVM

Ross,

I wish I could say yes. I think I see where these are intended to be loaded=
 in from the fourth patch in the v3 series. I guess I'm not clear on how th=
e tool stack would read these in. Would these values be hard coded in from =
/sysfs or could these be configured in xen.cfg or other arguments passed in=
?


+#define HVM_XS_HVMLOADER               "hvmloader"
+#define HVM_XS_BIOS                    "hvmloader/bios"
+#define HVM_XS_GENERATION_ID_ADDRESS   "hvmloader/generation-id-address"
+
+/* The following values allow additional ACPI tables to be added to the
+ * virtual ACPI BIOS that hvmloader constructs. The values specify the gue=
st
+ * physical address and length of a block of ACPI tables to add. The forma=
t of
+ * the block is simply concatenated raw tables (which specify their own le=
ngth
+ * in the ACPI header).
+ */
+#define HVM_XS_ACPI_PT_ADDRESS         "hvmloader/acpi/address"
+#define HVM_XS_ACPI_PT_LENGTH          "hvmloader/acpi/length"
+
+/* Any number of SMBIOS types can be passed through to an HVM guest using
+ * the following xenstore values. The values specify the guest physical
+ * address and length of a block of SMBIOS structures for hvmloader to use=
.
+ * The block is formatted in the following way:
+ *
+ * ...
+ *
+ * Each length separator is a 32b integer indicating the length of the nex=
t
+ * SMBIOS structure. For DMTF defined types (0 - 121), the passed in struc=
t
+ * will replace the default structure in hvmloader. In addition, any
+ * OEM/vendortypes (128 - 255) will all be added.
+ */
+#define HVM_XS_SMBIOS_PT_ADDRESS       "hvmloader/smbios/address"
+#define HVM_XS_SMBIOS_PT_LENGTH        "hvmloader/smbios/length"
+
+/* Set to 1 to enable SMBIOS default portable battery (type 22) values. */
+#define HVM_XS_SMBIOS_DEFAULT_BATTERY  "hvmloader/smbios/default_battery"
+
+/* The following xenstore values are used to override some of the default
+ * string values in the SMBIOS table constructed in hvmloader.
+ */
+#define HVM_XS_BIOS_STRINGS            "bios-strings"
+#define HVM_XS_BIOS_VENDOR             "bios-strings/bios-vendor"
+#define HVM_XS_BIOS_VERSION            "bios-strings/bios-version"
+#define HVM_XS_SYSTEM_MANUFACTURER     "bios-strings/system-manufacturer"
+#define HVM_XS_SYSTEM_PRODUCT_NAME     "bios-strings/system-product-name"
+#define HVM_XS_SYSTEM_VERSION          "bios-strings/system-version"
+#define HVM_XS_SYSTEM_SERIAL_NUMBER    "bios-strings/system-serial-number"
+#define HVM_XS_ENCLOSURE_MANUFACTURER  "bios-strings/enclosure-manufacture=
r"
+#define HVM_XS_ENCLOSURE_SERIAL_NUMBER "bios-strings/enclosure-serial-numb=
er"
+#define HVM_XS_BATTERY_MANUFACTURER    "bios-strings/battery-manufacturer"
+#define HVM_XS_BATTERY_DEVICE_NAME     "bios-strings/battery-device-name"
+
+/* Up to 100 OEM strings can be set in xenstore using values of the form

________________________________
From: Ross Philipson 
To: Art Napor 
Sent: Tuesday, October 9, 2012 2:06 PM
Subject: RE: [Xen-devel] [PATCH v3 01/04] HVM firmware passthrough HVM

Hi,

So the patches to xen are only part of what you need to make it all work. S=
omething in your toolstack needs to load the tables you want into the new g=
uest. There was no really good place to do this in the xen tools so I did n=
ot push. I am guessing e.g. somewhere in you dom0 tools, you would call dmi=
decode or read the tables from sysfs, form the set of tables for the guest =
that you want and pass them in to the libxc domain creator function. Does t=
hat make sense?

Thanks
Ross

From: Art Napor [mailto:artnapor@yahoo.com]
Sent: Tuesday, October 09, 2012 1:55 PM
To: Ross Philipson
Subject: Re: [Xen-devel] [PATCH v3 01/04] HVM firmware passthrough HVM

Ross,

Thanks again for the information. I was able to apply the SMBIOS patch seri=
es cleanly to 4.1.2 and v3 of your later patch series to 4.2 and 4.3 testin=
g. Is there an option or flag that needs to be set to enable the HVM passth=
rough? I believe the patches applied cleanly - I didn't notice any rejects.=
 I have smbios loaded in the Dom0 /sys/firmware/smbios and /sys/class/dmi/.=
 A Centos 5 DomU with the patched Xen 4.2/4.3 appears to still report the s=
tandard Xen bios information via dmidecode.


________________________________
From: Ross Philipson 
To: Art Napor ; "xen-devel@lists.xen.org" 
Sent: Friday, August 31, 2012 4:36 PM
Subject: RE: [Xen-devel] [PATCH v3 01/04] HVM firmware passthrough HVM

> I also came across the earlier smbios passthrough patch series. I'm looki=
ng to be able to pass the DMI block from the Dom0 to the DomU when. Your ea=
rlier smbios patch series applied cleanly built against to 4.1.2, but the D=
om0 smbios data didn't seem to make it into the HVM DomU.

> Are there any version or other changset limitations that would prevent th=
e patches from being manually applied to 4.1?

> http://lists.xen.org/archives/html/xen-devel/2012-02/msg01754.html

Well there were some tool stack changes (in libxl) that happened right arou=
nd the time I was making the patches so I had to change things to match tha=
t. So in an older branch you might have to change the way the BIOS blobs ge=
t sent in to the domain building code.

The rest of the code to load the BIOS bits into the new guests memory and t=
he changes to hvmloader to process them should apply cleanly I think.

Note that the last patch set for this (v3) does support passing in both SMB=
IOS structures and ACPI tables so you can use that patch set.

Thanks
Ross




--_000_831D55AF5A11D64C9B4B43F59EEBF720A31C6A4C96FTLPMAILBOX02_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


It looks like this thread fell o=
ff the xen-devel list – putting it back. I am not sure what you mean =
by hard-coded. Newer kernels expose the DMI/SMBIOS information in sysfs. I =
could send out some sample code that does this.
<=
o:p> 
General question for xen-devel: Is it ok to=
 forward sample code to the list? I am not sure what the rules of engagemen=
t are concerning that.
 
Thanks
Ross
 
From:<=
/b> Art =
Napor [mailto:artnapor@yahoo.com] 
Sent: Tuesday, October 09, 201=
2 3:58 PM
To: Ross Philipson
Subject: Re: [Xen-devel] [=
PATCH v3 01/04] HVM firmware passthrough HVM
 
Ro=
ss,
 
I wish I could sa=
y yes. I think I see where these are intended to be loaded in from the four=
th patch in the v3 series. I guess I'm not clear on how the tool stack woul=
d read these in. Would these values be hard coded in from /sysfs or could t=
hese be configured in xen.cfg or other arguments passed in? 
 
 
+#defi=
ne HVM_XS_HVMLOADER         &n=
bsp;     "hvmloader"
+#define HVM_XS_BIOS&=
nbsp;           &nbs=
p;       "hvmloader/bios"
+#defi=
ne HVM_XS_GENERATION_ID_ADDRESS   "hvmloader/generation-id-a=
ddress"
+
+/* The following values allow additional ACPI tables =
to be added to the
+ * virtual ACPI BIOS that hvmloader constructs. The =
values specify the guest
+ * physical address and length of a block of A=
CPI tables to add. The format of
+ * the block is simply concatenated ra=
w tables (which specify their own length
+ * in the ACPI header).
+ *=
/
+#define HVM_XS_ACPI_PT_ADDRESS      &nb=
sp;  "hvmloader/acpi/address"
+#define HVM_XS_ACPI_PT_LEN=
GTH          "hvmloader/a=
cpi/length"
+
+/* Any number of SMBIOS types can be passed throu=
gh to an HVM guest using
+ * the following xenstore values. The values s=
pecify the guest physical
+ * address and length of a block of SMBIOS st=
ructures for hvmloader to use.
+ * The block is formatted in the followi=
ng way:
+ *
+ * <length><struct><length><struct&=
gt;...
+ *
+ * Each length separator is a 32b integer indicating the =
length of the next
+ * SMBIOS structure. For DMTF defined types (0 - 121=
), the passed in struct
+ * will replace the default structure in hvmloa=
der. In addition, any
+ * OEM/vendortypes (128 - 255) will all be added.=

+ */
+#define HVM_XS_SMBIOS_PT_ADDRESS     =
  "hvmloader/smbios/address"
+#define HVM_XS_SMBIOS_PT_LE=
NGTH        "hvmloader/smbios/lengt=
h"
+
+/* Set to 1 to enable SMBIOS default portable battery (typ=
e 22) values. */
+#define HVM_XS_SMBIOS_DEFAULT_BATTERY  "hvml=
oader/smbios/default_battery"
+
+/* The following xenstore value=
s are used to override some of the default
+ * string values in the SMBI=
OS table constructed in hvmloader.
+ */
+#define HVM_XS_BIOS_STRINGS&=
nbsp;           "bio=
s-strings"
+#define HVM_XS_BIOS_VENDOR     =
;        "bios-strings/bios-vendor&=
quot;
+#define HVM_XS_BIOS_VERSION      &n=
bsp;     "bios-strings/bios-version"
+#def=
ine HVM_XS_SYSTEM_MANUFACTURER     "bios-strings/s=
ystem-manufacturer"
+#define HVM_XS_SYSTEM_PRODUCT_NAME  =
   "bios-strings/system-product-name"
+#define HVM_X=
S_SYSTEM_VERSION          &quo=
t;bios-strings/system-version"
+#define HVM_XS_SYSTEM_SERIAL_NUMBER=
    "bios-strings/system-serial-number"
+#defin=
e HVM_XS_ENCLOSURE_MANUFACTURER  "bios-strings/enclosure-manufact=
urer"
+#define HVM_XS_ENCLOSURE_SERIAL_NUMBER "bios-strings/en=
closure-serial-number"
+#define HVM_XS_BATTERY_MANUFACTURER &n=
bsp;  "bios-strings/battery-manufacturer"
+#define HVM_XS=
_BATTERY_DEVICE_NAME     "bios-strings/battery-dev=
ice-name"
+
+/* Up to 100 OEM strings can be set in xenstore usi=
ng values of the form
 
From: Ross Philipson <Ross.Philipson@cit=
rix.com>
To: Art Napor <artnapor@yahoo.com> 
Sent:=
 Tuesday, October 9, 2012 2:06 PM
Subject: RE: [Xen-devel] [P=
ATCH v3 01/04] HVM firmware passthrough HVM
 
Hi,
 
=
So the patches to xen are only part of what you need to make it all work. S=
omething in your toolstack needs to load the tables you want into the new g=
uest. There was no really good place to do this in the xen tools so I did n=
ot push. I am guessing e.g. somewhere in you dom0 tools, you would call dmi=
decode or read the tables from sysfs, form the set of tables for the guest =
that you want and pass them in to the libxc domain creator function. Does t=
hat make sense?
 =

Thanks
Ro=
ss
 
From: Art Napor [mail=
to:artnapor@yahoo.com] 
Sent: Tuesday, October 09, 2012 1:55 PMTo: Ross Philipson
Subject: Re: [Xen-devel] [PATCH v3 01=
/04] HVM firmware passthrough HVM
 
Ross,
 
Thanks again for the information. I was able to apply the SMBIOS=
 patch series cleanly to 4.1.2 and v3 of your later patch series to 4.2 and=
 4.3 testing. Is there an option or flag that needs to be set to enable the=
 HVM passthrough? I believe the patches applied cleanly - I didn't notice a=
ny rejects. I have smbios loaded in the Dom0 /sys/firmware/smbios and /sys/=
class/dmi/. A Centos 5 DomU with the patched Xen 4.2/4.3 appears to still r=
eport the standard Xen bios information via dmidecode. 
 
 
From: Ross Philipson <Ross.Philipson@citrix.co=
m>
To: Art Napor <artnapor@yahoo.com>; "xen-devel@l=
ists.xen.org" <xen-devel@lists.xen.org> 
Sent: Friday,=
 August 31, 2012 4:36 PM
Subject: RE: [Xen-devel] [PATCH v3 01/04=
] HVM firmware passthrough HVM

> I also came across the earlier smbios passthrough patch ser=
ies. I'm looking to be able to pass the DMI block from the Dom0 to the DomU=
 when. Your earlier smbios patch series applied cleanly built against to 4.=
1.2, but the Dom0 smbios data didn't seem to make it into the HVM DomU. 
> Are there any version or other changset limitations that would pr=
event the patches from being manually applied to 4.1? 

> htt=
p://lists.xen.org/archives/html/xen-devel/2012-02/msg01754.html

=
Well there were some tool stack changes (in libxl) that happened right arou=
nd the time I was making the patches so I had to change things to match tha=
t. So in an older branch you might have to change the way the BIOS blobs ge=
t sent in to the domain building code.

The rest of the code to load =
the BIOS bits into the new guests memory and the changes to hvmloader to pr=
ocess them should apply cleanly I think.

Note that the last patch se=
t for this (v3) does support passing in both SMBIOS structures and ACPI tab=
les so you can use that patch set.

Thanks
Ross


 
=
=

--_000_831D55AF5A11D64C9B4B43F59EEBF720A31C6A4C96FTLPMAILBOX02_--


--===============3612128345330520971==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3612128345330520971==--


From xen-devel-bounces@lists.xen.org Wed Oct 10 15:08:38 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 15:08:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLxtY-0001Xa-LY; Wed, 10 Oct 2012 15:08:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLxtW-0001XV-OY
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 15:08:23 +0000
Received: from [85.158.143.99:22596] by server-3.bemta-4.messagelabs.com id
	7E/FB-10075-66F85705; Wed, 10 Oct 2012 15:08:22 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1349881699!23995954!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzU1MDA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19532 invoked from network); 10 Oct 2012 15:08:20 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 15:08:20 -0000
X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208,217";a="40764034"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 15:00:46 +0000
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.210]) by
	FTLPMAILMX01.citrite.net ([10.13.107.65]) with mapi; Wed, 10 Oct 2012
	11:00:43 -0400
From: Ross Philipson 
To: Art Napor , "xen-devel@lists.xen.org"
	
Date: Wed, 10 Oct 2012 11:00:54 -0400
Thread-Topic: [Xen-devel]  [PATCH v3 01/04] HVM firmware passthrough HVM
Thread-Index: Ac2mWFO3s7pnKixmRTqQ/gvVPFA6jQAn1wrQ
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720A31C6A4C96@FTLPMAILBOX02.citrite.net>
References: <1346343064.91089.YahooMailNeo@web121001.mail.ne1.yahoo.com>
	<831D55AF5A11D64C9B4B43F59EEBF720A31BCC42AB@FTLPMAILBOX02.citrite.net>
	<1346437375.61994.YahooMailNeo@web121001.mail.ne1.yahoo.com>
	<831D55AF5A11D64C9B4B43F59EEBF720A31BCC442E@FTLPMAILBOX02.citrite.net>
	<1349805295.77475.YahooMailNeo@web121002.mail.ne1.yahoo.com>
	<831D55AF5A11D64C9B4B43F59EEBF720A31C4E5D51@FTLPMAILBOX02.citrite.net>
	<1349812653.76722.YahooMailNeo@web121001.mail.ne1.yahoo.com>
In-Reply-To: <1349812653.76722.YahooMailNeo@web121001.mail.ne1.yahoo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH v3 01/04] HVM firmware passthrough HVM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============3612128345330520971=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3612128345330520971==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_831D55AF5A11D64C9B4B43F59EEBF720A31C6A4C96FTLPMAILBOX02_"

--_000_831D55AF5A11D64C9B4B43F59EEBF720A31C6A4C96FTLPMAILBOX02_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

It looks like this thread fell off the xen-devel list - putting it back. I =
am not sure what you mean by hard-coded. Newer kernels expose the DMI/SMBIO=
S information in sysfs. I could send out some sample code that does this.

General question for xen-devel: Is it ok to forward sample code to the list=
? I am not sure what the rules of engagement are concerning that.

Thanks
Ross

From: Art Napor [mailto:artnapor@yahoo.com]
Sent: Tuesday, October 09, 2012 3:58 PM
To: Ross Philipson
Subject: Re: [Xen-devel] [PATCH v3 01/04] HVM firmware passthrough HVM

Ross,

I wish I could say yes. I think I see where these are intended to be loaded=
 in from the fourth patch in the v3 series. I guess I'm not clear on how th=
e tool stack would read these in. Would these values be hard coded in from =
/sysfs or could these be configured in xen.cfg or other arguments passed in=
?


+#define HVM_XS_HVMLOADER               "hvmloader"
+#define HVM_XS_BIOS                    "hvmloader/bios"
+#define HVM_XS_GENERATION_ID_ADDRESS   "hvmloader/generation-id-address"
+
+/* The following values allow additional ACPI tables to be added to the
+ * virtual ACPI BIOS that hvmloader constructs. The values specify the gue=
st
+ * physical address and length of a block of ACPI tables to add. The forma=
t of
+ * the block is simply concatenated raw tables (which specify their own le=
ngth
+ * in the ACPI header).
+ */
+#define HVM_XS_ACPI_PT_ADDRESS         "hvmloader/acpi/address"
+#define HVM_XS_ACPI_PT_LENGTH          "hvmloader/acpi/length"
+
+/* Any number of SMBIOS types can be passed through to an HVM guest using
+ * the following xenstore values. The values specify the guest physical
+ * address and length of a block of SMBIOS structures for hvmloader to use=
.
+ * The block is formatted in the following way:
+ *
+ * ...
+ *
+ * Each length separator is a 32b integer indicating the length of the nex=
t
+ * SMBIOS structure. For DMTF defined types (0 - 121), the passed in struc=
t
+ * will replace the default structure in hvmloader. In addition, any
+ * OEM/vendortypes (128 - 255) will all be added.
+ */
+#define HVM_XS_SMBIOS_PT_ADDRESS       "hvmloader/smbios/address"
+#define HVM_XS_SMBIOS_PT_LENGTH        "hvmloader/smbios/length"
+
+/* Set to 1 to enable SMBIOS default portable battery (type 22) values. */
+#define HVM_XS_SMBIOS_DEFAULT_BATTERY  "hvmloader/smbios/default_battery"
+
+/* The following xenstore values are used to override some of the default
+ * string values in the SMBIOS table constructed in hvmloader.
+ */
+#define HVM_XS_BIOS_STRINGS            "bios-strings"
+#define HVM_XS_BIOS_VENDOR             "bios-strings/bios-vendor"
+#define HVM_XS_BIOS_VERSION            "bios-strings/bios-version"
+#define HVM_XS_SYSTEM_MANUFACTURER     "bios-strings/system-manufacturer"
+#define HVM_XS_SYSTEM_PRODUCT_NAME     "bios-strings/system-product-name"
+#define HVM_XS_SYSTEM_VERSION          "bios-strings/system-version"
+#define HVM_XS_SYSTEM_SERIAL_NUMBER    "bios-strings/system-serial-number"
+#define HVM_XS_ENCLOSURE_MANUFACTURER  "bios-strings/enclosure-manufacture=
r"
+#define HVM_XS_ENCLOSURE_SERIAL_NUMBER "bios-strings/enclosure-serial-numb=
er"
+#define HVM_XS_BATTERY_MANUFACTURER    "bios-strings/battery-manufacturer"
+#define HVM_XS_BATTERY_DEVICE_NAME     "bios-strings/battery-device-name"
+
+/* Up to 100 OEM strings can be set in xenstore using values of the form

________________________________
From: Ross Philipson 
To: Art Napor 
Sent: Tuesday, October 9, 2012 2:06 PM
Subject: RE: [Xen-devel] [PATCH v3 01/04] HVM firmware passthrough HVM

Hi,

So the patches to xen are only part of what you need to make it all work. S=
omething in your toolstack needs to load the tables you want into the new g=
uest. There was no really good place to do this in the xen tools so I did n=
ot push. I am guessing e.g. somewhere in you dom0 tools, you would call dmi=
decode or read the tables from sysfs, form the set of tables for the guest =
that you want and pass them in to the libxc domain creator function. Does t=
hat make sense?

Thanks
Ross

From: Art Napor [mailto:artnapor@yahoo.com]
Sent: Tuesday, October 09, 2012 1:55 PM
To: Ross Philipson
Subject: Re: [Xen-devel] [PATCH v3 01/04] HVM firmware passthrough HVM

Ross,

Thanks again for the information. I was able to apply the SMBIOS patch seri=
es cleanly to 4.1.2 and v3 of your later patch series to 4.2 and 4.3 testin=
g. Is there an option or flag that needs to be set to enable the HVM passth=
rough? I believe the patches applied cleanly - I didn't notice any rejects.=
 I have smbios loaded in the Dom0 /sys/firmware/smbios and /sys/class/dmi/.=
 A Centos 5 DomU with the patched Xen 4.2/4.3 appears to still report the s=
tandard Xen bios information via dmidecode.


________________________________
From: Ross Philipson 
To: Art Napor ; "xen-devel@lists.xen.org" 
Sent: Friday, August 31, 2012 4:36 PM
Subject: RE: [Xen-devel] [PATCH v3 01/04] HVM firmware passthrough HVM

> I also came across the earlier smbios passthrough patch series. I'm looki=
ng to be able to pass the DMI block from the Dom0 to the DomU when. Your ea=
rlier smbios patch series applied cleanly built against to 4.1.2, but the D=
om0 smbios data didn't seem to make it into the HVM DomU.

> Are there any version or other changset limitations that would prevent th=
e patches from being manually applied to 4.1?

> http://lists.xen.org/archives/html/xen-devel/2012-02/msg01754.html

Well there were some tool stack changes (in libxl) that happened right arou=
nd the time I was making the patches so I had to change things to match tha=
t. So in an older branch you might have to change the way the BIOS blobs ge=
t sent in to the domain building code.

The rest of the code to load the BIOS bits into the new guests memory and t=
he changes to hvmloader to process them should apply cleanly I think.

Note that the last patch set for this (v3) does support passing in both SMB=
IOS structures and ACPI tables so you can use that patch set.

Thanks
Ross




--_000_831D55AF5A11D64C9B4B43F59EEBF720A31C6A4C96FTLPMAILBOX02_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


It looks like this thread fell o=
ff the xen-devel list – putting it back. I am not sure what you mean =
by hard-coded. Newer kernels expose the DMI/SMBIOS information in sysfs. I =
could send out some sample code that does this.
<=
o:p> 
General question for xen-devel: Is it ok to=
 forward sample code to the list? I am not sure what the rules of engagemen=
t are concerning that.
 
Thanks
Ross
 
From:<=
/b> Art =
Napor [mailto:artnapor@yahoo.com] 
Sent: Tuesday, October 09, 201=
2 3:58 PM
To: Ross Philipson
Subject: Re: [Xen-devel] [=
PATCH v3 01/04] HVM firmware passthrough HVM
 
Ro=
ss,
 
I wish I could sa=
y yes. I think I see where these are intended to be loaded in from the four=
th patch in the v3 series. I guess I'm not clear on how the tool stack woul=
d read these in. Would these values be hard coded in from /sysfs or could t=
hese be configured in xen.cfg or other arguments passed in? 
 
 
+#defi=
ne HVM_XS_HVMLOADER         &n=
bsp;     "hvmloader"
+#define HVM_XS_BIOS&=
nbsp;           &nbs=
p;       "hvmloader/bios"
+#defi=
ne HVM_XS_GENERATION_ID_ADDRESS   "hvmloader/generation-id-a=
ddress"
+
+/* The following values allow additional ACPI tables =
to be added to the
+ * virtual ACPI BIOS that hvmloader constructs. The =
values specify the guest
+ * physical address and length of a block of A=
CPI tables to add. The format of
+ * the block is simply concatenated ra=
w tables (which specify their own length
+ * in the ACPI header).
+ *=
/
+#define HVM_XS_ACPI_PT_ADDRESS      &nb=
sp;  "hvmloader/acpi/address"
+#define HVM_XS_ACPI_PT_LEN=
GTH          "hvmloader/a=
cpi/length"
+
+/* Any number of SMBIOS types can be passed throu=
gh to an HVM guest using
+ * the following xenstore values. The values s=
pecify the guest physical
+ * address and length of a block of SMBIOS st=
ructures for hvmloader to use.
+ * The block is formatted in the followi=
ng way:
+ *
+ * <length><struct><length><struct&=
gt;...
+ *
+ * Each length separator is a 32b integer indicating the =
length of the next
+ * SMBIOS structure. For DMTF defined types (0 - 121=
), the passed in struct
+ * will replace the default structure in hvmloa=
der. In addition, any
+ * OEM/vendortypes (128 - 255) will all be added.=

+ */
+#define HVM_XS_SMBIOS_PT_ADDRESS     =
  "hvmloader/smbios/address"
+#define HVM_XS_SMBIOS_PT_LE=
NGTH        "hvmloader/smbios/lengt=
h"
+
+/* Set to 1 to enable SMBIOS default portable battery (typ=
e 22) values. */
+#define HVM_XS_SMBIOS_DEFAULT_BATTERY  "hvml=
oader/smbios/default_battery"
+
+/* The following xenstore value=
s are used to override some of the default
+ * string values in the SMBI=
OS table constructed in hvmloader.
+ */
+#define HVM_XS_BIOS_STRINGS&=
nbsp;           "bio=
s-strings"
+#define HVM_XS_BIOS_VENDOR     =
;        "bios-strings/bios-vendor&=
quot;
+#define HVM_XS_BIOS_VERSION      &n=
bsp;     "bios-strings/bios-version"
+#def=
ine HVM_XS_SYSTEM_MANUFACTURER     "bios-strings/s=
ystem-manufacturer"
+#define HVM_XS_SYSTEM_PRODUCT_NAME  =
   "bios-strings/system-product-name"
+#define HVM_X=
S_SYSTEM_VERSION          &quo=
t;bios-strings/system-version"
+#define HVM_XS_SYSTEM_SERIAL_NUMBER=
    "bios-strings/system-serial-number"
+#defin=
e HVM_XS_ENCLOSURE_MANUFACTURER  "bios-strings/enclosure-manufact=
urer"
+#define HVM_XS_ENCLOSURE_SERIAL_NUMBER "bios-strings/en=
closure-serial-number"
+#define HVM_XS_BATTERY_MANUFACTURER &n=
bsp;  "bios-strings/battery-manufacturer"
+#define HVM_XS=
_BATTERY_DEVICE_NAME     "bios-strings/battery-dev=
ice-name"
+
+/* Up to 100 OEM strings can be set in xenstore usi=
ng values of the form
 
From: Ross Philipson <Ross.Philipson@cit=
rix.com>
To: Art Napor <artnapor@yahoo.com> 
Sent:=
 Tuesday, October 9, 2012 2:06 PM
Subject: RE: [Xen-devel] [P=
ATCH v3 01/04] HVM firmware passthrough HVM
 
Hi,
 
=
So the patches to xen are only part of what you need to make it all work. S=
omething in your toolstack needs to load the tables you want into the new g=
uest. There was no really good place to do this in the xen tools so I did n=
ot push. I am guessing e.g. somewhere in you dom0 tools, you would call dmi=
decode or read the tables from sysfs, form the set of tables for the guest =
that you want and pass them in to the libxc domain creator function. Does t=
hat make sense?
 =

Thanks
Ro=
ss
 
From: Art Napor [mail=
to:artnapor@yahoo.com] 
Sent: Tuesday, October 09, 2012 1:55 PMTo: Ross Philipson
Subject: Re: [Xen-devel] [PATCH v3 01=
/04] HVM firmware passthrough HVM
 
Ross,
 
Thanks again for the information. I was able to apply the SMBIOS=
 patch series cleanly to 4.1.2 and v3 of your later patch series to 4.2 and=
 4.3 testing. Is there an option or flag that needs to be set to enable the=
 HVM passthrough? I believe the patches applied cleanly - I didn't notice a=
ny rejects. I have smbios loaded in the Dom0 /sys/firmware/smbios and /sys/=
class/dmi/. A Centos 5 DomU with the patched Xen 4.2/4.3 appears to still r=
eport the standard Xen bios information via dmidecode. 
 
 
From: Ross Philipson <Ross.Philipson@citrix.co=
m>
To: Art Napor <artnapor@yahoo.com>; "xen-devel@l=
ists.xen.org" <xen-devel@lists.xen.org> 
Sent: Friday,=
 August 31, 2012 4:36 PM
Subject: RE: [Xen-devel] [PATCH v3 01/04=
] HVM firmware passthrough HVM

> I also came across the earlier smbios passthrough patch ser=
ies. I'm looking to be able to pass the DMI block from the Dom0 to the DomU=
 when. Your earlier smbios patch series applied cleanly built against to 4.=
1.2, but the Dom0 smbios data didn't seem to make it into the HVM DomU. 
> Are there any version or other changset limitations that would pr=
event the patches from being manually applied to 4.1? 

> htt=
p://lists.xen.org/archives/html/xen-devel/2012-02/msg01754.html

=
Well there were some tool stack changes (in libxl) that happened right arou=
nd the time I was making the patches so I had to change things to match tha=
t. So in an older branch you might have to change the way the BIOS blobs ge=
t sent in to the domain building code.

The rest of the code to load =
the BIOS bits into the new guests memory and the changes to hvmloader to pr=
ocess them should apply cleanly I think.

Note that the last patch se=
t for this (v3) does support passing in both SMBIOS structures and ACPI tab=
les so you can use that patch set.

Thanks
Ross


 
=
=

--_000_831D55AF5A11D64C9B4B43F59EEBF720A31C6A4C96FTLPMAILBOX02_--


--===============3612128345330520971==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3612128345330520971==--


From xen-devel-bounces@lists.xen.org Wed Oct 10 15:15:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 15:15:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLxzm-0001ip-M8; Wed, 10 Oct 2012 15:14:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLxzl-0001if-EM
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 15:14:49 +0000
Received: from [85.158.138.51:43947] by server-11.bemta-3.messagelabs.com id
	32/C1-24008-8E095705; Wed, 10 Oct 2012 15:14:48 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1349882086!25772142!1
X-Originating-IP: [209.85.213.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27173 invoked from network); 10 Oct 2012 15:14:48 -0000
Received: from mail-yh0-f43.google.com (HELO mail-yh0-f43.google.com)
	(209.85.213.43)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 15:14:48 -0000
Received: by mail-yh0-f43.google.com with SMTP id i33so146589yhi.30
	for ;
	Wed, 10 Oct 2012 08:14:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:subject:from:to:cc:date:in-reply-to:references
	:content-type:x-mailer:content-transfer-encoding:mime-version;
	bh=IjswFB4ol68VwJ7gcZKCTxMbhdGy3ks9JZ920cH2SvU=;
	b=LDD2Vp597GLKZjpcqVzW8pc0qcHGqHE0caCtKhF/51HrEX0eG+hlX/m/4njnEqDqnE
	uWUnufKL/ibixYXRhLY/3MzRe1+vl0iXEF4QOZJgt4JJITPQvwKo6hW4lOwRKVTzZR6Z
	iSzg0M2DX15RmWM8hP5TSYV6v4BHCPtmP8qKQVWqIxg1bn+4ldRZaFOCRooES/Wy4kHk
	YfkZYddqvVVaBGYaOl0MrmR/U4xxRnvG6iGhgaLCrTVi/a6TBgxdePrKdaOhR+AcwtyP
	J9X0SI2rLD8a27YJRdxys6YHiM/nqcDIgEYs8J8jsmV3toSszsb2v5AnkE7gVfxtih8Q
	DLmQ==
Received: by 10.236.189.68 with SMTP id b44mr23324317yhn.82.1349882086581;
	Wed, 10 Oct 2012 08:14:46 -0700 (PDT)
Received: from [10.80.116.182] (firewall.ctxuk.citrix.com. [62.200.22.2])
	by mx.google.com with ESMTPS id b46sm1390905yhn.5.2012.10.10.08.14.44
	(version=SSLv3 cipher=OTHER); Wed, 10 Oct 2012 08:14:45 -0700 (PDT)
Message-ID: <1349882083.3610.219.camel@Abyss>
From: Dario Faggioli 
To: Ian Jackson 
Date: Wed, 10 Oct 2012 16:14:43 +0100
In-Reply-To: <20596.26200.30125.482942@mariner.uk.xensource.com>
References: 
	<20596.26200.30125.482942@mariner.uk.xensource.com>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
Mime-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [xen-unstable test] 13944: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-09 at 19:00 +0100, Ian Jackson wrote: 
> This is this:
> 
> fatal: Out of memory? mmap failed: Cannot allocate memory
> fatal: The remote end hung up unexpectedly
> make[1]: *** [qemu-xen-dir-find] Error 128
> 
> On gall-mite:
> 
> root@gall-mite:~# free -m
>              total       used       free     shared    buffers     cached
> Mem:          8102       2059       6042          0        650       1286
> -/+ buffers/cache:        122       7980
> Swap:        12143          0      12143
> root@gall-mite:~# 
> 
> So it has 8G of RAM and 12G of swap.
> 
> I wonder if the git object cache is too big.  I will clear gall-mite's
> and see if it helps.
> 
Mmm, gall-mite is the box on which _all_ the sched=sedf test were
running for quite a bit of flights, and consistently failing at the
xen-boot stage. I pointed out the situation already here:

http://www.gossamer-threads.com/lists/xen/devel/258909?do=post_view_threaded

Now that the very same test has moved to some other host it seems to be
working again:

http://www.chiark.greenend.org.uk/~xensrcts/logs/13943/test-amd64-amd64-xl-sedf/info.html

That could be something very silly to think (in which case sorry), but
might this all be some hardware issue on that machine?

Regards,
Dario



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 15:15:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 15:15:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLxzm-0001ip-M8; Wed, 10 Oct 2012 15:14:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLxzl-0001if-EM
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 15:14:49 +0000
Received: from [85.158.138.51:43947] by server-11.bemta-3.messagelabs.com id
	32/C1-24008-8E095705; Wed, 10 Oct 2012 15:14:48 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1349882086!25772142!1
X-Originating-IP: [209.85.213.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27173 invoked from network); 10 Oct 2012 15:14:48 -0000
Received: from mail-yh0-f43.google.com (HELO mail-yh0-f43.google.com)
	(209.85.213.43)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 15:14:48 -0000
Received: by mail-yh0-f43.google.com with SMTP id i33so146589yhi.30
	for ;
	Wed, 10 Oct 2012 08:14:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:subject:from:to:cc:date:in-reply-to:references
	:content-type:x-mailer:content-transfer-encoding:mime-version;
	bh=IjswFB4ol68VwJ7gcZKCTxMbhdGy3ks9JZ920cH2SvU=;
	b=LDD2Vp597GLKZjpcqVzW8pc0qcHGqHE0caCtKhF/51HrEX0eG+hlX/m/4njnEqDqnE
	uWUnufKL/ibixYXRhLY/3MzRe1+vl0iXEF4QOZJgt4JJITPQvwKo6hW4lOwRKVTzZR6Z
	iSzg0M2DX15RmWM8hP5TSYV6v4BHCPtmP8qKQVWqIxg1bn+4ldRZaFOCRooES/Wy4kHk
	YfkZYddqvVVaBGYaOl0MrmR/U4xxRnvG6iGhgaLCrTVi/a6TBgxdePrKdaOhR+AcwtyP
	J9X0SI2rLD8a27YJRdxys6YHiM/nqcDIgEYs8J8jsmV3toSszsb2v5AnkE7gVfxtih8Q
	DLmQ==
Received: by 10.236.189.68 with SMTP id b44mr23324317yhn.82.1349882086581;
	Wed, 10 Oct 2012 08:14:46 -0700 (PDT)
Received: from [10.80.116.182] (firewall.ctxuk.citrix.com. [62.200.22.2])
	by mx.google.com with ESMTPS id b46sm1390905yhn.5.2012.10.10.08.14.44
	(version=SSLv3 cipher=OTHER); Wed, 10 Oct 2012 08:14:45 -0700 (PDT)
Message-ID: <1349882083.3610.219.camel@Abyss>
From: Dario Faggioli 
To: Ian Jackson 
Date: Wed, 10 Oct 2012 16:14:43 +0100
In-Reply-To: <20596.26200.30125.482942@mariner.uk.xensource.com>
References: 
	<20596.26200.30125.482942@mariner.uk.xensource.com>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
Mime-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [xen-unstable test] 13944: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-09 at 19:00 +0100, Ian Jackson wrote: 
> This is this:
> 
> fatal: Out of memory? mmap failed: Cannot allocate memory
> fatal: The remote end hung up unexpectedly
> make[1]: *** [qemu-xen-dir-find] Error 128
> 
> On gall-mite:
> 
> root@gall-mite:~# free -m
>              total       used       free     shared    buffers     cached
> Mem:          8102       2059       6042          0        650       1286
> -/+ buffers/cache:        122       7980
> Swap:        12143          0      12143
> root@gall-mite:~# 
> 
> So it has 8G of RAM and 12G of swap.
> 
> I wonder if the git object cache is too big.  I will clear gall-mite's
> and see if it helps.
> 
Mmm, gall-mite is the box on which _all_ the sched=sedf test were
running for quite a bit of flights, and consistently failing at the
xen-boot stage. I pointed out the situation already here:

http://www.gossamer-threads.com/lists/xen/devel/258909?do=post_view_threaded

Now that the very same test has moved to some other host it seems to be
working again:

http://www.chiark.greenend.org.uk/~xensrcts/logs/13943/test-amd64-amd64-xl-sedf/info.html

That could be something very silly to think (in which case sorry), but
might this all be some hardware issue on that machine?

Regards,
Dario



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 15:33:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 15:33:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLyHi-0002BA-82; Wed, 10 Oct 2012 15:33:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from ) id 1TLyHh-0002B3-Is
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 15:33:21 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-27.messagelabs.com!1349883194!12764511!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9169 invoked from network); 10 Oct 2012 15:33:15 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-16.tower-27.messagelabs.com with SMTP;
	10 Oct 2012 15:33:15 -0000
X-TM-IMSS-Message-ID: 
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1;
	TLSv1/SSLv3 DHE-RSA-AES256-SHA (256/256)) id c9f9fccd0000ec9b ;
	Wed, 10 Oct 2012 11:32:54 -0400
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q9AFWxbr003494; 
	Wed, 10 Oct 2012 11:32:59 -0400
Message-ID: <5075952B.7050309@tycho.nsa.gov>
Date: Wed, 10 Oct 2012 11:32:59 -0400
From: Daniel De Graaf 
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120911 Thunderbird/15.0.1
MIME-Version: 1.0
To: Dario Faggioli 
References: <1349801565.21847.228.camel@zakaz.uk.xensource.com>
	<1349807513-10923-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1349858695.3610.158.camel@Abyss> <50758038.6050009@tycho.nsa.gov>
	<1349879988.3610.194.camel@Abyss>
In-Reply-To: <1349879988.3610.194.camel@Abyss>
Cc: Marcus Granado ,
	"andre.przywara@amd.com" ,
	Ian Campbell ,
	"anil@recoil.org" ,
	George Dunlap ,
	Andrew Cooper ,
	"juergen.gross@ts.fujitsu.com" ,
	Ian Jackson ,
	"xen-devel@lists.xen.org" ,
	"JBeulich@suse.com" , "msw@amazon.com" ,
	"Keir \(Xen.org\)" 
Subject: Re: [Xen-devel] [PATCH RFC] flask: move policy header sources into
 hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/10/2012 10:39 AM, Dario Faggioli wrote:
[...]
>> A more general note on the topic of what XSM permissions to use: 
>> normally, each domctl has its own permission, and so adding new domctls
>> would be done by adding a new permission to the access_vectors file
>> (which is the source of av_perm_to_string.h). However, for this case, it
>> seems rather unlikely that one would want to allow access to vcpu
>> affinity and deny node affinity, so using the same permission for both 
>> accesses is the best solution.
>>
> Yes, exactly.
> 
> Moreover, looking at xen/xsm/flask/include/av_permissions.h where
> DOMAIN__{GET,SET}VCPUAFFINITY are, I got thee impression that there is
> no more space left for DOMAIN__* permissions, as they already go from
> 0x00000001UL to 0x80000000UL... Is that so?

Yes. My XSM patch series expands this by adding SECCLASS_DOMAIN2 to address
this (and that part is already in 4.3). This solution can be applied to any
XSM classes needing more than 32 permission bits.

-- 
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 15:33:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 15:33:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLyHi-0002BA-82; Wed, 10 Oct 2012 15:33:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from ) id 1TLyHh-0002B3-Is
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 15:33:21 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-27.messagelabs.com!1349883194!12764511!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9169 invoked from network); 10 Oct 2012 15:33:15 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-16.tower-27.messagelabs.com with SMTP;
	10 Oct 2012 15:33:15 -0000
X-TM-IMSS-Message-ID: 
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1;
	TLSv1/SSLv3 DHE-RSA-AES256-SHA (256/256)) id c9f9fccd0000ec9b ;
	Wed, 10 Oct 2012 11:32:54 -0400
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q9AFWxbr003494; 
	Wed, 10 Oct 2012 11:32:59 -0400
Message-ID: <5075952B.7050309@tycho.nsa.gov>
Date: Wed, 10 Oct 2012 11:32:59 -0400
From: Daniel De Graaf 
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120911 Thunderbird/15.0.1
MIME-Version: 1.0
To: Dario Faggioli 
References: <1349801565.21847.228.camel@zakaz.uk.xensource.com>
	<1349807513-10923-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1349858695.3610.158.camel@Abyss> <50758038.6050009@tycho.nsa.gov>
	<1349879988.3610.194.camel@Abyss>
In-Reply-To: <1349879988.3610.194.camel@Abyss>
Cc: Marcus Granado ,
	"andre.przywara@amd.com" ,
	Ian Campbell ,
	"anil@recoil.org" ,
	George Dunlap ,
	Andrew Cooper ,
	"juergen.gross@ts.fujitsu.com" ,
	Ian Jackson ,
	"xen-devel@lists.xen.org" ,
	"JBeulich@suse.com" , "msw@amazon.com" ,
	"Keir \(Xen.org\)" 
Subject: Re: [Xen-devel] [PATCH RFC] flask: move policy header sources into
 hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/10/2012 10:39 AM, Dario Faggioli wrote:
[...]
>> A more general note on the topic of what XSM permissions to use: 
>> normally, each domctl has its own permission, and so adding new domctls
>> would be done by adding a new permission to the access_vectors file
>> (which is the source of av_perm_to_string.h). However, for this case, it
>> seems rather unlikely that one would want to allow access to vcpu
>> affinity and deny node affinity, so using the same permission for both 
>> accesses is the best solution.
>>
> Yes, exactly.
> 
> Moreover, looking at xen/xsm/flask/include/av_permissions.h where
> DOMAIN__{GET,SET}VCPUAFFINITY are, I got thee impression that there is
> no more space left for DOMAIN__* permissions, as they already go from
> 0x00000001UL to 0x80000000UL... Is that so?

Yes. My XSM patch series expands this by adding SECCLASS_DOMAIN2 to address
this (and that part is already in 4.3). This solution can be applied to any
XSM classes needing more than 32 permission bits.

-- 
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 15:59:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 15:59:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLyfz-0002Tj-LA; Wed, 10 Oct 2012 15:58:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLyfy-0002Te-LI
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 15:58:26 +0000
Received: from [85.158.139.211:20755] by server-9.bemta-5.messagelabs.com id
	C5/CC-31466-12B95705; Wed, 10 Oct 2012 15:58:25 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-11.tower-206.messagelabs.com!1349884705!21820769!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20449 invoked from network); 10 Oct 2012 15:58:25 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-11.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Oct 2012 15:58:25 -0000
Received: from 50-66-ftth.onsneteindhoven.nl ([88.159.66.50]:59400
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TLyhG-0008A7-Vx; Wed, 10 Oct 2012 17:59:47 +0200
Date: Wed, 10 Oct 2012 17:58:18 +0200
From: Sander Eikelenboom 
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <76252326.20121010175818@eikelenboom.it>
To: "Konrad Rzeszutek Wilk" 
MIME-Version: 1.0
Cc: xen-devel 
Subject: [Xen-devel] Kernel 3.7.0-pre-rc1: mcelog:4344 map pfn expected
	mapping type write-back for [mem 0x0009f000-0x000a0fff],
	got uncached-minus,
	WARNING: at arch/x86/mm/pat.c:774 untrack_pfn+0x8c/0xc0()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Konrad,

On boot with a 3.7.0-pre-rc1 (latest commit is 42859eea96ba6beabfb0369a1eeffa3c7d2bd9cb) i always get:


[   75.718807] mcelog:4344 map pfn expected mapping type write-back for [mem 0x0009f000-0x000a0fff], got uncached-minus
[   75.725282] ------------[ cut here ]------------
[   75.731316] WARNING: at arch/x86/mm/pat.c:774 untrack_pfn+0x8c/0xc0()
[   75.737465] Hardware name: MS-7640
[   75.743678] Modules linked in:
[   75.749528] Pid: 4344, comm: mcelog Not tainted 3.6.0pre-rc1-20121010 #1
[   75.755581] Call Trace:
[   75.761303]  [] warn_slowpath_common+0x7a/0xb0
[   75.767036]  [] warn_slowpath_null+0x15/0x20
[   75.772804]  [] untrack_pfn+0x8c/0xc0
[   75.778391]  [] unmap_single_vma+0x86b/0x8e0
[   75.784002]  [] ? release_pages+0x196/0x1f0
[   75.789484]  [] ? _raw_spin_unlock_irqrestore+0x75/0xa0
[   75.794970]  [] unmap_vmas+0x4c/0xa0
[   75.800375]  [] exit_mmap+0x9a/0x180
[   75.805748]  [] mmput+0x52/0xd0
[   75.811046]  [] dup_mm+0x3c7/0x510
[   75.816380]  [] copy_process+0xad5/0x14b0
[   75.821777]  [] do_fork+0x53/0x360
[   75.827114]  [] ? lock_release+0x117/0x250
[   75.832380]  [] ? _raw_spin_unlock+0x30/0x60
[   75.837977]  [] ? sysret_check+0x22/0x5d
[   75.843337]  [] sys_clone+0x23/0x30
[   75.848567]  [] stub_clone+0x13/0x20
[   75.853718]  [] ? system_call_fastpath+0x16/0x1b
[   75.858913] ---[ end trace df00fd3532db355c ]---


xl dmesg and dmesg attached.

--
Sander


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 15:59:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 15:59:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLyfz-0002Tj-LA; Wed, 10 Oct 2012 15:58:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLyfy-0002Te-LI
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 15:58:26 +0000
Received: from [85.158.139.211:20755] by server-9.bemta-5.messagelabs.com id
	C5/CC-31466-12B95705; Wed, 10 Oct 2012 15:58:25 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-11.tower-206.messagelabs.com!1349884705!21820769!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20449 invoked from network); 10 Oct 2012 15:58:25 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-11.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Oct 2012 15:58:25 -0000
Received: from 50-66-ftth.onsneteindhoven.nl ([88.159.66.50]:59400
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TLyhG-0008A7-Vx; Wed, 10 Oct 2012 17:59:47 +0200
Date: Wed, 10 Oct 2012 17:58:18 +0200
From: Sander Eikelenboom 
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <76252326.20121010175818@eikelenboom.it>
To: "Konrad Rzeszutek Wilk" 
MIME-Version: 1.0
Cc: xen-devel 
Subject: [Xen-devel] Kernel 3.7.0-pre-rc1: mcelog:4344 map pfn expected
	mapping type write-back for [mem 0x0009f000-0x000a0fff],
	got uncached-minus,
	WARNING: at arch/x86/mm/pat.c:774 untrack_pfn+0x8c/0xc0()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Konrad,

On boot with a 3.7.0-pre-rc1 (latest commit is 42859eea96ba6beabfb0369a1eeffa3c7d2bd9cb) i always get:


[   75.718807] mcelog:4344 map pfn expected mapping type write-back for [mem 0x0009f000-0x000a0fff], got uncached-minus
[   75.725282] ------------[ cut here ]------------
[   75.731316] WARNING: at arch/x86/mm/pat.c:774 untrack_pfn+0x8c/0xc0()
[   75.737465] Hardware name: MS-7640
[   75.743678] Modules linked in:
[   75.749528] Pid: 4344, comm: mcelog Not tainted 3.6.0pre-rc1-20121010 #1
[   75.755581] Call Trace:
[   75.761303]  [] warn_slowpath_common+0x7a/0xb0
[   75.767036]  [] warn_slowpath_null+0x15/0x20
[   75.772804]  [] untrack_pfn+0x8c/0xc0
[   75.778391]  [] unmap_single_vma+0x86b/0x8e0
[   75.784002]  [] ? release_pages+0x196/0x1f0
[   75.789484]  [] ? _raw_spin_unlock_irqrestore+0x75/0xa0
[   75.794970]  [] unmap_vmas+0x4c/0xa0
[   75.800375]  [] exit_mmap+0x9a/0x180
[   75.805748]  [] mmput+0x52/0xd0
[   75.811046]  [] dup_mm+0x3c7/0x510
[   75.816380]  [] copy_process+0xad5/0x14b0
[   75.821777]  [] do_fork+0x53/0x360
[   75.827114]  [] ? lock_release+0x117/0x250
[   75.832380]  [] ? _raw_spin_unlock+0x30/0x60
[   75.837977]  [] ? sysret_check+0x22/0x5d
[   75.843337]  [] sys_clone+0x23/0x30
[   75.848567]  [] stub_clone+0x13/0x20
[   75.853718]  [] ? system_call_fastpath+0x16/0x1b
[   75.858913] ---[ end trace df00fd3532db355c ]---


xl dmesg and dmesg attached.

--
Sander


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 16:02:21 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 16:02:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLyjP-0002z5-Am; Wed, 10 Oct 2012 16:01:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLyjN-0002yx-MO
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 16:01:57 +0000
Received: from [85.158.137.99:17314] by server-4.bemta-3.messagelabs.com id
	89/87-01405-4FB95705; Wed, 10 Oct 2012 16:01:56 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1349884913!15928627!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM3MzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9659 invoked from network); 10 Oct 2012 16:01:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 16:01:56 -0000
X-IronPort-AV: E=Sophos;i="4.80,565,1344211200"; d="scan'208";a="15080299"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 16:01:43 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 10 Oct 2012 17:01:43 +0100
Date: Wed, 10 Oct 2012 17:01:26 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1349880826.10070.41.camel@zakaz.uk.xensource.com>
Message-ID: 
References: <1349796183-30648-1-git-send-email-arnd@arndb.de>
	<1349796183-30648-6-git-send-email-arnd@arndb.de>
	
	<201210091821.27818.arnd@arndb.de>
	<1349855687.6952.75.camel@dagon.hellion.org.uk>
	
	<1349880826.10070.41.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge ,
	"xen-devel@lists.xensource.com" ,
	Arnd Bergmann ,
	Konrad Rzeszutek Wilk ,
	Stefano Stabellini ,
	"linux-kernel@vger.kernel.org" ,
	Russell King ,
	"linux-arm-kernel@lists.infradead.org"
	
Subject: Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 10 Oct 2012, Ian Campbell wrote:
> On Wed, 2012-10-10 at 15:47 +0100, Stefano Stabellini wrote:
> > On Wed, 10 Oct 2012, Ian Campbell wrote:
> > > On Tue, 2012-10-09 at 19:21 +0100, Arnd Bergmann wrote:
> > > > On Tuesday 09 October 2012, Stefano Stabellini wrote:
> > > > > >  config XEN
> > > > > >       bool "Xen guest support on ARM (EXPERIMENTAL)"
> > > > > >       depends on EXPERIMENTAL && ARM && OF
> > > > > > +     depends on !CPU_V6
> > > > > >       help
> > > > > >         Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
> > > > > 
> > > > > Considering that we rely on the virtualization extensions, this one can
> > > > > be:
> > > > > 
> > > > >     depends on CPU_V7
> > > > > 
> > > > > The rest looks fine. I can submit a second patch to change !CPU_V6 into
> > > > > CPU_V7 later, if you prefer.
> > > > 
> > > > CPU_V6 and CPU_V7 are not exclusive, I saw the problem when building a
> > > > combined kernel for both V6 and V7. The code also needs to depend on ARMv7
> > > > with virtualization extensions, but that is a different issue. We don't
> > > > actually have a configuration symbol for that yet, as far as I can tell.
> > > 
> > > I don't think the guest kernels (including dom0) need the extensions to
> > > run under Xen, they are only need by Xen itself. The guests should just
> > > see a relatively normal v7 processor. 
> > > 
> > > Stefano, does that sound right?
> > 
> > Keep in mind that we are using HVC to issue hypercalls, and HVC has been
> > introduced with the virtualization extensions, if I am not mistaken.
> 
> I think we can ignore that in this context since it is only used by bits
> which are already virtualisation aware -- i.e. you wouldn't want to add
> it to the Kconfig as a dependency for Xen.

Considering that ARM CPU_V* symbols are not mutually exclusive, if Linux
had a CPU_V7_VIRTEXT symbol I don't see why we shouldn't add it to our
list of dependencies. It is more accurate than CPU_V7 after all.

But I don't think that it is necessary to introduce one now only for
Xen, because like you said, we only need HVC and that is only used in
virtualization aware code.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 16:02:21 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 16:02:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLyjP-0002z5-Am; Wed, 10 Oct 2012 16:01:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLyjN-0002yx-MO
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 16:01:57 +0000
Received: from [85.158.137.99:17314] by server-4.bemta-3.messagelabs.com id
	89/87-01405-4FB95705; Wed, 10 Oct 2012 16:01:56 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1349884913!15928627!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM3MzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9659 invoked from network); 10 Oct 2012 16:01:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 16:01:56 -0000
X-IronPort-AV: E=Sophos;i="4.80,565,1344211200"; d="scan'208";a="15080299"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 16:01:43 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 10 Oct 2012 17:01:43 +0100
Date: Wed, 10 Oct 2012 17:01:26 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1349880826.10070.41.camel@zakaz.uk.xensource.com>
Message-ID: 
References: <1349796183-30648-1-git-send-email-arnd@arndb.de>
	<1349796183-30648-6-git-send-email-arnd@arndb.de>
	
	<201210091821.27818.arnd@arndb.de>
	<1349855687.6952.75.camel@dagon.hellion.org.uk>
	
	<1349880826.10070.41.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge ,
	"xen-devel@lists.xensource.com" ,
	Arnd Bergmann ,
	Konrad Rzeszutek Wilk ,
	Stefano Stabellini ,
	"linux-kernel@vger.kernel.org" ,
	Russell King ,
	"linux-arm-kernel@lists.infradead.org"
	
Subject: Re: [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 10 Oct 2012, Ian Campbell wrote:
> On Wed, 2012-10-10 at 15:47 +0100, Stefano Stabellini wrote:
> > On Wed, 10 Oct 2012, Ian Campbell wrote:
> > > On Tue, 2012-10-09 at 19:21 +0100, Arnd Bergmann wrote:
> > > > On Tuesday 09 October 2012, Stefano Stabellini wrote:
> > > > > >  config XEN
> > > > > >       bool "Xen guest support on ARM (EXPERIMENTAL)"
> > > > > >       depends on EXPERIMENTAL && ARM && OF
> > > > > > +     depends on !CPU_V6
> > > > > >       help
> > > > > >         Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
> > > > > 
> > > > > Considering that we rely on the virtualization extensions, this one can
> > > > > be:
> > > > > 
> > > > >     depends on CPU_V7
> > > > > 
> > > > > The rest looks fine. I can submit a second patch to change !CPU_V6 into
> > > > > CPU_V7 later, if you prefer.
> > > > 
> > > > CPU_V6 and CPU_V7 are not exclusive, I saw the problem when building a
> > > > combined kernel for both V6 and V7. The code also needs to depend on ARMv7
> > > > with virtualization extensions, but that is a different issue. We don't
> > > > actually have a configuration symbol for that yet, as far as I can tell.
> > > 
> > > I don't think the guest kernels (including dom0) need the extensions to
> > > run under Xen, they are only need by Xen itself. The guests should just
> > > see a relatively normal v7 processor. 
> > > 
> > > Stefano, does that sound right?
> > 
> > Keep in mind that we are using HVC to issue hypercalls, and HVC has been
> > introduced with the virtualization extensions, if I am not mistaken.
> 
> I think we can ignore that in this context since it is only used by bits
> which are already virtualisation aware -- i.e. you wouldn't want to add
> it to the Kconfig as a dependency for Xen.

Considering that ARM CPU_V* symbols are not mutually exclusive, if Linux
had a CPU_V7_VIRTEXT symbol I don't see why we shouldn't add it to our
list of dependencies. It is more accurate than CPU_V7 after all.

But I don't think that it is necessary to introduce one now only for
Xen, because like you said, we only need HVC and that is only used in
virtualization aware code.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 16:03:20 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 16:03:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLykR-00033l-Pl; Wed, 10 Oct 2012 16:03:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLykP-00033X-FE
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 16:03:02 +0000
Received: from [85.158.138.51:48397] by server-15.bemta-3.messagelabs.com id
	55/F4-10261-43C95705; Wed, 10 Oct 2012 16:03:00 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-10.tower-174.messagelabs.com!1349884976!26258743!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31003 invoked from network); 10 Oct 2012 16:02:56 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-10.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Oct 2012 16:02:56 -0000
Received: from 50-66-ftth.onsneteindhoven.nl ([88.159.66.50]:59411
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TLyli-0008Bb-6g; Wed, 10 Oct 2012 18:04:22 +0200
Date: Wed, 10 Oct 2012 18:02:53 +0200
From: Sander Eikelenboom 
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1786005637.20121010180253@eikelenboom.it>
To: xen-devel 
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------08613C0C31EE607B1"
Cc: Ian Campbell 
Subject: [Xen-devel] xen-unstable: HVM start memory_map:add
	memory_map:remove cycle
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

------------08613C0C31EE607B1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Ian,

When i start a HVM guest i get this cycle of adding removing adding removing and finally adding ... for some memory ranges during the start of the guest.
I don't know if it's intentionally, but it seems kind of strange .. :

(XEN) [2012-10-10 15:17:54] memory_map:add: dom16 gfn=f3028 mfn=f9fff nr=1
(XEN) [2012-10-10 15:17:54] memory_map:remove: dom16 gfn=f3028 mfn=f9fff nr=1
(XEN) [2012-10-10 15:17:54] memory_map:add: dom16 gfn=f3028 mfn=f9fff nr=1
(XEN) [2012-10-10 15:17:54] memory_map:remove: dom16 gfn=f3028 mfn=f9fff nr=1
(XEN) [2012-10-10 15:17:54] memory_map:add: dom16 gfn=f3028 mfn=f9fff nr=1
(XEN) [2012-10-10 15:17:54] memory_map:remove: dom16 gfn=f3028 mfn=f9fff nr=1
(XEN) [2012-10-10 15:17:54] memory_map:add: dom16 gfn=f3028 mfn=f9fff nr=1
(XEN) [2012-10-10 15:17:54] memory_map:remove: dom16 gfn=f3028 mfn=f9fff nr=1
(XEN) [2012-10-10 15:17:54] memory_map:add: dom16 gfn=f3028 mfn=f9fff nr=1
(XEN) [2012-10-10 15:17:54] memory_map:remove: dom16 gfn=f3028 mfn=f9fff nr=1
(XEN) [2012-10-10 15:17:54] memory_map:add: dom16 gfn=f3028 mfn=f9fff nr=1
(XEN) [2012-10-10 15:17:54] memory_map:remove: dom16 gfn=f3028 mfn=f9fff nr=1
(XEN) [2012-10-10 15:17:54] memory_map:add: dom16 gfn=f3028 mfn=f9fff nr=1


xl dmesg attached

--

Sander
------------08613C0C31EE607B1
Content-Type: text/plain;
 name="xl-dmesg.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="xl-dmesg.txt"

IF9fICBfXyAgICAgICAgICAgIF8gIF8gICAgX19fX18gICAgICAgICAgICAgICAgICAgIF8g
ICAgICAgIF8gICAgIF8gICAgICANCiBcIFwvIC9fX18gXyBfXyAgIHwgfHwgfCAgfF9fXyAv
ICAgIF8gICBfIF8gX18gIF9fX3wgfF8gX18gX3wgfF9fIHwgfCBfX18gDQogIFwgIC8vIF8g
XCAnXyBcICB8IHx8IHxfICAgfF8gXCBfX3wgfCB8IHwgJ18gXC8gX198IF9fLyBfYCB8ICdf
IFx8IHwvIF8gXA0KICAvICBcICBfXy8gfCB8IHwgfF9fICAgX3wgX19fKSB8X198IHxffCB8
IHwgfCBcX18gXCB8fCAoX3wgfCB8XykgfCB8ICBfXy8NCiAvXy9cX1xfX198X3wgfF98ICAg
IHxffChfKV9fX18vICAgIFxfXyxffF98IHxffF9fXy9cX19cX18sX3xfLl9fL3xffFxfX198
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIA0KKFhFTikgWGVuIHZlcnNpb24gNC4zLXVuc3RhYmxl
IChyb290QGR5bmRucy5vcmcpIChnY2MgKERlYmlhbiA0LjQuNS04KSA0LjQuNSkgV2VkIE9j
dCAgMyAxMTo0NTo0NyBDRVNUIDIwMTINCihYRU4pIExhdGVzdCBDaGFuZ2VTZXQ6IFR1ZSBP
Y3QgMDIgMTI6MTQ6MDAgMjAxMiArMDIwMCAyNTk3NTo4N2JmOTlmYWQ3YTkNCihYRU4pIEJv
b3Rsb2FkZXI6IEdSVUIgMS45OCsyMDEwMDgwNC0xNCtzcXVlZXplMQ0KKFhFTikgQ29tbWFu
ZCBsaW5lOiBkb20wX21lbT0xMDI0TSxtYXg6MTAyNE0gbG9nbHZsPWFsbCBsb2dsdmxfZ3Vl
c3Q9YWxsIGNvbnNvbGVfdGltZXN0YW1wcyB2Z2E9Z2Z4LTEyODB4MTAyNHgzMiBjcHVpZGxl
IGNwdWZyZXE9eGVuIHhzYXZlPW9mZiBub3JlYm9vdCBkZWJ1ZyBsYXBpYz1kZWJ1ZyBhcGlj
X3ZlcmJvc2l0eT1kZWJ1ZyBhcGljPWRlYnVnIGlvbW11PW9uLHZlcmJvc2UsZGVidWcsYW1k
LWlvbW11LWRlYnVnIGNvbTE9Mzg0MDAsOG4xIGNvbnNvbGU9dmdhLGNvbTENCihYRU4pIFZp
ZGVvIGluZm9ybWF0aW9uOg0KKFhFTikgIFZHQSBpcyBncmFwaGljcyBtb2RlIDEyODB4MTAy
NCwgMzIgYnBwDQooWEVOKSAgVkJFL0REQyBtZXRob2RzOiBWMjsgRURJRCB0cmFuc2ZlciB0
aW1lOiAxIHNlY29uZHMNCihYRU4pIERpc2MgaW5mb3JtYXRpb246DQooWEVOKSAgRm91bmQg
MiBNQlIgc2lnbmF0dXJlcw0KKFhFTikgIEZvdW5kIDIgRUREIGluZm9ybWF0aW9uIHN0cnVj
dHVyZXMNCihYRU4pIFhlbi1lODIwIFJBTSBtYXA6DQooWEVOKSAgMDAwMDAwMDAwMDAwMDAw
MCAtIDAwMDAwMDAwMDAwOWYwMDAgKHVzYWJsZSkNCihYRU4pICAwMDAwMDAwMDAwMDlmMDAw
IC0gMDAwMDAwMDAwMDBhMDAwMCAocmVzZXJ2ZWQpDQooWEVOKSAgMDAwMDAwMDAwMDBlNDAw
MCAtIDAwMDAwMDAwMDAxMDAwMDAgKHJlc2VydmVkKQ0KKFhFTikgIDAwMDAwMDAwMDAxMDAw
MDAgLSAwMDAwMDAwMGFmZjkwMDAwICh1c2FibGUpDQooWEVOKSAgMDAwMDAwMDBhZmY5MDAw
MCAtIDAwMDAwMDAwYWZmOWUwMDAgKEFDUEkgZGF0YSkNCihYRU4pICAwMDAwMDAwMGFmZjll
MDAwIC0gMDAwMDAwMDBhZmZlMDAwMCAoQUNQSSBOVlMpDQooWEVOKSAgMDAwMDAwMDBhZmZl
MDAwMCAtIDAwMDAwMDAwYjAwMDAwMDAgKHJlc2VydmVkKQ0KKFhFTikgIDAwMDAwMDAwZmZl
MDAwMDAgLSAwMDAwMDAwMTAwMDAwMDAwIChyZXNlcnZlZCkNCihYRU4pICAwMDAwMDAwMTAw
MDAwMDAwIC0gMDAwMDAwMDI1MDAwMDAwMCAodXNhYmxlKQ0KKFhFTikgQUNQSTogUlNEUCAw
MDBGQjEwMCwgMDAxNCAocjAgQUNQSUFNKQ0KKFhFTikgQUNQSTogUlNEVCBBRkY5MDAwMCwg
MDA0OCAocjEgTVNJICAgIE9FTVNMSUMgIDIwMTAwOTEzIE1TRlQgICAgICAgOTcpDQooWEVO
KSBBQ1BJOiBGQUNQIEFGRjkwMjAwLCAwMDg0IChyMSA3NjQwTVMgQTc2NDAxMDAgMjAxMDA5
MTMgTVNGVCAgICAgICA5NykNCihYRU4pIEFDUEk6IERTRFQgQUZGOTA1RTAsIDk0MjcgKHIx
ICBBNzY0MCBBNzY0MDEwMCAgICAgIDEwMCBJTlRMIDIwMDUxMTE3KQ0KKFhFTikgQUNQSTog
RkFDUyBBRkY5RTAwMCwgMDA0MA0KKFhFTikgQUNQSTogQVBJQyBBRkY5MDM5MCwgMDA4OCAo
cjEgNzY0ME1TIEE3NjQwMTAwIDIwMTAwOTEzIE1TRlQgICAgICAgOTcpDQooWEVOKSBBQ1BJ
OiBNQ0ZHIEFGRjkwNDIwLCAwMDNDIChyMSA3NjQwTVMgT0VNTUNGRyAgMjAxMDA5MTMgTVNG
VCAgICAgICA5NykNCihYRU4pIEFDUEk6IFNMSUMgQUZGOTA0NjAsIDAxNzYgKHIxIE1TSSAg
ICBPRU1TTElDICAyMDEwMDkxMyBNU0ZUICAgICAgIDk3KQ0KKFhFTikgQUNQSTogT0VNQiBB
RkY5RTA0MCwgMDA3MiAocjEgNzY0ME1TIEE3NjQwMTAwIDIwMTAwOTEzIE1TRlQgICAgICAg
OTcpDQooWEVOKSBBQ1BJOiBTUkFUIEFGRjlBNUUwLCAwMTA4IChyMyBBTUQgICAgRkFNX0Zf
MTAgICAgICAgIDIgQU1EICAgICAgICAgMSkNCihYRU4pIEFDUEk6IEhQRVQgQUZGOUE2RjAs
IDAwMzggKHIxIDc2NDBNUyBPRU1IUEVUICAyMDEwMDkxMyBNU0ZUICAgICAgIDk3KQ0KKFhF
TikgQUNQSTogSVZSUyBBRkY5QTczMCwgMDBGOCAocjEgIEFNRCAgICAgUkQ4OTBTICAgMjAy
MDMxIEFNRCAgICAgICAgIDApDQooWEVOKSBBQ1BJOiBTU0RUIEFGRjlBODMwLCAwREE0IChy
MSBBIE0gSSAgUE9XRVJOT1cgICAgICAgIDEgQU1EICAgICAgICAgMSkNCihYRU4pIFN5c3Rl
bSBSQU06IDgxOTFNQiAoODM4Nzc3MmtCKQ0KKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyAw
IC0+IE5vZGUgMA0KKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyAxIC0+IE5vZGUgMA0KKFhF
TikgU1JBVDogUFhNIDAgLT4gQVBJQyAyIC0+IE5vZGUgMA0KKFhFTikgU1JBVDogUFhNIDAg
LT4gQVBJQyAzIC0+IE5vZGUgMA0KKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyA0IC0+IE5v
ZGUgMA0KKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyA1IC0+IE5vZGUgMA0KKFhFTikgU1JB
VDogTm9kZSAwIFBYTSAwIDAtYTAwMDANCihYRU4pIFNSQVQ6IE5vZGUgMCBQWE0gMCAxMDAw
MDAtYjAwMDAwMDANCihYRU4pIFNSQVQ6IE5vZGUgMCBQWE0gMCAxMDAwMDAwMDAtMjUwMDAw
MDAwDQooWEVOKSBOVU1BOiBBbGxvY2F0ZWQgbWVtbm9kZW1hcCBmcm9tIDI0ZGMyYTAwMCAt
IDI0ZGMyZDAwMA0KKFhFTikgTlVNQTogVXNpbmcgOCBmb3IgdGhlIGhhc2ggc2hpZnQuDQoo
WEVOKSBEb21haW4gaGVhcCBpbml0aWFsaXNlZA0KKFhFTikgdmVzYWZiOiBmcmFtZWJ1ZmZl
ciBhdCAweGZiMDAwMDAwLCBtYXBwZWQgdG8gMHhmZmZmODJjMDAwMDAwMDAwLCB1c2luZyA2
MTQ0aywgdG90YWwgMTQzMzZrDQooWEVOKSB2ZXNhZmI6IG1vZGUgaXMgMTI4MHgxMDI0eDMy
LCBsaW5lbGVuZ3RoPTUxMjAsIGZvbnQgOHgxNg0KKFhFTikgdmVzYWZiOiBUcnVlY29sb3I6
IHNpemU9ODo4Ojg6OCwgc2hpZnQ9MjQ6MTY6ODowDQooWEVOKSBmb3VuZCBTTVAgTVAtdGFi
bGUgYXQgMDAwZmY3ODANCihYRU4pIERNSSBwcmVzZW50Lg0KKFhFTikgQVBJQyBib290IHN0
YXRlIGlzICd4YXBpYycNCihYRU4pIFVzaW5nIEFQSUMgZHJpdmVyIGRlZmF1bHQNCihYRU4p
IEFDUEk6IFBNLVRpbWVyIElPIFBvcnQ6IDB4ODA4DQooWEVOKSBBQ1BJOiBBQ1BJIFNMRUVQ
IElORk86IHBtMXhfY250WzgwNCwwXSwgcG0xeF9ldnRbODAwLDBdDQooWEVOKSBBQ1BJOiAg
ICAgICAgICAgICAgICAgIHdha2V1cF92ZWNbYWZmOWUwMGNdLCB2ZWNfc2l6ZVsyMF0NCihY
RU4pIEFDUEk6IExvY2FsIEFQSUMgYWRkcmVzcyAweGZlZTAwMDAwDQooWEVOKSBBQ1BJOiBM
QVBJQyAoYWNwaV9pZFsweDAxXSBsYXBpY19pZFsweDAwXSBlbmFibGVkKQ0KKFhFTikgUHJv
Y2Vzc29yICMwIDA6MTAgQVBJQyB2ZXJzaW9uIDE2DQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNw
aV9pZFsweDAyXSBsYXBpY19pZFsweDAxXSBlbmFibGVkKQ0KKFhFTikgUHJvY2Vzc29yICMx
IDA6MTAgQVBJQyB2ZXJzaW9uIDE2DQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAz
XSBsYXBpY19pZFsweDAyXSBlbmFibGVkKQ0KKFhFTikgUHJvY2Vzc29yICMyIDA6MTAgQVBJ
QyB2ZXJzaW9uIDE2DQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA0XSBsYXBpY19p
ZFsweDAzXSBlbmFibGVkKQ0KKFhFTikgUHJvY2Vzc29yICMzIDA6MTAgQVBJQyB2ZXJzaW9u
IDE2DQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA1XSBsYXBpY19pZFsweDA0XSBl
bmFibGVkKQ0KKFhFTikgUHJvY2Vzc29yICM0IDA6MTAgQVBJQyB2ZXJzaW9uIDE2DQooWEVO
KSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA2XSBsYXBpY19pZFsweDA1XSBlbmFibGVkKQ0K
KFhFTikgUHJvY2Vzc29yICM1IDA6MTAgQVBJQyB2ZXJzaW9uIDE2DQooWEVOKSBBQ1BJOiBJ
T0FQSUMgKGlkWzB4MDZdIGFkZHJlc3NbMHhmZWMwMDAwMF0gZ3NpX2Jhc2VbMF0pDQooWEVO
KSBJT0FQSUNbMF06IGFwaWNfaWQgNiwgdmVyc2lvbiAzMywgYWRkcmVzcyAweGZlYzAwMDAw
LCBHU0kgMC0yMw0KKFhFTikgQUNQSTogSU9BUElDIChpZFsweDA3XSBhZGRyZXNzWzB4ZmVj
MjAwMDBdIGdzaV9iYXNlWzI0XSkNCihYRU4pIElPQVBJQ1sxXTogYXBpY19pZCA3LCB2ZXJz
aW9uIDMzLCBhZGRyZXNzIDB4ZmVjMjAwMDAsIEdTSSAyNC01NQ0KKFhFTikgQUNQSTogSU5U
X1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEgMCBnbG9iYWxfaXJxIDIgZGZsIGRmbCkNCihYRU4p
IEFDUEk6IElOVF9TUkNfT1ZSIChidXMgMCBidXNfaXJxIDkgZ2xvYmFsX2lycSA5IGxvdyBs
ZXZlbCkNCihYRU4pIEFDUEk6IElSUTAgdXNlZCBieSBvdmVycmlkZS4NCihYRU4pIEFDUEk6
IElSUTIgdXNlZCBieSBvdmVycmlkZS4NCihYRU4pIEFDUEk6IElSUTkgdXNlZCBieSBvdmVy
cmlkZS4NCihYRU4pIEVuYWJsaW5nIEFQSUMgbW9kZTogIEZsYXQuICBVc2luZyAyIEkvTyBB
UElDcw0KKFhFTikgQUNQSTogSFBFVCBpZDogMHg4MzAwIGJhc2U6IDB4ZmVkMDAwMDANCihY
RU4pIFRhYmxlIGlzIG5vdCBmb3VuZCENCihYRU4pIFVzaW5nIEFDUEkgKE1BRFQpIGZvciBT
TVAgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbg0KKFhFTikgU01QOiBBbGxvd2luZyA2IENQ
VXMgKDAgaG90cGx1ZyBDUFVzKQ0KKFhFTikgbWFwcGVkIEFQSUMgdG8gZmZmZjgyYzNmZmRm
YjAwMCAoZmVlMDAwMDApDQooWEVOKSBtYXBwZWQgSU9BUElDIHRvIGZmZmY4MmMzZmZkZmEw
MDAgKGZlYzAwMDAwKQ0KKFhFTikgbWFwcGVkIElPQVBJQyB0byBmZmZmODJjM2ZmZGY5MDAw
IChmZWMyMDAwMCkNCihYRU4pIElSUSBsaW1pdHM6IDU2IEdTSSwgMTExMiBNU0kvTVNJLVgN
CihYRU4pIFVzaW5nIHNjaGVkdWxlcjogU01QIENyZWRpdCBTY2hlZHVsZXIgKGNyZWRpdCkN
CihYRU4pIERldGVjdGVkIDMyMDAuMTgwIE1IeiBwcm9jZXNzb3IuDQooWEVOKSBJbml0aW5n
IG1lbW9yeSBzaGFyaW5nLg0KKFhFTikgQU1EIEZhbTEwaCBtYWNoaW5lIGNoZWNrIHJlcG9y
dGluZyBlbmFibGVkDQooWEVOKSBQQ0k6IE1DRkcgY29uZmlndXJhdGlvbiAwOiBiYXNlIGUw
MDAwMDAwIHNlZ21lbnQgMDAwMCBidXNlcyAwMCAtIGZmDQooWEVOKSBQQ0k6IE5vdCB1c2lu
ZyBNQ0ZHIGZvciBzZWdtZW50IDAwMDAgYnVzIDAwLWZmDQooWEVOKSBBTUQtVmk6IEZvdW5k
IE1TSSBjYXBhYmlsaXR5IGJsb2NrIGF0IDB4NTQNCihYRU4pIEFNRC1WaTogQUNQSSBUYWJs
ZToNCihYRU4pIEFNRC1WaTogIFNpZ25hdHVyZSBJVlJTDQooWEVOKSBBTUQtVmk6ICBMZW5n
dGggMHhmOA0KKFhFTikgQU1ELVZpOiAgUmV2aXNpb24gMHgxDQooWEVOKSBBTUQtVmk6ICBD
aGVja1N1bSAweDk4DQooWEVOKSBBTUQtVmk6ICBPRU1fSWQgQU1EICANCihYRU4pIEFNRC1W
aTogIE9FTV9UYWJsZV9JZCBSRDg5MFMNCihYRU4pIEFNRC1WaTogIE9FTV9SZXZpc2lvbiAw
eDIwMjAzMQ0KKFhFTikgQU1ELVZpOiAgQ3JlYXRvcl9JZCBBTUQgDQooWEVOKSBBTUQtVmk6
ICBDcmVhdG9yX1JldmlzaW9uIDANCihYRU4pIEFNRC1WaTogSVZSUyBCbG9jazoNCihYRU4p
IEFNRC1WaTogIFR5cGUgMHgxMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgzZQ0KKFhFTikg
QU1ELVZpOiAgTGVuZ3RoIDB4YzgNCihYRU4pIEFNRC1WaTogIERldl9JZCAweDINCihYRU4p
IEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mw0K
KFhFTikgQU1ELVZpOiAgRGV2X0lkIDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDANCihYRU4p
IEFNRC1WaTogIERldl9JZCBSYW5nZTogMCAtPiAweDINCihYRU4pIEFNRC1WaTogSVZIRCBE
ZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAg
RGV2X0lkIDB4MTANCihYRU4pIEFNRC1WaTogIEZsYWdzIDANCihYRU4pIEFNRC1WaTogSVZI
RCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZp
OiAgRGV2X0lkIDB4YTAwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAwDQooWEVOKSBBTUQtVmk6
IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFN
RC1WaTogIERldl9JZCAweDE4DQooWEVOKSBBTUQtVmk6ICBGbGFncyAwDQooWEVOKSBBTUQt
Vmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDMNCihYRU4p
IEFNRC1WaTogIERldl9JZCAweDkwMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMA0KKFhFTikg
QU1ELVZpOiAgRGV2X0lkIFJhbmdlOiAweDkwMCAtPiAweDkwNw0KKFhFTikgQU1ELVZpOiBJ
VkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQt
Vmk6ICBEZXZfSWQgMHgyOA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMA0KKFhFTikgQU1ELVZp
OiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBB
TUQtVmk6ICBEZXZfSWQgMHg4MDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDANCihYRU4pIEFN
RC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhF
TikgQU1ELVZpOiAgRGV2X0lkIDB4MzANCihYRU4pIEFNRC1WaTogIEZsYWdzIDANCihYRU4p
IEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0K
KFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4NzAwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAwDQoo
WEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAw
eDINCihYRU4pIEFNRC1WaTogIERldl9JZCAweDUwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAw
DQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlw
ZSAweDINCihYRU4pIEFNRC1WaTogIERldl9JZCAweDYwMA0KKFhFTikgQU1ELVZpOiAgRmxh
Z3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTog
IFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHg1OA0KKFhFTikgQU1ELVZpOiAg
RmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1W
aTogIFR5cGUgMHgzDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHg1MDANCihYRU4pIEFNRC1W
aTogIEZsYWdzIDANCihYRU4pIEFNRC1WaTogIERldl9JZCBSYW5nZTogMHg1MDAgLT4gMHg1
MDENCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBU
eXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4NjgNCihYRU4pIEFNRC1WaTogIEZs
YWdzIDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6
ICBUeXBlIDB4Mw0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4NDAwDQooWEVOKSBBTUQtVmk6
ICBGbGFncyAwDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4NDAwIC0+IDB4NDA3
DQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlw
ZSAweDINCihYRU4pIEFNRC1WaTogIERldl9JZCAweDg4DQooWEVOKSBBTUQtVmk6ICBGbGFn
cyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAg
VHlwZSAweDMNCihYRU4pIEFNRC1WaTogIERldl9JZCAweDkwDQooWEVOKSBBTUQtVmk6ICBG
bGFncyAwDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4OTAgLT4gMHg5Mg0KKFhF
TikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgz
DQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHg5OA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMA0K
KFhFTikgQU1ELVZpOiAgRGV2X0lkIFJhbmdlOiAweDk4IC0+IDB4OWENCihYRU4pIEFNRC1W
aTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikg
QU1ELVZpOiAgRGV2X0lkIDB4YTANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4ZDcNCihYRU4p
IEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0K
KFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4YTENCihYRU4pIEFNRC1WaTogIEZsYWdzIDANCihY
RU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4
Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4YTINCihYRU4pIEFNRC1WaTogIEZsYWdzIDAN
CihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBl
IDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4YTMNCihYRU4pIEFNRC1WaTogIEZsYWdz
IDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBU
eXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4YTQNCihYRU4pIEFNRC1WaTogIEZs
YWdzIDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6
ICBUeXBlIDANCihYRU4pIEFNRC1WaTogIERldl9JZCAwDQooWEVOKSBBTUQtVmk6ICBGbGFn
cyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgc3B1cmlvdXMg
ODI1OUEgaW50ZXJydXB0OiBJUlE3Lg0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDQzDQooWEVO
KSBBTUQtVmk6ICBEZXZfSWQgMHgzMDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDANCihYRU4p
IEFNRC1WaTogIERldl9JZCBSYW5nZTogMHgzMDAgLT4gMHgzZmYNCihYRU4pIEFNRC1WaTog
IERldl9JZCBBbGlhczogMHhhNA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToN
CihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHhhNQ0K
KFhFTikgQU1ELVZpOiAgRmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRy
eToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHhh
OA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBF
bnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQg
MHhhOQ0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmlj
ZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZf
SWQgMHgxMDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDANCihYRU4pIEFNRC1WaTogSVZIRCBE
ZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mw0KKFhFTikgQU1ELVZpOiAg
RGV2X0lkIDB4YjANCihYRU4pIEFNRC1WaTogIEZsYWdzIDANCihYRU4pIEFNRC1WaTogIERl
dl9JZCBSYW5nZTogMHhiMCAtPiAweGIyDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVu
dHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAwDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMA0K
KFhFTikgQU1ELVZpOiAgRmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRy
eToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHg0OA0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDAN
CihYRU4pIEFNRC1WaTogIEZsYWdzIDB4ZDcNCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2Ug
RW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4NDgNCihYRU4pIEFNRC1WaTogIERldl9J
ZCAwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAwDQooWEVOKSBBTUQtVmk6IElPTU1VIDAgRW5h
YmxlZC4NCihYRU4pIEFNRC1WaTogRW5hYmxpbmcgZ2xvYmFsIHZlY3RvciBtYXANCihYRU4p
IEkvTyB2aXJ0dWFsaXNhdGlvbiBlbmFibGVkDQooWEVOKSAgLSBEb20wIG1vZGU6IFJlbGF4
ZWQNCihYRU4pIEdldHRpbmcgVkVSU0lPTjogODAwNTAwMTANCihYRU4pIEdldHRpbmcgVkVS
U0lPTjogODAwNTAwMTANCihYRU4pIEdldHRpbmcgSUQ6IDANCihYRU4pIEdldHRpbmcgTFZU
MDogNzAwDQooWEVOKSBHZXR0aW5nIExWVDE6IDQwMA0KKFhFTikgZW5hYmxlZCBFeHRJTlQg
b24gQ1BVIzANCihYRU4pIEVTUiB2YWx1ZSBiZWZvcmUgZW5hYmxpbmcgdmVjdG9yOiAweDQg
IGFmdGVyOiAwDQooWEVOKSBFTkFCTElORyBJTy1BUElDIElSUXMNCihYRU4pICAtPiBVc2lu
ZyBuZXcgQUNLIG1ldGhvZA0KKFhFTikgaW5pdCBJT19BUElDIElSUXMNCihYRU4pICBJTy1B
UElDIChhcGljaWQtcGluKSA2LTAsIDYtMTYsIDYtMTcsIDYtMTgsIDYtMTksIDYtMjAsIDYt
MjEsIDYtMjIsIDYtMjMsIDctMCwgNy0xLCA3LTIsIDctMywgNy00LCA3LTUsIDctNiwgNy03
LCA3LTgsIDctOSwgNy0xMCwgNy0xMSwgNy0xMiwgNy0xMywgNy0xNCwgNy0xNSwgNy0xNiwg
Ny0xNywgNy0xOCwgNy0xOSwgNy0yMCwgNy0yMSwgNy0yMiwgNy0yMywgNy0yNCwgNy0yNSwg
Ny0yNiwgNy0yNywgNy0yOCwgNy0yOSwgNy0zMCwgNy0zMSBub3QgY29ubmVjdGVkLg0KKFhF
TikgLi5USU1FUjogdmVjdG9yPTB4RjAgYXBpYzE9MCBwaW4xPTIgYXBpYzI9LTEgcGluMj0t
MQ0KKFhFTikgbnVtYmVyIG9mIE1QIElSUSBzb3VyY2VzOiAxNS4NCihYRU4pIG51bWJlciBv
ZiBJTy1BUElDICM2IHJlZ2lzdGVyczogMjQuDQooWEVOKSBudW1iZXIgb2YgSU8tQVBJQyAj
NyByZWdpc3RlcnM6IDMyLg0KKFhFTikgdGVzdGluZyB0aGUgSU8gQVBJQy4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uDQooWEVOKSBJTyBBUElDICM2Li4uLi4uDQooWEVOKSAuLi4uIHJlZ2lz
dGVyICMwMDogMDYwMDAwMDANCihYRU4pIC4uLi4uLi4gICAgOiBwaHlzaWNhbCBBUElDIGlk
OiAwNg0KKFhFTikgLi4uLi4uLiAgICA6IERlbGl2ZXJ5IFR5cGU6IDANCihYRU4pIC4uLi4u
Li4gICAgOiBMVFMgICAgICAgICAgOiAwDQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMTogMDAx
NzgwMjENCihYRU4pIC4uLi4uLi4gICAgIDogbWF4IHJlZGlyZWN0aW9uIGVudHJpZXM6IDAw
MTcNCihYRU4pIC4uLi4uLi4gICAgIDogUFJRIGltcGxlbWVudGVkOiAxDQooWEVOKSAuLi4u
Li4uICAgICA6IElPIEFQSUMgdmVyc2lvbjogMDAyMQ0KKFhFTikgLi4uLiByZWdpc3RlciAj
MDI6IDA2MDAwMDAwDQooWEVOKSAuLi4uLi4uICAgICA6IGFyYml0cmF0aW9uOiAwNg0KKFhF
TikgLi4uLiByZWdpc3RlciAjMDM6IDA3MDAwMDAwDQooWEVOKSAuLi4uLi4uICAgICA6IEJv
b3QgRFQgICAgOiAwDQooWEVOKSAuLi4uIElSUSByZWRpcmVjdGlvbiB0YWJsZToNCihYRU4p
ICBOUiBMb2cgUGh5IE1hc2sgVHJpZyBJUlIgUG9sIFN0YXQgRGVzdCBEZWxpIFZlY3Q6ICAg
DQooWEVOKSAgMDAgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAw
MA0KKFhFTikgIDAxIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAg
MzANCihYRU4pICAwMiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAg
IEYwDQooWEVOKSAgMDMgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAg
ICAzOA0KKFhFTikgIDA0IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEg
ICAgRjENCihYRU4pICAwNSAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAx
ICAgIDQwDQooWEVOKSAgMDYgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAg
MSAgICA0OA0KKFhFTikgIDA3IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAg
IDEgICAgNTANCihYRU4pICAwOCAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAg
ICAxICAgIDU4DQooWEVOKSAgMDkgMDAxIDAxICAxICAgIDEgICAgMCAgIDEgICAwICAgIDEg
ICAgMSAgICA2MA0KKFhFTikgIDBhIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAx
ICAgIDEgICAgNjgNCihYRU4pICAwYiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAg
MSAgICAxICAgIDcwDQooWEVOKSAgMGMgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAg
IDEgICAgMSAgICA3OA0KKFhFTikgIDBkIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAg
ICAxICAgIDEgICAgODgNCihYRU4pICAwZSAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAg
ICAgMSAgICAxICAgIDkwDQooWEVOKSAgMGYgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAw
ICAgIDEgICAgMSAgICA5OA0KKFhFTikgIDEwIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAg
MCAgICAwICAgIDAgICAgMDANCihYRU4pICAxMSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAg
IDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMTIgMDAwIDAwICAxICAgIDAgICAgMCAgIDAg
ICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDEzIDAwMCAwMCAgMSAgICAwICAgIDAgICAw
ICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAxNCAwMDAgMDAgIDEgICAgMCAgICAwICAg
MCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMTUgMDAwIDAwICAxICAgIDAgICAgMCAg
IDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDE2IDAwMCAwMCAgMSAgICAwICAgIDAg
ICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAxNyAwMDAgMDAgIDEgICAgMCAgICAw
ICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSBJTyBBUElDICM3Li4uLi4uDQooWEVO
KSAuLi4uIHJlZ2lzdGVyICMwMDogMDcwMDAwMDANCihYRU4pIC4uLi4uLi4gICAgOiBwaHlz
aWNhbCBBUElDIGlkOiAwNw0KKFhFTikgLi4uLi4uLiAgICA6IERlbGl2ZXJ5IFR5cGU6IDAN
CihYRU4pIC4uLi4uLi4gICAgOiBMVFMgICAgICAgICAgOiAwDQooWEVOKSAuLi4uIHJlZ2lz
dGVyICMwMTogMDAxRjgwMjENCihYRU4pIC4uLi4uLi4gICAgIDogbWF4IHJlZGlyZWN0aW9u
IGVudHJpZXM6IDAwMUYNCihYRU4pIC4uLi4uLi4gICAgIDogUFJRIGltcGxlbWVudGVkOiAx
DQooWEVOKSAuLi4uLi4uICAgICA6IElPIEFQSUMgdmVyc2lvbjogMDAyMQ0KKFhFTikgLi4u
LiByZWdpc3RlciAjMDI6IDAwMDAwMDAwDQooWEVOKSAuLi4uLi4uICAgICA6IGFyYml0cmF0
aW9uOiAwMA0KKFhFTikgLi4uLiBJUlEgcmVkaXJlY3Rpb24gdGFibGU6DQooWEVOKSAgTlIg
TG9nIFBoeSBNYXNrIFRyaWcgSVJSIFBvbCBTdGF0IERlc3QgRGVsaSBWZWN0OiAgIA0KKFhF
TikgIDAwIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihY
RU4pICAwMSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQoo
WEVOKSAgMDIgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0K
KFhFTikgIDAzIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDAN
CihYRU4pICAwNCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAw
DQooWEVOKSAgMDUgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAw
MA0KKFhFTikgIDA2IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDANCihYRU4pICAwNyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwDQooWEVOKSAgMDggMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAg
ICAwMA0KKFhFTikgIDA5IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAg
ICAgMDANCihYRU4pICAwYSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAw
ICAgIDAwDQooWEVOKSAgMGIgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAg
MCAgICAwMA0KKFhFTikgIDBjIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAg
IDAgICAgMDANCihYRU4pICAwZCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAg
ICAwICAgIDAwDQooWEVOKSAgMGUgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAg
ICAgMCAgICAwMA0KKFhFTikgIDBmIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAw
ICAgIDAgICAgMDANCihYRU4pICAxMCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAg
MCAgICAwICAgIDAwDQooWEVOKSAgMTEgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAg
IDAgICAgMCAgICAwMA0KKFhFTikgIDEyIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAg
ICAwICAgIDAgICAgMDANCihYRU4pICAxMyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAg
ICAgMCAgICAwICAgIDAwDQooWEVOKSAgMTQgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAw
ICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDE1IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAg
MCAgICAwICAgIDAgICAgMDANCihYRU4pICAxNiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAg
IDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMTcgMDAwIDAwICAxICAgIDAgICAgMCAgIDAg
ICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDE4IDAwMCAwMCAgMSAgICAwICAgIDAgICAw
ICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAxOSAwMDAgMDAgIDEgICAgMCAgICAwICAg
MCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMWEgMDAwIDAwICAxICAgIDAgICAgMCAg
IDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDFiIDAwMCAwMCAgMSAgICAwICAgIDAg
ICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAxYyAwMDAgMDAgIDEgICAgMCAgICAw
ICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMWQgMDAwIDAwICAxICAgIDAgICAg
MCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDFlIDAwMCAwMCAgMSAgICAwICAg
IDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAxZiAwMDAgMDAgIDEgICAgMCAg
ICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSBVc2luZyB2ZWN0b3ItYmFzZWQg
aW5kZXhpbmcNCihYRU4pIElSUSB0byBwaW4gbWFwcGluZ3M6DQooWEVOKSBJUlEyNDAgLT4g
MDoyDQooWEVOKSBJUlE0OCAtPiAwOjENCihYRU4pIElSUTU2IC0+IDA6Mw0KKFhFTikgSVJR
MjQxIC0+IDA6NA0KKFhFTikgSVJRNjQgLT4gMDo1DQooWEVOKSBJUlE3MiAtPiAwOjYNCihY
RU4pIElSUTgwIC0+IDA6Nw0KKFhFTikgSVJRODggLT4gMDo4DQooWEVOKSBJUlE5NiAtPiAw
OjkNCihYRU4pIElSUTEwNCAtPiAwOjEwDQooWEVOKSBJUlExMTIgLT4gMDoxMQ0KKFhFTikg
SVJRMTIwIC0+IDA6MTINCihYRU4pIElSUTEzNiAtPiAwOjEzDQooWEVOKSBJUlExNDQgLT4g
MDoxNA0KKFhFTikgSVJRMTUyIC0+IDA6MTUNCihYRU4pIC4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLiBkb25lLg0KKFhFTikgVXNpbmcgbG9jYWwgQVBJQyB0aW1lciBp
bnRlcnJ1cHRzLg0KKFhFTikgY2FsaWJyYXRpbmcgQVBJQyB0aW1lciAuLi4NCihYRU4pIC4u
Li4uIENQVSBjbG9jayBzcGVlZCBpcyAzMjAwLjEyOTUgTUh6Lg0KKFhFTikgLi4uLi4gaG9z
dCBidXMgY2xvY2sgc3BlZWQgaXMgMjAwLjAwODAgTUh6Lg0KKFhFTikgLi4uLi4gYnVzX3Nj
YWxlID0gMHhjY2Q3DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxM10gUGxhdGZvcm0gdGlt
ZXIgaXMgMTQuMzE4TUh6IEhQRVQNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjEzOjEzXSBBbGxv
Y2F0ZWQgY29uc29sZSByaW5nIG9mIDY0IEtpQi4NCihYRU4pIFsyMDEyLTEwLTEwIDE1OjEz
OjEzXSBIVk06IEFTSURzIGVuYWJsZWQuDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxM10g
U1ZNOiBTdXBwb3J0ZWQgYWR2YW5jZWQgZmVhdHVyZXM6DQooWEVOKSBbMjAxMi0xMC0xMCAx
NToxMzoxM10gIC0gTmVzdGVkIFBhZ2UgVGFibGVzIChOUFQpDQooWEVOKSBbMjAxMi0xMC0x
MCAxNToxMzoxM10gIC0gTGFzdCBCcmFuY2ggUmVjb3JkIChMQlIpIFZpcnR1YWxpc2F0aW9u
DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxM10gIC0gTmV4dC1SSVAgU2F2ZWQgb24gI1ZN
RVhJVA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTM6MTNdICAtIFBhdXNlLUludGVyY2VwdCBG
aWx0ZXINCihYRU4pIFsyMDEyLTEwLTEwIDE1OjEzOjEzXSBIVk06IFNWTSBlbmFibGVkDQoo
WEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxM10gSFZNOiBIYXJkd2FyZSBBc3Npc3RlZCBQYWdp
bmcgKEhBUCkgZGV0ZWN0ZWQNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjEzOjEzXSBIVk06IEhB
UCBwYWdlIHNpemVzOiA0a0IsIDJNQiwgMUdCDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzox
Ml0gbWFza2VkIEV4dElOVCBvbiBDUFUjMQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTM6MTNd
IG1pY3JvY29kZTogY29sbGVjdF9jcHVfaW5mbzogcGF0Y2hfaWQ9MHgxMDAwMGJmDQooWEVO
KSBbMjAxMi0xMC0xMCAxNToxMzoxMl0gbWFza2VkIEV4dElOVCBvbiBDUFUjMg0KKFhFTikg
WzIwMTItMTAtMTAgMTU6MTM6MTNdIG1pY3JvY29kZTogY29sbGVjdF9jcHVfaW5mbzogcGF0
Y2hfaWQ9MHgxMDAwMGJmDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxMl0gbWFza2VkIEV4
dElOVCBvbiBDUFUjMw0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTM6MTNdIG1pY3JvY29kZTog
Y29sbGVjdF9jcHVfaW5mbzogcGF0Y2hfaWQ9MHgxMDAwMGJmDQooWEVOKSBbMjAxMi0xMC0x
MCAxNToxMzoxMl0gbWFza2VkIEV4dElOVCBvbiBDUFUjNA0KKFhFTikgWzIwMTItMTAtMTAg
MTU6MTM6MTNdIG1pY3JvY29kZTogY29sbGVjdF9jcHVfaW5mbzogcGF0Y2hfaWQ9MHgxMDAw
MGJmDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxMl0gbWFza2VkIEV4dElOVCBvbiBDUFUj
NQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTM6MTNdIEJyb3VnaHQgdXAgNiBDUFVzDQooWEVO
KSBbMjAxMi0xMC0xMCAxNToxMzoxM10gbWljcm9jb2RlOiBjb2xsZWN0X2NwdV9pbmZvOiBw
YXRjaF9pZD0weDEwMDAwYmYNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjEzOjEzXSBIUEVUJ3Mg
TVNJIG1vZGUgaGFzbid0IGJlZW4gc3VwcG9ydGVkIHdoZW4gSW50ZXJydXB0IFJlbWFwcGlu
ZyBpcyBlbmFibGVkLg0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTM6MTNdIEFDUEkgc2xlZXAg
bW9kZXM6IFMzDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxM10gTUNBOiBVc2UgaHcgdGhy
ZXNob2xkaW5nIHRvIGFkanVzdCBwb2xsaW5nIGZyZXF1ZW5jeQ0KKFhFTikgWzIwMTItMTAt
MTAgMTU6MTM6MTNdIG1jaGVja19wb2xsOiBNYWNoaW5lIGNoZWNrIHBvbGxpbmcgdGltZXIg
c3RhcnRlZC4NCihYRU4pIFsyMDEyLTEwLTEwIDE1OjEzOjEzXSBYZW5vcHJvZmlsZTogRmFp
bGVkIHRvIHNldHVwIElCUyBMVlQgb2Zmc2V0LCBJQlNDVEwgPSAweGZmZmZmZmZmDQooWEVO
KSBbMjAxMi0xMC0xMCAxNToxMzoxM10gKioqIExPQURJTkcgRE9NQUlOIDAgKioqDQooWEVO
KSBbMjAxMi0xMC0xMCAxNToxMzoxM10gZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9
MHgxMDAwMDAwIG1lbXN6PTB4YWYyMDAwDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxM10g
ZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgxYzAwMDAwIG1lbXN6PTB4Y2EwZTgN
CihYRU4pIFsyMDEyLTEwLTEwIDE1OjEzOjEzXSBlbGZfcGFyc2VfYmluYXJ5OiBwaGRyOiBw
YWRkcj0weDFjY2IwMDAgbWVtc3o9MHgxM2NjMA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTM6
MTNdIGVsZl9wYXJzZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4MWNkZjAwMCBtZW1zej0weGRl
NjAwMA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTM6MTNdIGVsZl9wYXJzZV9iaW5hcnk6IG1l
bW9yeTogMHgxMDAwMDAwIC0+IDB4MmFjNTAwMA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTM6
MTNdIGVsZl94ZW5fcGFyc2Vfbm90ZTogR1VFU1RfT1MgPSAibGludXgiDQooWEVOKSBbMjAx
Mi0xMC0xMCAxNToxMzoxM10gZWxmX3hlbl9wYXJzZV9ub3RlOiBHVUVTVF9WRVJTSU9OID0g
IjIuNiINCihYRU4pIFsyMDEyLTEwLTEwIDE1OjEzOjEzXSBlbGZfeGVuX3BhcnNlX25vdGU6
IFhFTl9WRVJTSU9OID0gInhlbi0zLjAiDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxM10g
ZWxmX3hlbl9wYXJzZV9ub3RlOiBWSVJUX0JBU0UgPSAweGZmZmZmZmZmODAwMDAwMDANCihY
RU4pIFsyMDEyLTEwLTEwIDE1OjEzOjEzXSBlbGZfeGVuX3BhcnNlX25vdGU6IEVOVFJZID0g
MHhmZmZmZmZmZjgxY2RmMjEwDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxM10gZWxmX3hl
bl9wYXJzZV9ub3RlOiBIWVBFUkNBTExfUEFHRSA9IDB4ZmZmZmZmZmY4MTAwMTAwMA0KKFhF
TikgWzIwMTItMTAtMTAgMTU6MTM6MTNdIGVsZl94ZW5fcGFyc2Vfbm90ZTogRkVBVFVSRVMg
PSAiIXdyaXRhYmxlX3BhZ2VfdGFibGVzfHBhZV9wZ2Rpcl9hYm92ZV80Z2IiDQooWEVOKSBb
MjAxMi0xMC0xMCAxNToxMzoxM10gZWxmX3hlbl9wYXJzZV9ub3RlOiBQQUVfTU9ERSA9ICJ5
ZXMiDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxM10gZWxmX3hlbl9wYXJzZV9ub3RlOiBM
T0FERVIgPSAiZ2VuZXJpYyINCihYRU4pIFsyMDEyLTEwLTEwIDE1OjEzOjEzXSBlbGZfeGVu
X3BhcnNlX25vdGU6IHVua25vd24geGVuIGVsZiBub3RlICgweGQpDQooWEVOKSBbMjAxMi0x
MC0xMCAxNToxMzoxM10gZWxmX3hlbl9wYXJzZV9ub3RlOiBTVVNQRU5EX0NBTkNFTCA9IDB4
MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTM6MTNdIGVsZl94ZW5fcGFyc2Vfbm90ZTogSFZf
U1RBUlRfTE9XID0gMHhmZmZmODAwMDAwMDAwMDAwDQooWEVOKSBbMjAxMi0xMC0xMCAxNTox
MzoxM10gZWxmX3hlbl9wYXJzZV9ub3RlOiBQQUREUl9PRkZTRVQgPSAweDANCihYRU4pIFsy
MDEyLTEwLTEwIDE1OjEzOjEzXSBlbGZfeGVuX2FkZHJfY2FsY19jaGVjazogYWRkcmVzc2Vz
Og0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTM6MTNdICAgICB2aXJ0X2Jhc2UgICAgICAgID0g
MHhmZmZmZmZmZjgwMDAwMDAwDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxM10gICAgIGVs
Zl9wYWRkcl9vZmZzZXQgPSAweDANCihYRU4pIFsyMDEyLTEwLTEwIDE1OjEzOjEzXSAgICAg
dmlydF9vZmZzZXQgICAgICA9IDB4ZmZmZmZmZmY4MDAwMDAwMA0KKFhFTikgWzIwMTItMTAt
MTAgMTU6MTM6MTNdICAgICB2aXJ0X2tzdGFydCAgICAgID0gMHhmZmZmZmZmZjgxMDAwMDAw
DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNF0gICAgIHZpcnRfa2VuZCAgICAgICAgPSAw
eGZmZmZmZmZmODJhYzUwMDANCihYRU4pIFsyMDEyLTEwLTEwIDE1OjEzOjE0XSAgICAgdmly
dF9lbnRyeSAgICAgICA9IDB4ZmZmZmZmZmY4MWNkZjIxMA0KKFhFTikgWzIwMTItMTAtMTAg
MTU6MTM6MTRdICAgICBwMm1fYmFzZSAgICAgICAgID0gMHhmZmZmZmZmZmZmZmZmZmZmDQoo
WEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNF0gIFhlbiAga2VybmVsOiA2NC1iaXQsIGxzYiwg
Y29tcGF0MzINCihYRU4pIFsyMDEyLTEwLTEwIDE1OjEzOjE0XSAgRG9tMCBrZXJuZWw6IDY0
LWJpdCwgUEFFLCBsc2IsIHBhZGRyIDB4MTAwMDAwMCAtPiAweDJhYzUwMDANCihYRU4pIFsy
MDEyLTEwLTEwIDE1OjEzOjE0XSBQSFlTSUNBTCBNRU1PUlkgQVJSQU5HRU1FTlQ6DQooWEVO
KSBbMjAxMi0xMC0xMCAxNToxMzoxNF0gIERvbTAgYWxsb2MuOiAgIDAwMDAwMDAyNDAwMDAw
MDAtPjAwMDAwMDAyNDQwMDAwMDAgKDI0MjQyOCBwYWdlcyB0byBiZSBhbGxvY2F0ZWQpDQoo
WEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNF0gIEluaXQuIHJhbWRpc2s6IDAwMDAwMDAyNGYy
ZmMwMDAtPjAwMDAwMDAyNGZmZmY4MDANCihYRU4pIFsyMDEyLTEwLTEwIDE1OjEzOjE0XSBW
SVJUVUFMIE1FTU9SWSBBUlJBTkdFTUVOVDoNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjEzOjE0
XSAgTG9hZGVkIGtlcm5lbDogZmZmZmZmZmY4MTAwMDAwMC0+ZmZmZmZmZmY4MmFjNTAwMA0K
KFhFTikgWzIwMTItMTAtMTAgMTU6MTM6MTRdICBJbml0LiByYW1kaXNrOiBmZmZmZmZmZjgy
YWM1MDAwLT5mZmZmZmZmZjgzN2M4ODAwDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNF0g
IFBoeXMtTWFjaCBtYXA6IGZmZmZmZmZmODM3YzkwMDAtPmZmZmZmZmZmODM5YzkwMDANCihY
RU4pIFsyMDEyLTEwLTEwIDE1OjEzOjE0XSAgU3RhcnQgaW5mbzogICAgZmZmZmZmZmY4Mzlj
OTAwMC0+ZmZmZmZmZmY4MzljOTRiNA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTM6MTRdICBQ
YWdlIHRhYmxlczogICBmZmZmZmZmZjgzOWNhMDAwLT5mZmZmZmZmZjgzOWViMDAwDQooWEVO
KSBbMjAxMi0xMC0xMCAxNToxMzoxNF0gIEJvb3Qgc3RhY2s6ICAgIGZmZmZmZmZmODM5ZWIw
MDAtPmZmZmZmZmZmODM5ZWMwMDANCihYRU4pIFsyMDEyLTEwLTEwIDE1OjEzOjE0XSAgVE9U
QUw6ICAgICAgICAgZmZmZmZmZmY4MDAwMDAwMC0+ZmZmZmZmZmY4M2MwMDAwMA0KKFhFTikg
WzIwMTItMTAtMTAgMTU6MTM6MTRdICBFTlRSWSBBRERSRVNTOiBmZmZmZmZmZjgxY2RmMjEw
DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNF0gRG9tMCBoYXMgbWF4aW11bSA2IFZDUFVz
DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNF0gZWxmX2xvYWRfYmluYXJ5OiBwaGRyIDAg
YXQgMHhmZmZmZmZmZjgxMDAwMDAwIC0+IDB4ZmZmZmZmZmY4MWFmMjAwMA0KKFhFTikgWzIw
MTItMTAtMTAgMTU6MTM6MTRdIGVsZl9sb2FkX2JpbmFyeTogcGhkciAxIGF0IDB4ZmZmZmZm
ZmY4MWMwMDAwMCAtPiAweGZmZmZmZmZmODFjY2EwZTgNCihYRU4pIFsyMDEyLTEwLTEwIDE1
OjEzOjE0XSBlbGZfbG9hZF9iaW5hcnk6IHBoZHIgMiBhdCAweGZmZmZmZmZmODFjY2IwMDAg
LT4gMHhmZmZmZmZmZjgxY2RlY2MwDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNF0gZWxm
X2xvYWRfYmluYXJ5OiBwaGRyIDMgYXQgMHhmZmZmZmZmZjgxY2RmMDAwIC0+IDB4ZmZmZmZm
ZmY4MWQ3ZjAwMA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTM6MTRdIEFNRC1WaTogU2V0dXAg
SS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDAsIHJvb3QgdGFibGUgPSAweDI0N2VkNDAw
MCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0xMC0xMCAxNTox
MzoxNF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgyLCBy
b290IHRhYmxlID0gMHgyNDdlZDQwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0K
KFhFTikgWzIwMTItMTAtMTAgMTU6MTM6MTRdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFi
bGU6IGRldmljZSBpZCA9IDB4MTAsIHJvb3QgdGFibGUgPSAweDI0N2VkNDAwMCwgZG9tYWlu
ID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNF0gQU1E
LVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgxOCwgcm9vdCB0YWJs
ZSA9IDB4MjQ3ZWQ0MDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsy
MDEyLTEwLTEwIDE1OjEzOjE0XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZp
Y2UgaWQgPSAweDI4LCByb290IHRhYmxlID0gMHgyNDdlZDQwMDAsIGRvbWFpbiA9IDAsIHBh
Z2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTM6MTRdIEFNRC1WaTogU2V0
dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MzAsIHJvb3QgdGFibGUgPSAweDI0
N2VkNDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0xMC0x
MCAxNToxMzoxNF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0g
MHg1MCwgcm9vdCB0YWJsZSA9IDB4MjQ3ZWQ0MDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9k
ZSA9IDMNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjEzOjE0XSBBTUQtVmk6IFNldHVwIEkvTyBw
YWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDU4LCByb290IHRhYmxlID0gMHgyNDdlZDQwMDAs
IGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTM6
MTRdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4NjgsIHJv
b3QgdGFibGUgPSAweDI0N2VkNDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQoo
WEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJs
ZTogZGV2aWNlIGlkID0gMHg4OCwgcm9vdCB0YWJsZSA9IDB4MjQ3ZWQ0MDAwLCBkb21haW4g
PSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjEzOjE0XSBBTUQt
Vmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDkwLCByb290IHRhYmxl
ID0gMHgyNDdlZDQwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIw
MTItMTAtMTAgMTU6MTM6MTRdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmlj
ZSBpZCA9IDB4OTIsIHJvb3QgdGFibGUgPSAweDI0N2VkNDAwMCwgZG9tYWluID0gMCwgcGFn
aW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNF0gQU1ELVZpOiBTZXR1
cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg5OCwgcm9vdCB0YWJsZSA9IDB4MjQ3
ZWQ0MDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTEwLTEw
IDE1OjEzOjE0XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAw
eDlhLCByb290IHRhYmxlID0gMHgyNDdlZDQwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2Rl
ID0gMw0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTM6MTRdIEFNRC1WaTogU2V0dXAgSS9PIHBh
Z2UgdGFibGU6IGRldmljZSBpZCA9IDB4YTAsIHJvb3QgdGFibGUgPSAweDI0N2VkNDAwMCwg
ZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzox
NF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhhMSwgcm9v
dCB0YWJsZSA9IDB4MjQ3ZWQ0MDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihY
RU4pIFsyMDEyLTEwLTEwIDE1OjEzOjE0XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxl
OiBkZXZpY2UgaWQgPSAweGEyLCByb290IHRhYmxlID0gMHgyNDdlZDQwMDAsIGRvbWFpbiA9
IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTM6MTRdIEFNRC1W
aTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4YTMsIHJvb3QgdGFibGUg
PSAweDI0N2VkNDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAx
Mi0xMC0xMCAxNToxMzoxNF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNl
IGlkID0gMHhhNCwgcm9vdCB0YWJsZSA9IDB4MjQ3ZWQ0MDAwLCBkb21haW4gPSAwLCBwYWdp
bmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjEzOjE0XSBBTUQtVmk6IFNldHVw
IEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGE1LCByb290IHRhYmxlID0gMHgyNDdl
ZDQwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMTAtMTAg
MTU6MTM6MTRdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4
YTgsIHJvb3QgdGFibGUgPSAweDI0N2VkNDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUg
PSAzDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNF0gQU1ELVZpOiBTZXR1cCBJL08gcGFn
ZSB0YWJsZTogZGV2aWNlIGlkID0gMHhiMCwgcm9vdCB0YWJsZSA9IDB4MjQ3ZWQ0MDAwLCBk
b21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjEzOjE0
XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGIyLCByb290
IHRhYmxlID0gMHgyNDdlZDQwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhF
TikgWzIwMTItMTAtMTAgMTU6MTM6MTRdIEFNRC1WaTogTm8gaW9tbXUgZm9yIGRldmljZSAw
MDAwOjAwOjE4LjANCihYRU4pIFsyMDEyLTEwLTEwIDE1OjEzOjE0XSBBTUQtVmk6IE5vIGlv
bW11IGZvciBkZXZpY2UgMDAwMDowMDoxOC4xDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzox
NF0gQU1ELVZpOiBObyBpb21tdSBmb3IgZGV2aWNlIDAwMDA6MDA6MTguMg0KKFhFTikgWzIw
MTItMTAtMTAgMTU6MTM6MTRdIEFNRC1WaTogTm8gaW9tbXUgZm9yIGRldmljZSAwMDAwOjAw
OjE4LjMNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjEzOjE0XSBBTUQtVmk6IE5vIGlvbW11IGZv
ciBkZXZpY2UgMDAwMDowMDoxOC40DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNF0gQU1E
LVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg0MDAsIHJvb3QgdGFi
bGUgPSAweDI0N2VkNDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBb
MjAxMi0xMC0xMCAxNToxMzoxNF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2
aWNlIGlkID0gMHg0MDEsIHJvb3QgdGFibGUgPSAweDI0N2VkNDAwMCwgZG9tYWluID0gMCwg
cGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNF0gQU1ELVZpOiBT
ZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg0MDIsIHJvb3QgdGFibGUgPSAw
eDI0N2VkNDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0x
MC0xMCAxNToxMzoxNF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlk
ID0gMHg0MDMsIHJvb3QgdGFibGUgPSAweDI0N2VkNDAwMCwgZG9tYWluID0gMCwgcGFnaW5n
IG1vZGUgPSAzDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNF0gQU1ELVZpOiBTZXR1cCBJ
L08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg0MDQsIHJvb3QgdGFibGUgPSAweDI0N2Vk
NDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0xMC0xMCAx
NToxMzoxNF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg0
MDUsIHJvb3QgdGFibGUgPSAweDI0N2VkNDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUg
PSAzDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNF0gQU1ELVZpOiBTZXR1cCBJL08gcGFn
ZSB0YWJsZTogZGV2aWNlIGlkID0gMHg0MDYsIHJvb3QgdGFibGUgPSAweDI0N2VkNDAwMCwg
ZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzox
NF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg0MDcsIHJv
b3QgdGFibGUgPSAweDI0N2VkNDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQoo
WEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJs
ZTogZGV2aWNlIGlkID0gMHg1MDAsIHJvb3QgdGFibGUgPSAweDI0N2VkNDAwMCwgZG9tYWlu
ID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNF0gQU1E
LVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg1MDEsIHJvb3QgdGFi
bGUgPSAweDI0N2VkNDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBb
MjAxMi0xMC0xMCAxNToxMzoxNF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2
aWNlIGlkID0gMHg2MDAsIHJvb3QgdGFibGUgPSAweDI0N2VkNDAwMCwgZG9tYWluID0gMCwg
cGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNF0gQU1ELVZpOiBT
ZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg3MDAsIHJvb3QgdGFibGUgPSAw
eDI0N2VkNDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0x
MC0xMCAxNToxMzoxNF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlk
ID0gMHg4MDAsIHJvb3QgdGFibGUgPSAweDI0N2VkNDAwMCwgZG9tYWluID0gMCwgcGFnaW5n
IG1vZGUgPSAzDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNF0gQU1ELVZpOiBTZXR1cCBJ
L08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg5MDAsIHJvb3QgdGFibGUgPSAweDI0N2Vk
NDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0xMC0xMCAx
NToxMzoxNF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg5
MDEsIHJvb3QgdGFibGUgPSAweDI0N2VkNDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUg
PSAzDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNV0gQU1ELVZpOiBTZXR1cCBJL08gcGFn
ZSB0YWJsZTogZGV2aWNlIGlkID0gMHg5MDIsIHJvb3QgdGFibGUgPSAweDI0N2VkNDAwMCwg
ZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzox
NV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg5MDMsIHJv
b3QgdGFibGUgPSAweDI0N2VkNDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQoo
WEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJs
ZTogZGV2aWNlIGlkID0gMHg5MDQsIHJvb3QgdGFibGUgPSAweDI0N2VkNDAwMCwgZG9tYWlu
ID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNV0gQU1E
LVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg5MDUsIHJvb3QgdGFi
bGUgPSAweDI0N2VkNDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBb
MjAxMi0xMC0xMCAxNToxMzoxNV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2
aWNlIGlkID0gMHg5MDYsIHJvb3QgdGFibGUgPSAweDI0N2VkNDAwMCwgZG9tYWluID0gMCwg
cGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNV0gQU1ELVZpOiBT
ZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg5MDcsIHJvb3QgdGFibGUgPSAw
eDI0N2VkNDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0x
MC0xMCAxNToxMzoxNV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlk
ID0gMHhhMDAsIHJvb3QgdGFibGUgPSAweDI0N2VkNDAwMCwgZG9tYWluID0gMCwgcGFnaW5n
IG1vZGUgPSAzDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNV0gU2NydWJiaW5nIEZyZWUg
UkFNOiAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLmRvbmUuDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzox
Nl0gSW5pdGlhbCBsb3cgbWVtb3J5IHZpcnEgdGhyZXNob2xkIHNldCBhdCAweDQwMDAgcGFn
ZXMuDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNl0gU3RkLiBMb2dsZXZlbDogQWxsDQoo
WEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNl0gR3Vlc3QgTG9nbGV2ZWw6IEFsbA0KKFhFTikg
WzIwMTItMTAtMTAgMTU6MTM6MTZdIFhlbiBpcyByZWxpbnF1aXNoaW5nIFZHQSBjb25zb2xl
Lg0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTM6MTddICoqKiBTZXJpYWwgaW5wdXQgLT4gRE9N
MCAodHlwZSAnQ1RSTC1hJyB0aHJlZSB0aW1lcyB0byBzd2l0Y2ggaW5wdXQgdG8gWGVuKQ0K
KFhFTikgWzIwMTItMTAtMTAgMTU6MTM6MTddIEZyZWVkIDI2MGtCIGluaXQgbWVtb3J5Lg0K
KFhFTikgWzIwMTItMTAtMTAgMTU6MTM6MTddIElPQVBJQ1swXTogU2V0IFBDSSByb3V0aW5n
IGVudHJ5ICg2LTkgLT4gMHg2MCAtPiBJUlEgOSBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBb
MjAxMi0xMC0xMCAxNToxMzoxN10gdHJhcHMuYzoyNTEyOmQwIERvbWFpbiBhdHRlbXB0ZWQg
V1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMGVmZjJiZmRiMWE5ZSB0byAweDAw
MDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBk
ZXZpY2UgMDAwMDowMDowMC4wDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFk
ZCBkZXZpY2UgMDAwMDowMDowMC4yDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJ
IGFkZCBkZXZpY2UgMDAwMDowMDowMi4wDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10g
UENJIGFkZCBkZXZpY2UgMDAwMDowMDowMy4wDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzox
N10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowNS4wDQooWEVOKSBbMjAxMi0xMC0xMCAxNTox
MzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowNi4wDQooWEVOKSBbMjAxMi0xMC0xMCAx
NToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowYS4wDQooWEVOKSBbMjAxMi0xMC0x
MCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowYi4wDQooWEVOKSBbMjAxMi0x
MC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowZC4wDQooWEVOKSBbMjAx
Mi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxMS4wDQooWEVOKSBb
MjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxMi4wDQooWEVO
KSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxMi4yDQoo
WEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxMy4w
DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDox
My4yDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDow
MDoxNC4wDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAw
MDowMDoxNC4xDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2Ug
MDAwMDowMDoxNC4yDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZp
Y2UgMDAwMDowMDoxNC4zDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBk
ZXZpY2UgMDAwMDowMDoxNC40DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFk
ZCBkZXZpY2UgMDAwMDowMDoxNC41DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJ
IGFkZCBkZXZpY2UgMDAwMDowMDoxNS4wDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10g
UENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNi4wDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzox
N10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNi4yDQooWEVOKSBbMjAxMi0xMC0xMCAxNTox
MzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC4wDQooWEVOKSBbMjAxMi0xMC0xMCAx
NToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC4xDQooWEVOKSBbMjAxMi0xMC0x
MCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC4yDQooWEVOKSBbMjAxMi0x
MC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC4zDQooWEVOKSBbMjAx
Mi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC40DQooWEVOKSBb
MjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowYTowMC4wDQooWEVO
KSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowOTowMC4wDQoo
WEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowOTowMC4x
DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowOTow
MC4yDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDow
OTowMC4zDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAw
MDowOTowMC40DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2Ug
MDAwMDowOTowMC41DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZp
Y2UgMDAwMDowOTowMC42DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBk
ZXZpY2UgMDAwMDowOTowMC43DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFk
ZCBkZXZpY2UgMDAwMDowODowMC4wDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJ
IGFkZCBkZXZpY2UgMDAwMDowNzowMC4wDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10g
UENJIGFkZCBkZXZpY2UgMDAwMDowNjowMC4wDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzox
N10gUENJIGFkZCBkZXZpY2UgMDAwMDowNTowMC4wDQooWEVOKSBbMjAxMi0xMC0xMCAxNTox
MzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowNTowMC4xDQooWEVOKSBbMjAxMi0xMC0xMCAx
NToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowNDowMC4wDQooWEVOKSBbMjAxMi0xMC0x
MCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowNDowMC4xDQooWEVOKSBbMjAxMi0x
MC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowNDowMC4yDQooWEVOKSBbMjAx
Mi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowNDowMC4zDQooWEVOKSBb
MjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowNDowMC40DQooWEVO
KSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowNDowMC41DQoo
WEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowNDowMC42
DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowNDow
MC43DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDow
MzowNi4wDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gSU9BUElDWzBdOiBTZXQgUENJ
IHJvdXRpbmcgZW50cnkgKDYtOCAtPiAweDU4IC0+IElSUSA4IE1vZGU6MCBBY3RpdmU6MCkN
CihYRU4pIFsyMDEyLTEwLTEwIDE1OjEzOjE3XSBJT0FQSUNbMF06IFNldCBQQ0kgcm91dGlu
ZyBlbnRyeSAoNi0xMyAtPiAweDg4IC0+IElSUSAxMyBNb2RlOjAgQWN0aXZlOjApDQooWEVO
KSBbMjAxMi0xMC0xMCAxNToxMzoxN10gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50
cnkgKDctMjggLT4gMHhhMCAtPiBJUlEgNTIgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIw
MTItMTAtMTAgMTU6MTM6MTddIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3
LTI5IC0+IDB4YTggLT4gSVJRIDUzIE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTEw
LTEwIDE1OjEzOjE3XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0zMCAt
PiAweGIwIC0+IElSUSA1NCBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0xMC0xMCAx
NToxMzoxN10gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDYtMTYgLT4gMHhi
OCAtPiBJUlEgMTYgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTM6
MTddIElPQVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg2LTE4IC0+IDB4YzAgLT4g
SVJRIDE4IE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjEzOjE3XSBJ
T0FQSUNbMF06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNi0xNyAtPiAweGM4IC0+IElSUSAx
NyBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gSU9BUElD
WzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctNCAtPiAweGQwIC0+IElSUSAyOCBNb2Rl
OjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gSU9BUElDWzFdOiBT
ZXQgUENJIHJvdXRpbmcgZW50cnkgKDctNSAtPiAweGQ4IC0+IElSUSAyOSBNb2RlOjEgQWN0
aXZlOjEpDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gSU9BUElDWzFdOiBTZXQgUENJ
IHJvdXRpbmcgZW50cnkgKDctNiAtPiAweDIxIC0+IElSUSAzMCBNb2RlOjEgQWN0aXZlOjEp
DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRp
bmcgZW50cnkgKDctNyAtPiAweDI5IC0+IElSUSAzMSBNb2RlOjEgQWN0aXZlOjEpDQooWEVO
KSBbMjAxMi0xMC0xMCAxNToxMzoxN10gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50
cnkgKDctMTYgLT4gMHgzMSAtPiBJUlEgNDAgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIw
MTItMTAtMTAgMTU6MTM6MThdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3
LTE3IC0+IDB4MzkgLT4gSVJRIDQxIE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTEw
LTEwIDE1OjEzOjE4XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0xOCAt
PiAweDQxIC0+IElSUSA0MiBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0xMC0xMCAx
NToxMzoxOF0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMTkgLT4gMHg0
OSAtPiBJUlEgNDMgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTM6
MThdIElPQVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg2LTIyIC0+IDB4OTEgLT4g
SVJRIDIyIE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjEzOjE4XSBJ
T0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0yMyAtPiAweDk5IC0+IElSUSA0
NyBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxOF0gSU9BUElD
WzBdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDYtMTkgLT4gMHhhMSAtPiBJUlEgMTkgTW9k
ZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTM6MThdIElPQVBJQ1sxXTog
U2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTIyIC0+IDB4YjEgLT4gSVJRIDQ2IE1vZGU6MSBB
Y3RpdmU6MSkNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjEzOjE4XSBJT0FQSUNbMV06IFNldCBQ
Q0kgcm91dGluZyBlbnRyeSAoNy0yNyAtPiAweGMxIC0+IElSUSA1MSBNb2RlOjEgQWN0aXZl
OjEpDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoyMF0gSU9BUElDWzFdOiBTZXQgUENJIHJv
dXRpbmcgZW50cnkgKDctOSAtPiAweGQxIC0+IElSUSAzMyBNb2RlOjEgQWN0aXZlOjEpDQoo
WEVOKSBbMjAxMi0xMC0xMCAxNToxNTozMl0gdHJhcHMuYzoyNTEyOmQxIERvbWFpbiBhdHRl
bXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMGVkYjQxOWRlNzk1YSB0
byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNTozOF0gdHJh
cHMuYzoyNTEyOmQyIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBm
cm9tIDB4MDAwMDA0NmE4MDJiNDE2NSB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBb
MjAxMi0xMC0xMCAxNToxNTo0NF0gdHJhcHMuYzoyNTEyOmQzIERvbWFpbiBhdHRlbXB0ZWQg
V1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMGVkYjQxOWRlNzk1YSB0byAweDAw
MDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNTo1MV0gdHJhcHMuYzoy
NTEyOmQ0IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4
MDAwMDIxODdjNTNmNjM4ZiB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0x
MC0xMCAxNToxNTo1N10gdHJhcHMuYzoyNTEyOmQ1IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1Ig
MDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMGVkYjQxOWRlNzk1YSB0byAweDAwMDAwMDAw
MDAwMGFiY2QuDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNjowOV0gdHJhcHMuYzoyNTEyOmQ2
IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDIx
ODdjNTNmNjM4ZiB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0xMC0xMCAx
NToxNjoxNV0gdHJhcHMuYzoyNTEyOmQ3IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAw
MDBjMDAxMDAwNCBmcm9tIDB4MDAwMDA0NmE4MDJiNDE2NSB0byAweDAwMDAwMDAwMDAwMGFi
Y2QuDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNjoyMl0gdHJhcHMuYzoyNTEyOmQ4IERvbWFp
biBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDA0NmE4MDJi
NDE2NSB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNjoy
OF0gdHJhcHMuYzoyNTEyOmQ5IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAx
MDAwNCBmcm9tIDB4MDAwMGVkYjQxOWRlNzk1YSB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQoo
WEVOKSBbMjAxMi0xMC0xMCAxNToxNjozNV0gdHJhcHMuYzoyNTEyOmQxMCBEb21haW4gYXR0
ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDBlZGI0MTlkZTc5NWEg
dG8gMHgwMDAwMDAwMDAwMDBhYmNkLg0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTY6NDJdIEFN
RC1WaTogRGlzYWJsZTogZGV2aWNlIGlkID0gMHhhNCwgZG9tYWluID0gMCwgcGFnaW5nIG1v
ZGUgPSAzDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNjo0Ml0gQU1ELVZpOiBTZXR1cCBJL08g
cGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhhNCwgcm9vdCB0YWJsZSA9IDB4MThlMGE1MDAw
LCBkb21haW4gPSAxMSwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0xMC0xMCAxNTox
Njo0Ml0gQU1ELVZpOiBSZS1hc3NpZ24gMDAwMDowMzowNi4wIGZyb20gZG9tMCB0byBkb20x
MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTY6NDNdIHRyYXBzLmM6MjUxMjpkMTEgRG9tYWlu
IGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwNDZiNGY2MDFh
MTQ1IHRvIDB4MDAwMDAwMDAwMDAwYWJjZC4NCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE2OjUz
XSB0cmFwcy5jOjI1MTI6ZDEyIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAx
MDAwNCBmcm9tIDB4MDAwMDIxODdjNTNmNjM4ZiB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQoo
WEVOKSBbMjAxMi0xMC0xMCAxNToxNjo1OV0gdHJhcHMuYzoyNTEyOmQxMyBEb21haW4gYXR0
ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDAwNDZhODAyYjQxNjUg
dG8gMHgwMDAwMDAwMDAwMDBhYmNkLg0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MDVdIHRy
YXBzLmM6MjUxMjpkMTQgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0
IGZyb20gMHgwMDAwMDQ2YTgwMmI0MTY1IHRvIDB4MDAwMDAwMDAwMDAwYWJjZC4NCihYRU4p
IFsyMDEyLTEwLTEwIDE1OjE3OjExXSBBTUQtVmk6IFNoYXJlIHAybSB0YWJsZSB3aXRoIGlv
bW11OiBwMm0gdGFibGUgPSAweDFjMWY5NQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MjRd
IFtWVC1EXWlvLmM6MjgyOiBkMTU6IGJpbmQ6IG1fZ3NpPTE2IGdfZ3NpPTM2IGRldmljZT01
IGludHg9MA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MjRdIEFNRC1WaTogRGlzYWJsZTog
ZGV2aWNlIGlkID0gMHg2MDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikg
WzIwMTItMTAtMTAgMTU6MTc6MjRdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRl
dmljZSBpZCA9IDB4NjAwLCByb290IHRhYmxlID0gMHgxYzFmOTUwMDAsIGRvbWFpbiA9IDE1
LCBwYWdpbmcgbW9kZSA9IDQNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjI0XSBBTUQtVmk6
IFJlLWFzc2lnbiAwMDAwOjA2OjAwLjAgZnJvbSBkb20wIHRvIGRvbTE1DQooWEVOKSBbMjAx
Mi0xMC0xMCAxNToxNzoyNl0gSFZNMTU6IEhWTSBMb2FkZXINCihYRU4pIFsyMDEyLTEwLTEw
IDE1OjE3OjI2XSBIVk0xNTogRGV0ZWN0ZWQgWGVuIHY0LjMtdW5zdGFibGUNCihYRU4pIFsy
MDEyLTEwLTEwIDE1OjE3OjI2XSBIVk0xNTogWGVuYnVzIHJpbmdzIEAweGZlZmZjMDAwLCBl
dmVudCBjaGFubmVsIDUNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjI2XSBIVk0xNTogU3lz
dGVtIHJlcXVlc3RlZCBST01CSU9TDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzoyNl0gSFZN
MTU6IENQVSBzcGVlZCBpcyAzMjAwIE1Ieg0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MjZd
IGlycS5jOjI3MDogRG9tMTUgUENJIGxpbmsgMCBjaGFuZ2VkIDAgLT4gNQ0KKFhFTikgWzIw
MTItMTAtMTAgMTU6MTc6MjZdIEhWTTE1OiBQQ0ktSVNBIGxpbmsgMCByb3V0ZWQgdG8gSVJR
NQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MjZdIGlycS5jOjI3MDogRG9tMTUgUENJIGxp
bmsgMSBjaGFuZ2VkIDAgLT4gMTANCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjI2XSBIVk0x
NTogUENJLUlTQSBsaW5rIDEgcm91dGVkIHRvIElSUTEwDQooWEVOKSBbMjAxMi0xMC0xMCAx
NToxNzoyNl0gaXJxLmM6MjcwOiBEb20xNSBQQ0kgbGluayAyIGNoYW5nZWQgMCAtPiAxMQ0K
KFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MjZdIEhWTTE1OiBQQ0ktSVNBIGxpbmsgMiByb3V0
ZWQgdG8gSVJRMTENCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjI2XSBpcnEuYzoyNzA6IERv
bTE1IFBDSSBsaW5rIDMgY2hhbmdlZCAwIC0+IDUNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3
OjI2XSBIVk0xNTogUENJLUlTQSBsaW5rIDMgcm91dGVkIHRvIElSUTUNCihYRU4pIFsyMDEy
LTEwLTEwIDE1OjE3OjI2XSBIVk0xNTogcGNpIGRldiAwMToyIElOVEQtPklSUTUNCihYRU4p
IFsyMDEyLTEwLTEwIDE1OjE3OjI2XSBIVk0xNTogcGNpIGRldiAwMTozIElOVEEtPklSUTEw
DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzoyNl0gSFZNMTU6IHBjaSBkZXYgMDM6MCBJTlRB
LT5JUlE1DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzoyNl0gSFZNMTU6IHBjaSBkZXYgMDQ6
MCBJTlRBLT5JUlE1DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzoyNl0gSFZNMTU6IHBjaSBk
ZXYgMDU6MCBJTlRBLT5JUlExMA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MjZdIEhWTTE1
OiBwY2kgZGV2IDAyOjAgYmFyIDEwIHNpemUgbHg6IDAyMDAwMDAwDQooWEVOKSBbMjAxMi0x
MC0xMCAxNToxNzoyNl0gSFZNMTU6IHBjaSBkZXYgMDM6MCBiYXIgMTQgc2l6ZSBseDogMDEw
MDAwMDANCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjI2XSBIVk0xNTogcGNpIGRldiAwNTow
IGJhciAxMCBzaXplIGx4OiAwMDIwMDAwMA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MjZd
IG1lbW9yeV9tYXA6YWRkOiBkb20xNSBnZm49ZjMwMDAgbWZuPWY5YTAwIG5yPTIwMA0KKFhF
TikgWzIwMTItMTAtMTAgMTU6MTc6MjZdIEhWTTE1OiBwY2kgZGV2IDA0OjAgYmFyIDEwIHNp
emUgbHg6IDAwMDIwMDAwDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzoyNl0gSFZNMTU6IHBj
aSBkZXYgMDI6MCBiYXIgMTQgc2l6ZSBseDogMDAwMDEwMDANCihYRU4pIFsyMDEyLTEwLTEw
IDE1OjE3OjI2XSBIVk0xNTogcGNpIGRldiAwMzowIGJhciAxMCBzaXplIGx4OiAwMDAwMDEw
MA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MjZdIEhWTTE1OiBwY2kgZGV2IDA0OjAgYmFy
IDE0IHNpemUgbHg6IDAwMDAwMDQwDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzoyNl0gSFZN
MTU6IHBjaSBkZXYgMDE6MiBiYXIgMjAgc2l6ZSBseDogMDAwMDAwMjANCihYRU4pIFsyMDEy
LTEwLTEwIDE1OjE3OjI2XSBIVk0xNTogcGNpIGRldiAwMToxIGJhciAyMCBzaXplIGx4OiAw
MDAwMDAxMA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MjZdIEhWTTE1OiBNdWx0aXByb2Nl
c3NvciBpbml0aWFsaXNhdGlvbjoNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjI2XSBIVk0x
NTogIC0gQ1BVMCAuLi4gNDgtYml0IHBoeXMgLi4uIGZpeGVkIE1UUlJzIC4uLiB2YXIgTVRS
UnMgWzIvOF0gLi4uIGRvbmUuDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzoyNl0gSFZNMTU6
ICAtIENQVTEgLi4uIDQ4LWJpdCBwaHlzIC4uLiBmaXhlZCBNVFJScyAuLi4gdmFyIE1UUlJz
IFsyLzhdIC4uLiBkb25lLg0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MjZdIEhWTTE1OiAg
LSBDUFUyIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBb
Mi84XSAuLi4gZG9uZS4NCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjI2XSBIVk0xNTogVGVz
dGluZyBIVk0gZW52aXJvbm1lbnQ6DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzoyNl0gSFZN
MTU6ICAtIFJFUCBJTlNCIGFjcm9zcyBwYWdlIGJvdW5kYXJpZXMgLi4uIHBhc3NlZA0KKFhF
TikgWzIwMTItMTAtMTAgMTU6MTc6MjZdIEhWTTE1OiAgLSBHUyBiYXNlIE1TUnMgYW5kIFNX
QVBHUyAuLi4gcGFzc2VkDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzoyNl0gSFZNMTU6IFBh
c3NlZCAyIG9mIDIgdGVzdHMNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjI2XSBIVk0xNTog
V3JpdGluZyBTTUJJT1MgdGFibGVzIC4uLg0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MjZd
IEhWTTE1OiBMb2FkaW5nIFJPTUJJT1MgLi4uDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzoy
Nl0gSFZNMTU6IDk2NjAgYnl0ZXMgb2YgUk9NQklPUyBoaWdoLW1lbW9yeSBleHRlbnNpb25z
Og0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MjZdIEhWTTE1OiAgIFJlbG9jYXRpbmcgdG8g
MHhmYzAwMTAwMC0weGZjMDAzNWJjIC4uLiBkb25lDQooWEVOKSBbMjAxMi0xMC0xMCAxNTox
NzoyNl0gSFZNMTU6IENyZWF0aW5nIE1QIHRhYmxlcyAuLi4NCihYRU4pIFsyMDEyLTEwLTEw
IDE1OjE3OjI2XSBIVk0xNTogTG9hZGluZyBDaXJydXMgVkdBQklPUyAuLi4NCihYRU4pIFsy
MDEyLTEwLTEwIDE1OjE3OjI2XSBIVk0xNTogTG9hZGluZyBQQ0kgT3B0aW9uIFJPTSAuLi4N
CihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjI2XSBIVk0xNTogIC0gTWFudWZhY3R1cmVyOiBo
dHRwOi8vaXB4ZS5vcmcNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjI2XSBIVk0xNTogIC0g
UHJvZHVjdCBuYW1lOiBpUFhFDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzoyNl0gSFZNMTU6
IE9wdGlvbiBST01zOg0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MjZdIEhWTTE1OiAgYzAw
MDAtYzhmZmY6IFZHQSBCSU9TDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzoyNl0gSFZNMTU6
ICBjOTAwMC1kOWZmZjogRXRoZXJib290IFJPTQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6
MjZdIEhWTTE1OiBMb2FkaW5nIEFDUEkgLi4uDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzoy
Nl0gSFZNMTU6IHZtODYgVFNTIGF0IGZjMDBmNjgwDQooWEVOKSBbMjAxMi0xMC0xMCAxNTox
NzoyNl0gSFZNMTU6IEJJT1MgbWFwOg0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MjZdIEhW
TTE1OiAgZjAwMDAtZmZmZmY6IE1haW4gQklPUw0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6
MjZdIEhWTTE1OiBFODIwIHRhYmxlOg0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MjZdIEhW
TTE1OiAgWzAwXTogMDAwMDAwMDA6MDAwMDAwMDAgLSAwMDAwMDAwMDowMDA5ZTAwMDogUkFN
DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzoyNl0gSFZNMTU6ICBbMDFdOiAwMDAwMDAwMDow
MDA5ZTAwMCAtIDAwMDAwMDAwOjAwMGEwMDAwOiBSRVNFUlZFRA0KKFhFTikgWzIwMTItMTAt
MTAgMTU6MTc6MjZdIEhWTTE1OiAgSE9MRTogMDAwMDAwMDA6MDAwYTAwMDAgLSAwMDAwMDAw
MDowMDBlMDAwMA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MjZdIEhWTTE1OiAgWzAyXTog
MDAwMDAwMDA6MDAwZTAwMDAgLSAwMDAwMDAwMDowMDEwMDAwMDogUkVTRVJWRUQNCihYRU4p
IFsyMDEyLTEwLTEwIDE1OjE3OjI2XSBIVk0xNTogIFswM106IDAwMDAwMDAwOjAwMTAwMDAw
IC0gMDAwMDAwMDA6MmY4MDAwMDA6IFJBTQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MjZd
IEhWTTE1OiAgSE9MRTogMDAwMDAwMDA6MmY4MDAwMDAgLSAwMDAwMDAwMDpmYzAwMDAwMA0K
KFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MjZdIEhWTTE1OiAgWzA0XTogMDAwMDAwMDA6ZmMw
MDAwMDAgLSAwMDAwMDAwMTowMDAwMDAwMDogUkVTRVJWRUQNCihYRU4pIFsyMDEyLTEwLTEw
IDE1OjE3OjI2XSBIVk0xNTogSW52b2tpbmcgUk9NQklPUyAuLi4NCihYRU4pIFsyMDEyLTEw
LTEwIDE1OjE3OjI2XSBIVk0xNTogJFJldmlzaW9uOiAxLjIyMSAkICREYXRlOiAyMDA4LzEy
LzA3IDE3OjMyOjI5ICQNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjI2XSBzdGR2Z2EuYzox
NDc6ZDE1IGVudGVyaW5nIHN0ZHZnYSBhbmQgY2FjaGluZyBtb2Rlcw0KKFhFTikgWzIwMTIt
MTAtMTAgMTU6MTc6MjZdIEhWTTE1OiBWR0FCaW9zICRJZDogdmdhYmlvcy5jLHYgMS42NyAy
MDA4LzAxLzI3IDA5OjQ0OjEyIHZydXBwZXJ0IEV4cCAkDQooWEVOKSBbMjAxMi0xMC0xMCAx
NToxNzoyNl0gSFZNMTU6IEJvY2hzIEJJT1MgLSBidWlsZDogMDYvMjMvOTkNCihYRU4pIFsy
MDEyLTEwLTEwIDE1OjE3OjI2XSBIVk0xNTogJFJldmlzaW9uOiAxLjIyMSAkICREYXRlOiAy
MDA4LzEyLzA3IDE3OjMyOjI5ICQNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjI2XSBIVk0x
NTogT3B0aW9uczogYXBtYmlvcyBwY2liaW9zIGVsdG9yaXRvIFBNTSANCihYRU4pIFsyMDEy
LTEwLTEwIDE1OjE3OjI2XSBIVk0xNTogDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzoyNl0g
SFZNMTU6IGF0YTAtMDogUENIUz0xNjM4My8xNi82MyB0cmFuc2xhdGlvbj1sYmEgTENIUz0x
MDI0LzI1NS82Mw0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MjZdIEhWTTE1OiBhdGEwIG1h
c3RlcjogUUVNVSBIQVJERElTSyBBVEEtNyBIYXJkLURpc2sgKDEwMjQwIE1CeXRlcykNCihY
RU4pIFsyMDEyLTEwLTEwIDE1OjE3OjI2XSBIVk0xNTogYXRhMC0xOiBQQ0hTPTE2MzgzLzE2
LzYzIHRyYW5zbGF0aW9uPWxiYSBMQ0hTPTEwMjQvMjU1LzYzDQooWEVOKSBbMjAxMi0xMC0x
MCAxNToxNzoyNl0gSFZNMTU6IGF0YTAgIHNsYXZlOiBRRU1VIEhBUkRESVNLIEFUQS03IEhh
cmQtRGlzayAoIDMwMCBHQnl0ZXMpDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzoyNl0gSFZN
MTU6IA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MjZdIEhWTTE1OiANCihYRU4pIFsyMDEy
LTEwLTEwIDE1OjE3OjI2XSBIVk0xNTogDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzoyNl0g
SFZNMTU6IFByZXNzIEYxMiBmb3IgYm9vdCBtZW51Lg0KKFhFTikgWzIwMTItMTAtMTAgMTU6
MTc6MjZdIEhWTTE1OiANCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjI2XSBIVk0xNTogQm9v
dGluZyBmcm9tIEhhcmQgRGlzay4uLg0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MjZdIEhW
TTE1OiBCb290aW5nIGZyb20gMDAwMDo3YzAwDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzoz
MF0gc3RkdmdhLmM6MTUxOmQxNSBsZWF2aW5nIHN0ZHZnYQ0KKFhFTikgWzIwMTItMTAtMTAg
MTU6MTc6MzFdIEFNRC1WaTogU2hhcmUgcDJtIHRhYmxlIHdpdGggaW9tbXU6IHAybSB0YWJs
ZSA9IDB4ODE3MDcNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjMyXSBbVlQtRF1pby5jOjI4
MjogZDE2OiBiaW5kOiBtX2dzaT0xNiBnX2dzaT0zNiBkZXZpY2U9NSBpbnR4PTANCihYRU4p
IFsyMDEyLTEwLTEwIDE1OjE3OjMyXSBBTUQtVmk6IERpc2FibGU6IGRldmljZSBpZCA9IDB4
OTAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTEwLTEwIDE1
OjE3OjMyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDkw
MCwgcm9vdCB0YWJsZSA9IDB4ODE3MDcwMDAsIGRvbWFpbiA9IDE2LCBwYWdpbmcgbW9kZSA9
IDQNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjMyXSBBTUQtVmk6IFJlLWFzc2lnbiAwMDAw
OjA5OjAwLjAgZnJvbSBkb20wIHRvIGRvbTE2DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzoz
Ml0gcGh5c2Rldi5jOjE3NzogZG9tMTY6IDI4Oi0xIGFscmVhZHkgbWFwcGVkIHRvIDE2DQoo
WEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gW1ZULURdaW8uYzoyODI6IGQxNjogYmluZDog
bV9nc2k9MTYgZ19nc2k9NDAgZGV2aWNlPTYgaW50eD0wDQooWEVOKSBbMjAxMi0xMC0xMCAx
NToxNzozMl0gQU1ELVZpOiBEaXNhYmxlOiBkZXZpY2UgaWQgPSAweDkwMSwgZG9tYWluID0g
MCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gQU1ELVZp
OiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg5MDEsIHJvb3QgdGFibGUg
PSAweDgxNzA3MDAwLCBkb21haW4gPSAxNiwgcGFnaW5nIG1vZGUgPSA0DQooWEVOKSBbMjAx
Mi0xMC0xMCAxNToxNzozMl0gQU1ELVZpOiBSZS1hc3NpZ24gMDAwMDowOTowMC4xIGZyb20g
ZG9tMCB0byBkb20xNg0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MzJdIFtWVC1EXWlvLmM6
MjgyOiBkMTY6IGJpbmQ6IG1fZ3NpPTE3IGdfZ3NpPTQ1IGRldmljZT03IGludHg9MQ0KKFhF
TikgWzIwMTItMTAtMTAgMTU6MTc6MzJdIEFNRC1WaTogRGlzYWJsZTogZGV2aWNlIGlkID0g
MHg5MDIsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMTAtMTAg
MTU6MTc6MzJdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4
OTAyLCByb290IHRhYmxlID0gMHg4MTcwNzAwMCwgZG9tYWluID0gMTYsIHBhZ2luZyBtb2Rl
ID0gNA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MzJdIEFNRC1WaTogUmUtYXNzaWduIDAw
MDA6MDk6MDAuMiBmcm9tIGRvbTAgdG8gZG9tMTYNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3
OjMyXSBwaHlzZGV2LmM6MTc3OiBkb20xNjogMjk6LTEgYWxyZWFkeSBtYXBwZWQgdG8gMTcN
CihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjMyXSBbVlQtRF1pby5jOjI4MjogZDE2OiBiaW5k
OiBtX2dzaT0xNyBnX2dzaT0xOCBkZXZpY2U9OCBpbnR4PTENCihYRU4pIFsyMDEyLTEwLTEw
IDE1OjE3OjMyXSBBTUQtVmk6IERpc2FibGU6IGRldmljZSBpZCA9IDB4OTAzLCBkb21haW4g
PSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjMyXSBBTUQt
Vmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDkwMywgcm9vdCB0YWJs
ZSA9IDB4ODE3MDcwMDAsIGRvbWFpbiA9IDE2LCBwYWdpbmcgbW9kZSA9IDQNCihYRU4pIFsy
MDEyLTEwLTEwIDE1OjE3OjMyXSBBTUQtVmk6IFJlLWFzc2lnbiAwMDAwOjA5OjAwLjMgZnJv
bSBkb20wIHRvIGRvbTE2DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gW1ZULURdaW8u
YzoyODI6IGQxNjogYmluZDogbV9nc2k9MTggZ19nc2k9MjMgZGV2aWNlPTkgaW50eD0yDQoo
WEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gQU1ELVZpOiBEaXNhYmxlOiBkZXZpY2UgaWQg
PSAweDkwNCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0xMC0x
MCAxNToxNzozMl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0g
MHg5MDQsIHJvb3QgdGFibGUgPSAweDgxNzA3MDAwLCBkb21haW4gPSAxNiwgcGFnaW5nIG1v
ZGUgPSA0DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gQU1ELVZpOiBSZS1hc3NpZ24g
MDAwMDowOTowMC40IGZyb20gZG9tMCB0byBkb20xNg0KKFhFTikgWzIwMTItMTAtMTAgMTU6
MTc6MzJdIHBoeXNkZXYuYzoxNzc6IGRvbTE2OiAzMDotMSBhbHJlYWR5IG1hcHBlZCB0byAx
OA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MzJdIFtWVC1EXWlvLmM6MjgyOiBkMTY6IGJp
bmQ6IG1fZ3NpPTE4IGdfZ3NpPTI3IGRldmljZT0xMCBpbnR4PTINCihYRU4pIFsyMDEyLTEw
LTEwIDE1OjE3OjMyXSBBTUQtVmk6IERpc2FibGU6IGRldmljZSBpZCA9IDB4OTA1LCBkb21h
aW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjMyXSBB
TUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDkwNSwgcm9vdCB0
YWJsZSA9IDB4ODE3MDcwMDAsIGRvbWFpbiA9IDE2LCBwYWdpbmcgbW9kZSA9IDQNCihYRU4p
IFsyMDEyLTEwLTEwIDE1OjE3OjMyXSBBTUQtVmk6IFJlLWFzc2lnbiAwMDAwOjA5OjAwLjUg
ZnJvbSBkb20wIHRvIGRvbTE2DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gW1ZULURd
aW8uYzoyODI6IGQxNjogYmluZDogbV9nc2k9MTkgZ19nc2k9MzIgZGV2aWNlPTExIGludHg9
Mw0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MzJdIEFNRC1WaTogRGlzYWJsZTogZGV2aWNl
IGlkID0gMHg5MDYsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTIt
MTAtMTAgMTU6MTc6MzJdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBp
ZCA9IDB4OTA2LCByb290IHRhYmxlID0gMHg4MTcwNzAwMCwgZG9tYWluID0gMTYsIHBhZ2lu
ZyBtb2RlID0gNA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MzJdIEFNRC1WaTogUmUtYXNz
aWduIDAwMDA6MDk6MDAuNiBmcm9tIGRvbTAgdG8gZG9tMTYNCihYRU4pIFsyMDEyLTEwLTEw
IDE1OjE3OjMyXSBwaHlzZGV2LmM6MTc3OiBkb20xNjogMzE6LTEgYWxyZWFkeSBtYXBwZWQg
dG8gMTkNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjMyXSBbVlQtRF1pby5jOjI4MjogZDE2
OiBiaW5kOiBtX2dzaT0xOSBnX2dzaT0zNiBkZXZpY2U9MTIgaW50eD0zDQooWEVOKSBbMjAx
Mi0xMC0xMCAxNToxNzozMl0gQU1ELVZpOiBEaXNhYmxlOiBkZXZpY2UgaWQgPSAweDkwNywg
ZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzoz
Ml0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg5MDcsIHJv
b3QgdGFibGUgPSAweDgxNzA3MDAwLCBkb21haW4gPSAxNiwgcGFnaW5nIG1vZGUgPSA0DQoo
WEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gQU1ELVZpOiBSZS1hc3NpZ24gMDAwMDowOTow
MC43IGZyb20gZG9tMCB0byBkb20xNg0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MzJdIEhW
TTE2OiBIVk0gTG9hZGVyDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gSFZNMTY6IERl
dGVjdGVkIFhlbiB2NC4zLXVuc3RhYmxlDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0g
SFZNMTY6IFhlbmJ1cyByaW5ncyBAMHhmZWZmYzAwMCwgZXZlbnQgY2hhbm5lbCA1DQooWEVO
KSBbMjAxMi0xMC0xMCAxNToxNzozMl0gSFZNMTY6IFN5c3RlbSByZXF1ZXN0ZWQgUk9NQklP
Uw0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MzJdIEhWTTE2OiBDUFUgc3BlZWQgaXMgMzIw
MCBNSHoNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjMyXSBpcnEuYzoyNzA6IERvbTE2IFBD
SSBsaW5rIDAgY2hhbmdlZCAwIC0+IDUNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjMyXSBI
Vk0xNjogUENJLUlTQSBsaW5rIDAgcm91dGVkIHRvIElSUTUNCihYRU4pIFsyMDEyLTEwLTEw
IDE1OjE3OjMyXSBpcnEuYzoyNzA6IERvbTE2IFBDSSBsaW5rIDEgY2hhbmdlZCAwIC0+IDEw
DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gSFZNMTY6IFBDSS1JU0EgbGluayAxIHJv
dXRlZCB0byBJUlExMA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MzJdIGlycS5jOjI3MDog
RG9tMTYgUENJIGxpbmsgMiBjaGFuZ2VkIDAgLT4gMTENCihYRU4pIFsyMDEyLTEwLTEwIDE1
OjE3OjMyXSBIVk0xNjogUENJLUlTQSBsaW5rIDIgcm91dGVkIHRvIElSUTExDQooWEVOKSBb
MjAxMi0xMC0xMCAxNToxNzozMl0gaXJxLmM6MjcwOiBEb20xNiBQQ0kgbGluayAzIGNoYW5n
ZWQgMCAtPiA1DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gSFZNMTY6IFBDSS1JU0Eg
bGluayAzIHJvdXRlZCB0byBJUlE1DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gSFZN
MTY6IHBjaSBkZXYgMDE6MiBJTlRELT5JUlE1DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzoz
Ml0gSFZNMTY6IHBjaSBkZXYgMDE6MyBJTlRBLT5JUlExMA0KKFhFTikgWzIwMTItMTAtMTAg
MTU6MTc6MzJdIEhWTTE2OiBwY2kgZGV2IDAzOjAgSU5UQS0+SVJRNQ0KKFhFTikgWzIwMTIt
MTAtMTAgMTU6MTc6MzJdIEhWTTE2OiBwY2kgZGV2IDA0OjAgSU5UQS0+SVJRNQ0KKFhFTikg
WzIwMTItMTAtMTAgMTU6MTc6MzJdIEhWTTE2OiBwY2kgZGV2IDA1OjAgSU5UQS0+SVJRMTAN
CihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjMyXSBIVk0xNjogcGNpIGRldiAwNjowIElOVEEt
PklSUTExDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gSFZNMTY6IHBjaSBkZXYgMDc6
MCBJTlRCLT5JUlE1DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gSFZNMTY6IHBjaSBk
ZXYgMDg6MCBJTlRCLT5JUlExMA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MzJdIEhWTTE2
OiBwY2kgZGV2IDA5OjAgSU5UQy0+SVJRNQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MzJd
IEhWTTE2OiBwY2kgZGV2IDBhOjAgSU5UQy0+SVJRNQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6
MTc6MzJdIEhWTTE2OiBwY2kgZGV2IDBiOjAgSU5URC0+SVJRMTENCihYRU4pIFsyMDEyLTEw
LTEwIDE1OjE3OjMyXSBIVk0xNjogcGNpIGRldiAwYzowIElOVEQtPklSUTUNCihYRU4pIFsy
MDEyLTEwLTEwIDE1OjE3OjMyXSBIVk0xNjogcGNpIGRldiAwMjowIGJhciAxMCBzaXplIGx4
OiAwMjAwMDAwMA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MzJdIEhWTTE2OiBwY2kgZGV2
IDAzOjAgYmFyIDE0IHNpemUgbHg6IDAxMDAwMDAwDQooWEVOKSBbMjAxMi0xMC0xMCAxNTox
NzozMl0gSFZNMTY6IHBjaSBkZXYgMDQ6MCBiYXIgMTAgc2l6ZSBseDogMDAwMjAwMDANCihY
RU4pIFsyMDEyLTEwLTEwIDE1OjE3OjMyXSBIVk0xNjogcGNpIGRldiAwMjowIGJhciAxNCBz
aXplIGx4OiAwMDAwMTAwMA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MzJdIEhWTTE2OiBw
Y2kgZGV2IDA1OjAgYmFyIDEwIHNpemUgbHg6IDAwMDAxMDAwDQooWEVOKSBbMjAxMi0xMC0x
MCAxNToxNzozMl0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzAyMSBtZm49ZjlmZjgg
bnI9MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MzJdIEhWTTE2OiBwY2kgZGV2IDA2OjAg
YmFyIDEwIHNpemUgbHg6IDAwMDAxMDAwDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0g
bWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzAyMiBtZm49ZjlmZjkgbnI9MQ0KKFhFTikg
WzIwMTItMTAtMTAgMTU6MTc6MzJdIEhWTTE2OiBwY2kgZGV2IDA3OjAgYmFyIDEwIHNpemUg
bHg6IDAwMDAxMDAwDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gbWVtb3J5X21hcDph
ZGQ6IGRvbTE2IGdmbj1mMzAyMyBtZm49ZjlmZmEgbnI9MQ0KKFhFTikgWzIwMTItMTAtMTAg
MTU6MTc6MzJdIEhWTTE2OiBwY2kgZGV2IDA4OjAgYmFyIDEwIHNpemUgbHg6IDAwMDAxMDAw
DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdm
bj1mMzAyNCBtZm49ZjlmZmIgbnI9MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MzJdIEhW
TTE2OiBwY2kgZGV2IDA5OjAgYmFyIDEwIHNpemUgbHg6IDAwMDAxMDAwDQooWEVOKSBbMjAx
Mi0xMC0xMCAxNToxNzozMl0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzAyNSBtZm49
ZjlmZmMgbnI9MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MzJdIEhWTTE2OiBwY2kgZGV2
IDBhOjAgYmFyIDEwIHNpemUgbHg6IDAwMDAxMDAwDQooWEVOKSBbMjAxMi0xMC0xMCAxNTox
NzozMl0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzAyNiBtZm49ZjlmZmQgbnI9MQ0K
KFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MzJdIEhWTTE2OiBwY2kgZGV2IDBiOjAgYmFyIDEw
IHNpemUgbHg6IDAwMDAxMDAwDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gbWVtb3J5
X21hcDphZGQ6IGRvbTE2IGdmbj1mMzAyNyBtZm49ZjlmZmUgbnI9MQ0KKFhFTikgWzIwMTIt
MTAtMTAgMTU6MTc6MzJdIEhWTTE2OiBwY2kgZGV2IDBjOjAgYmFyIDEwIHNpemUgbHg6IDAw
MDAxMDAwDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gbWVtb3J5X21hcDphZGQ6IGRv
bTE2IGdmbj1mMzAyOCBtZm49ZjlmZmYgbnI9MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6
MzJdIEhWTTE2OiBwY2kgZGV2IDAzOjAgYmFyIDEwIHNpemUgbHg6IDAwMDAwMTAwDQooWEVO
KSBbMjAxMi0xMC0xMCAxNToxNzozMl0gSFZNMTY6IHBjaSBkZXYgMDQ6MCBiYXIgMTQgc2l6
ZSBseDogMDAwMDAwNDANCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjMyXSBIVk0xNjogcGNp
IGRldiAwMToyIGJhciAyMCBzaXplIGx4OiAwMDAwMDAyMA0KKFhFTikgWzIwMTItMTAtMTAg
MTU6MTc6MzJdIEhWTTE2OiBwY2kgZGV2IDAxOjEgYmFyIDIwIHNpemUgbHg6IDAwMDAwMDEw
DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gSFZNMTY6IE11bHRpcHJvY2Vzc29yIGlu
aXRpYWxpc2F0aW9uOg0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MzJdIEhWTTE2OiAgLSBD
UFUwIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMi84
XSAuLi4gZG9uZS4NCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjMyXSBIVk0xNjogIC0gQ1BV
MSAuLi4gNDgtYml0IHBoeXMgLi4uIGZpeGVkIE1UUlJzIC4uLiB2YXIgTVRSUnMgWzIvOF0g
Li4uIGRvbmUuDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gSFZNMTY6ICAtIENQVTIg
Li4uIDQ4LWJpdCBwaHlzIC4uLiBmaXhlZCBNVFJScyAuLi4gdmFyIE1UUlJzIFsyLzhdIC4u
LiBkb25lLg0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MzJdIEhWTTE2OiBUZXN0aW5nIEhW
TSBlbnZpcm9ubWVudDoNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjMyXSBIVk0xNjogIC0g
UkVQIElOU0IgYWNyb3NzIHBhZ2UgYm91bmRhcmllcyAuLi4gcGFzc2VkDQooWEVOKSBbMjAx
Mi0xMC0xMCAxNToxNzozMl0gSFZNMTY6ICAtIEdTIGJhc2UgTVNScyBhbmQgU1dBUEdTIC4u
LiBwYXNzZWQNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjMyXSBIVk0xNjogUGFzc2VkIDIg
b2YgMiB0ZXN0cw0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MzJdIEhWTTE2OiBXcml0aW5n
IFNNQklPUyB0YWJsZXMgLi4uDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gSFZNMTY6
IExvYWRpbmcgUk9NQklPUyAuLi4NCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjMyXSBIVk0x
NjogOTY2MCBieXRlcyBvZiBST01CSU9TIGhpZ2gtbWVtb3J5IGV4dGVuc2lvbnM6DQooWEVO
KSBbMjAxMi0xMC0xMCAxNToxNzozMl0gSFZNMTY6ICAgUmVsb2NhdGluZyB0byAweGZjMDAx
MDAwLTB4ZmMwMDM1YmMgLi4uIGRvbmUNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjMyXSBI
Vk0xNjogQ3JlYXRpbmcgTVAgdGFibGVzIC4uLg0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6
MzJdIEhWTTE2OiBMb2FkaW5nIENpcnJ1cyBWR0FCSU9TIC4uLg0KKFhFTikgWzIwMTItMTAt
MTAgMTU6MTc6MzJdIEhWTTE2OiBMb2FkaW5nIFBDSSBPcHRpb24gUk9NIC4uLg0KKFhFTikg
WzIwMTItMTAtMTAgMTU6MTc6MzJdIEhWTTE2OiAgLSBNYW51ZmFjdHVyZXI6IGh0dHA6Ly9p
cHhlLm9yZw0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MzJdIEhWTTE2OiAgLSBQcm9kdWN0
IG5hbWU6IGlQWEUNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjMyXSBIVk0xNjogT3B0aW9u
IFJPTXM6DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gSFZNMTY6ICBjMDAwMC1jOGZm
ZjogVkdBIEJJT1MNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjMyXSBIVk0xNjogIGM5MDAw
LWQ5ZmZmOiBFdGhlcmJvb3QgUk9NDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gSFZN
MTY6IExvYWRpbmcgQUNQSSAuLi4NCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjMyXSBIVk0x
Njogdm04NiBUU1MgYXQgZmMwMGY2ODANCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjMyXSBI
Vk0xNjogQklPUyBtYXA6DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gSFZNMTY6ICBm
MDAwMC1mZmZmZjogTWFpbiBCSU9TDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gSFZN
MTY6IEU4MjAgdGFibGU6DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gSFZNMTY6ICBb
MDBdOiAwMDAwMDAwMDowMDAwMDAwMCAtIDAwMDAwMDAwOjAwMDllMDAwOiBSQU0NCihYRU4p
IFsyMDEyLTEwLTEwIDE1OjE3OjMyXSBIVk0xNjogIFswMV06IDAwMDAwMDAwOjAwMDllMDAw
IC0gMDAwMDAwMDA6MDAwYTAwMDA6IFJFU0VSVkVEDQooWEVOKSBbMjAxMi0xMC0xMCAxNTox
NzozMl0gSFZNMTY6ICBIT0xFOiAwMDAwMDAwMDowMDBhMDAwMCAtIDAwMDAwMDAwOjAwMGUw
MDAwDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gSFZNMTY6ICBbMDJdOiAwMDAwMDAw
MDowMDBlMDAwMCAtIDAwMDAwMDAwOjAwMTAwMDAwOiBSRVNFUlZFRA0KKFhFTikgWzIwMTIt
MTAtMTAgMTU6MTc6MzJdIEhWTTE2OiAgWzAzXTogMDAwMDAwMDA6MDAxMDAwMDAgLSAwMDAw
MDAwMDoxZjgwMDAwMDogUkFNDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gSFZNMTY6
ICBIT0xFOiAwMDAwMDAwMDoxZjgwMDAwMCAtIDAwMDAwMDAwOmZjMDAwMDAwDQooWEVOKSBb
MjAxMi0xMC0xMCAxNToxNzozMl0gSFZNMTY6ICBbMDRdOiAwMDAwMDAwMDpmYzAwMDAwMCAt
IDAwMDAwMDAxOjAwMDAwMDAwOiBSRVNFUlZFRA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6
MzJdIEhWTTE2OiBJbnZva2luZyBST01CSU9TIC4uLg0KKFhFTikgWzIwMTItMTAtMTAgMTU6
MTc6MzJdIEhWTTE2OiAkUmV2aXNpb246IDEuMjIxICQgJERhdGU6IDIwMDgvMTIvMDcgMTc6
MzI6MjkgJA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MzNdIHN0ZHZnYS5jOjE0NzpkMTYg
ZW50ZXJpbmcgc3RkdmdhIGFuZCBjYWNoaW5nIG1vZGVzDQooWEVOKSBbMjAxMi0xMC0xMCAx
NToxNzozM10gSFZNMTY6IFZHQUJpb3MgJElkOiB2Z2FiaW9zLmMsdiAxLjY3IDIwMDgvMDEv
MjcgMDk6NDQ6MTIgdnJ1cHBlcnQgRXhwICQNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjMz
XSBIVk0xNjogQm9jaHMgQklPUyAtIGJ1aWxkOiAwNi8yMy85OQ0KKFhFTikgWzIwMTItMTAt
MTAgMTU6MTc6MzNdIEhWTTE2OiAkUmV2aXNpb246IDEuMjIxICQgJERhdGU6IDIwMDgvMTIv
MDcgMTc6MzI6MjkgJA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MzNdIEhWTTE2OiBPcHRp
b25zOiBhcG1iaW9zIHBjaWJpb3MgZWx0b3JpdG8gUE1NIA0KKFhFTikgWzIwMTItMTAtMTAg
MTU6MTc6MzNdIEhWTTE2OiANCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjMzXSBIVk0xNjog
YXRhMC0wOiBQQ0hTPTEwNDAyLzE2LzYzIHRyYW5zbGF0aW9uPWxiYSBMQ0hTPTY1Mi8yNTUv
NjMNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjMzXSBIVk0xNjogYXRhMCBtYXN0ZXI6IFFF
TVUgSEFSRERJU0sgQVRBLTcgSGFyZC1EaXNrICg1MTIwIE1CeXRlcykNCihYRU4pIFsyMDEy
LTEwLTEwIDE1OjE3OjM0XSBIVk0xNjogSURFIHRpbWUgb3V0DQooWEVOKSBbMjAxMi0xMC0x
MCAxNToxNzozNF0gSFZNMTY6IA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MzddIEhWTTE2
OiANCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjM3XSBIVk0xNjogDQooWEVOKSBbMjAxMi0x
MC0xMCAxNToxNzozN10gSFZNMTY6IFByZXNzIEYxMiBmb3IgYm9vdCBtZW51Lg0KKFhFTikg
WzIwMTItMTAtMTAgMTU6MTc6MzddIEhWTTE2OiANCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3
OjM3XSBIVk0xNjogQm9vdGluZyBmcm9tIEhhcmQgRGlzay4uLg0KKFhFTikgWzIwMTItMTAt
MTAgMTU6MTc6MzddIEhWTTE2OiBCb290aW5nIGZyb20gMDAwMDo3YzAwDQooWEVOKSBbMjAx
Mi0xMC0xMCAxNToxNzo0MF0gc3RkdmdhLmM6MTQ3OmQxNSBlbnRlcmluZyBzdGR2Z2EgYW5k
IGNhY2hpbmcgbW9kZXMNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjQxXSBpcnEuYzozNzU6
IERvbTE1IGNhbGxiYWNrIHZpYSBjaGFuZ2VkIHRvIERpcmVjdCBWZWN0b3IgMHhmMw0KKFhF
TikgWzIwMTItMTAtMTAgMTU6MTc6NDFdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNSBnZm49
ZjMwMDAgbWZuPWY5YTAwIG5yPTIwMA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NDFdIG1l
bW9yeV9tYXA6YWRkOiBkb20xNSBnZm49ZjMwMDAgbWZuPWY5YTAwIG5yPTIwMA0KKFhFTikg
WzIwMTItMTAtMTAgMTU6MTc6NDFdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNSBnZm49ZjMw
MDAgbWZuPWY5YTAwIG5yPTIwMA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NDFdIG1lbW9y
eV9tYXA6YWRkOiBkb20xNSBnZm49ZjMwMDAgbWZuPWY5YTAwIG5yPTIwMA0KKFhFTikgWzIw
MTItMTAtMTAgMTU6MTc6NDFdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNSBnZm49ZjMwMDAg
bWZuPWY5YTAwIG5yPTIwMA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NDFdIG1lbW9yeV9t
YXA6YWRkOiBkb20xNSBnZm49ZjMwMDAgbWZuPWY5YTAwIG5yPTIwMA0KKFhFTikgWzIwMTIt
MTAtMTAgMTU6MTc6NDFdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNSBnZm49ZjMwMDAgbWZu
PWY5YTAwIG5yPTIwMA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NDFdIG1lbW9yeV9tYXA6
YWRkOiBkb20xNSBnZm49ZjMwMDAgbWZuPWY5YTAwIG5yPTIwMA0KKFhFTikgWzIwMTItMTAt
MTAgMTU6MTc6NDFdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNSBnZm49ZjMwMDAgbWZuPWY5
YTAwIG5yPTIwMA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NDFdIG1lbW9yeV9tYXA6YWRk
OiBkb20xNSBnZm49ZjMwMDAgbWZuPWY5YTAwIG5yPTIwMA0KKFhFTikgWzIwMTItMTAtMTAg
MTU6MTc6NDFdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNSBnZm49ZjMwMDAgbWZuPWY5YTAw
IG5yPTIwMA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NDFdIG1lbW9yeV9tYXA6YWRkOiBk
b20xNSBnZm49ZjMwMDAgbWZuPWY5YTAwIG5yPTIwMA0KKFhFTikgWzIwMTItMTAtMTAgMTU6
MTc6NDFdIGlycS5jOjI3MDogRG9tMTUgUENJIGxpbmsgMCBjaGFuZ2VkIDUgLT4gMA0KKFhF
TikgWzIwMTItMTAtMTAgMTU6MTc6NDFdIGlycS5jOjI3MDogRG9tMTUgUENJIGxpbmsgMSBj
aGFuZ2VkIDEwIC0+IDANCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjQxXSBpcnEuYzoyNzA6
IERvbTE1IFBDSSBsaW5rIDIgY2hhbmdlZCAxMSAtPiAwDQooWEVOKSBbMjAxMi0xMC0xMCAx
NToxNzo0MV0gaXJxLmM6MjcwOiBEb20xNSBQQ0kgbGluayAzIGNoYW5nZWQgNSAtPiAwDQoo
WEVOKSBbMjAxMi0xMC0xMCAxNToxNzo0Ml0gc3RkdmdhLmM6MTUxOmQxNiBsZWF2aW5nIHN0
ZHZnYQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NTNdIHN0ZHZnYS5jOjE0NzpkMTYgZW50
ZXJpbmcgc3RkdmdhIGFuZCBjYWNoaW5nIG1vZGVzDQooWEVOKSBbMjAxMi0xMC0xMCAxNTox
Nzo1NF0gaXJxLmM6Mzc1OiBEb20xNiBjYWxsYmFjayB2aWEgY2hhbmdlZCB0byBEaXJlY3Qg
VmVjdG9yIDB4ZjMNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU0XSBtZW1vcnlfbWFwOnJl
bW92ZTogZG9tMTYgZ2ZuPWYzMDIxIG1mbj1mOWZmOCBucj0xDQooWEVOKSBbMjAxMi0xMC0x
MCAxNToxNzo1NF0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzAyMSBtZm49ZjlmZjgg
bnI9MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NTRdIG1lbW9yeV9tYXA6cmVtb3ZlOiBk
b20xNiBnZm49ZjMwMjEgbWZuPWY5ZmY4IG5yPTENCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3
OjU0XSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDIxIG1mbj1mOWZmOCBucj0xDQoo
WEVOKSBbMjAxMi0xMC0xMCAxNToxNzo1NF0gbWVtb3J5X21hcDpyZW1vdmU6IGRvbTE2IGdm
bj1mMzAyMSBtZm49ZjlmZjggbnI9MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NTRdIG1l
bW9yeV9tYXA6YWRkOiBkb20xNiBnZm49ZjMwMjEgbWZuPWY5ZmY4IG5yPTENCihYRU4pIFsy
MDEyLTEwLTEwIDE1OjE3OjU0XSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYgZ2ZuPWYzMDIx
IG1mbj1mOWZmOCBucj0xDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzo1NF0gbWVtb3J5X21h
cDphZGQ6IGRvbTE2IGdmbj1mMzAyMSBtZm49ZjlmZjggbnI9MQ0KKFhFTikgWzIwMTItMTAt
MTAgMTU6MTc6NTRdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNiBnZm49ZjMwMjEgbWZuPWY5
ZmY4IG5yPTENCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU0XSBtZW1vcnlfbWFwOmFkZDog
ZG9tMTYgZ2ZuPWYzMDIxIG1mbj1mOWZmOCBucj0xDQooWEVOKSBbMjAxMi0xMC0xMCAxNTox
Nzo1NF0gbWVtb3J5X21hcDpyZW1vdmU6IGRvbTE2IGdmbj1mMzAyMSBtZm49ZjlmZjggbnI9
MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NTRdIG1lbW9yeV9tYXA6YWRkOiBkb20xNiBn
Zm49ZjMwMjEgbWZuPWY5ZmY4IG5yPTENCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU0XSBt
ZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYgZ2ZuPWYzMDIxIG1mbj1mOWZmOCBucj0xDQooWEVO
KSBbMjAxMi0xMC0xMCAxNToxNzo1NF0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzAy
MSBtZm49ZjlmZjggbnI9MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NTRdIG1lbW9yeV9t
YXA6cmVtb3ZlOiBkb20xNiBnZm49ZjMwMjIgbWZuPWY5ZmY5IG5yPTENCihYRU4pIFsyMDEy
LTEwLTEwIDE1OjE3OjU0XSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDIyIG1mbj1m
OWZmOSBucj0xDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzo1NF0gbWVtb3J5X21hcDpyZW1v
dmU6IGRvbTE2IGdmbj1mMzAyMiBtZm49ZjlmZjkgbnI9MQ0KKFhFTikgWzIwMTItMTAtMTAg
MTU6MTc6NTRdIG1lbW9yeV9tYXA6YWRkOiBkb20xNiBnZm49ZjMwMjIgbWZuPWY5ZmY5IG5y
PTENCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU0XSBtZW1vcnlfbWFwOnJlbW92ZTogZG9t
MTYgZ2ZuPWYzMDIyIG1mbj1mOWZmOSBucj0xDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzo1
NF0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzAyMiBtZm49ZjlmZjkgbnI9MQ0KKFhF
TikgWzIwMTItMTAtMTAgMTU6MTc6NTRdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNiBnZm49
ZjMwMjIgbWZuPWY5ZmY5IG5yPTENCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU0XSBtZW1v
cnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDIyIG1mbj1mOWZmOSBucj0xDQooWEVOKSBbMjAx
Mi0xMC0xMCAxNToxNzo1NF0gbWVtb3J5X21hcDpyZW1vdmU6IGRvbTE2IGdmbj1mMzAyMiBt
Zm49ZjlmZjkgbnI9MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NTRdIG1lbW9yeV9tYXA6
YWRkOiBkb20xNiBnZm49ZjMwMjIgbWZuPWY5ZmY5IG5yPTENCihYRU4pIFsyMDEyLTEwLTEw
IDE1OjE3OjU0XSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYgZ2ZuPWYzMDIyIG1mbj1mOWZm
OSBucj0xDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzo1NF0gbWVtb3J5X21hcDphZGQ6IGRv
bTE2IGdmbj1mMzAyMiBtZm49ZjlmZjkgbnI9MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6
NTRdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNiBnZm49ZjMwMjIgbWZuPWY5ZmY5IG5yPTEN
CihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU0XSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2Zu
PWYzMDIyIG1mbj1mOWZmOSBucj0xDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzo1NF0gbWVt
b3J5X21hcDpyZW1vdmU6IGRvbTE2IGdmbj1mMzAyMyBtZm49ZjlmZmEgbnI9MQ0KKFhFTikg
WzIwMTItMTAtMTAgMTU6MTc6NTRdIG1lbW9yeV9tYXA6YWRkOiBkb20xNiBnZm49ZjMwMjMg
bWZuPWY5ZmZhIG5yPTENCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU0XSBtZW1vcnlfbWFw
OnJlbW92ZTogZG9tMTYgZ2ZuPWYzMDIzIG1mbj1mOWZmYSBucj0xDQooWEVOKSBbMjAxMi0x
MC0xMCAxNToxNzo1NF0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzAyMyBtZm49Zjlm
ZmEgbnI9MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NTRdIG1lbW9yeV9tYXA6cmVtb3Zl
OiBkb20xNiBnZm49ZjMwMjMgbWZuPWY5ZmZhIG5yPTENCihYRU4pIFsyMDEyLTEwLTEwIDE1
OjE3OjU0XSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDIzIG1mbj1mOWZmYSBucj0x
DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzo1NF0gbWVtb3J5X21hcDpyZW1vdmU6IGRvbTE2
IGdmbj1mMzAyMyBtZm49ZjlmZmEgbnI9MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NTRd
IG1lbW9yeV9tYXA6YWRkOiBkb20xNiBnZm49ZjMwMjMgbWZuPWY5ZmZhIG5yPTENCihYRU4p
IFsyMDEyLTEwLTEwIDE1OjE3OjU0XSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYgZ2ZuPWYz
MDIzIG1mbj1mOWZmYSBucj0xDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzo1NF0gbWVtb3J5
X21hcDphZGQ6IGRvbTE2IGdmbj1mMzAyMyBtZm49ZjlmZmEgbnI9MQ0KKFhFTikgWzIwMTIt
MTAtMTAgMTU6MTc6NTRdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNiBnZm49ZjMwMjMgbWZu
PWY5ZmZhIG5yPTENCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU0XSBtZW1vcnlfbWFwOmFk
ZDogZG9tMTYgZ2ZuPWYzMDIzIG1mbj1mOWZmYSBucj0xDQooWEVOKSBbMjAxMi0xMC0xMCAx
NToxNzo1NF0gbWVtb3J5X21hcDpyZW1vdmU6IGRvbTE2IGdmbj1mMzAyMyBtZm49ZjlmZmEg
bnI9MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NTRdIG1lbW9yeV9tYXA6YWRkOiBkb20x
NiBnZm49ZjMwMjMgbWZuPWY5ZmZhIG5yPTENCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU0
XSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYgZ2ZuPWYzMDI0IG1mbj1mOWZmYiBucj0xDQoo
WEVOKSBbMjAxMi0xMC0xMCAxNToxNzo1NF0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1m
MzAyNCBtZm49ZjlmZmIgbnI9MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NTRdIG1lbW9y
eV9tYXA6cmVtb3ZlOiBkb20xNiBnZm49ZjMwMjQgbWZuPWY5ZmZiIG5yPTENCihYRU4pIFsy
MDEyLTEwLTEwIDE1OjE3OjU0XSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDI0IG1m
bj1mOWZmYiBucj0xDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzo1NF0gbWVtb3J5X21hcDpy
ZW1vdmU6IGRvbTE2IGdmbj1mMzAyNCBtZm49ZjlmZmIgbnI9MQ0KKFhFTikgWzIwMTItMTAt
MTAgMTU6MTc6NTRdIG1lbW9yeV9tYXA6YWRkOiBkb20xNiBnZm49ZjMwMjQgbWZuPWY5ZmZi
IG5yPTENCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU0XSBtZW1vcnlfbWFwOnJlbW92ZTog
ZG9tMTYgZ2ZuPWYzMDI0IG1mbj1mOWZmYiBucj0xDQooWEVOKSBbMjAxMi0xMC0xMCAxNTox
Nzo1NF0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzAyNCBtZm49ZjlmZmIgbnI9MQ0K
KFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NTRdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNiBn
Zm49ZjMwMjQgbWZuPWY5ZmZiIG5yPTENCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU0XSBt
ZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDI0IG1mbj1mOWZmYiBucj0xDQooWEVOKSBb
MjAxMi0xMC0xMCAxNToxNzo1NF0gbWVtb3J5X21hcDpyZW1vdmU6IGRvbTE2IGdmbj1mMzAy
NCBtZm49ZjlmZmIgbnI9MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NTRdIG1lbW9yeV9t
YXA6YWRkOiBkb20xNiBnZm49ZjMwMjQgbWZuPWY5ZmZiIG5yPTENCihYRU4pIFsyMDEyLTEw
LTEwIDE1OjE3OjU0XSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYgZ2ZuPWYzMDI0IG1mbj1m
OWZmYiBucj0xDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzo1NF0gbWVtb3J5X21hcDphZGQ6
IGRvbTE2IGdmbj1mMzAyNCBtZm49ZjlmZmIgbnI9MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6
MTc6NTRdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNiBnZm49ZjMwMjUgbWZuPWY5ZmZjIG5y
PTENCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU0XSBtZW1vcnlfbWFwOmFkZDogZG9tMTYg
Z2ZuPWYzMDI1IG1mbj1mOWZmYyBucj0xDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzo1NF0g
bWVtb3J5X21hcDpyZW1vdmU6IGRvbTE2IGdmbj1mMzAyNSBtZm49ZjlmZmMgbnI9MQ0KKFhF
TikgWzIwMTItMTAtMTAgMTU6MTc6NTRdIG1lbW9yeV9tYXA6YWRkOiBkb20xNiBnZm49ZjMw
MjUgbWZuPWY5ZmZjIG5yPTENCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU0XSBtZW1vcnlf
bWFwOnJlbW92ZTogZG9tMTYgZ2ZuPWYzMDI1IG1mbj1mOWZmYyBucj0xDQooWEVOKSBbMjAx
Mi0xMC0xMCAxNToxNzo1NF0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzAyNSBtZm49
ZjlmZmMgbnI9MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NTRdIG1lbW9yeV9tYXA6cmVt
b3ZlOiBkb20xNiBnZm49ZjMwMjUgbWZuPWY5ZmZjIG5yPTENCihYRU4pIFsyMDEyLTEwLTEw
IDE1OjE3OjU0XSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDI1IG1mbj1mOWZmYyBu
cj0xDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzo1NF0gbWVtb3J5X21hcDpyZW1vdmU6IGRv
bTE2IGdmbj1mMzAyNSBtZm49ZjlmZmMgbnI9MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6
NTRdIG1lbW9yeV9tYXA6YWRkOiBkb20xNiBnZm49ZjMwMjUgbWZuPWY5ZmZjIG5yPTENCihY
RU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU0XSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYgZ2Zu
PWYzMDI1IG1mbj1mOWZmYyBucj0xDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzo1NF0gbWVt
b3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzAyNSBtZm49ZjlmZmMgbnI9MQ0KKFhFTikgWzIw
MTItMTAtMTAgMTU6MTc6NTRdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNiBnZm49ZjMwMjUg
bWZuPWY5ZmZjIG5yPTENCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU0XSBtZW1vcnlfbWFw
OmFkZDogZG9tMTYgZ2ZuPWYzMDI1IG1mbj1mOWZmYyBucj0xDQooWEVOKSBbMjAxMi0xMC0x
MCAxNToxNzo1NF0gbWVtb3J5X21hcDpyZW1vdmU6IGRvbTE2IGdmbj1mMzAyNiBtZm49Zjlm
ZmQgbnI9MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NTRdIG1lbW9yeV9tYXA6YWRkOiBk
b20xNiBnZm49ZjMwMjYgbWZuPWY5ZmZkIG5yPTENCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3
OjU0XSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYgZ2ZuPWYzMDI2IG1mbj1mOWZmZCBucj0x
DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzo1NF0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdm
bj1mMzAyNiBtZm49ZjlmZmQgbnI9MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NTRdIG1l
bW9yeV9tYXA6cmVtb3ZlOiBkb20xNiBnZm49ZjMwMjYgbWZuPWY5ZmZkIG5yPTENCihYRU4p
IFsyMDEyLTEwLTEwIDE1OjE3OjU0XSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDI2
IG1mbj1mOWZmZCBucj0xDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzo1NF0gbWVtb3J5X21h
cDpyZW1vdmU6IGRvbTE2IGdmbj1mMzAyNiBtZm49ZjlmZmQgbnI9MQ0KKFhFTikgWzIwMTIt
MTAtMTAgMTU6MTc6NTRdIG1lbW9yeV9tYXA6YWRkOiBkb20xNiBnZm49ZjMwMjYgbWZuPWY5
ZmZkIG5yPTENCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU0XSBtZW1vcnlfbWFwOnJlbW92
ZTogZG9tMTYgZ2ZuPWYzMDI2IG1mbj1mOWZmZCBucj0xDQooWEVOKSBbMjAxMi0xMC0xMCAx
NToxNzo1NF0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzAyNiBtZm49ZjlmZmQgbnI9
MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NTRdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20x
NiBnZm49ZjMwMjYgbWZuPWY5ZmZkIG5yPTENCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU0
XSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDI2IG1mbj1mOWZmZCBucj0xDQooWEVO
KSBbMjAxMi0xMC0xMCAxNToxNzo1NF0gbWVtb3J5X21hcDpyZW1vdmU6IGRvbTE2IGdmbj1m
MzAyNiBtZm49ZjlmZmQgbnI9MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NTRdIG1lbW9y
eV9tYXA6YWRkOiBkb20xNiBnZm49ZjMwMjYgbWZuPWY5ZmZkIG5yPTENCihYRU4pIFsyMDEy
LTEwLTEwIDE1OjE3OjU0XSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYgZ2ZuPWYzMDI3IG1m
bj1mOWZmZSBucj0xDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzo1NF0gbWVtb3J5X21hcDph
ZGQ6IGRvbTE2IGdmbj1mMzAyNyBtZm49ZjlmZmUgbnI9MQ0KKFhFTikgWzIwMTItMTAtMTAg
MTU6MTc6NTRdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNiBnZm49ZjMwMjcgbWZuPWY5ZmZl
IG5yPTENCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU0XSBtZW1vcnlfbWFwOmFkZDogZG9t
MTYgZ2ZuPWYzMDI3IG1mbj1mOWZmZSBucj0xDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzo1
NF0gbWVtb3J5X21hcDpyZW1vdmU6IGRvbTE2IGdmbj1mMzAyNyBtZm49ZjlmZmUgbnI9MQ0K
KFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NTRdIG1lbW9yeV9tYXA6YWRkOiBkb20xNiBnZm49
ZjMwMjcgbWZuPWY5ZmZlIG5yPTENCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU0XSBtZW1v
cnlfbWFwOnJlbW92ZTogZG9tMTYgZ2ZuPWYzMDI3IG1mbj1mOWZmZSBucj0xDQooWEVOKSBb
MjAxMi0xMC0xMCAxNToxNzo1NF0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzAyNyBt
Zm49ZjlmZmUgbnI9MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NTRdIG1lbW9yeV9tYXA6
cmVtb3ZlOiBkb20xNiBnZm49ZjMwMjcgbWZuPWY5ZmZlIG5yPTENCihYRU4pIFsyMDEyLTEw
LTEwIDE1OjE3OjU0XSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDI3IG1mbj1mOWZm
ZSBucj0xDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzo1NF0gbWVtb3J5X21hcDpyZW1vdmU6
IGRvbTE2IGdmbj1mMzAyNyBtZm49ZjlmZmUgbnI9MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6
MTc6NTRdIG1lbW9yeV9tYXA6YWRkOiBkb20xNiBnZm49ZjMwMjcgbWZuPWY5ZmZlIG5yPTEN
CihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU0XSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYg
Z2ZuPWYzMDI3IG1mbj1mOWZmZSBucj0xDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzo1NF0g
bWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzAyNyBtZm49ZjlmZmUgbnI9MQ0KKFhFTikg
WzIwMTItMTAtMTAgMTU6MTc6NTRdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNiBnZm49ZjMw
MjggbWZuPWY5ZmZmIG5yPTENCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU0XSBtZW1vcnlf
bWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDI4IG1mbj1mOWZmZiBucj0xDQooWEVOKSBbMjAxMi0x
MC0xMCAxNToxNzo1NF0gbWVtb3J5X21hcDpyZW1vdmU6IGRvbTE2IGdmbj1mMzAyOCBtZm49
ZjlmZmYgbnI9MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NTRdIG1lbW9yeV9tYXA6YWRk
OiBkb20xNiBnZm49ZjMwMjggbWZuPWY5ZmZmIG5yPTENCihYRU4pIFsyMDEyLTEwLTEwIDE1
OjE3OjU0XSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYgZ2ZuPWYzMDI4IG1mbj1mOWZmZiBu
cj0xDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzo1NF0gbWVtb3J5X21hcDphZGQ6IGRvbTE2
IGdmbj1mMzAyOCBtZm49ZjlmZmYgbnI9MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NTRd
IG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNiBnZm49ZjMwMjggbWZuPWY5ZmZmIG5yPTENCihY
RU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU0XSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYz
MDI4IG1mbj1mOWZmZiBucj0xDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzo1NF0gbWVtb3J5
X21hcDpyZW1vdmU6IGRvbTE2IGdmbj1mMzAyOCBtZm49ZjlmZmYgbnI9MQ0KKFhFTikgWzIw
MTItMTAtMTAgMTU6MTc6NTRdIG1lbW9yeV9tYXA6YWRkOiBkb20xNiBnZm49ZjMwMjggbWZu
PWY5ZmZmIG5yPTENCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU0XSBtZW1vcnlfbWFwOnJl
bW92ZTogZG9tMTYgZ2ZuPWYzMDI4IG1mbj1mOWZmZiBucj0xDQooWEVOKSBbMjAxMi0xMC0x
MCAxNToxNzo1NF0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzAyOCBtZm49ZjlmZmYg
bnI9MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NTRdIG1lbW9yeV9tYXA6cmVtb3ZlOiBk
b20xNiBnZm49ZjMwMjggbWZuPWY5ZmZmIG5yPTENCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3
OjU0XSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDI4IG1mbj1mOWZmZiBucj0xDQoo
WEVOKSBbMjAxMi0xMC0xMCAxNToxNzo1NV0gaXJxLmM6MjcwOiBEb20xNiBQQ0kgbGluayAw
IGNoYW5nZWQgNSAtPiAwDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzo1NV0gaXJxLmM6Mjcw
OiBEb20xNiBQQ0kgbGluayAxIGNoYW5nZWQgMTAgLT4gMA0KKFhFTikgWzIwMTItMTAtMTAg
MTU6MTc6NTVdIGlycS5jOjI3MDogRG9tMTYgUENJIGxpbmsgMiBjaGFuZ2VkIDExIC0+IDAN
CihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU1XSBpcnEuYzoyNzA6IERvbTE2IFBDSSBsaW5r
IDMgY2hhbmdlZCA1IC0+IDANCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU2XSBldmVudF9j
aGFubmVsLmM6Mzc3OmQxNiBFVlRDSE5PUCBmYWlsdXJlOiBlcnJvciAtMTcNCihYRU4pIFsy
MDEyLTEwLTEwIDE1OjE3OjU2XSBldmVudF9jaGFubmVsLmM6Mzc3OmQxNiBFVlRDSE5PUCBm
YWlsdXJlOiBlcnJvciAtMTcNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU2XSBldmVudF9j
aGFubmVsLmM6Mzc3OmQxNiBFVlRDSE5PUCBmYWlsdXJlOiBlcnJvciAtMTcNCihYRU4pIFsy
MDEyLTEwLTEwIDE1OjE3OjU2XSBldmVudF9jaGFubmVsLmM6Mzc3OmQxNiBFVlRDSE5PUCBm
YWlsdXJlOiBlcnJvciAtMTcNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU2XSBldmVudF9j
aGFubmVsLmM6Mzc3OmQxNiBFVlRDSE5PUCBmYWlsdXJlOiBlcnJvciAtMTcNCihYRU4pIFsy
MDEyLTEwLTEwIDE1OjE3OjU2XSBldmVudF9jaGFubmVsLmM6Mzc3OmQxNiBFVlRDSE5PUCBm
YWlsdXJlOiBlcnJvciAtMTcNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU2XSBldmVudF9j
aGFubmVsLmM6Mzc3OmQxNiBFVlRDSE5PUCBmYWlsdXJlOiBlcnJvciAtMTcNCihYRU4pIFsy
MDEyLTEwLTEwIDE1OjE3OjU2XSBldmVudF9jaGFubmVsLmM6Mzc3OmQxNiBFVlRDSE5PUCBm
YWlsdXJlOiBlcnJvciAtMTcNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU2XSBldmVudF9j
aGFubmVsLmM6Mzc3OmQxNiBFVlRDSE5PUCBmYWlsdXJlOiBlcnJvciAtMTcNCihYRU4pIFsy
MDEyLTEwLTEwIDE1OjE3OjU2XSBldmVudF9jaGFubmVsLmM6Mzc3OmQxNiBFVlRDSE5PUCBm
YWlsdXJlOiBlcnJvciAtMTcNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU2XSBldmVudF9j
aGFubmVsLmM6Mzc3OmQxNiBFVlRDSE5PUCBmYWlsdXJlOiBlcnJvciAtMTcNCihYRU4pIFsy
MDEyLTEwLTEwIDE1OjE3OjU2XSBldmVudF9jaGFubmVsLmM6Mzc3OmQxNiBFVlRDSE5PUCBm
YWlsdXJlOiBlcnJvciAtMTcNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU3XSBldmVudF9j
aGFubmVsLmM6Mzc3OmQxNiBFVlRDSE5PUCBmYWlsdXJlOiBlcnJvciAtMTcNCihYRU4pIFsy
MDEyLTEwLTEwIDE1OjE3OjU3XSBldmVudF9jaGFubmVsLmM6Mzc3OmQxNiBFVlRDSE5PUCBm
YWlsdXJlOiBlcnJvciAtMTcNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU3XSBldmVudF9j
aGFubmVsLmM6Mzc3OmQxNiBFVlRDSE5PUCBmYWlsdXJlOiBlcnJvciAtMTcNCg==
------------08613C0C31EE607B1
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

------------08613C0C31EE607B1--



From xen-devel-bounces@lists.xen.org Wed Oct 10 16:03:20 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 16:03:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLykR-00033l-Pl; Wed, 10 Oct 2012 16:03:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLykP-00033X-FE
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 16:03:02 +0000
Received: from [85.158.138.51:48397] by server-15.bemta-3.messagelabs.com id
	55/F4-10261-43C95705; Wed, 10 Oct 2012 16:03:00 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-10.tower-174.messagelabs.com!1349884976!26258743!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31003 invoked from network); 10 Oct 2012 16:02:56 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-10.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Oct 2012 16:02:56 -0000
Received: from 50-66-ftth.onsneteindhoven.nl ([88.159.66.50]:59411
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TLyli-0008Bb-6g; Wed, 10 Oct 2012 18:04:22 +0200
Date: Wed, 10 Oct 2012 18:02:53 +0200
From: Sander Eikelenboom 
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1786005637.20121010180253@eikelenboom.it>
To: xen-devel 
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------08613C0C31EE607B1"
Cc: Ian Campbell 
Subject: [Xen-devel] xen-unstable: HVM start memory_map:add
	memory_map:remove cycle
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

------------08613C0C31EE607B1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Ian,

When i start a HVM guest i get this cycle of adding removing adding removing and finally adding ... for some memory ranges during the start of the guest.
I don't know if it's intentionally, but it seems kind of strange .. :

(XEN) [2012-10-10 15:17:54] memory_map:add: dom16 gfn=f3028 mfn=f9fff nr=1
(XEN) [2012-10-10 15:17:54] memory_map:remove: dom16 gfn=f3028 mfn=f9fff nr=1
(XEN) [2012-10-10 15:17:54] memory_map:add: dom16 gfn=f3028 mfn=f9fff nr=1
(XEN) [2012-10-10 15:17:54] memory_map:remove: dom16 gfn=f3028 mfn=f9fff nr=1
(XEN) [2012-10-10 15:17:54] memory_map:add: dom16 gfn=f3028 mfn=f9fff nr=1
(XEN) [2012-10-10 15:17:54] memory_map:remove: dom16 gfn=f3028 mfn=f9fff nr=1
(XEN) [2012-10-10 15:17:54] memory_map:add: dom16 gfn=f3028 mfn=f9fff nr=1
(XEN) [2012-10-10 15:17:54] memory_map:remove: dom16 gfn=f3028 mfn=f9fff nr=1
(XEN) [2012-10-10 15:17:54] memory_map:add: dom16 gfn=f3028 mfn=f9fff nr=1
(XEN) [2012-10-10 15:17:54] memory_map:remove: dom16 gfn=f3028 mfn=f9fff nr=1
(XEN) [2012-10-10 15:17:54] memory_map:add: dom16 gfn=f3028 mfn=f9fff nr=1
(XEN) [2012-10-10 15:17:54] memory_map:remove: dom16 gfn=f3028 mfn=f9fff nr=1
(XEN) [2012-10-10 15:17:54] memory_map:add: dom16 gfn=f3028 mfn=f9fff nr=1


xl dmesg attached

--

Sander
------------08613C0C31EE607B1
Content-Type: text/plain;
 name="xl-dmesg.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="xl-dmesg.txt"

IF9fICBfXyAgICAgICAgICAgIF8gIF8gICAgX19fX18gICAgICAgICAgICAgICAgICAgIF8g
ICAgICAgIF8gICAgIF8gICAgICANCiBcIFwvIC9fX18gXyBfXyAgIHwgfHwgfCAgfF9fXyAv
ICAgIF8gICBfIF8gX18gIF9fX3wgfF8gX18gX3wgfF9fIHwgfCBfX18gDQogIFwgIC8vIF8g
XCAnXyBcICB8IHx8IHxfICAgfF8gXCBfX3wgfCB8IHwgJ18gXC8gX198IF9fLyBfYCB8ICdf
IFx8IHwvIF8gXA0KICAvICBcICBfXy8gfCB8IHwgfF9fICAgX3wgX19fKSB8X198IHxffCB8
IHwgfCBcX18gXCB8fCAoX3wgfCB8XykgfCB8ICBfXy8NCiAvXy9cX1xfX198X3wgfF98ICAg
IHxffChfKV9fX18vICAgIFxfXyxffF98IHxffF9fXy9cX19cX18sX3xfLl9fL3xffFxfX198
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIA0KKFhFTikgWGVuIHZlcnNpb24gNC4zLXVuc3RhYmxl
IChyb290QGR5bmRucy5vcmcpIChnY2MgKERlYmlhbiA0LjQuNS04KSA0LjQuNSkgV2VkIE9j
dCAgMyAxMTo0NTo0NyBDRVNUIDIwMTINCihYRU4pIExhdGVzdCBDaGFuZ2VTZXQ6IFR1ZSBP
Y3QgMDIgMTI6MTQ6MDAgMjAxMiArMDIwMCAyNTk3NTo4N2JmOTlmYWQ3YTkNCihYRU4pIEJv
b3Rsb2FkZXI6IEdSVUIgMS45OCsyMDEwMDgwNC0xNCtzcXVlZXplMQ0KKFhFTikgQ29tbWFu
ZCBsaW5lOiBkb20wX21lbT0xMDI0TSxtYXg6MTAyNE0gbG9nbHZsPWFsbCBsb2dsdmxfZ3Vl
c3Q9YWxsIGNvbnNvbGVfdGltZXN0YW1wcyB2Z2E9Z2Z4LTEyODB4MTAyNHgzMiBjcHVpZGxl
IGNwdWZyZXE9eGVuIHhzYXZlPW9mZiBub3JlYm9vdCBkZWJ1ZyBsYXBpYz1kZWJ1ZyBhcGlj
X3ZlcmJvc2l0eT1kZWJ1ZyBhcGljPWRlYnVnIGlvbW11PW9uLHZlcmJvc2UsZGVidWcsYW1k
LWlvbW11LWRlYnVnIGNvbTE9Mzg0MDAsOG4xIGNvbnNvbGU9dmdhLGNvbTENCihYRU4pIFZp
ZGVvIGluZm9ybWF0aW9uOg0KKFhFTikgIFZHQSBpcyBncmFwaGljcyBtb2RlIDEyODB4MTAy
NCwgMzIgYnBwDQooWEVOKSAgVkJFL0REQyBtZXRob2RzOiBWMjsgRURJRCB0cmFuc2ZlciB0
aW1lOiAxIHNlY29uZHMNCihYRU4pIERpc2MgaW5mb3JtYXRpb246DQooWEVOKSAgRm91bmQg
MiBNQlIgc2lnbmF0dXJlcw0KKFhFTikgIEZvdW5kIDIgRUREIGluZm9ybWF0aW9uIHN0cnVj
dHVyZXMNCihYRU4pIFhlbi1lODIwIFJBTSBtYXA6DQooWEVOKSAgMDAwMDAwMDAwMDAwMDAw
MCAtIDAwMDAwMDAwMDAwOWYwMDAgKHVzYWJsZSkNCihYRU4pICAwMDAwMDAwMDAwMDlmMDAw
IC0gMDAwMDAwMDAwMDBhMDAwMCAocmVzZXJ2ZWQpDQooWEVOKSAgMDAwMDAwMDAwMDBlNDAw
MCAtIDAwMDAwMDAwMDAxMDAwMDAgKHJlc2VydmVkKQ0KKFhFTikgIDAwMDAwMDAwMDAxMDAw
MDAgLSAwMDAwMDAwMGFmZjkwMDAwICh1c2FibGUpDQooWEVOKSAgMDAwMDAwMDBhZmY5MDAw
MCAtIDAwMDAwMDAwYWZmOWUwMDAgKEFDUEkgZGF0YSkNCihYRU4pICAwMDAwMDAwMGFmZjll
MDAwIC0gMDAwMDAwMDBhZmZlMDAwMCAoQUNQSSBOVlMpDQooWEVOKSAgMDAwMDAwMDBhZmZl
MDAwMCAtIDAwMDAwMDAwYjAwMDAwMDAgKHJlc2VydmVkKQ0KKFhFTikgIDAwMDAwMDAwZmZl
MDAwMDAgLSAwMDAwMDAwMTAwMDAwMDAwIChyZXNlcnZlZCkNCihYRU4pICAwMDAwMDAwMTAw
MDAwMDAwIC0gMDAwMDAwMDI1MDAwMDAwMCAodXNhYmxlKQ0KKFhFTikgQUNQSTogUlNEUCAw
MDBGQjEwMCwgMDAxNCAocjAgQUNQSUFNKQ0KKFhFTikgQUNQSTogUlNEVCBBRkY5MDAwMCwg
MDA0OCAocjEgTVNJICAgIE9FTVNMSUMgIDIwMTAwOTEzIE1TRlQgICAgICAgOTcpDQooWEVO
KSBBQ1BJOiBGQUNQIEFGRjkwMjAwLCAwMDg0IChyMSA3NjQwTVMgQTc2NDAxMDAgMjAxMDA5
MTMgTVNGVCAgICAgICA5NykNCihYRU4pIEFDUEk6IERTRFQgQUZGOTA1RTAsIDk0MjcgKHIx
ICBBNzY0MCBBNzY0MDEwMCAgICAgIDEwMCBJTlRMIDIwMDUxMTE3KQ0KKFhFTikgQUNQSTog
RkFDUyBBRkY5RTAwMCwgMDA0MA0KKFhFTikgQUNQSTogQVBJQyBBRkY5MDM5MCwgMDA4OCAo
cjEgNzY0ME1TIEE3NjQwMTAwIDIwMTAwOTEzIE1TRlQgICAgICAgOTcpDQooWEVOKSBBQ1BJ
OiBNQ0ZHIEFGRjkwNDIwLCAwMDNDIChyMSA3NjQwTVMgT0VNTUNGRyAgMjAxMDA5MTMgTVNG
VCAgICAgICA5NykNCihYRU4pIEFDUEk6IFNMSUMgQUZGOTA0NjAsIDAxNzYgKHIxIE1TSSAg
ICBPRU1TTElDICAyMDEwMDkxMyBNU0ZUICAgICAgIDk3KQ0KKFhFTikgQUNQSTogT0VNQiBB
RkY5RTA0MCwgMDA3MiAocjEgNzY0ME1TIEE3NjQwMTAwIDIwMTAwOTEzIE1TRlQgICAgICAg
OTcpDQooWEVOKSBBQ1BJOiBTUkFUIEFGRjlBNUUwLCAwMTA4IChyMyBBTUQgICAgRkFNX0Zf
MTAgICAgICAgIDIgQU1EICAgICAgICAgMSkNCihYRU4pIEFDUEk6IEhQRVQgQUZGOUE2RjAs
IDAwMzggKHIxIDc2NDBNUyBPRU1IUEVUICAyMDEwMDkxMyBNU0ZUICAgICAgIDk3KQ0KKFhF
TikgQUNQSTogSVZSUyBBRkY5QTczMCwgMDBGOCAocjEgIEFNRCAgICAgUkQ4OTBTICAgMjAy
MDMxIEFNRCAgICAgICAgIDApDQooWEVOKSBBQ1BJOiBTU0RUIEFGRjlBODMwLCAwREE0IChy
MSBBIE0gSSAgUE9XRVJOT1cgICAgICAgIDEgQU1EICAgICAgICAgMSkNCihYRU4pIFN5c3Rl
bSBSQU06IDgxOTFNQiAoODM4Nzc3MmtCKQ0KKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyAw
IC0+IE5vZGUgMA0KKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyAxIC0+IE5vZGUgMA0KKFhF
TikgU1JBVDogUFhNIDAgLT4gQVBJQyAyIC0+IE5vZGUgMA0KKFhFTikgU1JBVDogUFhNIDAg
LT4gQVBJQyAzIC0+IE5vZGUgMA0KKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyA0IC0+IE5v
ZGUgMA0KKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyA1IC0+IE5vZGUgMA0KKFhFTikgU1JB
VDogTm9kZSAwIFBYTSAwIDAtYTAwMDANCihYRU4pIFNSQVQ6IE5vZGUgMCBQWE0gMCAxMDAw
MDAtYjAwMDAwMDANCihYRU4pIFNSQVQ6IE5vZGUgMCBQWE0gMCAxMDAwMDAwMDAtMjUwMDAw
MDAwDQooWEVOKSBOVU1BOiBBbGxvY2F0ZWQgbWVtbm9kZW1hcCBmcm9tIDI0ZGMyYTAwMCAt
IDI0ZGMyZDAwMA0KKFhFTikgTlVNQTogVXNpbmcgOCBmb3IgdGhlIGhhc2ggc2hpZnQuDQoo
WEVOKSBEb21haW4gaGVhcCBpbml0aWFsaXNlZA0KKFhFTikgdmVzYWZiOiBmcmFtZWJ1ZmZl
ciBhdCAweGZiMDAwMDAwLCBtYXBwZWQgdG8gMHhmZmZmODJjMDAwMDAwMDAwLCB1c2luZyA2
MTQ0aywgdG90YWwgMTQzMzZrDQooWEVOKSB2ZXNhZmI6IG1vZGUgaXMgMTI4MHgxMDI0eDMy
LCBsaW5lbGVuZ3RoPTUxMjAsIGZvbnQgOHgxNg0KKFhFTikgdmVzYWZiOiBUcnVlY29sb3I6
IHNpemU9ODo4Ojg6OCwgc2hpZnQ9MjQ6MTY6ODowDQooWEVOKSBmb3VuZCBTTVAgTVAtdGFi
bGUgYXQgMDAwZmY3ODANCihYRU4pIERNSSBwcmVzZW50Lg0KKFhFTikgQVBJQyBib290IHN0
YXRlIGlzICd4YXBpYycNCihYRU4pIFVzaW5nIEFQSUMgZHJpdmVyIGRlZmF1bHQNCihYRU4p
IEFDUEk6IFBNLVRpbWVyIElPIFBvcnQ6IDB4ODA4DQooWEVOKSBBQ1BJOiBBQ1BJIFNMRUVQ
IElORk86IHBtMXhfY250WzgwNCwwXSwgcG0xeF9ldnRbODAwLDBdDQooWEVOKSBBQ1BJOiAg
ICAgICAgICAgICAgICAgIHdha2V1cF92ZWNbYWZmOWUwMGNdLCB2ZWNfc2l6ZVsyMF0NCihY
RU4pIEFDUEk6IExvY2FsIEFQSUMgYWRkcmVzcyAweGZlZTAwMDAwDQooWEVOKSBBQ1BJOiBM
QVBJQyAoYWNwaV9pZFsweDAxXSBsYXBpY19pZFsweDAwXSBlbmFibGVkKQ0KKFhFTikgUHJv
Y2Vzc29yICMwIDA6MTAgQVBJQyB2ZXJzaW9uIDE2DQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNw
aV9pZFsweDAyXSBsYXBpY19pZFsweDAxXSBlbmFibGVkKQ0KKFhFTikgUHJvY2Vzc29yICMx
IDA6MTAgQVBJQyB2ZXJzaW9uIDE2DQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAz
XSBsYXBpY19pZFsweDAyXSBlbmFibGVkKQ0KKFhFTikgUHJvY2Vzc29yICMyIDA6MTAgQVBJ
QyB2ZXJzaW9uIDE2DQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA0XSBsYXBpY19p
ZFsweDAzXSBlbmFibGVkKQ0KKFhFTikgUHJvY2Vzc29yICMzIDA6MTAgQVBJQyB2ZXJzaW9u
IDE2DQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA1XSBsYXBpY19pZFsweDA0XSBl
bmFibGVkKQ0KKFhFTikgUHJvY2Vzc29yICM0IDA6MTAgQVBJQyB2ZXJzaW9uIDE2DQooWEVO
KSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA2XSBsYXBpY19pZFsweDA1XSBlbmFibGVkKQ0K
KFhFTikgUHJvY2Vzc29yICM1IDA6MTAgQVBJQyB2ZXJzaW9uIDE2DQooWEVOKSBBQ1BJOiBJ
T0FQSUMgKGlkWzB4MDZdIGFkZHJlc3NbMHhmZWMwMDAwMF0gZ3NpX2Jhc2VbMF0pDQooWEVO
KSBJT0FQSUNbMF06IGFwaWNfaWQgNiwgdmVyc2lvbiAzMywgYWRkcmVzcyAweGZlYzAwMDAw
LCBHU0kgMC0yMw0KKFhFTikgQUNQSTogSU9BUElDIChpZFsweDA3XSBhZGRyZXNzWzB4ZmVj
MjAwMDBdIGdzaV9iYXNlWzI0XSkNCihYRU4pIElPQVBJQ1sxXTogYXBpY19pZCA3LCB2ZXJz
aW9uIDMzLCBhZGRyZXNzIDB4ZmVjMjAwMDAsIEdTSSAyNC01NQ0KKFhFTikgQUNQSTogSU5U
X1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEgMCBnbG9iYWxfaXJxIDIgZGZsIGRmbCkNCihYRU4p
IEFDUEk6IElOVF9TUkNfT1ZSIChidXMgMCBidXNfaXJxIDkgZ2xvYmFsX2lycSA5IGxvdyBs
ZXZlbCkNCihYRU4pIEFDUEk6IElSUTAgdXNlZCBieSBvdmVycmlkZS4NCihYRU4pIEFDUEk6
IElSUTIgdXNlZCBieSBvdmVycmlkZS4NCihYRU4pIEFDUEk6IElSUTkgdXNlZCBieSBvdmVy
cmlkZS4NCihYRU4pIEVuYWJsaW5nIEFQSUMgbW9kZTogIEZsYXQuICBVc2luZyAyIEkvTyBB
UElDcw0KKFhFTikgQUNQSTogSFBFVCBpZDogMHg4MzAwIGJhc2U6IDB4ZmVkMDAwMDANCihY
RU4pIFRhYmxlIGlzIG5vdCBmb3VuZCENCihYRU4pIFVzaW5nIEFDUEkgKE1BRFQpIGZvciBT
TVAgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbg0KKFhFTikgU01QOiBBbGxvd2luZyA2IENQ
VXMgKDAgaG90cGx1ZyBDUFVzKQ0KKFhFTikgbWFwcGVkIEFQSUMgdG8gZmZmZjgyYzNmZmRm
YjAwMCAoZmVlMDAwMDApDQooWEVOKSBtYXBwZWQgSU9BUElDIHRvIGZmZmY4MmMzZmZkZmEw
MDAgKGZlYzAwMDAwKQ0KKFhFTikgbWFwcGVkIElPQVBJQyB0byBmZmZmODJjM2ZmZGY5MDAw
IChmZWMyMDAwMCkNCihYRU4pIElSUSBsaW1pdHM6IDU2IEdTSSwgMTExMiBNU0kvTVNJLVgN
CihYRU4pIFVzaW5nIHNjaGVkdWxlcjogU01QIENyZWRpdCBTY2hlZHVsZXIgKGNyZWRpdCkN
CihYRU4pIERldGVjdGVkIDMyMDAuMTgwIE1IeiBwcm9jZXNzb3IuDQooWEVOKSBJbml0aW5n
IG1lbW9yeSBzaGFyaW5nLg0KKFhFTikgQU1EIEZhbTEwaCBtYWNoaW5lIGNoZWNrIHJlcG9y
dGluZyBlbmFibGVkDQooWEVOKSBQQ0k6IE1DRkcgY29uZmlndXJhdGlvbiAwOiBiYXNlIGUw
MDAwMDAwIHNlZ21lbnQgMDAwMCBidXNlcyAwMCAtIGZmDQooWEVOKSBQQ0k6IE5vdCB1c2lu
ZyBNQ0ZHIGZvciBzZWdtZW50IDAwMDAgYnVzIDAwLWZmDQooWEVOKSBBTUQtVmk6IEZvdW5k
IE1TSSBjYXBhYmlsaXR5IGJsb2NrIGF0IDB4NTQNCihYRU4pIEFNRC1WaTogQUNQSSBUYWJs
ZToNCihYRU4pIEFNRC1WaTogIFNpZ25hdHVyZSBJVlJTDQooWEVOKSBBTUQtVmk6ICBMZW5n
dGggMHhmOA0KKFhFTikgQU1ELVZpOiAgUmV2aXNpb24gMHgxDQooWEVOKSBBTUQtVmk6ICBD
aGVja1N1bSAweDk4DQooWEVOKSBBTUQtVmk6ICBPRU1fSWQgQU1EICANCihYRU4pIEFNRC1W
aTogIE9FTV9UYWJsZV9JZCBSRDg5MFMNCihYRU4pIEFNRC1WaTogIE9FTV9SZXZpc2lvbiAw
eDIwMjAzMQ0KKFhFTikgQU1ELVZpOiAgQ3JlYXRvcl9JZCBBTUQgDQooWEVOKSBBTUQtVmk6
ICBDcmVhdG9yX1JldmlzaW9uIDANCihYRU4pIEFNRC1WaTogSVZSUyBCbG9jazoNCihYRU4p
IEFNRC1WaTogIFR5cGUgMHgxMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgzZQ0KKFhFTikg
QU1ELVZpOiAgTGVuZ3RoIDB4YzgNCihYRU4pIEFNRC1WaTogIERldl9JZCAweDINCihYRU4p
IEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mw0K
KFhFTikgQU1ELVZpOiAgRGV2X0lkIDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDANCihYRU4p
IEFNRC1WaTogIERldl9JZCBSYW5nZTogMCAtPiAweDINCihYRU4pIEFNRC1WaTogSVZIRCBE
ZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAg
RGV2X0lkIDB4MTANCihYRU4pIEFNRC1WaTogIEZsYWdzIDANCihYRU4pIEFNRC1WaTogSVZI
RCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZp
OiAgRGV2X0lkIDB4YTAwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAwDQooWEVOKSBBTUQtVmk6
IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFN
RC1WaTogIERldl9JZCAweDE4DQooWEVOKSBBTUQtVmk6ICBGbGFncyAwDQooWEVOKSBBTUQt
Vmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDMNCihYRU4p
IEFNRC1WaTogIERldl9JZCAweDkwMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMA0KKFhFTikg
QU1ELVZpOiAgRGV2X0lkIFJhbmdlOiAweDkwMCAtPiAweDkwNw0KKFhFTikgQU1ELVZpOiBJ
VkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQt
Vmk6ICBEZXZfSWQgMHgyOA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMA0KKFhFTikgQU1ELVZp
OiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBB
TUQtVmk6ICBEZXZfSWQgMHg4MDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDANCihYRU4pIEFN
RC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhF
TikgQU1ELVZpOiAgRGV2X0lkIDB4MzANCihYRU4pIEFNRC1WaTogIEZsYWdzIDANCihYRU4p
IEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0K
KFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4NzAwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAwDQoo
WEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAw
eDINCihYRU4pIEFNRC1WaTogIERldl9JZCAweDUwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAw
DQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlw
ZSAweDINCihYRU4pIEFNRC1WaTogIERldl9JZCAweDYwMA0KKFhFTikgQU1ELVZpOiAgRmxh
Z3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTog
IFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHg1OA0KKFhFTikgQU1ELVZpOiAg
RmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1W
aTogIFR5cGUgMHgzDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHg1MDANCihYRU4pIEFNRC1W
aTogIEZsYWdzIDANCihYRU4pIEFNRC1WaTogIERldl9JZCBSYW5nZTogMHg1MDAgLT4gMHg1
MDENCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBU
eXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4NjgNCihYRU4pIEFNRC1WaTogIEZs
YWdzIDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6
ICBUeXBlIDB4Mw0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4NDAwDQooWEVOKSBBTUQtVmk6
ICBGbGFncyAwDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4NDAwIC0+IDB4NDA3
DQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlw
ZSAweDINCihYRU4pIEFNRC1WaTogIERldl9JZCAweDg4DQooWEVOKSBBTUQtVmk6ICBGbGFn
cyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAg
VHlwZSAweDMNCihYRU4pIEFNRC1WaTogIERldl9JZCAweDkwDQooWEVOKSBBTUQtVmk6ICBG
bGFncyAwDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4OTAgLT4gMHg5Mg0KKFhF
TikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgz
DQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHg5OA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMA0K
KFhFTikgQU1ELVZpOiAgRGV2X0lkIFJhbmdlOiAweDk4IC0+IDB4OWENCihYRU4pIEFNRC1W
aTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikg
QU1ELVZpOiAgRGV2X0lkIDB4YTANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4ZDcNCihYRU4p
IEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0K
KFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4YTENCihYRU4pIEFNRC1WaTogIEZsYWdzIDANCihY
RU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4
Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4YTINCihYRU4pIEFNRC1WaTogIEZsYWdzIDAN
CihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBl
IDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4YTMNCihYRU4pIEFNRC1WaTogIEZsYWdz
IDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBU
eXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4YTQNCihYRU4pIEFNRC1WaTogIEZs
YWdzIDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6
ICBUeXBlIDANCihYRU4pIEFNRC1WaTogIERldl9JZCAwDQooWEVOKSBBTUQtVmk6ICBGbGFn
cyAwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgc3B1cmlvdXMg
ODI1OUEgaW50ZXJydXB0OiBJUlE3Lg0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDQzDQooWEVO
KSBBTUQtVmk6ICBEZXZfSWQgMHgzMDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDANCihYRU4p
IEFNRC1WaTogIERldl9JZCBSYW5nZTogMHgzMDAgLT4gMHgzZmYNCihYRU4pIEFNRC1WaTog
IERldl9JZCBBbGlhczogMHhhNA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToN
CihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHhhNQ0K
KFhFTikgQU1ELVZpOiAgRmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRy
eToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHhh
OA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBF
bnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQg
MHhhOQ0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmlj
ZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZf
SWQgMHgxMDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDANCihYRU4pIEFNRC1WaTogSVZIRCBE
ZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mw0KKFhFTikgQU1ELVZpOiAg
RGV2X0lkIDB4YjANCihYRU4pIEFNRC1WaTogIEZsYWdzIDANCihYRU4pIEFNRC1WaTogIERl
dl9JZCBSYW5nZTogMHhiMCAtPiAweGIyDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVu
dHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAwDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMA0K
KFhFTikgQU1ELVZpOiAgRmxhZ3MgMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRy
eToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHg0OA0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDAN
CihYRU4pIEFNRC1WaTogIEZsYWdzIDB4ZDcNCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2Ug
RW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4NDgNCihYRU4pIEFNRC1WaTogIERldl9J
ZCAwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAwDQooWEVOKSBBTUQtVmk6IElPTU1VIDAgRW5h
YmxlZC4NCihYRU4pIEFNRC1WaTogRW5hYmxpbmcgZ2xvYmFsIHZlY3RvciBtYXANCihYRU4p
IEkvTyB2aXJ0dWFsaXNhdGlvbiBlbmFibGVkDQooWEVOKSAgLSBEb20wIG1vZGU6IFJlbGF4
ZWQNCihYRU4pIEdldHRpbmcgVkVSU0lPTjogODAwNTAwMTANCihYRU4pIEdldHRpbmcgVkVS
U0lPTjogODAwNTAwMTANCihYRU4pIEdldHRpbmcgSUQ6IDANCihYRU4pIEdldHRpbmcgTFZU
MDogNzAwDQooWEVOKSBHZXR0aW5nIExWVDE6IDQwMA0KKFhFTikgZW5hYmxlZCBFeHRJTlQg
b24gQ1BVIzANCihYRU4pIEVTUiB2YWx1ZSBiZWZvcmUgZW5hYmxpbmcgdmVjdG9yOiAweDQg
IGFmdGVyOiAwDQooWEVOKSBFTkFCTElORyBJTy1BUElDIElSUXMNCihYRU4pICAtPiBVc2lu
ZyBuZXcgQUNLIG1ldGhvZA0KKFhFTikgaW5pdCBJT19BUElDIElSUXMNCihYRU4pICBJTy1B
UElDIChhcGljaWQtcGluKSA2LTAsIDYtMTYsIDYtMTcsIDYtMTgsIDYtMTksIDYtMjAsIDYt
MjEsIDYtMjIsIDYtMjMsIDctMCwgNy0xLCA3LTIsIDctMywgNy00LCA3LTUsIDctNiwgNy03
LCA3LTgsIDctOSwgNy0xMCwgNy0xMSwgNy0xMiwgNy0xMywgNy0xNCwgNy0xNSwgNy0xNiwg
Ny0xNywgNy0xOCwgNy0xOSwgNy0yMCwgNy0yMSwgNy0yMiwgNy0yMywgNy0yNCwgNy0yNSwg
Ny0yNiwgNy0yNywgNy0yOCwgNy0yOSwgNy0zMCwgNy0zMSBub3QgY29ubmVjdGVkLg0KKFhF
TikgLi5USU1FUjogdmVjdG9yPTB4RjAgYXBpYzE9MCBwaW4xPTIgYXBpYzI9LTEgcGluMj0t
MQ0KKFhFTikgbnVtYmVyIG9mIE1QIElSUSBzb3VyY2VzOiAxNS4NCihYRU4pIG51bWJlciBv
ZiBJTy1BUElDICM2IHJlZ2lzdGVyczogMjQuDQooWEVOKSBudW1iZXIgb2YgSU8tQVBJQyAj
NyByZWdpc3RlcnM6IDMyLg0KKFhFTikgdGVzdGluZyB0aGUgSU8gQVBJQy4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uDQooWEVOKSBJTyBBUElDICM2Li4uLi4uDQooWEVOKSAuLi4uIHJlZ2lz
dGVyICMwMDogMDYwMDAwMDANCihYRU4pIC4uLi4uLi4gICAgOiBwaHlzaWNhbCBBUElDIGlk
OiAwNg0KKFhFTikgLi4uLi4uLiAgICA6IERlbGl2ZXJ5IFR5cGU6IDANCihYRU4pIC4uLi4u
Li4gICAgOiBMVFMgICAgICAgICAgOiAwDQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMTogMDAx
NzgwMjENCihYRU4pIC4uLi4uLi4gICAgIDogbWF4IHJlZGlyZWN0aW9uIGVudHJpZXM6IDAw
MTcNCihYRU4pIC4uLi4uLi4gICAgIDogUFJRIGltcGxlbWVudGVkOiAxDQooWEVOKSAuLi4u
Li4uICAgICA6IElPIEFQSUMgdmVyc2lvbjogMDAyMQ0KKFhFTikgLi4uLiByZWdpc3RlciAj
MDI6IDA2MDAwMDAwDQooWEVOKSAuLi4uLi4uICAgICA6IGFyYml0cmF0aW9uOiAwNg0KKFhF
TikgLi4uLiByZWdpc3RlciAjMDM6IDA3MDAwMDAwDQooWEVOKSAuLi4uLi4uICAgICA6IEJv
b3QgRFQgICAgOiAwDQooWEVOKSAuLi4uIElSUSByZWRpcmVjdGlvbiB0YWJsZToNCihYRU4p
ICBOUiBMb2cgUGh5IE1hc2sgVHJpZyBJUlIgUG9sIFN0YXQgRGVzdCBEZWxpIFZlY3Q6ICAg
DQooWEVOKSAgMDAgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAw
MA0KKFhFTikgIDAxIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAg
MzANCihYRU4pICAwMiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAg
IEYwDQooWEVOKSAgMDMgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAg
ICAzOA0KKFhFTikgIDA0IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEg
ICAgRjENCihYRU4pICAwNSAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAx
ICAgIDQwDQooWEVOKSAgMDYgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAg
MSAgICA0OA0KKFhFTikgIDA3IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAg
IDEgICAgNTANCihYRU4pICAwOCAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAg
ICAxICAgIDU4DQooWEVOKSAgMDkgMDAxIDAxICAxICAgIDEgICAgMCAgIDEgICAwICAgIDEg
ICAgMSAgICA2MA0KKFhFTikgIDBhIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAx
ICAgIDEgICAgNjgNCihYRU4pICAwYiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAg
MSAgICAxICAgIDcwDQooWEVOKSAgMGMgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAg
IDEgICAgMSAgICA3OA0KKFhFTikgIDBkIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAg
ICAxICAgIDEgICAgODgNCihYRU4pICAwZSAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAg
ICAgMSAgICAxICAgIDkwDQooWEVOKSAgMGYgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAw
ICAgIDEgICAgMSAgICA5OA0KKFhFTikgIDEwIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAg
MCAgICAwICAgIDAgICAgMDANCihYRU4pICAxMSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAg
IDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMTIgMDAwIDAwICAxICAgIDAgICAgMCAgIDAg
ICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDEzIDAwMCAwMCAgMSAgICAwICAgIDAgICAw
ICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAxNCAwMDAgMDAgIDEgICAgMCAgICAwICAg
MCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMTUgMDAwIDAwICAxICAgIDAgICAgMCAg
IDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDE2IDAwMCAwMCAgMSAgICAwICAgIDAg
ICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAxNyAwMDAgMDAgIDEgICAgMCAgICAw
ICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSBJTyBBUElDICM3Li4uLi4uDQooWEVO
KSAuLi4uIHJlZ2lzdGVyICMwMDogMDcwMDAwMDANCihYRU4pIC4uLi4uLi4gICAgOiBwaHlz
aWNhbCBBUElDIGlkOiAwNw0KKFhFTikgLi4uLi4uLiAgICA6IERlbGl2ZXJ5IFR5cGU6IDAN
CihYRU4pIC4uLi4uLi4gICAgOiBMVFMgICAgICAgICAgOiAwDQooWEVOKSAuLi4uIHJlZ2lz
dGVyICMwMTogMDAxRjgwMjENCihYRU4pIC4uLi4uLi4gICAgIDogbWF4IHJlZGlyZWN0aW9u
IGVudHJpZXM6IDAwMUYNCihYRU4pIC4uLi4uLi4gICAgIDogUFJRIGltcGxlbWVudGVkOiAx
DQooWEVOKSAuLi4uLi4uICAgICA6IElPIEFQSUMgdmVyc2lvbjogMDAyMQ0KKFhFTikgLi4u
LiByZWdpc3RlciAjMDI6IDAwMDAwMDAwDQooWEVOKSAuLi4uLi4uICAgICA6IGFyYml0cmF0
aW9uOiAwMA0KKFhFTikgLi4uLiBJUlEgcmVkaXJlY3Rpb24gdGFibGU6DQooWEVOKSAgTlIg
TG9nIFBoeSBNYXNrIFRyaWcgSVJSIFBvbCBTdGF0IERlc3QgRGVsaSBWZWN0OiAgIA0KKFhF
TikgIDAwIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihY
RU4pICAwMSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQoo
WEVOKSAgMDIgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0K
KFhFTikgIDAzIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDAN
CihYRU4pICAwNCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAw
DQooWEVOKSAgMDUgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAw
MA0KKFhFTikgIDA2IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDANCihYRU4pICAwNyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwDQooWEVOKSAgMDggMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAg
ICAwMA0KKFhFTikgIDA5IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAg
ICAgMDANCihYRU4pICAwYSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAw
ICAgIDAwDQooWEVOKSAgMGIgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAg
MCAgICAwMA0KKFhFTikgIDBjIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAg
IDAgICAgMDANCihYRU4pICAwZCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAg
ICAwICAgIDAwDQooWEVOKSAgMGUgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAg
ICAgMCAgICAwMA0KKFhFTikgIDBmIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAw
ICAgIDAgICAgMDANCihYRU4pICAxMCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAg
MCAgICAwICAgIDAwDQooWEVOKSAgMTEgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAg
IDAgICAgMCAgICAwMA0KKFhFTikgIDEyIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAg
ICAwICAgIDAgICAgMDANCihYRU4pICAxMyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAg
ICAgMCAgICAwICAgIDAwDQooWEVOKSAgMTQgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAw
ICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDE1IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAg
MCAgICAwICAgIDAgICAgMDANCihYRU4pICAxNiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAg
IDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMTcgMDAwIDAwICAxICAgIDAgICAgMCAgIDAg
ICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDE4IDAwMCAwMCAgMSAgICAwICAgIDAgICAw
ICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAxOSAwMDAgMDAgIDEgICAgMCAgICAwICAg
MCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMWEgMDAwIDAwICAxICAgIDAgICAgMCAg
IDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDFiIDAwMCAwMCAgMSAgICAwICAgIDAg
ICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAxYyAwMDAgMDAgIDEgICAgMCAgICAw
ICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMWQgMDAwIDAwICAxICAgIDAgICAg
MCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDFlIDAwMCAwMCAgMSAgICAwICAg
IDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAxZiAwMDAgMDAgIDEgICAgMCAg
ICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSBVc2luZyB2ZWN0b3ItYmFzZWQg
aW5kZXhpbmcNCihYRU4pIElSUSB0byBwaW4gbWFwcGluZ3M6DQooWEVOKSBJUlEyNDAgLT4g
MDoyDQooWEVOKSBJUlE0OCAtPiAwOjENCihYRU4pIElSUTU2IC0+IDA6Mw0KKFhFTikgSVJR
MjQxIC0+IDA6NA0KKFhFTikgSVJRNjQgLT4gMDo1DQooWEVOKSBJUlE3MiAtPiAwOjYNCihY
RU4pIElSUTgwIC0+IDA6Nw0KKFhFTikgSVJRODggLT4gMDo4DQooWEVOKSBJUlE5NiAtPiAw
OjkNCihYRU4pIElSUTEwNCAtPiAwOjEwDQooWEVOKSBJUlExMTIgLT4gMDoxMQ0KKFhFTikg
SVJRMTIwIC0+IDA6MTINCihYRU4pIElSUTEzNiAtPiAwOjEzDQooWEVOKSBJUlExNDQgLT4g
MDoxNA0KKFhFTikgSVJRMTUyIC0+IDA6MTUNCihYRU4pIC4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLiBkb25lLg0KKFhFTikgVXNpbmcgbG9jYWwgQVBJQyB0aW1lciBp
bnRlcnJ1cHRzLg0KKFhFTikgY2FsaWJyYXRpbmcgQVBJQyB0aW1lciAuLi4NCihYRU4pIC4u
Li4uIENQVSBjbG9jayBzcGVlZCBpcyAzMjAwLjEyOTUgTUh6Lg0KKFhFTikgLi4uLi4gaG9z
dCBidXMgY2xvY2sgc3BlZWQgaXMgMjAwLjAwODAgTUh6Lg0KKFhFTikgLi4uLi4gYnVzX3Nj
YWxlID0gMHhjY2Q3DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxM10gUGxhdGZvcm0gdGlt
ZXIgaXMgMTQuMzE4TUh6IEhQRVQNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjEzOjEzXSBBbGxv
Y2F0ZWQgY29uc29sZSByaW5nIG9mIDY0IEtpQi4NCihYRU4pIFsyMDEyLTEwLTEwIDE1OjEz
OjEzXSBIVk06IEFTSURzIGVuYWJsZWQuDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxM10g
U1ZNOiBTdXBwb3J0ZWQgYWR2YW5jZWQgZmVhdHVyZXM6DQooWEVOKSBbMjAxMi0xMC0xMCAx
NToxMzoxM10gIC0gTmVzdGVkIFBhZ2UgVGFibGVzIChOUFQpDQooWEVOKSBbMjAxMi0xMC0x
MCAxNToxMzoxM10gIC0gTGFzdCBCcmFuY2ggUmVjb3JkIChMQlIpIFZpcnR1YWxpc2F0aW9u
DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxM10gIC0gTmV4dC1SSVAgU2F2ZWQgb24gI1ZN
RVhJVA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTM6MTNdICAtIFBhdXNlLUludGVyY2VwdCBG
aWx0ZXINCihYRU4pIFsyMDEyLTEwLTEwIDE1OjEzOjEzXSBIVk06IFNWTSBlbmFibGVkDQoo
WEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxM10gSFZNOiBIYXJkd2FyZSBBc3Npc3RlZCBQYWdp
bmcgKEhBUCkgZGV0ZWN0ZWQNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjEzOjEzXSBIVk06IEhB
UCBwYWdlIHNpemVzOiA0a0IsIDJNQiwgMUdCDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzox
Ml0gbWFza2VkIEV4dElOVCBvbiBDUFUjMQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTM6MTNd
IG1pY3JvY29kZTogY29sbGVjdF9jcHVfaW5mbzogcGF0Y2hfaWQ9MHgxMDAwMGJmDQooWEVO
KSBbMjAxMi0xMC0xMCAxNToxMzoxMl0gbWFza2VkIEV4dElOVCBvbiBDUFUjMg0KKFhFTikg
WzIwMTItMTAtMTAgMTU6MTM6MTNdIG1pY3JvY29kZTogY29sbGVjdF9jcHVfaW5mbzogcGF0
Y2hfaWQ9MHgxMDAwMGJmDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxMl0gbWFza2VkIEV4
dElOVCBvbiBDUFUjMw0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTM6MTNdIG1pY3JvY29kZTog
Y29sbGVjdF9jcHVfaW5mbzogcGF0Y2hfaWQ9MHgxMDAwMGJmDQooWEVOKSBbMjAxMi0xMC0x
MCAxNToxMzoxMl0gbWFza2VkIEV4dElOVCBvbiBDUFUjNA0KKFhFTikgWzIwMTItMTAtMTAg
MTU6MTM6MTNdIG1pY3JvY29kZTogY29sbGVjdF9jcHVfaW5mbzogcGF0Y2hfaWQ9MHgxMDAw
MGJmDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxMl0gbWFza2VkIEV4dElOVCBvbiBDUFUj
NQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTM6MTNdIEJyb3VnaHQgdXAgNiBDUFVzDQooWEVO
KSBbMjAxMi0xMC0xMCAxNToxMzoxM10gbWljcm9jb2RlOiBjb2xsZWN0X2NwdV9pbmZvOiBw
YXRjaF9pZD0weDEwMDAwYmYNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjEzOjEzXSBIUEVUJ3Mg
TVNJIG1vZGUgaGFzbid0IGJlZW4gc3VwcG9ydGVkIHdoZW4gSW50ZXJydXB0IFJlbWFwcGlu
ZyBpcyBlbmFibGVkLg0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTM6MTNdIEFDUEkgc2xlZXAg
bW9kZXM6IFMzDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxM10gTUNBOiBVc2UgaHcgdGhy
ZXNob2xkaW5nIHRvIGFkanVzdCBwb2xsaW5nIGZyZXF1ZW5jeQ0KKFhFTikgWzIwMTItMTAt
MTAgMTU6MTM6MTNdIG1jaGVja19wb2xsOiBNYWNoaW5lIGNoZWNrIHBvbGxpbmcgdGltZXIg
c3RhcnRlZC4NCihYRU4pIFsyMDEyLTEwLTEwIDE1OjEzOjEzXSBYZW5vcHJvZmlsZTogRmFp
bGVkIHRvIHNldHVwIElCUyBMVlQgb2Zmc2V0LCBJQlNDVEwgPSAweGZmZmZmZmZmDQooWEVO
KSBbMjAxMi0xMC0xMCAxNToxMzoxM10gKioqIExPQURJTkcgRE9NQUlOIDAgKioqDQooWEVO
KSBbMjAxMi0xMC0xMCAxNToxMzoxM10gZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9
MHgxMDAwMDAwIG1lbXN6PTB4YWYyMDAwDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxM10g
ZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgxYzAwMDAwIG1lbXN6PTB4Y2EwZTgN
CihYRU4pIFsyMDEyLTEwLTEwIDE1OjEzOjEzXSBlbGZfcGFyc2VfYmluYXJ5OiBwaGRyOiBw
YWRkcj0weDFjY2IwMDAgbWVtc3o9MHgxM2NjMA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTM6
MTNdIGVsZl9wYXJzZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4MWNkZjAwMCBtZW1zej0weGRl
NjAwMA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTM6MTNdIGVsZl9wYXJzZV9iaW5hcnk6IG1l
bW9yeTogMHgxMDAwMDAwIC0+IDB4MmFjNTAwMA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTM6
MTNdIGVsZl94ZW5fcGFyc2Vfbm90ZTogR1VFU1RfT1MgPSAibGludXgiDQooWEVOKSBbMjAx
Mi0xMC0xMCAxNToxMzoxM10gZWxmX3hlbl9wYXJzZV9ub3RlOiBHVUVTVF9WRVJTSU9OID0g
IjIuNiINCihYRU4pIFsyMDEyLTEwLTEwIDE1OjEzOjEzXSBlbGZfeGVuX3BhcnNlX25vdGU6
IFhFTl9WRVJTSU9OID0gInhlbi0zLjAiDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxM10g
ZWxmX3hlbl9wYXJzZV9ub3RlOiBWSVJUX0JBU0UgPSAweGZmZmZmZmZmODAwMDAwMDANCihY
RU4pIFsyMDEyLTEwLTEwIDE1OjEzOjEzXSBlbGZfeGVuX3BhcnNlX25vdGU6IEVOVFJZID0g
MHhmZmZmZmZmZjgxY2RmMjEwDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxM10gZWxmX3hl
bl9wYXJzZV9ub3RlOiBIWVBFUkNBTExfUEFHRSA9IDB4ZmZmZmZmZmY4MTAwMTAwMA0KKFhF
TikgWzIwMTItMTAtMTAgMTU6MTM6MTNdIGVsZl94ZW5fcGFyc2Vfbm90ZTogRkVBVFVSRVMg
PSAiIXdyaXRhYmxlX3BhZ2VfdGFibGVzfHBhZV9wZ2Rpcl9hYm92ZV80Z2IiDQooWEVOKSBb
MjAxMi0xMC0xMCAxNToxMzoxM10gZWxmX3hlbl9wYXJzZV9ub3RlOiBQQUVfTU9ERSA9ICJ5
ZXMiDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxM10gZWxmX3hlbl9wYXJzZV9ub3RlOiBM
T0FERVIgPSAiZ2VuZXJpYyINCihYRU4pIFsyMDEyLTEwLTEwIDE1OjEzOjEzXSBlbGZfeGVu
X3BhcnNlX25vdGU6IHVua25vd24geGVuIGVsZiBub3RlICgweGQpDQooWEVOKSBbMjAxMi0x
MC0xMCAxNToxMzoxM10gZWxmX3hlbl9wYXJzZV9ub3RlOiBTVVNQRU5EX0NBTkNFTCA9IDB4
MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTM6MTNdIGVsZl94ZW5fcGFyc2Vfbm90ZTogSFZf
U1RBUlRfTE9XID0gMHhmZmZmODAwMDAwMDAwMDAwDQooWEVOKSBbMjAxMi0xMC0xMCAxNTox
MzoxM10gZWxmX3hlbl9wYXJzZV9ub3RlOiBQQUREUl9PRkZTRVQgPSAweDANCihYRU4pIFsy
MDEyLTEwLTEwIDE1OjEzOjEzXSBlbGZfeGVuX2FkZHJfY2FsY19jaGVjazogYWRkcmVzc2Vz
Og0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTM6MTNdICAgICB2aXJ0X2Jhc2UgICAgICAgID0g
MHhmZmZmZmZmZjgwMDAwMDAwDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxM10gICAgIGVs
Zl9wYWRkcl9vZmZzZXQgPSAweDANCihYRU4pIFsyMDEyLTEwLTEwIDE1OjEzOjEzXSAgICAg
dmlydF9vZmZzZXQgICAgICA9IDB4ZmZmZmZmZmY4MDAwMDAwMA0KKFhFTikgWzIwMTItMTAt
MTAgMTU6MTM6MTNdICAgICB2aXJ0X2tzdGFydCAgICAgID0gMHhmZmZmZmZmZjgxMDAwMDAw
DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNF0gICAgIHZpcnRfa2VuZCAgICAgICAgPSAw
eGZmZmZmZmZmODJhYzUwMDANCihYRU4pIFsyMDEyLTEwLTEwIDE1OjEzOjE0XSAgICAgdmly
dF9lbnRyeSAgICAgICA9IDB4ZmZmZmZmZmY4MWNkZjIxMA0KKFhFTikgWzIwMTItMTAtMTAg
MTU6MTM6MTRdICAgICBwMm1fYmFzZSAgICAgICAgID0gMHhmZmZmZmZmZmZmZmZmZmZmDQoo
WEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNF0gIFhlbiAga2VybmVsOiA2NC1iaXQsIGxzYiwg
Y29tcGF0MzINCihYRU4pIFsyMDEyLTEwLTEwIDE1OjEzOjE0XSAgRG9tMCBrZXJuZWw6IDY0
LWJpdCwgUEFFLCBsc2IsIHBhZGRyIDB4MTAwMDAwMCAtPiAweDJhYzUwMDANCihYRU4pIFsy
MDEyLTEwLTEwIDE1OjEzOjE0XSBQSFlTSUNBTCBNRU1PUlkgQVJSQU5HRU1FTlQ6DQooWEVO
KSBbMjAxMi0xMC0xMCAxNToxMzoxNF0gIERvbTAgYWxsb2MuOiAgIDAwMDAwMDAyNDAwMDAw
MDAtPjAwMDAwMDAyNDQwMDAwMDAgKDI0MjQyOCBwYWdlcyB0byBiZSBhbGxvY2F0ZWQpDQoo
WEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNF0gIEluaXQuIHJhbWRpc2s6IDAwMDAwMDAyNGYy
ZmMwMDAtPjAwMDAwMDAyNGZmZmY4MDANCihYRU4pIFsyMDEyLTEwLTEwIDE1OjEzOjE0XSBW
SVJUVUFMIE1FTU9SWSBBUlJBTkdFTUVOVDoNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjEzOjE0
XSAgTG9hZGVkIGtlcm5lbDogZmZmZmZmZmY4MTAwMDAwMC0+ZmZmZmZmZmY4MmFjNTAwMA0K
KFhFTikgWzIwMTItMTAtMTAgMTU6MTM6MTRdICBJbml0LiByYW1kaXNrOiBmZmZmZmZmZjgy
YWM1MDAwLT5mZmZmZmZmZjgzN2M4ODAwDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNF0g
IFBoeXMtTWFjaCBtYXA6IGZmZmZmZmZmODM3YzkwMDAtPmZmZmZmZmZmODM5YzkwMDANCihY
RU4pIFsyMDEyLTEwLTEwIDE1OjEzOjE0XSAgU3RhcnQgaW5mbzogICAgZmZmZmZmZmY4Mzlj
OTAwMC0+ZmZmZmZmZmY4MzljOTRiNA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTM6MTRdICBQ
YWdlIHRhYmxlczogICBmZmZmZmZmZjgzOWNhMDAwLT5mZmZmZmZmZjgzOWViMDAwDQooWEVO
KSBbMjAxMi0xMC0xMCAxNToxMzoxNF0gIEJvb3Qgc3RhY2s6ICAgIGZmZmZmZmZmODM5ZWIw
MDAtPmZmZmZmZmZmODM5ZWMwMDANCihYRU4pIFsyMDEyLTEwLTEwIDE1OjEzOjE0XSAgVE9U
QUw6ICAgICAgICAgZmZmZmZmZmY4MDAwMDAwMC0+ZmZmZmZmZmY4M2MwMDAwMA0KKFhFTikg
WzIwMTItMTAtMTAgMTU6MTM6MTRdICBFTlRSWSBBRERSRVNTOiBmZmZmZmZmZjgxY2RmMjEw
DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNF0gRG9tMCBoYXMgbWF4aW11bSA2IFZDUFVz
DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNF0gZWxmX2xvYWRfYmluYXJ5OiBwaGRyIDAg
YXQgMHhmZmZmZmZmZjgxMDAwMDAwIC0+IDB4ZmZmZmZmZmY4MWFmMjAwMA0KKFhFTikgWzIw
MTItMTAtMTAgMTU6MTM6MTRdIGVsZl9sb2FkX2JpbmFyeTogcGhkciAxIGF0IDB4ZmZmZmZm
ZmY4MWMwMDAwMCAtPiAweGZmZmZmZmZmODFjY2EwZTgNCihYRU4pIFsyMDEyLTEwLTEwIDE1
OjEzOjE0XSBlbGZfbG9hZF9iaW5hcnk6IHBoZHIgMiBhdCAweGZmZmZmZmZmODFjY2IwMDAg
LT4gMHhmZmZmZmZmZjgxY2RlY2MwDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNF0gZWxm
X2xvYWRfYmluYXJ5OiBwaGRyIDMgYXQgMHhmZmZmZmZmZjgxY2RmMDAwIC0+IDB4ZmZmZmZm
ZmY4MWQ3ZjAwMA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTM6MTRdIEFNRC1WaTogU2V0dXAg
SS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDAsIHJvb3QgdGFibGUgPSAweDI0N2VkNDAw
MCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0xMC0xMCAxNTox
MzoxNF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgyLCBy
b290IHRhYmxlID0gMHgyNDdlZDQwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0K
KFhFTikgWzIwMTItMTAtMTAgMTU6MTM6MTRdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFi
bGU6IGRldmljZSBpZCA9IDB4MTAsIHJvb3QgdGFibGUgPSAweDI0N2VkNDAwMCwgZG9tYWlu
ID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNF0gQU1E
LVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgxOCwgcm9vdCB0YWJs
ZSA9IDB4MjQ3ZWQ0MDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsy
MDEyLTEwLTEwIDE1OjEzOjE0XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZp
Y2UgaWQgPSAweDI4LCByb290IHRhYmxlID0gMHgyNDdlZDQwMDAsIGRvbWFpbiA9IDAsIHBh
Z2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTM6MTRdIEFNRC1WaTogU2V0
dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MzAsIHJvb3QgdGFibGUgPSAweDI0
N2VkNDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0xMC0x
MCAxNToxMzoxNF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0g
MHg1MCwgcm9vdCB0YWJsZSA9IDB4MjQ3ZWQ0MDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9k
ZSA9IDMNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjEzOjE0XSBBTUQtVmk6IFNldHVwIEkvTyBw
YWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDU4LCByb290IHRhYmxlID0gMHgyNDdlZDQwMDAs
IGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTM6
MTRdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4NjgsIHJv
b3QgdGFibGUgPSAweDI0N2VkNDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQoo
WEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJs
ZTogZGV2aWNlIGlkID0gMHg4OCwgcm9vdCB0YWJsZSA9IDB4MjQ3ZWQ0MDAwLCBkb21haW4g
PSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjEzOjE0XSBBTUQt
Vmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDkwLCByb290IHRhYmxl
ID0gMHgyNDdlZDQwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIw
MTItMTAtMTAgMTU6MTM6MTRdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmlj
ZSBpZCA9IDB4OTIsIHJvb3QgdGFibGUgPSAweDI0N2VkNDAwMCwgZG9tYWluID0gMCwgcGFn
aW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNF0gQU1ELVZpOiBTZXR1
cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg5OCwgcm9vdCB0YWJsZSA9IDB4MjQ3
ZWQ0MDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTEwLTEw
IDE1OjEzOjE0XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAw
eDlhLCByb290IHRhYmxlID0gMHgyNDdlZDQwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2Rl
ID0gMw0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTM6MTRdIEFNRC1WaTogU2V0dXAgSS9PIHBh
Z2UgdGFibGU6IGRldmljZSBpZCA9IDB4YTAsIHJvb3QgdGFibGUgPSAweDI0N2VkNDAwMCwg
ZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzox
NF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhhMSwgcm9v
dCB0YWJsZSA9IDB4MjQ3ZWQ0MDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihY
RU4pIFsyMDEyLTEwLTEwIDE1OjEzOjE0XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxl
OiBkZXZpY2UgaWQgPSAweGEyLCByb290IHRhYmxlID0gMHgyNDdlZDQwMDAsIGRvbWFpbiA9
IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTM6MTRdIEFNRC1W
aTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4YTMsIHJvb3QgdGFibGUg
PSAweDI0N2VkNDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAx
Mi0xMC0xMCAxNToxMzoxNF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNl
IGlkID0gMHhhNCwgcm9vdCB0YWJsZSA9IDB4MjQ3ZWQ0MDAwLCBkb21haW4gPSAwLCBwYWdp
bmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjEzOjE0XSBBTUQtVmk6IFNldHVw
IEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGE1LCByb290IHRhYmxlID0gMHgyNDdl
ZDQwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMTAtMTAg
MTU6MTM6MTRdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4
YTgsIHJvb3QgdGFibGUgPSAweDI0N2VkNDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUg
PSAzDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNF0gQU1ELVZpOiBTZXR1cCBJL08gcGFn
ZSB0YWJsZTogZGV2aWNlIGlkID0gMHhiMCwgcm9vdCB0YWJsZSA9IDB4MjQ3ZWQ0MDAwLCBk
b21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjEzOjE0
XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweGIyLCByb290
IHRhYmxlID0gMHgyNDdlZDQwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhF
TikgWzIwMTItMTAtMTAgMTU6MTM6MTRdIEFNRC1WaTogTm8gaW9tbXUgZm9yIGRldmljZSAw
MDAwOjAwOjE4LjANCihYRU4pIFsyMDEyLTEwLTEwIDE1OjEzOjE0XSBBTUQtVmk6IE5vIGlv
bW11IGZvciBkZXZpY2UgMDAwMDowMDoxOC4xDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzox
NF0gQU1ELVZpOiBObyBpb21tdSBmb3IgZGV2aWNlIDAwMDA6MDA6MTguMg0KKFhFTikgWzIw
MTItMTAtMTAgMTU6MTM6MTRdIEFNRC1WaTogTm8gaW9tbXUgZm9yIGRldmljZSAwMDAwOjAw
OjE4LjMNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjEzOjE0XSBBTUQtVmk6IE5vIGlvbW11IGZv
ciBkZXZpY2UgMDAwMDowMDoxOC40DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNF0gQU1E
LVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg0MDAsIHJvb3QgdGFi
bGUgPSAweDI0N2VkNDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBb
MjAxMi0xMC0xMCAxNToxMzoxNF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2
aWNlIGlkID0gMHg0MDEsIHJvb3QgdGFibGUgPSAweDI0N2VkNDAwMCwgZG9tYWluID0gMCwg
cGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNF0gQU1ELVZpOiBT
ZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg0MDIsIHJvb3QgdGFibGUgPSAw
eDI0N2VkNDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0x
MC0xMCAxNToxMzoxNF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlk
ID0gMHg0MDMsIHJvb3QgdGFibGUgPSAweDI0N2VkNDAwMCwgZG9tYWluID0gMCwgcGFnaW5n
IG1vZGUgPSAzDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNF0gQU1ELVZpOiBTZXR1cCBJ
L08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg0MDQsIHJvb3QgdGFibGUgPSAweDI0N2Vk
NDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0xMC0xMCAx
NToxMzoxNF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg0
MDUsIHJvb3QgdGFibGUgPSAweDI0N2VkNDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUg
PSAzDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNF0gQU1ELVZpOiBTZXR1cCBJL08gcGFn
ZSB0YWJsZTogZGV2aWNlIGlkID0gMHg0MDYsIHJvb3QgdGFibGUgPSAweDI0N2VkNDAwMCwg
ZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzox
NF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg0MDcsIHJv
b3QgdGFibGUgPSAweDI0N2VkNDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQoo
WEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJs
ZTogZGV2aWNlIGlkID0gMHg1MDAsIHJvb3QgdGFibGUgPSAweDI0N2VkNDAwMCwgZG9tYWlu
ID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNF0gQU1E
LVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg1MDEsIHJvb3QgdGFi
bGUgPSAweDI0N2VkNDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBb
MjAxMi0xMC0xMCAxNToxMzoxNF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2
aWNlIGlkID0gMHg2MDAsIHJvb3QgdGFibGUgPSAweDI0N2VkNDAwMCwgZG9tYWluID0gMCwg
cGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNF0gQU1ELVZpOiBT
ZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg3MDAsIHJvb3QgdGFibGUgPSAw
eDI0N2VkNDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0x
MC0xMCAxNToxMzoxNF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlk
ID0gMHg4MDAsIHJvb3QgdGFibGUgPSAweDI0N2VkNDAwMCwgZG9tYWluID0gMCwgcGFnaW5n
IG1vZGUgPSAzDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNF0gQU1ELVZpOiBTZXR1cCBJ
L08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg5MDAsIHJvb3QgdGFibGUgPSAweDI0N2Vk
NDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0xMC0xMCAx
NToxMzoxNF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg5
MDEsIHJvb3QgdGFibGUgPSAweDI0N2VkNDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUg
PSAzDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNV0gQU1ELVZpOiBTZXR1cCBJL08gcGFn
ZSB0YWJsZTogZGV2aWNlIGlkID0gMHg5MDIsIHJvb3QgdGFibGUgPSAweDI0N2VkNDAwMCwg
ZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzox
NV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg5MDMsIHJv
b3QgdGFibGUgPSAweDI0N2VkNDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQoo
WEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJs
ZTogZGV2aWNlIGlkID0gMHg5MDQsIHJvb3QgdGFibGUgPSAweDI0N2VkNDAwMCwgZG9tYWlu
ID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNV0gQU1E
LVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg5MDUsIHJvb3QgdGFi
bGUgPSAweDI0N2VkNDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBb
MjAxMi0xMC0xMCAxNToxMzoxNV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2
aWNlIGlkID0gMHg5MDYsIHJvb3QgdGFibGUgPSAweDI0N2VkNDAwMCwgZG9tYWluID0gMCwg
cGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNV0gQU1ELVZpOiBT
ZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg5MDcsIHJvb3QgdGFibGUgPSAw
eDI0N2VkNDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0x
MC0xMCAxNToxMzoxNV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlk
ID0gMHhhMDAsIHJvb3QgdGFibGUgPSAweDI0N2VkNDAwMCwgZG9tYWluID0gMCwgcGFnaW5n
IG1vZGUgPSAzDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNV0gU2NydWJiaW5nIEZyZWUg
UkFNOiAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLmRvbmUuDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzox
Nl0gSW5pdGlhbCBsb3cgbWVtb3J5IHZpcnEgdGhyZXNob2xkIHNldCBhdCAweDQwMDAgcGFn
ZXMuDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNl0gU3RkLiBMb2dsZXZlbDogQWxsDQoo
WEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxNl0gR3Vlc3QgTG9nbGV2ZWw6IEFsbA0KKFhFTikg
WzIwMTItMTAtMTAgMTU6MTM6MTZdIFhlbiBpcyByZWxpbnF1aXNoaW5nIFZHQSBjb25zb2xl
Lg0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTM6MTddICoqKiBTZXJpYWwgaW5wdXQgLT4gRE9N
MCAodHlwZSAnQ1RSTC1hJyB0aHJlZSB0aW1lcyB0byBzd2l0Y2ggaW5wdXQgdG8gWGVuKQ0K
KFhFTikgWzIwMTItMTAtMTAgMTU6MTM6MTddIEZyZWVkIDI2MGtCIGluaXQgbWVtb3J5Lg0K
KFhFTikgWzIwMTItMTAtMTAgMTU6MTM6MTddIElPQVBJQ1swXTogU2V0IFBDSSByb3V0aW5n
IGVudHJ5ICg2LTkgLT4gMHg2MCAtPiBJUlEgOSBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBb
MjAxMi0xMC0xMCAxNToxMzoxN10gdHJhcHMuYzoyNTEyOmQwIERvbWFpbiBhdHRlbXB0ZWQg
V1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMGVmZjJiZmRiMWE5ZSB0byAweDAw
MDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBk
ZXZpY2UgMDAwMDowMDowMC4wDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFk
ZCBkZXZpY2UgMDAwMDowMDowMC4yDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJ
IGFkZCBkZXZpY2UgMDAwMDowMDowMi4wDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10g
UENJIGFkZCBkZXZpY2UgMDAwMDowMDowMy4wDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzox
N10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowNS4wDQooWEVOKSBbMjAxMi0xMC0xMCAxNTox
MzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowNi4wDQooWEVOKSBbMjAxMi0xMC0xMCAx
NToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowYS4wDQooWEVOKSBbMjAxMi0xMC0x
MCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowYi4wDQooWEVOKSBbMjAxMi0x
MC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowZC4wDQooWEVOKSBbMjAx
Mi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxMS4wDQooWEVOKSBb
MjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxMi4wDQooWEVO
KSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxMi4yDQoo
WEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxMy4w
DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDox
My4yDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDow
MDoxNC4wDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAw
MDowMDoxNC4xDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2Ug
MDAwMDowMDoxNC4yDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZp
Y2UgMDAwMDowMDoxNC4zDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBk
ZXZpY2UgMDAwMDowMDoxNC40DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFk
ZCBkZXZpY2UgMDAwMDowMDoxNC41DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJ
IGFkZCBkZXZpY2UgMDAwMDowMDoxNS4wDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10g
UENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNi4wDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzox
N10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNi4yDQooWEVOKSBbMjAxMi0xMC0xMCAxNTox
MzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC4wDQooWEVOKSBbMjAxMi0xMC0xMCAx
NToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC4xDQooWEVOKSBbMjAxMi0xMC0x
MCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC4yDQooWEVOKSBbMjAxMi0x
MC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC4zDQooWEVOKSBbMjAx
Mi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC40DQooWEVOKSBb
MjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowYTowMC4wDQooWEVO
KSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowOTowMC4wDQoo
WEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowOTowMC4x
DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowOTow
MC4yDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDow
OTowMC4zDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAw
MDowOTowMC40DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2Ug
MDAwMDowOTowMC41DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZp
Y2UgMDAwMDowOTowMC42DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBk
ZXZpY2UgMDAwMDowOTowMC43DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFk
ZCBkZXZpY2UgMDAwMDowODowMC4wDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJ
IGFkZCBkZXZpY2UgMDAwMDowNzowMC4wDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10g
UENJIGFkZCBkZXZpY2UgMDAwMDowNjowMC4wDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzox
N10gUENJIGFkZCBkZXZpY2UgMDAwMDowNTowMC4wDQooWEVOKSBbMjAxMi0xMC0xMCAxNTox
MzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowNTowMC4xDQooWEVOKSBbMjAxMi0xMC0xMCAx
NToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowNDowMC4wDQooWEVOKSBbMjAxMi0xMC0x
MCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowNDowMC4xDQooWEVOKSBbMjAxMi0x
MC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowNDowMC4yDQooWEVOKSBbMjAx
Mi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowNDowMC4zDQooWEVOKSBb
MjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowNDowMC40DQooWEVO
KSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowNDowMC41DQoo
WEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowNDowMC42
DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDowNDow
MC43DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gUENJIGFkZCBkZXZpY2UgMDAwMDow
MzowNi4wDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gSU9BUElDWzBdOiBTZXQgUENJ
IHJvdXRpbmcgZW50cnkgKDYtOCAtPiAweDU4IC0+IElSUSA4IE1vZGU6MCBBY3RpdmU6MCkN
CihYRU4pIFsyMDEyLTEwLTEwIDE1OjEzOjE3XSBJT0FQSUNbMF06IFNldCBQQ0kgcm91dGlu
ZyBlbnRyeSAoNi0xMyAtPiAweDg4IC0+IElSUSAxMyBNb2RlOjAgQWN0aXZlOjApDQooWEVO
KSBbMjAxMi0xMC0xMCAxNToxMzoxN10gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50
cnkgKDctMjggLT4gMHhhMCAtPiBJUlEgNTIgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIw
MTItMTAtMTAgMTU6MTM6MTddIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3
LTI5IC0+IDB4YTggLT4gSVJRIDUzIE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTEw
LTEwIDE1OjEzOjE3XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0zMCAt
PiAweGIwIC0+IElSUSA1NCBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0xMC0xMCAx
NToxMzoxN10gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDYtMTYgLT4gMHhi
OCAtPiBJUlEgMTYgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTM6
MTddIElPQVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg2LTE4IC0+IDB4YzAgLT4g
SVJRIDE4IE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjEzOjE3XSBJ
T0FQSUNbMF06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNi0xNyAtPiAweGM4IC0+IElSUSAx
NyBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gSU9BUElD
WzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctNCAtPiAweGQwIC0+IElSUSAyOCBNb2Rl
OjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gSU9BUElDWzFdOiBT
ZXQgUENJIHJvdXRpbmcgZW50cnkgKDctNSAtPiAweGQ4IC0+IElSUSAyOSBNb2RlOjEgQWN0
aXZlOjEpDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gSU9BUElDWzFdOiBTZXQgUENJ
IHJvdXRpbmcgZW50cnkgKDctNiAtPiAweDIxIC0+IElSUSAzMCBNb2RlOjEgQWN0aXZlOjEp
DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxN10gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRp
bmcgZW50cnkgKDctNyAtPiAweDI5IC0+IElSUSAzMSBNb2RlOjEgQWN0aXZlOjEpDQooWEVO
KSBbMjAxMi0xMC0xMCAxNToxMzoxN10gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50
cnkgKDctMTYgLT4gMHgzMSAtPiBJUlEgNDAgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIw
MTItMTAtMTAgMTU6MTM6MThdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3
LTE3IC0+IDB4MzkgLT4gSVJRIDQxIE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTEw
LTEwIDE1OjEzOjE4XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0xOCAt
PiAweDQxIC0+IElSUSA0MiBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0xMC0xMCAx
NToxMzoxOF0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMTkgLT4gMHg0
OSAtPiBJUlEgNDMgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTM6
MThdIElPQVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg2LTIyIC0+IDB4OTEgLT4g
SVJRIDIyIE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjEzOjE4XSBJ
T0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0yMyAtPiAweDk5IC0+IElSUSA0
NyBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoxOF0gSU9BUElD
WzBdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDYtMTkgLT4gMHhhMSAtPiBJUlEgMTkgTW9k
ZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTM6MThdIElPQVBJQ1sxXTog
U2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTIyIC0+IDB4YjEgLT4gSVJRIDQ2IE1vZGU6MSBB
Y3RpdmU6MSkNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjEzOjE4XSBJT0FQSUNbMV06IFNldCBQ
Q0kgcm91dGluZyBlbnRyeSAoNy0yNyAtPiAweGMxIC0+IElSUSA1MSBNb2RlOjEgQWN0aXZl
OjEpDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxMzoyMF0gSU9BUElDWzFdOiBTZXQgUENJIHJv
dXRpbmcgZW50cnkgKDctOSAtPiAweGQxIC0+IElSUSAzMyBNb2RlOjEgQWN0aXZlOjEpDQoo
WEVOKSBbMjAxMi0xMC0xMCAxNToxNTozMl0gdHJhcHMuYzoyNTEyOmQxIERvbWFpbiBhdHRl
bXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMGVkYjQxOWRlNzk1YSB0
byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNTozOF0gdHJh
cHMuYzoyNTEyOmQyIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBm
cm9tIDB4MDAwMDA0NmE4MDJiNDE2NSB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBb
MjAxMi0xMC0xMCAxNToxNTo0NF0gdHJhcHMuYzoyNTEyOmQzIERvbWFpbiBhdHRlbXB0ZWQg
V1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMGVkYjQxOWRlNzk1YSB0byAweDAw
MDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNTo1MV0gdHJhcHMuYzoy
NTEyOmQ0IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4
MDAwMDIxODdjNTNmNjM4ZiB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0x
MC0xMCAxNToxNTo1N10gdHJhcHMuYzoyNTEyOmQ1IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1Ig
MDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMGVkYjQxOWRlNzk1YSB0byAweDAwMDAwMDAw
MDAwMGFiY2QuDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNjowOV0gdHJhcHMuYzoyNTEyOmQ2
IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDIx
ODdjNTNmNjM4ZiB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0xMC0xMCAx
NToxNjoxNV0gdHJhcHMuYzoyNTEyOmQ3IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAw
MDBjMDAxMDAwNCBmcm9tIDB4MDAwMDA0NmE4MDJiNDE2NSB0byAweDAwMDAwMDAwMDAwMGFi
Y2QuDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNjoyMl0gdHJhcHMuYzoyNTEyOmQ4IERvbWFp
biBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDA0NmE4MDJi
NDE2NSB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNjoy
OF0gdHJhcHMuYzoyNTEyOmQ5IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAx
MDAwNCBmcm9tIDB4MDAwMGVkYjQxOWRlNzk1YSB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQoo
WEVOKSBbMjAxMi0xMC0xMCAxNToxNjozNV0gdHJhcHMuYzoyNTEyOmQxMCBEb21haW4gYXR0
ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDBlZGI0MTlkZTc5NWEg
dG8gMHgwMDAwMDAwMDAwMDBhYmNkLg0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTY6NDJdIEFN
RC1WaTogRGlzYWJsZTogZGV2aWNlIGlkID0gMHhhNCwgZG9tYWluID0gMCwgcGFnaW5nIG1v
ZGUgPSAzDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNjo0Ml0gQU1ELVZpOiBTZXR1cCBJL08g
cGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHhhNCwgcm9vdCB0YWJsZSA9IDB4MThlMGE1MDAw
LCBkb21haW4gPSAxMSwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0xMC0xMCAxNTox
Njo0Ml0gQU1ELVZpOiBSZS1hc3NpZ24gMDAwMDowMzowNi4wIGZyb20gZG9tMCB0byBkb20x
MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTY6NDNdIHRyYXBzLmM6MjUxMjpkMTEgRG9tYWlu
IGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwNDZiNGY2MDFh
MTQ1IHRvIDB4MDAwMDAwMDAwMDAwYWJjZC4NCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE2OjUz
XSB0cmFwcy5jOjI1MTI6ZDEyIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAx
MDAwNCBmcm9tIDB4MDAwMDIxODdjNTNmNjM4ZiB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQoo
WEVOKSBbMjAxMi0xMC0xMCAxNToxNjo1OV0gdHJhcHMuYzoyNTEyOmQxMyBEb21haW4gYXR0
ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDAwNDZhODAyYjQxNjUg
dG8gMHgwMDAwMDAwMDAwMDBhYmNkLg0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MDVdIHRy
YXBzLmM6MjUxMjpkMTQgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0
IGZyb20gMHgwMDAwMDQ2YTgwMmI0MTY1IHRvIDB4MDAwMDAwMDAwMDAwYWJjZC4NCihYRU4p
IFsyMDEyLTEwLTEwIDE1OjE3OjExXSBBTUQtVmk6IFNoYXJlIHAybSB0YWJsZSB3aXRoIGlv
bW11OiBwMm0gdGFibGUgPSAweDFjMWY5NQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MjRd
IFtWVC1EXWlvLmM6MjgyOiBkMTU6IGJpbmQ6IG1fZ3NpPTE2IGdfZ3NpPTM2IGRldmljZT01
IGludHg9MA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MjRdIEFNRC1WaTogRGlzYWJsZTog
ZGV2aWNlIGlkID0gMHg2MDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikg
WzIwMTItMTAtMTAgMTU6MTc6MjRdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRl
dmljZSBpZCA9IDB4NjAwLCByb290IHRhYmxlID0gMHgxYzFmOTUwMDAsIGRvbWFpbiA9IDE1
LCBwYWdpbmcgbW9kZSA9IDQNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjI0XSBBTUQtVmk6
IFJlLWFzc2lnbiAwMDAwOjA2OjAwLjAgZnJvbSBkb20wIHRvIGRvbTE1DQooWEVOKSBbMjAx
Mi0xMC0xMCAxNToxNzoyNl0gSFZNMTU6IEhWTSBMb2FkZXINCihYRU4pIFsyMDEyLTEwLTEw
IDE1OjE3OjI2XSBIVk0xNTogRGV0ZWN0ZWQgWGVuIHY0LjMtdW5zdGFibGUNCihYRU4pIFsy
MDEyLTEwLTEwIDE1OjE3OjI2XSBIVk0xNTogWGVuYnVzIHJpbmdzIEAweGZlZmZjMDAwLCBl
dmVudCBjaGFubmVsIDUNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjI2XSBIVk0xNTogU3lz
dGVtIHJlcXVlc3RlZCBST01CSU9TDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzoyNl0gSFZN
MTU6IENQVSBzcGVlZCBpcyAzMjAwIE1Ieg0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MjZd
IGlycS5jOjI3MDogRG9tMTUgUENJIGxpbmsgMCBjaGFuZ2VkIDAgLT4gNQ0KKFhFTikgWzIw
MTItMTAtMTAgMTU6MTc6MjZdIEhWTTE1OiBQQ0ktSVNBIGxpbmsgMCByb3V0ZWQgdG8gSVJR
NQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MjZdIGlycS5jOjI3MDogRG9tMTUgUENJIGxp
bmsgMSBjaGFuZ2VkIDAgLT4gMTANCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjI2XSBIVk0x
NTogUENJLUlTQSBsaW5rIDEgcm91dGVkIHRvIElSUTEwDQooWEVOKSBbMjAxMi0xMC0xMCAx
NToxNzoyNl0gaXJxLmM6MjcwOiBEb20xNSBQQ0kgbGluayAyIGNoYW5nZWQgMCAtPiAxMQ0K
KFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MjZdIEhWTTE1OiBQQ0ktSVNBIGxpbmsgMiByb3V0
ZWQgdG8gSVJRMTENCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjI2XSBpcnEuYzoyNzA6IERv
bTE1IFBDSSBsaW5rIDMgY2hhbmdlZCAwIC0+IDUNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3
OjI2XSBIVk0xNTogUENJLUlTQSBsaW5rIDMgcm91dGVkIHRvIElSUTUNCihYRU4pIFsyMDEy
LTEwLTEwIDE1OjE3OjI2XSBIVk0xNTogcGNpIGRldiAwMToyIElOVEQtPklSUTUNCihYRU4p
IFsyMDEyLTEwLTEwIDE1OjE3OjI2XSBIVk0xNTogcGNpIGRldiAwMTozIElOVEEtPklSUTEw
DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzoyNl0gSFZNMTU6IHBjaSBkZXYgMDM6MCBJTlRB
LT5JUlE1DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzoyNl0gSFZNMTU6IHBjaSBkZXYgMDQ6
MCBJTlRBLT5JUlE1DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzoyNl0gSFZNMTU6IHBjaSBk
ZXYgMDU6MCBJTlRBLT5JUlExMA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MjZdIEhWTTE1
OiBwY2kgZGV2IDAyOjAgYmFyIDEwIHNpemUgbHg6IDAyMDAwMDAwDQooWEVOKSBbMjAxMi0x
MC0xMCAxNToxNzoyNl0gSFZNMTU6IHBjaSBkZXYgMDM6MCBiYXIgMTQgc2l6ZSBseDogMDEw
MDAwMDANCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjI2XSBIVk0xNTogcGNpIGRldiAwNTow
IGJhciAxMCBzaXplIGx4OiAwMDIwMDAwMA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MjZd
IG1lbW9yeV9tYXA6YWRkOiBkb20xNSBnZm49ZjMwMDAgbWZuPWY5YTAwIG5yPTIwMA0KKFhF
TikgWzIwMTItMTAtMTAgMTU6MTc6MjZdIEhWTTE1OiBwY2kgZGV2IDA0OjAgYmFyIDEwIHNp
emUgbHg6IDAwMDIwMDAwDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzoyNl0gSFZNMTU6IHBj
aSBkZXYgMDI6MCBiYXIgMTQgc2l6ZSBseDogMDAwMDEwMDANCihYRU4pIFsyMDEyLTEwLTEw
IDE1OjE3OjI2XSBIVk0xNTogcGNpIGRldiAwMzowIGJhciAxMCBzaXplIGx4OiAwMDAwMDEw
MA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MjZdIEhWTTE1OiBwY2kgZGV2IDA0OjAgYmFy
IDE0IHNpemUgbHg6IDAwMDAwMDQwDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzoyNl0gSFZN
MTU6IHBjaSBkZXYgMDE6MiBiYXIgMjAgc2l6ZSBseDogMDAwMDAwMjANCihYRU4pIFsyMDEy
LTEwLTEwIDE1OjE3OjI2XSBIVk0xNTogcGNpIGRldiAwMToxIGJhciAyMCBzaXplIGx4OiAw
MDAwMDAxMA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MjZdIEhWTTE1OiBNdWx0aXByb2Nl
c3NvciBpbml0aWFsaXNhdGlvbjoNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjI2XSBIVk0x
NTogIC0gQ1BVMCAuLi4gNDgtYml0IHBoeXMgLi4uIGZpeGVkIE1UUlJzIC4uLiB2YXIgTVRS
UnMgWzIvOF0gLi4uIGRvbmUuDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzoyNl0gSFZNMTU6
ICAtIENQVTEgLi4uIDQ4LWJpdCBwaHlzIC4uLiBmaXhlZCBNVFJScyAuLi4gdmFyIE1UUlJz
IFsyLzhdIC4uLiBkb25lLg0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MjZdIEhWTTE1OiAg
LSBDUFUyIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBb
Mi84XSAuLi4gZG9uZS4NCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjI2XSBIVk0xNTogVGVz
dGluZyBIVk0gZW52aXJvbm1lbnQ6DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzoyNl0gSFZN
MTU6ICAtIFJFUCBJTlNCIGFjcm9zcyBwYWdlIGJvdW5kYXJpZXMgLi4uIHBhc3NlZA0KKFhF
TikgWzIwMTItMTAtMTAgMTU6MTc6MjZdIEhWTTE1OiAgLSBHUyBiYXNlIE1TUnMgYW5kIFNX
QVBHUyAuLi4gcGFzc2VkDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzoyNl0gSFZNMTU6IFBh
c3NlZCAyIG9mIDIgdGVzdHMNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjI2XSBIVk0xNTog
V3JpdGluZyBTTUJJT1MgdGFibGVzIC4uLg0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MjZd
IEhWTTE1OiBMb2FkaW5nIFJPTUJJT1MgLi4uDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzoy
Nl0gSFZNMTU6IDk2NjAgYnl0ZXMgb2YgUk9NQklPUyBoaWdoLW1lbW9yeSBleHRlbnNpb25z
Og0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MjZdIEhWTTE1OiAgIFJlbG9jYXRpbmcgdG8g
MHhmYzAwMTAwMC0weGZjMDAzNWJjIC4uLiBkb25lDQooWEVOKSBbMjAxMi0xMC0xMCAxNTox
NzoyNl0gSFZNMTU6IENyZWF0aW5nIE1QIHRhYmxlcyAuLi4NCihYRU4pIFsyMDEyLTEwLTEw
IDE1OjE3OjI2XSBIVk0xNTogTG9hZGluZyBDaXJydXMgVkdBQklPUyAuLi4NCihYRU4pIFsy
MDEyLTEwLTEwIDE1OjE3OjI2XSBIVk0xNTogTG9hZGluZyBQQ0kgT3B0aW9uIFJPTSAuLi4N
CihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjI2XSBIVk0xNTogIC0gTWFudWZhY3R1cmVyOiBo
dHRwOi8vaXB4ZS5vcmcNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjI2XSBIVk0xNTogIC0g
UHJvZHVjdCBuYW1lOiBpUFhFDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzoyNl0gSFZNMTU6
IE9wdGlvbiBST01zOg0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MjZdIEhWTTE1OiAgYzAw
MDAtYzhmZmY6IFZHQSBCSU9TDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzoyNl0gSFZNMTU6
ICBjOTAwMC1kOWZmZjogRXRoZXJib290IFJPTQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6
MjZdIEhWTTE1OiBMb2FkaW5nIEFDUEkgLi4uDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzoy
Nl0gSFZNMTU6IHZtODYgVFNTIGF0IGZjMDBmNjgwDQooWEVOKSBbMjAxMi0xMC0xMCAxNTox
NzoyNl0gSFZNMTU6IEJJT1MgbWFwOg0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MjZdIEhW
TTE1OiAgZjAwMDAtZmZmZmY6IE1haW4gQklPUw0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6
MjZdIEhWTTE1OiBFODIwIHRhYmxlOg0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MjZdIEhW
TTE1OiAgWzAwXTogMDAwMDAwMDA6MDAwMDAwMDAgLSAwMDAwMDAwMDowMDA5ZTAwMDogUkFN
DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzoyNl0gSFZNMTU6ICBbMDFdOiAwMDAwMDAwMDow
MDA5ZTAwMCAtIDAwMDAwMDAwOjAwMGEwMDAwOiBSRVNFUlZFRA0KKFhFTikgWzIwMTItMTAt
MTAgMTU6MTc6MjZdIEhWTTE1OiAgSE9MRTogMDAwMDAwMDA6MDAwYTAwMDAgLSAwMDAwMDAw
MDowMDBlMDAwMA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MjZdIEhWTTE1OiAgWzAyXTog
MDAwMDAwMDA6MDAwZTAwMDAgLSAwMDAwMDAwMDowMDEwMDAwMDogUkVTRVJWRUQNCihYRU4p
IFsyMDEyLTEwLTEwIDE1OjE3OjI2XSBIVk0xNTogIFswM106IDAwMDAwMDAwOjAwMTAwMDAw
IC0gMDAwMDAwMDA6MmY4MDAwMDA6IFJBTQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MjZd
IEhWTTE1OiAgSE9MRTogMDAwMDAwMDA6MmY4MDAwMDAgLSAwMDAwMDAwMDpmYzAwMDAwMA0K
KFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MjZdIEhWTTE1OiAgWzA0XTogMDAwMDAwMDA6ZmMw
MDAwMDAgLSAwMDAwMDAwMTowMDAwMDAwMDogUkVTRVJWRUQNCihYRU4pIFsyMDEyLTEwLTEw
IDE1OjE3OjI2XSBIVk0xNTogSW52b2tpbmcgUk9NQklPUyAuLi4NCihYRU4pIFsyMDEyLTEw
LTEwIDE1OjE3OjI2XSBIVk0xNTogJFJldmlzaW9uOiAxLjIyMSAkICREYXRlOiAyMDA4LzEy
LzA3IDE3OjMyOjI5ICQNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjI2XSBzdGR2Z2EuYzox
NDc6ZDE1IGVudGVyaW5nIHN0ZHZnYSBhbmQgY2FjaGluZyBtb2Rlcw0KKFhFTikgWzIwMTIt
MTAtMTAgMTU6MTc6MjZdIEhWTTE1OiBWR0FCaW9zICRJZDogdmdhYmlvcy5jLHYgMS42NyAy
MDA4LzAxLzI3IDA5OjQ0OjEyIHZydXBwZXJ0IEV4cCAkDQooWEVOKSBbMjAxMi0xMC0xMCAx
NToxNzoyNl0gSFZNMTU6IEJvY2hzIEJJT1MgLSBidWlsZDogMDYvMjMvOTkNCihYRU4pIFsy
MDEyLTEwLTEwIDE1OjE3OjI2XSBIVk0xNTogJFJldmlzaW9uOiAxLjIyMSAkICREYXRlOiAy
MDA4LzEyLzA3IDE3OjMyOjI5ICQNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjI2XSBIVk0x
NTogT3B0aW9uczogYXBtYmlvcyBwY2liaW9zIGVsdG9yaXRvIFBNTSANCihYRU4pIFsyMDEy
LTEwLTEwIDE1OjE3OjI2XSBIVk0xNTogDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzoyNl0g
SFZNMTU6IGF0YTAtMDogUENIUz0xNjM4My8xNi82MyB0cmFuc2xhdGlvbj1sYmEgTENIUz0x
MDI0LzI1NS82Mw0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MjZdIEhWTTE1OiBhdGEwIG1h
c3RlcjogUUVNVSBIQVJERElTSyBBVEEtNyBIYXJkLURpc2sgKDEwMjQwIE1CeXRlcykNCihY
RU4pIFsyMDEyLTEwLTEwIDE1OjE3OjI2XSBIVk0xNTogYXRhMC0xOiBQQ0hTPTE2MzgzLzE2
LzYzIHRyYW5zbGF0aW9uPWxiYSBMQ0hTPTEwMjQvMjU1LzYzDQooWEVOKSBbMjAxMi0xMC0x
MCAxNToxNzoyNl0gSFZNMTU6IGF0YTAgIHNsYXZlOiBRRU1VIEhBUkRESVNLIEFUQS03IEhh
cmQtRGlzayAoIDMwMCBHQnl0ZXMpDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzoyNl0gSFZN
MTU6IA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MjZdIEhWTTE1OiANCihYRU4pIFsyMDEy
LTEwLTEwIDE1OjE3OjI2XSBIVk0xNTogDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzoyNl0g
SFZNMTU6IFByZXNzIEYxMiBmb3IgYm9vdCBtZW51Lg0KKFhFTikgWzIwMTItMTAtMTAgMTU6
MTc6MjZdIEhWTTE1OiANCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjI2XSBIVk0xNTogQm9v
dGluZyBmcm9tIEhhcmQgRGlzay4uLg0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MjZdIEhW
TTE1OiBCb290aW5nIGZyb20gMDAwMDo3YzAwDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzoz
MF0gc3RkdmdhLmM6MTUxOmQxNSBsZWF2aW5nIHN0ZHZnYQ0KKFhFTikgWzIwMTItMTAtMTAg
MTU6MTc6MzFdIEFNRC1WaTogU2hhcmUgcDJtIHRhYmxlIHdpdGggaW9tbXU6IHAybSB0YWJs
ZSA9IDB4ODE3MDcNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjMyXSBbVlQtRF1pby5jOjI4
MjogZDE2OiBiaW5kOiBtX2dzaT0xNiBnX2dzaT0zNiBkZXZpY2U9NSBpbnR4PTANCihYRU4p
IFsyMDEyLTEwLTEwIDE1OjE3OjMyXSBBTUQtVmk6IERpc2FibGU6IGRldmljZSBpZCA9IDB4
OTAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTEwLTEwIDE1
OjE3OjMyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDkw
MCwgcm9vdCB0YWJsZSA9IDB4ODE3MDcwMDAsIGRvbWFpbiA9IDE2LCBwYWdpbmcgbW9kZSA9
IDQNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjMyXSBBTUQtVmk6IFJlLWFzc2lnbiAwMDAw
OjA5OjAwLjAgZnJvbSBkb20wIHRvIGRvbTE2DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzoz
Ml0gcGh5c2Rldi5jOjE3NzogZG9tMTY6IDI4Oi0xIGFscmVhZHkgbWFwcGVkIHRvIDE2DQoo
WEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gW1ZULURdaW8uYzoyODI6IGQxNjogYmluZDog
bV9nc2k9MTYgZ19nc2k9NDAgZGV2aWNlPTYgaW50eD0wDQooWEVOKSBbMjAxMi0xMC0xMCAx
NToxNzozMl0gQU1ELVZpOiBEaXNhYmxlOiBkZXZpY2UgaWQgPSAweDkwMSwgZG9tYWluID0g
MCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gQU1ELVZp
OiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg5MDEsIHJvb3QgdGFibGUg
PSAweDgxNzA3MDAwLCBkb21haW4gPSAxNiwgcGFnaW5nIG1vZGUgPSA0DQooWEVOKSBbMjAx
Mi0xMC0xMCAxNToxNzozMl0gQU1ELVZpOiBSZS1hc3NpZ24gMDAwMDowOTowMC4xIGZyb20g
ZG9tMCB0byBkb20xNg0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MzJdIFtWVC1EXWlvLmM6
MjgyOiBkMTY6IGJpbmQ6IG1fZ3NpPTE3IGdfZ3NpPTQ1IGRldmljZT03IGludHg9MQ0KKFhF
TikgWzIwMTItMTAtMTAgMTU6MTc6MzJdIEFNRC1WaTogRGlzYWJsZTogZGV2aWNlIGlkID0g
MHg5MDIsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMTAtMTAg
MTU6MTc6MzJdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4
OTAyLCByb290IHRhYmxlID0gMHg4MTcwNzAwMCwgZG9tYWluID0gMTYsIHBhZ2luZyBtb2Rl
ID0gNA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MzJdIEFNRC1WaTogUmUtYXNzaWduIDAw
MDA6MDk6MDAuMiBmcm9tIGRvbTAgdG8gZG9tMTYNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3
OjMyXSBwaHlzZGV2LmM6MTc3OiBkb20xNjogMjk6LTEgYWxyZWFkeSBtYXBwZWQgdG8gMTcN
CihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjMyXSBbVlQtRF1pby5jOjI4MjogZDE2OiBiaW5k
OiBtX2dzaT0xNyBnX2dzaT0xOCBkZXZpY2U9OCBpbnR4PTENCihYRU4pIFsyMDEyLTEwLTEw
IDE1OjE3OjMyXSBBTUQtVmk6IERpc2FibGU6IGRldmljZSBpZCA9IDB4OTAzLCBkb21haW4g
PSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjMyXSBBTUQt
Vmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDkwMywgcm9vdCB0YWJs
ZSA9IDB4ODE3MDcwMDAsIGRvbWFpbiA9IDE2LCBwYWdpbmcgbW9kZSA9IDQNCihYRU4pIFsy
MDEyLTEwLTEwIDE1OjE3OjMyXSBBTUQtVmk6IFJlLWFzc2lnbiAwMDAwOjA5OjAwLjMgZnJv
bSBkb20wIHRvIGRvbTE2DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gW1ZULURdaW8u
YzoyODI6IGQxNjogYmluZDogbV9nc2k9MTggZ19nc2k9MjMgZGV2aWNlPTkgaW50eD0yDQoo
WEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gQU1ELVZpOiBEaXNhYmxlOiBkZXZpY2UgaWQg
PSAweDkwNCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0xMC0x
MCAxNToxNzozMl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0g
MHg5MDQsIHJvb3QgdGFibGUgPSAweDgxNzA3MDAwLCBkb21haW4gPSAxNiwgcGFnaW5nIG1v
ZGUgPSA0DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gQU1ELVZpOiBSZS1hc3NpZ24g
MDAwMDowOTowMC40IGZyb20gZG9tMCB0byBkb20xNg0KKFhFTikgWzIwMTItMTAtMTAgMTU6
MTc6MzJdIHBoeXNkZXYuYzoxNzc6IGRvbTE2OiAzMDotMSBhbHJlYWR5IG1hcHBlZCB0byAx
OA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MzJdIFtWVC1EXWlvLmM6MjgyOiBkMTY6IGJp
bmQ6IG1fZ3NpPTE4IGdfZ3NpPTI3IGRldmljZT0xMCBpbnR4PTINCihYRU4pIFsyMDEyLTEw
LTEwIDE1OjE3OjMyXSBBTUQtVmk6IERpc2FibGU6IGRldmljZSBpZCA9IDB4OTA1LCBkb21h
aW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjMyXSBB
TUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDkwNSwgcm9vdCB0
YWJsZSA9IDB4ODE3MDcwMDAsIGRvbWFpbiA9IDE2LCBwYWdpbmcgbW9kZSA9IDQNCihYRU4p
IFsyMDEyLTEwLTEwIDE1OjE3OjMyXSBBTUQtVmk6IFJlLWFzc2lnbiAwMDAwOjA5OjAwLjUg
ZnJvbSBkb20wIHRvIGRvbTE2DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gW1ZULURd
aW8uYzoyODI6IGQxNjogYmluZDogbV9nc2k9MTkgZ19nc2k9MzIgZGV2aWNlPTExIGludHg9
Mw0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MzJdIEFNRC1WaTogRGlzYWJsZTogZGV2aWNl
IGlkID0gMHg5MDYsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTIt
MTAtMTAgMTU6MTc6MzJdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBp
ZCA9IDB4OTA2LCByb290IHRhYmxlID0gMHg4MTcwNzAwMCwgZG9tYWluID0gMTYsIHBhZ2lu
ZyBtb2RlID0gNA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MzJdIEFNRC1WaTogUmUtYXNz
aWduIDAwMDA6MDk6MDAuNiBmcm9tIGRvbTAgdG8gZG9tMTYNCihYRU4pIFsyMDEyLTEwLTEw
IDE1OjE3OjMyXSBwaHlzZGV2LmM6MTc3OiBkb20xNjogMzE6LTEgYWxyZWFkeSBtYXBwZWQg
dG8gMTkNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjMyXSBbVlQtRF1pby5jOjI4MjogZDE2
OiBiaW5kOiBtX2dzaT0xOSBnX2dzaT0zNiBkZXZpY2U9MTIgaW50eD0zDQooWEVOKSBbMjAx
Mi0xMC0xMCAxNToxNzozMl0gQU1ELVZpOiBEaXNhYmxlOiBkZXZpY2UgaWQgPSAweDkwNywg
ZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzoz
Ml0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHg5MDcsIHJv
b3QgdGFibGUgPSAweDgxNzA3MDAwLCBkb21haW4gPSAxNiwgcGFnaW5nIG1vZGUgPSA0DQoo
WEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gQU1ELVZpOiBSZS1hc3NpZ24gMDAwMDowOTow
MC43IGZyb20gZG9tMCB0byBkb20xNg0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MzJdIEhW
TTE2OiBIVk0gTG9hZGVyDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gSFZNMTY6IERl
dGVjdGVkIFhlbiB2NC4zLXVuc3RhYmxlDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0g
SFZNMTY6IFhlbmJ1cyByaW5ncyBAMHhmZWZmYzAwMCwgZXZlbnQgY2hhbm5lbCA1DQooWEVO
KSBbMjAxMi0xMC0xMCAxNToxNzozMl0gSFZNMTY6IFN5c3RlbSByZXF1ZXN0ZWQgUk9NQklP
Uw0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MzJdIEhWTTE2OiBDUFUgc3BlZWQgaXMgMzIw
MCBNSHoNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjMyXSBpcnEuYzoyNzA6IERvbTE2IFBD
SSBsaW5rIDAgY2hhbmdlZCAwIC0+IDUNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjMyXSBI
Vk0xNjogUENJLUlTQSBsaW5rIDAgcm91dGVkIHRvIElSUTUNCihYRU4pIFsyMDEyLTEwLTEw
IDE1OjE3OjMyXSBpcnEuYzoyNzA6IERvbTE2IFBDSSBsaW5rIDEgY2hhbmdlZCAwIC0+IDEw
DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gSFZNMTY6IFBDSS1JU0EgbGluayAxIHJv
dXRlZCB0byBJUlExMA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MzJdIGlycS5jOjI3MDog
RG9tMTYgUENJIGxpbmsgMiBjaGFuZ2VkIDAgLT4gMTENCihYRU4pIFsyMDEyLTEwLTEwIDE1
OjE3OjMyXSBIVk0xNjogUENJLUlTQSBsaW5rIDIgcm91dGVkIHRvIElSUTExDQooWEVOKSBb
MjAxMi0xMC0xMCAxNToxNzozMl0gaXJxLmM6MjcwOiBEb20xNiBQQ0kgbGluayAzIGNoYW5n
ZWQgMCAtPiA1DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gSFZNMTY6IFBDSS1JU0Eg
bGluayAzIHJvdXRlZCB0byBJUlE1DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gSFZN
MTY6IHBjaSBkZXYgMDE6MiBJTlRELT5JUlE1DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzoz
Ml0gSFZNMTY6IHBjaSBkZXYgMDE6MyBJTlRBLT5JUlExMA0KKFhFTikgWzIwMTItMTAtMTAg
MTU6MTc6MzJdIEhWTTE2OiBwY2kgZGV2IDAzOjAgSU5UQS0+SVJRNQ0KKFhFTikgWzIwMTIt
MTAtMTAgMTU6MTc6MzJdIEhWTTE2OiBwY2kgZGV2IDA0OjAgSU5UQS0+SVJRNQ0KKFhFTikg
WzIwMTItMTAtMTAgMTU6MTc6MzJdIEhWTTE2OiBwY2kgZGV2IDA1OjAgSU5UQS0+SVJRMTAN
CihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjMyXSBIVk0xNjogcGNpIGRldiAwNjowIElOVEEt
PklSUTExDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gSFZNMTY6IHBjaSBkZXYgMDc6
MCBJTlRCLT5JUlE1DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gSFZNMTY6IHBjaSBk
ZXYgMDg6MCBJTlRCLT5JUlExMA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MzJdIEhWTTE2
OiBwY2kgZGV2IDA5OjAgSU5UQy0+SVJRNQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MzJd
IEhWTTE2OiBwY2kgZGV2IDBhOjAgSU5UQy0+SVJRNQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6
MTc6MzJdIEhWTTE2OiBwY2kgZGV2IDBiOjAgSU5URC0+SVJRMTENCihYRU4pIFsyMDEyLTEw
LTEwIDE1OjE3OjMyXSBIVk0xNjogcGNpIGRldiAwYzowIElOVEQtPklSUTUNCihYRU4pIFsy
MDEyLTEwLTEwIDE1OjE3OjMyXSBIVk0xNjogcGNpIGRldiAwMjowIGJhciAxMCBzaXplIGx4
OiAwMjAwMDAwMA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MzJdIEhWTTE2OiBwY2kgZGV2
IDAzOjAgYmFyIDE0IHNpemUgbHg6IDAxMDAwMDAwDQooWEVOKSBbMjAxMi0xMC0xMCAxNTox
NzozMl0gSFZNMTY6IHBjaSBkZXYgMDQ6MCBiYXIgMTAgc2l6ZSBseDogMDAwMjAwMDANCihY
RU4pIFsyMDEyLTEwLTEwIDE1OjE3OjMyXSBIVk0xNjogcGNpIGRldiAwMjowIGJhciAxNCBz
aXplIGx4OiAwMDAwMTAwMA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MzJdIEhWTTE2OiBw
Y2kgZGV2IDA1OjAgYmFyIDEwIHNpemUgbHg6IDAwMDAxMDAwDQooWEVOKSBbMjAxMi0xMC0x
MCAxNToxNzozMl0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzAyMSBtZm49ZjlmZjgg
bnI9MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MzJdIEhWTTE2OiBwY2kgZGV2IDA2OjAg
YmFyIDEwIHNpemUgbHg6IDAwMDAxMDAwDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0g
bWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzAyMiBtZm49ZjlmZjkgbnI9MQ0KKFhFTikg
WzIwMTItMTAtMTAgMTU6MTc6MzJdIEhWTTE2OiBwY2kgZGV2IDA3OjAgYmFyIDEwIHNpemUg
bHg6IDAwMDAxMDAwDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gbWVtb3J5X21hcDph
ZGQ6IGRvbTE2IGdmbj1mMzAyMyBtZm49ZjlmZmEgbnI9MQ0KKFhFTikgWzIwMTItMTAtMTAg
MTU6MTc6MzJdIEhWTTE2OiBwY2kgZGV2IDA4OjAgYmFyIDEwIHNpemUgbHg6IDAwMDAxMDAw
DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdm
bj1mMzAyNCBtZm49ZjlmZmIgbnI9MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MzJdIEhW
TTE2OiBwY2kgZGV2IDA5OjAgYmFyIDEwIHNpemUgbHg6IDAwMDAxMDAwDQooWEVOKSBbMjAx
Mi0xMC0xMCAxNToxNzozMl0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzAyNSBtZm49
ZjlmZmMgbnI9MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MzJdIEhWTTE2OiBwY2kgZGV2
IDBhOjAgYmFyIDEwIHNpemUgbHg6IDAwMDAxMDAwDQooWEVOKSBbMjAxMi0xMC0xMCAxNTox
NzozMl0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzAyNiBtZm49ZjlmZmQgbnI9MQ0K
KFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MzJdIEhWTTE2OiBwY2kgZGV2IDBiOjAgYmFyIDEw
IHNpemUgbHg6IDAwMDAxMDAwDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gbWVtb3J5
X21hcDphZGQ6IGRvbTE2IGdmbj1mMzAyNyBtZm49ZjlmZmUgbnI9MQ0KKFhFTikgWzIwMTIt
MTAtMTAgMTU6MTc6MzJdIEhWTTE2OiBwY2kgZGV2IDBjOjAgYmFyIDEwIHNpemUgbHg6IDAw
MDAxMDAwDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gbWVtb3J5X21hcDphZGQ6IGRv
bTE2IGdmbj1mMzAyOCBtZm49ZjlmZmYgbnI9MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6
MzJdIEhWTTE2OiBwY2kgZGV2IDAzOjAgYmFyIDEwIHNpemUgbHg6IDAwMDAwMTAwDQooWEVO
KSBbMjAxMi0xMC0xMCAxNToxNzozMl0gSFZNMTY6IHBjaSBkZXYgMDQ6MCBiYXIgMTQgc2l6
ZSBseDogMDAwMDAwNDANCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjMyXSBIVk0xNjogcGNp
IGRldiAwMToyIGJhciAyMCBzaXplIGx4OiAwMDAwMDAyMA0KKFhFTikgWzIwMTItMTAtMTAg
MTU6MTc6MzJdIEhWTTE2OiBwY2kgZGV2IDAxOjEgYmFyIDIwIHNpemUgbHg6IDAwMDAwMDEw
DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gSFZNMTY6IE11bHRpcHJvY2Vzc29yIGlu
aXRpYWxpc2F0aW9uOg0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MzJdIEhWTTE2OiAgLSBD
UFUwIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMi84
XSAuLi4gZG9uZS4NCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjMyXSBIVk0xNjogIC0gQ1BV
MSAuLi4gNDgtYml0IHBoeXMgLi4uIGZpeGVkIE1UUlJzIC4uLiB2YXIgTVRSUnMgWzIvOF0g
Li4uIGRvbmUuDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gSFZNMTY6ICAtIENQVTIg
Li4uIDQ4LWJpdCBwaHlzIC4uLiBmaXhlZCBNVFJScyAuLi4gdmFyIE1UUlJzIFsyLzhdIC4u
LiBkb25lLg0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MzJdIEhWTTE2OiBUZXN0aW5nIEhW
TSBlbnZpcm9ubWVudDoNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjMyXSBIVk0xNjogIC0g
UkVQIElOU0IgYWNyb3NzIHBhZ2UgYm91bmRhcmllcyAuLi4gcGFzc2VkDQooWEVOKSBbMjAx
Mi0xMC0xMCAxNToxNzozMl0gSFZNMTY6ICAtIEdTIGJhc2UgTVNScyBhbmQgU1dBUEdTIC4u
LiBwYXNzZWQNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjMyXSBIVk0xNjogUGFzc2VkIDIg
b2YgMiB0ZXN0cw0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MzJdIEhWTTE2OiBXcml0aW5n
IFNNQklPUyB0YWJsZXMgLi4uDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gSFZNMTY6
IExvYWRpbmcgUk9NQklPUyAuLi4NCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjMyXSBIVk0x
NjogOTY2MCBieXRlcyBvZiBST01CSU9TIGhpZ2gtbWVtb3J5IGV4dGVuc2lvbnM6DQooWEVO
KSBbMjAxMi0xMC0xMCAxNToxNzozMl0gSFZNMTY6ICAgUmVsb2NhdGluZyB0byAweGZjMDAx
MDAwLTB4ZmMwMDM1YmMgLi4uIGRvbmUNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjMyXSBI
Vk0xNjogQ3JlYXRpbmcgTVAgdGFibGVzIC4uLg0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6
MzJdIEhWTTE2OiBMb2FkaW5nIENpcnJ1cyBWR0FCSU9TIC4uLg0KKFhFTikgWzIwMTItMTAt
MTAgMTU6MTc6MzJdIEhWTTE2OiBMb2FkaW5nIFBDSSBPcHRpb24gUk9NIC4uLg0KKFhFTikg
WzIwMTItMTAtMTAgMTU6MTc6MzJdIEhWTTE2OiAgLSBNYW51ZmFjdHVyZXI6IGh0dHA6Ly9p
cHhlLm9yZw0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MzJdIEhWTTE2OiAgLSBQcm9kdWN0
IG5hbWU6IGlQWEUNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjMyXSBIVk0xNjogT3B0aW9u
IFJPTXM6DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gSFZNMTY6ICBjMDAwMC1jOGZm
ZjogVkdBIEJJT1MNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjMyXSBIVk0xNjogIGM5MDAw
LWQ5ZmZmOiBFdGhlcmJvb3QgUk9NDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gSFZN
MTY6IExvYWRpbmcgQUNQSSAuLi4NCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjMyXSBIVk0x
Njogdm04NiBUU1MgYXQgZmMwMGY2ODANCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjMyXSBI
Vk0xNjogQklPUyBtYXA6DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gSFZNMTY6ICBm
MDAwMC1mZmZmZjogTWFpbiBCSU9TDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gSFZN
MTY6IEU4MjAgdGFibGU6DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gSFZNMTY6ICBb
MDBdOiAwMDAwMDAwMDowMDAwMDAwMCAtIDAwMDAwMDAwOjAwMDllMDAwOiBSQU0NCihYRU4p
IFsyMDEyLTEwLTEwIDE1OjE3OjMyXSBIVk0xNjogIFswMV06IDAwMDAwMDAwOjAwMDllMDAw
IC0gMDAwMDAwMDA6MDAwYTAwMDA6IFJFU0VSVkVEDQooWEVOKSBbMjAxMi0xMC0xMCAxNTox
NzozMl0gSFZNMTY6ICBIT0xFOiAwMDAwMDAwMDowMDBhMDAwMCAtIDAwMDAwMDAwOjAwMGUw
MDAwDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gSFZNMTY6ICBbMDJdOiAwMDAwMDAw
MDowMDBlMDAwMCAtIDAwMDAwMDAwOjAwMTAwMDAwOiBSRVNFUlZFRA0KKFhFTikgWzIwMTIt
MTAtMTAgMTU6MTc6MzJdIEhWTTE2OiAgWzAzXTogMDAwMDAwMDA6MDAxMDAwMDAgLSAwMDAw
MDAwMDoxZjgwMDAwMDogUkFNDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzozMl0gSFZNMTY6
ICBIT0xFOiAwMDAwMDAwMDoxZjgwMDAwMCAtIDAwMDAwMDAwOmZjMDAwMDAwDQooWEVOKSBb
MjAxMi0xMC0xMCAxNToxNzozMl0gSFZNMTY6ICBbMDRdOiAwMDAwMDAwMDpmYzAwMDAwMCAt
IDAwMDAwMDAxOjAwMDAwMDAwOiBSRVNFUlZFRA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6
MzJdIEhWTTE2OiBJbnZva2luZyBST01CSU9TIC4uLg0KKFhFTikgWzIwMTItMTAtMTAgMTU6
MTc6MzJdIEhWTTE2OiAkUmV2aXNpb246IDEuMjIxICQgJERhdGU6IDIwMDgvMTIvMDcgMTc6
MzI6MjkgJA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MzNdIHN0ZHZnYS5jOjE0NzpkMTYg
ZW50ZXJpbmcgc3RkdmdhIGFuZCBjYWNoaW5nIG1vZGVzDQooWEVOKSBbMjAxMi0xMC0xMCAx
NToxNzozM10gSFZNMTY6IFZHQUJpb3MgJElkOiB2Z2FiaW9zLmMsdiAxLjY3IDIwMDgvMDEv
MjcgMDk6NDQ6MTIgdnJ1cHBlcnQgRXhwICQNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjMz
XSBIVk0xNjogQm9jaHMgQklPUyAtIGJ1aWxkOiAwNi8yMy85OQ0KKFhFTikgWzIwMTItMTAt
MTAgMTU6MTc6MzNdIEhWTTE2OiAkUmV2aXNpb246IDEuMjIxICQgJERhdGU6IDIwMDgvMTIv
MDcgMTc6MzI6MjkgJA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MzNdIEhWTTE2OiBPcHRp
b25zOiBhcG1iaW9zIHBjaWJpb3MgZWx0b3JpdG8gUE1NIA0KKFhFTikgWzIwMTItMTAtMTAg
MTU6MTc6MzNdIEhWTTE2OiANCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjMzXSBIVk0xNjog
YXRhMC0wOiBQQ0hTPTEwNDAyLzE2LzYzIHRyYW5zbGF0aW9uPWxiYSBMQ0hTPTY1Mi8yNTUv
NjMNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjMzXSBIVk0xNjogYXRhMCBtYXN0ZXI6IFFF
TVUgSEFSRERJU0sgQVRBLTcgSGFyZC1EaXNrICg1MTIwIE1CeXRlcykNCihYRU4pIFsyMDEy
LTEwLTEwIDE1OjE3OjM0XSBIVk0xNjogSURFIHRpbWUgb3V0DQooWEVOKSBbMjAxMi0xMC0x
MCAxNToxNzozNF0gSFZNMTY6IA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6MzddIEhWTTE2
OiANCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjM3XSBIVk0xNjogDQooWEVOKSBbMjAxMi0x
MC0xMCAxNToxNzozN10gSFZNMTY6IFByZXNzIEYxMiBmb3IgYm9vdCBtZW51Lg0KKFhFTikg
WzIwMTItMTAtMTAgMTU6MTc6MzddIEhWTTE2OiANCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3
OjM3XSBIVk0xNjogQm9vdGluZyBmcm9tIEhhcmQgRGlzay4uLg0KKFhFTikgWzIwMTItMTAt
MTAgMTU6MTc6MzddIEhWTTE2OiBCb290aW5nIGZyb20gMDAwMDo3YzAwDQooWEVOKSBbMjAx
Mi0xMC0xMCAxNToxNzo0MF0gc3RkdmdhLmM6MTQ3OmQxNSBlbnRlcmluZyBzdGR2Z2EgYW5k
IGNhY2hpbmcgbW9kZXMNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjQxXSBpcnEuYzozNzU6
IERvbTE1IGNhbGxiYWNrIHZpYSBjaGFuZ2VkIHRvIERpcmVjdCBWZWN0b3IgMHhmMw0KKFhF
TikgWzIwMTItMTAtMTAgMTU6MTc6NDFdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNSBnZm49
ZjMwMDAgbWZuPWY5YTAwIG5yPTIwMA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NDFdIG1l
bW9yeV9tYXA6YWRkOiBkb20xNSBnZm49ZjMwMDAgbWZuPWY5YTAwIG5yPTIwMA0KKFhFTikg
WzIwMTItMTAtMTAgMTU6MTc6NDFdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNSBnZm49ZjMw
MDAgbWZuPWY5YTAwIG5yPTIwMA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NDFdIG1lbW9y
eV9tYXA6YWRkOiBkb20xNSBnZm49ZjMwMDAgbWZuPWY5YTAwIG5yPTIwMA0KKFhFTikgWzIw
MTItMTAtMTAgMTU6MTc6NDFdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNSBnZm49ZjMwMDAg
bWZuPWY5YTAwIG5yPTIwMA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NDFdIG1lbW9yeV9t
YXA6YWRkOiBkb20xNSBnZm49ZjMwMDAgbWZuPWY5YTAwIG5yPTIwMA0KKFhFTikgWzIwMTIt
MTAtMTAgMTU6MTc6NDFdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNSBnZm49ZjMwMDAgbWZu
PWY5YTAwIG5yPTIwMA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NDFdIG1lbW9yeV9tYXA6
YWRkOiBkb20xNSBnZm49ZjMwMDAgbWZuPWY5YTAwIG5yPTIwMA0KKFhFTikgWzIwMTItMTAt
MTAgMTU6MTc6NDFdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNSBnZm49ZjMwMDAgbWZuPWY5
YTAwIG5yPTIwMA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NDFdIG1lbW9yeV9tYXA6YWRk
OiBkb20xNSBnZm49ZjMwMDAgbWZuPWY5YTAwIG5yPTIwMA0KKFhFTikgWzIwMTItMTAtMTAg
MTU6MTc6NDFdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNSBnZm49ZjMwMDAgbWZuPWY5YTAw
IG5yPTIwMA0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NDFdIG1lbW9yeV9tYXA6YWRkOiBk
b20xNSBnZm49ZjMwMDAgbWZuPWY5YTAwIG5yPTIwMA0KKFhFTikgWzIwMTItMTAtMTAgMTU6
MTc6NDFdIGlycS5jOjI3MDogRG9tMTUgUENJIGxpbmsgMCBjaGFuZ2VkIDUgLT4gMA0KKFhF
TikgWzIwMTItMTAtMTAgMTU6MTc6NDFdIGlycS5jOjI3MDogRG9tMTUgUENJIGxpbmsgMSBj
aGFuZ2VkIDEwIC0+IDANCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjQxXSBpcnEuYzoyNzA6
IERvbTE1IFBDSSBsaW5rIDIgY2hhbmdlZCAxMSAtPiAwDQooWEVOKSBbMjAxMi0xMC0xMCAx
NToxNzo0MV0gaXJxLmM6MjcwOiBEb20xNSBQQ0kgbGluayAzIGNoYW5nZWQgNSAtPiAwDQoo
WEVOKSBbMjAxMi0xMC0xMCAxNToxNzo0Ml0gc3RkdmdhLmM6MTUxOmQxNiBsZWF2aW5nIHN0
ZHZnYQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NTNdIHN0ZHZnYS5jOjE0NzpkMTYgZW50
ZXJpbmcgc3RkdmdhIGFuZCBjYWNoaW5nIG1vZGVzDQooWEVOKSBbMjAxMi0xMC0xMCAxNTox
Nzo1NF0gaXJxLmM6Mzc1OiBEb20xNiBjYWxsYmFjayB2aWEgY2hhbmdlZCB0byBEaXJlY3Qg
VmVjdG9yIDB4ZjMNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU0XSBtZW1vcnlfbWFwOnJl
bW92ZTogZG9tMTYgZ2ZuPWYzMDIxIG1mbj1mOWZmOCBucj0xDQooWEVOKSBbMjAxMi0xMC0x
MCAxNToxNzo1NF0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzAyMSBtZm49ZjlmZjgg
bnI9MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NTRdIG1lbW9yeV9tYXA6cmVtb3ZlOiBk
b20xNiBnZm49ZjMwMjEgbWZuPWY5ZmY4IG5yPTENCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3
OjU0XSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDIxIG1mbj1mOWZmOCBucj0xDQoo
WEVOKSBbMjAxMi0xMC0xMCAxNToxNzo1NF0gbWVtb3J5X21hcDpyZW1vdmU6IGRvbTE2IGdm
bj1mMzAyMSBtZm49ZjlmZjggbnI9MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NTRdIG1l
bW9yeV9tYXA6YWRkOiBkb20xNiBnZm49ZjMwMjEgbWZuPWY5ZmY4IG5yPTENCihYRU4pIFsy
MDEyLTEwLTEwIDE1OjE3OjU0XSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYgZ2ZuPWYzMDIx
IG1mbj1mOWZmOCBucj0xDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzo1NF0gbWVtb3J5X21h
cDphZGQ6IGRvbTE2IGdmbj1mMzAyMSBtZm49ZjlmZjggbnI9MQ0KKFhFTikgWzIwMTItMTAt
MTAgMTU6MTc6NTRdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNiBnZm49ZjMwMjEgbWZuPWY5
ZmY4IG5yPTENCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU0XSBtZW1vcnlfbWFwOmFkZDog
ZG9tMTYgZ2ZuPWYzMDIxIG1mbj1mOWZmOCBucj0xDQooWEVOKSBbMjAxMi0xMC0xMCAxNTox
Nzo1NF0gbWVtb3J5X21hcDpyZW1vdmU6IGRvbTE2IGdmbj1mMzAyMSBtZm49ZjlmZjggbnI9
MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NTRdIG1lbW9yeV9tYXA6YWRkOiBkb20xNiBn
Zm49ZjMwMjEgbWZuPWY5ZmY4IG5yPTENCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU0XSBt
ZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYgZ2ZuPWYzMDIxIG1mbj1mOWZmOCBucj0xDQooWEVO
KSBbMjAxMi0xMC0xMCAxNToxNzo1NF0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzAy
MSBtZm49ZjlmZjggbnI9MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NTRdIG1lbW9yeV9t
YXA6cmVtb3ZlOiBkb20xNiBnZm49ZjMwMjIgbWZuPWY5ZmY5IG5yPTENCihYRU4pIFsyMDEy
LTEwLTEwIDE1OjE3OjU0XSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDIyIG1mbj1m
OWZmOSBucj0xDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzo1NF0gbWVtb3J5X21hcDpyZW1v
dmU6IGRvbTE2IGdmbj1mMzAyMiBtZm49ZjlmZjkgbnI9MQ0KKFhFTikgWzIwMTItMTAtMTAg
MTU6MTc6NTRdIG1lbW9yeV9tYXA6YWRkOiBkb20xNiBnZm49ZjMwMjIgbWZuPWY5ZmY5IG5y
PTENCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU0XSBtZW1vcnlfbWFwOnJlbW92ZTogZG9t
MTYgZ2ZuPWYzMDIyIG1mbj1mOWZmOSBucj0xDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzo1
NF0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzAyMiBtZm49ZjlmZjkgbnI9MQ0KKFhF
TikgWzIwMTItMTAtMTAgMTU6MTc6NTRdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNiBnZm49
ZjMwMjIgbWZuPWY5ZmY5IG5yPTENCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU0XSBtZW1v
cnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDIyIG1mbj1mOWZmOSBucj0xDQooWEVOKSBbMjAx
Mi0xMC0xMCAxNToxNzo1NF0gbWVtb3J5X21hcDpyZW1vdmU6IGRvbTE2IGdmbj1mMzAyMiBt
Zm49ZjlmZjkgbnI9MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NTRdIG1lbW9yeV9tYXA6
YWRkOiBkb20xNiBnZm49ZjMwMjIgbWZuPWY5ZmY5IG5yPTENCihYRU4pIFsyMDEyLTEwLTEw
IDE1OjE3OjU0XSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYgZ2ZuPWYzMDIyIG1mbj1mOWZm
OSBucj0xDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzo1NF0gbWVtb3J5X21hcDphZGQ6IGRv
bTE2IGdmbj1mMzAyMiBtZm49ZjlmZjkgbnI9MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6
NTRdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNiBnZm49ZjMwMjIgbWZuPWY5ZmY5IG5yPTEN
CihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU0XSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2Zu
PWYzMDIyIG1mbj1mOWZmOSBucj0xDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzo1NF0gbWVt
b3J5X21hcDpyZW1vdmU6IGRvbTE2IGdmbj1mMzAyMyBtZm49ZjlmZmEgbnI9MQ0KKFhFTikg
WzIwMTItMTAtMTAgMTU6MTc6NTRdIG1lbW9yeV9tYXA6YWRkOiBkb20xNiBnZm49ZjMwMjMg
bWZuPWY5ZmZhIG5yPTENCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU0XSBtZW1vcnlfbWFw
OnJlbW92ZTogZG9tMTYgZ2ZuPWYzMDIzIG1mbj1mOWZmYSBucj0xDQooWEVOKSBbMjAxMi0x
MC0xMCAxNToxNzo1NF0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzAyMyBtZm49Zjlm
ZmEgbnI9MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NTRdIG1lbW9yeV9tYXA6cmVtb3Zl
OiBkb20xNiBnZm49ZjMwMjMgbWZuPWY5ZmZhIG5yPTENCihYRU4pIFsyMDEyLTEwLTEwIDE1
OjE3OjU0XSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDIzIG1mbj1mOWZmYSBucj0x
DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzo1NF0gbWVtb3J5X21hcDpyZW1vdmU6IGRvbTE2
IGdmbj1mMzAyMyBtZm49ZjlmZmEgbnI9MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NTRd
IG1lbW9yeV9tYXA6YWRkOiBkb20xNiBnZm49ZjMwMjMgbWZuPWY5ZmZhIG5yPTENCihYRU4p
IFsyMDEyLTEwLTEwIDE1OjE3OjU0XSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYgZ2ZuPWYz
MDIzIG1mbj1mOWZmYSBucj0xDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzo1NF0gbWVtb3J5
X21hcDphZGQ6IGRvbTE2IGdmbj1mMzAyMyBtZm49ZjlmZmEgbnI9MQ0KKFhFTikgWzIwMTIt
MTAtMTAgMTU6MTc6NTRdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNiBnZm49ZjMwMjMgbWZu
PWY5ZmZhIG5yPTENCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU0XSBtZW1vcnlfbWFwOmFk
ZDogZG9tMTYgZ2ZuPWYzMDIzIG1mbj1mOWZmYSBucj0xDQooWEVOKSBbMjAxMi0xMC0xMCAx
NToxNzo1NF0gbWVtb3J5X21hcDpyZW1vdmU6IGRvbTE2IGdmbj1mMzAyMyBtZm49ZjlmZmEg
bnI9MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NTRdIG1lbW9yeV9tYXA6YWRkOiBkb20x
NiBnZm49ZjMwMjMgbWZuPWY5ZmZhIG5yPTENCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU0
XSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYgZ2ZuPWYzMDI0IG1mbj1mOWZmYiBucj0xDQoo
WEVOKSBbMjAxMi0xMC0xMCAxNToxNzo1NF0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1m
MzAyNCBtZm49ZjlmZmIgbnI9MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NTRdIG1lbW9y
eV9tYXA6cmVtb3ZlOiBkb20xNiBnZm49ZjMwMjQgbWZuPWY5ZmZiIG5yPTENCihYRU4pIFsy
MDEyLTEwLTEwIDE1OjE3OjU0XSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDI0IG1m
bj1mOWZmYiBucj0xDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzo1NF0gbWVtb3J5X21hcDpy
ZW1vdmU6IGRvbTE2IGdmbj1mMzAyNCBtZm49ZjlmZmIgbnI9MQ0KKFhFTikgWzIwMTItMTAt
MTAgMTU6MTc6NTRdIG1lbW9yeV9tYXA6YWRkOiBkb20xNiBnZm49ZjMwMjQgbWZuPWY5ZmZi
IG5yPTENCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU0XSBtZW1vcnlfbWFwOnJlbW92ZTog
ZG9tMTYgZ2ZuPWYzMDI0IG1mbj1mOWZmYiBucj0xDQooWEVOKSBbMjAxMi0xMC0xMCAxNTox
Nzo1NF0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzAyNCBtZm49ZjlmZmIgbnI9MQ0K
KFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NTRdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNiBn
Zm49ZjMwMjQgbWZuPWY5ZmZiIG5yPTENCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU0XSBt
ZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDI0IG1mbj1mOWZmYiBucj0xDQooWEVOKSBb
MjAxMi0xMC0xMCAxNToxNzo1NF0gbWVtb3J5X21hcDpyZW1vdmU6IGRvbTE2IGdmbj1mMzAy
NCBtZm49ZjlmZmIgbnI9MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NTRdIG1lbW9yeV9t
YXA6YWRkOiBkb20xNiBnZm49ZjMwMjQgbWZuPWY5ZmZiIG5yPTENCihYRU4pIFsyMDEyLTEw
LTEwIDE1OjE3OjU0XSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYgZ2ZuPWYzMDI0IG1mbj1m
OWZmYiBucj0xDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzo1NF0gbWVtb3J5X21hcDphZGQ6
IGRvbTE2IGdmbj1mMzAyNCBtZm49ZjlmZmIgbnI9MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6
MTc6NTRdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNiBnZm49ZjMwMjUgbWZuPWY5ZmZjIG5y
PTENCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU0XSBtZW1vcnlfbWFwOmFkZDogZG9tMTYg
Z2ZuPWYzMDI1IG1mbj1mOWZmYyBucj0xDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzo1NF0g
bWVtb3J5X21hcDpyZW1vdmU6IGRvbTE2IGdmbj1mMzAyNSBtZm49ZjlmZmMgbnI9MQ0KKFhF
TikgWzIwMTItMTAtMTAgMTU6MTc6NTRdIG1lbW9yeV9tYXA6YWRkOiBkb20xNiBnZm49ZjMw
MjUgbWZuPWY5ZmZjIG5yPTENCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU0XSBtZW1vcnlf
bWFwOnJlbW92ZTogZG9tMTYgZ2ZuPWYzMDI1IG1mbj1mOWZmYyBucj0xDQooWEVOKSBbMjAx
Mi0xMC0xMCAxNToxNzo1NF0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzAyNSBtZm49
ZjlmZmMgbnI9MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NTRdIG1lbW9yeV9tYXA6cmVt
b3ZlOiBkb20xNiBnZm49ZjMwMjUgbWZuPWY5ZmZjIG5yPTENCihYRU4pIFsyMDEyLTEwLTEw
IDE1OjE3OjU0XSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDI1IG1mbj1mOWZmYyBu
cj0xDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzo1NF0gbWVtb3J5X21hcDpyZW1vdmU6IGRv
bTE2IGdmbj1mMzAyNSBtZm49ZjlmZmMgbnI9MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6
NTRdIG1lbW9yeV9tYXA6YWRkOiBkb20xNiBnZm49ZjMwMjUgbWZuPWY5ZmZjIG5yPTENCihY
RU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU0XSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYgZ2Zu
PWYzMDI1IG1mbj1mOWZmYyBucj0xDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzo1NF0gbWVt
b3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzAyNSBtZm49ZjlmZmMgbnI9MQ0KKFhFTikgWzIw
MTItMTAtMTAgMTU6MTc6NTRdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNiBnZm49ZjMwMjUg
bWZuPWY5ZmZjIG5yPTENCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU0XSBtZW1vcnlfbWFw
OmFkZDogZG9tMTYgZ2ZuPWYzMDI1IG1mbj1mOWZmYyBucj0xDQooWEVOKSBbMjAxMi0xMC0x
MCAxNToxNzo1NF0gbWVtb3J5X21hcDpyZW1vdmU6IGRvbTE2IGdmbj1mMzAyNiBtZm49Zjlm
ZmQgbnI9MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NTRdIG1lbW9yeV9tYXA6YWRkOiBk
b20xNiBnZm49ZjMwMjYgbWZuPWY5ZmZkIG5yPTENCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3
OjU0XSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYgZ2ZuPWYzMDI2IG1mbj1mOWZmZCBucj0x
DQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzo1NF0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdm
bj1mMzAyNiBtZm49ZjlmZmQgbnI9MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NTRdIG1l
bW9yeV9tYXA6cmVtb3ZlOiBkb20xNiBnZm49ZjMwMjYgbWZuPWY5ZmZkIG5yPTENCihYRU4p
IFsyMDEyLTEwLTEwIDE1OjE3OjU0XSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDI2
IG1mbj1mOWZmZCBucj0xDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzo1NF0gbWVtb3J5X21h
cDpyZW1vdmU6IGRvbTE2IGdmbj1mMzAyNiBtZm49ZjlmZmQgbnI9MQ0KKFhFTikgWzIwMTIt
MTAtMTAgMTU6MTc6NTRdIG1lbW9yeV9tYXA6YWRkOiBkb20xNiBnZm49ZjMwMjYgbWZuPWY5
ZmZkIG5yPTENCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU0XSBtZW1vcnlfbWFwOnJlbW92
ZTogZG9tMTYgZ2ZuPWYzMDI2IG1mbj1mOWZmZCBucj0xDQooWEVOKSBbMjAxMi0xMC0xMCAx
NToxNzo1NF0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzAyNiBtZm49ZjlmZmQgbnI9
MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NTRdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20x
NiBnZm49ZjMwMjYgbWZuPWY5ZmZkIG5yPTENCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU0
XSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDI2IG1mbj1mOWZmZCBucj0xDQooWEVO
KSBbMjAxMi0xMC0xMCAxNToxNzo1NF0gbWVtb3J5X21hcDpyZW1vdmU6IGRvbTE2IGdmbj1m
MzAyNiBtZm49ZjlmZmQgbnI9MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NTRdIG1lbW9y
eV9tYXA6YWRkOiBkb20xNiBnZm49ZjMwMjYgbWZuPWY5ZmZkIG5yPTENCihYRU4pIFsyMDEy
LTEwLTEwIDE1OjE3OjU0XSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYgZ2ZuPWYzMDI3IG1m
bj1mOWZmZSBucj0xDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzo1NF0gbWVtb3J5X21hcDph
ZGQ6IGRvbTE2IGdmbj1mMzAyNyBtZm49ZjlmZmUgbnI9MQ0KKFhFTikgWzIwMTItMTAtMTAg
MTU6MTc6NTRdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNiBnZm49ZjMwMjcgbWZuPWY5ZmZl
IG5yPTENCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU0XSBtZW1vcnlfbWFwOmFkZDogZG9t
MTYgZ2ZuPWYzMDI3IG1mbj1mOWZmZSBucj0xDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzo1
NF0gbWVtb3J5X21hcDpyZW1vdmU6IGRvbTE2IGdmbj1mMzAyNyBtZm49ZjlmZmUgbnI9MQ0K
KFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NTRdIG1lbW9yeV9tYXA6YWRkOiBkb20xNiBnZm49
ZjMwMjcgbWZuPWY5ZmZlIG5yPTENCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU0XSBtZW1v
cnlfbWFwOnJlbW92ZTogZG9tMTYgZ2ZuPWYzMDI3IG1mbj1mOWZmZSBucj0xDQooWEVOKSBb
MjAxMi0xMC0xMCAxNToxNzo1NF0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzAyNyBt
Zm49ZjlmZmUgbnI9MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NTRdIG1lbW9yeV9tYXA6
cmVtb3ZlOiBkb20xNiBnZm49ZjMwMjcgbWZuPWY5ZmZlIG5yPTENCihYRU4pIFsyMDEyLTEw
LTEwIDE1OjE3OjU0XSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDI3IG1mbj1mOWZm
ZSBucj0xDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzo1NF0gbWVtb3J5X21hcDpyZW1vdmU6
IGRvbTE2IGdmbj1mMzAyNyBtZm49ZjlmZmUgbnI9MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6
MTc6NTRdIG1lbW9yeV9tYXA6YWRkOiBkb20xNiBnZm49ZjMwMjcgbWZuPWY5ZmZlIG5yPTEN
CihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU0XSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYg
Z2ZuPWYzMDI3IG1mbj1mOWZmZSBucj0xDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzo1NF0g
bWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzAyNyBtZm49ZjlmZmUgbnI9MQ0KKFhFTikg
WzIwMTItMTAtMTAgMTU6MTc6NTRdIG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNiBnZm49ZjMw
MjggbWZuPWY5ZmZmIG5yPTENCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU0XSBtZW1vcnlf
bWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDI4IG1mbj1mOWZmZiBucj0xDQooWEVOKSBbMjAxMi0x
MC0xMCAxNToxNzo1NF0gbWVtb3J5X21hcDpyZW1vdmU6IGRvbTE2IGdmbj1mMzAyOCBtZm49
ZjlmZmYgbnI9MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NTRdIG1lbW9yeV9tYXA6YWRk
OiBkb20xNiBnZm49ZjMwMjggbWZuPWY5ZmZmIG5yPTENCihYRU4pIFsyMDEyLTEwLTEwIDE1
OjE3OjU0XSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTYgZ2ZuPWYzMDI4IG1mbj1mOWZmZiBu
cj0xDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzo1NF0gbWVtb3J5X21hcDphZGQ6IGRvbTE2
IGdmbj1mMzAyOCBtZm49ZjlmZmYgbnI9MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NTRd
IG1lbW9yeV9tYXA6cmVtb3ZlOiBkb20xNiBnZm49ZjMwMjggbWZuPWY5ZmZmIG5yPTENCihY
RU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU0XSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYz
MDI4IG1mbj1mOWZmZiBucj0xDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzo1NF0gbWVtb3J5
X21hcDpyZW1vdmU6IGRvbTE2IGdmbj1mMzAyOCBtZm49ZjlmZmYgbnI9MQ0KKFhFTikgWzIw
MTItMTAtMTAgMTU6MTc6NTRdIG1lbW9yeV9tYXA6YWRkOiBkb20xNiBnZm49ZjMwMjggbWZu
PWY5ZmZmIG5yPTENCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU0XSBtZW1vcnlfbWFwOnJl
bW92ZTogZG9tMTYgZ2ZuPWYzMDI4IG1mbj1mOWZmZiBucj0xDQooWEVOKSBbMjAxMi0xMC0x
MCAxNToxNzo1NF0gbWVtb3J5X21hcDphZGQ6IGRvbTE2IGdmbj1mMzAyOCBtZm49ZjlmZmYg
bnI9MQ0KKFhFTikgWzIwMTItMTAtMTAgMTU6MTc6NTRdIG1lbW9yeV9tYXA6cmVtb3ZlOiBk
b20xNiBnZm49ZjMwMjggbWZuPWY5ZmZmIG5yPTENCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3
OjU0XSBtZW1vcnlfbWFwOmFkZDogZG9tMTYgZ2ZuPWYzMDI4IG1mbj1mOWZmZiBucj0xDQoo
WEVOKSBbMjAxMi0xMC0xMCAxNToxNzo1NV0gaXJxLmM6MjcwOiBEb20xNiBQQ0kgbGluayAw
IGNoYW5nZWQgNSAtPiAwDQooWEVOKSBbMjAxMi0xMC0xMCAxNToxNzo1NV0gaXJxLmM6Mjcw
OiBEb20xNiBQQ0kgbGluayAxIGNoYW5nZWQgMTAgLT4gMA0KKFhFTikgWzIwMTItMTAtMTAg
MTU6MTc6NTVdIGlycS5jOjI3MDogRG9tMTYgUENJIGxpbmsgMiBjaGFuZ2VkIDExIC0+IDAN
CihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU1XSBpcnEuYzoyNzA6IERvbTE2IFBDSSBsaW5r
IDMgY2hhbmdlZCA1IC0+IDANCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU2XSBldmVudF9j
aGFubmVsLmM6Mzc3OmQxNiBFVlRDSE5PUCBmYWlsdXJlOiBlcnJvciAtMTcNCihYRU4pIFsy
MDEyLTEwLTEwIDE1OjE3OjU2XSBldmVudF9jaGFubmVsLmM6Mzc3OmQxNiBFVlRDSE5PUCBm
YWlsdXJlOiBlcnJvciAtMTcNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU2XSBldmVudF9j
aGFubmVsLmM6Mzc3OmQxNiBFVlRDSE5PUCBmYWlsdXJlOiBlcnJvciAtMTcNCihYRU4pIFsy
MDEyLTEwLTEwIDE1OjE3OjU2XSBldmVudF9jaGFubmVsLmM6Mzc3OmQxNiBFVlRDSE5PUCBm
YWlsdXJlOiBlcnJvciAtMTcNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU2XSBldmVudF9j
aGFubmVsLmM6Mzc3OmQxNiBFVlRDSE5PUCBmYWlsdXJlOiBlcnJvciAtMTcNCihYRU4pIFsy
MDEyLTEwLTEwIDE1OjE3OjU2XSBldmVudF9jaGFubmVsLmM6Mzc3OmQxNiBFVlRDSE5PUCBm
YWlsdXJlOiBlcnJvciAtMTcNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU2XSBldmVudF9j
aGFubmVsLmM6Mzc3OmQxNiBFVlRDSE5PUCBmYWlsdXJlOiBlcnJvciAtMTcNCihYRU4pIFsy
MDEyLTEwLTEwIDE1OjE3OjU2XSBldmVudF9jaGFubmVsLmM6Mzc3OmQxNiBFVlRDSE5PUCBm
YWlsdXJlOiBlcnJvciAtMTcNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU2XSBldmVudF9j
aGFubmVsLmM6Mzc3OmQxNiBFVlRDSE5PUCBmYWlsdXJlOiBlcnJvciAtMTcNCihYRU4pIFsy
MDEyLTEwLTEwIDE1OjE3OjU2XSBldmVudF9jaGFubmVsLmM6Mzc3OmQxNiBFVlRDSE5PUCBm
YWlsdXJlOiBlcnJvciAtMTcNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU2XSBldmVudF9j
aGFubmVsLmM6Mzc3OmQxNiBFVlRDSE5PUCBmYWlsdXJlOiBlcnJvciAtMTcNCihYRU4pIFsy
MDEyLTEwLTEwIDE1OjE3OjU2XSBldmVudF9jaGFubmVsLmM6Mzc3OmQxNiBFVlRDSE5PUCBm
YWlsdXJlOiBlcnJvciAtMTcNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU3XSBldmVudF9j
aGFubmVsLmM6Mzc3OmQxNiBFVlRDSE5PUCBmYWlsdXJlOiBlcnJvciAtMTcNCihYRU4pIFsy
MDEyLTEwLTEwIDE1OjE3OjU3XSBldmVudF9jaGFubmVsLmM6Mzc3OmQxNiBFVlRDSE5PUCBm
YWlsdXJlOiBlcnJvciAtMTcNCihYRU4pIFsyMDEyLTEwLTEwIDE1OjE3OjU3XSBldmVudF9j
aGFubmVsLmM6Mzc3OmQxNiBFVlRDSE5PUCBmYWlsdXJlOiBlcnJvciAtMTcNCg==
------------08613C0C31EE607B1
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

------------08613C0C31EE607B1--



From xen-devel-bounces@lists.xen.org Wed Oct 10 16:18:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 16:18:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLyz0-0003PN-Hr; Wed, 10 Oct 2012 16:18:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLyyy-0003PI-V7
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 16:18:05 +0000
Received: from [85.158.137.99:34701] by server-7.bemta-3.messagelabs.com id
	21/77-06991-CBF95705; Wed, 10 Oct 2012 16:18:04 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1349885883!21033259!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM3MzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27697 invoked from network); 10 Oct 2012 16:18:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 16:18:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,565,1344211200"; 
	d="asc'?scan'208";a="15080709"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 16:18:03 +0000
Received: from [IPv6:::1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 10 Oct 2012 17:18:03 +0100
Message-ID: <1349885882.3610.227.camel@Abyss>
From: Dario Faggioli 
To: Dan Magenheimer 
Date: Wed, 10 Oct 2012 17:18:02 +0100
In-Reply-To: 
References: 
	
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
MIME-Version: 1.0
Cc: Marcus Granado ,
	Andre Przywara ,
	Ian Campbell ,
	Anil Madhavapeddy , George
	Dunlap ,
	Andrew Cooper ,
	Juergen Gross ,
	Ian Jackson , xen-devel@lists.xen.org,
	Jan Beulich , Daniel De Graaf ,
	Matt Wilson 
Subject: Re: [Xen-devel] [PATCH 0 of 8] NUMA Awareness for the Credit
 Scheduler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============2584223142133803677=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2584223142133803677==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-mp7q0XtYWbXdHWTyDC4E"

--=-mp7q0XtYWbXdHWTyDC4E
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2012-10-08 at 12:43 -0700, Dan Magenheimer wrote:=20
> Just wondering... is the NUMA information preserved on live migration?
> I'm not saying that it necessarily should, but it may just work
> due to the implementation (since migration is a form of domain creation).
> In either case, it might be good to comment about live migration
> on your wiki.
>=20
FYI:

http://wiki.xen.org/wiki/Xen_NUMA_Introduction=20
http://wiki.xen.org/wiki?title=3DXen_NUMA_Introduction&diff=3D5327&oldid=3D=
4598

As per the NUMA roadmap ( http://wiki.xen.org/wiki/Xen_NUMA_Roadmap ),
you can see here [1] that it was already there. :-)

Regards,
Dario

[1] http://wiki.xen.org/wiki/Xen_NUMA_Roadmap#Virtual_NUMA_topology_exposur=
e_to_guests

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-mp7q0XtYWbXdHWTyDC4E
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlB1n7oACgkQk4XaBE3IOsQuwgCfX5S1xQXEnu9Av98uSGB/OYM0
KaAAoIb28+hh9ROR8vemAyprsPUTd8Df
=fEw8
-----END PGP SIGNATURE-----

--=-mp7q0XtYWbXdHWTyDC4E--


--===============2584223142133803677==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2584223142133803677==--


From xen-devel-bounces@lists.xen.org Wed Oct 10 16:18:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 16:18:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLyz0-0003PN-Hr; Wed, 10 Oct 2012 16:18:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLyyy-0003PI-V7
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 16:18:05 +0000
Received: from [85.158.137.99:34701] by server-7.bemta-3.messagelabs.com id
	21/77-06991-CBF95705; Wed, 10 Oct 2012 16:18:04 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1349885883!21033259!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM3MzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27697 invoked from network); 10 Oct 2012 16:18:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 16:18:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,565,1344211200"; 
	d="asc'?scan'208";a="15080709"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 16:18:03 +0000
Received: from [IPv6:::1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 10 Oct 2012 17:18:03 +0100
Message-ID: <1349885882.3610.227.camel@Abyss>
From: Dario Faggioli 
To: Dan Magenheimer 
Date: Wed, 10 Oct 2012 17:18:02 +0100
In-Reply-To: 
References: 
	
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
MIME-Version: 1.0
Cc: Marcus Granado ,
	Andre Przywara ,
	Ian Campbell ,
	Anil Madhavapeddy , George
	Dunlap ,
	Andrew Cooper ,
	Juergen Gross ,
	Ian Jackson , xen-devel@lists.xen.org,
	Jan Beulich , Daniel De Graaf ,
	Matt Wilson 
Subject: Re: [Xen-devel] [PATCH 0 of 8] NUMA Awareness for the Credit
 Scheduler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============2584223142133803677=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2584223142133803677==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-mp7q0XtYWbXdHWTyDC4E"

--=-mp7q0XtYWbXdHWTyDC4E
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2012-10-08 at 12:43 -0700, Dan Magenheimer wrote:=20
> Just wondering... is the NUMA information preserved on live migration?
> I'm not saying that it necessarily should, but it may just work
> due to the implementation (since migration is a form of domain creation).
> In either case, it might be good to comment about live migration
> on your wiki.
>=20
FYI:

http://wiki.xen.org/wiki/Xen_NUMA_Introduction=20
http://wiki.xen.org/wiki?title=3DXen_NUMA_Introduction&diff=3D5327&oldid=3D=
4598

As per the NUMA roadmap ( http://wiki.xen.org/wiki/Xen_NUMA_Roadmap ),
you can see here [1] that it was already there. :-)

Regards,
Dario

[1] http://wiki.xen.org/wiki/Xen_NUMA_Roadmap#Virtual_NUMA_topology_exposur=
e_to_guests

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-mp7q0XtYWbXdHWTyDC4E
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlB1n7oACgkQk4XaBE3IOsQuwgCfX5S1xQXEnu9Av98uSGB/OYM0
KaAAoIb28+hh9ROR8vemAyprsPUTd8Df
=fEw8
-----END PGP SIGNATURE-----

--=-mp7q0XtYWbXdHWTyDC4E--


--===============2584223142133803677==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2584223142133803677==--


From xen-devel-bounces@lists.xen.org Wed Oct 10 16:44:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 16:44:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLzNs-0003ez-4I; Wed, 10 Oct 2012 16:43:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLzNr-0003et-9T
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 16:43:47 +0000
Received: from [85.158.143.99:48444] by server-2.bemta-4.messagelabs.com id
	AC/C5-25171-2C5A5705; Wed, 10 Oct 2012 16:43:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1349887426!25430687!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM3MzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3822 invoked from network); 10 Oct 2012 16:43:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 16:43:46 -0000
X-IronPort-AV: E=Sophos;i="4.80,565,1344211200"; d="scan'208";a="15081088"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 16:43:45 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 10 Oct 2012 17:43:45 +0100
Message-ID: <1349887424.14806.2.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Sander Eikelenboom 
Date: Wed, 10 Oct 2012 17:43:44 +0100
In-Reply-To: <1786005637.20121010180253@eikelenboom.it>
References: <1786005637.20121010180253@eikelenboom.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel 
Subject: Re: [Xen-devel] xen-unstable: HVM start memory_map:add
	memory_map:remove cycle
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-10 at 17:02 +0100, Sander Eikelenboom wrote:
> Hi Ian,

Why me specifically? Do you think this relates to something I've
committed recently or...?
> 
> When i start a HVM guest i get this cycle of adding removing adding
> removing and finally adding ... for some memory ranges during the
> start of the guest.
> I don't know if it's intentionally, but it seems kind of strange .. :

Can you identify the changeset where it started?

> 
> (XEN) [2012-10-10 15:17:54] memory_map:add: dom16 gfn=f3028 mfn=f9fff nr=1
> (XEN) [2012-10-10 15:17:54] memory_map:remove: dom16 gfn=f3028 mfn=f9fff nr=1
> (XEN) [2012-10-10 15:17:54] memory_map:add: dom16 gfn=f3028 mfn=f9fff nr=1
> (XEN) [2012-10-10 15:17:54] memory_map:remove: dom16 gfn=f3028 mfn=f9fff nr=1
> (XEN) [2012-10-10 15:17:54] memory_map:add: dom16 gfn=f3028 mfn=f9fff nr=1
> (XEN) [2012-10-10 15:17:54] memory_map:remove: dom16 gfn=f3028 mfn=f9fff nr=1
> (XEN) [2012-10-10 15:17:54] memory_map:add: dom16 gfn=f3028 mfn=f9fff nr=1
> (XEN) [2012-10-10 15:17:54] memory_map:remove: dom16 gfn=f3028 mfn=f9fff nr=1
> (XEN) [2012-10-10 15:17:54] memory_map:add: dom16 gfn=f3028 mfn=f9fff nr=1
> (XEN) [2012-10-10 15:17:54] memory_map:remove: dom16 gfn=f3028 mfn=f9fff nr=1
> (XEN) [2012-10-10 15:17:54] memory_map:add: dom16 gfn=f3028 mfn=f9fff nr=1
> (XEN) [2012-10-10 15:17:54] memory_map:remove: dom16 gfn=f3028 mfn=f9fff nr=1
> (XEN) [2012-10-10 15:17:54] memory_map:add: dom16 gfn=f3028 mfn=f9fff nr=1
> 
> 
> xl dmesg attached
> 
> --
> 
> Sander



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 16:44:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 16:44:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLzNs-0003ez-4I; Wed, 10 Oct 2012 16:43:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLzNr-0003et-9T
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 16:43:47 +0000
Received: from [85.158.143.99:48444] by server-2.bemta-4.messagelabs.com id
	AC/C5-25171-2C5A5705; Wed, 10 Oct 2012 16:43:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1349887426!25430687!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM3MzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3822 invoked from network); 10 Oct 2012 16:43:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 16:43:46 -0000
X-IronPort-AV: E=Sophos;i="4.80,565,1344211200"; d="scan'208";a="15081088"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 16:43:45 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 10 Oct 2012 17:43:45 +0100
Message-ID: <1349887424.14806.2.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Sander Eikelenboom 
Date: Wed, 10 Oct 2012 17:43:44 +0100
In-Reply-To: <1786005637.20121010180253@eikelenboom.it>
References: <1786005637.20121010180253@eikelenboom.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel 
Subject: Re: [Xen-devel] xen-unstable: HVM start memory_map:add
	memory_map:remove cycle
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-10 at 17:02 +0100, Sander Eikelenboom wrote:
> Hi Ian,

Why me specifically? Do you think this relates to something I've
committed recently or...?
> 
> When i start a HVM guest i get this cycle of adding removing adding
> removing and finally adding ... for some memory ranges during the
> start of the guest.
> I don't know if it's intentionally, but it seems kind of strange .. :

Can you identify the changeset where it started?

> 
> (XEN) [2012-10-10 15:17:54] memory_map:add: dom16 gfn=f3028 mfn=f9fff nr=1
> (XEN) [2012-10-10 15:17:54] memory_map:remove: dom16 gfn=f3028 mfn=f9fff nr=1
> (XEN) [2012-10-10 15:17:54] memory_map:add: dom16 gfn=f3028 mfn=f9fff nr=1
> (XEN) [2012-10-10 15:17:54] memory_map:remove: dom16 gfn=f3028 mfn=f9fff nr=1
> (XEN) [2012-10-10 15:17:54] memory_map:add: dom16 gfn=f3028 mfn=f9fff nr=1
> (XEN) [2012-10-10 15:17:54] memory_map:remove: dom16 gfn=f3028 mfn=f9fff nr=1
> (XEN) [2012-10-10 15:17:54] memory_map:add: dom16 gfn=f3028 mfn=f9fff nr=1
> (XEN) [2012-10-10 15:17:54] memory_map:remove: dom16 gfn=f3028 mfn=f9fff nr=1
> (XEN) [2012-10-10 15:17:54] memory_map:add: dom16 gfn=f3028 mfn=f9fff nr=1
> (XEN) [2012-10-10 15:17:54] memory_map:remove: dom16 gfn=f3028 mfn=f9fff nr=1
> (XEN) [2012-10-10 15:17:54] memory_map:add: dom16 gfn=f3028 mfn=f9fff nr=1
> (XEN) [2012-10-10 15:17:54] memory_map:remove: dom16 gfn=f3028 mfn=f9fff nr=1
> (XEN) [2012-10-10 15:17:54] memory_map:add: dom16 gfn=f3028 mfn=f9fff nr=1
> 
> 
> xl dmesg attached
> 
> --
> 
> Sander



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 16:48:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 16:48:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLzS0-0003mX-Q3; Wed, 10 Oct 2012 16:48:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLzRz-0003mP-FX
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 16:48:03 +0000
Received: from [85.158.143.35:47912] by server-1.bemta-4.messagelabs.com id
	AE/73-19551-2C6A5705; Wed, 10 Oct 2012 16:48:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1349887681!14490573!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM3MzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21059 invoked from network); 10 Oct 2012 16:48:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 16:48:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,565,1344211200"; d="scan'208";a="15081186"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 16:48:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 10 Oct 2012 17:48:01 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TLzRx-0006I5-7K;
	Wed, 10 Oct 2012 16:48:01 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TLzRw-0002BV-Td;
	Wed, 10 Oct 2012 17:48:01 +0100
To: 
Message-ID: 
From: xen.org 
Date: Wed, 10 Oct 2012 17:48:00 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13945: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13945 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13945/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 13932
 build-i386                    4 xen-build                 fail REGR. vs. 13932

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13932
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13932
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13932
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13932

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  3696dd6a7836
baseline version:
 xen                  099589002239

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper 
  Anthony PERARD 
  Christoph Egger 
  David Vrabel 
  Ian Campbell 
  Ian Jackson 
  Keir Fraser 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Samuel Thibault 
  Samuel Thibault 
  Stefano Stabellini 
  Tim Deegan 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 659 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 16:48:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 16:48:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLzS0-0003mX-Q3; Wed, 10 Oct 2012 16:48:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLzRz-0003mP-FX
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 16:48:03 +0000
Received: from [85.158.143.35:47912] by server-1.bemta-4.messagelabs.com id
	AE/73-19551-2C6A5705; Wed, 10 Oct 2012 16:48:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1349887681!14490573!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM3MzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21059 invoked from network); 10 Oct 2012 16:48:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 16:48:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,565,1344211200"; d="scan'208";a="15081186"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 16:48:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 10 Oct 2012 17:48:01 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TLzRx-0006I5-7K;
	Wed, 10 Oct 2012 16:48:01 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TLzRw-0002BV-Td;
	Wed, 10 Oct 2012 17:48:01 +0100
To: 
Message-ID: 
From: xen.org 
Date: Wed, 10 Oct 2012 17:48:00 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13945: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13945 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13945/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 13932
 build-i386                    4 xen-build                 fail REGR. vs. 13932

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13932
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13932
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13932
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13932

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  3696dd6a7836
baseline version:
 xen                  099589002239

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper 
  Anthony PERARD 
  Christoph Egger 
  David Vrabel 
  Ian Campbell 
  Ian Jackson 
  Keir Fraser 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Samuel Thibault 
  Samuel Thibault 
  Stefano Stabellini 
  Tim Deegan 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 659 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 16:51:01 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 16:51:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLzUb-0003tQ-Br; Wed, 10 Oct 2012 16:50:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLzUZ-0003tH-SQ
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 16:50:44 +0000
Received: from [85.158.137.99:22419] by server-4.bemta-3.messagelabs.com id
	C7/61-01405-367A5705; Wed, 10 Oct 2012 16:50:43 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1349887842!21086079!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR, RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23953 invoked from network); 10 Oct 2012 16:50:42 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 16:50:42 -0000
Received: by mail-ee0-f43.google.com with SMTP id c13so544311eek.30
	for ;
	Wed, 10 Oct 2012 09:50:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=aSu43FHMA5p4SENo0OgeZsWJR6gjIkhUciRkoyqkFFM=;
	b=d7y7f5sNPEWgw6FAindR9dXhYeik3idWPLcP418ioKTFhNCGemGhnhjrsRJkjlEvkX
	IQYUGA7d/0K31kF8FwyQopkqfm+IM5LZunqiOGPuDsT1E2SWl1R3KFY4l54X/PaZA26L
	ijr/Of2il6b8wmlAKQ24Juv8rZFJayZWVjJ6lL9llarHs0c2gP4Fy74Xsv5DsBW6HzcZ
	e5zffdNPL0yXsn4lCRizjvpo1ucKctBr6UseNNgSBTdQ2H1MXO+yIA1iwILg5Dw10X1m
	uZrQX/HWj4JATl5LT0P+8GrD1Q/YeBcScWViPU46TtUqh6xIcGOKipFQ4tUDz1eOQXam
	BEEA==
MIME-Version: 1.0
Received: by 10.14.4.201 with SMTP id 49mr34439822eej.0.1349887842100; Wed, 10
	Oct 2012 09:50:42 -0700 (PDT)
Received: by 10.14.134.10 with HTTP; Wed, 10 Oct 2012 09:50:42 -0700 (PDT)
In-Reply-To: <1341325462.21547.20.camel@zakaz.uk.xensource.com>
References: 
	<1338987918.32319.84.camel@zakaz.uk.xensource.com>
	
	<1339049291.6557.11.camel@dagon.hellion.org.uk>
	
	<1341325462.21547.20.camel@zakaz.uk.xensource.com>
Date: Wed, 10 Oct 2012 17:50:42 +0100
X-Google-Sender-Auth: oEEGXAjpHaNCHNA5NVlffXC7M8s
Message-ID: 
From: George Dunlap 
To: Ian Campbell 
Cc: ZhouPeng ,
	"Xen-Devel \(E-mail\)" ,
	Ian Jackson ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 2/3] tools:libxl: Add qxl vga interface
 support v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Jul 3, 2012 at 3:24 PM, Ian Campbell  wrote:
> On Tue, 2012-07-03 at 12:30 +0100, ZhouPeng wrote:
>> qxl support and docs accordingly
>> v3
>> --
>>
>> tools:libxl: Add qxl vga interface support for upstream-qemu-xen.
>>
>> Usage:
>>   qxl=1|0
>>
>> Signed-off-by: Zhou Peng 
>
> Thanks. As previously mentioned we think this is 4.3 material. Please
> could you resubmit (or otherwise remind us) once the 4.3 development
> branch has opened.

Now that 4.3 development has started, what's the status of this patch?
 Does it need a refresh?  Zhou Peng, if you're planning to get this
working for 4.3, can I add this to my 4.3 feature tracking list?

Thanks,
 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 16:51:01 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 16:51:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TLzUb-0003tQ-Br; Wed, 10 Oct 2012 16:50:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TLzUZ-0003tH-SQ
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 16:50:44 +0000
Received: from [85.158.137.99:22419] by server-4.bemta-3.messagelabs.com id
	C7/61-01405-367A5705; Wed, 10 Oct 2012 16:50:43 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1349887842!21086079!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR, RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23953 invoked from network); 10 Oct 2012 16:50:42 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 16:50:42 -0000
Received: by mail-ee0-f43.google.com with SMTP id c13so544311eek.30
	for ;
	Wed, 10 Oct 2012 09:50:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=aSu43FHMA5p4SENo0OgeZsWJR6gjIkhUciRkoyqkFFM=;
	b=d7y7f5sNPEWgw6FAindR9dXhYeik3idWPLcP418ioKTFhNCGemGhnhjrsRJkjlEvkX
	IQYUGA7d/0K31kF8FwyQopkqfm+IM5LZunqiOGPuDsT1E2SWl1R3KFY4l54X/PaZA26L
	ijr/Of2il6b8wmlAKQ24Juv8rZFJayZWVjJ6lL9llarHs0c2gP4Fy74Xsv5DsBW6HzcZ
	e5zffdNPL0yXsn4lCRizjvpo1ucKctBr6UseNNgSBTdQ2H1MXO+yIA1iwILg5Dw10X1m
	uZrQX/HWj4JATl5LT0P+8GrD1Q/YeBcScWViPU46TtUqh6xIcGOKipFQ4tUDz1eOQXam
	BEEA==
MIME-Version: 1.0
Received: by 10.14.4.201 with SMTP id 49mr34439822eej.0.1349887842100; Wed, 10
	Oct 2012 09:50:42 -0700 (PDT)
Received: by 10.14.134.10 with HTTP; Wed, 10 Oct 2012 09:50:42 -0700 (PDT)
In-Reply-To: <1341325462.21547.20.camel@zakaz.uk.xensource.com>
References: 
	<1338987918.32319.84.camel@zakaz.uk.xensource.com>
	
	<1339049291.6557.11.camel@dagon.hellion.org.uk>
	
	<1341325462.21547.20.camel@zakaz.uk.xensource.com>
Date: Wed, 10 Oct 2012 17:50:42 +0100
X-Google-Sender-Auth: oEEGXAjpHaNCHNA5NVlffXC7M8s
Message-ID: 
From: George Dunlap 
To: Ian Campbell 
Cc: ZhouPeng ,
	"Xen-Devel \(E-mail\)" ,
	Ian Jackson ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 2/3] tools:libxl: Add qxl vga interface
 support v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Jul 3, 2012 at 3:24 PM, Ian Campbell  wrote:
> On Tue, 2012-07-03 at 12:30 +0100, ZhouPeng wrote:
>> qxl support and docs accordingly
>> v3
>> --
>>
>> tools:libxl: Add qxl vga interface support for upstream-qemu-xen.
>>
>> Usage:
>>   qxl=1|0
>>
>> Signed-off-by: Zhou Peng 
>
> Thanks. As previously mentioned we think this is 4.3 material. Please
> could you resubmit (or otherwise remind us) once the 4.3 development
> branch has opened.

Now that 4.3 development has started, what's the status of this patch?
 Does it need a refresh?  Zhou Peng, if you're planning to get this
working for 4.3, can I add this to my 4.3 feature tracking list?

Thanks,
 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 17:53:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 17:53:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TM0Sc-0004KY-7j; Wed, 10 Oct 2012 17:52:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TM0Sa-0004KE-B7
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 17:52:44 +0000
Received: from [85.158.137.99:65291] by server-14.bemta-3.messagelabs.com id
	67/7A-17276-BE5B5705; Wed, 10 Oct 2012 17:52:43 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1349891561!19869321!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgwNDY4OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14737 invoked from network); 10 Oct 2012 17:52:42 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Oct 2012 17:52:42 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9AHqcZ2017018
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 10 Oct 2012 17:52:39 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9AHqc0x008238
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 10 Oct 2012 17:52:38 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9AHqcN7016242; Wed, 10 Oct 2012 12:52:38 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 10 Oct 2012 10:52:37 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id AD0D140376; Wed, 10 Oct 2012 13:40:50 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Date: Wed, 10 Oct 2012 13:40:49 -0400
Message-Id: <1349890849-17471-4-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1349890849-17471-1-git-send-email-konrad.wilk@oracle.com>
References: <1349890849-17471-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 3/3] xen/bootup: allow read_tscp call for Xen PV
	guests.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The hypervisor will trap it. However without this patch,
we would crash as the .read_tscp is set to NULL. This patch
fixes it and sets it to the native_read_tscp call.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/xen/enlighten.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index e1e4636..c1461de 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1175,6 +1175,8 @@ static const struct pv_cpu_ops xen_cpu_ops __initconst = {
 	.read_tsc = native_read_tsc,
 	.read_pmc = native_read_pmc,
 
+	.read_tscp = native_read_tscp,
+
 	.iret = xen_iret,
 	.irq_enable_sysexit = xen_sysexit,
 #ifdef CONFIG_X86_64
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 17:53:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 17:53:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TM0Sa-0004KQ-R4; Wed, 10 Oct 2012 17:52:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TM0SZ-0004K5-Gc
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 17:52:43 +0000
Received: from [85.158.139.83:45474] by server-13.bemta-5.messagelabs.com id
	F5/B0-29905-AE5B5705; Wed, 10 Oct 2012 17:52:42 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1349891560!34116914!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgwNDY4OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15807 invoked from network); 10 Oct 2012 17:52:42 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Oct 2012 17:52:42 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9AHqcaM017002
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 10 Oct 2012 17:52:39 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9AHqbkM027736
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 10 Oct 2012 17:52:38 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9AHqbXj016237; Wed, 10 Oct 2012 12:52:37 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 10 Oct 2012 10:52:37 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 992114031E; Wed, 10 Oct 2012 13:40:50 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Date: Wed, 10 Oct 2012 13:40:46 -0400
Message-Id: <1349890849-17471-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Subject: [Xen-devel] [PATCH v1] Various bug-fixes for v3.6.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hey,

Three patches that were discovered with v3.6. The first one:

 [PATCH 1/3] xen/pv-on-hvm kexec: add quirk for Xen 3.4 and shutdown
should have been found earlier, but it seems there is only a small selection
of provides run Xen 3.4 and without the 23839:42a45baf037d in xen-unstable.hg fix.
It is easy to reproduce with OVM 2.2 product.

The other two are a bit embarrassing. We had a similar issue with rdmsr_safe
pvops call in v3.5 where it was not implemented for Xen PV (but rdmsr was).
The fix was to make rdmsr_safe a macro around rdmsr and a lookout for other
calls that were not implemented. Well, v3.6 has gone by and now I find three other
culprits:
 [PATCH 2/3] xen/bootup: allow {read|write}_cr8 pvops call.
 [PATCH 3/3] xen/bootup: allow read_tscp call for Xen PV guests.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 17:53:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 17:53:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TM0Sd-0004L2-PC; Wed, 10 Oct 2012 17:52:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TM0Sc-0004KX-69
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 17:52:46 +0000
Received: from [85.158.143.99:45658] by server-2.bemta-4.messagelabs.com id
	3A/43-25171-DE5B5705; Wed, 10 Oct 2012 17:52:45 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1349891563!23845760!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgwNDY4OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21698 invoked from network); 10 Oct 2012 17:52:44 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Oct 2012 17:52:44 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9AHqdxi017020
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 10 Oct 2012 17:52:40 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9AHqcZA010321
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 10 Oct 2012 17:52:39 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9AHqbr0026285; Wed, 10 Oct 2012 12:52:37 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 10 Oct 2012 10:52:37 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id A118E402BD; Wed, 10 Oct 2012 13:40:50 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Date: Wed, 10 Oct 2012 13:40:47 -0400
Message-Id: <1349890849-17471-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1349890849-17471-1-git-send-email-konrad.wilk@oracle.com>
References: <1349890849-17471-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Olaf Hering , stable@vger.kernel.org,
	Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 1/3] xen/pv-on-hvm kexec: add quirk for Xen 3.4
	and shutdown watches.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The commit 254d1a3f02ebc10ccc6e4903394d8d3f484f715e, titled
"xen/pv-on-hvm kexec: shutdown watches from old kernel" assumes that the
XenBus backend can deal with reading of values from:
 "control/platform-feature-xs_reset_watches":

    ... a patch for xenstored is required so that it
    accepts the XS_RESET_WATCHES request from a client (see changeset
    23839:42a45baf037d in xen-unstable.hg). Without the patch for xenstored
    the registration of watches will fail and some features of a PVonHVM
    guest are not available. The guest is still able to boot, but repeated
    kexec boots will fail."

Sadly this is not true when using a Xen 3.4 hypervisor and booting a PVHVM
guest. We end up hanging at:

  err = xenbus_scanf(XBT_NIL, "control",
                        "platform-feature-xs_reset_watches", "%d", &supported);

This can easily be seen with guests hanging at xenbus_init:

NX (Execute Disable) protection: active
SMBIOS 2.4 present.
DMI: Xen HVM domU, BIOS 3.4.0 05/13/2011
Hypervisor detected: Xen HVM
Xen version 3.4.
Xen Platform PCI: I/O protocol version 1
... snip ..
calling  xenbus_init+0x0/0x27e @ 1

Reverting the commit or using the attached patch fixes the issue. This fix
checks whether the hypervisor is older than 4.0 and if so does not try to
perform the read.

Fixes-Oracle-Bug: 14708233
CC: stable@vger.kernel.org
CC: Olaf Hering 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 drivers/xen/xenbus/xenbus_xs.c |   15 +++++++++++++++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
index bce15cf..91f513b 100644
--- a/drivers/xen/xenbus/xenbus_xs.c
+++ b/drivers/xen/xenbus/xenbus_xs.c
@@ -47,6 +47,7 @@
 #include 
 #include 
 #include "xenbus_comms.h"
+#include 
 
 struct xs_stored_msg {
 	struct list_head list;
@@ -617,7 +618,18 @@ static struct xenbus_watch *find_watch(const char *token)
 
 	return NULL;
 }
+static bool xen_strict_xenbus_quirk()
+{
+	uint32_t eax, ebx, ecx, edx, base;
+
+	base = xen_cpuid_base();
+	cpuid(base + 1, &eax, &ebx, &ecx, &edx);
+
+	if ((eax >> 16) < 4)
+		return true;
+	return false;
 
+}
 static void xs_reset_watches(void)
 {
 	int err, supported = 0;
@@ -625,6 +637,9 @@ static void xs_reset_watches(void)
 	if (!xen_hvm_domain())
 		return;
 
+	if (xen_strict_xenbus_quirk())
+		return;
+
 	err = xenbus_scanf(XBT_NIL, "control",
 			"platform-feature-xs_reset_watches", "%d", &supported);
 	if (err != 1 || !supported)
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 17:53:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 17:53:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TM0Sa-0004KF-Ei; Wed, 10 Oct 2012 17:52:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TM0SZ-0004K4-6l
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 17:52:43 +0000
Received: from [85.158.137.99:12284] by server-5.bemta-3.messagelabs.com id
	97/5C-12440-AE5B5705; Wed, 10 Oct 2012 17:52:42 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1349891560!21063431!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzk0NzQ0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2985 invoked from network); 10 Oct 2012 17:52:41 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-16.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Oct 2012 17:52:41 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9AHqcbv012094
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 10 Oct 2012 17:52:39 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9AHqcK1009242
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 10 Oct 2012 17:52:38 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9AHqbao009948; Wed, 10 Oct 2012 12:52:37 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 10 Oct 2012 10:52:37 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id A5E4240366; Wed, 10 Oct 2012 13:40:50 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Date: Wed, 10 Oct 2012 13:40:48 -0400
Message-Id: <1349890849-17471-3-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1349890849-17471-1-git-send-email-konrad.wilk@oracle.com>
References: <1349890849-17471-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 2/3] xen/bootup: allow {read|write}_cr8 pvops
	call.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We actually do not do anything about it. Just return a default
value of zero and if the kernel tries to write anything but 0
we BUG_ON.

This fixes the case when an user tries to suspend the machine
and it blows up in save_processor_state b/c 'read_cr8' is set
to NULL and we get:

kernel BUG at /home/konrad/ssd/linux/arch/x86/include/asm/paravirt.h:100!
invalid opcode: 0000 [#1] SMP
Pid: 2687, comm: init.late Tainted: G           O 3.6.0upstream-00002-gac264ac-dirty #4 Bochs Bochs
RIP: e030:[]  [] save_processor_state+0x212/0x270

.. snip..
Call Trace:
 [] do_suspend_lowlevel+0xf/0xac
 [] ? x86_acpi_suspend_lowlevel+0x10c/0x150
 [] acpi_suspend_enter+0x57/0xd5

Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/xen/enlighten.c |   16 +++++++++++++++-
 1 files changed, 15 insertions(+), 1 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 1fbe75a..e1e4636 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -984,7 +984,16 @@ static void xen_write_cr4(unsigned long cr4)
 
 	native_write_cr4(cr4);
 }
-
+#ifdef CONFIG_X86_64
+static inline unsigned long xen_read_cr8(void)
+{
+	return 0;
+}
+static inline void xen_write_cr8(unsigned long val)
+{
+	BUG_ON(val);
+}
+#endif
 static int xen_write_msr_safe(unsigned int msr, unsigned low, unsigned high)
 {
 	int ret;
@@ -1153,6 +1162,11 @@ static const struct pv_cpu_ops xen_cpu_ops __initconst = {
 	.read_cr4_safe = native_read_cr4_safe,
 	.write_cr4 = xen_write_cr4,
 
+#ifdef CONFIG_X86_64
+	.read_cr8 = xen_read_cr8,
+	.write_cr8 = xen_write_cr8,
+#endif
+
 	.wbinvd = native_wbinvd,
 
 	.read_msr = native_read_msr_safe,
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 17:53:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 17:53:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TM0Sa-0004KQ-R4; Wed, 10 Oct 2012 17:52:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TM0SZ-0004K5-Gc
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 17:52:43 +0000
Received: from [85.158.139.83:45474] by server-13.bemta-5.messagelabs.com id
	F5/B0-29905-AE5B5705; Wed, 10 Oct 2012 17:52:42 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1349891560!34116914!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgwNDY4OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15807 invoked from network); 10 Oct 2012 17:52:42 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Oct 2012 17:52:42 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9AHqcaM017002
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 10 Oct 2012 17:52:39 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9AHqbkM027736
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 10 Oct 2012 17:52:38 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9AHqbXj016237; Wed, 10 Oct 2012 12:52:37 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 10 Oct 2012 10:52:37 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 992114031E; Wed, 10 Oct 2012 13:40:50 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Date: Wed, 10 Oct 2012 13:40:46 -0400
Message-Id: <1349890849-17471-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Subject: [Xen-devel] [PATCH v1] Various bug-fixes for v3.6.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hey,

Three patches that were discovered with v3.6. The first one:

 [PATCH 1/3] xen/pv-on-hvm kexec: add quirk for Xen 3.4 and shutdown
should have been found earlier, but it seems there is only a small selection
of provides run Xen 3.4 and without the 23839:42a45baf037d in xen-unstable.hg fix.
It is easy to reproduce with OVM 2.2 product.

The other two are a bit embarrassing. We had a similar issue with rdmsr_safe
pvops call in v3.5 where it was not implemented for Xen PV (but rdmsr was).
The fix was to make rdmsr_safe a macro around rdmsr and a lookout for other
calls that were not implemented. Well, v3.6 has gone by and now I find three other
culprits:
 [PATCH 2/3] xen/bootup: allow {read|write}_cr8 pvops call.
 [PATCH 3/3] xen/bootup: allow read_tscp call for Xen PV guests.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 17:53:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 17:53:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TM0Sd-0004L2-PC; Wed, 10 Oct 2012 17:52:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TM0Sc-0004KX-69
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 17:52:46 +0000
Received: from [85.158.143.99:45658] by server-2.bemta-4.messagelabs.com id
	3A/43-25171-DE5B5705; Wed, 10 Oct 2012 17:52:45 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1349891563!23845760!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgwNDY4OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21698 invoked from network); 10 Oct 2012 17:52:44 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Oct 2012 17:52:44 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9AHqdxi017020
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 10 Oct 2012 17:52:40 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9AHqcZA010321
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 10 Oct 2012 17:52:39 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9AHqbr0026285; Wed, 10 Oct 2012 12:52:37 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 10 Oct 2012 10:52:37 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id A118E402BD; Wed, 10 Oct 2012 13:40:50 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Date: Wed, 10 Oct 2012 13:40:47 -0400
Message-Id: <1349890849-17471-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1349890849-17471-1-git-send-email-konrad.wilk@oracle.com>
References: <1349890849-17471-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Olaf Hering , stable@vger.kernel.org,
	Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 1/3] xen/pv-on-hvm kexec: add quirk for Xen 3.4
	and shutdown watches.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The commit 254d1a3f02ebc10ccc6e4903394d8d3f484f715e, titled
"xen/pv-on-hvm kexec: shutdown watches from old kernel" assumes that the
XenBus backend can deal with reading of values from:
 "control/platform-feature-xs_reset_watches":

    ... a patch for xenstored is required so that it
    accepts the XS_RESET_WATCHES request from a client (see changeset
    23839:42a45baf037d in xen-unstable.hg). Without the patch for xenstored
    the registration of watches will fail and some features of a PVonHVM
    guest are not available. The guest is still able to boot, but repeated
    kexec boots will fail."

Sadly this is not true when using a Xen 3.4 hypervisor and booting a PVHVM
guest. We end up hanging at:

  err = xenbus_scanf(XBT_NIL, "control",
                        "platform-feature-xs_reset_watches", "%d", &supported);

This can easily be seen with guests hanging at xenbus_init:

NX (Execute Disable) protection: active
SMBIOS 2.4 present.
DMI: Xen HVM domU, BIOS 3.4.0 05/13/2011
Hypervisor detected: Xen HVM
Xen version 3.4.
Xen Platform PCI: I/O protocol version 1
... snip ..
calling  xenbus_init+0x0/0x27e @ 1

Reverting the commit or using the attached patch fixes the issue. This fix
checks whether the hypervisor is older than 4.0 and if so does not try to
perform the read.

Fixes-Oracle-Bug: 14708233
CC: stable@vger.kernel.org
CC: Olaf Hering 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 drivers/xen/xenbus/xenbus_xs.c |   15 +++++++++++++++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
index bce15cf..91f513b 100644
--- a/drivers/xen/xenbus/xenbus_xs.c
+++ b/drivers/xen/xenbus/xenbus_xs.c
@@ -47,6 +47,7 @@
 #include 
 #include 
 #include "xenbus_comms.h"
+#include 
 
 struct xs_stored_msg {
 	struct list_head list;
@@ -617,7 +618,18 @@ static struct xenbus_watch *find_watch(const char *token)
 
 	return NULL;
 }
+static bool xen_strict_xenbus_quirk()
+{
+	uint32_t eax, ebx, ecx, edx, base;
+
+	base = xen_cpuid_base();
+	cpuid(base + 1, &eax, &ebx, &ecx, &edx);
+
+	if ((eax >> 16) < 4)
+		return true;
+	return false;
 
+}
 static void xs_reset_watches(void)
 {
 	int err, supported = 0;
@@ -625,6 +637,9 @@ static void xs_reset_watches(void)
 	if (!xen_hvm_domain())
 		return;
 
+	if (xen_strict_xenbus_quirk())
+		return;
+
 	err = xenbus_scanf(XBT_NIL, "control",
 			"platform-feature-xs_reset_watches", "%d", &supported);
 	if (err != 1 || !supported)
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 17:53:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 17:53:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TM0Sc-0004KY-7j; Wed, 10 Oct 2012 17:52:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TM0Sa-0004KE-B7
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 17:52:44 +0000
Received: from [85.158.137.99:65291] by server-14.bemta-3.messagelabs.com id
	67/7A-17276-BE5B5705; Wed, 10 Oct 2012 17:52:43 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1349891561!19869321!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgwNDY4OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14737 invoked from network); 10 Oct 2012 17:52:42 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Oct 2012 17:52:42 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9AHqcZ2017018
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 10 Oct 2012 17:52:39 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9AHqc0x008238
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 10 Oct 2012 17:52:38 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9AHqcN7016242; Wed, 10 Oct 2012 12:52:38 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 10 Oct 2012 10:52:37 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id AD0D140376; Wed, 10 Oct 2012 13:40:50 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Date: Wed, 10 Oct 2012 13:40:49 -0400
Message-Id: <1349890849-17471-4-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1349890849-17471-1-git-send-email-konrad.wilk@oracle.com>
References: <1349890849-17471-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 3/3] xen/bootup: allow read_tscp call for Xen PV
	guests.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The hypervisor will trap it. However without this patch,
we would crash as the .read_tscp is set to NULL. This patch
fixes it and sets it to the native_read_tscp call.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/xen/enlighten.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index e1e4636..c1461de 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1175,6 +1175,8 @@ static const struct pv_cpu_ops xen_cpu_ops __initconst = {
 	.read_tsc = native_read_tsc,
 	.read_pmc = native_read_pmc,
 
+	.read_tscp = native_read_tscp,
+
 	.iret = xen_iret,
 	.irq_enable_sysexit = xen_sysexit,
 #ifdef CONFIG_X86_64
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 17:53:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 17:53:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TM0Sa-0004KF-Ei; Wed, 10 Oct 2012 17:52:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TM0SZ-0004K4-6l
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 17:52:43 +0000
Received: from [85.158.137.99:12284] by server-5.bemta-3.messagelabs.com id
	97/5C-12440-AE5B5705; Wed, 10 Oct 2012 17:52:42 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1349891560!21063431!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzk0NzQ0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2985 invoked from network); 10 Oct 2012 17:52:41 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-16.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Oct 2012 17:52:41 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9AHqcbv012094
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 10 Oct 2012 17:52:39 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9AHqcK1009242
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 10 Oct 2012 17:52:38 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9AHqbao009948; Wed, 10 Oct 2012 12:52:37 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 10 Oct 2012 10:52:37 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id A5E4240366; Wed, 10 Oct 2012 13:40:50 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Date: Wed, 10 Oct 2012 13:40:48 -0400
Message-Id: <1349890849-17471-3-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1349890849-17471-1-git-send-email-konrad.wilk@oracle.com>
References: <1349890849-17471-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 2/3] xen/bootup: allow {read|write}_cr8 pvops
	call.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We actually do not do anything about it. Just return a default
value of zero and if the kernel tries to write anything but 0
we BUG_ON.

This fixes the case when an user tries to suspend the machine
and it blows up in save_processor_state b/c 'read_cr8' is set
to NULL and we get:

kernel BUG at /home/konrad/ssd/linux/arch/x86/include/asm/paravirt.h:100!
invalid opcode: 0000 [#1] SMP
Pid: 2687, comm: init.late Tainted: G           O 3.6.0upstream-00002-gac264ac-dirty #4 Bochs Bochs
RIP: e030:[]  [] save_processor_state+0x212/0x270

.. snip..
Call Trace:
 [] do_suspend_lowlevel+0xf/0xac
 [] ? x86_acpi_suspend_lowlevel+0x10c/0x150
 [] acpi_suspend_enter+0x57/0xd5

Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/xen/enlighten.c |   16 +++++++++++++++-
 1 files changed, 15 insertions(+), 1 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 1fbe75a..e1e4636 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -984,7 +984,16 @@ static void xen_write_cr4(unsigned long cr4)
 
 	native_write_cr4(cr4);
 }
-
+#ifdef CONFIG_X86_64
+static inline unsigned long xen_read_cr8(void)
+{
+	return 0;
+}
+static inline void xen_write_cr8(unsigned long val)
+{
+	BUG_ON(val);
+}
+#endif
 static int xen_write_msr_safe(unsigned int msr, unsigned low, unsigned high)
 {
 	int ret;
@@ -1153,6 +1162,11 @@ static const struct pv_cpu_ops xen_cpu_ops __initconst = {
 	.read_cr4_safe = native_read_cr4_safe,
 	.write_cr4 = xen_write_cr4,
 
+#ifdef CONFIG_X86_64
+	.read_cr8 = xen_read_cr8,
+	.write_cr8 = xen_write_cr8,
+#endif
+
 	.wbinvd = native_wbinvd,
 
 	.read_msr = native_read_msr_safe,
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 18:10:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 18:10:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TM0jP-00050a-EF; Wed, 10 Oct 2012 18:10:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TM0jN-00050V-Qm
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 18:10:06 +0000
Received: from [85.158.139.211:26177] by server-11.bemta-5.messagelabs.com id
	D0/82-15507-DF9B5705; Wed, 10 Oct 2012 18:10:05 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-206.messagelabs.com!1349892603!20819484!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0Mjc1MTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0Mjc1MTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 520 invoked from network); 10 Oct 2012 18:10:03 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Oct 2012 18:10:03 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0Kfg==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-004.pools.arcor-ip.net [88.65.70.4])
	by smtp.strato.de (jorabe mo15) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id U05896o9AH8VA8 ;
	Wed, 10 Oct 2012 20:09:57 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id B4AA318642; Wed, 10 Oct 2012 20:09:56 +0200 (CEST)
Date: Wed, 10 Oct 2012 20:09:56 +0200
From: Olaf Hering 
To: Konrad Rzeszutek Wilk 
Message-ID: <20121010180956.GA2130@aepfle.de>
References: <1349890849-17471-1-git-send-email-konrad.wilk@oracle.com>
	<1349890849-17471-2-git-send-email-konrad.wilk@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1349890849-17471-2-git-send-email-konrad.wilk@oracle.com>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 1/3] xen/pv-on-hvm kexec: add quirk for Xen
 3.4 and shutdown watches.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 10, Konrad Rzeszutek Wilk wrote:

> The commit 254d1a3f02ebc10ccc6e4903394d8d3f484f715e, titled
> "xen/pv-on-hvm kexec: shutdown watches from old kernel" assumes that the
> XenBus backend can deal with reading of values from:
>  "control/platform-feature-xs_reset_watches":
> 
>     ... a patch for xenstored is required so that it
>     accepts the XS_RESET_WATCHES request from a client (see changeset
>     23839:42a45baf037d in xen-unstable.hg). Without the patch for xenstored
>     the registration of watches will fail and some features of a PVonHVM
>     guest are not available. The guest is still able to boot, but repeated
>     kexec boots will fail."
> 
> Sadly this is not true when using a Xen 3.4 hypervisor and booting a PVHVM
> guest. We end up hanging at:

This is sad.
So far I have not seen reports like that with a sles11sp1 or sles11sp2
guest. Thats either because noone uses Xen 3.4+sles11 (or recent
openSuSE) HVM guests, or because it happens to work with that
combination.

If the patch solves the issue:

Acked-by: Olaf Hering 

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 18:10:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 18:10:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TM0jP-00050a-EF; Wed, 10 Oct 2012 18:10:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TM0jN-00050V-Qm
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 18:10:06 +0000
Received: from [85.158.139.211:26177] by server-11.bemta-5.messagelabs.com id
	D0/82-15507-DF9B5705; Wed, 10 Oct 2012 18:10:05 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-206.messagelabs.com!1349892603!20819484!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0Mjc1MTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0Mjc1MTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 520 invoked from network); 10 Oct 2012 18:10:03 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Oct 2012 18:10:03 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0Kfg==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-004.pools.arcor-ip.net [88.65.70.4])
	by smtp.strato.de (jorabe mo15) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id U05896o9AH8VA8 ;
	Wed, 10 Oct 2012 20:09:57 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id B4AA318642; Wed, 10 Oct 2012 20:09:56 +0200 (CEST)
Date: Wed, 10 Oct 2012 20:09:56 +0200
From: Olaf Hering 
To: Konrad Rzeszutek Wilk 
Message-ID: <20121010180956.GA2130@aepfle.de>
References: <1349890849-17471-1-git-send-email-konrad.wilk@oracle.com>
	<1349890849-17471-2-git-send-email-konrad.wilk@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1349890849-17471-2-git-send-email-konrad.wilk@oracle.com>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 1/3] xen/pv-on-hvm kexec: add quirk for Xen
 3.4 and shutdown watches.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 10, Konrad Rzeszutek Wilk wrote:

> The commit 254d1a3f02ebc10ccc6e4903394d8d3f484f715e, titled
> "xen/pv-on-hvm kexec: shutdown watches from old kernel" assumes that the
> XenBus backend can deal with reading of values from:
>  "control/platform-feature-xs_reset_watches":
> 
>     ... a patch for xenstored is required so that it
>     accepts the XS_RESET_WATCHES request from a client (see changeset
>     23839:42a45baf037d in xen-unstable.hg). Without the patch for xenstored
>     the registration of watches will fail and some features of a PVonHVM
>     guest are not available. The guest is still able to boot, but repeated
>     kexec boots will fail."
> 
> Sadly this is not true when using a Xen 3.4 hypervisor and booting a PVHVM
> guest. We end up hanging at:

This is sad.
So far I have not seen reports like that with a sles11sp1 or sles11sp2
guest. Thats either because noone uses Xen 3.4+sles11 (or recent
openSuSE) HVM guests, or because it happens to work with that
combination.

If the patch solves the issue:

Acked-by: Olaf Hering 

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 19:03:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 19:03:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TM1YR-0005O9-2U; Wed, 10 Oct 2012 19:02:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TM1YP-0005O1-Fy
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 19:02:49 +0000
Received: from [85.158.139.211:62819] by server-6.bemta-5.messagelabs.com id
	00/F2-08519-856C5705; Wed, 10 Oct 2012 19:02:48 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1349895766!21377859!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2912 invoked from network); 10 Oct 2012 19:02:48 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 19:02:48 -0000
Received: by mail-qa0-f45.google.com with SMTP id s11so5275004qaa.11
	for ; Wed, 10 Oct 2012 12:02:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=Xbx7iRgIHDUzzm5Jr6Huyz+wUEuTAwkEsWETj5sKu1s=;
	b=H5pTK6jRpV6bKu6IFN9iilkyDFpz1nuGkQrZf9HrmwdwjpcpIPgzjfkWZg0Fps3aZ4
	GZoHhSXQ6Igi+2duZY8O6wYZaXs1eCA4LpmndmtW0OjLA5dT6Ctw3NrPbLdHspY1hmcy
	ZUXCDyZKbLAONbtf/w+XJ6T55eEFai65utS7hEw828ePE5e5j1moP9ym5AjW/Eop8osa
	nJPQk2vZ1rRcmX2Zynlhh2gY5WXFOYla4llEJMnfRUEKiugAVwHacp/EjdOHSyOl4EW8
	mRzqlZ9JMLKRR2E/NmpsLVR94pExAQ3QyN9AfLVWv7zy7EAOoh3EyzkxCdFB+bB6hUb/
	368w==
Received: by 10.229.38.17 with SMTP id z17mr10683320qcd.30.1349895766408;
	Wed, 10 Oct 2012 12:02:46 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id fy1sm2334370qab.10.2012.10.10.12.02.45
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 10 Oct 2012 12:02:45 -0700 (PDT)
Date: Wed, 10 Oct 2012 14:50:57 -0400
From: Konrad Rzeszutek Wilk 
To: Sander Eikelenboom 
Message-ID: <20121010185056.GA5448@phenom.dumpdata.com>
References: <76252326.20121010175818@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <76252326.20121010175818@eikelenboom.it>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel 
Subject: Re: [Xen-devel] Kernel 3.7.0-pre-rc1: mcelog:4344 map pfn expected
 mapping type write-back for [mem 0x0009f000-0x000a0fff], got uncached-minus,
 WARNING: at arch/x86/mm/pat.c:774 untrack_pfn+0x8c/0xc0()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 10, 2012 at 05:58:18PM +0200, Sander Eikelenboom wrote:
> Hi Konrad,
> 
> On boot with a 3.7.0-pre-rc1 (latest commit is 42859eea96ba6beabfb0369a1eeffa3c7d2bd9cb) i always get:
> 
> 
> [   75.718807] mcelog:4344 map pfn expected mapping type write-back for [mem 0x0009f000-0x000a0fff], got uncached-minus
> [   75.725282] ------------[ cut here ]------------
> [   75.731316] WARNING: at arch/x86/mm/pat.c:774 untrack_pfn+0x8c/0xc0()
> [   75.737465] Hardware name: MS-7640
> [   75.743678] Modules linked in:
> [   75.749528] Pid: 4344, comm: mcelog Not tainted 3.6.0pre-rc1-20121010 #1
> [   75.755581] Call Trace:
> [   75.761303]  [] warn_slowpath_common+0x7a/0xb0
> [   75.767036]  [] warn_slowpath_null+0x15/0x20
> [   75.772804]  [] untrack_pfn+0x8c/0xc0
> [   75.778391]  [] unmap_single_vma+0x86b/0x8e0
> [   75.784002]  [] ? release_pages+0x196/0x1f0
> [   75.789484]  [] ? _raw_spin_unlock_irqrestore+0x75/0xa0
> [   75.794970]  [] unmap_vmas+0x4c/0xa0
> [   75.800375]  [] exit_mmap+0x9a/0x180
> [   75.805748]  [] mmput+0x52/0xd0
> [   75.811046]  [] dup_mm+0x3c7/0x510
> [   75.816380]  [] copy_process+0xad5/0x14b0
> [   75.821777]  [] do_fork+0x53/0x360
> [   75.827114]  [] ? lock_release+0x117/0x250
> [   75.832380]  [] ? _raw_spin_unlock+0x30/0x60
> [   75.837977]  [] ? sysret_check+0x22/0x5d
> [   75.843337]  [] sys_clone+0x23/0x30
> [   75.848567]  [] stub_clone+0x13/0x20
> [   75.853718]  [] ? system_call_fastpath+0x16/0x1b
> [   75.858913] ---[ end trace df00fd3532db355c ]---
> 
> 
> xl dmesg and dmesg attached.

Heh. Not seeing them.

But more importantly, do you have CONFIG_XEN_MCE.. something enabled?

> 
> --
> Sander
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 19:03:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 19:03:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TM1YR-0005O9-2U; Wed, 10 Oct 2012 19:02:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TM1YP-0005O1-Fy
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 19:02:49 +0000
Received: from [85.158.139.211:62819] by server-6.bemta-5.messagelabs.com id
	00/F2-08519-856C5705; Wed, 10 Oct 2012 19:02:48 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1349895766!21377859!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2912 invoked from network); 10 Oct 2012 19:02:48 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 19:02:48 -0000
Received: by mail-qa0-f45.google.com with SMTP id s11so5275004qaa.11
	for ; Wed, 10 Oct 2012 12:02:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=Xbx7iRgIHDUzzm5Jr6Huyz+wUEuTAwkEsWETj5sKu1s=;
	b=H5pTK6jRpV6bKu6IFN9iilkyDFpz1nuGkQrZf9HrmwdwjpcpIPgzjfkWZg0Fps3aZ4
	GZoHhSXQ6Igi+2duZY8O6wYZaXs1eCA4LpmndmtW0OjLA5dT6Ctw3NrPbLdHspY1hmcy
	ZUXCDyZKbLAONbtf/w+XJ6T55eEFai65utS7hEw828ePE5e5j1moP9ym5AjW/Eop8osa
	nJPQk2vZ1rRcmX2Zynlhh2gY5WXFOYla4llEJMnfRUEKiugAVwHacp/EjdOHSyOl4EW8
	mRzqlZ9JMLKRR2E/NmpsLVR94pExAQ3QyN9AfLVWv7zy7EAOoh3EyzkxCdFB+bB6hUb/
	368w==
Received: by 10.229.38.17 with SMTP id z17mr10683320qcd.30.1349895766408;
	Wed, 10 Oct 2012 12:02:46 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id fy1sm2334370qab.10.2012.10.10.12.02.45
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 10 Oct 2012 12:02:45 -0700 (PDT)
Date: Wed, 10 Oct 2012 14:50:57 -0400
From: Konrad Rzeszutek Wilk 
To: Sander Eikelenboom 
Message-ID: <20121010185056.GA5448@phenom.dumpdata.com>
References: <76252326.20121010175818@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <76252326.20121010175818@eikelenboom.it>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel 
Subject: Re: [Xen-devel] Kernel 3.7.0-pre-rc1: mcelog:4344 map pfn expected
 mapping type write-back for [mem 0x0009f000-0x000a0fff], got uncached-minus,
 WARNING: at arch/x86/mm/pat.c:774 untrack_pfn+0x8c/0xc0()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 10, 2012 at 05:58:18PM +0200, Sander Eikelenboom wrote:
> Hi Konrad,
> 
> On boot with a 3.7.0-pre-rc1 (latest commit is 42859eea96ba6beabfb0369a1eeffa3c7d2bd9cb) i always get:
> 
> 
> [   75.718807] mcelog:4344 map pfn expected mapping type write-back for [mem 0x0009f000-0x000a0fff], got uncached-minus
> [   75.725282] ------------[ cut here ]------------
> [   75.731316] WARNING: at arch/x86/mm/pat.c:774 untrack_pfn+0x8c/0xc0()
> [   75.737465] Hardware name: MS-7640
> [   75.743678] Modules linked in:
> [   75.749528] Pid: 4344, comm: mcelog Not tainted 3.6.0pre-rc1-20121010 #1
> [   75.755581] Call Trace:
> [   75.761303]  [] warn_slowpath_common+0x7a/0xb0
> [   75.767036]  [] warn_slowpath_null+0x15/0x20
> [   75.772804]  [] untrack_pfn+0x8c/0xc0
> [   75.778391]  [] unmap_single_vma+0x86b/0x8e0
> [   75.784002]  [] ? release_pages+0x196/0x1f0
> [   75.789484]  [] ? _raw_spin_unlock_irqrestore+0x75/0xa0
> [   75.794970]  [] unmap_vmas+0x4c/0xa0
> [   75.800375]  [] exit_mmap+0x9a/0x180
> [   75.805748]  [] mmput+0x52/0xd0
> [   75.811046]  [] dup_mm+0x3c7/0x510
> [   75.816380]  [] copy_process+0xad5/0x14b0
> [   75.821777]  [] do_fork+0x53/0x360
> [   75.827114]  [] ? lock_release+0x117/0x250
> [   75.832380]  [] ? _raw_spin_unlock+0x30/0x60
> [   75.837977]  [] ? sysret_check+0x22/0x5d
> [   75.843337]  [] sys_clone+0x23/0x30
> [   75.848567]  [] stub_clone+0x13/0x20
> [   75.853718]  [] ? system_call_fastpath+0x16/0x1b
> [   75.858913] ---[ end trace df00fd3532db355c ]---
> 
> 
> xl dmesg and dmesg attached.

Heh. Not seeing them.

But more importantly, do you have CONFIG_XEN_MCE.. something enabled?

> 
> --
> Sander
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 19:05:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 19:05:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TM1b3-0005VR-Nu; Wed, 10 Oct 2012 19:05:33 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TM1b2-0005VJ-88
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 19:05:32 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1349895923!12230482!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgwNDY4OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8023 invoked from network); 10 Oct 2012 19:05:25 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Oct 2012 19:05:25 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9AJ5BIr019096
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 10 Oct 2012 19:05:12 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9AJ5BUp011052
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 10 Oct 2012 19:05:11 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9AJ5BvN031470; Wed, 10 Oct 2012 14:05:11 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 10 Oct 2012 12:05:11 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D4CA74031E; Wed, 10 Oct 2012 14:53:23 -0400 (EDT)
Date: Wed, 10 Oct 2012 14:53:23 -0400
From: Konrad Rzeszutek Wilk 
To: Ian Campbell 
Message-ID: <20121010185323.GA7988@phenom.dumpdata.com>
References: <1349876922-11907-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1349876922-11907-1-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: netdev@vger.kernel.org, Sander Eikelenboom ,
	Konrad Rzeszutek Wilk ,
	Eric Dumazet , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH V2] xen: netback: handle compound page
 fragments on transmit.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 10, 2012 at 02:48:42PM +0100, Ian Campbell wrote:
> An SKB paged fragment can consist of a compound page with order > 0.
> However the netchannel protocol deals only in PAGE_SIZE frames.
> 
> Handle this in netbk_gop_frag_copy and xen_netbk_count_skb_slots by
> iterating over the frames which make up the page.
> 
> Signed-off-by: Ian Campbell 
> Cc: Eric Dumazet 
> Cc: Konrad Rzeszutek Wilk 

Tested-by: Konrad Rzeszutek Wilk 

> Cc: Sander Eikelenboom 
> ---
> v2: Only move to next frame if there is data remaining.
> ---
>  drivers/net/xen-netback/netback.c |   40 ++++++++++++++++++++++++++++++++----
>  1 files changed, 35 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index 4ebfcf3..f2d6b78 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -335,21 +335,35 @@ unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb)
>  
>  	for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
>  		unsigned long size = skb_frag_size(&skb_shinfo(skb)->frags[i]);
> +		unsigned long offset = skb_shinfo(skb)->frags[i].page_offset;
>  		unsigned long bytes;
> +
> +		offset &= ~PAGE_MASK;
> +
>  		while (size > 0) {
> +			BUG_ON(offset >= PAGE_SIZE);
>  			BUG_ON(copy_off > MAX_BUFFER_OFFSET);
>  
> -			if (start_new_rx_buffer(copy_off, size, 0)) {
> +			bytes = PAGE_SIZE - offset;
> +
> +			if (bytes > size)
> +				bytes = size;
> +
> +			if (start_new_rx_buffer(copy_off, bytes, 0)) {
>  				count++;
>  				copy_off = 0;
>  			}
>  
> -			bytes = size;
>  			if (copy_off + bytes > MAX_BUFFER_OFFSET)
>  				bytes = MAX_BUFFER_OFFSET - copy_off;
>  
>  			copy_off += bytes;
> +
> +			offset += bytes;
>  			size -= bytes;
> +
> +			if (offset == PAGE_SIZE)
> +				offset = 0;
>  		}
>  	}
>  	return count;
> @@ -403,14 +417,24 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
>  	unsigned long bytes;
>  
>  	/* Data must not cross a page boundary. */
> -	BUG_ON(size + offset > PAGE_SIZE);
> +	BUG_ON(size + offset > PAGE_SIZE<  
>  	meta = npo->meta + npo->meta_prod - 1;
>  
> +	/* Skip unused frames from start of page */
> +	page += offset >> PAGE_SHIFT;
> +	offset &= ~PAGE_MASK;
> +
>  	while (size > 0) {
> +		BUG_ON(offset >= PAGE_SIZE);
>  		BUG_ON(npo->copy_off > MAX_BUFFER_OFFSET);
>  
> -		if (start_new_rx_buffer(npo->copy_off, size, *head)) {
> +		bytes = PAGE_SIZE - offset;
> +
> +		if (bytes > size)
> +			bytes = size;
> +
> +		if (start_new_rx_buffer(npo->copy_off, bytes, *head)) {
>  			/*
>  			 * Netfront requires there to be some data in the head
>  			 * buffer.
> @@ -420,7 +444,6 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
>  			meta = get_next_rx_buffer(vif, npo);
>  		}
>  
> -		bytes = size;
>  		if (npo->copy_off + bytes > MAX_BUFFER_OFFSET)
>  			bytes = MAX_BUFFER_OFFSET - npo->copy_off;
>  
> @@ -453,6 +476,13 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
>  		offset += bytes;
>  		size -= bytes;
>  
> +		/* Next frame */
> +		if (offset == PAGE_SIZE && size) {
> +			BUG_ON(!PageCompound(page));
> +			page++;
> +			offset = 0;
> +		}
> +
>  		/* Leave a gap for the GSO descriptor. */
>  		if (*head && skb_shinfo(skb)->gso_size && !vif->gso_prefix)
>  			vif->rx.req_cons++;
> -- 
> 1.7.2.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 19:05:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 19:05:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TM1b3-0005VR-Nu; Wed, 10 Oct 2012 19:05:33 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TM1b2-0005VJ-88
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 19:05:32 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1349895923!12230482!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgwNDY4OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8023 invoked from network); 10 Oct 2012 19:05:25 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Oct 2012 19:05:25 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9AJ5BIr019096
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 10 Oct 2012 19:05:12 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9AJ5BUp011052
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 10 Oct 2012 19:05:11 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9AJ5BvN031470; Wed, 10 Oct 2012 14:05:11 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 10 Oct 2012 12:05:11 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D4CA74031E; Wed, 10 Oct 2012 14:53:23 -0400 (EDT)
Date: Wed, 10 Oct 2012 14:53:23 -0400
From: Konrad Rzeszutek Wilk 
To: Ian Campbell 
Message-ID: <20121010185323.GA7988@phenom.dumpdata.com>
References: <1349876922-11907-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1349876922-11907-1-git-send-email-ian.campbell@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: netdev@vger.kernel.org, Sander Eikelenboom ,
	Konrad Rzeszutek Wilk ,
	Eric Dumazet , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH V2] xen: netback: handle compound page
 fragments on transmit.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 10, 2012 at 02:48:42PM +0100, Ian Campbell wrote:
> An SKB paged fragment can consist of a compound page with order > 0.
> However the netchannel protocol deals only in PAGE_SIZE frames.
> 
> Handle this in netbk_gop_frag_copy and xen_netbk_count_skb_slots by
> iterating over the frames which make up the page.
> 
> Signed-off-by: Ian Campbell 
> Cc: Eric Dumazet 
> Cc: Konrad Rzeszutek Wilk 

Tested-by: Konrad Rzeszutek Wilk 

> Cc: Sander Eikelenboom 
> ---
> v2: Only move to next frame if there is data remaining.
> ---
>  drivers/net/xen-netback/netback.c |   40 ++++++++++++++++++++++++++++++++----
>  1 files changed, 35 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index 4ebfcf3..f2d6b78 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -335,21 +335,35 @@ unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb)
>  
>  	for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
>  		unsigned long size = skb_frag_size(&skb_shinfo(skb)->frags[i]);
> +		unsigned long offset = skb_shinfo(skb)->frags[i].page_offset;
>  		unsigned long bytes;
> +
> +		offset &= ~PAGE_MASK;
> +
>  		while (size > 0) {
> +			BUG_ON(offset >= PAGE_SIZE);
>  			BUG_ON(copy_off > MAX_BUFFER_OFFSET);
>  
> -			if (start_new_rx_buffer(copy_off, size, 0)) {
> +			bytes = PAGE_SIZE - offset;
> +
> +			if (bytes > size)
> +				bytes = size;
> +
> +			if (start_new_rx_buffer(copy_off, bytes, 0)) {
>  				count++;
>  				copy_off = 0;
>  			}
>  
> -			bytes = size;
>  			if (copy_off + bytes > MAX_BUFFER_OFFSET)
>  				bytes = MAX_BUFFER_OFFSET - copy_off;
>  
>  			copy_off += bytes;
> +
> +			offset += bytes;
>  			size -= bytes;
> +
> +			if (offset == PAGE_SIZE)
> +				offset = 0;
>  		}
>  	}
>  	return count;
> @@ -403,14 +417,24 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
>  	unsigned long bytes;
>  
>  	/* Data must not cross a page boundary. */
> -	BUG_ON(size + offset > PAGE_SIZE);
> +	BUG_ON(size + offset > PAGE_SIZE<  
>  	meta = npo->meta + npo->meta_prod - 1;
>  
> +	/* Skip unused frames from start of page */
> +	page += offset >> PAGE_SHIFT;
> +	offset &= ~PAGE_MASK;
> +
>  	while (size > 0) {
> +		BUG_ON(offset >= PAGE_SIZE);
>  		BUG_ON(npo->copy_off > MAX_BUFFER_OFFSET);
>  
> -		if (start_new_rx_buffer(npo->copy_off, size, *head)) {
> +		bytes = PAGE_SIZE - offset;
> +
> +		if (bytes > size)
> +			bytes = size;
> +
> +		if (start_new_rx_buffer(npo->copy_off, bytes, *head)) {
>  			/*
>  			 * Netfront requires there to be some data in the head
>  			 * buffer.
> @@ -420,7 +444,6 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
>  			meta = get_next_rx_buffer(vif, npo);
>  		}
>  
> -		bytes = size;
>  		if (npo->copy_off + bytes > MAX_BUFFER_OFFSET)
>  			bytes = MAX_BUFFER_OFFSET - npo->copy_off;
>  
> @@ -453,6 +476,13 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
>  		offset += bytes;
>  		size -= bytes;
>  
> +		/* Next frame */
> +		if (offset == PAGE_SIZE && size) {
> +			BUG_ON(!PageCompound(page));
> +			page++;
> +			offset = 0;
> +		}
> +
>  		/* Leave a gap for the GSO descriptor. */
>  		if (*head && skb_shinfo(skb)->gso_size && !vif->gso_prefix)
>  			vif->rx.req_cons++;
> -- 
> 1.7.2.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 19:08:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 19:08:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TM1dU-0005dE-At; Wed, 10 Oct 2012 19:08:04 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TM1dT-0005cz-57
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 19:08:03 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-5.tower-27.messagelabs.com!1349896076!8105537!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22791 invoked from network); 10 Oct 2012 19:07:57 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-5.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Oct 2012 19:07:57 -0000
Received: from 50-66-ftth.onsneteindhoven.nl ([88.159.66.50]:59997
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TM1ei-0000y1-FV; Wed, 10 Oct 2012 21:09:20 +0200
Date: Wed, 10 Oct 2012 21:07:51 +0200
From: Sander Eikelenboom 
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1831776290.20121010210751@eikelenboom.it>
To: Konrad Rzeszutek Wilk 
In-Reply-To: <20121010185056.GA5448@phenom.dumpdata.com>
References: <76252326.20121010175818@eikelenboom.it>
	<20121010185056.GA5448@phenom.dumpdata.com>
MIME-Version: 1.0
Cc: xen-devel 
Subject: Re: [Xen-devel] Kernel 3.7.0-pre-rc1: mcelog:4344 map pfn expected
	mapping type write-back for [mem 0x0009f000-0x000a0fff],
	got uncached-minus,
	WARNING: at arch/x86/mm/pat.c:774 untrack_pfn+0x8c/0xc0()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Wednesday, October 10, 2012, 8:50:57 PM, you wrote:

> On Wed, Oct 10, 2012 at 05:58:18PM +0200, Sander Eikelenboom wrote:
>> Hi Konrad,
>> 
>> On boot with a 3.7.0-pre-rc1 (latest commit is 42859eea96ba6beabfb0369a1eeffa3c7d2bd9cb) i always get:
>> 
>> 
>> [   75.718807] mcelog:4344 map pfn expected mapping type write-back for [mem 0x0009f000-0x000a0fff], got uncached-minus
>> [   75.725282] ------------[ cut here ]------------
>> [   75.731316] WARNING: at arch/x86/mm/pat.c:774 untrack_pfn+0x8c/0xc0()
>> [   75.737465] Hardware name: MS-7640
>> [   75.743678] Modules linked in:
>> [   75.749528] Pid: 4344, comm: mcelog Not tainted 3.6.0pre-rc1-20121010 #1
>> [   75.755581] Call Trace:
>> [   75.761303]  [] warn_slowpath_common+0x7a/0xb0
>> [   75.767036]  [] warn_slowpath_null+0x15/0x20
>> [   75.772804]  [] untrack_pfn+0x8c/0xc0
>> [   75.778391]  [] unmap_single_vma+0x86b/0x8e0
>> [   75.784002]  [] ? release_pages+0x196/0x1f0
>> [   75.789484]  [] ? _raw_spin_unlock_irqrestore+0x75/0xa0
>> [   75.794970]  [] unmap_vmas+0x4c/0xa0
>> [   75.800375]  [] exit_mmap+0x9a/0x180
>> [   75.805748]  [] mmput+0x52/0xd0
>> [   75.811046]  [] dup_mm+0x3c7/0x510
>> [   75.816380]  [] copy_process+0xad5/0x14b0
>> [   75.821777]  [] do_fork+0x53/0x360
>> [   75.827114]  [] ? lock_release+0x117/0x250
>> [   75.832380]  [] ? _raw_spin_unlock+0x30/0x60
>> [   75.837977]  [] ? sysret_check+0x22/0x5d
>> [   75.843337]  [] sys_clone+0x23/0x30
>> [   75.848567]  [] stub_clone+0x13/0x20
>> [   75.853718]  [] ? system_call_fastpath+0x16/0x1b
>> [   75.858913] ---[ end trace df00fd3532db355c ]---
>> 
>> 
>> xl dmesg and dmesg attached.

> Heh. Not seeing them.

> But more importantly, do you have CONFIG_XEN_MCE.. something enabled?

# grep XEN_MCE .config
# CONFIG_XEN_MCE_LOG is not set

Nope

>> 
>> --
>> Sander
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 19:08:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 19:08:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TM1dU-0005dE-At; Wed, 10 Oct 2012 19:08:04 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TM1dT-0005cz-57
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 19:08:03 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-5.tower-27.messagelabs.com!1349896076!8105537!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22791 invoked from network); 10 Oct 2012 19:07:57 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-5.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Oct 2012 19:07:57 -0000
Received: from 50-66-ftth.onsneteindhoven.nl ([88.159.66.50]:59997
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TM1ei-0000y1-FV; Wed, 10 Oct 2012 21:09:20 +0200
Date: Wed, 10 Oct 2012 21:07:51 +0200
From: Sander Eikelenboom 
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1831776290.20121010210751@eikelenboom.it>
To: Konrad Rzeszutek Wilk 
In-Reply-To: <20121010185056.GA5448@phenom.dumpdata.com>
References: <76252326.20121010175818@eikelenboom.it>
	<20121010185056.GA5448@phenom.dumpdata.com>
MIME-Version: 1.0
Cc: xen-devel 
Subject: Re: [Xen-devel] Kernel 3.7.0-pre-rc1: mcelog:4344 map pfn expected
	mapping type write-back for [mem 0x0009f000-0x000a0fff],
	got uncached-minus,
	WARNING: at arch/x86/mm/pat.c:774 untrack_pfn+0x8c/0xc0()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Wednesday, October 10, 2012, 8:50:57 PM, you wrote:

> On Wed, Oct 10, 2012 at 05:58:18PM +0200, Sander Eikelenboom wrote:
>> Hi Konrad,
>> 
>> On boot with a 3.7.0-pre-rc1 (latest commit is 42859eea96ba6beabfb0369a1eeffa3c7d2bd9cb) i always get:
>> 
>> 
>> [   75.718807] mcelog:4344 map pfn expected mapping type write-back for [mem 0x0009f000-0x000a0fff], got uncached-minus
>> [   75.725282] ------------[ cut here ]------------
>> [   75.731316] WARNING: at arch/x86/mm/pat.c:774 untrack_pfn+0x8c/0xc0()
>> [   75.737465] Hardware name: MS-7640
>> [   75.743678] Modules linked in:
>> [   75.749528] Pid: 4344, comm: mcelog Not tainted 3.6.0pre-rc1-20121010 #1
>> [   75.755581] Call Trace:
>> [   75.761303]  [] warn_slowpath_common+0x7a/0xb0
>> [   75.767036]  [] warn_slowpath_null+0x15/0x20
>> [   75.772804]  [] untrack_pfn+0x8c/0xc0
>> [   75.778391]  [] unmap_single_vma+0x86b/0x8e0
>> [   75.784002]  [] ? release_pages+0x196/0x1f0
>> [   75.789484]  [] ? _raw_spin_unlock_irqrestore+0x75/0xa0
>> [   75.794970]  [] unmap_vmas+0x4c/0xa0
>> [   75.800375]  [] exit_mmap+0x9a/0x180
>> [   75.805748]  [] mmput+0x52/0xd0
>> [   75.811046]  [] dup_mm+0x3c7/0x510
>> [   75.816380]  [] copy_process+0xad5/0x14b0
>> [   75.821777]  [] do_fork+0x53/0x360
>> [   75.827114]  [] ? lock_release+0x117/0x250
>> [   75.832380]  [] ? _raw_spin_unlock+0x30/0x60
>> [   75.837977]  [] ? sysret_check+0x22/0x5d
>> [   75.843337]  [] sys_clone+0x23/0x30
>> [   75.848567]  [] stub_clone+0x13/0x20
>> [   75.853718]  [] ? system_call_fastpath+0x16/0x1b
>> [   75.858913] ---[ end trace df00fd3532db355c ]---
>> 
>> 
>> xl dmesg and dmesg attached.

> Heh. Not seeing them.

> But more importantly, do you have CONFIG_XEN_MCE.. something enabled?

# grep XEN_MCE .config
# CONFIG_XEN_MCE_LOG is not set

Nope

>> 
>> --
>> Sander
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 19:30:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 19:30:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TM1yN-0005ro-AG; Wed, 10 Oct 2012 19:29:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TM1yL-0005rj-QT
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 19:29:38 +0000
Received: from [85.158.137.99:29591] by server-15.bemta-3.messagelabs.com id
	45/D0-10261-0ACC5705; Wed, 10 Oct 2012 19:29:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1349897376!19877129!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM3MzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3377 invoked from network); 10 Oct 2012 19:29:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 19:29:36 -0000
X-IronPort-AV: E=Sophos;i="4.80,565,1344211200"; d="scan'208";a="15083536"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 19:29:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 10 Oct 2012 20:29:36 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TM1yJ-0007Ai-Oh;
	Wed, 10 Oct 2012 19:29:35 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TM1yJ-0008Sv-59;
	Wed, 10 Oct 2012 20:29:35 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Wed, 10 Oct 2012 20:29:35 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 13948: tolerable trouble:
	broken/fail/pass - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13948 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13948/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-pv            3 host-install(3)           broken pass in 13933
 test-amd64-i386-xl-credit2    5 xen-boot           fail in 13933 pass in 13948

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13915
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13915

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 linux                24e842ae6cb8179126246ebcbfc477b36a7b8719
baseline version:
 linux                b9a7985a8d9ca00d8ce977756fde1306c9ab1e41

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           broken  
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=linux-3.0
+ revision=24e842ae6cb8179126246ebcbfc477b36a7b8719
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push linux-3.0 24e842ae6cb8179126246ebcbfc477b36a7b8719
+ branch=linux-3.0
+ revision=24e842ae6cb8179126246ebcbfc477b36a7b8719
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=linux
+ xenbranch=xen-unstable
+ '[' xlinux = xlinux ']'
+ linuxbranch=linux-3.0
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.linux-3.0
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux-3.0
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree linux-3.0
+ case $1 in
+ : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
+ : linux-3.0.y
+ : linux-3.0.y
+ : git
+ : git
+ : git://xenbits.xen.org/linux-pvops.git
+ : xen@xenbits.xensource.com:git/linux-pvops.git
+ : tested/linux-3.0
+ : tested/linux-3.0
+ return 0
+ cd /export/home/osstest/repos/linux
+ git push xen@xenbits.xensource.com:git/linux-pvops.git 24e842ae6cb8179126246ebcbfc477b36a7b8719:tested/linux-3.0
Counting objects: 1   
Counting objects: 276, done.
Compressing objects:   2% (1/35)   
Compressing objects:   5% (2/35)   
Compressing objects:   8% (3/35)   
Compressing objects:  11% (4/35)   
Compressing objects:  14% (5/35)   
Compressing objects:  17% (6/35)   
Compressing objects:  20% (7/35)   
Compressing objects:  22% (8/35)   
Compressing objects:  25% (9/35)   
Compressing objects:  28% (10/35)   
Compressing objects:  31% (11/35)   
Compressing objects:  34% (12/35)   
Compressing objects:  37% (13/35)   
Compressing objects:  40% (14/35)   
Compressing objects:  42% (15/35)   
Compressing objects:  45% (16/35)   
Compressing objects:  48% (17/35)   
Compressing objects:  51% (18/35)   
Compressing objects:  54% (19/35)   
Compressing objects:  57% (20/35)   
Compressing objects:  60% (21/35)   
Compressing objects:  62% (22/35)   
Compressing objects:  65% (23/35)   
Compressing objects:  68% (24/35)   
Compressing objects:  71% (25/35)   
Compressing objects:  74% (26/35)   
Compressing objects:  77% (27/35)   
Compressing objects:  80% (28/35)   
Compressing objects:  82% (29/35)   
Compressing objects:  85% (30/35)   
Compressing objects:  88% (31/35)   
Compressing objects:  91% (32/35)   
Compressing objects:  94% (33/35)   
Compressing objects:  97% (34/35)   
Compressing objects: 100% (35/35)   
Compressing objects: 100% (35/35), done.
Writing objects:   0% (1/203)   
Writing objects:   1% (3/203)   
Writing objects:   2% (5/203)   
Writing objects:   3% (7/203)   
Writing objects:   4% (9/203)   
Writing objects:   5% (11/203)   
Writing objects:   6% (13/203)   
Writing objects:   7% (15/203)   
Writing objects:   8% (17/203)   
Writing objects:   9% (19/203)   
Writing objects:  10% (21/203)   
Writing objects:  11% (23/203)   
Writing objects:  12% (25/203)   
Writing objects:  13% (27/203)   
Writing objects:  14% (29/203)   
Writing objects:  15% (31/203)   
Writing objects:  16% (33/203)   
Writing objects:  17% (35/203)   
Writing objects:  18% (37/203)   
Writing objects:  19% (39/203)   
Writing objects:  20% (41/203)   
Writing objects:  21% (43/203)   
Writing objects:  22% (45/203)   
Writing objects:  23% (47/203)   
Writing objects:  24% (49/203)   
Writing objects:  25% (51/203)   
Writing objects:  26% (53/203)   
Writing objects:  27% (55/203)   
Writing objects:  28% (57/203)   
Writing objects:  29% (59/203)   
Writing objects:  30% (61/203)   
Writing objects:  31% (63/203)   
Writing objects:  32% (65/203)   
Writing objects:  33% (67/203)   
Writing objects:  34% (70/203)   
Writing objects:  35% (72/203)   
Writing objects:  36% (74/203)   
Writing objects:  37% (76/203)   
Writing objects:  38% (78/203)   
Writing objects:  39% (80/203)   
Writing objects:  40% (82/203)   
Writing objects:  41% (84/203)   
Writing objects:  42% (86/203)   
Writing objects:  43% (88/203)   
Writing objects:  44% (90/203)   
Writing objects:  45% (92/203)   
Writing objects:  46% (94/203)   
Writing objects:  47% (96/203)   
Writing objects:  48% (98/203)   
Writing objects:  49% (100/203)   
Writing objects:  50% (102/203)   
Writing objects:  51% (104/203)   
Writing objects:  52% (106/203)   
Writing objects:  53% (108/203)   
Writing objects:  54% (110/203)   
Writing objects:  55% (112/203)   
Writing objects:  56% (114/203)   
Writing objects:  57% (116/203)   
Writing objects:  58% (118/203)   
Writing objects:  59% (120/203)   
Writing objects:  60% (122/203)   
Writing objects:  61% (124/203)   
Writing objects:  62% (126/203)   
Writing objects:  63% (128/203)   
Writing objects:  64% (130/203)   
Writing objects:  65% (132/203)   
Writing objects:  66% (134/203)   
Writing objects:  67% (137/203)   
Writing objects:  68% (139/203)   
Writing objects:  69% (141/203)   
Writing objects:  70% (143/203)   
Writing objects:  71% (145/203)   
Writing objects:  72% (147/203)   
Writing objects:  73% (149/203)   
Writing objects:  74% (151/203)   
Writing objects:  75% (153/203)   
Writing objects:  76% (155/203)   
Writing objects:  77% (157/203)   
Writing objects:  78% (159/203)   
Writing objects:  79% (161/203)   
Writing objects:  80% (163/203)   
Writing objects:  81% (165/203)   
Writing objects:  82% (167/203)   
Writing objects:  83% (169/203)   
Writing objects:  84% (171/203)   
Writing objects:  85% (173/203)   
Writing objects:  86% (175/203)   
Writing objects:  87% (177/203)   
Writing objects:  88% (179/203)   
Writing objects:  89% (181/203)   
Writing objects:  90% (183/203)   
Writing objects:  91% (185/203)   
Writing objects:  92% (187/203)   
Writing objects:  93% (189/203)   
Writing objects:  94% (191/203)   
Writing objects:  95% (193/203)   
Writing objects:  96% (195/203)   
Writing objects:  97% (197/203)   
Writing objects:  98% (199/203)   
Writing objects:  99% (201/203)   
Writing objects: 100% (203/203)   
Writing objects: 100% (203/203), 33.55 KiB, done.
Total 203 (delta 168), reused 203 (delta 168)
To xen@xenbits.xensource.com:git/linux-pvops.git
   b9a7985..24e842a  24e842ae6cb8179126246ebcbfc477b36a7b8719 -> tested/linux-3.0
+ exit 0

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 19:30:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 19:30:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TM1yN-0005ro-AG; Wed, 10 Oct 2012 19:29:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TM1yL-0005rj-QT
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 19:29:38 +0000
Received: from [85.158.137.99:29591] by server-15.bemta-3.messagelabs.com id
	45/D0-10261-0ACC5705; Wed, 10 Oct 2012 19:29:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1349897376!19877129!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM3MzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3377 invoked from network); 10 Oct 2012 19:29:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 19:29:36 -0000
X-IronPort-AV: E=Sophos;i="4.80,565,1344211200"; d="scan'208";a="15083536"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 19:29:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 10 Oct 2012 20:29:36 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TM1yJ-0007Ai-Oh;
	Wed, 10 Oct 2012 19:29:35 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TM1yJ-0008Sv-59;
	Wed, 10 Oct 2012 20:29:35 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Wed, 10 Oct 2012 20:29:35 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 13948: tolerable trouble:
	broken/fail/pass - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13948 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13948/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-pv            3 host-install(3)           broken pass in 13933
 test-amd64-i386-xl-credit2    5 xen-boot           fail in 13933 pass in 13948

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13915
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13915

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 linux                24e842ae6cb8179126246ebcbfc477b36a7b8719
baseline version:
 linux                b9a7985a8d9ca00d8ce977756fde1306c9ab1e41

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           broken  
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=linux-3.0
+ revision=24e842ae6cb8179126246ebcbfc477b36a7b8719
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push linux-3.0 24e842ae6cb8179126246ebcbfc477b36a7b8719
+ branch=linux-3.0
+ revision=24e842ae6cb8179126246ebcbfc477b36a7b8719
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=linux
+ xenbranch=xen-unstable
+ '[' xlinux = xlinux ']'
+ linuxbranch=linux-3.0
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.linux-3.0
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux-3.0
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree linux-3.0
+ case $1 in
+ : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
+ : linux-3.0.y
+ : linux-3.0.y
+ : git
+ : git
+ : git://xenbits.xen.org/linux-pvops.git
+ : xen@xenbits.xensource.com:git/linux-pvops.git
+ : tested/linux-3.0
+ : tested/linux-3.0
+ return 0
+ cd /export/home/osstest/repos/linux
+ git push xen@xenbits.xensource.com:git/linux-pvops.git 24e842ae6cb8179126246ebcbfc477b36a7b8719:tested/linux-3.0
Counting objects: 1   
Counting objects: 276, done.
Compressing objects:   2% (1/35)   
Compressing objects:   5% (2/35)   
Compressing objects:   8% (3/35)   
Compressing objects:  11% (4/35)   
Compressing objects:  14% (5/35)   
Compressing objects:  17% (6/35)   
Compressing objects:  20% (7/35)   
Compressing objects:  22% (8/35)   
Compressing objects:  25% (9/35)   
Compressing objects:  28% (10/35)   
Compressing objects:  31% (11/35)   
Compressing objects:  34% (12/35)   
Compressing objects:  37% (13/35)   
Compressing objects:  40% (14/35)   
Compressing objects:  42% (15/35)   
Compressing objects:  45% (16/35)   
Compressing objects:  48% (17/35)   
Compressing objects:  51% (18/35)   
Compressing objects:  54% (19/35)   
Compressing objects:  57% (20/35)   
Compressing objects:  60% (21/35)   
Compressing objects:  62% (22/35)   
Compressing objects:  65% (23/35)   
Compressing objects:  68% (24/35)   
Compressing objects:  71% (25/35)   
Compressing objects:  74% (26/35)   
Compressing objects:  77% (27/35)   
Compressing objects:  80% (28/35)   
Compressing objects:  82% (29/35)   
Compressing objects:  85% (30/35)   
Compressing objects:  88% (31/35)   
Compressing objects:  91% (32/35)   
Compressing objects:  94% (33/35)   
Compressing objects:  97% (34/35)   
Compressing objects: 100% (35/35)   
Compressing objects: 100% (35/35), done.
Writing objects:   0% (1/203)   
Writing objects:   1% (3/203)   
Writing objects:   2% (5/203)   
Writing objects:   3% (7/203)   
Writing objects:   4% (9/203)   
Writing objects:   5% (11/203)   
Writing objects:   6% (13/203)   
Writing objects:   7% (15/203)   
Writing objects:   8% (17/203)   
Writing objects:   9% (19/203)   
Writing objects:  10% (21/203)   
Writing objects:  11% (23/203)   
Writing objects:  12% (25/203)   
Writing objects:  13% (27/203)   
Writing objects:  14% (29/203)   
Writing objects:  15% (31/203)   
Writing objects:  16% (33/203)   
Writing objects:  17% (35/203)   
Writing objects:  18% (37/203)   
Writing objects:  19% (39/203)   
Writing objects:  20% (41/203)   
Writing objects:  21% (43/203)   
Writing objects:  22% (45/203)   
Writing objects:  23% (47/203)   
Writing objects:  24% (49/203)   
Writing objects:  25% (51/203)   
Writing objects:  26% (53/203)   
Writing objects:  27% (55/203)   
Writing objects:  28% (57/203)   
Writing objects:  29% (59/203)   
Writing objects:  30% (61/203)   
Writing objects:  31% (63/203)   
Writing objects:  32% (65/203)   
Writing objects:  33% (67/203)   
Writing objects:  34% (70/203)   
Writing objects:  35% (72/203)   
Writing objects:  36% (74/203)   
Writing objects:  37% (76/203)   
Writing objects:  38% (78/203)   
Writing objects:  39% (80/203)   
Writing objects:  40% (82/203)   
Writing objects:  41% (84/203)   
Writing objects:  42% (86/203)   
Writing objects:  43% (88/203)   
Writing objects:  44% (90/203)   
Writing objects:  45% (92/203)   
Writing objects:  46% (94/203)   
Writing objects:  47% (96/203)   
Writing objects:  48% (98/203)   
Writing objects:  49% (100/203)   
Writing objects:  50% (102/203)   
Writing objects:  51% (104/203)   
Writing objects:  52% (106/203)   
Writing objects:  53% (108/203)   
Writing objects:  54% (110/203)   
Writing objects:  55% (112/203)   
Writing objects:  56% (114/203)   
Writing objects:  57% (116/203)   
Writing objects:  58% (118/203)   
Writing objects:  59% (120/203)   
Writing objects:  60% (122/203)   
Writing objects:  61% (124/203)   
Writing objects:  62% (126/203)   
Writing objects:  63% (128/203)   
Writing objects:  64% (130/203)   
Writing objects:  65% (132/203)   
Writing objects:  66% (134/203)   
Writing objects:  67% (137/203)   
Writing objects:  68% (139/203)   
Writing objects:  69% (141/203)   
Writing objects:  70% (143/203)   
Writing objects:  71% (145/203)   
Writing objects:  72% (147/203)   
Writing objects:  73% (149/203)   
Writing objects:  74% (151/203)   
Writing objects:  75% (153/203)   
Writing objects:  76% (155/203)   
Writing objects:  77% (157/203)   
Writing objects:  78% (159/203)   
Writing objects:  79% (161/203)   
Writing objects:  80% (163/203)   
Writing objects:  81% (165/203)   
Writing objects:  82% (167/203)   
Writing objects:  83% (169/203)   
Writing objects:  84% (171/203)   
Writing objects:  85% (173/203)   
Writing objects:  86% (175/203)   
Writing objects:  87% (177/203)   
Writing objects:  88% (179/203)   
Writing objects:  89% (181/203)   
Writing objects:  90% (183/203)   
Writing objects:  91% (185/203)   
Writing objects:  92% (187/203)   
Writing objects:  93% (189/203)   
Writing objects:  94% (191/203)   
Writing objects:  95% (193/203)   
Writing objects:  96% (195/203)   
Writing objects:  97% (197/203)   
Writing objects:  98% (199/203)   
Writing objects:  99% (201/203)   
Writing objects: 100% (203/203)   
Writing objects: 100% (203/203), 33.55 KiB, done.
Total 203 (delta 168), reused 203 (delta 168)
To xen@xenbits.xensource.com:git/linux-pvops.git
   b9a7985..24e842a  24e842ae6cb8179126246ebcbfc477b36a7b8719 -> tested/linux-3.0
+ exit 0

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 21:12:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 21:12:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TM3Zv-0006qK-Jc; Wed, 10 Oct 2012 21:12:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TM3Zt-0006q2-4n
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 21:12:29 +0000
Received: from [85.158.139.211:27549] by server-9.bemta-5.messagelabs.com id
	5B/5E-31466-CB4E5705; Wed, 10 Oct 2012 21:12:28 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1349903546!21386633!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9457 invoked from network); 10 Oct 2012 21:12:27 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 21:12:27 -0000
Received: by mail-qa0-f45.google.com with SMTP id s11so5412761qaa.11
	for ; Wed, 10 Oct 2012 14:12:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=AY8yryyoMaGly6GTgGHB/YuyN+ejDz6Jvzff04S9g6I=;
	b=yxBlU7mWvkozX2ofQzL2JbufmX4htQ83E8+l0ruYqwl+r0U6l5xpHCt5JTt+q9i5Ee
	gS/3xQvBbX5rCFB+XdY1BeFfvKzd4NGRLsc3bmJ8bd7zd1dfdN0BRQFTTXXXi0dsP3D6
	XQOmeACZAJ9LAnwSUzxCpI9kbcriU0gmOjjn1CB2CCWNR+uq12ChDN76laQOHkgklh+3
	3s1hdsUOSpG3N5dlpjS7VFLr51YnFRKsrXIWIFkHuNjalYZM+QtkfqcOiaFu5O6C/JbZ
	U1dgAnkytlph9YoxzEpBC8J99Fbcc+Sg/65GsG/L2Imkidf+g75Fji0SkoiycoauxfK4
	6iSw==
Received: by 10.224.39.76 with SMTP id f12mr42306271qae.94.1349903546375;
	Wed, 10 Oct 2012 14:12:26 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id ce2sm2641555qab.3.2012.10.10.14.12.25
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 10 Oct 2012 14:12:26 -0700 (PDT)
Date: Wed, 10 Oct 2012 17:00:37 -0400
From: Konrad Rzeszutek Wilk 
To: Sander Eikelenboom 
Message-ID: <20121010210037.GA31679@phenom.dumpdata.com>
References: <76252326.20121010175818@eikelenboom.it>
	<20121010185056.GA5448@phenom.dumpdata.com>
	<1831776290.20121010210751@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1831776290.20121010210751@eikelenboom.it>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel 
Subject: Re: [Xen-devel] Kernel 3.7.0-pre-rc1: mcelog:4344 map pfn expected
 mapping type write-back for [mem 0x0009f000-0x000a0fff], got uncached-minus,
 WARNING: at arch/x86/mm/pat.c:774 untrack_pfn+0x8c/0xc0()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 10, 2012 at 09:07:51PM +0200, Sander Eikelenboom wrote:
> 
> Wednesday, October 10, 2012, 8:50:57 PM, you wrote:
> 
> > On Wed, Oct 10, 2012 at 05:58:18PM +0200, Sander Eikelenboom wrote:
> >> Hi Konrad,
> >> 
> >> On boot with a 3.7.0-pre-rc1 (latest commit is 42859eea96ba6beabfb0369a1eeffa3c7d2bd9cb) i always get:
> >> 
> >> 
> >> [   75.718807] mcelog:4344 map pfn expected mapping type write-back for [mem 0x0009f000-0x000a0fff], got uncached-minus
> >> [   75.725282] ------------[ cut here ]------------
> >> [   75.731316] WARNING: at arch/x86/mm/pat.c:774 untrack_pfn+0x8c/0xc0()
> >> [   75.737465] Hardware name: MS-7640
> >> [   75.743678] Modules linked in:
> >> [   75.749528] Pid: 4344, comm: mcelog Not tainted 3.6.0pre-rc1-20121010 #1
> >> [   75.755581] Call Trace:
> >> [   75.761303]  [] warn_slowpath_common+0x7a/0xb0
> >> [   75.767036]  [] warn_slowpath_null+0x15/0x20
> >> [   75.772804]  [] untrack_pfn+0x8c/0xc0
> >> [   75.778391]  [] unmap_single_vma+0x86b/0x8e0
> >> [   75.784002]  [] ? release_pages+0x196/0x1f0
> >> [   75.789484]  [] ? _raw_spin_unlock_irqrestore+0x75/0xa0
> >> [   75.794970]  [] unmap_vmas+0x4c/0xa0
> >> [   75.800375]  [] exit_mmap+0x9a/0x180
> >> [   75.805748]  [] mmput+0x52/0xd0
> >> [   75.811046]  [] dup_mm+0x3c7/0x510
> >> [   75.816380]  [] copy_process+0xad5/0x14b0
> >> [   75.821777]  [] do_fork+0x53/0x360
> >> [   75.827114]  [] ? lock_release+0x117/0x250
> >> [   75.832380]  [] ? _raw_spin_unlock+0x30/0x60
> >> [   75.837977]  [] ? sysret_check+0x22/0x5d
> >> [   75.843337]  [] sys_clone+0x23/0x30
> >> [   75.848567]  [] stub_clone+0x13/0x20
> >> [   75.853718]  [] ? system_call_fastpath+0x16/0x1b
> >> [   75.858913] ---[ end trace df00fd3532db355c ]---
> >> 
> >> 
> >> xl dmesg and dmesg attached.
> 
> > Heh. Not seeing them.
> 
> > But more importantly, do you have CONFIG_XEN_MCE.. something enabled?
> 
> # grep XEN_MCE .config
> # CONFIG_XEN_MCE_LOG is not set
> 
> Nope

If you enable that, do these issues go away?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 21:12:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 21:12:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TM3Zv-0006qK-Jc; Wed, 10 Oct 2012 21:12:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TM3Zt-0006q2-4n
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 21:12:29 +0000
Received: from [85.158.139.211:27549] by server-9.bemta-5.messagelabs.com id
	5B/5E-31466-CB4E5705; Wed, 10 Oct 2012 21:12:28 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1349903546!21386633!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9457 invoked from network); 10 Oct 2012 21:12:27 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 21:12:27 -0000
Received: by mail-qa0-f45.google.com with SMTP id s11so5412761qaa.11
	for ; Wed, 10 Oct 2012 14:12:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=AY8yryyoMaGly6GTgGHB/YuyN+ejDz6Jvzff04S9g6I=;
	b=yxBlU7mWvkozX2ofQzL2JbufmX4htQ83E8+l0ruYqwl+r0U6l5xpHCt5JTt+q9i5Ee
	gS/3xQvBbX5rCFB+XdY1BeFfvKzd4NGRLsc3bmJ8bd7zd1dfdN0BRQFTTXXXi0dsP3D6
	XQOmeACZAJ9LAnwSUzxCpI9kbcriU0gmOjjn1CB2CCWNR+uq12ChDN76laQOHkgklh+3
	3s1hdsUOSpG3N5dlpjS7VFLr51YnFRKsrXIWIFkHuNjalYZM+QtkfqcOiaFu5O6C/JbZ
	U1dgAnkytlph9YoxzEpBC8J99Fbcc+Sg/65GsG/L2Imkidf+g75Fji0SkoiycoauxfK4
	6iSw==
Received: by 10.224.39.76 with SMTP id f12mr42306271qae.94.1349903546375;
	Wed, 10 Oct 2012 14:12:26 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id ce2sm2641555qab.3.2012.10.10.14.12.25
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 10 Oct 2012 14:12:26 -0700 (PDT)
Date: Wed, 10 Oct 2012 17:00:37 -0400
From: Konrad Rzeszutek Wilk 
To: Sander Eikelenboom 
Message-ID: <20121010210037.GA31679@phenom.dumpdata.com>
References: <76252326.20121010175818@eikelenboom.it>
	<20121010185056.GA5448@phenom.dumpdata.com>
	<1831776290.20121010210751@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1831776290.20121010210751@eikelenboom.it>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel 
Subject: Re: [Xen-devel] Kernel 3.7.0-pre-rc1: mcelog:4344 map pfn expected
 mapping type write-back for [mem 0x0009f000-0x000a0fff], got uncached-minus,
 WARNING: at arch/x86/mm/pat.c:774 untrack_pfn+0x8c/0xc0()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 10, 2012 at 09:07:51PM +0200, Sander Eikelenboom wrote:
> 
> Wednesday, October 10, 2012, 8:50:57 PM, you wrote:
> 
> > On Wed, Oct 10, 2012 at 05:58:18PM +0200, Sander Eikelenboom wrote:
> >> Hi Konrad,
> >> 
> >> On boot with a 3.7.0-pre-rc1 (latest commit is 42859eea96ba6beabfb0369a1eeffa3c7d2bd9cb) i always get:
> >> 
> >> 
> >> [   75.718807] mcelog:4344 map pfn expected mapping type write-back for [mem 0x0009f000-0x000a0fff], got uncached-minus
> >> [   75.725282] ------------[ cut here ]------------
> >> [   75.731316] WARNING: at arch/x86/mm/pat.c:774 untrack_pfn+0x8c/0xc0()
> >> [   75.737465] Hardware name: MS-7640
> >> [   75.743678] Modules linked in:
> >> [   75.749528] Pid: 4344, comm: mcelog Not tainted 3.6.0pre-rc1-20121010 #1
> >> [   75.755581] Call Trace:
> >> [   75.761303]  [] warn_slowpath_common+0x7a/0xb0
> >> [   75.767036]  [] warn_slowpath_null+0x15/0x20
> >> [   75.772804]  [] untrack_pfn+0x8c/0xc0
> >> [   75.778391]  [] unmap_single_vma+0x86b/0x8e0
> >> [   75.784002]  [] ? release_pages+0x196/0x1f0
> >> [   75.789484]  [] ? _raw_spin_unlock_irqrestore+0x75/0xa0
> >> [   75.794970]  [] unmap_vmas+0x4c/0xa0
> >> [   75.800375]  [] exit_mmap+0x9a/0x180
> >> [   75.805748]  [] mmput+0x52/0xd0
> >> [   75.811046]  [] dup_mm+0x3c7/0x510
> >> [   75.816380]  [] copy_process+0xad5/0x14b0
> >> [   75.821777]  [] do_fork+0x53/0x360
> >> [   75.827114]  [] ? lock_release+0x117/0x250
> >> [   75.832380]  [] ? _raw_spin_unlock+0x30/0x60
> >> [   75.837977]  [] ? sysret_check+0x22/0x5d
> >> [   75.843337]  [] sys_clone+0x23/0x30
> >> [   75.848567]  [] stub_clone+0x13/0x20
> >> [   75.853718]  [] ? system_call_fastpath+0x16/0x1b
> >> [   75.858913] ---[ end trace df00fd3532db355c ]---
> >> 
> >> 
> >> xl dmesg and dmesg attached.
> 
> > Heh. Not seeing them.
> 
> > But more importantly, do you have CONFIG_XEN_MCE.. something enabled?
> 
> # grep XEN_MCE .config
> # CONFIG_XEN_MCE_LOG is not set
> 
> Nope

If you enable that, do these issues go away?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 22:12:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 22:12:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TM4VG-0008S7-Ru; Wed, 10 Oct 2012 22:11:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TM4VE-0008Pu-Kt
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 22:11:44 +0000
Received: from [85.158.139.83:61558] by server-11.bemta-5.messagelabs.com id
	79/F7-15507-F92F5705; Wed, 10 Oct 2012 22:11:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1349907103!34297018!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM3MzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9678 invoked from network); 10 Oct 2012 22:11:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 22:11:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,567,1344211200"; d="scan'208";a="15084910"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 22:11:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 10 Oct 2012 23:11:19 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TM4Up-00084Z-3x;
	Wed, 10 Oct 2012 22:11:19 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TM4Uo-0003aD-GB;
	Wed, 10 Oct 2012 23:11:18 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Wed, 10 Oct 2012 23:11:18 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13949: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13949 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13949/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13932
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13932
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13932
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13932

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  3696dd6a7836
baseline version:
 xen                  099589002239

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper 
  Anthony PERARD 
  Christoph Egger 
  David Vrabel 
  Ian Campbell 
  Ian Jackson 
  Keir Fraser 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Samuel Thibault 
  Samuel Thibault 
  Stefano Stabellini 
  Tim Deegan 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=3696dd6a7836
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 3696dd6a7836
+ branch=xen-unstable
+ revision=3696dd6a7836
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 3696dd6a7836 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 38 changesets with 82 changes to 70 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 22:12:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 22:12:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TM4VG-0008S7-Ru; Wed, 10 Oct 2012 22:11:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TM4VE-0008Pu-Kt
	for xen-devel@lists.xensource.com; Wed, 10 Oct 2012 22:11:44 +0000
Received: from [85.158.139.83:61558] by server-11.bemta-5.messagelabs.com id
	79/F7-15507-F92F5705; Wed, 10 Oct 2012 22:11:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1349907103!34297018!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM3MzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9678 invoked from network); 10 Oct 2012 22:11:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Oct 2012 22:11:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,567,1344211200"; d="scan'208";a="15084910"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Oct 2012 22:11:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 10 Oct 2012 23:11:19 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TM4Up-00084Z-3x;
	Wed, 10 Oct 2012 22:11:19 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TM4Uo-0003aD-GB;
	Wed, 10 Oct 2012 23:11:18 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Wed, 10 Oct 2012 23:11:18 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13949: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13949 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13949/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13932
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13932
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13932
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13932

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  3696dd6a7836
baseline version:
 xen                  099589002239

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper 
  Anthony PERARD 
  Christoph Egger 
  David Vrabel 
  Ian Campbell 
  Ian Jackson 
  Keir Fraser 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Samuel Thibault 
  Samuel Thibault 
  Stefano Stabellini 
  Tim Deegan 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=3696dd6a7836
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 3696dd6a7836
+ branch=xen-unstable
+ revision=3696dd6a7836
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 3696dd6a7836 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 38 changesets with 82 changes to 70 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 23:52:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 23:52:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TM64D-0001eA-RV; Wed, 10 Oct 2012 23:51:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TM64C-0001e5-7x
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 23:51:56 +0000
Received: from [85.158.137.99:57426] by server-6.bemta-3.messagelabs.com id
	90/43-32375-B1A06705; Wed, 10 Oct 2012 23:51:55 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-5.tower-217.messagelabs.com!1349913114!16361655!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12930 invoked from network); 10 Oct 2012 23:51:54 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-5.tower-217.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Oct 2012 23:51:54 -0000
Received: from 50-66-ftth.onsneteindhoven.nl ([88.159.66.50]:61283
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TM65V-0003Rs-Ct; Thu, 11 Oct 2012 01:53:17 +0200
Date: Thu, 11 Oct 2012 01:51:47 +0200
From: Sander Eikelenboom 
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <876735018.20121011015147@eikelenboom.it>
To: Konrad Rzeszutek Wilk 
In-Reply-To: <20121010210037.GA31679@phenom.dumpdata.com>
References: <76252326.20121010175818@eikelenboom.it>
	<20121010185056.GA5448@phenom.dumpdata.com>
	<1831776290.20121010210751@eikelenboom.it>
	<20121010210037.GA31679@phenom.dumpdata.com>
MIME-Version: 1.0
Cc: xen-devel 
Subject: Re: [Xen-devel] Kernel 3.7.0-pre-rc1: mcelog:4344 map pfn expected
	mapping type write-back for [mem 0x0009f000-0x000a0fff],
	got uncached-minus,
	WARNING: at arch/x86/mm/pat.c:774 untrack_pfn+0x8c/0xc0()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Wednesday, October 10, 2012, 11:00:37 PM, you wrote:

> On Wed, Oct 10, 2012 at 09:07:51PM +0200, Sander Eikelenboom wrote:
>> 
>> Wednesday, October 10, 2012, 8:50:57 PM, you wrote:
>> 
>> > On Wed, Oct 10, 2012 at 05:58:18PM +0200, Sander Eikelenboom wrote:
>> >> Hi Konrad,
>> >> 
>> >> On boot with a 3.7.0-pre-rc1 (latest commit is 42859eea96ba6beabfb0369a1eeffa3c7d2bd9cb) i always get:
>> >> 
>> >> 
>> >> [   75.718807] mcelog:4344 map pfn expected mapping type write-back for [mem 0x0009f000-0x000a0fff], got uncached-minus
>> >> [   75.725282] ------------[ cut here ]------------
>> >> [   75.731316] WARNING: at arch/x86/mm/pat.c:774 untrack_pfn+0x8c/0xc0()
>> >> [   75.737465] Hardware name: MS-7640
>> >> [   75.743678] Modules linked in:
>> >> [   75.749528] Pid: 4344, comm: mcelog Not tainted 3.6.0pre-rc1-20121010 #1
>> >> [   75.755581] Call Trace:
>> >> [   75.761303]  [] warn_slowpath_common+0x7a/0xb0
>> >> [   75.767036]  [] warn_slowpath_null+0x15/0x20
>> >> [   75.772804]  [] untrack_pfn+0x8c/0xc0
>> >> [   75.778391]  [] unmap_single_vma+0x86b/0x8e0
>> >> [   75.784002]  [] ? release_pages+0x196/0x1f0
>> >> [   75.789484]  [] ? _raw_spin_unlock_irqrestore+0x75/0xa0
>> >> [   75.794970]  [] unmap_vmas+0x4c/0xa0
>> >> [   75.800375]  [] exit_mmap+0x9a/0x180
>> >> [   75.805748]  [] mmput+0x52/0xd0
>> >> [   75.811046]  [] dup_mm+0x3c7/0x510
>> >> [   75.816380]  [] copy_process+0xad5/0x14b0
>> >> [   75.821777]  [] do_fork+0x53/0x360
>> >> [   75.827114]  [] ? lock_release+0x117/0x250
>> >> [   75.832380]  [] ? _raw_spin_unlock+0x30/0x60
>> >> [   75.837977]  [] ? sysret_check+0x22/0x5d
>> >> [   75.843337]  [] sys_clone+0x23/0x30
>> >> [   75.848567]  [] stub_clone+0x13/0x20
>> >> [   75.853718]  [] ? system_call_fastpath+0x16/0x1b
>> >> [   75.858913] ---[ end trace df00fd3532db355c ]---
>> >> 
>> >> 
>> >> xl dmesg and dmesg attached.
>> 
>> > Heh. Not seeing them.
>> 
>> > But more importantly, do you have CONFIG_XEN_MCE.. something enabled?
>> 
>> # grep XEN_MCE .config
>> # CONFIG_XEN_MCE_LOG is not set
>> 
>> Nope

> If you enable that, do these issues go away?

Nope, doesn't change a thing ...


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 10 23:52:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 10 Oct 2012 23:52:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TM64D-0001eA-RV; Wed, 10 Oct 2012 23:51:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TM64C-0001e5-7x
	for xen-devel@lists.xen.org; Wed, 10 Oct 2012 23:51:56 +0000
Received: from [85.158.137.99:57426] by server-6.bemta-3.messagelabs.com id
	90/43-32375-B1A06705; Wed, 10 Oct 2012 23:51:55 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-5.tower-217.messagelabs.com!1349913114!16361655!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12930 invoked from network); 10 Oct 2012 23:51:54 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-5.tower-217.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Oct 2012 23:51:54 -0000
Received: from 50-66-ftth.onsneteindhoven.nl ([88.159.66.50]:61283
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TM65V-0003Rs-Ct; Thu, 11 Oct 2012 01:53:17 +0200
Date: Thu, 11 Oct 2012 01:51:47 +0200
From: Sander Eikelenboom 
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <876735018.20121011015147@eikelenboom.it>
To: Konrad Rzeszutek Wilk 
In-Reply-To: <20121010210037.GA31679@phenom.dumpdata.com>
References: <76252326.20121010175818@eikelenboom.it>
	<20121010185056.GA5448@phenom.dumpdata.com>
	<1831776290.20121010210751@eikelenboom.it>
	<20121010210037.GA31679@phenom.dumpdata.com>
MIME-Version: 1.0
Cc: xen-devel 
Subject: Re: [Xen-devel] Kernel 3.7.0-pre-rc1: mcelog:4344 map pfn expected
	mapping type write-back for [mem 0x0009f000-0x000a0fff],
	got uncached-minus,
	WARNING: at arch/x86/mm/pat.c:774 untrack_pfn+0x8c/0xc0()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Wednesday, October 10, 2012, 11:00:37 PM, you wrote:

> On Wed, Oct 10, 2012 at 09:07:51PM +0200, Sander Eikelenboom wrote:
>> 
>> Wednesday, October 10, 2012, 8:50:57 PM, you wrote:
>> 
>> > On Wed, Oct 10, 2012 at 05:58:18PM +0200, Sander Eikelenboom wrote:
>> >> Hi Konrad,
>> >> 
>> >> On boot with a 3.7.0-pre-rc1 (latest commit is 42859eea96ba6beabfb0369a1eeffa3c7d2bd9cb) i always get:
>> >> 
>> >> 
>> >> [   75.718807] mcelog:4344 map pfn expected mapping type write-back for [mem 0x0009f000-0x000a0fff], got uncached-minus
>> >> [   75.725282] ------------[ cut here ]------------
>> >> [   75.731316] WARNING: at arch/x86/mm/pat.c:774 untrack_pfn+0x8c/0xc0()
>> >> [   75.737465] Hardware name: MS-7640
>> >> [   75.743678] Modules linked in:
>> >> [   75.749528] Pid: 4344, comm: mcelog Not tainted 3.6.0pre-rc1-20121010 #1
>> >> [   75.755581] Call Trace:
>> >> [   75.761303]  [] warn_slowpath_common+0x7a/0xb0
>> >> [   75.767036]  [] warn_slowpath_null+0x15/0x20
>> >> [   75.772804]  [] untrack_pfn+0x8c/0xc0
>> >> [   75.778391]  [] unmap_single_vma+0x86b/0x8e0
>> >> [   75.784002]  [] ? release_pages+0x196/0x1f0
>> >> [   75.789484]  [] ? _raw_spin_unlock_irqrestore+0x75/0xa0
>> >> [   75.794970]  [] unmap_vmas+0x4c/0xa0
>> >> [   75.800375]  [] exit_mmap+0x9a/0x180
>> >> [   75.805748]  [] mmput+0x52/0xd0
>> >> [   75.811046]  [] dup_mm+0x3c7/0x510
>> >> [   75.816380]  [] copy_process+0xad5/0x14b0
>> >> [   75.821777]  [] do_fork+0x53/0x360
>> >> [   75.827114]  [] ? lock_release+0x117/0x250
>> >> [   75.832380]  [] ? _raw_spin_unlock+0x30/0x60
>> >> [   75.837977]  [] ? sysret_check+0x22/0x5d
>> >> [   75.843337]  [] sys_clone+0x23/0x30
>> >> [   75.848567]  [] stub_clone+0x13/0x20
>> >> [   75.853718]  [] ? system_call_fastpath+0x16/0x1b
>> >> [   75.858913] ---[ end trace df00fd3532db355c ]---
>> >> 
>> >> 
>> >> xl dmesg and dmesg attached.
>> 
>> > Heh. Not seeing them.
>> 
>> > But more importantly, do you have CONFIG_XEN_MCE.. something enabled?
>> 
>> # grep XEN_MCE .config
>> # CONFIG_XEN_MCE_LOG is not set
>> 
>> Nope

> If you enable that, do these issues go away?

Nope, doesn't change a thing ...


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 02:14:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 02:14:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TM8IC-0007zZ-QM; Thu, 11 Oct 2012 02:14:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TM8IB-0007zS-Ig
	for xen-devel@lists.xensource.com; Thu, 11 Oct 2012 02:14:31 +0000
Received: from [85.158.139.211:27927] by server-12.bemta-5.messagelabs.com id
	A8/4B-19095-68B26705; Thu, 11 Oct 2012 02:14:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1349921670!21832133!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM4Mjk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 919 invoked from network); 11 Oct 2012 02:14:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Oct 2012 02:14:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,567,1344211200"; d="scan'208";a="15086857"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Oct 2012 02:14:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 11 Oct 2012 03:14:29 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TM8I9-0000td-5X;
	Thu, 11 Oct 2012 02:14:29 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TM8I9-0003NW-01;
	Thu, 11 Oct 2012 03:14:29 +0100
To: 
Message-ID: 
From: xen.org 
Date: Thu, 11 Oct 2012 03:14:29 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13950: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13950 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13950/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13949
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13949
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13949
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13949

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  3696dd6a7836
baseline version:
 xen                  3696dd6a7836

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 02:14:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 02:14:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TM8IC-0007zZ-QM; Thu, 11 Oct 2012 02:14:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TM8IB-0007zS-Ig
	for xen-devel@lists.xensource.com; Thu, 11 Oct 2012 02:14:31 +0000
Received: from [85.158.139.211:27927] by server-12.bemta-5.messagelabs.com id
	A8/4B-19095-68B26705; Thu, 11 Oct 2012 02:14:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1349921670!21832133!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM4Mjk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 919 invoked from network); 11 Oct 2012 02:14:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Oct 2012 02:14:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,567,1344211200"; d="scan'208";a="15086857"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Oct 2012 02:14:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 11 Oct 2012 03:14:29 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TM8I9-0000td-5X;
	Thu, 11 Oct 2012 02:14:29 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TM8I9-0003NW-01;
	Thu, 11 Oct 2012 03:14:29 +0100
To: 
Message-ID: 
From: xen.org 
Date: Thu, 11 Oct 2012 03:14:29 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13950: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13950 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13950/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13949
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13949
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13949
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13949

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  3696dd6a7836
baseline version:
 xen                  3696dd6a7836

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 02:54:39 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 02:54:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TM8uY-0000F8-Vy; Thu, 11 Oct 2012 02:54:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TM8uX-0000F0-BW
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 02:54:09 +0000
Received: from [85.158.143.35:41039] by server-2.bemta-4.messagelabs.com id
	9B/C1-25171-0D436705; Thu, 11 Oct 2012 02:54:08 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-10.tower-21.messagelabs.com!1349924047!10989581!1
X-Originating-IP: [149.20.54.216]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19040 invoked from network); 11 Oct 2012 02:54:07 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-10.tower-21.messagelabs.com with SMTP;
	11 Oct 2012 02:54:07 -0000
Received: from localhost (cpe-66-108-116-58.nyc.res.rr.com [66.108.116.58])
	by shards.monkeyblade.net (Postfix) with ESMTPSA id 8EBB9585149;
	Wed, 10 Oct 2012 19:54:08 -0700 (PDT)
Date: Wed, 10 Oct 2012 22:54:05 -0400 (EDT)
Message-Id: <20121010.225405.819531775702809174.davem@davemloft.net>
To: ian.campbell@citrix.com
From: David Miller 
In-Reply-To: <1349876922-11907-1-git-send-email-ian.campbell@citrix.com>
References: <1349876922-11907-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: Mew version 6.5 on Emacs 24.1 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Cc: netdev@vger.kernel.org, linux@eikelenboom.it, konrad@kernel.org,
	eric.dumazet@gmail.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH V2] xen: netback: handle compound page
 fragments on transmit.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Ian Campbell 
Date: Wed, 10 Oct 2012 14:48:42 +0100

> An SKB paged fragment can consist of a compound page with order > 0.
> However the netchannel protocol deals only in PAGE_SIZE frames.
> 
> Handle this in netbk_gop_frag_copy and xen_netbk_count_skb_slots by
> iterating over the frames which make up the page.
> 
> Signed-off-by: Ian Campbell 

Applied.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 02:54:39 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 02:54:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TM8uY-0000F8-Vy; Thu, 11 Oct 2012 02:54:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TM8uX-0000F0-BW
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 02:54:09 +0000
Received: from [85.158.143.35:41039] by server-2.bemta-4.messagelabs.com id
	9B/C1-25171-0D436705; Thu, 11 Oct 2012 02:54:08 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-10.tower-21.messagelabs.com!1349924047!10989581!1
X-Originating-IP: [149.20.54.216]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19040 invoked from network); 11 Oct 2012 02:54:07 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-10.tower-21.messagelabs.com with SMTP;
	11 Oct 2012 02:54:07 -0000
Received: from localhost (cpe-66-108-116-58.nyc.res.rr.com [66.108.116.58])
	by shards.monkeyblade.net (Postfix) with ESMTPSA id 8EBB9585149;
	Wed, 10 Oct 2012 19:54:08 -0700 (PDT)
Date: Wed, 10 Oct 2012 22:54:05 -0400 (EDT)
Message-Id: <20121010.225405.819531775702809174.davem@davemloft.net>
To: ian.campbell@citrix.com
From: David Miller 
In-Reply-To: <1349876922-11907-1-git-send-email-ian.campbell@citrix.com>
References: <1349876922-11907-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: Mew version 6.5 on Emacs 24.1 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Cc: netdev@vger.kernel.org, linux@eikelenboom.it, konrad@kernel.org,
	eric.dumazet@gmail.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH V2] xen: netback: handle compound page
 fragments on transmit.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Ian Campbell 
Date: Wed, 10 Oct 2012 14:48:42 +0100

> An SKB paged fragment can consist of a compound page with order > 0.
> However the netchannel protocol deals only in PAGE_SIZE frames.
> 
> Handle this in netbk_gop_frag_copy and xen_netbk_count_skb_slots by
> iterating over the frames which make up the page.
> 
> Signed-off-by: Ian Campbell 

Applied.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 04:20:12 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 04:20:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMAFM-00015V-2X; Thu, 11 Oct 2012 04:19:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMAFJ-00015Q-VV
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 04:19:42 +0000
Received: from [85.158.139.83:62168] by server-5.bemta-5.messagelabs.com id
	B5/C6-19238-DD846705; Thu, 11 Oct 2012 04:19:41 +0000
X-Env-Sender: avs.009@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1349929175!30050410!1
X-Originating-IP: [209.85.210.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10593 invoked from network); 11 Oct 2012 04:19:36 -0000
Received: from mail-ia0-f173.google.com (HELO mail-ia0-f173.google.com)
	(209.85.210.173)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Oct 2012 04:19:36 -0000
Received: by mail-ia0-f173.google.com with SMTP id m10so1176521iam.32
	for ; Wed, 10 Oct 2012 21:19:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=QqCdBhK52TgtA/rvX38GV/iddN6YvC5JsRQmV1ZjhjA=;
	b=hFGYFOQZu/pvXrtFAcF9ynyhGl9zfQgoc/dQg2Rv9vtj9HUWEImMmNl5USC3UaMYlL
	7FycrmNMeu0kRZZSfBYh4WUnT4K+ba5nxXILGbVpsBs1D6dckF4rGNDuW/b8BDeb3W+u
	xXZTEPOrE693EUOgR3Q7s52uxEsakLcWIdgaC2Nt1cDdYvEbxJiTo9/wFyJ+UoIdZo/V
	8rM25OK2SXg44Pj2pGeXSNvgIJFGUMTjyXsi44cyvgvfX+p6FkVfDJcnQt9JfM9VAd3o
	M83XbUzbTiUcPm5wHRp0FYmuEf4gpdzbBUKmOwdyhESTXclmYrr7Rv5oDUYutz7SL25F
	/ojA==
MIME-Version: 1.0
Received: by 10.50.185.194 with SMTP id fe2mr7561274igc.60.1349929174748; Wed,
	10 Oct 2012 21:19:34 -0700 (PDT)
Received: by 10.64.22.71 with HTTP; Wed, 10 Oct 2012 21:19:34 -0700 (PDT)
Date: Thu, 11 Oct 2012 01:19:34 -0300
Message-ID: 
From: Allan Scheid 
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Xen 4.2 with EFI on IBM Server ACPI Bug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============4323735893482094400=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4323735893482094400==
Content-Type: multipart/alternative; boundary=14dae934109feecd8704cbc0e07e

--14dae934109feecd8704cbc0e07e
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hellow all, i need help with this bug:

ACPI BIOS Bug: Error: A valid RSDP was not found (20120711/tbxfroot-219)

Because of this first errors i get this second error, and it causes don't
work USB ports and some PCI cards on the system:

can't find IRQ for PCI INT A; please try using pci=3Dbiosirq

This occours only when i try boot with xen multiboot (with hypervisor), if
i boot only kernel with xen extensions no has errors in dmesg.

Kernel: 3.6.1-xen self compiled (work perfect without xen multiboot)
Xen Version: 4.2
Grub2 EFI: 1.99-23
Debian Unstable distro
Server: IBM System x3650 M3 7945AC1

dmesg output:

[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.6.1-xen (root@lca-fw) (gcc version 4.7.1
(Debian 4.7.1-7) ) #1 SMP Wed Oct 10 22:46:05 BRT 2012
[    0.000000] Command line: placeholder root=3D/dev/mapper/xen-fw_root ro
[    0.000000] Freeing 6c-6d pfn range: 1 pages freed
[    0.000000] 1-1 mapping on 6c->6d
[    0.000000] Freeing 9f-100 pfn range: 97 pages freed
[    0.000000] 1-1 mapping on 9f->100
[    0.000000] Freeing 7acb7-7ccb8 pfn range: 8193 pages freed
[    0.000000] 1-1 mapping on 7acb7->7ccb8
[    0.000000] Freeing 7d4f0-7d51b pfn range: 43 pages freed
[    0.000000] 1-1 mapping on 7d4f0->7d51b
[    0.000000] Freeing 7d53f-7d56a pfn range: 43 pages freed
[    0.000000] 1-1 mapping on 7d53f->7d56a
[    0.000000] Freeing 7d704-7d7b4 pfn range: 176 pages freed
[    0.000000] 1-1 mapping on 7d704->7d7b4
[    0.000000] Freeing 7f5ef-7f7ff pfn range: 528 pages freed
[    0.000000] 1-1 mapping on 7f5ef->7f7ff
[    0.000000] Freeing 7f800-f258d pfn range: 470413 pages freed
[    0.000000] 1-1 mapping on 7f800->100000
[    0.000000] Released 479494 pages of unused memory
[    0.000000] Set 535417 page(s) to 1-1 mapping
[    0.000000] Populating 100000-175106 pfn range: 479494 pages added
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] Xen: [mem 0x0000000000000000-0x000000000006bfff] usable
[    0.000000] Xen: [mem 0x000000000006c000-0x000000000006cfff] ACPI NVS
[    0.000000] Xen: [mem 0x000000000006d000-0x000000000009efff] usable
[    0.000000] Xen: [mem 0x000000000009f000-0x000000000009ffff] ACPI NVS
[    0.000000] Xen: [mem 0x00000000000a0000-0x00000000000fffff] reserved
[    0.000000] Xen: [mem 0x0000000000100000-0x000000007acb6fff] usable
[    0.000000] Xen: [mem 0x000000007acb7000-0x000000007ccb7fff] reserved
[    0.000000] Xen: [mem 0x000000007ccb8000-0x000000007d4effff] usable
[    0.000000] Xen: [mem 0x000000007d4f0000-0x000000007d51afff] reserved
[    0.000000] Xen: [mem 0x000000007d51b000-0x000000007d53efff] usable
[    0.000000] Xen: [mem 0x000000007d53f000-0x000000007d569fff] reserved
[    0.000000] Xen: [mem 0x000000007d56a000-0x000000007d703fff] usable
[    0.000000] Xen: [mem 0x000000007d704000-0x000000007d7b3fff] reserved
[    0.000000] Xen: [mem 0x000000007d7b4000-0x000000007f5eefff] usable
[    0.000000] Xen: [mem 0x000000007f5ef000-0x000000007f6defff] reserved
[    0.000000] Xen: [mem 0x000000007f6df000-0x000000007f7defff] ACPI NVS
[    0.000000] Xen: [mem 0x000000007f7df000-0x000000007f7fefff] ACPI data
[    0.000000] Xen: [mem 0x000000007f7ff000-0x000000007f7fffff] usable
[    0.000000] Xen: [mem 0x0000000080000000-0x000000008fffffff] reserved
[    0.000000] Xen: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved
[    0.000000] Xen: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
[    0.000000] Xen: [mem 0x00000000ff800000-0x00000000ffffffff] reserved
[    0.000000] Xen: [mem 0x0000000100000000-0x000000017fffffff] usable
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI 2.5 present.
[    0.000000] DMI: IBM System x3650 M3 -[7945AC1]-/00D4062, BIOS
-[D6E157AUS-1.15]- 06/13/2012
[    0.000000] e820: update [mem 0x00000000-0x0000ffff] usable =3D=3D> rese=
rved
[    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[    0.000000] No AGP bridge found
[    0.000000] e820: last_pfn =3D 0x180000 max_arch_pfn =3D 0x400000000
[    0.000000] e820: last_pfn =3D 0x7f800 max_arch_pfn =3D 0x400000000
[    0.000000] initial memory mapped: [mem 0x00000000-0x02334fff]
[    0.000000] Base memory trampoline at [ffff880000099000] 99000 size 2457=
6
[    0.000000] init_memory_mapping: [mem 0x00000000-0x7f7fffff]
[    0.000000]  [mem 0x00000000-0x7f7fffff] page 4k
[    0.000000] kernel direct mapping tables up to 0x7f7fffff @ [mem
0x01831000-0x01c2ffff]
[    0.000000] xen: setting RW the range 1c14000 - 1c30000
[    0.000000] init_memory_mapping: [mem 0x100000000-0x17fffffff]
[    0.000000]  [mem 0x100000000-0x17fffffff] page 4k
[    0.000000] kernel direct mapping tables up to 0x17fffffff @ [mem
0x7e9e8000-0x7f5eefff]
[    0.000000] xen: setting RW the range 7edea000 - 7f5ef000
[    0.000000] RAMDISK: [mem 0x01c30000-0x02334fff]
[    0.000000] ACPI BIOS Bug: Error: A valid RSDP was not found
(20120711/tbxfroot-219)
[    0.000000] NUMA turned off
[    0.000000] Faking a node at [mem 0x0000000000000000-0x000000017fffffff]
[    0.000000] Initmem setup node 0 [mem 0x00000000-0x17fffffff]
[    0.000000]   NODE_DATA [mem 0x175102000-0x175105fff]
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x00010000-0x00ffffff]
[    0.000000]   DMA32    [mem 0x01000000-0xffffffff]
[    0.000000]   Normal   [mem 0x100000000-0x17fffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x00010000-0x0006bfff]
[    0.000000]   node   0: [mem 0x0006d000-0x0009efff]
[    0.000000]   node   0: [mem 0x00100000-0x7acb6fff]
[    0.000000]   node   0: [mem 0x7ccb8000-0x7d4effff]
[    0.000000]   node   0: [mem 0x7d51b000-0x7d53efff]
[    0.000000]   node   0: [mem 0x7d56a000-0x7d703fff]
[    0.000000]   node   0: [mem 0x7d7b4000-0x7f5eefff]
[    0.000000]   node   0: [mem 0x7f7ff000-0x7f7fffff]
[    0.000000]   node   0: [mem 0x100000000-0x17fffffff]
[    0.000000] On node 0 totalpages: 1037431
[    0.000000]   DMA zone: 56 pages used for memmap
[    0.000000]   DMA zone: 6 pages reserved
[    0.000000]   DMA zone: 3920 pages, LIFO batch:0
[    0.000000]   DMA32 zone: 14280 pages used for memmap
[    0.000000]   DMA32 zone: 494881 pages, LIFO batch:31
[    0.000000]   Normal zone: 7168 pages used for memmap
[    0.000000]   Normal zone: 517120 pages, LIFO batch:31
[    0.000000] SFI: Simple Firmware Interface v0.81
http://simplefirmware.org
[    0.000000] smpboot: Allowing 1 CPUs, 0 hotplug CPUs
[    0.000000] nr_irqs_gsi: 16
[    0.000000] PM: Registered nosave memory: 000000000006c000 -
000000000006d000
[    0.000000] PM: Registered nosave memory: 000000000009f000 -
00000000000a0000
[    0.000000] PM: Registered nosave memory: 00000000000a0000 -
0000000000100000
[    0.000000] PM: Registered nosave memory: 000000007acb7000 -
000000007ccb8000
[    0.000000] PM: Registered nosave memory: 000000007d4f0000 -
000000007d51b000
[    0.000000] PM: Registered nosave memory: 000000007d53f000 -
000000007d56a000
[    0.000000] PM: Registered nosave memory: 000000007d704000 -
000000007d7b4000
[    0.000000] PM: Registered nosave memory: 000000007f5ef000 -
000000007f6df000
[    0.000000] PM: Registered nosave memory: 000000007f6df000 -
000000007f7df000
[    0.000000] PM: Registered nosave memory: 000000007f7df000 -
000000007f7ff000
[    0.000000] PM: Registered nosave memory: 000000007f800000 -
0000000080000000
[    0.000000] PM: Registered nosave memory: 0000000080000000 -
0000000090000000
[    0.000000] PM: Registered nosave memory: 0000000090000000 -
00000000fed1c000
[    0.000000] PM: Registered nosave memory: 00000000fed1c000 -
00000000fed20000
[    0.000000] PM: Registered nosave memory: 00000000fed20000 -
00000000fee00000
[    0.000000] PM: Registered nosave memory: 00000000fee00000 -
00000000fee01000
[    0.000000] PM: Registered nosave memory: 00000000fee01000 -
00000000ff800000
[    0.000000] PM: Registered nosave memory: 00000000ff800000 -
0000000100000000
[    0.000000] e820: [mem 0x90000000-0xfed1bfff] available for PCI devices
[    0.000000] Booting paravirtualized kernel on Xen
[    0.000000] Xen version: 4.2.0 (preserve-AD)
[    0.000000] setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:1
nr_node_ids:1
[    0.000000] PERCPU: Embedded 28 pages/cpu @ffff880174e00000 s83840 r8192
d22656 u2097152
[    0.000000] pcpu-alloc: s83840 r8192 d22656 u2097152 alloc=3D1*2097152
[    0.000000] pcpu-alloc: [0] 0
[    1.096975] Built 1 zonelists in Zone order, mobility grouping on.
 Total pages: 1015921
[    1.096977] Policy zone: Normal
[    1.096979] Kernel command line: placeholder
root=3D/dev/mapper/xen-fw_root ro
[    1.097016] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    1.097021] __ex_table already sorted, skipping sort
[    1.121932] software IO TLB [mem 0x16c800000-0x1707fffff] (64MB) mapped
at [ffff88016c800000-ffff8801707fffff]
[    1.138656] Memory: 3815116k/6291456k available (3573k kernel code,
2141732k absent, 334608k reserved, 3147k data, 592k init)
[    1.138717] Hierarchical RCU implementation.
[    1.138718] RCU dyntick-idle grace-period acceleration is enabled.
[    1.138719] RCU restricting CPUs from NR_CPUS=3D512 to nr_cpu_ids=3D1.
[    1.138728] NR_IRQS:33024 nr_irqs:256 16
[    1.147171] Console: colour VGA+ 80x25
[    1.154296] console [tty0] enabled
[    1.159002] allocated 16777216 bytes of page_cgroup
[    1.159079] please try 'cgroup_disable=3Dmemory' option if you don't wan=
t
memory cgroups
[    1.159208] Xen: using vcpuop timer interface
[    1.159214] installing Xen timer for CPU 0
[    1.159303] tsc: Detected 2400.126 MHz processor
[    1.159375] Calibrating delay loop (skipped), value calculated using
timer frequency.. 4800.25 BogoMIPS (lpj=3D9600504)
[    1.159517] pid_max: default: 32768 minimum: 301
[    1.159607] Security Framework initialized
[    1.159680] AppArmor: AppArmor disabled by boot time parameter
[    1.160298] Dentry cache hash table entries: 524288 (order: 10, 4194304
bytes)
[    1.161752] Inode-cache hash table entries: 262144 (order: 9, 2097152
bytes)
[    1.162415] Mount-cache hash table entries: 256
[    1.162658] Initializing cgroup subsys cpuacct
[    1.162729] Initializing cgroup subsys memory
[    1.162806] Initializing cgroup subsys devices
[    1.162876] Initializing cgroup subsys freezer
[    1.162945] Initializing cgroup subsys net_cls
[    1.163014] Initializing cgroup subsys blkio
[    1.163082] Initializing cgroup subsys perf_event
[    1.163204] CPU: Physical Processor ID: 0
[    1.163277] CPU: Processor Core ID: 0
[    1.163346] mce: CPU supports 2 MCE banks
[    1.163452] Last level iTLB entries: 4KB 512, 2MB 7, 4MB 7
[    1.163452] Last level dTLB entries: 4KB 512, 2MB 32, 4MB 32
[    1.163452] tlb_flushall_shift is 0x6
[    1.163602] SMP alternatives: switching to UP code
[    1.171342] Freeing SMP alternatives: 8k freed
[    1.171471] Performance Events: unsupported p6 CPU model 44 no PMU
driver, software events only.
[    1.171785] NMI watchdog: disabled (cpu0): hardware events not enabled
[    1.171876] Brought up 1 CPUs
[    1.172058] devtmpfs: initialized
[    1.174970] PM: Registering ACPI NVS region [mem 0x0006c000-0x0006cfff]
(4096 bytes)
[    1.175062] PM: Registering ACPI NVS region [mem 0x0009f000-0x0009ffff]
(4096 bytes)
[    1.175153] PM: Registering ACPI NVS region [mem 0x7f6df000-0x7f7defff]
(1048576 bytes)
[    1.175314] Grant tables using version 2 layout.
[    1.175394] Grant table initialized
[    1.175514] dummy:
[    1.175625] NET: Registered protocol family 16
[    1.175969] PCI: Using configuration type 1 for base access
[    1.176599] bio: create slab  at 0
[    1.176719] ACPI: Interpreter disabled.
[    1.176796] xen/balloon: Initialising balloon driver.
[    1.177620] xen-balloon: Initialising balloon driver.
[    1.177761] vgaarb: loaded
[    1.177860] PCI: Probing PCI hardware
[    1.177929] PCI: root bus 00: using default resources
[    1.177930] PCI: Probing PCI hardware (bus 00)
[    1.177954] PCI host bridge to bus 0000:00
[    1.178025] pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
[    1.178098] pci_bus 0000:00: root bus resource [mem
0x00000000-0xffffffffff]
[    1.178173] pci_bus 0000:00: No busn resource found for root bus, will
use [bus 00-ff]
[    1.178266] pci_bus 0000:00: busn_res: [bus 00-ff] is inserted under
domain [bus 00-ff]
[    1.178287] pci 0000:00:00.0: [8086:3406] type 00 class 0x060000
[    1.178389] pci 0000:00:00.0: PME# supported from D0 D3hot D3cold
[    1.178425] pci 0000:00:01.0: [8086:3408] type 01 class 0x060400
[    1.178532] pci 0000:00:01.0: PME# supported from D0 D3hot D3cold
[    1.178571] pci 0000:00:02.0: [8086:3409] type 01 class 0x060400
[    1.178678] pci 0000:00:02.0: PME# supported from D0 D3hot D3cold
[    1.178716] pci 0000:00:03.0: [8086:340a] type 01 class 0x060400
[    1.178824] pci 0000:00:03.0: PME# supported from D0 D3hot D3cold
[    1.178865] pci 0000:00:05.0: [8086:340c] type 01 class 0x060400
[    1.178973] pci 0000:00:05.0: PME# supported from D0 D3hot D3cold
[    1.179013] pci 0000:00:07.0: [8086:340e] type 01 class 0x060400
[    1.179121] pci 0000:00:07.0: PME# supported from D0 D3hot D3cold
[    1.179161] pci 0000:00:09.0: [8086:3410] type 01 class 0x060400
[    1.179269] pci 0000:00:09.0: PME# supported from D0 D3hot D3cold
[    1.179309] pci 0000:00:10.0: [8086:3425] type 00 class 0x080000
[    1.179434] pci 0000:00:10.1: [8086:3426] type 00 class 0x080000
[    1.179543] pci 0000:00:11.0: [8086:3427] type 00 class 0x080000
[    1.179668] pci 0000:00:11.1: [8086:3428] type 00 class 0x080000
[    1.179795] pci 0000:00:14.0: [8086:342e] type 00 class 0x080000
[    1.179919] pci 0000:00:14.1: [8086:3422] type 00 class 0x080000
[    1.180053] pci 0000:00:14.2: [8086:3423] type 00 class 0x080000
[    1.180172] pci 0000:00:14.3: [8086:3438] type 00 class 0x080000
[    1.180273] pci 0000:00:15.0: [8086:342f] type 00 class 0x080020
[    1.180387] pci 0000:00:16.0: [8086:3430] type 00 class 0x088000
[    1.180408] pci 0000:00:16.0: reg 10: [mem 0x97a00000-0x97a03fff 64bit]
[    1.180540] pci 0000:00:16.1: [8086:3431] type 00 class 0x088000
[    1.180561] pci 0000:00:16.1: reg 10: [mem 0x97a04000-0x97a07fff 64bit]
[    1.180693] pci 0000:00:16.2: [8086:3432] type 00 class 0x088000
[    1.180713] pci 0000:00:16.2: reg 10: [mem 0x97a08000-0x97a0bfff 64bit]
[    1.180845] pci 0000:00:16.3: [8086:3433] type 00 class 0x088000
[    1.180866] pci 0000:00:16.3: reg 10: [mem 0x97a0c000-0x97a0ffff 64bit]
[    1.180997] pci 0000:00:16.4: [8086:3429] type 00 class 0x088000
[    1.181018] pci 0000:00:16.4: reg 10: [mem 0x97a10000-0x97a13fff 64bit]
[    1.181150] pci 0000:00:16.5: [8086:342a] type 00 class 0x088000
[    1.181170] pci 0000:00:16.5: reg 10: [mem 0x97a14000-0x97a17fff 64bit]
[    1.181302] pci 0000:00:16.6: [8086:342b] type 00 class 0x088000
[    1.181323] pci 0000:00:16.6: reg 10: [mem 0x97a18000-0x97a1bfff 64bit]
[    1.181455] pci 0000:00:16.7: [8086:342c] type 00 class 0x088000
[    1.181475] pci 0000:00:16.7: reg 10: [mem 0x97a1c000-0x97a1ffff 64bit]
[    1.181610] pci 0000:00:1a.0: [8086:3a37] type 00 class 0x0c0300
[    1.181681] pci 0000:00:1a.0: reg 20: [io  0x20a0-0x20bf]
[    1.181766] pci 0000:00:1a.1: [8086:3a38] type 00 class 0x0c0300
[    1.181837] pci 0000:00:1a.1: reg 20: [io  0x2080-0x209f]
[    1.181937] pci 0000:00:1a.7: [8086:3a3c] type 00 class 0x0c0320
[    1.181970] pci 0000:00:1a.7: reg 10: [mem 0x97a21000-0x97a213ff]
[    1.182116] pci 0000:00:1a.7: PME# supported from D0 D3hot D3cold
[    1.182153] pci 0000:00:1c.0: [8086:3a40] type 01 class 0x060400
[    1.182274] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
[    1.182316] pci 0000:00:1c.4: [8086:3a48] type 01 class 0x060400
[    1.182435] pci 0000:00:1c.4: PME# supported from D0 D3hot D3cold
[    1.182478] pci 0000:00:1d.0: [8086:3a34] type 00 class 0x0c0300
[    1.182549] pci 0000:00:1d.0: reg 20: [io  0x2060-0x207f]
[    1.182634] pci 0000:00:1d.1: [8086:3a35] type 00 class 0x0c0300
[    1.182705] pci 0000:00:1d.1: reg 20: [io  0x2040-0x205f]
[    1.182790] pci 0000:00:1d.2: [8086:3a36] type 00 class 0x0c0300
[    1.182860] pci 0000:00:1d.2: reg 20: [io  0x2020-0x203f]
[    1.182960] pci 0000:00:1d.7: [8086:3a3a] type 00 class 0x0c0320
[    1.182993] pci 0000:00:1d.7: reg 10: [mem 0x97a20000-0x97a203ff]
[    1.183138] pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold
[    1.183173] pci 0000:00:1e.0: [8086:244e] type 01 class 0x060401
[    1.183279] pci 0000:00:1f.0: [8086:3a18] type 00 class 0x060100
[    1.183458] pci 0000:00:1f.2: [8086:3a20] type 00 class 0x01018f
[    1.183484] pci 0000:00:1f.2: reg 10: [io  0x2118-0x211f]
[    1.183497] pci 0000:00:1f.2: reg 14: [io  0x212c-0x212f]
[    1.183510] pci 0000:00:1f.2: reg 18: [io  0x2110-0x2117]
[    1.183522] pci 0000:00:1f.2: reg 1c: [io  0x2128-0x212b]
[    1.183535] pci 0000:00:1f.2: reg 20: [io  0x20f0-0x20ff]
[    1.183548] pci 0000:00:1f.2: reg 24: [io  0x20e0-0x20ef]
[    1.183629] pci 0000:00:1f.3: [8086:3a30] type 00 class 0x0c0500
[    1.183653] pci 0000:00:1f.3: reg 10: [mem 0x97a22000-0x97a220ff 64bit]
[    1.183689] pci 0000:00:1f.3: reg 20: [io  0x2000-0x201f]
[    1.183746] pci 0000:00:1f.5: [8086:3a26] type 00 class 0x010185
[    1.183772] pci 0000:00:1f.5: reg 10: [io  0x2108-0x210f]
[    1.183784] pci 0000:00:1f.5: reg 14: [io  0x2124-0x2127]
[    1.183797] pci 0000:00:1f.5: reg 18: [io  0x2100-0x2107]
[    1.183816] pci 0000:00:1f.5: reg 1c: [io  0x2120-0x2123]
[    1.183829] pci 0000:00:1f.5: reg 20: [io  0x20d0-0x20df]
[    1.183841] pci 0000:00:1f.5: reg 24: [io  0x20c0-0x20cf]
[    1.183985] pci_bus 0000:0b: busn_res: [bus 0b-0f] is inserted under
[bus 00-ff]
[    1.184016] pci 0000:0b:00.0: [14e4:1639] type 00 class 0x020000
[    1.184040] pci 0000:0b:00.0: reg 10: [mem 0x92000000-0x93ffffff 64bit]
[    1.184181] pci 0000:0b:00.0: PME# supported from D0 D3hot D3cold
[    1.184224] pci 0000:0b:00.1: [14e4:1639] type 00 class 0x020000
[    1.184248] pci 0000:0b:00.1: reg 10: [mem 0x94000000-0x95ffffff 64bit]
[    1.184390] pci 0000:0b:00.1: PME# supported from D0 D3hot D3cold
[    1.191939] pci 0000:00:01.0: PCI bridge to [bus 0b-0f]
[    1.192017] pci 0000:00:01.0:   bridge window [mem 0x92000000-0x95ffffff=
]
[    1.192089] pci_bus 0000:10: busn_res: [bus 10-14] is inserted under
[bus 00-ff]
[    1.192093] pci 0000:00:02.0: PCI bridge to [bus 10-14]
[    1.192240] pci_bus 0000:15: busn_res: [bus 15-19] is inserted under
[bus 00-ff]
[    1.192244] pci 0000:00:03.0: PCI bridge to [bus 15-19]
[    1.192389] pci_bus 0000:1a: busn_res: [bus 1a-1e] is inserted under
[bus 00-ff]
[    1.192392] pci 0000:00:05.0: PCI bridge to [bus 1a-1e]
[    1.192539] pci_bus 0000:1f: busn_res: [bus 1f-23] is inserted under
[bus 00-ff]
[    1.192542] pci 0000:00:07.0: PCI bridge to [bus 1f-23]
[    1.192688] pci_bus 0000:24: busn_res: [bus 24-28] is inserted under
[bus 00-ff]
[    1.192691] pci 0000:00:09.0: PCI bridge to [bus 24-28]
[    1.192838] pci_bus 0000:01: busn_res: [bus 01-05] is inserted under
[bus 00-ff]
[    1.192863] pci 0000:01:00.0: [1000:0073] type 00 class 0x010400
[    1.192884] pci 0000:01:00.0: reg 10: [io  0x1000-0x10ff]
[    1.192908] pci 0000:01:00.0: reg 14: [mem 0x97940000-0x97943fff 64bit]
[    1.192932] pci 0000:01:00.0: reg 1c: [mem 0x97900000-0x9793ffff 64bit]
[    1.192962] pci 0000:01:00.0: reg 30: [mem 0xfffe0000-0xffffffff pref]
[    1.193060] pci 0000:01:00.0: supports D1 D2
[    1.200042] pci 0000:00:1c.0: PCI bridge to [bus 01-05]
[    1.200117] pci 0000:00:1c.0:   bridge window [io  0x1000-0x1fff]
[    1.200123] pci 0000:00:1c.0:   bridge window [mem 0x97900000-0x979fffff=
]
[    1.200196] pci_bus 0000:06: busn_res: [bus 06-0a] is inserted under
[bus 00-ff]
[    1.200228] pci 0000:06:00.0: [101b:0452] type 01 class 0x060400
[    1.200394] pci 0000:06:00.0: PME# supported from D0 D3hot D3cold
[    1.208144] pci 0000:00:1c.4: PCI bridge to [bus 06-0a]
[    1.208223] pci 0000:00:1c.4:   bridge window [mem 0x97000000-0x978fffff=
]
[    1.208231] pci 0000:00:1c.4:   bridge window [mem 0x96000000-0x96ffffff
64bit pref]
[    1.208330] pci_bus 0000:07: busn_res: [bus 07] is inserted under [bus
06-0a]
[    1.208353] pci 0000:07:00.0: [102b:0530] type 00 class 0x030000
[    1.208388] pci 0000:07:00.0: reg 10: [mem 0x96000000-0x96ffffff pref]
[    1.208407] pci 0000:07:00.0: reg 14: [mem 0x97800000-0x97803fff]
[    1.208427] pci 0000:07:00.0: reg 18: [mem 0x97000000-0x977fffff]
[    1.208633] pci 0000:06:00.0: PCI bridge to [bus 07]
[    1.208713] pci 0000:06:00.0:   bridge window [mem 0x97000000-0x978fffff=
]
[    1.208720] pci 0000:06:00.0:   bridge window [mem 0x96000000-0x96ffffff
pref]
[    1.208768] pci_bus 0000:29: busn_res: [bus 29-2d] is inserted under
[bus 00-ff]
[    1.208829] pci 0000:00:1e.0: PCI bridge to [bus 29-2d] (subtractive
decode)
[    1.208917] pci 0000:00:1e.0:   bridge window [io  0x0000-0xffff]
(subtractive decode)
[    1.208919] pci 0000:00:1e.0:   bridge window [mem
0x00000000-0xffffffffff] (subtractive decode)
[    1.208978] pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 2d
[    1.210287] vgaarb: device added:
PCI:0000:07:00.0,decodes=3Dio+mem,owns=3Dio+mem,locks=3Dnone
[    1.210898] PCI: pci_cache_line_size set to 64 bytes
[    1.211078] e820: reserve RAM buffer [mem 0x0006c000-0x0006ffff]
[    1.211080] e820: reserve RAM buffer [mem 0x0009f000-0x0009ffff]
[    1.211081] e820: reserve RAM buffer [mem 0x7acb7000-0x7bffffff]
[    1.211082] e820: reserve RAM buffer [mem 0x7d4f0000-0x7fffffff]
[    1.211086] e820: reserve RAM buffer [mem 0x7d53f000-0x7fffffff]
[    1.211088] e820: reserve RAM buffer [mem 0x7d704000-0x7fffffff]
[    1.211091] e820: reserve RAM buffer [mem 0x7f5ef000-0x7fffffff]
[    1.211093] e820: reserve RAM buffer [mem 0x7f800000-0x7fffffff]
[    1.211210] Switching to clocksource xen
[    1.212720] pnp: PnP ACPI: disabled
[    1.214391] pci 0000:01:00.0: no compatible bridge window for [mem
0xfffe0000-0xffffffff pref]
[    1.214569] pci 0000:00:1c.0: bridge window [mem 0x00100000-0x001fffff
pref] to [bus 01-05] add_size 200000
[    1.214613] pci 0000:00:1c.0: res[15]=3D[mem 0x00100000-0x001fffff pref]
get_res_add_size add_size 200000
[    1.214617] pci 0000:00:1c.0: BAR 15: assigned [mem
0x90000000-0x902fffff pref]
[    1.214708] pci 0000:00:01.0: PCI bridge to [bus 0b-0f]
[    1.214783] pci 0000:00:01.0:   bridge window [mem 0x92000000-0x95ffffff=
]
[    1.214865] pci 0000:00:02.0: PCI bridge to [bus 10-14]
[    1.214948] pci 0000:00:03.0: PCI bridge to [bus 15-19]
[    1.215032] pci 0000:00:05.0: PCI bridge to [bus 1a-1e]
[    1.215114] pci 0000:00:07.0: PCI bridge to [bus 1f-23]
[    1.215198] pci 0000:00:09.0: PCI bridge to [bus 24-28]
[    1.215282] pci 0000:01:00.0: BAR 6: assigned [mem 0x90000000-0x9001ffff
pref]
[    1.215383] pci 0000:00:1c.0: PCI bridge to [bus 01-05]
[    1.215456] pci 0000:00:1c.0:   bridge window [io  0x1000-0x1fff]
[    1.215532] pci 0000:00:1c.0:   bridge window [mem 0x97900000-0x979fffff=
]
[    1.215609] pci 0000:00:1c.0:   bridge window [mem 0x90000000-0x902fffff
pref]
[    1.215705] pci 0000:06:00.0: PCI bridge to [bus 07]
[    1.215782] pci 0000:06:00.0:   bridge window [mem 0x97000000-0x978fffff=
]
[    1.215860] pci 0000:06:00.0:   bridge window [mem 0x96000000-0x96ffffff
pref]
[    1.223235] pci 0000:00:1c.4: PCI bridge to [bus 06-0a]
[    1.223310] pci 0000:00:1c.4:   bridge window [mem 0x97000000-0x978fffff=
]
[    1.223391] pci 0000:00:1c.4:   bridge window [mem 0x96000000-0x96ffffff
64bit pref]
[    1.223489] pci 0000:00:1e.0: PCI bridge to [bus 29-2d]
[    1.223580] pci 0000:00:01.0: can't find IRQ for PCI INT A; please try
using pci=3Dbiosirq
[    1.223680] pci 0000:00:02.0: can't find IRQ for PCI INT A; please try
using pci=3Dbiosirq
[    1.223780] pci 0000:00:03.0: can't find IRQ for PCI INT A; please try
using pci=3Dbiosirq
[    1.223880] pci 0000:00:05.0: can't find IRQ for PCI INT A; please try
using pci=3Dbiosirq
[    1.223981] pci 0000:00:07.0: can't find IRQ for PCI INT A; please try
using pci=3Dbiosirq
[    1.224081] pci 0000:00:09.0: can't find IRQ for PCI INT A; please try
using pci=3Dbiosirq
[    1.224183] pci 0000:00:1c.0: can't find IRQ for PCI INT A; please try
using pci=3Dbiosirq
[    1.224283] pci 0000:00:1c.4: can't find IRQ for PCI INT A; please try
using pci=3Dbiosirq
[    1.224385] pci 0000:06:00.0: can't find IRQ for PCI INT A; please try
using pci=3Dbiosirq
[    1.224487] pci 0000:00:1e.0: setting latency timer to 64
[    1.224492] pci_bus 0000:00: resource 4 [io  0x0000-0xffff]
[    1.224494] pci_bus 0000:00: resource 5 [mem 0x00000000-0xffffffffff]
[    1.224496] pci_bus 0000:0b: resource 1 [mem 0x92000000-0x95ffffff]
[    1.224498] pci_bus 0000:01: resource 0 [io  0x1000-0x1fff]
[    1.224500] pci_bus 0000:01: resource 1 [mem 0x97900000-0x979fffff]
[    1.224502] pci_bus 0000:01: resource 2 [mem 0x90000000-0x902fffff pref]
[    1.224504] pci_bus 0000:06: resource 1 [mem 0x97000000-0x978fffff]
[    1.224507] pci_bus 0000:06: resource 2 [mem 0x96000000-0x96ffffff 64bit
pref]
[    1.224510] pci_bus 0000:07: resource 1 [mem 0x97000000-0x978fffff]
[    1.224512] pci_bus 0000:07: resource 2 [mem 0x96000000-0x96ffffff pref]
[    1.224514] pci_bus 0000:29: resource 4 [io  0x0000-0xffff]
[    1.224516] pci_bus 0000:29: resource 5 [mem 0x00000000-0xffffffffff]
[    1.224538] NET: Registered protocol family 2
[    1.225637] TCP established hash table entries: 524288 (order: 11,
8388608 bytes)
[    1.228185] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[    1.228521] TCP: Hash tables configured (established 524288 bind 65536)
[    1.228613] TCP: reno registered
[    1.228689] UDP hash table entries: 2048 (order: 4, 65536 bytes)
[    1.228785] UDP-Lite hash table entries: 2048 (order: 4, 65536 bytes)
[    1.228922] NET: Registered protocol family 1
[    1.229073] pci 0000:00:1a.0: can't find IRQ for PCI INT A; please try
using pci=3Dbiosirq
[    1.229201] pci 0000:00:1a.1: can't find IRQ for PCI INT B; please try
using pci=3Dbiosirq
[    1.229325] pci 0000:00:1a.7: can't find IRQ for PCI INT C; please try
using pci=3Dbiosirq
[    1.229466] pci 0000:00:1d.0: can't find IRQ for PCI INT A; please try
using pci=3Dbiosirq
[    1.229588] pci 0000:00:1d.1: can't find IRQ for PCI INT B; please try
using pci=3Dbiosirq
[    1.229708] pci 0000:00:1d.2: can't find IRQ for PCI INT C; please try
using pci=3Dbiosirq
[    1.229836] pci 0000:00:1d.7: can't find IRQ for PCI INT A; please try
using pci=3Dbiosirq
[    1.229986] pci 0000:07:00.0: Boot video device
[    1.229991] PCI: CLS 64 bytes, default 64
[    1.230040] Unpacking initramfs...
[    1.236939] Freeing initrd memory: 7188k freed
[    1.238401] platform rtc_cmos: registered platform RTC device (no PNP
device found)
[    1.238695] audit: initializing netlink socket (disabled)
[    1.238779] type=3D2000 audit(1349925915.231:1): initialized
[    1.253042] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[    1.253247] VFS: Disk quotas dquot_6.5.2
[    1.253330] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    1.253465] msgmni has been set to 7465
[    1.253646] alg: No test for stdrng (krng)
[    1.253730] Block layer SCSI generic (bsg) driver version 0.4 loaded
(major 252)
[    1.253820] io scheduler noop registered
[    1.253888] io scheduler deadline registered
[    1.253960] io scheduler cfq registered (default)
[    1.254124] pcieport 0000:00:01.0: device [8086:3408] has invalid IRQ;
check vendor BIOS
[    1.254277] pcieport 0000:00:02.0: device [8086:3409] has invalid IRQ;
check vendor BIOS
[    1.254425] pcieport 0000:00:03.0: device [8086:340a] has invalid IRQ;
check vendor BIOS
[    1.254573] pcieport 0000:00:05.0: device [8086:340c] has invalid IRQ;
check vendor BIOS
[    1.254723] pcieport 0000:00:07.0: device [8086:340e] has invalid IRQ;
check vendor BIOS
[    1.254870] pcieport 0000:00:09.0: device [8086:3410] has invalid IRQ;
check vendor BIOS
[    1.255019] pcieport 0000:00:1c.0: device [8086:3a40] has invalid IRQ;
check vendor BIOS
[    1.255170] pcieport 0000:00:1c.4: device [8086:3a48] has invalid IRQ;
check vendor BIOS
[    1.255389] ioapic: probe of 0000:00:15.0 failed with error -22
[    1.255467] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[    1.255554] pciehp: PCI Express Hot Plug Controller Driver version: 0.4
[    1.255627] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
[    1.255752] intel_idle: does not run on family 6 model 44
[    1.255833] Event-channel device installed.
[    1.255989] xen-pciback: backend is vpci
[    1.256298] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    1.277599] serial8250: ttyS0 at I/O 0x3f8 (irq =3D 4) is a 16550A
[    1.298917] serial8250: ttyS1 at I/O 0x2f8 (irq =3D 3) is a 16550A
[    1.299221] Linux agpgart interface v0.103
[    1.299387] i8042: PNP: No PS/2 controller found. Probing ports directly=
.
[    1.551430] serio: i8042 KBD port at 0x60,0x64 irq 1
[    1.551580] mousedev: PS/2 mouse device common for all mice
[    1.551800] rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0
[    1.551897] rtc0: alarms up to one day, 114 bytes nvram
[    1.551972] EFI Variables Facility v0.08 2004-May-17
[    1.552053] drop_monitor: Initializing network drop monitor service
[    1.552197] TCP: cubic registered
[    1.552276] NET: Registered protocol family 10
[    1.552496] mip6: Mobile IPv6
[    1.552564] NET: Registered protocol family 17
[    1.552641] Key type dns_resolver registered
[    1.552859] PM: Hibernation image not present or could not be loaded.
[    1.552868] registered taskstats version 1
[    1.553635] rtc_cmos rtc_cmos: setting system clock to 2012-10-11
03:25:15 UTC (1349925915)
[    1.553954] Freeing unused kernel memory: 592k freed
[    1.554130] Write protecting the kernel read-only data: 6144k
[    1.555798] Freeing unused kernel memory: 512k freed
[    1.556107] Freeing unused kernel memory: 620k freed
[    1.583588] udevd[50]: starting version 175
[    1.657119] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[    1.663281] SCSI subsystem initialized
[    1.681024] megasas: 00.00.06.15-rc1 Mon. Mar. 19 17:00:00 PDT 2012
[    1.681111] megasas: 0x1000:0x0073:0x1014:0x03b1: bus 1:slot 0:func 0
[    1.681241] megaraid_sas 0000:01:00.0: can't find IRQ for PCI INT A;
please try using pci=3Dbiosirq
[    1.687892] megasas: FW now in Ready state
[    1.735350] megasas_init_mfi: fw_support_ieee=3D67108864
[    1.735407] megasas: INIT adapter done
[    1.807365] scsi0 : LSI SAS based MegaRAID driver
[    1.808799] scsi 0:0:8:0: Direct-Access     IBM-ESXS ST9146803SS
 B53C PQ: 0 ANSI: 5
[    1.811249] scsi 0:0:9:0: Direct-Access     ATA      ST9500620NS
 BE24 PQ: 0 ANSI: 5
[    1.812739] scsi 0:0:10:0: Direct-Access     ATA      ST9500620NS
 BE24 PQ: 0 ANSI: 5
[    1.824208] scsi 0:2:0:0: Direct-Access     IBM      ServeRAID M1015
 2.12 PQ: 0 ANSI: 5
[    1.839755] sd 0:2:0:0: [sdb] 1949216768 512-byte logical blocks: (997
GB/929 GiB)
[    1.840060] sd 0:2:0:0: [sdb] Write Protect is off
[    1.840141] sd 0:2:0:0: [sdb] Mode Sense: 1f 00 10 08
[    1.840153] sd 0:0:8:0: [sda] 286748000 512-byte logical blocks: (146
GB/136 GiB)
[    1.840302] sd 0:2:0:0: [sdb] Write cache: disabled, read cache:
disabled, supports DPO and FUA
[    1.842564] sd 0:0:8:0: [sda] Write Protect is off
[    1.842637] sd 0:0:8:0: [sda] Mode Sense: c3 00 10 08
[    1.843418]  sdb: sdb1
[    1.843898] sd 0:0:8:0: [sda] Write cache: disabled, read cache:
enabled, supports DPO and FUA
[    1.844117] sd 0:2:0:0: [sdb] Attached SCSI disk
[    1.866028]  sda: sda1 sda2 sda3 sda4
[    1.870498] sd 0:0:8:0: [sda] Attached SCSI disk
[    2.053157] device-mapper: uevent: version 1.0.3
[    2.053610] device-mapper: ioctl: 4.23.0-ioctl (2012-07-25) initialised:
dm-devel@redhat.com
[    2.214131] EXT4-fs (dm-0): mounted filesystem with ordered data mode.
Opts: (null)
[    3.162111] udevd[298]: starting version 175
[    3.419449] bnx2: Broadcom NetXtreme II Gigabit Ethernet Driver bnx2
v2.2.3 (June 27, 2012)
[    3.419565] bnx2 0000:0b:00.0: can't find IRQ for PCI INT A; please try
using pci=3Dbiosirq
[    3.420241] bnx2 0000:0b:00.0: eth0: Broadcom NetXtreme II BCM5709
1000Base-T (C0) PCI Express found at mem 92000000, IRQ 0, node addr
34:40:b5:ab:e5:b4
[    3.421062] bnx2 0000:0b:00.1: can't find IRQ for PCI INT B; please try
using pci=3Dbiosirq
[    3.421705] bnx2 0000:0b:00.1: eth1: Broadcom NetXtreme II BCM5709
1000Base-T (C0) PCI Express found at mem 94000000, IRQ 0, node addr
34:40:b5:ab:e5:b6
[    3.428805] dca service started, version 1.12.1
[    3.467169] EDAC MC: Ver: 3.0.0
[    3.473824] ioatdma: Intel(R) QuickData Technology Driver 4.00
[    3.473918] ioatdma 0000:00:16.0: enabling device (0000 -> 0002)
[    3.473996] ioatdma 0000:00:16.0: can't find IRQ for PCI INT A; please
try using pci=3Dbiosirq
[    3.474116] ioatdma 0000:00:16.0: channel error register unreachable
[    3.474191] ioatdma 0000:00:16.0: channel enumeration error
[    3.505302] microcode: CPU0 sig=3D0x206c2, pf=3D0x1, revision=3D0x15
[    3.505995] ioatdma 0000:00:16.0: Intel(R) I/OAT DMA Engine init failed
[    3.506096] ioatdma 0000:00:16.1: enabling device (0000 -> 0002)
[    3.506173] ioatdma 0000:00:16.1: can't find IRQ for PCI INT B; please
try using pci=3Dbiosirq
[    3.506296] ioatdma 0000:00:16.1: channel error register unreachable
[    3.506369] ioatdma 0000:00:16.1: channel enumeration error
[    3.506441] ioatdma 0000:00:16.1: Intel(R) I/OAT DMA Engine init failed
[    3.506532] ioatdma 0000:00:16.2: enabling device (0000 -> 0002)
[    3.506608] ioatdma 0000:00:16.2: can't find IRQ for PCI INT C; please
try using pci=3Dbiosirq
[    3.506722] ioatdma 0000:00:16.2: channel error register unreachable
[    3.506795] ioatdma 0000:00:16.2: channel enumeration error
[    3.506867] ioatdma 0000:00:16.2: Intel(R) I/OAT DMA Engine init failed
[    3.506957] ioatdma 0000:00:16.3: enabling device (0000 -> 0002)
[    3.507034] ioatdma 0000:00:16.3: can't find IRQ for PCI INT D; please
try using pci=3Dbiosirq
[    3.507147] ioatdma 0000:00:16.3: channel error register unreachable
[    3.507222] ioatdma 0000:00:16.3: channel enumeration error
[    3.507294] ioatdma 0000:00:16.3: Intel(R) I/OAT DMA Engine init failed
[    3.507398] ioatdma 0000:00:16.4: enabling device (0000 -> 0002)
[    3.507476] ioatdma 0000:00:16.4: can't find IRQ for PCI INT A; please
try using pci=3Dbiosirq
[    3.507590] ioatdma 0000:00:16.4: channel error register unreachable
[    3.507663] ioatdma 0000:00:16.4: channel enumeration error
[    3.507735] ioatdma 0000:00:16.4: Intel(R) I/OAT DMA Engine init failed
[    3.507826] ioatdma 0000:00:16.5: enabling device (0000 -> 0002)
[    3.507903] ioatdma 0000:00:16.5: can't find IRQ for PCI INT B; please
try using pci=3Dbiosirq
[    3.508016] ioatdma 0000:00:16.5: channel error register unreachable
[    3.508090] ioatdma 0000:00:16.5: channel enumeration error
[    3.508162] ioatdma 0000:00:16.5: Intel(R) I/OAT DMA Engine init failed
[    3.508255] ioatdma 0000:00:16.6: enabling device (0000 -> 0002)
[    3.508337] ioatdma 0000:00:16.6: can't find IRQ for PCI INT C; please
try using pci=3Dbiosirq
[    3.508454] ioatdma 0000:00:16.6: channel error register unreachable
[    3.508529] ioatdma 0000:00:16.6: channel enumeration error
[    3.508601] ioatdma 0000:00:16.6: Intel(R) I/OAT DMA Engine init failed
[    3.508692] ioatdma 0000:00:16.7: enabling device (0000 -> 0002)
[    3.508769] ioatdma 0000:00:16.7: can't find IRQ for PCI INT D; please
try using pci=3Dbiosirq
[    3.508885] ioatdma 0000:00:16.7: channel error register unreachable
[    3.508958] ioatdma 0000:00:16.7: channel enumeration error
[    3.509030] ioatdma 0000:00:16.7: Intel(R) I/OAT DMA Engine init failed
[    3.571248] usbcore: registered new interface driver usbfs
[    3.571330] usbcore: registered new interface driver hub
[    3.585483] ACPI Exception: AE_BAD_PARAMETER, Thread 1786484928 could
not acquire Mutex [0x1] (20120711/utmutex-276)
[    3.585675] ACPI Exception: AE_BAD_PARAMETER, Thread 1786484928 could
not acquire Mutex [0x1] (20120711/utmutex-276)
[    3.590919] usbcore: registered new device driver usb
[    3.603433] input: PC Speaker as /devices/platform/pcspkr/input/input0
[    3.604762] libata version 3.00 loaded.
[    3.607430] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    3.607535] ehci_hcd 0000:00:1a.7: can't find IRQ for PCI INT C; please
try using pci=3Dbiosirq
[    3.607629] ehci_hcd 0000:00:1a.7: Found HC with no IRQ.  Check BIOS/PCI
0000:00:1a.7 setup!
[    3.607723] ehci_hcd 0000:00:1a.7: init 0000:00:1a.7 fail, -19
[    3.607808] ehci_hcd 0000:00:1d.7: can't find IRQ for PCI INT A; please
try using pci=3Dbiosirq
[    3.607900] ehci_hcd 0000:00:1d.7: Found HC with no IRQ.  Check BIOS/PCI
0000:00:1d.7 setup!
[    3.607994] ehci_hcd 0000:00:1d.7: init 0000:00:1d.7 fail, -19
[    3.623701] i801_smbus 0000:00:1f.3: enabling device (0140 -> 0143)
[    3.623781] i801_smbus 0000:00:1f.3: can't find IRQ for PCI INT B;
please try using pci=3Dbiosirq
[    3.623874] ACPI Exception: AE_BAD_PARAMETER, Thread 1775910976 could
not acquire Mutex [0x1] (20120711/utmutex-276)
[    3.624093] i801_smbus 0000:00:1f.3: SMBus using PCI Interrupt
[    3.676083] ata_piix 0000:00:1f.2: version 2.13
[    3.676095] ata_piix 0000:00:1f.2: can't find IRQ for PCI INT A; please
try using pci=3Dbiosirq
[    3.676193] ata_piix 0000:00:1f.2: MAP [
[    3.676260]  P0 P2 P1 P3 ]
[    3.676539] ata_piix 0000:00:1f.2: setting latency timer to 64
[    3.677344] scsi1 : ata_piix
[    3.677732] scsi2 : ata_piix
[    3.677862] ata1: SATA max UDMA/133 cmd 0x2118 ctl 0x212c bmdma 0x20f0
[    3.677954] ata2: SATA max UDMA/133 cmd 0x2110 ctl 0x2128 bmdma 0x20f8
[    3.678154] gpio_ich: GPIO from 195 to 255 on gpio_ich
[    3.678606] ata_piix 0000:00:1f.5: can't find IRQ for PCI INT C; please
try using pci=3Dbiosirq
[    3.678703] ata_piix 0000:00:1f.5: MAP [
[    3.678771]  P0 -- P1 -- ]
[    3.679046] ata_piix 0000:00:1f.5: setting latency timer to 64
[    3.679562] scsi3 : ata_piix
[    3.680057] uhci_hcd: USB Universal Host Controller Interface driver
[    3.682601] scsi4 : ata_piix
[    3.682814] ata3: SATA max UDMA/133 cmd 0x2108 ctl 0x2124 bmdma 0x20d0
[    3.682893] ata4: SATA max UDMA/133 cmd 0x2100 ctl 0x2120 bmdma 0x20d8
[    3.683028] uhci_hcd 0000:00:1a.0: can't find IRQ for PCI INT A; please
try using pci=3Dbiosirq
[    3.683123] uhci_hcd 0000:00:1a.0: Found HC with no IRQ.  Check BIOS/PCI
0000:00:1a.0 setup!
[    3.683217] uhci_hcd 0000:00:1a.0: init 0000:00:1a.0 fail, -19
[    3.683300] uhci_hcd 0000:00:1a.1: can't find IRQ for PCI INT B; please
try using pci=3Dbiosirq
[    3.683408] uhci_hcd 0000:00:1a.1: Found HC with no IRQ.  Check BIOS/PCI
0000:00:1a.1 setup!
[    3.683504] uhci_hcd 0000:00:1a.1: init 0000:00:1a.1 fail, -19
[    3.683588] uhci_hcd 0000:00:1d.0: can't find IRQ for PCI INT A; please
try using pci=3Dbiosirq
[    3.683682] uhci_hcd 0000:00:1d.0: Found HC with no IRQ.  Check BIOS/PCI
0000:00:1d.0 setup!
[    3.683802] uhci_hcd 0000:00:1d.0: init 0000:00:1d.0 fail, -19
[    3.683933] uhci_hcd 0000:00:1d.1: can't find IRQ for PCI INT B; please
try using pci=3Dbiosirq
[    3.684026] uhci_hcd 0000:00:1d.1: Found HC with no IRQ.  Check BIOS/PCI
0000:00:1d.1 setup!
[    3.684121] uhci_hcd 0000:00:1d.1: init 0000:00:1d.1 fail, -19
[    3.684201] uhci_hcd 0000:00:1d.2: can't find IRQ for PCI INT C; please
try using pci=3Dbiosirq
[    3.684293] uhci_hcd 0000:00:1d.2: Found HC with no IRQ.  Check BIOS/PCI
0000:00:1d.2 setup!
[    3.684387] uhci_hcd 0000:00:1d.2: init 0000:00:1d.2 fail, -19
[    3.751594] microcode: Microcode Update Driver: v2.00 <
tigran@aivazian.fsnet.co.uk>, Peter Oruba
[    3.771183] iTCO_vendor_support: vendor-support=3D0
[    4.010635] ata3: SATA link down (SStatus 0 SControl 300)
[    4.022013] ata4: SATA link down (SStatus 0 SControl 300)
[    4.342660] ata2.00: SATA link down (SStatus 0 SControl 300)
[    4.342751] ata2.01: SATA link down (SStatus 0 SControl 300)
[    4.487426] ata1.00: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[    4.487519] ata1.01: SATA link down (SStatus 0 SControl 300)
[    4.487603] ata1.01: link offline, clearing class 3 to NONE
[    4.495491] ata1.00: ATAPI: IBM SATA DEVICE 81Y3657, IB01, max UDMA/33
[    4.511489] ata1.00: configured for UDMA/33
[    9.511364] ata1.00: qc timeout (cmd 0xa0)
[    9.511434] ata1.00: TEST_UNIT_READY failed (err_mask=3D0x5)
[   10.307422] ata1.00: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   10.307515] ata1.01: SATA link down (SStatus 0 SControl 300)
[   10.307600] ata1.01: link offline, clearing class 3 to NONE
[   10.331487] ata1.00: configured for UDMA/33
[   15.331361] ata1.00: qc timeout (cmd 0xa0)
[   15.331431] ata1.00: TEST_UNIT_READY failed (err_mask=3D0x5)
[   15.331504] ata1.00: limiting SATA link speed to 1.5 Gbps
[   15.331574] ata1.00: limiting speed to UDMA/33:PIO3
[   16.127423] ata1.00: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[   16.127515] ata1.01: SATA link down (SStatus 0 SControl 300)
[   16.127601] ata1.01: link offline, clearing class 3 to NONE
[   16.151487] ata1.00: configured for UDMA/33
[   21.151378] ata1.00: qc timeout (cmd 0xa0)
[   21.151448] ata1.00: TEST_UNIT_READY failed (err_mask=3D0x5)
[   21.151518] ata1.00: disabled
[   21.151603] ata1.00: hard resetting link
[   21.471351] ata1.01: hard resetting link
[   21.947430] ata1.00: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[   21.947523] ata1.01: SATA link down (SStatus 0 SControl 300)
[   21.947608] ata1.01: link offline, clearing class 3 to NONE
[   21.947611] ata1: EH complete
[   21.963868] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.10
[   21.963965] iTCO_wdt: Found a ICH10 TCO device (Version=3D2,
TCOBASE=3D0x05e0)
[   21.964124] iTCO_wdt: initialized. heartbeat=3D30 sec (nowayout=3D0)
[   21.997872] Error: Driver 'pcspkr' is already registered, aborting...
[   22.010315] alg: No test for __gcm-aes-aesni (__driver-gcm-aes-aesni)
[   22.995255] EXT4-fs (dm-0): re-mounted. Opts: (null)
[   23.177611] EXT4-fs (dm-0): re-mounted. Opts: errors=3Dremount-ro
[   23.281974] loop: module loaded
[   23.346661] lp: driver loaded but no devices found
[   24.043404] Adding 4194300k swap on /dev/mapper/xen-fw_swap.
 Priority:-1 extents:1 across:4194300k
[   24.347072] EXT4-fs (sda3): mounted filesystem with ordered data mode.
Opts: (null)
[   24.386139] FAT-fs (sda2): utf8 is not a recommended IO charset for FAT
filesystems, filesystem will be case sensitive!
[   25.140294] bnx2 0000:0b:00.0: eth0: using MSIX
[   25.140439] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   25.181911] Bridge firewalling registered
[   25.186131] device eth1 entered promiscuous mode
[   25.288312] bnx2 0000:0b:00.1: eth1: using MSIX
[   25.288410] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[   25.290413] IPv6: ADDRCONF(NETDEV_UP): xenbr0: link is not ready
[   26.898999] bnx2 0000:0b:00.0: eth0: NIC Copper Link is Up, 100 Mbps
full duplex
[   26.899091]
[   26.899222] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   28.981380] bnx2 0000:0b:00.1: eth1: NIC Copper Link is Up, 1000 Mbps
full duplex
[   28.981477]
[   28.981613] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[   28.981698] xenbr0: port 1(eth1) entered forwarding state
[   28.981771] xenbr0: port 1(eth1) entered forwarding state
[   28.981850] IPv6: ADDRCONF(NETDEV_CHANGE): xenbr0: link becomes ready
[   33.512189] RPC: Registered named UNIX socket transport module.
[   33.512281] RPC: Registered udp transport module.
[   33.512351] RPC: Registered tcp transport module.
[   33.512420] RPC: Registered tcp NFSv4.1 backchannel transport module.
[   33.533692] FS-Cache: Loaded
[   33.547314] FS-Cache: Netfs 'nfs' registered for caching
[   33.579870] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
[   34.845026] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
[   34.854870] ip_tables: (C) 2000-2006 Netfilter Core Team
[   35.475210] ppdev: user-space parallel port driver
[   39.140866] colord-sane[2701]: segfault at 0 ip 00007fc826bc4884 sp
00007fff6a44fea0 error 4 in libc-2.13.so[7fc826b1f000+17d000]
[   44.011341] xenbr0: port 1(eth1) entered forwarding state


Thanks for all,
Allan Scheid




--=20
*Att,*
*Allan Vicente Scheid*
*Acad=EAmico de Ci=EAncia da Computa=E7=E3o - Unioeste Foz*

--14dae934109feecd8704cbc0e07e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hellow all, i need help with this bug:
=

ACPI BIOS Bug: Error: A valid RSDP was not found (20120711/t=
bxfroot-219)

Because of this first errors i get th=
is second error, and it causes don't work USB ports and some PCI cards =
on the system:




can't find IRQ for PCI INT A; please try using pci=
=3Dbiosirq

This occours only when i try boot with =
xen multiboot (with hypervisor), if i boot only kernel with xen extensions =
no has errors in dmesg.



Kernel:=A03.6.1-xen self compiled (work perfect without=
 xen multiboot)
Xen Version: 4.2
Grub2 EFI: 1.99-23

Debian Unstable distro
Server: IBM System x3650 M3 7945AC1

dmesg output:

[ =A0 =
=A00.000000] Initializing cgroup subsys cpuset
[ =A0 =A00.000000]=
 Initializing cgroup subsys cpu


[ =A0 =A00.000000] Linux version 3.6.1-xen (root@lca-fw) (gcc version =
4.7.1 (Debian 4.7.1-7) ) #1 SMP Wed Oct 10 22:46:05 BRT 2012


[ =A0 =A00.000000] Command line: placeholder root=3D/dev/mapper/xen-fw=
_root ro
[ =A0 =A00.000000] Freeing 6c-6d pfn range: 1 pages free=
d
[ =A0 =A00.000000] 1-1 mapping on 6c->6d
[ =A0 =A0=
0.000000] Freeing 9f-100 pfn range: 97 pages freed



[ =A0 =A00.000000] 1-1 mapping on 9f->100
[ =A0 =A00.0000=
00] Freeing 7acb7-7ccb8 pfn range: 8193 pages freed
[ =A0 =A00.00=
0000] 1-1 mapping on 7acb7->7ccb8
[ =A0 =A00.000000] Freeing 7=
d4f0-7d51b pfn range: 43 pages freed



[ =A0 =A00.000000] 1-1 mapping on 7d4f0->7d51b
[ =A0 =A00=
.000000] Freeing 7d53f-7d56a pfn range: 43 pages freed
[ =A0 =A00=
.000000] 1-1 mapping on 7d53f->7d56a
[ =A0 =A00.000000] Freein=
g 7d704-7d7b4 pfn range: 176 pages freed



[ =A0 =A00.000000] 1-1 mapping on 7d704->7d7b4
[ =A0 =A00=
.000000] Freeing 7f5ef-7f7ff pfn range: 528 pages freed
[ =A0 =A0=
0.000000] 1-1 mapping on 7f5ef->7f7ff
[ =A0 =A00.000000] Freei=
ng 7f800-f258d pfn range: 470413 pages freed



[ =A0 =A00.000000] 1-1 mapping on 7f800->100000
[ =A0 =A0=
0.000000] Released 479494 pages of unused memory
[ =A0 =A00.00000=
0] Set 535417 page(s) to 1-1 mapping
[ =A0 =A00.000000] Populatin=
g 100000-175106 pfn range: 479494 pages added



[ =A0 =A00.000000] e820: BIOS-provided physical RAM map:
[ =
=A0 =A00.000000] Xen: [mem 0x0000000000000000-0x000000000006bfff] usable
[ =A0 =A00.000000] Xen: [mem 0x000000000006c000-0x000000000006cfff]=
 ACPI NVS



[ =A0 =A00.000000] Xen: [mem 0x000000000006d000-0x000000000009efff] us=
able
[ =A0 =A00.000000] Xen: [mem 0x000000000009f000-0x0000000000=
09ffff] ACPI NVS
[ =A0 =A00.000000] Xen: [mem 0x00000000000a0000-=
0x00000000000fffff] reserved



[ =A0 =A00.000000] Xen: [mem 0x0000000000100000-0x000000007acb6fff] us=
able
[ =A0 =A00.000000] Xen: [mem 0x000000007acb7000-0x000000007c=
cb7fff] reserved
[ =A0 =A00.000000] Xen: [mem 0x000000007ccb8000-=
0x000000007d4effff] usable



[ =A0 =A00.000000] Xen: [mem 0x000000007d4f0000-0x000000007d51afff] re=
served
[ =A0 =A00.000000] Xen: [mem 0x000000007d51b000-0x00000000=
7d53efff] usable
[ =A0 =A00.000000] Xen: [mem 0x000000007d53f000-=
0x000000007d569fff] reserved



[ =A0 =A00.000000] Xen: [mem 0x000000007d56a000-0x000000007d703fff] us=
able
[ =A0 =A00.000000] Xen: [mem 0x000000007d704000-0x000000007d=
7b3fff] reserved
[ =A0 =A00.000000] Xen: [mem 0x000000007d7b4000-=
0x000000007f5eefff] usable



[ =A0 =A00.000000] Xen: [mem 0x000000007f5ef000-0x000000007f6defff] re=
served
[ =A0 =A00.000000] Xen: [mem 0x000000007f6df000-0x00000000=
7f7defff] ACPI NVS
[ =A0 =A00.000000] Xen: [mem 0x000000007f7df00=
0-0x000000007f7fefff] ACPI data



[ =A0 =A00.000000] Xen: [mem 0x000000007f7ff000-0x000000007f7fffff] us=
able
[ =A0 =A00.000000] Xen: [mem 0x0000000080000000-0x000000008f=
ffffff] reserved
[ =A0 =A00.000000] Xen: [mem 0x00000000fed1c000-=
0x00000000fed1ffff] reserved



[ =A0 =A00.000000] Xen: [mem 0x00000000fee00000-0x00000000fee00fff] re=
served
[ =A0 =A00.000000] Xen: [mem 0x00000000ff800000-0x00000000=
ffffffff] reserved
[ =A0 =A00.000000] Xen: [mem 0x000000010000000=
0-0x000000017fffffff] usable



[ =A0 =A00.000000] NX (Execute Disable) protection: active
[=
 =A0 =A00.000000] DMI 2.5 present.
[ =A0 =A00.000000] DMI: IBM Sy=
stem x3650 M3 -[7945AC1]-/00D4062, BIOS -[D6E157AUS-1.15]- 06/13/2012
=

[ =A0 =A00.000000] e820: update [mem 0x00000000-0x0000ffff] usable =3D=
=3D> reserved



[ =A0 =A00.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[ =A0 =A00.000000] No AGP bridge found
[ =A0 =A00.000000] =
e820: last_pfn =3D 0x180000 max_arch_pfn =3D 0x400000000
[ =A0 =
=A00.000000] e820: last_pfn =3D 0x7f800 max_arch_pfn =3D 0x400000000



[ =A0 =A00.000000] initial memory mapped: [mem 0x00000000-0x02334fff]<=
/div>
[ =A0 =A00.000000] Base memory trampoline at [ffff880000099000] 9=
9000 size 24576
[ =A0 =A00.000000] init_memory_mapping: [mem 0x00=
000000-0x7f7fffff]



[ =A0 =A00.000000] =A0[mem 0x00000000-0x7f7fffff] page 4k
[ =
=A0 =A00.000000] kernel direct mapping tables up to 0x7f7fffff @ [mem 0x018=
31000-0x01c2ffff]
[ =A0 =A00.000000] xen: setting RW the range 1c=
14000 - 1c30000



[ =A0 =A00.000000] init_memory_mapping: [mem 0x100000000-0x17fffffff]<=
/div>
[ =A0 =A00.000000] =A0[mem 0x100000000-0x17fffffff] page 4k
=

[ =A0 =A00.000000] kernel direct mapping tables up to 0x17fffffff @ [m=
em 0x7e9e8000-0x7f5eefff]



[ =A0 =A00.000000] xen: setting RW the range 7edea000 - 7f5ef000
=

[ =A0 =A00.000000] RAMDISK: [mem 0x01c30000-0x02334fff]
[ =
=A0 =A00.000000] ACPI BIOS Bug: Error: A valid RSDP was not found (20120711=
/tbxfroot-219)



[ =A0 =A00.000000] NUMA turned off
[ =A0 =A00.000000] Faking=
 a node at [mem 0x0000000000000000-0x000000017fffffff]
[ =A0 =A00=
.000000] Initmem setup node 0 [mem 0x00000000-0x17fffffff]
[ =A0 =
=A00.000000] =A0 NODE_DATA [mem 0x175102000-0x175105fff]



[ =A0 =A00.000000] Zone ranges:
[ =A0 =A00.000000] =A0 DMA =
=A0 =A0 =A0[mem 0x00010000-0x00ffffff]
[ =A0 =A00.000000] =A0 DMA=
32 =A0 =A0[mem 0x01000000-0xffffffff]
[ =A0 =A00.000000] =A0 Norm=
al =A0 [mem 0x100000000-0x17fffffff]



[ =A0 =A00.000000] Movable zone start for each node
[ =A0 =
=A00.000000] Early memory node ranges
[ =A0 =A00.000000] =A0 node=
 =A0 0: [mem 0x00010000-0x0006bfff]
[ =A0 =A00.000000] =A0 node =
=A0 0: [mem 0x0006d000-0x0009efff]



[ =A0 =A00.000000] =A0 node =A0 0: [mem 0x00100000-0x7acb6fff]
[ =A0 =A00.000000] =A0 node =A0 0: [mem 0x7ccb8000-0x7d4effff]
[ =A0 =A00.000000] =A0 node =A0 0: [mem 0x7d51b000-0x7d53efff]
[=
 =A0 =A00.000000] =A0 node =A0 0: [mem 0x7d56a000-0x7d703fff]



[ =A0 =A00.000000] =A0 node =A0 0: [mem 0x7d7b4000-0x7f5eefff]
[ =A0 =A00.000000] =A0 node =A0 0: [mem 0x7f7ff000-0x7f7fffff]
[ =A0 =A00.000000] =A0 node =A0 0: [mem 0x100000000-0x17fffffff]
[ =A0 =A00.000000] On node 0 totalpages: 1037431



[ =A0 =A00.000000] =A0 DMA zone: 56 pages used for memmap
[ =
=A0 =A00.000000] =A0 DMA zone: 6 pages reserved
[ =A0 =A00.000000=
] =A0 DMA zone: 3920 pages, LIFO batch:0
[ =A0 =A00.000000] =A0 D=
MA32 zone: 14280 pages used for memmap



[ =A0 =A00.000000] =A0 DMA32 zone: 494881 pages, LIFO batch:31
[ =A0 =A00.000000] =A0 Normal zone: 7168 pages used for memmap
[ =A0 =A00.000000] =A0 Normal zone: 517120 pages, LIFO batch:31
=
[ =A0 =A00.000000] SFI: Simple Firmware Interface v0.81 http://simplefirmware.org



[ =A0 =A00.000000] smpboot: Allowing 1 CPUs, 0 hotplug CPUs
=
[ =A0 =A00.000000] nr_irqs_gsi: 16
[ =A0 =A00.000000] PM: Registe=
red nosave memory: 000000000006c000 - 000000000006d000
[ =A0 =A00=
.000000] PM: Registered nosave memory: 000000000009f000 - 00000000000a0000<=
/div>


[ =A0 =A00.000000] PM: Registered nosave memory: 00000000000a0000 - 00=
00000000100000
[ =A0 =A00.000000] PM: Registered nosave memory: 0=
00000007acb7000 - 000000007ccb8000
[ =A0 =A00.000000] PM: Registe=
red nosave memory: 000000007d4f0000 - 000000007d51b000



[ =A0 =A00.000000] PM: Registered nosave memory: 000000007d53f000 - 00=
0000007d56a000
[ =A0 =A00.000000] PM: Registered nosave memory: 0=
00000007d704000 - 000000007d7b4000
[ =A0 =A00.000000] PM: Registe=
red nosave memory: 000000007f5ef000 - 000000007f6df000



[ =A0 =A00.000000] PM: Registered nosave memory: 000000007f6df000 - 00=
0000007f7df000
[ =A0 =A00.000000] PM: Registered nosave memory: 0=
00000007f7df000 - 000000007f7ff000
[ =A0 =A00.000000] PM: Registe=
red nosave memory: 000000007f800000 - 0000000080000000



[ =A0 =A00.000000] PM: Registered nosave memory: 0000000080000000 - 00=
00000090000000
[ =A0 =A00.000000] PM: Registered nosave memory: 0=
000000090000000 - 00000000fed1c000
[ =A0 =A00.000000] PM: Registe=
red nosave memory: 00000000fed1c000 - 00000000fed20000



[ =A0 =A00.000000] PM: Registered nosave memory: 00000000fed20000 - 00=
000000fee00000
[ =A0 =A00.000000] PM: Registered nosave memory: 0=
0000000fee00000 - 00000000fee01000
[ =A0 =A00.000000] PM: Registe=
red nosave memory: 00000000fee01000 - 00000000ff800000



[ =A0 =A00.000000] PM: Registered nosave memory: 00000000ff800000 - 00=
00000100000000
[ =A0 =A00.000000] e820: [mem 0x90000000-0xfed1bff=
f] available for PCI devices
[ =A0 =A00.000000] Booting paravirtu=
alized kernel on Xen



[ =A0 =A00.000000] Xen version: 4.2.0 (preserve-AD)
[ =A0 =
=A00.000000] setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:1 nr_=
node_ids:1
[ =A0 =A00.000000] PERCPU: Embedded 28 pages/cpu @ffff=
880174e00000 s83840 r8192 d22656 u2097152



[ =A0 =A00.000000] pcpu-alloc: s83840 r8192 d22656 u2097152 alloc=3D1*=
2097152
[ =A0 =A00.000000] pcpu-alloc: [0] 0=A0
[ =A0 =
=A01.096975] Built 1 zonelists in Zone order, mobility grouping on. =A0Tota=
l pages: 1015921



[ =A0 =A01.096977] Policy zone: Normal
[ =A0 =A01.096979] Ke=
rnel command line: placeholder root=3D/dev/mapper/xen-fw_root ro
=
[ =A0 =A01.097016] PID hash table entries: 4096 (order: 3, 32768 bytes)
[ =A0 =A01.097021] __ex_table already sorted, skipping sort



[ =A0 =A01.121932] software IO TLB [mem 0x16c800000-0x1707fffff] (64MB=
) mapped at [ffff88016c800000-ffff8801707fffff]
[ =A0 =A01.138656=
] Memory: 3815116k/6291456k available (3573k kernel code, 2141732k absent, =
334608k reserved, 3147k data, 592k init)



[ =A0 =A01.138717] Hierarchical RCU implementation.
[ =A0 =
=A01.138718] 	RCU dyntick-idle =
grace-period acceleration is enabled.
[ =A0 =A01.138719] 	RCU restricting CPUs from NR_CPUS=3D51=
2 to nr_cpu_ids=3D1.



[ =A0 =A01.138728] NR_IRQS:33024 nr_irqs:256 16
[ =A0 =A01.1=
47171] Console: colour VGA+ 80x25
[ =A0 =A01.154296] console [tty=
0] enabled
[ =A0 =A01.159002] allocated 16777216 bytes of page_cg=
roup


[ =A0 =A01.159079] please try 'cgroup_disable=3Dmemory' option if y=
ou don't want memory cgroups
[ =A0 =A01.159208] Xen: using vc=
puop timer interface
[ =A0 =A01.159214] installing Xen timer for =
CPU 0



[ =A0 =A01.159303] tsc: Detected 2400.126 MHz processor
[ =
=A0 =A01.159375] Calibrating delay loop (skipped), value calculated using t=
imer frequency.. 4800.25 BogoMIPS (lpj=3D9600504)
[ =A0 =A01.1595=
17] pid_max: default: 32768 minimum: 301



[ =A0 =A01.159607] Security Framework initialized
[ =A0 =A01=
.159680] AppArmor: AppArmor disabled by boot time parameter
[ =A0=
 =A01.160298] Dentry cache hash table entries: 524288 (order: 10, 4194304 b=
ytes)



[ =A0 =A01.161752] Inode-cache hash table entries: 262144 (order: 9, 2=
097152 bytes)
[ =A0 =A01.162415] Mount-cache hash table entries: =
256
[ =A0 =A01.162658] Initializing cgroup subsys cpuacct
[ =A0 =A01.162729] Initializing cgroup subsys memory



[ =A0 =A01.162806] Initializing cgroup subsys devices
[ =A0 =
=A01.162876] Initializing cgroup subsys freezer
[ =A0 =A01.162945=
] Initializing cgroup subsys net_cls
[ =A0 =A01.163014] Initializ=
ing cgroup subsys blkio



[ =A0 =A01.163082] Initializing cgroup subsys perf_event
[ =
=A0 =A01.163204] CPU: Physical Processor ID: 0
[ =A0 =A01.163277]=
 CPU: Processor Core ID: 0
[ =A0 =A01.163346] mce: CPU supports 2=
 MCE banks



[ =A0 =A01.163452] Last level iTLB entries: 4KB 512, 2MB 7, 4MB 7
[ =A0 =A01.163452] Last level dTLB entries: 4KB 512, 2MB 32, 4MB 32
[ =A0 =A01.163452] tlb_flushall_shift is 0x6
[ =A0 =A01.=
163602] SMP alternatives: switching to UP code



[ =A0 =A01.171342] Freeing SMP alternatives: 8k freed
[ =A0 =
=A01.171471] Performance Events: unsupported p6 CPU model 44 no PMU driver,=
 software events only.
[ =A0 =A01.171785] NMI watchdog: disabled =
(cpu0): hardware events not enabled



[ =A0 =A01.171876] Brought up 1 CPUs
[ =A0 =A01.172058] devt=
mpfs: initialized
[ =A0 =A01.174970] PM: Registering ACPI NVS reg=
ion [mem 0x0006c000-0x0006cfff] (4096 bytes)
[ =A0 =A01.175062] P=
M: Registering ACPI NVS region [mem 0x0009f000-0x0009ffff] (4096 bytes)


[ =A0 =A01.175153] PM: Registering ACPI NVS region [mem 0x7f6df000-0x7=
f7defff] (1048576 bytes)
[ =A0 =A01.175314] Grant tables using ve=
rsion 2 layout.
[ =A0 =A01.175394] Grant table initialized
<=
div>[ =A0 =A01.175514] dummy:=A0



[ =A0 =A01.175625] NET: Registered protocol family 16
[ =A0 =
=A01.175969] PCI: Using configuration type 1 for base access
[ =
=A0 =A01.176599] bio: create slab <bio-0> at 0
[ =A0 =A01.1=
76719] ACPI: Interpreter disabled.



[ =A0 =A01.176796] xen/balloon: Initialising balloon driver.
[ =A0 =A01.177620] xen-balloon: Initialising balloon driver.
[ =
=A0 =A01.177761] vgaarb: loaded
[ =A0 =A01.177860] PCI: Probing P=
CI hardware



[ =A0 =A01.177929] PCI: root bus 00: using default resources
[ =A0 =A01.177930] PCI: Probing PCI hardware (bus 00)
[ =A0 =A01=
.177954] PCI host bridge to bus 0000:00
[ =A0 =A01.178025] pci_bu=
s 0000:00: root bus resource [io =A00x0000-0xffff]



[ =A0 =A01.178098] pci_bus 0000:00: root bus resource [mem 0x00000000-=
0xffffffffff]
[ =A0 =A01.178173] pci_bus 0000:00: No busn resourc=
e found for root bus, will use [bus 00-ff]
[ =A0 =A01.178266] pci=
_bus 0000:00: busn_res: [bus 00-ff] is inserted under domain [bus 00-ff]


[ =A0 =A01.178287] pci 0000:00:00.0: [8086:3406] type 00 class 0x06000=
0
[ =A0 =A01.178389] pci 0000:00:00.0: PME# supported from D0 D3h=
ot D3cold
[ =A0 =A01.178425] pci 0000:00:01.0: [8086:3408] type 0=
1 class 0x060400



[ =A0 =A01.178532] pci 0000:00:01.0: PME# supported from D0 D3hot D3co=
ld
[ =A0 =A01.178571] pci 0000:00:02.0: [8086:3409] type 01 class=
 0x060400
[ =A0 =A01.178678] pci 0000:00:02.0: PME# supported fro=
m D0 D3hot D3cold



[ =A0 =A01.178716] pci 0000:00:03.0: [8086:340a] type 01 class 0x06040=
0
[ =A0 =A01.178824] pci 0000:00:03.0: PME# supported from D0 D3h=
ot D3cold
[ =A0 =A01.178865] pci 0000:00:05.0: [8086:340c] type 0=
1 class 0x060400



[ =A0 =A01.178973] pci 0000:00:05.0: PME# supported from D0 D3hot D3co=
ld
[ =A0 =A01.179013] pci 0000:00:07.0: [8086:340e] type 01 class=
 0x060400
[ =A0 =A01.179121] pci 0000:00:07.0: PME# supported fro=
m D0 D3hot D3cold



[ =A0 =A01.179161] pci 0000:00:09.0: [8086:3410] type 01 class 0x06040=
0
[ =A0 =A01.179269] pci 0000:00:09.0: PME# supported from D0 D3h=
ot D3cold
[ =A0 =A01.179309] pci 0000:00:10.0: [8086:3425] type 0=
0 class 0x080000



[ =A0 =A01.179434] pci 0000:00:10.1: [8086:3426] type 00 class 0x08000=
0
[ =A0 =A01.179543] pci 0000:00:11.0: [8086:3427] type 00 class =
0x080000
[ =A0 =A01.179668] pci 0000:00:11.1: [8086:3428] type 00=
 class 0x080000



[ =A0 =A01.179795] pci 0000:00:14.0: [8086:342e] type 00 class 0x08000=
0
[ =A0 =A01.179919] pci 0000:00:14.1: [8086:3422] type 00 class =
0x080000
[ =A0 =A01.180053] pci 0000:00:14.2: [8086:3423] type 00=
 class 0x080000



[ =A0 =A01.180172] pci 0000:00:14.3: [8086:3438] type 00 class 0x08000=
0
[ =A0 =A01.180273] pci 0000:00:15.0: [8086:342f] type 00 class =
0x080020
[ =A0 =A01.180387] pci 0000:00:16.0: [8086:3430] type 00=
 class 0x088000



[ =A0 =A01.180408] pci 0000:00:16.0: reg 10: [mem 0x97a00000-0x97a03ff=
f 64bit]
[ =A0 =A01.180540] pci 0000:00:16.1: [8086:3431] type 00=
 class 0x088000
[ =A0 =A01.180561] pci 0000:00:16.1: reg 10: [mem=
 0x97a04000-0x97a07fff 64bit]



[ =A0 =A01.180693] pci 0000:00:16.2: [8086:3432] type 00 class 0x08800=
0
[ =A0 =A01.180713] pci 0000:00:16.2: reg 10: [mem 0x97a08000-0x=
97a0bfff 64bit]
[ =A0 =A01.180845] pci 0000:00:16.3: [8086:3433] =
type 00 class 0x088000



[ =A0 =A01.180866] pci 0000:00:16.3: reg 10: [mem 0x97a0c000-0x97a0fff=
f 64bit]
[ =A0 =A01.180997] pci 0000:00:16.4: [8086:3429] type 00=
 class 0x088000
[ =A0 =A01.181018] pci 0000:00:16.4: reg 10: [mem=
 0x97a10000-0x97a13fff 64bit]



[ =A0 =A01.181150] pci 0000:00:16.5: [8086:342a] type 00 class 0x08800=
0
[ =A0 =A01.181170] pci 0000:00:16.5: reg 10: [mem 0x97a14000-0x=
97a17fff 64bit]
[ =A0 =A01.181302] pci 0000:00:16.6: [8086:342b] =
type 00 class 0x088000



[ =A0 =A01.181323] pci 0000:00:16.6: reg 10: [mem 0x97a18000-0x97a1bff=
f 64bit]
[ =A0 =A01.181455] pci 0000:00:16.7: [8086:342c] type 00=
 class 0x088000
[ =A0 =A01.181475] pci 0000:00:16.7: reg 10: [mem=
 0x97a1c000-0x97a1ffff 64bit]



[ =A0 =A01.181610] pci 0000:00:1a.0: [8086:3a37] type 00 class 0x0c030=
0
[ =A0 =A01.181681] pci 0000:00:1a.0: reg 20: [io =A00x20a0-0x20=
bf]
[ =A0 =A01.181766] pci 0000:00:1a.1: [8086:3a38] type 00 clas=
s 0x0c0300



[ =A0 =A01.181837] pci 0000:00:1a.1: reg 20: [io =A00x2080-0x209f]
[ =A0 =A01.181937] pci 0000:00:1a.7: [8086:3a3c] type 00 class 0x0c0=
320
[ =A0 =A01.181970] pci 0000:00:1a.7: reg 10: [mem 0x97a21000-=
0x97a213ff]



[ =A0 =A01.182116] pci 0000:00:1a.7: PME# supported from D0 D3hot D3co=
ld
[ =A0 =A01.182153] pci 0000:00:1c.0: [8086:3a40] type 01 class=
 0x060400
[ =A0 =A01.182274] pci 0000:00:1c.0: PME# supported fro=
m D0 D3hot D3cold



[ =A0 =A01.182316] pci 0000:00:1c.4: [8086:3a48] type 01 class 0x06040=
0
[ =A0 =A01.182435] pci 0000:00:1c.4: PME# supported from D0 D3h=
ot D3cold
[ =A0 =A01.182478] pci 0000:00:1d.0: [8086:3a34] type 0=
0 class 0x0c0300



[ =A0 =A01.182549] pci 0000:00:1d.0: reg 20: [io =A00x2060-0x207f]
[ =A0 =A01.182634] pci 0000:00:1d.1: [8086:3a35] type 00 class 0x0c0=
300
[ =A0 =A01.182705] pci 0000:00:1d.1: reg 20: [io =A00x2040-0x=
205f]



[ =A0 =A01.182790] pci 0000:00:1d.2: [8086:3a36] type 00 class 0x0c0300
[ =A0 =A01.182860] pci 0000:00:1d.2: reg 20: [io =A00x2020-0x203f]
[ =A0 =A01.182960] pci 0000:00:1d.7: [8086:3a3a] type 00 class 0x0=
c0320



[ =A0 =A01.182993] pci 0000:00:1d.7: reg 10: [mem 0x97a20000-0x97a203f=
f]
[ =A0 =A01.183138] pci 0000:00:1d.7: PME# supported from D0 D3=
hot D3cold
[ =A0 =A01.183173] pci 0000:00:1e.0: [8086:244e] type =
01 class 0x060401



[ =A0 =A01.183279] pci 0000:00:1f.0: [8086:3a18] type 00 class 0x06010=
0
[ =A0 =A01.183458] pci 0000:00:1f.2: [8086:3a20] type 00 class =
0x01018f
[ =A0 =A01.183484] pci 0000:00:1f.2: reg 10: [io =A00x21=
18-0x211f]



[ =A0 =A01.183497] pci 0000:00:1f.2: reg 14: [io =A00x212c-0x212f]
[ =A0 =A01.183510] pci 0000:00:1f.2: reg 18: [io =A00x2110-0x2117]
[ =A0 =A01.183522] pci 0000:00:1f.2: reg 1c: [io =A00x2128-0x212b]=

[ =A0 =A01.183535] pci 0000:00:1f.2: reg 20: [io =A00x20f0-0x20f=
f]



[ =A0 =A01.183548] pci 0000:00:1f.2: reg 24: [io =A00x20e0-0x20ef]
[ =A0 =A01.183629] pci 0000:00:1f.3: [8086:3a30] type 00 class 0x0c0=
500
[ =A0 =A01.183653] pci 0000:00:1f.3: reg 10: [mem 0x97a22000-=
0x97a220ff 64bit]



[ =A0 =A01.183689] pci 0000:00:1f.3: reg 20: [io =A00x2000-0x201f]
[ =A0 =A01.183746] pci 0000:00:1f.5: [8086:3a26] type 00 class 0x010=
185
[ =A0 =A01.183772] pci 0000:00:1f.5: reg 10: [io =A00x2108-0x=
210f]



[ =A0 =A01.183784] pci 0000:00:1f.5: reg 14: [io =A00x2124-0x2127]
[ =A0 =A01.183797] pci 0000:00:1f.5: reg 18: [io =A00x2100-0x2107]
<=
div>[ =A0 =A01.183816] pci 0000:00:1f.5: reg 1c: [io =A00x2120-0x2123]
[ =A0 =A01.183829] pci 0000:00:1f.5: reg 20: [io =A00x20d0-0x20df]


[ =A0 =A01.183841] pci 0000:00:1f.5: reg 24: [io =A00x20c0-0x20cf]
[ =A0 =A01.183985] pci_bus 0000:0b: busn_res: [bus 0b-0f] is inserte=
d under [bus 00-ff]
[ =A0 =A01.184016] pci 0000:0b:00.0: [14e4:16=
39] type 00 class 0x020000



[ =A0 =A01.184040] pci 0000:0b:00.0: reg 10: [mem 0x92000000-0x93fffff=
f 64bit]
[ =A0 =A01.184181] pci 0000:0b:00.0: PME# supported from=
 D0 D3hot D3cold
[ =A0 =A01.184224] pci 0000:0b:00.1: [14e4:1639]=
 type 00 class 0x020000



[ =A0 =A01.184248] pci 0000:0b:00.1: reg 10: [mem 0x94000000-0x95fffff=
f 64bit]
[ =A0 =A01.184390] pci 0000:0b:00.1: PME# supported from=
 D0 D3hot D3cold
[ =A0 =A01.191939] pci 0000:00:01.0: PCI bridge =
to [bus 0b-0f]



[ =A0 =A01.192017] pci 0000:00:01.0: =A0 bridge window [mem 0x92000000=
-0x95ffffff]
[ =A0 =A01.192089] pci_bus 0000:10: busn_res: [bus 1=
0-14] is inserted under [bus 00-ff]
[ =A0 =A01.192093] pci 0000:0=
0:02.0: PCI bridge to [bus 10-14]



[ =A0 =A01.192240] pci_bus 0000:15: busn_res: [bus 15-19] is inserted =
under [bus 00-ff]
[ =A0 =A01.192244] pci 0000:00:03.0: PCI bridge=
 to [bus 15-19]
[ =A0 =A01.192389] pci_bus 0000:1a: busn_res: [bu=
s 1a-1e] is inserted under [bus 00-ff]



[ =A0 =A01.192392] pci 0000:00:05.0: PCI bridge to [bus 1a-1e]
[ =A0 =A01.192539] pci_bus 0000:1f: busn_res: [bus 1f-23] is inserted un=
der [bus 00-ff]
[ =A0 =A01.192542] pci 0000:00:07.0: PCI bridge t=
o [bus 1f-23]



[ =A0 =A01.192688] pci_bus 0000:24: busn_res: [bus 24-28] is inserted =
under [bus 00-ff]
[ =A0 =A01.192691] pci 0000:00:09.0: PCI bridge=
 to [bus 24-28]
[ =A0 =A01.192838] pci_bus 0000:01: busn_res: [bu=
s 01-05] is inserted under [bus 00-ff]



[ =A0 =A01.192863] pci 0000:01:00.0: [1000:0073] type 00 class 0x01040=
0
[ =A0 =A01.192884] pci 0000:01:00.0: reg 10: [io =A00x1000-0x10=
ff]
[ =A0 =A01.192908] pci 0000:01:00.0: reg 14: [mem 0x97940000-=
0x97943fff 64bit]



[ =A0 =A01.192932] pci 0000:01:00.0: reg 1c: [mem 0x97900000-0x9793fff=
f 64bit]
[ =A0 =A01.192962] pci 0000:01:00.0: reg 30: [mem 0xfffe=
0000-0xffffffff pref]
[ =A0 =A01.193060] pci 0000:01:00.0: suppor=
ts D1 D2



[ =A0 =A01.200042] pci 0000:00:1c.0: PCI bridge to [bus 01-05]
[ =A0 =A01.200117] pci 0000:00:1c.0: =A0 bridge window [io =A00x1000-0x1=
fff]
[ =A0 =A01.200123] pci 0000:00:1c.0: =A0 bridge window [mem =
0x97900000-0x979fffff]



[ =A0 =A01.200196] pci_bus 0000:06: busn_res: [bus 06-0a] is inserted =
under [bus 00-ff]
[ =A0 =A01.200228] pci 0000:06:00.0: [101b:0452=
] type 01 class 0x060400
[ =A0 =A01.200394] pci 0000:06:00.0: PME=
# supported from D0 D3hot D3cold



[ =A0 =A01.208144] pci 0000:00:1c.4: PCI bridge to [bus 06-0a]
[ =A0 =A01.208223] pci 0000:00:1c.4: =A0 bridge window [mem 0x97000000-0=
x978fffff]
[ =A0 =A01.208231] pci 0000:00:1c.4: =A0 bridge window=
 [mem 0x96000000-0x96ffffff 64bit pref]



[ =A0 =A01.208330] pci_bus 0000:07: busn_res: [bus 07] is inserted und=
er [bus 06-0a]
[ =A0 =A01.208353] pci 0000:07:00.0: [102b:0530] t=
ype 00 class 0x030000
[ =A0 =A01.208388] pci 0000:07:00.0: reg 10=
: [mem 0x96000000-0x96ffffff pref]



[ =A0 =A01.208407] pci 0000:07:00.0: reg 14: [mem 0x97800000-0x97803ff=
f]
[ =A0 =A01.208427] pci 0000:07:00.0: reg 18: [mem 0x97000000-0=
x977fffff]
[ =A0 =A01.208633] pci 0000:06:00.0: PCI bridge to [bu=
s 07]



[ =A0 =A01.208713] pci 0000:06:00.0: =A0 bridge window [mem 0x97000000=
-0x978fffff]
[ =A0 =A01.208720] pci 0000:06:00.0: =A0 bridge wind=
ow [mem 0x96000000-0x96ffffff pref]
[ =A0 =A01.208768] pci_bus 00=
00:29: busn_res: [bus 29-2d] is inserted under [bus 00-ff]



[ =A0 =A01.208829] pci 0000:00:1e.0: PCI bridge to [bus 29-2d] (subtra=
ctive decode)
[ =A0 =A01.208917] pci 0000:00:1e.0: =A0 bridge win=
dow [io =A00x0000-0xffff] (subtractive decode)
[ =A0 =A01.208919]=
 pci 0000:00:1e.0: =A0 bridge window [mem 0x00000000-0xffffffffff] (subtrac=
tive decode)



[ =A0 =A01.208978] pci_bus 0000:00: busn_res: [bus 00-ff] end is updat=
ed to 2d
[ =A0 =A01.210287] vgaarb: device added: PCI:0000:07:00.=
0,decodes=3Dio+mem,owns=3Dio+mem,locks=3Dnone
[ =A0 =A01.210898] =
PCI: pci_cache_line_size set to 64 bytes



[ =A0 =A01.211078] e820: reserve RAM buffer [mem 0x0006c000-0x0006ffff=
]
[ =A0 =A01.211080] e820: reserve RAM buffer [mem 0x0009f000-0x0=
009ffff]
[ =A0 =A01.211081] e820: reserve RAM buffer [mem 0x7acb7=
000-0x7bffffff]



[ =A0 =A01.211082] e820: reserve RAM buffer [mem 0x7d4f0000-0x7fffffff=
]
[ =A0 =A01.211086] e820: reserve RAM buffer [mem 0x7d53f000-0x7=
fffffff]
[ =A0 =A01.211088] e820: reserve RAM buffer [mem 0x7d704=
000-0x7fffffff]



[ =A0 =A01.211091] e820: reserve RAM buffer [mem 0x7f5ef000-0x7fffffff=
]
[ =A0 =A01.211093] e820: reserve RAM buffer [mem 0x7f800000-0x7=
fffffff]
[ =A0 =A01.211210] Switching to clocksource xen
[ =A0 =A01.212720] pnp: PnP ACPI: disabled



[ =A0 =A01.214391] pci 0000:01:00.0: no compatible bridge window for [=
mem 0xfffe0000-0xffffffff pref]
[ =A0 =A01.214569] pci 0000:00:1c=
.0: bridge window [mem 0x00100000-0x001fffff pref] to [bus 01-05] add_size =
200000



[ =A0 =A01.214613] pci 0000:00:1c.0: res[15]=3D[mem 0x00100000-0x001ff=
fff pref] get_res_add_size add_size 200000
[ =A0 =A01.214617] pci=
 0000:00:1c.0: BAR 15: assigned [mem 0x90000000-0x902fffff pref]
=
[ =A0 =A01.214708] pci 0000:00:01.0: PCI bridge to [bus 0b-0f]



[ =A0 =A01.214783] pci 0000:00:01.0: =A0 bridge window [mem 0x92000000=
-0x95ffffff]
[ =A0 =A01.214865] pci 0000:00:02.0: PCI bridge to [=
bus 10-14]
[ =A0 =A01.214948] pci 0000:00:03.0: PCI bridge to [bu=
s 15-19]



[ =A0 =A01.215032] pci 0000:00:05.0: PCI bridge to [bus 1a-1e]
[ =A0 =A01.215114] pci 0000:00:07.0: PCI bridge to [bus 1f-23]
[ =A0 =A01.215198] pci 0000:00:09.0: PCI bridge to [bus 24-28]
[=
 =A0 =A01.215282] pci 0000:01:00.0: BAR 6: assigned [mem 0x90000000-0x9001f=
fff pref]



[ =A0 =A01.215383] pci 0000:00:1c.0: PCI bridge to [bus 01-05]
[ =A0 =A01.215456] pci 0000:00:1c.0: =A0 bridge window [io =A00x1000-0x1=
fff]
[ =A0 =A01.215532] pci 0000:00:1c.0: =A0 bridge window [mem =
0x97900000-0x979fffff]



[ =A0 =A01.215609] pci 0000:00:1c.0: =A0 bridge window [mem 0x90000000=
-0x902fffff pref]
[ =A0 =A01.215705] pci 0000:06:00.0: PCI bridge=
 to [bus 07]
[ =A0 =A01.215782] pci 0000:06:00.0: =A0 bridge wind=
ow [mem 0x97000000-0x978fffff]



[ =A0 =A01.215860] pci 0000:06:00.0: =A0 bridge window [mem 0x96000000=
-0x96ffffff pref]
[ =A0 =A01.223235] pci 0000:00:1c.4: PCI bridge=
 to [bus 06-0a]
[ =A0 =A01.223310] pci 0000:00:1c.4: =A0 bridge w=
indow [mem 0x97000000-0x978fffff]



[ =A0 =A01.223391] pci 0000:00:1c.4: =A0 bridge window [mem 0x96000000=
-0x96ffffff 64bit pref]
[ =A0 =A01.223489] pci 0000:00:1e.0: PCI =
bridge to [bus 29-2d]
[ =A0 =A01.223580] pci 0000:00:01.0: can=
9;t find IRQ for PCI INT A; please try using pci=3Dbiosirq



[ =A0 =A01.223680] pci 0000:00:02.0: can't find IRQ for PCI INT A;=
 please try using pci=3Dbiosirq
[ =A0 =A01.223780] pci 0000:00:03=
.0: can't find IRQ for PCI INT A; please try using pci=3Dbiosirq
<=
div>[ =A0 =A01.223880] pci 0000:00:05.0: can't find IRQ for PCI INT A; =
please try using pci=3Dbiosirq



[ =A0 =A01.223981] pci 0000:00:07.0: can't find IRQ for PCI INT A;=
 please try using pci=3Dbiosirq
[ =A0 =A01.224081] pci 0000:00:09=
.0: can't find IRQ for PCI INT A; please try using pci=3Dbiosirq
<=
div>[ =A0 =A01.224183] pci 0000:00:1c.0: can't find IRQ for PCI INT A; =
please try using pci=3Dbiosirq



[ =A0 =A01.224283] pci 0000:00:1c.4: can't find IRQ for PCI INT A;=
 please try using pci=3Dbiosirq
[ =A0 =A01.224385] pci 0000:06:00=
.0: can't find IRQ for PCI INT A; please try using pci=3Dbiosirq
<=
div>[ =A0 =A01.224487] pci 0000:00:1e.0: setting latency timer to 64



[ =A0 =A01.224492] pci_bus 0000:00: resource 4 [io =A00x0000-0xffff]
[ =A0 =A01.224494] pci_bus 0000:00: resource 5 [mem 0x00000000-0xf=
fffffffff]
[ =A0 =A01.224496] pci_bus 0000:0b: resource 1 [mem 0x=
92000000-0x95ffffff]



[ =A0 =A01.224498] pci_bus 0000:01: resource 0 [io =A00x1000-0x1fff]
[ =A0 =A01.224500] pci_bus 0000:01: resource 1 [mem 0x97900000-0x9=
79fffff]
[ =A0 =A01.224502] pci_bus 0000:01: resource 2 [mem 0x90=
000000-0x902fffff pref]



[ =A0 =A01.224504] pci_bus 0000:06: resource 1 [mem 0x97000000-0x978ff=
fff]
[ =A0 =A01.224507] pci_bus 0000:06: resource 2 [mem 0x960000=
00-0x96ffffff 64bit pref]
[ =A0 =A01.224510] pci_bus 0000:07: res=
ource 1 [mem 0x97000000-0x978fffff]



[ =A0 =A01.224512] pci_bus 0000:07: resource 2 [mem 0x96000000-0x96fff=
fff pref]
[ =A0 =A01.224514] pci_bus 0000:29: resource 4 [io =A00=
x0000-0xffff]
[ =A0 =A01.224516] pci_bus 0000:29: resource 5 [mem=
 0x00000000-0xffffffffff]



[ =A0 =A01.224538] NET: Registered protocol family 2
[ =A0 =
=A01.225637] TCP established hash table entries: 524288 (order: 11, 8388608=
 bytes)
[ =A0 =A01.228185] TCP bind hash table entries: 65536 (or=
der: 8, 1048576 bytes)



[ =A0 =A01.228521] TCP: Hash tables configured (established 524288 bin=
d 65536)
[ =A0 =A01.228613] TCP: reno registered
[ =A0 =
=A01.228689] UDP hash table entries: 2048 (order: 4, 65536 bytes)
[ =A0 =A01.228785] UDP-Lite hash table entries: 2048 (order: 4, 65536 byte=
s)



[ =A0 =A01.228922] NET: Registered protocol family 1
[ =A0 =
=A01.229073] pci 0000:00:1a.0: can't find IRQ for PCI INT A; please try=
 using pci=3Dbiosirq
[ =A0 =A01.229201] pci 0000:00:1a.1: can'=
;t find IRQ for PCI INT B; please try using pci=3Dbiosirq



[ =A0 =A01.229325] pci 0000:00:1a.7: can't find IRQ for PCI INT C;=
 please try using pci=3Dbiosirq
[ =A0 =A01.229466] pci 0000:00:1d=
.0: can't find IRQ for PCI INT A; please try using pci=3Dbiosirq
<=
div>[ =A0 =A01.229588] pci 0000:00:1d.1: can't find IRQ for PCI INT B; =
please try using pci=3Dbiosirq



[ =A0 =A01.229708] pci 0000:00:1d.2: can't find IRQ for PCI INT C;=
 please try using pci=3Dbiosirq
[ =A0 =A01.229836] pci 0000:00:1d=
.7: can't find IRQ for PCI INT A; please try using pci=3Dbiosirq
<=
div>[ =A0 =A01.229986] pci 0000:07:00.0: Boot video device



[ =A0 =A01.229991] PCI: CLS 64 bytes, default 64
[ =A0 =A01.=
230040] Unpacking initramfs...
[ =A0 =A01.236939] Freeing initrd =
memory: 7188k freed
[ =A0 =A01.238401] platform rtc_cmos: registe=
red platform RTC device (no PNP device found)



[ =A0 =A01.238695] audit: initializing netlink socket (disabled)
=

[ =A0 =A01.238779] type=3D2000 audit(1349925915.231:1): initialized
[ =A0 =A01.253042] HugeTLB registered 2 MB page size, pre-allocated=
 0 pages



[ =A0 =A01.253247] VFS: Disk quotas dquot_6.5.2
[ =A0 =A01.2=
53330] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
=
[ =A0 =A01.253465] msgmni has been set to 7465
[ =A0 =A01.253646]=
 alg: No test for stdrng (krng)



[ =A0 =A01.253730] Block layer SCSI generic (bsg) driver version 0.4 l=
oaded (major 252)
[ =A0 =A01.253820] io scheduler noop registered=

[ =A0 =A01.253888] io scheduler deadline registered
[ =
=A0 =A01.253960] io scheduler cfq registered (default)



[ =A0 =A01.254124] pcieport 0000:00:01.0: device [8086:3408] has inval=
id IRQ; check vendor BIOS
[ =A0 =A01.254277] pcieport 0000:00:02.=
0: device [8086:3409] has invalid IRQ; check vendor BIOS
[ =A0 =
=A01.254425] pcieport 0000:00:03.0: device [8086:340a] has invalid IRQ; che=
ck vendor BIOS



[ =A0 =A01.254573] pcieport 0000:00:05.0: device [8086:340c] has inval=
id IRQ; check vendor BIOS
[ =A0 =A01.254723] pcieport 0000:00:07.=
0: device [8086:340e] has invalid IRQ; check vendor BIOS
[ =A0 =
=A01.254870] pcieport 0000:00:09.0: device [8086:3410] has invalid IRQ; che=
ck vendor BIOS



[ =A0 =A01.255019] pcieport 0000:00:1c.0: device [8086:3a40] has inval=
id IRQ; check vendor BIOS
[ =A0 =A01.255170] pcieport 0000:00:1c.=
4: device [8086:3a48] has invalid IRQ; check vendor BIOS
[ =A0 =
=A01.255389] ioapic: probe of 0000:00:15.0 failed with error -22



[ =A0 =A01.255467] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[ =A0 =A01.255554] pciehp: PCI Express Hot Plug Controller Driver ve=
rsion: 0.4
[ =A0 =A01.255627] acpiphp: ACPI Hot Plug PCI Controll=
er Driver version: 0.5



[ =A0 =A01.255752] intel_idle: does not run on family 6 model 44
=

[ =A0 =A01.255833] Event-channel device installed.
[ =A0 =A0=
1.255989] xen-pciback: backend is vpci
[ =A0 =A01.256298] Serial:=
 8250/16550 driver, 4 ports, IRQ sharing enabled



[ =A0 =A01.277599] serial8250: ttyS0 at I/O 0x3f8 (irq =3D 4) is a 165=
50A
[ =A0 =A01.298917] serial8250: ttyS1 at I/O 0x2f8 (irq =3D 3)=
 is a 16550A
[ =A0 =A01.299221] Linux agpgart interface v0.103
[ =A0 =A01.299387] i8042: PNP: No PS/2 controller found. Probing po=
rts directly.



[ =A0 =A01.551430] serio: i8042 KBD port at 0x60,0x64 irq 1
=
[ =A0 =A01.551580] mousedev: PS/2 mouse device common for all mice
[ =A0 =A01.551800] rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rt=
c0



[ =A0 =A01.551897] rtc0: alarms up to one day, 114 bytes nvram
[ =A0 =A01.551972] EFI Variables Facility v0.08 2004-May-17
[ =
=A0 =A01.552053] drop_monitor: Initializing network drop monitor service


[ =A0 =A01.552197] TCP: cubic registered
[ =A0 =A01.552276] NET: =
Registered protocol family 10
[ =A0 =A01.552496] mip6: Mobile IPv=
6
[ =A0 =A01.552564] NET: Registered protocol family 17
[ =A0 =A01.552641] Key type dns_resolver registered



[ =A0 =A01.552859] PM: Hibernation image not present or could not be l=
oaded.
[ =A0 =A01.552868] registered taskstats version 1
[ =A0 =A01.553635] rtc_cmos rtc_cmos: setting system clock to 2012-10-11 =
03:25:15 UTC (1349925915)



[ =A0 =A01.553954] Freeing unused kernel memory: 592k freed
=
[ =A0 =A01.554130] Write protecting the kernel read-only data: 6144k
<=
div>[ =A0 =A01.555798] Freeing unused kernel memory: 512k freed
[=
 =A0 =A01.556107] Freeing unused kernel memory: 620k freed



[ =A0 =A01.583588] udevd[50]: starting version 175
[ =A0 =A0=
1.657119] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[ =A0 =A01.663281] SCSI subsystem initialized
[ =A0 =A01.68=
1024] megasas: 00.00.06.15-rc1 Mon. Mar. 19 17:00:00 PDT 2012



[ =A0 =A01.681111] megasas: 0x1000:0x0073:0x1014:0x03b1: bus 1:slot 0:=
func 0
[ =A0 =A01.681241] megaraid_sas 0000:01:00.0: can't fi=
nd IRQ for PCI INT A; please try using pci=3Dbiosirq
[ =A0 =A01.6=
87892] megasas: FW now in Ready state



[ =A0 =A01.735350] megasas_init_mfi: fw_support_ieee=3D67108864
<=
div>[ =A0 =A01.735407] megasas: INIT adapter done
[ =A0 =A01.8073=
65] scsi0 : LSI SAS based MegaRAID driver
[ =A0 =A01.808799] scsi=
 0:0:8:0: Direct-Access =A0 =A0 IBM-ESXS ST9146803SS =A0 =A0 =A0B53C PQ: 0 =
ANSI: 5



[ =A0 =A01.811249] scsi 0:0:9:0: Direct-Access =A0 =A0 ATA =A0 =A0 =A0=
ST9500620NS =A0 =A0 =A0BE24 PQ: 0 ANSI: 5
[ =A0 =A01.812739] scsi=
 0:0:10:0: Direct-Access =A0 =A0 ATA =A0 =A0 =A0ST9500620NS =A0 =A0 =A0BE24=
 PQ: 0 ANSI: 5
[ =A0 =A01.824208] scsi 0:2:0:0: Direct-Access =A0=
 =A0 IBM =A0 =A0 =A0ServeRAID M1015 =A02.12 PQ: 0 ANSI: 5



[ =A0 =A01.839755] sd 0:2:0:0: [sdb] 1949216768 512-byte logical block=
s: (997 GB/929 GiB)
[ =A0 =A01.840060] sd 0:2:0:0: [sdb] Write Pr=
otect is off
[ =A0 =A01.840141] sd 0:2:0:0: [sdb] Mode Sense: 1f =
00 10 08



[ =A0 =A01.840153] sd 0:0:8:0: [sda] 286748000 512-byte logical blocks=
: (146 GB/136 GiB)
[ =A0 =A01.840302] sd 0:2:0:0: [sdb] Write cac=
he: disabled, read cache: disabled, supports DPO and FUA
[ =A0 =
=A01.842564] sd 0:0:8:0: [sda] Write Protect is off



[ =A0 =A01.842637] sd 0:0:8:0: [sda] Mode Sense: c3 00 10 08
[ =A0 =A01.843418] =A0sdb: sdb1
[ =A0 =A01.843898] sd 0:0:8:0: [=
sda] Write cache: disabled, read cache: enabled, supports DPO and FUA
=

[ =A0 =A01.844117] sd 0:2:0:0: [sdb] Attached SCSI disk



[ =A0 =A01.866028] =A0sda: sda1 sda2 sda3 sda4
[ =A0 =A01.87=
0498] sd 0:0:8:0: [sda] Attached SCSI disk
[ =A0 =A02.053157] dev=
ice-mapper: uevent: version 1.0.3
[ =A0 =A02.053610] device-mappe=
r: ioctl: 4.23.0-ioctl (2012-07-25) initialised: dm-devel@redhat.com



[ =A0 =A02.214131] EXT4-fs (dm-0): mounted filesystem with ordered dat=
a mode. Opts: (null)
[ =A0 =A03.162111] udevd[298]: starting vers=
ion 175
[ =A0 =A03.419449] bnx2: Broadcom NetXtreme II Gigabit Et=
hernet Driver bnx2 v2.2.3 (June 27, 2012)



[ =A0 =A03.419565] bnx2 0000:0b:00.0: can't find IRQ for PCI INT A=
; please try using pci=3Dbiosirq
[ =A0 =A03.420241] bnx2 0000:0b:=
00.0: eth0: Broadcom NetXtreme II BCM5709 1000Base-T (C0) PCI Express found=
 at mem 92000000, IRQ 0, node addr 34:40:b5:ab:e5:b4



[ =A0 =A03.421062] bnx2 0000:0b:00.1: can't find IRQ for PCI INT B=
; please try using pci=3Dbiosirq
[ =A0 =A03.421705] bnx2 0000:0b:=
00.1: eth1: Broadcom NetXtreme II BCM5709 1000Base-T (C0) PCI Express found=
 at mem 94000000, IRQ 0, node addr 34:40:b5:ab:e5:b6



[ =A0 =A03.428805] dca service started, version 1.12.1
[ =A0=
 =A03.467169] EDAC MC: Ver: 3.0.0
[ =A0 =A03.473824] ioatdma: Int=
el(R) QuickData Technology Driver 4.00
[ =A0 =A03.473918] ioatdma=
 0000:00:16.0: enabling device (0000 -> 0002)



[ =A0 =A03.473996] ioatdma 0000:00:16.0: can't find IRQ for PCI IN=
T A; please try using pci=3Dbiosirq
[ =A0 =A03.474116] ioatdma 00=
00:00:16.0: channel error register unreachable
[ =A0 =A03.474191]=
 ioatdma 0000:00:16.0: channel enumeration error



[ =A0 =A03.505302] microcode: CPU0 sig=3D0x206c2, pf=3D0x1, revision=
=3D0x15
[ =A0 =A03.505995] ioatdma 0000:00:16.0: Intel(R) I/OAT D=
MA Engine init failed
[ =A0 =A03.506096] ioatdma 0000:00:16.1: en=
abling device (0000 -> 0002)



[ =A0 =A03.506173] ioatdma 0000:00:16.1: can't find IRQ for PCI IN=
T B; please try using pci=3Dbiosirq
[ =A0 =A03.506296] ioatdma 00=
00:00:16.1: channel error register unreachable
[ =A0 =A03.506369]=
 ioatdma 0000:00:16.1: channel enumeration error



[ =A0 =A03.506441] ioatdma 0000:00:16.1: Intel(R) I/OAT DMA Engine ini=
t failed
[ =A0 =A03.506532] ioatdma 0000:00:16.2: enabling device=
 (0000 -> 0002)
[ =A0 =A03.506608] ioatdma 0000:00:16.2: can&#=
39;t find IRQ for PCI INT C; please try using pci=3Dbiosirq



[ =A0 =A03.506722] ioatdma 0000:00:16.2: channel error register unreac=
hable
[ =A0 =A03.506795] ioatdma 0000:00:16.2: channel enumeratio=
n error
[ =A0 =A03.506867] ioatdma 0000:00:16.2: Intel(R) I/OAT D=
MA Engine init failed



[ =A0 =A03.506957] ioatdma 0000:00:16.3: enabling device (0000 -> 0=
002)
[ =A0 =A03.507034] ioatdma 0000:00:16.3: can't find IRQ =
for PCI INT D; please try using pci=3Dbiosirq
[ =A0 =A03.507147] =
ioatdma 0000:00:16.3: channel error register unreachable



[ =A0 =A03.507222] ioatdma 0000:00:16.3: channel enumeration error
[ =A0 =A03.507294] ioatdma 0000:00:16.3: Intel(R) I/OAT DMA Engine i=
nit failed
[ =A0 =A03.507398] ioatdma 0000:00:16.4: enabling devi=
ce (0000 -> 0002)



[ =A0 =A03.507476] ioatdma 0000:00:16.4: can't find IRQ for PCI IN=
T A; please try using pci=3Dbiosirq
[ =A0 =A03.507590] ioatdma 00=
00:00:16.4: channel error register unreachable
[ =A0 =A03.507663]=
 ioatdma 0000:00:16.4: channel enumeration error



[ =A0 =A03.507735] ioatdma 0000:00:16.4: Intel(R) I/OAT DMA Engine ini=
t failed
[ =A0 =A03.507826] ioatdma 0000:00:16.5: enabling device=
 (0000 -> 0002)
[ =A0 =A03.507903] ioatdma 0000:00:16.5: can&#=
39;t find IRQ for PCI INT B; please try using pci=3Dbiosirq



[ =A0 =A03.508016] ioatdma 0000:00:16.5: channel error register unreac=
hable
[ =A0 =A03.508090] ioatdma 0000:00:16.5: channel enumeratio=
n error
[ =A0 =A03.508162] ioatdma 0000:00:16.5: Intel(R) I/OAT D=
MA Engine init failed



[ =A0 =A03.508255] ioatdma 0000:00:16.6: enabling device (0000 -> 0=
002)
[ =A0 =A03.508337] ioatdma 0000:00:16.6: can't find IRQ =
for PCI INT C; please try using pci=3Dbiosirq
[ =A0 =A03.508454] =
ioatdma 0000:00:16.6: channel error register unreachable



[ =A0 =A03.508529] ioatdma 0000:00:16.6: channel enumeration error
[ =A0 =A03.508601] ioatdma 0000:00:16.6: Intel(R) I/OAT DMA Engine i=
nit failed
[ =A0 =A03.508692] ioatdma 0000:00:16.7: enabling devi=
ce (0000 -> 0002)



[ =A0 =A03.508769] ioatdma 0000:00:16.7: can't find IRQ for PCI IN=
T D; please try using pci=3Dbiosirq
[ =A0 =A03.508885] ioatdma 00=
00:00:16.7: channel error register unreachable
[ =A0 =A03.508958]=
 ioatdma 0000:00:16.7: channel enumeration error



[ =A0 =A03.509030] ioatdma 0000:00:16.7: Intel(R) I/OAT DMA Engine ini=
t failed
[ =A0 =A03.571248] usbcore: registered new interface dri=
ver usbfs
[ =A0 =A03.571330] usbcore: registered new interface dr=
iver hub



[ =A0 =A03.585483] ACPI Exception: AE_BAD_PARAMETER, Thread 1786484928=
 could not acquire Mutex [0x1] (20120711/utmutex-276)
[ =A0 =A03.=
585675] ACPI Exception: AE_BAD_PARAMETER, Thread 1786484928 could not acqui=
re Mutex [0x1] (20120711/utmutex-276)



[ =A0 =A03.590919] usbcore: registered new device driver usb
[ =A0 =A03.603433] input: PC Speaker as /devices/platform/pcspkr/input/inp=
ut0
[ =A0 =A03.604762] libata version 3.00 loaded.
[ =
=A0 =A03.607430] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI=
) Driver



[ =A0 =A03.607535] ehci_hcd 0000:00:1a.7: can't find IRQ for PCI I=
NT C; please try using pci=3Dbiosirq
[ =A0 =A03.607629] ehci_hcd =
0000:00:1a.7: Found HC with no IRQ. =A0Check BIOS/PCI 0000:00:1a.7 setup!


[ =A0 =A03.607723] ehci_hcd 0000:00:1a.7: init 0000:00:1a.7 fail, -19
=

[ =A0 =A03.607808] ehci_hcd 0000:00:1d.7: can't find IRQ for PCI I=
NT A; please try using pci=3Dbiosirq
[ =A0 =A03.607900] ehci_hcd =
0000:00:1d.7: Found HC with no IRQ. =A0Check BIOS/PCI 0000:00:1d.7 setup!


[ =A0 =A03.607994] ehci_hcd 0000:00:1d.7: init 0000:00:1d.7 fail, -19<=
/div>
[ =A0 =A03.623701] i801_smbus 0000:00:1f.3: enabling device (0140=
 -> 0143)
[ =A0 =A03.623781] i801_smbus 0000:00:1f.3: can'=
t find IRQ for PCI INT B; please try using pci=3Dbiosirq



[ =A0 =A03.623874] ACPI Exception: AE_BAD_PARAMETER, Thread 1775910976=
 could not acquire Mutex [0x1] (20120711/utmutex-276)
[ =A0 =A03.=
624093] i801_smbus 0000:00:1f.3: SMBus using PCI Interrupt
[ =A0 =
=A03.676083] ata_piix 0000:00:1f.2: version 2.13



[ =A0 =A03.676095] ata_piix 0000:00:1f.2: can't find IRQ for PCI I=
NT A; please try using pci=3Dbiosirq
[ =A0 =A03.676193] ata_piix =
0000:00:1f.2: MAP [
[ =A0 =A03.676260] =A0P0 P2 P1 P3 ]
[ =A0 =A03.676539] ata_piix 0000:00:1f.2: setting latency timer to 64


[ =A0 =A03.677344] scsi1 : ata_piix
[ =A0 =A03.677732] scsi2=
 : ata_piix
[ =A0 =A03.677862] ata1: SATA max UDMA/133 cmd 0x2118=
 ctl 0x212c bmdma 0x20f0
[ =A0 =A03.677954] ata2: SATA max UDMA/1=
33 cmd 0x2110 ctl 0x2128 bmdma 0x20f8



[ =A0 =A03.678154] gpio_ich: GPIO from 195 to 255 on gpio_ich
[ =A0 =A03.678606] ata_piix 0000:00:1f.5: can't find IRQ for PCI INT =
C; please try using pci=3Dbiosirq
[ =A0 =A03.678703] ata_piix 000=
0:00:1f.5: MAP [



[ =A0 =A03.678771] =A0P0 -- P1 -- ]
[ =A0 =A03.679046] ata_p=
iix 0000:00:1f.5: setting latency timer to 64
[ =A0 =A03.679562] =
scsi3 : ata_piix
[ =A0 =A03.680057] uhci_hcd: USB Universal Host =
Controller Interface driver



[ =A0 =A03.682601] scsi4 : ata_piix
[ =A0 =A03.682814] ata3:=
 SATA max UDMA/133 cmd 0x2108 ctl 0x2124 bmdma 0x20d0
[ =A0 =A03.=
682893] ata4: SATA max UDMA/133 cmd 0x2100 ctl 0x2120 bmdma 0x20d8
[ =A0 =A03.683028] uhci_hcd 0000:00:1a.0: can't find IRQ for PCI INT =
A; please try using pci=3Dbiosirq



[ =A0 =A03.683123] uhci_hcd 0000:00:1a.0: Found HC with no IRQ. =A0Che=
ck BIOS/PCI 0000:00:1a.0 setup!
[ =A0 =A03.683217] uhci_hcd 0000:=
00:1a.0: init 0000:00:1a.0 fail, -19
[ =A0 =A03.683300] uhci_hcd =
0000:00:1a.1: can't find IRQ for PCI INT B; please try using pci=3Dbios=
irq



[ =A0 =A03.683408] uhci_hcd 0000:00:1a.1: Found HC with no IRQ. =A0Che=
ck BIOS/PCI 0000:00:1a.1 setup!
[ =A0 =A03.683504] uhci_hcd 0000:=
00:1a.1: init 0000:00:1a.1 fail, -19
[ =A0 =A03.683588] uhci_hcd =
0000:00:1d.0: can't find IRQ for PCI INT A; please try using pci=3Dbios=
irq



[ =A0 =A03.683682] uhci_hcd 0000:00:1d.0: Found HC with no IRQ. =A0Che=
ck BIOS/PCI 0000:00:1d.0 setup!
[ =A0 =A03.683802] uhci_hcd 0000:=
00:1d.0: init 0000:00:1d.0 fail, -19
[ =A0 =A03.683933] uhci_hcd =
0000:00:1d.1: can't find IRQ for PCI INT B; please try using pci=3Dbios=
irq



[ =A0 =A03.684026] uhci_hcd 0000:00:1d.1: Found HC with no IRQ. =A0Che=
ck BIOS/PCI 0000:00:1d.1 setup!
[ =A0 =A03.684121] uhci_hcd 0000:=
00:1d.1: init 0000:00:1d.1 fail, -19
[ =A0 =A03.684201] uhci_hcd =
0000:00:1d.2: can't find IRQ for PCI INT C; please try using pci=3Dbios=
irq



[ =A0 =A03.684293] uhci_hcd 0000:00:1d.2: Found HC with no IRQ. =A0Che=
ck BIOS/PCI 0000:00:1d.2 setup!
[ =A0 =A03.684387] uhci_hcd 0000:=
00:1d.2: init 0000:00:1d.2 fail, -19
[ =A0 =A03.751594] microcode=
: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba=




[ =A0 =A03.771183] iTCO_vendor_support: vendor-support=3D0
[=
 =A0 =A04.010635] ata3: SATA link down (SStatus 0 SControl 300)
[=
 =A0 =A04.022013] ata4: SATA link down (SStatus 0 SControl 300)
[=
 =A0 =A04.342660] ata2.00: SATA link down (SStatus 0 SControl 300)



[ =A0 =A04.342751] ata2.01: SATA link down (SStatus 0 SControl 300)
[ =A0 =A04.487426] ata1.00: SATA link up 1.5 Gbps (SStatus 113 SCon=
trol 300)
[ =A0 =A04.487519] ata1.01: SATA link down (SStatus 0 S=
Control 300)



[ =A0 =A04.487603] ata1.01: link offline, clearing class 3 to NONE
[ =A0 =A04.495491] ata1.00: ATAPI: IBM SATA DEVICE 81Y3657, IB01, ma=
x UDMA/33
[ =A0 =A04.511489] ata1.00: configured for UDMA/33
[ =A0 =A09.511364] ata1.00: qc timeout (cmd 0xa0)



[ =A0 =A09.511434] ata1.00: TEST_UNIT_READY failed (err_mask=3D0x5)
[ =A0 10.307422] ata1.00: SATA link up 1.5 Gbps (SStatus 113 SContr=
ol 300)
[ =A0 10.307515] ata1.01: SATA link down (SStatus 0 SCont=
rol 300)



[ =A0 10.307600] ata1.01: link offline, clearing class 3 to NONE
=

[ =A0 10.331487] ata1.00: configured for UDMA/33
[ =A0 15.33=
1361] ata1.00: qc timeout (cmd 0xa0)
[ =A0 15.331431] ata1.00: TE=
ST_UNIT_READY failed (err_mask=3D0x5)



[ =A0 15.331504] ata1.00: limiting SATA link speed to 1.5 Gbps
[ =A0 15.331574] ata1.00: limiting speed to UDMA/33:PIO3
[ =A0=
 16.127423] ata1.00: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
=



[ =A0 16.127515] ata1.01: SATA link down (SStatus 0 SControl 300)
[ =A0 16.127601] ata1.01: link offline, clearing class 3 to NONE
[ =A0 16.151487] ata1.00: configured for UDMA/33
[ =A0 21.151378=
] ata1.00: qc timeout (cmd 0xa0)



[ =A0 21.151448] ata1.00: TEST_UNIT_READY failed (err_mask=3D0x5)
[ =A0 21.151518] ata1.00: disabled
[ =A0 21.151603] ata1.00=
: hard resetting link
[ =A0 21.471351] ata1.01: hard resetting li=
nk



[ =A0 21.947430] ata1.00: SATA link up 1.5 Gbps (SStatus 113 SControl =
310)
[ =A0 21.947523] ata1.01: SATA link down (SStatus 0 SControl=
 300)
[ =A0 21.947608] ata1.01: link offline, clearing class 3 to=
 NONE



[ =A0 21.947611] ata1: EH complete
[ =A0 21.963868] iTCO_wdt=
: Intel TCO WatchDog Timer Driver v1.10
[ =A0 21.963965] iTCO_wdt=
: Found a ICH10 TCO device (Version=3D2, TCOBASE=3D0x05e0)
[ =A0 =
21.964124] iTCO_wdt: initialized. heartbeat=3D30 sec (nowayout=3D0)



[ =A0 21.997872] Error: Driver 'pcspkr' is already registered,=
 aborting...
[ =A0 22.010315] alg: No test for __gcm-aes-aesni (_=
_driver-gcm-aes-aesni)
[ =A0 22.995255] EXT4-fs (dm-0): re-mounte=
d. Opts: (null)



[ =A0 23.177611] EXT4-fs (dm-0): re-mounted. Opts: errors=3Dremount-ro=

[ =A0 23.281974] loop: module loaded
[ =A0 23.346661] =
lp: driver loaded but no devices found
[ =A0 24.043404] Adding 41=
94300k swap on /dev/mapper/xen-fw_swap. =A0Priority:-1 extents:1 across:419=
4300k=A0



[ =A0 24.347072] EXT4-fs (sda3): mounted filesystem with ordered data =
mode. Opts: (null)
[ =A0 24.386139] FAT-fs (sda2): utf8 is not a =
recommended IO charset for FAT filesystems, filesystem will be case sensiti=
ve!



[ =A0 25.140294] bnx2 0000:0b:00.0: eth0: using MSIX
[ =A0 2=
5.140439] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ =
=A0 25.181911] Bridge firewalling registered
[ =A0 25.186131] dev=
ice eth1 entered promiscuous mode



[ =A0 25.288312] bnx2 0000:0b:00.1: eth1: using MSIX
[ =A0 2=
5.288410] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[ =
=A0 25.290413] IPv6: ADDRCONF(NETDEV_UP): xenbr0: link is not ready

[ =A0 26.898999] bnx2 0000:0b:00.0: eth0: NIC Copper Link is Up, 100 Mbps f=
ull duplex


[ =A0 26.899091]=A0
[ =A0 26.899222] IPv6: ADDRCONF(NETDEV_C=
HANGE): eth0: link becomes ready
[ =A0 28.981380] bnx2 0000:0b:00=
.1: eth1: NIC Copper Link is Up, 1000 Mbps full duplex
[ =A0 28.9=
81477]=A0



[ =A0 28.981613] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes rea=
dy
[ =A0 28.981698] xenbr0: port 1(eth1) entered forwarding state=

[ =A0 28.981771] xenbr0: port 1(eth1) entered forwarding state


[ =A0 28.981850] IPv6: ADDRCONF(NETDEV_CHANGE): xenbr0: link becomes r=
eady
[ =A0 33.512189] RPC: Registered named UNIX socket transport=
 module.
[ =A0 33.512281] RPC: Registered udp transport module.


[ =A0 33.512351] RPC: Registered tcp transport module.
[ =A0=
 33.512420] RPC: Registered tcp NFSv4.1 backchannel transport module.
=

[ =A0 33.533692] FS-Cache: Loaded
[ =A0 33.547314] FS-Cache:=
 Netfs 'nfs' registered for caching



[ =A0 33.579870] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
[ =
=A0 34.845026] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
<=
div>
[ =A0 34.854870] ip_tables: (C) 2000-2006 Netfilter Core Team


[ =A0 35.475210] ppdev: user-space parallel port driver
[ =
=A0 39.140866] colord-sane[2701]: segfault at 0 ip 00007fc826bc4884 sp 0000=
7fff6a44fea0 error 4 in l=
ibc-2.13.so[7fc826b1f000+17d000]



[ =A0 44.011341] xenbr0: port 1(eth1) entered forwarding state


Thanks for all,
Allan Sche=
id






-- 
<=
em>Att,
Allan Vicente Scheid


Acad=EAmico de Ci=EAncia da Computa=E7=E3o -=
 Unioeste Foz





--14dae934109feecd8704cbc0e07e--


--===============4323735893482094400==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4323735893482094400==--


From xen-devel-bounces@lists.xen.org Thu Oct 11 04:20:12 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 04:20:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMAFM-00015V-2X; Thu, 11 Oct 2012 04:19:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMAFJ-00015Q-VV
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 04:19:42 +0000
Received: from [85.158.139.83:62168] by server-5.bemta-5.messagelabs.com id
	B5/C6-19238-DD846705; Thu, 11 Oct 2012 04:19:41 +0000
X-Env-Sender: avs.009@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1349929175!30050410!1
X-Originating-IP: [209.85.210.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10593 invoked from network); 11 Oct 2012 04:19:36 -0000
Received: from mail-ia0-f173.google.com (HELO mail-ia0-f173.google.com)
	(209.85.210.173)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Oct 2012 04:19:36 -0000
Received: by mail-ia0-f173.google.com with SMTP id m10so1176521iam.32
	for ; Wed, 10 Oct 2012 21:19:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=QqCdBhK52TgtA/rvX38GV/iddN6YvC5JsRQmV1ZjhjA=;
	b=hFGYFOQZu/pvXrtFAcF9ynyhGl9zfQgoc/dQg2Rv9vtj9HUWEImMmNl5USC3UaMYlL
	7FycrmNMeu0kRZZSfBYh4WUnT4K+ba5nxXILGbVpsBs1D6dckF4rGNDuW/b8BDeb3W+u
	xXZTEPOrE693EUOgR3Q7s52uxEsakLcWIdgaC2Nt1cDdYvEbxJiTo9/wFyJ+UoIdZo/V
	8rM25OK2SXg44Pj2pGeXSNvgIJFGUMTjyXsi44cyvgvfX+p6FkVfDJcnQt9JfM9VAd3o
	M83XbUzbTiUcPm5wHRp0FYmuEf4gpdzbBUKmOwdyhESTXclmYrr7Rv5oDUYutz7SL25F
	/ojA==
MIME-Version: 1.0
Received: by 10.50.185.194 with SMTP id fe2mr7561274igc.60.1349929174748; Wed,
	10 Oct 2012 21:19:34 -0700 (PDT)
Received: by 10.64.22.71 with HTTP; Wed, 10 Oct 2012 21:19:34 -0700 (PDT)
Date: Thu, 11 Oct 2012 01:19:34 -0300
Message-ID: 
From: Allan Scheid 
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Xen 4.2 with EFI on IBM Server ACPI Bug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============4323735893482094400=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4323735893482094400==
Content-Type: multipart/alternative; boundary=14dae934109feecd8704cbc0e07e

--14dae934109feecd8704cbc0e07e
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hellow all, i need help with this bug:

ACPI BIOS Bug: Error: A valid RSDP was not found (20120711/tbxfroot-219)

Because of this first errors i get this second error, and it causes don't
work USB ports and some PCI cards on the system:

can't find IRQ for PCI INT A; please try using pci=3Dbiosirq

This occours only when i try boot with xen multiboot (with hypervisor), if
i boot only kernel with xen extensions no has errors in dmesg.

Kernel: 3.6.1-xen self compiled (work perfect without xen multiboot)
Xen Version: 4.2
Grub2 EFI: 1.99-23
Debian Unstable distro
Server: IBM System x3650 M3 7945AC1

dmesg output:

[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.6.1-xen (root@lca-fw) (gcc version 4.7.1
(Debian 4.7.1-7) ) #1 SMP Wed Oct 10 22:46:05 BRT 2012
[    0.000000] Command line: placeholder root=3D/dev/mapper/xen-fw_root ro
[    0.000000] Freeing 6c-6d pfn range: 1 pages freed
[    0.000000] 1-1 mapping on 6c->6d
[    0.000000] Freeing 9f-100 pfn range: 97 pages freed
[    0.000000] 1-1 mapping on 9f->100
[    0.000000] Freeing 7acb7-7ccb8 pfn range: 8193 pages freed
[    0.000000] 1-1 mapping on 7acb7->7ccb8
[    0.000000] Freeing 7d4f0-7d51b pfn range: 43 pages freed
[    0.000000] 1-1 mapping on 7d4f0->7d51b
[    0.000000] Freeing 7d53f-7d56a pfn range: 43 pages freed
[    0.000000] 1-1 mapping on 7d53f->7d56a
[    0.000000] Freeing 7d704-7d7b4 pfn range: 176 pages freed
[    0.000000] 1-1 mapping on 7d704->7d7b4
[    0.000000] Freeing 7f5ef-7f7ff pfn range: 528 pages freed
[    0.000000] 1-1 mapping on 7f5ef->7f7ff
[    0.000000] Freeing 7f800-f258d pfn range: 470413 pages freed
[    0.000000] 1-1 mapping on 7f800->100000
[    0.000000] Released 479494 pages of unused memory
[    0.000000] Set 535417 page(s) to 1-1 mapping
[    0.000000] Populating 100000-175106 pfn range: 479494 pages added
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] Xen: [mem 0x0000000000000000-0x000000000006bfff] usable
[    0.000000] Xen: [mem 0x000000000006c000-0x000000000006cfff] ACPI NVS
[    0.000000] Xen: [mem 0x000000000006d000-0x000000000009efff] usable
[    0.000000] Xen: [mem 0x000000000009f000-0x000000000009ffff] ACPI NVS
[    0.000000] Xen: [mem 0x00000000000a0000-0x00000000000fffff] reserved
[    0.000000] Xen: [mem 0x0000000000100000-0x000000007acb6fff] usable
[    0.000000] Xen: [mem 0x000000007acb7000-0x000000007ccb7fff] reserved
[    0.000000] Xen: [mem 0x000000007ccb8000-0x000000007d4effff] usable
[    0.000000] Xen: [mem 0x000000007d4f0000-0x000000007d51afff] reserved
[    0.000000] Xen: [mem 0x000000007d51b000-0x000000007d53efff] usable
[    0.000000] Xen: [mem 0x000000007d53f000-0x000000007d569fff] reserved
[    0.000000] Xen: [mem 0x000000007d56a000-0x000000007d703fff] usable
[    0.000000] Xen: [mem 0x000000007d704000-0x000000007d7b3fff] reserved
[    0.000000] Xen: [mem 0x000000007d7b4000-0x000000007f5eefff] usable
[    0.000000] Xen: [mem 0x000000007f5ef000-0x000000007f6defff] reserved
[    0.000000] Xen: [mem 0x000000007f6df000-0x000000007f7defff] ACPI NVS
[    0.000000] Xen: [mem 0x000000007f7df000-0x000000007f7fefff] ACPI data
[    0.000000] Xen: [mem 0x000000007f7ff000-0x000000007f7fffff] usable
[    0.000000] Xen: [mem 0x0000000080000000-0x000000008fffffff] reserved
[    0.000000] Xen: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved
[    0.000000] Xen: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
[    0.000000] Xen: [mem 0x00000000ff800000-0x00000000ffffffff] reserved
[    0.000000] Xen: [mem 0x0000000100000000-0x000000017fffffff] usable
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI 2.5 present.
[    0.000000] DMI: IBM System x3650 M3 -[7945AC1]-/00D4062, BIOS
-[D6E157AUS-1.15]- 06/13/2012
[    0.000000] e820: update [mem 0x00000000-0x0000ffff] usable =3D=3D> rese=
rved
[    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[    0.000000] No AGP bridge found
[    0.000000] e820: last_pfn =3D 0x180000 max_arch_pfn =3D 0x400000000
[    0.000000] e820: last_pfn =3D 0x7f800 max_arch_pfn =3D 0x400000000
[    0.000000] initial memory mapped: [mem 0x00000000-0x02334fff]
[    0.000000] Base memory trampoline at [ffff880000099000] 99000 size 2457=
6
[    0.000000] init_memory_mapping: [mem 0x00000000-0x7f7fffff]
[    0.000000]  [mem 0x00000000-0x7f7fffff] page 4k
[    0.000000] kernel direct mapping tables up to 0x7f7fffff @ [mem
0x01831000-0x01c2ffff]
[    0.000000] xen: setting RW the range 1c14000 - 1c30000
[    0.000000] init_memory_mapping: [mem 0x100000000-0x17fffffff]
[    0.000000]  [mem 0x100000000-0x17fffffff] page 4k
[    0.000000] kernel direct mapping tables up to 0x17fffffff @ [mem
0x7e9e8000-0x7f5eefff]
[    0.000000] xen: setting RW the range 7edea000 - 7f5ef000
[    0.000000] RAMDISK: [mem 0x01c30000-0x02334fff]
[    0.000000] ACPI BIOS Bug: Error: A valid RSDP was not found
(20120711/tbxfroot-219)
[    0.000000] NUMA turned off
[    0.000000] Faking a node at [mem 0x0000000000000000-0x000000017fffffff]
[    0.000000] Initmem setup node 0 [mem 0x00000000-0x17fffffff]
[    0.000000]   NODE_DATA [mem 0x175102000-0x175105fff]
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x00010000-0x00ffffff]
[    0.000000]   DMA32    [mem 0x01000000-0xffffffff]
[    0.000000]   Normal   [mem 0x100000000-0x17fffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x00010000-0x0006bfff]
[    0.000000]   node   0: [mem 0x0006d000-0x0009efff]
[    0.000000]   node   0: [mem 0x00100000-0x7acb6fff]
[    0.000000]   node   0: [mem 0x7ccb8000-0x7d4effff]
[    0.000000]   node   0: [mem 0x7d51b000-0x7d53efff]
[    0.000000]   node   0: [mem 0x7d56a000-0x7d703fff]
[    0.000000]   node   0: [mem 0x7d7b4000-0x7f5eefff]
[    0.000000]   node   0: [mem 0x7f7ff000-0x7f7fffff]
[    0.000000]   node   0: [mem 0x100000000-0x17fffffff]
[    0.000000] On node 0 totalpages: 1037431
[    0.000000]   DMA zone: 56 pages used for memmap
[    0.000000]   DMA zone: 6 pages reserved
[    0.000000]   DMA zone: 3920 pages, LIFO batch:0
[    0.000000]   DMA32 zone: 14280 pages used for memmap
[    0.000000]   DMA32 zone: 494881 pages, LIFO batch:31
[    0.000000]   Normal zone: 7168 pages used for memmap
[    0.000000]   Normal zone: 517120 pages, LIFO batch:31
[    0.000000] SFI: Simple Firmware Interface v0.81
http://simplefirmware.org
[    0.000000] smpboot: Allowing 1 CPUs, 0 hotplug CPUs
[    0.000000] nr_irqs_gsi: 16
[    0.000000] PM: Registered nosave memory: 000000000006c000 -
000000000006d000
[    0.000000] PM: Registered nosave memory: 000000000009f000 -
00000000000a0000
[    0.000000] PM: Registered nosave memory: 00000000000a0000 -
0000000000100000
[    0.000000] PM: Registered nosave memory: 000000007acb7000 -
000000007ccb8000
[    0.000000] PM: Registered nosave memory: 000000007d4f0000 -
000000007d51b000
[    0.000000] PM: Registered nosave memory: 000000007d53f000 -
000000007d56a000
[    0.000000] PM: Registered nosave memory: 000000007d704000 -
000000007d7b4000
[    0.000000] PM: Registered nosave memory: 000000007f5ef000 -
000000007f6df000
[    0.000000] PM: Registered nosave memory: 000000007f6df000 -
000000007f7df000
[    0.000000] PM: Registered nosave memory: 000000007f7df000 -
000000007f7ff000
[    0.000000] PM: Registered nosave memory: 000000007f800000 -
0000000080000000
[    0.000000] PM: Registered nosave memory: 0000000080000000 -
0000000090000000
[    0.000000] PM: Registered nosave memory: 0000000090000000 -
00000000fed1c000
[    0.000000] PM: Registered nosave memory: 00000000fed1c000 -
00000000fed20000
[    0.000000] PM: Registered nosave memory: 00000000fed20000 -
00000000fee00000
[    0.000000] PM: Registered nosave memory: 00000000fee00000 -
00000000fee01000
[    0.000000] PM: Registered nosave memory: 00000000fee01000 -
00000000ff800000
[    0.000000] PM: Registered nosave memory: 00000000ff800000 -
0000000100000000
[    0.000000] e820: [mem 0x90000000-0xfed1bfff] available for PCI devices
[    0.000000] Booting paravirtualized kernel on Xen
[    0.000000] Xen version: 4.2.0 (preserve-AD)
[    0.000000] setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:1
nr_node_ids:1
[    0.000000] PERCPU: Embedded 28 pages/cpu @ffff880174e00000 s83840 r8192
d22656 u2097152
[    0.000000] pcpu-alloc: s83840 r8192 d22656 u2097152 alloc=3D1*2097152
[    0.000000] pcpu-alloc: [0] 0
[    1.096975] Built 1 zonelists in Zone order, mobility grouping on.
 Total pages: 1015921
[    1.096977] Policy zone: Normal
[    1.096979] Kernel command line: placeholder
root=3D/dev/mapper/xen-fw_root ro
[    1.097016] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    1.097021] __ex_table already sorted, skipping sort
[    1.121932] software IO TLB [mem 0x16c800000-0x1707fffff] (64MB) mapped
at [ffff88016c800000-ffff8801707fffff]
[    1.138656] Memory: 3815116k/6291456k available (3573k kernel code,
2141732k absent, 334608k reserved, 3147k data, 592k init)
[    1.138717] Hierarchical RCU implementation.
[    1.138718] RCU dyntick-idle grace-period acceleration is enabled.
[    1.138719] RCU restricting CPUs from NR_CPUS=3D512 to nr_cpu_ids=3D1.
[    1.138728] NR_IRQS:33024 nr_irqs:256 16
[    1.147171] Console: colour VGA+ 80x25
[    1.154296] console [tty0] enabled
[    1.159002] allocated 16777216 bytes of page_cgroup
[    1.159079] please try 'cgroup_disable=3Dmemory' option if you don't wan=
t
memory cgroups
[    1.159208] Xen: using vcpuop timer interface
[    1.159214] installing Xen timer for CPU 0
[    1.159303] tsc: Detected 2400.126 MHz processor
[    1.159375] Calibrating delay loop (skipped), value calculated using
timer frequency.. 4800.25 BogoMIPS (lpj=3D9600504)
[    1.159517] pid_max: default: 32768 minimum: 301
[    1.159607] Security Framework initialized
[    1.159680] AppArmor: AppArmor disabled by boot time parameter
[    1.160298] Dentry cache hash table entries: 524288 (order: 10, 4194304
bytes)
[    1.161752] Inode-cache hash table entries: 262144 (order: 9, 2097152
bytes)
[    1.162415] Mount-cache hash table entries: 256
[    1.162658] Initializing cgroup subsys cpuacct
[    1.162729] Initializing cgroup subsys memory
[    1.162806] Initializing cgroup subsys devices
[    1.162876] Initializing cgroup subsys freezer
[    1.162945] Initializing cgroup subsys net_cls
[    1.163014] Initializing cgroup subsys blkio
[    1.163082] Initializing cgroup subsys perf_event
[    1.163204] CPU: Physical Processor ID: 0
[    1.163277] CPU: Processor Core ID: 0
[    1.163346] mce: CPU supports 2 MCE banks
[    1.163452] Last level iTLB entries: 4KB 512, 2MB 7, 4MB 7
[    1.163452] Last level dTLB entries: 4KB 512, 2MB 32, 4MB 32
[    1.163452] tlb_flushall_shift is 0x6
[    1.163602] SMP alternatives: switching to UP code
[    1.171342] Freeing SMP alternatives: 8k freed
[    1.171471] Performance Events: unsupported p6 CPU model 44 no PMU
driver, software events only.
[    1.171785] NMI watchdog: disabled (cpu0): hardware events not enabled
[    1.171876] Brought up 1 CPUs
[    1.172058] devtmpfs: initialized
[    1.174970] PM: Registering ACPI NVS region [mem 0x0006c000-0x0006cfff]
(4096 bytes)
[    1.175062] PM: Registering ACPI NVS region [mem 0x0009f000-0x0009ffff]
(4096 bytes)
[    1.175153] PM: Registering ACPI NVS region [mem 0x7f6df000-0x7f7defff]
(1048576 bytes)
[    1.175314] Grant tables using version 2 layout.
[    1.175394] Grant table initialized
[    1.175514] dummy:
[    1.175625] NET: Registered protocol family 16
[    1.175969] PCI: Using configuration type 1 for base access
[    1.176599] bio: create slab  at 0
[    1.176719] ACPI: Interpreter disabled.
[    1.176796] xen/balloon: Initialising balloon driver.
[    1.177620] xen-balloon: Initialising balloon driver.
[    1.177761] vgaarb: loaded
[    1.177860] PCI: Probing PCI hardware
[    1.177929] PCI: root bus 00: using default resources
[    1.177930] PCI: Probing PCI hardware (bus 00)
[    1.177954] PCI host bridge to bus 0000:00
[    1.178025] pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
[    1.178098] pci_bus 0000:00: root bus resource [mem
0x00000000-0xffffffffff]
[    1.178173] pci_bus 0000:00: No busn resource found for root bus, will
use [bus 00-ff]
[    1.178266] pci_bus 0000:00: busn_res: [bus 00-ff] is inserted under
domain [bus 00-ff]
[    1.178287] pci 0000:00:00.0: [8086:3406] type 00 class 0x060000
[    1.178389] pci 0000:00:00.0: PME# supported from D0 D3hot D3cold
[    1.178425] pci 0000:00:01.0: [8086:3408] type 01 class 0x060400
[    1.178532] pci 0000:00:01.0: PME# supported from D0 D3hot D3cold
[    1.178571] pci 0000:00:02.0: [8086:3409] type 01 class 0x060400
[    1.178678] pci 0000:00:02.0: PME# supported from D0 D3hot D3cold
[    1.178716] pci 0000:00:03.0: [8086:340a] type 01 class 0x060400
[    1.178824] pci 0000:00:03.0: PME# supported from D0 D3hot D3cold
[    1.178865] pci 0000:00:05.0: [8086:340c] type 01 class 0x060400
[    1.178973] pci 0000:00:05.0: PME# supported from D0 D3hot D3cold
[    1.179013] pci 0000:00:07.0: [8086:340e] type 01 class 0x060400
[    1.179121] pci 0000:00:07.0: PME# supported from D0 D3hot D3cold
[    1.179161] pci 0000:00:09.0: [8086:3410] type 01 class 0x060400
[    1.179269] pci 0000:00:09.0: PME# supported from D0 D3hot D3cold
[    1.179309] pci 0000:00:10.0: [8086:3425] type 00 class 0x080000
[    1.179434] pci 0000:00:10.1: [8086:3426] type 00 class 0x080000
[    1.179543] pci 0000:00:11.0: [8086:3427] type 00 class 0x080000
[    1.179668] pci 0000:00:11.1: [8086:3428] type 00 class 0x080000
[    1.179795] pci 0000:00:14.0: [8086:342e] type 00 class 0x080000
[    1.179919] pci 0000:00:14.1: [8086:3422] type 00 class 0x080000
[    1.180053] pci 0000:00:14.2: [8086:3423] type 00 class 0x080000
[    1.180172] pci 0000:00:14.3: [8086:3438] type 00 class 0x080000
[    1.180273] pci 0000:00:15.0: [8086:342f] type 00 class 0x080020
[    1.180387] pci 0000:00:16.0: [8086:3430] type 00 class 0x088000
[    1.180408] pci 0000:00:16.0: reg 10: [mem 0x97a00000-0x97a03fff 64bit]
[    1.180540] pci 0000:00:16.1: [8086:3431] type 00 class 0x088000
[    1.180561] pci 0000:00:16.1: reg 10: [mem 0x97a04000-0x97a07fff 64bit]
[    1.180693] pci 0000:00:16.2: [8086:3432] type 00 class 0x088000
[    1.180713] pci 0000:00:16.2: reg 10: [mem 0x97a08000-0x97a0bfff 64bit]
[    1.180845] pci 0000:00:16.3: [8086:3433] type 00 class 0x088000
[    1.180866] pci 0000:00:16.3: reg 10: [mem 0x97a0c000-0x97a0ffff 64bit]
[    1.180997] pci 0000:00:16.4: [8086:3429] type 00 class 0x088000
[    1.181018] pci 0000:00:16.4: reg 10: [mem 0x97a10000-0x97a13fff 64bit]
[    1.181150] pci 0000:00:16.5: [8086:342a] type 00 class 0x088000
[    1.181170] pci 0000:00:16.5: reg 10: [mem 0x97a14000-0x97a17fff 64bit]
[    1.181302] pci 0000:00:16.6: [8086:342b] type 00 class 0x088000
[    1.181323] pci 0000:00:16.6: reg 10: [mem 0x97a18000-0x97a1bfff 64bit]
[    1.181455] pci 0000:00:16.7: [8086:342c] type 00 class 0x088000
[    1.181475] pci 0000:00:16.7: reg 10: [mem 0x97a1c000-0x97a1ffff 64bit]
[    1.181610] pci 0000:00:1a.0: [8086:3a37] type 00 class 0x0c0300
[    1.181681] pci 0000:00:1a.0: reg 20: [io  0x20a0-0x20bf]
[    1.181766] pci 0000:00:1a.1: [8086:3a38] type 00 class 0x0c0300
[    1.181837] pci 0000:00:1a.1: reg 20: [io  0x2080-0x209f]
[    1.181937] pci 0000:00:1a.7: [8086:3a3c] type 00 class 0x0c0320
[    1.181970] pci 0000:00:1a.7: reg 10: [mem 0x97a21000-0x97a213ff]
[    1.182116] pci 0000:00:1a.7: PME# supported from D0 D3hot D3cold
[    1.182153] pci 0000:00:1c.0: [8086:3a40] type 01 class 0x060400
[    1.182274] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
[    1.182316] pci 0000:00:1c.4: [8086:3a48] type 01 class 0x060400
[    1.182435] pci 0000:00:1c.4: PME# supported from D0 D3hot D3cold
[    1.182478] pci 0000:00:1d.0: [8086:3a34] type 00 class 0x0c0300
[    1.182549] pci 0000:00:1d.0: reg 20: [io  0x2060-0x207f]
[    1.182634] pci 0000:00:1d.1: [8086:3a35] type 00 class 0x0c0300
[    1.182705] pci 0000:00:1d.1: reg 20: [io  0x2040-0x205f]
[    1.182790] pci 0000:00:1d.2: [8086:3a36] type 00 class 0x0c0300
[    1.182860] pci 0000:00:1d.2: reg 20: [io  0x2020-0x203f]
[    1.182960] pci 0000:00:1d.7: [8086:3a3a] type 00 class 0x0c0320
[    1.182993] pci 0000:00:1d.7: reg 10: [mem 0x97a20000-0x97a203ff]
[    1.183138] pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold
[    1.183173] pci 0000:00:1e.0: [8086:244e] type 01 class 0x060401
[    1.183279] pci 0000:00:1f.0: [8086:3a18] type 00 class 0x060100
[    1.183458] pci 0000:00:1f.2: [8086:3a20] type 00 class 0x01018f
[    1.183484] pci 0000:00:1f.2: reg 10: [io  0x2118-0x211f]
[    1.183497] pci 0000:00:1f.2: reg 14: [io  0x212c-0x212f]
[    1.183510] pci 0000:00:1f.2: reg 18: [io  0x2110-0x2117]
[    1.183522] pci 0000:00:1f.2: reg 1c: [io  0x2128-0x212b]
[    1.183535] pci 0000:00:1f.2: reg 20: [io  0x20f0-0x20ff]
[    1.183548] pci 0000:00:1f.2: reg 24: [io  0x20e0-0x20ef]
[    1.183629] pci 0000:00:1f.3: [8086:3a30] type 00 class 0x0c0500
[    1.183653] pci 0000:00:1f.3: reg 10: [mem 0x97a22000-0x97a220ff 64bit]
[    1.183689] pci 0000:00:1f.3: reg 20: [io  0x2000-0x201f]
[    1.183746] pci 0000:00:1f.5: [8086:3a26] type 00 class 0x010185
[    1.183772] pci 0000:00:1f.5: reg 10: [io  0x2108-0x210f]
[    1.183784] pci 0000:00:1f.5: reg 14: [io  0x2124-0x2127]
[    1.183797] pci 0000:00:1f.5: reg 18: [io  0x2100-0x2107]
[    1.183816] pci 0000:00:1f.5: reg 1c: [io  0x2120-0x2123]
[    1.183829] pci 0000:00:1f.5: reg 20: [io  0x20d0-0x20df]
[    1.183841] pci 0000:00:1f.5: reg 24: [io  0x20c0-0x20cf]
[    1.183985] pci_bus 0000:0b: busn_res: [bus 0b-0f] is inserted under
[bus 00-ff]
[    1.184016] pci 0000:0b:00.0: [14e4:1639] type 00 class 0x020000
[    1.184040] pci 0000:0b:00.0: reg 10: [mem 0x92000000-0x93ffffff 64bit]
[    1.184181] pci 0000:0b:00.0: PME# supported from D0 D3hot D3cold
[    1.184224] pci 0000:0b:00.1: [14e4:1639] type 00 class 0x020000
[    1.184248] pci 0000:0b:00.1: reg 10: [mem 0x94000000-0x95ffffff 64bit]
[    1.184390] pci 0000:0b:00.1: PME# supported from D0 D3hot D3cold
[    1.191939] pci 0000:00:01.0: PCI bridge to [bus 0b-0f]
[    1.192017] pci 0000:00:01.0:   bridge window [mem 0x92000000-0x95ffffff=
]
[    1.192089] pci_bus 0000:10: busn_res: [bus 10-14] is inserted under
[bus 00-ff]
[    1.192093] pci 0000:00:02.0: PCI bridge to [bus 10-14]
[    1.192240] pci_bus 0000:15: busn_res: [bus 15-19] is inserted under
[bus 00-ff]
[    1.192244] pci 0000:00:03.0: PCI bridge to [bus 15-19]
[    1.192389] pci_bus 0000:1a: busn_res: [bus 1a-1e] is inserted under
[bus 00-ff]
[    1.192392] pci 0000:00:05.0: PCI bridge to [bus 1a-1e]
[    1.192539] pci_bus 0000:1f: busn_res: [bus 1f-23] is inserted under
[bus 00-ff]
[    1.192542] pci 0000:00:07.0: PCI bridge to [bus 1f-23]
[    1.192688] pci_bus 0000:24: busn_res: [bus 24-28] is inserted under
[bus 00-ff]
[    1.192691] pci 0000:00:09.0: PCI bridge to [bus 24-28]
[    1.192838] pci_bus 0000:01: busn_res: [bus 01-05] is inserted under
[bus 00-ff]
[    1.192863] pci 0000:01:00.0: [1000:0073] type 00 class 0x010400
[    1.192884] pci 0000:01:00.0: reg 10: [io  0x1000-0x10ff]
[    1.192908] pci 0000:01:00.0: reg 14: [mem 0x97940000-0x97943fff 64bit]
[    1.192932] pci 0000:01:00.0: reg 1c: [mem 0x97900000-0x9793ffff 64bit]
[    1.192962] pci 0000:01:00.0: reg 30: [mem 0xfffe0000-0xffffffff pref]
[    1.193060] pci 0000:01:00.0: supports D1 D2
[    1.200042] pci 0000:00:1c.0: PCI bridge to [bus 01-05]
[    1.200117] pci 0000:00:1c.0:   bridge window [io  0x1000-0x1fff]
[    1.200123] pci 0000:00:1c.0:   bridge window [mem 0x97900000-0x979fffff=
]
[    1.200196] pci_bus 0000:06: busn_res: [bus 06-0a] is inserted under
[bus 00-ff]
[    1.200228] pci 0000:06:00.0: [101b:0452] type 01 class 0x060400
[    1.200394] pci 0000:06:00.0: PME# supported from D0 D3hot D3cold
[    1.208144] pci 0000:00:1c.4: PCI bridge to [bus 06-0a]
[    1.208223] pci 0000:00:1c.4:   bridge window [mem 0x97000000-0x978fffff=
]
[    1.208231] pci 0000:00:1c.4:   bridge window [mem 0x96000000-0x96ffffff
64bit pref]
[    1.208330] pci_bus 0000:07: busn_res: [bus 07] is inserted under [bus
06-0a]
[    1.208353] pci 0000:07:00.0: [102b:0530] type 00 class 0x030000
[    1.208388] pci 0000:07:00.0: reg 10: [mem 0x96000000-0x96ffffff pref]
[    1.208407] pci 0000:07:00.0: reg 14: [mem 0x97800000-0x97803fff]
[    1.208427] pci 0000:07:00.0: reg 18: [mem 0x97000000-0x977fffff]
[    1.208633] pci 0000:06:00.0: PCI bridge to [bus 07]
[    1.208713] pci 0000:06:00.0:   bridge window [mem 0x97000000-0x978fffff=
]
[    1.208720] pci 0000:06:00.0:   bridge window [mem 0x96000000-0x96ffffff
pref]
[    1.208768] pci_bus 0000:29: busn_res: [bus 29-2d] is inserted under
[bus 00-ff]
[    1.208829] pci 0000:00:1e.0: PCI bridge to [bus 29-2d] (subtractive
decode)
[    1.208917] pci 0000:00:1e.0:   bridge window [io  0x0000-0xffff]
(subtractive decode)
[    1.208919] pci 0000:00:1e.0:   bridge window [mem
0x00000000-0xffffffffff] (subtractive decode)
[    1.208978] pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 2d
[    1.210287] vgaarb: device added:
PCI:0000:07:00.0,decodes=3Dio+mem,owns=3Dio+mem,locks=3Dnone
[    1.210898] PCI: pci_cache_line_size set to 64 bytes
[    1.211078] e820: reserve RAM buffer [mem 0x0006c000-0x0006ffff]
[    1.211080] e820: reserve RAM buffer [mem 0x0009f000-0x0009ffff]
[    1.211081] e820: reserve RAM buffer [mem 0x7acb7000-0x7bffffff]
[    1.211082] e820: reserve RAM buffer [mem 0x7d4f0000-0x7fffffff]
[    1.211086] e820: reserve RAM buffer [mem 0x7d53f000-0x7fffffff]
[    1.211088] e820: reserve RAM buffer [mem 0x7d704000-0x7fffffff]
[    1.211091] e820: reserve RAM buffer [mem 0x7f5ef000-0x7fffffff]
[    1.211093] e820: reserve RAM buffer [mem 0x7f800000-0x7fffffff]
[    1.211210] Switching to clocksource xen
[    1.212720] pnp: PnP ACPI: disabled
[    1.214391] pci 0000:01:00.0: no compatible bridge window for [mem
0xfffe0000-0xffffffff pref]
[    1.214569] pci 0000:00:1c.0: bridge window [mem 0x00100000-0x001fffff
pref] to [bus 01-05] add_size 200000
[    1.214613] pci 0000:00:1c.0: res[15]=3D[mem 0x00100000-0x001fffff pref]
get_res_add_size add_size 200000
[    1.214617] pci 0000:00:1c.0: BAR 15: assigned [mem
0x90000000-0x902fffff pref]
[    1.214708] pci 0000:00:01.0: PCI bridge to [bus 0b-0f]
[    1.214783] pci 0000:00:01.0:   bridge window [mem 0x92000000-0x95ffffff=
]
[    1.214865] pci 0000:00:02.0: PCI bridge to [bus 10-14]
[    1.214948] pci 0000:00:03.0: PCI bridge to [bus 15-19]
[    1.215032] pci 0000:00:05.0: PCI bridge to [bus 1a-1e]
[    1.215114] pci 0000:00:07.0: PCI bridge to [bus 1f-23]
[    1.215198] pci 0000:00:09.0: PCI bridge to [bus 24-28]
[    1.215282] pci 0000:01:00.0: BAR 6: assigned [mem 0x90000000-0x9001ffff
pref]
[    1.215383] pci 0000:00:1c.0: PCI bridge to [bus 01-05]
[    1.215456] pci 0000:00:1c.0:   bridge window [io  0x1000-0x1fff]
[    1.215532] pci 0000:00:1c.0:   bridge window [mem 0x97900000-0x979fffff=
]
[    1.215609] pci 0000:00:1c.0:   bridge window [mem 0x90000000-0x902fffff
pref]
[    1.215705] pci 0000:06:00.0: PCI bridge to [bus 07]
[    1.215782] pci 0000:06:00.0:   bridge window [mem 0x97000000-0x978fffff=
]
[    1.215860] pci 0000:06:00.0:   bridge window [mem 0x96000000-0x96ffffff
pref]
[    1.223235] pci 0000:00:1c.4: PCI bridge to [bus 06-0a]
[    1.223310] pci 0000:00:1c.4:   bridge window [mem 0x97000000-0x978fffff=
]
[    1.223391] pci 0000:00:1c.4:   bridge window [mem 0x96000000-0x96ffffff
64bit pref]
[    1.223489] pci 0000:00:1e.0: PCI bridge to [bus 29-2d]
[    1.223580] pci 0000:00:01.0: can't find IRQ for PCI INT A; please try
using pci=3Dbiosirq
[    1.223680] pci 0000:00:02.0: can't find IRQ for PCI INT A; please try
using pci=3Dbiosirq
[    1.223780] pci 0000:00:03.0: can't find IRQ for PCI INT A; please try
using pci=3Dbiosirq
[    1.223880] pci 0000:00:05.0: can't find IRQ for PCI INT A; please try
using pci=3Dbiosirq
[    1.223981] pci 0000:00:07.0: can't find IRQ for PCI INT A; please try
using pci=3Dbiosirq
[    1.224081] pci 0000:00:09.0: can't find IRQ for PCI INT A; please try
using pci=3Dbiosirq
[    1.224183] pci 0000:00:1c.0: can't find IRQ for PCI INT A; please try
using pci=3Dbiosirq
[    1.224283] pci 0000:00:1c.4: can't find IRQ for PCI INT A; please try
using pci=3Dbiosirq
[    1.224385] pci 0000:06:00.0: can't find IRQ for PCI INT A; please try
using pci=3Dbiosirq
[    1.224487] pci 0000:00:1e.0: setting latency timer to 64
[    1.224492] pci_bus 0000:00: resource 4 [io  0x0000-0xffff]
[    1.224494] pci_bus 0000:00: resource 5 [mem 0x00000000-0xffffffffff]
[    1.224496] pci_bus 0000:0b: resource 1 [mem 0x92000000-0x95ffffff]
[    1.224498] pci_bus 0000:01: resource 0 [io  0x1000-0x1fff]
[    1.224500] pci_bus 0000:01: resource 1 [mem 0x97900000-0x979fffff]
[    1.224502] pci_bus 0000:01: resource 2 [mem 0x90000000-0x902fffff pref]
[    1.224504] pci_bus 0000:06: resource 1 [mem 0x97000000-0x978fffff]
[    1.224507] pci_bus 0000:06: resource 2 [mem 0x96000000-0x96ffffff 64bit
pref]
[    1.224510] pci_bus 0000:07: resource 1 [mem 0x97000000-0x978fffff]
[    1.224512] pci_bus 0000:07: resource 2 [mem 0x96000000-0x96ffffff pref]
[    1.224514] pci_bus 0000:29: resource 4 [io  0x0000-0xffff]
[    1.224516] pci_bus 0000:29: resource 5 [mem 0x00000000-0xffffffffff]
[    1.224538] NET: Registered protocol family 2
[    1.225637] TCP established hash table entries: 524288 (order: 11,
8388608 bytes)
[    1.228185] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[    1.228521] TCP: Hash tables configured (established 524288 bind 65536)
[    1.228613] TCP: reno registered
[    1.228689] UDP hash table entries: 2048 (order: 4, 65536 bytes)
[    1.228785] UDP-Lite hash table entries: 2048 (order: 4, 65536 bytes)
[    1.228922] NET: Registered protocol family 1
[    1.229073] pci 0000:00:1a.0: can't find IRQ for PCI INT A; please try
using pci=3Dbiosirq
[    1.229201] pci 0000:00:1a.1: can't find IRQ for PCI INT B; please try
using pci=3Dbiosirq
[    1.229325] pci 0000:00:1a.7: can't find IRQ for PCI INT C; please try
using pci=3Dbiosirq
[    1.229466] pci 0000:00:1d.0: can't find IRQ for PCI INT A; please try
using pci=3Dbiosirq
[    1.229588] pci 0000:00:1d.1: can't find IRQ for PCI INT B; please try
using pci=3Dbiosirq
[    1.229708] pci 0000:00:1d.2: can't find IRQ for PCI INT C; please try
using pci=3Dbiosirq
[    1.229836] pci 0000:00:1d.7: can't find IRQ for PCI INT A; please try
using pci=3Dbiosirq
[    1.229986] pci 0000:07:00.0: Boot video device
[    1.229991] PCI: CLS 64 bytes, default 64
[    1.230040] Unpacking initramfs...
[    1.236939] Freeing initrd memory: 7188k freed
[    1.238401] platform rtc_cmos: registered platform RTC device (no PNP
device found)
[    1.238695] audit: initializing netlink socket (disabled)
[    1.238779] type=3D2000 audit(1349925915.231:1): initialized
[    1.253042] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[    1.253247] VFS: Disk quotas dquot_6.5.2
[    1.253330] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    1.253465] msgmni has been set to 7465
[    1.253646] alg: No test for stdrng (krng)
[    1.253730] Block layer SCSI generic (bsg) driver version 0.4 loaded
(major 252)
[    1.253820] io scheduler noop registered
[    1.253888] io scheduler deadline registered
[    1.253960] io scheduler cfq registered (default)
[    1.254124] pcieport 0000:00:01.0: device [8086:3408] has invalid IRQ;
check vendor BIOS
[    1.254277] pcieport 0000:00:02.0: device [8086:3409] has invalid IRQ;
check vendor BIOS
[    1.254425] pcieport 0000:00:03.0: device [8086:340a] has invalid IRQ;
check vendor BIOS
[    1.254573] pcieport 0000:00:05.0: device [8086:340c] has invalid IRQ;
check vendor BIOS
[    1.254723] pcieport 0000:00:07.0: device [8086:340e] has invalid IRQ;
check vendor BIOS
[    1.254870] pcieport 0000:00:09.0: device [8086:3410] has invalid IRQ;
check vendor BIOS
[    1.255019] pcieport 0000:00:1c.0: device [8086:3a40] has invalid IRQ;
check vendor BIOS
[    1.255170] pcieport 0000:00:1c.4: device [8086:3a48] has invalid IRQ;
check vendor BIOS
[    1.255389] ioapic: probe of 0000:00:15.0 failed with error -22
[    1.255467] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[    1.255554] pciehp: PCI Express Hot Plug Controller Driver version: 0.4
[    1.255627] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
[    1.255752] intel_idle: does not run on family 6 model 44
[    1.255833] Event-channel device installed.
[    1.255989] xen-pciback: backend is vpci
[    1.256298] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    1.277599] serial8250: ttyS0 at I/O 0x3f8 (irq =3D 4) is a 16550A
[    1.298917] serial8250: ttyS1 at I/O 0x2f8 (irq =3D 3) is a 16550A
[    1.299221] Linux agpgart interface v0.103
[    1.299387] i8042: PNP: No PS/2 controller found. Probing ports directly=
.
[    1.551430] serio: i8042 KBD port at 0x60,0x64 irq 1
[    1.551580] mousedev: PS/2 mouse device common for all mice
[    1.551800] rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0
[    1.551897] rtc0: alarms up to one day, 114 bytes nvram
[    1.551972] EFI Variables Facility v0.08 2004-May-17
[    1.552053] drop_monitor: Initializing network drop monitor service
[    1.552197] TCP: cubic registered
[    1.552276] NET: Registered protocol family 10
[    1.552496] mip6: Mobile IPv6
[    1.552564] NET: Registered protocol family 17
[    1.552641] Key type dns_resolver registered
[    1.552859] PM: Hibernation image not present or could not be loaded.
[    1.552868] registered taskstats version 1
[    1.553635] rtc_cmos rtc_cmos: setting system clock to 2012-10-11
03:25:15 UTC (1349925915)
[    1.553954] Freeing unused kernel memory: 592k freed
[    1.554130] Write protecting the kernel read-only data: 6144k
[    1.555798] Freeing unused kernel memory: 512k freed
[    1.556107] Freeing unused kernel memory: 620k freed
[    1.583588] udevd[50]: starting version 175
[    1.657119] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[    1.663281] SCSI subsystem initialized
[    1.681024] megasas: 00.00.06.15-rc1 Mon. Mar. 19 17:00:00 PDT 2012
[    1.681111] megasas: 0x1000:0x0073:0x1014:0x03b1: bus 1:slot 0:func 0
[    1.681241] megaraid_sas 0000:01:00.0: can't find IRQ for PCI INT A;
please try using pci=3Dbiosirq
[    1.687892] megasas: FW now in Ready state
[    1.735350] megasas_init_mfi: fw_support_ieee=3D67108864
[    1.735407] megasas: INIT adapter done
[    1.807365] scsi0 : LSI SAS based MegaRAID driver
[    1.808799] scsi 0:0:8:0: Direct-Access     IBM-ESXS ST9146803SS
 B53C PQ: 0 ANSI: 5
[    1.811249] scsi 0:0:9:0: Direct-Access     ATA      ST9500620NS
 BE24 PQ: 0 ANSI: 5
[    1.812739] scsi 0:0:10:0: Direct-Access     ATA      ST9500620NS
 BE24 PQ: 0 ANSI: 5
[    1.824208] scsi 0:2:0:0: Direct-Access     IBM      ServeRAID M1015
 2.12 PQ: 0 ANSI: 5
[    1.839755] sd 0:2:0:0: [sdb] 1949216768 512-byte logical blocks: (997
GB/929 GiB)
[    1.840060] sd 0:2:0:0: [sdb] Write Protect is off
[    1.840141] sd 0:2:0:0: [sdb] Mode Sense: 1f 00 10 08
[    1.840153] sd 0:0:8:0: [sda] 286748000 512-byte logical blocks: (146
GB/136 GiB)
[    1.840302] sd 0:2:0:0: [sdb] Write cache: disabled, read cache:
disabled, supports DPO and FUA
[    1.842564] sd 0:0:8:0: [sda] Write Protect is off
[    1.842637] sd 0:0:8:0: [sda] Mode Sense: c3 00 10 08
[    1.843418]  sdb: sdb1
[    1.843898] sd 0:0:8:0: [sda] Write cache: disabled, read cache:
enabled, supports DPO and FUA
[    1.844117] sd 0:2:0:0: [sdb] Attached SCSI disk
[    1.866028]  sda: sda1 sda2 sda3 sda4
[    1.870498] sd 0:0:8:0: [sda] Attached SCSI disk
[    2.053157] device-mapper: uevent: version 1.0.3
[    2.053610] device-mapper: ioctl: 4.23.0-ioctl (2012-07-25) initialised:
dm-devel@redhat.com
[    2.214131] EXT4-fs (dm-0): mounted filesystem with ordered data mode.
Opts: (null)
[    3.162111] udevd[298]: starting version 175
[    3.419449] bnx2: Broadcom NetXtreme II Gigabit Ethernet Driver bnx2
v2.2.3 (June 27, 2012)
[    3.419565] bnx2 0000:0b:00.0: can't find IRQ for PCI INT A; please try
using pci=3Dbiosirq
[    3.420241] bnx2 0000:0b:00.0: eth0: Broadcom NetXtreme II BCM5709
1000Base-T (C0) PCI Express found at mem 92000000, IRQ 0, node addr
34:40:b5:ab:e5:b4
[    3.421062] bnx2 0000:0b:00.1: can't find IRQ for PCI INT B; please try
using pci=3Dbiosirq
[    3.421705] bnx2 0000:0b:00.1: eth1: Broadcom NetXtreme II BCM5709
1000Base-T (C0) PCI Express found at mem 94000000, IRQ 0, node addr
34:40:b5:ab:e5:b6
[    3.428805] dca service started, version 1.12.1
[    3.467169] EDAC MC: Ver: 3.0.0
[    3.473824] ioatdma: Intel(R) QuickData Technology Driver 4.00
[    3.473918] ioatdma 0000:00:16.0: enabling device (0000 -> 0002)
[    3.473996] ioatdma 0000:00:16.0: can't find IRQ for PCI INT A; please
try using pci=3Dbiosirq
[    3.474116] ioatdma 0000:00:16.0: channel error register unreachable
[    3.474191] ioatdma 0000:00:16.0: channel enumeration error
[    3.505302] microcode: CPU0 sig=3D0x206c2, pf=3D0x1, revision=3D0x15
[    3.505995] ioatdma 0000:00:16.0: Intel(R) I/OAT DMA Engine init failed
[    3.506096] ioatdma 0000:00:16.1: enabling device (0000 -> 0002)
[    3.506173] ioatdma 0000:00:16.1: can't find IRQ for PCI INT B; please
try using pci=3Dbiosirq
[    3.506296] ioatdma 0000:00:16.1: channel error register unreachable
[    3.506369] ioatdma 0000:00:16.1: channel enumeration error
[    3.506441] ioatdma 0000:00:16.1: Intel(R) I/OAT DMA Engine init failed
[    3.506532] ioatdma 0000:00:16.2: enabling device (0000 -> 0002)
[    3.506608] ioatdma 0000:00:16.2: can't find IRQ for PCI INT C; please
try using pci=3Dbiosirq
[    3.506722] ioatdma 0000:00:16.2: channel error register unreachable
[    3.506795] ioatdma 0000:00:16.2: channel enumeration error
[    3.506867] ioatdma 0000:00:16.2: Intel(R) I/OAT DMA Engine init failed
[    3.506957] ioatdma 0000:00:16.3: enabling device (0000 -> 0002)
[    3.507034] ioatdma 0000:00:16.3: can't find IRQ for PCI INT D; please
try using pci=3Dbiosirq
[    3.507147] ioatdma 0000:00:16.3: channel error register unreachable
[    3.507222] ioatdma 0000:00:16.3: channel enumeration error
[    3.507294] ioatdma 0000:00:16.3: Intel(R) I/OAT DMA Engine init failed
[    3.507398] ioatdma 0000:00:16.4: enabling device (0000 -> 0002)
[    3.507476] ioatdma 0000:00:16.4: can't find IRQ for PCI INT A; please
try using pci=3Dbiosirq
[    3.507590] ioatdma 0000:00:16.4: channel error register unreachable
[    3.507663] ioatdma 0000:00:16.4: channel enumeration error
[    3.507735] ioatdma 0000:00:16.4: Intel(R) I/OAT DMA Engine init failed
[    3.507826] ioatdma 0000:00:16.5: enabling device (0000 -> 0002)
[    3.507903] ioatdma 0000:00:16.5: can't find IRQ for PCI INT B; please
try using pci=3Dbiosirq
[    3.508016] ioatdma 0000:00:16.5: channel error register unreachable
[    3.508090] ioatdma 0000:00:16.5: channel enumeration error
[    3.508162] ioatdma 0000:00:16.5: Intel(R) I/OAT DMA Engine init failed
[    3.508255] ioatdma 0000:00:16.6: enabling device (0000 -> 0002)
[    3.508337] ioatdma 0000:00:16.6: can't find IRQ for PCI INT C; please
try using pci=3Dbiosirq
[    3.508454] ioatdma 0000:00:16.6: channel error register unreachable
[    3.508529] ioatdma 0000:00:16.6: channel enumeration error
[    3.508601] ioatdma 0000:00:16.6: Intel(R) I/OAT DMA Engine init failed
[    3.508692] ioatdma 0000:00:16.7: enabling device (0000 -> 0002)
[    3.508769] ioatdma 0000:00:16.7: can't find IRQ for PCI INT D; please
try using pci=3Dbiosirq
[    3.508885] ioatdma 0000:00:16.7: channel error register unreachable
[    3.508958] ioatdma 0000:00:16.7: channel enumeration error
[    3.509030] ioatdma 0000:00:16.7: Intel(R) I/OAT DMA Engine init failed
[    3.571248] usbcore: registered new interface driver usbfs
[    3.571330] usbcore: registered new interface driver hub
[    3.585483] ACPI Exception: AE_BAD_PARAMETER, Thread 1786484928 could
not acquire Mutex [0x1] (20120711/utmutex-276)
[    3.585675] ACPI Exception: AE_BAD_PARAMETER, Thread 1786484928 could
not acquire Mutex [0x1] (20120711/utmutex-276)
[    3.590919] usbcore: registered new device driver usb
[    3.603433] input: PC Speaker as /devices/platform/pcspkr/input/input0
[    3.604762] libata version 3.00 loaded.
[    3.607430] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    3.607535] ehci_hcd 0000:00:1a.7: can't find IRQ for PCI INT C; please
try using pci=3Dbiosirq
[    3.607629] ehci_hcd 0000:00:1a.7: Found HC with no IRQ.  Check BIOS/PCI
0000:00:1a.7 setup!
[    3.607723] ehci_hcd 0000:00:1a.7: init 0000:00:1a.7 fail, -19
[    3.607808] ehci_hcd 0000:00:1d.7: can't find IRQ for PCI INT A; please
try using pci=3Dbiosirq
[    3.607900] ehci_hcd 0000:00:1d.7: Found HC with no IRQ.  Check BIOS/PCI
0000:00:1d.7 setup!
[    3.607994] ehci_hcd 0000:00:1d.7: init 0000:00:1d.7 fail, -19
[    3.623701] i801_smbus 0000:00:1f.3: enabling device (0140 -> 0143)
[    3.623781] i801_smbus 0000:00:1f.3: can't find IRQ for PCI INT B;
please try using pci=3Dbiosirq
[    3.623874] ACPI Exception: AE_BAD_PARAMETER, Thread 1775910976 could
not acquire Mutex [0x1] (20120711/utmutex-276)
[    3.624093] i801_smbus 0000:00:1f.3: SMBus using PCI Interrupt
[    3.676083] ata_piix 0000:00:1f.2: version 2.13
[    3.676095] ata_piix 0000:00:1f.2: can't find IRQ for PCI INT A; please
try using pci=3Dbiosirq
[    3.676193] ata_piix 0000:00:1f.2: MAP [
[    3.676260]  P0 P2 P1 P3 ]
[    3.676539] ata_piix 0000:00:1f.2: setting latency timer to 64
[    3.677344] scsi1 : ata_piix
[    3.677732] scsi2 : ata_piix
[    3.677862] ata1: SATA max UDMA/133 cmd 0x2118 ctl 0x212c bmdma 0x20f0
[    3.677954] ata2: SATA max UDMA/133 cmd 0x2110 ctl 0x2128 bmdma 0x20f8
[    3.678154] gpio_ich: GPIO from 195 to 255 on gpio_ich
[    3.678606] ata_piix 0000:00:1f.5: can't find IRQ for PCI INT C; please
try using pci=3Dbiosirq
[    3.678703] ata_piix 0000:00:1f.5: MAP [
[    3.678771]  P0 -- P1 -- ]
[    3.679046] ata_piix 0000:00:1f.5: setting latency timer to 64
[    3.679562] scsi3 : ata_piix
[    3.680057] uhci_hcd: USB Universal Host Controller Interface driver
[    3.682601] scsi4 : ata_piix
[    3.682814] ata3: SATA max UDMA/133 cmd 0x2108 ctl 0x2124 bmdma 0x20d0
[    3.682893] ata4: SATA max UDMA/133 cmd 0x2100 ctl 0x2120 bmdma 0x20d8
[    3.683028] uhci_hcd 0000:00:1a.0: can't find IRQ for PCI INT A; please
try using pci=3Dbiosirq
[    3.683123] uhci_hcd 0000:00:1a.0: Found HC with no IRQ.  Check BIOS/PCI
0000:00:1a.0 setup!
[    3.683217] uhci_hcd 0000:00:1a.0: init 0000:00:1a.0 fail, -19
[    3.683300] uhci_hcd 0000:00:1a.1: can't find IRQ for PCI INT B; please
try using pci=3Dbiosirq
[    3.683408] uhci_hcd 0000:00:1a.1: Found HC with no IRQ.  Check BIOS/PCI
0000:00:1a.1 setup!
[    3.683504] uhci_hcd 0000:00:1a.1: init 0000:00:1a.1 fail, -19
[    3.683588] uhci_hcd 0000:00:1d.0: can't find IRQ for PCI INT A; please
try using pci=3Dbiosirq
[    3.683682] uhci_hcd 0000:00:1d.0: Found HC with no IRQ.  Check BIOS/PCI
0000:00:1d.0 setup!
[    3.683802] uhci_hcd 0000:00:1d.0: init 0000:00:1d.0 fail, -19
[    3.683933] uhci_hcd 0000:00:1d.1: can't find IRQ for PCI INT B; please
try using pci=3Dbiosirq
[    3.684026] uhci_hcd 0000:00:1d.1: Found HC with no IRQ.  Check BIOS/PCI
0000:00:1d.1 setup!
[    3.684121] uhci_hcd 0000:00:1d.1: init 0000:00:1d.1 fail, -19
[    3.684201] uhci_hcd 0000:00:1d.2: can't find IRQ for PCI INT C; please
try using pci=3Dbiosirq
[    3.684293] uhci_hcd 0000:00:1d.2: Found HC with no IRQ.  Check BIOS/PCI
0000:00:1d.2 setup!
[    3.684387] uhci_hcd 0000:00:1d.2: init 0000:00:1d.2 fail, -19
[    3.751594] microcode: Microcode Update Driver: v2.00 <
tigran@aivazian.fsnet.co.uk>, Peter Oruba
[    3.771183] iTCO_vendor_support: vendor-support=3D0
[    4.010635] ata3: SATA link down (SStatus 0 SControl 300)
[    4.022013] ata4: SATA link down (SStatus 0 SControl 300)
[    4.342660] ata2.00: SATA link down (SStatus 0 SControl 300)
[    4.342751] ata2.01: SATA link down (SStatus 0 SControl 300)
[    4.487426] ata1.00: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[    4.487519] ata1.01: SATA link down (SStatus 0 SControl 300)
[    4.487603] ata1.01: link offline, clearing class 3 to NONE
[    4.495491] ata1.00: ATAPI: IBM SATA DEVICE 81Y3657, IB01, max UDMA/33
[    4.511489] ata1.00: configured for UDMA/33
[    9.511364] ata1.00: qc timeout (cmd 0xa0)
[    9.511434] ata1.00: TEST_UNIT_READY failed (err_mask=3D0x5)
[   10.307422] ata1.00: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   10.307515] ata1.01: SATA link down (SStatus 0 SControl 300)
[   10.307600] ata1.01: link offline, clearing class 3 to NONE
[   10.331487] ata1.00: configured for UDMA/33
[   15.331361] ata1.00: qc timeout (cmd 0xa0)
[   15.331431] ata1.00: TEST_UNIT_READY failed (err_mask=3D0x5)
[   15.331504] ata1.00: limiting SATA link speed to 1.5 Gbps
[   15.331574] ata1.00: limiting speed to UDMA/33:PIO3
[   16.127423] ata1.00: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[   16.127515] ata1.01: SATA link down (SStatus 0 SControl 300)
[   16.127601] ata1.01: link offline, clearing class 3 to NONE
[   16.151487] ata1.00: configured for UDMA/33
[   21.151378] ata1.00: qc timeout (cmd 0xa0)
[   21.151448] ata1.00: TEST_UNIT_READY failed (err_mask=3D0x5)
[   21.151518] ata1.00: disabled
[   21.151603] ata1.00: hard resetting link
[   21.471351] ata1.01: hard resetting link
[   21.947430] ata1.00: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[   21.947523] ata1.01: SATA link down (SStatus 0 SControl 300)
[   21.947608] ata1.01: link offline, clearing class 3 to NONE
[   21.947611] ata1: EH complete
[   21.963868] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.10
[   21.963965] iTCO_wdt: Found a ICH10 TCO device (Version=3D2,
TCOBASE=3D0x05e0)
[   21.964124] iTCO_wdt: initialized. heartbeat=3D30 sec (nowayout=3D0)
[   21.997872] Error: Driver 'pcspkr' is already registered, aborting...
[   22.010315] alg: No test for __gcm-aes-aesni (__driver-gcm-aes-aesni)
[   22.995255] EXT4-fs (dm-0): re-mounted. Opts: (null)
[   23.177611] EXT4-fs (dm-0): re-mounted. Opts: errors=3Dremount-ro
[   23.281974] loop: module loaded
[   23.346661] lp: driver loaded but no devices found
[   24.043404] Adding 4194300k swap on /dev/mapper/xen-fw_swap.
 Priority:-1 extents:1 across:4194300k
[   24.347072] EXT4-fs (sda3): mounted filesystem with ordered data mode.
Opts: (null)
[   24.386139] FAT-fs (sda2): utf8 is not a recommended IO charset for FAT
filesystems, filesystem will be case sensitive!
[   25.140294] bnx2 0000:0b:00.0: eth0: using MSIX
[   25.140439] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   25.181911] Bridge firewalling registered
[   25.186131] device eth1 entered promiscuous mode
[   25.288312] bnx2 0000:0b:00.1: eth1: using MSIX
[   25.288410] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[   25.290413] IPv6: ADDRCONF(NETDEV_UP): xenbr0: link is not ready
[   26.898999] bnx2 0000:0b:00.0: eth0: NIC Copper Link is Up, 100 Mbps
full duplex
[   26.899091]
[   26.899222] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   28.981380] bnx2 0000:0b:00.1: eth1: NIC Copper Link is Up, 1000 Mbps
full duplex
[   28.981477]
[   28.981613] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[   28.981698] xenbr0: port 1(eth1) entered forwarding state
[   28.981771] xenbr0: port 1(eth1) entered forwarding state
[   28.981850] IPv6: ADDRCONF(NETDEV_CHANGE): xenbr0: link becomes ready
[   33.512189] RPC: Registered named UNIX socket transport module.
[   33.512281] RPC: Registered udp transport module.
[   33.512351] RPC: Registered tcp transport module.
[   33.512420] RPC: Registered tcp NFSv4.1 backchannel transport module.
[   33.533692] FS-Cache: Loaded
[   33.547314] FS-Cache: Netfs 'nfs' registered for caching
[   33.579870] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
[   34.845026] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
[   34.854870] ip_tables: (C) 2000-2006 Netfilter Core Team
[   35.475210] ppdev: user-space parallel port driver
[   39.140866] colord-sane[2701]: segfault at 0 ip 00007fc826bc4884 sp
00007fff6a44fea0 error 4 in libc-2.13.so[7fc826b1f000+17d000]
[   44.011341] xenbr0: port 1(eth1) entered forwarding state


Thanks for all,
Allan Scheid




--=20
*Att,*
*Allan Vicente Scheid*
*Acad=EAmico de Ci=EAncia da Computa=E7=E3o - Unioeste Foz*

--14dae934109feecd8704cbc0e07e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hellow all, i need help with this bug:
=

ACPI BIOS Bug: Error: A valid RSDP was not found (20120711/t=
bxfroot-219)

Because of this first errors i get th=
is second error, and it causes don't work USB ports and some PCI cards =
on the system:




can't find IRQ for PCI INT A; please try using pci=
=3Dbiosirq

This occours only when i try boot with =
xen multiboot (with hypervisor), if i boot only kernel with xen extensions =
no has errors in dmesg.



Kernel:=A03.6.1-xen self compiled (work perfect without=
 xen multiboot)
Xen Version: 4.2
Grub2 EFI: 1.99-23

Debian Unstable distro
Server: IBM System x3650 M3 7945AC1

dmesg output:

[ =A0 =
=A00.000000] Initializing cgroup subsys cpuset
[ =A0 =A00.000000]=
 Initializing cgroup subsys cpu


[ =A0 =A00.000000] Linux version 3.6.1-xen (root@lca-fw) (gcc version =
4.7.1 (Debian 4.7.1-7) ) #1 SMP Wed Oct 10 22:46:05 BRT 2012


[ =A0 =A00.000000] Command line: placeholder root=3D/dev/mapper/xen-fw=
_root ro
[ =A0 =A00.000000] Freeing 6c-6d pfn range: 1 pages free=
d
[ =A0 =A00.000000] 1-1 mapping on 6c->6d
[ =A0 =A0=
0.000000] Freeing 9f-100 pfn range: 97 pages freed



[ =A0 =A00.000000] 1-1 mapping on 9f->100
[ =A0 =A00.0000=
00] Freeing 7acb7-7ccb8 pfn range: 8193 pages freed
[ =A0 =A00.00=
0000] 1-1 mapping on 7acb7->7ccb8
[ =A0 =A00.000000] Freeing 7=
d4f0-7d51b pfn range: 43 pages freed



[ =A0 =A00.000000] 1-1 mapping on 7d4f0->7d51b
[ =A0 =A00=
.000000] Freeing 7d53f-7d56a pfn range: 43 pages freed
[ =A0 =A00=
.000000] 1-1 mapping on 7d53f->7d56a
[ =A0 =A00.000000] Freein=
g 7d704-7d7b4 pfn range: 176 pages freed



[ =A0 =A00.000000] 1-1 mapping on 7d704->7d7b4
[ =A0 =A00=
.000000] Freeing 7f5ef-7f7ff pfn range: 528 pages freed
[ =A0 =A0=
0.000000] 1-1 mapping on 7f5ef->7f7ff
[ =A0 =A00.000000] Freei=
ng 7f800-f258d pfn range: 470413 pages freed



[ =A0 =A00.000000] 1-1 mapping on 7f800->100000
[ =A0 =A0=
0.000000] Released 479494 pages of unused memory
[ =A0 =A00.00000=
0] Set 535417 page(s) to 1-1 mapping
[ =A0 =A00.000000] Populatin=
g 100000-175106 pfn range: 479494 pages added



[ =A0 =A00.000000] e820: BIOS-provided physical RAM map:
[ =
=A0 =A00.000000] Xen: [mem 0x0000000000000000-0x000000000006bfff] usable
[ =A0 =A00.000000] Xen: [mem 0x000000000006c000-0x000000000006cfff]=
 ACPI NVS



[ =A0 =A00.000000] Xen: [mem 0x000000000006d000-0x000000000009efff] us=
able
[ =A0 =A00.000000] Xen: [mem 0x000000000009f000-0x0000000000=
09ffff] ACPI NVS
[ =A0 =A00.000000] Xen: [mem 0x00000000000a0000-=
0x00000000000fffff] reserved



[ =A0 =A00.000000] Xen: [mem 0x0000000000100000-0x000000007acb6fff] us=
able
[ =A0 =A00.000000] Xen: [mem 0x000000007acb7000-0x000000007c=
cb7fff] reserved
[ =A0 =A00.000000] Xen: [mem 0x000000007ccb8000-=
0x000000007d4effff] usable



[ =A0 =A00.000000] Xen: [mem 0x000000007d4f0000-0x000000007d51afff] re=
served
[ =A0 =A00.000000] Xen: [mem 0x000000007d51b000-0x00000000=
7d53efff] usable
[ =A0 =A00.000000] Xen: [mem 0x000000007d53f000-=
0x000000007d569fff] reserved



[ =A0 =A00.000000] Xen: [mem 0x000000007d56a000-0x000000007d703fff] us=
able
[ =A0 =A00.000000] Xen: [mem 0x000000007d704000-0x000000007d=
7b3fff] reserved
[ =A0 =A00.000000] Xen: [mem 0x000000007d7b4000-=
0x000000007f5eefff] usable



[ =A0 =A00.000000] Xen: [mem 0x000000007f5ef000-0x000000007f6defff] re=
served
[ =A0 =A00.000000] Xen: [mem 0x000000007f6df000-0x00000000=
7f7defff] ACPI NVS
[ =A0 =A00.000000] Xen: [mem 0x000000007f7df00=
0-0x000000007f7fefff] ACPI data



[ =A0 =A00.000000] Xen: [mem 0x000000007f7ff000-0x000000007f7fffff] us=
able
[ =A0 =A00.000000] Xen: [mem 0x0000000080000000-0x000000008f=
ffffff] reserved
[ =A0 =A00.000000] Xen: [mem 0x00000000fed1c000-=
0x00000000fed1ffff] reserved



[ =A0 =A00.000000] Xen: [mem 0x00000000fee00000-0x00000000fee00fff] re=
served
[ =A0 =A00.000000] Xen: [mem 0x00000000ff800000-0x00000000=
ffffffff] reserved
[ =A0 =A00.000000] Xen: [mem 0x000000010000000=
0-0x000000017fffffff] usable



[ =A0 =A00.000000] NX (Execute Disable) protection: active
[=
 =A0 =A00.000000] DMI 2.5 present.
[ =A0 =A00.000000] DMI: IBM Sy=
stem x3650 M3 -[7945AC1]-/00D4062, BIOS -[D6E157AUS-1.15]- 06/13/2012
=

[ =A0 =A00.000000] e820: update [mem 0x00000000-0x0000ffff] usable =3D=
=3D> reserved



[ =A0 =A00.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[ =A0 =A00.000000] No AGP bridge found
[ =A0 =A00.000000] =
e820: last_pfn =3D 0x180000 max_arch_pfn =3D 0x400000000
[ =A0 =
=A00.000000] e820: last_pfn =3D 0x7f800 max_arch_pfn =3D 0x400000000



[ =A0 =A00.000000] initial memory mapped: [mem 0x00000000-0x02334fff]<=
/div>
[ =A0 =A00.000000] Base memory trampoline at [ffff880000099000] 9=
9000 size 24576
[ =A0 =A00.000000] init_memory_mapping: [mem 0x00=
000000-0x7f7fffff]



[ =A0 =A00.000000] =A0[mem 0x00000000-0x7f7fffff] page 4k
[ =
=A0 =A00.000000] kernel direct mapping tables up to 0x7f7fffff @ [mem 0x018=
31000-0x01c2ffff]
[ =A0 =A00.000000] xen: setting RW the range 1c=
14000 - 1c30000



[ =A0 =A00.000000] init_memory_mapping: [mem 0x100000000-0x17fffffff]<=
/div>
[ =A0 =A00.000000] =A0[mem 0x100000000-0x17fffffff] page 4k
=

[ =A0 =A00.000000] kernel direct mapping tables up to 0x17fffffff @ [m=
em 0x7e9e8000-0x7f5eefff]



[ =A0 =A00.000000] xen: setting RW the range 7edea000 - 7f5ef000
=

[ =A0 =A00.000000] RAMDISK: [mem 0x01c30000-0x02334fff]
[ =
=A0 =A00.000000] ACPI BIOS Bug: Error: A valid RSDP was not found (20120711=
/tbxfroot-219)



[ =A0 =A00.000000] NUMA turned off
[ =A0 =A00.000000] Faking=
 a node at [mem 0x0000000000000000-0x000000017fffffff]
[ =A0 =A00=
.000000] Initmem setup node 0 [mem 0x00000000-0x17fffffff]
[ =A0 =
=A00.000000] =A0 NODE_DATA [mem 0x175102000-0x175105fff]



[ =A0 =A00.000000] Zone ranges:
[ =A0 =A00.000000] =A0 DMA =
=A0 =A0 =A0[mem 0x00010000-0x00ffffff]
[ =A0 =A00.000000] =A0 DMA=
32 =A0 =A0[mem 0x01000000-0xffffffff]
[ =A0 =A00.000000] =A0 Norm=
al =A0 [mem 0x100000000-0x17fffffff]



[ =A0 =A00.000000] Movable zone start for each node
[ =A0 =
=A00.000000] Early memory node ranges
[ =A0 =A00.000000] =A0 node=
 =A0 0: [mem 0x00010000-0x0006bfff]
[ =A0 =A00.000000] =A0 node =
=A0 0: [mem 0x0006d000-0x0009efff]



[ =A0 =A00.000000] =A0 node =A0 0: [mem 0x00100000-0x7acb6fff]
[ =A0 =A00.000000] =A0 node =A0 0: [mem 0x7ccb8000-0x7d4effff]
[ =A0 =A00.000000] =A0 node =A0 0: [mem 0x7d51b000-0x7d53efff]
[=
 =A0 =A00.000000] =A0 node =A0 0: [mem 0x7d56a000-0x7d703fff]



[ =A0 =A00.000000] =A0 node =A0 0: [mem 0x7d7b4000-0x7f5eefff]
[ =A0 =A00.000000] =A0 node =A0 0: [mem 0x7f7ff000-0x7f7fffff]
[ =A0 =A00.000000] =A0 node =A0 0: [mem 0x100000000-0x17fffffff]
[ =A0 =A00.000000] On node 0 totalpages: 1037431



[ =A0 =A00.000000] =A0 DMA zone: 56 pages used for memmap
[ =
=A0 =A00.000000] =A0 DMA zone: 6 pages reserved
[ =A0 =A00.000000=
] =A0 DMA zone: 3920 pages, LIFO batch:0
[ =A0 =A00.000000] =A0 D=
MA32 zone: 14280 pages used for memmap



[ =A0 =A00.000000] =A0 DMA32 zone: 494881 pages, LIFO batch:31
[ =A0 =A00.000000] =A0 Normal zone: 7168 pages used for memmap
[ =A0 =A00.000000] =A0 Normal zone: 517120 pages, LIFO batch:31
=
[ =A0 =A00.000000] SFI: Simple Firmware Interface v0.81 http://simplefirmware.org



[ =A0 =A00.000000] smpboot: Allowing 1 CPUs, 0 hotplug CPUs
=
[ =A0 =A00.000000] nr_irqs_gsi: 16
[ =A0 =A00.000000] PM: Registe=
red nosave memory: 000000000006c000 - 000000000006d000
[ =A0 =A00=
.000000] PM: Registered nosave memory: 000000000009f000 - 00000000000a0000<=
/div>


[ =A0 =A00.000000] PM: Registered nosave memory: 00000000000a0000 - 00=
00000000100000
[ =A0 =A00.000000] PM: Registered nosave memory: 0=
00000007acb7000 - 000000007ccb8000
[ =A0 =A00.000000] PM: Registe=
red nosave memory: 000000007d4f0000 - 000000007d51b000



[ =A0 =A00.000000] PM: Registered nosave memory: 000000007d53f000 - 00=
0000007d56a000
[ =A0 =A00.000000] PM: Registered nosave memory: 0=
00000007d704000 - 000000007d7b4000
[ =A0 =A00.000000] PM: Registe=
red nosave memory: 000000007f5ef000 - 000000007f6df000



[ =A0 =A00.000000] PM: Registered nosave memory: 000000007f6df000 - 00=
0000007f7df000
[ =A0 =A00.000000] PM: Registered nosave memory: 0=
00000007f7df000 - 000000007f7ff000
[ =A0 =A00.000000] PM: Registe=
red nosave memory: 000000007f800000 - 0000000080000000



[ =A0 =A00.000000] PM: Registered nosave memory: 0000000080000000 - 00=
00000090000000
[ =A0 =A00.000000] PM: Registered nosave memory: 0=
000000090000000 - 00000000fed1c000
[ =A0 =A00.000000] PM: Registe=
red nosave memory: 00000000fed1c000 - 00000000fed20000



[ =A0 =A00.000000] PM: Registered nosave memory: 00000000fed20000 - 00=
000000fee00000
[ =A0 =A00.000000] PM: Registered nosave memory: 0=
0000000fee00000 - 00000000fee01000
[ =A0 =A00.000000] PM: Registe=
red nosave memory: 00000000fee01000 - 00000000ff800000



[ =A0 =A00.000000] PM: Registered nosave memory: 00000000ff800000 - 00=
00000100000000
[ =A0 =A00.000000] e820: [mem 0x90000000-0xfed1bff=
f] available for PCI devices
[ =A0 =A00.000000] Booting paravirtu=
alized kernel on Xen



[ =A0 =A00.000000] Xen version: 4.2.0 (preserve-AD)
[ =A0 =
=A00.000000] setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:1 nr_=
node_ids:1
[ =A0 =A00.000000] PERCPU: Embedded 28 pages/cpu @ffff=
880174e00000 s83840 r8192 d22656 u2097152



[ =A0 =A00.000000] pcpu-alloc: s83840 r8192 d22656 u2097152 alloc=3D1*=
2097152
[ =A0 =A00.000000] pcpu-alloc: [0] 0=A0
[ =A0 =
=A01.096975] Built 1 zonelists in Zone order, mobility grouping on. =A0Tota=
l pages: 1015921



[ =A0 =A01.096977] Policy zone: Normal
[ =A0 =A01.096979] Ke=
rnel command line: placeholder root=3D/dev/mapper/xen-fw_root ro
=
[ =A0 =A01.097016] PID hash table entries: 4096 (order: 3, 32768 bytes)
[ =A0 =A01.097021] __ex_table already sorted, skipping sort



[ =A0 =A01.121932] software IO TLB [mem 0x16c800000-0x1707fffff] (64MB=
) mapped at [ffff88016c800000-ffff8801707fffff]
[ =A0 =A01.138656=
] Memory: 3815116k/6291456k available (3573k kernel code, 2141732k absent, =
334608k reserved, 3147k data, 592k init)



[ =A0 =A01.138717] Hierarchical RCU implementation.
[ =A0 =
=A01.138718] 	RCU dyntick-idle =
grace-period acceleration is enabled.
[ =A0 =A01.138719] 	RCU restricting CPUs from NR_CPUS=3D51=
2 to nr_cpu_ids=3D1.



[ =A0 =A01.138728] NR_IRQS:33024 nr_irqs:256 16
[ =A0 =A01.1=
47171] Console: colour VGA+ 80x25
[ =A0 =A01.154296] console [tty=
0] enabled
[ =A0 =A01.159002] allocated 16777216 bytes of page_cg=
roup


[ =A0 =A01.159079] please try 'cgroup_disable=3Dmemory' option if y=
ou don't want memory cgroups
[ =A0 =A01.159208] Xen: using vc=
puop timer interface
[ =A0 =A01.159214] installing Xen timer for =
CPU 0



[ =A0 =A01.159303] tsc: Detected 2400.126 MHz processor
[ =
=A0 =A01.159375] Calibrating delay loop (skipped), value calculated using t=
imer frequency.. 4800.25 BogoMIPS (lpj=3D9600504)
[ =A0 =A01.1595=
17] pid_max: default: 32768 minimum: 301



[ =A0 =A01.159607] Security Framework initialized
[ =A0 =A01=
.159680] AppArmor: AppArmor disabled by boot time parameter
[ =A0=
 =A01.160298] Dentry cache hash table entries: 524288 (order: 10, 4194304 b=
ytes)



[ =A0 =A01.161752] Inode-cache hash table entries: 262144 (order: 9, 2=
097152 bytes)
[ =A0 =A01.162415] Mount-cache hash table entries: =
256
[ =A0 =A01.162658] Initializing cgroup subsys cpuacct
[ =A0 =A01.162729] Initializing cgroup subsys memory



[ =A0 =A01.162806] Initializing cgroup subsys devices
[ =A0 =
=A01.162876] Initializing cgroup subsys freezer
[ =A0 =A01.162945=
] Initializing cgroup subsys net_cls
[ =A0 =A01.163014] Initializ=
ing cgroup subsys blkio



[ =A0 =A01.163082] Initializing cgroup subsys perf_event
[ =
=A0 =A01.163204] CPU: Physical Processor ID: 0
[ =A0 =A01.163277]=
 CPU: Processor Core ID: 0
[ =A0 =A01.163346] mce: CPU supports 2=
 MCE banks



[ =A0 =A01.163452] Last level iTLB entries: 4KB 512, 2MB 7, 4MB 7
[ =A0 =A01.163452] Last level dTLB entries: 4KB 512, 2MB 32, 4MB 32
[ =A0 =A01.163452] tlb_flushall_shift is 0x6
[ =A0 =A01.=
163602] SMP alternatives: switching to UP code



[ =A0 =A01.171342] Freeing SMP alternatives: 8k freed
[ =A0 =
=A01.171471] Performance Events: unsupported p6 CPU model 44 no PMU driver,=
 software events only.
[ =A0 =A01.171785] NMI watchdog: disabled =
(cpu0): hardware events not enabled



[ =A0 =A01.171876] Brought up 1 CPUs
[ =A0 =A01.172058] devt=
mpfs: initialized
[ =A0 =A01.174970] PM: Registering ACPI NVS reg=
ion [mem 0x0006c000-0x0006cfff] (4096 bytes)
[ =A0 =A01.175062] P=
M: Registering ACPI NVS region [mem 0x0009f000-0x0009ffff] (4096 bytes)


[ =A0 =A01.175153] PM: Registering ACPI NVS region [mem 0x7f6df000-0x7=
f7defff] (1048576 bytes)
[ =A0 =A01.175314] Grant tables using ve=
rsion 2 layout.
[ =A0 =A01.175394] Grant table initialized
<=
div>[ =A0 =A01.175514] dummy:=A0



[ =A0 =A01.175625] NET: Registered protocol family 16
[ =A0 =
=A01.175969] PCI: Using configuration type 1 for base access
[ =
=A0 =A01.176599] bio: create slab <bio-0> at 0
[ =A0 =A01.1=
76719] ACPI: Interpreter disabled.



[ =A0 =A01.176796] xen/balloon: Initialising balloon driver.
[ =A0 =A01.177620] xen-balloon: Initialising balloon driver.
[ =
=A0 =A01.177761] vgaarb: loaded
[ =A0 =A01.177860] PCI: Probing P=
CI hardware



[ =A0 =A01.177929] PCI: root bus 00: using default resources
[ =A0 =A01.177930] PCI: Probing PCI hardware (bus 00)
[ =A0 =A01=
.177954] PCI host bridge to bus 0000:00
[ =A0 =A01.178025] pci_bu=
s 0000:00: root bus resource [io =A00x0000-0xffff]



[ =A0 =A01.178098] pci_bus 0000:00: root bus resource [mem 0x00000000-=
0xffffffffff]
[ =A0 =A01.178173] pci_bus 0000:00: No busn resourc=
e found for root bus, will use [bus 00-ff]
[ =A0 =A01.178266] pci=
_bus 0000:00: busn_res: [bus 00-ff] is inserted under domain [bus 00-ff]


[ =A0 =A01.178287] pci 0000:00:00.0: [8086:3406] type 00 class 0x06000=
0
[ =A0 =A01.178389] pci 0000:00:00.0: PME# supported from D0 D3h=
ot D3cold
[ =A0 =A01.178425] pci 0000:00:01.0: [8086:3408] type 0=
1 class 0x060400



[ =A0 =A01.178532] pci 0000:00:01.0: PME# supported from D0 D3hot D3co=
ld
[ =A0 =A01.178571] pci 0000:00:02.0: [8086:3409] type 01 class=
 0x060400
[ =A0 =A01.178678] pci 0000:00:02.0: PME# supported fro=
m D0 D3hot D3cold



[ =A0 =A01.178716] pci 0000:00:03.0: [8086:340a] type 01 class 0x06040=
0
[ =A0 =A01.178824] pci 0000:00:03.0: PME# supported from D0 D3h=
ot D3cold
[ =A0 =A01.178865] pci 0000:00:05.0: [8086:340c] type 0=
1 class 0x060400



[ =A0 =A01.178973] pci 0000:00:05.0: PME# supported from D0 D3hot D3co=
ld
[ =A0 =A01.179013] pci 0000:00:07.0: [8086:340e] type 01 class=
 0x060400
[ =A0 =A01.179121] pci 0000:00:07.0: PME# supported fro=
m D0 D3hot D3cold



[ =A0 =A01.179161] pci 0000:00:09.0: [8086:3410] type 01 class 0x06040=
0
[ =A0 =A01.179269] pci 0000:00:09.0: PME# supported from D0 D3h=
ot D3cold
[ =A0 =A01.179309] pci 0000:00:10.0: [8086:3425] type 0=
0 class 0x080000



[ =A0 =A01.179434] pci 0000:00:10.1: [8086:3426] type 00 class 0x08000=
0
[ =A0 =A01.179543] pci 0000:00:11.0: [8086:3427] type 00 class =
0x080000
[ =A0 =A01.179668] pci 0000:00:11.1: [8086:3428] type 00=
 class 0x080000



[ =A0 =A01.179795] pci 0000:00:14.0: [8086:342e] type 00 class 0x08000=
0
[ =A0 =A01.179919] pci 0000:00:14.1: [8086:3422] type 00 class =
0x080000
[ =A0 =A01.180053] pci 0000:00:14.2: [8086:3423] type 00=
 class 0x080000



[ =A0 =A01.180172] pci 0000:00:14.3: [8086:3438] type 00 class 0x08000=
0
[ =A0 =A01.180273] pci 0000:00:15.0: [8086:342f] type 00 class =
0x080020
[ =A0 =A01.180387] pci 0000:00:16.0: [8086:3430] type 00=
 class 0x088000



[ =A0 =A01.180408] pci 0000:00:16.0: reg 10: [mem 0x97a00000-0x97a03ff=
f 64bit]
[ =A0 =A01.180540] pci 0000:00:16.1: [8086:3431] type 00=
 class 0x088000
[ =A0 =A01.180561] pci 0000:00:16.1: reg 10: [mem=
 0x97a04000-0x97a07fff 64bit]



[ =A0 =A01.180693] pci 0000:00:16.2: [8086:3432] type 00 class 0x08800=
0
[ =A0 =A01.180713] pci 0000:00:16.2: reg 10: [mem 0x97a08000-0x=
97a0bfff 64bit]
[ =A0 =A01.180845] pci 0000:00:16.3: [8086:3433] =
type 00 class 0x088000



[ =A0 =A01.180866] pci 0000:00:16.3: reg 10: [mem 0x97a0c000-0x97a0fff=
f 64bit]
[ =A0 =A01.180997] pci 0000:00:16.4: [8086:3429] type 00=
 class 0x088000
[ =A0 =A01.181018] pci 0000:00:16.4: reg 10: [mem=
 0x97a10000-0x97a13fff 64bit]



[ =A0 =A01.181150] pci 0000:00:16.5: [8086:342a] type 00 class 0x08800=
0
[ =A0 =A01.181170] pci 0000:00:16.5: reg 10: [mem 0x97a14000-0x=
97a17fff 64bit]
[ =A0 =A01.181302] pci 0000:00:16.6: [8086:342b] =
type 00 class 0x088000



[ =A0 =A01.181323] pci 0000:00:16.6: reg 10: [mem 0x97a18000-0x97a1bff=
f 64bit]
[ =A0 =A01.181455] pci 0000:00:16.7: [8086:342c] type 00=
 class 0x088000
[ =A0 =A01.181475] pci 0000:00:16.7: reg 10: [mem=
 0x97a1c000-0x97a1ffff 64bit]



[ =A0 =A01.181610] pci 0000:00:1a.0: [8086:3a37] type 00 class 0x0c030=
0
[ =A0 =A01.181681] pci 0000:00:1a.0: reg 20: [io =A00x20a0-0x20=
bf]
[ =A0 =A01.181766] pci 0000:00:1a.1: [8086:3a38] type 00 clas=
s 0x0c0300



[ =A0 =A01.181837] pci 0000:00:1a.1: reg 20: [io =A00x2080-0x209f]
[ =A0 =A01.181937] pci 0000:00:1a.7: [8086:3a3c] type 00 class 0x0c0=
320
[ =A0 =A01.181970] pci 0000:00:1a.7: reg 10: [mem 0x97a21000-=
0x97a213ff]



[ =A0 =A01.182116] pci 0000:00:1a.7: PME# supported from D0 D3hot D3co=
ld
[ =A0 =A01.182153] pci 0000:00:1c.0: [8086:3a40] type 01 class=
 0x060400
[ =A0 =A01.182274] pci 0000:00:1c.0: PME# supported fro=
m D0 D3hot D3cold



[ =A0 =A01.182316] pci 0000:00:1c.4: [8086:3a48] type 01 class 0x06040=
0
[ =A0 =A01.182435] pci 0000:00:1c.4: PME# supported from D0 D3h=
ot D3cold
[ =A0 =A01.182478] pci 0000:00:1d.0: [8086:3a34] type 0=
0 class 0x0c0300



[ =A0 =A01.182549] pci 0000:00:1d.0: reg 20: [io =A00x2060-0x207f]
[ =A0 =A01.182634] pci 0000:00:1d.1: [8086:3a35] type 00 class 0x0c0=
300
[ =A0 =A01.182705] pci 0000:00:1d.1: reg 20: [io =A00x2040-0x=
205f]



[ =A0 =A01.182790] pci 0000:00:1d.2: [8086:3a36] type 00 class 0x0c0300
[ =A0 =A01.182860] pci 0000:00:1d.2: reg 20: [io =A00x2020-0x203f]
[ =A0 =A01.182960] pci 0000:00:1d.7: [8086:3a3a] type 00 class 0x0=
c0320



[ =A0 =A01.182993] pci 0000:00:1d.7: reg 10: [mem 0x97a20000-0x97a203f=
f]
[ =A0 =A01.183138] pci 0000:00:1d.7: PME# supported from D0 D3=
hot D3cold
[ =A0 =A01.183173] pci 0000:00:1e.0: [8086:244e] type =
01 class 0x060401



[ =A0 =A01.183279] pci 0000:00:1f.0: [8086:3a18] type 00 class 0x06010=
0
[ =A0 =A01.183458] pci 0000:00:1f.2: [8086:3a20] type 00 class =
0x01018f
[ =A0 =A01.183484] pci 0000:00:1f.2: reg 10: [io =A00x21=
18-0x211f]



[ =A0 =A01.183497] pci 0000:00:1f.2: reg 14: [io =A00x212c-0x212f]
[ =A0 =A01.183510] pci 0000:00:1f.2: reg 18: [io =A00x2110-0x2117]
[ =A0 =A01.183522] pci 0000:00:1f.2: reg 1c: [io =A00x2128-0x212b]=

[ =A0 =A01.183535] pci 0000:00:1f.2: reg 20: [io =A00x20f0-0x20f=
f]



[ =A0 =A01.183548] pci 0000:00:1f.2: reg 24: [io =A00x20e0-0x20ef]
[ =A0 =A01.183629] pci 0000:00:1f.3: [8086:3a30] type 00 class 0x0c0=
500
[ =A0 =A01.183653] pci 0000:00:1f.3: reg 10: [mem 0x97a22000-=
0x97a220ff 64bit]



[ =A0 =A01.183689] pci 0000:00:1f.3: reg 20: [io =A00x2000-0x201f]
[ =A0 =A01.183746] pci 0000:00:1f.5: [8086:3a26] type 00 class 0x010=
185
[ =A0 =A01.183772] pci 0000:00:1f.5: reg 10: [io =A00x2108-0x=
210f]



[ =A0 =A01.183784] pci 0000:00:1f.5: reg 14: [io =A00x2124-0x2127]
[ =A0 =A01.183797] pci 0000:00:1f.5: reg 18: [io =A00x2100-0x2107]
<=
div>[ =A0 =A01.183816] pci 0000:00:1f.5: reg 1c: [io =A00x2120-0x2123]
[ =A0 =A01.183829] pci 0000:00:1f.5: reg 20: [io =A00x20d0-0x20df]


[ =A0 =A01.183841] pci 0000:00:1f.5: reg 24: [io =A00x20c0-0x20cf]
[ =A0 =A01.183985] pci_bus 0000:0b: busn_res: [bus 0b-0f] is inserte=
d under [bus 00-ff]
[ =A0 =A01.184016] pci 0000:0b:00.0: [14e4:16=
39] type 00 class 0x020000



[ =A0 =A01.184040] pci 0000:0b:00.0: reg 10: [mem 0x92000000-0x93fffff=
f 64bit]
[ =A0 =A01.184181] pci 0000:0b:00.0: PME# supported from=
 D0 D3hot D3cold
[ =A0 =A01.184224] pci 0000:0b:00.1: [14e4:1639]=
 type 00 class 0x020000



[ =A0 =A01.184248] pci 0000:0b:00.1: reg 10: [mem 0x94000000-0x95fffff=
f 64bit]
[ =A0 =A01.184390] pci 0000:0b:00.1: PME# supported from=
 D0 D3hot D3cold
[ =A0 =A01.191939] pci 0000:00:01.0: PCI bridge =
to [bus 0b-0f]



[ =A0 =A01.192017] pci 0000:00:01.0: =A0 bridge window [mem 0x92000000=
-0x95ffffff]
[ =A0 =A01.192089] pci_bus 0000:10: busn_res: [bus 1=
0-14] is inserted under [bus 00-ff]
[ =A0 =A01.192093] pci 0000:0=
0:02.0: PCI bridge to [bus 10-14]



[ =A0 =A01.192240] pci_bus 0000:15: busn_res: [bus 15-19] is inserted =
under [bus 00-ff]
[ =A0 =A01.192244] pci 0000:00:03.0: PCI bridge=
 to [bus 15-19]
[ =A0 =A01.192389] pci_bus 0000:1a: busn_res: [bu=
s 1a-1e] is inserted under [bus 00-ff]



[ =A0 =A01.192392] pci 0000:00:05.0: PCI bridge to [bus 1a-1e]
[ =A0 =A01.192539] pci_bus 0000:1f: busn_res: [bus 1f-23] is inserted un=
der [bus 00-ff]
[ =A0 =A01.192542] pci 0000:00:07.0: PCI bridge t=
o [bus 1f-23]



[ =A0 =A01.192688] pci_bus 0000:24: busn_res: [bus 24-28] is inserted =
under [bus 00-ff]
[ =A0 =A01.192691] pci 0000:00:09.0: PCI bridge=
 to [bus 24-28]
[ =A0 =A01.192838] pci_bus 0000:01: busn_res: [bu=
s 01-05] is inserted under [bus 00-ff]



[ =A0 =A01.192863] pci 0000:01:00.0: [1000:0073] type 00 class 0x01040=
0
[ =A0 =A01.192884] pci 0000:01:00.0: reg 10: [io =A00x1000-0x10=
ff]
[ =A0 =A01.192908] pci 0000:01:00.0: reg 14: [mem 0x97940000-=
0x97943fff 64bit]



[ =A0 =A01.192932] pci 0000:01:00.0: reg 1c: [mem 0x97900000-0x9793fff=
f 64bit]
[ =A0 =A01.192962] pci 0000:01:00.0: reg 30: [mem 0xfffe=
0000-0xffffffff pref]
[ =A0 =A01.193060] pci 0000:01:00.0: suppor=
ts D1 D2



[ =A0 =A01.200042] pci 0000:00:1c.0: PCI bridge to [bus 01-05]
[ =A0 =A01.200117] pci 0000:00:1c.0: =A0 bridge window [io =A00x1000-0x1=
fff]
[ =A0 =A01.200123] pci 0000:00:1c.0: =A0 bridge window [mem =
0x97900000-0x979fffff]



[ =A0 =A01.200196] pci_bus 0000:06: busn_res: [bus 06-0a] is inserted =
under [bus 00-ff]
[ =A0 =A01.200228] pci 0000:06:00.0: [101b:0452=
] type 01 class 0x060400
[ =A0 =A01.200394] pci 0000:06:00.0: PME=
# supported from D0 D3hot D3cold



[ =A0 =A01.208144] pci 0000:00:1c.4: PCI bridge to [bus 06-0a]
[ =A0 =A01.208223] pci 0000:00:1c.4: =A0 bridge window [mem 0x97000000-0=
x978fffff]
[ =A0 =A01.208231] pci 0000:00:1c.4: =A0 bridge window=
 [mem 0x96000000-0x96ffffff 64bit pref]



[ =A0 =A01.208330] pci_bus 0000:07: busn_res: [bus 07] is inserted und=
er [bus 06-0a]
[ =A0 =A01.208353] pci 0000:07:00.0: [102b:0530] t=
ype 00 class 0x030000
[ =A0 =A01.208388] pci 0000:07:00.0: reg 10=
: [mem 0x96000000-0x96ffffff pref]



[ =A0 =A01.208407] pci 0000:07:00.0: reg 14: [mem 0x97800000-0x97803ff=
f]
[ =A0 =A01.208427] pci 0000:07:00.0: reg 18: [mem 0x97000000-0=
x977fffff]
[ =A0 =A01.208633] pci 0000:06:00.0: PCI bridge to [bu=
s 07]



[ =A0 =A01.208713] pci 0000:06:00.0: =A0 bridge window [mem 0x97000000=
-0x978fffff]
[ =A0 =A01.208720] pci 0000:06:00.0: =A0 bridge wind=
ow [mem 0x96000000-0x96ffffff pref]
[ =A0 =A01.208768] pci_bus 00=
00:29: busn_res: [bus 29-2d] is inserted under [bus 00-ff]



[ =A0 =A01.208829] pci 0000:00:1e.0: PCI bridge to [bus 29-2d] (subtra=
ctive decode)
[ =A0 =A01.208917] pci 0000:00:1e.0: =A0 bridge win=
dow [io =A00x0000-0xffff] (subtractive decode)
[ =A0 =A01.208919]=
 pci 0000:00:1e.0: =A0 bridge window [mem 0x00000000-0xffffffffff] (subtrac=
tive decode)



[ =A0 =A01.208978] pci_bus 0000:00: busn_res: [bus 00-ff] end is updat=
ed to 2d
[ =A0 =A01.210287] vgaarb: device added: PCI:0000:07:00.=
0,decodes=3Dio+mem,owns=3Dio+mem,locks=3Dnone
[ =A0 =A01.210898] =
PCI: pci_cache_line_size set to 64 bytes



[ =A0 =A01.211078] e820: reserve RAM buffer [mem 0x0006c000-0x0006ffff=
]
[ =A0 =A01.211080] e820: reserve RAM buffer [mem 0x0009f000-0x0=
009ffff]
[ =A0 =A01.211081] e820: reserve RAM buffer [mem 0x7acb7=
000-0x7bffffff]



[ =A0 =A01.211082] e820: reserve RAM buffer [mem 0x7d4f0000-0x7fffffff=
]
[ =A0 =A01.211086] e820: reserve RAM buffer [mem 0x7d53f000-0x7=
fffffff]
[ =A0 =A01.211088] e820: reserve RAM buffer [mem 0x7d704=
000-0x7fffffff]



[ =A0 =A01.211091] e820: reserve RAM buffer [mem 0x7f5ef000-0x7fffffff=
]
[ =A0 =A01.211093] e820: reserve RAM buffer [mem 0x7f800000-0x7=
fffffff]
[ =A0 =A01.211210] Switching to clocksource xen
[ =A0 =A01.212720] pnp: PnP ACPI: disabled



[ =A0 =A01.214391] pci 0000:01:00.0: no compatible bridge window for [=
mem 0xfffe0000-0xffffffff pref]
[ =A0 =A01.214569] pci 0000:00:1c=
.0: bridge window [mem 0x00100000-0x001fffff pref] to [bus 01-05] add_size =
200000



[ =A0 =A01.214613] pci 0000:00:1c.0: res[15]=3D[mem 0x00100000-0x001ff=
fff pref] get_res_add_size add_size 200000
[ =A0 =A01.214617] pci=
 0000:00:1c.0: BAR 15: assigned [mem 0x90000000-0x902fffff pref]
=
[ =A0 =A01.214708] pci 0000:00:01.0: PCI bridge to [bus 0b-0f]



[ =A0 =A01.214783] pci 0000:00:01.0: =A0 bridge window [mem 0x92000000=
-0x95ffffff]
[ =A0 =A01.214865] pci 0000:00:02.0: PCI bridge to [=
bus 10-14]
[ =A0 =A01.214948] pci 0000:00:03.0: PCI bridge to [bu=
s 15-19]



[ =A0 =A01.215032] pci 0000:00:05.0: PCI bridge to [bus 1a-1e]
[ =A0 =A01.215114] pci 0000:00:07.0: PCI bridge to [bus 1f-23]
[ =A0 =A01.215198] pci 0000:00:09.0: PCI bridge to [bus 24-28]
[=
 =A0 =A01.215282] pci 0000:01:00.0: BAR 6: assigned [mem 0x90000000-0x9001f=
fff pref]



[ =A0 =A01.215383] pci 0000:00:1c.0: PCI bridge to [bus 01-05]
[ =A0 =A01.215456] pci 0000:00:1c.0: =A0 bridge window [io =A00x1000-0x1=
fff]
[ =A0 =A01.215532] pci 0000:00:1c.0: =A0 bridge window [mem =
0x97900000-0x979fffff]



[ =A0 =A01.215609] pci 0000:00:1c.0: =A0 bridge window [mem 0x90000000=
-0x902fffff pref]
[ =A0 =A01.215705] pci 0000:06:00.0: PCI bridge=
 to [bus 07]
[ =A0 =A01.215782] pci 0000:06:00.0: =A0 bridge wind=
ow [mem 0x97000000-0x978fffff]



[ =A0 =A01.215860] pci 0000:06:00.0: =A0 bridge window [mem 0x96000000=
-0x96ffffff pref]
[ =A0 =A01.223235] pci 0000:00:1c.4: PCI bridge=
 to [bus 06-0a]
[ =A0 =A01.223310] pci 0000:00:1c.4: =A0 bridge w=
indow [mem 0x97000000-0x978fffff]



[ =A0 =A01.223391] pci 0000:00:1c.4: =A0 bridge window [mem 0x96000000=
-0x96ffffff 64bit pref]
[ =A0 =A01.223489] pci 0000:00:1e.0: PCI =
bridge to [bus 29-2d]
[ =A0 =A01.223580] pci 0000:00:01.0: can=
9;t find IRQ for PCI INT A; please try using pci=3Dbiosirq



[ =A0 =A01.223680] pci 0000:00:02.0: can't find IRQ for PCI INT A;=
 please try using pci=3Dbiosirq
[ =A0 =A01.223780] pci 0000:00:03=
.0: can't find IRQ for PCI INT A; please try using pci=3Dbiosirq
<=
div>[ =A0 =A01.223880] pci 0000:00:05.0: can't find IRQ for PCI INT A; =
please try using pci=3Dbiosirq



[ =A0 =A01.223981] pci 0000:00:07.0: can't find IRQ for PCI INT A;=
 please try using pci=3Dbiosirq
[ =A0 =A01.224081] pci 0000:00:09=
.0: can't find IRQ for PCI INT A; please try using pci=3Dbiosirq
<=
div>[ =A0 =A01.224183] pci 0000:00:1c.0: can't find IRQ for PCI INT A; =
please try using pci=3Dbiosirq



[ =A0 =A01.224283] pci 0000:00:1c.4: can't find IRQ for PCI INT A;=
 please try using pci=3Dbiosirq
[ =A0 =A01.224385] pci 0000:06:00=
.0: can't find IRQ for PCI INT A; please try using pci=3Dbiosirq
<=
div>[ =A0 =A01.224487] pci 0000:00:1e.0: setting latency timer to 64



[ =A0 =A01.224492] pci_bus 0000:00: resource 4 [io =A00x0000-0xffff]
[ =A0 =A01.224494] pci_bus 0000:00: resource 5 [mem 0x00000000-0xf=
fffffffff]
[ =A0 =A01.224496] pci_bus 0000:0b: resource 1 [mem 0x=
92000000-0x95ffffff]



[ =A0 =A01.224498] pci_bus 0000:01: resource 0 [io =A00x1000-0x1fff]
[ =A0 =A01.224500] pci_bus 0000:01: resource 1 [mem 0x97900000-0x9=
79fffff]
[ =A0 =A01.224502] pci_bus 0000:01: resource 2 [mem 0x90=
000000-0x902fffff pref]



[ =A0 =A01.224504] pci_bus 0000:06: resource 1 [mem 0x97000000-0x978ff=
fff]
[ =A0 =A01.224507] pci_bus 0000:06: resource 2 [mem 0x960000=
00-0x96ffffff 64bit pref]
[ =A0 =A01.224510] pci_bus 0000:07: res=
ource 1 [mem 0x97000000-0x978fffff]



[ =A0 =A01.224512] pci_bus 0000:07: resource 2 [mem 0x96000000-0x96fff=
fff pref]
[ =A0 =A01.224514] pci_bus 0000:29: resource 4 [io =A00=
x0000-0xffff]
[ =A0 =A01.224516] pci_bus 0000:29: resource 5 [mem=
 0x00000000-0xffffffffff]



[ =A0 =A01.224538] NET: Registered protocol family 2
[ =A0 =
=A01.225637] TCP established hash table entries: 524288 (order: 11, 8388608=
 bytes)
[ =A0 =A01.228185] TCP bind hash table entries: 65536 (or=
der: 8, 1048576 bytes)



[ =A0 =A01.228521] TCP: Hash tables configured (established 524288 bin=
d 65536)
[ =A0 =A01.228613] TCP: reno registered
[ =A0 =
=A01.228689] UDP hash table entries: 2048 (order: 4, 65536 bytes)
[ =A0 =A01.228785] UDP-Lite hash table entries: 2048 (order: 4, 65536 byte=
s)



[ =A0 =A01.228922] NET: Registered protocol family 1
[ =A0 =
=A01.229073] pci 0000:00:1a.0: can't find IRQ for PCI INT A; please try=
 using pci=3Dbiosirq
[ =A0 =A01.229201] pci 0000:00:1a.1: can'=
;t find IRQ for PCI INT B; please try using pci=3Dbiosirq



[ =A0 =A01.229325] pci 0000:00:1a.7: can't find IRQ for PCI INT C;=
 please try using pci=3Dbiosirq
[ =A0 =A01.229466] pci 0000:00:1d=
.0: can't find IRQ for PCI INT A; please try using pci=3Dbiosirq
<=
div>[ =A0 =A01.229588] pci 0000:00:1d.1: can't find IRQ for PCI INT B; =
please try using pci=3Dbiosirq



[ =A0 =A01.229708] pci 0000:00:1d.2: can't find IRQ for PCI INT C;=
 please try using pci=3Dbiosirq
[ =A0 =A01.229836] pci 0000:00:1d=
.7: can't find IRQ for PCI INT A; please try using pci=3Dbiosirq
<=
div>[ =A0 =A01.229986] pci 0000:07:00.0: Boot video device



[ =A0 =A01.229991] PCI: CLS 64 bytes, default 64
[ =A0 =A01.=
230040] Unpacking initramfs...
[ =A0 =A01.236939] Freeing initrd =
memory: 7188k freed
[ =A0 =A01.238401] platform rtc_cmos: registe=
red platform RTC device (no PNP device found)



[ =A0 =A01.238695] audit: initializing netlink socket (disabled)
=

[ =A0 =A01.238779] type=3D2000 audit(1349925915.231:1): initialized
[ =A0 =A01.253042] HugeTLB registered 2 MB page size, pre-allocated=
 0 pages



[ =A0 =A01.253247] VFS: Disk quotas dquot_6.5.2
[ =A0 =A01.2=
53330] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
=
[ =A0 =A01.253465] msgmni has been set to 7465
[ =A0 =A01.253646]=
 alg: No test for stdrng (krng)



[ =A0 =A01.253730] Block layer SCSI generic (bsg) driver version 0.4 l=
oaded (major 252)
[ =A0 =A01.253820] io scheduler noop registered=

[ =A0 =A01.253888] io scheduler deadline registered
[ =
=A0 =A01.253960] io scheduler cfq registered (default)



[ =A0 =A01.254124] pcieport 0000:00:01.0: device [8086:3408] has inval=
id IRQ; check vendor BIOS
[ =A0 =A01.254277] pcieport 0000:00:02.=
0: device [8086:3409] has invalid IRQ; check vendor BIOS
[ =A0 =
=A01.254425] pcieport 0000:00:03.0: device [8086:340a] has invalid IRQ; che=
ck vendor BIOS



[ =A0 =A01.254573] pcieport 0000:00:05.0: device [8086:340c] has inval=
id IRQ; check vendor BIOS
[ =A0 =A01.254723] pcieport 0000:00:07.=
0: device [8086:340e] has invalid IRQ; check vendor BIOS
[ =A0 =
=A01.254870] pcieport 0000:00:09.0: device [8086:3410] has invalid IRQ; che=
ck vendor BIOS



[ =A0 =A01.255019] pcieport 0000:00:1c.0: device [8086:3a40] has inval=
id IRQ; check vendor BIOS
[ =A0 =A01.255170] pcieport 0000:00:1c.=
4: device [8086:3a48] has invalid IRQ; check vendor BIOS
[ =A0 =
=A01.255389] ioapic: probe of 0000:00:15.0 failed with error -22



[ =A0 =A01.255467] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[ =A0 =A01.255554] pciehp: PCI Express Hot Plug Controller Driver ve=
rsion: 0.4
[ =A0 =A01.255627] acpiphp: ACPI Hot Plug PCI Controll=
er Driver version: 0.5



[ =A0 =A01.255752] intel_idle: does not run on family 6 model 44
=

[ =A0 =A01.255833] Event-channel device installed.
[ =A0 =A0=
1.255989] xen-pciback: backend is vpci
[ =A0 =A01.256298] Serial:=
 8250/16550 driver, 4 ports, IRQ sharing enabled



[ =A0 =A01.277599] serial8250: ttyS0 at I/O 0x3f8 (irq =3D 4) is a 165=
50A
[ =A0 =A01.298917] serial8250: ttyS1 at I/O 0x2f8 (irq =3D 3)=
 is a 16550A
[ =A0 =A01.299221] Linux agpgart interface v0.103
[ =A0 =A01.299387] i8042: PNP: No PS/2 controller found. Probing po=
rts directly.



[ =A0 =A01.551430] serio: i8042 KBD port at 0x60,0x64 irq 1
=
[ =A0 =A01.551580] mousedev: PS/2 mouse device common for all mice
[ =A0 =A01.551800] rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rt=
c0



[ =A0 =A01.551897] rtc0: alarms up to one day, 114 bytes nvram
[ =A0 =A01.551972] EFI Variables Facility v0.08 2004-May-17
[ =
=A0 =A01.552053] drop_monitor: Initializing network drop monitor service


[ =A0 =A01.552197] TCP: cubic registered
[ =A0 =A01.552276] NET: =
Registered protocol family 10
[ =A0 =A01.552496] mip6: Mobile IPv=
6
[ =A0 =A01.552564] NET: Registered protocol family 17
[ =A0 =A01.552641] Key type dns_resolver registered



[ =A0 =A01.552859] PM: Hibernation image not present or could not be l=
oaded.
[ =A0 =A01.552868] registered taskstats version 1
[ =A0 =A01.553635] rtc_cmos rtc_cmos: setting system clock to 2012-10-11 =
03:25:15 UTC (1349925915)



[ =A0 =A01.553954] Freeing unused kernel memory: 592k freed
=
[ =A0 =A01.554130] Write protecting the kernel read-only data: 6144k
<=
div>[ =A0 =A01.555798] Freeing unused kernel memory: 512k freed
[=
 =A0 =A01.556107] Freeing unused kernel memory: 620k freed



[ =A0 =A01.583588] udevd[50]: starting version 175
[ =A0 =A0=
1.657119] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[ =A0 =A01.663281] SCSI subsystem initialized
[ =A0 =A01.68=
1024] megasas: 00.00.06.15-rc1 Mon. Mar. 19 17:00:00 PDT 2012



[ =A0 =A01.681111] megasas: 0x1000:0x0073:0x1014:0x03b1: bus 1:slot 0:=
func 0
[ =A0 =A01.681241] megaraid_sas 0000:01:00.0: can't fi=
nd IRQ for PCI INT A; please try using pci=3Dbiosirq
[ =A0 =A01.6=
87892] megasas: FW now in Ready state



[ =A0 =A01.735350] megasas_init_mfi: fw_support_ieee=3D67108864
<=
div>[ =A0 =A01.735407] megasas: INIT adapter done
[ =A0 =A01.8073=
65] scsi0 : LSI SAS based MegaRAID driver
[ =A0 =A01.808799] scsi=
 0:0:8:0: Direct-Access =A0 =A0 IBM-ESXS ST9146803SS =A0 =A0 =A0B53C PQ: 0 =
ANSI: 5



[ =A0 =A01.811249] scsi 0:0:9:0: Direct-Access =A0 =A0 ATA =A0 =A0 =A0=
ST9500620NS =A0 =A0 =A0BE24 PQ: 0 ANSI: 5
[ =A0 =A01.812739] scsi=
 0:0:10:0: Direct-Access =A0 =A0 ATA =A0 =A0 =A0ST9500620NS =A0 =A0 =A0BE24=
 PQ: 0 ANSI: 5
[ =A0 =A01.824208] scsi 0:2:0:0: Direct-Access =A0=
 =A0 IBM =A0 =A0 =A0ServeRAID M1015 =A02.12 PQ: 0 ANSI: 5



[ =A0 =A01.839755] sd 0:2:0:0: [sdb] 1949216768 512-byte logical block=
s: (997 GB/929 GiB)
[ =A0 =A01.840060] sd 0:2:0:0: [sdb] Write Pr=
otect is off
[ =A0 =A01.840141] sd 0:2:0:0: [sdb] Mode Sense: 1f =
00 10 08



[ =A0 =A01.840153] sd 0:0:8:0: [sda] 286748000 512-byte logical blocks=
: (146 GB/136 GiB)
[ =A0 =A01.840302] sd 0:2:0:0: [sdb] Write cac=
he: disabled, read cache: disabled, supports DPO and FUA
[ =A0 =
=A01.842564] sd 0:0:8:0: [sda] Write Protect is off



[ =A0 =A01.842637] sd 0:0:8:0: [sda] Mode Sense: c3 00 10 08
[ =A0 =A01.843418] =A0sdb: sdb1
[ =A0 =A01.843898] sd 0:0:8:0: [=
sda] Write cache: disabled, read cache: enabled, supports DPO and FUA
=

[ =A0 =A01.844117] sd 0:2:0:0: [sdb] Attached SCSI disk



[ =A0 =A01.866028] =A0sda: sda1 sda2 sda3 sda4
[ =A0 =A01.87=
0498] sd 0:0:8:0: [sda] Attached SCSI disk
[ =A0 =A02.053157] dev=
ice-mapper: uevent: version 1.0.3
[ =A0 =A02.053610] device-mappe=
r: ioctl: 4.23.0-ioctl (2012-07-25) initialised: dm-devel@redhat.com



[ =A0 =A02.214131] EXT4-fs (dm-0): mounted filesystem with ordered dat=
a mode. Opts: (null)
[ =A0 =A03.162111] udevd[298]: starting vers=
ion 175
[ =A0 =A03.419449] bnx2: Broadcom NetXtreme II Gigabit Et=
hernet Driver bnx2 v2.2.3 (June 27, 2012)



[ =A0 =A03.419565] bnx2 0000:0b:00.0: can't find IRQ for PCI INT A=
; please try using pci=3Dbiosirq
[ =A0 =A03.420241] bnx2 0000:0b:=
00.0: eth0: Broadcom NetXtreme II BCM5709 1000Base-T (C0) PCI Express found=
 at mem 92000000, IRQ 0, node addr 34:40:b5:ab:e5:b4



[ =A0 =A03.421062] bnx2 0000:0b:00.1: can't find IRQ for PCI INT B=
; please try using pci=3Dbiosirq
[ =A0 =A03.421705] bnx2 0000:0b:=
00.1: eth1: Broadcom NetXtreme II BCM5709 1000Base-T (C0) PCI Express found=
 at mem 94000000, IRQ 0, node addr 34:40:b5:ab:e5:b6



[ =A0 =A03.428805] dca service started, version 1.12.1
[ =A0=
 =A03.467169] EDAC MC: Ver: 3.0.0
[ =A0 =A03.473824] ioatdma: Int=
el(R) QuickData Technology Driver 4.00
[ =A0 =A03.473918] ioatdma=
 0000:00:16.0: enabling device (0000 -> 0002)



[ =A0 =A03.473996] ioatdma 0000:00:16.0: can't find IRQ for PCI IN=
T A; please try using pci=3Dbiosirq
[ =A0 =A03.474116] ioatdma 00=
00:00:16.0: channel error register unreachable
[ =A0 =A03.474191]=
 ioatdma 0000:00:16.0: channel enumeration error



[ =A0 =A03.505302] microcode: CPU0 sig=3D0x206c2, pf=3D0x1, revision=
=3D0x15
[ =A0 =A03.505995] ioatdma 0000:00:16.0: Intel(R) I/OAT D=
MA Engine init failed
[ =A0 =A03.506096] ioatdma 0000:00:16.1: en=
abling device (0000 -> 0002)



[ =A0 =A03.506173] ioatdma 0000:00:16.1: can't find IRQ for PCI IN=
T B; please try using pci=3Dbiosirq
[ =A0 =A03.506296] ioatdma 00=
00:00:16.1: channel error register unreachable
[ =A0 =A03.506369]=
 ioatdma 0000:00:16.1: channel enumeration error



[ =A0 =A03.506441] ioatdma 0000:00:16.1: Intel(R) I/OAT DMA Engine ini=
t failed
[ =A0 =A03.506532] ioatdma 0000:00:16.2: enabling device=
 (0000 -> 0002)
[ =A0 =A03.506608] ioatdma 0000:00:16.2: can&#=
39;t find IRQ for PCI INT C; please try using pci=3Dbiosirq



[ =A0 =A03.506722] ioatdma 0000:00:16.2: channel error register unreac=
hable
[ =A0 =A03.506795] ioatdma 0000:00:16.2: channel enumeratio=
n error
[ =A0 =A03.506867] ioatdma 0000:00:16.2: Intel(R) I/OAT D=
MA Engine init failed



[ =A0 =A03.506957] ioatdma 0000:00:16.3: enabling device (0000 -> 0=
002)
[ =A0 =A03.507034] ioatdma 0000:00:16.3: can't find IRQ =
for PCI INT D; please try using pci=3Dbiosirq
[ =A0 =A03.507147] =
ioatdma 0000:00:16.3: channel error register unreachable



[ =A0 =A03.507222] ioatdma 0000:00:16.3: channel enumeration error
[ =A0 =A03.507294] ioatdma 0000:00:16.3: Intel(R) I/OAT DMA Engine i=
nit failed
[ =A0 =A03.507398] ioatdma 0000:00:16.4: enabling devi=
ce (0000 -> 0002)



[ =A0 =A03.507476] ioatdma 0000:00:16.4: can't find IRQ for PCI IN=
T A; please try using pci=3Dbiosirq
[ =A0 =A03.507590] ioatdma 00=
00:00:16.4: channel error register unreachable
[ =A0 =A03.507663]=
 ioatdma 0000:00:16.4: channel enumeration error



[ =A0 =A03.507735] ioatdma 0000:00:16.4: Intel(R) I/OAT DMA Engine ini=
t failed
[ =A0 =A03.507826] ioatdma 0000:00:16.5: enabling device=
 (0000 -> 0002)
[ =A0 =A03.507903] ioatdma 0000:00:16.5: can&#=
39;t find IRQ for PCI INT B; please try using pci=3Dbiosirq



[ =A0 =A03.508016] ioatdma 0000:00:16.5: channel error register unreac=
hable
[ =A0 =A03.508090] ioatdma 0000:00:16.5: channel enumeratio=
n error
[ =A0 =A03.508162] ioatdma 0000:00:16.5: Intel(R) I/OAT D=
MA Engine init failed



[ =A0 =A03.508255] ioatdma 0000:00:16.6: enabling device (0000 -> 0=
002)
[ =A0 =A03.508337] ioatdma 0000:00:16.6: can't find IRQ =
for PCI INT C; please try using pci=3Dbiosirq
[ =A0 =A03.508454] =
ioatdma 0000:00:16.6: channel error register unreachable



[ =A0 =A03.508529] ioatdma 0000:00:16.6: channel enumeration error
[ =A0 =A03.508601] ioatdma 0000:00:16.6: Intel(R) I/OAT DMA Engine i=
nit failed
[ =A0 =A03.508692] ioatdma 0000:00:16.7: enabling devi=
ce (0000 -> 0002)



[ =A0 =A03.508769] ioatdma 0000:00:16.7: can't find IRQ for PCI IN=
T D; please try using pci=3Dbiosirq
[ =A0 =A03.508885] ioatdma 00=
00:00:16.7: channel error register unreachable
[ =A0 =A03.508958]=
 ioatdma 0000:00:16.7: channel enumeration error



[ =A0 =A03.509030] ioatdma 0000:00:16.7: Intel(R) I/OAT DMA Engine ini=
t failed
[ =A0 =A03.571248] usbcore: registered new interface dri=
ver usbfs
[ =A0 =A03.571330] usbcore: registered new interface dr=
iver hub



[ =A0 =A03.585483] ACPI Exception: AE_BAD_PARAMETER, Thread 1786484928=
 could not acquire Mutex [0x1] (20120711/utmutex-276)
[ =A0 =A03.=
585675] ACPI Exception: AE_BAD_PARAMETER, Thread 1786484928 could not acqui=
re Mutex [0x1] (20120711/utmutex-276)



[ =A0 =A03.590919] usbcore: registered new device driver usb
[ =A0 =A03.603433] input: PC Speaker as /devices/platform/pcspkr/input/inp=
ut0
[ =A0 =A03.604762] libata version 3.00 loaded.
[ =
=A0 =A03.607430] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI=
) Driver



[ =A0 =A03.607535] ehci_hcd 0000:00:1a.7: can't find IRQ for PCI I=
NT C; please try using pci=3Dbiosirq
[ =A0 =A03.607629] ehci_hcd =
0000:00:1a.7: Found HC with no IRQ. =A0Check BIOS/PCI 0000:00:1a.7 setup!


[ =A0 =A03.607723] ehci_hcd 0000:00:1a.7: init 0000:00:1a.7 fail, -19
=

[ =A0 =A03.607808] ehci_hcd 0000:00:1d.7: can't find IRQ for PCI I=
NT A; please try using pci=3Dbiosirq
[ =A0 =A03.607900] ehci_hcd =
0000:00:1d.7: Found HC with no IRQ. =A0Check BIOS/PCI 0000:00:1d.7 setup!


[ =A0 =A03.607994] ehci_hcd 0000:00:1d.7: init 0000:00:1d.7 fail, -19<=
/div>
[ =A0 =A03.623701] i801_smbus 0000:00:1f.3: enabling device (0140=
 -> 0143)
[ =A0 =A03.623781] i801_smbus 0000:00:1f.3: can'=
t find IRQ for PCI INT B; please try using pci=3Dbiosirq



[ =A0 =A03.623874] ACPI Exception: AE_BAD_PARAMETER, Thread 1775910976=
 could not acquire Mutex [0x1] (20120711/utmutex-276)
[ =A0 =A03.=
624093] i801_smbus 0000:00:1f.3: SMBus using PCI Interrupt
[ =A0 =
=A03.676083] ata_piix 0000:00:1f.2: version 2.13



[ =A0 =A03.676095] ata_piix 0000:00:1f.2: can't find IRQ for PCI I=
NT A; please try using pci=3Dbiosirq
[ =A0 =A03.676193] ata_piix =
0000:00:1f.2: MAP [
[ =A0 =A03.676260] =A0P0 P2 P1 P3 ]
[ =A0 =A03.676539] ata_piix 0000:00:1f.2: setting latency timer to 64


[ =A0 =A03.677344] scsi1 : ata_piix
[ =A0 =A03.677732] scsi2=
 : ata_piix
[ =A0 =A03.677862] ata1: SATA max UDMA/133 cmd 0x2118=
 ctl 0x212c bmdma 0x20f0
[ =A0 =A03.677954] ata2: SATA max UDMA/1=
33 cmd 0x2110 ctl 0x2128 bmdma 0x20f8



[ =A0 =A03.678154] gpio_ich: GPIO from 195 to 255 on gpio_ich
[ =A0 =A03.678606] ata_piix 0000:00:1f.5: can't find IRQ for PCI INT =
C; please try using pci=3Dbiosirq
[ =A0 =A03.678703] ata_piix 000=
0:00:1f.5: MAP [



[ =A0 =A03.678771] =A0P0 -- P1 -- ]
[ =A0 =A03.679046] ata_p=
iix 0000:00:1f.5: setting latency timer to 64
[ =A0 =A03.679562] =
scsi3 : ata_piix
[ =A0 =A03.680057] uhci_hcd: USB Universal Host =
Controller Interface driver



[ =A0 =A03.682601] scsi4 : ata_piix
[ =A0 =A03.682814] ata3:=
 SATA max UDMA/133 cmd 0x2108 ctl 0x2124 bmdma 0x20d0
[ =A0 =A03.=
682893] ata4: SATA max UDMA/133 cmd 0x2100 ctl 0x2120 bmdma 0x20d8
[ =A0 =A03.683028] uhci_hcd 0000:00:1a.0: can't find IRQ for PCI INT =
A; please try using pci=3Dbiosirq



[ =A0 =A03.683123] uhci_hcd 0000:00:1a.0: Found HC with no IRQ. =A0Che=
ck BIOS/PCI 0000:00:1a.0 setup!
[ =A0 =A03.683217] uhci_hcd 0000:=
00:1a.0: init 0000:00:1a.0 fail, -19
[ =A0 =A03.683300] uhci_hcd =
0000:00:1a.1: can't find IRQ for PCI INT B; please try using pci=3Dbios=
irq



[ =A0 =A03.683408] uhci_hcd 0000:00:1a.1: Found HC with no IRQ. =A0Che=
ck BIOS/PCI 0000:00:1a.1 setup!
[ =A0 =A03.683504] uhci_hcd 0000:=
00:1a.1: init 0000:00:1a.1 fail, -19
[ =A0 =A03.683588] uhci_hcd =
0000:00:1d.0: can't find IRQ for PCI INT A; please try using pci=3Dbios=
irq



[ =A0 =A03.683682] uhci_hcd 0000:00:1d.0: Found HC with no IRQ. =A0Che=
ck BIOS/PCI 0000:00:1d.0 setup!
[ =A0 =A03.683802] uhci_hcd 0000:=
00:1d.0: init 0000:00:1d.0 fail, -19
[ =A0 =A03.683933] uhci_hcd =
0000:00:1d.1: can't find IRQ for PCI INT B; please try using pci=3Dbios=
irq



[ =A0 =A03.684026] uhci_hcd 0000:00:1d.1: Found HC with no IRQ. =A0Che=
ck BIOS/PCI 0000:00:1d.1 setup!
[ =A0 =A03.684121] uhci_hcd 0000:=
00:1d.1: init 0000:00:1d.1 fail, -19
[ =A0 =A03.684201] uhci_hcd =
0000:00:1d.2: can't find IRQ for PCI INT C; please try using pci=3Dbios=
irq



[ =A0 =A03.684293] uhci_hcd 0000:00:1d.2: Found HC with no IRQ. =A0Che=
ck BIOS/PCI 0000:00:1d.2 setup!
[ =A0 =A03.684387] uhci_hcd 0000:=
00:1d.2: init 0000:00:1d.2 fail, -19
[ =A0 =A03.751594] microcode=
: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba=




[ =A0 =A03.771183] iTCO_vendor_support: vendor-support=3D0
[=
 =A0 =A04.010635] ata3: SATA link down (SStatus 0 SControl 300)
[=
 =A0 =A04.022013] ata4: SATA link down (SStatus 0 SControl 300)
[=
 =A0 =A04.342660] ata2.00: SATA link down (SStatus 0 SControl 300)



[ =A0 =A04.342751] ata2.01: SATA link down (SStatus 0 SControl 300)
[ =A0 =A04.487426] ata1.00: SATA link up 1.5 Gbps (SStatus 113 SCon=
trol 300)
[ =A0 =A04.487519] ata1.01: SATA link down (SStatus 0 S=
Control 300)



[ =A0 =A04.487603] ata1.01: link offline, clearing class 3 to NONE
[ =A0 =A04.495491] ata1.00: ATAPI: IBM SATA DEVICE 81Y3657, IB01, ma=
x UDMA/33
[ =A0 =A04.511489] ata1.00: configured for UDMA/33
[ =A0 =A09.511364] ata1.00: qc timeout (cmd 0xa0)



[ =A0 =A09.511434] ata1.00: TEST_UNIT_READY failed (err_mask=3D0x5)
[ =A0 10.307422] ata1.00: SATA link up 1.5 Gbps (SStatus 113 SContr=
ol 300)
[ =A0 10.307515] ata1.01: SATA link down (SStatus 0 SCont=
rol 300)



[ =A0 10.307600] ata1.01: link offline, clearing class 3 to NONE
=

[ =A0 10.331487] ata1.00: configured for UDMA/33
[ =A0 15.33=
1361] ata1.00: qc timeout (cmd 0xa0)
[ =A0 15.331431] ata1.00: TE=
ST_UNIT_READY failed (err_mask=3D0x5)



[ =A0 15.331504] ata1.00: limiting SATA link speed to 1.5 Gbps
[ =A0 15.331574] ata1.00: limiting speed to UDMA/33:PIO3
[ =A0=
 16.127423] ata1.00: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
=



[ =A0 16.127515] ata1.01: SATA link down (SStatus 0 SControl 300)
[ =A0 16.127601] ata1.01: link offline, clearing class 3 to NONE
[ =A0 16.151487] ata1.00: configured for UDMA/33
[ =A0 21.151378=
] ata1.00: qc timeout (cmd 0xa0)



[ =A0 21.151448] ata1.00: TEST_UNIT_READY failed (err_mask=3D0x5)
[ =A0 21.151518] ata1.00: disabled
[ =A0 21.151603] ata1.00=
: hard resetting link
[ =A0 21.471351] ata1.01: hard resetting li=
nk



[ =A0 21.947430] ata1.00: SATA link up 1.5 Gbps (SStatus 113 SControl =
310)
[ =A0 21.947523] ata1.01: SATA link down (SStatus 0 SControl=
 300)
[ =A0 21.947608] ata1.01: link offline, clearing class 3 to=
 NONE



[ =A0 21.947611] ata1: EH complete
[ =A0 21.963868] iTCO_wdt=
: Intel TCO WatchDog Timer Driver v1.10
[ =A0 21.963965] iTCO_wdt=
: Found a ICH10 TCO device (Version=3D2, TCOBASE=3D0x05e0)
[ =A0 =
21.964124] iTCO_wdt: initialized. heartbeat=3D30 sec (nowayout=3D0)



[ =A0 21.997872] Error: Driver 'pcspkr' is already registered,=
 aborting...
[ =A0 22.010315] alg: No test for __gcm-aes-aesni (_=
_driver-gcm-aes-aesni)
[ =A0 22.995255] EXT4-fs (dm-0): re-mounte=
d. Opts: (null)



[ =A0 23.177611] EXT4-fs (dm-0): re-mounted. Opts: errors=3Dremount-ro=

[ =A0 23.281974] loop: module loaded
[ =A0 23.346661] =
lp: driver loaded but no devices found
[ =A0 24.043404] Adding 41=
94300k swap on /dev/mapper/xen-fw_swap. =A0Priority:-1 extents:1 across:419=
4300k=A0



[ =A0 24.347072] EXT4-fs (sda3): mounted filesystem with ordered data =
mode. Opts: (null)
[ =A0 24.386139] FAT-fs (sda2): utf8 is not a =
recommended IO charset for FAT filesystems, filesystem will be case sensiti=
ve!



[ =A0 25.140294] bnx2 0000:0b:00.0: eth0: using MSIX
[ =A0 2=
5.140439] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ =
=A0 25.181911] Bridge firewalling registered
[ =A0 25.186131] dev=
ice eth1 entered promiscuous mode



[ =A0 25.288312] bnx2 0000:0b:00.1: eth1: using MSIX
[ =A0 2=
5.288410] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[ =
=A0 25.290413] IPv6: ADDRCONF(NETDEV_UP): xenbr0: link is not ready

[ =A0 26.898999] bnx2 0000:0b:00.0: eth0: NIC Copper Link is Up, 100 Mbps f=
ull duplex


[ =A0 26.899091]=A0
[ =A0 26.899222] IPv6: ADDRCONF(NETDEV_C=
HANGE): eth0: link becomes ready
[ =A0 28.981380] bnx2 0000:0b:00=
.1: eth1: NIC Copper Link is Up, 1000 Mbps full duplex
[ =A0 28.9=
81477]=A0



[ =A0 28.981613] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes rea=
dy
[ =A0 28.981698] xenbr0: port 1(eth1) entered forwarding state=

[ =A0 28.981771] xenbr0: port 1(eth1) entered forwarding state


[ =A0 28.981850] IPv6: ADDRCONF(NETDEV_CHANGE): xenbr0: link becomes r=
eady
[ =A0 33.512189] RPC: Registered named UNIX socket transport=
 module.
[ =A0 33.512281] RPC: Registered udp transport module.


[ =A0 33.512351] RPC: Registered tcp transport module.
[ =A0=
 33.512420] RPC: Registered tcp NFSv4.1 backchannel transport module.
=

[ =A0 33.533692] FS-Cache: Loaded
[ =A0 33.547314] FS-Cache:=
 Netfs 'nfs' registered for caching



[ =A0 33.579870] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
[ =
=A0 34.845026] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
<=
div>
[ =A0 34.854870] ip_tables: (C) 2000-2006 Netfilter Core Team


[ =A0 35.475210] ppdev: user-space parallel port driver
[ =
=A0 39.140866] colord-sane[2701]: segfault at 0 ip 00007fc826bc4884 sp 0000=
7fff6a44fea0 error 4 in l=
ibc-2.13.so[7fc826b1f000+17d000]



[ =A0 44.011341] xenbr0: port 1(eth1) entered forwarding state


Thanks for all,
Allan Sche=
id






-- 
<=
em>Att,
Allan Vicente Scheid


Acad=EAmico de Ci=EAncia da Computa=E7=E3o -=
 Unioeste Foz





--14dae934109feecd8704cbc0e07e--


--===============4323735893482094400==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4323735893482094400==--


From xen-devel-bounces@lists.xen.org Thu Oct 11 05:56:00 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 05:56:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMBjy-0001g2-8x; Thu, 11 Oct 2012 05:55:26 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMA5N-00013q-6M
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 04:09:25 +0000
X-Env-Sender: avs.009@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1349928549!8138114!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8012 invoked from network); 11 Oct 2012 04:09:10 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Oct 2012 04:09:10 -0000
Received: by mail-ie0-f173.google.com with SMTP id 17so2911021iea.32
	for ; Wed, 10 Oct 2012 21:09:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=PBoaX0hWyFiG2/NUOkbkFFwuWZC0noIesAxrwLor5xU=;
	b=tRRz4WNWKRxgn4aGmd74Sb/wjcPOORFtInkOMgwGXmD1jGcjl5cXiPEDZC7m7FEUWp
	o5EIGfIhfkHhc/0QI87FvTwUy6zJhTGEKzH681ZyM3a6kdEaVB7jLGVWBboFpJq4NQIO
	7Eans+ABh9fQf6ltDSw2nTQdE0w1pjuZDIrdk9cWClmToX+vyhlKDWAsfxP+lBiQiS7d
	OlF21UAsPkj1M1FiyIGqk618Q5oLyBd/Dg+a9IfTjGl3WB57KSjUvec+F0mlOrsTDpXO
	oK7P40pou6RcHcnBHG2rOYH4ro/Xkzg87v+pZ4LKmtoa7dyF2fRyYCNoDiHj7aruT6GO
	IAFA==
MIME-Version: 1.0
Received: by 10.43.48.129 with SMTP id uw1mr20141161icb.10.1349928544597; Wed,
	10 Oct 2012 21:09:04 -0700 (PDT)
Received: by 10.64.22.71 with HTTP; Wed, 10 Oct 2012 21:09:04 -0700 (PDT)
Date: Thu, 11 Oct 2012 01:09:04 -0300
Message-ID: 
From: Allan Scheid 
To: xen-devel@lists.xen.org
X-Mailman-Approved-At: Thu, 11 Oct 2012 05:55:25 +0000
Subject: [Xen-devel] Xen 4.2 with EFI on IBM x3650 ACPI Bug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============5491451415256564798=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5491451415256564798==
Content-Type: multipart/alternative; boundary=bcaec5299feb5f768904cbc0bbb9

--bcaec5299feb5f768904cbc0bbb9
Content-Type: text/plain; charset=ISO-8859-1

Hellow all, i need help to fix this bug:

ACPI BIOS Bug: Error: A valid RSDP was not found (20120711/tbxfroot-219)

Because of this first errors i get this after, and it causes don't work USB
ports and some PCI cards on the system:

can't find IRQ for PCI INT A; please try using pci=biosirq

Kernel: 3.6.1-xen self compiled (work perfect without xen multiboot)
Xen Version: 4.2
Grub2 EFI: 1.99-23
Debian Unstable distro

dmesg output:

[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.6.1-xen (root@lca-fw) (gcc version 4.7.1
(Debian 4.7.1-7) ) #1 SMP Wed Oct 10 22:46:05 BRT 2012
[    0.000000] Command line: placeholder root=/dev/mapper/xen-fw_root ro
[    0.000000] Freeing 6c-6d pfn range: 1 pages freed
[    0.000000] 1-1 mapping on 6c->6d
[    0.000000] Freeing 9f-100 pfn range: 97 pages freed
[    0.000000] 1-1 mapping on 9f->100
[    0.000000] Freeing 7acb7-7ccb8 pfn range: 8193 pages freed
[    0.000000] 1-1 mapping on 7acb7->7ccb8
[    0.000000] Freeing 7d4f0-7d51b pfn range: 43 pages freed
[    0.000000] 1-1 mapping on 7d4f0->7d51b
[    0.000000] Freeing 7d53f-7d56a pfn range: 43 pages freed
[    0.000000] 1-1 mapping on 7d53f->7d56a
[    0.000000] Freeing 7d704-7d7b4 pfn range: 176 pages freed
[    0.000000] 1-1 mapping on 7d704->7d7b4
[    0.000000] Freeing 7f5ef-7f7ff pfn range: 528 pages freed
[    0.000000] 1-1 mapping on 7f5ef->7f7ff
[    0.000000] Freeing 7f800-f258d pfn range: 470413 pages freed
[    0.000000] 1-1 mapping on 7f800->100000
[    0.000000] Released 479494 pages of unused memory
[    0.000000] Set 535417 page(s) to 1-1 mapping
[    0.000000] Populating 100000-175106 pfn range: 479494 pages added
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] Xen: [mem 0x0000000000000000-0x000000000006bfff] usable
[    0.000000] Xen: [mem 0x000000000006c000-0x000000000006cfff] ACPI NVS
[    0.000000] Xen: [mem 0x000000000006d000-0x000000000009efff] usable
[    0.000000] Xen: [mem 0x000000000009f000-0x000000000009ffff] ACPI NVS
[    0.000000] Xen: [mem 0x00000000000a0000-0x00000000000fffff] reserved
[    0.000000] Xen: [mem 0x0000000000100000-0x000000007acb6fff] usable
[    0.000000] Xen: [mem 0x000000007acb7000-0x000000007ccb7fff] reserved
[    0.000000] Xen: [mem 0x000000007ccb8000-0x000000007d4effff] usable
[    0.000000] Xen: [mem 0x000000007d4f0000-0x000000007d51afff] reserved
[    0.000000] Xen: [mem 0x000000007d51b000-0x000000007d53efff] usable
[    0.000000] Xen: [mem 0x000000007d53f000-0x000000007d569fff] reserved
[    0.000000] Xen: [mem 0x000000007d56a000-0x000000007d703fff] usable
[    0.000000] Xen: [mem 0x000000007d704000-0x000000007d7b3fff] reserved
[    0.000000] Xen: [mem 0x000000007d7b4000-0x000000007f5eefff] usable
[    0.000000] Xen: [mem 0x000000007f5ef000-0x000000007f6defff] reserved
[    0.000000] Xen: [mem 0x000000007f6df000-0x000000007f7defff] ACPI NVS
[    0.000000] Xen: [mem 0x000000007f7df000-0x000000007f7fefff] ACPI data
[    0.000000] Xen: [mem 0x000000007f7ff000-0x000000007f7fffff] usable
[    0.000000] Xen: [mem 0x0000000080000000-0x000000008fffffff] reserved
[    0.000000] Xen: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved
[    0.000000] Xen: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
[    0.000000] Xen: [mem 0x00000000ff800000-0x00000000ffffffff] reserved
[    0.000000] Xen: [mem 0x0000000100000000-0x000000017fffffff] usable
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI 2.5 present.
[    0.000000] DMI: IBM System x3650 M3 -[7945AC1]-/00D4062, BIOS
-[D6E157AUS-1.15]- 06/13/2012
[    0.000000] e820: update [mem 0x00000000-0x0000ffff] usable ==> reserved
[    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[    0.000000] No AGP bridge found
[    0.000000] e820: last_pfn = 0x180000 max_arch_pfn = 0x400000000
[    0.000000] e820: last_pfn = 0x7f800 max_arch_pfn = 0x400000000
[    0.000000] initial memory mapped: [mem 0x00000000-0x02334fff]
[    0.000000] Base memory trampoline at [ffff880000099000] 99000 size 24576
[    0.000000] init_memory_mapping: [mem 0x00000000-0x7f7fffff]
[    0.000000]  [mem 0x00000000-0x7f7fffff] page 4k
[    0.000000] kernel direct mapping tables up to 0x7f7fffff @ [mem
0x01831000-0x01c2ffff]
[    0.000000] xen: setting RW the range 1c14000 - 1c30000
[    0.000000] init_memory_mapping: [mem 0x100000000-0x17fffffff]
[    0.000000]  [mem 0x100000000-0x17fffffff] page 4k
[    0.000000] kernel direct mapping tables up to 0x17fffffff @ [mem
0x7e9e8000-0x7f5eefff]
[    0.000000] xen: setting RW the range 7edea000 - 7f5ef000
[    0.000000] RAMDISK: [mem 0x01c30000-0x02334fff]
[    0.000000] ACPI BIOS Bug: Error: A valid RSDP was not found
(20120711/tbxfroot-219)
[    0.000000] NUMA turned off
[    0.000000] Faking a node at [mem 0x0000000000000000-0x000000017fffffff]
[    0.000000] Initmem setup node 0 [mem 0x00000000-0x17fffffff]
[    0.000000]   NODE_DATA [mem 0x175102000-0x175105fff]
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x00010000-0x00ffffff]
[    0.000000]   DMA32    [mem 0x01000000-0xffffffff]
[    0.000000]   Normal   [mem 0x100000000-0x17fffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x00010000-0x0006bfff]
[    0.000000]   node   0: [mem 0x0006d000-0x0009efff]
[    0.000000]   node   0: [mem 0x00100000-0x7acb6fff]
[    0.000000]   node   0: [mem 0x7ccb8000-0x7d4effff]
[    0.000000]   node   0: [mem 0x7d51b000-0x7d53efff]
[    0.000000]   node   0: [mem 0x7d56a000-0x7d703fff]
[    0.000000]   node   0: [mem 0x7d7b4000-0x7f5eefff]
[    0.000000]   node   0: [mem 0x7f7ff000-0x7f7fffff]
[    0.000000]   node   0: [mem 0x100000000-0x17fffffff]
[    0.000000] On node 0 totalpages: 1037431
[    0.000000]   DMA zone: 56 pages used for memmap
[    0.000000]   DMA zone: 6 pages reserved
[    0.000000]   DMA zone: 3920 pages, LIFO batch:0
[    0.000000]   DMA32 zone: 14280 pages used for memmap
[    0.000000]   DMA32 zone: 494881 pages, LIFO batch:31
[    0.000000]   Normal zone: 7168 pages used for memmap
[    0.000000]   Normal zone: 517120 pages, LIFO batch:31
[    0.000000] SFI: Simple Firmware Interface v0.81
http://simplefirmware.org
[    0.000000] smpboot: Allowing 1 CPUs, 0 hotplug CPUs
[    0.000000] nr_irqs_gsi: 16
[    0.000000] PM: Registered nosave memory: 000000000006c000 -
000000000006d000
[    0.000000] PM: Registered nosave memory: 000000000009f000 -
00000000000a0000
[    0.000000] PM: Registered nosave memory: 00000000000a0000 -
0000000000100000
[    0.000000] PM: Registered nosave memory: 000000007acb7000 -
000000007ccb8000
[    0.000000] PM: Registered nosave memory: 000000007d4f0000 -
000000007d51b000
[    0.000000] PM: Registered nosave memory: 000000007d53f000 -
000000007d56a000
[    0.000000] PM: Registered nosave memory: 000000007d704000 -
000000007d7b4000
[    0.000000] PM: Registered nosave memory: 000000007f5ef000 -
000000007f6df000
[    0.000000] PM: Registered nosave memory: 000000007f6df000 -
000000007f7df000
[    0.000000] PM: Registered nosave memory: 000000007f7df000 -
000000007f7ff000
[    0.000000] PM: Registered nosave memory: 000000007f800000 -
0000000080000000
[    0.000000] PM: Registered nosave memory: 0000000080000000 -
0000000090000000
[    0.000000] PM: Registered nosave memory: 0000000090000000 -
00000000fed1c000
[    0.000000] PM: Registered nosave memory: 00000000fed1c000 -
00000000fed20000
[    0.000000] PM: Registered nosave memory: 00000000fed20000 -
00000000fee00000
[    0.000000] PM: Registered nosave memory: 00000000fee00000 -
00000000fee01000
[    0.000000] PM: Registered nosave memory: 00000000fee01000 -
00000000ff800000
[    0.000000] PM: Registered nosave memory: 00000000ff800000 -
0000000100000000
[    0.000000] e820: [mem 0x90000000-0xfed1bfff] available for PCI devices
[    0.000000] Booting paravirtualized kernel on Xen
[    0.000000] Xen version: 4.2.0 (preserve-AD)
[    0.000000] setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:1
nr_node_ids:1
[    0.000000] PERCPU: Embedded 28 pages/cpu @ffff880174e00000 s83840 r8192
d22656 u2097152
[    0.000000] pcpu-alloc: s83840 r8192 d22656 u2097152 alloc=1*2097152
[    0.000000] pcpu-alloc: [0] 0
[    1.096975] Built 1 zonelists in Zone order, mobility grouping on.
 Total pages: 1015921
[    1.096977] Policy zone: Normal
[    1.096979] Kernel command line: placeholder
root=/dev/mapper/xen-fw_root ro
[    1.097016] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    1.097021] __ex_table already sorted, skipping sort
[    1.121932] software IO TLB [mem 0x16c800000-0x1707fffff] (64MB) mapped
at [ffff88016c800000-ffff8801707fffff]
[    1.138656] Memory: 3815116k/6291456k available (3573k kernel code,
2141732k absent, 334608k reserved, 3147k data, 592k init)
[    1.138717] Hierarchical RCU implementation.
[    1.138718] RCU dyntick-idle grace-period acceleration is enabled.
[    1.138719] RCU restricting CPUs from NR_CPUS=512 to nr_cpu_ids=1.
[    1.138728] NR_IRQS:33024 nr_irqs:256 16
[    1.147171] Console: colour VGA+ 80x25
[    1.154296] console [tty0] enabled
[    1.159002] allocated 16777216 bytes of page_cgroup
[    1.159079] please try 'cgroup_disable=memory' option if you don't want
memory cgroups
[    1.159208] Xen: using vcpuop timer interface
[    1.159214] installing Xen timer for CPU 0
[    1.159303] tsc: Detected 2400.126 MHz processor
[    1.159375] Calibrating delay loop (skipped), value calculated using
timer frequency.. 4800.25 BogoMIPS (lpj=9600504)
[    1.159517] pid_max: default: 32768 minimum: 301
[    1.159607] Security Framework initialized
[    1.159680] AppArmor: AppArmor disabled by boot time parameter
[    1.160298] Dentry cache hash table entries: 524288 (order: 10, 4194304
bytes)
[    1.161752] Inode-cache hash table entries: 262144 (order: 9, 2097152
bytes)
[    1.162415] Mount-cache hash table entries: 256
[    1.162658] Initializing cgroup subsys cpuacct
[    1.162729] Initializing cgroup subsys memory
[    1.162806] Initializing cgroup subsys devices
[    1.162876] Initializing cgroup subsys freezer
[    1.162945] Initializing cgroup subsys net_cls
[    1.163014] Initializing cgroup subsys blkio
[    1.163082] Initializing cgroup subsys perf_event
[    1.163204] CPU: Physical Processor ID: 0
[    1.163277] CPU: Processor Core ID: 0
[    1.163346] mce: CPU supports 2 MCE banks
[    1.163452] Last level iTLB entries: 4KB 512, 2MB 7, 4MB 7
[    1.163452] Last level dTLB entries: 4KB 512, 2MB 32, 4MB 32
[    1.163452] tlb_flushall_shift is 0x6
[    1.163602] SMP alternatives: switching to UP code
[    1.171342] Freeing SMP alternatives: 8k freed
[    1.171471] Performance Events: unsupported p6 CPU model 44 no PMU
driver, software events only.
[    1.171785] NMI watchdog: disabled (cpu0): hardware events not enabled
[    1.171876] Brought up 1 CPUs
[    1.172058] devtmpfs: initialized
[    1.174970] PM: Registering ACPI NVS region [mem 0x0006c000-0x0006cfff]
(4096 bytes)
[    1.175062] PM: Registering ACPI NVS region [mem 0x0009f000-0x0009ffff]
(4096 bytes)
[    1.175153] PM: Registering ACPI NVS region [mem 0x7f6df000-0x7f7defff]
(1048576 bytes)
[    1.175314] Grant tables using version 2 layout.
[    1.175394] Grant table initialized
[    1.175514] dummy:
[    1.175625] NET: Registered protocol family 16
[    1.175969] PCI: Using configuration type 1 for base access
[    1.176599] bio: create slab  at 0
[    1.176719] ACPI: Interpreter disabled.
[    1.176796] xen/balloon: Initialising balloon driver.
[    1.177620] xen-balloon: Initialising balloon driver.
[    1.177761] vgaarb: loaded
[    1.177860] PCI: Probing PCI hardware
[    1.177929] PCI: root bus 00: using default resources
[    1.177930] PCI: Probing PCI hardware (bus 00)
[    1.177954] PCI host bridge to bus 0000:00
[    1.178025] pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
[    1.178098] pci_bus 0000:00: root bus resource [mem
0x00000000-0xffffffffff]
[    1.178173] pci_bus 0000:00: No busn resource found for root bus, will
use [bus 00-ff]
[    1.178266] pci_bus 0000:00: busn_res: [bus 00-ff] is inserted under
domain [bus 00-ff]
[    1.178287] pci 0000:00:00.0: [8086:3406] type 00 class 0x060000
[    1.178389] pci 0000:00:00.0: PME# supported from D0 D3hot D3cold
[    1.178425] pci 0000:00:01.0: [8086:3408] type 01 class 0x060400
[    1.178532] pci 0000:00:01.0: PME# supported from D0 D3hot D3cold
[    1.178571] pci 0000:00:02.0: [8086:3409] type 01 class 0x060400
[    1.178678] pci 0000:00:02.0: PME# supported from D0 D3hot D3cold
[    1.178716] pci 0000:00:03.0: [8086:340a] type 01 class 0x060400
[    1.178824] pci 0000:00:03.0: PME# supported from D0 D3hot D3cold
[    1.178865] pci 0000:00:05.0: [8086:340c] type 01 class 0x060400
[    1.178973] pci 0000:00:05.0: PME# supported from D0 D3hot D3cold
[    1.179013] pci 0000:00:07.0: [8086:340e] type 01 class 0x060400
[    1.179121] pci 0000:00:07.0: PME# supported from D0 D3hot D3cold
[    1.179161] pci 0000:00:09.0: [8086:3410] type 01 class 0x060400
[    1.179269] pci 0000:00:09.0: PME# supported from D0 D3hot D3cold
[    1.179309] pci 0000:00:10.0: [8086:3425] type 00 class 0x080000
[    1.179434] pci 0000:00:10.1: [8086:3426] type 00 class 0x080000
[    1.179543] pci 0000:00:11.0: [8086:3427] type 00 class 0x080000
[    1.179668] pci 0000:00:11.1: [8086:3428] type 00 class 0x080000
[    1.179795] pci 0000:00:14.0: [8086:342e] type 00 class 0x080000
[    1.179919] pci 0000:00:14.1: [8086:3422] type 00 class 0x080000
[    1.180053] pci 0000:00:14.2: [8086:3423] type 00 class 0x080000
[    1.180172] pci 0000:00:14.3: [8086:3438] type 00 class 0x080000
[    1.180273] pci 0000:00:15.0: [8086:342f] type 00 class 0x080020
[    1.180387] pci 0000:00:16.0: [8086:3430] type 00 class 0x088000
[    1.180408] pci 0000:00:16.0: reg 10: [mem 0x97a00000-0x97a03fff 64bit]
[    1.180540] pci 0000:00:16.1: [8086:3431] type 00 class 0x088000
[    1.180561] pci 0000:00:16.1: reg 10: [mem 0x97a04000-0x97a07fff 64bit]
[    1.180693] pci 0000:00:16.2: [8086:3432] type 00 class 0x088000
[    1.180713] pci 0000:00:16.2: reg 10: [mem 0x97a08000-0x97a0bfff 64bit]
[    1.180845] pci 0000:00:16.3: [8086:3433] type 00 class 0x088000
[    1.180866] pci 0000:00:16.3: reg 10: [mem 0x97a0c000-0x97a0ffff 64bit]
[    1.180997] pci 0000:00:16.4: [8086:3429] type 00 class 0x088000
[    1.181018] pci 0000:00:16.4: reg 10: [mem 0x97a10000-0x97a13fff 64bit]
[    1.181150] pci 0000:00:16.5: [8086:342a] type 00 class 0x088000
[    1.181170] pci 0000:00:16.5: reg 10: [mem 0x97a14000-0x97a17fff 64bit]
[    1.181302] pci 0000:00:16.6: [8086:342b] type 00 class 0x088000
[    1.181323] pci 0000:00:16.6: reg 10: [mem 0x97a18000-0x97a1bfff 64bit]
[    1.181455] pci 0000:00:16.7: [8086:342c] type 00 class 0x088000
[    1.181475] pci 0000:00:16.7: reg 10: [mem 0x97a1c000-0x97a1ffff 64bit]
[    1.181610] pci 0000:00:1a.0: [8086:3a37] type 00 class 0x0c0300
[    1.181681] pci 0000:00:1a.0: reg 20: [io  0x20a0-0x20bf]
[    1.181766] pci 0000:00:1a.1: [8086:3a38] type 00 class 0x0c0300
[    1.181837] pci 0000:00:1a.1: reg 20: [io  0x2080-0x209f]
[    1.181937] pci 0000:00:1a.7: [8086:3a3c] type 00 class 0x0c0320
[    1.181970] pci 0000:00:1a.7: reg 10: [mem 0x97a21000-0x97a213ff]
[    1.182116] pci 0000:00:1a.7: PME# supported from D0 D3hot D3cold
[    1.182153] pci 0000:00:1c.0: [8086:3a40] type 01 class 0x060400
[    1.182274] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
[    1.182316] pci 0000:00:1c.4: [8086:3a48] type 01 class 0x060400
[    1.182435] pci 0000:00:1c.4: PME# supported from D0 D3hot D3cold
[    1.182478] pci 0000:00:1d.0: [8086:3a34] type 00 class 0x0c0300
[    1.182549] pci 0000:00:1d.0: reg 20: [io  0x2060-0x207f]
[    1.182634] pci 0000:00:1d.1: [8086:3a35] type 00 class 0x0c0300
[    1.182705] pci 0000:00:1d.1: reg 20: [io  0x2040-0x205f]
[    1.182790] pci 0000:00:1d.2: [8086:3a36] type 00 class 0x0c0300
[    1.182860] pci 0000:00:1d.2: reg 20: [io  0x2020-0x203f]
[    1.182960] pci 0000:00:1d.7: [8086:3a3a] type 00 class 0x0c0320
[    1.182993] pci 0000:00:1d.7: reg 10: [mem 0x97a20000-0x97a203ff]
[    1.183138] pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold
[    1.183173] pci 0000:00:1e.0: [8086:244e] type 01 class 0x060401
[    1.183279] pci 0000:00:1f.0: [8086:3a18] type 00 class 0x060100
[    1.183458] pci 0000:00:1f.2: [8086:3a20] type 00 class 0x01018f
[    1.183484] pci 0000:00:1f.2: reg 10: [io  0x2118-0x211f]
[    1.183497] pci 0000:00:1f.2: reg 14: [io  0x212c-0x212f]
[    1.183510] pci 0000:00:1f.2: reg 18: [io  0x2110-0x2117]
[    1.183522] pci 0000:00:1f.2: reg 1c: [io  0x2128-0x212b]
[    1.183535] pci 0000:00:1f.2: reg 20: [io  0x20f0-0x20ff]
[    1.183548] pci 0000:00:1f.2: reg 24: [io  0x20e0-0x20ef]
[    1.183629] pci 0000:00:1f.3: [8086:3a30] type 00 class 0x0c0500
[    1.183653] pci 0000:00:1f.3: reg 10: [mem 0x97a22000-0x97a220ff 64bit]
[    1.183689] pci 0000:00:1f.3: reg 20: [io  0x2000-0x201f]
[    1.183746] pci 0000:00:1f.5: [8086:3a26] type 00 class 0x010185
[    1.183772] pci 0000:00:1f.5: reg 10: [io  0x2108-0x210f]
[    1.183784] pci 0000:00:1f.5: reg 14: [io  0x2124-0x2127]
[    1.183797] pci 0000:00:1f.5: reg 18: [io  0x2100-0x2107]
[    1.183816] pci 0000:00:1f.5: reg 1c: [io  0x2120-0x2123]
[    1.183829] pci 0000:00:1f.5: reg 20: [io  0x20d0-0x20df]
[    1.183841] pci 0000:00:1f.5: reg 24: [io  0x20c0-0x20cf]
[    1.183985] pci_bus 0000:0b: busn_res: [bus 0b-0f] is inserted under
[bus 00-ff]
[    1.184016] pci 0000:0b:00.0: [14e4:1639] type 00 class 0x020000
[    1.184040] pci 0000:0b:00.0: reg 10: [mem 0x92000000-0x93ffffff 64bit]
[    1.184181] pci 0000:0b:00.0: PME# supported from D0 D3hot D3cold
[    1.184224] pci 0000:0b:00.1: [14e4:1639] type 00 class 0x020000
[    1.184248] pci 0000:0b:00.1: reg 10: [mem 0x94000000-0x95ffffff 64bit]
[    1.184390] pci 0000:0b:00.1: PME# supported from D0 D3hot D3cold
[    1.191939] pci 0000:00:01.0: PCI bridge to [bus 0b-0f]
[    1.192017] pci 0000:00:01.0:   bridge window [mem 0x92000000-0x95ffffff]
[    1.192089] pci_bus 0000:10: busn_res: [bus 10-14] is inserted under
[bus 00-ff]
[    1.192093] pci 0000:00:02.0: PCI bridge to [bus 10-14]
[    1.192240] pci_bus 0000:15: busn_res: [bus 15-19] is inserted under
[bus 00-ff]
[    1.192244] pci 0000:00:03.0: PCI bridge to [bus 15-19]
[    1.192389] pci_bus 0000:1a: busn_res: [bus 1a-1e] is inserted under
[bus 00-ff]
[    1.192392] pci 0000:00:05.0: PCI bridge to [bus 1a-1e]
[    1.192539] pci_bus 0000:1f: busn_res: [bus 1f-23] is inserted under
[bus 00-ff]
[    1.192542] pci 0000:00:07.0: PCI bridge to [bus 1f-23]
[    1.192688] pci_bus 0000:24: busn_res: [bus 24-28] is inserted under
[bus 00-ff]
[    1.192691] pci 0000:00:09.0: PCI bridge to [bus 24-28]
[    1.192838] pci_bus 0000:01: busn_res: [bus 01-05] is inserted under
[bus 00-ff]
[    1.192863] pci 0000:01:00.0: [1000:0073] type 00 class 0x010400
[    1.192884] pci 0000:01:00.0: reg 10: [io  0x1000-0x10ff]
[    1.192908] pci 0000:01:00.0: reg 14: [mem 0x97940000-0x97943fff 64bit]
[    1.192932] pci 0000:01:00.0: reg 1c: [mem 0x97900000-0x9793ffff 64bit]
[    1.192962] pci 0000:01:00.0: reg 30: [mem 0xfffe0000-0xffffffff pref]
[    1.193060] pci 0000:01:00.0: supports D1 D2
[    1.200042] pci 0000:00:1c.0: PCI bridge to [bus 01-05]
[    1.200117] pci 0000:00:1c.0:   bridge window [io  0x1000-0x1fff]
[    1.200123] pci 0000:00:1c.0:   bridge window [mem 0x97900000-0x979fffff]
[    1.200196] pci_bus 0000:06: busn_res: [bus 06-0a] is inserted under
[bus 00-ff]
[    1.200228] pci 0000:06:00.0: [101b:0452] type 01 class 0x060400
[    1.200394] pci 0000:06:00.0: PME# supported from D0 D3hot D3cold
[    1.208144] pci 0000:00:1c.4: PCI bridge to [bus 06-0a]
[    1.208223] pci 0000:00:1c.4:   bridge window [mem 0x97000000-0x978fffff]
[    1.208231] pci 0000:00:1c.4:   bridge window [mem 0x96000000-0x96ffffff
64bit pref]
[    1.208330] pci_bus 0000:07: busn_res: [bus 07] is inserted under [bus
06-0a]
[    1.208353] pci 0000:07:00.0: [102b:0530] type 00 class 0x030000
[    1.208388] pci 0000:07:00.0: reg 10: [mem 0x96000000-0x96ffffff pref]
[    1.208407] pci 0000:07:00.0: reg 14: [mem 0x97800000-0x97803fff]
[    1.208427] pci 0000:07:00.0: reg 18: [mem 0x97000000-0x977fffff]
[    1.208633] pci 0000:06:00.0: PCI bridge to [bus 07]
[    1.208713] pci 0000:06:00.0:   bridge window [mem 0x97000000-0x978fffff]
[    1.208720] pci 0000:06:00.0:   bridge window [mem 0x96000000-0x96ffffff
pref]
[    1.208768] pci_bus 0000:29: busn_res: [bus 29-2d] is inserted under
[bus 00-ff]
[    1.208829] pci 0000:00:1e.0: PCI bridge to [bus 29-2d] (subtractive
decode)
[    1.208917] pci 0000:00:1e.0:   bridge window [io  0x0000-0xffff]
(subtractive decode)
[    1.208919] pci 0000:00:1e.0:   bridge window [mem
0x00000000-0xffffffffff] (subtractive decode)
[    1.208978] pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 2d
[    1.210287] vgaarb: device added:
PCI:0000:07:00.0,decodes=io+mem,owns=io+mem,locks=none
[    1.210898] PCI: pci_cache_line_size set to 64 bytes
[    1.211078] e820: reserve RAM buffer [mem 0x0006c000-0x0006ffff]
[    1.211080] e820: reserve RAM buffer [mem 0x0009f000-0x0009ffff]
[    1.211081] e820: reserve RAM buffer [mem 0x7acb7000-0x7bffffff]
[    1.211082] e820: reserve RAM buffer [mem 0x7d4f0000-0x7fffffff]
[    1.211086] e820: reserve RAM buffer [mem 0x7d53f000-0x7fffffff]
[    1.211088] e820: reserve RAM buffer [mem 0x7d704000-0x7fffffff]
[    1.211091] e820: reserve RAM buffer [mem 0x7f5ef000-0x7fffffff]
[    1.211093] e820: reserve RAM buffer [mem 0x7f800000-0x7fffffff]
[    1.211210] Switching to clocksource xen
[    1.212720] pnp: PnP ACPI: disabled
[    1.214391] pci 0000:01:00.0: no compatible bridge window for [mem
0xfffe0000-0xffffffff pref]
[    1.214569] pci 0000:00:1c.0: bridge window [mem 0x00100000-0x001fffff
pref] to [bus 01-05] add_size 200000
[    1.214613] pci 0000:00:1c.0: res[15]=[mem 0x00100000-0x001fffff pref]
get_res_add_size add_size 200000
[    1.214617] pci 0000:00:1c.0: BAR 15: assigned [mem
0x90000000-0x902fffff pref]
[    1.214708] pci 0000:00:01.0: PCI bridge to [bus 0b-0f]
[    1.214783] pci 0000:00:01.0:   bridge window [mem 0x92000000-0x95ffffff]
[    1.214865] pci 0000:00:02.0: PCI bridge to [bus 10-14]
[    1.214948] pci 0000:00:03.0: PCI bridge to [bus 15-19]
[    1.215032] pci 0000:00:05.0: PCI bridge to [bus 1a-1e]
[    1.215114] pci 0000:00:07.0: PCI bridge to [bus 1f-23]
[    1.215198] pci 0000:00:09.0: PCI bridge to [bus 24-28]
[    1.215282] pci 0000:01:00.0: BAR 6: assigned [mem 0x90000000-0x9001ffff
pref]
[    1.215383] pci 0000:00:1c.0: PCI bridge to [bus 01-05]
[    1.215456] pci 0000:00:1c.0:   bridge window [io  0x1000-0x1fff]
[    1.215532] pci 0000:00:1c.0:   bridge window [mem 0x97900000-0x979fffff]
[    1.215609] pci 0000:00:1c.0:   bridge window [mem 0x90000000-0x902fffff
pref]
[    1.215705] pci 0000:06:00.0: PCI bridge to [bus 07]
[    1.215782] pci 0000:06:00.0:   bridge window [mem 0x97000000-0x978fffff]
[    1.215860] pci 0000:06:00.0:   bridge window [mem 0x96000000-0x96ffffff
pref]
[    1.223235] pci 0000:00:1c.4: PCI bridge to [bus 06-0a]
[    1.223310] pci 0000:00:1c.4:   bridge window [mem 0x97000000-0x978fffff]
[    1.223391] pci 0000:00:1c.4:   bridge window [mem 0x96000000-0x96ffffff
64bit pref]
[    1.223489] pci 0000:00:1e.0: PCI bridge to [bus 29-2d]
[    1.223580] pci 0000:00:01.0: can't find IRQ for PCI INT A; please try
using pci=biosirq
[    1.223680] pci 0000:00:02.0: can't find IRQ for PCI INT A; please try
using pci=biosirq
[    1.223780] pci 0000:00:03.0: can't find IRQ for PCI INT A; please try
using pci=biosirq
[    1.223880] pci 0000:00:05.0: can't find IRQ for PCI INT A; please try
using pci=biosirq
[    1.223981] pci 0000:00:07.0: can't find IRQ for PCI INT A; please try
using pci=biosirq
[    1.224081] pci 0000:00:09.0: can't find IRQ for PCI INT A; please try
using pci=biosirq
[    1.224183] pci 0000:00:1c.0: can't find IRQ for PCI INT A; please try
using pci=biosirq
[    1.224283] pci 0000:00:1c.4: can't find IRQ for PCI INT A; please try
using pci=biosirq
[    1.224385] pci 0000:06:00.0: can't find IRQ for PCI INT A; please try
using pci=biosirq
[    1.224487] pci 0000:00:1e.0: setting latency timer to 64
[    1.224492] pci_bus 0000:00: resource 4 [io  0x0000-0xffff]
[    1.224494] pci_bus 0000:00: resource 5 [mem 0x00000000-0xffffffffff]
[    1.224496] pci_bus 0000:0b: resource 1 [mem 0x92000000-0x95ffffff]
[    1.224498] pci_bus 0000:01: resource 0 [io  0x1000-0x1fff]
[    1.224500] pci_bus 0000:01: resource 1 [mem 0x97900000-0x979fffff]
[    1.224502] pci_bus 0000:01: resource 2 [mem 0x90000000-0x902fffff pref]
[    1.224504] pci_bus 0000:06: resource 1 [mem 0x97000000-0x978fffff]
[    1.224507] pci_bus 0000:06: resource 2 [mem 0x96000000-0x96ffffff 64bit
pref]
[    1.224510] pci_bus 0000:07: resource 1 [mem 0x97000000-0x978fffff]
[    1.224512] pci_bus 0000:07: resource 2 [mem 0x96000000-0x96ffffff pref]
[    1.224514] pci_bus 0000:29: resource 4 [io  0x0000-0xffff]
[    1.224516] pci_bus 0000:29: resource 5 [mem 0x00000000-0xffffffffff]
[    1.224538] NET: Registered protocol family 2
[    1.225637] TCP established hash table entries: 524288 (order: 11,
8388608 bytes)
[    1.228185] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[    1.228521] TCP: Hash tables configured (established 524288 bind 65536)
[    1.228613] TCP: reno registered
[    1.228689] UDP hash table entries: 2048 (order: 4, 65536 bytes)
[    1.228785] UDP-Lite hash table entries: 2048 (order: 4, 65536 bytes)
[    1.228922] NET: Registered protocol family 1
[    1.229073] pci 0000:00:1a.0: can't find IRQ for PCI INT A; please try
using pci=biosirq
[    1.229201] pci 0000:00:1a.1: can't find IRQ for PCI INT B; please try
using pci=biosirq
[    1.229325] pci 0000:00:1a.7: can't find IRQ for PCI INT C; please try
using pci=biosirq
[    1.229466] pci 0000:00:1d.0: can't find IRQ for PCI INT A; please try
using pci=biosirq
[    1.229588] pci 0000:00:1d.1: can't find IRQ for PCI INT B; please try
using pci=biosirq
[    1.229708] pci 0000:00:1d.2: can't find IRQ for PCI INT C; please try
using pci=biosirq
[    1.229836] pci 0000:00:1d.7: can't find IRQ for PCI INT A; please try
using pci=biosirq
[    1.229986] pci 0000:07:00.0: Boot video device
[    1.229991] PCI: CLS 64 bytes, default 64
[    1.230040] Unpacking initramfs...
[    1.236939] Freeing initrd memory: 7188k freed
[    1.238401] platform rtc_cmos: registered platform RTC device (no PNP
device found)
[    1.238695] audit: initializing netlink socket (disabled)
[    1.238779] type=2000 audit(1349925915.231:1): initialized
[    1.253042] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[    1.253247] VFS: Disk quotas dquot_6.5.2
[    1.253330] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    1.253465] msgmni has been set to 7465
[    1.253646] alg: No test for stdrng (krng)
[    1.253730] Block layer SCSI generic (bsg) driver version 0.4 loaded
(major 252)
[    1.253820] io scheduler noop registered
[    1.253888] io scheduler deadline registered
[    1.253960] io scheduler cfq registered (default)
[    1.254124] pcieport 0000:00:01.0: device [8086:3408] has invalid IRQ;
check vendor BIOS
[    1.254277] pcieport 0000:00:02.0: device [8086:3409] has invalid IRQ;
check vendor BIOS
[    1.254425] pcieport 0000:00:03.0: device [8086:340a] has invalid IRQ;
check vendor BIOS
[    1.254573] pcieport 0000:00:05.0: device [8086:340c] has invalid IRQ;
check vendor BIOS
[    1.254723] pcieport 0000:00:07.0: device [8086:340e] has invalid IRQ;
check vendor BIOS
[    1.254870] pcieport 0000:00:09.0: device [8086:3410] has invalid IRQ;
check vendor BIOS
[    1.255019] pcieport 0000:00:1c.0: device [8086:3a40] has invalid IRQ;
check vendor BIOS
[    1.255170] pcieport 0000:00:1c.4: device [8086:3a48] has invalid IRQ;
check vendor BIOS
[    1.255389] ioapic: probe of 0000:00:15.0 failed with error -22
[    1.255467] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[    1.255554] pciehp: PCI Express Hot Plug Controller Driver version: 0.4
[    1.255627] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
[    1.255752] intel_idle: does not run on family 6 model 44
[    1.255833] Event-channel device installed.
[    1.255989] xen-pciback: backend is vpci
[    1.256298] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    1.277599] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[    1.298917] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
[    1.299221] Linux agpgart interface v0.103
[    1.299387] i8042: PNP: No PS/2 controller found. Probing ports directly.
[    1.551430] serio: i8042 KBD port at 0x60,0x64 irq 1
[    1.551580] mousedev: PS/2 mouse device common for all mice
[    1.551800] rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0
[    1.551897] rtc0: alarms up to one day, 114 bytes nvram
[    1.551972] EFI Variables Facility v0.08 2004-May-17
[    1.552053] drop_monitor: Initializing network drop monitor service
[    1.552197] TCP: cubic registered
[    1.552276] NET: Registered protocol family 10
[    1.552496] mip6: Mobile IPv6
[    1.552564] NET: Registered protocol family 17
[    1.552641] Key type dns_resolver registered
[    1.552859] PM: Hibernation image not present or could not be loaded.
[    1.552868] registered taskstats version 1
[    1.553635] rtc_cmos rtc_cmos: setting system clock to 2012-10-11
03:25:15 UTC (1349925915)
[    1.553954] Freeing unused kernel memory: 592k freed
[    1.554130] Write protecting the kernel read-only data: 6144k
[    1.555798] Freeing unused kernel memory: 512k freed
[    1.556107] Freeing unused kernel memory: 620k freed
[    1.583588] udevd[50]: starting version 175
[    1.657119] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[    1.663281] SCSI subsystem initialized
[    1.681024] megasas: 00.00.06.15-rc1 Mon. Mar. 19 17:00:00 PDT 2012
[    1.681111] megasas: 0x1000:0x0073:0x1014:0x03b1: bus 1:slot 0:func 0
[    1.681241] megaraid_sas 0000:01:00.0: can't find IRQ for PCI INT A;
please try using pci=biosirq
[    1.687892] megasas: FW now in Ready state
[    1.735350] megasas_init_mfi: fw_support_ieee=67108864
[    1.735407] megasas: INIT adapter done
[    1.807365] scsi0 : LSI SAS based MegaRAID driver
[    1.808799] scsi 0:0:8:0: Direct-Access     IBM-ESXS ST9146803SS
 B53C PQ: 0 ANSI: 5
[    1.811249] scsi 0:0:9:0: Direct-Access     ATA      ST9500620NS
 BE24 PQ: 0 ANSI: 5
[    1.812739] scsi 0:0:10:0: Direct-Access     ATA      ST9500620NS
 BE24 PQ: 0 ANSI: 5
[    1.824208] scsi 0:2:0:0: Direct-Access     IBM      ServeRAID M1015
 2.12 PQ: 0 ANSI: 5
[    1.839755] sd 0:2:0:0: [sdb] 1949216768 512-byte logical blocks: (997
GB/929 GiB)
[    1.840060] sd 0:2:0:0: [sdb] Write Protect is off
[    1.840141] sd 0:2:0:0: [sdb] Mode Sense: 1f 00 10 08
[    1.840153] sd 0:0:8:0: [sda] 286748000 512-byte logical blocks: (146
GB/136 GiB)
[    1.840302] sd 0:2:0:0: [sdb] Write cache: disabled, read cache:
disabled, supports DPO and FUA
[    1.842564] sd 0:0:8:0: [sda] Write Protect is off
[    1.842637] sd 0:0:8:0: [sda] Mode Sense: c3 00 10 08
[    1.843418]  sdb: sdb1
[    1.843898] sd 0:0:8:0: [sda] Write cache: disabled, read cache:
enabled, supports DPO and FUA
[    1.844117] sd 0:2:0:0: [sdb] Attached SCSI disk
[    1.866028]  sda: sda1 sda2 sda3 sda4
[    1.870498] sd 0:0:8:0: [sda] Attached SCSI disk
[    2.053157] device-mapper: uevent: version 1.0.3
[    2.053610] device-mapper: ioctl: 4.23.0-ioctl (2012-07-25) initialised:
dm-devel@redhat.com
[    2.214131] EXT4-fs (dm-0): mounted filesystem with ordered data mode.
Opts: (null)
[    3.162111] udevd[298]: starting version 175
[    3.419449] bnx2: Broadcom NetXtreme II Gigabit Ethernet Driver bnx2
v2.2.3 (June 27, 2012)
[    3.419565] bnx2 0000:0b:00.0: can't find IRQ for PCI INT A; please try
using pci=biosirq
[    3.420241] bnx2 0000:0b:00.0: eth0: Broadcom NetXtreme II BCM5709
1000Base-T (C0) PCI Express found at mem 92000000, IRQ 0, node addr
34:40:b5:ab:e5:b4
[    3.421062] bnx2 0000:0b:00.1: can't find IRQ for PCI INT B; please try
using pci=biosirq
[    3.421705] bnx2 0000:0b:00.1: eth1: Broadcom NetXtreme II BCM5709
1000Base-T (C0) PCI Express found at mem 94000000, IRQ 0, node addr
34:40:b5:ab:e5:b6
[    3.428805] dca service started, version 1.12.1
[    3.467169] EDAC MC: Ver: 3.0.0
[    3.473824] ioatdma: Intel(R) QuickData Technology Driver 4.00
[    3.473918] ioatdma 0000:00:16.0: enabling device (0000 -> 0002)
[    3.473996] ioatdma 0000:00:16.0: can't find IRQ for PCI INT A; please
try using pci=biosirq
[    3.474116] ioatdma 0000:00:16.0: channel error register unreachable
[    3.474191] ioatdma 0000:00:16.0: channel enumeration error
[    3.505302] microcode: CPU0 sig=0x206c2, pf=0x1, revision=0x15
[    3.505995] ioatdma 0000:00:16.0: Intel(R) I/OAT DMA Engine init failed
[    3.506096] ioatdma 0000:00:16.1: enabling device (0000 -> 0002)
[    3.506173] ioatdma 0000:00:16.1: can't find IRQ for PCI INT B; please
try using pci=biosirq
[    3.506296] ioatdma 0000:00:16.1: channel error register unreachable
[    3.506369] ioatdma 0000:00:16.1: channel enumeration error
[    3.506441] ioatdma 0000:00:16.1: Intel(R) I/OAT DMA Engine init failed
[    3.506532] ioatdma 0000:00:16.2: enabling device (0000 -> 0002)
[    3.506608] ioatdma 0000:00:16.2: can't find IRQ for PCI INT C; please
try using pci=biosirq
[    3.506722] ioatdma 0000:00:16.2: channel error register unreachable
[    3.506795] ioatdma 0000:00:16.2: channel enumeration error
[    3.506867] ioatdma 0000:00:16.2: Intel(R) I/OAT DMA Engine init failed
[    3.506957] ioatdma 0000:00:16.3: enabling device (0000 -> 0002)
[    3.507034] ioatdma 0000:00:16.3: can't find IRQ for PCI INT D; please
try using pci=biosirq
[    3.507147] ioatdma 0000:00:16.3: channel error register unreachable
[    3.507222] ioatdma 0000:00:16.3: channel enumeration error
[    3.507294] ioatdma 0000:00:16.3: Intel(R) I/OAT DMA Engine init failed
[    3.507398] ioatdma 0000:00:16.4: enabling device (0000 -> 0002)
[    3.507476] ioatdma 0000:00:16.4: can't find IRQ for PCI INT A; please
try using pci=biosirq
[    3.507590] ioatdma 0000:00:16.4: channel error register unreachable
[    3.507663] ioatdma 0000:00:16.4: channel enumeration error
[    3.507735] ioatdma 0000:00:16.4: Intel(R) I/OAT DMA Engine init failed
[    3.507826] ioatdma 0000:00:16.5: enabling device (0000 -> 0002)
[    3.507903] ioatdma 0000:00:16.5: can't find IRQ for PCI INT B; please
try using pci=biosirq
[    3.508016] ioatdma 0000:00:16.5: channel error register unreachable
[    3.508090] ioatdma 0000:00:16.5: channel enumeration error
[    3.508162] ioatdma 0000:00:16.5: Intel(R) I/OAT DMA Engine init failed
[    3.508255] ioatdma 0000:00:16.6: enabling device (0000 -> 0002)
[    3.508337] ioatdma 0000:00:16.6: can't find IRQ for PCI INT C; please
try using pci=biosirq
[    3.508454] ioatdma 0000:00:16.6: channel error register unreachable
[    3.508529] ioatdma 0000:00:16.6: channel enumeration error
[    3.508601] ioatdma 0000:00:16.6: Intel(R) I/OAT DMA Engine init failed
[    3.508692] ioatdma 0000:00:16.7: enabling device (0000 -> 0002)
[    3.508769] ioatdma 0000:00:16.7: can't find IRQ for PCI INT D; please
try using pci=biosirq
[    3.508885] ioatdma 0000:00:16.7: channel error register unreachable
[    3.508958] ioatdma 0000:00:16.7: channel enumeration error
[    3.509030] ioatdma 0000:00:16.7: Intel(R) I/OAT DMA Engine init failed
[    3.571248] usbcore: registered new interface driver usbfs
[    3.571330] usbcore: registered new interface driver hub
[    3.585483] ACPI Exception: AE_BAD_PARAMETER, Thread 1786484928 could
not acquire Mutex [0x1] (20120711/utmutex-276)
[    3.585675] ACPI Exception: AE_BAD_PARAMETER, Thread 1786484928 could
not acquire Mutex [0x1] (20120711/utmutex-276)
[    3.590919] usbcore: registered new device driver usb
[    3.603433] input: PC Speaker as /devices/platform/pcspkr/input/input0
[    3.604762] libata version 3.00 loaded.
[    3.607430] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    3.607535] ehci_hcd 0000:00:1a.7: can't find IRQ for PCI INT C; please
try using pci=biosirq
[    3.607629] ehci_hcd 0000:00:1a.7: Found HC with no IRQ.  Check BIOS/PCI
0000:00:1a.7 setup!
[    3.607723] ehci_hcd 0000:00:1a.7: init 0000:00:1a.7 fail, -19
[    3.607808] ehci_hcd 0000:00:1d.7: can't find IRQ for PCI INT A; please
try using pci=biosirq
[    3.607900] ehci_hcd 0000:00:1d.7: Found HC with no IRQ.  Check BIOS/PCI
0000:00:1d.7 setup!
[    3.607994] ehci_hcd 0000:00:1d.7: init 0000:00:1d.7 fail, -19
[    3.623701] i801_smbus 0000:00:1f.3: enabling device (0140 -> 0143)
[    3.623781] i801_smbus 0000:00:1f.3: can't find IRQ for PCI INT B;
please try using pci=biosirq
[    3.623874] ACPI Exception: AE_BAD_PARAMETER, Thread 1775910976 could
not acquire Mutex [0x1] (20120711/utmutex-276)
[    3.624093] i801_smbus 0000:00:1f.3: SMBus using PCI Interrupt
[    3.676083] ata_piix 0000:00:1f.2: version 2.13
[    3.676095] ata_piix 0000:00:1f.2: can't find IRQ for PCI INT A; please
try using pci=biosirq
[    3.676193] ata_piix 0000:00:1f.2: MAP [
[    3.676260]  P0 P2 P1 P3 ]
[    3.676539] ata_piix 0000:00:1f.2: setting latency timer to 64
[    3.677344] scsi1 : ata_piix
[    3.677732] scsi2 : ata_piix
[    3.677862] ata1: SATA max UDMA/133 cmd 0x2118 ctl 0x212c bmdma 0x20f0
[    3.677954] ata2: SATA max UDMA/133 cmd 0x2110 ctl 0x2128 bmdma 0x20f8
[    3.678154] gpio_ich: GPIO from 195 to 255 on gpio_ich
[    3.678606] ata_piix 0000:00:1f.5: can't find IRQ for PCI INT C; please
try using pci=biosirq
[    3.678703] ata_piix 0000:00:1f.5: MAP [
[    3.678771]  P0 -- P1 -- ]
[    3.679046] ata_piix 0000:00:1f.5: setting latency timer to 64
[    3.679562] scsi3 : ata_piix
[    3.680057] uhci_hcd: USB Universal Host Controller Interface driver
[    3.682601] scsi4 : ata_piix
[    3.682814] ata3: SATA max UDMA/133 cmd 0x2108 ctl 0x2124 bmdma 0x20d0
[    3.682893] ata4: SATA max UDMA/133 cmd 0x2100 ctl 0x2120 bmdma 0x20d8
[    3.683028] uhci_hcd 0000:00:1a.0: can't find IRQ for PCI INT A; please
try using pci=biosirq
[    3.683123] uhci_hcd 0000:00:1a.0: Found HC with no IRQ.  Check BIOS/PCI
0000:00:1a.0 setup!
[    3.683217] uhci_hcd 0000:00:1a.0: init 0000:00:1a.0 fail, -19
[    3.683300] uhci_hcd 0000:00:1a.1: can't find IRQ for PCI INT B; please
try using pci=biosirq
[    3.683408] uhci_hcd 0000:00:1a.1: Found HC with no IRQ.  Check BIOS/PCI
0000:00:1a.1 setup!
[    3.683504] uhci_hcd 0000:00:1a.1: init 0000:00:1a.1 fail, -19
[    3.683588] uhci_hcd 0000:00:1d.0: can't find IRQ for PCI INT A; please
try using pci=biosirq
[    3.683682] uhci_hcd 0000:00:1d.0: Found HC with no IRQ.  Check BIOS/PCI
0000:00:1d.0 setup!
[    3.683802] uhci_hcd 0000:00:1d.0: init 0000:00:1d.0 fail, -19
[    3.683933] uhci_hcd 0000:00:1d.1: can't find IRQ for PCI INT B; please
try using pci=biosirq
[    3.684026] uhci_hcd 0000:00:1d.1: Found HC with no IRQ.  Check BIOS/PCI
0000:00:1d.1 setup!
[    3.684121] uhci_hcd 0000:00:1d.1: init 0000:00:1d.1 fail, -19
[    3.684201] uhci_hcd 0000:00:1d.2: can't find IRQ for PCI INT C; please
try using pci=biosirq
[    3.684293] uhci_hcd 0000:00:1d.2: Found HC with no IRQ.  Check BIOS/PCI
0000:00:1d.2 setup!
[    3.684387] uhci_hcd 0000:00:1d.2: init 0000:00:1d.2 fail, -19
[    3.751594] microcode: Microcode Update Driver: v2.00 <
tigran@aivazian.fsnet.co.uk>, Peter Oruba
[    3.771183] iTCO_vendor_support: vendor-support=0
[    4.010635] ata3: SATA link down (SStatus 0 SControl 300)
[    4.022013] ata4: SATA link down (SStatus 0 SControl 300)
[    4.342660] ata2.00: SATA link down (SStatus 0 SControl 300)
[    4.342751] ata2.01: SATA link down (SStatus 0 SControl 300)
[    4.487426] ata1.00: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[    4.487519] ata1.01: SATA link down (SStatus 0 SControl 300)
[    4.487603] ata1.01: link offline, clearing class 3 to NONE
[    4.495491] ata1.00: ATAPI: IBM SATA DEVICE 81Y3657, IB01, max UDMA/33
[    4.511489] ata1.00: configured for UDMA/33
[    9.511364] ata1.00: qc timeout (cmd 0xa0)
[    9.511434] ata1.00: TEST_UNIT_READY failed (err_mask=0x5)
[   10.307422] ata1.00: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   10.307515] ata1.01: SATA link down (SStatus 0 SControl 300)
[   10.307600] ata1.01: link offline, clearing class 3 to NONE
[   10.331487] ata1.00: configured for UDMA/33
[   15.331361] ata1.00: qc timeout (cmd 0xa0)
[   15.331431] ata1.00: TEST_UNIT_READY failed (err_mask=0x5)
[   15.331504] ata1.00: limiting SATA link speed to 1.5 Gbps
[   15.331574] ata1.00: limiting speed to UDMA/33:PIO3
[   16.127423] ata1.00: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[   16.127515] ata1.01: SATA link down (SStatus 0 SControl 300)
[   16.127601] ata1.01: link offline, clearing class 3 to NONE
[   16.151487] ata1.00: configured for UDMA/33
[   21.151378] ata1.00: qc timeout (cmd 0xa0)
[   21.151448] ata1.00: TEST_UNIT_READY failed (err_mask=0x5)
[   21.151518] ata1.00: disabled
[   21.151603] ata1.00: hard resetting link
[   21.471351] ata1.01: hard resetting link
[   21.947430] ata1.00: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[   21.947523] ata1.01: SATA link down (SStatus 0 SControl 300)
[   21.947608] ata1.01: link offline, clearing class 3 to NONE
[   21.947611] ata1: EH complete
[   21.963868] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.10
[   21.963965] iTCO_wdt: Found a ICH10 TCO device (Version=2,
TCOBASE=0x05e0)
[   21.964124] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[   21.997872] Error: Driver 'pcspkr' is already registered, aborting...
[   22.010315] alg: No test for __gcm-aes-aesni (__driver-gcm-aes-aesni)
[   22.995255] EXT4-fs (dm-0): re-mounted. Opts: (null)
[   23.177611] EXT4-fs (dm-0): re-mounted. Opts: errors=remount-ro
[   23.281974] loop: module loaded
[   23.346661] lp: driver loaded but no devices found
[   24.043404] Adding 4194300k swap on /dev/mapper/xen-fw_swap.
 Priority:-1 extents:1 across:4194300k
[   24.347072] EXT4-fs (sda3): mounted filesystem with ordered data mode.
Opts: (null)
[   24.386139] FAT-fs (sda2): utf8 is not a recommended IO charset for FAT
filesystems, filesystem will be case sensitive!
[   25.140294] bnx2 0000:0b:00.0: eth0: using MSIX
[   25.140439] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   25.181911] Bridge firewalling registered
[   25.186131] device eth1 entered promiscuous mode
[   25.288312] bnx2 0000:0b:00.1: eth1: using MSIX
[   25.288410] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[   25.290413] IPv6: ADDRCONF(NETDEV_UP): xenbr0: link is not ready
[   26.898999] bnx2 0000:0b:00.0: eth0: NIC Copper Link is Up, 100 Mbps
full duplex
[   26.899091]
[   26.899222] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   28.981380] bnx2 0000:0b:00.1: eth1: NIC Copper Link is Up, 1000 Mbps
full duplex
[   28.981477]
[   28.981613] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[   28.981698] xenbr0: port 1(eth1) entered forwarding state
[   28.981771] xenbr0: port 1(eth1) entered forwarding state
[   28.981850] IPv6: ADDRCONF(NETDEV_CHANGE): xenbr0: link becomes ready
[   33.512189] RPC: Registered named UNIX socket transport module.
[   33.512281] RPC: Registered udp transport module.
[   33.512351] RPC: Registered tcp transport module.
[   33.512420] RPC: Registered tcp NFSv4.1 backchannel transport module.
[   33.533692] FS-Cache: Loaded
[   33.547314] FS-Cache: Netfs 'nfs' registered for caching
[   33.579870] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
[   34.845026] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
[   34.854870] ip_tables: (C) 2000-2006 Netfilter Core Team
[   35.475210] ppdev: user-space parallel port driver
[   39.140866] colord-sane[2701]: segfault at 0 ip 00007fc826bc4884 sp
00007fff6a44fea0 error 4 in libc-2.13.so[7fc826b1f000+17d000]
[   44.011341] xenbr0: port 1(eth1) entered forwarding state


Thanks for all,
Allan Scheid

--bcaec5299feb5f768904cbc0bbb9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hellow all, i need help to fix this bug:


ACPI BIOS Bug: Error: A valid RSDP was not found (20120=
711/tbxfroot-219)

Because of this first errors i g=
et this after, and it causes don't work USB ports and some PCI cards on=
 the system:



can't find IRQ for PCI INT A; please try using pci=
=3Dbiosirq

Kernel:=A03.6.1-xen self compiled (work=
 perfect without xen multiboot)
Xen Version: 4.2
Grub2 =
EFI: 1.99-23


Debian Unstable distro

dmesg output:

[ =A0 =A00.000000] Initializing cgroup subsys cpuset<=
/div>
[ =A0 =A00.000000] Initializing cgroup subsys cpu
[ =A0=
 =A00.000000] Linux version 3.6.1-xen (root@lca-fw) (gcc version 4.7.1 (Deb=
ian 4.7.1-7) ) #1 SMP Wed Oct 10 22:46:05 BRT 2012


[ =A0 =A00.000000] Command line: placeholder root=3D/dev/mapper/xen-fw=
_root ro
[ =A0 =A00.000000] Freeing 6c-6d pfn range: 1 pages free=
d
[ =A0 =A00.000000] 1-1 mapping on 6c->6d
[ =A0 =A0=
0.000000] Freeing 9f-100 pfn range: 97 pages freed


[ =A0 =A00.000000] 1-1 mapping on 9f->100
[ =A0 =A00.0000=
00] Freeing 7acb7-7ccb8 pfn range: 8193 pages freed
[ =A0 =A00.00=
0000] 1-1 mapping on 7acb7->7ccb8
[ =A0 =A00.000000] Freeing 7=
d4f0-7d51b pfn range: 43 pages freed


[ =A0 =A00.000000] 1-1 mapping on 7d4f0->7d51b
[ =A0 =A00=
.000000] Freeing 7d53f-7d56a pfn range: 43 pages freed
[ =A0 =A00=
.000000] 1-1 mapping on 7d53f->7d56a
[ =A0 =A00.000000] Freein=
g 7d704-7d7b4 pfn range: 176 pages freed


[ =A0 =A00.000000] 1-1 mapping on 7d704->7d7b4
[ =A0 =A00=
.000000] Freeing 7f5ef-7f7ff pfn range: 528 pages freed
[ =A0 =A0=
0.000000] 1-1 mapping on 7f5ef->7f7ff
[ =A0 =A00.000000] Freei=
ng 7f800-f258d pfn range: 470413 pages freed


[ =A0 =A00.000000] 1-1 mapping on 7f800->100000
[ =A0 =A0=
0.000000] Released 479494 pages of unused memory
[ =A0 =A00.00000=
0] Set 535417 page(s) to 1-1 mapping
[ =A0 =A00.000000] Populatin=
g 100000-175106 pfn range: 479494 pages added


[ =A0 =A00.000000] e820: BIOS-provided physical RAM map:
[ =
=A0 =A00.000000] Xen: [mem 0x0000000000000000-0x000000000006bfff] usable
[ =A0 =A00.000000] Xen: [mem 0x000000000006c000-0x000000000006cfff]=
 ACPI NVS


[ =A0 =A00.000000] Xen: [mem 0x000000000006d000-0x000000000009efff] us=
able
[ =A0 =A00.000000] Xen: [mem 0x000000000009f000-0x0000000000=
09ffff] ACPI NVS
[ =A0 =A00.000000] Xen: [mem 0x00000000000a0000-=
0x00000000000fffff] reserved


[ =A0 =A00.000000] Xen: [mem 0x0000000000100000-0x000000007acb6fff] us=
able
[ =A0 =A00.000000] Xen: [mem 0x000000007acb7000-0x000000007c=
cb7fff] reserved
[ =A0 =A00.000000] Xen: [mem 0x000000007ccb8000-=
0x000000007d4effff] usable


[ =A0 =A00.000000] Xen: [mem 0x000000007d4f0000-0x000000007d51afff] re=
served
[ =A0 =A00.000000] Xen: [mem 0x000000007d51b000-0x00000000=
7d53efff] usable
[ =A0 =A00.000000] Xen: [mem 0x000000007d53f000-=
0x000000007d569fff] reserved


[ =A0 =A00.000000] Xen: [mem 0x000000007d56a000-0x000000007d703fff] us=
able
[ =A0 =A00.000000] Xen: [mem 0x000000007d704000-0x000000007d=
7b3fff] reserved
[ =A0 =A00.000000] Xen: [mem 0x000000007d7b4000-=
0x000000007f5eefff] usable


[ =A0 =A00.000000] Xen: [mem 0x000000007f5ef000-0x000000007f6defff] re=
served
[ =A0 =A00.000000] Xen: [mem 0x000000007f6df000-0x00000000=
7f7defff] ACPI NVS
[ =A0 =A00.000000] Xen: [mem 0x000000007f7df00=
0-0x000000007f7fefff] ACPI data


[ =A0 =A00.000000] Xen: [mem 0x000000007f7ff000-0x000000007f7fffff] us=
able
[ =A0 =A00.000000] Xen: [mem 0x0000000080000000-0x000000008f=
ffffff] reserved
[ =A0 =A00.000000] Xen: [mem 0x00000000fed1c000-=
0x00000000fed1ffff] reserved


[ =A0 =A00.000000] Xen: [mem 0x00000000fee00000-0x00000000fee00fff] re=
served
[ =A0 =A00.000000] Xen: [mem 0x00000000ff800000-0x00000000=
ffffffff] reserved
[ =A0 =A00.000000] Xen: [mem 0x000000010000000=
0-0x000000017fffffff] usable


[ =A0 =A00.000000] NX (Execute Disable) protection: active
[=
 =A0 =A00.000000] DMI 2.5 present.
[ =A0 =A00.000000] DMI: IBM Sy=
stem x3650 M3 -[7945AC1]-/00D4062, BIOS -[D6E157AUS-1.15]- 06/13/2012
=

[ =A0 =A00.000000] e820: update [mem 0x00000000-0x0000ffff] usable =3D=
=3D> reserved


[ =A0 =A00.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[ =A0 =A00.000000] No AGP bridge found
[ =A0 =A00.000000] =
e820: last_pfn =3D 0x180000 max_arch_pfn =3D 0x400000000
[ =A0 =
=A00.000000] e820: last_pfn =3D 0x7f800 max_arch_pfn =3D 0x400000000


[ =A0 =A00.000000] initial memory mapped: [mem 0x00000000-0x02334fff]<=
/div>
[ =A0 =A00.000000] Base memory trampoline at [ffff880000099000] 9=
9000 size 24576
[ =A0 =A00.000000] init_memory_mapping: [mem 0x00=
000000-0x7f7fffff]


[ =A0 =A00.000000] =A0[mem 0x00000000-0x7f7fffff] page 4k
[ =
=A0 =A00.000000] kernel direct mapping tables up to 0x7f7fffff @ [mem 0x018=
31000-0x01c2ffff]
[ =A0 =A00.000000] xen: setting RW the range 1c=
14000 - 1c30000


[ =A0 =A00.000000] init_memory_mapping: [mem 0x100000000-0x17fffffff]<=
/div>
[ =A0 =A00.000000] =A0[mem 0x100000000-0x17fffffff] page 4k
=

[ =A0 =A00.000000] kernel direct mapping tables up to 0x17fffffff @ [m=
em 0x7e9e8000-0x7f5eefff]


[ =A0 =A00.000000] xen: setting RW the range 7edea000 - 7f5ef000
=

[ =A0 =A00.000000] RAMDISK: [mem 0x01c30000-0x02334fff]
[ =
=A0 =A00.000000] ACPI BIOS Bug: Error: A valid RSDP was not found (20120711=
/tbxfroot-219)


[ =A0 =A00.000000] NUMA turned off
[ =A0 =A00.000000] Faking=
 a node at [mem 0x0000000000000000-0x000000017fffffff]
[ =A0 =A00=
.000000] Initmem setup node 0 [mem 0x00000000-0x17fffffff]
[ =A0 =
=A00.000000] =A0 NODE_DATA [mem 0x175102000-0x175105fff]


[ =A0 =A00.000000] Zone ranges:
[ =A0 =A00.000000] =A0 DMA =
=A0 =A0 =A0[mem 0x00010000-0x00ffffff]
[ =A0 =A00.000000] =A0 DMA=
32 =A0 =A0[mem 0x01000000-0xffffffff]
[ =A0 =A00.000000] =A0 Norm=
al =A0 [mem 0x100000000-0x17fffffff]


[ =A0 =A00.000000] Movable zone start for each node
[ =A0 =
=A00.000000] Early memory node ranges
[ =A0 =A00.000000] =A0 node=
 =A0 0: [mem 0x00010000-0x0006bfff]
[ =A0 =A00.000000] =A0 node =
=A0 0: [mem 0x0006d000-0x0009efff]


[ =A0 =A00.000000] =A0 node =A0 0: [mem 0x00100000-0x7acb6fff]
[ =A0 =A00.000000] =A0 node =A0 0: [mem 0x7ccb8000-0x7d4effff]
[ =A0 =A00.000000] =A0 node =A0 0: [mem 0x7d51b000-0x7d53efff]
[=
 =A0 =A00.000000] =A0 node =A0 0: [mem 0x7d56a000-0x7d703fff]


[ =A0 =A00.000000] =A0 node =A0 0: [mem 0x7d7b4000-0x7f5eefff]
[ =A0 =A00.000000] =A0 node =A0 0: [mem 0x7f7ff000-0x7f7fffff]
[ =A0 =A00.000000] =A0 node =A0 0: [mem 0x100000000-0x17fffffff]
[ =A0 =A00.000000] On node 0 totalpages: 1037431


[ =A0 =A00.000000] =A0 DMA zone: 56 pages used for memmap
[ =
=A0 =A00.000000] =A0 DMA zone: 6 pages reserved
[ =A0 =A00.000000=
] =A0 DMA zone: 3920 pages, LIFO batch:0
[ =A0 =A00.000000] =A0 D=
MA32 zone: 14280 pages used for memmap


[ =A0 =A00.000000] =A0 DMA32 zone: 494881 pages, LIFO batch:31
[ =A0 =A00.000000] =A0 Normal zone: 7168 pages used for memmap
[ =A0 =A00.000000] =A0 Normal zone: 517120 pages, LIFO batch:31
=
[ =A0 =A00.000000] SFI: Simple Firmware Interface v0.81 http://simplefirmware.org


[ =A0 =A00.000000] smpboot: Allowing 1 CPUs, 0 hotplug CPUs
=
[ =A0 =A00.000000] nr_irqs_gsi: 16
[ =A0 =A00.000000] PM: Registe=
red nosave memory: 000000000006c000 - 000000000006d000
[ =A0 =A00=
.000000] PM: Registered nosave memory: 000000000009f000 - 00000000000a0000<=
/div>

[ =A0 =A00.000000] PM: Registered nosave memory: 00000000000a0000 - 00=
00000000100000
[ =A0 =A00.000000] PM: Registered nosave memory: 0=
00000007acb7000 - 000000007ccb8000
[ =A0 =A00.000000] PM: Registe=
red nosave memory: 000000007d4f0000 - 000000007d51b000


[ =A0 =A00.000000] PM: Registered nosave memory: 000000007d53f000 - 00=
0000007d56a000
[ =A0 =A00.000000] PM: Registered nosave memory: 0=
00000007d704000 - 000000007d7b4000
[ =A0 =A00.000000] PM: Registe=
red nosave memory: 000000007f5ef000 - 000000007f6df000


[ =A0 =A00.000000] PM: Registered nosave memory: 000000007f6df000 - 00=
0000007f7df000
[ =A0 =A00.000000] PM: Registered nosave memory: 0=
00000007f7df000 - 000000007f7ff000
[ =A0 =A00.000000] PM: Registe=
red nosave memory: 000000007f800000 - 0000000080000000


[ =A0 =A00.000000] PM: Registered nosave memory: 0000000080000000 - 00=
00000090000000
[ =A0 =A00.000000] PM: Registered nosave memory: 0=
000000090000000 - 00000000fed1c000
[ =A0 =A00.000000] PM: Registe=
red nosave memory: 00000000fed1c000 - 00000000fed20000


[ =A0 =A00.000000] PM: Registered nosave memory: 00000000fed20000 - 00=
000000fee00000
[ =A0 =A00.000000] PM: Registered nosave memory: 0=
0000000fee00000 - 00000000fee01000
[ =A0 =A00.000000] PM: Registe=
red nosave memory: 00000000fee01000 - 00000000ff800000


[ =A0 =A00.000000] PM: Registered nosave memory: 00000000ff800000 - 00=
00000100000000
[ =A0 =A00.000000] e820: [mem 0x90000000-0xfed1bff=
f] available for PCI devices
[ =A0 =A00.000000] Booting paravirtu=
alized kernel on Xen


[ =A0 =A00.000000] Xen version: 4.2.0 (preserve-AD)
[ =A0 =
=A00.000000] setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:1 nr_=
node_ids:1
[ =A0 =A00.000000] PERCPU: Embedded 28 pages/cpu @ffff=
880174e00000 s83840 r8192 d22656 u2097152


[ =A0 =A00.000000] pcpu-alloc: s83840 r8192 d22656 u2097152 alloc=3D1*=
2097152
[ =A0 =A00.000000] pcpu-alloc: [0] 0=A0
[ =A0 =
=A01.096975] Built 1 zonelists in Zone order, mobility grouping on. =A0Tota=
l pages: 1015921


[ =A0 =A01.096977] Policy zone: Normal
[ =A0 =A01.096979] Ke=
rnel command line: placeholder root=3D/dev/mapper/xen-fw_root ro
=
[ =A0 =A01.097016] PID hash table entries: 4096 (order: 3, 32768 bytes)
[ =A0 =A01.097021] __ex_table already sorted, skipping sort


[ =A0 =A01.121932] software IO TLB [mem 0x16c800000-0x1707fffff] (64MB=
) mapped at [ffff88016c800000-ffff8801707fffff]
[ =A0 =A01.138656=
] Memory: 3815116k/6291456k available (3573k kernel code, 2141732k absent, =
334608k reserved, 3147k data, 592k init)


[ =A0 =A01.138717] Hierarchical RCU implementation.
[ =A0 =
=A01.138718] 	RCU dyntick-idle grace-period acceleration is enabled.
[ =A0 =
=A01.138719] 	RCU restricting CPUs from NR_CPUS=3D512 to nr_cpu_ids=3D1.


[ =A0 =A01.138728] NR_IRQS:33024 nr_irqs:256 16
[ =A0 =A01.1=
47171] Console: colour VGA+ 80x25
[ =A0 =A01.154296] console [tty=
0] enabled
[ =A0 =A01.159002] allocated 16777216 bytes of page_cg=
roup

[ =A0 =A01.159079] please try 'cgroup_disable=3Dmemory' option if y=
ou don't want memory cgroups
[ =A0 =A01.159208] Xen: using vc=
puop timer interface
[ =A0 =A01.159214] installing Xen timer for =
CPU 0


[ =A0 =A01.159303] tsc: Detected 2400.126 MHz processor
[ =
=A0 =A01.159375] Calibrating delay loop (skipped), value calculated using t=
imer frequency.. 4800.25 BogoMIPS (lpj=3D9600504)
[ =A0 =A01.1595=
17] pid_max: default: 32768 minimum: 301


[ =A0 =A01.159607] Security Framework initialized
[ =A0 =A01=
.159680] AppArmor: AppArmor disabled by boot time parameter
[ =A0=
 =A01.160298] Dentry cache hash table entries: 524288 (order: 10, 4194304 b=
ytes)


[ =A0 =A01.161752] Inode-cache hash table entries: 262144 (order: 9, 2=
097152 bytes)
[ =A0 =A01.162415] Mount-cache hash table entries: =
256
[ =A0 =A01.162658] Initializing cgroup subsys cpuacct
[ =A0 =A01.162729] Initializing cgroup subsys memory


[ =A0 =A01.162806] Initializing cgroup subsys devices
[ =A0 =
=A01.162876] Initializing cgroup subsys freezer
[ =A0 =A01.162945=
] Initializing cgroup subsys net_cls
[ =A0 =A01.163014] Initializ=
ing cgroup subsys blkio


[ =A0 =A01.163082] Initializing cgroup subsys perf_event
[ =
=A0 =A01.163204] CPU: Physical Processor ID: 0
[ =A0 =A01.163277]=
 CPU: Processor Core ID: 0
[ =A0 =A01.163346] mce: CPU supports 2=
 MCE banks


[ =A0 =A01.163452] Last level iTLB entries: 4KB 512, 2MB 7, 4MB 7
[ =A0 =A01.163452] Last level dTLB entries: 4KB 512, 2MB 32, 4MB 32
[ =A0 =A01.163452] tlb_flushall_shift is 0x6
[ =A0 =A01.=
163602] SMP alternatives: switching to UP code


[ =A0 =A01.171342] Freeing SMP alternatives: 8k freed
[ =A0 =
=A01.171471] Performance Events: unsupported p6 CPU model 44 no PMU driver,=
 software events only.
[ =A0 =A01.171785] NMI watchdog: disabled =
(cpu0): hardware events not enabled


[ =A0 =A01.171876] Brought up 1 CPUs
[ =A0 =A01.172058] devt=
mpfs: initialized
[ =A0 =A01.174970] PM: Registering ACPI NVS reg=
ion [mem 0x0006c000-0x0006cfff] (4096 bytes)
[ =A0 =A01.175062] P=
M: Registering ACPI NVS region [mem 0x0009f000-0x0009ffff] (4096 bytes)

[ =A0 =A01.175153] PM: Registering ACPI NVS region [mem 0x7f6df000-0x7=
f7defff] (1048576 bytes)
[ =A0 =A01.175314] Grant tables using ve=
rsion 2 layout.
[ =A0 =A01.175394] Grant table initialized
<=
div>[ =A0 =A01.175514] dummy:=A0


[ =A0 =A01.175625] NET: Registered protocol family 16
[ =A0 =
=A01.175969] PCI: Using configuration type 1 for base access
[ =
=A0 =A01.176599] bio: create slab <bio-0> at 0
[ =A0 =A01.1=
76719] ACPI: Interpreter disabled.


[ =A0 =A01.176796] xen/balloon: Initialising balloon driver.
[ =A0 =A01.177620] xen-balloon: Initialising balloon driver.
[ =
=A0 =A01.177761] vgaarb: loaded
[ =A0 =A01.177860] PCI: Probing P=
CI hardware


[ =A0 =A01.177929] PCI: root bus 00: using default resources
[ =A0 =A01.177930] PCI: Probing PCI hardware (bus 00)
[ =A0 =A01=
.177954] PCI host bridge to bus 0000:00
[ =A0 =A01.178025] pci_bu=
s 0000:00: root bus resource [io =A00x0000-0xffff]


[ =A0 =A01.178098] pci_bus 0000:00: root bus resource [mem 0x00000000-=
0xffffffffff]
[ =A0 =A01.178173] pci_bus 0000:00: No busn resourc=
e found for root bus, will use [bus 00-ff]
[ =A0 =A01.178266] pci=
_bus 0000:00: busn_res: [bus 00-ff] is inserted under domain [bus 00-ff]

[ =A0 =A01.178287] pci 0000:00:00.0: [8086:3406] type 00 class 0x06000=
0
[ =A0 =A01.178389] pci 0000:00:00.0: PME# supported from D0 D3h=
ot D3cold
[ =A0 =A01.178425] pci 0000:00:01.0: [8086:3408] type 0=
1 class 0x060400


[ =A0 =A01.178532] pci 0000:00:01.0: PME# supported from D0 D3hot D3co=
ld
[ =A0 =A01.178571] pci 0000:00:02.0: [8086:3409] type 01 class=
 0x060400
[ =A0 =A01.178678] pci 0000:00:02.0: PME# supported fro=
m D0 D3hot D3cold


[ =A0 =A01.178716] pci 0000:00:03.0: [8086:340a] type 01 class 0x06040=
0
[ =A0 =A01.178824] pci 0000:00:03.0: PME# supported from D0 D3h=
ot D3cold
[ =A0 =A01.178865] pci 0000:00:05.0: [8086:340c] type 0=
1 class 0x060400


[ =A0 =A01.178973] pci 0000:00:05.0: PME# supported from D0 D3hot D3co=
ld
[ =A0 =A01.179013] pci 0000:00:07.0: [8086:340e] type 01 class=
 0x060400
[ =A0 =A01.179121] pci 0000:00:07.0: PME# supported fro=
m D0 D3hot D3cold


[ =A0 =A01.179161] pci 0000:00:09.0: [8086:3410] type 01 class 0x06040=
0
[ =A0 =A01.179269] pci 0000:00:09.0: PME# supported from D0 D3h=
ot D3cold
[ =A0 =A01.179309] pci 0000:00:10.0: [8086:3425] type 0=
0 class 0x080000


[ =A0 =A01.179434] pci 0000:00:10.1: [8086:3426] type 00 class 0x08000=
0
[ =A0 =A01.179543] pci 0000:00:11.0: [8086:3427] type 00 class =
0x080000
[ =A0 =A01.179668] pci 0000:00:11.1: [8086:3428] type 00=
 class 0x080000


[ =A0 =A01.179795] pci 0000:00:14.0: [8086:342e] type 00 class 0x08000=
0
[ =A0 =A01.179919] pci 0000:00:14.1: [8086:3422] type 00 class =
0x080000
[ =A0 =A01.180053] pci 0000:00:14.2: [8086:3423] type 00=
 class 0x080000


[ =A0 =A01.180172] pci 0000:00:14.3: [8086:3438] type 00 class 0x08000=
0
[ =A0 =A01.180273] pci 0000:00:15.0: [8086:342f] type 00 class =
0x080020
[ =A0 =A01.180387] pci 0000:00:16.0: [8086:3430] type 00=
 class 0x088000


[ =A0 =A01.180408] pci 0000:00:16.0: reg 10: [mem 0x97a00000-0x97a03ff=
f 64bit]
[ =A0 =A01.180540] pci 0000:00:16.1: [8086:3431] type 00=
 class 0x088000
[ =A0 =A01.180561] pci 0000:00:16.1: reg 10: [mem=
 0x97a04000-0x97a07fff 64bit]


[ =A0 =A01.180693] pci 0000:00:16.2: [8086:3432] type 00 class 0x08800=
0
[ =A0 =A01.180713] pci 0000:00:16.2: reg 10: [mem 0x97a08000-0x=
97a0bfff 64bit]
[ =A0 =A01.180845] pci 0000:00:16.3: [8086:3433] =
type 00 class 0x088000


[ =A0 =A01.180866] pci 0000:00:16.3: reg 10: [mem 0x97a0c000-0x97a0fff=
f 64bit]
[ =A0 =A01.180997] pci 0000:00:16.4: [8086:3429] type 00=
 class 0x088000
[ =A0 =A01.181018] pci 0000:00:16.4: reg 10: [mem=
 0x97a10000-0x97a13fff 64bit]


[ =A0 =A01.181150] pci 0000:00:16.5: [8086:342a] type 00 class 0x08800=
0
[ =A0 =A01.181170] pci 0000:00:16.5: reg 10: [mem 0x97a14000-0x=
97a17fff 64bit]
[ =A0 =A01.181302] pci 0000:00:16.6: [8086:342b] =
type 00 class 0x088000


[ =A0 =A01.181323] pci 0000:00:16.6: reg 10: [mem 0x97a18000-0x97a1bff=
f 64bit]
[ =A0 =A01.181455] pci 0000:00:16.7: [8086:342c] type 00=
 class 0x088000
[ =A0 =A01.181475] pci 0000:00:16.7: reg 10: [mem=
 0x97a1c000-0x97a1ffff 64bit]


[ =A0 =A01.181610] pci 0000:00:1a.0: [8086:3a37] type 00 class 0x0c030=
0
[ =A0 =A01.181681] pci 0000:00:1a.0: reg 20: [io =A00x20a0-0x20=
bf]
[ =A0 =A01.181766] pci 0000:00:1a.1: [8086:3a38] type 00 clas=
s 0x0c0300


[ =A0 =A01.181837] pci 0000:00:1a.1: reg 20: [io =A00x2080-0x209f]
[ =A0 =A01.181937] pci 0000:00:1a.7: [8086:3a3c] type 00 class 0x0c0=
320
[ =A0 =A01.181970] pci 0000:00:1a.7: reg 10: [mem 0x97a21000-=
0x97a213ff]


[ =A0 =A01.182116] pci 0000:00:1a.7: PME# supported from D0 D3hot D3co=
ld
[ =A0 =A01.182153] pci 0000:00:1c.0: [8086:3a40] type 01 class=
 0x060400
[ =A0 =A01.182274] pci 0000:00:1c.0: PME# supported fro=
m D0 D3hot D3cold


[ =A0 =A01.182316] pci 0000:00:1c.4: [8086:3a48] type 01 class 0x06040=
0
[ =A0 =A01.182435] pci 0000:00:1c.4: PME# supported from D0 D3h=
ot D3cold
[ =A0 =A01.182478] pci 0000:00:1d.0: [8086:3a34] type 0=
0 class 0x0c0300


[ =A0 =A01.182549] pci 0000:00:1d.0: reg 20: [io =A00x2060-0x207f]
[ =A0 =A01.182634] pci 0000:00:1d.1: [8086:3a35] type 00 class 0x0c0=
300
[ =A0 =A01.182705] pci 0000:00:1d.1: reg 20: [io =A00x2040-0x=
205f]

[ =A0 =A01.182790] pci 0000:00:1d.2: [8086:3a36] type 00 class 0x0c0300
[ =A0 =A01.182860] pci 0000:00:1d.2: reg 20: [io =A00x2020-0x203f]
[ =A0 =A01.182960] pci 0000:00:1d.7: [8086:3a3a] type 00 class 0x0=
c0320


[ =A0 =A01.182993] pci 0000:00:1d.7: reg 10: [mem 0x97a20000-0x97a203f=
f]
[ =A0 =A01.183138] pci 0000:00:1d.7: PME# supported from D0 D3=
hot D3cold
[ =A0 =A01.183173] pci 0000:00:1e.0: [8086:244e] type =
01 class 0x060401


[ =A0 =A01.183279] pci 0000:00:1f.0: [8086:3a18] type 00 class 0x06010=
0
[ =A0 =A01.183458] pci 0000:00:1f.2: [8086:3a20] type 00 class =
0x01018f
[ =A0 =A01.183484] pci 0000:00:1f.2: reg 10: [io =A00x21=
18-0x211f]


[ =A0 =A01.183497] pci 0000:00:1f.2: reg 14: [io =A00x212c-0x212f]
[ =A0 =A01.183510] pci 0000:00:1f.2: reg 18: [io =A00x2110-0x2117]
[ =A0 =A01.183522] pci 0000:00:1f.2: reg 1c: [io =A00x2128-0x212b]=

[ =A0 =A01.183535] pci 0000:00:1f.2: reg 20: [io =A00x20f0-0x20f=
f]


[ =A0 =A01.183548] pci 0000:00:1f.2: reg 24: [io =A00x20e0-0x20ef]
[ =A0 =A01.183629] pci 0000:00:1f.3: [8086:3a30] type 00 class 0x0c0=
500
[ =A0 =A01.183653] pci 0000:00:1f.3: reg 10: [mem 0x97a22000-=
0x97a220ff 64bit]


[ =A0 =A01.183689] pci 0000:00:1f.3: reg 20: [io =A00x2000-0x201f]
[ =A0 =A01.183746] pci 0000:00:1f.5: [8086:3a26] type 00 class 0x010=
185
[ =A0 =A01.183772] pci 0000:00:1f.5: reg 10: [io =A00x2108-0x=
210f]

[ =A0 =A01.183784] pci 0000:00:1f.5: reg 14: [io =A00x2124-0x2127]
[ =A0 =A01.183797] pci 0000:00:1f.5: reg 18: [io =A00x2100-0x2107]
<=
div>[ =A0 =A01.183816] pci 0000:00:1f.5: reg 1c: [io =A00x2120-0x2123]
[ =A0 =A01.183829] pci 0000:00:1f.5: reg 20: [io =A00x20d0-0x20df]

[ =A0 =A01.183841] pci 0000:00:1f.5: reg 24: [io =A00x20c0-0x20cf]
[ =A0 =A01.183985] pci_bus 0000:0b: busn_res: [bus 0b-0f] is inserte=
d under [bus 00-ff]
[ =A0 =A01.184016] pci 0000:0b:00.0: [14e4:16=
39] type 00 class 0x020000


[ =A0 =A01.184040] pci 0000:0b:00.0: reg 10: [mem 0x92000000-0x93fffff=
f 64bit]
[ =A0 =A01.184181] pci 0000:0b:00.0: PME# supported from=
 D0 D3hot D3cold
[ =A0 =A01.184224] pci 0000:0b:00.1: [14e4:1639]=
 type 00 class 0x020000


[ =A0 =A01.184248] pci 0000:0b:00.1: reg 10: [mem 0x94000000-0x95fffff=
f 64bit]
[ =A0 =A01.184390] pci 0000:0b:00.1: PME# supported from=
 D0 D3hot D3cold
[ =A0 =A01.191939] pci 0000:00:01.0: PCI bridge =
to [bus 0b-0f]


[ =A0 =A01.192017] pci 0000:00:01.0: =A0 bridge window [mem 0x92000000=
-0x95ffffff]
[ =A0 =A01.192089] pci_bus 0000:10: busn_res: [bus 1=
0-14] is inserted under [bus 00-ff]
[ =A0 =A01.192093] pci 0000:0=
0:02.0: PCI bridge to [bus 10-14]


[ =A0 =A01.192240] pci_bus 0000:15: busn_res: [bus 15-19] is inserted =
under [bus 00-ff]
[ =A0 =A01.192244] pci 0000:00:03.0: PCI bridge=
 to [bus 15-19]
[ =A0 =A01.192389] pci_bus 0000:1a: busn_res: [bu=
s 1a-1e] is inserted under [bus 00-ff]


[ =A0 =A01.192392] pci 0000:00:05.0: PCI bridge to [bus 1a-1e]
[ =A0 =A01.192539] pci_bus 0000:1f: busn_res: [bus 1f-23] is inserted un=
der [bus 00-ff]
[ =A0 =A01.192542] pci 0000:00:07.0: PCI bridge t=
o [bus 1f-23]


[ =A0 =A01.192688] pci_bus 0000:24: busn_res: [bus 24-28] is inserted =
under [bus 00-ff]
[ =A0 =A01.192691] pci 0000:00:09.0: PCI bridge=
 to [bus 24-28]
[ =A0 =A01.192838] pci_bus 0000:01: busn_res: [bu=
s 01-05] is inserted under [bus 00-ff]


[ =A0 =A01.192863] pci 0000:01:00.0: [1000:0073] type 00 class 0x01040=
0
[ =A0 =A01.192884] pci 0000:01:00.0: reg 10: [io =A00x1000-0x10=
ff]
[ =A0 =A01.192908] pci 0000:01:00.0: reg 14: [mem 0x97940000-=
0x97943fff 64bit]


[ =A0 =A01.192932] pci 0000:01:00.0: reg 1c: [mem 0x97900000-0x9793fff=
f 64bit]
[ =A0 =A01.192962] pci 0000:01:00.0: reg 30: [mem 0xfffe=
0000-0xffffffff pref]
[ =A0 =A01.193060] pci 0000:01:00.0: suppor=
ts D1 D2


[ =A0 =A01.200042] pci 0000:00:1c.0: PCI bridge to [bus 01-05]
[ =A0 =A01.200117] pci 0000:00:1c.0: =A0 bridge window [io =A00x1000-0x1=
fff]
[ =A0 =A01.200123] pci 0000:00:1c.0: =A0 bridge window [mem =
0x97900000-0x979fffff]


[ =A0 =A01.200196] pci_bus 0000:06: busn_res: [bus 06-0a] is inserted =
under [bus 00-ff]
[ =A0 =A01.200228] pci 0000:06:00.0: [101b:0452=
] type 01 class 0x060400
[ =A0 =A01.200394] pci 0000:06:00.0: PME=
# supported from D0 D3hot D3cold


[ =A0 =A01.208144] pci 0000:00:1c.4: PCI bridge to [bus 06-0a]
[ =A0 =A01.208223] pci 0000:00:1c.4: =A0 bridge window [mem 0x97000000-0=
x978fffff]
[ =A0 =A01.208231] pci 0000:00:1c.4: =A0 bridge window=
 [mem 0x96000000-0x96ffffff 64bit pref]


[ =A0 =A01.208330] pci_bus 0000:07: busn_res: [bus 07] is inserted und=
er [bus 06-0a]
[ =A0 =A01.208353] pci 0000:07:00.0: [102b:0530] t=
ype 00 class 0x030000
[ =A0 =A01.208388] pci 0000:07:00.0: reg 10=
: [mem 0x96000000-0x96ffffff pref]


[ =A0 =A01.208407] pci 0000:07:00.0: reg 14: [mem 0x97800000-0x97803ff=
f]
[ =A0 =A01.208427] pci 0000:07:00.0: reg 18: [mem 0x97000000-0=
x977fffff]
[ =A0 =A01.208633] pci 0000:06:00.0: PCI bridge to [bu=
s 07]


[ =A0 =A01.208713] pci 0000:06:00.0: =A0 bridge window [mem 0x97000000=
-0x978fffff]
[ =A0 =A01.208720] pci 0000:06:00.0: =A0 bridge wind=
ow [mem 0x96000000-0x96ffffff pref]
[ =A0 =A01.208768] pci_bus 00=
00:29: busn_res: [bus 29-2d] is inserted under [bus 00-ff]


[ =A0 =A01.208829] pci 0000:00:1e.0: PCI bridge to [bus 29-2d] (subtra=
ctive decode)
[ =A0 =A01.208917] pci 0000:00:1e.0: =A0 bridge win=
dow [io =A00x0000-0xffff] (subtractive decode)
[ =A0 =A01.208919]=
 pci 0000:00:1e.0: =A0 bridge window [mem 0x00000000-0xffffffffff] (subtrac=
tive decode)


[ =A0 =A01.208978] pci_bus 0000:00: busn_res: [bus 00-ff] end is updat=
ed to 2d
[ =A0 =A01.210287] vgaarb: device added: PCI:0000:07:00.=
0,decodes=3Dio+mem,owns=3Dio+mem,locks=3Dnone
[ =A0 =A01.210898] =
PCI: pci_cache_line_size set to 64 bytes


[ =A0 =A01.211078] e820: reserve RAM buffer [mem 0x0006c000-0x0006ffff=
]
[ =A0 =A01.211080] e820: reserve RAM buffer [mem 0x0009f000-0x0=
009ffff]
[ =A0 =A01.211081] e820: reserve RAM buffer [mem 0x7acb7=
000-0x7bffffff]


[ =A0 =A01.211082] e820: reserve RAM buffer [mem 0x7d4f0000-0x7fffffff=
]
[ =A0 =A01.211086] e820: reserve RAM buffer [mem 0x7d53f000-0x7=
fffffff]
[ =A0 =A01.211088] e820: reserve RAM buffer [mem 0x7d704=
000-0x7fffffff]


[ =A0 =A01.211091] e820: reserve RAM buffer [mem 0x7f5ef000-0x7fffffff=
]
[ =A0 =A01.211093] e820: reserve RAM buffer [mem 0x7f800000-0x7=
fffffff]
[ =A0 =A01.211210] Switching to clocksource xen
[ =A0 =A01.212720] pnp: PnP ACPI: disabled


[ =A0 =A01.214391] pci 0000:01:00.0: no compatible bridge window for [=
mem 0xfffe0000-0xffffffff pref]
[ =A0 =A01.214569] pci 0000:00:1c=
.0: bridge window [mem 0x00100000-0x001fffff pref] to [bus 01-05] add_size =
200000


[ =A0 =A01.214613] pci 0000:00:1c.0: res[15]=3D[mem 0x00100000-0x001ff=
fff pref] get_res_add_size add_size 200000
[ =A0 =A01.214617] pci=
 0000:00:1c.0: BAR 15: assigned [mem 0x90000000-0x902fffff pref]
=
[ =A0 =A01.214708] pci 0000:00:01.0: PCI bridge to [bus 0b-0f]


[ =A0 =A01.214783] pci 0000:00:01.0: =A0 bridge window [mem 0x92000000=
-0x95ffffff]
[ =A0 =A01.214865] pci 0000:00:02.0: PCI bridge to [=
bus 10-14]
[ =A0 =A01.214948] pci 0000:00:03.0: PCI bridge to [bu=
s 15-19]


[ =A0 =A01.215032] pci 0000:00:05.0: PCI bridge to [bus 1a-1e]
[ =A0 =A01.215114] pci 0000:00:07.0: PCI bridge to [bus 1f-23]
[ =A0 =A01.215198] pci 0000:00:09.0: PCI bridge to [bus 24-28]
[=
 =A0 =A01.215282] pci 0000:01:00.0: BAR 6: assigned [mem 0x90000000-0x9001f=
fff pref]


[ =A0 =A01.215383] pci 0000:00:1c.0: PCI bridge to [bus 01-05]
[ =A0 =A01.215456] pci 0000:00:1c.0: =A0 bridge window [io =A00x1000-0x1=
fff]
[ =A0 =A01.215532] pci 0000:00:1c.0: =A0 bridge window [mem =
0x97900000-0x979fffff]


[ =A0 =A01.215609] pci 0000:00:1c.0: =A0 bridge window [mem 0x90000000=
-0x902fffff pref]
[ =A0 =A01.215705] pci 0000:06:00.0: PCI bridge=
 to [bus 07]
[ =A0 =A01.215782] pci 0000:06:00.0: =A0 bridge wind=
ow [mem 0x97000000-0x978fffff]


[ =A0 =A01.215860] pci 0000:06:00.0: =A0 bridge window [mem 0x96000000=
-0x96ffffff pref]
[ =A0 =A01.223235] pci 0000:00:1c.4: PCI bridge=
 to [bus 06-0a]
[ =A0 =A01.223310] pci 0000:00:1c.4: =A0 bridge w=
indow [mem 0x97000000-0x978fffff]


[ =A0 =A01.223391] pci 0000:00:1c.4: =A0 bridge window [mem 0x96000000=
-0x96ffffff 64bit pref]
[ =A0 =A01.223489] pci 0000:00:1e.0: PCI =
bridge to [bus 29-2d]
[ =A0 =A01.223580] pci 0000:00:01.0: can=
9;t find IRQ for PCI INT A; please try using pci=3Dbiosirq


[ =A0 =A01.223680] pci 0000:00:02.0: can't find IRQ for PCI INT A;=
 please try using pci=3Dbiosirq
[ =A0 =A01.223780] pci 0000:00:03=
.0: can't find IRQ for PCI INT A; please try using pci=3Dbiosirq
<=
div>[ =A0 =A01.223880] pci 0000:00:05.0: can't find IRQ for PCI INT A; =
please try using pci=3Dbiosirq


[ =A0 =A01.223981] pci 0000:00:07.0: can't find IRQ for PCI INT A;=
 please try using pci=3Dbiosirq
[ =A0 =A01.224081] pci 0000:00:09=
.0: can't find IRQ for PCI INT A; please try using pci=3Dbiosirq
<=
div>[ =A0 =A01.224183] pci 0000:00:1c.0: can't find IRQ for PCI INT A; =
please try using pci=3Dbiosirq


[ =A0 =A01.224283] pci 0000:00:1c.4: can't find IRQ for PCI INT A;=
 please try using pci=3Dbiosirq
[ =A0 =A01.224385] pci 0000:06:00=
.0: can't find IRQ for PCI INT A; please try using pci=3Dbiosirq
<=
div>[ =A0 =A01.224487] pci 0000:00:1e.0: setting latency timer to 64


[ =A0 =A01.224492] pci_bus 0000:00: resource 4 [io =A00x0000-0xffff]
[ =A0 =A01.224494] pci_bus 0000:00: resource 5 [mem 0x00000000-0xf=
fffffffff]
[ =A0 =A01.224496] pci_bus 0000:0b: resource 1 [mem 0x=
92000000-0x95ffffff]


[ =A0 =A01.224498] pci_bus 0000:01: resource 0 [io =A00x1000-0x1fff]
[ =A0 =A01.224500] pci_bus 0000:01: resource 1 [mem 0x97900000-0x9=
79fffff]
[ =A0 =A01.224502] pci_bus 0000:01: resource 2 [mem 0x90=
000000-0x902fffff pref]


[ =A0 =A01.224504] pci_bus 0000:06: resource 1 [mem 0x97000000-0x978ff=
fff]
[ =A0 =A01.224507] pci_bus 0000:06: resource 2 [mem 0x960000=
00-0x96ffffff 64bit pref]
[ =A0 =A01.224510] pci_bus 0000:07: res=
ource 1 [mem 0x97000000-0x978fffff]


[ =A0 =A01.224512] pci_bus 0000:07: resource 2 [mem 0x96000000-0x96fff=
fff pref]
[ =A0 =A01.224514] pci_bus 0000:29: resource 4 [io =A00=
x0000-0xffff]
[ =A0 =A01.224516] pci_bus 0000:29: resource 5 [mem=
 0x00000000-0xffffffffff]


[ =A0 =A01.224538] NET: Registered protocol family 2
[ =A0 =
=A01.225637] TCP established hash table entries: 524288 (order: 11, 8388608=
 bytes)
[ =A0 =A01.228185] TCP bind hash table entries: 65536 (or=
der: 8, 1048576 bytes)


[ =A0 =A01.228521] TCP: Hash tables configured (established 524288 bin=
d 65536)
[ =A0 =A01.228613] TCP: reno registered
[ =A0 =
=A01.228689] UDP hash table entries: 2048 (order: 4, 65536 bytes)
[ =A0 =A01.228785] UDP-Lite hash table entries: 2048 (order: 4, 65536 byte=
s)


[ =A0 =A01.228922] NET: Registered protocol family 1
[ =A0 =
=A01.229073] pci 0000:00:1a.0: can't find IRQ for PCI INT A; please try=
 using pci=3Dbiosirq
[ =A0 =A01.229201] pci 0000:00:1a.1: can'=
;t find IRQ for PCI INT B; please try using pci=3Dbiosirq


[ =A0 =A01.229325] pci 0000:00:1a.7: can't find IRQ for PCI INT C;=
 please try using pci=3Dbiosirq
[ =A0 =A01.229466] pci 0000:00:1d=
.0: can't find IRQ for PCI INT A; please try using pci=3Dbiosirq
<=
div>[ =A0 =A01.229588] pci 0000:00:1d.1: can't find IRQ for PCI INT B; =
please try using pci=3Dbiosirq


[ =A0 =A01.229708] pci 0000:00:1d.2: can't find IRQ for PCI INT C;=
 please try using pci=3Dbiosirq
[ =A0 =A01.229836] pci 0000:00:1d=
.7: can't find IRQ for PCI INT A; please try using pci=3Dbiosirq
<=
div>[ =A0 =A01.229986] pci 0000:07:00.0: Boot video device


[ =A0 =A01.229991] PCI: CLS 64 bytes, default 64
[ =A0 =A01.=
230040] Unpacking initramfs...
[ =A0 =A01.236939] Freeing initrd =
memory: 7188k freed
[ =A0 =A01.238401] platform rtc_cmos: registe=
red platform RTC device (no PNP device found)


[ =A0 =A01.238695] audit: initializing netlink socket (disabled)
=

[ =A0 =A01.238779] type=3D2000 audit(1349925915.231:1): initialized
[ =A0 =A01.253042] HugeTLB registered 2 MB page size, pre-allocated=
 0 pages


[ =A0 =A01.253247] VFS: Disk quotas dquot_6.5.2
[ =A0 =A01.2=
53330] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
=
[ =A0 =A01.253465] msgmni has been set to 7465
[ =A0 =A01.253646]=
 alg: No test for stdrng (krng)


[ =A0 =A01.253730] Block layer SCSI generic (bsg) driver version 0.4 l=
oaded (major 252)
[ =A0 =A01.253820] io scheduler noop registered=

[ =A0 =A01.253888] io scheduler deadline registered
[ =
=A0 =A01.253960] io scheduler cfq registered (default)


[ =A0 =A01.254124] pcieport 0000:00:01.0: device [8086:3408] has inval=
id IRQ; check vendor BIOS
[ =A0 =A01.254277] pcieport 0000:00:02.=
0: device [8086:3409] has invalid IRQ; check vendor BIOS
[ =A0 =
=A01.254425] pcieport 0000:00:03.0: device [8086:340a] has invalid IRQ; che=
ck vendor BIOS


[ =A0 =A01.254573] pcieport 0000:00:05.0: device [8086:340c] has inval=
id IRQ; check vendor BIOS
[ =A0 =A01.254723] pcieport 0000:00:07.=
0: device [8086:340e] has invalid IRQ; check vendor BIOS
[ =A0 =
=A01.254870] pcieport 0000:00:09.0: device [8086:3410] has invalid IRQ; che=
ck vendor BIOS


[ =A0 =A01.255019] pcieport 0000:00:1c.0: device [8086:3a40] has inval=
id IRQ; check vendor BIOS
[ =A0 =A01.255170] pcieport 0000:00:1c.=
4: device [8086:3a48] has invalid IRQ; check vendor BIOS
[ =A0 =
=A01.255389] ioapic: probe of 0000:00:15.0 failed with error -22


[ =A0 =A01.255467] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[ =A0 =A01.255554] pciehp: PCI Express Hot Plug Controller Driver ve=
rsion: 0.4
[ =A0 =A01.255627] acpiphp: ACPI Hot Plug PCI Controll=
er Driver version: 0.5


[ =A0 =A01.255752] intel_idle: does not run on family 6 model 44
=

[ =A0 =A01.255833] Event-channel device installed.
[ =A0 =A0=
1.255989] xen-pciback: backend is vpci
[ =A0 =A01.256298] Serial:=
 8250/16550 driver, 4 ports, IRQ sharing enabled


[ =A0 =A01.277599] serial8250: ttyS0 at I/O 0x3f8 (irq =3D 4) is a 165=
50A
[ =A0 =A01.298917] serial8250: ttyS1 at I/O 0x2f8 (irq =3D 3)=
 is a 16550A
[ =A0 =A01.299221] Linux agpgart interface v0.103
[ =A0 =A01.299387] i8042: PNP: No PS/2 controller found. Probing po=
rts directly.


[ =A0 =A01.551430] serio: i8042 KBD port at 0x60,0x64 irq 1
=
[ =A0 =A01.551580] mousedev: PS/2 mouse device common for all mice
[ =A0 =A01.551800] rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rt=
c0


[ =A0 =A01.551897] rtc0: alarms up to one day, 114 bytes nvram
[ =A0 =A01.551972] EFI Variables Facility v0.08 2004-May-17
[ =
=A0 =A01.552053] drop_monitor: Initializing network drop monitor service

[ =A0 =A01.552197] TCP: cubic registered
[ =A0 =A01.552276] NET: =
Registered protocol family 10
[ =A0 =A01.552496] mip6: Mobile IPv=
6
[ =A0 =A01.552564] NET: Registered protocol family 17
[ =A0 =A01.552641] Key type dns_resolver registered


[ =A0 =A01.552859] PM: Hibernation image not present or could not be l=
oaded.
[ =A0 =A01.552868] registered taskstats version 1
[ =A0 =A01.553635] rtc_cmos rtc_cmos: setting system clock to 2012-10-11 =
03:25:15 UTC (1349925915)


[ =A0 =A01.553954] Freeing unused kernel memory: 592k freed
=
[ =A0 =A01.554130] Write protecting the kernel read-only data: 6144k
<=
div>[ =A0 =A01.555798] Freeing unused kernel memory: 512k freed
[=
 =A0 =A01.556107] Freeing unused kernel memory: 620k freed


[ =A0 =A01.583588] udevd[50]: starting version 175
[ =A0 =A0=
1.657119] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[ =A0 =A01.663281] SCSI subsystem initialized
[ =A0 =A01.68=
1024] megasas: 00.00.06.15-rc1 Mon. Mar. 19 17:00:00 PDT 2012


[ =A0 =A01.681111] megasas: 0x1000:0x0073:0x1014:0x03b1: bus 1:slot 0:=
func 0
[ =A0 =A01.681241] megaraid_sas 0000:01:00.0: can't fi=
nd IRQ for PCI INT A; please try using pci=3Dbiosirq
[ =A0 =A01.6=
87892] megasas: FW now in Ready state


[ =A0 =A01.735350] megasas_init_mfi: fw_support_ieee=3D67108864
<=
div>[ =A0 =A01.735407] megasas: INIT adapter done
[ =A0 =A01.8073=
65] scsi0 : LSI SAS based MegaRAID driver
[ =A0 =A01.808799] scsi=
 0:0:8:0: Direct-Access =A0 =A0 IBM-ESXS ST9146803SS =A0 =A0 =A0B53C PQ: 0 =
ANSI: 5


[ =A0 =A01.811249] scsi 0:0:9:0: Direct-Access =A0 =A0 ATA =A0 =A0 =A0=
ST9500620NS =A0 =A0 =A0BE24 PQ: 0 ANSI: 5
[ =A0 =A01.812739] scsi=
 0:0:10:0: Direct-Access =A0 =A0 ATA =A0 =A0 =A0ST9500620NS =A0 =A0 =A0BE24=
 PQ: 0 ANSI: 5
[ =A0 =A01.824208] scsi 0:2:0:0: Direct-Access =A0=
 =A0 IBM =A0 =A0 =A0ServeRAID M1015 =A02.12 PQ: 0 ANSI: 5


[ =A0 =A01.839755] sd 0:2:0:0: [sdb] 1949216768 512-byte logical block=
s: (997 GB/929 GiB)
[ =A0 =A01.840060] sd 0:2:0:0: [sdb] Write Pr=
otect is off
[ =A0 =A01.840141] sd 0:2:0:0: [sdb] Mode Sense: 1f =
00 10 08


[ =A0 =A01.840153] sd 0:0:8:0: [sda] 286748000 512-byte logical blocks=
: (146 GB/136 GiB)
[ =A0 =A01.840302] sd 0:2:0:0: [sdb] Write cac=
he: disabled, read cache: disabled, supports DPO and FUA
[ =A0 =
=A01.842564] sd 0:0:8:0: [sda] Write Protect is off


[ =A0 =A01.842637] sd 0:0:8:0: [sda] Mode Sense: c3 00 10 08
[ =A0 =A01.843418] =A0sdb: sdb1
[ =A0 =A01.843898] sd 0:0:8:0: [=
sda] Write cache: disabled, read cache: enabled, supports DPO and FUA
=

[ =A0 =A01.844117] sd 0:2:0:0: [sdb] Attached SCSI disk


[ =A0 =A01.866028] =A0sda: sda1 sda2 sda3 sda4
[ =A0 =A01.87=
0498] sd 0:0:8:0: [sda] Attached SCSI disk
[ =A0 =A02.053157] dev=
ice-mapper: uevent: version 1.0.3
[ =A0 =A02.053610] device-mappe=
r: ioctl: 4.23.0-ioctl (2012-07-25) initialised: dm-devel@redhat.com


[ =A0 =A02.214131] EXT4-fs (dm-0): mounted filesystem with ordered dat=
a mode. Opts: (null)
[ =A0 =A03.162111] udevd[298]: starting vers=
ion 175
[ =A0 =A03.419449] bnx2: Broadcom NetXtreme II Gigabit Et=
hernet Driver bnx2 v2.2.3 (June 27, 2012)


[ =A0 =A03.419565] bnx2 0000:0b:00.0: can't find IRQ for PCI INT A=
; please try using pci=3Dbiosirq
[ =A0 =A03.420241] bnx2 0000:0b:=
00.0: eth0: Broadcom NetXtreme II BCM5709 1000Base-T (C0) PCI Express found=
 at mem 92000000, IRQ 0, node addr 34:40:b5:ab:e5:b4


[ =A0 =A03.421062] bnx2 0000:0b:00.1: can't find IRQ for PCI INT B=
; please try using pci=3Dbiosirq
[ =A0 =A03.421705] bnx2 0000:0b:=
00.1: eth1: Broadcom NetXtreme II BCM5709 1000Base-T (C0) PCI Express found=
 at mem 94000000, IRQ 0, node addr 34:40:b5:ab:e5:b6


[ =A0 =A03.428805] dca service started, version 1.12.1
[ =A0=
 =A03.467169] EDAC MC: Ver: 3.0.0
[ =A0 =A03.473824] ioatdma: Int=
el(R) QuickData Technology Driver 4.00
[ =A0 =A03.473918] ioatdma=
 0000:00:16.0: enabling device (0000 -> 0002)


[ =A0 =A03.473996] ioatdma 0000:00:16.0: can't find IRQ for PCI IN=
T A; please try using pci=3Dbiosirq
[ =A0 =A03.474116] ioatdma 00=
00:00:16.0: channel error register unreachable
[ =A0 =A03.474191]=
 ioatdma 0000:00:16.0: channel enumeration error


[ =A0 =A03.505302] microcode: CPU0 sig=3D0x206c2, pf=3D0x1, revision=
=3D0x15
[ =A0 =A03.505995] ioatdma 0000:00:16.0: Intel(R) I/OAT D=
MA Engine init failed
[ =A0 =A03.506096] ioatdma 0000:00:16.1: en=
abling device (0000 -> 0002)


[ =A0 =A03.506173] ioatdma 0000:00:16.1: can't find IRQ for PCI IN=
T B; please try using pci=3Dbiosirq
[ =A0 =A03.506296] ioatdma 00=
00:00:16.1: channel error register unreachable
[ =A0 =A03.506369]=
 ioatdma 0000:00:16.1: channel enumeration error


[ =A0 =A03.506441] ioatdma 0000:00:16.1: Intel(R) I/OAT DMA Engine ini=
t failed
[ =A0 =A03.506532] ioatdma 0000:00:16.2: enabling device=
 (0000 -> 0002)
[ =A0 =A03.506608] ioatdma 0000:00:16.2: can&#=
39;t find IRQ for PCI INT C; please try using pci=3Dbiosirq


[ =A0 =A03.506722] ioatdma 0000:00:16.2: channel error register unreac=
hable
[ =A0 =A03.506795] ioatdma 0000:00:16.2: channel enumeratio=
n error
[ =A0 =A03.506867] ioatdma 0000:00:16.2: Intel(R) I/OAT D=
MA Engine init failed


[ =A0 =A03.506957] ioatdma 0000:00:16.3: enabling device (0000 -> 0=
002)
[ =A0 =A03.507034] ioatdma 0000:00:16.3: can't find IRQ =
for PCI INT D; please try using pci=3Dbiosirq
[ =A0 =A03.507147] =
ioatdma 0000:00:16.3: channel error register unreachable


[ =A0 =A03.507222] ioatdma 0000:00:16.3: channel enumeration error
[ =A0 =A03.507294] ioatdma 0000:00:16.3: Intel(R) I/OAT DMA Engine i=
nit failed
[ =A0 =A03.507398] ioatdma 0000:00:16.4: enabling devi=
ce (0000 -> 0002)


[ =A0 =A03.507476] ioatdma 0000:00:16.4: can't find IRQ for PCI IN=
T A; please try using pci=3Dbiosirq
[ =A0 =A03.507590] ioatdma 00=
00:00:16.4: channel error register unreachable
[ =A0 =A03.507663]=
 ioatdma 0000:00:16.4: channel enumeration error


[ =A0 =A03.507735] ioatdma 0000:00:16.4: Intel(R) I/OAT DMA Engine ini=
t failed
[ =A0 =A03.507826] ioatdma 0000:00:16.5: enabling device=
 (0000 -> 0002)
[ =A0 =A03.507903] ioatdma 0000:00:16.5: can&#=
39;t find IRQ for PCI INT B; please try using pci=3Dbiosirq


[ =A0 =A03.508016] ioatdma 0000:00:16.5: channel error register unreac=
hable
[ =A0 =A03.508090] ioatdma 0000:00:16.5: channel enumeratio=
n error
[ =A0 =A03.508162] ioatdma 0000:00:16.5: Intel(R) I/OAT D=
MA Engine init failed


[ =A0 =A03.508255] ioatdma 0000:00:16.6: enabling device (0000 -> 0=
002)
[ =A0 =A03.508337] ioatdma 0000:00:16.6: can't find IRQ =
for PCI INT C; please try using pci=3Dbiosirq
[ =A0 =A03.508454] =
ioatdma 0000:00:16.6: channel error register unreachable


[ =A0 =A03.508529] ioatdma 0000:00:16.6: channel enumeration error
[ =A0 =A03.508601] ioatdma 0000:00:16.6: Intel(R) I/OAT DMA Engine i=
nit failed
[ =A0 =A03.508692] ioatdma 0000:00:16.7: enabling devi=
ce (0000 -> 0002)


[ =A0 =A03.508769] ioatdma 0000:00:16.7: can't find IRQ for PCI IN=
T D; please try using pci=3Dbiosirq
[ =A0 =A03.508885] ioatdma 00=
00:00:16.7: channel error register unreachable
[ =A0 =A03.508958]=
 ioatdma 0000:00:16.7: channel enumeration error


[ =A0 =A03.509030] ioatdma 0000:00:16.7: Intel(R) I/OAT DMA Engine ini=
t failed
[ =A0 =A03.571248] usbcore: registered new interface dri=
ver usbfs
[ =A0 =A03.571330] usbcore: registered new interface dr=
iver hub


[ =A0 =A03.585483] ACPI Exception: AE_BAD_PARAMETER, Thread 1786484928=
 could not acquire Mutex [0x1] (20120711/utmutex-276)
[ =A0 =A03.=
585675] ACPI Exception: AE_BAD_PARAMETER, Thread 1786484928 could not acqui=
re Mutex [0x1] (20120711/utmutex-276)


[ =A0 =A03.590919] usbcore: registered new device driver usb
[ =A0 =A03.603433] input: PC Speaker as /devices/platform/pcspkr/input/inp=
ut0
[ =A0 =A03.604762] libata version 3.00 loaded.
[ =
=A0 =A03.607430] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI=
) Driver


[ =A0 =A03.607535] ehci_hcd 0000:00:1a.7: can't find IRQ for PCI I=
NT C; please try using pci=3Dbiosirq
[ =A0 =A03.607629] ehci_hcd =
0000:00:1a.7: Found HC with no IRQ. =A0Check BIOS/PCI 0000:00:1a.7 setup!

[ =A0 =A03.607723] ehci_hcd 0000:00:1a.7: init 0000:00:1a.7 fail, -19
=

[ =A0 =A03.607808] ehci_hcd 0000:00:1d.7: can't find IRQ for PCI I=
NT A; please try using pci=3Dbiosirq
[ =A0 =A03.607900] ehci_hcd =
0000:00:1d.7: Found HC with no IRQ. =A0Check BIOS/PCI 0000:00:1d.7 setup!

[ =A0 =A03.607994] ehci_hcd 0000:00:1d.7: init 0000:00:1d.7 fail, -19<=
/div>
[ =A0 =A03.623701] i801_smbus 0000:00:1f.3: enabling device (0140=
 -> 0143)
[ =A0 =A03.623781] i801_smbus 0000:00:1f.3: can'=
t find IRQ for PCI INT B; please try using pci=3Dbiosirq


[ =A0 =A03.623874] ACPI Exception: AE_BAD_PARAMETER, Thread 1775910976=
 could not acquire Mutex [0x1] (20120711/utmutex-276)
[ =A0 =A03.=
624093] i801_smbus 0000:00:1f.3: SMBus using PCI Interrupt
[ =A0 =
=A03.676083] ata_piix 0000:00:1f.2: version 2.13


[ =A0 =A03.676095] ata_piix 0000:00:1f.2: can't find IRQ for PCI I=
NT A; please try using pci=3Dbiosirq
[ =A0 =A03.676193] ata_piix =
0000:00:1f.2: MAP [
[ =A0 =A03.676260] =A0P0 P2 P1 P3 ]
[ =A0 =A03.676539] ata_piix 0000:00:1f.2: setting latency timer to 64

[ =A0 =A03.677344] scsi1 : ata_piix
[ =A0 =A03.677732] scsi2=
 : ata_piix
[ =A0 =A03.677862] ata1: SATA max UDMA/133 cmd 0x2118=
 ctl 0x212c bmdma 0x20f0
[ =A0 =A03.677954] ata2: SATA max UDMA/1=
33 cmd 0x2110 ctl 0x2128 bmdma 0x20f8


[ =A0 =A03.678154] gpio_ich: GPIO from 195 to 255 on gpio_ich
[ =A0 =A03.678606] ata_piix 0000:00:1f.5: can't find IRQ for PCI INT =
C; please try using pci=3Dbiosirq
[ =A0 =A03.678703] ata_piix 000=
0:00:1f.5: MAP [


[ =A0 =A03.678771] =A0P0 -- P1 -- ]
[ =A0 =A03.679046] ata_p=
iix 0000:00:1f.5: setting latency timer to 64
[ =A0 =A03.679562] =
scsi3 : ata_piix
[ =A0 =A03.680057] uhci_hcd: USB Universal Host =
Controller Interface driver


[ =A0 =A03.682601] scsi4 : ata_piix
[ =A0 =A03.682814] ata3:=
 SATA max UDMA/133 cmd 0x2108 ctl 0x2124 bmdma 0x20d0
[ =A0 =A03.=
682893] ata4: SATA max UDMA/133 cmd 0x2100 ctl 0x2120 bmdma 0x20d8
[ =A0 =A03.683028] uhci_hcd 0000:00:1a.0: can't find IRQ for PCI INT =
A; please try using pci=3Dbiosirq


[ =A0 =A03.683123] uhci_hcd 0000:00:1a.0: Found HC with no IRQ. =A0Che=
ck BIOS/PCI 0000:00:1a.0 setup!
[ =A0 =A03.683217] uhci_hcd 0000:=
00:1a.0: init 0000:00:1a.0 fail, -19
[ =A0 =A03.683300] uhci_hcd =
0000:00:1a.1: can't find IRQ for PCI INT B; please try using pci=3Dbios=
irq


[ =A0 =A03.683408] uhci_hcd 0000:00:1a.1: Found HC with no IRQ. =A0Che=
ck BIOS/PCI 0000:00:1a.1 setup!
[ =A0 =A03.683504] uhci_hcd 0000:=
00:1a.1: init 0000:00:1a.1 fail, -19
[ =A0 =A03.683588] uhci_hcd =
0000:00:1d.0: can't find IRQ for PCI INT A; please try using pci=3Dbios=
irq


[ =A0 =A03.683682] uhci_hcd 0000:00:1d.0: Found HC with no IRQ. =A0Che=
ck BIOS/PCI 0000:00:1d.0 setup!
[ =A0 =A03.683802] uhci_hcd 0000:=
00:1d.0: init 0000:00:1d.0 fail, -19
[ =A0 =A03.683933] uhci_hcd =
0000:00:1d.1: can't find IRQ for PCI INT B; please try using pci=3Dbios=
irq


[ =A0 =A03.684026] uhci_hcd 0000:00:1d.1: Found HC with no IRQ. =A0Che=
ck BIOS/PCI 0000:00:1d.1 setup!
[ =A0 =A03.684121] uhci_hcd 0000:=
00:1d.1: init 0000:00:1d.1 fail, -19
[ =A0 =A03.684201] uhci_hcd =
0000:00:1d.2: can't find IRQ for PCI INT C; please try using pci=3Dbios=
irq


[ =A0 =A03.684293] uhci_hcd 0000:00:1d.2: Found HC with no IRQ. =A0Che=
ck BIOS/PCI 0000:00:1d.2 setup!
[ =A0 =A03.684387] uhci_hcd 0000:=
00:1d.2: init 0000:00:1d.2 fail, -19
[ =A0 =A03.751594] microcode=
: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba


[ =A0 =A03.771183] iTCO_vendor_support: vendor-support=3D0
[=
 =A0 =A04.010635] ata3: SATA link down (SStatus 0 SControl 300)
[=
 =A0 =A04.022013] ata4: SATA link down (SStatus 0 SControl 300)
[=
 =A0 =A04.342660] ata2.00: SATA link down (SStatus 0 SControl 300)


[ =A0 =A04.342751] ata2.01: SATA link down (SStatus 0 SControl 300)
[ =A0 =A04.487426] ata1.00: SATA link up 1.5 Gbps (SStatus 113 SCon=
trol 300)
[ =A0 =A04.487519] ata1.01: SATA link down (SStatus 0 S=
Control 300)


[ =A0 =A04.487603] ata1.01: link offline, clearing class 3 to NONE
[ =A0 =A04.495491] ata1.00: ATAPI: IBM SATA DEVICE 81Y3657, IB01, ma=
x UDMA/33
[ =A0 =A04.511489] ata1.00: configured for UDMA/33
[ =A0 =A09.511364] ata1.00: qc timeout (cmd 0xa0)


[ =A0 =A09.511434] ata1.00: TEST_UNIT_READY failed (err_mask=3D0x5)
[ =A0 10.307422] ata1.00: SATA link up 1.5 Gbps (SStatus 113 SContr=
ol 300)
[ =A0 10.307515] ata1.01: SATA link down (SStatus 0 SCont=
rol 300)


[ =A0 10.307600] ata1.01: link offline, clearing class 3 to NONE
=

[ =A0 10.331487] ata1.00: configured for UDMA/33
[ =A0 15.33=
1361] ata1.00: qc timeout (cmd 0xa0)
[ =A0 15.331431] ata1.00: TE=
ST_UNIT_READY failed (err_mask=3D0x5)


[ =A0 15.331504] ata1.00: limiting SATA link speed to 1.5 Gbps
[ =A0 15.331574] ata1.00: limiting speed to UDMA/33:PIO3
[ =A0=
 16.127423] ata1.00: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
=


[ =A0 16.127515] ata1.01: SATA link down (SStatus 0 SControl 300)
[ =A0 16.127601] ata1.01: link offline, clearing class 3 to NONE
[ =A0 16.151487] ata1.00: configured for UDMA/33
[ =A0 21.151378=
] ata1.00: qc timeout (cmd 0xa0)


[ =A0 21.151448] ata1.00: TEST_UNIT_READY failed (err_mask=3D0x5)
[ =A0 21.151518] ata1.00: disabled
[ =A0 21.151603] ata1.00=
: hard resetting link
[ =A0 21.471351] ata1.01: hard resetting li=
nk


[ =A0 21.947430] ata1.00: SATA link up 1.5 Gbps (SStatus 113 SControl =
310)
[ =A0 21.947523] ata1.01: SATA link down (SStatus 0 SControl=
 300)
[ =A0 21.947608] ata1.01: link offline, clearing class 3 to=
 NONE


[ =A0 21.947611] ata1: EH complete
[ =A0 21.963868] iTCO_wdt=
: Intel TCO WatchDog Timer Driver v1.10
[ =A0 21.963965] iTCO_wdt=
: Found a ICH10 TCO device (Version=3D2, TCOBASE=3D0x05e0)
[ =A0 =
21.964124] iTCO_wdt: initialized. heartbeat=3D30 sec (nowayout=3D0)


[ =A0 21.997872] Error: Driver 'pcspkr' is already registered,=
 aborting...
[ =A0 22.010315] alg: No test for __gcm-aes-aesni (_=
_driver-gcm-aes-aesni)
[ =A0 22.995255] EXT4-fs (dm-0): re-mounte=
d. Opts: (null)


[ =A0 23.177611] EXT4-fs (dm-0): re-mounted. Opts: errors=3Dremount-ro=

[ =A0 23.281974] loop: module loaded
[ =A0 23.346661] =
lp: driver loaded but no devices found
[ =A0 24.043404] Adding 41=
94300k swap on /dev/mapper/xen-fw_swap. =A0Priority:-1 extents:1 across:419=
4300k=A0


[ =A0 24.347072] EXT4-fs (sda3): mounted filesystem with ordered data =
mode. Opts: (null)
[ =A0 24.386139] FAT-fs (sda2): utf8 is not a =
recommended IO charset for FAT filesystems, filesystem will be case sensiti=
ve!


[ =A0 25.140294] bnx2 0000:0b:00.0: eth0: using MSIX
[ =A0 2=
5.140439] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ =
=A0 25.181911] Bridge firewalling registered
[ =A0 25.186131] dev=
ice eth1 entered promiscuous mode


[ =A0 25.288312] bnx2 0000:0b:00.1: eth1: using MSIX
[ =A0 2=
5.288410] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[ =
=A0 25.290413] IPv6: ADDRCONF(NETDEV_UP): xenbr0: link is not ready
[ =A0 26.898999] bnx2 0000:0b:00.0: eth0: NIC Copper Link is Up, 100 Mbp=
s full duplex


[ =A0 26.899091]=A0
[ =A0 26.899222] IPv6: ADDRCONF(NETDEV_C=
HANGE): eth0: link becomes ready
[ =A0 28.981380] bnx2 0000:0b:00=
.1: eth1: NIC Copper Link is Up, 1000 Mbps full duplex
[ =A0 28.9=
81477]=A0


[ =A0 28.981613] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes rea=
dy
[ =A0 28.981698] xenbr0: port 1(eth1) entered forwarding state=

[ =A0 28.981771] xenbr0: port 1(eth1) entered forwarding state

[ =A0 28.981850] IPv6: ADDRCONF(NETDEV_CHANGE): xenbr0: link becomes r=
eady
[ =A0 33.512189] RPC: Registered named UNIX socket transport=
 module.
[ =A0 33.512281] RPC: Registered udp transport module.

[ =A0 33.512351] RPC: Registered tcp transport module.
[ =A0=
 33.512420] RPC: Registered tcp NFSv4.1 backchannel transport module.
=

[ =A0 33.533692] FS-Cache: Loaded
[ =A0 33.547314] FS-Cache:=
 Netfs 'nfs' registered for caching


[ =A0 33.579870] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
[ =A0 34.845026] nf_=
conntrack version 0.5.0 (16384 buckets, 65536 max)
[ =A0 34.85487=
0] ip_tables: (C) 2000-2006 Netfilter Core Team


[ =A0 35.475210] ppdev: user-space parallel port driver
[ =
=A0 39.140866] colord-sane[2701]: segfault at 0 ip 00007fc826bc4884 sp 0000=
7fff6a44fea0 error 4 in libc-2.13.so[7f=
c826b1f000+17d000]


[ =A0 44.011341] xenbr0: port 1(eth1) entered forwarding state


Thanks for all,
Allan Sche=
id



--bcaec5299feb5f768904cbc0bbb9--


--===============5491451415256564798==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5491451415256564798==--


From xen-devel-bounces@lists.xen.org Thu Oct 11 05:56:00 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 05:56:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMBjy-0001g2-8x; Thu, 11 Oct 2012 05:55:26 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMA5N-00013q-6M
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 04:09:25 +0000
X-Env-Sender: avs.009@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1349928549!8138114!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8012 invoked from network); 11 Oct 2012 04:09:10 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Oct 2012 04:09:10 -0000
Received: by mail-ie0-f173.google.com with SMTP id 17so2911021iea.32
	for ; Wed, 10 Oct 2012 21:09:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=PBoaX0hWyFiG2/NUOkbkFFwuWZC0noIesAxrwLor5xU=;
	b=tRRz4WNWKRxgn4aGmd74Sb/wjcPOORFtInkOMgwGXmD1jGcjl5cXiPEDZC7m7FEUWp
	o5EIGfIhfkHhc/0QI87FvTwUy6zJhTGEKzH681ZyM3a6kdEaVB7jLGVWBboFpJq4NQIO
	7Eans+ABh9fQf6ltDSw2nTQdE0w1pjuZDIrdk9cWClmToX+vyhlKDWAsfxP+lBiQiS7d
	OlF21UAsPkj1M1FiyIGqk618Q5oLyBd/Dg+a9IfTjGl3WB57KSjUvec+F0mlOrsTDpXO
	oK7P40pou6RcHcnBHG2rOYH4ro/Xkzg87v+pZ4LKmtoa7dyF2fRyYCNoDiHj7aruT6GO
	IAFA==
MIME-Version: 1.0
Received: by 10.43.48.129 with SMTP id uw1mr20141161icb.10.1349928544597; Wed,
	10 Oct 2012 21:09:04 -0700 (PDT)
Received: by 10.64.22.71 with HTTP; Wed, 10 Oct 2012 21:09:04 -0700 (PDT)
Date: Thu, 11 Oct 2012 01:09:04 -0300
Message-ID: 
From: Allan Scheid 
To: xen-devel@lists.xen.org
X-Mailman-Approved-At: Thu, 11 Oct 2012 05:55:25 +0000
Subject: [Xen-devel] Xen 4.2 with EFI on IBM x3650 ACPI Bug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============5491451415256564798=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5491451415256564798==
Content-Type: multipart/alternative; boundary=bcaec5299feb5f768904cbc0bbb9

--bcaec5299feb5f768904cbc0bbb9
Content-Type: text/plain; charset=ISO-8859-1

Hellow all, i need help to fix this bug:

ACPI BIOS Bug: Error: A valid RSDP was not found (20120711/tbxfroot-219)

Because of this first errors i get this after, and it causes don't work USB
ports and some PCI cards on the system:

can't find IRQ for PCI INT A; please try using pci=biosirq

Kernel: 3.6.1-xen self compiled (work perfect without xen multiboot)
Xen Version: 4.2
Grub2 EFI: 1.99-23
Debian Unstable distro

dmesg output:

[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.6.1-xen (root@lca-fw) (gcc version 4.7.1
(Debian 4.7.1-7) ) #1 SMP Wed Oct 10 22:46:05 BRT 2012
[    0.000000] Command line: placeholder root=/dev/mapper/xen-fw_root ro
[    0.000000] Freeing 6c-6d pfn range: 1 pages freed
[    0.000000] 1-1 mapping on 6c->6d
[    0.000000] Freeing 9f-100 pfn range: 97 pages freed
[    0.000000] 1-1 mapping on 9f->100
[    0.000000] Freeing 7acb7-7ccb8 pfn range: 8193 pages freed
[    0.000000] 1-1 mapping on 7acb7->7ccb8
[    0.000000] Freeing 7d4f0-7d51b pfn range: 43 pages freed
[    0.000000] 1-1 mapping on 7d4f0->7d51b
[    0.000000] Freeing 7d53f-7d56a pfn range: 43 pages freed
[    0.000000] 1-1 mapping on 7d53f->7d56a
[    0.000000] Freeing 7d704-7d7b4 pfn range: 176 pages freed
[    0.000000] 1-1 mapping on 7d704->7d7b4
[    0.000000] Freeing 7f5ef-7f7ff pfn range: 528 pages freed
[    0.000000] 1-1 mapping on 7f5ef->7f7ff
[    0.000000] Freeing 7f800-f258d pfn range: 470413 pages freed
[    0.000000] 1-1 mapping on 7f800->100000
[    0.000000] Released 479494 pages of unused memory
[    0.000000] Set 535417 page(s) to 1-1 mapping
[    0.000000] Populating 100000-175106 pfn range: 479494 pages added
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] Xen: [mem 0x0000000000000000-0x000000000006bfff] usable
[    0.000000] Xen: [mem 0x000000000006c000-0x000000000006cfff] ACPI NVS
[    0.000000] Xen: [mem 0x000000000006d000-0x000000000009efff] usable
[    0.000000] Xen: [mem 0x000000000009f000-0x000000000009ffff] ACPI NVS
[    0.000000] Xen: [mem 0x00000000000a0000-0x00000000000fffff] reserved
[    0.000000] Xen: [mem 0x0000000000100000-0x000000007acb6fff] usable
[    0.000000] Xen: [mem 0x000000007acb7000-0x000000007ccb7fff] reserved
[    0.000000] Xen: [mem 0x000000007ccb8000-0x000000007d4effff] usable
[    0.000000] Xen: [mem 0x000000007d4f0000-0x000000007d51afff] reserved
[    0.000000] Xen: [mem 0x000000007d51b000-0x000000007d53efff] usable
[    0.000000] Xen: [mem 0x000000007d53f000-0x000000007d569fff] reserved
[    0.000000] Xen: [mem 0x000000007d56a000-0x000000007d703fff] usable
[    0.000000] Xen: [mem 0x000000007d704000-0x000000007d7b3fff] reserved
[    0.000000] Xen: [mem 0x000000007d7b4000-0x000000007f5eefff] usable
[    0.000000] Xen: [mem 0x000000007f5ef000-0x000000007f6defff] reserved
[    0.000000] Xen: [mem 0x000000007f6df000-0x000000007f7defff] ACPI NVS
[    0.000000] Xen: [mem 0x000000007f7df000-0x000000007f7fefff] ACPI data
[    0.000000] Xen: [mem 0x000000007f7ff000-0x000000007f7fffff] usable
[    0.000000] Xen: [mem 0x0000000080000000-0x000000008fffffff] reserved
[    0.000000] Xen: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved
[    0.000000] Xen: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
[    0.000000] Xen: [mem 0x00000000ff800000-0x00000000ffffffff] reserved
[    0.000000] Xen: [mem 0x0000000100000000-0x000000017fffffff] usable
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI 2.5 present.
[    0.000000] DMI: IBM System x3650 M3 -[7945AC1]-/00D4062, BIOS
-[D6E157AUS-1.15]- 06/13/2012
[    0.000000] e820: update [mem 0x00000000-0x0000ffff] usable ==> reserved
[    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[    0.000000] No AGP bridge found
[    0.000000] e820: last_pfn = 0x180000 max_arch_pfn = 0x400000000
[    0.000000] e820: last_pfn = 0x7f800 max_arch_pfn = 0x400000000
[    0.000000] initial memory mapped: [mem 0x00000000-0x02334fff]
[    0.000000] Base memory trampoline at [ffff880000099000] 99000 size 24576
[    0.000000] init_memory_mapping: [mem 0x00000000-0x7f7fffff]
[    0.000000]  [mem 0x00000000-0x7f7fffff] page 4k
[    0.000000] kernel direct mapping tables up to 0x7f7fffff @ [mem
0x01831000-0x01c2ffff]
[    0.000000] xen: setting RW the range 1c14000 - 1c30000
[    0.000000] init_memory_mapping: [mem 0x100000000-0x17fffffff]
[    0.000000]  [mem 0x100000000-0x17fffffff] page 4k
[    0.000000] kernel direct mapping tables up to 0x17fffffff @ [mem
0x7e9e8000-0x7f5eefff]
[    0.000000] xen: setting RW the range 7edea000 - 7f5ef000
[    0.000000] RAMDISK: [mem 0x01c30000-0x02334fff]
[    0.000000] ACPI BIOS Bug: Error: A valid RSDP was not found
(20120711/tbxfroot-219)
[    0.000000] NUMA turned off
[    0.000000] Faking a node at [mem 0x0000000000000000-0x000000017fffffff]
[    0.000000] Initmem setup node 0 [mem 0x00000000-0x17fffffff]
[    0.000000]   NODE_DATA [mem 0x175102000-0x175105fff]
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x00010000-0x00ffffff]
[    0.000000]   DMA32    [mem 0x01000000-0xffffffff]
[    0.000000]   Normal   [mem 0x100000000-0x17fffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x00010000-0x0006bfff]
[    0.000000]   node   0: [mem 0x0006d000-0x0009efff]
[    0.000000]   node   0: [mem 0x00100000-0x7acb6fff]
[    0.000000]   node   0: [mem 0x7ccb8000-0x7d4effff]
[    0.000000]   node   0: [mem 0x7d51b000-0x7d53efff]
[    0.000000]   node   0: [mem 0x7d56a000-0x7d703fff]
[    0.000000]   node   0: [mem 0x7d7b4000-0x7f5eefff]
[    0.000000]   node   0: [mem 0x7f7ff000-0x7f7fffff]
[    0.000000]   node   0: [mem 0x100000000-0x17fffffff]
[    0.000000] On node 0 totalpages: 1037431
[    0.000000]   DMA zone: 56 pages used for memmap
[    0.000000]   DMA zone: 6 pages reserved
[    0.000000]   DMA zone: 3920 pages, LIFO batch:0
[    0.000000]   DMA32 zone: 14280 pages used for memmap
[    0.000000]   DMA32 zone: 494881 pages, LIFO batch:31
[    0.000000]   Normal zone: 7168 pages used for memmap
[    0.000000]   Normal zone: 517120 pages, LIFO batch:31
[    0.000000] SFI: Simple Firmware Interface v0.81
http://simplefirmware.org
[    0.000000] smpboot: Allowing 1 CPUs, 0 hotplug CPUs
[    0.000000] nr_irqs_gsi: 16
[    0.000000] PM: Registered nosave memory: 000000000006c000 -
000000000006d000
[    0.000000] PM: Registered nosave memory: 000000000009f000 -
00000000000a0000
[    0.000000] PM: Registered nosave memory: 00000000000a0000 -
0000000000100000
[    0.000000] PM: Registered nosave memory: 000000007acb7000 -
000000007ccb8000
[    0.000000] PM: Registered nosave memory: 000000007d4f0000 -
000000007d51b000
[    0.000000] PM: Registered nosave memory: 000000007d53f000 -
000000007d56a000
[    0.000000] PM: Registered nosave memory: 000000007d704000 -
000000007d7b4000
[    0.000000] PM: Registered nosave memory: 000000007f5ef000 -
000000007f6df000
[    0.000000] PM: Registered nosave memory: 000000007f6df000 -
000000007f7df000
[    0.000000] PM: Registered nosave memory: 000000007f7df000 -
000000007f7ff000
[    0.000000] PM: Registered nosave memory: 000000007f800000 -
0000000080000000
[    0.000000] PM: Registered nosave memory: 0000000080000000 -
0000000090000000
[    0.000000] PM: Registered nosave memory: 0000000090000000 -
00000000fed1c000
[    0.000000] PM: Registered nosave memory: 00000000fed1c000 -
00000000fed20000
[    0.000000] PM: Registered nosave memory: 00000000fed20000 -
00000000fee00000
[    0.000000] PM: Registered nosave memory: 00000000fee00000 -
00000000fee01000
[    0.000000] PM: Registered nosave memory: 00000000fee01000 -
00000000ff800000
[    0.000000] PM: Registered nosave memory: 00000000ff800000 -
0000000100000000
[    0.000000] e820: [mem 0x90000000-0xfed1bfff] available for PCI devices
[    0.000000] Booting paravirtualized kernel on Xen
[    0.000000] Xen version: 4.2.0 (preserve-AD)
[    0.000000] setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:1
nr_node_ids:1
[    0.000000] PERCPU: Embedded 28 pages/cpu @ffff880174e00000 s83840 r8192
d22656 u2097152
[    0.000000] pcpu-alloc: s83840 r8192 d22656 u2097152 alloc=1*2097152
[    0.000000] pcpu-alloc: [0] 0
[    1.096975] Built 1 zonelists in Zone order, mobility grouping on.
 Total pages: 1015921
[    1.096977] Policy zone: Normal
[    1.096979] Kernel command line: placeholder
root=/dev/mapper/xen-fw_root ro
[    1.097016] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    1.097021] __ex_table already sorted, skipping sort
[    1.121932] software IO TLB [mem 0x16c800000-0x1707fffff] (64MB) mapped
at [ffff88016c800000-ffff8801707fffff]
[    1.138656] Memory: 3815116k/6291456k available (3573k kernel code,
2141732k absent, 334608k reserved, 3147k data, 592k init)
[    1.138717] Hierarchical RCU implementation.
[    1.138718] RCU dyntick-idle grace-period acceleration is enabled.
[    1.138719] RCU restricting CPUs from NR_CPUS=512 to nr_cpu_ids=1.
[    1.138728] NR_IRQS:33024 nr_irqs:256 16
[    1.147171] Console: colour VGA+ 80x25
[    1.154296] console [tty0] enabled
[    1.159002] allocated 16777216 bytes of page_cgroup
[    1.159079] please try 'cgroup_disable=memory' option if you don't want
memory cgroups
[    1.159208] Xen: using vcpuop timer interface
[    1.159214] installing Xen timer for CPU 0
[    1.159303] tsc: Detected 2400.126 MHz processor
[    1.159375] Calibrating delay loop (skipped), value calculated using
timer frequency.. 4800.25 BogoMIPS (lpj=9600504)
[    1.159517] pid_max: default: 32768 minimum: 301
[    1.159607] Security Framework initialized
[    1.159680] AppArmor: AppArmor disabled by boot time parameter
[    1.160298] Dentry cache hash table entries: 524288 (order: 10, 4194304
bytes)
[    1.161752] Inode-cache hash table entries: 262144 (order: 9, 2097152
bytes)
[    1.162415] Mount-cache hash table entries: 256
[    1.162658] Initializing cgroup subsys cpuacct
[    1.162729] Initializing cgroup subsys memory
[    1.162806] Initializing cgroup subsys devices
[    1.162876] Initializing cgroup subsys freezer
[    1.162945] Initializing cgroup subsys net_cls
[    1.163014] Initializing cgroup subsys blkio
[    1.163082] Initializing cgroup subsys perf_event
[    1.163204] CPU: Physical Processor ID: 0
[    1.163277] CPU: Processor Core ID: 0
[    1.163346] mce: CPU supports 2 MCE banks
[    1.163452] Last level iTLB entries: 4KB 512, 2MB 7, 4MB 7
[    1.163452] Last level dTLB entries: 4KB 512, 2MB 32, 4MB 32
[    1.163452] tlb_flushall_shift is 0x6
[    1.163602] SMP alternatives: switching to UP code
[    1.171342] Freeing SMP alternatives: 8k freed
[    1.171471] Performance Events: unsupported p6 CPU model 44 no PMU
driver, software events only.
[    1.171785] NMI watchdog: disabled (cpu0): hardware events not enabled
[    1.171876] Brought up 1 CPUs
[    1.172058] devtmpfs: initialized
[    1.174970] PM: Registering ACPI NVS region [mem 0x0006c000-0x0006cfff]
(4096 bytes)
[    1.175062] PM: Registering ACPI NVS region [mem 0x0009f000-0x0009ffff]
(4096 bytes)
[    1.175153] PM: Registering ACPI NVS region [mem 0x7f6df000-0x7f7defff]
(1048576 bytes)
[    1.175314] Grant tables using version 2 layout.
[    1.175394] Grant table initialized
[    1.175514] dummy:
[    1.175625] NET: Registered protocol family 16
[    1.175969] PCI: Using configuration type 1 for base access
[    1.176599] bio: create slab  at 0
[    1.176719] ACPI: Interpreter disabled.
[    1.176796] xen/balloon: Initialising balloon driver.
[    1.177620] xen-balloon: Initialising balloon driver.
[    1.177761] vgaarb: loaded
[    1.177860] PCI: Probing PCI hardware
[    1.177929] PCI: root bus 00: using default resources
[    1.177930] PCI: Probing PCI hardware (bus 00)
[    1.177954] PCI host bridge to bus 0000:00
[    1.178025] pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
[    1.178098] pci_bus 0000:00: root bus resource [mem
0x00000000-0xffffffffff]
[    1.178173] pci_bus 0000:00: No busn resource found for root bus, will
use [bus 00-ff]
[    1.178266] pci_bus 0000:00: busn_res: [bus 00-ff] is inserted under
domain [bus 00-ff]
[    1.178287] pci 0000:00:00.0: [8086:3406] type 00 class 0x060000
[    1.178389] pci 0000:00:00.0: PME# supported from D0 D3hot D3cold
[    1.178425] pci 0000:00:01.0: [8086:3408] type 01 class 0x060400
[    1.178532] pci 0000:00:01.0: PME# supported from D0 D3hot D3cold
[    1.178571] pci 0000:00:02.0: [8086:3409] type 01 class 0x060400
[    1.178678] pci 0000:00:02.0: PME# supported from D0 D3hot D3cold
[    1.178716] pci 0000:00:03.0: [8086:340a] type 01 class 0x060400
[    1.178824] pci 0000:00:03.0: PME# supported from D0 D3hot D3cold
[    1.178865] pci 0000:00:05.0: [8086:340c] type 01 class 0x060400
[    1.178973] pci 0000:00:05.0: PME# supported from D0 D3hot D3cold
[    1.179013] pci 0000:00:07.0: [8086:340e] type 01 class 0x060400
[    1.179121] pci 0000:00:07.0: PME# supported from D0 D3hot D3cold
[    1.179161] pci 0000:00:09.0: [8086:3410] type 01 class 0x060400
[    1.179269] pci 0000:00:09.0: PME# supported from D0 D3hot D3cold
[    1.179309] pci 0000:00:10.0: [8086:3425] type 00 class 0x080000
[    1.179434] pci 0000:00:10.1: [8086:3426] type 00 class 0x080000
[    1.179543] pci 0000:00:11.0: [8086:3427] type 00 class 0x080000
[    1.179668] pci 0000:00:11.1: [8086:3428] type 00 class 0x080000
[    1.179795] pci 0000:00:14.0: [8086:342e] type 00 class 0x080000
[    1.179919] pci 0000:00:14.1: [8086:3422] type 00 class 0x080000
[    1.180053] pci 0000:00:14.2: [8086:3423] type 00 class 0x080000
[    1.180172] pci 0000:00:14.3: [8086:3438] type 00 class 0x080000
[    1.180273] pci 0000:00:15.0: [8086:342f] type 00 class 0x080020
[    1.180387] pci 0000:00:16.0: [8086:3430] type 00 class 0x088000
[    1.180408] pci 0000:00:16.0: reg 10: [mem 0x97a00000-0x97a03fff 64bit]
[    1.180540] pci 0000:00:16.1: [8086:3431] type 00 class 0x088000
[    1.180561] pci 0000:00:16.1: reg 10: [mem 0x97a04000-0x97a07fff 64bit]
[    1.180693] pci 0000:00:16.2: [8086:3432] type 00 class 0x088000
[    1.180713] pci 0000:00:16.2: reg 10: [mem 0x97a08000-0x97a0bfff 64bit]
[    1.180845] pci 0000:00:16.3: [8086:3433] type 00 class 0x088000
[    1.180866] pci 0000:00:16.3: reg 10: [mem 0x97a0c000-0x97a0ffff 64bit]
[    1.180997] pci 0000:00:16.4: [8086:3429] type 00 class 0x088000
[    1.181018] pci 0000:00:16.4: reg 10: [mem 0x97a10000-0x97a13fff 64bit]
[    1.181150] pci 0000:00:16.5: [8086:342a] type 00 class 0x088000
[    1.181170] pci 0000:00:16.5: reg 10: [mem 0x97a14000-0x97a17fff 64bit]
[    1.181302] pci 0000:00:16.6: [8086:342b] type 00 class 0x088000
[    1.181323] pci 0000:00:16.6: reg 10: [mem 0x97a18000-0x97a1bfff 64bit]
[    1.181455] pci 0000:00:16.7: [8086:342c] type 00 class 0x088000
[    1.181475] pci 0000:00:16.7: reg 10: [mem 0x97a1c000-0x97a1ffff 64bit]
[    1.181610] pci 0000:00:1a.0: [8086:3a37] type 00 class 0x0c0300
[    1.181681] pci 0000:00:1a.0: reg 20: [io  0x20a0-0x20bf]
[    1.181766] pci 0000:00:1a.1: [8086:3a38] type 00 class 0x0c0300
[    1.181837] pci 0000:00:1a.1: reg 20: [io  0x2080-0x209f]
[    1.181937] pci 0000:00:1a.7: [8086:3a3c] type 00 class 0x0c0320
[    1.181970] pci 0000:00:1a.7: reg 10: [mem 0x97a21000-0x97a213ff]
[    1.182116] pci 0000:00:1a.7: PME# supported from D0 D3hot D3cold
[    1.182153] pci 0000:00:1c.0: [8086:3a40] type 01 class 0x060400
[    1.182274] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
[    1.182316] pci 0000:00:1c.4: [8086:3a48] type 01 class 0x060400
[    1.182435] pci 0000:00:1c.4: PME# supported from D0 D3hot D3cold
[    1.182478] pci 0000:00:1d.0: [8086:3a34] type 00 class 0x0c0300
[    1.182549] pci 0000:00:1d.0: reg 20: [io  0x2060-0x207f]
[    1.182634] pci 0000:00:1d.1: [8086:3a35] type 00 class 0x0c0300
[    1.182705] pci 0000:00:1d.1: reg 20: [io  0x2040-0x205f]
[    1.182790] pci 0000:00:1d.2: [8086:3a36] type 00 class 0x0c0300
[    1.182860] pci 0000:00:1d.2: reg 20: [io  0x2020-0x203f]
[    1.182960] pci 0000:00:1d.7: [8086:3a3a] type 00 class 0x0c0320
[    1.182993] pci 0000:00:1d.7: reg 10: [mem 0x97a20000-0x97a203ff]
[    1.183138] pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold
[    1.183173] pci 0000:00:1e.0: [8086:244e] type 01 class 0x060401
[    1.183279] pci 0000:00:1f.0: [8086:3a18] type 00 class 0x060100
[    1.183458] pci 0000:00:1f.2: [8086:3a20] type 00 class 0x01018f
[    1.183484] pci 0000:00:1f.2: reg 10: [io  0x2118-0x211f]
[    1.183497] pci 0000:00:1f.2: reg 14: [io  0x212c-0x212f]
[    1.183510] pci 0000:00:1f.2: reg 18: [io  0x2110-0x2117]
[    1.183522] pci 0000:00:1f.2: reg 1c: [io  0x2128-0x212b]
[    1.183535] pci 0000:00:1f.2: reg 20: [io  0x20f0-0x20ff]
[    1.183548] pci 0000:00:1f.2: reg 24: [io  0x20e0-0x20ef]
[    1.183629] pci 0000:00:1f.3: [8086:3a30] type 00 class 0x0c0500
[    1.183653] pci 0000:00:1f.3: reg 10: [mem 0x97a22000-0x97a220ff 64bit]
[    1.183689] pci 0000:00:1f.3: reg 20: [io  0x2000-0x201f]
[    1.183746] pci 0000:00:1f.5: [8086:3a26] type 00 class 0x010185
[    1.183772] pci 0000:00:1f.5: reg 10: [io  0x2108-0x210f]
[    1.183784] pci 0000:00:1f.5: reg 14: [io  0x2124-0x2127]
[    1.183797] pci 0000:00:1f.5: reg 18: [io  0x2100-0x2107]
[    1.183816] pci 0000:00:1f.5: reg 1c: [io  0x2120-0x2123]
[    1.183829] pci 0000:00:1f.5: reg 20: [io  0x20d0-0x20df]
[    1.183841] pci 0000:00:1f.5: reg 24: [io  0x20c0-0x20cf]
[    1.183985] pci_bus 0000:0b: busn_res: [bus 0b-0f] is inserted under
[bus 00-ff]
[    1.184016] pci 0000:0b:00.0: [14e4:1639] type 00 class 0x020000
[    1.184040] pci 0000:0b:00.0: reg 10: [mem 0x92000000-0x93ffffff 64bit]
[    1.184181] pci 0000:0b:00.0: PME# supported from D0 D3hot D3cold
[    1.184224] pci 0000:0b:00.1: [14e4:1639] type 00 class 0x020000
[    1.184248] pci 0000:0b:00.1: reg 10: [mem 0x94000000-0x95ffffff 64bit]
[    1.184390] pci 0000:0b:00.1: PME# supported from D0 D3hot D3cold
[    1.191939] pci 0000:00:01.0: PCI bridge to [bus 0b-0f]
[    1.192017] pci 0000:00:01.0:   bridge window [mem 0x92000000-0x95ffffff]
[    1.192089] pci_bus 0000:10: busn_res: [bus 10-14] is inserted under
[bus 00-ff]
[    1.192093] pci 0000:00:02.0: PCI bridge to [bus 10-14]
[    1.192240] pci_bus 0000:15: busn_res: [bus 15-19] is inserted under
[bus 00-ff]
[    1.192244] pci 0000:00:03.0: PCI bridge to [bus 15-19]
[    1.192389] pci_bus 0000:1a: busn_res: [bus 1a-1e] is inserted under
[bus 00-ff]
[    1.192392] pci 0000:00:05.0: PCI bridge to [bus 1a-1e]
[    1.192539] pci_bus 0000:1f: busn_res: [bus 1f-23] is inserted under
[bus 00-ff]
[    1.192542] pci 0000:00:07.0: PCI bridge to [bus 1f-23]
[    1.192688] pci_bus 0000:24: busn_res: [bus 24-28] is inserted under
[bus 00-ff]
[    1.192691] pci 0000:00:09.0: PCI bridge to [bus 24-28]
[    1.192838] pci_bus 0000:01: busn_res: [bus 01-05] is inserted under
[bus 00-ff]
[    1.192863] pci 0000:01:00.0: [1000:0073] type 00 class 0x010400
[    1.192884] pci 0000:01:00.0: reg 10: [io  0x1000-0x10ff]
[    1.192908] pci 0000:01:00.0: reg 14: [mem 0x97940000-0x97943fff 64bit]
[    1.192932] pci 0000:01:00.0: reg 1c: [mem 0x97900000-0x9793ffff 64bit]
[    1.192962] pci 0000:01:00.0: reg 30: [mem 0xfffe0000-0xffffffff pref]
[    1.193060] pci 0000:01:00.0: supports D1 D2
[    1.200042] pci 0000:00:1c.0: PCI bridge to [bus 01-05]
[    1.200117] pci 0000:00:1c.0:   bridge window [io  0x1000-0x1fff]
[    1.200123] pci 0000:00:1c.0:   bridge window [mem 0x97900000-0x979fffff]
[    1.200196] pci_bus 0000:06: busn_res: [bus 06-0a] is inserted under
[bus 00-ff]
[    1.200228] pci 0000:06:00.0: [101b:0452] type 01 class 0x060400
[    1.200394] pci 0000:06:00.0: PME# supported from D0 D3hot D3cold
[    1.208144] pci 0000:00:1c.4: PCI bridge to [bus 06-0a]
[    1.208223] pci 0000:00:1c.4:   bridge window [mem 0x97000000-0x978fffff]
[    1.208231] pci 0000:00:1c.4:   bridge window [mem 0x96000000-0x96ffffff
64bit pref]
[    1.208330] pci_bus 0000:07: busn_res: [bus 07] is inserted under [bus
06-0a]
[    1.208353] pci 0000:07:00.0: [102b:0530] type 00 class 0x030000
[    1.208388] pci 0000:07:00.0: reg 10: [mem 0x96000000-0x96ffffff pref]
[    1.208407] pci 0000:07:00.0: reg 14: [mem 0x97800000-0x97803fff]
[    1.208427] pci 0000:07:00.0: reg 18: [mem 0x97000000-0x977fffff]
[    1.208633] pci 0000:06:00.0: PCI bridge to [bus 07]
[    1.208713] pci 0000:06:00.0:   bridge window [mem 0x97000000-0x978fffff]
[    1.208720] pci 0000:06:00.0:   bridge window [mem 0x96000000-0x96ffffff
pref]
[    1.208768] pci_bus 0000:29: busn_res: [bus 29-2d] is inserted under
[bus 00-ff]
[    1.208829] pci 0000:00:1e.0: PCI bridge to [bus 29-2d] (subtractive
decode)
[    1.208917] pci 0000:00:1e.0:   bridge window [io  0x0000-0xffff]
(subtractive decode)
[    1.208919] pci 0000:00:1e.0:   bridge window [mem
0x00000000-0xffffffffff] (subtractive decode)
[    1.208978] pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 2d
[    1.210287] vgaarb: device added:
PCI:0000:07:00.0,decodes=io+mem,owns=io+mem,locks=none
[    1.210898] PCI: pci_cache_line_size set to 64 bytes
[    1.211078] e820: reserve RAM buffer [mem 0x0006c000-0x0006ffff]
[    1.211080] e820: reserve RAM buffer [mem 0x0009f000-0x0009ffff]
[    1.211081] e820: reserve RAM buffer [mem 0x7acb7000-0x7bffffff]
[    1.211082] e820: reserve RAM buffer [mem 0x7d4f0000-0x7fffffff]
[    1.211086] e820: reserve RAM buffer [mem 0x7d53f000-0x7fffffff]
[    1.211088] e820: reserve RAM buffer [mem 0x7d704000-0x7fffffff]
[    1.211091] e820: reserve RAM buffer [mem 0x7f5ef000-0x7fffffff]
[    1.211093] e820: reserve RAM buffer [mem 0x7f800000-0x7fffffff]
[    1.211210] Switching to clocksource xen
[    1.212720] pnp: PnP ACPI: disabled
[    1.214391] pci 0000:01:00.0: no compatible bridge window for [mem
0xfffe0000-0xffffffff pref]
[    1.214569] pci 0000:00:1c.0: bridge window [mem 0x00100000-0x001fffff
pref] to [bus 01-05] add_size 200000
[    1.214613] pci 0000:00:1c.0: res[15]=[mem 0x00100000-0x001fffff pref]
get_res_add_size add_size 200000
[    1.214617] pci 0000:00:1c.0: BAR 15: assigned [mem
0x90000000-0x902fffff pref]
[    1.214708] pci 0000:00:01.0: PCI bridge to [bus 0b-0f]
[    1.214783] pci 0000:00:01.0:   bridge window [mem 0x92000000-0x95ffffff]
[    1.214865] pci 0000:00:02.0: PCI bridge to [bus 10-14]
[    1.214948] pci 0000:00:03.0: PCI bridge to [bus 15-19]
[    1.215032] pci 0000:00:05.0: PCI bridge to [bus 1a-1e]
[    1.215114] pci 0000:00:07.0: PCI bridge to [bus 1f-23]
[    1.215198] pci 0000:00:09.0: PCI bridge to [bus 24-28]
[    1.215282] pci 0000:01:00.0: BAR 6: assigned [mem 0x90000000-0x9001ffff
pref]
[    1.215383] pci 0000:00:1c.0: PCI bridge to [bus 01-05]
[    1.215456] pci 0000:00:1c.0:   bridge window [io  0x1000-0x1fff]
[    1.215532] pci 0000:00:1c.0:   bridge window [mem 0x97900000-0x979fffff]
[    1.215609] pci 0000:00:1c.0:   bridge window [mem 0x90000000-0x902fffff
pref]
[    1.215705] pci 0000:06:00.0: PCI bridge to [bus 07]
[    1.215782] pci 0000:06:00.0:   bridge window [mem 0x97000000-0x978fffff]
[    1.215860] pci 0000:06:00.0:   bridge window [mem 0x96000000-0x96ffffff
pref]
[    1.223235] pci 0000:00:1c.4: PCI bridge to [bus 06-0a]
[    1.223310] pci 0000:00:1c.4:   bridge window [mem 0x97000000-0x978fffff]
[    1.223391] pci 0000:00:1c.4:   bridge window [mem 0x96000000-0x96ffffff
64bit pref]
[    1.223489] pci 0000:00:1e.0: PCI bridge to [bus 29-2d]
[    1.223580] pci 0000:00:01.0: can't find IRQ for PCI INT A; please try
using pci=biosirq
[    1.223680] pci 0000:00:02.0: can't find IRQ for PCI INT A; please try
using pci=biosirq
[    1.223780] pci 0000:00:03.0: can't find IRQ for PCI INT A; please try
using pci=biosirq
[    1.223880] pci 0000:00:05.0: can't find IRQ for PCI INT A; please try
using pci=biosirq
[    1.223981] pci 0000:00:07.0: can't find IRQ for PCI INT A; please try
using pci=biosirq
[    1.224081] pci 0000:00:09.0: can't find IRQ for PCI INT A; please try
using pci=biosirq
[    1.224183] pci 0000:00:1c.0: can't find IRQ for PCI INT A; please try
using pci=biosirq
[    1.224283] pci 0000:00:1c.4: can't find IRQ for PCI INT A; please try
using pci=biosirq
[    1.224385] pci 0000:06:00.0: can't find IRQ for PCI INT A; please try
using pci=biosirq
[    1.224487] pci 0000:00:1e.0: setting latency timer to 64
[    1.224492] pci_bus 0000:00: resource 4 [io  0x0000-0xffff]
[    1.224494] pci_bus 0000:00: resource 5 [mem 0x00000000-0xffffffffff]
[    1.224496] pci_bus 0000:0b: resource 1 [mem 0x92000000-0x95ffffff]
[    1.224498] pci_bus 0000:01: resource 0 [io  0x1000-0x1fff]
[    1.224500] pci_bus 0000:01: resource 1 [mem 0x97900000-0x979fffff]
[    1.224502] pci_bus 0000:01: resource 2 [mem 0x90000000-0x902fffff pref]
[    1.224504] pci_bus 0000:06: resource 1 [mem 0x97000000-0x978fffff]
[    1.224507] pci_bus 0000:06: resource 2 [mem 0x96000000-0x96ffffff 64bit
pref]
[    1.224510] pci_bus 0000:07: resource 1 [mem 0x97000000-0x978fffff]
[    1.224512] pci_bus 0000:07: resource 2 [mem 0x96000000-0x96ffffff pref]
[    1.224514] pci_bus 0000:29: resource 4 [io  0x0000-0xffff]
[    1.224516] pci_bus 0000:29: resource 5 [mem 0x00000000-0xffffffffff]
[    1.224538] NET: Registered protocol family 2
[    1.225637] TCP established hash table entries: 524288 (order: 11,
8388608 bytes)
[    1.228185] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[    1.228521] TCP: Hash tables configured (established 524288 bind 65536)
[    1.228613] TCP: reno registered
[    1.228689] UDP hash table entries: 2048 (order: 4, 65536 bytes)
[    1.228785] UDP-Lite hash table entries: 2048 (order: 4, 65536 bytes)
[    1.228922] NET: Registered protocol family 1
[    1.229073] pci 0000:00:1a.0: can't find IRQ for PCI INT A; please try
using pci=biosirq
[    1.229201] pci 0000:00:1a.1: can't find IRQ for PCI INT B; please try
using pci=biosirq
[    1.229325] pci 0000:00:1a.7: can't find IRQ for PCI INT C; please try
using pci=biosirq
[    1.229466] pci 0000:00:1d.0: can't find IRQ for PCI INT A; please try
using pci=biosirq
[    1.229588] pci 0000:00:1d.1: can't find IRQ for PCI INT B; please try
using pci=biosirq
[    1.229708] pci 0000:00:1d.2: can't find IRQ for PCI INT C; please try
using pci=biosirq
[    1.229836] pci 0000:00:1d.7: can't find IRQ for PCI INT A; please try
using pci=biosirq
[    1.229986] pci 0000:07:00.0: Boot video device
[    1.229991] PCI: CLS 64 bytes, default 64
[    1.230040] Unpacking initramfs...
[    1.236939] Freeing initrd memory: 7188k freed
[    1.238401] platform rtc_cmos: registered platform RTC device (no PNP
device found)
[    1.238695] audit: initializing netlink socket (disabled)
[    1.238779] type=2000 audit(1349925915.231:1): initialized
[    1.253042] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[    1.253247] VFS: Disk quotas dquot_6.5.2
[    1.253330] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    1.253465] msgmni has been set to 7465
[    1.253646] alg: No test for stdrng (krng)
[    1.253730] Block layer SCSI generic (bsg) driver version 0.4 loaded
(major 252)
[    1.253820] io scheduler noop registered
[    1.253888] io scheduler deadline registered
[    1.253960] io scheduler cfq registered (default)
[    1.254124] pcieport 0000:00:01.0: device [8086:3408] has invalid IRQ;
check vendor BIOS
[    1.254277] pcieport 0000:00:02.0: device [8086:3409] has invalid IRQ;
check vendor BIOS
[    1.254425] pcieport 0000:00:03.0: device [8086:340a] has invalid IRQ;
check vendor BIOS
[    1.254573] pcieport 0000:00:05.0: device [8086:340c] has invalid IRQ;
check vendor BIOS
[    1.254723] pcieport 0000:00:07.0: device [8086:340e] has invalid IRQ;
check vendor BIOS
[    1.254870] pcieport 0000:00:09.0: device [8086:3410] has invalid IRQ;
check vendor BIOS
[    1.255019] pcieport 0000:00:1c.0: device [8086:3a40] has invalid IRQ;
check vendor BIOS
[    1.255170] pcieport 0000:00:1c.4: device [8086:3a48] has invalid IRQ;
check vendor BIOS
[    1.255389] ioapic: probe of 0000:00:15.0 failed with error -22
[    1.255467] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[    1.255554] pciehp: PCI Express Hot Plug Controller Driver version: 0.4
[    1.255627] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
[    1.255752] intel_idle: does not run on family 6 model 44
[    1.255833] Event-channel device installed.
[    1.255989] xen-pciback: backend is vpci
[    1.256298] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    1.277599] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[    1.298917] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
[    1.299221] Linux agpgart interface v0.103
[    1.299387] i8042: PNP: No PS/2 controller found. Probing ports directly.
[    1.551430] serio: i8042 KBD port at 0x60,0x64 irq 1
[    1.551580] mousedev: PS/2 mouse device common for all mice
[    1.551800] rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0
[    1.551897] rtc0: alarms up to one day, 114 bytes nvram
[    1.551972] EFI Variables Facility v0.08 2004-May-17
[    1.552053] drop_monitor: Initializing network drop monitor service
[    1.552197] TCP: cubic registered
[    1.552276] NET: Registered protocol family 10
[    1.552496] mip6: Mobile IPv6
[    1.552564] NET: Registered protocol family 17
[    1.552641] Key type dns_resolver registered
[    1.552859] PM: Hibernation image not present or could not be loaded.
[    1.552868] registered taskstats version 1
[    1.553635] rtc_cmos rtc_cmos: setting system clock to 2012-10-11
03:25:15 UTC (1349925915)
[    1.553954] Freeing unused kernel memory: 592k freed
[    1.554130] Write protecting the kernel read-only data: 6144k
[    1.555798] Freeing unused kernel memory: 512k freed
[    1.556107] Freeing unused kernel memory: 620k freed
[    1.583588] udevd[50]: starting version 175
[    1.657119] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[    1.663281] SCSI subsystem initialized
[    1.681024] megasas: 00.00.06.15-rc1 Mon. Mar. 19 17:00:00 PDT 2012
[    1.681111] megasas: 0x1000:0x0073:0x1014:0x03b1: bus 1:slot 0:func 0
[    1.681241] megaraid_sas 0000:01:00.0: can't find IRQ for PCI INT A;
please try using pci=biosirq
[    1.687892] megasas: FW now in Ready state
[    1.735350] megasas_init_mfi: fw_support_ieee=67108864
[    1.735407] megasas: INIT adapter done
[    1.807365] scsi0 : LSI SAS based MegaRAID driver
[    1.808799] scsi 0:0:8:0: Direct-Access     IBM-ESXS ST9146803SS
 B53C PQ: 0 ANSI: 5
[    1.811249] scsi 0:0:9:0: Direct-Access     ATA      ST9500620NS
 BE24 PQ: 0 ANSI: 5
[    1.812739] scsi 0:0:10:0: Direct-Access     ATA      ST9500620NS
 BE24 PQ: 0 ANSI: 5
[    1.824208] scsi 0:2:0:0: Direct-Access     IBM      ServeRAID M1015
 2.12 PQ: 0 ANSI: 5
[    1.839755] sd 0:2:0:0: [sdb] 1949216768 512-byte logical blocks: (997
GB/929 GiB)
[    1.840060] sd 0:2:0:0: [sdb] Write Protect is off
[    1.840141] sd 0:2:0:0: [sdb] Mode Sense: 1f 00 10 08
[    1.840153] sd 0:0:8:0: [sda] 286748000 512-byte logical blocks: (146
GB/136 GiB)
[    1.840302] sd 0:2:0:0: [sdb] Write cache: disabled, read cache:
disabled, supports DPO and FUA
[    1.842564] sd 0:0:8:0: [sda] Write Protect is off
[    1.842637] sd 0:0:8:0: [sda] Mode Sense: c3 00 10 08
[    1.843418]  sdb: sdb1
[    1.843898] sd 0:0:8:0: [sda] Write cache: disabled, read cache:
enabled, supports DPO and FUA
[    1.844117] sd 0:2:0:0: [sdb] Attached SCSI disk
[    1.866028]  sda: sda1 sda2 sda3 sda4
[    1.870498] sd 0:0:8:0: [sda] Attached SCSI disk
[    2.053157] device-mapper: uevent: version 1.0.3
[    2.053610] device-mapper: ioctl: 4.23.0-ioctl (2012-07-25) initialised:
dm-devel@redhat.com
[    2.214131] EXT4-fs (dm-0): mounted filesystem with ordered data mode.
Opts: (null)
[    3.162111] udevd[298]: starting version 175
[    3.419449] bnx2: Broadcom NetXtreme II Gigabit Ethernet Driver bnx2
v2.2.3 (June 27, 2012)
[    3.419565] bnx2 0000:0b:00.0: can't find IRQ for PCI INT A; please try
using pci=biosirq
[    3.420241] bnx2 0000:0b:00.0: eth0: Broadcom NetXtreme II BCM5709
1000Base-T (C0) PCI Express found at mem 92000000, IRQ 0, node addr
34:40:b5:ab:e5:b4
[    3.421062] bnx2 0000:0b:00.1: can't find IRQ for PCI INT B; please try
using pci=biosirq
[    3.421705] bnx2 0000:0b:00.1: eth1: Broadcom NetXtreme II BCM5709
1000Base-T (C0) PCI Express found at mem 94000000, IRQ 0, node addr
34:40:b5:ab:e5:b6
[    3.428805] dca service started, version 1.12.1
[    3.467169] EDAC MC: Ver: 3.0.0
[    3.473824] ioatdma: Intel(R) QuickData Technology Driver 4.00
[    3.473918] ioatdma 0000:00:16.0: enabling device (0000 -> 0002)
[    3.473996] ioatdma 0000:00:16.0: can't find IRQ for PCI INT A; please
try using pci=biosirq
[    3.474116] ioatdma 0000:00:16.0: channel error register unreachable
[    3.474191] ioatdma 0000:00:16.0: channel enumeration error
[    3.505302] microcode: CPU0 sig=0x206c2, pf=0x1, revision=0x15
[    3.505995] ioatdma 0000:00:16.0: Intel(R) I/OAT DMA Engine init failed
[    3.506096] ioatdma 0000:00:16.1: enabling device (0000 -> 0002)
[    3.506173] ioatdma 0000:00:16.1: can't find IRQ for PCI INT B; please
try using pci=biosirq
[    3.506296] ioatdma 0000:00:16.1: channel error register unreachable
[    3.506369] ioatdma 0000:00:16.1: channel enumeration error
[    3.506441] ioatdma 0000:00:16.1: Intel(R) I/OAT DMA Engine init failed
[    3.506532] ioatdma 0000:00:16.2: enabling device (0000 -> 0002)
[    3.506608] ioatdma 0000:00:16.2: can't find IRQ for PCI INT C; please
try using pci=biosirq
[    3.506722] ioatdma 0000:00:16.2: channel error register unreachable
[    3.506795] ioatdma 0000:00:16.2: channel enumeration error
[    3.506867] ioatdma 0000:00:16.2: Intel(R) I/OAT DMA Engine init failed
[    3.506957] ioatdma 0000:00:16.3: enabling device (0000 -> 0002)
[    3.507034] ioatdma 0000:00:16.3: can't find IRQ for PCI INT D; please
try using pci=biosirq
[    3.507147] ioatdma 0000:00:16.3: channel error register unreachable
[    3.507222] ioatdma 0000:00:16.3: channel enumeration error
[    3.507294] ioatdma 0000:00:16.3: Intel(R) I/OAT DMA Engine init failed
[    3.507398] ioatdma 0000:00:16.4: enabling device (0000 -> 0002)
[    3.507476] ioatdma 0000:00:16.4: can't find IRQ for PCI INT A; please
try using pci=biosirq
[    3.507590] ioatdma 0000:00:16.4: channel error register unreachable
[    3.507663] ioatdma 0000:00:16.4: channel enumeration error
[    3.507735] ioatdma 0000:00:16.4: Intel(R) I/OAT DMA Engine init failed
[    3.507826] ioatdma 0000:00:16.5: enabling device (0000 -> 0002)
[    3.507903] ioatdma 0000:00:16.5: can't find IRQ for PCI INT B; please
try using pci=biosirq
[    3.508016] ioatdma 0000:00:16.5: channel error register unreachable
[    3.508090] ioatdma 0000:00:16.5: channel enumeration error
[    3.508162] ioatdma 0000:00:16.5: Intel(R) I/OAT DMA Engine init failed
[    3.508255] ioatdma 0000:00:16.6: enabling device (0000 -> 0002)
[    3.508337] ioatdma 0000:00:16.6: can't find IRQ for PCI INT C; please
try using pci=biosirq
[    3.508454] ioatdma 0000:00:16.6: channel error register unreachable
[    3.508529] ioatdma 0000:00:16.6: channel enumeration error
[    3.508601] ioatdma 0000:00:16.6: Intel(R) I/OAT DMA Engine init failed
[    3.508692] ioatdma 0000:00:16.7: enabling device (0000 -> 0002)
[    3.508769] ioatdma 0000:00:16.7: can't find IRQ for PCI INT D; please
try using pci=biosirq
[    3.508885] ioatdma 0000:00:16.7: channel error register unreachable
[    3.508958] ioatdma 0000:00:16.7: channel enumeration error
[    3.509030] ioatdma 0000:00:16.7: Intel(R) I/OAT DMA Engine init failed
[    3.571248] usbcore: registered new interface driver usbfs
[    3.571330] usbcore: registered new interface driver hub
[    3.585483] ACPI Exception: AE_BAD_PARAMETER, Thread 1786484928 could
not acquire Mutex [0x1] (20120711/utmutex-276)
[    3.585675] ACPI Exception: AE_BAD_PARAMETER, Thread 1786484928 could
not acquire Mutex [0x1] (20120711/utmutex-276)
[    3.590919] usbcore: registered new device driver usb
[    3.603433] input: PC Speaker as /devices/platform/pcspkr/input/input0
[    3.604762] libata version 3.00 loaded.
[    3.607430] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    3.607535] ehci_hcd 0000:00:1a.7: can't find IRQ for PCI INT C; please
try using pci=biosirq
[    3.607629] ehci_hcd 0000:00:1a.7: Found HC with no IRQ.  Check BIOS/PCI
0000:00:1a.7 setup!
[    3.607723] ehci_hcd 0000:00:1a.7: init 0000:00:1a.7 fail, -19
[    3.607808] ehci_hcd 0000:00:1d.7: can't find IRQ for PCI INT A; please
try using pci=biosirq
[    3.607900] ehci_hcd 0000:00:1d.7: Found HC with no IRQ.  Check BIOS/PCI
0000:00:1d.7 setup!
[    3.607994] ehci_hcd 0000:00:1d.7: init 0000:00:1d.7 fail, -19
[    3.623701] i801_smbus 0000:00:1f.3: enabling device (0140 -> 0143)
[    3.623781] i801_smbus 0000:00:1f.3: can't find IRQ for PCI INT B;
please try using pci=biosirq
[    3.623874] ACPI Exception: AE_BAD_PARAMETER, Thread 1775910976 could
not acquire Mutex [0x1] (20120711/utmutex-276)
[    3.624093] i801_smbus 0000:00:1f.3: SMBus using PCI Interrupt
[    3.676083] ata_piix 0000:00:1f.2: version 2.13
[    3.676095] ata_piix 0000:00:1f.2: can't find IRQ for PCI INT A; please
try using pci=biosirq
[    3.676193] ata_piix 0000:00:1f.2: MAP [
[    3.676260]  P0 P2 P1 P3 ]
[    3.676539] ata_piix 0000:00:1f.2: setting latency timer to 64
[    3.677344] scsi1 : ata_piix
[    3.677732] scsi2 : ata_piix
[    3.677862] ata1: SATA max UDMA/133 cmd 0x2118 ctl 0x212c bmdma 0x20f0
[    3.677954] ata2: SATA max UDMA/133 cmd 0x2110 ctl 0x2128 bmdma 0x20f8
[    3.678154] gpio_ich: GPIO from 195 to 255 on gpio_ich
[    3.678606] ata_piix 0000:00:1f.5: can't find IRQ for PCI INT C; please
try using pci=biosirq
[    3.678703] ata_piix 0000:00:1f.5: MAP [
[    3.678771]  P0 -- P1 -- ]
[    3.679046] ata_piix 0000:00:1f.5: setting latency timer to 64
[    3.679562] scsi3 : ata_piix
[    3.680057] uhci_hcd: USB Universal Host Controller Interface driver
[    3.682601] scsi4 : ata_piix
[    3.682814] ata3: SATA max UDMA/133 cmd 0x2108 ctl 0x2124 bmdma 0x20d0
[    3.682893] ata4: SATA max UDMA/133 cmd 0x2100 ctl 0x2120 bmdma 0x20d8
[    3.683028] uhci_hcd 0000:00:1a.0: can't find IRQ for PCI INT A; please
try using pci=biosirq
[    3.683123] uhci_hcd 0000:00:1a.0: Found HC with no IRQ.  Check BIOS/PCI
0000:00:1a.0 setup!
[    3.683217] uhci_hcd 0000:00:1a.0: init 0000:00:1a.0 fail, -19
[    3.683300] uhci_hcd 0000:00:1a.1: can't find IRQ for PCI INT B; please
try using pci=biosirq
[    3.683408] uhci_hcd 0000:00:1a.1: Found HC with no IRQ.  Check BIOS/PCI
0000:00:1a.1 setup!
[    3.683504] uhci_hcd 0000:00:1a.1: init 0000:00:1a.1 fail, -19
[    3.683588] uhci_hcd 0000:00:1d.0: can't find IRQ for PCI INT A; please
try using pci=biosirq
[    3.683682] uhci_hcd 0000:00:1d.0: Found HC with no IRQ.  Check BIOS/PCI
0000:00:1d.0 setup!
[    3.683802] uhci_hcd 0000:00:1d.0: init 0000:00:1d.0 fail, -19
[    3.683933] uhci_hcd 0000:00:1d.1: can't find IRQ for PCI INT B; please
try using pci=biosirq
[    3.684026] uhci_hcd 0000:00:1d.1: Found HC with no IRQ.  Check BIOS/PCI
0000:00:1d.1 setup!
[    3.684121] uhci_hcd 0000:00:1d.1: init 0000:00:1d.1 fail, -19
[    3.684201] uhci_hcd 0000:00:1d.2: can't find IRQ for PCI INT C; please
try using pci=biosirq
[    3.684293] uhci_hcd 0000:00:1d.2: Found HC with no IRQ.  Check BIOS/PCI
0000:00:1d.2 setup!
[    3.684387] uhci_hcd 0000:00:1d.2: init 0000:00:1d.2 fail, -19
[    3.751594] microcode: Microcode Update Driver: v2.00 <
tigran@aivazian.fsnet.co.uk>, Peter Oruba
[    3.771183] iTCO_vendor_support: vendor-support=0
[    4.010635] ata3: SATA link down (SStatus 0 SControl 300)
[    4.022013] ata4: SATA link down (SStatus 0 SControl 300)
[    4.342660] ata2.00: SATA link down (SStatus 0 SControl 300)
[    4.342751] ata2.01: SATA link down (SStatus 0 SControl 300)
[    4.487426] ata1.00: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[    4.487519] ata1.01: SATA link down (SStatus 0 SControl 300)
[    4.487603] ata1.01: link offline, clearing class 3 to NONE
[    4.495491] ata1.00: ATAPI: IBM SATA DEVICE 81Y3657, IB01, max UDMA/33
[    4.511489] ata1.00: configured for UDMA/33
[    9.511364] ata1.00: qc timeout (cmd 0xa0)
[    9.511434] ata1.00: TEST_UNIT_READY failed (err_mask=0x5)
[   10.307422] ata1.00: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   10.307515] ata1.01: SATA link down (SStatus 0 SControl 300)
[   10.307600] ata1.01: link offline, clearing class 3 to NONE
[   10.331487] ata1.00: configured for UDMA/33
[   15.331361] ata1.00: qc timeout (cmd 0xa0)
[   15.331431] ata1.00: TEST_UNIT_READY failed (err_mask=0x5)
[   15.331504] ata1.00: limiting SATA link speed to 1.5 Gbps
[   15.331574] ata1.00: limiting speed to UDMA/33:PIO3
[   16.127423] ata1.00: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[   16.127515] ata1.01: SATA link down (SStatus 0 SControl 300)
[   16.127601] ata1.01: link offline, clearing class 3 to NONE
[   16.151487] ata1.00: configured for UDMA/33
[   21.151378] ata1.00: qc timeout (cmd 0xa0)
[   21.151448] ata1.00: TEST_UNIT_READY failed (err_mask=0x5)
[   21.151518] ata1.00: disabled
[   21.151603] ata1.00: hard resetting link
[   21.471351] ata1.01: hard resetting link
[   21.947430] ata1.00: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[   21.947523] ata1.01: SATA link down (SStatus 0 SControl 300)
[   21.947608] ata1.01: link offline, clearing class 3 to NONE
[   21.947611] ata1: EH complete
[   21.963868] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.10
[   21.963965] iTCO_wdt: Found a ICH10 TCO device (Version=2,
TCOBASE=0x05e0)
[   21.964124] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[   21.997872] Error: Driver 'pcspkr' is already registered, aborting...
[   22.010315] alg: No test for __gcm-aes-aesni (__driver-gcm-aes-aesni)
[   22.995255] EXT4-fs (dm-0): re-mounted. Opts: (null)
[   23.177611] EXT4-fs (dm-0): re-mounted. Opts: errors=remount-ro
[   23.281974] loop: module loaded
[   23.346661] lp: driver loaded but no devices found
[   24.043404] Adding 4194300k swap on /dev/mapper/xen-fw_swap.
 Priority:-1 extents:1 across:4194300k
[   24.347072] EXT4-fs (sda3): mounted filesystem with ordered data mode.
Opts: (null)
[   24.386139] FAT-fs (sda2): utf8 is not a recommended IO charset for FAT
filesystems, filesystem will be case sensitive!
[   25.140294] bnx2 0000:0b:00.0: eth0: using MSIX
[   25.140439] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   25.181911] Bridge firewalling registered
[   25.186131] device eth1 entered promiscuous mode
[   25.288312] bnx2 0000:0b:00.1: eth1: using MSIX
[   25.288410] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[   25.290413] IPv6: ADDRCONF(NETDEV_UP): xenbr0: link is not ready
[   26.898999] bnx2 0000:0b:00.0: eth0: NIC Copper Link is Up, 100 Mbps
full duplex
[   26.899091]
[   26.899222] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   28.981380] bnx2 0000:0b:00.1: eth1: NIC Copper Link is Up, 1000 Mbps
full duplex
[   28.981477]
[   28.981613] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[   28.981698] xenbr0: port 1(eth1) entered forwarding state
[   28.981771] xenbr0: port 1(eth1) entered forwarding state
[   28.981850] IPv6: ADDRCONF(NETDEV_CHANGE): xenbr0: link becomes ready
[   33.512189] RPC: Registered named UNIX socket transport module.
[   33.512281] RPC: Registered udp transport module.
[   33.512351] RPC: Registered tcp transport module.
[   33.512420] RPC: Registered tcp NFSv4.1 backchannel transport module.
[   33.533692] FS-Cache: Loaded
[   33.547314] FS-Cache: Netfs 'nfs' registered for caching
[   33.579870] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
[   34.845026] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
[   34.854870] ip_tables: (C) 2000-2006 Netfilter Core Team
[   35.475210] ppdev: user-space parallel port driver
[   39.140866] colord-sane[2701]: segfault at 0 ip 00007fc826bc4884 sp
00007fff6a44fea0 error 4 in libc-2.13.so[7fc826b1f000+17d000]
[   44.011341] xenbr0: port 1(eth1) entered forwarding state


Thanks for all,
Allan Scheid

--bcaec5299feb5f768904cbc0bbb9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hellow all, i need help to fix this bug:


ACPI BIOS Bug: Error: A valid RSDP was not found (20120=
711/tbxfroot-219)

Because of this first errors i g=
et this after, and it causes don't work USB ports and some PCI cards on=
 the system:



can't find IRQ for PCI INT A; please try using pci=
=3Dbiosirq

Kernel:=A03.6.1-xen self compiled (work=
 perfect without xen multiboot)
Xen Version: 4.2
Grub2 =
EFI: 1.99-23


Debian Unstable distro

dmesg output:

[ =A0 =A00.000000] Initializing cgroup subsys cpuset<=
/div>
[ =A0 =A00.000000] Initializing cgroup subsys cpu
[ =A0=
 =A00.000000] Linux version 3.6.1-xen (root@lca-fw) (gcc version 4.7.1 (Deb=
ian 4.7.1-7) ) #1 SMP Wed Oct 10 22:46:05 BRT 2012


[ =A0 =A00.000000] Command line: placeholder root=3D/dev/mapper/xen-fw=
_root ro
[ =A0 =A00.000000] Freeing 6c-6d pfn range: 1 pages free=
d
[ =A0 =A00.000000] 1-1 mapping on 6c->6d
[ =A0 =A0=
0.000000] Freeing 9f-100 pfn range: 97 pages freed


[ =A0 =A00.000000] 1-1 mapping on 9f->100
[ =A0 =A00.0000=
00] Freeing 7acb7-7ccb8 pfn range: 8193 pages freed
[ =A0 =A00.00=
0000] 1-1 mapping on 7acb7->7ccb8
[ =A0 =A00.000000] Freeing 7=
d4f0-7d51b pfn range: 43 pages freed


[ =A0 =A00.000000] 1-1 mapping on 7d4f0->7d51b
[ =A0 =A00=
.000000] Freeing 7d53f-7d56a pfn range: 43 pages freed
[ =A0 =A00=
.000000] 1-1 mapping on 7d53f->7d56a
[ =A0 =A00.000000] Freein=
g 7d704-7d7b4 pfn range: 176 pages freed


[ =A0 =A00.000000] 1-1 mapping on 7d704->7d7b4
[ =A0 =A00=
.000000] Freeing 7f5ef-7f7ff pfn range: 528 pages freed
[ =A0 =A0=
0.000000] 1-1 mapping on 7f5ef->7f7ff
[ =A0 =A00.000000] Freei=
ng 7f800-f258d pfn range: 470413 pages freed


[ =A0 =A00.000000] 1-1 mapping on 7f800->100000
[ =A0 =A0=
0.000000] Released 479494 pages of unused memory
[ =A0 =A00.00000=
0] Set 535417 page(s) to 1-1 mapping
[ =A0 =A00.000000] Populatin=
g 100000-175106 pfn range: 479494 pages added


[ =A0 =A00.000000] e820: BIOS-provided physical RAM map:
[ =
=A0 =A00.000000] Xen: [mem 0x0000000000000000-0x000000000006bfff] usable
[ =A0 =A00.000000] Xen: [mem 0x000000000006c000-0x000000000006cfff]=
 ACPI NVS


[ =A0 =A00.000000] Xen: [mem 0x000000000006d000-0x000000000009efff] us=
able
[ =A0 =A00.000000] Xen: [mem 0x000000000009f000-0x0000000000=
09ffff] ACPI NVS
[ =A0 =A00.000000] Xen: [mem 0x00000000000a0000-=
0x00000000000fffff] reserved


[ =A0 =A00.000000] Xen: [mem 0x0000000000100000-0x000000007acb6fff] us=
able
[ =A0 =A00.000000] Xen: [mem 0x000000007acb7000-0x000000007c=
cb7fff] reserved
[ =A0 =A00.000000] Xen: [mem 0x000000007ccb8000-=
0x000000007d4effff] usable


[ =A0 =A00.000000] Xen: [mem 0x000000007d4f0000-0x000000007d51afff] re=
served
[ =A0 =A00.000000] Xen: [mem 0x000000007d51b000-0x00000000=
7d53efff] usable
[ =A0 =A00.000000] Xen: [mem 0x000000007d53f000-=
0x000000007d569fff] reserved


[ =A0 =A00.000000] Xen: [mem 0x000000007d56a000-0x000000007d703fff] us=
able
[ =A0 =A00.000000] Xen: [mem 0x000000007d704000-0x000000007d=
7b3fff] reserved
[ =A0 =A00.000000] Xen: [mem 0x000000007d7b4000-=
0x000000007f5eefff] usable


[ =A0 =A00.000000] Xen: [mem 0x000000007f5ef000-0x000000007f6defff] re=
served
[ =A0 =A00.000000] Xen: [mem 0x000000007f6df000-0x00000000=
7f7defff] ACPI NVS
[ =A0 =A00.000000] Xen: [mem 0x000000007f7df00=
0-0x000000007f7fefff] ACPI data


[ =A0 =A00.000000] Xen: [mem 0x000000007f7ff000-0x000000007f7fffff] us=
able
[ =A0 =A00.000000] Xen: [mem 0x0000000080000000-0x000000008f=
ffffff] reserved
[ =A0 =A00.000000] Xen: [mem 0x00000000fed1c000-=
0x00000000fed1ffff] reserved


[ =A0 =A00.000000] Xen: [mem 0x00000000fee00000-0x00000000fee00fff] re=
served
[ =A0 =A00.000000] Xen: [mem 0x00000000ff800000-0x00000000=
ffffffff] reserved
[ =A0 =A00.000000] Xen: [mem 0x000000010000000=
0-0x000000017fffffff] usable


[ =A0 =A00.000000] NX (Execute Disable) protection: active
[=
 =A0 =A00.000000] DMI 2.5 present.
[ =A0 =A00.000000] DMI: IBM Sy=
stem x3650 M3 -[7945AC1]-/00D4062, BIOS -[D6E157AUS-1.15]- 06/13/2012
=

[ =A0 =A00.000000] e820: update [mem 0x00000000-0x0000ffff] usable =3D=
=3D> reserved


[ =A0 =A00.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[ =A0 =A00.000000] No AGP bridge found
[ =A0 =A00.000000] =
e820: last_pfn =3D 0x180000 max_arch_pfn =3D 0x400000000
[ =A0 =
=A00.000000] e820: last_pfn =3D 0x7f800 max_arch_pfn =3D 0x400000000


[ =A0 =A00.000000] initial memory mapped: [mem 0x00000000-0x02334fff]<=
/div>
[ =A0 =A00.000000] Base memory trampoline at [ffff880000099000] 9=
9000 size 24576
[ =A0 =A00.000000] init_memory_mapping: [mem 0x00=
000000-0x7f7fffff]


[ =A0 =A00.000000] =A0[mem 0x00000000-0x7f7fffff] page 4k
[ =
=A0 =A00.000000] kernel direct mapping tables up to 0x7f7fffff @ [mem 0x018=
31000-0x01c2ffff]
[ =A0 =A00.000000] xen: setting RW the range 1c=
14000 - 1c30000


[ =A0 =A00.000000] init_memory_mapping: [mem 0x100000000-0x17fffffff]<=
/div>
[ =A0 =A00.000000] =A0[mem 0x100000000-0x17fffffff] page 4k
=

[ =A0 =A00.000000] kernel direct mapping tables up to 0x17fffffff @ [m=
em 0x7e9e8000-0x7f5eefff]


[ =A0 =A00.000000] xen: setting RW the range 7edea000 - 7f5ef000
=

[ =A0 =A00.000000] RAMDISK: [mem 0x01c30000-0x02334fff]
[ =
=A0 =A00.000000] ACPI BIOS Bug: Error: A valid RSDP was not found (20120711=
/tbxfroot-219)


[ =A0 =A00.000000] NUMA turned off
[ =A0 =A00.000000] Faking=
 a node at [mem 0x0000000000000000-0x000000017fffffff]
[ =A0 =A00=
.000000] Initmem setup node 0 [mem 0x00000000-0x17fffffff]
[ =A0 =
=A00.000000] =A0 NODE_DATA [mem 0x175102000-0x175105fff]


[ =A0 =A00.000000] Zone ranges:
[ =A0 =A00.000000] =A0 DMA =
=A0 =A0 =A0[mem 0x00010000-0x00ffffff]
[ =A0 =A00.000000] =A0 DMA=
32 =A0 =A0[mem 0x01000000-0xffffffff]
[ =A0 =A00.000000] =A0 Norm=
al =A0 [mem 0x100000000-0x17fffffff]


[ =A0 =A00.000000] Movable zone start for each node
[ =A0 =
=A00.000000] Early memory node ranges
[ =A0 =A00.000000] =A0 node=
 =A0 0: [mem 0x00010000-0x0006bfff]
[ =A0 =A00.000000] =A0 node =
=A0 0: [mem 0x0006d000-0x0009efff]


[ =A0 =A00.000000] =A0 node =A0 0: [mem 0x00100000-0x7acb6fff]
[ =A0 =A00.000000] =A0 node =A0 0: [mem 0x7ccb8000-0x7d4effff]
[ =A0 =A00.000000] =A0 node =A0 0: [mem 0x7d51b000-0x7d53efff]
[=
 =A0 =A00.000000] =A0 node =A0 0: [mem 0x7d56a000-0x7d703fff]


[ =A0 =A00.000000] =A0 node =A0 0: [mem 0x7d7b4000-0x7f5eefff]
[ =A0 =A00.000000] =A0 node =A0 0: [mem 0x7f7ff000-0x7f7fffff]
[ =A0 =A00.000000] =A0 node =A0 0: [mem 0x100000000-0x17fffffff]
[ =A0 =A00.000000] On node 0 totalpages: 1037431


[ =A0 =A00.000000] =A0 DMA zone: 56 pages used for memmap
[ =
=A0 =A00.000000] =A0 DMA zone: 6 pages reserved
[ =A0 =A00.000000=
] =A0 DMA zone: 3920 pages, LIFO batch:0
[ =A0 =A00.000000] =A0 D=
MA32 zone: 14280 pages used for memmap


[ =A0 =A00.000000] =A0 DMA32 zone: 494881 pages, LIFO batch:31
[ =A0 =A00.000000] =A0 Normal zone: 7168 pages used for memmap
[ =A0 =A00.000000] =A0 Normal zone: 517120 pages, LIFO batch:31
=
[ =A0 =A00.000000] SFI: Simple Firmware Interface v0.81 http://simplefirmware.org


[ =A0 =A00.000000] smpboot: Allowing 1 CPUs, 0 hotplug CPUs
=
[ =A0 =A00.000000] nr_irqs_gsi: 16
[ =A0 =A00.000000] PM: Registe=
red nosave memory: 000000000006c000 - 000000000006d000
[ =A0 =A00=
.000000] PM: Registered nosave memory: 000000000009f000 - 00000000000a0000<=
/div>

[ =A0 =A00.000000] PM: Registered nosave memory: 00000000000a0000 - 00=
00000000100000
[ =A0 =A00.000000] PM: Registered nosave memory: 0=
00000007acb7000 - 000000007ccb8000
[ =A0 =A00.000000] PM: Registe=
red nosave memory: 000000007d4f0000 - 000000007d51b000


[ =A0 =A00.000000] PM: Registered nosave memory: 000000007d53f000 - 00=
0000007d56a000
[ =A0 =A00.000000] PM: Registered nosave memory: 0=
00000007d704000 - 000000007d7b4000
[ =A0 =A00.000000] PM: Registe=
red nosave memory: 000000007f5ef000 - 000000007f6df000


[ =A0 =A00.000000] PM: Registered nosave memory: 000000007f6df000 - 00=
0000007f7df000
[ =A0 =A00.000000] PM: Registered nosave memory: 0=
00000007f7df000 - 000000007f7ff000
[ =A0 =A00.000000] PM: Registe=
red nosave memory: 000000007f800000 - 0000000080000000


[ =A0 =A00.000000] PM: Registered nosave memory: 0000000080000000 - 00=
00000090000000
[ =A0 =A00.000000] PM: Registered nosave memory: 0=
000000090000000 - 00000000fed1c000
[ =A0 =A00.000000] PM: Registe=
red nosave memory: 00000000fed1c000 - 00000000fed20000


[ =A0 =A00.000000] PM: Registered nosave memory: 00000000fed20000 - 00=
000000fee00000
[ =A0 =A00.000000] PM: Registered nosave memory: 0=
0000000fee00000 - 00000000fee01000
[ =A0 =A00.000000] PM: Registe=
red nosave memory: 00000000fee01000 - 00000000ff800000


[ =A0 =A00.000000] PM: Registered nosave memory: 00000000ff800000 - 00=
00000100000000
[ =A0 =A00.000000] e820: [mem 0x90000000-0xfed1bff=
f] available for PCI devices
[ =A0 =A00.000000] Booting paravirtu=
alized kernel on Xen


[ =A0 =A00.000000] Xen version: 4.2.0 (preserve-AD)
[ =A0 =
=A00.000000] setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:1 nr_=
node_ids:1
[ =A0 =A00.000000] PERCPU: Embedded 28 pages/cpu @ffff=
880174e00000 s83840 r8192 d22656 u2097152


[ =A0 =A00.000000] pcpu-alloc: s83840 r8192 d22656 u2097152 alloc=3D1*=
2097152
[ =A0 =A00.000000] pcpu-alloc: [0] 0=A0
[ =A0 =
=A01.096975] Built 1 zonelists in Zone order, mobility grouping on. =A0Tota=
l pages: 1015921


[ =A0 =A01.096977] Policy zone: Normal
[ =A0 =A01.096979] Ke=
rnel command line: placeholder root=3D/dev/mapper/xen-fw_root ro
=
[ =A0 =A01.097016] PID hash table entries: 4096 (order: 3, 32768 bytes)
[ =A0 =A01.097021] __ex_table already sorted, skipping sort


[ =A0 =A01.121932] software IO TLB [mem 0x16c800000-0x1707fffff] (64MB=
) mapped at [ffff88016c800000-ffff8801707fffff]
[ =A0 =A01.138656=
] Memory: 3815116k/6291456k available (3573k kernel code, 2141732k absent, =
334608k reserved, 3147k data, 592k init)


[ =A0 =A01.138717] Hierarchical RCU implementation.
[ =A0 =
=A01.138718] 	RCU dyntick-idle grace-period acceleration is enabled.
[ =A0 =
=A01.138719] 	RCU restricting CPUs from NR_CPUS=3D512 to nr_cpu_ids=3D1.


[ =A0 =A01.138728] NR_IRQS:33024 nr_irqs:256 16
[ =A0 =A01.1=
47171] Console: colour VGA+ 80x25
[ =A0 =A01.154296] console [tty=
0] enabled
[ =A0 =A01.159002] allocated 16777216 bytes of page_cg=
roup

[ =A0 =A01.159079] please try 'cgroup_disable=3Dmemory' option if y=
ou don't want memory cgroups
[ =A0 =A01.159208] Xen: using vc=
puop timer interface
[ =A0 =A01.159214] installing Xen timer for =
CPU 0


[ =A0 =A01.159303] tsc: Detected 2400.126 MHz processor
[ =
=A0 =A01.159375] Calibrating delay loop (skipped), value calculated using t=
imer frequency.. 4800.25 BogoMIPS (lpj=3D9600504)
[ =A0 =A01.1595=
17] pid_max: default: 32768 minimum: 301


[ =A0 =A01.159607] Security Framework initialized
[ =A0 =A01=
.159680] AppArmor: AppArmor disabled by boot time parameter
[ =A0=
 =A01.160298] Dentry cache hash table entries: 524288 (order: 10, 4194304 b=
ytes)


[ =A0 =A01.161752] Inode-cache hash table entries: 262144 (order: 9, 2=
097152 bytes)
[ =A0 =A01.162415] Mount-cache hash table entries: =
256
[ =A0 =A01.162658] Initializing cgroup subsys cpuacct
[ =A0 =A01.162729] Initializing cgroup subsys memory


[ =A0 =A01.162806] Initializing cgroup subsys devices
[ =A0 =
=A01.162876] Initializing cgroup subsys freezer
[ =A0 =A01.162945=
] Initializing cgroup subsys net_cls
[ =A0 =A01.163014] Initializ=
ing cgroup subsys blkio


[ =A0 =A01.163082] Initializing cgroup subsys perf_event
[ =
=A0 =A01.163204] CPU: Physical Processor ID: 0
[ =A0 =A01.163277]=
 CPU: Processor Core ID: 0
[ =A0 =A01.163346] mce: CPU supports 2=
 MCE banks


[ =A0 =A01.163452] Last level iTLB entries: 4KB 512, 2MB 7, 4MB 7
[ =A0 =A01.163452] Last level dTLB entries: 4KB 512, 2MB 32, 4MB 32
[ =A0 =A01.163452] tlb_flushall_shift is 0x6
[ =A0 =A01.=
163602] SMP alternatives: switching to UP code


[ =A0 =A01.171342] Freeing SMP alternatives: 8k freed
[ =A0 =
=A01.171471] Performance Events: unsupported p6 CPU model 44 no PMU driver,=
 software events only.
[ =A0 =A01.171785] NMI watchdog: disabled =
(cpu0): hardware events not enabled


[ =A0 =A01.171876] Brought up 1 CPUs
[ =A0 =A01.172058] devt=
mpfs: initialized
[ =A0 =A01.174970] PM: Registering ACPI NVS reg=
ion [mem 0x0006c000-0x0006cfff] (4096 bytes)
[ =A0 =A01.175062] P=
M: Registering ACPI NVS region [mem 0x0009f000-0x0009ffff] (4096 bytes)

[ =A0 =A01.175153] PM: Registering ACPI NVS region [mem 0x7f6df000-0x7=
f7defff] (1048576 bytes)
[ =A0 =A01.175314] Grant tables using ve=
rsion 2 layout.
[ =A0 =A01.175394] Grant table initialized
<=
div>[ =A0 =A01.175514] dummy:=A0


[ =A0 =A01.175625] NET: Registered protocol family 16
[ =A0 =
=A01.175969] PCI: Using configuration type 1 for base access
[ =
=A0 =A01.176599] bio: create slab <bio-0> at 0
[ =A0 =A01.1=
76719] ACPI: Interpreter disabled.


[ =A0 =A01.176796] xen/balloon: Initialising balloon driver.
[ =A0 =A01.177620] xen-balloon: Initialising balloon driver.
[ =
=A0 =A01.177761] vgaarb: loaded
[ =A0 =A01.177860] PCI: Probing P=
CI hardware


[ =A0 =A01.177929] PCI: root bus 00: using default resources
[ =A0 =A01.177930] PCI: Probing PCI hardware (bus 00)
[ =A0 =A01=
.177954] PCI host bridge to bus 0000:00
[ =A0 =A01.178025] pci_bu=
s 0000:00: root bus resource [io =A00x0000-0xffff]


[ =A0 =A01.178098] pci_bus 0000:00: root bus resource [mem 0x00000000-=
0xffffffffff]
[ =A0 =A01.178173] pci_bus 0000:00: No busn resourc=
e found for root bus, will use [bus 00-ff]
[ =A0 =A01.178266] pci=
_bus 0000:00: busn_res: [bus 00-ff] is inserted under domain [bus 00-ff]

[ =A0 =A01.178287] pci 0000:00:00.0: [8086:3406] type 00 class 0x06000=
0
[ =A0 =A01.178389] pci 0000:00:00.0: PME# supported from D0 D3h=
ot D3cold
[ =A0 =A01.178425] pci 0000:00:01.0: [8086:3408] type 0=
1 class 0x060400


[ =A0 =A01.178532] pci 0000:00:01.0: PME# supported from D0 D3hot D3co=
ld
[ =A0 =A01.178571] pci 0000:00:02.0: [8086:3409] type 01 class=
 0x060400
[ =A0 =A01.178678] pci 0000:00:02.0: PME# supported fro=
m D0 D3hot D3cold


[ =A0 =A01.178716] pci 0000:00:03.0: [8086:340a] type 01 class 0x06040=
0
[ =A0 =A01.178824] pci 0000:00:03.0: PME# supported from D0 D3h=
ot D3cold
[ =A0 =A01.178865] pci 0000:00:05.0: [8086:340c] type 0=
1 class 0x060400


[ =A0 =A01.178973] pci 0000:00:05.0: PME# supported from D0 D3hot D3co=
ld
[ =A0 =A01.179013] pci 0000:00:07.0: [8086:340e] type 01 class=
 0x060400
[ =A0 =A01.179121] pci 0000:00:07.0: PME# supported fro=
m D0 D3hot D3cold


[ =A0 =A01.179161] pci 0000:00:09.0: [8086:3410] type 01 class 0x06040=
0
[ =A0 =A01.179269] pci 0000:00:09.0: PME# supported from D0 D3h=
ot D3cold
[ =A0 =A01.179309] pci 0000:00:10.0: [8086:3425] type 0=
0 class 0x080000


[ =A0 =A01.179434] pci 0000:00:10.1: [8086:3426] type 00 class 0x08000=
0
[ =A0 =A01.179543] pci 0000:00:11.0: [8086:3427] type 00 class =
0x080000
[ =A0 =A01.179668] pci 0000:00:11.1: [8086:3428] type 00=
 class 0x080000


[ =A0 =A01.179795] pci 0000:00:14.0: [8086:342e] type 00 class 0x08000=
0
[ =A0 =A01.179919] pci 0000:00:14.1: [8086:3422] type 00 class =
0x080000
[ =A0 =A01.180053] pci 0000:00:14.2: [8086:3423] type 00=
 class 0x080000


[ =A0 =A01.180172] pci 0000:00:14.3: [8086:3438] type 00 class 0x08000=
0
[ =A0 =A01.180273] pci 0000:00:15.0: [8086:342f] type 00 class =
0x080020
[ =A0 =A01.180387] pci 0000:00:16.0: [8086:3430] type 00=
 class 0x088000


[ =A0 =A01.180408] pci 0000:00:16.0: reg 10: [mem 0x97a00000-0x97a03ff=
f 64bit]
[ =A0 =A01.180540] pci 0000:00:16.1: [8086:3431] type 00=
 class 0x088000
[ =A0 =A01.180561] pci 0000:00:16.1: reg 10: [mem=
 0x97a04000-0x97a07fff 64bit]


[ =A0 =A01.180693] pci 0000:00:16.2: [8086:3432] type 00 class 0x08800=
0
[ =A0 =A01.180713] pci 0000:00:16.2: reg 10: [mem 0x97a08000-0x=
97a0bfff 64bit]
[ =A0 =A01.180845] pci 0000:00:16.3: [8086:3433] =
type 00 class 0x088000


[ =A0 =A01.180866] pci 0000:00:16.3: reg 10: [mem 0x97a0c000-0x97a0fff=
f 64bit]
[ =A0 =A01.180997] pci 0000:00:16.4: [8086:3429] type 00=
 class 0x088000
[ =A0 =A01.181018] pci 0000:00:16.4: reg 10: [mem=
 0x97a10000-0x97a13fff 64bit]


[ =A0 =A01.181150] pci 0000:00:16.5: [8086:342a] type 00 class 0x08800=
0
[ =A0 =A01.181170] pci 0000:00:16.5: reg 10: [mem 0x97a14000-0x=
97a17fff 64bit]
[ =A0 =A01.181302] pci 0000:00:16.6: [8086:342b] =
type 00 class 0x088000


[ =A0 =A01.181323] pci 0000:00:16.6: reg 10: [mem 0x97a18000-0x97a1bff=
f 64bit]
[ =A0 =A01.181455] pci 0000:00:16.7: [8086:342c] type 00=
 class 0x088000
[ =A0 =A01.181475] pci 0000:00:16.7: reg 10: [mem=
 0x97a1c000-0x97a1ffff 64bit]


[ =A0 =A01.181610] pci 0000:00:1a.0: [8086:3a37] type 00 class 0x0c030=
0
[ =A0 =A01.181681] pci 0000:00:1a.0: reg 20: [io =A00x20a0-0x20=
bf]
[ =A0 =A01.181766] pci 0000:00:1a.1: [8086:3a38] type 00 clas=
s 0x0c0300


[ =A0 =A01.181837] pci 0000:00:1a.1: reg 20: [io =A00x2080-0x209f]
[ =A0 =A01.181937] pci 0000:00:1a.7: [8086:3a3c] type 00 class 0x0c0=
320
[ =A0 =A01.181970] pci 0000:00:1a.7: reg 10: [mem 0x97a21000-=
0x97a213ff]


[ =A0 =A01.182116] pci 0000:00:1a.7: PME# supported from D0 D3hot D3co=
ld
[ =A0 =A01.182153] pci 0000:00:1c.0: [8086:3a40] type 01 class=
 0x060400
[ =A0 =A01.182274] pci 0000:00:1c.0: PME# supported fro=
m D0 D3hot D3cold


[ =A0 =A01.182316] pci 0000:00:1c.4: [8086:3a48] type 01 class 0x06040=
0
[ =A0 =A01.182435] pci 0000:00:1c.4: PME# supported from D0 D3h=
ot D3cold
[ =A0 =A01.182478] pci 0000:00:1d.0: [8086:3a34] type 0=
0 class 0x0c0300


[ =A0 =A01.182549] pci 0000:00:1d.0: reg 20: [io =A00x2060-0x207f]
[ =A0 =A01.182634] pci 0000:00:1d.1: [8086:3a35] type 00 class 0x0c0=
300
[ =A0 =A01.182705] pci 0000:00:1d.1: reg 20: [io =A00x2040-0x=
205f]

[ =A0 =A01.182790] pci 0000:00:1d.2: [8086:3a36] type 00 class 0x0c0300
[ =A0 =A01.182860] pci 0000:00:1d.2: reg 20: [io =A00x2020-0x203f]
[ =A0 =A01.182960] pci 0000:00:1d.7: [8086:3a3a] type 00 class 0x0=
c0320


[ =A0 =A01.182993] pci 0000:00:1d.7: reg 10: [mem 0x97a20000-0x97a203f=
f]
[ =A0 =A01.183138] pci 0000:00:1d.7: PME# supported from D0 D3=
hot D3cold
[ =A0 =A01.183173] pci 0000:00:1e.0: [8086:244e] type =
01 class 0x060401


[ =A0 =A01.183279] pci 0000:00:1f.0: [8086:3a18] type 00 class 0x06010=
0
[ =A0 =A01.183458] pci 0000:00:1f.2: [8086:3a20] type 00 class =
0x01018f
[ =A0 =A01.183484] pci 0000:00:1f.2: reg 10: [io =A00x21=
18-0x211f]


[ =A0 =A01.183497] pci 0000:00:1f.2: reg 14: [io =A00x212c-0x212f]
[ =A0 =A01.183510] pci 0000:00:1f.2: reg 18: [io =A00x2110-0x2117]
[ =A0 =A01.183522] pci 0000:00:1f.2: reg 1c: [io =A00x2128-0x212b]=

[ =A0 =A01.183535] pci 0000:00:1f.2: reg 20: [io =A00x20f0-0x20f=
f]


[ =A0 =A01.183548] pci 0000:00:1f.2: reg 24: [io =A00x20e0-0x20ef]
[ =A0 =A01.183629] pci 0000:00:1f.3: [8086:3a30] type 00 class 0x0c0=
500
[ =A0 =A01.183653] pci 0000:00:1f.3: reg 10: [mem 0x97a22000-=
0x97a220ff 64bit]


[ =A0 =A01.183689] pci 0000:00:1f.3: reg 20: [io =A00x2000-0x201f]
[ =A0 =A01.183746] pci 0000:00:1f.5: [8086:3a26] type 00 class 0x010=
185
[ =A0 =A01.183772] pci 0000:00:1f.5: reg 10: [io =A00x2108-0x=
210f]

[ =A0 =A01.183784] pci 0000:00:1f.5: reg 14: [io =A00x2124-0x2127]
[ =A0 =A01.183797] pci 0000:00:1f.5: reg 18: [io =A00x2100-0x2107]
<=
div>[ =A0 =A01.183816] pci 0000:00:1f.5: reg 1c: [io =A00x2120-0x2123]
[ =A0 =A01.183829] pci 0000:00:1f.5: reg 20: [io =A00x20d0-0x20df]

[ =A0 =A01.183841] pci 0000:00:1f.5: reg 24: [io =A00x20c0-0x20cf]
[ =A0 =A01.183985] pci_bus 0000:0b: busn_res: [bus 0b-0f] is inserte=
d under [bus 00-ff]
[ =A0 =A01.184016] pci 0000:0b:00.0: [14e4:16=
39] type 00 class 0x020000


[ =A0 =A01.184040] pci 0000:0b:00.0: reg 10: [mem 0x92000000-0x93fffff=
f 64bit]
[ =A0 =A01.184181] pci 0000:0b:00.0: PME# supported from=
 D0 D3hot D3cold
[ =A0 =A01.184224] pci 0000:0b:00.1: [14e4:1639]=
 type 00 class 0x020000


[ =A0 =A01.184248] pci 0000:0b:00.1: reg 10: [mem 0x94000000-0x95fffff=
f 64bit]
[ =A0 =A01.184390] pci 0000:0b:00.1: PME# supported from=
 D0 D3hot D3cold
[ =A0 =A01.191939] pci 0000:00:01.0: PCI bridge =
to [bus 0b-0f]


[ =A0 =A01.192017] pci 0000:00:01.0: =A0 bridge window [mem 0x92000000=
-0x95ffffff]
[ =A0 =A01.192089] pci_bus 0000:10: busn_res: [bus 1=
0-14] is inserted under [bus 00-ff]
[ =A0 =A01.192093] pci 0000:0=
0:02.0: PCI bridge to [bus 10-14]


[ =A0 =A01.192240] pci_bus 0000:15: busn_res: [bus 15-19] is inserted =
under [bus 00-ff]
[ =A0 =A01.192244] pci 0000:00:03.0: PCI bridge=
 to [bus 15-19]
[ =A0 =A01.192389] pci_bus 0000:1a: busn_res: [bu=
s 1a-1e] is inserted under [bus 00-ff]


[ =A0 =A01.192392] pci 0000:00:05.0: PCI bridge to [bus 1a-1e]
[ =A0 =A01.192539] pci_bus 0000:1f: busn_res: [bus 1f-23] is inserted un=
der [bus 00-ff]
[ =A0 =A01.192542] pci 0000:00:07.0: PCI bridge t=
o [bus 1f-23]


[ =A0 =A01.192688] pci_bus 0000:24: busn_res: [bus 24-28] is inserted =
under [bus 00-ff]
[ =A0 =A01.192691] pci 0000:00:09.0: PCI bridge=
 to [bus 24-28]
[ =A0 =A01.192838] pci_bus 0000:01: busn_res: [bu=
s 01-05] is inserted under [bus 00-ff]


[ =A0 =A01.192863] pci 0000:01:00.0: [1000:0073] type 00 class 0x01040=
0
[ =A0 =A01.192884] pci 0000:01:00.0: reg 10: [io =A00x1000-0x10=
ff]
[ =A0 =A01.192908] pci 0000:01:00.0: reg 14: [mem 0x97940000-=
0x97943fff 64bit]


[ =A0 =A01.192932] pci 0000:01:00.0: reg 1c: [mem 0x97900000-0x9793fff=
f 64bit]
[ =A0 =A01.192962] pci 0000:01:00.0: reg 30: [mem 0xfffe=
0000-0xffffffff pref]
[ =A0 =A01.193060] pci 0000:01:00.0: suppor=
ts D1 D2


[ =A0 =A01.200042] pci 0000:00:1c.0: PCI bridge to [bus 01-05]
[ =A0 =A01.200117] pci 0000:00:1c.0: =A0 bridge window [io =A00x1000-0x1=
fff]
[ =A0 =A01.200123] pci 0000:00:1c.0: =A0 bridge window [mem =
0x97900000-0x979fffff]


[ =A0 =A01.200196] pci_bus 0000:06: busn_res: [bus 06-0a] is inserted =
under [bus 00-ff]
[ =A0 =A01.200228] pci 0000:06:00.0: [101b:0452=
] type 01 class 0x060400
[ =A0 =A01.200394] pci 0000:06:00.0: PME=
# supported from D0 D3hot D3cold


[ =A0 =A01.208144] pci 0000:00:1c.4: PCI bridge to [bus 06-0a]
[ =A0 =A01.208223] pci 0000:00:1c.4: =A0 bridge window [mem 0x97000000-0=
x978fffff]
[ =A0 =A01.208231] pci 0000:00:1c.4: =A0 bridge window=
 [mem 0x96000000-0x96ffffff 64bit pref]


[ =A0 =A01.208330] pci_bus 0000:07: busn_res: [bus 07] is inserted und=
er [bus 06-0a]
[ =A0 =A01.208353] pci 0000:07:00.0: [102b:0530] t=
ype 00 class 0x030000
[ =A0 =A01.208388] pci 0000:07:00.0: reg 10=
: [mem 0x96000000-0x96ffffff pref]


[ =A0 =A01.208407] pci 0000:07:00.0: reg 14: [mem 0x97800000-0x97803ff=
f]
[ =A0 =A01.208427] pci 0000:07:00.0: reg 18: [mem 0x97000000-0=
x977fffff]
[ =A0 =A01.208633] pci 0000:06:00.0: PCI bridge to [bu=
s 07]


[ =A0 =A01.208713] pci 0000:06:00.0: =A0 bridge window [mem 0x97000000=
-0x978fffff]
[ =A0 =A01.208720] pci 0000:06:00.0: =A0 bridge wind=
ow [mem 0x96000000-0x96ffffff pref]
[ =A0 =A01.208768] pci_bus 00=
00:29: busn_res: [bus 29-2d] is inserted under [bus 00-ff]


[ =A0 =A01.208829] pci 0000:00:1e.0: PCI bridge to [bus 29-2d] (subtra=
ctive decode)
[ =A0 =A01.208917] pci 0000:00:1e.0: =A0 bridge win=
dow [io =A00x0000-0xffff] (subtractive decode)
[ =A0 =A01.208919]=
 pci 0000:00:1e.0: =A0 bridge window [mem 0x00000000-0xffffffffff] (subtrac=
tive decode)


[ =A0 =A01.208978] pci_bus 0000:00: busn_res: [bus 00-ff] end is updat=
ed to 2d
[ =A0 =A01.210287] vgaarb: device added: PCI:0000:07:00.=
0,decodes=3Dio+mem,owns=3Dio+mem,locks=3Dnone
[ =A0 =A01.210898] =
PCI: pci_cache_line_size set to 64 bytes


[ =A0 =A01.211078] e820: reserve RAM buffer [mem 0x0006c000-0x0006ffff=
]
[ =A0 =A01.211080] e820: reserve RAM buffer [mem 0x0009f000-0x0=
009ffff]
[ =A0 =A01.211081] e820: reserve RAM buffer [mem 0x7acb7=
000-0x7bffffff]


[ =A0 =A01.211082] e820: reserve RAM buffer [mem 0x7d4f0000-0x7fffffff=
]
[ =A0 =A01.211086] e820: reserve RAM buffer [mem 0x7d53f000-0x7=
fffffff]
[ =A0 =A01.211088] e820: reserve RAM buffer [mem 0x7d704=
000-0x7fffffff]


[ =A0 =A01.211091] e820: reserve RAM buffer [mem 0x7f5ef000-0x7fffffff=
]
[ =A0 =A01.211093] e820: reserve RAM buffer [mem 0x7f800000-0x7=
fffffff]
[ =A0 =A01.211210] Switching to clocksource xen
[ =A0 =A01.212720] pnp: PnP ACPI: disabled


[ =A0 =A01.214391] pci 0000:01:00.0: no compatible bridge window for [=
mem 0xfffe0000-0xffffffff pref]
[ =A0 =A01.214569] pci 0000:00:1c=
.0: bridge window [mem 0x00100000-0x001fffff pref] to [bus 01-05] add_size =
200000


[ =A0 =A01.214613] pci 0000:00:1c.0: res[15]=3D[mem 0x00100000-0x001ff=
fff pref] get_res_add_size add_size 200000
[ =A0 =A01.214617] pci=
 0000:00:1c.0: BAR 15: assigned [mem 0x90000000-0x902fffff pref]
=
[ =A0 =A01.214708] pci 0000:00:01.0: PCI bridge to [bus 0b-0f]


[ =A0 =A01.214783] pci 0000:00:01.0: =A0 bridge window [mem 0x92000000=
-0x95ffffff]
[ =A0 =A01.214865] pci 0000:00:02.0: PCI bridge to [=
bus 10-14]
[ =A0 =A01.214948] pci 0000:00:03.0: PCI bridge to [bu=
s 15-19]


[ =A0 =A01.215032] pci 0000:00:05.0: PCI bridge to [bus 1a-1e]
[ =A0 =A01.215114] pci 0000:00:07.0: PCI bridge to [bus 1f-23]
[ =A0 =A01.215198] pci 0000:00:09.0: PCI bridge to [bus 24-28]
[=
 =A0 =A01.215282] pci 0000:01:00.0: BAR 6: assigned [mem 0x90000000-0x9001f=
fff pref]


[ =A0 =A01.215383] pci 0000:00:1c.0: PCI bridge to [bus 01-05]
[ =A0 =A01.215456] pci 0000:00:1c.0: =A0 bridge window [io =A00x1000-0x1=
fff]
[ =A0 =A01.215532] pci 0000:00:1c.0: =A0 bridge window [mem =
0x97900000-0x979fffff]


[ =A0 =A01.215609] pci 0000:00:1c.0: =A0 bridge window [mem 0x90000000=
-0x902fffff pref]
[ =A0 =A01.215705] pci 0000:06:00.0: PCI bridge=
 to [bus 07]
[ =A0 =A01.215782] pci 0000:06:00.0: =A0 bridge wind=
ow [mem 0x97000000-0x978fffff]


[ =A0 =A01.215860] pci 0000:06:00.0: =A0 bridge window [mem 0x96000000=
-0x96ffffff pref]
[ =A0 =A01.223235] pci 0000:00:1c.4: PCI bridge=
 to [bus 06-0a]
[ =A0 =A01.223310] pci 0000:00:1c.4: =A0 bridge w=
indow [mem 0x97000000-0x978fffff]


[ =A0 =A01.223391] pci 0000:00:1c.4: =A0 bridge window [mem 0x96000000=
-0x96ffffff 64bit pref]
[ =A0 =A01.223489] pci 0000:00:1e.0: PCI =
bridge to [bus 29-2d]
[ =A0 =A01.223580] pci 0000:00:01.0: can=
9;t find IRQ for PCI INT A; please try using pci=3Dbiosirq


[ =A0 =A01.223680] pci 0000:00:02.0: can't find IRQ for PCI INT A;=
 please try using pci=3Dbiosirq
[ =A0 =A01.223780] pci 0000:00:03=
.0: can't find IRQ for PCI INT A; please try using pci=3Dbiosirq
<=
div>[ =A0 =A01.223880] pci 0000:00:05.0: can't find IRQ for PCI INT A; =
please try using pci=3Dbiosirq


[ =A0 =A01.223981] pci 0000:00:07.0: can't find IRQ for PCI INT A;=
 please try using pci=3Dbiosirq
[ =A0 =A01.224081] pci 0000:00:09=
.0: can't find IRQ for PCI INT A; please try using pci=3Dbiosirq
<=
div>[ =A0 =A01.224183] pci 0000:00:1c.0: can't find IRQ for PCI INT A; =
please try using pci=3Dbiosirq


[ =A0 =A01.224283] pci 0000:00:1c.4: can't find IRQ for PCI INT A;=
 please try using pci=3Dbiosirq
[ =A0 =A01.224385] pci 0000:06:00=
.0: can't find IRQ for PCI INT A; please try using pci=3Dbiosirq
<=
div>[ =A0 =A01.224487] pci 0000:00:1e.0: setting latency timer to 64


[ =A0 =A01.224492] pci_bus 0000:00: resource 4 [io =A00x0000-0xffff]
[ =A0 =A01.224494] pci_bus 0000:00: resource 5 [mem 0x00000000-0xf=
fffffffff]
[ =A0 =A01.224496] pci_bus 0000:0b: resource 1 [mem 0x=
92000000-0x95ffffff]


[ =A0 =A01.224498] pci_bus 0000:01: resource 0 [io =A00x1000-0x1fff]
[ =A0 =A01.224500] pci_bus 0000:01: resource 1 [mem 0x97900000-0x9=
79fffff]
[ =A0 =A01.224502] pci_bus 0000:01: resource 2 [mem 0x90=
000000-0x902fffff pref]


[ =A0 =A01.224504] pci_bus 0000:06: resource 1 [mem 0x97000000-0x978ff=
fff]
[ =A0 =A01.224507] pci_bus 0000:06: resource 2 [mem 0x960000=
00-0x96ffffff 64bit pref]
[ =A0 =A01.224510] pci_bus 0000:07: res=
ource 1 [mem 0x97000000-0x978fffff]


[ =A0 =A01.224512] pci_bus 0000:07: resource 2 [mem 0x96000000-0x96fff=
fff pref]
[ =A0 =A01.224514] pci_bus 0000:29: resource 4 [io =A00=
x0000-0xffff]
[ =A0 =A01.224516] pci_bus 0000:29: resource 5 [mem=
 0x00000000-0xffffffffff]


[ =A0 =A01.224538] NET: Registered protocol family 2
[ =A0 =
=A01.225637] TCP established hash table entries: 524288 (order: 11, 8388608=
 bytes)
[ =A0 =A01.228185] TCP bind hash table entries: 65536 (or=
der: 8, 1048576 bytes)


[ =A0 =A01.228521] TCP: Hash tables configured (established 524288 bin=
d 65536)
[ =A0 =A01.228613] TCP: reno registered
[ =A0 =
=A01.228689] UDP hash table entries: 2048 (order: 4, 65536 bytes)
[ =A0 =A01.228785] UDP-Lite hash table entries: 2048 (order: 4, 65536 byte=
s)


[ =A0 =A01.228922] NET: Registered protocol family 1
[ =A0 =
=A01.229073] pci 0000:00:1a.0: can't find IRQ for PCI INT A; please try=
 using pci=3Dbiosirq
[ =A0 =A01.229201] pci 0000:00:1a.1: can'=
;t find IRQ for PCI INT B; please try using pci=3Dbiosirq


[ =A0 =A01.229325] pci 0000:00:1a.7: can't find IRQ for PCI INT C;=
 please try using pci=3Dbiosirq
[ =A0 =A01.229466] pci 0000:00:1d=
.0: can't find IRQ for PCI INT A; please try using pci=3Dbiosirq
<=
div>[ =A0 =A01.229588] pci 0000:00:1d.1: can't find IRQ for PCI INT B; =
please try using pci=3Dbiosirq


[ =A0 =A01.229708] pci 0000:00:1d.2: can't find IRQ for PCI INT C;=
 please try using pci=3Dbiosirq
[ =A0 =A01.229836] pci 0000:00:1d=
.7: can't find IRQ for PCI INT A; please try using pci=3Dbiosirq
<=
div>[ =A0 =A01.229986] pci 0000:07:00.0: Boot video device


[ =A0 =A01.229991] PCI: CLS 64 bytes, default 64
[ =A0 =A01.=
230040] Unpacking initramfs...
[ =A0 =A01.236939] Freeing initrd =
memory: 7188k freed
[ =A0 =A01.238401] platform rtc_cmos: registe=
red platform RTC device (no PNP device found)


[ =A0 =A01.238695] audit: initializing netlink socket (disabled)
=

[ =A0 =A01.238779] type=3D2000 audit(1349925915.231:1): initialized
[ =A0 =A01.253042] HugeTLB registered 2 MB page size, pre-allocated=
 0 pages


[ =A0 =A01.253247] VFS: Disk quotas dquot_6.5.2
[ =A0 =A01.2=
53330] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
=
[ =A0 =A01.253465] msgmni has been set to 7465
[ =A0 =A01.253646]=
 alg: No test for stdrng (krng)


[ =A0 =A01.253730] Block layer SCSI generic (bsg) driver version 0.4 l=
oaded (major 252)
[ =A0 =A01.253820] io scheduler noop registered=

[ =A0 =A01.253888] io scheduler deadline registered
[ =
=A0 =A01.253960] io scheduler cfq registered (default)


[ =A0 =A01.254124] pcieport 0000:00:01.0: device [8086:3408] has inval=
id IRQ; check vendor BIOS
[ =A0 =A01.254277] pcieport 0000:00:02.=
0: device [8086:3409] has invalid IRQ; check vendor BIOS
[ =A0 =
=A01.254425] pcieport 0000:00:03.0: device [8086:340a] has invalid IRQ; che=
ck vendor BIOS


[ =A0 =A01.254573] pcieport 0000:00:05.0: device [8086:340c] has inval=
id IRQ; check vendor BIOS
[ =A0 =A01.254723] pcieport 0000:00:07.=
0: device [8086:340e] has invalid IRQ; check vendor BIOS
[ =A0 =
=A01.254870] pcieport 0000:00:09.0: device [8086:3410] has invalid IRQ; che=
ck vendor BIOS


[ =A0 =A01.255019] pcieport 0000:00:1c.0: device [8086:3a40] has inval=
id IRQ; check vendor BIOS
[ =A0 =A01.255170] pcieport 0000:00:1c.=
4: device [8086:3a48] has invalid IRQ; check vendor BIOS
[ =A0 =
=A01.255389] ioapic: probe of 0000:00:15.0 failed with error -22


[ =A0 =A01.255467] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[ =A0 =A01.255554] pciehp: PCI Express Hot Plug Controller Driver ve=
rsion: 0.4
[ =A0 =A01.255627] acpiphp: ACPI Hot Plug PCI Controll=
er Driver version: 0.5


[ =A0 =A01.255752] intel_idle: does not run on family 6 model 44
=

[ =A0 =A01.255833] Event-channel device installed.
[ =A0 =A0=
1.255989] xen-pciback: backend is vpci
[ =A0 =A01.256298] Serial:=
 8250/16550 driver, 4 ports, IRQ sharing enabled


[ =A0 =A01.277599] serial8250: ttyS0 at I/O 0x3f8 (irq =3D 4) is a 165=
50A
[ =A0 =A01.298917] serial8250: ttyS1 at I/O 0x2f8 (irq =3D 3)=
 is a 16550A
[ =A0 =A01.299221] Linux agpgart interface v0.103
[ =A0 =A01.299387] i8042: PNP: No PS/2 controller found. Probing po=
rts directly.


[ =A0 =A01.551430] serio: i8042 KBD port at 0x60,0x64 irq 1
=
[ =A0 =A01.551580] mousedev: PS/2 mouse device common for all mice
[ =A0 =A01.551800] rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rt=
c0


[ =A0 =A01.551897] rtc0: alarms up to one day, 114 bytes nvram
[ =A0 =A01.551972] EFI Variables Facility v0.08 2004-May-17
[ =
=A0 =A01.552053] drop_monitor: Initializing network drop monitor service

[ =A0 =A01.552197] TCP: cubic registered
[ =A0 =A01.552276] NET: =
Registered protocol family 10
[ =A0 =A01.552496] mip6: Mobile IPv=
6
[ =A0 =A01.552564] NET: Registered protocol family 17
[ =A0 =A01.552641] Key type dns_resolver registered


[ =A0 =A01.552859] PM: Hibernation image not present or could not be l=
oaded.
[ =A0 =A01.552868] registered taskstats version 1
[ =A0 =A01.553635] rtc_cmos rtc_cmos: setting system clock to 2012-10-11 =
03:25:15 UTC (1349925915)


[ =A0 =A01.553954] Freeing unused kernel memory: 592k freed
=
[ =A0 =A01.554130] Write protecting the kernel read-only data: 6144k
<=
div>[ =A0 =A01.555798] Freeing unused kernel memory: 512k freed
[=
 =A0 =A01.556107] Freeing unused kernel memory: 620k freed


[ =A0 =A01.583588] udevd[50]: starting version 175
[ =A0 =A0=
1.657119] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[ =A0 =A01.663281] SCSI subsystem initialized
[ =A0 =A01.68=
1024] megasas: 00.00.06.15-rc1 Mon. Mar. 19 17:00:00 PDT 2012


[ =A0 =A01.681111] megasas: 0x1000:0x0073:0x1014:0x03b1: bus 1:slot 0:=
func 0
[ =A0 =A01.681241] megaraid_sas 0000:01:00.0: can't fi=
nd IRQ for PCI INT A; please try using pci=3Dbiosirq
[ =A0 =A01.6=
87892] megasas: FW now in Ready state


[ =A0 =A01.735350] megasas_init_mfi: fw_support_ieee=3D67108864
<=
div>[ =A0 =A01.735407] megasas: INIT adapter done
[ =A0 =A01.8073=
65] scsi0 : LSI SAS based MegaRAID driver
[ =A0 =A01.808799] scsi=
 0:0:8:0: Direct-Access =A0 =A0 IBM-ESXS ST9146803SS =A0 =A0 =A0B53C PQ: 0 =
ANSI: 5


[ =A0 =A01.811249] scsi 0:0:9:0: Direct-Access =A0 =A0 ATA =A0 =A0 =A0=
ST9500620NS =A0 =A0 =A0BE24 PQ: 0 ANSI: 5
[ =A0 =A01.812739] scsi=
 0:0:10:0: Direct-Access =A0 =A0 ATA =A0 =A0 =A0ST9500620NS =A0 =A0 =A0BE24=
 PQ: 0 ANSI: 5
[ =A0 =A01.824208] scsi 0:2:0:0: Direct-Access =A0=
 =A0 IBM =A0 =A0 =A0ServeRAID M1015 =A02.12 PQ: 0 ANSI: 5


[ =A0 =A01.839755] sd 0:2:0:0: [sdb] 1949216768 512-byte logical block=
s: (997 GB/929 GiB)
[ =A0 =A01.840060] sd 0:2:0:0: [sdb] Write Pr=
otect is off
[ =A0 =A01.840141] sd 0:2:0:0: [sdb] Mode Sense: 1f =
00 10 08


[ =A0 =A01.840153] sd 0:0:8:0: [sda] 286748000 512-byte logical blocks=
: (146 GB/136 GiB)
[ =A0 =A01.840302] sd 0:2:0:0: [sdb] Write cac=
he: disabled, read cache: disabled, supports DPO and FUA
[ =A0 =
=A01.842564] sd 0:0:8:0: [sda] Write Protect is off


[ =A0 =A01.842637] sd 0:0:8:0: [sda] Mode Sense: c3 00 10 08
[ =A0 =A01.843418] =A0sdb: sdb1
[ =A0 =A01.843898] sd 0:0:8:0: [=
sda] Write cache: disabled, read cache: enabled, supports DPO and FUA
=

[ =A0 =A01.844117] sd 0:2:0:0: [sdb] Attached SCSI disk


[ =A0 =A01.866028] =A0sda: sda1 sda2 sda3 sda4
[ =A0 =A01.87=
0498] sd 0:0:8:0: [sda] Attached SCSI disk
[ =A0 =A02.053157] dev=
ice-mapper: uevent: version 1.0.3
[ =A0 =A02.053610] device-mappe=
r: ioctl: 4.23.0-ioctl (2012-07-25) initialised: dm-devel@redhat.com


[ =A0 =A02.214131] EXT4-fs (dm-0): mounted filesystem with ordered dat=
a mode. Opts: (null)
[ =A0 =A03.162111] udevd[298]: starting vers=
ion 175
[ =A0 =A03.419449] bnx2: Broadcom NetXtreme II Gigabit Et=
hernet Driver bnx2 v2.2.3 (June 27, 2012)


[ =A0 =A03.419565] bnx2 0000:0b:00.0: can't find IRQ for PCI INT A=
; please try using pci=3Dbiosirq
[ =A0 =A03.420241] bnx2 0000:0b:=
00.0: eth0: Broadcom NetXtreme II BCM5709 1000Base-T (C0) PCI Express found=
 at mem 92000000, IRQ 0, node addr 34:40:b5:ab:e5:b4


[ =A0 =A03.421062] bnx2 0000:0b:00.1: can't find IRQ for PCI INT B=
; please try using pci=3Dbiosirq
[ =A0 =A03.421705] bnx2 0000:0b:=
00.1: eth1: Broadcom NetXtreme II BCM5709 1000Base-T (C0) PCI Express found=
 at mem 94000000, IRQ 0, node addr 34:40:b5:ab:e5:b6


[ =A0 =A03.428805] dca service started, version 1.12.1
[ =A0=
 =A03.467169] EDAC MC: Ver: 3.0.0
[ =A0 =A03.473824] ioatdma: Int=
el(R) QuickData Technology Driver 4.00
[ =A0 =A03.473918] ioatdma=
 0000:00:16.0: enabling device (0000 -> 0002)


[ =A0 =A03.473996] ioatdma 0000:00:16.0: can't find IRQ for PCI IN=
T A; please try using pci=3Dbiosirq
[ =A0 =A03.474116] ioatdma 00=
00:00:16.0: channel error register unreachable
[ =A0 =A03.474191]=
 ioatdma 0000:00:16.0: channel enumeration error


[ =A0 =A03.505302] microcode: CPU0 sig=3D0x206c2, pf=3D0x1, revision=
=3D0x15
[ =A0 =A03.505995] ioatdma 0000:00:16.0: Intel(R) I/OAT D=
MA Engine init failed
[ =A0 =A03.506096] ioatdma 0000:00:16.1: en=
abling device (0000 -> 0002)


[ =A0 =A03.506173] ioatdma 0000:00:16.1: can't find IRQ for PCI IN=
T B; please try using pci=3Dbiosirq
[ =A0 =A03.506296] ioatdma 00=
00:00:16.1: channel error register unreachable
[ =A0 =A03.506369]=
 ioatdma 0000:00:16.1: channel enumeration error


[ =A0 =A03.506441] ioatdma 0000:00:16.1: Intel(R) I/OAT DMA Engine ini=
t failed
[ =A0 =A03.506532] ioatdma 0000:00:16.2: enabling device=
 (0000 -> 0002)
[ =A0 =A03.506608] ioatdma 0000:00:16.2: can&#=
39;t find IRQ for PCI INT C; please try using pci=3Dbiosirq


[ =A0 =A03.506722] ioatdma 0000:00:16.2: channel error register unreac=
hable
[ =A0 =A03.506795] ioatdma 0000:00:16.2: channel enumeratio=
n error
[ =A0 =A03.506867] ioatdma 0000:00:16.2: Intel(R) I/OAT D=
MA Engine init failed


[ =A0 =A03.506957] ioatdma 0000:00:16.3: enabling device (0000 -> 0=
002)
[ =A0 =A03.507034] ioatdma 0000:00:16.3: can't find IRQ =
for PCI INT D; please try using pci=3Dbiosirq
[ =A0 =A03.507147] =
ioatdma 0000:00:16.3: channel error register unreachable


[ =A0 =A03.507222] ioatdma 0000:00:16.3: channel enumeration error
[ =A0 =A03.507294] ioatdma 0000:00:16.3: Intel(R) I/OAT DMA Engine i=
nit failed
[ =A0 =A03.507398] ioatdma 0000:00:16.4: enabling devi=
ce (0000 -> 0002)


[ =A0 =A03.507476] ioatdma 0000:00:16.4: can't find IRQ for PCI IN=
T A; please try using pci=3Dbiosirq
[ =A0 =A03.507590] ioatdma 00=
00:00:16.4: channel error register unreachable
[ =A0 =A03.507663]=
 ioatdma 0000:00:16.4: channel enumeration error


[ =A0 =A03.507735] ioatdma 0000:00:16.4: Intel(R) I/OAT DMA Engine ini=
t failed
[ =A0 =A03.507826] ioatdma 0000:00:16.5: enabling device=
 (0000 -> 0002)
[ =A0 =A03.507903] ioatdma 0000:00:16.5: can&#=
39;t find IRQ for PCI INT B; please try using pci=3Dbiosirq


[ =A0 =A03.508016] ioatdma 0000:00:16.5: channel error register unreac=
hable
[ =A0 =A03.508090] ioatdma 0000:00:16.5: channel enumeratio=
n error
[ =A0 =A03.508162] ioatdma 0000:00:16.5: Intel(R) I/OAT D=
MA Engine init failed


[ =A0 =A03.508255] ioatdma 0000:00:16.6: enabling device (0000 -> 0=
002)
[ =A0 =A03.508337] ioatdma 0000:00:16.6: can't find IRQ =
for PCI INT C; please try using pci=3Dbiosirq
[ =A0 =A03.508454] =
ioatdma 0000:00:16.6: channel error register unreachable


[ =A0 =A03.508529] ioatdma 0000:00:16.6: channel enumeration error
[ =A0 =A03.508601] ioatdma 0000:00:16.6: Intel(R) I/OAT DMA Engine i=
nit failed
[ =A0 =A03.508692] ioatdma 0000:00:16.7: enabling devi=
ce (0000 -> 0002)


[ =A0 =A03.508769] ioatdma 0000:00:16.7: can't find IRQ for PCI IN=
T D; please try using pci=3Dbiosirq
[ =A0 =A03.508885] ioatdma 00=
00:00:16.7: channel error register unreachable
[ =A0 =A03.508958]=
 ioatdma 0000:00:16.7: channel enumeration error


[ =A0 =A03.509030] ioatdma 0000:00:16.7: Intel(R) I/OAT DMA Engine ini=
t failed
[ =A0 =A03.571248] usbcore: registered new interface dri=
ver usbfs
[ =A0 =A03.571330] usbcore: registered new interface dr=
iver hub


[ =A0 =A03.585483] ACPI Exception: AE_BAD_PARAMETER, Thread 1786484928=
 could not acquire Mutex [0x1] (20120711/utmutex-276)
[ =A0 =A03.=
585675] ACPI Exception: AE_BAD_PARAMETER, Thread 1786484928 could not acqui=
re Mutex [0x1] (20120711/utmutex-276)


[ =A0 =A03.590919] usbcore: registered new device driver usb
[ =A0 =A03.603433] input: PC Speaker as /devices/platform/pcspkr/input/inp=
ut0
[ =A0 =A03.604762] libata version 3.00 loaded.
[ =
=A0 =A03.607430] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI=
) Driver


[ =A0 =A03.607535] ehci_hcd 0000:00:1a.7: can't find IRQ for PCI I=
NT C; please try using pci=3Dbiosirq
[ =A0 =A03.607629] ehci_hcd =
0000:00:1a.7: Found HC with no IRQ. =A0Check BIOS/PCI 0000:00:1a.7 setup!

[ =A0 =A03.607723] ehci_hcd 0000:00:1a.7: init 0000:00:1a.7 fail, -19
=

[ =A0 =A03.607808] ehci_hcd 0000:00:1d.7: can't find IRQ for PCI I=
NT A; please try using pci=3Dbiosirq
[ =A0 =A03.607900] ehci_hcd =
0000:00:1d.7: Found HC with no IRQ. =A0Check BIOS/PCI 0000:00:1d.7 setup!

[ =A0 =A03.607994] ehci_hcd 0000:00:1d.7: init 0000:00:1d.7 fail, -19<=
/div>
[ =A0 =A03.623701] i801_smbus 0000:00:1f.3: enabling device (0140=
 -> 0143)
[ =A0 =A03.623781] i801_smbus 0000:00:1f.3: can'=
t find IRQ for PCI INT B; please try using pci=3Dbiosirq


[ =A0 =A03.623874] ACPI Exception: AE_BAD_PARAMETER, Thread 1775910976=
 could not acquire Mutex [0x1] (20120711/utmutex-276)
[ =A0 =A03.=
624093] i801_smbus 0000:00:1f.3: SMBus using PCI Interrupt
[ =A0 =
=A03.676083] ata_piix 0000:00:1f.2: version 2.13


[ =A0 =A03.676095] ata_piix 0000:00:1f.2: can't find IRQ for PCI I=
NT A; please try using pci=3Dbiosirq
[ =A0 =A03.676193] ata_piix =
0000:00:1f.2: MAP [
[ =A0 =A03.676260] =A0P0 P2 P1 P3 ]
[ =A0 =A03.676539] ata_piix 0000:00:1f.2: setting latency timer to 64

[ =A0 =A03.677344] scsi1 : ata_piix
[ =A0 =A03.677732] scsi2=
 : ata_piix
[ =A0 =A03.677862] ata1: SATA max UDMA/133 cmd 0x2118=
 ctl 0x212c bmdma 0x20f0
[ =A0 =A03.677954] ata2: SATA max UDMA/1=
33 cmd 0x2110 ctl 0x2128 bmdma 0x20f8


[ =A0 =A03.678154] gpio_ich: GPIO from 195 to 255 on gpio_ich
[ =A0 =A03.678606] ata_piix 0000:00:1f.5: can't find IRQ for PCI INT =
C; please try using pci=3Dbiosirq
[ =A0 =A03.678703] ata_piix 000=
0:00:1f.5: MAP [


[ =A0 =A03.678771] =A0P0 -- P1 -- ]
[ =A0 =A03.679046] ata_p=
iix 0000:00:1f.5: setting latency timer to 64
[ =A0 =A03.679562] =
scsi3 : ata_piix
[ =A0 =A03.680057] uhci_hcd: USB Universal Host =
Controller Interface driver


[ =A0 =A03.682601] scsi4 : ata_piix
[ =A0 =A03.682814] ata3:=
 SATA max UDMA/133 cmd 0x2108 ctl 0x2124 bmdma 0x20d0
[ =A0 =A03.=
682893] ata4: SATA max UDMA/133 cmd 0x2100 ctl 0x2120 bmdma 0x20d8
[ =A0 =A03.683028] uhci_hcd 0000:00:1a.0: can't find IRQ for PCI INT =
A; please try using pci=3Dbiosirq


[ =A0 =A03.683123] uhci_hcd 0000:00:1a.0: Found HC with no IRQ. =A0Che=
ck BIOS/PCI 0000:00:1a.0 setup!
[ =A0 =A03.683217] uhci_hcd 0000:=
00:1a.0: init 0000:00:1a.0 fail, -19
[ =A0 =A03.683300] uhci_hcd =
0000:00:1a.1: can't find IRQ for PCI INT B; please try using pci=3Dbios=
irq


[ =A0 =A03.683408] uhci_hcd 0000:00:1a.1: Found HC with no IRQ. =A0Che=
ck BIOS/PCI 0000:00:1a.1 setup!
[ =A0 =A03.683504] uhci_hcd 0000:=
00:1a.1: init 0000:00:1a.1 fail, -19
[ =A0 =A03.683588] uhci_hcd =
0000:00:1d.0: can't find IRQ for PCI INT A; please try using pci=3Dbios=
irq


[ =A0 =A03.683682] uhci_hcd 0000:00:1d.0: Found HC with no IRQ. =A0Che=
ck BIOS/PCI 0000:00:1d.0 setup!
[ =A0 =A03.683802] uhci_hcd 0000:=
00:1d.0: init 0000:00:1d.0 fail, -19
[ =A0 =A03.683933] uhci_hcd =
0000:00:1d.1: can't find IRQ for PCI INT B; please try using pci=3Dbios=
irq


[ =A0 =A03.684026] uhci_hcd 0000:00:1d.1: Found HC with no IRQ. =A0Che=
ck BIOS/PCI 0000:00:1d.1 setup!
[ =A0 =A03.684121] uhci_hcd 0000:=
00:1d.1: init 0000:00:1d.1 fail, -19
[ =A0 =A03.684201] uhci_hcd =
0000:00:1d.2: can't find IRQ for PCI INT C; please try using pci=3Dbios=
irq


[ =A0 =A03.684293] uhci_hcd 0000:00:1d.2: Found HC with no IRQ. =A0Che=
ck BIOS/PCI 0000:00:1d.2 setup!
[ =A0 =A03.684387] uhci_hcd 0000:=
00:1d.2: init 0000:00:1d.2 fail, -19
[ =A0 =A03.751594] microcode=
: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba


[ =A0 =A03.771183] iTCO_vendor_support: vendor-support=3D0
[=
 =A0 =A04.010635] ata3: SATA link down (SStatus 0 SControl 300)
[=
 =A0 =A04.022013] ata4: SATA link down (SStatus 0 SControl 300)
[=
 =A0 =A04.342660] ata2.00: SATA link down (SStatus 0 SControl 300)


[ =A0 =A04.342751] ata2.01: SATA link down (SStatus 0 SControl 300)
[ =A0 =A04.487426] ata1.00: SATA link up 1.5 Gbps (SStatus 113 SCon=
trol 300)
[ =A0 =A04.487519] ata1.01: SATA link down (SStatus 0 S=
Control 300)


[ =A0 =A04.487603] ata1.01: link offline, clearing class 3 to NONE
[ =A0 =A04.495491] ata1.00: ATAPI: IBM SATA DEVICE 81Y3657, IB01, ma=
x UDMA/33
[ =A0 =A04.511489] ata1.00: configured for UDMA/33
[ =A0 =A09.511364] ata1.00: qc timeout (cmd 0xa0)


[ =A0 =A09.511434] ata1.00: TEST_UNIT_READY failed (err_mask=3D0x5)
[ =A0 10.307422] ata1.00: SATA link up 1.5 Gbps (SStatus 113 SContr=
ol 300)
[ =A0 10.307515] ata1.01: SATA link down (SStatus 0 SCont=
rol 300)


[ =A0 10.307600] ata1.01: link offline, clearing class 3 to NONE
=

[ =A0 10.331487] ata1.00: configured for UDMA/33
[ =A0 15.33=
1361] ata1.00: qc timeout (cmd 0xa0)
[ =A0 15.331431] ata1.00: TE=
ST_UNIT_READY failed (err_mask=3D0x5)


[ =A0 15.331504] ata1.00: limiting SATA link speed to 1.5 Gbps
[ =A0 15.331574] ata1.00: limiting speed to UDMA/33:PIO3
[ =A0=
 16.127423] ata1.00: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
=


[ =A0 16.127515] ata1.01: SATA link down (SStatus 0 SControl 300)
[ =A0 16.127601] ata1.01: link offline, clearing class 3 to NONE
[ =A0 16.151487] ata1.00: configured for UDMA/33
[ =A0 21.151378=
] ata1.00: qc timeout (cmd 0xa0)


[ =A0 21.151448] ata1.00: TEST_UNIT_READY failed (err_mask=3D0x5)
[ =A0 21.151518] ata1.00: disabled
[ =A0 21.151603] ata1.00=
: hard resetting link
[ =A0 21.471351] ata1.01: hard resetting li=
nk


[ =A0 21.947430] ata1.00: SATA link up 1.5 Gbps (SStatus 113 SControl =
310)
[ =A0 21.947523] ata1.01: SATA link down (SStatus 0 SControl=
 300)
[ =A0 21.947608] ata1.01: link offline, clearing class 3 to=
 NONE


[ =A0 21.947611] ata1: EH complete
[ =A0 21.963868] iTCO_wdt=
: Intel TCO WatchDog Timer Driver v1.10
[ =A0 21.963965] iTCO_wdt=
: Found a ICH10 TCO device (Version=3D2, TCOBASE=3D0x05e0)
[ =A0 =
21.964124] iTCO_wdt: initialized. heartbeat=3D30 sec (nowayout=3D0)


[ =A0 21.997872] Error: Driver 'pcspkr' is already registered,=
 aborting...
[ =A0 22.010315] alg: No test for __gcm-aes-aesni (_=
_driver-gcm-aes-aesni)
[ =A0 22.995255] EXT4-fs (dm-0): re-mounte=
d. Opts: (null)


[ =A0 23.177611] EXT4-fs (dm-0): re-mounted. Opts: errors=3Dremount-ro=

[ =A0 23.281974] loop: module loaded
[ =A0 23.346661] =
lp: driver loaded but no devices found
[ =A0 24.043404] Adding 41=
94300k swap on /dev/mapper/xen-fw_swap. =A0Priority:-1 extents:1 across:419=
4300k=A0


[ =A0 24.347072] EXT4-fs (sda3): mounted filesystem with ordered data =
mode. Opts: (null)
[ =A0 24.386139] FAT-fs (sda2): utf8 is not a =
recommended IO charset for FAT filesystems, filesystem will be case sensiti=
ve!


[ =A0 25.140294] bnx2 0000:0b:00.0: eth0: using MSIX
[ =A0 2=
5.140439] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ =
=A0 25.181911] Bridge firewalling registered
[ =A0 25.186131] dev=
ice eth1 entered promiscuous mode


[ =A0 25.288312] bnx2 0000:0b:00.1: eth1: using MSIX
[ =A0 2=
5.288410] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[ =
=A0 25.290413] IPv6: ADDRCONF(NETDEV_UP): xenbr0: link is not ready
[ =A0 26.898999] bnx2 0000:0b:00.0: eth0: NIC Copper Link is Up, 100 Mbp=
s full duplex


[ =A0 26.899091]=A0
[ =A0 26.899222] IPv6: ADDRCONF(NETDEV_C=
HANGE): eth0: link becomes ready
[ =A0 28.981380] bnx2 0000:0b:00=
.1: eth1: NIC Copper Link is Up, 1000 Mbps full duplex
[ =A0 28.9=
81477]=A0


[ =A0 28.981613] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes rea=
dy
[ =A0 28.981698] xenbr0: port 1(eth1) entered forwarding state=

[ =A0 28.981771] xenbr0: port 1(eth1) entered forwarding state

[ =A0 28.981850] IPv6: ADDRCONF(NETDEV_CHANGE): xenbr0: link becomes r=
eady
[ =A0 33.512189] RPC: Registered named UNIX socket transport=
 module.
[ =A0 33.512281] RPC: Registered udp transport module.

[ =A0 33.512351] RPC: Registered tcp transport module.
[ =A0=
 33.512420] RPC: Registered tcp NFSv4.1 backchannel transport module.
=

[ =A0 33.533692] FS-Cache: Loaded
[ =A0 33.547314] FS-Cache:=
 Netfs 'nfs' registered for caching


[ =A0 33.579870] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
[ =A0 34.845026] nf_=
conntrack version 0.5.0 (16384 buckets, 65536 max)
[ =A0 34.85487=
0] ip_tables: (C) 2000-2006 Netfilter Core Team


[ =A0 35.475210] ppdev: user-space parallel port driver
[ =
=A0 39.140866] colord-sane[2701]: segfault at 0 ip 00007fc826bc4884 sp 0000=
7fff6a44fea0 error 4 in libc-2.13.so[7f=
c826b1f000+17d000]


[ =A0 44.011341] xenbr0: port 1(eth1) entered forwarding state


Thanks for all,
Allan Sche=
id



--bcaec5299feb5f768904cbc0bbb9--


--===============5491451415256564798==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5491451415256564798==--


From xen-devel-bounces@lists.xen.org Thu Oct 11 05:56:00 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 05:56:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMBjx-0001fv-SB; Thu, 11 Oct 2012 05:55:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TM6OU-0002GR-2N
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 00:12:54 +0000
Received: from [85.158.139.83:43474] by server-15.bemta-5.messagelabs.com id
	1B/8E-27811-50F06705; Thu, 11 Oct 2012 00:12:53 +0000
X-Env-Sender: ming.aaron.liu@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1349914371!29787880!1
X-Originating-IP: [209.85.160.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16330 invoked from network); 11 Oct 2012 00:12:52 -0000
Received: from mail-gh0-f173.google.com (HELO mail-gh0-f173.google.com)
	(209.85.160.173)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Oct 2012 00:12:52 -0000
Received: by mail-gh0-f173.google.com with SMTP id 16so375424ghy.32
	for ; Wed, 10 Oct 2012 17:12:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=from:content-type:content-transfer-encoding:subject:date:message-id
	:to:mime-version:x-mailer;
	bh=WGBFLg5J4FkM78/pM+rfIGn5x8hYmX5kfCQllXDOvVc=;
	b=L82SoNvssV49UMMm8Fiw5MFSMh9JlNgDbgJiTrumdQ7SUXsHJgUBpipHuIjKuQzOSM
	V/ck9z8NLVVZtd7FQP85UqHZaNvfySVzfy65+j07EXJKfYGy0+7tvJclDEARjuXatppi
	3z9EcxT4AuOMqAXsovIOP1eOF/Us0TZW1OdwpVp9Z0RyZ7vTZvTgsmr3WbwNvJ74IiSS
	rv/Ed+FaBgE7X/QIVtYIf16I5T985ngnW2roeTrg4n/SUvYQEiJRqNBa02t0Ir+Fim2G
	VuRryIwb1XrtrI2WLPZwCrN7NAx6G48gYHXzihpdfyCZJJ/VYnCI8Eh4A+haeaMzsvg4
	4vsA==
Received: by 10.236.145.100 with SMTP id o64mr23230273yhj.89.1349914371502;
	Wed, 10 Oct 2012 17:12:51 -0700 (PDT)
Received: from vpn-183.acis.ufl.edu (n128-227-143-169.xlate.ufl.edu.
	[128.227.143.169])
	by mx.google.com with ESMTPS id h22sm2745352yhk.13.2012.10.10.17.12.49
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 10 Oct 2012 17:12:50 -0700 (PDT)
From: Ming Liu 
Date: Wed, 10 Oct 2012 20:12:48 -0400
Message-Id: <50F4CF19-626E-4210-BA69-E03FF8D7C951@gmail.com>
To: xen-devel@lists.xen.org
Mime-Version: 1.0 (Apple Message framework v1283)
X-Mailer: Apple Mail (2.1283)
X-Mailman-Approved-At: Thu, 11 Oct 2012 05:55:25 +0000
Subject: [Xen-devel] About getting guest pfn number from virtual address
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, 
I find that the shadow page fault entry function is : sh_page_fault. 
It has three parameters: struct vcpu *v, unsigned long va and struct cpu_user_regs *regs. 

I have two questions here: 
1. The "unsigned long va" means the virtual address of the guest? 
2. How can I get the physical frame number (PFN) from this va variable? 
Thanks.

Best,
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 05:56:00 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 05:56:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMBjx-0001fv-SB; Thu, 11 Oct 2012 05:55:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TM6OU-0002GR-2N
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 00:12:54 +0000
Received: from [85.158.139.83:43474] by server-15.bemta-5.messagelabs.com id
	1B/8E-27811-50F06705; Thu, 11 Oct 2012 00:12:53 +0000
X-Env-Sender: ming.aaron.liu@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1349914371!29787880!1
X-Originating-IP: [209.85.160.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16330 invoked from network); 11 Oct 2012 00:12:52 -0000
Received: from mail-gh0-f173.google.com (HELO mail-gh0-f173.google.com)
	(209.85.160.173)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Oct 2012 00:12:52 -0000
Received: by mail-gh0-f173.google.com with SMTP id 16so375424ghy.32
	for ; Wed, 10 Oct 2012 17:12:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=from:content-type:content-transfer-encoding:subject:date:message-id
	:to:mime-version:x-mailer;
	bh=WGBFLg5J4FkM78/pM+rfIGn5x8hYmX5kfCQllXDOvVc=;
	b=L82SoNvssV49UMMm8Fiw5MFSMh9JlNgDbgJiTrumdQ7SUXsHJgUBpipHuIjKuQzOSM
	V/ck9z8NLVVZtd7FQP85UqHZaNvfySVzfy65+j07EXJKfYGy0+7tvJclDEARjuXatppi
	3z9EcxT4AuOMqAXsovIOP1eOF/Us0TZW1OdwpVp9Z0RyZ7vTZvTgsmr3WbwNvJ74IiSS
	rv/Ed+FaBgE7X/QIVtYIf16I5T985ngnW2roeTrg4n/SUvYQEiJRqNBa02t0Ir+Fim2G
	VuRryIwb1XrtrI2WLPZwCrN7NAx6G48gYHXzihpdfyCZJJ/VYnCI8Eh4A+haeaMzsvg4
	4vsA==
Received: by 10.236.145.100 with SMTP id o64mr23230273yhj.89.1349914371502;
	Wed, 10 Oct 2012 17:12:51 -0700 (PDT)
Received: from vpn-183.acis.ufl.edu (n128-227-143-169.xlate.ufl.edu.
	[128.227.143.169])
	by mx.google.com with ESMTPS id h22sm2745352yhk.13.2012.10.10.17.12.49
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 10 Oct 2012 17:12:50 -0700 (PDT)
From: Ming Liu 
Date: Wed, 10 Oct 2012 20:12:48 -0400
Message-Id: <50F4CF19-626E-4210-BA69-E03FF8D7C951@gmail.com>
To: xen-devel@lists.xen.org
Mime-Version: 1.0 (Apple Message framework v1283)
X-Mailer: Apple Mail (2.1283)
X-Mailman-Approved-At: Thu, 11 Oct 2012 05:55:25 +0000
Subject: [Xen-devel] About getting guest pfn number from virtual address
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, 
I find that the shadow page fault entry function is : sh_page_fault. 
It has three parameters: struct vcpu *v, unsigned long va and struct cpu_user_regs *regs. 

I have two questions here: 
1. The "unsigned long va" means the virtual address of the guest? 
2. How can I get the physical frame number (PFN) from this va variable? 
Thanks.

Best,
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 05:58:48 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 05:58:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMBms-0001rr-51; Thu, 11 Oct 2012 05:58:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMBmq-0001rj-9A
	for xen-devel@lists.xensource.com; Thu, 11 Oct 2012 05:58:24 +0000
Received: from [85.158.139.83:52713] by server-4.bemta-5.messagelabs.com id
	29/EC-18688-FFF56705; Thu, 11 Oct 2012 05:58:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1349935101!31493793!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM4Mjk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1004 invoked from network); 11 Oct 2012 05:58:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Oct 2012 05:58:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,570,1344211200"; d="scan'208";a="15088524"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Oct 2012 05:58:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 11 Oct 2012 06:58:21 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TMBmm-00023e-Kx;
	Thu, 11 Oct 2012 05:58:20 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TMBmm-0004Z9-H4;
	Thu, 11 Oct 2012 06:58:20 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Thu, 11 Oct 2012 06:58:20 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13951: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13951 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13951/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13950
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13950
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13950
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13950

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  3696dd6a7836
baseline version:
 xen                  3696dd6a7836

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 05:58:48 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 05:58:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMBms-0001rr-51; Thu, 11 Oct 2012 05:58:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMBmq-0001rj-9A
	for xen-devel@lists.xensource.com; Thu, 11 Oct 2012 05:58:24 +0000
Received: from [85.158.139.83:52713] by server-4.bemta-5.messagelabs.com id
	29/EC-18688-FFF56705; Thu, 11 Oct 2012 05:58:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1349935101!31493793!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM4Mjk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1004 invoked from network); 11 Oct 2012 05:58:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Oct 2012 05:58:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,570,1344211200"; d="scan'208";a="15088524"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Oct 2012 05:58:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 11 Oct 2012 06:58:21 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TMBmm-00023e-Kx;
	Thu, 11 Oct 2012 05:58:20 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TMBmm-0004Z9-H4;
	Thu, 11 Oct 2012 06:58:20 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Thu, 11 Oct 2012 06:58:20 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13951: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13951 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13951/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13950
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13950
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13950
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13950

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  3696dd6a7836
baseline version:
 xen                  3696dd6a7836

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 06:16:56 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 06:16:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMC4P-0002DS-F5; Thu, 11 Oct 2012 06:16:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMC4O-0002DA-7B
	for xen-devel@lists.xensource.com; Thu, 11 Oct 2012 06:16:32 +0000
Received: from [85.158.137.99:44364] by server-4.bemta-3.messagelabs.com id
	70/5D-01405-F3466705; Thu, 11 Oct 2012 06:16:31 +0000
X-Env-Sender: maheen_butt26@yahoo.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1349936189!21114309!1
X-Originating-IP: [98.138.91.18]
X-SpamReason: No, hits=0.7 required=7.0 tests=FROM_HAS_ULINE_NUMS,
	HTML_MESSAGE, ML_RADAR_SPEW_LINKS_12, ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2009 invoked from network); 11 Oct 2012 06:16:30 -0000
Received: from nm2-vm2.bullet.mail.ne1.yahoo.com (HELO
	nm2-vm2.bullet.mail.ne1.yahoo.com) (98.138.91.18)
	by server-16.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Oct 2012 06:16:30 -0000
Received: from [98.138.90.56] by nm2.bullet.mail.ne1.yahoo.com with NNFMP;
	11 Oct 2012 06:16:28 -0000
Received: from [98.138.87.8] by tm9.bullet.mail.ne1.yahoo.com with NNFMP;
	11 Oct 2012 06:16:28 -0000
Received: from [127.0.0.1] by omp1008.mail.ne1.yahoo.com with NNFMP;
	11 Oct 2012 06:16:28 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 306066.14389.bm@omp1008.mail.ne1.yahoo.com
Received: (qmail 79062 invoked by uid 60001); 11 Oct 2012 06:16:28 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024;
	t=1349936188; bh=64jGQZ7aQr17s8kNY+UFiYlChbVcg1r3dbQ3mWXHIjc=;
	h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type;
	b=ED7lazUYhQBu63mPxgGo78TnOFIrhjV/mPFalbqS0LeB65NKJwOGTzAL6OHZh8Xx/fX29a6qVPCyLNis7yfoBrLcWKOAC7vvphh2cmZ3+4T+reTxDbU9oXNncYXotK5hg6RIhiGiyHNkm3y2pUKAxEj1yLcD6ANMn1el0AlBqAA=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type;
	b=HxtLc1cKmkPxtpms9tDdUltZ1GIGZ+GRFKKwjPmhvdoyIXJbSvVfokbOD/RvCYdE4Nl3N/uYFrN/tHXNmgXppQLmDxanPuuxGX5cW6ihxGOEVPJf0mnPS08SKUZNRHEEnZ4QPa/jp5v26igfanlBmZB74n/9eBizSV0GNvJibUs=;
X-YMail-OSG: umkWMKwVM1mnTzGAQ8AQQCggbjtYTA0EhwzgSxi9Ft6bGUY
	4.kamyMwn2Xk27VVXDQAkr2G7MKsz7d82XucBjuqQD7WJ9v_rodaRwaSyp.4
	7kIZvDNdY44zNFRivyWo64wPXgKkMC5QNojaR43VGxVwJyBC.3AgoPDVytLr
	GY4egg0jnPeKDUxDhr.O3zEiHV.07fXDUGDkqYwPCU_TQRbB31c0upKC3eQT
	St6UX6KU9CU8SAV6UwoBs5LU.Wr7uohCe6ViNn7Sq9RpHvAIhXgJn70VzSo1
	uZmNkvtsm3.rjGY0OzsBymfUJu3JuAx8U7ImnD7qHc1rUPiKsAAo2DwrGaX3
	bNJRwl0QwDKaDyhTUQcmWqDt9Y0N1cRxEms5azkDds.HxYUb1ACafPjkNvQg
	pWdxv5rp3ydD9qfvDqNnMrT8c1F3dqtM2Zn0CYXYDoTvIPxudsCPWVX1lRvw
	8LDRvATq.6yhv9456od5kELeW32MG_aBmPFBf8Lct2YVwCLlXQFG2dg--
Received: from [111.68.102.23] by web120006.mail.ne1.yahoo.com via HTTP;
	Wed, 10 Oct 2012 23:16:28 PDT
X-Rocket-MIMEInfo: 001.001,
	SGkgYWxsLAoKSSdtIGludmVzdGlnYXRpbmcgdGhlIHNvdXJjZSBjb2RlIG9mIFhlbmlmaWVkIGtlcm5lbC4gRnJvbSBkb2N1bWVudGF0aW9ucyByZWxhdGVkIHRvIAoKWGVuIHRvbGQgbWUgdGhhdCBhbGwgZ3Vlc3QgZG9tYWlucyBydW4gaW4gbGVzcyBwcml2aWxlZ2UgbW9kZSAoIHJpbmcgMSBpbiBjYXNlIG9mIHg4NikuCkRvbTAgaXMgYWxzbyBydW5uaW5nIGluIHJpbmcgMS4gQnV0IGl0IGNhbiBoYXZlIGRpcmVjdCBhY2Nlc3MgdG8gSU8gZGV2aWNlcy4gSXQgbWVhbnMgCgpEb20wIGhhcyBhIHNwZWNpYWwBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.123.450
Message-ID: <1349936188.70593.YahooMailNeo@web120006.mail.ne1.yahoo.com>
Date: Wed, 10 Oct 2012 23:16:28 -0700 (PDT)
From: maheen butt 
To: "xen-users@lists.xen.org" ,
	"xen-devel@lists.xensource.com" 
MIME-Version: 1.0
Subject: [Xen-devel] Dom0 IO handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: maheen butt 
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0970932086661697980=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0970932086661697980==
Content-Type: multipart/alternative; boundary="1454997657-1713095224-1349936188=:70593"

--1454997657-1713095224-1349936188=:70593
Content-Type: text/plain; charset=us-ascii

Hi all,

I'm investigating the source code of Xenified kernel. From documentations related to 

Xen told me that all guest domains run in less privilege mode ( ring 1 in case of x86).
Dom0 is also running in ring 1. But it can have direct access to IO devices. It means 

Dom0 has a special bahaviour that it is running in ring1 but can directly access IO devices.
How Dom0 access IO devices directly?
how can I relate this special way of Dom0 with its source code?

--1454997657-1713095224-1349936188=:70593
Content-Type: text/html; charset=us-ascii


Hi all,

I'm investigating the source code of Xenified kernel. From documentations related to 
Xen told me that all guest domains run in less privilege mode ( ring 1 in case of x86).
Dom0 is also running in ring 1. But it can have direct access to IO devices. It means 
Dom0 has a special bahaviour that it is running in ring1 but can directly access IO devices.
How Dom0 access IO devices directly?
 how can I relate this special way of Dom0 with its source code?

--1454997657-1713095224-1349936188=:70593--


--===============0970932086661697980==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0970932086661697980==--


From xen-devel-bounces@lists.xen.org Thu Oct 11 06:16:56 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 06:16:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMC4P-0002DS-F5; Thu, 11 Oct 2012 06:16:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMC4O-0002DA-7B
	for xen-devel@lists.xensource.com; Thu, 11 Oct 2012 06:16:32 +0000
Received: from [85.158.137.99:44364] by server-4.bemta-3.messagelabs.com id
	70/5D-01405-F3466705; Thu, 11 Oct 2012 06:16:31 +0000
X-Env-Sender: maheen_butt26@yahoo.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1349936189!21114309!1
X-Originating-IP: [98.138.91.18]
X-SpamReason: No, hits=0.7 required=7.0 tests=FROM_HAS_ULINE_NUMS,
	HTML_MESSAGE, ML_RADAR_SPEW_LINKS_12, ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2009 invoked from network); 11 Oct 2012 06:16:30 -0000
Received: from nm2-vm2.bullet.mail.ne1.yahoo.com (HELO
	nm2-vm2.bullet.mail.ne1.yahoo.com) (98.138.91.18)
	by server-16.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Oct 2012 06:16:30 -0000
Received: from [98.138.90.56] by nm2.bullet.mail.ne1.yahoo.com with NNFMP;
	11 Oct 2012 06:16:28 -0000
Received: from [98.138.87.8] by tm9.bullet.mail.ne1.yahoo.com with NNFMP;
	11 Oct 2012 06:16:28 -0000
Received: from [127.0.0.1] by omp1008.mail.ne1.yahoo.com with NNFMP;
	11 Oct 2012 06:16:28 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 306066.14389.bm@omp1008.mail.ne1.yahoo.com
Received: (qmail 79062 invoked by uid 60001); 11 Oct 2012 06:16:28 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024;
	t=1349936188; bh=64jGQZ7aQr17s8kNY+UFiYlChbVcg1r3dbQ3mWXHIjc=;
	h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type;
	b=ED7lazUYhQBu63mPxgGo78TnOFIrhjV/mPFalbqS0LeB65NKJwOGTzAL6OHZh8Xx/fX29a6qVPCyLNis7yfoBrLcWKOAC7vvphh2cmZ3+4T+reTxDbU9oXNncYXotK5hg6RIhiGiyHNkm3y2pUKAxEj1yLcD6ANMn1el0AlBqAA=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type;
	b=HxtLc1cKmkPxtpms9tDdUltZ1GIGZ+GRFKKwjPmhvdoyIXJbSvVfokbOD/RvCYdE4Nl3N/uYFrN/tHXNmgXppQLmDxanPuuxGX5cW6ihxGOEVPJf0mnPS08SKUZNRHEEnZ4QPa/jp5v26igfanlBmZB74n/9eBizSV0GNvJibUs=;
X-YMail-OSG: umkWMKwVM1mnTzGAQ8AQQCggbjtYTA0EhwzgSxi9Ft6bGUY
	4.kamyMwn2Xk27VVXDQAkr2G7MKsz7d82XucBjuqQD7WJ9v_rodaRwaSyp.4
	7kIZvDNdY44zNFRivyWo64wPXgKkMC5QNojaR43VGxVwJyBC.3AgoPDVytLr
	GY4egg0jnPeKDUxDhr.O3zEiHV.07fXDUGDkqYwPCU_TQRbB31c0upKC3eQT
	St6UX6KU9CU8SAV6UwoBs5LU.Wr7uohCe6ViNn7Sq9RpHvAIhXgJn70VzSo1
	uZmNkvtsm3.rjGY0OzsBymfUJu3JuAx8U7ImnD7qHc1rUPiKsAAo2DwrGaX3
	bNJRwl0QwDKaDyhTUQcmWqDt9Y0N1cRxEms5azkDds.HxYUb1ACafPjkNvQg
	pWdxv5rp3ydD9qfvDqNnMrT8c1F3dqtM2Zn0CYXYDoTvIPxudsCPWVX1lRvw
	8LDRvATq.6yhv9456od5kELeW32MG_aBmPFBf8Lct2YVwCLlXQFG2dg--
Received: from [111.68.102.23] by web120006.mail.ne1.yahoo.com via HTTP;
	Wed, 10 Oct 2012 23:16:28 PDT
X-Rocket-MIMEInfo: 001.001,
	SGkgYWxsLAoKSSdtIGludmVzdGlnYXRpbmcgdGhlIHNvdXJjZSBjb2RlIG9mIFhlbmlmaWVkIGtlcm5lbC4gRnJvbSBkb2N1bWVudGF0aW9ucyByZWxhdGVkIHRvIAoKWGVuIHRvbGQgbWUgdGhhdCBhbGwgZ3Vlc3QgZG9tYWlucyBydW4gaW4gbGVzcyBwcml2aWxlZ2UgbW9kZSAoIHJpbmcgMSBpbiBjYXNlIG9mIHg4NikuCkRvbTAgaXMgYWxzbyBydW5uaW5nIGluIHJpbmcgMS4gQnV0IGl0IGNhbiBoYXZlIGRpcmVjdCBhY2Nlc3MgdG8gSU8gZGV2aWNlcy4gSXQgbWVhbnMgCgpEb20wIGhhcyBhIHNwZWNpYWwBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.123.450
Message-ID: <1349936188.70593.YahooMailNeo@web120006.mail.ne1.yahoo.com>
Date: Wed, 10 Oct 2012 23:16:28 -0700 (PDT)
From: maheen butt 
To: "xen-users@lists.xen.org" ,
	"xen-devel@lists.xensource.com" 
MIME-Version: 1.0
Subject: [Xen-devel] Dom0 IO handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: maheen butt 
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0970932086661697980=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0970932086661697980==
Content-Type: multipart/alternative; boundary="1454997657-1713095224-1349936188=:70593"

--1454997657-1713095224-1349936188=:70593
Content-Type: text/plain; charset=us-ascii

Hi all,

I'm investigating the source code of Xenified kernel. From documentations related to 

Xen told me that all guest domains run in less privilege mode ( ring 1 in case of x86).
Dom0 is also running in ring 1. But it can have direct access to IO devices. It means 

Dom0 has a special bahaviour that it is running in ring1 but can directly access IO devices.
How Dom0 access IO devices directly?
how can I relate this special way of Dom0 with its source code?

--1454997657-1713095224-1349936188=:70593
Content-Type: text/html; charset=us-ascii


Hi all,

I'm investigating the source code of Xenified kernel. From documentations related to 
Xen told me that all guest domains run in less privilege mode ( ring 1 in case of x86).
Dom0 is also running in ring 1. But it can have direct access to IO devices. It means 
Dom0 has a special bahaviour that it is running in ring1 but can directly access IO devices.
How Dom0 access IO devices directly?
 how can I relate this special way of Dom0 with its source code?

--1454997657-1713095224-1349936188=:70593--


--===============0970932086661697980==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0970932086661697980==--


From xen-devel-bounces@lists.xen.org Thu Oct 11 07:07:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 07:07:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMCqt-00033i-RT; Thu, 11 Oct 2012 07:06:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMCqr-00033d-NZ
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 07:06:37 +0000
Received: from [85.158.139.83:37147] by server-10.bemta-5.messagelabs.com id
	A8/31-06995-CFF66705; Thu, 11 Oct 2012 07:06:36 +0000
X-Env-Sender: singapore.mr.teo.en.ming@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1349939194!31502323!1
X-Originating-IP: [209.85.210.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24280 invoked from network); 11 Oct 2012 07:06:36 -0000
Received: from mail-da0-f45.google.com (HELO mail-da0-f45.google.com)
	(209.85.210.45)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Oct 2012 07:06:36 -0000
Received: by mail-da0-f45.google.com with SMTP id n15so614107dad.32
	for ; Thu, 11 Oct 2012 00:06:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:subject
	:content-type:content-transfer-encoding;
	bh=RanAG/226a5w+kyXECucaUjctQS9Kvs6GmegWN1Zk60=;
	b=OBAflqDo5HNfIiRa2ySDww9g7rQegCtCwA0ybbKR9SiwA19c+n1lgTGpFQf4+ATIRU
	6JPwP3V05bM6raoGoqf6jGrrOEY6SKiYiBjxb+xI9EvNEEEQfhTHH+euXy3YbqVIFtWU
	Dn8WanwHcdA9FMs/tpb3q0oolYiwgU+aI4cZuUvYsfJ63hJvxihWWOA1fFQQaG82BoZb
	+MnumfMFbujyqarK5fEi6tRTn1+WuM9zGqrqb4qKqKBetaR0M2Mu1ByKVoTU83d6szSj
	540XLxCC4YF83fkCEEMMzQGxef2FqUVLFn125uCXV2hNpsWpscDNSRHfyEG5aiUoouVh
	sdBw==
Received: by 10.68.136.138 with SMTP id qa10mr815056pbb.142.1349939194228;
	Thu, 11 Oct 2012 00:06:34 -0700 (PDT)
Received: from [192.168.1.2] (cm152.gamma205.maxonline.com.sg.
	[202.156.205.152])
	by mx.google.com with ESMTPS id vz8sm2290191pbc.63.2012.10.11.00.06.31
	(version=SSLv3 cipher=OTHER); Thu, 11 Oct 2012 00:06:33 -0700 (PDT)
Message-ID: <50766FF6.2000407@gmail.com>
Date: Thu, 11 Oct 2012 15:06:30 +0800
From: "Teo En Ming (Zhang Enming)" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" , 
	"Teo En Ming (Zhang Enming)" 
Subject: [Xen-devel] Are there any NVIDIA engineers in xen-devel mailing
	list?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

Are there any NVIDIA engineers in xen-devel mailing list? Please 
respond. I need your help.

Thank you very much.

-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 07:07:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 07:07:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMCqt-00033i-RT; Thu, 11 Oct 2012 07:06:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMCqr-00033d-NZ
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 07:06:37 +0000
Received: from [85.158.139.83:37147] by server-10.bemta-5.messagelabs.com id
	A8/31-06995-CFF66705; Thu, 11 Oct 2012 07:06:36 +0000
X-Env-Sender: singapore.mr.teo.en.ming@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1349939194!31502323!1
X-Originating-IP: [209.85.210.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24280 invoked from network); 11 Oct 2012 07:06:36 -0000
Received: from mail-da0-f45.google.com (HELO mail-da0-f45.google.com)
	(209.85.210.45)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Oct 2012 07:06:36 -0000
Received: by mail-da0-f45.google.com with SMTP id n15so614107dad.32
	for ; Thu, 11 Oct 2012 00:06:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:subject
	:content-type:content-transfer-encoding;
	bh=RanAG/226a5w+kyXECucaUjctQS9Kvs6GmegWN1Zk60=;
	b=OBAflqDo5HNfIiRa2ySDww9g7rQegCtCwA0ybbKR9SiwA19c+n1lgTGpFQf4+ATIRU
	6JPwP3V05bM6raoGoqf6jGrrOEY6SKiYiBjxb+xI9EvNEEEQfhTHH+euXy3YbqVIFtWU
	Dn8WanwHcdA9FMs/tpb3q0oolYiwgU+aI4cZuUvYsfJ63hJvxihWWOA1fFQQaG82BoZb
	+MnumfMFbujyqarK5fEi6tRTn1+WuM9zGqrqb4qKqKBetaR0M2Mu1ByKVoTU83d6szSj
	540XLxCC4YF83fkCEEMMzQGxef2FqUVLFn125uCXV2hNpsWpscDNSRHfyEG5aiUoouVh
	sdBw==
Received: by 10.68.136.138 with SMTP id qa10mr815056pbb.142.1349939194228;
	Thu, 11 Oct 2012 00:06:34 -0700 (PDT)
Received: from [192.168.1.2] (cm152.gamma205.maxonline.com.sg.
	[202.156.205.152])
	by mx.google.com with ESMTPS id vz8sm2290191pbc.63.2012.10.11.00.06.31
	(version=SSLv3 cipher=OTHER); Thu, 11 Oct 2012 00:06:33 -0700 (PDT)
Message-ID: <50766FF6.2000407@gmail.com>
Date: Thu, 11 Oct 2012 15:06:30 +0800
From: "Teo En Ming (Zhang Enming)" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" , 
	"Teo En Ming (Zhang Enming)" 
Subject: [Xen-devel] Are there any NVIDIA engineers in xen-devel mailing
	list?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

Are there any NVIDIA engineers in xen-devel mailing list? Please 
respond. I need your help.

Thank you very much.

-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 07:25:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 07:25:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMD94-0003Eb-TB; Thu, 11 Oct 2012 07:25:26 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMD93-0003ET-6Y; Thu, 11 Oct 2012 07:25:25 +0000
X-Env-Sender: singapore.mr.teo.en.ming@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1349940315!9537174!1
X-Originating-IP: [209.85.220.45]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14575 invoked from network); 11 Oct 2012 07:25:17 -0000
Received: from mail-pa0-f45.google.com (HELO mail-pa0-f45.google.com)
	(209.85.220.45)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Oct 2012 07:25:17 -0000
Received: by mail-pa0-f45.google.com with SMTP id fb10so1478084pad.32
	for ; Thu, 11 Oct 2012 00:25:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:subject
	:content-type; bh=gnb8r2fREBkSS2g7MPIWofdcxgc9HBQqgDRARfNn604=;
	b=0pC7EeaGLIzU8U8x3DA+vKt0I2DgbnP+MubVN1Y8Aa5iSKCqbFVsVe9iVkk6vaFghF
	p+4iJ+SfX4kBUaJgg0D4q3KcUzJdMWX7DpzQ1oD5OCn+0yiMFptmqwWxM8ylvcxiV7zp
	xkiJK60nkIcyVy9OgKsmUkHeNfyzvT/k+KKrGcDdgniCxgg55MNAxTGbNsC/VbU4nQNt
	rw+QDAPjKOi3+pNDbTmLxB5jCL7aVQxF+iS67NambzjWu5MbEiwxwct3s0YCNLZ81k/8
	hONyqv4bBMGwXdIm9deDtgHVoyVla0D0/o1P/pZpcNNjCPuMb4s59it+zObhHjIv0bsl
	qElg==
Received: by 10.68.136.138 with SMTP id qa10mr944767pbb.142.1349940315369;
	Thu, 11 Oct 2012 00:25:15 -0700 (PDT)
Received: from [192.168.1.2] (cm152.gamma205.maxonline.com.sg.
	[202.156.205.152])
	by mx.google.com with ESMTPS id ky6sm2323809pbc.18.2012.10.11.00.25.12
	(version=SSLv3 cipher=OTHER); Thu, 11 Oct 2012 00:25:14 -0700 (PDT)
Message-ID: <50767457.1020000@gmail.com>
Date: Thu, 11 Oct 2012 15:25:11 +0800
From: "Teo En Ming (Zhang Enming)" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: "xen-users@lists.xen.org" , 
	"xen-devel@lists.xen.org" ,
	"Teo En Ming (Zhang Enming)" , 
	Frank Lyon 
Subject: [Xen-devel] I am offering a reward of USD$100 to anyone who could
 solve my Xen VGA Passthrough problem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1892417179761918824=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============1892417179761918824==
Content-Type: multipart/alternative;
 boundary="------------060801040806020703090407"

This is a multi-part message in MIME format.
--------------060801040806020703090407
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

_History_

I have 100% success in Xen VGA Passthrough with Xen 3.5-unstable with my 
first Palit NVIDIA Geforce 8400 GS VGA card in 2009, which is 3 years 
ago. Then my first Palit NVIDIA Geforce 8400 GS VGA card overheated and 
malfunctioned. So I bought a 2nd Palit NVIDIA Geforce 8400 GS VGA card 
several months ago in March 2012 for S$44, to replace the first card. At 
that point in time, Xen was already of version 4.2-unstable. I have 
tried to passthrough my 2nd Palit NVIDIA Geforce 8400 GS, which is only 
partially working, or partial success. _In Windows 8 HVM domU, you will 
see a yellow triangle with exclamation mark and error code 43 in Device 
Manager for the 2nd Palit NVIDIA Geforce 8400 GS. In Windows XP Home 
Edition HVM domU, you will see a yellow circle with exclamation mark and 
error code 10 in Device Manager for the 2nd Palit NVIDIA Geforce 8400 GS._

Then I noticed Jean David Techer uses a Geforce 560 Ti for his Xen VGA 
Passthrough. So 1-2 weeks ago I bought a EVGA Geforce GTX 560 1 GB GDDR5 
for S$269. Same thing. Xen VGA Passthrough is only partially working or 
partial success. So I went back to the computer shop and exchanged my 
EVGA Geforce GTX 560 with a Gigabyte Geforce GTX 560 1 GB GDDR5, which 
costs S$289. Again, Xen VGA Passthrough is only partially working or 
partial success. _In Windows 8 HVM domU, you will see a yellow triangle 
with exclamation mark and error code 43 in Device Manager for the 
Gigabyte Geforce GTX 560. In Windows XP Home Edition HVM domU, you will 
see a yellow circle with exclamation mark and error code 10 in Device 
Manager for the Gigabyte Geforce GTX 560._

_The Challenge_

My computer hardware specifications:

Processor: Intel Pentium Dual Core E2300 @ 2.8 GHz
Motherboard: Intel DQ45CB Desktop Board with VT-d enabled
VGA Card: Gigabyte Geforce GTX 560 1 GB GDDR5
Memory: 6 GB

My computer software specifications:

Host operating system: Ubuntu 12.04.1 LTS SERVER EDITION
Xen Hypervisor version: (a) Xen 4.2-unstable Changeset 25099 (b) Xen 
4.2.1-pre (c) Xen 4.3-unstable Changeset 25993
Linux Dom0 Kernel: (a) 3.5.4 (b) 3.6.0-rc7 (c) 3.6.1
Windows HVM domU: (a) Windows XP Home Edition SP3 (b) Windows 8 Release 
Preview 64-bit (c) Windows 7 Ultimate Evaluation Copy

Manuals which I have followed in getting Xen VGA Passthrough done:

(1) 
http://wiki.xen.org/wiki/Building_and_Installing_Xen_4.x_and_Linux_Kernel_3.x_on_Ubuntu_and_Debian_Linux

(2) 
http://wiki.xen.org/wiki/Xen_VGA_Passthrough_to_Windows_8_with_Xen_4.2-unstable

The above 2 are manuals which I have written myself, after studying 
several Xen Wiki Pages and Jean David Techer's notes.

Now, the above 2 manuals are the same manuals which I have used to 
obtain 100% success in Xen VGA Passthrough for Frank Lyon's NVIDIA 
Quadro 6000. Yes, 100% success. Absolutely no yellow triangle with 
exclamation mark and error code 43 in Windows 7 and Windows 8 HVM domU. 
It is an irony and a joke that, with the same set of manuals which I 
have written, I cannot get 100% success in Xen VGA Passthrough with my 
very own display cards. Frank Lyon's NVIDIA Quadro 6000 costs S$6000++, 
and I can't afford it.

So now, the problem stands. I get a yellow triangle with exclamation 
mark and error code 43 in device manager for Gigabyte Geforce GTX 560 in 
Windows 8 HVM domU and a yellow circle with exclamation mark and error 
code 10 in device manager for Gigabyte Geforce GTX 560 in Windows XP 
Home Edition HVM domU.

_The Reward__or Prize Money_

1. USD$100 in cash


_How to Get the Reward_

If I can say that you have solved my Xen VGA Passthrough problem 100%, 
you get the reward! Basically, the idea is to get rid of the yellow 
triangle with exclamation mark and error code 43 in Windows 8 HVM domU 
and the yellow circle with exclamation mark and error code 10 in Windows 
XP HVM domU.

Hence,

(1) If you can tell me off-hand the solution which leads to my Xen VGA 
Passthrough problem being solved 100%, you get the reward. OR

(2) You have spotted mistakes or errors in the manuals which I have 
written, leading to my Xen VGA Passthrough problem being solved 100%. 
You get the reward. OR

(3) If you have a VT-d capable motherboard and processor, and a 
compatible NVIDIA Geforce GTX 560 like mine, and follow the 2 manuals 
which I have written for your Xen VGA Passthrough needs. If you can 
obtain 100% success, please tell me the mistakes or errors in my 
manuals, which leads to my Xen VGA Passthrough problem being solved 
100%. You get the reward.

*_100% success means no error code 43 and no error code 10._*

For a start, you may follow the thread series "*Help Needed from Xen 
Developers: Nasty Yellow Triangle with Exclamation Mark and Error Code 
43 in Device Manager in Windows 8 HVM domU 
" in 
the xen-users and xen-devel mailing lists.*

Please note that the prize money of US$100 is guaranteed and there is 
only one winner. There is no closing date for this challenge.


-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore


--------------060801040806020703090407
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    History

    

    I have 100% success in Xen VGA Passthrough with Xen 3.5-unstable
    with my first Palit NVIDIA Geforce 8400 GS VGA card in 2009, which
    is 3 years ago. Then my first Palit NVIDIA Geforce 8400 GS VGA card
    overheated and malfunctioned. So I bought a 2nd Palit NVIDIA Geforce
    8400 GS VGA card several months ago in March 2012 for S$44, to
    replace the first card. At that point in time, Xen was already of
    version 4.2-unstable. I have tried to passthrough my 2nd Palit
    NVIDIA Geforce 8400 GS, which is only partially working, or partial
    success. In Windows 8 HVM domU, you will see a yellow triangle
      with exclamation mark and error code 43 in Device Manager for the
      2nd Palit NVIDIA Geforce 8400 GS. In Windows XP Home Edition HVM
      domU, you will see a yellow circle with exclamation mark and error
      code 10 in Device Manager for the 2nd Palit NVIDIA Geforce 8400
      GS.

    

    Then I noticed Jean David Techer uses a Geforce 560 Ti for his Xen
    VGA Passthrough. So 1-2 weeks ago I bought a EVGA Geforce GTX 560 1
    GB GDDR5 for S$269. Same thing. Xen VGA Passthrough is only
    partially working or partial success. So I went back to the computer
    shop and exchanged my EVGA Geforce GTX 560 with a Gigabyte Geforce
    GTX 560 1 GB GDDR5, which costs S$289. Again, Xen VGA Passthrough is
    only partially working or partial success. In Windows 8 HVM
      domU, you will see a yellow triangle with exclamation mark and
      error code 43 in Device Manager for the Gigabyte Geforce GTX 560.
      In Windows XP Home Edition HVM domU, you will see a yellow circle
      with exclamation mark and error code 10 in Device Manager for the
      Gigabyte Geforce GTX 560.

    

    The Challenge

    

    My computer hardware specifications:

    

    Processor: Intel Pentium Dual Core E2300 @ 2.8 GHz

    Motherboard: Intel DQ45CB Desktop Board with VT-d enabled

    VGA Card: Gigabyte Geforce GTX 560 1 GB GDDR5

    Memory: 6 GB

    

    My computer software specifications:

    

    Host operating system: Ubuntu 12.04.1 LTS SERVER EDITION

    Xen Hypervisor version: (a) Xen 4.2-unstable Changeset 25099 (b) Xen
    4.2.1-pre (c) Xen 4.3-unstable Changeset 25993

    Linux Dom0 Kernel: (a) 3.5.4 (b) 3.6.0-rc7 (c) 3.6.1

    Windows HVM domU: (a) Windows XP Home Edition SP3 (b) Windows 8
    Release Preview 64-bit (c) Windows 7 Ultimate Evaluation Copy

    

    Manuals which I have followed in getting Xen VGA Passthrough done:

    

    (1)
    http://wiki.xen.org/wiki/Building_and_Installing_Xen_4.x_and_Linux_Kernel_3.x_on_Ubuntu_and_Debian_Linux

    

    (2)
    http://wiki.xen.org/wiki/Xen_VGA_Passthrough_to_Windows_8_with_Xen_4.2-unstable

    

    The above 2 are manuals which I have written myself, after studying
    several Xen Wiki Pages and Jean David Techer's notes.

    

    Now, the above 2 manuals are the same manuals which I have used to
    obtain 100% success in Xen VGA Passthrough for Frank Lyon's NVIDIA
    Quadro 6000. Yes, 100% success. Absolutely no yellow triangle with
    exclamation mark and error code 43 in Windows 7 and Windows 8 HVM
    domU. It is an irony and a joke that, with the same set of manuals
    which I have written, I cannot get 100% success in Xen VGA
    Passthrough with my very own display cards. Frank Lyon's NVIDIA
    Quadro 6000 costs S$6000++, and I can't afford it. 

    

    So now, the problem stands. I get a yellow triangle with exclamation
    mark and error code 43 in device manager for Gigabyte Geforce GTX
    560 in Windows 8 HVM domU and a yellow circle with exclamation mark
    and error code 10 in device manager for Gigabyte Geforce GTX 560 in
    Windows XP Home Edition HVM domU.

    

    The Reward or Prize Money

    

    1. USD$100 in cash

    

    

    How to Get the Reward

    

    If I can say that you have solved my Xen VGA Passthrough problem
    100%, you get the reward! Basically, the idea is to get rid of the
    yellow triangle with exclamation mark and error code 43 in Windows 8
    HVM domU and the yellow circle with exclamation mark and error code
    10 in Windows XP HVM domU.

    

    Hence,

    

    (1) If you can tell me off-hand the solution which leads to my Xen
    VGA Passthrough problem being solved 100%, you get the reward. OR

    

    (2) You have spotted mistakes or errors in the manuals which I have
    written, leading to my Xen VGA Passthrough problem being solved
    100%. You get the reward. OR

    

    (3) If you have a VT-d capable motherboard and processor, and a
    compatible NVIDIA Geforce GTX 560 like mine, and follow the 2
    manuals which I have written for your Xen VGA Passthrough needs. If
    you can obtain 100% success, please tell me the mistakes or errors
    in my manuals, which leads to my Xen VGA Passthrough problem being
    solved 100%. You get the reward.

    

    100% success means no error code 43 and no error code 10.

    

    For a start, you may follow the thread series "Help


        Needed from Xen Developers: Nasty Yellow Triangle with
        Exclamation Mark and Error Code 43 in Device Manager in Windows
        8 HVM domU" in the xen-users and xen-devel mailing lists.

    

    Please note that the prize money of US$100 is guaranteed and there
    is only one winner. There is no closing date for this challenge.

    

    

    
-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore

  


--------------060801040806020703090407--


--===============1892417179761918824==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1892417179761918824==--


From xen-devel-bounces@lists.xen.org Thu Oct 11 07:25:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 07:25:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMD94-0003Eb-TB; Thu, 11 Oct 2012 07:25:26 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMD93-0003ET-6Y; Thu, 11 Oct 2012 07:25:25 +0000
X-Env-Sender: singapore.mr.teo.en.ming@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1349940315!9537174!1
X-Originating-IP: [209.85.220.45]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14575 invoked from network); 11 Oct 2012 07:25:17 -0000
Received: from mail-pa0-f45.google.com (HELO mail-pa0-f45.google.com)
	(209.85.220.45)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Oct 2012 07:25:17 -0000
Received: by mail-pa0-f45.google.com with SMTP id fb10so1478084pad.32
	for ; Thu, 11 Oct 2012 00:25:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:subject
	:content-type; bh=gnb8r2fREBkSS2g7MPIWofdcxgc9HBQqgDRARfNn604=;
	b=0pC7EeaGLIzU8U8x3DA+vKt0I2DgbnP+MubVN1Y8Aa5iSKCqbFVsVe9iVkk6vaFghF
	p+4iJ+SfX4kBUaJgg0D4q3KcUzJdMWX7DpzQ1oD5OCn+0yiMFptmqwWxM8ylvcxiV7zp
	xkiJK60nkIcyVy9OgKsmUkHeNfyzvT/k+KKrGcDdgniCxgg55MNAxTGbNsC/VbU4nQNt
	rw+QDAPjKOi3+pNDbTmLxB5jCL7aVQxF+iS67NambzjWu5MbEiwxwct3s0YCNLZ81k/8
	hONyqv4bBMGwXdIm9deDtgHVoyVla0D0/o1P/pZpcNNjCPuMb4s59it+zObhHjIv0bsl
	qElg==
Received: by 10.68.136.138 with SMTP id qa10mr944767pbb.142.1349940315369;
	Thu, 11 Oct 2012 00:25:15 -0700 (PDT)
Received: from [192.168.1.2] (cm152.gamma205.maxonline.com.sg.
	[202.156.205.152])
	by mx.google.com with ESMTPS id ky6sm2323809pbc.18.2012.10.11.00.25.12
	(version=SSLv3 cipher=OTHER); Thu, 11 Oct 2012 00:25:14 -0700 (PDT)
Message-ID: <50767457.1020000@gmail.com>
Date: Thu, 11 Oct 2012 15:25:11 +0800
From: "Teo En Ming (Zhang Enming)" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: "xen-users@lists.xen.org" , 
	"xen-devel@lists.xen.org" ,
	"Teo En Ming (Zhang Enming)" , 
	Frank Lyon 
Subject: [Xen-devel] I am offering a reward of USD$100 to anyone who could
 solve my Xen VGA Passthrough problem
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1892417179761918824=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============1892417179761918824==
Content-Type: multipart/alternative;
 boundary="------------060801040806020703090407"

This is a multi-part message in MIME format.
--------------060801040806020703090407
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

_History_

I have 100% success in Xen VGA Passthrough with Xen 3.5-unstable with my 
first Palit NVIDIA Geforce 8400 GS VGA card in 2009, which is 3 years 
ago. Then my first Palit NVIDIA Geforce 8400 GS VGA card overheated and 
malfunctioned. So I bought a 2nd Palit NVIDIA Geforce 8400 GS VGA card 
several months ago in March 2012 for S$44, to replace the first card. At 
that point in time, Xen was already of version 4.2-unstable. I have 
tried to passthrough my 2nd Palit NVIDIA Geforce 8400 GS, which is only 
partially working, or partial success. _In Windows 8 HVM domU, you will 
see a yellow triangle with exclamation mark and error code 43 in Device 
Manager for the 2nd Palit NVIDIA Geforce 8400 GS. In Windows XP Home 
Edition HVM domU, you will see a yellow circle with exclamation mark and 
error code 10 in Device Manager for the 2nd Palit NVIDIA Geforce 8400 GS._

Then I noticed Jean David Techer uses a Geforce 560 Ti for his Xen VGA 
Passthrough. So 1-2 weeks ago I bought a EVGA Geforce GTX 560 1 GB GDDR5 
for S$269. Same thing. Xen VGA Passthrough is only partially working or 
partial success. So I went back to the computer shop and exchanged my 
EVGA Geforce GTX 560 with a Gigabyte Geforce GTX 560 1 GB GDDR5, which 
costs S$289. Again, Xen VGA Passthrough is only partially working or 
partial success. _In Windows 8 HVM domU, you will see a yellow triangle 
with exclamation mark and error code 43 in Device Manager for the 
Gigabyte Geforce GTX 560. In Windows XP Home Edition HVM domU, you will 
see a yellow circle with exclamation mark and error code 10 in Device 
Manager for the Gigabyte Geforce GTX 560._

_The Challenge_

My computer hardware specifications:

Processor: Intel Pentium Dual Core E2300 @ 2.8 GHz
Motherboard: Intel DQ45CB Desktop Board with VT-d enabled
VGA Card: Gigabyte Geforce GTX 560 1 GB GDDR5
Memory: 6 GB

My computer software specifications:

Host operating system: Ubuntu 12.04.1 LTS SERVER EDITION
Xen Hypervisor version: (a) Xen 4.2-unstable Changeset 25099 (b) Xen 
4.2.1-pre (c) Xen 4.3-unstable Changeset 25993
Linux Dom0 Kernel: (a) 3.5.4 (b) 3.6.0-rc7 (c) 3.6.1
Windows HVM domU: (a) Windows XP Home Edition SP3 (b) Windows 8 Release 
Preview 64-bit (c) Windows 7 Ultimate Evaluation Copy

Manuals which I have followed in getting Xen VGA Passthrough done:

(1) 
http://wiki.xen.org/wiki/Building_and_Installing_Xen_4.x_and_Linux_Kernel_3.x_on_Ubuntu_and_Debian_Linux

(2) 
http://wiki.xen.org/wiki/Xen_VGA_Passthrough_to_Windows_8_with_Xen_4.2-unstable

The above 2 are manuals which I have written myself, after studying 
several Xen Wiki Pages and Jean David Techer's notes.

Now, the above 2 manuals are the same manuals which I have used to 
obtain 100% success in Xen VGA Passthrough for Frank Lyon's NVIDIA 
Quadro 6000. Yes, 100% success. Absolutely no yellow triangle with 
exclamation mark and error code 43 in Windows 7 and Windows 8 HVM domU. 
It is an irony and a joke that, with the same set of manuals which I 
have written, I cannot get 100% success in Xen VGA Passthrough with my 
very own display cards. Frank Lyon's NVIDIA Quadro 6000 costs S$6000++, 
and I can't afford it.

So now, the problem stands. I get a yellow triangle with exclamation 
mark and error code 43 in device manager for Gigabyte Geforce GTX 560 in 
Windows 8 HVM domU and a yellow circle with exclamation mark and error 
code 10 in device manager for Gigabyte Geforce GTX 560 in Windows XP 
Home Edition HVM domU.

_The Reward__or Prize Money_

1. USD$100 in cash


_How to Get the Reward_

If I can say that you have solved my Xen VGA Passthrough problem 100%, 
you get the reward! Basically, the idea is to get rid of the yellow 
triangle with exclamation mark and error code 43 in Windows 8 HVM domU 
and the yellow circle with exclamation mark and error code 10 in Windows 
XP HVM domU.

Hence,

(1) If you can tell me off-hand the solution which leads to my Xen VGA 
Passthrough problem being solved 100%, you get the reward. OR

(2) You have spotted mistakes or errors in the manuals which I have 
written, leading to my Xen VGA Passthrough problem being solved 100%. 
You get the reward. OR

(3) If you have a VT-d capable motherboard and processor, and a 
compatible NVIDIA Geforce GTX 560 like mine, and follow the 2 manuals 
which I have written for your Xen VGA Passthrough needs. If you can 
obtain 100% success, please tell me the mistakes or errors in my 
manuals, which leads to my Xen VGA Passthrough problem being solved 
100%. You get the reward.

*_100% success means no error code 43 and no error code 10._*

For a start, you may follow the thread series "*Help Needed from Xen 
Developers: Nasty Yellow Triangle with Exclamation Mark and Error Code 
43 in Device Manager in Windows 8 HVM domU 
" in 
the xen-users and xen-devel mailing lists.*

Please note that the prize money of US$100 is guaranteed and there is 
only one winner. There is no closing date for this challenge.


-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore


--------------060801040806020703090407
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    History

    

    I have 100% success in Xen VGA Passthrough with Xen 3.5-unstable
    with my first Palit NVIDIA Geforce 8400 GS VGA card in 2009, which
    is 3 years ago. Then my first Palit NVIDIA Geforce 8400 GS VGA card
    overheated and malfunctioned. So I bought a 2nd Palit NVIDIA Geforce
    8400 GS VGA card several months ago in March 2012 for S$44, to
    replace the first card. At that point in time, Xen was already of
    version 4.2-unstable. I have tried to passthrough my 2nd Palit
    NVIDIA Geforce 8400 GS, which is only partially working, or partial
    success. In Windows 8 HVM domU, you will see a yellow triangle
      with exclamation mark and error code 43 in Device Manager for the
      2nd Palit NVIDIA Geforce 8400 GS. In Windows XP Home Edition HVM
      domU, you will see a yellow circle with exclamation mark and error
      code 10 in Device Manager for the 2nd Palit NVIDIA Geforce 8400
      GS.

    

    Then I noticed Jean David Techer uses a Geforce 560 Ti for his Xen
    VGA Passthrough. So 1-2 weeks ago I bought a EVGA Geforce GTX 560 1
    GB GDDR5 for S$269. Same thing. Xen VGA Passthrough is only
    partially working or partial success. So I went back to the computer
    shop and exchanged my EVGA Geforce GTX 560 with a Gigabyte Geforce
    GTX 560 1 GB GDDR5, which costs S$289. Again, Xen VGA Passthrough is
    only partially working or partial success. In Windows 8 HVM
      domU, you will see a yellow triangle with exclamation mark and
      error code 43 in Device Manager for the Gigabyte Geforce GTX 560.
      In Windows XP Home Edition HVM domU, you will see a yellow circle
      with exclamation mark and error code 10 in Device Manager for the
      Gigabyte Geforce GTX 560.

    

    The Challenge

    

    My computer hardware specifications:

    

    Processor: Intel Pentium Dual Core E2300 @ 2.8 GHz

    Motherboard: Intel DQ45CB Desktop Board with VT-d enabled

    VGA Card: Gigabyte Geforce GTX 560 1 GB GDDR5

    Memory: 6 GB

    

    My computer software specifications:

    

    Host operating system: Ubuntu 12.04.1 LTS SERVER EDITION

    Xen Hypervisor version: (a) Xen 4.2-unstable Changeset 25099 (b) Xen
    4.2.1-pre (c) Xen 4.3-unstable Changeset 25993

    Linux Dom0 Kernel: (a) 3.5.4 (b) 3.6.0-rc7 (c) 3.6.1

    Windows HVM domU: (a) Windows XP Home Edition SP3 (b) Windows 8
    Release Preview 64-bit (c) Windows 7 Ultimate Evaluation Copy

    

    Manuals which I have followed in getting Xen VGA Passthrough done:

    

    (1)
    http://wiki.xen.org/wiki/Building_and_Installing_Xen_4.x_and_Linux_Kernel_3.x_on_Ubuntu_and_Debian_Linux

    

    (2)
    http://wiki.xen.org/wiki/Xen_VGA_Passthrough_to_Windows_8_with_Xen_4.2-unstable

    

    The above 2 are manuals which I have written myself, after studying
    several Xen Wiki Pages and Jean David Techer's notes.

    

    Now, the above 2 manuals are the same manuals which I have used to
    obtain 100% success in Xen VGA Passthrough for Frank Lyon's NVIDIA
    Quadro 6000. Yes, 100% success. Absolutely no yellow triangle with
    exclamation mark and error code 43 in Windows 7 and Windows 8 HVM
    domU. It is an irony and a joke that, with the same set of manuals
    which I have written, I cannot get 100% success in Xen VGA
    Passthrough with my very own display cards. Frank Lyon's NVIDIA
    Quadro 6000 costs S$6000++, and I can't afford it. 

    

    So now, the problem stands. I get a yellow triangle with exclamation
    mark and error code 43 in device manager for Gigabyte Geforce GTX
    560 in Windows 8 HVM domU and a yellow circle with exclamation mark
    and error code 10 in device manager for Gigabyte Geforce GTX 560 in
    Windows XP Home Edition HVM domU.

    

    The Reward or Prize Money

    

    1. USD$100 in cash

    

    

    How to Get the Reward

    

    If I can say that you have solved my Xen VGA Passthrough problem
    100%, you get the reward! Basically, the idea is to get rid of the
    yellow triangle with exclamation mark and error code 43 in Windows 8
    HVM domU and the yellow circle with exclamation mark and error code
    10 in Windows XP HVM domU.

    

    Hence,

    

    (1) If you can tell me off-hand the solution which leads to my Xen
    VGA Passthrough problem being solved 100%, you get the reward. OR

    

    (2) You have spotted mistakes or errors in the manuals which I have
    written, leading to my Xen VGA Passthrough problem being solved
    100%. You get the reward. OR

    

    (3) If you have a VT-d capable motherboard and processor, and a
    compatible NVIDIA Geforce GTX 560 like mine, and follow the 2
    manuals which I have written for your Xen VGA Passthrough needs. If
    you can obtain 100% success, please tell me the mistakes or errors
    in my manuals, which leads to my Xen VGA Passthrough problem being
    solved 100%. You get the reward.

    

    100% success means no error code 43 and no error code 10.

    

    For a start, you may follow the thread series "Help


        Needed from Xen Developers: Nasty Yellow Triangle with
        Exclamation Mark and Error Code 43 in Device Manager in Windows
        8 HVM domU" in the xen-users and xen-devel mailing lists.

    

    Please note that the prize money of US$100 is guaranteed and there
    is only one winner. There is no closing date for this challenge.

    

    

    
-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore

  


--------------060801040806020703090407--


--===============1892417179761918824==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1892417179761918824==--


From xen-devel-bounces@lists.xen.org Thu Oct 11 08:02:59 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 08:02:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMDix-0004FE-Vh; Thu, 11 Oct 2012 08:02:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMDiw-0004F9-JV
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 08:02:30 +0000
Received: from [85.158.138.51:49996] by server-3.bemta-3.messagelabs.com id
	21/1D-09368-51D76705; Thu, 11 Oct 2012 08:02:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1349942549!32152393!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM4Mjk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28260 invoked from network); 11 Oct 2012 08:02:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Oct 2012 08:02:29 -0000
X-IronPort-AV: E=Sophos;i="4.80,570,1344211200"; d="scan'208";a="15090752"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Oct 2012 08:02:28 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 11 Oct 2012 09:02:28 +0100
Message-ID: <1349942546.14806.7.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Sander Eikelenboom 
Date: Thu, 11 Oct 2012 09:02:26 +0100
In-Reply-To: <748966751.20121010164949@eikelenboom.it>
References: <1349790467.21847.185.camel@zakaz.uk.xensource.com>
	<1349790863.21172.4406.camel@edumazet-glaptop>
	<1349792241.21847.199.camel@zakaz.uk.xensource.com>
	<1349792847.21172.4479.camel@edumazet-glaptop>
	<1349793630.21847.208.camel@zakaz.uk.xensource.com>
	<1349863984.10070.26.camel@zakaz.uk.xensource.com>
	<1349874598.10070.39.camel@zakaz.uk.xensource.com>
	<748966751.20121010164949@eikelenboom.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk ,
	Eric Dumazet ,
	"netdev@vger.kernel.org" ,
	Eric Dumazet , xen-devel 
Subject: Re: [Xen-devel] compound skb frag pages appearing in start_xmit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-10 at 15:49 +0100, Sander Eikelenboom wrote:
> Wednesday, October 10, 2012, 3:09:58 PM, you wrote:
> 
> > On Wed, 2012-10-10 at 11:13 +0100, Ian Campbell wrote:
> >> I haven't tackled netfront yet. 
> 
> > I seem to be totally unable to reproduce the equivalent issue on the
> > netfront xmit side, even though it seems like the loop in
> > xennet_make_frags ought to be obviously susceptible to it.
> 
> > Konrad, Sander, are either of you able to repro, e.g. with:
> 
> 
> Hmrrrmm i don't see any traces, only strange behaviour ..
> 
> - i can connect to guests by ssh, but it's sluggish, and sometimes stops working

I saw something like this (ssh sluggish) even with dom0 itself. I'm
trying to see if I can characterise it enough to reliably bisect it.

I already switched out xen-unstable for 4.2-testing but that didn't make
any difference.

> - The guest seem to keep trying to connect to netback:
> 
> [  658.276719] xen_bridge: port 2(vif40.0) entered forwarding state
> [  658.282258] xen_bridge: port 2(vif40.0) entered forwarding state
> [  663.945964] xen_bridge: port 7(vif39.0) entered forwarding state
> [  669.674277] xen_bridge: port 2(vif40.0) entered disabled state
> [  669.680290] device vif40.0 left promiscuous mode
> [  669.685464] xen_bridge: port 2(vif40.0) entered disabled state
> [  672.857222] device vif41.0 entered promiscuous mode
> [  673.166254] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
> [  673.176368] xen_bridge: port 2(vif41.0) entered forwarding state
> [  673.182042] xen_bridge: port 2(vif41.0) entered forwarding state
> [  674.439725] xen_bridge: port 7(vif39.0) entered disabled state
> [  674.445708] device vif39.0 left promiscuous mode
> [  674.450955] xen_bridge: port 7(vif39.0) entered disabled state
> [  677.726040] device vif42.0 entered promiscuous mode
> [  678.053381] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
> [  678.062804] xen_bridge: port 7(vif42.0) entered forwarding state
> [  678.068433] xen_bridge: port 7(vif42.0) entered forwarding state
> [  688.224736] xen_bridge: port 2(vif41.0) entered forwarding state
> [  693.080557] xen_bridge: port 7(vif42.0) entered forwarding state
> [  700.786276] xen_bridge: port 7(vif42.0) entered disabled state
> [  700.792484] device vif42.0 left promiscuous mode
> [  700.802409] xen_bridge: port 7(vif42.0) entered disabled state
> [  704.133606] device vif43.0 entered promiscuous mode
> [  704.460160] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
> [  704.469800] xen_bridge: port 7(vif43.0) entered forwarding state
> [  704.475303] xen_bridge: port 7(vif43.0) entered forwarding state
> [  719.493788] xen_bridge: port 7(vif43.0) entered forwarding state
> [  726.302456] xen_bridge: port 7(vif43.0) entered disabled state
> [  726.308898] device vif43.0 left promiscuous mode
> [  726.314029] xen_bridge: port 7(vif43.0) entered disabled state
> 
> All the guests are already up, but this keeps on going and going and going ....

The domain number seems to be climbing, are you sure something isn't
(crashing and) restarting?

> > diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> > index b06ef81..8a3f770 100644
> > --- a/drivers/net/xen-netfront.c
> > +++ b/drivers/net/xen-netfront.c
> > @@ -462,6 +462,8 @@ static void xennet_make_frags(struct sk_buff *skb, struct net_device *dev,
> >                 ref = gnttab_claim_grant_reference(&np->gref_tx_head);
> >                 BUG_ON((signed short)ref < 0);
> >  
> > +               BUG_ON(PageCompound(skb_frag_page(frag)));
> > +
> >                 mfn = pfn_to_mfn(page_to_pfn(skb_frag_page(frag)));
> >                 gnttab_grant_foreign_access_ref(ref, np->xbdev->otherend_id,
> >                                                 mfn, GNTMAP_readonly);
> 
> > My repro for netback was just to netcat a wodge of data from dom0->domU
> > but going the other way doesn't seem to trigger.
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 08:02:59 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 08:02:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMDix-0004FE-Vh; Thu, 11 Oct 2012 08:02:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMDiw-0004F9-JV
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 08:02:30 +0000
Received: from [85.158.138.51:49996] by server-3.bemta-3.messagelabs.com id
	21/1D-09368-51D76705; Thu, 11 Oct 2012 08:02:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1349942549!32152393!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM4Mjk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28260 invoked from network); 11 Oct 2012 08:02:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Oct 2012 08:02:29 -0000
X-IronPort-AV: E=Sophos;i="4.80,570,1344211200"; d="scan'208";a="15090752"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Oct 2012 08:02:28 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 11 Oct 2012 09:02:28 +0100
Message-ID: <1349942546.14806.7.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Sander Eikelenboom 
Date: Thu, 11 Oct 2012 09:02:26 +0100
In-Reply-To: <748966751.20121010164949@eikelenboom.it>
References: <1349790467.21847.185.camel@zakaz.uk.xensource.com>
	<1349790863.21172.4406.camel@edumazet-glaptop>
	<1349792241.21847.199.camel@zakaz.uk.xensource.com>
	<1349792847.21172.4479.camel@edumazet-glaptop>
	<1349793630.21847.208.camel@zakaz.uk.xensource.com>
	<1349863984.10070.26.camel@zakaz.uk.xensource.com>
	<1349874598.10070.39.camel@zakaz.uk.xensource.com>
	<748966751.20121010164949@eikelenboom.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk ,
	Eric Dumazet ,
	"netdev@vger.kernel.org" ,
	Eric Dumazet , xen-devel 
Subject: Re: [Xen-devel] compound skb frag pages appearing in start_xmit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-10 at 15:49 +0100, Sander Eikelenboom wrote:
> Wednesday, October 10, 2012, 3:09:58 PM, you wrote:
> 
> > On Wed, 2012-10-10 at 11:13 +0100, Ian Campbell wrote:
> >> I haven't tackled netfront yet. 
> 
> > I seem to be totally unable to reproduce the equivalent issue on the
> > netfront xmit side, even though it seems like the loop in
> > xennet_make_frags ought to be obviously susceptible to it.
> 
> > Konrad, Sander, are either of you able to repro, e.g. with:
> 
> 
> Hmrrrmm i don't see any traces, only strange behaviour ..
> 
> - i can connect to guests by ssh, but it's sluggish, and sometimes stops working

I saw something like this (ssh sluggish) even with dom0 itself. I'm
trying to see if I can characterise it enough to reliably bisect it.

I already switched out xen-unstable for 4.2-testing but that didn't make
any difference.

> - The guest seem to keep trying to connect to netback:
> 
> [  658.276719] xen_bridge: port 2(vif40.0) entered forwarding state
> [  658.282258] xen_bridge: port 2(vif40.0) entered forwarding state
> [  663.945964] xen_bridge: port 7(vif39.0) entered forwarding state
> [  669.674277] xen_bridge: port 2(vif40.0) entered disabled state
> [  669.680290] device vif40.0 left promiscuous mode
> [  669.685464] xen_bridge: port 2(vif40.0) entered disabled state
> [  672.857222] device vif41.0 entered promiscuous mode
> [  673.166254] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
> [  673.176368] xen_bridge: port 2(vif41.0) entered forwarding state
> [  673.182042] xen_bridge: port 2(vif41.0) entered forwarding state
> [  674.439725] xen_bridge: port 7(vif39.0) entered disabled state
> [  674.445708] device vif39.0 left promiscuous mode
> [  674.450955] xen_bridge: port 7(vif39.0) entered disabled state
> [  677.726040] device vif42.0 entered promiscuous mode
> [  678.053381] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
> [  678.062804] xen_bridge: port 7(vif42.0) entered forwarding state
> [  678.068433] xen_bridge: port 7(vif42.0) entered forwarding state
> [  688.224736] xen_bridge: port 2(vif41.0) entered forwarding state
> [  693.080557] xen_bridge: port 7(vif42.0) entered forwarding state
> [  700.786276] xen_bridge: port 7(vif42.0) entered disabled state
> [  700.792484] device vif42.0 left promiscuous mode
> [  700.802409] xen_bridge: port 7(vif42.0) entered disabled state
> [  704.133606] device vif43.0 entered promiscuous mode
> [  704.460160] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
> [  704.469800] xen_bridge: port 7(vif43.0) entered forwarding state
> [  704.475303] xen_bridge: port 7(vif43.0) entered forwarding state
> [  719.493788] xen_bridge: port 7(vif43.0) entered forwarding state
> [  726.302456] xen_bridge: port 7(vif43.0) entered disabled state
> [  726.308898] device vif43.0 left promiscuous mode
> [  726.314029] xen_bridge: port 7(vif43.0) entered disabled state
> 
> All the guests are already up, but this keeps on going and going and going ....

The domain number seems to be climbing, are you sure something isn't
(crashing and) restarting?

> > diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> > index b06ef81..8a3f770 100644
> > --- a/drivers/net/xen-netfront.c
> > +++ b/drivers/net/xen-netfront.c
> > @@ -462,6 +462,8 @@ static void xennet_make_frags(struct sk_buff *skb, struct net_device *dev,
> >                 ref = gnttab_claim_grant_reference(&np->gref_tx_head);
> >                 BUG_ON((signed short)ref < 0);
> >  
> > +               BUG_ON(PageCompound(skb_frag_page(frag)));
> > +
> >                 mfn = pfn_to_mfn(page_to_pfn(skb_frag_page(frag)));
> >                 gnttab_grant_foreign_access_ref(ref, np->xbdev->otherend_id,
> >                                                 mfn, GNTMAP_readonly);
> 
> > My repro for netback was just to netcat a wodge of data from dom0->domU
> > but going the other way doesn't seem to trigger.
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 08:25:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 08:25:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TME4y-0004Uu-BS; Thu, 11 Oct 2012 08:25:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TME4x-0004Ud-5S
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 08:25:15 +0000
Received: from [85.158.143.99:42097] by server-1.bemta-4.messagelabs.com id
	9B/98-19551-A6286705; Thu, 11 Oct 2012 08:25:14 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-16.tower-216.messagelabs.com!1349943912!22448865!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20244 invoked from network); 11 Oct 2012 08:25:13 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-16.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	11 Oct 2012 08:25:13 -0000
Received: from 50-66-ftth.onsneteindhoven.nl ([88.159.66.50]:41648
	helo=localhost.localdomain) by smtp.eikelenboom.it with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72)
	(envelope-from )
	id 1TME6J-0000Z4-Ft; Thu, 11 Oct 2012 10:26:39 +0200
From: linux@eikelenboom.it
To: xen-devel@lists.xen.org
Date: Thu, 11 Oct 2012 10:25:06 +0200
Message-Id: <1349943909-2495-1-git-send-email-linux@eikelenboom.it>
X-Mailer: git-send-email 1.7.2.5
Cc: Ian.Campbell@citrix.com
Subject: [Xen-devel] Fix xl shutdown and init / sysconfig behaviour
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi IanC,

Here are some patches that fix the most important part of the lack of a working shutdown in the default init / sysconfig scripts when using xl.
This patch series does *not* include the --all option, which is also lacking from xl/libxl and is used as "catch all" 
in the xendomains init script during shutdown.

--

Sander


[PATCH 1/3] init/sysconfig scripts: Remove --halt/-H option for shutdown command.
[PATCH 2/3] init scripts: xendomains correct order of options for shutdown command
[PATCH 3/3] xl/libxl: make shutdown accept the long option --wait for -w

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 08:25:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 08:25:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TME4y-0004Uu-BS; Thu, 11 Oct 2012 08:25:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TME4x-0004Ud-5S
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 08:25:15 +0000
Received: from [85.158.143.99:42097] by server-1.bemta-4.messagelabs.com id
	9B/98-19551-A6286705; Thu, 11 Oct 2012 08:25:14 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-16.tower-216.messagelabs.com!1349943912!22448865!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20244 invoked from network); 11 Oct 2012 08:25:13 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-16.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	11 Oct 2012 08:25:13 -0000
Received: from 50-66-ftth.onsneteindhoven.nl ([88.159.66.50]:41648
	helo=localhost.localdomain) by smtp.eikelenboom.it with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72)
	(envelope-from )
	id 1TME6J-0000Z4-Ft; Thu, 11 Oct 2012 10:26:39 +0200
From: linux@eikelenboom.it
To: xen-devel@lists.xen.org
Date: Thu, 11 Oct 2012 10:25:06 +0200
Message-Id: <1349943909-2495-1-git-send-email-linux@eikelenboom.it>
X-Mailer: git-send-email 1.7.2.5
Cc: Ian.Campbell@citrix.com
Subject: [Xen-devel] Fix xl shutdown and init / sysconfig behaviour
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi IanC,

Here are some patches that fix the most important part of the lack of a working shutdown in the default init / sysconfig scripts when using xl.
This patch series does *not* include the --all option, which is also lacking from xl/libxl and is used as "catch all" 
in the xendomains init script during shutdown.

--

Sander


[PATCH 1/3] init/sysconfig scripts: Remove --halt/-H option for shutdown command.
[PATCH 2/3] init scripts: xendomains correct order of options for shutdown command
[PATCH 3/3] xl/libxl: make shutdown accept the long option --wait for -w

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 08:25:38 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 08:25:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TME4w-0004Uf-VP; Thu, 11 Oct 2012 08:25:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TME4w-0004UX-8a
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 08:25:14 +0000
Received: from [85.158.139.211:42897] by server-15.bemta-5.messagelabs.com id
	FE/FD-27811-96286705; Thu, 11 Oct 2012 08:25:13 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-4.tower-206.messagelabs.com!1349943912!21907483!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29510 invoked from network); 11 Oct 2012 08:25:12 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-4.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	11 Oct 2012 08:25:12 -0000
Received: from 50-66-ftth.onsneteindhoven.nl ([88.159.66.50]:41648
	helo=localhost.localdomain) by smtp.eikelenboom.it with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72)
	(envelope-from )
	id 1TME6J-0000Z4-MN; Thu, 11 Oct 2012 10:26:39 +0200
From: linux@eikelenboom.it
To: xen-devel@lists.xen.org
Date: Thu, 11 Oct 2012 10:25:07 +0200
Message-Id: <1349943909-2495-2-git-send-email-linux@eikelenboom.it>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1349943909-2495-1-git-send-email-linux@eikelenboom.it>
References: <1349943909-2495-1-git-send-email-linux@eikelenboom.it>
Cc: Sander Eikelenboom , Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 1/3] init/sysconfig scripts: Remove --halt/-H
	option for shutdown command.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Sander Eikelenboom 

The --halt/-H option for the shutdown command is now pointless,
since linux in a guest treats "halt" and "poweroff" identically.
The option is not implemented in xl / libxl and if supplied causes the command
to fail , so remove it from the init and sysconfig scripts.

Signed-off-by: Sander Eikelenboom 
---
 tools/hotplug/Linux/init.d/sysconfig.xendomains |   12 ++++++------
 tools/hotplug/Linux/init.d/xendomains           |    4 ++--
 tools/hotplug/NetBSD/rc.d/xendomains            |    2 +-
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/tools/hotplug/Linux/init.d/sysconfig.xendomains b/tools/hotplug/Linux/init.d/sysconfig.xendomains
index e590d3f..4775277 100644
--- a/tools/hotplug/Linux/init.d/sysconfig.xendomains
+++ b/tools/hotplug/Linux/init.d/sysconfig.xendomains
@@ -56,29 +56,29 @@ XENDOMAINS_MIGRATE=""
 XENDOMAINS_SAVE=/var/lib/xen/save
 
 ## Type: string
-## Default: "--halt --wait"
+## Default: "--wait"
 #
 # If neither MIGRATE nor SAVE were enabled or if they failed, you can
 # try to shut down a domain by sending it a shutdown request. To do this,
-# set this to "--halt --wait". Omit the "--wait" flag to avoid waiting
+# set this to "--wait". Omit the "--wait" flag to avoid waiting
 # for the domain to be really down. Leave empty to skip domain shutdown.
 #
-XENDOMAINS_SHUTDOWN="--halt --wait"
+XENDOMAINS_SHUTDOWN="--wait"
 
 ## Type: string
-## Default: "--all --halt --wait"
+## Default: "--all --wait"
 #
 # After we have gone over all virtual machines (resp. all automatically
 # started ones, see XENDOMAINS_AUTO_ONLY below) in a loop and sent SysRq,
 # migrated, saved and/or shutdown according to the settings above, we
 # might want to shutdown the virtual machines that are still running
 # for some reason or another. To do this, set this variable to
-# "--all --halt --wait", it will be passed to xm shutdown.
+# "--all --wait", it will be passed to xm shutdown.
 # Leave it empty not to do anything special here.
 # (Note: This will hit all virtual machines, even if XENDOMAINS_AUTO_ONLY
 # is set.)
 # 
-XENDOMAINS_SHUTDOWN_ALL="--all --halt --wait"
+XENDOMAINS_SHUTDOWN_ALL="--all --wait"
 
 ## Type: boolean
 ## Default: true
diff --git a/tools/hotplug/Linux/init.d/xendomains b/tools/hotplug/Linux/init.d/xendomains
index c033581..c363208 100644
--- a/tools/hotplug/Linux/init.d/xendomains
+++ b/tools/hotplug/Linux/init.d/xendomains
@@ -434,7 +434,7 @@ stop()
 	    fi
 	fi
 	if test -n "$XENDOMAINS_SHUTDOWN"; then
-	    # XENDOMAINS_SHUTDOWN should be "--halt --wait"
+	    # XENDOMAINS_SHUTDOWN should be "--wait"
 	    echo -n "(shut)"
 	    watchdog_xencmd shutdown &
 	    WDOG_PID=$!
@@ -453,7 +453,7 @@ stop()
     # This is because it's easier to do ;-) but arguably if this script is run
     # on system shutdown then it's also the right thing to do.
     if ! all_zombies && test -n "$XENDOMAINS_SHUTDOWN_ALL"; then
-	# XENDOMAINS_SHUTDOWN_ALL should be "--all --halt --wait"
+	# XENDOMAINS_SHUTDOWN_ALL should be "--all --wait"
 	echo -n " SHUTDOWN_ALL "
 	watchdog_xencmd shutdown 1 false &
 	WDOG_PID=$!
diff --git a/tools/hotplug/NetBSD/rc.d/xendomains b/tools/hotplug/NetBSD/rc.d/xendomains
index c368c58..3e62038 100644
--- a/tools/hotplug/NetBSD/rc.d/xendomains
+++ b/tools/hotplug/NetBSD/rc.d/xendomains
@@ -94,7 +94,7 @@ xendomains_stop()
 	#
 	echo "Stopping xen domains."
 	for domain in $(xendomains_list); do
-		${ctl_command} shutdown --halt $domain
+		${ctl_command} shutdown $domain
 	done
 	while [ $timeout -gt 0 ]; do
 		livedomains=$(xendomains_list)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 08:25:38 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 08:25:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TME4w-0004Uf-VP; Thu, 11 Oct 2012 08:25:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TME4w-0004UX-8a
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 08:25:14 +0000
Received: from [85.158.139.211:42897] by server-15.bemta-5.messagelabs.com id
	FE/FD-27811-96286705; Thu, 11 Oct 2012 08:25:13 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-4.tower-206.messagelabs.com!1349943912!21907483!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29510 invoked from network); 11 Oct 2012 08:25:12 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-4.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	11 Oct 2012 08:25:12 -0000
Received: from 50-66-ftth.onsneteindhoven.nl ([88.159.66.50]:41648
	helo=localhost.localdomain) by smtp.eikelenboom.it with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72)
	(envelope-from )
	id 1TME6J-0000Z4-MN; Thu, 11 Oct 2012 10:26:39 +0200
From: linux@eikelenboom.it
To: xen-devel@lists.xen.org
Date: Thu, 11 Oct 2012 10:25:07 +0200
Message-Id: <1349943909-2495-2-git-send-email-linux@eikelenboom.it>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1349943909-2495-1-git-send-email-linux@eikelenboom.it>
References: <1349943909-2495-1-git-send-email-linux@eikelenboom.it>
Cc: Sander Eikelenboom , Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 1/3] init/sysconfig scripts: Remove --halt/-H
	option for shutdown command.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Sander Eikelenboom 

The --halt/-H option for the shutdown command is now pointless,
since linux in a guest treats "halt" and "poweroff" identically.
The option is not implemented in xl / libxl and if supplied causes the command
to fail , so remove it from the init and sysconfig scripts.

Signed-off-by: Sander Eikelenboom 
---
 tools/hotplug/Linux/init.d/sysconfig.xendomains |   12 ++++++------
 tools/hotplug/Linux/init.d/xendomains           |    4 ++--
 tools/hotplug/NetBSD/rc.d/xendomains            |    2 +-
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/tools/hotplug/Linux/init.d/sysconfig.xendomains b/tools/hotplug/Linux/init.d/sysconfig.xendomains
index e590d3f..4775277 100644
--- a/tools/hotplug/Linux/init.d/sysconfig.xendomains
+++ b/tools/hotplug/Linux/init.d/sysconfig.xendomains
@@ -56,29 +56,29 @@ XENDOMAINS_MIGRATE=""
 XENDOMAINS_SAVE=/var/lib/xen/save
 
 ## Type: string
-## Default: "--halt --wait"
+## Default: "--wait"
 #
 # If neither MIGRATE nor SAVE were enabled or if they failed, you can
 # try to shut down a domain by sending it a shutdown request. To do this,
-# set this to "--halt --wait". Omit the "--wait" flag to avoid waiting
+# set this to "--wait". Omit the "--wait" flag to avoid waiting
 # for the domain to be really down. Leave empty to skip domain shutdown.
 #
-XENDOMAINS_SHUTDOWN="--halt --wait"
+XENDOMAINS_SHUTDOWN="--wait"
 
 ## Type: string
-## Default: "--all --halt --wait"
+## Default: "--all --wait"
 #
 # After we have gone over all virtual machines (resp. all automatically
 # started ones, see XENDOMAINS_AUTO_ONLY below) in a loop and sent SysRq,
 # migrated, saved and/or shutdown according to the settings above, we
 # might want to shutdown the virtual machines that are still running
 # for some reason or another. To do this, set this variable to
-# "--all --halt --wait", it will be passed to xm shutdown.
+# "--all --wait", it will be passed to xm shutdown.
 # Leave it empty not to do anything special here.
 # (Note: This will hit all virtual machines, even if XENDOMAINS_AUTO_ONLY
 # is set.)
 # 
-XENDOMAINS_SHUTDOWN_ALL="--all --halt --wait"
+XENDOMAINS_SHUTDOWN_ALL="--all --wait"
 
 ## Type: boolean
 ## Default: true
diff --git a/tools/hotplug/Linux/init.d/xendomains b/tools/hotplug/Linux/init.d/xendomains
index c033581..c363208 100644
--- a/tools/hotplug/Linux/init.d/xendomains
+++ b/tools/hotplug/Linux/init.d/xendomains
@@ -434,7 +434,7 @@ stop()
 	    fi
 	fi
 	if test -n "$XENDOMAINS_SHUTDOWN"; then
-	    # XENDOMAINS_SHUTDOWN should be "--halt --wait"
+	    # XENDOMAINS_SHUTDOWN should be "--wait"
 	    echo -n "(shut)"
 	    watchdog_xencmd shutdown &
 	    WDOG_PID=$!
@@ -453,7 +453,7 @@ stop()
     # This is because it's easier to do ;-) but arguably if this script is run
     # on system shutdown then it's also the right thing to do.
     if ! all_zombies && test -n "$XENDOMAINS_SHUTDOWN_ALL"; then
-	# XENDOMAINS_SHUTDOWN_ALL should be "--all --halt --wait"
+	# XENDOMAINS_SHUTDOWN_ALL should be "--all --wait"
 	echo -n " SHUTDOWN_ALL "
 	watchdog_xencmd shutdown 1 false &
 	WDOG_PID=$!
diff --git a/tools/hotplug/NetBSD/rc.d/xendomains b/tools/hotplug/NetBSD/rc.d/xendomains
index c368c58..3e62038 100644
--- a/tools/hotplug/NetBSD/rc.d/xendomains
+++ b/tools/hotplug/NetBSD/rc.d/xendomains
@@ -94,7 +94,7 @@ xendomains_stop()
 	#
 	echo "Stopping xen domains."
 	for domain in $(xendomains_list); do
-		${ctl_command} shutdown --halt $domain
+		${ctl_command} shutdown $domain
 	done
 	while [ $timeout -gt 0 ]; do
 		livedomains=$(xendomains_list)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 08:25:38 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 08:25:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TME4y-0004V1-N5; Thu, 11 Oct 2012 08:25:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TME4x-0004Ue-EH
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 08:25:15 +0000
Received: from [85.158.137.99:45332] by server-6.bemta-3.messagelabs.com id
	98/38-32375-A6286705; Thu, 11 Oct 2012 08:25:14 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-9.tower-217.messagelabs.com!1349943912!17989897!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21632 invoked from network); 11 Oct 2012 08:25:13 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-9.tower-217.messagelabs.com with AES256-SHA encrypted SMTP;
	11 Oct 2012 08:25:13 -0000
Received: from 50-66-ftth.onsneteindhoven.nl ([88.159.66.50]:41648
	helo=localhost.localdomain) by smtp.eikelenboom.it with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72)
	(envelope-from )
	id 1TME6J-0000Z4-S6; Thu, 11 Oct 2012 10:26:39 +0200
From: linux@eikelenboom.it
To: xen-devel@lists.xen.org
Date: Thu, 11 Oct 2012 10:25:08 +0200
Message-Id: <1349943909-2495-3-git-send-email-linux@eikelenboom.it>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1349943909-2495-1-git-send-email-linux@eikelenboom.it>
References: <1349943909-2495-1-git-send-email-linux@eikelenboom.it>
Cc: Sander Eikelenboom , Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 2/3] init scripts: xendomains correct order of
	options for shutdown command
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Sander Eikelenboom 

Options for the shutdown command that are supplied behind the domain id are
ignored. In case of the default xendomains init script this means that it will
not wait for the domains to be actually shutdown.

Signed-off-by: Sander Eikelenboom 
---
 tools/hotplug/Linux/init.d/xendomains |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tools/hotplug/Linux/init.d/xendomains b/tools/hotplug/Linux/init.d/xendomains
index c363208..00e5944 100644
--- a/tools/hotplug/Linux/init.d/xendomains
+++ b/tools/hotplug/Linux/init.d/xendomains
@@ -438,7 +438,7 @@ stop()
 	    echo -n "(shut)"
 	    watchdog_xencmd shutdown &
 	    WDOG_PID=$!
-	    XMR=`$CMD shutdown $id $XENDOMAINS_SHUTDOWN 2>&1 1>/dev/null`
+	    XMR=`$CMD shutdown $XENDOMAINS_SHUTDOWN $id 2>&1 1>/dev/null`
 	    if test $? -ne 0; then
 		echo -e "\nAn error occurred while shutting down domain:\n$XMR\n"
 		rc_failed $?
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 08:25:38 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 08:25:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TME4y-0004V1-N5; Thu, 11 Oct 2012 08:25:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TME4x-0004Ue-EH
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 08:25:15 +0000
Received: from [85.158.137.99:45332] by server-6.bemta-3.messagelabs.com id
	98/38-32375-A6286705; Thu, 11 Oct 2012 08:25:14 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-9.tower-217.messagelabs.com!1349943912!17989897!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21632 invoked from network); 11 Oct 2012 08:25:13 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-9.tower-217.messagelabs.com with AES256-SHA encrypted SMTP;
	11 Oct 2012 08:25:13 -0000
Received: from 50-66-ftth.onsneteindhoven.nl ([88.159.66.50]:41648
	helo=localhost.localdomain) by smtp.eikelenboom.it with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72)
	(envelope-from )
	id 1TME6J-0000Z4-S6; Thu, 11 Oct 2012 10:26:39 +0200
From: linux@eikelenboom.it
To: xen-devel@lists.xen.org
Date: Thu, 11 Oct 2012 10:25:08 +0200
Message-Id: <1349943909-2495-3-git-send-email-linux@eikelenboom.it>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1349943909-2495-1-git-send-email-linux@eikelenboom.it>
References: <1349943909-2495-1-git-send-email-linux@eikelenboom.it>
Cc: Sander Eikelenboom , Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 2/3] init scripts: xendomains correct order of
	options for shutdown command
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Sander Eikelenboom 

Options for the shutdown command that are supplied behind the domain id are
ignored. In case of the default xendomains init script this means that it will
not wait for the domains to be actually shutdown.

Signed-off-by: Sander Eikelenboom 
---
 tools/hotplug/Linux/init.d/xendomains |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tools/hotplug/Linux/init.d/xendomains b/tools/hotplug/Linux/init.d/xendomains
index c363208..00e5944 100644
--- a/tools/hotplug/Linux/init.d/xendomains
+++ b/tools/hotplug/Linux/init.d/xendomains
@@ -438,7 +438,7 @@ stop()
 	    echo -n "(shut)"
 	    watchdog_xencmd shutdown &
 	    WDOG_PID=$!
-	    XMR=`$CMD shutdown $id $XENDOMAINS_SHUTDOWN 2>&1 1>/dev/null`
+	    XMR=`$CMD shutdown $XENDOMAINS_SHUTDOWN $id 2>&1 1>/dev/null`
 	    if test $? -ne 0; then
 		echo -e "\nAn error occurred while shutting down domain:\n$XMR\n"
 		rc_failed $?
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 08:25:38 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 08:25:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TME53-0004Vg-3l; Thu, 11 Oct 2012 08:25:21 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TME51-0004UY-DB
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 08:25:19 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-8.tower-27.messagelabs.com!1349943912!10926962!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10730 invoked from network); 11 Oct 2012 08:25:13 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-8.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	11 Oct 2012 08:25:13 -0000
Received: from 50-66-ftth.onsneteindhoven.nl ([88.159.66.50]:41648
	helo=localhost.localdomain) by smtp.eikelenboom.it with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72)
	(envelope-from )
	id 1TME6K-0000Z4-0N; Thu, 11 Oct 2012 10:26:40 +0200
From: linux@eikelenboom.it
To: xen-devel@lists.xen.org
Date: Thu, 11 Oct 2012 10:25:09 +0200
Message-Id: <1349943909-2495-4-git-send-email-linux@eikelenboom.it>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1349943909-2495-1-git-send-email-linux@eikelenboom.it>
References: <1349943909-2495-1-git-send-email-linux@eikelenboom.it>
Cc: Sander Eikelenboom , Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 3/3] xl/libxl: make shutdown accept the long
	option --wait for -w
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Sander Eikelenboom 

Make xl/libxl accept the long option --wait for -w to be compatible with xm.
The long options are used in the default init and sysconfig scripts

Signed-off-by: Sander Eikelenboom 
---
 docs/man/xl.pod.1         |    2 +-
 tools/libxl/xl_cmdimpl.c  |    7 ++++++-
 tools/libxl/xl_cmdtable.c |    2 +-
 3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index 25ce777..dd387c9 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -550,7 +550,7 @@ B
 
 =over 4
 
-=item B<-w>
+=item B<-w>, B<--wait>
 
 Wait for the domain to complete shutdown before returning.
 
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 93066d3..768ba1f 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3709,8 +3709,13 @@ int main_shutdown(int argc, char **argv)
     int opt;
     int wait_for_it = 0;
     int fallback_trigger = 0;
+    int option_index = 0;
+    static struct option long_options[] = {
+        {"wait", 0, 0, 'w'},
+        {0, 0, 0, 0}
+    };
 
-    while ((opt = def_getopt(argc, argv, "wF", "shutdown", 1)) != -1) {
+    while ((opt = getopt_long(argc, argv, "wF", long_options, &option_index)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
diff --git a/tools/libxl/xl_cmdtable.c b/tools/libxl/xl_cmdtable.c
index 85ea768..b398c0a 100644
--- a/tools/libxl/xl_cmdtable.c
+++ b/tools/libxl/xl_cmdtable.c
@@ -64,7 +64,7 @@ struct cmd_spec cmd_table[] = {
       "-h                      Print this help.\n"
       "-F                      Fallback to ACPI power event for HVM guests with\n"
       "                        no PV drivers.\n"
-      "-w                      Wait for guest to shutdown.\n"
+      "-w, --wait              Wait for guest to shutdown.\n"
     },
     { "reboot",
       &main_reboot, 0, 1,
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 08:25:38 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 08:25:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TME53-0004Vg-3l; Thu, 11 Oct 2012 08:25:21 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TME51-0004UY-DB
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 08:25:19 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-8.tower-27.messagelabs.com!1349943912!10926962!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10730 invoked from network); 11 Oct 2012 08:25:13 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-8.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	11 Oct 2012 08:25:13 -0000
Received: from 50-66-ftth.onsneteindhoven.nl ([88.159.66.50]:41648
	helo=localhost.localdomain) by smtp.eikelenboom.it with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72)
	(envelope-from )
	id 1TME6K-0000Z4-0N; Thu, 11 Oct 2012 10:26:40 +0200
From: linux@eikelenboom.it
To: xen-devel@lists.xen.org
Date: Thu, 11 Oct 2012 10:25:09 +0200
Message-Id: <1349943909-2495-4-git-send-email-linux@eikelenboom.it>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1349943909-2495-1-git-send-email-linux@eikelenboom.it>
References: <1349943909-2495-1-git-send-email-linux@eikelenboom.it>
Cc: Sander Eikelenboom , Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 3/3] xl/libxl: make shutdown accept the long
	option --wait for -w
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Sander Eikelenboom 

Make xl/libxl accept the long option --wait for -w to be compatible with xm.
The long options are used in the default init and sysconfig scripts

Signed-off-by: Sander Eikelenboom 
---
 docs/man/xl.pod.1         |    2 +-
 tools/libxl/xl_cmdimpl.c  |    7 ++++++-
 tools/libxl/xl_cmdtable.c |    2 +-
 3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index 25ce777..dd387c9 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -550,7 +550,7 @@ B
 
 =over 4
 
-=item B<-w>
+=item B<-w>, B<--wait>
 
 Wait for the domain to complete shutdown before returning.
 
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 93066d3..768ba1f 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3709,8 +3709,13 @@ int main_shutdown(int argc, char **argv)
     int opt;
     int wait_for_it = 0;
     int fallback_trigger = 0;
+    int option_index = 0;
+    static struct option long_options[] = {
+        {"wait", 0, 0, 'w'},
+        {0, 0, 0, 0}
+    };
 
-    while ((opt = def_getopt(argc, argv, "wF", "shutdown", 1)) != -1) {
+    while ((opt = getopt_long(argc, argv, "wF", long_options, &option_index)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
diff --git a/tools/libxl/xl_cmdtable.c b/tools/libxl/xl_cmdtable.c
index 85ea768..b398c0a 100644
--- a/tools/libxl/xl_cmdtable.c
+++ b/tools/libxl/xl_cmdtable.c
@@ -64,7 +64,7 @@ struct cmd_spec cmd_table[] = {
       "-h                      Print this help.\n"
       "-F                      Fallback to ACPI power event for HVM guests with\n"
       "                        no PV drivers.\n"
-      "-w                      Wait for guest to shutdown.\n"
+      "-w, --wait              Wait for guest to shutdown.\n"
     },
     { "reboot",
       &main_reboot, 0, 1,
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 08:30:49 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 08:30:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMEA6-0004w1-SH; Thu, 11 Oct 2012 08:30:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMEA6-0004vt-2F
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 08:30:34 +0000
Received: from [85.158.139.211:51309] by server-15.bemta-5.messagelabs.com id
	D5/19-27811-9A386705; Thu, 11 Oct 2012 08:30:33 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-15.tower-206.messagelabs.com!1349944232!21939597!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9014 invoked from network); 11 Oct 2012 08:30:32 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-15.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	11 Oct 2012 08:30:32 -0000
Received: from 50-66-ftth.onsneteindhoven.nl ([88.159.66.50]:51777
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TMEBU-0000b3-Aw; Thu, 11 Oct 2012 10:32:00 +0200
Date: Thu, 11 Oct 2012 10:30:29 +0200
From: Sander Eikelenboom 
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <348095457.20121011103029@eikelenboom.it>
To: Ian Campbell 
In-Reply-To: <1349887424.14806.2.camel@zakaz.uk.xensource.com>
References: <1786005637.20121010180253@eikelenboom.it>
	<1349887424.14806.2.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel 
Subject: Re: [Xen-devel] xen-unstable: HVM start memory_map:add
	memory_map:remove cycle
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Wednesday, October 10, 2012, 6:43:44 PM, you wrote:

> On Wed, 2012-10-10 at 17:02 +0100, Sander Eikelenboom wrote:
>> Hi Ian,

> Why me specifically? Do you think this relates to something I've
> committed recently or...?

Nope, sorry just my favorite scapegoat i guess ;-)

>> 
>> When i start a HVM guest i get this cycle of adding removing adding
>> removing and finally adding ... for some memory ranges during the
>> start of the guest.
>> I don't know if it's intentionally, but it seems kind of strange .. :

> Can you identify the changeset where it started?

Not yet, will see if i can.


>> 
>> (XEN) [2012-10-10 15:17:54] memory_map:add: dom16 gfn=f3028 mfn=f9fff nr=1
>> (XEN) [2012-10-10 15:17:54] memory_map:remove: dom16 gfn=f3028 mfn=f9fff nr=1
>> (XEN) [2012-10-10 15:17:54] memory_map:add: dom16 gfn=f3028 mfn=f9fff nr=1
>> (XEN) [2012-10-10 15:17:54] memory_map:remove: dom16 gfn=f3028 mfn=f9fff nr=1
>> (XEN) [2012-10-10 15:17:54] memory_map:add: dom16 gfn=f3028 mfn=f9fff nr=1
>> (XEN) [2012-10-10 15:17:54] memory_map:remove: dom16 gfn=f3028 mfn=f9fff nr=1
>> (XEN) [2012-10-10 15:17:54] memory_map:add: dom16 gfn=f3028 mfn=f9fff nr=1
>> (XEN) [2012-10-10 15:17:54] memory_map:remove: dom16 gfn=f3028 mfn=f9fff nr=1
>> (XEN) [2012-10-10 15:17:54] memory_map:add: dom16 gfn=f3028 mfn=f9fff nr=1
>> (XEN) [2012-10-10 15:17:54] memory_map:remove: dom16 gfn=f3028 mfn=f9fff nr=1
>> (XEN) [2012-10-10 15:17:54] memory_map:add: dom16 gfn=f3028 mfn=f9fff nr=1
>> (XEN) [2012-10-10 15:17:54] memory_map:remove: dom16 gfn=f3028 mfn=f9fff nr=1
>> (XEN) [2012-10-10 15:17:54] memory_map:add: dom16 gfn=f3028 mfn=f9fff nr=1
>> 
>> 
>> xl dmesg attached
>> 
>> --
>> 
>> Sander





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 08:30:49 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 08:30:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMEA6-0004w1-SH; Thu, 11 Oct 2012 08:30:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMEA6-0004vt-2F
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 08:30:34 +0000
Received: from [85.158.139.211:51309] by server-15.bemta-5.messagelabs.com id
	D5/19-27811-9A386705; Thu, 11 Oct 2012 08:30:33 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-15.tower-206.messagelabs.com!1349944232!21939597!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9014 invoked from network); 11 Oct 2012 08:30:32 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-15.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	11 Oct 2012 08:30:32 -0000
Received: from 50-66-ftth.onsneteindhoven.nl ([88.159.66.50]:51777
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TMEBU-0000b3-Aw; Thu, 11 Oct 2012 10:32:00 +0200
Date: Thu, 11 Oct 2012 10:30:29 +0200
From: Sander Eikelenboom 
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <348095457.20121011103029@eikelenboom.it>
To: Ian Campbell 
In-Reply-To: <1349887424.14806.2.camel@zakaz.uk.xensource.com>
References: <1786005637.20121010180253@eikelenboom.it>
	<1349887424.14806.2.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel 
Subject: Re: [Xen-devel] xen-unstable: HVM start memory_map:add
	memory_map:remove cycle
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Wednesday, October 10, 2012, 6:43:44 PM, you wrote:

> On Wed, 2012-10-10 at 17:02 +0100, Sander Eikelenboom wrote:
>> Hi Ian,

> Why me specifically? Do you think this relates to something I've
> committed recently or...?

Nope, sorry just my favorite scapegoat i guess ;-)

>> 
>> When i start a HVM guest i get this cycle of adding removing adding
>> removing and finally adding ... for some memory ranges during the
>> start of the guest.
>> I don't know if it's intentionally, but it seems kind of strange .. :

> Can you identify the changeset where it started?

Not yet, will see if i can.


>> 
>> (XEN) [2012-10-10 15:17:54] memory_map:add: dom16 gfn=f3028 mfn=f9fff nr=1
>> (XEN) [2012-10-10 15:17:54] memory_map:remove: dom16 gfn=f3028 mfn=f9fff nr=1
>> (XEN) [2012-10-10 15:17:54] memory_map:add: dom16 gfn=f3028 mfn=f9fff nr=1
>> (XEN) [2012-10-10 15:17:54] memory_map:remove: dom16 gfn=f3028 mfn=f9fff nr=1
>> (XEN) [2012-10-10 15:17:54] memory_map:add: dom16 gfn=f3028 mfn=f9fff nr=1
>> (XEN) [2012-10-10 15:17:54] memory_map:remove: dom16 gfn=f3028 mfn=f9fff nr=1
>> (XEN) [2012-10-10 15:17:54] memory_map:add: dom16 gfn=f3028 mfn=f9fff nr=1
>> (XEN) [2012-10-10 15:17:54] memory_map:remove: dom16 gfn=f3028 mfn=f9fff nr=1
>> (XEN) [2012-10-10 15:17:54] memory_map:add: dom16 gfn=f3028 mfn=f9fff nr=1
>> (XEN) [2012-10-10 15:17:54] memory_map:remove: dom16 gfn=f3028 mfn=f9fff nr=1
>> (XEN) [2012-10-10 15:17:54] memory_map:add: dom16 gfn=f3028 mfn=f9fff nr=1
>> (XEN) [2012-10-10 15:17:54] memory_map:remove: dom16 gfn=f3028 mfn=f9fff nr=1
>> (XEN) [2012-10-10 15:17:54] memory_map:add: dom16 gfn=f3028 mfn=f9fff nr=1
>> 
>> 
>> xl dmesg attached
>> 
>> --
>> 
>> Sander





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 08:55:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 08:55:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMEXr-0005Ih-6K; Thu, 11 Oct 2012 08:55:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMEXp-0005Ic-Gs
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 08:55:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1349945557!4963024!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM4Mjk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21833 invoked from network); 11 Oct 2012 08:52:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Oct 2012 08:52:38 -0000
X-IronPort-AV: E=Sophos;i="4.80,570,1344211200"; d="scan'208";a="15092371"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Oct 2012 08:52:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 11 Oct 2012 09:52:38 +0100
Message-ID: <1349945556.14806.22.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: "linux@eikelenboom.it" , Roger Pau Monne
	, Attilio Rao , "Christoph
	Egger" 
Date: Thu, 11 Oct 2012 09:52:36 +0100
In-Reply-To: <1349943909-2495-2-git-send-email-linux@eikelenboom.it>
References: <1349943909-2495-1-git-send-email-linux@eikelenboom.it>
	<1349943909-2495-2-git-send-email-linux@eikelenboom.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 1/3] init/sysconfig scripts: Remove
 --halt/-H option for shutdown command.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-11 at 09:25 +0100, linux@eikelenboom.it wrote:
> From: Sander Eikelenboom 
> 
> The --halt/-H option for the shutdown command is now pointless,
> since linux in a guest treats "halt" and "poweroff" identically.

This looks good to me but I'd just like to confirm that Free&NetBSD also
treat them the same before I commit it.

Ian.

> The option is not implemented in xl / libxl and if supplied causes the command
> to fail , so remove it from the init and sysconfig scripts.
> 
> Signed-off-by: Sander Eikelenboom 
> ---
>  tools/hotplug/Linux/init.d/sysconfig.xendomains |   12 ++++++------
>  tools/hotplug/Linux/init.d/xendomains           |    4 ++--
>  tools/hotplug/NetBSD/rc.d/xendomains            |    2 +-
>  3 files changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/tools/hotplug/Linux/init.d/sysconfig.xendomains b/tools/hotplug/Linux/init.d/sysconfig.xendomains
> index e590d3f..4775277 100644
> --- a/tools/hotplug/Linux/init.d/sysconfig.xendomains
> +++ b/tools/hotplug/Linux/init.d/sysconfig.xendomains
> @@ -56,29 +56,29 @@ XENDOMAINS_MIGRATE=""
>  XENDOMAINS_SAVE=/var/lib/xen/save
>  
>  ## Type: string
> -## Default: "--halt --wait"
> +## Default: "--wait"
>  #
>  # If neither MIGRATE nor SAVE were enabled or if they failed, you can
>  # try to shut down a domain by sending it a shutdown request. To do this,
> -# set this to "--halt --wait". Omit the "--wait" flag to avoid waiting
> +# set this to "--wait". Omit the "--wait" flag to avoid waiting
>  # for the domain to be really down. Leave empty to skip domain shutdown.
>  #
> -XENDOMAINS_SHUTDOWN="--halt --wait"
> +XENDOMAINS_SHUTDOWN="--wait"
>  
>  ## Type: string
> -## Default: "--all --halt --wait"
> +## Default: "--all --wait"
>  #
>  # After we have gone over all virtual machines (resp. all automatically
>  # started ones, see XENDOMAINS_AUTO_ONLY below) in a loop and sent SysRq,
>  # migrated, saved and/or shutdown according to the settings above, we
>  # might want to shutdown the virtual machines that are still running
>  # for some reason or another. To do this, set this variable to
> -# "--all --halt --wait", it will be passed to xm shutdown.
> +# "--all --wait", it will be passed to xm shutdown.
>  # Leave it empty not to do anything special here.
>  # (Note: This will hit all virtual machines, even if XENDOMAINS_AUTO_ONLY
>  # is set.)
>  # 
> -XENDOMAINS_SHUTDOWN_ALL="--all --halt --wait"
> +XENDOMAINS_SHUTDOWN_ALL="--all --wait"
>  
>  ## Type: boolean
>  ## Default: true
> diff --git a/tools/hotplug/Linux/init.d/xendomains b/tools/hotplug/Linux/init.d/xendomains
> index c033581..c363208 100644
> --- a/tools/hotplug/Linux/init.d/xendomains
> +++ b/tools/hotplug/Linux/init.d/xendomains
> @@ -434,7 +434,7 @@ stop()
>  	    fi
>  	fi
>  	if test -n "$XENDOMAINS_SHUTDOWN"; then
> -	    # XENDOMAINS_SHUTDOWN should be "--halt --wait"
> +	    # XENDOMAINS_SHUTDOWN should be "--wait"
>  	    echo -n "(shut)"
>  	    watchdog_xencmd shutdown &
>  	    WDOG_PID=$!
> @@ -453,7 +453,7 @@ stop()
>      # This is because it's easier to do ;-) but arguably if this script is run
>      # on system shutdown then it's also the right thing to do.
>      if ! all_zombies && test -n "$XENDOMAINS_SHUTDOWN_ALL"; then
> -	# XENDOMAINS_SHUTDOWN_ALL should be "--all --halt --wait"
> +	# XENDOMAINS_SHUTDOWN_ALL should be "--all --wait"
>  	echo -n " SHUTDOWN_ALL "
>  	watchdog_xencmd shutdown 1 false &
>  	WDOG_PID=$!
> diff --git a/tools/hotplug/NetBSD/rc.d/xendomains b/tools/hotplug/NetBSD/rc.d/xendomains
> index c368c58..3e62038 100644
> --- a/tools/hotplug/NetBSD/rc.d/xendomains
> +++ b/tools/hotplug/NetBSD/rc.d/xendomains
> @@ -94,7 +94,7 @@ xendomains_stop()
>  	#
>  	echo "Stopping xen domains."
>  	for domain in $(xendomains_list); do
> -		${ctl_command} shutdown --halt $domain
> +		${ctl_command} shutdown $domain
>  	done
>  	while [ $timeout -gt 0 ]; do
>  		livedomains=$(xendomains_list)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 08:55:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 08:55:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMEXr-0005Ih-6K; Thu, 11 Oct 2012 08:55:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMEXp-0005Ic-Gs
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 08:55:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1349945557!4963024!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM4Mjk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21833 invoked from network); 11 Oct 2012 08:52:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Oct 2012 08:52:38 -0000
X-IronPort-AV: E=Sophos;i="4.80,570,1344211200"; d="scan'208";a="15092371"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Oct 2012 08:52:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 11 Oct 2012 09:52:38 +0100
Message-ID: <1349945556.14806.22.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: "linux@eikelenboom.it" , Roger Pau Monne
	, Attilio Rao , "Christoph
	Egger" 
Date: Thu, 11 Oct 2012 09:52:36 +0100
In-Reply-To: <1349943909-2495-2-git-send-email-linux@eikelenboom.it>
References: <1349943909-2495-1-git-send-email-linux@eikelenboom.it>
	<1349943909-2495-2-git-send-email-linux@eikelenboom.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 1/3] init/sysconfig scripts: Remove
 --halt/-H option for shutdown command.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-11 at 09:25 +0100, linux@eikelenboom.it wrote:
> From: Sander Eikelenboom 
> 
> The --halt/-H option for the shutdown command is now pointless,
> since linux in a guest treats "halt" and "poweroff" identically.

This looks good to me but I'd just like to confirm that Free&NetBSD also
treat them the same before I commit it.

Ian.

> The option is not implemented in xl / libxl and if supplied causes the command
> to fail , so remove it from the init and sysconfig scripts.
> 
> Signed-off-by: Sander Eikelenboom 
> ---
>  tools/hotplug/Linux/init.d/sysconfig.xendomains |   12 ++++++------
>  tools/hotplug/Linux/init.d/xendomains           |    4 ++--
>  tools/hotplug/NetBSD/rc.d/xendomains            |    2 +-
>  3 files changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/tools/hotplug/Linux/init.d/sysconfig.xendomains b/tools/hotplug/Linux/init.d/sysconfig.xendomains
> index e590d3f..4775277 100644
> --- a/tools/hotplug/Linux/init.d/sysconfig.xendomains
> +++ b/tools/hotplug/Linux/init.d/sysconfig.xendomains
> @@ -56,29 +56,29 @@ XENDOMAINS_MIGRATE=""
>  XENDOMAINS_SAVE=/var/lib/xen/save
>  
>  ## Type: string
> -## Default: "--halt --wait"
> +## Default: "--wait"
>  #
>  # If neither MIGRATE nor SAVE were enabled or if they failed, you can
>  # try to shut down a domain by sending it a shutdown request. To do this,
> -# set this to "--halt --wait". Omit the "--wait" flag to avoid waiting
> +# set this to "--wait". Omit the "--wait" flag to avoid waiting
>  # for the domain to be really down. Leave empty to skip domain shutdown.
>  #
> -XENDOMAINS_SHUTDOWN="--halt --wait"
> +XENDOMAINS_SHUTDOWN="--wait"
>  
>  ## Type: string
> -## Default: "--all --halt --wait"
> +## Default: "--all --wait"
>  #
>  # After we have gone over all virtual machines (resp. all automatically
>  # started ones, see XENDOMAINS_AUTO_ONLY below) in a loop and sent SysRq,
>  # migrated, saved and/or shutdown according to the settings above, we
>  # might want to shutdown the virtual machines that are still running
>  # for some reason or another. To do this, set this variable to
> -# "--all --halt --wait", it will be passed to xm shutdown.
> +# "--all --wait", it will be passed to xm shutdown.
>  # Leave it empty not to do anything special here.
>  # (Note: This will hit all virtual machines, even if XENDOMAINS_AUTO_ONLY
>  # is set.)
>  # 
> -XENDOMAINS_SHUTDOWN_ALL="--all --halt --wait"
> +XENDOMAINS_SHUTDOWN_ALL="--all --wait"
>  
>  ## Type: boolean
>  ## Default: true
> diff --git a/tools/hotplug/Linux/init.d/xendomains b/tools/hotplug/Linux/init.d/xendomains
> index c033581..c363208 100644
> --- a/tools/hotplug/Linux/init.d/xendomains
> +++ b/tools/hotplug/Linux/init.d/xendomains
> @@ -434,7 +434,7 @@ stop()
>  	    fi
>  	fi
>  	if test -n "$XENDOMAINS_SHUTDOWN"; then
> -	    # XENDOMAINS_SHUTDOWN should be "--halt --wait"
> +	    # XENDOMAINS_SHUTDOWN should be "--wait"
>  	    echo -n "(shut)"
>  	    watchdog_xencmd shutdown &
>  	    WDOG_PID=$!
> @@ -453,7 +453,7 @@ stop()
>      # This is because it's easier to do ;-) but arguably if this script is run
>      # on system shutdown then it's also the right thing to do.
>      if ! all_zombies && test -n "$XENDOMAINS_SHUTDOWN_ALL"; then
> -	# XENDOMAINS_SHUTDOWN_ALL should be "--all --halt --wait"
> +	# XENDOMAINS_SHUTDOWN_ALL should be "--all --wait"
>  	echo -n " SHUTDOWN_ALL "
>  	watchdog_xencmd shutdown 1 false &
>  	WDOG_PID=$!
> diff --git a/tools/hotplug/NetBSD/rc.d/xendomains b/tools/hotplug/NetBSD/rc.d/xendomains
> index c368c58..3e62038 100644
> --- a/tools/hotplug/NetBSD/rc.d/xendomains
> +++ b/tools/hotplug/NetBSD/rc.d/xendomains
> @@ -94,7 +94,7 @@ xendomains_stop()
>  	#
>  	echo "Stopping xen domains."
>  	for domain in $(xendomains_list); do
> -		${ctl_command} shutdown --halt $domain
> +		${ctl_command} shutdown $domain
>  	done
>  	while [ $timeout -gt 0 ]; do
>  		livedomains=$(xendomains_list)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 08:58:38 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 08:58:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMEaz-0005Qt-09; Thu, 11 Oct 2012 08:58:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMEay-0005Ql-4t
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 08:58:20 +0000
Received: from [85.158.143.99:33240] by server-2.bemta-4.messagelabs.com id
	B5/35-25171-B2A86705; Thu, 11 Oct 2012 08:58:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1349945898!23917145!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM4Mjk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25534 invoked from network); 11 Oct 2012 08:58:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Oct 2012 08:58:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,570,1344211200"; d="scan'208";a="15092545"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Oct 2012 08:58:18 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 11 Oct 2012 09:58:18 +0100
Message-ID: <1349945896.14806.25.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: "linux@eikelenboom.it" 
Date: Thu, 11 Oct 2012 09:58:16 +0100
In-Reply-To: <1349943909-2495-4-git-send-email-linux@eikelenboom.it>
References: <1349943909-2495-1-git-send-email-linux@eikelenboom.it>
	<1349943909-2495-4-git-send-email-linux@eikelenboom.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 3/3] xl/libxl: make shutdown accept the long
 option --wait for -w
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-11 at 09:25 +0100, linux@eikelenboom.it wrote:
> From: Sander Eikelenboom 
> 
> Make xl/libxl accept the long option --wait for -w to be compatible with xm.
> The long options are used in the default init and sysconfig scripts
> 
> Signed-off-by: Sander Eikelenboom 
> ---
>  docs/man/xl.pod.1         |    2 +-
>  tools/libxl/xl_cmdimpl.c  |    7 ++++++-
>  tools/libxl/xl_cmdtable.c |    2 +-
>  3 files changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
> index 25ce777..dd387c9 100644
> --- a/docs/man/xl.pod.1
> +++ b/docs/man/xl.pod.1
> @@ -550,7 +550,7 @@ B
>  
>  =over 4
>  
> -=item B<-w>
> +=item B<-w>, B<--wait>
>  
>  Wait for the domain to complete shutdown before returning.
>  
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 93066d3..768ba1f 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -3709,8 +3709,13 @@ int main_shutdown(int argc, char **argv)
>      int opt;
>      int wait_for_it = 0;
>      int fallback_trigger = 0;
> +    int option_index = 0;
> +    static struct option long_options[] = {
> +        {"wait", 0, 0, 'w'},
> +        {0, 0, 0, 0}
> +    };
>  
> -    while ((opt = def_getopt(argc, argv, "wF", "shutdown", 1)) != -1) {
> +    while ((opt = getopt_long(argc, argv, "wF", long_options, &option_index)) != -1) {

Since you don't use it you can pass NULL instead of &option_index.

>          switch (opt) {
>          case 0: case 2:
>              return opt;
> diff --git a/tools/libxl/xl_cmdtable.c b/tools/libxl/xl_cmdtable.c
> index 85ea768..b398c0a 100644
> --- a/tools/libxl/xl_cmdtable.c
> +++ b/tools/libxl/xl_cmdtable.c
> @@ -64,7 +64,7 @@ struct cmd_spec cmd_table[] = {
>        "-h                      Print this help.\n"
>        "-F                      Fallback to ACPI power event for HVM guests with\n"
>        "                        no PV drivers.\n"
> -      "-w                      Wait for guest to shutdown.\n"
> +      "-w, --wait              Wait for guest to shutdown.\n"
>      },
>      { "reboot",
>        &main_reboot, 0, 1,



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 08:58:38 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 08:58:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMEaz-0005Qt-09; Thu, 11 Oct 2012 08:58:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMEay-0005Ql-4t
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 08:58:20 +0000
Received: from [85.158.143.99:33240] by server-2.bemta-4.messagelabs.com id
	B5/35-25171-B2A86705; Thu, 11 Oct 2012 08:58:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1349945898!23917145!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM4Mjk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25534 invoked from network); 11 Oct 2012 08:58:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Oct 2012 08:58:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,570,1344211200"; d="scan'208";a="15092545"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Oct 2012 08:58:18 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 11 Oct 2012 09:58:18 +0100
Message-ID: <1349945896.14806.25.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: "linux@eikelenboom.it" 
Date: Thu, 11 Oct 2012 09:58:16 +0100
In-Reply-To: <1349943909-2495-4-git-send-email-linux@eikelenboom.it>
References: <1349943909-2495-1-git-send-email-linux@eikelenboom.it>
	<1349943909-2495-4-git-send-email-linux@eikelenboom.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 3/3] xl/libxl: make shutdown accept the long
 option --wait for -w
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-11 at 09:25 +0100, linux@eikelenboom.it wrote:
> From: Sander Eikelenboom 
> 
> Make xl/libxl accept the long option --wait for -w to be compatible with xm.
> The long options are used in the default init and sysconfig scripts
> 
> Signed-off-by: Sander Eikelenboom 
> ---
>  docs/man/xl.pod.1         |    2 +-
>  tools/libxl/xl_cmdimpl.c  |    7 ++++++-
>  tools/libxl/xl_cmdtable.c |    2 +-
>  3 files changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
> index 25ce777..dd387c9 100644
> --- a/docs/man/xl.pod.1
> +++ b/docs/man/xl.pod.1
> @@ -550,7 +550,7 @@ B
>  
>  =over 4
>  
> -=item B<-w>
> +=item B<-w>, B<--wait>
>  
>  Wait for the domain to complete shutdown before returning.
>  
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 93066d3..768ba1f 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -3709,8 +3709,13 @@ int main_shutdown(int argc, char **argv)
>      int opt;
>      int wait_for_it = 0;
>      int fallback_trigger = 0;
> +    int option_index = 0;
> +    static struct option long_options[] = {
> +        {"wait", 0, 0, 'w'},
> +        {0, 0, 0, 0}
> +    };
>  
> -    while ((opt = def_getopt(argc, argv, "wF", "shutdown", 1)) != -1) {
> +    while ((opt = getopt_long(argc, argv, "wF", long_options, &option_index)) != -1) {

Since you don't use it you can pass NULL instead of &option_index.

>          switch (opt) {
>          case 0: case 2:
>              return opt;
> diff --git a/tools/libxl/xl_cmdtable.c b/tools/libxl/xl_cmdtable.c
> index 85ea768..b398c0a 100644
> --- a/tools/libxl/xl_cmdtable.c
> +++ b/tools/libxl/xl_cmdtable.c
> @@ -64,7 +64,7 @@ struct cmd_spec cmd_table[] = {
>        "-h                      Print this help.\n"
>        "-F                      Fallback to ACPI power event for HVM guests with\n"
>        "                        no PV drivers.\n"
> -      "-w                      Wait for guest to shutdown.\n"
> +      "-w, --wait              Wait for guest to shutdown.\n"
>      },
>      { "reboot",
>        &main_reboot, 0, 1,



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 09:00:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 09:00:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMEct-0005Zi-LS; Thu, 11 Oct 2012 09:00:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TMEcs-0005Zc-BR
	for Xen-devel@lists.xen.org; Thu, 11 Oct 2012 09:00:18 +0000
Received: from [85.158.143.99:36650] by server-1.bemta-4.messagelabs.com id
	0B/00-19551-1AA86705; Thu, 11 Oct 2012 09:00:17 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-216.messagelabs.com!1349946015!28404931!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5357 invoked from network); 11 Oct 2012 09:00:16 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Oct 2012 09:00:16 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TMEcp-000E36-C8; Thu, 11 Oct 2012 09:00:15 +0000
Date: Thu, 11 Oct 2012 10:00:15 +0100
From: Tim Deegan 
To: Xinxin Jin 
Message-ID: <20121011090015.GA53661@ocelot.phlegethon.org>
References: 
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.1i
Cc: Xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Where is PV's root page table?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

At 10:02 -0700 on 05 Oct (1349431352), Xinxin Jin wrote:
> Hi, I want to manually walk guest's page table in Xen, but I cannot find
> where the base address of the guest root page table is defined. Could
> anyone give me some clue ?

You should use or copy the pagetable walkers that are already in Xen.
>From dom0 userspace, look at xc_translate_foreign_address(); inside Xen,
look at, e.g. sh_walk_guest_tables().

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 09:00:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 09:00:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMEct-0005Zi-LS; Thu, 11 Oct 2012 09:00:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TMEcs-0005Zc-BR
	for Xen-devel@lists.xen.org; Thu, 11 Oct 2012 09:00:18 +0000
Received: from [85.158.143.99:36650] by server-1.bemta-4.messagelabs.com id
	0B/00-19551-1AA86705; Thu, 11 Oct 2012 09:00:17 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-216.messagelabs.com!1349946015!28404931!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5357 invoked from network); 11 Oct 2012 09:00:16 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Oct 2012 09:00:16 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TMEcp-000E36-C8; Thu, 11 Oct 2012 09:00:15 +0000
Date: Thu, 11 Oct 2012 10:00:15 +0100
From: Tim Deegan 
To: Xinxin Jin 
Message-ID: <20121011090015.GA53661@ocelot.phlegethon.org>
References: 
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.1i
Cc: Xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Where is PV's root page table?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

At 10:02 -0700 on 05 Oct (1349431352), Xinxin Jin wrote:
> Hi, I want to manually walk guest's page table in Xen, but I cannot find
> where the base address of the guest root page table is defined. Could
> anyone give me some clue ?

You should use or copy the pagetable walkers that are already in Xen.
>From dom0 userspace, look at xc_translate_foreign_address(); inside Xen,
look at, e.g. sh_walk_guest_tables().

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 09:02:47 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 09:02:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMEf3-0005hx-5z; Thu, 11 Oct 2012 09:02:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TMEf1-0005hf-2X
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 09:02:31 +0000
Received: from [85.158.138.51:64813] by server-4.bemta-3.messagelabs.com id
	CB/43-01405-62B86705; Thu, 11 Oct 2012 09:02:30 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1349946148!27615339!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18698 invoked from network); 11 Oct 2012 09:02:29 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Oct 2012 09:02:29 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TMEey-000E3V-LE; Thu, 11 Oct 2012 09:02:28 +0000
Date: Thu, 11 Oct 2012 10:02:28 +0100
From: Tim Deegan 
To: Ming Liu 
Message-ID: <20121011090228.GB53661@ocelot.phlegethon.org>
References: <50F4CF19-626E-4210-BA69-E03FF8D7C951@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50F4CF19-626E-4210-BA69-E03FF8D7C951@gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] About getting guest pfn number from virtual address
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 20:12 -0400 on 10 Oct (1349899968), Ming Liu wrote:
> Hi, 
> I find that the shadow page fault entry function is : sh_page_fault. 
> It has three parameters: struct vcpu *v, unsigned long va and struct cpu_user_regs *regs. 
> 
> I have two questions here: 
> 1. The "unsigned long va" means the virtual address of the guest? 

Yes.  Yes, it is.

> 2. How can I get the physical frame number (PFN) from this va variable? 

Did you read the rest of that function?  Among other things, it finds
the GFN and MFN of the faulting address.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 09:02:47 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 09:02:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMEf3-0005hx-5z; Thu, 11 Oct 2012 09:02:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TMEf1-0005hf-2X
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 09:02:31 +0000
Received: from [85.158.138.51:64813] by server-4.bemta-3.messagelabs.com id
	CB/43-01405-62B86705; Thu, 11 Oct 2012 09:02:30 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1349946148!27615339!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18698 invoked from network); 11 Oct 2012 09:02:29 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Oct 2012 09:02:29 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TMEey-000E3V-LE; Thu, 11 Oct 2012 09:02:28 +0000
Date: Thu, 11 Oct 2012 10:02:28 +0100
From: Tim Deegan 
To: Ming Liu 
Message-ID: <20121011090228.GB53661@ocelot.phlegethon.org>
References: <50F4CF19-626E-4210-BA69-E03FF8D7C951@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50F4CF19-626E-4210-BA69-E03FF8D7C951@gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] About getting guest pfn number from virtual address
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 20:12 -0400 on 10 Oct (1349899968), Ming Liu wrote:
> Hi, 
> I find that the shadow page fault entry function is : sh_page_fault. 
> It has three parameters: struct vcpu *v, unsigned long va and struct cpu_user_regs *regs. 
> 
> I have two questions here: 
> 1. The "unsigned long va" means the virtual address of the guest? 

Yes.  Yes, it is.

> 2. How can I get the physical frame number (PFN) from this va variable? 

Did you read the rest of that function?  Among other things, it finds
the GFN and MFN of the faulting address.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 09:05:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 09:05:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMEhm-0005tV-OP; Thu, 11 Oct 2012 09:05:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMEhl-0005tM-Ho
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 09:05:21 +0000
Received: from [85.158.143.99:6729] by server-3.bemta-4.messagelabs.com id
	2F/98-10075-0DB86705; Thu, 11 Oct 2012 09:05:20 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1349946317!26165634!1
X-Originating-IP: [65.55.88.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21588 invoked from network); 11 Oct 2012 09:05:18 -0000
Received: from tx2ehsobe003.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.13)
	by server-11.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	11 Oct 2012 09:05:18 -0000
Received: from mail224-tx2-R.bigfish.com (10.9.14.251) by
	TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id
	14.1.225.23; Thu, 11 Oct 2012 09:05:16 +0000
Received: from mail224-tx2 (localhost [127.0.0.1])	by
	mail224-tx2-R.bigfish.com (Postfix) with ESMTP id 6E001940070;
	Thu, 11 Oct 2012 09:05:16 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: -4
X-BigFish: VPS-4(zzbb2dI98dI936eI1432Izz1202h1d1ah1d2ahzzz2dh668h839h93fhd25he5bhf0ah107ah1288h12a5h12a9h12bdh137ah13b6h1441h1155h)
Received: from mail224-tx2 (localhost.localdomain [127.0.0.1]) by mail224-tx2
	(MessageSwitch) id 1349946313774544_23076;
	Thu, 11 Oct 2012 09:05:13 +0000 (UTC)
Received: from TX2EHSMHS041.bigfish.com (unknown [10.9.14.236])	by
	mail224-tx2.bigfish.com (Postfix) with ESMTP id AE18ECC006F;
	Thu, 11 Oct 2012 09:05:13 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS041.bigfish.com (10.9.99.141) with Microsoft SMTP Server id
	14.1.225.23; Thu, 11 Oct 2012 09:05:12 +0000
X-WSS-ID: 0MBQ18M-01-1Q3-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2E23E1028065;	Thu, 11 Oct 2012 04:05:09 -0500 (CDT)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 11 Oct 2012 04:05:51 -0500
Received: from STOREXDAG01.amd.com (10.1.13.10) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Thu, 11 Oct 2012 04:05:09 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag01.amd.com
	(10.1.13.10) with Microsoft SMTP Server id 14.1.323.3; Thu, 11 Oct 2012
	05:05:08 -0400
Message-ID: <50768BC2.1080704@amd.com>
Date: Thu, 11 Oct 2012 11:05:06 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell 
References: <1349943909-2495-1-git-send-email-linux@eikelenboom.it>
	<1349943909-2495-2-git-send-email-linux@eikelenboom.it>
	<1349945556.14806.22.camel@zakaz.uk.xensource.com>
In-Reply-To: <1349945556.14806.22.camel@zakaz.uk.xensource.com>
X-OriginatorOrg: amd.com
Cc: Attilio Rao ,
	"linux@eikelenboom.it" ,
	"xen-devel@lists.xen.org" ,
	Roger Pau Monne 
Subject: Re: [Xen-devel] [PATCH 1/3] init/sysconfig scripts: Remove
 --halt/-H option for shutdown command.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/11/12 10:52, Ian Campbell wrote:
> On Thu, 2012-10-11 at 09:25 +0100, linux@eikelenboom.it wrote:
>> From: Sander Eikelenboom 
>>
>> The --halt/-H option for the shutdown command is now pointless,
>> since linux in a guest treats "halt" and "poweroff" identically.
> 
> This looks good to me but I'd just like to confirm that Free&NetBSD also
> treat them the same before I commit it.

shutdown in NetBSD never had a --halt option.
shutdown runs the shutdown procedure and halts the system.
shutdown -p runs the shutdown procedure and then powers off the system.

Christoph

> 
> Ian.
> 
>> The option is not implemented in xl / libxl and if supplied causes the command
>> to fail , so remove it from the init and sysconfig scripts.
>>
>> Signed-off-by: Sander Eikelenboom 
>> ---
>>  tools/hotplug/Linux/init.d/sysconfig.xendomains |   12 ++++++------
>>  tools/hotplug/Linux/init.d/xendomains           |    4 ++--
>>  tools/hotplug/NetBSD/rc.d/xendomains            |    2 +-
>>  3 files changed, 9 insertions(+), 9 deletions(-)
>>
>> diff --git a/tools/hotplug/Linux/init.d/sysconfig.xendomains b/tools/hotplug/Linux/init.d/sysconfig.xendomains
>> index e590d3f..4775277 100644
>> --- a/tools/hotplug/Linux/init.d/sysconfig.xendomains
>> +++ b/tools/hotplug/Linux/init.d/sysconfig.xendomains
>> @@ -56,29 +56,29 @@ XENDOMAINS_MIGRATE=""
>>  XENDOMAINS_SAVE=/var/lib/xen/save
>>  
>>  ## Type: string
>> -## Default: "--halt --wait"
>> +## Default: "--wait"
>>  #
>>  # If neither MIGRATE nor SAVE were enabled or if they failed, you can
>>  # try to shut down a domain by sending it a shutdown request. To do this,
>> -# set this to "--halt --wait". Omit the "--wait" flag to avoid waiting
>> +# set this to "--wait". Omit the "--wait" flag to avoid waiting
>>  # for the domain to be really down. Leave empty to skip domain shutdown.
>>  #
>> -XENDOMAINS_SHUTDOWN="--halt --wait"
>> +XENDOMAINS_SHUTDOWN="--wait"
>>  
>>  ## Type: string
>> -## Default: "--all --halt --wait"
>> +## Default: "--all --wait"
>>  #
>>  # After we have gone over all virtual machines (resp. all automatically
>>  # started ones, see XENDOMAINS_AUTO_ONLY below) in a loop and sent SysRq,
>>  # migrated, saved and/or shutdown according to the settings above, we
>>  # might want to shutdown the virtual machines that are still running
>>  # for some reason or another. To do this, set this variable to
>> -# "--all --halt --wait", it will be passed to xm shutdown.
>> +# "--all --wait", it will be passed to xm shutdown.
>>  # Leave it empty not to do anything special here.
>>  # (Note: This will hit all virtual machines, even if XENDOMAINS_AUTO_ONLY
>>  # is set.)
>>  # 
>> -XENDOMAINS_SHUTDOWN_ALL="--all --halt --wait"
>> +XENDOMAINS_SHUTDOWN_ALL="--all --wait"
>>  
>>  ## Type: boolean
>>  ## Default: true
>> diff --git a/tools/hotplug/Linux/init.d/xendomains b/tools/hotplug/Linux/init.d/xendomains
>> index c033581..c363208 100644
>> --- a/tools/hotplug/Linux/init.d/xendomains
>> +++ b/tools/hotplug/Linux/init.d/xendomains
>> @@ -434,7 +434,7 @@ stop()
>>  	    fi
>>  	fi
>>  	if test -n "$XENDOMAINS_SHUTDOWN"; then
>> -	    # XENDOMAINS_SHUTDOWN should be "--halt --wait"
>> +	    # XENDOMAINS_SHUTDOWN should be "--wait"
>>  	    echo -n "(shut)"
>>  	    watchdog_xencmd shutdown &
>>  	    WDOG_PID=$!
>> @@ -453,7 +453,7 @@ stop()
>>      # This is because it's easier to do ;-) but arguably if this script is run
>>      # on system shutdown then it's also the right thing to do.
>>      if ! all_zombies && test -n "$XENDOMAINS_SHUTDOWN_ALL"; then
>> -	# XENDOMAINS_SHUTDOWN_ALL should be "--all --halt --wait"
>> +	# XENDOMAINS_SHUTDOWN_ALL should be "--all --wait"
>>  	echo -n " SHUTDOWN_ALL "
>>  	watchdog_xencmd shutdown 1 false &
>>  	WDOG_PID=$!
>> diff --git a/tools/hotplug/NetBSD/rc.d/xendomains b/tools/hotplug/NetBSD/rc.d/xendomains
>> index c368c58..3e62038 100644
>> --- a/tools/hotplug/NetBSD/rc.d/xendomains
>> +++ b/tools/hotplug/NetBSD/rc.d/xendomains
>> @@ -94,7 +94,7 @@ xendomains_stop()
>>  	#
>>  	echo "Stopping xen domains."
>>  	for domain in $(xendomains_list); do
>> -		${ctl_command} shutdown --halt $domain
>> +		${ctl_command} shutdown $domain
>>  	done
>>  	while [ $timeout -gt 0 ]; do
>>  		livedomains=$(xendomains_list)
> 
> 
> 


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 09:05:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 09:05:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMEhm-0005tV-OP; Thu, 11 Oct 2012 09:05:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMEhl-0005tM-Ho
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 09:05:21 +0000
Received: from [85.158.143.99:6729] by server-3.bemta-4.messagelabs.com id
	2F/98-10075-0DB86705; Thu, 11 Oct 2012 09:05:20 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1349946317!26165634!1
X-Originating-IP: [65.55.88.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21588 invoked from network); 11 Oct 2012 09:05:18 -0000
Received: from tx2ehsobe003.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.13)
	by server-11.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	11 Oct 2012 09:05:18 -0000
Received: from mail224-tx2-R.bigfish.com (10.9.14.251) by
	TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id
	14.1.225.23; Thu, 11 Oct 2012 09:05:16 +0000
Received: from mail224-tx2 (localhost [127.0.0.1])	by
	mail224-tx2-R.bigfish.com (Postfix) with ESMTP id 6E001940070;
	Thu, 11 Oct 2012 09:05:16 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: -4
X-BigFish: VPS-4(zzbb2dI98dI936eI1432Izz1202h1d1ah1d2ahzzz2dh668h839h93fhd25he5bhf0ah107ah1288h12a5h12a9h12bdh137ah13b6h1441h1155h)
Received: from mail224-tx2 (localhost.localdomain [127.0.0.1]) by mail224-tx2
	(MessageSwitch) id 1349946313774544_23076;
	Thu, 11 Oct 2012 09:05:13 +0000 (UTC)
Received: from TX2EHSMHS041.bigfish.com (unknown [10.9.14.236])	by
	mail224-tx2.bigfish.com (Postfix) with ESMTP id AE18ECC006F;
	Thu, 11 Oct 2012 09:05:13 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS041.bigfish.com (10.9.99.141) with Microsoft SMTP Server id
	14.1.225.23; Thu, 11 Oct 2012 09:05:12 +0000
X-WSS-ID: 0MBQ18M-01-1Q3-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2E23E1028065;	Thu, 11 Oct 2012 04:05:09 -0500 (CDT)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 11 Oct 2012 04:05:51 -0500
Received: from STOREXDAG01.amd.com (10.1.13.10) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Thu, 11 Oct 2012 04:05:09 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag01.amd.com
	(10.1.13.10) with Microsoft SMTP Server id 14.1.323.3; Thu, 11 Oct 2012
	05:05:08 -0400
Message-ID: <50768BC2.1080704@amd.com>
Date: Thu, 11 Oct 2012 11:05:06 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell 
References: <1349943909-2495-1-git-send-email-linux@eikelenboom.it>
	<1349943909-2495-2-git-send-email-linux@eikelenboom.it>
	<1349945556.14806.22.camel@zakaz.uk.xensource.com>
In-Reply-To: <1349945556.14806.22.camel@zakaz.uk.xensource.com>
X-OriginatorOrg: amd.com
Cc: Attilio Rao ,
	"linux@eikelenboom.it" ,
	"xen-devel@lists.xen.org" ,
	Roger Pau Monne 
Subject: Re: [Xen-devel] [PATCH 1/3] init/sysconfig scripts: Remove
 --halt/-H option for shutdown command.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/11/12 10:52, Ian Campbell wrote:
> On Thu, 2012-10-11 at 09:25 +0100, linux@eikelenboom.it wrote:
>> From: Sander Eikelenboom 
>>
>> The --halt/-H option for the shutdown command is now pointless,
>> since linux in a guest treats "halt" and "poweroff" identically.
> 
> This looks good to me but I'd just like to confirm that Free&NetBSD also
> treat them the same before I commit it.

shutdown in NetBSD never had a --halt option.
shutdown runs the shutdown procedure and halts the system.
shutdown -p runs the shutdown procedure and then powers off the system.

Christoph

> 
> Ian.
> 
>> The option is not implemented in xl / libxl and if supplied causes the command
>> to fail , so remove it from the init and sysconfig scripts.
>>
>> Signed-off-by: Sander Eikelenboom 
>> ---
>>  tools/hotplug/Linux/init.d/sysconfig.xendomains |   12 ++++++------
>>  tools/hotplug/Linux/init.d/xendomains           |    4 ++--
>>  tools/hotplug/NetBSD/rc.d/xendomains            |    2 +-
>>  3 files changed, 9 insertions(+), 9 deletions(-)
>>
>> diff --git a/tools/hotplug/Linux/init.d/sysconfig.xendomains b/tools/hotplug/Linux/init.d/sysconfig.xendomains
>> index e590d3f..4775277 100644
>> --- a/tools/hotplug/Linux/init.d/sysconfig.xendomains
>> +++ b/tools/hotplug/Linux/init.d/sysconfig.xendomains
>> @@ -56,29 +56,29 @@ XENDOMAINS_MIGRATE=""
>>  XENDOMAINS_SAVE=/var/lib/xen/save
>>  
>>  ## Type: string
>> -## Default: "--halt --wait"
>> +## Default: "--wait"
>>  #
>>  # If neither MIGRATE nor SAVE were enabled or if they failed, you can
>>  # try to shut down a domain by sending it a shutdown request. To do this,
>> -# set this to "--halt --wait". Omit the "--wait" flag to avoid waiting
>> +# set this to "--wait". Omit the "--wait" flag to avoid waiting
>>  # for the domain to be really down. Leave empty to skip domain shutdown.
>>  #
>> -XENDOMAINS_SHUTDOWN="--halt --wait"
>> +XENDOMAINS_SHUTDOWN="--wait"
>>  
>>  ## Type: string
>> -## Default: "--all --halt --wait"
>> +## Default: "--all --wait"
>>  #
>>  # After we have gone over all virtual machines (resp. all automatically
>>  # started ones, see XENDOMAINS_AUTO_ONLY below) in a loop and sent SysRq,
>>  # migrated, saved and/or shutdown according to the settings above, we
>>  # might want to shutdown the virtual machines that are still running
>>  # for some reason or another. To do this, set this variable to
>> -# "--all --halt --wait", it will be passed to xm shutdown.
>> +# "--all --wait", it will be passed to xm shutdown.
>>  # Leave it empty not to do anything special here.
>>  # (Note: This will hit all virtual machines, even if XENDOMAINS_AUTO_ONLY
>>  # is set.)
>>  # 
>> -XENDOMAINS_SHUTDOWN_ALL="--all --halt --wait"
>> +XENDOMAINS_SHUTDOWN_ALL="--all --wait"
>>  
>>  ## Type: boolean
>>  ## Default: true
>> diff --git a/tools/hotplug/Linux/init.d/xendomains b/tools/hotplug/Linux/init.d/xendomains
>> index c033581..c363208 100644
>> --- a/tools/hotplug/Linux/init.d/xendomains
>> +++ b/tools/hotplug/Linux/init.d/xendomains
>> @@ -434,7 +434,7 @@ stop()
>>  	    fi
>>  	fi
>>  	if test -n "$XENDOMAINS_SHUTDOWN"; then
>> -	    # XENDOMAINS_SHUTDOWN should be "--halt --wait"
>> +	    # XENDOMAINS_SHUTDOWN should be "--wait"
>>  	    echo -n "(shut)"
>>  	    watchdog_xencmd shutdown &
>>  	    WDOG_PID=$!
>> @@ -453,7 +453,7 @@ stop()
>>      # This is because it's easier to do ;-) but arguably if this script is run
>>      # on system shutdown then it's also the right thing to do.
>>      if ! all_zombies && test -n "$XENDOMAINS_SHUTDOWN_ALL"; then
>> -	# XENDOMAINS_SHUTDOWN_ALL should be "--all --halt --wait"
>> +	# XENDOMAINS_SHUTDOWN_ALL should be "--all --wait"
>>  	echo -n " SHUTDOWN_ALL "
>>  	watchdog_xencmd shutdown 1 false &
>>  	WDOG_PID=$!
>> diff --git a/tools/hotplug/NetBSD/rc.d/xendomains b/tools/hotplug/NetBSD/rc.d/xendomains
>> index c368c58..3e62038 100644
>> --- a/tools/hotplug/NetBSD/rc.d/xendomains
>> +++ b/tools/hotplug/NetBSD/rc.d/xendomains
>> @@ -94,7 +94,7 @@ xendomains_stop()
>>  	#
>>  	echo "Stopping xen domains."
>>  	for domain in $(xendomains_list); do
>> -		${ctl_command} shutdown --halt $domain
>> +		${ctl_command} shutdown $domain
>>  	done
>>  	while [ $timeout -gt 0 ]; do
>>  		livedomains=$(xendomains_list)
> 
> 
> 


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 09:22:01 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 09:22:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMExa-00067C-H4; Thu, 11 Oct 2012 09:21:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMExZ-000672-Fn
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 09:21:41 +0000
Received: from [85.158.143.35:48220] by server-1.bemta-4.messagelabs.com id
	53/A5-19551-4AF86705; Thu, 11 Oct 2012 09:21:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1349947300!13901291!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM5ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5023 invoked from network); 11 Oct 2012 09:21:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Oct 2012 09:21:40 -0000
X-IronPort-AV: E=Sophos;i="4.80,571,1344211200"; d="scan'208";a="15093386"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Oct 2012 09:21:30 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 11 Oct 2012 10:21:30 +0100
Message-ID: <1349947288.14806.27.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: "linux@eikelenboom.it" 
Date: Thu, 11 Oct 2012 10:21:28 +0100
In-Reply-To: <1349943909-2495-3-git-send-email-linux@eikelenboom.it>
References: <1349943909-2495-1-git-send-email-linux@eikelenboom.it>
	<1349943909-2495-3-git-send-email-linux@eikelenboom.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 2/3] init scripts: xendomains correct order
 of options for shutdown command
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-11 at 09:25 +0100, linux@eikelenboom.it wrote:
> From: Sander Eikelenboom 
> 
> Options for the shutdown command that are supplied behind the domain id are
> ignored. In case of the default xendomains init script this means that it will
> not wait for the domains to be actually shutdown.
> 
> Signed-off-by: Sander Eikelenboom 

Acked-by: Ian Campbell 

and applied, thanks.

> ---
>  tools/hotplug/Linux/init.d/xendomains |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/hotplug/Linux/init.d/xendomains b/tools/hotplug/Linux/init.d/xendomains
> index c363208..00e5944 100644
> --- a/tools/hotplug/Linux/init.d/xendomains
> +++ b/tools/hotplug/Linux/init.d/xendomains
> @@ -438,7 +438,7 @@ stop()
>  	    echo -n "(shut)"
>  	    watchdog_xencmd shutdown &
>  	    WDOG_PID=$!
> -	    XMR=`$CMD shutdown $id $XENDOMAINS_SHUTDOWN 2>&1 1>/dev/null`
> +	    XMR=`$CMD shutdown $XENDOMAINS_SHUTDOWN $id 2>&1 1>/dev/null`
>  	    if test $? -ne 0; then
>  		echo -e "\nAn error occurred while shutting down domain:\n$XMR\n"
>  		rc_failed $?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 09:22:01 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 09:22:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMExa-00067C-H4; Thu, 11 Oct 2012 09:21:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMExZ-000672-Fn
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 09:21:41 +0000
Received: from [85.158.143.35:48220] by server-1.bemta-4.messagelabs.com id
	53/A5-19551-4AF86705; Thu, 11 Oct 2012 09:21:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1349947300!13901291!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM5ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5023 invoked from network); 11 Oct 2012 09:21:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Oct 2012 09:21:40 -0000
X-IronPort-AV: E=Sophos;i="4.80,571,1344211200"; d="scan'208";a="15093386"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Oct 2012 09:21:30 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 11 Oct 2012 10:21:30 +0100
Message-ID: <1349947288.14806.27.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: "linux@eikelenboom.it" 
Date: Thu, 11 Oct 2012 10:21:28 +0100
In-Reply-To: <1349943909-2495-3-git-send-email-linux@eikelenboom.it>
References: <1349943909-2495-1-git-send-email-linux@eikelenboom.it>
	<1349943909-2495-3-git-send-email-linux@eikelenboom.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 2/3] init scripts: xendomains correct order
 of options for shutdown command
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-11 at 09:25 +0100, linux@eikelenboom.it wrote:
> From: Sander Eikelenboom 
> 
> Options for the shutdown command that are supplied behind the domain id are
> ignored. In case of the default xendomains init script this means that it will
> not wait for the domains to be actually shutdown.
> 
> Signed-off-by: Sander Eikelenboom 

Acked-by: Ian Campbell 

and applied, thanks.

> ---
>  tools/hotplug/Linux/init.d/xendomains |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/hotplug/Linux/init.d/xendomains b/tools/hotplug/Linux/init.d/xendomains
> index c363208..00e5944 100644
> --- a/tools/hotplug/Linux/init.d/xendomains
> +++ b/tools/hotplug/Linux/init.d/xendomains
> @@ -438,7 +438,7 @@ stop()
>  	    echo -n "(shut)"
>  	    watchdog_xencmd shutdown &
>  	    WDOG_PID=$!
> -	    XMR=`$CMD shutdown $id $XENDOMAINS_SHUTDOWN 2>&1 1>/dev/null`
> +	    XMR=`$CMD shutdown $XENDOMAINS_SHUTDOWN $id 2>&1 1>/dev/null`
>  	    if test $? -ne 0; then
>  		echo -e "\nAn error occurred while shutting down domain:\n$XMR\n"
>  		rc_failed $?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 09:22:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 09:22:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMExw-00068w-WB; Thu, 11 Oct 2012 09:22:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMExv-00068l-Gw
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 09:22:03 +0000
Received: from [85.158.139.83:50763] by server-6.bemta-5.messagelabs.com id
	91/EB-08519-ABF86705; Thu, 11 Oct 2012 09:22:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1349947321!33715407!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM4Mjk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4516 invoked from network); 11 Oct 2012 09:22:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Oct 2012 09:22:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,571,1344211200"; d="scan'208";a="15093408"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Oct 2012 09:21:52 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 11 Oct 2012 10:21:52 +0100
Message-ID: <1349947311.14806.28.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Samuel Thibault 
Date: Thu, 11 Oct 2012 10:21:51 +0100
In-Reply-To: <20121009134648.GN6113@type.bordeaux.inria.fr>
References: <384714804b9b2a9742cc.1349787869@probook.site>
	<20121009134648.GN6113@type.bordeaux.inria.fr>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Olaf Hering ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] stubdom: fix error assignment in
 grub:load_module
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCAyMDEyLTEwLTA5IGF0IDE0OjQ2ICswMTAwLCBTYW11ZWwgVGhpYmF1bHQgd3JvdGU6
Cj4gT2xhZiBIZXJpbmcsIGxlIFR1ZSAwOSBPY3QgMjAxMiAxNTowNDoyOSArMDIwMCwgYSDDqWNy
aXQgOgo+ID4gIyBIRyBjaGFuZ2VzZXQgcGF0Y2gKPiA+ICMgVXNlciBPbGFmIEhlcmluZyA8b2xh
ZkBhZXBmbGUuZGU+Cj4gPiAjIERhdGUgMTM0OTc4Nzg1NSAtNzIwMAo+ID4gIyBOb2RlIElEIDM4
NDcxNDgwNGI5YjJhOTc0MmNjNDVkZmZhYTQzYjc0OWI4NTUxM2IKPiA+ICMgUGFyZW50ICAxNDJl
NDU3N2Y1YTliOTU4MzJiODJmN2I2ZDMxZmRlMTY5N2NiZTc2Cj4gPiBzdHViZG9tOiBmaXggZXJy
b3IgYXNzaWdubWVudCBpbiBncnViOmxvYWRfbW9kdWxlCj4gPiAKPiA+IFsgMTMzM3NdIG1pbmkt
b3MuYzogSW4gZnVuY3Rpb24gJ2xvYWRfbW9kdWxlJzoKPiA+IFsgMTMzM3NdIG1pbmktb3MuYzoy
NDQ6IHdhcm5pbmc6IHN0YXRlbWVudCB3aXRoIG5vIGVmZmVjdAo+ID4gCj4gPiBTaWduZWQtb2Zm
LWJ5OiBPbGFmIEhlcmluZyA8b2xhZkBhZXBmbGUuZGU+Cj4gCj4gQWNrZWQtYnk6IFNhbXVlbCBU
aGliYXVsdCA8c2FtdWVsLnRoaWJhdWx0QGVucy1seW9uLm9yZz4KCkFQcGxpZWQsIHRoYW5rcywK
CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2
ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4u
b3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Oct 11 09:22:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 09:22:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMExw-00068w-WB; Thu, 11 Oct 2012 09:22:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMExv-00068l-Gw
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 09:22:03 +0000
Received: from [85.158.139.83:50763] by server-6.bemta-5.messagelabs.com id
	91/EB-08519-ABF86705; Thu, 11 Oct 2012 09:22:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1349947321!33715407!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM4Mjk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4516 invoked from network); 11 Oct 2012 09:22:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Oct 2012 09:22:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,571,1344211200"; d="scan'208";a="15093408"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Oct 2012 09:21:52 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 11 Oct 2012 10:21:52 +0100
Message-ID: <1349947311.14806.28.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Samuel Thibault 
Date: Thu, 11 Oct 2012 10:21:51 +0100
In-Reply-To: <20121009134648.GN6113@type.bordeaux.inria.fr>
References: <384714804b9b2a9742cc.1349787869@probook.site>
	<20121009134648.GN6113@type.bordeaux.inria.fr>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Olaf Hering ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] stubdom: fix error assignment in
 grub:load_module
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCAyMDEyLTEwLTA5IGF0IDE0OjQ2ICswMTAwLCBTYW11ZWwgVGhpYmF1bHQgd3JvdGU6
Cj4gT2xhZiBIZXJpbmcsIGxlIFR1ZSAwOSBPY3QgMjAxMiAxNTowNDoyOSArMDIwMCwgYSDDqWNy
aXQgOgo+ID4gIyBIRyBjaGFuZ2VzZXQgcGF0Y2gKPiA+ICMgVXNlciBPbGFmIEhlcmluZyA8b2xh
ZkBhZXBmbGUuZGU+Cj4gPiAjIERhdGUgMTM0OTc4Nzg1NSAtNzIwMAo+ID4gIyBOb2RlIElEIDM4
NDcxNDgwNGI5YjJhOTc0MmNjNDVkZmZhYTQzYjc0OWI4NTUxM2IKPiA+ICMgUGFyZW50ICAxNDJl
NDU3N2Y1YTliOTU4MzJiODJmN2I2ZDMxZmRlMTY5N2NiZTc2Cj4gPiBzdHViZG9tOiBmaXggZXJy
b3IgYXNzaWdubWVudCBpbiBncnViOmxvYWRfbW9kdWxlCj4gPiAKPiA+IFsgMTMzM3NdIG1pbmkt
b3MuYzogSW4gZnVuY3Rpb24gJ2xvYWRfbW9kdWxlJzoKPiA+IFsgMTMzM3NdIG1pbmktb3MuYzoy
NDQ6IHdhcm5pbmc6IHN0YXRlbWVudCB3aXRoIG5vIGVmZmVjdAo+ID4gCj4gPiBTaWduZWQtb2Zm
LWJ5OiBPbGFmIEhlcmluZyA8b2xhZkBhZXBmbGUuZGU+Cj4gCj4gQWNrZWQtYnk6IFNhbXVlbCBU
aGliYXVsdCA8c2FtdWVsLnRoaWJhdWx0QGVucy1seW9uLm9yZz4KCkFQcGxpZWQsIHRoYW5rcywK
CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2
ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4u
b3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Oct 11 10:00:49 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 10:00:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMFZ1-0006XW-FI; Thu, 11 Oct 2012 10:00:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMFYy-0006XR-P8
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 10:00:21 +0000
Received: from [85.158.138.51:11654] by server-9.bemta-3.messagelabs.com id
	3E/98-16841-3B896705; Thu, 11 Oct 2012 10:00:19 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-6.tower-174.messagelabs.com!1349949613!25924142!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18923 invoked from network); 11 Oct 2012 10:00:13 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-6.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	11 Oct 2012 10:00:13 -0000
Received: from 50-66-ftth.onsneteindhoven.nl ([88.159.66.50]:52015
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TMFaC-00013r-7T; Thu, 11 Oct 2012 12:01:36 +0200
Date: Thu, 11 Oct 2012 12:00:04 +0200
From: Sander Eikelenboom 
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <151954917.20121011120004@eikelenboom.it>
To: Ian Campbell 
In-Reply-To: <1349942546.14806.7.camel@zakaz.uk.xensource.com>
References: <1349790467.21847.185.camel@zakaz.uk.xensource.com>
	<1349790863.21172.4406.camel@edumazet-glaptop>
	<1349792241.21847.199.camel@zakaz.uk.xensource.com>
	<1349792847.21172.4479.camel@edumazet-glaptop>
	<1349793630.21847.208.camel@zakaz.uk.xensource.com>
	<1349863984.10070.26.camel@zakaz.uk.xensource.com>
	<1349874598.10070.39.camel@zakaz.uk.xensource.com>
	<748966751.20121010164949@eikelenboom.it>
	<1349942546.14806.7.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------002085244038F36F8"
Cc: Konrad Rzeszutek Wilk ,
	Eric Dumazet ,
	"netdev@vger.kernel.org" ,
	Eric Dumazet , xen-devel 
Subject: Re: [Xen-devel] compound skb frag pages appearing in start_xmit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

------------002085244038F36F8
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Thursday, October 11, 2012, 10:02:26 AM, you wrote:

> On Wed, 2012-10-10 at 15:49 +0100, Sander Eikelenboom wrote:
>> Wednesday, October 10, 2012, 3:09:58 PM, you wrote:
>> 
>> > On Wed, 2012-10-10 at 11:13 +0100, Ian Campbell wrote:
>> >> I haven't tackled netfront yet. 
>> 
>> > I seem to be totally unable to reproduce the equivalent issue on the
>> > netfront xmit side, even though it seems like the loop in
>> > xennet_make_frags ought to be obviously susceptible to it.
>> 
>> > Konrad, Sander, are either of you able to repro, e.g. with:
>> 
>> 
>> Hmrrrmm i don't see any traces, only strange behaviour ..
>> 
>> - i can connect to guests by ssh, but it's sluggish, and sometimes stops working

> I saw something like this (ssh sluggish) even with dom0 itself. I'm
> trying to see if I can characterise it enough to reliably bisect it.

> I already switched out xen-unstable for 4.2-testing but that didn't make
> any difference.



>> - The guest seem to keep trying to connect to netback:
>> 
>> [  658.276719] xen_bridge: port 2(vif40.0) entered forwarding state
>> [  658.282258] xen_bridge: port 2(vif40.0) entered forwarding state
>> [  663.945964] xen_bridge: port 7(vif39.0) entered forwarding state
>> [  669.674277] xen_bridge: port 2(vif40.0) entered disabled state
>> [  669.680290] device vif40.0 left promiscuous mode
>> [  669.685464] xen_bridge: port 2(vif40.0) entered disabled state
>> [  672.857222] device vif41.0 entered promiscuous mode
>> [  673.166254] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
>> [  673.176368] xen_bridge: port 2(vif41.0) entered forwarding state
>> [  673.182042] xen_bridge: port 2(vif41.0) entered forwarding state
>> [  674.439725] xen_bridge: port 7(vif39.0) entered disabled state
>> [  674.445708] device vif39.0 left promiscuous mode
>> [  674.450955] xen_bridge: port 7(vif39.0) entered disabled state
>> [  677.726040] device vif42.0 entered promiscuous mode
>> [  678.053381] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
>> [  678.062804] xen_bridge: port 7(vif42.0) entered forwarding state
>> [  678.068433] xen_bridge: port 7(vif42.0) entered forwarding state
>> [  688.224736] xen_bridge: port 2(vif41.0) entered forwarding state
>> [  693.080557] xen_bridge: port 7(vif42.0) entered forwarding state
>> [  700.786276] xen_bridge: port 7(vif42.0) entered disabled state
>> [  700.792484] device vif42.0 left promiscuous mode
>> [  700.802409] xen_bridge: port 7(vif42.0) entered disabled state
>> [  704.133606] device vif43.0 entered promiscuous mode
>> [  704.460160] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
>> [  704.469800] xen_bridge: port 7(vif43.0) entered forwarding state
>> [  704.475303] xen_bridge: port 7(vif43.0) entered forwarding state
>> [  719.493788] xen_bridge: port 7(vif43.0) entered forwarding state
>> [  726.302456] xen_bridge: port 7(vif43.0) entered disabled state
>> [  726.308898] device vif43.0 left promiscuous mode
>> [  726.314029] xen_bridge: port 7(vif43.0) entered disabled state
>> 
>> All the guests are already up, but this keeps on going and going and going ....

> The domain number seems to be climbing, are you sure something isn't
> (crashing and) restarting?

Probably due to the BUG_ON from the patch below, i changed it into a WARN_ON.
And i seem to hit it, but only in one of the guests at the moment and it triggers quite irregularly.

[   34.298549] ------------[ cut here ]------------
[   34.298567] WARNING: at drivers/net/xen-netfront.c:465 xennet_start_xmit+0x7fe/0x860()
[   34.298574] Modules linked in:
[   34.298597] Pid: 1580, comm: sshd Not tainted 3.6.0pre-rc1-20121011 #1
[   34.298603] Call Trace:
[   34.298611]  [] warn_slowpath_common+0x7a/0xb0
[   34.298617]  [] warn_slowpath_null+0x15/0x20
[   34.298623]  [] xennet_start_xmit+0x7fe/0x860
[   34.298631]  [] dev_hard_start_xmit+0x209/0x460
[   34.298637]  [] sch_direct_xmit+0xf6/0x290
[   34.298643]  [] dev_queue_xmit+0x1a6/0x5a0
[   34.298649]  [] ? dev_hard_start_xmit+0x460/0x460
[   34.298656]  [] ? trace_softirqs_off+0x85/0x1b0
[   34.298663]  [] ip_finish_output+0x226/0x530
[   34.298668]  [] ? ip_finish_output+0xcd/0x530
[   34.298674]  [] ip_output+0x59/0xe0
[   34.298680]  [] ip_local_out+0x28/0x90
[   34.298687]  [] ip_queue_xmit+0x17f/0x4a0
[   34.298692]  [] ? ip_send_unicast_reply+0x340/0x340
[   34.298699]  [] ? getnstimeofday+0x47/0xe0
[   34.298705]  [] ? __skb_clone+0x29/0x120
[   34.298711]  [] tcp_transmit_skb+0x400/0x8d0
[   34.298717]  [] tcp_write_xmit+0x21a/0xa50
[   34.298723]  [] tcp_push_one+0x2b/0x40
[   34.298728]  [] tcp_sendmsg+0x8dc/0xe20
[   34.298735]  [] inet_sendmsg+0xa9/0x100
[   34.298740]  [] ? inet_autobind+0x70/0x70
[   34.298746]  [] ? lock_acquire+0xd8/0x100
[   34.298753]  [] sock_aio_write+0x12d/0x140
[   34.298762]  [] do_sync_write+0xa2/0xe0
[   34.298768]  [] ? trace_hardirqs_on+0xd/0x10
[   34.298774]  [] vfs_write+0x174/0x190
[   34.298779]  [] sys_write+0x5a/0xa0
[   34.298786]  [] ? trace_hardirqs_on_thunk+0x3a/0x3f
[   34.298792]  [] cstar_dispatch+0x7/0x26
[   34.298797] ---[ end trace 2e28eec93b7a8b74 ]---


Complete dmesg from guest attached.



>> > diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
>> > index b06ef81..8a3f770 100644
>> > --- a/drivers/net/xen-netfront.c
>> > +++ b/drivers/net/xen-netfront.c
>> > @@ -462,6 +462,8 @@ static void xennet_make_frags(struct sk_buff *skb, struct net_device *dev,
>> >                 ref = gnttab_claim_grant_reference(&np->gref_tx_head);
>> >                 BUG_ON((signed short)ref < 0);
>> >  
>> > +               BUG_ON(PageCompound(skb_frag_page(frag)));
>> > +
>> >                 mfn = pfn_to_mfn(page_to_pfn(skb_frag_page(frag)));
>> >                 gnttab_grant_foreign_access_ref(ref, np->xbdev->otherend_id,
>> >                                                 mfn, GNTMAP_readonly);
>> 
>> > My repro for netback was just to netcat a wodge of data from dom0->domU
>> > but going the other way doesn't seem to trigger.
>> 
>> 
>> 



------------002085244038F36F8
Content-Type: text/plain;
 name="dmesg-netfront.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="dmesg-netfront.txt"

WyAgICAwLjAwMDAwMF0gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgY3B1c2V0DQpbICAg
IDAuMDAwMDAwXSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBjcHUNClsgICAgMC4wMDAw
MDBdIExpbnV4IHZlcnNpb24gMy42LjBwcmUtcmMxLTIwMTIxMDExIChyb290QHNlcnZlZXJz
dGVydGplKSAoZ2NjIHZlcnNpb24gNC40LjUgKERlYmlhbiA0LjQuNS04KSApICMxIFNNUCBQ
UkVFTVBUIFRodSBPY3QgMTEgMTE6MDQ6MzggQ0VTVCAyMDEyDQpbICAgIDAuMDAwMDAwXSBD
b21tYW5kIGxpbmU6IHJvb3Q9L2Rldi94dmRhMSBybyANClsgICAgMC4wMDAwMDBdIEFDUEkg
aW4gdW5wcml2aWxlZ2VkIGRvbWFpbiBkaXNhYmxlZA0KWyAgICAwLjAwMDAwMF0gZTgyMDog
QklPUy1wcm92aWRlZCBwaHlzaWNhbCBSQU0gbWFwOg0KWyAgICAwLjAwMDAwMF0gWGVuOiBb
bWVtIDB4MDAwMDAwMDAwMDAwMDAwMC0weDAwMDAwMDAwMDAwOWZmZmZdIHVzYWJsZQ0KWyAg
ICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDAwMDBhMDAwMC0weDAwMDAwMDAwMDAw
ZmZmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMDAw
MTAwMDAwLTB4MDAwMDAwMDAxZmZmZmZmZl0gdXNhYmxlDQpbICAgIDAuMDAwMDAwXSBOWCAo
RXhlY3V0ZSBEaXNhYmxlKSBwcm90ZWN0aW9uOiBhY3RpdmUNClsgICAgMC4wMDAwMDBdIERN
SSBub3QgcHJlc2VudCBvciBpbnZhbGlkLg0KWyAgICAwLjAwMDAwMF0gZTgyMDogdXBkYXRl
IFttZW0gMHgwMDAwMDAwMC0weDAwMDBmZmZmXSB1c2FibGUgPT0+IHJlc2VydmVkDQpbICAg
IDAuMDAwMDAwXSBlODIwOiByZW1vdmUgW21lbSAweDAwMGEwMDAwLTB4MDAwZmZmZmZdIHVz
YWJsZQ0KWyAgICAwLjAwMDAwMF0gTm8gQUdQIGJyaWRnZSBmb3VuZA0KWyAgICAwLjAwMDAw
MF0gZTgyMDogbGFzdF9wZm4gPSAweDIwMDAwIG1heF9hcmNoX3BmbiA9IDB4NDAwMDAwMDAw
DQpbICAgIDAuMDAwMDAwXSBpbml0aWFsIG1lbW9yeSBtYXBwZWQ6IFttZW0gMHgwMDAwMDAw
MC0weDAzN2M5ZmZmXQ0KWyAgICAwLjAwMDAwMF0gQmFzZSBtZW1vcnkgdHJhbXBvbGluZSBh
dCBbZmZmZjg4MDAwMDA5YTAwMF0gOWEwMDAgc2l6ZSAyNDU3Ng0KWyAgICAwLjAwMDAwMF0g
aW5pdF9tZW1vcnlfbWFwcGluZzogW21lbSAweDAwMDAwMDAwLTB4MWZmZmZmZmZdDQpbICAg
IDAuMDAwMDAwXSAgW21lbSAweDAwMDAwMDAwLTB4MWZmZmZmZmZdIHBhZ2UgNGsNClsgICAg
MC4wMDAwMDBdIGtlcm5lbCBkaXJlY3QgbWFwcGluZyB0YWJsZXMgdXAgdG8gMHgxZmZmZmZm
ZiBAIFttZW0gMHgwMjljNDAwMC0weDAyYWM1ZmZmXQ0KWyAgICAwLjAwMDAwMF0geGVuOiBz
ZXR0aW5nIFJXIHRoZSByYW5nZSAyYWE2MDAwIC0gMmFjNjAwMA0KWyAgICAwLjAwMDAwMF0g
UkFNRElTSzogW21lbSAweDAyYWM2MDAwLTB4MDM3YzlmZmZdDQpbICAgIDAuMDAwMDAwXSBO
VU1BIHR1cm5lZCBvZmYNClsgICAgMC4wMDAwMDBdIEZha2luZyBhIG5vZGUgYXQgW21lbSAw
eDAwMDAwMDAwMDAwMDAwMDAtMHgwMDAwMDAwMDFmZmZmZmZmXQ0KWyAgICAwLjAwMDAwMF0g
SW5pdG1lbSBzZXR1cCBub2RlIDAgW21lbSAweDAwMDAwMDAwLTB4MWZmZmZmZmZdDQpbICAg
IDAuMDAwMDAwXSAgIE5PREVfREFUQSBbbWVtIDB4MWZmZjUwMDAtMHgxZmZmZmZmZl0NClsg
ICAgMC4wMDAwMDBdIFpvbmUgcmFuZ2VzOg0KWyAgICAwLjAwMDAwMF0gICBETUEgICAgICBb
bWVtIDB4MDAwMTAwMDAtMHgwMGZmZmZmZl0NClsgICAgMC4wMDAwMDBdICAgRE1BMzIgICAg
W21lbSAweDAxMDAwMDAwLTB4ZmZmZmZmZmZdDQpbICAgIDAuMDAwMDAwXSAgIE5vcm1hbCAg
IGVtcHR5DQpbICAgIDAuMDAwMDAwXSBNb3ZhYmxlIHpvbmUgc3RhcnQgZm9yIGVhY2ggbm9k
ZQ0KWyAgICAwLjAwMDAwMF0gRWFybHkgbWVtb3J5IG5vZGUgcmFuZ2VzDQpbICAgIDAuMDAw
MDAwXSAgIG5vZGUgICAwOiBbbWVtIDB4MDAwMTAwMDAtMHgwMDA5ZmZmZl0NClsgICAgMC4w
MDAwMDBdICAgbm9kZSAgIDA6IFttZW0gMHgwMDEwMDAwMC0weDFmZmZmZmZmXQ0KWyAgICAw
LjAwMDAwMF0gT24gbm9kZSAwIHRvdGFscGFnZXM6IDEzMDk2MA0KWyAgICAwLjAwMDAwMF0g
ICBETUEgem9uZTogNjQgcGFnZXMgdXNlZCBmb3IgbWVtbWFwDQpbICAgIDAuMDAwMDAwXSAg
IERNQSB6b25lOiA2IHBhZ2VzIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSAgIERNQSB6b25l
OiAzOTE0IHBhZ2VzLCBMSUZPIGJhdGNoOjANClsgICAgMC4wMDAwMDBdICAgRE1BMzIgem9u
ZTogMTk4NCBwYWdlcyB1c2VkIGZvciBtZW1tYXANClsgICAgMC4wMDAwMDBdICAgRE1BMzIg
em9uZTogMTI0OTkyIHBhZ2VzLCBMSUZPIGJhdGNoOjMxDQpbICAgIDAuMDAwMDAwXSBzbXBi
b290OiBBbGxvd2luZyAxIENQVXMsIDAgaG90cGx1ZyBDUFVzDQpbICAgIDAuMDAwMDAwXSBO
byBsb2NhbCBBUElDIHByZXNlbnQNClsgICAgMC4wMDAwMDBdIEFQSUM6IGRpc2FibGUgYXBp
YyBmYWNpbGl0eQ0KWyAgICAwLjAwMDAwMF0gQVBJQzogc3dpdGNoZWQgdG8gYXBpYyBOT09Q
DQpbICAgIDAuMDAwMDAwXSBucl9pcnFzX2dzaTogMTYNClsgICAgMC4wMDAwMDBdIGU4MjA6
IFttZW0gMHgyMDAwMDAwMC0weGZmZmZmZmZmXSBhdmFpbGFibGUgZm9yIFBDSSBkZXZpY2Vz
DQpbICAgIDAuMDAwMDAwXSBCb290aW5nIHBhcmF2aXJ0dWFsaXplZCBrZXJuZWwgb24gWGVu
DQpbICAgIDAuMDAwMDAwXSBYZW4gdmVyc2lvbjogNC4zLXVuc3RhYmxlIChwcmVzZXJ2ZS1B
RCkNClsgICAgMC4wMDAwMDBdIHNldHVwX3BlcmNwdTogTlJfQ1BVUzo4IG5yX2NwdW1hc2tf
Yml0czo4IG5yX2NwdV9pZHM6MSBucl9ub2RlX2lkczoxDQpbICAgIDAuMDAwMDAwXSBQRVJD
UFU6IEVtYmVkZGVkIDI3IHBhZ2VzL2NwdSBAZmZmZjg4MDAxZmMwMDAwMCBzODEwODggcjgx
OTIgZDIxMzEyIHUyMDk3MTUyDQpbICAgIDAuMDAwMDAwXSBwY3B1LWFsbG9jOiBzODEwODgg
cjgxOTIgZDIxMzEyIHUyMDk3MTUyIGFsbG9jPTEqMjA5NzE1Mg0KWyAgICAwLjAwMDAwMF0g
cGNwdS1hbGxvYzogWzBdIDAgDQpbICAgIDAuMDAwMDAwXSBCdWlsdCAxIHpvbmVsaXN0cyBp
biBOb2RlIG9yZGVyLCBtb2JpbGl0eSBncm91cGluZyBvbi4gIFRvdGFsIHBhZ2VzOiAxMjg5
MDYNClsgICAgMC4wMDAwMDBdIFBvbGljeSB6b25lOiBETUEzMg0KWyAgICAwLjAwMDAwMF0g
S2VybmVsIGNvbW1hbmQgbGluZTogcm9vdD0vZGV2L3h2ZGExIHJvIA0KWyAgICAwLjAwMDAw
MF0gUElEIGhhc2ggdGFibGUgZW50cmllczogMjA0OCAob3JkZXI6IDIsIDE2Mzg0IGJ5dGVz
KQ0KWyAgICAwLjAwMDAwMF0gX19leF90YWJsZSBhbHJlYWR5IHNvcnRlZCwgc2tpcHBpbmcg
c29ydA0KWyAgICAwLjAwMDAwMF0gQ2hlY2tpbmcgYXBlcnR1cmUuLi4NClsgICAgMC4wMDAw
MDBdIE5vIEFHUCBicmlkZ2UgZm91bmQNClsgICAgMC4wMDAwMDBdIE1lbW9yeTogNDc2NzI0
ay81MjQyODhrIGF2YWlsYWJsZSAoNzQ3Mmsga2VybmVsIGNvZGUsIDQ0OGsgYWJzZW50LCA0
NzExNmsgcmVzZXJ2ZWQsIDU2MjZrIGRhdGEsIDY5NmsgaW5pdCkNClsgICAgMC4wMDAwMDBd
IFNMVUI6IEdlbnNsYWJzPTE1LCBIV2FsaWduPTY0LCBPcmRlcj0wLTMsIE1pbk9iamVjdHM9
MCwgQ1BVcz0xLCBOb2Rlcz0xDQpbICAgIDAuMDAwMDAwXSBQcmVlbXB0aWJsZSBoaWVyYXJj
aGljYWwgUkNVIGltcGxlbWVudGF0aW9uLg0KWyAgICAwLjAwMDAwMF0gCVJDVSBkeW50aWNr
LWlkbGUgZ3JhY2UtcGVyaW9kIGFjY2VsZXJhdGlvbiBpcyBlbmFibGVkLg0KWyAgICAwLjAw
MDAwMF0gCUFkZGl0aW9uYWwgcGVyLUNQVSBpbmZvIHByaW50ZWQgd2l0aCBzdGFsbHMuDQpb
ICAgIDAuMDAwMDAwXSAJUkNVIHJlc3RyaWN0aW5nIENQVXMgZnJvbSBOUl9DUFVTPTggdG8g
bnJfY3B1X2lkcz0xLg0KWyAgICAwLjAwMDAwMF0gTlJfSVJRUzo0MzUyIG5yX2lycXM6MjU2
IDE2DQpbICAgIDAuMDAwMDAwXSBDb25zb2xlOiBjb2xvdXIgZHVtbXkgZGV2aWNlIDgweDI1
DQpbICAgIDAuMDAwMDAwXSBjb25zb2xlIFt0dHkwXSBlbmFibGVkDQpbICAgIDAuMDAwMDAw
XSBjb25zb2xlIFtodmMwXSBlbmFibGVkDQpbICAgIDAuMDAwMDAwXSBMb2NrIGRlcGVuZGVu
Y3kgdmFsaWRhdG9yOiBDb3B5cmlnaHQgKGMpIDIwMDYgUmVkIEhhdCwgSW5jLiwgSW5nbyBN
b2xuYXINClsgICAgMC4wMDAwMDBdIC4uLiBNQVhfTE9DS0RFUF9TVUJDTEFTU0VTOiAgOA0K
WyAgICAwLjAwMDAwMF0gLi4uIE1BWF9MT0NLX0RFUFRIOiAgICAgICAgICA0OA0KWyAgICAw
LjAwMDAwMF0gLi4uIE1BWF9MT0NLREVQX0tFWVM6ICAgICAgICA4MTkxDQpbICAgIDAuMDAw
MDAwXSAuLi4gQ0xBU1NIQVNIX1NJWkU6ICAgICAgICAgIDQwOTYNClsgICAgMC4wMDAwMDBd
IC4uLiBNQVhfTE9DS0RFUF9FTlRSSUVTOiAgICAgMTYzODQNClsgICAgMC4wMDAwMDBdIC4u
LiBNQVhfTE9DS0RFUF9DSEFJTlM6ICAgICAgMzI3NjgNClsgICAgMC4wMDAwMDBdIC4uLiBD
SEFJTkhBU0hfU0laRTogICAgICAgICAgMTYzODQNClsgICAgMC4wMDAwMDBdICBtZW1vcnkg
dXNlZCBieSBsb2NrIGRlcGVuZGVuY3kgaW5mbzogNTg1NSBrQg0KWyAgICAwLjAwMDAwMF0g
IHBlciB0YXNrLXN0cnVjdCBtZW1vcnkgZm9vdHByaW50OiAxOTIwIGJ5dGVzDQpbICAgIDAu
MDAwMDAwXSBYZW46IHVzaW5nIHZjcHVvcCB0aW1lciBpbnRlcmZhY2UNClsgICAgMC4wMDAw
MDBdIGluc3RhbGxpbmcgWGVuIHRpbWVyIGZvciBDUFUgMA0KWyAgICAwLjAwMDAwMF0gdHNj
OiBEZXRlY3RlZCAzMjAwLjE0NCBNSHogcHJvY2Vzc29yDQpbICAgIDAuMDAzMzMzXSBDYWxp
YnJhdGluZyBkZWxheSBsb29wIChza2lwcGVkKSwgdmFsdWUgY2FsY3VsYXRlZCB1c2luZyB0
aW1lciBmcmVxdWVuY3kuLiA2NDAyLjk2IEJvZ29NSVBTIChscGo9MTA2NjcxNDYpDQpbICAg
IDAuMDAzMzMzXSBwaWRfbWF4OiBkZWZhdWx0OiAzMjc2OCBtaW5pbXVtOiAzMDENClsgICAg
MC4wMDMzMzNdIERlbnRyeSBjYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDY1NTM2IChvcmRl
cjogNywgNTI0Mjg4IGJ5dGVzKQ0KWyAgICAwLjAwMzMzM10gSW5vZGUtY2FjaGUgaGFzaCB0
YWJsZSBlbnRyaWVzOiAzMjc2OCAob3JkZXI6IDYsIDI2MjE0NCBieXRlcykNClsgICAgMC4w
MDMzMzNdIE1vdW50LWNhY2hlIGhhc2ggdGFibGUgZW50cmllczogMjU2DQpbICAgIDAuMDAz
MzMzXSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBjcHVhY2N0DQpbICAgIDAuMDAzMzMz
XSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBmcmVlemVyDQpbICAgIDAuMDAzMzMzXSBJ
bml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBibGtpbw0KWyAgICAwLjAwMzMzM10gdHNlZzog
MDAwMDAwMDAwMA0KWyAgICAwLjAwMzMzM10gQ1BVOiBQaHlzaWNhbCBQcm9jZXNzb3IgSUQ6
IDANClsgICAgMC4wMDMzMzNdIENQVTogUHJvY2Vzc29yIENvcmUgSUQ6IDENClsgICAgMC4w
MDMzMzNdIExhc3QgbGV2ZWwgaVRMQiBlbnRyaWVzOiA0S0IgNTEyLCAyTUIgMTYsIDRNQiA4
DQpbICAgIDAuMDAzMzMzXSBMYXN0IGxldmVsIGRUTEIgZW50cmllczogNEtCIDUxMiwgMk1C
IDEyOCwgNE1CIDY0DQpbICAgIDAuMDAzMzMzXSB0bGJfZmx1c2hhbGxfc2hpZnQ6IDQNClsg
ICAgMC4wMjUzNjNdIEZyZWVpbmcgU01QIGFsdGVybmF0aXZlczogMjRrIGZyZWVkDQpbICAg
IDAuMDI2MTc0XSBQZXJmb3JtYW5jZSBFdmVudHM6IA0KWyAgICAwLjAyNjE4N10gbm8gQVBJ
QywgYm9vdCB3aXRoIHRoZSAibGFwaWMiIGJvb3QgcGFyYW1ldGVyIHRvIGZvcmNlLWVuYWJs
ZSBpdC4NClsgICAgMC4wMjYxOTNdIG5vIGhhcmR3YXJlIHNhbXBsaW5nIGludGVycnVwdCBh
dmFpbGFibGUuDQpbICAgIDAuMDI2MjE1XSBCcm9rZW4gUE1VIGhhcmR3YXJlIGRldGVjdGVk
LCB1c2luZyBzb2Z0d2FyZSBldmVudHMgb25seS4NClsgICAgMC4wMjYyMjBdIEZhaWxlZCB0
byBhY2Nlc3MgcGVyZmN0ciBtc3IgKE1TUiBjMDAxMDAwNCBpcyAyMTg1YzUyYjYzOGYpDQpb
ICAgIDAuMDQzNTQ5XSBCcm91Z2h0IHVwIDEgQ1BVcw0KWyAgICAwLjA0MzYzNF0gTk1JIHdh
dGNoZG9nOiBkaXNhYmxlZCAoY3B1MCk6IGhhcmR3YXJlIGV2ZW50cyBub3QgZW5hYmxlZA0K
WyAgICAwLjA0NDA3OV0gR3JhbnQgdGFibGVzIHVzaW5nIHZlcnNpb24gMiBsYXlvdXQuDQpb
ICAgIDAuMDQ0MTAzXSBHcmFudCB0YWJsZSBpbml0aWFsaXplZA0KWyAgICAwLjA0NDIyNV0g
TkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAxNg0KWyAgICAwLjA0NTQ5OV0gUENJ
OiBzZXR0aW5nIHVwIFhlbiBQQ0kgZnJvbnRlbmQgc3R1Yg0KWyAgICAwLjA0NTQ5OV0gUENJ
OiBwY2lfY2FjaGVfbGluZV9zaXplIHNldCB0byA2NCBieXRlcw0KWyAgICAwLjA2MzA5NF0g
YmlvOiBjcmVhdGUgc2xhYiA8YmlvLTA+IGF0IDANClsgICAgMC4wNjMzMjNdIEFDUEk6IElu
dGVycHJldGVyIGRpc2FibGVkLg0KWyAgICAwLjA2MzUxN10geGVuL2JhbGxvb246IEluaXRp
YWxpc2luZyBiYWxsb29uIGRyaXZlci4NClsgICAgMC4wNjM1OTRdIHhlbi1iYWxsb29uOiBJ
bml0aWFsaXNpbmcgYmFsbG9vbiBkcml2ZXIuDQpbICAgIDAuMDYzNTk0XSB2Z2FhcmI6IGxv
YWRlZA0KWyAgICAwLjA2Mzc5NV0gU0NTSSBzdWJzeXN0ZW0gaW5pdGlhbGl6ZWQNClsgICAg
MC4wNjM5MzFdIGxpYmF0YSB2ZXJzaW9uIDMuMDAgbG9hZGVkLg0KWyAgICAwLjA2NDIxMF0g
dXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciB1c2Jmcw0KWyAgICAw
LjA2NDI3MF0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBodWIN
ClsgICAgMC4wNjQzNDZdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGRldmljZSBkcml2ZXIg
dXNiDQpbICAgIDAuMDY0NDgyXSBMaW51eCB2aWRlbyBjYXB0dXJlIGludGVyZmFjZTogdjIu
MDANClsgICAgMC4wNjQ4MDldIEFkdmFuY2VkIExpbnV4IFNvdW5kIEFyY2hpdGVjdHVyZSBE
cml2ZXIgSW5pdGlhbGl6ZWQuDQpbICAgIDAuMDY0ODE1XSBQQ0k6IFN5c3RlbSBkb2VzIG5v
dCBzdXBwb3J0IFBDSQ0KWyAgICAwLjA2NDgxOV0gUENJOiBTeXN0ZW0gZG9lcyBub3Qgc3Vw
cG9ydCBQQ0kNClsgICAgMC4wNjcxMzddIFN3aXRjaGluZyB0byBjbG9ja3NvdXJjZSB4ZW4N
ClsgICAgMC4wNjczODhdIHBucDogUG5QIEFDUEk6IGRpc2FibGVkDQpbICAgIDAuMDcxMjQ3
XSBORVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDINClsgICAgMC4wNzE0NzldIFRD
UCBlc3RhYmxpc2hlZCBoYXNoIHRhYmxlIGVudHJpZXM6IDE2Mzg0IChvcmRlcjogNiwgMjYy
MTQ0IGJ5dGVzKQ0KWyAgICAwLjA3MTY4MF0gVENQIGJpbmQgaGFzaCB0YWJsZSBlbnRyaWVz
OiAxNjM4NCAob3JkZXI6IDgsIDEwNDg1NzYgYnl0ZXMpDQpbICAgIDAuMDcyNTA1XSBUQ1A6
IEhhc2ggdGFibGVzIGNvbmZpZ3VyZWQgKGVzdGFibGlzaGVkIDE2Mzg0IGJpbmQgMTYzODQp
DQpbICAgIDAuMDcyNTU3XSBUQ1A6IHJlbm8gcmVnaXN0ZXJlZA0KWyAgICAwLjA3MjU3NF0g
VURQIGhhc2ggdGFibGUgZW50cmllczogMjU2IChvcmRlcjogMywgNDA5NjAgYnl0ZXMpDQpb
ICAgIDAuMDcyNjEyXSBVRFAtTGl0ZSBoYXNoIHRhYmxlIGVudHJpZXM6IDI1NiAob3JkZXI6
IDMsIDQwOTYwIGJ5dGVzKQ0KWyAgICAwLjA3Mjc1NV0gTkVUOiBSZWdpc3RlcmVkIHByb3Rv
Y29sIGZhbWlseSAxDQpbICAgIDAuMDcyNzY3XSBQQ0k6IENMUyAwIGJ5dGVzLCBkZWZhdWx0
IDY0DQpbICAgIDAuMDcyOTEyXSBUcnlpbmcgdG8gdW5wYWNrIHJvb3RmcyBpbWFnZSBhcyBp
bml0cmFtZnMuLi4NClsgICAgMC4wOTQyMzRdIEZyZWVpbmcgaW5pdHJkIG1lbW9yeTogMTMz
MjhrIGZyZWVkDQpbICAgIDAuMTAxMTk0XSBETUEtQVBJOiBwcmVhbGxvY2F0ZWQgMzI3Njgg
ZGVidWcgZW50cmllcw0KWyAgICAwLjEwMTIwNl0gRE1BLUFQSTogZGVidWdnaW5nIGVuYWJs
ZWQgYnkga2VybmVsIGNvbmZpZw0KWyAgICAwLjEwMTQyMF0gcGxhdGZvcm0gcnRjX2Ntb3M6
IHJlZ2lzdGVyZWQgcGxhdGZvcm0gUlRDIGRldmljZSAobm8gUE5QIGRldmljZSBmb3VuZCkN
ClsgICAgMC4xMDI1NDldIHNoYTFfc3NzZTM6IE5laXRoZXIgQVZYIG5vciBTU1NFMyBpcyBh
dmFpbGFibGUvdXNhYmxlLg0KWyAgICAwLjEwMjkxNV0gYXVkaXQ6IGluaXRpYWxpemluZyBu
ZXRsaW5rIHNvY2tldCAoZGlzYWJsZWQpDQpbICAgIDAuMTAyOTQ4XSB0eXBlPTIwMDAgYXVk
aXQoMTM0OTk0ODA1MC44MjU6MSk6IGluaXRpYWxpemVkDQpbICAgIDAuMTAzNDcwXSBIdWdl
VExCIHJlZ2lzdGVyZWQgMiBNQiBwYWdlIHNpemUsIHByZS1hbGxvY2F0ZWQgMCBwYWdlcw0K
WyAgICAwLjEwODkxMl0gVkZTOiBEaXNrIHF1b3RhcyBkcXVvdF82LjUuMg0KWyAgICAwLjEw
OTAyMV0gRHF1b3QtY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiA1MTIgKG9yZGVyIDAsIDQw
OTYgYnl0ZXMpDQpbICAgIDAuMTEwNTQwXSBOVEZTIGRyaXZlciAyLjEuMzAgW0ZsYWdzOiBS
L1ddLg0KWyAgICAwLjExMDc1OF0gZnVzZSBpbml0IChBUEkgdmVyc2lvbiA3LjIwKQ0KWyAg
ICAwLjExMDk2MF0gbXNnbW5pIGhhcyBiZWVuIHNldCB0byA5NTcNClsgICAgMC4xMTE2NzNd
IEJsb2NrIGxheWVyIFNDU0kgZ2VuZXJpYyAoYnNnKSBkcml2ZXIgdmVyc2lvbiAwLjQgbG9h
ZGVkIChtYWpvciAyNTIpDQpbICAgIDAuMTExNjk1XSBpbyBzY2hlZHVsZXIgbm9vcCByZWdp
c3RlcmVkDQpbICAgIDAuMTExNjk5XSBpbyBzY2hlZHVsZXIgZGVhZGxpbmUgcmVnaXN0ZXJl
ZA0KWyAgICAwLjExMTg4MF0gaW8gc2NoZWR1bGVyIGNmcSByZWdpc3RlcmVkIChkZWZhdWx0
KQ0KWyAgICAwLjExMjkwOF0gY3JjMzI6IENSQ19MRV9CSVRTID0gNjQsIENSQ19CRSBCSVRT
ID0gNjQNClsgICAgMC4xMTI5MTJdIGNyYzMyOiBzZWxmIHRlc3RzIHBhc3NlZCwgcHJvY2Vz
c2VkIDIyNTk0NCBieXRlcyBpbiAxMTI1ODAgbnNlYw0KWyAgICAwLjExMzAyMV0gY3JjMzJj
OiBDUkNfTEVfQklUUyA9IDY0DQpbICAgIDAuMTE3MjI2XSBjcmMzMmM6IHNlbGYgdGVzdHMg
cGFzc2VkLCBwcm9jZXNzZWQgMjI1OTQ0IGJ5dGVzIGluIDUwMzMzIG5zZWMNClsgICAgMC4x
MTc1NzZdIHBjaV9ob3RwbHVnOiBQQ0kgSG90IFBsdWcgUENJIENvcmUgdmVyc2lvbjogMC41
DQpbICAgIDAuMTE3Nzk3XSBwY2llaHA6IFBDSSBFeHByZXNzIEhvdCBQbHVnIENvbnRyb2xs
ZXIgRHJpdmVyIHZlcnNpb246IDAuNA0KWyAgICAwLjExODAxM10gdXNiY29yZTogcmVnaXN0
ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciB1ZGxmYg0KWyAgICAwLjExODQ2N10gRXZlbnQt
Y2hhbm5lbCBkZXZpY2UgaW5zdGFsbGVkLg0KWyAgICAwLjExOTIxM10gU2VyaWFsOiA4MjUw
LzE2NTUwIGRyaXZlciwgNCBwb3J0cywgSVJRIHNoYXJpbmcgZW5hYmxlZA0KWyAgICAwLjEy
MDA1NV0gTGludXggYWdwZ2FydCBpbnRlcmZhY2UgdjAuMTAzDQpbICAgIDAuMTIwMzc0XSBI
YW5nY2hlY2s6IHN0YXJ0aW5nIGhhbmdjaGVjayB0aW1lciAwLjkuMSAodGljayBpcyAxODAg
c2Vjb25kcywgbWFyZ2luIGlzIDYwIHNlY29uZHMpLg0KWyAgICAwLjEyMDM4M10gSGFuZ2No
ZWNrOiBVc2luZyBnZXRyYXdtb25vdG9uaWMoKS4NClsgICAgMC4xMjA0NDNdIFtkcm1dIElu
aXRpYWxpemVkIGRybSAxLjEuMCAyMDA2MDgxMA0KWyAgICAwLjEyMzI2OF0gYnJkOiBtb2R1
bGUgbG9hZGVkDQpbICAgIDAuMTI0ODU5XSBsb29wOiBtb2R1bGUgbG9hZGVkDQpbICAgIDAu
MTI3Nzc4XSB0dW46IFVuaXZlcnNhbCBUVU4vVEFQIGRldmljZSBkcml2ZXIsIDEuNg0KWyAg
ICAwLjEyNzc5Ml0gdHVuOiAoQykgMTk5OS0yMDA0IE1heCBLcmFzbnlhbnNreSA8bWF4a0Bx
dWFsY29tbS5jb20+DQpbICAgIDAuMTI3ODczXSBlMTAwMDogSW50ZWwoUikgUFJPLzEwMDAg
TmV0d29yayBEcml2ZXIgLSB2ZXJzaW9uIDcuMy4yMS1rOC1OQVBJDQpbICAgIDAuMTI3ODgw
XSBlMTAwMDogQ29weXJpZ2h0IChjKSAxOTk5LTIwMDYgSW50ZWwgQ29ycG9yYXRpb24uDQpb
ICAgIDAuMTI4MDA0XSBJbml0aWFsaXNpbmcgWGVuIHZpcnR1YWwgZXRoZXJuZXQgZHJpdmVy
Lg0KWyAgICAwLjEzMzA1OF0gZWhjaV9oY2Q6IFVTQiAyLjAgJ0VuaGFuY2VkJyBIb3N0IENv
bnRyb2xsZXIgKEVIQ0kpIERyaXZlcg0KWyAgICAwLjEzMzA3MV0gZWhjaV9oY2Q6IGJsb2Nr
IHNpemVzOiBxaCAxMDQgcXRkIDk2IGl0ZCAxOTIgc2l0ZCA5Ng0KWyAgICAwLjEzMzEzMF0g
b2hjaV9oY2Q6IFVTQiAxLjEgJ09wZW4nIEhvc3QgQ29udHJvbGxlciAoT0hDSSkgRHJpdmVy
DQpbICAgIDAuMTMzMTM2XSBvaGNpX2hjZDogYmxvY2sgc2l6ZXM6IGVkIDgwIHRkIDk2DQpb
ICAgIDAuMTMzMTg4XSB1aGNpX2hjZDogVVNCIFVuaXZlcnNhbCBIb3N0IENvbnRyb2xsZXIg
SW50ZXJmYWNlIGRyaXZlcg0KWyAgICAwLjEzMzMwMV0gdXNiY29yZTogcmVnaXN0ZXJlZCBu
ZXcgaW50ZXJmYWNlIGRyaXZlciB1c2JscA0KWyAgICAwLjEzMzMwNl0gSW5pdGlhbGl6aW5n
IFVTQiBNYXNzIFN0b3JhZ2UgZHJpdmVyLi4uDQpbICAgIDAuMTMzMzU5XSB1c2Jjb3JlOiBy
ZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHVzYi1zdG9yYWdlDQpbICAgIDAuMTMz
MzY0XSBVU0IgTWFzcyBTdG9yYWdlIHN1cHBvcnQgcmVnaXN0ZXJlZC4NClsgICAgMC4xMzM0
OTddIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgdXNic2VyaWFs
DQpbICAgIDAuMTMzNTY4XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJp
dmVyIGNwMjEweA0KWyAgICAwLjEzMzcwMV0gdXNic2VyaWFsOiBVU0IgU2VyaWFsIHN1cHBv
cnQgcmVnaXN0ZXJlZCBmb3IgY3AyMTB4DQpbICAgIDAuMTMzNzU4XSB1c2Jjb3JlOiByZWdp
c3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIGN5cHJlc3NfbTgNClsgICAgMC4xMzM4MTVd
IHVzYnNlcmlhbDogVVNCIFNlcmlhbCBzdXBwb3J0IHJlZ2lzdGVyZWQgZm9yIERlTG9ybWUg
RWFydGhtYXRlIFVTQg0KWyAgICAwLjEzMzg3Ml0gdXNic2VyaWFsOiBVU0IgU2VyaWFsIHN1
cHBvcnQgcmVnaXN0ZXJlZCBmb3IgSElELT5DT00gUlMyMzIgQWRhcHRlcg0KWyAgICAwLjEz
MzkzMV0gdXNic2VyaWFsOiBVU0IgU2VyaWFsIHN1cHBvcnQgcmVnaXN0ZXJlZCBmb3IgTm9r
aWEgQ0EtNDIgVjIgQWRhcHRlcg0KWyAgICAwLjEzMzk4OV0gdXNiY29yZTogcmVnaXN0ZXJl
ZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBtb3M3NzIwDQpbICAgIDAuMTM0MDQ1XSB1c2JzZXJp
YWw6IFVTQiBTZXJpYWwgc3VwcG9ydCByZWdpc3RlcmVkIGZvciBNb3NjaGlwIDIgcG9ydCBh
ZGFwdGVyDQpbICAgIDAuMTM0MTAyXSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZh
Y2UgZHJpdmVyIG1vczc4NDANClsgICAgMC4xMzQxNThdIHVzYnNlcmlhbDogVVNCIFNlcmlh
bCBzdXBwb3J0IHJlZ2lzdGVyZWQgZm9yIE1vc2NoaXAgNzg0MC83ODIwIFVTQiBTZXJpYWwg
RHJpdmVyDQpbICAgIDAuMTM0MzYwXSBpODA0MjogUE5QOiBObyBQUy8yIGNvbnRyb2xsZXIg
Zm91bmQuIFByb2JpbmcgcG9ydHMgZGlyZWN0bHkuDQpbICAgIDAuMTM1MTkwXSBpODA0Mjog
Tm8gY29udHJvbGxlciBmb3VuZA0KWyAgICAwLjEzNTI4NF0gbW91c2VkZXY6IFBTLzIgbW91
c2UgZGV2aWNlIGNvbW1vbiBmb3IgYWxsIG1pY2UNClsgICAgMC4xMzc1MjBdIGJsa2Zyb250
OiB4dmRhOiBmbHVzaCBkaXNrY2FjaGU6IGVuYWJsZWQNClsgICAgMC4xOTYwNTRdIHJ0Y19j
bW9zIHJ0Y19jbW9zOiBydGMgY29yZTogcmVnaXN0ZXJlZCBydGNfY21vcyBhcyBydGMwDQpb
ICAgIDAuMTk2NDM4XSBpZGFfcmVtb3ZlIGNhbGxlZCBmb3IgaWQ9MCB3aGljaCBpcyBub3Qg
YWxsb2NhdGVkLg0KWyAgICAwLjE5NjQ0OF0gcnRjX2Ntb3M6IHByb2JlIG9mIHJ0Y19jbW9z
IGZhaWxlZCB3aXRoIGVycm9yIC0zOA0KWyAgICAwLjE5NzAwOV0gbGlyY19kZXY6IElSIFJl
bW90ZSBDb250cm9sIGRyaXZlciByZWdpc3RlcmVkLCBtYWpvciAyNTAgDQpbICAgIDAuMTk3
MDI3XSBJUiBORUMgcHJvdG9jb2wgaGFuZGxlciBpbml0aWFsaXplZA0KWyAgICAwLjE5NzAz
MV0gSVIgUkM1KHgpIHByb3RvY29sIGhhbmRsZXIgaW5pdGlhbGl6ZWQNClsgICAgMC4xOTcw
MzVdIElSIFJDNiBwcm90b2NvbCBoYW5kbGVyIGluaXRpYWxpemVkDQpbICAgIDAuMTk3MDM4
XSBJUiBKVkMgcHJvdG9jb2wgaGFuZGxlciBpbml0aWFsaXplZA0KWyAgICAwLjE5NzA0MV0g
SVIgU29ueSBwcm90b2NvbCBoYW5kbGVyIGluaXRpYWxpemVkDQpbICAgIDAuMTk3MDQ1XSBJ
UiBSQzUgKHN0cmVhbXphcCkgcHJvdG9jb2wgaGFuZGxlciBpbml0aWFsaXplZA0KWyAgICAw
LjE5NzA0OV0gSVIgU0FOWU8gcHJvdG9jb2wgaGFuZGxlciBpbml0aWFsaXplZA0KWyAgICAw
LjE5NzA1Ml0gSVIgTUNFIEtleWJvYXJkL21vdXNlIHByb3RvY29sIGhhbmRsZXIgaW5pdGlh
bGl6ZWQNClsgICAgMC4xOTcwNTddIElSIExJUkMgYnJpZGdlIGhhbmRsZXIgaW5pdGlhbGl6
ZWQNClsgICAgMC4xOTcyNjhdIHNwNTEwMF90Y286IFNQNTEwMCBUQ08gV2F0Y2hEb2cgVGlt
ZXIgRHJpdmVyIHYwLjAxDQpbICAgIDAuMTk3MzgyXSB4ZW5fd2R0OiBYZW4gV2F0Y2hEb2cg
VGltZXIgRHJpdmVyIHYwLjAxDQpbICAgIDAuMTk3NTc4XSB4ZW5fd2R0OiBpbml0aWFsaXpl
ZCAodGltZW91dD02MHMsIG5vd2F5b3V0PTApDQpbICAgIDAuMTk3ODIwXSBkZXZpY2UtbWFw
cGVyOiBpb2N0bDogNC4yMy4wLWlvY3RsICgyMDEyLTA3LTI1KSBpbml0aWFsaXNlZDogZG0t
ZGV2ZWxAcmVkaGF0LmNvbQ0KWyAgICAwLjE5OTEyM10gdXNiY29yZTogcmVnaXN0ZXJlZCBu
ZXcgaW50ZXJmYWNlIGRyaXZlciB1c2JoaWQNClsgICAgMC4xOTkxMjldIHVzYmhpZDogVVNC
IEhJRCBjb3JlIGRyaXZlcg0KWyAgICAwLjIwMjMxM10gdXNiY29yZTogcmVnaXN0ZXJlZCBu
ZXcgaW50ZXJmYWNlIGRyaXZlciBzbmQtdXNiLWF1ZGlvDQpbICAgIDAuMjAyMzczXSB1c2Jj
b3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHNuZC11YTEwMQ0KWyAgICAw
LjIwMjQzNF0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBzbmQt
dXNiLXVzeDJ5DQpbICAgIDAuMjAyNDg4XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRl
cmZhY2UgZHJpdmVyIHNuZC11c2ItY2FpYXENClsgICAgMC4yMDI1NDNdIHVzYmNvcmU6IHJl
Z2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgc25kLXVzYi02ZmlyZQ0KWyAgICAwLjIw
MjU3NV0gTmV0ZmlsdGVyIG1lc3NhZ2VzIHZpYSBORVRMSU5LIHYwLjMwLg0KWyAgICAwLjIw
MjU4M10gbmZubF9hY2N0OiByZWdpc3RlcmluZyB3aXRoIG5mbmV0bGluay4NClsgICAgMC4y
MDI2MjZdIG5mX2Nvbm50cmFjayB2ZXJzaW9uIDAuNS4wICgzODI4IGJ1Y2tldHMsIDE1MzEy
IG1heCkNClsgICAgMC4yMDI5NTBdIGN0bmV0bGluayB2MC45MzogcmVnaXN0ZXJpbmcgd2l0
aCBuZm5ldGxpbmsuDQpbICAgIDAuMjAzMjUwXSB4dF90aW1lOiBrZXJuZWwgdGltZXpvbmUg
aXMgLTAwMDANClsgICAgMC4zMTY4NDhdIGlwX3NldDogcHJvdG9jb2wgNg0KWyAgICAwLjMx
Njg3NV0gSVBWUzogUmVnaXN0ZXJlZCBwcm90b2NvbHMgKCkNClsgICAgMC4zMTY5OTZdIElQ
VlM6IENvbm5lY3Rpb24gaGFzaCB0YWJsZSBjb25maWd1cmVkIChzaXplPTQwOTYsIG1lbW9y
eT02NEtieXRlcykNClsgICAgMC4zMTcwNjhdIElQVlM6IENyZWF0aW5nIG5ldG5zIHNpemU9
MTg5NiBpZD0wDQpbICAgIDAuMzE3MTAwXSBJUFZTOiBpcHZzIGxvYWRlZC4NClsgICAgMC4z
MTcyMTNdIGlwX3RhYmxlczogKEMpIDIwMDAtMjAwNiBOZXRmaWx0ZXIgQ29yZSBUZWFtDQpb
ICAgIDAuMzE3Mjc5XSBUQ1A6IGN1YmljIHJlZ2lzdGVyZWQNClsgICAgMC4zMTcyODVdIE5F
VDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMTcNClsgICAgMC4zMTczNDBdIEJyaWRn
ZSBmaXJld2FsbGluZyByZWdpc3RlcmVkDQpbICAgIDAuMzE3MzU5XSBFYnRhYmxlcyB2Mi4w
IHJlZ2lzdGVyZWQNClsgICAgMC4zMTc2MTddIHJlZ2lzdGVyZWQgdGFza3N0YXRzIHZlcnNp
b24gMQ0KWyAgICAwLjc4MjEzNF0gIHh2ZGE6IHh2ZGExIHh2ZGEyDQpbICAgIDAuODE3MTQw
XSBjb25zb2xlIFtuZXRjb24wXSBlbmFibGVkDQpbICAgIDAuODE3MTY2XSBuZXRjb25zb2xl
OiBuZXR3b3JrIGxvZ2dpbmcgc3RhcnRlZA0KWyAgICAwLjgxNzM2OF0gQUxTQSBkZXZpY2Ug
bGlzdDoNClsgICAgMC44MTczODVdICAgTm8gc291bmRjYXJkcyBmb3VuZC4NClsgICAgMC44
MjA0MjVdIEZyZWVpbmcgdW51c2VkIGtlcm5lbCBtZW1vcnk6IDY5NmsgZnJlZWQNClsgICAg
MC44MjA4ODddIFdyaXRlIHByb3RlY3RpbmcgdGhlIGtlcm5lbCByZWFkLW9ubHkgZGF0YTog
MTIyODhrDQpbICAgIDAuODM3ODMwXSBGcmVlaW5nIHVudXNlZCBrZXJuZWwgbWVtb3J5OiA3
MDhrIGZyZWVkDQpbICAgIDAuODM5OTM3XSBGcmVlaW5nIHVudXNlZCBrZXJuZWwgbWVtb3J5
OiAxMDc2ayBmcmVlZA0KWyAgICAzLjg3MTU4MV0gRVhUNC1mcyAoeHZkYTEpOiBtb3VudGVk
IGZpbGVzeXN0ZW0gd2l0aCBvcmRlcmVkIGRhdGEgbW9kZS4gT3B0czogKG51bGwpDQpbICAg
MTMuNDg2MTE1XSBBZGRpbmcgNzY5MDIwayBzd2FwIG9uIC9kZXYveHZkYTIuICBQcmlvcml0
eTotMSBleHRlbnRzOjEgYWNyb3NzOjc2OTAyMGsgU1MNClsgICAxMy41MjkxMzRdIEVYVDQt
ZnMgKHh2ZGExKTogcmUtbW91bnRlZC4gT3B0czogKG51bGwpDQpbICAgMTQuNDQ5MjA2XSBF
WFQ0LWZzICh4dmRhMSk6IHJlLW1vdW50ZWQuIE9wdHM6IGVycm9ycz1yZW1vdW50LXJvDQpb
ICAgMjIuOTY3Mzk3XSB0dHlfaW5pdF9kZXY6IDIgY2FsbGJhY2tzIHN1cHByZXNzZWQNClsg
ICAyMi45Njc2OTJdIHR0eVMwOiBMU1Igc2FmZXR5IGNoZWNrIGVuZ2FnZWQhDQpbICAgMjIu
OTcwMzM0XSB0dHlTMDogTFNSIHNhZmV0eSBjaGVjayBlbmdhZ2VkIQ0KWyAgIDIyLjk3Mjk1
Nl0gdHR5UzE6IExTUiBzYWZldHkgY2hlY2sgZW5nYWdlZCENClsgICAyMi45NzQ4MTFdIHR0
eVMxOiBMU1Igc2FmZXR5IGNoZWNrIGVuZ2FnZWQhDQpbICAgMzQuMjk4NTQ5XSAtLS0tLS0t
LS0tLS1bIGN1dCBoZXJlIF0tLS0tLS0tLS0tLS0NClsgICAzNC4yOTg1NjddIFdBUk5JTkc6
IGF0IGRyaXZlcnMvbmV0L3hlbi1uZXRmcm9udC5jOjQ2NSB4ZW5uZXRfc3RhcnRfeG1pdCsw
eDdmZS8weDg2MCgpDQpbICAgMzQuMjk4NTc0XSBNb2R1bGVzIGxpbmtlZCBpbjoNClsgICAz
NC4yOTg1OTddIFBpZDogMTU4MCwgY29tbTogc3NoZCBOb3QgdGFpbnRlZCAzLjYuMHByZS1y
YzEtMjAxMjEwMTEgIzENClsgICAzNC4yOTg2MDNdIENhbGwgVHJhY2U6DQpbICAgMzQuMjk4
NjExXSAgWzxmZmZmZmZmZjgxMDY2NGVhPl0gd2Fybl9zbG93cGF0aF9jb21tb24rMHg3YS8w
eGIwDQpbICAgMzQuMjk4NjE3XSAgWzxmZmZmZmZmZjgxMDY2NTM1Pl0gd2Fybl9zbG93cGF0
aF9udWxsKzB4MTUvMHgyMA0KWyAgIDM0LjI5ODYyM10gIFs8ZmZmZmZmZmY4MTQ2ZDg5ZT5d
IHhlbm5ldF9zdGFydF94bWl0KzB4N2ZlLzB4ODYwDQpbICAgMzQuMjk4NjMxXSAgWzxmZmZm
ZmZmZjgxNjFmMzQ5Pl0gZGV2X2hhcmRfc3RhcnRfeG1pdCsweDIwOS8weDQ2MA0KWyAgIDM0
LjI5ODYzN10gIFs8ZmZmZmZmZmY4MTYzYjAzNj5dIHNjaF9kaXJlY3RfeG1pdCsweGY2LzB4
MjkwDQpbICAgMzQuMjk4NjQzXSAgWzxmZmZmZmZmZjgxNjFmNzQ2Pl0gZGV2X3F1ZXVlX3ht
aXQrMHgxYTYvMHg1YTANClsgICAzNC4yOTg2NDldICBbPGZmZmZmZmZmODE2MWY1YTA+XSA/
IGRldl9oYXJkX3N0YXJ0X3htaXQrMHg0NjAvMHg0NjANClsgICAzNC4yOTg2NTZdICBbPGZm
ZmZmZmZmODEwYWE4ZTU+XSA/IHRyYWNlX3NvZnRpcnFzX29mZisweDg1LzB4MWIwDQpbICAg
MzQuMjk4NjYzXSAgWzxmZmZmZmZmZjgxNmI5NTM2Pl0gaXBfZmluaXNoX291dHB1dCsweDIy
Ni8weDUzMA0KWyAgIDM0LjI5ODY2OF0gIFs8ZmZmZmZmZmY4MTZiOTNkZD5dID8gaXBfZmlu
aXNoX291dHB1dCsweGNkLzB4NTMwDQpbICAgMzQuMjk4Njc0XSAgWzxmZmZmZmZmZjgxNmI5
ODk5Pl0gaXBfb3V0cHV0KzB4NTkvMHhlMA0KWyAgIDM0LjI5ODY4MF0gIFs8ZmZmZmZmZmY4
MTZiODNiOD5dIGlwX2xvY2FsX291dCsweDI4LzB4OTANClsgICAzNC4yOTg2ODddICBbPGZm
ZmZmZmZmODE2Yjg5NmY+XSBpcF9xdWV1ZV94bWl0KzB4MTdmLzB4NGEwDQpbICAgMzQuMjk4
NjkyXSAgWzxmZmZmZmZmZjgxNmI4N2YwPl0gPyBpcF9zZW5kX3VuaWNhc3RfcmVwbHkrMHgz
NDAvMHgzNDANClsgICAzNC4yOTg2OTldICBbPGZmZmZmZmZmODEwYTBiYTc+XSA/IGdldG5z
dGltZW9mZGF5KzB4NDcvMHhlMA0KWyAgIDM0LjI5ODcwNV0gIFs8ZmZmZmZmZmY4MTYwZjRj
OT5dID8gX19za2JfY2xvbmUrMHgyOS8weDEyMA0KWyAgIDM0LjI5ODcxMV0gIFs8ZmZmZmZm
ZmY4MTZjZWEyMD5dIHRjcF90cmFuc21pdF9za2IrMHg0MDAvMHg4ZDANClsgICAzNC4yOTg3
MTddICBbPGZmZmZmZmZmODE2ZDE5ZmE+XSB0Y3Bfd3JpdGVfeG1pdCsweDIxYS8weGE1MA0K
WyAgIDM0LjI5ODcyM10gIFs8ZmZmZmZmZmY4MTZkMjI1Yj5dIHRjcF9wdXNoX29uZSsweDJi
LzB4NDANClsgICAzNC4yOTg3MjhdICBbPGZmZmZmZmZmODE2YzJkZWM+XSB0Y3Bfc2VuZG1z
ZysweDhkYy8weGUyMA0KWyAgIDM0LjI5ODczNV0gIFs8ZmZmZmZmZmY4MTZlOGYxOT5dIGlu
ZXRfc2VuZG1zZysweGE5LzB4MTAwDQpbICAgMzQuMjk4NzQwXSAgWzxmZmZmZmZmZjgxNmU4
ZTcwPl0gPyBpbmV0X2F1dG9iaW5kKzB4NzAvMHg3MA0KWyAgIDM0LjI5ODc0Nl0gIFs8ZmZm
ZmZmZmY4MTBiMGY4OD5dID8gbG9ja19hY3F1aXJlKzB4ZDgvMHgxMDANClsgICAzNC4yOTg3
NTNdICBbPGZmZmZmZmZmODE2MDYzMGQ+XSBzb2NrX2Fpb193cml0ZSsweDEyZC8weDE0MA0K
WyAgIDM0LjI5ODc2Ml0gIFs8ZmZmZmZmZmY4MTE0MzViMj5dIGRvX3N5bmNfd3JpdGUrMHhh
Mi8weGUwDQpbICAgMzQuMjk4NzY4XSAgWzxmZmZmZmZmZjgxMGFkMjJkPl0gPyB0cmFjZV9o
YXJkaXJxc19vbisweGQvMHgxMA0KWyAgIDM0LjI5ODc3NF0gIFs8ZmZmZmZmZmY4MTE0NDFk
ND5dIHZmc193cml0ZSsweDE3NC8weDE5MA0KWyAgIDM0LjI5ODc3OV0gIFs8ZmZmZmZmZmY4
MTE0NDJmYT5dIHN5c193cml0ZSsweDVhLzB4YTANClsgICAzNC4yOTg3ODZdICBbPGZmZmZm
ZmZmODEyYjMzZGU+XSA/IHRyYWNlX2hhcmRpcnFzX29uX3RodW5rKzB4M2EvMHgzZg0KWyAg
IDM0LjI5ODc5Ml0gIFs8ZmZmZmZmZmY4MTc0OTFjYz5dIGNzdGFyX2Rpc3BhdGNoKzB4Ny8w
eDI2DQpbICAgMzQuMjk4Nzk3XSAtLS1bIGVuZCB0cmFjZSAyZTI4ZWVjOTNiN2E4Yjc0IF0t
LS0NClsgICAzNC4yOTg4MjVdIC0tLS0tLS0tLS0tLVsgY3V0IGhlcmUgXS0tLS0tLS0tLS0t
LQ0KWyAgIDM0LjI5ODgzMl0gV0FSTklORzogYXQgZHJpdmVycy9uZXQveGVuLW5ldGZyb250
LmM6NDY1IHhlbm5ldF9zdGFydF94bWl0KzB4N2ZlLzB4ODYwKCkNClsgICAzNC4yOTg4Mzhd
IE1vZHVsZXMgbGlua2VkIGluOg0KWyAgIDM0LjI5ODg0M10gUGlkOiAxNTgwLCBjb21tOiBz
c2hkIFRhaW50ZWQ6IEcgICAgICAgIFcgICAgMy42LjBwcmUtcmMxLTIwMTIxMDExICMxDQpb
ICAgMzQuMjk4ODQ4XSBDYWxsIFRyYWNlOg0KWyAgIDM0LjI5ODg1Ml0gIFs8ZmZmZmZmZmY4
MTA2NjRlYT5dIHdhcm5fc2xvd3BhdGhfY29tbW9uKzB4N2EvMHhiMA0KWyAgIDM0LjI5ODg1
OF0gIFs8ZmZmZmZmZmY4MTA2NjUzNT5dIHdhcm5fc2xvd3BhdGhfbnVsbCsweDE1LzB4MjAN
ClsgICAzNC4yOTg4NjRdICBbPGZmZmZmZmZmODE0NmQ4OWU+XSB4ZW5uZXRfc3RhcnRfeG1p
dCsweDdmZS8weDg2MA0KWyAgIDM0LjI5ODg3MF0gIFs8ZmZmZmZmZmY4MTYxZjM0OT5dIGRl
dl9oYXJkX3N0YXJ0X3htaXQrMHgyMDkvMHg0NjANClsgICAzNC4yOTg4NzZdICBbPGZmZmZm
ZmZmODE2M2IwMzY+XSBzY2hfZGlyZWN0X3htaXQrMHhmNi8weDI5MA0KWyAgIDM0LjI5ODg4
MV0gIFs8ZmZmZmZmZmY4MTYxZjc0Nj5dIGRldl9xdWV1ZV94bWl0KzB4MWE2LzB4NWEwDQpb
ICAgMzQuMjk4ODg3XSAgWzxmZmZmZmZmZjgxNjFmNWEwPl0gPyBkZXZfaGFyZF9zdGFydF94
bWl0KzB4NDYwLzB4NDYwDQpbICAgMzQuMjk4ODkzXSAgWzxmZmZmZmZmZjgxMGFhOGU1Pl0g
PyB0cmFjZV9zb2Z0aXJxc19vZmYrMHg4NS8weDFiMA0KWyAgIDM0LjI5ODg5OV0gIFs8ZmZm
ZmZmZmY4MTZiOTUzNj5dIGlwX2ZpbmlzaF9vdXRwdXQrMHgyMjYvMHg1MzANClsgICAzNC4y
OTg5MDRdICBbPGZmZmZmZmZmODE2YjkzZGQ+XSA/IGlwX2ZpbmlzaF9vdXRwdXQrMHhjZC8w
eDUzMA0KWyAgIDM0LjI5ODkxMF0gIFs8ZmZmZmZmZmY4MTZiOTg5OT5dIGlwX291dHB1dCsw
eDU5LzB4ZTANClsgICAzNC4yOTg5MTZdICBbPGZmZmZmZmZmODE2YjgzYjg+XSBpcF9sb2Nh
bF9vdXQrMHgyOC8weDkwDQpbICAgMzQuMjk4OTIxXSAgWzxmZmZmZmZmZjgxNmI4OTZmPl0g
aXBfcXVldWVfeG1pdCsweDE3Zi8weDRhMA0KWyAgIDM0LjI5ODkyN10gIFs8ZmZmZmZmZmY4
MTZiODdmMD5dID8gaXBfc2VuZF91bmljYXN0X3JlcGx5KzB4MzQwLzB4MzQwDQpbICAgMzQu
Mjk4OTMyXSAgWzxmZmZmZmZmZjgxMGEwYmE3Pl0gPyBnZXRuc3RpbWVvZmRheSsweDQ3LzB4
ZTANClsgICAzNC4yOTg5MzhdICBbPGZmZmZmZmZmODE2MGY0Yzk+XSA/IF9fc2tiX2Nsb25l
KzB4MjkvMHgxMjANClsgICAzNC4yOTg5NDNdICBbPGZmZmZmZmZmODE2Y2VhMjA+XSB0Y3Bf
dHJhbnNtaXRfc2tiKzB4NDAwLzB4OGQwDQpbICAgMzQuMjk4OTQ5XSAgWzxmZmZmZmZmZjgx
NmQxOWZhPl0gdGNwX3dyaXRlX3htaXQrMHgyMWEvMHhhNTANClsgICAzNC4yOTg5NTVdICBb
PGZmZmZmZmZmODE2ZDIyOWQ+XSBfX3RjcF9wdXNoX3BlbmRpbmdfZnJhbWVzKzB4MmQvMHg5
MA0KWyAgIDM0LjI5ODk2MV0gIFs8ZmZmZmZmZmY4MTZjMjY5Mz5dIHRjcF9zZW5kbXNnKzB4
MTgzLzB4ZTIwDQpbICAgMzQuMjk4OTY2XSAgWzxmZmZmZmZmZjgxNmU4ZjE5Pl0gaW5ldF9z
ZW5kbXNnKzB4YTkvMHgxMDANClsgICAzNC4yOTg5NzJdICBbPGZmZmZmZmZmODE2ZThlNzA+
XSA/IGluZXRfYXV0b2JpbmQrMHg3MC8weDcwDQpbICAgMzQuMjk4OTc3XSAgWzxmZmZmZmZm
ZjgxMGIwZjg4Pl0gPyBsb2NrX2FjcXVpcmUrMHhkOC8weDEwMA0KWyAgIDM0LjI5ODk4M10g
IFs8ZmZmZmZmZmY4MTYwNjMwZD5dIHNvY2tfYWlvX3dyaXRlKzB4MTJkLzB4MTQwDQpbICAg
MzQuMjk4OTg4XSAgWzxmZmZmZmZmZjgxMTQzNWIyPl0gZG9fc3luY193cml0ZSsweGEyLzB4
ZTANClsgICAzNC4yOTg5OTRdICBbPGZmZmZmZmZmODEwYWQyMmQ+XSA/IHRyYWNlX2hhcmRp
cnFzX29uKzB4ZC8weDEwDQpbICAgMzQuMjk5MDAwXSAgWzxmZmZmZmZmZjgxMTQ0MWQ0Pl0g
dmZzX3dyaXRlKzB4MTc0LzB4MTkwDQpbICAgMzQuMjk5MDA1XSAgWzxmZmZmZmZmZjgxMTQ0
MmZhPl0gc3lzX3dyaXRlKzB4NWEvMHhhMA0KWyAgIDM0LjI5OTAxMV0gIFs8ZmZmZmZmZmY4
MTJiMzNkZT5dID8gdHJhY2VfaGFyZGlycXNfb25fdGh1bmsrMHgzYS8weDNmDQpbICAgMzQu
Mjk5MDE3XSAgWzxmZmZmZmZmZjgxNzQ5MWNjPl0gY3N0YXJfZGlzcGF0Y2grMHg3LzB4MjYN
ClsgICAzNC4yOTkwMjJdIC0tLVsgZW5kIHRyYWNlIDJlMjhlZWM5M2I3YThiNzUgXS0tLQ0K
WyAgIDM0LjI5OTAzNl0gLS0tLS0tLS0tLS0tWyBjdXQgaGVyZSBdLS0tLS0tLS0tLS0tDQpb
ICAgMzQuMjk5MDQyXSBXQVJOSU5HOiBhdCBkcml2ZXJzL25ldC94ZW4tbmV0ZnJvbnQuYzo0
NjUgeGVubmV0X3N0YXJ0X3htaXQrMHg3ZmUvMHg4NjAoKQ0KWyAgIDM0LjI5OTA0N10gTW9k
dWxlcyBsaW5rZWQgaW46DQpbICAgMzQuMjk5MDUyXSBQaWQ6IDE1ODAsIGNvbW06IHNzaGQg
VGFpbnRlZDogRyAgICAgICAgVyAgICAzLjYuMHByZS1yYzEtMjAxMjEwMTEgIzENClsgICAz
NC4yOTkwNTddIENhbGwgVHJhY2U6DQpbICAgMzQuMjk5MDYxXSAgWzxmZmZmZmZmZjgxMDY2
NGVhPl0gd2Fybl9zbG93cGF0aF9jb21tb24rMHg3YS8weGIwDQpbICAgMzQuMjk5MDcxXSAg
WzxmZmZmZmZmZjgxMDY2NTM1Pl0gd2Fybl9zbG93cGF0aF9udWxsKzB4MTUvMHgyMA0KWyAg
IDM0LjI5OTA3N10gIFs8ZmZmZmZmZmY4MTQ2ZDg5ZT5dIHhlbm5ldF9zdGFydF94bWl0KzB4
N2ZlLzB4ODYwDQpbICAgMzQuMjk5MDg0XSAgWzxmZmZmZmZmZjgxNjFmMzQ5Pl0gZGV2X2hh
cmRfc3RhcnRfeG1pdCsweDIwOS8weDQ2MA0KWyAgIDM0LjI5OTA4OV0gIFs8ZmZmZmZmZmY4
MTYzYjAzNj5dIHNjaF9kaXJlY3RfeG1pdCsweGY2LzB4MjkwDQpbICAgMzQuMjk5MDk1XSAg
WzxmZmZmZmZmZjgxNjFmNzQ2Pl0gZGV2X3F1ZXVlX3htaXQrMHgxYTYvMHg1YTANClsgICAz
NC4yOTkxMDFdICBbPGZmZmZmZmZmODE2MWY1YTA+XSA/IGRldl9oYXJkX3N0YXJ0X3htaXQr
MHg0NjAvMHg0NjANClsgICAzNC4yOTkxMDZdICBbPGZmZmZmZmZmODEwYWE4ZTU+XSA/IHRy
YWNlX3NvZnRpcnFzX29mZisweDg1LzB4MWIwDQpbICAgMzQuMjk5MTEyXSAgWzxmZmZmZmZm
ZjgxNmI5NTM2Pl0gaXBfZmluaXNoX291dHB1dCsweDIyNi8weDUzMA0KWyAgIDM0LjI5OTEx
OF0gIFs8ZmZmZmZmZmY4MTZiOTNkZD5dID8gaXBfZmluaXNoX291dHB1dCsweGNkLzB4NTMw
DQpbICAgMzQuMjk5MTI0XSAgWzxmZmZmZmZmZjgxNmI5ODk5Pl0gaXBfb3V0cHV0KzB4NTkv
MHhlMA0KWyAgIDM0LjI5OTEyOV0gIFs8ZmZmZmZmZmY4MTZiODNiOD5dIGlwX2xvY2FsX291
dCsweDI4LzB4OTANClsgICAzNC4yOTkxMzVdICBbPGZmZmZmZmZmODE2Yjg5NmY+XSBpcF9x
dWV1ZV94bWl0KzB4MTdmLzB4NGEwDQpbICAgMzQuMjk5MTQwXSAgWzxmZmZmZmZmZjgxNmI4
N2YwPl0gPyBpcF9zZW5kX3VuaWNhc3RfcmVwbHkrMHgzNDAvMHgzNDANClsgICAzNC4yOTkx
NDZdICBbPGZmZmZmZmZmODEwYTBiYTc+XSA/IGdldG5zdGltZW9mZGF5KzB4NDcvMHhlMA0K
WyAgIDM0LjI5OTE1Ml0gIFs8ZmZmZmZmZmY4MTYwZjRjOT5dID8gX19za2JfY2xvbmUrMHgy
OS8weDEyMA0KWyAgIDM0LjI5OTE1N10gIFs8ZmZmZmZmZmY4MTZjZWEyMD5dIHRjcF90cmFu
c21pdF9za2IrMHg0MDAvMHg4ZDANClsgICAzNC4yOTkxNjNdICBbPGZmZmZmZmZmODE2ZDE5
ZmE+XSB0Y3Bfd3JpdGVfeG1pdCsweDIxYS8weGE1MA0KWyAgIDM0LjI5OTE2OV0gIFs8ZmZm
ZmZmZmY4MTZkMjI5ZD5dIF9fdGNwX3B1c2hfcGVuZGluZ19mcmFtZXMrMHgyZC8weDkwDQpb
ICAgMzQuMjk5MTc0XSAgWzxmZmZmZmZmZjgxNmMyNjkzPl0gdGNwX3NlbmRtc2crMHgxODMv
MHhlMjANClsgICAzNC4yOTkxODBdICBbPGZmZmZmZmZmODE2ZThmMTk+XSBpbmV0X3NlbmRt
c2crMHhhOS8weDEwMA0KWyAgIDM0LjI5OTE4NV0gIFs8ZmZmZmZmZmY4MTZlOGU3MD5dID8g
aW5ldF9hdXRvYmluZCsweDcwLzB4NzANClsgICAzNC4yOTkxOTFdICBbPGZmZmZmZmZmODEw
YjBmODg+XSA/IGxvY2tfYWNxdWlyZSsweGQ4LzB4MTAwDQpbICAgMzQuMjk5MTk2XSAgWzxm
ZmZmZmZmZjgxNjA2MzBkPl0gc29ja19haW9fd3JpdGUrMHgxMmQvMHgxNDANClsgICAzNC4y
OTkyMDJdICBbPGZmZmZmZmZmODExNDM1YjI+XSBkb19zeW5jX3dyaXRlKzB4YTIvMHhlMA0K
WyAgIDM0LjI5OTIwOF0gIFs8ZmZmZmZmZmY4MTBhZDIyZD5dID8gdHJhY2VfaGFyZGlycXNf
b24rMHhkLzB4MTANClsgICAzNC4yOTkyMTNdICBbPGZmZmZmZmZmODExNDQxZDQ+XSB2ZnNf
d3JpdGUrMHgxNzQvMHgxOTANClsgICAzNC4yOTkyMTldICBbPGZmZmZmZmZmODExNDQyZmE+
XSBzeXNfd3JpdGUrMHg1YS8weGEwDQpbICAgMzQuMjk5MjI0XSAgWzxmZmZmZmZmZjgxMmIz
M2RlPl0gPyB0cmFjZV9oYXJkaXJxc19vbl90aHVuaysweDNhLzB4M2YNClsgICAzNC4yOTky
MzldICBbPGZmZmZmZmZmODE3NDkxY2M+XSBjc3Rhcl9kaXNwYXRjaCsweDcvMHgyNg0KWyAg
IDM0LjI5OTI0M10gLS0tWyBlbmQgdHJhY2UgMmUyOGVlYzkzYjdhOGI3NiBdLS0tDQpbICAg
MzQuNzk0NTkyXSAtLS0tLS0tLS0tLS1bIGN1dCBoZXJlIF0tLS0tLS0tLS0tLS0NClsgICAz
NC43OTQ2MTVdIFdBUk5JTkc6IGF0IGRyaXZlcnMvbmV0L3hlbi1uZXRmcm9udC5jOjQ2NSB4
ZW5uZXRfc3RhcnRfeG1pdCsweDdmZS8weDg2MCgpDQpbICAgMzQuNzk0NjIzXSBNb2R1bGVz
IGxpbmtlZCBpbjoNClsgICAzNC43OTQ2MzJdIFBpZDogMCwgY29tbTogc3dhcHBlci8wIFRh
aW50ZWQ6IEcgICAgICAgIFcgICAgMy42LjBwcmUtcmMxLTIwMTIxMDExICMxDQpbICAgMzQu
Nzk0NjQwXSBDYWxsIFRyYWNlOg0KWyAgIDM0Ljc5NDY0NF0gIDxJUlE+ICBbPGZmZmZmZmZm
ODEwNjY0ZWE+XSB3YXJuX3Nsb3dwYXRoX2NvbW1vbisweDdhLzB4YjANClsgICAzNC43OTQ2
NjBdICBbPGZmZmZmZmZmODEwNjY1MzU+XSB3YXJuX3Nsb3dwYXRoX251bGwrMHgxNS8weDIw
DQpbICAgMzQuNzk0NjY3XSAgWzxmZmZmZmZmZjgxNDZkODllPl0geGVubmV0X3N0YXJ0X3ht
aXQrMHg3ZmUvMHg4NjANClsgICAzNC43OTQ2NzddICBbPGZmZmZmZmZmODE2MWYzNDk+XSBk
ZXZfaGFyZF9zdGFydF94bWl0KzB4MjA5LzB4NDYwDQpbICAgMzQuNzk0Njg1XSAgWzxmZmZm
ZmZmZjgxNjNiMDM2Pl0gc2NoX2RpcmVjdF94bWl0KzB4ZjYvMHgyOTANClsgICAzNC43OTQ2
OTNdICBbPGZmZmZmZmZmODE2MWY3NDY+XSBkZXZfcXVldWVfeG1pdCsweDFhNi8weDVhMA0K
WyAgIDM0Ljc5NDcwMV0gIFs8ZmZmZmZmZmY4MTYxZjVhMD5dID8gZGV2X2hhcmRfc3RhcnRf
eG1pdCsweDQ2MC8weDQ2MA0KWyAgIDM0Ljc5NDcxMF0gIFs8ZmZmZmZmZmY4MTBiMTQxNz5d
ID8gbG9ja19yZWxlYXNlKzB4MTE3LzB4MjUwDQpbICAgMzQuNzk0NzE5XSAgWzxmZmZmZmZm
ZjgxNmI5NTM2Pl0gaXBfZmluaXNoX291dHB1dCsweDIyNi8weDUzMA0KWyAgIDM0Ljc5NDcz
MF0gIFs8ZmZmZmZmZmY4MTZiOTNkZD5dID8gaXBfZmluaXNoX291dHB1dCsweGNkLzB4NTMw
DQpbICAgMzQuNzk0NzQyXSAgWzxmZmZmZmZmZjgxNmI5ODk5Pl0gaXBfb3V0cHV0KzB4NTkv
MHhlMA0KWyAgIDM0Ljc5NDc1MF0gIFs8ZmZmZmZmZmY4MTZiODNiOD5dIGlwX2xvY2FsX291
dCsweDI4LzB4OTANClsgICAzNC43OTQ3NTddICBbPGZmZmZmZmZmODE2Yjg5NmY+XSBpcF9x
dWV1ZV94bWl0KzB4MTdmLzB4NGEwDQpbICAgMzQuNzk0NzY1XSAgWzxmZmZmZmZmZjgxNmI4
N2YwPl0gPyBpcF9zZW5kX3VuaWNhc3RfcmVwbHkrMHgzNDAvMHgzNDANClsgICAzNC43OTQ3
NzNdICBbPGZmZmZmZmZmODEwYTBiYTc+XSA/IGdldG5zdGltZW9mZGF5KzB4NDcvMHhlMA0K
WyAgIDM0Ljc5NDc4MV0gIFs8ZmZmZmZmZmY4MTYwZjRjOT5dID8gX19za2JfY2xvbmUrMHgy
OS8weDEyMA0KWyAgIDM0Ljc5NDc4OF0gIFs8ZmZmZmZmZmY4MTZjZWEyMD5dIHRjcF90cmFu
c21pdF9za2IrMHg0MDAvMHg4ZDANClsgICAzNC43OTQ3OTZdICBbPGZmZmZmZmZmODE2ZDEx
MDY+XSB0Y3BfcmV0cmFuc21pdF9za2IrMHgxYzYvMHg1YTANClsgICAzNC43OTQ4MDRdICBb
PGZmZmZmZmZmODE2ZDE2N2U+XSB0Y3BfeG1pdF9yZXRyYW5zbWl0X3F1ZXVlKzB4MTllLzB4
MzAwDQpbICAgMzQuNzk0ODEyXSAgWzxmZmZmZmZmZjgxNmM5OWZmPl0gdGNwX2Zhc3RyZXRy
YW5zX2FsZXJ0KzB4OTRmLzB4Y2IwDQpbICAgMzQuNzk0ODE5XSAgWzxmZmZmZmZmZjgxNmNh
NzBjPl0gdGNwX2FjaysweDlhYy8weDExNTANClsgICAzNC43OTQ4MjddICBbPGZmZmZmZmZm
ODE2Y2Q4NTg+XSB0Y3BfcmN2X2VzdGFibGlzaGVkKzB4MzE4LzB4NjQwDQpbICAgMzQuNzk0
ODM4XSAgWzxmZmZmZmZmZjgxNmQ1ZWVmPl0gPyB0Y3BfdjRfcmN2KzB4NmNmLzB4YjEwDQpb
ICAgMzQuNzk0ODQ1XSAgWzxmZmZmZmZmZjgxNmQ1NGQ1Pl0gdGNwX3Y0X2RvX3JjdisweDEz
NS8weDQ4MA0KWyAgIDM0Ljc5NDg1NF0gIFs8ZmZmZmZmZmY4MTc0NjFkMj5dID8gX3Jhd19z
cGluX2xvY2tfbmVzdGVkKzB4NDIvMHg1MA0KWyAgIDM0Ljc5NDg2Ml0gIFs8ZmZmZmZmZmY4
MTZkNWVlZj5dID8gdGNwX3Y0X3JjdisweDZjZi8weGIxMA0KWyAgIDM0Ljc5NDg2OV0gIFs8
ZmZmZmZmZmY4MTZkNjE3ZD5dIHRjcF92NF9yY3YrMHg5NWQvMHhiMTANClsgICAzNC43OTQ4
NzZdICBbPGZmZmZmZmZmODEwYjBmODg+XSA/IGxvY2tfYWNxdWlyZSsweGQ4LzB4MTAwDQpb
ICAgMzQuNzk0ODg0XSAgWzxmZmZmZmZmZjgxNmIyOTk1Pl0gPyBpcF9sb2NhbF9kZWxpdmVy
X2ZpbmlzaCsweDQ1LzB4MjMwDQpbICAgMzQuNzk0ODkyXSAgWzxmZmZmZmZmZjgxNmIyYTZh
Pl0gaXBfbG9jYWxfZGVsaXZlcl9maW5pc2grMHgxMWEvMHgyMzANClsgICAzNC43OTQ5MDBd
ICBbPGZmZmZmZmZmODE2YjI5OTU+XSA/IGlwX2xvY2FsX2RlbGl2ZXJfZmluaXNoKzB4NDUv
MHgyMzANClsgICAzNC43OTQ5MDhdICBbPGZmZmZmZmZmODE2YjJiYjg+XSBpcF9sb2NhbF9k
ZWxpdmVyKzB4MzgvMHg4MA0KWyAgIDM0Ljc5NDkxNV0gIFs8ZmZmZmZmZmY4MTZiMjE3YT5d
IGlwX3Jjdl9maW5pc2grMHgxNWEvMHg2MzANClsgICAzNC43OTQ5MjJdICBbPGZmZmZmZmZm
ODE2YjI4Njg+XSBpcF9yY3YrMHgyMTgvMHgzMDANClsgICAzNC43OTQ5MzBdICBbPGZmZmZm
ZmZmODE2MWFjOGQ+XSBfX25ldGlmX3JlY2VpdmVfc2tiKzB4NjVkLzB4OGQwDQpbICAgMzQu
Nzk0OTM3XSAgWzxmZmZmZmZmZjgxNjFhNzc1Pl0gPyBfX25ldGlmX3JlY2VpdmVfc2tiKzB4
MTQ1LzB4OGQwDQpbICAgMzQuNzk0OTQ1XSAgWzxmZmZmZmZmZjgxMGFkMjJkPl0gPyB0cmFj
ZV9oYXJkaXJxc19vbisweGQvMHgxMA0KWyAgIDM0Ljc5NDk1M10gIFs8ZmZmZmZmZmY4MTBm
OTk3Mz5dID8gZnJlZV9ob3RfY29sZF9wYWdlKzB4MWIzLzB4MWUwDQpbICAgMzQuNzk0OTYx
XSAgWzxmZmZmZmZmZjgxNjFkMWY4Pl0gbmV0aWZfcmVjZWl2ZV9za2IrMHgyOC8weGYwDQpb
ICAgMzQuNzk0OTY4XSAgWzxmZmZmZmZmZjgxNjEyZDAzPl0gPyBfX3Bza2JfcHVsbF90YWls
KzB4MjUzLzB4MzQwDQpbICAgMzQuNzk0OTc2XSAgWzxmZmZmZmZmZjgxNDZlNGM1Pl0geGVu
bmV0X3BvbGwrMHhhZDUvMHhlMTANClsgICAzNC43OTQ5OTBdICBbPGZmZmZmZmZmODE2MWRm
YTY+XSBuZXRfcnhfYWN0aW9uKzB4MTM2LzB4MjYwDQpbICAgMzQuNzk0OTk4XSAgWzxmZmZm
ZmZmZjgxMDZlMzgxPl0gPyBfX2RvX3NvZnRpcnErMHg3MS8weDFhMA0KWyAgIDM0Ljc5NTAw
Nl0gIFs8ZmZmZmZmZmY4MTA2ZTNkOT5dIF9fZG9fc29mdGlycSsweGM5LzB4MWEwDQpbICAg
MzQuNzk1MDE0XSAgWzxmZmZmZmZmZjgxNzQ4ZDNjPl0gY2FsbF9zb2Z0aXJxKzB4MWMvMHgz
MA0KWyAgIDM0Ljc5NTAyMV0gIFs8ZmZmZmZmZmY4MTAwZWRiNT5dIGRvX3NvZnRpcnErMHg4
NS8weGYwDQpbICAgMzQuNzk1MDI4XSAgWzxmZmZmZmZmZjgxMDZlMjRlPl0gaXJxX2V4aXQr
MHg5ZS8weGQwDQpbICAgMzQuNzk1MDM3XSAgWzxmZmZmZmZmZjgxMzM5ZjVmPl0geGVuX2V2
dGNobl9kb191cGNhbGwrMHgyZi8weDQwDQpbICAgMzQuNzk1MDQ0XSAgWzxmZmZmZmZmZjgx
NzQ4ZDllPl0geGVuX2RvX2h5cGVydmlzb3JfY2FsbGJhY2srMHgxZS8weDMwDQpbICAgMzQu
Nzk1MDUwXSAgPEVPST4gIFs8ZmZmZmZmZmY4MTAwMTNhYT5dID8geGVuX2h5cGVyY2FsbF9z
Y2hlZF9vcCsweGEvMHgyMA0KWyAgIDM0Ljc5NTA2M10gIFs8ZmZmZmZmZmY4MTAwMTNhYT5d
ID8geGVuX2h5cGVyY2FsbF9zY2hlZF9vcCsweGEvMHgyMA0KWyAgIDM0Ljc5NTA3Ml0gIFs8
ZmZmZmZmZmY4MTAwODY5MD5dID8geGVuX3NhZmVfaGFsdCsweDEwLzB4MjANClsgICAzNC43
OTUwODBdICBbPGZmZmZmZmZmODEwMTYwZDA+XSA/IGRlZmF1bHRfaWRsZSsweDQwLzB4OTAN
ClsgICAzNC43OTUwODddICBbPGZmZmZmZmZmODEwMTY0ODY+XSA/IGNwdV9pZGxlKzB4OTYv
MHhmMA0KWyAgIDM0Ljc5NTA5NF0gIFs8ZmZmZmZmZmY4MTcyMmQzYz5dID8gcmVzdF9pbml0
KzB4YmMvMHhkMA0KWyAgIDM0Ljc5NTEwMV0gIFs8ZmZmZmZmZmY4MTcyMmM4MD5dID8gY3N1
bV9wYXJ0aWFsX2NvcHlfZ2VuZXJpYysweDE3MC8weDE3MA0KWyAgIDM0Ljc5NTExMV0gIFs8
ZmZmZmZmZmY4MWNlMGRmMj5dID8gc3RhcnRfa2VybmVsKzB4MzkwLzB4MzlkDQpbICAgMzQu
Nzk1MTE5XSAgWzxmZmZmZmZmZjgxY2UwODgyPl0gPyBrZXJuZWxfaW5pdCsweDIwYi8weDIw
Yg0KWyAgIDM0Ljc5NTEyNl0gIFs8ZmZmZmZmZmY4MWNlMDM1Nj5dID8geDg2XzY0X3N0YXJ0
X3Jlc2VydmF0aW9ucysweDEzMS8weDEzNg0KWyAgIDM0Ljc5NTEzNV0gIFs8ZmZmZmZmZmY4
MWNlM2Q2MD5dID8geGVuX3N0YXJ0X2tlcm5lbCsweDcwZC8weDcwZg0KWyAgIDM0Ljc5NTE0
Ml0gLS0tWyBlbmQgdHJhY2UgMmUyOGVlYzkzYjdhOGI3NyBdLS0tDQpbICAgMzQuNzk1MTcw
XSAtLS0tLS0tLS0tLS1bIGN1dCBoZXJlIF0tLS0tLS0tLS0tLS0NClsgICAzNC43OTUxNzhd
IFdBUk5JTkc6IGF0IGRyaXZlcnMvbmV0L3hlbi1uZXRmcm9udC5jOjQ2NSB4ZW5uZXRfc3Rh
cnRfeG1pdCsweDdmZS8weDg2MCgpDQpbICAgMzQuNzk1MTg2XSBNb2R1bGVzIGxpbmtlZCBp
bjoNClsgICAzNC43OTUxOTJdIFBpZDogMCwgY29tbTogc3dhcHBlci8wIFRhaW50ZWQ6IEcg
ICAgICAgIFcgICAgMy42LjBwcmUtcmMxLTIwMTIxMDExICMxDQpbICAgMzQuNzk1MTk5XSBD
YWxsIFRyYWNlOg0KWyAgIDM0Ljc5NTIwM10gIDxJUlE+ICBbPGZmZmZmZmZmODEwNjY0ZWE+
XSB3YXJuX3Nsb3dwYXRoX2NvbW1vbisweDdhLzB4YjANClsgICAzNC43OTUyMTVdICBbPGZm
ZmZmZmZmODEwNjY1MzU+XSB3YXJuX3Nsb3dwYXRoX251bGwrMHgxNS8weDIwDQpbICAgMzQu
Nzk1MjIzXSAgWzxmZmZmZmZmZjgxNDZkODllPl0geGVubmV0X3N0YXJ0X3htaXQrMHg3ZmUv
MHg4NjANClsgICAzNC43OTUyMzFdICBbPGZmZmZmZmZmODE2MWYzNDk+XSBkZXZfaGFyZF9z
dGFydF94bWl0KzB4MjA5LzB4NDYwDQpbICAgMzQuNzk1MjM5XSAgWzxmZmZmZmZmZjgxNjNi
MDM2Pl0gc2NoX2RpcmVjdF94bWl0KzB4ZjYvMHgyOTANClsgICAzNC43OTUyNDddICBbPGZm
ZmZmZmZmODE2MWY3NDY+XSBkZXZfcXVldWVfeG1pdCsweDFhNi8weDVhMA0KWyAgIDM0Ljc5
NTI1NF0gIFs8ZmZmZmZmZmY4MTYxZjVhMD5dID8gZGV2X2hhcmRfc3RhcnRfeG1pdCsweDQ2
MC8weDQ2MA0KWyAgIDM0Ljc5NTI2Ml0gIFs8ZmZmZmZmZmY4MTBiMTQxNz5dID8gbG9ja19y
ZWxlYXNlKzB4MTE3LzB4MjUwDQpbICAgMzQuNzk1MjcwXSAgWzxmZmZmZmZmZjgxNmI5NTM2
Pl0gaXBfZmluaXNoX291dHB1dCsweDIyNi8weDUzMA0KWyAgIDM0Ljc5NTI3OF0gIFs8ZmZm
ZmZmZmY4MTZiOTNkZD5dID8gaXBfZmluaXNoX291dHB1dCsweGNkLzB4NTMwDQpbICAgMzQu
Nzk1Mjg1XSAgWzxmZmZmZmZmZjgxNmI5ODk5Pl0gaXBfb3V0cHV0KzB4NTkvMHhlMA0KWyAg
IDM0Ljc5NTI5M10gIFs8ZmZmZmZmZmY4MTZiODNiOD5dIGlwX2xvY2FsX291dCsweDI4LzB4
OTANClsgICAzNC43OTUzMDBdICBbPGZmZmZmZmZmODE2Yjg5NmY+XSBpcF9xdWV1ZV94bWl0
KzB4MTdmLzB4NGEwDQpbICAgMzQuNzk1MzA3XSAgWzxmZmZmZmZmZjgxNmI4N2YwPl0gPyBp
cF9zZW5kX3VuaWNhc3RfcmVwbHkrMHgzNDAvMHgzNDANClsgICAzNC43OTUzMTVdICBbPGZm
ZmZmZmZmODEwYTBiYTc+XSA/IGdldG5zdGltZW9mZGF5KzB4NDcvMHhlMA0KWyAgIDM0Ljc5
NTMyMl0gIFs8ZmZmZmZmZmY4MTYwZjRjOT5dID8gX19za2JfY2xvbmUrMHgyOS8weDEyMA0K
WyAgIDM0Ljc5NTMzMF0gIFs8ZmZmZmZmZmY4MTZjZWEyMD5dIHRjcF90cmFuc21pdF9za2Ir
MHg0MDAvMHg4ZDANClsgICAzNC43OTUzMzddICBbPGZmZmZmZmZmODE2ZDExMDY+XSB0Y3Bf
cmV0cmFuc21pdF9za2IrMHgxYzYvMHg1YTANClsgICAzNC43OTUzNDVdICBbPGZmZmZmZmZm
ODE2ZDE2N2U+XSB0Y3BfeG1pdF9yZXRyYW5zbWl0X3F1ZXVlKzB4MTllLzB4MzAwDQpbICAg
MzQuNzk1MzU0XSAgWzxmZmZmZmZmZjgxNmM5OWZmPl0gdGNwX2Zhc3RyZXRyYW5zX2FsZXJ0
KzB4OTRmLzB4Y2IwDQpbICAgMzQuNzk1MzYyXSAgWzxmZmZmZmZmZjgxNmNhNzBjPl0gdGNw
X2FjaysweDlhYy8weDExNTANClsgICAzNC43OTUzNjldICBbPGZmZmZmZmZmODE2Y2Q4NTg+
XSB0Y3BfcmN2X2VzdGFibGlzaGVkKzB4MzE4LzB4NjQwDQpbICAgMzQuNzk1Mzc3XSAgWzxm
ZmZmZmZmZjgxNmQ1ZWVmPl0gPyB0Y3BfdjRfcmN2KzB4NmNmLzB4YjEwDQpbICAgMzQuNzk1
Mzg0XSAgWzxmZmZmZmZmZjgxNmQ1NGQ1Pl0gdGNwX3Y0X2RvX3JjdisweDEzNS8weDQ4MA0K
WyAgIDM0Ljc5NTM5Ml0gIFs8ZmZmZmZmZmY4MTc0NjFkMj5dID8gX3Jhd19zcGluX2xvY2tf
bmVzdGVkKzB4NDIvMHg1MA0KWyAgIDM0Ljc5NTM5OV0gIFs8ZmZmZmZmZmY4MTZkNWVlZj5d
ID8gdGNwX3Y0X3JjdisweDZjZi8weGIxMA0KWyAgIDM0Ljc5NTQwNl0gIFs8ZmZmZmZmZmY4
MTZkNjE3ZD5dIHRjcF92NF9yY3YrMHg5NWQvMHhiMTANClsgICAzNC43OTU0MTNdICBbPGZm
ZmZmZmZmODEwYjBmODg+XSA/IGxvY2tfYWNxdWlyZSsweGQ4LzB4MTAwDQpbICAgMzQuNzk1
NDIwXSAgWzxmZmZmZmZmZjgxNmIyOTk1Pl0gPyBpcF9sb2NhbF9kZWxpdmVyX2ZpbmlzaCsw
eDQ1LzB4MjMwDQpbICAgMzQuNzk1NDI5XSAgWzxmZmZmZmZmZjgxNmIyYTZhPl0gaXBfbG9j
YWxfZGVsaXZlcl9maW5pc2grMHgxMWEvMHgyMzANClsgICAzNC43OTU0NDBdICBbPGZmZmZm
ZmZmODE2YjI5OTU+XSA/IGlwX2xvY2FsX2RlbGl2ZXJfZmluaXNoKzB4NDUvMHgyMzANClsg
ICAzNC43OTU0NTJdICBbPGZmZmZmZmZmODE2YjJiYjg+XSBpcF9sb2NhbF9kZWxpdmVyKzB4
MzgvMHg4MA0KWyAgIDM0Ljc5NTQ1OV0gIFs8ZmZmZmZmZmY4MTZiMjE3YT5dIGlwX3Jjdl9m
aW5pc2grMHgxNWEvMHg2MzANClsgICAzNC43OTU0NjZdICBbPGZmZmZmZmZmODE2YjI4Njg+
XSBpcF9yY3YrMHgyMTgvMHgzMDANClsgICAzNC43OTU0NzNdICBbPGZmZmZmZmZmODE2MWFj
OGQ+XSBfX25ldGlmX3JlY2VpdmVfc2tiKzB4NjVkLzB4OGQwDQpbICAgMzQuNzk1NDgyXSAg
WzxmZmZmZmZmZjgxNjFhNzc1Pl0gPyBfX25ldGlmX3JlY2VpdmVfc2tiKzB4MTQ1LzB4OGQw
DQpbICAgMzQuNzk1NDkwXSAgWzxmZmZmZmZmZjgxMGFkMjJkPl0gPyB0cmFjZV9oYXJkaXJx
c19vbisweGQvMHgxMA0KWyAgIDM0Ljc5NTQ5N10gIFs8ZmZmZmZmZmY4MTBmOTk3Mz5dID8g
ZnJlZV9ob3RfY29sZF9wYWdlKzB4MWIzLzB4MWUwDQpbICAgMzQuNzk1NTA1XSAgWzxmZmZm
ZmZmZjgxNjFkMWY4Pl0gbmV0aWZfcmVjZWl2ZV9za2IrMHgyOC8weGYwDQpbICAgMzQuNzk1
NTEzXSAgWzxmZmZmZmZmZjgxNjEyZDAzPl0gPyBfX3Bza2JfcHVsbF90YWlsKzB4MjUzLzB4
MzQwDQpbICAgMzQuNzk1NTIwXSAgWzxmZmZmZmZmZjgxNDZlNGM1Pl0geGVubmV0X3BvbGwr
MHhhZDUvMHhlMTANClsgICAzNC43OTU1MjldICBbPGZmZmZmZmZmODE2MWRmYTY+XSBuZXRf
cnhfYWN0aW9uKzB4MTM2LzB4MjYwDQpbICAgMzQuNzk1NTM2XSAgWzxmZmZmZmZmZjgxMDZl
MzgxPl0gPyBfX2RvX3NvZnRpcnErMHg3MS8weDFhMA0KWyAgIDM0Ljc5NTU0NF0gIFs8ZmZm
ZmZmZmY4MTA2ZTNkOT5dIF9fZG9fc29mdGlycSsweGM5LzB4MWEwDQpbICAgMzQuNzk1NTUx
XSAgWzxmZmZmZmZmZjgxNzQ4ZDNjPl0gY2FsbF9zb2Z0aXJxKzB4MWMvMHgzMA0KWyAgIDM0
Ljc5NTU1OF0gIFs8ZmZmZmZmZmY4MTAwZWRiNT5dIGRvX3NvZnRpcnErMHg4NS8weGYwDQpb
ICAgMzQuNzk1NTY1XSAgWzxmZmZmZmZmZjgxMDZlMjRlPl0gaXJxX2V4aXQrMHg5ZS8weGQw
DQpbICAgMzQuNzk1NTcyXSAgWzxmZmZmZmZmZjgxMzM5ZjVmPl0geGVuX2V2dGNobl9kb191
cGNhbGwrMHgyZi8weDQwDQpbICAgMzQuNzk1NTgwXSAgWzxmZmZmZmZmZjgxNzQ4ZDllPl0g
eGVuX2RvX2h5cGVydmlzb3JfY2FsbGJhY2srMHgxZS8weDMwDQpbICAgMzQuNzk1NTg2XSAg
PEVPST4gIFs8ZmZmZmZmZmY4MTAwMTNhYT5dID8geGVuX2h5cGVyY2FsbF9zY2hlZF9vcCsw
eGEvMHgyMA0KWyAgIDM0Ljc5NTU5OF0gIFs8ZmZmZmZmZmY4MTAwMTNhYT5dID8geGVuX2h5
cGVyY2FsbF9zY2hlZF9vcCsweGEvMHgyMA0KWyAgIDM0Ljc5NTYwNl0gIFs8ZmZmZmZmZmY4
MTAwODY5MD5dID8geGVuX3NhZmVfaGFsdCsweDEwLzB4MjANClsgICAzNC43OTU2MTNdICBb
PGZmZmZmZmZmODEwMTYwZDA+XSA/IGRlZmF1bHRfaWRsZSsweDQwLzB4OTANClsgICAzNC43
OTU2MjBdICBbPGZmZmZmZmZmODEwMTY0ODY+XSA/IGNwdV9pZGxlKzB4OTYvMHhmMA0KWyAg
IDM0Ljc5NTYyN10gIFs8ZmZmZmZmZmY4MTcyMmQzYz5dID8gcmVzdF9pbml0KzB4YmMvMHhk
MA0KWyAgIDM0Ljc5NTYzM10gIFs8ZmZmZmZmZmY4MTcyMmM4MD5dID8gY3N1bV9wYXJ0aWFs
X2NvcHlfZ2VuZXJpYysweDE3MC8weDE3MA0KWyAgIDM0Ljc5NTY0MV0gIFs8ZmZmZmZmZmY4
MWNlMGRmMj5dID8gc3RhcnRfa2VybmVsKzB4MzkwLzB4MzlkDQpbICAgMzQuNzk1NjQ5XSAg
WzxmZmZmZmZmZjgxY2UwODgyPl0gPyBrZXJuZWxfaW5pdCsweDIwYi8weDIwYg0KWyAgIDM0
Ljc5NTY1Nl0gIFs8ZmZmZmZmZmY4MWNlMDM1Nj5dID8geDg2XzY0X3N0YXJ0X3Jlc2VydmF0
aW9ucysweDEzMS8weDEzNg0KWyAgIDM0Ljc5NTY2NV0gIFs8ZmZmZmZmZmY4MWNlM2Q2MD5d
ID8geGVuX3N0YXJ0X2tlcm5lbCsweDcwZC8weDcwZg0KWyAgIDM0Ljc5NTY3Ml0gLS0tWyBl
bmQgdHJhY2UgMmUyOGVlYzkzYjdhOGI3OCBdLS0tDQpbICAgMzQuNzk3NDUwXSAtLS0tLS0t
LS0tLS1bIGN1dCBoZXJlIF0tLS0tLS0tLS0tLS0NClsgICAzNC43OTc0NjRdIFdBUk5JTkc6
IGF0IGRyaXZlcnMvbmV0L3hlbi1uZXRmcm9udC5jOjQ2NSB4ZW5uZXRfc3RhcnRfeG1pdCsw
eDdmZS8weDg2MCgpDQpbICAgMzQuNzk3NDc0XSBNb2R1bGVzIGxpbmtlZCBpbjoNClsgICAz
NC43OTc0ODJdIFBpZDogMTUzMiwgY29tbToga2xvZ2QgVGFpbnRlZDogRyAgICAgICAgVyAg
ICAzLjYuMHByZS1yYzEtMjAxMjEwMTEgIzENClsgICAzNC43OTc0ODldIENhbGwgVHJhY2U6
DQpbICAgMzQuNzk3NDkzXSAgPElSUT4gIFs8ZmZmZmZmZmY4MTA2NjRlYT5dIHdhcm5fc2xv
d3BhdGhfY29tbW9uKzB4N2EvMHhiMA0KWyAgIDM0Ljc5NzUwNl0gIFs8ZmZmZmZmZmY4MTA2
NjUzNT5dIHdhcm5fc2xvd3BhdGhfbnVsbCsweDE1LzB4MjANClsgICAzNC43OTc1MTNdICBb
PGZmZmZmZmZmODE0NmQ4OWU+XSB4ZW5uZXRfc3RhcnRfeG1pdCsweDdmZS8weDg2MA0KWyAg
IDM0Ljc5NzUyMl0gIFs8ZmZmZmZmZmY4MTYxZjM0OT5dIGRldl9oYXJkX3N0YXJ0X3htaXQr
MHgyMDkvMHg0NjANClsgICAzNC43OTc1MzBdICBbPGZmZmZmZmZmODE2M2IwMzY+XSBzY2hf
ZGlyZWN0X3htaXQrMHhmNi8weDI5MA0KWyAgIDM0Ljc5NzUzN10gIFs8ZmZmZmZmZmY4MTYx
Zjc0Nj5dIGRldl9xdWV1ZV94bWl0KzB4MWE2LzB4NWEwDQpbICAgMzQuNzk3NTQ1XSAgWzxm
ZmZmZmZmZjgxNjFmNWEwPl0gPyBkZXZfaGFyZF9zdGFydF94bWl0KzB4NDYwLzB4NDYwDQpb
ICAgMzQuNzk3NTU0XSAgWzxmZmZmZmZmZjgxMGIxNDE3Pl0gPyBsb2NrX3JlbGVhc2UrMHgx
MTcvMHgyNTANClsgICAzNC43OTc1NjJdICBbPGZmZmZmZmZmODE2Yjk1MzY+XSBpcF9maW5p
c2hfb3V0cHV0KzB4MjI2LzB4NTMwDQpbICAgMzQuNzk3NTcwXSAgWzxmZmZmZmZmZjgxNmI5
M2RkPl0gPyBpcF9maW5pc2hfb3V0cHV0KzB4Y2QvMHg1MzANClsgICAzNC43OTc1NzhdICBb
PGZmZmZmZmZmODE2Yjk4OTk+XSBpcF9vdXRwdXQrMHg1OS8weGUwDQpbICAgMzQuNzk3NTg3
XSAgWzxmZmZmZmZmZjgxNmI4M2I4Pl0gaXBfbG9jYWxfb3V0KzB4MjgvMHg5MA0KWyAgIDM0
Ljc5NzU5NF0gIFs8ZmZmZmZmZmY4MTZiODk2Zj5dIGlwX3F1ZXVlX3htaXQrMHgxN2YvMHg0
YTANClsgICAzNC43OTc2MDFdICBbPGZmZmZmZmZmODE2Yjg3ZjA+XSA/IGlwX3NlbmRfdW5p
Y2FzdF9yZXBseSsweDM0MC8weDM0MA0KWyAgIDM0Ljc5NzYwOV0gIFs8ZmZmZmZmZmY4MTBh
MGJhNz5dID8gZ2V0bnN0aW1lb2ZkYXkrMHg0Ny8weGUwDQpbICAgMzQuNzk3NjE3XSAgWzxm
ZmZmZmZmZjgxNjBmNGM5Pl0gPyBfX3NrYl9jbG9uZSsweDI5LzB4MTIwDQpbICAgMzQuNzk3
NjI0XSAgWzxmZmZmZmZmZjgxNmNlYTIwPl0gdGNwX3RyYW5zbWl0X3NrYisweDQwMC8weDhk
MA0KWyAgIDM0Ljc5NzYzMl0gIFs8ZmZmZmZmZmY4MTZkMTEwNj5dIHRjcF9yZXRyYW5zbWl0
X3NrYisweDFjNi8weDVhMA0KWyAgIDM0Ljc5NzY0MF0gIFs8ZmZmZmZmZmY4MTc0NmNiNT5d
ID8gX3Jhd19zcGluX3VubG9ja19pcnFyZXN0b3JlKzB4NzUvMHhhMA0KWyAgIDM0Ljc5NzY0
OF0gIFs8ZmZmZmZmZmY4MTZkMTY3ZT5dIHRjcF94bWl0X3JldHJhbnNtaXRfcXVldWUrMHgx
OWUvMHgzMDANClsgICAzNC43OTc2NTZdICBbPGZmZmZmZmZmODE2Yzk5ZmY+XSB0Y3BfZmFz
dHJldHJhbnNfYWxlcnQrMHg5NGYvMHhjYjANClsgICAzNC43OTc2NjNdICBbPGZmZmZmZmZm
ODE2Y2E3MGM+XSB0Y3BfYWNrKzB4OWFjLzB4MTE1MA0KWyAgIDM0Ljc5NzY3MV0gIFs8ZmZm
ZmZmZmY4MTZjZDhjZT5dIHRjcF9yY3ZfZXN0YWJsaXNoZWQrMHgzOGUvMHg2NDANClsgICAz
NC43OTc2NzhdICBbPGZmZmZmZmZmODE2ZDVlZWY+XSA/IHRjcF92NF9yY3YrMHg2Y2YvMHhi
MTANClsgICAzNC43OTc2ODZdICBbPGZmZmZmZmZmODE2ZDU0ZDU+XSB0Y3BfdjRfZG9fcmN2
KzB4MTM1LzB4NDgwDQpbICAgMzQuNzk3NjkzXSAgWzxmZmZmZmZmZjgxNzQ2MWQyPl0gPyBf
cmF3X3NwaW5fbG9ja19uZXN0ZWQrMHg0Mi8weDUwDQpbICAgMzQuNzk3NzAxXSAgWzxmZmZm
ZmZmZjgxNmQ1ZWVmPl0gPyB0Y3BfdjRfcmN2KzB4NmNmLzB4YjEwDQpbICAgMzQuNzk3NzA4
XSAgWzxmZmZmZmZmZjgxNmQ2MTdkPl0gdGNwX3Y0X3JjdisweDk1ZC8weGIxMA0KWyAgIDM0
Ljc5NzcxNV0gIFs8ZmZmZmZmZmY4MTBiMGY4OD5dID8gbG9ja19hY3F1aXJlKzB4ZDgvMHgx
MDANClsgICAzNC43OTc3MjNdICBbPGZmZmZmZmZmODE2YjI5OTU+XSA/IGlwX2xvY2FsX2Rl
bGl2ZXJfZmluaXNoKzB4NDUvMHgyMzANClsgICAzNC43OTc3MzFdICBbPGZmZmZmZmZmODE2
YjJhNmE+XSBpcF9sb2NhbF9kZWxpdmVyX2ZpbmlzaCsweDExYS8weDIzMA0KWyAgIDM0Ljc5
Nzc0M10gIFs8ZmZmZmZmZmY4MTZiMjk5NT5dID8gaXBfbG9jYWxfZGVsaXZlcl9maW5pc2gr
MHg0NS8weDIzMA0KWyAgIDM0Ljc5Nzc1MV0gIFs8ZmZmZmZmZmY4MTZiMmJiOD5dIGlwX2xv
Y2FsX2RlbGl2ZXIrMHgzOC8weDgwDQpbICAgMzQuNzk3NzU5XSAgWzxmZmZmZmZmZjgxNmIy
MTdhPl0gaXBfcmN2X2ZpbmlzaCsweDE1YS8weDYzMA0KWyAgIDM0Ljc5Nzc2Nl0gIFs8ZmZm
ZmZmZmY4MTZiMjg2OD5dIGlwX3JjdisweDIxOC8weDMwMA0KWyAgIDM0Ljc5Nzc3M10gIFs8
ZmZmZmZmZmY4MTYxYWM4ZD5dIF9fbmV0aWZfcmVjZWl2ZV9za2IrMHg2NWQvMHg4ZDANClsg
ICAzNC43OTc3ODBdICBbPGZmZmZmZmZmODE2MWE3NzU+XSA/IF9fbmV0aWZfcmVjZWl2ZV9z
a2IrMHgxNDUvMHg4ZDANClsgICAzNC43OTc3ODhdICBbPGZmZmZmZmZmODEwYWQyMmQ+XSA/
IHRyYWNlX2hhcmRpcnFzX29uKzB4ZC8weDEwDQpbICAgMzQuNzk3Nzk2XSAgWzxmZmZmZmZm
ZjgxMGY5OTczPl0gPyBmcmVlX2hvdF9jb2xkX3BhZ2UrMHgxYjMvMHgxZTANClsgICAzNC43
OTc4MDRdICBbPGZmZmZmZmZmODE2MWQxZjg+XSBuZXRpZl9yZWNlaXZlX3NrYisweDI4LzB4
ZjANClsgICAzNC43OTc4MTFdICBbPGZmZmZmZmZmODE2MTJkMDM+XSA/IF9fcHNrYl9wdWxs
X3RhaWwrMHgyNTMvMHgzNDANClsgICAzNC43OTc4MTldICBbPGZmZmZmZmZmODE0NmU0YzU+
XSB4ZW5uZXRfcG9sbCsweGFkNS8weGUxMA0KWyAgIDM0Ljc5NzgyN10gIFs8ZmZmZmZmZmY4
MTYxZGZhNj5dIG5ldF9yeF9hY3Rpb24rMHgxMzYvMHgyNjANClsgICAzNC43OTc4MzVdICBb
PGZmZmZmZmZmODEwNmUzODE+XSA/IF9fZG9fc29mdGlycSsweDcxLzB4MWEwDQpbICAgMzQu
Nzk3ODQyXSAgWzxmZmZmZmZmZjgxMDZlM2Q5Pl0gX19kb19zb2Z0aXJxKzB4YzkvMHgxYTAN
ClsgICAzNC43OTc4NDldICBbPGZmZmZmZmZmODE3NDhkM2M+XSBjYWxsX3NvZnRpcnErMHgx
Yy8weDMwDQpbICAgMzQuNzk3ODU2XSAgWzxmZmZmZmZmZjgxMDBlZGI1Pl0gZG9fc29mdGly
cSsweDg1LzB4ZjANClsgICAzNC43OTc4NjNdICBbPGZmZmZmZmZmODEwNmUyNGU+XSBpcnFf
ZXhpdCsweDllLzB4ZDANClsgICAzNC43OTc4NzFdICBbPGZmZmZmZmZmODEzMzlmNWY+XSB4
ZW5fZXZ0Y2huX2RvX3VwY2FsbCsweDJmLzB4NDANClsgICAzNC43OTc4NzldICBbPGZmZmZm
ZmZmODE3NDhkOWU+XSB4ZW5fZG9faHlwZXJ2aXNvcl9jYWxsYmFjaysweDFlLzB4MzANClsg
ICAzNC43OTc4ODVdICA8RU9JPiANClsgICAzNC43OTc4ODldIC0tLVsgZW5kIHRyYWNlIDJl
MjhlZWM5M2I3YThiNzkgXS0tLQ0KWyAgIDM0Ljc5NzkxN10gLS0tLS0tLS0tLS0tWyBjdXQg
aGVyZSBdLS0tLS0tLS0tLS0tDQpbICAgMzQuNzk3OTI1XSBXQVJOSU5HOiBhdCBkcml2ZXJz
L25ldC94ZW4tbmV0ZnJvbnQuYzo0NjUgeGVubmV0X3N0YXJ0X3htaXQrMHg3ZmUvMHg4NjAo
KQ0KWyAgIDM0Ljc5NzkzMl0gTW9kdWxlcyBsaW5rZWQgaW46DQpbICAgMzQuNzk3OTM5XSBQ
aWQ6IDE1MzIsIGNvbW06IGtsb2dkIFRhaW50ZWQ6IEcgICAgICAgIFcgICAgMy42LjBwcmUt
cmMxLTIwMTIxMDExICMxDQpbICAgMzQuNzk3OTQ3XSBDYWxsIFRyYWNlOg0KWyAgIDM0Ljc5
Nzk1MF0gIDxJUlE+ICBbPGZmZmZmZmZmODEwNjY0ZWE+XSB3YXJuX3Nsb3dwYXRoX2NvbW1v
bisweDdhLzB4YjANClsgICAzNC43OTc5NjJdICBbPGZmZmZmZmZmODEwNjY1MzU+XSB3YXJu
X3Nsb3dwYXRoX251bGwrMHgxNS8weDIwDQpbICAgMzQuNzk3OTcwXSAgWzxmZmZmZmZmZjgx
NDZkODllPl0geGVubmV0X3N0YXJ0X3htaXQrMHg3ZmUvMHg4NjANClsgICAzNC43OTc5Nzhd
ICBbPGZmZmZmZmZmODE2MWYzNDk+XSBkZXZfaGFyZF9zdGFydF94bWl0KzB4MjA5LzB4NDYw
DQpbICAgMzQuNzk3OTg2XSAgWzxmZmZmZmZmZjgxNjNiMDM2Pl0gc2NoX2RpcmVjdF94bWl0
KzB4ZjYvMHgyOTANClsgICAzNC43OTc5OTRdICBbPGZmZmZmZmZmODE2MWY3NDY+XSBkZXZf
cXVldWVfeG1pdCsweDFhNi8weDVhMA0KWyAgIDM0Ljc5ODAwMV0gIFs8ZmZmZmZmZmY4MTYx
ZjVhMD5dID8gZGV2X2hhcmRfc3RhcnRfeG1pdCsweDQ2MC8weDQ2MA0KWyAgIDM0Ljc5ODAx
Ml0gIFs8ZmZmZmZmZmY4MTBiMTQxNz5dID8gbG9ja19yZWxlYXNlKzB4MTE3LzB4MjUwDQpb
ICAgMzQuNzk4MDE5XSAgWzxmZmZmZmZmZjgxNmI5NTM2Pl0gaXBfZmluaXNoX291dHB1dCsw
eDIyNi8weDUzMA0KWyAgIDM0Ljc5ODAyN10gIFs8ZmZmZmZmZmY4MTZiOTNkZD5dID8gaXBf
ZmluaXNoX291dHB1dCsweGNkLzB4NTMwDQpbICAgMzQuNzk4MDM1XSAgWzxmZmZmZmZmZjgx
NmI5ODk5Pl0gaXBfb3V0cHV0KzB4NTkvMHhlMA0KWyAgIDM0Ljc5ODA0M10gIFs8ZmZmZmZm
ZmY4MTZiODNiOD5dIGlwX2xvY2FsX291dCsweDI4LzB4OTANClsgICAzNC43OTgwNTBdICBb
PGZmZmZmZmZmODE2Yjg5NmY+XSBpcF9xdWV1ZV94bWl0KzB4MTdmLzB4NGEwDQpbICAgMzQu
Nzk4MDU3XSAgWzxmZmZmZmZmZjgxNmI4N2YwPl0gPyBpcF9zZW5kX3VuaWNhc3RfcmVwbHkr
MHgzNDAvMHgzNDANClsgICAzNC43OTgwNjVdICBbPGZmZmZmZmZmODEwYTBiYTc+XSA/IGdl
dG5zdGltZW9mZGF5KzB4NDcvMHhlMA0KWyAgIDM0Ljc5ODA3Ml0gIFs8ZmZmZmZmZmY4MTYw
ZjRjOT5dID8gX19za2JfY2xvbmUrMHgyOS8weDEyMA0KWyAgIDM0Ljc5ODA4MF0gIFs8ZmZm
ZmZmZmY4MTZjZWEyMD5dIHRjcF90cmFuc21pdF9za2IrMHg0MDAvMHg4ZDANClsgICAzNC43
OTgwODddICBbPGZmZmZmZmZmODE2ZDExMDY+XSB0Y3BfcmV0cmFuc21pdF9za2IrMHgxYzYv
MHg1YTANClsgICAzNC43OTgwOTVdICBbPGZmZmZmZmZmODE3NDZjYjU+XSA/IF9yYXdfc3Bp
bl91bmxvY2tfaXJxcmVzdG9yZSsweDc1LzB4YTANClsgICAzNC43OTgxMDNdICBbPGZmZmZm
ZmZmODE2ZDE2N2U+XSB0Y3BfeG1pdF9yZXRyYW5zbWl0X3F1ZXVlKzB4MTllLzB4MzAwDQpb
ICAgMzQuNzk4MTExXSAgWzxmZmZmZmZmZjgxNmM5OWZmPl0gdGNwX2Zhc3RyZXRyYW5zX2Fs
ZXJ0KzB4OTRmLzB4Y2IwDQpbICAgMzQuNzk4MTE5XSAgWzxmZmZmZmZmZjgxNmNhNzBjPl0g
dGNwX2FjaysweDlhYy8weDExNTANClsgICAzNC43OTgxMjZdICBbPGZmZmZmZmZmODE2Y2Q4
Y2U+XSB0Y3BfcmN2X2VzdGFibGlzaGVkKzB4MzhlLzB4NjQwDQpbICAgMzQuNzk4MTM0XSAg
WzxmZmZmZmZmZjgxNmQ1ZWVmPl0gPyB0Y3BfdjRfcmN2KzB4NmNmLzB4YjEwDQpbICAgMzQu
Nzk4MTQxXSAgWzxmZmZmZmZmZjgxNmQ1NGQ1Pl0gdGNwX3Y0X2RvX3JjdisweDEzNS8weDQ4
MA0KWyAgIDM0Ljc5ODE0OV0gIFs8ZmZmZmZmZmY4MTc0NjFkMj5dID8gX3Jhd19zcGluX2xv
Y2tfbmVzdGVkKzB4NDIvMHg1MA0KWyAgIDM0Ljc5ODE1Nl0gIFs8ZmZmZmZmZmY4MTZkNWVl
Zj5dID8gdGNwX3Y0X3JjdisweDZjZi8weGIxMA0KWyAgIDM0Ljc5ODE2NF0gIFs8ZmZmZmZm
ZmY4MTZkNjE3ZD5dIHRjcF92NF9yY3YrMHg5NWQvMHhiMTANClsgICAzNC43OTgxNzFdICBb
PGZmZmZmZmZmODEwYjBmODg+XSA/IGxvY2tfYWNxdWlyZSsweGQ4LzB4MTAwDQpbICAgMzQu
Nzk4MTc4XSAgWzxmZmZmZmZmZjgxNmIyOTk1Pl0gPyBpcF9sb2NhbF9kZWxpdmVyX2Zpbmlz
aCsweDQ1LzB4MjMwDQpbICAgMzQuNzk4MTg2XSAgWzxmZmZmZmZmZjgxNmIyYTZhPl0gaXBf
bG9jYWxfZGVsaXZlcl9maW5pc2grMHgxMWEvMHgyMzANClsgICAzNC43OTgxOTRdICBbPGZm
ZmZmZmZmODE2YjI5OTU+XSA/IGlwX2xvY2FsX2RlbGl2ZXJfZmluaXNoKzB4NDUvMHgyMzAN
ClsgICAzNC43OTgyMDJdICBbPGZmZmZmZmZmODE2YjJiYjg+XSBpcF9sb2NhbF9kZWxpdmVy
KzB4MzgvMHg4MA0KWyAgIDM0Ljc5ODIxMF0gIFs8ZmZmZmZmZmY4MTZiMjE3YT5dIGlwX3Jj
dl9maW5pc2grMHgxNWEvMHg2MzANClsgICAzNC43OTgyMjBdICBbPGZmZmZmZmZmODE2YjI4
Njg+XSBpcF9yY3YrMHgyMTgvMHgzMDANClsgICAzNC43OTgyMjddICBbPGZmZmZmZmZmODE2
MWFjOGQ+XSBfX25ldGlmX3JlY2VpdmVfc2tiKzB4NjVkLzB4OGQwDQpbICAgMzQuNzk4MjM0
XSAgWzxmZmZmZmZmZjgxNjFhNzc1Pl0gPyBfX25ldGlmX3JlY2VpdmVfc2tiKzB4MTQ1LzB4
OGQwDQpbICAgMzQuNzk4MjQyXSAgWzxmZmZmZmZmZjgxMGFkMjJkPl0gPyB0cmFjZV9oYXJk
aXJxc19vbisweGQvMHgxMA0KWyAgIDM0Ljc5ODI0OV0gIFs8ZmZmZmZmZmY4MTBmOTk3Mz5d
ID8gZnJlZV9ob3RfY29sZF9wYWdlKzB4MWIzLzB4MWUwDQpbICAgMzQuNzk4MjU3XSAgWzxm
ZmZmZmZmZjgxNjFkMWY4Pl0gbmV0aWZfcmVjZWl2ZV9za2IrMHgyOC8weGYwDQpbICAgMzQu
Nzk4MjY1XSAgWzxmZmZmZmZmZjgxNjEyZDAzPl0gPyBfX3Bza2JfcHVsbF90YWlsKzB4MjUz
LzB4MzQwDQpbICAgMzQuNzk4Mjc2XSAgWzxmZmZmZmZmZjgxNDZlNGM1Pl0geGVubmV0X3Bv
bGwrMHhhZDUvMHhlMTANClsgICAzNC43OTgyODVdICBbPGZmZmZmZmZmODE2MWRmYTY+XSBu
ZXRfcnhfYWN0aW9uKzB4MTM2LzB4MjYwDQpbICAgMzQuNzk4MjkyXSAgWzxmZmZmZmZmZjgx
MDZlMzgxPl0gPyBfX2RvX3NvZnRpcnErMHg3MS8weDFhMA0KWyAgIDM0Ljc5ODMwMF0gIFs8
ZmZmZmZmZmY4MTA2ZTNkOT5dIF9fZG9fc29mdGlycSsweGM5LzB4MWEwDQpbICAgMzQuNzk4
MzA3XSAgWzxmZmZmZmZmZjgxNzQ4ZDNjPl0gY2FsbF9zb2Z0aXJxKzB4MWMvMHgzMA0KWyAg
IDM0Ljc5ODMxNF0gIFs8ZmZmZmZmZmY4MTAwZWRiNT5dIGRvX3NvZnRpcnErMHg4NS8weGYw
DQpbICAgMzQuNzk4MzIxXSAgWzxmZmZmZmZmZjgxMDZlMjRlPl0gaXJxX2V4aXQrMHg5ZS8w
eGQwDQpbICAgMzQuNzk4MzI4XSAgWzxmZmZmZmZmZjgxMzM5ZjVmPl0geGVuX2V2dGNobl9k
b191cGNhbGwrMHgyZi8weDQwDQpbICAgMzQuNzk4MzM1XSAgWzxmZmZmZmZmZjgxNzQ4ZDll
Pl0geGVuX2RvX2h5cGVydmlzb3JfY2FsbGJhY2srMHgxZS8weDMwDQpbICAgMzQuNzk4MzQy
XSAgPEVPST4gDQpbICAgMzQuNzk4MzQ1XSAtLS1bIGVuZCB0cmFjZSAyZTI4ZWVjOTNiN2E4
YjdhIF0tLS0NClsgICAzNC43OTgzNjhdIC0tLS0tLS0tLS0tLVsgY3V0IGhlcmUgXS0tLS0t
LS0tLS0tLQ0KWyAgIDM0Ljc5ODM3NV0gV0FSTklORzogYXQgZHJpdmVycy9uZXQveGVuLW5l
dGZyb250LmM6NDY1IHhlbm5ldF9zdGFydF94bWl0KzB4N2ZlLzB4ODYwKCkNClsgICAzNC43
OTgzODNdIE1vZHVsZXMgbGlua2VkIGluOg0KWyAgIDM0Ljc5ODM4OF0gUGlkOiAxNTMyLCBj
b21tOiBrbG9nZCBUYWludGVkOiBHICAgICAgICBXICAgIDMuNi4wcHJlLXJjMS0yMDEyMTAx
MSAjMQ0KWyAgIDM0Ljc5ODM5Nl0gQ2FsbCBUcmFjZToNClsgICAzNC43OTg0MDBdICA8SVJR
PiAgWzxmZmZmZmZmZjgxMDY2NGVhPl0gd2Fybl9zbG93cGF0aF9jb21tb24rMHg3YS8weGIw
DQpbICAgMzQuNzk4NDExXSAgWzxmZmZmZmZmZjgxMDY2NTM1Pl0gd2Fybl9zbG93cGF0aF9u
dWxsKzB4MTUvMHgyMA0KWyAgIDM0Ljc5ODQxOF0gIFs8ZmZmZmZmZmY4MTQ2ZDg5ZT5dIHhl
bm5ldF9zdGFydF94bWl0KzB4N2ZlLzB4ODYwDQpbICAgMzQuNzk4NDI2XSAgWzxmZmZmZmZm
ZjgxNjFmMzQ5Pl0gZGV2X2hhcmRfc3RhcnRfeG1pdCsweDIwOS8weDQ2MA0KWyAgIDM0Ljc5
ODQzNF0gIFs8ZmZmZmZmZmY4MTYzYjAzNj5dIHNjaF9kaXJlY3RfeG1pdCsweGY2LzB4Mjkw
DQpbICAgMzQuNzk4NDQyXSAgWzxmZmZmZmZmZjgxNjFmNzQ2Pl0gZGV2X3F1ZXVlX3htaXQr
MHgxYTYvMHg1YTANClsgICAzNC43OTg0NDldICBbPGZmZmZmZmZmODE2MWY1YTA+XSA/IGRl
dl9oYXJkX3N0YXJ0X3htaXQrMHg0NjAvMHg0NjANClsgICAzNC43OTg0NTddICBbPGZmZmZm
ZmZmODEwYjE0MTc+XSA/IGxvY2tfcmVsZWFzZSsweDExNy8weDI1MA0KWyAgIDM0Ljc5ODQ2
NV0gIFs8ZmZmZmZmZmY4MTZiOTUzNj5dIGlwX2ZpbmlzaF9vdXRwdXQrMHgyMjYvMHg1MzAN
ClsgICAzNC43OTg0NzJdICBbPGZmZmZmZmZmODE2YjkzZGQ+XSA/IGlwX2ZpbmlzaF9vdXRw
dXQrMHhjZC8weDUzMA0KWyAgIDM0Ljc5ODQ4MF0gIFs8ZmZmZmZmZmY4MTZiOTg5OT5dIGlw
X291dHB1dCsweDU5LzB4ZTANClsgICAzNC43OTg0ODddICBbPGZmZmZmZmZmODE2YjgzYjg+
XSBpcF9sb2NhbF9vdXQrMHgyOC8weDkwDQpbICAgMzQuNzk4NDk0XSAgWzxmZmZmZmZmZjgx
NmI4OTZmPl0gaXBfcXVldWVfeG1pdCsweDE3Zi8weDRhMA0KWyAgIDM0Ljc5ODUwMl0gIFs8
ZmZmZmZmZmY4MTZiODdmMD5dID8gaXBfc2VuZF91bmljYXN0X3JlcGx5KzB4MzQwLzB4MzQw
DQpbICAgMzQuNzk4NTEwXSAgWzxmZmZmZmZmZjgxMGEwYmE3Pl0gPyBnZXRuc3RpbWVvZmRh
eSsweDQ3LzB4ZTANClsgICAzNC43OTg1MThdICBbPGZmZmZmZmZmODE2MGY0Yzk+XSA/IF9f
c2tiX2Nsb25lKzB4MjkvMHgxMjANClsgICAzNC43OTg1MjZdICBbPGZmZmZmZmZmODE2Y2Vh
MjA+XSB0Y3BfdHJhbnNtaXRfc2tiKzB4NDAwLzB4OGQwDQpbICAgMzQuNzk4NTM0XSAgWzxm
ZmZmZmZmZjgxNmQxMTA2Pl0gdGNwX3JldHJhbnNtaXRfc2tiKzB4MWM2LzB4NWEwDQpbICAg
MzQuNzk4NTQxXSAgWzxmZmZmZmZmZjgxNzQ2Y2I1Pl0gPyBfcmF3X3NwaW5fdW5sb2NrX2ly
cXJlc3RvcmUrMHg3NS8weGEwDQpbICAgMzQuNzk4NTUwXSAgWzxmZmZmZmZmZjgxNmQxNjdl
Pl0gdGNwX3htaXRfcmV0cmFuc21pdF9xdWV1ZSsweDE5ZS8weDMwMA0KWyAgIDM0Ljc5ODU1
OF0gIFs8ZmZmZmZmZmY4MTZjOTlmZj5dIHRjcF9mYXN0cmV0cmFuc19hbGVydCsweDk0Zi8w
eGNiMA0KWyAgIDM0Ljc5ODU2NV0gIFs8ZmZmZmZmZmY4MTZjYTcwYz5dIHRjcF9hY2srMHg5
YWMvMHgxMTUwDQpbICAgMzQuNzk4NTczXSAgWzxmZmZmZmZmZjgxNmNkOGNlPl0gdGNwX3Jj
dl9lc3RhYmxpc2hlZCsweDM4ZS8weDY0MA0KWyAgIDM0Ljc5ODU4MF0gIFs8ZmZmZmZmZmY4
MTZkNWVlZj5dID8gdGNwX3Y0X3JjdisweDZjZi8weGIxMA0KWyAgIDM0Ljc5ODU4OF0gIFs8
ZmZmZmZmZmY4MTZkNTRkNT5dIHRjcF92NF9kb19yY3YrMHgxMzUvMHg0ODANClsgICAzNC43
OTg1OTVdICBbPGZmZmZmZmZmODE3NDYxZDI+XSA/IF9yYXdfc3Bpbl9sb2NrX25lc3RlZCsw
eDQyLzB4NTANClsgICAzNC43OTg2MDNdICBbPGZmZmZmZmZmODE2ZDVlZWY+XSA/IHRjcF92
NF9yY3YrMHg2Y2YvMHhiMTANClsgICAzNC43OTg2MTBdICBbPGZmZmZmZmZmODE2ZDYxN2Q+
XSB0Y3BfdjRfcmN2KzB4OTVkLzB4YjEwDQpbICAgMzQuNzk4NjE3XSAgWzxmZmZmZmZmZjgx
MGIwZjg4Pl0gPyBsb2NrX2FjcXVpcmUrMHhkOC8weDEwMA0KWyAgIDM0Ljc5ODYyNF0gIFs8
ZmZmZmZmZmY4MTZiMjk5NT5dID8gaXBfbG9jYWxfZGVsaXZlcl9maW5pc2grMHg0NS8weDIz
MA0KWyAgIDM0Ljc5ODYzM10gIFs8ZmZmZmZmZmY4MTZiMmE2YT5dIGlwX2xvY2FsX2RlbGl2
ZXJfZmluaXNoKzB4MTFhLzB4MjMwDQpbICAgMzQuNzk4NjQwXSAgWzxmZmZmZmZmZjgxNmIy
OTk1Pl0gPyBpcF9sb2NhbF9kZWxpdmVyX2ZpbmlzaCsweDQ1LzB4MjMwDQpbICAgMzQuNzk4
NjQ4XSAgWzxmZmZmZmZmZjgxNmIyYmI4Pl0gaXBfbG9jYWxfZGVsaXZlcisweDM4LzB4ODAN
ClsgICAzNC43OTg2NTZdICBbPGZmZmZmZmZmODE2YjIxN2E+XSBpcF9yY3ZfZmluaXNoKzB4
MTVhLzB4NjMwDQpbICAgMzQuNzk4NjYzXSAgWzxmZmZmZmZmZjgxNmIyODY4Pl0gaXBfcmN2
KzB4MjE4LzB4MzAwDQpbICAgMzQuNzk4NjcwXSAgWzxmZmZmZmZmZjgxNjFhYzhkPl0gX19u
ZXRpZl9yZWNlaXZlX3NrYisweDY1ZC8weDhkMA0KWyAgIDM0Ljc5ODY3OF0gIFs8ZmZmZmZm
ZmY4MTYxYTc3NT5dID8gX19uZXRpZl9yZWNlaXZlX3NrYisweDE0NS8weDhkMA0KWyAgIDM0
Ljc5ODY4NV0gIFs8ZmZmZmZmZmY4MTBhZDIyZD5dID8gdHJhY2VfaGFyZGlycXNfb24rMHhk
LzB4MTANClsgICAzNC43OTg2OTNdICBbPGZmZmZmZmZmODEwZjk5NzM+XSA/IGZyZWVfaG90
X2NvbGRfcGFnZSsweDFiMy8weDFlMA0KWyAgIDM0Ljc5ODcwMV0gIFs8ZmZmZmZmZmY4MTYx
ZDFmOD5dIG5ldGlmX3JlY2VpdmVfc2tiKzB4MjgvMHhmMA0KWyAgIDM0Ljc5ODcwOF0gIFs8
ZmZmZmZmZmY4MTYxMmQwMz5dID8gX19wc2tiX3B1bGxfdGFpbCsweDI1My8weDM0MA0KWyAg
IDM0Ljc5ODcxNl0gIFs8ZmZmZmZmZmY4MTQ2ZTRjNT5dIHhlbm5ldF9wb2xsKzB4YWQ1LzB4
ZTEwDQpbICAgMzQuNzk4NzI1XSAgWzxmZmZmZmZmZjgxNjFkZmE2Pl0gbmV0X3J4X2FjdGlv
bisweDEzNi8weDI2MA0KWyAgIDM0Ljc5ODczMl0gIFs8ZmZmZmZmZmY4MTA2ZTM4MT5dID8g
X19kb19zb2Z0aXJxKzB4NzEvMHgxYTANClsgICAzNC43OTg3MzldICBbPGZmZmZmZmZmODEw
NmUzZDk+XSBfX2RvX3NvZnRpcnErMHhjOS8weDFhMA0KWyAgIDM0Ljc5ODc0N10gIFs8ZmZm
ZmZmZmY4MTc0OGQzYz5dIGNhbGxfc29mdGlycSsweDFjLzB4MzANClsgICAzNC43OTg3NTRd
ICBbPGZmZmZmZmZmODEwMGVkYjU+XSBkb19zb2Z0aXJxKzB4ODUvMHhmMA0KWyAgIDM0Ljc5
ODc2MV0gIFs8ZmZmZmZmZmY4MTA2ZTI0ZT5dIGlycV9leGl0KzB4OWUvMHhkMA0KWyAgIDM0
Ljc5ODc2OF0gIFs8ZmZmZmZmZmY4MTMzOWY1Zj5dIHhlbl9ldnRjaG5fZG9fdXBjYWxsKzB4
MmYvMHg0MA0KWyAgIDM0Ljc5ODc3Nl0gIFs8ZmZmZmZmZmY4MTc0OGQ5ZT5dIHhlbl9kb19o
eXBlcnZpc29yX2NhbGxiYWNrKzB4MWUvMHgzMA0KWyAgIDM0Ljc5ODc4Ml0gIDxFT0k+IA0K
WyAgIDM0Ljc5ODc4Nl0gLS0tWyBlbmQgdHJhY2UgMmUyOGVlYzkzYjdhOGI3YiBdLS0tDQpb
ICAgMzUuMzYzNDQ0XSAtLS0tLS0tLS0tLS1bIGN1dCBoZXJlIF0tLS0tLS0tLS0tLS0NClsg
ICAzNS4zNjM0NjFdIFdBUk5JTkc6IGF0IGRyaXZlcnMvbmV0L3hlbi1uZXRmcm9udC5jOjQ2
NSB4ZW5uZXRfc3RhcnRfeG1pdCsweDdmZS8weDg2MCgpDQpbICAgMzUuMzYzNDY4XSBNb2R1
bGVzIGxpbmtlZCBpbjoNClsgICAzNS4zNjM0NzRdIFBpZDogMCwgY29tbTogc3dhcHBlci8w
IFRhaW50ZWQ6IEcgICAgICAgIFcgICAgMy42LjBwcmUtcmMxLTIwMTIxMDExICMxDQpbICAg
MzUuMzYzNDgwXSBDYWxsIFRyYWNlOg0KWyAgIDM1LjM2MzQ4M10gIDxJUlE+ICBbPGZmZmZm
ZmZmODEwNjY0ZWE+XSB3YXJuX3Nsb3dwYXRoX2NvbW1vbisweDdhLzB4YjANClsgICAzNS4z
NjM0OTVdICBbPGZmZmZmZmZmODEwNjY1MzU+XSB3YXJuX3Nsb3dwYXRoX251bGwrMHgxNS8w
eDIwDQpbICAgMzUuMzYzNTAwXSAgWzxmZmZmZmZmZjgxNDZkODllPl0geGVubmV0X3N0YXJ0
X3htaXQrMHg3ZmUvMHg4NjANClsgICAzNS4zNjM1MDldICBbPGZmZmZmZmZmODE2MWYzNDk+
XSBkZXZfaGFyZF9zdGFydF94bWl0KzB4MjA5LzB4NDYwDQpbICAgMzUuMzYzNTE1XSAgWzxm
ZmZmZmZmZjgxNjNiMDM2Pl0gc2NoX2RpcmVjdF94bWl0KzB4ZjYvMHgyOTANClsgICAzNS4z
NjM1MjJdICBbPGZmZmZmZmZmODE2MWY3NDY+XSBkZXZfcXVldWVfeG1pdCsweDFhNi8weDVh
MA0KWyAgIDM1LjM2MzUyOF0gIFs8ZmZmZmZmZmY4MTYxZjVhMD5dID8gZGV2X2hhcmRfc3Rh
cnRfeG1pdCsweDQ2MC8weDQ2MA0KWyAgIDM1LjM2MzUzNV0gIFs8ZmZmZmZmZmY4MTBiMTQx
Nz5dID8gbG9ja19yZWxlYXNlKzB4MTE3LzB4MjUwDQpbICAgMzUuMzYzNTQyXSAgWzxmZmZm
ZmZmZjgxNmI5NTM2Pl0gaXBfZmluaXNoX291dHB1dCsweDIyNi8weDUzMA0KWyAgIDM1LjM2
MzU0OF0gIFs8ZmZmZmZmZmY4MTZiOTNkZD5dID8gaXBfZmluaXNoX291dHB1dCsweGNkLzB4
NTMwDQpbICAgMzUuMzYzNTU1XSAgWzxmZmZmZmZmZjgxNmI5ODk5Pl0gaXBfb3V0cHV0KzB4
NTkvMHhlMA0KWyAgIDM1LjM2MzU2MF0gIFs8ZmZmZmZmZmY4MTZiODNiOD5dIGlwX2xvY2Fs
X291dCsweDI4LzB4OTANClsgICAzNS4zNjM1NjZdICBbPGZmZmZmZmZmODE2Yjg5NmY+XSBp
cF9xdWV1ZV94bWl0KzB4MTdmLzB4NGEwDQpbICAgMzUuMzYzNTcxXSAgWzxmZmZmZmZmZjgx
NmI4N2YwPl0gPyBpcF9zZW5kX3VuaWNhc3RfcmVwbHkrMHgzNDAvMHgzNDANClsgICAzNS4z
NjM1NzhdICBbPGZmZmZmZmZmODEwYTBiYTc+XSA/IGdldG5zdGltZW9mZGF5KzB4NDcvMHhl
MA0KWyAgIDM1LjM2MzU4NV0gIFs8ZmZmZmZmZmY4MTYwZjRjOT5dID8gX19za2JfY2xvbmUr
MHgyOS8weDEyMA0KWyAgIDM1LjM2MzU5MV0gIFs8ZmZmZmZmZmY4MTZjZWEyMD5dIHRjcF90
cmFuc21pdF9za2IrMHg0MDAvMHg4ZDANClsgICAzNS4zNjM1OTddICBbPGZmZmZmZmZmODE2
ZDExMDY+XSB0Y3BfcmV0cmFuc21pdF9za2IrMHgxYzYvMHg1YTANClsgICAzNS4zNjM2MDNd
ICBbPGZmZmZmZmZmODE2ZDMzYjA+XSA/IHRjcF93cml0ZV90aW1lcl9oYW5kbGVyKzB4MWEw
LzB4MWEwDQpbICAgMzUuMzYzNjA5XSAgWzxmZmZmZmZmZjgxNmQyZjM4Pl0gdGNwX3JldHJh
bnNtaXRfdGltZXIrMHgzNTgvMHg2MzANClsgICAzNS4zNjM2MTVdICBbPGZmZmZmZmZmODE2
ZDMzNGQ+XSB0Y3Bfd3JpdGVfdGltZXJfaGFuZGxlcisweDEzZC8weDFhMA0KWyAgIDM1LjM2
MzYyMF0gIFs8ZmZmZmZmZmY4MTZkMzQyOD5dIHRjcF93cml0ZV90aW1lcisweDc4LzB4ODAN
ClsgICAzNS4zNjM2MjZdICBbPGZmZmZmZmZmODEwNzNmN2M+XSBjYWxsX3RpbWVyX2ZuKzB4
N2MvMHgxMDANClsgICAzNS4zNjM2MzJdICBbPGZmZmZmZmZmODEwNzNmMDA+XSA/IGNhc2Nh
ZGUrMHhhMC8weGEwDQpbICAgMzUuMzYzNjM3XSAgWzxmZmZmZmZmZjgxNmQzM2IwPl0gPyB0
Y3Bfd3JpdGVfdGltZXJfaGFuZGxlcisweDFhMC8weDFhMA0KWyAgIDM1LjM2MzY0M10gIFs8
ZmZmZmZmZmY4MTZkMzNiMD5dID8gdGNwX3dyaXRlX3RpbWVyX2hhbmRsZXIrMHgxYTAvMHgx
YTANClsgICAzNS4zNjM2NDldICBbPGZmZmZmZmZmODEwNzQyMTc+XSBydW5fdGltZXJfc29m
dGlycSsweDIxNy8weDI1MA0KWyAgIDM1LjM2MzY1Nl0gIFs8ZmZmZmZmZmY4MTA2ZTNkOT5d
IF9fZG9fc29mdGlycSsweGM5LzB4MWEwDQpbICAgMzUuMzYzNjYyXSAgWzxmZmZmZmZmZjgx
NzQ4ZDNjPl0gY2FsbF9zb2Z0aXJxKzB4MWMvMHgzMA0KWyAgIDM1LjM2MzY2OF0gIFs8ZmZm
ZmZmZmY4MTAwZWRiNT5dIGRvX3NvZnRpcnErMHg4NS8weGYwDQpbICAgMzUuMzYzNjczXSAg
WzxmZmZmZmZmZjgxMDZlMjRlPl0gaXJxX2V4aXQrMHg5ZS8weGQwDQpbICAgMzUuMzYzNjgw
XSAgWzxmZmZmZmZmZjgxMzM5ZjVmPl0geGVuX2V2dGNobl9kb191cGNhbGwrMHgyZi8weDQw
DQpbICAgMzUuMzYzNjg2XSAgWzxmZmZmZmZmZjgxNzQ4ZDllPl0geGVuX2RvX2h5cGVydmlz
b3JfY2FsbGJhY2srMHgxZS8weDMwDQpbICAgMzUuMzYzNjkxXSAgPEVPST4gIFs8ZmZmZmZm
ZmY4MTAwMTNhYT5dID8geGVuX2h5cGVyY2FsbF9zY2hlZF9vcCsweGEvMHgyMA0KWyAgIDM1
LjM2MzcwMV0gIFs8ZmZmZmZmZmY4MTAwMTNhYT5dID8geGVuX2h5cGVyY2FsbF9zY2hlZF9v
cCsweGEvMHgyMA0KWyAgIDM1LjM2MzcwN10gIFs8ZmZmZmZmZmY4MTAwODY5MD5dID8geGVu
X3NhZmVfaGFsdCsweDEwLzB4MjANClsgICAzNS4zNjM3MTNdICBbPGZmZmZmZmZmODEwMTYw
ZDA+XSA/IGRlZmF1bHRfaWRsZSsweDQwLzB4OTANClsgICAzNS4zNjM3MTldICBbPGZmZmZm
ZmZmODEwMTY0ODY+XSA/IGNwdV9pZGxlKzB4OTYvMHhmMA0KWyAgIDM1LjM2MzcyNF0gIFs8
ZmZmZmZmZmY4MTcyMmQzYz5dID8gcmVzdF9pbml0KzB4YmMvMHhkMA0KWyAgIDM1LjM2Mzcy
OV0gIFs8ZmZmZmZmZmY4MTcyMmM4MD5dID8gY3N1bV9wYXJ0aWFsX2NvcHlfZ2VuZXJpYysw
eDE3MC8weDE3MA0KWyAgIDM1LjM2MzczN10gIFs8ZmZmZmZmZmY4MWNlMGRmMj5dID8gc3Rh
cnRfa2VybmVsKzB4MzkwLzB4MzlkDQpbICAgMzUuMzYzNzQzXSAgWzxmZmZmZmZmZjgxY2Uw
ODgyPl0gPyBrZXJuZWxfaW5pdCsweDIwYi8weDIwYg0KWyAgIDM1LjM2Mzc0OV0gIFs8ZmZm
ZmZmZmY4MWNlMDM1Nj5dID8geDg2XzY0X3N0YXJ0X3Jlc2VydmF0aW9ucysweDEzMS8weDEz
Ng0KWyAgIDM1LjM2Mzc1OV0gIFs8ZmZmZmZmZmY4MWNlM2Q2MD5dID8geGVuX3N0YXJ0X2tl
cm5lbCsweDcwZC8weDcwZg0KWyAgIDM1LjM2Mzc2NF0gLS0tWyBlbmQgdHJhY2UgMmUyOGVl
YzkzYjdhOGI3YyBdLS0tDQpbICAgMzYuNTAwMjIxXSAtLS0tLS0tLS0tLS1bIGN1dCBoZXJl
IF0tLS0tLS0tLS0tLS0NClsgICAzNi41MDAyNjddIFdBUk5JTkc6IGF0IGRyaXZlcnMvbmV0
L3hlbi1uZXRmcm9udC5jOjQ2NSB4ZW5uZXRfc3RhcnRfeG1pdCsweDdmZS8weDg2MCgpDQpb
ICAgMzYuNTAwMjkzXSBNb2R1bGVzIGxpbmtlZCBpbjoNClsgICAzNi41MDAzMTVdIFBpZDog
MCwgY29tbTogc3dhcHBlci8wIFRhaW50ZWQ6IEcgICAgICAgIFcgICAgMy42LjBwcmUtcmMx
LTIwMTIxMDExICMxDQpbICAgMzYuNTAwMzM5XSBDYWxsIFRyYWNlOg0KWyAgIDM2LjUwMDM1
MV0gIDxJUlE+ICBbPGZmZmZmZmZmODEwNjY0ZWE+XSB3YXJuX3Nsb3dwYXRoX2NvbW1vbisw
eDdhLzB4YjANClsgICAzNi41MDAzOTZdICBbPGZmZmZmZmZmODEwNjY1MzU+XSB3YXJuX3Ns
b3dwYXRoX251bGwrMHgxNS8weDIwDQpbICAgMzYuNTAwNDIwXSAgWzxmZmZmZmZmZjgxNDZk
ODllPl0geGVubmV0X3N0YXJ0X3htaXQrMHg3ZmUvMHg4NjANClsgICAzNi41MDA0NDddICBb
PGZmZmZmZmZmODE2MWYzNDk+XSBkZXZfaGFyZF9zdGFydF94bWl0KzB4MjA5LzB4NDYwDQpb
ICAgMzYuNTAwNDcxXSAgWzxmZmZmZmZmZjgxNjNiMDM2Pl0gc2NoX2RpcmVjdF94bWl0KzB4
ZjYvMHgyOTANClsgICAzNi41MDA0OTRdICBbPGZmZmZmZmZmODE2MWY3NDY+XSBkZXZfcXVl
dWVfeG1pdCsweDFhNi8weDVhMA0KWyAgIDM2LjUwMDUxNl0gIFs8ZmZmZmZmZmY4MTYxZjVh
MD5dID8gZGV2X2hhcmRfc3RhcnRfeG1pdCsweDQ2MC8weDQ2MA0KWyAgIDM2LjUwMDU0MV0g
IFs8ZmZmZmZmZmY4MTBiMTQxNz5dID8gbG9ja19yZWxlYXNlKzB4MTE3LzB4MjUwDQpbICAg
MzYuNTAwNTcwXSAgWzxmZmZmZmZmZjgxNmI5NTM2Pl0gaXBfZmluaXNoX291dHB1dCsweDIy
Ni8weDUzMA0KWyAgIDM2LjUwMDU5NF0gIFs8ZmZmZmZmZmY4MTZiOTNkZD5dID8gaXBfZmlu
aXNoX291dHB1dCsweGNkLzB4NTMwDQpbICAgMzYuNTAwNjE5XSAgWzxmZmZmZmZmZjgxNmI5
ODk5Pl0gaXBfb3V0cHV0KzB4NTkvMHhlMA0KWyAgIDM2LjUwMDY0MV0gIFs8ZmZmZmZmZmY4
MTZiODNiOD5dIGlwX2xvY2FsX291dCsweDI4LzB4OTANClsgICAzNi41MDA2NjJdICBbPGZm
ZmZmZmZmODE2Yjg5NmY+XSBpcF9xdWV1ZV94bWl0KzB4MTdmLzB4NGEwDQpbICAgMzYuNTAw
Njg0XSAgWzxmZmZmZmZmZjgxNmI4N2YwPl0gPyBpcF9zZW5kX3VuaWNhc3RfcmVwbHkrMHgz
NDAvMHgzNDANClsgICAzNi41MDA3MDldICBbPGZmZmZmZmZmODEwYTBiYTc+XSA/IGdldG5z
dGltZW9mZGF5KzB4NDcvMHhlMA0KWyAgIDM2LjUwMDczMl0gIFs8ZmZmZmZmZmY4MTYwZjRj
OT5dID8gX19za2JfY2xvbmUrMHgyOS8weDEyMA0KWyAgIDM2LjUwMDc1NV0gIFs8ZmZmZmZm
ZmY4MTZjZWEyMD5dIHRjcF90cmFuc21pdF9za2IrMHg0MDAvMHg4ZDANClsgICAzNi41MDA3
NzldICBbPGZmZmZmZmZmODE2ZDExMDY+XSB0Y3BfcmV0cmFuc21pdF9za2IrMHgxYzYvMHg1
YTANClsgICAzNi41MDA4MDNdICBbPGZmZmZmZmZmODE2ZDMzYjA+XSA/IHRjcF93cml0ZV90
aW1lcl9oYW5kbGVyKzB4MWEwLzB4MWEwDQpbICAgMzYuNTAwODI3XSAgWzxmZmZmZmZmZjgx
NmQyZjM4Pl0gdGNwX3JldHJhbnNtaXRfdGltZXIrMHgzNTgvMHg2MzANClsgICAzNi41MDA4
NTBdICBbPGZmZmZmZmZmODE2ZDMzNGQ+XSB0Y3Bfd3JpdGVfdGltZXJfaGFuZGxlcisweDEz
ZC8weDFhMA0KWyAgIDM2LjUwMDg3NF0gIFs8ZmZmZmZmZmY4MTZkMzQyOD5dIHRjcF93cml0
ZV90aW1lcisweDc4LzB4ODANClsgICAzNi41MDA4OTddICBbPGZmZmZmZmZmODEwNzNmN2M+
XSBjYWxsX3RpbWVyX2ZuKzB4N2MvMHgxMDANClsgICAzNi41MDA5MTddICBbPGZmZmZmZmZm
ODEwNzNmMDA+XSA/IGNhc2NhZGUrMHhhMC8weGEwDQpbICAgMzYuNTAwOTM4XSAgWzxmZmZm
ZmZmZjgxNmQzM2IwPl0gPyB0Y3Bfd3JpdGVfdGltZXJfaGFuZGxlcisweDFhMC8weDFhMA0K
WyAgIDM2LjUwMDk2Ml0gIFs8ZmZmZmZmZmY4MTZkMzNiMD5dID8gdGNwX3dyaXRlX3RpbWVy
X2hhbmRsZXIrMHgxYTAvMHgxYTANClsgICAzNi41MDA5ODVdICBbPGZmZmZmZmZmODEwNzQy
MTc+XSBydW5fdGltZXJfc29mdGlycSsweDIxNy8weDI1MA0KWyAgIDM2LjUwMTAxMV0gIFs8
ZmZmZmZmZmY4MTA2ZTNkOT5dIF9fZG9fc29mdGlycSsweGM5LzB4MWEwDQpbICAgMzYuNTAx
MDM0XSAgWzxmZmZmZmZmZjgxNzQ4ZDNjPl0gY2FsbF9zb2Z0aXJxKzB4MWMvMHgzMA0KWyAg
IDM2LjUwMTA1NV0gIFs8ZmZmZmZmZmY4MTAwZWRiNT5dIGRvX3NvZnRpcnErMHg4NS8weGYw
DQpbICAgMzYuNTAxMDc3XSAgWzxmZmZmZmZmZjgxMDZlMjRlPl0gaXJxX2V4aXQrMHg5ZS8w
eGQwDQpbICAgMzYuNTAxMTAxXSAgWzxmZmZmZmZmZjgxMzM5ZjVmPl0geGVuX2V2dGNobl9k
b191cGNhbGwrMHgyZi8weDQwDQpbICAgMzYuNTAxMTI0XSAgWzxmZmZmZmZmZjgxNzQ4ZDll
Pl0geGVuX2RvX2h5cGVydmlzb3JfY2FsbGJhY2srMHgxZS8weDMwDQpbICAgMzYuNTAxMTQz
XSAgPEVPST4gIFs8ZmZmZmZmZmY4MTAwMTNhYT5dID8geGVuX2h5cGVyY2FsbF9zY2hlZF9v
cCsweGEvMHgyMA0KWyAgIDM2LjUwMTE4MV0gIFs8ZmZmZmZmZmY4MTAwMTNhYT5dID8geGVu
X2h5cGVyY2FsbF9zY2hlZF9vcCsweGEvMHgyMA0KWyAgIDM2LjUwMTIwNV0gIFs8ZmZmZmZm
ZmY4MTAwODY5MD5dID8geGVuX3NhZmVfaGFsdCsweDEwLzB4MjANClsgICAzNi41MDEyMjhd
ICBbPGZmZmZmZmZmODEwMTYwZDA+XSA/IGRlZmF1bHRfaWRsZSsweDQwLzB4OTANClsgICAz
Ni41MDEyNDldICBbPGZmZmZmZmZmODEwMTY0ODY+XSA/IGNwdV9pZGxlKzB4OTYvMHhmMA0K
WyAgIDM2LjUwMTI3MF0gIFs8ZmZmZmZmZmY4MTcyMmQzYz5dID8gcmVzdF9pbml0KzB4YmMv
MHhkMA0KWyAgIDM2LjUwMTI5MF0gIFs8ZmZmZmZmZmY4MTcyMmM4MD5dID8gY3N1bV9wYXJ0
aWFsX2NvcHlfZ2VuZXJpYysweDE3MC8weDE3MA0KWyAgIDM2LjUwMTMxOF0gIFs8ZmZmZmZm
ZmY4MWNlMGRmMj5dID8gc3RhcnRfa2VybmVsKzB4MzkwLzB4MzlkDQpbICAgMzYuNTAxMzQx
XSAgWzxmZmZmZmZmZjgxY2UwODgyPl0gPyBrZXJuZWxfaW5pdCsweDIwYi8weDIwYg0KWyAg
IDM2LjUwMTM2NF0gIFs8ZmZmZmZmZmY4MWNlMDM1Nj5dID8geDg2XzY0X3N0YXJ0X3Jlc2Vy
dmF0aW9ucysweDEzMS8weDEzNg0KWyAgIDM2LjUwMTM4OF0gIFs8ZmZmZmZmZmY4MWNlM2Q2
MD5dID8geGVuX3N0YXJ0X2tlcm5lbCsweDcwZC8weDcwZg0KWyAgIDM2LjUwMTQwOV0gLS0t
WyBlbmQgdHJhY2UgMmUyOGVlYzkzYjdhOGI3ZCBdLS0tDQpbICAgMzguNzczNTEwXSAtLS0t
LS0tLS0tLS1bIGN1dCBoZXJlIF0tLS0tLS0tLS0tLS0NClsgICAzOC43NzM1MjhdIFdBUk5J
Tkc6IGF0IGRyaXZlcnMvbmV0L3hlbi1uZXRmcm9udC5jOjQ2NSB4ZW5uZXRfc3RhcnRfeG1p
dCsweDdmZS8weDg2MCgpDQpbICAgMzguNzczNTM1XSBNb2R1bGVzIGxpbmtlZCBpbjoNClsg
ICAzOC43NzM1NDJdIFBpZDogMCwgY29tbTogc3dhcHBlci8wIFRhaW50ZWQ6IEcgICAgICAg
IFcgICAgMy42LjBwcmUtcmMxLTIwMTIxMDExICMxDQpbICAgMzguNzczNTQ4XSBDYWxsIFRy
YWNlOg0KWyAgIDM4Ljc3MzU1Ml0gIDxJUlE+ICBbPGZmZmZmZmZmODEwNjY0ZWE+XSB3YXJu
X3Nsb3dwYXRoX2NvbW1vbisweDdhLzB4YjANClsgICAzOC43NzM1NjRdICBbPGZmZmZmZmZm
ODEwNjY1MzU+XSB3YXJuX3Nsb3dwYXRoX251bGwrMHgxNS8weDIwDQpbICAgMzguNzczNTcw
XSAgWzxmZmZmZmZmZjgxNDZkODllPl0geGVubmV0X3N0YXJ0X3htaXQrMHg3ZmUvMHg4NjAN
ClsgICAzOC43NzM1ODJdICBbPGZmZmZmZmZmODE2MWYzNDk+XSBkZXZfaGFyZF9zdGFydF94
bWl0KzB4MjA5LzB4NDYwDQpbICAgMzguNzczNTg5XSAgWzxmZmZmZmZmZjgxNjNiMDM2Pl0g
c2NoX2RpcmVjdF94bWl0KzB4ZjYvMHgyOTANClsgICAzOC43NzM1OTRdICBbPGZmZmZmZmZm
ODE2MWY3NDY+XSBkZXZfcXVldWVfeG1pdCsweDFhNi8weDVhMA0KWyAgIDM4Ljc3MzYwMF0g
IFs8ZmZmZmZmZmY4MTYxZjVhMD5dID8gZGV2X2hhcmRfc3RhcnRfeG1pdCsweDQ2MC8weDQ2
MA0KWyAgIDM4Ljc3MzYwN10gIFs8ZmZmZmZmZmY4MTBiMTQxNz5dID8gbG9ja19yZWxlYXNl
KzB4MTE3LzB4MjUwDQpbICAgMzguNzczNjEzXSAgWzxmZmZmZmZmZjgxNmI5NTM2Pl0gaXBf
ZmluaXNoX291dHB1dCsweDIyNi8weDUzMA0KWyAgIDM4Ljc3MzYxOV0gIFs8ZmZmZmZmZmY4
MTZiOTNkZD5dID8gaXBfZmluaXNoX291dHB1dCsweGNkLzB4NTMwDQpbICAgMzguNzczNjI1
XSAgWzxmZmZmZmZmZjgxNmI5ODk5Pl0gaXBfb3V0cHV0KzB4NTkvMHhlMA0KWyAgIDM4Ljc3
MzYzMV0gIFs8ZmZmZmZmZmY4MTZiODNiOD5dIGlwX2xvY2FsX291dCsweDI4LzB4OTANClsg
ICAzOC43NzM2MzZdICBbPGZmZmZmZmZmODE2Yjg5NmY+XSBpcF9xdWV1ZV94bWl0KzB4MTdm
LzB4NGEwDQpbICAgMzguNzczNjQzXSAgWzxmZmZmZmZmZjgxNmI4N2YwPl0gPyBpcF9zZW5k
X3VuaWNhc3RfcmVwbHkrMHgzNDAvMHgzNDANClsgICAzOC43NzM2NDldICBbPGZmZmZmZmZm
ODEwYTBiYTc+XSA/IGdldG5zdGltZW9mZGF5KzB4NDcvMHhlMA0KWyAgIDM4Ljc3MzY1Nl0g
IFs8ZmZmZmZmZmY4MTYwZjRjOT5dID8gX19za2JfY2xvbmUrMHgyOS8weDEyMA0KWyAgIDM4
Ljc3MzY2Ml0gIFs8ZmZmZmZmZmY4MTZjZWEyMD5dIHRjcF90cmFuc21pdF9za2IrMHg0MDAv
MHg4ZDANClsgICAzOC43NzM2NjhdICBbPGZmZmZmZmZmODE2ZDExMDY+XSB0Y3BfcmV0cmFu
c21pdF9za2IrMHgxYzYvMHg1YTANClsgICAzOC43NzM2NzRdICBbPGZmZmZmZmZmODE2ZDMz
YjA+XSA/IHRjcF93cml0ZV90aW1lcl9oYW5kbGVyKzB4MWEwLzB4MWEwDQpbICAgMzguNzcz
NjgwXSAgWzxmZmZmZmZmZjgxNmQyZjM4Pl0gdGNwX3JldHJhbnNtaXRfdGltZXIrMHgzNTgv
MHg2MzANClsgICAzOC43NzM2ODVdICBbPGZmZmZmZmZmODE2ZDMzNGQ+XSB0Y3Bfd3JpdGVf
dGltZXJfaGFuZGxlcisweDEzZC8weDFhMA0KWyAgIDM4Ljc3MzY5MV0gIFs8ZmZmZmZmZmY4
MTZkMzQyOD5dIHRjcF93cml0ZV90aW1lcisweDc4LzB4ODANClsgICAzOC43NzM2OTddICBb
PGZmZmZmZmZmODEwNzNmN2M+XSBjYWxsX3RpbWVyX2ZuKzB4N2MvMHgxMDANClsgICAzOC43
NzM3MDJdICBbPGZmZmZmZmZmODEwNzNmMDA+XSA/IGNhc2NhZGUrMHhhMC8weGEwDQpbICAg
MzguNzczNzA3XSAgWzxmZmZmZmZmZjgxNmQzM2IwPl0gPyB0Y3Bfd3JpdGVfdGltZXJfaGFu
ZGxlcisweDFhMC8weDFhMA0KWyAgIDM4Ljc3MzcxM10gIFs8ZmZmZmZmZmY4MTZkMzNiMD5d
ID8gdGNwX3dyaXRlX3RpbWVyX2hhbmRsZXIrMHgxYTAvMHgxYTANClsgICAzOC43NzM3MTld
ICBbPGZmZmZmZmZmODEwNzQyMTc+XSBydW5fdGltZXJfc29mdGlycSsweDIxNy8weDI1MA0K
WyAgIDM4Ljc3MzcyNl0gIFs8ZmZmZmZmZmY4MTA2ZTNkOT5dIF9fZG9fc29mdGlycSsweGM5
LzB4MWEwDQpbICAgMzguNzczNzMyXSAgWzxmZmZmZmZmZjgxNzQ4ZDNjPl0gY2FsbF9zb2Z0
aXJxKzB4MWMvMHgzMA0KWyAgIDM4Ljc3MzczOF0gIFs8ZmZmZmZmZmY4MTAwZWRiNT5dIGRv
X3NvZnRpcnErMHg4NS8weGYwDQpbICAgMzguNzczNzQzXSAgWzxmZmZmZmZmZjgxMDZlMjRl
Pl0gaXJxX2V4aXQrMHg5ZS8weGQwDQpbICAgMzguNzczNzUxXSAgWzxmZmZmZmZmZjgxMzM5
ZjVmPl0geGVuX2V2dGNobl9kb191cGNhbGwrMHgyZi8weDQwDQpbICAgMzguNzczNzU2XSAg
WzxmZmZmZmZmZjgxNzQ4ZDllPl0geGVuX2RvX2h5cGVydmlzb3JfY2FsbGJhY2srMHgxZS8w
eDMwDQpbICAgMzguNzczNzYxXSAgPEVPST4gIFs8ZmZmZmZmZmY4MTAwMTNhYT5dID8geGVu
X2h5cGVyY2FsbF9zY2hlZF9vcCsweGEvMHgyMA0KWyAgIDM4Ljc3Mzc3MV0gIFs8ZmZmZmZm
ZmY4MTAwMTNhYT5dID8geGVuX2h5cGVyY2FsbF9zY2hlZF9vcCsweGEvMHgyMA0KWyAgIDM4
Ljc3Mzc3OF0gIFs8ZmZmZmZmZmY4MTAwODY5MD5dID8geGVuX3NhZmVfaGFsdCsweDEwLzB4
MjANClsgICAzOC43NzM3ODRdICBbPGZmZmZmZmZmODEwMTYwZDA+XSA/IGRlZmF1bHRfaWRs
ZSsweDQwLzB4OTANClsgICAzOC43NzM3ODldICBbPGZmZmZmZmZmODEwMTY0ODY+XSA/IGNw
dV9pZGxlKzB4OTYvMHhmMA0KWyAgIDM4Ljc3Mzc5NF0gIFs8ZmZmZmZmZmY4MTcyMmQzYz5d
ID8gcmVzdF9pbml0KzB4YmMvMHhkMA0KWyAgIDM4Ljc3MzgwMF0gIFs8ZmZmZmZmZmY4MTcy
MmM4MD5dID8gY3N1bV9wYXJ0aWFsX2NvcHlfZ2VuZXJpYysweDE3MC8weDE3MA0KWyAgIDM4
Ljc3MzgwN10gIFs8ZmZmZmZmZmY4MWNlMGRmMj5dID8gc3RhcnRfa2VybmVsKzB4MzkwLzB4
MzlkDQpbICAgMzguNzczODEzXSAgWzxmZmZmZmZmZjgxY2UwODgyPl0gPyBrZXJuZWxfaW5p
dCsweDIwYi8weDIwYg0KWyAgIDM4Ljc3MzgxOV0gIFs8ZmZmZmZmZmY4MWNlMDM1Nj5dID8g
eDg2XzY0X3N0YXJ0X3Jlc2VydmF0aW9ucysweDEzMS8weDEzNg0KWyAgIDM4Ljc3MzgyNV0g
IFs8ZmZmZmZmZmY4MWNlM2Q2MD5dID8geGVuX3N0YXJ0X2tlcm5lbCsweDcwZC8weDcwZg0K
WyAgIDM4Ljc3MzgzMV0gLS0tWyBlbmQgdHJhY2UgMmUyOGVlYzkzYjdhOGI3ZSBdLS0tDQpb
ICAgNDMuMzIwMjA3XSAtLS0tLS0tLS0tLS1bIGN1dCBoZXJlIF0tLS0tLS0tLS0tLS0NClsg
ICA0My4zMjAyMzVdIFdBUk5JTkc6IGF0IGRyaXZlcnMvbmV0L3hlbi1uZXRmcm9udC5jOjQ2
NSB4ZW5uZXRfc3RhcnRfeG1pdCsweDdmZS8weDg2MCgpDQpbICAgNDMuMzIwMjQ0XSBNb2R1
bGVzIGxpbmtlZCBpbjoNClsgICA0My4zMjAyNTJdIFBpZDogMCwgY29tbTogc3dhcHBlci8w
IFRhaW50ZWQ6IEcgICAgICAgIFcgICAgMy42LjBwcmUtcmMxLTIwMTIxMDExICMxDQpbICAg
NDMuMzIwMjYxXSBDYWxsIFRyYWNlOg0KWyAgIDQzLjMyMDI2NV0gIDxJUlE+ICBbPGZmZmZm
ZmZmODEwNjY0ZWE+XSB3YXJuX3Nsb3dwYXRoX2NvbW1vbisweDdhLzB4YjANClsgICA0My4z
MjAyODBdICBbPGZmZmZmZmZmODEwNjY1MzU+XSB3YXJuX3Nsb3dwYXRoX251bGwrMHgxNS8w
eDIwDQpbICAgNDMuMzIwMjg4XSAgWzxmZmZmZmZmZjgxNDZkODllPl0geGVubmV0X3N0YXJ0
X3htaXQrMHg3ZmUvMHg4NjANClsgICA0My4zMjAyOThdICBbPGZmZmZmZmZmODE2MWYzNDk+
XSBkZXZfaGFyZF9zdGFydF94bWl0KzB4MjA5LzB4NDYwDQpbICAgNDMuMzIwMzA3XSAgWzxm
ZmZmZmZmZjgxNjNiMDM2Pl0gc2NoX2RpcmVjdF94bWl0KzB4ZjYvMHgyOTANClsgICA0My4z
MjAzMTVdICBbPGZmZmZmZmZmODE2MWY3NDY+XSBkZXZfcXVldWVfeG1pdCsweDFhNi8weDVh
MA0KWyAgIDQzLjMyMDMyM10gIFs8ZmZmZmZmZmY4MTYxZjVhMD5dID8gZGV2X2hhcmRfc3Rh
cnRfeG1pdCsweDQ2MC8weDQ2MA0KWyAgIDQzLjMyMDMzN10gIFs8ZmZmZmZmZmY4MTBiMTQx
Nz5dID8gbG9ja19yZWxlYXNlKzB4MTE3LzB4MjUwDQpbICAgNDMuMzIwMzQ2XSAgWzxmZmZm
ZmZmZjgxNmI5NTM2Pl0gaXBfZmluaXNoX291dHB1dCsweDIyNi8weDUzMA0KWyAgIDQzLjMy
MDM1NF0gIFs8ZmZmZmZmZmY4MTZiOTNkZD5dID8gaXBfZmluaXNoX291dHB1dCsweGNkLzB4
NTMwDQpbICAgNDMuMzIwMzYyXSAgWzxmZmZmZmZmZjgxNmI5ODk5Pl0gaXBfb3V0cHV0KzB4
NTkvMHhlMA0KWyAgIDQzLjMyMDM3MF0gIFs8ZmZmZmZmZmY4MTZiODNiOD5dIGlwX2xvY2Fs
X291dCsweDI4LzB4OTANClsgICA0My4zMjAzNzddICBbPGZmZmZmZmZmODE2Yjg5NmY+XSBp
cF9xdWV1ZV94bWl0KzB4MTdmLzB4NGEwDQpbICAgNDMuMzIwMzg1XSAgWzxmZmZmZmZmZjgx
NmI4N2YwPl0gPyBpcF9zZW5kX3VuaWNhc3RfcmVwbHkrMHgzNDAvMHgzNDANClsgICA0My4z
MjAzOTNdICBbPGZmZmZmZmZmODEwYTBiYTc+XSA/IGdldG5zdGltZW9mZGF5KzB4NDcvMHhl
MA0KWyAgIDQzLjMyMDQwMl0gIFs8ZmZmZmZmZmY4MTYwZjRjOT5dID8gX19za2JfY2xvbmUr
MHgyOS8weDEyMA0KWyAgIDQzLjMyMDQwOV0gIFs8ZmZmZmZmZmY4MTZjZWEyMD5dIHRjcF90
cmFuc21pdF9za2IrMHg0MDAvMHg4ZDANClsgICA0My4zMjA0MTddICBbPGZmZmZmZmZmODE2
ZDExMDY+XSB0Y3BfcmV0cmFuc21pdF9za2IrMHgxYzYvMHg1YTANClsgICA0My4zMjA0MjVd
ICBbPGZmZmZmZmZmODE2ZDMzYjA+XSA/IHRjcF93cml0ZV90aW1lcl9oYW5kbGVyKzB4MWEw
LzB4MWEwDQpbICAgNDMuMzIwNDMzXSAgWzxmZmZmZmZmZjgxNmQyZjM4Pl0gdGNwX3JldHJh
bnNtaXRfdGltZXIrMHgzNTgvMHg2MzANClsgICA0My4zMjA0NDFdICBbPGZmZmZmZmZmODE2
ZDMzNGQ+XSB0Y3Bfd3JpdGVfdGltZXJfaGFuZGxlcisweDEzZC8weDFhMA0KWyAgIDQzLjMy
MDQ0OV0gIFs8ZmZmZmZmZmY4MTZkMzQyOD5dIHRjcF93cml0ZV90aW1lcisweDc4LzB4ODAN
ClsgICA0My4zMjA0NTZdICBbPGZmZmZmZmZmODEwNzNmN2M+XSBjYWxsX3RpbWVyX2ZuKzB4
N2MvMHgxMDANClsgICA0My4zMjA0NjNdICBbPGZmZmZmZmZmODEwNzNmMDA+XSA/IGNhc2Nh
ZGUrMHhhMC8weGEwDQpbICAgNDMuMzIwNDcwXSAgWzxmZmZmZmZmZjgxNmQzM2IwPl0gPyB0
Y3Bfd3JpdGVfdGltZXJfaGFuZGxlcisweDFhMC8weDFhMA0KWyAgIDQzLjMyMDQ3OV0gIFs8
ZmZmZmZmZmY4MTZkMzNiMD5dID8gdGNwX3dyaXRlX3RpbWVyX2hhbmRsZXIrMHgxYTAvMHgx
YTANClsgICA0My4zMjA0ODddICBbPGZmZmZmZmZmODEwNzQyMTc+XSBydW5fdGltZXJfc29m
dGlycSsweDIxNy8weDI1MA0KWyAgIDQzLjMyMDQ5Nl0gIFs8ZmZmZmZmZmY4MTA2ZTNkOT5d
IF9fZG9fc29mdGlycSsweGM5LzB4MWEwDQpbICAgNDMuMzIwNTAzXSAgWzxmZmZmZmZmZjgx
NzQ4ZDNjPl0gY2FsbF9zb2Z0aXJxKzB4MWMvMHgzMA0KWyAgIDQzLjMyMDUxMV0gIFs8ZmZm
ZmZmZmY4MTAwZWRiNT5dIGRvX3NvZnRpcnErMHg4NS8weGYwDQpbICAgNDMuMzIwNTE4XSAg
WzxmZmZmZmZmZjgxMDZlMjRlPl0gaXJxX2V4aXQrMHg5ZS8weGQwDQpbICAgNDMuMzIwNTI4
XSAgWzxmZmZmZmZmZjgxMzM5ZjVmPl0geGVuX2V2dGNobl9kb191cGNhbGwrMHgyZi8weDQw
DQpbICAgNDMuMzIwNTM1XSAgWzxmZmZmZmZmZjgxNzQ4ZDllPl0geGVuX2RvX2h5cGVydmlz
b3JfY2FsbGJhY2srMHgxZS8weDMwDQpbICAgNDMuMzIwNTQyXSAgPEVPST4gIFs8ZmZmZmZm
ZmY4MTAwMTNhYT5dID8geGVuX2h5cGVyY2FsbF9zY2hlZF9vcCsweGEvMHgyMA0KWyAgIDQz
LjMyMDU1NV0gIFs8ZmZmZmZmZmY4MTAwMTNhYT5dID8geGVuX2h5cGVyY2FsbF9zY2hlZF9v
cCsweGEvMHgyMA0KWyAgIDQzLjMyMDU2NF0gIFs8ZmZmZmZmZmY4MTAwODY5MD5dID8geGVu
X3NhZmVfaGFsdCsweDEwLzB4MjANClsgICA0My4zMjA1NzFdICBbPGZmZmZmZmZmODEwMTYw
ZDA+XSA/IGRlZmF1bHRfaWRsZSsweDQwLzB4OTANClsgICA0My4zMjA1NzhdICBbPGZmZmZm
ZmZmODEwMTY0ODY+XSA/IGNwdV9pZGxlKzB4OTYvMHhmMA0KWyAgIDQzLjMyMDU4Nl0gIFs8
ZmZmZmZmZmY4MTcyMmQzYz5dID8gcmVzdF9pbml0KzB4YmMvMHhkMA0KWyAgIDQzLjMyMDU5
Ml0gIFs8ZmZmZmZmZmY4MTcyMmM4MD5dID8gY3N1bV9wYXJ0aWFsX2NvcHlfZ2VuZXJpYysw
eDE3MC8weDE3MA0KWyAgIDQzLjMyMDYwMl0gIFs8ZmZmZmZmZmY4MWNlMGRmMj5dID8gc3Rh
cnRfa2VybmVsKzB4MzkwLzB4MzlkDQpbICAgNDMuMzIwNjEwXSAgWzxmZmZmZmZmZjgxY2Uw
ODgyPl0gPyBrZXJuZWxfaW5pdCsweDIwYi8weDIwYg0KWyAgIDQzLjMyMDYxN10gIFs8ZmZm
ZmZmZmY4MWNlMDM1Nj5dID8geDg2XzY0X3N0YXJ0X3Jlc2VydmF0aW9ucysweDEzMS8weDEz
Ng0KWyAgIDQzLjMyMDYyNl0gIFs8ZmZmZmZmZmY4MWNlM2Q2MD5dID8geGVuX3N0YXJ0X2tl
cm5lbCsweDcwZC8weDcwZg0KWyAgIDQzLjMyMDYzM10gLS0tWyBlbmQgdHJhY2UgMmUyOGVl
YzkzYjdhOGI3ZiBdLS0tDQpbICAgNTIuNDAwMTI2XSAtLS0tLS0tLS0tLS1bIGN1dCBoZXJl
IF0tLS0tLS0tLS0tLS0NClsgICA1Mi40MDAxNDZdIFdBUk5JTkc6IGF0IGRyaXZlcnMvbmV0
L3hlbi1uZXRmcm9udC5jOjQ2NSB4ZW5uZXRfc3RhcnRfeG1pdCsweDdmZS8weDg2MCgpDQpb
ICAgNTIuNDAwMTUyXSBNb2R1bGVzIGxpbmtlZCBpbjoNClsgICA1Mi40MDAxNThdIFBpZDog
MCwgY29tbTogc3dhcHBlci8wIFRhaW50ZWQ6IEcgICAgICAgIFcgICAgMy42LjBwcmUtcmMx
LTIwMTIxMDExICMxDQpbICAgNTIuNDAwMTY0XSBDYWxsIFRyYWNlOg0KWyAgIDUyLjQwMDE2
N10gIDxJUlE+ICBbPGZmZmZmZmZmODEwNjY0ZWE+XSB3YXJuX3Nsb3dwYXRoX2NvbW1vbisw
eDdhLzB4YjANClsgICA1Mi40MDAxNzhdICBbPGZmZmZmZmZmODEwNjY1MzU+XSB3YXJuX3Ns
b3dwYXRoX251bGwrMHgxNS8weDIwDQpbICAgNTIuNDAwMTgzXSAgWzxmZmZmZmZmZjgxNDZk
ODllPl0geGVubmV0X3N0YXJ0X3htaXQrMHg3ZmUvMHg4NjANClsgICA1Mi40MDAxOTFdICBb
PGZmZmZmZmZmODE2MWYzNDk+XSBkZXZfaGFyZF9zdGFydF94bWl0KzB4MjA5LzB4NDYwDQpb
ICAgNTIuNDAwMTk3XSAgWzxmZmZmZmZmZjgxNjNiMDM2Pl0gc2NoX2RpcmVjdF94bWl0KzB4
ZjYvMHgyOTANClsgICA1Mi40MDAyMDJdICBbPGZmZmZmZmZmODE2MWY3NDY+XSBkZXZfcXVl
dWVfeG1pdCsweDFhNi8weDVhMA0KWyAgIDUyLjQwMDIwOF0gIFs8ZmZmZmZmZmY4MTYxZjVh
MD5dID8gZGV2X2hhcmRfc3RhcnRfeG1pdCsweDQ2MC8weDQ2MA0KWyAgIDUyLjQwMDIxNF0g
IFs8ZmZmZmZmZmY4MTBiMTQxNz5dID8gbG9ja19yZWxlYXNlKzB4MTE3LzB4MjUwDQpbICAg
NTIuNDAwMjIxXSAgWzxmZmZmZmZmZjgxNmI5NTM2Pl0gaXBfZmluaXNoX291dHB1dCsweDIy
Ni8weDUzMA0KWyAgIDUyLjQwMDIyNl0gIFs8ZmZmZmZmZmY4MTZiOTNkZD5dID8gaXBfZmlu
aXNoX291dHB1dCsweGNkLzB4NTMwDQpbICAgNTIuNDAwMjMyXSAgWzxmZmZmZmZmZjgxNmI5
ODk5Pl0gaXBfb3V0cHV0KzB4NTkvMHhlMA0KWyAgIDUyLjQwMDIzN10gIFs8ZmZmZmZmZmY4
MTZiODNiOD5dIGlwX2xvY2FsX291dCsweDI4LzB4OTANClsgICA1Mi40MDAyNDJdICBbPGZm
ZmZmZmZmODE2Yjg5NmY+XSBpcF9xdWV1ZV94bWl0KzB4MTdmLzB4NGEwDQpbICAgNTIuNDAw
MjQ3XSAgWzxmZmZmZmZmZjgxNmI4N2YwPl0gPyBpcF9zZW5kX3VuaWNhc3RfcmVwbHkrMHgz
NDAvMHgzNDANClsgICA1Mi40MDAyNTRdICBbPGZmZmZmZmZmODEwYTBiYTc+XSA/IGdldG5z
dGltZW9mZGF5KzB4NDcvMHhlMA0KWyAgIDUyLjQwMDI2MV0gIFs8ZmZmZmZmZmY4MTYwZjRj
OT5dID8gX19za2JfY2xvbmUrMHgyOS8weDEyMA0KWyAgIDUyLjQwMDI2Nl0gIFs8ZmZmZmZm
ZmY4MTZjZWEyMD5dIHRjcF90cmFuc21pdF9za2IrMHg0MDAvMHg4ZDANClsgICA1Mi40MDAy
NzJdICBbPGZmZmZmZmZmODE2ZDExMDY+XSB0Y3BfcmV0cmFuc21pdF9za2IrMHgxYzYvMHg1
YTANClsgICA1Mi40MDAyNzhdICBbPGZmZmZmZmZmODE2ZDMzYjA+XSA/IHRjcF93cml0ZV90
aW1lcl9oYW5kbGVyKzB4MWEwLzB4MWEwDQpbICAgNTIuNDAwMjgzXSAgWzxmZmZmZmZmZjgx
NmQyZjM4Pl0gdGNwX3JldHJhbnNtaXRfdGltZXIrMHgzNTgvMHg2MzANClsgICA1Mi40MDAy
ODhdICBbPGZmZmZmZmZmODE2ZDMzNGQ+XSB0Y3Bfd3JpdGVfdGltZXJfaGFuZGxlcisweDEz
ZC8weDFhMA0KWyAgIDUyLjQwMDI5M10gIFs8ZmZmZmZmZmY4MTZkMzQyOD5dIHRjcF93cml0
ZV90aW1lcisweDc4LzB4ODANClsgICA1Mi40MDAyOTldICBbPGZmZmZmZmZmODEwNzNmN2M+
XSBjYWxsX3RpbWVyX2ZuKzB4N2MvMHgxMDANClsgICA1Mi40MDAzMDNdICBbPGZmZmZmZmZm
ODEwNzNmMDA+XSA/IGNhc2NhZGUrMHhhMC8weGEwDQpbICAgNTIuNDAwMzA4XSAgWzxmZmZm
ZmZmZjgxNmQzM2IwPl0gPyB0Y3Bfd3JpdGVfdGltZXJfaGFuZGxlcisweDFhMC8weDFhMA0K
WyAgIDUyLjQwMDMxM10gIFs8ZmZmZmZmZmY4MTZkMzNiMD5dID8gdGNwX3dyaXRlX3RpbWVy
X2hhbmRsZXIrMHgxYTAvMHgxYTANClsgICA1Mi40MDAzMTldICBbPGZmZmZmZmZmODEwNzQy
MTc+XSBydW5fdGltZXJfc29mdGlycSsweDIxNy8weDI1MA0KWyAgIDUyLjQwMDMyNV0gIFs8
ZmZmZmZmZmY4MTA2ZTNkOT5dIF9fZG9fc29mdGlycSsweGM5LzB4MWEwDQpbICAgNTIuNDAw
MzMwXSAgWzxmZmZmZmZmZjgxNzQ4ZDNjPl0gY2FsbF9zb2Z0aXJxKzB4MWMvMHgzMA0KWyAg
IDUyLjQwMDMzNl0gIFs8ZmZmZmZmZmY4MTAwZWRiNT5dIGRvX3NvZnRpcnErMHg4NS8weGYw
DQpbICAgNTIuNDAwMzQxXSAgWzxmZmZmZmZmZjgxMDZlMjRlPl0gaXJxX2V4aXQrMHg5ZS8w
eGQwDQpbICAgNTIuNDAwMzQ3XSAgWzxmZmZmZmZmZjgxMzM5ZjVmPl0geGVuX2V2dGNobl9k
b191cGNhbGwrMHgyZi8weDQwDQpbICAgNTIuNDAwMzUyXSAgWzxmZmZmZmZmZjgxNzQ4ZDll
Pl0geGVuX2RvX2h5cGVydmlzb3JfY2FsbGJhY2srMHgxZS8weDMwDQpbICAgNTIuNDAwMzU2
XSAgPEVPST4gIFs8ZmZmZmZmZmY4MTAwMTNhYT5dID8geGVuX2h5cGVyY2FsbF9zY2hlZF9v
cCsweGEvMHgyMA0KWyAgIDUyLjQwMDM2Nl0gIFs8ZmZmZmZmZmY4MTAwMTNhYT5dID8geGVu
X2h5cGVyY2FsbF9zY2hlZF9vcCsweGEvMHgyMA0KWyAgIDUyLjQwMDM3MV0gIFs8ZmZmZmZm
ZmY4MTAwODY5MD5dID8geGVuX3NhZmVfaGFsdCsweDEwLzB4MjANClsgICA1Mi40MDAzNzdd
ICBbPGZmZmZmZmZmODEwMTYwZDA+XSA/IGRlZmF1bHRfaWRsZSsweDQwLzB4OTANClsgICA1
Mi40MDAzODJdICBbPGZmZmZmZmZmODEwMTY0ODY+XSA/IGNwdV9pZGxlKzB4OTYvMHhmMA0K
WyAgIDUyLjQwMDM4N10gIFs8ZmZmZmZmZmY4MTcyMmQzYz5dID8gcmVzdF9pbml0KzB4YmMv
MHhkMA0KWyAgIDUyLjQwMDM5MV0gIFs8ZmZmZmZmZmY4MTcyMmM4MD5dID8gY3N1bV9wYXJ0
aWFsX2NvcHlfZ2VuZXJpYysweDE3MC8weDE3MA0KWyAgIDUyLjQwMDM5OF0gIFs8ZmZmZmZm
ZmY4MWNlMGRmMj5dID8gc3RhcnRfa2VybmVsKzB4MzkwLzB4MzlkDQpbICAgNTIuNDAwNDAz
XSAgWzxmZmZmZmZmZjgxY2UwODgyPl0gPyBrZXJuZWxfaW5pdCsweDIwYi8weDIwYg0KWyAg
IDUyLjQwMDQwOF0gIFs8ZmZmZmZmZmY4MWNlMDM1Nj5dID8geDg2XzY0X3N0YXJ0X3Jlc2Vy
dmF0aW9ucysweDEzMS8weDEzNg0KWyAgIDUyLjQwMDQxNF0gIFs8ZmZmZmZmZmY4MWNlM2Q2
MD5dID8geGVuX3N0YXJ0X2tlcm5lbCsweDcwZC8weDcwZg0KWyAgIDUyLjQwMDQyMF0gLS0t
WyBlbmQgdHJhY2UgMmUyOGVlYzkzYjdhOGI4MCBdLS0tDQpbICAgNzAuNTYwMjQyXSAtLS0t
LS0tLS0tLS1bIGN1dCBoZXJlIF0tLS0tLS0tLS0tLS0NClsgICA3MC41NjAzMzJdIFdBUk5J
Tkc6IGF0IGRyaXZlcnMvbmV0L3hlbi1uZXRmcm9udC5jOjQ2NSB4ZW5uZXRfc3RhcnRfeG1p
dCsweDdmZS8weDg2MCgpDQpbICAgNzAuNTYwMzYwXSBNb2R1bGVzIGxpbmtlZCBpbjoNClsg
ICA3MC41NjAzODFdIFBpZDogMCwgY29tbTogc3dhcHBlci8wIFRhaW50ZWQ6IEcgICAgICAg
IFcgICAgMy42LjBwcmUtcmMxLTIwMTIxMDExICMxDQpbICAgNzAuNTYwNDA4XSBDYWxsIFRy
YWNlOg0KWyAgIDcwLjU2MDQyMV0gIDxJUlE+ICBbPGZmZmZmZmZmODEwNjY0ZWE+XSB3YXJu
X3Nsb3dwYXRoX2NvbW1vbisweDdhLzB4YjANClsgICA3MC41NjA0NjJdICBbPGZmZmZmZmZm
ODEwNjY1MzU+XSB3YXJuX3Nsb3dwYXRoX251bGwrMHgxNS8weDIwDQpbICAgNzAuNTYwNDg1
XSAgWzxmZmZmZmZmZjgxNDZkODllPl0geGVubmV0X3N0YXJ0X3htaXQrMHg3ZmUvMHg4NjAN
ClsgICA3MC41NjA1MTJdICBbPGZmZmZmZmZmODE2MWYzNDk+XSBkZXZfaGFyZF9zdGFydF94
bWl0KzB4MjA5LzB4NDYwDQpbICAgNzAuNTYwNTM2XSAgWzxmZmZmZmZmZjgxNjNiMDM2Pl0g
c2NoX2RpcmVjdF94bWl0KzB4ZjYvMHgyOTANClsgICA3MC41NjA1NTldICBbPGZmZmZmZmZm
ODE2MWY3NDY+XSBkZXZfcXVldWVfeG1pdCsweDFhNi8weDVhMA0KWyAgIDcwLjU2MDU4MV0g
IFs8ZmZmZmZmZmY4MTYxZjVhMD5dID8gZGV2X2hhcmRfc3RhcnRfeG1pdCsweDQ2MC8weDQ2
MA0KWyAgIDcwLjU2MDYwNV0gIFs8ZmZmZmZmZmY4MTYyOWE3Nz5dIG5laWdoX3Jlc29sdmVf
b3V0cHV0KzB4MTI3LzB4MjUwDQpbICAgNzAuNTYwNjMwXSAgWzxmZmZmZmZmZjgxNmI5NmFk
Pl0gaXBfZmluaXNoX291dHB1dCsweDM5ZC8weDUzMA0KWyAgIDcwLjU2MDY1M10gIFs8ZmZm
ZmZmZmY4MTZiOTNkZD5dID8gaXBfZmluaXNoX291dHB1dCsweGNkLzB4NTMwDQpbICAgNzAu
NTYwNjc5XSAgWzxmZmZmZmZmZjgxNmI5ODk5Pl0gaXBfb3V0cHV0KzB4NTkvMHhlMA0KWyAg
IDcwLjU2MDcwMV0gIFs8ZmZmZmZmZmY4MTZiODNiOD5dIGlwX2xvY2FsX291dCsweDI4LzB4
OTANClsgICA3MC41NjA3MjJdICBbPGZmZmZmZmZmODE2Yjg5NmY+XSBpcF9xdWV1ZV94bWl0
KzB4MTdmLzB4NGEwDQpbICAgNzAuNTYwNzQ0XSAgWzxmZmZmZmZmZjgxNmI4N2YwPl0gPyBp
cF9zZW5kX3VuaWNhc3RfcmVwbHkrMHgzNDAvMHgzNDANClsgICA3MC41NjA3NjhdICBbPGZm
ZmZmZmZmODEwYTBiYTc+XSA/IGdldG5zdGltZW9mZGF5KzB4NDcvMHhlMA0KWyAgIDcwLjU2
MDc5MV0gIFs8ZmZmZmZmZmY4MTYwZjRjOT5dID8gX19za2JfY2xvbmUrMHgyOS8weDEyMA0K
WyAgIDcwLjU2MDgxMl0gIFs8ZmZmZmZmZmY4MTZjZWEyMD5dIHRjcF90cmFuc21pdF9za2Ir
MHg0MDAvMHg4ZDANClsgICA3MC41NjA4MzVdICBbPGZmZmZmZmZmODE2ZDExMDY+XSB0Y3Bf
cmV0cmFuc21pdF9za2IrMHgxYzYvMHg1YTANClsgICA3MC41NjA4NTldICBbPGZmZmZmZmZm
ODE2ZDMzYjA+XSA/IHRjcF93cml0ZV90aW1lcl9oYW5kbGVyKzB4MWEwLzB4MWEwDQpbICAg
NzAuNTYwODgyXSAgWzxmZmZmZmZmZjgxNmQyZjM4Pl0gdGNwX3JldHJhbnNtaXRfdGltZXIr
MHgzNTgvMHg2MzANClsgICA3MC41NjA5MDVdICBbPGZmZmZmZmZmODE2ZDMzNGQ+XSB0Y3Bf
d3JpdGVfdGltZXJfaGFuZGxlcisweDEzZC8weDFhMA0KWyAgIDcwLjU2MDkyOF0gIFs8ZmZm
ZmZmZmY4MTZkMzQyOD5dIHRjcF93cml0ZV90aW1lcisweDc4LzB4ODANClsgICA3MC41NjA5
NTFdICBbPGZmZmZmZmZmODEwNzNmN2M+XSBjYWxsX3RpbWVyX2ZuKzB4N2MvMHgxMDANClsg
ICA3MC41NjA5NzJdICBbPGZmZmZmZmZmODEwNzNmMDA+XSA/IGNhc2NhZGUrMHhhMC8weGEw
DQpbICAgNzAuNTYwOTkzXSAgWzxmZmZmZmZmZjgxNmQzM2IwPl0gPyB0Y3Bfd3JpdGVfdGlt
ZXJfaGFuZGxlcisweDFhMC8weDFhMA0KWyAgIDcwLjU2MTAxN10gIFs8ZmZmZmZmZmY4MTZk
MzNiMD5dID8gdGNwX3dyaXRlX3RpbWVyX2hhbmRsZXIrMHgxYTAvMHgxYTANClsgICA3MC41
NjEwNDBdICBbPGZmZmZmZmZmODEwNzQyMTc+XSBydW5fdGltZXJfc29mdGlycSsweDIxNy8w
eDI1MA0KWyAgIDcwLjU2MTA2NF0gIFs8ZmZmZmZmZmY4MTA2ZTNkOT5dIF9fZG9fc29mdGly
cSsweGM5LzB4MWEwDQpbICAgNzAuNTYxMDg3XSAgWzxmZmZmZmZmZjgxNzQ4ZDNjPl0gY2Fs
bF9zb2Z0aXJxKzB4MWMvMHgzMA0KWyAgIDcwLjU2MTEwOF0gIFs8ZmZmZmZmZmY4MTAwZWRi
NT5dIGRvX3NvZnRpcnErMHg4NS8weGYwDQpbICAgNzAuNTYxMTMwXSAgWzxmZmZmZmZmZjgx
MDZlMjRlPl0gaXJxX2V4aXQrMHg5ZS8weGQwDQpbICAgNzAuNTYxMTUzXSAgWzxmZmZmZmZm
ZjgxMzM5ZjVmPl0geGVuX2V2dGNobl9kb191cGNhbGwrMHgyZi8weDQwDQpbICAgNzAuNTYx
MTc2XSAgWzxmZmZmZmZmZjgxNzQ4ZDllPl0geGVuX2RvX2h5cGVydmlzb3JfY2FsbGJhY2sr
MHgxZS8weDMwDQpbICAgNzAuNTYxMTk1XSAgPEVPST4gIFs8ZmZmZmZmZmY4MTAwMTNhYT5d
ID8geGVuX2h5cGVyY2FsbF9zY2hlZF9vcCsweGEvMHgyMA0KWyAgIDcwLjU2MTIzMl0gIFs8
ZmZmZmZmZmY4MTAwMTNhYT5dID8geGVuX2h5cGVyY2FsbF9zY2hlZF9vcCsweGEvMHgyMA0K
WyAgIDcwLjU2MTI1Nl0gIFs8ZmZmZmZmZmY4MTAwODY5MD5dID8geGVuX3NhZmVfaGFsdCsw
eDEwLzB4MjANClsgICA3MC41NjEyNzhdICBbPGZmZmZmZmZmODEwMTYwZDA+XSA/IGRlZmF1
bHRfaWRsZSsweDQwLzB4OTANClsgICA3MC41NjEyOTldICBbPGZmZmZmZmZmODEwMTY0ODY+
XSA/IGNwdV9pZGxlKzB4OTYvMHhmMA0KWyAgIDcwLjU2MTMxOV0gIFs8ZmZmZmZmZmY4MTcy
MmQzYz5dID8gcmVzdF9pbml0KzB4YmMvMHhkMA0KWyAgIDcwLjU2MTMzOV0gIFs8ZmZmZmZm
ZmY4MTcyMmM4MD5dID8gY3N1bV9wYXJ0aWFsX2NvcHlfZ2VuZXJpYysweDE3MC8weDE3MA0K
WyAgIDcwLjU2MTM5MF0gIFs8ZmZmZmZmZmY4MWNlMGRmMj5dID8gc3RhcnRfa2VybmVsKzB4
MzkwLzB4MzlkDQpbICAgNzAuNTYxNDE0XSAgWzxmZmZmZmZmZjgxY2UwODgyPl0gPyBrZXJu
ZWxfaW5pdCsweDIwYi8weDIwYg0KWyAgIDcwLjU2MTQzNl0gIFs8ZmZmZmZmZmY4MWNlMDM1
Nj5dID8geDg2XzY0X3N0YXJ0X3Jlc2VydmF0aW9ucysweDEzMS8weDEzNg0KWyAgIDcwLjU2
MTQ2Ml0gIFs8ZmZmZmZmZmY4MWNlM2Q2MD5dID8geGVuX3N0YXJ0X2tlcm5lbCsweDcwZC8w
eDcwZg0KWyAgIDcwLjU2MTQ4M10gLS0tWyBlbmQgdHJhY2UgMmUyOGVlYzkzYjdhOGI4MSBd
LS0tDQpbICAxMDYuOTMzNDIwXSAtLS0tLS0tLS0tLS1bIGN1dCBoZXJlIF0tLS0tLS0tLS0t
LS0NClsgIDEwNi45MzM0NDVdIFdBUk5JTkc6IGF0IGRyaXZlcnMvbmV0L3hlbi1uZXRmcm9u
dC5jOjQ2NSB4ZW5uZXRfc3RhcnRfeG1pdCsweDdmZS8weDg2MCgpDQpbICAxMDYuOTMzNDUy
XSBNb2R1bGVzIGxpbmtlZCBpbjoNClsgIDEwNi45MzM0NThdIFBpZDogMTk1NCwgY29tbTog
Z3ppcCBUYWludGVkOiBHICAgICAgICBXICAgIDMuNi4wcHJlLXJjMS0yMDEyMTAxMSAjMQ0K
WyAgMTA2LjkzMzQ2M10gQ2FsbCBUcmFjZToNClsgIDEwNi45MzM0NjZdICA8SVJRPiAgWzxm
ZmZmZmZmZjgxMDY2NGVhPl0gd2Fybl9zbG93cGF0aF9jb21tb24rMHg3YS8weGIwDQpbICAx
MDYuOTMzNDc2XSAgWzxmZmZmZmZmZjgxMDY2NTM1Pl0gd2Fybl9zbG93cGF0aF9udWxsKzB4
MTUvMHgyMA0KWyAgMTA2LjkzMzQ4Ml0gIFs8ZmZmZmZmZmY4MTQ2ZDg5ZT5dIHhlbm5ldF9z
dGFydF94bWl0KzB4N2ZlLzB4ODYwDQpbICAxMDYuOTMzNDkwXSAgWzxmZmZmZmZmZjgxNjFm
MzQ5Pl0gZGV2X2hhcmRfc3RhcnRfeG1pdCsweDIwOS8weDQ2MA0KWyAgMTA2LjkzMzQ5Nl0g
IFs8ZmZmZmZmZmY4MTYzYjAzNj5dIHNjaF9kaXJlY3RfeG1pdCsweGY2LzB4MjkwDQpbICAx
MDYuOTMzNTAxXSAgWzxmZmZmZmZmZjgxNjFmNzQ2Pl0gZGV2X3F1ZXVlX3htaXQrMHgxYTYv
MHg1YTANClsgIDEwNi45MzM1MDZdICBbPGZmZmZmZmZmODE2MWY1YTA+XSA/IGRldl9oYXJk
X3N0YXJ0X3htaXQrMHg0NjAvMHg0NjANClsgIDEwNi45MzM1MTJdICBbPGZmZmZmZmZmODE2
MjlhNzc+XSBuZWlnaF9yZXNvbHZlX291dHB1dCsweDEyNy8weDI1MA0KWyAgMTA2LjkzMzUx
OV0gIFs8ZmZmZmZmZmY4MTZiOTZhZD5dIGlwX2ZpbmlzaF9vdXRwdXQrMHgzOWQvMHg1MzAN
ClsgIDEwNi45MzM1MjVdICBbPGZmZmZmZmZmODE2YjkzZGQ+XSA/IGlwX2ZpbmlzaF9vdXRw
dXQrMHhjZC8weDUzMA0KWyAgMTA2LjkzMzUzMF0gIFs8ZmZmZmZmZmY4MTZiOTg5OT5dIGlw
X291dHB1dCsweDU5LzB4ZTANClsgIDEwNi45MzM1MzVdICBbPGZmZmZmZmZmODE2YjgzYjg+
XSBpcF9sb2NhbF9vdXQrMHgyOC8weDkwDQpbICAxMDYuOTMzNTQwXSAgWzxmZmZmZmZmZjgx
NmI4OTZmPl0gaXBfcXVldWVfeG1pdCsweDE3Zi8weDRhMA0KWyAgMTA2LjkzMzU0NV0gIFs8
ZmZmZmZmZmY4MTZiODdmMD5dID8gaXBfc2VuZF91bmljYXN0X3JlcGx5KzB4MzQwLzB4MzQw
DQpbICAxMDYuOTMzNTUxXSAgWzxmZmZmZmZmZjgxMGEwYmE3Pl0gPyBnZXRuc3RpbWVvZmRh
eSsweDQ3LzB4ZTANClsgIDEwNi45MzM1NTddICBbPGZmZmZmZmZmODE2MGY0Yzk+XSA/IF9f
c2tiX2Nsb25lKzB4MjkvMHgxMjANClsgIDEwNi45MzM1NjJdICBbPGZmZmZmZmZmODE2Y2Vh
MjA+XSB0Y3BfdHJhbnNtaXRfc2tiKzB4NDAwLzB4OGQwDQpbICAxMDYuOTMzNTY3XSAgWzxm
ZmZmZmZmZjgxNmQxMTA2Pl0gdGNwX3JldHJhbnNtaXRfc2tiKzB4MWM2LzB4NWEwDQpbICAx
MDYuOTMzNTczXSAgWzxmZmZmZmZmZjgxNmQzM2IwPl0gPyB0Y3Bfd3JpdGVfdGltZXJfaGFu
ZGxlcisweDFhMC8weDFhMA0KWyAgMTA2LjkzMzU3OF0gIFs8ZmZmZmZmZmY4MTZkMmYzOD5d
IHRjcF9yZXRyYW5zbWl0X3RpbWVyKzB4MzU4LzB4NjMwDQpbICAxMDYuOTMzNTg0XSAgWzxm
ZmZmZmZmZjgxNmQzMzRkPl0gdGNwX3dyaXRlX3RpbWVyX2hhbmRsZXIrMHgxM2QvMHgxYTAN
ClsgIDEwNi45MzM1OTBdICBbPGZmZmZmZmZmODE2ZDM0Mjg+XSB0Y3Bfd3JpdGVfdGltZXIr
MHg3OC8weDgwDQpbICAxMDYuOTMzNTk1XSAgWzxmZmZmZmZmZjgxMDczZjdjPl0gY2FsbF90
aW1lcl9mbisweDdjLzB4MTAwDQpbICAxMDYuOTMzNjAwXSAgWzxmZmZmZmZmZjgxMDczZjAw
Pl0gPyBjYXNjYWRlKzB4YTAvMHhhMA0KWyAgMTA2LjkzMzYwNF0gIFs8ZmZmZmZmZmY4MTZk
MzNiMD5dID8gdGNwX3dyaXRlX3RpbWVyX2hhbmRsZXIrMHgxYTAvMHgxYTANClsgIDEwNi45
MzM2MTBdICBbPGZmZmZmZmZmODE2ZDMzYjA+XSA/IHRjcF93cml0ZV90aW1lcl9oYW5kbGVy
KzB4MWEwLzB4MWEwDQpbICAxMDYuOTMzNjE1XSAgWzxmZmZmZmZmZjgxMDc0MjE3Pl0gcnVu
X3RpbWVyX3NvZnRpcnErMHgyMTcvMHgyNTANClsgIDEwNi45MzM2MjFdICBbPGZmZmZmZmZm
ODEwNmUzZDk+XSBfX2RvX3NvZnRpcnErMHhjOS8weDFhMA0KWyAgMTA2LjkzMzYyN10gIFs8
ZmZmZmZmZmY4MTc0OGQzYz5dIGNhbGxfc29mdGlycSsweDFjLzB4MzANClsgIDEwNi45MzM2
MzJdICBbPGZmZmZmZmZmODEwMGVkYjU+XSBkb19zb2Z0aXJxKzB4ODUvMHhmMA0KWyAgMTA2
LjkzMzYzN10gIFs8ZmZmZmZmZmY4MTA2ZTI0ZT5dIGlycV9leGl0KzB4OWUvMHhkMA0KWyAg
MTA2LjkzMzY0M10gIFs8ZmZmZmZmZmY4MTMzOWY1Zj5dIHhlbl9ldnRjaG5fZG9fdXBjYWxs
KzB4MmYvMHg0MA0KWyAgMTA2LjkzMzY0OF0gIFs8ZmZmZmZmZmY4MTc0OGQ5ZT5dIHhlbl9k
b19oeXBlcnZpc29yX2NhbGxiYWNrKzB4MWUvMHgzMA0KWyAgMTA2LjkzMzY1M10gIDxFT0k+
IA0KWyAgMTA2LjkzMzY1NV0gLS0tWyBlbmQgdHJhY2UgMmUyOGVlYzkzYjdhOGI4MiBdLS0t
DQpbICAxNzkuNjgwMzE1XSAtLS0tLS0tLS0tLS1bIGN1dCBoZXJlIF0tLS0tLS0tLS0tLS0N
ClsgIDE3OS42ODAzNDRdIFdBUk5JTkc6IGF0IGRyaXZlcnMvbmV0L3hlbi1uZXRmcm9udC5j
OjQ2NSB4ZW5uZXRfc3RhcnRfeG1pdCsweDdmZS8weDg2MCgpDQpbICAxNzkuNjgwMzU3XSBN
b2R1bGVzIGxpbmtlZCBpbjoNClsgIDE3OS42ODAzNjldIFBpZDogMCwgY29tbTogc3dhcHBl
ci8wIFRhaW50ZWQ6IEcgICAgICAgIFcgICAgMy42LjBwcmUtcmMxLTIwMTIxMDExICMxDQpb
ICAxNzkuNjgwMzgxXSBDYWxsIFRyYWNlOg0KWyAgMTc5LjY4MDM4N10gIDxJUlE+ICBbPGZm
ZmZmZmZmODEwNjY0ZWE+XSB3YXJuX3Nsb3dwYXRoX2NvbW1vbisweDdhLzB4YjANClsgIDE3
OS42ODA0MDldICBbPGZmZmZmZmZmODEwNjY1MzU+XSB3YXJuX3Nsb3dwYXRoX251bGwrMHgx
NS8weDIwDQpbICAxNzkuNjgwNDIwXSAgWzxmZmZmZmZmZjgxNDZkODllPl0geGVubmV0X3N0
YXJ0X3htaXQrMHg3ZmUvMHg4NjANClsgIDE3OS42ODA0MzddICBbPGZmZmZmZmZmODE2MWYz
NDk+XSBkZXZfaGFyZF9zdGFydF94bWl0KzB4MjA5LzB4NDYwDQpbICAxNzkuNjgwNDQ5XSAg
WzxmZmZmZmZmZjgxNjNiMDM2Pl0gc2NoX2RpcmVjdF94bWl0KzB4ZjYvMHgyOTANClsgIDE3
OS42ODA0NjFdICBbPGZmZmZmZmZmODE2MWY3NDY+XSBkZXZfcXVldWVfeG1pdCsweDFhNi8w
eDVhMA0KWyAgMTc5LjY4MDQ3Ml0gIFs8ZmZmZmZmZmY4MTYxZjVhMD5dID8gZGV2X2hhcmRf
c3RhcnRfeG1pdCsweDQ2MC8weDQ2MA0KWyAgMTc5LjY4MDQ4NV0gIFs8ZmZmZmZmZmY4MTYy
OWE3Nz5dIG5laWdoX3Jlc29sdmVfb3V0cHV0KzB4MTI3LzB4MjUwDQpbICAxNzkuNjgwNDk4
XSAgWzxmZmZmZmZmZjgxNmI5NmFkPl0gaXBfZmluaXNoX291dHB1dCsweDM5ZC8weDUzMA0K
WyAgMTc5LjY4MDUxMV0gIFs8ZmZmZmZmZmY4MTZiOTNkZD5dID8gaXBfZmluaXNoX291dHB1
dCsweGNkLzB4NTMwDQpbICAxNzkuNjgwNTIzXSAgWzxmZmZmZmZmZjgxNmI5ODk5Pl0gaXBf
b3V0cHV0KzB4NTkvMHhlMA0KWyAgMTc5LjY4MDUzM10gIFs8ZmZmZmZmZmY4MTZiODNiOD5d
IGlwX2xvY2FsX291dCsweDI4LzB4OTANClsgIDE3OS42ODA1NDRdICBbPGZmZmZmZmZmODE2
Yjg5NmY+XSBpcF9xdWV1ZV94bWl0KzB4MTdmLzB4NGEwDQpbICAxNzkuNjgwNTU1XSAgWzxm
ZmZmZmZmZjgxNmI4N2YwPl0gPyBpcF9zZW5kX3VuaWNhc3RfcmVwbHkrMHgzNDAvMHgzNDAN
ClsgIDE3OS42ODA1NjddICBbPGZmZmZmZmZmODEwYTBiYTc+XSA/IGdldG5zdGltZW9mZGF5
KzB4NDcvMHhlMA0KWyAgMTc5LjY4MDU3OV0gIFs8ZmZmZmZmZmY4MTYwZjRjOT5dID8gX19z
a2JfY2xvbmUrMHgyOS8weDEyMA0KWyAgMTc5LjY4MDU5MV0gIFs8ZmZmZmZmZmY4MTZjZWEy
MD5dIHRjcF90cmFuc21pdF9za2IrMHg0MDAvMHg4ZDANClsgIDE3OS42ODA2MDNdICBbPGZm
ZmZmZmZmODE2ZDExMDY+XSB0Y3BfcmV0cmFuc21pdF9za2IrMHgxYzYvMHg1YTANClsgIDE3
OS42ODA2MTVdICBbPGZmZmZmZmZmODE2ZDMzYjA+XSA/IHRjcF93cml0ZV90aW1lcl9oYW5k
bGVyKzB4MWEwLzB4MWEwDQpbICAxNzkuNjgwNjI3XSAgWzxmZmZmZmZmZjgxNmQyZjM4Pl0g
dGNwX3JldHJhbnNtaXRfdGltZXIrMHgzNTgvMHg2MzANClsgIDE3OS42ODA2MzldICBbPGZm
ZmZmZmZmODE2ZDMzNGQ+XSB0Y3Bfd3JpdGVfdGltZXJfaGFuZGxlcisweDEzZC8weDFhMA0K
WyAgMTc5LjY4MDY1MV0gIFs8ZmZmZmZmZmY4MTZkMzQyOD5dIHRjcF93cml0ZV90aW1lcisw
eDc4LzB4ODANClsgIDE3OS42ODA2NjJdICBbPGZmZmZmZmZmODEwNzNmN2M+XSBjYWxsX3Rp
bWVyX2ZuKzB4N2MvMHgxMDANClsgIDE3OS42ODA2NzNdICBbPGZmZmZmZmZmODEwNzNmMDA+
XSA/IGNhc2NhZGUrMHhhMC8weGEwDQpbICAxNzkuNjgwNjgzXSAgWzxmZmZmZmZmZjgxNmQz
M2IwPl0gPyB0Y3Bfd3JpdGVfdGltZXJfaGFuZGxlcisweDFhMC8weDFhMA0KWyAgMTc5LjY4
MDY5Nl0gIFs8ZmZmZmZmZmY4MTZkMzNiMD5dID8gdGNwX3dyaXRlX3RpbWVyX2hhbmRsZXIr
MHgxYTAvMHgxYTANClsgIDE3OS42ODA3MDddICBbPGZmZmZmZmZmODEwNzQyMTc+XSBydW5f
dGltZXJfc29mdGlycSsweDIxNy8weDI1MA0KWyAgMTc5LjY4MDcyMF0gIFs8ZmZmZmZmZmY4
MTA2ZTNkOT5dIF9fZG9fc29mdGlycSsweGM5LzB4MWEwDQpbICAxNzkuNjgwNzMyXSAgWzxm
ZmZmZmZmZjgxNzQ4ZDNjPl0gY2FsbF9zb2Z0aXJxKzB4MWMvMHgzMA0KWyAgMTc5LjY4MDc0
M10gIFs8ZmZmZmZmZmY4MTAwZWRiNT5dIGRvX3NvZnRpcnErMHg4NS8weGYwDQpbICAxNzku
NjgwNzU0XSAgWzxmZmZmZmZmZjgxMDZlMjRlPl0gaXJxX2V4aXQrMHg5ZS8weGQwDQpbICAx
NzkuNjgwNzY2XSAgWzxmZmZmZmZmZjgxMzM5ZjVmPl0geGVuX2V2dGNobl9kb191cGNhbGwr
MHgyZi8weDQwDQpbICAxNzkuNjgwNzc3XSAgWzxmZmZmZmZmZjgxNzQ4ZDllPl0geGVuX2Rv
X2h5cGVydmlzb3JfY2FsbGJhY2srMHgxZS8weDMwDQpbICAxNzkuNjgwNzg2XSAgPEVPST4g
IFs8ZmZmZmZmZmY4MTAwMTNhYT5dID8geGVuX2h5cGVyY2FsbF9zY2hlZF9vcCsweGEvMHgy
MA0KWyAgMTc5LjY4MDgwNl0gIFs8ZmZmZmZmZmY4MTAwMTNhYT5dID8geGVuX2h5cGVyY2Fs
bF9zY2hlZF9vcCsweGEvMHgyMA0KWyAgMTc5LjY4MDgxOF0gIFs8ZmZmZmZmZmY4MTAwODY5
MD5dID8geGVuX3NhZmVfaGFsdCsweDEwLzB4MjANClsgIDE3OS42ODA4MzBdICBbPGZmZmZm
ZmZmODEwMTYwZDA+XSA/IGRlZmF1bHRfaWRsZSsweDQwLzB4OTANClsgIDE3OS42ODA4NDFd
ICBbPGZmZmZmZmZmODEwMTY0ODY+XSA/IGNwdV9pZGxlKzB4OTYvMHhmMA0KWyAgMTc5LjY4
MDg1MV0gIFs8ZmZmZmZmZmY4MTcyMmQzYz5dID8gcmVzdF9pbml0KzB4YmMvMHhkMA0KWyAg
MTc5LjY4MDg2MV0gIFs8ZmZmZmZmZmY4MTcyMmM4MD5dID8gY3N1bV9wYXJ0aWFsX2NvcHlf
Z2VuZXJpYysweDE3MC8weDE3MA0KWyAgMTc5LjY4MDg3NV0gIFs8ZmZmZmZmZmY4MWNlMGRm
Mj5dID8gc3RhcnRfa2VybmVsKzB4MzkwLzB4MzlkDQpbICAxNzkuNjgwODg2XSAgWzxmZmZm
ZmZmZjgxY2UwODgyPl0gPyBrZXJuZWxfaW5pdCsweDIwYi8weDIwYg0KWyAgMTc5LjY4MDg5
OF0gIFs8ZmZmZmZmZmY4MWNlMDM1Nj5dID8geDg2XzY0X3N0YXJ0X3Jlc2VydmF0aW9ucysw
eDEzMS8weDEzNg0KWyAgMTc5LjY4MDkxMV0gIFs8ZmZmZmZmZmY4MWNlM2Q2MD5dID8geGVu
X3N0YXJ0X2tlcm5lbCsweDcwZC8weDcwZg0KWyAgMTc5LjY4MDkyMl0gLS0tWyBlbmQgdHJh
Y2UgMmUyOGVlYzkzYjdhOGI4MyBdLS0tDQpbICAxOTkuMzAyMjM5XSB0dHlfaW5pdF9kZXY6
IDE5IGNhbGxiYWNrcyBzdXBwcmVzc2VkDQpbICAzMDAuMTQ4MTcxXSAtLS0tLS0tLS0tLS1b
IGN1dCBoZXJlIF0tLS0tLS0tLS0tLS0NClsgIDMwMC4xNDgyMjZdIFdBUk5JTkc6IGF0IGRy
aXZlcnMvbmV0L3hlbi1uZXRmcm9udC5jOjQ2NSB4ZW5uZXRfc3RhcnRfeG1pdCsweDdmZS8w
eDg2MCgpDQpbICAzMDAuMTQ4MjU1XSBNb2R1bGVzIGxpbmtlZCBpbjoNClsgIDMwMC4xNDgy
NzhdIFBpZDogMCwgY29tbTogc3dhcHBlci8wIFRhaW50ZWQ6IEcgICAgICAgIFcgICAgMy42
LjBwcmUtcmMxLTIwMTIxMDExICMxDQpbICAzMDAuMTQ4MzA0XSBDYWxsIFRyYWNlOg0KWyAg
MzAwLjE0ODMxOF0gIDxJUlE+ICBbPGZmZmZmZmZmODEwNjY0ZWE+XSB3YXJuX3Nsb3dwYXRo
X2NvbW1vbisweDdhLzB4YjANClsgIDMwMC4xNDgzNjJdICBbPGZmZmZmZmZmODEwNjY1MzU+
XSB3YXJuX3Nsb3dwYXRoX251bGwrMHgxNS8weDIwDQpbICAzMDAuMTQ4Mzg2XSAgWzxmZmZm
ZmZmZjgxNDZkODllPl0geGVubmV0X3N0YXJ0X3htaXQrMHg3ZmUvMHg4NjANClsgIDMwMC4x
NDg0MTVdICBbPGZmZmZmZmZmODE2MWYzNDk+XSBkZXZfaGFyZF9zdGFydF94bWl0KzB4MjA5
LzB4NDYwDQpbICAzMDAuMTQ4NDQxXSAgWzxmZmZmZmZmZjgxNjNiMDM2Pl0gc2NoX2RpcmVj
dF94bWl0KzB4ZjYvMHgyOTANClsgIDMwMC4xNDg0NjRdICBbPGZmZmZmZmZmODE2MWY3NDY+
XSBkZXZfcXVldWVfeG1pdCsweDFhNi8weDVhMA0KWyAgMzAwLjE0ODQ4OF0gIFs8ZmZmZmZm
ZmY4MTYxZjVhMD5dID8gZGV2X2hhcmRfc3RhcnRfeG1pdCsweDQ2MC8weDQ2MA0KWyAgMzAw
LjE0ODUxNF0gIFs8ZmZmZmZmZmY4MTBhZDIyZD5dID8gdHJhY2VfaGFyZGlycXNfb24rMHhk
LzB4MTANClsgIDMwMC4xNDg1MzldICBbPGZmZmZmZmZmODE2MjlhNzc+XSBuZWlnaF9yZXNv
bHZlX291dHB1dCsweDEyNy8weDI1MA0KWyAgMzAwLjE0ODU2NV0gIFs8ZmZmZmZmZmY4MTZh
ZDFiZT5dID8gaXB2NF9uZWlnaF9sb29rdXArMHgzZS8weDE1MA0KWyAgMzAwLjE0ODU4OF0g
IFs8ZmZmZmZmZmY4MTYyYWQzNz5dIG5laWdoX3VwZGF0ZSsweDI5Ny8weDVlMA0KWyAgMzAw
LjE0ODYxMF0gIFs8ZmZmZmZmZmY4MTYyYWRjMj5dID8gbmVpZ2hfdXBkYXRlKzB4MzIyLzB4
NWUwDQpbICAzMDAuMTQ4NjMzXSAgWzxmZmZmZmZmZjgxMGFkMjJkPl0gPyB0cmFjZV9oYXJk
aXJxc19vbisweGQvMHgxMA0KWyAgMzAwLjE0ODY2MV0gIFs8ZmZmZmZmZmY4MTA2ZTc1Nj5d
ID8gbG9jYWxfYmhfZW5hYmxlKzB4YzYvMHgxNjANClsgIDMwMC4xNDg3MDJdICBbPGZmZmZm
ZmZmODE2ZTJmNTU+XSBhcnBfcHJvY2VzcysweDJlNS8weDcwMA0KWyAgMzAwLjE0ODcyNV0g
IFs8ZmZmZmZmZmY4MTBhZDM0NT5dID8gZGVidWdfY2hlY2tfbm9fbG9ja3NfZnJlZWQrMHgx
MTUvMHgxZDANClsgIDMwMC4xNDg3NTFdICBbPGZmZmZmZmZmODE2ZTM0NDU+XSBhcnBfcmN2
KzB4ZDUvMHgxNDANClsgIDMwMC4xNDg3NzNdICBbPGZmZmZmZmZmODE2MWFjOGQ+XSBfX25l
dGlmX3JlY2VpdmVfc2tiKzB4NjVkLzB4OGQwDQpbICAzMDAuMTQ4Nzk2XSAgWzxmZmZmZmZm
ZjgxNjFhNzc1Pl0gPyBfX25ldGlmX3JlY2VpdmVfc2tiKzB4MTQ1LzB4OGQwDQpbICAzMDAu
MTQ4ODIwXSAgWzxmZmZmZmZmZjgxMGFkMjJkPl0gPyB0cmFjZV9oYXJkaXJxc19vbisweGQv
MHgxMA0KWyAgMzAwLjE0ODg0NV0gIFs8ZmZmZmZmZmY4MTBmOTk3Mz5dID8gZnJlZV9ob3Rf
Y29sZF9wYWdlKzB4MWIzLzB4MWUwDQpbICAzMDAuMTQ4ODcwXSAgWzxmZmZmZmZmZjgxNjFk
MWY4Pl0gbmV0aWZfcmVjZWl2ZV9za2IrMHgyOC8weGYwDQpbICAzMDAuMTQ4ODk2XSAgWzxm
ZmZmZmZmZjgxNjEyZDAzPl0gPyBfX3Bza2JfcHVsbF90YWlsKzB4MjUzLzB4MzQwDQpbICAz
MDAuMTQ4OTIwXSAgWzxmZmZmZmZmZjgxNDZlNGM1Pl0geGVubmV0X3BvbGwrMHhhZDUvMHhl
MTANClsgIDMwMC4xNDg5NDddICBbPGZmZmZmZmZmODE2MWRmYTY+XSBuZXRfcnhfYWN0aW9u
KzB4MTM2LzB4MjYwDQpbICAzMDAuMTQ4OTcxXSAgWzxmZmZmZmZmZjgxMDZlMzgxPl0gPyBf
X2RvX3NvZnRpcnErMHg3MS8weDFhMA0KWyAgMzAwLjE0ODk5NV0gIFs8ZmZmZmZmZmY4MTA2
ZTNkOT5dIF9fZG9fc29mdGlycSsweGM5LzB4MWEwDQpbICAzMDAuMTQ5MDE5XSAgWzxmZmZm
ZmZmZjgxNzQ4ZDNjPl0gY2FsbF9zb2Z0aXJxKzB4MWMvMHgzMA0KWyAgMzAwLjE0OTA0Ml0g
IFs8ZmZmZmZmZmY4MTAwZWRiNT5dIGRvX3NvZnRpcnErMHg4NS8weGYwDQpbICAzMDAuMTQ5
MDY0XSAgWzxmZmZmZmZmZjgxMDZlMjRlPl0gaXJxX2V4aXQrMHg5ZS8weGQwDQpbICAzMDAu
MTQ5MDg5XSAgWzxmZmZmZmZmZjgxMzM5ZjVmPl0geGVuX2V2dGNobl9kb191cGNhbGwrMHgy
Zi8weDQwDQpbICAzMDAuMTQ5MTEzXSAgWzxmZmZmZmZmZjgxNzQ4ZDllPl0geGVuX2RvX2h5
cGVydmlzb3JfY2FsbGJhY2srMHgxZS8weDMwDQpbICAzMDAuMTQ5MTMzXSAgPEVPST4gIFs8
ZmZmZmZmZmY4MTAwMTNhYT5dID8geGVuX2h5cGVyY2FsbF9zY2hlZF9vcCsweGEvMHgyMA0K
WyAgMzAwLjE0OTE3Ml0gIFs8ZmZmZmZmZmY4MTAwMTNhYT5dID8geGVuX2h5cGVyY2FsbF9z
Y2hlZF9vcCsweGEvMHgyMA0KWyAgMzAwLjE0OTE5OF0gIFs8ZmZmZmZmZmY4MTAwODY5MD5d
ID8geGVuX3NhZmVfaGFsdCsweDEwLzB4MjANClsgIDMwMC4xNDkyMjJdICBbPGZmZmZmZmZm
ODEwMTYwZDA+XSA/IGRlZmF1bHRfaWRsZSsweDQwLzB4OTANClsgIDMwMC4xNDkyNDVdICBb
PGZmZmZmZmZmODEwMTY0ODY+XSA/IGNwdV9pZGxlKzB4OTYvMHhmMA0KWyAgMzAwLjE0OTI2
N10gIFs8ZmZmZmZmZmY4MTcyMmQzYz5dID8gcmVzdF9pbml0KzB4YmMvMHhkMA0KWyAgMzAw
LjE0OTI4OF0gIFs8ZmZmZmZmZmY4MTcyMmM4MD5dID8gY3N1bV9wYXJ0aWFsX2NvcHlfZ2Vu
ZXJpYysweDE3MC8weDE3MA0KWyAgMzAwLjE0OTMxNl0gIFs8ZmZmZmZmZmY4MWNlMGRmMj5d
ID8gc3RhcnRfa2VybmVsKzB4MzkwLzB4MzlkDQpbICAzMDAuMTQ5MzQwXSAgWzxmZmZmZmZm
ZjgxY2UwODgyPl0gPyBrZXJuZWxfaW5pdCsweDIwYi8weDIwYg0KWyAgMzAwLjE0OTM2NF0g
IFs8ZmZmZmZmZmY4MWNlMDM1Nj5dID8geDg2XzY0X3N0YXJ0X3Jlc2VydmF0aW9ucysweDEz
MS8weDEzNg0KWyAgMzAwLjE0OTM5MV0gIFs8ZmZmZmZmZmY4MWNlM2Q2MD5dID8geGVuX3N0
YXJ0X2tlcm5lbCsweDcwZC8weDcwZg0KWyAgMzAwLjE0OTQxM10gLS0tWyBlbmQgdHJhY2Ug
MmUyOGVlYzkzYjdhOGI4NCBdLS0tDQpbICAzMTIuNTkxMTMyXSAtLS0tLS0tLS0tLS1bIGN1
dCBoZXJlIF0tLS0tLS0tLS0tLS0NClsgIDMxMi41OTExNjRdIFdBUk5JTkc6IGF0IGRyaXZl
cnMvbmV0L3hlbi1uZXRmcm9udC5jOjQ2NSB4ZW5uZXRfc3RhcnRfeG1pdCsweDdmZS8weDg2
MCgpDQpbICAzMTIuNTkxMTcxXSBNb2R1bGVzIGxpbmtlZCBpbjoNClsgIDMxMi41OTExNzdd
IFBpZDogMjE1OSwgY29tbTogc3NoZCBUYWludGVkOiBHICAgICAgICBXICAgIDMuNi4wcHJl
LXJjMS0yMDEyMTAxMSAjMQ0KWyAgMzEyLjU5MTE4M10gQ2FsbCBUcmFjZToNClsgIDMxMi41
OTExOTFdICBbPGZmZmZmZmZmODEwNjY0ZWE+XSB3YXJuX3Nsb3dwYXRoX2NvbW1vbisweDdh
LzB4YjANClsgIDMxMi41OTEyMTNdICBbPGZmZmZmZmZmODEwNjY1MzU+XSB3YXJuX3Nsb3dw
YXRoX251bGwrMHgxNS8weDIwDQpbICAzMTIuNTkxMjE5XSAgWzxmZmZmZmZmZjgxNDZkODll
Pl0geGVubmV0X3N0YXJ0X3htaXQrMHg3ZmUvMHg4NjANClsgIDMxMi41OTEyMjZdICBbPGZm
ZmZmZmZmODE2MWYzNDk+XSBkZXZfaGFyZF9zdGFydF94bWl0KzB4MjA5LzB4NDYwDQpbICAz
MTIuNTkxMjMzXSAgWzxmZmZmZmZmZjgxNjNiMDM2Pl0gc2NoX2RpcmVjdF94bWl0KzB4ZjYv
MHgyOTANClsgIDMxMi41OTEyMzldICBbPGZmZmZmZmZmODE2MWY3NDY+XSBkZXZfcXVldWVf
eG1pdCsweDFhNi8weDVhMA0KWyAgMzEyLjU5MTI0NF0gIFs8ZmZmZmZmZmY4MTYxZjVhMD5d
ID8gZGV2X2hhcmRfc3RhcnRfeG1pdCsweDQ2MC8weDQ2MA0KWyAgMzEyLjU5MTI1MV0gIFs8
ZmZmZmZmZmY4MTBhYThlNT5dID8gdHJhY2Vfc29mdGlycXNfb2ZmKzB4ODUvMHgxYjANClsg
IDMxMi41OTEyNTldICBbPGZmZmZmZmZmODE2Yjk1MzY+XSBpcF9maW5pc2hfb3V0cHV0KzB4
MjI2LzB4NTMwDQpbICAzMTIuNTkxMjY0XSAgWzxmZmZmZmZmZjgxNmI5M2RkPl0gPyBpcF9m
aW5pc2hfb3V0cHV0KzB4Y2QvMHg1MzANClsgIDMxMi41OTEyNzBdICBbPGZmZmZmZmZmODE2
Yjk4OTk+XSBpcF9vdXRwdXQrMHg1OS8weGUwDQpbICAzMTIuNTkxMjc2XSAgWzxmZmZmZmZm
ZjgxNmI4M2I4Pl0gaXBfbG9jYWxfb3V0KzB4MjgvMHg5MA0KWyAgMzEyLjU5MTI4MV0gIFs8
ZmZmZmZmZmY4MTZiODk2Zj5dIGlwX3F1ZXVlX3htaXQrMHgxN2YvMHg0YTANClsgIDMxMi41
OTEyODZdICBbPGZmZmZmZmZmODE2Yjg3ZjA+XSA/IGlwX3NlbmRfdW5pY2FzdF9yZXBseSsw
eDM0MC8weDM0MA0KWyAgMzEyLjU5MTI5M10gIFs8ZmZmZmZmZmY4MTBhMGJhNz5dID8gZ2V0
bnN0aW1lb2ZkYXkrMHg0Ny8weGUwDQpbICAzMTIuNTkxMjk5XSAgWzxmZmZmZmZmZjgxNjBm
NGM5Pl0gPyBfX3NrYl9jbG9uZSsweDI5LzB4MTIwDQpbICAzMTIuNTkxMzA2XSAgWzxmZmZm
ZmZmZjgxNmNlYTIwPl0gdGNwX3RyYW5zbWl0X3NrYisweDQwMC8weDhkMA0KWyAgMzEyLjU5
MTMxMl0gIFs8ZmZmZmZmZmY4MTZkMTlmYT5dIHRjcF93cml0ZV94bWl0KzB4MjFhLzB4YTUw
DQpbICAzMTIuNTkxMzE3XSAgWzxmZmZmZmZmZjgxNmQyMjViPl0gdGNwX3B1c2hfb25lKzB4
MmIvMHg0MA0KWyAgMzEyLjU5MTMyNF0gIFs8ZmZmZmZmZmY4MTZjMmRlYz5dIHRjcF9zZW5k
bXNnKzB4OGRjLzB4ZTIwDQpbICAzMTIuNTkxMzMxXSAgWzxmZmZmZmZmZjgxNmU4ZjE5Pl0g
aW5ldF9zZW5kbXNnKzB4YTkvMHgxMDANClsgIDMxMi41OTEzMzZdICBbPGZmZmZmZmZmODE2
ZThlNzA+XSA/IGluZXRfYXV0b2JpbmQrMHg3MC8weDcwDQpbICAzMTIuNTkxMzQyXSAgWzxm
ZmZmZmZmZjgxMGIwZjg4Pl0gPyBsb2NrX2FjcXVpcmUrMHhkOC8weDEwMA0KWyAgMzEyLjU5
MTM0OV0gIFs8ZmZmZmZmZmY4MTYwNjMwZD5dIHNvY2tfYWlvX3dyaXRlKzB4MTJkLzB4MTQw
DQpbICAzMTIuNTkxMzU2XSAgWzxmZmZmZmZmZjgxMTQzNWIyPl0gZG9fc3luY193cml0ZSsw
eGEyLzB4ZTANClsgIDMxMi41OTEzNjVdICBbPGZmZmZmZmZmODEwYWQyMmQ+XSA/IHRyYWNl
X2hhcmRpcnFzX29uKzB4ZC8weDEwDQpbICAzMTIuNTkxMzcxXSAgWzxmZmZmZmZmZjgxMTQ0
MWQ0Pl0gdmZzX3dyaXRlKzB4MTc0LzB4MTkwDQpbICAzMTIuNTkxMzc2XSAgWzxmZmZmZmZm
ZjgxMTQ0MmZhPl0gc3lzX3dyaXRlKzB4NWEvMHhhMA0KWyAgMzEyLjU5MTM4M10gIFs8ZmZm
ZmZmZmY4MTJiMzNkZT5dID8gdHJhY2VfaGFyZGlycXNfb25fdGh1bmsrMHgzYS8weDNmDQpb
ICAzMTIuNTkxMzkxXSAgWzxmZmZmZmZmZjgxNzQ5MWNjPl0gY3N0YXJfZGlzcGF0Y2grMHg3
LzB4MjYNClsgIDMxMi41OTEzOTZdIC0tLVsgZW5kIHRyYWNlIDJlMjhlZWM5M2I3YThiODUg
XS0tLQ0KWyAgMzEyLjU5MTQyOV0gLS0tLS0tLS0tLS0tWyBjdXQgaGVyZSBdLS0tLS0tLS0t
LS0tDQpbICAzMTIuNTkxNDM1XSBXQVJOSU5HOiBhdCBkcml2ZXJzL25ldC94ZW4tbmV0ZnJv
bnQuYzo0NjUgeGVubmV0X3N0YXJ0X3htaXQrMHg3ZmUvMHg4NjAoKQ0KWyAgMzEyLjU5MTQ0
MV0gTW9kdWxlcyBsaW5rZWQgaW46DQpbICAzMTIuNTkxNDQ1XSBQaWQ6IDIxNTksIGNvbW06
IHNzaGQgVGFpbnRlZDogRyAgICAgICAgVyAgICAzLjYuMHByZS1yYzEtMjAxMjEwMTEgIzEN
ClsgIDMxMi41OTE0NTFdIENhbGwgVHJhY2U6DQpbICAzMTIuNTkxNDU3XSAgWzxmZmZmZmZm
ZjgxMDY2NGVhPl0gd2Fybl9zbG93cGF0aF9jb21tb24rMHg3YS8weGIwDQpbICAzMTIuNTkx
NDYzXSAgWzxmZmZmZmZmZjgxMDY2NTM1Pl0gd2Fybl9zbG93cGF0aF9udWxsKzB4MTUvMHgy
MA0KWyAgMzEyLjU5MTQ2OF0gIFs8ZmZmZmZmZmY4MTQ2ZDg5ZT5dIHhlbm5ldF9zdGFydF94
bWl0KzB4N2ZlLzB4ODYwDQpbICAzMTIuNTkxNDc1XSAgWzxmZmZmZmZmZjgxNjFmMzQ5Pl0g
ZGV2X2hhcmRfc3RhcnRfeG1pdCsweDIwOS8weDQ2MA0KWyAgMzEyLjU5MTQ4MV0gIFs8ZmZm
ZmZmZmY4MTYzYjAzNj5dIHNjaF9kaXJlY3RfeG1pdCsweGY2LzB4MjkwDQpbICAzMTIuNTkx
NDg3XSAgWzxmZmZmZmZmZjgxNjFmNzQ2Pl0gZGV2X3F1ZXVlX3htaXQrMHgxYTYvMHg1YTAN
ClsgIDMxMi41OTE0OTJdICBbPGZmZmZmZmZmODE2MWY1YTA+XSA/IGRldl9oYXJkX3N0YXJ0
X3htaXQrMHg0NjAvMHg0NjANClsgIDMxMi41OTE0OThdICBbPGZmZmZmZmZmODEwYWE4ZTU+
XSA/IHRyYWNlX3NvZnRpcnFzX29mZisweDg1LzB4MWIwDQpbICAzMTIuNTkxNTA0XSAgWzxm
ZmZmZmZmZjgxNmI5NTM2Pl0gaXBfZmluaXNoX291dHB1dCsweDIyNi8weDUzMA0KWyAgMzEy
LjU5MTUxMF0gIFs8ZmZmZmZmZmY4MTZiOTNkZD5dID8gaXBfZmluaXNoX291dHB1dCsweGNk
LzB4NTMwDQpbICAzMTIuNTkxNTE2XSAgWzxmZmZmZmZmZjgxNmI5ODk5Pl0gaXBfb3V0cHV0
KzB4NTkvMHhlMA0KWyAgMzEyLjU5MTUyMV0gIFs8ZmZmZmZmZmY4MTZiODNiOD5dIGlwX2xv
Y2FsX291dCsweDI4LzB4OTANClsgIDMxMi41OTE1MjZdICBbPGZmZmZmZmZmODE2Yjg5NmY+
XSBpcF9xdWV1ZV94bWl0KzB4MTdmLzB4NGEwDQpbICAzMTIuNTkxNTMyXSAgWzxmZmZmZmZm
ZjgxNmI4N2YwPl0gPyBpcF9zZW5kX3VuaWNhc3RfcmVwbHkrMHgzNDAvMHgzNDANClsgIDMx
Mi41OTE1MzhdICBbPGZmZmZmZmZmODEwYTBiYTc+XSA/IGdldG5zdGltZW9mZGF5KzB4NDcv
MHhlMA0KWyAgMzEyLjU5MTU0NF0gIFs8ZmZmZmZmZmY4MTYwZjRjOT5dID8gX19za2JfY2xv
bmUrMHgyOS8weDEyMA0KWyAgMzEyLjU5MTU0OV0gIFs8ZmZmZmZmZmY4MTZjZWEyMD5dIHRj
cF90cmFuc21pdF9za2IrMHg0MDAvMHg4ZDANClsgIDMxMi41OTE1NTVdICBbPGZmZmZmZmZm
ODE2ZDE5ZmE+XSB0Y3Bfd3JpdGVfeG1pdCsweDIxYS8weGE1MA0KWyAgMzEyLjU5MTU2MF0g
IFs8ZmZmZmZmZmY4MTZkMjI5ZD5dIF9fdGNwX3B1c2hfcGVuZGluZ19mcmFtZXMrMHgyZC8w
eDkwDQpbICAzMTIuNTkxNTY2XSAgWzxmZmZmZmZmZjgxNmMyNjkzPl0gdGNwX3NlbmRtc2cr
MHgxODMvMHhlMjANClsgIDMxMi41OTE1NzJdICBbPGZmZmZmZmZmODE2ZThmMTk+XSBpbmV0
X3NlbmRtc2crMHhhOS8weDEwMA0KWyAgMzEyLjU5MTU3OF0gIFs8ZmZmZmZmZmY4MTZlOGU3
MD5dID8gaW5ldF9hdXRvYmluZCsweDcwLzB4NzANClsgIDMxMi41OTE1ODNdICBbPGZmZmZm
ZmZmODEwYjBmODg+XSA/IGxvY2tfYWNxdWlyZSsweGQ4LzB4MTAwDQpbICAzMTIuNTkxNTg4
XSAgWzxmZmZmZmZmZjgxNjA2MzBkPl0gc29ja19haW9fd3JpdGUrMHgxMmQvMHgxNDANClsg
IDMxMi41OTE1OTRdICBbPGZmZmZmZmZmODExNDM1YjI+XSBkb19zeW5jX3dyaXRlKzB4YTIv
MHhlMA0KWyAgMzEyLjU5MTYwMF0gIFs8ZmZmZmZmZmY4MTBhZDIyZD5dID8gdHJhY2VfaGFy
ZGlycXNfb24rMHhkLzB4MTANClsgIDMxMi41OTE2MDZdICBbPGZmZmZmZmZmODExNDQxZDQ+
XSB2ZnNfd3JpdGUrMHgxNzQvMHgxOTANClsgIDMxMi41OTE2MTFdICBbPGZmZmZmZmZmODEx
NDQyZmE+XSBzeXNfd3JpdGUrMHg1YS8weGEwDQpbICAzMTIuNTkxNjE3XSAgWzxmZmZmZmZm
ZjgxMmIzM2RlPl0gPyB0cmFjZV9oYXJkaXJxc19vbl90aHVuaysweDNhLzB4M2YNClsgIDMx
Mi41OTE2MjNdICBbPGZmZmZmZmZmODE3NDkxY2M+XSBjc3Rhcl9kaXNwYXRjaCsweDcvMHgy
Ng0KWyAgMzEyLjU5MTYyN10gLS0tWyBlbmQgdHJhY2UgMmUyOGVlYzkzYjdhOGI4NiBdLS0t
DQpbICAzMTIuNTkxNjQ1XSAtLS0tLS0tLS0tLS1bIGN1dCBoZXJlIF0tLS0tLS0tLS0tLS0N
ClsgIDMxMi41OTE2NTFdIFdBUk5JTkc6IGF0IGRyaXZlcnMvbmV0L3hlbi1uZXRmcm9udC5j
OjQ2NSB4ZW5uZXRfc3RhcnRfeG1pdCsweDdmZS8weDg2MCgpDQpbICAzMTIuNTkxNjU3XSBN
b2R1bGVzIGxpbmtlZCBpbjoNClsgIDMxMi41OTE2NjJdIFBpZDogMjE1OSwgY29tbTogc3No
ZCBUYWludGVkOiBHICAgICAgICBXICAgIDMuNi4wcHJlLXJjMS0yMDEyMTAxMSAjMQ0KWyAg
MzEyLjU5MTY2N10gQ2FsbCBUcmFjZToNClsgIDMxMi41OTE2NzFdICBbPGZmZmZmZmZmODEw
NjY0ZWE+XSB3YXJuX3Nsb3dwYXRoX2NvbW1vbisweDdhLzB4YjANClsgIDMxMi41OTE2Nzdd
ICBbPGZmZmZmZmZmODEwNjY1MzU+XSB3YXJuX3Nsb3dwYXRoX251bGwrMHgxNS8weDIwDQpb
ICAzMTIuNTkxNjgyXSAgWzxmZmZmZmZmZjgxNDZkODllPl0geGVubmV0X3N0YXJ0X3htaXQr
MHg3ZmUvMHg4NjANClsgIDMxMi41OTE2ODhdICBbPGZmZmZmZmZmODE2MWYzNDk+XSBkZXZf
aGFyZF9zdGFydF94bWl0KzB4MjA5LzB4NDYwDQpbICAzMTIuNTkxNjk0XSAgWzxmZmZmZmZm
ZjgxNjNiMDM2Pl0gc2NoX2RpcmVjdF94bWl0KzB4ZjYvMHgyOTANClsgIDMxMi41OTE3MDBd
ICBbPGZmZmZmZmZmODE2MWY3NDY+XSBkZXZfcXVldWVfeG1pdCsweDFhNi8weDVhMA0KWyAg
MzEyLjU5MTcwNV0gIFs8ZmZmZmZmZmY4MTYxZjVhMD5dID8gZGV2X2hhcmRfc3RhcnRfeG1p
dCsweDQ2MC8weDQ2MA0KWyAgMzEyLjU5MTcxMV0gIFs8ZmZmZmZmZmY4MTBhYThlNT5dID8g
dHJhY2Vfc29mdGlycXNfb2ZmKzB4ODUvMHgxYjANClsgIDMxMi41OTE3MTddICBbPGZmZmZm
ZmZmODE2Yjk1MzY+XSBpcF9maW5pc2hfb3V0cHV0KzB4MjI2LzB4NTMwDQpbICAzMTIuNTkx
NzI2XSAgWzxmZmZmZmZmZjgxNmI5M2RkPl0gPyBpcF9maW5pc2hfb3V0cHV0KzB4Y2QvMHg1
MzANClsgIDMxMi41OTE3MzJdICBbPGZmZmZmZmZmODE2Yjk4OTk+XSBpcF9vdXRwdXQrMHg1
OS8weGUwDQpbICAzMTIuNTkxNzM3XSAgWzxmZmZmZmZmZjgxNmI4M2I4Pl0gaXBfbG9jYWxf
b3V0KzB4MjgvMHg5MA0KWyAgMzEyLjU5MTc0M10gIFs8ZmZmZmZmZmY4MTZiODk2Zj5dIGlw
X3F1ZXVlX3htaXQrMHgxN2YvMHg0YTANClsgIDMxMi41OTE3NDhdICBbPGZmZmZmZmZmODE2
Yjg3ZjA+XSA/IGlwX3NlbmRfdW5pY2FzdF9yZXBseSsweDM0MC8weDM0MA0KWyAgMzEyLjU5
MTc1NF0gIFs8ZmZmZmZmZmY4MTBhMGJhNz5dID8gZ2V0bnN0aW1lb2ZkYXkrMHg0Ny8weGUw
DQpbICAzMTIuNTkxNzU5XSAgWzxmZmZmZmZmZjgxNjBmNGM5Pl0gPyBfX3NrYl9jbG9uZSsw
eDI5LzB4MTIwDQpbICAzMTIuNTkxNzY1XSAgWzxmZmZmZmZmZjgxNmNlYTIwPl0gdGNwX3Ry
YW5zbWl0X3NrYisweDQwMC8weDhkMA0KWyAgMzEyLjU5MTc3MF0gIFs8ZmZmZmZmZmY4MTZk
MTlmYT5dIHRjcF93cml0ZV94bWl0KzB4MjFhLzB4YTUwDQpbICAzMTIuNTkxNzc2XSAgWzxm
ZmZmZmZmZjgxNmQyMjlkPl0gX190Y3BfcHVzaF9wZW5kaW5nX2ZyYW1lcysweDJkLzB4OTAN
ClsgIDMxMi41OTE3ODJdICBbPGZmZmZmZmZmODE2YzI2OTM+XSB0Y3Bfc2VuZG1zZysweDE4
My8weGUyMA0KWyAgMzEyLjU5MTc4OF0gIFs8ZmZmZmZmZmY4MTZlOGYxOT5dIGluZXRfc2Vu
ZG1zZysweGE5LzB4MTAwDQpbICAzMTIuNTkxNzkzXSAgWzxmZmZmZmZmZjgxNmU4ZTcwPl0g
PyBpbmV0X2F1dG9iaW5kKzB4NzAvMHg3MA0KWyAgMzEyLjU5MTc5OV0gIFs8ZmZmZmZmZmY4
MTBiMGY4OD5dID8gbG9ja19hY3F1aXJlKzB4ZDgvMHgxMDANClsgIDMxMi41OTE4MDRdICBb
PGZmZmZmZmZmODE2MDYzMGQ+XSBzb2NrX2Fpb193cml0ZSsweDEyZC8weDE0MA0KWyAgMzEy
LjU5MTgxMF0gIFs8ZmZmZmZmZmY4MTE0MzViMj5dIGRvX3N5bmNfd3JpdGUrMHhhMi8weGUw
DQpbICAzMTIuNTkxODE2XSAgWzxmZmZmZmZmZjgxMGFkMjJkPl0gPyB0cmFjZV9oYXJkaXJx
c19vbisweGQvMHgxMA0KWyAgMzEyLjU5MTgyMl0gIFs8ZmZmZmZmZmY4MTE0NDFkND5dIHZm
c193cml0ZSsweDE3NC8weDE5MA0KWyAgMzEyLjU5MTgyN10gIFs8ZmZmZmZmZmY4MTE0NDJm
YT5dIHN5c193cml0ZSsweDVhLzB4YTANClsgIDMxMi41OTE4MzNdICBbPGZmZmZmZmZmODEy
YjMzZGU+XSA/IHRyYWNlX2hhcmRpcnFzX29uX3RodW5rKzB4M2EvMHgzZg0KWyAgMzEyLjU5
MTgzOV0gIFs8ZmZmZmZmZmY4MTc0OTFjYz5dIGNzdGFyX2Rpc3BhdGNoKzB4Ny8weDI2DQpb
ICAzMTIuNTkxODQzXSAtLS1bIGVuZCB0cmFjZSAyZTI4ZWVjOTNiN2E4Yjg3IF0tLS0NClsg
IDMxMy4wNDg0MzFdIC0tLS0tLS0tLS0tLVsgY3V0IGhlcmUgXS0tLS0tLS0tLS0tLQ0KWyAg
MzEzLjA0ODQ4N10gV0FSTklORzogYXQgZHJpdmVycy9uZXQveGVuLW5ldGZyb250LmM6NDY1
IHhlbm5ldF9zdGFydF94bWl0KzB4N2ZlLzB4ODYwKCkNClsgIDMxMy4wNDg1MTRdIE1vZHVs
ZXMgbGlua2VkIGluOg0KWyAgMzEzLjA0ODUzNl0gUGlkOiAwLCBjb21tOiBzd2FwcGVyLzAg
VGFpbnRlZDogRyAgICAgICAgVyAgICAzLjYuMHByZS1yYzEtMjAxMjEwMTEgIzENClsgIDMx
My4wNDg1NjBdIENhbGwgVHJhY2U6DQpbICAzMTMuMDQ4NTczXSAgPElSUT4gIFs8ZmZmZmZm
ZmY4MTA2NjRlYT5dIHdhcm5fc2xvd3BhdGhfY29tbW9uKzB4N2EvMHhiMA0KWyAgMzEzLjA0
ODYxNF0gIFs8ZmZmZmZmZmY4MTA2NjUzNT5dIHdhcm5fc2xvd3BhdGhfbnVsbCsweDE1LzB4
MjANClsgIDMxMy4wNDg2MzhdICBbPGZmZmZmZmZmODE0NmQ4OWU+XSB4ZW5uZXRfc3RhcnRf
eG1pdCsweDdmZS8weDg2MA0KWyAgMzEzLjA0ODY2NV0gIFs8ZmZmZmZmZmY4MTYxZjM0OT5d
IGRldl9oYXJkX3N0YXJ0X3htaXQrMHgyMDkvMHg0NjANClsgIDMxMy4wNDg2ODldICBbPGZm
ZmZmZmZmODE2M2IwMzY+XSBzY2hfZGlyZWN0X3htaXQrMHhmNi8weDI5MA0KWyAgMzEzLjA0
ODcxMV0gIFs8ZmZmZmZmZmY4MTYxZjc0Nj5dIGRldl9xdWV1ZV94bWl0KzB4MWE2LzB4NWEw
DQpbICAzMTMuMDQ4NzM0XSAgWzxmZmZmZmZmZjgxNjFmNWEwPl0gPyBkZXZfaGFyZF9zdGFy
dF94bWl0KzB4NDYwLzB4NDYwDQpbICAzMTMuMDQ4NzU4XSAgWzxmZmZmZmZmZjgxMGIxNDE3
Pl0gPyBsb2NrX3JlbGVhc2UrMHgxMTcvMHgyNTANClsgIDMxMy4wNDg3ODNdICBbPGZmZmZm
ZmZmODE2Yjk1MzY+XSBpcF9maW5pc2hfb3V0cHV0KzB4MjI2LzB4NTMwDQpbICAzMTMuMDQ4
ODA2XSAgWzxmZmZmZmZmZjgxNmI5M2RkPl0gPyBpcF9maW5pc2hfb3V0cHV0KzB4Y2QvMHg1
MzANClsgIDMxMy4wNDg4MjldICBbPGZmZmZmZmZmODE2Yjk4OTk+XSBpcF9vdXRwdXQrMHg1
OS8weGUwDQpbICAzMTMuMDQ4ODUwXSAgWzxmZmZmZmZmZjgxNmI4M2I4Pl0gaXBfbG9jYWxf
b3V0KzB4MjgvMHg5MA0KWyAgMzEzLjA0ODg3Ml0gIFs8ZmZmZmZmZmY4MTZiODk2Zj5dIGlw
X3F1ZXVlX3htaXQrMHgxN2YvMHg0YTANClsgIDMxMy4wNDg4OTZdICBbPGZmZmZmZmZmODE2
Yjg3ZjA+XSA/IGlwX3NlbmRfdW5pY2FzdF9yZXBseSsweDM0MC8weDM0MA0KWyAgMzEzLjA0
ODkyMF0gIFs8ZmZmZmZmZmY4MTBhMGJhNz5dID8gZ2V0bnN0aW1lb2ZkYXkrMHg0Ny8weGUw
DQpbICAzMTMuMDQ4OTQzXSAgWzxmZmZmZmZmZjgxNjBmNGM5Pl0gPyBfX3NrYl9jbG9uZSsw
eDI5LzB4MTIwDQpbICAzMTMuMDQ4OTY1XSAgWzxmZmZmZmZmZjgxNmNlYTIwPl0gdGNwX3Ry
YW5zbWl0X3NrYisweDQwMC8weDhkMA0KWyAgMzEzLjA0ODk4OF0gIFs8ZmZmZmZmZmY4MTZk
MTEwNj5dIHRjcF9yZXRyYW5zbWl0X3NrYisweDFjNi8weDVhMA0KWyAgMzEzLjA0OTAxMV0g
IFs8ZmZmZmZmZmY4MTZkMTY3ZT5dIHRjcF94bWl0X3JldHJhbnNtaXRfcXVldWUrMHgxOWUv
MHgzMDANClsgIDMxMy4wNDkwMzRdICBbPGZmZmZmZmZmODE2Yzk5ZmY+XSB0Y3BfZmFzdHJl
dHJhbnNfYWxlcnQrMHg5NGYvMHhjYjANClsgIDMxMy4wNDkwNTddICBbPGZmZmZmZmZmODE2
Y2E3MGM+XSB0Y3BfYWNrKzB4OWFjLzB4MTE1MA0KWyAgMzEzLjA0OTA3OV0gIFs8ZmZmZmZm
ZmY4MTZjZDg1OD5dIHRjcF9yY3ZfZXN0YWJsaXNoZWQrMHgzMTgvMHg2NDANClsgIDMxMy4w
NDkxMDJdICBbPGZmZmZmZmZmODE2ZDVlZWY+XSA/IHRjcF92NF9yY3YrMHg2Y2YvMHhiMTAN
ClsgIDMxMy4wNDkxMjNdICBbPGZmZmZmZmZmODE2ZDU0ZDU+XSB0Y3BfdjRfZG9fcmN2KzB4
MTM1LzB4NDgwDQpbICAzMTMuMDQ5MTQ3XSAgWzxmZmZmZmZmZjgxNzQ2MWQyPl0gPyBfcmF3
X3NwaW5fbG9ja19uZXN0ZWQrMHg0Mi8weDUwDQpbICAzMTMuMDQ5MTY5XSAgWzxmZmZmZmZm
ZjgxNmQ1ZWVmPl0gPyB0Y3BfdjRfcmN2KzB4NmNmLzB4YjEwDQpbICAzMTMuMDQ5MTkxXSAg
WzxmZmZmZmZmZjgxNmQ2MTdkPl0gdGNwX3Y0X3JjdisweDk1ZC8weGIxMA0KWyAgMzEzLjA0
OTIxMl0gIFs8ZmZmZmZmZmY4MTBiMGY4OD5dID8gbG9ja19hY3F1aXJlKzB4ZDgvMHgxMDAN
ClsgIDMxMy4wNDkyMzNdICBbPGZmZmZmZmZmODE2YjI5OTU+XSA/IGlwX2xvY2FsX2RlbGl2
ZXJfZmluaXNoKzB4NDUvMHgyMzANClsgIDMxMy4wNDkyNTddICBbPGZmZmZmZmZmODE2YjJh
NmE+XSBpcF9sb2NhbF9kZWxpdmVyX2ZpbmlzaCsweDExYS8weDIzMA0KWyAgMzEzLjA0OTI4
MF0gIFs8ZmZmZmZmZmY4MTZiMjk5NT5dID8gaXBfbG9jYWxfZGVsaXZlcl9maW5pc2grMHg0
NS8weDIzMA0KWyAgMzEzLjA0OTMwNF0gIFs8ZmZmZmZmZmY4MTZiMmJiOD5dIGlwX2xvY2Fs
X2RlbGl2ZXIrMHgzOC8weDgwDQpbICAzMTMuMDQ5MzI2XSAgWzxmZmZmZmZmZjgxNmIyMTdh
Pl0gaXBfcmN2X2ZpbmlzaCsweDE1YS8weDYzMA0KWyAgMzEzLjA0OTM0N10gIFs8ZmZmZmZm
ZmY4MTZiMjg2OD5dIGlwX3JjdisweDIxOC8weDMwMA0KWyAgMzEzLjA0OTM2OF0gIFs8ZmZm
ZmZmZmY4MTYxYWM4ZD5dIF9fbmV0aWZfcmVjZWl2ZV9za2IrMHg2NWQvMHg4ZDANClsgIDMx
My4wNDkzOTNdICBbPGZmZmZmZmZmODE2MWE3NzU+XSA/IF9fbmV0aWZfcmVjZWl2ZV9za2Ir
MHgxNDUvMHg4ZDANClsgIDMxMy4wNDk0MTZdICBbPGZmZmZmZmZmODEwYWQyMmQ+XSA/IHRy
YWNlX2hhcmRpcnFzX29uKzB4ZC8weDEwDQpbICAzMTMuMDQ5NDQwXSAgWzxmZmZmZmZmZjgx
MGY5OTczPl0gPyBmcmVlX2hvdF9jb2xkX3BhZ2UrMHgxYjMvMHgxZTANClsgIDMxMy4wNDk0
NjNdICBbPGZmZmZmZmZmODE2MWQxZjg+XSBuZXRpZl9yZWNlaXZlX3NrYisweDI4LzB4ZjAN
ClsgIDMxMy4wNDk0ODZdICBbPGZmZmZmZmZmODE2MTJkMDM+XSA/IF9fcHNrYl9wdWxsX3Rh
aWwrMHgyNTMvMHgzNDANClsgIDMxMy4wNDk1MDhdICBbPGZmZmZmZmZmODE0NmU0YzU+XSB4
ZW5uZXRfcG9sbCsweGFkNS8weGUxMA0KWyAgMzEzLjA0OTUzNF0gIFs8ZmZmZmZmZmY4MTYx
ZGZhNj5dIG5ldF9yeF9hY3Rpb24rMHgxMzYvMHgyNjANClsgIDMxMy4wNDk1NTddICBbPGZm
ZmZmZmZmODEwNmUzODE+XSA/IF9fZG9fc29mdGlycSsweDcxLzB4MWEwDQpbICAzMTMuMDQ5
NTc5XSAgWzxmZmZmZmZmZjgxMDZlM2Q5Pl0gX19kb19zb2Z0aXJxKzB4YzkvMHgxYTANClsg
IDMxMy4wNDk2MDJdICBbPGZmZmZmZmZmODE3NDhkM2M+XSBjYWxsX3NvZnRpcnErMHgxYy8w
eDMwDQpbICAzMTMuMDQ5NjIzXSAgWzxmZmZmZmZmZjgxMDBlZGI1Pl0gZG9fc29mdGlycSsw
eDg1LzB4ZjANClsgIDMxMy4wNDk2NDVdICBbPGZmZmZmZmZmODEwNmUyNGU+XSBpcnFfZXhp
dCsweDllLzB4ZDANClsgIDMxMy4wNDk2NjhdICBbPGZmZmZmZmZmODEzMzlmNWY+XSB4ZW5f
ZXZ0Y2huX2RvX3VwY2FsbCsweDJmLzB4NDANClsgIDMxMy4wNDk2OTBdICBbPGZmZmZmZmZm
ODE3NDhkOWU+XSB4ZW5fZG9faHlwZXJ2aXNvcl9jYWxsYmFjaysweDFlLzB4MzANClsgIDMx
My4wNDk3MDldICA8RU9JPiAgWzxmZmZmZmZmZjgxMDAxM2FhPl0gPyB4ZW5faHlwZXJjYWxs
X3NjaGVkX29wKzB4YS8weDIwDQpbICAzMTMuMDQ5NzQ1XSAgWzxmZmZmZmZmZjgxMDAxM2Fh
Pl0gPyB4ZW5faHlwZXJjYWxsX3NjaGVkX29wKzB4YS8weDIwDQpbICAzMTMuMDQ5NzY5XSAg
WzxmZmZmZmZmZjgxMDA4NjkwPl0gPyB4ZW5fc2FmZV9oYWx0KzB4MTAvMHgyMA0KWyAgMzEz
LjA0OTc5MV0gIFs8ZmZmZmZmZmY4MTAxNjBkMD5dID8gZGVmYXVsdF9pZGxlKzB4NDAvMHg5
MA0KWyAgMzEzLjA0OTgxMl0gIFs8ZmZmZmZmZmY4MTAxNjQ4Nj5dID8gY3B1X2lkbGUrMHg5
Ni8weGYwDQpbICAzMTMuMDQ5ODMyXSAgWzxmZmZmZmZmZjgxNzIyZDNjPl0gPyByZXN0X2lu
aXQrMHhiYy8weGQwDQpbICAzMTMuMDQ5ODUyXSAgWzxmZmZmZmZmZjgxNzIyYzgwPl0gPyBj
c3VtX3BhcnRpYWxfY29weV9nZW5lcmljKzB4MTcwLzB4MTcwDQpbICAzMTMuMDQ5ODc4XSAg
WzxmZmZmZmZmZjgxY2UwZGYyPl0gPyBzdGFydF9rZXJuZWwrMHgzOTAvMHgzOWQNClsgIDMx
My4wNDk5MDFdICBbPGZmZmZmZmZmODFjZTA4ODI+XSA/IGtlcm5lbF9pbml0KzB4MjBiLzB4
MjBiDQpbICAzMTMuMDQ5OTI4XSAgWzxmZmZmZmZmZjgxY2UwMzU2Pl0gPyB4ODZfNjRfc3Rh
cnRfcmVzZXJ2YXRpb25zKzB4MTMxLzB4MTM2DQpbICAzMTMuMDQ5OTUyXSAgWzxmZmZmZmZm
ZjgxY2UzZDYwPl0gPyB4ZW5fc3RhcnRfa2VybmVsKzB4NzBkLzB4NzBmDQpbICAzMTMuMDQ5
OTc0XSAtLS1bIGVuZCB0cmFjZSAyZTI4ZWVjOTNiN2E4Yjg4IF0tLS0NClsgIDMxMy4wNTAw
NTRdIC0tLS0tLS0tLS0tLVsgY3V0IGhlcmUgXS0tLS0tLS0tLS0tLQ0KWyAgMzEzLjA1MDA3
N10gV0FSTklORzogYXQgZHJpdmVycy9uZXQveGVuLW5ldGZyb250LmM6NDY1IHhlbm5ldF9z
dGFydF94bWl0KzB4N2ZlLzB4ODYwKCkNClsgIDMxMy4wNTAxMDJdIE1vZHVsZXMgbGlua2Vk
IGluOg0KWyAgMzEzLjA1MDEyMV0gUGlkOiAwLCBjb21tOiBzd2FwcGVyLzAgVGFpbnRlZDog
RyAgICAgICAgVyAgICAzLjYuMHByZS1yYzEtMjAxMjEwMTEgIzENClsgIDMxMy4wNTAxNDNd
IENhbGwgVHJhY2U6DQpbICAzMTMuMDUwMTUzXSAgPElSUT4gIFs8ZmZmZmZmZmY4MTA2NjRl
YT5dIHdhcm5fc2xvd3BhdGhfY29tbW9uKzB4N2EvMHhiMA0KWyAgMzEzLjA1MDE4N10gIFs8
ZmZmZmZmZmY4MTA2NjUzNT5dIHdhcm5fc2xvd3BhdGhfbnVsbCsweDE1LzB4MjANClsgIDMx
My4wNTAyMTBdICBbPGZmZmZmZmZmODE0NmQ4OWU+XSB4ZW5uZXRfc3RhcnRfeG1pdCsweDdm
ZS8weDg2MA0KWyAgMzEzLjA1MDIzNF0gIFs8ZmZmZmZmZmY4MTYxZjM0OT5dIGRldl9oYXJk
X3N0YXJ0X3htaXQrMHgyMDkvMHg0NjANClsgIDMxMy4wNTAyNTddICBbPGZmZmZmZmZmODE2
M2IwMzY+XSBzY2hfZGlyZWN0X3htaXQrMHhmNi8weDI5MA0KWyAgMzEzLjA1MDI4MF0gIFs8
ZmZmZmZmZmY4MTYxZjc0Nj5dIGRldl9xdWV1ZV94bWl0KzB4MWE2LzB4NWEwDQpbICAzMTMu
MDUwMzAyXSAgWzxmZmZmZmZmZjgxNjFmNWEwPl0gPyBkZXZfaGFyZF9zdGFydF94bWl0KzB4
NDYwLzB4NDYwDQpbICAzMTMuMDUwMzI1XSAgWzxmZmZmZmZmZjgxMGIxNDE3Pl0gPyBsb2Nr
X3JlbGVhc2UrMHgxMTcvMHgyNTANClsgIDMxMy4wNTAzNDhdICBbPGZmZmZmZmZmODE2Yjk1
MzY+XSBpcF9maW5pc2hfb3V0cHV0KzB4MjI2LzB4NTMwDQpbICAzMTMuMDUwMzczXSAgWzxm
ZmZmZmZmZjgxNmI5M2RkPl0gPyBpcF9maW5pc2hfb3V0cHV0KzB4Y2QvMHg1MzANClsgIDMx
My4wNTAzOTddICBbPGZmZmZmZmZmODE2Yjk4OTk+XSBpcF9vdXRwdXQrMHg1OS8weGUwDQpb
ICAzMTMuMDUwNDE4XSAgWzxmZmZmZmZmZjgxNmI4M2I4Pl0gaXBfbG9jYWxfb3V0KzB4Mjgv
MHg5MA0KWyAgMzEzLjA1MDQzOV0gIFs8ZmZmZmZmZmY4MTZiODk2Zj5dIGlwX3F1ZXVlX3ht
aXQrMHgxN2YvMHg0YTANClsgIDMxMy4wNTA0NjFdICBbPGZmZmZmZmZmODE2Yjg3ZjA+XSA/
IGlwX3NlbmRfdW5pY2FzdF9yZXBseSsweDM0MC8weDM0MA0KWyAgMzEzLjA1MDQ4NF0gIFs8
ZmZmZmZmZmY4MTBhMGJhNz5dID8gZ2V0bnN0aW1lb2ZkYXkrMHg0Ny8weGUwDQpbICAzMTMu
MDUwNTA2XSAgWzxmZmZmZmZmZjgxNjBmNGM5Pl0gPyBfX3NrYl9jbG9uZSsweDI5LzB4MTIw
DQpbICAzMTMuMDUwNTI3XSAgWzxmZmZmZmZmZjgxNmNlYTIwPl0gdGNwX3RyYW5zbWl0X3Nr
YisweDQwMC8weDhkMA0KWyAgMzEzLjA1MDU1MF0gIFs8ZmZmZmZmZmY4MTZkMTEwNj5dIHRj
cF9yZXRyYW5zbWl0X3NrYisweDFjNi8weDVhMA0KWyAgMzEzLjA1MDU3NF0gIFs8ZmZmZmZm
ZmY4MTZkMTY3ZT5dIHRjcF94bWl0X3JldHJhbnNtaXRfcXVldWUrMHgxOWUvMHgzMDANClsg
IDMxMy4wNTA1OThdICBbPGZmZmZmZmZmODE2Yzk5ZmY+XSB0Y3BfZmFzdHJldHJhbnNfYWxl
cnQrMHg5NGYvMHhjYjANClsgIDMxMy4wNTA2MjFdICBbPGZmZmZmZmZmODE2Y2E3MGM+XSB0
Y3BfYWNrKzB4OWFjLzB4MTE1MA0KWyAgMzEzLjA1MDY0M10gIFs8ZmZmZmZmZmY4MTZjZDg1
OD5dIHRjcF9yY3ZfZXN0YWJsaXNoZWQrMHgzMTgvMHg2NDANClsgIDMxMy4wNTA2NjZdICBb
PGZmZmZmZmZmODE2ZDVlZWY+XSA/IHRjcF92NF9yY3YrMHg2Y2YvMHhiMTANClsgIDMxMy4w
NTA2ODhdICBbPGZmZmZmZmZmODE2ZDU0ZDU+XSB0Y3BfdjRfZG9fcmN2KzB4MTM1LzB4NDgw
DQpbICAzMTMuMDUwNzEwXSAgWzxmZmZmZmZmZjgxNzQ2MWQyPl0gPyBfcmF3X3NwaW5fbG9j
a19uZXN0ZWQrMHg0Mi8weDUwDQpbICAzMTMuMDUwNzMzXSAgWzxmZmZmZmZmZjgxNmQ1ZWVm
Pl0gPyB0Y3BfdjRfcmN2KzB4NmNmLzB4YjEwDQpbICAzMTMuMDUwNzU1XSAgWzxmZmZmZmZm
ZjgxNmQ2MTdkPl0gdGNwX3Y0X3JjdisweDk1ZC8weGIxMA0KWyAgMzEzLjA1MDc3Nl0gIFs8
ZmZmZmZmZmY4MTBiMGY4OD5dID8gbG9ja19hY3F1aXJlKzB4ZDgvMHgxMDANClsgIDMxMy4w
NTA3OTddICBbPGZmZmZmZmZmODE2YjI5OTU+XSA/IGlwX2xvY2FsX2RlbGl2ZXJfZmluaXNo
KzB4NDUvMHgyMzANClsgIDMxMy4wNTA4MjFdICBbPGZmZmZmZmZmODE2YjJhNmE+XSBpcF9s
b2NhbF9kZWxpdmVyX2ZpbmlzaCsweDExYS8weDIzMA0KWyAgMzEzLjA1MDg0NF0gIFs8ZmZm
ZmZmZmY4MTZiMjk5NT5dID8gaXBfbG9jYWxfZGVsaXZlcl9maW5pc2grMHg0NS8weDIzMA0K
WyAgMzEzLjA1MDg2OV0gIFs8ZmZmZmZmZmY4MTZiMmJiOD5dIGlwX2xvY2FsX2RlbGl2ZXIr
MHgzOC8weDgwDQpbICAzMTMuMDUwODkxXSAgWzxmZmZmZmZmZjgxNmIyMTdhPl0gaXBfcmN2
X2ZpbmlzaCsweDE1YS8weDYzMA0KWyAgMzEzLjA1MDkxM10gIFs8ZmZmZmZmZmY4MTZiMjg2
OD5dIGlwX3JjdisweDIxOC8weDMwMA0KWyAgMzEzLjA1MDkzNF0gIFs8ZmZmZmZmZmY4MTYx
YWM4ZD5dIF9fbmV0aWZfcmVjZWl2ZV9za2IrMHg2NWQvMHg4ZDANClsgIDMxMy4wNTA5NTZd
ICBbPGZmZmZmZmZmODE2MWE3NzU+XSA/IF9fbmV0aWZfcmVjZWl2ZV9za2IrMHgxNDUvMHg4
ZDANClsgIDMxMy4wNTA5NzldICBbPGZmZmZmZmZmODEwYWQyMmQ+XSA/IHRyYWNlX2hhcmRp
cnFzX29uKzB4ZC8weDEwDQpbICAzMTMuMDUxMDAxXSAgWzxmZmZmZmZmZjgxMGY5OTczPl0g
PyBmcmVlX2hvdF9jb2xkX3BhZ2UrMHgxYjMvMHgxZTANClsgIDMxMy4wNTEwMjRdICBbPGZm
ZmZmZmZmODE2MWQxZjg+XSBuZXRpZl9yZWNlaXZlX3NrYisweDI4LzB4ZjANClsgIDMxMy4w
NTEwNDddICBbPGZmZmZmZmZmODE2MTJkMDM+XSA/IF9fcHNrYl9wdWxsX3RhaWwrMHgyNTMv
MHgzNDANClsgIDMxMy4wNTEwNzBdICBbPGZmZmZmZmZmODE0NmU0YzU+XSB4ZW5uZXRfcG9s
bCsweGFkNS8weGUxMA0KWyAgMzEzLjA1MTA5NV0gIFs8ZmZmZmZmZmY4MTYxZGZhNj5dIG5l
dF9yeF9hY3Rpb24rMHgxMzYvMHgyNjANClsgIDMxMy4wNTExMTddICBbPGZmZmZmZmZmODEw
NmUzODE+XSA/IF9fZG9fc29mdGlycSsweDcxLzB4MWEwDQpbICAzMTMuMDUxMTM5XSAgWzxm
ZmZmZmZmZjgxMDZlM2Q5Pl0gX19kb19zb2Z0aXJxKzB4YzkvMHgxYTANClsgIDMxMy4wNTEx
NjFdICBbPGZmZmZmZmZmODE3NDhkM2M+XSBjYWxsX3NvZnRpcnErMHgxYy8weDMwDQpbICAz
MTMuMDUxMTgxXSAgWzxmZmZmZmZmZjgxMDBlZGI1Pl0gZG9fc29mdGlycSsweDg1LzB4ZjAN
ClsgIDMxMy4wNTEyMDJdICBbPGZmZmZmZmZmODEwNmUyNGU+XSBpcnFfZXhpdCsweDllLzB4
ZDANClsgIDMxMy4wNTEyMjNdICBbPGZmZmZmZmZmODEzMzlmNWY+XSB4ZW5fZXZ0Y2huX2Rv
X3VwY2FsbCsweDJmLzB4NDANClsgIDMxMy4wNTEyNDZdICBbPGZmZmZmZmZmODE3NDhkOWU+
XSB4ZW5fZG9faHlwZXJ2aXNvcl9jYWxsYmFjaysweDFlLzB4MzANClsgIDMxMy4wNTEyNjVd
ICA8RU9JPiAgWzxmZmZmZmZmZjgxMDAxM2FhPl0gPyB4ZW5faHlwZXJjYWxsX3NjaGVkX29w
KzB4YS8weDIwDQpbICAzMTMuMDUxMzAxXSAgWzxmZmZmZmZmZjgxMDAxM2FhPl0gPyB4ZW5f
aHlwZXJjYWxsX3NjaGVkX29wKzB4YS8weDIwDQpbICAzMTMuMDUxMzI1XSAgWzxmZmZmZmZm
ZjgxMDA4NjkwPl0gPyB4ZW5fc2FmZV9oYWx0KzB4MTAvMHgyMA0KWyAgMzEzLjA1MTM0N10g
IFs8ZmZmZmZmZmY4MTAxNjBkMD5dID8gZGVmYXVsdF9pZGxlKzB4NDAvMHg5MA0KWyAgMzEz
LjA1MTM2OV0gIFs8ZmZmZmZmZmY4MTAxNjQ4Nj5dID8gY3B1X2lkbGUrMHg5Ni8weGYwDQpb
ICAzMTMuMDUxMzg4XSAgWzxmZmZmZmZmZjgxNzIyZDNjPl0gPyByZXN0X2luaXQrMHhiYy8w
eGQwDQpbICAzMTMuMDUxNDA4XSAgWzxmZmZmZmZmZjgxNzIyYzgwPl0gPyBjc3VtX3BhcnRp
YWxfY29weV9nZW5lcmljKzB4MTcwLzB4MTcwDQpbICAzMTMuMDUxNDMyXSAgWzxmZmZmZmZm
ZjgxY2UwZGYyPl0gPyBzdGFydF9rZXJuZWwrMHgzOTAvMHgzOWQNClsgIDMxMy4wNTE0NTRd
ICBbPGZmZmZmZmZmODFjZTA4ODI+XSA/IGtlcm5lbF9pbml0KzB4MjBiLzB4MjBiDQpbICAz
MTMuMDUxNDc2XSAgWzxmZmZmZmZmZjgxY2UwMzU2Pl0gPyB4ODZfNjRfc3RhcnRfcmVzZXJ2
YXRpb25zKzB4MTMxLzB4MTM2DQpbICAzMTMuMDUxNTAzXSAgWzxmZmZmZmZmZjgxY2UzZDYw
Pl0gPyB4ZW5fc3RhcnRfa2VybmVsKzB4NzBkLzB4NzBmDQpbICAzMTMuMDUxNTIzXSAtLS1b
IGVuZCB0cmFjZSAyZTI4ZWVjOTNiN2E4Yjg5IF0tLS0NClsgIDMxMy4wNTM2NDVdIC0tLS0t
LS0tLS0tLVsgY3V0IGhlcmUgXS0tLS0tLS0tLS0tLQ0KWyAgMzEzLjA1MzY4NF0gV0FSTklO
RzogYXQgZHJpdmVycy9uZXQveGVuLW5ldGZyb250LmM6NDY1IHhlbm5ldF9zdGFydF94bWl0
KzB4N2ZlLzB4ODYwKCkNClsgIDMxMy4wNTM3MDddIE1vZHVsZXMgbGlua2VkIGluOg0KWyAg
MzEzLjA1MzcyOV0gUGlkOiAxNTIzLCBjb21tOiBzeXNsb2dkIFRhaW50ZWQ6IEcgICAgICAg
IFcgICAgMy42LjBwcmUtcmMxLTIwMTIxMDExICMxDQpbICAzMTMuMDUzNzUxXSBDYWxsIFRy
YWNlOg0KWyAgMzEzLjA1Mzc2Ml0gIDxJUlE+ICBbPGZmZmZmZmZmODEwNjY0ZWE+XSB3YXJu
X3Nsb3dwYXRoX2NvbW1vbisweDdhLzB4YjANClsgIDMxMy4wNTM3OThdICBbPGZmZmZmZmZm
ODEwNjY1MzU+XSB3YXJuX3Nsb3dwYXRoX251bGwrMHgxNS8weDIwDQpbICAzMTMuMDUzODIw
XSAgWzxmZmZmZmZmZjgxNDZkODllPl0geGVubmV0X3N0YXJ0X3htaXQrMHg3ZmUvMHg4NjAN
ClsgIDMxMy4wNTM4NDVdICBbPGZmZmZmZmZmODE2MWYzNDk+XSBkZXZfaGFyZF9zdGFydF94
bWl0KzB4MjA5LzB4NDYwDQpbICAzMTMuMDUzODY5XSAgWzxmZmZmZmZmZjgxNjNiMDM2Pl0g
c2NoX2RpcmVjdF94bWl0KzB4ZjYvMHgyOTANClsgIDMxMy4wNTM4OTFdICBbPGZmZmZmZmZm
ODE2MWY3NDY+XSBkZXZfcXVldWVfeG1pdCsweDFhNi8weDVhMA0KWyAgMzEzLjA1MzkxM10g
IFs8ZmZmZmZmZmY4MTYxZjVhMD5dID8gZGV2X2hhcmRfc3RhcnRfeG1pdCsweDQ2MC8weDQ2
MA0KWyAgMzEzLjA1MzkzNl0gIFs8ZmZmZmZmZmY4MTBiMTQxNz5dID8gbG9ja19yZWxlYXNl
KzB4MTE3LzB4MjUwDQpbICAzMTMuMDUzOTYwXSAgWzxmZmZmZmZmZjgxNmI5NTM2Pl0gaXBf
ZmluaXNoX291dHB1dCsweDIyNi8weDUzMA0KWyAgMzEzLjA1Mzk4NV0gIFs8ZmZmZmZmZmY4
MTZiOTNkZD5dID8gaXBfZmluaXNoX291dHB1dCsweGNkLzB4NTMwDQpbICAzMTMuMDU0MDEw
XSAgWzxmZmZmZmZmZjgxNmI5ODk5Pl0gaXBfb3V0cHV0KzB4NTkvMHhlMA0KWyAgMzEzLjA1
NDAzMV0gIFs8ZmZmZmZmZmY4MTZiODNiOD5dIGlwX2xvY2FsX291dCsweDI4LzB4OTANClsg
IDMxMy4wNTQwNTNdICBbPGZmZmZmZmZmODE2Yjg5NmY+XSBpcF9xdWV1ZV94bWl0KzB4MTdm
LzB4NGEwDQpbICAzMTMuMDU0MDc0XSAgWzxmZmZmZmZmZjgxNmI4N2YwPl0gPyBpcF9zZW5k
X3VuaWNhc3RfcmVwbHkrMHgzNDAvMHgzNDANClsgIDMxMy4wNTQwOTddICBbPGZmZmZmZmZm
ODEwYTBiYTc+XSA/IGdldG5zdGltZW9mZGF5KzB4NDcvMHhlMA0KWyAgMzEzLjA1NDEyMF0g
IFs8ZmZmZmZmZmY4MTYwZjRjOT5dID8gX19za2JfY2xvbmUrMHgyOS8weDEyMA0KWyAgMzEz
LjA1NDE0MV0gIFs8ZmZmZmZmZmY4MTZjZWEyMD5dIHRjcF90cmFuc21pdF9za2IrMHg0MDAv
MHg4ZDANClsgIDMxMy4wNTQxNjRdICBbPGZmZmZmZmZmODE2ZDExMDY+XSB0Y3BfcmV0cmFu
c21pdF9za2IrMHgxYzYvMHg1YTANClsgIDMxMy4wNTQxODZdICBbPGZmZmZmZmZmODE3NDZj
YjU+XSA/IF9yYXdfc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSsweDc1LzB4YTANClsgIDMxMy4w
NTQyMTFdICBbPGZmZmZmZmZmODE2ZDE2N2U+XSB0Y3BfeG1pdF9yZXRyYW5zbWl0X3F1ZXVl
KzB4MTllLzB4MzAwDQpbICAzMTMuMDU0MjM0XSAgWzxmZmZmZmZmZjgxNmM5OWZmPl0gdGNw
X2Zhc3RyZXRyYW5zX2FsZXJ0KzB4OTRmLzB4Y2IwDQpbICAzMTMuMDU0MjU3XSAgWzxmZmZm
ZmZmZjgxNmNhNzBjPl0gdGNwX2FjaysweDlhYy8weDExNTANClsgIDMxMy4wNTQyODBdICBb
PGZmZmZmZmZmODE2Y2Q4Y2U+XSB0Y3BfcmN2X2VzdGFibGlzaGVkKzB4MzhlLzB4NjQwDQpb
ICAzMTMuMDU0MzAzXSAgWzxmZmZmZmZmZjgxNmQ1ZWVmPl0gPyB0Y3BfdjRfcmN2KzB4NmNm
LzB4YjEwDQpbICAzMTMuMDU0MzI1XSAgWzxmZmZmZmZmZjgxNmQ1NGQ1Pl0gdGNwX3Y0X2Rv
X3JjdisweDEzNS8weDQ4MA0KWyAgMzEzLjA1NDM0N10gIFs8ZmZmZmZmZmY4MTc0NjFkMj5d
ID8gX3Jhd19zcGluX2xvY2tfbmVzdGVkKzB4NDIvMHg1MA0KWyAgMzEzLjA1NDM3MF0gIFs8
ZmZmZmZmZmY4MTZkNWVlZj5dID8gdGNwX3Y0X3JjdisweDZjZi8weGIxMA0KWyAgMzEzLjA1
NDM5MV0gIFs8ZmZmZmZmZmY4MTZkNjE3ZD5dIHRjcF92NF9yY3YrMHg5NWQvMHhiMTANClsg
IDMxMy4wNTQ0MTJdICBbPGZmZmZmZmZmODEwYjBmODg+XSA/IGxvY2tfYWNxdWlyZSsweGQ4
LzB4MTAwDQpbICAzMTMuMDU0NDMzXSAgWzxmZmZmZmZmZjgxNmIyOTk1Pl0gPyBpcF9sb2Nh
bF9kZWxpdmVyX2ZpbmlzaCsweDQ1LzB4MjMwDQpbICAzMTMuMDU0NDU4XSAgWzxmZmZmZmZm
ZjgxNmIyYTZhPl0gaXBfbG9jYWxfZGVsaXZlcl9maW5pc2grMHgxMWEvMHgyMzANClsgIDMx
My4wNTQ0ODFdICBbPGZmZmZmZmZmODE2YjI5OTU+XSA/IGlwX2xvY2FsX2RlbGl2ZXJfZmlu
aXNoKzB4NDUvMHgyMzANClsgIDMxMy4wNTQ1MDVdICBbPGZmZmZmZmZmODE2YjJiYjg+XSBp
cF9sb2NhbF9kZWxpdmVyKzB4MzgvMHg4MA0KWyAgMzEzLjA1NDUyN10gIFs8ZmZmZmZmZmY4
MTZiMjE3YT5dIGlwX3Jjdl9maW5pc2grMHgxNWEvMHg2MzANClsgIDMxMy4wNTQ1NDhdICBb
PGZmZmZmZmZmODE2YjI4Njg+XSBpcF9yY3YrMHgyMTgvMHgzMDANClsgIDMxMy4wNTQ1Njld
ICBbPGZmZmZmZmZmODE2MWFjOGQ+XSBfX25ldGlmX3JlY2VpdmVfc2tiKzB4NjVkLzB4OGQw
DQpbICAzMTMuMDU0NTkxXSAgWzxmZmZmZmZmZjgxNjFhNzc1Pl0gPyBfX25ldGlmX3JlY2Vp
dmVfc2tiKzB4MTQ1LzB4OGQwDQpbICAzMTMuMDU0NjEzXSAgWzxmZmZmZmZmZjgxMGFkMjJk
Pl0gPyB0cmFjZV9oYXJkaXJxc19vbisweGQvMHgxMA0KWyAgMzEzLjA1NDYzNl0gIFs8ZmZm
ZmZmZmY4MTBmOTk3Mz5dID8gZnJlZV9ob3RfY29sZF9wYWdlKzB4MWIzLzB4MWUwDQpbICAz
MTMuMDU0NjU5XSAgWzxmZmZmZmZmZjgxNjFkMWY4Pl0gbmV0aWZfcmVjZWl2ZV9za2IrMHgy
OC8weGYwDQpbICAzMTMuMDU0NjgyXSAgWzxmZmZmZmZmZjgxNjEyZDAzPl0gPyBfX3Bza2Jf
cHVsbF90YWlsKzB4MjUzLzB4MzQwDQpbICAzMTMuMDU0NzA1XSAgWzxmZmZmZmZmZjgxNDZl
NGM1Pl0geGVubmV0X3BvbGwrMHhhZDUvMHhlMTANClsgIDMxMy4wNTQ3MzBdICBbPGZmZmZm
ZmZmODE2MWRmYTY+XSBuZXRfcnhfYWN0aW9uKzB4MTM2LzB4MjYwDQpbICAzMTMuMDU0NzUy
XSAgWzxmZmZmZmZmZjgxMDZlMzgxPl0gPyBfX2RvX3NvZnRpcnErMHg3MS8weDFhMA0KWyAg
MzEzLjA1NDc3NF0gIFs8ZmZmZmZmZmY4MTA2ZTNkOT5dIF9fZG9fc29mdGlycSsweGM5LzB4
MWEwDQpbICAzMTMuMDU0Nzk1XSAgWzxmZmZmZmZmZjgxNzQ4ZDNjPl0gY2FsbF9zb2Z0aXJx
KzB4MWMvMHgzMA0KWyAgMzEzLjA1NDgxNl0gIFs8ZmZmZmZmZmY4MTAwZWRiNT5dIGRvX3Nv
ZnRpcnErMHg4NS8weGYwDQpbICAzMTMuMDU0ODM2XSAgWzxmZmZmZmZmZjgxMDZlMjRlPl0g
aXJxX2V4aXQrMHg5ZS8weGQwDQpbICAzMTMuMDU0ODU4XSAgWzxmZmZmZmZmZjgxMzM5ZjVm
Pl0geGVuX2V2dGNobl9kb191cGNhbGwrMHgyZi8weDQwDQpbICAzMTMuMDU0ODgxXSAgWzxm
ZmZmZmZmZjgxNzQ4ZDllPl0geGVuX2RvX2h5cGVydmlzb3JfY2FsbGJhY2srMHgxZS8weDMw
DQpbICAzMTMuMDU0ODk5XSAgPEVPST4gIFs8ZmZmZmZmZmY4MTAwMTIyYT5dID8geGVuX2h5
cGVyY2FsbF94ZW5fdmVyc2lvbisweGEvMHgyMA0KWyAgMzEzLjA1NDkzN10gIFs8ZmZmZmZm
ZmY4MTAwMTIyYT5dID8geGVuX2h5cGVyY2FsbF94ZW5fdmVyc2lvbisweGEvMHgyMA0KWyAg
MzEzLjA1NDk2MV0gIFs8ZmZmZmZmZmY4MTAwODY0ZD5dID8geGVuX2ZvcmNlX2V2dGNobl9j
YWxsYmFjaysweGQvMHgxMA0KWyAgMzEzLjA1NDk4NV0gIFs8ZmZmZmZmZmY4MTAwOGZmMj5d
ID8gY2hlY2tfZXZlbnRzKzB4MTIvMHgyMA0KWyAgMzEzLjA1NTAwN10gIFs8ZmZmZmZmZmY4
MTAwOGY5OT5dID8geGVuX2lycV9lbmFibGVfZGlyZWN0X3JlbG9jKzB4NC8weDQNClsgIDMx
My4wNTUwMzFdICBbPGZmZmZmZmZmODE3NDkxNDY+XSA/IGlhMzJfY3N0YXJfdGFyZ2V0KzB4
MTYvMHg4Yw0KWyAgMzEzLjA1NTA0OV0gLS0tWyBlbmQgdHJhY2UgMmUyOGVlYzkzYjdhOGI4
YSBdLS0tDQpbICAzMTMuMDU1MTE1XSAtLS0tLS0tLS0tLS1bIGN1dCBoZXJlIF0tLS0tLS0t
LS0tLS0NClsgIDMxMy4wNTUxMzddIFdBUk5JTkc6IGF0IGRyaXZlcnMvbmV0L3hlbi1uZXRm
cm9udC5jOjQ2NSB4ZW5uZXRfc3RhcnRfeG1pdCsweDdmZS8weDg2MCgpDQpbICAzMTMuMDU1
MTYwXSBNb2R1bGVzIGxpbmtlZCBpbjoNClsgIDMxMy4wNTUxNzldIFBpZDogMTUyMywgY29t
bTogc3lzbG9nZCBUYWludGVkOiBHICAgICAgICBXICAgIDMuNi4wcHJlLXJjMS0yMDEyMTAx
MSAjMQ0KWyAgMzEzLjA1NTIwNF0gQ2FsbCBUcmFjZToNClsgIDMxMy4wNTUyMTVdICA8SVJR
PiAgWzxmZmZmZmZmZjgxMDY2NGVhPl0gd2Fybl9zbG93cGF0aF9jb21tb24rMHg3YS8weGIw
DQpbICAzMTMuMDU1MjQ4XSAgWzxmZmZmZmZmZjgxMDY2NTM1Pl0gd2Fybl9zbG93cGF0aF9u
dWxsKzB4MTUvMHgyMA0KWyAgMzEzLjA1NTI3MV0gIFs8ZmZmZmZmZmY4MTQ2ZDg5ZT5dIHhl
bm5ldF9zdGFydF94bWl0KzB4N2ZlLzB4ODYwDQpbICAzMTMuMDU1Mjk2XSAgWzxmZmZmZmZm
ZjgxNjFmMzQ5Pl0gZGV2X2hhcmRfc3RhcnRfeG1pdCsweDIwOS8weDQ2MA0KWyAgMzEzLjA1
NTMxOV0gIFs8ZmZmZmZmZmY4MTYzYjAzNj5dIHNjaF9kaXJlY3RfeG1pdCsweGY2LzB4Mjkw
DQpbICAzMTMuMDU1MzQyXSAgWzxmZmZmZmZmZjgxNjFmNzQ2Pl0gZGV2X3F1ZXVlX3htaXQr
MHgxYTYvMHg1YTANClsgIDMxMy4wNTUzNjRdICBbPGZmZmZmZmZmODE2MWY1YTA+XSA/IGRl
dl9oYXJkX3N0YXJ0X3htaXQrMHg0NjAvMHg0NjANClsgIDMxMy4wNTUzODddICBbPGZmZmZm
ZmZmODEwYjE0MTc+XSA/IGxvY2tfcmVsZWFzZSsweDExNy8weDI1MA0KWyAgMzEzLjA1NTQx
MV0gIFs8ZmZmZmZmZmY4MTZiOTUzNj5dIGlwX2ZpbmlzaF9vdXRwdXQrMHgyMjYvMHg1MzAN
ClsgIDMxMy4wNTU0MzRdICBbPGZmZmZmZmZmODE2YjkzZGQ+XSA/IGlwX2ZpbmlzaF9vdXRw
dXQrMHhjZC8weDUzMA0KWyAgMzEzLjA1NTQ1OF0gIFs8ZmZmZmZmZmY4MTZiOTg5OT5dIGlw
X291dHB1dCsweDU5LzB4ZTANClsgIDMxMy4wNTU0NzldICBbPGZmZmZmZmZmODE2YjgzYjg+
XSBpcF9sb2NhbF9vdXQrMHgyOC8weDkwDQpbICAzMTMuMDU1NTAxXSAgWzxmZmZmZmZmZjgx
NmI4OTZmPl0gaXBfcXVldWVfeG1pdCsweDE3Zi8weDRhMA0KWyAgMzEzLjA1NTUyNF0gIFs8
ZmZmZmZmZmY4MTZiODdmMD5dID8gaXBfc2VuZF91bmljYXN0X3JlcGx5KzB4MzQwLzB4MzQw
DQpbICAzMTMuMDU1NTQ3XSAgWzxmZmZmZmZmZjgxMGEwYmE3Pl0gPyBnZXRuc3RpbWVvZmRh
eSsweDQ3LzB4ZTANClsgIDMxMy4wNTU1NjldICBbPGZmZmZmZmZmODE2MGY0Yzk+XSA/IF9f
c2tiX2Nsb25lKzB4MjkvMHgxMjANClsgIDMxMy4wNTU1OTFdICBbPGZmZmZmZmZmODE2Y2Vh
MjA+XSB0Y3BfdHJhbnNtaXRfc2tiKzB4NDAwLzB4OGQwDQpbICAzMTMuMDU1NjE1XSAgWzxm
ZmZmZmZmZjgxNmQxMTA2Pl0gdGNwX3JldHJhbnNtaXRfc2tiKzB4MWM2LzB4NWEwDQpbICAz
MTMuMDU1NjM3XSAgWzxmZmZmZmZmZjgxNzQ2Y2I1Pl0gPyBfcmF3X3NwaW5fdW5sb2NrX2ly
cXJlc3RvcmUrMHg3NS8weGEwDQpbICAzMTMuMDU1NjYyXSAgWzxmZmZmZmZmZjgxNmQxNjdl
Pl0gdGNwX3htaXRfcmV0cmFuc21pdF9xdWV1ZSsweDE5ZS8weDMwMA0KWyAgMzEzLjA1NTY4
Nl0gIFs8ZmZmZmZmZmY4MTZjOTlmZj5dIHRjcF9mYXN0cmV0cmFuc19hbGVydCsweDk0Zi8w
eGNiMA0KWyAgMzEzLjA1NTcwOV0gIFs8ZmZmZmZmZmY4MTZjYTcwYz5dIHRjcF9hY2srMHg5
YWMvMHgxMTUwDQpbICAzMTMuMDU1NzMyXSAgWzxmZmZmZmZmZjgxNmNkOGNlPl0gdGNwX3Jj
dl9lc3RhYmxpc2hlZCsweDM4ZS8weDY0MA0KWyAgMzEzLjA1NTc2MF0gIFs8ZmZmZmZmZmY4
MTZkNWVlZj5dID8gdGNwX3Y0X3JjdisweDZjZi8weGIxMA0KWyAgMzEzLjA1NTc4Ml0gIFs8
ZmZmZmZmZmY4MTZkNTRkNT5dIHRjcF92NF9kb19yY3YrMHgxMzUvMHg0ODANClsgIDMxMy4w
NTU4MDRdICBbPGZmZmZmZmZmODE3NDYxZDI+XSA/IF9yYXdfc3Bpbl9sb2NrX25lc3RlZCsw
eDQyLzB4NTANClsgIDMxMy4wNTU4MjhdICBbPGZmZmZmZmZmODE2ZDVlZWY+XSA/IHRjcF92
NF9yY3YrMHg2Y2YvMHhiMTANClsgIDMxMy4wNTU4NDldICBbPGZmZmZmZmZmODE2ZDYxN2Q+
XSB0Y3BfdjRfcmN2KzB4OTVkLzB4YjEwDQpbICAzMTMuMDU1ODcwXSAgWzxmZmZmZmZmZjgx
MGIwZjg4Pl0gPyBsb2NrX2FjcXVpcmUrMHhkOC8weDEwMA0KWyAgMzEzLjA1NTg5Ml0gIFs8
ZmZmZmZmZmY4MTZiMjk5NT5dID8gaXBfbG9jYWxfZGVsaXZlcl9maW5pc2grMHg0NS8weDIz
MA0KWyAgMzEzLjA1NTkxN10gIFs8ZmZmZmZmZmY4MTZiMmE2YT5dIGlwX2xvY2FsX2RlbGl2
ZXJfZmluaXNoKzB4MTFhLzB4MjMwDQpbICAzMTMuMDU1OTQwXSAgWzxmZmZmZmZmZjgxNmIy
OTk1Pl0gPyBpcF9sb2NhbF9kZWxpdmVyX2ZpbmlzaCsweDQ1LzB4MjMwDQpbICAzMTMuMDU1
OTY1XSAgWzxmZmZmZmZmZjgxNmIyYmI4Pl0gaXBfbG9jYWxfZGVsaXZlcisweDM4LzB4ODAN
ClsgIDMxMy4wNTU5ODddICBbPGZmZmZmZmZmODE2YjIxN2E+XSBpcF9yY3ZfZmluaXNoKzB4
MTVhLzB4NjMwDQpbICAzMTMuMDU2MDA5XSAgWzxmZmZmZmZmZjgxNmIyODY4Pl0gaXBfcmN2
KzB4MjE4LzB4MzAwDQpbICAzMTMuMDU2MDMwXSAgWzxmZmZmZmZmZjgxNjFhYzhkPl0gX19u
ZXRpZl9yZWNlaXZlX3NrYisweDY1ZC8weDhkMA0KWyAgMzEzLjA1NjA1Ml0gIFs8ZmZmZmZm
ZmY4MTYxYTc3NT5dID8gX19uZXRpZl9yZWNlaXZlX3NrYisweDE0NS8weDhkMA0KWyAgMzEz
LjA1NjA3NV0gIFs8ZmZmZmZmZmY4MTBhZDIyZD5dID8gdHJhY2VfaGFyZGlycXNfb24rMHhk
LzB4MTANClsgIDMxMy4wNTYwOThdICBbPGZmZmZmZmZmODEwZjk5NzM+XSA/IGZyZWVfaG90
X2NvbGRfcGFnZSsweDFiMy8weDFlMA0KWyAgMzEzLjA1NjEyMV0gIFs8ZmZmZmZmZmY4MTYx
ZDFmOD5dIG5ldGlmX3JlY2VpdmVfc2tiKzB4MjgvMHhmMA0KWyAgMzEzLjA1NjE0NV0gIFs8
ZmZmZmZmZmY4MTYxMmQwMz5dID8gX19wc2tiX3B1bGxfdGFpbCsweDI1My8weDM0MA0KWyAg
MzEzLjA1NjE2OF0gIFs8ZmZmZmZmZmY4MTQ2ZTRjNT5dIHhlbm5ldF9wb2xsKzB4YWQ1LzB4
ZTEwDQpbICAzMTMuMDU2MTkzXSAgWzxmZmZmZmZmZjgxNjFkZmE2Pl0gbmV0X3J4X2FjdGlv
bisweDEzNi8weDI2MA0KWyAgMzEzLjA1NjIxNl0gIFs8ZmZmZmZmZmY4MTA2ZTM4MT5dID8g
X19kb19zb2Z0aXJxKzB4NzEvMHgxYTANClsgIDMxMy4wNTYyMzhdICBbPGZmZmZmZmZmODEw
NmUzZDk+XSBfX2RvX3NvZnRpcnErMHhjOS8weDFhMA0KWyAgMzEzLjA1NjI2MF0gIFs8ZmZm
ZmZmZmY4MTc0OGQzYz5dIGNhbGxfc29mdGlycSsweDFjLzB4MzANClsgIDMxMy4wNTYyODFd
ICBbPGZmZmZmZmZmODEwMGVkYjU+XSBkb19zb2Z0aXJxKzB4ODUvMHhmMA0KWyAgMzEzLjA1
NjMwMl0gIFs8ZmZmZmZmZmY4MTA2ZTI0ZT5dIGlycV9leGl0KzB4OWUvMHhkMA0KWyAgMzEz
LjA1NjMyNF0gIFs8ZmZmZmZmZmY4MTMzOWY1Zj5dIHhlbl9ldnRjaG5fZG9fdXBjYWxsKzB4
MmYvMHg0MA0KWyAgMzEzLjA1NjM0N10gIFs8ZmZmZmZmZmY4MTc0OGQ5ZT5dIHhlbl9kb19o
eXBlcnZpc29yX2NhbGxiYWNrKzB4MWUvMHgzMA0KWyAgMzEzLjA1NjM2Nl0gIDxFT0k+ICBb
PGZmZmZmZmZmODEwMDEyMmE+XSA/IHhlbl9oeXBlcmNhbGxfeGVuX3ZlcnNpb24rMHhhLzB4
MjANClsgIDMxMy4wNTY0MDJdICBbPGZmZmZmZmZmODEwMDEyMmE+XSA/IHhlbl9oeXBlcmNh
bGxfeGVuX3ZlcnNpb24rMHhhLzB4MjANClsgIDMxMy4wNTY0MjddICBbPGZmZmZmZmZmODEw
MDg2NGQ+XSA/IHhlbl9mb3JjZV9ldnRjaG5fY2FsbGJhY2srMHhkLzB4MTANClsgIDMxMy4w
NTY0NTBdICBbPGZmZmZmZmZmODEwMDhmZjI+XSA/IGNoZWNrX2V2ZW50cysweDEyLzB4MjAN
ClsgIDMxMy4wNTY0NzNdICBbPGZmZmZmZmZmODEwMDhmOTk+XSA/IHhlbl9pcnFfZW5hYmxl
X2RpcmVjdF9yZWxvYysweDQvMHg0DQpbICAzMTMuMDU2NDk2XSAgWzxmZmZmZmZmZjgxNzQ5
MTQ2Pl0gPyBpYTMyX2NzdGFyX3RhcmdldCsweDE2LzB4OGMNClsgIDMxMy4wNTY1MTVdIC0t
LVsgZW5kIHRyYWNlIDJlMjhlZWM5M2I3YThiOGIgXS0tLQ0KWyAgMzEzLjA1NjU3OF0gLS0t
LS0tLS0tLS0tWyBjdXQgaGVyZSBdLS0tLS0tLS0tLS0tDQpbICAzMTMuMDU2NjAxXSBXQVJO
SU5HOiBhdCBkcml2ZXJzL25ldC94ZW4tbmV0ZnJvbnQuYzo0NjUgeGVubmV0X3N0YXJ0X3ht
aXQrMHg3ZmUvMHg4NjAoKQ0KWyAgMzEzLjA1NjYyNF0gTW9kdWxlcyBsaW5rZWQgaW46DQpb
ICAzMTMuMDU2NjQxXSBQaWQ6IDE1MjMsIGNvbW06IHN5c2xvZ2QgVGFpbnRlZDogRyAgICAg
ICAgVyAgICAzLjYuMHByZS1yYzEtMjAxMjEwMTEgIzENClsgIDMxMy4wNTY2NjRdIENhbGwg
VHJhY2U6DQpbICAzMTMuMDU2Njc1XSAgPElSUT4gIFs8ZmZmZmZmZmY4MTA2NjRlYT5dIHdh
cm5fc2xvd3BhdGhfY29tbW9uKzB4N2EvMHhiMA0KWyAgMzEzLjA1NjcwOF0gIFs8ZmZmZmZm
ZmY4MTA2NjUzNT5dIHdhcm5fc2xvd3BhdGhfbnVsbCsweDE1LzB4MjANClsgIDMxMy4wNTY3
MDhdICBbPGZmZmZmZmZmODE0NmQ4OWU+XSB4ZW5uZXRfc3RhcnRfeG1pdCsweDdmZS8weDg2
MA0KWyAgMzEzLjA1NjcwOF0gIFs8ZmZmZmZmZmY4MTYxZjM0OT5dIGRldl9oYXJkX3N0YXJ0
X3htaXQrMHgyMDkvMHg0NjANClsgIDMxMy4wNTY3MDhdICBbPGZmZmZmZmZmODE2M2IwMzY+
XSBzY2hfZGlyZWN0X3htaXQrMHhmNi8weDI5MA0KWyAgMzEzLjA1NjcwOF0gIFs8ZmZmZmZm
ZmY4MTYxZjc0Nj5dIGRldl9xdWV1ZV94bWl0KzB4MWE2LzB4NWEwDQpbICAzMTMuMDU2NzA4
XSAgWzxmZmZmZmZmZjgxNjFmNWEwPl0gPyBkZXZfaGFyZF9zdGFydF94bWl0KzB4NDYwLzB4
NDYwDQpbICAzMTMuMDU2NzA4XSAgWzxmZmZmZmZmZjgxMGIxNDE3Pl0gPyBsb2NrX3JlbGVh
c2UrMHgxMTcvMHgyNTANClsgIDMxMy4wNTY3MDhdICBbPGZmZmZmZmZmODE2Yjk1MzY+XSBp
cF9maW5pc2hfb3V0cHV0KzB4MjI2LzB4NTMwDQpbICAzMTMuMDU2NzA4XSAgWzxmZmZmZmZm
ZjgxNmI5M2RkPl0gPyBpcF9maW5pc2hfb3V0cHV0KzB4Y2QvMHg1MzANClsgIDMxMy4wNTY3
MDhdICBbPGZmZmZmZmZmODE2Yjk4OTk+XSBpcF9vdXRwdXQrMHg1OS8weGUwDQpbICAzMTMu
MDU2NzA4XSAgWzxmZmZmZmZmZjgxNmI4M2I4Pl0gaXBfbG9jYWxfb3V0KzB4MjgvMHg5MA0K
WyAgMzEzLjA1NjcwOF0gIFs8ZmZmZmZmZmY4MTZiODk2Zj5dIGlwX3F1ZXVlX3htaXQrMHgx
N2YvMHg0YTANClsgIDMxMy4wNTY3MDhdICBbPGZmZmZmZmZmODE2Yjg3ZjA+XSA/IGlwX3Nl
bmRfdW5pY2FzdF9yZXBseSsweDM0MC8weDM0MA0KWyAgMzEzLjA1NjcwOF0gIFs8ZmZmZmZm
ZmY4MTBhMGJhNz5dID8gZ2V0bnN0aW1lb2ZkYXkrMHg0Ny8weGUwDQpbICAzMTMuMDU2NzA4
XSAgWzxmZmZmZmZmZjgxNjBmNGM5Pl0gPyBfX3NrYl9jbG9uZSsweDI5LzB4MTIwDQpbICAz
MTMuMDU2NzA4XSAgWzxmZmZmZmZmZjgxNmNlYTIwPl0gdGNwX3RyYW5zbWl0X3NrYisweDQw
MC8weDhkMA0KWyAgMzEzLjA1NjcwOF0gIFs8ZmZmZmZmZmY4MTZkMTEwNj5dIHRjcF9yZXRy
YW5zbWl0X3NrYisweDFjNi8weDVhMA0KWyAgMzEzLjA1NjcwOF0gIFs8ZmZmZmZmZmY4MTc0
NmNiNT5dID8gX3Jhd19zcGluX3VubG9ja19pcnFyZXN0b3JlKzB4NzUvMHhhMA0KWyAgMzEz
LjA1NjcwOF0gIFs8ZmZmZmZmZmY4MTZkMTY3ZT5dIHRjcF94bWl0X3JldHJhbnNtaXRfcXVl
dWUrMHgxOWUvMHgzMDANClsgIDMxMy4wNTY3MDhdICBbPGZmZmZmZmZmODE2Yzk5ZmY+XSB0
Y3BfZmFzdHJldHJhbnNfYWxlcnQrMHg5NGYvMHhjYjANClsgIDMxMy4wNTY3MDhdICBbPGZm
ZmZmZmZmODE2Y2E3MGM+XSB0Y3BfYWNrKzB4OWFjLzB4MTE1MA0KWyAgMzEzLjA1NjcwOF0g
IFs8ZmZmZmZmZmY4MTZjZDhjZT5dIHRjcF9yY3ZfZXN0YWJsaXNoZWQrMHgzOGUvMHg2NDAN
ClsgIDMxMy4wNTY3MDhdICBbPGZmZmZmZmZmODE2ZDVlZWY+XSA/IHRjcF92NF9yY3YrMHg2
Y2YvMHhiMTANClsgIDMxMy4wNTY3MDhdICBbPGZmZmZmZmZmODE2ZDU0ZDU+XSB0Y3BfdjRf
ZG9fcmN2KzB4MTM1LzB4NDgwDQpbICAzMTMuMDU2NzA4XSAgWzxmZmZmZmZmZjgxNzQ2MWQy
Pl0gPyBfcmF3X3NwaW5fbG9ja19uZXN0ZWQrMHg0Mi8weDUwDQpbICAzMTMuMDU2NzA4XSAg
WzxmZmZmZmZmZjgxNmQ1ZWVmPl0gPyB0Y3BfdjRfcmN2KzB4NmNmLzB4YjEwDQpbICAzMTMu
MDU2NzA4XSAgWzxmZmZmZmZmZjgxNmQ2MTdkPl0gdGNwX3Y0X3JjdisweDk1ZC8weGIxMA0K
WyAgMzEzLjA1NjcwOF0gIFs8ZmZmZmZmZmY4MTBiMGY4OD5dID8gbG9ja19hY3F1aXJlKzB4
ZDgvMHgxMDANClsgIDMxMy4wNTY3MDhdICBbPGZmZmZmZmZmODE2YjI5OTU+XSA/IGlwX2xv
Y2FsX2RlbGl2ZXJfZmluaXNoKzB4NDUvMHgyMzANClsgIDMxMy4wNTY3MDhdICBbPGZmZmZm
ZmZmODE2YjJhNmE+XSBpcF9sb2NhbF9kZWxpdmVyX2ZpbmlzaCsweDExYS8weDIzMA0KWyAg
MzEzLjA1NjcwOF0gIFs8ZmZmZmZmZmY4MTZiMjk5NT5dID8gaXBfbG9jYWxfZGVsaXZlcl9m
aW5pc2grMHg0NS8weDIzMA0KWyAgMzEzLjA1NjcwOF0gIFs8ZmZmZmZmZmY4MTZiMmJiOD5d
IGlwX2xvY2FsX2RlbGl2ZXIrMHgzOC8weDgwDQpbICAzMTMuMDU2NzA4XSAgWzxmZmZmZmZm
ZjgxNmIyMTdhPl0gaXBfcmN2X2ZpbmlzaCsweDE1YS8weDYzMA0KWyAgMzEzLjA1NjcwOF0g
IFs8ZmZmZmZmZmY4MTZiMjg2OD5dIGlwX3JjdisweDIxOC8weDMwMA0KWyAgMzEzLjA1Njcw
OF0gIFs8ZmZmZmZmZmY4MTYxYWM4ZD5dIF9fbmV0aWZfcmVjZWl2ZV9za2IrMHg2NWQvMHg4
ZDANClsgIDMxMy4wNTY3MDhdICBbPGZmZmZmZmZmODE2MWE3NzU+XSA/IF9fbmV0aWZfcmVj
ZWl2ZV9za2IrMHgxNDUvMHg4ZDANClsgIDMxMy4wNTY3MDhdICBbPGZmZmZmZmZmODEwYWQy
MmQ+XSA/IHRyYWNlX2hhcmRpcnFzX29uKzB4ZC8weDEwDQpbICAzMTMuMDU2NzA4XSAgWzxm
ZmZmZmZmZjgxMGY5OTczPl0gPyBmcmVlX2hvdF9jb2xkX3BhZ2UrMHgxYjMvMHgxZTANClsg
IDMxMy4wNTY3MDhdICBbPGZmZmZmZmZmODE2MWQxZjg+XSBuZXRpZl9yZWNlaXZlX3NrYisw
eDI4LzB4ZjANClsgIDMxMy4wNTY3MDhdICBbPGZmZmZmZmZmODE2MTJkMDM+XSA/IF9fcHNr
Yl9wdWxsX3RhaWwrMHgyNTMvMHgzNDANClsgIDMxMy4wNTY3MDhdICBbPGZmZmZmZmZmODE0
NmU0YzU+XSB4ZW5uZXRfcG9sbCsweGFkNS8weGUxMA0KWyAgMzEzLjA1NjcwOF0gIFs8ZmZm
ZmZmZmY4MTYxZGZhNj5dIG5ldF9yeF9hY3Rpb24rMHgxMzYvMHgyNjANClsgIDMxMy4wNTY3
MDhdICBbPGZmZmZmZmZmODEwNmUzODE+XSA/IF9fZG9fc29mdGlycSsweDcxLzB4MWEwDQpb
ICAzMTMuMDU2NzA4XSAgWzxmZmZmZmZmZjgxMDZlM2Q5Pl0gX19kb19zb2Z0aXJxKzB4Yzkv
MHgxYTANClsgIDMxMy4wNTY3MDhdICBbPGZmZmZmZmZmODE3NDhkM2M+XSBjYWxsX3NvZnRp
cnErMHgxYy8weDMwDQpbICAzMTMuMDU2NzA4XSAgWzxmZmZmZmZmZjgxMDBlZGI1Pl0gZG9f
c29mdGlycSsweDg1LzB4ZjANClsgIDMxMy4wNTY3MDhdICBbPGZmZmZmZmZmODEwNmUyNGU+
XSBpcnFfZXhpdCsweDllLzB4ZDANClsgIDMxMy4wNTY3MDhdICBbPGZmZmZmZmZmODEzMzlm
NWY+XSB4ZW5fZXZ0Y2huX2RvX3VwY2FsbCsweDJmLzB4NDANClsgIDMxMy4wNTY3MDhdICBb
PGZmZmZmZmZmODE3NDhkOWU+XSB4ZW5fZG9faHlwZXJ2aXNvcl9jYWxsYmFjaysweDFlLzB4
MzANClsgIDMxMy4wNTY3MDhdICA8RU9JPiAgWzxmZmZmZmZmZjgxMDAxMjJhPl0gPyB4ZW5f
aHlwZXJjYWxsX3hlbl92ZXJzaW9uKzB4YS8weDIwDQpbICAzMTMuMDU2NzA4XSAgWzxmZmZm
ZmZmZjgxMDAxMjJhPl0gPyB4ZW5faHlwZXJjYWxsX3hlbl92ZXJzaW9uKzB4YS8weDIwDQpb
ICAzMTMuMDU2NzA4XSAgWzxmZmZmZmZmZjgxMDA4NjRkPl0gPyB4ZW5fZm9yY2VfZXZ0Y2hu
X2NhbGxiYWNrKzB4ZC8weDEwDQpbICAzMTMuMDU2NzA4XSAgWzxmZmZmZmZmZjgxMDA4ZmYy
Pl0gPyBjaGVja19ldmVudHMrMHgxMi8weDIwDQpbICAzMTMuMDU2NzA4XSAgWzxmZmZmZmZm
ZjgxMDA4Zjk5Pl0gPyB4ZW5faXJxX2VuYWJsZV9kaXJlY3RfcmVsb2MrMHg0LzB4NA0KWyAg
MzEzLjA1NjcwOF0gIFs8ZmZmZmZmZmY4MTc0OTE0Nj5dID8gaWEzMl9jc3Rhcl90YXJnZXQr
MHgxNi8weDhjDQpbICAzMTMuMDU2NzA4XSAtLS1bIGVuZCB0cmFjZSAyZTI4ZWVjOTNiN2E4
YjhjIF0tLS0NClsgIDMxMy41NDAyMDBdIC0tLS0tLS0tLS0tLVsgY3V0IGhlcmUgXS0tLS0t
LS0tLS0tLQ0KWyAgMzEzLjU0MDIxOF0gV0FSTklORzogYXQgZHJpdmVycy9uZXQveGVuLW5l
dGZyb250LmM6NDY1IHhlbm5ldF9zdGFydF94bWl0KzB4N2ZlLzB4ODYwKCkNClsgIDMxMy41
NDAyNDBdIE1vZHVsZXMgbGlua2VkIGluOg0KWyAgMzEzLjU0MDI0Nl0gUGlkOiAwLCBjb21t
OiBzd2FwcGVyLzAgVGFpbnRlZDogRyAgICAgICAgVyAgICAzLjYuMHByZS1yYzEtMjAxMjEw
MTEgIzENClsgIDMxMy41NDAyNTJdIENhbGwgVHJhY2U6DQpbICAzMTMuNTQwMjU2XSAgPElS
UT4gIFs8ZmZmZmZmZmY4MTA2NjRlYT5dIHdhcm5fc2xvd3BhdGhfY29tbW9uKzB4N2EvMHhi
MA0KWyAgMzEzLjU0MDI2OV0gIFs8ZmZmZmZmZmY4MTA2NjUzNT5dIHdhcm5fc2xvd3BhdGhf
bnVsbCsweDE1LzB4MjANClsgIDMxMy41NDAyNzRdICBbPGZmZmZmZmZmODE0NmQ4OWU+XSB4
ZW5uZXRfc3RhcnRfeG1pdCsweDdmZS8weDg2MA0KWyAgMzEzLjU0MDI4M10gIFs8ZmZmZmZm
ZmY4MTYxZjM0OT5dIGRldl9oYXJkX3N0YXJ0X3htaXQrMHgyMDkvMHg0NjANClsgIDMxMy41
NDAyOTBdICBbPGZmZmZmZmZmODE2M2IwMzY+XSBzY2hfZGlyZWN0X3htaXQrMHhmNi8weDI5
MA0KWyAgMzEzLjU0MDI5NV0gIFs8ZmZmZmZmZmY4MTYxZjc0Nj5dIGRldl9xdWV1ZV94bWl0
KzB4MWE2LzB4NWEwDQpbICAzMTMuNTQwMzAxXSAgWzxmZmZmZmZmZjgxNjFmNWEwPl0gPyBk
ZXZfaGFyZF9zdGFydF94bWl0KzB4NDYwLzB4NDYwDQpbICAzMTMuNTQwMzA4XSAgWzxmZmZm
ZmZmZjgxMGIxNDE3Pl0gPyBsb2NrX3JlbGVhc2UrMHgxMTcvMHgyNTANClsgIDMxMy41NDAz
MTZdICBbPGZmZmZmZmZmODE2Yjk1MzY+XSBpcF9maW5pc2hfb3V0cHV0KzB4MjI2LzB4NTMw
DQpbICAzMTMuNTQwMzIxXSAgWzxmZmZmZmZmZjgxNmI5M2RkPl0gPyBpcF9maW5pc2hfb3V0
cHV0KzB4Y2QvMHg1MzANClsgIDMxMy41NDAzMjddICBbPGZmZmZmZmZmODE2Yjk4OTk+XSBp
cF9vdXRwdXQrMHg1OS8weGUwDQpbICAzMTMuNTQwMzMzXSAgWzxmZmZmZmZmZjgxNmI4M2I4
Pl0gaXBfbG9jYWxfb3V0KzB4MjgvMHg5MA0KWyAgMzEzLjU0MDMzOF0gIFs8ZmZmZmZmZmY4
MTZiODk2Zj5dIGlwX3F1ZXVlX3htaXQrMHgxN2YvMHg0YTANClsgIDMxMy41NDAzNDRdICBb
PGZmZmZmZmZmODE2Yjg3ZjA+XSA/IGlwX3NlbmRfdW5pY2FzdF9yZXBseSsweDM0MC8weDM0
MA0KWyAgMzEzLjU0MDM1MF0gIFs8ZmZmZmZmZmY4MTBhMGJhNz5dID8gZ2V0bnN0aW1lb2Zk
YXkrMHg0Ny8weGUwDQpbICAzMTMuNTQwMzU3XSAgWzxmZmZmZmZmZjgxNjBmNGM5Pl0gPyBf
X3NrYl9jbG9uZSsweDI5LzB4MTIwDQpbICAzMTMuNTQwMzYzXSAgWzxmZmZmZmZmZjgxNmNl
YTIwPl0gdGNwX3RyYW5zbWl0X3NrYisweDQwMC8weDhkMA0KWyAgMzEzLjU0MDM2OV0gIFs8
ZmZmZmZmZmY4MTZkMTEwNj5dIHRjcF9yZXRyYW5zbWl0X3NrYisweDFjNi8weDVhMA0KWyAg
MzEzLjU0MDM3NV0gIFs8ZmZmZmZmZmY4MTZkMzNiMD5dID8gdGNwX3dyaXRlX3RpbWVyX2hh
bmRsZXIrMHgxYTAvMHgxYTANClsgIDMxMy41NDAzODFdICBbPGZmZmZmZmZmODE2ZDJmMzg+
XSB0Y3BfcmV0cmFuc21pdF90aW1lcisweDM1OC8weDYzMA0KWyAgMzEzLjU0MDM4Nl0gIFs8
ZmZmZmZmZmY4MTZkMzM0ZD5dIHRjcF93cml0ZV90aW1lcl9oYW5kbGVyKzB4MTNkLzB4MWEw
DQpbICAzMTMuNTQwMzkyXSAgWzxmZmZmZmZmZjgxNmQzNDI4Pl0gdGNwX3dyaXRlX3RpbWVy
KzB4NzgvMHg4MA0KWyAgMzEzLjU0MDM5OF0gIFs8ZmZmZmZmZmY4MTA3M2Y3Yz5dIGNhbGxf
dGltZXJfZm4rMHg3Yy8weDEwMA0KWyAgMzEzLjU0MDQwM10gIFs8ZmZmZmZmZmY4MTA3M2Yw
MD5dID8gY2FzY2FkZSsweGEwLzB4YTANClsgIDMxMy41NDA0MDhdICBbPGZmZmZmZmZmODE2
ZDMzYjA+XSA/IHRjcF93cml0ZV90aW1lcl9oYW5kbGVyKzB4MWEwLzB4MWEwDQpbICAzMTMu
NTQwNDE0XSAgWzxmZmZmZmZmZjgxNmQzM2IwPl0gPyB0Y3Bfd3JpdGVfdGltZXJfaGFuZGxl
cisweDFhMC8weDFhMA0KWyAgMzEzLjU0MDQ2OF0gIFs8ZmZmZmZmZmY4MTA3NDIxNz5dIHJ1
bl90aW1lcl9zb2Z0aXJxKzB4MjE3LzB4MjUwDQpbICAzMTMuNTQwNDc1XSAgWzxmZmZmZmZm
ZjgxMDZlM2Q5Pl0gX19kb19zb2Z0aXJxKzB4YzkvMHgxYTANClsgIDMxMy41NDA0ODNdICBb
PGZmZmZmZmZmODE3NDhkM2M+XSBjYWxsX3NvZnRpcnErMHgxYy8weDMwDQpbICAzMTMuNTQw
NDkwXSAgWzxmZmZmZmZmZjgxMDBlZGI1Pl0gZG9fc29mdGlycSsweDg1LzB4ZjANClsgIDMx
My41NDA0OTVdICBbPGZmZmZmZmZmODEwNmUyNGU+XSBpcnFfZXhpdCsweDllLzB4ZDANClsg
IDMxMy41NDA1MDJdICBbPGZmZmZmZmZmODEzMzlmNWY+XSB4ZW5fZXZ0Y2huX2RvX3VwY2Fs
bCsweDJmLzB4NDANClsgIDMxMy41NDA1MDhdICBbPGZmZmZmZmZmODE3NDhkOWU+XSB4ZW5f
ZG9faHlwZXJ2aXNvcl9jYWxsYmFjaysweDFlLzB4MzANClsgIDMxMy41NDA1MTNdICA8RU9J
PiAgWzxmZmZmZmZmZjgxMDAxM2FhPl0gPyB4ZW5faHlwZXJjYWxsX3NjaGVkX29wKzB4YS8w
eDIwDQpbICAzMTMuNTQwNTIzXSAgWzxmZmZmZmZmZjgxMDAxM2FhPl0gPyB4ZW5faHlwZXJj
YWxsX3NjaGVkX29wKzB4YS8weDIwDQpbICAzMTMuNTQwNTI5XSAgWzxmZmZmZmZmZjgxMDA4
NjkwPl0gPyB4ZW5fc2FmZV9oYWx0KzB4MTAvMHgyMA0KWyAgMzEzLjU0MDUzNV0gIFs8ZmZm
ZmZmZmY4MTAxNjBkMD5dID8gZGVmYXVsdF9pZGxlKzB4NDAvMHg5MA0KWyAgMzEzLjU0MDU0
MV0gIFs8ZmZmZmZmZmY4MTAxNjQ4Nj5dID8gY3B1X2lkbGUrMHg5Ni8weGYwDQpbICAzMTMu
NTQwNTQ2XSAgWzxmZmZmZmZmZjgxNzIyZDNjPl0gPyByZXN0X2luaXQrMHhiYy8weGQwDQpb
ICAzMTMuNTQwNTUxXSAgWzxmZmZmZmZmZjgxNzIyYzgwPl0gPyBjc3VtX3BhcnRpYWxfY29w
eV9nZW5lcmljKzB4MTcwLzB4MTcwDQpbICAzMTMuNTQwNTYwXSAgWzxmZmZmZmZmZjgxY2Uw
ZGYyPl0gPyBzdGFydF9rZXJuZWwrMHgzOTAvMHgzOWQNClsgIDMxMy41NDA1NjZdICBbPGZm
ZmZmZmZmODFjZTA4ODI+XSA/IGtlcm5lbF9pbml0KzB4MjBiLzB4MjBiDQpbICAzMTMuNTQw
NTcxXSAgWzxmZmZmZmZmZjgxY2UwMzU2Pl0gPyB4ODZfNjRfc3RhcnRfcmVzZXJ2YXRpb25z
KzB4MTMxLzB4MTM2DQpbICAzMTMuNTQwNTkwXSAgWzxmZmZmZmZmZjgxY2UzZDYwPl0gPyB4
ZW5fc3RhcnRfa2VybmVsKzB4NzBkLzB4NzBmDQpbICAzMTMuNTQwNTk1XSAtLS1bIGVuZCB0
cmFjZSAyZTI4ZWVjOTNiN2E4YjhkIF0tLS0NClsgIDMxNC41MTY4MTddIC0tLS0tLS0tLS0t
LVsgY3V0IGhlcmUgXS0tLS0tLS0tLS0tLQ0KWyAgMzE0LjUxNjg0NV0gV0FSTklORzogYXQg
ZHJpdmVycy9uZXQveGVuLW5ldGZyb250LmM6NDY1IHhlbm5ldF9zdGFydF94bWl0KzB4N2Zl
LzB4ODYwKCkNClsgIDMxNC41MTY4NThdIE1vZHVsZXMgbGlua2VkIGluOg0KWyAgMzE0LjUx
Njg3MF0gUGlkOiAwLCBjb21tOiBzd2FwcGVyLzAgVGFpbnRlZDogRyAgICAgICAgVyAgICAz
LjYuMHByZS1yYzEtMjAxMjEwMTEgIzENClsgIDMxNC41MTY4ODNdIENhbGwgVHJhY2U6DQpb
ICAzMTQuNTE2ODkwXSAgPElSUT4gIFs8ZmZmZmZmZmY4MTA2NjRlYT5dIHdhcm5fc2xvd3Bh
dGhfY29tbW9uKzB4N2EvMHhiMA0KWyAgMzE0LjUxNjkxMV0gIFs8ZmZmZmZmZmY4MTA2NjUz
NT5dIHdhcm5fc2xvd3BhdGhfbnVsbCsweDE1LzB4MjANClsgIDMxNC41MTY5MjNdICBbPGZm
ZmZmZmZmODE0NmQ4OWU+XSB4ZW5uZXRfc3RhcnRfeG1pdCsweDdmZS8weDg2MA0KWyAgMzE0
LjUxNjkzN10gIFs8ZmZmZmZmZmY4MTYxZjM0OT5dIGRldl9oYXJkX3N0YXJ0X3htaXQrMHgy
MDkvMHg0NjANClsgIDMxNC41MTY5NDldICBbPGZmZmZmZmZmODE2M2IwMzY+XSBzY2hfZGly
ZWN0X3htaXQrMHhmNi8weDI5MA0KWyAgMzE0LjUxNjk2MF0gIFs8ZmZmZmZmZmY4MTYxZjc0
Nj5dIGRldl9xdWV1ZV94bWl0KzB4MWE2LzB4NWEwDQpbICAzMTQuNTE2OTcyXSAgWzxmZmZm
ZmZmZjgxNjFmNWEwPl0gPyBkZXZfaGFyZF9zdGFydF94bWl0KzB4NDYwLzB4NDYwDQpbICAz
MTQuNTE2OTg0XSAgWzxmZmZmZmZmZjgxMGIxNDE3Pl0gPyBsb2NrX3JlbGVhc2UrMHgxMTcv
MHgyNTANClsgIDMxNC41MTY5OTldICBbPGZmZmZmZmZmODE2Yjk1MzY+XSBpcF9maW5pc2hf
b3V0cHV0KzB4MjI2LzB4NTMwDQpbICAzMTQuNTE3MDExXSAgWzxmZmZmZmZmZjgxNmI5M2Rk
Pl0gPyBpcF9maW5pc2hfb3V0cHV0KzB4Y2QvMHg1MzANClsgIDMxNC41MTcwMjNdICBbPGZm
ZmZmZmZmODE2Yjk4OTk+XSBpcF9vdXRwdXQrMHg1OS8weGUwDQpbICAzMTQuNTE3MDMzXSAg
WzxmZmZmZmZmZjgxNmI4M2I4Pl0gaXBfbG9jYWxfb3V0KzB4MjgvMHg5MA0KWyAgMzE0LjUx
NzA0NF0gIFs8ZmZmZmZmZmY4MTZiODk2Zj5dIGlwX3F1ZXVlX3htaXQrMHgxN2YvMHg0YTAN
ClsgIDMxNC41MTcwNTVdICBbPGZmZmZmZmZmODE2Yjg3ZjA+XSA/IGlwX3NlbmRfdW5pY2Fz
dF9yZXBseSsweDM0MC8weDM0MA0KWyAgMzE0LjUxNzA2N10gIFs8ZmZmZmZmZmY4MTBhMGJh
Nz5dID8gZ2V0bnN0aW1lb2ZkYXkrMHg0Ny8weGUwDQpbICAzMTQuNTE3MDc5XSAgWzxmZmZm
ZmZmZjgxNjBmNGM5Pl0gPyBfX3NrYl9jbG9uZSsweDI5LzB4MTIwDQpbICAzMTQuNTE3MDkw
XSAgWzxmZmZmZmZmZjgxNmNlYTIwPl0gdGNwX3RyYW5zbWl0X3NrYisweDQwMC8weDhkMA0K
WyAgMzE0LjUxNzEwMl0gIFs8ZmZmZmZmZmY4MTZkMTEwNj5dIHRjcF9yZXRyYW5zbWl0X3Nr
YisweDFjNi8weDVhMA0KWyAgMzE0LjUxNzExNF0gIFs8ZmZmZmZmZmY4MTZkMzNiMD5dID8g
dGNwX3dyaXRlX3RpbWVyX2hhbmRsZXIrMHgxYTAvMHgxYTANClsgIDMxNC41MTcxMjZdICBb
PGZmZmZmZmZmODE2ZDJmMzg+XSB0Y3BfcmV0cmFuc21pdF90aW1lcisweDM1OC8weDYzMA0K
WyAgMzE0LjUxNzEzOF0gIFs8ZmZmZmZmZmY4MTZkMzM0ZD5dIHRjcF93cml0ZV90aW1lcl9o
YW5kbGVyKzB4MTNkLzB4MWEwDQpbICAzMTQuNTE3MTUwXSAgWzxmZmZmZmZmZjgxNmQzNDI4
Pl0gdGNwX3dyaXRlX3RpbWVyKzB4NzgvMHg4MA0KWyAgMzE0LjUxNzE2MV0gIFs8ZmZmZmZm
ZmY4MTA3M2Y3Yz5dIGNhbGxfdGltZXJfZm4rMHg3Yy8weDEwMA0KWyAgMzE0LjUxNzE3MV0g
IFs8ZmZmZmZmZmY4MTA3M2YwMD5dID8gY2FzY2FkZSsweGEwLzB4YTANClsgIDMxNC41MTcx
ODFdICBbPGZmZmZmZmZmODE2ZDMzYjA+XSA/IHRjcF93cml0ZV90aW1lcl9oYW5kbGVyKzB4
MWEwLzB4MWEwDQpbICAzMTQuNTE3MTk0XSAgWzxmZmZmZmZmZjgxNmQzM2IwPl0gPyB0Y3Bf
d3JpdGVfdGltZXJfaGFuZGxlcisweDFhMC8weDFhMA0KWyAgMzE0LjUxNzIwNV0gIFs8ZmZm
ZmZmZmY4MTA3NDIxNz5dIHJ1bl90aW1lcl9zb2Z0aXJxKzB4MjE3LzB4MjUwDQpbICAzMTQu
NTE3MjE4XSAgWzxmZmZmZmZmZjgxMDZlM2Q5Pl0gX19kb19zb2Z0aXJxKzB4YzkvMHgxYTAN
ClsgIDMxNC41MTcyMzBdICBbPGZmZmZmZmZmODE3NDhkM2M+XSBjYWxsX3NvZnRpcnErMHgx
Yy8weDMwDQpbICAzMTQuNTE3MjQxXSAgWzxmZmZmZmZmZjgxMDBlZGI1Pl0gZG9fc29mdGly
cSsweDg1LzB4ZjANClsgIDMxNC41MTcyNTJdICBbPGZmZmZmZmZmODEwNmUyNGU+XSBpcnFf
ZXhpdCsweDllLzB4ZDANClsgIDMxNC41MTcyNjVdICBbPGZmZmZmZmZmODEzMzlmNWY+XSB4
ZW5fZXZ0Y2huX2RvX3VwY2FsbCsweDJmLzB4NDANClsgIDMxNC41MTcyNzddICBbPGZmZmZm
ZmZmODE3NDhkOWU+XSB4ZW5fZG9faHlwZXJ2aXNvcl9jYWxsYmFjaysweDFlLzB4MzANClsg
IDMxNC41MTcyODZdICA8RU9JPiAgWzxmZmZmZmZmZjgxMDAxM2FhPl0gPyB4ZW5faHlwZXJj
YWxsX3NjaGVkX29wKzB4YS8weDIwDQpbICAzMTQuNTE3MzA2XSAgWzxmZmZmZmZmZjgxMDAx
M2FhPl0gPyB4ZW5faHlwZXJjYWxsX3NjaGVkX29wKzB4YS8weDIwDQpbICAzMTQuNTE3MzE4
XSAgWzxmZmZmZmZmZjgxMDA4NjkwPl0gPyB4ZW5fc2FmZV9oYWx0KzB4MTAvMHgyMA0KWyAg
MzE0LjUxNzMyOV0gIFs8ZmZmZmZmZmY4MTAxNjBkMD5dID8gZGVmYXVsdF9pZGxlKzB4NDAv
MHg5MA0KWyAgMzE0LjUxNzM0MF0gIFs8ZmZmZmZmZmY4MTAxNjQ4Nj5dID8gY3B1X2lkbGUr
MHg5Ni8weGYwDQpbICAzMTQuNTE3MzUxXSAgWzxmZmZmZmZmZjgxNzIyZDNjPl0gPyByZXN0
X2luaXQrMHhiYy8weGQwDQpbICAzMTQuNTE3MzYxXSAgWzxmZmZmZmZmZjgxNzIyYzgwPl0g
PyBjc3VtX3BhcnRpYWxfY29weV9nZW5lcmljKzB4MTcwLzB4MTcwDQpbICAzMTQuNTE3Mzc1
XSAgWzxmZmZmZmZmZjgxY2UwZGYyPl0gPyBzdGFydF9rZXJuZWwrMHgzOTAvMHgzOWQNClsg
IDMxNC41MTczODZdICBbPGZmZmZmZmZmODFjZTA4ODI+XSA/IGtlcm5lbF9pbml0KzB4MjBi
LzB4MjBiDQpbICAzMTQuNTE3Mzk3XSAgWzxmZmZmZmZmZjgxY2UwMzU2Pl0gPyB4ODZfNjRf
c3RhcnRfcmVzZXJ2YXRpb25zKzB4MTMxLzB4MTM2DQpbICAzMTQuNTE3NDEwXSAgWzxmZmZm
ZmZmZjgxY2UzZDYwPl0gPyB4ZW5fc3RhcnRfa2VybmVsKzB4NzBkLzB4NzBmDQpbICAzMTQu
NTE3NDIxXSAtLS1bIGVuZCB0cmFjZSAyZTI4ZWVjOTNiN2E4YjhlIF0tLS0NClsgIDMxNi40
NjY4MzhdIC0tLS0tLS0tLS0tLVsgY3V0IGhlcmUgXS0tLS0tLS0tLS0tLQ0KWyAgMzE2LjQ2
Njg2N10gV0FSTklORzogYXQgZHJpdmVycy9uZXQveGVuLW5ldGZyb250LmM6NDY1IHhlbm5l
dF9zdGFydF94bWl0KzB4N2ZlLzB4ODYwKCkNClsgIDMxNi40NjY4ODFdIE1vZHVsZXMgbGlu
a2VkIGluOg0KWyAgMzE2LjQ2Njg5NF0gUGlkOiAwLCBjb21tOiBzd2FwcGVyLzAgVGFpbnRl
ZDogRyAgICAgICAgVyAgICAzLjYuMHByZS1yYzEtMjAxMjEwMTEgIzENClsgIDMxNi40NjY5
MDZdIENhbGwgVHJhY2U6DQpbICAzMTYuNDY2OTEyXSAgPElSUT4gIFs8ZmZmZmZmZmY4MTA2
NjRlYT5dIHdhcm5fc2xvd3BhdGhfY29tbW9uKzB4N2EvMHhiMA0KWyAgMzE2LjQ2NjkzNF0g
IFs8ZmZmZmZmZmY4MTA2NjUzNT5dIHdhcm5fc2xvd3BhdGhfbnVsbCsweDE1LzB4MjANClsg
IDMxNi40NjY5NDZdICBbPGZmZmZmZmZmODE0NmQ4OWU+XSB4ZW5uZXRfc3RhcnRfeG1pdCsw
eDdmZS8weDg2MA0KWyAgMzE2LjQ2Njk2MF0gIFs8ZmZmZmZmZmY4MTYxZjM0OT5dIGRldl9o
YXJkX3N0YXJ0X3htaXQrMHgyMDkvMHg0NjANClsgIDMxNi40NjY5NzNdICBbPGZmZmZmZmZm
ODE2M2IwMzY+XSBzY2hfZGlyZWN0X3htaXQrMHhmNi8weDI5MA0KWyAgMzE2LjQ2Njk4NF0g
IFs8ZmZmZmZmZmY4MTYxZjc0Nj5dIGRldl9xdWV1ZV94bWl0KzB4MWE2LzB4NWEwDQpbICAz
MTYuNDY2OTk5XSAgWzxmZmZmZmZmZjgxNjFmNWEwPl0gPyBkZXZfaGFyZF9zdGFydF94bWl0
KzB4NDYwLzB4NDYwDQpbICAzMTYuNDY3MDEyXSAgWzxmZmZmZmZmZjgxMGIxNDE3Pl0gPyBs
b2NrX3JlbGVhc2UrMHgxMTcvMHgyNTANClsgIDMxNi40NjcwMjVdICBbPGZmZmZmZmZmODE2
Yjk1MzY+XSBpcF9maW5pc2hfb3V0cHV0KzB4MjI2LzB4NTMwDQpbICAzMTYuNDY3MDM3XSAg
WzxmZmZmZmZmZjgxNmI5M2RkPl0gPyBpcF9maW5pc2hfb3V0cHV0KzB4Y2QvMHg1MzANClsg
IDMxNi40NjcwNDldICBbPGZmZmZmZmZmODE2Yjk4OTk+XSBpcF9vdXRwdXQrMHg1OS8weGUw
DQpbICAzMTYuNDY3MDYxXSAgWzxmZmZmZmZmZjgxNmI4M2I4Pl0gaXBfbG9jYWxfb3V0KzB4
MjgvMHg5MA0KWyAgMzE2LjQ2NzA3MV0gIFs8ZmZmZmZmZmY4MTZiODk2Zj5dIGlwX3F1ZXVl
X3htaXQrMHgxN2YvMHg0YTANClsgIDMxNi40NjcwODNdICBbPGZmZmZmZmZmODE2Yjg3ZjA+
XSA/IGlwX3NlbmRfdW5pY2FzdF9yZXBseSsweDM0MC8weDM0MA0KWyAgMzE2LjQ2NzA5Nl0g
IFs8ZmZmZmZmZmY4MTBhMGJhNz5dID8gZ2V0bnN0aW1lb2ZkYXkrMHg0Ny8weGUwDQpbICAz
MTYuNDY3MTA4XSAgWzxmZmZmZmZmZjgxNjBmNGM5Pl0gPyBfX3NrYl9jbG9uZSsweDI5LzB4
MTIwDQpbICAzMTYuNDY3MTE5XSAgWzxmZmZmZmZmZjgxNmNlYTIwPl0gdGNwX3RyYW5zbWl0
X3NrYisweDQwMC8weDhkMA0KWyAgMzE2LjQ2NzEzMV0gIFs8ZmZmZmZmZmY4MTZkMTEwNj5d
IHRjcF9yZXRyYW5zbWl0X3NrYisweDFjNi8weDVhMA0KWyAgMzE2LjQ2NzE0M10gIFs8ZmZm
ZmZmZmY4MTZkMzNiMD5dID8gdGNwX3dyaXRlX3RpbWVyX2hhbmRsZXIrMHgxYTAvMHgxYTAN
ClsgIDMxNi40NjcxNTVdICBbPGZmZmZmZmZmODE2ZDJmMzg+XSB0Y3BfcmV0cmFuc21pdF90
aW1lcisweDM1OC8weDYzMA0KWyAgMzE2LjQ2NzE2Nl0gIFs8ZmZmZmZmZmY4MTZkMzM0ZD5d
IHRjcF93cml0ZV90aW1lcl9oYW5kbGVyKzB4MTNkLzB4MWEwDQpbICAzMTYuNDY3MTc4XSAg
WzxmZmZmZmZmZjgxNmQzNDI4Pl0gdGNwX3dyaXRlX3RpbWVyKzB4NzgvMHg4MA0KWyAgMzE2
LjQ2NzE5MF0gIFs8ZmZmZmZmZmY4MTA3M2Y3Yz5dIGNhbGxfdGltZXJfZm4rMHg3Yy8weDEw
MA0KWyAgMzE2LjQ2NzIwMF0gIFs8ZmZmZmZmZmY4MTA3M2YwMD5dID8gY2FzY2FkZSsweGEw
LzB4YTANClsgIDMxNi40NjcyMTFdICBbPGZmZmZmZmZmODE2ZDMzYjA+XSA/IHRjcF93cml0
ZV90aW1lcl9oYW5kbGVyKzB4MWEwLzB4MWEwDQpbICAzMTYuNDY3MjIzXSAgWzxmZmZmZmZm
ZjgxNmQzM2IwPl0gPyB0Y3Bfd3JpdGVfdGltZXJfaGFuZGxlcisweDFhMC8weDFhMA0KWyAg
MzE2LjQ2NzIzNV0gIFs8ZmZmZmZmZmY4MTA3NDIxNz5dIHJ1bl90aW1lcl9zb2Z0aXJxKzB4
MjE3LzB4MjUwDQpbICAzMTYuNDY3MjQ4XSAgWzxmZmZmZmZmZjgxMDZlM2Q5Pl0gX19kb19z
b2Z0aXJxKzB4YzkvMHgxYTANClsgIDMxNi40NjcyNjBdICBbPGZmZmZmZmZmODE3NDhkM2M+
XSBjYWxsX3NvZnRpcnErMHgxYy8weDMwDQpbICAzMTYuNDY3MjcwXSAgWzxmZmZmZmZmZjgx
MDBlZGI1Pl0gZG9fc29mdGlycSsweDg1LzB4ZjANClsgIDMxNi40NjcyODFdICBbPGZmZmZm
ZmZmODEwNmUyNGU+XSBpcnFfZXhpdCsweDllLzB4ZDANClsgIDMxNi40NjcyOTNdICBbPGZm
ZmZmZmZmODEzMzlmNWY+XSB4ZW5fZXZ0Y2huX2RvX3VwY2FsbCsweDJmLzB4NDANClsgIDMx
Ni40NjczMDRdICBbPGZmZmZmZmZmODE3NDhkOWU+XSB4ZW5fZG9faHlwZXJ2aXNvcl9jYWxs
YmFjaysweDFlLzB4MzANClsgIDMxNi40NjczMTRdICA8RU9JPiAgWzxmZmZmZmZmZjgxMDAx
M2FhPl0gPyB4ZW5faHlwZXJjYWxsX3NjaGVkX29wKzB4YS8weDIwDQpbICAzMTYuNDY3MzM0
XSAgWzxmZmZmZmZmZjgxMDAxM2FhPl0gPyB4ZW5faHlwZXJjYWxsX3NjaGVkX29wKzB4YS8w
eDIwDQpbICAzMTYuNDY3MzQ3XSAgWzxmZmZmZmZmZjgxMDA4NjkwPl0gPyB4ZW5fc2FmZV9o
YWx0KzB4MTAvMHgyMA0KWyAgMzE2LjQ2NzM1OV0gIFs8ZmZmZmZmZmY4MTAxNjBkMD5dID8g
ZGVmYXVsdF9pZGxlKzB4NDAvMHg5MA0KWyAgMzE2LjQ2NzM2OV0gIFs8ZmZmZmZmZmY4MTAx
NjQ4Nj5dID8gY3B1X2lkbGUrMHg5Ni8weGYwDQpbICAzMTYuNDY3MzgwXSAgWzxmZmZmZmZm
ZjgxNzIyZDNjPl0gPyByZXN0X2luaXQrMHhiYy8weGQwDQpbICAzMTYuNDY3MzkwXSAgWzxm
ZmZmZmZmZjgxNzIyYzgwPl0gPyBjc3VtX3BhcnRpYWxfY29weV9nZW5lcmljKzB4MTcwLzB4
MTcwDQpbICAzMTYuNDY3NDAzXSAgWzxmZmZmZmZmZjgxY2UwZGYyPl0gPyBzdGFydF9rZXJu
ZWwrMHgzOTAvMHgzOWQNClsgIDMxNi40Njc0MTVdICBbPGZmZmZmZmZmODFjZTA4ODI+XSA/
IGtlcm5lbF9pbml0KzB4MjBiLzB4MjBiDQpbICAzMTYuNDY3NDI2XSAgWzxmZmZmZmZmZjgx
Y2UwMzU2Pl0gPyB4ODZfNjRfc3RhcnRfcmVzZXJ2YXRpb25zKzB4MTMxLzB4MTM2DQpbICAz
MTYuNDY3NDM5XSAgWzxmZmZmZmZmZjgxY2UzZDYwPl0gPyB4ZW5fc3RhcnRfa2VybmVsKzB4
NzBkLzB4NzBmDQpbICAzMTYuNDY3NDQ5XSAtLS1bIGVuZCB0cmFjZSAyZTI4ZWVjOTNiN2E4
YjhmIF0tLS0NClsgIDMyMC4zNzM0NDVdIC0tLS0tLS0tLS0tLVsgY3V0IGhlcmUgXS0tLS0t
LS0tLS0tLQ0KWyAgMzIwLjM3MzQ2NV0gV0FSTklORzogYXQgZHJpdmVycy9uZXQveGVuLW5l
dGZyb250LmM6NDY1IHhlbm5ldF9zdGFydF94bWl0KzB4N2ZlLzB4ODYwKCkNClsgIDMyMC4z
NzM0NzJdIE1vZHVsZXMgbGlua2VkIGluOg0KWyAgMzIwLjM3MzQ3OF0gUGlkOiAwLCBjb21t
OiBzd2FwcGVyLzAgVGFpbnRlZDogRyAgICAgICAgVyAgICAzLjYuMHByZS1yYzEtMjAxMjEw
MTEgIzENClsgIDMyMC4zNzM0ODldIENhbGwgVHJhY2U6DQpbICAzMjAuMzczNDkyXSAgPElS
UT4gIFs8ZmZmZmZmZmY4MTA2NjRlYT5dIHdhcm5fc2xvd3BhdGhfY29tbW9uKzB4N2EvMHhi
MA0KWyAgMzIwLjM3MzUwNV0gIFs8ZmZmZmZmZmY4MTA2NjUzNT5dIHdhcm5fc2xvd3BhdGhf
bnVsbCsweDE1LzB4MjANClsgIDMyMC4zNzM1MTFdICBbPGZmZmZmZmZmODE0NmQ4OWU+XSB4
ZW5uZXRfc3RhcnRfeG1pdCsweDdmZS8weDg2MA0KWyAgMzIwLjM3MzUxOV0gIFs8ZmZmZmZm
ZmY4MTYxZjM0OT5dIGRldl9oYXJkX3N0YXJ0X3htaXQrMHgyMDkvMHg0NjANClsgIDMyMC4z
NzM1MjZdICBbPGZmZmZmZmZmODE2M2IwMzY+XSBzY2hfZGlyZWN0X3htaXQrMHhmNi8weDI5
MA0KWyAgMzIwLjM3MzUzMl0gIFs8ZmZmZmZmZmY4MTYxZjc0Nj5dIGRldl9xdWV1ZV94bWl0
KzB4MWE2LzB4NWEwDQpbICAzMjAuMzczNTM4XSAgWzxmZmZmZmZmZjgxNjFmNWEwPl0gPyBk
ZXZfaGFyZF9zdGFydF94bWl0KzB4NDYwLzB4NDYwDQpbICAzMjAuMzczNTQ0XSAgWzxmZmZm
ZmZmZjgxMGIxNDE3Pl0gPyBsb2NrX3JlbGVhc2UrMHgxMTcvMHgyNTANClsgIDMyMC4zNzM1
NTJdICBbPGZmZmZmZmZmODE2Yjk1MzY+XSBpcF9maW5pc2hfb3V0cHV0KzB4MjI2LzB4NTMw
DQpbICAzMjAuMzczNTU3XSAgWzxmZmZmZmZmZjgxNmI5M2RkPl0gPyBpcF9maW5pc2hfb3V0
cHV0KzB4Y2QvMHg1MzANClsgIDMyMC4zNzM1NjRdICBbPGZmZmZmZmZmODE2Yjk4OTk+XSBp
cF9vdXRwdXQrMHg1OS8weGUwDQpbICAzMjAuMzczNTcwXSAgWzxmZmZmZmZmZjgxNmI4M2I4
Pl0gaXBfbG9jYWxfb3V0KzB4MjgvMHg5MA0KWyAgMzIwLjM3MzU3NV0gIFs8ZmZmZmZmZmY4
MTZiODk2Zj5dIGlwX3F1ZXVlX3htaXQrMHgxN2YvMHg0YTANClsgIDMyMC4zNzM1ODFdICBb
PGZmZmZmZmZmODE2Yjg3ZjA+XSA/IGlwX3NlbmRfdW5pY2FzdF9yZXBseSsweDM0MC8weDM0
MA0KWyAgMzIwLjM3MzU4N10gIFs8ZmZmZmZmZmY4MTBhMGJhNz5dID8gZ2V0bnN0aW1lb2Zk
YXkrMHg0Ny8weGUwDQpbICAzMjAuMzczNTk0XSAgWzxmZmZmZmZmZjgxNjBmNGM5Pl0gPyBf
X3NrYl9jbG9uZSsweDI5LzB4MTIwDQpbICAzMjAuMzczNjAwXSAgWzxmZmZmZmZmZjgxNmNl
YTIwPl0gdGNwX3RyYW5zbWl0X3NrYisweDQwMC8weDhkMA0KWyAgMzIwLjM3MzYwNl0gIFs8
ZmZmZmZmZmY4MTZkMTEwNj5dIHRjcF9yZXRyYW5zbWl0X3NrYisweDFjNi8weDVhMA0KWyAg
MzIwLjM3MzYxM10gIFs8ZmZmZmZmZmY4MTZkMzNiMD5dID8gdGNwX3dyaXRlX3RpbWVyX2hh
bmRsZXIrMHgxYTAvMHgxYTANClsgIDMyMC4zNzM2MTldICBbPGZmZmZmZmZmODE2ZDJmMzg+
XSB0Y3BfcmV0cmFuc21pdF90aW1lcisweDM1OC8weDYzMA0KWyAgMzIwLjM3MzYyNV0gIFs8
ZmZmZmZmZmY4MTZkMzM0ZD5dIHRjcF93cml0ZV90aW1lcl9oYW5kbGVyKzB4MTNkLzB4MWEw
DQpbICAzMjAuMzczNjMxXSAgWzxmZmZmZmZmZjgxNmQzNDI4Pl0gdGNwX3dyaXRlX3RpbWVy
KzB4NzgvMHg4MA0KWyAgMzIwLjM3MzY0MF0gIFs8ZmZmZmZmZmY4MTA3M2Y3Yz5dIGNhbGxf
dGltZXJfZm4rMHg3Yy8weDEwMA0KWyAgMzIwLjM3MzY0N10gIFs8ZmZmZmZmZmY4MTA3M2Yw
MD5dID8gY2FzY2FkZSsweGEwLzB4YTANClsgIDMyMC4zNzM2NTNdICBbPGZmZmZmZmZmODE2
ZDMzYjA+XSA/IHRjcF93cml0ZV90aW1lcl9oYW5kbGVyKzB4MWEwLzB4MWEwDQpbICAzMjAu
MzczNjU5XSAgWzxmZmZmZmZmZjgxNmQzM2IwPl0gPyB0Y3Bfd3JpdGVfdGltZXJfaGFuZGxl
cisweDFhMC8weDFhMA0KWyAgMzIwLjM3MzY2NV0gIFs8ZmZmZmZmZmY4MTA3NDIxNz5dIHJ1
bl90aW1lcl9zb2Z0aXJxKzB4MjE3LzB4MjUwDQpbICAzMjAuMzczNjcyXSAgWzxmZmZmZmZm
ZjgxMDZlM2Q5Pl0gX19kb19zb2Z0aXJxKzB4YzkvMHgxYTANClsgIDMyMC4zNzM2NzldICBb
PGZmZmZmZmZmODE3NDhkM2M+XSBjYWxsX3NvZnRpcnErMHgxYy8weDMwDQpbICAzMjAuMzcz
Njg1XSAgWzxmZmZmZmZmZjgxMDBlZGI1Pl0gZG9fc29mdGlycSsweDg1LzB4ZjANClsgIDMy
MC4zNzM2OTBdICBbPGZmZmZmZmZmODEwNmUyNGU+XSBpcnFfZXhpdCsweDllLzB4ZDANClsg
IDMyMC4zNzM2OTddICBbPGZmZmZmZmZmODEzMzlmNWY+XSB4ZW5fZXZ0Y2huX2RvX3VwY2Fs
bCsweDJmLzB4NDANClsgIDMyMC4zNzM3MDNdICBbPGZmZmZmZmZmODE3NDhkOWU+XSB4ZW5f
ZG9faHlwZXJ2aXNvcl9jYWxsYmFjaysweDFlLzB4MzANClsgIDMyMC4zNzM3MDhdICA8RU9J
PiAgWzxmZmZmZmZmZjgxMDAxM2FhPl0gPyB4ZW5faHlwZXJjYWxsX3NjaGVkX29wKzB4YS8w
eDIwDQpbICAzMjAuMzczNzE4XSAgWzxmZmZmZmZmZjgxMDAxM2FhPl0gPyB4ZW5faHlwZXJj
YWxsX3NjaGVkX29wKzB4YS8weDIwDQpbICAzMjAuMzczNzI3XSAgWzxmZmZmZmZmZjgxMDA4
NjkwPl0gPyB4ZW5fc2FmZV9oYWx0KzB4MTAvMHgyMA0KWyAgMzIwLjM3MzczM10gIFs8ZmZm
ZmZmZmY4MTAxNjBkMD5dID8gZGVmYXVsdF9pZGxlKzB4NDAvMHg5MA0KWyAgMzIwLjM3Mzcz
OV0gIFs8ZmZmZmZmZmY4MTAxNjQ4Nj5dID8gY3B1X2lkbGUrMHg5Ni8weGYwDQpbICAzMjAu
MzczNzQ0XSAgWzxmZmZmZmZmZjgxNzIyZDNjPl0gPyByZXN0X2luaXQrMHhiYy8weGQwDQpb
ICAzMjAuMzczNzQ5XSAgWzxmZmZmZmZmZjgxNzIyYzgwPl0gPyBjc3VtX3BhcnRpYWxfY29w
eV9nZW5lcmljKzB4MTcwLzB4MTcwDQpbICAzMjAuMzczNzU4XSAgWzxmZmZmZmZmZjgxY2Uw
ZGYyPl0gPyBzdGFydF9rZXJuZWwrMHgzOTAvMHgzOWQNClsgIDMyMC4zNzM3NjRdICBbPGZm
ZmZmZmZmODFjZTA4ODI+XSA/IGtlcm5lbF9pbml0KzB4MjBiLzB4MjBiDQpbICAzMjAuMzcz
NzY5XSAgWzxmZmZmZmZmZjgxY2UwMzU2Pl0gPyB4ODZfNjRfc3RhcnRfcmVzZXJ2YXRpb25z
KzB4MTMxLzB4MTM2DQpbICAzMjAuMzczNzc2XSAgWzxmZmZmZmZmZjgxY2UzZDYwPl0gPyB4
ZW5fc3RhcnRfa2VybmVsKzB4NzBkLzB4NzBmDQpbICAzMjAuMzczNzgyXSAtLS1bIGVuZCB0
cmFjZSAyZTI4ZWVjOTNiN2E4YjkwIF0tLS0NClsgIDMyOC4xODY5MDBdIC0tLS0tLS0tLS0t
LVsgY3V0IGhlcmUgXS0tLS0tLS0tLS0tLQ0KWyAgMzI4LjE4Njk0OF0gV0FSTklORzogYXQg
ZHJpdmVycy9uZXQveGVuLW5ldGZyb250LmM6NDY1IHhlbm5ldF9zdGFydF94bWl0KzB4N2Zl
LzB4ODYwKCkNClsgIDMyOC4xODY5NzRdIE1vZHVsZXMgbGlua2VkIGluOg0KWyAgMzI4LjE4
Njk5Nl0gUGlkOiAwLCBjb21tOiBzd2FwcGVyLzAgVGFpbnRlZDogRyAgICAgICAgVyAgICAz
LjYuMHByZS1yYzEtMjAxMjEwMTEgIzENClsgIDMyOC4xODcwMjBdIENhbGwgVHJhY2U6DQpb
ICAzMjguMTg3MDMzXSAgPElSUT4gIFs8ZmZmZmZmZmY4MTA2NjRlYT5dIHdhcm5fc2xvd3Bh
dGhfY29tbW9uKzB4N2EvMHhiMA0KWyAgMzI4LjE4NzA3NF0gIFs8ZmZmZmZmZmY4MTA2NjUz
NT5dIHdhcm5fc2xvd3BhdGhfbnVsbCsweDE1LzB4MjANClsgIDMyOC4xODcwOTddICBbPGZm
ZmZmZmZmODE0NmQ4OWU+XSB4ZW5uZXRfc3RhcnRfeG1pdCsweDdmZS8weDg2MA0KWyAgMzI4
LjE4NzEyNF0gIFs8ZmZmZmZmZmY4MTYxZjM0OT5dIGRldl9oYXJkX3N0YXJ0X3htaXQrMHgy
MDkvMHg0NjANClsgIDMyOC4xODcxNDhdICBbPGZmZmZmZmZmODE2M2IwMzY+XSBzY2hfZGly
ZWN0X3htaXQrMHhmNi8weDI5MA0KWyAgMzI4LjE4NzE3MV0gIFs8ZmZmZmZmZmY4MTYxZjc0
Nj5dIGRldl9xdWV1ZV94bWl0KzB4MWE2LzB4NWEwDQpbICAzMjguMTg3MTkzXSAgWzxmZmZm
ZmZmZjgxNjFmNWEwPl0gPyBkZXZfaGFyZF9zdGFydF94bWl0KzB4NDYwLzB4NDYwDQpbICAz
MjguMTg3MjE4XSAgWzxmZmZmZmZmZjgxMGIxNDE3Pl0gPyBsb2NrX3JlbGVhc2UrMHgxMTcv
MHgyNTANClsgIDMyOC4xODcyNDJdICBbPGZmZmZmZmZmODE2Yjk1MzY+XSBpcF9maW5pc2hf
b3V0cHV0KzB4MjI2LzB4NTMwDQpbICAzMjguMTg3MjY4XSAgWzxmZmZmZmZmZjgxNmI5M2Rk
Pl0gPyBpcF9maW5pc2hfb3V0cHV0KzB4Y2QvMHg1MzANClsgIDMyOC4xODcyOTFdICBbPGZm
ZmZmZmZmODE2Yjk4OTk+XSBpcF9vdXRwdXQrMHg1OS8weGUwDQpbICAzMjguMTg3MzE2XSAg
WzxmZmZmZmZmZjgxNmI4M2I4Pl0gaXBfbG9jYWxfb3V0KzB4MjgvMHg5MA0KWyAgMzI4LjE4
NzM0Ml0gIFs8ZmZmZmZmZmY4MTZiODk2Zj5dIGlwX3F1ZXVlX3htaXQrMHgxN2YvMHg0YTAN
ClsgIDMyOC4xODczNjRdICBbPGZmZmZmZmZmODE2Yjg3ZjA+XSA/IGlwX3NlbmRfdW5pY2Fz
dF9yZXBseSsweDM0MC8weDM0MA0KWyAgMzI4LjE4NzM4OV0gIFs8ZmZmZmZmZmY4MTBhMGJh
Nz5dID8gZ2V0bnN0aW1lb2ZkYXkrMHg0Ny8weGUwDQpbICAzMjguMTg3NDEyXSAgWzxmZmZm
ZmZmZjgxNjBmNGM5Pl0gPyBfX3NrYl9jbG9uZSsweDI5LzB4MTIwDQpbICAzMjguMTg3NDM0
XSAgWzxmZmZmZmZmZjgxNmNlYTIwPl0gdGNwX3RyYW5zbWl0X3NrYisweDQwMC8weDhkMA0K
WyAgMzI4LjE4NzQ1N10gIFs8ZmZmZmZmZmY4MTZkMTEwNj5dIHRjcF9yZXRyYW5zbWl0X3Nr
YisweDFjNi8weDVhMA0KWyAgMzI4LjE4NzQ4MV0gIFs8ZmZmZmZmZmY4MTZkMzNiMD5dID8g
dGNwX3dyaXRlX3RpbWVyX2hhbmRsZXIrMHgxYTAvMHgxYTANClsgIDMyOC4xODc1MDVdICBb
PGZmZmZmZmZmODE2ZDJmMzg+XSB0Y3BfcmV0cmFuc21pdF90aW1lcisweDM1OC8weDYzMA0K
WyAgMzI4LjE4NzUyOF0gIFs8ZmZmZmZmZmY4MTZkMzM0ZD5dIHRjcF93cml0ZV90aW1lcl9o
YW5kbGVyKzB4MTNkLzB4MWEwDQpbICAzMjguMTg3NTUxXSAgWzxmZmZmZmZmZjgxNmQzNDI4
Pl0gdGNwX3dyaXRlX3RpbWVyKzB4NzgvMHg4MA0KWyAgMzI4LjE4NzU3NF0gIFs8ZmZmZmZm
ZmY4MTA3M2Y3Yz5dIGNhbGxfdGltZXJfZm4rMHg3Yy8weDEwMA0KWyAgMzI4LjE4NzU5NF0g
IFs8ZmZmZmZmZmY4MTA3M2YwMD5dID8gY2FzY2FkZSsweGEwLzB4YTANClsgIDMyOC4xODc2
MTVdICBbPGZmZmZmZmZmODE2ZDMzYjA+XSA/IHRjcF93cml0ZV90aW1lcl9oYW5kbGVyKzB4
MWEwLzB4MWEwDQpbICAzMjguMTg3NjQwXSAgWzxmZmZmZmZmZjgxNmQzM2IwPl0gPyB0Y3Bf
d3JpdGVfdGltZXJfaGFuZGxlcisweDFhMC8weDFhMA0KWyAgMzI4LjE4NzY2M10gIFs8ZmZm
ZmZmZmY4MTA3NDIxNz5dIHJ1bl90aW1lcl9zb2Z0aXJxKzB4MjE3LzB4MjUwDQpbICAzMjgu
MTg3Njg4XSAgWzxmZmZmZmZmZjgxMDZlM2Q5Pl0gX19kb19zb2Z0aXJxKzB4YzkvMHgxYTAN
ClsgIDMyOC4xODc3MTFdICBbPGZmZmZmZmZmODE3NDhkM2M+XSBjYWxsX3NvZnRpcnErMHgx
Yy8weDMwDQpbICAzMjguMTg3NzMyXSAgWzxmZmZmZmZmZjgxMDBlZGI1Pl0gZG9fc29mdGly
cSsweDg1LzB4ZjANClsgIDMyOC4xODc3NTNdICBbPGZmZmZmZmZmODEwNmUyNGU+XSBpcnFf
ZXhpdCsweDllLzB4ZDANClsgIDMyOC4xODc3NzhdICBbPGZmZmZmZmZmODEzMzlmNWY+XSB4
ZW5fZXZ0Y2huX2RvX3VwY2FsbCsweDJmLzB4NDANClsgIDMyOC4xODc4MDFdICBbPGZmZmZm
ZmZmODE3NDhkOWU+XSB4ZW5fZG9faHlwZXJ2aXNvcl9jYWxsYmFjaysweDFlLzB4MzANClsg
IDMyOC4xODc4MjBdICA8RU9JPiAgWzxmZmZmZmZmZjgxMDAxM2FhPl0gPyB4ZW5faHlwZXJj
YWxsX3NjaGVkX29wKzB4YS8weDIwDQpbICAzMjguMTg3ODU5XSAgWzxmZmZmZmZmZjgxMDAx
M2FhPl0gPyB4ZW5faHlwZXJjYWxsX3NjaGVkX29wKzB4YS8weDIwDQpbICAzMjguMTg3ODgz
XSAgWzxmZmZmZmZmZjgxMDA4NjkwPl0gPyB4ZW5fc2FmZV9oYWx0KzB4MTAvMHgyMA0KWyAg
MzI4LjE4NzkwNV0gIFs8ZmZmZmZmZmY4MTAxNjBkMD5dID8gZGVmYXVsdF9pZGxlKzB4NDAv
MHg5MA0KWyAgMzI4LjE4NzkyN10gIFs8ZmZmZmZmZmY4MTAxNjQ4Nj5dID8gY3B1X2lkbGUr
MHg5Ni8weGYwDQpbICAzMjguMTg3OTQ3XSAgWzxmZmZmZmZmZjgxNzIyZDNjPl0gPyByZXN0
X2luaXQrMHhiYy8weGQwDQpbICAzMjguMTg3OTY3XSAgWzxmZmZmZmZmZjgxNzIyYzgwPl0g
PyBjc3VtX3BhcnRpYWxfY29weV9nZW5lcmljKzB4MTcwLzB4MTcwDQpbICAzMjguMTg3OTk0
XSAgWzxmZmZmZmZmZjgxY2UwZGYyPl0gPyBzdGFydF9rZXJuZWwrMHgzOTAvMHgzOWQNClsg
IDMyOC4xODgwMTddICBbPGZmZmZmZmZmODFjZTA4ODI+XSA/IGtlcm5lbF9pbml0KzB4MjBi
LzB4MjBiDQpbICAzMjguMTg4MDQwXSAgWzxmZmZmZmZmZjgxY2UwMzU2Pl0gPyB4ODZfNjRf
c3RhcnRfcmVzZXJ2YXRpb25zKzB4MTMxLzB4MTM2DQpbICAzMjguMTg4MDY1XSAgWzxmZmZm
ZmZmZjgxY2UzZDYwPl0gPyB4ZW5fc3RhcnRfa2VybmVsKzB4NzBkLzB4NzBmDQpbICAzMjgu
MTg4MDg3XSAtLS1bIGVuZCB0cmFjZSAyZTI4ZWVjOTNiN2E4YjkxIF0tLS0NClsgIDM0My43
ODY4ODNdIC0tLS0tLS0tLS0tLVsgY3V0IGhlcmUgXS0tLS0tLS0tLS0tLQ0KWyAgMzQzLjc4
NjkzNF0gV0FSTklORzogYXQgZHJpdmVycy9uZXQveGVuLW5ldGZyb250LmM6NDY1IHhlbm5l
dF9zdGFydF94bWl0KzB4N2ZlLzB4ODYwKCkNClsgIDM0My43ODY5NjBdIE1vZHVsZXMgbGlu
a2VkIGluOg0KWyAgMzQzLjc4Njk4Ml0gUGlkOiAwLCBjb21tOiBzd2FwcGVyLzAgVGFpbnRl
ZDogRyAgICAgICAgVyAgICAzLjYuMHByZS1yYzEtMjAxMjEwMTEgIzENClsgIDM0My43ODcw
MDZdIENhbGwgVHJhY2U6DQpbICAzNDMuNzg3MDE5XSAgPElSUT4gIFs8ZmZmZmZmZmY4MTA2
NjRlYT5dIHdhcm5fc2xvd3BhdGhfY29tbW9uKzB4N2EvMHhiMA0KWyAgMzQzLjc4NzA2MF0g
IFs8ZmZmZmZmZmY4MTA2NjUzNT5dIHdhcm5fc2xvd3BhdGhfbnVsbCsweDE1LzB4MjANClsg
IDM0My43ODcwODNdICBbPGZmZmZmZmZmODE0NmQ4OWU+XSB4ZW5uZXRfc3RhcnRfeG1pdCsw
eDdmZS8weDg2MA0KWyAgMzQzLjc4NzExMF0gIFs8ZmZmZmZmZmY4MTYxZjM0OT5dIGRldl9o
YXJkX3N0YXJ0X3htaXQrMHgyMDkvMHg0NjANClsgIDM0My43ODcxMzVdICBbPGZmZmZmZmZm
ODE2M2IwMzY+XSBzY2hfZGlyZWN0X3htaXQrMHhmNi8weDI5MA0KWyAgMzQzLjc4NzE1N10g
IFs8ZmZmZmZmZmY4MTYxZjc0Nj5dIGRldl9xdWV1ZV94bWl0KzB4MWE2LzB4NWEwDQpbICAz
NDMuNzg3MTgwXSAgWzxmZmZmZmZmZjgxNjFmNWEwPl0gPyBkZXZfaGFyZF9zdGFydF94bWl0
KzB4NDYwLzB4NDYwDQpbICAzNDMuNzg3MjAzXSAgWzxmZmZmZmZmZjgxNjI5YTc3Pl0gbmVp
Z2hfcmVzb2x2ZV9vdXRwdXQrMHgxMjcvMHgyNTANClsgIDM0My43ODcyMjldICBbPGZmZmZm
ZmZmODE2Yjk2YWQ+XSBpcF9maW5pc2hfb3V0cHV0KzB4MzlkLzB4NTMwDQpbICAzNDMuNzg3
MjUyXSAgWzxmZmZmZmZmZjgxNmI5M2RkPl0gPyBpcF9maW5pc2hfb3V0cHV0KzB4Y2QvMHg1
MzANClsgIDM0My43ODcyNzddICBbPGZmZmZmZmZmODE2Yjk4OTk+XSBpcF9vdXRwdXQrMHg1
OS8weGUwDQpbICAzNDMuNzg3Mjk4XSAgWzxmZmZmZmZmZjgxNmI4M2I4Pl0gaXBfbG9jYWxf
b3V0KzB4MjgvMHg5MA0KWyAgMzQzLjc4NzMyMF0gIFs8ZmZmZmZmZmY4MTZiODk2Zj5dIGlw
X3F1ZXVlX3htaXQrMHgxN2YvMHg0YTANClsgIDM0My43ODczNDJdICBbPGZmZmZmZmZmODE2
Yjg3ZjA+XSA/IGlwX3NlbmRfdW5pY2FzdF9yZXBseSsweDM0MC8weDM0MA0KWyAgMzQzLjc4
NzM2N10gIFs8ZmZmZmZmZmY4MTBhMGJhNz5dID8gZ2V0bnN0aW1lb2ZkYXkrMHg0Ny8weGUw
DQpbICAzNDMuNzg3MzkwXSAgWzxmZmZmZmZmZjgxNjBmNGM5Pl0gPyBfX3NrYl9jbG9uZSsw
eDI5LzB4MTIwDQpbICAzNDMuNzg3NDEyXSAgWzxmZmZmZmZmZjgxNmNlYTIwPl0gdGNwX3Ry
YW5zbWl0X3NrYisweDQwMC8weDhkMA0KWyAgMzQzLjc4NzQzNV0gIFs8ZmZmZmZmZmY4MTZk
MTEwNj5dIHRjcF9yZXRyYW5zbWl0X3NrYisweDFjNi8weDVhMA0KWyAgMzQzLjc4NzQ1OV0g
IFs8ZmZmZmZmZmY4MTZkMzNiMD5dID8gdGNwX3dyaXRlX3RpbWVyX2hhbmRsZXIrMHgxYTAv
MHgxYTANClsgIDM0My43ODc0ODJdICBbPGZmZmZmZmZmODE2ZDJmMzg+XSB0Y3BfcmV0cmFu
c21pdF90aW1lcisweDM1OC8weDYzMA0KWyAgMzQzLjc4NzUwNl0gIFs8ZmZmZmZmZmY4MTZk
MzM0ZD5dIHRjcF93cml0ZV90aW1lcl9oYW5kbGVyKzB4MTNkLzB4MWEwDQpbICAzNDMuNzg3
NTI5XSAgWzxmZmZmZmZmZjgxNmQzNDI4Pl0gdGNwX3dyaXRlX3RpbWVyKzB4NzgvMHg4MA0K
WyAgMzQzLjc4NzU1MF0gIFs8ZmZmZmZmZmY4MTA3M2Y3Yz5dIGNhbGxfdGltZXJfZm4rMHg3
Yy8weDEwMA0KWyAgMzQzLjc4NzU3MV0gIFs8ZmZmZmZmZmY4MTA3M2YwMD5dID8gY2FzY2Fk
ZSsweGEwLzB4YTANClsgIDM0My43ODc1OTFdICBbPGZmZmZmZmZmODE2ZDMzYjA+XSA/IHRj
cF93cml0ZV90aW1lcl9oYW5kbGVyKzB4MWEwLzB4MWEwDQpbICAzNDMuNzg3NjE1XSAgWzxm
ZmZmZmZmZjgxNmQzM2IwPl0gPyB0Y3Bfd3JpdGVfdGltZXJfaGFuZGxlcisweDFhMC8weDFh
MA0KWyAgMzQzLjc4NzYzOF0gIFs8ZmZmZmZmZmY4MTA3NDIxNz5dIHJ1bl90aW1lcl9zb2Z0
aXJxKzB4MjE3LzB4MjUwDQpbICAzNDMuNzg3NjYzXSAgWzxmZmZmZmZmZjgxMDZlM2Q5Pl0g
X19kb19zb2Z0aXJxKzB4YzkvMHgxYTANClsgIDM0My43ODc2ODZdICBbPGZmZmZmZmZmODE3
NDhkM2M+XSBjYWxsX3NvZnRpcnErMHgxYy8weDMwDQpbICAzNDMuNzg3NzA3XSAgWzxmZmZm
ZmZmZjgxMDBlZGI1Pl0gZG9fc29mdGlycSsweDg1LzB4ZjANClsgIDM0My43ODc3MjldICBb
PGZmZmZmZmZmODEwNmUyNGU+XSBpcnFfZXhpdCsweDllLzB4ZDANClsgIDM0My43ODc3NTJd
ICBbPGZmZmZmZmZmODEzMzlmNWY+XSB4ZW5fZXZ0Y2huX2RvX3VwY2FsbCsweDJmLzB4NDAN
ClsgIDM0My43ODc3NzRdICBbPGZmZmZmZmZmODE3NDhkOWU+XSB4ZW5fZG9faHlwZXJ2aXNv
cl9jYWxsYmFjaysweDFlLzB4MzANClsgIDM0My43ODc3OTNdICA8RU9JPiAgWzxmZmZmZmZm
ZjgxMDAxM2FhPl0gPyB4ZW5faHlwZXJjYWxsX3NjaGVkX29wKzB4YS8weDIwDQpbICAzNDMu
Nzg3ODMwXSAgWzxmZmZmZmZmZjgxMDAxM2FhPl0gPyB4ZW5faHlwZXJjYWxsX3NjaGVkX29w
KzB4YS8weDIwDQpbICAzNDMuNzg3ODU1XSAgWzxmZmZmZmZmZjgxMDA4NjkwPl0gPyB4ZW5f
c2FmZV9oYWx0KzB4MTAvMHgyMA0KWyAgMzQzLjc4Nzg3N10gIFs8ZmZmZmZmZmY4MTAxNjBk
MD5dID8gZGVmYXVsdF9pZGxlKzB4NDAvMHg5MA0KWyAgMzQzLjc4Nzg5OF0gIFs8ZmZmZmZm
ZmY4MTAxNjQ4Nj5dID8gY3B1X2lkbGUrMHg5Ni8weGYwDQpbICAzNDMuNzg3OTE4XSAgWzxm
ZmZmZmZmZjgxNzIyZDNjPl0gPyByZXN0X2luaXQrMHhiYy8weGQwDQpbICAzNDMuNzg3OTM4
XSAgWzxmZmZmZmZmZjgxNzIyYzgwPl0gPyBjc3VtX3BhcnRpYWxfY29weV9nZW5lcmljKzB4
MTcwLzB4MTcwDQpbICAzNDMuNzg3OTY0XSAgWzxmZmZmZmZmZjgxY2UwZGYyPl0gPyBzdGFy
dF9rZXJuZWwrMHgzOTAvMHgzOWQNClsgIDM0My43ODc5ODddICBbPGZmZmZmZmZmODFjZTA4
ODI+XSA/IGtlcm5lbF9pbml0KzB4MjBiLzB4MjBiDQpbICAzNDMuNzg4MDExXSAgWzxmZmZm
ZmZmZjgxY2UwMzU2Pl0gPyB4ODZfNjRfc3RhcnRfcmVzZXJ2YXRpb25zKzB4MTMxLzB4MTM2
DQpbICAzNDMuNzg4MDM1XSAgWzxmZmZmZmZmZjgxY2UzZDYwPl0gPyB4ZW5fc3RhcnRfa2Vy
bmVsKzB4NzBkLzB4NzBmDQpbICAzNDMuNzg4MDU2XSAtLS1bIGVuZCB0cmFjZSAyZTI4ZWVj
OTNiN2E4YjkyIF0tLS0NClsgIDM2OS4xMzgxMDhdIC0tLS0tLS0tLS0tLVsgY3V0IGhlcmUg
XS0tLS0tLS0tLS0tLQ0KWyAgMzY5LjEzODE0OF0gV0FSTklORzogYXQgZHJpdmVycy9uZXQv
eGVuLW5ldGZyb250LmM6NDY1IHhlbm5ldF9zdGFydF94bWl0KzB4N2ZlLzB4ODYwKCkNClsg
IDM2OS4xMzgxNTldIE1vZHVsZXMgbGlua2VkIGluOg0KWyAgMzY5LjEzODE2NV0gUGlkOiAy
MTY5LCBjb21tOiBzc2hkIFRhaW50ZWQ6IEcgICAgICAgIFcgICAgMy42LjBwcmUtcmMxLTIw
MTIxMDExICMxDQpbICAzNjkuMTM4MTcyXSBDYWxsIFRyYWNlOg0KWyAgMzY5LjEzODE3OV0g
IFs8ZmZmZmZmZmY4MTA2NjRlYT5dIHdhcm5fc2xvd3BhdGhfY29tbW9uKzB4N2EvMHhiMA0K
WyAgMzY5LjEzODE4Nl0gIFs8ZmZmZmZmZmY4MTA2NjUzNT5dIHdhcm5fc2xvd3BhdGhfbnVs
bCsweDE1LzB4MjANClsgIDM2OS4xMzgxOTFdICBbPGZmZmZmZmZmODE0NmQ4OWU+XSB4ZW5u
ZXRfc3RhcnRfeG1pdCsweDdmZS8weDg2MA0KWyAgMzY5LjEzODE5OV0gIFs8ZmZmZmZmZmY4
MTYxZjM0OT5dIGRldl9oYXJkX3N0YXJ0X3htaXQrMHgyMDkvMHg0NjANClsgIDM2OS4xMzgy
MDVdICBbPGZmZmZmZmZmODE2M2IwMzY+XSBzY2hfZGlyZWN0X3htaXQrMHhmNi8weDI5MA0K
WyAgMzY5LjEzODIxMV0gIFs8ZmZmZmZmZmY4MTYxZjc0Nj5dIGRldl9xdWV1ZV94bWl0KzB4
MWE2LzB4NWEwDQpbICAzNjkuMTM4MjE3XSAgWzxmZmZmZmZmZjgxNjFmNWEwPl0gPyBkZXZf
aGFyZF9zdGFydF94bWl0KzB4NDYwLzB4NDYwDQpbICAzNjkuMTM4MjIzXSAgWzxmZmZmZmZm
ZjgxMGFhOGU1Pl0gPyB0cmFjZV9zb2Z0aXJxc19vZmYrMHg4NS8weDFiMA0KWyAgMzY5LjEz
ODIzMV0gIFs8ZmZmZmZmZmY4MTZiOTUzNj5dIGlwX2ZpbmlzaF9vdXRwdXQrMHgyMjYvMHg1
MzANClsgIDM2OS4xMzgyMzZdICBbPGZmZmZmZmZmODE2YjkzZGQ+XSA/IGlwX2ZpbmlzaF9v
dXRwdXQrMHhjZC8weDUzMA0KWyAgMzY5LjEzODI0Ml0gIFs8ZmZmZmZmZmY4MTZiOTg5OT5d
IGlwX291dHB1dCsweDU5LzB4ZTANClsgIDM2OS4xMzgyNDddICBbPGZmZmZmZmZmODE2Yjgz
Yjg+XSBpcF9sb2NhbF9vdXQrMHgyOC8weDkwDQpbICAzNjkuMTM4MjUzXSAgWzxmZmZmZmZm
ZjgxNmI4OTZmPl0gaXBfcXVldWVfeG1pdCsweDE3Zi8weDRhMA0KWyAgMzY5LjEzODI1OF0g
IFs8ZmZmZmZmZmY4MTZiODdmMD5dID8gaXBfc2VuZF91bmljYXN0X3JlcGx5KzB4MzQwLzB4
MzQwDQpbICAzNjkuMTM4MjY1XSAgWzxmZmZmZmZmZjgxMGEwYmE3Pl0gPyBnZXRuc3RpbWVv
ZmRheSsweDQ3LzB4ZTANClsgIDM2OS4xMzgyNzFdICBbPGZmZmZmZmZmODE2MGY0Yzk+XSA/
IF9fc2tiX2Nsb25lKzB4MjkvMHgxMjANClsgIDM2OS4xMzgyNzddICBbPGZmZmZmZmZmODE2
Y2VhMjA+XSB0Y3BfdHJhbnNtaXRfc2tiKzB4NDAwLzB4OGQwDQpbICAzNjkuMTM4MjgzXSAg
WzxmZmZmZmZmZjgxNmQxOWZhPl0gdGNwX3dyaXRlX3htaXQrMHgyMWEvMHhhNTANClsgIDM2
OS4xMzgyODldICBbPGZmZmZmZmZmODE2ZDIyNWI+XSB0Y3BfcHVzaF9vbmUrMHgyYi8weDQw
DQpbICAzNjkuMTM4Mjk1XSAgWzxmZmZmZmZmZjgxNmMyZGVjPl0gdGNwX3NlbmRtc2crMHg4
ZGMvMHhlMjANClsgIDM2OS4xMzgzMDJdICBbPGZmZmZmZmZmODE2ZThmMTk+XSBpbmV0X3Nl
bmRtc2crMHhhOS8weDEwMA0KWyAgMzY5LjEzODMwN10gIFs8ZmZmZmZmZmY4MTZlOGU3MD5d
ID8gaW5ldF9hdXRvYmluZCsweDcwLzB4NzANClsgIDM2OS4xMzgzMTJdICBbPGZmZmZmZmZm
ODEwYjBmODg+XSA/IGxvY2tfYWNxdWlyZSsweGQ4LzB4MTAwDQpbICAzNjkuMTM4MzE5XSAg
WzxmZmZmZmZmZjgxNjA2MzBkPl0gc29ja19haW9fd3JpdGUrMHgxMmQvMHgxNDANClsgIDM2
OS4xMzgzMjZdICBbPGZmZmZmZmZmODExNDM1YjI+XSBkb19zeW5jX3dyaXRlKzB4YTIvMHhl
MA0KWyAgMzY5LjEzODMzMV0gIFs8ZmZmZmZmZmY4MTBhZDIyZD5dID8gdHJhY2VfaGFyZGly
cXNfb24rMHhkLzB4MTANClsgIDM2OS4xMzgzMzddICBbPGZmZmZmZmZmODExNDQxZDQ+XSB2
ZnNfd3JpdGUrMHgxNzQvMHgxOTANClsgIDM2OS4xMzgzNzZdICBbPGZmZmZmZmZmODExNDQy
ZmE+XSBzeXNfd3JpdGUrMHg1YS8weGEwDQpbICAzNjkuMTM4Mzg0XSAgWzxmZmZmZmZmZjgx
MmIzM2RlPl0gPyB0cmFjZV9oYXJkaXJxc19vbl90aHVuaysweDNhLzB4M2YNClsgIDM2OS4x
MzgzOTFdICBbPGZmZmZmZmZmODE3NDkxY2M+XSBjc3Rhcl9kaXNwYXRjaCsweDcvMHgyNg0K
WyAgMzY5LjEzODM5Nl0gLS0tWyBlbmQgdHJhY2UgMmUyOGVlYzkzYjdhOGI5MyBdLS0tDQpb
ICAzNjkuMTM4NDIyXSAtLS0tLS0tLS0tLS1bIGN1dCBoZXJlIF0tLS0tLS0tLS0tLS0NClsg
IDM2OS4xMzg0MjhdIFdBUk5JTkc6IGF0IGRyaXZlcnMvbmV0L3hlbi1uZXRmcm9udC5jOjQ2
NSB4ZW5uZXRfc3RhcnRfeG1pdCsweDdmZS8weDg2MCgpDQpbICAzNjkuMTM4NDM1XSBNb2R1
bGVzIGxpbmtlZCBpbjoNClsgIDM2OS4xMzg0MzldIFBpZDogMjE2OSwgY29tbTogc3NoZCBU
YWludGVkOiBHICAgICAgICBXICAgIDMuNi4wcHJlLXJjMS0yMDEyMTAxMSAjMQ0KWyAgMzY5
LjEzODQ0NV0gQ2FsbCBUcmFjZToNClsgIDM2OS4xMzg0NTBdICBbPGZmZmZmZmZmODEwNjY0
ZWE+XSB3YXJuX3Nsb3dwYXRoX2NvbW1vbisweDdhLzB4YjANClsgIDM2OS4xMzg0NTVdICBb
PGZmZmZmZmZmODEwNjY1MzU+XSB3YXJuX3Nsb3dwYXRoX251bGwrMHgxNS8weDIwDQpbICAz
NjkuMTM4NDYxXSAgWzxmZmZmZmZmZjgxNDZkODllPl0geGVubmV0X3N0YXJ0X3htaXQrMHg3
ZmUvMHg4NjANClsgIDM2OS4xMzg0NjhdICBbPGZmZmZmZmZmODE2MWYzNDk+XSBkZXZfaGFy
ZF9zdGFydF94bWl0KzB4MjA5LzB4NDYwDQpbICAzNjkuMTM4NDc0XSAgWzxmZmZmZmZmZjgx
NjNiMDM2Pl0gc2NoX2RpcmVjdF94bWl0KzB4ZjYvMHgyOTANClsgIDM2OS4xMzg0NzldICBb
PGZmZmZmZmZmODE2MWY3NDY+XSBkZXZfcXVldWVfeG1pdCsweDFhNi8weDVhMA0KWyAgMzY5
LjEzODQ4NV0gIFs8ZmZmZmZmZmY4MTYxZjVhMD5dID8gZGV2X2hhcmRfc3RhcnRfeG1pdCsw
eDQ2MC8weDQ2MA0KWyAgMzY5LjEzODQ5MV0gIFs8ZmZmZmZmZmY4MTBhYThlNT5dID8gdHJh
Y2Vfc29mdGlycXNfb2ZmKzB4ODUvMHgxYjANClsgIDM2OS4xMzg0OTddICBbPGZmZmZmZmZm
ODE2Yjk1MzY+XSBpcF9maW5pc2hfb3V0cHV0KzB4MjI2LzB4NTMwDQpbICAzNjkuMTM4NTAz
XSAgWzxmZmZmZmZmZjgxNmI5M2RkPl0gPyBpcF9maW5pc2hfb3V0cHV0KzB4Y2QvMHg1MzAN
ClsgIDM2OS4xMzg1MDldICBbPGZmZmZmZmZmODE2Yjk4OTk+XSBpcF9vdXRwdXQrMHg1OS8w
eGUwDQpbICAzNjkuMTM4NTE0XSAgWzxmZmZmZmZmZjgxNmI4M2I4Pl0gaXBfbG9jYWxfb3V0
KzB4MjgvMHg5MA0KWyAgMzY5LjEzODUyMF0gIFs8ZmZmZmZmZmY4MTZiODk2Zj5dIGlwX3F1
ZXVlX3htaXQrMHgxN2YvMHg0YTANClsgIDM2OS4xMzg1MjVdICBbPGZmZmZmZmZmODE2Yjg3
ZjA+XSA/IGlwX3NlbmRfdW5pY2FzdF9yZXBseSsweDM0MC8weDM0MA0KWyAgMzY5LjEzODUz
MV0gIFs8ZmZmZmZmZmY4MTBhMGJhNz5dID8gZ2V0bnN0aW1lb2ZkYXkrMHg0Ny8weGUwDQpb
ICAzNjkuMTM4NTM3XSAgWzxmZmZmZmZmZjgxNjBmNGM5Pl0gPyBfX3NrYl9jbG9uZSsweDI5
LzB4MTIwDQpbICAzNjkuMTM4NTQyXSAgWzxmZmZmZmZmZjgxNmNlYTIwPl0gdGNwX3RyYW5z
bWl0X3NrYisweDQwMC8weDhkMA0KWyAgMzY5LjEzODU0OF0gIFs8ZmZmZmZmZmY4MTZkMTlm
YT5dIHRjcF93cml0ZV94bWl0KzB4MjFhLzB4YTUwDQpbICAzNjkuMTM4NTU0XSAgWzxmZmZm
ZmZmZjgxNmQyMjlkPl0gX190Y3BfcHVzaF9wZW5kaW5nX2ZyYW1lcysweDJkLzB4OTANClsg
IDM2OS4xMzg1NjBdICBbPGZmZmZmZmZmODE2YzI2OTM+XSB0Y3Bfc2VuZG1zZysweDE4My8w
eGUyMA0KWyAgMzY5LjEzODU2Nl0gIFs8ZmZmZmZmZmY4MTZlOGYxOT5dIGluZXRfc2VuZG1z
ZysweGE5LzB4MTAwDQpbICAzNjkuMTM4NTcxXSAgWzxmZmZmZmZmZjgxNmU4ZTcwPl0gPyBp
bmV0X2F1dG9iaW5kKzB4NzAvMHg3MA0KWyAgMzY5LjEzODU3N10gIFs8ZmZmZmZmZmY4MTBi
MGY4OD5dID8gbG9ja19hY3F1aXJlKzB4ZDgvMHgxMDANClsgIDM2OS4xMzg1ODNdICBbPGZm
ZmZmZmZmODE2MDYzMGQ+XSBzb2NrX2Fpb193cml0ZSsweDEyZC8weDE0MA0KWyAgMzY5LjEz
ODU4OV0gIFs8ZmZmZmZmZmY4MTE0MzViMj5dIGRvX3N5bmNfd3JpdGUrMHhhMi8weGUwDQpb
ICAzNjkuMTM4NTk0XSAgWzxmZmZmZmZmZjgxMGFkMjJkPl0gPyB0cmFjZV9oYXJkaXJxc19v
bisweGQvMHgxMA0KWyAgMzY5LjEzODYwMF0gIFs8ZmZmZmZmZmY4MTE0NDFkND5dIHZmc193
cml0ZSsweDE3NC8weDE5MA0KWyAgMzY5LjEzODYwNV0gIFs8ZmZmZmZmZmY4MTE0NDJmYT5d
IHN5c193cml0ZSsweDVhLzB4YTANClsgIDM2OS4xMzg2MTFdICBbPGZmZmZmZmZmODEyYjMz
ZGU+XSA/IHRyYWNlX2hhcmRpcnFzX29uX3RodW5rKzB4M2EvMHgzZg0KWyAgMzY5LjEzODYx
N10gIFs8ZmZmZmZmZmY4MTc0OTFjYz5dIGNzdGFyX2Rpc3BhdGNoKzB4Ny8weDI2DQpbICAz
NjkuMTM4NjIxXSAtLS1bIGVuZCB0cmFjZSAyZTI4ZWVjOTNiN2E4Yjk0IF0tLS0NClsgIDM2
OS4xMzg2NDhdIC0tLS0tLS0tLS0tLVsgY3V0IGhlcmUgXS0tLS0tLS0tLS0tLQ0KWyAgMzY5
LjEzODY1M10gV0FSTklORzogYXQgZHJpdmVycy9uZXQveGVuLW5ldGZyb250LmM6NDY1IHhl
bm5ldF9zdGFydF94bWl0KzB4N2ZlLzB4ODYwKCkNClsgIDM2OS4xMzg2NTldIE1vZHVsZXMg
bGlua2VkIGluOg0KWyAgMzY5LjEzODY2NF0gUGlkOiAyMTY5LCBjb21tOiBzc2hkIFRhaW50
ZWQ6IEcgICAgICAgIFcgICAgMy42LjBwcmUtcmMxLTIwMTIxMDExICMxDQpbICAzNjkuMTM4
NjcwXSBDYWxsIFRyYWNlOg0KWyAgMzY5LjEzODY3NF0gIFs8ZmZmZmZmZmY4MTA2NjRlYT5d
IHdhcm5fc2xvd3BhdGhfY29tbW9uKzB4N2EvMHhiMA0KWyAgMzY5LjEzODY4MF0gIFs8ZmZm
ZmZmZmY4MTA2NjUzNT5dIHdhcm5fc2xvd3BhdGhfbnVsbCsweDE1LzB4MjANClsgIDM2OS4x
Mzg2ODZdICBbPGZmZmZmZmZmODE0NmQ4OWU+XSB4ZW5uZXRfc3RhcnRfeG1pdCsweDdmZS8w
eDg2MA0KWyAgMzY5LjEzODY5Ml0gIFs8ZmZmZmZmZmY4MTYxZjM0OT5dIGRldl9oYXJkX3N0
YXJ0X3htaXQrMHgyMDkvMHg0NjANClsgIDM2OS4xMzg2OThdICBbPGZmZmZmZmZmODE2M2Iw
MzY+XSBzY2hfZGlyZWN0X3htaXQrMHhmNi8weDI5MA0KWyAgMzY5LjEzODcwNF0gIFs8ZmZm
ZmZmZmY4MTYxZjc0Nj5dIGRldl9xdWV1ZV94bWl0KzB4MWE2LzB4NWEwDQpbICAzNjkuMTM4
NzA5XSAgWzxmZmZmZmZmZjgxNjFmNWEwPl0gPyBkZXZfaGFyZF9zdGFydF94bWl0KzB4NDYw
LzB4NDYwDQpbICAzNjkuMTM4NzE1XSAgWzxmZmZmZmZmZjgxMGFhOGU1Pl0gPyB0cmFjZV9z
b2Z0aXJxc19vZmYrMHg4NS8weDFiMA0KWyAgMzY5LjEzODcyMV0gIFs8ZmZmZmZmZmY4MTZi
OTUzNj5dIGlwX2ZpbmlzaF9vdXRwdXQrMHgyMjYvMHg1MzANClsgIDM2OS4xMzg3MjddICBb
PGZmZmZmZmZmODE2YjkzZGQ+XSA/IGlwX2ZpbmlzaF9vdXRwdXQrMHhjZC8weDUzMA0KWyAg
MzY5LjEzODczM10gIFs8ZmZmZmZmZmY4MTZiOTg5OT5dIGlwX291dHB1dCsweDU5LzB4ZTAN
ClsgIDM2OS4xMzg3MzldICBbPGZmZmZmZmZmODE2YjgzYjg+XSBpcF9sb2NhbF9vdXQrMHgy
OC8weDkwDQpbICAzNjkuMTM4NzQ0XSAgWzxmZmZmZmZmZjgxNmI4OTZmPl0gaXBfcXVldWVf
eG1pdCsweDE3Zi8weDRhMA0KWyAgMzY5LjEzODc1MF0gIFs8ZmZmZmZmZmY4MTZiODdmMD5d
ID8gaXBfc2VuZF91bmljYXN0X3JlcGx5KzB4MzQwLzB4MzQwDQpbICAzNjkuMTM4NzU2XSAg
WzxmZmZmZmZmZjgxMGEwYmE3Pl0gPyBnZXRuc3RpbWVvZmRheSsweDQ3LzB4ZTANClsgIDM2
OS4xMzg3NjJdICBbPGZmZmZmZmZmODE2MGY0Yzk+XSA/IF9fc2tiX2Nsb25lKzB4MjkvMHgx
MjANClsgIDM2OS4xMzg3NjddICBbPGZmZmZmZmZmODE2Y2VhMjA+XSB0Y3BfdHJhbnNtaXRf
c2tiKzB4NDAwLzB4OGQwDQpbICAzNjkuMTM4NzczXSAgWzxmZmZmZmZmZjgxNmQxOWZhPl0g
dGNwX3dyaXRlX3htaXQrMHgyMWEvMHhhNTANClsgIDM2OS4xMzg3NzldICBbPGZmZmZmZmZm
ODE2ZDIyOWQ+XSBfX3RjcF9wdXNoX3BlbmRpbmdfZnJhbWVzKzB4MmQvMHg5MA0KWyAgMzY5
LjEzODc4NV0gIFs8ZmZmZmZmZmY4MTZjMjY5Mz5dIHRjcF9zZW5kbXNnKzB4MTgzLzB4ZTIw
DQpbICAzNjkuMTM4NzkxXSAgWzxmZmZmZmZmZjgxNmU4ZjE5Pl0gaW5ldF9zZW5kbXNnKzB4
YTkvMHgxMDANClsgIDM2OS4xMzg3OTZdICBbPGZmZmZmZmZmODE2ZThlNzA+XSA/IGluZXRf
YXV0b2JpbmQrMHg3MC8weDcwDQpbICAzNjkuMTM4ODAyXSAgWzxmZmZmZmZmZjgxMGIwZjg4
Pl0gPyBsb2NrX2FjcXVpcmUrMHhkOC8weDEwMA0KWyAgMzY5LjEzODgwOF0gIFs8ZmZmZmZm
ZmY4MTYwNjMwZD5dIHNvY2tfYWlvX3dyaXRlKzB4MTJkLzB4MTQwDQpbICAzNjkuMTM4ODE0
XSAgWzxmZmZmZmZmZjgxMTQzNWIyPl0gZG9fc3luY193cml0ZSsweGEyLzB4ZTANClsgIDM2
OS4xMzg4MTldICBbPGZmZmZmZmZmODEwYWQyMmQ+XSA/IHRyYWNlX2hhcmRpcnFzX29uKzB4
ZC8weDEwDQpbICAzNjkuMTM4ODI1XSAgWzxmZmZmZmZmZjgxMTQ0MWQ0Pl0gdmZzX3dyaXRl
KzB4MTc0LzB4MTkwDQpbICAzNjkuMTM4ODMwXSAgWzxmZmZmZmZmZjgxMTQ0MmZhPl0gc3lz
X3dyaXRlKzB4NWEvMHhhMA0KWyAgMzY5LjEzODgzNl0gIFs8ZmZmZmZmZmY4MTJiMzNkZT5d
ID8gdHJhY2VfaGFyZGlycXNfb25fdGh1bmsrMHgzYS8weDNmDQpbICAzNjkuMTM4ODQyXSAg
WzxmZmZmZmZmZjgxNzQ5MWNjPl0gY3N0YXJfZGlzcGF0Y2grMHg3LzB4MjYNClsgIDM2OS4x
Mzg4NDddIC0tLVsgZW5kIHRyYWNlIDJlMjhlZWM5M2I3YThiOTUgXS0tLQ0KWyAgMzY5LjU3
MTc4NV0gLS0tLS0tLS0tLS0tWyBjdXQgaGVyZSBdLS0tLS0tLS0tLS0tDQpbICAzNjkuNTcx
ODExXSBXQVJOSU5HOiBhdCBkcml2ZXJzL25ldC94ZW4tbmV0ZnJvbnQuYzo0NjUgeGVubmV0
X3N0YXJ0X3htaXQrMHg3ZmUvMHg4NjAoKQ0KWyAgMzY5LjU3MTgxOF0gTW9kdWxlcyBsaW5r
ZWQgaW46DQpbICAzNjkuNTcxODI1XSBQaWQ6IDAsIGNvbW06IHN3YXBwZXIvMCBUYWludGVk
OiBHICAgICAgICBXICAgIDMuNi4wcHJlLXJjMS0yMDEyMTAxMSAjMQ0KWyAgMzY5LjU3MTgz
Ml0gQ2FsbCBUcmFjZToNClsgIDM2OS41NzE4MzVdICA8SVJRPiAgWzxmZmZmZmZmZjgxMDY2
NGVhPl0gd2Fybl9zbG93cGF0aF9jb21tb24rMHg3YS8weGIwDQpbICAzNjkuNTcxODQ4XSAg
WzxmZmZmZmZmZjgxMDY2NTM1Pl0gd2Fybl9zbG93cGF0aF9udWxsKzB4MTUvMHgyMA0KWyAg
MzY5LjU3MTg1NF0gIFs8ZmZmZmZmZmY4MTQ2ZDg5ZT5dIHhlbm5ldF9zdGFydF94bWl0KzB4
N2ZlLzB4ODYwDQpbICAzNjkuNTcxODYzXSAgWzxmZmZmZmZmZjgxNjFmMzQ5Pl0gZGV2X2hh
cmRfc3RhcnRfeG1pdCsweDIwOS8weDQ2MA0KWyAgMzY5LjU3MTg3MV0gIFs8ZmZmZmZmZmY4
MTYzYjAzNj5dIHNjaF9kaXJlY3RfeG1pdCsweGY2LzB4MjkwDQpbICAzNjkuNTcxODc3XSAg
WzxmZmZmZmZmZjgxNjFmNzQ2Pl0gZGV2X3F1ZXVlX3htaXQrMHgxYTYvMHg1YTANClsgIDM2
OS41NzE4ODNdICBbPGZmZmZmZmZmODE2MWY1YTA+XSA/IGRldl9oYXJkX3N0YXJ0X3htaXQr
MHg0NjAvMHg0NjANClsgIDM2OS41NzE4OTBdICBbPGZmZmZmZmZmODEwYjE0MTc+XSA/IGxv
Y2tfcmVsZWFzZSsweDExNy8weDI1MA0KWyAgMzY5LjU3MTg5OF0gIFs8ZmZmZmZmZmY4MTZi
OTUzNj5dIGlwX2ZpbmlzaF9vdXRwdXQrMHgyMjYvMHg1MzANClsgIDM2OS41NzE5MDNdICBb
PGZmZmZmZmZmODE2YjkzZGQ+XSA/IGlwX2ZpbmlzaF9vdXRwdXQrMHhjZC8weDUzMA0KWyAg
MzY5LjU3MTkwOV0gIFs8ZmZmZmZmZmY4MTZiOTg5OT5dIGlwX291dHB1dCsweDU5LzB4ZTAN
ClsgIDM2OS41NzE5MTVdICBbPGZmZmZmZmZmODE2YjgzYjg+XSBpcF9sb2NhbF9vdXQrMHgy
OC8weDkwDQpbICAzNjkuNTcxOTIyXSAgWzxmZmZmZmZmZjgxNmI4OTZmPl0gaXBfcXVldWVf
eG1pdCsweDE3Zi8weDRhMA0KWyAgMzY5LjU3MTkyN10gIFs8ZmZmZmZmZmY4MTZiODdmMD5d
ID8gaXBfc2VuZF91bmljYXN0X3JlcGx5KzB4MzQwLzB4MzQwDQpbICAzNjkuNTcxOTM0XSAg
WzxmZmZmZmZmZjgxMGEwYmE3Pl0gPyBnZXRuc3RpbWVvZmRheSsweDQ3LzB4ZTANClsgIDM2
OS41NzE5NDFdICBbPGZmZmZmZmZmODE2MGY0Yzk+XSA/IF9fc2tiX2Nsb25lKzB4MjkvMHgx
MjANClsgIDM2OS41NzE5NDddICBbPGZmZmZmZmZmODE2Y2VhMjA+XSB0Y3BfdHJhbnNtaXRf
c2tiKzB4NDAwLzB4OGQwDQpbICAzNjkuNTcxOTUzXSAgWzxmZmZmZmZmZjgxNmQxMTA2Pl0g
dGNwX3JldHJhbnNtaXRfc2tiKzB4MWM2LzB4NWEwDQpbICAzNjkuNTcxOTU5XSAgWzxmZmZm
ZmZmZjgxNmQxNjdlPl0gdGNwX3htaXRfcmV0cmFuc21pdF9xdWV1ZSsweDE5ZS8weDMwMA0K
WyAgMzY5LjU3MTk2NV0gIFs8ZmZmZmZmZmY4MTZjOTlmZj5dIHRjcF9mYXN0cmV0cmFuc19h
bGVydCsweDk0Zi8weGNiMA0KWyAgMzY5LjU3MTk3MV0gIFs8ZmZmZmZmZmY4MTZjYTcwYz5d
IHRjcF9hY2srMHg5YWMvMHgxMTUwDQpbICAzNjkuNTcxOTc3XSAgWzxmZmZmZmZmZjgxNmNk
ODU4Pl0gdGNwX3Jjdl9lc3RhYmxpc2hlZCsweDMxOC8weDY0MA0KWyAgMzY5LjU3MTk4M10g
IFs8ZmZmZmZmZmY4MTZkNWVlZj5dID8gdGNwX3Y0X3JjdisweDZjZi8weGIxMA0KWyAgMzY5
LjU3MTk4OV0gIFs8ZmZmZmZmZmY4MTZkNTRkNT5dIHRjcF92NF9kb19yY3YrMHgxMzUvMHg0
ODANClsgIDM2OS41NzE5OTZdICBbPGZmZmZmZmZmODE3NDYxZDI+XSA/IF9yYXdfc3Bpbl9s
b2NrX25lc3RlZCsweDQyLzB4NTANClsgIDM2OS41NzIwMDJdICBbPGZmZmZmZmZmODE2ZDVl
ZWY+XSA/IHRjcF92NF9yY3YrMHg2Y2YvMHhiMTANClsgIDM2OS41NzIwMDddICBbPGZmZmZm
ZmZmODE2ZDYxN2Q+XSB0Y3BfdjRfcmN2KzB4OTVkLzB4YjEwDQpbICAzNjkuNTcyMDEzXSAg
WzxmZmZmZmZmZjgxMGIwZjg4Pl0gPyBsb2NrX2FjcXVpcmUrMHhkOC8weDEwMA0KWyAgMzY5
LjU3MjAxOV0gIFs8ZmZmZmZmZmY4MTZiMjk5NT5dID8gaXBfbG9jYWxfZGVsaXZlcl9maW5p
c2grMHg0NS8weDIzMA0KWyAgMzY5LjU3MjAyNl0gIFs8ZmZmZmZmZmY4MTZiMmE2YT5dIGlw
X2xvY2FsX2RlbGl2ZXJfZmluaXNoKzB4MTFhLzB4MjMwDQpbICAzNjkuNTcyMDMxXSAgWzxm
ZmZmZmZmZjgxNmIyOTk1Pl0gPyBpcF9sb2NhbF9kZWxpdmVyX2ZpbmlzaCsweDQ1LzB4MjMw
DQpbICAzNjkuNTcyMDM3XSAgWzxmZmZmZmZmZjgxNmIyYmI4Pl0gaXBfbG9jYWxfZGVsaXZl
cisweDM4LzB4ODANClsgIDM2OS41NzIwNDNdICBbPGZmZmZmZmZmODE2YjIxN2E+XSBpcF9y
Y3ZfZmluaXNoKzB4MTVhLzB4NjMwDQpbICAzNjkuNTcyMDQ4XSAgWzxmZmZmZmZmZjgxNmIy
ODY4Pl0gaXBfcmN2KzB4MjE4LzB4MzAwDQpbICAzNjkuNTcyMDU0XSAgWzxmZmZmZmZmZjgx
NjFhYzhkPl0gX19uZXRpZl9yZWNlaXZlX3NrYisweDY1ZC8weDhkMA0KWyAgMzY5LjU3MjA2
MF0gIFs8ZmZmZmZmZmY4MTYxYTc3NT5dID8gX19uZXRpZl9yZWNlaXZlX3NrYisweDE0NS8w
eDhkMA0KWyAgMzY5LjU3MjA2Nl0gIFs8ZmZmZmZmZmY4MTBhZDIyZD5dID8gdHJhY2VfaGFy
ZGlycXNfb24rMHhkLzB4MTANClsgIDM2OS41NzIwNzNdICBbPGZmZmZmZmZmODEwZjk5NzM+
XSA/IGZyZWVfaG90X2NvbGRfcGFnZSsweDFiMy8weDFlMA0KWyAgMzY5LjU3MjA4MF0gIFs8
ZmZmZmZmZmY4MTYxZDFmOD5dIG5ldGlmX3JlY2VpdmVfc2tiKzB4MjgvMHhmMA0KWyAgMzY5
LjU3MjA4Nl0gIFs8ZmZmZmZmZmY4MTYxMmQwMz5dID8gX19wc2tiX3B1bGxfdGFpbCsweDI1
My8weDM0MA0KWyAgMzY5LjU3MjA5Ml0gIFs8ZmZmZmZmZmY4MTQ2ZTRjNT5dIHhlbm5ldF9w
b2xsKzB4YWQ1LzB4ZTEwDQpbICAzNjkuNTcyMDk4XSAgWzxmZmZmZmZmZjgxNjFkZmE2Pl0g
bmV0X3J4X2FjdGlvbisweDEzNi8weDI2MA0KWyAgMzY5LjU3MjEwNV0gIFs8ZmZmZmZmZmY4
MTA2ZTM4MT5dID8gX19kb19zb2Z0aXJxKzB4NzEvMHgxYTANClsgIDM2OS41NzIxMTBdICBb
PGZmZmZmZmZmODEwNmUzZDk+XSBfX2RvX3NvZnRpcnErMHhjOS8weDFhMA0KWyAgMzY5LjU3
MjExNl0gIFs8ZmZmZmZmZmY4MTc0OGQzYz5dIGNhbGxfc29mdGlycSsweDFjLzB4MzANClsg
IDM2OS41NzIxMjRdICBbPGZmZmZmZmZmODEwMGVkYjU+XSBkb19zb2Z0aXJxKzB4ODUvMHhm
MA0KWyAgMzY5LjU3MjEyOV0gIFs8ZmZmZmZmZmY4MTA2ZTI0ZT5dIGlycV9leGl0KzB4OWUv
MHhkMA0KWyAgMzY5LjU3MjEzN10gIFs8ZmZmZmZmZmY4MTMzOWY1Zj5dIHhlbl9ldnRjaG5f
ZG9fdXBjYWxsKzB4MmYvMHg0MA0KWyAgMzY5LjU3MjE0M10gIFs8ZmZmZmZmZmY4MTc0OGQ5
ZT5dIHhlbl9kb19oeXBlcnZpc29yX2NhbGxiYWNrKzB4MWUvMHgzMA0KWyAgMzY5LjU3MjE0
N10gIDxFT0k+ICBbPGZmZmZmZmZmODEwMDEzYWE+XSA/IHhlbl9oeXBlcmNhbGxfc2NoZWRf
b3ArMHhhLzB4MjANClsgIDM2OS41NzIxNThdICBbPGZmZmZmZmZmODEwMDEzYWE+XSA/IHhl
bl9oeXBlcmNhbGxfc2NoZWRfb3ArMHhhLzB4MjANClsgIDM2OS41NzIxNjVdICBbPGZmZmZm
ZmZmODEwMDg2OTA+XSA/IHhlbl9zYWZlX2hhbHQrMHgxMC8weDIwDQpbICAzNjkuNTcyMTcx
XSAgWzxmZmZmZmZmZjgxMDE2MGQwPl0gPyBkZWZhdWx0X2lkbGUrMHg0MC8weDkwDQpbICAz
NjkuNTcyMTc2XSAgWzxmZmZmZmZmZjgxMDE2NDg2Pl0gPyBjcHVfaWRsZSsweDk2LzB4ZjAN
ClsgIDM2OS41NzIxODZdICBbPGZmZmZmZmZmODE3MjJkM2M+XSA/IHJlc3RfaW5pdCsweGJj
LzB4ZDANClsgIDM2OS41NzIxOTJdICBbPGZmZmZmZmZmODE3MjJjODA+XSA/IGNzdW1fcGFy
dGlhbF9jb3B5X2dlbmVyaWMrMHgxNzAvMHgxNzANClsgIDM2OS41NzIyMDBdICBbPGZmZmZm
ZmZmODFjZTBkZjI+XSA/IHN0YXJ0X2tlcm5lbCsweDM5MC8weDM5ZA0KWyAgMzY5LjU3MjIw
Nl0gIFs8ZmZmZmZmZmY4MWNlMDg4Mj5dID8ga2VybmVsX2luaXQrMHgyMGIvMHgyMGINClsg
IDM2OS41NzIyMTJdICBbPGZmZmZmZmZmODFjZTAzNTY+XSA/IHg4Nl82NF9zdGFydF9yZXNl
cnZhdGlvbnMrMHgxMzEvMHgxMzYNClsgIDM2OS41NzIyMThdICBbPGZmZmZmZmZmODFjZTNk
NjA+XSA/IHhlbl9zdGFydF9rZXJuZWwrMHg3MGQvMHg3MGYNClsgIDM2OS41NzIyMjRdIC0t
LVsgZW5kIHRyYWNlIDJlMjhlZWM5M2I3YThiOTYgXS0tLQ0KWyAgMzY5LjU3MjI1MV0gLS0t
LS0tLS0tLS0tWyBjdXQgaGVyZSBdLS0tLS0tLS0tLS0tDQpbICAzNjkuNTcyMjU3XSBXQVJO
SU5HOiBhdCBkcml2ZXJzL25ldC94ZW4tbmV0ZnJvbnQuYzo0NjUgeGVubmV0X3N0YXJ0X3ht
aXQrMHg3ZmUvMHg4NjAoKQ0KWyAgMzY5LjU3MjI2NF0gTW9kdWxlcyBsaW5rZWQgaW46DQpb
ICAzNjkuNTcyMjY4XSBQaWQ6IDAsIGNvbW06IHN3YXBwZXIvMCBUYWludGVkOiBHICAgICAg
ICBXICAgIDMuNi4wcHJlLXJjMS0yMDEyMTAxMSAjMQ0KWyAgMzY5LjU3MjI3NF0gQ2FsbCBU
cmFjZToNClsgIDM2OS41NzIyNzddICA8SVJRPiAgWzxmZmZmZmZmZjgxMDY2NGVhPl0gd2Fy
bl9zbG93cGF0aF9jb21tb24rMHg3YS8weGIwDQpbICAzNjkuNTcyMjg2XSAgWzxmZmZmZmZm
ZjgxMDY2NTM1Pl0gd2Fybl9zbG93cGF0aF9udWxsKzB4MTUvMHgyMA0KWyAgMzY5LjU3MjI5
MV0gIFs8ZmZmZmZmZmY4MTQ2ZDg5ZT5dIHhlbm5ldF9zdGFydF94bWl0KzB4N2ZlLzB4ODYw
DQpbICAzNjkuNTcyMjk4XSAgWzxmZmZmZmZmZjgxNjFmMzQ5Pl0gZGV2X2hhcmRfc3RhcnRf
eG1pdCsweDIwOS8weDQ2MA0KWyAgMzY5LjU3MjMwNF0gIFs8ZmZmZmZmZmY4MTYzYjAzNj5d
IHNjaF9kaXJlY3RfeG1pdCsweGY2LzB4MjkwDQpbICAzNjkuNTcyMzA5XSAgWzxmZmZmZmZm
ZjgxNjFmNzQ2Pl0gZGV2X3F1ZXVlX3htaXQrMHgxYTYvMHg1YTANClsgIDM2OS41NzIzMTVd
ICBbPGZmZmZmZmZmODE2MWY1YTA+XSA/IGRldl9oYXJkX3N0YXJ0X3htaXQrMHg0NjAvMHg0
NjANClsgIDM2OS41NzIzMjFdICBbPGZmZmZmZmZmODEwYjE0MTc+XSA/IGxvY2tfcmVsZWFz
ZSsweDExNy8weDI1MA0KWyAgMzY5LjU3MjMyN10gIFs8ZmZmZmZmZmY4MTZiOTUzNj5dIGlw
X2ZpbmlzaF9vdXRwdXQrMHgyMjYvMHg1MzANClsgIDM2OS41NzIzMzNdICBbPGZmZmZmZmZm
ODE2YjkzZGQ+XSA/IGlwX2ZpbmlzaF9vdXRwdXQrMHhjZC8weDUzMA0KWyAgMzY5LjU3MjMz
OV0gIFs8ZmZmZmZmZmY4MTZiOTg5OT5dIGlwX291dHB1dCsweDU5LzB4ZTANClsgIDM2OS41
NzIzNDRdICBbPGZmZmZmZmZmODE2YjgzYjg+XSBpcF9sb2NhbF9vdXQrMHgyOC8weDkwDQpb
ICAzNjkuNTcyMzUwXSAgWzxmZmZmZmZmZjgxNmI4OTZmPl0gaXBfcXVldWVfeG1pdCsweDE3
Zi8weDRhMA0KWyAgMzY5LjU3MjM1NV0gIFs8ZmZmZmZmZmY4MTZiODdmMD5dID8gaXBfc2Vu
ZF91bmljYXN0X3JlcGx5KzB4MzQwLzB4MzQwDQpbICAzNjkuNTcyMzYxXSAgWzxmZmZmZmZm
ZjgxMGEwYmE3Pl0gPyBnZXRuc3RpbWVvZmRheSsweDQ3LzB4ZTANClsgIDM2OS41NzIzNzBd
ICBbPGZmZmZmZmZmODE2MGY0Yzk+XSA/IF9fc2tiX2Nsb25lKzB4MjkvMHgxMjANClsgIDM2
OS41NzIzNzZdICBbPGZmZmZmZmZmODE2Y2VhMjA+XSB0Y3BfdHJhbnNtaXRfc2tiKzB4NDAw
LzB4OGQwDQpbICAzNjkuNTcyMzgyXSAgWzxmZmZmZmZmZjgxNmQxMTA2Pl0gdGNwX3JldHJh
bnNtaXRfc2tiKzB4MWM2LzB4NWEwDQpbICAzNjkuNTcyMzg4XSAgWzxmZmZmZmZmZjgxNmQx
NjdlPl0gdGNwX3htaXRfcmV0cmFuc21pdF9xdWV1ZSsweDE5ZS8weDMwMA0KWyAgMzY5LjU3
MjM5NF0gIFs8ZmZmZmZmZmY4MTZjOTlmZj5dIHRjcF9mYXN0cmV0cmFuc19hbGVydCsweDk0
Zi8weGNiMA0KWyAgMzY5LjU3MjQwMF0gIFs8ZmZmZmZmZmY4MTZjYTcwYz5dIHRjcF9hY2sr
MHg5YWMvMHgxMTUwDQpbICAzNjkuNTcyNDA2XSAgWzxmZmZmZmZmZjgxNmNkODU4Pl0gdGNw
X3Jjdl9lc3RhYmxpc2hlZCsweDMxOC8weDY0MA0KWyAgMzY5LjU3MjQxMV0gIFs8ZmZmZmZm
ZmY4MTZkNWVlZj5dID8gdGNwX3Y0X3JjdisweDZjZi8weGIxMA0KWyAgMzY5LjU3MjQxN10g
IFs8ZmZmZmZmZmY4MTZkNTRkNT5dIHRjcF92NF9kb19yY3YrMHgxMzUvMHg0ODANClsgIDM2
OS41NzI0MjNdICBbPGZmZmZmZmZmODE3NDYxZDI+XSA/IF9yYXdfc3Bpbl9sb2NrX25lc3Rl
ZCsweDQyLzB4NTANClsgIDM2OS41NzI0MjldICBbPGZmZmZmZmZmODE2ZDVlZWY+XSA/IHRj
cF92NF9yY3YrMHg2Y2YvMHhiMTANClsgIDM2OS41NzI0MzRdICBbPGZmZmZmZmZmODE2ZDYx
N2Q+XSB0Y3BfdjRfcmN2KzB4OTVkLzB4YjEwDQpbICAzNjkuNTcyNDM5XSAgWzxmZmZmZmZm
ZjgxMGIwZjg4Pl0gPyBsb2NrX2FjcXVpcmUrMHhkOC8weDEwMA0KWyAgMzY5LjU3MjQ0NV0g
IFs8ZmZmZmZmZmY4MTZiMjk5NT5dID8gaXBfbG9jYWxfZGVsaXZlcl9maW5pc2grMHg0NS8w
eDIzMA0KWyAgMzY5LjU3MjQ1MV0gIFs8ZmZmZmZmZmY4MTZiMmE2YT5dIGlwX2xvY2FsX2Rl
bGl2ZXJfZmluaXNoKzB4MTFhLzB4MjMwDQpbICAzNjkuNTcyNDU3XSAgWzxmZmZmZmZmZjgx
NmIyOTk1Pl0gPyBpcF9sb2NhbF9kZWxpdmVyX2ZpbmlzaCsweDQ1LzB4MjMwDQpbICAzNjku
NTcyNDYzXSAgWzxmZmZmZmZmZjgxNmIyYmI4Pl0gaXBfbG9jYWxfZGVsaXZlcisweDM4LzB4
ODANClsgIDM2OS41NzI0NjldICBbPGZmZmZmZmZmODE2YjIxN2E+XSBpcF9yY3ZfZmluaXNo
KzB4MTVhLzB4NjMwDQpbICAzNjkuNTcyNDc0XSAgWzxmZmZmZmZmZjgxNmIyODY4Pl0gaXBf
cmN2KzB4MjE4LzB4MzAwDQpbICAzNjkuNTcyNDgwXSAgWzxmZmZmZmZmZjgxNjFhYzhkPl0g
X19uZXRpZl9yZWNlaXZlX3NrYisweDY1ZC8weDhkMA0KWyAgMzY5LjU3MjQ4Nl0gIFs8ZmZm
ZmZmZmY4MTYxYTc3NT5dID8gX19uZXRpZl9yZWNlaXZlX3NrYisweDE0NS8weDhkMA0KWyAg
MzY5LjU3MjQ5Ml0gIFs8ZmZmZmZmZmY4MTBhZDIyZD5dID8gdHJhY2VfaGFyZGlycXNfb24r
MHhkLzB4MTANClsgIDM2OS41NzI0OTddICBbPGZmZmZmZmZmODEwZjk5NzM+XSA/IGZyZWVf
aG90X2NvbGRfcGFnZSsweDFiMy8weDFlMA0KWyAgMzY5LjU3MjUwM10gIFs8ZmZmZmZmZmY4
MTYxZDFmOD5dIG5ldGlmX3JlY2VpdmVfc2tiKzB4MjgvMHhmMA0KWyAgMzY5LjU3MjUwOV0g
IFs8ZmZmZmZmZmY4MTYxMmQwMz5dID8gX19wc2tiX3B1bGxfdGFpbCsweDI1My8weDM0MA0K
WyAgMzY5LjU3MjUxNV0gIFs8ZmZmZmZmZmY4MTQ2ZTRjNT5dIHhlbm5ldF9wb2xsKzB4YWQ1
LzB4ZTEwDQpbICAzNjkuNTcyNTIxXSAgWzxmZmZmZmZmZjgxNjFkZmE2Pl0gbmV0X3J4X2Fj
dGlvbisweDEzNi8weDI2MA0KWyAgMzY5LjU3MjUyN10gIFs8ZmZmZmZmZmY4MTA2ZTM4MT5d
ID8gX19kb19zb2Z0aXJxKzB4NzEvMHgxYTANClsgIDM2OS41NzI1MzNdICBbPGZmZmZmZmZm
ODEwNmUzZDk+XSBfX2RvX3NvZnRpcnErMHhjOS8weDFhMA0KWyAgMzY5LjU3MjUzOF0gIFs8
ZmZmZmZmZmY4MTc0OGQzYz5dIGNhbGxfc29mdGlycSsweDFjLzB4MzANClsgIDM2OS41NzI1
NDNdICBbPGZmZmZmZmZmODEwMGVkYjU+XSBkb19zb2Z0aXJxKzB4ODUvMHhmMA0KWyAgMzY5
LjU3MjU0OV0gIFs8ZmZmZmZmZmY4MTA2ZTI0ZT5dIGlycV9leGl0KzB4OWUvMHhkMA0KWyAg
MzY5LjU3MjU1NV0gIFs8ZmZmZmZmZmY4MTMzOWY1Zj5dIHhlbl9ldnRjaG5fZG9fdXBjYWxs
KzB4MmYvMHg0MA0KWyAgMzY5LjU3MjU2MF0gIFs8ZmZmZmZmZmY4MTc0OGQ5ZT5dIHhlbl9k
b19oeXBlcnZpc29yX2NhbGxiYWNrKzB4MWUvMHgzMA0KWyAgMzY5LjU3MjU2Nl0gIDxFT0k+
ICBbPGZmZmZmZmZmODEwMDEzYWE+XSA/IHhlbl9oeXBlcmNhbGxfc2NoZWRfb3ArMHhhLzB4
MjANClsgIDM2OS41NzI1NzVdICBbPGZmZmZmZmZmODEwMDEzYWE+XSA/IHhlbl9oeXBlcmNh
bGxfc2NoZWRfb3ArMHhhLzB4MjANClsgIDM2OS41NzI1ODFdICBbPGZmZmZmZmZmODEwMDg2
OTA+XSA/IHhlbl9zYWZlX2hhbHQrMHgxMC8weDIwDQpbICAzNjkuNTcyNTg2XSAgWzxmZmZm
ZmZmZjgxMDE2MGQwPl0gPyBkZWZhdWx0X2lkbGUrMHg0MC8weDkwDQpbICAzNjkuNTcyNTky
XSAgWzxmZmZmZmZmZjgxMDE2NDg2Pl0gPyBjcHVfaWRsZSsweDk2LzB4ZjANClsgIDM2OS41
NzI1OTddICBbPGZmZmZmZmZmODE3MjJkM2M+XSA/IHJlc3RfaW5pdCsweGJjLzB4ZDANClsg
IDM2OS41NzI2MDJdICBbPGZmZmZmZmZmODE3MjJjODA+XSA/IGNzdW1fcGFydGlhbF9jb3B5
X2dlbmVyaWMrMHgxNzAvMHgxNzANClsgIDM2OS41NzI2MDhdICBbPGZmZmZmZmZmODFjZTBk
ZjI+XSA/IHN0YXJ0X2tlcm5lbCsweDM5MC8weDM5ZA0KWyAgMzY5LjU3MjYxNF0gIFs8ZmZm
ZmZmZmY4MWNlMDg4Mj5dID8ga2VybmVsX2luaXQrMHgyMGIvMHgyMGINClsgIDM2OS41NzI2
MTldICBbPGZmZmZmZmZmODFjZTAzNTY+XSA/IHg4Nl82NF9zdGFydF9yZXNlcnZhdGlvbnMr
MHgxMzEvMHgxMzYNClsgIDM2OS41NzI2MjZdICBbPGZmZmZmZmZmODFjZTNkNjA+XSA/IHhl
bl9zdGFydF9rZXJuZWwrMHg3MGQvMHg3MGYNClsgIDM2OS41NzI2MzFdIC0tLVsgZW5kIHRy
YWNlIDJlMjhlZWM5M2I3YThiOTcgXS0tLQ0KWyAgMzY5LjU3NDU3OV0gLS0tLS0tLS0tLS0t
WyBjdXQgaGVyZSBdLS0tLS0tLS0tLS0tDQpbICAzNjkuNTc0NTk5XSBXQVJOSU5HOiBhdCBk
cml2ZXJzL25ldC94ZW4tbmV0ZnJvbnQuYzo0NjUgeGVubmV0X3N0YXJ0X3htaXQrMHg3ZmUv
MHg4NjAoKQ0KWyAgMzY5LjU3NDYwNV0gTW9kdWxlcyBsaW5rZWQgaW46DQpbICAzNjkuNTc0
NjExXSBQaWQ6IDE1MjMsIGNvbW06IHN5c2xvZ2QgVGFpbnRlZDogRyAgICAgICAgVyAgICAz
LjYuMHByZS1yYzEtMjAxMjEwMTEgIzENClsgIDM2OS41NzQ2MTddIENhbGwgVHJhY2U6DQpb
ICAzNjkuNTc0NjIwXSAgPElSUT4gIFs8ZmZmZmZmZmY4MTA2NjRlYT5dIHdhcm5fc2xvd3Bh
dGhfY29tbW9uKzB4N2EvMHhiMA0KWyAgMzY5LjU3NDYyOV0gIFs8ZmZmZmZmZmY4MTA2NjUz
NT5dIHdhcm5fc2xvd3BhdGhfbnVsbCsweDE1LzB4MjANClsgIDM2OS41NzQ2MzVdICBbPGZm
ZmZmZmZmODE0NmQ4OWU+XSB4ZW5uZXRfc3RhcnRfeG1pdCsweDdmZS8weDg2MA0KWyAgMzY5
LjU3NDY0Ml0gIFs8ZmZmZmZmZmY4MTYxZjM0OT5dIGRldl9oYXJkX3N0YXJ0X3htaXQrMHgy
MDkvMHg0NjANClsgIDM2OS41NzQ2NDhdICBbPGZmZmZmZmZmODE2M2IwMzY+XSBzY2hfZGly
ZWN0X3htaXQrMHhmNi8weDI5MA0KWyAgMzY5LjU3NDY1M10gIFs8ZmZmZmZmZmY4MTYxZjc0
Nj5dIGRldl9xdWV1ZV94bWl0KzB4MWE2LzB4NWEwDQpbICAzNjkuNTc0NjU5XSAgWzxmZmZm
ZmZmZjgxNjFmNWEwPl0gPyBkZXZfaGFyZF9zdGFydF94bWl0KzB4NDYwLzB4NDYwDQpbICAz
NjkuNTc0NjY1XSAgWzxmZmZmZmZmZjgxMGIxNDE3Pl0gPyBsb2NrX3JlbGVhc2UrMHgxMTcv
MHgyNTANClsgIDM2OS41NzQ2NzFdICBbPGZmZmZmZmZmODE2Yjk1MzY+XSBpcF9maW5pc2hf
b3V0cHV0KzB4MjI2LzB4NTMwDQpbICAzNjkuNTc0Njc3XSAgWzxmZmZmZmZmZjgxNmI5M2Rk
Pl0gPyBpcF9maW5pc2hfb3V0cHV0KzB4Y2QvMHg1MzANClsgIDM2OS41NzQ2ODNdICBbPGZm
ZmZmZmZmODE2Yjk4OTk+XSBpcF9vdXRwdXQrMHg1OS8weGUwDQpbICAzNjkuNTc0Njg4XSAg
WzxmZmZmZmZmZjgxNmI4M2I4Pl0gaXBfbG9jYWxfb3V0KzB4MjgvMHg5MA0KWyAgMzY5LjU3
NDY5NF0gIFs8ZmZmZmZmZmY4MTZiODk2Zj5dIGlwX3F1ZXVlX3htaXQrMHgxN2YvMHg0YTAN
ClsgIDM2OS41NzQ2OTldICBbPGZmZmZmZmZmODE2Yjg3ZjA+XSA/IGlwX3NlbmRfdW5pY2Fz
dF9yZXBseSsweDM0MC8weDM0MA0KWyAgMzY5LjU3NDcwNl0gIFs8ZmZmZmZmZmY4MTBhMGJh
Nz5dID8gZ2V0bnN0aW1lb2ZkYXkrMHg0Ny8weGUwDQpbICAzNjkuNTc0NzEyXSAgWzxmZmZm
ZmZmZjgxNjBmNGM5Pl0gPyBfX3NrYl9jbG9uZSsweDI5LzB4MTIwDQpbICAzNjkuNTc0NzE4
XSAgWzxmZmZmZmZmZjgxNmNlYTIwPl0gdGNwX3RyYW5zbWl0X3NrYisweDQwMC8weDhkMA0K
WyAgMzY5LjU3NDcyOF0gIFs8ZmZmZmZmZmY4MTZkMTEwNj5dIHRjcF9yZXRyYW5zbWl0X3Nr
YisweDFjNi8weDVhMA0KWyAgMzY5LjU3NDczNF0gIFs8ZmZmZmZmZmY4MTc0NmNiNT5dID8g
X3Jhd19zcGluX3VubG9ja19pcnFyZXN0b3JlKzB4NzUvMHhhMA0KWyAgMzY5LjU3NDc0MF0g
IFs8ZmZmZmZmZmY4MTZkMTY3ZT5dIHRjcF94bWl0X3JldHJhbnNtaXRfcXVldWUrMHgxOWUv
MHgzMDANClsgIDM2OS41NzQ3NDZdICBbPGZmZmZmZmZmODE2Yzk5ZmY+XSB0Y3BfZmFzdHJl
dHJhbnNfYWxlcnQrMHg5NGYvMHhjYjANClsgIDM2OS41NzQ3NTJdICBbPGZmZmZmZmZmODE2
Y2E3MGM+XSB0Y3BfYWNrKzB4OWFjLzB4MTE1MA0KWyAgMzY5LjU3NDc1OF0gIFs8ZmZmZmZm
ZmY4MTZjZDhjZT5dIHRjcF9yY3ZfZXN0YWJsaXNoZWQrMHgzOGUvMHg2NDANClsgIDM2OS41
NzQ3NjNdICBbPGZmZmZmZmZmODE2ZDVlZWY+XSA/IHRjcF92NF9yY3YrMHg2Y2YvMHhiMTAN
ClsgIDM2OS41NzQ3NjldICBbPGZmZmZmZmZmODE2ZDU0ZDU+XSB0Y3BfdjRfZG9fcmN2KzB4
MTM1LzB4NDgwDQpbICAzNjkuNTc0Nzc1XSAgWzxmZmZmZmZmZjgxNzQ2MWQyPl0gPyBfcmF3
X3NwaW5fbG9ja19uZXN0ZWQrMHg0Mi8weDUwDQpbICAzNjkuNTc0NzgxXSAgWzxmZmZmZmZm
ZjgxNmQ1ZWVmPl0gPyB0Y3BfdjRfcmN2KzB4NmNmLzB4YjEwDQpbICAzNjkuNTc0Nzg2XSAg
WzxmZmZmZmZmZjgxNmQ2MTdkPl0gdGNwX3Y0X3JjdisweDk1ZC8weGIxMA0KWyAgMzY5LjU3
NDc5Ml0gIFs8ZmZmZmZmZmY4MTBiMGY4OD5dID8gbG9ja19hY3F1aXJlKzB4ZDgvMHgxMDAN
ClsgIDM2OS41NzQ3OTddICBbPGZmZmZmZmZmODE2YjI5OTU+XSA/IGlwX2xvY2FsX2RlbGl2
ZXJfZmluaXNoKzB4NDUvMHgyMzANClsgIDM2OS41NzQ4MDRdICBbPGZmZmZmZmZmODE2YjJh
NmE+XSBpcF9sb2NhbF9kZWxpdmVyX2ZpbmlzaCsweDExYS8weDIzMA0KWyAgMzY5LjU3NDgx
MF0gIFs8ZmZmZmZmZmY4MTZiMjk5NT5dID8gaXBfbG9jYWxfZGVsaXZlcl9maW5pc2grMHg0
NS8weDIzMA0KWyAgMzY5LjU3NDgxNl0gIFs8ZmZmZmZmZmY4MTZiMmJiOD5dIGlwX2xvY2Fs
X2RlbGl2ZXIrMHgzOC8weDgwDQpbICAzNjkuNTc0ODIxXSAgWzxmZmZmZmZmZjgxNmIyMTdh
Pl0gaXBfcmN2X2ZpbmlzaCsweDE1YS8weDYzMA0KWyAgMzY5LjU3NDgyN10gIFs8ZmZmZmZm
ZmY4MTZiMjg2OD5dIGlwX3JjdisweDIxOC8weDMwMA0KWyAgMzY5LjU3NDgzMl0gIFs8ZmZm
ZmZmZmY4MTYxYWM4ZD5dIF9fbmV0aWZfcmVjZWl2ZV9za2IrMHg2NWQvMHg4ZDANClsgIDM2
OS41NzQ4MzhdICBbPGZmZmZmZmZmODE2MWE3NzU+XSA/IF9fbmV0aWZfcmVjZWl2ZV9za2Ir
MHgxNDUvMHg4ZDANClsgIDM2OS41NzQ4NDNdICBbPGZmZmZmZmZmODEwYWQyMmQ+XSA/IHRy
YWNlX2hhcmRpcnFzX29uKzB4ZC8weDEwDQpbICAzNjkuNTc0ODUwXSAgWzxmZmZmZmZmZjgx
MGY5OTczPl0gPyBmcmVlX2hvdF9jb2xkX3BhZ2UrMHgxYjMvMHgxZTANClsgIDM2OS41NzQ4
NTZdICBbPGZmZmZmZmZmODE2MWQxZjg+XSBuZXRpZl9yZWNlaXZlX3NrYisweDI4LzB4ZjAN
ClsgIDM2OS41NzQ4NjJdICBbPGZmZmZmZmZmODE2MTJkMDM+XSA/IF9fcHNrYl9wdWxsX3Rh
aWwrMHgyNTMvMHgzNDANClsgIDM2OS41NzQ4NjddICBbPGZmZmZmZmZmODE0NmU0YzU+XSB4
ZW5uZXRfcG9sbCsweGFkNS8weGUxMA0KWyAgMzY5LjU3NDg3NF0gIFs8ZmZmZmZmZmY4MTYx
ZGZhNj5dIG5ldF9yeF9hY3Rpb24rMHgxMzYvMHgyNjANClsgIDM2OS41NzQ4NzldICBbPGZm
ZmZmZmZmODEwNmUzODE+XSA/IF9fZG9fc29mdGlycSsweDcxLzB4MWEwDQpbICAzNjkuNTc0
ODg1XSAgWzxmZmZmZmZmZjgxMDZlM2Q5Pl0gX19kb19zb2Z0aXJxKzB4YzkvMHgxYTANClsg
IDM2OS41NzQ4OTFdICBbPGZmZmZmZmZmODE3NDhkM2M+XSBjYWxsX3NvZnRpcnErMHgxYy8w
eDMwDQpbICAzNjkuNTc0ODk2XSAgWzxmZmZmZmZmZjgxMDBlZGI1Pl0gZG9fc29mdGlycSsw
eDg1LzB4ZjANClsgIDM2OS41NzQ5MDFdICBbPGZmZmZmZmZmODEwNmUyNGU+XSBpcnFfZXhp
dCsweDllLzB4ZDANClsgIDM2OS41NzQ5MDddICBbPGZmZmZmZmZmODEzMzlmNWY+XSB4ZW5f
ZXZ0Y2huX2RvX3VwY2FsbCsweDJmLzB4NDANClsgIDM2OS41NzQ5MTNdICBbPGZmZmZmZmZm
ODE3NDhkOWU+XSB4ZW5fZG9faHlwZXJ2aXNvcl9jYWxsYmFjaysweDFlLzB4MzANClsgIDM2
OS41NzQ5MThdICA8RU9JPiAgWzxmZmZmZmZmZjgxMDAxMjJhPl0gPyB4ZW5faHlwZXJjYWxs
X3hlbl92ZXJzaW9uKzB4YS8weDIwDQpbICAzNjkuNTc0OTI4XSAgWzxmZmZmZmZmZjgxMDAx
MjJhPl0gPyB4ZW5faHlwZXJjYWxsX3hlbl92ZXJzaW9uKzB4YS8weDIwDQpbICAzNjkuNTc0
OTM0XSAgWzxmZmZmZmZmZjgxMDA4NjRkPl0gPyB4ZW5fZm9yY2VfZXZ0Y2huX2NhbGxiYWNr
KzB4ZC8weDEwDQpbICAzNjkuNTc0OTQwXSAgWzxmZmZmZmZmZjgxMDA4ZmYyPl0gPyBjaGVj
a19ldmVudHMrMHgxMi8weDIwDQpbICAzNjkuNTc0OTQ2XSAgWzxmZmZmZmZmZjgxMDA4ZmRm
Pl0gPyB4ZW5fcmVzdG9yZV9mbF9kaXJlY3RfcmVsb2MrMHg0LzB4NA0KWyAgMzY5LjU3NDk1
Ml0gIFs8ZmZmZmZmZmY4MTBiMGY4OD5dID8gbG9ja19hY3F1aXJlKzB4ZDgvMHgxMDANClsg
IDM2OS41NzQ5NThdICBbPGZmZmZmZmZmODEwZjJhNDA+XSA/IGZpbmRfZ2V0X3BhZ2VzKzB4
MTkwLzB4MTkwDQpbICAzNjkuNTc0OTY0XSAgWzxmZmZmZmZmZjgxMGYyYTgyPl0gPyBmaW5k
X2dldF9wYWdlKzB4NDIvMHgxMDANClsgIDM2OS41NzQ5NjldICBbPGZmZmZmZmZmODEwZjJh
NDA+XSA/IGZpbmRfZ2V0X3BhZ2VzKzB4MTkwLzB4MTkwDQpbICAzNjkuNTc0OTc1XSAgWzxm
ZmZmZmZmZjgxMGYyZGMxPl0gPyBmaW5kX2xvY2tfcGFnZSsweDIxLzB4ODANClsgIDM2OS41
NzQ5ODBdICBbPGZmZmZmZmZmODEwZjMzMWE+XSA/IGdyYWJfY2FjaGVfcGFnZV93cml0ZV9i
ZWdpbisweDZhLzB4ZTANClsgIDM2OS41NzQ5ODhdICBbPGZmZmZmZmZmODExZDZkZjc+XSA/
IGV4dDRfZGFfd3JpdGVfYmVnaW4rMHg5Ny8weDFhMA0KWyAgMzY5LjU3NDk5M10gIFs8ZmZm
ZmZmZmY4MTBiMDU0Yj5dID8gX19sb2NrX2FjcXVpcmUrMHg0NmIvMHhkZDANClsgIDM2OS41
NzQ5OTldICBbPGZmZmZmZmZmODE2MTAzNGM+XSA/IHNrYl9mcmVlX2hlYWQrMHg0Yy8weDYw
DQpbICAzNjkuNTc1MDA1XSAgWzxmZmZmZmZmZjgxMGYxZWJiPl0gPyBnZW5lcmljX2ZpbGVf
YnVmZmVyZWRfd3JpdGUrMHgxMGIvMHgyYjANClsgIDM2OS41NzUwMTJdICBbPGZmZmZmZmZm
ODEwNmQ3NDI+XSA/IGN1cnJlbnRfZnNfdGltZSsweDIyLzB4MzANClsgIDM2OS41NzUwMTdd
ICBbPGZmZmZmZmZmODEwZjQwOWI+XSA/IF9fZ2VuZXJpY19maWxlX2Fpb193cml0ZSsweDFi
Yi8weDNjMA0KWyAgMzY5LjU3NTAyM10gIFs8ZmZmZmZmZmY4MTBmNDMxYz5dID8gZ2VuZXJp
Y19maWxlX2Fpb193cml0ZSsweDdjLzB4ZjANClsgIDM2OS41NzUwMjldICBbPGZmZmZmZmZm
ODExZDA0YzQ+XSA/IGV4dDRfZmlsZV93cml0ZSsweDY0LzB4NGMwDQpbICAzNjkuNTc1MDM2
XSAgWzxmZmZmZmZmZjgxMDhlYjFkPl0gPyBsZ19sb2NhbF91bmxvY2srMHgzZC8weDcwDQpb
ICAzNjkuNTc1MDQyXSAgWzxmZmZmZmZmZjgxMWQwNDYwPl0gPyBleHQ0X3Vud3JpdHRlbl93
YWl0KzB4YzAvMHhjMA0KWyAgMzY5LjU3NTA0OV0gIFs8ZmZmZmZmZmY4MTE0MzRjYj5dID8g
ZG9fc3luY19yZWFkdl93cml0ZXYrMHg5Yi8weGUwDQpbICAzNjkuNTc1MDU2XSAgWzxmZmZm
ZmZmZjgxMThkMDdjPl0gPyBjb21wYXRfZG9fcmVhZHZfd3JpdGV2KzB4MWNjLzB4MjEwDQpb
ICAzNjkuNTc1MDYyXSAgWzxmZmZmZmZmZjgxNzQ5MjE5Pl0gPyBzeXNyZXRsX2Zyb21fc3lz
X2NhbGwrMHgyZS8weDM4DQpbICAzNjkuNTc1MDY4XSAgWzxmZmZmZmZmZjgxMThkMGY3Pl0g
PyBjb21wYXRfd3JpdGV2KzB4MzcvMHg3MA0KWyAgMzY5LjU3NTA3NF0gIFs8ZmZmZmZmZmY4
MTE4ZDJiND5dID8gY29tcGF0X3N5c193cml0ZXYrMHg1NC8weDkwDQpbICAzNjkuNTc1MDc5
XSAgWzxmZmZmZmZmZjgxNzQ5MWNjPl0gPyBjc3Rhcl9kaXNwYXRjaCsweDcvMHgyNg0KWyAg
MzY5LjU3NTA4NF0gLS0tWyBlbmQgdHJhY2UgMmUyOGVlYzkzYjdhOGI5OCBdLS0tDQpbICAz
NjkuNTc1MTA1XSAtLS0tLS0tLS0tLS1bIGN1dCBoZXJlIF0tLS0tLS0tLS0tLS0NClsgIDM2
OS41NzUxMTFdIFdBUk5JTkc6IGF0IGRyaXZlcnMvbmV0L3hlbi1uZXRmcm9udC5jOjQ2NSB4
ZW5uZXRfc3RhcnRfeG1pdCsweDdmZS8weDg2MCgpDQpbICAzNjkuNTc1MTE3XSBNb2R1bGVz
IGxpbmtlZCBpbjoNClsgIDM2OS41NzUxMjJdIFBpZDogMTUyMywgY29tbTogc3lzbG9nZCBU
YWludGVkOiBHICAgICAgICBXICAgIDMuNi4wcHJlLXJjMS0yMDEyMTAxMSAjMQ0KWyAgMzY5
LjU3NTEyOF0gQ2FsbCBUcmFjZToNClsgIDM2OS41NzUxMzBdICA8SVJRPiAgWzxmZmZmZmZm
ZjgxMDY2NGVhPl0gd2Fybl9zbG93cGF0aF9jb21tb24rMHg3YS8weGIwDQpbICAzNjkuNTc1
MTM5XSAgWzxmZmZmZmZmZjgxMDY2NTM1Pl0gd2Fybl9zbG93cGF0aF9udWxsKzB4MTUvMHgy
MA0KWyAgMzY5LjU3NTE0NV0gIFs8ZmZmZmZmZmY4MTQ2ZDg5ZT5dIHhlbm5ldF9zdGFydF94
bWl0KzB4N2ZlLzB4ODYwDQpbICAzNjkuNTc1MTUxXSAgWzxmZmZmZmZmZjgxNjFmMzQ5Pl0g
ZGV2X2hhcmRfc3RhcnRfeG1pdCsweDIwOS8weDQ2MA0KWyAgMzY5LjU3NTE1N10gIFs8ZmZm
ZmZmZmY4MTYzYjAzNj5dIHNjaF9kaXJlY3RfeG1pdCsweGY2LzB4MjkwDQpbICAzNjkuNTc1
MTY2XSAgWzxmZmZmZmZmZjgxNjFmNzQ2Pl0gZGV2X3F1ZXVlX3htaXQrMHgxYTYvMHg1YTAN
ClsgIDM2OS41NzUxNzJdICBbPGZmZmZmZmZmODE2MWY1YTA+XSA/IGRldl9oYXJkX3N0YXJ0
X3htaXQrMHg0NjAvMHg0NjANClsgIDM2OS41NzUxNzhdICBbPGZmZmZmZmZmODEwYjE0MTc+
XSA/IGxvY2tfcmVsZWFzZSsweDExNy8weDI1MA0KWyAgMzY5LjU3NTE4NF0gIFs8ZmZmZmZm
ZmY4MTZiOTUzNj5dIGlwX2ZpbmlzaF9vdXRwdXQrMHgyMjYvMHg1MzANClsgIDM2OS41NzUx
OTBdICBbPGZmZmZmZmZmODE2YjkzZGQ+XSA/IGlwX2ZpbmlzaF9vdXRwdXQrMHhjZC8weDUz
MA0KWyAgMzY5LjU3NTE5Nl0gIFs8ZmZmZmZmZmY4MTZiOTg5OT5dIGlwX291dHB1dCsweDU5
LzB4ZTANClsgIDM2OS41NzUyMDJdICBbPGZmZmZmZmZmODE2YjgzYjg+XSBpcF9sb2NhbF9v
dXQrMHgyOC8weDkwDQpbICAzNjkuNTc1MjA3XSAgWzxmZmZmZmZmZjgxNmI4OTZmPl0gaXBf
cXVldWVfeG1pdCsweDE3Zi8weDRhMA0KWyAgMzY5LjU3NTIxM10gIFs8ZmZmZmZmZmY4MTZi
ODdmMD5dID8gaXBfc2VuZF91bmljYXN0X3JlcGx5KzB4MzQwLzB4MzQwDQpbICAzNjkuNTc1
MjE5XSAgWzxmZmZmZmZmZjgxMGEwYmE3Pl0gPyBnZXRuc3RpbWVvZmRheSsweDQ3LzB4ZTAN
ClsgIDM2OS41NzUyMjVdICBbPGZmZmZmZmZmODE2MGY0Yzk+XSA/IF9fc2tiX2Nsb25lKzB4
MjkvMHgxMjANClsgIDM2OS41NzUyMzBdICBbPGZmZmZmZmZmODE2Y2VhMjA+XSB0Y3BfdHJh
bnNtaXRfc2tiKzB4NDAwLzB4OGQwDQpbICAzNjkuNTc1MjM2XSAgWzxmZmZmZmZmZjgxNmQx
MTA2Pl0gdGNwX3JldHJhbnNtaXRfc2tiKzB4MWM2LzB4NWEwDQpbICAzNjkuNTc1MjQyXSAg
WzxmZmZmZmZmZjgxNzQ2Y2I1Pl0gPyBfcmF3X3NwaW5fdW5sb2NrX2lycXJlc3RvcmUrMHg3
NS8weGEwDQpbICAzNjkuNTc1MjQ4XSAgWzxmZmZmZmZmZjgxNmQxNjdlPl0gdGNwX3htaXRf
cmV0cmFuc21pdF9xdWV1ZSsweDE5ZS8weDMwMA0KWyAgMzY5LjU3NTI1NV0gIFs8ZmZmZmZm
ZmY4MTZjOTlmZj5dIHRjcF9mYXN0cmV0cmFuc19hbGVydCsweDk0Zi8weGNiMA0KWyAgMzY5
LjU3NTI2MF0gIFs8ZmZmZmZmZmY4MTZjYTcwYz5dIHRjcF9hY2srMHg5YWMvMHgxMTUwDQpb
ICAzNjkuNTc1MjY2XSAgWzxmZmZmZmZmZjgxNmNkOGNlPl0gdGNwX3Jjdl9lc3RhYmxpc2hl
ZCsweDM4ZS8weDY0MA0KWyAgMzY5LjU3NTI3Ml0gIFs8ZmZmZmZmZmY4MTZkNWVlZj5dID8g
dGNwX3Y0X3JjdisweDZjZi8weGIxMA0KWyAgMzY5LjU3NTI3OF0gIFs8ZmZmZmZmZmY4MTZk
NTRkNT5dIHRjcF92NF9kb19yY3YrMHgxMzUvMHg0ODANClsgIDM2OS41NzUyODRdICBbPGZm
ZmZmZmZmODE3NDYxZDI+XSA/IF9yYXdfc3Bpbl9sb2NrX25lc3RlZCsweDQyLzB4NTANClsg
IDM2OS41NzUyODldICBbPGZmZmZmZmZmODE2ZDVlZWY+XSA/IHRjcF92NF9yY3YrMHg2Y2Yv
MHhiMTANClsgIDM2OS41NzUyOTVdICBbPGZmZmZmZmZmODE2ZDYxN2Q+XSB0Y3BfdjRfcmN2
KzB4OTVkLzB4YjEwDQpbICAzNjkuNTc1MzAwXSAgWzxmZmZmZmZmZjgxMGIwZjg4Pl0gPyBs
b2NrX2FjcXVpcmUrMHhkOC8weDEwMA0KWyAgMzY5LjU3NTMwOV0gIFs8ZmZmZmZmZmY4MTZi
Mjk5NT5dID8gaXBfbG9jYWxfZGVsaXZlcl9maW5pc2grMHg0NS8weDIzMA0KWyAgMzY5LjU3
NTMxNl0gIFs8ZmZmZmZmZmY4MTZiMmE2YT5dIGlwX2xvY2FsX2RlbGl2ZXJfZmluaXNoKzB4
MTFhLzB4MjMwDQpbICAzNjkuNTc1MzIyXSAgWzxmZmZmZmZmZjgxNmIyOTk1Pl0gPyBpcF9s
b2NhbF9kZWxpdmVyX2ZpbmlzaCsweDQ1LzB4MjMwDQpbICAzNjkuNTc1MzI4XSAgWzxmZmZm
ZmZmZjgxNmIyYmI4Pl0gaXBfbG9jYWxfZGVsaXZlcisweDM4LzB4ODANClsgIDM2OS41NzUz
MzRdICBbPGZmZmZmZmZmODE2YjIxN2E+XSBpcF9yY3ZfZmluaXNoKzB4MTVhLzB4NjMwDQpb
ICAzNjkuNTc1MzM5XSAgWzxmZmZmZmZmZjgxNmIyODY4Pl0gaXBfcmN2KzB4MjE4LzB4MzAw
DQpbICAzNjkuNTc1MzQ0XSAgWzxmZmZmZmZmZjgxNjFhYzhkPl0gX19uZXRpZl9yZWNlaXZl
X3NrYisweDY1ZC8weDhkMA0KWyAgMzY5LjU3NTM1MF0gIFs8ZmZmZmZmZmY4MTYxYTc3NT5d
ID8gX19uZXRpZl9yZWNlaXZlX3NrYisweDE0NS8weDhkMA0KWyAgMzY5LjU3NTM1Nl0gIFs8
ZmZmZmZmZmY4MTBhZDIyZD5dID8gdHJhY2VfaGFyZGlycXNfb24rMHhkLzB4MTANClsgIDM2
OS41NzUzNjJdICBbPGZmZmZmZmZmODEwZjk5NzM+XSA/IGZyZWVfaG90X2NvbGRfcGFnZSsw
eDFiMy8weDFlMA0KWyAgMzY5LjU3NTM2OV0gIFs8ZmZmZmZmZmY4MTYxZDFmOD5dIG5ldGlm
X3JlY2VpdmVfc2tiKzB4MjgvMHhmMA0KWyAgMzY5LjU3NTM3NV0gIFs8ZmZmZmZmZmY4MTYx
MmQwMz5dID8gX19wc2tiX3B1bGxfdGFpbCsweDI1My8weDM0MA0KWyAgMzY5LjU3NTM4NF0g
IFs8ZmZmZmZmZmY4MTQ2ZTRjNT5dIHhlbm5ldF9wb2xsKzB4YWQ1LzB4ZTEwDQpbICAzNjku
NTc1MzkxXSAgWzxmZmZmZmZmZjgxNjFkZmE2Pl0gbmV0X3J4X2FjdGlvbisweDEzNi8weDI2
MA0KWyAgMzY5LjU3NTM5N10gIFs8ZmZmZmZmZmY4MTA2ZTM4MT5dID8gX19kb19zb2Z0aXJx
KzB4NzEvMHgxYTANClsgIDM2OS41NzU0MDJdICBbPGZmZmZmZmZmODEwNmUzZDk+XSBfX2Rv
X3NvZnRpcnErMHhjOS8weDFhMA0KWyAgMzY5LjU3NTQwOF0gIFs8ZmZmZmZmZmY4MTc0OGQz
Yz5dIGNhbGxfc29mdGlycSsweDFjLzB4MzANClsgIDM2OS41NzU0MTNdICBbPGZmZmZmZmZm
ODEwMGVkYjU+XSBkb19zb2Z0aXJxKzB4ODUvMHhmMA0KWyAgMzY5LjU3NTQxOV0gIFs8ZmZm
ZmZmZmY4MTA2ZTI0ZT5dIGlycV9leGl0KzB4OWUvMHhkMA0KWyAgMzY5LjU3NTQyOF0gIFs8
ZmZmZmZmZmY4MTMzOWY1Zj5dIHhlbl9ldnRjaG5fZG9fdXBjYWxsKzB4MmYvMHg0MA0KWyAg
MzY5LjU3NTQzNF0gIFs8ZmZmZmZmZmY4MTc0OGQ5ZT5dIHhlbl9kb19oeXBlcnZpc29yX2Nh
bGxiYWNrKzB4MWUvMHgzMA0KWyAgMzY5LjU3NTQzOV0gIDxFT0k+ICBbPGZmZmZmZmZmODEw
MDEyMmE+XSA/IHhlbl9oeXBlcmNhbGxfeGVuX3ZlcnNpb24rMHhhLzB4MjANClsgIDM2OS41
NzU0NDhdICBbPGZmZmZmZmZmODEwMDEyMmE+XSA/IHhlbl9oeXBlcmNhbGxfeGVuX3ZlcnNp
b24rMHhhLzB4MjANClsgIDM2OS41NzU0NTRdICBbPGZmZmZmZmZmODEwMDg2NGQ+XSA/IHhl
bl9mb3JjZV9ldnRjaG5fY2FsbGJhY2srMHhkLzB4MTANClsgIDM2OS41NzU0NjBdICBbPGZm
ZmZmZmZmODEwMDhmZjI+XSA/IGNoZWNrX2V2ZW50cysweDEyLzB4MjANClsgIDM2OS41NzU0
NjZdICBbPGZmZmZmZmZmODEwMDhmZGY+XSA/IHhlbl9yZXN0b3JlX2ZsX2RpcmVjdF9yZWxv
YysweDQvMHg0DQpbICAzNjkuNTc1NDcyXSAgWzxmZmZmZmZmZjgxMGIwZjg4Pl0gPyBsb2Nr
X2FjcXVpcmUrMHhkOC8weDEwMA0KWyAgMzY5LjU3NTQ3OF0gIFs8ZmZmZmZmZmY4MTBmMmE0
MD5dID8gZmluZF9nZXRfcGFnZXMrMHgxOTAvMHgxOTANClsgIDM2OS41NzU0ODVdICBbPGZm
ZmZmZmZmODEwZjJhODI+XSA/IGZpbmRfZ2V0X3BhZ2UrMHg0Mi8weDEwMA0KWyAgMzY5LjU3
NTQ5MV0gIFs8ZmZmZmZmZmY4MTBmMmE0MD5dID8gZmluZF9nZXRfcGFnZXMrMHgxOTAvMHgx
OTANClsgIDM2OS41NzU0OTddICBbPGZmZmZmZmZmODEwZjJkYzE+XSA/IGZpbmRfbG9ja19w
YWdlKzB4MjEvMHg4MA0KWyAgMzY5LjU3NTUwMl0gIFs8ZmZmZmZmZmY4MTBmMzMxYT5dID8g
Z3JhYl9jYWNoZV9wYWdlX3dyaXRlX2JlZ2luKzB4NmEvMHhlMA0KWyAgMzY5LjU3NTUwOF0g
IFs8ZmZmZmZmZmY4MTFkNmRmNz5dID8gZXh0NF9kYV93cml0ZV9iZWdpbisweDk3LzB4MWEw
DQpbICAzNjkuNTc1NTE0XSAgWzxmZmZmZmZmZjgxMGIwNTRiPl0gPyBfX2xvY2tfYWNxdWly
ZSsweDQ2Yi8weGRkMA0KWyAgMzY5LjU3NTUyMF0gIFs8ZmZmZmZmZmY4MTYxMDM0Yz5dID8g
c2tiX2ZyZWVfaGVhZCsweDRjLzB4NjANClsgIDM2OS41NzU1MjZdICBbPGZmZmZmZmZmODEw
ZjFlYmI+XSA/IGdlbmVyaWNfZmlsZV9idWZmZXJlZF93cml0ZSsweDEwYi8weDJiMA0KWyAg
MzY5LjU3NTUzMl0gIFs8ZmZmZmZmZmY4MTA2ZDc0Mj5dID8gY3VycmVudF9mc190aW1lKzB4
MjIvMHgzMA0KWyAgMzY5LjU3NTUzOF0gIFs8ZmZmZmZmZmY4MTBmNDA5Yj5dID8gX19nZW5l
cmljX2ZpbGVfYWlvX3dyaXRlKzB4MWJiLzB4M2MwDQpbICAzNjkuNTc1NTQ0XSAgWzxmZmZm
ZmZmZjgxMGY0MzFjPl0gPyBnZW5lcmljX2ZpbGVfYWlvX3dyaXRlKzB4N2MvMHhmMA0KWyAg
MzY5LjU3NTU1MF0gIFs8ZmZmZmZmZmY4MTFkMDRjND5dID8gZXh0NF9maWxlX3dyaXRlKzB4
NjQvMHg0YzANClsgIDM2OS41NzU1NTZdICBbPGZmZmZmZmZmODEwOGViMWQ+XSA/IGxnX2xv
Y2FsX3VubG9jaysweDNkLzB4NzANClsgIDM2OS41NzU1NjJdICBbPGZmZmZmZmZmODExZDA0
NjA+XSA/IGV4dDRfdW53cml0dGVuX3dhaXQrMHhjMC8weGMwDQpbICAzNjkuNTc1NTY3XSAg
WzxmZmZmZmZmZjgxMTQzNGNiPl0gPyBkb19zeW5jX3JlYWR2X3dyaXRldisweDliLzB4ZTAN
ClsgIDM2OS41NzU1NzRdICBbPGZmZmZmZmZmODExOGQwN2M+XSA/IGNvbXBhdF9kb19yZWFk
dl93cml0ZXYrMHgxY2MvMHgyMTANClsgIDM2OS41NzU1ODJdICBbPGZmZmZmZmZmODE3NDky
MTk+XSA/IHN5c3JldGxfZnJvbV9zeXNfY2FsbCsweDJlLzB4MzgNClsgIDM2OS41NzU1ODhd
ICBbPGZmZmZmZmZmODExOGQwZjc+XSA/IGNvbXBhdF93cml0ZXYrMHgzNy8weDcwDQpbICAz
NjkuNTc1NTk0XSAgWzxmZmZmZmZmZjgxMThkMmI0Pl0gPyBjb21wYXRfc3lzX3dyaXRldisw
eDU0LzB4OTANClsgIDM2OS41NzU2MDBdICBbPGZmZmZmZmZmODE3NDkxY2M+XSA/IGNzdGFy
X2Rpc3BhdGNoKzB4Ny8weDI2DQpbICAzNjkuNTc1NjA0XSAtLS1bIGVuZCB0cmFjZSAyZTI4
ZWVjOTNiN2E4Yjk5IF0tLS0NClsgIDM2OS41NzU2MjZdIC0tLS0tLS0tLS0tLVsgY3V0IGhl
cmUgXS0tLS0tLS0tLS0tLQ0KWyAgMzY5LjU3NTYzMl0gV0FSTklORzogYXQgZHJpdmVycy9u
ZXQveGVuLW5ldGZyb250LmM6NDY1IHhlbm5ldF9zdGFydF94bWl0KzB4N2ZlLzB4ODYwKCkN
ClsgIDM2OS41NzU2MzhdIE1vZHVsZXMgbGlua2VkIGluOg0KWyAgMzY5LjU3NTY0Ml0gUGlk
OiAxNTIzLCBjb21tOiBzeXNsb2dkIFRhaW50ZWQ6IEcgICAgICAgIFcgICAgMy42LjBwcmUt
cmMxLTIwMTIxMDExICMxDQpbICAzNjkuNTc1NjQ4XSBDYWxsIFRyYWNlOg0KWyAgMzY5LjU3
NTY1MV0gIDxJUlE+ICBbPGZmZmZmZmZmODEwNjY0ZWE+XSB3YXJuX3Nsb3dwYXRoX2NvbW1v
bisweDdhLzB4YjANClsgIDM2OS41NzU2NjBdICBbPGZmZmZmZmZmODEwNjY1MzU+XSB3YXJu
X3Nsb3dwYXRoX251bGwrMHgxNS8weDIwDQpbICAzNjkuNTc1NjY1XSAgWzxmZmZmZmZmZjgx
NDZkODllPl0geGVubmV0X3N0YXJ0X3htaXQrMHg3ZmUvMHg4NjANClsgIDM2OS41NzU2NzJd
ICBbPGZmZmZmZmZmODE2MWYzNDk+XSBkZXZfaGFyZF9zdGFydF94bWl0KzB4MjA5LzB4NDYw
DQpbICAzNjkuNTc1Njc4XSAgWzxmZmZmZmZmZjgxNjNiMDM2Pl0gc2NoX2RpcmVjdF94bWl0
KzB4ZjYvMHgyOTANClsgIDM2OS41NzU2ODRdICBbPGZmZmZmZmZmODE2MWY3NDY+XSBkZXZf
cXVldWVfeG1pdCsweDFhNi8weDVhMA0KWyAgMzY5LjU3NTY5MF0gIFs8ZmZmZmZmZmY4MTYx
ZjVhMD5dID8gZGV2X2hhcmRfc3RhcnRfeG1pdCsweDQ2MC8weDQ2MA0KWyAgMzY5LjU3NTY5
Nl0gIFs8ZmZmZmZmZmY4MTBiMTQxNz5dID8gbG9ja19yZWxlYXNlKzB4MTE3LzB4MjUwDQpb
ICAzNjkuNTc1NzAyXSAgWzxmZmZmZmZmZjgxNmI5NTM2Pl0gaXBfZmluaXNoX291dHB1dCsw
eDIyNi8weDUzMA0KWyAgMzY5LjU3NTcwN10gIFs8ZmZmZmZmZmY4MTZiOTNkZD5dID8gaXBf
ZmluaXNoX291dHB1dCsweGNkLzB4NTMwDQpbICAzNjkuNTc1NzE0XSAgWzxmZmZmZmZmZjgx
NmI5ODk5Pl0gaXBfb3V0cHV0KzB4NTkvMHhlMA0KWyAgMzY5LjU3NTcxOV0gIFs8ZmZmZmZm
ZmY4MTZiODNiOD5dIGlwX2xvY2FsX291dCsweDI4LzB4OTANClsgIDM2OS41NzU3MjVdICBb
PGZmZmZmZmZmODE2Yjg5NmY+XSBpcF9xdWV1ZV94bWl0KzB4MTdmLzB4NGEwDQpbICAzNjku
NTc1NzMwXSAgWzxmZmZmZmZmZjgxNmI4N2YwPl0gPyBpcF9zZW5kX3VuaWNhc3RfcmVwbHkr
MHgzNDAvMHgzNDANClsgIDM2OS41NzU3MzZdICBbPGZmZmZmZmZmODEwYTBiYTc+XSA/IGdl
dG5zdGltZW9mZGF5KzB4NDcvMHhlMA0KWyAgMzY5LjU3NTc0Ml0gIFs8ZmZmZmZmZmY4MTYw
ZjRjOT5dID8gX19za2JfY2xvbmUrMHgyOS8weDEyMA0KWyAgMzY5LjU3NTc0OF0gIFs8ZmZm
ZmZmZmY4MTZjZWEyMD5dIHRjcF90cmFuc21pdF9za2IrMHg0MDAvMHg4ZDANClsgIDM2OS41
NzU3NTRdICBbPGZmZmZmZmZmODE2ZDExMDY+XSB0Y3BfcmV0cmFuc21pdF9za2IrMHgxYzYv
MHg1YTANClsgIDM2OS41NzU3NTldICBbPGZmZmZmZmZmODE3NDZjYjU+XSA/IF9yYXdfc3Bp
bl91bmxvY2tfaXJxcmVzdG9yZSsweDc1LzB4YTANClsgIDM2OS41NzU3NjZdICBbPGZmZmZm
ZmZmODE2ZDE2N2U+XSB0Y3BfeG1pdF9yZXRyYW5zbWl0X3F1ZXVlKzB4MTllLzB4MzAwDQpb
ICAzNjkuNTc1NzcyXSAgWzxmZmZmZmZmZjgxNmM5OWZmPl0gdGNwX2Zhc3RyZXRyYW5zX2Fs
ZXJ0KzB4OTRmLzB4Y2IwDQpbICAzNjkuNTc1Nzc4XSAgWzxmZmZmZmZmZjgxNmNhNzBjPl0g
dGNwX2FjaysweDlhYy8weDExNTANClsgIDM2OS41NzU3ODNdICBbPGZmZmZmZmZmODE2Y2Q4
Y2U+XSB0Y3BfcmN2X2VzdGFibGlzaGVkKzB4MzhlLzB4NjQwDQpbICAzNjkuNTc1Nzg5XSAg
WzxmZmZmZmZmZjgxNmQ1ZWVmPl0gPyB0Y3BfdjRfcmN2KzB4NmNmLzB4YjEwDQpbICAzNjku
NTc1Nzk1XSAgWzxmZmZmZmZmZjgxNmQ1NGQ1Pl0gdGNwX3Y0X2RvX3JjdisweDEzNS8weDQ4
MA0KWyAgMzY5LjU3NTgwM10gIFs8ZmZmZmZmZmY4MTc0NjFkMj5dID8gX3Jhd19zcGluX2xv
Y2tfbmVzdGVkKzB4NDIvMHg1MA0KWyAgMzY5LjU3NTgwOV0gIFs8ZmZmZmZmZmY4MTZkNWVl
Zj5dID8gdGNwX3Y0X3JjdisweDZjZi8weGIxMA0KWyAgMzY5LjU3NTgxNV0gIFs8ZmZmZmZm
ZmY4MTZkNjE3ZD5dIHRjcF92NF9yY3YrMHg5NWQvMHhiMTANClsgIDM2OS41NzU4MjNdICBb
PGZmZmZmZmZmODEwYjBmODg+XSA/IGxvY2tfYWNxdWlyZSsweGQ4LzB4MTAwDQpbICAzNjku
NTc1ODI4XSAgWzxmZmZmZmZmZjgxNmIyOTk1Pl0gPyBpcF9sb2NhbF9kZWxpdmVyX2Zpbmlz
aCsweDQ1LzB4MjMwDQpbICAzNjkuNTc1ODM1XSAgWzxmZmZmZmZmZjgxNmIyYTZhPl0gaXBf
bG9jYWxfZGVsaXZlcl9maW5pc2grMHgxMWEvMHgyMzANClsgIDM2OS41NzU4NDFdICBbPGZm
ZmZmZmZmODE2YjI5OTU+XSA/IGlwX2xvY2FsX2RlbGl2ZXJfZmluaXNoKzB4NDUvMHgyMzAN
ClsgIDM2OS41NzU4NDddICBbPGZmZmZmZmZmODE2YjJiYjg+XSBpcF9sb2NhbF9kZWxpdmVy
KzB4MzgvMHg4MA0KWyAgMzY5LjU3NTg1Ml0gIFs8ZmZmZmZmZmY4MTZiMjE3YT5dIGlwX3Jj
dl9maW5pc2grMHgxNWEvMHg2MzANClsgIDM2OS41NzU4NThdICBbPGZmZmZmZmZmODE2YjI4
Njg+XSBpcF9yY3YrMHgyMTgvMHgzMDANClsgIDM2OS41NzU4NjNdICBbPGZmZmZmZmZmODE2
MWFjOGQ+XSBfX25ldGlmX3JlY2VpdmVfc2tiKzB4NjVkLzB4OGQwDQpbICAzNjkuNTc1ODY5
XSAgWzxmZmZmZmZmZjgxNjFhNzc1Pl0gPyBfX25ldGlmX3JlY2VpdmVfc2tiKzB4MTQ1LzB4
OGQwDQpbICAzNjkuNTc1ODc1XSAgWzxmZmZmZmZmZjgxMGFkMjJkPl0gPyB0cmFjZV9oYXJk
aXJxc19vbisweGQvMHgxMA0KWyAgMzY5LjU3NTg4MV0gIFs8ZmZmZmZmZmY4MTBmOTk3Mz5d
ID8gZnJlZV9ob3RfY29sZF9wYWdlKzB4MWIzLzB4MWUwDQpbICAzNjkuNTc1ODg3XSAgWzxm
ZmZmZmZmZjgxNjFkMWY4Pl0gbmV0aWZfcmVjZWl2ZV9za2IrMHgyOC8weGYwDQpbICAzNjku
NTc1ODkzXSAgWzxmZmZmZmZmZjgxNjEyZDAzPl0gPyBfX3Bza2JfcHVsbF90YWlsKzB4MjUz
LzB4MzQwDQpbICAzNjkuNTc2NzI2XSAgWzxmZmZmZmZmZjgxNDZlNGM1Pl0geGVubmV0X3Bv
bGwrMHhhZDUvMHhlMTANClsgIDM2OS41NzY3MjZdICBbPGZmZmZmZmZmODE2MWRmYTY+XSBu
ZXRfcnhfYWN0aW9uKzB4MTM2LzB4MjYwDQpbICAzNjkuNTc2NzI2XSAgWzxmZmZmZmZmZjgx
MDZlMzgxPl0gPyBfX2RvX3NvZnRpcnErMHg3MS8weDFhMA0KWyAgMzY5LjU3NjcyNl0gIFs8
ZmZmZmZmZmY4MTA2ZTNkOT5dIF9fZG9fc29mdGlycSsweGM5LzB4MWEwDQpbICAzNjkuNTc2
NzI2XSAgWzxmZmZmZmZmZjgxNzQ4ZDNjPl0gY2FsbF9zb2Z0aXJxKzB4MWMvMHgzMA0KWyAg
MzY5LjU3NjcyNl0gIFs8ZmZmZmZmZmY4MTAwZWRiNT5dIGRvX3NvZnRpcnErMHg4NS8weGYw
DQpbICAzNjkuNTc2NzI2XSAgWzxmZmZmZmZmZjgxMDZlMjRlPl0gaXJxX2V4aXQrMHg5ZS8w
eGQwDQpbICAzNjkuNTc2NzI2XSAgWzxmZmZmZmZmZjgxMzM5ZjVmPl0geGVuX2V2dGNobl9k
b191cGNhbGwrMHgyZi8weDQwDQpbICAzNjkuNTc2NzI2XSAgWzxmZmZmZmZmZjgxNzQ4ZDll
Pl0geGVuX2RvX2h5cGVydmlzb3JfY2FsbGJhY2srMHgxZS8weDMwDQpbICAzNjkuNTc2NzI2
XSAgPEVPST4gIFs8ZmZmZmZmZmY4MTAwMTIyYT5dID8geGVuX2h5cGVyY2FsbF94ZW5fdmVy
c2lvbisweGEvMHgyMA0KWyAgMzY5LjU3NjcyNl0gIFs8ZmZmZmZmZmY4MTAwMTIyYT5dID8g
eGVuX2h5cGVyY2FsbF94ZW5fdmVyc2lvbisweGEvMHgyMA0KWyAgMzY5LjU3NjcyNl0gIFs8
ZmZmZmZmZmY4MTAwODY0ZD5dID8geGVuX2ZvcmNlX2V2dGNobl9jYWxsYmFjaysweGQvMHgx
MA0KWyAgMzY5LjU3NjcyNl0gIFs8ZmZmZmZmZmY4MTAwOGZmMj5dID8gY2hlY2tfZXZlbnRz
KzB4MTIvMHgyMA0KWyAgMzY5LjU3NjcyNl0gIFs8ZmZmZmZmZmY4MTAwOGZkZj5dID8geGVu
X3Jlc3RvcmVfZmxfZGlyZWN0X3JlbG9jKzB4NC8weDQNClsgIDM2OS41NzY3MjZdICBbPGZm
ZmZmZmZmODEwYjBmODg+XSA/IGxvY2tfYWNxdWlyZSsweGQ4LzB4MTAwDQpbICAzNjkuNTc2
NzI2XSAgWzxmZmZmZmZmZjgxMGYyYTQwPl0gPyBmaW5kX2dldF9wYWdlcysweDE5MC8weDE5
MA0KWyAgMzY5LjU3NjcyNl0gIFs8ZmZmZmZmZmY4MTBmMmE4Mj5dID8gZmluZF9nZXRfcGFn
ZSsweDQyLzB4MTAwDQpbICAzNjkuNTc2NzI2XSAgWzxmZmZmZmZmZjgxMGYyYTQwPl0gPyBm
aW5kX2dldF9wYWdlcysweDE5MC8weDE5MA0KWyAgMzY5LjU3NjcyNl0gIFs8ZmZmZmZmZmY4
MTBmMmRjMT5dID8gZmluZF9sb2NrX3BhZ2UrMHgyMS8weDgwDQpbICAzNjkuNTc2NzI2XSAg
WzxmZmZmZmZmZjgxMGYzMzFhPl0gPyBncmFiX2NhY2hlX3BhZ2Vfd3JpdGVfYmVnaW4rMHg2
YS8weGUwDQpbICAzNjkuNTc2NzI2XSAgWzxmZmZmZmZmZjgxMWQ2ZGY3Pl0gPyBleHQ0X2Rh
X3dyaXRlX2JlZ2luKzB4OTcvMHgxYTANClsgIDM2OS41NzY3MjZdICBbPGZmZmZmZmZmODEw
YjA1NGI+XSA/IF9fbG9ja19hY3F1aXJlKzB4NDZiLzB4ZGQwDQpbICAzNjkuNTc2NzI2XSAg
WzxmZmZmZmZmZjgxNjEwMzRjPl0gPyBza2JfZnJlZV9oZWFkKzB4NGMvMHg2MA0KWyAgMzY5
LjU3NjcyNl0gIFs8ZmZmZmZmZmY4MTBmMWViYj5dID8gZ2VuZXJpY19maWxlX2J1ZmZlcmVk
X3dyaXRlKzB4MTBiLzB4MmIwDQpbICAzNjkuNTc2NzI2XSAgWzxmZmZmZmZmZjgxMDZkNzQy
Pl0gPyBjdXJyZW50X2ZzX3RpbWUrMHgyMi8weDMwDQpbICAzNjkuNTc2NzI2XSAgWzxmZmZm
ZmZmZjgxMGY0MDliPl0gPyBfX2dlbmVyaWNfZmlsZV9haW9fd3JpdGUrMHgxYmIvMHgzYzAN
ClsgIDM2OS41NzY3MjZdICBbPGZmZmZmZmZmODEwZjQzMWM+XSA/IGdlbmVyaWNfZmlsZV9h
aW9fd3JpdGUrMHg3Yy8weGYwDQpbICAzNjkuNTc2NzI2XSAgWzxmZmZmZmZmZjgxMWQwNGM0
Pl0gPyBleHQ0X2ZpbGVfd3JpdGUrMHg2NC8weDRjMA0KWyAgMzY5LjU3NjcyNl0gIFs8ZmZm
ZmZmZmY4MTA4ZWIxZD5dID8gbGdfbG9jYWxfdW5sb2NrKzB4M2QvMHg3MA0KWyAgMzY5LjU3
NjcyNl0gIFs8ZmZmZmZmZmY4MTFkMDQ2MD5dID8gZXh0NF91bndyaXR0ZW5fd2FpdCsweGMw
LzB4YzANClsgIDM2OS41NzY3MjZdICBbPGZmZmZmZmZmODExNDM0Y2I+XSA/IGRvX3N5bmNf
cmVhZHZfd3JpdGV2KzB4OWIvMHhlMA0KWyAgMzY5LjU3NjcyNl0gIFs8ZmZmZmZmZmY4MTE4
ZDA3Yz5dID8gY29tcGF0X2RvX3JlYWR2X3dyaXRldisweDFjYy8weDIxMA0KWyAgMzY5LjU3
NjcyNl0gIFs8ZmZmZmZmZmY4MTc0OTIxOT5dID8gc3lzcmV0bF9mcm9tX3N5c19jYWxsKzB4
MmUvMHgzOA0KWyAgMzY5LjU3NjcyNl0gIFs8ZmZmZmZmZmY4MTE4ZDBmNz5dID8gY29tcGF0
X3dyaXRldisweDM3LzB4NzANClsgIDM2OS41NzY3MjZdICBbPGZmZmZmZmZmODExOGQyYjQ+
XSA/IGNvbXBhdF9zeXNfd3JpdGV2KzB4NTQvMHg5MA0KWyAgMzY5LjU3NjcyNl0gIFs8ZmZm
ZmZmZmY4MTc0OTFjYz5dID8gY3N0YXJfZGlzcGF0Y2grMHg3LzB4MjYNClsgIDM2OS41NzY3
MjZdIC0tLVsgZW5kIHRyYWNlIDJlMjhlZWM5M2I3YThiOWEgXS0tLQ0KWyAgMzcwLjA0Njg4
MF0gLS0tLS0tLS0tLS0tWyBjdXQgaGVyZSBdLS0tLS0tLS0tLS0tDQpbICAzNzAuMDQ2OTA0
XSBXQVJOSU5HOiBhdCBkcml2ZXJzL25ldC94ZW4tbmV0ZnJvbnQuYzo0NjUgeGVubmV0X3N0
YXJ0X3htaXQrMHg3ZmUvMHg4NjAoKQ0KWyAgMzcwLjA0NjkxMF0gTW9kdWxlcyBsaW5rZWQg
aW46DQpbICAzNzAuMDQ2OTE3XSBQaWQ6IDAsIGNvbW06IHN3YXBwZXIvMCBUYWludGVkOiBH
ICAgICAgICBXICAgIDMuNi4wcHJlLXJjMS0yMDEyMTAxMSAjMQ0KWyAgMzcwLjA0NjkyM10g
Q2FsbCBUcmFjZToNClsgIDM3MC4wNDY5MjddICA8SVJRPiAgWzxmZmZmZmZmZjgxMDY2NGVh
Pl0gd2Fybl9zbG93cGF0aF9jb21tb24rMHg3YS8weGIwDQpbICAzNzAuMDQ2OTM5XSAgWzxm
ZmZmZmZmZjgxMDY2NTM1Pl0gd2Fybl9zbG93cGF0aF9udWxsKzB4MTUvMHgyMA0KWyAgMzcw
LjA0Njk0NV0gIFs8ZmZmZmZmZmY4MTQ2ZDg5ZT5dIHhlbm5ldF9zdGFydF94bWl0KzB4N2Zl
LzB4ODYwDQpbICAzNzAuMDQ2OTU0XSAgWzxmZmZmZmZmZjgxNjFmMzQ5Pl0gZGV2X2hhcmRf
c3RhcnRfeG1pdCsweDIwOS8weDQ2MA0KWyAgMzcwLjA0Njk2MV0gIFs8ZmZmZmZmZmY4MTYz
YjAzNj5dIHNjaF9kaXJlY3RfeG1pdCsweGY2LzB4MjkwDQpbICAzNzAuMDQ2OTY2XSAgWzxm
ZmZmZmZmZjgxNjFmNzQ2Pl0gZGV2X3F1ZXVlX3htaXQrMHgxYTYvMHg1YTANClsgIDM3MC4w
NDY5NzJdICBbPGZmZmZmZmZmODE2MWY1YTA+XSA/IGRldl9oYXJkX3N0YXJ0X3htaXQrMHg0
NjAvMHg0NjANClsgIDM3MC4wNDY5NzldICBbPGZmZmZmZmZmODEwYjE0MTc+XSA/IGxvY2tf
cmVsZWFzZSsweDExNy8weDI1MA0KWyAgMzcwLjA0Njk4Nl0gIFs8ZmZmZmZmZmY4MTZiOTUz
Nj5dIGlwX2ZpbmlzaF9vdXRwdXQrMHgyMjYvMHg1MzANClsgIDM3MC4wNDY5OTJdICBbPGZm
ZmZmZmZmODE2YjkzZGQ+XSA/IGlwX2ZpbmlzaF9vdXRwdXQrMHhjZC8weDUzMA0KWyAgMzcw
LjA0Njk5OF0gIFs8ZmZmZmZmZmY4MTZiOTg5OT5dIGlwX291dHB1dCsweDU5LzB4ZTANClsg
IDM3MC4wNDcwMDNdICBbPGZmZmZmZmZmODE2YjgzYjg+XSBpcF9sb2NhbF9vdXQrMHgyOC8w
eDkwDQpbICAzNzAuMDQ3MDA5XSAgWzxmZmZmZmZmZjgxNmI4OTZmPl0gaXBfcXVldWVfeG1p
dCsweDE3Zi8weDRhMA0KWyAgMzcwLjA0NzAxNF0gIFs8ZmZmZmZmZmY4MTZiODdmMD5dID8g
aXBfc2VuZF91bmljYXN0X3JlcGx5KzB4MzQwLzB4MzQwDQpbICAzNzAuMDQ3MDIwXSAgWzxm
ZmZmZmZmZjgxMGEwYmE3Pl0gPyBnZXRuc3RpbWVvZmRheSsweDQ3LzB4ZTANClsgIDM3MC4w
NDcwMjddICBbPGZmZmZmZmZmODE2MGY0Yzk+XSA/IF9fc2tiX2Nsb25lKzB4MjkvMHgxMjAN
ClsgIDM3MC4wNDcwMzNdICBbPGZmZmZmZmZmODE2Y2VhMjA+XSB0Y3BfdHJhbnNtaXRfc2ti
KzB4NDAwLzB4OGQwDQpbICAzNzAuMDQ3MDM5XSAgWzxmZmZmZmZmZjgxNmQxMTA2Pl0gdGNw
X3JldHJhbnNtaXRfc2tiKzB4MWM2LzB4NWEwDQpbICAzNzAuMDQ3MDQ1XSAgWzxmZmZmZmZm
ZjgxNmQzM2IwPl0gPyB0Y3Bfd3JpdGVfdGltZXJfaGFuZGxlcisweDFhMC8weDFhMA0KWyAg
MzcwLjA0NzA1MV0gIFs8ZmZmZmZmZmY4MTZkMmYzOD5dIHRjcF9yZXRyYW5zbWl0X3RpbWVy
KzB4MzU4LzB4NjMwDQpbICAzNzAuMDQ3MDU3XSAgWzxmZmZmZmZmZjgxNmQzMzRkPl0gdGNw
X3dyaXRlX3RpbWVyX2hhbmRsZXIrMHgxM2QvMHgxYTANClsgIDM3MC4wNDcwNjNdICBbPGZm
ZmZmZmZmODE2ZDM0Mjg+XSB0Y3Bfd3JpdGVfdGltZXIrMHg3OC8weDgwDQpbICAzNzAuMDQ3
MDY4XSAgWzxmZmZmZmZmZjgxMDczZjdjPl0gY2FsbF90aW1lcl9mbisweDdjLzB4MTAwDQpb
ICAzNzAuMDQ3MDczXSAgWzxmZmZmZmZmZjgxMDczZjAwPl0gPyBjYXNjYWRlKzB4YTAvMHhh
MA0KWyAgMzcwLjA0NzA3OV0gIFs8ZmZmZmZmZmY4MTZkMzNiMD5dID8gdGNwX3dyaXRlX3Rp
bWVyX2hhbmRsZXIrMHgxYTAvMHgxYTANClsgIDM3MC4wNDcwODVdICBbPGZmZmZmZmZmODE2
ZDMzYjA+XSA/IHRjcF93cml0ZV90aW1lcl9oYW5kbGVyKzB4MWEwLzB4MWEwDQpbICAzNzAu
MDQ3MjM0XSAgWzxmZmZmZmZmZjgxMDc0MjE3Pl0gcnVuX3RpbWVyX3NvZnRpcnErMHgyMTcv
MHgyNTANClsgIDM3MC4wNDcyNDFdICBbPGZmZmZmZmZmODEwNmUzZDk+XSBfX2RvX3NvZnRp
cnErMHhjOS8weDFhMA0KWyAgMzcwLjA0NzI0OF0gIFs8ZmZmZmZmZmY4MTc0OGQzYz5dIGNh
bGxfc29mdGlycSsweDFjLzB4MzANClsgIDM3MC4wNDcyNTRdICBbPGZmZmZmZmZmODEwMGVk
YjU+XSBkb19zb2Z0aXJxKzB4ODUvMHhmMA0KWyAgMzcwLjA0NzI1OV0gIFs8ZmZmZmZmZmY4
MTA2ZTI0ZT5dIGlycV9leGl0KzB4OWUvMHhkMA0KWyAgMzcwLjA0NzI2Nl0gIFs8ZmZmZmZm
ZmY4MTMzOWY1Zj5dIHhlbl9ldnRjaG5fZG9fdXBjYWxsKzB4MmYvMHg0MA0KWyAgMzcwLjA0
NzI3Ml0gIFs8ZmZmZmZmZmY4MTc0OGQ5ZT5dIHhlbl9kb19oeXBlcnZpc29yX2NhbGxiYWNr
KzB4MWUvMHgzMA0KWyAgMzcwLjA0NzI3N10gIDxFT0k+ICBbPGZmZmZmZmZmODEwMDEzYWE+
XSA/IHhlbl9oeXBlcmNhbGxfc2NoZWRfb3ArMHhhLzB4MjANClsgIDM3MC4wNDcyODddICBb
PGZmZmZmZmZmODEwMDEzYWE+XSA/IHhlbl9oeXBlcmNhbGxfc2NoZWRfb3ArMHhhLzB4MjAN
ClsgIDM3MC4wNDcyOTNdICBbPGZmZmZmZmZmODEwMDg2OTA+XSA/IHhlbl9zYWZlX2hhbHQr
MHgxMC8weDIwDQpbICAzNzAuMDQ3MzAwXSAgWzxmZmZmZmZmZjgxMDE2MGQwPl0gPyBkZWZh
dWx0X2lkbGUrMHg0MC8weDkwDQpbICAzNzAuMDQ3MzA1XSAgWzxmZmZmZmZmZjgxMDE2NDg2
Pl0gPyBjcHVfaWRsZSsweDk2LzB4ZjANClsgIDM3MC4wNDczMTFdICBbPGZmZmZmZmZmODE3
MjJkM2M+XSA/IHJlc3RfaW5pdCsweGJjLzB4ZDANClsgIDM3MC4wNDczMTZdICBbPGZmZmZm
ZmZmODE3MjJjODA+XSA/IGNzdW1fcGFydGlhbF9jb3B5X2dlbmVyaWMrMHgxNzAvMHgxNzAN
ClsgIDM3MC4wNDczMjVdICBbPGZmZmZmZmZmODFjZTBkZjI+XSA/IHN0YXJ0X2tlcm5lbCsw
eDM5MC8weDM5ZA0KWyAgMzcwLjA0NzMzMV0gIFs8ZmZmZmZmZmY4MWNlMDg4Mj5dID8ga2Vy
bmVsX2luaXQrMHgyMGIvMHgyMGINClsgIDM3MC4wNDczMzddICBbPGZmZmZmZmZmODFjZTAz
NTY+XSA/IHg4Nl82NF9zdGFydF9yZXNlcnZhdGlvbnMrMHgxMzEvMHgxMzYNClsgIDM3MC4w
NDczNDNdICBbPGZmZmZmZmZmODFjZTNkNjA+XSA/IHhlbl9zdGFydF9rZXJuZWwrMHg3MGQv
MHg3MGYNClsgIDM3MC4wNDczNDldIC0tLVsgZW5kIHRyYWNlIDJlMjhlZWM5M2I3YThiOWIg
XS0tLQ0KWyAgMzcwLjk5Njc4OV0gLS0tLS0tLS0tLS0tWyBjdXQgaGVyZSBdLS0tLS0tLS0t
LS0tDQpbICAzNzAuOTk2ODA3XSBXQVJOSU5HOiBhdCBkcml2ZXJzL25ldC94ZW4tbmV0ZnJv
bnQuYzo0NjUgeGVubmV0X3N0YXJ0X3htaXQrMHg3ZmUvMHg4NjAoKQ0KWyAgMzcwLjk5Njgx
NF0gTW9kdWxlcyBsaW5rZWQgaW46DQpbICAzNzAuOTk2ODIwXSBQaWQ6IDAsIGNvbW06IHN3
YXBwZXIvMCBUYWludGVkOiBHICAgICAgICBXICAgIDMuNi4wcHJlLXJjMS0yMDEyMTAxMSAj
MQ0KWyAgMzcwLjk5NjgyNl0gQ2FsbCBUcmFjZToNClsgIDM3MC45OTY4MjldICA8SVJRPiAg
WzxmZmZmZmZmZjgxMDY2NGVhPl0gd2Fybl9zbG93cGF0aF9jb21tb24rMHg3YS8weGIwDQpb
ICAzNzAuOTk2ODQwXSAgWzxmZmZmZmZmZjgxMDY2NTM1Pl0gd2Fybl9zbG93cGF0aF9udWxs
KzB4MTUvMHgyMA0KWyAgMzcwLjk5Njg0NV0gIFs8ZmZmZmZmZmY4MTQ2ZDg5ZT5dIHhlbm5l
dF9zdGFydF94bWl0KzB4N2ZlLzB4ODYwDQpbICAzNzAuOTk2ODUyXSAgWzxmZmZmZmZmZjgx
NjFmMzQ5Pl0gZGV2X2hhcmRfc3RhcnRfeG1pdCsweDIwOS8weDQ2MA0KWyAgMzcwLjk5Njg1
OF0gIFs8ZmZmZmZmZmY4MTYzYjAzNj5dIHNjaF9kaXJlY3RfeG1pdCsweGY2LzB4MjkwDQpb
ICAzNzAuOTk2ODYzXSAgWzxmZmZmZmZmZjgxNjFmNzQ2Pl0gZGV2X3F1ZXVlX3htaXQrMHgx
YTYvMHg1YTANClsgIDM3MC45OTY4NjhdICBbPGZmZmZmZmZmODE2MWY1YTA+XSA/IGRldl9o
YXJkX3N0YXJ0X3htaXQrMHg0NjAvMHg0NjANClsgIDM3MC45OTY4NzVdICBbPGZmZmZmZmZm
ODEwYjE0MTc+XSA/IGxvY2tfcmVsZWFzZSsweDExNy8weDI1MA0KWyAgMzcwLjk5Njg4MV0g
IFs8ZmZmZmZmZmY4MTZiOTUzNj5dIGlwX2ZpbmlzaF9vdXRwdXQrMHgyMjYvMHg1MzANClsg
IDM3MC45OTY4ODZdICBbPGZmZmZmZmZmODE2YjkzZGQ+XSA/IGlwX2ZpbmlzaF9vdXRwdXQr
MHhjZC8weDUzMA0KWyAgMzcwLjk5Njg5Ml0gIFs8ZmZmZmZmZmY4MTZiOTg5OT5dIGlwX291
dHB1dCsweDU5LzB4ZTANClsgIDM3MC45OTY4OTZdICBbPGZmZmZmZmZmODE2YjgzYjg+XSBp
cF9sb2NhbF9vdXQrMHgyOC8weDkwDQpbICAzNzAuOTk2OTAxXSAgWzxmZmZmZmZmZjgxNmI4
OTZmPl0gaXBfcXVldWVfeG1pdCsweDE3Zi8weDRhMA0KWyAgMzcwLjk5NjkwNl0gIFs8ZmZm
ZmZmZmY4MTZiODdmMD5dID8gaXBfc2VuZF91bmljYXN0X3JlcGx5KzB4MzQwLzB4MzQwDQpb
ICAzNzAuOTk2OTEyXSAgWzxmZmZmZmZmZjgxMGEwYmE3Pl0gPyBnZXRuc3RpbWVvZmRheSsw
eDQ3LzB4ZTANClsgIDM3MC45OTY5MjZdICBbPGZmZmZmZmZmODE2MGY0Yzk+XSA/IF9fc2ti
X2Nsb25lKzB4MjkvMHgxMjANClsgIDM3MC45OTY5NDFdICBbPGZmZmZmZmZmODE2Y2VhMjA+
XSB0Y3BfdHJhbnNtaXRfc2tiKzB4NDAwLzB4OGQwDQpbICAzNzAuOTk2OTQ3XSAgWzxmZmZm
ZmZmZjgxNmQxMTA2Pl0gdGNwX3JldHJhbnNtaXRfc2tiKzB4MWM2LzB4NWEwDQpbICAzNzAu
OTk2OTUzXSAgWzxmZmZmZmZmZjgxNmQzM2IwPl0gPyB0Y3Bfd3JpdGVfdGltZXJfaGFuZGxl
cisweDFhMC8weDFhMA0KWyAgMzcwLjk5Njk1OV0gIFs8ZmZmZmZmZmY4MTZkMmYzOD5dIHRj
cF9yZXRyYW5zbWl0X3RpbWVyKzB4MzU4LzB4NjMwDQpbICAzNzAuOTk2OTY1XSAgWzxmZmZm
ZmZmZjgxNmQzMzRkPl0gdGNwX3dyaXRlX3RpbWVyX2hhbmRsZXIrMHgxM2QvMHgxYTANClsg
IDM3MC45OTY5NzFdICBbPGZmZmZmZmZmODE2ZDM0Mjg+XSB0Y3Bfd3JpdGVfdGltZXIrMHg3
OC8weDgwDQpbICAzNzAuOTk2OTc3XSAgWzxmZmZmZmZmZjgxMDczZjdjPl0gY2FsbF90aW1l
cl9mbisweDdjLzB4MTAwDQpbICAzNzAuOTk2OTgzXSAgWzxmZmZmZmZmZjgxMDczZjAwPl0g
PyBjYXNjYWRlKzB4YTAvMHhhMA0KWyAgMzcwLjk5Njk4OF0gIFs8ZmZmZmZmZmY4MTZkMzNi
MD5dID8gdGNwX3dyaXRlX3RpbWVyX2hhbmRsZXIrMHgxYTAvMHgxYTANClsgIDM3MC45OTY5
OThdICBbPGZmZmZmZmZmODE2ZDMzYjA+XSA/IHRjcF93cml0ZV90aW1lcl9oYW5kbGVyKzB4
MWEwLzB4MWEwDQpbICAzNzAuOTk3MDA0XSAgWzxmZmZmZmZmZjgxMDc0MjE3Pl0gcnVuX3Rp
bWVyX3NvZnRpcnErMHgyMTcvMHgyNTANClsgIDM3MC45OTcwMTFdICBbPGZmZmZmZmZmODEw
NmUzZDk+XSBfX2RvX3NvZnRpcnErMHhjOS8weDFhMA0KWyAgMzcwLjk5NzAxN10gIFs8ZmZm
ZmZmZmY4MTc0OGQzYz5dIGNhbGxfc29mdGlycSsweDFjLzB4MzANClsgIDM3MC45OTcwMjNd
ICBbPGZmZmZmZmZmODEwMGVkYjU+XSBkb19zb2Z0aXJxKzB4ODUvMHhmMA0KWyAgMzcwLjk5
NzAyOV0gIFs8ZmZmZmZmZmY4MTA2ZTI0ZT5dIGlycV9leGl0KzB4OWUvMHhkMA0KWyAgMzcw
Ljk5NzAzNl0gIFs8ZmZmZmZmZmY4MTMzOWY1Zj5dIHhlbl9ldnRjaG5fZG9fdXBjYWxsKzB4
MmYvMHg0MA0KWyAgMzcwLjk5NzA0Ml0gIFs8ZmZmZmZmZmY4MTc0OGQ5ZT5dIHhlbl9kb19o
eXBlcnZpc29yX2NhbGxiYWNrKzB4MWUvMHgzMA0KWyAgMzcwLjk5NzA0Nl0gIDxFT0k+ICBb
PGZmZmZmZmZmODEwMDEzYWE+XSA/IHhlbl9oeXBlcmNhbGxfc2NoZWRfb3ArMHhhLzB4MjAN
ClsgIDM3MC45OTcwNTddICBbPGZmZmZmZmZmODEwMDEzYWE+XSA/IHhlbl9oeXBlcmNhbGxf
c2NoZWRfb3ArMHhhLzB4MjANClsgIDM3MC45OTcwNjRdICBbPGZmZmZmZmZmODEwMDg2OTA+
XSA/IHhlbl9zYWZlX2hhbHQrMHgxMC8weDIwDQpbICAzNzAuOTk3MDcwXSAgWzxmZmZmZmZm
ZjgxMDE2MGQwPl0gPyBkZWZhdWx0X2lkbGUrMHg0MC8weDkwDQpbICAzNzAuOTk3MDc1XSAg
WzxmZmZmZmZmZjgxMDE2NDg2Pl0gPyBjcHVfaWRsZSsweDk2LzB4ZjANClsgIDM3MC45OTcw
ODFdICBbPGZmZmZmZmZmODE3MjJkM2M+XSA/IHJlc3RfaW5pdCsweGJjLzB4ZDANClsgIDM3
MC45OTcwOTNdICBbPGZmZmZmZmZmODE3MjJjODA+XSA/IGNzdW1fcGFydGlhbF9jb3B5X2dl
bmVyaWMrMHgxNzAvMHgxNzANClsgIDM3MC45OTcxMDJdICBbPGZmZmZmZmZmODFjZTBkZjI+
XSA/IHN0YXJ0X2tlcm5lbCsweDM5MC8weDM5ZA0KWyAgMzcwLjk5NzEwOF0gIFs8ZmZmZmZm
ZmY4MWNlMDg4Mj5dID8ga2VybmVsX2luaXQrMHgyMGIvMHgyMGINClsgIDM3MC45OTcxMTRd
ICBbPGZmZmZmZmZmODFjZTAzNTY+XSA/IHg4Nl82NF9zdGFydF9yZXNlcnZhdGlvbnMrMHgx
MzEvMHgxMzYNClsgIDM3MC45OTcxMjBdICBbPGZmZmZmZmZmODFjZTNkNjA+XSA/IHhlbl9z
dGFydF9rZXJuZWwrMHg3MGQvMHg3MGYNClsgIDM3MC45OTcxMjZdIC0tLVsgZW5kIHRyYWNl
IDJlMjhlZWM5M2I3YThiOWMgXS0tLQ0KWyAgMzcyLjg5MzU3MF0gLS0tLS0tLS0tLS0tWyBj
dXQgaGVyZSBdLS0tLS0tLS0tLS0tDQpbICAzNzIuODkzNTk0XSBXQVJOSU5HOiBhdCBkcml2
ZXJzL25ldC94ZW4tbmV0ZnJvbnQuYzo0NjUgeGVubmV0X3N0YXJ0X3htaXQrMHg3ZmUvMHg4
NjAoKQ0KWyAgMzcyLjg5MzYwMV0gTW9kdWxlcyBsaW5rZWQgaW46DQpbICAzNzIuODkzNjA3
XSBQaWQ6IDAsIGNvbW06IHN3YXBwZXIvMCBUYWludGVkOiBHICAgICAgICBXICAgIDMuNi4w
cHJlLXJjMS0yMDEyMTAxMSAjMQ0KWyAgMzcyLjg5MzYxM10gQ2FsbCBUcmFjZToNClsgIDM3
Mi44OTM2MTddICA8SVJRPiAgWzxmZmZmZmZmZjgxMDY2NGVhPl0gd2Fybl9zbG93cGF0aF9j
b21tb24rMHg3YS8weGIwDQpbICAzNzIuODkzNjMwXSAgWzxmZmZmZmZmZjgxMDY2NTM1Pl0g
d2Fybl9zbG93cGF0aF9udWxsKzB4MTUvMHgyMA0KWyAgMzcyLjg5MzYzNl0gIFs8ZmZmZmZm
ZmY4MTQ2ZDg5ZT5dIHhlbm5ldF9zdGFydF94bWl0KzB4N2ZlLzB4ODYwDQpbICAzNzIuODkz
NjQ0XSAgWzxmZmZmZmZmZjgxNjFmMzQ5Pl0gZGV2X2hhcmRfc3RhcnRfeG1pdCsweDIwOS8w
eDQ2MA0KWyAgMzcyLjg5MzY1MV0gIFs8ZmZmZmZmZmY4MTYzYjAzNj5dIHNjaF9kaXJlY3Rf
eG1pdCsweGY2LzB4MjkwDQpbICAzNzIuODkzNjU3XSAgWzxmZmZmZmZmZjgxNjFmNzQ2Pl0g
ZGV2X3F1ZXVlX3htaXQrMHgxYTYvMHg1YTANClsgIDM3Mi44OTM2NjNdICBbPGZmZmZmZmZm
ODE2MWY1YTA+XSA/IGRldl9oYXJkX3N0YXJ0X3htaXQrMHg0NjAvMHg0NjANClsgIDM3Mi44
OTM2NjldICBbPGZmZmZmZmZmODEwYjE0MTc+XSA/IGxvY2tfcmVsZWFzZSsweDExNy8weDI1
MA0KWyAgMzcyLjg5MzY3Nl0gIFs8ZmZmZmZmZmY4MTZiOTUzNj5dIGlwX2ZpbmlzaF9vdXRw
dXQrMHgyMjYvMHg1MzANClsgIDM3Mi44OTM2ODJdICBbPGZmZmZmZmZmODE2YjkzZGQ+XSA/
IGlwX2ZpbmlzaF9vdXRwdXQrMHhjZC8weDUzMA0KWyAgMzcyLjg5MzY4OF0gIFs8ZmZmZmZm
ZmY4MTZiOTg5OT5dIGlwX291dHB1dCsweDU5LzB4ZTANClsgIDM3Mi44OTM2OTRdICBbPGZm
ZmZmZmZmODE2YjgzYjg+XSBpcF9sb2NhbF9vdXQrMHgyOC8weDkwDQpbICAzNzIuODkzNjk5
XSAgWzxmZmZmZmZmZjgxNmI4OTZmPl0gaXBfcXVldWVfeG1pdCsweDE3Zi8weDRhMA0KWyAg
MzcyLjg5MzcwNV0gIFs8ZmZmZmZmZmY4MTZiODdmMD5dID8gaXBfc2VuZF91bmljYXN0X3Jl
cGx5KzB4MzQwLzB4MzQwDQpbICAzNzIuODkzNzExXSAgWzxmZmZmZmZmZjgxMGEwYmE3Pl0g
PyBnZXRuc3RpbWVvZmRheSsweDQ3LzB4ZTANClsgIDM3Mi44OTM3MThdICBbPGZmZmZmZmZm
ODE2MGY0Yzk+XSA/IF9fc2tiX2Nsb25lKzB4MjkvMHgxMjANClsgIDM3Mi44OTM3MjRdICBb
PGZmZmZmZmZmODE2Y2VhMjA+XSB0Y3BfdHJhbnNtaXRfc2tiKzB4NDAwLzB4OGQwDQpbICAz
NzIuODkzNzMwXSAgWzxmZmZmZmZmZjgxNmQxMTA2Pl0gdGNwX3JldHJhbnNtaXRfc2tiKzB4
MWM2LzB4NWEwDQpbICAzNzIuODkzNzM3XSAgWzxmZmZmZmZmZjgxNmQzM2IwPl0gPyB0Y3Bf
d3JpdGVfdGltZXJfaGFuZGxlcisweDFhMC8weDFhMA0KWyAgMzcyLjg5Mzc0M10gIFs8ZmZm
ZmZmZmY4MTZkMmYzOD5dIHRjcF9yZXRyYW5zbWl0X3RpbWVyKzB4MzU4LzB4NjMwDQpbICAz
NzIuODkzNzQ4XSAgWzxmZmZmZmZmZjgxNmQzMzRkPl0gdGNwX3dyaXRlX3RpbWVyX2hhbmRs
ZXIrMHgxM2QvMHgxYTANClsgIDM3Mi44OTM3NTRdICBbPGZmZmZmZmZmODE2ZDM0Mjg+XSB0
Y3Bfd3JpdGVfdGltZXIrMHg3OC8weDgwDQpbICAzNzIuODkzNzYwXSAgWzxmZmZmZmZmZjgx
MDczZjdjPl0gY2FsbF90aW1lcl9mbisweDdjLzB4MTAwDQpbICAzNzIuODkzNzY1XSAgWzxm
ZmZmZmZmZjgxMDczZjAwPl0gPyBjYXNjYWRlKzB4YTAvMHhhMA0KWyAgMzcyLjg5Mzc3MV0g
IFs8ZmZmZmZmZmY4MTZkMzNiMD5dID8gdGNwX3dyaXRlX3RpbWVyX2hhbmRsZXIrMHgxYTAv
MHgxYTANClsgIDM3Mi44OTM3NzddICBbPGZmZmZmZmZmODE2ZDMzYjA+XSA/IHRjcF93cml0
ZV90aW1lcl9oYW5kbGVyKzB4MWEwLzB4MWEwDQpbICAzNzIuODkzOTM5XSAgWzxmZmZmZmZm
ZjgxMDc0MjE3Pl0gcnVuX3RpbWVyX3NvZnRpcnErMHgyMTcvMHgyNTANClsgIDM3Mi44OTM5
NDZdICBbPGZmZmZmZmZmODEwNmUzZDk+XSBfX2RvX3NvZnRpcnErMHhjOS8weDFhMA0KWyAg
MzcyLjg5Mzk1Ml0gIFs8ZmZmZmZmZmY4MTc0OGQzYz5dIGNhbGxfc29mdGlycSsweDFjLzB4
MzANClsgIDM3Mi44OTM5NThdICBbPGZmZmZmZmZmODEwMGVkYjU+XSBkb19zb2Z0aXJxKzB4
ODUvMHhmMA0KWyAgMzcyLjg5Mzk2M10gIFs8ZmZmZmZmZmY4MTA2ZTI0ZT5dIGlycV9leGl0
KzB4OWUvMHhkMA0KWyAgMzcyLjg5Mzk3MF0gIFs8ZmZmZmZmZmY4MTMzOWY1Zj5dIHhlbl9l
dnRjaG5fZG9fdXBjYWxsKzB4MmYvMHg0MA0KWyAgMzcyLjg5Mzk3Nl0gIFs8ZmZmZmZmZmY4
MTc0OGQ5ZT5dIHhlbl9kb19oeXBlcnZpc29yX2NhbGxiYWNrKzB4MWUvMHgzMA0KWyAgMzcy
Ljg5Mzk4MF0gIDxFT0k+ICBbPGZmZmZmZmZmODEwMDEzYWE+XSA/IHhlbl9oeXBlcmNhbGxf
c2NoZWRfb3ArMHhhLzB4MjANClsgIDM3Mi44OTM5OTBdICBbPGZmZmZmZmZmODEwMDEzYWE+
XSA/IHhlbl9oeXBlcmNhbGxfc2NoZWRfb3ArMHhhLzB4MjANClsgIDM3Mi44OTM5OTddICBb
PGZmZmZmZmZmODEwMDg2OTA+XSA/IHhlbl9zYWZlX2hhbHQrMHgxMC8weDIwDQpbICAzNzIu
ODk0MDAzXSAgWzxmZmZmZmZmZjgxMDE2MGQwPl0gPyBkZWZhdWx0X2lkbGUrMHg0MC8weDkw
DQpbICAzNzIuODk0MDA4XSAgWzxmZmZmZmZmZjgxMDE2NDg2Pl0gPyBjcHVfaWRsZSsweDk2
LzB4ZjANClsgIDM3Mi44OTQwMTRdICBbPGZmZmZmZmZmODE3MjJkM2M+XSA/IHJlc3RfaW5p
dCsweGJjLzB4ZDANClsgIDM3Mi44OTQwMTldICBbPGZmZmZmZmZmODE3MjJjODA+XSA/IGNz
dW1fcGFydGlhbF9jb3B5X2dlbmVyaWMrMHgxNzAvMHgxNzANClsgIDM3Mi44OTQwMjddICBb
PGZmZmZmZmZmODFjZTBkZjI+XSA/IHN0YXJ0X2tlcm5lbCsweDM5MC8weDM5ZA0KWyAgMzcy
Ljg5NDAzNl0gIFs8ZmZmZmZmZmY4MWNlMDg4Mj5dID8ga2VybmVsX2luaXQrMHgyMGIvMHgy
MGINClsgIDM3Mi44OTQwNDJdICBbPGZmZmZmZmZmODFjZTAzNTY+XSA/IHg4Nl82NF9zdGFy
dF9yZXNlcnZhdGlvbnMrMHgxMzEvMHgxMzYNClsgIDM3Mi44OTQwNDhdICBbPGZmZmZmZmZm
ODFjZTNkNjA+XSA/IHhlbl9zdGFydF9rZXJuZWwrMHg3MGQvMHg3MGYNClsgIDM3Mi44OTQw
NTRdIC0tLVsgZW5kIHRyYWNlIDJlMjhlZWM5M2I3YThiOWQgXS0tLQ0KWyAgMzc0Ljk4Njc3
MF0gLS0tLS0tLS0tLS0tWyBjdXQgaGVyZSBdLS0tLS0tLS0tLS0tDQpbICAzNzQuOTg2Nzk1
XSBXQVJOSU5HOiBhdCBkcml2ZXJzL25ldC94ZW4tbmV0ZnJvbnQuYzo0NjUgeGVubmV0X3N0
YXJ0X3htaXQrMHg3ZmUvMHg4NjAoKQ0KWyAgMzc0Ljk4NjgwMl0gTW9kdWxlcyBsaW5rZWQg
aW46DQpbICAzNzQuOTg2ODEwXSBQaWQ6IDAsIGNvbW06IHN3YXBwZXIvMCBUYWludGVkOiBH
ICAgICAgICBXICAgIDMuNi4wcHJlLXJjMS0yMDEyMTAxMSAjMQ0KWyAgMzc0Ljk4NjgxNl0g
Q2FsbCBUcmFjZToNClsgIDM3NC45ODY4MTldICA8SVJRPiAgWzxmZmZmZmZmZjgxMDY2NGVh
Pl0gd2Fybl9zbG93cGF0aF9jb21tb24rMHg3YS8weGIwDQpbICAzNzQuOTg2ODMzXSAgWzxm
ZmZmZmZmZjgxMDY2NTM1Pl0gd2Fybl9zbG93cGF0aF9udWxsKzB4MTUvMHgyMA0KWyAgMzc0
Ljk4NjgzOF0gIFs8ZmZmZmZmZmY4MTQ2ZDg5ZT5dIHhlbm5ldF9zdGFydF94bWl0KzB4N2Zl
LzB4ODYwDQpbICAzNzQuOTg2ODQ3XSAgWzxmZmZmZmZmZjgxNjFmMzQ5Pl0gZGV2X2hhcmRf
c3RhcnRfeG1pdCsweDIwOS8weDQ2MA0KWyAgMzc0Ljk4Njg1NF0gIFs8ZmZmZmZmZmY4MTYz
YjAzNj5dIHNjaF9kaXJlY3RfeG1pdCsweGY2LzB4MjkwDQpbICAzNzQuOTg2ODU5XSAgWzxm
ZmZmZmZmZjgxNjFmNzQ2Pl0gZGV2X3F1ZXVlX3htaXQrMHgxYTYvMHg1YTANClsgIDM3NC45
ODY4NjRdICBbPGZmZmZmZmZmODE2MWY1YTA+XSA/IGRldl9oYXJkX3N0YXJ0X3htaXQrMHg0
NjAvMHg0NjANClsgIDM3NC45ODY4NzFdICBbPGZmZmZmZmZmODEwYjE0MTc+XSA/IGxvY2tf
cmVsZWFzZSsweDExNy8weDI1MA0KWyAgMzc0Ljk4Njg3OV0gIFs8ZmZmZmZmZmY4MTZiOTUz
Nj5dIGlwX2ZpbmlzaF9vdXRwdXQrMHgyMjYvMHg1MzANClsgIDM3NC45ODY4ODRdICBbPGZm
ZmZmZmZmODE2YjkzZGQ+XSA/IGlwX2ZpbmlzaF9vdXRwdXQrMHhjZC8weDUzMA0KWyAgMzc0
Ljk4Njg5MF0gIFs8ZmZmZmZmZmY4MTZiOTg5OT5dIGlwX291dHB1dCsweDU5LzB4ZTANClsg
IDM3NC45ODY4OTRdICBbPGZmZmZmZmZmODE2YjgzYjg+XSBpcF9sb2NhbF9vdXQrMHgyOC8w
eDkwDQpbICAzNzQuOTg2ODk5XSAgWzxmZmZmZmZmZjgxNmI4OTZmPl0gaXBfcXVldWVfeG1p
dCsweDE3Zi8weDRhMA0KWyAgMzc0Ljk4NjkwNF0gIFs8ZmZmZmZmZmY4MTZiODdmMD5dID8g
aXBfc2VuZF91bmljYXN0X3JlcGx5KzB4MzQwLzB4MzQwDQpbICAzNzQuOTg2OTExXSAgWzxm
ZmZmZmZmZjgxMGEwYmE3Pl0gPyBnZXRuc3RpbWVvZmRheSsweDQ3LzB4ZTANClsgIDM3NC45
ODY5MThdICBbPGZmZmZmZmZmODE2MGY0Yzk+XSA/IF9fc2tiX2Nsb25lKzB4MjkvMHgxMjAN
ClsgIDM3NC45ODY5MjZdICBbPGZmZmZmZmZmODE2Y2VhMjA+XSB0Y3BfdHJhbnNtaXRfc2ti
KzB4NDAwLzB4OGQwDQpbICAzNzQuOTg2OTMxXSAgWzxmZmZmZmZmZjgxNmQxMTA2Pl0gdGNw
X3JldHJhbnNtaXRfc2tiKzB4MWM2LzB4NWEwDQpbICAzNzQuOTg2OTM3XSAgWzxmZmZmZmZm
ZjgxNmQzM2IwPl0gPyB0Y3Bfd3JpdGVfdGltZXJfaGFuZGxlcisweDFhMC8weDFhMA0KWyAg
Mzc0Ljk4Njk0Ml0gIFs8ZmZmZmZmZmY4MTZkMmYzOD5dIHRjcF9yZXRyYW5zbWl0X3RpbWVy
KzB4MzU4LzB4NjMwDQpbICAzNzQuOTg2OTQ3XSAgWzxmZmZmZmZmZjgxNmQzMzRkPl0gdGNw
X3dyaXRlX3RpbWVyX2hhbmRsZXIrMHgxM2QvMHgxYTANClsgIDM3NC45ODY5NTNdICBbPGZm
ZmZmZmZmODE2ZDM0Mjg+XSB0Y3Bfd3JpdGVfdGltZXIrMHg3OC8weDgwDQpbICAzNzQuOTg2
OTU4XSAgWzxmZmZmZmZmZjgxMDczZjdjPl0gY2FsbF90aW1lcl9mbisweDdjLzB4MTAwDQpb
ICAzNzQuOTg2OTYzXSAgWzxmZmZmZmZmZjgxMDczZjAwPl0gPyBjYXNjYWRlKzB4YTAvMHhh
MA0KWyAgMzc0Ljk4Njk2N10gIFs8ZmZmZmZmZmY4MTZkMzNiMD5dID8gdGNwX3dyaXRlX3Rp
bWVyX2hhbmRsZXIrMHgxYTAvMHgxYTANClsgIDM3NC45ODY5NzNdICBbPGZmZmZmZmZmODE2
ZDMzYjA+XSA/IHRjcF93cml0ZV90aW1lcl9oYW5kbGVyKzB4MWEwLzB4MWEwDQpbICAzNzQu
OTg2OTc4XSAgWzxmZmZmZmZmZjgxMDc0MjE3Pl0gcnVuX3RpbWVyX3NvZnRpcnErMHgyMTcv
MHgyNTANClsgIDM3NC45ODY5ODVdICBbPGZmZmZmZmZmODEwNmUzZDk+XSBfX2RvX3NvZnRp
cnErMHhjOS8weDFhMA0KWyAgMzc0Ljk4Njk5MV0gIFs8ZmZmZmZmZmY4MTc0OGQzYz5dIGNh
bGxfc29mdGlycSsweDFjLzB4MzANClsgIDM3NC45ODY5OTddICBbPGZmZmZmZmZmODEwMGVk
YjU+XSBkb19zb2Z0aXJxKzB4ODUvMHhmMA0KWyAgMzc0Ljk4NzAwMl0gIFs8ZmZmZmZmZmY4
MTA2ZTI0ZT5dIGlycV9leGl0KzB4OWUvMHhkMA0KWyAgMzc0Ljk4NzAwOV0gIFs8ZmZmZmZm
ZmY4MTMzOWY1Zj5dIHhlbl9ldnRjaG5fZG9fdXBjYWxsKzB4MmYvMHg0MA0KWyAgMzc0Ljk4
NzAxNF0gIFs8ZmZmZmZmZmY4MTc0OGQ5ZT5dIHhlbl9kb19oeXBlcnZpc29yX2NhbGxiYWNr
KzB4MWUvMHgzMA0KWyAgMzc0Ljk4NzAxOF0gIDxFT0k+ICBbPGZmZmZmZmZmODEwMDEzYWE+
XSA/IHhlbl9oeXBlcmNhbGxfc2NoZWRfb3ArMHhhLzB4MjANClsgIDM3NC45ODcwMjhdICBb
PGZmZmZmZmZmODEwMDEzYWE+XSA/IHhlbl9oeXBlcmNhbGxfc2NoZWRfb3ArMHhhLzB4MjAN
ClsgIDM3NC45ODcwMzldICBbPGZmZmZmZmZmODEwMDg2OTA+XSA/IHhlbl9zYWZlX2hhbHQr
MHgxMC8weDIwDQpbICAzNzQuOTg3MDU5XSAgWzxmZmZmZmZmZjgxMDE2MGQwPl0gPyBkZWZh
dWx0X2lkbGUrMHg0MC8weDkwDQpbICAzNzQuOTg3MDY0XSAgWzxmZmZmZmZmZjgxMDE2NDg2
Pl0gPyBjcHVfaWRsZSsweDk2LzB4ZjANClsgIDM3NC45ODcwNzBdICBbPGZmZmZmZmZmODE3
MjJkM2M+XSA/IHJlc3RfaW5pdCsweGJjLzB4ZDANClsgIDM3NC45ODcwNzVdICBbPGZmZmZm
ZmZmODE3MjJjODA+XSA/IGNzdW1fcGFydGlhbF9jb3B5X2dlbmVyaWMrMHgxNzAvMHgxNzAN
ClsgIDM3NC45ODcwODRdICBbPGZmZmZmZmZmODFjZTBkZjI+XSA/IHN0YXJ0X2tlcm5lbCsw
eDM5MC8weDM5ZA0KWyAgMzc0Ljk4NzA5MV0gIFs8ZmZmZmZmZmY4MWNlMDg4Mj5dID8ga2Vy
bmVsX2luaXQrMHgyMGIvMHgyMGINClsgIDM3NC45ODcwOTddICBbPGZmZmZmZmZmODFjZTAz
NTY+XSA/IHg4Nl82NF9zdGFydF9yZXNlcnZhdGlvbnMrMHgxMzEvMHgxMzYNClsgIDM3NC45
ODcxMDRdICBbPGZmZmZmZmZmODFjZTNkNjA+XSA/IHhlbl9zdGFydF9rZXJuZWwrMHg3MGQv
MHg3MGYNClsgIDM3NC45ODcxMTBdIC0tLVsgZW5kIHRyYWNlIDJlMjhlZWM5M2I3YThiOWUg
XS0tLQ0KWyAgMzc2LjY5MzUyOV0gLS0tLS0tLS0tLS0tWyBjdXQgaGVyZSBdLS0tLS0tLS0t
LS0tDQpbICAzNzYuNjkzNTgyXSBXQVJOSU5HOiBhdCBkcml2ZXJzL25ldC94ZW4tbmV0ZnJv
bnQuYzo0NjUgeGVubmV0X3N0YXJ0X3htaXQrMHg3ZmUvMHg4NjAoKQ0KWyAgMzc2LjY5MzYw
N10gTW9kdWxlcyBsaW5rZWQgaW46DQpbICAzNzYuNjkzNjMwXSBQaWQ6IDAsIGNvbW06IHN3
YXBwZXIvMCBUYWludGVkOiBHICAgICAgICBXICAgIDMuNi4wcHJlLXJjMS0yMDEyMTAxMSAj
MQ0KWyAgMzc2LjY5MzY1NF0gQ2FsbCBUcmFjZToNClsgIDM3Ni42OTM2NjZdICA8SVJRPiAg
WzxmZmZmZmZmZjgxMDY2NGVhPl0gd2Fybl9zbG93cGF0aF9jb21tb24rMHg3YS8weGIwDQpb
ICAzNzYuNjkzNzA4XSAgWzxmZmZmZmZmZjgxMDY2NTM1Pl0gd2Fybl9zbG93cGF0aF9udWxs
KzB4MTUvMHgyMA0KWyAgMzc2LjY5MzczMV0gIFs8ZmZmZmZmZmY4MTQ2ZDg5ZT5dIHhlbm5l
dF9zdGFydF94bWl0KzB4N2ZlLzB4ODYwDQpbICAzNzYuNjkzNzU4XSAgWzxmZmZmZmZmZjgx
NjFmMzQ5Pl0gZGV2X2hhcmRfc3RhcnRfeG1pdCsweDIwOS8weDQ2MA0KWyAgMzc2LjY5Mzc4
M10gIFs8ZmZmZmZmZmY4MTYzYjAzNj5dIHNjaF9kaXJlY3RfeG1pdCsweGY2LzB4MjkwDQpb
ICAzNzYuNjkzODA2XSAgWzxmZmZmZmZmZjgxNjFmNzQ2Pl0gZGV2X3F1ZXVlX3htaXQrMHgx
YTYvMHg1YTANClsgIDM3Ni42OTM4MjhdICBbPGZmZmZmZmZmODE2MWY1YTA+XSA/IGRldl9o
YXJkX3N0YXJ0X3htaXQrMHg0NjAvMHg0NjANClsgIDM3Ni42OTM4NTJdICBbPGZmZmZmZmZm
ODEwYjE0MTc+XSA/IGxvY2tfcmVsZWFzZSsweDExNy8weDI1MA0KWyAgMzc2LjY5Mzg3N10g
IFs8ZmZmZmZmZmY4MTZiOTUzNj5dIGlwX2ZpbmlzaF9vdXRwdXQrMHgyMjYvMHg1MzANClsg
IDM3Ni42OTM5MDJdICBbPGZmZmZmZmZmODE2YjkzZGQ+XSA/IGlwX2ZpbmlzaF9vdXRwdXQr
MHhjZC8weDUzMA0KWyAgMzc2LjY5MzkyNl0gIFs8ZmZmZmZmZmY4MTZiOTg5OT5dIGlwX291
dHB1dCsweDU5LzB4ZTANClsgIDM3Ni42OTM5NDhdICBbPGZmZmZmZmZmODE2YjgzYjg+XSBp
cF9sb2NhbF9vdXQrMHgyOC8weDkwDQpbICAzNzYuNjkzOTcwXSAgWzxmZmZmZmZmZjgxNmI4
OTZmPl0gaXBfcXVldWVfeG1pdCsweDE3Zi8weDRhMA0KWyAgMzc2LjY5Mzk5MV0gIFs8ZmZm
ZmZmZmY4MTZiODdmMD5dID8gaXBfc2VuZF91bmljYXN0X3JlcGx5KzB4MzQwLzB4MzQwDQpb
ICAzNzYuNjk0MDE3XSAgWzxmZmZmZmZmZjgxMGEwYmE3Pl0gPyBnZXRuc3RpbWVvZmRheSsw
eDQ3LzB4ZTANClsgIDM3Ni42OTQwNDBdICBbPGZmZmZmZmZmODE2MGY0Yzk+XSA/IF9fc2ti
X2Nsb25lKzB4MjkvMHgxMjANClsgIDM3Ni42OTQwNjJdICBbPGZmZmZmZmZmODE2Y2VhMjA+
XSB0Y3BfdHJhbnNtaXRfc2tiKzB4NDAwLzB4OGQwDQpbICAzNzYuNjk0MDg1XSAgWzxmZmZm
ZmZmZjgxNmQxMTA2Pl0gdGNwX3JldHJhbnNtaXRfc2tiKzB4MWM2LzB4NWEwDQpbICAzNzYu
Njk0MTEwXSAgWzxmZmZmZmZmZjgxNmQzM2IwPl0gPyB0Y3Bfd3JpdGVfdGltZXJfaGFuZGxl
cisweDFhMC8weDFhMA0KWyAgMzc2LjY5NDEzM10gIFs8ZmZmZmZmZmY4MTZkMmYzOD5dIHRj
cF9yZXRyYW5zbWl0X3RpbWVyKzB4MzU4LzB4NjMwDQpbICAzNzYuNjk0MTU2XSAgWzxmZmZm
ZmZmZjgxNmQzMzRkPl0gdGNwX3dyaXRlX3RpbWVyX2hhbmRsZXIrMHgxM2QvMHgxYTANClsg
IDM3Ni42OTQxNzldICBbPGZmZmZmZmZmODE2ZDM0Mjg+XSB0Y3Bfd3JpdGVfdGltZXIrMHg3
OC8weDgwDQpbICAzNzYuNjk0MjAxXSAgWzxmZmZmZmZmZjgxMDczZjdjPl0gY2FsbF90aW1l
cl9mbisweDdjLzB4MTAwDQpbICAzNzYuNjk0MjIyXSAgWzxmZmZmZmZmZjgxMDczZjAwPl0g
PyBjYXNjYWRlKzB4YTAvMHhhMA0KWyAgMzc2LjY5NDI0Ml0gIFs8ZmZmZmZmZmY4MTZkMzNi
MD5dID8gdGNwX3dyaXRlX3RpbWVyX2hhbmRsZXIrMHgxYTAvMHgxYTANClsgIDM3Ni42OTQy
NjddICBbPGZmZmZmZmZmODE2ZDMzYjA+XSA/IHRjcF93cml0ZV90aW1lcl9oYW5kbGVyKzB4
MWEwLzB4MWEwDQpbICAzNzYuNjk0MjkwXSAgWzxmZmZmZmZmZjgxMDc0MjE3Pl0gcnVuX3Rp
bWVyX3NvZnRpcnErMHgyMTcvMHgyNTANClsgIDM3Ni42OTQzMTVdICBbPGZmZmZmZmZmODEw
NmUzZDk+XSBfX2RvX3NvZnRpcnErMHhjOS8weDFhMA0KWyAgMzc2LjY5NDMzN10gIFs8ZmZm
ZmZmZmY4MTc0OGQzYz5dIGNhbGxfc29mdGlycSsweDFjLzB4MzANClsgIDM3Ni42OTQzNThd
ICBbPGZmZmZmZmZmODEwMGVkYjU+XSBkb19zb2Z0aXJxKzB4ODUvMHhmMA0KWyAgMzc2LjY5
NDM4MF0gIFs8ZmZmZmZmZmY4MTA2ZTI0ZT5dIGlycV9leGl0KzB4OWUvMHhkMA0KWyAgMzc2
LjY5NDQwNF0gIFs8ZmZmZmZmZmY4MTMzOWY1Zj5dIHhlbl9ldnRjaG5fZG9fdXBjYWxsKzB4
MmYvMHg0MA0KWyAgMzc2LjY5NDQyN10gIFs8ZmZmZmZmZmY4MTc0OGQ5ZT5dIHhlbl9kb19o
eXBlcnZpc29yX2NhbGxiYWNrKzB4MWUvMHgzMA0KWyAgMzc2LjY5NDQ0Nl0gIDxFT0k+ICBb
PGZmZmZmZmZmODEwMDEzYWE+XSA/IHhlbl9oeXBlcmNhbGxfc2NoZWRfb3ArMHhhLzB4MjAN
ClsgIDM3Ni42OTQ0ODRdICBbPGZmZmZmZmZmODEwMDEzYWE+XSA/IHhlbl9oeXBlcmNhbGxf
c2NoZWRfb3ArMHhhLzB4MjANClsgIDM3Ni42OTQ1MDldICBbPGZmZmZmZmZmODEwMDg2OTA+
XSA/IHhlbl9zYWZlX2hhbHQrMHgxMC8weDIwDQpbICAzNzYuNjk0NTMxXSAgWzxmZmZmZmZm
ZjgxMDE2MGQwPl0gPyBkZWZhdWx0X2lkbGUrMHg0MC8weDkwDQpbICAzNzYuNjk0NTUyXSAg
WzxmZmZmZmZmZjgxMDE2NDg2Pl0gPyBjcHVfaWRsZSsweDk2LzB4ZjANClsgIDM3Ni42OTQ1
NzNdICBbPGZmZmZmZmZmODE3MjJkM2M+XSA/IHJlc3RfaW5pdCsweGJjLzB4ZDANClsgIDM3
Ni42OTQ1OTRdICBbPGZmZmZmZmZmODE3MjJjODA+XSA/IGNzdW1fcGFydGlhbF9jb3B5X2dl
bmVyaWMrMHgxNzAvMHgxNzANClsgIDM3Ni42OTQ2MjFdICBbPGZmZmZmZmZmODFjZTBkZjI+
XSA/IHN0YXJ0X2tlcm5lbCsweDM5MC8weDM5ZA0KWyAgMzc2LjY5NDY0NF0gIFs8ZmZmZmZm
ZmY4MWNlMDg4Mj5dID8ga2VybmVsX2luaXQrMHgyMGIvMHgyMGINClsgIDM3Ni42OTQ2NjZd
ICBbPGZmZmZmZmZmODFjZTAzNTY+XSA/IHg4Nl82NF9zdGFydF9yZXNlcnZhdGlvbnMrMHgx
MzEvMHgxMzYNClsgIDM3Ni42OTQ2OTFdICBbPGZmZmZmZmZmODFjZTNkNjA+XSA/IHhlbl9z
dGFydF9rZXJuZWwrMHg3MGQvMHg3MGYNClsgIDM3Ni42OTQ3MTJdIC0tLVsgZW5kIHRyYWNl
IDJlMjhlZWM5M2I3YThiOWYgXS0tLQ0KWyAgMzg0LjI5MzU5Ml0gLS0tLS0tLS0tLS0tWyBj
dXQgaGVyZSBdLS0tLS0tLS0tLS0tDQpbICAzODQuMjkzNjIyXSBXQVJOSU5HOiBhdCBkcml2
ZXJzL25ldC94ZW4tbmV0ZnJvbnQuYzo0NjUgeGVubmV0X3N0YXJ0X3htaXQrMHg3ZmUvMHg4
NjAoKQ0KWyAgMzg0LjI5MzYyOV0gTW9kdWxlcyBsaW5rZWQgaW46DQpbICAzODQuMjkzNjM3
XSBQaWQ6IDAsIGNvbW06IHN3YXBwZXIvMCBUYWludGVkOiBHICAgICAgICBXICAgIDMuNi4w
cHJlLXJjMS0yMDEyMTAxMSAjMQ0KWyAgMzg0LjI5MzY0M10gQ2FsbCBUcmFjZToNClsgIDM4
NC4yOTM2NDddICA8SVJRPiAgWzxmZmZmZmZmZjgxMDY2NGVhPl0gd2Fybl9zbG93cGF0aF9j
b21tb24rMHg3YS8weGIwDQpbICAzODQuMjkzNjYyXSAgWzxmZmZmZmZmZjgxMDY2NTM1Pl0g
d2Fybl9zbG93cGF0aF9udWxsKzB4MTUvMHgyMA0KWyAgMzg0LjI5MzY2N10gIFs8ZmZmZmZm
ZmY4MTQ2ZDg5ZT5dIHhlbm5ldF9zdGFydF94bWl0KzB4N2ZlLzB4ODYwDQpbICAzODQuMjkz
Njc2XSAgWzxmZmZmZmZmZjgxNjFmMzQ5Pl0gZGV2X2hhcmRfc3RhcnRfeG1pdCsweDIwOS8w
eDQ2MA0KWyAgMzg0LjI5MzY4M10gIFs8ZmZmZmZmZmY4MTYzYjAzNj5dIHNjaF9kaXJlY3Rf
eG1pdCsweGY2LzB4MjkwDQpbICAzODQuMjkzNjg5XSAgWzxmZmZmZmZmZjgxNjFmNzQ2Pl0g
ZGV2X3F1ZXVlX3htaXQrMHgxYTYvMHg1YTANClsgIDM4NC4yOTM2OTZdICBbPGZmZmZmZmZm
ODE2MWY1YTA+XSA/IGRldl9oYXJkX3N0YXJ0X3htaXQrMHg0NjAvMHg0NjANClsgIDM4NC4y
OTM3MDRdICBbPGZmZmZmZmZmODEwYjE0MTc+XSA/IGxvY2tfcmVsZWFzZSsweDExNy8weDI1
MA0KWyAgMzg0LjI5MzcxMV0gIFs8ZmZmZmZmZmY4MTZiOTUzNj5dIGlwX2ZpbmlzaF9vdXRw
dXQrMHgyMjYvMHg1MzANClsgIDM4NC4yOTM3MTddICBbPGZmZmZmZmZmODE2YjkzZGQ+XSA/
IGlwX2ZpbmlzaF9vdXRwdXQrMHhjZC8weDUzMA0KWyAgMzg0LjI5MzcyNF0gIFs8ZmZmZmZm
ZmY4MTZiOTg5OT5dIGlwX291dHB1dCsweDU5LzB4ZTANClsgIDM4NC4yOTM3MjldICBbPGZm
ZmZmZmZmODE2YjgzYjg+XSBpcF9sb2NhbF9vdXQrMHgyOC8weDkwDQpbICAzODQuMjkzNzM1
XSAgWzxmZmZmZmZmZjgxNmI4OTZmPl0gaXBfcXVldWVfeG1pdCsweDE3Zi8weDRhMA0KWyAg
Mzg0LjI5Mzc0MV0gIFs8ZmZmZmZmZmY4MTZiODdmMD5dID8gaXBfc2VuZF91bmljYXN0X3Jl
cGx5KzB4MzQwLzB4MzQwDQpbICAzODQuMjkzNzQ3XSAgWzxmZmZmZmZmZjgxMGEwYmE3Pl0g
PyBnZXRuc3RpbWVvZmRheSsweDQ3LzB4ZTANClsgIDM4NC4yOTM3NTRdICBbPGZmZmZmZmZm
ODE2MGY0Yzk+XSA/IF9fc2tiX2Nsb25lKzB4MjkvMHgxMjANClsgIDM4NC4yOTM3NjBdICBb
PGZmZmZmZmZmODE2Y2VhMjA+XSB0Y3BfdHJhbnNtaXRfc2tiKzB4NDAwLzB4OGQwDQpbICAz
ODQuMjkzNzY3XSAgWzxmZmZmZmZmZjgxNmQxMTA2Pl0gdGNwX3JldHJhbnNtaXRfc2tiKzB4
MWM2LzB4NWEwDQpbICAzODQuMjkzNzc1XSAgWzxmZmZmZmZmZjgxNmQzM2IwPl0gPyB0Y3Bf
d3JpdGVfdGltZXJfaGFuZGxlcisweDFhMC8weDFhMA0KWyAgMzg0LjI5Mzc4MV0gIFs8ZmZm
ZmZmZmY4MTZkMmYzOD5dIHRjcF9yZXRyYW5zbWl0X3RpbWVyKzB4MzU4LzB4NjMwDQpbICAz
ODQuMjkzNzg3XSAgWzxmZmZmZmZmZjgxNmQzMzRkPl0gdGNwX3dyaXRlX3RpbWVyX2hhbmRs
ZXIrMHgxM2QvMHgxYTANClsgIDM4NC4yOTM3OTNdICBbPGZmZmZmZmZmODE2ZDM0Mjg+XSB0
Y3Bfd3JpdGVfdGltZXIrMHg3OC8weDgwDQpbICAzODQuMjkzODAwXSAgWzxmZmZmZmZmZjgx
MDczZjdjPl0gY2FsbF90aW1lcl9mbisweDdjLzB4MTAwDQpbICAzODQuMjkzODA1XSAgWzxm
ZmZmZmZmZjgxMDczZjAwPl0gPyBjYXNjYWRlKzB4YTAvMHhhMA0KWyAgMzg0LjI5MzgxMF0g
IFs8ZmZmZmZmZmY4MTZkMzNiMD5dID8gdGNwX3dyaXRlX3RpbWVyX2hhbmRsZXIrMHgxYTAv
MHgxYTANClsgIDM4NC4yOTM4MjRdICBbPGZmZmZmZmZmODE2ZDMzYjA+XSA/IHRjcF93cml0
ZV90aW1lcl9oYW5kbGVyKzB4MWEwLzB4MWEwDQpbICAzODQuMjkzODMwXSAgWzxmZmZmZmZm
ZjgxMDc0MjE3Pl0gcnVuX3RpbWVyX3NvZnRpcnErMHgyMTcvMHgyNTANClsgIDM4NC4yOTM4
MzhdICBbPGZmZmZmZmZmODEwNmUzZDk+XSBfX2RvX3NvZnRpcnErMHhjOS8weDFhMA0KWyAg
Mzg0LjI5Mzg0NV0gIFs8ZmZmZmZmZmY4MTc0OGQzYz5dIGNhbGxfc29mdGlycSsweDFjLzB4
MzANClsgIDM4NC4yOTM4NTFdICBbPGZmZmZmZmZmODEwMGVkYjU+XSBkb19zb2Z0aXJxKzB4
ODUvMHhmMA0KWyAgMzg0LjI5Mzg1N10gIFs8ZmZmZmZmZmY4MTA2ZTI0ZT5dIGlycV9leGl0
KzB4OWUvMHhkMA0KWyAgMzg0LjI5Mzg2NF0gIFs8ZmZmZmZmZmY4MTMzOWY1Zj5dIHhlbl9l
dnRjaG5fZG9fdXBjYWxsKzB4MmYvMHg0MA0KWyAgMzg0LjI5Mzg3MF0gIFs8ZmZmZmZmZmY4
MTc0OGQ5ZT5dIHhlbl9kb19oeXBlcnZpc29yX2NhbGxiYWNrKzB4MWUvMHgzMA0KWyAgMzg0
LjI5Mzg3NV0gIDxFT0k+ICBbPGZmZmZmZmZmODEwMDEzYWE+XSA/IHhlbl9oeXBlcmNhbGxf
c2NoZWRfb3ArMHhhLzB4MjANClsgIDM4NC4yOTM4ODZdICBbPGZmZmZmZmZmODEwMDEzYWE+
XSA/IHhlbl9oeXBlcmNhbGxfc2NoZWRfb3ArMHhhLzB4MjANClsgIDM4NC4yOTM4OTNdICBb
PGZmZmZmZmZmODEwMDg2OTA+XSA/IHhlbl9zYWZlX2hhbHQrMHgxMC8weDIwDQpbICAzODQu
MjkzOTAwXSAgWzxmZmZmZmZmZjgxMDE2MGQwPl0gPyBkZWZhdWx0X2lkbGUrMHg0MC8weDkw
DQpbICAzODQuMjkzOTA1XSAgWzxmZmZmZmZmZjgxMDE2NDg2Pl0gPyBjcHVfaWRsZSsweDk2
LzB4ZjANClsgIDM4NC4yOTM5MTFdICBbPGZmZmZmZmZmODE3MjJkM2M+XSA/IHJlc3RfaW5p
dCsweGJjLzB4ZDANClsgIDM4NC4yOTM5MTZdICBbPGZmZmZmZmZmODE3MjJjODA+XSA/IGNz
dW1fcGFydGlhbF9jb3B5X2dlbmVyaWMrMHgxNzAvMHgxNzANClsgIDM4NC4yOTM5MjVdICBb
PGZmZmZmZmZmODFjZTBkZjI+XSA/IHN0YXJ0X2tlcm5lbCsweDM5MC8weDM5ZA0KWyAgMzg0
LjI5MzkzMl0gIFs8ZmZmZmZmZmY4MWNlMDg4Mj5dID8ga2VybmVsX2luaXQrMHgyMGIvMHgy
MGINClsgIDM4NC4yOTM5MzhdICBbPGZmZmZmZmZmODFjZTAzNTY+XSA/IHg4Nl82NF9zdGFy
dF9yZXNlcnZhdGlvbnMrMHgxMzEvMHgxMzYNClsgIDM4NC4yOTM5NDVdICBbPGZmZmZmZmZm
ODFjZTNkNjA+XSA/IHhlbl9zdGFydF9rZXJuZWwrMHg3MGQvMHg3MGYNClsgIDM4NC4yOTM5
NTBdIC0tLVsgZW5kIHRyYWNlIDJlMjhlZWM5M2I3YThiYTAgXS0tLQ0KWyAgMzk5LjQ2Njc3
M10gLS0tLS0tLS0tLS0tWyBjdXQgaGVyZSBdLS0tLS0tLS0tLS0tDQpbICAzOTkuNDY2Nzkx
XSBXQVJOSU5HOiBhdCBkcml2ZXJzL25ldC94ZW4tbmV0ZnJvbnQuYzo0NjUgeGVubmV0X3N0
YXJ0X3htaXQrMHg3ZmUvMHg4NjAoKQ0KWyAgMzk5LjQ2Njc5OF0gTW9kdWxlcyBsaW5rZWQg
aW46DQpbICAzOTkuNDY2ODA0XSBQaWQ6IDAsIGNvbW06IHN3YXBwZXIvMCBUYWludGVkOiBH
ICAgICAgICBXICAgIDMuNi4wcHJlLXJjMS0yMDEyMTAxMSAjMQ0KWyAgMzk5LjQ2NjgwOV0g
Q2FsbCBUcmFjZToNClsgIDM5OS40NjY4MTNdICA8SVJRPiAgWzxmZmZmZmZmZjgxMDY2NGVh
Pl0gd2Fybl9zbG93cGF0aF9jb21tb24rMHg3YS8weGIwDQpbICAzOTkuNDY2ODI0XSAgWzxm
ZmZmZmZmZjgxMDY2NTM1Pl0gd2Fybl9zbG93cGF0aF9udWxsKzB4MTUvMHgyMA0KWyAgMzk5
LjQ2NjgzMF0gIFs8ZmZmZmZmZmY4MTQ2ZDg5ZT5dIHhlbm5ldF9zdGFydF94bWl0KzB4N2Zl
LzB4ODYwDQpbICAzOTkuNDY2ODM3XSAgWzxmZmZmZmZmZjgxNjFmMzQ5Pl0gZGV2X2hhcmRf
c3RhcnRfeG1pdCsweDIwOS8weDQ2MA0KWyAgMzk5LjQ2Njg0M10gIFs8ZmZmZmZmZmY4MTYz
YjAzNj5dIHNjaF9kaXJlY3RfeG1pdCsweGY2LzB4MjkwDQpbICAzOTkuNDY2ODQ4XSAgWzxm
ZmZmZmZmZjgxNjFmNzQ2Pl0gZGV2X3F1ZXVlX3htaXQrMHgxYTYvMHg1YTANClsgIDM5OS40
NjY4NTNdICBbPGZmZmZmZmZmODE2MWY1YTA+XSA/IGRldl9oYXJkX3N0YXJ0X3htaXQrMHg0
NjAvMHg0NjANClsgIDM5OS40NjY4NTldICBbPGZmZmZmZmZmODE2MjlhNzc+XSBuZWlnaF9y
ZXNvbHZlX291dHB1dCsweDEyNy8weDI1MA0KWyAgMzk5LjQ2Njg2NV0gIFs8ZmZmZmZmZmY4
MTZiOTZhZD5dIGlwX2ZpbmlzaF9vdXRwdXQrMHgzOWQvMHg1MzANClsgIDM5OS40NjY4NzFd
ICBbPGZmZmZmZmZmODE2YjkzZGQ+XSA/IGlwX2ZpbmlzaF9vdXRwdXQrMHhjZC8weDUzMA0K
WyAgMzk5LjQ2Njg3Nl0gIFs8ZmZmZmZmZmY4MTZiOTg5OT5dIGlwX291dHB1dCsweDU5LzB4
ZTANClsgIDM5OS40NjY4ODFdICBbPGZmZmZmZmZmODE2YjgzYjg+XSBpcF9sb2NhbF9vdXQr
MHgyOC8weDkwDQpbICAzOTkuNDY2ODg2XSAgWzxmZmZmZmZmZjgxNmI4OTZmPl0gaXBfcXVl
dWVfeG1pdCsweDE3Zi8weDRhMA0KWyAgMzk5LjQ2Njg5MV0gIFs8ZmZmZmZmZmY4MTZiODdm
MD5dID8gaXBfc2VuZF91bmljYXN0X3JlcGx5KzB4MzQwLzB4MzQwDQpbICAzOTkuNDY2ODk2
XSAgWzxmZmZmZmZmZjgxMGEwYmE3Pl0gPyBnZXRuc3RpbWVvZmRheSsweDQ3LzB4ZTANClsg
IDM5OS40NjY5MDNdICBbPGZmZmZmZmZmODE2MGY0Yzk+XSA/IF9fc2tiX2Nsb25lKzB4Mjkv
MHgxMjANClsgIDM5OS40NjY5MDldICBbPGZmZmZmZmZmODE2Y2VhMjA+XSB0Y3BfdHJhbnNt
aXRfc2tiKzB4NDAwLzB4OGQwDQpbICAzOTkuNDY2OTE0XSAgWzxmZmZmZmZmZjgxNmQxMTA2
Pl0gdGNwX3JldHJhbnNtaXRfc2tiKzB4MWM2LzB4NWEwDQpbICAzOTkuNDY2OTE5XSAgWzxm
ZmZmZmZmZjgxNmQzM2IwPl0gPyB0Y3Bfd3JpdGVfdGltZXJfaGFuZGxlcisweDFhMC8weDFh
MA0KWyAgMzk5LjQ2NjkyNV0gIFs8ZmZmZmZmZmY4MTZkMmYzOD5dIHRjcF9yZXRyYW5zbWl0
X3RpbWVyKzB4MzU4LzB4NjMwDQpbICAzOTkuNDY2OTMwXSAgWzxmZmZmZmZmZjgxNmQzMzRk
Pl0gdGNwX3dyaXRlX3RpbWVyX2hhbmRsZXIrMHgxM2QvMHgxYTANClsgIDM5OS40NjY5MzVd
ICBbPGZmZmZmZmZmODE2ZDM0Mjg+XSB0Y3Bfd3JpdGVfdGltZXIrMHg3OC8weDgwDQpbICAz
OTkuNDY2OTQwXSAgWzxmZmZmZmZmZjgxMDczZjdjPl0gY2FsbF90aW1lcl9mbisweDdjLzB4
MTAwDQpbICAzOTkuNDY2OTQ1XSAgWzxmZmZmZmZmZjgxMDczZjAwPl0gPyBjYXNjYWRlKzB4
YTAvMHhhMA0KWyAgMzk5LjQ2Njk0OV0gIFs8ZmZmZmZmZmY4MTZkMzNiMD5dID8gdGNwX3dy
aXRlX3RpbWVyX2hhbmRsZXIrMHgxYTAvMHgxYTANClsgIDM5OS40NjY5NTVdICBbPGZmZmZm
ZmZmODE2ZDMzYjA+XSA/IHRjcF93cml0ZV90aW1lcl9oYW5kbGVyKzB4MWEwLzB4MWEwDQpb
ICAzOTkuNDY2OTYwXSAgWzxmZmZmZmZmZjgxMDc0MjE3Pl0gcnVuX3RpbWVyX3NvZnRpcnEr
MHgyMTcvMHgyNTANClsgIDM5OS40NjY5NjZdICBbPGZmZmZmZmZmODEwNmUzZDk+XSBfX2Rv
X3NvZnRpcnErMHhjOS8weDFhMA0KWyAgMzk5LjQ2Njk3Ml0gIFs8ZmZmZmZmZmY4MTc0OGQz
Yz5dIGNhbGxfc29mdGlycSsweDFjLzB4MzANClsgIDM5OS40NjY5NzddICBbPGZmZmZmZmZm
ODEwMGVkYjU+XSBkb19zb2Z0aXJxKzB4ODUvMHhmMA0KWyAgMzk5LjQ2Njk4Ml0gIFs8ZmZm
ZmZmZmY4MTA2ZTI0ZT5dIGlycV9leGl0KzB4OWUvMHhkMA0KWyAgMzk5LjQ2Njk4OV0gIFs8
ZmZmZmZmZmY4MTMzOWY1Zj5dIHhlbl9ldnRjaG5fZG9fdXBjYWxsKzB4MmYvMHg0MA0KWyAg
Mzk5LjQ2Njk5NF0gIFs8ZmZmZmZmZmY4MTc0OGQ5ZT5dIHhlbl9kb19oeXBlcnZpc29yX2Nh
bGxiYWNrKzB4MWUvMHgzMA0KWyAgMzk5LjQ2Njk5OF0gIDxFT0k+ICBbPGZmZmZmZmZmODEw
MDEzYWE+XSA/IHhlbl9oeXBlcmNhbGxfc2NoZWRfb3ArMHhhLzB4MjANClsgIDM5OS40Njcw
MDhdICBbPGZmZmZmZmZmODEwMDEzYWE+XSA/IHhlbl9oeXBlcmNhbGxfc2NoZWRfb3ArMHhh
LzB4MjANClsgIDM5OS40NjcwMTNdICBbPGZmZmZmZmZmODEwMDg2OTA+XSA/IHhlbl9zYWZl
X2hhbHQrMHgxMC8weDIwDQpbICAzOTkuNDY3MDE5XSAgWzxmZmZmZmZmZjgxMDE2MGQwPl0g
PyBkZWZhdWx0X2lkbGUrMHg0MC8weDkwDQpbICAzOTkuNDY3MDI0XSAgWzxmZmZmZmZmZjgx
MDE2NDg2Pl0gPyBjcHVfaWRsZSsweDk2LzB4ZjANClsgIDM5OS40NjcwMjhdICBbPGZmZmZm
ZmZmODE3MjJkM2M+XSA/IHJlc3RfaW5pdCsweGJjLzB4ZDANClsgIDM5OS40NjcwMzNdICBb
PGZmZmZmZmZmODE3MjJjODA+XSA/IGNzdW1fcGFydGlhbF9jb3B5X2dlbmVyaWMrMHgxNzAv
MHgxNzANClsgIDM5OS40NjcwNDBdICBbPGZmZmZmZmZmODFjZTBkZjI+XSA/IHN0YXJ0X2tl
cm5lbCsweDM5MC8weDM5ZA0KWyAgMzk5LjQ2NzA0NV0gIFs8ZmZmZmZmZmY4MWNlMDg4Mj5d
ID8ga2VybmVsX2luaXQrMHgyMGIvMHgyMGINClsgIDM5OS40NjcwNTBdICBbPGZmZmZmZmZm
ODFjZTAzNTY+XSA/IHg4Nl82NF9zdGFydF9yZXNlcnZhdGlvbnMrMHgxMzEvMHgxMzYNClsg
IDM5OS40NjcwNTVdICBbPGZmZmZmZmZmODFjZTNkNjA+XSA/IHhlbl9zdGFydF9rZXJuZWwr
MHg3MGQvMHg3MGYNClsgIDM5OS40NjcwNjBdIC0tLVsgZW5kIHRyYWNlIDJlMjhlZWM5M2I3
YThiYTEgXS0tLQ0KWyAgNDI5LjgxMzQ0MF0gLS0tLS0tLS0tLS0tWyBjdXQgaGVyZSBdLS0t
LS0tLS0tLS0tDQpbICA0MjkuODEzNDc3XSBXQVJOSU5HOiBhdCBkcml2ZXJzL25ldC94ZW4t
bmV0ZnJvbnQuYzo0NjUgeGVubmV0X3N0YXJ0X3htaXQrMHg3ZmUvMHg4NjAoKQ0KWyAgNDI5
LjgxMzQ4NF0gTW9kdWxlcyBsaW5rZWQgaW46DQpbICA0MjkuODEzNDkxXSBQaWQ6IDAsIGNv
bW06IHN3YXBwZXIvMCBUYWludGVkOiBHICAgICAgICBXICAgIDMuNi4wcHJlLXJjMS0yMDEy
MTAxMSAjMQ0KWyAgNDI5LjgxMzQ5N10gQ2FsbCBUcmFjZToNClsgIDQyOS44MTM1MDFdICA8
SVJRPiAgWzxmZmZmZmZmZjgxMDY2NGVhPl0gd2Fybl9zbG93cGF0aF9jb21tb24rMHg3YS8w
eGIwDQpbICA0MjkuODEzNTEzXSAgWzxmZmZmZmZmZjgxMDY2NTM1Pl0gd2Fybl9zbG93cGF0
aF9udWxsKzB4MTUvMHgyMA0KWyAgNDI5LjgxMzUxOV0gIFs8ZmZmZmZmZmY4MTQ2ZDg5ZT5d
IHhlbm5ldF9zdGFydF94bWl0KzB4N2ZlLzB4ODYwDQpbICA0MjkuODEzNTI3XSAgWzxmZmZm
ZmZmZjgxNjFmMzQ5Pl0gZGV2X2hhcmRfc3RhcnRfeG1pdCsweDIwOS8weDQ2MA0KWyAgNDI5
LjgxMzUzNF0gIFs8ZmZmZmZmZmY4MTYzYjAzNj5dIHNjaF9kaXJlY3RfeG1pdCsweGY2LzB4
MjkwDQpbICA0MjkuODEzNTM5XSAgWzxmZmZmZmZmZjgxNjFmNzQ2Pl0gZGV2X3F1ZXVlX3ht
aXQrMHgxYTYvMHg1YTANClsgIDQyOS44MTM1NDVdICBbPGZmZmZmZmZmODE2MWY1YTA+XSA/
IGRldl9oYXJkX3N0YXJ0X3htaXQrMHg0NjAvMHg0NjANClsgIDQyOS44MTM1NTJdICBbPGZm
ZmZmZmZmODEwYjE0MTc+XSA/IGxvY2tfcmVsZWFzZSsweDExNy8weDI1MA0KWyAgNDI5Ljgx
MzU1OV0gIFs8ZmZmZmZmZmY4MTZiOTUzNj5dIGlwX2ZpbmlzaF9vdXRwdXQrMHgyMjYvMHg1
MzANClsgIDQyOS44MTM1NjVdICBbPGZmZmZmZmZmODE2YjkzZGQ+XSA/IGlwX2ZpbmlzaF9v
dXRwdXQrMHhjZC8weDUzMA0KWyAgNDI5LjgxMzU3MV0gIFs8ZmZmZmZmZmY4MTZiOTg5OT5d
IGlwX291dHB1dCsweDU5LzB4ZTANClsgIDQyOS44MTM1NzZdICBbPGZmZmZmZmZmODE2Yjgz
Yjg+XSBpcF9sb2NhbF9vdXQrMHgyOC8weDkwDQpbICA0MjkuODEzNTgyXSAgWzxmZmZmZmZm
ZjgxNmI4OTZmPl0gaXBfcXVldWVfeG1pdCsweDE3Zi8weDRhMA0KWyAgNDI5LjgxMzU4OF0g
IFs8ZmZmZmZmZmY4MTZiODdmMD5dID8gaXBfc2VuZF91bmljYXN0X3JlcGx5KzB4MzQwLzB4
MzQwDQpbICA0MjkuODEzNTk0XSAgWzxmZmZmZmZmZjgxMGEwYmE3Pl0gPyBnZXRuc3RpbWVv
ZmRheSsweDQ3LzB4ZTANClsgIDQyOS44MTM2MDBdICBbPGZmZmZmZmZmODE2MGY0Yzk+XSA/
IF9fc2tiX2Nsb25lKzB4MjkvMHgxMjANClsgIDQyOS44MTM2MDZdICBbPGZmZmZmZmZmODE2
Y2VhMjA+XSB0Y3BfdHJhbnNtaXRfc2tiKzB4NDAwLzB4OGQwDQpbICA0MjkuODEzNjE0XSAg
WzxmZmZmZmZmZjgxNmQxMTA2Pl0gdGNwX3JldHJhbnNtaXRfc2tiKzB4MWM2LzB4NWEwDQpb
ICA0MjkuODEzNjIzXSAgWzxmZmZmZmZmZjgxNmQzM2IwPl0gPyB0Y3Bfd3JpdGVfdGltZXJf
aGFuZGxlcisweDFhMC8weDFhMA0KWyAgNDI5LjgxMzYzMV0gIFs8ZmZmZmZmZmY4MTZkMmYz
OD5dIHRjcF9yZXRyYW5zbWl0X3RpbWVyKzB4MzU4LzB4NjMwDQpbICA0MjkuODEzNjM3XSAg
WzxmZmZmZmZmZjgxNmQzMzRkPl0gdGNwX3dyaXRlX3RpbWVyX2hhbmRsZXIrMHgxM2QvMHgx
YTANClsgIDQyOS44MTM2NDNdICBbPGZmZmZmZmZmODE2ZDM0Mjg+XSB0Y3Bfd3JpdGVfdGlt
ZXIrMHg3OC8weDgwDQpbICA0MjkuODEzNjQ5XSAgWzxmZmZmZmZmZjgxMDczZjdjPl0gY2Fs
bF90aW1lcl9mbisweDdjLzB4MTAwDQpbICA0MjkuODEzNjU0XSAgWzxmZmZmZmZmZjgxMDcz
ZjAwPl0gPyBjYXNjYWRlKzB4YTAvMHhhMA0KWyAgNDI5LjgxMzY1OV0gIFs8ZmZmZmZmZmY4
MTZkMzNiMD5dID8gdGNwX3dyaXRlX3RpbWVyX2hhbmRsZXIrMHgxYTAvMHgxYTANClsgIDQy
OS44MTM2NjVdICBbPGZmZmZmZmZmODE2ZDMzYjA+XSA/IHRjcF93cml0ZV90aW1lcl9oYW5k
bGVyKzB4MWEwLzB4MWEwDQpbICA0MjkuODEzNzI4XSAgWzxmZmZmZmZmZjgxMDc0MjE3Pl0g
cnVuX3RpbWVyX3NvZnRpcnErMHgyMTcvMHgyNTANClsgIDQyOS44MTM3MzVdICBbPGZmZmZm
ZmZmODEwNmUzZDk+XSBfX2RvX3NvZnRpcnErMHhjOS8weDFhMA0KWyAgNDI5LjgxMzc0Ml0g
IFs8ZmZmZmZmZmY4MTc0OGQzYz5dIGNhbGxfc29mdGlycSsweDFjLzB4MzANClsgIDQyOS44
MTM3NDldICBbPGZmZmZmZmZmODEwMGVkYjU+XSBkb19zb2Z0aXJxKzB4ODUvMHhmMA0KWyAg
NDI5LjgxMzc1NF0gIFs8ZmZmZmZmZmY4MTA2ZTI0ZT5dIGlycV9leGl0KzB4OWUvMHhkMA0K
WyAgNDI5LjgxMzc2Ml0gIFs8ZmZmZmZmZmY4MTMzOWY1Zj5dIHhlbl9ldnRjaG5fZG9fdXBj
YWxsKzB4MmYvMHg0MA0KWyAgNDI5LjgxMzc2N10gIFs8ZmZmZmZmZmY4MTc0OGQ5ZT5dIHhl
bl9kb19oeXBlcnZpc29yX2NhbGxiYWNrKzB4MWUvMHgzMA0KWyAgNDI5LjgxMzc3Ml0gIDxF
T0k+ICBbPGZmZmZmZmZmODEwMDEzYWE+XSA/IHhlbl9oeXBlcmNhbGxfc2NoZWRfb3ArMHhh
LzB4MjANClsgIDQyOS44MTM3ODNdICBbPGZmZmZmZmZmODEwMDEzYWE+XSA/IHhlbl9oeXBl
cmNhbGxfc2NoZWRfb3ArMHhhLzB4MjANClsgIDQyOS44MTM3ODldICBbPGZmZmZmZmZmODEw
MDg2OTA+XSA/IHhlbl9zYWZlX2hhbHQrMHgxMC8weDIwDQpbICA0MjkuODEzNzk1XSAgWzxm
ZmZmZmZmZjgxMDE2MGQwPl0gPyBkZWZhdWx0X2lkbGUrMHg0MC8weDkwDQpbICA0MjkuODEz
ODAxXSAgWzxmZmZmZmZmZjgxMDE2NDg2Pl0gPyBjcHVfaWRsZSsweDk2LzB4ZjANClsgIDQy
OS44MTM4MDddICBbPGZmZmZmZmZmODE3MjJkM2M+XSA/IHJlc3RfaW5pdCsweGJjLzB4ZDAN
ClsgIDQyOS44MTM4MTNdICBbPGZmZmZmZmZmODE3MjJjODA+XSA/IGNzdW1fcGFydGlhbF9j
b3B5X2dlbmVyaWMrMHgxNzAvMHgxNzANClsgIDQyOS44MTM4MjFdICBbPGZmZmZmZmZmODFj
ZTBkZjI+XSA/IHN0YXJ0X2tlcm5lbCsweDM5MC8weDM5ZA0KWyAgNDI5LjgxMzgyN10gIFs8
ZmZmZmZmZmY4MWNlMDg4Mj5dID8ga2VybmVsX2luaXQrMHgyMGIvMHgyMGINClsgIDQyOS44
MTM4MzNdICBbPGZmZmZmZmZmODFjZTAzNTY+XSA/IHg4Nl82NF9zdGFydF9yZXNlcnZhdGlv
bnMrMHgxMzEvMHgxMzYNClsgIDQyOS44MTM4MzldICBbPGZmZmZmZmZmODFjZTNkNjA+XSA/
IHhlbl9zdGFydF9rZXJuZWwrMHg3MGQvMHg3MGYNClsgIDQyOS44MTM4NDVdIC0tLVsgZW5k
IHRyYWNlIDJlMjhlZWM5M2I3YThiYTIgXS0tLQ0K
------------002085244038F36F8
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

------------002085244038F36F8--



From xen-devel-bounces@lists.xen.org Thu Oct 11 10:00:49 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 10:00:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMFZ1-0006XW-FI; Thu, 11 Oct 2012 10:00:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMFYy-0006XR-P8
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 10:00:21 +0000
Received: from [85.158.138.51:11654] by server-9.bemta-3.messagelabs.com id
	3E/98-16841-3B896705; Thu, 11 Oct 2012 10:00:19 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-6.tower-174.messagelabs.com!1349949613!25924142!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18923 invoked from network); 11 Oct 2012 10:00:13 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-6.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	11 Oct 2012 10:00:13 -0000
Received: from 50-66-ftth.onsneteindhoven.nl ([88.159.66.50]:52015
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TMFaC-00013r-7T; Thu, 11 Oct 2012 12:01:36 +0200
Date: Thu, 11 Oct 2012 12:00:04 +0200
From: Sander Eikelenboom 
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <151954917.20121011120004@eikelenboom.it>
To: Ian Campbell 
In-Reply-To: <1349942546.14806.7.camel@zakaz.uk.xensource.com>
References: <1349790467.21847.185.camel@zakaz.uk.xensource.com>
	<1349790863.21172.4406.camel@edumazet-glaptop>
	<1349792241.21847.199.camel@zakaz.uk.xensource.com>
	<1349792847.21172.4479.camel@edumazet-glaptop>
	<1349793630.21847.208.camel@zakaz.uk.xensource.com>
	<1349863984.10070.26.camel@zakaz.uk.xensource.com>
	<1349874598.10070.39.camel@zakaz.uk.xensource.com>
	<748966751.20121010164949@eikelenboom.it>
	<1349942546.14806.7.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------002085244038F36F8"
Cc: Konrad Rzeszutek Wilk ,
	Eric Dumazet ,
	"netdev@vger.kernel.org" ,
	Eric Dumazet , xen-devel 
Subject: Re: [Xen-devel] compound skb frag pages appearing in start_xmit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

------------002085244038F36F8
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Thursday, October 11, 2012, 10:02:26 AM, you wrote:

> On Wed, 2012-10-10 at 15:49 +0100, Sander Eikelenboom wrote:
>> Wednesday, October 10, 2012, 3:09:58 PM, you wrote:
>> 
>> > On Wed, 2012-10-10 at 11:13 +0100, Ian Campbell wrote:
>> >> I haven't tackled netfront yet. 
>> 
>> > I seem to be totally unable to reproduce the equivalent issue on the
>> > netfront xmit side, even though it seems like the loop in
>> > xennet_make_frags ought to be obviously susceptible to it.
>> 
>> > Konrad, Sander, are either of you able to repro, e.g. with:
>> 
>> 
>> Hmrrrmm i don't see any traces, only strange behaviour ..
>> 
>> - i can connect to guests by ssh, but it's sluggish, and sometimes stops working

> I saw something like this (ssh sluggish) even with dom0 itself. I'm
> trying to see if I can characterise it enough to reliably bisect it.

> I already switched out xen-unstable for 4.2-testing but that didn't make
> any difference.



>> - The guest seem to keep trying to connect to netback:
>> 
>> [  658.276719] xen_bridge: port 2(vif40.0) entered forwarding state
>> [  658.282258] xen_bridge: port 2(vif40.0) entered forwarding state
>> [  663.945964] xen_bridge: port 7(vif39.0) entered forwarding state
>> [  669.674277] xen_bridge: port 2(vif40.0) entered disabled state
>> [  669.680290] device vif40.0 left promiscuous mode
>> [  669.685464] xen_bridge: port 2(vif40.0) entered disabled state
>> [  672.857222] device vif41.0 entered promiscuous mode
>> [  673.166254] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
>> [  673.176368] xen_bridge: port 2(vif41.0) entered forwarding state
>> [  673.182042] xen_bridge: port 2(vif41.0) entered forwarding state
>> [  674.439725] xen_bridge: port 7(vif39.0) entered disabled state
>> [  674.445708] device vif39.0 left promiscuous mode
>> [  674.450955] xen_bridge: port 7(vif39.0) entered disabled state
>> [  677.726040] device vif42.0 entered promiscuous mode
>> [  678.053381] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
>> [  678.062804] xen_bridge: port 7(vif42.0) entered forwarding state
>> [  678.068433] xen_bridge: port 7(vif42.0) entered forwarding state
>> [  688.224736] xen_bridge: port 2(vif41.0) entered forwarding state
>> [  693.080557] xen_bridge: port 7(vif42.0) entered forwarding state
>> [  700.786276] xen_bridge: port 7(vif42.0) entered disabled state
>> [  700.792484] device vif42.0 left promiscuous mode
>> [  700.802409] xen_bridge: port 7(vif42.0) entered disabled state
>> [  704.133606] device vif43.0 entered promiscuous mode
>> [  704.460160] xen-blkback:ring-ref 8, event-channel 9, protocol 1 (x86_64-abi)
>> [  704.469800] xen_bridge: port 7(vif43.0) entered forwarding state
>> [  704.475303] xen_bridge: port 7(vif43.0) entered forwarding state
>> [  719.493788] xen_bridge: port 7(vif43.0) entered forwarding state
>> [  726.302456] xen_bridge: port 7(vif43.0) entered disabled state
>> [  726.308898] device vif43.0 left promiscuous mode
>> [  726.314029] xen_bridge: port 7(vif43.0) entered disabled state
>> 
>> All the guests are already up, but this keeps on going and going and going ....

> The domain number seems to be climbing, are you sure something isn't
> (crashing and) restarting?

Probably due to the BUG_ON from the patch below, i changed it into a WARN_ON.
And i seem to hit it, but only in one of the guests at the moment and it triggers quite irregularly.

[   34.298549] ------------[ cut here ]------------
[   34.298567] WARNING: at drivers/net/xen-netfront.c:465 xennet_start_xmit+0x7fe/0x860()
[   34.298574] Modules linked in:
[   34.298597] Pid: 1580, comm: sshd Not tainted 3.6.0pre-rc1-20121011 #1
[   34.298603] Call Trace:
[   34.298611]  [] warn_slowpath_common+0x7a/0xb0
[   34.298617]  [] warn_slowpath_null+0x15/0x20
[   34.298623]  [] xennet_start_xmit+0x7fe/0x860
[   34.298631]  [] dev_hard_start_xmit+0x209/0x460
[   34.298637]  [] sch_direct_xmit+0xf6/0x290
[   34.298643]  [] dev_queue_xmit+0x1a6/0x5a0
[   34.298649]  [] ? dev_hard_start_xmit+0x460/0x460
[   34.298656]  [] ? trace_softirqs_off+0x85/0x1b0
[   34.298663]  [] ip_finish_output+0x226/0x530
[   34.298668]  [] ? ip_finish_output+0xcd/0x530
[   34.298674]  [] ip_output+0x59/0xe0
[   34.298680]  [] ip_local_out+0x28/0x90
[   34.298687]  [] ip_queue_xmit+0x17f/0x4a0
[   34.298692]  [] ? ip_send_unicast_reply+0x340/0x340
[   34.298699]  [] ? getnstimeofday+0x47/0xe0
[   34.298705]  [] ? __skb_clone+0x29/0x120
[   34.298711]  [] tcp_transmit_skb+0x400/0x8d0
[   34.298717]  [] tcp_write_xmit+0x21a/0xa50
[   34.298723]  [] tcp_push_one+0x2b/0x40
[   34.298728]  [] tcp_sendmsg+0x8dc/0xe20
[   34.298735]  [] inet_sendmsg+0xa9/0x100
[   34.298740]  [] ? inet_autobind+0x70/0x70
[   34.298746]  [] ? lock_acquire+0xd8/0x100
[   34.298753]  [] sock_aio_write+0x12d/0x140
[   34.298762]  [] do_sync_write+0xa2/0xe0
[   34.298768]  [] ? trace_hardirqs_on+0xd/0x10
[   34.298774]  [] vfs_write+0x174/0x190
[   34.298779]  [] sys_write+0x5a/0xa0
[   34.298786]  [] ? trace_hardirqs_on_thunk+0x3a/0x3f
[   34.298792]  [] cstar_dispatch+0x7/0x26
[   34.298797] ---[ end trace 2e28eec93b7a8b74 ]---


Complete dmesg from guest attached.



>> > diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
>> > index b06ef81..8a3f770 100644
>> > --- a/drivers/net/xen-netfront.c
>> > +++ b/drivers/net/xen-netfront.c
>> > @@ -462,6 +462,8 @@ static void xennet_make_frags(struct sk_buff *skb, struct net_device *dev,
>> >                 ref = gnttab_claim_grant_reference(&np->gref_tx_head);
>> >                 BUG_ON((signed short)ref < 0);
>> >  
>> > +               BUG_ON(PageCompound(skb_frag_page(frag)));
>> > +
>> >                 mfn = pfn_to_mfn(page_to_pfn(skb_frag_page(frag)));
>> >                 gnttab_grant_foreign_access_ref(ref, np->xbdev->otherend_id,
>> >                                                 mfn, GNTMAP_readonly);
>> 
>> > My repro for netback was just to netcat a wodge of data from dom0->domU
>> > but going the other way doesn't seem to trigger.
>> 
>> 
>> 



------------002085244038F36F8
Content-Type: text/plain;
 name="dmesg-netfront.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="dmesg-netfront.txt"

WyAgICAwLjAwMDAwMF0gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgY3B1c2V0DQpbICAg
IDAuMDAwMDAwXSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBjcHUNClsgICAgMC4wMDAw
MDBdIExpbnV4IHZlcnNpb24gMy42LjBwcmUtcmMxLTIwMTIxMDExIChyb290QHNlcnZlZXJz
dGVydGplKSAoZ2NjIHZlcnNpb24gNC40LjUgKERlYmlhbiA0LjQuNS04KSApICMxIFNNUCBQ
UkVFTVBUIFRodSBPY3QgMTEgMTE6MDQ6MzggQ0VTVCAyMDEyDQpbICAgIDAuMDAwMDAwXSBD
b21tYW5kIGxpbmU6IHJvb3Q9L2Rldi94dmRhMSBybyANClsgICAgMC4wMDAwMDBdIEFDUEkg
aW4gdW5wcml2aWxlZ2VkIGRvbWFpbiBkaXNhYmxlZA0KWyAgICAwLjAwMDAwMF0gZTgyMDog
QklPUy1wcm92aWRlZCBwaHlzaWNhbCBSQU0gbWFwOg0KWyAgICAwLjAwMDAwMF0gWGVuOiBb
bWVtIDB4MDAwMDAwMDAwMDAwMDAwMC0weDAwMDAwMDAwMDAwOWZmZmZdIHVzYWJsZQ0KWyAg
ICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDAwMDBhMDAwMC0weDAwMDAwMDAwMDAw
ZmZmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMDAw
MTAwMDAwLTB4MDAwMDAwMDAxZmZmZmZmZl0gdXNhYmxlDQpbICAgIDAuMDAwMDAwXSBOWCAo
RXhlY3V0ZSBEaXNhYmxlKSBwcm90ZWN0aW9uOiBhY3RpdmUNClsgICAgMC4wMDAwMDBdIERN
SSBub3QgcHJlc2VudCBvciBpbnZhbGlkLg0KWyAgICAwLjAwMDAwMF0gZTgyMDogdXBkYXRl
IFttZW0gMHgwMDAwMDAwMC0weDAwMDBmZmZmXSB1c2FibGUgPT0+IHJlc2VydmVkDQpbICAg
IDAuMDAwMDAwXSBlODIwOiByZW1vdmUgW21lbSAweDAwMGEwMDAwLTB4MDAwZmZmZmZdIHVz
YWJsZQ0KWyAgICAwLjAwMDAwMF0gTm8gQUdQIGJyaWRnZSBmb3VuZA0KWyAgICAwLjAwMDAw
MF0gZTgyMDogbGFzdF9wZm4gPSAweDIwMDAwIG1heF9hcmNoX3BmbiA9IDB4NDAwMDAwMDAw
DQpbICAgIDAuMDAwMDAwXSBpbml0aWFsIG1lbW9yeSBtYXBwZWQ6IFttZW0gMHgwMDAwMDAw
MC0weDAzN2M5ZmZmXQ0KWyAgICAwLjAwMDAwMF0gQmFzZSBtZW1vcnkgdHJhbXBvbGluZSBh
dCBbZmZmZjg4MDAwMDA5YTAwMF0gOWEwMDAgc2l6ZSAyNDU3Ng0KWyAgICAwLjAwMDAwMF0g
aW5pdF9tZW1vcnlfbWFwcGluZzogW21lbSAweDAwMDAwMDAwLTB4MWZmZmZmZmZdDQpbICAg
IDAuMDAwMDAwXSAgW21lbSAweDAwMDAwMDAwLTB4MWZmZmZmZmZdIHBhZ2UgNGsNClsgICAg
MC4wMDAwMDBdIGtlcm5lbCBkaXJlY3QgbWFwcGluZyB0YWJsZXMgdXAgdG8gMHgxZmZmZmZm
ZiBAIFttZW0gMHgwMjljNDAwMC0weDAyYWM1ZmZmXQ0KWyAgICAwLjAwMDAwMF0geGVuOiBz
ZXR0aW5nIFJXIHRoZSByYW5nZSAyYWE2MDAwIC0gMmFjNjAwMA0KWyAgICAwLjAwMDAwMF0g
UkFNRElTSzogW21lbSAweDAyYWM2MDAwLTB4MDM3YzlmZmZdDQpbICAgIDAuMDAwMDAwXSBO
VU1BIHR1cm5lZCBvZmYNClsgICAgMC4wMDAwMDBdIEZha2luZyBhIG5vZGUgYXQgW21lbSAw
eDAwMDAwMDAwMDAwMDAwMDAtMHgwMDAwMDAwMDFmZmZmZmZmXQ0KWyAgICAwLjAwMDAwMF0g
SW5pdG1lbSBzZXR1cCBub2RlIDAgW21lbSAweDAwMDAwMDAwLTB4MWZmZmZmZmZdDQpbICAg
IDAuMDAwMDAwXSAgIE5PREVfREFUQSBbbWVtIDB4MWZmZjUwMDAtMHgxZmZmZmZmZl0NClsg
ICAgMC4wMDAwMDBdIFpvbmUgcmFuZ2VzOg0KWyAgICAwLjAwMDAwMF0gICBETUEgICAgICBb
bWVtIDB4MDAwMTAwMDAtMHgwMGZmZmZmZl0NClsgICAgMC4wMDAwMDBdICAgRE1BMzIgICAg
W21lbSAweDAxMDAwMDAwLTB4ZmZmZmZmZmZdDQpbICAgIDAuMDAwMDAwXSAgIE5vcm1hbCAg
IGVtcHR5DQpbICAgIDAuMDAwMDAwXSBNb3ZhYmxlIHpvbmUgc3RhcnQgZm9yIGVhY2ggbm9k
ZQ0KWyAgICAwLjAwMDAwMF0gRWFybHkgbWVtb3J5IG5vZGUgcmFuZ2VzDQpbICAgIDAuMDAw
MDAwXSAgIG5vZGUgICAwOiBbbWVtIDB4MDAwMTAwMDAtMHgwMDA5ZmZmZl0NClsgICAgMC4w
MDAwMDBdICAgbm9kZSAgIDA6IFttZW0gMHgwMDEwMDAwMC0weDFmZmZmZmZmXQ0KWyAgICAw
LjAwMDAwMF0gT24gbm9kZSAwIHRvdGFscGFnZXM6IDEzMDk2MA0KWyAgICAwLjAwMDAwMF0g
ICBETUEgem9uZTogNjQgcGFnZXMgdXNlZCBmb3IgbWVtbWFwDQpbICAgIDAuMDAwMDAwXSAg
IERNQSB6b25lOiA2IHBhZ2VzIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSAgIERNQSB6b25l
OiAzOTE0IHBhZ2VzLCBMSUZPIGJhdGNoOjANClsgICAgMC4wMDAwMDBdICAgRE1BMzIgem9u
ZTogMTk4NCBwYWdlcyB1c2VkIGZvciBtZW1tYXANClsgICAgMC4wMDAwMDBdICAgRE1BMzIg
em9uZTogMTI0OTkyIHBhZ2VzLCBMSUZPIGJhdGNoOjMxDQpbICAgIDAuMDAwMDAwXSBzbXBi
b290OiBBbGxvd2luZyAxIENQVXMsIDAgaG90cGx1ZyBDUFVzDQpbICAgIDAuMDAwMDAwXSBO
byBsb2NhbCBBUElDIHByZXNlbnQNClsgICAgMC4wMDAwMDBdIEFQSUM6IGRpc2FibGUgYXBp
YyBmYWNpbGl0eQ0KWyAgICAwLjAwMDAwMF0gQVBJQzogc3dpdGNoZWQgdG8gYXBpYyBOT09Q
DQpbICAgIDAuMDAwMDAwXSBucl9pcnFzX2dzaTogMTYNClsgICAgMC4wMDAwMDBdIGU4MjA6
IFttZW0gMHgyMDAwMDAwMC0weGZmZmZmZmZmXSBhdmFpbGFibGUgZm9yIFBDSSBkZXZpY2Vz
DQpbICAgIDAuMDAwMDAwXSBCb290aW5nIHBhcmF2aXJ0dWFsaXplZCBrZXJuZWwgb24gWGVu
DQpbICAgIDAuMDAwMDAwXSBYZW4gdmVyc2lvbjogNC4zLXVuc3RhYmxlIChwcmVzZXJ2ZS1B
RCkNClsgICAgMC4wMDAwMDBdIHNldHVwX3BlcmNwdTogTlJfQ1BVUzo4IG5yX2NwdW1hc2tf
Yml0czo4IG5yX2NwdV9pZHM6MSBucl9ub2RlX2lkczoxDQpbICAgIDAuMDAwMDAwXSBQRVJD
UFU6IEVtYmVkZGVkIDI3IHBhZ2VzL2NwdSBAZmZmZjg4MDAxZmMwMDAwMCBzODEwODggcjgx
OTIgZDIxMzEyIHUyMDk3MTUyDQpbICAgIDAuMDAwMDAwXSBwY3B1LWFsbG9jOiBzODEwODgg
cjgxOTIgZDIxMzEyIHUyMDk3MTUyIGFsbG9jPTEqMjA5NzE1Mg0KWyAgICAwLjAwMDAwMF0g
cGNwdS1hbGxvYzogWzBdIDAgDQpbICAgIDAuMDAwMDAwXSBCdWlsdCAxIHpvbmVsaXN0cyBp
biBOb2RlIG9yZGVyLCBtb2JpbGl0eSBncm91cGluZyBvbi4gIFRvdGFsIHBhZ2VzOiAxMjg5
MDYNClsgICAgMC4wMDAwMDBdIFBvbGljeSB6b25lOiBETUEzMg0KWyAgICAwLjAwMDAwMF0g
S2VybmVsIGNvbW1hbmQgbGluZTogcm9vdD0vZGV2L3h2ZGExIHJvIA0KWyAgICAwLjAwMDAw
MF0gUElEIGhhc2ggdGFibGUgZW50cmllczogMjA0OCAob3JkZXI6IDIsIDE2Mzg0IGJ5dGVz
KQ0KWyAgICAwLjAwMDAwMF0gX19leF90YWJsZSBhbHJlYWR5IHNvcnRlZCwgc2tpcHBpbmcg
c29ydA0KWyAgICAwLjAwMDAwMF0gQ2hlY2tpbmcgYXBlcnR1cmUuLi4NClsgICAgMC4wMDAw
MDBdIE5vIEFHUCBicmlkZ2UgZm91bmQNClsgICAgMC4wMDAwMDBdIE1lbW9yeTogNDc2NzI0
ay81MjQyODhrIGF2YWlsYWJsZSAoNzQ3Mmsga2VybmVsIGNvZGUsIDQ0OGsgYWJzZW50LCA0
NzExNmsgcmVzZXJ2ZWQsIDU2MjZrIGRhdGEsIDY5NmsgaW5pdCkNClsgICAgMC4wMDAwMDBd
IFNMVUI6IEdlbnNsYWJzPTE1LCBIV2FsaWduPTY0LCBPcmRlcj0wLTMsIE1pbk9iamVjdHM9
MCwgQ1BVcz0xLCBOb2Rlcz0xDQpbICAgIDAuMDAwMDAwXSBQcmVlbXB0aWJsZSBoaWVyYXJj
aGljYWwgUkNVIGltcGxlbWVudGF0aW9uLg0KWyAgICAwLjAwMDAwMF0gCVJDVSBkeW50aWNr
LWlkbGUgZ3JhY2UtcGVyaW9kIGFjY2VsZXJhdGlvbiBpcyBlbmFibGVkLg0KWyAgICAwLjAw
MDAwMF0gCUFkZGl0aW9uYWwgcGVyLUNQVSBpbmZvIHByaW50ZWQgd2l0aCBzdGFsbHMuDQpb
ICAgIDAuMDAwMDAwXSAJUkNVIHJlc3RyaWN0aW5nIENQVXMgZnJvbSBOUl9DUFVTPTggdG8g
bnJfY3B1X2lkcz0xLg0KWyAgICAwLjAwMDAwMF0gTlJfSVJRUzo0MzUyIG5yX2lycXM6MjU2
IDE2DQpbICAgIDAuMDAwMDAwXSBDb25zb2xlOiBjb2xvdXIgZHVtbXkgZGV2aWNlIDgweDI1
DQpbICAgIDAuMDAwMDAwXSBjb25zb2xlIFt0dHkwXSBlbmFibGVkDQpbICAgIDAuMDAwMDAw
XSBjb25zb2xlIFtodmMwXSBlbmFibGVkDQpbICAgIDAuMDAwMDAwXSBMb2NrIGRlcGVuZGVu
Y3kgdmFsaWRhdG9yOiBDb3B5cmlnaHQgKGMpIDIwMDYgUmVkIEhhdCwgSW5jLiwgSW5nbyBN
b2xuYXINClsgICAgMC4wMDAwMDBdIC4uLiBNQVhfTE9DS0RFUF9TVUJDTEFTU0VTOiAgOA0K
WyAgICAwLjAwMDAwMF0gLi4uIE1BWF9MT0NLX0RFUFRIOiAgICAgICAgICA0OA0KWyAgICAw
LjAwMDAwMF0gLi4uIE1BWF9MT0NLREVQX0tFWVM6ICAgICAgICA4MTkxDQpbICAgIDAuMDAw
MDAwXSAuLi4gQ0xBU1NIQVNIX1NJWkU6ICAgICAgICAgIDQwOTYNClsgICAgMC4wMDAwMDBd
IC4uLiBNQVhfTE9DS0RFUF9FTlRSSUVTOiAgICAgMTYzODQNClsgICAgMC4wMDAwMDBdIC4u
LiBNQVhfTE9DS0RFUF9DSEFJTlM6ICAgICAgMzI3NjgNClsgICAgMC4wMDAwMDBdIC4uLiBD
SEFJTkhBU0hfU0laRTogICAgICAgICAgMTYzODQNClsgICAgMC4wMDAwMDBdICBtZW1vcnkg
dXNlZCBieSBsb2NrIGRlcGVuZGVuY3kgaW5mbzogNTg1NSBrQg0KWyAgICAwLjAwMDAwMF0g
IHBlciB0YXNrLXN0cnVjdCBtZW1vcnkgZm9vdHByaW50OiAxOTIwIGJ5dGVzDQpbICAgIDAu
MDAwMDAwXSBYZW46IHVzaW5nIHZjcHVvcCB0aW1lciBpbnRlcmZhY2UNClsgICAgMC4wMDAw
MDBdIGluc3RhbGxpbmcgWGVuIHRpbWVyIGZvciBDUFUgMA0KWyAgICAwLjAwMDAwMF0gdHNj
OiBEZXRlY3RlZCAzMjAwLjE0NCBNSHogcHJvY2Vzc29yDQpbICAgIDAuMDAzMzMzXSBDYWxp
YnJhdGluZyBkZWxheSBsb29wIChza2lwcGVkKSwgdmFsdWUgY2FsY3VsYXRlZCB1c2luZyB0
aW1lciBmcmVxdWVuY3kuLiA2NDAyLjk2IEJvZ29NSVBTIChscGo9MTA2NjcxNDYpDQpbICAg
IDAuMDAzMzMzXSBwaWRfbWF4OiBkZWZhdWx0OiAzMjc2OCBtaW5pbXVtOiAzMDENClsgICAg
MC4wMDMzMzNdIERlbnRyeSBjYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDY1NTM2IChvcmRl
cjogNywgNTI0Mjg4IGJ5dGVzKQ0KWyAgICAwLjAwMzMzM10gSW5vZGUtY2FjaGUgaGFzaCB0
YWJsZSBlbnRyaWVzOiAzMjc2OCAob3JkZXI6IDYsIDI2MjE0NCBieXRlcykNClsgICAgMC4w
MDMzMzNdIE1vdW50LWNhY2hlIGhhc2ggdGFibGUgZW50cmllczogMjU2DQpbICAgIDAuMDAz
MzMzXSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBjcHVhY2N0DQpbICAgIDAuMDAzMzMz
XSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBmcmVlemVyDQpbICAgIDAuMDAzMzMzXSBJ
bml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBibGtpbw0KWyAgICAwLjAwMzMzM10gdHNlZzog
MDAwMDAwMDAwMA0KWyAgICAwLjAwMzMzM10gQ1BVOiBQaHlzaWNhbCBQcm9jZXNzb3IgSUQ6
IDANClsgICAgMC4wMDMzMzNdIENQVTogUHJvY2Vzc29yIENvcmUgSUQ6IDENClsgICAgMC4w
MDMzMzNdIExhc3QgbGV2ZWwgaVRMQiBlbnRyaWVzOiA0S0IgNTEyLCAyTUIgMTYsIDRNQiA4
DQpbICAgIDAuMDAzMzMzXSBMYXN0IGxldmVsIGRUTEIgZW50cmllczogNEtCIDUxMiwgMk1C
IDEyOCwgNE1CIDY0DQpbICAgIDAuMDAzMzMzXSB0bGJfZmx1c2hhbGxfc2hpZnQ6IDQNClsg
ICAgMC4wMjUzNjNdIEZyZWVpbmcgU01QIGFsdGVybmF0aXZlczogMjRrIGZyZWVkDQpbICAg
IDAuMDI2MTc0XSBQZXJmb3JtYW5jZSBFdmVudHM6IA0KWyAgICAwLjAyNjE4N10gbm8gQVBJ
QywgYm9vdCB3aXRoIHRoZSAibGFwaWMiIGJvb3QgcGFyYW1ldGVyIHRvIGZvcmNlLWVuYWJs
ZSBpdC4NClsgICAgMC4wMjYxOTNdIG5vIGhhcmR3YXJlIHNhbXBsaW5nIGludGVycnVwdCBh
dmFpbGFibGUuDQpbICAgIDAuMDI2MjE1XSBCcm9rZW4gUE1VIGhhcmR3YXJlIGRldGVjdGVk
LCB1c2luZyBzb2Z0d2FyZSBldmVudHMgb25seS4NClsgICAgMC4wMjYyMjBdIEZhaWxlZCB0
byBhY2Nlc3MgcGVyZmN0ciBtc3IgKE1TUiBjMDAxMDAwNCBpcyAyMTg1YzUyYjYzOGYpDQpb
ICAgIDAuMDQzNTQ5XSBCcm91Z2h0IHVwIDEgQ1BVcw0KWyAgICAwLjA0MzYzNF0gTk1JIHdh
dGNoZG9nOiBkaXNhYmxlZCAoY3B1MCk6IGhhcmR3YXJlIGV2ZW50cyBub3QgZW5hYmxlZA0K
WyAgICAwLjA0NDA3OV0gR3JhbnQgdGFibGVzIHVzaW5nIHZlcnNpb24gMiBsYXlvdXQuDQpb
ICAgIDAuMDQ0MTAzXSBHcmFudCB0YWJsZSBpbml0aWFsaXplZA0KWyAgICAwLjA0NDIyNV0g
TkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAxNg0KWyAgICAwLjA0NTQ5OV0gUENJ
OiBzZXR0aW5nIHVwIFhlbiBQQ0kgZnJvbnRlbmQgc3R1Yg0KWyAgICAwLjA0NTQ5OV0gUENJ
OiBwY2lfY2FjaGVfbGluZV9zaXplIHNldCB0byA2NCBieXRlcw0KWyAgICAwLjA2MzA5NF0g
YmlvOiBjcmVhdGUgc2xhYiA8YmlvLTA+IGF0IDANClsgICAgMC4wNjMzMjNdIEFDUEk6IElu
dGVycHJldGVyIGRpc2FibGVkLg0KWyAgICAwLjA2MzUxN10geGVuL2JhbGxvb246IEluaXRp
YWxpc2luZyBiYWxsb29uIGRyaXZlci4NClsgICAgMC4wNjM1OTRdIHhlbi1iYWxsb29uOiBJ
bml0aWFsaXNpbmcgYmFsbG9vbiBkcml2ZXIuDQpbICAgIDAuMDYzNTk0XSB2Z2FhcmI6IGxv
YWRlZA0KWyAgICAwLjA2Mzc5NV0gU0NTSSBzdWJzeXN0ZW0gaW5pdGlhbGl6ZWQNClsgICAg
MC4wNjM5MzFdIGxpYmF0YSB2ZXJzaW9uIDMuMDAgbG9hZGVkLg0KWyAgICAwLjA2NDIxMF0g
dXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciB1c2Jmcw0KWyAgICAw
LjA2NDI3MF0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBodWIN
ClsgICAgMC4wNjQzNDZdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGRldmljZSBkcml2ZXIg
dXNiDQpbICAgIDAuMDY0NDgyXSBMaW51eCB2aWRlbyBjYXB0dXJlIGludGVyZmFjZTogdjIu
MDANClsgICAgMC4wNjQ4MDldIEFkdmFuY2VkIExpbnV4IFNvdW5kIEFyY2hpdGVjdHVyZSBE
cml2ZXIgSW5pdGlhbGl6ZWQuDQpbICAgIDAuMDY0ODE1XSBQQ0k6IFN5c3RlbSBkb2VzIG5v
dCBzdXBwb3J0IFBDSQ0KWyAgICAwLjA2NDgxOV0gUENJOiBTeXN0ZW0gZG9lcyBub3Qgc3Vw
cG9ydCBQQ0kNClsgICAgMC4wNjcxMzddIFN3aXRjaGluZyB0byBjbG9ja3NvdXJjZSB4ZW4N
ClsgICAgMC4wNjczODhdIHBucDogUG5QIEFDUEk6IGRpc2FibGVkDQpbICAgIDAuMDcxMjQ3
XSBORVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDINClsgICAgMC4wNzE0NzldIFRD
UCBlc3RhYmxpc2hlZCBoYXNoIHRhYmxlIGVudHJpZXM6IDE2Mzg0IChvcmRlcjogNiwgMjYy
MTQ0IGJ5dGVzKQ0KWyAgICAwLjA3MTY4MF0gVENQIGJpbmQgaGFzaCB0YWJsZSBlbnRyaWVz
OiAxNjM4NCAob3JkZXI6IDgsIDEwNDg1NzYgYnl0ZXMpDQpbICAgIDAuMDcyNTA1XSBUQ1A6
IEhhc2ggdGFibGVzIGNvbmZpZ3VyZWQgKGVzdGFibGlzaGVkIDE2Mzg0IGJpbmQgMTYzODQp
DQpbICAgIDAuMDcyNTU3XSBUQ1A6IHJlbm8gcmVnaXN0ZXJlZA0KWyAgICAwLjA3MjU3NF0g
VURQIGhhc2ggdGFibGUgZW50cmllczogMjU2IChvcmRlcjogMywgNDA5NjAgYnl0ZXMpDQpb
ICAgIDAuMDcyNjEyXSBVRFAtTGl0ZSBoYXNoIHRhYmxlIGVudHJpZXM6IDI1NiAob3JkZXI6
IDMsIDQwOTYwIGJ5dGVzKQ0KWyAgICAwLjA3Mjc1NV0gTkVUOiBSZWdpc3RlcmVkIHByb3Rv
Y29sIGZhbWlseSAxDQpbICAgIDAuMDcyNzY3XSBQQ0k6IENMUyAwIGJ5dGVzLCBkZWZhdWx0
IDY0DQpbICAgIDAuMDcyOTEyXSBUcnlpbmcgdG8gdW5wYWNrIHJvb3RmcyBpbWFnZSBhcyBp
bml0cmFtZnMuLi4NClsgICAgMC4wOTQyMzRdIEZyZWVpbmcgaW5pdHJkIG1lbW9yeTogMTMz
MjhrIGZyZWVkDQpbICAgIDAuMTAxMTk0XSBETUEtQVBJOiBwcmVhbGxvY2F0ZWQgMzI3Njgg
ZGVidWcgZW50cmllcw0KWyAgICAwLjEwMTIwNl0gRE1BLUFQSTogZGVidWdnaW5nIGVuYWJs
ZWQgYnkga2VybmVsIGNvbmZpZw0KWyAgICAwLjEwMTQyMF0gcGxhdGZvcm0gcnRjX2Ntb3M6
IHJlZ2lzdGVyZWQgcGxhdGZvcm0gUlRDIGRldmljZSAobm8gUE5QIGRldmljZSBmb3VuZCkN
ClsgICAgMC4xMDI1NDldIHNoYTFfc3NzZTM6IE5laXRoZXIgQVZYIG5vciBTU1NFMyBpcyBh
dmFpbGFibGUvdXNhYmxlLg0KWyAgICAwLjEwMjkxNV0gYXVkaXQ6IGluaXRpYWxpemluZyBu
ZXRsaW5rIHNvY2tldCAoZGlzYWJsZWQpDQpbICAgIDAuMTAyOTQ4XSB0eXBlPTIwMDAgYXVk
aXQoMTM0OTk0ODA1MC44MjU6MSk6IGluaXRpYWxpemVkDQpbICAgIDAuMTAzNDcwXSBIdWdl
VExCIHJlZ2lzdGVyZWQgMiBNQiBwYWdlIHNpemUsIHByZS1hbGxvY2F0ZWQgMCBwYWdlcw0K
WyAgICAwLjEwODkxMl0gVkZTOiBEaXNrIHF1b3RhcyBkcXVvdF82LjUuMg0KWyAgICAwLjEw
OTAyMV0gRHF1b3QtY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiA1MTIgKG9yZGVyIDAsIDQw
OTYgYnl0ZXMpDQpbICAgIDAuMTEwNTQwXSBOVEZTIGRyaXZlciAyLjEuMzAgW0ZsYWdzOiBS
L1ddLg0KWyAgICAwLjExMDc1OF0gZnVzZSBpbml0IChBUEkgdmVyc2lvbiA3LjIwKQ0KWyAg
ICAwLjExMDk2MF0gbXNnbW5pIGhhcyBiZWVuIHNldCB0byA5NTcNClsgICAgMC4xMTE2NzNd
IEJsb2NrIGxheWVyIFNDU0kgZ2VuZXJpYyAoYnNnKSBkcml2ZXIgdmVyc2lvbiAwLjQgbG9h
ZGVkIChtYWpvciAyNTIpDQpbICAgIDAuMTExNjk1XSBpbyBzY2hlZHVsZXIgbm9vcCByZWdp
c3RlcmVkDQpbICAgIDAuMTExNjk5XSBpbyBzY2hlZHVsZXIgZGVhZGxpbmUgcmVnaXN0ZXJl
ZA0KWyAgICAwLjExMTg4MF0gaW8gc2NoZWR1bGVyIGNmcSByZWdpc3RlcmVkIChkZWZhdWx0
KQ0KWyAgICAwLjExMjkwOF0gY3JjMzI6IENSQ19MRV9CSVRTID0gNjQsIENSQ19CRSBCSVRT
ID0gNjQNClsgICAgMC4xMTI5MTJdIGNyYzMyOiBzZWxmIHRlc3RzIHBhc3NlZCwgcHJvY2Vz
c2VkIDIyNTk0NCBieXRlcyBpbiAxMTI1ODAgbnNlYw0KWyAgICAwLjExMzAyMV0gY3JjMzJj
OiBDUkNfTEVfQklUUyA9IDY0DQpbICAgIDAuMTE3MjI2XSBjcmMzMmM6IHNlbGYgdGVzdHMg
cGFzc2VkLCBwcm9jZXNzZWQgMjI1OTQ0IGJ5dGVzIGluIDUwMzMzIG5zZWMNClsgICAgMC4x
MTc1NzZdIHBjaV9ob3RwbHVnOiBQQ0kgSG90IFBsdWcgUENJIENvcmUgdmVyc2lvbjogMC41
DQpbICAgIDAuMTE3Nzk3XSBwY2llaHA6IFBDSSBFeHByZXNzIEhvdCBQbHVnIENvbnRyb2xs
ZXIgRHJpdmVyIHZlcnNpb246IDAuNA0KWyAgICAwLjExODAxM10gdXNiY29yZTogcmVnaXN0
ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciB1ZGxmYg0KWyAgICAwLjExODQ2N10gRXZlbnQt
Y2hhbm5lbCBkZXZpY2UgaW5zdGFsbGVkLg0KWyAgICAwLjExOTIxM10gU2VyaWFsOiA4MjUw
LzE2NTUwIGRyaXZlciwgNCBwb3J0cywgSVJRIHNoYXJpbmcgZW5hYmxlZA0KWyAgICAwLjEy
MDA1NV0gTGludXggYWdwZ2FydCBpbnRlcmZhY2UgdjAuMTAzDQpbICAgIDAuMTIwMzc0XSBI
YW5nY2hlY2s6IHN0YXJ0aW5nIGhhbmdjaGVjayB0aW1lciAwLjkuMSAodGljayBpcyAxODAg
c2Vjb25kcywgbWFyZ2luIGlzIDYwIHNlY29uZHMpLg0KWyAgICAwLjEyMDM4M10gSGFuZ2No
ZWNrOiBVc2luZyBnZXRyYXdtb25vdG9uaWMoKS4NClsgICAgMC4xMjA0NDNdIFtkcm1dIElu
aXRpYWxpemVkIGRybSAxLjEuMCAyMDA2MDgxMA0KWyAgICAwLjEyMzI2OF0gYnJkOiBtb2R1
bGUgbG9hZGVkDQpbICAgIDAuMTI0ODU5XSBsb29wOiBtb2R1bGUgbG9hZGVkDQpbICAgIDAu
MTI3Nzc4XSB0dW46IFVuaXZlcnNhbCBUVU4vVEFQIGRldmljZSBkcml2ZXIsIDEuNg0KWyAg
ICAwLjEyNzc5Ml0gdHVuOiAoQykgMTk5OS0yMDA0IE1heCBLcmFzbnlhbnNreSA8bWF4a0Bx
dWFsY29tbS5jb20+DQpbICAgIDAuMTI3ODczXSBlMTAwMDogSW50ZWwoUikgUFJPLzEwMDAg
TmV0d29yayBEcml2ZXIgLSB2ZXJzaW9uIDcuMy4yMS1rOC1OQVBJDQpbICAgIDAuMTI3ODgw
XSBlMTAwMDogQ29weXJpZ2h0IChjKSAxOTk5LTIwMDYgSW50ZWwgQ29ycG9yYXRpb24uDQpb
ICAgIDAuMTI4MDA0XSBJbml0aWFsaXNpbmcgWGVuIHZpcnR1YWwgZXRoZXJuZXQgZHJpdmVy
Lg0KWyAgICAwLjEzMzA1OF0gZWhjaV9oY2Q6IFVTQiAyLjAgJ0VuaGFuY2VkJyBIb3N0IENv
bnRyb2xsZXIgKEVIQ0kpIERyaXZlcg0KWyAgICAwLjEzMzA3MV0gZWhjaV9oY2Q6IGJsb2Nr
IHNpemVzOiBxaCAxMDQgcXRkIDk2IGl0ZCAxOTIgc2l0ZCA5Ng0KWyAgICAwLjEzMzEzMF0g
b2hjaV9oY2Q6IFVTQiAxLjEgJ09wZW4nIEhvc3QgQ29udHJvbGxlciAoT0hDSSkgRHJpdmVy
DQpbICAgIDAuMTMzMTM2XSBvaGNpX2hjZDogYmxvY2sgc2l6ZXM6IGVkIDgwIHRkIDk2DQpb
ICAgIDAuMTMzMTg4XSB1aGNpX2hjZDogVVNCIFVuaXZlcnNhbCBIb3N0IENvbnRyb2xsZXIg
SW50ZXJmYWNlIGRyaXZlcg0KWyAgICAwLjEzMzMwMV0gdXNiY29yZTogcmVnaXN0ZXJlZCBu
ZXcgaW50ZXJmYWNlIGRyaXZlciB1c2JscA0KWyAgICAwLjEzMzMwNl0gSW5pdGlhbGl6aW5n
IFVTQiBNYXNzIFN0b3JhZ2UgZHJpdmVyLi4uDQpbICAgIDAuMTMzMzU5XSB1c2Jjb3JlOiBy
ZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHVzYi1zdG9yYWdlDQpbICAgIDAuMTMz
MzY0XSBVU0IgTWFzcyBTdG9yYWdlIHN1cHBvcnQgcmVnaXN0ZXJlZC4NClsgICAgMC4xMzM0
OTddIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgdXNic2VyaWFs
DQpbICAgIDAuMTMzNTY4XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJp
dmVyIGNwMjEweA0KWyAgICAwLjEzMzcwMV0gdXNic2VyaWFsOiBVU0IgU2VyaWFsIHN1cHBv
cnQgcmVnaXN0ZXJlZCBmb3IgY3AyMTB4DQpbICAgIDAuMTMzNzU4XSB1c2Jjb3JlOiByZWdp
c3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIGN5cHJlc3NfbTgNClsgICAgMC4xMzM4MTVd
IHVzYnNlcmlhbDogVVNCIFNlcmlhbCBzdXBwb3J0IHJlZ2lzdGVyZWQgZm9yIERlTG9ybWUg
RWFydGhtYXRlIFVTQg0KWyAgICAwLjEzMzg3Ml0gdXNic2VyaWFsOiBVU0IgU2VyaWFsIHN1
cHBvcnQgcmVnaXN0ZXJlZCBmb3IgSElELT5DT00gUlMyMzIgQWRhcHRlcg0KWyAgICAwLjEz
MzkzMV0gdXNic2VyaWFsOiBVU0IgU2VyaWFsIHN1cHBvcnQgcmVnaXN0ZXJlZCBmb3IgTm9r
aWEgQ0EtNDIgVjIgQWRhcHRlcg0KWyAgICAwLjEzMzk4OV0gdXNiY29yZTogcmVnaXN0ZXJl
ZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBtb3M3NzIwDQpbICAgIDAuMTM0MDQ1XSB1c2JzZXJp
YWw6IFVTQiBTZXJpYWwgc3VwcG9ydCByZWdpc3RlcmVkIGZvciBNb3NjaGlwIDIgcG9ydCBh
ZGFwdGVyDQpbICAgIDAuMTM0MTAyXSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZh
Y2UgZHJpdmVyIG1vczc4NDANClsgICAgMC4xMzQxNThdIHVzYnNlcmlhbDogVVNCIFNlcmlh
bCBzdXBwb3J0IHJlZ2lzdGVyZWQgZm9yIE1vc2NoaXAgNzg0MC83ODIwIFVTQiBTZXJpYWwg
RHJpdmVyDQpbICAgIDAuMTM0MzYwXSBpODA0MjogUE5QOiBObyBQUy8yIGNvbnRyb2xsZXIg
Zm91bmQuIFByb2JpbmcgcG9ydHMgZGlyZWN0bHkuDQpbICAgIDAuMTM1MTkwXSBpODA0Mjog
Tm8gY29udHJvbGxlciBmb3VuZA0KWyAgICAwLjEzNTI4NF0gbW91c2VkZXY6IFBTLzIgbW91
c2UgZGV2aWNlIGNvbW1vbiBmb3IgYWxsIG1pY2UNClsgICAgMC4xMzc1MjBdIGJsa2Zyb250
OiB4dmRhOiBmbHVzaCBkaXNrY2FjaGU6IGVuYWJsZWQNClsgICAgMC4xOTYwNTRdIHJ0Y19j
bW9zIHJ0Y19jbW9zOiBydGMgY29yZTogcmVnaXN0ZXJlZCBydGNfY21vcyBhcyBydGMwDQpb
ICAgIDAuMTk2NDM4XSBpZGFfcmVtb3ZlIGNhbGxlZCBmb3IgaWQ9MCB3aGljaCBpcyBub3Qg
YWxsb2NhdGVkLg0KWyAgICAwLjE5NjQ0OF0gcnRjX2Ntb3M6IHByb2JlIG9mIHJ0Y19jbW9z
IGZhaWxlZCB3aXRoIGVycm9yIC0zOA0KWyAgICAwLjE5NzAwOV0gbGlyY19kZXY6IElSIFJl
bW90ZSBDb250cm9sIGRyaXZlciByZWdpc3RlcmVkLCBtYWpvciAyNTAgDQpbICAgIDAuMTk3
MDI3XSBJUiBORUMgcHJvdG9jb2wgaGFuZGxlciBpbml0aWFsaXplZA0KWyAgICAwLjE5NzAz
MV0gSVIgUkM1KHgpIHByb3RvY29sIGhhbmRsZXIgaW5pdGlhbGl6ZWQNClsgICAgMC4xOTcw
MzVdIElSIFJDNiBwcm90b2NvbCBoYW5kbGVyIGluaXRpYWxpemVkDQpbICAgIDAuMTk3MDM4
XSBJUiBKVkMgcHJvdG9jb2wgaGFuZGxlciBpbml0aWFsaXplZA0KWyAgICAwLjE5NzA0MV0g
SVIgU29ueSBwcm90b2NvbCBoYW5kbGVyIGluaXRpYWxpemVkDQpbICAgIDAuMTk3MDQ1XSBJ
UiBSQzUgKHN0cmVhbXphcCkgcHJvdG9jb2wgaGFuZGxlciBpbml0aWFsaXplZA0KWyAgICAw
LjE5NzA0OV0gSVIgU0FOWU8gcHJvdG9jb2wgaGFuZGxlciBpbml0aWFsaXplZA0KWyAgICAw
LjE5NzA1Ml0gSVIgTUNFIEtleWJvYXJkL21vdXNlIHByb3RvY29sIGhhbmRsZXIgaW5pdGlh
bGl6ZWQNClsgICAgMC4xOTcwNTddIElSIExJUkMgYnJpZGdlIGhhbmRsZXIgaW5pdGlhbGl6
ZWQNClsgICAgMC4xOTcyNjhdIHNwNTEwMF90Y286IFNQNTEwMCBUQ08gV2F0Y2hEb2cgVGlt
ZXIgRHJpdmVyIHYwLjAxDQpbICAgIDAuMTk3MzgyXSB4ZW5fd2R0OiBYZW4gV2F0Y2hEb2cg
VGltZXIgRHJpdmVyIHYwLjAxDQpbICAgIDAuMTk3NTc4XSB4ZW5fd2R0OiBpbml0aWFsaXpl
ZCAodGltZW91dD02MHMsIG5vd2F5b3V0PTApDQpbICAgIDAuMTk3ODIwXSBkZXZpY2UtbWFw
cGVyOiBpb2N0bDogNC4yMy4wLWlvY3RsICgyMDEyLTA3LTI1KSBpbml0aWFsaXNlZDogZG0t
ZGV2ZWxAcmVkaGF0LmNvbQ0KWyAgICAwLjE5OTEyM10gdXNiY29yZTogcmVnaXN0ZXJlZCBu
ZXcgaW50ZXJmYWNlIGRyaXZlciB1c2JoaWQNClsgICAgMC4xOTkxMjldIHVzYmhpZDogVVNC
IEhJRCBjb3JlIGRyaXZlcg0KWyAgICAwLjIwMjMxM10gdXNiY29yZTogcmVnaXN0ZXJlZCBu
ZXcgaW50ZXJmYWNlIGRyaXZlciBzbmQtdXNiLWF1ZGlvDQpbICAgIDAuMjAyMzczXSB1c2Jj
b3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHNuZC11YTEwMQ0KWyAgICAw
LjIwMjQzNF0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBzbmQt
dXNiLXVzeDJ5DQpbICAgIDAuMjAyNDg4XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRl
cmZhY2UgZHJpdmVyIHNuZC11c2ItY2FpYXENClsgICAgMC4yMDI1NDNdIHVzYmNvcmU6IHJl
Z2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgc25kLXVzYi02ZmlyZQ0KWyAgICAwLjIw
MjU3NV0gTmV0ZmlsdGVyIG1lc3NhZ2VzIHZpYSBORVRMSU5LIHYwLjMwLg0KWyAgICAwLjIw
MjU4M10gbmZubF9hY2N0OiByZWdpc3RlcmluZyB3aXRoIG5mbmV0bGluay4NClsgICAgMC4y
MDI2MjZdIG5mX2Nvbm50cmFjayB2ZXJzaW9uIDAuNS4wICgzODI4IGJ1Y2tldHMsIDE1MzEy
IG1heCkNClsgICAgMC4yMDI5NTBdIGN0bmV0bGluayB2MC45MzogcmVnaXN0ZXJpbmcgd2l0
aCBuZm5ldGxpbmsuDQpbICAgIDAuMjAzMjUwXSB4dF90aW1lOiBrZXJuZWwgdGltZXpvbmUg
aXMgLTAwMDANClsgICAgMC4zMTY4NDhdIGlwX3NldDogcHJvdG9jb2wgNg0KWyAgICAwLjMx
Njg3NV0gSVBWUzogUmVnaXN0ZXJlZCBwcm90b2NvbHMgKCkNClsgICAgMC4zMTY5OTZdIElQ
VlM6IENvbm5lY3Rpb24gaGFzaCB0YWJsZSBjb25maWd1cmVkIChzaXplPTQwOTYsIG1lbW9y
eT02NEtieXRlcykNClsgICAgMC4zMTcwNjhdIElQVlM6IENyZWF0aW5nIG5ldG5zIHNpemU9
MTg5NiBpZD0wDQpbICAgIDAuMzE3MTAwXSBJUFZTOiBpcHZzIGxvYWRlZC4NClsgICAgMC4z
MTcyMTNdIGlwX3RhYmxlczogKEMpIDIwMDAtMjAwNiBOZXRmaWx0ZXIgQ29yZSBUZWFtDQpb
ICAgIDAuMzE3Mjc5XSBUQ1A6IGN1YmljIHJlZ2lzdGVyZWQNClsgICAgMC4zMTcyODVdIE5F
VDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMTcNClsgICAgMC4zMTczNDBdIEJyaWRn
ZSBmaXJld2FsbGluZyByZWdpc3RlcmVkDQpbICAgIDAuMzE3MzU5XSBFYnRhYmxlcyB2Mi4w
IHJlZ2lzdGVyZWQNClsgICAgMC4zMTc2MTddIHJlZ2lzdGVyZWQgdGFza3N0YXRzIHZlcnNp
b24gMQ0KWyAgICAwLjc4MjEzNF0gIHh2ZGE6IHh2ZGExIHh2ZGEyDQpbICAgIDAuODE3MTQw
XSBjb25zb2xlIFtuZXRjb24wXSBlbmFibGVkDQpbICAgIDAuODE3MTY2XSBuZXRjb25zb2xl
OiBuZXR3b3JrIGxvZ2dpbmcgc3RhcnRlZA0KWyAgICAwLjgxNzM2OF0gQUxTQSBkZXZpY2Ug
bGlzdDoNClsgICAgMC44MTczODVdICAgTm8gc291bmRjYXJkcyBmb3VuZC4NClsgICAgMC44
MjA0MjVdIEZyZWVpbmcgdW51c2VkIGtlcm5lbCBtZW1vcnk6IDY5NmsgZnJlZWQNClsgICAg
MC44MjA4ODddIFdyaXRlIHByb3RlY3RpbmcgdGhlIGtlcm5lbCByZWFkLW9ubHkgZGF0YTog
MTIyODhrDQpbICAgIDAuODM3ODMwXSBGcmVlaW5nIHVudXNlZCBrZXJuZWwgbWVtb3J5OiA3
MDhrIGZyZWVkDQpbICAgIDAuODM5OTM3XSBGcmVlaW5nIHVudXNlZCBrZXJuZWwgbWVtb3J5
OiAxMDc2ayBmcmVlZA0KWyAgICAzLjg3MTU4MV0gRVhUNC1mcyAoeHZkYTEpOiBtb3VudGVk
IGZpbGVzeXN0ZW0gd2l0aCBvcmRlcmVkIGRhdGEgbW9kZS4gT3B0czogKG51bGwpDQpbICAg
MTMuNDg2MTE1XSBBZGRpbmcgNzY5MDIwayBzd2FwIG9uIC9kZXYveHZkYTIuICBQcmlvcml0
eTotMSBleHRlbnRzOjEgYWNyb3NzOjc2OTAyMGsgU1MNClsgICAxMy41MjkxMzRdIEVYVDQt
ZnMgKHh2ZGExKTogcmUtbW91bnRlZC4gT3B0czogKG51bGwpDQpbICAgMTQuNDQ5MjA2XSBF
WFQ0LWZzICh4dmRhMSk6IHJlLW1vdW50ZWQuIE9wdHM6IGVycm9ycz1yZW1vdW50LXJvDQpb
ICAgMjIuOTY3Mzk3XSB0dHlfaW5pdF9kZXY6IDIgY2FsbGJhY2tzIHN1cHByZXNzZWQNClsg
ICAyMi45Njc2OTJdIHR0eVMwOiBMU1Igc2FmZXR5IGNoZWNrIGVuZ2FnZWQhDQpbICAgMjIu
OTcwMzM0XSB0dHlTMDogTFNSIHNhZmV0eSBjaGVjayBlbmdhZ2VkIQ0KWyAgIDIyLjk3Mjk1
Nl0gdHR5UzE6IExTUiBzYWZldHkgY2hlY2sgZW5nYWdlZCENClsgICAyMi45NzQ4MTFdIHR0
eVMxOiBMU1Igc2FmZXR5IGNoZWNrIGVuZ2FnZWQhDQpbICAgMzQuMjk4NTQ5XSAtLS0tLS0t
LS0tLS1bIGN1dCBoZXJlIF0tLS0tLS0tLS0tLS0NClsgICAzNC4yOTg1NjddIFdBUk5JTkc6
IGF0IGRyaXZlcnMvbmV0L3hlbi1uZXRmcm9udC5jOjQ2NSB4ZW5uZXRfc3RhcnRfeG1pdCsw
eDdmZS8weDg2MCgpDQpbICAgMzQuMjk4NTc0XSBNb2R1bGVzIGxpbmtlZCBpbjoNClsgICAz
NC4yOTg1OTddIFBpZDogMTU4MCwgY29tbTogc3NoZCBOb3QgdGFpbnRlZCAzLjYuMHByZS1y
YzEtMjAxMjEwMTEgIzENClsgICAzNC4yOTg2MDNdIENhbGwgVHJhY2U6DQpbICAgMzQuMjk4
NjExXSAgWzxmZmZmZmZmZjgxMDY2NGVhPl0gd2Fybl9zbG93cGF0aF9jb21tb24rMHg3YS8w
eGIwDQpbICAgMzQuMjk4NjE3XSAgWzxmZmZmZmZmZjgxMDY2NTM1Pl0gd2Fybl9zbG93cGF0
aF9udWxsKzB4MTUvMHgyMA0KWyAgIDM0LjI5ODYyM10gIFs8ZmZmZmZmZmY4MTQ2ZDg5ZT5d
IHhlbm5ldF9zdGFydF94bWl0KzB4N2ZlLzB4ODYwDQpbICAgMzQuMjk4NjMxXSAgWzxmZmZm
ZmZmZjgxNjFmMzQ5Pl0gZGV2X2hhcmRfc3RhcnRfeG1pdCsweDIwOS8weDQ2MA0KWyAgIDM0
LjI5ODYzN10gIFs8ZmZmZmZmZmY4MTYzYjAzNj5dIHNjaF9kaXJlY3RfeG1pdCsweGY2LzB4
MjkwDQpbICAgMzQuMjk4NjQzXSAgWzxmZmZmZmZmZjgxNjFmNzQ2Pl0gZGV2X3F1ZXVlX3ht
aXQrMHgxYTYvMHg1YTANClsgICAzNC4yOTg2NDldICBbPGZmZmZmZmZmODE2MWY1YTA+XSA/
IGRldl9oYXJkX3N0YXJ0X3htaXQrMHg0NjAvMHg0NjANClsgICAzNC4yOTg2NTZdICBbPGZm
ZmZmZmZmODEwYWE4ZTU+XSA/IHRyYWNlX3NvZnRpcnFzX29mZisweDg1LzB4MWIwDQpbICAg
MzQuMjk4NjYzXSAgWzxmZmZmZmZmZjgxNmI5NTM2Pl0gaXBfZmluaXNoX291dHB1dCsweDIy
Ni8weDUzMA0KWyAgIDM0LjI5ODY2OF0gIFs8ZmZmZmZmZmY4MTZiOTNkZD5dID8gaXBfZmlu
aXNoX291dHB1dCsweGNkLzB4NTMwDQpbICAgMzQuMjk4Njc0XSAgWzxmZmZmZmZmZjgxNmI5
ODk5Pl0gaXBfb3V0cHV0KzB4NTkvMHhlMA0KWyAgIDM0LjI5ODY4MF0gIFs8ZmZmZmZmZmY4
MTZiODNiOD5dIGlwX2xvY2FsX291dCsweDI4LzB4OTANClsgICAzNC4yOTg2ODddICBbPGZm
ZmZmZmZmODE2Yjg5NmY+XSBpcF9xdWV1ZV94bWl0KzB4MTdmLzB4NGEwDQpbICAgMzQuMjk4
NjkyXSAgWzxmZmZmZmZmZjgxNmI4N2YwPl0gPyBpcF9zZW5kX3VuaWNhc3RfcmVwbHkrMHgz
NDAvMHgzNDANClsgICAzNC4yOTg2OTldICBbPGZmZmZmZmZmODEwYTBiYTc+XSA/IGdldG5z
dGltZW9mZGF5KzB4NDcvMHhlMA0KWyAgIDM0LjI5ODcwNV0gIFs8ZmZmZmZmZmY4MTYwZjRj
OT5dID8gX19za2JfY2xvbmUrMHgyOS8weDEyMA0KWyAgIDM0LjI5ODcxMV0gIFs8ZmZmZmZm
ZmY4MTZjZWEyMD5dIHRjcF90cmFuc21pdF9za2IrMHg0MDAvMHg4ZDANClsgICAzNC4yOTg3
MTddICBbPGZmZmZmZmZmODE2ZDE5ZmE+XSB0Y3Bfd3JpdGVfeG1pdCsweDIxYS8weGE1MA0K
WyAgIDM0LjI5ODcyM10gIFs8ZmZmZmZmZmY4MTZkMjI1Yj5dIHRjcF9wdXNoX29uZSsweDJi
LzB4NDANClsgICAzNC4yOTg3MjhdICBbPGZmZmZmZmZmODE2YzJkZWM+XSB0Y3Bfc2VuZG1z
ZysweDhkYy8weGUyMA0KWyAgIDM0LjI5ODczNV0gIFs8ZmZmZmZmZmY4MTZlOGYxOT5dIGlu
ZXRfc2VuZG1zZysweGE5LzB4MTAwDQpbICAgMzQuMjk4NzQwXSAgWzxmZmZmZmZmZjgxNmU4
ZTcwPl0gPyBpbmV0X2F1dG9iaW5kKzB4NzAvMHg3MA0KWyAgIDM0LjI5ODc0Nl0gIFs8ZmZm
ZmZmZmY4MTBiMGY4OD5dID8gbG9ja19hY3F1aXJlKzB4ZDgvMHgxMDANClsgICAzNC4yOTg3
NTNdICBbPGZmZmZmZmZmODE2MDYzMGQ+XSBzb2NrX2Fpb193cml0ZSsweDEyZC8weDE0MA0K
WyAgIDM0LjI5ODc2Ml0gIFs8ZmZmZmZmZmY4MTE0MzViMj5dIGRvX3N5bmNfd3JpdGUrMHhh
Mi8weGUwDQpbICAgMzQuMjk4NzY4XSAgWzxmZmZmZmZmZjgxMGFkMjJkPl0gPyB0cmFjZV9o
YXJkaXJxc19vbisweGQvMHgxMA0KWyAgIDM0LjI5ODc3NF0gIFs8ZmZmZmZmZmY4MTE0NDFk
ND5dIHZmc193cml0ZSsweDE3NC8weDE5MA0KWyAgIDM0LjI5ODc3OV0gIFs8ZmZmZmZmZmY4
MTE0NDJmYT5dIHN5c193cml0ZSsweDVhLzB4YTANClsgICAzNC4yOTg3ODZdICBbPGZmZmZm
ZmZmODEyYjMzZGU+XSA/IHRyYWNlX2hhcmRpcnFzX29uX3RodW5rKzB4M2EvMHgzZg0KWyAg
IDM0LjI5ODc5Ml0gIFs8ZmZmZmZmZmY4MTc0OTFjYz5dIGNzdGFyX2Rpc3BhdGNoKzB4Ny8w
eDI2DQpbICAgMzQuMjk4Nzk3XSAtLS1bIGVuZCB0cmFjZSAyZTI4ZWVjOTNiN2E4Yjc0IF0t
LS0NClsgICAzNC4yOTg4MjVdIC0tLS0tLS0tLS0tLVsgY3V0IGhlcmUgXS0tLS0tLS0tLS0t
LQ0KWyAgIDM0LjI5ODgzMl0gV0FSTklORzogYXQgZHJpdmVycy9uZXQveGVuLW5ldGZyb250
LmM6NDY1IHhlbm5ldF9zdGFydF94bWl0KzB4N2ZlLzB4ODYwKCkNClsgICAzNC4yOTg4Mzhd
IE1vZHVsZXMgbGlua2VkIGluOg0KWyAgIDM0LjI5ODg0M10gUGlkOiAxNTgwLCBjb21tOiBz
c2hkIFRhaW50ZWQ6IEcgICAgICAgIFcgICAgMy42LjBwcmUtcmMxLTIwMTIxMDExICMxDQpb
ICAgMzQuMjk4ODQ4XSBDYWxsIFRyYWNlOg0KWyAgIDM0LjI5ODg1Ml0gIFs8ZmZmZmZmZmY4
MTA2NjRlYT5dIHdhcm5fc2xvd3BhdGhfY29tbW9uKzB4N2EvMHhiMA0KWyAgIDM0LjI5ODg1
OF0gIFs8ZmZmZmZmZmY4MTA2NjUzNT5dIHdhcm5fc2xvd3BhdGhfbnVsbCsweDE1LzB4MjAN
ClsgICAzNC4yOTg4NjRdICBbPGZmZmZmZmZmODE0NmQ4OWU+XSB4ZW5uZXRfc3RhcnRfeG1p
dCsweDdmZS8weDg2MA0KWyAgIDM0LjI5ODg3MF0gIFs8ZmZmZmZmZmY4MTYxZjM0OT5dIGRl
dl9oYXJkX3N0YXJ0X3htaXQrMHgyMDkvMHg0NjANClsgICAzNC4yOTg4NzZdICBbPGZmZmZm
ZmZmODE2M2IwMzY+XSBzY2hfZGlyZWN0X3htaXQrMHhmNi8weDI5MA0KWyAgIDM0LjI5ODg4
MV0gIFs8ZmZmZmZmZmY4MTYxZjc0Nj5dIGRldl9xdWV1ZV94bWl0KzB4MWE2LzB4NWEwDQpb
ICAgMzQuMjk4ODg3XSAgWzxmZmZmZmZmZjgxNjFmNWEwPl0gPyBkZXZfaGFyZF9zdGFydF94
bWl0KzB4NDYwLzB4NDYwDQpbICAgMzQuMjk4ODkzXSAgWzxmZmZmZmZmZjgxMGFhOGU1Pl0g
PyB0cmFjZV9zb2Z0aXJxc19vZmYrMHg4NS8weDFiMA0KWyAgIDM0LjI5ODg5OV0gIFs8ZmZm
ZmZmZmY4MTZiOTUzNj5dIGlwX2ZpbmlzaF9vdXRwdXQrMHgyMjYvMHg1MzANClsgICAzNC4y
OTg5MDRdICBbPGZmZmZmZmZmODE2YjkzZGQ+XSA/IGlwX2ZpbmlzaF9vdXRwdXQrMHhjZC8w
eDUzMA0KWyAgIDM0LjI5ODkxMF0gIFs8ZmZmZmZmZmY4MTZiOTg5OT5dIGlwX291dHB1dCsw
eDU5LzB4ZTANClsgICAzNC4yOTg5MTZdICBbPGZmZmZmZmZmODE2YjgzYjg+XSBpcF9sb2Nh
bF9vdXQrMHgyOC8weDkwDQpbICAgMzQuMjk4OTIxXSAgWzxmZmZmZmZmZjgxNmI4OTZmPl0g
aXBfcXVldWVfeG1pdCsweDE3Zi8weDRhMA0KWyAgIDM0LjI5ODkyN10gIFs8ZmZmZmZmZmY4
MTZiODdmMD5dID8gaXBfc2VuZF91bmljYXN0X3JlcGx5KzB4MzQwLzB4MzQwDQpbICAgMzQu
Mjk4OTMyXSAgWzxmZmZmZmZmZjgxMGEwYmE3Pl0gPyBnZXRuc3RpbWVvZmRheSsweDQ3LzB4
ZTANClsgICAzNC4yOTg5MzhdICBbPGZmZmZmZmZmODE2MGY0Yzk+XSA/IF9fc2tiX2Nsb25l
KzB4MjkvMHgxMjANClsgICAzNC4yOTg5NDNdICBbPGZmZmZmZmZmODE2Y2VhMjA+XSB0Y3Bf
dHJhbnNtaXRfc2tiKzB4NDAwLzB4OGQwDQpbICAgMzQuMjk4OTQ5XSAgWzxmZmZmZmZmZjgx
NmQxOWZhPl0gdGNwX3dyaXRlX3htaXQrMHgyMWEvMHhhNTANClsgICAzNC4yOTg5NTVdICBb
PGZmZmZmZmZmODE2ZDIyOWQ+XSBfX3RjcF9wdXNoX3BlbmRpbmdfZnJhbWVzKzB4MmQvMHg5
MA0KWyAgIDM0LjI5ODk2MV0gIFs8ZmZmZmZmZmY4MTZjMjY5Mz5dIHRjcF9zZW5kbXNnKzB4
MTgzLzB4ZTIwDQpbICAgMzQuMjk4OTY2XSAgWzxmZmZmZmZmZjgxNmU4ZjE5Pl0gaW5ldF9z
ZW5kbXNnKzB4YTkvMHgxMDANClsgICAzNC4yOTg5NzJdICBbPGZmZmZmZmZmODE2ZThlNzA+
XSA/IGluZXRfYXV0b2JpbmQrMHg3MC8weDcwDQpbICAgMzQuMjk4OTc3XSAgWzxmZmZmZmZm
ZjgxMGIwZjg4Pl0gPyBsb2NrX2FjcXVpcmUrMHhkOC8weDEwMA0KWyAgIDM0LjI5ODk4M10g
IFs8ZmZmZmZmZmY4MTYwNjMwZD5dIHNvY2tfYWlvX3dyaXRlKzB4MTJkLzB4MTQwDQpbICAg
MzQuMjk4OTg4XSAgWzxmZmZmZmZmZjgxMTQzNWIyPl0gZG9fc3luY193cml0ZSsweGEyLzB4
ZTANClsgICAzNC4yOTg5OTRdICBbPGZmZmZmZmZmODEwYWQyMmQ+XSA/IHRyYWNlX2hhcmRp
cnFzX29uKzB4ZC8weDEwDQpbICAgMzQuMjk5MDAwXSAgWzxmZmZmZmZmZjgxMTQ0MWQ0Pl0g
dmZzX3dyaXRlKzB4MTc0LzB4MTkwDQpbICAgMzQuMjk5MDA1XSAgWzxmZmZmZmZmZjgxMTQ0
MmZhPl0gc3lzX3dyaXRlKzB4NWEvMHhhMA0KWyAgIDM0LjI5OTAxMV0gIFs8ZmZmZmZmZmY4
MTJiMzNkZT5dID8gdHJhY2VfaGFyZGlycXNfb25fdGh1bmsrMHgzYS8weDNmDQpbICAgMzQu
Mjk5MDE3XSAgWzxmZmZmZmZmZjgxNzQ5MWNjPl0gY3N0YXJfZGlzcGF0Y2grMHg3LzB4MjYN
ClsgICAzNC4yOTkwMjJdIC0tLVsgZW5kIHRyYWNlIDJlMjhlZWM5M2I3YThiNzUgXS0tLQ0K
WyAgIDM0LjI5OTAzNl0gLS0tLS0tLS0tLS0tWyBjdXQgaGVyZSBdLS0tLS0tLS0tLS0tDQpb
ICAgMzQuMjk5MDQyXSBXQVJOSU5HOiBhdCBkcml2ZXJzL25ldC94ZW4tbmV0ZnJvbnQuYzo0
NjUgeGVubmV0X3N0YXJ0X3htaXQrMHg3ZmUvMHg4NjAoKQ0KWyAgIDM0LjI5OTA0N10gTW9k
dWxlcyBsaW5rZWQgaW46DQpbICAgMzQuMjk5MDUyXSBQaWQ6IDE1ODAsIGNvbW06IHNzaGQg
VGFpbnRlZDogRyAgICAgICAgVyAgICAzLjYuMHByZS1yYzEtMjAxMjEwMTEgIzENClsgICAz
NC4yOTkwNTddIENhbGwgVHJhY2U6DQpbICAgMzQuMjk5MDYxXSAgWzxmZmZmZmZmZjgxMDY2
NGVhPl0gd2Fybl9zbG93cGF0aF9jb21tb24rMHg3YS8weGIwDQpbICAgMzQuMjk5MDcxXSAg
WzxmZmZmZmZmZjgxMDY2NTM1Pl0gd2Fybl9zbG93cGF0aF9udWxsKzB4MTUvMHgyMA0KWyAg
IDM0LjI5OTA3N10gIFs8ZmZmZmZmZmY4MTQ2ZDg5ZT5dIHhlbm5ldF9zdGFydF94bWl0KzB4
N2ZlLzB4ODYwDQpbICAgMzQuMjk5MDg0XSAgWzxmZmZmZmZmZjgxNjFmMzQ5Pl0gZGV2X2hh
cmRfc3RhcnRfeG1pdCsweDIwOS8weDQ2MA0KWyAgIDM0LjI5OTA4OV0gIFs8ZmZmZmZmZmY4
MTYzYjAzNj5dIHNjaF9kaXJlY3RfeG1pdCsweGY2LzB4MjkwDQpbICAgMzQuMjk5MDk1XSAg
WzxmZmZmZmZmZjgxNjFmNzQ2Pl0gZGV2X3F1ZXVlX3htaXQrMHgxYTYvMHg1YTANClsgICAz
NC4yOTkxMDFdICBbPGZmZmZmZmZmODE2MWY1YTA+XSA/IGRldl9oYXJkX3N0YXJ0X3htaXQr
MHg0NjAvMHg0NjANClsgICAzNC4yOTkxMDZdICBbPGZmZmZmZmZmODEwYWE4ZTU+XSA/IHRy
YWNlX3NvZnRpcnFzX29mZisweDg1LzB4MWIwDQpbICAgMzQuMjk5MTEyXSAgWzxmZmZmZmZm
ZjgxNmI5NTM2Pl0gaXBfZmluaXNoX291dHB1dCsweDIyNi8weDUzMA0KWyAgIDM0LjI5OTEx
OF0gIFs8ZmZmZmZmZmY4MTZiOTNkZD5dID8gaXBfZmluaXNoX291dHB1dCsweGNkLzB4NTMw
DQpbICAgMzQuMjk5MTI0XSAgWzxmZmZmZmZmZjgxNmI5ODk5Pl0gaXBfb3V0cHV0KzB4NTkv
MHhlMA0KWyAgIDM0LjI5OTEyOV0gIFs8ZmZmZmZmZmY4MTZiODNiOD5dIGlwX2xvY2FsX291
dCsweDI4LzB4OTANClsgICAzNC4yOTkxMzVdICBbPGZmZmZmZmZmODE2Yjg5NmY+XSBpcF9x
dWV1ZV94bWl0KzB4MTdmLzB4NGEwDQpbICAgMzQuMjk5MTQwXSAgWzxmZmZmZmZmZjgxNmI4
N2YwPl0gPyBpcF9zZW5kX3VuaWNhc3RfcmVwbHkrMHgzNDAvMHgzNDANClsgICAzNC4yOTkx
NDZdICBbPGZmZmZmZmZmODEwYTBiYTc+XSA/IGdldG5zdGltZW9mZGF5KzB4NDcvMHhlMA0K
WyAgIDM0LjI5OTE1Ml0gIFs8ZmZmZmZmZmY4MTYwZjRjOT5dID8gX19za2JfY2xvbmUrMHgy
OS8weDEyMA0KWyAgIDM0LjI5OTE1N10gIFs8ZmZmZmZmZmY4MTZjZWEyMD5dIHRjcF90cmFu
c21pdF9za2IrMHg0MDAvMHg4ZDANClsgICAzNC4yOTkxNjNdICBbPGZmZmZmZmZmODE2ZDE5
ZmE+XSB0Y3Bfd3JpdGVfeG1pdCsweDIxYS8weGE1MA0KWyAgIDM0LjI5OTE2OV0gIFs8ZmZm
ZmZmZmY4MTZkMjI5ZD5dIF9fdGNwX3B1c2hfcGVuZGluZ19mcmFtZXMrMHgyZC8weDkwDQpb
ICAgMzQuMjk5MTc0XSAgWzxmZmZmZmZmZjgxNmMyNjkzPl0gdGNwX3NlbmRtc2crMHgxODMv
MHhlMjANClsgICAzNC4yOTkxODBdICBbPGZmZmZmZmZmODE2ZThmMTk+XSBpbmV0X3NlbmRt
c2crMHhhOS8weDEwMA0KWyAgIDM0LjI5OTE4NV0gIFs8ZmZmZmZmZmY4MTZlOGU3MD5dID8g
aW5ldF9hdXRvYmluZCsweDcwLzB4NzANClsgICAzNC4yOTkxOTFdICBbPGZmZmZmZmZmODEw
YjBmODg+XSA/IGxvY2tfYWNxdWlyZSsweGQ4LzB4MTAwDQpbICAgMzQuMjk5MTk2XSAgWzxm
ZmZmZmZmZjgxNjA2MzBkPl0gc29ja19haW9fd3JpdGUrMHgxMmQvMHgxNDANClsgICAzNC4y
OTkyMDJdICBbPGZmZmZmZmZmODExNDM1YjI+XSBkb19zeW5jX3dyaXRlKzB4YTIvMHhlMA0K
WyAgIDM0LjI5OTIwOF0gIFs8ZmZmZmZmZmY4MTBhZDIyZD5dID8gdHJhY2VfaGFyZGlycXNf
b24rMHhkLzB4MTANClsgICAzNC4yOTkyMTNdICBbPGZmZmZmZmZmODExNDQxZDQ+XSB2ZnNf
d3JpdGUrMHgxNzQvMHgxOTANClsgICAzNC4yOTkyMTldICBbPGZmZmZmZmZmODExNDQyZmE+
XSBzeXNfd3JpdGUrMHg1YS8weGEwDQpbICAgMzQuMjk5MjI0XSAgWzxmZmZmZmZmZjgxMmIz
M2RlPl0gPyB0cmFjZV9oYXJkaXJxc19vbl90aHVuaysweDNhLzB4M2YNClsgICAzNC4yOTky
MzldICBbPGZmZmZmZmZmODE3NDkxY2M+XSBjc3Rhcl9kaXNwYXRjaCsweDcvMHgyNg0KWyAg
IDM0LjI5OTI0M10gLS0tWyBlbmQgdHJhY2UgMmUyOGVlYzkzYjdhOGI3NiBdLS0tDQpbICAg
MzQuNzk0NTkyXSAtLS0tLS0tLS0tLS1bIGN1dCBoZXJlIF0tLS0tLS0tLS0tLS0NClsgICAz
NC43OTQ2MTVdIFdBUk5JTkc6IGF0IGRyaXZlcnMvbmV0L3hlbi1uZXRmcm9udC5jOjQ2NSB4
ZW5uZXRfc3RhcnRfeG1pdCsweDdmZS8weDg2MCgpDQpbICAgMzQuNzk0NjIzXSBNb2R1bGVz
IGxpbmtlZCBpbjoNClsgICAzNC43OTQ2MzJdIFBpZDogMCwgY29tbTogc3dhcHBlci8wIFRh
aW50ZWQ6IEcgICAgICAgIFcgICAgMy42LjBwcmUtcmMxLTIwMTIxMDExICMxDQpbICAgMzQu
Nzk0NjQwXSBDYWxsIFRyYWNlOg0KWyAgIDM0Ljc5NDY0NF0gIDxJUlE+ICBbPGZmZmZmZmZm
ODEwNjY0ZWE+XSB3YXJuX3Nsb3dwYXRoX2NvbW1vbisweDdhLzB4YjANClsgICAzNC43OTQ2
NjBdICBbPGZmZmZmZmZmODEwNjY1MzU+XSB3YXJuX3Nsb3dwYXRoX251bGwrMHgxNS8weDIw
DQpbICAgMzQuNzk0NjY3XSAgWzxmZmZmZmZmZjgxNDZkODllPl0geGVubmV0X3N0YXJ0X3ht
aXQrMHg3ZmUvMHg4NjANClsgICAzNC43OTQ2NzddICBbPGZmZmZmZmZmODE2MWYzNDk+XSBk
ZXZfaGFyZF9zdGFydF94bWl0KzB4MjA5LzB4NDYwDQpbICAgMzQuNzk0Njg1XSAgWzxmZmZm
ZmZmZjgxNjNiMDM2Pl0gc2NoX2RpcmVjdF94bWl0KzB4ZjYvMHgyOTANClsgICAzNC43OTQ2
OTNdICBbPGZmZmZmZmZmODE2MWY3NDY+XSBkZXZfcXVldWVfeG1pdCsweDFhNi8weDVhMA0K
WyAgIDM0Ljc5NDcwMV0gIFs8ZmZmZmZmZmY4MTYxZjVhMD5dID8gZGV2X2hhcmRfc3RhcnRf
eG1pdCsweDQ2MC8weDQ2MA0KWyAgIDM0Ljc5NDcxMF0gIFs8ZmZmZmZmZmY4MTBiMTQxNz5d
ID8gbG9ja19yZWxlYXNlKzB4MTE3LzB4MjUwDQpbICAgMzQuNzk0NzE5XSAgWzxmZmZmZmZm
ZjgxNmI5NTM2Pl0gaXBfZmluaXNoX291dHB1dCsweDIyNi8weDUzMA0KWyAgIDM0Ljc5NDcz
MF0gIFs8ZmZmZmZmZmY4MTZiOTNkZD5dID8gaXBfZmluaXNoX291dHB1dCsweGNkLzB4NTMw
DQpbICAgMzQuNzk0NzQyXSAgWzxmZmZmZmZmZjgxNmI5ODk5Pl0gaXBfb3V0cHV0KzB4NTkv
MHhlMA0KWyAgIDM0Ljc5NDc1MF0gIFs8ZmZmZmZmZmY4MTZiODNiOD5dIGlwX2xvY2FsX291
dCsweDI4LzB4OTANClsgICAzNC43OTQ3NTddICBbPGZmZmZmZmZmODE2Yjg5NmY+XSBpcF9x
dWV1ZV94bWl0KzB4MTdmLzB4NGEwDQpbICAgMzQuNzk0NzY1XSAgWzxmZmZmZmZmZjgxNmI4
N2YwPl0gPyBpcF9zZW5kX3VuaWNhc3RfcmVwbHkrMHgzNDAvMHgzNDANClsgICAzNC43OTQ3
NzNdICBbPGZmZmZmZmZmODEwYTBiYTc+XSA/IGdldG5zdGltZW9mZGF5KzB4NDcvMHhlMA0K
WyAgIDM0Ljc5NDc4MV0gIFs8ZmZmZmZmZmY4MTYwZjRjOT5dID8gX19za2JfY2xvbmUrMHgy
OS8weDEyMA0KWyAgIDM0Ljc5NDc4OF0gIFs8ZmZmZmZmZmY4MTZjZWEyMD5dIHRjcF90cmFu
c21pdF9za2IrMHg0MDAvMHg4ZDANClsgICAzNC43OTQ3OTZdICBbPGZmZmZmZmZmODE2ZDEx
MDY+XSB0Y3BfcmV0cmFuc21pdF9za2IrMHgxYzYvMHg1YTANClsgICAzNC43OTQ4MDRdICBb
PGZmZmZmZmZmODE2ZDE2N2U+XSB0Y3BfeG1pdF9yZXRyYW5zbWl0X3F1ZXVlKzB4MTllLzB4
MzAwDQpbICAgMzQuNzk0ODEyXSAgWzxmZmZmZmZmZjgxNmM5OWZmPl0gdGNwX2Zhc3RyZXRy
YW5zX2FsZXJ0KzB4OTRmLzB4Y2IwDQpbICAgMzQuNzk0ODE5XSAgWzxmZmZmZmZmZjgxNmNh
NzBjPl0gdGNwX2FjaysweDlhYy8weDExNTANClsgICAzNC43OTQ4MjddICBbPGZmZmZmZmZm
ODE2Y2Q4NTg+XSB0Y3BfcmN2X2VzdGFibGlzaGVkKzB4MzE4LzB4NjQwDQpbICAgMzQuNzk0
ODM4XSAgWzxmZmZmZmZmZjgxNmQ1ZWVmPl0gPyB0Y3BfdjRfcmN2KzB4NmNmLzB4YjEwDQpb
ICAgMzQuNzk0ODQ1XSAgWzxmZmZmZmZmZjgxNmQ1NGQ1Pl0gdGNwX3Y0X2RvX3JjdisweDEz
NS8weDQ4MA0KWyAgIDM0Ljc5NDg1NF0gIFs8ZmZmZmZmZmY4MTc0NjFkMj5dID8gX3Jhd19z
cGluX2xvY2tfbmVzdGVkKzB4NDIvMHg1MA0KWyAgIDM0Ljc5NDg2Ml0gIFs8ZmZmZmZmZmY4
MTZkNWVlZj5dID8gdGNwX3Y0X3JjdisweDZjZi8weGIxMA0KWyAgIDM0Ljc5NDg2OV0gIFs8
ZmZmZmZmZmY4MTZkNjE3ZD5dIHRjcF92NF9yY3YrMHg5NWQvMHhiMTANClsgICAzNC43OTQ4
NzZdICBbPGZmZmZmZmZmODEwYjBmODg+XSA/IGxvY2tfYWNxdWlyZSsweGQ4LzB4MTAwDQpb
ICAgMzQuNzk0ODg0XSAgWzxmZmZmZmZmZjgxNmIyOTk1Pl0gPyBpcF9sb2NhbF9kZWxpdmVy
X2ZpbmlzaCsweDQ1LzB4MjMwDQpbICAgMzQuNzk0ODkyXSAgWzxmZmZmZmZmZjgxNmIyYTZh
Pl0gaXBfbG9jYWxfZGVsaXZlcl9maW5pc2grMHgxMWEvMHgyMzANClsgICAzNC43OTQ5MDBd
ICBbPGZmZmZmZmZmODE2YjI5OTU+XSA/IGlwX2xvY2FsX2RlbGl2ZXJfZmluaXNoKzB4NDUv
MHgyMzANClsgICAzNC43OTQ5MDhdICBbPGZmZmZmZmZmODE2YjJiYjg+XSBpcF9sb2NhbF9k
ZWxpdmVyKzB4MzgvMHg4MA0KWyAgIDM0Ljc5NDkxNV0gIFs8ZmZmZmZmZmY4MTZiMjE3YT5d
IGlwX3Jjdl9maW5pc2grMHgxNWEvMHg2MzANClsgICAzNC43OTQ5MjJdICBbPGZmZmZmZmZm
ODE2YjI4Njg+XSBpcF9yY3YrMHgyMTgvMHgzMDANClsgICAzNC43OTQ5MzBdICBbPGZmZmZm
ZmZmODE2MWFjOGQ+XSBfX25ldGlmX3JlY2VpdmVfc2tiKzB4NjVkLzB4OGQwDQpbICAgMzQu
Nzk0OTM3XSAgWzxmZmZmZmZmZjgxNjFhNzc1Pl0gPyBfX25ldGlmX3JlY2VpdmVfc2tiKzB4
MTQ1LzB4OGQwDQpbICAgMzQuNzk0OTQ1XSAgWzxmZmZmZmZmZjgxMGFkMjJkPl0gPyB0cmFj
ZV9oYXJkaXJxc19vbisweGQvMHgxMA0KWyAgIDM0Ljc5NDk1M10gIFs8ZmZmZmZmZmY4MTBm
OTk3Mz5dID8gZnJlZV9ob3RfY29sZF9wYWdlKzB4MWIzLzB4MWUwDQpbICAgMzQuNzk0OTYx
XSAgWzxmZmZmZmZmZjgxNjFkMWY4Pl0gbmV0aWZfcmVjZWl2ZV9za2IrMHgyOC8weGYwDQpb
ICAgMzQuNzk0OTY4XSAgWzxmZmZmZmZmZjgxNjEyZDAzPl0gPyBfX3Bza2JfcHVsbF90YWls
KzB4MjUzLzB4MzQwDQpbICAgMzQuNzk0OTc2XSAgWzxmZmZmZmZmZjgxNDZlNGM1Pl0geGVu
bmV0X3BvbGwrMHhhZDUvMHhlMTANClsgICAzNC43OTQ5OTBdICBbPGZmZmZmZmZmODE2MWRm
YTY+XSBuZXRfcnhfYWN0aW9uKzB4MTM2LzB4MjYwDQpbICAgMzQuNzk0OTk4XSAgWzxmZmZm
ZmZmZjgxMDZlMzgxPl0gPyBfX2RvX3NvZnRpcnErMHg3MS8weDFhMA0KWyAgIDM0Ljc5NTAw
Nl0gIFs8ZmZmZmZmZmY4MTA2ZTNkOT5dIF9fZG9fc29mdGlycSsweGM5LzB4MWEwDQpbICAg
MzQuNzk1MDE0XSAgWzxmZmZmZmZmZjgxNzQ4ZDNjPl0gY2FsbF9zb2Z0aXJxKzB4MWMvMHgz
MA0KWyAgIDM0Ljc5NTAyMV0gIFs8ZmZmZmZmZmY4MTAwZWRiNT5dIGRvX3NvZnRpcnErMHg4
NS8weGYwDQpbICAgMzQuNzk1MDI4XSAgWzxmZmZmZmZmZjgxMDZlMjRlPl0gaXJxX2V4aXQr
MHg5ZS8weGQwDQpbICAgMzQuNzk1MDM3XSAgWzxmZmZmZmZmZjgxMzM5ZjVmPl0geGVuX2V2
dGNobl9kb191cGNhbGwrMHgyZi8weDQwDQpbICAgMzQuNzk1MDQ0XSAgWzxmZmZmZmZmZjgx
NzQ4ZDllPl0geGVuX2RvX2h5cGVydmlzb3JfY2FsbGJhY2srMHgxZS8weDMwDQpbICAgMzQu
Nzk1MDUwXSAgPEVPST4gIFs8ZmZmZmZmZmY4MTAwMTNhYT5dID8geGVuX2h5cGVyY2FsbF9z
Y2hlZF9vcCsweGEvMHgyMA0KWyAgIDM0Ljc5NTA2M10gIFs8ZmZmZmZmZmY4MTAwMTNhYT5d
ID8geGVuX2h5cGVyY2FsbF9zY2hlZF9vcCsweGEvMHgyMA0KWyAgIDM0Ljc5NTA3Ml0gIFs8
ZmZmZmZmZmY4MTAwODY5MD5dID8geGVuX3NhZmVfaGFsdCsweDEwLzB4MjANClsgICAzNC43
OTUwODBdICBbPGZmZmZmZmZmODEwMTYwZDA+XSA/IGRlZmF1bHRfaWRsZSsweDQwLzB4OTAN
ClsgICAzNC43OTUwODddICBbPGZmZmZmZmZmODEwMTY0ODY+XSA/IGNwdV9pZGxlKzB4OTYv
MHhmMA0KWyAgIDM0Ljc5NTA5NF0gIFs8ZmZmZmZmZmY4MTcyMmQzYz5dID8gcmVzdF9pbml0
KzB4YmMvMHhkMA0KWyAgIDM0Ljc5NTEwMV0gIFs8ZmZmZmZmZmY4MTcyMmM4MD5dID8gY3N1
bV9wYXJ0aWFsX2NvcHlfZ2VuZXJpYysweDE3MC8weDE3MA0KWyAgIDM0Ljc5NTExMV0gIFs8
ZmZmZmZmZmY4MWNlMGRmMj5dID8gc3RhcnRfa2VybmVsKzB4MzkwLzB4MzlkDQpbICAgMzQu
Nzk1MTE5XSAgWzxmZmZmZmZmZjgxY2UwODgyPl0gPyBrZXJuZWxfaW5pdCsweDIwYi8weDIw
Yg0KWyAgIDM0Ljc5NTEyNl0gIFs8ZmZmZmZmZmY4MWNlMDM1Nj5dID8geDg2XzY0X3N0YXJ0
X3Jlc2VydmF0aW9ucysweDEzMS8weDEzNg0KWyAgIDM0Ljc5NTEzNV0gIFs8ZmZmZmZmZmY4
MWNlM2Q2MD5dID8geGVuX3N0YXJ0X2tlcm5lbCsweDcwZC8weDcwZg0KWyAgIDM0Ljc5NTE0
Ml0gLS0tWyBlbmQgdHJhY2UgMmUyOGVlYzkzYjdhOGI3NyBdLS0tDQpbICAgMzQuNzk1MTcw
XSAtLS0tLS0tLS0tLS1bIGN1dCBoZXJlIF0tLS0tLS0tLS0tLS0NClsgICAzNC43OTUxNzhd
IFdBUk5JTkc6IGF0IGRyaXZlcnMvbmV0L3hlbi1uZXRmcm9udC5jOjQ2NSB4ZW5uZXRfc3Rh
cnRfeG1pdCsweDdmZS8weDg2MCgpDQpbICAgMzQuNzk1MTg2XSBNb2R1bGVzIGxpbmtlZCBp
bjoNClsgICAzNC43OTUxOTJdIFBpZDogMCwgY29tbTogc3dhcHBlci8wIFRhaW50ZWQ6IEcg
ICAgICAgIFcgICAgMy42LjBwcmUtcmMxLTIwMTIxMDExICMxDQpbICAgMzQuNzk1MTk5XSBD
YWxsIFRyYWNlOg0KWyAgIDM0Ljc5NTIwM10gIDxJUlE+ICBbPGZmZmZmZmZmODEwNjY0ZWE+
XSB3YXJuX3Nsb3dwYXRoX2NvbW1vbisweDdhLzB4YjANClsgICAzNC43OTUyMTVdICBbPGZm
ZmZmZmZmODEwNjY1MzU+XSB3YXJuX3Nsb3dwYXRoX251bGwrMHgxNS8weDIwDQpbICAgMzQu
Nzk1MjIzXSAgWzxmZmZmZmZmZjgxNDZkODllPl0geGVubmV0X3N0YXJ0X3htaXQrMHg3ZmUv
MHg4NjANClsgICAzNC43OTUyMzFdICBbPGZmZmZmZmZmODE2MWYzNDk+XSBkZXZfaGFyZF9z
dGFydF94bWl0KzB4MjA5LzB4NDYwDQpbICAgMzQuNzk1MjM5XSAgWzxmZmZmZmZmZjgxNjNi
MDM2Pl0gc2NoX2RpcmVjdF94bWl0KzB4ZjYvMHgyOTANClsgICAzNC43OTUyNDddICBbPGZm
ZmZmZmZmODE2MWY3NDY+XSBkZXZfcXVldWVfeG1pdCsweDFhNi8weDVhMA0KWyAgIDM0Ljc5
NTI1NF0gIFs8ZmZmZmZmZmY4MTYxZjVhMD5dID8gZGV2X2hhcmRfc3RhcnRfeG1pdCsweDQ2
MC8weDQ2MA0KWyAgIDM0Ljc5NTI2Ml0gIFs8ZmZmZmZmZmY4MTBiMTQxNz5dID8gbG9ja19y
ZWxlYXNlKzB4MTE3LzB4MjUwDQpbICAgMzQuNzk1MjcwXSAgWzxmZmZmZmZmZjgxNmI5NTM2
Pl0gaXBfZmluaXNoX291dHB1dCsweDIyNi8weDUzMA0KWyAgIDM0Ljc5NTI3OF0gIFs8ZmZm
ZmZmZmY4MTZiOTNkZD5dID8gaXBfZmluaXNoX291dHB1dCsweGNkLzB4NTMwDQpbICAgMzQu
Nzk1Mjg1XSAgWzxmZmZmZmZmZjgxNmI5ODk5Pl0gaXBfb3V0cHV0KzB4NTkvMHhlMA0KWyAg
IDM0Ljc5NTI5M10gIFs8ZmZmZmZmZmY4MTZiODNiOD5dIGlwX2xvY2FsX291dCsweDI4LzB4
OTANClsgICAzNC43OTUzMDBdICBbPGZmZmZmZmZmODE2Yjg5NmY+XSBpcF9xdWV1ZV94bWl0
KzB4MTdmLzB4NGEwDQpbICAgMzQuNzk1MzA3XSAgWzxmZmZmZmZmZjgxNmI4N2YwPl0gPyBp
cF9zZW5kX3VuaWNhc3RfcmVwbHkrMHgzNDAvMHgzNDANClsgICAzNC43OTUzMTVdICBbPGZm
ZmZmZmZmODEwYTBiYTc+XSA/IGdldG5zdGltZW9mZGF5KzB4NDcvMHhlMA0KWyAgIDM0Ljc5
NTMyMl0gIFs8ZmZmZmZmZmY4MTYwZjRjOT5dID8gX19za2JfY2xvbmUrMHgyOS8weDEyMA0K
WyAgIDM0Ljc5NTMzMF0gIFs8ZmZmZmZmZmY4MTZjZWEyMD5dIHRjcF90cmFuc21pdF9za2Ir
MHg0MDAvMHg4ZDANClsgICAzNC43OTUzMzddICBbPGZmZmZmZmZmODE2ZDExMDY+XSB0Y3Bf
cmV0cmFuc21pdF9za2IrMHgxYzYvMHg1YTANClsgICAzNC43OTUzNDVdICBbPGZmZmZmZmZm
ODE2ZDE2N2U+XSB0Y3BfeG1pdF9yZXRyYW5zbWl0X3F1ZXVlKzB4MTllLzB4MzAwDQpbICAg
MzQuNzk1MzU0XSAgWzxmZmZmZmZmZjgxNmM5OWZmPl0gdGNwX2Zhc3RyZXRyYW5zX2FsZXJ0
KzB4OTRmLzB4Y2IwDQpbICAgMzQuNzk1MzYyXSAgWzxmZmZmZmZmZjgxNmNhNzBjPl0gdGNw
X2FjaysweDlhYy8weDExNTANClsgICAzNC43OTUzNjldICBbPGZmZmZmZmZmODE2Y2Q4NTg+
XSB0Y3BfcmN2X2VzdGFibGlzaGVkKzB4MzE4LzB4NjQwDQpbICAgMzQuNzk1Mzc3XSAgWzxm
ZmZmZmZmZjgxNmQ1ZWVmPl0gPyB0Y3BfdjRfcmN2KzB4NmNmLzB4YjEwDQpbICAgMzQuNzk1
Mzg0XSAgWzxmZmZmZmZmZjgxNmQ1NGQ1Pl0gdGNwX3Y0X2RvX3JjdisweDEzNS8weDQ4MA0K
WyAgIDM0Ljc5NTM5Ml0gIFs8ZmZmZmZmZmY4MTc0NjFkMj5dID8gX3Jhd19zcGluX2xvY2tf
bmVzdGVkKzB4NDIvMHg1MA0KWyAgIDM0Ljc5NTM5OV0gIFs8ZmZmZmZmZmY4MTZkNWVlZj5d
ID8gdGNwX3Y0X3JjdisweDZjZi8weGIxMA0KWyAgIDM0Ljc5NTQwNl0gIFs8ZmZmZmZmZmY4
MTZkNjE3ZD5dIHRjcF92NF9yY3YrMHg5NWQvMHhiMTANClsgICAzNC43OTU0MTNdICBbPGZm
ZmZmZmZmODEwYjBmODg+XSA/IGxvY2tfYWNxdWlyZSsweGQ4LzB4MTAwDQpbICAgMzQuNzk1
NDIwXSAgWzxmZmZmZmZmZjgxNmIyOTk1Pl0gPyBpcF9sb2NhbF9kZWxpdmVyX2ZpbmlzaCsw
eDQ1LzB4MjMwDQpbICAgMzQuNzk1NDI5XSAgWzxmZmZmZmZmZjgxNmIyYTZhPl0gaXBfbG9j
YWxfZGVsaXZlcl9maW5pc2grMHgxMWEvMHgyMzANClsgICAzNC43OTU0NDBdICBbPGZmZmZm
ZmZmODE2YjI5OTU+XSA/IGlwX2xvY2FsX2RlbGl2ZXJfZmluaXNoKzB4NDUvMHgyMzANClsg
ICAzNC43OTU0NTJdICBbPGZmZmZmZmZmODE2YjJiYjg+XSBpcF9sb2NhbF9kZWxpdmVyKzB4
MzgvMHg4MA0KWyAgIDM0Ljc5NTQ1OV0gIFs8ZmZmZmZmZmY4MTZiMjE3YT5dIGlwX3Jjdl9m
aW5pc2grMHgxNWEvMHg2MzANClsgICAzNC43OTU0NjZdICBbPGZmZmZmZmZmODE2YjI4Njg+
XSBpcF9yY3YrMHgyMTgvMHgzMDANClsgICAzNC43OTU0NzNdICBbPGZmZmZmZmZmODE2MWFj
OGQ+XSBfX25ldGlmX3JlY2VpdmVfc2tiKzB4NjVkLzB4OGQwDQpbICAgMzQuNzk1NDgyXSAg
WzxmZmZmZmZmZjgxNjFhNzc1Pl0gPyBfX25ldGlmX3JlY2VpdmVfc2tiKzB4MTQ1LzB4OGQw
DQpbICAgMzQuNzk1NDkwXSAgWzxmZmZmZmZmZjgxMGFkMjJkPl0gPyB0cmFjZV9oYXJkaXJx
c19vbisweGQvMHgxMA0KWyAgIDM0Ljc5NTQ5N10gIFs8ZmZmZmZmZmY4MTBmOTk3Mz5dID8g
ZnJlZV9ob3RfY29sZF9wYWdlKzB4MWIzLzB4MWUwDQpbICAgMzQuNzk1NTA1XSAgWzxmZmZm
ZmZmZjgxNjFkMWY4Pl0gbmV0aWZfcmVjZWl2ZV9za2IrMHgyOC8weGYwDQpbICAgMzQuNzk1
NTEzXSAgWzxmZmZmZmZmZjgxNjEyZDAzPl0gPyBfX3Bza2JfcHVsbF90YWlsKzB4MjUzLzB4
MzQwDQpbICAgMzQuNzk1NTIwXSAgWzxmZmZmZmZmZjgxNDZlNGM1Pl0geGVubmV0X3BvbGwr
MHhhZDUvMHhlMTANClsgICAzNC43OTU1MjldICBbPGZmZmZmZmZmODE2MWRmYTY+XSBuZXRf
cnhfYWN0aW9uKzB4MTM2LzB4MjYwDQpbICAgMzQuNzk1NTM2XSAgWzxmZmZmZmZmZjgxMDZl
MzgxPl0gPyBfX2RvX3NvZnRpcnErMHg3MS8weDFhMA0KWyAgIDM0Ljc5NTU0NF0gIFs8ZmZm
ZmZmZmY4MTA2ZTNkOT5dIF9fZG9fc29mdGlycSsweGM5LzB4MWEwDQpbICAgMzQuNzk1NTUx
XSAgWzxmZmZmZmZmZjgxNzQ4ZDNjPl0gY2FsbF9zb2Z0aXJxKzB4MWMvMHgzMA0KWyAgIDM0
Ljc5NTU1OF0gIFs8ZmZmZmZmZmY4MTAwZWRiNT5dIGRvX3NvZnRpcnErMHg4NS8weGYwDQpb
ICAgMzQuNzk1NTY1XSAgWzxmZmZmZmZmZjgxMDZlMjRlPl0gaXJxX2V4aXQrMHg5ZS8weGQw
DQpbICAgMzQuNzk1NTcyXSAgWzxmZmZmZmZmZjgxMzM5ZjVmPl0geGVuX2V2dGNobl9kb191
cGNhbGwrMHgyZi8weDQwDQpbICAgMzQuNzk1NTgwXSAgWzxmZmZmZmZmZjgxNzQ4ZDllPl0g
eGVuX2RvX2h5cGVydmlzb3JfY2FsbGJhY2srMHgxZS8weDMwDQpbICAgMzQuNzk1NTg2XSAg
PEVPST4gIFs8ZmZmZmZmZmY4MTAwMTNhYT5dID8geGVuX2h5cGVyY2FsbF9zY2hlZF9vcCsw
eGEvMHgyMA0KWyAgIDM0Ljc5NTU5OF0gIFs8ZmZmZmZmZmY4MTAwMTNhYT5dID8geGVuX2h5
cGVyY2FsbF9zY2hlZF9vcCsweGEvMHgyMA0KWyAgIDM0Ljc5NTYwNl0gIFs8ZmZmZmZmZmY4
MTAwODY5MD5dID8geGVuX3NhZmVfaGFsdCsweDEwLzB4MjANClsgICAzNC43OTU2MTNdICBb
PGZmZmZmZmZmODEwMTYwZDA+XSA/IGRlZmF1bHRfaWRsZSsweDQwLzB4OTANClsgICAzNC43
OTU2MjBdICBbPGZmZmZmZmZmODEwMTY0ODY+XSA/IGNwdV9pZGxlKzB4OTYvMHhmMA0KWyAg
IDM0Ljc5NTYyN10gIFs8ZmZmZmZmZmY4MTcyMmQzYz5dID8gcmVzdF9pbml0KzB4YmMvMHhk
MA0KWyAgIDM0Ljc5NTYzM10gIFs8ZmZmZmZmZmY4MTcyMmM4MD5dID8gY3N1bV9wYXJ0aWFs
X2NvcHlfZ2VuZXJpYysweDE3MC8weDE3MA0KWyAgIDM0Ljc5NTY0MV0gIFs8ZmZmZmZmZmY4
MWNlMGRmMj5dID8gc3RhcnRfa2VybmVsKzB4MzkwLzB4MzlkDQpbICAgMzQuNzk1NjQ5XSAg
WzxmZmZmZmZmZjgxY2UwODgyPl0gPyBrZXJuZWxfaW5pdCsweDIwYi8weDIwYg0KWyAgIDM0
Ljc5NTY1Nl0gIFs8ZmZmZmZmZmY4MWNlMDM1Nj5dID8geDg2XzY0X3N0YXJ0X3Jlc2VydmF0
aW9ucysweDEzMS8weDEzNg0KWyAgIDM0Ljc5NTY2NV0gIFs8ZmZmZmZmZmY4MWNlM2Q2MD5d
ID8geGVuX3N0YXJ0X2tlcm5lbCsweDcwZC8weDcwZg0KWyAgIDM0Ljc5NTY3Ml0gLS0tWyBl
bmQgdHJhY2UgMmUyOGVlYzkzYjdhOGI3OCBdLS0tDQpbICAgMzQuNzk3NDUwXSAtLS0tLS0t
LS0tLS1bIGN1dCBoZXJlIF0tLS0tLS0tLS0tLS0NClsgICAzNC43OTc0NjRdIFdBUk5JTkc6
IGF0IGRyaXZlcnMvbmV0L3hlbi1uZXRmcm9udC5jOjQ2NSB4ZW5uZXRfc3RhcnRfeG1pdCsw
eDdmZS8weDg2MCgpDQpbICAgMzQuNzk3NDc0XSBNb2R1bGVzIGxpbmtlZCBpbjoNClsgICAz
NC43OTc0ODJdIFBpZDogMTUzMiwgY29tbToga2xvZ2QgVGFpbnRlZDogRyAgICAgICAgVyAg
ICAzLjYuMHByZS1yYzEtMjAxMjEwMTEgIzENClsgICAzNC43OTc0ODldIENhbGwgVHJhY2U6
DQpbICAgMzQuNzk3NDkzXSAgPElSUT4gIFs8ZmZmZmZmZmY4MTA2NjRlYT5dIHdhcm5fc2xv
d3BhdGhfY29tbW9uKzB4N2EvMHhiMA0KWyAgIDM0Ljc5NzUwNl0gIFs8ZmZmZmZmZmY4MTA2
NjUzNT5dIHdhcm5fc2xvd3BhdGhfbnVsbCsweDE1LzB4MjANClsgICAzNC43OTc1MTNdICBb
PGZmZmZmZmZmODE0NmQ4OWU+XSB4ZW5uZXRfc3RhcnRfeG1pdCsweDdmZS8weDg2MA0KWyAg
IDM0Ljc5NzUyMl0gIFs8ZmZmZmZmZmY4MTYxZjM0OT5dIGRldl9oYXJkX3N0YXJ0X3htaXQr
MHgyMDkvMHg0NjANClsgICAzNC43OTc1MzBdICBbPGZmZmZmZmZmODE2M2IwMzY+XSBzY2hf
ZGlyZWN0X3htaXQrMHhmNi8weDI5MA0KWyAgIDM0Ljc5NzUzN10gIFs8ZmZmZmZmZmY4MTYx
Zjc0Nj5dIGRldl9xdWV1ZV94bWl0KzB4MWE2LzB4NWEwDQpbICAgMzQuNzk3NTQ1XSAgWzxm
ZmZmZmZmZjgxNjFmNWEwPl0gPyBkZXZfaGFyZF9zdGFydF94bWl0KzB4NDYwLzB4NDYwDQpb
ICAgMzQuNzk3NTU0XSAgWzxmZmZmZmZmZjgxMGIxNDE3Pl0gPyBsb2NrX3JlbGVhc2UrMHgx
MTcvMHgyNTANClsgICAzNC43OTc1NjJdICBbPGZmZmZmZmZmODE2Yjk1MzY+XSBpcF9maW5p
c2hfb3V0cHV0KzB4MjI2LzB4NTMwDQpbICAgMzQuNzk3NTcwXSAgWzxmZmZmZmZmZjgxNmI5
M2RkPl0gPyBpcF9maW5pc2hfb3V0cHV0KzB4Y2QvMHg1MzANClsgICAzNC43OTc1NzhdICBb
PGZmZmZmZmZmODE2Yjk4OTk+XSBpcF9vdXRwdXQrMHg1OS8weGUwDQpbICAgMzQuNzk3NTg3
XSAgWzxmZmZmZmZmZjgxNmI4M2I4Pl0gaXBfbG9jYWxfb3V0KzB4MjgvMHg5MA0KWyAgIDM0
Ljc5NzU5NF0gIFs8ZmZmZmZmZmY4MTZiODk2Zj5dIGlwX3F1ZXVlX3htaXQrMHgxN2YvMHg0
YTANClsgICAzNC43OTc2MDFdICBbPGZmZmZmZmZmODE2Yjg3ZjA+XSA/IGlwX3NlbmRfdW5p
Y2FzdF9yZXBseSsweDM0MC8weDM0MA0KWyAgIDM0Ljc5NzYwOV0gIFs8ZmZmZmZmZmY4MTBh
MGJhNz5dID8gZ2V0bnN0aW1lb2ZkYXkrMHg0Ny8weGUwDQpbICAgMzQuNzk3NjE3XSAgWzxm
ZmZmZmZmZjgxNjBmNGM5Pl0gPyBfX3NrYl9jbG9uZSsweDI5LzB4MTIwDQpbICAgMzQuNzk3
NjI0XSAgWzxmZmZmZmZmZjgxNmNlYTIwPl0gdGNwX3RyYW5zbWl0X3NrYisweDQwMC8weDhk
MA0KWyAgIDM0Ljc5NzYzMl0gIFs8ZmZmZmZmZmY4MTZkMTEwNj5dIHRjcF9yZXRyYW5zbWl0
X3NrYisweDFjNi8weDVhMA0KWyAgIDM0Ljc5NzY0MF0gIFs8ZmZmZmZmZmY4MTc0NmNiNT5d
ID8gX3Jhd19zcGluX3VubG9ja19pcnFyZXN0b3JlKzB4NzUvMHhhMA0KWyAgIDM0Ljc5NzY0
OF0gIFs8ZmZmZmZmZmY4MTZkMTY3ZT5dIHRjcF94bWl0X3JldHJhbnNtaXRfcXVldWUrMHgx
OWUvMHgzMDANClsgICAzNC43OTc2NTZdICBbPGZmZmZmZmZmODE2Yzk5ZmY+XSB0Y3BfZmFz
dHJldHJhbnNfYWxlcnQrMHg5NGYvMHhjYjANClsgICAzNC43OTc2NjNdICBbPGZmZmZmZmZm
ODE2Y2E3MGM+XSB0Y3BfYWNrKzB4OWFjLzB4MTE1MA0KWyAgIDM0Ljc5NzY3MV0gIFs8ZmZm
ZmZmZmY4MTZjZDhjZT5dIHRjcF9yY3ZfZXN0YWJsaXNoZWQrMHgzOGUvMHg2NDANClsgICAz
NC43OTc2NzhdICBbPGZmZmZmZmZmODE2ZDVlZWY+XSA/IHRjcF92NF9yY3YrMHg2Y2YvMHhi
MTANClsgICAzNC43OTc2ODZdICBbPGZmZmZmZmZmODE2ZDU0ZDU+XSB0Y3BfdjRfZG9fcmN2
KzB4MTM1LzB4NDgwDQpbICAgMzQuNzk3NjkzXSAgWzxmZmZmZmZmZjgxNzQ2MWQyPl0gPyBf
cmF3X3NwaW5fbG9ja19uZXN0ZWQrMHg0Mi8weDUwDQpbICAgMzQuNzk3NzAxXSAgWzxmZmZm
ZmZmZjgxNmQ1ZWVmPl0gPyB0Y3BfdjRfcmN2KzB4NmNmLzB4YjEwDQpbICAgMzQuNzk3NzA4
XSAgWzxmZmZmZmZmZjgxNmQ2MTdkPl0gdGNwX3Y0X3JjdisweDk1ZC8weGIxMA0KWyAgIDM0
Ljc5NzcxNV0gIFs8ZmZmZmZmZmY4MTBiMGY4OD5dID8gbG9ja19hY3F1aXJlKzB4ZDgvMHgx
MDANClsgICAzNC43OTc3MjNdICBbPGZmZmZmZmZmODE2YjI5OTU+XSA/IGlwX2xvY2FsX2Rl
bGl2ZXJfZmluaXNoKzB4NDUvMHgyMzANClsgICAzNC43OTc3MzFdICBbPGZmZmZmZmZmODE2
YjJhNmE+XSBpcF9sb2NhbF9kZWxpdmVyX2ZpbmlzaCsweDExYS8weDIzMA0KWyAgIDM0Ljc5
Nzc0M10gIFs8ZmZmZmZmZmY4MTZiMjk5NT5dID8gaXBfbG9jYWxfZGVsaXZlcl9maW5pc2gr
MHg0NS8weDIzMA0KWyAgIDM0Ljc5Nzc1MV0gIFs8ZmZmZmZmZmY4MTZiMmJiOD5dIGlwX2xv
Y2FsX2RlbGl2ZXIrMHgzOC8weDgwDQpbICAgMzQuNzk3NzU5XSAgWzxmZmZmZmZmZjgxNmIy
MTdhPl0gaXBfcmN2X2ZpbmlzaCsweDE1YS8weDYzMA0KWyAgIDM0Ljc5Nzc2Nl0gIFs8ZmZm
ZmZmZmY4MTZiMjg2OD5dIGlwX3JjdisweDIxOC8weDMwMA0KWyAgIDM0Ljc5Nzc3M10gIFs8
ZmZmZmZmZmY4MTYxYWM4ZD5dIF9fbmV0aWZfcmVjZWl2ZV9za2IrMHg2NWQvMHg4ZDANClsg
ICAzNC43OTc3ODBdICBbPGZmZmZmZmZmODE2MWE3NzU+XSA/IF9fbmV0aWZfcmVjZWl2ZV9z
a2IrMHgxNDUvMHg4ZDANClsgICAzNC43OTc3ODhdICBbPGZmZmZmZmZmODEwYWQyMmQ+XSA/
IHRyYWNlX2hhcmRpcnFzX29uKzB4ZC8weDEwDQpbICAgMzQuNzk3Nzk2XSAgWzxmZmZmZmZm
ZjgxMGY5OTczPl0gPyBmcmVlX2hvdF9jb2xkX3BhZ2UrMHgxYjMvMHgxZTANClsgICAzNC43
OTc4MDRdICBbPGZmZmZmZmZmODE2MWQxZjg+XSBuZXRpZl9yZWNlaXZlX3NrYisweDI4LzB4
ZjANClsgICAzNC43OTc4MTFdICBbPGZmZmZmZmZmODE2MTJkMDM+XSA/IF9fcHNrYl9wdWxs
X3RhaWwrMHgyNTMvMHgzNDANClsgICAzNC43OTc4MTldICBbPGZmZmZmZmZmODE0NmU0YzU+
XSB4ZW5uZXRfcG9sbCsweGFkNS8weGUxMA0KWyAgIDM0Ljc5NzgyN10gIFs8ZmZmZmZmZmY4
MTYxZGZhNj5dIG5ldF9yeF9hY3Rpb24rMHgxMzYvMHgyNjANClsgICAzNC43OTc4MzVdICBb
PGZmZmZmZmZmODEwNmUzODE+XSA/IF9fZG9fc29mdGlycSsweDcxLzB4MWEwDQpbICAgMzQu
Nzk3ODQyXSAgWzxmZmZmZmZmZjgxMDZlM2Q5Pl0gX19kb19zb2Z0aXJxKzB4YzkvMHgxYTAN
ClsgICAzNC43OTc4NDldICBbPGZmZmZmZmZmODE3NDhkM2M+XSBjYWxsX3NvZnRpcnErMHgx
Yy8weDMwDQpbICAgMzQuNzk3ODU2XSAgWzxmZmZmZmZmZjgxMDBlZGI1Pl0gZG9fc29mdGly
cSsweDg1LzB4ZjANClsgICAzNC43OTc4NjNdICBbPGZmZmZmZmZmODEwNmUyNGU+XSBpcnFf
ZXhpdCsweDllLzB4ZDANClsgICAzNC43OTc4NzFdICBbPGZmZmZmZmZmODEzMzlmNWY+XSB4
ZW5fZXZ0Y2huX2RvX3VwY2FsbCsweDJmLzB4NDANClsgICAzNC43OTc4NzldICBbPGZmZmZm
ZmZmODE3NDhkOWU+XSB4ZW5fZG9faHlwZXJ2aXNvcl9jYWxsYmFjaysweDFlLzB4MzANClsg
ICAzNC43OTc4ODVdICA8RU9JPiANClsgICAzNC43OTc4ODldIC0tLVsgZW5kIHRyYWNlIDJl
MjhlZWM5M2I3YThiNzkgXS0tLQ0KWyAgIDM0Ljc5NzkxN10gLS0tLS0tLS0tLS0tWyBjdXQg
aGVyZSBdLS0tLS0tLS0tLS0tDQpbICAgMzQuNzk3OTI1XSBXQVJOSU5HOiBhdCBkcml2ZXJz
L25ldC94ZW4tbmV0ZnJvbnQuYzo0NjUgeGVubmV0X3N0YXJ0X3htaXQrMHg3ZmUvMHg4NjAo
KQ0KWyAgIDM0Ljc5NzkzMl0gTW9kdWxlcyBsaW5rZWQgaW46DQpbICAgMzQuNzk3OTM5XSBQ
aWQ6IDE1MzIsIGNvbW06IGtsb2dkIFRhaW50ZWQ6IEcgICAgICAgIFcgICAgMy42LjBwcmUt
cmMxLTIwMTIxMDExICMxDQpbICAgMzQuNzk3OTQ3XSBDYWxsIFRyYWNlOg0KWyAgIDM0Ljc5
Nzk1MF0gIDxJUlE+ICBbPGZmZmZmZmZmODEwNjY0ZWE+XSB3YXJuX3Nsb3dwYXRoX2NvbW1v
bisweDdhLzB4YjANClsgICAzNC43OTc5NjJdICBbPGZmZmZmZmZmODEwNjY1MzU+XSB3YXJu
X3Nsb3dwYXRoX251bGwrMHgxNS8weDIwDQpbICAgMzQuNzk3OTcwXSAgWzxmZmZmZmZmZjgx
NDZkODllPl0geGVubmV0X3N0YXJ0X3htaXQrMHg3ZmUvMHg4NjANClsgICAzNC43OTc5Nzhd
ICBbPGZmZmZmZmZmODE2MWYzNDk+XSBkZXZfaGFyZF9zdGFydF94bWl0KzB4MjA5LzB4NDYw
DQpbICAgMzQuNzk3OTg2XSAgWzxmZmZmZmZmZjgxNjNiMDM2Pl0gc2NoX2RpcmVjdF94bWl0
KzB4ZjYvMHgyOTANClsgICAzNC43OTc5OTRdICBbPGZmZmZmZmZmODE2MWY3NDY+XSBkZXZf
cXVldWVfeG1pdCsweDFhNi8weDVhMA0KWyAgIDM0Ljc5ODAwMV0gIFs8ZmZmZmZmZmY4MTYx
ZjVhMD5dID8gZGV2X2hhcmRfc3RhcnRfeG1pdCsweDQ2MC8weDQ2MA0KWyAgIDM0Ljc5ODAx
Ml0gIFs8ZmZmZmZmZmY4MTBiMTQxNz5dID8gbG9ja19yZWxlYXNlKzB4MTE3LzB4MjUwDQpb
ICAgMzQuNzk4MDE5XSAgWzxmZmZmZmZmZjgxNmI5NTM2Pl0gaXBfZmluaXNoX291dHB1dCsw
eDIyNi8weDUzMA0KWyAgIDM0Ljc5ODAyN10gIFs8ZmZmZmZmZmY4MTZiOTNkZD5dID8gaXBf
ZmluaXNoX291dHB1dCsweGNkLzB4NTMwDQpbICAgMzQuNzk4MDM1XSAgWzxmZmZmZmZmZjgx
NmI5ODk5Pl0gaXBfb3V0cHV0KzB4NTkvMHhlMA0KWyAgIDM0Ljc5ODA0M10gIFs8ZmZmZmZm
ZmY4MTZiODNiOD5dIGlwX2xvY2FsX291dCsweDI4LzB4OTANClsgICAzNC43OTgwNTBdICBb
PGZmZmZmZmZmODE2Yjg5NmY+XSBpcF9xdWV1ZV94bWl0KzB4MTdmLzB4NGEwDQpbICAgMzQu
Nzk4MDU3XSAgWzxmZmZmZmZmZjgxNmI4N2YwPl0gPyBpcF9zZW5kX3VuaWNhc3RfcmVwbHkr
MHgzNDAvMHgzNDANClsgICAzNC43OTgwNjVdICBbPGZmZmZmZmZmODEwYTBiYTc+XSA/IGdl
dG5zdGltZW9mZGF5KzB4NDcvMHhlMA0KWyAgIDM0Ljc5ODA3Ml0gIFs8ZmZmZmZmZmY4MTYw
ZjRjOT5dID8gX19za2JfY2xvbmUrMHgyOS8weDEyMA0KWyAgIDM0Ljc5ODA4MF0gIFs8ZmZm
ZmZmZmY4MTZjZWEyMD5dIHRjcF90cmFuc21pdF9za2IrMHg0MDAvMHg4ZDANClsgICAzNC43
OTgwODddICBbPGZmZmZmZmZmODE2ZDExMDY+XSB0Y3BfcmV0cmFuc21pdF9za2IrMHgxYzYv
MHg1YTANClsgICAzNC43OTgwOTVdICBbPGZmZmZmZmZmODE3NDZjYjU+XSA/IF9yYXdfc3Bp
bl91bmxvY2tfaXJxcmVzdG9yZSsweDc1LzB4YTANClsgICAzNC43OTgxMDNdICBbPGZmZmZm
ZmZmODE2ZDE2N2U+XSB0Y3BfeG1pdF9yZXRyYW5zbWl0X3F1ZXVlKzB4MTllLzB4MzAwDQpb
ICAgMzQuNzk4MTExXSAgWzxmZmZmZmZmZjgxNmM5OWZmPl0gdGNwX2Zhc3RyZXRyYW5zX2Fs
ZXJ0KzB4OTRmLzB4Y2IwDQpbICAgMzQuNzk4MTE5XSAgWzxmZmZmZmZmZjgxNmNhNzBjPl0g
dGNwX2FjaysweDlhYy8weDExNTANClsgICAzNC43OTgxMjZdICBbPGZmZmZmZmZmODE2Y2Q4
Y2U+XSB0Y3BfcmN2X2VzdGFibGlzaGVkKzB4MzhlLzB4NjQwDQpbICAgMzQuNzk4MTM0XSAg
WzxmZmZmZmZmZjgxNmQ1ZWVmPl0gPyB0Y3BfdjRfcmN2KzB4NmNmLzB4YjEwDQpbICAgMzQu
Nzk4MTQxXSAgWzxmZmZmZmZmZjgxNmQ1NGQ1Pl0gdGNwX3Y0X2RvX3JjdisweDEzNS8weDQ4
MA0KWyAgIDM0Ljc5ODE0OV0gIFs8ZmZmZmZmZmY4MTc0NjFkMj5dID8gX3Jhd19zcGluX2xv
Y2tfbmVzdGVkKzB4NDIvMHg1MA0KWyAgIDM0Ljc5ODE1Nl0gIFs8ZmZmZmZmZmY4MTZkNWVl
Zj5dID8gdGNwX3Y0X3JjdisweDZjZi8weGIxMA0KWyAgIDM0Ljc5ODE2NF0gIFs8ZmZmZmZm
ZmY4MTZkNjE3ZD5dIHRjcF92NF9yY3YrMHg5NWQvMHhiMTANClsgICAzNC43OTgxNzFdICBb
PGZmZmZmZmZmODEwYjBmODg+XSA/IGxvY2tfYWNxdWlyZSsweGQ4LzB4MTAwDQpbICAgMzQu
Nzk4MTc4XSAgWzxmZmZmZmZmZjgxNmIyOTk1Pl0gPyBpcF9sb2NhbF9kZWxpdmVyX2Zpbmlz
aCsweDQ1LzB4MjMwDQpbICAgMzQuNzk4MTg2XSAgWzxmZmZmZmZmZjgxNmIyYTZhPl0gaXBf
bG9jYWxfZGVsaXZlcl9maW5pc2grMHgxMWEvMHgyMzANClsgICAzNC43OTgxOTRdICBbPGZm
ZmZmZmZmODE2YjI5OTU+XSA/IGlwX2xvY2FsX2RlbGl2ZXJfZmluaXNoKzB4NDUvMHgyMzAN
ClsgICAzNC43OTgyMDJdICBbPGZmZmZmZmZmODE2YjJiYjg+XSBpcF9sb2NhbF9kZWxpdmVy
KzB4MzgvMHg4MA0KWyAgIDM0Ljc5ODIxMF0gIFs8ZmZmZmZmZmY4MTZiMjE3YT5dIGlwX3Jj
dl9maW5pc2grMHgxNWEvMHg2MzANClsgICAzNC43OTgyMjBdICBbPGZmZmZmZmZmODE2YjI4
Njg+XSBpcF9yY3YrMHgyMTgvMHgzMDANClsgICAzNC43OTgyMjddICBbPGZmZmZmZmZmODE2
MWFjOGQ+XSBfX25ldGlmX3JlY2VpdmVfc2tiKzB4NjVkLzB4OGQwDQpbICAgMzQuNzk4MjM0
XSAgWzxmZmZmZmZmZjgxNjFhNzc1Pl0gPyBfX25ldGlmX3JlY2VpdmVfc2tiKzB4MTQ1LzB4
OGQwDQpbICAgMzQuNzk4MjQyXSAgWzxmZmZmZmZmZjgxMGFkMjJkPl0gPyB0cmFjZV9oYXJk
aXJxc19vbisweGQvMHgxMA0KWyAgIDM0Ljc5ODI0OV0gIFs8ZmZmZmZmZmY4MTBmOTk3Mz5d
ID8gZnJlZV9ob3RfY29sZF9wYWdlKzB4MWIzLzB4MWUwDQpbICAgMzQuNzk4MjU3XSAgWzxm
ZmZmZmZmZjgxNjFkMWY4Pl0gbmV0aWZfcmVjZWl2ZV9za2IrMHgyOC8weGYwDQpbICAgMzQu
Nzk4MjY1XSAgWzxmZmZmZmZmZjgxNjEyZDAzPl0gPyBfX3Bza2JfcHVsbF90YWlsKzB4MjUz
LzB4MzQwDQpbICAgMzQuNzk4Mjc2XSAgWzxmZmZmZmZmZjgxNDZlNGM1Pl0geGVubmV0X3Bv
bGwrMHhhZDUvMHhlMTANClsgICAzNC43OTgyODVdICBbPGZmZmZmZmZmODE2MWRmYTY+XSBu
ZXRfcnhfYWN0aW9uKzB4MTM2LzB4MjYwDQpbICAgMzQuNzk4MjkyXSAgWzxmZmZmZmZmZjgx
MDZlMzgxPl0gPyBfX2RvX3NvZnRpcnErMHg3MS8weDFhMA0KWyAgIDM0Ljc5ODMwMF0gIFs8
ZmZmZmZmZmY4MTA2ZTNkOT5dIF9fZG9fc29mdGlycSsweGM5LzB4MWEwDQpbICAgMzQuNzk4
MzA3XSAgWzxmZmZmZmZmZjgxNzQ4ZDNjPl0gY2FsbF9zb2Z0aXJxKzB4MWMvMHgzMA0KWyAg
IDM0Ljc5ODMxNF0gIFs8ZmZmZmZmZmY4MTAwZWRiNT5dIGRvX3NvZnRpcnErMHg4NS8weGYw
DQpbICAgMzQuNzk4MzIxXSAgWzxmZmZmZmZmZjgxMDZlMjRlPl0gaXJxX2V4aXQrMHg5ZS8w
eGQwDQpbICAgMzQuNzk4MzI4XSAgWzxmZmZmZmZmZjgxMzM5ZjVmPl0geGVuX2V2dGNobl9k
b191cGNhbGwrMHgyZi8weDQwDQpbICAgMzQuNzk4MzM1XSAgWzxmZmZmZmZmZjgxNzQ4ZDll
Pl0geGVuX2RvX2h5cGVydmlzb3JfY2FsbGJhY2srMHgxZS8weDMwDQpbICAgMzQuNzk4MzQy
XSAgPEVPST4gDQpbICAgMzQuNzk4MzQ1XSAtLS1bIGVuZCB0cmFjZSAyZTI4ZWVjOTNiN2E4
YjdhIF0tLS0NClsgICAzNC43OTgzNjhdIC0tLS0tLS0tLS0tLVsgY3V0IGhlcmUgXS0tLS0t
LS0tLS0tLQ0KWyAgIDM0Ljc5ODM3NV0gV0FSTklORzogYXQgZHJpdmVycy9uZXQveGVuLW5l
dGZyb250LmM6NDY1IHhlbm5ldF9zdGFydF94bWl0KzB4N2ZlLzB4ODYwKCkNClsgICAzNC43
OTgzODNdIE1vZHVsZXMgbGlua2VkIGluOg0KWyAgIDM0Ljc5ODM4OF0gUGlkOiAxNTMyLCBj
b21tOiBrbG9nZCBUYWludGVkOiBHICAgICAgICBXICAgIDMuNi4wcHJlLXJjMS0yMDEyMTAx
MSAjMQ0KWyAgIDM0Ljc5ODM5Nl0gQ2FsbCBUcmFjZToNClsgICAzNC43OTg0MDBdICA8SVJR
PiAgWzxmZmZmZmZmZjgxMDY2NGVhPl0gd2Fybl9zbG93cGF0aF9jb21tb24rMHg3YS8weGIw
DQpbICAgMzQuNzk4NDExXSAgWzxmZmZmZmZmZjgxMDY2NTM1Pl0gd2Fybl9zbG93cGF0aF9u
dWxsKzB4MTUvMHgyMA0KWyAgIDM0Ljc5ODQxOF0gIFs8ZmZmZmZmZmY4MTQ2ZDg5ZT5dIHhl
bm5ldF9zdGFydF94bWl0KzB4N2ZlLzB4ODYwDQpbICAgMzQuNzk4NDI2XSAgWzxmZmZmZmZm
ZjgxNjFmMzQ5Pl0gZGV2X2hhcmRfc3RhcnRfeG1pdCsweDIwOS8weDQ2MA0KWyAgIDM0Ljc5
ODQzNF0gIFs8ZmZmZmZmZmY4MTYzYjAzNj5dIHNjaF9kaXJlY3RfeG1pdCsweGY2LzB4Mjkw
DQpbICAgMzQuNzk4NDQyXSAgWzxmZmZmZmZmZjgxNjFmNzQ2Pl0gZGV2X3F1ZXVlX3htaXQr
MHgxYTYvMHg1YTANClsgICAzNC43OTg0NDldICBbPGZmZmZmZmZmODE2MWY1YTA+XSA/IGRl
dl9oYXJkX3N0YXJ0X3htaXQrMHg0NjAvMHg0NjANClsgICAzNC43OTg0NTddICBbPGZmZmZm
ZmZmODEwYjE0MTc+XSA/IGxvY2tfcmVsZWFzZSsweDExNy8weDI1MA0KWyAgIDM0Ljc5ODQ2
NV0gIFs8ZmZmZmZmZmY4MTZiOTUzNj5dIGlwX2ZpbmlzaF9vdXRwdXQrMHgyMjYvMHg1MzAN
ClsgICAzNC43OTg0NzJdICBbPGZmZmZmZmZmODE2YjkzZGQ+XSA/IGlwX2ZpbmlzaF9vdXRw
dXQrMHhjZC8weDUzMA0KWyAgIDM0Ljc5ODQ4MF0gIFs8ZmZmZmZmZmY4MTZiOTg5OT5dIGlw
X291dHB1dCsweDU5LzB4ZTANClsgICAzNC43OTg0ODddICBbPGZmZmZmZmZmODE2YjgzYjg+
XSBpcF9sb2NhbF9vdXQrMHgyOC8weDkwDQpbICAgMzQuNzk4NDk0XSAgWzxmZmZmZmZmZjgx
NmI4OTZmPl0gaXBfcXVldWVfeG1pdCsweDE3Zi8weDRhMA0KWyAgIDM0Ljc5ODUwMl0gIFs8
ZmZmZmZmZmY4MTZiODdmMD5dID8gaXBfc2VuZF91bmljYXN0X3JlcGx5KzB4MzQwLzB4MzQw
DQpbICAgMzQuNzk4NTEwXSAgWzxmZmZmZmZmZjgxMGEwYmE3Pl0gPyBnZXRuc3RpbWVvZmRh
eSsweDQ3LzB4ZTANClsgICAzNC43OTg1MThdICBbPGZmZmZmZmZmODE2MGY0Yzk+XSA/IF9f
c2tiX2Nsb25lKzB4MjkvMHgxMjANClsgICAzNC43OTg1MjZdICBbPGZmZmZmZmZmODE2Y2Vh
MjA+XSB0Y3BfdHJhbnNtaXRfc2tiKzB4NDAwLzB4OGQwDQpbICAgMzQuNzk4NTM0XSAgWzxm
ZmZmZmZmZjgxNmQxMTA2Pl0gdGNwX3JldHJhbnNtaXRfc2tiKzB4MWM2LzB4NWEwDQpbICAg
MzQuNzk4NTQxXSAgWzxmZmZmZmZmZjgxNzQ2Y2I1Pl0gPyBfcmF3X3NwaW5fdW5sb2NrX2ly
cXJlc3RvcmUrMHg3NS8weGEwDQpbICAgMzQuNzk4NTUwXSAgWzxmZmZmZmZmZjgxNmQxNjdl
Pl0gdGNwX3htaXRfcmV0cmFuc21pdF9xdWV1ZSsweDE5ZS8weDMwMA0KWyAgIDM0Ljc5ODU1
OF0gIFs8ZmZmZmZmZmY4MTZjOTlmZj5dIHRjcF9mYXN0cmV0cmFuc19hbGVydCsweDk0Zi8w
eGNiMA0KWyAgIDM0Ljc5ODU2NV0gIFs8ZmZmZmZmZmY4MTZjYTcwYz5dIHRjcF9hY2srMHg5
YWMvMHgxMTUwDQpbICAgMzQuNzk4NTczXSAgWzxmZmZmZmZmZjgxNmNkOGNlPl0gdGNwX3Jj
dl9lc3RhYmxpc2hlZCsweDM4ZS8weDY0MA0KWyAgIDM0Ljc5ODU4MF0gIFs8ZmZmZmZmZmY4
MTZkNWVlZj5dID8gdGNwX3Y0X3JjdisweDZjZi8weGIxMA0KWyAgIDM0Ljc5ODU4OF0gIFs8
ZmZmZmZmZmY4MTZkNTRkNT5dIHRjcF92NF9kb19yY3YrMHgxMzUvMHg0ODANClsgICAzNC43
OTg1OTVdICBbPGZmZmZmZmZmODE3NDYxZDI+XSA/IF9yYXdfc3Bpbl9sb2NrX25lc3RlZCsw
eDQyLzB4NTANClsgICAzNC43OTg2MDNdICBbPGZmZmZmZmZmODE2ZDVlZWY+XSA/IHRjcF92
NF9yY3YrMHg2Y2YvMHhiMTANClsgICAzNC43OTg2MTBdICBbPGZmZmZmZmZmODE2ZDYxN2Q+
XSB0Y3BfdjRfcmN2KzB4OTVkLzB4YjEwDQpbICAgMzQuNzk4NjE3XSAgWzxmZmZmZmZmZjgx
MGIwZjg4Pl0gPyBsb2NrX2FjcXVpcmUrMHhkOC8weDEwMA0KWyAgIDM0Ljc5ODYyNF0gIFs8
ZmZmZmZmZmY4MTZiMjk5NT5dID8gaXBfbG9jYWxfZGVsaXZlcl9maW5pc2grMHg0NS8weDIz
MA0KWyAgIDM0Ljc5ODYzM10gIFs8ZmZmZmZmZmY4MTZiMmE2YT5dIGlwX2xvY2FsX2RlbGl2
ZXJfZmluaXNoKzB4MTFhLzB4MjMwDQpbICAgMzQuNzk4NjQwXSAgWzxmZmZmZmZmZjgxNmIy
OTk1Pl0gPyBpcF9sb2NhbF9kZWxpdmVyX2ZpbmlzaCsweDQ1LzB4MjMwDQpbICAgMzQuNzk4
NjQ4XSAgWzxmZmZmZmZmZjgxNmIyYmI4Pl0gaXBfbG9jYWxfZGVsaXZlcisweDM4LzB4ODAN
ClsgICAzNC43OTg2NTZdICBbPGZmZmZmZmZmODE2YjIxN2E+XSBpcF9yY3ZfZmluaXNoKzB4
MTVhLzB4NjMwDQpbICAgMzQuNzk4NjYzXSAgWzxmZmZmZmZmZjgxNmIyODY4Pl0gaXBfcmN2
KzB4MjE4LzB4MzAwDQpbICAgMzQuNzk4NjcwXSAgWzxmZmZmZmZmZjgxNjFhYzhkPl0gX19u
ZXRpZl9yZWNlaXZlX3NrYisweDY1ZC8weDhkMA0KWyAgIDM0Ljc5ODY3OF0gIFs8ZmZmZmZm
ZmY4MTYxYTc3NT5dID8gX19uZXRpZl9yZWNlaXZlX3NrYisweDE0NS8weDhkMA0KWyAgIDM0
Ljc5ODY4NV0gIFs8ZmZmZmZmZmY4MTBhZDIyZD5dID8gdHJhY2VfaGFyZGlycXNfb24rMHhk
LzB4MTANClsgICAzNC43OTg2OTNdICBbPGZmZmZmZmZmODEwZjk5NzM+XSA/IGZyZWVfaG90
X2NvbGRfcGFnZSsweDFiMy8weDFlMA0KWyAgIDM0Ljc5ODcwMV0gIFs8ZmZmZmZmZmY4MTYx
ZDFmOD5dIG5ldGlmX3JlY2VpdmVfc2tiKzB4MjgvMHhmMA0KWyAgIDM0Ljc5ODcwOF0gIFs8
ZmZmZmZmZmY4MTYxMmQwMz5dID8gX19wc2tiX3B1bGxfdGFpbCsweDI1My8weDM0MA0KWyAg
IDM0Ljc5ODcxNl0gIFs8ZmZmZmZmZmY4MTQ2ZTRjNT5dIHhlbm5ldF9wb2xsKzB4YWQ1LzB4
ZTEwDQpbICAgMzQuNzk4NzI1XSAgWzxmZmZmZmZmZjgxNjFkZmE2Pl0gbmV0X3J4X2FjdGlv
bisweDEzNi8weDI2MA0KWyAgIDM0Ljc5ODczMl0gIFs8ZmZmZmZmZmY4MTA2ZTM4MT5dID8g
X19kb19zb2Z0aXJxKzB4NzEvMHgxYTANClsgICAzNC43OTg3MzldICBbPGZmZmZmZmZmODEw
NmUzZDk+XSBfX2RvX3NvZnRpcnErMHhjOS8weDFhMA0KWyAgIDM0Ljc5ODc0N10gIFs8ZmZm
ZmZmZmY4MTc0OGQzYz5dIGNhbGxfc29mdGlycSsweDFjLzB4MzANClsgICAzNC43OTg3NTRd
ICBbPGZmZmZmZmZmODEwMGVkYjU+XSBkb19zb2Z0aXJxKzB4ODUvMHhmMA0KWyAgIDM0Ljc5
ODc2MV0gIFs8ZmZmZmZmZmY4MTA2ZTI0ZT5dIGlycV9leGl0KzB4OWUvMHhkMA0KWyAgIDM0
Ljc5ODc2OF0gIFs8ZmZmZmZmZmY4MTMzOWY1Zj5dIHhlbl9ldnRjaG5fZG9fdXBjYWxsKzB4
MmYvMHg0MA0KWyAgIDM0Ljc5ODc3Nl0gIFs8ZmZmZmZmZmY4MTc0OGQ5ZT5dIHhlbl9kb19o
eXBlcnZpc29yX2NhbGxiYWNrKzB4MWUvMHgzMA0KWyAgIDM0Ljc5ODc4Ml0gIDxFT0k+IA0K
WyAgIDM0Ljc5ODc4Nl0gLS0tWyBlbmQgdHJhY2UgMmUyOGVlYzkzYjdhOGI3YiBdLS0tDQpb
ICAgMzUuMzYzNDQ0XSAtLS0tLS0tLS0tLS1bIGN1dCBoZXJlIF0tLS0tLS0tLS0tLS0NClsg
ICAzNS4zNjM0NjFdIFdBUk5JTkc6IGF0IGRyaXZlcnMvbmV0L3hlbi1uZXRmcm9udC5jOjQ2
NSB4ZW5uZXRfc3RhcnRfeG1pdCsweDdmZS8weDg2MCgpDQpbICAgMzUuMzYzNDY4XSBNb2R1
bGVzIGxpbmtlZCBpbjoNClsgICAzNS4zNjM0NzRdIFBpZDogMCwgY29tbTogc3dhcHBlci8w
IFRhaW50ZWQ6IEcgICAgICAgIFcgICAgMy42LjBwcmUtcmMxLTIwMTIxMDExICMxDQpbICAg
MzUuMzYzNDgwXSBDYWxsIFRyYWNlOg0KWyAgIDM1LjM2MzQ4M10gIDxJUlE+ICBbPGZmZmZm
ZmZmODEwNjY0ZWE+XSB3YXJuX3Nsb3dwYXRoX2NvbW1vbisweDdhLzB4YjANClsgICAzNS4z
NjM0OTVdICBbPGZmZmZmZmZmODEwNjY1MzU+XSB3YXJuX3Nsb3dwYXRoX251bGwrMHgxNS8w
eDIwDQpbICAgMzUuMzYzNTAwXSAgWzxmZmZmZmZmZjgxNDZkODllPl0geGVubmV0X3N0YXJ0
X3htaXQrMHg3ZmUvMHg4NjANClsgICAzNS4zNjM1MDldICBbPGZmZmZmZmZmODE2MWYzNDk+
XSBkZXZfaGFyZF9zdGFydF94bWl0KzB4MjA5LzB4NDYwDQpbICAgMzUuMzYzNTE1XSAgWzxm
ZmZmZmZmZjgxNjNiMDM2Pl0gc2NoX2RpcmVjdF94bWl0KzB4ZjYvMHgyOTANClsgICAzNS4z
NjM1MjJdICBbPGZmZmZmZmZmODE2MWY3NDY+XSBkZXZfcXVldWVfeG1pdCsweDFhNi8weDVh
MA0KWyAgIDM1LjM2MzUyOF0gIFs8ZmZmZmZmZmY4MTYxZjVhMD5dID8gZGV2X2hhcmRfc3Rh
cnRfeG1pdCsweDQ2MC8weDQ2MA0KWyAgIDM1LjM2MzUzNV0gIFs8ZmZmZmZmZmY4MTBiMTQx
Nz5dID8gbG9ja19yZWxlYXNlKzB4MTE3LzB4MjUwDQpbICAgMzUuMzYzNTQyXSAgWzxmZmZm
ZmZmZjgxNmI5NTM2Pl0gaXBfZmluaXNoX291dHB1dCsweDIyNi8weDUzMA0KWyAgIDM1LjM2
MzU0OF0gIFs8ZmZmZmZmZmY4MTZiOTNkZD5dID8gaXBfZmluaXNoX291dHB1dCsweGNkLzB4
NTMwDQpbICAgMzUuMzYzNTU1XSAgWzxmZmZmZmZmZjgxNmI5ODk5Pl0gaXBfb3V0cHV0KzB4
NTkvMHhlMA0KWyAgIDM1LjM2MzU2MF0gIFs8ZmZmZmZmZmY4MTZiODNiOD5dIGlwX2xvY2Fs
X291dCsweDI4LzB4OTANClsgICAzNS4zNjM1NjZdICBbPGZmZmZmZmZmODE2Yjg5NmY+XSBp
cF9xdWV1ZV94bWl0KzB4MTdmLzB4NGEwDQpbICAgMzUuMzYzNTcxXSAgWzxmZmZmZmZmZjgx
NmI4N2YwPl0gPyBpcF9zZW5kX3VuaWNhc3RfcmVwbHkrMHgzNDAvMHgzNDANClsgICAzNS4z
NjM1NzhdICBbPGZmZmZmZmZmODEwYTBiYTc+XSA/IGdldG5zdGltZW9mZGF5KzB4NDcvMHhl
MA0KWyAgIDM1LjM2MzU4NV0gIFs8ZmZmZmZmZmY4MTYwZjRjOT5dID8gX19za2JfY2xvbmUr
MHgyOS8weDEyMA0KWyAgIDM1LjM2MzU5MV0gIFs8ZmZmZmZmZmY4MTZjZWEyMD5dIHRjcF90
cmFuc21pdF9za2IrMHg0MDAvMHg4ZDANClsgICAzNS4zNjM1OTddICBbPGZmZmZmZmZmODE2
ZDExMDY+XSB0Y3BfcmV0cmFuc21pdF9za2IrMHgxYzYvMHg1YTANClsgICAzNS4zNjM2MDNd
ICBbPGZmZmZmZmZmODE2ZDMzYjA+XSA/IHRjcF93cml0ZV90aW1lcl9oYW5kbGVyKzB4MWEw
LzB4MWEwDQpbICAgMzUuMzYzNjA5XSAgWzxmZmZmZmZmZjgxNmQyZjM4Pl0gdGNwX3JldHJh
bnNtaXRfdGltZXIrMHgzNTgvMHg2MzANClsgICAzNS4zNjM2MTVdICBbPGZmZmZmZmZmODE2
ZDMzNGQ+XSB0Y3Bfd3JpdGVfdGltZXJfaGFuZGxlcisweDEzZC8weDFhMA0KWyAgIDM1LjM2
MzYyMF0gIFs8ZmZmZmZmZmY4MTZkMzQyOD5dIHRjcF93cml0ZV90aW1lcisweDc4LzB4ODAN
ClsgICAzNS4zNjM2MjZdICBbPGZmZmZmZmZmODEwNzNmN2M+XSBjYWxsX3RpbWVyX2ZuKzB4
N2MvMHgxMDANClsgICAzNS4zNjM2MzJdICBbPGZmZmZmZmZmODEwNzNmMDA+XSA/IGNhc2Nh
ZGUrMHhhMC8weGEwDQpbICAgMzUuMzYzNjM3XSAgWzxmZmZmZmZmZjgxNmQzM2IwPl0gPyB0
Y3Bfd3JpdGVfdGltZXJfaGFuZGxlcisweDFhMC8weDFhMA0KWyAgIDM1LjM2MzY0M10gIFs8
ZmZmZmZmZmY4MTZkMzNiMD5dID8gdGNwX3dyaXRlX3RpbWVyX2hhbmRsZXIrMHgxYTAvMHgx
YTANClsgICAzNS4zNjM2NDldICBbPGZmZmZmZmZmODEwNzQyMTc+XSBydW5fdGltZXJfc29m
dGlycSsweDIxNy8weDI1MA0KWyAgIDM1LjM2MzY1Nl0gIFs8ZmZmZmZmZmY4MTA2ZTNkOT5d
IF9fZG9fc29mdGlycSsweGM5LzB4MWEwDQpbICAgMzUuMzYzNjYyXSAgWzxmZmZmZmZmZjgx
NzQ4ZDNjPl0gY2FsbF9zb2Z0aXJxKzB4MWMvMHgzMA0KWyAgIDM1LjM2MzY2OF0gIFs8ZmZm
ZmZmZmY4MTAwZWRiNT5dIGRvX3NvZnRpcnErMHg4NS8weGYwDQpbICAgMzUuMzYzNjczXSAg
WzxmZmZmZmZmZjgxMDZlMjRlPl0gaXJxX2V4aXQrMHg5ZS8weGQwDQpbICAgMzUuMzYzNjgw
XSAgWzxmZmZmZmZmZjgxMzM5ZjVmPl0geGVuX2V2dGNobl9kb191cGNhbGwrMHgyZi8weDQw
DQpbICAgMzUuMzYzNjg2XSAgWzxmZmZmZmZmZjgxNzQ4ZDllPl0geGVuX2RvX2h5cGVydmlz
b3JfY2FsbGJhY2srMHgxZS8weDMwDQpbICAgMzUuMzYzNjkxXSAgPEVPST4gIFs8ZmZmZmZm
ZmY4MTAwMTNhYT5dID8geGVuX2h5cGVyY2FsbF9zY2hlZF9vcCsweGEvMHgyMA0KWyAgIDM1
LjM2MzcwMV0gIFs8ZmZmZmZmZmY4MTAwMTNhYT5dID8geGVuX2h5cGVyY2FsbF9zY2hlZF9v
cCsweGEvMHgyMA0KWyAgIDM1LjM2MzcwN10gIFs8ZmZmZmZmZmY4MTAwODY5MD5dID8geGVu
X3NhZmVfaGFsdCsweDEwLzB4MjANClsgICAzNS4zNjM3MTNdICBbPGZmZmZmZmZmODEwMTYw
ZDA+XSA/IGRlZmF1bHRfaWRsZSsweDQwLzB4OTANClsgICAzNS4zNjM3MTldICBbPGZmZmZm
ZmZmODEwMTY0ODY+XSA/IGNwdV9pZGxlKzB4OTYvMHhmMA0KWyAgIDM1LjM2MzcyNF0gIFs8
ZmZmZmZmZmY4MTcyMmQzYz5dID8gcmVzdF9pbml0KzB4YmMvMHhkMA0KWyAgIDM1LjM2Mzcy
OV0gIFs8ZmZmZmZmZmY4MTcyMmM4MD5dID8gY3N1bV9wYXJ0aWFsX2NvcHlfZ2VuZXJpYysw
eDE3MC8weDE3MA0KWyAgIDM1LjM2MzczN10gIFs8ZmZmZmZmZmY4MWNlMGRmMj5dID8gc3Rh
cnRfa2VybmVsKzB4MzkwLzB4MzlkDQpbICAgMzUuMzYzNzQzXSAgWzxmZmZmZmZmZjgxY2Uw
ODgyPl0gPyBrZXJuZWxfaW5pdCsweDIwYi8weDIwYg0KWyAgIDM1LjM2Mzc0OV0gIFs8ZmZm
ZmZmZmY4MWNlMDM1Nj5dID8geDg2XzY0X3N0YXJ0X3Jlc2VydmF0aW9ucysweDEzMS8weDEz
Ng0KWyAgIDM1LjM2Mzc1OV0gIFs8ZmZmZmZmZmY4MWNlM2Q2MD5dID8geGVuX3N0YXJ0X2tl
cm5lbCsweDcwZC8weDcwZg0KWyAgIDM1LjM2Mzc2NF0gLS0tWyBlbmQgdHJhY2UgMmUyOGVl
YzkzYjdhOGI3YyBdLS0tDQpbICAgMzYuNTAwMjIxXSAtLS0tLS0tLS0tLS1bIGN1dCBoZXJl
IF0tLS0tLS0tLS0tLS0NClsgICAzNi41MDAyNjddIFdBUk5JTkc6IGF0IGRyaXZlcnMvbmV0
L3hlbi1uZXRmcm9udC5jOjQ2NSB4ZW5uZXRfc3RhcnRfeG1pdCsweDdmZS8weDg2MCgpDQpb
ICAgMzYuNTAwMjkzXSBNb2R1bGVzIGxpbmtlZCBpbjoNClsgICAzNi41MDAzMTVdIFBpZDog
MCwgY29tbTogc3dhcHBlci8wIFRhaW50ZWQ6IEcgICAgICAgIFcgICAgMy42LjBwcmUtcmMx
LTIwMTIxMDExICMxDQpbICAgMzYuNTAwMzM5XSBDYWxsIFRyYWNlOg0KWyAgIDM2LjUwMDM1
MV0gIDxJUlE+ICBbPGZmZmZmZmZmODEwNjY0ZWE+XSB3YXJuX3Nsb3dwYXRoX2NvbW1vbisw
eDdhLzB4YjANClsgICAzNi41MDAzOTZdICBbPGZmZmZmZmZmODEwNjY1MzU+XSB3YXJuX3Ns
b3dwYXRoX251bGwrMHgxNS8weDIwDQpbICAgMzYuNTAwNDIwXSAgWzxmZmZmZmZmZjgxNDZk
ODllPl0geGVubmV0X3N0YXJ0X3htaXQrMHg3ZmUvMHg4NjANClsgICAzNi41MDA0NDddICBb
PGZmZmZmZmZmODE2MWYzNDk+XSBkZXZfaGFyZF9zdGFydF94bWl0KzB4MjA5LzB4NDYwDQpb
ICAgMzYuNTAwNDcxXSAgWzxmZmZmZmZmZjgxNjNiMDM2Pl0gc2NoX2RpcmVjdF94bWl0KzB4
ZjYvMHgyOTANClsgICAzNi41MDA0OTRdICBbPGZmZmZmZmZmODE2MWY3NDY+XSBkZXZfcXVl
dWVfeG1pdCsweDFhNi8weDVhMA0KWyAgIDM2LjUwMDUxNl0gIFs8ZmZmZmZmZmY4MTYxZjVh
MD5dID8gZGV2X2hhcmRfc3RhcnRfeG1pdCsweDQ2MC8weDQ2MA0KWyAgIDM2LjUwMDU0MV0g
IFs8ZmZmZmZmZmY4MTBiMTQxNz5dID8gbG9ja19yZWxlYXNlKzB4MTE3LzB4MjUwDQpbICAg
MzYuNTAwNTcwXSAgWzxmZmZmZmZmZjgxNmI5NTM2Pl0gaXBfZmluaXNoX291dHB1dCsweDIy
Ni8weDUzMA0KWyAgIDM2LjUwMDU5NF0gIFs8ZmZmZmZmZmY4MTZiOTNkZD5dID8gaXBfZmlu
aXNoX291dHB1dCsweGNkLzB4NTMwDQpbICAgMzYuNTAwNjE5XSAgWzxmZmZmZmZmZjgxNmI5
ODk5Pl0gaXBfb3V0cHV0KzB4NTkvMHhlMA0KWyAgIDM2LjUwMDY0MV0gIFs8ZmZmZmZmZmY4
MTZiODNiOD5dIGlwX2xvY2FsX291dCsweDI4LzB4OTANClsgICAzNi41MDA2NjJdICBbPGZm
ZmZmZmZmODE2Yjg5NmY+XSBpcF9xdWV1ZV94bWl0KzB4MTdmLzB4NGEwDQpbICAgMzYuNTAw
Njg0XSAgWzxmZmZmZmZmZjgxNmI4N2YwPl0gPyBpcF9zZW5kX3VuaWNhc3RfcmVwbHkrMHgz
NDAvMHgzNDANClsgICAzNi41MDA3MDldICBbPGZmZmZmZmZmODEwYTBiYTc+XSA/IGdldG5z
dGltZW9mZGF5KzB4NDcvMHhlMA0KWyAgIDM2LjUwMDczMl0gIFs8ZmZmZmZmZmY4MTYwZjRj
OT5dID8gX19za2JfY2xvbmUrMHgyOS8weDEyMA0KWyAgIDM2LjUwMDc1NV0gIFs8ZmZmZmZm
ZmY4MTZjZWEyMD5dIHRjcF90cmFuc21pdF9za2IrMHg0MDAvMHg4ZDANClsgICAzNi41MDA3
NzldICBbPGZmZmZmZmZmODE2ZDExMDY+XSB0Y3BfcmV0cmFuc21pdF9za2IrMHgxYzYvMHg1
YTANClsgICAzNi41MDA4MDNdICBbPGZmZmZmZmZmODE2ZDMzYjA+XSA/IHRjcF93cml0ZV90
aW1lcl9oYW5kbGVyKzB4MWEwLzB4MWEwDQpbICAgMzYuNTAwODI3XSAgWzxmZmZmZmZmZjgx
NmQyZjM4Pl0gdGNwX3JldHJhbnNtaXRfdGltZXIrMHgzNTgvMHg2MzANClsgICAzNi41MDA4
NTBdICBbPGZmZmZmZmZmODE2ZDMzNGQ+XSB0Y3Bfd3JpdGVfdGltZXJfaGFuZGxlcisweDEz
ZC8weDFhMA0KWyAgIDM2LjUwMDg3NF0gIFs8ZmZmZmZmZmY4MTZkMzQyOD5dIHRjcF93cml0
ZV90aW1lcisweDc4LzB4ODANClsgICAzNi41MDA4OTddICBbPGZmZmZmZmZmODEwNzNmN2M+
XSBjYWxsX3RpbWVyX2ZuKzB4N2MvMHgxMDANClsgICAzNi41MDA5MTddICBbPGZmZmZmZmZm
ODEwNzNmMDA+XSA/IGNhc2NhZGUrMHhhMC8weGEwDQpbICAgMzYuNTAwOTM4XSAgWzxmZmZm
ZmZmZjgxNmQzM2IwPl0gPyB0Y3Bfd3JpdGVfdGltZXJfaGFuZGxlcisweDFhMC8weDFhMA0K
WyAgIDM2LjUwMDk2Ml0gIFs8ZmZmZmZmZmY4MTZkMzNiMD5dID8gdGNwX3dyaXRlX3RpbWVy
X2hhbmRsZXIrMHgxYTAvMHgxYTANClsgICAzNi41MDA5ODVdICBbPGZmZmZmZmZmODEwNzQy
MTc+XSBydW5fdGltZXJfc29mdGlycSsweDIxNy8weDI1MA0KWyAgIDM2LjUwMTAxMV0gIFs8
ZmZmZmZmZmY4MTA2ZTNkOT5dIF9fZG9fc29mdGlycSsweGM5LzB4MWEwDQpbICAgMzYuNTAx
MDM0XSAgWzxmZmZmZmZmZjgxNzQ4ZDNjPl0gY2FsbF9zb2Z0aXJxKzB4MWMvMHgzMA0KWyAg
IDM2LjUwMTA1NV0gIFs8ZmZmZmZmZmY4MTAwZWRiNT5dIGRvX3NvZnRpcnErMHg4NS8weGYw
DQpbICAgMzYuNTAxMDc3XSAgWzxmZmZmZmZmZjgxMDZlMjRlPl0gaXJxX2V4aXQrMHg5ZS8w
eGQwDQpbICAgMzYuNTAxMTAxXSAgWzxmZmZmZmZmZjgxMzM5ZjVmPl0geGVuX2V2dGNobl9k
b191cGNhbGwrMHgyZi8weDQwDQpbICAgMzYuNTAxMTI0XSAgWzxmZmZmZmZmZjgxNzQ4ZDll
Pl0geGVuX2RvX2h5cGVydmlzb3JfY2FsbGJhY2srMHgxZS8weDMwDQpbICAgMzYuNTAxMTQz
XSAgPEVPST4gIFs8ZmZmZmZmZmY4MTAwMTNhYT5dID8geGVuX2h5cGVyY2FsbF9zY2hlZF9v
cCsweGEvMHgyMA0KWyAgIDM2LjUwMTE4MV0gIFs8ZmZmZmZmZmY4MTAwMTNhYT5dID8geGVu
X2h5cGVyY2FsbF9zY2hlZF9vcCsweGEvMHgyMA0KWyAgIDM2LjUwMTIwNV0gIFs8ZmZmZmZm
ZmY4MTAwODY5MD5dID8geGVuX3NhZmVfaGFsdCsweDEwLzB4MjANClsgICAzNi41MDEyMjhd
ICBbPGZmZmZmZmZmODEwMTYwZDA+XSA/IGRlZmF1bHRfaWRsZSsweDQwLzB4OTANClsgICAz
Ni41MDEyNDldICBbPGZmZmZmZmZmODEwMTY0ODY+XSA/IGNwdV9pZGxlKzB4OTYvMHhmMA0K
WyAgIDM2LjUwMTI3MF0gIFs8ZmZmZmZmZmY4MTcyMmQzYz5dID8gcmVzdF9pbml0KzB4YmMv
MHhkMA0KWyAgIDM2LjUwMTI5MF0gIFs8ZmZmZmZmZmY4MTcyMmM4MD5dID8gY3N1bV9wYXJ0
aWFsX2NvcHlfZ2VuZXJpYysweDE3MC8weDE3MA0KWyAgIDM2LjUwMTMxOF0gIFs8ZmZmZmZm
ZmY4MWNlMGRmMj5dID8gc3RhcnRfa2VybmVsKzB4MzkwLzB4MzlkDQpbICAgMzYuNTAxMzQx
XSAgWzxmZmZmZmZmZjgxY2UwODgyPl0gPyBrZXJuZWxfaW5pdCsweDIwYi8weDIwYg0KWyAg
IDM2LjUwMTM2NF0gIFs8ZmZmZmZmZmY4MWNlMDM1Nj5dID8geDg2XzY0X3N0YXJ0X3Jlc2Vy
dmF0aW9ucysweDEzMS8weDEzNg0KWyAgIDM2LjUwMTM4OF0gIFs8ZmZmZmZmZmY4MWNlM2Q2
MD5dID8geGVuX3N0YXJ0X2tlcm5lbCsweDcwZC8weDcwZg0KWyAgIDM2LjUwMTQwOV0gLS0t
WyBlbmQgdHJhY2UgMmUyOGVlYzkzYjdhOGI3ZCBdLS0tDQpbICAgMzguNzczNTEwXSAtLS0t
LS0tLS0tLS1bIGN1dCBoZXJlIF0tLS0tLS0tLS0tLS0NClsgICAzOC43NzM1MjhdIFdBUk5J
Tkc6IGF0IGRyaXZlcnMvbmV0L3hlbi1uZXRmcm9udC5jOjQ2NSB4ZW5uZXRfc3RhcnRfeG1p
dCsweDdmZS8weDg2MCgpDQpbICAgMzguNzczNTM1XSBNb2R1bGVzIGxpbmtlZCBpbjoNClsg
ICAzOC43NzM1NDJdIFBpZDogMCwgY29tbTogc3dhcHBlci8wIFRhaW50ZWQ6IEcgICAgICAg
IFcgICAgMy42LjBwcmUtcmMxLTIwMTIxMDExICMxDQpbICAgMzguNzczNTQ4XSBDYWxsIFRy
YWNlOg0KWyAgIDM4Ljc3MzU1Ml0gIDxJUlE+ICBbPGZmZmZmZmZmODEwNjY0ZWE+XSB3YXJu
X3Nsb3dwYXRoX2NvbW1vbisweDdhLzB4YjANClsgICAzOC43NzM1NjRdICBbPGZmZmZmZmZm
ODEwNjY1MzU+XSB3YXJuX3Nsb3dwYXRoX251bGwrMHgxNS8weDIwDQpbICAgMzguNzczNTcw
XSAgWzxmZmZmZmZmZjgxNDZkODllPl0geGVubmV0X3N0YXJ0X3htaXQrMHg3ZmUvMHg4NjAN
ClsgICAzOC43NzM1ODJdICBbPGZmZmZmZmZmODE2MWYzNDk+XSBkZXZfaGFyZF9zdGFydF94
bWl0KzB4MjA5LzB4NDYwDQpbICAgMzguNzczNTg5XSAgWzxmZmZmZmZmZjgxNjNiMDM2Pl0g
c2NoX2RpcmVjdF94bWl0KzB4ZjYvMHgyOTANClsgICAzOC43NzM1OTRdICBbPGZmZmZmZmZm
ODE2MWY3NDY+XSBkZXZfcXVldWVfeG1pdCsweDFhNi8weDVhMA0KWyAgIDM4Ljc3MzYwMF0g
IFs8ZmZmZmZmZmY4MTYxZjVhMD5dID8gZGV2X2hhcmRfc3RhcnRfeG1pdCsweDQ2MC8weDQ2
MA0KWyAgIDM4Ljc3MzYwN10gIFs8ZmZmZmZmZmY4MTBiMTQxNz5dID8gbG9ja19yZWxlYXNl
KzB4MTE3LzB4MjUwDQpbICAgMzguNzczNjEzXSAgWzxmZmZmZmZmZjgxNmI5NTM2Pl0gaXBf
ZmluaXNoX291dHB1dCsweDIyNi8weDUzMA0KWyAgIDM4Ljc3MzYxOV0gIFs8ZmZmZmZmZmY4
MTZiOTNkZD5dID8gaXBfZmluaXNoX291dHB1dCsweGNkLzB4NTMwDQpbICAgMzguNzczNjI1
XSAgWzxmZmZmZmZmZjgxNmI5ODk5Pl0gaXBfb3V0cHV0KzB4NTkvMHhlMA0KWyAgIDM4Ljc3
MzYzMV0gIFs8ZmZmZmZmZmY4MTZiODNiOD5dIGlwX2xvY2FsX291dCsweDI4LzB4OTANClsg
ICAzOC43NzM2MzZdICBbPGZmZmZmZmZmODE2Yjg5NmY+XSBpcF9xdWV1ZV94bWl0KzB4MTdm
LzB4NGEwDQpbICAgMzguNzczNjQzXSAgWzxmZmZmZmZmZjgxNmI4N2YwPl0gPyBpcF9zZW5k
X3VuaWNhc3RfcmVwbHkrMHgzNDAvMHgzNDANClsgICAzOC43NzM2NDldICBbPGZmZmZmZmZm
ODEwYTBiYTc+XSA/IGdldG5zdGltZW9mZGF5KzB4NDcvMHhlMA0KWyAgIDM4Ljc3MzY1Nl0g
IFs8ZmZmZmZmZmY4MTYwZjRjOT5dID8gX19za2JfY2xvbmUrMHgyOS8weDEyMA0KWyAgIDM4
Ljc3MzY2Ml0gIFs8ZmZmZmZmZmY4MTZjZWEyMD5dIHRjcF90cmFuc21pdF9za2IrMHg0MDAv
MHg4ZDANClsgICAzOC43NzM2NjhdICBbPGZmZmZmZmZmODE2ZDExMDY+XSB0Y3BfcmV0cmFu
c21pdF9za2IrMHgxYzYvMHg1YTANClsgICAzOC43NzM2NzRdICBbPGZmZmZmZmZmODE2ZDMz
YjA+XSA/IHRjcF93cml0ZV90aW1lcl9oYW5kbGVyKzB4MWEwLzB4MWEwDQpbICAgMzguNzcz
NjgwXSAgWzxmZmZmZmZmZjgxNmQyZjM4Pl0gdGNwX3JldHJhbnNtaXRfdGltZXIrMHgzNTgv
MHg2MzANClsgICAzOC43NzM2ODVdICBbPGZmZmZmZmZmODE2ZDMzNGQ+XSB0Y3Bfd3JpdGVf
dGltZXJfaGFuZGxlcisweDEzZC8weDFhMA0KWyAgIDM4Ljc3MzY5MV0gIFs8ZmZmZmZmZmY4
MTZkMzQyOD5dIHRjcF93cml0ZV90aW1lcisweDc4LzB4ODANClsgICAzOC43NzM2OTddICBb
PGZmZmZmZmZmODEwNzNmN2M+XSBjYWxsX3RpbWVyX2ZuKzB4N2MvMHgxMDANClsgICAzOC43
NzM3MDJdICBbPGZmZmZmZmZmODEwNzNmMDA+XSA/IGNhc2NhZGUrMHhhMC8weGEwDQpbICAg
MzguNzczNzA3XSAgWzxmZmZmZmZmZjgxNmQzM2IwPl0gPyB0Y3Bfd3JpdGVfdGltZXJfaGFu
ZGxlcisweDFhMC8weDFhMA0KWyAgIDM4Ljc3MzcxM10gIFs8ZmZmZmZmZmY4MTZkMzNiMD5d
ID8gdGNwX3dyaXRlX3RpbWVyX2hhbmRsZXIrMHgxYTAvMHgxYTANClsgICAzOC43NzM3MTld
ICBbPGZmZmZmZmZmODEwNzQyMTc+XSBydW5fdGltZXJfc29mdGlycSsweDIxNy8weDI1MA0K
WyAgIDM4Ljc3MzcyNl0gIFs8ZmZmZmZmZmY4MTA2ZTNkOT5dIF9fZG9fc29mdGlycSsweGM5
LzB4MWEwDQpbICAgMzguNzczNzMyXSAgWzxmZmZmZmZmZjgxNzQ4ZDNjPl0gY2FsbF9zb2Z0
aXJxKzB4MWMvMHgzMA0KWyAgIDM4Ljc3MzczOF0gIFs8ZmZmZmZmZmY4MTAwZWRiNT5dIGRv
X3NvZnRpcnErMHg4NS8weGYwDQpbICAgMzguNzczNzQzXSAgWzxmZmZmZmZmZjgxMDZlMjRl
Pl0gaXJxX2V4aXQrMHg5ZS8weGQwDQpbICAgMzguNzczNzUxXSAgWzxmZmZmZmZmZjgxMzM5
ZjVmPl0geGVuX2V2dGNobl9kb191cGNhbGwrMHgyZi8weDQwDQpbICAgMzguNzczNzU2XSAg
WzxmZmZmZmZmZjgxNzQ4ZDllPl0geGVuX2RvX2h5cGVydmlzb3JfY2FsbGJhY2srMHgxZS8w
eDMwDQpbICAgMzguNzczNzYxXSAgPEVPST4gIFs8ZmZmZmZmZmY4MTAwMTNhYT5dID8geGVu
X2h5cGVyY2FsbF9zY2hlZF9vcCsweGEvMHgyMA0KWyAgIDM4Ljc3Mzc3MV0gIFs8ZmZmZmZm
ZmY4MTAwMTNhYT5dID8geGVuX2h5cGVyY2FsbF9zY2hlZF9vcCsweGEvMHgyMA0KWyAgIDM4
Ljc3Mzc3OF0gIFs8ZmZmZmZmZmY4MTAwODY5MD5dID8geGVuX3NhZmVfaGFsdCsweDEwLzB4
MjANClsgICAzOC43NzM3ODRdICBbPGZmZmZmZmZmODEwMTYwZDA+XSA/IGRlZmF1bHRfaWRs
ZSsweDQwLzB4OTANClsgICAzOC43NzM3ODldICBbPGZmZmZmZmZmODEwMTY0ODY+XSA/IGNw
dV9pZGxlKzB4OTYvMHhmMA0KWyAgIDM4Ljc3Mzc5NF0gIFs8ZmZmZmZmZmY4MTcyMmQzYz5d
ID8gcmVzdF9pbml0KzB4YmMvMHhkMA0KWyAgIDM4Ljc3MzgwMF0gIFs8ZmZmZmZmZmY4MTcy
MmM4MD5dID8gY3N1bV9wYXJ0aWFsX2NvcHlfZ2VuZXJpYysweDE3MC8weDE3MA0KWyAgIDM4
Ljc3MzgwN10gIFs8ZmZmZmZmZmY4MWNlMGRmMj5dID8gc3RhcnRfa2VybmVsKzB4MzkwLzB4
MzlkDQpbICAgMzguNzczODEzXSAgWzxmZmZmZmZmZjgxY2UwODgyPl0gPyBrZXJuZWxfaW5p
dCsweDIwYi8weDIwYg0KWyAgIDM4Ljc3MzgxOV0gIFs8ZmZmZmZmZmY4MWNlMDM1Nj5dID8g
eDg2XzY0X3N0YXJ0X3Jlc2VydmF0aW9ucysweDEzMS8weDEzNg0KWyAgIDM4Ljc3MzgyNV0g
IFs8ZmZmZmZmZmY4MWNlM2Q2MD5dID8geGVuX3N0YXJ0X2tlcm5lbCsweDcwZC8weDcwZg0K
WyAgIDM4Ljc3MzgzMV0gLS0tWyBlbmQgdHJhY2UgMmUyOGVlYzkzYjdhOGI3ZSBdLS0tDQpb
ICAgNDMuMzIwMjA3XSAtLS0tLS0tLS0tLS1bIGN1dCBoZXJlIF0tLS0tLS0tLS0tLS0NClsg
ICA0My4zMjAyMzVdIFdBUk5JTkc6IGF0IGRyaXZlcnMvbmV0L3hlbi1uZXRmcm9udC5jOjQ2
NSB4ZW5uZXRfc3RhcnRfeG1pdCsweDdmZS8weDg2MCgpDQpbICAgNDMuMzIwMjQ0XSBNb2R1
bGVzIGxpbmtlZCBpbjoNClsgICA0My4zMjAyNTJdIFBpZDogMCwgY29tbTogc3dhcHBlci8w
IFRhaW50ZWQ6IEcgICAgICAgIFcgICAgMy42LjBwcmUtcmMxLTIwMTIxMDExICMxDQpbICAg
NDMuMzIwMjYxXSBDYWxsIFRyYWNlOg0KWyAgIDQzLjMyMDI2NV0gIDxJUlE+ICBbPGZmZmZm
ZmZmODEwNjY0ZWE+XSB3YXJuX3Nsb3dwYXRoX2NvbW1vbisweDdhLzB4YjANClsgICA0My4z
MjAyODBdICBbPGZmZmZmZmZmODEwNjY1MzU+XSB3YXJuX3Nsb3dwYXRoX251bGwrMHgxNS8w
eDIwDQpbICAgNDMuMzIwMjg4XSAgWzxmZmZmZmZmZjgxNDZkODllPl0geGVubmV0X3N0YXJ0
X3htaXQrMHg3ZmUvMHg4NjANClsgICA0My4zMjAyOThdICBbPGZmZmZmZmZmODE2MWYzNDk+
XSBkZXZfaGFyZF9zdGFydF94bWl0KzB4MjA5LzB4NDYwDQpbICAgNDMuMzIwMzA3XSAgWzxm
ZmZmZmZmZjgxNjNiMDM2Pl0gc2NoX2RpcmVjdF94bWl0KzB4ZjYvMHgyOTANClsgICA0My4z
MjAzMTVdICBbPGZmZmZmZmZmODE2MWY3NDY+XSBkZXZfcXVldWVfeG1pdCsweDFhNi8weDVh
MA0KWyAgIDQzLjMyMDMyM10gIFs8ZmZmZmZmZmY4MTYxZjVhMD5dID8gZGV2X2hhcmRfc3Rh
cnRfeG1pdCsweDQ2MC8weDQ2MA0KWyAgIDQzLjMyMDMzN10gIFs8ZmZmZmZmZmY4MTBiMTQx
Nz5dID8gbG9ja19yZWxlYXNlKzB4MTE3LzB4MjUwDQpbICAgNDMuMzIwMzQ2XSAgWzxmZmZm
ZmZmZjgxNmI5NTM2Pl0gaXBfZmluaXNoX291dHB1dCsweDIyNi8weDUzMA0KWyAgIDQzLjMy
MDM1NF0gIFs8ZmZmZmZmZmY4MTZiOTNkZD5dID8gaXBfZmluaXNoX291dHB1dCsweGNkLzB4
NTMwDQpbICAgNDMuMzIwMzYyXSAgWzxmZmZmZmZmZjgxNmI5ODk5Pl0gaXBfb3V0cHV0KzB4
NTkvMHhlMA0KWyAgIDQzLjMyMDM3MF0gIFs8ZmZmZmZmZmY4MTZiODNiOD5dIGlwX2xvY2Fs
X291dCsweDI4LzB4OTANClsgICA0My4zMjAzNzddICBbPGZmZmZmZmZmODE2Yjg5NmY+XSBp
cF9xdWV1ZV94bWl0KzB4MTdmLzB4NGEwDQpbICAgNDMuMzIwMzg1XSAgWzxmZmZmZmZmZjgx
NmI4N2YwPl0gPyBpcF9zZW5kX3VuaWNhc3RfcmVwbHkrMHgzNDAvMHgzNDANClsgICA0My4z
MjAzOTNdICBbPGZmZmZmZmZmODEwYTBiYTc+XSA/IGdldG5zdGltZW9mZGF5KzB4NDcvMHhl
MA0KWyAgIDQzLjMyMDQwMl0gIFs8ZmZmZmZmZmY4MTYwZjRjOT5dID8gX19za2JfY2xvbmUr
MHgyOS8weDEyMA0KWyAgIDQzLjMyMDQwOV0gIFs8ZmZmZmZmZmY4MTZjZWEyMD5dIHRjcF90
cmFuc21pdF9za2IrMHg0MDAvMHg4ZDANClsgICA0My4zMjA0MTddICBbPGZmZmZmZmZmODE2
ZDExMDY+XSB0Y3BfcmV0cmFuc21pdF9za2IrMHgxYzYvMHg1YTANClsgICA0My4zMjA0MjVd
ICBbPGZmZmZmZmZmODE2ZDMzYjA+XSA/IHRjcF93cml0ZV90aW1lcl9oYW5kbGVyKzB4MWEw
LzB4MWEwDQpbICAgNDMuMzIwNDMzXSAgWzxmZmZmZmZmZjgxNmQyZjM4Pl0gdGNwX3JldHJh
bnNtaXRfdGltZXIrMHgzNTgvMHg2MzANClsgICA0My4zMjA0NDFdICBbPGZmZmZmZmZmODE2
ZDMzNGQ+XSB0Y3Bfd3JpdGVfdGltZXJfaGFuZGxlcisweDEzZC8weDFhMA0KWyAgIDQzLjMy
MDQ0OV0gIFs8ZmZmZmZmZmY4MTZkMzQyOD5dIHRjcF93cml0ZV90aW1lcisweDc4LzB4ODAN
ClsgICA0My4zMjA0NTZdICBbPGZmZmZmZmZmODEwNzNmN2M+XSBjYWxsX3RpbWVyX2ZuKzB4
N2MvMHgxMDANClsgICA0My4zMjA0NjNdICBbPGZmZmZmZmZmODEwNzNmMDA+XSA/IGNhc2Nh
ZGUrMHhhMC8weGEwDQpbICAgNDMuMzIwNDcwXSAgWzxmZmZmZmZmZjgxNmQzM2IwPl0gPyB0
Y3Bfd3JpdGVfdGltZXJfaGFuZGxlcisweDFhMC8weDFhMA0KWyAgIDQzLjMyMDQ3OV0gIFs8
ZmZmZmZmZmY4MTZkMzNiMD5dID8gdGNwX3dyaXRlX3RpbWVyX2hhbmRsZXIrMHgxYTAvMHgx
YTANClsgICA0My4zMjA0ODddICBbPGZmZmZmZmZmODEwNzQyMTc+XSBydW5fdGltZXJfc29m
dGlycSsweDIxNy8weDI1MA0KWyAgIDQzLjMyMDQ5Nl0gIFs8ZmZmZmZmZmY4MTA2ZTNkOT5d
IF9fZG9fc29mdGlycSsweGM5LzB4MWEwDQpbICAgNDMuMzIwNTAzXSAgWzxmZmZmZmZmZjgx
NzQ4ZDNjPl0gY2FsbF9zb2Z0aXJxKzB4MWMvMHgzMA0KWyAgIDQzLjMyMDUxMV0gIFs8ZmZm
ZmZmZmY4MTAwZWRiNT5dIGRvX3NvZnRpcnErMHg4NS8weGYwDQpbICAgNDMuMzIwNTE4XSAg
WzxmZmZmZmZmZjgxMDZlMjRlPl0gaXJxX2V4aXQrMHg5ZS8weGQwDQpbICAgNDMuMzIwNTI4
XSAgWzxmZmZmZmZmZjgxMzM5ZjVmPl0geGVuX2V2dGNobl9kb191cGNhbGwrMHgyZi8weDQw
DQpbICAgNDMuMzIwNTM1XSAgWzxmZmZmZmZmZjgxNzQ4ZDllPl0geGVuX2RvX2h5cGVydmlz
b3JfY2FsbGJhY2srMHgxZS8weDMwDQpbICAgNDMuMzIwNTQyXSAgPEVPST4gIFs8ZmZmZmZm
ZmY4MTAwMTNhYT5dID8geGVuX2h5cGVyY2FsbF9zY2hlZF9vcCsweGEvMHgyMA0KWyAgIDQz
LjMyMDU1NV0gIFs8ZmZmZmZmZmY4MTAwMTNhYT5dID8geGVuX2h5cGVyY2FsbF9zY2hlZF9v
cCsweGEvMHgyMA0KWyAgIDQzLjMyMDU2NF0gIFs8ZmZmZmZmZmY4MTAwODY5MD5dID8geGVu
X3NhZmVfaGFsdCsweDEwLzB4MjANClsgICA0My4zMjA1NzFdICBbPGZmZmZmZmZmODEwMTYw
ZDA+XSA/IGRlZmF1bHRfaWRsZSsweDQwLzB4OTANClsgICA0My4zMjA1NzhdICBbPGZmZmZm
ZmZmODEwMTY0ODY+XSA/IGNwdV9pZGxlKzB4OTYvMHhmMA0KWyAgIDQzLjMyMDU4Nl0gIFs8
ZmZmZmZmZmY4MTcyMmQzYz5dID8gcmVzdF9pbml0KzB4YmMvMHhkMA0KWyAgIDQzLjMyMDU5
Ml0gIFs8ZmZmZmZmZmY4MTcyMmM4MD5dID8gY3N1bV9wYXJ0aWFsX2NvcHlfZ2VuZXJpYysw
eDE3MC8weDE3MA0KWyAgIDQzLjMyMDYwMl0gIFs8ZmZmZmZmZmY4MWNlMGRmMj5dID8gc3Rh
cnRfa2VybmVsKzB4MzkwLzB4MzlkDQpbICAgNDMuMzIwNjEwXSAgWzxmZmZmZmZmZjgxY2Uw
ODgyPl0gPyBrZXJuZWxfaW5pdCsweDIwYi8weDIwYg0KWyAgIDQzLjMyMDYxN10gIFs8ZmZm
ZmZmZmY4MWNlMDM1Nj5dID8geDg2XzY0X3N0YXJ0X3Jlc2VydmF0aW9ucysweDEzMS8weDEz
Ng0KWyAgIDQzLjMyMDYyNl0gIFs8ZmZmZmZmZmY4MWNlM2Q2MD5dID8geGVuX3N0YXJ0X2tl
cm5lbCsweDcwZC8weDcwZg0KWyAgIDQzLjMyMDYzM10gLS0tWyBlbmQgdHJhY2UgMmUyOGVl
YzkzYjdhOGI3ZiBdLS0tDQpbICAgNTIuNDAwMTI2XSAtLS0tLS0tLS0tLS1bIGN1dCBoZXJl
IF0tLS0tLS0tLS0tLS0NClsgICA1Mi40MDAxNDZdIFdBUk5JTkc6IGF0IGRyaXZlcnMvbmV0
L3hlbi1uZXRmcm9udC5jOjQ2NSB4ZW5uZXRfc3RhcnRfeG1pdCsweDdmZS8weDg2MCgpDQpb
ICAgNTIuNDAwMTUyXSBNb2R1bGVzIGxpbmtlZCBpbjoNClsgICA1Mi40MDAxNThdIFBpZDog
MCwgY29tbTogc3dhcHBlci8wIFRhaW50ZWQ6IEcgICAgICAgIFcgICAgMy42LjBwcmUtcmMx
LTIwMTIxMDExICMxDQpbICAgNTIuNDAwMTY0XSBDYWxsIFRyYWNlOg0KWyAgIDUyLjQwMDE2
N10gIDxJUlE+ICBbPGZmZmZmZmZmODEwNjY0ZWE+XSB3YXJuX3Nsb3dwYXRoX2NvbW1vbisw
eDdhLzB4YjANClsgICA1Mi40MDAxNzhdICBbPGZmZmZmZmZmODEwNjY1MzU+XSB3YXJuX3Ns
b3dwYXRoX251bGwrMHgxNS8weDIwDQpbICAgNTIuNDAwMTgzXSAgWzxmZmZmZmZmZjgxNDZk
ODllPl0geGVubmV0X3N0YXJ0X3htaXQrMHg3ZmUvMHg4NjANClsgICA1Mi40MDAxOTFdICBb
PGZmZmZmZmZmODE2MWYzNDk+XSBkZXZfaGFyZF9zdGFydF94bWl0KzB4MjA5LzB4NDYwDQpb
ICAgNTIuNDAwMTk3XSAgWzxmZmZmZmZmZjgxNjNiMDM2Pl0gc2NoX2RpcmVjdF94bWl0KzB4
ZjYvMHgyOTANClsgICA1Mi40MDAyMDJdICBbPGZmZmZmZmZmODE2MWY3NDY+XSBkZXZfcXVl
dWVfeG1pdCsweDFhNi8weDVhMA0KWyAgIDUyLjQwMDIwOF0gIFs8ZmZmZmZmZmY4MTYxZjVh
MD5dID8gZGV2X2hhcmRfc3RhcnRfeG1pdCsweDQ2MC8weDQ2MA0KWyAgIDUyLjQwMDIxNF0g
IFs8ZmZmZmZmZmY4MTBiMTQxNz5dID8gbG9ja19yZWxlYXNlKzB4MTE3LzB4MjUwDQpbICAg
NTIuNDAwMjIxXSAgWzxmZmZmZmZmZjgxNmI5NTM2Pl0gaXBfZmluaXNoX291dHB1dCsweDIy
Ni8weDUzMA0KWyAgIDUyLjQwMDIyNl0gIFs8ZmZmZmZmZmY4MTZiOTNkZD5dID8gaXBfZmlu
aXNoX291dHB1dCsweGNkLzB4NTMwDQpbICAgNTIuNDAwMjMyXSAgWzxmZmZmZmZmZjgxNmI5
ODk5Pl0gaXBfb3V0cHV0KzB4NTkvMHhlMA0KWyAgIDUyLjQwMDIzN10gIFs8ZmZmZmZmZmY4
MTZiODNiOD5dIGlwX2xvY2FsX291dCsweDI4LzB4OTANClsgICA1Mi40MDAyNDJdICBbPGZm
ZmZmZmZmODE2Yjg5NmY+XSBpcF9xdWV1ZV94bWl0KzB4MTdmLzB4NGEwDQpbICAgNTIuNDAw
MjQ3XSAgWzxmZmZmZmZmZjgxNmI4N2YwPl0gPyBpcF9zZW5kX3VuaWNhc3RfcmVwbHkrMHgz
NDAvMHgzNDANClsgICA1Mi40MDAyNTRdICBbPGZmZmZmZmZmODEwYTBiYTc+XSA/IGdldG5z
dGltZW9mZGF5KzB4NDcvMHhlMA0KWyAgIDUyLjQwMDI2MV0gIFs8ZmZmZmZmZmY4MTYwZjRj
OT5dID8gX19za2JfY2xvbmUrMHgyOS8weDEyMA0KWyAgIDUyLjQwMDI2Nl0gIFs8ZmZmZmZm
ZmY4MTZjZWEyMD5dIHRjcF90cmFuc21pdF9za2IrMHg0MDAvMHg4ZDANClsgICA1Mi40MDAy
NzJdICBbPGZmZmZmZmZmODE2ZDExMDY+XSB0Y3BfcmV0cmFuc21pdF9za2IrMHgxYzYvMHg1
YTANClsgICA1Mi40MDAyNzhdICBbPGZmZmZmZmZmODE2ZDMzYjA+XSA/IHRjcF93cml0ZV90
aW1lcl9oYW5kbGVyKzB4MWEwLzB4MWEwDQpbICAgNTIuNDAwMjgzXSAgWzxmZmZmZmZmZjgx
NmQyZjM4Pl0gdGNwX3JldHJhbnNtaXRfdGltZXIrMHgzNTgvMHg2MzANClsgICA1Mi40MDAy
ODhdICBbPGZmZmZmZmZmODE2ZDMzNGQ+XSB0Y3Bfd3JpdGVfdGltZXJfaGFuZGxlcisweDEz
ZC8weDFhMA0KWyAgIDUyLjQwMDI5M10gIFs8ZmZmZmZmZmY4MTZkMzQyOD5dIHRjcF93cml0
ZV90aW1lcisweDc4LzB4ODANClsgICA1Mi40MDAyOTldICBbPGZmZmZmZmZmODEwNzNmN2M+
XSBjYWxsX3RpbWVyX2ZuKzB4N2MvMHgxMDANClsgICA1Mi40MDAzMDNdICBbPGZmZmZmZmZm
ODEwNzNmMDA+XSA/IGNhc2NhZGUrMHhhMC8weGEwDQpbICAgNTIuNDAwMzA4XSAgWzxmZmZm
ZmZmZjgxNmQzM2IwPl0gPyB0Y3Bfd3JpdGVfdGltZXJfaGFuZGxlcisweDFhMC8weDFhMA0K
WyAgIDUyLjQwMDMxM10gIFs8ZmZmZmZmZmY4MTZkMzNiMD5dID8gdGNwX3dyaXRlX3RpbWVy
X2hhbmRsZXIrMHgxYTAvMHgxYTANClsgICA1Mi40MDAzMTldICBbPGZmZmZmZmZmODEwNzQy
MTc+XSBydW5fdGltZXJfc29mdGlycSsweDIxNy8weDI1MA0KWyAgIDUyLjQwMDMyNV0gIFs8
ZmZmZmZmZmY4MTA2ZTNkOT5dIF9fZG9fc29mdGlycSsweGM5LzB4MWEwDQpbICAgNTIuNDAw
MzMwXSAgWzxmZmZmZmZmZjgxNzQ4ZDNjPl0gY2FsbF9zb2Z0aXJxKzB4MWMvMHgzMA0KWyAg
IDUyLjQwMDMzNl0gIFs8ZmZmZmZmZmY4MTAwZWRiNT5dIGRvX3NvZnRpcnErMHg4NS8weGYw
DQpbICAgNTIuNDAwMzQxXSAgWzxmZmZmZmZmZjgxMDZlMjRlPl0gaXJxX2V4aXQrMHg5ZS8w
eGQwDQpbICAgNTIuNDAwMzQ3XSAgWzxmZmZmZmZmZjgxMzM5ZjVmPl0geGVuX2V2dGNobl9k
b191cGNhbGwrMHgyZi8weDQwDQpbICAgNTIuNDAwMzUyXSAgWzxmZmZmZmZmZjgxNzQ4ZDll
Pl0geGVuX2RvX2h5cGVydmlzb3JfY2FsbGJhY2srMHgxZS8weDMwDQpbICAgNTIuNDAwMzU2
XSAgPEVPST4gIFs8ZmZmZmZmZmY4MTAwMTNhYT5dID8geGVuX2h5cGVyY2FsbF9zY2hlZF9v
cCsweGEvMHgyMA0KWyAgIDUyLjQwMDM2Nl0gIFs8ZmZmZmZmZmY4MTAwMTNhYT5dID8geGVu
X2h5cGVyY2FsbF9zY2hlZF9vcCsweGEvMHgyMA0KWyAgIDUyLjQwMDM3MV0gIFs8ZmZmZmZm
ZmY4MTAwODY5MD5dID8geGVuX3NhZmVfaGFsdCsweDEwLzB4MjANClsgICA1Mi40MDAzNzdd
ICBbPGZmZmZmZmZmODEwMTYwZDA+XSA/IGRlZmF1bHRfaWRsZSsweDQwLzB4OTANClsgICA1
Mi40MDAzODJdICBbPGZmZmZmZmZmODEwMTY0ODY+XSA/IGNwdV9pZGxlKzB4OTYvMHhmMA0K
WyAgIDUyLjQwMDM4N10gIFs8ZmZmZmZmZmY4MTcyMmQzYz5dID8gcmVzdF9pbml0KzB4YmMv
MHhkMA0KWyAgIDUyLjQwMDM5MV0gIFs8ZmZmZmZmZmY4MTcyMmM4MD5dID8gY3N1bV9wYXJ0
aWFsX2NvcHlfZ2VuZXJpYysweDE3MC8weDE3MA0KWyAgIDUyLjQwMDM5OF0gIFs8ZmZmZmZm
ZmY4MWNlMGRmMj5dID8gc3RhcnRfa2VybmVsKzB4MzkwLzB4MzlkDQpbICAgNTIuNDAwNDAz
XSAgWzxmZmZmZmZmZjgxY2UwODgyPl0gPyBrZXJuZWxfaW5pdCsweDIwYi8weDIwYg0KWyAg
IDUyLjQwMDQwOF0gIFs8ZmZmZmZmZmY4MWNlMDM1Nj5dID8geDg2XzY0X3N0YXJ0X3Jlc2Vy
dmF0aW9ucysweDEzMS8weDEzNg0KWyAgIDUyLjQwMDQxNF0gIFs8ZmZmZmZmZmY4MWNlM2Q2
MD5dID8geGVuX3N0YXJ0X2tlcm5lbCsweDcwZC8weDcwZg0KWyAgIDUyLjQwMDQyMF0gLS0t
WyBlbmQgdHJhY2UgMmUyOGVlYzkzYjdhOGI4MCBdLS0tDQpbICAgNzAuNTYwMjQyXSAtLS0t
LS0tLS0tLS1bIGN1dCBoZXJlIF0tLS0tLS0tLS0tLS0NClsgICA3MC41NjAzMzJdIFdBUk5J
Tkc6IGF0IGRyaXZlcnMvbmV0L3hlbi1uZXRmcm9udC5jOjQ2NSB4ZW5uZXRfc3RhcnRfeG1p
dCsweDdmZS8weDg2MCgpDQpbICAgNzAuNTYwMzYwXSBNb2R1bGVzIGxpbmtlZCBpbjoNClsg
ICA3MC41NjAzODFdIFBpZDogMCwgY29tbTogc3dhcHBlci8wIFRhaW50ZWQ6IEcgICAgICAg
IFcgICAgMy42LjBwcmUtcmMxLTIwMTIxMDExICMxDQpbICAgNzAuNTYwNDA4XSBDYWxsIFRy
YWNlOg0KWyAgIDcwLjU2MDQyMV0gIDxJUlE+ICBbPGZmZmZmZmZmODEwNjY0ZWE+XSB3YXJu
X3Nsb3dwYXRoX2NvbW1vbisweDdhLzB4YjANClsgICA3MC41NjA0NjJdICBbPGZmZmZmZmZm
ODEwNjY1MzU+XSB3YXJuX3Nsb3dwYXRoX251bGwrMHgxNS8weDIwDQpbICAgNzAuNTYwNDg1
XSAgWzxmZmZmZmZmZjgxNDZkODllPl0geGVubmV0X3N0YXJ0X3htaXQrMHg3ZmUvMHg4NjAN
ClsgICA3MC41NjA1MTJdICBbPGZmZmZmZmZmODE2MWYzNDk+XSBkZXZfaGFyZF9zdGFydF94
bWl0KzB4MjA5LzB4NDYwDQpbICAgNzAuNTYwNTM2XSAgWzxmZmZmZmZmZjgxNjNiMDM2Pl0g
c2NoX2RpcmVjdF94bWl0KzB4ZjYvMHgyOTANClsgICA3MC41NjA1NTldICBbPGZmZmZmZmZm
ODE2MWY3NDY+XSBkZXZfcXVldWVfeG1pdCsweDFhNi8weDVhMA0KWyAgIDcwLjU2MDU4MV0g
IFs8ZmZmZmZmZmY4MTYxZjVhMD5dID8gZGV2X2hhcmRfc3RhcnRfeG1pdCsweDQ2MC8weDQ2
MA0KWyAgIDcwLjU2MDYwNV0gIFs8ZmZmZmZmZmY4MTYyOWE3Nz5dIG5laWdoX3Jlc29sdmVf
b3V0cHV0KzB4MTI3LzB4MjUwDQpbICAgNzAuNTYwNjMwXSAgWzxmZmZmZmZmZjgxNmI5NmFk
Pl0gaXBfZmluaXNoX291dHB1dCsweDM5ZC8weDUzMA0KWyAgIDcwLjU2MDY1M10gIFs8ZmZm
ZmZmZmY4MTZiOTNkZD5dID8gaXBfZmluaXNoX291dHB1dCsweGNkLzB4NTMwDQpbICAgNzAu
NTYwNjc5XSAgWzxmZmZmZmZmZjgxNmI5ODk5Pl0gaXBfb3V0cHV0KzB4NTkvMHhlMA0KWyAg
IDcwLjU2MDcwMV0gIFs8ZmZmZmZmZmY4MTZiODNiOD5dIGlwX2xvY2FsX291dCsweDI4LzB4
OTANClsgICA3MC41NjA3MjJdICBbPGZmZmZmZmZmODE2Yjg5NmY+XSBpcF9xdWV1ZV94bWl0
KzB4MTdmLzB4NGEwDQpbICAgNzAuNTYwNzQ0XSAgWzxmZmZmZmZmZjgxNmI4N2YwPl0gPyBp
cF9zZW5kX3VuaWNhc3RfcmVwbHkrMHgzNDAvMHgzNDANClsgICA3MC41NjA3NjhdICBbPGZm
ZmZmZmZmODEwYTBiYTc+XSA/IGdldG5zdGltZW9mZGF5KzB4NDcvMHhlMA0KWyAgIDcwLjU2
MDc5MV0gIFs8ZmZmZmZmZmY4MTYwZjRjOT5dID8gX19za2JfY2xvbmUrMHgyOS8weDEyMA0K
WyAgIDcwLjU2MDgxMl0gIFs8ZmZmZmZmZmY4MTZjZWEyMD5dIHRjcF90cmFuc21pdF9za2Ir
MHg0MDAvMHg4ZDANClsgICA3MC41NjA4MzVdICBbPGZmZmZmZmZmODE2ZDExMDY+XSB0Y3Bf
cmV0cmFuc21pdF9za2IrMHgxYzYvMHg1YTANClsgICA3MC41NjA4NTldICBbPGZmZmZmZmZm
ODE2ZDMzYjA+XSA/IHRjcF93cml0ZV90aW1lcl9oYW5kbGVyKzB4MWEwLzB4MWEwDQpbICAg
NzAuNTYwODgyXSAgWzxmZmZmZmZmZjgxNmQyZjM4Pl0gdGNwX3JldHJhbnNtaXRfdGltZXIr
MHgzNTgvMHg2MzANClsgICA3MC41NjA5MDVdICBbPGZmZmZmZmZmODE2ZDMzNGQ+XSB0Y3Bf
d3JpdGVfdGltZXJfaGFuZGxlcisweDEzZC8weDFhMA0KWyAgIDcwLjU2MDkyOF0gIFs8ZmZm
ZmZmZmY4MTZkMzQyOD5dIHRjcF93cml0ZV90aW1lcisweDc4LzB4ODANClsgICA3MC41NjA5
NTFdICBbPGZmZmZmZmZmODEwNzNmN2M+XSBjYWxsX3RpbWVyX2ZuKzB4N2MvMHgxMDANClsg
ICA3MC41NjA5NzJdICBbPGZmZmZmZmZmODEwNzNmMDA+XSA/IGNhc2NhZGUrMHhhMC8weGEw
DQpbICAgNzAuNTYwOTkzXSAgWzxmZmZmZmZmZjgxNmQzM2IwPl0gPyB0Y3Bfd3JpdGVfdGlt
ZXJfaGFuZGxlcisweDFhMC8weDFhMA0KWyAgIDcwLjU2MTAxN10gIFs8ZmZmZmZmZmY4MTZk
MzNiMD5dID8gdGNwX3dyaXRlX3RpbWVyX2hhbmRsZXIrMHgxYTAvMHgxYTANClsgICA3MC41
NjEwNDBdICBbPGZmZmZmZmZmODEwNzQyMTc+XSBydW5fdGltZXJfc29mdGlycSsweDIxNy8w
eDI1MA0KWyAgIDcwLjU2MTA2NF0gIFs8ZmZmZmZmZmY4MTA2ZTNkOT5dIF9fZG9fc29mdGly
cSsweGM5LzB4MWEwDQpbICAgNzAuNTYxMDg3XSAgWzxmZmZmZmZmZjgxNzQ4ZDNjPl0gY2Fs
bF9zb2Z0aXJxKzB4MWMvMHgzMA0KWyAgIDcwLjU2MTEwOF0gIFs8ZmZmZmZmZmY4MTAwZWRi
NT5dIGRvX3NvZnRpcnErMHg4NS8weGYwDQpbICAgNzAuNTYxMTMwXSAgWzxmZmZmZmZmZjgx
MDZlMjRlPl0gaXJxX2V4aXQrMHg5ZS8weGQwDQpbICAgNzAuNTYxMTUzXSAgWzxmZmZmZmZm
ZjgxMzM5ZjVmPl0geGVuX2V2dGNobl9kb191cGNhbGwrMHgyZi8weDQwDQpbICAgNzAuNTYx
MTc2XSAgWzxmZmZmZmZmZjgxNzQ4ZDllPl0geGVuX2RvX2h5cGVydmlzb3JfY2FsbGJhY2sr
MHgxZS8weDMwDQpbICAgNzAuNTYxMTk1XSAgPEVPST4gIFs8ZmZmZmZmZmY4MTAwMTNhYT5d
ID8geGVuX2h5cGVyY2FsbF9zY2hlZF9vcCsweGEvMHgyMA0KWyAgIDcwLjU2MTIzMl0gIFs8
ZmZmZmZmZmY4MTAwMTNhYT5dID8geGVuX2h5cGVyY2FsbF9zY2hlZF9vcCsweGEvMHgyMA0K
WyAgIDcwLjU2MTI1Nl0gIFs8ZmZmZmZmZmY4MTAwODY5MD5dID8geGVuX3NhZmVfaGFsdCsw
eDEwLzB4MjANClsgICA3MC41NjEyNzhdICBbPGZmZmZmZmZmODEwMTYwZDA+XSA/IGRlZmF1
bHRfaWRsZSsweDQwLzB4OTANClsgICA3MC41NjEyOTldICBbPGZmZmZmZmZmODEwMTY0ODY+
XSA/IGNwdV9pZGxlKzB4OTYvMHhmMA0KWyAgIDcwLjU2MTMxOV0gIFs8ZmZmZmZmZmY4MTcy
MmQzYz5dID8gcmVzdF9pbml0KzB4YmMvMHhkMA0KWyAgIDcwLjU2MTMzOV0gIFs8ZmZmZmZm
ZmY4MTcyMmM4MD5dID8gY3N1bV9wYXJ0aWFsX2NvcHlfZ2VuZXJpYysweDE3MC8weDE3MA0K
WyAgIDcwLjU2MTM5MF0gIFs8ZmZmZmZmZmY4MWNlMGRmMj5dID8gc3RhcnRfa2VybmVsKzB4
MzkwLzB4MzlkDQpbICAgNzAuNTYxNDE0XSAgWzxmZmZmZmZmZjgxY2UwODgyPl0gPyBrZXJu
ZWxfaW5pdCsweDIwYi8weDIwYg0KWyAgIDcwLjU2MTQzNl0gIFs8ZmZmZmZmZmY4MWNlMDM1
Nj5dID8geDg2XzY0X3N0YXJ0X3Jlc2VydmF0aW9ucysweDEzMS8weDEzNg0KWyAgIDcwLjU2
MTQ2Ml0gIFs8ZmZmZmZmZmY4MWNlM2Q2MD5dID8geGVuX3N0YXJ0X2tlcm5lbCsweDcwZC8w
eDcwZg0KWyAgIDcwLjU2MTQ4M10gLS0tWyBlbmQgdHJhY2UgMmUyOGVlYzkzYjdhOGI4MSBd
LS0tDQpbICAxMDYuOTMzNDIwXSAtLS0tLS0tLS0tLS1bIGN1dCBoZXJlIF0tLS0tLS0tLS0t
LS0NClsgIDEwNi45MzM0NDVdIFdBUk5JTkc6IGF0IGRyaXZlcnMvbmV0L3hlbi1uZXRmcm9u
dC5jOjQ2NSB4ZW5uZXRfc3RhcnRfeG1pdCsweDdmZS8weDg2MCgpDQpbICAxMDYuOTMzNDUy
XSBNb2R1bGVzIGxpbmtlZCBpbjoNClsgIDEwNi45MzM0NThdIFBpZDogMTk1NCwgY29tbTog
Z3ppcCBUYWludGVkOiBHICAgICAgICBXICAgIDMuNi4wcHJlLXJjMS0yMDEyMTAxMSAjMQ0K
WyAgMTA2LjkzMzQ2M10gQ2FsbCBUcmFjZToNClsgIDEwNi45MzM0NjZdICA8SVJRPiAgWzxm
ZmZmZmZmZjgxMDY2NGVhPl0gd2Fybl9zbG93cGF0aF9jb21tb24rMHg3YS8weGIwDQpbICAx
MDYuOTMzNDc2XSAgWzxmZmZmZmZmZjgxMDY2NTM1Pl0gd2Fybl9zbG93cGF0aF9udWxsKzB4
MTUvMHgyMA0KWyAgMTA2LjkzMzQ4Ml0gIFs8ZmZmZmZmZmY4MTQ2ZDg5ZT5dIHhlbm5ldF9z
dGFydF94bWl0KzB4N2ZlLzB4ODYwDQpbICAxMDYuOTMzNDkwXSAgWzxmZmZmZmZmZjgxNjFm
MzQ5Pl0gZGV2X2hhcmRfc3RhcnRfeG1pdCsweDIwOS8weDQ2MA0KWyAgMTA2LjkzMzQ5Nl0g
IFs8ZmZmZmZmZmY4MTYzYjAzNj5dIHNjaF9kaXJlY3RfeG1pdCsweGY2LzB4MjkwDQpbICAx
MDYuOTMzNTAxXSAgWzxmZmZmZmZmZjgxNjFmNzQ2Pl0gZGV2X3F1ZXVlX3htaXQrMHgxYTYv
MHg1YTANClsgIDEwNi45MzM1MDZdICBbPGZmZmZmZmZmODE2MWY1YTA+XSA/IGRldl9oYXJk
X3N0YXJ0X3htaXQrMHg0NjAvMHg0NjANClsgIDEwNi45MzM1MTJdICBbPGZmZmZmZmZmODE2
MjlhNzc+XSBuZWlnaF9yZXNvbHZlX291dHB1dCsweDEyNy8weDI1MA0KWyAgMTA2LjkzMzUx
OV0gIFs8ZmZmZmZmZmY4MTZiOTZhZD5dIGlwX2ZpbmlzaF9vdXRwdXQrMHgzOWQvMHg1MzAN
ClsgIDEwNi45MzM1MjVdICBbPGZmZmZmZmZmODE2YjkzZGQ+XSA/IGlwX2ZpbmlzaF9vdXRw
dXQrMHhjZC8weDUzMA0KWyAgMTA2LjkzMzUzMF0gIFs8ZmZmZmZmZmY4MTZiOTg5OT5dIGlw
X291dHB1dCsweDU5LzB4ZTANClsgIDEwNi45MzM1MzVdICBbPGZmZmZmZmZmODE2YjgzYjg+
XSBpcF9sb2NhbF9vdXQrMHgyOC8weDkwDQpbICAxMDYuOTMzNTQwXSAgWzxmZmZmZmZmZjgx
NmI4OTZmPl0gaXBfcXVldWVfeG1pdCsweDE3Zi8weDRhMA0KWyAgMTA2LjkzMzU0NV0gIFs8
ZmZmZmZmZmY4MTZiODdmMD5dID8gaXBfc2VuZF91bmljYXN0X3JlcGx5KzB4MzQwLzB4MzQw
DQpbICAxMDYuOTMzNTUxXSAgWzxmZmZmZmZmZjgxMGEwYmE3Pl0gPyBnZXRuc3RpbWVvZmRh
eSsweDQ3LzB4ZTANClsgIDEwNi45MzM1NTddICBbPGZmZmZmZmZmODE2MGY0Yzk+XSA/IF9f
c2tiX2Nsb25lKzB4MjkvMHgxMjANClsgIDEwNi45MzM1NjJdICBbPGZmZmZmZmZmODE2Y2Vh
MjA+XSB0Y3BfdHJhbnNtaXRfc2tiKzB4NDAwLzB4OGQwDQpbICAxMDYuOTMzNTY3XSAgWzxm
ZmZmZmZmZjgxNmQxMTA2Pl0gdGNwX3JldHJhbnNtaXRfc2tiKzB4MWM2LzB4NWEwDQpbICAx
MDYuOTMzNTczXSAgWzxmZmZmZmZmZjgxNmQzM2IwPl0gPyB0Y3Bfd3JpdGVfdGltZXJfaGFu
ZGxlcisweDFhMC8weDFhMA0KWyAgMTA2LjkzMzU3OF0gIFs8ZmZmZmZmZmY4MTZkMmYzOD5d
IHRjcF9yZXRyYW5zbWl0X3RpbWVyKzB4MzU4LzB4NjMwDQpbICAxMDYuOTMzNTg0XSAgWzxm
ZmZmZmZmZjgxNmQzMzRkPl0gdGNwX3dyaXRlX3RpbWVyX2hhbmRsZXIrMHgxM2QvMHgxYTAN
ClsgIDEwNi45MzM1OTBdICBbPGZmZmZmZmZmODE2ZDM0Mjg+XSB0Y3Bfd3JpdGVfdGltZXIr
MHg3OC8weDgwDQpbICAxMDYuOTMzNTk1XSAgWzxmZmZmZmZmZjgxMDczZjdjPl0gY2FsbF90
aW1lcl9mbisweDdjLzB4MTAwDQpbICAxMDYuOTMzNjAwXSAgWzxmZmZmZmZmZjgxMDczZjAw
Pl0gPyBjYXNjYWRlKzB4YTAvMHhhMA0KWyAgMTA2LjkzMzYwNF0gIFs8ZmZmZmZmZmY4MTZk
MzNiMD5dID8gdGNwX3dyaXRlX3RpbWVyX2hhbmRsZXIrMHgxYTAvMHgxYTANClsgIDEwNi45
MzM2MTBdICBbPGZmZmZmZmZmODE2ZDMzYjA+XSA/IHRjcF93cml0ZV90aW1lcl9oYW5kbGVy
KzB4MWEwLzB4MWEwDQpbICAxMDYuOTMzNjE1XSAgWzxmZmZmZmZmZjgxMDc0MjE3Pl0gcnVu
X3RpbWVyX3NvZnRpcnErMHgyMTcvMHgyNTANClsgIDEwNi45MzM2MjFdICBbPGZmZmZmZmZm
ODEwNmUzZDk+XSBfX2RvX3NvZnRpcnErMHhjOS8weDFhMA0KWyAgMTA2LjkzMzYyN10gIFs8
ZmZmZmZmZmY4MTc0OGQzYz5dIGNhbGxfc29mdGlycSsweDFjLzB4MzANClsgIDEwNi45MzM2
MzJdICBbPGZmZmZmZmZmODEwMGVkYjU+XSBkb19zb2Z0aXJxKzB4ODUvMHhmMA0KWyAgMTA2
LjkzMzYzN10gIFs8ZmZmZmZmZmY4MTA2ZTI0ZT5dIGlycV9leGl0KzB4OWUvMHhkMA0KWyAg
MTA2LjkzMzY0M10gIFs8ZmZmZmZmZmY4MTMzOWY1Zj5dIHhlbl9ldnRjaG5fZG9fdXBjYWxs
KzB4MmYvMHg0MA0KWyAgMTA2LjkzMzY0OF0gIFs8ZmZmZmZmZmY4MTc0OGQ5ZT5dIHhlbl9k
b19oeXBlcnZpc29yX2NhbGxiYWNrKzB4MWUvMHgzMA0KWyAgMTA2LjkzMzY1M10gIDxFT0k+
IA0KWyAgMTA2LjkzMzY1NV0gLS0tWyBlbmQgdHJhY2UgMmUyOGVlYzkzYjdhOGI4MiBdLS0t
DQpbICAxNzkuNjgwMzE1XSAtLS0tLS0tLS0tLS1bIGN1dCBoZXJlIF0tLS0tLS0tLS0tLS0N
ClsgIDE3OS42ODAzNDRdIFdBUk5JTkc6IGF0IGRyaXZlcnMvbmV0L3hlbi1uZXRmcm9udC5j
OjQ2NSB4ZW5uZXRfc3RhcnRfeG1pdCsweDdmZS8weDg2MCgpDQpbICAxNzkuNjgwMzU3XSBN
b2R1bGVzIGxpbmtlZCBpbjoNClsgIDE3OS42ODAzNjldIFBpZDogMCwgY29tbTogc3dhcHBl
ci8wIFRhaW50ZWQ6IEcgICAgICAgIFcgICAgMy42LjBwcmUtcmMxLTIwMTIxMDExICMxDQpb
ICAxNzkuNjgwMzgxXSBDYWxsIFRyYWNlOg0KWyAgMTc5LjY4MDM4N10gIDxJUlE+ICBbPGZm
ZmZmZmZmODEwNjY0ZWE+XSB3YXJuX3Nsb3dwYXRoX2NvbW1vbisweDdhLzB4YjANClsgIDE3
OS42ODA0MDldICBbPGZmZmZmZmZmODEwNjY1MzU+XSB3YXJuX3Nsb3dwYXRoX251bGwrMHgx
NS8weDIwDQpbICAxNzkuNjgwNDIwXSAgWzxmZmZmZmZmZjgxNDZkODllPl0geGVubmV0X3N0
YXJ0X3htaXQrMHg3ZmUvMHg4NjANClsgIDE3OS42ODA0MzddICBbPGZmZmZmZmZmODE2MWYz
NDk+XSBkZXZfaGFyZF9zdGFydF94bWl0KzB4MjA5LzB4NDYwDQpbICAxNzkuNjgwNDQ5XSAg
WzxmZmZmZmZmZjgxNjNiMDM2Pl0gc2NoX2RpcmVjdF94bWl0KzB4ZjYvMHgyOTANClsgIDE3
OS42ODA0NjFdICBbPGZmZmZmZmZmODE2MWY3NDY+XSBkZXZfcXVldWVfeG1pdCsweDFhNi8w
eDVhMA0KWyAgMTc5LjY4MDQ3Ml0gIFs8ZmZmZmZmZmY4MTYxZjVhMD5dID8gZGV2X2hhcmRf
c3RhcnRfeG1pdCsweDQ2MC8weDQ2MA0KWyAgMTc5LjY4MDQ4NV0gIFs8ZmZmZmZmZmY4MTYy
OWE3Nz5dIG5laWdoX3Jlc29sdmVfb3V0cHV0KzB4MTI3LzB4MjUwDQpbICAxNzkuNjgwNDk4
XSAgWzxmZmZmZmZmZjgxNmI5NmFkPl0gaXBfZmluaXNoX291dHB1dCsweDM5ZC8weDUzMA0K
WyAgMTc5LjY4MDUxMV0gIFs8ZmZmZmZmZmY4MTZiOTNkZD5dID8gaXBfZmluaXNoX291dHB1
dCsweGNkLzB4NTMwDQpbICAxNzkuNjgwNTIzXSAgWzxmZmZmZmZmZjgxNmI5ODk5Pl0gaXBf
b3V0cHV0KzB4NTkvMHhlMA0KWyAgMTc5LjY4MDUzM10gIFs8ZmZmZmZmZmY4MTZiODNiOD5d
IGlwX2xvY2FsX291dCsweDI4LzB4OTANClsgIDE3OS42ODA1NDRdICBbPGZmZmZmZmZmODE2
Yjg5NmY+XSBpcF9xdWV1ZV94bWl0KzB4MTdmLzB4NGEwDQpbICAxNzkuNjgwNTU1XSAgWzxm
ZmZmZmZmZjgxNmI4N2YwPl0gPyBpcF9zZW5kX3VuaWNhc3RfcmVwbHkrMHgzNDAvMHgzNDAN
ClsgIDE3OS42ODA1NjddICBbPGZmZmZmZmZmODEwYTBiYTc+XSA/IGdldG5zdGltZW9mZGF5
KzB4NDcvMHhlMA0KWyAgMTc5LjY4MDU3OV0gIFs8ZmZmZmZmZmY4MTYwZjRjOT5dID8gX19z
a2JfY2xvbmUrMHgyOS8weDEyMA0KWyAgMTc5LjY4MDU5MV0gIFs8ZmZmZmZmZmY4MTZjZWEy
MD5dIHRjcF90cmFuc21pdF9za2IrMHg0MDAvMHg4ZDANClsgIDE3OS42ODA2MDNdICBbPGZm
ZmZmZmZmODE2ZDExMDY+XSB0Y3BfcmV0cmFuc21pdF9za2IrMHgxYzYvMHg1YTANClsgIDE3
OS42ODA2MTVdICBbPGZmZmZmZmZmODE2ZDMzYjA+XSA/IHRjcF93cml0ZV90aW1lcl9oYW5k
bGVyKzB4MWEwLzB4MWEwDQpbICAxNzkuNjgwNjI3XSAgWzxmZmZmZmZmZjgxNmQyZjM4Pl0g
dGNwX3JldHJhbnNtaXRfdGltZXIrMHgzNTgvMHg2MzANClsgIDE3OS42ODA2MzldICBbPGZm
ZmZmZmZmODE2ZDMzNGQ+XSB0Y3Bfd3JpdGVfdGltZXJfaGFuZGxlcisweDEzZC8weDFhMA0K
WyAgMTc5LjY4MDY1MV0gIFs8ZmZmZmZmZmY4MTZkMzQyOD5dIHRjcF93cml0ZV90aW1lcisw
eDc4LzB4ODANClsgIDE3OS42ODA2NjJdICBbPGZmZmZmZmZmODEwNzNmN2M+XSBjYWxsX3Rp
bWVyX2ZuKzB4N2MvMHgxMDANClsgIDE3OS42ODA2NzNdICBbPGZmZmZmZmZmODEwNzNmMDA+
XSA/IGNhc2NhZGUrMHhhMC8weGEwDQpbICAxNzkuNjgwNjgzXSAgWzxmZmZmZmZmZjgxNmQz
M2IwPl0gPyB0Y3Bfd3JpdGVfdGltZXJfaGFuZGxlcisweDFhMC8weDFhMA0KWyAgMTc5LjY4
MDY5Nl0gIFs8ZmZmZmZmZmY4MTZkMzNiMD5dID8gdGNwX3dyaXRlX3RpbWVyX2hhbmRsZXIr
MHgxYTAvMHgxYTANClsgIDE3OS42ODA3MDddICBbPGZmZmZmZmZmODEwNzQyMTc+XSBydW5f
dGltZXJfc29mdGlycSsweDIxNy8weDI1MA0KWyAgMTc5LjY4MDcyMF0gIFs8ZmZmZmZmZmY4
MTA2ZTNkOT5dIF9fZG9fc29mdGlycSsweGM5LzB4MWEwDQpbICAxNzkuNjgwNzMyXSAgWzxm
ZmZmZmZmZjgxNzQ4ZDNjPl0gY2FsbF9zb2Z0aXJxKzB4MWMvMHgzMA0KWyAgMTc5LjY4MDc0
M10gIFs8ZmZmZmZmZmY4MTAwZWRiNT5dIGRvX3NvZnRpcnErMHg4NS8weGYwDQpbICAxNzku
NjgwNzU0XSAgWzxmZmZmZmZmZjgxMDZlMjRlPl0gaXJxX2V4aXQrMHg5ZS8weGQwDQpbICAx
NzkuNjgwNzY2XSAgWzxmZmZmZmZmZjgxMzM5ZjVmPl0geGVuX2V2dGNobl9kb191cGNhbGwr
MHgyZi8weDQwDQpbICAxNzkuNjgwNzc3XSAgWzxmZmZmZmZmZjgxNzQ4ZDllPl0geGVuX2Rv
X2h5cGVydmlzb3JfY2FsbGJhY2srMHgxZS8weDMwDQpbICAxNzkuNjgwNzg2XSAgPEVPST4g
IFs8ZmZmZmZmZmY4MTAwMTNhYT5dID8geGVuX2h5cGVyY2FsbF9zY2hlZF9vcCsweGEvMHgy
MA0KWyAgMTc5LjY4MDgwNl0gIFs8ZmZmZmZmZmY4MTAwMTNhYT5dID8geGVuX2h5cGVyY2Fs
bF9zY2hlZF9vcCsweGEvMHgyMA0KWyAgMTc5LjY4MDgxOF0gIFs8ZmZmZmZmZmY4MTAwODY5
MD5dID8geGVuX3NhZmVfaGFsdCsweDEwLzB4MjANClsgIDE3OS42ODA4MzBdICBbPGZmZmZm
ZmZmODEwMTYwZDA+XSA/IGRlZmF1bHRfaWRsZSsweDQwLzB4OTANClsgIDE3OS42ODA4NDFd
ICBbPGZmZmZmZmZmODEwMTY0ODY+XSA/IGNwdV9pZGxlKzB4OTYvMHhmMA0KWyAgMTc5LjY4
MDg1MV0gIFs8ZmZmZmZmZmY4MTcyMmQzYz5dID8gcmVzdF9pbml0KzB4YmMvMHhkMA0KWyAg
MTc5LjY4MDg2MV0gIFs8ZmZmZmZmZmY4MTcyMmM4MD5dID8gY3N1bV9wYXJ0aWFsX2NvcHlf
Z2VuZXJpYysweDE3MC8weDE3MA0KWyAgMTc5LjY4MDg3NV0gIFs8ZmZmZmZmZmY4MWNlMGRm
Mj5dID8gc3RhcnRfa2VybmVsKzB4MzkwLzB4MzlkDQpbICAxNzkuNjgwODg2XSAgWzxmZmZm
ZmZmZjgxY2UwODgyPl0gPyBrZXJuZWxfaW5pdCsweDIwYi8weDIwYg0KWyAgMTc5LjY4MDg5
OF0gIFs8ZmZmZmZmZmY4MWNlMDM1Nj5dID8geDg2XzY0X3N0YXJ0X3Jlc2VydmF0aW9ucysw
eDEzMS8weDEzNg0KWyAgMTc5LjY4MDkxMV0gIFs8ZmZmZmZmZmY4MWNlM2Q2MD5dID8geGVu
X3N0YXJ0X2tlcm5lbCsweDcwZC8weDcwZg0KWyAgMTc5LjY4MDkyMl0gLS0tWyBlbmQgdHJh
Y2UgMmUyOGVlYzkzYjdhOGI4MyBdLS0tDQpbICAxOTkuMzAyMjM5XSB0dHlfaW5pdF9kZXY6
IDE5IGNhbGxiYWNrcyBzdXBwcmVzc2VkDQpbICAzMDAuMTQ4MTcxXSAtLS0tLS0tLS0tLS1b
IGN1dCBoZXJlIF0tLS0tLS0tLS0tLS0NClsgIDMwMC4xNDgyMjZdIFdBUk5JTkc6IGF0IGRy
aXZlcnMvbmV0L3hlbi1uZXRmcm9udC5jOjQ2NSB4ZW5uZXRfc3RhcnRfeG1pdCsweDdmZS8w
eDg2MCgpDQpbICAzMDAuMTQ4MjU1XSBNb2R1bGVzIGxpbmtlZCBpbjoNClsgIDMwMC4xNDgy
NzhdIFBpZDogMCwgY29tbTogc3dhcHBlci8wIFRhaW50ZWQ6IEcgICAgICAgIFcgICAgMy42
LjBwcmUtcmMxLTIwMTIxMDExICMxDQpbICAzMDAuMTQ4MzA0XSBDYWxsIFRyYWNlOg0KWyAg
MzAwLjE0ODMxOF0gIDxJUlE+ICBbPGZmZmZmZmZmODEwNjY0ZWE+XSB3YXJuX3Nsb3dwYXRo
X2NvbW1vbisweDdhLzB4YjANClsgIDMwMC4xNDgzNjJdICBbPGZmZmZmZmZmODEwNjY1MzU+
XSB3YXJuX3Nsb3dwYXRoX251bGwrMHgxNS8weDIwDQpbICAzMDAuMTQ4Mzg2XSAgWzxmZmZm
ZmZmZjgxNDZkODllPl0geGVubmV0X3N0YXJ0X3htaXQrMHg3ZmUvMHg4NjANClsgIDMwMC4x
NDg0MTVdICBbPGZmZmZmZmZmODE2MWYzNDk+XSBkZXZfaGFyZF9zdGFydF94bWl0KzB4MjA5
LzB4NDYwDQpbICAzMDAuMTQ4NDQxXSAgWzxmZmZmZmZmZjgxNjNiMDM2Pl0gc2NoX2RpcmVj
dF94bWl0KzB4ZjYvMHgyOTANClsgIDMwMC4xNDg0NjRdICBbPGZmZmZmZmZmODE2MWY3NDY+
XSBkZXZfcXVldWVfeG1pdCsweDFhNi8weDVhMA0KWyAgMzAwLjE0ODQ4OF0gIFs8ZmZmZmZm
ZmY4MTYxZjVhMD5dID8gZGV2X2hhcmRfc3RhcnRfeG1pdCsweDQ2MC8weDQ2MA0KWyAgMzAw
LjE0ODUxNF0gIFs8ZmZmZmZmZmY4MTBhZDIyZD5dID8gdHJhY2VfaGFyZGlycXNfb24rMHhk
LzB4MTANClsgIDMwMC4xNDg1MzldICBbPGZmZmZmZmZmODE2MjlhNzc+XSBuZWlnaF9yZXNv
bHZlX291dHB1dCsweDEyNy8weDI1MA0KWyAgMzAwLjE0ODU2NV0gIFs8ZmZmZmZmZmY4MTZh
ZDFiZT5dID8gaXB2NF9uZWlnaF9sb29rdXArMHgzZS8weDE1MA0KWyAgMzAwLjE0ODU4OF0g
IFs8ZmZmZmZmZmY4MTYyYWQzNz5dIG5laWdoX3VwZGF0ZSsweDI5Ny8weDVlMA0KWyAgMzAw
LjE0ODYxMF0gIFs8ZmZmZmZmZmY4MTYyYWRjMj5dID8gbmVpZ2hfdXBkYXRlKzB4MzIyLzB4
NWUwDQpbICAzMDAuMTQ4NjMzXSAgWzxmZmZmZmZmZjgxMGFkMjJkPl0gPyB0cmFjZV9oYXJk
aXJxc19vbisweGQvMHgxMA0KWyAgMzAwLjE0ODY2MV0gIFs8ZmZmZmZmZmY4MTA2ZTc1Nj5d
ID8gbG9jYWxfYmhfZW5hYmxlKzB4YzYvMHgxNjANClsgIDMwMC4xNDg3MDJdICBbPGZmZmZm
ZmZmODE2ZTJmNTU+XSBhcnBfcHJvY2VzcysweDJlNS8weDcwMA0KWyAgMzAwLjE0ODcyNV0g
IFs8ZmZmZmZmZmY4MTBhZDM0NT5dID8gZGVidWdfY2hlY2tfbm9fbG9ja3NfZnJlZWQrMHgx
MTUvMHgxZDANClsgIDMwMC4xNDg3NTFdICBbPGZmZmZmZmZmODE2ZTM0NDU+XSBhcnBfcmN2
KzB4ZDUvMHgxNDANClsgIDMwMC4xNDg3NzNdICBbPGZmZmZmZmZmODE2MWFjOGQ+XSBfX25l
dGlmX3JlY2VpdmVfc2tiKzB4NjVkLzB4OGQwDQpbICAzMDAuMTQ4Nzk2XSAgWzxmZmZmZmZm
ZjgxNjFhNzc1Pl0gPyBfX25ldGlmX3JlY2VpdmVfc2tiKzB4MTQ1LzB4OGQwDQpbICAzMDAu
MTQ4ODIwXSAgWzxmZmZmZmZmZjgxMGFkMjJkPl0gPyB0cmFjZV9oYXJkaXJxc19vbisweGQv
MHgxMA0KWyAgMzAwLjE0ODg0NV0gIFs8ZmZmZmZmZmY4MTBmOTk3Mz5dID8gZnJlZV9ob3Rf
Y29sZF9wYWdlKzB4MWIzLzB4MWUwDQpbICAzMDAuMTQ4ODcwXSAgWzxmZmZmZmZmZjgxNjFk
MWY4Pl0gbmV0aWZfcmVjZWl2ZV9za2IrMHgyOC8weGYwDQpbICAzMDAuMTQ4ODk2XSAgWzxm
ZmZmZmZmZjgxNjEyZDAzPl0gPyBfX3Bza2JfcHVsbF90YWlsKzB4MjUzLzB4MzQwDQpbICAz
MDAuMTQ4OTIwXSAgWzxmZmZmZmZmZjgxNDZlNGM1Pl0geGVubmV0X3BvbGwrMHhhZDUvMHhl
MTANClsgIDMwMC4xNDg5NDddICBbPGZmZmZmZmZmODE2MWRmYTY+XSBuZXRfcnhfYWN0aW9u
KzB4MTM2LzB4MjYwDQpbICAzMDAuMTQ4OTcxXSAgWzxmZmZmZmZmZjgxMDZlMzgxPl0gPyBf
X2RvX3NvZnRpcnErMHg3MS8weDFhMA0KWyAgMzAwLjE0ODk5NV0gIFs8ZmZmZmZmZmY4MTA2
ZTNkOT5dIF9fZG9fc29mdGlycSsweGM5LzB4MWEwDQpbICAzMDAuMTQ5MDE5XSAgWzxmZmZm
ZmZmZjgxNzQ4ZDNjPl0gY2FsbF9zb2Z0aXJxKzB4MWMvMHgzMA0KWyAgMzAwLjE0OTA0Ml0g
IFs8ZmZmZmZmZmY4MTAwZWRiNT5dIGRvX3NvZnRpcnErMHg4NS8weGYwDQpbICAzMDAuMTQ5
MDY0XSAgWzxmZmZmZmZmZjgxMDZlMjRlPl0gaXJxX2V4aXQrMHg5ZS8weGQwDQpbICAzMDAu
MTQ5MDg5XSAgWzxmZmZmZmZmZjgxMzM5ZjVmPl0geGVuX2V2dGNobl9kb191cGNhbGwrMHgy
Zi8weDQwDQpbICAzMDAuMTQ5MTEzXSAgWzxmZmZmZmZmZjgxNzQ4ZDllPl0geGVuX2RvX2h5
cGVydmlzb3JfY2FsbGJhY2srMHgxZS8weDMwDQpbICAzMDAuMTQ5MTMzXSAgPEVPST4gIFs8
ZmZmZmZmZmY4MTAwMTNhYT5dID8geGVuX2h5cGVyY2FsbF9zY2hlZF9vcCsweGEvMHgyMA0K
WyAgMzAwLjE0OTE3Ml0gIFs8ZmZmZmZmZmY4MTAwMTNhYT5dID8geGVuX2h5cGVyY2FsbF9z
Y2hlZF9vcCsweGEvMHgyMA0KWyAgMzAwLjE0OTE5OF0gIFs8ZmZmZmZmZmY4MTAwODY5MD5d
ID8geGVuX3NhZmVfaGFsdCsweDEwLzB4MjANClsgIDMwMC4xNDkyMjJdICBbPGZmZmZmZmZm
ODEwMTYwZDA+XSA/IGRlZmF1bHRfaWRsZSsweDQwLzB4OTANClsgIDMwMC4xNDkyNDVdICBb
PGZmZmZmZmZmODEwMTY0ODY+XSA/IGNwdV9pZGxlKzB4OTYvMHhmMA0KWyAgMzAwLjE0OTI2
N10gIFs8ZmZmZmZmZmY4MTcyMmQzYz5dID8gcmVzdF9pbml0KzB4YmMvMHhkMA0KWyAgMzAw
LjE0OTI4OF0gIFs8ZmZmZmZmZmY4MTcyMmM4MD5dID8gY3N1bV9wYXJ0aWFsX2NvcHlfZ2Vu
ZXJpYysweDE3MC8weDE3MA0KWyAgMzAwLjE0OTMxNl0gIFs8ZmZmZmZmZmY4MWNlMGRmMj5d
ID8gc3RhcnRfa2VybmVsKzB4MzkwLzB4MzlkDQpbICAzMDAuMTQ5MzQwXSAgWzxmZmZmZmZm
ZjgxY2UwODgyPl0gPyBrZXJuZWxfaW5pdCsweDIwYi8weDIwYg0KWyAgMzAwLjE0OTM2NF0g
IFs8ZmZmZmZmZmY4MWNlMDM1Nj5dID8geDg2XzY0X3N0YXJ0X3Jlc2VydmF0aW9ucysweDEz
MS8weDEzNg0KWyAgMzAwLjE0OTM5MV0gIFs8ZmZmZmZmZmY4MWNlM2Q2MD5dID8geGVuX3N0
YXJ0X2tlcm5lbCsweDcwZC8weDcwZg0KWyAgMzAwLjE0OTQxM10gLS0tWyBlbmQgdHJhY2Ug
MmUyOGVlYzkzYjdhOGI4NCBdLS0tDQpbICAzMTIuNTkxMTMyXSAtLS0tLS0tLS0tLS1bIGN1
dCBoZXJlIF0tLS0tLS0tLS0tLS0NClsgIDMxMi41OTExNjRdIFdBUk5JTkc6IGF0IGRyaXZl
cnMvbmV0L3hlbi1uZXRmcm9udC5jOjQ2NSB4ZW5uZXRfc3RhcnRfeG1pdCsweDdmZS8weDg2
MCgpDQpbICAzMTIuNTkxMTcxXSBNb2R1bGVzIGxpbmtlZCBpbjoNClsgIDMxMi41OTExNzdd
IFBpZDogMjE1OSwgY29tbTogc3NoZCBUYWludGVkOiBHICAgICAgICBXICAgIDMuNi4wcHJl
LXJjMS0yMDEyMTAxMSAjMQ0KWyAgMzEyLjU5MTE4M10gQ2FsbCBUcmFjZToNClsgIDMxMi41
OTExOTFdICBbPGZmZmZmZmZmODEwNjY0ZWE+XSB3YXJuX3Nsb3dwYXRoX2NvbW1vbisweDdh
LzB4YjANClsgIDMxMi41OTEyMTNdICBbPGZmZmZmZmZmODEwNjY1MzU+XSB3YXJuX3Nsb3dw
YXRoX251bGwrMHgxNS8weDIwDQpbICAzMTIuNTkxMjE5XSAgWzxmZmZmZmZmZjgxNDZkODll
Pl0geGVubmV0X3N0YXJ0X3htaXQrMHg3ZmUvMHg4NjANClsgIDMxMi41OTEyMjZdICBbPGZm
ZmZmZmZmODE2MWYzNDk+XSBkZXZfaGFyZF9zdGFydF94bWl0KzB4MjA5LzB4NDYwDQpbICAz
MTIuNTkxMjMzXSAgWzxmZmZmZmZmZjgxNjNiMDM2Pl0gc2NoX2RpcmVjdF94bWl0KzB4ZjYv
MHgyOTANClsgIDMxMi41OTEyMzldICBbPGZmZmZmZmZmODE2MWY3NDY+XSBkZXZfcXVldWVf
eG1pdCsweDFhNi8weDVhMA0KWyAgMzEyLjU5MTI0NF0gIFs8ZmZmZmZmZmY4MTYxZjVhMD5d
ID8gZGV2X2hhcmRfc3RhcnRfeG1pdCsweDQ2MC8weDQ2MA0KWyAgMzEyLjU5MTI1MV0gIFs8
ZmZmZmZmZmY4MTBhYThlNT5dID8gdHJhY2Vfc29mdGlycXNfb2ZmKzB4ODUvMHgxYjANClsg
IDMxMi41OTEyNTldICBbPGZmZmZmZmZmODE2Yjk1MzY+XSBpcF9maW5pc2hfb3V0cHV0KzB4
MjI2LzB4NTMwDQpbICAzMTIuNTkxMjY0XSAgWzxmZmZmZmZmZjgxNmI5M2RkPl0gPyBpcF9m
aW5pc2hfb3V0cHV0KzB4Y2QvMHg1MzANClsgIDMxMi41OTEyNzBdICBbPGZmZmZmZmZmODE2
Yjk4OTk+XSBpcF9vdXRwdXQrMHg1OS8weGUwDQpbICAzMTIuNTkxMjc2XSAgWzxmZmZmZmZm
ZjgxNmI4M2I4Pl0gaXBfbG9jYWxfb3V0KzB4MjgvMHg5MA0KWyAgMzEyLjU5MTI4MV0gIFs8
ZmZmZmZmZmY4MTZiODk2Zj5dIGlwX3F1ZXVlX3htaXQrMHgxN2YvMHg0YTANClsgIDMxMi41
OTEyODZdICBbPGZmZmZmZmZmODE2Yjg3ZjA+XSA/IGlwX3NlbmRfdW5pY2FzdF9yZXBseSsw
eDM0MC8weDM0MA0KWyAgMzEyLjU5MTI5M10gIFs8ZmZmZmZmZmY4MTBhMGJhNz5dID8gZ2V0
bnN0aW1lb2ZkYXkrMHg0Ny8weGUwDQpbICAzMTIuNTkxMjk5XSAgWzxmZmZmZmZmZjgxNjBm
NGM5Pl0gPyBfX3NrYl9jbG9uZSsweDI5LzB4MTIwDQpbICAzMTIuNTkxMzA2XSAgWzxmZmZm
ZmZmZjgxNmNlYTIwPl0gdGNwX3RyYW5zbWl0X3NrYisweDQwMC8weDhkMA0KWyAgMzEyLjU5
MTMxMl0gIFs8ZmZmZmZmZmY4MTZkMTlmYT5dIHRjcF93cml0ZV94bWl0KzB4MjFhLzB4YTUw
DQpbICAzMTIuNTkxMzE3XSAgWzxmZmZmZmZmZjgxNmQyMjViPl0gdGNwX3B1c2hfb25lKzB4
MmIvMHg0MA0KWyAgMzEyLjU5MTMyNF0gIFs8ZmZmZmZmZmY4MTZjMmRlYz5dIHRjcF9zZW5k
bXNnKzB4OGRjLzB4ZTIwDQpbICAzMTIuNTkxMzMxXSAgWzxmZmZmZmZmZjgxNmU4ZjE5Pl0g
aW5ldF9zZW5kbXNnKzB4YTkvMHgxMDANClsgIDMxMi41OTEzMzZdICBbPGZmZmZmZmZmODE2
ZThlNzA+XSA/IGluZXRfYXV0b2JpbmQrMHg3MC8weDcwDQpbICAzMTIuNTkxMzQyXSAgWzxm
ZmZmZmZmZjgxMGIwZjg4Pl0gPyBsb2NrX2FjcXVpcmUrMHhkOC8weDEwMA0KWyAgMzEyLjU5
MTM0OV0gIFs8ZmZmZmZmZmY4MTYwNjMwZD5dIHNvY2tfYWlvX3dyaXRlKzB4MTJkLzB4MTQw
DQpbICAzMTIuNTkxMzU2XSAgWzxmZmZmZmZmZjgxMTQzNWIyPl0gZG9fc3luY193cml0ZSsw
eGEyLzB4ZTANClsgIDMxMi41OTEzNjVdICBbPGZmZmZmZmZmODEwYWQyMmQ+XSA/IHRyYWNl
X2hhcmRpcnFzX29uKzB4ZC8weDEwDQpbICAzMTIuNTkxMzcxXSAgWzxmZmZmZmZmZjgxMTQ0
MWQ0Pl0gdmZzX3dyaXRlKzB4MTc0LzB4MTkwDQpbICAzMTIuNTkxMzc2XSAgWzxmZmZmZmZm
ZjgxMTQ0MmZhPl0gc3lzX3dyaXRlKzB4NWEvMHhhMA0KWyAgMzEyLjU5MTM4M10gIFs8ZmZm
ZmZmZmY4MTJiMzNkZT5dID8gdHJhY2VfaGFyZGlycXNfb25fdGh1bmsrMHgzYS8weDNmDQpb
ICAzMTIuNTkxMzkxXSAgWzxmZmZmZmZmZjgxNzQ5MWNjPl0gY3N0YXJfZGlzcGF0Y2grMHg3
LzB4MjYNClsgIDMxMi41OTEzOTZdIC0tLVsgZW5kIHRyYWNlIDJlMjhlZWM5M2I3YThiODUg
XS0tLQ0KWyAgMzEyLjU5MTQyOV0gLS0tLS0tLS0tLS0tWyBjdXQgaGVyZSBdLS0tLS0tLS0t
LS0tDQpbICAzMTIuNTkxNDM1XSBXQVJOSU5HOiBhdCBkcml2ZXJzL25ldC94ZW4tbmV0ZnJv
bnQuYzo0NjUgeGVubmV0X3N0YXJ0X3htaXQrMHg3ZmUvMHg4NjAoKQ0KWyAgMzEyLjU5MTQ0
MV0gTW9kdWxlcyBsaW5rZWQgaW46DQpbICAzMTIuNTkxNDQ1XSBQaWQ6IDIxNTksIGNvbW06
IHNzaGQgVGFpbnRlZDogRyAgICAgICAgVyAgICAzLjYuMHByZS1yYzEtMjAxMjEwMTEgIzEN
ClsgIDMxMi41OTE0NTFdIENhbGwgVHJhY2U6DQpbICAzMTIuNTkxNDU3XSAgWzxmZmZmZmZm
ZjgxMDY2NGVhPl0gd2Fybl9zbG93cGF0aF9jb21tb24rMHg3YS8weGIwDQpbICAzMTIuNTkx
NDYzXSAgWzxmZmZmZmZmZjgxMDY2NTM1Pl0gd2Fybl9zbG93cGF0aF9udWxsKzB4MTUvMHgy
MA0KWyAgMzEyLjU5MTQ2OF0gIFs8ZmZmZmZmZmY4MTQ2ZDg5ZT5dIHhlbm5ldF9zdGFydF94
bWl0KzB4N2ZlLzB4ODYwDQpbICAzMTIuNTkxNDc1XSAgWzxmZmZmZmZmZjgxNjFmMzQ5Pl0g
ZGV2X2hhcmRfc3RhcnRfeG1pdCsweDIwOS8weDQ2MA0KWyAgMzEyLjU5MTQ4MV0gIFs8ZmZm
ZmZmZmY4MTYzYjAzNj5dIHNjaF9kaXJlY3RfeG1pdCsweGY2LzB4MjkwDQpbICAzMTIuNTkx
NDg3XSAgWzxmZmZmZmZmZjgxNjFmNzQ2Pl0gZGV2X3F1ZXVlX3htaXQrMHgxYTYvMHg1YTAN
ClsgIDMxMi41OTE0OTJdICBbPGZmZmZmZmZmODE2MWY1YTA+XSA/IGRldl9oYXJkX3N0YXJ0
X3htaXQrMHg0NjAvMHg0NjANClsgIDMxMi41OTE0OThdICBbPGZmZmZmZmZmODEwYWE4ZTU+
XSA/IHRyYWNlX3NvZnRpcnFzX29mZisweDg1LzB4MWIwDQpbICAzMTIuNTkxNTA0XSAgWzxm
ZmZmZmZmZjgxNmI5NTM2Pl0gaXBfZmluaXNoX291dHB1dCsweDIyNi8weDUzMA0KWyAgMzEy
LjU5MTUxMF0gIFs8ZmZmZmZmZmY4MTZiOTNkZD5dID8gaXBfZmluaXNoX291dHB1dCsweGNk
LzB4NTMwDQpbICAzMTIuNTkxNTE2XSAgWzxmZmZmZmZmZjgxNmI5ODk5Pl0gaXBfb3V0cHV0
KzB4NTkvMHhlMA0KWyAgMzEyLjU5MTUyMV0gIFs8ZmZmZmZmZmY4MTZiODNiOD5dIGlwX2xv
Y2FsX291dCsweDI4LzB4OTANClsgIDMxMi41OTE1MjZdICBbPGZmZmZmZmZmODE2Yjg5NmY+
XSBpcF9xdWV1ZV94bWl0KzB4MTdmLzB4NGEwDQpbICAzMTIuNTkxNTMyXSAgWzxmZmZmZmZm
ZjgxNmI4N2YwPl0gPyBpcF9zZW5kX3VuaWNhc3RfcmVwbHkrMHgzNDAvMHgzNDANClsgIDMx
Mi41OTE1MzhdICBbPGZmZmZmZmZmODEwYTBiYTc+XSA/IGdldG5zdGltZW9mZGF5KzB4NDcv
MHhlMA0KWyAgMzEyLjU5MTU0NF0gIFs8ZmZmZmZmZmY4MTYwZjRjOT5dID8gX19za2JfY2xv
bmUrMHgyOS8weDEyMA0KWyAgMzEyLjU5MTU0OV0gIFs8ZmZmZmZmZmY4MTZjZWEyMD5dIHRj
cF90cmFuc21pdF9za2IrMHg0MDAvMHg4ZDANClsgIDMxMi41OTE1NTVdICBbPGZmZmZmZmZm
ODE2ZDE5ZmE+XSB0Y3Bfd3JpdGVfeG1pdCsweDIxYS8weGE1MA0KWyAgMzEyLjU5MTU2MF0g
IFs8ZmZmZmZmZmY4MTZkMjI5ZD5dIF9fdGNwX3B1c2hfcGVuZGluZ19mcmFtZXMrMHgyZC8w
eDkwDQpbICAzMTIuNTkxNTY2XSAgWzxmZmZmZmZmZjgxNmMyNjkzPl0gdGNwX3NlbmRtc2cr
MHgxODMvMHhlMjANClsgIDMxMi41OTE1NzJdICBbPGZmZmZmZmZmODE2ZThmMTk+XSBpbmV0
X3NlbmRtc2crMHhhOS8weDEwMA0KWyAgMzEyLjU5MTU3OF0gIFs8ZmZmZmZmZmY4MTZlOGU3
MD5dID8gaW5ldF9hdXRvYmluZCsweDcwLzB4NzANClsgIDMxMi41OTE1ODNdICBbPGZmZmZm
ZmZmODEwYjBmODg+XSA/IGxvY2tfYWNxdWlyZSsweGQ4LzB4MTAwDQpbICAzMTIuNTkxNTg4
XSAgWzxmZmZmZmZmZjgxNjA2MzBkPl0gc29ja19haW9fd3JpdGUrMHgxMmQvMHgxNDANClsg
IDMxMi41OTE1OTRdICBbPGZmZmZmZmZmODExNDM1YjI+XSBkb19zeW5jX3dyaXRlKzB4YTIv
MHhlMA0KWyAgMzEyLjU5MTYwMF0gIFs8ZmZmZmZmZmY4MTBhZDIyZD5dID8gdHJhY2VfaGFy
ZGlycXNfb24rMHhkLzB4MTANClsgIDMxMi41OTE2MDZdICBbPGZmZmZmZmZmODExNDQxZDQ+
XSB2ZnNfd3JpdGUrMHgxNzQvMHgxOTANClsgIDMxMi41OTE2MTFdICBbPGZmZmZmZmZmODEx
NDQyZmE+XSBzeXNfd3JpdGUrMHg1YS8weGEwDQpbICAzMTIuNTkxNjE3XSAgWzxmZmZmZmZm
ZjgxMmIzM2RlPl0gPyB0cmFjZV9oYXJkaXJxc19vbl90aHVuaysweDNhLzB4M2YNClsgIDMx
Mi41OTE2MjNdICBbPGZmZmZmZmZmODE3NDkxY2M+XSBjc3Rhcl9kaXNwYXRjaCsweDcvMHgy
Ng0KWyAgMzEyLjU5MTYyN10gLS0tWyBlbmQgdHJhY2UgMmUyOGVlYzkzYjdhOGI4NiBdLS0t
DQpbICAzMTIuNTkxNjQ1XSAtLS0tLS0tLS0tLS1bIGN1dCBoZXJlIF0tLS0tLS0tLS0tLS0N
ClsgIDMxMi41OTE2NTFdIFdBUk5JTkc6IGF0IGRyaXZlcnMvbmV0L3hlbi1uZXRmcm9udC5j
OjQ2NSB4ZW5uZXRfc3RhcnRfeG1pdCsweDdmZS8weDg2MCgpDQpbICAzMTIuNTkxNjU3XSBN
b2R1bGVzIGxpbmtlZCBpbjoNClsgIDMxMi41OTE2NjJdIFBpZDogMjE1OSwgY29tbTogc3No
ZCBUYWludGVkOiBHICAgICAgICBXICAgIDMuNi4wcHJlLXJjMS0yMDEyMTAxMSAjMQ0KWyAg
MzEyLjU5MTY2N10gQ2FsbCBUcmFjZToNClsgIDMxMi41OTE2NzFdICBbPGZmZmZmZmZmODEw
NjY0ZWE+XSB3YXJuX3Nsb3dwYXRoX2NvbW1vbisweDdhLzB4YjANClsgIDMxMi41OTE2Nzdd
ICBbPGZmZmZmZmZmODEwNjY1MzU+XSB3YXJuX3Nsb3dwYXRoX251bGwrMHgxNS8weDIwDQpb
ICAzMTIuNTkxNjgyXSAgWzxmZmZmZmZmZjgxNDZkODllPl0geGVubmV0X3N0YXJ0X3htaXQr
MHg3ZmUvMHg4NjANClsgIDMxMi41OTE2ODhdICBbPGZmZmZmZmZmODE2MWYzNDk+XSBkZXZf
aGFyZF9zdGFydF94bWl0KzB4MjA5LzB4NDYwDQpbICAzMTIuNTkxNjk0XSAgWzxmZmZmZmZm
ZjgxNjNiMDM2Pl0gc2NoX2RpcmVjdF94bWl0KzB4ZjYvMHgyOTANClsgIDMxMi41OTE3MDBd
ICBbPGZmZmZmZmZmODE2MWY3NDY+XSBkZXZfcXVldWVfeG1pdCsweDFhNi8weDVhMA0KWyAg
MzEyLjU5MTcwNV0gIFs8ZmZmZmZmZmY4MTYxZjVhMD5dID8gZGV2X2hhcmRfc3RhcnRfeG1p
dCsweDQ2MC8weDQ2MA0KWyAgMzEyLjU5MTcxMV0gIFs8ZmZmZmZmZmY4MTBhYThlNT5dID8g
dHJhY2Vfc29mdGlycXNfb2ZmKzB4ODUvMHgxYjANClsgIDMxMi41OTE3MTddICBbPGZmZmZm
ZmZmODE2Yjk1MzY+XSBpcF9maW5pc2hfb3V0cHV0KzB4MjI2LzB4NTMwDQpbICAzMTIuNTkx
NzI2XSAgWzxmZmZmZmZmZjgxNmI5M2RkPl0gPyBpcF9maW5pc2hfb3V0cHV0KzB4Y2QvMHg1
MzANClsgIDMxMi41OTE3MzJdICBbPGZmZmZmZmZmODE2Yjk4OTk+XSBpcF9vdXRwdXQrMHg1
OS8weGUwDQpbICAzMTIuNTkxNzM3XSAgWzxmZmZmZmZmZjgxNmI4M2I4Pl0gaXBfbG9jYWxf
b3V0KzB4MjgvMHg5MA0KWyAgMzEyLjU5MTc0M10gIFs8ZmZmZmZmZmY4MTZiODk2Zj5dIGlw
X3F1ZXVlX3htaXQrMHgxN2YvMHg0YTANClsgIDMxMi41OTE3NDhdICBbPGZmZmZmZmZmODE2
Yjg3ZjA+XSA/IGlwX3NlbmRfdW5pY2FzdF9yZXBseSsweDM0MC8weDM0MA0KWyAgMzEyLjU5
MTc1NF0gIFs8ZmZmZmZmZmY4MTBhMGJhNz5dID8gZ2V0bnN0aW1lb2ZkYXkrMHg0Ny8weGUw
DQpbICAzMTIuNTkxNzU5XSAgWzxmZmZmZmZmZjgxNjBmNGM5Pl0gPyBfX3NrYl9jbG9uZSsw
eDI5LzB4MTIwDQpbICAzMTIuNTkxNzY1XSAgWzxmZmZmZmZmZjgxNmNlYTIwPl0gdGNwX3Ry
YW5zbWl0X3NrYisweDQwMC8weDhkMA0KWyAgMzEyLjU5MTc3MF0gIFs8ZmZmZmZmZmY4MTZk
MTlmYT5dIHRjcF93cml0ZV94bWl0KzB4MjFhLzB4YTUwDQpbICAzMTIuNTkxNzc2XSAgWzxm
ZmZmZmZmZjgxNmQyMjlkPl0gX190Y3BfcHVzaF9wZW5kaW5nX2ZyYW1lcysweDJkLzB4OTAN
ClsgIDMxMi41OTE3ODJdICBbPGZmZmZmZmZmODE2YzI2OTM+XSB0Y3Bfc2VuZG1zZysweDE4
My8weGUyMA0KWyAgMzEyLjU5MTc4OF0gIFs8ZmZmZmZmZmY4MTZlOGYxOT5dIGluZXRfc2Vu
ZG1zZysweGE5LzB4MTAwDQpbICAzMTIuNTkxNzkzXSAgWzxmZmZmZmZmZjgxNmU4ZTcwPl0g
PyBpbmV0X2F1dG9iaW5kKzB4NzAvMHg3MA0KWyAgMzEyLjU5MTc5OV0gIFs8ZmZmZmZmZmY4
MTBiMGY4OD5dID8gbG9ja19hY3F1aXJlKzB4ZDgvMHgxMDANClsgIDMxMi41OTE4MDRdICBb
PGZmZmZmZmZmODE2MDYzMGQ+XSBzb2NrX2Fpb193cml0ZSsweDEyZC8weDE0MA0KWyAgMzEy
LjU5MTgxMF0gIFs8ZmZmZmZmZmY4MTE0MzViMj5dIGRvX3N5bmNfd3JpdGUrMHhhMi8weGUw
DQpbICAzMTIuNTkxODE2XSAgWzxmZmZmZmZmZjgxMGFkMjJkPl0gPyB0cmFjZV9oYXJkaXJx
c19vbisweGQvMHgxMA0KWyAgMzEyLjU5MTgyMl0gIFs8ZmZmZmZmZmY4MTE0NDFkND5dIHZm
c193cml0ZSsweDE3NC8weDE5MA0KWyAgMzEyLjU5MTgyN10gIFs8ZmZmZmZmZmY4MTE0NDJm
YT5dIHN5c193cml0ZSsweDVhLzB4YTANClsgIDMxMi41OTE4MzNdICBbPGZmZmZmZmZmODEy
YjMzZGU+XSA/IHRyYWNlX2hhcmRpcnFzX29uX3RodW5rKzB4M2EvMHgzZg0KWyAgMzEyLjU5
MTgzOV0gIFs8ZmZmZmZmZmY4MTc0OTFjYz5dIGNzdGFyX2Rpc3BhdGNoKzB4Ny8weDI2DQpb
ICAzMTIuNTkxODQzXSAtLS1bIGVuZCB0cmFjZSAyZTI4ZWVjOTNiN2E4Yjg3IF0tLS0NClsg
IDMxMy4wNDg0MzFdIC0tLS0tLS0tLS0tLVsgY3V0IGhlcmUgXS0tLS0tLS0tLS0tLQ0KWyAg
MzEzLjA0ODQ4N10gV0FSTklORzogYXQgZHJpdmVycy9uZXQveGVuLW5ldGZyb250LmM6NDY1
IHhlbm5ldF9zdGFydF94bWl0KzB4N2ZlLzB4ODYwKCkNClsgIDMxMy4wNDg1MTRdIE1vZHVs
ZXMgbGlua2VkIGluOg0KWyAgMzEzLjA0ODUzNl0gUGlkOiAwLCBjb21tOiBzd2FwcGVyLzAg
VGFpbnRlZDogRyAgICAgICAgVyAgICAzLjYuMHByZS1yYzEtMjAxMjEwMTEgIzENClsgIDMx
My4wNDg1NjBdIENhbGwgVHJhY2U6DQpbICAzMTMuMDQ4NTczXSAgPElSUT4gIFs8ZmZmZmZm
ZmY4MTA2NjRlYT5dIHdhcm5fc2xvd3BhdGhfY29tbW9uKzB4N2EvMHhiMA0KWyAgMzEzLjA0
ODYxNF0gIFs8ZmZmZmZmZmY4MTA2NjUzNT5dIHdhcm5fc2xvd3BhdGhfbnVsbCsweDE1LzB4
MjANClsgIDMxMy4wNDg2MzhdICBbPGZmZmZmZmZmODE0NmQ4OWU+XSB4ZW5uZXRfc3RhcnRf
eG1pdCsweDdmZS8weDg2MA0KWyAgMzEzLjA0ODY2NV0gIFs8ZmZmZmZmZmY4MTYxZjM0OT5d
IGRldl9oYXJkX3N0YXJ0X3htaXQrMHgyMDkvMHg0NjANClsgIDMxMy4wNDg2ODldICBbPGZm
ZmZmZmZmODE2M2IwMzY+XSBzY2hfZGlyZWN0X3htaXQrMHhmNi8weDI5MA0KWyAgMzEzLjA0
ODcxMV0gIFs8ZmZmZmZmZmY4MTYxZjc0Nj5dIGRldl9xdWV1ZV94bWl0KzB4MWE2LzB4NWEw
DQpbICAzMTMuMDQ4NzM0XSAgWzxmZmZmZmZmZjgxNjFmNWEwPl0gPyBkZXZfaGFyZF9zdGFy
dF94bWl0KzB4NDYwLzB4NDYwDQpbICAzMTMuMDQ4NzU4XSAgWzxmZmZmZmZmZjgxMGIxNDE3
Pl0gPyBsb2NrX3JlbGVhc2UrMHgxMTcvMHgyNTANClsgIDMxMy4wNDg3ODNdICBbPGZmZmZm
ZmZmODE2Yjk1MzY+XSBpcF9maW5pc2hfb3V0cHV0KzB4MjI2LzB4NTMwDQpbICAzMTMuMDQ4
ODA2XSAgWzxmZmZmZmZmZjgxNmI5M2RkPl0gPyBpcF9maW5pc2hfb3V0cHV0KzB4Y2QvMHg1
MzANClsgIDMxMy4wNDg4MjldICBbPGZmZmZmZmZmODE2Yjk4OTk+XSBpcF9vdXRwdXQrMHg1
OS8weGUwDQpbICAzMTMuMDQ4ODUwXSAgWzxmZmZmZmZmZjgxNmI4M2I4Pl0gaXBfbG9jYWxf
b3V0KzB4MjgvMHg5MA0KWyAgMzEzLjA0ODg3Ml0gIFs8ZmZmZmZmZmY4MTZiODk2Zj5dIGlw
X3F1ZXVlX3htaXQrMHgxN2YvMHg0YTANClsgIDMxMy4wNDg4OTZdICBbPGZmZmZmZmZmODE2
Yjg3ZjA+XSA/IGlwX3NlbmRfdW5pY2FzdF9yZXBseSsweDM0MC8weDM0MA0KWyAgMzEzLjA0
ODkyMF0gIFs8ZmZmZmZmZmY4MTBhMGJhNz5dID8gZ2V0bnN0aW1lb2ZkYXkrMHg0Ny8weGUw
DQpbICAzMTMuMDQ4OTQzXSAgWzxmZmZmZmZmZjgxNjBmNGM5Pl0gPyBfX3NrYl9jbG9uZSsw
eDI5LzB4MTIwDQpbICAzMTMuMDQ4OTY1XSAgWzxmZmZmZmZmZjgxNmNlYTIwPl0gdGNwX3Ry
YW5zbWl0X3NrYisweDQwMC8weDhkMA0KWyAgMzEzLjA0ODk4OF0gIFs8ZmZmZmZmZmY4MTZk
MTEwNj5dIHRjcF9yZXRyYW5zbWl0X3NrYisweDFjNi8weDVhMA0KWyAgMzEzLjA0OTAxMV0g
IFs8ZmZmZmZmZmY4MTZkMTY3ZT5dIHRjcF94bWl0X3JldHJhbnNtaXRfcXVldWUrMHgxOWUv
MHgzMDANClsgIDMxMy4wNDkwMzRdICBbPGZmZmZmZmZmODE2Yzk5ZmY+XSB0Y3BfZmFzdHJl
dHJhbnNfYWxlcnQrMHg5NGYvMHhjYjANClsgIDMxMy4wNDkwNTddICBbPGZmZmZmZmZmODE2
Y2E3MGM+XSB0Y3BfYWNrKzB4OWFjLzB4MTE1MA0KWyAgMzEzLjA0OTA3OV0gIFs8ZmZmZmZm
ZmY4MTZjZDg1OD5dIHRjcF9yY3ZfZXN0YWJsaXNoZWQrMHgzMTgvMHg2NDANClsgIDMxMy4w
NDkxMDJdICBbPGZmZmZmZmZmODE2ZDVlZWY+XSA/IHRjcF92NF9yY3YrMHg2Y2YvMHhiMTAN
ClsgIDMxMy4wNDkxMjNdICBbPGZmZmZmZmZmODE2ZDU0ZDU+XSB0Y3BfdjRfZG9fcmN2KzB4
MTM1LzB4NDgwDQpbICAzMTMuMDQ5MTQ3XSAgWzxmZmZmZmZmZjgxNzQ2MWQyPl0gPyBfcmF3
X3NwaW5fbG9ja19uZXN0ZWQrMHg0Mi8weDUwDQpbICAzMTMuMDQ5MTY5XSAgWzxmZmZmZmZm
ZjgxNmQ1ZWVmPl0gPyB0Y3BfdjRfcmN2KzB4NmNmLzB4YjEwDQpbICAzMTMuMDQ5MTkxXSAg
WzxmZmZmZmZmZjgxNmQ2MTdkPl0gdGNwX3Y0X3JjdisweDk1ZC8weGIxMA0KWyAgMzEzLjA0
OTIxMl0gIFs8ZmZmZmZmZmY4MTBiMGY4OD5dID8gbG9ja19hY3F1aXJlKzB4ZDgvMHgxMDAN
ClsgIDMxMy4wNDkyMzNdICBbPGZmZmZmZmZmODE2YjI5OTU+XSA/IGlwX2xvY2FsX2RlbGl2
ZXJfZmluaXNoKzB4NDUvMHgyMzANClsgIDMxMy4wNDkyNTddICBbPGZmZmZmZmZmODE2YjJh
NmE+XSBpcF9sb2NhbF9kZWxpdmVyX2ZpbmlzaCsweDExYS8weDIzMA0KWyAgMzEzLjA0OTI4
MF0gIFs8ZmZmZmZmZmY4MTZiMjk5NT5dID8gaXBfbG9jYWxfZGVsaXZlcl9maW5pc2grMHg0
NS8weDIzMA0KWyAgMzEzLjA0OTMwNF0gIFs8ZmZmZmZmZmY4MTZiMmJiOD5dIGlwX2xvY2Fs
X2RlbGl2ZXIrMHgzOC8weDgwDQpbICAzMTMuMDQ5MzI2XSAgWzxmZmZmZmZmZjgxNmIyMTdh
Pl0gaXBfcmN2X2ZpbmlzaCsweDE1YS8weDYzMA0KWyAgMzEzLjA0OTM0N10gIFs8ZmZmZmZm
ZmY4MTZiMjg2OD5dIGlwX3JjdisweDIxOC8weDMwMA0KWyAgMzEzLjA0OTM2OF0gIFs8ZmZm
ZmZmZmY4MTYxYWM4ZD5dIF9fbmV0aWZfcmVjZWl2ZV9za2IrMHg2NWQvMHg4ZDANClsgIDMx
My4wNDkzOTNdICBbPGZmZmZmZmZmODE2MWE3NzU+XSA/IF9fbmV0aWZfcmVjZWl2ZV9za2Ir
MHgxNDUvMHg4ZDANClsgIDMxMy4wNDk0MTZdICBbPGZmZmZmZmZmODEwYWQyMmQ+XSA/IHRy
YWNlX2hhcmRpcnFzX29uKzB4ZC8weDEwDQpbICAzMTMuMDQ5NDQwXSAgWzxmZmZmZmZmZjgx
MGY5OTczPl0gPyBmcmVlX2hvdF9jb2xkX3BhZ2UrMHgxYjMvMHgxZTANClsgIDMxMy4wNDk0
NjNdICBbPGZmZmZmZmZmODE2MWQxZjg+XSBuZXRpZl9yZWNlaXZlX3NrYisweDI4LzB4ZjAN
ClsgIDMxMy4wNDk0ODZdICBbPGZmZmZmZmZmODE2MTJkMDM+XSA/IF9fcHNrYl9wdWxsX3Rh
aWwrMHgyNTMvMHgzNDANClsgIDMxMy4wNDk1MDhdICBbPGZmZmZmZmZmODE0NmU0YzU+XSB4
ZW5uZXRfcG9sbCsweGFkNS8weGUxMA0KWyAgMzEzLjA0OTUzNF0gIFs8ZmZmZmZmZmY4MTYx
ZGZhNj5dIG5ldF9yeF9hY3Rpb24rMHgxMzYvMHgyNjANClsgIDMxMy4wNDk1NTddICBbPGZm
ZmZmZmZmODEwNmUzODE+XSA/IF9fZG9fc29mdGlycSsweDcxLzB4MWEwDQpbICAzMTMuMDQ5
NTc5XSAgWzxmZmZmZmZmZjgxMDZlM2Q5Pl0gX19kb19zb2Z0aXJxKzB4YzkvMHgxYTANClsg
IDMxMy4wNDk2MDJdICBbPGZmZmZmZmZmODE3NDhkM2M+XSBjYWxsX3NvZnRpcnErMHgxYy8w
eDMwDQpbICAzMTMuMDQ5NjIzXSAgWzxmZmZmZmZmZjgxMDBlZGI1Pl0gZG9fc29mdGlycSsw
eDg1LzB4ZjANClsgIDMxMy4wNDk2NDVdICBbPGZmZmZmZmZmODEwNmUyNGU+XSBpcnFfZXhp
dCsweDllLzB4ZDANClsgIDMxMy4wNDk2NjhdICBbPGZmZmZmZmZmODEzMzlmNWY+XSB4ZW5f
ZXZ0Y2huX2RvX3VwY2FsbCsweDJmLzB4NDANClsgIDMxMy4wNDk2OTBdICBbPGZmZmZmZmZm
ODE3NDhkOWU+XSB4ZW5fZG9faHlwZXJ2aXNvcl9jYWxsYmFjaysweDFlLzB4MzANClsgIDMx
My4wNDk3MDldICA8RU9JPiAgWzxmZmZmZmZmZjgxMDAxM2FhPl0gPyB4ZW5faHlwZXJjYWxs
X3NjaGVkX29wKzB4YS8weDIwDQpbICAzMTMuMDQ5NzQ1XSAgWzxmZmZmZmZmZjgxMDAxM2Fh
Pl0gPyB4ZW5faHlwZXJjYWxsX3NjaGVkX29wKzB4YS8weDIwDQpbICAzMTMuMDQ5NzY5XSAg
WzxmZmZmZmZmZjgxMDA4NjkwPl0gPyB4ZW5fc2FmZV9oYWx0KzB4MTAvMHgyMA0KWyAgMzEz
LjA0OTc5MV0gIFs8ZmZmZmZmZmY4MTAxNjBkMD5dID8gZGVmYXVsdF9pZGxlKzB4NDAvMHg5
MA0KWyAgMzEzLjA0OTgxMl0gIFs8ZmZmZmZmZmY4MTAxNjQ4Nj5dID8gY3B1X2lkbGUrMHg5
Ni8weGYwDQpbICAzMTMuMDQ5ODMyXSAgWzxmZmZmZmZmZjgxNzIyZDNjPl0gPyByZXN0X2lu
aXQrMHhiYy8weGQwDQpbICAzMTMuMDQ5ODUyXSAgWzxmZmZmZmZmZjgxNzIyYzgwPl0gPyBj
c3VtX3BhcnRpYWxfY29weV9nZW5lcmljKzB4MTcwLzB4MTcwDQpbICAzMTMuMDQ5ODc4XSAg
WzxmZmZmZmZmZjgxY2UwZGYyPl0gPyBzdGFydF9rZXJuZWwrMHgzOTAvMHgzOWQNClsgIDMx
My4wNDk5MDFdICBbPGZmZmZmZmZmODFjZTA4ODI+XSA/IGtlcm5lbF9pbml0KzB4MjBiLzB4
MjBiDQpbICAzMTMuMDQ5OTI4XSAgWzxmZmZmZmZmZjgxY2UwMzU2Pl0gPyB4ODZfNjRfc3Rh
cnRfcmVzZXJ2YXRpb25zKzB4MTMxLzB4MTM2DQpbICAzMTMuMDQ5OTUyXSAgWzxmZmZmZmZm
ZjgxY2UzZDYwPl0gPyB4ZW5fc3RhcnRfa2VybmVsKzB4NzBkLzB4NzBmDQpbICAzMTMuMDQ5
OTc0XSAtLS1bIGVuZCB0cmFjZSAyZTI4ZWVjOTNiN2E4Yjg4IF0tLS0NClsgIDMxMy4wNTAw
NTRdIC0tLS0tLS0tLS0tLVsgY3V0IGhlcmUgXS0tLS0tLS0tLS0tLQ0KWyAgMzEzLjA1MDA3
N10gV0FSTklORzogYXQgZHJpdmVycy9uZXQveGVuLW5ldGZyb250LmM6NDY1IHhlbm5ldF9z
dGFydF94bWl0KzB4N2ZlLzB4ODYwKCkNClsgIDMxMy4wNTAxMDJdIE1vZHVsZXMgbGlua2Vk
IGluOg0KWyAgMzEzLjA1MDEyMV0gUGlkOiAwLCBjb21tOiBzd2FwcGVyLzAgVGFpbnRlZDog
RyAgICAgICAgVyAgICAzLjYuMHByZS1yYzEtMjAxMjEwMTEgIzENClsgIDMxMy4wNTAxNDNd
IENhbGwgVHJhY2U6DQpbICAzMTMuMDUwMTUzXSAgPElSUT4gIFs8ZmZmZmZmZmY4MTA2NjRl
YT5dIHdhcm5fc2xvd3BhdGhfY29tbW9uKzB4N2EvMHhiMA0KWyAgMzEzLjA1MDE4N10gIFs8
ZmZmZmZmZmY4MTA2NjUzNT5dIHdhcm5fc2xvd3BhdGhfbnVsbCsweDE1LzB4MjANClsgIDMx
My4wNTAyMTBdICBbPGZmZmZmZmZmODE0NmQ4OWU+XSB4ZW5uZXRfc3RhcnRfeG1pdCsweDdm
ZS8weDg2MA0KWyAgMzEzLjA1MDIzNF0gIFs8ZmZmZmZmZmY4MTYxZjM0OT5dIGRldl9oYXJk
X3N0YXJ0X3htaXQrMHgyMDkvMHg0NjANClsgIDMxMy4wNTAyNTddICBbPGZmZmZmZmZmODE2
M2IwMzY+XSBzY2hfZGlyZWN0X3htaXQrMHhmNi8weDI5MA0KWyAgMzEzLjA1MDI4MF0gIFs8
ZmZmZmZmZmY4MTYxZjc0Nj5dIGRldl9xdWV1ZV94bWl0KzB4MWE2LzB4NWEwDQpbICAzMTMu
MDUwMzAyXSAgWzxmZmZmZmZmZjgxNjFmNWEwPl0gPyBkZXZfaGFyZF9zdGFydF94bWl0KzB4
NDYwLzB4NDYwDQpbICAzMTMuMDUwMzI1XSAgWzxmZmZmZmZmZjgxMGIxNDE3Pl0gPyBsb2Nr
X3JlbGVhc2UrMHgxMTcvMHgyNTANClsgIDMxMy4wNTAzNDhdICBbPGZmZmZmZmZmODE2Yjk1
MzY+XSBpcF9maW5pc2hfb3V0cHV0KzB4MjI2LzB4NTMwDQpbICAzMTMuMDUwMzczXSAgWzxm
ZmZmZmZmZjgxNmI5M2RkPl0gPyBpcF9maW5pc2hfb3V0cHV0KzB4Y2QvMHg1MzANClsgIDMx
My4wNTAzOTddICBbPGZmZmZmZmZmODE2Yjk4OTk+XSBpcF9vdXRwdXQrMHg1OS8weGUwDQpb
ICAzMTMuMDUwNDE4XSAgWzxmZmZmZmZmZjgxNmI4M2I4Pl0gaXBfbG9jYWxfb3V0KzB4Mjgv
MHg5MA0KWyAgMzEzLjA1MDQzOV0gIFs8ZmZmZmZmZmY4MTZiODk2Zj5dIGlwX3F1ZXVlX3ht
aXQrMHgxN2YvMHg0YTANClsgIDMxMy4wNTA0NjFdICBbPGZmZmZmZmZmODE2Yjg3ZjA+XSA/
IGlwX3NlbmRfdW5pY2FzdF9yZXBseSsweDM0MC8weDM0MA0KWyAgMzEzLjA1MDQ4NF0gIFs8
ZmZmZmZmZmY4MTBhMGJhNz5dID8gZ2V0bnN0aW1lb2ZkYXkrMHg0Ny8weGUwDQpbICAzMTMu
MDUwNTA2XSAgWzxmZmZmZmZmZjgxNjBmNGM5Pl0gPyBfX3NrYl9jbG9uZSsweDI5LzB4MTIw
DQpbICAzMTMuMDUwNTI3XSAgWzxmZmZmZmZmZjgxNmNlYTIwPl0gdGNwX3RyYW5zbWl0X3Nr
YisweDQwMC8weDhkMA0KWyAgMzEzLjA1MDU1MF0gIFs8ZmZmZmZmZmY4MTZkMTEwNj5dIHRj
cF9yZXRyYW5zbWl0X3NrYisweDFjNi8weDVhMA0KWyAgMzEzLjA1MDU3NF0gIFs8ZmZmZmZm
ZmY4MTZkMTY3ZT5dIHRjcF94bWl0X3JldHJhbnNtaXRfcXVldWUrMHgxOWUvMHgzMDANClsg
IDMxMy4wNTA1OThdICBbPGZmZmZmZmZmODE2Yzk5ZmY+XSB0Y3BfZmFzdHJldHJhbnNfYWxl
cnQrMHg5NGYvMHhjYjANClsgIDMxMy4wNTA2MjFdICBbPGZmZmZmZmZmODE2Y2E3MGM+XSB0
Y3BfYWNrKzB4OWFjLzB4MTE1MA0KWyAgMzEzLjA1MDY0M10gIFs8ZmZmZmZmZmY4MTZjZDg1
OD5dIHRjcF9yY3ZfZXN0YWJsaXNoZWQrMHgzMTgvMHg2NDANClsgIDMxMy4wNTA2NjZdICBb
PGZmZmZmZmZmODE2ZDVlZWY+XSA/IHRjcF92NF9yY3YrMHg2Y2YvMHhiMTANClsgIDMxMy4w
NTA2ODhdICBbPGZmZmZmZmZmODE2ZDU0ZDU+XSB0Y3BfdjRfZG9fcmN2KzB4MTM1LzB4NDgw
DQpbICAzMTMuMDUwNzEwXSAgWzxmZmZmZmZmZjgxNzQ2MWQyPl0gPyBfcmF3X3NwaW5fbG9j
a19uZXN0ZWQrMHg0Mi8weDUwDQpbICAzMTMuMDUwNzMzXSAgWzxmZmZmZmZmZjgxNmQ1ZWVm
Pl0gPyB0Y3BfdjRfcmN2KzB4NmNmLzB4YjEwDQpbICAzMTMuMDUwNzU1XSAgWzxmZmZmZmZm
ZjgxNmQ2MTdkPl0gdGNwX3Y0X3JjdisweDk1ZC8weGIxMA0KWyAgMzEzLjA1MDc3Nl0gIFs8
ZmZmZmZmZmY4MTBiMGY4OD5dID8gbG9ja19hY3F1aXJlKzB4ZDgvMHgxMDANClsgIDMxMy4w
NTA3OTddICBbPGZmZmZmZmZmODE2YjI5OTU+XSA/IGlwX2xvY2FsX2RlbGl2ZXJfZmluaXNo
KzB4NDUvMHgyMzANClsgIDMxMy4wNTA4MjFdICBbPGZmZmZmZmZmODE2YjJhNmE+XSBpcF9s
b2NhbF9kZWxpdmVyX2ZpbmlzaCsweDExYS8weDIzMA0KWyAgMzEzLjA1MDg0NF0gIFs8ZmZm
ZmZmZmY4MTZiMjk5NT5dID8gaXBfbG9jYWxfZGVsaXZlcl9maW5pc2grMHg0NS8weDIzMA0K
WyAgMzEzLjA1MDg2OV0gIFs8ZmZmZmZmZmY4MTZiMmJiOD5dIGlwX2xvY2FsX2RlbGl2ZXIr
MHgzOC8weDgwDQpbICAzMTMuMDUwODkxXSAgWzxmZmZmZmZmZjgxNmIyMTdhPl0gaXBfcmN2
X2ZpbmlzaCsweDE1YS8weDYzMA0KWyAgMzEzLjA1MDkxM10gIFs8ZmZmZmZmZmY4MTZiMjg2
OD5dIGlwX3JjdisweDIxOC8weDMwMA0KWyAgMzEzLjA1MDkzNF0gIFs8ZmZmZmZmZmY4MTYx
YWM4ZD5dIF9fbmV0aWZfcmVjZWl2ZV9za2IrMHg2NWQvMHg4ZDANClsgIDMxMy4wNTA5NTZd
ICBbPGZmZmZmZmZmODE2MWE3NzU+XSA/IF9fbmV0aWZfcmVjZWl2ZV9za2IrMHgxNDUvMHg4
ZDANClsgIDMxMy4wNTA5NzldICBbPGZmZmZmZmZmODEwYWQyMmQ+XSA/IHRyYWNlX2hhcmRp
cnFzX29uKzB4ZC8weDEwDQpbICAzMTMuMDUxMDAxXSAgWzxmZmZmZmZmZjgxMGY5OTczPl0g
PyBmcmVlX2hvdF9jb2xkX3BhZ2UrMHgxYjMvMHgxZTANClsgIDMxMy4wNTEwMjRdICBbPGZm
ZmZmZmZmODE2MWQxZjg+XSBuZXRpZl9yZWNlaXZlX3NrYisweDI4LzB4ZjANClsgIDMxMy4w
NTEwNDddICBbPGZmZmZmZmZmODE2MTJkMDM+XSA/IF9fcHNrYl9wdWxsX3RhaWwrMHgyNTMv
MHgzNDANClsgIDMxMy4wNTEwNzBdICBbPGZmZmZmZmZmODE0NmU0YzU+XSB4ZW5uZXRfcG9s
bCsweGFkNS8weGUxMA0KWyAgMzEzLjA1MTA5NV0gIFs8ZmZmZmZmZmY4MTYxZGZhNj5dIG5l
dF9yeF9hY3Rpb24rMHgxMzYvMHgyNjANClsgIDMxMy4wNTExMTddICBbPGZmZmZmZmZmODEw
NmUzODE+XSA/IF9fZG9fc29mdGlycSsweDcxLzB4MWEwDQpbICAzMTMuMDUxMTM5XSAgWzxm
ZmZmZmZmZjgxMDZlM2Q5Pl0gX19kb19zb2Z0aXJxKzB4YzkvMHgxYTANClsgIDMxMy4wNTEx
NjFdICBbPGZmZmZmZmZmODE3NDhkM2M+XSBjYWxsX3NvZnRpcnErMHgxYy8weDMwDQpbICAz
MTMuMDUxMTgxXSAgWzxmZmZmZmZmZjgxMDBlZGI1Pl0gZG9fc29mdGlycSsweDg1LzB4ZjAN
ClsgIDMxMy4wNTEyMDJdICBbPGZmZmZmZmZmODEwNmUyNGU+XSBpcnFfZXhpdCsweDllLzB4
ZDANClsgIDMxMy4wNTEyMjNdICBbPGZmZmZmZmZmODEzMzlmNWY+XSB4ZW5fZXZ0Y2huX2Rv
X3VwY2FsbCsweDJmLzB4NDANClsgIDMxMy4wNTEyNDZdICBbPGZmZmZmZmZmODE3NDhkOWU+
XSB4ZW5fZG9faHlwZXJ2aXNvcl9jYWxsYmFjaysweDFlLzB4MzANClsgIDMxMy4wNTEyNjVd
ICA8RU9JPiAgWzxmZmZmZmZmZjgxMDAxM2FhPl0gPyB4ZW5faHlwZXJjYWxsX3NjaGVkX29w
KzB4YS8weDIwDQpbICAzMTMuMDUxMzAxXSAgWzxmZmZmZmZmZjgxMDAxM2FhPl0gPyB4ZW5f
aHlwZXJjYWxsX3NjaGVkX29wKzB4YS8weDIwDQpbICAzMTMuMDUxMzI1XSAgWzxmZmZmZmZm
ZjgxMDA4NjkwPl0gPyB4ZW5fc2FmZV9oYWx0KzB4MTAvMHgyMA0KWyAgMzEzLjA1MTM0N10g
IFs8ZmZmZmZmZmY4MTAxNjBkMD5dID8gZGVmYXVsdF9pZGxlKzB4NDAvMHg5MA0KWyAgMzEz
LjA1MTM2OV0gIFs8ZmZmZmZmZmY4MTAxNjQ4Nj5dID8gY3B1X2lkbGUrMHg5Ni8weGYwDQpb
ICAzMTMuMDUxMzg4XSAgWzxmZmZmZmZmZjgxNzIyZDNjPl0gPyByZXN0X2luaXQrMHhiYy8w
eGQwDQpbICAzMTMuMDUxNDA4XSAgWzxmZmZmZmZmZjgxNzIyYzgwPl0gPyBjc3VtX3BhcnRp
YWxfY29weV9nZW5lcmljKzB4MTcwLzB4MTcwDQpbICAzMTMuMDUxNDMyXSAgWzxmZmZmZmZm
ZjgxY2UwZGYyPl0gPyBzdGFydF9rZXJuZWwrMHgzOTAvMHgzOWQNClsgIDMxMy4wNTE0NTRd
ICBbPGZmZmZmZmZmODFjZTA4ODI+XSA/IGtlcm5lbF9pbml0KzB4MjBiLzB4MjBiDQpbICAz
MTMuMDUxNDc2XSAgWzxmZmZmZmZmZjgxY2UwMzU2Pl0gPyB4ODZfNjRfc3RhcnRfcmVzZXJ2
YXRpb25zKzB4MTMxLzB4MTM2DQpbICAzMTMuMDUxNTAzXSAgWzxmZmZmZmZmZjgxY2UzZDYw
Pl0gPyB4ZW5fc3RhcnRfa2VybmVsKzB4NzBkLzB4NzBmDQpbICAzMTMuMDUxNTIzXSAtLS1b
IGVuZCB0cmFjZSAyZTI4ZWVjOTNiN2E4Yjg5IF0tLS0NClsgIDMxMy4wNTM2NDVdIC0tLS0t
LS0tLS0tLVsgY3V0IGhlcmUgXS0tLS0tLS0tLS0tLQ0KWyAgMzEzLjA1MzY4NF0gV0FSTklO
RzogYXQgZHJpdmVycy9uZXQveGVuLW5ldGZyb250LmM6NDY1IHhlbm5ldF9zdGFydF94bWl0
KzB4N2ZlLzB4ODYwKCkNClsgIDMxMy4wNTM3MDddIE1vZHVsZXMgbGlua2VkIGluOg0KWyAg
MzEzLjA1MzcyOV0gUGlkOiAxNTIzLCBjb21tOiBzeXNsb2dkIFRhaW50ZWQ6IEcgICAgICAg
IFcgICAgMy42LjBwcmUtcmMxLTIwMTIxMDExICMxDQpbICAzMTMuMDUzNzUxXSBDYWxsIFRy
YWNlOg0KWyAgMzEzLjA1Mzc2Ml0gIDxJUlE+ICBbPGZmZmZmZmZmODEwNjY0ZWE+XSB3YXJu
X3Nsb3dwYXRoX2NvbW1vbisweDdhLzB4YjANClsgIDMxMy4wNTM3OThdICBbPGZmZmZmZmZm
ODEwNjY1MzU+XSB3YXJuX3Nsb3dwYXRoX251bGwrMHgxNS8weDIwDQpbICAzMTMuMDUzODIw
XSAgWzxmZmZmZmZmZjgxNDZkODllPl0geGVubmV0X3N0YXJ0X3htaXQrMHg3ZmUvMHg4NjAN
ClsgIDMxMy4wNTM4NDVdICBbPGZmZmZmZmZmODE2MWYzNDk+XSBkZXZfaGFyZF9zdGFydF94
bWl0KzB4MjA5LzB4NDYwDQpbICAzMTMuMDUzODY5XSAgWzxmZmZmZmZmZjgxNjNiMDM2Pl0g
c2NoX2RpcmVjdF94bWl0KzB4ZjYvMHgyOTANClsgIDMxMy4wNTM4OTFdICBbPGZmZmZmZmZm
ODE2MWY3NDY+XSBkZXZfcXVldWVfeG1pdCsweDFhNi8weDVhMA0KWyAgMzEzLjA1MzkxM10g
IFs8ZmZmZmZmZmY4MTYxZjVhMD5dID8gZGV2X2hhcmRfc3RhcnRfeG1pdCsweDQ2MC8weDQ2
MA0KWyAgMzEzLjA1MzkzNl0gIFs8ZmZmZmZmZmY4MTBiMTQxNz5dID8gbG9ja19yZWxlYXNl
KzB4MTE3LzB4MjUwDQpbICAzMTMuMDUzOTYwXSAgWzxmZmZmZmZmZjgxNmI5NTM2Pl0gaXBf
ZmluaXNoX291dHB1dCsweDIyNi8weDUzMA0KWyAgMzEzLjA1Mzk4NV0gIFs8ZmZmZmZmZmY4
MTZiOTNkZD5dID8gaXBfZmluaXNoX291dHB1dCsweGNkLzB4NTMwDQpbICAzMTMuMDU0MDEw
XSAgWzxmZmZmZmZmZjgxNmI5ODk5Pl0gaXBfb3V0cHV0KzB4NTkvMHhlMA0KWyAgMzEzLjA1
NDAzMV0gIFs8ZmZmZmZmZmY4MTZiODNiOD5dIGlwX2xvY2FsX291dCsweDI4LzB4OTANClsg
IDMxMy4wNTQwNTNdICBbPGZmZmZmZmZmODE2Yjg5NmY+XSBpcF9xdWV1ZV94bWl0KzB4MTdm
LzB4NGEwDQpbICAzMTMuMDU0MDc0XSAgWzxmZmZmZmZmZjgxNmI4N2YwPl0gPyBpcF9zZW5k
X3VuaWNhc3RfcmVwbHkrMHgzNDAvMHgzNDANClsgIDMxMy4wNTQwOTddICBbPGZmZmZmZmZm
ODEwYTBiYTc+XSA/IGdldG5zdGltZW9mZGF5KzB4NDcvMHhlMA0KWyAgMzEzLjA1NDEyMF0g
IFs8ZmZmZmZmZmY4MTYwZjRjOT5dID8gX19za2JfY2xvbmUrMHgyOS8weDEyMA0KWyAgMzEz
LjA1NDE0MV0gIFs8ZmZmZmZmZmY4MTZjZWEyMD5dIHRjcF90cmFuc21pdF9za2IrMHg0MDAv
MHg4ZDANClsgIDMxMy4wNTQxNjRdICBbPGZmZmZmZmZmODE2ZDExMDY+XSB0Y3BfcmV0cmFu
c21pdF9za2IrMHgxYzYvMHg1YTANClsgIDMxMy4wNTQxODZdICBbPGZmZmZmZmZmODE3NDZj
YjU+XSA/IF9yYXdfc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSsweDc1LzB4YTANClsgIDMxMy4w
NTQyMTFdICBbPGZmZmZmZmZmODE2ZDE2N2U+XSB0Y3BfeG1pdF9yZXRyYW5zbWl0X3F1ZXVl
KzB4MTllLzB4MzAwDQpbICAzMTMuMDU0MjM0XSAgWzxmZmZmZmZmZjgxNmM5OWZmPl0gdGNw
X2Zhc3RyZXRyYW5zX2FsZXJ0KzB4OTRmLzB4Y2IwDQpbICAzMTMuMDU0MjU3XSAgWzxmZmZm
ZmZmZjgxNmNhNzBjPl0gdGNwX2FjaysweDlhYy8weDExNTANClsgIDMxMy4wNTQyODBdICBb
PGZmZmZmZmZmODE2Y2Q4Y2U+XSB0Y3BfcmN2X2VzdGFibGlzaGVkKzB4MzhlLzB4NjQwDQpb
ICAzMTMuMDU0MzAzXSAgWzxmZmZmZmZmZjgxNmQ1ZWVmPl0gPyB0Y3BfdjRfcmN2KzB4NmNm
LzB4YjEwDQpbICAzMTMuMDU0MzI1XSAgWzxmZmZmZmZmZjgxNmQ1NGQ1Pl0gdGNwX3Y0X2Rv
X3JjdisweDEzNS8weDQ4MA0KWyAgMzEzLjA1NDM0N10gIFs8ZmZmZmZmZmY4MTc0NjFkMj5d
ID8gX3Jhd19zcGluX2xvY2tfbmVzdGVkKzB4NDIvMHg1MA0KWyAgMzEzLjA1NDM3MF0gIFs8
ZmZmZmZmZmY4MTZkNWVlZj5dID8gdGNwX3Y0X3JjdisweDZjZi8weGIxMA0KWyAgMzEzLjA1
NDM5MV0gIFs8ZmZmZmZmZmY4MTZkNjE3ZD5dIHRjcF92NF9yY3YrMHg5NWQvMHhiMTANClsg
IDMxMy4wNTQ0MTJdICBbPGZmZmZmZmZmODEwYjBmODg+XSA/IGxvY2tfYWNxdWlyZSsweGQ4
LzB4MTAwDQpbICAzMTMuMDU0NDMzXSAgWzxmZmZmZmZmZjgxNmIyOTk1Pl0gPyBpcF9sb2Nh
bF9kZWxpdmVyX2ZpbmlzaCsweDQ1LzB4MjMwDQpbICAzMTMuMDU0NDU4XSAgWzxmZmZmZmZm
ZjgxNmIyYTZhPl0gaXBfbG9jYWxfZGVsaXZlcl9maW5pc2grMHgxMWEvMHgyMzANClsgIDMx
My4wNTQ0ODFdICBbPGZmZmZmZmZmODE2YjI5OTU+XSA/IGlwX2xvY2FsX2RlbGl2ZXJfZmlu
aXNoKzB4NDUvMHgyMzANClsgIDMxMy4wNTQ1MDVdICBbPGZmZmZmZmZmODE2YjJiYjg+XSBp
cF9sb2NhbF9kZWxpdmVyKzB4MzgvMHg4MA0KWyAgMzEzLjA1NDUyN10gIFs8ZmZmZmZmZmY4
MTZiMjE3YT5dIGlwX3Jjdl9maW5pc2grMHgxNWEvMHg2MzANClsgIDMxMy4wNTQ1NDhdICBb
PGZmZmZmZmZmODE2YjI4Njg+XSBpcF9yY3YrMHgyMTgvMHgzMDANClsgIDMxMy4wNTQ1Njld
ICBbPGZmZmZmZmZmODE2MWFjOGQ+XSBfX25ldGlmX3JlY2VpdmVfc2tiKzB4NjVkLzB4OGQw
DQpbICAzMTMuMDU0NTkxXSAgWzxmZmZmZmZmZjgxNjFhNzc1Pl0gPyBfX25ldGlmX3JlY2Vp
dmVfc2tiKzB4MTQ1LzB4OGQwDQpbICAzMTMuMDU0NjEzXSAgWzxmZmZmZmZmZjgxMGFkMjJk
Pl0gPyB0cmFjZV9oYXJkaXJxc19vbisweGQvMHgxMA0KWyAgMzEzLjA1NDYzNl0gIFs8ZmZm
ZmZmZmY4MTBmOTk3Mz5dID8gZnJlZV9ob3RfY29sZF9wYWdlKzB4MWIzLzB4MWUwDQpbICAz
MTMuMDU0NjU5XSAgWzxmZmZmZmZmZjgxNjFkMWY4Pl0gbmV0aWZfcmVjZWl2ZV9za2IrMHgy
OC8weGYwDQpbICAzMTMuMDU0NjgyXSAgWzxmZmZmZmZmZjgxNjEyZDAzPl0gPyBfX3Bza2Jf
cHVsbF90YWlsKzB4MjUzLzB4MzQwDQpbICAzMTMuMDU0NzA1XSAgWzxmZmZmZmZmZjgxNDZl
NGM1Pl0geGVubmV0X3BvbGwrMHhhZDUvMHhlMTANClsgIDMxMy4wNTQ3MzBdICBbPGZmZmZm
ZmZmODE2MWRmYTY+XSBuZXRfcnhfYWN0aW9uKzB4MTM2LzB4MjYwDQpbICAzMTMuMDU0NzUy
XSAgWzxmZmZmZmZmZjgxMDZlMzgxPl0gPyBfX2RvX3NvZnRpcnErMHg3MS8weDFhMA0KWyAg
MzEzLjA1NDc3NF0gIFs8ZmZmZmZmZmY4MTA2ZTNkOT5dIF9fZG9fc29mdGlycSsweGM5LzB4
MWEwDQpbICAzMTMuMDU0Nzk1XSAgWzxmZmZmZmZmZjgxNzQ4ZDNjPl0gY2FsbF9zb2Z0aXJx
KzB4MWMvMHgzMA0KWyAgMzEzLjA1NDgxNl0gIFs8ZmZmZmZmZmY4MTAwZWRiNT5dIGRvX3Nv
ZnRpcnErMHg4NS8weGYwDQpbICAzMTMuMDU0ODM2XSAgWzxmZmZmZmZmZjgxMDZlMjRlPl0g
aXJxX2V4aXQrMHg5ZS8weGQwDQpbICAzMTMuMDU0ODU4XSAgWzxmZmZmZmZmZjgxMzM5ZjVm
Pl0geGVuX2V2dGNobl9kb191cGNhbGwrMHgyZi8weDQwDQpbICAzMTMuMDU0ODgxXSAgWzxm
ZmZmZmZmZjgxNzQ4ZDllPl0geGVuX2RvX2h5cGVydmlzb3JfY2FsbGJhY2srMHgxZS8weDMw
DQpbICAzMTMuMDU0ODk5XSAgPEVPST4gIFs8ZmZmZmZmZmY4MTAwMTIyYT5dID8geGVuX2h5
cGVyY2FsbF94ZW5fdmVyc2lvbisweGEvMHgyMA0KWyAgMzEzLjA1NDkzN10gIFs8ZmZmZmZm
ZmY4MTAwMTIyYT5dID8geGVuX2h5cGVyY2FsbF94ZW5fdmVyc2lvbisweGEvMHgyMA0KWyAg
MzEzLjA1NDk2MV0gIFs8ZmZmZmZmZmY4MTAwODY0ZD5dID8geGVuX2ZvcmNlX2V2dGNobl9j
YWxsYmFjaysweGQvMHgxMA0KWyAgMzEzLjA1NDk4NV0gIFs8ZmZmZmZmZmY4MTAwOGZmMj5d
ID8gY2hlY2tfZXZlbnRzKzB4MTIvMHgyMA0KWyAgMzEzLjA1NTAwN10gIFs8ZmZmZmZmZmY4
MTAwOGY5OT5dID8geGVuX2lycV9lbmFibGVfZGlyZWN0X3JlbG9jKzB4NC8weDQNClsgIDMx
My4wNTUwMzFdICBbPGZmZmZmZmZmODE3NDkxNDY+XSA/IGlhMzJfY3N0YXJfdGFyZ2V0KzB4
MTYvMHg4Yw0KWyAgMzEzLjA1NTA0OV0gLS0tWyBlbmQgdHJhY2UgMmUyOGVlYzkzYjdhOGI4
YSBdLS0tDQpbICAzMTMuMDU1MTE1XSAtLS0tLS0tLS0tLS1bIGN1dCBoZXJlIF0tLS0tLS0t
LS0tLS0NClsgIDMxMy4wNTUxMzddIFdBUk5JTkc6IGF0IGRyaXZlcnMvbmV0L3hlbi1uZXRm
cm9udC5jOjQ2NSB4ZW5uZXRfc3RhcnRfeG1pdCsweDdmZS8weDg2MCgpDQpbICAzMTMuMDU1
MTYwXSBNb2R1bGVzIGxpbmtlZCBpbjoNClsgIDMxMy4wNTUxNzldIFBpZDogMTUyMywgY29t
bTogc3lzbG9nZCBUYWludGVkOiBHICAgICAgICBXICAgIDMuNi4wcHJlLXJjMS0yMDEyMTAx
MSAjMQ0KWyAgMzEzLjA1NTIwNF0gQ2FsbCBUcmFjZToNClsgIDMxMy4wNTUyMTVdICA8SVJR
PiAgWzxmZmZmZmZmZjgxMDY2NGVhPl0gd2Fybl9zbG93cGF0aF9jb21tb24rMHg3YS8weGIw
DQpbICAzMTMuMDU1MjQ4XSAgWzxmZmZmZmZmZjgxMDY2NTM1Pl0gd2Fybl9zbG93cGF0aF9u
dWxsKzB4MTUvMHgyMA0KWyAgMzEzLjA1NTI3MV0gIFs8ZmZmZmZmZmY4MTQ2ZDg5ZT5dIHhl
bm5ldF9zdGFydF94bWl0KzB4N2ZlLzB4ODYwDQpbICAzMTMuMDU1Mjk2XSAgWzxmZmZmZmZm
ZjgxNjFmMzQ5Pl0gZGV2X2hhcmRfc3RhcnRfeG1pdCsweDIwOS8weDQ2MA0KWyAgMzEzLjA1
NTMxOV0gIFs8ZmZmZmZmZmY4MTYzYjAzNj5dIHNjaF9kaXJlY3RfeG1pdCsweGY2LzB4Mjkw
DQpbICAzMTMuMDU1MzQyXSAgWzxmZmZmZmZmZjgxNjFmNzQ2Pl0gZGV2X3F1ZXVlX3htaXQr
MHgxYTYvMHg1YTANClsgIDMxMy4wNTUzNjRdICBbPGZmZmZmZmZmODE2MWY1YTA+XSA/IGRl
dl9oYXJkX3N0YXJ0X3htaXQrMHg0NjAvMHg0NjANClsgIDMxMy4wNTUzODddICBbPGZmZmZm
ZmZmODEwYjE0MTc+XSA/IGxvY2tfcmVsZWFzZSsweDExNy8weDI1MA0KWyAgMzEzLjA1NTQx
MV0gIFs8ZmZmZmZmZmY4MTZiOTUzNj5dIGlwX2ZpbmlzaF9vdXRwdXQrMHgyMjYvMHg1MzAN
ClsgIDMxMy4wNTU0MzRdICBbPGZmZmZmZmZmODE2YjkzZGQ+XSA/IGlwX2ZpbmlzaF9vdXRw
dXQrMHhjZC8weDUzMA0KWyAgMzEzLjA1NTQ1OF0gIFs8ZmZmZmZmZmY4MTZiOTg5OT5dIGlw
X291dHB1dCsweDU5LzB4ZTANClsgIDMxMy4wNTU0NzldICBbPGZmZmZmZmZmODE2YjgzYjg+
XSBpcF9sb2NhbF9vdXQrMHgyOC8weDkwDQpbICAzMTMuMDU1NTAxXSAgWzxmZmZmZmZmZjgx
NmI4OTZmPl0gaXBfcXVldWVfeG1pdCsweDE3Zi8weDRhMA0KWyAgMzEzLjA1NTUyNF0gIFs8
ZmZmZmZmZmY4MTZiODdmMD5dID8gaXBfc2VuZF91bmljYXN0X3JlcGx5KzB4MzQwLzB4MzQw
DQpbICAzMTMuMDU1NTQ3XSAgWzxmZmZmZmZmZjgxMGEwYmE3Pl0gPyBnZXRuc3RpbWVvZmRh
eSsweDQ3LzB4ZTANClsgIDMxMy4wNTU1NjldICBbPGZmZmZmZmZmODE2MGY0Yzk+XSA/IF9f
c2tiX2Nsb25lKzB4MjkvMHgxMjANClsgIDMxMy4wNTU1OTFdICBbPGZmZmZmZmZmODE2Y2Vh
MjA+XSB0Y3BfdHJhbnNtaXRfc2tiKzB4NDAwLzB4OGQwDQpbICAzMTMuMDU1NjE1XSAgWzxm
ZmZmZmZmZjgxNmQxMTA2Pl0gdGNwX3JldHJhbnNtaXRfc2tiKzB4MWM2LzB4NWEwDQpbICAz
MTMuMDU1NjM3XSAgWzxmZmZmZmZmZjgxNzQ2Y2I1Pl0gPyBfcmF3X3NwaW5fdW5sb2NrX2ly
cXJlc3RvcmUrMHg3NS8weGEwDQpbICAzMTMuMDU1NjYyXSAgWzxmZmZmZmZmZjgxNmQxNjdl
Pl0gdGNwX3htaXRfcmV0cmFuc21pdF9xdWV1ZSsweDE5ZS8weDMwMA0KWyAgMzEzLjA1NTY4
Nl0gIFs8ZmZmZmZmZmY4MTZjOTlmZj5dIHRjcF9mYXN0cmV0cmFuc19hbGVydCsweDk0Zi8w
eGNiMA0KWyAgMzEzLjA1NTcwOV0gIFs8ZmZmZmZmZmY4MTZjYTcwYz5dIHRjcF9hY2srMHg5
YWMvMHgxMTUwDQpbICAzMTMuMDU1NzMyXSAgWzxmZmZmZmZmZjgxNmNkOGNlPl0gdGNwX3Jj
dl9lc3RhYmxpc2hlZCsweDM4ZS8weDY0MA0KWyAgMzEzLjA1NTc2MF0gIFs8ZmZmZmZmZmY4
MTZkNWVlZj5dID8gdGNwX3Y0X3JjdisweDZjZi8weGIxMA0KWyAgMzEzLjA1NTc4Ml0gIFs8
ZmZmZmZmZmY4MTZkNTRkNT5dIHRjcF92NF9kb19yY3YrMHgxMzUvMHg0ODANClsgIDMxMy4w
NTU4MDRdICBbPGZmZmZmZmZmODE3NDYxZDI+XSA/IF9yYXdfc3Bpbl9sb2NrX25lc3RlZCsw
eDQyLzB4NTANClsgIDMxMy4wNTU4MjhdICBbPGZmZmZmZmZmODE2ZDVlZWY+XSA/IHRjcF92
NF9yY3YrMHg2Y2YvMHhiMTANClsgIDMxMy4wNTU4NDldICBbPGZmZmZmZmZmODE2ZDYxN2Q+
XSB0Y3BfdjRfcmN2KzB4OTVkLzB4YjEwDQpbICAzMTMuMDU1ODcwXSAgWzxmZmZmZmZmZjgx
MGIwZjg4Pl0gPyBsb2NrX2FjcXVpcmUrMHhkOC8weDEwMA0KWyAgMzEzLjA1NTg5Ml0gIFs8
ZmZmZmZmZmY4MTZiMjk5NT5dID8gaXBfbG9jYWxfZGVsaXZlcl9maW5pc2grMHg0NS8weDIz
MA0KWyAgMzEzLjA1NTkxN10gIFs8ZmZmZmZmZmY4MTZiMmE2YT5dIGlwX2xvY2FsX2RlbGl2
ZXJfZmluaXNoKzB4MTFhLzB4MjMwDQpbICAzMTMuMDU1OTQwXSAgWzxmZmZmZmZmZjgxNmIy
OTk1Pl0gPyBpcF9sb2NhbF9kZWxpdmVyX2ZpbmlzaCsweDQ1LzB4MjMwDQpbICAzMTMuMDU1
OTY1XSAgWzxmZmZmZmZmZjgxNmIyYmI4Pl0gaXBfbG9jYWxfZGVsaXZlcisweDM4LzB4ODAN
ClsgIDMxMy4wNTU5ODddICBbPGZmZmZmZmZmODE2YjIxN2E+XSBpcF9yY3ZfZmluaXNoKzB4
MTVhLzB4NjMwDQpbICAzMTMuMDU2MDA5XSAgWzxmZmZmZmZmZjgxNmIyODY4Pl0gaXBfcmN2
KzB4MjE4LzB4MzAwDQpbICAzMTMuMDU2MDMwXSAgWzxmZmZmZmZmZjgxNjFhYzhkPl0gX19u
ZXRpZl9yZWNlaXZlX3NrYisweDY1ZC8weDhkMA0KWyAgMzEzLjA1NjA1Ml0gIFs8ZmZmZmZm
ZmY4MTYxYTc3NT5dID8gX19uZXRpZl9yZWNlaXZlX3NrYisweDE0NS8weDhkMA0KWyAgMzEz
LjA1NjA3NV0gIFs8ZmZmZmZmZmY4MTBhZDIyZD5dID8gdHJhY2VfaGFyZGlycXNfb24rMHhk
LzB4MTANClsgIDMxMy4wNTYwOThdICBbPGZmZmZmZmZmODEwZjk5NzM+XSA/IGZyZWVfaG90
X2NvbGRfcGFnZSsweDFiMy8weDFlMA0KWyAgMzEzLjA1NjEyMV0gIFs8ZmZmZmZmZmY4MTYx
ZDFmOD5dIG5ldGlmX3JlY2VpdmVfc2tiKzB4MjgvMHhmMA0KWyAgMzEzLjA1NjE0NV0gIFs8
ZmZmZmZmZmY4MTYxMmQwMz5dID8gX19wc2tiX3B1bGxfdGFpbCsweDI1My8weDM0MA0KWyAg
MzEzLjA1NjE2OF0gIFs8ZmZmZmZmZmY4MTQ2ZTRjNT5dIHhlbm5ldF9wb2xsKzB4YWQ1LzB4
ZTEwDQpbICAzMTMuMDU2MTkzXSAgWzxmZmZmZmZmZjgxNjFkZmE2Pl0gbmV0X3J4X2FjdGlv
bisweDEzNi8weDI2MA0KWyAgMzEzLjA1NjIxNl0gIFs8ZmZmZmZmZmY4MTA2ZTM4MT5dID8g
X19kb19zb2Z0aXJxKzB4NzEvMHgxYTANClsgIDMxMy4wNTYyMzhdICBbPGZmZmZmZmZmODEw
NmUzZDk+XSBfX2RvX3NvZnRpcnErMHhjOS8weDFhMA0KWyAgMzEzLjA1NjI2MF0gIFs8ZmZm
ZmZmZmY4MTc0OGQzYz5dIGNhbGxfc29mdGlycSsweDFjLzB4MzANClsgIDMxMy4wNTYyODFd
ICBbPGZmZmZmZmZmODEwMGVkYjU+XSBkb19zb2Z0aXJxKzB4ODUvMHhmMA0KWyAgMzEzLjA1
NjMwMl0gIFs8ZmZmZmZmZmY4MTA2ZTI0ZT5dIGlycV9leGl0KzB4OWUvMHhkMA0KWyAgMzEz
LjA1NjMyNF0gIFs8ZmZmZmZmZmY4MTMzOWY1Zj5dIHhlbl9ldnRjaG5fZG9fdXBjYWxsKzB4
MmYvMHg0MA0KWyAgMzEzLjA1NjM0N10gIFs8ZmZmZmZmZmY4MTc0OGQ5ZT5dIHhlbl9kb19o
eXBlcnZpc29yX2NhbGxiYWNrKzB4MWUvMHgzMA0KWyAgMzEzLjA1NjM2Nl0gIDxFT0k+ICBb
PGZmZmZmZmZmODEwMDEyMmE+XSA/IHhlbl9oeXBlcmNhbGxfeGVuX3ZlcnNpb24rMHhhLzB4
MjANClsgIDMxMy4wNTY0MDJdICBbPGZmZmZmZmZmODEwMDEyMmE+XSA/IHhlbl9oeXBlcmNh
bGxfeGVuX3ZlcnNpb24rMHhhLzB4MjANClsgIDMxMy4wNTY0MjddICBbPGZmZmZmZmZmODEw
MDg2NGQ+XSA/IHhlbl9mb3JjZV9ldnRjaG5fY2FsbGJhY2srMHhkLzB4MTANClsgIDMxMy4w
NTY0NTBdICBbPGZmZmZmZmZmODEwMDhmZjI+XSA/IGNoZWNrX2V2ZW50cysweDEyLzB4MjAN
ClsgIDMxMy4wNTY0NzNdICBbPGZmZmZmZmZmODEwMDhmOTk+XSA/IHhlbl9pcnFfZW5hYmxl
X2RpcmVjdF9yZWxvYysweDQvMHg0DQpbICAzMTMuMDU2NDk2XSAgWzxmZmZmZmZmZjgxNzQ5
MTQ2Pl0gPyBpYTMyX2NzdGFyX3RhcmdldCsweDE2LzB4OGMNClsgIDMxMy4wNTY1MTVdIC0t
LVsgZW5kIHRyYWNlIDJlMjhlZWM5M2I3YThiOGIgXS0tLQ0KWyAgMzEzLjA1NjU3OF0gLS0t
LS0tLS0tLS0tWyBjdXQgaGVyZSBdLS0tLS0tLS0tLS0tDQpbICAzMTMuMDU2NjAxXSBXQVJO
SU5HOiBhdCBkcml2ZXJzL25ldC94ZW4tbmV0ZnJvbnQuYzo0NjUgeGVubmV0X3N0YXJ0X3ht
aXQrMHg3ZmUvMHg4NjAoKQ0KWyAgMzEzLjA1NjYyNF0gTW9kdWxlcyBsaW5rZWQgaW46DQpb
ICAzMTMuMDU2NjQxXSBQaWQ6IDE1MjMsIGNvbW06IHN5c2xvZ2QgVGFpbnRlZDogRyAgICAg
ICAgVyAgICAzLjYuMHByZS1yYzEtMjAxMjEwMTEgIzENClsgIDMxMy4wNTY2NjRdIENhbGwg
VHJhY2U6DQpbICAzMTMuMDU2Njc1XSAgPElSUT4gIFs8ZmZmZmZmZmY4MTA2NjRlYT5dIHdh
cm5fc2xvd3BhdGhfY29tbW9uKzB4N2EvMHhiMA0KWyAgMzEzLjA1NjcwOF0gIFs8ZmZmZmZm
ZmY4MTA2NjUzNT5dIHdhcm5fc2xvd3BhdGhfbnVsbCsweDE1LzB4MjANClsgIDMxMy4wNTY3
MDhdICBbPGZmZmZmZmZmODE0NmQ4OWU+XSB4ZW5uZXRfc3RhcnRfeG1pdCsweDdmZS8weDg2
MA0KWyAgMzEzLjA1NjcwOF0gIFs8ZmZmZmZmZmY4MTYxZjM0OT5dIGRldl9oYXJkX3N0YXJ0
X3htaXQrMHgyMDkvMHg0NjANClsgIDMxMy4wNTY3MDhdICBbPGZmZmZmZmZmODE2M2IwMzY+
XSBzY2hfZGlyZWN0X3htaXQrMHhmNi8weDI5MA0KWyAgMzEzLjA1NjcwOF0gIFs8ZmZmZmZm
ZmY4MTYxZjc0Nj5dIGRldl9xdWV1ZV94bWl0KzB4MWE2LzB4NWEwDQpbICAzMTMuMDU2NzA4
XSAgWzxmZmZmZmZmZjgxNjFmNWEwPl0gPyBkZXZfaGFyZF9zdGFydF94bWl0KzB4NDYwLzB4
NDYwDQpbICAzMTMuMDU2NzA4XSAgWzxmZmZmZmZmZjgxMGIxNDE3Pl0gPyBsb2NrX3JlbGVh
c2UrMHgxMTcvMHgyNTANClsgIDMxMy4wNTY3MDhdICBbPGZmZmZmZmZmODE2Yjk1MzY+XSBp
cF9maW5pc2hfb3V0cHV0KzB4MjI2LzB4NTMwDQpbICAzMTMuMDU2NzA4XSAgWzxmZmZmZmZm
ZjgxNmI5M2RkPl0gPyBpcF9maW5pc2hfb3V0cHV0KzB4Y2QvMHg1MzANClsgIDMxMy4wNTY3
MDhdICBbPGZmZmZmZmZmODE2Yjk4OTk+XSBpcF9vdXRwdXQrMHg1OS8weGUwDQpbICAzMTMu
MDU2NzA4XSAgWzxmZmZmZmZmZjgxNmI4M2I4Pl0gaXBfbG9jYWxfb3V0KzB4MjgvMHg5MA0K
WyAgMzEzLjA1NjcwOF0gIFs8ZmZmZmZmZmY4MTZiODk2Zj5dIGlwX3F1ZXVlX3htaXQrMHgx
N2YvMHg0YTANClsgIDMxMy4wNTY3MDhdICBbPGZmZmZmZmZmODE2Yjg3ZjA+XSA/IGlwX3Nl
bmRfdW5pY2FzdF9yZXBseSsweDM0MC8weDM0MA0KWyAgMzEzLjA1NjcwOF0gIFs8ZmZmZmZm
ZmY4MTBhMGJhNz5dID8gZ2V0bnN0aW1lb2ZkYXkrMHg0Ny8weGUwDQpbICAzMTMuMDU2NzA4
XSAgWzxmZmZmZmZmZjgxNjBmNGM5Pl0gPyBfX3NrYl9jbG9uZSsweDI5LzB4MTIwDQpbICAz
MTMuMDU2NzA4XSAgWzxmZmZmZmZmZjgxNmNlYTIwPl0gdGNwX3RyYW5zbWl0X3NrYisweDQw
MC8weDhkMA0KWyAgMzEzLjA1NjcwOF0gIFs8ZmZmZmZmZmY4MTZkMTEwNj5dIHRjcF9yZXRy
YW5zbWl0X3NrYisweDFjNi8weDVhMA0KWyAgMzEzLjA1NjcwOF0gIFs8ZmZmZmZmZmY4MTc0
NmNiNT5dID8gX3Jhd19zcGluX3VubG9ja19pcnFyZXN0b3JlKzB4NzUvMHhhMA0KWyAgMzEz
LjA1NjcwOF0gIFs8ZmZmZmZmZmY4MTZkMTY3ZT5dIHRjcF94bWl0X3JldHJhbnNtaXRfcXVl
dWUrMHgxOWUvMHgzMDANClsgIDMxMy4wNTY3MDhdICBbPGZmZmZmZmZmODE2Yzk5ZmY+XSB0
Y3BfZmFzdHJldHJhbnNfYWxlcnQrMHg5NGYvMHhjYjANClsgIDMxMy4wNTY3MDhdICBbPGZm
ZmZmZmZmODE2Y2E3MGM+XSB0Y3BfYWNrKzB4OWFjLzB4MTE1MA0KWyAgMzEzLjA1NjcwOF0g
IFs8ZmZmZmZmZmY4MTZjZDhjZT5dIHRjcF9yY3ZfZXN0YWJsaXNoZWQrMHgzOGUvMHg2NDAN
ClsgIDMxMy4wNTY3MDhdICBbPGZmZmZmZmZmODE2ZDVlZWY+XSA/IHRjcF92NF9yY3YrMHg2
Y2YvMHhiMTANClsgIDMxMy4wNTY3MDhdICBbPGZmZmZmZmZmODE2ZDU0ZDU+XSB0Y3BfdjRf
ZG9fcmN2KzB4MTM1LzB4NDgwDQpbICAzMTMuMDU2NzA4XSAgWzxmZmZmZmZmZjgxNzQ2MWQy
Pl0gPyBfcmF3X3NwaW5fbG9ja19uZXN0ZWQrMHg0Mi8weDUwDQpbICAzMTMuMDU2NzA4XSAg
WzxmZmZmZmZmZjgxNmQ1ZWVmPl0gPyB0Y3BfdjRfcmN2KzB4NmNmLzB4YjEwDQpbICAzMTMu
MDU2NzA4XSAgWzxmZmZmZmZmZjgxNmQ2MTdkPl0gdGNwX3Y0X3JjdisweDk1ZC8weGIxMA0K
WyAgMzEzLjA1NjcwOF0gIFs8ZmZmZmZmZmY4MTBiMGY4OD5dID8gbG9ja19hY3F1aXJlKzB4
ZDgvMHgxMDANClsgIDMxMy4wNTY3MDhdICBbPGZmZmZmZmZmODE2YjI5OTU+XSA/IGlwX2xv
Y2FsX2RlbGl2ZXJfZmluaXNoKzB4NDUvMHgyMzANClsgIDMxMy4wNTY3MDhdICBbPGZmZmZm
ZmZmODE2YjJhNmE+XSBpcF9sb2NhbF9kZWxpdmVyX2ZpbmlzaCsweDExYS8weDIzMA0KWyAg
MzEzLjA1NjcwOF0gIFs8ZmZmZmZmZmY4MTZiMjk5NT5dID8gaXBfbG9jYWxfZGVsaXZlcl9m
aW5pc2grMHg0NS8weDIzMA0KWyAgMzEzLjA1NjcwOF0gIFs8ZmZmZmZmZmY4MTZiMmJiOD5d
IGlwX2xvY2FsX2RlbGl2ZXIrMHgzOC8weDgwDQpbICAzMTMuMDU2NzA4XSAgWzxmZmZmZmZm
ZjgxNmIyMTdhPl0gaXBfcmN2X2ZpbmlzaCsweDE1YS8weDYzMA0KWyAgMzEzLjA1NjcwOF0g
IFs8ZmZmZmZmZmY4MTZiMjg2OD5dIGlwX3JjdisweDIxOC8weDMwMA0KWyAgMzEzLjA1Njcw
OF0gIFs8ZmZmZmZmZmY4MTYxYWM4ZD5dIF9fbmV0aWZfcmVjZWl2ZV9za2IrMHg2NWQvMHg4
ZDANClsgIDMxMy4wNTY3MDhdICBbPGZmZmZmZmZmODE2MWE3NzU+XSA/IF9fbmV0aWZfcmVj
ZWl2ZV9za2IrMHgxNDUvMHg4ZDANClsgIDMxMy4wNTY3MDhdICBbPGZmZmZmZmZmODEwYWQy
MmQ+XSA/IHRyYWNlX2hhcmRpcnFzX29uKzB4ZC8weDEwDQpbICAzMTMuMDU2NzA4XSAgWzxm
ZmZmZmZmZjgxMGY5OTczPl0gPyBmcmVlX2hvdF9jb2xkX3BhZ2UrMHgxYjMvMHgxZTANClsg
IDMxMy4wNTY3MDhdICBbPGZmZmZmZmZmODE2MWQxZjg+XSBuZXRpZl9yZWNlaXZlX3NrYisw
eDI4LzB4ZjANClsgIDMxMy4wNTY3MDhdICBbPGZmZmZmZmZmODE2MTJkMDM+XSA/IF9fcHNr
Yl9wdWxsX3RhaWwrMHgyNTMvMHgzNDANClsgIDMxMy4wNTY3MDhdICBbPGZmZmZmZmZmODE0
NmU0YzU+XSB4ZW5uZXRfcG9sbCsweGFkNS8weGUxMA0KWyAgMzEzLjA1NjcwOF0gIFs8ZmZm
ZmZmZmY4MTYxZGZhNj5dIG5ldF9yeF9hY3Rpb24rMHgxMzYvMHgyNjANClsgIDMxMy4wNTY3
MDhdICBbPGZmZmZmZmZmODEwNmUzODE+XSA/IF9fZG9fc29mdGlycSsweDcxLzB4MWEwDQpb
ICAzMTMuMDU2NzA4XSAgWzxmZmZmZmZmZjgxMDZlM2Q5Pl0gX19kb19zb2Z0aXJxKzB4Yzkv
MHgxYTANClsgIDMxMy4wNTY3MDhdICBbPGZmZmZmZmZmODE3NDhkM2M+XSBjYWxsX3NvZnRp
cnErMHgxYy8weDMwDQpbICAzMTMuMDU2NzA4XSAgWzxmZmZmZmZmZjgxMDBlZGI1Pl0gZG9f
c29mdGlycSsweDg1LzB4ZjANClsgIDMxMy4wNTY3MDhdICBbPGZmZmZmZmZmODEwNmUyNGU+
XSBpcnFfZXhpdCsweDllLzB4ZDANClsgIDMxMy4wNTY3MDhdICBbPGZmZmZmZmZmODEzMzlm
NWY+XSB4ZW5fZXZ0Y2huX2RvX3VwY2FsbCsweDJmLzB4NDANClsgIDMxMy4wNTY3MDhdICBb
PGZmZmZmZmZmODE3NDhkOWU+XSB4ZW5fZG9faHlwZXJ2aXNvcl9jYWxsYmFjaysweDFlLzB4
MzANClsgIDMxMy4wNTY3MDhdICA8RU9JPiAgWzxmZmZmZmZmZjgxMDAxMjJhPl0gPyB4ZW5f
aHlwZXJjYWxsX3hlbl92ZXJzaW9uKzB4YS8weDIwDQpbICAzMTMuMDU2NzA4XSAgWzxmZmZm
ZmZmZjgxMDAxMjJhPl0gPyB4ZW5faHlwZXJjYWxsX3hlbl92ZXJzaW9uKzB4YS8weDIwDQpb
ICAzMTMuMDU2NzA4XSAgWzxmZmZmZmZmZjgxMDA4NjRkPl0gPyB4ZW5fZm9yY2VfZXZ0Y2hu
X2NhbGxiYWNrKzB4ZC8weDEwDQpbICAzMTMuMDU2NzA4XSAgWzxmZmZmZmZmZjgxMDA4ZmYy
Pl0gPyBjaGVja19ldmVudHMrMHgxMi8weDIwDQpbICAzMTMuMDU2NzA4XSAgWzxmZmZmZmZm
ZjgxMDA4Zjk5Pl0gPyB4ZW5faXJxX2VuYWJsZV9kaXJlY3RfcmVsb2MrMHg0LzB4NA0KWyAg
MzEzLjA1NjcwOF0gIFs8ZmZmZmZmZmY4MTc0OTE0Nj5dID8gaWEzMl9jc3Rhcl90YXJnZXQr
MHgxNi8weDhjDQpbICAzMTMuMDU2NzA4XSAtLS1bIGVuZCB0cmFjZSAyZTI4ZWVjOTNiN2E4
YjhjIF0tLS0NClsgIDMxMy41NDAyMDBdIC0tLS0tLS0tLS0tLVsgY3V0IGhlcmUgXS0tLS0t
LS0tLS0tLQ0KWyAgMzEzLjU0MDIxOF0gV0FSTklORzogYXQgZHJpdmVycy9uZXQveGVuLW5l
dGZyb250LmM6NDY1IHhlbm5ldF9zdGFydF94bWl0KzB4N2ZlLzB4ODYwKCkNClsgIDMxMy41
NDAyNDBdIE1vZHVsZXMgbGlua2VkIGluOg0KWyAgMzEzLjU0MDI0Nl0gUGlkOiAwLCBjb21t
OiBzd2FwcGVyLzAgVGFpbnRlZDogRyAgICAgICAgVyAgICAzLjYuMHByZS1yYzEtMjAxMjEw
MTEgIzENClsgIDMxMy41NDAyNTJdIENhbGwgVHJhY2U6DQpbICAzMTMuNTQwMjU2XSAgPElS
UT4gIFs8ZmZmZmZmZmY4MTA2NjRlYT5dIHdhcm5fc2xvd3BhdGhfY29tbW9uKzB4N2EvMHhi
MA0KWyAgMzEzLjU0MDI2OV0gIFs8ZmZmZmZmZmY4MTA2NjUzNT5dIHdhcm5fc2xvd3BhdGhf
bnVsbCsweDE1LzB4MjANClsgIDMxMy41NDAyNzRdICBbPGZmZmZmZmZmODE0NmQ4OWU+XSB4
ZW5uZXRfc3RhcnRfeG1pdCsweDdmZS8weDg2MA0KWyAgMzEzLjU0MDI4M10gIFs8ZmZmZmZm
ZmY4MTYxZjM0OT5dIGRldl9oYXJkX3N0YXJ0X3htaXQrMHgyMDkvMHg0NjANClsgIDMxMy41
NDAyOTBdICBbPGZmZmZmZmZmODE2M2IwMzY+XSBzY2hfZGlyZWN0X3htaXQrMHhmNi8weDI5
MA0KWyAgMzEzLjU0MDI5NV0gIFs8ZmZmZmZmZmY4MTYxZjc0Nj5dIGRldl9xdWV1ZV94bWl0
KzB4MWE2LzB4NWEwDQpbICAzMTMuNTQwMzAxXSAgWzxmZmZmZmZmZjgxNjFmNWEwPl0gPyBk
ZXZfaGFyZF9zdGFydF94bWl0KzB4NDYwLzB4NDYwDQpbICAzMTMuNTQwMzA4XSAgWzxmZmZm
ZmZmZjgxMGIxNDE3Pl0gPyBsb2NrX3JlbGVhc2UrMHgxMTcvMHgyNTANClsgIDMxMy41NDAz
MTZdICBbPGZmZmZmZmZmODE2Yjk1MzY+XSBpcF9maW5pc2hfb3V0cHV0KzB4MjI2LzB4NTMw
DQpbICAzMTMuNTQwMzIxXSAgWzxmZmZmZmZmZjgxNmI5M2RkPl0gPyBpcF9maW5pc2hfb3V0
cHV0KzB4Y2QvMHg1MzANClsgIDMxMy41NDAzMjddICBbPGZmZmZmZmZmODE2Yjk4OTk+XSBp
cF9vdXRwdXQrMHg1OS8weGUwDQpbICAzMTMuNTQwMzMzXSAgWzxmZmZmZmZmZjgxNmI4M2I4
Pl0gaXBfbG9jYWxfb3V0KzB4MjgvMHg5MA0KWyAgMzEzLjU0MDMzOF0gIFs8ZmZmZmZmZmY4
MTZiODk2Zj5dIGlwX3F1ZXVlX3htaXQrMHgxN2YvMHg0YTANClsgIDMxMy41NDAzNDRdICBb
PGZmZmZmZmZmODE2Yjg3ZjA+XSA/IGlwX3NlbmRfdW5pY2FzdF9yZXBseSsweDM0MC8weDM0
MA0KWyAgMzEzLjU0MDM1MF0gIFs8ZmZmZmZmZmY4MTBhMGJhNz5dID8gZ2V0bnN0aW1lb2Zk
YXkrMHg0Ny8weGUwDQpbICAzMTMuNTQwMzU3XSAgWzxmZmZmZmZmZjgxNjBmNGM5Pl0gPyBf
X3NrYl9jbG9uZSsweDI5LzB4MTIwDQpbICAzMTMuNTQwMzYzXSAgWzxmZmZmZmZmZjgxNmNl
YTIwPl0gdGNwX3RyYW5zbWl0X3NrYisweDQwMC8weDhkMA0KWyAgMzEzLjU0MDM2OV0gIFs8
ZmZmZmZmZmY4MTZkMTEwNj5dIHRjcF9yZXRyYW5zbWl0X3NrYisweDFjNi8weDVhMA0KWyAg
MzEzLjU0MDM3NV0gIFs8ZmZmZmZmZmY4MTZkMzNiMD5dID8gdGNwX3dyaXRlX3RpbWVyX2hh
bmRsZXIrMHgxYTAvMHgxYTANClsgIDMxMy41NDAzODFdICBbPGZmZmZmZmZmODE2ZDJmMzg+
XSB0Y3BfcmV0cmFuc21pdF90aW1lcisweDM1OC8weDYzMA0KWyAgMzEzLjU0MDM4Nl0gIFs8
ZmZmZmZmZmY4MTZkMzM0ZD5dIHRjcF93cml0ZV90aW1lcl9oYW5kbGVyKzB4MTNkLzB4MWEw
DQpbICAzMTMuNTQwMzkyXSAgWzxmZmZmZmZmZjgxNmQzNDI4Pl0gdGNwX3dyaXRlX3RpbWVy
KzB4NzgvMHg4MA0KWyAgMzEzLjU0MDM5OF0gIFs8ZmZmZmZmZmY4MTA3M2Y3Yz5dIGNhbGxf
dGltZXJfZm4rMHg3Yy8weDEwMA0KWyAgMzEzLjU0MDQwM10gIFs8ZmZmZmZmZmY4MTA3M2Yw
MD5dID8gY2FzY2FkZSsweGEwLzB4YTANClsgIDMxMy41NDA0MDhdICBbPGZmZmZmZmZmODE2
ZDMzYjA+XSA/IHRjcF93cml0ZV90aW1lcl9oYW5kbGVyKzB4MWEwLzB4MWEwDQpbICAzMTMu
NTQwNDE0XSAgWzxmZmZmZmZmZjgxNmQzM2IwPl0gPyB0Y3Bfd3JpdGVfdGltZXJfaGFuZGxl
cisweDFhMC8weDFhMA0KWyAgMzEzLjU0MDQ2OF0gIFs8ZmZmZmZmZmY4MTA3NDIxNz5dIHJ1
bl90aW1lcl9zb2Z0aXJxKzB4MjE3LzB4MjUwDQpbICAzMTMuNTQwNDc1XSAgWzxmZmZmZmZm
ZjgxMDZlM2Q5Pl0gX19kb19zb2Z0aXJxKzB4YzkvMHgxYTANClsgIDMxMy41NDA0ODNdICBb
PGZmZmZmZmZmODE3NDhkM2M+XSBjYWxsX3NvZnRpcnErMHgxYy8weDMwDQpbICAzMTMuNTQw
NDkwXSAgWzxmZmZmZmZmZjgxMDBlZGI1Pl0gZG9fc29mdGlycSsweDg1LzB4ZjANClsgIDMx
My41NDA0OTVdICBbPGZmZmZmZmZmODEwNmUyNGU+XSBpcnFfZXhpdCsweDllLzB4ZDANClsg
IDMxMy41NDA1MDJdICBbPGZmZmZmZmZmODEzMzlmNWY+XSB4ZW5fZXZ0Y2huX2RvX3VwY2Fs
bCsweDJmLzB4NDANClsgIDMxMy41NDA1MDhdICBbPGZmZmZmZmZmODE3NDhkOWU+XSB4ZW5f
ZG9faHlwZXJ2aXNvcl9jYWxsYmFjaysweDFlLzB4MzANClsgIDMxMy41NDA1MTNdICA8RU9J
PiAgWzxmZmZmZmZmZjgxMDAxM2FhPl0gPyB4ZW5faHlwZXJjYWxsX3NjaGVkX29wKzB4YS8w
eDIwDQpbICAzMTMuNTQwNTIzXSAgWzxmZmZmZmZmZjgxMDAxM2FhPl0gPyB4ZW5faHlwZXJj
YWxsX3NjaGVkX29wKzB4YS8weDIwDQpbICAzMTMuNTQwNTI5XSAgWzxmZmZmZmZmZjgxMDA4
NjkwPl0gPyB4ZW5fc2FmZV9oYWx0KzB4MTAvMHgyMA0KWyAgMzEzLjU0MDUzNV0gIFs8ZmZm
ZmZmZmY4MTAxNjBkMD5dID8gZGVmYXVsdF9pZGxlKzB4NDAvMHg5MA0KWyAgMzEzLjU0MDU0
MV0gIFs8ZmZmZmZmZmY4MTAxNjQ4Nj5dID8gY3B1X2lkbGUrMHg5Ni8weGYwDQpbICAzMTMu
NTQwNTQ2XSAgWzxmZmZmZmZmZjgxNzIyZDNjPl0gPyByZXN0X2luaXQrMHhiYy8weGQwDQpb
ICAzMTMuNTQwNTUxXSAgWzxmZmZmZmZmZjgxNzIyYzgwPl0gPyBjc3VtX3BhcnRpYWxfY29w
eV9nZW5lcmljKzB4MTcwLzB4MTcwDQpbICAzMTMuNTQwNTYwXSAgWzxmZmZmZmZmZjgxY2Uw
ZGYyPl0gPyBzdGFydF9rZXJuZWwrMHgzOTAvMHgzOWQNClsgIDMxMy41NDA1NjZdICBbPGZm
ZmZmZmZmODFjZTA4ODI+XSA/IGtlcm5lbF9pbml0KzB4MjBiLzB4MjBiDQpbICAzMTMuNTQw
NTcxXSAgWzxmZmZmZmZmZjgxY2UwMzU2Pl0gPyB4ODZfNjRfc3RhcnRfcmVzZXJ2YXRpb25z
KzB4MTMxLzB4MTM2DQpbICAzMTMuNTQwNTkwXSAgWzxmZmZmZmZmZjgxY2UzZDYwPl0gPyB4
ZW5fc3RhcnRfa2VybmVsKzB4NzBkLzB4NzBmDQpbICAzMTMuNTQwNTk1XSAtLS1bIGVuZCB0
cmFjZSAyZTI4ZWVjOTNiN2E4YjhkIF0tLS0NClsgIDMxNC41MTY4MTddIC0tLS0tLS0tLS0t
LVsgY3V0IGhlcmUgXS0tLS0tLS0tLS0tLQ0KWyAgMzE0LjUxNjg0NV0gV0FSTklORzogYXQg
ZHJpdmVycy9uZXQveGVuLW5ldGZyb250LmM6NDY1IHhlbm5ldF9zdGFydF94bWl0KzB4N2Zl
LzB4ODYwKCkNClsgIDMxNC41MTY4NThdIE1vZHVsZXMgbGlua2VkIGluOg0KWyAgMzE0LjUx
Njg3MF0gUGlkOiAwLCBjb21tOiBzd2FwcGVyLzAgVGFpbnRlZDogRyAgICAgICAgVyAgICAz
LjYuMHByZS1yYzEtMjAxMjEwMTEgIzENClsgIDMxNC41MTY4ODNdIENhbGwgVHJhY2U6DQpb
ICAzMTQuNTE2ODkwXSAgPElSUT4gIFs8ZmZmZmZmZmY4MTA2NjRlYT5dIHdhcm5fc2xvd3Bh
dGhfY29tbW9uKzB4N2EvMHhiMA0KWyAgMzE0LjUxNjkxMV0gIFs8ZmZmZmZmZmY4MTA2NjUz
NT5dIHdhcm5fc2xvd3BhdGhfbnVsbCsweDE1LzB4MjANClsgIDMxNC41MTY5MjNdICBbPGZm
ZmZmZmZmODE0NmQ4OWU+XSB4ZW5uZXRfc3RhcnRfeG1pdCsweDdmZS8weDg2MA0KWyAgMzE0
LjUxNjkzN10gIFs8ZmZmZmZmZmY4MTYxZjM0OT5dIGRldl9oYXJkX3N0YXJ0X3htaXQrMHgy
MDkvMHg0NjANClsgIDMxNC41MTY5NDldICBbPGZmZmZmZmZmODE2M2IwMzY+XSBzY2hfZGly
ZWN0X3htaXQrMHhmNi8weDI5MA0KWyAgMzE0LjUxNjk2MF0gIFs8ZmZmZmZmZmY4MTYxZjc0
Nj5dIGRldl9xdWV1ZV94bWl0KzB4MWE2LzB4NWEwDQpbICAzMTQuNTE2OTcyXSAgWzxmZmZm
ZmZmZjgxNjFmNWEwPl0gPyBkZXZfaGFyZF9zdGFydF94bWl0KzB4NDYwLzB4NDYwDQpbICAz
MTQuNTE2OTg0XSAgWzxmZmZmZmZmZjgxMGIxNDE3Pl0gPyBsb2NrX3JlbGVhc2UrMHgxMTcv
MHgyNTANClsgIDMxNC41MTY5OTldICBbPGZmZmZmZmZmODE2Yjk1MzY+XSBpcF9maW5pc2hf
b3V0cHV0KzB4MjI2LzB4NTMwDQpbICAzMTQuNTE3MDExXSAgWzxmZmZmZmZmZjgxNmI5M2Rk
Pl0gPyBpcF9maW5pc2hfb3V0cHV0KzB4Y2QvMHg1MzANClsgIDMxNC41MTcwMjNdICBbPGZm
ZmZmZmZmODE2Yjk4OTk+XSBpcF9vdXRwdXQrMHg1OS8weGUwDQpbICAzMTQuNTE3MDMzXSAg
WzxmZmZmZmZmZjgxNmI4M2I4Pl0gaXBfbG9jYWxfb3V0KzB4MjgvMHg5MA0KWyAgMzE0LjUx
NzA0NF0gIFs8ZmZmZmZmZmY4MTZiODk2Zj5dIGlwX3F1ZXVlX3htaXQrMHgxN2YvMHg0YTAN
ClsgIDMxNC41MTcwNTVdICBbPGZmZmZmZmZmODE2Yjg3ZjA+XSA/IGlwX3NlbmRfdW5pY2Fz
dF9yZXBseSsweDM0MC8weDM0MA0KWyAgMzE0LjUxNzA2N10gIFs8ZmZmZmZmZmY4MTBhMGJh
Nz5dID8gZ2V0bnN0aW1lb2ZkYXkrMHg0Ny8weGUwDQpbICAzMTQuNTE3MDc5XSAgWzxmZmZm
ZmZmZjgxNjBmNGM5Pl0gPyBfX3NrYl9jbG9uZSsweDI5LzB4MTIwDQpbICAzMTQuNTE3MDkw
XSAgWzxmZmZmZmZmZjgxNmNlYTIwPl0gdGNwX3RyYW5zbWl0X3NrYisweDQwMC8weDhkMA0K
WyAgMzE0LjUxNzEwMl0gIFs8ZmZmZmZmZmY4MTZkMTEwNj5dIHRjcF9yZXRyYW5zbWl0X3Nr
YisweDFjNi8weDVhMA0KWyAgMzE0LjUxNzExNF0gIFs8ZmZmZmZmZmY4MTZkMzNiMD5dID8g
dGNwX3dyaXRlX3RpbWVyX2hhbmRsZXIrMHgxYTAvMHgxYTANClsgIDMxNC41MTcxMjZdICBb
PGZmZmZmZmZmODE2ZDJmMzg+XSB0Y3BfcmV0cmFuc21pdF90aW1lcisweDM1OC8weDYzMA0K
WyAgMzE0LjUxNzEzOF0gIFs8ZmZmZmZmZmY4MTZkMzM0ZD5dIHRjcF93cml0ZV90aW1lcl9o
YW5kbGVyKzB4MTNkLzB4MWEwDQpbICAzMTQuNTE3MTUwXSAgWzxmZmZmZmZmZjgxNmQzNDI4
Pl0gdGNwX3dyaXRlX3RpbWVyKzB4NzgvMHg4MA0KWyAgMzE0LjUxNzE2MV0gIFs8ZmZmZmZm
ZmY4MTA3M2Y3Yz5dIGNhbGxfdGltZXJfZm4rMHg3Yy8weDEwMA0KWyAgMzE0LjUxNzE3MV0g
IFs8ZmZmZmZmZmY4MTA3M2YwMD5dID8gY2FzY2FkZSsweGEwLzB4YTANClsgIDMxNC41MTcx
ODFdICBbPGZmZmZmZmZmODE2ZDMzYjA+XSA/IHRjcF93cml0ZV90aW1lcl9oYW5kbGVyKzB4
MWEwLzB4MWEwDQpbICAzMTQuNTE3MTk0XSAgWzxmZmZmZmZmZjgxNmQzM2IwPl0gPyB0Y3Bf
d3JpdGVfdGltZXJfaGFuZGxlcisweDFhMC8weDFhMA0KWyAgMzE0LjUxNzIwNV0gIFs8ZmZm
ZmZmZmY4MTA3NDIxNz5dIHJ1bl90aW1lcl9zb2Z0aXJxKzB4MjE3LzB4MjUwDQpbICAzMTQu
NTE3MjE4XSAgWzxmZmZmZmZmZjgxMDZlM2Q5Pl0gX19kb19zb2Z0aXJxKzB4YzkvMHgxYTAN
ClsgIDMxNC41MTcyMzBdICBbPGZmZmZmZmZmODE3NDhkM2M+XSBjYWxsX3NvZnRpcnErMHgx
Yy8weDMwDQpbICAzMTQuNTE3MjQxXSAgWzxmZmZmZmZmZjgxMDBlZGI1Pl0gZG9fc29mdGly
cSsweDg1LzB4ZjANClsgIDMxNC41MTcyNTJdICBbPGZmZmZmZmZmODEwNmUyNGU+XSBpcnFf
ZXhpdCsweDllLzB4ZDANClsgIDMxNC41MTcyNjVdICBbPGZmZmZmZmZmODEzMzlmNWY+XSB4
ZW5fZXZ0Y2huX2RvX3VwY2FsbCsweDJmLzB4NDANClsgIDMxNC41MTcyNzddICBbPGZmZmZm
ZmZmODE3NDhkOWU+XSB4ZW5fZG9faHlwZXJ2aXNvcl9jYWxsYmFjaysweDFlLzB4MzANClsg
IDMxNC41MTcyODZdICA8RU9JPiAgWzxmZmZmZmZmZjgxMDAxM2FhPl0gPyB4ZW5faHlwZXJj
YWxsX3NjaGVkX29wKzB4YS8weDIwDQpbICAzMTQuNTE3MzA2XSAgWzxmZmZmZmZmZjgxMDAx
M2FhPl0gPyB4ZW5faHlwZXJjYWxsX3NjaGVkX29wKzB4YS8weDIwDQpbICAzMTQuNTE3MzE4
XSAgWzxmZmZmZmZmZjgxMDA4NjkwPl0gPyB4ZW5fc2FmZV9oYWx0KzB4MTAvMHgyMA0KWyAg
MzE0LjUxNzMyOV0gIFs8ZmZmZmZmZmY4MTAxNjBkMD5dID8gZGVmYXVsdF9pZGxlKzB4NDAv
MHg5MA0KWyAgMzE0LjUxNzM0MF0gIFs8ZmZmZmZmZmY4MTAxNjQ4Nj5dID8gY3B1X2lkbGUr
MHg5Ni8weGYwDQpbICAzMTQuNTE3MzUxXSAgWzxmZmZmZmZmZjgxNzIyZDNjPl0gPyByZXN0
X2luaXQrMHhiYy8weGQwDQpbICAzMTQuNTE3MzYxXSAgWzxmZmZmZmZmZjgxNzIyYzgwPl0g
PyBjc3VtX3BhcnRpYWxfY29weV9nZW5lcmljKzB4MTcwLzB4MTcwDQpbICAzMTQuNTE3Mzc1
XSAgWzxmZmZmZmZmZjgxY2UwZGYyPl0gPyBzdGFydF9rZXJuZWwrMHgzOTAvMHgzOWQNClsg
IDMxNC41MTczODZdICBbPGZmZmZmZmZmODFjZTA4ODI+XSA/IGtlcm5lbF9pbml0KzB4MjBi
LzB4MjBiDQpbICAzMTQuNTE3Mzk3XSAgWzxmZmZmZmZmZjgxY2UwMzU2Pl0gPyB4ODZfNjRf
c3RhcnRfcmVzZXJ2YXRpb25zKzB4MTMxLzB4MTM2DQpbICAzMTQuNTE3NDEwXSAgWzxmZmZm
ZmZmZjgxY2UzZDYwPl0gPyB4ZW5fc3RhcnRfa2VybmVsKzB4NzBkLzB4NzBmDQpbICAzMTQu
NTE3NDIxXSAtLS1bIGVuZCB0cmFjZSAyZTI4ZWVjOTNiN2E4YjhlIF0tLS0NClsgIDMxNi40
NjY4MzhdIC0tLS0tLS0tLS0tLVsgY3V0IGhlcmUgXS0tLS0tLS0tLS0tLQ0KWyAgMzE2LjQ2
Njg2N10gV0FSTklORzogYXQgZHJpdmVycy9uZXQveGVuLW5ldGZyb250LmM6NDY1IHhlbm5l
dF9zdGFydF94bWl0KzB4N2ZlLzB4ODYwKCkNClsgIDMxNi40NjY4ODFdIE1vZHVsZXMgbGlu
a2VkIGluOg0KWyAgMzE2LjQ2Njg5NF0gUGlkOiAwLCBjb21tOiBzd2FwcGVyLzAgVGFpbnRl
ZDogRyAgICAgICAgVyAgICAzLjYuMHByZS1yYzEtMjAxMjEwMTEgIzENClsgIDMxNi40NjY5
MDZdIENhbGwgVHJhY2U6DQpbICAzMTYuNDY2OTEyXSAgPElSUT4gIFs8ZmZmZmZmZmY4MTA2
NjRlYT5dIHdhcm5fc2xvd3BhdGhfY29tbW9uKzB4N2EvMHhiMA0KWyAgMzE2LjQ2NjkzNF0g
IFs8ZmZmZmZmZmY4MTA2NjUzNT5dIHdhcm5fc2xvd3BhdGhfbnVsbCsweDE1LzB4MjANClsg
IDMxNi40NjY5NDZdICBbPGZmZmZmZmZmODE0NmQ4OWU+XSB4ZW5uZXRfc3RhcnRfeG1pdCsw
eDdmZS8weDg2MA0KWyAgMzE2LjQ2Njk2MF0gIFs8ZmZmZmZmZmY4MTYxZjM0OT5dIGRldl9o
YXJkX3N0YXJ0X3htaXQrMHgyMDkvMHg0NjANClsgIDMxNi40NjY5NzNdICBbPGZmZmZmZmZm
ODE2M2IwMzY+XSBzY2hfZGlyZWN0X3htaXQrMHhmNi8weDI5MA0KWyAgMzE2LjQ2Njk4NF0g
IFs8ZmZmZmZmZmY4MTYxZjc0Nj5dIGRldl9xdWV1ZV94bWl0KzB4MWE2LzB4NWEwDQpbICAz
MTYuNDY2OTk5XSAgWzxmZmZmZmZmZjgxNjFmNWEwPl0gPyBkZXZfaGFyZF9zdGFydF94bWl0
KzB4NDYwLzB4NDYwDQpbICAzMTYuNDY3MDEyXSAgWzxmZmZmZmZmZjgxMGIxNDE3Pl0gPyBs
b2NrX3JlbGVhc2UrMHgxMTcvMHgyNTANClsgIDMxNi40NjcwMjVdICBbPGZmZmZmZmZmODE2
Yjk1MzY+XSBpcF9maW5pc2hfb3V0cHV0KzB4MjI2LzB4NTMwDQpbICAzMTYuNDY3MDM3XSAg
WzxmZmZmZmZmZjgxNmI5M2RkPl0gPyBpcF9maW5pc2hfb3V0cHV0KzB4Y2QvMHg1MzANClsg
IDMxNi40NjcwNDldICBbPGZmZmZmZmZmODE2Yjk4OTk+XSBpcF9vdXRwdXQrMHg1OS8weGUw
DQpbICAzMTYuNDY3MDYxXSAgWzxmZmZmZmZmZjgxNmI4M2I4Pl0gaXBfbG9jYWxfb3V0KzB4
MjgvMHg5MA0KWyAgMzE2LjQ2NzA3MV0gIFs8ZmZmZmZmZmY4MTZiODk2Zj5dIGlwX3F1ZXVl
X3htaXQrMHgxN2YvMHg0YTANClsgIDMxNi40NjcwODNdICBbPGZmZmZmZmZmODE2Yjg3ZjA+
XSA/IGlwX3NlbmRfdW5pY2FzdF9yZXBseSsweDM0MC8weDM0MA0KWyAgMzE2LjQ2NzA5Nl0g
IFs8ZmZmZmZmZmY4MTBhMGJhNz5dID8gZ2V0bnN0aW1lb2ZkYXkrMHg0Ny8weGUwDQpbICAz
MTYuNDY3MTA4XSAgWzxmZmZmZmZmZjgxNjBmNGM5Pl0gPyBfX3NrYl9jbG9uZSsweDI5LzB4
MTIwDQpbICAzMTYuNDY3MTE5XSAgWzxmZmZmZmZmZjgxNmNlYTIwPl0gdGNwX3RyYW5zbWl0
X3NrYisweDQwMC8weDhkMA0KWyAgMzE2LjQ2NzEzMV0gIFs8ZmZmZmZmZmY4MTZkMTEwNj5d
IHRjcF9yZXRyYW5zbWl0X3NrYisweDFjNi8weDVhMA0KWyAgMzE2LjQ2NzE0M10gIFs8ZmZm
ZmZmZmY4MTZkMzNiMD5dID8gdGNwX3dyaXRlX3RpbWVyX2hhbmRsZXIrMHgxYTAvMHgxYTAN
ClsgIDMxNi40NjcxNTVdICBbPGZmZmZmZmZmODE2ZDJmMzg+XSB0Y3BfcmV0cmFuc21pdF90
aW1lcisweDM1OC8weDYzMA0KWyAgMzE2LjQ2NzE2Nl0gIFs8ZmZmZmZmZmY4MTZkMzM0ZD5d
IHRjcF93cml0ZV90aW1lcl9oYW5kbGVyKzB4MTNkLzB4MWEwDQpbICAzMTYuNDY3MTc4XSAg
WzxmZmZmZmZmZjgxNmQzNDI4Pl0gdGNwX3dyaXRlX3RpbWVyKzB4NzgvMHg4MA0KWyAgMzE2
LjQ2NzE5MF0gIFs8ZmZmZmZmZmY4MTA3M2Y3Yz5dIGNhbGxfdGltZXJfZm4rMHg3Yy8weDEw
MA0KWyAgMzE2LjQ2NzIwMF0gIFs8ZmZmZmZmZmY4MTA3M2YwMD5dID8gY2FzY2FkZSsweGEw
LzB4YTANClsgIDMxNi40NjcyMTFdICBbPGZmZmZmZmZmODE2ZDMzYjA+XSA/IHRjcF93cml0
ZV90aW1lcl9oYW5kbGVyKzB4MWEwLzB4MWEwDQpbICAzMTYuNDY3MjIzXSAgWzxmZmZmZmZm
ZjgxNmQzM2IwPl0gPyB0Y3Bfd3JpdGVfdGltZXJfaGFuZGxlcisweDFhMC8weDFhMA0KWyAg
MzE2LjQ2NzIzNV0gIFs8ZmZmZmZmZmY4MTA3NDIxNz5dIHJ1bl90aW1lcl9zb2Z0aXJxKzB4
MjE3LzB4MjUwDQpbICAzMTYuNDY3MjQ4XSAgWzxmZmZmZmZmZjgxMDZlM2Q5Pl0gX19kb19z
b2Z0aXJxKzB4YzkvMHgxYTANClsgIDMxNi40NjcyNjBdICBbPGZmZmZmZmZmODE3NDhkM2M+
XSBjYWxsX3NvZnRpcnErMHgxYy8weDMwDQpbICAzMTYuNDY3MjcwXSAgWzxmZmZmZmZmZjgx
MDBlZGI1Pl0gZG9fc29mdGlycSsweDg1LzB4ZjANClsgIDMxNi40NjcyODFdICBbPGZmZmZm
ZmZmODEwNmUyNGU+XSBpcnFfZXhpdCsweDllLzB4ZDANClsgIDMxNi40NjcyOTNdICBbPGZm
ZmZmZmZmODEzMzlmNWY+XSB4ZW5fZXZ0Y2huX2RvX3VwY2FsbCsweDJmLzB4NDANClsgIDMx
Ni40NjczMDRdICBbPGZmZmZmZmZmODE3NDhkOWU+XSB4ZW5fZG9faHlwZXJ2aXNvcl9jYWxs
YmFjaysweDFlLzB4MzANClsgIDMxNi40NjczMTRdICA8RU9JPiAgWzxmZmZmZmZmZjgxMDAx
M2FhPl0gPyB4ZW5faHlwZXJjYWxsX3NjaGVkX29wKzB4YS8weDIwDQpbICAzMTYuNDY3MzM0
XSAgWzxmZmZmZmZmZjgxMDAxM2FhPl0gPyB4ZW5faHlwZXJjYWxsX3NjaGVkX29wKzB4YS8w
eDIwDQpbICAzMTYuNDY3MzQ3XSAgWzxmZmZmZmZmZjgxMDA4NjkwPl0gPyB4ZW5fc2FmZV9o
YWx0KzB4MTAvMHgyMA0KWyAgMzE2LjQ2NzM1OV0gIFs8ZmZmZmZmZmY4MTAxNjBkMD5dID8g
ZGVmYXVsdF9pZGxlKzB4NDAvMHg5MA0KWyAgMzE2LjQ2NzM2OV0gIFs8ZmZmZmZmZmY4MTAx
NjQ4Nj5dID8gY3B1X2lkbGUrMHg5Ni8weGYwDQpbICAzMTYuNDY3MzgwXSAgWzxmZmZmZmZm
ZjgxNzIyZDNjPl0gPyByZXN0X2luaXQrMHhiYy8weGQwDQpbICAzMTYuNDY3MzkwXSAgWzxm
ZmZmZmZmZjgxNzIyYzgwPl0gPyBjc3VtX3BhcnRpYWxfY29weV9nZW5lcmljKzB4MTcwLzB4
MTcwDQpbICAzMTYuNDY3NDAzXSAgWzxmZmZmZmZmZjgxY2UwZGYyPl0gPyBzdGFydF9rZXJu
ZWwrMHgzOTAvMHgzOWQNClsgIDMxNi40Njc0MTVdICBbPGZmZmZmZmZmODFjZTA4ODI+XSA/
IGtlcm5lbF9pbml0KzB4MjBiLzB4MjBiDQpbICAzMTYuNDY3NDI2XSAgWzxmZmZmZmZmZjgx
Y2UwMzU2Pl0gPyB4ODZfNjRfc3RhcnRfcmVzZXJ2YXRpb25zKzB4MTMxLzB4MTM2DQpbICAz
MTYuNDY3NDM5XSAgWzxmZmZmZmZmZjgxY2UzZDYwPl0gPyB4ZW5fc3RhcnRfa2VybmVsKzB4
NzBkLzB4NzBmDQpbICAzMTYuNDY3NDQ5XSAtLS1bIGVuZCB0cmFjZSAyZTI4ZWVjOTNiN2E4
YjhmIF0tLS0NClsgIDMyMC4zNzM0NDVdIC0tLS0tLS0tLS0tLVsgY3V0IGhlcmUgXS0tLS0t
LS0tLS0tLQ0KWyAgMzIwLjM3MzQ2NV0gV0FSTklORzogYXQgZHJpdmVycy9uZXQveGVuLW5l
dGZyb250LmM6NDY1IHhlbm5ldF9zdGFydF94bWl0KzB4N2ZlLzB4ODYwKCkNClsgIDMyMC4z
NzM0NzJdIE1vZHVsZXMgbGlua2VkIGluOg0KWyAgMzIwLjM3MzQ3OF0gUGlkOiAwLCBjb21t
OiBzd2FwcGVyLzAgVGFpbnRlZDogRyAgICAgICAgVyAgICAzLjYuMHByZS1yYzEtMjAxMjEw
MTEgIzENClsgIDMyMC4zNzM0ODldIENhbGwgVHJhY2U6DQpbICAzMjAuMzczNDkyXSAgPElS
UT4gIFs8ZmZmZmZmZmY4MTA2NjRlYT5dIHdhcm5fc2xvd3BhdGhfY29tbW9uKzB4N2EvMHhi
MA0KWyAgMzIwLjM3MzUwNV0gIFs8ZmZmZmZmZmY4MTA2NjUzNT5dIHdhcm5fc2xvd3BhdGhf
bnVsbCsweDE1LzB4MjANClsgIDMyMC4zNzM1MTFdICBbPGZmZmZmZmZmODE0NmQ4OWU+XSB4
ZW5uZXRfc3RhcnRfeG1pdCsweDdmZS8weDg2MA0KWyAgMzIwLjM3MzUxOV0gIFs8ZmZmZmZm
ZmY4MTYxZjM0OT5dIGRldl9oYXJkX3N0YXJ0X3htaXQrMHgyMDkvMHg0NjANClsgIDMyMC4z
NzM1MjZdICBbPGZmZmZmZmZmODE2M2IwMzY+XSBzY2hfZGlyZWN0X3htaXQrMHhmNi8weDI5
MA0KWyAgMzIwLjM3MzUzMl0gIFs8ZmZmZmZmZmY4MTYxZjc0Nj5dIGRldl9xdWV1ZV94bWl0
KzB4MWE2LzB4NWEwDQpbICAzMjAuMzczNTM4XSAgWzxmZmZmZmZmZjgxNjFmNWEwPl0gPyBk
ZXZfaGFyZF9zdGFydF94bWl0KzB4NDYwLzB4NDYwDQpbICAzMjAuMzczNTQ0XSAgWzxmZmZm
ZmZmZjgxMGIxNDE3Pl0gPyBsb2NrX3JlbGVhc2UrMHgxMTcvMHgyNTANClsgIDMyMC4zNzM1
NTJdICBbPGZmZmZmZmZmODE2Yjk1MzY+XSBpcF9maW5pc2hfb3V0cHV0KzB4MjI2LzB4NTMw
DQpbICAzMjAuMzczNTU3XSAgWzxmZmZmZmZmZjgxNmI5M2RkPl0gPyBpcF9maW5pc2hfb3V0
cHV0KzB4Y2QvMHg1MzANClsgIDMyMC4zNzM1NjRdICBbPGZmZmZmZmZmODE2Yjk4OTk+XSBp
cF9vdXRwdXQrMHg1OS8weGUwDQpbICAzMjAuMzczNTcwXSAgWzxmZmZmZmZmZjgxNmI4M2I4
Pl0gaXBfbG9jYWxfb3V0KzB4MjgvMHg5MA0KWyAgMzIwLjM3MzU3NV0gIFs8ZmZmZmZmZmY4
MTZiODk2Zj5dIGlwX3F1ZXVlX3htaXQrMHgxN2YvMHg0YTANClsgIDMyMC4zNzM1ODFdICBb
PGZmZmZmZmZmODE2Yjg3ZjA+XSA/IGlwX3NlbmRfdW5pY2FzdF9yZXBseSsweDM0MC8weDM0
MA0KWyAgMzIwLjM3MzU4N10gIFs8ZmZmZmZmZmY4MTBhMGJhNz5dID8gZ2V0bnN0aW1lb2Zk
YXkrMHg0Ny8weGUwDQpbICAzMjAuMzczNTk0XSAgWzxmZmZmZmZmZjgxNjBmNGM5Pl0gPyBf
X3NrYl9jbG9uZSsweDI5LzB4MTIwDQpbICAzMjAuMzczNjAwXSAgWzxmZmZmZmZmZjgxNmNl
YTIwPl0gdGNwX3RyYW5zbWl0X3NrYisweDQwMC8weDhkMA0KWyAgMzIwLjM3MzYwNl0gIFs8
ZmZmZmZmZmY4MTZkMTEwNj5dIHRjcF9yZXRyYW5zbWl0X3NrYisweDFjNi8weDVhMA0KWyAg
MzIwLjM3MzYxM10gIFs8ZmZmZmZmZmY4MTZkMzNiMD5dID8gdGNwX3dyaXRlX3RpbWVyX2hh
bmRsZXIrMHgxYTAvMHgxYTANClsgIDMyMC4zNzM2MTldICBbPGZmZmZmZmZmODE2ZDJmMzg+
XSB0Y3BfcmV0cmFuc21pdF90aW1lcisweDM1OC8weDYzMA0KWyAgMzIwLjM3MzYyNV0gIFs8
ZmZmZmZmZmY4MTZkMzM0ZD5dIHRjcF93cml0ZV90aW1lcl9oYW5kbGVyKzB4MTNkLzB4MWEw
DQpbICAzMjAuMzczNjMxXSAgWzxmZmZmZmZmZjgxNmQzNDI4Pl0gdGNwX3dyaXRlX3RpbWVy
KzB4NzgvMHg4MA0KWyAgMzIwLjM3MzY0MF0gIFs8ZmZmZmZmZmY4MTA3M2Y3Yz5dIGNhbGxf
dGltZXJfZm4rMHg3Yy8weDEwMA0KWyAgMzIwLjM3MzY0N10gIFs8ZmZmZmZmZmY4MTA3M2Yw
MD5dID8gY2FzY2FkZSsweGEwLzB4YTANClsgIDMyMC4zNzM2NTNdICBbPGZmZmZmZmZmODE2
ZDMzYjA+XSA/IHRjcF93cml0ZV90aW1lcl9oYW5kbGVyKzB4MWEwLzB4MWEwDQpbICAzMjAu
MzczNjU5XSAgWzxmZmZmZmZmZjgxNmQzM2IwPl0gPyB0Y3Bfd3JpdGVfdGltZXJfaGFuZGxl
cisweDFhMC8weDFhMA0KWyAgMzIwLjM3MzY2NV0gIFs8ZmZmZmZmZmY4MTA3NDIxNz5dIHJ1
bl90aW1lcl9zb2Z0aXJxKzB4MjE3LzB4MjUwDQpbICAzMjAuMzczNjcyXSAgWzxmZmZmZmZm
ZjgxMDZlM2Q5Pl0gX19kb19zb2Z0aXJxKzB4YzkvMHgxYTANClsgIDMyMC4zNzM2NzldICBb
PGZmZmZmZmZmODE3NDhkM2M+XSBjYWxsX3NvZnRpcnErMHgxYy8weDMwDQpbICAzMjAuMzcz
Njg1XSAgWzxmZmZmZmZmZjgxMDBlZGI1Pl0gZG9fc29mdGlycSsweDg1LzB4ZjANClsgIDMy
MC4zNzM2OTBdICBbPGZmZmZmZmZmODEwNmUyNGU+XSBpcnFfZXhpdCsweDllLzB4ZDANClsg
IDMyMC4zNzM2OTddICBbPGZmZmZmZmZmODEzMzlmNWY+XSB4ZW5fZXZ0Y2huX2RvX3VwY2Fs
bCsweDJmLzB4NDANClsgIDMyMC4zNzM3MDNdICBbPGZmZmZmZmZmODE3NDhkOWU+XSB4ZW5f
ZG9faHlwZXJ2aXNvcl9jYWxsYmFjaysweDFlLzB4MzANClsgIDMyMC4zNzM3MDhdICA8RU9J
PiAgWzxmZmZmZmZmZjgxMDAxM2FhPl0gPyB4ZW5faHlwZXJjYWxsX3NjaGVkX29wKzB4YS8w
eDIwDQpbICAzMjAuMzczNzE4XSAgWzxmZmZmZmZmZjgxMDAxM2FhPl0gPyB4ZW5faHlwZXJj
YWxsX3NjaGVkX29wKzB4YS8weDIwDQpbICAzMjAuMzczNzI3XSAgWzxmZmZmZmZmZjgxMDA4
NjkwPl0gPyB4ZW5fc2FmZV9oYWx0KzB4MTAvMHgyMA0KWyAgMzIwLjM3MzczM10gIFs8ZmZm
ZmZmZmY4MTAxNjBkMD5dID8gZGVmYXVsdF9pZGxlKzB4NDAvMHg5MA0KWyAgMzIwLjM3Mzcz
OV0gIFs8ZmZmZmZmZmY4MTAxNjQ4Nj5dID8gY3B1X2lkbGUrMHg5Ni8weGYwDQpbICAzMjAu
MzczNzQ0XSAgWzxmZmZmZmZmZjgxNzIyZDNjPl0gPyByZXN0X2luaXQrMHhiYy8weGQwDQpb
ICAzMjAuMzczNzQ5XSAgWzxmZmZmZmZmZjgxNzIyYzgwPl0gPyBjc3VtX3BhcnRpYWxfY29w
eV9nZW5lcmljKzB4MTcwLzB4MTcwDQpbICAzMjAuMzczNzU4XSAgWzxmZmZmZmZmZjgxY2Uw
ZGYyPl0gPyBzdGFydF9rZXJuZWwrMHgzOTAvMHgzOWQNClsgIDMyMC4zNzM3NjRdICBbPGZm
ZmZmZmZmODFjZTA4ODI+XSA/IGtlcm5lbF9pbml0KzB4MjBiLzB4MjBiDQpbICAzMjAuMzcz
NzY5XSAgWzxmZmZmZmZmZjgxY2UwMzU2Pl0gPyB4ODZfNjRfc3RhcnRfcmVzZXJ2YXRpb25z
KzB4MTMxLzB4MTM2DQpbICAzMjAuMzczNzc2XSAgWzxmZmZmZmZmZjgxY2UzZDYwPl0gPyB4
ZW5fc3RhcnRfa2VybmVsKzB4NzBkLzB4NzBmDQpbICAzMjAuMzczNzgyXSAtLS1bIGVuZCB0
cmFjZSAyZTI4ZWVjOTNiN2E4YjkwIF0tLS0NClsgIDMyOC4xODY5MDBdIC0tLS0tLS0tLS0t
LVsgY3V0IGhlcmUgXS0tLS0tLS0tLS0tLQ0KWyAgMzI4LjE4Njk0OF0gV0FSTklORzogYXQg
ZHJpdmVycy9uZXQveGVuLW5ldGZyb250LmM6NDY1IHhlbm5ldF9zdGFydF94bWl0KzB4N2Zl
LzB4ODYwKCkNClsgIDMyOC4xODY5NzRdIE1vZHVsZXMgbGlua2VkIGluOg0KWyAgMzI4LjE4
Njk5Nl0gUGlkOiAwLCBjb21tOiBzd2FwcGVyLzAgVGFpbnRlZDogRyAgICAgICAgVyAgICAz
LjYuMHByZS1yYzEtMjAxMjEwMTEgIzENClsgIDMyOC4xODcwMjBdIENhbGwgVHJhY2U6DQpb
ICAzMjguMTg3MDMzXSAgPElSUT4gIFs8ZmZmZmZmZmY4MTA2NjRlYT5dIHdhcm5fc2xvd3Bh
dGhfY29tbW9uKzB4N2EvMHhiMA0KWyAgMzI4LjE4NzA3NF0gIFs8ZmZmZmZmZmY4MTA2NjUz
NT5dIHdhcm5fc2xvd3BhdGhfbnVsbCsweDE1LzB4MjANClsgIDMyOC4xODcwOTddICBbPGZm
ZmZmZmZmODE0NmQ4OWU+XSB4ZW5uZXRfc3RhcnRfeG1pdCsweDdmZS8weDg2MA0KWyAgMzI4
LjE4NzEyNF0gIFs8ZmZmZmZmZmY4MTYxZjM0OT5dIGRldl9oYXJkX3N0YXJ0X3htaXQrMHgy
MDkvMHg0NjANClsgIDMyOC4xODcxNDhdICBbPGZmZmZmZmZmODE2M2IwMzY+XSBzY2hfZGly
ZWN0X3htaXQrMHhmNi8weDI5MA0KWyAgMzI4LjE4NzE3MV0gIFs8ZmZmZmZmZmY4MTYxZjc0
Nj5dIGRldl9xdWV1ZV94bWl0KzB4MWE2LzB4NWEwDQpbICAzMjguMTg3MTkzXSAgWzxmZmZm
ZmZmZjgxNjFmNWEwPl0gPyBkZXZfaGFyZF9zdGFydF94bWl0KzB4NDYwLzB4NDYwDQpbICAz
MjguMTg3MjE4XSAgWzxmZmZmZmZmZjgxMGIxNDE3Pl0gPyBsb2NrX3JlbGVhc2UrMHgxMTcv
MHgyNTANClsgIDMyOC4xODcyNDJdICBbPGZmZmZmZmZmODE2Yjk1MzY+XSBpcF9maW5pc2hf
b3V0cHV0KzB4MjI2LzB4NTMwDQpbICAzMjguMTg3MjY4XSAgWzxmZmZmZmZmZjgxNmI5M2Rk
Pl0gPyBpcF9maW5pc2hfb3V0cHV0KzB4Y2QvMHg1MzANClsgIDMyOC4xODcyOTFdICBbPGZm
ZmZmZmZmODE2Yjk4OTk+XSBpcF9vdXRwdXQrMHg1OS8weGUwDQpbICAzMjguMTg3MzE2XSAg
WzxmZmZmZmZmZjgxNmI4M2I4Pl0gaXBfbG9jYWxfb3V0KzB4MjgvMHg5MA0KWyAgMzI4LjE4
NzM0Ml0gIFs8ZmZmZmZmZmY4MTZiODk2Zj5dIGlwX3F1ZXVlX3htaXQrMHgxN2YvMHg0YTAN
ClsgIDMyOC4xODczNjRdICBbPGZmZmZmZmZmODE2Yjg3ZjA+XSA/IGlwX3NlbmRfdW5pY2Fz
dF9yZXBseSsweDM0MC8weDM0MA0KWyAgMzI4LjE4NzM4OV0gIFs8ZmZmZmZmZmY4MTBhMGJh
Nz5dID8gZ2V0bnN0aW1lb2ZkYXkrMHg0Ny8weGUwDQpbICAzMjguMTg3NDEyXSAgWzxmZmZm
ZmZmZjgxNjBmNGM5Pl0gPyBfX3NrYl9jbG9uZSsweDI5LzB4MTIwDQpbICAzMjguMTg3NDM0
XSAgWzxmZmZmZmZmZjgxNmNlYTIwPl0gdGNwX3RyYW5zbWl0X3NrYisweDQwMC8weDhkMA0K
WyAgMzI4LjE4NzQ1N10gIFs8ZmZmZmZmZmY4MTZkMTEwNj5dIHRjcF9yZXRyYW5zbWl0X3Nr
YisweDFjNi8weDVhMA0KWyAgMzI4LjE4NzQ4MV0gIFs8ZmZmZmZmZmY4MTZkMzNiMD5dID8g
dGNwX3dyaXRlX3RpbWVyX2hhbmRsZXIrMHgxYTAvMHgxYTANClsgIDMyOC4xODc1MDVdICBb
PGZmZmZmZmZmODE2ZDJmMzg+XSB0Y3BfcmV0cmFuc21pdF90aW1lcisweDM1OC8weDYzMA0K
WyAgMzI4LjE4NzUyOF0gIFs8ZmZmZmZmZmY4MTZkMzM0ZD5dIHRjcF93cml0ZV90aW1lcl9o
YW5kbGVyKzB4MTNkLzB4MWEwDQpbICAzMjguMTg3NTUxXSAgWzxmZmZmZmZmZjgxNmQzNDI4
Pl0gdGNwX3dyaXRlX3RpbWVyKzB4NzgvMHg4MA0KWyAgMzI4LjE4NzU3NF0gIFs8ZmZmZmZm
ZmY4MTA3M2Y3Yz5dIGNhbGxfdGltZXJfZm4rMHg3Yy8weDEwMA0KWyAgMzI4LjE4NzU5NF0g
IFs8ZmZmZmZmZmY4MTA3M2YwMD5dID8gY2FzY2FkZSsweGEwLzB4YTANClsgIDMyOC4xODc2
MTVdICBbPGZmZmZmZmZmODE2ZDMzYjA+XSA/IHRjcF93cml0ZV90aW1lcl9oYW5kbGVyKzB4
MWEwLzB4MWEwDQpbICAzMjguMTg3NjQwXSAgWzxmZmZmZmZmZjgxNmQzM2IwPl0gPyB0Y3Bf
d3JpdGVfdGltZXJfaGFuZGxlcisweDFhMC8weDFhMA0KWyAgMzI4LjE4NzY2M10gIFs8ZmZm
ZmZmZmY4MTA3NDIxNz5dIHJ1bl90aW1lcl9zb2Z0aXJxKzB4MjE3LzB4MjUwDQpbICAzMjgu
MTg3Njg4XSAgWzxmZmZmZmZmZjgxMDZlM2Q5Pl0gX19kb19zb2Z0aXJxKzB4YzkvMHgxYTAN
ClsgIDMyOC4xODc3MTFdICBbPGZmZmZmZmZmODE3NDhkM2M+XSBjYWxsX3NvZnRpcnErMHgx
Yy8weDMwDQpbICAzMjguMTg3NzMyXSAgWzxmZmZmZmZmZjgxMDBlZGI1Pl0gZG9fc29mdGly
cSsweDg1LzB4ZjANClsgIDMyOC4xODc3NTNdICBbPGZmZmZmZmZmODEwNmUyNGU+XSBpcnFf
ZXhpdCsweDllLzB4ZDANClsgIDMyOC4xODc3NzhdICBbPGZmZmZmZmZmODEzMzlmNWY+XSB4
ZW5fZXZ0Y2huX2RvX3VwY2FsbCsweDJmLzB4NDANClsgIDMyOC4xODc4MDFdICBbPGZmZmZm
ZmZmODE3NDhkOWU+XSB4ZW5fZG9faHlwZXJ2aXNvcl9jYWxsYmFjaysweDFlLzB4MzANClsg
IDMyOC4xODc4MjBdICA8RU9JPiAgWzxmZmZmZmZmZjgxMDAxM2FhPl0gPyB4ZW5faHlwZXJj
YWxsX3NjaGVkX29wKzB4YS8weDIwDQpbICAzMjguMTg3ODU5XSAgWzxmZmZmZmZmZjgxMDAx
M2FhPl0gPyB4ZW5faHlwZXJjYWxsX3NjaGVkX29wKzB4YS8weDIwDQpbICAzMjguMTg3ODgz
XSAgWzxmZmZmZmZmZjgxMDA4NjkwPl0gPyB4ZW5fc2FmZV9oYWx0KzB4MTAvMHgyMA0KWyAg
MzI4LjE4NzkwNV0gIFs8ZmZmZmZmZmY4MTAxNjBkMD5dID8gZGVmYXVsdF9pZGxlKzB4NDAv
MHg5MA0KWyAgMzI4LjE4NzkyN10gIFs8ZmZmZmZmZmY4MTAxNjQ4Nj5dID8gY3B1X2lkbGUr
MHg5Ni8weGYwDQpbICAzMjguMTg3OTQ3XSAgWzxmZmZmZmZmZjgxNzIyZDNjPl0gPyByZXN0
X2luaXQrMHhiYy8weGQwDQpbICAzMjguMTg3OTY3XSAgWzxmZmZmZmZmZjgxNzIyYzgwPl0g
PyBjc3VtX3BhcnRpYWxfY29weV9nZW5lcmljKzB4MTcwLzB4MTcwDQpbICAzMjguMTg3OTk0
XSAgWzxmZmZmZmZmZjgxY2UwZGYyPl0gPyBzdGFydF9rZXJuZWwrMHgzOTAvMHgzOWQNClsg
IDMyOC4xODgwMTddICBbPGZmZmZmZmZmODFjZTA4ODI+XSA/IGtlcm5lbF9pbml0KzB4MjBi
LzB4MjBiDQpbICAzMjguMTg4MDQwXSAgWzxmZmZmZmZmZjgxY2UwMzU2Pl0gPyB4ODZfNjRf
c3RhcnRfcmVzZXJ2YXRpb25zKzB4MTMxLzB4MTM2DQpbICAzMjguMTg4MDY1XSAgWzxmZmZm
ZmZmZjgxY2UzZDYwPl0gPyB4ZW5fc3RhcnRfa2VybmVsKzB4NzBkLzB4NzBmDQpbICAzMjgu
MTg4MDg3XSAtLS1bIGVuZCB0cmFjZSAyZTI4ZWVjOTNiN2E4YjkxIF0tLS0NClsgIDM0My43
ODY4ODNdIC0tLS0tLS0tLS0tLVsgY3V0IGhlcmUgXS0tLS0tLS0tLS0tLQ0KWyAgMzQzLjc4
NjkzNF0gV0FSTklORzogYXQgZHJpdmVycy9uZXQveGVuLW5ldGZyb250LmM6NDY1IHhlbm5l
dF9zdGFydF94bWl0KzB4N2ZlLzB4ODYwKCkNClsgIDM0My43ODY5NjBdIE1vZHVsZXMgbGlu
a2VkIGluOg0KWyAgMzQzLjc4Njk4Ml0gUGlkOiAwLCBjb21tOiBzd2FwcGVyLzAgVGFpbnRl
ZDogRyAgICAgICAgVyAgICAzLjYuMHByZS1yYzEtMjAxMjEwMTEgIzENClsgIDM0My43ODcw
MDZdIENhbGwgVHJhY2U6DQpbICAzNDMuNzg3MDE5XSAgPElSUT4gIFs8ZmZmZmZmZmY4MTA2
NjRlYT5dIHdhcm5fc2xvd3BhdGhfY29tbW9uKzB4N2EvMHhiMA0KWyAgMzQzLjc4NzA2MF0g
IFs8ZmZmZmZmZmY4MTA2NjUzNT5dIHdhcm5fc2xvd3BhdGhfbnVsbCsweDE1LzB4MjANClsg
IDM0My43ODcwODNdICBbPGZmZmZmZmZmODE0NmQ4OWU+XSB4ZW5uZXRfc3RhcnRfeG1pdCsw
eDdmZS8weDg2MA0KWyAgMzQzLjc4NzExMF0gIFs8ZmZmZmZmZmY4MTYxZjM0OT5dIGRldl9o
YXJkX3N0YXJ0X3htaXQrMHgyMDkvMHg0NjANClsgIDM0My43ODcxMzVdICBbPGZmZmZmZmZm
ODE2M2IwMzY+XSBzY2hfZGlyZWN0X3htaXQrMHhmNi8weDI5MA0KWyAgMzQzLjc4NzE1N10g
IFs8ZmZmZmZmZmY4MTYxZjc0Nj5dIGRldl9xdWV1ZV94bWl0KzB4MWE2LzB4NWEwDQpbICAz
NDMuNzg3MTgwXSAgWzxmZmZmZmZmZjgxNjFmNWEwPl0gPyBkZXZfaGFyZF9zdGFydF94bWl0
KzB4NDYwLzB4NDYwDQpbICAzNDMuNzg3MjAzXSAgWzxmZmZmZmZmZjgxNjI5YTc3Pl0gbmVp
Z2hfcmVzb2x2ZV9vdXRwdXQrMHgxMjcvMHgyNTANClsgIDM0My43ODcyMjldICBbPGZmZmZm
ZmZmODE2Yjk2YWQ+XSBpcF9maW5pc2hfb3V0cHV0KzB4MzlkLzB4NTMwDQpbICAzNDMuNzg3
MjUyXSAgWzxmZmZmZmZmZjgxNmI5M2RkPl0gPyBpcF9maW5pc2hfb3V0cHV0KzB4Y2QvMHg1
MzANClsgIDM0My43ODcyNzddICBbPGZmZmZmZmZmODE2Yjk4OTk+XSBpcF9vdXRwdXQrMHg1
OS8weGUwDQpbICAzNDMuNzg3Mjk4XSAgWzxmZmZmZmZmZjgxNmI4M2I4Pl0gaXBfbG9jYWxf
b3V0KzB4MjgvMHg5MA0KWyAgMzQzLjc4NzMyMF0gIFs8ZmZmZmZmZmY4MTZiODk2Zj5dIGlw
X3F1ZXVlX3htaXQrMHgxN2YvMHg0YTANClsgIDM0My43ODczNDJdICBbPGZmZmZmZmZmODE2
Yjg3ZjA+XSA/IGlwX3NlbmRfdW5pY2FzdF9yZXBseSsweDM0MC8weDM0MA0KWyAgMzQzLjc4
NzM2N10gIFs8ZmZmZmZmZmY4MTBhMGJhNz5dID8gZ2V0bnN0aW1lb2ZkYXkrMHg0Ny8weGUw
DQpbICAzNDMuNzg3MzkwXSAgWzxmZmZmZmZmZjgxNjBmNGM5Pl0gPyBfX3NrYl9jbG9uZSsw
eDI5LzB4MTIwDQpbICAzNDMuNzg3NDEyXSAgWzxmZmZmZmZmZjgxNmNlYTIwPl0gdGNwX3Ry
YW5zbWl0X3NrYisweDQwMC8weDhkMA0KWyAgMzQzLjc4NzQzNV0gIFs8ZmZmZmZmZmY4MTZk
MTEwNj5dIHRjcF9yZXRyYW5zbWl0X3NrYisweDFjNi8weDVhMA0KWyAgMzQzLjc4NzQ1OV0g
IFs8ZmZmZmZmZmY4MTZkMzNiMD5dID8gdGNwX3dyaXRlX3RpbWVyX2hhbmRsZXIrMHgxYTAv
MHgxYTANClsgIDM0My43ODc0ODJdICBbPGZmZmZmZmZmODE2ZDJmMzg+XSB0Y3BfcmV0cmFu
c21pdF90aW1lcisweDM1OC8weDYzMA0KWyAgMzQzLjc4NzUwNl0gIFs8ZmZmZmZmZmY4MTZk
MzM0ZD5dIHRjcF93cml0ZV90aW1lcl9oYW5kbGVyKzB4MTNkLzB4MWEwDQpbICAzNDMuNzg3
NTI5XSAgWzxmZmZmZmZmZjgxNmQzNDI4Pl0gdGNwX3dyaXRlX3RpbWVyKzB4NzgvMHg4MA0K
WyAgMzQzLjc4NzU1MF0gIFs8ZmZmZmZmZmY4MTA3M2Y3Yz5dIGNhbGxfdGltZXJfZm4rMHg3
Yy8weDEwMA0KWyAgMzQzLjc4NzU3MV0gIFs8ZmZmZmZmZmY4MTA3M2YwMD5dID8gY2FzY2Fk
ZSsweGEwLzB4YTANClsgIDM0My43ODc1OTFdICBbPGZmZmZmZmZmODE2ZDMzYjA+XSA/IHRj
cF93cml0ZV90aW1lcl9oYW5kbGVyKzB4MWEwLzB4MWEwDQpbICAzNDMuNzg3NjE1XSAgWzxm
ZmZmZmZmZjgxNmQzM2IwPl0gPyB0Y3Bfd3JpdGVfdGltZXJfaGFuZGxlcisweDFhMC8weDFh
MA0KWyAgMzQzLjc4NzYzOF0gIFs8ZmZmZmZmZmY4MTA3NDIxNz5dIHJ1bl90aW1lcl9zb2Z0
aXJxKzB4MjE3LzB4MjUwDQpbICAzNDMuNzg3NjYzXSAgWzxmZmZmZmZmZjgxMDZlM2Q5Pl0g
X19kb19zb2Z0aXJxKzB4YzkvMHgxYTANClsgIDM0My43ODc2ODZdICBbPGZmZmZmZmZmODE3
NDhkM2M+XSBjYWxsX3NvZnRpcnErMHgxYy8weDMwDQpbICAzNDMuNzg3NzA3XSAgWzxmZmZm
ZmZmZjgxMDBlZGI1Pl0gZG9fc29mdGlycSsweDg1LzB4ZjANClsgIDM0My43ODc3MjldICBb
PGZmZmZmZmZmODEwNmUyNGU+XSBpcnFfZXhpdCsweDllLzB4ZDANClsgIDM0My43ODc3NTJd
ICBbPGZmZmZmZmZmODEzMzlmNWY+XSB4ZW5fZXZ0Y2huX2RvX3VwY2FsbCsweDJmLzB4NDAN
ClsgIDM0My43ODc3NzRdICBbPGZmZmZmZmZmODE3NDhkOWU+XSB4ZW5fZG9faHlwZXJ2aXNv
cl9jYWxsYmFjaysweDFlLzB4MzANClsgIDM0My43ODc3OTNdICA8RU9JPiAgWzxmZmZmZmZm
ZjgxMDAxM2FhPl0gPyB4ZW5faHlwZXJjYWxsX3NjaGVkX29wKzB4YS8weDIwDQpbICAzNDMu
Nzg3ODMwXSAgWzxmZmZmZmZmZjgxMDAxM2FhPl0gPyB4ZW5faHlwZXJjYWxsX3NjaGVkX29w
KzB4YS8weDIwDQpbICAzNDMuNzg3ODU1XSAgWzxmZmZmZmZmZjgxMDA4NjkwPl0gPyB4ZW5f
c2FmZV9oYWx0KzB4MTAvMHgyMA0KWyAgMzQzLjc4Nzg3N10gIFs8ZmZmZmZmZmY4MTAxNjBk
MD5dID8gZGVmYXVsdF9pZGxlKzB4NDAvMHg5MA0KWyAgMzQzLjc4Nzg5OF0gIFs8ZmZmZmZm
ZmY4MTAxNjQ4Nj5dID8gY3B1X2lkbGUrMHg5Ni8weGYwDQpbICAzNDMuNzg3OTE4XSAgWzxm
ZmZmZmZmZjgxNzIyZDNjPl0gPyByZXN0X2luaXQrMHhiYy8weGQwDQpbICAzNDMuNzg3OTM4
XSAgWzxmZmZmZmZmZjgxNzIyYzgwPl0gPyBjc3VtX3BhcnRpYWxfY29weV9nZW5lcmljKzB4
MTcwLzB4MTcwDQpbICAzNDMuNzg3OTY0XSAgWzxmZmZmZmZmZjgxY2UwZGYyPl0gPyBzdGFy
dF9rZXJuZWwrMHgzOTAvMHgzOWQNClsgIDM0My43ODc5ODddICBbPGZmZmZmZmZmODFjZTA4
ODI+XSA/IGtlcm5lbF9pbml0KzB4MjBiLzB4MjBiDQpbICAzNDMuNzg4MDExXSAgWzxmZmZm
ZmZmZjgxY2UwMzU2Pl0gPyB4ODZfNjRfc3RhcnRfcmVzZXJ2YXRpb25zKzB4MTMxLzB4MTM2
DQpbICAzNDMuNzg4MDM1XSAgWzxmZmZmZmZmZjgxY2UzZDYwPl0gPyB4ZW5fc3RhcnRfa2Vy
bmVsKzB4NzBkLzB4NzBmDQpbICAzNDMuNzg4MDU2XSAtLS1bIGVuZCB0cmFjZSAyZTI4ZWVj
OTNiN2E4YjkyIF0tLS0NClsgIDM2OS4xMzgxMDhdIC0tLS0tLS0tLS0tLVsgY3V0IGhlcmUg
XS0tLS0tLS0tLS0tLQ0KWyAgMzY5LjEzODE0OF0gV0FSTklORzogYXQgZHJpdmVycy9uZXQv
eGVuLW5ldGZyb250LmM6NDY1IHhlbm5ldF9zdGFydF94bWl0KzB4N2ZlLzB4ODYwKCkNClsg
IDM2OS4xMzgxNTldIE1vZHVsZXMgbGlua2VkIGluOg0KWyAgMzY5LjEzODE2NV0gUGlkOiAy
MTY5LCBjb21tOiBzc2hkIFRhaW50ZWQ6IEcgICAgICAgIFcgICAgMy42LjBwcmUtcmMxLTIw
MTIxMDExICMxDQpbICAzNjkuMTM4MTcyXSBDYWxsIFRyYWNlOg0KWyAgMzY5LjEzODE3OV0g
IFs8ZmZmZmZmZmY4MTA2NjRlYT5dIHdhcm5fc2xvd3BhdGhfY29tbW9uKzB4N2EvMHhiMA0K
WyAgMzY5LjEzODE4Nl0gIFs8ZmZmZmZmZmY4MTA2NjUzNT5dIHdhcm5fc2xvd3BhdGhfbnVs
bCsweDE1LzB4MjANClsgIDM2OS4xMzgxOTFdICBbPGZmZmZmZmZmODE0NmQ4OWU+XSB4ZW5u
ZXRfc3RhcnRfeG1pdCsweDdmZS8weDg2MA0KWyAgMzY5LjEzODE5OV0gIFs8ZmZmZmZmZmY4
MTYxZjM0OT5dIGRldl9oYXJkX3N0YXJ0X3htaXQrMHgyMDkvMHg0NjANClsgIDM2OS4xMzgy
MDVdICBbPGZmZmZmZmZmODE2M2IwMzY+XSBzY2hfZGlyZWN0X3htaXQrMHhmNi8weDI5MA0K
WyAgMzY5LjEzODIxMV0gIFs8ZmZmZmZmZmY4MTYxZjc0Nj5dIGRldl9xdWV1ZV94bWl0KzB4
MWE2LzB4NWEwDQpbICAzNjkuMTM4MjE3XSAgWzxmZmZmZmZmZjgxNjFmNWEwPl0gPyBkZXZf
aGFyZF9zdGFydF94bWl0KzB4NDYwLzB4NDYwDQpbICAzNjkuMTM4MjIzXSAgWzxmZmZmZmZm
ZjgxMGFhOGU1Pl0gPyB0cmFjZV9zb2Z0aXJxc19vZmYrMHg4NS8weDFiMA0KWyAgMzY5LjEz
ODIzMV0gIFs8ZmZmZmZmZmY4MTZiOTUzNj5dIGlwX2ZpbmlzaF9vdXRwdXQrMHgyMjYvMHg1
MzANClsgIDM2OS4xMzgyMzZdICBbPGZmZmZmZmZmODE2YjkzZGQ+XSA/IGlwX2ZpbmlzaF9v
dXRwdXQrMHhjZC8weDUzMA0KWyAgMzY5LjEzODI0Ml0gIFs8ZmZmZmZmZmY4MTZiOTg5OT5d
IGlwX291dHB1dCsweDU5LzB4ZTANClsgIDM2OS4xMzgyNDddICBbPGZmZmZmZmZmODE2Yjgz
Yjg+XSBpcF9sb2NhbF9vdXQrMHgyOC8weDkwDQpbICAzNjkuMTM4MjUzXSAgWzxmZmZmZmZm
ZjgxNmI4OTZmPl0gaXBfcXVldWVfeG1pdCsweDE3Zi8weDRhMA0KWyAgMzY5LjEzODI1OF0g
IFs8ZmZmZmZmZmY4MTZiODdmMD5dID8gaXBfc2VuZF91bmljYXN0X3JlcGx5KzB4MzQwLzB4
MzQwDQpbICAzNjkuMTM4MjY1XSAgWzxmZmZmZmZmZjgxMGEwYmE3Pl0gPyBnZXRuc3RpbWVv
ZmRheSsweDQ3LzB4ZTANClsgIDM2OS4xMzgyNzFdICBbPGZmZmZmZmZmODE2MGY0Yzk+XSA/
IF9fc2tiX2Nsb25lKzB4MjkvMHgxMjANClsgIDM2OS4xMzgyNzddICBbPGZmZmZmZmZmODE2
Y2VhMjA+XSB0Y3BfdHJhbnNtaXRfc2tiKzB4NDAwLzB4OGQwDQpbICAzNjkuMTM4MjgzXSAg
WzxmZmZmZmZmZjgxNmQxOWZhPl0gdGNwX3dyaXRlX3htaXQrMHgyMWEvMHhhNTANClsgIDM2
OS4xMzgyODldICBbPGZmZmZmZmZmODE2ZDIyNWI+XSB0Y3BfcHVzaF9vbmUrMHgyYi8weDQw
DQpbICAzNjkuMTM4Mjk1XSAgWzxmZmZmZmZmZjgxNmMyZGVjPl0gdGNwX3NlbmRtc2crMHg4
ZGMvMHhlMjANClsgIDM2OS4xMzgzMDJdICBbPGZmZmZmZmZmODE2ZThmMTk+XSBpbmV0X3Nl
bmRtc2crMHhhOS8weDEwMA0KWyAgMzY5LjEzODMwN10gIFs8ZmZmZmZmZmY4MTZlOGU3MD5d
ID8gaW5ldF9hdXRvYmluZCsweDcwLzB4NzANClsgIDM2OS4xMzgzMTJdICBbPGZmZmZmZmZm
ODEwYjBmODg+XSA/IGxvY2tfYWNxdWlyZSsweGQ4LzB4MTAwDQpbICAzNjkuMTM4MzE5XSAg
WzxmZmZmZmZmZjgxNjA2MzBkPl0gc29ja19haW9fd3JpdGUrMHgxMmQvMHgxNDANClsgIDM2
OS4xMzgzMjZdICBbPGZmZmZmZmZmODExNDM1YjI+XSBkb19zeW5jX3dyaXRlKzB4YTIvMHhl
MA0KWyAgMzY5LjEzODMzMV0gIFs8ZmZmZmZmZmY4MTBhZDIyZD5dID8gdHJhY2VfaGFyZGly
cXNfb24rMHhkLzB4MTANClsgIDM2OS4xMzgzMzddICBbPGZmZmZmZmZmODExNDQxZDQ+XSB2
ZnNfd3JpdGUrMHgxNzQvMHgxOTANClsgIDM2OS4xMzgzNzZdICBbPGZmZmZmZmZmODExNDQy
ZmE+XSBzeXNfd3JpdGUrMHg1YS8weGEwDQpbICAzNjkuMTM4Mzg0XSAgWzxmZmZmZmZmZjgx
MmIzM2RlPl0gPyB0cmFjZV9oYXJkaXJxc19vbl90aHVuaysweDNhLzB4M2YNClsgIDM2OS4x
MzgzOTFdICBbPGZmZmZmZmZmODE3NDkxY2M+XSBjc3Rhcl9kaXNwYXRjaCsweDcvMHgyNg0K
WyAgMzY5LjEzODM5Nl0gLS0tWyBlbmQgdHJhY2UgMmUyOGVlYzkzYjdhOGI5MyBdLS0tDQpb
ICAzNjkuMTM4NDIyXSAtLS0tLS0tLS0tLS1bIGN1dCBoZXJlIF0tLS0tLS0tLS0tLS0NClsg
IDM2OS4xMzg0MjhdIFdBUk5JTkc6IGF0IGRyaXZlcnMvbmV0L3hlbi1uZXRmcm9udC5jOjQ2
NSB4ZW5uZXRfc3RhcnRfeG1pdCsweDdmZS8weDg2MCgpDQpbICAzNjkuMTM4NDM1XSBNb2R1
bGVzIGxpbmtlZCBpbjoNClsgIDM2OS4xMzg0MzldIFBpZDogMjE2OSwgY29tbTogc3NoZCBU
YWludGVkOiBHICAgICAgICBXICAgIDMuNi4wcHJlLXJjMS0yMDEyMTAxMSAjMQ0KWyAgMzY5
LjEzODQ0NV0gQ2FsbCBUcmFjZToNClsgIDM2OS4xMzg0NTBdICBbPGZmZmZmZmZmODEwNjY0
ZWE+XSB3YXJuX3Nsb3dwYXRoX2NvbW1vbisweDdhLzB4YjANClsgIDM2OS4xMzg0NTVdICBb
PGZmZmZmZmZmODEwNjY1MzU+XSB3YXJuX3Nsb3dwYXRoX251bGwrMHgxNS8weDIwDQpbICAz
NjkuMTM4NDYxXSAgWzxmZmZmZmZmZjgxNDZkODllPl0geGVubmV0X3N0YXJ0X3htaXQrMHg3
ZmUvMHg4NjANClsgIDM2OS4xMzg0NjhdICBbPGZmZmZmZmZmODE2MWYzNDk+XSBkZXZfaGFy
ZF9zdGFydF94bWl0KzB4MjA5LzB4NDYwDQpbICAzNjkuMTM4NDc0XSAgWzxmZmZmZmZmZjgx
NjNiMDM2Pl0gc2NoX2RpcmVjdF94bWl0KzB4ZjYvMHgyOTANClsgIDM2OS4xMzg0NzldICBb
PGZmZmZmZmZmODE2MWY3NDY+XSBkZXZfcXVldWVfeG1pdCsweDFhNi8weDVhMA0KWyAgMzY5
LjEzODQ4NV0gIFs8ZmZmZmZmZmY4MTYxZjVhMD5dID8gZGV2X2hhcmRfc3RhcnRfeG1pdCsw
eDQ2MC8weDQ2MA0KWyAgMzY5LjEzODQ5MV0gIFs8ZmZmZmZmZmY4MTBhYThlNT5dID8gdHJh
Y2Vfc29mdGlycXNfb2ZmKzB4ODUvMHgxYjANClsgIDM2OS4xMzg0OTddICBbPGZmZmZmZmZm
ODE2Yjk1MzY+XSBpcF9maW5pc2hfb3V0cHV0KzB4MjI2LzB4NTMwDQpbICAzNjkuMTM4NTAz
XSAgWzxmZmZmZmZmZjgxNmI5M2RkPl0gPyBpcF9maW5pc2hfb3V0cHV0KzB4Y2QvMHg1MzAN
ClsgIDM2OS4xMzg1MDldICBbPGZmZmZmZmZmODE2Yjk4OTk+XSBpcF9vdXRwdXQrMHg1OS8w
eGUwDQpbICAzNjkuMTM4NTE0XSAgWzxmZmZmZmZmZjgxNmI4M2I4Pl0gaXBfbG9jYWxfb3V0
KzB4MjgvMHg5MA0KWyAgMzY5LjEzODUyMF0gIFs8ZmZmZmZmZmY4MTZiODk2Zj5dIGlwX3F1
ZXVlX3htaXQrMHgxN2YvMHg0YTANClsgIDM2OS4xMzg1MjVdICBbPGZmZmZmZmZmODE2Yjg3
ZjA+XSA/IGlwX3NlbmRfdW5pY2FzdF9yZXBseSsweDM0MC8weDM0MA0KWyAgMzY5LjEzODUz
MV0gIFs8ZmZmZmZmZmY4MTBhMGJhNz5dID8gZ2V0bnN0aW1lb2ZkYXkrMHg0Ny8weGUwDQpb
ICAzNjkuMTM4NTM3XSAgWzxmZmZmZmZmZjgxNjBmNGM5Pl0gPyBfX3NrYl9jbG9uZSsweDI5
LzB4MTIwDQpbICAzNjkuMTM4NTQyXSAgWzxmZmZmZmZmZjgxNmNlYTIwPl0gdGNwX3RyYW5z
bWl0X3NrYisweDQwMC8weDhkMA0KWyAgMzY5LjEzODU0OF0gIFs8ZmZmZmZmZmY4MTZkMTlm
YT5dIHRjcF93cml0ZV94bWl0KzB4MjFhLzB4YTUwDQpbICAzNjkuMTM4NTU0XSAgWzxmZmZm
ZmZmZjgxNmQyMjlkPl0gX190Y3BfcHVzaF9wZW5kaW5nX2ZyYW1lcysweDJkLzB4OTANClsg
IDM2OS4xMzg1NjBdICBbPGZmZmZmZmZmODE2YzI2OTM+XSB0Y3Bfc2VuZG1zZysweDE4My8w
eGUyMA0KWyAgMzY5LjEzODU2Nl0gIFs8ZmZmZmZmZmY4MTZlOGYxOT5dIGluZXRfc2VuZG1z
ZysweGE5LzB4MTAwDQpbICAzNjkuMTM4NTcxXSAgWzxmZmZmZmZmZjgxNmU4ZTcwPl0gPyBp
bmV0X2F1dG9iaW5kKzB4NzAvMHg3MA0KWyAgMzY5LjEzODU3N10gIFs8ZmZmZmZmZmY4MTBi
MGY4OD5dID8gbG9ja19hY3F1aXJlKzB4ZDgvMHgxMDANClsgIDM2OS4xMzg1ODNdICBbPGZm
ZmZmZmZmODE2MDYzMGQ+XSBzb2NrX2Fpb193cml0ZSsweDEyZC8weDE0MA0KWyAgMzY5LjEz
ODU4OV0gIFs8ZmZmZmZmZmY4MTE0MzViMj5dIGRvX3N5bmNfd3JpdGUrMHhhMi8weGUwDQpb
ICAzNjkuMTM4NTk0XSAgWzxmZmZmZmZmZjgxMGFkMjJkPl0gPyB0cmFjZV9oYXJkaXJxc19v
bisweGQvMHgxMA0KWyAgMzY5LjEzODYwMF0gIFs8ZmZmZmZmZmY4MTE0NDFkND5dIHZmc193
cml0ZSsweDE3NC8weDE5MA0KWyAgMzY5LjEzODYwNV0gIFs8ZmZmZmZmZmY4MTE0NDJmYT5d
IHN5c193cml0ZSsweDVhLzB4YTANClsgIDM2OS4xMzg2MTFdICBbPGZmZmZmZmZmODEyYjMz
ZGU+XSA/IHRyYWNlX2hhcmRpcnFzX29uX3RodW5rKzB4M2EvMHgzZg0KWyAgMzY5LjEzODYx
N10gIFs8ZmZmZmZmZmY4MTc0OTFjYz5dIGNzdGFyX2Rpc3BhdGNoKzB4Ny8weDI2DQpbICAz
NjkuMTM4NjIxXSAtLS1bIGVuZCB0cmFjZSAyZTI4ZWVjOTNiN2E4Yjk0IF0tLS0NClsgIDM2
OS4xMzg2NDhdIC0tLS0tLS0tLS0tLVsgY3V0IGhlcmUgXS0tLS0tLS0tLS0tLQ0KWyAgMzY5
LjEzODY1M10gV0FSTklORzogYXQgZHJpdmVycy9uZXQveGVuLW5ldGZyb250LmM6NDY1IHhl
bm5ldF9zdGFydF94bWl0KzB4N2ZlLzB4ODYwKCkNClsgIDM2OS4xMzg2NTldIE1vZHVsZXMg
bGlua2VkIGluOg0KWyAgMzY5LjEzODY2NF0gUGlkOiAyMTY5LCBjb21tOiBzc2hkIFRhaW50
ZWQ6IEcgICAgICAgIFcgICAgMy42LjBwcmUtcmMxLTIwMTIxMDExICMxDQpbICAzNjkuMTM4
NjcwXSBDYWxsIFRyYWNlOg0KWyAgMzY5LjEzODY3NF0gIFs8ZmZmZmZmZmY4MTA2NjRlYT5d
IHdhcm5fc2xvd3BhdGhfY29tbW9uKzB4N2EvMHhiMA0KWyAgMzY5LjEzODY4MF0gIFs8ZmZm
ZmZmZmY4MTA2NjUzNT5dIHdhcm5fc2xvd3BhdGhfbnVsbCsweDE1LzB4MjANClsgIDM2OS4x
Mzg2ODZdICBbPGZmZmZmZmZmODE0NmQ4OWU+XSB4ZW5uZXRfc3RhcnRfeG1pdCsweDdmZS8w
eDg2MA0KWyAgMzY5LjEzODY5Ml0gIFs8ZmZmZmZmZmY4MTYxZjM0OT5dIGRldl9oYXJkX3N0
YXJ0X3htaXQrMHgyMDkvMHg0NjANClsgIDM2OS4xMzg2OThdICBbPGZmZmZmZmZmODE2M2Iw
MzY+XSBzY2hfZGlyZWN0X3htaXQrMHhmNi8weDI5MA0KWyAgMzY5LjEzODcwNF0gIFs8ZmZm
ZmZmZmY4MTYxZjc0Nj5dIGRldl9xdWV1ZV94bWl0KzB4MWE2LzB4NWEwDQpbICAzNjkuMTM4
NzA5XSAgWzxmZmZmZmZmZjgxNjFmNWEwPl0gPyBkZXZfaGFyZF9zdGFydF94bWl0KzB4NDYw
LzB4NDYwDQpbICAzNjkuMTM4NzE1XSAgWzxmZmZmZmZmZjgxMGFhOGU1Pl0gPyB0cmFjZV9z
b2Z0aXJxc19vZmYrMHg4NS8weDFiMA0KWyAgMzY5LjEzODcyMV0gIFs8ZmZmZmZmZmY4MTZi
OTUzNj5dIGlwX2ZpbmlzaF9vdXRwdXQrMHgyMjYvMHg1MzANClsgIDM2OS4xMzg3MjddICBb
PGZmZmZmZmZmODE2YjkzZGQ+XSA/IGlwX2ZpbmlzaF9vdXRwdXQrMHhjZC8weDUzMA0KWyAg
MzY5LjEzODczM10gIFs8ZmZmZmZmZmY4MTZiOTg5OT5dIGlwX291dHB1dCsweDU5LzB4ZTAN
ClsgIDM2OS4xMzg3MzldICBbPGZmZmZmZmZmODE2YjgzYjg+XSBpcF9sb2NhbF9vdXQrMHgy
OC8weDkwDQpbICAzNjkuMTM4NzQ0XSAgWzxmZmZmZmZmZjgxNmI4OTZmPl0gaXBfcXVldWVf
eG1pdCsweDE3Zi8weDRhMA0KWyAgMzY5LjEzODc1MF0gIFs8ZmZmZmZmZmY4MTZiODdmMD5d
ID8gaXBfc2VuZF91bmljYXN0X3JlcGx5KzB4MzQwLzB4MzQwDQpbICAzNjkuMTM4NzU2XSAg
WzxmZmZmZmZmZjgxMGEwYmE3Pl0gPyBnZXRuc3RpbWVvZmRheSsweDQ3LzB4ZTANClsgIDM2
OS4xMzg3NjJdICBbPGZmZmZmZmZmODE2MGY0Yzk+XSA/IF9fc2tiX2Nsb25lKzB4MjkvMHgx
MjANClsgIDM2OS4xMzg3NjddICBbPGZmZmZmZmZmODE2Y2VhMjA+XSB0Y3BfdHJhbnNtaXRf
c2tiKzB4NDAwLzB4OGQwDQpbICAzNjkuMTM4NzczXSAgWzxmZmZmZmZmZjgxNmQxOWZhPl0g
dGNwX3dyaXRlX3htaXQrMHgyMWEvMHhhNTANClsgIDM2OS4xMzg3NzldICBbPGZmZmZmZmZm
ODE2ZDIyOWQ+XSBfX3RjcF9wdXNoX3BlbmRpbmdfZnJhbWVzKzB4MmQvMHg5MA0KWyAgMzY5
LjEzODc4NV0gIFs8ZmZmZmZmZmY4MTZjMjY5Mz5dIHRjcF9zZW5kbXNnKzB4MTgzLzB4ZTIw
DQpbICAzNjkuMTM4NzkxXSAgWzxmZmZmZmZmZjgxNmU4ZjE5Pl0gaW5ldF9zZW5kbXNnKzB4
YTkvMHgxMDANClsgIDM2OS4xMzg3OTZdICBbPGZmZmZmZmZmODE2ZThlNzA+XSA/IGluZXRf
YXV0b2JpbmQrMHg3MC8weDcwDQpbICAzNjkuMTM4ODAyXSAgWzxmZmZmZmZmZjgxMGIwZjg4
Pl0gPyBsb2NrX2FjcXVpcmUrMHhkOC8weDEwMA0KWyAgMzY5LjEzODgwOF0gIFs8ZmZmZmZm
ZmY4MTYwNjMwZD5dIHNvY2tfYWlvX3dyaXRlKzB4MTJkLzB4MTQwDQpbICAzNjkuMTM4ODE0
XSAgWzxmZmZmZmZmZjgxMTQzNWIyPl0gZG9fc3luY193cml0ZSsweGEyLzB4ZTANClsgIDM2
OS4xMzg4MTldICBbPGZmZmZmZmZmODEwYWQyMmQ+XSA/IHRyYWNlX2hhcmRpcnFzX29uKzB4
ZC8weDEwDQpbICAzNjkuMTM4ODI1XSAgWzxmZmZmZmZmZjgxMTQ0MWQ0Pl0gdmZzX3dyaXRl
KzB4MTc0LzB4MTkwDQpbICAzNjkuMTM4ODMwXSAgWzxmZmZmZmZmZjgxMTQ0MmZhPl0gc3lz
X3dyaXRlKzB4NWEvMHhhMA0KWyAgMzY5LjEzODgzNl0gIFs8ZmZmZmZmZmY4MTJiMzNkZT5d
ID8gdHJhY2VfaGFyZGlycXNfb25fdGh1bmsrMHgzYS8weDNmDQpbICAzNjkuMTM4ODQyXSAg
WzxmZmZmZmZmZjgxNzQ5MWNjPl0gY3N0YXJfZGlzcGF0Y2grMHg3LzB4MjYNClsgIDM2OS4x
Mzg4NDddIC0tLVsgZW5kIHRyYWNlIDJlMjhlZWM5M2I3YThiOTUgXS0tLQ0KWyAgMzY5LjU3
MTc4NV0gLS0tLS0tLS0tLS0tWyBjdXQgaGVyZSBdLS0tLS0tLS0tLS0tDQpbICAzNjkuNTcx
ODExXSBXQVJOSU5HOiBhdCBkcml2ZXJzL25ldC94ZW4tbmV0ZnJvbnQuYzo0NjUgeGVubmV0
X3N0YXJ0X3htaXQrMHg3ZmUvMHg4NjAoKQ0KWyAgMzY5LjU3MTgxOF0gTW9kdWxlcyBsaW5r
ZWQgaW46DQpbICAzNjkuNTcxODI1XSBQaWQ6IDAsIGNvbW06IHN3YXBwZXIvMCBUYWludGVk
OiBHICAgICAgICBXICAgIDMuNi4wcHJlLXJjMS0yMDEyMTAxMSAjMQ0KWyAgMzY5LjU3MTgz
Ml0gQ2FsbCBUcmFjZToNClsgIDM2OS41NzE4MzVdICA8SVJRPiAgWzxmZmZmZmZmZjgxMDY2
NGVhPl0gd2Fybl9zbG93cGF0aF9jb21tb24rMHg3YS8weGIwDQpbICAzNjkuNTcxODQ4XSAg
WzxmZmZmZmZmZjgxMDY2NTM1Pl0gd2Fybl9zbG93cGF0aF9udWxsKzB4MTUvMHgyMA0KWyAg
MzY5LjU3MTg1NF0gIFs8ZmZmZmZmZmY4MTQ2ZDg5ZT5dIHhlbm5ldF9zdGFydF94bWl0KzB4
N2ZlLzB4ODYwDQpbICAzNjkuNTcxODYzXSAgWzxmZmZmZmZmZjgxNjFmMzQ5Pl0gZGV2X2hh
cmRfc3RhcnRfeG1pdCsweDIwOS8weDQ2MA0KWyAgMzY5LjU3MTg3MV0gIFs8ZmZmZmZmZmY4
MTYzYjAzNj5dIHNjaF9kaXJlY3RfeG1pdCsweGY2LzB4MjkwDQpbICAzNjkuNTcxODc3XSAg
WzxmZmZmZmZmZjgxNjFmNzQ2Pl0gZGV2X3F1ZXVlX3htaXQrMHgxYTYvMHg1YTANClsgIDM2
OS41NzE4ODNdICBbPGZmZmZmZmZmODE2MWY1YTA+XSA/IGRldl9oYXJkX3N0YXJ0X3htaXQr
MHg0NjAvMHg0NjANClsgIDM2OS41NzE4OTBdICBbPGZmZmZmZmZmODEwYjE0MTc+XSA/IGxv
Y2tfcmVsZWFzZSsweDExNy8weDI1MA0KWyAgMzY5LjU3MTg5OF0gIFs8ZmZmZmZmZmY4MTZi
OTUzNj5dIGlwX2ZpbmlzaF9vdXRwdXQrMHgyMjYvMHg1MzANClsgIDM2OS41NzE5MDNdICBb
PGZmZmZmZmZmODE2YjkzZGQ+XSA/IGlwX2ZpbmlzaF9vdXRwdXQrMHhjZC8weDUzMA0KWyAg
MzY5LjU3MTkwOV0gIFs8ZmZmZmZmZmY4MTZiOTg5OT5dIGlwX291dHB1dCsweDU5LzB4ZTAN
ClsgIDM2OS41NzE5MTVdICBbPGZmZmZmZmZmODE2YjgzYjg+XSBpcF9sb2NhbF9vdXQrMHgy
OC8weDkwDQpbICAzNjkuNTcxOTIyXSAgWzxmZmZmZmZmZjgxNmI4OTZmPl0gaXBfcXVldWVf
eG1pdCsweDE3Zi8weDRhMA0KWyAgMzY5LjU3MTkyN10gIFs8ZmZmZmZmZmY4MTZiODdmMD5d
ID8gaXBfc2VuZF91bmljYXN0X3JlcGx5KzB4MzQwLzB4MzQwDQpbICAzNjkuNTcxOTM0XSAg
WzxmZmZmZmZmZjgxMGEwYmE3Pl0gPyBnZXRuc3RpbWVvZmRheSsweDQ3LzB4ZTANClsgIDM2
OS41NzE5NDFdICBbPGZmZmZmZmZmODE2MGY0Yzk+XSA/IF9fc2tiX2Nsb25lKzB4MjkvMHgx
MjANClsgIDM2OS41NzE5NDddICBbPGZmZmZmZmZmODE2Y2VhMjA+XSB0Y3BfdHJhbnNtaXRf
c2tiKzB4NDAwLzB4OGQwDQpbICAzNjkuNTcxOTUzXSAgWzxmZmZmZmZmZjgxNmQxMTA2Pl0g
dGNwX3JldHJhbnNtaXRfc2tiKzB4MWM2LzB4NWEwDQpbICAzNjkuNTcxOTU5XSAgWzxmZmZm
ZmZmZjgxNmQxNjdlPl0gdGNwX3htaXRfcmV0cmFuc21pdF9xdWV1ZSsweDE5ZS8weDMwMA0K
WyAgMzY5LjU3MTk2NV0gIFs8ZmZmZmZmZmY4MTZjOTlmZj5dIHRjcF9mYXN0cmV0cmFuc19h
bGVydCsweDk0Zi8weGNiMA0KWyAgMzY5LjU3MTk3MV0gIFs8ZmZmZmZmZmY4MTZjYTcwYz5d
IHRjcF9hY2srMHg5YWMvMHgxMTUwDQpbICAzNjkuNTcxOTc3XSAgWzxmZmZmZmZmZjgxNmNk
ODU4Pl0gdGNwX3Jjdl9lc3RhYmxpc2hlZCsweDMxOC8weDY0MA0KWyAgMzY5LjU3MTk4M10g
IFs8ZmZmZmZmZmY4MTZkNWVlZj5dID8gdGNwX3Y0X3JjdisweDZjZi8weGIxMA0KWyAgMzY5
LjU3MTk4OV0gIFs8ZmZmZmZmZmY4MTZkNTRkNT5dIHRjcF92NF9kb19yY3YrMHgxMzUvMHg0
ODANClsgIDM2OS41NzE5OTZdICBbPGZmZmZmZmZmODE3NDYxZDI+XSA/IF9yYXdfc3Bpbl9s
b2NrX25lc3RlZCsweDQyLzB4NTANClsgIDM2OS41NzIwMDJdICBbPGZmZmZmZmZmODE2ZDVl
ZWY+XSA/IHRjcF92NF9yY3YrMHg2Y2YvMHhiMTANClsgIDM2OS41NzIwMDddICBbPGZmZmZm
ZmZmODE2ZDYxN2Q+XSB0Y3BfdjRfcmN2KzB4OTVkLzB4YjEwDQpbICAzNjkuNTcyMDEzXSAg
WzxmZmZmZmZmZjgxMGIwZjg4Pl0gPyBsb2NrX2FjcXVpcmUrMHhkOC8weDEwMA0KWyAgMzY5
LjU3MjAxOV0gIFs8ZmZmZmZmZmY4MTZiMjk5NT5dID8gaXBfbG9jYWxfZGVsaXZlcl9maW5p
c2grMHg0NS8weDIzMA0KWyAgMzY5LjU3MjAyNl0gIFs8ZmZmZmZmZmY4MTZiMmE2YT5dIGlw
X2xvY2FsX2RlbGl2ZXJfZmluaXNoKzB4MTFhLzB4MjMwDQpbICAzNjkuNTcyMDMxXSAgWzxm
ZmZmZmZmZjgxNmIyOTk1Pl0gPyBpcF9sb2NhbF9kZWxpdmVyX2ZpbmlzaCsweDQ1LzB4MjMw
DQpbICAzNjkuNTcyMDM3XSAgWzxmZmZmZmZmZjgxNmIyYmI4Pl0gaXBfbG9jYWxfZGVsaXZl
cisweDM4LzB4ODANClsgIDM2OS41NzIwNDNdICBbPGZmZmZmZmZmODE2YjIxN2E+XSBpcF9y
Y3ZfZmluaXNoKzB4MTVhLzB4NjMwDQpbICAzNjkuNTcyMDQ4XSAgWzxmZmZmZmZmZjgxNmIy
ODY4Pl0gaXBfcmN2KzB4MjE4LzB4MzAwDQpbICAzNjkuNTcyMDU0XSAgWzxmZmZmZmZmZjgx
NjFhYzhkPl0gX19uZXRpZl9yZWNlaXZlX3NrYisweDY1ZC8weDhkMA0KWyAgMzY5LjU3MjA2
MF0gIFs8ZmZmZmZmZmY4MTYxYTc3NT5dID8gX19uZXRpZl9yZWNlaXZlX3NrYisweDE0NS8w
eDhkMA0KWyAgMzY5LjU3MjA2Nl0gIFs8ZmZmZmZmZmY4MTBhZDIyZD5dID8gdHJhY2VfaGFy
ZGlycXNfb24rMHhkLzB4MTANClsgIDM2OS41NzIwNzNdICBbPGZmZmZmZmZmODEwZjk5NzM+
XSA/IGZyZWVfaG90X2NvbGRfcGFnZSsweDFiMy8weDFlMA0KWyAgMzY5LjU3MjA4MF0gIFs8
ZmZmZmZmZmY4MTYxZDFmOD5dIG5ldGlmX3JlY2VpdmVfc2tiKzB4MjgvMHhmMA0KWyAgMzY5
LjU3MjA4Nl0gIFs8ZmZmZmZmZmY4MTYxMmQwMz5dID8gX19wc2tiX3B1bGxfdGFpbCsweDI1
My8weDM0MA0KWyAgMzY5LjU3MjA5Ml0gIFs8ZmZmZmZmZmY4MTQ2ZTRjNT5dIHhlbm5ldF9w
b2xsKzB4YWQ1LzB4ZTEwDQpbICAzNjkuNTcyMDk4XSAgWzxmZmZmZmZmZjgxNjFkZmE2Pl0g
bmV0X3J4X2FjdGlvbisweDEzNi8weDI2MA0KWyAgMzY5LjU3MjEwNV0gIFs8ZmZmZmZmZmY4
MTA2ZTM4MT5dID8gX19kb19zb2Z0aXJxKzB4NzEvMHgxYTANClsgIDM2OS41NzIxMTBdICBb
PGZmZmZmZmZmODEwNmUzZDk+XSBfX2RvX3NvZnRpcnErMHhjOS8weDFhMA0KWyAgMzY5LjU3
MjExNl0gIFs8ZmZmZmZmZmY4MTc0OGQzYz5dIGNhbGxfc29mdGlycSsweDFjLzB4MzANClsg
IDM2OS41NzIxMjRdICBbPGZmZmZmZmZmODEwMGVkYjU+XSBkb19zb2Z0aXJxKzB4ODUvMHhm
MA0KWyAgMzY5LjU3MjEyOV0gIFs8ZmZmZmZmZmY4MTA2ZTI0ZT5dIGlycV9leGl0KzB4OWUv
MHhkMA0KWyAgMzY5LjU3MjEzN10gIFs8ZmZmZmZmZmY4MTMzOWY1Zj5dIHhlbl9ldnRjaG5f
ZG9fdXBjYWxsKzB4MmYvMHg0MA0KWyAgMzY5LjU3MjE0M10gIFs8ZmZmZmZmZmY4MTc0OGQ5
ZT5dIHhlbl9kb19oeXBlcnZpc29yX2NhbGxiYWNrKzB4MWUvMHgzMA0KWyAgMzY5LjU3MjE0
N10gIDxFT0k+ICBbPGZmZmZmZmZmODEwMDEzYWE+XSA/IHhlbl9oeXBlcmNhbGxfc2NoZWRf
b3ArMHhhLzB4MjANClsgIDM2OS41NzIxNThdICBbPGZmZmZmZmZmODEwMDEzYWE+XSA/IHhl
bl9oeXBlcmNhbGxfc2NoZWRfb3ArMHhhLzB4MjANClsgIDM2OS41NzIxNjVdICBbPGZmZmZm
ZmZmODEwMDg2OTA+XSA/IHhlbl9zYWZlX2hhbHQrMHgxMC8weDIwDQpbICAzNjkuNTcyMTcx
XSAgWzxmZmZmZmZmZjgxMDE2MGQwPl0gPyBkZWZhdWx0X2lkbGUrMHg0MC8weDkwDQpbICAz
NjkuNTcyMTc2XSAgWzxmZmZmZmZmZjgxMDE2NDg2Pl0gPyBjcHVfaWRsZSsweDk2LzB4ZjAN
ClsgIDM2OS41NzIxODZdICBbPGZmZmZmZmZmODE3MjJkM2M+XSA/IHJlc3RfaW5pdCsweGJj
LzB4ZDANClsgIDM2OS41NzIxOTJdICBbPGZmZmZmZmZmODE3MjJjODA+XSA/IGNzdW1fcGFy
dGlhbF9jb3B5X2dlbmVyaWMrMHgxNzAvMHgxNzANClsgIDM2OS41NzIyMDBdICBbPGZmZmZm
ZmZmODFjZTBkZjI+XSA/IHN0YXJ0X2tlcm5lbCsweDM5MC8weDM5ZA0KWyAgMzY5LjU3MjIw
Nl0gIFs8ZmZmZmZmZmY4MWNlMDg4Mj5dID8ga2VybmVsX2luaXQrMHgyMGIvMHgyMGINClsg
IDM2OS41NzIyMTJdICBbPGZmZmZmZmZmODFjZTAzNTY+XSA/IHg4Nl82NF9zdGFydF9yZXNl
cnZhdGlvbnMrMHgxMzEvMHgxMzYNClsgIDM2OS41NzIyMThdICBbPGZmZmZmZmZmODFjZTNk
NjA+XSA/IHhlbl9zdGFydF9rZXJuZWwrMHg3MGQvMHg3MGYNClsgIDM2OS41NzIyMjRdIC0t
LVsgZW5kIHRyYWNlIDJlMjhlZWM5M2I3YThiOTYgXS0tLQ0KWyAgMzY5LjU3MjI1MV0gLS0t
LS0tLS0tLS0tWyBjdXQgaGVyZSBdLS0tLS0tLS0tLS0tDQpbICAzNjkuNTcyMjU3XSBXQVJO
SU5HOiBhdCBkcml2ZXJzL25ldC94ZW4tbmV0ZnJvbnQuYzo0NjUgeGVubmV0X3N0YXJ0X3ht
aXQrMHg3ZmUvMHg4NjAoKQ0KWyAgMzY5LjU3MjI2NF0gTW9kdWxlcyBsaW5rZWQgaW46DQpb
ICAzNjkuNTcyMjY4XSBQaWQ6IDAsIGNvbW06IHN3YXBwZXIvMCBUYWludGVkOiBHICAgICAg
ICBXICAgIDMuNi4wcHJlLXJjMS0yMDEyMTAxMSAjMQ0KWyAgMzY5LjU3MjI3NF0gQ2FsbCBU
cmFjZToNClsgIDM2OS41NzIyNzddICA8SVJRPiAgWzxmZmZmZmZmZjgxMDY2NGVhPl0gd2Fy
bl9zbG93cGF0aF9jb21tb24rMHg3YS8weGIwDQpbICAzNjkuNTcyMjg2XSAgWzxmZmZmZmZm
ZjgxMDY2NTM1Pl0gd2Fybl9zbG93cGF0aF9udWxsKzB4MTUvMHgyMA0KWyAgMzY5LjU3MjI5
MV0gIFs8ZmZmZmZmZmY4MTQ2ZDg5ZT5dIHhlbm5ldF9zdGFydF94bWl0KzB4N2ZlLzB4ODYw
DQpbICAzNjkuNTcyMjk4XSAgWzxmZmZmZmZmZjgxNjFmMzQ5Pl0gZGV2X2hhcmRfc3RhcnRf
eG1pdCsweDIwOS8weDQ2MA0KWyAgMzY5LjU3MjMwNF0gIFs8ZmZmZmZmZmY4MTYzYjAzNj5d
IHNjaF9kaXJlY3RfeG1pdCsweGY2LzB4MjkwDQpbICAzNjkuNTcyMzA5XSAgWzxmZmZmZmZm
ZjgxNjFmNzQ2Pl0gZGV2X3F1ZXVlX3htaXQrMHgxYTYvMHg1YTANClsgIDM2OS41NzIzMTVd
ICBbPGZmZmZmZmZmODE2MWY1YTA+XSA/IGRldl9oYXJkX3N0YXJ0X3htaXQrMHg0NjAvMHg0
NjANClsgIDM2OS41NzIzMjFdICBbPGZmZmZmZmZmODEwYjE0MTc+XSA/IGxvY2tfcmVsZWFz
ZSsweDExNy8weDI1MA0KWyAgMzY5LjU3MjMyN10gIFs8ZmZmZmZmZmY4MTZiOTUzNj5dIGlw
X2ZpbmlzaF9vdXRwdXQrMHgyMjYvMHg1MzANClsgIDM2OS41NzIzMzNdICBbPGZmZmZmZmZm
ODE2YjkzZGQ+XSA/IGlwX2ZpbmlzaF9vdXRwdXQrMHhjZC8weDUzMA0KWyAgMzY5LjU3MjMz
OV0gIFs8ZmZmZmZmZmY4MTZiOTg5OT5dIGlwX291dHB1dCsweDU5LzB4ZTANClsgIDM2OS41
NzIzNDRdICBbPGZmZmZmZmZmODE2YjgzYjg+XSBpcF9sb2NhbF9vdXQrMHgyOC8weDkwDQpb
ICAzNjkuNTcyMzUwXSAgWzxmZmZmZmZmZjgxNmI4OTZmPl0gaXBfcXVldWVfeG1pdCsweDE3
Zi8weDRhMA0KWyAgMzY5LjU3MjM1NV0gIFs8ZmZmZmZmZmY4MTZiODdmMD5dID8gaXBfc2Vu
ZF91bmljYXN0X3JlcGx5KzB4MzQwLzB4MzQwDQpbICAzNjkuNTcyMzYxXSAgWzxmZmZmZmZm
ZjgxMGEwYmE3Pl0gPyBnZXRuc3RpbWVvZmRheSsweDQ3LzB4ZTANClsgIDM2OS41NzIzNzBd
ICBbPGZmZmZmZmZmODE2MGY0Yzk+XSA/IF9fc2tiX2Nsb25lKzB4MjkvMHgxMjANClsgIDM2
OS41NzIzNzZdICBbPGZmZmZmZmZmODE2Y2VhMjA+XSB0Y3BfdHJhbnNtaXRfc2tiKzB4NDAw
LzB4OGQwDQpbICAzNjkuNTcyMzgyXSAgWzxmZmZmZmZmZjgxNmQxMTA2Pl0gdGNwX3JldHJh
bnNtaXRfc2tiKzB4MWM2LzB4NWEwDQpbICAzNjkuNTcyMzg4XSAgWzxmZmZmZmZmZjgxNmQx
NjdlPl0gdGNwX3htaXRfcmV0cmFuc21pdF9xdWV1ZSsweDE5ZS8weDMwMA0KWyAgMzY5LjU3
MjM5NF0gIFs8ZmZmZmZmZmY4MTZjOTlmZj5dIHRjcF9mYXN0cmV0cmFuc19hbGVydCsweDk0
Zi8weGNiMA0KWyAgMzY5LjU3MjQwMF0gIFs8ZmZmZmZmZmY4MTZjYTcwYz5dIHRjcF9hY2sr
MHg5YWMvMHgxMTUwDQpbICAzNjkuNTcyNDA2XSAgWzxmZmZmZmZmZjgxNmNkODU4Pl0gdGNw
X3Jjdl9lc3RhYmxpc2hlZCsweDMxOC8weDY0MA0KWyAgMzY5LjU3MjQxMV0gIFs8ZmZmZmZm
ZmY4MTZkNWVlZj5dID8gdGNwX3Y0X3JjdisweDZjZi8weGIxMA0KWyAgMzY5LjU3MjQxN10g
IFs8ZmZmZmZmZmY4MTZkNTRkNT5dIHRjcF92NF9kb19yY3YrMHgxMzUvMHg0ODANClsgIDM2
OS41NzI0MjNdICBbPGZmZmZmZmZmODE3NDYxZDI+XSA/IF9yYXdfc3Bpbl9sb2NrX25lc3Rl
ZCsweDQyLzB4NTANClsgIDM2OS41NzI0MjldICBbPGZmZmZmZmZmODE2ZDVlZWY+XSA/IHRj
cF92NF9yY3YrMHg2Y2YvMHhiMTANClsgIDM2OS41NzI0MzRdICBbPGZmZmZmZmZmODE2ZDYx
N2Q+XSB0Y3BfdjRfcmN2KzB4OTVkLzB4YjEwDQpbICAzNjkuNTcyNDM5XSAgWzxmZmZmZmZm
ZjgxMGIwZjg4Pl0gPyBsb2NrX2FjcXVpcmUrMHhkOC8weDEwMA0KWyAgMzY5LjU3MjQ0NV0g
IFs8ZmZmZmZmZmY4MTZiMjk5NT5dID8gaXBfbG9jYWxfZGVsaXZlcl9maW5pc2grMHg0NS8w
eDIzMA0KWyAgMzY5LjU3MjQ1MV0gIFs8ZmZmZmZmZmY4MTZiMmE2YT5dIGlwX2xvY2FsX2Rl
bGl2ZXJfZmluaXNoKzB4MTFhLzB4MjMwDQpbICAzNjkuNTcyNDU3XSAgWzxmZmZmZmZmZjgx
NmIyOTk1Pl0gPyBpcF9sb2NhbF9kZWxpdmVyX2ZpbmlzaCsweDQ1LzB4MjMwDQpbICAzNjku
NTcyNDYzXSAgWzxmZmZmZmZmZjgxNmIyYmI4Pl0gaXBfbG9jYWxfZGVsaXZlcisweDM4LzB4
ODANClsgIDM2OS41NzI0NjldICBbPGZmZmZmZmZmODE2YjIxN2E+XSBpcF9yY3ZfZmluaXNo
KzB4MTVhLzB4NjMwDQpbICAzNjkuNTcyNDc0XSAgWzxmZmZmZmZmZjgxNmIyODY4Pl0gaXBf
cmN2KzB4MjE4LzB4MzAwDQpbICAzNjkuNTcyNDgwXSAgWzxmZmZmZmZmZjgxNjFhYzhkPl0g
X19uZXRpZl9yZWNlaXZlX3NrYisweDY1ZC8weDhkMA0KWyAgMzY5LjU3MjQ4Nl0gIFs8ZmZm
ZmZmZmY4MTYxYTc3NT5dID8gX19uZXRpZl9yZWNlaXZlX3NrYisweDE0NS8weDhkMA0KWyAg
MzY5LjU3MjQ5Ml0gIFs8ZmZmZmZmZmY4MTBhZDIyZD5dID8gdHJhY2VfaGFyZGlycXNfb24r
MHhkLzB4MTANClsgIDM2OS41NzI0OTddICBbPGZmZmZmZmZmODEwZjk5NzM+XSA/IGZyZWVf
aG90X2NvbGRfcGFnZSsweDFiMy8weDFlMA0KWyAgMzY5LjU3MjUwM10gIFs8ZmZmZmZmZmY4
MTYxZDFmOD5dIG5ldGlmX3JlY2VpdmVfc2tiKzB4MjgvMHhmMA0KWyAgMzY5LjU3MjUwOV0g
IFs8ZmZmZmZmZmY4MTYxMmQwMz5dID8gX19wc2tiX3B1bGxfdGFpbCsweDI1My8weDM0MA0K
WyAgMzY5LjU3MjUxNV0gIFs8ZmZmZmZmZmY4MTQ2ZTRjNT5dIHhlbm5ldF9wb2xsKzB4YWQ1
LzB4ZTEwDQpbICAzNjkuNTcyNTIxXSAgWzxmZmZmZmZmZjgxNjFkZmE2Pl0gbmV0X3J4X2Fj
dGlvbisweDEzNi8weDI2MA0KWyAgMzY5LjU3MjUyN10gIFs8ZmZmZmZmZmY4MTA2ZTM4MT5d
ID8gX19kb19zb2Z0aXJxKzB4NzEvMHgxYTANClsgIDM2OS41NzI1MzNdICBbPGZmZmZmZmZm
ODEwNmUzZDk+XSBfX2RvX3NvZnRpcnErMHhjOS8weDFhMA0KWyAgMzY5LjU3MjUzOF0gIFs8
ZmZmZmZmZmY4MTc0OGQzYz5dIGNhbGxfc29mdGlycSsweDFjLzB4MzANClsgIDM2OS41NzI1
NDNdICBbPGZmZmZmZmZmODEwMGVkYjU+XSBkb19zb2Z0aXJxKzB4ODUvMHhmMA0KWyAgMzY5
LjU3MjU0OV0gIFs8ZmZmZmZmZmY4MTA2ZTI0ZT5dIGlycV9leGl0KzB4OWUvMHhkMA0KWyAg
MzY5LjU3MjU1NV0gIFs8ZmZmZmZmZmY4MTMzOWY1Zj5dIHhlbl9ldnRjaG5fZG9fdXBjYWxs
KzB4MmYvMHg0MA0KWyAgMzY5LjU3MjU2MF0gIFs8ZmZmZmZmZmY4MTc0OGQ5ZT5dIHhlbl9k
b19oeXBlcnZpc29yX2NhbGxiYWNrKzB4MWUvMHgzMA0KWyAgMzY5LjU3MjU2Nl0gIDxFT0k+
ICBbPGZmZmZmZmZmODEwMDEzYWE+XSA/IHhlbl9oeXBlcmNhbGxfc2NoZWRfb3ArMHhhLzB4
MjANClsgIDM2OS41NzI1NzVdICBbPGZmZmZmZmZmODEwMDEzYWE+XSA/IHhlbl9oeXBlcmNh
bGxfc2NoZWRfb3ArMHhhLzB4MjANClsgIDM2OS41NzI1ODFdICBbPGZmZmZmZmZmODEwMDg2
OTA+XSA/IHhlbl9zYWZlX2hhbHQrMHgxMC8weDIwDQpbICAzNjkuNTcyNTg2XSAgWzxmZmZm
ZmZmZjgxMDE2MGQwPl0gPyBkZWZhdWx0X2lkbGUrMHg0MC8weDkwDQpbICAzNjkuNTcyNTky
XSAgWzxmZmZmZmZmZjgxMDE2NDg2Pl0gPyBjcHVfaWRsZSsweDk2LzB4ZjANClsgIDM2OS41
NzI1OTddICBbPGZmZmZmZmZmODE3MjJkM2M+XSA/IHJlc3RfaW5pdCsweGJjLzB4ZDANClsg
IDM2OS41NzI2MDJdICBbPGZmZmZmZmZmODE3MjJjODA+XSA/IGNzdW1fcGFydGlhbF9jb3B5
X2dlbmVyaWMrMHgxNzAvMHgxNzANClsgIDM2OS41NzI2MDhdICBbPGZmZmZmZmZmODFjZTBk
ZjI+XSA/IHN0YXJ0X2tlcm5lbCsweDM5MC8weDM5ZA0KWyAgMzY5LjU3MjYxNF0gIFs8ZmZm
ZmZmZmY4MWNlMDg4Mj5dID8ga2VybmVsX2luaXQrMHgyMGIvMHgyMGINClsgIDM2OS41NzI2
MTldICBbPGZmZmZmZmZmODFjZTAzNTY+XSA/IHg4Nl82NF9zdGFydF9yZXNlcnZhdGlvbnMr
MHgxMzEvMHgxMzYNClsgIDM2OS41NzI2MjZdICBbPGZmZmZmZmZmODFjZTNkNjA+XSA/IHhl
bl9zdGFydF9rZXJuZWwrMHg3MGQvMHg3MGYNClsgIDM2OS41NzI2MzFdIC0tLVsgZW5kIHRy
YWNlIDJlMjhlZWM5M2I3YThiOTcgXS0tLQ0KWyAgMzY5LjU3NDU3OV0gLS0tLS0tLS0tLS0t
WyBjdXQgaGVyZSBdLS0tLS0tLS0tLS0tDQpbICAzNjkuNTc0NTk5XSBXQVJOSU5HOiBhdCBk
cml2ZXJzL25ldC94ZW4tbmV0ZnJvbnQuYzo0NjUgeGVubmV0X3N0YXJ0X3htaXQrMHg3ZmUv
MHg4NjAoKQ0KWyAgMzY5LjU3NDYwNV0gTW9kdWxlcyBsaW5rZWQgaW46DQpbICAzNjkuNTc0
NjExXSBQaWQ6IDE1MjMsIGNvbW06IHN5c2xvZ2QgVGFpbnRlZDogRyAgICAgICAgVyAgICAz
LjYuMHByZS1yYzEtMjAxMjEwMTEgIzENClsgIDM2OS41NzQ2MTddIENhbGwgVHJhY2U6DQpb
ICAzNjkuNTc0NjIwXSAgPElSUT4gIFs8ZmZmZmZmZmY4MTA2NjRlYT5dIHdhcm5fc2xvd3Bh
dGhfY29tbW9uKzB4N2EvMHhiMA0KWyAgMzY5LjU3NDYyOV0gIFs8ZmZmZmZmZmY4MTA2NjUz
NT5dIHdhcm5fc2xvd3BhdGhfbnVsbCsweDE1LzB4MjANClsgIDM2OS41NzQ2MzVdICBbPGZm
ZmZmZmZmODE0NmQ4OWU+XSB4ZW5uZXRfc3RhcnRfeG1pdCsweDdmZS8weDg2MA0KWyAgMzY5
LjU3NDY0Ml0gIFs8ZmZmZmZmZmY4MTYxZjM0OT5dIGRldl9oYXJkX3N0YXJ0X3htaXQrMHgy
MDkvMHg0NjANClsgIDM2OS41NzQ2NDhdICBbPGZmZmZmZmZmODE2M2IwMzY+XSBzY2hfZGly
ZWN0X3htaXQrMHhmNi8weDI5MA0KWyAgMzY5LjU3NDY1M10gIFs8ZmZmZmZmZmY4MTYxZjc0
Nj5dIGRldl9xdWV1ZV94bWl0KzB4MWE2LzB4NWEwDQpbICAzNjkuNTc0NjU5XSAgWzxmZmZm
ZmZmZjgxNjFmNWEwPl0gPyBkZXZfaGFyZF9zdGFydF94bWl0KzB4NDYwLzB4NDYwDQpbICAz
NjkuNTc0NjY1XSAgWzxmZmZmZmZmZjgxMGIxNDE3Pl0gPyBsb2NrX3JlbGVhc2UrMHgxMTcv
MHgyNTANClsgIDM2OS41NzQ2NzFdICBbPGZmZmZmZmZmODE2Yjk1MzY+XSBpcF9maW5pc2hf
b3V0cHV0KzB4MjI2LzB4NTMwDQpbICAzNjkuNTc0Njc3XSAgWzxmZmZmZmZmZjgxNmI5M2Rk
Pl0gPyBpcF9maW5pc2hfb3V0cHV0KzB4Y2QvMHg1MzANClsgIDM2OS41NzQ2ODNdICBbPGZm
ZmZmZmZmODE2Yjk4OTk+XSBpcF9vdXRwdXQrMHg1OS8weGUwDQpbICAzNjkuNTc0Njg4XSAg
WzxmZmZmZmZmZjgxNmI4M2I4Pl0gaXBfbG9jYWxfb3V0KzB4MjgvMHg5MA0KWyAgMzY5LjU3
NDY5NF0gIFs8ZmZmZmZmZmY4MTZiODk2Zj5dIGlwX3F1ZXVlX3htaXQrMHgxN2YvMHg0YTAN
ClsgIDM2OS41NzQ2OTldICBbPGZmZmZmZmZmODE2Yjg3ZjA+XSA/IGlwX3NlbmRfdW5pY2Fz
dF9yZXBseSsweDM0MC8weDM0MA0KWyAgMzY5LjU3NDcwNl0gIFs8ZmZmZmZmZmY4MTBhMGJh
Nz5dID8gZ2V0bnN0aW1lb2ZkYXkrMHg0Ny8weGUwDQpbICAzNjkuNTc0NzEyXSAgWzxmZmZm
ZmZmZjgxNjBmNGM5Pl0gPyBfX3NrYl9jbG9uZSsweDI5LzB4MTIwDQpbICAzNjkuNTc0NzE4
XSAgWzxmZmZmZmZmZjgxNmNlYTIwPl0gdGNwX3RyYW5zbWl0X3NrYisweDQwMC8weDhkMA0K
WyAgMzY5LjU3NDcyOF0gIFs8ZmZmZmZmZmY4MTZkMTEwNj5dIHRjcF9yZXRyYW5zbWl0X3Nr
YisweDFjNi8weDVhMA0KWyAgMzY5LjU3NDczNF0gIFs8ZmZmZmZmZmY4MTc0NmNiNT5dID8g
X3Jhd19zcGluX3VubG9ja19pcnFyZXN0b3JlKzB4NzUvMHhhMA0KWyAgMzY5LjU3NDc0MF0g
IFs8ZmZmZmZmZmY4MTZkMTY3ZT5dIHRjcF94bWl0X3JldHJhbnNtaXRfcXVldWUrMHgxOWUv
MHgzMDANClsgIDM2OS41NzQ3NDZdICBbPGZmZmZmZmZmODE2Yzk5ZmY+XSB0Y3BfZmFzdHJl
dHJhbnNfYWxlcnQrMHg5NGYvMHhjYjANClsgIDM2OS41NzQ3NTJdICBbPGZmZmZmZmZmODE2
Y2E3MGM+XSB0Y3BfYWNrKzB4OWFjLzB4MTE1MA0KWyAgMzY5LjU3NDc1OF0gIFs8ZmZmZmZm
ZmY4MTZjZDhjZT5dIHRjcF9yY3ZfZXN0YWJsaXNoZWQrMHgzOGUvMHg2NDANClsgIDM2OS41
NzQ3NjNdICBbPGZmZmZmZmZmODE2ZDVlZWY+XSA/IHRjcF92NF9yY3YrMHg2Y2YvMHhiMTAN
ClsgIDM2OS41NzQ3NjldICBbPGZmZmZmZmZmODE2ZDU0ZDU+XSB0Y3BfdjRfZG9fcmN2KzB4
MTM1LzB4NDgwDQpbICAzNjkuNTc0Nzc1XSAgWzxmZmZmZmZmZjgxNzQ2MWQyPl0gPyBfcmF3
X3NwaW5fbG9ja19uZXN0ZWQrMHg0Mi8weDUwDQpbICAzNjkuNTc0NzgxXSAgWzxmZmZmZmZm
ZjgxNmQ1ZWVmPl0gPyB0Y3BfdjRfcmN2KzB4NmNmLzB4YjEwDQpbICAzNjkuNTc0Nzg2XSAg
WzxmZmZmZmZmZjgxNmQ2MTdkPl0gdGNwX3Y0X3JjdisweDk1ZC8weGIxMA0KWyAgMzY5LjU3
NDc5Ml0gIFs8ZmZmZmZmZmY4MTBiMGY4OD5dID8gbG9ja19hY3F1aXJlKzB4ZDgvMHgxMDAN
ClsgIDM2OS41NzQ3OTddICBbPGZmZmZmZmZmODE2YjI5OTU+XSA/IGlwX2xvY2FsX2RlbGl2
ZXJfZmluaXNoKzB4NDUvMHgyMzANClsgIDM2OS41NzQ4MDRdICBbPGZmZmZmZmZmODE2YjJh
NmE+XSBpcF9sb2NhbF9kZWxpdmVyX2ZpbmlzaCsweDExYS8weDIzMA0KWyAgMzY5LjU3NDgx
MF0gIFs8ZmZmZmZmZmY4MTZiMjk5NT5dID8gaXBfbG9jYWxfZGVsaXZlcl9maW5pc2grMHg0
NS8weDIzMA0KWyAgMzY5LjU3NDgxNl0gIFs8ZmZmZmZmZmY4MTZiMmJiOD5dIGlwX2xvY2Fs
X2RlbGl2ZXIrMHgzOC8weDgwDQpbICAzNjkuNTc0ODIxXSAgWzxmZmZmZmZmZjgxNmIyMTdh
Pl0gaXBfcmN2X2ZpbmlzaCsweDE1YS8weDYzMA0KWyAgMzY5LjU3NDgyN10gIFs8ZmZmZmZm
ZmY4MTZiMjg2OD5dIGlwX3JjdisweDIxOC8weDMwMA0KWyAgMzY5LjU3NDgzMl0gIFs8ZmZm
ZmZmZmY4MTYxYWM4ZD5dIF9fbmV0aWZfcmVjZWl2ZV9za2IrMHg2NWQvMHg4ZDANClsgIDM2
OS41NzQ4MzhdICBbPGZmZmZmZmZmODE2MWE3NzU+XSA/IF9fbmV0aWZfcmVjZWl2ZV9za2Ir
MHgxNDUvMHg4ZDANClsgIDM2OS41NzQ4NDNdICBbPGZmZmZmZmZmODEwYWQyMmQ+XSA/IHRy
YWNlX2hhcmRpcnFzX29uKzB4ZC8weDEwDQpbICAzNjkuNTc0ODUwXSAgWzxmZmZmZmZmZjgx
MGY5OTczPl0gPyBmcmVlX2hvdF9jb2xkX3BhZ2UrMHgxYjMvMHgxZTANClsgIDM2OS41NzQ4
NTZdICBbPGZmZmZmZmZmODE2MWQxZjg+XSBuZXRpZl9yZWNlaXZlX3NrYisweDI4LzB4ZjAN
ClsgIDM2OS41NzQ4NjJdICBbPGZmZmZmZmZmODE2MTJkMDM+XSA/IF9fcHNrYl9wdWxsX3Rh
aWwrMHgyNTMvMHgzNDANClsgIDM2OS41NzQ4NjddICBbPGZmZmZmZmZmODE0NmU0YzU+XSB4
ZW5uZXRfcG9sbCsweGFkNS8weGUxMA0KWyAgMzY5LjU3NDg3NF0gIFs8ZmZmZmZmZmY4MTYx
ZGZhNj5dIG5ldF9yeF9hY3Rpb24rMHgxMzYvMHgyNjANClsgIDM2OS41NzQ4NzldICBbPGZm
ZmZmZmZmODEwNmUzODE+XSA/IF9fZG9fc29mdGlycSsweDcxLzB4MWEwDQpbICAzNjkuNTc0
ODg1XSAgWzxmZmZmZmZmZjgxMDZlM2Q5Pl0gX19kb19zb2Z0aXJxKzB4YzkvMHgxYTANClsg
IDM2OS41NzQ4OTFdICBbPGZmZmZmZmZmODE3NDhkM2M+XSBjYWxsX3NvZnRpcnErMHgxYy8w
eDMwDQpbICAzNjkuNTc0ODk2XSAgWzxmZmZmZmZmZjgxMDBlZGI1Pl0gZG9fc29mdGlycSsw
eDg1LzB4ZjANClsgIDM2OS41NzQ5MDFdICBbPGZmZmZmZmZmODEwNmUyNGU+XSBpcnFfZXhp
dCsweDllLzB4ZDANClsgIDM2OS41NzQ5MDddICBbPGZmZmZmZmZmODEzMzlmNWY+XSB4ZW5f
ZXZ0Y2huX2RvX3VwY2FsbCsweDJmLzB4NDANClsgIDM2OS41NzQ5MTNdICBbPGZmZmZmZmZm
ODE3NDhkOWU+XSB4ZW5fZG9faHlwZXJ2aXNvcl9jYWxsYmFjaysweDFlLzB4MzANClsgIDM2
OS41NzQ5MThdICA8RU9JPiAgWzxmZmZmZmZmZjgxMDAxMjJhPl0gPyB4ZW5faHlwZXJjYWxs
X3hlbl92ZXJzaW9uKzB4YS8weDIwDQpbICAzNjkuNTc0OTI4XSAgWzxmZmZmZmZmZjgxMDAx
MjJhPl0gPyB4ZW5faHlwZXJjYWxsX3hlbl92ZXJzaW9uKzB4YS8weDIwDQpbICAzNjkuNTc0
OTM0XSAgWzxmZmZmZmZmZjgxMDA4NjRkPl0gPyB4ZW5fZm9yY2VfZXZ0Y2huX2NhbGxiYWNr
KzB4ZC8weDEwDQpbICAzNjkuNTc0OTQwXSAgWzxmZmZmZmZmZjgxMDA4ZmYyPl0gPyBjaGVj
a19ldmVudHMrMHgxMi8weDIwDQpbICAzNjkuNTc0OTQ2XSAgWzxmZmZmZmZmZjgxMDA4ZmRm
Pl0gPyB4ZW5fcmVzdG9yZV9mbF9kaXJlY3RfcmVsb2MrMHg0LzB4NA0KWyAgMzY5LjU3NDk1
Ml0gIFs8ZmZmZmZmZmY4MTBiMGY4OD5dID8gbG9ja19hY3F1aXJlKzB4ZDgvMHgxMDANClsg
IDM2OS41NzQ5NThdICBbPGZmZmZmZmZmODEwZjJhNDA+XSA/IGZpbmRfZ2V0X3BhZ2VzKzB4
MTkwLzB4MTkwDQpbICAzNjkuNTc0OTY0XSAgWzxmZmZmZmZmZjgxMGYyYTgyPl0gPyBmaW5k
X2dldF9wYWdlKzB4NDIvMHgxMDANClsgIDM2OS41NzQ5NjldICBbPGZmZmZmZmZmODEwZjJh
NDA+XSA/IGZpbmRfZ2V0X3BhZ2VzKzB4MTkwLzB4MTkwDQpbICAzNjkuNTc0OTc1XSAgWzxm
ZmZmZmZmZjgxMGYyZGMxPl0gPyBmaW5kX2xvY2tfcGFnZSsweDIxLzB4ODANClsgIDM2OS41
NzQ5ODBdICBbPGZmZmZmZmZmODEwZjMzMWE+XSA/IGdyYWJfY2FjaGVfcGFnZV93cml0ZV9i
ZWdpbisweDZhLzB4ZTANClsgIDM2OS41NzQ5ODhdICBbPGZmZmZmZmZmODExZDZkZjc+XSA/
IGV4dDRfZGFfd3JpdGVfYmVnaW4rMHg5Ny8weDFhMA0KWyAgMzY5LjU3NDk5M10gIFs8ZmZm
ZmZmZmY4MTBiMDU0Yj5dID8gX19sb2NrX2FjcXVpcmUrMHg0NmIvMHhkZDANClsgIDM2OS41
NzQ5OTldICBbPGZmZmZmZmZmODE2MTAzNGM+XSA/IHNrYl9mcmVlX2hlYWQrMHg0Yy8weDYw
DQpbICAzNjkuNTc1MDA1XSAgWzxmZmZmZmZmZjgxMGYxZWJiPl0gPyBnZW5lcmljX2ZpbGVf
YnVmZmVyZWRfd3JpdGUrMHgxMGIvMHgyYjANClsgIDM2OS41NzUwMTJdICBbPGZmZmZmZmZm
ODEwNmQ3NDI+XSA/IGN1cnJlbnRfZnNfdGltZSsweDIyLzB4MzANClsgIDM2OS41NzUwMTdd
ICBbPGZmZmZmZmZmODEwZjQwOWI+XSA/IF9fZ2VuZXJpY19maWxlX2Fpb193cml0ZSsweDFi
Yi8weDNjMA0KWyAgMzY5LjU3NTAyM10gIFs8ZmZmZmZmZmY4MTBmNDMxYz5dID8gZ2VuZXJp
Y19maWxlX2Fpb193cml0ZSsweDdjLzB4ZjANClsgIDM2OS41NzUwMjldICBbPGZmZmZmZmZm
ODExZDA0YzQ+XSA/IGV4dDRfZmlsZV93cml0ZSsweDY0LzB4NGMwDQpbICAzNjkuNTc1MDM2
XSAgWzxmZmZmZmZmZjgxMDhlYjFkPl0gPyBsZ19sb2NhbF91bmxvY2srMHgzZC8weDcwDQpb
ICAzNjkuNTc1MDQyXSAgWzxmZmZmZmZmZjgxMWQwNDYwPl0gPyBleHQ0X3Vud3JpdHRlbl93
YWl0KzB4YzAvMHhjMA0KWyAgMzY5LjU3NTA0OV0gIFs8ZmZmZmZmZmY4MTE0MzRjYj5dID8g
ZG9fc3luY19yZWFkdl93cml0ZXYrMHg5Yi8weGUwDQpbICAzNjkuNTc1MDU2XSAgWzxmZmZm
ZmZmZjgxMThkMDdjPl0gPyBjb21wYXRfZG9fcmVhZHZfd3JpdGV2KzB4MWNjLzB4MjEwDQpb
ICAzNjkuNTc1MDYyXSAgWzxmZmZmZmZmZjgxNzQ5MjE5Pl0gPyBzeXNyZXRsX2Zyb21fc3lz
X2NhbGwrMHgyZS8weDM4DQpbICAzNjkuNTc1MDY4XSAgWzxmZmZmZmZmZjgxMThkMGY3Pl0g
PyBjb21wYXRfd3JpdGV2KzB4MzcvMHg3MA0KWyAgMzY5LjU3NTA3NF0gIFs8ZmZmZmZmZmY4
MTE4ZDJiND5dID8gY29tcGF0X3N5c193cml0ZXYrMHg1NC8weDkwDQpbICAzNjkuNTc1MDc5
XSAgWzxmZmZmZmZmZjgxNzQ5MWNjPl0gPyBjc3Rhcl9kaXNwYXRjaCsweDcvMHgyNg0KWyAg
MzY5LjU3NTA4NF0gLS0tWyBlbmQgdHJhY2UgMmUyOGVlYzkzYjdhOGI5OCBdLS0tDQpbICAz
NjkuNTc1MTA1XSAtLS0tLS0tLS0tLS1bIGN1dCBoZXJlIF0tLS0tLS0tLS0tLS0NClsgIDM2
OS41NzUxMTFdIFdBUk5JTkc6IGF0IGRyaXZlcnMvbmV0L3hlbi1uZXRmcm9udC5jOjQ2NSB4
ZW5uZXRfc3RhcnRfeG1pdCsweDdmZS8weDg2MCgpDQpbICAzNjkuNTc1MTE3XSBNb2R1bGVz
IGxpbmtlZCBpbjoNClsgIDM2OS41NzUxMjJdIFBpZDogMTUyMywgY29tbTogc3lzbG9nZCBU
YWludGVkOiBHICAgICAgICBXICAgIDMuNi4wcHJlLXJjMS0yMDEyMTAxMSAjMQ0KWyAgMzY5
LjU3NTEyOF0gQ2FsbCBUcmFjZToNClsgIDM2OS41NzUxMzBdICA8SVJRPiAgWzxmZmZmZmZm
ZjgxMDY2NGVhPl0gd2Fybl9zbG93cGF0aF9jb21tb24rMHg3YS8weGIwDQpbICAzNjkuNTc1
MTM5XSAgWzxmZmZmZmZmZjgxMDY2NTM1Pl0gd2Fybl9zbG93cGF0aF9udWxsKzB4MTUvMHgy
MA0KWyAgMzY5LjU3NTE0NV0gIFs8ZmZmZmZmZmY4MTQ2ZDg5ZT5dIHhlbm5ldF9zdGFydF94
bWl0KzB4N2ZlLzB4ODYwDQpbICAzNjkuNTc1MTUxXSAgWzxmZmZmZmZmZjgxNjFmMzQ5Pl0g
ZGV2X2hhcmRfc3RhcnRfeG1pdCsweDIwOS8weDQ2MA0KWyAgMzY5LjU3NTE1N10gIFs8ZmZm
ZmZmZmY4MTYzYjAzNj5dIHNjaF9kaXJlY3RfeG1pdCsweGY2LzB4MjkwDQpbICAzNjkuNTc1
MTY2XSAgWzxmZmZmZmZmZjgxNjFmNzQ2Pl0gZGV2X3F1ZXVlX3htaXQrMHgxYTYvMHg1YTAN
ClsgIDM2OS41NzUxNzJdICBbPGZmZmZmZmZmODE2MWY1YTA+XSA/IGRldl9oYXJkX3N0YXJ0
X3htaXQrMHg0NjAvMHg0NjANClsgIDM2OS41NzUxNzhdICBbPGZmZmZmZmZmODEwYjE0MTc+
XSA/IGxvY2tfcmVsZWFzZSsweDExNy8weDI1MA0KWyAgMzY5LjU3NTE4NF0gIFs8ZmZmZmZm
ZmY4MTZiOTUzNj5dIGlwX2ZpbmlzaF9vdXRwdXQrMHgyMjYvMHg1MzANClsgIDM2OS41NzUx
OTBdICBbPGZmZmZmZmZmODE2YjkzZGQ+XSA/IGlwX2ZpbmlzaF9vdXRwdXQrMHhjZC8weDUz
MA0KWyAgMzY5LjU3NTE5Nl0gIFs8ZmZmZmZmZmY4MTZiOTg5OT5dIGlwX291dHB1dCsweDU5
LzB4ZTANClsgIDM2OS41NzUyMDJdICBbPGZmZmZmZmZmODE2YjgzYjg+XSBpcF9sb2NhbF9v
dXQrMHgyOC8weDkwDQpbICAzNjkuNTc1MjA3XSAgWzxmZmZmZmZmZjgxNmI4OTZmPl0gaXBf
cXVldWVfeG1pdCsweDE3Zi8weDRhMA0KWyAgMzY5LjU3NTIxM10gIFs8ZmZmZmZmZmY4MTZi
ODdmMD5dID8gaXBfc2VuZF91bmljYXN0X3JlcGx5KzB4MzQwLzB4MzQwDQpbICAzNjkuNTc1
MjE5XSAgWzxmZmZmZmZmZjgxMGEwYmE3Pl0gPyBnZXRuc3RpbWVvZmRheSsweDQ3LzB4ZTAN
ClsgIDM2OS41NzUyMjVdICBbPGZmZmZmZmZmODE2MGY0Yzk+XSA/IF9fc2tiX2Nsb25lKzB4
MjkvMHgxMjANClsgIDM2OS41NzUyMzBdICBbPGZmZmZmZmZmODE2Y2VhMjA+XSB0Y3BfdHJh
bnNtaXRfc2tiKzB4NDAwLzB4OGQwDQpbICAzNjkuNTc1MjM2XSAgWzxmZmZmZmZmZjgxNmQx
MTA2Pl0gdGNwX3JldHJhbnNtaXRfc2tiKzB4MWM2LzB4NWEwDQpbICAzNjkuNTc1MjQyXSAg
WzxmZmZmZmZmZjgxNzQ2Y2I1Pl0gPyBfcmF3X3NwaW5fdW5sb2NrX2lycXJlc3RvcmUrMHg3
NS8weGEwDQpbICAzNjkuNTc1MjQ4XSAgWzxmZmZmZmZmZjgxNmQxNjdlPl0gdGNwX3htaXRf
cmV0cmFuc21pdF9xdWV1ZSsweDE5ZS8weDMwMA0KWyAgMzY5LjU3NTI1NV0gIFs8ZmZmZmZm
ZmY4MTZjOTlmZj5dIHRjcF9mYXN0cmV0cmFuc19hbGVydCsweDk0Zi8weGNiMA0KWyAgMzY5
LjU3NTI2MF0gIFs8ZmZmZmZmZmY4MTZjYTcwYz5dIHRjcF9hY2srMHg5YWMvMHgxMTUwDQpb
ICAzNjkuNTc1MjY2XSAgWzxmZmZmZmZmZjgxNmNkOGNlPl0gdGNwX3Jjdl9lc3RhYmxpc2hl
ZCsweDM4ZS8weDY0MA0KWyAgMzY5LjU3NTI3Ml0gIFs8ZmZmZmZmZmY4MTZkNWVlZj5dID8g
dGNwX3Y0X3JjdisweDZjZi8weGIxMA0KWyAgMzY5LjU3NTI3OF0gIFs8ZmZmZmZmZmY4MTZk
NTRkNT5dIHRjcF92NF9kb19yY3YrMHgxMzUvMHg0ODANClsgIDM2OS41NzUyODRdICBbPGZm
ZmZmZmZmODE3NDYxZDI+XSA/IF9yYXdfc3Bpbl9sb2NrX25lc3RlZCsweDQyLzB4NTANClsg
IDM2OS41NzUyODldICBbPGZmZmZmZmZmODE2ZDVlZWY+XSA/IHRjcF92NF9yY3YrMHg2Y2Yv
MHhiMTANClsgIDM2OS41NzUyOTVdICBbPGZmZmZmZmZmODE2ZDYxN2Q+XSB0Y3BfdjRfcmN2
KzB4OTVkLzB4YjEwDQpbICAzNjkuNTc1MzAwXSAgWzxmZmZmZmZmZjgxMGIwZjg4Pl0gPyBs
b2NrX2FjcXVpcmUrMHhkOC8weDEwMA0KWyAgMzY5LjU3NTMwOV0gIFs8ZmZmZmZmZmY4MTZi
Mjk5NT5dID8gaXBfbG9jYWxfZGVsaXZlcl9maW5pc2grMHg0NS8weDIzMA0KWyAgMzY5LjU3
NTMxNl0gIFs8ZmZmZmZmZmY4MTZiMmE2YT5dIGlwX2xvY2FsX2RlbGl2ZXJfZmluaXNoKzB4
MTFhLzB4MjMwDQpbICAzNjkuNTc1MzIyXSAgWzxmZmZmZmZmZjgxNmIyOTk1Pl0gPyBpcF9s
b2NhbF9kZWxpdmVyX2ZpbmlzaCsweDQ1LzB4MjMwDQpbICAzNjkuNTc1MzI4XSAgWzxmZmZm
ZmZmZjgxNmIyYmI4Pl0gaXBfbG9jYWxfZGVsaXZlcisweDM4LzB4ODANClsgIDM2OS41NzUz
MzRdICBbPGZmZmZmZmZmODE2YjIxN2E+XSBpcF9yY3ZfZmluaXNoKzB4MTVhLzB4NjMwDQpb
ICAzNjkuNTc1MzM5XSAgWzxmZmZmZmZmZjgxNmIyODY4Pl0gaXBfcmN2KzB4MjE4LzB4MzAw
DQpbICAzNjkuNTc1MzQ0XSAgWzxmZmZmZmZmZjgxNjFhYzhkPl0gX19uZXRpZl9yZWNlaXZl
X3NrYisweDY1ZC8weDhkMA0KWyAgMzY5LjU3NTM1MF0gIFs8ZmZmZmZmZmY4MTYxYTc3NT5d
ID8gX19uZXRpZl9yZWNlaXZlX3NrYisweDE0NS8weDhkMA0KWyAgMzY5LjU3NTM1Nl0gIFs8
ZmZmZmZmZmY4MTBhZDIyZD5dID8gdHJhY2VfaGFyZGlycXNfb24rMHhkLzB4MTANClsgIDM2
OS41NzUzNjJdICBbPGZmZmZmZmZmODEwZjk5NzM+XSA/IGZyZWVfaG90X2NvbGRfcGFnZSsw
eDFiMy8weDFlMA0KWyAgMzY5LjU3NTM2OV0gIFs8ZmZmZmZmZmY4MTYxZDFmOD5dIG5ldGlm
X3JlY2VpdmVfc2tiKzB4MjgvMHhmMA0KWyAgMzY5LjU3NTM3NV0gIFs8ZmZmZmZmZmY4MTYx
MmQwMz5dID8gX19wc2tiX3B1bGxfdGFpbCsweDI1My8weDM0MA0KWyAgMzY5LjU3NTM4NF0g
IFs8ZmZmZmZmZmY4MTQ2ZTRjNT5dIHhlbm5ldF9wb2xsKzB4YWQ1LzB4ZTEwDQpbICAzNjku
NTc1MzkxXSAgWzxmZmZmZmZmZjgxNjFkZmE2Pl0gbmV0X3J4X2FjdGlvbisweDEzNi8weDI2
MA0KWyAgMzY5LjU3NTM5N10gIFs8ZmZmZmZmZmY4MTA2ZTM4MT5dID8gX19kb19zb2Z0aXJx
KzB4NzEvMHgxYTANClsgIDM2OS41NzU0MDJdICBbPGZmZmZmZmZmODEwNmUzZDk+XSBfX2Rv
X3NvZnRpcnErMHhjOS8weDFhMA0KWyAgMzY5LjU3NTQwOF0gIFs8ZmZmZmZmZmY4MTc0OGQz
Yz5dIGNhbGxfc29mdGlycSsweDFjLzB4MzANClsgIDM2OS41NzU0MTNdICBbPGZmZmZmZmZm
ODEwMGVkYjU+XSBkb19zb2Z0aXJxKzB4ODUvMHhmMA0KWyAgMzY5LjU3NTQxOV0gIFs8ZmZm
ZmZmZmY4MTA2ZTI0ZT5dIGlycV9leGl0KzB4OWUvMHhkMA0KWyAgMzY5LjU3NTQyOF0gIFs8
ZmZmZmZmZmY4MTMzOWY1Zj5dIHhlbl9ldnRjaG5fZG9fdXBjYWxsKzB4MmYvMHg0MA0KWyAg
MzY5LjU3NTQzNF0gIFs8ZmZmZmZmZmY4MTc0OGQ5ZT5dIHhlbl9kb19oeXBlcnZpc29yX2Nh
bGxiYWNrKzB4MWUvMHgzMA0KWyAgMzY5LjU3NTQzOV0gIDxFT0k+ICBbPGZmZmZmZmZmODEw
MDEyMmE+XSA/IHhlbl9oeXBlcmNhbGxfeGVuX3ZlcnNpb24rMHhhLzB4MjANClsgIDM2OS41
NzU0NDhdICBbPGZmZmZmZmZmODEwMDEyMmE+XSA/IHhlbl9oeXBlcmNhbGxfeGVuX3ZlcnNp
b24rMHhhLzB4MjANClsgIDM2OS41NzU0NTRdICBbPGZmZmZmZmZmODEwMDg2NGQ+XSA/IHhl
bl9mb3JjZV9ldnRjaG5fY2FsbGJhY2srMHhkLzB4MTANClsgIDM2OS41NzU0NjBdICBbPGZm
ZmZmZmZmODEwMDhmZjI+XSA/IGNoZWNrX2V2ZW50cysweDEyLzB4MjANClsgIDM2OS41NzU0
NjZdICBbPGZmZmZmZmZmODEwMDhmZGY+XSA/IHhlbl9yZXN0b3JlX2ZsX2RpcmVjdF9yZWxv
YysweDQvMHg0DQpbICAzNjkuNTc1NDcyXSAgWzxmZmZmZmZmZjgxMGIwZjg4Pl0gPyBsb2Nr
X2FjcXVpcmUrMHhkOC8weDEwMA0KWyAgMzY5LjU3NTQ3OF0gIFs8ZmZmZmZmZmY4MTBmMmE0
MD5dID8gZmluZF9nZXRfcGFnZXMrMHgxOTAvMHgxOTANClsgIDM2OS41NzU0ODVdICBbPGZm
ZmZmZmZmODEwZjJhODI+XSA/IGZpbmRfZ2V0X3BhZ2UrMHg0Mi8weDEwMA0KWyAgMzY5LjU3
NTQ5MV0gIFs8ZmZmZmZmZmY4MTBmMmE0MD5dID8gZmluZF9nZXRfcGFnZXMrMHgxOTAvMHgx
OTANClsgIDM2OS41NzU0OTddICBbPGZmZmZmZmZmODEwZjJkYzE+XSA/IGZpbmRfbG9ja19w
YWdlKzB4MjEvMHg4MA0KWyAgMzY5LjU3NTUwMl0gIFs8ZmZmZmZmZmY4MTBmMzMxYT5dID8g
Z3JhYl9jYWNoZV9wYWdlX3dyaXRlX2JlZ2luKzB4NmEvMHhlMA0KWyAgMzY5LjU3NTUwOF0g
IFs8ZmZmZmZmZmY4MTFkNmRmNz5dID8gZXh0NF9kYV93cml0ZV9iZWdpbisweDk3LzB4MWEw
DQpbICAzNjkuNTc1NTE0XSAgWzxmZmZmZmZmZjgxMGIwNTRiPl0gPyBfX2xvY2tfYWNxdWly
ZSsweDQ2Yi8weGRkMA0KWyAgMzY5LjU3NTUyMF0gIFs8ZmZmZmZmZmY4MTYxMDM0Yz5dID8g
c2tiX2ZyZWVfaGVhZCsweDRjLzB4NjANClsgIDM2OS41NzU1MjZdICBbPGZmZmZmZmZmODEw
ZjFlYmI+XSA/IGdlbmVyaWNfZmlsZV9idWZmZXJlZF93cml0ZSsweDEwYi8weDJiMA0KWyAg
MzY5LjU3NTUzMl0gIFs8ZmZmZmZmZmY4MTA2ZDc0Mj5dID8gY3VycmVudF9mc190aW1lKzB4
MjIvMHgzMA0KWyAgMzY5LjU3NTUzOF0gIFs8ZmZmZmZmZmY4MTBmNDA5Yj5dID8gX19nZW5l
cmljX2ZpbGVfYWlvX3dyaXRlKzB4MWJiLzB4M2MwDQpbICAzNjkuNTc1NTQ0XSAgWzxmZmZm
ZmZmZjgxMGY0MzFjPl0gPyBnZW5lcmljX2ZpbGVfYWlvX3dyaXRlKzB4N2MvMHhmMA0KWyAg
MzY5LjU3NTU1MF0gIFs8ZmZmZmZmZmY4MTFkMDRjND5dID8gZXh0NF9maWxlX3dyaXRlKzB4
NjQvMHg0YzANClsgIDM2OS41NzU1NTZdICBbPGZmZmZmZmZmODEwOGViMWQ+XSA/IGxnX2xv
Y2FsX3VubG9jaysweDNkLzB4NzANClsgIDM2OS41NzU1NjJdICBbPGZmZmZmZmZmODExZDA0
NjA+XSA/IGV4dDRfdW53cml0dGVuX3dhaXQrMHhjMC8weGMwDQpbICAzNjkuNTc1NTY3XSAg
WzxmZmZmZmZmZjgxMTQzNGNiPl0gPyBkb19zeW5jX3JlYWR2X3dyaXRldisweDliLzB4ZTAN
ClsgIDM2OS41NzU1NzRdICBbPGZmZmZmZmZmODExOGQwN2M+XSA/IGNvbXBhdF9kb19yZWFk
dl93cml0ZXYrMHgxY2MvMHgyMTANClsgIDM2OS41NzU1ODJdICBbPGZmZmZmZmZmODE3NDky
MTk+XSA/IHN5c3JldGxfZnJvbV9zeXNfY2FsbCsweDJlLzB4MzgNClsgIDM2OS41NzU1ODhd
ICBbPGZmZmZmZmZmODExOGQwZjc+XSA/IGNvbXBhdF93cml0ZXYrMHgzNy8weDcwDQpbICAz
NjkuNTc1NTk0XSAgWzxmZmZmZmZmZjgxMThkMmI0Pl0gPyBjb21wYXRfc3lzX3dyaXRldisw
eDU0LzB4OTANClsgIDM2OS41NzU2MDBdICBbPGZmZmZmZmZmODE3NDkxY2M+XSA/IGNzdGFy
X2Rpc3BhdGNoKzB4Ny8weDI2DQpbICAzNjkuNTc1NjA0XSAtLS1bIGVuZCB0cmFjZSAyZTI4
ZWVjOTNiN2E4Yjk5IF0tLS0NClsgIDM2OS41NzU2MjZdIC0tLS0tLS0tLS0tLVsgY3V0IGhl
cmUgXS0tLS0tLS0tLS0tLQ0KWyAgMzY5LjU3NTYzMl0gV0FSTklORzogYXQgZHJpdmVycy9u
ZXQveGVuLW5ldGZyb250LmM6NDY1IHhlbm5ldF9zdGFydF94bWl0KzB4N2ZlLzB4ODYwKCkN
ClsgIDM2OS41NzU2MzhdIE1vZHVsZXMgbGlua2VkIGluOg0KWyAgMzY5LjU3NTY0Ml0gUGlk
OiAxNTIzLCBjb21tOiBzeXNsb2dkIFRhaW50ZWQ6IEcgICAgICAgIFcgICAgMy42LjBwcmUt
cmMxLTIwMTIxMDExICMxDQpbICAzNjkuNTc1NjQ4XSBDYWxsIFRyYWNlOg0KWyAgMzY5LjU3
NTY1MV0gIDxJUlE+ICBbPGZmZmZmZmZmODEwNjY0ZWE+XSB3YXJuX3Nsb3dwYXRoX2NvbW1v
bisweDdhLzB4YjANClsgIDM2OS41NzU2NjBdICBbPGZmZmZmZmZmODEwNjY1MzU+XSB3YXJu
X3Nsb3dwYXRoX251bGwrMHgxNS8weDIwDQpbICAzNjkuNTc1NjY1XSAgWzxmZmZmZmZmZjgx
NDZkODllPl0geGVubmV0X3N0YXJ0X3htaXQrMHg3ZmUvMHg4NjANClsgIDM2OS41NzU2NzJd
ICBbPGZmZmZmZmZmODE2MWYzNDk+XSBkZXZfaGFyZF9zdGFydF94bWl0KzB4MjA5LzB4NDYw
DQpbICAzNjkuNTc1Njc4XSAgWzxmZmZmZmZmZjgxNjNiMDM2Pl0gc2NoX2RpcmVjdF94bWl0
KzB4ZjYvMHgyOTANClsgIDM2OS41NzU2ODRdICBbPGZmZmZmZmZmODE2MWY3NDY+XSBkZXZf
cXVldWVfeG1pdCsweDFhNi8weDVhMA0KWyAgMzY5LjU3NTY5MF0gIFs8ZmZmZmZmZmY4MTYx
ZjVhMD5dID8gZGV2X2hhcmRfc3RhcnRfeG1pdCsweDQ2MC8weDQ2MA0KWyAgMzY5LjU3NTY5
Nl0gIFs8ZmZmZmZmZmY4MTBiMTQxNz5dID8gbG9ja19yZWxlYXNlKzB4MTE3LzB4MjUwDQpb
ICAzNjkuNTc1NzAyXSAgWzxmZmZmZmZmZjgxNmI5NTM2Pl0gaXBfZmluaXNoX291dHB1dCsw
eDIyNi8weDUzMA0KWyAgMzY5LjU3NTcwN10gIFs8ZmZmZmZmZmY4MTZiOTNkZD5dID8gaXBf
ZmluaXNoX291dHB1dCsweGNkLzB4NTMwDQpbICAzNjkuNTc1NzE0XSAgWzxmZmZmZmZmZjgx
NmI5ODk5Pl0gaXBfb3V0cHV0KzB4NTkvMHhlMA0KWyAgMzY5LjU3NTcxOV0gIFs8ZmZmZmZm
ZmY4MTZiODNiOD5dIGlwX2xvY2FsX291dCsweDI4LzB4OTANClsgIDM2OS41NzU3MjVdICBb
PGZmZmZmZmZmODE2Yjg5NmY+XSBpcF9xdWV1ZV94bWl0KzB4MTdmLzB4NGEwDQpbICAzNjku
NTc1NzMwXSAgWzxmZmZmZmZmZjgxNmI4N2YwPl0gPyBpcF9zZW5kX3VuaWNhc3RfcmVwbHkr
MHgzNDAvMHgzNDANClsgIDM2OS41NzU3MzZdICBbPGZmZmZmZmZmODEwYTBiYTc+XSA/IGdl
dG5zdGltZW9mZGF5KzB4NDcvMHhlMA0KWyAgMzY5LjU3NTc0Ml0gIFs8ZmZmZmZmZmY4MTYw
ZjRjOT5dID8gX19za2JfY2xvbmUrMHgyOS8weDEyMA0KWyAgMzY5LjU3NTc0OF0gIFs8ZmZm
ZmZmZmY4MTZjZWEyMD5dIHRjcF90cmFuc21pdF9za2IrMHg0MDAvMHg4ZDANClsgIDM2OS41
NzU3NTRdICBbPGZmZmZmZmZmODE2ZDExMDY+XSB0Y3BfcmV0cmFuc21pdF9za2IrMHgxYzYv
MHg1YTANClsgIDM2OS41NzU3NTldICBbPGZmZmZmZmZmODE3NDZjYjU+XSA/IF9yYXdfc3Bp
bl91bmxvY2tfaXJxcmVzdG9yZSsweDc1LzB4YTANClsgIDM2OS41NzU3NjZdICBbPGZmZmZm
ZmZmODE2ZDE2N2U+XSB0Y3BfeG1pdF9yZXRyYW5zbWl0X3F1ZXVlKzB4MTllLzB4MzAwDQpb
ICAzNjkuNTc1NzcyXSAgWzxmZmZmZmZmZjgxNmM5OWZmPl0gdGNwX2Zhc3RyZXRyYW5zX2Fs
ZXJ0KzB4OTRmLzB4Y2IwDQpbICAzNjkuNTc1Nzc4XSAgWzxmZmZmZmZmZjgxNmNhNzBjPl0g
dGNwX2FjaysweDlhYy8weDExNTANClsgIDM2OS41NzU3ODNdICBbPGZmZmZmZmZmODE2Y2Q4
Y2U+XSB0Y3BfcmN2X2VzdGFibGlzaGVkKzB4MzhlLzB4NjQwDQpbICAzNjkuNTc1Nzg5XSAg
WzxmZmZmZmZmZjgxNmQ1ZWVmPl0gPyB0Y3BfdjRfcmN2KzB4NmNmLzB4YjEwDQpbICAzNjku
NTc1Nzk1XSAgWzxmZmZmZmZmZjgxNmQ1NGQ1Pl0gdGNwX3Y0X2RvX3JjdisweDEzNS8weDQ4
MA0KWyAgMzY5LjU3NTgwM10gIFs8ZmZmZmZmZmY4MTc0NjFkMj5dID8gX3Jhd19zcGluX2xv
Y2tfbmVzdGVkKzB4NDIvMHg1MA0KWyAgMzY5LjU3NTgwOV0gIFs8ZmZmZmZmZmY4MTZkNWVl
Zj5dID8gdGNwX3Y0X3JjdisweDZjZi8weGIxMA0KWyAgMzY5LjU3NTgxNV0gIFs8ZmZmZmZm
ZmY4MTZkNjE3ZD5dIHRjcF92NF9yY3YrMHg5NWQvMHhiMTANClsgIDM2OS41NzU4MjNdICBb
PGZmZmZmZmZmODEwYjBmODg+XSA/IGxvY2tfYWNxdWlyZSsweGQ4LzB4MTAwDQpbICAzNjku
NTc1ODI4XSAgWzxmZmZmZmZmZjgxNmIyOTk1Pl0gPyBpcF9sb2NhbF9kZWxpdmVyX2Zpbmlz
aCsweDQ1LzB4MjMwDQpbICAzNjkuNTc1ODM1XSAgWzxmZmZmZmZmZjgxNmIyYTZhPl0gaXBf
bG9jYWxfZGVsaXZlcl9maW5pc2grMHgxMWEvMHgyMzANClsgIDM2OS41NzU4NDFdICBbPGZm
ZmZmZmZmODE2YjI5OTU+XSA/IGlwX2xvY2FsX2RlbGl2ZXJfZmluaXNoKzB4NDUvMHgyMzAN
ClsgIDM2OS41NzU4NDddICBbPGZmZmZmZmZmODE2YjJiYjg+XSBpcF9sb2NhbF9kZWxpdmVy
KzB4MzgvMHg4MA0KWyAgMzY5LjU3NTg1Ml0gIFs8ZmZmZmZmZmY4MTZiMjE3YT5dIGlwX3Jj
dl9maW5pc2grMHgxNWEvMHg2MzANClsgIDM2OS41NzU4NThdICBbPGZmZmZmZmZmODE2YjI4
Njg+XSBpcF9yY3YrMHgyMTgvMHgzMDANClsgIDM2OS41NzU4NjNdICBbPGZmZmZmZmZmODE2
MWFjOGQ+XSBfX25ldGlmX3JlY2VpdmVfc2tiKzB4NjVkLzB4OGQwDQpbICAzNjkuNTc1ODY5
XSAgWzxmZmZmZmZmZjgxNjFhNzc1Pl0gPyBfX25ldGlmX3JlY2VpdmVfc2tiKzB4MTQ1LzB4
OGQwDQpbICAzNjkuNTc1ODc1XSAgWzxmZmZmZmZmZjgxMGFkMjJkPl0gPyB0cmFjZV9oYXJk
aXJxc19vbisweGQvMHgxMA0KWyAgMzY5LjU3NTg4MV0gIFs8ZmZmZmZmZmY4MTBmOTk3Mz5d
ID8gZnJlZV9ob3RfY29sZF9wYWdlKzB4MWIzLzB4MWUwDQpbICAzNjkuNTc1ODg3XSAgWzxm
ZmZmZmZmZjgxNjFkMWY4Pl0gbmV0aWZfcmVjZWl2ZV9za2IrMHgyOC8weGYwDQpbICAzNjku
NTc1ODkzXSAgWzxmZmZmZmZmZjgxNjEyZDAzPl0gPyBfX3Bza2JfcHVsbF90YWlsKzB4MjUz
LzB4MzQwDQpbICAzNjkuNTc2NzI2XSAgWzxmZmZmZmZmZjgxNDZlNGM1Pl0geGVubmV0X3Bv
bGwrMHhhZDUvMHhlMTANClsgIDM2OS41NzY3MjZdICBbPGZmZmZmZmZmODE2MWRmYTY+XSBu
ZXRfcnhfYWN0aW9uKzB4MTM2LzB4MjYwDQpbICAzNjkuNTc2NzI2XSAgWzxmZmZmZmZmZjgx
MDZlMzgxPl0gPyBfX2RvX3NvZnRpcnErMHg3MS8weDFhMA0KWyAgMzY5LjU3NjcyNl0gIFs8
ZmZmZmZmZmY4MTA2ZTNkOT5dIF9fZG9fc29mdGlycSsweGM5LzB4MWEwDQpbICAzNjkuNTc2
NzI2XSAgWzxmZmZmZmZmZjgxNzQ4ZDNjPl0gY2FsbF9zb2Z0aXJxKzB4MWMvMHgzMA0KWyAg
MzY5LjU3NjcyNl0gIFs8ZmZmZmZmZmY4MTAwZWRiNT5dIGRvX3NvZnRpcnErMHg4NS8weGYw
DQpbICAzNjkuNTc2NzI2XSAgWzxmZmZmZmZmZjgxMDZlMjRlPl0gaXJxX2V4aXQrMHg5ZS8w
eGQwDQpbICAzNjkuNTc2NzI2XSAgWzxmZmZmZmZmZjgxMzM5ZjVmPl0geGVuX2V2dGNobl9k
b191cGNhbGwrMHgyZi8weDQwDQpbICAzNjkuNTc2NzI2XSAgWzxmZmZmZmZmZjgxNzQ4ZDll
Pl0geGVuX2RvX2h5cGVydmlzb3JfY2FsbGJhY2srMHgxZS8weDMwDQpbICAzNjkuNTc2NzI2
XSAgPEVPST4gIFs8ZmZmZmZmZmY4MTAwMTIyYT5dID8geGVuX2h5cGVyY2FsbF94ZW5fdmVy
c2lvbisweGEvMHgyMA0KWyAgMzY5LjU3NjcyNl0gIFs8ZmZmZmZmZmY4MTAwMTIyYT5dID8g
eGVuX2h5cGVyY2FsbF94ZW5fdmVyc2lvbisweGEvMHgyMA0KWyAgMzY5LjU3NjcyNl0gIFs8
ZmZmZmZmZmY4MTAwODY0ZD5dID8geGVuX2ZvcmNlX2V2dGNobl9jYWxsYmFjaysweGQvMHgx
MA0KWyAgMzY5LjU3NjcyNl0gIFs8ZmZmZmZmZmY4MTAwOGZmMj5dID8gY2hlY2tfZXZlbnRz
KzB4MTIvMHgyMA0KWyAgMzY5LjU3NjcyNl0gIFs8ZmZmZmZmZmY4MTAwOGZkZj5dID8geGVu
X3Jlc3RvcmVfZmxfZGlyZWN0X3JlbG9jKzB4NC8weDQNClsgIDM2OS41NzY3MjZdICBbPGZm
ZmZmZmZmODEwYjBmODg+XSA/IGxvY2tfYWNxdWlyZSsweGQ4LzB4MTAwDQpbICAzNjkuNTc2
NzI2XSAgWzxmZmZmZmZmZjgxMGYyYTQwPl0gPyBmaW5kX2dldF9wYWdlcysweDE5MC8weDE5
MA0KWyAgMzY5LjU3NjcyNl0gIFs8ZmZmZmZmZmY4MTBmMmE4Mj5dID8gZmluZF9nZXRfcGFn
ZSsweDQyLzB4MTAwDQpbICAzNjkuNTc2NzI2XSAgWzxmZmZmZmZmZjgxMGYyYTQwPl0gPyBm
aW5kX2dldF9wYWdlcysweDE5MC8weDE5MA0KWyAgMzY5LjU3NjcyNl0gIFs8ZmZmZmZmZmY4
MTBmMmRjMT5dID8gZmluZF9sb2NrX3BhZ2UrMHgyMS8weDgwDQpbICAzNjkuNTc2NzI2XSAg
WzxmZmZmZmZmZjgxMGYzMzFhPl0gPyBncmFiX2NhY2hlX3BhZ2Vfd3JpdGVfYmVnaW4rMHg2
YS8weGUwDQpbICAzNjkuNTc2NzI2XSAgWzxmZmZmZmZmZjgxMWQ2ZGY3Pl0gPyBleHQ0X2Rh
X3dyaXRlX2JlZ2luKzB4OTcvMHgxYTANClsgIDM2OS41NzY3MjZdICBbPGZmZmZmZmZmODEw
YjA1NGI+XSA/IF9fbG9ja19hY3F1aXJlKzB4NDZiLzB4ZGQwDQpbICAzNjkuNTc2NzI2XSAg
WzxmZmZmZmZmZjgxNjEwMzRjPl0gPyBza2JfZnJlZV9oZWFkKzB4NGMvMHg2MA0KWyAgMzY5
LjU3NjcyNl0gIFs8ZmZmZmZmZmY4MTBmMWViYj5dID8gZ2VuZXJpY19maWxlX2J1ZmZlcmVk
X3dyaXRlKzB4MTBiLzB4MmIwDQpbICAzNjkuNTc2NzI2XSAgWzxmZmZmZmZmZjgxMDZkNzQy
Pl0gPyBjdXJyZW50X2ZzX3RpbWUrMHgyMi8weDMwDQpbICAzNjkuNTc2NzI2XSAgWzxmZmZm
ZmZmZjgxMGY0MDliPl0gPyBfX2dlbmVyaWNfZmlsZV9haW9fd3JpdGUrMHgxYmIvMHgzYzAN
ClsgIDM2OS41NzY3MjZdICBbPGZmZmZmZmZmODEwZjQzMWM+XSA/IGdlbmVyaWNfZmlsZV9h
aW9fd3JpdGUrMHg3Yy8weGYwDQpbICAzNjkuNTc2NzI2XSAgWzxmZmZmZmZmZjgxMWQwNGM0
Pl0gPyBleHQ0X2ZpbGVfd3JpdGUrMHg2NC8weDRjMA0KWyAgMzY5LjU3NjcyNl0gIFs8ZmZm
ZmZmZmY4MTA4ZWIxZD5dID8gbGdfbG9jYWxfdW5sb2NrKzB4M2QvMHg3MA0KWyAgMzY5LjU3
NjcyNl0gIFs8ZmZmZmZmZmY4MTFkMDQ2MD5dID8gZXh0NF91bndyaXR0ZW5fd2FpdCsweGMw
LzB4YzANClsgIDM2OS41NzY3MjZdICBbPGZmZmZmZmZmODExNDM0Y2I+XSA/IGRvX3N5bmNf
cmVhZHZfd3JpdGV2KzB4OWIvMHhlMA0KWyAgMzY5LjU3NjcyNl0gIFs8ZmZmZmZmZmY4MTE4
ZDA3Yz5dID8gY29tcGF0X2RvX3JlYWR2X3dyaXRldisweDFjYy8weDIxMA0KWyAgMzY5LjU3
NjcyNl0gIFs8ZmZmZmZmZmY4MTc0OTIxOT5dID8gc3lzcmV0bF9mcm9tX3N5c19jYWxsKzB4
MmUvMHgzOA0KWyAgMzY5LjU3NjcyNl0gIFs8ZmZmZmZmZmY4MTE4ZDBmNz5dID8gY29tcGF0
X3dyaXRldisweDM3LzB4NzANClsgIDM2OS41NzY3MjZdICBbPGZmZmZmZmZmODExOGQyYjQ+
XSA/IGNvbXBhdF9zeXNfd3JpdGV2KzB4NTQvMHg5MA0KWyAgMzY5LjU3NjcyNl0gIFs8ZmZm
ZmZmZmY4MTc0OTFjYz5dID8gY3N0YXJfZGlzcGF0Y2grMHg3LzB4MjYNClsgIDM2OS41NzY3
MjZdIC0tLVsgZW5kIHRyYWNlIDJlMjhlZWM5M2I3YThiOWEgXS0tLQ0KWyAgMzcwLjA0Njg4
MF0gLS0tLS0tLS0tLS0tWyBjdXQgaGVyZSBdLS0tLS0tLS0tLS0tDQpbICAzNzAuMDQ2OTA0
XSBXQVJOSU5HOiBhdCBkcml2ZXJzL25ldC94ZW4tbmV0ZnJvbnQuYzo0NjUgeGVubmV0X3N0
YXJ0X3htaXQrMHg3ZmUvMHg4NjAoKQ0KWyAgMzcwLjA0NjkxMF0gTW9kdWxlcyBsaW5rZWQg
aW46DQpbICAzNzAuMDQ2OTE3XSBQaWQ6IDAsIGNvbW06IHN3YXBwZXIvMCBUYWludGVkOiBH
ICAgICAgICBXICAgIDMuNi4wcHJlLXJjMS0yMDEyMTAxMSAjMQ0KWyAgMzcwLjA0NjkyM10g
Q2FsbCBUcmFjZToNClsgIDM3MC4wNDY5MjddICA8SVJRPiAgWzxmZmZmZmZmZjgxMDY2NGVh
Pl0gd2Fybl9zbG93cGF0aF9jb21tb24rMHg3YS8weGIwDQpbICAzNzAuMDQ2OTM5XSAgWzxm
ZmZmZmZmZjgxMDY2NTM1Pl0gd2Fybl9zbG93cGF0aF9udWxsKzB4MTUvMHgyMA0KWyAgMzcw
LjA0Njk0NV0gIFs8ZmZmZmZmZmY4MTQ2ZDg5ZT5dIHhlbm5ldF9zdGFydF94bWl0KzB4N2Zl
LzB4ODYwDQpbICAzNzAuMDQ2OTU0XSAgWzxmZmZmZmZmZjgxNjFmMzQ5Pl0gZGV2X2hhcmRf
c3RhcnRfeG1pdCsweDIwOS8weDQ2MA0KWyAgMzcwLjA0Njk2MV0gIFs8ZmZmZmZmZmY4MTYz
YjAzNj5dIHNjaF9kaXJlY3RfeG1pdCsweGY2LzB4MjkwDQpbICAzNzAuMDQ2OTY2XSAgWzxm
ZmZmZmZmZjgxNjFmNzQ2Pl0gZGV2X3F1ZXVlX3htaXQrMHgxYTYvMHg1YTANClsgIDM3MC4w
NDY5NzJdICBbPGZmZmZmZmZmODE2MWY1YTA+XSA/IGRldl9oYXJkX3N0YXJ0X3htaXQrMHg0
NjAvMHg0NjANClsgIDM3MC4wNDY5NzldICBbPGZmZmZmZmZmODEwYjE0MTc+XSA/IGxvY2tf
cmVsZWFzZSsweDExNy8weDI1MA0KWyAgMzcwLjA0Njk4Nl0gIFs8ZmZmZmZmZmY4MTZiOTUz
Nj5dIGlwX2ZpbmlzaF9vdXRwdXQrMHgyMjYvMHg1MzANClsgIDM3MC4wNDY5OTJdICBbPGZm
ZmZmZmZmODE2YjkzZGQ+XSA/IGlwX2ZpbmlzaF9vdXRwdXQrMHhjZC8weDUzMA0KWyAgMzcw
LjA0Njk5OF0gIFs8ZmZmZmZmZmY4MTZiOTg5OT5dIGlwX291dHB1dCsweDU5LzB4ZTANClsg
IDM3MC4wNDcwMDNdICBbPGZmZmZmZmZmODE2YjgzYjg+XSBpcF9sb2NhbF9vdXQrMHgyOC8w
eDkwDQpbICAzNzAuMDQ3MDA5XSAgWzxmZmZmZmZmZjgxNmI4OTZmPl0gaXBfcXVldWVfeG1p
dCsweDE3Zi8weDRhMA0KWyAgMzcwLjA0NzAxNF0gIFs8ZmZmZmZmZmY4MTZiODdmMD5dID8g
aXBfc2VuZF91bmljYXN0X3JlcGx5KzB4MzQwLzB4MzQwDQpbICAzNzAuMDQ3MDIwXSAgWzxm
ZmZmZmZmZjgxMGEwYmE3Pl0gPyBnZXRuc3RpbWVvZmRheSsweDQ3LzB4ZTANClsgIDM3MC4w
NDcwMjddICBbPGZmZmZmZmZmODE2MGY0Yzk+XSA/IF9fc2tiX2Nsb25lKzB4MjkvMHgxMjAN
ClsgIDM3MC4wNDcwMzNdICBbPGZmZmZmZmZmODE2Y2VhMjA+XSB0Y3BfdHJhbnNtaXRfc2ti
KzB4NDAwLzB4OGQwDQpbICAzNzAuMDQ3MDM5XSAgWzxmZmZmZmZmZjgxNmQxMTA2Pl0gdGNw
X3JldHJhbnNtaXRfc2tiKzB4MWM2LzB4NWEwDQpbICAzNzAuMDQ3MDQ1XSAgWzxmZmZmZmZm
ZjgxNmQzM2IwPl0gPyB0Y3Bfd3JpdGVfdGltZXJfaGFuZGxlcisweDFhMC8weDFhMA0KWyAg
MzcwLjA0NzA1MV0gIFs8ZmZmZmZmZmY4MTZkMmYzOD5dIHRjcF9yZXRyYW5zbWl0X3RpbWVy
KzB4MzU4LzB4NjMwDQpbICAzNzAuMDQ3MDU3XSAgWzxmZmZmZmZmZjgxNmQzMzRkPl0gdGNw
X3dyaXRlX3RpbWVyX2hhbmRsZXIrMHgxM2QvMHgxYTANClsgIDM3MC4wNDcwNjNdICBbPGZm
ZmZmZmZmODE2ZDM0Mjg+XSB0Y3Bfd3JpdGVfdGltZXIrMHg3OC8weDgwDQpbICAzNzAuMDQ3
MDY4XSAgWzxmZmZmZmZmZjgxMDczZjdjPl0gY2FsbF90aW1lcl9mbisweDdjLzB4MTAwDQpb
ICAzNzAuMDQ3MDczXSAgWzxmZmZmZmZmZjgxMDczZjAwPl0gPyBjYXNjYWRlKzB4YTAvMHhh
MA0KWyAgMzcwLjA0NzA3OV0gIFs8ZmZmZmZmZmY4MTZkMzNiMD5dID8gdGNwX3dyaXRlX3Rp
bWVyX2hhbmRsZXIrMHgxYTAvMHgxYTANClsgIDM3MC4wNDcwODVdICBbPGZmZmZmZmZmODE2
ZDMzYjA+XSA/IHRjcF93cml0ZV90aW1lcl9oYW5kbGVyKzB4MWEwLzB4MWEwDQpbICAzNzAu
MDQ3MjM0XSAgWzxmZmZmZmZmZjgxMDc0MjE3Pl0gcnVuX3RpbWVyX3NvZnRpcnErMHgyMTcv
MHgyNTANClsgIDM3MC4wNDcyNDFdICBbPGZmZmZmZmZmODEwNmUzZDk+XSBfX2RvX3NvZnRp
cnErMHhjOS8weDFhMA0KWyAgMzcwLjA0NzI0OF0gIFs8ZmZmZmZmZmY4MTc0OGQzYz5dIGNh
bGxfc29mdGlycSsweDFjLzB4MzANClsgIDM3MC4wNDcyNTRdICBbPGZmZmZmZmZmODEwMGVk
YjU+XSBkb19zb2Z0aXJxKzB4ODUvMHhmMA0KWyAgMzcwLjA0NzI1OV0gIFs8ZmZmZmZmZmY4
MTA2ZTI0ZT5dIGlycV9leGl0KzB4OWUvMHhkMA0KWyAgMzcwLjA0NzI2Nl0gIFs8ZmZmZmZm
ZmY4MTMzOWY1Zj5dIHhlbl9ldnRjaG5fZG9fdXBjYWxsKzB4MmYvMHg0MA0KWyAgMzcwLjA0
NzI3Ml0gIFs8ZmZmZmZmZmY4MTc0OGQ5ZT5dIHhlbl9kb19oeXBlcnZpc29yX2NhbGxiYWNr
KzB4MWUvMHgzMA0KWyAgMzcwLjA0NzI3N10gIDxFT0k+ICBbPGZmZmZmZmZmODEwMDEzYWE+
XSA/IHhlbl9oeXBlcmNhbGxfc2NoZWRfb3ArMHhhLzB4MjANClsgIDM3MC4wNDcyODddICBb
PGZmZmZmZmZmODEwMDEzYWE+XSA/IHhlbl9oeXBlcmNhbGxfc2NoZWRfb3ArMHhhLzB4MjAN
ClsgIDM3MC4wNDcyOTNdICBbPGZmZmZmZmZmODEwMDg2OTA+XSA/IHhlbl9zYWZlX2hhbHQr
MHgxMC8weDIwDQpbICAzNzAuMDQ3MzAwXSAgWzxmZmZmZmZmZjgxMDE2MGQwPl0gPyBkZWZh
dWx0X2lkbGUrMHg0MC8weDkwDQpbICAzNzAuMDQ3MzA1XSAgWzxmZmZmZmZmZjgxMDE2NDg2
Pl0gPyBjcHVfaWRsZSsweDk2LzB4ZjANClsgIDM3MC4wNDczMTFdICBbPGZmZmZmZmZmODE3
MjJkM2M+XSA/IHJlc3RfaW5pdCsweGJjLzB4ZDANClsgIDM3MC4wNDczMTZdICBbPGZmZmZm
ZmZmODE3MjJjODA+XSA/IGNzdW1fcGFydGlhbF9jb3B5X2dlbmVyaWMrMHgxNzAvMHgxNzAN
ClsgIDM3MC4wNDczMjVdICBbPGZmZmZmZmZmODFjZTBkZjI+XSA/IHN0YXJ0X2tlcm5lbCsw
eDM5MC8weDM5ZA0KWyAgMzcwLjA0NzMzMV0gIFs8ZmZmZmZmZmY4MWNlMDg4Mj5dID8ga2Vy
bmVsX2luaXQrMHgyMGIvMHgyMGINClsgIDM3MC4wNDczMzddICBbPGZmZmZmZmZmODFjZTAz
NTY+XSA/IHg4Nl82NF9zdGFydF9yZXNlcnZhdGlvbnMrMHgxMzEvMHgxMzYNClsgIDM3MC4w
NDczNDNdICBbPGZmZmZmZmZmODFjZTNkNjA+XSA/IHhlbl9zdGFydF9rZXJuZWwrMHg3MGQv
MHg3MGYNClsgIDM3MC4wNDczNDldIC0tLVsgZW5kIHRyYWNlIDJlMjhlZWM5M2I3YThiOWIg
XS0tLQ0KWyAgMzcwLjk5Njc4OV0gLS0tLS0tLS0tLS0tWyBjdXQgaGVyZSBdLS0tLS0tLS0t
LS0tDQpbICAzNzAuOTk2ODA3XSBXQVJOSU5HOiBhdCBkcml2ZXJzL25ldC94ZW4tbmV0ZnJv
bnQuYzo0NjUgeGVubmV0X3N0YXJ0X3htaXQrMHg3ZmUvMHg4NjAoKQ0KWyAgMzcwLjk5Njgx
NF0gTW9kdWxlcyBsaW5rZWQgaW46DQpbICAzNzAuOTk2ODIwXSBQaWQ6IDAsIGNvbW06IHN3
YXBwZXIvMCBUYWludGVkOiBHICAgICAgICBXICAgIDMuNi4wcHJlLXJjMS0yMDEyMTAxMSAj
MQ0KWyAgMzcwLjk5NjgyNl0gQ2FsbCBUcmFjZToNClsgIDM3MC45OTY4MjldICA8SVJRPiAg
WzxmZmZmZmZmZjgxMDY2NGVhPl0gd2Fybl9zbG93cGF0aF9jb21tb24rMHg3YS8weGIwDQpb
ICAzNzAuOTk2ODQwXSAgWzxmZmZmZmZmZjgxMDY2NTM1Pl0gd2Fybl9zbG93cGF0aF9udWxs
KzB4MTUvMHgyMA0KWyAgMzcwLjk5Njg0NV0gIFs8ZmZmZmZmZmY4MTQ2ZDg5ZT5dIHhlbm5l
dF9zdGFydF94bWl0KzB4N2ZlLzB4ODYwDQpbICAzNzAuOTk2ODUyXSAgWzxmZmZmZmZmZjgx
NjFmMzQ5Pl0gZGV2X2hhcmRfc3RhcnRfeG1pdCsweDIwOS8weDQ2MA0KWyAgMzcwLjk5Njg1
OF0gIFs8ZmZmZmZmZmY4MTYzYjAzNj5dIHNjaF9kaXJlY3RfeG1pdCsweGY2LzB4MjkwDQpb
ICAzNzAuOTk2ODYzXSAgWzxmZmZmZmZmZjgxNjFmNzQ2Pl0gZGV2X3F1ZXVlX3htaXQrMHgx
YTYvMHg1YTANClsgIDM3MC45OTY4NjhdICBbPGZmZmZmZmZmODE2MWY1YTA+XSA/IGRldl9o
YXJkX3N0YXJ0X3htaXQrMHg0NjAvMHg0NjANClsgIDM3MC45OTY4NzVdICBbPGZmZmZmZmZm
ODEwYjE0MTc+XSA/IGxvY2tfcmVsZWFzZSsweDExNy8weDI1MA0KWyAgMzcwLjk5Njg4MV0g
IFs8ZmZmZmZmZmY4MTZiOTUzNj5dIGlwX2ZpbmlzaF9vdXRwdXQrMHgyMjYvMHg1MzANClsg
IDM3MC45OTY4ODZdICBbPGZmZmZmZmZmODE2YjkzZGQ+XSA/IGlwX2ZpbmlzaF9vdXRwdXQr
MHhjZC8weDUzMA0KWyAgMzcwLjk5Njg5Ml0gIFs8ZmZmZmZmZmY4MTZiOTg5OT5dIGlwX291
dHB1dCsweDU5LzB4ZTANClsgIDM3MC45OTY4OTZdICBbPGZmZmZmZmZmODE2YjgzYjg+XSBp
cF9sb2NhbF9vdXQrMHgyOC8weDkwDQpbICAzNzAuOTk2OTAxXSAgWzxmZmZmZmZmZjgxNmI4
OTZmPl0gaXBfcXVldWVfeG1pdCsweDE3Zi8weDRhMA0KWyAgMzcwLjk5NjkwNl0gIFs8ZmZm
ZmZmZmY4MTZiODdmMD5dID8gaXBfc2VuZF91bmljYXN0X3JlcGx5KzB4MzQwLzB4MzQwDQpb
ICAzNzAuOTk2OTEyXSAgWzxmZmZmZmZmZjgxMGEwYmE3Pl0gPyBnZXRuc3RpbWVvZmRheSsw
eDQ3LzB4ZTANClsgIDM3MC45OTY5MjZdICBbPGZmZmZmZmZmODE2MGY0Yzk+XSA/IF9fc2ti
X2Nsb25lKzB4MjkvMHgxMjANClsgIDM3MC45OTY5NDFdICBbPGZmZmZmZmZmODE2Y2VhMjA+
XSB0Y3BfdHJhbnNtaXRfc2tiKzB4NDAwLzB4OGQwDQpbICAzNzAuOTk2OTQ3XSAgWzxmZmZm
ZmZmZjgxNmQxMTA2Pl0gdGNwX3JldHJhbnNtaXRfc2tiKzB4MWM2LzB4NWEwDQpbICAzNzAu
OTk2OTUzXSAgWzxmZmZmZmZmZjgxNmQzM2IwPl0gPyB0Y3Bfd3JpdGVfdGltZXJfaGFuZGxl
cisweDFhMC8weDFhMA0KWyAgMzcwLjk5Njk1OV0gIFs8ZmZmZmZmZmY4MTZkMmYzOD5dIHRj
cF9yZXRyYW5zbWl0X3RpbWVyKzB4MzU4LzB4NjMwDQpbICAzNzAuOTk2OTY1XSAgWzxmZmZm
ZmZmZjgxNmQzMzRkPl0gdGNwX3dyaXRlX3RpbWVyX2hhbmRsZXIrMHgxM2QvMHgxYTANClsg
IDM3MC45OTY5NzFdICBbPGZmZmZmZmZmODE2ZDM0Mjg+XSB0Y3Bfd3JpdGVfdGltZXIrMHg3
OC8weDgwDQpbICAzNzAuOTk2OTc3XSAgWzxmZmZmZmZmZjgxMDczZjdjPl0gY2FsbF90aW1l
cl9mbisweDdjLzB4MTAwDQpbICAzNzAuOTk2OTgzXSAgWzxmZmZmZmZmZjgxMDczZjAwPl0g
PyBjYXNjYWRlKzB4YTAvMHhhMA0KWyAgMzcwLjk5Njk4OF0gIFs8ZmZmZmZmZmY4MTZkMzNi
MD5dID8gdGNwX3dyaXRlX3RpbWVyX2hhbmRsZXIrMHgxYTAvMHgxYTANClsgIDM3MC45OTY5
OThdICBbPGZmZmZmZmZmODE2ZDMzYjA+XSA/IHRjcF93cml0ZV90aW1lcl9oYW5kbGVyKzB4
MWEwLzB4MWEwDQpbICAzNzAuOTk3MDA0XSAgWzxmZmZmZmZmZjgxMDc0MjE3Pl0gcnVuX3Rp
bWVyX3NvZnRpcnErMHgyMTcvMHgyNTANClsgIDM3MC45OTcwMTFdICBbPGZmZmZmZmZmODEw
NmUzZDk+XSBfX2RvX3NvZnRpcnErMHhjOS8weDFhMA0KWyAgMzcwLjk5NzAxN10gIFs8ZmZm
ZmZmZmY4MTc0OGQzYz5dIGNhbGxfc29mdGlycSsweDFjLzB4MzANClsgIDM3MC45OTcwMjNd
ICBbPGZmZmZmZmZmODEwMGVkYjU+XSBkb19zb2Z0aXJxKzB4ODUvMHhmMA0KWyAgMzcwLjk5
NzAyOV0gIFs8ZmZmZmZmZmY4MTA2ZTI0ZT5dIGlycV9leGl0KzB4OWUvMHhkMA0KWyAgMzcw
Ljk5NzAzNl0gIFs8ZmZmZmZmZmY4MTMzOWY1Zj5dIHhlbl9ldnRjaG5fZG9fdXBjYWxsKzB4
MmYvMHg0MA0KWyAgMzcwLjk5NzA0Ml0gIFs8ZmZmZmZmZmY4MTc0OGQ5ZT5dIHhlbl9kb19o
eXBlcnZpc29yX2NhbGxiYWNrKzB4MWUvMHgzMA0KWyAgMzcwLjk5NzA0Nl0gIDxFT0k+ICBb
PGZmZmZmZmZmODEwMDEzYWE+XSA/IHhlbl9oeXBlcmNhbGxfc2NoZWRfb3ArMHhhLzB4MjAN
ClsgIDM3MC45OTcwNTddICBbPGZmZmZmZmZmODEwMDEzYWE+XSA/IHhlbl9oeXBlcmNhbGxf
c2NoZWRfb3ArMHhhLzB4MjANClsgIDM3MC45OTcwNjRdICBbPGZmZmZmZmZmODEwMDg2OTA+
XSA/IHhlbl9zYWZlX2hhbHQrMHgxMC8weDIwDQpbICAzNzAuOTk3MDcwXSAgWzxmZmZmZmZm
ZjgxMDE2MGQwPl0gPyBkZWZhdWx0X2lkbGUrMHg0MC8weDkwDQpbICAzNzAuOTk3MDc1XSAg
WzxmZmZmZmZmZjgxMDE2NDg2Pl0gPyBjcHVfaWRsZSsweDk2LzB4ZjANClsgIDM3MC45OTcw
ODFdICBbPGZmZmZmZmZmODE3MjJkM2M+XSA/IHJlc3RfaW5pdCsweGJjLzB4ZDANClsgIDM3
MC45OTcwOTNdICBbPGZmZmZmZmZmODE3MjJjODA+XSA/IGNzdW1fcGFydGlhbF9jb3B5X2dl
bmVyaWMrMHgxNzAvMHgxNzANClsgIDM3MC45OTcxMDJdICBbPGZmZmZmZmZmODFjZTBkZjI+
XSA/IHN0YXJ0X2tlcm5lbCsweDM5MC8weDM5ZA0KWyAgMzcwLjk5NzEwOF0gIFs8ZmZmZmZm
ZmY4MWNlMDg4Mj5dID8ga2VybmVsX2luaXQrMHgyMGIvMHgyMGINClsgIDM3MC45OTcxMTRd
ICBbPGZmZmZmZmZmODFjZTAzNTY+XSA/IHg4Nl82NF9zdGFydF9yZXNlcnZhdGlvbnMrMHgx
MzEvMHgxMzYNClsgIDM3MC45OTcxMjBdICBbPGZmZmZmZmZmODFjZTNkNjA+XSA/IHhlbl9z
dGFydF9rZXJuZWwrMHg3MGQvMHg3MGYNClsgIDM3MC45OTcxMjZdIC0tLVsgZW5kIHRyYWNl
IDJlMjhlZWM5M2I3YThiOWMgXS0tLQ0KWyAgMzcyLjg5MzU3MF0gLS0tLS0tLS0tLS0tWyBj
dXQgaGVyZSBdLS0tLS0tLS0tLS0tDQpbICAzNzIuODkzNTk0XSBXQVJOSU5HOiBhdCBkcml2
ZXJzL25ldC94ZW4tbmV0ZnJvbnQuYzo0NjUgeGVubmV0X3N0YXJ0X3htaXQrMHg3ZmUvMHg4
NjAoKQ0KWyAgMzcyLjg5MzYwMV0gTW9kdWxlcyBsaW5rZWQgaW46DQpbICAzNzIuODkzNjA3
XSBQaWQ6IDAsIGNvbW06IHN3YXBwZXIvMCBUYWludGVkOiBHICAgICAgICBXICAgIDMuNi4w
cHJlLXJjMS0yMDEyMTAxMSAjMQ0KWyAgMzcyLjg5MzYxM10gQ2FsbCBUcmFjZToNClsgIDM3
Mi44OTM2MTddICA8SVJRPiAgWzxmZmZmZmZmZjgxMDY2NGVhPl0gd2Fybl9zbG93cGF0aF9j
b21tb24rMHg3YS8weGIwDQpbICAzNzIuODkzNjMwXSAgWzxmZmZmZmZmZjgxMDY2NTM1Pl0g
d2Fybl9zbG93cGF0aF9udWxsKzB4MTUvMHgyMA0KWyAgMzcyLjg5MzYzNl0gIFs8ZmZmZmZm
ZmY4MTQ2ZDg5ZT5dIHhlbm5ldF9zdGFydF94bWl0KzB4N2ZlLzB4ODYwDQpbICAzNzIuODkz
NjQ0XSAgWzxmZmZmZmZmZjgxNjFmMzQ5Pl0gZGV2X2hhcmRfc3RhcnRfeG1pdCsweDIwOS8w
eDQ2MA0KWyAgMzcyLjg5MzY1MV0gIFs8ZmZmZmZmZmY4MTYzYjAzNj5dIHNjaF9kaXJlY3Rf
eG1pdCsweGY2LzB4MjkwDQpbICAzNzIuODkzNjU3XSAgWzxmZmZmZmZmZjgxNjFmNzQ2Pl0g
ZGV2X3F1ZXVlX3htaXQrMHgxYTYvMHg1YTANClsgIDM3Mi44OTM2NjNdICBbPGZmZmZmZmZm
ODE2MWY1YTA+XSA/IGRldl9oYXJkX3N0YXJ0X3htaXQrMHg0NjAvMHg0NjANClsgIDM3Mi44
OTM2NjldICBbPGZmZmZmZmZmODEwYjE0MTc+XSA/IGxvY2tfcmVsZWFzZSsweDExNy8weDI1
MA0KWyAgMzcyLjg5MzY3Nl0gIFs8ZmZmZmZmZmY4MTZiOTUzNj5dIGlwX2ZpbmlzaF9vdXRw
dXQrMHgyMjYvMHg1MzANClsgIDM3Mi44OTM2ODJdICBbPGZmZmZmZmZmODE2YjkzZGQ+XSA/
IGlwX2ZpbmlzaF9vdXRwdXQrMHhjZC8weDUzMA0KWyAgMzcyLjg5MzY4OF0gIFs8ZmZmZmZm
ZmY4MTZiOTg5OT5dIGlwX291dHB1dCsweDU5LzB4ZTANClsgIDM3Mi44OTM2OTRdICBbPGZm
ZmZmZmZmODE2YjgzYjg+XSBpcF9sb2NhbF9vdXQrMHgyOC8weDkwDQpbICAzNzIuODkzNjk5
XSAgWzxmZmZmZmZmZjgxNmI4OTZmPl0gaXBfcXVldWVfeG1pdCsweDE3Zi8weDRhMA0KWyAg
MzcyLjg5MzcwNV0gIFs8ZmZmZmZmZmY4MTZiODdmMD5dID8gaXBfc2VuZF91bmljYXN0X3Jl
cGx5KzB4MzQwLzB4MzQwDQpbICAzNzIuODkzNzExXSAgWzxmZmZmZmZmZjgxMGEwYmE3Pl0g
PyBnZXRuc3RpbWVvZmRheSsweDQ3LzB4ZTANClsgIDM3Mi44OTM3MThdICBbPGZmZmZmZmZm
ODE2MGY0Yzk+XSA/IF9fc2tiX2Nsb25lKzB4MjkvMHgxMjANClsgIDM3Mi44OTM3MjRdICBb
PGZmZmZmZmZmODE2Y2VhMjA+XSB0Y3BfdHJhbnNtaXRfc2tiKzB4NDAwLzB4OGQwDQpbICAz
NzIuODkzNzMwXSAgWzxmZmZmZmZmZjgxNmQxMTA2Pl0gdGNwX3JldHJhbnNtaXRfc2tiKzB4
MWM2LzB4NWEwDQpbICAzNzIuODkzNzM3XSAgWzxmZmZmZmZmZjgxNmQzM2IwPl0gPyB0Y3Bf
d3JpdGVfdGltZXJfaGFuZGxlcisweDFhMC8weDFhMA0KWyAgMzcyLjg5Mzc0M10gIFs8ZmZm
ZmZmZmY4MTZkMmYzOD5dIHRjcF9yZXRyYW5zbWl0X3RpbWVyKzB4MzU4LzB4NjMwDQpbICAz
NzIuODkzNzQ4XSAgWzxmZmZmZmZmZjgxNmQzMzRkPl0gdGNwX3dyaXRlX3RpbWVyX2hhbmRs
ZXIrMHgxM2QvMHgxYTANClsgIDM3Mi44OTM3NTRdICBbPGZmZmZmZmZmODE2ZDM0Mjg+XSB0
Y3Bfd3JpdGVfdGltZXIrMHg3OC8weDgwDQpbICAzNzIuODkzNzYwXSAgWzxmZmZmZmZmZjgx
MDczZjdjPl0gY2FsbF90aW1lcl9mbisweDdjLzB4MTAwDQpbICAzNzIuODkzNzY1XSAgWzxm
ZmZmZmZmZjgxMDczZjAwPl0gPyBjYXNjYWRlKzB4YTAvMHhhMA0KWyAgMzcyLjg5Mzc3MV0g
IFs8ZmZmZmZmZmY4MTZkMzNiMD5dID8gdGNwX3dyaXRlX3RpbWVyX2hhbmRsZXIrMHgxYTAv
MHgxYTANClsgIDM3Mi44OTM3NzddICBbPGZmZmZmZmZmODE2ZDMzYjA+XSA/IHRjcF93cml0
ZV90aW1lcl9oYW5kbGVyKzB4MWEwLzB4MWEwDQpbICAzNzIuODkzOTM5XSAgWzxmZmZmZmZm
ZjgxMDc0MjE3Pl0gcnVuX3RpbWVyX3NvZnRpcnErMHgyMTcvMHgyNTANClsgIDM3Mi44OTM5
NDZdICBbPGZmZmZmZmZmODEwNmUzZDk+XSBfX2RvX3NvZnRpcnErMHhjOS8weDFhMA0KWyAg
MzcyLjg5Mzk1Ml0gIFs8ZmZmZmZmZmY4MTc0OGQzYz5dIGNhbGxfc29mdGlycSsweDFjLzB4
MzANClsgIDM3Mi44OTM5NThdICBbPGZmZmZmZmZmODEwMGVkYjU+XSBkb19zb2Z0aXJxKzB4
ODUvMHhmMA0KWyAgMzcyLjg5Mzk2M10gIFs8ZmZmZmZmZmY4MTA2ZTI0ZT5dIGlycV9leGl0
KzB4OWUvMHhkMA0KWyAgMzcyLjg5Mzk3MF0gIFs8ZmZmZmZmZmY4MTMzOWY1Zj5dIHhlbl9l
dnRjaG5fZG9fdXBjYWxsKzB4MmYvMHg0MA0KWyAgMzcyLjg5Mzk3Nl0gIFs8ZmZmZmZmZmY4
MTc0OGQ5ZT5dIHhlbl9kb19oeXBlcnZpc29yX2NhbGxiYWNrKzB4MWUvMHgzMA0KWyAgMzcy
Ljg5Mzk4MF0gIDxFT0k+ICBbPGZmZmZmZmZmODEwMDEzYWE+XSA/IHhlbl9oeXBlcmNhbGxf
c2NoZWRfb3ArMHhhLzB4MjANClsgIDM3Mi44OTM5OTBdICBbPGZmZmZmZmZmODEwMDEzYWE+
XSA/IHhlbl9oeXBlcmNhbGxfc2NoZWRfb3ArMHhhLzB4MjANClsgIDM3Mi44OTM5OTddICBb
PGZmZmZmZmZmODEwMDg2OTA+XSA/IHhlbl9zYWZlX2hhbHQrMHgxMC8weDIwDQpbICAzNzIu
ODk0MDAzXSAgWzxmZmZmZmZmZjgxMDE2MGQwPl0gPyBkZWZhdWx0X2lkbGUrMHg0MC8weDkw
DQpbICAzNzIuODk0MDA4XSAgWzxmZmZmZmZmZjgxMDE2NDg2Pl0gPyBjcHVfaWRsZSsweDk2
LzB4ZjANClsgIDM3Mi44OTQwMTRdICBbPGZmZmZmZmZmODE3MjJkM2M+XSA/IHJlc3RfaW5p
dCsweGJjLzB4ZDANClsgIDM3Mi44OTQwMTldICBbPGZmZmZmZmZmODE3MjJjODA+XSA/IGNz
dW1fcGFydGlhbF9jb3B5X2dlbmVyaWMrMHgxNzAvMHgxNzANClsgIDM3Mi44OTQwMjddICBb
PGZmZmZmZmZmODFjZTBkZjI+XSA/IHN0YXJ0X2tlcm5lbCsweDM5MC8weDM5ZA0KWyAgMzcy
Ljg5NDAzNl0gIFs8ZmZmZmZmZmY4MWNlMDg4Mj5dID8ga2VybmVsX2luaXQrMHgyMGIvMHgy
MGINClsgIDM3Mi44OTQwNDJdICBbPGZmZmZmZmZmODFjZTAzNTY+XSA/IHg4Nl82NF9zdGFy
dF9yZXNlcnZhdGlvbnMrMHgxMzEvMHgxMzYNClsgIDM3Mi44OTQwNDhdICBbPGZmZmZmZmZm
ODFjZTNkNjA+XSA/IHhlbl9zdGFydF9rZXJuZWwrMHg3MGQvMHg3MGYNClsgIDM3Mi44OTQw
NTRdIC0tLVsgZW5kIHRyYWNlIDJlMjhlZWM5M2I3YThiOWQgXS0tLQ0KWyAgMzc0Ljk4Njc3
MF0gLS0tLS0tLS0tLS0tWyBjdXQgaGVyZSBdLS0tLS0tLS0tLS0tDQpbICAzNzQuOTg2Nzk1
XSBXQVJOSU5HOiBhdCBkcml2ZXJzL25ldC94ZW4tbmV0ZnJvbnQuYzo0NjUgeGVubmV0X3N0
YXJ0X3htaXQrMHg3ZmUvMHg4NjAoKQ0KWyAgMzc0Ljk4NjgwMl0gTW9kdWxlcyBsaW5rZWQg
aW46DQpbICAzNzQuOTg2ODEwXSBQaWQ6IDAsIGNvbW06IHN3YXBwZXIvMCBUYWludGVkOiBH
ICAgICAgICBXICAgIDMuNi4wcHJlLXJjMS0yMDEyMTAxMSAjMQ0KWyAgMzc0Ljk4NjgxNl0g
Q2FsbCBUcmFjZToNClsgIDM3NC45ODY4MTldICA8SVJRPiAgWzxmZmZmZmZmZjgxMDY2NGVh
Pl0gd2Fybl9zbG93cGF0aF9jb21tb24rMHg3YS8weGIwDQpbICAzNzQuOTg2ODMzXSAgWzxm
ZmZmZmZmZjgxMDY2NTM1Pl0gd2Fybl9zbG93cGF0aF9udWxsKzB4MTUvMHgyMA0KWyAgMzc0
Ljk4NjgzOF0gIFs8ZmZmZmZmZmY4MTQ2ZDg5ZT5dIHhlbm5ldF9zdGFydF94bWl0KzB4N2Zl
LzB4ODYwDQpbICAzNzQuOTg2ODQ3XSAgWzxmZmZmZmZmZjgxNjFmMzQ5Pl0gZGV2X2hhcmRf
c3RhcnRfeG1pdCsweDIwOS8weDQ2MA0KWyAgMzc0Ljk4Njg1NF0gIFs8ZmZmZmZmZmY4MTYz
YjAzNj5dIHNjaF9kaXJlY3RfeG1pdCsweGY2LzB4MjkwDQpbICAzNzQuOTg2ODU5XSAgWzxm
ZmZmZmZmZjgxNjFmNzQ2Pl0gZGV2X3F1ZXVlX3htaXQrMHgxYTYvMHg1YTANClsgIDM3NC45
ODY4NjRdICBbPGZmZmZmZmZmODE2MWY1YTA+XSA/IGRldl9oYXJkX3N0YXJ0X3htaXQrMHg0
NjAvMHg0NjANClsgIDM3NC45ODY4NzFdICBbPGZmZmZmZmZmODEwYjE0MTc+XSA/IGxvY2tf
cmVsZWFzZSsweDExNy8weDI1MA0KWyAgMzc0Ljk4Njg3OV0gIFs8ZmZmZmZmZmY4MTZiOTUz
Nj5dIGlwX2ZpbmlzaF9vdXRwdXQrMHgyMjYvMHg1MzANClsgIDM3NC45ODY4ODRdICBbPGZm
ZmZmZmZmODE2YjkzZGQ+XSA/IGlwX2ZpbmlzaF9vdXRwdXQrMHhjZC8weDUzMA0KWyAgMzc0
Ljk4Njg5MF0gIFs8ZmZmZmZmZmY4MTZiOTg5OT5dIGlwX291dHB1dCsweDU5LzB4ZTANClsg
IDM3NC45ODY4OTRdICBbPGZmZmZmZmZmODE2YjgzYjg+XSBpcF9sb2NhbF9vdXQrMHgyOC8w
eDkwDQpbICAzNzQuOTg2ODk5XSAgWzxmZmZmZmZmZjgxNmI4OTZmPl0gaXBfcXVldWVfeG1p
dCsweDE3Zi8weDRhMA0KWyAgMzc0Ljk4NjkwNF0gIFs8ZmZmZmZmZmY4MTZiODdmMD5dID8g
aXBfc2VuZF91bmljYXN0X3JlcGx5KzB4MzQwLzB4MzQwDQpbICAzNzQuOTg2OTExXSAgWzxm
ZmZmZmZmZjgxMGEwYmE3Pl0gPyBnZXRuc3RpbWVvZmRheSsweDQ3LzB4ZTANClsgIDM3NC45
ODY5MThdICBbPGZmZmZmZmZmODE2MGY0Yzk+XSA/IF9fc2tiX2Nsb25lKzB4MjkvMHgxMjAN
ClsgIDM3NC45ODY5MjZdICBbPGZmZmZmZmZmODE2Y2VhMjA+XSB0Y3BfdHJhbnNtaXRfc2ti
KzB4NDAwLzB4OGQwDQpbICAzNzQuOTg2OTMxXSAgWzxmZmZmZmZmZjgxNmQxMTA2Pl0gdGNw
X3JldHJhbnNtaXRfc2tiKzB4MWM2LzB4NWEwDQpbICAzNzQuOTg2OTM3XSAgWzxmZmZmZmZm
ZjgxNmQzM2IwPl0gPyB0Y3Bfd3JpdGVfdGltZXJfaGFuZGxlcisweDFhMC8weDFhMA0KWyAg
Mzc0Ljk4Njk0Ml0gIFs8ZmZmZmZmZmY4MTZkMmYzOD5dIHRjcF9yZXRyYW5zbWl0X3RpbWVy
KzB4MzU4LzB4NjMwDQpbICAzNzQuOTg2OTQ3XSAgWzxmZmZmZmZmZjgxNmQzMzRkPl0gdGNw
X3dyaXRlX3RpbWVyX2hhbmRsZXIrMHgxM2QvMHgxYTANClsgIDM3NC45ODY5NTNdICBbPGZm
ZmZmZmZmODE2ZDM0Mjg+XSB0Y3Bfd3JpdGVfdGltZXIrMHg3OC8weDgwDQpbICAzNzQuOTg2
OTU4XSAgWzxmZmZmZmZmZjgxMDczZjdjPl0gY2FsbF90aW1lcl9mbisweDdjLzB4MTAwDQpb
ICAzNzQuOTg2OTYzXSAgWzxmZmZmZmZmZjgxMDczZjAwPl0gPyBjYXNjYWRlKzB4YTAvMHhh
MA0KWyAgMzc0Ljk4Njk2N10gIFs8ZmZmZmZmZmY4MTZkMzNiMD5dID8gdGNwX3dyaXRlX3Rp
bWVyX2hhbmRsZXIrMHgxYTAvMHgxYTANClsgIDM3NC45ODY5NzNdICBbPGZmZmZmZmZmODE2
ZDMzYjA+XSA/IHRjcF93cml0ZV90aW1lcl9oYW5kbGVyKzB4MWEwLzB4MWEwDQpbICAzNzQu
OTg2OTc4XSAgWzxmZmZmZmZmZjgxMDc0MjE3Pl0gcnVuX3RpbWVyX3NvZnRpcnErMHgyMTcv
MHgyNTANClsgIDM3NC45ODY5ODVdICBbPGZmZmZmZmZmODEwNmUzZDk+XSBfX2RvX3NvZnRp
cnErMHhjOS8weDFhMA0KWyAgMzc0Ljk4Njk5MV0gIFs8ZmZmZmZmZmY4MTc0OGQzYz5dIGNh
bGxfc29mdGlycSsweDFjLzB4MzANClsgIDM3NC45ODY5OTddICBbPGZmZmZmZmZmODEwMGVk
YjU+XSBkb19zb2Z0aXJxKzB4ODUvMHhmMA0KWyAgMzc0Ljk4NzAwMl0gIFs8ZmZmZmZmZmY4
MTA2ZTI0ZT5dIGlycV9leGl0KzB4OWUvMHhkMA0KWyAgMzc0Ljk4NzAwOV0gIFs8ZmZmZmZm
ZmY4MTMzOWY1Zj5dIHhlbl9ldnRjaG5fZG9fdXBjYWxsKzB4MmYvMHg0MA0KWyAgMzc0Ljk4
NzAxNF0gIFs8ZmZmZmZmZmY4MTc0OGQ5ZT5dIHhlbl9kb19oeXBlcnZpc29yX2NhbGxiYWNr
KzB4MWUvMHgzMA0KWyAgMzc0Ljk4NzAxOF0gIDxFT0k+ICBbPGZmZmZmZmZmODEwMDEzYWE+
XSA/IHhlbl9oeXBlcmNhbGxfc2NoZWRfb3ArMHhhLzB4MjANClsgIDM3NC45ODcwMjhdICBb
PGZmZmZmZmZmODEwMDEzYWE+XSA/IHhlbl9oeXBlcmNhbGxfc2NoZWRfb3ArMHhhLzB4MjAN
ClsgIDM3NC45ODcwMzldICBbPGZmZmZmZmZmODEwMDg2OTA+XSA/IHhlbl9zYWZlX2hhbHQr
MHgxMC8weDIwDQpbICAzNzQuOTg3MDU5XSAgWzxmZmZmZmZmZjgxMDE2MGQwPl0gPyBkZWZh
dWx0X2lkbGUrMHg0MC8weDkwDQpbICAzNzQuOTg3MDY0XSAgWzxmZmZmZmZmZjgxMDE2NDg2
Pl0gPyBjcHVfaWRsZSsweDk2LzB4ZjANClsgIDM3NC45ODcwNzBdICBbPGZmZmZmZmZmODE3
MjJkM2M+XSA/IHJlc3RfaW5pdCsweGJjLzB4ZDANClsgIDM3NC45ODcwNzVdICBbPGZmZmZm
ZmZmODE3MjJjODA+XSA/IGNzdW1fcGFydGlhbF9jb3B5X2dlbmVyaWMrMHgxNzAvMHgxNzAN
ClsgIDM3NC45ODcwODRdICBbPGZmZmZmZmZmODFjZTBkZjI+XSA/IHN0YXJ0X2tlcm5lbCsw
eDM5MC8weDM5ZA0KWyAgMzc0Ljk4NzA5MV0gIFs8ZmZmZmZmZmY4MWNlMDg4Mj5dID8ga2Vy
bmVsX2luaXQrMHgyMGIvMHgyMGINClsgIDM3NC45ODcwOTddICBbPGZmZmZmZmZmODFjZTAz
NTY+XSA/IHg4Nl82NF9zdGFydF9yZXNlcnZhdGlvbnMrMHgxMzEvMHgxMzYNClsgIDM3NC45
ODcxMDRdICBbPGZmZmZmZmZmODFjZTNkNjA+XSA/IHhlbl9zdGFydF9rZXJuZWwrMHg3MGQv
MHg3MGYNClsgIDM3NC45ODcxMTBdIC0tLVsgZW5kIHRyYWNlIDJlMjhlZWM5M2I3YThiOWUg
XS0tLQ0KWyAgMzc2LjY5MzUyOV0gLS0tLS0tLS0tLS0tWyBjdXQgaGVyZSBdLS0tLS0tLS0t
LS0tDQpbICAzNzYuNjkzNTgyXSBXQVJOSU5HOiBhdCBkcml2ZXJzL25ldC94ZW4tbmV0ZnJv
bnQuYzo0NjUgeGVubmV0X3N0YXJ0X3htaXQrMHg3ZmUvMHg4NjAoKQ0KWyAgMzc2LjY5MzYw
N10gTW9kdWxlcyBsaW5rZWQgaW46DQpbICAzNzYuNjkzNjMwXSBQaWQ6IDAsIGNvbW06IHN3
YXBwZXIvMCBUYWludGVkOiBHICAgICAgICBXICAgIDMuNi4wcHJlLXJjMS0yMDEyMTAxMSAj
MQ0KWyAgMzc2LjY5MzY1NF0gQ2FsbCBUcmFjZToNClsgIDM3Ni42OTM2NjZdICA8SVJRPiAg
WzxmZmZmZmZmZjgxMDY2NGVhPl0gd2Fybl9zbG93cGF0aF9jb21tb24rMHg3YS8weGIwDQpb
ICAzNzYuNjkzNzA4XSAgWzxmZmZmZmZmZjgxMDY2NTM1Pl0gd2Fybl9zbG93cGF0aF9udWxs
KzB4MTUvMHgyMA0KWyAgMzc2LjY5MzczMV0gIFs8ZmZmZmZmZmY4MTQ2ZDg5ZT5dIHhlbm5l
dF9zdGFydF94bWl0KzB4N2ZlLzB4ODYwDQpbICAzNzYuNjkzNzU4XSAgWzxmZmZmZmZmZjgx
NjFmMzQ5Pl0gZGV2X2hhcmRfc3RhcnRfeG1pdCsweDIwOS8weDQ2MA0KWyAgMzc2LjY5Mzc4
M10gIFs8ZmZmZmZmZmY4MTYzYjAzNj5dIHNjaF9kaXJlY3RfeG1pdCsweGY2LzB4MjkwDQpb
ICAzNzYuNjkzODA2XSAgWzxmZmZmZmZmZjgxNjFmNzQ2Pl0gZGV2X3F1ZXVlX3htaXQrMHgx
YTYvMHg1YTANClsgIDM3Ni42OTM4MjhdICBbPGZmZmZmZmZmODE2MWY1YTA+XSA/IGRldl9o
YXJkX3N0YXJ0X3htaXQrMHg0NjAvMHg0NjANClsgIDM3Ni42OTM4NTJdICBbPGZmZmZmZmZm
ODEwYjE0MTc+XSA/IGxvY2tfcmVsZWFzZSsweDExNy8weDI1MA0KWyAgMzc2LjY5Mzg3N10g
IFs8ZmZmZmZmZmY4MTZiOTUzNj5dIGlwX2ZpbmlzaF9vdXRwdXQrMHgyMjYvMHg1MzANClsg
IDM3Ni42OTM5MDJdICBbPGZmZmZmZmZmODE2YjkzZGQ+XSA/IGlwX2ZpbmlzaF9vdXRwdXQr
MHhjZC8weDUzMA0KWyAgMzc2LjY5MzkyNl0gIFs8ZmZmZmZmZmY4MTZiOTg5OT5dIGlwX291
dHB1dCsweDU5LzB4ZTANClsgIDM3Ni42OTM5NDhdICBbPGZmZmZmZmZmODE2YjgzYjg+XSBp
cF9sb2NhbF9vdXQrMHgyOC8weDkwDQpbICAzNzYuNjkzOTcwXSAgWzxmZmZmZmZmZjgxNmI4
OTZmPl0gaXBfcXVldWVfeG1pdCsweDE3Zi8weDRhMA0KWyAgMzc2LjY5Mzk5MV0gIFs8ZmZm
ZmZmZmY4MTZiODdmMD5dID8gaXBfc2VuZF91bmljYXN0X3JlcGx5KzB4MzQwLzB4MzQwDQpb
ICAzNzYuNjk0MDE3XSAgWzxmZmZmZmZmZjgxMGEwYmE3Pl0gPyBnZXRuc3RpbWVvZmRheSsw
eDQ3LzB4ZTANClsgIDM3Ni42OTQwNDBdICBbPGZmZmZmZmZmODE2MGY0Yzk+XSA/IF9fc2ti
X2Nsb25lKzB4MjkvMHgxMjANClsgIDM3Ni42OTQwNjJdICBbPGZmZmZmZmZmODE2Y2VhMjA+
XSB0Y3BfdHJhbnNtaXRfc2tiKzB4NDAwLzB4OGQwDQpbICAzNzYuNjk0MDg1XSAgWzxmZmZm
ZmZmZjgxNmQxMTA2Pl0gdGNwX3JldHJhbnNtaXRfc2tiKzB4MWM2LzB4NWEwDQpbICAzNzYu
Njk0MTEwXSAgWzxmZmZmZmZmZjgxNmQzM2IwPl0gPyB0Y3Bfd3JpdGVfdGltZXJfaGFuZGxl
cisweDFhMC8weDFhMA0KWyAgMzc2LjY5NDEzM10gIFs8ZmZmZmZmZmY4MTZkMmYzOD5dIHRj
cF9yZXRyYW5zbWl0X3RpbWVyKzB4MzU4LzB4NjMwDQpbICAzNzYuNjk0MTU2XSAgWzxmZmZm
ZmZmZjgxNmQzMzRkPl0gdGNwX3dyaXRlX3RpbWVyX2hhbmRsZXIrMHgxM2QvMHgxYTANClsg
IDM3Ni42OTQxNzldICBbPGZmZmZmZmZmODE2ZDM0Mjg+XSB0Y3Bfd3JpdGVfdGltZXIrMHg3
OC8weDgwDQpbICAzNzYuNjk0MjAxXSAgWzxmZmZmZmZmZjgxMDczZjdjPl0gY2FsbF90aW1l
cl9mbisweDdjLzB4MTAwDQpbICAzNzYuNjk0MjIyXSAgWzxmZmZmZmZmZjgxMDczZjAwPl0g
PyBjYXNjYWRlKzB4YTAvMHhhMA0KWyAgMzc2LjY5NDI0Ml0gIFs8ZmZmZmZmZmY4MTZkMzNi
MD5dID8gdGNwX3dyaXRlX3RpbWVyX2hhbmRsZXIrMHgxYTAvMHgxYTANClsgIDM3Ni42OTQy
NjddICBbPGZmZmZmZmZmODE2ZDMzYjA+XSA/IHRjcF93cml0ZV90aW1lcl9oYW5kbGVyKzB4
MWEwLzB4MWEwDQpbICAzNzYuNjk0MjkwXSAgWzxmZmZmZmZmZjgxMDc0MjE3Pl0gcnVuX3Rp
bWVyX3NvZnRpcnErMHgyMTcvMHgyNTANClsgIDM3Ni42OTQzMTVdICBbPGZmZmZmZmZmODEw
NmUzZDk+XSBfX2RvX3NvZnRpcnErMHhjOS8weDFhMA0KWyAgMzc2LjY5NDMzN10gIFs8ZmZm
ZmZmZmY4MTc0OGQzYz5dIGNhbGxfc29mdGlycSsweDFjLzB4MzANClsgIDM3Ni42OTQzNThd
ICBbPGZmZmZmZmZmODEwMGVkYjU+XSBkb19zb2Z0aXJxKzB4ODUvMHhmMA0KWyAgMzc2LjY5
NDM4MF0gIFs8ZmZmZmZmZmY4MTA2ZTI0ZT5dIGlycV9leGl0KzB4OWUvMHhkMA0KWyAgMzc2
LjY5NDQwNF0gIFs8ZmZmZmZmZmY4MTMzOWY1Zj5dIHhlbl9ldnRjaG5fZG9fdXBjYWxsKzB4
MmYvMHg0MA0KWyAgMzc2LjY5NDQyN10gIFs8ZmZmZmZmZmY4MTc0OGQ5ZT5dIHhlbl9kb19o
eXBlcnZpc29yX2NhbGxiYWNrKzB4MWUvMHgzMA0KWyAgMzc2LjY5NDQ0Nl0gIDxFT0k+ICBb
PGZmZmZmZmZmODEwMDEzYWE+XSA/IHhlbl9oeXBlcmNhbGxfc2NoZWRfb3ArMHhhLzB4MjAN
ClsgIDM3Ni42OTQ0ODRdICBbPGZmZmZmZmZmODEwMDEzYWE+XSA/IHhlbl9oeXBlcmNhbGxf
c2NoZWRfb3ArMHhhLzB4MjANClsgIDM3Ni42OTQ1MDldICBbPGZmZmZmZmZmODEwMDg2OTA+
XSA/IHhlbl9zYWZlX2hhbHQrMHgxMC8weDIwDQpbICAzNzYuNjk0NTMxXSAgWzxmZmZmZmZm
ZjgxMDE2MGQwPl0gPyBkZWZhdWx0X2lkbGUrMHg0MC8weDkwDQpbICAzNzYuNjk0NTUyXSAg
WzxmZmZmZmZmZjgxMDE2NDg2Pl0gPyBjcHVfaWRsZSsweDk2LzB4ZjANClsgIDM3Ni42OTQ1
NzNdICBbPGZmZmZmZmZmODE3MjJkM2M+XSA/IHJlc3RfaW5pdCsweGJjLzB4ZDANClsgIDM3
Ni42OTQ1OTRdICBbPGZmZmZmZmZmODE3MjJjODA+XSA/IGNzdW1fcGFydGlhbF9jb3B5X2dl
bmVyaWMrMHgxNzAvMHgxNzANClsgIDM3Ni42OTQ2MjFdICBbPGZmZmZmZmZmODFjZTBkZjI+
XSA/IHN0YXJ0X2tlcm5lbCsweDM5MC8weDM5ZA0KWyAgMzc2LjY5NDY0NF0gIFs8ZmZmZmZm
ZmY4MWNlMDg4Mj5dID8ga2VybmVsX2luaXQrMHgyMGIvMHgyMGINClsgIDM3Ni42OTQ2NjZd
ICBbPGZmZmZmZmZmODFjZTAzNTY+XSA/IHg4Nl82NF9zdGFydF9yZXNlcnZhdGlvbnMrMHgx
MzEvMHgxMzYNClsgIDM3Ni42OTQ2OTFdICBbPGZmZmZmZmZmODFjZTNkNjA+XSA/IHhlbl9z
dGFydF9rZXJuZWwrMHg3MGQvMHg3MGYNClsgIDM3Ni42OTQ3MTJdIC0tLVsgZW5kIHRyYWNl
IDJlMjhlZWM5M2I3YThiOWYgXS0tLQ0KWyAgMzg0LjI5MzU5Ml0gLS0tLS0tLS0tLS0tWyBj
dXQgaGVyZSBdLS0tLS0tLS0tLS0tDQpbICAzODQuMjkzNjIyXSBXQVJOSU5HOiBhdCBkcml2
ZXJzL25ldC94ZW4tbmV0ZnJvbnQuYzo0NjUgeGVubmV0X3N0YXJ0X3htaXQrMHg3ZmUvMHg4
NjAoKQ0KWyAgMzg0LjI5MzYyOV0gTW9kdWxlcyBsaW5rZWQgaW46DQpbICAzODQuMjkzNjM3
XSBQaWQ6IDAsIGNvbW06IHN3YXBwZXIvMCBUYWludGVkOiBHICAgICAgICBXICAgIDMuNi4w
cHJlLXJjMS0yMDEyMTAxMSAjMQ0KWyAgMzg0LjI5MzY0M10gQ2FsbCBUcmFjZToNClsgIDM4
NC4yOTM2NDddICA8SVJRPiAgWzxmZmZmZmZmZjgxMDY2NGVhPl0gd2Fybl9zbG93cGF0aF9j
b21tb24rMHg3YS8weGIwDQpbICAzODQuMjkzNjYyXSAgWzxmZmZmZmZmZjgxMDY2NTM1Pl0g
d2Fybl9zbG93cGF0aF9udWxsKzB4MTUvMHgyMA0KWyAgMzg0LjI5MzY2N10gIFs8ZmZmZmZm
ZmY4MTQ2ZDg5ZT5dIHhlbm5ldF9zdGFydF94bWl0KzB4N2ZlLzB4ODYwDQpbICAzODQuMjkz
Njc2XSAgWzxmZmZmZmZmZjgxNjFmMzQ5Pl0gZGV2X2hhcmRfc3RhcnRfeG1pdCsweDIwOS8w
eDQ2MA0KWyAgMzg0LjI5MzY4M10gIFs8ZmZmZmZmZmY4MTYzYjAzNj5dIHNjaF9kaXJlY3Rf
eG1pdCsweGY2LzB4MjkwDQpbICAzODQuMjkzNjg5XSAgWzxmZmZmZmZmZjgxNjFmNzQ2Pl0g
ZGV2X3F1ZXVlX3htaXQrMHgxYTYvMHg1YTANClsgIDM4NC4yOTM2OTZdICBbPGZmZmZmZmZm
ODE2MWY1YTA+XSA/IGRldl9oYXJkX3N0YXJ0X3htaXQrMHg0NjAvMHg0NjANClsgIDM4NC4y
OTM3MDRdICBbPGZmZmZmZmZmODEwYjE0MTc+XSA/IGxvY2tfcmVsZWFzZSsweDExNy8weDI1
MA0KWyAgMzg0LjI5MzcxMV0gIFs8ZmZmZmZmZmY4MTZiOTUzNj5dIGlwX2ZpbmlzaF9vdXRw
dXQrMHgyMjYvMHg1MzANClsgIDM4NC4yOTM3MTddICBbPGZmZmZmZmZmODE2YjkzZGQ+XSA/
IGlwX2ZpbmlzaF9vdXRwdXQrMHhjZC8weDUzMA0KWyAgMzg0LjI5MzcyNF0gIFs8ZmZmZmZm
ZmY4MTZiOTg5OT5dIGlwX291dHB1dCsweDU5LzB4ZTANClsgIDM4NC4yOTM3MjldICBbPGZm
ZmZmZmZmODE2YjgzYjg+XSBpcF9sb2NhbF9vdXQrMHgyOC8weDkwDQpbICAzODQuMjkzNzM1
XSAgWzxmZmZmZmZmZjgxNmI4OTZmPl0gaXBfcXVldWVfeG1pdCsweDE3Zi8weDRhMA0KWyAg
Mzg0LjI5Mzc0MV0gIFs8ZmZmZmZmZmY4MTZiODdmMD5dID8gaXBfc2VuZF91bmljYXN0X3Jl
cGx5KzB4MzQwLzB4MzQwDQpbICAzODQuMjkzNzQ3XSAgWzxmZmZmZmZmZjgxMGEwYmE3Pl0g
PyBnZXRuc3RpbWVvZmRheSsweDQ3LzB4ZTANClsgIDM4NC4yOTM3NTRdICBbPGZmZmZmZmZm
ODE2MGY0Yzk+XSA/IF9fc2tiX2Nsb25lKzB4MjkvMHgxMjANClsgIDM4NC4yOTM3NjBdICBb
PGZmZmZmZmZmODE2Y2VhMjA+XSB0Y3BfdHJhbnNtaXRfc2tiKzB4NDAwLzB4OGQwDQpbICAz
ODQuMjkzNzY3XSAgWzxmZmZmZmZmZjgxNmQxMTA2Pl0gdGNwX3JldHJhbnNtaXRfc2tiKzB4
MWM2LzB4NWEwDQpbICAzODQuMjkzNzc1XSAgWzxmZmZmZmZmZjgxNmQzM2IwPl0gPyB0Y3Bf
d3JpdGVfdGltZXJfaGFuZGxlcisweDFhMC8weDFhMA0KWyAgMzg0LjI5Mzc4MV0gIFs8ZmZm
ZmZmZmY4MTZkMmYzOD5dIHRjcF9yZXRyYW5zbWl0X3RpbWVyKzB4MzU4LzB4NjMwDQpbICAz
ODQuMjkzNzg3XSAgWzxmZmZmZmZmZjgxNmQzMzRkPl0gdGNwX3dyaXRlX3RpbWVyX2hhbmRs
ZXIrMHgxM2QvMHgxYTANClsgIDM4NC4yOTM3OTNdICBbPGZmZmZmZmZmODE2ZDM0Mjg+XSB0
Y3Bfd3JpdGVfdGltZXIrMHg3OC8weDgwDQpbICAzODQuMjkzODAwXSAgWzxmZmZmZmZmZjgx
MDczZjdjPl0gY2FsbF90aW1lcl9mbisweDdjLzB4MTAwDQpbICAzODQuMjkzODA1XSAgWzxm
ZmZmZmZmZjgxMDczZjAwPl0gPyBjYXNjYWRlKzB4YTAvMHhhMA0KWyAgMzg0LjI5MzgxMF0g
IFs8ZmZmZmZmZmY4MTZkMzNiMD5dID8gdGNwX3dyaXRlX3RpbWVyX2hhbmRsZXIrMHgxYTAv
MHgxYTANClsgIDM4NC4yOTM4MjRdICBbPGZmZmZmZmZmODE2ZDMzYjA+XSA/IHRjcF93cml0
ZV90aW1lcl9oYW5kbGVyKzB4MWEwLzB4MWEwDQpbICAzODQuMjkzODMwXSAgWzxmZmZmZmZm
ZjgxMDc0MjE3Pl0gcnVuX3RpbWVyX3NvZnRpcnErMHgyMTcvMHgyNTANClsgIDM4NC4yOTM4
MzhdICBbPGZmZmZmZmZmODEwNmUzZDk+XSBfX2RvX3NvZnRpcnErMHhjOS8weDFhMA0KWyAg
Mzg0LjI5Mzg0NV0gIFs8ZmZmZmZmZmY4MTc0OGQzYz5dIGNhbGxfc29mdGlycSsweDFjLzB4
MzANClsgIDM4NC4yOTM4NTFdICBbPGZmZmZmZmZmODEwMGVkYjU+XSBkb19zb2Z0aXJxKzB4
ODUvMHhmMA0KWyAgMzg0LjI5Mzg1N10gIFs8ZmZmZmZmZmY4MTA2ZTI0ZT5dIGlycV9leGl0
KzB4OWUvMHhkMA0KWyAgMzg0LjI5Mzg2NF0gIFs8ZmZmZmZmZmY4MTMzOWY1Zj5dIHhlbl9l
dnRjaG5fZG9fdXBjYWxsKzB4MmYvMHg0MA0KWyAgMzg0LjI5Mzg3MF0gIFs8ZmZmZmZmZmY4
MTc0OGQ5ZT5dIHhlbl9kb19oeXBlcnZpc29yX2NhbGxiYWNrKzB4MWUvMHgzMA0KWyAgMzg0
LjI5Mzg3NV0gIDxFT0k+ICBbPGZmZmZmZmZmODEwMDEzYWE+XSA/IHhlbl9oeXBlcmNhbGxf
c2NoZWRfb3ArMHhhLzB4MjANClsgIDM4NC4yOTM4ODZdICBbPGZmZmZmZmZmODEwMDEzYWE+
XSA/IHhlbl9oeXBlcmNhbGxfc2NoZWRfb3ArMHhhLzB4MjANClsgIDM4NC4yOTM4OTNdICBb
PGZmZmZmZmZmODEwMDg2OTA+XSA/IHhlbl9zYWZlX2hhbHQrMHgxMC8weDIwDQpbICAzODQu
MjkzOTAwXSAgWzxmZmZmZmZmZjgxMDE2MGQwPl0gPyBkZWZhdWx0X2lkbGUrMHg0MC8weDkw
DQpbICAzODQuMjkzOTA1XSAgWzxmZmZmZmZmZjgxMDE2NDg2Pl0gPyBjcHVfaWRsZSsweDk2
LzB4ZjANClsgIDM4NC4yOTM5MTFdICBbPGZmZmZmZmZmODE3MjJkM2M+XSA/IHJlc3RfaW5p
dCsweGJjLzB4ZDANClsgIDM4NC4yOTM5MTZdICBbPGZmZmZmZmZmODE3MjJjODA+XSA/IGNz
dW1fcGFydGlhbF9jb3B5X2dlbmVyaWMrMHgxNzAvMHgxNzANClsgIDM4NC4yOTM5MjVdICBb
PGZmZmZmZmZmODFjZTBkZjI+XSA/IHN0YXJ0X2tlcm5lbCsweDM5MC8weDM5ZA0KWyAgMzg0
LjI5MzkzMl0gIFs8ZmZmZmZmZmY4MWNlMDg4Mj5dID8ga2VybmVsX2luaXQrMHgyMGIvMHgy
MGINClsgIDM4NC4yOTM5MzhdICBbPGZmZmZmZmZmODFjZTAzNTY+XSA/IHg4Nl82NF9zdGFy
dF9yZXNlcnZhdGlvbnMrMHgxMzEvMHgxMzYNClsgIDM4NC4yOTM5NDVdICBbPGZmZmZmZmZm
ODFjZTNkNjA+XSA/IHhlbl9zdGFydF9rZXJuZWwrMHg3MGQvMHg3MGYNClsgIDM4NC4yOTM5
NTBdIC0tLVsgZW5kIHRyYWNlIDJlMjhlZWM5M2I3YThiYTAgXS0tLQ0KWyAgMzk5LjQ2Njc3
M10gLS0tLS0tLS0tLS0tWyBjdXQgaGVyZSBdLS0tLS0tLS0tLS0tDQpbICAzOTkuNDY2Nzkx
XSBXQVJOSU5HOiBhdCBkcml2ZXJzL25ldC94ZW4tbmV0ZnJvbnQuYzo0NjUgeGVubmV0X3N0
YXJ0X3htaXQrMHg3ZmUvMHg4NjAoKQ0KWyAgMzk5LjQ2Njc5OF0gTW9kdWxlcyBsaW5rZWQg
aW46DQpbICAzOTkuNDY2ODA0XSBQaWQ6IDAsIGNvbW06IHN3YXBwZXIvMCBUYWludGVkOiBH
ICAgICAgICBXICAgIDMuNi4wcHJlLXJjMS0yMDEyMTAxMSAjMQ0KWyAgMzk5LjQ2NjgwOV0g
Q2FsbCBUcmFjZToNClsgIDM5OS40NjY4MTNdICA8SVJRPiAgWzxmZmZmZmZmZjgxMDY2NGVh
Pl0gd2Fybl9zbG93cGF0aF9jb21tb24rMHg3YS8weGIwDQpbICAzOTkuNDY2ODI0XSAgWzxm
ZmZmZmZmZjgxMDY2NTM1Pl0gd2Fybl9zbG93cGF0aF9udWxsKzB4MTUvMHgyMA0KWyAgMzk5
LjQ2NjgzMF0gIFs8ZmZmZmZmZmY4MTQ2ZDg5ZT5dIHhlbm5ldF9zdGFydF94bWl0KzB4N2Zl
LzB4ODYwDQpbICAzOTkuNDY2ODM3XSAgWzxmZmZmZmZmZjgxNjFmMzQ5Pl0gZGV2X2hhcmRf
c3RhcnRfeG1pdCsweDIwOS8weDQ2MA0KWyAgMzk5LjQ2Njg0M10gIFs8ZmZmZmZmZmY4MTYz
YjAzNj5dIHNjaF9kaXJlY3RfeG1pdCsweGY2LzB4MjkwDQpbICAzOTkuNDY2ODQ4XSAgWzxm
ZmZmZmZmZjgxNjFmNzQ2Pl0gZGV2X3F1ZXVlX3htaXQrMHgxYTYvMHg1YTANClsgIDM5OS40
NjY4NTNdICBbPGZmZmZmZmZmODE2MWY1YTA+XSA/IGRldl9oYXJkX3N0YXJ0X3htaXQrMHg0
NjAvMHg0NjANClsgIDM5OS40NjY4NTldICBbPGZmZmZmZmZmODE2MjlhNzc+XSBuZWlnaF9y
ZXNvbHZlX291dHB1dCsweDEyNy8weDI1MA0KWyAgMzk5LjQ2Njg2NV0gIFs8ZmZmZmZmZmY4
MTZiOTZhZD5dIGlwX2ZpbmlzaF9vdXRwdXQrMHgzOWQvMHg1MzANClsgIDM5OS40NjY4NzFd
ICBbPGZmZmZmZmZmODE2YjkzZGQ+XSA/IGlwX2ZpbmlzaF9vdXRwdXQrMHhjZC8weDUzMA0K
WyAgMzk5LjQ2Njg3Nl0gIFs8ZmZmZmZmZmY4MTZiOTg5OT5dIGlwX291dHB1dCsweDU5LzB4
ZTANClsgIDM5OS40NjY4ODFdICBbPGZmZmZmZmZmODE2YjgzYjg+XSBpcF9sb2NhbF9vdXQr
MHgyOC8weDkwDQpbICAzOTkuNDY2ODg2XSAgWzxmZmZmZmZmZjgxNmI4OTZmPl0gaXBfcXVl
dWVfeG1pdCsweDE3Zi8weDRhMA0KWyAgMzk5LjQ2Njg5MV0gIFs8ZmZmZmZmZmY4MTZiODdm
MD5dID8gaXBfc2VuZF91bmljYXN0X3JlcGx5KzB4MzQwLzB4MzQwDQpbICAzOTkuNDY2ODk2
XSAgWzxmZmZmZmZmZjgxMGEwYmE3Pl0gPyBnZXRuc3RpbWVvZmRheSsweDQ3LzB4ZTANClsg
IDM5OS40NjY5MDNdICBbPGZmZmZmZmZmODE2MGY0Yzk+XSA/IF9fc2tiX2Nsb25lKzB4Mjkv
MHgxMjANClsgIDM5OS40NjY5MDldICBbPGZmZmZmZmZmODE2Y2VhMjA+XSB0Y3BfdHJhbnNt
aXRfc2tiKzB4NDAwLzB4OGQwDQpbICAzOTkuNDY2OTE0XSAgWzxmZmZmZmZmZjgxNmQxMTA2
Pl0gdGNwX3JldHJhbnNtaXRfc2tiKzB4MWM2LzB4NWEwDQpbICAzOTkuNDY2OTE5XSAgWzxm
ZmZmZmZmZjgxNmQzM2IwPl0gPyB0Y3Bfd3JpdGVfdGltZXJfaGFuZGxlcisweDFhMC8weDFh
MA0KWyAgMzk5LjQ2NjkyNV0gIFs8ZmZmZmZmZmY4MTZkMmYzOD5dIHRjcF9yZXRyYW5zbWl0
X3RpbWVyKzB4MzU4LzB4NjMwDQpbICAzOTkuNDY2OTMwXSAgWzxmZmZmZmZmZjgxNmQzMzRk
Pl0gdGNwX3dyaXRlX3RpbWVyX2hhbmRsZXIrMHgxM2QvMHgxYTANClsgIDM5OS40NjY5MzVd
ICBbPGZmZmZmZmZmODE2ZDM0Mjg+XSB0Y3Bfd3JpdGVfdGltZXIrMHg3OC8weDgwDQpbICAz
OTkuNDY2OTQwXSAgWzxmZmZmZmZmZjgxMDczZjdjPl0gY2FsbF90aW1lcl9mbisweDdjLzB4
MTAwDQpbICAzOTkuNDY2OTQ1XSAgWzxmZmZmZmZmZjgxMDczZjAwPl0gPyBjYXNjYWRlKzB4
YTAvMHhhMA0KWyAgMzk5LjQ2Njk0OV0gIFs8ZmZmZmZmZmY4MTZkMzNiMD5dID8gdGNwX3dy
aXRlX3RpbWVyX2hhbmRsZXIrMHgxYTAvMHgxYTANClsgIDM5OS40NjY5NTVdICBbPGZmZmZm
ZmZmODE2ZDMzYjA+XSA/IHRjcF93cml0ZV90aW1lcl9oYW5kbGVyKzB4MWEwLzB4MWEwDQpb
ICAzOTkuNDY2OTYwXSAgWzxmZmZmZmZmZjgxMDc0MjE3Pl0gcnVuX3RpbWVyX3NvZnRpcnEr
MHgyMTcvMHgyNTANClsgIDM5OS40NjY5NjZdICBbPGZmZmZmZmZmODEwNmUzZDk+XSBfX2Rv
X3NvZnRpcnErMHhjOS8weDFhMA0KWyAgMzk5LjQ2Njk3Ml0gIFs8ZmZmZmZmZmY4MTc0OGQz
Yz5dIGNhbGxfc29mdGlycSsweDFjLzB4MzANClsgIDM5OS40NjY5NzddICBbPGZmZmZmZmZm
ODEwMGVkYjU+XSBkb19zb2Z0aXJxKzB4ODUvMHhmMA0KWyAgMzk5LjQ2Njk4Ml0gIFs8ZmZm
ZmZmZmY4MTA2ZTI0ZT5dIGlycV9leGl0KzB4OWUvMHhkMA0KWyAgMzk5LjQ2Njk4OV0gIFs8
ZmZmZmZmZmY4MTMzOWY1Zj5dIHhlbl9ldnRjaG5fZG9fdXBjYWxsKzB4MmYvMHg0MA0KWyAg
Mzk5LjQ2Njk5NF0gIFs8ZmZmZmZmZmY4MTc0OGQ5ZT5dIHhlbl9kb19oeXBlcnZpc29yX2Nh
bGxiYWNrKzB4MWUvMHgzMA0KWyAgMzk5LjQ2Njk5OF0gIDxFT0k+ICBbPGZmZmZmZmZmODEw
MDEzYWE+XSA/IHhlbl9oeXBlcmNhbGxfc2NoZWRfb3ArMHhhLzB4MjANClsgIDM5OS40Njcw
MDhdICBbPGZmZmZmZmZmODEwMDEzYWE+XSA/IHhlbl9oeXBlcmNhbGxfc2NoZWRfb3ArMHhh
LzB4MjANClsgIDM5OS40NjcwMTNdICBbPGZmZmZmZmZmODEwMDg2OTA+XSA/IHhlbl9zYWZl
X2hhbHQrMHgxMC8weDIwDQpbICAzOTkuNDY3MDE5XSAgWzxmZmZmZmZmZjgxMDE2MGQwPl0g
PyBkZWZhdWx0X2lkbGUrMHg0MC8weDkwDQpbICAzOTkuNDY3MDI0XSAgWzxmZmZmZmZmZjgx
MDE2NDg2Pl0gPyBjcHVfaWRsZSsweDk2LzB4ZjANClsgIDM5OS40NjcwMjhdICBbPGZmZmZm
ZmZmODE3MjJkM2M+XSA/IHJlc3RfaW5pdCsweGJjLzB4ZDANClsgIDM5OS40NjcwMzNdICBb
PGZmZmZmZmZmODE3MjJjODA+XSA/IGNzdW1fcGFydGlhbF9jb3B5X2dlbmVyaWMrMHgxNzAv
MHgxNzANClsgIDM5OS40NjcwNDBdICBbPGZmZmZmZmZmODFjZTBkZjI+XSA/IHN0YXJ0X2tl
cm5lbCsweDM5MC8weDM5ZA0KWyAgMzk5LjQ2NzA0NV0gIFs8ZmZmZmZmZmY4MWNlMDg4Mj5d
ID8ga2VybmVsX2luaXQrMHgyMGIvMHgyMGINClsgIDM5OS40NjcwNTBdICBbPGZmZmZmZmZm
ODFjZTAzNTY+XSA/IHg4Nl82NF9zdGFydF9yZXNlcnZhdGlvbnMrMHgxMzEvMHgxMzYNClsg
IDM5OS40NjcwNTVdICBbPGZmZmZmZmZmODFjZTNkNjA+XSA/IHhlbl9zdGFydF9rZXJuZWwr
MHg3MGQvMHg3MGYNClsgIDM5OS40NjcwNjBdIC0tLVsgZW5kIHRyYWNlIDJlMjhlZWM5M2I3
YThiYTEgXS0tLQ0KWyAgNDI5LjgxMzQ0MF0gLS0tLS0tLS0tLS0tWyBjdXQgaGVyZSBdLS0t
LS0tLS0tLS0tDQpbICA0MjkuODEzNDc3XSBXQVJOSU5HOiBhdCBkcml2ZXJzL25ldC94ZW4t
bmV0ZnJvbnQuYzo0NjUgeGVubmV0X3N0YXJ0X3htaXQrMHg3ZmUvMHg4NjAoKQ0KWyAgNDI5
LjgxMzQ4NF0gTW9kdWxlcyBsaW5rZWQgaW46DQpbICA0MjkuODEzNDkxXSBQaWQ6IDAsIGNv
bW06IHN3YXBwZXIvMCBUYWludGVkOiBHICAgICAgICBXICAgIDMuNi4wcHJlLXJjMS0yMDEy
MTAxMSAjMQ0KWyAgNDI5LjgxMzQ5N10gQ2FsbCBUcmFjZToNClsgIDQyOS44MTM1MDFdICA8
SVJRPiAgWzxmZmZmZmZmZjgxMDY2NGVhPl0gd2Fybl9zbG93cGF0aF9jb21tb24rMHg3YS8w
eGIwDQpbICA0MjkuODEzNTEzXSAgWzxmZmZmZmZmZjgxMDY2NTM1Pl0gd2Fybl9zbG93cGF0
aF9udWxsKzB4MTUvMHgyMA0KWyAgNDI5LjgxMzUxOV0gIFs8ZmZmZmZmZmY4MTQ2ZDg5ZT5d
IHhlbm5ldF9zdGFydF94bWl0KzB4N2ZlLzB4ODYwDQpbICA0MjkuODEzNTI3XSAgWzxmZmZm
ZmZmZjgxNjFmMzQ5Pl0gZGV2X2hhcmRfc3RhcnRfeG1pdCsweDIwOS8weDQ2MA0KWyAgNDI5
LjgxMzUzNF0gIFs8ZmZmZmZmZmY4MTYzYjAzNj5dIHNjaF9kaXJlY3RfeG1pdCsweGY2LzB4
MjkwDQpbICA0MjkuODEzNTM5XSAgWzxmZmZmZmZmZjgxNjFmNzQ2Pl0gZGV2X3F1ZXVlX3ht
aXQrMHgxYTYvMHg1YTANClsgIDQyOS44MTM1NDVdICBbPGZmZmZmZmZmODE2MWY1YTA+XSA/
IGRldl9oYXJkX3N0YXJ0X3htaXQrMHg0NjAvMHg0NjANClsgIDQyOS44MTM1NTJdICBbPGZm
ZmZmZmZmODEwYjE0MTc+XSA/IGxvY2tfcmVsZWFzZSsweDExNy8weDI1MA0KWyAgNDI5Ljgx
MzU1OV0gIFs8ZmZmZmZmZmY4MTZiOTUzNj5dIGlwX2ZpbmlzaF9vdXRwdXQrMHgyMjYvMHg1
MzANClsgIDQyOS44MTM1NjVdICBbPGZmZmZmZmZmODE2YjkzZGQ+XSA/IGlwX2ZpbmlzaF9v
dXRwdXQrMHhjZC8weDUzMA0KWyAgNDI5LjgxMzU3MV0gIFs8ZmZmZmZmZmY4MTZiOTg5OT5d
IGlwX291dHB1dCsweDU5LzB4ZTANClsgIDQyOS44MTM1NzZdICBbPGZmZmZmZmZmODE2Yjgz
Yjg+XSBpcF9sb2NhbF9vdXQrMHgyOC8weDkwDQpbICA0MjkuODEzNTgyXSAgWzxmZmZmZmZm
ZjgxNmI4OTZmPl0gaXBfcXVldWVfeG1pdCsweDE3Zi8weDRhMA0KWyAgNDI5LjgxMzU4OF0g
IFs8ZmZmZmZmZmY4MTZiODdmMD5dID8gaXBfc2VuZF91bmljYXN0X3JlcGx5KzB4MzQwLzB4
MzQwDQpbICA0MjkuODEzNTk0XSAgWzxmZmZmZmZmZjgxMGEwYmE3Pl0gPyBnZXRuc3RpbWVv
ZmRheSsweDQ3LzB4ZTANClsgIDQyOS44MTM2MDBdICBbPGZmZmZmZmZmODE2MGY0Yzk+XSA/
IF9fc2tiX2Nsb25lKzB4MjkvMHgxMjANClsgIDQyOS44MTM2MDZdICBbPGZmZmZmZmZmODE2
Y2VhMjA+XSB0Y3BfdHJhbnNtaXRfc2tiKzB4NDAwLzB4OGQwDQpbICA0MjkuODEzNjE0XSAg
WzxmZmZmZmZmZjgxNmQxMTA2Pl0gdGNwX3JldHJhbnNtaXRfc2tiKzB4MWM2LzB4NWEwDQpb
ICA0MjkuODEzNjIzXSAgWzxmZmZmZmZmZjgxNmQzM2IwPl0gPyB0Y3Bfd3JpdGVfdGltZXJf
aGFuZGxlcisweDFhMC8weDFhMA0KWyAgNDI5LjgxMzYzMV0gIFs8ZmZmZmZmZmY4MTZkMmYz
OD5dIHRjcF9yZXRyYW5zbWl0X3RpbWVyKzB4MzU4LzB4NjMwDQpbICA0MjkuODEzNjM3XSAg
WzxmZmZmZmZmZjgxNmQzMzRkPl0gdGNwX3dyaXRlX3RpbWVyX2hhbmRsZXIrMHgxM2QvMHgx
YTANClsgIDQyOS44MTM2NDNdICBbPGZmZmZmZmZmODE2ZDM0Mjg+XSB0Y3Bfd3JpdGVfdGlt
ZXIrMHg3OC8weDgwDQpbICA0MjkuODEzNjQ5XSAgWzxmZmZmZmZmZjgxMDczZjdjPl0gY2Fs
bF90aW1lcl9mbisweDdjLzB4MTAwDQpbICA0MjkuODEzNjU0XSAgWzxmZmZmZmZmZjgxMDcz
ZjAwPl0gPyBjYXNjYWRlKzB4YTAvMHhhMA0KWyAgNDI5LjgxMzY1OV0gIFs8ZmZmZmZmZmY4
MTZkMzNiMD5dID8gdGNwX3dyaXRlX3RpbWVyX2hhbmRsZXIrMHgxYTAvMHgxYTANClsgIDQy
OS44MTM2NjVdICBbPGZmZmZmZmZmODE2ZDMzYjA+XSA/IHRjcF93cml0ZV90aW1lcl9oYW5k
bGVyKzB4MWEwLzB4MWEwDQpbICA0MjkuODEzNzI4XSAgWzxmZmZmZmZmZjgxMDc0MjE3Pl0g
cnVuX3RpbWVyX3NvZnRpcnErMHgyMTcvMHgyNTANClsgIDQyOS44MTM3MzVdICBbPGZmZmZm
ZmZmODEwNmUzZDk+XSBfX2RvX3NvZnRpcnErMHhjOS8weDFhMA0KWyAgNDI5LjgxMzc0Ml0g
IFs8ZmZmZmZmZmY4MTc0OGQzYz5dIGNhbGxfc29mdGlycSsweDFjLzB4MzANClsgIDQyOS44
MTM3NDldICBbPGZmZmZmZmZmODEwMGVkYjU+XSBkb19zb2Z0aXJxKzB4ODUvMHhmMA0KWyAg
NDI5LjgxMzc1NF0gIFs8ZmZmZmZmZmY4MTA2ZTI0ZT5dIGlycV9leGl0KzB4OWUvMHhkMA0K
WyAgNDI5LjgxMzc2Ml0gIFs8ZmZmZmZmZmY4MTMzOWY1Zj5dIHhlbl9ldnRjaG5fZG9fdXBj
YWxsKzB4MmYvMHg0MA0KWyAgNDI5LjgxMzc2N10gIFs8ZmZmZmZmZmY4MTc0OGQ5ZT5dIHhl
bl9kb19oeXBlcnZpc29yX2NhbGxiYWNrKzB4MWUvMHgzMA0KWyAgNDI5LjgxMzc3Ml0gIDxF
T0k+ICBbPGZmZmZmZmZmODEwMDEzYWE+XSA/IHhlbl9oeXBlcmNhbGxfc2NoZWRfb3ArMHhh
LzB4MjANClsgIDQyOS44MTM3ODNdICBbPGZmZmZmZmZmODEwMDEzYWE+XSA/IHhlbl9oeXBl
cmNhbGxfc2NoZWRfb3ArMHhhLzB4MjANClsgIDQyOS44MTM3ODldICBbPGZmZmZmZmZmODEw
MDg2OTA+XSA/IHhlbl9zYWZlX2hhbHQrMHgxMC8weDIwDQpbICA0MjkuODEzNzk1XSAgWzxm
ZmZmZmZmZjgxMDE2MGQwPl0gPyBkZWZhdWx0X2lkbGUrMHg0MC8weDkwDQpbICA0MjkuODEz
ODAxXSAgWzxmZmZmZmZmZjgxMDE2NDg2Pl0gPyBjcHVfaWRsZSsweDk2LzB4ZjANClsgIDQy
OS44MTM4MDddICBbPGZmZmZmZmZmODE3MjJkM2M+XSA/IHJlc3RfaW5pdCsweGJjLzB4ZDAN
ClsgIDQyOS44MTM4MTNdICBbPGZmZmZmZmZmODE3MjJjODA+XSA/IGNzdW1fcGFydGlhbF9j
b3B5X2dlbmVyaWMrMHgxNzAvMHgxNzANClsgIDQyOS44MTM4MjFdICBbPGZmZmZmZmZmODFj
ZTBkZjI+XSA/IHN0YXJ0X2tlcm5lbCsweDM5MC8weDM5ZA0KWyAgNDI5LjgxMzgyN10gIFs8
ZmZmZmZmZmY4MWNlMDg4Mj5dID8ga2VybmVsX2luaXQrMHgyMGIvMHgyMGINClsgIDQyOS44
MTM4MzNdICBbPGZmZmZmZmZmODFjZTAzNTY+XSA/IHg4Nl82NF9zdGFydF9yZXNlcnZhdGlv
bnMrMHgxMzEvMHgxMzYNClsgIDQyOS44MTM4MzldICBbPGZmZmZmZmZmODFjZTNkNjA+XSA/
IHhlbl9zdGFydF9rZXJuZWwrMHg3MGQvMHg3MGYNClsgIDQyOS44MTM4NDVdIC0tLVsgZW5k
IHRyYWNlIDJlMjhlZWM5M2I3YThiYTIgXS0tLQ0K
------------002085244038F36F8
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

------------002085244038F36F8--



From xen-devel-bounces@lists.xen.org Thu Oct 11 10:05:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 10:05:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMFe2-0006g9-Kl; Thu, 11 Oct 2012 10:05:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMFe1-0006g2-0c
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 10:05:33 +0000
Received: from [85.158.143.35:20053] by server-1.bemta-4.messagelabs.com id
	8B/9E-19551-CE996705; Thu, 11 Oct 2012 10:05:32 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1349949926!14586334!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7536 invoked from network); 11 Oct 2012 10:05:27 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Oct 2012 10:05:27 -0000
Received: by mail-bk0-f45.google.com with SMTP id jf3so804967bkc.32
	for ; Thu, 11 Oct 2012 03:05:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:from:to:cc:in-reply-to:references:content-type:date
	:message-id:mime-version:x-mailer:content-transfer-encoding;
	bh=gP4pnONVtickog3/KdgGBB4slbUS5WF0REQmRpECt6g=;
	b=LdB/ju1qGy12xqjnYjEBr/6soG+pzl7fJME5/OcNzB6E0LBiUqamHvZSK+1ne37K9d
	ohA2oSOwl+xXedfRJgOkmf7bHgDPondTbSAN735zkZUurnFqGvS/gWRDiu3hU3PAaMJo
	6lJhXZgabI8Yp43c0wGsh3GUmf08XDLVi77+W69M13+m5zrwHN3PgLKGxEmkMMzkvFvm
	En+/x+xmW73wkEDklpQTP4BvZCvHjqNxgJmJjpyzCt33KjjzWysqKudED/59AhA1E+vC
	l+4D9ZhWg8XzEU976GGtZIFFO/UjhxEyy0Z3rDvVj3Y12imQUg8j56vgQkAmVaRK7o+q
	Fgyw==
Received: by 10.204.9.130 with SMTP id l2mr113795bkl.56.1349949926715;
	Thu, 11 Oct 2012 03:05:26 -0700 (PDT)
Received: from [172.28.90.114] ([172.28.90.114])
	by mx.google.com with ESMTPS id e13sm3083316bkw.12.2012.10.11.03.05.24
	(version=SSLv3 cipher=OTHER); Thu, 11 Oct 2012 03:05:25 -0700 (PDT)
From: Eric Dumazet 
To: Sander Eikelenboom 
In-Reply-To: <151954917.20121011120004@eikelenboom.it>
References: <1349790467.21847.185.camel@zakaz.uk.xensource.com>
	<1349790863.21172.4406.camel@edumazet-glaptop>
	<1349792241.21847.199.camel@zakaz.uk.xensource.com>
	<1349792847.21172.4479.camel@edumazet-glaptop>
	<1349793630.21847.208.camel@zakaz.uk.xensource.com>
	<1349863984.10070.26.camel@zakaz.uk.xensource.com>
	<1349874598.10070.39.camel@zakaz.uk.xensource.com>
	<748966751.20121010164949@eikelenboom.it>
	<1349942546.14806.7.camel@zakaz.uk.xensource.com>
	<151954917.20121011120004@eikelenboom.it>
Date: Thu, 11 Oct 2012 12:05:24 +0200
Message-ID: <1349949924.21172.8462.camel@edumazet-glaptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: Konrad Rzeszutek Wilk ,
	Eric Dumazet ,
	"netdev@vger.kernel.org" ,
	Ian Campbell , xen-devel 
Subject: Re: [Xen-devel] compound skb frag pages appearing in start_xmit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-11 at 12:00 +0200, Sander Eikelenboom wrote:

> Probably due to the BUG_ON from the patch below, i changed it into a WARN_ON.
> And i seem to hit it, but only in one of the guests at the moment and it triggers quite irregularly.

xennet_make_frags() is able to split the skb->head in multiple page-size
chunks.

It should do the same for fragments



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 10:05:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 10:05:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMFe2-0006g9-Kl; Thu, 11 Oct 2012 10:05:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMFe1-0006g2-0c
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 10:05:33 +0000
Received: from [85.158.143.35:20053] by server-1.bemta-4.messagelabs.com id
	8B/9E-19551-CE996705; Thu, 11 Oct 2012 10:05:32 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1349949926!14586334!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7536 invoked from network); 11 Oct 2012 10:05:27 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Oct 2012 10:05:27 -0000
Received: by mail-bk0-f45.google.com with SMTP id jf3so804967bkc.32
	for ; Thu, 11 Oct 2012 03:05:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:from:to:cc:in-reply-to:references:content-type:date
	:message-id:mime-version:x-mailer:content-transfer-encoding;
	bh=gP4pnONVtickog3/KdgGBB4slbUS5WF0REQmRpECt6g=;
	b=LdB/ju1qGy12xqjnYjEBr/6soG+pzl7fJME5/OcNzB6E0LBiUqamHvZSK+1ne37K9d
	ohA2oSOwl+xXedfRJgOkmf7bHgDPondTbSAN735zkZUurnFqGvS/gWRDiu3hU3PAaMJo
	6lJhXZgabI8Yp43c0wGsh3GUmf08XDLVi77+W69M13+m5zrwHN3PgLKGxEmkMMzkvFvm
	En+/x+xmW73wkEDklpQTP4BvZCvHjqNxgJmJjpyzCt33KjjzWysqKudED/59AhA1E+vC
	l+4D9ZhWg8XzEU976GGtZIFFO/UjhxEyy0Z3rDvVj3Y12imQUg8j56vgQkAmVaRK7o+q
	Fgyw==
Received: by 10.204.9.130 with SMTP id l2mr113795bkl.56.1349949926715;
	Thu, 11 Oct 2012 03:05:26 -0700 (PDT)
Received: from [172.28.90.114] ([172.28.90.114])
	by mx.google.com with ESMTPS id e13sm3083316bkw.12.2012.10.11.03.05.24
	(version=SSLv3 cipher=OTHER); Thu, 11 Oct 2012 03:05:25 -0700 (PDT)
From: Eric Dumazet 
To: Sander Eikelenboom 
In-Reply-To: <151954917.20121011120004@eikelenboom.it>
References: <1349790467.21847.185.camel@zakaz.uk.xensource.com>
	<1349790863.21172.4406.camel@edumazet-glaptop>
	<1349792241.21847.199.camel@zakaz.uk.xensource.com>
	<1349792847.21172.4479.camel@edumazet-glaptop>
	<1349793630.21847.208.camel@zakaz.uk.xensource.com>
	<1349863984.10070.26.camel@zakaz.uk.xensource.com>
	<1349874598.10070.39.camel@zakaz.uk.xensource.com>
	<748966751.20121010164949@eikelenboom.it>
	<1349942546.14806.7.camel@zakaz.uk.xensource.com>
	<151954917.20121011120004@eikelenboom.it>
Date: Thu, 11 Oct 2012 12:05:24 +0200
Message-ID: <1349949924.21172.8462.camel@edumazet-glaptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: Konrad Rzeszutek Wilk ,
	Eric Dumazet ,
	"netdev@vger.kernel.org" ,
	Ian Campbell , xen-devel 
Subject: Re: [Xen-devel] compound skb frag pages appearing in start_xmit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-11 at 12:00 +0200, Sander Eikelenboom wrote:

> Probably due to the BUG_ON from the patch below, i changed it into a WARN_ON.
> And i seem to hit it, but only in one of the guests at the moment and it triggers quite irregularly.

xennet_make_frags() is able to split the skb->head in multiple page-size
chunks.

It should do the same for fragments



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 10:15:44 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 10:15:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMFnX-0006sq-OK; Thu, 11 Oct 2012 10:15:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMFnV-0006sl-Ms
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 10:15:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1349950514!892884!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM5ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7456 invoked from network); 11 Oct 2012 10:15:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Oct 2012 10:15:15 -0000
X-IronPort-AV: E=Sophos;i="4.80,571,1344211200"; d="scan'208";a="15094932"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Oct 2012 10:14:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 11 Oct 2012 11:14:56 +0100
Message-ID: <1349950494.14806.29.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Eric Dumazet 
Date: Thu, 11 Oct 2012 11:14:54 +0100
In-Reply-To: <1349949924.21172.8462.camel@edumazet-glaptop>
References: <1349790467.21847.185.camel@zakaz.uk.xensource.com>
	<1349790863.21172.4406.camel@edumazet-glaptop>
	<1349792241.21847.199.camel@zakaz.uk.xensource.com>
	<1349792847.21172.4479.camel@edumazet-glaptop>
	<1349793630.21847.208.camel@zakaz.uk.xensource.com>
	<1349863984.10070.26.camel@zakaz.uk.xensource.com>
	<1349874598.10070.39.camel@zakaz.uk.xensource.com>
	<748966751.20121010164949@eikelenboom.it>
	<1349942546.14806.7.camel@zakaz.uk.xensource.com>
	<151954917.20121011120004@eikelenboom.it>
	<1349949924.21172.8462.camel@edumazet-glaptop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Sander Eikelenboom ,
	Eric Dumazet ,
	"netdev@vger.kernel.org" ,
	Konrad Rzeszutek Wilk ,
	xen-devel 
Subject: Re: [Xen-devel] compound skb frag pages appearing in start_xmit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-11 at 11:05 +0100, Eric Dumazet wrote:
> On Thu, 2012-10-11 at 12:00 +0200, Sander Eikelenboom wrote:
> 
> > Probably due to the BUG_ON from the patch below, i changed it into a WARN_ON.
> > And i seem to hit it, but only in one of the guests at the moment and it triggers quite irregularly.
> 
> xennet_make_frags() is able to split the skb->head in multiple page-size
> chunks.
> 
> It should do the same for fragments

Right, I just want to be reproduce the issue so I can know I've fixed it
properly ;-)

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 10:15:44 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 10:15:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMFnX-0006sq-OK; Thu, 11 Oct 2012 10:15:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMFnV-0006sl-Ms
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 10:15:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1349950514!892884!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM5ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7456 invoked from network); 11 Oct 2012 10:15:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Oct 2012 10:15:15 -0000
X-IronPort-AV: E=Sophos;i="4.80,571,1344211200"; d="scan'208";a="15094932"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Oct 2012 10:14:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 11 Oct 2012 11:14:56 +0100
Message-ID: <1349950494.14806.29.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Eric Dumazet 
Date: Thu, 11 Oct 2012 11:14:54 +0100
In-Reply-To: <1349949924.21172.8462.camel@edumazet-glaptop>
References: <1349790467.21847.185.camel@zakaz.uk.xensource.com>
	<1349790863.21172.4406.camel@edumazet-glaptop>
	<1349792241.21847.199.camel@zakaz.uk.xensource.com>
	<1349792847.21172.4479.camel@edumazet-glaptop>
	<1349793630.21847.208.camel@zakaz.uk.xensource.com>
	<1349863984.10070.26.camel@zakaz.uk.xensource.com>
	<1349874598.10070.39.camel@zakaz.uk.xensource.com>
	<748966751.20121010164949@eikelenboom.it>
	<1349942546.14806.7.camel@zakaz.uk.xensource.com>
	<151954917.20121011120004@eikelenboom.it>
	<1349949924.21172.8462.camel@edumazet-glaptop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Sander Eikelenboom ,
	Eric Dumazet ,
	"netdev@vger.kernel.org" ,
	Konrad Rzeszutek Wilk ,
	xen-devel 
Subject: Re: [Xen-devel] compound skb frag pages appearing in start_xmit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-11 at 11:05 +0100, Eric Dumazet wrote:
> On Thu, 2012-10-11 at 12:00 +0200, Sander Eikelenboom wrote:
> 
> > Probably due to the BUG_ON from the patch below, i changed it into a WARN_ON.
> > And i seem to hit it, but only in one of the guests at the moment and it triggers quite irregularly.
> 
> xennet_make_frags() is able to split the skb->head in multiple page-size
> chunks.
> 
> It should do the same for fragments

Right, I just want to be reproduce the issue so I can know I've fixed it
properly ;-)

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 10:20:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 10:20:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMFsE-000710-Dy; Thu, 11 Oct 2012 10:20:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMFsD-00070u-Hv
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 10:20:13 +0000
Received: from [85.158.139.83:11529] by server-8.bemta-5.messagelabs.com id
	F1/04-23193-C5D96705; Thu, 11 Oct 2012 10:20:12 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-7.tower-182.messagelabs.com!1349950811!30435909!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4277 invoked from network); 11 Oct 2012 10:20:11 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-7.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	11 Oct 2012 10:20:11 -0000
Received: from 50-66-ftth.onsneteindhoven.nl ([88.159.66.50]:52063
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TMFtX-0001FB-CQ; Thu, 11 Oct 2012 12:21:35 +0200
Date: Thu, 11 Oct 2012 12:20:04 +0200
From: Sander Eikelenboom 
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <878987058.20121011122004@eikelenboom.it>
To: Ian Campbell 
In-Reply-To: <1349950494.14806.29.camel@zakaz.uk.xensource.com>
References: <1349790467.21847.185.camel@zakaz.uk.xensource.com>
	<1349790863.21172.4406.camel@edumazet-glaptop>
	<1349792241.21847.199.camel@zakaz.uk.xensource.com>
	<1349792847.21172.4479.camel@edumazet-glaptop>
	<1349793630.21847.208.camel@zakaz.uk.xensource.com>
	<1349863984.10070.26.camel@zakaz.uk.xensource.com>
	<1349874598.10070.39.camel@zakaz.uk.xensource.com>
	<748966751.20121010164949@eikelenboom.it>
	<1349942546.14806.7.camel@zakaz.uk.xensource.com>
	<151954917.20121011120004@eikelenboom.it>
	<1349949924.21172.8462.camel@edumazet-glaptop>
	<1349950494.14806.29.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk ,
	Eric Dumazet ,
	"netdev@vger.kernel.org" ,
	Eric Dumazet , xen-devel 
Subject: Re: [Xen-devel] compound skb frag pages appearing in start_xmit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Thursday, October 11, 2012, 12:14:54 PM, you wrote:

> On Thu, 2012-10-11 at 11:05 +0100, Eric Dumazet wrote:
>> On Thu, 2012-10-11 at 12:00 +0200, Sander Eikelenboom wrote:
>> 
>> > Probably due to the BUG_ON from the patch below, i changed it into a WARN_ON.
>> > And i seem to hit it, but only in one of the guests at the moment and it triggers quite irregularly.
>> 
>> xennet_make_frags() is able to split the skb->head in multiple page-size
>> chunks.
>> 
>> It should do the same for fragments

> Right, I just want to be reproduce the issue so I can know I've fixed it
> properly ;-)

Trying to scp/sftp files from a guest seems to trigger it for me ..

> Ian.






_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 10:20:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 10:20:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMFsE-000710-Dy; Thu, 11 Oct 2012 10:20:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMFsD-00070u-Hv
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 10:20:13 +0000
Received: from [85.158.139.83:11529] by server-8.bemta-5.messagelabs.com id
	F1/04-23193-C5D96705; Thu, 11 Oct 2012 10:20:12 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-7.tower-182.messagelabs.com!1349950811!30435909!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4277 invoked from network); 11 Oct 2012 10:20:11 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-7.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	11 Oct 2012 10:20:11 -0000
Received: from 50-66-ftth.onsneteindhoven.nl ([88.159.66.50]:52063
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TMFtX-0001FB-CQ; Thu, 11 Oct 2012 12:21:35 +0200
Date: Thu, 11 Oct 2012 12:20:04 +0200
From: Sander Eikelenboom 
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <878987058.20121011122004@eikelenboom.it>
To: Ian Campbell 
In-Reply-To: <1349950494.14806.29.camel@zakaz.uk.xensource.com>
References: <1349790467.21847.185.camel@zakaz.uk.xensource.com>
	<1349790863.21172.4406.camel@edumazet-glaptop>
	<1349792241.21847.199.camel@zakaz.uk.xensource.com>
	<1349792847.21172.4479.camel@edumazet-glaptop>
	<1349793630.21847.208.camel@zakaz.uk.xensource.com>
	<1349863984.10070.26.camel@zakaz.uk.xensource.com>
	<1349874598.10070.39.camel@zakaz.uk.xensource.com>
	<748966751.20121010164949@eikelenboom.it>
	<1349942546.14806.7.camel@zakaz.uk.xensource.com>
	<151954917.20121011120004@eikelenboom.it>
	<1349949924.21172.8462.camel@edumazet-glaptop>
	<1349950494.14806.29.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk ,
	Eric Dumazet ,
	"netdev@vger.kernel.org" ,
	Eric Dumazet , xen-devel 
Subject: Re: [Xen-devel] compound skb frag pages appearing in start_xmit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Thursday, October 11, 2012, 12:14:54 PM, you wrote:

> On Thu, 2012-10-11 at 11:05 +0100, Eric Dumazet wrote:
>> On Thu, 2012-10-11 at 12:00 +0200, Sander Eikelenboom wrote:
>> 
>> > Probably due to the BUG_ON from the patch below, i changed it into a WARN_ON.
>> > And i seem to hit it, but only in one of the guests at the moment and it triggers quite irregularly.
>> 
>> xennet_make_frags() is able to split the skb->head in multiple page-size
>> chunks.
>> 
>> It should do the same for fragments

> Right, I just want to be reproduce the issue so I can know I've fixed it
> properly ;-)

Trying to scp/sftp files from a guest seems to trigger it for me ..

> Ian.






_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 10:25:48 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 10:25:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMFxM-0007AJ-61; Thu, 11 Oct 2012 10:25:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMFxL-0007AE-Ar
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 10:25:31 +0000
Received: from [85.158.139.211:49270] by server-16.bemta-5.messagelabs.com id
	7C/07-10155-A9E96705; Thu, 11 Oct 2012 10:25:30 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-8.tower-206.messagelabs.com!1349951129!21902681!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2966 invoked from network); 11 Oct 2012 10:25:29 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-8.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	11 Oct 2012 10:25:29 -0000
Received: from 50-66-ftth.onsneteindhoven.nl ([88.159.66.50]:54436
	helo=localhost.localdomain) by smtp.eikelenboom.it with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72)
	(envelope-from )
	id 1TMFyj-0001Hs-Jy; Thu, 11 Oct 2012 12:26:57 +0200
From: linux@eikelenboom.it
To: xen-devel@lists.xen.org
Date: Thu, 11 Oct 2012 12:25:20 +0200
Message-Id: <1349951120-1968-1-git-send-email-linux@eikelenboom.it>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1349945896.14806.25.camel@zakaz.uk.xensource.com>
References: <1349945896.14806.25.camel@zakaz.uk.xensource.com>
Cc: Sander Eikelenboom , Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH v2 3/3] xl/libxl: make shutdown accept the long
	option --wait for -w
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Sander Eikelenboom 

Make xl/libxl accept the long option --wait for -w to be compatible with xm.
The long options are used in the default init and sysconfig scripts.

Signed-off-by: Sander Eikelenboom 
---
 docs/man/xl.pod.1         |    2 +-
 tools/libxl/xl_cmdimpl.c  |    6 +++++-
 tools/libxl/xl_cmdtable.c |    2 +-
 3 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index 25ce777..dd387c9 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -550,7 +550,7 @@ B
 
 =over 4
 
-=item B<-w>
+=item B<-w>, B<--wait>
 
 Wait for the domain to complete shutdown before returning.
 
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 93066d3..389b5f7 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3709,8 +3709,12 @@ int main_shutdown(int argc, char **argv)
     int opt;
     int wait_for_it = 0;
     int fallback_trigger = 0;
+    static struct option long_options[] = {
+        {"wait", 0, 0, 'w'},
+        {0, 0, 0, 0}
+    };
 
-    while ((opt = def_getopt(argc, argv, "wF", "shutdown", 1)) != -1) {
+    while ((opt = getopt_long(argc, argv, "wF", long_options, NULL)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
diff --git a/tools/libxl/xl_cmdtable.c b/tools/libxl/xl_cmdtable.c
index 85ea768..b398c0a 100644
--- a/tools/libxl/xl_cmdtable.c
+++ b/tools/libxl/xl_cmdtable.c
@@ -64,7 +64,7 @@ struct cmd_spec cmd_table[] = {
       "-h                      Print this help.\n"
       "-F                      Fallback to ACPI power event for HVM guests with\n"
       "                        no PV drivers.\n"
-      "-w                      Wait for guest to shutdown.\n"
+      "-w, --wait              Wait for guest to shutdown.\n"
     },
     { "reboot",
       &main_reboot, 0, 1,
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 10:25:48 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 10:25:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMFxM-0007AJ-61; Thu, 11 Oct 2012 10:25:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMFxL-0007AE-Ar
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 10:25:31 +0000
Received: from [85.158.139.211:49270] by server-16.bemta-5.messagelabs.com id
	7C/07-10155-A9E96705; Thu, 11 Oct 2012 10:25:30 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-8.tower-206.messagelabs.com!1349951129!21902681!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2966 invoked from network); 11 Oct 2012 10:25:29 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-8.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	11 Oct 2012 10:25:29 -0000
Received: from 50-66-ftth.onsneteindhoven.nl ([88.159.66.50]:54436
	helo=localhost.localdomain) by smtp.eikelenboom.it with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72)
	(envelope-from )
	id 1TMFyj-0001Hs-Jy; Thu, 11 Oct 2012 12:26:57 +0200
From: linux@eikelenboom.it
To: xen-devel@lists.xen.org
Date: Thu, 11 Oct 2012 12:25:20 +0200
Message-Id: <1349951120-1968-1-git-send-email-linux@eikelenboom.it>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1349945896.14806.25.camel@zakaz.uk.xensource.com>
References: <1349945896.14806.25.camel@zakaz.uk.xensource.com>
Cc: Sander Eikelenboom , Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH v2 3/3] xl/libxl: make shutdown accept the long
	option --wait for -w
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Sander Eikelenboom 

Make xl/libxl accept the long option --wait for -w to be compatible with xm.
The long options are used in the default init and sysconfig scripts.

Signed-off-by: Sander Eikelenboom 
---
 docs/man/xl.pod.1         |    2 +-
 tools/libxl/xl_cmdimpl.c  |    6 +++++-
 tools/libxl/xl_cmdtable.c |    2 +-
 3 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index 25ce777..dd387c9 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -550,7 +550,7 @@ B
 
 =over 4
 
-=item B<-w>
+=item B<-w>, B<--wait>
 
 Wait for the domain to complete shutdown before returning.
 
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 93066d3..389b5f7 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3709,8 +3709,12 @@ int main_shutdown(int argc, char **argv)
     int opt;
     int wait_for_it = 0;
     int fallback_trigger = 0;
+    static struct option long_options[] = {
+        {"wait", 0, 0, 'w'},
+        {0, 0, 0, 0}
+    };
 
-    while ((opt = def_getopt(argc, argv, "wF", "shutdown", 1)) != -1) {
+    while ((opt = getopt_long(argc, argv, "wF", long_options, NULL)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
diff --git a/tools/libxl/xl_cmdtable.c b/tools/libxl/xl_cmdtable.c
index 85ea768..b398c0a 100644
--- a/tools/libxl/xl_cmdtable.c
+++ b/tools/libxl/xl_cmdtable.c
@@ -64,7 +64,7 @@ struct cmd_spec cmd_table[] = {
       "-h                      Print this help.\n"
       "-F                      Fallback to ACPI power event for HVM guests with\n"
       "                        no PV drivers.\n"
-      "-w                      Wait for guest to shutdown.\n"
+      "-w, --wait              Wait for guest to shutdown.\n"
     },
     { "reboot",
       &main_reboot, 0, 1,
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 10:52:51 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 10:52:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMGNV-0007Lv-In; Thu, 11 Oct 2012 10:52:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMGNT-0007Lq-PB
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 10:52:32 +0000
Received: from [85.158.139.83:38050] by server-5.bemta-5.messagelabs.com id
	2A/70-19238-FE4A6705; Thu, 11 Oct 2012 10:52:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1349952750!34380789!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM5ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8887 invoked from network); 11 Oct 2012 10:52:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Oct 2012 10:52:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,571,1344211200"; d="scan'208";a="15095834"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Oct 2012 10:52:30 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 11 Oct 2012 11:52:29 +0100
Message-ID: <1349952748.14806.32.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Christoph Egger 
Date: Thu, 11 Oct 2012 11:52:28 +0100
In-Reply-To: <50768BC2.1080704@amd.com>
References: <1349943909-2495-1-git-send-email-linux@eikelenboom.it>
	<1349943909-2495-2-git-send-email-linux@eikelenboom.it>
	<1349945556.14806.22.camel@zakaz.uk.xensource.com>
	<50768BC2.1080704@amd.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Attilio Rao ,
	"linux@eikelenboom.it" ,
	"xen-devel@lists.xen.org" ,
	Roger Pau Monne 
Subject: Re: [Xen-devel] [PATCH 1/3] init/sysconfig scripts: Remove
 --halt/-H option for shutdown command.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-11 at 10:05 +0100, Christoph Egger wrote:
> On 10/11/12 10:52, Ian Campbell wrote:
> > On Thu, 2012-10-11 at 09:25 +0100, linux@eikelenboom.it wrote:
> >> From: Sander Eikelenboom 
> >>
> >> The --halt/-H option for the shutdown command is now pointless,
> >> since linux in a guest treats "halt" and "poweroff" identically.
> > 
> > This looks good to me but I'd just like to confirm that Free&NetBSD also
> > treat them the same before I commit it.
> 
> shutdown in NetBSD never had a --halt option.
> shutdown runs the shutdown procedure and halts the system.
> shutdown -p runs the shutdown procedure and then powers off the system.

Thanks, I've acked + applied this now.

Ian.


> 
> Christoph
> 
> > 
> > Ian.
> > 
> >> The option is not implemented in xl / libxl and if supplied causes the command
> >> to fail , so remove it from the init and sysconfig scripts.
> >>
> >> Signed-off-by: Sander Eikelenboom 
> >> ---
> >>  tools/hotplug/Linux/init.d/sysconfig.xendomains |   12 ++++++------
> >>  tools/hotplug/Linux/init.d/xendomains           |    4 ++--
> >>  tools/hotplug/NetBSD/rc.d/xendomains            |    2 +-
> >>  3 files changed, 9 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/tools/hotplug/Linux/init.d/sysconfig.xendomains b/tools/hotplug/Linux/init.d/sysconfig.xendomains
> >> index e590d3f..4775277 100644
> >> --- a/tools/hotplug/Linux/init.d/sysconfig.xendomains
> >> +++ b/tools/hotplug/Linux/init.d/sysconfig.xendomains
> >> @@ -56,29 +56,29 @@ XENDOMAINS_MIGRATE=""
> >>  XENDOMAINS_SAVE=/var/lib/xen/save
> >>  
> >>  ## Type: string
> >> -## Default: "--halt --wait"
> >> +## Default: "--wait"
> >>  #
> >>  # If neither MIGRATE nor SAVE were enabled or if they failed, you can
> >>  # try to shut down a domain by sending it a shutdown request. To do this,
> >> -# set this to "--halt --wait". Omit the "--wait" flag to avoid waiting
> >> +# set this to "--wait". Omit the "--wait" flag to avoid waiting
> >>  # for the domain to be really down. Leave empty to skip domain shutdown.
> >>  #
> >> -XENDOMAINS_SHUTDOWN="--halt --wait"
> >> +XENDOMAINS_SHUTDOWN="--wait"
> >>  
> >>  ## Type: string
> >> -## Default: "--all --halt --wait"
> >> +## Default: "--all --wait"
> >>  #
> >>  # After we have gone over all virtual machines (resp. all automatically
> >>  # started ones, see XENDOMAINS_AUTO_ONLY below) in a loop and sent SysRq,
> >>  # migrated, saved and/or shutdown according to the settings above, we
> >>  # might want to shutdown the virtual machines that are still running
> >>  # for some reason or another. To do this, set this variable to
> >> -# "--all --halt --wait", it will be passed to xm shutdown.
> >> +# "--all --wait", it will be passed to xm shutdown.
> >>  # Leave it empty not to do anything special here.
> >>  # (Note: This will hit all virtual machines, even if XENDOMAINS_AUTO_ONLY
> >>  # is set.)
> >>  # 
> >> -XENDOMAINS_SHUTDOWN_ALL="--all --halt --wait"
> >> +XENDOMAINS_SHUTDOWN_ALL="--all --wait"
> >>  
> >>  ## Type: boolean
> >>  ## Default: true
> >> diff --git a/tools/hotplug/Linux/init.d/xendomains b/tools/hotplug/Linux/init.d/xendomains
> >> index c033581..c363208 100644
> >> --- a/tools/hotplug/Linux/init.d/xendomains
> >> +++ b/tools/hotplug/Linux/init.d/xendomains
> >> @@ -434,7 +434,7 @@ stop()
> >>  	    fi
> >>  	fi
> >>  	if test -n "$XENDOMAINS_SHUTDOWN"; then
> >> -	    # XENDOMAINS_SHUTDOWN should be "--halt --wait"
> >> +	    # XENDOMAINS_SHUTDOWN should be "--wait"
> >>  	    echo -n "(shut)"
> >>  	    watchdog_xencmd shutdown &
> >>  	    WDOG_PID=$!
> >> @@ -453,7 +453,7 @@ stop()
> >>      # This is because it's easier to do ;-) but arguably if this script is run
> >>      # on system shutdown then it's also the right thing to do.
> >>      if ! all_zombies && test -n "$XENDOMAINS_SHUTDOWN_ALL"; then
> >> -	# XENDOMAINS_SHUTDOWN_ALL should be "--all --halt --wait"
> >> +	# XENDOMAINS_SHUTDOWN_ALL should be "--all --wait"
> >>  	echo -n " SHUTDOWN_ALL "
> >>  	watchdog_xencmd shutdown 1 false &
> >>  	WDOG_PID=$!
> >> diff --git a/tools/hotplug/NetBSD/rc.d/xendomains b/tools/hotplug/NetBSD/rc.d/xendomains
> >> index c368c58..3e62038 100644
> >> --- a/tools/hotplug/NetBSD/rc.d/xendomains
> >> +++ b/tools/hotplug/NetBSD/rc.d/xendomains
> >> @@ -94,7 +94,7 @@ xendomains_stop()
> >>  	#
> >>  	echo "Stopping xen domains."
> >>  	for domain in $(xendomains_list); do
> >> -		${ctl_command} shutdown --halt $domain
> >> +		${ctl_command} shutdown $domain
> >>  	done
> >>  	while [ $timeout -gt 0 ]; do
> >>  		livedomains=$(xendomains_list)
> > 
> > 
> > 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 10:52:51 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 10:52:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMGNV-0007Lv-In; Thu, 11 Oct 2012 10:52:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMGNT-0007Lq-PB
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 10:52:32 +0000
Received: from [85.158.139.83:38050] by server-5.bemta-5.messagelabs.com id
	2A/70-19238-FE4A6705; Thu, 11 Oct 2012 10:52:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1349952750!34380789!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM5ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8887 invoked from network); 11 Oct 2012 10:52:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Oct 2012 10:52:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,571,1344211200"; d="scan'208";a="15095834"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Oct 2012 10:52:30 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 11 Oct 2012 11:52:29 +0100
Message-ID: <1349952748.14806.32.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Christoph Egger 
Date: Thu, 11 Oct 2012 11:52:28 +0100
In-Reply-To: <50768BC2.1080704@amd.com>
References: <1349943909-2495-1-git-send-email-linux@eikelenboom.it>
	<1349943909-2495-2-git-send-email-linux@eikelenboom.it>
	<1349945556.14806.22.camel@zakaz.uk.xensource.com>
	<50768BC2.1080704@amd.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Attilio Rao ,
	"linux@eikelenboom.it" ,
	"xen-devel@lists.xen.org" ,
	Roger Pau Monne 
Subject: Re: [Xen-devel] [PATCH 1/3] init/sysconfig scripts: Remove
 --halt/-H option for shutdown command.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-11 at 10:05 +0100, Christoph Egger wrote:
> On 10/11/12 10:52, Ian Campbell wrote:
> > On Thu, 2012-10-11 at 09:25 +0100, linux@eikelenboom.it wrote:
> >> From: Sander Eikelenboom 
> >>
> >> The --halt/-H option for the shutdown command is now pointless,
> >> since linux in a guest treats "halt" and "poweroff" identically.
> > 
> > This looks good to me but I'd just like to confirm that Free&NetBSD also
> > treat them the same before I commit it.
> 
> shutdown in NetBSD never had a --halt option.
> shutdown runs the shutdown procedure and halts the system.
> shutdown -p runs the shutdown procedure and then powers off the system.

Thanks, I've acked + applied this now.

Ian.


> 
> Christoph
> 
> > 
> > Ian.
> > 
> >> The option is not implemented in xl / libxl and if supplied causes the command
> >> to fail , so remove it from the init and sysconfig scripts.
> >>
> >> Signed-off-by: Sander Eikelenboom 
> >> ---
> >>  tools/hotplug/Linux/init.d/sysconfig.xendomains |   12 ++++++------
> >>  tools/hotplug/Linux/init.d/xendomains           |    4 ++--
> >>  tools/hotplug/NetBSD/rc.d/xendomains            |    2 +-
> >>  3 files changed, 9 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/tools/hotplug/Linux/init.d/sysconfig.xendomains b/tools/hotplug/Linux/init.d/sysconfig.xendomains
> >> index e590d3f..4775277 100644
> >> --- a/tools/hotplug/Linux/init.d/sysconfig.xendomains
> >> +++ b/tools/hotplug/Linux/init.d/sysconfig.xendomains
> >> @@ -56,29 +56,29 @@ XENDOMAINS_MIGRATE=""
> >>  XENDOMAINS_SAVE=/var/lib/xen/save
> >>  
> >>  ## Type: string
> >> -## Default: "--halt --wait"
> >> +## Default: "--wait"
> >>  #
> >>  # If neither MIGRATE nor SAVE were enabled or if they failed, you can
> >>  # try to shut down a domain by sending it a shutdown request. To do this,
> >> -# set this to "--halt --wait". Omit the "--wait" flag to avoid waiting
> >> +# set this to "--wait". Omit the "--wait" flag to avoid waiting
> >>  # for the domain to be really down. Leave empty to skip domain shutdown.
> >>  #
> >> -XENDOMAINS_SHUTDOWN="--halt --wait"
> >> +XENDOMAINS_SHUTDOWN="--wait"
> >>  
> >>  ## Type: string
> >> -## Default: "--all --halt --wait"
> >> +## Default: "--all --wait"
> >>  #
> >>  # After we have gone over all virtual machines (resp. all automatically
> >>  # started ones, see XENDOMAINS_AUTO_ONLY below) in a loop and sent SysRq,
> >>  # migrated, saved and/or shutdown according to the settings above, we
> >>  # might want to shutdown the virtual machines that are still running
> >>  # for some reason or another. To do this, set this variable to
> >> -# "--all --halt --wait", it will be passed to xm shutdown.
> >> +# "--all --wait", it will be passed to xm shutdown.
> >>  # Leave it empty not to do anything special here.
> >>  # (Note: This will hit all virtual machines, even if XENDOMAINS_AUTO_ONLY
> >>  # is set.)
> >>  # 
> >> -XENDOMAINS_SHUTDOWN_ALL="--all --halt --wait"
> >> +XENDOMAINS_SHUTDOWN_ALL="--all --wait"
> >>  
> >>  ## Type: boolean
> >>  ## Default: true
> >> diff --git a/tools/hotplug/Linux/init.d/xendomains b/tools/hotplug/Linux/init.d/xendomains
> >> index c033581..c363208 100644
> >> --- a/tools/hotplug/Linux/init.d/xendomains
> >> +++ b/tools/hotplug/Linux/init.d/xendomains
> >> @@ -434,7 +434,7 @@ stop()
> >>  	    fi
> >>  	fi
> >>  	if test -n "$XENDOMAINS_SHUTDOWN"; then
> >> -	    # XENDOMAINS_SHUTDOWN should be "--halt --wait"
> >> +	    # XENDOMAINS_SHUTDOWN should be "--wait"
> >>  	    echo -n "(shut)"
> >>  	    watchdog_xencmd shutdown &
> >>  	    WDOG_PID=$!
> >> @@ -453,7 +453,7 @@ stop()
> >>      # This is because it's easier to do ;-) but arguably if this script is run
> >>      # on system shutdown then it's also the right thing to do.
> >>      if ! all_zombies && test -n "$XENDOMAINS_SHUTDOWN_ALL"; then
> >> -	# XENDOMAINS_SHUTDOWN_ALL should be "--all --halt --wait"
> >> +	# XENDOMAINS_SHUTDOWN_ALL should be "--all --wait"
> >>  	echo -n " SHUTDOWN_ALL "
> >>  	watchdog_xencmd shutdown 1 false &
> >>  	WDOG_PID=$!
> >> diff --git a/tools/hotplug/NetBSD/rc.d/xendomains b/tools/hotplug/NetBSD/rc.d/xendomains
> >> index c368c58..3e62038 100644
> >> --- a/tools/hotplug/NetBSD/rc.d/xendomains
> >> +++ b/tools/hotplug/NetBSD/rc.d/xendomains
> >> @@ -94,7 +94,7 @@ xendomains_stop()
> >>  	#
> >>  	echo "Stopping xen domains."
> >>  	for domain in $(xendomains_list); do
> >> -		${ctl_command} shutdown --halt $domain
> >> +		${ctl_command} shutdown $domain
> >>  	done
> >>  	while [ $timeout -gt 0 ]; do
> >>  		livedomains=$(xendomains_list)
> > 
> > 
> > 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 10:52:57 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 10:52:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMGNZ-0007ME-V6; Thu, 11 Oct 2012 10:52:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMGNX-0007M2-Ny
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 10:52:36 +0000
Received: from [85.158.139.83:23405] by server-10.bemta-5.messagelabs.com id
	B2/FC-06995-3F4A6705; Thu, 11 Oct 2012 10:52:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1349952750!34380789!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM5ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9385 invoked from network); 11 Oct 2012 10:52:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Oct 2012 10:52:34 -0000
X-IronPort-AV: E=Sophos;i="4.80,571,1344211200"; d="scan'208";a="15095836"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Oct 2012 10:52:34 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 11 Oct 2012 11:52:33 +0100
Message-ID: <1349952752.14806.33.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: "linux@eikelenboom.it" 
Date: Thu, 11 Oct 2012 11:52:32 +0100
In-Reply-To: <1349951120-1968-1-git-send-email-linux@eikelenboom.it>
References: <1349945896.14806.25.camel@zakaz.uk.xensource.com>
	<1349951120-1968-1-git-send-email-linux@eikelenboom.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH v2 3/3] xl/libxl: make shutdown accept the
 long option --wait for -w
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-11 at 11:25 +0100, linux@eikelenboom.it wrote:
> From: Sander Eikelenboom 
> 
> Make xl/libxl accept the long option --wait for -w to be compatible with xm.
> The long options are used in the default init and sysconfig scripts.
> 
> Signed-off-by: Sander Eikelenboom 

Acked-by: Ian Campbell 
and committed, thanks.
> ---
>  docs/man/xl.pod.1         |    2 +-
>  tools/libxl/xl_cmdimpl.c  |    6 +++++-
>  tools/libxl/xl_cmdtable.c |    2 +-
>  3 files changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
> index 25ce777..dd387c9 100644
> --- a/docs/man/xl.pod.1
> +++ b/docs/man/xl.pod.1
> @@ -550,7 +550,7 @@ B
>  
>  =over 4
>  
> -=item B<-w>
> +=item B<-w>, B<--wait>
>  
>  Wait for the domain to complete shutdown before returning.
>  
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 93066d3..389b5f7 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -3709,8 +3709,12 @@ int main_shutdown(int argc, char **argv)
>      int opt;
>      int wait_for_it = 0;
>      int fallback_trigger = 0;
> +    static struct option long_options[] = {
> +        {"wait", 0, 0, 'w'},
> +        {0, 0, 0, 0}
> +    };
>  
> -    while ((opt = def_getopt(argc, argv, "wF", "shutdown", 1)) != -1) {
> +    while ((opt = getopt_long(argc, argv, "wF", long_options, NULL)) != -1) {
>          switch (opt) {
>          case 0: case 2:
>              return opt;
> diff --git a/tools/libxl/xl_cmdtable.c b/tools/libxl/xl_cmdtable.c
> index 85ea768..b398c0a 100644
> --- a/tools/libxl/xl_cmdtable.c
> +++ b/tools/libxl/xl_cmdtable.c
> @@ -64,7 +64,7 @@ struct cmd_spec cmd_table[] = {
>        "-h                      Print this help.\n"
>        "-F                      Fallback to ACPI power event for HVM guests with\n"
>        "                        no PV drivers.\n"
> -      "-w                      Wait for guest to shutdown.\n"
> +      "-w, --wait              Wait for guest to shutdown.\n"
>      },
>      { "reboot",
>        &main_reboot, 0, 1,



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 10:52:57 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 10:52:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMGNZ-0007ME-V6; Thu, 11 Oct 2012 10:52:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMGNX-0007M2-Ny
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 10:52:36 +0000
Received: from [85.158.139.83:23405] by server-10.bemta-5.messagelabs.com id
	B2/FC-06995-3F4A6705; Thu, 11 Oct 2012 10:52:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1349952750!34380789!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM5ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9385 invoked from network); 11 Oct 2012 10:52:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Oct 2012 10:52:34 -0000
X-IronPort-AV: E=Sophos;i="4.80,571,1344211200"; d="scan'208";a="15095836"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Oct 2012 10:52:34 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 11 Oct 2012 11:52:33 +0100
Message-ID: <1349952752.14806.33.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: "linux@eikelenboom.it" 
Date: Thu, 11 Oct 2012 11:52:32 +0100
In-Reply-To: <1349951120-1968-1-git-send-email-linux@eikelenboom.it>
References: <1349945896.14806.25.camel@zakaz.uk.xensource.com>
	<1349951120-1968-1-git-send-email-linux@eikelenboom.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH v2 3/3] xl/libxl: make shutdown accept the
 long option --wait for -w
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-11 at 11:25 +0100, linux@eikelenboom.it wrote:
> From: Sander Eikelenboom 
> 
> Make xl/libxl accept the long option --wait for -w to be compatible with xm.
> The long options are used in the default init and sysconfig scripts.
> 
> Signed-off-by: Sander Eikelenboom 

Acked-by: Ian Campbell 
and committed, thanks.
> ---
>  docs/man/xl.pod.1         |    2 +-
>  tools/libxl/xl_cmdimpl.c  |    6 +++++-
>  tools/libxl/xl_cmdtable.c |    2 +-
>  3 files changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
> index 25ce777..dd387c9 100644
> --- a/docs/man/xl.pod.1
> +++ b/docs/man/xl.pod.1
> @@ -550,7 +550,7 @@ B
>  
>  =over 4
>  
> -=item B<-w>
> +=item B<-w>, B<--wait>
>  
>  Wait for the domain to complete shutdown before returning.
>  
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 93066d3..389b5f7 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -3709,8 +3709,12 @@ int main_shutdown(int argc, char **argv)
>      int opt;
>      int wait_for_it = 0;
>      int fallback_trigger = 0;
> +    static struct option long_options[] = {
> +        {"wait", 0, 0, 'w'},
> +        {0, 0, 0, 0}
> +    };
>  
> -    while ((opt = def_getopt(argc, argv, "wF", "shutdown", 1)) != -1) {
> +    while ((opt = getopt_long(argc, argv, "wF", long_options, NULL)) != -1) {
>          switch (opt) {
>          case 0: case 2:
>              return opt;
> diff --git a/tools/libxl/xl_cmdtable.c b/tools/libxl/xl_cmdtable.c
> index 85ea768..b398c0a 100644
> --- a/tools/libxl/xl_cmdtable.c
> +++ b/tools/libxl/xl_cmdtable.c
> @@ -64,7 +64,7 @@ struct cmd_spec cmd_table[] = {
>        "-h                      Print this help.\n"
>        "-F                      Fallback to ACPI power event for HVM guests with\n"
>        "                        no PV drivers.\n"
> -      "-w                      Wait for guest to shutdown.\n"
> +      "-w, --wait              Wait for guest to shutdown.\n"
>      },
>      { "reboot",
>        &main_reboot, 0, 1,



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 13:15:21 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 13:15:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMIb2-00089i-Uc; Thu, 11 Oct 2012 13:14:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMIb2-00089d-B1
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 13:14:40 +0000
Received: from [85.158.139.83:31967] by server-11.bemta-5.messagelabs.com id
	81/8C-15507-F36C6705; Thu, 11 Oct 2012 13:14:39 +0000
X-Env-Sender: pavel@netsafe.cz
X-Msg-Ref: server-16.tower-182.messagelabs.com!1349961278!27091508!1
X-Originating-IP: [83.223.49.132]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29990 invoked from network); 11 Oct 2012 13:14:39 -0000
Received: from gate1.netsafe.cz (HELO gate1.netsafe.cz) (83.223.49.132)
	by server-16.tower-182.messagelabs.com with SMTP;
	11 Oct 2012 13:14:39 -0000
Received: (qmail 29529 invoked from network); 11 Oct 2012 15:14:23 +0200
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on webgate.netsafe.cz
X-Spam-Level: 
X-Spam-Status: No, score=-106.8 required=5.0 tests=ALL_TRUSTED,BAYES_00,
	USER_IN_WHITELIST autolearn=ham version=3.2.5
Received: from unknown (HELO nudel.localnet) (pavel@10.64.1.132)
	by webgate.netsafe.cz with AES256-SHA encrypted SMTP;
	11 Oct 2012 15:14:23 +0200
From: Pavel Mateja 
Organization: Netsafe
To: xen-devel@lists.xen.org
Date: Thu, 11 Oct 2012 15:14:22 +0200
User-Agent: KMail/1.13.7 (Linux/3.2.0-3-amd64; KDE/4.8.4; x86_64; ; )
References: <1349511545.3350.8.camel@multiplex>
In-Reply-To: <1349511545.3350.8.camel@multiplex>
MIME-Version: 1.0
Message-Id: <201210111514.23294.pavel@netsafe.cz>
Subject: Re: [Xen-devel] PCI USB Passthrough on Kernel 3.5 and 3.6 not
	working (HVM or PVM)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Hi Xenners,
> 
> I have tried to upgrade to kernel 3.5 and experienced the USB/PCI
> passthrough problem.  This has not been "fixed" in 3.6 either.  I do not
> know if this is qemu, xen or kernel related.
> 
> I am using Xen 4.2 final and Xen 4.3-unstable to test.
> 
> DomU is Windows 7 64 bit or Linux Fedora 17.  In Windows, I get the
> little yellow triangle with Code 10 (I know this means nothing...
> really).  In linux, the PCI device is recognised, but a few seconds
> later disabled due to a "fatal error", no more details than that in
> dmesg.
> 
> Dom0 retains full control over the USB controller (this is not the case
> when passthrough works, xl switches between Dom0 and DomU depending on
> who claims the device).
> 
> In both Windows and Linux (lspci), the device is "seen" but cannot be
> activated.
> 
> In Dom0, the device is assigned to the guest (xl pci-list show that it
> is assigned and has a valid guest PCI ID).
> 
> Xen logs are normal, devices get assigned as if they were working with a
> kernel 3.3.4 Dom0 - no errors according to xen logs or xl dmesg.
> 
> VGA PCI passthrough works 100%.
> 
> I tried also with device model qemu-xen, but then passthrough doesn't
> work at all (no VGA either), even with upstream QEMU from git.
> 
> Please tell me if I'm missing something obvious or if I can provide more
> information for troubleshooting!
> 
> Kind regards,
> Andi

Hi,
did you try the resource_allignment workaround?
What is your HW anyway?
-- 
Pavel Mateja

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 13:15:21 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 13:15:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMIb2-00089i-Uc; Thu, 11 Oct 2012 13:14:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMIb2-00089d-B1
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 13:14:40 +0000
Received: from [85.158.139.83:31967] by server-11.bemta-5.messagelabs.com id
	81/8C-15507-F36C6705; Thu, 11 Oct 2012 13:14:39 +0000
X-Env-Sender: pavel@netsafe.cz
X-Msg-Ref: server-16.tower-182.messagelabs.com!1349961278!27091508!1
X-Originating-IP: [83.223.49.132]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29990 invoked from network); 11 Oct 2012 13:14:39 -0000
Received: from gate1.netsafe.cz (HELO gate1.netsafe.cz) (83.223.49.132)
	by server-16.tower-182.messagelabs.com with SMTP;
	11 Oct 2012 13:14:39 -0000
Received: (qmail 29529 invoked from network); 11 Oct 2012 15:14:23 +0200
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on webgate.netsafe.cz
X-Spam-Level: 
X-Spam-Status: No, score=-106.8 required=5.0 tests=ALL_TRUSTED,BAYES_00,
	USER_IN_WHITELIST autolearn=ham version=3.2.5
Received: from unknown (HELO nudel.localnet) (pavel@10.64.1.132)
	by webgate.netsafe.cz with AES256-SHA encrypted SMTP;
	11 Oct 2012 15:14:23 +0200
From: Pavel Mateja 
Organization: Netsafe
To: xen-devel@lists.xen.org
Date: Thu, 11 Oct 2012 15:14:22 +0200
User-Agent: KMail/1.13.7 (Linux/3.2.0-3-amd64; KDE/4.8.4; x86_64; ; )
References: <1349511545.3350.8.camel@multiplex>
In-Reply-To: <1349511545.3350.8.camel@multiplex>
MIME-Version: 1.0
Message-Id: <201210111514.23294.pavel@netsafe.cz>
Subject: Re: [Xen-devel] PCI USB Passthrough on Kernel 3.5 and 3.6 not
	working (HVM or PVM)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Hi Xenners,
> 
> I have tried to upgrade to kernel 3.5 and experienced the USB/PCI
> passthrough problem.  This has not been "fixed" in 3.6 either.  I do not
> know if this is qemu, xen or kernel related.
> 
> I am using Xen 4.2 final and Xen 4.3-unstable to test.
> 
> DomU is Windows 7 64 bit or Linux Fedora 17.  In Windows, I get the
> little yellow triangle with Code 10 (I know this means nothing...
> really).  In linux, the PCI device is recognised, but a few seconds
> later disabled due to a "fatal error", no more details than that in
> dmesg.
> 
> Dom0 retains full control over the USB controller (this is not the case
> when passthrough works, xl switches between Dom0 and DomU depending on
> who claims the device).
> 
> In both Windows and Linux (lspci), the device is "seen" but cannot be
> activated.
> 
> In Dom0, the device is assigned to the guest (xl pci-list show that it
> is assigned and has a valid guest PCI ID).
> 
> Xen logs are normal, devices get assigned as if they were working with a
> kernel 3.3.4 Dom0 - no errors according to xen logs or xl dmesg.
> 
> VGA PCI passthrough works 100%.
> 
> I tried also with device model qemu-xen, but then passthrough doesn't
> work at all (no VGA either), even with upstream QEMU from git.
> 
> Please tell me if I'm missing something obvious or if I can provide more
> information for troubleshooting!
> 
> Kind regards,
> Andi

Hi,
did you try the resource_allignment workaround?
What is your HW anyway?
-- 
Pavel Mateja

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 14:07:22 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 14:07:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMJPX-00005C-PQ; Thu, 11 Oct 2012 14:06:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMJPV-00004u-FV
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 14:06:49 +0000
Received: from [85.158.139.83:36465] by server-11.bemta-5.messagelabs.com id
	E2/8D-15507-872D6705; Thu, 11 Oct 2012 14:06:48 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1349964407!28821662!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31398 invoked from network); 11 Oct 2012 14:06:48 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Oct 2012 14:06:48 -0000
Received: by mail-qc0-f173.google.com with SMTP id b12so1766843qca.32
	for ; Thu, 11 Oct 2012 07:06:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=pAon9VuaJdhxxN7NOpS3Cnf6oPS6QDmn4V5gE6daiiI=;
	b=cwt7H7NkYmPkxIWDf1KYxmOf1uYbWIbLik3nxYwEaI2kUXZkfEggr6NBcS9mr4ID+r
	DZ7smq+FacSSrCkJDI+9YZ0xk5Jm2TrdV4lGJyRuJJdquGNV2ew9y2Tb2WSizafZwBxf
	khMXP/2D7RhHb+W2QnweiDHJwzVIZCEtpcfOj/Qf30a5m1JQWoz/Ri+e7iP4hj2PJIfd
	wdRkmyu4cI+1/R5jCc99f2en4+2ja78ak3C17Ld8QgzaHhzWUfuiLIyeqCrVca8XPNle
	+DMLNOKF9/13yo0linFxJzxk25hIuS524cHenx3qflMfTguSk6H7jLyoIXAv4VVK1ttw
	C34g==
Received: by 10.224.39.76 with SMTP id f12mr1850552qae.94.1349964406722;
	Thu, 11 Oct 2012 07:06:46 -0700 (PDT)
Received: from localhost.localdomain (me62436d0.tmodns.net. [208.54.36.230])
	by mx.google.com with ESMTPS id hb7sm2221718qab.20.2012.10.11.07.06.45
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 11 Oct 2012 07:06:46 -0700 (PDT)
Date: Thu, 11 Oct 2012 10:06:42 -0400
From: Konrad Rzeszutek Wilk 
To: Pavel Mateja 
Message-ID: <20121011140640.GB1883@localhost.localdomain>
References: <1349511545.3350.8.camel@multiplex>
	<201210111514.23294.pavel@netsafe.cz>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <201210111514.23294.pavel@netsafe.cz>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] PCI USB Passthrough on Kernel 3.5 and 3.6 not
 working (HVM or PVM)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Oct 11, 2012 at 03:14:22PM +0200, Pavel Mateja wrote:
> > Hi Xenners,
> > 
> > I have tried to upgrade to kernel 3.5 and experienced the USB/PCI
> > passthrough problem.  This has not been "fixed" in 3.6 either.  I do not
> > know if this is qemu, xen or kernel related.

Does your lspci (in dom0) for the device you are passing in, show
'virtual' for the BARs? If so, then it is a kernel issue.

I did another patch for this and it ought to be on the v3.6.x and
v3.5.x train:

commit c341ca45ce56143804ef5a8f4db753e554e640b4
Author: Konrad Rzeszutek Wilk 
Date:   Tue Sep 25 16:48:24 2012 -0400

    xen/pciback: Restore the PCI config space after an FLR.

> > 
> > I am using Xen 4.2 final and Xen 4.3-unstable to test.
> > 
> > DomU is Windows 7 64 bit or Linux Fedora 17.  In Windows, I get the
> > little yellow triangle with Code 10 (I know this means nothing...
> > really).  In linux, the PCI device is recognised, but a few seconds
> > later disabled due to a "fatal error", no more details than that in
> > dmesg.
> > 
> > Dom0 retains full control over the USB controller (this is not the case
> > when passthrough works, xl switches between Dom0 and DomU depending on
> > who claims the device).
> > 
> > In both Windows and Linux (lspci), the device is "seen" but cannot be
> > activated.
> > 
> > In Dom0, the device is assigned to the guest (xl pci-list show that it
> > is assigned and has a valid guest PCI ID).
> > 
> > Xen logs are normal, devices get assigned as if they were working with a
> > kernel 3.3.4 Dom0 - no errors according to xen logs or xl dmesg.
> > 
> > VGA PCI passthrough works 100%.
> > 
> > I tried also with device model qemu-xen, but then passthrough doesn't
> > work at all (no VGA either), even with upstream QEMU from git.
> > 
> > Please tell me if I'm missing something obvious or if I can provide more
> > information for troubleshooting!
> > 
> > Kind regards,
> > Andi
> 
> Hi,
> did you try the resource_allignment workaround?
> What is your HW anyway?
> -- 
> Pavel Mateja
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 14:07:22 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 14:07:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMJPX-00005C-PQ; Thu, 11 Oct 2012 14:06:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMJPV-00004u-FV
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 14:06:49 +0000
Received: from [85.158.139.83:36465] by server-11.bemta-5.messagelabs.com id
	E2/8D-15507-872D6705; Thu, 11 Oct 2012 14:06:48 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1349964407!28821662!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31398 invoked from network); 11 Oct 2012 14:06:48 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Oct 2012 14:06:48 -0000
Received: by mail-qc0-f173.google.com with SMTP id b12so1766843qca.32
	for ; Thu, 11 Oct 2012 07:06:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=pAon9VuaJdhxxN7NOpS3Cnf6oPS6QDmn4V5gE6daiiI=;
	b=cwt7H7NkYmPkxIWDf1KYxmOf1uYbWIbLik3nxYwEaI2kUXZkfEggr6NBcS9mr4ID+r
	DZ7smq+FacSSrCkJDI+9YZ0xk5Jm2TrdV4lGJyRuJJdquGNV2ew9y2Tb2WSizafZwBxf
	khMXP/2D7RhHb+W2QnweiDHJwzVIZCEtpcfOj/Qf30a5m1JQWoz/Ri+e7iP4hj2PJIfd
	wdRkmyu4cI+1/R5jCc99f2en4+2ja78ak3C17Ld8QgzaHhzWUfuiLIyeqCrVca8XPNle
	+DMLNOKF9/13yo0linFxJzxk25hIuS524cHenx3qflMfTguSk6H7jLyoIXAv4VVK1ttw
	C34g==
Received: by 10.224.39.76 with SMTP id f12mr1850552qae.94.1349964406722;
	Thu, 11 Oct 2012 07:06:46 -0700 (PDT)
Received: from localhost.localdomain (me62436d0.tmodns.net. [208.54.36.230])
	by mx.google.com with ESMTPS id hb7sm2221718qab.20.2012.10.11.07.06.45
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 11 Oct 2012 07:06:46 -0700 (PDT)
Date: Thu, 11 Oct 2012 10:06:42 -0400
From: Konrad Rzeszutek Wilk 
To: Pavel Mateja 
Message-ID: <20121011140640.GB1883@localhost.localdomain>
References: <1349511545.3350.8.camel@multiplex>
	<201210111514.23294.pavel@netsafe.cz>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <201210111514.23294.pavel@netsafe.cz>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] PCI USB Passthrough on Kernel 3.5 and 3.6 not
 working (HVM or PVM)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Oct 11, 2012 at 03:14:22PM +0200, Pavel Mateja wrote:
> > Hi Xenners,
> > 
> > I have tried to upgrade to kernel 3.5 and experienced the USB/PCI
> > passthrough problem.  This has not been "fixed" in 3.6 either.  I do not
> > know if this is qemu, xen or kernel related.

Does your lspci (in dom0) for the device you are passing in, show
'virtual' for the BARs? If so, then it is a kernel issue.

I did another patch for this and it ought to be on the v3.6.x and
v3.5.x train:

commit c341ca45ce56143804ef5a8f4db753e554e640b4
Author: Konrad Rzeszutek Wilk 
Date:   Tue Sep 25 16:48:24 2012 -0400

    xen/pciback: Restore the PCI config space after an FLR.

> > 
> > I am using Xen 4.2 final and Xen 4.3-unstable to test.
> > 
> > DomU is Windows 7 64 bit or Linux Fedora 17.  In Windows, I get the
> > little yellow triangle with Code 10 (I know this means nothing...
> > really).  In linux, the PCI device is recognised, but a few seconds
> > later disabled due to a "fatal error", no more details than that in
> > dmesg.
> > 
> > Dom0 retains full control over the USB controller (this is not the case
> > when passthrough works, xl switches between Dom0 and DomU depending on
> > who claims the device).
> > 
> > In both Windows and Linux (lspci), the device is "seen" but cannot be
> > activated.
> > 
> > In Dom0, the device is assigned to the guest (xl pci-list show that it
> > is assigned and has a valid guest PCI ID).
> > 
> > Xen logs are normal, devices get assigned as if they were working with a
> > kernel 3.3.4 Dom0 - no errors according to xen logs or xl dmesg.
> > 
> > VGA PCI passthrough works 100%.
> > 
> > I tried also with device model qemu-xen, but then passthrough doesn't
> > work at all (no VGA either), even with upstream QEMU from git.
> > 
> > Please tell me if I'm missing something obvious or if I can provide more
> > information for troubleshooting!
> > 
> > Kind regards,
> > Andi
> 
> Hi,
> did you try the resource_allignment workaround?
> What is your HW anyway?
> -- 
> Pavel Mateja
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 14:50:39 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 14:50:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMK5U-0000aZ-K6; Thu, 11 Oct 2012 14:50:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMK5T-0000aU-5c
	for xen-devel@lists.xensource.com; Thu, 11 Oct 2012 14:50:11 +0000
Received: from [85.158.143.35:42533] by server-2.bemta-4.messagelabs.com id
	51/ED-25171-2ACD6705; Thu, 11 Oct 2012 14:50:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1349967008!10933007!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM5ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17210 invoked from network); 11 Oct 2012 14:50:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Oct 2012 14:50:08 -0000
X-IronPort-AV: E=Sophos;i="4.80,572,1344211200"; d="scan'208";a="15103165"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Oct 2012 14:50:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 11 Oct 2012 15:50:07 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TMK5P-0005OB-GY;
	Thu, 11 Oct 2012 14:50:07 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TMK5P-0003BY-7V;
	Thu, 11 Oct 2012 15:50:07 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Thu, 11 Oct 2012 15:50:07 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13952: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13952 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13952/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check  fail REGR. vs. 13951

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13951
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13951
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13951
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13951

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  b91f57f54f47
baseline version:
 xen                  3696dd6a7836

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell 
  Ian Jackson 
  Olaf Hering 
  Samuel Thibault 
  Sander Eikelenboom 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26046:b91f57f54f47
tag:         tip
user:        Sander Eikelenboom 
date:        Thu Oct 11 11:52:10 2012 +0100
    
    init/sysconfig scripts: Remove --halt/-H option for shutdown command.
    
    The --halt/-H option for the shutdown command is now pointless,
    since linux in a guest treats "halt" and "poweroff" identically.
    The option is not implemented in xl / libxl and if supplied causes the command
    to fail , so remove it from the init and sysconfig scripts.
    
    Signed-off-by: Sander Eikelenboom 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26045:ba7198bfc679
user:        Sander Eikelenboom 
date:        Thu Oct 11 11:52:09 2012 +0100
    
    xl/libxl: make shutdown accept the long option --wait for -w
    
    Make xl/libxl accept the long option --wait for -w to be compatible with xm.
    The long options are used in the default init and sysconfig scripts.
    
    Signed-off-by: Sander Eikelenboom 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26044:4845b5ce90e8
user:        Sander Eikelenboom 
date:        Thu Oct 11 10:21:16 2012 +0100
    
    init scripts: xendomains correct order of options for shutdown command
    
    Options for the shutdown command that are supplied behind the domain id are
    ignored. In case of the default xendomains init script this means that it will
    not wait for the domains to be actually shutdown.
    
    Signed-off-by: Sander Eikelenboom 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26043:d1c3b589af50
user:        Olaf Hering 
date:        Thu Oct 11 10:21:15 2012 +0100
    
    stubdom: fix error assignment in grub:load_module
    
    [ 1333s] mini-os.c: In function 'load_module':
    [ 1333s] mini-os.c:244: warning: statement with no effect
    
    Signed-off-by: Olaf Hering 
    Acked-by: Samuel Thibault 
    Committed-by: Ian Campbell 
    
    
changeset:   26042:3696dd6a7836
user:        Ian Jackson 
date:        Tue Oct 09 18:00:00 2012 +0100
    
    docs, build: Do not ignore install-docs errors
    
    In the toplevel Makefile "install-docs" (depended on by "install" and
    hence "dist"), but not "build", ignores errors.
    
    This was inherited from before 24563:4271634e4c86, prior to which the
    ||true seems intended to handle failures of check_pkgs.  Nowadays we
    handle docs tools individually in the docs makefiles so there is no
    need for this ||true here.
    
    Signed-off-by: Ian Jackson 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 14:50:39 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 14:50:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMK5U-0000aZ-K6; Thu, 11 Oct 2012 14:50:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMK5T-0000aU-5c
	for xen-devel@lists.xensource.com; Thu, 11 Oct 2012 14:50:11 +0000
Received: from [85.158.143.35:42533] by server-2.bemta-4.messagelabs.com id
	51/ED-25171-2ACD6705; Thu, 11 Oct 2012 14:50:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1349967008!10933007!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM5ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17210 invoked from network); 11 Oct 2012 14:50:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Oct 2012 14:50:08 -0000
X-IronPort-AV: E=Sophos;i="4.80,572,1344211200"; d="scan'208";a="15103165"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Oct 2012 14:50:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 11 Oct 2012 15:50:07 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TMK5P-0005OB-GY;
	Thu, 11 Oct 2012 14:50:07 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TMK5P-0003BY-7V;
	Thu, 11 Oct 2012 15:50:07 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Thu, 11 Oct 2012 15:50:07 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13952: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13952 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13952/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check  fail REGR. vs. 13951

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13951
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13951
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13951
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13951

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  b91f57f54f47
baseline version:
 xen                  3696dd6a7836

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell 
  Ian Jackson 
  Olaf Hering 
  Samuel Thibault 
  Sander Eikelenboom 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26046:b91f57f54f47
tag:         tip
user:        Sander Eikelenboom 
date:        Thu Oct 11 11:52:10 2012 +0100
    
    init/sysconfig scripts: Remove --halt/-H option for shutdown command.
    
    The --halt/-H option for the shutdown command is now pointless,
    since linux in a guest treats "halt" and "poweroff" identically.
    The option is not implemented in xl / libxl and if supplied causes the command
    to fail , so remove it from the init and sysconfig scripts.
    
    Signed-off-by: Sander Eikelenboom 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26045:ba7198bfc679
user:        Sander Eikelenboom 
date:        Thu Oct 11 11:52:09 2012 +0100
    
    xl/libxl: make shutdown accept the long option --wait for -w
    
    Make xl/libxl accept the long option --wait for -w to be compatible with xm.
    The long options are used in the default init and sysconfig scripts.
    
    Signed-off-by: Sander Eikelenboom 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26044:4845b5ce90e8
user:        Sander Eikelenboom 
date:        Thu Oct 11 10:21:16 2012 +0100
    
    init scripts: xendomains correct order of options for shutdown command
    
    Options for the shutdown command that are supplied behind the domain id are
    ignored. In case of the default xendomains init script this means that it will
    not wait for the domains to be actually shutdown.
    
    Signed-off-by: Sander Eikelenboom 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26043:d1c3b589af50
user:        Olaf Hering 
date:        Thu Oct 11 10:21:15 2012 +0100
    
    stubdom: fix error assignment in grub:load_module
    
    [ 1333s] mini-os.c: In function 'load_module':
    [ 1333s] mini-os.c:244: warning: statement with no effect
    
    Signed-off-by: Olaf Hering 
    Acked-by: Samuel Thibault 
    Committed-by: Ian Campbell 
    
    
changeset:   26042:3696dd6a7836
user:        Ian Jackson 
date:        Tue Oct 09 18:00:00 2012 +0100
    
    docs, build: Do not ignore install-docs errors
    
    In the toplevel Makefile "install-docs" (depended on by "install" and
    hence "dist"), but not "build", ignores errors.
    
    This was inherited from before 24563:4271634e4c86, prior to which the
    ||true seems intended to handle failures of check_pkgs.  Nowadays we
    handle docs tools individually in the docs makefiles so there is no
    need for this ||true here.
    
    Signed-off-by: Ian Jackson 
    Acked-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 14:58:23 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 14:58:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMKD1-0000jp-Kl; Thu, 11 Oct 2012 14:57:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMKD0-0000jk-DB
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 14:57:58 +0000
Received: from [85.158.139.83:61457] by server-10.bemta-5.messagelabs.com id
	35/BF-06995-57ED6705; Thu, 11 Oct 2012 14:57:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1349967477!33780481!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM5ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4353 invoked from network); 11 Oct 2012 14:57:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Oct 2012 14:57:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,572,1344211200"; d="scan'208";a="15103427"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Oct 2012 14:57:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 11 Oct 2012 15:57:56 +0100
Message-ID: <1349967475.14806.36.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: xen-devel 
Date: Thu, 11 Oct 2012 15:57:55 +0100
In-Reply-To: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH 0/16] arm: support for initial modules (e.g.
 dom0) and DTB supplied in RAM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-03 at 14:28 +0100, Ian Campbell wrote:
> The following series implements support for initial images and DTB in
> RAM

A subset of these patches have been acked so I have applied them. They
are generally cleanups rather than the main boot-wrapper stuff.
        arm: Zero the BSS at start of day.
        arm: make virtual address defines unsigned
        arm: move get_paddr_function to arch setup.c from device_tree.c
        arm: really allocate boot frametable pages with 32M alignment
        arm: print a message if multiple banks of memory are present.
        arm: mark heap and frametable limits as read mostly

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 14:58:23 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 14:58:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMKD1-0000jp-Kl; Thu, 11 Oct 2012 14:57:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMKD0-0000jk-DB
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 14:57:58 +0000
Received: from [85.158.139.83:61457] by server-10.bemta-5.messagelabs.com id
	35/BF-06995-57ED6705; Thu, 11 Oct 2012 14:57:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1349967477!33780481!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM5ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4353 invoked from network); 11 Oct 2012 14:57:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Oct 2012 14:57:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,572,1344211200"; d="scan'208";a="15103427"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Oct 2012 14:57:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 11 Oct 2012 15:57:56 +0100
Message-ID: <1349967475.14806.36.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: xen-devel 
Date: Thu, 11 Oct 2012 15:57:55 +0100
In-Reply-To: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH 0/16] arm: support for initial modules (e.g.
 dom0) and DTB supplied in RAM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-03 at 14:28 +0100, Ian Campbell wrote:
> The following series implements support for initial images and DTB in
> RAM

A subset of these patches have been acked so I have applied them. They
are generally cleanups rather than the main boot-wrapper stuff.
        arm: Zero the BSS at start of day.
        arm: make virtual address defines unsigned
        arm: move get_paddr_function to arch setup.c from device_tree.c
        arm: really allocate boot frametable pages with 32M alignment
        arm: print a message if multiple banks of memory are present.
        arm: mark heap and frametable limits as read mostly

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 15:19:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 15:19:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMKXZ-0000yR-6J; Thu, 11 Oct 2012 15:19:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMKXY-0000yJ-Es
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 15:19:12 +0000
Received: from [85.158.139.211:49901] by server-12.bemta-5.messagelabs.com id
	25/B9-19095-F63E6705; Thu, 11 Oct 2012 15:19:11 +0000
X-Env-Sender: tupeng212@gmail.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1349968748!22010645!1
X-Originating-IP: [209.85.220.45]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_50_60,HTML_MESSAGE,
	MIME_BASE64_TEXT, MIME_BOUND_NEXTPART, ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP, spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28774 invoked from network); 11 Oct 2012 15:19:10 -0000
Received: from mail-pa0-f45.google.com (HELO mail-pa0-f45.google.com)
	(209.85.220.45)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Oct 2012 15:19:10 -0000
Received: by mail-pa0-f45.google.com with SMTP id fb10so1880668pad.32
	for ; Thu, 11 Oct 2012 08:19:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=date:from:to:reply-to:subject:x-priority:x-guid:x-has-attach
	:x-mailer:mime-version:message-id:content-type;
	bh=9e52YfMbYLG9cVIdAiL7L/Jfwq6nFnc7XXI1gCrQvAs=;
	b=djNtWTS3+fhnDwclq0N2MECaJMG985JqBACVk7sjN9STYnYpd8OFPrS9buGQ8+Urth
	EuXvVY0ffqwHDieM5wAdpjGwtMRbIiZeUv87RYgwW7ThXZlylULjG1onq3EoxEq/ENgk
	8dZGFr+F6sD8nqszQsTLpy0gLL0Fusm2+rQwMRdR/76zu4khBsARfWBdKV9Knxfd1xl8
	Hr5yvg5lyiJpsVM7Bn5AGuGuzTfcNfeiGZ8ukRlEj4uZQVsWbhuDxoO26ZJmHu7aSSjD
	07m9szhbs/akGjV7hoR9Cw9qbplKSrwzjiYcO20/S4oS+ThaIqM/Qhsbra7aqoykMcSm
	aUow==
Received: by 10.68.143.162 with SMTP id sf2mr4412618pbb.137.1349968748388;
	Thu, 11 Oct 2012 08:19:08 -0700 (PDT)
Received: from root ([183.128.153.80])
	by mx.google.com with ESMTPS id vw4sm2885754pbc.26.2012.10.11.08.18.52
	(version=SSLv3 cipher=OTHER); Thu, 11 Oct 2012 08:19:06 -0700 (PDT)
Date: Thu, 11 Oct 2012 23:18:52 +0800
From: tupeng212 
To: xen-devel 
X-Priority: 3
X-GUID: 463ADFE7-4216-46E4-9551-A6A65B1E9B97
X-Has-Attach: no
X-Mailer: Foxmail 7.0.1.87[cn]
Mime-Version: 1.0
Message-ID: <201210112318468920764@gmail.com>
Subject: [Xen-devel] alloc_heap_pages is low efficient with more CPUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: tupeng212 
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============5297671841591368988=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.

--===============5297671841591368988==
Content-Type: multipart/alternative;
	boundary="----=_001_NextPart007376380103_=----"

This is a multi-part message in MIME format.

------=_001_NextPart007376380103_=----
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: base64

SSBhbSBjb25mdXNlZCB3aXRoIGEgcHJvYmxlbToNCkkgaGF2ZSBhIGJsYWRlIHdpdGggNjQgcGh5
c2ljYWwgQ1BVcyBhbmQgNjRHIHBoeXNpY2FsIFJBTSwgYW5kIGRlZmluZWQgb25seSBvbmUgVk0g
d2l0aCAxIENQVSBhbmQgNDBHIFJBTS4NCkZvciB0aGUgZmlyc3QgdGltZSBJIHN0YXJ0ZWQgdGhl
IFZNLCBpdCBqdXN0IHRvb2sgM3MsIEJ1dCBmb3IgdGhlIHNlY29uZCBzdGFydGluZyBpdCB0b29r
IDMwcy4gDQpBZnRlciBzdHVkaWVkIGl0IGJ5IHByaW50aW5nIGxvZywgSSBoYXZlIGxvY2F0ZWQg
YSBwbGFjZSBpbiB0aGUgaHlwZXJ2aXNvciB3aGVyZSBjb3N0IHRvbyBtdWNoIHRpbWUsIA0Kb2Nj
dXBpZWQgOTglIG9mIHRoZSB3aG9sZSBzdGFydGluZyB0aW1lLg0KDQp4ZW4vY29tbW9uL3BhZ2Vf
YWxsb2MuYyANCi8qIEFsbG9jYXRlIDJeQG9yZGVyIGNvbnRpZ3VvdXMgcGFnZXMuICovDQpzdGF0
aWMgc3RydWN0IHBhZ2VfaW5mbyAqYWxsb2NfaGVhcF9wYWdlcygNCiAgICB1bnNpZ25lZCBpbnQg
em9uZV9sbywgdW5zaWduZWQgaW50IHpvbmVfaGksDQogICAgdW5zaWduZWQgaW50IG5vZGUsIHVu
c2lnbmVkIGludCBvcmRlciwgdW5zaWduZWQgaW50IG1lbWZsYWdzKQ0Kew0KICAgICAgICBpZiAo
IHBnW2ldLnUuZnJlZS5uZWVkX3RsYmZsdXNoICkNCiAgICAgICAgew0KICAgICAgICAgICAgLyog
QWRkIGluIGV4dHJhIENQVXMgdGhhdCBuZWVkIGZsdXNoaW5nIGJlY2F1c2Ugb2YgdGhpcyBwYWdl
LiAqLw0KICAgICAgICAgICAgY3B1c19hbmRub3QoZXh0cmFfY3B1c19tYXNrLCBjcHVfb25saW5l
X21hcCwgbWFzayk7DQogICAgICAgICAgICB0bGJmbHVzaF9maWx0ZXIoZXh0cmFfY3B1c19tYXNr
LCBwZ1tpXS50bGJmbHVzaF90aW1lc3RhbXApOw0KICAgICAgICAgICAgY3B1c19vcihtYXNrLCBt
YXNrLCBleHRyYV9jcHVzX21hc2spOw0KICAgICAgICB9DQoNCn0NCg0KMSBpbiB0aGUgZmlyc3Qg
c3RhcnRpbmcsIG1vc3Qgb2YgbmVlZF90bGJmbHVzaD1OVUxMLCBzbyBjb3N0IGxpdHRsZTsgaW4g
dGhlIHNlY29uZCBvbmUsIG1vc3Qgb2YgUkFNIGhhdmUgYmVlbiB1c2VkIA0KICB0aHVzIG1ha2Vz
IG5lZWRfdGxiZmx1c2g9dHJ1ZSwgc28gY29zdCBtdWNoLg0KDQoyIGJ1dCBJIHJlcGVhdGVkIHRo
ZSBzYW1lIGV4cGVyaW1lbnQgaW4gYW5vdGhlciBibGFkZSB3aGljaCBjb250YWlucyAxNiBwaHlz
aWNhbCBDUFVzIGFuZCA2NEcgcGh5c2ljYWwgUkFNLCB0aGUgc2Vjb25kDQogIHN0YXJ0aW5nIGNv
c3QgM3MuIEFmdGVyIEkgdHJhY2VkIHRoZSBwcm9jZXNzIGJldHdlZW4gdGhlIHR3byBzZWNvbmQg
c3RhcnRpbmdzLCBmb3VuZCB0aGF0IGNvdW50IGVudGVyaW5nIGludG8gdGhlIGp1ZGdlbWVudCBv
Zg0KICBwZ1tpXS51LmZyZWUubmVlZF90bGJmbHVzaCBpcyB0aGUgc2FtZSwgYnV0IG51bWJlciBv
ZiBDUFVzIGxlYWRzIHRvIHRoZSBkaWZmZXJlbmNlLg0KDQozIFRoZSBjb2RlIEkgcGFzdGVkIGFp
bXMgdG8gY29tcHV0ZSBhIG1hc2sgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgaXQgc2hvdWxkIGZsdXNo
IENQVSdzIFRMQi4gSSB0cmFjZWQgdGhlIHZhbHVlcyBpbiBzdGFydGluZyBwZXJpb2QgYmVsb3c6
DQoNCmNwdXNfYW5kbm90KGV4dHJhX2NwdXNfbWFzaywgY3B1X29ubGluZV9tYXAsIG1hc2spOw0K
Ly9hZnRlciwgbWFzaz0wLCBjcHVfb25saW5lX21hcD0weEZGRkZGRkZGRkZGRkZGRkYsIGV4dHJh
X2NwdXNfbWFzaz0weEZGRkZGRkZGRkZGRkZGRkYNCnRsYmZsdXNoX2ZpbHRlcihleHRyYV9jcHVz
X21hc2ssIHBnW2ldLnRsYmZsdXNoX3RpbWVzdGFtcCk7DQovL2FmdGVyLCBtYXNrPTAsIGV4dHJh
X2NwdXNfbWFzaz0wDQpjcHVzX29yKG1hc2ssIG1hc2ssIGV4dHJhX2NwdXNfbWFzayk7DQovL2Fm
dGVyLCBtYXNrPTAsIGV4dHJhX2NwdXNfbWFzaz0wDQoNCiAgZXZlcnkgdGltZSBpdCBzdGFydHMg
d2l0aCBtYXNrPTAsIGFuZCBlbmRzIHdpdGggdGhlIHNhbWUgcmVzdWx0IG1hc2s9MCwgc28gbGVh
ZHMgdG8gZmx1c2ggQ1BVJ3MgVExCIGRlZmluaXRlbHksICANCiAgd2hpY2ggc2VlbXMgbWVhbmlu
Z2xlc3MgaW4gdGhlIHN0YXJpbmcgcHJvY2Vzcy4NCg0KNCBUaGUgcHJvYmxlbSBpcywgdGhpcyBz
ZWVtZWQgbWVhbmluZ2xlc3MgY29kZSBpcyB2ZXJ5IHRpbWUtY29uc3VtaW5nLCBDUFVzIGdldCBt
b3JlLCB0aW1lIGNvc3RzIG1vcmUsIGl0IHRha2VzIDMwcyBoZXJlIGluIG15IGJsYWRlDQogIHdp
dGggNjQgQ1BVcyB3aGljaCBtYXkgbmVlZCBzb21lIHNvbHV0aW9uIHRvIGltcHJvdmUgdGhlIGVm
ZmljaWVuY3kuDQogIA0KDQoNCg0KdHVwZW5n

------=_001_NextPart007376380103_=----
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable











I am confused with a problem:


I have a blade with 64 physical CP=
Us and 64G physical RAM, and defined on=
ly one VM with 1 CPU and 40G RAM.<=
/DIV>

For the first time I started the V=
M, it just took 3s, But for the se=
cond starting it took 30s. 


After studied it by printing log, I&nbs=
p;have located a place in the hypervisor&nbs=
p;where cost too much time, 


occupied 98% of the whole starting time=
.


 


xen/common/page_alloc.c 


/* Allocate 2^@order contiguous pages. */

static struct page_info *alloc_heap_pages(


    unsigned int zone_lo, unsigned=
 int zone_hi,


    unsigned int node, unsigned&nb=
sp;int order, unsigned int memflags)


{


        if ( pg[i].=
u.free.need_tlbflush )


        {


           &nb=
sp;/* Add in extra CPUs that need flush=
ing because of this page. */


           &nb=
sp;cpus_andnot(extra_cpus_mask, cpu_online_map, mask);


           &nb=
sp;tlbflush_filter(extra_cpus_mask, pg[i].tlbflush_timestamp);


           &nb=
sp;cpus_or(mask, mask, extra_cpus_mask);


        }


 


}


 


1 in the first starting, most of n=
eed_tlbflush=3DNULL, so cost little; in the =
second one, most of RAM have been used&=
nbsp;


  thus makes need_tlbflush=3Dtrue, so c=
ost much.


 


2 but I repeated the same experiment&nb=
sp;in another blade which contains 16 physic=
al CPUs and 64G physical RAM, the secon=
d


  starting cost 3s. After I traced=
 the=20
process between the two second=20
startings, found that count entering into th=
e judgement=20
of


  pg[i].u.free.need_tlbflush is the same,&nb=
sp;but number of CPUs leads to the diff=
erence.


 


3 The code I pasted aims to comput=
e a mask to determine whether it should=
 flush CPU's TLB. I traced the values&n=
bsp;in starting period below:


 



  
cpus_andnot(extra_cpus_mask, cpu_online_map, mask);

  
//after, mask=3D0, cpu_online_map=3D0xFFFFFFFFFFFFFFFF,&n=
bsp;extra_cpus_mask=3D0xFFFFFFFFFFFFFFFF

  
tlbflush_filter(extra_cpus_mask, pg[i].tlbflush_timestamp);
  
//after, mask=3D0, extra_cpus_mask=3D0

  
cpus_or(mask, mask, extra_cpus_mask);

  
//after, mask=3D0, extra_cpus_mask=3D0


 


  every time it starts with mask=
=3D0, and ends with the same result mas=
k=3D0, so leads to flush CPU's TLB defi=
nitely,  


 =20
which seems meaningless in the staring proce=
ss.


 


4 The problem is, this seemed meaningle=
ss code is very time-consuming, CPUs get&nbs=
p;more, time costs more, it takes 30s h=
ere in my blade


  with 64 CPUs which may need =
;some solution to improve the efficiency.


  





tupeng


------=_001_NextPart007376380103_=------



--===============5297671841591368988==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5297671841591368988==--



From xen-devel-bounces@lists.xen.org Thu Oct 11 15:19:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 15:19:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMKXZ-0000yR-6J; Thu, 11 Oct 2012 15:19:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMKXY-0000yJ-Es
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 15:19:12 +0000
Received: from [85.158.139.211:49901] by server-12.bemta-5.messagelabs.com id
	25/B9-19095-F63E6705; Thu, 11 Oct 2012 15:19:11 +0000
X-Env-Sender: tupeng212@gmail.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1349968748!22010645!1
X-Originating-IP: [209.85.220.45]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_50_60,HTML_MESSAGE,
	MIME_BASE64_TEXT, MIME_BOUND_NEXTPART, ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP, spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28774 invoked from network); 11 Oct 2012 15:19:10 -0000
Received: from mail-pa0-f45.google.com (HELO mail-pa0-f45.google.com)
	(209.85.220.45)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Oct 2012 15:19:10 -0000
Received: by mail-pa0-f45.google.com with SMTP id fb10so1880668pad.32
	for ; Thu, 11 Oct 2012 08:19:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=date:from:to:reply-to:subject:x-priority:x-guid:x-has-attach
	:x-mailer:mime-version:message-id:content-type;
	bh=9e52YfMbYLG9cVIdAiL7L/Jfwq6nFnc7XXI1gCrQvAs=;
	b=djNtWTS3+fhnDwclq0N2MECaJMG985JqBACVk7sjN9STYnYpd8OFPrS9buGQ8+Urth
	EuXvVY0ffqwHDieM5wAdpjGwtMRbIiZeUv87RYgwW7ThXZlylULjG1onq3EoxEq/ENgk
	8dZGFr+F6sD8nqszQsTLpy0gLL0Fusm2+rQwMRdR/76zu4khBsARfWBdKV9Knxfd1xl8
	Hr5yvg5lyiJpsVM7Bn5AGuGuzTfcNfeiGZ8ukRlEj4uZQVsWbhuDxoO26ZJmHu7aSSjD
	07m9szhbs/akGjV7hoR9Cw9qbplKSrwzjiYcO20/S4oS+ThaIqM/Qhsbra7aqoykMcSm
	aUow==
Received: by 10.68.143.162 with SMTP id sf2mr4412618pbb.137.1349968748388;
	Thu, 11 Oct 2012 08:19:08 -0700 (PDT)
Received: from root ([183.128.153.80])
	by mx.google.com with ESMTPS id vw4sm2885754pbc.26.2012.10.11.08.18.52
	(version=SSLv3 cipher=OTHER); Thu, 11 Oct 2012 08:19:06 -0700 (PDT)
Date: Thu, 11 Oct 2012 23:18:52 +0800
From: tupeng212 
To: xen-devel 
X-Priority: 3
X-GUID: 463ADFE7-4216-46E4-9551-A6A65B1E9B97
X-Has-Attach: no
X-Mailer: Foxmail 7.0.1.87[cn]
Mime-Version: 1.0
Message-ID: <201210112318468920764@gmail.com>
Subject: [Xen-devel] alloc_heap_pages is low efficient with more CPUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: tupeng212 
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============5297671841591368988=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.

--===============5297671841591368988==
Content-Type: multipart/alternative;
	boundary="----=_001_NextPart007376380103_=----"

This is a multi-part message in MIME format.

------=_001_NextPart007376380103_=----
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: base64

SSBhbSBjb25mdXNlZCB3aXRoIGEgcHJvYmxlbToNCkkgaGF2ZSBhIGJsYWRlIHdpdGggNjQgcGh5
c2ljYWwgQ1BVcyBhbmQgNjRHIHBoeXNpY2FsIFJBTSwgYW5kIGRlZmluZWQgb25seSBvbmUgVk0g
d2l0aCAxIENQVSBhbmQgNDBHIFJBTS4NCkZvciB0aGUgZmlyc3QgdGltZSBJIHN0YXJ0ZWQgdGhl
IFZNLCBpdCBqdXN0IHRvb2sgM3MsIEJ1dCBmb3IgdGhlIHNlY29uZCBzdGFydGluZyBpdCB0b29r
IDMwcy4gDQpBZnRlciBzdHVkaWVkIGl0IGJ5IHByaW50aW5nIGxvZywgSSBoYXZlIGxvY2F0ZWQg
YSBwbGFjZSBpbiB0aGUgaHlwZXJ2aXNvciB3aGVyZSBjb3N0IHRvbyBtdWNoIHRpbWUsIA0Kb2Nj
dXBpZWQgOTglIG9mIHRoZSB3aG9sZSBzdGFydGluZyB0aW1lLg0KDQp4ZW4vY29tbW9uL3BhZ2Vf
YWxsb2MuYyANCi8qIEFsbG9jYXRlIDJeQG9yZGVyIGNvbnRpZ3VvdXMgcGFnZXMuICovDQpzdGF0
aWMgc3RydWN0IHBhZ2VfaW5mbyAqYWxsb2NfaGVhcF9wYWdlcygNCiAgICB1bnNpZ25lZCBpbnQg
em9uZV9sbywgdW5zaWduZWQgaW50IHpvbmVfaGksDQogICAgdW5zaWduZWQgaW50IG5vZGUsIHVu
c2lnbmVkIGludCBvcmRlciwgdW5zaWduZWQgaW50IG1lbWZsYWdzKQ0Kew0KICAgICAgICBpZiAo
IHBnW2ldLnUuZnJlZS5uZWVkX3RsYmZsdXNoICkNCiAgICAgICAgew0KICAgICAgICAgICAgLyog
QWRkIGluIGV4dHJhIENQVXMgdGhhdCBuZWVkIGZsdXNoaW5nIGJlY2F1c2Ugb2YgdGhpcyBwYWdl
LiAqLw0KICAgICAgICAgICAgY3B1c19hbmRub3QoZXh0cmFfY3B1c19tYXNrLCBjcHVfb25saW5l
X21hcCwgbWFzayk7DQogICAgICAgICAgICB0bGJmbHVzaF9maWx0ZXIoZXh0cmFfY3B1c19tYXNr
LCBwZ1tpXS50bGJmbHVzaF90aW1lc3RhbXApOw0KICAgICAgICAgICAgY3B1c19vcihtYXNrLCBt
YXNrLCBleHRyYV9jcHVzX21hc2spOw0KICAgICAgICB9DQoNCn0NCg0KMSBpbiB0aGUgZmlyc3Qg
c3RhcnRpbmcsIG1vc3Qgb2YgbmVlZF90bGJmbHVzaD1OVUxMLCBzbyBjb3N0IGxpdHRsZTsgaW4g
dGhlIHNlY29uZCBvbmUsIG1vc3Qgb2YgUkFNIGhhdmUgYmVlbiB1c2VkIA0KICB0aHVzIG1ha2Vz
IG5lZWRfdGxiZmx1c2g9dHJ1ZSwgc28gY29zdCBtdWNoLg0KDQoyIGJ1dCBJIHJlcGVhdGVkIHRo
ZSBzYW1lIGV4cGVyaW1lbnQgaW4gYW5vdGhlciBibGFkZSB3aGljaCBjb250YWlucyAxNiBwaHlz
aWNhbCBDUFVzIGFuZCA2NEcgcGh5c2ljYWwgUkFNLCB0aGUgc2Vjb25kDQogIHN0YXJ0aW5nIGNv
c3QgM3MuIEFmdGVyIEkgdHJhY2VkIHRoZSBwcm9jZXNzIGJldHdlZW4gdGhlIHR3byBzZWNvbmQg
c3RhcnRpbmdzLCBmb3VuZCB0aGF0IGNvdW50IGVudGVyaW5nIGludG8gdGhlIGp1ZGdlbWVudCBv
Zg0KICBwZ1tpXS51LmZyZWUubmVlZF90bGJmbHVzaCBpcyB0aGUgc2FtZSwgYnV0IG51bWJlciBv
ZiBDUFVzIGxlYWRzIHRvIHRoZSBkaWZmZXJlbmNlLg0KDQozIFRoZSBjb2RlIEkgcGFzdGVkIGFp
bXMgdG8gY29tcHV0ZSBhIG1hc2sgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgaXQgc2hvdWxkIGZsdXNo
IENQVSdzIFRMQi4gSSB0cmFjZWQgdGhlIHZhbHVlcyBpbiBzdGFydGluZyBwZXJpb2QgYmVsb3c6
DQoNCmNwdXNfYW5kbm90KGV4dHJhX2NwdXNfbWFzaywgY3B1X29ubGluZV9tYXAsIG1hc2spOw0K
Ly9hZnRlciwgbWFzaz0wLCBjcHVfb25saW5lX21hcD0weEZGRkZGRkZGRkZGRkZGRkYsIGV4dHJh
X2NwdXNfbWFzaz0weEZGRkZGRkZGRkZGRkZGRkYNCnRsYmZsdXNoX2ZpbHRlcihleHRyYV9jcHVz
X21hc2ssIHBnW2ldLnRsYmZsdXNoX3RpbWVzdGFtcCk7DQovL2FmdGVyLCBtYXNrPTAsIGV4dHJh
X2NwdXNfbWFzaz0wDQpjcHVzX29yKG1hc2ssIG1hc2ssIGV4dHJhX2NwdXNfbWFzayk7DQovL2Fm
dGVyLCBtYXNrPTAsIGV4dHJhX2NwdXNfbWFzaz0wDQoNCiAgZXZlcnkgdGltZSBpdCBzdGFydHMg
d2l0aCBtYXNrPTAsIGFuZCBlbmRzIHdpdGggdGhlIHNhbWUgcmVzdWx0IG1hc2s9MCwgc28gbGVh
ZHMgdG8gZmx1c2ggQ1BVJ3MgVExCIGRlZmluaXRlbHksICANCiAgd2hpY2ggc2VlbXMgbWVhbmlu
Z2xlc3MgaW4gdGhlIHN0YXJpbmcgcHJvY2Vzcy4NCg0KNCBUaGUgcHJvYmxlbSBpcywgdGhpcyBz
ZWVtZWQgbWVhbmluZ2xlc3MgY29kZSBpcyB2ZXJ5IHRpbWUtY29uc3VtaW5nLCBDUFVzIGdldCBt
b3JlLCB0aW1lIGNvc3RzIG1vcmUsIGl0IHRha2VzIDMwcyBoZXJlIGluIG15IGJsYWRlDQogIHdp
dGggNjQgQ1BVcyB3aGljaCBtYXkgbmVlZCBzb21lIHNvbHV0aW9uIHRvIGltcHJvdmUgdGhlIGVm
ZmljaWVuY3kuDQogIA0KDQoNCg0KdHVwZW5n

------=_001_NextPart007376380103_=----
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable











I am confused with a problem:


I have a blade with 64 physical CP=
Us and 64G physical RAM, and defined on=
ly one VM with 1 CPU and 40G RAM.<=
/DIV>

For the first time I started the V=
M, it just took 3s, But for the se=
cond starting it took 30s. 


After studied it by printing log, I&nbs=
p;have located a place in the hypervisor&nbs=
p;where cost too much time, 


occupied 98% of the whole starting time=
.


 


xen/common/page_alloc.c 


/* Allocate 2^@order contiguous pages. */

static struct page_info *alloc_heap_pages(


    unsigned int zone_lo, unsigned=
 int zone_hi,


    unsigned int node, unsigned&nb=
sp;int order, unsigned int memflags)


{


        if ( pg[i].=
u.free.need_tlbflush )


        {


           &nb=
sp;/* Add in extra CPUs that need flush=
ing because of this page. */


           &nb=
sp;cpus_andnot(extra_cpus_mask, cpu_online_map, mask);


           &nb=
sp;tlbflush_filter(extra_cpus_mask, pg[i].tlbflush_timestamp);


           &nb=
sp;cpus_or(mask, mask, extra_cpus_mask);


        }


 


}


 


1 in the first starting, most of n=
eed_tlbflush=3DNULL, so cost little; in the =
second one, most of RAM have been used&=
nbsp;


  thus makes need_tlbflush=3Dtrue, so c=
ost much.


 


2 but I repeated the same experiment&nb=
sp;in another blade which contains 16 physic=
al CPUs and 64G physical RAM, the secon=
d


  starting cost 3s. After I traced=
 the=20
process between the two second=20
startings, found that count entering into th=
e judgement=20
of


  pg[i].u.free.need_tlbflush is the same,&nb=
sp;but number of CPUs leads to the diff=
erence.


 


3 The code I pasted aims to comput=
e a mask to determine whether it should=
 flush CPU's TLB. I traced the values&n=
bsp;in starting period below:


 



  
cpus_andnot(extra_cpus_mask, cpu_online_map, mask);

  
//after, mask=3D0, cpu_online_map=3D0xFFFFFFFFFFFFFFFF,&n=
bsp;extra_cpus_mask=3D0xFFFFFFFFFFFFFFFF

  
tlbflush_filter(extra_cpus_mask, pg[i].tlbflush_timestamp);
  
//after, mask=3D0, extra_cpus_mask=3D0

  
cpus_or(mask, mask, extra_cpus_mask);

  
//after, mask=3D0, extra_cpus_mask=3D0


 


  every time it starts with mask=
=3D0, and ends with the same result mas=
k=3D0, so leads to flush CPU's TLB defi=
nitely,  


 =20
which seems meaningless in the staring proce=
ss.


 


4 The problem is, this seemed meaningle=
ss code is very time-consuming, CPUs get&nbs=
p;more, time costs more, it takes 30s h=
ere in my blade


  with 64 CPUs which may need =
;some solution to improve the efficiency.


  





tupeng


------=_001_NextPart007376380103_=------



--===============5297671841591368988==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5297671841591368988==--



From xen-devel-bounces@lists.xen.org Thu Oct 11 15:42:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 15:42:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMKtI-0001Gp-LY; Thu, 11 Oct 2012 15:41:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMKtG-0001Gk-KB
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 15:41:39 +0000
Received: from [85.158.139.83:29563] by server-11.bemta-5.messagelabs.com id
	1B/D3-15507-1B8E6705; Thu, 11 Oct 2012 15:41:37 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1349970096!34274922!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	MAILTO_TO_SPAM_ADDR,MIME_QP_LONG_LINE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7901 invoked from network); 11 Oct 2012 15:41:37 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Oct 2012 15:41:37 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so1299833eek.32
	for ; Thu, 11 Oct 2012 08:41:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type;
	bh=3iqEyHlpXAEszFUpjmR5lRnzQQCiMyMLtfw8cFoMQJM=;
	b=RWBUnNTe7NRbMlqn/tPUAPln6dKFogiV0nUwZb6sSlYBKU2qQklfFU5BXASs2ffFaQ
	2rCQLmaH1tN2hCuRlX5RlTTyw86Avouy+5+IMr5r0LAK5tuBl+K3uqwjlT5xoIHh14YO
	fnwyptXPVJ+BwqgPe63+6rCppEdxWIhZBK/jFYjZd91dbv0S+v32hYuT3NYYnuTRz6EQ
	l3M9w1UIMxxUHswil5edoKPmYamJ01CUdtd2h6AoxF9U5n1+i2uBCg1g3R5VHaXY5PKN
	R4tvdHZelIJw8y0byOWY7kS0hPGYkqC3/GY65qsOdtebjdiOnEjN4jBd6MLrMHDFkaZc
	3i+g==
Received: by 10.14.198.133 with SMTP id v5mr2358049een.7.1349970082632;
	Thu, 11 Oct 2012 08:41:22 -0700 (PDT)
Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com.
	[86.183.156.141])
	by mx.google.com with ESMTPS id t1sm7435165eeo.3.2012.10.11.08.41.19
	(version=SSLv3 cipher=OTHER); Thu, 11 Oct 2012 08:41:21 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Thu, 11 Oct 2012 16:41:09 +0100
From: Keir Fraser 
To: tupeng212 ,
	xen-devel 
Message-ID: 
Thread-Topic: [Xen-devel] alloc_heap_pages is low efficient with more CPUs
Thread-Index: Ac2nxtVyq1Ry/EgQ/EKDteC17SNtPA==
In-Reply-To: <201210112318468920764@gmail.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] alloc_heap_pages is low efficient with more CPUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============3492283311836442562=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============3492283311836442562==
Content-type: multipart/alternative;
	boundary="B_3432818480_11120560"

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3432818480_11120560
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Not sure I understand. With 16 CPUs you find domain startup takes 3s always=
.
With 64 CPUs you find it takes 3s first time, then 30s in future? And this
is due to cost of tlbflush_filter() (not actual TLB flushes, because you
always end up with mask=3D0)? If tlbflush_filter() were that expensive I=B9d
expect the 16-CPU case to have slowdown after the first domain startup, too=
.

 -- Keir

On 11/10/2012 16:18, "tupeng212"  wrote:

> I am confused with a problem:
> I have a blade with 64 physical CPUs and 64G physical RAM, and defined on=
ly
> one VM with 1 CPU and 40G RAM.
> For the first time I started the VM, it just took 3s, But for the second
> starting it took 30s.
> After studied it by printing log, I have located a place in the hyperviso=
r
> where cost too much time,
> occupied 98% of the whole starting time.
> =20
> xen/common/page_alloc.c
> /* Allocate 2^@order contiguous pages. */
> static struct page_info *alloc_heap_pages(
>     unsigned int zone_lo, unsigned int zone_hi,
>     unsigned int node, unsigned int order, unsigned int memflags)
> {
>         if ( pg[i].u.free.need_tlbflush )
>         {
>             /* Add in extra CPUs that need flushing because of this page.=
 */
>             cpus_andnot(extra_cpus_mask, cpu_online_map, mask);
>             tlbflush_filter(extra_cpus_mask, pg[i].tlbflush_timestamp);
>             cpus_or(mask, mask, extra_cpus_mask);
>         }
> =20
> }
> =20
> 1 in the first starting, most of need_tlbflush=3DNULL, so cost little; in t=
he
> second one, most of RAM have been used
>   thus makes need_tlbflush=3Dtrue, so cost much.
> =20
> 2 but I repeated the same experiment in another blade which contains 16
> physical CPUs and 64G physical RAM, the second
>   starting cost 3s. After I traced the process between the two second
> startings, found that count entering into the judgement of
>   pg[i].u.free.need_tlbflush is the same, but number of CPUs leads to the
> difference.
> =20
> 3 The code I pasted aims to compute a mask to determine whether it should
> flush CPU's TLB. I traced the values in starting period below:
> =20
>> =20
>> cpus_andnot(extra_cpus_mask, cpu_online_map, mask);
>> =20
>> //after, mask=3D0, cpu_online_map=3D0xFFFFFFFFFFFFFFFF,
>> extra_cpus_mask=3D0xFFFFFFFFFFFFFFFF
>> =20
>> tlbflush_filter(extra_cpus_mask, pg[i].tlbflush_timestamp);
>> =20
>> //after, mask=3D0, extra_cpus_mask=3D0
>> =20
>> cpus_or(mask, mask, extra_cpus_mask);
>> =20
>> //after, mask=3D0, extra_cpus_mask=3D0
> =20
>   every time it starts with mask=3D0, and ends with the same result mask=3D0,=
 so
> leads to flush CPU's TLB definitely,
>   which seems meaningless in the staring process.
> =20
> 4 The problem is, this seemed meaningless code is very time-consuming, CP=
Us
> get more, time costs more, it takes 30s here in my blade
>   with 64 CPUs which may need some solution to improve the efficiency.
>  =20
>=20
> tupeng
>=20
>=20
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


--B_3432818480_11120560
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable



Re: [Xen-devel] alloc_heap_pages is low efficient with more CPUs</TI=
TLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>Not sure I understand. With 16 CPUs you find domain startup takes 3s alway=
s. With 64 CPUs you find it takes 3s first time, then 30s in future? And thi=
s is due to cost of tlbflush_filter() (not actual TLB flushes, because you a=
lways end up with mask=3D0)? If tlbflush_filter() were that expensive I’=
d expect the 16-CPU case to have slowdown after the first domain startup, to=
o.<BR>
<BR>
 -- Keir<BR>
<BR>
On 11/10/2012 16:18, "tupeng212" <<a href=3D"tupeng212@gmail.com=
">tupeng212@gmail.com</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'>I am confused with a problem:<BR>
I have a blade with 64 physical CPUs and 64G physical RAM, and defined only=
 one VM with 1 CPU and 40G RAM.<BR>
For the first time I started the VM, it just took 3s, But for the second st=
arting it took 30s. <BR>
After studied it by printing log, I have located a place in the hypervisor =
where cost too much time, <BR>
occupied 98% of the whole starting time.<BR>
 <BR>
xen/common/page_alloc.c <BR>
/* Allocate 2^@order contiguous pages. */<BR>
static struct page_info *alloc_heap_pages(<BR>
    unsigned int zone_lo, unsigned int zone_hi,<BR>
    unsigned int node, unsigned int order, unsigned int=
 memflags)<BR>
{<BR>
        if ( pg[i].u.free.need_tlbf=
lush )<BR>
        {<BR>
            /* =
Add in extra CPUs that need flushing because of this page. */<BR>
            cpu=
s_andnot(extra_cpus_mask, cpu_online_map, mask);<BR>
            tlb=
flush_filter(extra_cpus_mask, pg[i].tlbflush_timestamp);<BR>
            cpu=
s_or(mask, mask, extra_cpus_mask);<BR>
        }<BR>
 <BR>
}<BR>
 <BR>
1 in the first starting, most of need_tlbflush=3DNULL, so cost little; in the=
 second one, most of RAM have been used <BR>
  thus makes need_tlbflush=3Dtrue, so cost much.<BR>
 <BR>
2 but I repeated the same experiment in another blade which contains 16 phy=
sical CPUs and 64G physical RAM, the second<BR>
  starting cost 3s. After I traced the process between the two se=
cond startings, found that count entering into the judgement of<BR>
  pg[i].u.free.need_tlbflush is the same, but number of CPUs lead=
s to the difference.<BR>
 <BR>
3 The code I pasted aims to compute a mask to determine whether it should f=
lush CPU's TLB. I traced the values in starting period below:<BR>
 <BR>
</SPAN></FONT></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, A=
rial"><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'> <BR>
cpus_andnot(extra_cpus_mask, cpu_online_map, mask);<BR>
 <BR>
//after, mask=3D0, cpu_online_map=3D0xFFFFFFFFFFFFFFFF, extra_cpus_mask=3D0xFFFFF=
FFFFFFFFFFF<BR>
 <BR>
tlbflush_filter(extra_cpus_mask, pg[i].tlbflush_timestamp);<BR>
 <BR>
//after, mask=3D0, extra_cpus_mask=3D0<BR>
 <BR>
cpus_or(mask, mask, extra_cpus_mask);<BR>
 <BR>
//after, mask=3D0, extra_cpus_mask=3D0<BR>
</SPAN></FONT></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, =
Arial"><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'> <BR>
  every time it starts with mask=3D0, and ends with the same result=
 mask=3D0, so leads to flush CPU's TLB definitely,  <BR>
  which seems meaningless in the staring process.<BR>
 <BR>
4 The problem is, this seemed meaningless code is very time-consuming, CPUs=
 get more, time costs more, it takes 30s here in my blade<BR>
  with 64 CPUs which may need some solution to improve the effici=
ency.<BR>
  <BR>
<HR ALIGN=3DLEFT SIZE=3D"1" WIDTH=3D"100%">tupeng<BR>
<BR>
<HR ALIGN=3DCENTER SIZE=3D"3" WIDTH=3D"95%"></SPAN></FONT></FONT><FONT SIZE=3D"2"><=
SPAN STYLE=3D'font-size:10pt'><FONT FACE=3D"Consolas, Courier New, Courier">____=
___________________________________________<BR>
Xen-devel mailing list<BR>
<a href=3D"Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a><BR>
<a href=3D"http://lists.xen.org/xen-devel">http://lists.xen.org/xen-devel</a>=
<BR>
</FONT></SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--B_3432818480_11120560--




--===============3492283311836442562==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3492283311836442562==--




From xen-devel-bounces@lists.xen.org Thu Oct 11 15:42:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 15:42:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMKtI-0001Gp-LY; Thu, 11 Oct 2012 15:41:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TMKtG-0001Gk-KB
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 15:41:39 +0000
Received: from [85.158.139.83:29563] by server-11.bemta-5.messagelabs.com id
	1B/D3-15507-1B8E6705; Thu, 11 Oct 2012 15:41:37 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1349970096!34274922!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	MAILTO_TO_SPAM_ADDR,MIME_QP_LONG_LINE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7901 invoked from network); 11 Oct 2012 15:41:37 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Oct 2012 15:41:37 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so1299833eek.32
	for <xen-devel@lists.xen.org>; Thu, 11 Oct 2012 08:41:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type;
	bh=3iqEyHlpXAEszFUpjmR5lRnzQQCiMyMLtfw8cFoMQJM=;
	b=RWBUnNTe7NRbMlqn/tPUAPln6dKFogiV0nUwZb6sSlYBKU2qQklfFU5BXASs2ffFaQ
	2rCQLmaH1tN2hCuRlX5RlTTyw86Avouy+5+IMr5r0LAK5tuBl+K3uqwjlT5xoIHh14YO
	fnwyptXPVJ+BwqgPe63+6rCppEdxWIhZBK/jFYjZd91dbv0S+v32hYuT3NYYnuTRz6EQ
	l3M9w1UIMxxUHswil5edoKPmYamJ01CUdtd2h6AoxF9U5n1+i2uBCg1g3R5VHaXY5PKN
	R4tvdHZelIJw8y0byOWY7kS0hPGYkqC3/GY65qsOdtebjdiOnEjN4jBd6MLrMHDFkaZc
	3i+g==
Received: by 10.14.198.133 with SMTP id v5mr2358049een.7.1349970082632;
	Thu, 11 Oct 2012 08:41:22 -0700 (PDT)
Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com.
	[86.183.156.141])
	by mx.google.com with ESMTPS id t1sm7435165eeo.3.2012.10.11.08.41.19
	(version=SSLv3 cipher=OTHER); Thu, 11 Oct 2012 08:41:21 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Thu, 11 Oct 2012 16:41:09 +0100
From: Keir Fraser <keir@xen.org>
To: tupeng212 <tupeng212@gmail.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC9CA725.4EB45%keir@xen.org>
Thread-Topic: [Xen-devel] alloc_heap_pages is low efficient with more CPUs
Thread-Index: Ac2nxtVyq1Ry/EgQ/EKDteC17SNtPA==
In-Reply-To: <201210112318468920764@gmail.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] alloc_heap_pages is low efficient with more CPUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3492283311836442562=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============3492283311836442562==
Content-type: multipart/alternative;
	boundary="B_3432818480_11120560"

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3432818480_11120560
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Not sure I understand. With 16 CPUs you find domain startup takes 3s always=
.
With 64 CPUs you find it takes 3s first time, then 30s in future? And this
is due to cost of tlbflush_filter() (not actual TLB flushes, because you
always end up with mask=3D0)? If tlbflush_filter() were that expensive I=B9d
expect the 16-CPU case to have slowdown after the first domain startup, too=
.

 -- Keir

On 11/10/2012 16:18, "tupeng212" <tupeng212@gmail.com> wrote:

> I am confused with a problem:
> I have a blade with 64 physical CPUs and 64G physical RAM, and defined on=
ly
> one VM with 1 CPU and 40G RAM.
> For the first time I started the VM, it just took 3s, But for the second
> starting it took 30s.
> After studied it by printing log, I have located a place in the hyperviso=
r
> where cost too much time,
> occupied 98% of the whole starting time.
> =20
> xen/common/page_alloc.c
> /* Allocate 2^@order contiguous pages. */
> static struct page_info *alloc_heap_pages(
>     unsigned int zone_lo, unsigned int zone_hi,
>     unsigned int node, unsigned int order, unsigned int memflags)
> {
>         if ( pg[i].u.free.need_tlbflush )
>         {
>             /* Add in extra CPUs that need flushing because of this page.=
 */
>             cpus_andnot(extra_cpus_mask, cpu_online_map, mask);
>             tlbflush_filter(extra_cpus_mask, pg[i].tlbflush_timestamp);
>             cpus_or(mask, mask, extra_cpus_mask);
>         }
> =20
> }
> =20
> 1 in the first starting, most of need_tlbflush=3DNULL, so cost little; in t=
he
> second one, most of RAM have been used
>   thus makes need_tlbflush=3Dtrue, so cost much.
> =20
> 2 but I repeated the same experiment in another blade which contains 16
> physical CPUs and 64G physical RAM, the second
>   starting cost 3s. After I traced the process between the two second
> startings, found that count entering into the judgement of
>   pg[i].u.free.need_tlbflush is the same, but number of CPUs leads to the
> difference.
> =20
> 3 The code I pasted aims to compute a mask to determine whether it should
> flush CPU's TLB. I traced the values in starting period below:
> =20
>> =20
>> cpus_andnot(extra_cpus_mask, cpu_online_map, mask);
>> =20
>> //after, mask=3D0, cpu_online_map=3D0xFFFFFFFFFFFFFFFF,
>> extra_cpus_mask=3D0xFFFFFFFFFFFFFFFF
>> =20
>> tlbflush_filter(extra_cpus_mask, pg[i].tlbflush_timestamp);
>> =20
>> //after, mask=3D0, extra_cpus_mask=3D0
>> =20
>> cpus_or(mask, mask, extra_cpus_mask);
>> =20
>> //after, mask=3D0, extra_cpus_mask=3D0
> =20
>   every time it starts with mask=3D0, and ends with the same result mask=3D0,=
 so
> leads to flush CPU's TLB definitely,
>   which seems meaningless in the staring process.
> =20
> 4 The problem is, this seemed meaningless code is very time-consuming, CP=
Us
> get more, time costs more, it takes 30s here in my blade
>   with 64 CPUs which may need some solution to improve the efficiency.
>  =20
>=20
> tupeng
>=20
>=20
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


--B_3432818480_11120560
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [Xen-devel] alloc_heap_pages is low efficient with more CPUs</TI=
TLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>Not sure I understand. With 16 CPUs you find domain startup takes 3s alway=
s. With 64 CPUs you find it takes 3s first time, then 30s in future? And thi=
s is due to cost of tlbflush_filter() (not actual TLB flushes, because you a=
lways end up with mask=3D0)? If tlbflush_filter() were that expensive I’=
d expect the 16-CPU case to have slowdown after the first domain startup, to=
o.<BR>
<BR>
 -- Keir<BR>
<BR>
On 11/10/2012 16:18, "tupeng212" <<a href=3D"tupeng212@gmail.com=
">tupeng212@gmail.com</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'>I am confused with a problem:<BR>
I have a blade with 64 physical CPUs and 64G physical RAM, and defined only=
 one VM with 1 CPU and 40G RAM.<BR>
For the first time I started the VM, it just took 3s, But for the second st=
arting it took 30s. <BR>
After studied it by printing log, I have located a place in the hypervisor =
where cost too much time, <BR>
occupied 98% of the whole starting time.<BR>
 <BR>
xen/common/page_alloc.c <BR>
/* Allocate 2^@order contiguous pages. */<BR>
static struct page_info *alloc_heap_pages(<BR>
    unsigned int zone_lo, unsigned int zone_hi,<BR>
    unsigned int node, unsigned int order, unsigned int=
 memflags)<BR>
{<BR>
        if ( pg[i].u.free.need_tlbf=
lush )<BR>
        {<BR>
            /* =
Add in extra CPUs that need flushing because of this page. */<BR>
            cpu=
s_andnot(extra_cpus_mask, cpu_online_map, mask);<BR>
            tlb=
flush_filter(extra_cpus_mask, pg[i].tlbflush_timestamp);<BR>
            cpu=
s_or(mask, mask, extra_cpus_mask);<BR>
        }<BR>
 <BR>
}<BR>
 <BR>
1 in the first starting, most of need_tlbflush=3DNULL, so cost little; in the=
 second one, most of RAM have been used <BR>
  thus makes need_tlbflush=3Dtrue, so cost much.<BR>
 <BR>
2 but I repeated the same experiment in another blade which contains 16 phy=
sical CPUs and 64G physical RAM, the second<BR>
  starting cost 3s. After I traced the process between the two se=
cond startings, found that count entering into the judgement of<BR>
  pg[i].u.free.need_tlbflush is the same, but number of CPUs lead=
s to the difference.<BR>
 <BR>
3 The code I pasted aims to compute a mask to determine whether it should f=
lush CPU's TLB. I traced the values in starting period below:<BR>
 <BR>
</SPAN></FONT></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, A=
rial"><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'> <BR>
cpus_andnot(extra_cpus_mask, cpu_online_map, mask);<BR>
 <BR>
//after, mask=3D0, cpu_online_map=3D0xFFFFFFFFFFFFFFFF, extra_cpus_mask=3D0xFFFFF=
FFFFFFFFFFF<BR>
 <BR>
tlbflush_filter(extra_cpus_mask, pg[i].tlbflush_timestamp);<BR>
 <BR>
//after, mask=3D0, extra_cpus_mask=3D0<BR>
 <BR>
cpus_or(mask, mask, extra_cpus_mask);<BR>
 <BR>
//after, mask=3D0, extra_cpus_mask=3D0<BR>
</SPAN></FONT></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, =
Arial"><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'> <BR>
  every time it starts with mask=3D0, and ends with the same result=
 mask=3D0, so leads to flush CPU's TLB definitely,  <BR>
  which seems meaningless in the staring process.<BR>
 <BR>
4 The problem is, this seemed meaningless code is very time-consuming, CPUs=
 get more, time costs more, it takes 30s here in my blade<BR>
  with 64 CPUs which may need some solution to improve the effici=
ency.<BR>
  <BR>
<HR ALIGN=3DLEFT SIZE=3D"1" WIDTH=3D"100%">tupeng<BR>
<BR>
<HR ALIGN=3DCENTER SIZE=3D"3" WIDTH=3D"95%"></SPAN></FONT></FONT><FONT SIZE=3D"2"><=
SPAN STYLE=3D'font-size:10pt'><FONT FACE=3D"Consolas, Courier New, Courier">____=
___________________________________________<BR>
Xen-devel mailing list<BR>
<a href=3D"Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a><BR>
<a href=3D"http://lists.xen.org/xen-devel">http://lists.xen.org/xen-devel</a>=
<BR>
</FONT></SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--B_3432818480_11120560--




--===============3492283311836442562==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3492283311836442562==--




From xen-devel-bounces@lists.xen.org Thu Oct 11 16:50:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 16:50:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMLwy-0001xD-Vk; Thu, 11 Oct 2012 16:49:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jseward@acm.org>) id 1TMLqF-0001w7-FY
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 16:42:35 +0000
Received: from [85.158.143.99:32026] by server-3.bemta-4.messagelabs.com id
	C4/10-10075-AF6F6705; Thu, 11 Oct 2012 16:42:34 +0000
X-Env-Sender: jseward@acm.org
X-Msg-Ref: server-14.tower-216.messagelabs.com!1349973753!24159862!1
X-Originating-IP: [67.58.97.34]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30237 invoked from network); 11 Oct 2012 16:42:33 -0000
Received: from server.rebelnetworks.com (HELO server.rebelnetworks.com)
	(67.58.97.34)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Oct 2012 16:42:33 -0000
Received: from p4fd6701c.dip.t-dialin.net ([79.214.112.28]:44190
	helo=phoenix.localnet)
	by server.rebelnetworks.com with esmtpa (Exim 4.77)
	(envelope-from <jseward@acm.org>)
	id 1TMLpy-0003Ym-RH; Thu, 11 Oct 2012 12:42:19 -0400
From: Julian Seward <jseward@acm.org>
To: valgrind-developers@lists.sourceforge.net
Date: Thu, 11 Oct 2012 18:36:53 +0200
User-Agent: KMail/1.13.5 (Linux/2.6.32-41-generic; KDE/4.4.5; x86_64; ; )
References: <1349696046.18008.116.camel@zakaz.uk.xensource.com>
	<1349696067-4273-1-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1349696067-4273-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Message-Id: <201210111836.53184.jseward@acm.org>
X-Rebelnetworks-MailScanner-Information: Please contact the ISP for more
	information
X-Rebelnetworks-MailScanner-ID: 1TMLpy-0003Ym-RH
X-Rebelnetworks-MailScanner: Not scanned: please contact your Internet E-Mail
	Service Provider for details
X-Rebelnetworks-MailScanner-SpamCheck: 
X-Rebelnetworks-MailScanner-From: jseward@acm.org
X-Spam-Status: No
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.rebelnetworks.com
X-AntiAbuse: Original Domain - lists.xen.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - acm.org
X-Mailman-Approved-At: Thu, 11 Oct 2012 16:49:31 +0000
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Valgrind-developers] [PATCH 1/4] Useful messages
	for sys/domctl interface_version mismatch.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Please: file a bug report and attach the patches to it.  Else they
are pretty much guaranteed to wind up at /dev/null, because nobody
tracks patches on the list AFAIK.

J


On Monday, October 08, 2012, Ian Campbell wrote:
> ---
>  coregrind/m_syswrap/syswrap-xen.c |   52
> ++++++++++++++++++++++++++++++++----- 1 files changed, 45 insertions(+), 7
> deletions(-)
> 
> diff --git a/coregrind/m_syswrap/syswrap-xen.c
> b/coregrind/m_syswrap/syswrap-xen.c index 00192bf..6226f7e 100644
> --- a/coregrind/m_syswrap/syswrap-xen.c
> +++ b/coregrind/m_syswrap/syswrap-xen.c
> @@ -59,6 +59,7 @@
>  #include "priv_syswrap-xen.h"
> 
>  #include <stdint.h>
> +#include <inttypes.h>
> 
>  #define __XEN_TOOLS__
> 
> @@ -353,9 +354,26 @@ PRE(sysctl) {
>     PRE_MEM_READ("__HYPERVISOR_sysctl", ARG1,
>                  sizeof(uint32_t) + sizeof(uint32_t));
> 
> -   if (!sysctl || sysctl->interface_version !=
> XEN_SYSCTL_INTERFACE_VERSION) -      /* BUG ? */
> +   if (!sysctl)
> +      return;
> +
> +   if (sysctl->interface_version != XEN_SYSCTL_INTERFACE_VERSION) {
> +      VG_(dmsg)("WARNING: sysctl version %"PRIx32" not supported, "
> +                "built for %"PRIx32"\n",
> +                sysctl->interface_version,
> +                XEN_SYSCTL_INTERFACE_VERSION);
> +      if (VG_(clo_verbosity) > 1) {
> +         VG_(get_and_pp_StackTrace)(tid, VG_(clo_backtrace_size));
> +      }
> +      VG_(dmsg)("You may be able to write your own handler.\n");
> +      VG_(dmsg)("Read the file README_MISSING_SYSCALL_OR_IOCTL.\n");
> +      VG_(dmsg)("Nevertheless we consider this a bug.  Please report\n");
> +      VG_(dmsg)("it at http://valgrind.org/support/bug_reports.html &\n");
> +      VG_(dmsg)("http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen.\n");
> +
> +      SET_STATUS_Failure(VKI_EINVAL);
>        return;
> +   }
> 
>  #define __PRE_XEN_SYSCTL_READ(_sysctl, _union, _field)  \
>        PRE_MEM_READ("XEN_SYSCTL_" # _sysctl,             \
> @@ -438,9 +456,26 @@ PRE(domctl)
>     PRE_MEM_READ("__HYPERVISOR_domctl", ARG1,
>                  sizeof(uint32_t) + sizeof(uint32_t) + sizeof(domid_t));
> 
> -   if (!domctl || domctl->interface_version !=
> XEN_DOMCTL_INTERFACE_VERSION) -      /* BUG ? */
> +   if (!domctl)
> +      return;
> +
> +   if (domctl->interface_version != XEN_DOMCTL_INTERFACE_VERSION) {
> +      VG_(dmsg)("WARNING: domctl version %"PRIx32" not supported, "
> +                "built for %"PRIx32"\n",
> +                domctl->interface_version,
> +                XEN_DOMCTL_INTERFACE_VERSION);
> +      if (VG_(clo_verbosity) > 1) {
> +         VG_(get_and_pp_StackTrace)(tid, VG_(clo_backtrace_size));
> +      }
> +      VG_(dmsg)("You may be able to write your own handler.\n");
> +      VG_(dmsg)("Read the file README_MISSING_SYSCALL_OR_IOCTL.\n");
> +      VG_(dmsg)("Nevertheless we consider this a bug.  Please report\n");
> +      VG_(dmsg)("it at http://valgrind.org/support/bug_reports.html &\n");
> +      VG_(dmsg)("http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen.\n");
> +
> +      SET_STATUS_Failure(VKI_EINVAL);
>        return;
> +   }
> 
>  #define __PRE_XEN_DOMCTL_READ(_domctl, _union, _field)  \
>        PRE_MEM_READ("XEN_DOMCTL_" # _domctl,             \
> @@ -740,11 +775,14 @@ POST(sysctl)
> 
>     case XEN_SYSCTL_topologyinfo:
>        POST_XEN_SYSCTL_WRITE(topologyinfo, max_cpu_index);
> -      POST_MEM_WRITE((Addr)sysctl->u.topologyinfo.cpu_to_core.p,
> +      if (sysctl->u.topologyinfo.cpu_to_core.p)
> +         POST_MEM_WRITE((Addr)sysctl->u.topologyinfo.cpu_to_core.p,
>                       sizeof(uint32_t) *
> sysctl->u.topologyinfo.max_cpu_index); -     
> POST_MEM_WRITE((Addr)sysctl->u.topologyinfo.cpu_to_socket.p, +      if
> (sysctl->u.topologyinfo.cpu_to_socket.p)
> +         POST_MEM_WRITE((Addr)sysctl->u.topologyinfo.cpu_to_socket.p,
>                       sizeof(uint32_t) *
> sysctl->u.topologyinfo.max_cpu_index); -     
> POST_MEM_WRITE((Addr)sysctl->u.topologyinfo.cpu_to_node.p,
> +      if (sysctl->u.topologyinfo.cpu_to_node.p)
> +         POST_MEM_WRITE((Addr)sysctl->u.topologyinfo.cpu_to_node.p,
>                       sizeof(uint32_t) *
> sysctl->u.topologyinfo.max_cpu_index); break;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 16:50:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 16:50:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMLwy-0001xD-Vk; Thu, 11 Oct 2012 16:49:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jseward@acm.org>) id 1TMLqF-0001w7-FY
	for xen-devel@lists.xen.org; Thu, 11 Oct 2012 16:42:35 +0000
Received: from [85.158.143.99:32026] by server-3.bemta-4.messagelabs.com id
	C4/10-10075-AF6F6705; Thu, 11 Oct 2012 16:42:34 +0000
X-Env-Sender: jseward@acm.org
X-Msg-Ref: server-14.tower-216.messagelabs.com!1349973753!24159862!1
X-Originating-IP: [67.58.97.34]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30237 invoked from network); 11 Oct 2012 16:42:33 -0000
Received: from server.rebelnetworks.com (HELO server.rebelnetworks.com)
	(67.58.97.34)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Oct 2012 16:42:33 -0000
Received: from p4fd6701c.dip.t-dialin.net ([79.214.112.28]:44190
	helo=phoenix.localnet)
	by server.rebelnetworks.com with esmtpa (Exim 4.77)
	(envelope-from <jseward@acm.org>)
	id 1TMLpy-0003Ym-RH; Thu, 11 Oct 2012 12:42:19 -0400
From: Julian Seward <jseward@acm.org>
To: valgrind-developers@lists.sourceforge.net
Date: Thu, 11 Oct 2012 18:36:53 +0200
User-Agent: KMail/1.13.5 (Linux/2.6.32-41-generic; KDE/4.4.5; x86_64; ; )
References: <1349696046.18008.116.camel@zakaz.uk.xensource.com>
	<1349696067-4273-1-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1349696067-4273-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Message-Id: <201210111836.53184.jseward@acm.org>
X-Rebelnetworks-MailScanner-Information: Please contact the ISP for more
	information
X-Rebelnetworks-MailScanner-ID: 1TMLpy-0003Ym-RH
X-Rebelnetworks-MailScanner: Not scanned: please contact your Internet E-Mail
	Service Provider for details
X-Rebelnetworks-MailScanner-SpamCheck: 
X-Rebelnetworks-MailScanner-From: jseward@acm.org
X-Spam-Status: No
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.rebelnetworks.com
X-AntiAbuse: Original Domain - lists.xen.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - acm.org
X-Mailman-Approved-At: Thu, 11 Oct 2012 16:49:31 +0000
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Valgrind-developers] [PATCH 1/4] Useful messages
	for sys/domctl interface_version mismatch.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Please: file a bug report and attach the patches to it.  Else they
are pretty much guaranteed to wind up at /dev/null, because nobody
tracks patches on the list AFAIK.

J


On Monday, October 08, 2012, Ian Campbell wrote:
> ---
>  coregrind/m_syswrap/syswrap-xen.c |   52
> ++++++++++++++++++++++++++++++++----- 1 files changed, 45 insertions(+), 7
> deletions(-)
> 
> diff --git a/coregrind/m_syswrap/syswrap-xen.c
> b/coregrind/m_syswrap/syswrap-xen.c index 00192bf..6226f7e 100644
> --- a/coregrind/m_syswrap/syswrap-xen.c
> +++ b/coregrind/m_syswrap/syswrap-xen.c
> @@ -59,6 +59,7 @@
>  #include "priv_syswrap-xen.h"
> 
>  #include <stdint.h>
> +#include <inttypes.h>
> 
>  #define __XEN_TOOLS__
> 
> @@ -353,9 +354,26 @@ PRE(sysctl) {
>     PRE_MEM_READ("__HYPERVISOR_sysctl", ARG1,
>                  sizeof(uint32_t) + sizeof(uint32_t));
> 
> -   if (!sysctl || sysctl->interface_version !=
> XEN_SYSCTL_INTERFACE_VERSION) -      /* BUG ? */
> +   if (!sysctl)
> +      return;
> +
> +   if (sysctl->interface_version != XEN_SYSCTL_INTERFACE_VERSION) {
> +      VG_(dmsg)("WARNING: sysctl version %"PRIx32" not supported, "
> +                "built for %"PRIx32"\n",
> +                sysctl->interface_version,
> +                XEN_SYSCTL_INTERFACE_VERSION);
> +      if (VG_(clo_verbosity) > 1) {
> +         VG_(get_and_pp_StackTrace)(tid, VG_(clo_backtrace_size));
> +      }
> +      VG_(dmsg)("You may be able to write your own handler.\n");
> +      VG_(dmsg)("Read the file README_MISSING_SYSCALL_OR_IOCTL.\n");
> +      VG_(dmsg)("Nevertheless we consider this a bug.  Please report\n");
> +      VG_(dmsg)("it at http://valgrind.org/support/bug_reports.html &\n");
> +      VG_(dmsg)("http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen.\n");
> +
> +      SET_STATUS_Failure(VKI_EINVAL);
>        return;
> +   }
> 
>  #define __PRE_XEN_SYSCTL_READ(_sysctl, _union, _field)  \
>        PRE_MEM_READ("XEN_SYSCTL_" # _sysctl,             \
> @@ -438,9 +456,26 @@ PRE(domctl)
>     PRE_MEM_READ("__HYPERVISOR_domctl", ARG1,
>                  sizeof(uint32_t) + sizeof(uint32_t) + sizeof(domid_t));
> 
> -   if (!domctl || domctl->interface_version !=
> XEN_DOMCTL_INTERFACE_VERSION) -      /* BUG ? */
> +   if (!domctl)
> +      return;
> +
> +   if (domctl->interface_version != XEN_DOMCTL_INTERFACE_VERSION) {
> +      VG_(dmsg)("WARNING: domctl version %"PRIx32" not supported, "
> +                "built for %"PRIx32"\n",
> +                domctl->interface_version,
> +                XEN_DOMCTL_INTERFACE_VERSION);
> +      if (VG_(clo_verbosity) > 1) {
> +         VG_(get_and_pp_StackTrace)(tid, VG_(clo_backtrace_size));
> +      }
> +      VG_(dmsg)("You may be able to write your own handler.\n");
> +      VG_(dmsg)("Read the file README_MISSING_SYSCALL_OR_IOCTL.\n");
> +      VG_(dmsg)("Nevertheless we consider this a bug.  Please report\n");
> +      VG_(dmsg)("it at http://valgrind.org/support/bug_reports.html &\n");
> +      VG_(dmsg)("http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen.\n");
> +
> +      SET_STATUS_Failure(VKI_EINVAL);
>        return;
> +   }
> 
>  #define __PRE_XEN_DOMCTL_READ(_domctl, _union, _field)  \
>        PRE_MEM_READ("XEN_DOMCTL_" # _domctl,             \
> @@ -740,11 +775,14 @@ POST(sysctl)
> 
>     case XEN_SYSCTL_topologyinfo:
>        POST_XEN_SYSCTL_WRITE(topologyinfo, max_cpu_index);
> -      POST_MEM_WRITE((Addr)sysctl->u.topologyinfo.cpu_to_core.p,
> +      if (sysctl->u.topologyinfo.cpu_to_core.p)
> +         POST_MEM_WRITE((Addr)sysctl->u.topologyinfo.cpu_to_core.p,
>                       sizeof(uint32_t) *
> sysctl->u.topologyinfo.max_cpu_index); -     
> POST_MEM_WRITE((Addr)sysctl->u.topologyinfo.cpu_to_socket.p, +      if
> (sysctl->u.topologyinfo.cpu_to_socket.p)
> +         POST_MEM_WRITE((Addr)sysctl->u.topologyinfo.cpu_to_socket.p,
>                       sizeof(uint32_t) *
> sysctl->u.topologyinfo.max_cpu_index); -     
> POST_MEM_WRITE((Addr)sysctl->u.topologyinfo.cpu_to_node.p,
> +      if (sysctl->u.topologyinfo.cpu_to_node.p)
> +         POST_MEM_WRITE((Addr)sysctl->u.topologyinfo.cpu_to_node.p,
>                       sizeof(uint32_t) *
> sysctl->u.topologyinfo.max_cpu_index); break;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 19:19:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 19:19:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMOHv-0002rT-7Z; Thu, 11 Oct 2012 19:19:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TMOHt-0002rO-0y
	for xen-devel@lists.xensource.com; Thu, 11 Oct 2012 19:19:17 +0000
Received: from [85.158.143.35:5369] by server-2.bemta-4.messagelabs.com id
	F7/B6-25171-4BB17705; Thu, 11 Oct 2012 19:19:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1349983155!14668832!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM5ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7420 invoked from network); 11 Oct 2012 19:19:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Oct 2012 19:19:15 -0000
X-IronPort-AV: E=Sophos;i="4.80,573,1344211200"; d="scan'208";a="15109383"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Oct 2012 19:19:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 11 Oct 2012 20:19:16 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1TMOHr-0006pj-De;
	Thu, 11 Oct 2012 19:19:15 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TMOHr-00076g-7V;
	Thu, 11 Oct 2012 20:19:15 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13953-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 11 Oct 2012 20:19:15 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13953: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13953 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13953/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13951
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13951
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13951
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13951

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  b91f57f54f47
baseline version:
 xen                  3696dd6a7836

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Olaf Hering <olaf@aepfle.de>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  Sander Eikelenboom <linux@eikelenboom.it>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=b91f57f54f47
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable b91f57f54f47
+ branch=xen-unstable
+ revision=b91f57f54f47
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r b91f57f54f47 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 4 changesets with 8 changes to 7 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 19:19:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 19:19:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMOHv-0002rT-7Z; Thu, 11 Oct 2012 19:19:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TMOHt-0002rO-0y
	for xen-devel@lists.xensource.com; Thu, 11 Oct 2012 19:19:17 +0000
Received: from [85.158.143.35:5369] by server-2.bemta-4.messagelabs.com id
	F7/B6-25171-4BB17705; Thu, 11 Oct 2012 19:19:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1349983155!14668832!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM5ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7420 invoked from network); 11 Oct 2012 19:19:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Oct 2012 19:19:15 -0000
X-IronPort-AV: E=Sophos;i="4.80,573,1344211200"; d="scan'208";a="15109383"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Oct 2012 19:19:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 11 Oct 2012 20:19:16 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1TMOHr-0006pj-De;
	Thu, 11 Oct 2012 19:19:15 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TMOHr-00076g-7V;
	Thu, 11 Oct 2012 20:19:15 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13953-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 11 Oct 2012 20:19:15 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13953: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13953 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13953/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13951
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13951
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13951
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13951

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  b91f57f54f47
baseline version:
 xen                  3696dd6a7836

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Olaf Hering <olaf@aepfle.de>
  Samuel Thibault <samuel.thibault@ens-lyon.org>
  Sander Eikelenboom <linux@eikelenboom.it>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=b91f57f54f47
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable b91f57f54f47
+ branch=xen-unstable
+ revision=b91f57f54f47
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r b91f57f54f47 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 4 changesets with 8 changes to 7 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 21:50:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 21:50:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMQdS-0003rt-U2; Thu, 11 Oct 2012 21:49:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1TMQdR-0003ro-7b
	for Xen-devel@lists.xensource.com; Thu, 11 Oct 2012 21:49:41 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1349992173!11025492!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzk3Njc3\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29860 invoked from network); 11 Oct 2012 21:49:35 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Oct 2012 21:49:35 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9BLnWtU010201
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 11 Oct 2012 21:49:33 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9BLnVuh016937
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 11 Oct 2012 21:49:32 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9BLnVFx014545; Thu, 11 Oct 2012 16:49:31 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 11 Oct 2012 14:49:31 -0700
Date: Thu, 11 Oct 2012 14:49:29 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	linux-kernel@vger.kernel.org
Message-ID: <20121011144929.06e71a9e@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Subject: [Xen-devel] [PATCH V2 0/7]: PVH: PV guest with extensions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi guys,

Ok, I've made all the changes from prev RFC patch submissions. Tested
all the combinations. The patches are organized slightly differently
from prev version because of the nature of changes after last review. I
am building xen patch just for the corresponding header file changes.
Following that I'll refresh xen tree, debug, test, and send patches.

For linux kernel mailing list introduction, PVH is a PV guest that can
run in an HVM container, uses native pagetables, uses callback vector,
native IDT, and native syscalls.

They were built on top of 89d0307af2b9957d59bfb2a86aaa57464ff921de
commit.

thanks,
Mukesh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 21:50:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 21:50:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMQdS-0003rt-U2; Thu, 11 Oct 2012 21:49:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1TMQdR-0003ro-7b
	for Xen-devel@lists.xensource.com; Thu, 11 Oct 2012 21:49:41 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1349992173!11025492!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzk3Njc3\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29860 invoked from network); 11 Oct 2012 21:49:35 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Oct 2012 21:49:35 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9BLnWtU010201
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 11 Oct 2012 21:49:33 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9BLnVuh016937
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 11 Oct 2012 21:49:32 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9BLnVFx014545; Thu, 11 Oct 2012 16:49:31 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 11 Oct 2012 14:49:31 -0700
Date: Thu, 11 Oct 2012 14:49:29 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	linux-kernel@vger.kernel.org
Message-ID: <20121011144929.06e71a9e@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Subject: [Xen-devel] [PATCH V2 0/7]: PVH: PV guest with extensions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi guys,

Ok, I've made all the changes from prev RFC patch submissions. Tested
all the combinations. The patches are organized slightly differently
from prev version because of the nature of changes after last review. I
am building xen patch just for the corresponding header file changes.
Following that I'll refresh xen tree, debug, test, and send patches.

For linux kernel mailing list introduction, PVH is a PV guest that can
run in an HVM container, uses native pagetables, uses callback vector,
native IDT, and native syscalls.

They were built on top of 89d0307af2b9957d59bfb2a86aaa57464ff921de
commit.

thanks,
Mukesh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 21:53:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 21:53:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMQh4-000408-NV; Thu, 11 Oct 2012 21:53:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1TMQh3-000401-82
	for Xen-devel@lists.xensource.com; Thu, 11 Oct 2012 21:53:25 +0000
Received: from [85.158.138.51:32472] by server-14.bemta-3.messagelabs.com id
	37/ED-17276-4DF37705; Thu, 11 Oct 2012 21:53:24 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1349992402!32358432!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgwNDQ1Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16964 invoked from network); 11 Oct 2012 21:53:23 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Oct 2012 21:53:23 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9BLrJSH009884
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 11 Oct 2012 21:53:20 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9BLrIvf027126
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 11 Oct 2012 21:53:19 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9BLrIct016696; Thu, 11 Oct 2012 16:53:18 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 11 Oct 2012 14:53:18 -0700
Date: Thu, 11 Oct 2012 14:53:17 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	linux-kernel@vger.kernel.org
Message-ID: <20121011145317.51655302@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: [Xen-devel] [PATCH V2 1/7]: PVH: basic and header changes,
	elfnote changes, ...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


PVH: is a PV linux guest that has extended capabilities. This patch allows it to be configured and enabled. Also, basic header file changes to add new subcalls to physmap hypercall. Lastly, mfn_to_local_pfn must return mfn for paging mode translate

Signed-off-by: Mukesh R <mukesh.rathor@oracle.com>
---
 arch/x86/include/asm/xen/page.h |    3 +++
 arch/x86/xen/Kconfig            |   10 ++++++++++
 arch/x86/xen/xen-head.S         |   11 ++++++++++-
 include/xen/interface/memory.h  |   30 +++++++++++++++++++++++++++---
 include/xen/interface/physdev.h |   10 ++++++++++
 5 files changed, 60 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index 472b9b7..6af440d 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -159,6 +159,9 @@ static inline xpaddr_t machine_to_phys(xmaddr_t machine)
 static inline unsigned long mfn_to_local_pfn(unsigned long mfn)
 {
 	unsigned long pfn = mfn_to_pfn(mfn);
+
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return mfn;
 	if (get_phys_to_machine(pfn) != mfn)
 		return -1; /* force !pfn_valid() */
 	return pfn;
diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index fdce49c..9323b8c 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -50,3 +50,13 @@ config XEN_DEBUG_FS
 	  Enable statistics output and various tuning options in debugfs.
 	  Enabling this option may incur a significant performance overhead.
 
+config XEN_X86_PVH
+	bool "Support for running as a PVH guest (EXPERIMENTAL)"
+	depends on X86_64 && XEN && INTEL_IOMMU && EXPERIMENTAL
+	default n
+	help
+	   This option enables support for running as a PVH guest (PV guest
+	   using hardware extensions) under a suitably capable hypervisor.
+	   This option is EXPERIMETNAL because the hypervisor interfaces
+	   which it uses are not yet considered stable therefore backwards and
+	   forwards compatibility is not yet guaranteed.  If unsure, say N.
diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
index 7faed58..3e65ece 100644
--- a/arch/x86/xen/xen-head.S
+++ b/arch/x86/xen/xen-head.S
@@ -13,6 +13,15 @@
 #include <xen/interface/elfnote.h>
 #include <asm/xen/interface.h>
 
+#ifdef CONFIG_XEN_X86_PVH
+#define FEATURES_PVH "| writable_descriptor_tables" \
+		     "| auto_translated_physmap" \
+		     "| supervisor_mode_kernel" \
+		     "| hvm_callback_vector"
+#else
+#define FEATURES_PVH /* Not supported */
+#endif
+
 	__INIT
 ENTRY(startup_xen)
 	cld
@@ -95,7 +104,7 @@ NEXT_HYPERCALL(arch_6)
 #endif
 	ELFNOTE(Xen, XEN_ELFNOTE_ENTRY,          _ASM_PTR startup_xen)
 	ELFNOTE(Xen, XEN_ELFNOTE_HYPERCALL_PAGE, _ASM_PTR hypercall_page)
-	ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,       .asciz "!writable_page_tables|pae_pgdir_above_4gb")
+	ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,       .asciz "!writable_page_tables|pae_pgdir_above_4gb"FEATURES_PVH)
 	ELFNOTE(Xen, XEN_ELFNOTE_PAE_MODE,       .asciz "yes")
 	ELFNOTE(Xen, XEN_ELFNOTE_LOADER,         .asciz "generic")
 	ELFNOTE(Xen, XEN_ELFNOTE_L1_MFN_VALID,
diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index d8e33a9..dbf4c6b 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -163,14 +163,22 @@ struct xen_add_to_physmap {
     /* Which domain to change the mapping for. */
     domid_t domid;
 
-    /* Number of pages to go through for gmfn_range */
-    uint16_t    size;
-
+    union {
+	/* Number of pages to go through for gmfn_range */
+	uint16_t    size;
+	/* IFF XENMAPSPACE_gmfn_foreign */
+	domid_t foreign_domid;
+    } u;
     /* Source mapping space. */
 #define XENMAPSPACE_shared_info 0 /* shared info page */
 #define XENMAPSPACE_grant_table 1 /* grant table page */
+#define XENMAPSPACE_gmfn        2 /* GMFN */
+#define XENMAPSPACE_gmfn_range  3 /* GMFN range */
+#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */
     unsigned int space;
 
+#define XENMAPIDX_grant_table_status 0x80000000
+
     /* Index into source mapping space. */
     unsigned long idx;
 
@@ -237,4 +245,20 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_memory_map);
  * during a driver critical region.
  */
 extern spinlock_t xen_reservation_lock;
+
+/*
+ * Unmaps the page appearing at a particular GPFN from the specified guest's
+ * pseudophysical address space.
+ * arg == addr of xen_remove_from_physmap_t.
+ */
+#define XENMEM_remove_from_physmap      15
+struct xen_remove_from_physmap {
+    /* Which domain to change the mapping for. */
+    domid_t domid;
+
+    /* GPFN of the current mapping of the page. */
+    xen_pfn_t gpfn;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_remove_from_physmap);
+
 #endif /* __XEN_PUBLIC_MEMORY_H__ */
diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
index 9ce788d..3b9d5b6 100644
--- a/include/xen/interface/physdev.h
+++ b/include/xen/interface/physdev.h
@@ -258,6 +258,16 @@ struct physdev_pci_device {
     uint8_t devfn;
 };
 
+#define PHYSDEVOP_pvh_map_iomem        30
+struct physdev_map_iomem {
+    /* IN */
+    uint64_t first_gfn;
+    uint64_t first_mfn;
+    uint32_t nr_mfns;
+    uint32_t add_mapping;        /* 1 == add mapping;  0 == unmap */
+
+};
+
 /*
  * Notify that some PIRQ-bound event channels have been unmasked.
  * ** This command is obsolete since interface version 0x00030202 and is **
-- 
1.7.2.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 21:53:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 21:53:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMQh4-000408-NV; Thu, 11 Oct 2012 21:53:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1TMQh3-000401-82
	for Xen-devel@lists.xensource.com; Thu, 11 Oct 2012 21:53:25 +0000
Received: from [85.158.138.51:32472] by server-14.bemta-3.messagelabs.com id
	37/ED-17276-4DF37705; Thu, 11 Oct 2012 21:53:24 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1349992402!32358432!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgwNDQ1Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16964 invoked from network); 11 Oct 2012 21:53:23 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Oct 2012 21:53:23 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9BLrJSH009884
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 11 Oct 2012 21:53:20 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9BLrIvf027126
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 11 Oct 2012 21:53:19 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9BLrIct016696; Thu, 11 Oct 2012 16:53:18 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 11 Oct 2012 14:53:18 -0700
Date: Thu, 11 Oct 2012 14:53:17 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	linux-kernel@vger.kernel.org
Message-ID: <20121011145317.51655302@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: [Xen-devel] [PATCH V2 1/7]: PVH: basic and header changes,
	elfnote changes, ...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


PVH: is a PV linux guest that has extended capabilities. This patch allows it to be configured and enabled. Also, basic header file changes to add new subcalls to physmap hypercall. Lastly, mfn_to_local_pfn must return mfn for paging mode translate

Signed-off-by: Mukesh R <mukesh.rathor@oracle.com>
---
 arch/x86/include/asm/xen/page.h |    3 +++
 arch/x86/xen/Kconfig            |   10 ++++++++++
 arch/x86/xen/xen-head.S         |   11 ++++++++++-
 include/xen/interface/memory.h  |   30 +++++++++++++++++++++++++++---
 include/xen/interface/physdev.h |   10 ++++++++++
 5 files changed, 60 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index 472b9b7..6af440d 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -159,6 +159,9 @@ static inline xpaddr_t machine_to_phys(xmaddr_t machine)
 static inline unsigned long mfn_to_local_pfn(unsigned long mfn)
 {
 	unsigned long pfn = mfn_to_pfn(mfn);
+
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return mfn;
 	if (get_phys_to_machine(pfn) != mfn)
 		return -1; /* force !pfn_valid() */
 	return pfn;
diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index fdce49c..9323b8c 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -50,3 +50,13 @@ config XEN_DEBUG_FS
 	  Enable statistics output and various tuning options in debugfs.
 	  Enabling this option may incur a significant performance overhead.
 
+config XEN_X86_PVH
+	bool "Support for running as a PVH guest (EXPERIMENTAL)"
+	depends on X86_64 && XEN && INTEL_IOMMU && EXPERIMENTAL
+	default n
+	help
+	   This option enables support for running as a PVH guest (PV guest
+	   using hardware extensions) under a suitably capable hypervisor.
+	   This option is EXPERIMETNAL because the hypervisor interfaces
+	   which it uses are not yet considered stable therefore backwards and
+	   forwards compatibility is not yet guaranteed.  If unsure, say N.
diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
index 7faed58..3e65ece 100644
--- a/arch/x86/xen/xen-head.S
+++ b/arch/x86/xen/xen-head.S
@@ -13,6 +13,15 @@
 #include <xen/interface/elfnote.h>
 #include <asm/xen/interface.h>
 
+#ifdef CONFIG_XEN_X86_PVH
+#define FEATURES_PVH "| writable_descriptor_tables" \
+		     "| auto_translated_physmap" \
+		     "| supervisor_mode_kernel" \
+		     "| hvm_callback_vector"
+#else
+#define FEATURES_PVH /* Not supported */
+#endif
+
 	__INIT
 ENTRY(startup_xen)
 	cld
@@ -95,7 +104,7 @@ NEXT_HYPERCALL(arch_6)
 #endif
 	ELFNOTE(Xen, XEN_ELFNOTE_ENTRY,          _ASM_PTR startup_xen)
 	ELFNOTE(Xen, XEN_ELFNOTE_HYPERCALL_PAGE, _ASM_PTR hypercall_page)
-	ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,       .asciz "!writable_page_tables|pae_pgdir_above_4gb")
+	ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,       .asciz "!writable_page_tables|pae_pgdir_above_4gb"FEATURES_PVH)
 	ELFNOTE(Xen, XEN_ELFNOTE_PAE_MODE,       .asciz "yes")
 	ELFNOTE(Xen, XEN_ELFNOTE_LOADER,         .asciz "generic")
 	ELFNOTE(Xen, XEN_ELFNOTE_L1_MFN_VALID,
diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index d8e33a9..dbf4c6b 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -163,14 +163,22 @@ struct xen_add_to_physmap {
     /* Which domain to change the mapping for. */
     domid_t domid;
 
-    /* Number of pages to go through for gmfn_range */
-    uint16_t    size;
-
+    union {
+	/* Number of pages to go through for gmfn_range */
+	uint16_t    size;
+	/* IFF XENMAPSPACE_gmfn_foreign */
+	domid_t foreign_domid;
+    } u;
     /* Source mapping space. */
 #define XENMAPSPACE_shared_info 0 /* shared info page */
 #define XENMAPSPACE_grant_table 1 /* grant table page */
+#define XENMAPSPACE_gmfn        2 /* GMFN */
+#define XENMAPSPACE_gmfn_range  3 /* GMFN range */
+#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */
     unsigned int space;
 
+#define XENMAPIDX_grant_table_status 0x80000000
+
     /* Index into source mapping space. */
     unsigned long idx;
 
@@ -237,4 +245,20 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_memory_map);
  * during a driver critical region.
  */
 extern spinlock_t xen_reservation_lock;
+
+/*
+ * Unmaps the page appearing at a particular GPFN from the specified guest's
+ * pseudophysical address space.
+ * arg == addr of xen_remove_from_physmap_t.
+ */
+#define XENMEM_remove_from_physmap      15
+struct xen_remove_from_physmap {
+    /* Which domain to change the mapping for. */
+    domid_t domid;
+
+    /* GPFN of the current mapping of the page. */
+    xen_pfn_t gpfn;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_remove_from_physmap);
+
 #endif /* __XEN_PUBLIC_MEMORY_H__ */
diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
index 9ce788d..3b9d5b6 100644
--- a/include/xen/interface/physdev.h
+++ b/include/xen/interface/physdev.h
@@ -258,6 +258,16 @@ struct physdev_pci_device {
     uint8_t devfn;
 };
 
+#define PHYSDEVOP_pvh_map_iomem        30
+struct physdev_map_iomem {
+    /* IN */
+    uint64_t first_gfn;
+    uint64_t first_mfn;
+    uint32_t nr_mfns;
+    uint32_t add_mapping;        /* 1 == add mapping;  0 == unmap */
+
+};
+
 /*
  * Notify that some PIRQ-bound event channels have been unmasked.
  * ** This command is obsolete since interface version 0x00030202 and is **
-- 
1.7.2.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 21:57:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 21:57:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMQkv-00049c-Df; Thu, 11 Oct 2012 21:57:25 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1TMQkt-00049R-Qw
	for Xen-devel@lists.xensource.com; Thu, 11 Oct 2012 21:57:24 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1349992635!1893127!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzk3Njc3\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11987 invoked from network); 11 Oct 2012 21:57:16 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Oct 2012 21:57:16 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9BLvEQW016649
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 11 Oct 2012 21:57:14 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9BLvDJK020820
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 11 Oct 2012 21:57:13 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9BLvDUV022427; Thu, 11 Oct 2012 16:57:13 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 11 Oct 2012 14:57:12 -0700
Date: Thu, 11 Oct 2012 14:57:11 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Message-ID: <20121011145711.0d9c27df@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: [Xen-devel] [PATCH V2 2/7]: PVH: use native irq, enable callback,
 use HVM ring ops, ...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

PVH: make gdt_frames[]/gdt_ents into a union with {gdtaddr, gdtsz}, PVH
only needs to send down gdtaddr and gdtsz. irq.c: PVH uses
native_irq_ops. vcpu hotplug is currently not available for PVH.
events.c: setup callback vector for PVH. Finally, PVH ring ops uses HVM
paths for xenbus.

Signed-off-by: Mukesh R <mukesh.rathor@oracle.com>
---
 arch/x86/include/asm/xen/interface.h |    8 +++++++-
 arch/x86/xen/irq.c                   |    5 ++++-
 arch/x86/xen/p2m.c                   |    2 +-
 arch/x86/xen/smp.c                   |    4 ++--
 drivers/xen/cpu_hotplug.c            |    4 +++-
 drivers/xen/events.c                 |    9 ++++++++-
 drivers/xen/xenbus/xenbus_client.c   |    3 ++-
 7 files changed, 27 insertions(+), 8 deletions(-)

diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
index 555f94d..f11edb0 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -143,7 +143,13 @@ struct vcpu_guest_context {
     struct cpu_user_regs user_regs;         /* User-level CPU registers     */
     struct trap_info trap_ctxt[256];        /* Virtual IDT                  */
     unsigned long ldt_base, ldt_ents;       /* LDT (linear address, # ents) */
-    unsigned long gdt_frames[16], gdt_ents; /* GDT (machine frames, # ents) */
+    union {
+	struct {
+		/* PV: GDT (machine frames, # ents).*/
+		unsigned long gdt_frames[16], gdt_ents;
+	} s;
+	unsigned long gdtaddr, gdtsz;	    /* PVH: GDTR addr and size */
+    } u;
     unsigned long kernel_ss, kernel_sp;     /* Virtual TSS (only SS1/SP1)   */
     /* NB. User pagetable on x86/64 is placed in ctrlreg[1]. */
     unsigned long ctrlreg[8];               /* CR0-CR7 (control registers)  */
diff --git a/arch/x86/xen/irq.c b/arch/x86/xen/irq.c
index 1573376..31959a7 100644
--- a/arch/x86/xen/irq.c
+++ b/arch/x86/xen/irq.c
@@ -5,6 +5,7 @@
 #include <xen/interface/xen.h>
 #include <xen/interface/sched.h>
 #include <xen/interface/vcpu.h>
+#include <xen/features.h>
 
 #include <asm/xen/hypercall.h>
 #include <asm/xen/hypervisor.h>
@@ -128,6 +129,8 @@ static const struct pv_irq_ops xen_irq_ops __initconst = {
 
 void __init xen_init_irq_ops(void)
 {
-	pv_irq_ops = xen_irq_ops;
+	/* For PVH we use default pv_irq_ops settings */
+	if (!xen_feature(XENFEAT_hvm_callback_vector))
+		pv_irq_ops = xen_irq_ops;
 	x86_init.irqs.intr_init = xen_init_IRQ;
 }
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 95fb2aa..ea553c8 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -798,7 +798,7 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 {
 	unsigned topidx, mididx, idx;
 
-	if (unlikely(xen_feature(XENFEAT_auto_translated_physmap))) {
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
 		BUG_ON(pfn != mfn && mfn != INVALID_P2M_ENTRY);
 		return true;
 	}
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index f58dca7..bd92698 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -324,8 +324,8 @@ cpu_initialize_context(unsigned int cpu, struct task_struct *idle)
 	make_lowmem_page_readonly(gdt);
 	make_lowmem_page_readonly(mfn_to_virt(gdt_mfn));
 
-	ctxt->gdt_frames[0] = gdt_mfn;
-	ctxt->gdt_ents      = GDT_ENTRIES;
+	ctxt->u.s.gdt_frames[0] = gdt_mfn;
+	ctxt->u.s.gdt_ents      = GDT_ENTRIES;
 
 	ctxt->user_regs.cs = __KERNEL_CS;
 	ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct pt_regs);
diff --git a/drivers/xen/cpu_hotplug.c b/drivers/xen/cpu_hotplug.c
index 4dcfced..de6bcf9 100644
--- a/drivers/xen/cpu_hotplug.c
+++ b/drivers/xen/cpu_hotplug.c
@@ -2,6 +2,7 @@
 
 #include <xen/xen.h>
 #include <xen/xenbus.h>
+#include <xen/features.h>
 
 #include <asm/xen/hypervisor.h>
 #include <asm/cpu.h>
@@ -100,7 +101,8 @@ static int __init setup_vcpu_hotplug_event(void)
 	static struct notifier_block xsn_cpu = {
 		.notifier_call = setup_cpu_watcher };
 
-	if (!xen_pv_domain())
+	/* PVH TBD/FIXME: future work */
+	if (!xen_pv_domain() || xen_feature(XENFEAT_auto_translated_physmap))
 		return -ENODEV;
 
 	register_xenstore_notifier(&xsn_cpu);
diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index c60d162..a977612 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -1767,7 +1767,7 @@ int xen_set_callback_via(uint64_t via)
 }
 EXPORT_SYMBOL_GPL(xen_set_callback_via);
 
-#ifdef CONFIG_XEN_PVHVM
+#ifdef CONFIG_X86
 /* Vector callbacks are better than PCI interrupts to receive event
  * channel notifications because we can receive vector callbacks on any
  * vcpu and we don't need PCI support or APIC interactions. */
@@ -1826,6 +1826,13 @@ void __init xen_init_IRQ(void)
 		if (xen_initial_domain())
 			pci_xen_initial_domain();
 
+		if (xen_feature(XENFEAT_hvm_callback_vector)) {
+			xen_callback_vector();
+			return;
+		}
+
+		/* PVH: TBD/FIXME: debug and fix eio map to work with pvh */
+
 		pirq_eoi_map = (void *)__get_free_page(GFP_KERNEL|__GFP_ZERO);
 		eoi_gmfn.gmfn = virt_to_mfn(pirq_eoi_map);
 		rc = HYPERVISOR_physdev_op(PHYSDEVOP_pirq_eoi_gmfn_v2, &eoi_gmfn);
diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
index b3e146e..1bac743 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -44,6 +44,7 @@
 #include <xen/grant_table.h>
 #include <xen/xenbus.h>
 #include <xen/xen.h>
+#include <xen/features.h>
 
 #include "xenbus_probe.h"
 
@@ -743,7 +744,7 @@ static const struct xenbus_ring_ops ring_ops_hvm = {
 
 void __init xenbus_ring_ops_init(void)
 {
-	if (xen_pv_domain())
+	if (xen_pv_domain() && !xen_feature(XENFEAT_auto_translated_physmap))
 		ring_ops = &ring_ops_pv;
 	else
 		ring_ops = &ring_ops_hvm;
-- 
1.7.2.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 21:57:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 21:57:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMQkv-00049c-Df; Thu, 11 Oct 2012 21:57:25 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1TMQkt-00049R-Qw
	for Xen-devel@lists.xensource.com; Thu, 11 Oct 2012 21:57:24 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1349992635!1893127!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzk3Njc3\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11987 invoked from network); 11 Oct 2012 21:57:16 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Oct 2012 21:57:16 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9BLvEQW016649
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 11 Oct 2012 21:57:14 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9BLvDJK020820
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 11 Oct 2012 21:57:13 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9BLvDUV022427; Thu, 11 Oct 2012 16:57:13 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 11 Oct 2012 14:57:12 -0700
Date: Thu, 11 Oct 2012 14:57:11 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Message-ID: <20121011145711.0d9c27df@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: [Xen-devel] [PATCH V2 2/7]: PVH: use native irq, enable callback,
 use HVM ring ops, ...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

PVH: make gdt_frames[]/gdt_ents into a union with {gdtaddr, gdtsz}, PVH
only needs to send down gdtaddr and gdtsz. irq.c: PVH uses
native_irq_ops. vcpu hotplug is currently not available for PVH.
events.c: setup callback vector for PVH. Finally, PVH ring ops uses HVM
paths for xenbus.

Signed-off-by: Mukesh R <mukesh.rathor@oracle.com>
---
 arch/x86/include/asm/xen/interface.h |    8 +++++++-
 arch/x86/xen/irq.c                   |    5 ++++-
 arch/x86/xen/p2m.c                   |    2 +-
 arch/x86/xen/smp.c                   |    4 ++--
 drivers/xen/cpu_hotplug.c            |    4 +++-
 drivers/xen/events.c                 |    9 ++++++++-
 drivers/xen/xenbus/xenbus_client.c   |    3 ++-
 7 files changed, 27 insertions(+), 8 deletions(-)

diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
index 555f94d..f11edb0 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -143,7 +143,13 @@ struct vcpu_guest_context {
     struct cpu_user_regs user_regs;         /* User-level CPU registers     */
     struct trap_info trap_ctxt[256];        /* Virtual IDT                  */
     unsigned long ldt_base, ldt_ents;       /* LDT (linear address, # ents) */
-    unsigned long gdt_frames[16], gdt_ents; /* GDT (machine frames, # ents) */
+    union {
+	struct {
+		/* PV: GDT (machine frames, # ents).*/
+		unsigned long gdt_frames[16], gdt_ents;
+	} s;
+	unsigned long gdtaddr, gdtsz;	    /* PVH: GDTR addr and size */
+    } u;
     unsigned long kernel_ss, kernel_sp;     /* Virtual TSS (only SS1/SP1)   */
     /* NB. User pagetable on x86/64 is placed in ctrlreg[1]. */
     unsigned long ctrlreg[8];               /* CR0-CR7 (control registers)  */
diff --git a/arch/x86/xen/irq.c b/arch/x86/xen/irq.c
index 1573376..31959a7 100644
--- a/arch/x86/xen/irq.c
+++ b/arch/x86/xen/irq.c
@@ -5,6 +5,7 @@
 #include <xen/interface/xen.h>
 #include <xen/interface/sched.h>
 #include <xen/interface/vcpu.h>
+#include <xen/features.h>
 
 #include <asm/xen/hypercall.h>
 #include <asm/xen/hypervisor.h>
@@ -128,6 +129,8 @@ static const struct pv_irq_ops xen_irq_ops __initconst = {
 
 void __init xen_init_irq_ops(void)
 {
-	pv_irq_ops = xen_irq_ops;
+	/* For PVH we use default pv_irq_ops settings */
+	if (!xen_feature(XENFEAT_hvm_callback_vector))
+		pv_irq_ops = xen_irq_ops;
 	x86_init.irqs.intr_init = xen_init_IRQ;
 }
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 95fb2aa..ea553c8 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -798,7 +798,7 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 {
 	unsigned topidx, mididx, idx;
 
-	if (unlikely(xen_feature(XENFEAT_auto_translated_physmap))) {
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
 		BUG_ON(pfn != mfn && mfn != INVALID_P2M_ENTRY);
 		return true;
 	}
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index f58dca7..bd92698 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -324,8 +324,8 @@ cpu_initialize_context(unsigned int cpu, struct task_struct *idle)
 	make_lowmem_page_readonly(gdt);
 	make_lowmem_page_readonly(mfn_to_virt(gdt_mfn));
 
-	ctxt->gdt_frames[0] = gdt_mfn;
-	ctxt->gdt_ents      = GDT_ENTRIES;
+	ctxt->u.s.gdt_frames[0] = gdt_mfn;
+	ctxt->u.s.gdt_ents      = GDT_ENTRIES;
 
 	ctxt->user_regs.cs = __KERNEL_CS;
 	ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct pt_regs);
diff --git a/drivers/xen/cpu_hotplug.c b/drivers/xen/cpu_hotplug.c
index 4dcfced..de6bcf9 100644
--- a/drivers/xen/cpu_hotplug.c
+++ b/drivers/xen/cpu_hotplug.c
@@ -2,6 +2,7 @@
 
 #include <xen/xen.h>
 #include <xen/xenbus.h>
+#include <xen/features.h>
 
 #include <asm/xen/hypervisor.h>
 #include <asm/cpu.h>
@@ -100,7 +101,8 @@ static int __init setup_vcpu_hotplug_event(void)
 	static struct notifier_block xsn_cpu = {
 		.notifier_call = setup_cpu_watcher };
 
-	if (!xen_pv_domain())
+	/* PVH TBD/FIXME: future work */
+	if (!xen_pv_domain() || xen_feature(XENFEAT_auto_translated_physmap))
 		return -ENODEV;
 
 	register_xenstore_notifier(&xsn_cpu);
diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index c60d162..a977612 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -1767,7 +1767,7 @@ int xen_set_callback_via(uint64_t via)
 }
 EXPORT_SYMBOL_GPL(xen_set_callback_via);
 
-#ifdef CONFIG_XEN_PVHVM
+#ifdef CONFIG_X86
 /* Vector callbacks are better than PCI interrupts to receive event
  * channel notifications because we can receive vector callbacks on any
  * vcpu and we don't need PCI support or APIC interactions. */
@@ -1826,6 +1826,13 @@ void __init xen_init_IRQ(void)
 		if (xen_initial_domain())
 			pci_xen_initial_domain();
 
+		if (xen_feature(XENFEAT_hvm_callback_vector)) {
+			xen_callback_vector();
+			return;
+		}
+
+		/* PVH: TBD/FIXME: debug and fix eio map to work with pvh */
+
 		pirq_eoi_map = (void *)__get_free_page(GFP_KERNEL|__GFP_ZERO);
 		eoi_gmfn.gmfn = virt_to_mfn(pirq_eoi_map);
 		rc = HYPERVISOR_physdev_op(PHYSDEVOP_pirq_eoi_gmfn_v2, &eoi_gmfn);
diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
index b3e146e..1bac743 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -44,6 +44,7 @@
 #include <xen/grant_table.h>
 #include <xen/xenbus.h>
 #include <xen/xen.h>
+#include <xen/features.h>
 
 #include "xenbus_probe.h"
 
@@ -743,7 +744,7 @@ static const struct xenbus_ring_ops ring_ops_hvm = {
 
 void __init xenbus_ring_ops_init(void)
 {
-	if (xen_pv_domain())
+	if (xen_pv_domain() && !xen_feature(XENFEAT_auto_translated_physmap))
 		ring_ops = &ring_ops_pv;
 	else
 		ring_ops = &ring_ops_hvm;
-- 
1.7.2.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 21:58:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 21:58:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMQlu-0004Dp-Rz; Thu, 11 Oct 2012 21:58:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1TMQls-0004Dd-MW
	for Xen-devel@lists.xensource.com; Thu, 11 Oct 2012 21:58:25 +0000
Received: from [85.158.143.35:2832] by server-1.bemta-4.messagelabs.com id
	42/24-19551-FF047705; Thu, 11 Oct 2012 21:58:23 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1349992700!4934114!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzk3Njc3\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17911 invoked from network); 11 Oct 2012 21:58:22 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Oct 2012 21:58:22 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9BLwJ9g017611
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 11 Oct 2012 21:58:20 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9BLwI42022399
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 11 Oct 2012 21:58:19 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9BLwIOx022987; Thu, 11 Oct 2012 16:58:18 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 11 Oct 2012 14:58:18 -0700
Date: Thu, 11 Oct 2012 14:58:17 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Message-ID: <20121011145817.0d744c99@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: [Xen-devel] [PATCH V2 3/7]: PVH:  mmu related changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

PVH: This patch implements mmu changes for PVH. First the set/clear
mmio pte function makes a hypercall to update the p2m in xen with 1:1
mapping. PVH uses mostly native mmu ops. Two local functions are
introduced to add to xen physmap for xen remap interface. xen unmap
interface is introduced so the privcmd pte entries can be cleared in
xen p2m table.

Signed-off-by: Mukesh R <mukesh.rathor@oracle.com>
---
 arch/x86/xen/mmu.c    |  172 ++++++++++++++++++++++++++++++++++++++++++++++---
 arch/x86/xen/mmu.h    |    2 +
 drivers/xen/privcmd.c |    5 +-
 include/xen/xen-ops.h |    4 +-
 4 files changed, 171 insertions(+), 12 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 5a16824..12b56a0 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -73,6 +73,7 @@
 #include <xen/interface/version.h>
 #include <xen/interface/memory.h>
 #include <xen/hvc-console.h>
+#include <xen/balloon.h>
 
 #include "multicalls.h"
 #include "mmu.h"
@@ -331,6 +332,20 @@ static void xen_set_pte(pte_t *ptep, pte_t pteval)
 	__xen_set_pte(ptep, pteval);
 }
 
+void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn,
+			      int nr_mfns, int add_mapping)
+{
+	struct physdev_map_iomem iomem;
+
+	iomem.first_gfn = pfn;
+	iomem.first_mfn = mfn;
+	iomem.nr_mfns = nr_mfns;
+	iomem.add_mapping = add_mapping;
+
+	if (HYPERVISOR_physdev_op(PHYSDEVOP_pvh_map_iomem, &iomem))
+		BUG();
+}
+
 static void xen_set_pte_at(struct mm_struct *mm, unsigned long addr,
 		    pte_t *ptep, pte_t pteval)
 {
@@ -1220,6 +1235,8 @@ static void __init xen_pagetable_init(void)
 #endif
 	paging_init();
 	xen_setup_shared_info();
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return;
 #ifdef CONFIG_X86_64
 	if (!xen_feature(XENFEAT_auto_translated_physmap)) {
 		unsigned long new_mfn_list;
@@ -1527,6 +1544,10 @@ static void __init xen_set_pte_init(pte_t *ptep, pte_t pte)
 static void pin_pagetable_pfn(unsigned cmd, unsigned long pfn)
 {
 	struct mmuext_op op;
+
+	if (xen_feature(XENFEAT_writable_page_tables))
+		return;
+
 	op.cmd = cmd;
 	op.arg1.mfn = pfn_to_mfn(pfn);
 	if (HYPERVISOR_mmuext_op(&op, 1, NULL, DOMID_SELF))
@@ -1724,6 +1745,10 @@ static void set_page_prot(void *addr, pgprot_t prot)
 	unsigned long pfn = __pa(addr) >> PAGE_SHIFT;
 	pte_t pte = pfn_pte(pfn, prot);
 
+	/* recall for PVH, page tables are native. */
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return;
+
 	if (HYPERVISOR_update_va_mapping((unsigned long)addr, pte, 0))
 		BUG();
 }
@@ -1801,6 +1826,9 @@ static void convert_pfn_mfn(void *v)
 	pte_t *pte = v;
 	int i;
 
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return;
+
 	/* All levels are converted the same way, so just treat them
 	   as ptes. */
 	for (i = 0; i < PTRS_PER_PTE; i++)
@@ -1820,6 +1848,7 @@ static void __init check_pt_base(unsigned long *pt_base, unsigned long *pt_end,
 		(*pt_end)--;
 	}
 }
+
 /*
  * Set up the initial kernel pagetable.
  *
@@ -1830,6 +1859,7 @@ static void __init check_pt_base(unsigned long *pt_base, unsigned long *pt_end,
  * but that's enough to get __va working.  We need to fill in the rest
  * of the physical mapping once some sort of allocator has been set
  * up.
+ * NOTE: for PVH, the page tables are native.
  */
 void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn)
 {
@@ -1907,10 +1937,13 @@ void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn)
 	 * structure to attach it to, so make sure we just set kernel
 	 * pgd.
 	 */
-	xen_mc_batch();
-	__xen_write_cr3(true, __pa(init_level4_pgt));
-	xen_mc_issue(PARAVIRT_LAZY_CPU);
-
+	if (xen_feature(XENFEAT_writable_page_tables)) {
+		native_write_cr3(__pa(init_level4_pgt));
+	} else {
+		xen_mc_batch();
+		__xen_write_cr3(true, __pa(init_level4_pgt));
+		xen_mc_issue(PARAVIRT_LAZY_CPU);
+	}
 	/* We can't that easily rip out L3 and L2, as the Xen pagetables are
 	 * set out this way: [L4], [L1], [L2], [L3], [L1], [L1] ...  for
 	 * the initial domain. For guests using the toolstack, they are in:
@@ -2177,8 +2210,19 @@ static const struct pv_mmu_ops xen_mmu_ops __initconst = {
 
 void __init xen_init_mmu_ops(void)
 {
-	x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
 	x86_init.paging.pagetable_init = xen_pagetable_init;
+
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		pv_mmu_ops.flush_tlb_others = xen_flush_tlb_others;
+
+		/* For PCI devices to map iomem. */
+		if (xen_initial_domain()) {
+			pv_mmu_ops.set_pte = native_set_pte;
+			pv_mmu_ops.set_pte_at = native_set_pte_at;
+		}
+		return;
+	}
+	x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
 	pv_mmu_ops = xen_mmu_ops;
 
 	memset(dummy_mapping, 0xff, PAGE_SIZE);
@@ -2414,6 +2458,87 @@ void __init xen_hvm_init_mmu_ops(void)
 }
 #endif
 
+/* Map foreign gmfn, fgmfn, to local pfn, lpfn. This for the user space
+ * creating new guest on PVH dom0 and needs to map domU pages.
+ */
+static int pvh_add_to_xen_p2m(unsigned long lpfn, unsigned long fgmfn,
+			      unsigned int domid)
+{
+	int rc;
+	struct xen_add_to_physmap xatp = { .u.foreign_domid = domid };
+
+	xatp.gpfn = lpfn;
+	xatp.idx = fgmfn;
+	xatp.domid = DOMID_SELF;
+	xatp.space = XENMAPSPACE_gmfn_foreign;
+	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
+	if (rc)
+		pr_warn("d0: Failed to map pfn (0x%lx) to mfn (0x%lx) rc:%d\n",
+			lpfn, fgmfn, rc);
+	return rc;
+}
+
+static int pvh_rem_xen_p2m(unsigned long spfn, int count)
+{
+	struct xen_remove_from_physmap xrp;
+	int i, rc;
+
+	for (i = 0; i < count; i++) {
+		xrp.domid = DOMID_SELF;
+		xrp.gpfn = spfn+i;
+		rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, &xrp);
+		if (rc) {
+			pr_warn("Failed to unmap pfn:%lx rc:%d done:%d\n",
+				spfn+i, rc, i);
+			return 1;
+		}
+	}
+	return 0;
+}
+
+struct pvh_remap_data {
+	unsigned long fgmfn;		/* foreign domain's gmfn */
+	pgprot_t prot;
+	domid_t  domid;
+	int	 index;
+	struct page **pages;
+};
+
+static int pvh_map_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr,
+			void *data)
+{
+	int rc;
+	struct pvh_remap_data *remap = data;
+	unsigned long pfn = page_to_pfn(remap->pages[remap->index++]);
+	pte_t pteval = pte_mkspecial(pfn_pte(pfn, remap->prot));
+
+	rc = pvh_add_to_xen_p2m(pfn, remap->fgmfn, remap->domid);
+	if (rc)
+		return rc;
+	native_set_pte(ptep, pteval);
+
+	return 0;
+}
+
+static int pvh_remap_gmfn_range(struct vm_area_struct *vma,
+				unsigned long addr, unsigned long mfn, int nr,
+				pgprot_t prot, unsigned domid,
+				struct page **pages)
+{
+	int err;
+	struct pvh_remap_data pvhdata;
+
+	pvhdata.fgmfn = mfn;
+	pvhdata.prot = prot;
+	pvhdata.domid = domid;
+	pvhdata.index = 0;
+	pvhdata.pages = pages;
+	err = apply_to_page_range(vma->vm_mm, addr, nr << PAGE_SHIFT,
+				  pvh_map_pte_fn, &pvhdata);
+	flush_tlb_all();
+	return err;
+}
+
 #define REMAP_BATCH_SIZE 16
 
 struct remap_data {
@@ -2438,7 +2563,9 @@ static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token,
 int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 			       unsigned long addr,
 			       unsigned long mfn, int nr,
-			       pgprot_t prot, unsigned domid)
+			       pgprot_t prot, unsigned domid,
+			       struct page **pages)
+
 {
 	struct remap_data rmd;
 	struct mmu_update mmu_update[REMAP_BATCH_SIZE];
@@ -2446,14 +2573,17 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 	unsigned long range;
 	int err = 0;
 
-	if (xen_feature(XENFEAT_auto_translated_physmap))
-		return -EINVAL;
-
 	prot = __pgprot(pgprot_val(prot) | _PAGE_IOMAP);
 
 	BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_RESERVED | VM_IO)) ==
 				(VM_PFNMAP | VM_RESERVED | VM_IO)));
 
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		/* We need to update the local page tables and the xen HAP */
+		return pvh_remap_gmfn_range(vma, addr, mfn, nr, prot, domid,
+					    pages);
+	}
+
 	rmd.mfn = mfn;
 	rmd.prot = prot;
 
@@ -2483,3 +2613,27 @@ out:
 	return err;
 }
 EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
+
+/* Returns: 0 success */
+int xen_unmap_domain_mfn_range(struct vm_area_struct *vma)
+{
+	int numpgs = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
+	struct page **pages = vma ? vma->vm_private_data : NULL;
+
+	if (!pages || !xen_feature(XENFEAT_auto_translated_physmap))
+		return 0;
+
+	while (numpgs--) {
+
+		/* the mmu has already cleaned up the process mmu resources at
+		 * this point (lookup_address will return NULL). */
+		unsigned long pfn = page_to_pfn(pages[numpgs]);
+
+		pvh_rem_xen_p2m(pfn, 1);
+	}
+	/* We don't need to flush tlbs because as part of pvh_rem_xen_p2m(),
+	 * the hypervisor will do tlb flushes after removing the p2m entries
+	 * from the EPT/NPT */
+	return 0;
+}
+EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range);
diff --git a/arch/x86/xen/mmu.h b/arch/x86/xen/mmu.h
index 73809bb..6d0bb56 100644
--- a/arch/x86/xen/mmu.h
+++ b/arch/x86/xen/mmu.h
@@ -23,4 +23,6 @@ unsigned long xen_read_cr2_direct(void);
 
 extern void xen_init_mmu_ops(void);
 extern void xen_hvm_init_mmu_ops(void);
+extern void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn,
+				     int nr_mfns, int add_mapping);
 #endif	/* _XEN_MMU_H */
diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index ef63895..63d9ee8 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -178,7 +178,7 @@ static int mmap_mfn_range(void *data, void *state)
 					msg->va & PAGE_MASK,
 					msg->mfn, msg->npages,
 					vma->vm_page_prot,
-					st->domain);
+					st->domain, NULL);
 	if (rc < 0)
 		return rc;
 
@@ -267,7 +267,8 @@ static int mmap_batch_fn(void *data, void *state)
 	int ret;
 
 	ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
-					 st->vma->vm_page_prot, st->domain);
+					 st->vma->vm_page_prot, st->domain,
+					 NULL);
 
 	/* Store error code for second pass. */
 	*(st->err++) = ret;
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 6a198e4..8b24315 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -27,6 +27,8 @@ struct vm_area_struct;
 int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 			       unsigned long addr,
 			       unsigned long mfn, int nr,
-			       pgprot_t prot, unsigned domid);
+			       pgprot_t prot, unsigned domid,
+			       struct page **pages);
+int xen_unmap_domain_mfn_range(struct vm_area_struct *vma);
 
 #endif /* INCLUDE_XEN_OPS_H */
-- 
1.7.2.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 21:58:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 21:58:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMQlu-0004Dp-Rz; Thu, 11 Oct 2012 21:58:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1TMQls-0004Dd-MW
	for Xen-devel@lists.xensource.com; Thu, 11 Oct 2012 21:58:25 +0000
Received: from [85.158.143.35:2832] by server-1.bemta-4.messagelabs.com id
	42/24-19551-FF047705; Thu, 11 Oct 2012 21:58:23 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1349992700!4934114!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzk3Njc3\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17911 invoked from network); 11 Oct 2012 21:58:22 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Oct 2012 21:58:22 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9BLwJ9g017611
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 11 Oct 2012 21:58:20 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9BLwI42022399
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 11 Oct 2012 21:58:19 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9BLwIOx022987; Thu, 11 Oct 2012 16:58:18 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 11 Oct 2012 14:58:18 -0700
Date: Thu, 11 Oct 2012 14:58:17 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Message-ID: <20121011145817.0d744c99@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: [Xen-devel] [PATCH V2 3/7]: PVH:  mmu related changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

PVH: This patch implements mmu changes for PVH. First the set/clear
mmio pte function makes a hypercall to update the p2m in xen with 1:1
mapping. PVH uses mostly native mmu ops. Two local functions are
introduced to add to xen physmap for xen remap interface. xen unmap
interface is introduced so the privcmd pte entries can be cleared in
xen p2m table.

Signed-off-by: Mukesh R <mukesh.rathor@oracle.com>
---
 arch/x86/xen/mmu.c    |  172 ++++++++++++++++++++++++++++++++++++++++++++++---
 arch/x86/xen/mmu.h    |    2 +
 drivers/xen/privcmd.c |    5 +-
 include/xen/xen-ops.h |    4 +-
 4 files changed, 171 insertions(+), 12 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 5a16824..12b56a0 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -73,6 +73,7 @@
 #include <xen/interface/version.h>
 #include <xen/interface/memory.h>
 #include <xen/hvc-console.h>
+#include <xen/balloon.h>
 
 #include "multicalls.h"
 #include "mmu.h"
@@ -331,6 +332,20 @@ static void xen_set_pte(pte_t *ptep, pte_t pteval)
 	__xen_set_pte(ptep, pteval);
 }
 
+void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn,
+			      int nr_mfns, int add_mapping)
+{
+	struct physdev_map_iomem iomem;
+
+	iomem.first_gfn = pfn;
+	iomem.first_mfn = mfn;
+	iomem.nr_mfns = nr_mfns;
+	iomem.add_mapping = add_mapping;
+
+	if (HYPERVISOR_physdev_op(PHYSDEVOP_pvh_map_iomem, &iomem))
+		BUG();
+}
+
 static void xen_set_pte_at(struct mm_struct *mm, unsigned long addr,
 		    pte_t *ptep, pte_t pteval)
 {
@@ -1220,6 +1235,8 @@ static void __init xen_pagetable_init(void)
 #endif
 	paging_init();
 	xen_setup_shared_info();
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return;
 #ifdef CONFIG_X86_64
 	if (!xen_feature(XENFEAT_auto_translated_physmap)) {
 		unsigned long new_mfn_list;
@@ -1527,6 +1544,10 @@ static void __init xen_set_pte_init(pte_t *ptep, pte_t pte)
 static void pin_pagetable_pfn(unsigned cmd, unsigned long pfn)
 {
 	struct mmuext_op op;
+
+	if (xen_feature(XENFEAT_writable_page_tables))
+		return;
+
 	op.cmd = cmd;
 	op.arg1.mfn = pfn_to_mfn(pfn);
 	if (HYPERVISOR_mmuext_op(&op, 1, NULL, DOMID_SELF))
@@ -1724,6 +1745,10 @@ static void set_page_prot(void *addr, pgprot_t prot)
 	unsigned long pfn = __pa(addr) >> PAGE_SHIFT;
 	pte_t pte = pfn_pte(pfn, prot);
 
+	/* recall for PVH, page tables are native. */
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return;
+
 	if (HYPERVISOR_update_va_mapping((unsigned long)addr, pte, 0))
 		BUG();
 }
@@ -1801,6 +1826,9 @@ static void convert_pfn_mfn(void *v)
 	pte_t *pte = v;
 	int i;
 
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return;
+
 	/* All levels are converted the same way, so just treat them
 	   as ptes. */
 	for (i = 0; i < PTRS_PER_PTE; i++)
@@ -1820,6 +1848,7 @@ static void __init check_pt_base(unsigned long *pt_base, unsigned long *pt_end,
 		(*pt_end)--;
 	}
 }
+
 /*
  * Set up the initial kernel pagetable.
  *
@@ -1830,6 +1859,7 @@ static void __init check_pt_base(unsigned long *pt_base, unsigned long *pt_end,
  * but that's enough to get __va working.  We need to fill in the rest
  * of the physical mapping once some sort of allocator has been set
  * up.
+ * NOTE: for PVH, the page tables are native.
  */
 void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn)
 {
@@ -1907,10 +1937,13 @@ void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn)
 	 * structure to attach it to, so make sure we just set kernel
 	 * pgd.
 	 */
-	xen_mc_batch();
-	__xen_write_cr3(true, __pa(init_level4_pgt));
-	xen_mc_issue(PARAVIRT_LAZY_CPU);
-
+	if (xen_feature(XENFEAT_writable_page_tables)) {
+		native_write_cr3(__pa(init_level4_pgt));
+	} else {
+		xen_mc_batch();
+		__xen_write_cr3(true, __pa(init_level4_pgt));
+		xen_mc_issue(PARAVIRT_LAZY_CPU);
+	}
 	/* We can't that easily rip out L3 and L2, as the Xen pagetables are
 	 * set out this way: [L4], [L1], [L2], [L3], [L1], [L1] ...  for
 	 * the initial domain. For guests using the toolstack, they are in:
@@ -2177,8 +2210,19 @@ static const struct pv_mmu_ops xen_mmu_ops __initconst = {
 
 void __init xen_init_mmu_ops(void)
 {
-	x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
 	x86_init.paging.pagetable_init = xen_pagetable_init;
+
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		pv_mmu_ops.flush_tlb_others = xen_flush_tlb_others;
+
+		/* For PCI devices to map iomem. */
+		if (xen_initial_domain()) {
+			pv_mmu_ops.set_pte = native_set_pte;
+			pv_mmu_ops.set_pte_at = native_set_pte_at;
+		}
+		return;
+	}
+	x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
 	pv_mmu_ops = xen_mmu_ops;
 
 	memset(dummy_mapping, 0xff, PAGE_SIZE);
@@ -2414,6 +2458,87 @@ void __init xen_hvm_init_mmu_ops(void)
 }
 #endif
 
+/* Map foreign gmfn, fgmfn, to local pfn, lpfn. This for the user space
+ * creating new guest on PVH dom0 and needs to map domU pages.
+ */
+static int pvh_add_to_xen_p2m(unsigned long lpfn, unsigned long fgmfn,
+			      unsigned int domid)
+{
+	int rc;
+	struct xen_add_to_physmap xatp = { .u.foreign_domid = domid };
+
+	xatp.gpfn = lpfn;
+	xatp.idx = fgmfn;
+	xatp.domid = DOMID_SELF;
+	xatp.space = XENMAPSPACE_gmfn_foreign;
+	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
+	if (rc)
+		pr_warn("d0: Failed to map pfn (0x%lx) to mfn (0x%lx) rc:%d\n",
+			lpfn, fgmfn, rc);
+	return rc;
+}
+
+static int pvh_rem_xen_p2m(unsigned long spfn, int count)
+{
+	struct xen_remove_from_physmap xrp;
+	int i, rc;
+
+	for (i = 0; i < count; i++) {
+		xrp.domid = DOMID_SELF;
+		xrp.gpfn = spfn+i;
+		rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, &xrp);
+		if (rc) {
+			pr_warn("Failed to unmap pfn:%lx rc:%d done:%d\n",
+				spfn+i, rc, i);
+			return 1;
+		}
+	}
+	return 0;
+}
+
+struct pvh_remap_data {
+	unsigned long fgmfn;		/* foreign domain's gmfn */
+	pgprot_t prot;
+	domid_t  domid;
+	int	 index;
+	struct page **pages;
+};
+
+static int pvh_map_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr,
+			void *data)
+{
+	int rc;
+	struct pvh_remap_data *remap = data;
+	unsigned long pfn = page_to_pfn(remap->pages[remap->index++]);
+	pte_t pteval = pte_mkspecial(pfn_pte(pfn, remap->prot));
+
+	rc = pvh_add_to_xen_p2m(pfn, remap->fgmfn, remap->domid);
+	if (rc)
+		return rc;
+	native_set_pte(ptep, pteval);
+
+	return 0;
+}
+
+static int pvh_remap_gmfn_range(struct vm_area_struct *vma,
+				unsigned long addr, unsigned long mfn, int nr,
+				pgprot_t prot, unsigned domid,
+				struct page **pages)
+{
+	int err;
+	struct pvh_remap_data pvhdata;
+
+	pvhdata.fgmfn = mfn;
+	pvhdata.prot = prot;
+	pvhdata.domid = domid;
+	pvhdata.index = 0;
+	pvhdata.pages = pages;
+	err = apply_to_page_range(vma->vm_mm, addr, nr << PAGE_SHIFT,
+				  pvh_map_pte_fn, &pvhdata);
+	flush_tlb_all();
+	return err;
+}
+
 #define REMAP_BATCH_SIZE 16
 
 struct remap_data {
@@ -2438,7 +2563,9 @@ static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token,
 int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 			       unsigned long addr,
 			       unsigned long mfn, int nr,
-			       pgprot_t prot, unsigned domid)
+			       pgprot_t prot, unsigned domid,
+			       struct page **pages)
+
 {
 	struct remap_data rmd;
 	struct mmu_update mmu_update[REMAP_BATCH_SIZE];
@@ -2446,14 +2573,17 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 	unsigned long range;
 	int err = 0;
 
-	if (xen_feature(XENFEAT_auto_translated_physmap))
-		return -EINVAL;
-
 	prot = __pgprot(pgprot_val(prot) | _PAGE_IOMAP);
 
 	BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_RESERVED | VM_IO)) ==
 				(VM_PFNMAP | VM_RESERVED | VM_IO)));
 
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		/* We need to update the local page tables and the xen HAP */
+		return pvh_remap_gmfn_range(vma, addr, mfn, nr, prot, domid,
+					    pages);
+	}
+
 	rmd.mfn = mfn;
 	rmd.prot = prot;
 
@@ -2483,3 +2613,27 @@ out:
 	return err;
 }
 EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
+
+/* Returns: 0 success */
+int xen_unmap_domain_mfn_range(struct vm_area_struct *vma)
+{
+	int numpgs = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
+	struct page **pages = vma ? vma->vm_private_data : NULL;
+
+	if (!pages || !xen_feature(XENFEAT_auto_translated_physmap))
+		return 0;
+
+	while (numpgs--) {
+
+		/* the mmu has already cleaned up the process mmu resources at
+		 * this point (lookup_address will return NULL). */
+		unsigned long pfn = page_to_pfn(pages[numpgs]);
+
+		pvh_rem_xen_p2m(pfn, 1);
+	}
+	/* We don't need to flush tlbs because as part of pvh_rem_xen_p2m(),
+	 * the hypervisor will do tlb flushes after removing the p2m entries
+	 * from the EPT/NPT */
+	return 0;
+}
+EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range);
diff --git a/arch/x86/xen/mmu.h b/arch/x86/xen/mmu.h
index 73809bb..6d0bb56 100644
--- a/arch/x86/xen/mmu.h
+++ b/arch/x86/xen/mmu.h
@@ -23,4 +23,6 @@ unsigned long xen_read_cr2_direct(void);
 
 extern void xen_init_mmu_ops(void);
 extern void xen_hvm_init_mmu_ops(void);
+extern void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn,
+				     int nr_mfns, int add_mapping);
 #endif	/* _XEN_MMU_H */
diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index ef63895..63d9ee8 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -178,7 +178,7 @@ static int mmap_mfn_range(void *data, void *state)
 					msg->va & PAGE_MASK,
 					msg->mfn, msg->npages,
 					vma->vm_page_prot,
-					st->domain);
+					st->domain, NULL);
 	if (rc < 0)
 		return rc;
 
@@ -267,7 +267,8 @@ static int mmap_batch_fn(void *data, void *state)
 	int ret;
 
 	ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
-					 st->vma->vm_page_prot, st->domain);
+					 st->vma->vm_page_prot, st->domain,
+					 NULL);
 
 	/* Store error code for second pass. */
 	*(st->err++) = ret;
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 6a198e4..8b24315 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -27,6 +27,8 @@ struct vm_area_struct;
 int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 			       unsigned long addr,
 			       unsigned long mfn, int nr,
-			       pgprot_t prot, unsigned domid);
+			       pgprot_t prot, unsigned domid,
+			       struct page **pages);
+int xen_unmap_domain_mfn_range(struct vm_area_struct *vma);
 
 #endif /* INCLUDE_XEN_OPS_H */
-- 
1.7.2.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 21:59:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 21:59:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMQn2-0004Jo-Ap; Thu, 11 Oct 2012 21:59:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1TMQn0-0004Jb-9Y
	for Xen-devel@lists.xensource.com; Thu, 11 Oct 2012 21:59:34 +0000
Received: from [85.158.139.83:47725] by server-4.bemta-5.messagelabs.com id
	F3/23-18688-54147705; Thu, 11 Oct 2012 21:59:33 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1349992771!30597975!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzk5MDU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3677 invoked from network); 11 Oct 2012 21:59:32 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Oct 2012 21:59:32 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9BLxUO0018630
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 11 Oct 2012 21:59:30 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9BLxTID023983
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 11 Oct 2012 21:59:29 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9BLxTRm023730; Thu, 11 Oct 2012 16:59:29 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 11 Oct 2012 14:59:28 -0700
Date: Thu, 11 Oct 2012 14:59:27 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Message-ID: <20121011145927.3e740233@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: [Xen-devel] [PATCH V2 4/7]: PVH: bootup and setup related changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

PVH: bootup and setup related changes. enlighten.c: for PVH we can trap
cpuid via vmexit, so don't need to use emulated prefix call. Check for
vector callback early on, as it is a required feature. PVH runs at
default kernel iopl. setup.c: in xen_add_extra_mem() we can skip
updating p2m as it's managed by xen. PVH maps the entire IO space, but
only RAM pages need to be repopulated. Finally, pure PV settings are
moved to a separate function that is only called for pure pv, ie, pv
with pvmmu.

Signed-off-by: Mukesh R <mukesh.rathor@oracle.com>
---
 arch/x86/xen/enlighten.c |   78 ++++++++++++++++++++++++++++++++++------------
 arch/x86/xen/setup.c     |   64 ++++++++++++++++++++++++++++++-------
 2 files changed, 110 insertions(+), 32 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 2d932c3..5199258 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -44,6 +44,7 @@
 #include <xen/hvm.h>
 #include <xen/hvc-console.h>
 #include <xen/acpi.h>
+#include <xen/features.h>
 
 #include <asm/paravirt.h>
 #include <asm/apic.h>
@@ -106,6 +107,9 @@ RESERVE_BRK(shared_info_page_brk, PAGE_SIZE);
 __read_mostly int xen_have_vector_callback;
 EXPORT_SYMBOL_GPL(xen_have_vector_callback);
 
+#define xen_pvh_domain() (xen_pv_domain() && \
+			  xen_feature(XENFEAT_auto_translated_physmap) && \
+			  xen_have_vector_callback)
 /*
  * Point at some empty memory to start with. We map the real shared_info
  * page as soon as fixmap is up and running.
@@ -218,8 +222,9 @@ static void __init xen_banner(void)
 	struct xen_extraversion extra;
 	HYPERVISOR_xen_version(XENVER_extraversion, &extra);
 
-	printk(KERN_INFO "Booting paravirtualized kernel on %s\n",
-	       pv_info.name);
+	pr_info("Booting paravirtualized kernel %son %s\n",
+		xen_feature(XENFEAT_auto_translated_physmap) ?
+			"with PVH extensions " : "", pv_info.name);
 	printk(KERN_INFO "Xen version: %d.%d%s%s\n",
 	       version >> 16, version & 0xffff, extra.extraversion,
 	       xen_feature(XENFEAT_mmu_pt_update_preserve_ad) ? " (preserve-AD)" : "");
@@ -272,12 +277,15 @@ static void xen_cpuid(unsigned int *ax, unsigned int *bx,
 		break;
 	}
 
-	asm(XEN_EMULATE_PREFIX "cpuid"
-		: "=a" (*ax),
-		  "=b" (*bx),
-		  "=c" (*cx),
-		  "=d" (*dx)
-		: "0" (*ax), "2" (*cx));
+	if (xen_pvh_domain())
+		native_cpuid(ax, bx, cx, dx);
+	else
+		asm(XEN_EMULATE_PREFIX "cpuid"
+			: "=a" (*ax),
+			"=b" (*bx),
+			"=c" (*cx),
+			"=d" (*dx)
+			: "0" (*ax), "2" (*cx));
 
 	*bx &= maskebx;
 	*cx &= maskecx;
@@ -1045,6 +1053,10 @@ void xen_setup_shared_info(void)
 		HYPERVISOR_shared_info =
 			(struct shared_info *)__va(xen_start_info->shared_info);
 
+	/* PVH TBD/FIXME: vcpu info placement in phase 2 */
+	if (xen_pvh_domain())
+		return;
+
 #ifndef CONFIG_SMP
 	/* In UP this is as good a place as any to set up shared info */
 	xen_setup_vcpu_info_placement();
@@ -1275,6 +1287,11 @@ static const struct machine_ops xen_machine_ops __initconst = {
  */
 static void __init xen_setup_stackprotector(void)
 {
+	/* PVH TBD/FIXME: investigate setup_stack_canary_segment */
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		switch_to_new_gdt(0);
+		return;
+	}
 	pv_cpu_ops.write_gdt_entry = xen_write_gdt_entry_boot;
 	pv_cpu_ops.load_gdt = xen_load_gdt_boot;
 
@@ -1285,6 +1302,19 @@ static void __init xen_setup_stackprotector(void)
 	pv_cpu_ops.load_gdt = xen_load_gdt;
 }
 
+static void __init xen_pvh_early_guest_init(void)
+{
+	if (xen_feature(XENFEAT_hvm_callback_vector))
+		xen_have_vector_callback = 1;
+
+#ifdef CONFIG_X86_32
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		xen_raw_printk("ERROR: 32bit PVH guests are not supported\n");
+		BUG();
+	}
+#endif
+}
+
 /* First C function to be called on Xen boot */
 asmlinkage void __init xen_start_kernel(void)
 {
@@ -1296,13 +1326,18 @@ asmlinkage void __init xen_start_kernel(void)
 
 	xen_domain_type = XEN_PV_DOMAIN;
 
+	xen_setup_features();
+	xen_pvh_early_guest_init();
 	xen_setup_machphys_mapping();
 
 	/* Install Xen paravirt ops */
 	pv_info = xen_info;
 	pv_init_ops = xen_init_ops;
-	pv_cpu_ops = xen_cpu_ops;
 	pv_apic_ops = xen_apic_ops;
+	if (xen_pvh_domain())
+		pv_cpu_ops.cpuid = xen_cpuid;
+	else
+		pv_cpu_ops = xen_cpu_ops;
 
 	x86_init.resources.memory_setup = xen_memory_setup;
 	x86_init.oem.arch_setup = xen_arch_setup;
@@ -1334,8 +1369,6 @@ asmlinkage void __init xen_start_kernel(void)
 	/* Work out if we support NX */
 	x86_configure_nx();
 
-	xen_setup_features();
-
 	/* Get mfn list */
 	if (!xen_feature(XENFEAT_auto_translated_physmap))
 		xen_build_dynamic_phys_to_machine();
@@ -1406,14 +1439,18 @@ asmlinkage void __init xen_start_kernel(void)
 	/* set the limit of our address space */
 	xen_reserve_top();
 
-	/* We used to do this in xen_arch_setup, but that is too late on AMD
-	 * were early_cpu_init (run before ->arch_setup()) calls early_amd_init
-	 * which pokes 0xcf8 port.
-	 */
-	set_iopl.iopl = 1;
-	rc = HYPERVISOR_physdev_op(PHYSDEVOP_set_iopl, &set_iopl);
-	if (rc != 0)
-		xen_raw_printk("physdev_op failed %d\n", rc);
+	/* PVH: runs at default kernel iopl of 0 */
+	if (!xen_pvh_domain()) {
+		/*
+		 * We used to do this in xen_arch_setup, but that is too late
+		 * on AMD were early_cpu_init (run before ->arch_setup()) calls
+		 * early_amd_init which pokes 0xcf8 port.
+		 */
+		set_iopl.iopl = 1;
+		rc = HYPERVISOR_physdev_op(PHYSDEVOP_set_iopl, &set_iopl);
+		if (rc != 0)
+			xen_raw_printk("physdev_op failed %d\n", rc);
+	}
 
 #ifdef CONFIG_X86_32
 	/* set up basic CPUID stuff */
@@ -1479,7 +1516,8 @@ asmlinkage void __init xen_start_kernel(void)
 	x86_64_start_reservations((char *)__pa_symbol(&boot_params));
 #endif
 }
-
+/* Use a pfn in RAM, may move to MMIO before kexec.
+ * This function also called for PVH dom0 */
 void __ref xen_hvm_init_shared_info(void)
 {
 	int cpu;
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 8971a26..8cce47b 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -27,6 +27,7 @@
 #include <xen/interface/memory.h>
 #include <xen/interface/physdev.h>
 #include <xen/features.h>
+#include "mmu.h"
 #include "xen-ops.h"
 #include "vdso.h"
 
@@ -78,6 +79,9 @@ static void __init xen_add_extra_mem(u64 start, u64 size)
 
 	memblock_reserve(start, size);
 
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return;
+
 	xen_max_p2m_pfn = PFN_DOWN(start + size);
 	for (pfn = PFN_DOWN(start); pfn < xen_max_p2m_pfn; pfn++) {
 		unsigned long mfn = pfn_to_mfn(pfn);
@@ -100,6 +104,7 @@ static unsigned long __init xen_do_chunk(unsigned long start,
 		.domid        = DOMID_SELF
 	};
 	unsigned long len = 0;
+	int xlated_phys = xen_feature(XENFEAT_auto_translated_physmap);
 	unsigned long pfn;
 	int ret;
 
@@ -113,7 +118,7 @@ static unsigned long __init xen_do_chunk(unsigned long start,
 				continue;
 			frame = mfn;
 		} else {
-			if (mfn != INVALID_P2M_ENTRY)
+			if (!xlated_phys && mfn != INVALID_P2M_ENTRY)
 				continue;
 			frame = pfn;
 		}
@@ -230,6 +235,27 @@ static void __init xen_set_identity_and_release_chunk(
 	*identity += set_phys_range_identity(start_pfn, end_pfn);
 }
 
+/* For PVH, the pfns [0..MAX] are mapped to mfn's in the EPT/NPT. The mfns
+ * are released as part of this 1:1 mapping hypercall back to the dom heap.
+ * Also, we map the entire IO space, ie, beyond max_pfn_mapped.
+ */
+static void __init xen_pvh_identity_map_chunk(unsigned long start_pfn,
+		unsigned long end_pfn, unsigned long *released,
+		unsigned long *identity, unsigned long max_pfn)
+{
+	unsigned long pfn;
+	int numpfns = 1, add_mapping = 1;
+
+	for (pfn = start_pfn; pfn < end_pfn; pfn++)
+		xen_set_clr_mmio_pvh_pte(pfn, pfn, numpfns, add_mapping);
+
+	if (start_pfn <= max_pfn) {
+		unsigned long end = min(max_pfn_mapped, end_pfn);
+		*released += end - start_pfn;
+	}
+	*identity += end_pfn - start_pfn;
+}
+
 static unsigned long __init xen_set_identity_and_release(
 	const struct e820entry *list, size_t map_size, unsigned long nr_pages)
 {
@@ -238,6 +264,7 @@ static unsigned long __init xen_set_identity_and_release(
 	unsigned long identity = 0;
 	const struct e820entry *entry;
 	int i;
+	int xlated_phys = xen_feature(XENFEAT_auto_translated_physmap);
 
 	/*
 	 * Combine non-RAM regions and gaps until a RAM region (or the
@@ -259,11 +286,17 @@ static unsigned long __init xen_set_identity_and_release(
 			if (entry->type == E820_RAM)
 				end_pfn = PFN_UP(entry->addr);
 
-			if (start_pfn < end_pfn)
-				xen_set_identity_and_release_chunk(
-					start_pfn, end_pfn, nr_pages,
-					&released, &identity);
-
+			if (start_pfn < end_pfn) {
+				if (xlated_phys) {
+					xen_pvh_identity_map_chunk(start_pfn,
+						end_pfn, &released, &identity,
+						nr_pages);
+				} else {
+					xen_set_identity_and_release_chunk(
+						start_pfn, end_pfn, nr_pages,
+						&released, &identity);
+				}
+			}
 			start = end;
 		}
 	}
@@ -526,16 +559,14 @@ void __cpuinit xen_enable_syscall(void)
 #endif /* CONFIG_X86_64 */
 }
 
-void __init xen_arch_setup(void)
+/* Non auto translated PV domain, ie, it's not PVH. */
+static __init void xen_pvmmu_arch_setup(void)
 {
-	xen_panic_handler_init();
-
 	HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_4gb_segments);
 	HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_writable_pagetables);
 
-	if (!xen_feature(XENFEAT_auto_translated_physmap))
-		HYPERVISOR_vm_assist(VMASST_CMD_enable,
-				     VMASST_TYPE_pae_extended_cr3);
+	HYPERVISOR_vm_assist(VMASST_CMD_enable,
+			     VMASST_TYPE_pae_extended_cr3);
 
 	if (register_callback(CALLBACKTYPE_event, xen_hypervisor_callback) ||
 	    register_callback(CALLBACKTYPE_failsafe, xen_failsafe_callback))
@@ -543,6 +574,15 @@ void __init xen_arch_setup(void)
 
 	xen_enable_sysenter();
 	xen_enable_syscall();
+}
+
+/* This function not called for HVM domain */
+void __init xen_arch_setup(void)
+{
+	xen_panic_handler_init();
+
+	if (!xen_feature(XENFEAT_auto_translated_physmap))
+		xen_pvmmu_arch_setup();
 
 #ifdef CONFIG_ACPI
 	if (!(xen_start_info->flags & SIF_INITDOMAIN)) {
-- 
1.7.2.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 21:59:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 21:59:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMQn2-0004Jo-Ap; Thu, 11 Oct 2012 21:59:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1TMQn0-0004Jb-9Y
	for Xen-devel@lists.xensource.com; Thu, 11 Oct 2012 21:59:34 +0000
Received: from [85.158.139.83:47725] by server-4.bemta-5.messagelabs.com id
	F3/23-18688-54147705; Thu, 11 Oct 2012 21:59:33 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1349992771!30597975!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzk5MDU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3677 invoked from network); 11 Oct 2012 21:59:32 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Oct 2012 21:59:32 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9BLxUO0018630
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 11 Oct 2012 21:59:30 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9BLxTID023983
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 11 Oct 2012 21:59:29 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9BLxTRm023730; Thu, 11 Oct 2012 16:59:29 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 11 Oct 2012 14:59:28 -0700
Date: Thu, 11 Oct 2012 14:59:27 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Message-ID: <20121011145927.3e740233@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: [Xen-devel] [PATCH V2 4/7]: PVH: bootup and setup related changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

PVH: bootup and setup related changes. enlighten.c: for PVH we can trap
cpuid via vmexit, so don't need to use emulated prefix call. Check for
vector callback early on, as it is a required feature. PVH runs at
default kernel iopl. setup.c: in xen_add_extra_mem() we can skip
updating p2m as it's managed by xen. PVH maps the entire IO space, but
only RAM pages need to be repopulated. Finally, pure PV settings are
moved to a separate function that is only called for pure pv, ie, pv
with pvmmu.

Signed-off-by: Mukesh R <mukesh.rathor@oracle.com>
---
 arch/x86/xen/enlighten.c |   78 ++++++++++++++++++++++++++++++++++------------
 arch/x86/xen/setup.c     |   64 ++++++++++++++++++++++++++++++-------
 2 files changed, 110 insertions(+), 32 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 2d932c3..5199258 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -44,6 +44,7 @@
 #include <xen/hvm.h>
 #include <xen/hvc-console.h>
 #include <xen/acpi.h>
+#include <xen/features.h>
 
 #include <asm/paravirt.h>
 #include <asm/apic.h>
@@ -106,6 +107,9 @@ RESERVE_BRK(shared_info_page_brk, PAGE_SIZE);
 __read_mostly int xen_have_vector_callback;
 EXPORT_SYMBOL_GPL(xen_have_vector_callback);
 
+#define xen_pvh_domain() (xen_pv_domain() && \
+			  xen_feature(XENFEAT_auto_translated_physmap) && \
+			  xen_have_vector_callback)
 /*
  * Point at some empty memory to start with. We map the real shared_info
  * page as soon as fixmap is up and running.
@@ -218,8 +222,9 @@ static void __init xen_banner(void)
 	struct xen_extraversion extra;
 	HYPERVISOR_xen_version(XENVER_extraversion, &extra);
 
-	printk(KERN_INFO "Booting paravirtualized kernel on %s\n",
-	       pv_info.name);
+	pr_info("Booting paravirtualized kernel %son %s\n",
+		xen_feature(XENFEAT_auto_translated_physmap) ?
+			"with PVH extensions " : "", pv_info.name);
 	printk(KERN_INFO "Xen version: %d.%d%s%s\n",
 	       version >> 16, version & 0xffff, extra.extraversion,
 	       xen_feature(XENFEAT_mmu_pt_update_preserve_ad) ? " (preserve-AD)" : "");
@@ -272,12 +277,15 @@ static void xen_cpuid(unsigned int *ax, unsigned int *bx,
 		break;
 	}
 
-	asm(XEN_EMULATE_PREFIX "cpuid"
-		: "=a" (*ax),
-		  "=b" (*bx),
-		  "=c" (*cx),
-		  "=d" (*dx)
-		: "0" (*ax), "2" (*cx));
+	if (xen_pvh_domain())
+		native_cpuid(ax, bx, cx, dx);
+	else
+		asm(XEN_EMULATE_PREFIX "cpuid"
+			: "=a" (*ax),
+			"=b" (*bx),
+			"=c" (*cx),
+			"=d" (*dx)
+			: "0" (*ax), "2" (*cx));
 
 	*bx &= maskebx;
 	*cx &= maskecx;
@@ -1045,6 +1053,10 @@ void xen_setup_shared_info(void)
 		HYPERVISOR_shared_info =
 			(struct shared_info *)__va(xen_start_info->shared_info);
 
+	/* PVH TBD/FIXME: vcpu info placement in phase 2 */
+	if (xen_pvh_domain())
+		return;
+
 #ifndef CONFIG_SMP
 	/* In UP this is as good a place as any to set up shared info */
 	xen_setup_vcpu_info_placement();
@@ -1275,6 +1287,11 @@ static const struct machine_ops xen_machine_ops __initconst = {
  */
 static void __init xen_setup_stackprotector(void)
 {
+	/* PVH TBD/FIXME: investigate setup_stack_canary_segment */
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		switch_to_new_gdt(0);
+		return;
+	}
 	pv_cpu_ops.write_gdt_entry = xen_write_gdt_entry_boot;
 	pv_cpu_ops.load_gdt = xen_load_gdt_boot;
 
@@ -1285,6 +1302,19 @@ static void __init xen_setup_stackprotector(void)
 	pv_cpu_ops.load_gdt = xen_load_gdt;
 }
 
+static void __init xen_pvh_early_guest_init(void)
+{
+	if (xen_feature(XENFEAT_hvm_callback_vector))
+		xen_have_vector_callback = 1;
+
+#ifdef CONFIG_X86_32
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		xen_raw_printk("ERROR: 32bit PVH guests are not supported\n");
+		BUG();
+	}
+#endif
+}
+
 /* First C function to be called on Xen boot */
 asmlinkage void __init xen_start_kernel(void)
 {
@@ -1296,13 +1326,18 @@ asmlinkage void __init xen_start_kernel(void)
 
 	xen_domain_type = XEN_PV_DOMAIN;
 
+	xen_setup_features();
+	xen_pvh_early_guest_init();
 	xen_setup_machphys_mapping();
 
 	/* Install Xen paravirt ops */
 	pv_info = xen_info;
 	pv_init_ops = xen_init_ops;
-	pv_cpu_ops = xen_cpu_ops;
 	pv_apic_ops = xen_apic_ops;
+	if (xen_pvh_domain())
+		pv_cpu_ops.cpuid = xen_cpuid;
+	else
+		pv_cpu_ops = xen_cpu_ops;
 
 	x86_init.resources.memory_setup = xen_memory_setup;
 	x86_init.oem.arch_setup = xen_arch_setup;
@@ -1334,8 +1369,6 @@ asmlinkage void __init xen_start_kernel(void)
 	/* Work out if we support NX */
 	x86_configure_nx();
 
-	xen_setup_features();
-
 	/* Get mfn list */
 	if (!xen_feature(XENFEAT_auto_translated_physmap))
 		xen_build_dynamic_phys_to_machine();
@@ -1406,14 +1439,18 @@ asmlinkage void __init xen_start_kernel(void)
 	/* set the limit of our address space */
 	xen_reserve_top();
 
-	/* We used to do this in xen_arch_setup, but that is too late on AMD
-	 * were early_cpu_init (run before ->arch_setup()) calls early_amd_init
-	 * which pokes 0xcf8 port.
-	 */
-	set_iopl.iopl = 1;
-	rc = HYPERVISOR_physdev_op(PHYSDEVOP_set_iopl, &set_iopl);
-	if (rc != 0)
-		xen_raw_printk("physdev_op failed %d\n", rc);
+	/* PVH: runs at default kernel iopl of 0 */
+	if (!xen_pvh_domain()) {
+		/*
+		 * We used to do this in xen_arch_setup, but that is too late
+		 * on AMD were early_cpu_init (run before ->arch_setup()) calls
+		 * early_amd_init which pokes 0xcf8 port.
+		 */
+		set_iopl.iopl = 1;
+		rc = HYPERVISOR_physdev_op(PHYSDEVOP_set_iopl, &set_iopl);
+		if (rc != 0)
+			xen_raw_printk("physdev_op failed %d\n", rc);
+	}
 
 #ifdef CONFIG_X86_32
 	/* set up basic CPUID stuff */
@@ -1479,7 +1516,8 @@ asmlinkage void __init xen_start_kernel(void)
 	x86_64_start_reservations((char *)__pa_symbol(&boot_params));
 #endif
 }
-
+/* Use a pfn in RAM, may move to MMIO before kexec.
+ * This function also called for PVH dom0 */
 void __ref xen_hvm_init_shared_info(void)
 {
 	int cpu;
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 8971a26..8cce47b 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -27,6 +27,7 @@
 #include <xen/interface/memory.h>
 #include <xen/interface/physdev.h>
 #include <xen/features.h>
+#include "mmu.h"
 #include "xen-ops.h"
 #include "vdso.h"
 
@@ -78,6 +79,9 @@ static void __init xen_add_extra_mem(u64 start, u64 size)
 
 	memblock_reserve(start, size);
 
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return;
+
 	xen_max_p2m_pfn = PFN_DOWN(start + size);
 	for (pfn = PFN_DOWN(start); pfn < xen_max_p2m_pfn; pfn++) {
 		unsigned long mfn = pfn_to_mfn(pfn);
@@ -100,6 +104,7 @@ static unsigned long __init xen_do_chunk(unsigned long start,
 		.domid        = DOMID_SELF
 	};
 	unsigned long len = 0;
+	int xlated_phys = xen_feature(XENFEAT_auto_translated_physmap);
 	unsigned long pfn;
 	int ret;
 
@@ -113,7 +118,7 @@ static unsigned long __init xen_do_chunk(unsigned long start,
 				continue;
 			frame = mfn;
 		} else {
-			if (mfn != INVALID_P2M_ENTRY)
+			if (!xlated_phys && mfn != INVALID_P2M_ENTRY)
 				continue;
 			frame = pfn;
 		}
@@ -230,6 +235,27 @@ static void __init xen_set_identity_and_release_chunk(
 	*identity += set_phys_range_identity(start_pfn, end_pfn);
 }
 
+/* For PVH, the pfns [0..MAX] are mapped to mfn's in the EPT/NPT. The mfns
+ * are released as part of this 1:1 mapping hypercall back to the dom heap.
+ * Also, we map the entire IO space, ie, beyond max_pfn_mapped.
+ */
+static void __init xen_pvh_identity_map_chunk(unsigned long start_pfn,
+		unsigned long end_pfn, unsigned long *released,
+		unsigned long *identity, unsigned long max_pfn)
+{
+	unsigned long pfn;
+	int numpfns = 1, add_mapping = 1;
+
+	for (pfn = start_pfn; pfn < end_pfn; pfn++)
+		xen_set_clr_mmio_pvh_pte(pfn, pfn, numpfns, add_mapping);
+
+	if (start_pfn <= max_pfn) {
+		unsigned long end = min(max_pfn_mapped, end_pfn);
+		*released += end - start_pfn;
+	}
+	*identity += end_pfn - start_pfn;
+}
+
 static unsigned long __init xen_set_identity_and_release(
 	const struct e820entry *list, size_t map_size, unsigned long nr_pages)
 {
@@ -238,6 +264,7 @@ static unsigned long __init xen_set_identity_and_release(
 	unsigned long identity = 0;
 	const struct e820entry *entry;
 	int i;
+	int xlated_phys = xen_feature(XENFEAT_auto_translated_physmap);
 
 	/*
 	 * Combine non-RAM regions and gaps until a RAM region (or the
@@ -259,11 +286,17 @@ static unsigned long __init xen_set_identity_and_release(
 			if (entry->type == E820_RAM)
 				end_pfn = PFN_UP(entry->addr);
 
-			if (start_pfn < end_pfn)
-				xen_set_identity_and_release_chunk(
-					start_pfn, end_pfn, nr_pages,
-					&released, &identity);
-
+			if (start_pfn < end_pfn) {
+				if (xlated_phys) {
+					xen_pvh_identity_map_chunk(start_pfn,
+						end_pfn, &released, &identity,
+						nr_pages);
+				} else {
+					xen_set_identity_and_release_chunk(
+						start_pfn, end_pfn, nr_pages,
+						&released, &identity);
+				}
+			}
 			start = end;
 		}
 	}
@@ -526,16 +559,14 @@ void __cpuinit xen_enable_syscall(void)
 #endif /* CONFIG_X86_64 */
 }
 
-void __init xen_arch_setup(void)
+/* Non auto translated PV domain, ie, it's not PVH. */
+static __init void xen_pvmmu_arch_setup(void)
 {
-	xen_panic_handler_init();
-
 	HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_4gb_segments);
 	HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_writable_pagetables);
 
-	if (!xen_feature(XENFEAT_auto_translated_physmap))
-		HYPERVISOR_vm_assist(VMASST_CMD_enable,
-				     VMASST_TYPE_pae_extended_cr3);
+	HYPERVISOR_vm_assist(VMASST_CMD_enable,
+			     VMASST_TYPE_pae_extended_cr3);
 
 	if (register_callback(CALLBACKTYPE_event, xen_hypervisor_callback) ||
 	    register_callback(CALLBACKTYPE_failsafe, xen_failsafe_callback))
@@ -543,6 +574,15 @@ void __init xen_arch_setup(void)
 
 	xen_enable_sysenter();
 	xen_enable_syscall();
+}
+
+/* This function not called for HVM domain */
+void __init xen_arch_setup(void)
+{
+	xen_panic_handler_init();
+
+	if (!xen_feature(XENFEAT_auto_translated_physmap))
+		xen_pvmmu_arch_setup();
 
 #ifdef CONFIG_ACPI
 	if (!(xen_start_info->flags & SIF_INITDOMAIN)) {
-- 
1.7.2.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 22:00:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 22:00:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMQns-0004RH-Ub; Thu, 11 Oct 2012 22:00:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1TMQnr-0004Qy-3g
	for Xen-devel@lists.xensource.com; Thu, 11 Oct 2012 22:00:27 +0000
Received: from [85.158.137.99:61962] by server-13.bemta-3.messagelabs.com id
	0A/2D-26794-A7147705; Thu, 11 Oct 2012 22:00:26 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1349992823!16515484!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzk3Njc3\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27317 invoked from network); 11 Oct 2012 22:00:25 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-5.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Oct 2012 22:00:25 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9BM0M5n019570
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 11 Oct 2012 22:00:23 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9BM0Lnr008960
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 11 Oct 2012 22:00:22 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9BM0LBM024469; Thu, 11 Oct 2012 17:00:21 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 11 Oct 2012 15:00:21 -0700
Date: Thu, 11 Oct 2012 15:00:19 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Message-ID: <20121011150019.07d2686f@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: [Xen-devel] [PATCH V2 5/7]: PVH: smp changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

PVH: smp changes. This pertains to bringing up smp vcpus. PVH runs in
ring 0, so syscalls are native. Also, the vcpu context is send down via
the hcall to be set in the vmcs. gdtaddr and gdtsz are unionionized as
PVH only needs to send these two to be set in the vmcs

Signed-off-by: Mukesh R <mukesh.rathor@oracle.com>
---
 arch/x86/xen/smp.c |   75 ++++++++++++++++++++++++++++++++++------------------
 1 files changed, 49 insertions(+), 26 deletions(-)

diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index bd92698..63a0bfb 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -68,9 +68,11 @@ static void __cpuinit cpu_bringup(void)
 	touch_softlockup_watchdog();
 	preempt_disable();
 
-	xen_enable_sysenter();
-	xen_enable_syscall();
-
+	/* PVH runs in ring 0 and allows us to do native syscalls. Yay! */
+	if (!xen_feature(XENFEAT_supervisor_mode_kernel)) {
+		xen_enable_sysenter();
+		xen_enable_syscall();
+	}
 	cpu = smp_processor_id();
 	smp_store_cpu_info(cpu);
 	cpu_data(cpu).x86_max_cores = 1;
@@ -230,10 +232,11 @@ static void __init xen_smp_prepare_boot_cpu(void)
 	BUG_ON(smp_processor_id() != 0);
 	native_smp_prepare_boot_cpu();
 
-	/* We've switched to the "real" per-cpu gdt, so make sure the
-	   old memory can be recycled */
-	make_lowmem_page_readwrite(xen_initial_gdt);
-
+	if (!xen_feature(XENFEAT_writable_page_tables)) {
+		/* We've switched to the "real" per-cpu gdt, so make sure the
+		 * old memory can be recycled */
+		make_lowmem_page_readwrite(xen_initial_gdt);
+	}
 	xen_filter_cpu_maps();
 	xen_setup_vcpu_info_placement();
 }
@@ -300,8 +303,6 @@ cpu_initialize_context(unsigned int cpu, struct task_struct *idle)
 	gdt = get_cpu_gdt_table(cpu);
 
 	ctxt->flags = VGCF_IN_KERNEL;
-	ctxt->user_regs.ds = __USER_DS;
-	ctxt->user_regs.es = __USER_DS;
 	ctxt->user_regs.ss = __KERNEL_DS;
 #ifdef CONFIG_X86_32
 	ctxt->user_regs.fs = __KERNEL_PERCPU;
@@ -310,35 +311,57 @@ cpu_initialize_context(unsigned int cpu, struct task_struct *idle)
 	ctxt->gs_base_kernel = per_cpu_offset(cpu);
 #endif
 	ctxt->user_regs.eip = (unsigned long)cpu_bringup_and_idle;
-	ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
 
 	memset(&ctxt->fpu_ctxt, 0, sizeof(ctxt->fpu_ctxt));
 
-	xen_copy_trap_info(ctxt->trap_ctxt);
+	/* check for autoxlated to get it right for 32bit kernel */
+	if (xen_feature(XENFEAT_auto_translated_physmap) &&
+	    xen_feature(XENFEAT_supervisor_mode_kernel)) {
 
-	ctxt->ldt_ents = 0;
+		ctxt->user_regs.ds = __KERNEL_DS;
+		ctxt->user_regs.es = 0;
+		ctxt->user_regs.gs = 0;
 
-	BUG_ON((unsigned long)gdt & ~PAGE_MASK);
+		ctxt->u.gdtaddr = (unsigned long)gdt;
+		ctxt->u.gdtsz = (unsigned long)(GDT_SIZE - 1);
 
-	gdt_mfn = arbitrary_virt_to_mfn(gdt);
-	make_lowmem_page_readonly(gdt);
-	make_lowmem_page_readonly(mfn_to_virt(gdt_mfn));
+#ifdef CONFIG_X86_64
+		/* Note: PVH is not supported on x86_32. */
+		ctxt->gs_base_user = (unsigned long)
+					per_cpu(irq_stack_union.gs_base, cpu);
+#endif
+	} else {
+		ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
+		ctxt->user_regs.ds = __USER_DS;
+		ctxt->user_regs.es = __USER_DS;
 
-	ctxt->u.s.gdt_frames[0] = gdt_mfn;
-	ctxt->u.s.gdt_ents      = GDT_ENTRIES;
+		xen_copy_trap_info(ctxt->trap_ctxt);
 
-	ctxt->user_regs.cs = __KERNEL_CS;
-	ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct pt_regs);
+		ctxt->ldt_ents = 0;
 
-	ctxt->kernel_ss = __KERNEL_DS;
-	ctxt->kernel_sp = idle->thread.sp0;
+		BUG_ON((unsigned long)gdt & ~PAGE_MASK);
+
+		gdt_mfn = arbitrary_virt_to_mfn(gdt);
+		make_lowmem_page_readonly(gdt);
+		make_lowmem_page_readonly(mfn_to_virt(gdt_mfn));
+
+		ctxt->u.s.gdt_frames[0] = gdt_mfn;
+		ctxt->u.s.gdt_ents      = GDT_ENTRIES;
+
+		ctxt->kernel_ss = __KERNEL_DS;
+		ctxt->kernel_sp = idle->thread.sp0;
 
 #ifdef CONFIG_X86_32
-	ctxt->event_callback_cs     = __KERNEL_CS;
-	ctxt->failsafe_callback_cs  = __KERNEL_CS;
+		ctxt->event_callback_cs     = __KERNEL_CS;
+		ctxt->failsafe_callback_cs  = __KERNEL_CS;
 #endif
-	ctxt->event_callback_eip    = (unsigned long)xen_hypervisor_callback;
-	ctxt->failsafe_callback_eip = (unsigned long)xen_failsafe_callback;
+		ctxt->event_callback_eip    =
+					(unsigned long)xen_hypervisor_callback;
+		ctxt->failsafe_callback_eip =
+					(unsigned long)xen_failsafe_callback;
+	}
+	ctxt->user_regs.cs = __KERNEL_CS;
+	ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct pt_regs);
 
 	per_cpu(xen_cr3, cpu) = __pa(swapper_pg_dir);
 	ctxt->ctrlreg[3] = xen_pfn_to_cr3(virt_to_mfn(swapper_pg_dir));
-- 
1.7.2.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 22:00:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 22:00:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMQns-0004RH-Ub; Thu, 11 Oct 2012 22:00:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1TMQnr-0004Qy-3g
	for Xen-devel@lists.xensource.com; Thu, 11 Oct 2012 22:00:27 +0000
Received: from [85.158.137.99:61962] by server-13.bemta-3.messagelabs.com id
	0A/2D-26794-A7147705; Thu, 11 Oct 2012 22:00:26 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1349992823!16515484!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzk3Njc3\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27317 invoked from network); 11 Oct 2012 22:00:25 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-5.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Oct 2012 22:00:25 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9BM0M5n019570
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 11 Oct 2012 22:00:23 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9BM0Lnr008960
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 11 Oct 2012 22:00:22 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9BM0LBM024469; Thu, 11 Oct 2012 17:00:21 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 11 Oct 2012 15:00:21 -0700
Date: Thu, 11 Oct 2012 15:00:19 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Message-ID: <20121011150019.07d2686f@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: [Xen-devel] [PATCH V2 5/7]: PVH: smp changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

PVH: smp changes. This pertains to bringing up smp vcpus. PVH runs in
ring 0, so syscalls are native. Also, the vcpu context is send down via
the hcall to be set in the vmcs. gdtaddr and gdtsz are unionionized as
PVH only needs to send these two to be set in the vmcs

Signed-off-by: Mukesh R <mukesh.rathor@oracle.com>
---
 arch/x86/xen/smp.c |   75 ++++++++++++++++++++++++++++++++++------------------
 1 files changed, 49 insertions(+), 26 deletions(-)

diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index bd92698..63a0bfb 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -68,9 +68,11 @@ static void __cpuinit cpu_bringup(void)
 	touch_softlockup_watchdog();
 	preempt_disable();
 
-	xen_enable_sysenter();
-	xen_enable_syscall();
-
+	/* PVH runs in ring 0 and allows us to do native syscalls. Yay! */
+	if (!xen_feature(XENFEAT_supervisor_mode_kernel)) {
+		xen_enable_sysenter();
+		xen_enable_syscall();
+	}
 	cpu = smp_processor_id();
 	smp_store_cpu_info(cpu);
 	cpu_data(cpu).x86_max_cores = 1;
@@ -230,10 +232,11 @@ static void __init xen_smp_prepare_boot_cpu(void)
 	BUG_ON(smp_processor_id() != 0);
 	native_smp_prepare_boot_cpu();
 
-	/* We've switched to the "real" per-cpu gdt, so make sure the
-	   old memory can be recycled */
-	make_lowmem_page_readwrite(xen_initial_gdt);
-
+	if (!xen_feature(XENFEAT_writable_page_tables)) {
+		/* We've switched to the "real" per-cpu gdt, so make sure the
+		 * old memory can be recycled */
+		make_lowmem_page_readwrite(xen_initial_gdt);
+	}
 	xen_filter_cpu_maps();
 	xen_setup_vcpu_info_placement();
 }
@@ -300,8 +303,6 @@ cpu_initialize_context(unsigned int cpu, struct task_struct *idle)
 	gdt = get_cpu_gdt_table(cpu);
 
 	ctxt->flags = VGCF_IN_KERNEL;
-	ctxt->user_regs.ds = __USER_DS;
-	ctxt->user_regs.es = __USER_DS;
 	ctxt->user_regs.ss = __KERNEL_DS;
 #ifdef CONFIG_X86_32
 	ctxt->user_regs.fs = __KERNEL_PERCPU;
@@ -310,35 +311,57 @@ cpu_initialize_context(unsigned int cpu, struct task_struct *idle)
 	ctxt->gs_base_kernel = per_cpu_offset(cpu);
 #endif
 	ctxt->user_regs.eip = (unsigned long)cpu_bringup_and_idle;
-	ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
 
 	memset(&ctxt->fpu_ctxt, 0, sizeof(ctxt->fpu_ctxt));
 
-	xen_copy_trap_info(ctxt->trap_ctxt);
+	/* check for autoxlated to get it right for 32bit kernel */
+	if (xen_feature(XENFEAT_auto_translated_physmap) &&
+	    xen_feature(XENFEAT_supervisor_mode_kernel)) {
 
-	ctxt->ldt_ents = 0;
+		ctxt->user_regs.ds = __KERNEL_DS;
+		ctxt->user_regs.es = 0;
+		ctxt->user_regs.gs = 0;
 
-	BUG_ON((unsigned long)gdt & ~PAGE_MASK);
+		ctxt->u.gdtaddr = (unsigned long)gdt;
+		ctxt->u.gdtsz = (unsigned long)(GDT_SIZE - 1);
 
-	gdt_mfn = arbitrary_virt_to_mfn(gdt);
-	make_lowmem_page_readonly(gdt);
-	make_lowmem_page_readonly(mfn_to_virt(gdt_mfn));
+#ifdef CONFIG_X86_64
+		/* Note: PVH is not supported on x86_32. */
+		ctxt->gs_base_user = (unsigned long)
+					per_cpu(irq_stack_union.gs_base, cpu);
+#endif
+	} else {
+		ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
+		ctxt->user_regs.ds = __USER_DS;
+		ctxt->user_regs.es = __USER_DS;
 
-	ctxt->u.s.gdt_frames[0] = gdt_mfn;
-	ctxt->u.s.gdt_ents      = GDT_ENTRIES;
+		xen_copy_trap_info(ctxt->trap_ctxt);
 
-	ctxt->user_regs.cs = __KERNEL_CS;
-	ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct pt_regs);
+		ctxt->ldt_ents = 0;
 
-	ctxt->kernel_ss = __KERNEL_DS;
-	ctxt->kernel_sp = idle->thread.sp0;
+		BUG_ON((unsigned long)gdt & ~PAGE_MASK);
+
+		gdt_mfn = arbitrary_virt_to_mfn(gdt);
+		make_lowmem_page_readonly(gdt);
+		make_lowmem_page_readonly(mfn_to_virt(gdt_mfn));
+
+		ctxt->u.s.gdt_frames[0] = gdt_mfn;
+		ctxt->u.s.gdt_ents      = GDT_ENTRIES;
+
+		ctxt->kernel_ss = __KERNEL_DS;
+		ctxt->kernel_sp = idle->thread.sp0;
 
 #ifdef CONFIG_X86_32
-	ctxt->event_callback_cs     = __KERNEL_CS;
-	ctxt->failsafe_callback_cs  = __KERNEL_CS;
+		ctxt->event_callback_cs     = __KERNEL_CS;
+		ctxt->failsafe_callback_cs  = __KERNEL_CS;
 #endif
-	ctxt->event_callback_eip    = (unsigned long)xen_hypervisor_callback;
-	ctxt->failsafe_callback_eip = (unsigned long)xen_failsafe_callback;
+		ctxt->event_callback_eip    =
+					(unsigned long)xen_hypervisor_callback;
+		ctxt->failsafe_callback_eip =
+					(unsigned long)xen_failsafe_callback;
+	}
+	ctxt->user_regs.cs = __KERNEL_CS;
+	ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct pt_regs);
 
 	per_cpu(xen_cr3, cpu) = __pa(swapper_pg_dir);
 	ctxt->ctrlreg[3] = xen_pfn_to_cr3(virt_to_mfn(swapper_pg_dir));
-- 
1.7.2.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 22:01:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 22:01:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMQom-0004ZH-Cl; Thu, 11 Oct 2012 22:01:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1TMQok-0004Yc-E9
	for Xen-devel@lists.xensource.com; Thu, 11 Oct 2012 22:01:22 +0000
Received: from [85.158.137.99:36204] by server-8.bemta-3.messagelabs.com id
	32/61-10525-0B147705; Thu, 11 Oct 2012 22:01:20 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1349992878!16458493!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgwNDQ1Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22727 invoked from network); 11 Oct 2012 22:01:19 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-7.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Oct 2012 22:01:19 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9BM1GpE016661
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 11 Oct 2012 22:01:17 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9BM1FOR027265
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 11 Oct 2012 22:01:15 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9BM1Fg4021801; Thu, 11 Oct 2012 17:01:15 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 11 Oct 2012 15:01:14 -0700
Date: Thu, 11 Oct 2012 15:01:13 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Message-ID: <20121011150113.4d525407@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: [Xen-devel] [PATCH V2 6/7]: PVH: balloon and grant changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

PVH: balloon and grant changes. For balloon changes we skip setting of
local p2m as it's updated in xen. For grant, the shared grant frame is
the pfn and not mfn, hence its mapped via the same code path as HVM

Signed-off-by: Mukesh R <mukesh.rathor@oracle.com>
---
 drivers/xen/balloon.c     |   18 +++++++++++-------
 drivers/xen/gntdev.c      |    3 ++-
 drivers/xen/grant-table.c |   25 +++++++++++++++++++++----
 3 files changed, 34 insertions(+), 12 deletions(-)

diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 31ab82f..9b895ad 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -358,10 +358,13 @@ static enum bp_state increase_reservation(unsigned long nr_pages)
 		BUG_ON(!xen_feature(XENFEAT_auto_translated_physmap) &&
 		       phys_to_machine_mapping_valid(pfn));
 
-		set_phys_to_machine(pfn, frame_list[i]);
+		if (!xen_feature(XENFEAT_auto_translated_physmap))
+			set_phys_to_machine(pfn, frame_list[i]);
 
 		/* Link back into the page tables if not highmem. */
-		if (xen_pv_domain() && !PageHighMem(page)) {
+		if (xen_pv_domain() && !PageHighMem(page) &&
+		    !xen_feature(XENFEAT_auto_translated_physmap)) {
+
 			int ret;
 			ret = HYPERVISOR_update_va_mapping(
 				(unsigned long)__va(pfn << PAGE_SHIFT),
@@ -418,12 +421,13 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
 		scrub_page(page);
 
 		if (xen_pv_domain() && !PageHighMem(page)) {
-			ret = HYPERVISOR_update_va_mapping(
-				(unsigned long)__va(pfn << PAGE_SHIFT),
-				__pte_ma(0), 0);
-			BUG_ON(ret);
+			if (!xen_feature(XENFEAT_auto_translated_physmap)) {
+				ret = HYPERVISOR_update_va_mapping(
+					(unsigned long)__va(pfn << PAGE_SHIFT),
+					__pte_ma(0), 0);
+				BUG_ON(ret);
+			}
 		}
-
 	}
 
 	/* Ensure that ballooned highmem pages don't have kmaps. */
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 5df9fd8..36ec380 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -803,7 +803,8 @@ static int __init gntdev_init(void)
 	if (!xen_domain())
 		return -ENODEV;
 
-	use_ptemod = xen_pv_domain();
+	use_ptemod = xen_pv_domain() &&
+		     !xen_feature(XENFEAT_auto_translated_physmap);
 
 	err = misc_register(&gntdev_miscdev);
 	if (err != 0) {
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index f37faf6..feaebeb 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -976,14 +976,19 @@ static void gnttab_unmap_frames_v2(void)
 static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 {
 	struct gnttab_setup_table setup;
-	unsigned long *frames;
+	unsigned long *frames, start_gpfn;
 	unsigned int nr_gframes = end_idx + 1;
 	int rc;
 
-	if (xen_hvm_domain()) {
+	if (xen_hvm_domain() || xen_feature(XENFEAT_auto_translated_physmap)) {
 		struct xen_add_to_physmap xatp;
 		unsigned int i = end_idx;
 		rc = 0;
+
+		if (xen_hvm_domain())
+			start_gpfn = xen_hvm_resume_frames >> PAGE_SHIFT;
+		else
+			start_gpfn = virt_to_pfn(gnttab_shared.addr);
 		/*
 		 * Loop backwards, so that the first hypercall has the largest
 		 * index, ensuring that the table will grow only once.
@@ -992,7 +997,7 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 			xatp.domid = DOMID_SELF;
 			xatp.idx = i;
 			xatp.space = XENMAPSPACE_grant_table;
-			xatp.gpfn = (xen_hvm_resume_frames >> PAGE_SHIFT) + i;
+			xatp.gpfn = start_gpfn + i;
 			rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
 			if (rc != 0) {
 				printk(KERN_WARNING
@@ -1055,7 +1060,7 @@ static void gnttab_request_version(void)
 	int rc;
 	struct gnttab_set_version gsv;
 
-	if (xen_hvm_domain())
+	if (xen_hvm_domain() || xen_feature(XENFEAT_auto_translated_physmap))
 		gsv.version = 1;
 	else
 		gsv.version = 2;
@@ -1083,12 +1088,24 @@ static void gnttab_request_version(void)
 int gnttab_resume(void)
 {
 	unsigned int max_nr_gframes;
+	char *kmsg = "Failed to kmalloc pages for pv in hvm grant frames\n";
 
 	gnttab_request_version();
 	max_nr_gframes = gnttab_max_grant_frames();
 	if (max_nr_gframes < nr_grant_frames)
 		return -ENOSYS;
 
+	/* PVH note: xen will free existing kmalloc'd mfn in
+	 * XENMEM_add_to_physmap */
+	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap) &&
+	    !gnttab_shared.addr) {
+		gnttab_shared.addr =
+			kmalloc(max_nr_gframes * PAGE_SIZE, GFP_KERNEL);
+		if (!gnttab_shared.addr) {
+			pr_warn("%s", kmsg);
+			return -ENOMEM;
+		}
+	}
 	if (xen_pv_domain())
 		return gnttab_map(0, nr_grant_frames - 1);
 
-- 
1.7.2.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 22:01:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 22:01:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMQom-0004ZH-Cl; Thu, 11 Oct 2012 22:01:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1TMQok-0004Yc-E9
	for Xen-devel@lists.xensource.com; Thu, 11 Oct 2012 22:01:22 +0000
Received: from [85.158.137.99:36204] by server-8.bemta-3.messagelabs.com id
	32/61-10525-0B147705; Thu, 11 Oct 2012 22:01:20 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1349992878!16458493!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgwNDQ1Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22727 invoked from network); 11 Oct 2012 22:01:19 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-7.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Oct 2012 22:01:19 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9BM1GpE016661
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 11 Oct 2012 22:01:17 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9BM1FOR027265
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 11 Oct 2012 22:01:15 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9BM1Fg4021801; Thu, 11 Oct 2012 17:01:15 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 11 Oct 2012 15:01:14 -0700
Date: Thu, 11 Oct 2012 15:01:13 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Message-ID: <20121011150113.4d525407@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: [Xen-devel] [PATCH V2 6/7]: PVH: balloon and grant changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

PVH: balloon and grant changes. For balloon changes we skip setting of
local p2m as it's updated in xen. For grant, the shared grant frame is
the pfn and not mfn, hence its mapped via the same code path as HVM

Signed-off-by: Mukesh R <mukesh.rathor@oracle.com>
---
 drivers/xen/balloon.c     |   18 +++++++++++-------
 drivers/xen/gntdev.c      |    3 ++-
 drivers/xen/grant-table.c |   25 +++++++++++++++++++++----
 3 files changed, 34 insertions(+), 12 deletions(-)

diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 31ab82f..9b895ad 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -358,10 +358,13 @@ static enum bp_state increase_reservation(unsigned long nr_pages)
 		BUG_ON(!xen_feature(XENFEAT_auto_translated_physmap) &&
 		       phys_to_machine_mapping_valid(pfn));
 
-		set_phys_to_machine(pfn, frame_list[i]);
+		if (!xen_feature(XENFEAT_auto_translated_physmap))
+			set_phys_to_machine(pfn, frame_list[i]);
 
 		/* Link back into the page tables if not highmem. */
-		if (xen_pv_domain() && !PageHighMem(page)) {
+		if (xen_pv_domain() && !PageHighMem(page) &&
+		    !xen_feature(XENFEAT_auto_translated_physmap)) {
+
 			int ret;
 			ret = HYPERVISOR_update_va_mapping(
 				(unsigned long)__va(pfn << PAGE_SHIFT),
@@ -418,12 +421,13 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
 		scrub_page(page);
 
 		if (xen_pv_domain() && !PageHighMem(page)) {
-			ret = HYPERVISOR_update_va_mapping(
-				(unsigned long)__va(pfn << PAGE_SHIFT),
-				__pte_ma(0), 0);
-			BUG_ON(ret);
+			if (!xen_feature(XENFEAT_auto_translated_physmap)) {
+				ret = HYPERVISOR_update_va_mapping(
+					(unsigned long)__va(pfn << PAGE_SHIFT),
+					__pte_ma(0), 0);
+				BUG_ON(ret);
+			}
 		}
-
 	}
 
 	/* Ensure that ballooned highmem pages don't have kmaps. */
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 5df9fd8..36ec380 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -803,7 +803,8 @@ static int __init gntdev_init(void)
 	if (!xen_domain())
 		return -ENODEV;
 
-	use_ptemod = xen_pv_domain();
+	use_ptemod = xen_pv_domain() &&
+		     !xen_feature(XENFEAT_auto_translated_physmap);
 
 	err = misc_register(&gntdev_miscdev);
 	if (err != 0) {
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index f37faf6..feaebeb 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -976,14 +976,19 @@ static void gnttab_unmap_frames_v2(void)
 static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 {
 	struct gnttab_setup_table setup;
-	unsigned long *frames;
+	unsigned long *frames, start_gpfn;
 	unsigned int nr_gframes = end_idx + 1;
 	int rc;
 
-	if (xen_hvm_domain()) {
+	if (xen_hvm_domain() || xen_feature(XENFEAT_auto_translated_physmap)) {
 		struct xen_add_to_physmap xatp;
 		unsigned int i = end_idx;
 		rc = 0;
+
+		if (xen_hvm_domain())
+			start_gpfn = xen_hvm_resume_frames >> PAGE_SHIFT;
+		else
+			start_gpfn = virt_to_pfn(gnttab_shared.addr);
 		/*
 		 * Loop backwards, so that the first hypercall has the largest
 		 * index, ensuring that the table will grow only once.
@@ -992,7 +997,7 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 			xatp.domid = DOMID_SELF;
 			xatp.idx = i;
 			xatp.space = XENMAPSPACE_grant_table;
-			xatp.gpfn = (xen_hvm_resume_frames >> PAGE_SHIFT) + i;
+			xatp.gpfn = start_gpfn + i;
 			rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
 			if (rc != 0) {
 				printk(KERN_WARNING
@@ -1055,7 +1060,7 @@ static void gnttab_request_version(void)
 	int rc;
 	struct gnttab_set_version gsv;
 
-	if (xen_hvm_domain())
+	if (xen_hvm_domain() || xen_feature(XENFEAT_auto_translated_physmap))
 		gsv.version = 1;
 	else
 		gsv.version = 2;
@@ -1083,12 +1088,24 @@ static void gnttab_request_version(void)
 int gnttab_resume(void)
 {
 	unsigned int max_nr_gframes;
+	char *kmsg = "Failed to kmalloc pages for pv in hvm grant frames\n";
 
 	gnttab_request_version();
 	max_nr_gframes = gnttab_max_grant_frames();
 	if (max_nr_gframes < nr_grant_frames)
 		return -ENOSYS;
 
+	/* PVH note: xen will free existing kmalloc'd mfn in
+	 * XENMEM_add_to_physmap */
+	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap) &&
+	    !gnttab_shared.addr) {
+		gnttab_shared.addr =
+			kmalloc(max_nr_gframes * PAGE_SIZE, GFP_KERNEL);
+		if (!gnttab_shared.addr) {
+			pr_warn("%s", kmsg);
+			return -ENOMEM;
+		}
+	}
 	if (xen_pv_domain())
 		return gnttab_map(0, nr_grant_frames - 1);
 
-- 
1.7.2.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 22:02:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 22:02:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMQpa-0004gc-Q5; Thu, 11 Oct 2012 22:02:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1TMQpZ-0004gM-RP
	for Xen-devel@lists.xensource.com; Thu, 11 Oct 2012 22:02:14 +0000
Received: from [85.158.143.99:42088] by server-2.bemta-4.messagelabs.com id
	ED/2B-25171-5E147705; Thu, 11 Oct 2012 22:02:13 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1349992931!28502918!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzk3Njc3\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4573 invoked from network); 11 Oct 2012 22:02:12 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Oct 2012 22:02:12 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9BM2AHo021002
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 11 Oct 2012 22:02:10 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9BM29IB005776
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 11 Oct 2012 22:02:10 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9BM29E1022373; Thu, 11 Oct 2012 17:02:09 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 11 Oct 2012 15:02:09 -0700
Date: Thu, 11 Oct 2012 15:02:07 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Message-ID: <20121011150207.431a087b@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Subject: [Xen-devel] [PATCH V2 7/7]: PVH: privcmd changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

PVH: privcmd changes. PVH only supports the batch interface. To map a
foreign page to a process, pfn must be allocated. PVH path uses
ballooning for that purpose. The returned pfn is then mapped to the
foreign page. xen_unmap_domain_mfn_range() is introduced to unmap these
pages via the privcmd close call.

Signed-off-by: Mukesh R <mukesh.rathor@oracle.com>
---
 drivers/xen/privcmd.c |   70 +++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 68 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 63d9ee8..b76d33c 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -33,11 +33,14 @@
 #include <xen/features.h>
 #include <xen/page.h>
 #include <xen/xen-ops.h>
+#include <xen/balloon.h>
 
 #include "privcmd.h"
 
 MODULE_LICENSE("GPL");
 
+#define PRIV_VMA_LOCKED ((void *)1)
+
 #ifndef HAVE_ARCH_PRIVCMD_MMAP
 static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma);
 #endif
@@ -199,6 +202,10 @@ static long privcmd_ioctl_mmap(void __user *udata)
 	if (!xen_initial_domain())
 		return -EPERM;
 
+	/* We only support privcmd_ioctl_mmap_batch for auto translated. */
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return -ENOSYS;
+
 	if (copy_from_user(&mmapcmd, udata, sizeof(mmapcmd)))
 		return -EFAULT;
 
@@ -246,6 +253,7 @@ struct mmap_batch_state {
 	domid_t domain;
 	unsigned long va;
 	struct vm_area_struct *vma;
+	int index;
 	/* A tristate:
 	 *      0 for no errors
 	 *      1 if at least one error has happened (and no
@@ -260,15 +268,24 @@ struct mmap_batch_state {
 	xen_pfn_t __user *user_mfn;
 };
 
+/* auto translated dom0 note: if domU being created is PV, then mfn is
+ * mfn(addr on bus). If it's auto xlated, then mfn is pfn (input to HAP).
+ */
 static int mmap_batch_fn(void *data, void *state)
 {
 	xen_pfn_t *mfnp = data;
 	struct mmap_batch_state *st = state;
+	struct vm_area_struct *vma = st->vma;
+	struct page **pages = vma->vm_private_data;
+	struct page *cur_page = NULL;
 	int ret;
 
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		cur_page = pages[st->index++];
+
 	ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
 					 st->vma->vm_page_prot, st->domain,
-					 NULL);
+					 &cur_page);
 
 	/* Store error code for second pass. */
 	*(st->err++) = ret;
@@ -304,6 +321,32 @@ static int mmap_return_errors_v1(void *data, void *state)
 	return __put_user(*mfnp, st->user_mfn++);
 }
 
+/* Allocate pfns that are then mapped with gmfns from foreign domid. Update
+ * the vma with the page info to use later.
+ * Returns: 0 if success, otherwise -errno
+ */
+static int alloc_empty_pages(struct vm_area_struct *vma, int numpgs)
+{
+	int rc;
+	struct page **pages;
+
+	pages = kcalloc(numpgs, sizeof(pages[0]), GFP_KERNEL);
+	if (pages == NULL)
+		return -ENOMEM;
+
+	rc = alloc_xenballooned_pages(numpgs, pages, 0);
+	if (rc != 0) {
+		pr_warn("%s Could not alloc %d pfns rc:%d\n", __func__,
+			numpgs, rc);
+		kfree(pages);
+		return -ENOMEM;
+	}
+	BUG_ON(vma->vm_private_data != PRIV_VMA_LOCKED);
+	vma->vm_private_data = pages;
+
+	return 0;
+}
+
 static struct vm_operations_struct privcmd_vm_ops;
 
 static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
@@ -371,10 +414,18 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
 		up_write(&mm->mmap_sem);
 		goto out;
 	}
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		ret = alloc_empty_pages(vma, m.num);
+		if (ret < 0) {
+			up_write(&mm->mmap_sem);
+			goto out;
+		}
+	}
 
 	state.domain        = m.dom;
 	state.vma           = vma;
 	state.va            = m.addr;
+	state.index         = 0;
 	state.global_error  = 0;
 	state.err           = err_array;
 
@@ -439,6 +490,20 @@ static long privcmd_ioctl(struct file *file,
 	return ret;
 }
 
+static void privcmd_close(struct vm_area_struct *vma)
+{
+	struct page **pages = vma ? vma->vm_private_data : NULL;
+	int numpgs = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
+
+	if (!pages || !numpgs || !xen_feature(XENFEAT_auto_translated_physmap))
+		return;
+
+	xen_unmap_domain_mfn_range(vma);
+	while (numpgs--)
+		free_xenballooned_pages(1, &pages[numpgs]);
+	kfree(pages);
+}
+
 static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
 {
 	printk(KERN_DEBUG "privcmd_fault: vma=%p %lx-%lx, pgoff=%lx, uv=%p\n",
@@ -449,6 +514,7 @@ static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
 }
 
 static struct vm_operations_struct privcmd_vm_ops = {
+	.close = privcmd_close,
 	.fault = privcmd_fault
 };
 
@@ -465,7 +531,7 @@ static int privcmd_mmap(struct file *file, struct vm_area_struct *vma)
 
 static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma)
 {
-	return (xchg(&vma->vm_private_data, (void *)1) == NULL);
+	return !cmpxchg(&vma->vm_private_data, NULL, PRIV_VMA_LOCKED);
 }
 
 const struct file_operations xen_privcmd_fops = {
-- 
1.7.2.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 22:02:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 22:02:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMQpa-0004gc-Q5; Thu, 11 Oct 2012 22:02:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1TMQpZ-0004gM-RP
	for Xen-devel@lists.xensource.com; Thu, 11 Oct 2012 22:02:14 +0000
Received: from [85.158.143.99:42088] by server-2.bemta-4.messagelabs.com id
	ED/2B-25171-5E147705; Thu, 11 Oct 2012 22:02:13 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1349992931!28502918!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzk3Njc3\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4573 invoked from network); 11 Oct 2012 22:02:12 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Oct 2012 22:02:12 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9BM2AHo021002
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 11 Oct 2012 22:02:10 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9BM29IB005776
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 11 Oct 2012 22:02:10 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9BM29E1022373; Thu, 11 Oct 2012 17:02:09 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 11 Oct 2012 15:02:09 -0700
Date: Thu, 11 Oct 2012 15:02:07 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Message-ID: <20121011150207.431a087b@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Subject: [Xen-devel] [PATCH V2 7/7]: PVH: privcmd changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

PVH: privcmd changes. PVH only supports the batch interface. To map a
foreign page to a process, pfn must be allocated. PVH path uses
ballooning for that purpose. The returned pfn is then mapped to the
foreign page. xen_unmap_domain_mfn_range() is introduced to unmap these
pages via the privcmd close call.

Signed-off-by: Mukesh R <mukesh.rathor@oracle.com>
---
 drivers/xen/privcmd.c |   70 +++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 68 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 63d9ee8..b76d33c 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -33,11 +33,14 @@
 #include <xen/features.h>
 #include <xen/page.h>
 #include <xen/xen-ops.h>
+#include <xen/balloon.h>
 
 #include "privcmd.h"
 
 MODULE_LICENSE("GPL");
 
+#define PRIV_VMA_LOCKED ((void *)1)
+
 #ifndef HAVE_ARCH_PRIVCMD_MMAP
 static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma);
 #endif
@@ -199,6 +202,10 @@ static long privcmd_ioctl_mmap(void __user *udata)
 	if (!xen_initial_domain())
 		return -EPERM;
 
+	/* We only support privcmd_ioctl_mmap_batch for auto translated. */
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return -ENOSYS;
+
 	if (copy_from_user(&mmapcmd, udata, sizeof(mmapcmd)))
 		return -EFAULT;
 
@@ -246,6 +253,7 @@ struct mmap_batch_state {
 	domid_t domain;
 	unsigned long va;
 	struct vm_area_struct *vma;
+	int index;
 	/* A tristate:
 	 *      0 for no errors
 	 *      1 if at least one error has happened (and no
@@ -260,15 +268,24 @@ struct mmap_batch_state {
 	xen_pfn_t __user *user_mfn;
 };
 
+/* auto translated dom0 note: if domU being created is PV, then mfn is
+ * mfn(addr on bus). If it's auto xlated, then mfn is pfn (input to HAP).
+ */
 static int mmap_batch_fn(void *data, void *state)
 {
 	xen_pfn_t *mfnp = data;
 	struct mmap_batch_state *st = state;
+	struct vm_area_struct *vma = st->vma;
+	struct page **pages = vma->vm_private_data;
+	struct page *cur_page = NULL;
 	int ret;
 
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		cur_page = pages[st->index++];
+
 	ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
 					 st->vma->vm_page_prot, st->domain,
-					 NULL);
+					 &cur_page);
 
 	/* Store error code for second pass. */
 	*(st->err++) = ret;
@@ -304,6 +321,32 @@ static int mmap_return_errors_v1(void *data, void *state)
 	return __put_user(*mfnp, st->user_mfn++);
 }
 
+/* Allocate pfns that are then mapped with gmfns from foreign domid. Update
+ * the vma with the page info to use later.
+ * Returns: 0 if success, otherwise -errno
+ */
+static int alloc_empty_pages(struct vm_area_struct *vma, int numpgs)
+{
+	int rc;
+	struct page **pages;
+
+	pages = kcalloc(numpgs, sizeof(pages[0]), GFP_KERNEL);
+	if (pages == NULL)
+		return -ENOMEM;
+
+	rc = alloc_xenballooned_pages(numpgs, pages, 0);
+	if (rc != 0) {
+		pr_warn("%s Could not alloc %d pfns rc:%d\n", __func__,
+			numpgs, rc);
+		kfree(pages);
+		return -ENOMEM;
+	}
+	BUG_ON(vma->vm_private_data != PRIV_VMA_LOCKED);
+	vma->vm_private_data = pages;
+
+	return 0;
+}
+
 static struct vm_operations_struct privcmd_vm_ops;
 
 static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
@@ -371,10 +414,18 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
 		up_write(&mm->mmap_sem);
 		goto out;
 	}
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		ret = alloc_empty_pages(vma, m.num);
+		if (ret < 0) {
+			up_write(&mm->mmap_sem);
+			goto out;
+		}
+	}
 
 	state.domain        = m.dom;
 	state.vma           = vma;
 	state.va            = m.addr;
+	state.index         = 0;
 	state.global_error  = 0;
 	state.err           = err_array;
 
@@ -439,6 +490,20 @@ static long privcmd_ioctl(struct file *file,
 	return ret;
 }
 
+static void privcmd_close(struct vm_area_struct *vma)
+{
+	struct page **pages = vma ? vma->vm_private_data : NULL;
+	int numpgs = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
+
+	if (!pages || !numpgs || !xen_feature(XENFEAT_auto_translated_physmap))
+		return;
+
+	xen_unmap_domain_mfn_range(vma);
+	while (numpgs--)
+		free_xenballooned_pages(1, &pages[numpgs]);
+	kfree(pages);
+}
+
 static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
 {
 	printk(KERN_DEBUG "privcmd_fault: vma=%p %lx-%lx, pgoff=%lx, uv=%p\n",
@@ -449,6 +514,7 @@ static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
 }
 
 static struct vm_operations_struct privcmd_vm_ops = {
+	.close = privcmd_close,
 	.fault = privcmd_fault
 };
 
@@ -465,7 +531,7 @@ static int privcmd_mmap(struct file *file, struct vm_area_struct *vma)
 
 static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma)
 {
-	return (xchg(&vma->vm_private_data, (void *)1) == NULL);
+	return !cmpxchg(&vma->vm_private_data, NULL, PRIV_VMA_LOCKED);
 }
 
 const struct file_operations xen_privcmd_fops = {
-- 
1.7.2.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 23:27:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 23:27:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMS9X-0005ZA-0i; Thu, 11 Oct 2012 23:26:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1TMS9V-0005Z5-N6
	for Xen-devel@lists.xensource.com; Thu, 11 Oct 2012 23:26:53 +0000
Received: from [85.158.139.211:10229] by server-14.bemta-5.messagelabs.com id
	DF/3D-22559-CB557705; Thu, 11 Oct 2012 23:26:52 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1349998011!22004566!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgwNDQ1Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24235 invoked from network); 11 Oct 2012 23:26:52 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Oct 2012 23:26:52 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9BNQhJ2013034
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 11 Oct 2012 23:26:45 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9BNQgxr008035
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 11 Oct 2012 23:26:43 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9BNQgWq019472; Thu, 11 Oct 2012 18:26:42 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 11 Oct 2012 16:26:42 -0700
Date: Thu, 11 Oct 2012 16:26:38 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, "stefano.stabellini@eu.citrix.com"
	<stefano.stabellini@eu.citrix.com>, "Xen-devel@lists.xensource.com"
	<Xen-devel@lists.xensource.com>
Message-ID: <20121011162638.76ec328c@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: [Xen-devel] struct xen_add_to_physmap UNION
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

What's the latest on the union of size/foreign_domid. I don't see it
checked in xen unstable. Final decision is to unionize it, right? It
doesn't matter for PVH either way.

+++ b/xen/include/public/memory.h       Thu Oct 11 16:24:47 2012 -0700
@@ -208,14 +208,19 @@ struct xen_add_to_physmap {
     /* Which domain to change the mapping for. */
     domid_t domid;
 
-    /* Number of pages to go through for gmfn_range */
-    uint16_t    size;
+    union {
+        /* Number of pages to go through for gmfn_range */
+        uint16_t    size;
+        /* IFF XENMAPSPACE_gmfn_foreign */
+        domid_t foreign_domid;
+    } u;


thanks,
Mukesh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 11 23:27:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 11 Oct 2012 23:27:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMS9X-0005ZA-0i; Thu, 11 Oct 2012 23:26:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1TMS9V-0005Z5-N6
	for Xen-devel@lists.xensource.com; Thu, 11 Oct 2012 23:26:53 +0000
Received: from [85.158.139.211:10229] by server-14.bemta-5.messagelabs.com id
	DF/3D-22559-CB557705; Thu, 11 Oct 2012 23:26:52 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1349998011!22004566!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgwNDQ1Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24235 invoked from network); 11 Oct 2012 23:26:52 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Oct 2012 23:26:52 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9BNQhJ2013034
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 11 Oct 2012 23:26:45 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9BNQgxr008035
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 11 Oct 2012 23:26:43 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9BNQgWq019472; Thu, 11 Oct 2012 18:26:42 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 11 Oct 2012 16:26:42 -0700
Date: Thu, 11 Oct 2012 16:26:38 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, "stefano.stabellini@eu.citrix.com"
	<stefano.stabellini@eu.citrix.com>, "Xen-devel@lists.xensource.com"
	<Xen-devel@lists.xensource.com>
Message-ID: <20121011162638.76ec328c@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: [Xen-devel] struct xen_add_to_physmap UNION
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

What's the latest on the union of size/foreign_domid. I don't see it
checked in xen unstable. Final decision is to unionize it, right? It
doesn't matter for PVH either way.

+++ b/xen/include/public/memory.h       Thu Oct 11 16:24:47 2012 -0700
@@ -208,14 +208,19 @@ struct xen_add_to_physmap {
     /* Which domain to change the mapping for. */
     domid_t domid;
 
-    /* Number of pages to go through for gmfn_range */
-    uint16_t    size;
+    union {
+        /* Number of pages to go through for gmfn_range */
+        uint16_t    size;
+        /* IFF XENMAPSPACE_gmfn_foreign */
+        domid_t foreign_domid;
+    } u;


thanks,
Mukesh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 00:11:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 00:11:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMSqD-0006DR-KP; Fri, 12 Oct 2012 00:11:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TMSqB-0006DM-W5
	for xen-devel@lists.xensource.com; Fri, 12 Oct 2012 00:11:00 +0000
Received: from [85.158.137.99:41671] by server-16.bemta-3.messagelabs.com id
	69/F1-16565-31067705; Fri, 12 Oct 2012 00:10:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1350000648!21150134!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM5ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1115 invoked from network); 12 Oct 2012 00:10:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 00:10:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,574,1344211200"; d="scan'208";a="15114418"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 00:10:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 12 Oct 2012 01:10:47 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1TMSpy-00005D-LD;
	Fri, 12 Oct 2012 00:10:46 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TMSpy-0001zV-6B;
	Fri, 12 Oct 2012 01:10:46 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13956-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 12 Oct 2012 01:10:46 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13956: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13956 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13956/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13953
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13953
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13953
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13953

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  e0e1350dfe9b
baseline version:
 xen                  b91f57f54f47

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <ian.campbell@citrix.com>
  Sander Eikelenboom <linux@eikelenboom.it>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=e0e1350dfe9b
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable e0e1350dfe9b
+ branch=xen-unstable
+ revision=e0e1350dfe9b
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r e0e1350dfe9b ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 6 changesets with 11 changes to 8 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 00:11:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 00:11:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMSqD-0006DR-KP; Fri, 12 Oct 2012 00:11:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TMSqB-0006DM-W5
	for xen-devel@lists.xensource.com; Fri, 12 Oct 2012 00:11:00 +0000
Received: from [85.158.137.99:41671] by server-16.bemta-3.messagelabs.com id
	69/F1-16565-31067705; Fri, 12 Oct 2012 00:10:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1350000648!21150134!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTM5ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1115 invoked from network); 12 Oct 2012 00:10:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 00:10:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,574,1344211200"; d="scan'208";a="15114418"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 00:10:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 12 Oct 2012 01:10:47 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1TMSpy-00005D-LD;
	Fri, 12 Oct 2012 00:10:46 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TMSpy-0001zV-6B;
	Fri, 12 Oct 2012 01:10:46 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13956-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 12 Oct 2012 01:10:46 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13956: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13956 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13956/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13953
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13953
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13953
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13953

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  e0e1350dfe9b
baseline version:
 xen                  b91f57f54f47

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <ian.campbell@citrix.com>
  Sander Eikelenboom <linux@eikelenboom.it>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=e0e1350dfe9b
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable e0e1350dfe9b
+ branch=xen-unstable
+ revision=e0e1350dfe9b
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r e0e1350dfe9b ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 6 changesets with 11 changes to 8 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 04:44:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 04:44:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMX6Q-0002qq-Vk; Fri, 12 Oct 2012 04:44:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <john.krstev@gmail.com>) id 1TMX6P-0002ql-NO
	for xen-devel@lists.xensource.com; Fri, 12 Oct 2012 04:44:02 +0000
Received: from [85.158.137.99:54098] by server-3.bemta-3.messagelabs.com id
	F3/AE-09368-010A7705; Fri, 12 Oct 2012 04:44:00 +0000
X-Env-Sender: john.krstev@gmail.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1350017037!18121441!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22921 invoked from network); 12 Oct 2012 04:43:59 -0000
Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com)
	(209.85.212.43)
	by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 04:43:59 -0000
Received: by mail-vb0-f43.google.com with SMTP id fq11so3259589vbb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 11 Oct 2012 21:43:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=+xkvI+V2JcVhy47YNdITUvLJTzYsOCjm5+zG3w4d/Bk=;
	b=YEdqkmrDo35to1XgDo62PeSmrJ6K/YAsHLOJBGqyGxxtq+pwO5SHmvzyz+kD25Lc7Y
	tCTlOSdC5vx26h15FJ3oNfln8qRFMk/IRS/QcnoekoupdfgSYEBa1Ly3Cbpl2VhRNre6
	sESE2hfDoJmUaJNVS5df42/Xg8BZsmYebmHvzRFXDN6HVyD9aYNzVX9b/LSwkCSe43+P
	dQ/Z/3ejJazFOojirllU2ZzLNSn4A2D7gqtr7fVHlqecQOFZYMFYlL8G33Mwd931OfNX
	m3aBYcd/jPa9ISgLdD/VIUPaSCf3ruAixCYbiYCR5SQ6EWW+ff2+hdyB0V8z4pAKgAQ/
	SYdQ==
MIME-Version: 1.0
Received: by 10.52.97.200 with SMTP id ec8mr1472776vdb.89.1350017037449; Thu,
	11 Oct 2012 21:43:57 -0700 (PDT)
Received: by 10.58.29.37 with HTTP; Thu, 11 Oct 2012 21:43:57 -0700 (PDT)
In-Reply-To: <CA+LkAa==rHSiZ5JqDo1MC-HEJWPa=QEBd7X6vSxFjLSRMpM58g@mail.gmail.com>
References: <CA+LkAa=RHJCtpncP8AUSeR8Te3ZLMvRctuZqnv_NwUkCQ-im8Q@mail.gmail.com>
	<20120921172901.GA6821@phenom.dumpdata.com>
	<099949C5-C4C0-4D57-A778-849C94781372@gmail.com>
	<20120925141013.GC16478@phenom.dumpdata.com>
	<CA+LkAa==rHSiZ5JqDo1MC-HEJWPa=QEBd7X6vSxFjLSRMpM58g@mail.gmail.com>
Date: Fri, 12 Oct 2012 15:43:57 +1100
Message-ID: <CA+LkAa=+nyis-QHJr6ZZnWaBYOH-CSS7pYBFL=kGVAVvFeq8LA@mail.gmail.com>
From: John Krstev <john.krstev@gmail.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen + DVB = not working. memory allocation issue?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6005088499668153197=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6005088499668153197==
Content-Type: multipart/alternative; boundary=20cf307c9c1cf5390004cbd555f7

--20cf307c9c1cf5390004cbd555f7
Content-Type: text/plain; charset=ISO-8859-1

Hi Konrad,

I have done some more testing and like to share my findings:

> > Did you first try running it under baremetal Linux (using a Live CD for
> > example?) Did it work there?
I have found that under kernel version 3.2.0 (stock debian kernel) when
running on baremetal I get data, with or without kernel parameter
"intel_iommu=1"  'cat /dev/video > /tmp/file' produces data there too.
However when booting this kernel under Xen (Dom0) cannot get DVB data and
get filter timeout with scan utility.

With (custom built vanilla) kernel 3.6 and custom built 3.5 (with -pf
patches), when running on baremetal; with intel_iommu=1 I am unable to get
any DVB data. I have tried intel_iommu=0 and I still cannot get DVB data.
To add to this I now have DMAR messages in dmesg output (06:00.0 is the DVB
card) :

[   * 0.074639*] DMAR:[DMA Read] Request device [06:00.0] fault addr 80c6000
[    *0.074639*] DMAR:[fault reason 02] Present bit in context entry is
clear
[    0.422177] DMAR: No ATSR found
[   49.194033] DMAR:[DMA Read] Request device [06:00.0] fault addr fff7f000
[   49.194033] DMAR:[fault reason 02] Present bit in context entry is clear

Also, I'm getting these (with intel_iommu=0 or with intel_iommu=1) under
3.5-pf kernel and 3.6 custom vanilla:

[    0.418811] IOMMU: Setting identity map for device 0000:00:1f.0 [0x0 -
0xffffff]
[    0.419294]  [<ffffffff81250d01>] ? intel_iommu_device_group+0x64/0xb1
[    0.419330]  [<ffffffff8124c9b0>] ? bus_set_iommu+0x37/0x37
[    0.419364]  [<ffffffff8124c9c2>] ? add_iommu_group+0x12/0x2f
[    0.419399]  [<ffffffff8124c9b0>] ? bus_set_iommu+0x37/0x37
[    0.420778]  [<ffffffff8124c9ac>] ? bus_set_iommu+0x33/0x37
[    0.420813]  [<ffffffff814c39c0>] ? intel_iommu_init+0x9a9/0xac5
[    0.420920]  [<ffffffff8149c7df>] ? pci_iommu_init+0xe/0x37


Now; I did manage to get it it work WITH Xen under the following conditions:

Debian kernel 3.2.0 and Xen (Dom0) and passing "iommu=0" on the xen line.

FYI I'd like to mention that I have had success doing VGA passthrough to
Win XP guest (Intel on board graphics) so I'm reasonably confident the BIOS
IOMMU code is OK (Asrock Z77 Extreme 4 motherboard - BIOS version 1.30).

What are your thoughts?

Regards,

John


On 26 September 2012 11:02, John Krstev <john.krstev@gmail.com> wrote:

> Hey Konrad,
>
> >Please do not top-post.
> Apologies.
>
>
> >So try also limiting how much memory the hypervisor has to eliminate
> >this being a 4GB issue. Meaning on the _hypervisor_ line add 'mem=4G'.
>
> Yes, that was on the hypervisor line which I was specifying mem=3G. I've
> also tried mem=4G and still having the same problem.
>
>
> >And I need to know whether you are running this in a domain or in the
> initial domain?
>
> Running in Dom0.
>
>
> >If you do it manually (cat /dev/video0 > /tmp/file.mpg)
> >does the file increase? Is it full of garbage ?
>
> cat: /dev/video0: Input/output error
>
> The file size is 0 bytes.
>
>
> >Does the channel selection work? Can you select the proper channel?
> Analogue selection works ok and I can also watch analogue TV. When using
> digital, I get a lock but no video data.
>
>
> > If you crank up all the debug options do you get anything saying what
> the problem is
>
> With debug turned on to level 8 (echo 8 > /proc/sys/kernel/printk) I see
> the following in dmesg which may be useful:
> [130009.484098] cx88[0]/0: [ffff8802c03b3400/0] timeout - dma=0x96a7e000
>
> Let me know if there's anything else I can try?
>
> Regards,
>
> John
>
>
> On 26 September 2012 00:10, Konrad Rzeszutek Wilk <konrad@kernel.org>wrote:
>
>> On Tue, Sep 25, 2012 at 10:49:38AM +1000, John Krstev wrote:
>> > Hello Konrad,
>>
>> Hey John,
>>
>> Please do not top-post.
>> >
>> > Do you have any patches I can try? FYI I've tried booting dom0 with
>> mem=3G and various other options, still does not work. As I mentioned it
>> runs fine on bare metal.
>>
>> So try also limiting how much memory the hypervisor has to eliminate
>> this being a 4GB issue. Meaning on the _hypervisor_ line add 'mem=4G'.
>>
>> The next step is to actually figure out if where in the driver (cx88)
>> fails. And I need to know whether you are running this in a domain or
>> in the initial domain? If you crank up all the debug options do you
>> get anything saying what the problem is? How do you 'capture' the
>> video output? If you do it manually (cat /dev/video0 > /tmp/file.mpg)
>> does the file increase? Is it full of garbage ?
>>
>> Does the channel selection work? Can you select the proper channel?
>>
>> >
>> > Last time it did work with xen was Jeremy's kernel + xen 4.0, also
>> kernel 3.0.8 with xen 4.0.4 i believe (cannot reproduce success).
>> >
>> > Thank you again for your input.
>> >
>> > Regards,
>> >
>> > John
>> >
>> >
>> >
>> > On 22/09/2012, at 3:29, Konrad Rzeszutek Wilk <konrad@kernel.org>
>> wrote:
>> >
>> > > On Fri, Sep 21, 2012 at 01:02:23PM +1000, John Krstev wrote:
>> > >> Hi Konrad,
>> > >
>> > > Hey John,
>> > >
>> > > Please next time also include xen-devel on the To header. I've done
>> that
>> > > for you.
>> > >>
>> > >> I refer to your patch at:
>> > >> http://lists.xen.org/archives/html/xen-devel/2012-01/msg01927.html
>> > >> which I found reading
>> > >> http://www.gossamer-threads.com/lists/xen/devel/256197
>> > >>
>> > >> I have a winfast DVT 2000H (cx88) DVB card which is not able to
>> > >> scan/watch digital TV when running under Xen.
>> > >
>> > > Did you first try running it under baremetal Linux (using a Live CD
>> for
>> > > example?) Did it work there?
>> > >
>> > > How does it not work? Can you program it? Is this under a guest or the
>> > > main kernel? When it wsa not working, did you try all the debug
>> > > options enable (http://wiki.xen.org/wiki/XenSerialConsole) to
>> > > see if there is anthing being reported?
>> > >
>> > >>
>> > >> I've tried installing the above patch to the 3.6-rc6 kernel, but did
>> > >> not seem to help.
>> > >>
>> > >> Apologies if this has been asked before (I wasn't able to find
>> another
>> > >> patch), but is there a patch to get this (suspected vmalloc_32) fixed
>> > >> and DVB card working?
>> > >
>> > > Eventually yes.
>> > >>
>> > >> FYI I'm running 64 bit 3.5-rc6 and xen 4.3-unstable.
>> > >
>> > > 3.5-rc6 or 3.6-rc6?
>> > > I presume the latter?
>> > >>
>> > >> Thank you! :)
>> > >>
>> > >> Regards,
>> > >>
>> > >> John
>> > >>
>> >
>> > _______________________________________________
>> > Xen-devel mailing list
>> > Xen-devel@lists.xen.org
>> > http://lists.xen.org/xen-devel
>> >
>>
>
>

--20cf307c9c1cf5390004cbd555f7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Konrad,<br><br>I have done some more testing and like to share my findin=
gs:<br><br>> > Did you first try running it under baremetal Linux (us=
ing a Live CD for<br>
> > example?) Did it work there?<br>I have found that under kernel ve=
rsion 3.2.0 (stock debian kernel) when running on baremetal I get data, wit=
h or without kernel parameter "intel_iommu=3D1"=A0 'cat /dev/=
video > /tmp/file' produces data there too. However when booting thi=
s kernel under Xen (Dom0) cannot get DVB data and get filter timeout with s=
can utility.<br>
<br>With (custom built vanilla) kernel 3.6 and custom built 3.5 (with -pf p=
atches), when running on baremetal; with intel_iommu=3D1 I am unable to get=
 any DVB data. I have tried intel_iommu=3D0 and I still cannot get DVB data=
. To add to this I now have DMAR messages in dmesg output (06:00.0 is the D=
VB card) :<br>
<br>[=A0=A0=A0<b> 0.074639</b>] DMAR:[DMA Read] Request device [06:00.0] fa=
ult addr 80c6000<br>[=A0=A0=A0 <b>0.074639</b>] DMAR:[fault reason 02] Pres=
ent bit in context entry is clear<br>[=A0=A0=A0 0.422177] DMAR: No ATSR fou=
nd<br>[=A0=A0 49.194033] DMAR:[DMA Read] Request device [06:00.0] fault add=
r fff7f000<br>
[=A0=A0 49.194033] DMAR:[fault reason 02] Present bit in context entry is c=
lear<br><br>Also, I'm getting these (with intel_iommu=3D0 or with intel=
_iommu=3D1) under 3.5-pf kernel and 3.6 custom vanilla:<br><br>[=A0=A0=A0 0=
.418811] IOMMU: Setting identity map for device 0000:00:1f.0 [0x0 - 0xfffff=
f]<br>
[=A0=A0=A0 0.419294]=A0 [<ffffffff81250d01>] ? intel_iommu_device_gro=
up+0x64/0xb1<br>[=A0=A0=A0 0.419330]=A0 [<ffffffff8124c9b0>] ? bus_se=
t_iommu+0x37/0x37<br>[=A0=A0=A0 0.419364]=A0 [<ffffffff8124c9c2>] ? a=
dd_iommu_group+0x12/0x2f<br>
[=A0=A0=A0 0.419399]=A0 [<ffffffff8124c9b0>] ? bus_set_iommu+0x37/0x3=
7<br>[=A0=A0=A0 0.420778]=A0 [<ffffffff8124c9ac>] ? bus_set_iommu+0x3=
3/0x37<br>[=A0=A0=A0 0.420813]=A0 [<ffffffff814c39c0>] ? intel_iommu_=
init+0x9a9/0xac5<br>
[=A0=A0=A0 0.420920]=A0 [<ffffffff8149c7df>] ? pci_iommu_init+0xe/0x3=
7<br><br><br>Now; I did manage to get it it work WITH Xen under the followi=
ng conditions:<br><br>Debian kernel 3.2.0 and Xen (Dom0) and passing "=
iommu=3D0" on the xen line. <br>
<br>FYI I'd like to mention that I have had success doing VGA passthrou=
gh to Win XP guest (Intel on board graphics) so I'm reasonably confiden=
t the BIOS IOMMU code is OK (Asrock Z77 Extreme 4 motherboard - BIOS versio=
n 1.30).<br>
<br>What are your thoughts?<br><br>Regards,<br><br>John<br><br><br><div cla=
ss=3D"gmail_quote">On 26 September 2012 11:02, John Krstev <span dir=3D"ltr=
"><<a href=3D"mailto:john.krstev@gmail.com" target=3D"_blank">john.krste=
v@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Hey Konrad,<br><br>>Please do not top-pos=
t.<br>Apologies. <br><div class=3D"im"><br><br>>So try also limiting how=
 much memory the hypervisor has to eliminate<br>

>this being a 4GB issue. Meaning on the _hypervisor_ line add 'mem=
=3D4G'.<br><br></div>Yes, that was on the hypervisor line which I was s=
pecifying mem=3D3G. I've also tried mem=3D4G and still having the same =
problem.<div class=3D"im">
<br>
<br>>And I need to know whether you are running this in a domain or in t=
he initial domain?<br>
<br></div>Running in Dom0.<div class=3D"im"><br><br>>If you do it manual=
ly (cat /dev/video0 > /tmp/file.mpg)<br>
>does the file increase? Is it full of garbage ?<br><br></div>cat: /dev/=
video0: Input/output error<br><br>The file size is 0 bytes.<div class=3D"im=
"><br><br>>Does the channel selection work? Can you select the proper ch=
annel?<br>
</div>Analogue selection works ok and I can also watch analogue TV. When us=
ing digital, I get a lock but no video data.<div class=3D"im"><br>

<br>> If you crank up all the debug options do you get anything saying w=
hat the problem is<br><br></div>With debug turned on to level 8 (echo 8 >=
; /proc/sys/kernel/printk) I see the following in dmesg which may be useful=
:<br>

[130009.484098] cx88[0]/0: [ffff8802c03b3400/0] timeout - dma=3D0x96a7e000<=
br><br>Let me know if there's anything else I can try?<br><br>Regards,<=
br><br>John<div class=3D"HOEnZb"><div class=3D"h5"><br><br><div class=3D"gm=
ail_quote">
On 26 September 2012 00:10, Konrad Rzeszutek Wilk <span dir=3D"ltr"><<a =
href=3D"mailto:konrad@kernel.org" target=3D"_blank">konrad@kernel.org</a>&g=
t;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On Tue, Sep 25, 2012 at 10:49:38AM +1000, John Krstev wrote:<br>
> Hello Konrad,<br>
<br>
Hey John,<br>
<br>
Please do not top-post.<br>
<div>><br>
> Do you have any patches I can try? FYI I've tried booting dom0 wit=
h mem=3D3G and various other options, still does not work. As I mentioned i=
t runs fine on bare metal.<br>
<br>
</div>So try also limiting how much memory the hypervisor has to eliminate<=
br>
this being a 4GB issue. Meaning on the _hypervisor_ line add 'mem=3D4G&=
#39;.<br>
<br>
The next step is to actually figure out if where in the driver (cx88)<br>
fails. And I need to know whether you are running this in a domain or<br>
in the initial domain? If you crank up all the debug options do you<br>
get anything saying what the problem is? How do you 'capture' the<b=
r>
video output? If you do it manually (cat /dev/video0 > /tmp/file.mpg)<br=
>
does the file increase? Is it full of garbage ?<br>
<br>
Does the channel selection work? Can you select the proper channel?<br>
<div><div><br>
><br>
> Last time it did work with xen was Jeremy's kernel + xen 4.0, also=
 kernel 3.0.8 with xen 4.0.4 i believe (cannot reproduce success).<br>
><br>
> Thank you again for your input.<br>
><br>
> Regards,<br>
><br>
> John<br>
><br>
><br>
><br>
> On 22/09/2012, at 3:29, Konrad Rzeszutek Wilk <<a href=3D"mailto:ko=
nrad@kernel.org" target=3D"_blank">konrad@kernel.org</a>> wrote:<br>
><br>
> > On Fri, Sep 21, 2012 at 01:02:23PM +1000, John Krstev wrote:<br>
> >> Hi Konrad,<br>
> ><br>
> > Hey John,<br>
> ><br>
> > Please next time also include xen-devel on the To header. I'v=
e done that<br>
> > for you.<br>
> >><br>
> >> I refer to your patch at:<br>
> >> <a href=3D"http://lists.xen.org/archives/html/xen-devel/2012-=
01/msg01927.html" target=3D"_blank">http://lists.xen.org/archives/html/xen-=
devel/2012-01/msg01927.html</a><br>
> >> which I found reading<br>
> >> <a href=3D"http://www.gossamer-threads.com/lists/xen/devel/25=
6197" target=3D"_blank">http://www.gossamer-threads.com/lists/xen/devel/256=
197</a><br>
> >><br>
> >> I have a winfast DVT 2000H (cx88) DVB card which is not able =
to<br>
> >> scan/watch digital TV when running under Xen.<br>
> ><br>
> > Did you first try running it under baremetal Linux (using a Live =
CD for<br>
> > example?) Did it work there?<br>
> ><br>
> > How does it not work? Can you program it? Is this under a guest o=
r the<br>
> > main kernel? When it wsa not working, did you try all the debug<b=
r>
> > options enable (<a href=3D"http://wiki.xen.org/wiki/XenSerialCons=
ole" target=3D"_blank">http://wiki.xen.org/wiki/XenSerialConsole</a>) to<br=
>
> > see if there is anthing being reported?<br>
> ><br>
> >><br>
> >> I've tried installing the above patch to the 3.6-rc6 kern=
el, but did<br>
> >> not seem to help.<br>
> >><br>
> >> Apologies if this has been asked before (I wasn't able to=
 find another<br>
> >> patch), but is there a patch to get this (suspected vmalloc_3=
2) fixed<br>
> >> and DVB card working?<br>
> ><br>
> > Eventually yes.<br>
> >><br>
> >> FYI I'm running 64 bit 3.5-rc6 and xen 4.3-unstable.<br>
> ><br>
> > 3.5-rc6 or 3.6-rc6?<br>
> > I presume the latter?<br>
> >><br>
> >> Thank you! :)<br>
> >><br>
> >> Regards,<br>
> >><br>
> >> John<br>
> >><br>
><br>
</div></div>> _______________________________________________<br>
> Xen-devel mailing list<br>
> <a href=3D"mailto:Xen-devel@lists.xen.org" target=3D"_blank">Xen-devel=
@lists.xen.org</a><br>
> <a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://li=
sts.xen.org/xen-devel</a><br>
><br>
</blockquote></div><br>
</div></div></blockquote></div><br>

--20cf307c9c1cf5390004cbd555f7--


--===============6005088499668153197==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6005088499668153197==--


From xen-devel-bounces@lists.xen.org Fri Oct 12 04:44:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 04:44:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMX6Q-0002qq-Vk; Fri, 12 Oct 2012 04:44:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <john.krstev@gmail.com>) id 1TMX6P-0002ql-NO
	for xen-devel@lists.xensource.com; Fri, 12 Oct 2012 04:44:02 +0000
Received: from [85.158.137.99:54098] by server-3.bemta-3.messagelabs.com id
	F3/AE-09368-010A7705; Fri, 12 Oct 2012 04:44:00 +0000
X-Env-Sender: john.krstev@gmail.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1350017037!18121441!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22921 invoked from network); 12 Oct 2012 04:43:59 -0000
Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com)
	(209.85.212.43)
	by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 04:43:59 -0000
Received: by mail-vb0-f43.google.com with SMTP id fq11so3259589vbb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 11 Oct 2012 21:43:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=+xkvI+V2JcVhy47YNdITUvLJTzYsOCjm5+zG3w4d/Bk=;
	b=YEdqkmrDo35to1XgDo62PeSmrJ6K/YAsHLOJBGqyGxxtq+pwO5SHmvzyz+kD25Lc7Y
	tCTlOSdC5vx26h15FJ3oNfln8qRFMk/IRS/QcnoekoupdfgSYEBa1Ly3Cbpl2VhRNre6
	sESE2hfDoJmUaJNVS5df42/Xg8BZsmYebmHvzRFXDN6HVyD9aYNzVX9b/LSwkCSe43+P
	dQ/Z/3ejJazFOojirllU2ZzLNSn4A2D7gqtr7fVHlqecQOFZYMFYlL8G33Mwd931OfNX
	m3aBYcd/jPa9ISgLdD/VIUPaSCf3ruAixCYbiYCR5SQ6EWW+ff2+hdyB0V8z4pAKgAQ/
	SYdQ==
MIME-Version: 1.0
Received: by 10.52.97.200 with SMTP id ec8mr1472776vdb.89.1350017037449; Thu,
	11 Oct 2012 21:43:57 -0700 (PDT)
Received: by 10.58.29.37 with HTTP; Thu, 11 Oct 2012 21:43:57 -0700 (PDT)
In-Reply-To: <CA+LkAa==rHSiZ5JqDo1MC-HEJWPa=QEBd7X6vSxFjLSRMpM58g@mail.gmail.com>
References: <CA+LkAa=RHJCtpncP8AUSeR8Te3ZLMvRctuZqnv_NwUkCQ-im8Q@mail.gmail.com>
	<20120921172901.GA6821@phenom.dumpdata.com>
	<099949C5-C4C0-4D57-A778-849C94781372@gmail.com>
	<20120925141013.GC16478@phenom.dumpdata.com>
	<CA+LkAa==rHSiZ5JqDo1MC-HEJWPa=QEBd7X6vSxFjLSRMpM58g@mail.gmail.com>
Date: Fri, 12 Oct 2012 15:43:57 +1100
Message-ID: <CA+LkAa=+nyis-QHJr6ZZnWaBYOH-CSS7pYBFL=kGVAVvFeq8LA@mail.gmail.com>
From: John Krstev <john.krstev@gmail.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen + DVB = not working. memory allocation issue?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6005088499668153197=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6005088499668153197==
Content-Type: multipart/alternative; boundary=20cf307c9c1cf5390004cbd555f7

--20cf307c9c1cf5390004cbd555f7
Content-Type: text/plain; charset=ISO-8859-1

Hi Konrad,

I have done some more testing and like to share my findings:

> > Did you first try running it under baremetal Linux (using a Live CD for
> > example?) Did it work there?
I have found that under kernel version 3.2.0 (stock debian kernel) when
running on baremetal I get data, with or without kernel parameter
"intel_iommu=1"  'cat /dev/video > /tmp/file' produces data there too.
However when booting this kernel under Xen (Dom0) cannot get DVB data and
get filter timeout with scan utility.

With (custom built vanilla) kernel 3.6 and custom built 3.5 (with -pf
patches), when running on baremetal; with intel_iommu=1 I am unable to get
any DVB data. I have tried intel_iommu=0 and I still cannot get DVB data.
To add to this I now have DMAR messages in dmesg output (06:00.0 is the DVB
card) :

[   * 0.074639*] DMAR:[DMA Read] Request device [06:00.0] fault addr 80c6000
[    *0.074639*] DMAR:[fault reason 02] Present bit in context entry is
clear
[    0.422177] DMAR: No ATSR found
[   49.194033] DMAR:[DMA Read] Request device [06:00.0] fault addr fff7f000
[   49.194033] DMAR:[fault reason 02] Present bit in context entry is clear

Also, I'm getting these (with intel_iommu=0 or with intel_iommu=1) under
3.5-pf kernel and 3.6 custom vanilla:

[    0.418811] IOMMU: Setting identity map for device 0000:00:1f.0 [0x0 -
0xffffff]
[    0.419294]  [<ffffffff81250d01>] ? intel_iommu_device_group+0x64/0xb1
[    0.419330]  [<ffffffff8124c9b0>] ? bus_set_iommu+0x37/0x37
[    0.419364]  [<ffffffff8124c9c2>] ? add_iommu_group+0x12/0x2f
[    0.419399]  [<ffffffff8124c9b0>] ? bus_set_iommu+0x37/0x37
[    0.420778]  [<ffffffff8124c9ac>] ? bus_set_iommu+0x33/0x37
[    0.420813]  [<ffffffff814c39c0>] ? intel_iommu_init+0x9a9/0xac5
[    0.420920]  [<ffffffff8149c7df>] ? pci_iommu_init+0xe/0x37


Now; I did manage to get it it work WITH Xen under the following conditions:

Debian kernel 3.2.0 and Xen (Dom0) and passing "iommu=0" on the xen line.

FYI I'd like to mention that I have had success doing VGA passthrough to
Win XP guest (Intel on board graphics) so I'm reasonably confident the BIOS
IOMMU code is OK (Asrock Z77 Extreme 4 motherboard - BIOS version 1.30).

What are your thoughts?

Regards,

John


On 26 September 2012 11:02, John Krstev <john.krstev@gmail.com> wrote:

> Hey Konrad,
>
> >Please do not top-post.
> Apologies.
>
>
> >So try also limiting how much memory the hypervisor has to eliminate
> >this being a 4GB issue. Meaning on the _hypervisor_ line add 'mem=4G'.
>
> Yes, that was on the hypervisor line which I was specifying mem=3G. I've
> also tried mem=4G and still having the same problem.
>
>
> >And I need to know whether you are running this in a domain or in the
> initial domain?
>
> Running in Dom0.
>
>
> >If you do it manually (cat /dev/video0 > /tmp/file.mpg)
> >does the file increase? Is it full of garbage ?
>
> cat: /dev/video0: Input/output error
>
> The file size is 0 bytes.
>
>
> >Does the channel selection work? Can you select the proper channel?
> Analogue selection works ok and I can also watch analogue TV. When using
> digital, I get a lock but no video data.
>
>
> > If you crank up all the debug options do you get anything saying what
> the problem is
>
> With debug turned on to level 8 (echo 8 > /proc/sys/kernel/printk) I see
> the following in dmesg which may be useful:
> [130009.484098] cx88[0]/0: [ffff8802c03b3400/0] timeout - dma=0x96a7e000
>
> Let me know if there's anything else I can try?
>
> Regards,
>
> John
>
>
> On 26 September 2012 00:10, Konrad Rzeszutek Wilk <konrad@kernel.org>wrote:
>
>> On Tue, Sep 25, 2012 at 10:49:38AM +1000, John Krstev wrote:
>> > Hello Konrad,
>>
>> Hey John,
>>
>> Please do not top-post.
>> >
>> > Do you have any patches I can try? FYI I've tried booting dom0 with
>> mem=3G and various other options, still does not work. As I mentioned it
>> runs fine on bare metal.
>>
>> So try also limiting how much memory the hypervisor has to eliminate
>> this being a 4GB issue. Meaning on the _hypervisor_ line add 'mem=4G'.
>>
>> The next step is to actually figure out if where in the driver (cx88)
>> fails. And I need to know whether you are running this in a domain or
>> in the initial domain? If you crank up all the debug options do you
>> get anything saying what the problem is? How do you 'capture' the
>> video output? If you do it manually (cat /dev/video0 > /tmp/file.mpg)
>> does the file increase? Is it full of garbage ?
>>
>> Does the channel selection work? Can you select the proper channel?
>>
>> >
>> > Last time it did work with xen was Jeremy's kernel + xen 4.0, also
>> kernel 3.0.8 with xen 4.0.4 i believe (cannot reproduce success).
>> >
>> > Thank you again for your input.
>> >
>> > Regards,
>> >
>> > John
>> >
>> >
>> >
>> > On 22/09/2012, at 3:29, Konrad Rzeszutek Wilk <konrad@kernel.org>
>> wrote:
>> >
>> > > On Fri, Sep 21, 2012 at 01:02:23PM +1000, John Krstev wrote:
>> > >> Hi Konrad,
>> > >
>> > > Hey John,
>> > >
>> > > Please next time also include xen-devel on the To header. I've done
>> that
>> > > for you.
>> > >>
>> > >> I refer to your patch at:
>> > >> http://lists.xen.org/archives/html/xen-devel/2012-01/msg01927.html
>> > >> which I found reading
>> > >> http://www.gossamer-threads.com/lists/xen/devel/256197
>> > >>
>> > >> I have a winfast DVT 2000H (cx88) DVB card which is not able to
>> > >> scan/watch digital TV when running under Xen.
>> > >
>> > > Did you first try running it under baremetal Linux (using a Live CD
>> for
>> > > example?) Did it work there?
>> > >
>> > > How does it not work? Can you program it? Is this under a guest or the
>> > > main kernel? When it wsa not working, did you try all the debug
>> > > options enable (http://wiki.xen.org/wiki/XenSerialConsole) to
>> > > see if there is anthing being reported?
>> > >
>> > >>
>> > >> I've tried installing the above patch to the 3.6-rc6 kernel, but did
>> > >> not seem to help.
>> > >>
>> > >> Apologies if this has been asked before (I wasn't able to find
>> another
>> > >> patch), but is there a patch to get this (suspected vmalloc_32) fixed
>> > >> and DVB card working?
>> > >
>> > > Eventually yes.
>> > >>
>> > >> FYI I'm running 64 bit 3.5-rc6 and xen 4.3-unstable.
>> > >
>> > > 3.5-rc6 or 3.6-rc6?
>> > > I presume the latter?
>> > >>
>> > >> Thank you! :)
>> > >>
>> > >> Regards,
>> > >>
>> > >> John
>> > >>
>> >
>> > _______________________________________________
>> > Xen-devel mailing list
>> > Xen-devel@lists.xen.org
>> > http://lists.xen.org/xen-devel
>> >
>>
>
>

--20cf307c9c1cf5390004cbd555f7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Konrad,<br><br>I have done some more testing and like to share my findin=
gs:<br><br>> > Did you first try running it under baremetal Linux (us=
ing a Live CD for<br>
> > example?) Did it work there?<br>I have found that under kernel ve=
rsion 3.2.0 (stock debian kernel) when running on baremetal I get data, wit=
h or without kernel parameter "intel_iommu=3D1"=A0 'cat /dev/=
video > /tmp/file' produces data there too. However when booting thi=
s kernel under Xen (Dom0) cannot get DVB data and get filter timeout with s=
can utility.<br>
<br>With (custom built vanilla) kernel 3.6 and custom built 3.5 (with -pf p=
atches), when running on baremetal; with intel_iommu=3D1 I am unable to get=
 any DVB data. I have tried intel_iommu=3D0 and I still cannot get DVB data=
. To add to this I now have DMAR messages in dmesg output (06:00.0 is the D=
VB card) :<br>
<br>[=A0=A0=A0<b> 0.074639</b>] DMAR:[DMA Read] Request device [06:00.0] fa=
ult addr 80c6000<br>[=A0=A0=A0 <b>0.074639</b>] DMAR:[fault reason 02] Pres=
ent bit in context entry is clear<br>[=A0=A0=A0 0.422177] DMAR: No ATSR fou=
nd<br>[=A0=A0 49.194033] DMAR:[DMA Read] Request device [06:00.0] fault add=
r fff7f000<br>
[=A0=A0 49.194033] DMAR:[fault reason 02] Present bit in context entry is c=
lear<br><br>Also, I'm getting these (with intel_iommu=3D0 or with intel=
_iommu=3D1) under 3.5-pf kernel and 3.6 custom vanilla:<br><br>[=A0=A0=A0 0=
.418811] IOMMU: Setting identity map for device 0000:00:1f.0 [0x0 - 0xfffff=
f]<br>
[=A0=A0=A0 0.419294]=A0 [<ffffffff81250d01>] ? intel_iommu_device_gro=
up+0x64/0xb1<br>[=A0=A0=A0 0.419330]=A0 [<ffffffff8124c9b0>] ? bus_se=
t_iommu+0x37/0x37<br>[=A0=A0=A0 0.419364]=A0 [<ffffffff8124c9c2>] ? a=
dd_iommu_group+0x12/0x2f<br>
[=A0=A0=A0 0.419399]=A0 [<ffffffff8124c9b0>] ? bus_set_iommu+0x37/0x3=
7<br>[=A0=A0=A0 0.420778]=A0 [<ffffffff8124c9ac>] ? bus_set_iommu+0x3=
3/0x37<br>[=A0=A0=A0 0.420813]=A0 [<ffffffff814c39c0>] ? intel_iommu_=
init+0x9a9/0xac5<br>
[=A0=A0=A0 0.420920]=A0 [<ffffffff8149c7df>] ? pci_iommu_init+0xe/0x3=
7<br><br><br>Now; I did manage to get it it work WITH Xen under the followi=
ng conditions:<br><br>Debian kernel 3.2.0 and Xen (Dom0) and passing "=
iommu=3D0" on the xen line. <br>
<br>FYI I'd like to mention that I have had success doing VGA passthrou=
gh to Win XP guest (Intel on board graphics) so I'm reasonably confiden=
t the BIOS IOMMU code is OK (Asrock Z77 Extreme 4 motherboard - BIOS versio=
n 1.30).<br>
<br>What are your thoughts?<br><br>Regards,<br><br>John<br><br><br><div cla=
ss=3D"gmail_quote">On 26 September 2012 11:02, John Krstev <span dir=3D"ltr=
"><<a href=3D"mailto:john.krstev@gmail.com" target=3D"_blank">john.krste=
v@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Hey Konrad,<br><br>>Please do not top-pos=
t.<br>Apologies. <br><div class=3D"im"><br><br>>So try also limiting how=
 much memory the hypervisor has to eliminate<br>

>this being a 4GB issue. Meaning on the _hypervisor_ line add 'mem=
=3D4G'.<br><br></div>Yes, that was on the hypervisor line which I was s=
pecifying mem=3D3G. I've also tried mem=3D4G and still having the same =
problem.<div class=3D"im">
<br>
<br>>And I need to know whether you are running this in a domain or in t=
he initial domain?<br>
<br></div>Running in Dom0.<div class=3D"im"><br><br>>If you do it manual=
ly (cat /dev/video0 > /tmp/file.mpg)<br>
>does the file increase? Is it full of garbage ?<br><br></div>cat: /dev/=
video0: Input/output error<br><br>The file size is 0 bytes.<div class=3D"im=
"><br><br>>Does the channel selection work? Can you select the proper ch=
annel?<br>
</div>Analogue selection works ok and I can also watch analogue TV. When us=
ing digital, I get a lock but no video data.<div class=3D"im"><br>

<br>> If you crank up all the debug options do you get anything saying w=
hat the problem is<br><br></div>With debug turned on to level 8 (echo 8 >=
; /proc/sys/kernel/printk) I see the following in dmesg which may be useful=
:<br>

[130009.484098] cx88[0]/0: [ffff8802c03b3400/0] timeout - dma=3D0x96a7e000<=
br><br>Let me know if there's anything else I can try?<br><br>Regards,<=
br><br>John<div class=3D"HOEnZb"><div class=3D"h5"><br><br><div class=3D"gm=
ail_quote">
On 26 September 2012 00:10, Konrad Rzeszutek Wilk <span dir=3D"ltr"><<a =
href=3D"mailto:konrad@kernel.org" target=3D"_blank">konrad@kernel.org</a>&g=
t;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On Tue, Sep 25, 2012 at 10:49:38AM +1000, John Krstev wrote:<br>
> Hello Konrad,<br>
<br>
Hey John,<br>
<br>
Please do not top-post.<br>
<div>><br>
> Do you have any patches I can try? FYI I've tried booting dom0 wit=
h mem=3D3G and various other options, still does not work. As I mentioned i=
t runs fine on bare metal.<br>
<br>
</div>So try also limiting how much memory the hypervisor has to eliminate<=
br>
this being a 4GB issue. Meaning on the _hypervisor_ line add 'mem=3D4G&=
#39;.<br>
<br>
The next step is to actually figure out if where in the driver (cx88)<br>
fails. And I need to know whether you are running this in a domain or<br>
in the initial domain? If you crank up all the debug options do you<br>
get anything saying what the problem is? How do you 'capture' the<b=
r>
video output? If you do it manually (cat /dev/video0 > /tmp/file.mpg)<br=
>
does the file increase? Is it full of garbage ?<br>
<br>
Does the channel selection work? Can you select the proper channel?<br>
<div><div><br>
><br>
> Last time it did work with xen was Jeremy's kernel + xen 4.0, also=
 kernel 3.0.8 with xen 4.0.4 i believe (cannot reproduce success).<br>
><br>
> Thank you again for your input.<br>
><br>
> Regards,<br>
><br>
> John<br>
><br>
><br>
><br>
> On 22/09/2012, at 3:29, Konrad Rzeszutek Wilk <<a href=3D"mailto:ko=
nrad@kernel.org" target=3D"_blank">konrad@kernel.org</a>> wrote:<br>
><br>
> > On Fri, Sep 21, 2012 at 01:02:23PM +1000, John Krstev wrote:<br>
> >> Hi Konrad,<br>
> ><br>
> > Hey John,<br>
> ><br>
> > Please next time also include xen-devel on the To header. I'v=
e done that<br>
> > for you.<br>
> >><br>
> >> I refer to your patch at:<br>
> >> <a href=3D"http://lists.xen.org/archives/html/xen-devel/2012-=
01/msg01927.html" target=3D"_blank">http://lists.xen.org/archives/html/xen-=
devel/2012-01/msg01927.html</a><br>
> >> which I found reading<br>
> >> <a href=3D"http://www.gossamer-threads.com/lists/xen/devel/25=
6197" target=3D"_blank">http://www.gossamer-threads.com/lists/xen/devel/256=
197</a><br>
> >><br>
> >> I have a winfast DVT 2000H (cx88) DVB card which is not able =
to<br>
> >> scan/watch digital TV when running under Xen.<br>
> ><br>
> > Did you first try running it under baremetal Linux (using a Live =
CD for<br>
> > example?) Did it work there?<br>
> ><br>
> > How does it not work? Can you program it? Is this under a guest o=
r the<br>
> > main kernel? When it wsa not working, did you try all the debug<b=
r>
> > options enable (<a href=3D"http://wiki.xen.org/wiki/XenSerialCons=
ole" target=3D"_blank">http://wiki.xen.org/wiki/XenSerialConsole</a>) to<br=
>
> > see if there is anthing being reported?<br>
> ><br>
> >><br>
> >> I've tried installing the above patch to the 3.6-rc6 kern=
el, but did<br>
> >> not seem to help.<br>
> >><br>
> >> Apologies if this has been asked before (I wasn't able to=
 find another<br>
> >> patch), but is there a patch to get this (suspected vmalloc_3=
2) fixed<br>
> >> and DVB card working?<br>
> ><br>
> > Eventually yes.<br>
> >><br>
> >> FYI I'm running 64 bit 3.5-rc6 and xen 4.3-unstable.<br>
> ><br>
> > 3.5-rc6 or 3.6-rc6?<br>
> > I presume the latter?<br>
> >><br>
> >> Thank you! :)<br>
> >><br>
> >> Regards,<br>
> >><br>
> >> John<br>
> >><br>
><br>
</div></div>> _______________________________________________<br>
> Xen-devel mailing list<br>
> <a href=3D"mailto:Xen-devel@lists.xen.org" target=3D"_blank">Xen-devel=
@lists.xen.org</a><br>
> <a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://li=
sts.xen.org/xen-devel</a><br>
><br>
</blockquote></div><br>
</div></div></blockquote></div><br>

--20cf307c9c1cf5390004cbd555f7--


--===============6005088499668153197==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6005088499668153197==--


From xen-devel-bounces@lists.xen.org Fri Oct 12 04:49:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 04:49:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMXAs-0002y0-Nt; Fri, 12 Oct 2012 04:48:38 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TMXAr-0002xt-DW
	for xen-devel@lists.xensource.com; Fri, 12 Oct 2012 04:48:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1350017311!10633044!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQyNDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27165 invoked from network); 12 Oct 2012 04:48:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 04:48:31 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="15116819"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 04:48:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 12 Oct 2012 05:48:30 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1TMXAk-0001XO-7n;
	Fri, 12 Oct 2012 04:48:30 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TMXAj-0008E9-QW;
	Fri, 12 Oct 2012 05:48:30 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13957-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 12 Oct 2012 05:48:29 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13957: tolerable trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13957 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13957/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-credit2    3 host-install(3)           broken pass in 13956

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13956
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13956
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13956
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13956

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  e0e1350dfe9b
baseline version:
 xen                  e0e1350dfe9b

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 04:49:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 04:49:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMXAs-0002y0-Nt; Fri, 12 Oct 2012 04:48:38 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TMXAr-0002xt-DW
	for xen-devel@lists.xensource.com; Fri, 12 Oct 2012 04:48:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1350017311!10633044!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQyNDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27165 invoked from network); 12 Oct 2012 04:48:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 04:48:31 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="15116819"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 04:48:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 12 Oct 2012 05:48:30 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1TMXAk-0001XO-7n;
	Fri, 12 Oct 2012 04:48:30 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TMXAj-0008E9-QW;
	Fri, 12 Oct 2012 05:48:30 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13957-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 12 Oct 2012 05:48:29 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13957: tolerable trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13957 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13957/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-credit2    3 host-install(3)           broken pass in 13956

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13956
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13956
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13956
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13956

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  e0e1350dfe9b
baseline version:
 xen                  e0e1350dfe9b

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 08:41:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 08:41:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMao8-0004k2-Uj; Fri, 12 Oct 2012 08:41:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TMao8-0004jx-5t
	for Xen-devel@lists.xensource.com; Fri, 12 Oct 2012 08:41:24 +0000
Received: from [85.158.139.211:59453] by server-9.bemta-5.messagelabs.com id
	8D/26-31466-3B7D7705; Fri, 12 Oct 2012 08:41:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1350031282!21978565!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQyNDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29522 invoked from network); 12 Oct 2012 08:41:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 08:41:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="15120472"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 08:41:00 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 12 Oct 2012 09:41:00 +0100
Message-ID: <1350031258.14806.40.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Fri, 12 Oct 2012 09:40:58 +0100
In-Reply-To: <20121011162638.76ec328c@mantra.us.oracle.com>
References: <20121011162638.76ec328c@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] struct xen_add_to_physmap UNION
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-12 at 00:26 +0100, Mukesh Rathor wrote:
> Hi,
> 
> What's the latest on the union of size/foreign_domid. I don't see it
> checked in xen unstable. Final decision is to unionize it, right? It
> doesn't matter for PVH either way.

I think the final decision is to go with XENMEM_add_to_physmap_range,
see <1349433507-21148-1-git-send-email-ian.campbell@citrix.com>.

Ian.

> 
> +++ b/xen/include/public/memory.h       Thu Oct 11 16:24:47 2012 -0700
> @@ -208,14 +208,19 @@ struct xen_add_to_physmap {
>      /* Which domain to change the mapping for. */
>      domid_t domid;
>  
> -    /* Number of pages to go through for gmfn_range */
> -    uint16_t    size;
> +    union {
> +        /* Number of pages to go through for gmfn_range */
> +        uint16_t    size;
> +        /* IFF XENMAPSPACE_gmfn_foreign */
> +        domid_t foreign_domid;
> +    } u;
> 
> 
> thanks,
> Mukesh



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 08:41:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 08:41:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMao8-0004k2-Uj; Fri, 12 Oct 2012 08:41:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TMao8-0004jx-5t
	for Xen-devel@lists.xensource.com; Fri, 12 Oct 2012 08:41:24 +0000
Received: from [85.158.139.211:59453] by server-9.bemta-5.messagelabs.com id
	8D/26-31466-3B7D7705; Fri, 12 Oct 2012 08:41:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1350031282!21978565!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQyNDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29522 invoked from network); 12 Oct 2012 08:41:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 08:41:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="15120472"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 08:41:00 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 12 Oct 2012 09:41:00 +0100
Message-ID: <1350031258.14806.40.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Fri, 12 Oct 2012 09:40:58 +0100
In-Reply-To: <20121011162638.76ec328c@mantra.us.oracle.com>
References: <20121011162638.76ec328c@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] struct xen_add_to_physmap UNION
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-12 at 00:26 +0100, Mukesh Rathor wrote:
> Hi,
> 
> What's the latest on the union of size/foreign_domid. I don't see it
> checked in xen unstable. Final decision is to unionize it, right? It
> doesn't matter for PVH either way.

I think the final decision is to go with XENMEM_add_to_physmap_range,
see <1349433507-21148-1-git-send-email-ian.campbell@citrix.com>.

Ian.

> 
> +++ b/xen/include/public/memory.h       Thu Oct 11 16:24:47 2012 -0700
> @@ -208,14 +208,19 @@ struct xen_add_to_physmap {
>      /* Which domain to change the mapping for. */
>      domid_t domid;
>  
> -    /* Number of pages to go through for gmfn_range */
> -    uint16_t    size;
> +    union {
> +        /* Number of pages to go through for gmfn_range */
> +        uint16_t    size;
> +        /* IFF XENMAPSPACE_gmfn_foreign */
> +        domid_t foreign_domid;
> +    } u;
> 
> 
> thanks,
> Mukesh



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 08:49:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 08:49:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMavL-0004t2-UA; Fri, 12 Oct 2012 08:48:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TMavK-0004su-SB
	for Xen-devel@lists.xensource.com; Fri, 12 Oct 2012 08:48:51 +0000
Received: from [85.158.143.35:17482] by server-1.bemta-4.messagelabs.com id
	5F/1F-19551-279D7705; Fri, 12 Oct 2012 08:48:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1350031729!6333498!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQyNDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16499 invoked from network); 12 Oct 2012 08:48:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 08:48:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="15120690"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 08:48:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 12 Oct 2012 09:48:49 +0100
Message-ID: <1350031728.14806.45.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Fri, 12 Oct 2012 09:48:48 +0100
In-Reply-To: <20121011145317.51655302@mantra.us.oracle.com>
References: <20121011145317.51655302@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH V2 1/7]: PVH: basic and header changes,
	elfnote changes, ...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-11 at 22:53 +0100, Mukesh Rathor wrote:
> PVH: is a PV linux guest that has extended capabilities. This patch allows it to be configured and enabled. Also, basic header file changes to add new subcalls to physmap hypercall. Lastly, mfn_to_local_pfn must return mfn for paging mode translate
> 
> Signed-off-by: Mukesh R <mukesh.rathor@oracle.com>

Since a S-o-b is a quasi-legal statement you probably ought to put your
full name here (I know it's obvious from the email address, but...)

> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> index fdce49c..9323b8c 100644
> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@ -50,3 +50,13 @@ config XEN_DEBUG_FS
>  	  Enable statistics output and various tuning options in debugfs.
>  	  Enabling this option may incur a significant performance overhead.
>  
> +config XEN_X86_PVH
> +	bool "Support for running as a PVH guest (EXPERIMENTAL)"
> +	depends on X86_64 && XEN && INTEL_IOMMU && EXPERIMENTAL

OOI why does the kernel side require an INTEL_IOMMU? I can see why the
hypervisor would need it but the guests (including dom0) can't actually
see the underlying IOMMU, can they?

> +	default n
> +	help
> +	   This option enables support for running as a PVH guest (PV guest
> +	   using hardware extensions) under a suitably capable hypervisor.
> +	   This option is EXPERIMETNAL because the hypervisor interfaces

You've carried over my original "EXPERIMETNAL" typo.

> +	   which it uses are not yet considered stable therefore backwards and
> +	   forwards compatibility is not yet guaranteed.  If unsure, say N.
> diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
> index 7faed58..3e65ece 100644
> --- a/arch/x86/xen/xen-head.S
> +++ b/arch/x86/xen/xen-head.S
> @@ -13,6 +13,15 @@
>  #include <xen/interface/elfnote.h>
>  #include <asm/xen/interface.h>
>  
> +#ifdef CONFIG_XEN_X86_PVH
> +#define FEATURES_PVH "| writable_descriptor_tables" \
> +		     "| auto_translated_physmap" \
> +		     "| supervisor_mode_kernel" \
> +		     "| hvm_callback_vector"

It's pretty lame but it looks like elf_xen_parse_features doesn't
support stripping whitespace.

Since we need these features to be parsable by older hypervisors and
tools I think we're stuck with that snafu.

> diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
> index 9ce788d..3b9d5b6 100644
> --- a/include/xen/interface/physdev.h
> +++ b/include/xen/interface/physdev.h
> @@ -258,6 +258,16 @@ struct physdev_pci_device {
>      uint8_t devfn;
>  };
>  
> +#define PHYSDEVOP_pvh_map_iomem        30
> +struct physdev_map_iomem {
> +    /* IN */
> +    uint64_t first_gfn;
> +    uint64_t first_mfn;
> +    uint32_t nr_mfns;
> +    uint32_t add_mapping;        /* 1 == add mapping;  0 == unmap */
> +
> +};
> +
>  /*
>   * Notify that some PIRQ-bound event channels have been unmasked.
>   * ** This command is obsolete since interface version 0x00030202 and is **



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 08:49:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 08:49:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMavL-0004t2-UA; Fri, 12 Oct 2012 08:48:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TMavK-0004su-SB
	for Xen-devel@lists.xensource.com; Fri, 12 Oct 2012 08:48:51 +0000
Received: from [85.158.143.35:17482] by server-1.bemta-4.messagelabs.com id
	5F/1F-19551-279D7705; Fri, 12 Oct 2012 08:48:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1350031729!6333498!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQyNDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16499 invoked from network); 12 Oct 2012 08:48:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 08:48:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="15120690"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 08:48:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 12 Oct 2012 09:48:49 +0100
Message-ID: <1350031728.14806.45.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Fri, 12 Oct 2012 09:48:48 +0100
In-Reply-To: <20121011145317.51655302@mantra.us.oracle.com>
References: <20121011145317.51655302@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH V2 1/7]: PVH: basic and header changes,
	elfnote changes, ...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-11 at 22:53 +0100, Mukesh Rathor wrote:
> PVH: is a PV linux guest that has extended capabilities. This patch allows it to be configured and enabled. Also, basic header file changes to add new subcalls to physmap hypercall. Lastly, mfn_to_local_pfn must return mfn for paging mode translate
> 
> Signed-off-by: Mukesh R <mukesh.rathor@oracle.com>

Since a S-o-b is a quasi-legal statement you probably ought to put your
full name here (I know it's obvious from the email address, but...)

> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> index fdce49c..9323b8c 100644
> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@ -50,3 +50,13 @@ config XEN_DEBUG_FS
>  	  Enable statistics output and various tuning options in debugfs.
>  	  Enabling this option may incur a significant performance overhead.
>  
> +config XEN_X86_PVH
> +	bool "Support for running as a PVH guest (EXPERIMENTAL)"
> +	depends on X86_64 && XEN && INTEL_IOMMU && EXPERIMENTAL

OOI why does the kernel side require an INTEL_IOMMU? I can see why the
hypervisor would need it but the guests (including dom0) can't actually
see the underlying IOMMU, can they?

> +	default n
> +	help
> +	   This option enables support for running as a PVH guest (PV guest
> +	   using hardware extensions) under a suitably capable hypervisor.
> +	   This option is EXPERIMETNAL because the hypervisor interfaces

You've carried over my original "EXPERIMETNAL" typo.

> +	   which it uses are not yet considered stable therefore backwards and
> +	   forwards compatibility is not yet guaranteed.  If unsure, say N.
> diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
> index 7faed58..3e65ece 100644
> --- a/arch/x86/xen/xen-head.S
> +++ b/arch/x86/xen/xen-head.S
> @@ -13,6 +13,15 @@
>  #include <xen/interface/elfnote.h>
>  #include <asm/xen/interface.h>
>  
> +#ifdef CONFIG_XEN_X86_PVH
> +#define FEATURES_PVH "| writable_descriptor_tables" \
> +		     "| auto_translated_physmap" \
> +		     "| supervisor_mode_kernel" \
> +		     "| hvm_callback_vector"

It's pretty lame but it looks like elf_xen_parse_features doesn't
support stripping whitespace.

Since we need these features to be parsable by older hypervisors and
tools I think we're stuck with that snafu.

> diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
> index 9ce788d..3b9d5b6 100644
> --- a/include/xen/interface/physdev.h
> +++ b/include/xen/interface/physdev.h
> @@ -258,6 +258,16 @@ struct physdev_pci_device {
>      uint8_t devfn;
>  };
>  
> +#define PHYSDEVOP_pvh_map_iomem        30
> +struct physdev_map_iomem {
> +    /* IN */
> +    uint64_t first_gfn;
> +    uint64_t first_mfn;
> +    uint32_t nr_mfns;
> +    uint32_t add_mapping;        /* 1 == add mapping;  0 == unmap */
> +
> +};
> +
>  /*
>   * Notify that some PIRQ-bound event channels have been unmasked.
>   * ** This command is obsolete since interface version 0x00030202 and is **



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 08:53:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 08:53:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMaz0-00051H-N2; Fri, 12 Oct 2012 08:52:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TMayz-000519-7x
	for Xen-devel@lists.xensource.com; Fri, 12 Oct 2012 08:52:37 +0000
Received: from [85.158.138.51:49275] by server-15.bemta-3.messagelabs.com id
	4E/A2-10261-45AD7705; Fri, 12 Oct 2012 08:52:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1350031955!32411145!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQyNDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11273 invoked from network); 12 Oct 2012 08:52:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 08:52:35 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="15120784"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 08:52:18 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 12 Oct 2012 09:52:18 +0100
Message-ID: <1350031937.14806.49.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Fri, 12 Oct 2012 09:52:17 +0100
In-Reply-To: <20121011145711.0d9c27df@mantra.us.oracle.com>
References: <20121011145711.0d9c27df@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH V2 2/7]: PVH: use native irq, enable callback,
 use HVM ring ops, ...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-11 at 22:57 +0100, Mukesh Rathor wrote:
> PVH: make gdt_frames[]/gdt_ents into a union with {gdtaddr, gdtsz}, PVH
> only needs to send down gdtaddr and gdtsz. irq.c: PVH uses
> native_irq_ops. vcpu hotplug is currently not available for PVH.
> events.c: setup callback vector for PVH. Finally, PVH ring ops uses HVM
> paths for xenbus.
> 
> Signed-off-by: Mukesh R <mukesh.rathor@oracle.com>
> ---
>  arch/x86/include/asm/xen/interface.h |    8 +++++++-
>  arch/x86/xen/irq.c                   |    5 ++++-
>  arch/x86/xen/p2m.c                   |    2 +-
>  arch/x86/xen/smp.c                   |    4 ++--
>  drivers/xen/cpu_hotplug.c            |    4 +++-
>  drivers/xen/events.c                 |    9 ++++++++-
>  drivers/xen/xenbus/xenbus_client.c   |    3 ++-
>  7 files changed, 27 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
> index 555f94d..f11edb0 100644
> --- a/arch/x86/include/asm/xen/interface.h
> +++ b/arch/x86/include/asm/xen/interface.h
> @@ -143,7 +143,13 @@ struct vcpu_guest_context {
>      struct cpu_user_regs user_regs;         /* User-level CPU registers     */
>      struct trap_info trap_ctxt[256];        /* Virtual IDT                  */
>      unsigned long ldt_base, ldt_ents;       /* LDT (linear address, # ents) */
> -    unsigned long gdt_frames[16], gdt_ents; /* GDT (machine frames, # ents) */
> +    union {
> +	struct {
> +		/* PV: GDT (machine frames, # ents).*/
> +		unsigned long gdt_frames[16], gdt_ents;
> +	} s;
> +	unsigned long gdtaddr, gdtsz;	    /* PVH: GDTR addr and size */

I've pointed out a few times that I think this is wrong -- gdtaddr and
gdtsz will overlap each other in the union. I'm not sure how it even
works, unless the hypervisor is ignoring one or the other. You need:

union {
	struct {
		unsigned long gdt_frames[16], gdt_ents;
	} pv;
	struct {
		unsigned long gdtaddr, gdtsz;
	} pvh;
} gdt;

(I've gone with naming the union gdt instead of u. You might want
therefore to also drop the gdt prefix from the members?)

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 08:53:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 08:53:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMaz0-00051H-N2; Fri, 12 Oct 2012 08:52:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TMayz-000519-7x
	for Xen-devel@lists.xensource.com; Fri, 12 Oct 2012 08:52:37 +0000
Received: from [85.158.138.51:49275] by server-15.bemta-3.messagelabs.com id
	4E/A2-10261-45AD7705; Fri, 12 Oct 2012 08:52:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1350031955!32411145!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQyNDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11273 invoked from network); 12 Oct 2012 08:52:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 08:52:35 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="15120784"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 08:52:18 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 12 Oct 2012 09:52:18 +0100
Message-ID: <1350031937.14806.49.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Fri, 12 Oct 2012 09:52:17 +0100
In-Reply-To: <20121011145711.0d9c27df@mantra.us.oracle.com>
References: <20121011145711.0d9c27df@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH V2 2/7]: PVH: use native irq, enable callback,
 use HVM ring ops, ...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-11 at 22:57 +0100, Mukesh Rathor wrote:
> PVH: make gdt_frames[]/gdt_ents into a union with {gdtaddr, gdtsz}, PVH
> only needs to send down gdtaddr and gdtsz. irq.c: PVH uses
> native_irq_ops. vcpu hotplug is currently not available for PVH.
> events.c: setup callback vector for PVH. Finally, PVH ring ops uses HVM
> paths for xenbus.
> 
> Signed-off-by: Mukesh R <mukesh.rathor@oracle.com>
> ---
>  arch/x86/include/asm/xen/interface.h |    8 +++++++-
>  arch/x86/xen/irq.c                   |    5 ++++-
>  arch/x86/xen/p2m.c                   |    2 +-
>  arch/x86/xen/smp.c                   |    4 ++--
>  drivers/xen/cpu_hotplug.c            |    4 +++-
>  drivers/xen/events.c                 |    9 ++++++++-
>  drivers/xen/xenbus/xenbus_client.c   |    3 ++-
>  7 files changed, 27 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
> index 555f94d..f11edb0 100644
> --- a/arch/x86/include/asm/xen/interface.h
> +++ b/arch/x86/include/asm/xen/interface.h
> @@ -143,7 +143,13 @@ struct vcpu_guest_context {
>      struct cpu_user_regs user_regs;         /* User-level CPU registers     */
>      struct trap_info trap_ctxt[256];        /* Virtual IDT                  */
>      unsigned long ldt_base, ldt_ents;       /* LDT (linear address, # ents) */
> -    unsigned long gdt_frames[16], gdt_ents; /* GDT (machine frames, # ents) */
> +    union {
> +	struct {
> +		/* PV: GDT (machine frames, # ents).*/
> +		unsigned long gdt_frames[16], gdt_ents;
> +	} s;
> +	unsigned long gdtaddr, gdtsz;	    /* PVH: GDTR addr and size */

I've pointed out a few times that I think this is wrong -- gdtaddr and
gdtsz will overlap each other in the union. I'm not sure how it even
works, unless the hypervisor is ignoring one or the other. You need:

union {
	struct {
		unsigned long gdt_frames[16], gdt_ents;
	} pv;
	struct {
		unsigned long gdtaddr, gdtsz;
	} pvh;
} gdt;

(I've gone with naming the union gdt instead of u. You might want
therefore to also drop the gdt prefix from the members?)

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 08:58:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 08:58:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMb4E-0005Bw-F0; Fri, 12 Oct 2012 08:58:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TMb4C-0005Bq-Vk
	for Xen-devel@lists.xensource.com; Fri, 12 Oct 2012 08:58:01 +0000
Received: from [85.158.138.51:29235] by server-3.bemta-3.messagelabs.com id
	D1/FD-09368-89BD7705; Fri, 12 Oct 2012 08:58:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1350032278!26172589!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQzMTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2576 invoked from network); 12 Oct 2012 08:57:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 08:57:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="15120992"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 08:57:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 12 Oct 2012 09:57:58 +0100
Message-ID: <1350032276.14806.53.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Fri, 12 Oct 2012 09:57:56 +0100
In-Reply-To: <20121011145817.0d744c99@mantra.us.oracle.com>
References: <20121011145817.0d744c99@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH V2 3/7]: PVH:  mmu related changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-11 at 22:58 +0100, Mukesh Rathor wrote:
> @@ -2177,8 +2210,19 @@ static const struct pv_mmu_ops xen_mmu_ops __initconst = {
> 
>  void __init xen_init_mmu_ops(void)
>  {
> -       x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
>         x86_init.paging.pagetable_init = xen_pagetable_init;
> +
> +       if (xen_feature(XENFEAT_auto_translated_physmap)) {
> +               pv_mmu_ops.flush_tlb_others = xen_flush_tlb_others;
> +
> +               /* For PCI devices to map iomem. */
> +               if (xen_initial_domain()) {
> +                       pv_mmu_ops.set_pte = native_set_pte;
> +                       pv_mmu_ops.set_pte_at = native_set_pte_at;

What do these end up being for the !xen_initial_domain case? I'd have
expected native_FOO.

> +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma)
> +{
> +       int numpgs = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
> +       struct page **pages = vma ? vma->vm_private_data : NULL;

I thought we agreed to keep uses of vm_private_data in the privcmd
driver?

I think you should just add pages and nr as direct parameters to this
function, which is symmetric with the map call.

> +
> +       if (!pages || !xen_feature(XENFEAT_auto_translated_physmap))
> +               return 0;
> +
> +       while (numpgs--) {
> +
> +               /* the mmu has already cleaned up the process mmu resources at
> +                * this point (lookup_address will return NULL). */
> +               unsigned long pfn = page_to_pfn(pages[numpgs]);
> +
> +               pvh_rem_xen_p2m(pfn, 1);
> +       }
> +       /* We don't need to flush tlbs because as part of pvh_rem_xen_p2m(),
> +        * the hypervisor will do tlb flushes after removing the p2m entries
> +        * from the EPT/NPT */
> +       return 0;
> +}
> +EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range);
[...]
> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> index ef63895..63d9ee8 100644
> --- a/drivers/xen/privcmd.c
> +++ b/drivers/xen/privcmd.c
> @@ -178,7 +178,7 @@ static int mmap_mfn_range(void *data, void *state)
>                                         msg->va & PAGE_MASK,
>                                         msg->mfn, msg->npages,
>                                         vma->vm_page_prot,
> -                                       st->domain);
> +                                       st->domain, NULL);

Might it be useful to BUG_ON(!pages) in pvh_remap_gmfn_range?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 08:58:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 08:58:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMb4E-0005Bw-F0; Fri, 12 Oct 2012 08:58:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TMb4C-0005Bq-Vk
	for Xen-devel@lists.xensource.com; Fri, 12 Oct 2012 08:58:01 +0000
Received: from [85.158.138.51:29235] by server-3.bemta-3.messagelabs.com id
	D1/FD-09368-89BD7705; Fri, 12 Oct 2012 08:58:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1350032278!26172589!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQzMTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2576 invoked from network); 12 Oct 2012 08:57:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 08:57:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="15120992"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 08:57:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 12 Oct 2012 09:57:58 +0100
Message-ID: <1350032276.14806.53.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Fri, 12 Oct 2012 09:57:56 +0100
In-Reply-To: <20121011145817.0d744c99@mantra.us.oracle.com>
References: <20121011145817.0d744c99@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH V2 3/7]: PVH:  mmu related changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-11 at 22:58 +0100, Mukesh Rathor wrote:
> @@ -2177,8 +2210,19 @@ static const struct pv_mmu_ops xen_mmu_ops __initconst = {
> 
>  void __init xen_init_mmu_ops(void)
>  {
> -       x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
>         x86_init.paging.pagetable_init = xen_pagetable_init;
> +
> +       if (xen_feature(XENFEAT_auto_translated_physmap)) {
> +               pv_mmu_ops.flush_tlb_others = xen_flush_tlb_others;
> +
> +               /* For PCI devices to map iomem. */
> +               if (xen_initial_domain()) {
> +                       pv_mmu_ops.set_pte = native_set_pte;
> +                       pv_mmu_ops.set_pte_at = native_set_pte_at;

What do these end up being for the !xen_initial_domain case? I'd have
expected native_FOO.

> +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma)
> +{
> +       int numpgs = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
> +       struct page **pages = vma ? vma->vm_private_data : NULL;

I thought we agreed to keep uses of vm_private_data in the privcmd
driver?

I think you should just add pages and nr as direct parameters to this
function, which is symmetric with the map call.

> +
> +       if (!pages || !xen_feature(XENFEAT_auto_translated_physmap))
> +               return 0;
> +
> +       while (numpgs--) {
> +
> +               /* the mmu has already cleaned up the process mmu resources at
> +                * this point (lookup_address will return NULL). */
> +               unsigned long pfn = page_to_pfn(pages[numpgs]);
> +
> +               pvh_rem_xen_p2m(pfn, 1);
> +       }
> +       /* We don't need to flush tlbs because as part of pvh_rem_xen_p2m(),
> +        * the hypervisor will do tlb flushes after removing the p2m entries
> +        * from the EPT/NPT */
> +       return 0;
> +}
> +EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range);
[...]
> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> index ef63895..63d9ee8 100644
> --- a/drivers/xen/privcmd.c
> +++ b/drivers/xen/privcmd.c
> @@ -178,7 +178,7 @@ static int mmap_mfn_range(void *data, void *state)
>                                         msg->va & PAGE_MASK,
>                                         msg->mfn, msg->npages,
>                                         vma->vm_page_prot,
> -                                       st->domain);
> +                                       st->domain, NULL);

Might it be useful to BUG_ON(!pages) in pvh_remap_gmfn_range?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 09:07:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 09:07:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMbCx-0005aZ-4T; Fri, 12 Oct 2012 09:07:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TMbCv-0005aP-3M
	for Xen-devel@lists.xensource.com; Fri, 12 Oct 2012 09:07:01 +0000
Received: from [85.158.139.211:26821] by server-10.bemta-5.messagelabs.com id
	CC/B6-06995-4BDD7705; Fri, 12 Oct 2012 09:07:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1350032819!22100947!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQyNDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4068 invoked from network); 12 Oct 2012 09:06:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 09:06:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="15121246"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 09:06:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 12 Oct 2012 10:06:58 +0100
Message-ID: <1350032817.14806.58.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Fri, 12 Oct 2012 10:06:57 +0100
In-Reply-To: <20121011150113.4d525407@mantra.us.oracle.com>
References: <20121011150113.4d525407@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH V2 6/7]: PVH: balloon and grant changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-11 at 23:01 +0100, Mukesh Rathor wrote:
> PVH: balloon and grant changes. For balloon changes we skip setting of
> local p2m as it's updated in xen. For grant, the shared grant frame is
> the pfn and not mfn, hence its mapped via the same code path as HVM
> 
> Signed-off-by: Mukesh R <mukesh.rathor@oracle.com>
> ---
>  drivers/xen/balloon.c     |   18 +++++++++++-------
>  drivers/xen/gntdev.c      |    3 ++-
>  drivers/xen/grant-table.c |   25 +++++++++++++++++++++----
>  3 files changed, 34 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> index 31ab82f..9b895ad 100644
> --- a/drivers/xen/balloon.c
> +++ b/drivers/xen/balloon.c
> @@ -358,10 +358,13 @@ static enum bp_state increase_reservation(unsigned long nr_pages)
>  		BUG_ON(!xen_feature(XENFEAT_auto_translated_physmap) &&
>  		       phys_to_machine_mapping_valid(pfn));
>  
> -		set_phys_to_machine(pfn, frame_list[i]);
> +		if (!xen_feature(XENFEAT_auto_translated_physmap))
> +			set_phys_to_machine(pfn, frame_list[i]);

set_phys_to_machine is a NOP if XENFEAT_auto_translated_physmap but it
includes some useful sanity checks (BUG_ON(pfn != mfn && mfn !=
INVALID_P2M_ENTRY)) so it would be useful to keep calling it I think.

>  
>  		/* Link back into the page tables if not highmem. */
> -		if (xen_pv_domain() && !PageHighMem(page)) {
> +		if (xen_pv_domain() && !PageHighMem(page) &&
> +		    !xen_feature(XENFEAT_auto_translated_physmap)) {
> +
>  			int ret;
>  			ret = HYPERVISOR_update_va_mapping(
>  				(unsigned long)__va(pfn << PAGE_SHIFT),
> @@ -418,12 +421,13 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
>  		scrub_page(page);
>  
>  		if (xen_pv_domain() && !PageHighMem(page)) {
> -			ret = HYPERVISOR_update_va_mapping(
> -				(unsigned long)__va(pfn << PAGE_SHIFT),
> -				__pte_ma(0), 0);
> -			BUG_ON(ret);
> +			if (!xen_feature(XENFEAT_auto_translated_physmap)) {

You can combine this two ifs into one (like you did above).

> +				ret = HYPERVISOR_update_va_mapping(
> +					(unsigned long)__va(pfn << PAGE_SHIFT),
> +					__pte_ma(0), 0);
> +				BUG_ON(ret);
> +			}
>  		}
> -
>  	}
>  
>  	/* Ensure that ballooned highmem pages don't have kmaps. */
> diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
> index 5df9fd8..36ec380 100644
> --- a/drivers/xen/gntdev.c
> +++ b/drivers/xen/gntdev.c
> @@ -803,7 +803,8 @@ static int __init gntdev_init(void)
>  	if (!xen_domain())
>  		return -ENODEV;
>  
> -	use_ptemod = xen_pv_domain();
> +	use_ptemod = xen_pv_domain() &&
> +		     !xen_feature(XENFEAT_auto_translated_physmap);
>  
>  	err = misc_register(&gntdev_miscdev);
>  	if (err != 0) {
> @@ -1055,7 +1060,7 @@ static void gnttab_request_version(void)
>  	int rc;
>  	struct gnttab_set_version gsv;
>  
> -	if (xen_hvm_domain())
> +	if (xen_hvm_domain() || xen_feature(XENFEAT_auto_translated_physmap))

This is just a case of not yet implemented rather than a fundamental
problem with v2 grant tables, correct? (i.e. future work)

>  		gsv.version = 1;
>  	else
>  		gsv.version = 2;
> @@ -1083,12 +1088,24 @@ static void gnttab_request_version(void)
>  int gnttab_resume(void)
>  {
>  	unsigned int max_nr_gframes;
> +	char *kmsg = "Failed to kmalloc pages for pv in hvm grant frames\n";
>  
>  	gnttab_request_version();
>  	max_nr_gframes = gnttab_max_grant_frames();
>  	if (max_nr_gframes < nr_grant_frames)
>  		return -ENOSYS;
>  
> +	/* PVH note: xen will free existing kmalloc'd mfn in
> +	 * XENMEM_add_to_physmap */

It doesn't leak it?

We should consider using xenballoon_alloc_pages here.

> +	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap) &&
> +	    !gnttab_shared.addr) {
> +		gnttab_shared.addr =
> +			kmalloc(max_nr_gframes * PAGE_SIZE, GFP_KERNEL);
> +		if (!gnttab_shared.addr) {
> +			pr_warn("%s", kmsg);
> +			return -ENOMEM;
> +		}
> +	}
>  	if (xen_pv_domain())
>  		return gnttab_map(0, nr_grant_frames - 1);
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 09:07:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 09:07:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMbCx-0005aZ-4T; Fri, 12 Oct 2012 09:07:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TMbCv-0005aP-3M
	for Xen-devel@lists.xensource.com; Fri, 12 Oct 2012 09:07:01 +0000
Received: from [85.158.139.211:26821] by server-10.bemta-5.messagelabs.com id
	CC/B6-06995-4BDD7705; Fri, 12 Oct 2012 09:07:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1350032819!22100947!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQyNDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4068 invoked from network); 12 Oct 2012 09:06:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 09:06:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="15121246"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 09:06:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 12 Oct 2012 10:06:58 +0100
Message-ID: <1350032817.14806.58.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Fri, 12 Oct 2012 10:06:57 +0100
In-Reply-To: <20121011150113.4d525407@mantra.us.oracle.com>
References: <20121011150113.4d525407@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH V2 6/7]: PVH: balloon and grant changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-11 at 23:01 +0100, Mukesh Rathor wrote:
> PVH: balloon and grant changes. For balloon changes we skip setting of
> local p2m as it's updated in xen. For grant, the shared grant frame is
> the pfn and not mfn, hence its mapped via the same code path as HVM
> 
> Signed-off-by: Mukesh R <mukesh.rathor@oracle.com>
> ---
>  drivers/xen/balloon.c     |   18 +++++++++++-------
>  drivers/xen/gntdev.c      |    3 ++-
>  drivers/xen/grant-table.c |   25 +++++++++++++++++++++----
>  3 files changed, 34 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> index 31ab82f..9b895ad 100644
> --- a/drivers/xen/balloon.c
> +++ b/drivers/xen/balloon.c
> @@ -358,10 +358,13 @@ static enum bp_state increase_reservation(unsigned long nr_pages)
>  		BUG_ON(!xen_feature(XENFEAT_auto_translated_physmap) &&
>  		       phys_to_machine_mapping_valid(pfn));
>  
> -		set_phys_to_machine(pfn, frame_list[i]);
> +		if (!xen_feature(XENFEAT_auto_translated_physmap))
> +			set_phys_to_machine(pfn, frame_list[i]);

set_phys_to_machine is a NOP if XENFEAT_auto_translated_physmap but it
includes some useful sanity checks (BUG_ON(pfn != mfn && mfn !=
INVALID_P2M_ENTRY)) so it would be useful to keep calling it I think.

>  
>  		/* Link back into the page tables if not highmem. */
> -		if (xen_pv_domain() && !PageHighMem(page)) {
> +		if (xen_pv_domain() && !PageHighMem(page) &&
> +		    !xen_feature(XENFEAT_auto_translated_physmap)) {
> +
>  			int ret;
>  			ret = HYPERVISOR_update_va_mapping(
>  				(unsigned long)__va(pfn << PAGE_SHIFT),
> @@ -418,12 +421,13 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
>  		scrub_page(page);
>  
>  		if (xen_pv_domain() && !PageHighMem(page)) {
> -			ret = HYPERVISOR_update_va_mapping(
> -				(unsigned long)__va(pfn << PAGE_SHIFT),
> -				__pte_ma(0), 0);
> -			BUG_ON(ret);
> +			if (!xen_feature(XENFEAT_auto_translated_physmap)) {

You can combine this two ifs into one (like you did above).

> +				ret = HYPERVISOR_update_va_mapping(
> +					(unsigned long)__va(pfn << PAGE_SHIFT),
> +					__pte_ma(0), 0);
> +				BUG_ON(ret);
> +			}
>  		}
> -
>  	}
>  
>  	/* Ensure that ballooned highmem pages don't have kmaps. */
> diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
> index 5df9fd8..36ec380 100644
> --- a/drivers/xen/gntdev.c
> +++ b/drivers/xen/gntdev.c
> @@ -803,7 +803,8 @@ static int __init gntdev_init(void)
>  	if (!xen_domain())
>  		return -ENODEV;
>  
> -	use_ptemod = xen_pv_domain();
> +	use_ptemod = xen_pv_domain() &&
> +		     !xen_feature(XENFEAT_auto_translated_physmap);
>  
>  	err = misc_register(&gntdev_miscdev);
>  	if (err != 0) {
> @@ -1055,7 +1060,7 @@ static void gnttab_request_version(void)
>  	int rc;
>  	struct gnttab_set_version gsv;
>  
> -	if (xen_hvm_domain())
> +	if (xen_hvm_domain() || xen_feature(XENFEAT_auto_translated_physmap))

This is just a case of not yet implemented rather than a fundamental
problem with v2 grant tables, correct? (i.e. future work)

>  		gsv.version = 1;
>  	else
>  		gsv.version = 2;
> @@ -1083,12 +1088,24 @@ static void gnttab_request_version(void)
>  int gnttab_resume(void)
>  {
>  	unsigned int max_nr_gframes;
> +	char *kmsg = "Failed to kmalloc pages for pv in hvm grant frames\n";
>  
>  	gnttab_request_version();
>  	max_nr_gframes = gnttab_max_grant_frames();
>  	if (max_nr_gframes < nr_grant_frames)
>  		return -ENOSYS;
>  
> +	/* PVH note: xen will free existing kmalloc'd mfn in
> +	 * XENMEM_add_to_physmap */

It doesn't leak it?

We should consider using xenballoon_alloc_pages here.

> +	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap) &&
> +	    !gnttab_shared.addr) {
> +		gnttab_shared.addr =
> +			kmalloc(max_nr_gframes * PAGE_SIZE, GFP_KERNEL);
> +		if (!gnttab_shared.addr) {
> +			pr_warn("%s", kmsg);
> +			return -ENOMEM;
> +		}
> +	}
>  	if (xen_pv_domain())
>  		return gnttab_map(0, nr_grant_frames - 1);
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 09:11:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 09:11:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMbHE-0005lY-Qd; Fri, 12 Oct 2012 09:11:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TMbHD-0005lQ-Ck
	for Xen-devel@lists.xensource.com; Fri, 12 Oct 2012 09:11:27 +0000
Received: from [85.158.139.211:39874] by server-7.bemta-5.messagelabs.com id
	E9/E2-20187-EBED7705; Fri, 12 Oct 2012 09:11:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1350033085!21593168!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQyNDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20535 invoked from network); 12 Oct 2012 09:11:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 09:11:25 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="15121333"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 09:11:25 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 12 Oct 2012 10:11:25 +0100
Message-ID: <1350033084.14806.60.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Fri, 12 Oct 2012 10:11:24 +0100
In-Reply-To: <20121011150207.431a087b@mantra.us.oracle.com>
References: <20121011150207.431a087b@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH V2 7/7]: PVH: privcmd changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> @@ -260,15 +268,24 @@ struct mmap_batch_state {
>  	xen_pfn_t __user *user_mfn;
>  };
>  
> +/* auto translated dom0 note: if domU being created is PV, then mfn is
> + * mfn(addr on bus). If it's auto xlated, then mfn is pfn (input to HAP).
> + */
>  static int mmap_batch_fn(void *data, void *state)
>  {
>  	xen_pfn_t *mfnp = data;
>  	struct mmap_batch_state *st = state;
> +	struct vm_area_struct *vma = st->vma;
> +	struct page **pages = vma->vm_private_data;
> +	struct page *cur_page = NULL;
>  	int ret;
>  
> +	if (xen_feature(XENFEAT_auto_translated_physmap))
> +		cur_page = pages[st->index++];

Shame we can't pass the batchiness of mmap_batch_fn through to
remap_domain_mfn_range. Perhaps one for future work.

> +
>  	ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
>  					 st->vma->vm_page_prot, st->domain,
> -					 NULL);
> +					 &cur_page);
>  
>  	/* Store error code for second pass. */
>  	*(st->err++) = ret;
> @@ -439,6 +490,20 @@ static long privcmd_ioctl(struct file *file,
>  	return ret;
>  }
>  
> +static void privcmd_close(struct vm_area_struct *vma)
> +{
> +	struct page **pages = vma ? vma->vm_private_data : NULL;
> +	int numpgs = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
> +
> +	if (!pages || !numpgs || !xen_feature(XENFEAT_auto_translated_physmap))
> +		return;
> +
> +	xen_unmap_domain_mfn_range(vma);
> +	while (numpgs--)
> +		free_xenballooned_pages(1, &pages[numpgs]);

Does free_xenballooned_pages(numpgs, pages) not do what I expect?

> +	kfree(pages);
> +}
> +
>  static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
>  {
>  	printk(KERN_DEBUG "privcmd_fault: vma=%p %lx-%lx, pgoff=%lx, uv=%p\n",
> @@ -449,6 +514,7 @@ static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
>  }
>  
>  static struct vm_operations_struct privcmd_vm_ops = {
> +	.close = privcmd_close,
>  	.fault = privcmd_fault
>  };
>  
> @@ -465,7 +531,7 @@ static int privcmd_mmap(struct file *file, struct vm_area_struct *vma)
>  
>  static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma)
>  {
> -	return (xchg(&vma->vm_private_data, (void *)1) == NULL);
> +	return !cmpxchg(&vma->vm_private_data, NULL, PRIV_VMA_LOCKED);

Looks good, thanks.

>  }
>  
>  const struct file_operations xen_privcmd_fops = {



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 09:11:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 09:11:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMbHE-0005lY-Qd; Fri, 12 Oct 2012 09:11:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TMbHD-0005lQ-Ck
	for Xen-devel@lists.xensource.com; Fri, 12 Oct 2012 09:11:27 +0000
Received: from [85.158.139.211:39874] by server-7.bemta-5.messagelabs.com id
	E9/E2-20187-EBED7705; Fri, 12 Oct 2012 09:11:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1350033085!21593168!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQyNDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20535 invoked from network); 12 Oct 2012 09:11:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 09:11:25 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="15121333"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 09:11:25 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 12 Oct 2012 10:11:25 +0100
Message-ID: <1350033084.14806.60.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Fri, 12 Oct 2012 10:11:24 +0100
In-Reply-To: <20121011150207.431a087b@mantra.us.oracle.com>
References: <20121011150207.431a087b@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH V2 7/7]: PVH: privcmd changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> @@ -260,15 +268,24 @@ struct mmap_batch_state {
>  	xen_pfn_t __user *user_mfn;
>  };
>  
> +/* auto translated dom0 note: if domU being created is PV, then mfn is
> + * mfn(addr on bus). If it's auto xlated, then mfn is pfn (input to HAP).
> + */
>  static int mmap_batch_fn(void *data, void *state)
>  {
>  	xen_pfn_t *mfnp = data;
>  	struct mmap_batch_state *st = state;
> +	struct vm_area_struct *vma = st->vma;
> +	struct page **pages = vma->vm_private_data;
> +	struct page *cur_page = NULL;
>  	int ret;
>  
> +	if (xen_feature(XENFEAT_auto_translated_physmap))
> +		cur_page = pages[st->index++];

Shame we can't pass the batchiness of mmap_batch_fn through to
remap_domain_mfn_range. Perhaps one for future work.

> +
>  	ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
>  					 st->vma->vm_page_prot, st->domain,
> -					 NULL);
> +					 &cur_page);
>  
>  	/* Store error code for second pass. */
>  	*(st->err++) = ret;
> @@ -439,6 +490,20 @@ static long privcmd_ioctl(struct file *file,
>  	return ret;
>  }
>  
> +static void privcmd_close(struct vm_area_struct *vma)
> +{
> +	struct page **pages = vma ? vma->vm_private_data : NULL;
> +	int numpgs = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
> +
> +	if (!pages || !numpgs || !xen_feature(XENFEAT_auto_translated_physmap))
> +		return;
> +
> +	xen_unmap_domain_mfn_range(vma);
> +	while (numpgs--)
> +		free_xenballooned_pages(1, &pages[numpgs]);

Does free_xenballooned_pages(numpgs, pages) not do what I expect?

> +	kfree(pages);
> +}
> +
>  static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
>  {
>  	printk(KERN_DEBUG "privcmd_fault: vma=%p %lx-%lx, pgoff=%lx, uv=%p\n",
> @@ -449,6 +514,7 @@ static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
>  }
>  
>  static struct vm_operations_struct privcmd_vm_ops = {
> +	.close = privcmd_close,
>  	.fault = privcmd_fault
>  };
>  
> @@ -465,7 +531,7 @@ static int privcmd_mmap(struct file *file, struct vm_area_struct *vma)
>  
>  static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma)
>  {
> -	return (xchg(&vma->vm_private_data, (void *)1) == NULL);
> +	return !cmpxchg(&vma->vm_private_data, NULL, PRIV_VMA_LOCKED);

Looks good, thanks.

>  }
>  
>  const struct file_operations xen_privcmd_fops = {



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 09:18:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 09:18:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMbO7-0005yt-MQ; Fri, 12 Oct 2012 09:18:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TMbO6-0005yo-76
	for Xen-devel@lists.xensource.com; Fri, 12 Oct 2012 09:18:34 +0000
Received: from [85.158.139.83:18545] by server-6.bemta-5.messagelabs.com id
	E1/28-08519-960E7705; Fri, 12 Oct 2012 09:18:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1350033512!32353061!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQyNDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7206 invoked from network); 12 Oct 2012 09:18:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 09:18:32 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="15121513"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 09:18:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 12 Oct 2012 10:18:32 +0100
Message-ID: <1350033511.14806.64.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Fri, 12 Oct 2012 10:18:31 +0100
In-Reply-To: <20121011144929.06e71a9e@mantra.us.oracle.com>
References: <20121011144929.06e71a9e@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH V2 0/7]: PVH: PV guest with extensions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-11 at 22:49 +0100, Mukesh Rathor wrote:
> Hi guys,
> 
> Ok, I've made all the changes from prev RFC patch submissions. Tested
> all the combinations. The patches are organized slightly differently
> from prev version because of the nature of changes after last review. I
> am building xen patch just for the corresponding header file changes.
> Following that I'll refresh xen tree, debug, test, and send patches.
> 
> For linux kernel mailing list introduction, PVH is a PV guest that can
> run in an HVM container, uses native pagetables, uses callback vector,
> native IDT, and native syscalls.
> 
> They were built on top of 89d0307af2b9957d59bfb2a86aaa57464ff921de
> commit.

I took a (fairly quick) look. I had a few comments but overall looks
pretty good, thanks!

I'm constantly amazed by how small this patchset is. I suspect you are
going to make up for it in the hypervisor side ;-)

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 09:18:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 09:18:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMbO7-0005yt-MQ; Fri, 12 Oct 2012 09:18:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TMbO6-0005yo-76
	for Xen-devel@lists.xensource.com; Fri, 12 Oct 2012 09:18:34 +0000
Received: from [85.158.139.83:18545] by server-6.bemta-5.messagelabs.com id
	E1/28-08519-960E7705; Fri, 12 Oct 2012 09:18:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1350033512!32353061!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQyNDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7206 invoked from network); 12 Oct 2012 09:18:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 09:18:32 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="15121513"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 09:18:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 12 Oct 2012 10:18:32 +0100
Message-ID: <1350033511.14806.64.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Fri, 12 Oct 2012 10:18:31 +0100
In-Reply-To: <20121011144929.06e71a9e@mantra.us.oracle.com>
References: <20121011144929.06e71a9e@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH V2 0/7]: PVH: PV guest with extensions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-11 at 22:49 +0100, Mukesh Rathor wrote:
> Hi guys,
> 
> Ok, I've made all the changes from prev RFC patch submissions. Tested
> all the combinations. The patches are organized slightly differently
> from prev version because of the nature of changes after last review. I
> am building xen patch just for the corresponding header file changes.
> Following that I'll refresh xen tree, debug, test, and send patches.
> 
> For linux kernel mailing list introduction, PVH is a PV guest that can
> run in an HVM container, uses native pagetables, uses callback vector,
> native IDT, and native syscalls.
> 
> They were built on top of 89d0307af2b9957d59bfb2a86aaa57464ff921de
> commit.

I took a (fairly quick) look. I had a few comments but overall looks
pretty good, thanks!

I'm constantly amazed by how small this patchset is. I suspect you are
going to make up for it in the hypervisor side ;-)

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 10:28:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 10:28:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMcTb-0006KE-EM; Fri, 12 Oct 2012 10:28:19 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TMcTa-0006K9-52
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 10:28:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1350037691!5117872!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQzMTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12415 invoked from network); 12 Oct 2012 10:28:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 10:28:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="15123624"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 10:28:09 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 12 Oct 2012 11:28:09 +0100
Message-ID: <1350037688.14806.93.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 12 Oct 2012 11:28:08 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] Dom0 physical networking/swiotlb/something issue in
	3.7-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Konrad,

The following patch causes fairly large packet loss when transmitting
from dom0 to the physical network, at least with my tg3 hardware, but I
assume it can impact anything which uses this interface.

I suspect that the issue is that the compound pages allocated in this
way are not backed by contiguous mfns and so things fall apart when the
driver tries to do DMA.

However I don't understand why the swiotlb is not fixing this up
successfully? The tg3 driver seems to use pci_map_single on this data.
Any thoughts? Perhaps the swiotlb (either generically or in the Xen
backend) doesn't correctly handle compound pages?

Ideally we would also fix this at the point of allocation to avoid the
bouncing -- I suppose that would involve using the DMA API in
netdev_alloc_frag?

We have a, sort of, similar situation in the block layer which is solved
via BIOVEC_PHYS_MERGEABLE. Sadly I don't think anything similar can
easily be retrofitted to the net drivers without changing every single
one.

Ian.

commit 69b08f62e17439ee3d436faf0b9a7ca6fffb78db
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed Sep 26 06:46:57 2012 +0000

    net: use bigger pages in __netdev_alloc_frag
    
    We currently use percpu order-0 pages in __netdev_alloc_frag
    to deliver fragments used by __netdev_alloc_skb()
    
    Depending on NIC driver and arch being 32 or 64 bit, it allows a page to
    be split in several fragments (between 1 and 8), assuming PAGE_SIZE=4096
    
    Switching to bigger pages (32768 bytes for PAGE_SIZE=4096 case) allows :
    
    - Better filling of space (the ending hole overhead is less an issue)
    
    - Less calls to page allocator or accesses to page->_count
    
    - Could allow struct skb_shared_info futures changes without major
      performance impact.
    
    This patch implements a transparent fallback to smaller
    pages in case of memory pressure.
    
    It also uses a standard "struct page_frag" instead of a custom one.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Alexander Duyck <alexander.h.duyck@intel.com>
    Cc: Benjamin LaHaise <bcrl@kvack.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 10:28:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 10:28:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMcTb-0006KE-EM; Fri, 12 Oct 2012 10:28:19 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TMcTa-0006K9-52
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 10:28:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1350037691!5117872!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQzMTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12415 invoked from network); 12 Oct 2012 10:28:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 10:28:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="15123624"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 10:28:09 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 12 Oct 2012 11:28:09 +0100
Message-ID: <1350037688.14806.93.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 12 Oct 2012 11:28:08 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] Dom0 physical networking/swiotlb/something issue in
	3.7-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Konrad,

The following patch causes fairly large packet loss when transmitting
from dom0 to the physical network, at least with my tg3 hardware, but I
assume it can impact anything which uses this interface.

I suspect that the issue is that the compound pages allocated in this
way are not backed by contiguous mfns and so things fall apart when the
driver tries to do DMA.

However I don't understand why the swiotlb is not fixing this up
successfully? The tg3 driver seems to use pci_map_single on this data.
Any thoughts? Perhaps the swiotlb (either generically or in the Xen
backend) doesn't correctly handle compound pages?

Ideally we would also fix this at the point of allocation to avoid the
bouncing -- I suppose that would involve using the DMA API in
netdev_alloc_frag?

We have a, sort of, similar situation in the block layer which is solved
via BIOVEC_PHYS_MERGEABLE. Sadly I don't think anything similar can
easily be retrofitted to the net drivers without changing every single
one.

Ian.

commit 69b08f62e17439ee3d436faf0b9a7ca6fffb78db
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed Sep 26 06:46:57 2012 +0000

    net: use bigger pages in __netdev_alloc_frag
    
    We currently use percpu order-0 pages in __netdev_alloc_frag
    to deliver fragments used by __netdev_alloc_skb()
    
    Depending on NIC driver and arch being 32 or 64 bit, it allows a page to
    be split in several fragments (between 1 and 8), assuming PAGE_SIZE=4096
    
    Switching to bigger pages (32768 bytes for PAGE_SIZE=4096 case) allows :
    
    - Better filling of space (the ending hole overhead is less an issue)
    
    - Less calls to page allocator or accesses to page->_count
    
    - Could allow struct skb_shared_info futures changes without major
      performance impact.
    
    This patch implements a transparent fallback to smaller
    pages in case of memory pressure.
    
    It also uses a standard "struct page_frag" instead of a custom one.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Alexander Duyck <alexander.h.duyck@intel.com>
    Cc: Benjamin LaHaise <bcrl@kvack.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 11:24:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 11:24:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMdLg-0006bR-0u; Fri, 12 Oct 2012 11:24:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TMdLe-0006bM-VS
	for xen-devel@lists.xensource.com; Fri, 12 Oct 2012 11:24:11 +0000
Received: from [85.158.143.35:12557] by server-3.bemta-4.messagelabs.com id
	4A/6A-10075-ADDF7705; Fri, 12 Oct 2012 11:24:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1350041049!13716454!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQzMTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16134 invoked from network); 12 Oct 2012 11:24:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 11:24:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="15125076"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 11:24:09 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 12 Oct 2012 12:24:09 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1TMdLd-0003vr-4I; Fri, 12 Oct 2012 11:24:09 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TMdLc-0007Pw-V3;
	Fri, 12 Oct 2012 12:24:08 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20599.64984.830259.493886@mariner.uk.xensource.com>
Date: Fri, 12 Oct 2012 12:24:08 +0100
To: Dario Faggioli <raistlin.df@gmail.com>
In-Reply-To: <1349882083.3610.219.camel@Abyss>
References: <osstest-13944-mainreport@xen.org>
	<20596.26200.30125.482942@mariner.uk.xensource.com>
	<1349882083.3610.219.camel@Abyss>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 13944: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dario Faggioli writes ("Re: [Xen-devel] [xen-unstable test] 13944: regressions - FAIL"):
> Mmm, gall-mite is the box on which _all_ the sched=sedf test were
> running for quite a bit of flights, and consistently failing at the
> xen-boot stage. I pointed out the situation already here:
> 
> http://www.gossamer-threads.com/lists/xen/devel/258909?do=post_view_threaded
> 
> Now that the very same test has moved to some other host it seems to be
> working again:
> 
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13943/test-amd64-amd64-xl-sedf/info.html
> 
> That could be something very silly to think (in which case sorry), but
> might this all be some hardware issue on that machine?

I guess we should see whether it fails on itch-mite, which is
supposedly identical to gall-mite.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 11:24:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 11:24:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMdLg-0006bR-0u; Fri, 12 Oct 2012 11:24:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TMdLe-0006bM-VS
	for xen-devel@lists.xensource.com; Fri, 12 Oct 2012 11:24:11 +0000
Received: from [85.158.143.35:12557] by server-3.bemta-4.messagelabs.com id
	4A/6A-10075-ADDF7705; Fri, 12 Oct 2012 11:24:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1350041049!13716454!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQzMTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16134 invoked from network); 12 Oct 2012 11:24:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 11:24:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="15125076"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 11:24:09 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 12 Oct 2012 12:24:09 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1TMdLd-0003vr-4I; Fri, 12 Oct 2012 11:24:09 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TMdLc-0007Pw-V3;
	Fri, 12 Oct 2012 12:24:08 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20599.64984.830259.493886@mariner.uk.xensource.com>
Date: Fri, 12 Oct 2012 12:24:08 +0100
To: Dario Faggioli <raistlin.df@gmail.com>
In-Reply-To: <1349882083.3610.219.camel@Abyss>
References: <osstest-13944-mainreport@xen.org>
	<20596.26200.30125.482942@mariner.uk.xensource.com>
	<1349882083.3610.219.camel@Abyss>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 13944: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dario Faggioli writes ("Re: [Xen-devel] [xen-unstable test] 13944: regressions - FAIL"):
> Mmm, gall-mite is the box on which _all_ the sched=sedf test were
> running for quite a bit of flights, and consistently failing at the
> xen-boot stage. I pointed out the situation already here:
> 
> http://www.gossamer-threads.com/lists/xen/devel/258909?do=post_view_threaded
> 
> Now that the very same test has moved to some other host it seems to be
> working again:
> 
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13943/test-amd64-amd64-xl-sedf/info.html
> 
> That could be something very silly to think (in which case sorry), but
> might this all be some hardware issue on that machine?

I guess we should see whether it fails on itch-mite, which is
supposedly identical to gall-mite.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 12:00:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 12:00:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMduM-0006sF-6A; Fri, 12 Oct 2012 12:00:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TMduJ-0006qG-V7
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 12:00:00 +0000
Received: from [85.158.143.99:61320] by server-3.bemta-4.messagelabs.com id
	33/E9-10075-F3608705; Fri, 12 Oct 2012 11:59:59 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1350043197!27617687!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgwNzQ3OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1741 invoked from network); 12 Oct 2012 11:59:58 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Oct 2012 11:59:58 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9CBxrqn015813
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 12 Oct 2012 11:59:54 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9CBxqJh011892
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 12 Oct 2012 11:59:53 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9CBxqDP002198; Fri, 12 Oct 2012 06:59:52 -0500
Received: from localhost.localdomain (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Oct 2012 04:59:52 -0700
Date: Fri, 12 Oct 2012 07:59:50 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20121012115949.GB4028@localhost.localdomain>
References: <1350037688.14806.93.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1350037688.14806.93.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Dom0 physical networking/swiotlb/something issue in
	3.7-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 12, 2012 at 11:28:08AM +0100, Ian Campbell wrote:
> Hi Konrad,
> 
> The following patch causes fairly large packet loss when transmitting
> from dom0 to the physical network, at least with my tg3 hardware, but I
> assume it can impact anything which uses this interface.

Ah, that would explain why one of my machines suddenly started
developing checksum errors (and had a tg3 card). I hadn't gotten
deep into it.
> 
> I suspect that the issue is that the compound pages allocated in this
> way are not backed by contiguous mfns and so things fall apart when the
> driver tries to do DMA.

So this should also be easily reproduced on barmetal with 'iommu=soft' then.
> 
> However I don't understand why the swiotlb is not fixing this up
> successfully? The tg3 driver seems to use pci_map_single on this data.
> Any thoughts? Perhaps the swiotlb (either generically or in the Xen
> backend) doesn't correctly handle compound pages?

The assumption is that it is just a page. I am surprsed that the other
IOMMUs aren't hitting this as well - ah, that is b/c they do handle
a virtual address of more than one PAGE_SIZE..
> 
> Ideally we would also fix this at the point of allocation to avoid the
> bouncing -- I suppose that would involve using the DMA API in
> netdev_alloc_frag?

Using pci_alloc_coherent would do it.. but
> 
> We have a, sort of, similar situation in the block layer which is solved
> via BIOVEC_PHYS_MERGEABLE. Sadly I don't think anything similar can
> easily be retrofitted to the net drivers without changing every single
> one.

.. I think the right way would be to fix the SWIOTLB. And since I am now
officially the maintainer of said subsystem you have come to the right
person!

What is the easiest way of reproducing this? Just doing large amount
of netperf/netserver traffic both ways?
> 
> Ian.
> 
> commit 69b08f62e17439ee3d436faf0b9a7ca6fffb78db
> Author: Eric Dumazet <edumazet@google.com>
> Date:   Wed Sep 26 06:46:57 2012 +0000
> 
>     net: use bigger pages in __netdev_alloc_frag
>     
>     We currently use percpu order-0 pages in __netdev_alloc_frag
>     to deliver fragments used by __netdev_alloc_skb()
>     
>     Depending on NIC driver and arch being 32 or 64 bit, it allows a page to
>     be split in several fragments (between 1 and 8), assuming PAGE_SIZE=4096
>     
>     Switching to bigger pages (32768 bytes for PAGE_SIZE=4096 case) allows :
>     
>     - Better filling of space (the ending hole overhead is less an issue)
>     
>     - Less calls to page allocator or accesses to page->_count
>     
>     - Could allow struct skb_shared_info futures changes without major
>       performance impact.
>     
>     This patch implements a transparent fallback to smaller
>     pages in case of memory pressure.
>     
>     It also uses a standard "struct page_frag" instead of a custom one.
>     
>     Signed-off-by: Eric Dumazet <edumazet@google.com>
>     Cc: Alexander Duyck <alexander.h.duyck@intel.com>
>     Cc: Benjamin LaHaise <bcrl@kvack.org>
>     Signed-off-by: David S. Miller <davem@davemloft.net>
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 12:00:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 12:00:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMduM-0006sF-6A; Fri, 12 Oct 2012 12:00:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TMduJ-0006qG-V7
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 12:00:00 +0000
Received: from [85.158.143.99:61320] by server-3.bemta-4.messagelabs.com id
	33/E9-10075-F3608705; Fri, 12 Oct 2012 11:59:59 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1350043197!27617687!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgwNzQ3OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1741 invoked from network); 12 Oct 2012 11:59:58 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Oct 2012 11:59:58 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9CBxrqn015813
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 12 Oct 2012 11:59:54 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9CBxqJh011892
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 12 Oct 2012 11:59:53 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9CBxqDP002198; Fri, 12 Oct 2012 06:59:52 -0500
Received: from localhost.localdomain (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Oct 2012 04:59:52 -0700
Date: Fri, 12 Oct 2012 07:59:50 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20121012115949.GB4028@localhost.localdomain>
References: <1350037688.14806.93.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1350037688.14806.93.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Dom0 physical networking/swiotlb/something issue in
	3.7-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 12, 2012 at 11:28:08AM +0100, Ian Campbell wrote:
> Hi Konrad,
> 
> The following patch causes fairly large packet loss when transmitting
> from dom0 to the physical network, at least with my tg3 hardware, but I
> assume it can impact anything which uses this interface.

Ah, that would explain why one of my machines suddenly started
developing checksum errors (and had a tg3 card). I hadn't gotten
deep into it.
> 
> I suspect that the issue is that the compound pages allocated in this
> way are not backed by contiguous mfns and so things fall apart when the
> driver tries to do DMA.

So this should also be easily reproduced on barmetal with 'iommu=soft' then.
> 
> However I don't understand why the swiotlb is not fixing this up
> successfully? The tg3 driver seems to use pci_map_single on this data.
> Any thoughts? Perhaps the swiotlb (either generically or in the Xen
> backend) doesn't correctly handle compound pages?

The assumption is that it is just a page. I am surprsed that the other
IOMMUs aren't hitting this as well - ah, that is b/c they do handle
a virtual address of more than one PAGE_SIZE..
> 
> Ideally we would also fix this at the point of allocation to avoid the
> bouncing -- I suppose that would involve using the DMA API in
> netdev_alloc_frag?

Using pci_alloc_coherent would do it.. but
> 
> We have a, sort of, similar situation in the block layer which is solved
> via BIOVEC_PHYS_MERGEABLE. Sadly I don't think anything similar can
> easily be retrofitted to the net drivers without changing every single
> one.

.. I think the right way would be to fix the SWIOTLB. And since I am now
officially the maintainer of said subsystem you have come to the right
person!

What is the easiest way of reproducing this? Just doing large amount
of netperf/netserver traffic both ways?
> 
> Ian.
> 
> commit 69b08f62e17439ee3d436faf0b9a7ca6fffb78db
> Author: Eric Dumazet <edumazet@google.com>
> Date:   Wed Sep 26 06:46:57 2012 +0000
> 
>     net: use bigger pages in __netdev_alloc_frag
>     
>     We currently use percpu order-0 pages in __netdev_alloc_frag
>     to deliver fragments used by __netdev_alloc_skb()
>     
>     Depending on NIC driver and arch being 32 or 64 bit, it allows a page to
>     be split in several fragments (between 1 and 8), assuming PAGE_SIZE=4096
>     
>     Switching to bigger pages (32768 bytes for PAGE_SIZE=4096 case) allows :
>     
>     - Better filling of space (the ending hole overhead is less an issue)
>     
>     - Less calls to page allocator or accesses to page->_count
>     
>     - Could allow struct skb_shared_info futures changes without major
>       performance impact.
>     
>     This patch implements a transparent fallback to smaller
>     pages in case of memory pressure.
>     
>     It also uses a standard "struct page_frag" instead of a custom one.
>     
>     Signed-off-by: Eric Dumazet <edumazet@google.com>
>     Cc: Alexander Duyck <alexander.h.duyck@intel.com>
>     Cc: Benjamin LaHaise <bcrl@kvack.org>
>     Signed-off-by: David S. Miller <davem@davemloft.net>
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 12:09:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 12:09:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMe3Z-0007AR-8t; Fri, 12 Oct 2012 12:09:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TMe3X-0007AM-OS
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 12:09:31 +0000
Received: from [85.158.143.99:46696] by server-2.bemta-4.messagelabs.com id
	92/C8-25171-A7808705; Fri, 12 Oct 2012 12:09:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1350043770!33540460!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQzMTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9613 invoked from network); 12 Oct 2012 12:09:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 12:09:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="15126184"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 12:09:30 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 12 Oct 2012 13:09:30 +0100
Message-ID: <1350043768.14806.96.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 12 Oct 2012 13:09:28 +0100
In-Reply-To: <20121012115949.GB4028@localhost.localdomain>
References: <1350037688.14806.93.camel@zakaz.uk.xensource.com>
	<20121012115949.GB4028@localhost.localdomain>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Dom0 physical networking/swiotlb/something issue in
	3.7-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-12 at 12:59 +0100, Konrad Rzeszutek Wilk wrote:
> > I suspect that the issue is that the compound pages allocated in this
> > way are not backed by contiguous mfns and so things fall apart when the
> > driver tries to do DMA.
> 
> So this should also be easily reproduced on barmetal with 'iommu=soft' then.

Does that cause the frames backing the page to become non-contiguous in
"machine" memory?

> > However I don't understand why the swiotlb is not fixing this up
> > successfully? The tg3 driver seems to use pci_map_single on this data.
> > Any thoughts? Perhaps the swiotlb (either generically or in the Xen
> > backend) doesn't correctly handle compound pages?
> 
> The assumption is that it is just a page. I am surprsed that the other
> IOMMUs aren't hitting this as well - ah, that is b/c they do handle
> a virtual address of more than one PAGE_SIZE..
> > 
> > Ideally we would also fix this at the point of allocation to avoid the
> > bouncing -- I suppose that would involve using the DMA API in
> > netdev_alloc_frag?
> 
> Using pci_alloc_coherent would do it.. but
> > 
> > We have a, sort of, similar situation in the block layer which is solved
> > via BIOVEC_PHYS_MERGEABLE. Sadly I don't think anything similar can
> > easily be retrofitted to the net drivers without changing every single
> > one.
> 
> .. I think the right way would be to fix the SWIOTLB. And since I am now
> officially the maintainer of said subsystem you have come to the right
> person!
> 
> What is the easiest way of reproducing this? Just doing large amount
> of netperf/netserver traffic both ways?

I'm seeing ~75% loss from ping plus an scp from the dom0 to another host
was measuring hundreds of kb/s instead of a few mb/s.

Fixing this only at the swiotlb layer is going to cause lots of bouncing
though?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 12:09:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 12:09:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMe3Z-0007AR-8t; Fri, 12 Oct 2012 12:09:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TMe3X-0007AM-OS
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 12:09:31 +0000
Received: from [85.158.143.99:46696] by server-2.bemta-4.messagelabs.com id
	92/C8-25171-A7808705; Fri, 12 Oct 2012 12:09:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1350043770!33540460!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQzMTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9613 invoked from network); 12 Oct 2012 12:09:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 12:09:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="15126184"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 12:09:30 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 12 Oct 2012 13:09:30 +0100
Message-ID: <1350043768.14806.96.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 12 Oct 2012 13:09:28 +0100
In-Reply-To: <20121012115949.GB4028@localhost.localdomain>
References: <1350037688.14806.93.camel@zakaz.uk.xensource.com>
	<20121012115949.GB4028@localhost.localdomain>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Dom0 physical networking/swiotlb/something issue in
	3.7-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-12 at 12:59 +0100, Konrad Rzeszutek Wilk wrote:
> > I suspect that the issue is that the compound pages allocated in this
> > way are not backed by contiguous mfns and so things fall apart when the
> > driver tries to do DMA.
> 
> So this should also be easily reproduced on barmetal with 'iommu=soft' then.

Does that cause the frames backing the page to become non-contiguous in
"machine" memory?

> > However I don't understand why the swiotlb is not fixing this up
> > successfully? The tg3 driver seems to use pci_map_single on this data.
> > Any thoughts? Perhaps the swiotlb (either generically or in the Xen
> > backend) doesn't correctly handle compound pages?
> 
> The assumption is that it is just a page. I am surprsed that the other
> IOMMUs aren't hitting this as well - ah, that is b/c they do handle
> a virtual address of more than one PAGE_SIZE..
> > 
> > Ideally we would also fix this at the point of allocation to avoid the
> > bouncing -- I suppose that would involve using the DMA API in
> > netdev_alloc_frag?
> 
> Using pci_alloc_coherent would do it.. but
> > 
> > We have a, sort of, similar situation in the block layer which is solved
> > via BIOVEC_PHYS_MERGEABLE. Sadly I don't think anything similar can
> > easily be retrofitted to the net drivers without changing every single
> > one.
> 
> .. I think the right way would be to fix the SWIOTLB. And since I am now
> officially the maintainer of said subsystem you have come to the right
> person!
> 
> What is the easiest way of reproducing this? Just doing large amount
> of netperf/netserver traffic both ways?

I'm seeing ~75% loss from ping plus an scp from the dom0 to another host
was measuring hundreds of kb/s instead of a few mb/s.

Fixing this only at the swiotlb layer is going to cause lots of bouncing
though?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 12:11:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 12:11:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMe50-0007En-OK; Fri, 12 Oct 2012 12:11:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TMe4y-0007Eh-Vc
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 12:11:01 +0000
Received: from [85.158.143.35:42400] by server-1.bemta-4.messagelabs.com id
	8D/93-19551-4D808705; Fri, 12 Oct 2012 12:11:00 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1350043857!5023095!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgwNzQ3OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13187 invoked from network); 12 Oct 2012 12:10:59 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Oct 2012 12:10:59 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9CCArjI026553
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 12 Oct 2012 12:10:54 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9CCAqvg001623
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 12 Oct 2012 12:10:53 GMT
Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9CCAqgW023292; Fri, 12 Oct 2012 07:10:52 -0500
Received: from localhost.localdomain (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Oct 2012 05:10:52 -0700
Date: Fri, 12 Oct 2012 08:10:50 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20121012121049.GB4155@localhost.localdomain>
References: <1350037688.14806.93.camel@zakaz.uk.xensource.com>
	<20121012115949.GB4028@localhost.localdomain>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20121012115949.GB4028@localhost.localdomain>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Dom0 physical networking/swiotlb/something issue in
	3.7-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 12, 2012 at 07:59:49AM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, Oct 12, 2012 at 11:28:08AM +0100, Ian Campbell wrote:
> > Hi Konrad,
> > 
> > The following patch causes fairly large packet loss when transmitting
> > from dom0 to the physical network, at least with my tg3 hardware, but I
> > assume it can impact anything which uses this interface.
> 
> Ah, that would explain why one of my machines suddenly started
> developing checksum errors (and had a tg3 card). I hadn't gotten
> deep into it.
> > 
> > I suspect that the issue is that the compound pages allocated in this
> > way are not backed by contiguous mfns and so things fall apart when the
> > driver tries to do DMA.
> 
> So this should also be easily reproduced on barmetal with 'iommu=soft' then.
> > 
> > However I don't understand why the swiotlb is not fixing this up
> > successfully? The tg3 driver seems to use pci_map_single on this data.
> > Any thoughts? Perhaps the swiotlb (either generically or in the Xen
> > backend) doesn't correctly handle compound pages?
> 
> The assumption is that it is just a page. I am surprsed that the other
> IOMMUs aren't hitting this as well - ah, that is b/c they do handle
> a virtual address of more than one PAGE_SIZE..

So.. the GART one (AMD poor man IOTLB - was used for AGP card
translation, but can still be used as an IOMMU - and is still present on
some AMD machines), looks to suffer the same problem.

But perhaps not - can you explain to me if a compound page
is virtually contingous? One of the things the GART does for
pci_map_single is call page_to_phys(p), feeds the CPU physical address
(and size) into the GART engine to setup the mapping.

If compound pages are virtually (and physically on barmetal) contingous
- this ought to work. But if they are not, then this should also break on
AMD machines with tg3 and a AMD GART enabled.

(and I should be able to find such machine in my lab).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 12:11:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 12:11:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMe50-0007En-OK; Fri, 12 Oct 2012 12:11:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TMe4y-0007Eh-Vc
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 12:11:01 +0000
Received: from [85.158.143.35:42400] by server-1.bemta-4.messagelabs.com id
	8D/93-19551-4D808705; Fri, 12 Oct 2012 12:11:00 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1350043857!5023095!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgwNzQ3OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13187 invoked from network); 12 Oct 2012 12:10:59 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Oct 2012 12:10:59 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9CCArjI026553
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 12 Oct 2012 12:10:54 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9CCAqvg001623
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 12 Oct 2012 12:10:53 GMT
Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9CCAqgW023292; Fri, 12 Oct 2012 07:10:52 -0500
Received: from localhost.localdomain (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Oct 2012 05:10:52 -0700
Date: Fri, 12 Oct 2012 08:10:50 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20121012121049.GB4155@localhost.localdomain>
References: <1350037688.14806.93.camel@zakaz.uk.xensource.com>
	<20121012115949.GB4028@localhost.localdomain>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20121012115949.GB4028@localhost.localdomain>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Dom0 physical networking/swiotlb/something issue in
	3.7-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 12, 2012 at 07:59:49AM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, Oct 12, 2012 at 11:28:08AM +0100, Ian Campbell wrote:
> > Hi Konrad,
> > 
> > The following patch causes fairly large packet loss when transmitting
> > from dom0 to the physical network, at least with my tg3 hardware, but I
> > assume it can impact anything which uses this interface.
> 
> Ah, that would explain why one of my machines suddenly started
> developing checksum errors (and had a tg3 card). I hadn't gotten
> deep into it.
> > 
> > I suspect that the issue is that the compound pages allocated in this
> > way are not backed by contiguous mfns and so things fall apart when the
> > driver tries to do DMA.
> 
> So this should also be easily reproduced on barmetal with 'iommu=soft' then.
> > 
> > However I don't understand why the swiotlb is not fixing this up
> > successfully? The tg3 driver seems to use pci_map_single on this data.
> > Any thoughts? Perhaps the swiotlb (either generically or in the Xen
> > backend) doesn't correctly handle compound pages?
> 
> The assumption is that it is just a page. I am surprsed that the other
> IOMMUs aren't hitting this as well - ah, that is b/c they do handle
> a virtual address of more than one PAGE_SIZE..

So.. the GART one (AMD poor man IOTLB - was used for AGP card
translation, but can still be used as an IOMMU - and is still present on
some AMD machines), looks to suffer the same problem.

But perhaps not - can you explain to me if a compound page
is virtually contingous? One of the things the GART does for
pci_map_single is call page_to_phys(p), feeds the CPU physical address
(and size) into the GART engine to setup the mapping.

If compound pages are virtually (and physically on barmetal) contingous
- this ought to work. But if they are not, then this should also break on
AMD machines with tg3 and a AMD GART enabled.

(and I should be able to find such machine in my lab).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 12:18:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 12:18:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMeC4-0007Rq-Kj; Fri, 12 Oct 2012 12:18:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TMeC3-0007Rl-G9
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 12:18:19 +0000
Received: from [85.158.139.211:43053] by server-3.bemta-5.messagelabs.com id
	67/E2-09712-A8A08705; Fri, 12 Oct 2012 12:18:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1350044298!22068280!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQzMTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20683 invoked from network); 12 Oct 2012 12:18:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 12:18:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="15126418"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 12:18:18 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 12 Oct 2012 13:18:18 +0100
Message-ID: <1350044296.14806.100.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 12 Oct 2012 13:18:16 +0100
In-Reply-To: <20121012121049.GB4155@localhost.localdomain>
References: <1350037688.14806.93.camel@zakaz.uk.xensource.com>
	<20121012115949.GB4028@localhost.localdomain>
	<20121012121049.GB4155@localhost.localdomain>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Dom0 physical networking/swiotlb/something issue in
	3.7-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-12 at 13:10 +0100, Konrad Rzeszutek Wilk wrote:
> On Fri, Oct 12, 2012 at 07:59:49AM -0400, Konrad Rzeszutek Wilk wrote:
> > On Fri, Oct 12, 2012 at 11:28:08AM +0100, Ian Campbell wrote:
> > > Hi Konrad,
> > > 
> > > The following patch causes fairly large packet loss when transmitting
> > > from dom0 to the physical network, at least with my tg3 hardware, but I
> > > assume it can impact anything which uses this interface.
> > 
> > Ah, that would explain why one of my machines suddenly started
> > developing checksum errors (and had a tg3 card). I hadn't gotten
> > deep into it.
> > > 
> > > I suspect that the issue is that the compound pages allocated in this
> > > way are not backed by contiguous mfns and so things fall apart when the
> > > driver tries to do DMA.
> > 
> > So this should also be easily reproduced on barmetal with 'iommu=soft' then.
> > > 
> > > However I don't understand why the swiotlb is not fixing this up
> > > successfully? The tg3 driver seems to use pci_map_single on this data.
> > > Any thoughts? Perhaps the swiotlb (either generically or in the Xen
> > > backend) doesn't correctly handle compound pages?
> > 
> > The assumption is that it is just a page. I am surprsed that the other
> > IOMMUs aren't hitting this as well - ah, that is b/c they do handle
> > a virtual address of more than one PAGE_SIZE..
> 
> So.. the GART one (AMD poor man IOTLB - was used for AGP card
> translation, but can still be used as an IOMMU - and is still present on
> some AMD machines), looks to suffer the same problem.
> 
> But perhaps not - can you explain to me if a compound page
> is virtually contingous? One of the things the GART does for
> pci_map_single is call page_to_phys(p), feeds the CPU physical address
> (and size) into the GART engine to setup the mapping.
> 
> If compound pages are virtually (and physically on barmetal) contingous
> - this ought to work. But if they are not, then this should also break on
> AMD machines with tg3 and a AMD GART enabled.

AFAIK compound pages are always physically contiguous. i.e. given a
"struct page *page" which is the head of a compound page you can do
"page++" to walk through its constituent frames.

I'm not sure about virtually contiguous. Obviously if they are in lowmem
then the 1-1 map combined with the fact that they are physically
contiguous makes them virtually contiguous too. I'm not sure what
happens if they are highmem -- since kmap (or whatever) would need to do
some extra work in this case. I've not looked but I don't recall
noticing this in the past...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 12:18:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 12:18:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMeC4-0007Rq-Kj; Fri, 12 Oct 2012 12:18:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TMeC3-0007Rl-G9
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 12:18:19 +0000
Received: from [85.158.139.211:43053] by server-3.bemta-5.messagelabs.com id
	67/E2-09712-A8A08705; Fri, 12 Oct 2012 12:18:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1350044298!22068280!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQzMTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20683 invoked from network); 12 Oct 2012 12:18:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 12:18:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="15126418"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 12:18:18 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 12 Oct 2012 13:18:18 +0100
Message-ID: <1350044296.14806.100.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 12 Oct 2012 13:18:16 +0100
In-Reply-To: <20121012121049.GB4155@localhost.localdomain>
References: <1350037688.14806.93.camel@zakaz.uk.xensource.com>
	<20121012115949.GB4028@localhost.localdomain>
	<20121012121049.GB4155@localhost.localdomain>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Dom0 physical networking/swiotlb/something issue in
	3.7-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-12 at 13:10 +0100, Konrad Rzeszutek Wilk wrote:
> On Fri, Oct 12, 2012 at 07:59:49AM -0400, Konrad Rzeszutek Wilk wrote:
> > On Fri, Oct 12, 2012 at 11:28:08AM +0100, Ian Campbell wrote:
> > > Hi Konrad,
> > > 
> > > The following patch causes fairly large packet loss when transmitting
> > > from dom0 to the physical network, at least with my tg3 hardware, but I
> > > assume it can impact anything which uses this interface.
> > 
> > Ah, that would explain why one of my machines suddenly started
> > developing checksum errors (and had a tg3 card). I hadn't gotten
> > deep into it.
> > > 
> > > I suspect that the issue is that the compound pages allocated in this
> > > way are not backed by contiguous mfns and so things fall apart when the
> > > driver tries to do DMA.
> > 
> > So this should also be easily reproduced on barmetal with 'iommu=soft' then.
> > > 
> > > However I don't understand why the swiotlb is not fixing this up
> > > successfully? The tg3 driver seems to use pci_map_single on this data.
> > > Any thoughts? Perhaps the swiotlb (either generically or in the Xen
> > > backend) doesn't correctly handle compound pages?
> > 
> > The assumption is that it is just a page. I am surprsed that the other
> > IOMMUs aren't hitting this as well - ah, that is b/c they do handle
> > a virtual address of more than one PAGE_SIZE..
> 
> So.. the GART one (AMD poor man IOTLB - was used for AGP card
> translation, but can still be used as an IOMMU - and is still present on
> some AMD machines), looks to suffer the same problem.
> 
> But perhaps not - can you explain to me if a compound page
> is virtually contingous? One of the things the GART does for
> pci_map_single is call page_to_phys(p), feeds the CPU physical address
> (and size) into the GART engine to setup the mapping.
> 
> If compound pages are virtually (and physically on barmetal) contingous
> - this ought to work. But if they are not, then this should also break on
> AMD machines with tg3 and a AMD GART enabled.

AFAIK compound pages are always physically contiguous. i.e. given a
"struct page *page" which is the head of a compound page you can do
"page++" to walk through its constituent frames.

I'm not sure about virtually contiguous. Obviously if they are in lowmem
then the 1-1 map combined with the fact that they are physically
contiguous makes them virtually contiguous too. I'm not sure what
happens if they are highmem -- since kmap (or whatever) would need to do
some extra work in this case. I've not looked but I don't recall
noticing this in the past...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 12:24:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 12:24:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMeHy-0007ar-EI; Fri, 12 Oct 2012 12:24:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tupeng212@gmail.com>) id 1TMeHw-0007ak-WB
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 12:24:25 +0000
Received: from [85.158.139.211:44059] by server-12.bemta-5.messagelabs.com id
	2D/0A-19095-8FB08705; Fri, 12 Oct 2012 12:24:24 +0000
X-Env-Sender: tupeng212@gmail.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1350044661!22013589!1
X-Originating-IP: [209.85.210.45]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_50_60,HTML_MESSAGE,
	MIME_BOUND_NEXTPART,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13269 invoked from network); 12 Oct 2012 12:24:22 -0000
Received: from mail-da0-f45.google.com (HELO mail-da0-f45.google.com)
	(209.85.210.45)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 12:24:22 -0000
Received: by mail-da0-f45.google.com with SMTP id n15so1321420dad.32
	for <xen-devel@lists.xen.org>; Fri, 12 Oct 2012 05:24:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=date:from:to:reply-to:subject:references:x-priority:x-guid
	:x-has-attach:x-mailer:mime-version:message-id:content-type;
	bh=Qq+Ci0Vvm4Y81pv+tje8HL7hsPNDI5nqsG6yoQPL9o4=;
	b=BdbkgPWXxVif0Owt9KbyRQuuCugK31dObe+9ACFwIsdIK9A+5fQHaJYpQLKIpZ2cxg
	iKHVzsfkNZ5y1l+TBMWk4WUE3zH4ggrYe1AYdjGZOtVk9Vusj7LPCnxoJydRTjp1Xq//
	7t2Mww+LxkENv3pDcIzha7qkWjR5I2T0BgwkiqC7EkDc2eseszGNLabeB4IF/jRS2xsu
	SQpEhy7m6WrByuUf0xK9iHtr3NG88CDEVFvONAPQzNXFyNpBCDKZlNhhWqDYexYjEiTN
	4VOXPSp5Pr9FFpRBZ2ldViDS6mWkzM5OYK7Kak1hAPuebXuo28WGAtzlBKV4A4BITWfI
	FHLA==
Received: by 10.66.88.40 with SMTP id bd8mr10930030pab.36.1350044660752;
	Fri, 12 Oct 2012 05:24:20 -0700 (PDT)
Received: from root ([115.199.242.10])
	by mx.google.com with ESMTPS id qv4sm3033816pbc.38.2012.10.12.05.24.16
	(version=SSLv3 cipher=OTHER); Fri, 12 Oct 2012 05:24:20 -0700 (PDT)
Date: Fri, 12 Oct 2012 20:24:16 +0800
From: tupeng212 <tupeng212@gmail.com>
To: "Keir Fraser" <keir@xen.org>, 
	xen-devel <xen-devel@lists.xen.org>
References: <CC9CA725.4EB45%keir@xen.org>
X-Priority: 3
X-GUID: 8462B3AE-8093-4110-A83E-FAA54E41E0D4
X-Has-Attach: no
X-Mailer: Foxmail 7.0.1.87[cn]
Mime-Version: 1.0
Message-ID: <201210122024123436447@gmail.com>
Subject: Re: [Xen-devel] alloc_heap_pages is low efficient with more CPUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: tupeng212 <tupeng212@gmail.com>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============9116212788730668343=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.

--===============9116212788730668343==
Content-Type: multipart/alternative;
	boundary="----=_001_NextPart540553674733_=----"

This is a multi-part message in MIME format.

------=_001_NextPart540553674733_=----
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64

V2l0aCAxNiBDUFVzIHlvdSBmaW5kIGRvbWFpbiBzdGFydHVwIHRha2VzIDNzIGFsd2F5cy4gDQo6
Tm8NCldpdGggMTZDUFVzLCBmaXJzdCAwLjNzLCBzZWNvbmQgM3MNCldpdGggNjRDUFVzLCBmaXJz
dCAzcywgc2Vjb25kIDMwcy4NCg0KV2l0aCA2NCBDUFVzIHlvdSBmaW5kIGl0IHRha2VzIDNzIGZp
cnN0IHRpbWUsIHRoZW4gMzBzIGluIGZ1dHVyZT8gDQo6IFllcw0KDQpBbmQgdGhpcyBpcyBkdWUg
dG8gY29zdCBvZiB0bGJmbHVzaF9maWx0ZXIoKSAobm90IGFjdHVhbCBUTEIgZmx1c2hlcywgYmVj
YXVzZSB5b3UgYWx3YXlzIGVuZCB1cCB3aXRoIG1hc2s9MCk/IA0KOiBZZXMsIGl0IGNvc3RzIG11
Y2ggaW4gdGxiZmx1c2hfZmlsdGVyKCkgaW4gdGhlIGp1ZGdlbWVudC4NClRMQiBmbHVzaGluZyBp
cyByZWFsbHkgdmVyeSBmYXN0LCBpdCBqdXN0IHNlbmRzIGEgSVBJIHRvIHJlbGF0ZWQgQ1BVLg0K
SW4gdGhlIHN0YXJ0aW5nIHByb2Nlc3MncyBhbGxvY2F0aW9uLCBpdCBhbHdheXMgZW5kcyB1cCB3
aXRoIG1hc2s9MCB3aGljaCBzZWVtcyBuZWVkbGVzcy4NCg0KSWYgdGxiZmx1c2hfZmlsdGVyKCkg
d2VyZSB0aGF0IGV4cGVuc2l2ZSBJ4oCZZCBleHBlY3QgdGhlIDE2LUNQVSBjYXNlIHRvIGhhdmUg
c2xvd2Rvd24gYWZ0ZXIgdGhlIGZpcnN0IGRvbWFpbiBzdGFydHVwLCB0b28uDQo6IFllcywgeW91
IGFyZSByaWdodCwgMTZDUFUgc2xvd3MgZG93biB0b28gYWZ0ZXIgaXRzIGZpcnN0IHN0YXJ0dXAu
DQoNClRoZSByZWFzb24gaXMgdmVyeSBjbGVhciwgSSBoYXZlIGRpc2N1c3NlZCBpdCB3aXRoIG90
aGVycywgdGxiZmx1c2hfZmlsdGVyKCkgaXMgbG93IGVmZmljaWVudCBpcyBubyBkb3VidCwgDQpC
dXQgSSBkb24ndCBrbm93IGhvdyB0byBpbXByb3ZlIGl0IC4NCg0KYW5kIEkgYWxzbyB1c2VkICB4
ZW4gb3Byb2ZpbGUgdG8gZmluZCB0aGUgZm9sbG93aW5nIHR3byBmdW5jdGlvbnMgYXJlIGNhbGxl
ZCBoaWdoIGZyZXF1ZW50bHk6DQphbGxvY19oZWFwX3BhZ2VzOiA0MCUNCl9fbmV4dF9jcHUgOiAy
MCUNCm90aGVyczogMC54JQ0KLi4uLi4NCmFsbG9jX2hlYXBfcGFnZXMgLT4gdGxiZmx1c2hfZmls
dGVyIC0+IGZvcl9lYWNoX2NwdV9tYXNrIG5leHRfY3B1ICAtPiBfX25leHRfY3B1IA0KaXQgc2Vl
bXMgdHJhdmVsaW5nIGFtb25nIENQVXMgaXMgZXhwZW5zaXZlLg==

------=_001_NextPart540553674733_=----
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

=EF=BB=BF<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Re: [Xen-devel] alloc_heap_pages is low efficient with =
more CPUs






With 16 CPUs you find domain startup ta=
kes 3s=20
always. 


:No


With 16CPUs, first 0.3s, second 3s


With 64CPUs, first 3s, second 30s.


 


With 64 CPUs you find it takes 3s first=
 time,=20
then 30s in future? 


: Yes


 


And this is due to cost of tlbflush_fil=
ter() (not=20
actual TLB flushes, because you always end up with mask=3D0)? 

: Yes, it costs much in tlbflush_filter=
() in the=20
judgement.


TLB flushing is really very fast, it ju=
st sends a=20
IPI to related CPU.


In the starting process's allocation, i=
t always=20
ends up with mask=3D0 which seems needless.


 


If tlbflush_filter() were that expensiv=
e I=E2=80=99d=20
expect the 16-CPU case to have slowdown after the first domain startup,=20
too.


: Yes, you are right, 16CPU slows down =
too after=20
its first startup.


 


The reason is very clear, I have discus=
sed it=20
with others, tlbflush_filter() is low efficient is no doubt, 


But I don't know how to improve it .


 


and I also used  xen opr=
ofile to=20
find the following two functions are called high frequently:


alloc_heap_pages: 40%


__next_cpu : 20%


others: 0.x%


.....


alloc_heap_pages -> tlbflush_filter -> for_each_cpu_mask=20
next_cpu  -> __next_cpu 


it seems traveling among CPUs is expensive.


 


------=_001_NextPart540553674733_=------



--===============9116212788730668343==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============9116212788730668343==--



From xen-devel-bounces@lists.xen.org Fri Oct 12 12:24:49 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 12:24:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMeHy-0007ar-EI; Fri, 12 Oct 2012 12:24:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMeHw-0007ak-WB
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 12:24:25 +0000
Received: from [85.158.139.211:44059] by server-12.bemta-5.messagelabs.com id
	2D/0A-19095-8FB08705; Fri, 12 Oct 2012 12:24:24 +0000
X-Env-Sender: tupeng212@gmail.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1350044661!22013589!1
X-Originating-IP: [209.85.210.45]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_50_60,HTML_MESSAGE,
	MIME_BOUND_NEXTPART,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13269 invoked from network); 12 Oct 2012 12:24:22 -0000
Received: from mail-da0-f45.google.com (HELO mail-da0-f45.google.com)
	(209.85.210.45)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 12:24:22 -0000
Received: by mail-da0-f45.google.com with SMTP id n15so1321420dad.32
	for ; Fri, 12 Oct 2012 05:24:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=date:from:to:reply-to:subject:references:x-priority:x-guid
	:x-has-attach:x-mailer:mime-version:message-id:content-type;
	bh=Qq+Ci0Vvm4Y81pv+tje8HL7hsPNDI5nqsG6yoQPL9o4=;
	b=BdbkgPWXxVif0Owt9KbyRQuuCugK31dObe+9ACFwIsdIK9A+5fQHaJYpQLKIpZ2cxg
	iKHVzsfkNZ5y1l+TBMWk4WUE3zH4ggrYe1AYdjGZOtVk9Vusj7LPCnxoJydRTjp1Xq//
	7t2Mww+LxkENv3pDcIzha7qkWjR5I2T0BgwkiqC7EkDc2eseszGNLabeB4IF/jRS2xsu
	SQpEhy7m6WrByuUf0xK9iHtr3NG88CDEVFvONAPQzNXFyNpBCDKZlNhhWqDYexYjEiTN
	4VOXPSp5Pr9FFpRBZ2ldViDS6mWkzM5OYK7Kak1hAPuebXuo28WGAtzlBKV4A4BITWfI
	FHLA==
Received: by 10.66.88.40 with SMTP id bd8mr10930030pab.36.1350044660752;
	Fri, 12 Oct 2012 05:24:20 -0700 (PDT)
Received: from root ([115.199.242.10])
	by mx.google.com with ESMTPS id qv4sm3033816pbc.38.2012.10.12.05.24.16
	(version=SSLv3 cipher=OTHER); Fri, 12 Oct 2012 05:24:20 -0700 (PDT)
Date: Fri, 12 Oct 2012 20:24:16 +0800
From: tupeng212 
To: "Keir Fraser" , 
	xen-devel 
References: 
X-Priority: 3
X-GUID: 8462B3AE-8093-4110-A83E-FAA54E41E0D4
X-Has-Attach: no
X-Mailer: Foxmail 7.0.1.87[cn]
Mime-Version: 1.0
Message-ID: <201210122024123436447@gmail.com>
Subject: Re: [Xen-devel] alloc_heap_pages is low efficient with more CPUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: tupeng212 
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============9116212788730668343=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.

--===============9116212788730668343==
Content-Type: multipart/alternative;
	boundary="----=_001_NextPart540553674733_=----"

This is a multi-part message in MIME format.

------=_001_NextPart540553674733_=----
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64

V2l0aCAxNiBDUFVzIHlvdSBmaW5kIGRvbWFpbiBzdGFydHVwIHRha2VzIDNzIGFsd2F5cy4gDQo6
Tm8NCldpdGggMTZDUFVzLCBmaXJzdCAwLjNzLCBzZWNvbmQgM3MNCldpdGggNjRDUFVzLCBmaXJz
dCAzcywgc2Vjb25kIDMwcy4NCg0KV2l0aCA2NCBDUFVzIHlvdSBmaW5kIGl0IHRha2VzIDNzIGZp
cnN0IHRpbWUsIHRoZW4gMzBzIGluIGZ1dHVyZT8gDQo6IFllcw0KDQpBbmQgdGhpcyBpcyBkdWUg
dG8gY29zdCBvZiB0bGJmbHVzaF9maWx0ZXIoKSAobm90IGFjdHVhbCBUTEIgZmx1c2hlcywgYmVj
YXVzZSB5b3UgYWx3YXlzIGVuZCB1cCB3aXRoIG1hc2s9MCk/IA0KOiBZZXMsIGl0IGNvc3RzIG11
Y2ggaW4gdGxiZmx1c2hfZmlsdGVyKCkgaW4gdGhlIGp1ZGdlbWVudC4NClRMQiBmbHVzaGluZyBp
cyByZWFsbHkgdmVyeSBmYXN0LCBpdCBqdXN0IHNlbmRzIGEgSVBJIHRvIHJlbGF0ZWQgQ1BVLg0K
SW4gdGhlIHN0YXJ0aW5nIHByb2Nlc3MncyBhbGxvY2F0aW9uLCBpdCBhbHdheXMgZW5kcyB1cCB3
aXRoIG1hc2s9MCB3aGljaCBzZWVtcyBuZWVkbGVzcy4NCg0KSWYgdGxiZmx1c2hfZmlsdGVyKCkg
d2VyZSB0aGF0IGV4cGVuc2l2ZSBJ4oCZZCBleHBlY3QgdGhlIDE2LUNQVSBjYXNlIHRvIGhhdmUg
c2xvd2Rvd24gYWZ0ZXIgdGhlIGZpcnN0IGRvbWFpbiBzdGFydHVwLCB0b28uDQo6IFllcywgeW91
IGFyZSByaWdodCwgMTZDUFUgc2xvd3MgZG93biB0b28gYWZ0ZXIgaXRzIGZpcnN0IHN0YXJ0dXAu
DQoNClRoZSByZWFzb24gaXMgdmVyeSBjbGVhciwgSSBoYXZlIGRpc2N1c3NlZCBpdCB3aXRoIG90
aGVycywgdGxiZmx1c2hfZmlsdGVyKCkgaXMgbG93IGVmZmljaWVudCBpcyBubyBkb3VidCwgDQpC
dXQgSSBkb24ndCBrbm93IGhvdyB0byBpbXByb3ZlIGl0IC4NCg0KYW5kIEkgYWxzbyB1c2VkICB4
ZW4gb3Byb2ZpbGUgdG8gZmluZCB0aGUgZm9sbG93aW5nIHR3byBmdW5jdGlvbnMgYXJlIGNhbGxl
ZCBoaWdoIGZyZXF1ZW50bHk6DQphbGxvY19oZWFwX3BhZ2VzOiA0MCUNCl9fbmV4dF9jcHUgOiAy
MCUNCm90aGVyczogMC54JQ0KLi4uLi4NCmFsbG9jX2hlYXBfcGFnZXMgLT4gdGxiZmx1c2hfZmls
dGVyIC0+IGZvcl9lYWNoX2NwdV9tYXNrIG5leHRfY3B1ICAtPiBfX25leHRfY3B1IA0KaXQgc2Vl
bXMgdHJhdmVsaW5nIGFtb25nIENQVXMgaXMgZXhwZW5zaXZlLg==

------=_001_NextPart540553674733_=----
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

=EF=BB=BF
Re: [Xen-devel] alloc_heap_pages is low efficient with =
more CPUs






With 16 CPUs you find domain startup ta=
kes 3s=20
always. 


:No


With 16CPUs, first 0.3s, second 3s


With 64CPUs, first 3s, second 30s.


 


With 64 CPUs you find it takes 3s first=
 time,=20
then 30s in future? 


: Yes


 


And this is due to cost of tlbflush_fil=
ter() (not=20
actual TLB flushes, because you always end up with mask=3D0)? 

: Yes, it costs much in tlbflush_filter=
() in the=20
judgement.


TLB flushing is really very fast, it ju=
st sends a=20
IPI to related CPU.


In the starting process's allocation, i=
t always=20
ends up with mask=3D0 which seems needless.


 


If tlbflush_filter() were that expensiv=
e I=E2=80=99d=20
expect the 16-CPU case to have slowdown after the first domain startup,=20
too.


: Yes, you are right, 16CPU slows down =
too after=20
its first startup.


 


The reason is very clear, I have discus=
sed it=20
with others, tlbflush_filter() is low efficient is no doubt, 


But I don't know how to improve it .


 


and I also used  xen opr=
ofile to=20
find the following two functions are called high frequently:


alloc_heap_pages: 40%


__next_cpu : 20%


others: 0.x%


.....


alloc_heap_pages -> tlbflush_filter -> for_each_cpu_mask=20
next_cpu  -> __next_cpu 


it seems traveling among CPUs is expensive.


 


------=_001_NextPart540553674733_=------



--===============9116212788730668343==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============9116212788730668343==--



From xen-devel-bounces@lists.xen.org Fri Oct 12 12:51:20 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 12:51:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMehd-0007mi-O2; Fri, 12 Oct 2012 12:50:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMehb-0007md-T9
	for xen-devel@lists.xensource.com; Fri, 12 Oct 2012 12:50:56 +0000
Received: from [85.158.143.35:41123] by server-1.bemta-4.messagelabs.com id
	39/46-19551-F2218705; Fri, 12 Oct 2012 12:50:55 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1350046247!15625969!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgwNzQ3OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28264 invoked from network); 12 Oct 2012 12:50:49 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Oct 2012 12:50:49 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9CCoeTR000537
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 12 Oct 2012 12:50:41 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9CCoclY023115
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 12 Oct 2012 12:50:39 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9CCoa1l008411; Fri, 12 Oct 2012 07:50:36 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Oct 2012 05:50:35 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2E7BD40376; Fri, 12 Oct 2012 08:38:43 -0400 (EDT)
Date: Fri, 12 Oct 2012 08:38:43 -0400
From: Konrad Rzeszutek Wilk 
To: David Howells 
Message-ID: <20121012123843.GC32494@phenom.dumpdata.com>
References: <30773.1349789452@warthog.procyon.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <30773.1349789452@warthog.procyon.org.uk>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [GIT PULL] Disintegrate UAPI for xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 09, 2012 at 02:30:52PM +0100, David Howells wrote:
> Can you merge the following branch into the xen tree please.

Pulled. And going to send a git pull today to Linus with it.

> 
> This is to complete part of the Userspace API (UAPI) disintegration for which
> the preparatory patches were pulled recently.  After these patches, userspace
> headers will be segregated into:
> 
> 	include/uapi/linux/.../foo.h
> 
> for the userspace interface stuff, and:
> 
> 	include/linux/.../foo.h
> 
> for the strictly kernel internal stuff.
> 
> ---
> The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8:
> 
>   Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900)
> 
> are available in the git repository at:
> 
> 
>   git://git.infradead.org/users/dhowells/linux-headers.git tags/disintegrate-xen-20121009
> 
> for you to fetch changes up to 72503791edffe516848d0f01d377fa9cd0711970:
> 
>   UAPI: (Scripted) Disintegrate include/xen (2012-10-09 09:49:15 +0100)
> 
> ----------------------------------------------------------------
> UAPI Disintegration 2012-10-09
> 
> ----------------------------------------------------------------
> David Howells (1):
>       UAPI: (Scripted) Disintegrate include/xen
> 
>  include/uapi/xen/Kbuild          | 2 ++
>  include/{ => uapi}/xen/evtchn.h  | 0
>  include/{ => uapi}/xen/privcmd.h | 0
>  include/xen/Kbuild               | 2 --
>  4 files changed, 2 insertions(+), 2 deletions(-)
>  rename include/{ => uapi}/xen/evtchn.h (100%)
>  rename include/{ => uapi}/xen/privcmd.h (100%)
> .

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 12:51:20 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 12:51:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMehd-0007mi-O2; Fri, 12 Oct 2012 12:50:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMehb-0007md-T9
	for xen-devel@lists.xensource.com; Fri, 12 Oct 2012 12:50:56 +0000
Received: from [85.158.143.35:41123] by server-1.bemta-4.messagelabs.com id
	39/46-19551-F2218705; Fri, 12 Oct 2012 12:50:55 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1350046247!15625969!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgwNzQ3OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28264 invoked from network); 12 Oct 2012 12:50:49 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Oct 2012 12:50:49 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9CCoeTR000537
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 12 Oct 2012 12:50:41 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9CCoclY023115
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 12 Oct 2012 12:50:39 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9CCoa1l008411; Fri, 12 Oct 2012 07:50:36 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Oct 2012 05:50:35 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2E7BD40376; Fri, 12 Oct 2012 08:38:43 -0400 (EDT)
Date: Fri, 12 Oct 2012 08:38:43 -0400
From: Konrad Rzeszutek Wilk 
To: David Howells 
Message-ID: <20121012123843.GC32494@phenom.dumpdata.com>
References: <30773.1349789452@warthog.procyon.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <30773.1349789452@warthog.procyon.org.uk>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [GIT PULL] Disintegrate UAPI for xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 09, 2012 at 02:30:52PM +0100, David Howells wrote:
> Can you merge the following branch into the xen tree please.

Pulled. And going to send a git pull today to Linus with it.

> 
> This is to complete part of the Userspace API (UAPI) disintegration for which
> the preparatory patches were pulled recently.  After these patches, userspace
> headers will be segregated into:
> 
> 	include/uapi/linux/.../foo.h
> 
> for the userspace interface stuff, and:
> 
> 	include/linux/.../foo.h
> 
> for the strictly kernel internal stuff.
> 
> ---
> The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8:
> 
>   Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900)
> 
> are available in the git repository at:
> 
> 
>   git://git.infradead.org/users/dhowells/linux-headers.git tags/disintegrate-xen-20121009
> 
> for you to fetch changes up to 72503791edffe516848d0f01d377fa9cd0711970:
> 
>   UAPI: (Scripted) Disintegrate include/xen (2012-10-09 09:49:15 +0100)
> 
> ----------------------------------------------------------------
> UAPI Disintegration 2012-10-09
> 
> ----------------------------------------------------------------
> David Howells (1):
>       UAPI: (Scripted) Disintegrate include/xen
> 
>  include/uapi/xen/Kbuild          | 2 ++
>  include/{ => uapi}/xen/evtchn.h  | 0
>  include/{ => uapi}/xen/privcmd.h | 0
>  include/xen/Kbuild               | 2 --
>  4 files changed, 2 insertions(+), 2 deletions(-)
>  rename include/{ => uapi}/xen/evtchn.h (100%)
>  rename include/{ => uapi}/xen/privcmd.h (100%)
> .

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 12:57:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 12:57:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMenr-0007vk-Hh; Fri, 12 Oct 2012 12:57:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMenr-0007ve-1e
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 12:57:23 +0000
Received: from [85.158.139.83:35054] by server-6.bemta-5.messagelabs.com id
	EA/EA-08519-2B318705; Fri, 12 Oct 2012 12:57:22 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1350046640!28977894!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYwMjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30953 invoked from network); 12 Oct 2012 12:57:21 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 12:57:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="41021554"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 12:57:19 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 12 Oct 2012 08:57:19 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TMenn-0005yL-6n;
	Fri, 12 Oct 2012 13:57:19 +0100
From: David Vrabel 
To: xen-devel@lists.xen.org
Date: Fri, 12 Oct 2012 13:57:11 +0100
Message-ID: <1350046634-2462-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: David Vrabel ,
	Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 0/3] xen: fix various wallclock problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This series (with some toolstack updates) corrects a number of cases
where a guest can see an incorrect wallclock time.

1. Systems with NTP won't periodically synchronize the hardware RTC so
the wallclock may be incorrect after a reboot.

2. The wallclock is always ~500 ms behind the correct time.

3. If the system time was stepped and NTP isn't synchronized yet, the
wallclock will still have the incorrect time.  The fix for this
requires the toolstack to synchronize the wallclock -- patch #3
provides the mechanism for this.

David


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 12:57:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 12:57:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMenr-0007vk-Hh; Fri, 12 Oct 2012 12:57:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMenr-0007ve-1e
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 12:57:23 +0000
Received: from [85.158.139.83:35054] by server-6.bemta-5.messagelabs.com id
	EA/EA-08519-2B318705; Fri, 12 Oct 2012 12:57:22 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1350046640!28977894!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYwMjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30953 invoked from network); 12 Oct 2012 12:57:21 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 12:57:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="41021554"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 12:57:19 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 12 Oct 2012 08:57:19 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TMenn-0005yL-6n;
	Fri, 12 Oct 2012 13:57:19 +0100
From: David Vrabel 
To: xen-devel@lists.xen.org
Date: Fri, 12 Oct 2012 13:57:11 +0100
Message-ID: <1350046634-2462-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: David Vrabel ,
	Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 0/3] xen: fix various wallclock problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This series (with some toolstack updates) corrects a number of cases
where a guest can see an incorrect wallclock time.

1. Systems with NTP won't periodically synchronize the hardware RTC so
the wallclock may be incorrect after a reboot.

2. The wallclock is always ~500 ms behind the correct time.

3. If the system time was stepped and NTP isn't synchronized yet, the
wallclock will still have the incorrect time.  The fix for this
requires the toolstack to synchronize the wallclock -- patch #3
provides the mechanism for this.

David


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 12:57:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 12:57:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMens-0007w3-Up; Fri, 12 Oct 2012 12:57:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMenr-0007vf-Hj
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 12:57:23 +0000
Received: from [85.158.139.83:5247] by server-16.bemta-5.messagelabs.com id
	E3/25-10155-2B318705; Fri, 12 Oct 2012 12:57:22 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1350046640!28977894!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYwMjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31007 invoked from network); 12 Oct 2012 12:57:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 12:57:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="41021555"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 12:57:19 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 12 Oct 2012 08:57:19 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TMenn-0005yL-98;
	Fri, 12 Oct 2012 13:57:19 +0100
From: David Vrabel 
To: xen-devel@lists.xen.org
Date: Fri, 12 Oct 2012 13:57:13 +0100
Message-ID: <1350046634-2462-3-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1350046634-2462-1-git-send-email-david.vrabel@citrix.com>
References: <1350046634-2462-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel ,
	Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 2/3] xen: add correct 500 ms offset when setting
	Xen wallclock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel 

update_persistent_wallclock() (and hence xet_set_wallclock()) is
called 500 ms after the second.  xen_set_wallclock() was not
considering this so the Xen wallclock would end up ~500 ms behind the
correct time.

Signed-off-by: David Vrabel 
---
 arch/x86/xen/time.c |    9 +++++++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index 5e7f536..11770d0 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -212,10 +212,15 @@ static int xen_set_wallclock(unsigned long now)
 	/* Set the hardware RTC. */
 	mach_set_rtc_mmss(now);
 
-	/* Set the Xen wallclock. */
+	/*
+	 * Set the Xen wallclock.
+	 *
+	 * update_persistent_wallclock() is called ~500 ms after 'now'
+	 * so add an extra 500 ms.
+	 */
 	op.cmd = XENPF_settime;
 	op.u.settime.secs = now;
-	op.u.settime.nsecs = 0;
+	op.u.settime.nsecs = NSEC_PER_SEC / 2;
 	op.u.settime.system_time = xen_clocksource_read();
 
 	rc = HYPERVISOR_dom0_op(&op);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 12:57:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 12:57:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMens-0007w3-Up; Fri, 12 Oct 2012 12:57:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMenr-0007vf-Hj
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 12:57:23 +0000
Received: from [85.158.139.83:5247] by server-16.bemta-5.messagelabs.com id
	E3/25-10155-2B318705; Fri, 12 Oct 2012 12:57:22 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1350046640!28977894!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYwMjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31007 invoked from network); 12 Oct 2012 12:57:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 12:57:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="41021555"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 12:57:19 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 12 Oct 2012 08:57:19 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TMenn-0005yL-98;
	Fri, 12 Oct 2012 13:57:19 +0100
From: David Vrabel 
To: xen-devel@lists.xen.org
Date: Fri, 12 Oct 2012 13:57:13 +0100
Message-ID: <1350046634-2462-3-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1350046634-2462-1-git-send-email-david.vrabel@citrix.com>
References: <1350046634-2462-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel ,
	Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 2/3] xen: add correct 500 ms offset when setting
	Xen wallclock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel 

update_persistent_wallclock() (and hence xet_set_wallclock()) is
called 500 ms after the second.  xen_set_wallclock() was not
considering this so the Xen wallclock would end up ~500 ms behind the
correct time.

Signed-off-by: David Vrabel 
---
 arch/x86/xen/time.c |    9 +++++++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index 5e7f536..11770d0 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -212,10 +212,15 @@ static int xen_set_wallclock(unsigned long now)
 	/* Set the hardware RTC. */
 	mach_set_rtc_mmss(now);
 
-	/* Set the Xen wallclock. */
+	/*
+	 * Set the Xen wallclock.
+	 *
+	 * update_persistent_wallclock() is called ~500 ms after 'now'
+	 * so add an extra 500 ms.
+	 */
 	op.cmd = XENPF_settime;
 	op.u.settime.secs = now;
-	op.u.settime.nsecs = 0;
+	op.u.settime.nsecs = NSEC_PER_SEC / 2;
 	op.u.settime.system_time = xen_clocksource_read();
 
 	rc = HYPERVISOR_dom0_op(&op);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 12:57:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 12:57:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMenu-0007wS-GK; Fri, 12 Oct 2012 12:57:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMens-0007vv-G5
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 12:57:24 +0000
Received: from [85.158.139.83:35174] by server-9.bemta-5.messagelabs.com id
	7C/50-31466-3B318705; Fri, 12 Oct 2012 12:57:23 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1350046640!28977894!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYwMjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31067 invoked from network); 12 Oct 2012 12:57:23 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 12:57:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="41021556"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 12:57:19 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 12 Oct 2012 08:57:19 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TMenn-0005yL-9c;
	Fri, 12 Oct 2012 13:57:19 +0100
From: David Vrabel 
To: xen-devel@lists.xen.org
Date: Fri, 12 Oct 2012 13:57:14 +0100
Message-ID: <1350046634-2462-4-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1350046634-2462-1-git-send-email-david.vrabel@citrix.com>
References: <1350046634-2462-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel ,
	Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 3/3] xen/privcmd: add
	IOCTL_PRIVCMD_SYNC_WALLCLOCK to sync Xen's wallclock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel 

Add a new ioctl to synchronize Xen's wallclock with the current system
time.

This may be used by the tools to ensure that newly created domains see
the correct wallclock time if NTP is not used in dom0 or if domains
are started before NTP has synchronized.

Signed-off-by: David Vrabel 
---
 arch/x86/xen/time.c   |   25 ++++++++++++++++++-------
 drivers/xen/privcmd.c |   12 ++++++++++++
 include/xen/privcmd.h |    8 ++++++++
 include/xen/xen-ops.h |    2 ++
 4 files changed, 40 insertions(+), 7 deletions(-)

diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index 11770d0..d481ac9 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -8,6 +8,7 @@
  * Jeremy Fitzhardinge , XenSource Inc, 2007
  */
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -192,6 +193,19 @@ static void xen_read_wallclock(struct timespec *ts)
 	put_cpu_var(xen_vcpu);
 }
 
+int xen_write_wallclock(const struct timespec *ts)
+{
+	struct xen_platform_op op;
+
+	op.cmd = XENPF_settime;
+	op.u.settime.secs = ts->tv_sec;
+	op.u.settime.nsecs = ts->tv_nsec;
+	op.u.settime.system_time = xen_clocksource_read();
+
+	return HYPERVISOR_dom0_op(&op);
+}
+EXPORT_SYMBOL_GPL(xen_write_wallclock);
+
 static unsigned long xen_get_wallclock(void)
 {
 	struct timespec ts;
@@ -202,7 +216,7 @@ static unsigned long xen_get_wallclock(void)
 
 static int xen_set_wallclock(unsigned long now)
 {
-	struct xen_platform_op op;
+	struct timespec ts;
 	int rc;
 
 	/* do nothing for domU */
@@ -218,12 +232,9 @@ static int xen_set_wallclock(unsigned long now)
 	 * update_persistent_wallclock() is called ~500 ms after 'now'
 	 * so add an extra 500 ms.
 	 */
-	op.cmd = XENPF_settime;
-	op.u.settime.secs = now;
-	op.u.settime.nsecs = NSEC_PER_SEC / 2;
-	op.u.settime.system_time = xen_clocksource_read();
-
-	rc = HYPERVISOR_dom0_op(&op);
+	ts.tv_sec = now;
+	ts.tv_nsec = NSEC_PER_SEC / 2;
+	rc = xen_write_wallclock(&ts);
 	WARN(rc != 0, "XENPF_settime failed: now=%ld\n", now);
 
 	return rc;
diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index ccee0f1..ed2caf3 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -338,6 +338,14 @@ out:
 	return ret;
 }
 
+static long privcmd_ioctl_sync_wallclock(void)
+{
+	struct timespec ts;
+
+	getnstimeofday(&ts);
+	return xen_write_wallclock(&ts);
+}
+
 static long privcmd_ioctl(struct file *file,
 			  unsigned int cmd, unsigned long data)
 {
@@ -357,6 +365,10 @@ static long privcmd_ioctl(struct file *file,
 		ret = privcmd_ioctl_mmap_batch(udata);
 		break;
 
+	case IOCTL_PRIVCMD_SYNC_WALLCLOCK:
+		ret = privcmd_ioctl_sync_wallclock();
+		break;
+
 	default:
 		ret = -EINVAL;
 		break;
diff --git a/include/xen/privcmd.h b/include/xen/privcmd.h
index 17857fb..d17d087 100644
--- a/include/xen/privcmd.h
+++ b/include/xen/privcmd.h
@@ -66,6 +66,12 @@ struct privcmd_mmapbatch {
  * @cmd: IOCTL_PRIVCMD_HYPERCALL
  * @arg: &privcmd_hypercall_t
  * Return: Value returned from execution of the specified hypercall.
+ *
+ * @cmd: IOCTL_PRIVCMD_SYNC_WALLCLOCK
+ * @arg: Unused.
+ * Synchronizes the Xen wallclock with the current system time.
+ * Return: 0 on success, or -1 on error with errno set to EPERM or
+ * EACCES.
  */
 #define IOCTL_PRIVCMD_HYPERCALL					\
 	_IOC(_IOC_NONE, 'P', 0, sizeof(struct privcmd_hypercall))
@@ -73,5 +79,7 @@ struct privcmd_mmapbatch {
 	_IOC(_IOC_NONE, 'P', 2, sizeof(struct privcmd_mmap))
 #define IOCTL_PRIVCMD_MMAPBATCH					\
 	_IOC(_IOC_NONE, 'P', 3, sizeof(struct privcmd_mmapbatch))
+#define IOCTL_PRIVCMD_SYNC_WALLCLOCK				\
+	_IOC(_IOC_NONE, 'P', 5, 0)
 
 #endif /* __LINUX_PUBLIC_PRIVCMD_H__ */
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 6a198e4..eefed22 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -29,4 +29,6 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 			       unsigned long mfn, int nr,
 			       pgprot_t prot, unsigned domid);
 
+int xen_write_wallclock(const struct timespec *ts);
+
 #endif /* INCLUDE_XEN_OPS_H */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 12:57:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 12:57:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMenu-0007wS-GK; Fri, 12 Oct 2012 12:57:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMens-0007vv-G5
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 12:57:24 +0000
Received: from [85.158.139.83:35174] by server-9.bemta-5.messagelabs.com id
	7C/50-31466-3B318705; Fri, 12 Oct 2012 12:57:23 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1350046640!28977894!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYwMjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31067 invoked from network); 12 Oct 2012 12:57:23 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 12:57:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="41021556"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 12:57:19 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 12 Oct 2012 08:57:19 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TMenn-0005yL-9c;
	Fri, 12 Oct 2012 13:57:19 +0100
From: David Vrabel 
To: xen-devel@lists.xen.org
Date: Fri, 12 Oct 2012 13:57:14 +0100
Message-ID: <1350046634-2462-4-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1350046634-2462-1-git-send-email-david.vrabel@citrix.com>
References: <1350046634-2462-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel ,
	Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 3/3] xen/privcmd: add
	IOCTL_PRIVCMD_SYNC_WALLCLOCK to sync Xen's wallclock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel 

Add a new ioctl to synchronize Xen's wallclock with the current system
time.

This may be used by the tools to ensure that newly created domains see
the correct wallclock time if NTP is not used in dom0 or if domains
are started before NTP has synchronized.

Signed-off-by: David Vrabel 
---
 arch/x86/xen/time.c   |   25 ++++++++++++++++++-------
 drivers/xen/privcmd.c |   12 ++++++++++++
 include/xen/privcmd.h |    8 ++++++++
 include/xen/xen-ops.h |    2 ++
 4 files changed, 40 insertions(+), 7 deletions(-)

diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index 11770d0..d481ac9 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -8,6 +8,7 @@
  * Jeremy Fitzhardinge , XenSource Inc, 2007
  */
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -192,6 +193,19 @@ static void xen_read_wallclock(struct timespec *ts)
 	put_cpu_var(xen_vcpu);
 }
 
+int xen_write_wallclock(const struct timespec *ts)
+{
+	struct xen_platform_op op;
+
+	op.cmd = XENPF_settime;
+	op.u.settime.secs = ts->tv_sec;
+	op.u.settime.nsecs = ts->tv_nsec;
+	op.u.settime.system_time = xen_clocksource_read();
+
+	return HYPERVISOR_dom0_op(&op);
+}
+EXPORT_SYMBOL_GPL(xen_write_wallclock);
+
 static unsigned long xen_get_wallclock(void)
 {
 	struct timespec ts;
@@ -202,7 +216,7 @@ static unsigned long xen_get_wallclock(void)
 
 static int xen_set_wallclock(unsigned long now)
 {
-	struct xen_platform_op op;
+	struct timespec ts;
 	int rc;
 
 	/* do nothing for domU */
@@ -218,12 +232,9 @@ static int xen_set_wallclock(unsigned long now)
 	 * update_persistent_wallclock() is called ~500 ms after 'now'
 	 * so add an extra 500 ms.
 	 */
-	op.cmd = XENPF_settime;
-	op.u.settime.secs = now;
-	op.u.settime.nsecs = NSEC_PER_SEC / 2;
-	op.u.settime.system_time = xen_clocksource_read();
-
-	rc = HYPERVISOR_dom0_op(&op);
+	ts.tv_sec = now;
+	ts.tv_nsec = NSEC_PER_SEC / 2;
+	rc = xen_write_wallclock(&ts);
 	WARN(rc != 0, "XENPF_settime failed: now=%ld\n", now);
 
 	return rc;
diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index ccee0f1..ed2caf3 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -338,6 +338,14 @@ out:
 	return ret;
 }
 
+static long privcmd_ioctl_sync_wallclock(void)
+{
+	struct timespec ts;
+
+	getnstimeofday(&ts);
+	return xen_write_wallclock(&ts);
+}
+
 static long privcmd_ioctl(struct file *file,
 			  unsigned int cmd, unsigned long data)
 {
@@ -357,6 +365,10 @@ static long privcmd_ioctl(struct file *file,
 		ret = privcmd_ioctl_mmap_batch(udata);
 		break;
 
+	case IOCTL_PRIVCMD_SYNC_WALLCLOCK:
+		ret = privcmd_ioctl_sync_wallclock();
+		break;
+
 	default:
 		ret = -EINVAL;
 		break;
diff --git a/include/xen/privcmd.h b/include/xen/privcmd.h
index 17857fb..d17d087 100644
--- a/include/xen/privcmd.h
+++ b/include/xen/privcmd.h
@@ -66,6 +66,12 @@ struct privcmd_mmapbatch {
  * @cmd: IOCTL_PRIVCMD_HYPERCALL
  * @arg: &privcmd_hypercall_t
  * Return: Value returned from execution of the specified hypercall.
+ *
+ * @cmd: IOCTL_PRIVCMD_SYNC_WALLCLOCK
+ * @arg: Unused.
+ * Synchronizes the Xen wallclock with the current system time.
+ * Return: 0 on success, or -1 on error with errno set to EPERM or
+ * EACCES.
  */
 #define IOCTL_PRIVCMD_HYPERCALL					\
 	_IOC(_IOC_NONE, 'P', 0, sizeof(struct privcmd_hypercall))
@@ -73,5 +79,7 @@ struct privcmd_mmapbatch {
 	_IOC(_IOC_NONE, 'P', 2, sizeof(struct privcmd_mmap))
 #define IOCTL_PRIVCMD_MMAPBATCH					\
 	_IOC(_IOC_NONE, 'P', 3, sizeof(struct privcmd_mmapbatch))
+#define IOCTL_PRIVCMD_SYNC_WALLCLOCK				\
+	_IOC(_IOC_NONE, 'P', 5, 0)
 
 #endif /* __LINUX_PUBLIC_PRIVCMD_H__ */
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 6a198e4..eefed22 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -29,4 +29,6 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 			       unsigned long mfn, int nr,
 			       pgprot_t prot, unsigned domid);
 
+int xen_write_wallclock(const struct timespec *ts);
+
 #endif /* INCLUDE_XEN_OPS_H */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 12:57:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 12:57:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMenu-0007wb-Sj; Fri, 12 Oct 2012 12:57:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMens-0007vw-Vf
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 12:57:25 +0000
Received: from [85.158.139.211:63414] by server-1.bemta-5.messagelabs.com id
	05/04-18294-4B318705; Fri, 12 Oct 2012 12:57:24 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1350046642!22135305!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYwMjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25273 invoked from network); 12 Oct 2012 12:57:23 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 12:57:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="41021557"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 12:57:19 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 12 Oct 2012 08:57:19 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TMenn-0005yL-8b;
	Fri, 12 Oct 2012 13:57:19 +0100
From: David Vrabel 
To: xen-devel@lists.xen.org
Date: Fri, 12 Oct 2012 13:57:12 +0100
Message-ID: <1350046634-2462-2-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1350046634-2462-1-git-send-email-david.vrabel@citrix.com>
References: <1350046634-2462-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel ,
	Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 1/3] xen: sync the CMOS RTC as well as the Xen
	wallclock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel 

If NTP is used in dom0 and it is synchronized to its clock source,
then the kernel will periodically synchronize the Xen wallclock with
the system time.  Updates to the Xen wallclock do not persist across
reboots, so also synchronize the CMOS RTC (as on bare metal).

Signed-off-by: David Vrabel 
---
 arch/x86/xen/time.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index 0296a95..5e7f536 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -208,6 +209,10 @@ static int xen_set_wallclock(unsigned long now)
 	if (!xen_initial_domain())
 		return -1;
 
+	/* Set the hardware RTC. */
+	mach_set_rtc_mmss(now);
+
+	/* Set the Xen wallclock. */
 	op.cmd = XENPF_settime;
 	op.u.settime.secs = now;
 	op.u.settime.nsecs = 0;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 12:57:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 12:57:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMenu-0007wb-Sj; Fri, 12 Oct 2012 12:57:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMens-0007vw-Vf
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 12:57:25 +0000
Received: from [85.158.139.211:63414] by server-1.bemta-5.messagelabs.com id
	05/04-18294-4B318705; Fri, 12 Oct 2012 12:57:24 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1350046642!22135305!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYwMjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25273 invoked from network); 12 Oct 2012 12:57:23 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 12:57:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="41021557"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 12:57:19 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 12 Oct 2012 08:57:19 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TMenn-0005yL-8b;
	Fri, 12 Oct 2012 13:57:19 +0100
From: David Vrabel 
To: xen-devel@lists.xen.org
Date: Fri, 12 Oct 2012 13:57:12 +0100
Message-ID: <1350046634-2462-2-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1350046634-2462-1-git-send-email-david.vrabel@citrix.com>
References: <1350046634-2462-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel ,
	Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 1/3] xen: sync the CMOS RTC as well as the Xen
	wallclock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel 

If NTP is used in dom0 and it is synchronized to its clock source,
then the kernel will periodically synchronize the Xen wallclock with
the system time.  Updates to the Xen wallclock do not persist across
reboots, so also synchronize the CMOS RTC (as on bare metal).

Signed-off-by: David Vrabel 
---
 arch/x86/xen/time.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index 0296a95..5e7f536 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -208,6 +209,10 @@ static int xen_set_wallclock(unsigned long now)
 	if (!xen_initial_domain())
 		return -1;
 
+	/* Set the hardware RTC. */
+	mach_set_rtc_mmss(now);
+
+	/* Set the Xen wallclock. */
 	op.cmd = XENPF_settime;
 	op.u.settime.secs = now;
 	op.u.settime.nsecs = 0;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 13:03:13 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 13:03:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMetI-000055-Ln; Fri, 12 Oct 2012 13:03:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMetH-00004q-20
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 13:02:59 +0000
Received: from [85.158.138.51:15971] by server-1.bemta-3.messagelabs.com id
	47/F2-31728-20518705; Fri, 12 Oct 2012 13:02:58 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1350046976!34078915!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYwMjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26868 invoked from network); 12 Oct 2012 13:02:57 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 13:02:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="41022230"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 13:02:55 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 12 Oct 2012 09:02:55 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TMetD-00063o-2R;
	Fri, 12 Oct 2012 14:02:55 +0100
From: David Vrabel 
To: xen-devel@lists.xen.org
Date: Fri, 12 Oct 2012 14:02:48 +0100
Message-ID: <1350046970-2591-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: David Vrabel 
Subject: [Xen-devel] [PATCH 0/2] tools: add wallclock synchronization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is the toolstack side of the Linux wallclock fixes.  A new libxc
call, xc_wallclock_sync() is provided and a new command line utility
(xen-wallclock) makes use of this.

I also considered making libxl call xc_wallclock_sync() during domain
creation but wasn't sure if this was sensible or whether there needed
to be an xl configuration option to enable/disable this behaviour.
Any comments?

David


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 13:03:13 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 13:03:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMetI-000055-Ln; Fri, 12 Oct 2012 13:03:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMetH-00004q-20
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 13:02:59 +0000
Received: from [85.158.138.51:15971] by server-1.bemta-3.messagelabs.com id
	47/F2-31728-20518705; Fri, 12 Oct 2012 13:02:58 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1350046976!34078915!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYwMjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26868 invoked from network); 12 Oct 2012 13:02:57 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 13:02:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="41022230"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 13:02:55 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 12 Oct 2012 09:02:55 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TMetD-00063o-2R;
	Fri, 12 Oct 2012 14:02:55 +0100
From: David Vrabel 
To: xen-devel@lists.xen.org
Date: Fri, 12 Oct 2012 14:02:48 +0100
Message-ID: <1350046970-2591-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: David Vrabel 
Subject: [Xen-devel] [PATCH 0/2] tools: add wallclock synchronization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is the toolstack side of the Linux wallclock fixes.  A new libxc
call, xc_wallclock_sync() is provided and a new command line utility
(xen-wallclock) makes use of this.

I also considered making libxl call xc_wallclock_sync() during domain
creation but wasn't sure if this was sensible or whether there needed
to be an xl configuration option to enable/disable this behaviour.
Any comments?

David


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 13:03:13 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 13:03:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMetJ-00005H-1V; Fri, 12 Oct 2012 13:03:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMetH-00004u-PZ
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 13:03:00 +0000
Received: from [85.158.138.51:4661] by server-3.bemta-3.messagelabs.com id
	C3/44-09368-20518705; Fri, 12 Oct 2012 13:02:58 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1350046976!34078915!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYwMjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26883 invoked from network); 12 Oct 2012 13:02:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 13:02:58 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="41022231"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 13:02:55 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 12 Oct 2012 09:02:55 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TMetD-00063o-4B;
	Fri, 12 Oct 2012 14:02:55 +0100
From: David Vrabel 
To: xen-devel@lists.xen.org
Date: Fri, 12 Oct 2012 14:02:49 +0100
Message-ID: <1350046970-2591-2-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1350046970-2591-1-git-send-email-david.vrabel@citrix.com>
References: <1350046970-2591-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel 
Subject: [Xen-devel] [PATCH 1/2] libxc: add xc_wallclock_sync()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel 

xc_wallclock_sync() synchronizes the Xen wallclock to system time.

This requires a Linux kernel with a privcmd device that provides the
IOCTL_PRIVCMD_SYNC_WALLCLOCK ioctl.

Signed-off-by: David Vrabel 
---
 tools/include/xen-sys/Linux/privcmd.h |    8 ++++++++
 tools/libxc/Makefile                  |    1 +
 tools/libxc/xc_linux_osdep.c          |    7 +++++++
 tools/libxc/xc_wallclock.c            |   23 +++++++++++++++++++++++
 tools/libxc/xenctrl.h                 |    5 +++++
 tools/libxc/xenctrlosdep.h            |    2 ++
 6 files changed, 46 insertions(+), 0 deletions(-)
 create mode 100644 tools/libxc/xc_wallclock.c

diff --git a/tools/include/xen-sys/Linux/privcmd.h b/tools/include/xen-sys/Linux/privcmd.h
index d35aac9..55765d1 100644
--- a/tools/include/xen-sys/Linux/privcmd.h
+++ b/tools/include/xen-sys/Linux/privcmd.h
@@ -76,6 +76,12 @@ typedef struct privcmd_mmapbatch_v2 {
  * @cmd: IOCTL_PRIVCMD_HYPERCALL
  * @arg: &privcmd_hypercall_t
  * Return: Value returned from execution of the specified hypercall.
+ *
+ * @cmd: IOCTL_PRIVCMD_SYNC_WALLCLOCK
+ * @arg: Unused.
+ * Synchronizes the Xen wallclock with the current system time.
+ * Return: 0 on success, or -1 on error with errno set to EPERM or
+ * EACCES.
  */
 #define IOCTL_PRIVCMD_HYPERCALL					\
 	_IOC(_IOC_NONE, 'P', 0, sizeof(privcmd_hypercall_t))
@@ -85,5 +91,7 @@ typedef struct privcmd_mmapbatch_v2 {
 	_IOC(_IOC_NONE, 'P', 3, sizeof(privcmd_mmapbatch_t))
 #define IOCTL_PRIVCMD_MMAPBATCH_V2				\
 	_IOC(_IOC_NONE, 'P', 4, sizeof(privcmd_mmapbatch_v2_t))
+#define IOCTL_PRIVCMD_SYNC_WALLCLOCK				\
+	_IOC(_IOC_NONE, 'P', 5, 0)
 
 #endif /* __LINUX_PUBLIC_PRIVCMD_H__ */
diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index d44abf9..601ea4b 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -31,6 +31,7 @@ CTRL_SRCS-y       += xc_mem_access.c
 CTRL_SRCS-y       += xc_memshr.c
 CTRL_SRCS-y       += xc_hcall_buf.c
 CTRL_SRCS-y       += xc_foreign_memory.c
+CTRL_SRCS-y       += xc_wallclock.c
 CTRL_SRCS-y       += xtl_core.c
 CTRL_SRCS-y       += xtl_logger_stdio.c
 CTRL_SRCS-$(CONFIG_X86) += xc_pagetab.c
diff --git a/tools/libxc/xc_linux_osdep.c b/tools/libxc/xc_linux_osdep.c
index 787e742..7c73b66 100644
--- a/tools/libxc/xc_linux_osdep.c
+++ b/tools/libxc/xc_linux_osdep.c
@@ -412,6 +412,11 @@ static void *linux_privcmd_map_foreign_ranges(xc_interface *xch, xc_osdep_handle
     return ret;
 }
 
+static int linux_wallclock_sync(xc_interface *xch, xc_osdep_handle h)
+{
+    return ioctl(h, IOCTL_PRIVCMD_SYNC_WALLCLOCK, NULL);
+}
+
 static struct xc_osdep_ops linux_privcmd_ops = {
     .open = &linux_privcmd_open,
     .close = &linux_privcmd_close,
@@ -426,6 +431,8 @@ static struct xc_osdep_ops linux_privcmd_ops = {
         .map_foreign_bulk = &linux_privcmd_map_foreign_bulk,
         .map_foreign_range = &linux_privcmd_map_foreign_range,
         .map_foreign_ranges = &linux_privcmd_map_foreign_ranges,
+
+        .wallclock_sync = linux_wallclock_sync,
     },
 };
 
diff --git a/tools/libxc/xc_wallclock.c b/tools/libxc/xc_wallclock.c
new file mode 100644
index 0000000..5119b2a
--- /dev/null
+++ b/tools/libxc/xc_wallclock.c
@@ -0,0 +1,23 @@
+/******************************************************************************
+ * xc_wallclock.c
+ *
+ * API for the wallclock.
+ *
+ * Copyright (C) 2012, Citrix Systems (UK) Ltd.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ */
+
+#include "xc_private.h"
+
+int xc_wallclock_sync(xc_interface *xch)
+{
+    if (xch->ops->u.privcmd.wallclock_sync == NULL) {
+        errno = ENOSYS;
+        return -1;
+    }
+    return xch->ops->u.privcmd.wallclock_sync(xch, xch->ops_handle);
+}
diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
index 7eb5743..f9bb21b 100644
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -2224,4 +2224,9 @@ int xc_compression_uncompress_page(xc_interface *xch, char *compbuf,
 				   unsigned long compbuf_size,
 				   unsigned long *compbuf_pos, char *dest);
 
+/**
+ * Synchronize Xen's wallclock with the current system time.
+ */
+int xc_wallclock_sync(xc_interface *xch);
+
 #endif /* XENCTRL_H */
diff --git a/tools/libxc/xenctrlosdep.h b/tools/libxc/xenctrlosdep.h
index a36c4aa..3aa3360 100644
--- a/tools/libxc/xenctrlosdep.h
+++ b/tools/libxc/xenctrlosdep.h
@@ -89,6 +89,8 @@ struct xc_osdep_ops
             void *(*map_foreign_ranges)(xc_interface *xch, xc_osdep_handle h, uint32_t dom, size_t size, int prot,
                                         size_t chunksize, privcmd_mmap_entry_t entries[],
                                         int nentries);
+
+            int (*wallclock_sync)(xc_interface *xch, xc_osdep_handle h);
         } privcmd;
         struct {
             int (*fd)(xc_evtchn *xce, xc_osdep_handle h);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 13:03:13 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 13:03:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMetJ-00005H-1V; Fri, 12 Oct 2012 13:03:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMetH-00004u-PZ
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 13:03:00 +0000
Received: from [85.158.138.51:4661] by server-3.bemta-3.messagelabs.com id
	C3/44-09368-20518705; Fri, 12 Oct 2012 13:02:58 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1350046976!34078915!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYwMjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26883 invoked from network); 12 Oct 2012 13:02:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 13:02:58 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="41022231"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 13:02:55 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 12 Oct 2012 09:02:55 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TMetD-00063o-4B;
	Fri, 12 Oct 2012 14:02:55 +0100
From: David Vrabel 
To: xen-devel@lists.xen.org
Date: Fri, 12 Oct 2012 14:02:49 +0100
Message-ID: <1350046970-2591-2-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1350046970-2591-1-git-send-email-david.vrabel@citrix.com>
References: <1350046970-2591-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel 
Subject: [Xen-devel] [PATCH 1/2] libxc: add xc_wallclock_sync()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel 

xc_wallclock_sync() synchronizes the Xen wallclock to system time.

This requires a Linux kernel with a privcmd device that provides the
IOCTL_PRIVCMD_SYNC_WALLCLOCK ioctl.

Signed-off-by: David Vrabel 
---
 tools/include/xen-sys/Linux/privcmd.h |    8 ++++++++
 tools/libxc/Makefile                  |    1 +
 tools/libxc/xc_linux_osdep.c          |    7 +++++++
 tools/libxc/xc_wallclock.c            |   23 +++++++++++++++++++++++
 tools/libxc/xenctrl.h                 |    5 +++++
 tools/libxc/xenctrlosdep.h            |    2 ++
 6 files changed, 46 insertions(+), 0 deletions(-)
 create mode 100644 tools/libxc/xc_wallclock.c

diff --git a/tools/include/xen-sys/Linux/privcmd.h b/tools/include/xen-sys/Linux/privcmd.h
index d35aac9..55765d1 100644
--- a/tools/include/xen-sys/Linux/privcmd.h
+++ b/tools/include/xen-sys/Linux/privcmd.h
@@ -76,6 +76,12 @@ typedef struct privcmd_mmapbatch_v2 {
  * @cmd: IOCTL_PRIVCMD_HYPERCALL
  * @arg: &privcmd_hypercall_t
  * Return: Value returned from execution of the specified hypercall.
+ *
+ * @cmd: IOCTL_PRIVCMD_SYNC_WALLCLOCK
+ * @arg: Unused.
+ * Synchronizes the Xen wallclock with the current system time.
+ * Return: 0 on success, or -1 on error with errno set to EPERM or
+ * EACCES.
  */
 #define IOCTL_PRIVCMD_HYPERCALL					\
 	_IOC(_IOC_NONE, 'P', 0, sizeof(privcmd_hypercall_t))
@@ -85,5 +91,7 @@ typedef struct privcmd_mmapbatch_v2 {
 	_IOC(_IOC_NONE, 'P', 3, sizeof(privcmd_mmapbatch_t))
 #define IOCTL_PRIVCMD_MMAPBATCH_V2				\
 	_IOC(_IOC_NONE, 'P', 4, sizeof(privcmd_mmapbatch_v2_t))
+#define IOCTL_PRIVCMD_SYNC_WALLCLOCK				\
+	_IOC(_IOC_NONE, 'P', 5, 0)
 
 #endif /* __LINUX_PUBLIC_PRIVCMD_H__ */
diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index d44abf9..601ea4b 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -31,6 +31,7 @@ CTRL_SRCS-y       += xc_mem_access.c
 CTRL_SRCS-y       += xc_memshr.c
 CTRL_SRCS-y       += xc_hcall_buf.c
 CTRL_SRCS-y       += xc_foreign_memory.c
+CTRL_SRCS-y       += xc_wallclock.c
 CTRL_SRCS-y       += xtl_core.c
 CTRL_SRCS-y       += xtl_logger_stdio.c
 CTRL_SRCS-$(CONFIG_X86) += xc_pagetab.c
diff --git a/tools/libxc/xc_linux_osdep.c b/tools/libxc/xc_linux_osdep.c
index 787e742..7c73b66 100644
--- a/tools/libxc/xc_linux_osdep.c
+++ b/tools/libxc/xc_linux_osdep.c
@@ -412,6 +412,11 @@ static void *linux_privcmd_map_foreign_ranges(xc_interface *xch, xc_osdep_handle
     return ret;
 }
 
+static int linux_wallclock_sync(xc_interface *xch, xc_osdep_handle h)
+{
+    return ioctl(h, IOCTL_PRIVCMD_SYNC_WALLCLOCK, NULL);
+}
+
 static struct xc_osdep_ops linux_privcmd_ops = {
     .open = &linux_privcmd_open,
     .close = &linux_privcmd_close,
@@ -426,6 +431,8 @@ static struct xc_osdep_ops linux_privcmd_ops = {
         .map_foreign_bulk = &linux_privcmd_map_foreign_bulk,
         .map_foreign_range = &linux_privcmd_map_foreign_range,
         .map_foreign_ranges = &linux_privcmd_map_foreign_ranges,
+
+        .wallclock_sync = linux_wallclock_sync,
     },
 };
 
diff --git a/tools/libxc/xc_wallclock.c b/tools/libxc/xc_wallclock.c
new file mode 100644
index 0000000..5119b2a
--- /dev/null
+++ b/tools/libxc/xc_wallclock.c
@@ -0,0 +1,23 @@
+/******************************************************************************
+ * xc_wallclock.c
+ *
+ * API for the wallclock.
+ *
+ * Copyright (C) 2012, Citrix Systems (UK) Ltd.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ */
+
+#include "xc_private.h"
+
+int xc_wallclock_sync(xc_interface *xch)
+{
+    if (xch->ops->u.privcmd.wallclock_sync == NULL) {
+        errno = ENOSYS;
+        return -1;
+    }
+    return xch->ops->u.privcmd.wallclock_sync(xch, xch->ops_handle);
+}
diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
index 7eb5743..f9bb21b 100644
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -2224,4 +2224,9 @@ int xc_compression_uncompress_page(xc_interface *xch, char *compbuf,
 				   unsigned long compbuf_size,
 				   unsigned long *compbuf_pos, char *dest);
 
+/**
+ * Synchronize Xen's wallclock with the current system time.
+ */
+int xc_wallclock_sync(xc_interface *xch);
+
 #endif /* XENCTRL_H */
diff --git a/tools/libxc/xenctrlosdep.h b/tools/libxc/xenctrlosdep.h
index a36c4aa..3aa3360 100644
--- a/tools/libxc/xenctrlosdep.h
+++ b/tools/libxc/xenctrlosdep.h
@@ -89,6 +89,8 @@ struct xc_osdep_ops
             void *(*map_foreign_ranges)(xc_interface *xch, xc_osdep_handle h, uint32_t dom, size_t size, int prot,
                                         size_t chunksize, privcmd_mmap_entry_t entries[],
                                         int nentries);
+
+            int (*wallclock_sync)(xc_interface *xch, xc_osdep_handle h);
         } privcmd;
         struct {
             int (*fd)(xc_evtchn *xce, xc_osdep_handle h);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 13:03:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 13:03:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMetJ-00005S-Ry; Fri, 12 Oct 2012 13:03:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMetI-00004z-FD
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 13:03:00 +0000
Received: from [85.158.138.51:4696] by server-7.bemta-3.messagelabs.com id
	16/D2-06991-30518705; Fri, 12 Oct 2012 13:02:59 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1350046976!34078915!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYwMjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26896 invoked from network); 12 Oct 2012 13:02:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 13:02:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="41022232"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 13:02:55 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 12 Oct 2012 09:02:55 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TMetD-00063o-4a;
	Fri, 12 Oct 2012 14:02:55 +0100
From: David Vrabel 
To: xen-devel@lists.xen.org
Date: Fri, 12 Oct 2012 14:02:50 +0100
Message-ID: <1350046970-2591-3-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1350046970-2591-1-git-send-email-david.vrabel@citrix.com>
References: <1350046970-2591-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel 
Subject: [Xen-devel] [PATCH 2/2] tools/misc: add xen-wallclock command
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel 

Add the xen-wallclock command for synchronizing the Xen wallclock to
system time.  The command is similar to the hwclock command for
synchronizing the hardware RTC and takes a similar --systowc command
line option.

Signed-off-by: David Vrabel 
---
 .gitignore                 |    1 +
 .hgignore                  |    1 +
 tools/misc/Makefile        |    8 +++-
 tools/misc/xen-wallclock.c |   87 ++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 95 insertions(+), 2 deletions(-)
 create mode 100644 tools/misc/xen-wallclock.c

diff --git a/.gitignore b/.gitignore
index f6edc43..a62abd2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -196,6 +196,7 @@ tools/misc/xc_shadow
 tools/misc/xen_cpuperf
 tools/misc/xen-detect
 tools/misc/xen-tmem-list-parse
+tools/misc/xen-wallclock
 tools/misc/xenperf
 tools/misc/xenpm
 tools/misc/xen-hvmctx
diff --git a/.hgignore b/.hgignore
index 344792a..3b6f747 100644
--- a/.hgignore
+++ b/.hgignore
@@ -198,6 +198,7 @@
 ^tools/misc/xen-hptool$
 ^tools/misc/xen-hvmcrash$
 ^tools/misc/xen-tmem-list-parse$
+^tools/misc/xen-wallclock$
 ^tools/misc/xenperf$
 ^tools/misc/xenpm$
 ^tools/misc/xen-hvmctx$
diff --git a/tools/misc/Makefile b/tools/misc/Makefile
index 22e60fd..456d1ad 100644
--- a/tools/misc/Makefile
+++ b/tools/misc/Makefile
@@ -9,7 +9,8 @@ CFLAGS += $(CFLAGS_libxenstore)
 
 HDRS     = $(wildcard *.h)
 
-TARGETS-y := xenperf xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd
+TARGETS-y := xenperf xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd \
+	xen-wallclock
 TARGETS-$(CONFIG_X86) += xen-detect xen-hvmctx xen-hvmcrash xen-lowmemd
 TARGETS-$(CONFIG_MIGRATE) += xen-hptool
 TARGETS := $(TARGETS-y)
@@ -22,7 +23,7 @@ INSTALL_BIN-y := xencons
 INSTALL_BIN-$(CONFIG_X86) += xen-detect
 INSTALL_BIN := $(INSTALL_BIN-y)
 
-INSTALL_SBIN-y := xm xen-bugtool xen-python-path xend xenperf xsview xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd xen-ringwatch
+INSTALL_SBIN-y := xm xen-bugtool xen-python-path xend xenperf xsview xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd xen-ringwatch xen-wallclock
 INSTALL_SBIN-$(CONFIG_X86) += xen-hvmctx xen-hvmcrash xen-lowmemd
 INSTALL_SBIN-$(CONFIG_MIGRATE) += xen-hptool
 INSTALL_SBIN := $(INSTALL_SBIN-y)
@@ -85,4 +86,7 @@ xen-lowmemd: xen-lowmemd.o
 gtraceview: gtraceview.o
 	$(CC) $(LDFLAGS) -o $@ $< $(CURSES_LIBS) $(APPEND_LDFLAGS)
 
+xen-wallclock: xen-wallclock.o
+	$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
+
 -include $(DEPS)
diff --git a/tools/misc/xen-wallclock.c b/tools/misc/xen-wallclock.c
new file mode 100644
index 0000000..e4af166
--- /dev/null
+++ b/tools/misc/xen-wallclock.c
@@ -0,0 +1,87 @@
+/*
+ * xen-wallclock.c: manage the Xen wallclock.
+ * Copyright (C) 2012, Citrix Systems (UK) Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+static const char *exe_name;
+
+static void usage(FILE *f)
+{
+    fprintf(f, "Usage: %s --systowc\n", exe_name);
+}
+
+static void help(void)
+{
+    usage(stdout);
+    printf("Synchronize the Xen wallclock with system time.\n"
+           "\n"
+           "  -w, --systowc synchronize wallclock with system time\n"
+           "      --help    display this help and exit\n");
+    exit(0);
+}
+
+int main(int argc, char *argv[])
+{
+    const static char sopts[] = "w";
+    const static struct option lopts[] = {
+        { "help", 0, NULL, 0 },
+        { "systowc", 0, NULL, 'w' },
+        { 0, 0, NULL, 0 },
+    };
+    int opt, opt_idx;
+
+    int systowc = 0;
+    xc_interface *xch;
+
+    exe_name = argv[0];
+
+    while ( (opt = getopt_long(argc, argv, sopts, lopts, &opt_idx)) != -1 )
+    {
+        switch ( opt )
+        {
+        case 'w':
+            systowc = 1;
+            break;
+        case 0:
+            switch (opt_idx)
+            {
+            case 0:
+                help();
+            }
+            break;
+        default:
+            usage(stderr);
+            exit(1);
+        }
+    }
+
+    /* Valid combination of options? i.e., --systowc */
+    if (!systowc)
+    {
+        usage(stderr);
+        exit(1);
+    }
+
+    xch = xc_interface_open(NULL, NULL, 0);
+    if (xch == NULL)
+    {
+        exit(1);
+    }
+    xc_wallclock_sync(xch);
+    xc_interface_close(xch);
+
+    return 0;
+}
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 13:03:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 13:03:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMetJ-00005S-Ry; Fri, 12 Oct 2012 13:03:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMetI-00004z-FD
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 13:03:00 +0000
Received: from [85.158.138.51:4696] by server-7.bemta-3.messagelabs.com id
	16/D2-06991-30518705; Fri, 12 Oct 2012 13:02:59 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1350046976!34078915!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYwMjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26896 invoked from network); 12 Oct 2012 13:02:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 13:02:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="41022232"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 13:02:55 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 12 Oct 2012 09:02:55 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TMetD-00063o-4a;
	Fri, 12 Oct 2012 14:02:55 +0100
From: David Vrabel 
To: xen-devel@lists.xen.org
Date: Fri, 12 Oct 2012 14:02:50 +0100
Message-ID: <1350046970-2591-3-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1350046970-2591-1-git-send-email-david.vrabel@citrix.com>
References: <1350046970-2591-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel 
Subject: [Xen-devel] [PATCH 2/2] tools/misc: add xen-wallclock command
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel 

Add the xen-wallclock command for synchronizing the Xen wallclock to
system time.  The command is similar to the hwclock command for
synchronizing the hardware RTC and takes a similar --systowc command
line option.

Signed-off-by: David Vrabel 
---
 .gitignore                 |    1 +
 .hgignore                  |    1 +
 tools/misc/Makefile        |    8 +++-
 tools/misc/xen-wallclock.c |   87 ++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 95 insertions(+), 2 deletions(-)
 create mode 100644 tools/misc/xen-wallclock.c

diff --git a/.gitignore b/.gitignore
index f6edc43..a62abd2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -196,6 +196,7 @@ tools/misc/xc_shadow
 tools/misc/xen_cpuperf
 tools/misc/xen-detect
 tools/misc/xen-tmem-list-parse
+tools/misc/xen-wallclock
 tools/misc/xenperf
 tools/misc/xenpm
 tools/misc/xen-hvmctx
diff --git a/.hgignore b/.hgignore
index 344792a..3b6f747 100644
--- a/.hgignore
+++ b/.hgignore
@@ -198,6 +198,7 @@
 ^tools/misc/xen-hptool$
 ^tools/misc/xen-hvmcrash$
 ^tools/misc/xen-tmem-list-parse$
+^tools/misc/xen-wallclock$
 ^tools/misc/xenperf$
 ^tools/misc/xenpm$
 ^tools/misc/xen-hvmctx$
diff --git a/tools/misc/Makefile b/tools/misc/Makefile
index 22e60fd..456d1ad 100644
--- a/tools/misc/Makefile
+++ b/tools/misc/Makefile
@@ -9,7 +9,8 @@ CFLAGS += $(CFLAGS_libxenstore)
 
 HDRS     = $(wildcard *.h)
 
-TARGETS-y := xenperf xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd
+TARGETS-y := xenperf xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd \
+	xen-wallclock
 TARGETS-$(CONFIG_X86) += xen-detect xen-hvmctx xen-hvmcrash xen-lowmemd
 TARGETS-$(CONFIG_MIGRATE) += xen-hptool
 TARGETS := $(TARGETS-y)
@@ -22,7 +23,7 @@ INSTALL_BIN-y := xencons
 INSTALL_BIN-$(CONFIG_X86) += xen-detect
 INSTALL_BIN := $(INSTALL_BIN-y)
 
-INSTALL_SBIN-y := xm xen-bugtool xen-python-path xend xenperf xsview xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd xen-ringwatch
+INSTALL_SBIN-y := xm xen-bugtool xen-python-path xend xenperf xsview xenpm xen-tmem-list-parse gtraceview gtracestat xenlockprof xenwatchdogd xen-ringwatch xen-wallclock
 INSTALL_SBIN-$(CONFIG_X86) += xen-hvmctx xen-hvmcrash xen-lowmemd
 INSTALL_SBIN-$(CONFIG_MIGRATE) += xen-hptool
 INSTALL_SBIN := $(INSTALL_SBIN-y)
@@ -85,4 +86,7 @@ xen-lowmemd: xen-lowmemd.o
 gtraceview: gtraceview.o
 	$(CC) $(LDFLAGS) -o $@ $< $(CURSES_LIBS) $(APPEND_LDFLAGS)
 
+xen-wallclock: xen-wallclock.o
+	$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
+
 -include $(DEPS)
diff --git a/tools/misc/xen-wallclock.c b/tools/misc/xen-wallclock.c
new file mode 100644
index 0000000..e4af166
--- /dev/null
+++ b/tools/misc/xen-wallclock.c
@@ -0,0 +1,87 @@
+/*
+ * xen-wallclock.c: manage the Xen wallclock.
+ * Copyright (C) 2012, Citrix Systems (UK) Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+static const char *exe_name;
+
+static void usage(FILE *f)
+{
+    fprintf(f, "Usage: %s --systowc\n", exe_name);
+}
+
+static void help(void)
+{
+    usage(stdout);
+    printf("Synchronize the Xen wallclock with system time.\n"
+           "\n"
+           "  -w, --systowc synchronize wallclock with system time\n"
+           "      --help    display this help and exit\n");
+    exit(0);
+}
+
+int main(int argc, char *argv[])
+{
+    const static char sopts[] = "w";
+    const static struct option lopts[] = {
+        { "help", 0, NULL, 0 },
+        { "systowc", 0, NULL, 'w' },
+        { 0, 0, NULL, 0 },
+    };
+    int opt, opt_idx;
+
+    int systowc = 0;
+    xc_interface *xch;
+
+    exe_name = argv[0];
+
+    while ( (opt = getopt_long(argc, argv, sopts, lopts, &opt_idx)) != -1 )
+    {
+        switch ( opt )
+        {
+        case 'w':
+            systowc = 1;
+            break;
+        case 0:
+            switch (opt_idx)
+            {
+            case 0:
+                help();
+            }
+            break;
+        default:
+            usage(stderr);
+            exit(1);
+        }
+    }
+
+    /* Valid combination of options? i.e., --systowc */
+    if (!systowc)
+    {
+        usage(stderr);
+        exit(1);
+    }
+
+    xch = xc_interface_open(NULL, NULL, 0);
+    if (xch == NULL)
+    {
+        exit(1);
+    }
+    xc_wallclock_sync(xch);
+    xc_interface_close(xch);
+
+    return 0;
+}
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 13:20:21 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 13:20:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMf9o-0000Wi-Jq; Fri, 12 Oct 2012 13:20:04 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMf9n-0000Wd-1B
	for xen-devel@lists.xensource.com; Fri, 12 Oct 2012 13:20:03 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1350047995!14410484!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODAwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10041 invoked from network); 12 Oct 2012 13:19:56 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Oct 2012 13:19:56 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9CDJrvT029382
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 12 Oct 2012 13:19:53 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9CDJqAO021075
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 12 Oct 2012 13:19:53 GMT
Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9CDJqN2006543; Fri, 12 Oct 2012 08:19:52 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Oct 2012 06:19:52 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 18DF940376; Fri, 12 Oct 2012 09:08:01 -0400 (EDT)
Date: Fri, 12 Oct 2012 09:08:01 -0400
From: Konrad Rzeszutek Wilk 
To: Linus Torvalds ,
	linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Message-ID: <20121012130800.GD32494@phenom.dumpdata.com>
MIME-Version: 1.0
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Subject: [Xen-devel] [GIT PULL] (xen) stable/for-linus-3.7-rc0-tag for
	v3.7-rc0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============7689612060310045404=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============7689612060310045404==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="C7zPtVaVf+AK4Oqc"
Content-Disposition: inline


--C7zPtVaVf+AK4Oqc
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hey Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-linus-3.7-rc0-tag

which has four bug-fixes and one tiny feature that I forgot to put initially in my tree
due to oversight.

The feature is for kdump kernels to speed up the /proc/vmcore reading. There is a
ram_is_pfn helper function that the different platforms can register for. We are
now doing that.

The bug-fixes cover some embarrassing struct pv_cpu_ops variables being set to NULL
on Xen (but not baremetal). We had a similar issue in the past with {write|read}_msr_safe
and this fills the three missing ones. The other bug-fix is to make the console output
(hvc) be capable of dealing with misbehaving backends and not fall flat on its face.
Lastly, a quirk for older XenBus implementations that came with an ancient v3.4
hypervisor (so RHEL5 based) - reading of certain non-existent attributes just hangs
the guest during bootup - so we take precaution of not doing that on such older
installations.

That is it. Please pull!


 arch/x86/xen/enlighten.c           |   18 +++++++++++++++-
 arch/x86/xen/mmu.c                 |   41 ++++++++++++++++++++++++++++++++++++
 drivers/tty/hvc/hvc_xen.c          |    5 +++-
 drivers/xen/xenbus/xenbus_xs.c     |   21 ++++++++++++++++++
 include/xen/interface/hvm/hvm_op.h |   19 ++++++++++++++++
 5 files changed, 102 insertions(+), 2 deletions(-)

David Vrabel (1):
      xen/hvc: handle backend CLOSED without CLOSING

Konrad Rzeszutek Wilk (3):
      xen/bootup: allow read_tscp call for Xen PV guests.
      xen/bootup: allow {read|write}_cr8 pvops call.
      xen/pv-on-hvm kexec: add quirk for Xen 3.4 and shutdown watches.

Olaf Hering (1):
      xen pv-on-hvm: add pfn_is_ram helper for kdump


--C7zPtVaVf+AK4Oqc
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJQeBYsAAoJEFjIrFwIi8fJ2xcIALBrvKBKAcp2u/Pv0ntqvotD
okU46cIqXVCShioKI6tlP4OwOGlGZo1XIWDQ4UGm8fh1PhogUXJ+uuRws7ELE9Bo
ouBbFTTr+OhdsOlX3+KPtJoKjbjneEIAMAS86i+zTYJ4JDL/B8p02+dn5WQTAiMy
wJ8ErbQqL8ByEyg058tTxc+/AbAKg+fbAeqndNKnMIAvFVCyITKvcP0ye9P7lqrH
IGfzBnNwJW38BqhjjpjPwZWEOfwjfPcePLRJAkoUm95K39pRqDiTDI/UMs2jqE7Z
jWKuXZuGACzW/lcPgGc8HUE6ol7MuOwg8Oz2odEl+pJ+l3b0gCqG4BkbQArcrrI=
=4iLS
-----END PGP SIGNATURE-----

--C7zPtVaVf+AK4Oqc--


--===============7689612060310045404==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7689612060310045404==--


From xen-devel-bounces@lists.xen.org Fri Oct 12 13:20:21 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 13:20:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMf9o-0000Wi-Jq; Fri, 12 Oct 2012 13:20:04 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMf9n-0000Wd-1B
	for xen-devel@lists.xensource.com; Fri, 12 Oct 2012 13:20:03 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1350047995!14410484!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODAwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10041 invoked from network); 12 Oct 2012 13:19:56 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Oct 2012 13:19:56 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9CDJrvT029382
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 12 Oct 2012 13:19:53 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9CDJqAO021075
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 12 Oct 2012 13:19:53 GMT
Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9CDJqN2006543; Fri, 12 Oct 2012 08:19:52 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Oct 2012 06:19:52 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 18DF940376; Fri, 12 Oct 2012 09:08:01 -0400 (EDT)
Date: Fri, 12 Oct 2012 09:08:01 -0400
From: Konrad Rzeszutek Wilk 
To: Linus Torvalds ,
	linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Message-ID: <20121012130800.GD32494@phenom.dumpdata.com>
MIME-Version: 1.0
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Subject: [Xen-devel] [GIT PULL] (xen) stable/for-linus-3.7-rc0-tag for
	v3.7-rc0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============7689612060310045404=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============7689612060310045404==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="C7zPtVaVf+AK4Oqc"
Content-Disposition: inline


--C7zPtVaVf+AK4Oqc
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hey Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-linus-3.7-rc0-tag

which has four bug-fixes and one tiny feature that I forgot to put initially in my tree
due to oversight.

The feature is for kdump kernels to speed up the /proc/vmcore reading. There is a
ram_is_pfn helper function that the different platforms can register for. We are
now doing that.

The bug-fixes cover some embarrassing struct pv_cpu_ops variables being set to NULL
on Xen (but not baremetal). We had a similar issue in the past with {write|read}_msr_safe
and this fills the three missing ones. The other bug-fix is to make the console output
(hvc) be capable of dealing with misbehaving backends and not fall flat on its face.
Lastly, a quirk for older XenBus implementations that came with an ancient v3.4
hypervisor (so RHEL5 based) - reading of certain non-existent attributes just hangs
the guest during bootup - so we take precaution of not doing that on such older
installations.

That is it. Please pull!


 arch/x86/xen/enlighten.c           |   18 +++++++++++++++-
 arch/x86/xen/mmu.c                 |   41 ++++++++++++++++++++++++++++++++++++
 drivers/tty/hvc/hvc_xen.c          |    5 +++-
 drivers/xen/xenbus/xenbus_xs.c     |   21 ++++++++++++++++++
 include/xen/interface/hvm/hvm_op.h |   19 ++++++++++++++++
 5 files changed, 102 insertions(+), 2 deletions(-)

David Vrabel (1):
      xen/hvc: handle backend CLOSED without CLOSING

Konrad Rzeszutek Wilk (3):
      xen/bootup: allow read_tscp call for Xen PV guests.
      xen/bootup: allow {read|write}_cr8 pvops call.
      xen/pv-on-hvm kexec: add quirk for Xen 3.4 and shutdown watches.

Olaf Hering (1):
      xen pv-on-hvm: add pfn_is_ram helper for kdump


--C7zPtVaVf+AK4Oqc
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJQeBYsAAoJEFjIrFwIi8fJ2xcIALBrvKBKAcp2u/Pv0ntqvotD
okU46cIqXVCShioKI6tlP4OwOGlGZo1XIWDQ4UGm8fh1PhogUXJ+uuRws7ELE9Bo
ouBbFTTr+OhdsOlX3+KPtJoKjbjneEIAMAS86i+zTYJ4JDL/B8p02+dn5WQTAiMy
wJ8ErbQqL8ByEyg058tTxc+/AbAKg+fbAeqndNKnMIAvFVCyITKvcP0ye9P7lqrH
IGfzBnNwJW38BqhjjpjPwZWEOfwjfPcePLRJAkoUm95K39pRqDiTDI/UMs2jqE7Z
jWKuXZuGACzW/lcPgGc8HUE6ol7MuOwg8Oz2odEl+pJ+l3b0gCqG4BkbQArcrrI=
=4iLS
-----END PGP SIGNATURE-----

--C7zPtVaVf+AK4Oqc--


--===============7689612060310045404==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7689612060310045404==--


From xen-devel-bounces@lists.xen.org Fri Oct 12 13:23:56 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 13:23:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMfDH-0000gF-GJ; Fri, 12 Oct 2012 13:23:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMfAr-0000bH-6U
	for xen-devel@lists.xensource.com; Fri, 12 Oct 2012 13:21:09 +0000
Received: from [85.158.143.99:59963] by server-2.bemta-4.messagelabs.com id
	29/56-25171-44918705; Fri, 12 Oct 2012 13:21:08 +0000
X-Env-Sender: will.deacon@arm.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1350048065!26356329!1
X-Originating-IP: [217.140.96.50]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20065 invoked from network); 12 Oct 2012 13:21:05 -0000
Received: from cam-admin0.cambridge.arm.com (HELO
	cam-admin0.cambridge.arm.com) (217.140.96.50)
	by server-11.tower-216.messagelabs.com with SMTP;
	12 Oct 2012 13:21:05 -0000
Received: from mudshark.cambridge.arm.com (mudshark.cambridge.arm.com
	[10.1.79.58])
	by cam-admin0.cambridge.arm.com (8.12.6/8.12.6) with ESMTP id
	q9CDKVE7018634; Fri, 12 Oct 2012 14:20:31 +0100 (BST)
Date: Fri, 12 Oct 2012 14:20:29 +0100
From: Will Deacon 
To: Arnd Bergmann 
Message-ID: <20121012132029.GC17399@mudshark.cambridge.arm.com>
References: <1349796183-30648-1-git-send-email-arnd@arndb.de>
	<20121009160814.GH4625@n2100.arm.linux.org.uk>
	<201210091840.25176.arnd@arndb.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <201210091840.25176.arnd@arndb.de>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Mailman-Approved-At: Fri, 12 Oct 2012 13:23:38 +0000
Cc: "mmarek@suse.cz" ,
	"dave.martin@linaro.org" ,
	"xen-devel@lists.xensource.com" ,
	Russell King - ARM Linux ,
	Jonathan Austin ,
	"konrad.wilk@oracle.com" ,
	Catalin Marinas ,
	"linus.walleij@linaro.org" ,
	"stefano.stabellini@eu.citrix.com" ,
	"sboyd@codeaurora.org" ,
	"linux-kernel@vger.kernel.org" ,
	"rjw@sisk.pl" , "damm@opensource.se" ,
	"jeremy@goop.org" ,
	"bryan.wu@canonical.com" ,
	"tglx@linutronix.de" ,
	Leif Lindholm ,
	"linux-arm-kernel@lists.infradead.org"
	
Subject: Re: [Xen-devel] [GIT PULL 0/9] ARM architecture fixes for 3.7
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Arnd, Russell,

On Tue, Oct 09, 2012 at 07:40:24PM +0100, Arnd Bergmann wrote:
> On Tuesday 09 October 2012, Russell King - ARM Linux wrote:
> > 
> > On Tue, Oct 09, 2012 at 05:22:54PM +0200, Arnd Bergmann wrote:
> > > Here are some patches that belong into your domain, I hope you can
> > > just send the lot to Linus the next time you send other patches.
> > > 
> > > These bug fixes all address problems found with automated build testing.
> > > Some of them have been around for a long time, other bugs are
> > > regressions since the merge window.
> > 
> > Apart from the sliced off comment in one commit (which XEN people need
> > to confirm they're happy with the final version), I think these are
> > otherwise fine... I'll hold off pulling them until that can be fixed.
> 
> Fixed that now, and I also added the Acks that I got in the meantime,
> changed the dependency from Xen on (CPU_v7 && !CPU_V6), and edited the
> description for patch 6 as Dave suggested.
> 
> 	Arnd
> 
> 8<---
> The following changes since commit 0e51793e162ca432fc5f04178cf82b80a92c2659:
> 
>   Merge branch 'for-linus' of git://git.linaro.org/people/rmk/linux-arm (2012-10-07 21:20:57 +0900)
> 
> are available in the git repository at:
> 
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/fixes-for-rmk
> 
> for you to fetch changes up to 8e7fc18b5eacc37b6e6fcf486ec4eafbfef91738:
> 
>   ARM: warnings in arch/arm/include/asm/uaccess.h (2012-10-09 20:29:07 +0200)

It would be good to see these for -rc1 if there's still time. I'm tired of
seeing patches to fix the export of the read_current_timer symbol!

Cheers,

Will

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 13:23:56 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 13:23:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMfDH-0000gF-GJ; Fri, 12 Oct 2012 13:23:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMfAr-0000bH-6U
	for xen-devel@lists.xensource.com; Fri, 12 Oct 2012 13:21:09 +0000
Received: from [85.158.143.99:59963] by server-2.bemta-4.messagelabs.com id
	29/56-25171-44918705; Fri, 12 Oct 2012 13:21:08 +0000
X-Env-Sender: will.deacon@arm.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1350048065!26356329!1
X-Originating-IP: [217.140.96.50]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20065 invoked from network); 12 Oct 2012 13:21:05 -0000
Received: from cam-admin0.cambridge.arm.com (HELO
	cam-admin0.cambridge.arm.com) (217.140.96.50)
	by server-11.tower-216.messagelabs.com with SMTP;
	12 Oct 2012 13:21:05 -0000
Received: from mudshark.cambridge.arm.com (mudshark.cambridge.arm.com
	[10.1.79.58])
	by cam-admin0.cambridge.arm.com (8.12.6/8.12.6) with ESMTP id
	q9CDKVE7018634; Fri, 12 Oct 2012 14:20:31 +0100 (BST)
Date: Fri, 12 Oct 2012 14:20:29 +0100
From: Will Deacon 
To: Arnd Bergmann 
Message-ID: <20121012132029.GC17399@mudshark.cambridge.arm.com>
References: <1349796183-30648-1-git-send-email-arnd@arndb.de>
	<20121009160814.GH4625@n2100.arm.linux.org.uk>
	<201210091840.25176.arnd@arndb.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <201210091840.25176.arnd@arndb.de>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Mailman-Approved-At: Fri, 12 Oct 2012 13:23:38 +0000
Cc: "mmarek@suse.cz" ,
	"dave.martin@linaro.org" ,
	"xen-devel@lists.xensource.com" ,
	Russell King - ARM Linux ,
	Jonathan Austin ,
	"konrad.wilk@oracle.com" ,
	Catalin Marinas ,
	"linus.walleij@linaro.org" ,
	"stefano.stabellini@eu.citrix.com" ,
	"sboyd@codeaurora.org" ,
	"linux-kernel@vger.kernel.org" ,
	"rjw@sisk.pl" , "damm@opensource.se" ,
	"jeremy@goop.org" ,
	"bryan.wu@canonical.com" ,
	"tglx@linutronix.de" ,
	Leif Lindholm ,
	"linux-arm-kernel@lists.infradead.org"
	
Subject: Re: [Xen-devel] [GIT PULL 0/9] ARM architecture fixes for 3.7
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Arnd, Russell,

On Tue, Oct 09, 2012 at 07:40:24PM +0100, Arnd Bergmann wrote:
> On Tuesday 09 October 2012, Russell King - ARM Linux wrote:
> > 
> > On Tue, Oct 09, 2012 at 05:22:54PM +0200, Arnd Bergmann wrote:
> > > Here are some patches that belong into your domain, I hope you can
> > > just send the lot to Linus the next time you send other patches.
> > > 
> > > These bug fixes all address problems found with automated build testing.
> > > Some of them have been around for a long time, other bugs are
> > > regressions since the merge window.
> > 
> > Apart from the sliced off comment in one commit (which XEN people need
> > to confirm they're happy with the final version), I think these are
> > otherwise fine... I'll hold off pulling them until that can be fixed.
> 
> Fixed that now, and I also added the Acks that I got in the meantime,
> changed the dependency from Xen on (CPU_v7 && !CPU_V6), and edited the
> description for patch 6 as Dave suggested.
> 
> 	Arnd
> 
> 8<---
> The following changes since commit 0e51793e162ca432fc5f04178cf82b80a92c2659:
> 
>   Merge branch 'for-linus' of git://git.linaro.org/people/rmk/linux-arm (2012-10-07 21:20:57 +0900)
> 
> are available in the git repository at:
> 
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/fixes-for-rmk
> 
> for you to fetch changes up to 8e7fc18b5eacc37b6e6fcf486ec4eafbfef91738:
> 
>   ARM: warnings in arch/arm/include/asm/uaccess.h (2012-10-09 20:29:07 +0200)

It would be good to see these for -rc1 if there's still time. I'm tired of
seeing patches to fix the export of the read_current_timer symbol!

Cheers,

Will

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 13:29:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 13:29:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMfIo-0000r2-8u; Fri, 12 Oct 2012 13:29:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMfIm-0000qx-QI
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 13:29:21 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1350048553!13031802!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODAwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16254 invoked from network); 12 Oct 2012 13:29:14 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Oct 2012 13:29:14 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9CDTBWi006703
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 12 Oct 2012 13:29:11 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9CDTA91005654
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 12 Oct 2012 13:29:11 GMT
Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9CDTA5O002297; Fri, 12 Oct 2012 08:29:10 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Oct 2012 06:29:10 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 97ABB40376; Fri, 12 Oct 2012 09:17:19 -0400 (EDT)
Date: Fri, 12 Oct 2012 09:17:19 -0400
From: Konrad Rzeszutek Wilk 
To: Ian Campbell 
Message-ID: <20121012131719.GF32494@phenom.dumpdata.com>
References: <1350037688.14806.93.camel@zakaz.uk.xensource.com>
	<20121012115949.GB4028@localhost.localdomain>
	<20121012121049.GB4155@localhost.localdomain>
	<1350044296.14806.100.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1350044296.14806.100.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel 
Subject: Re: [Xen-devel] Dom0 physical networking/swiotlb/something issue in
	3.7-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 12, 2012 at 01:18:16PM +0100, Ian Campbell wrote:
> On Fri, 2012-10-12 at 13:10 +0100, Konrad Rzeszutek Wilk wrote:
> > On Fri, Oct 12, 2012 at 07:59:49AM -0400, Konrad Rzeszutek Wilk wrote:
> > > On Fri, Oct 12, 2012 at 11:28:08AM +0100, Ian Campbell wrote:
> > > > Hi Konrad,
> > > > 
> > > > The following patch causes fairly large packet loss when transmitting
> > > > from dom0 to the physical network, at least with my tg3 hardware, but I
> > > > assume it can impact anything which uses this interface.
> > > 
> > > Ah, that would explain why one of my machines suddenly started
> > > developing checksum errors (and had a tg3 card). I hadn't gotten
> > > deep into it.
> > > > 
> > > > I suspect that the issue is that the compound pages allocated in this
> > > > way are not backed by contiguous mfns and so things fall apart when the
> > > > driver tries to do DMA.
> > > 
> > > So this should also be easily reproduced on barmetal with 'iommu=soft' then.
> > > > 
> > > > However I don't understand why the swiotlb is not fixing this up
> > > > successfully? The tg3 driver seems to use pci_map_single on this data.
> > > > Any thoughts? Perhaps the swiotlb (either generically or in the Xen
> > > > backend) doesn't correctly handle compound pages?
> > > 
> > > The assumption is that it is just a page. I am surprsed that the other
> > > IOMMUs aren't hitting this as well - ah, that is b/c they do handle
> > > a virtual address of more than one PAGE_SIZE..
> > 
> > So.. the GART one (AMD poor man IOTLB - was used for AGP card
> > translation, but can still be used as an IOMMU - and is still present on
> > some AMD machines), looks to suffer the same problem.
> > 
> > But perhaps not - can you explain to me if a compound page
> > is virtually contingous? One of the things the GART does for
> > pci_map_single is call page_to_phys(p), feeds the CPU physical address
> > (and size) into the GART engine to setup the mapping.
> > 
> > If compound pages are virtually (and physically on barmetal) contingous
> > - this ought to work. But if they are not, then this should also break on
> > AMD machines with tg3 and a AMD GART enabled.
> 
> AFAIK compound pages are always physically contiguous. i.e. given a
> "struct page *page" which is the head of a compound page you can do
> "page++" to walk through its constituent frames.
> 
> I'm not sure about virtually contiguous. Obviously if they are in lowmem
> then the 1-1 map combined with the fact that they are physically
> contiguous makes them virtually contiguous too. I'm not sure what
> happens if they are highmem -- since kmap (or whatever) would need to do
> some extra work in this case. I've not looked but I don't recall
> noticing this in the past...

I think it also depends on how they are allocated - if your use GFP_DMA32
they will be in lowmem. And since the networking is using that by default
they would be in the 1-1 map.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 13:29:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 13:29:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMfIo-0000r2-8u; Fri, 12 Oct 2012 13:29:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMfIm-0000qx-QI
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 13:29:21 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1350048553!13031802!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODAwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16254 invoked from network); 12 Oct 2012 13:29:14 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Oct 2012 13:29:14 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9CDTBWi006703
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 12 Oct 2012 13:29:11 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9CDTA91005654
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 12 Oct 2012 13:29:11 GMT
Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9CDTA5O002297; Fri, 12 Oct 2012 08:29:10 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Oct 2012 06:29:10 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 97ABB40376; Fri, 12 Oct 2012 09:17:19 -0400 (EDT)
Date: Fri, 12 Oct 2012 09:17:19 -0400
From: Konrad Rzeszutek Wilk 
To: Ian Campbell 
Message-ID: <20121012131719.GF32494@phenom.dumpdata.com>
References: <1350037688.14806.93.camel@zakaz.uk.xensource.com>
	<20121012115949.GB4028@localhost.localdomain>
	<20121012121049.GB4155@localhost.localdomain>
	<1350044296.14806.100.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1350044296.14806.100.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel 
Subject: Re: [Xen-devel] Dom0 physical networking/swiotlb/something issue in
	3.7-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 12, 2012 at 01:18:16PM +0100, Ian Campbell wrote:
> On Fri, 2012-10-12 at 13:10 +0100, Konrad Rzeszutek Wilk wrote:
> > On Fri, Oct 12, 2012 at 07:59:49AM -0400, Konrad Rzeszutek Wilk wrote:
> > > On Fri, Oct 12, 2012 at 11:28:08AM +0100, Ian Campbell wrote:
> > > > Hi Konrad,
> > > > 
> > > > The following patch causes fairly large packet loss when transmitting
> > > > from dom0 to the physical network, at least with my tg3 hardware, but I
> > > > assume it can impact anything which uses this interface.
> > > 
> > > Ah, that would explain why one of my machines suddenly started
> > > developing checksum errors (and had a tg3 card). I hadn't gotten
> > > deep into it.
> > > > 
> > > > I suspect that the issue is that the compound pages allocated in this
> > > > way are not backed by contiguous mfns and so things fall apart when the
> > > > driver tries to do DMA.
> > > 
> > > So this should also be easily reproduced on barmetal with 'iommu=soft' then.
> > > > 
> > > > However I don't understand why the swiotlb is not fixing this up
> > > > successfully? The tg3 driver seems to use pci_map_single on this data.
> > > > Any thoughts? Perhaps the swiotlb (either generically or in the Xen
> > > > backend) doesn't correctly handle compound pages?
> > > 
> > > The assumption is that it is just a page. I am surprsed that the other
> > > IOMMUs aren't hitting this as well - ah, that is b/c they do handle
> > > a virtual address of more than one PAGE_SIZE..
> > 
> > So.. the GART one (AMD poor man IOTLB - was used for AGP card
> > translation, but can still be used as an IOMMU - and is still present on
> > some AMD machines), looks to suffer the same problem.
> > 
> > But perhaps not - can you explain to me if a compound page
> > is virtually contingous? One of the things the GART does for
> > pci_map_single is call page_to_phys(p), feeds the CPU physical address
> > (and size) into the GART engine to setup the mapping.
> > 
> > If compound pages are virtually (and physically on barmetal) contingous
> > - this ought to work. But if they are not, then this should also break on
> > AMD machines with tg3 and a AMD GART enabled.
> 
> AFAIK compound pages are always physically contiguous. i.e. given a
> "struct page *page" which is the head of a compound page you can do
> "page++" to walk through its constituent frames.
> 
> I'm not sure about virtually contiguous. Obviously if they are in lowmem
> then the 1-1 map combined with the fact that they are physically
> contiguous makes them virtually contiguous too. I'm not sure what
> happens if they are highmem -- since kmap (or whatever) would need to do
> some extra work in this case. I've not looked but I don't recall
> noticing this in the past...

I think it also depends on how they are allocated - if your use GFP_DMA32
they will be in lowmem. And since the networking is using that by default
they would be in the 1-1 map.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 13:54:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 13:54:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMfgP-00012N-BO; Fri, 12 Oct 2012 13:53:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMfgN-00012I-HE
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 13:53:43 +0000
Received: from [85.158.137.99:55791] by server-8.bemta-3.messagelabs.com id
	F5/35-10525-6E028705; Fri, 12 Oct 2012 13:53:42 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1350050020!16617190!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29993 invoked from network); 12 Oct 2012 13:53:41 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 13:53:41 -0000
Received: by mail-vc0-f173.google.com with SMTP id fl15so4376282vcb.32
	for ; Fri, 12 Oct 2012 06:53:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=pe+rIc+sAVkjOMZukdfx6LrxShSabVewsbpoIHItCOc=;
	b=tONfT4rMFIQvTFrZeNKeen8nOghut+gWby8Qynj4eMIvyOJI1OomSia09Me727LjU0
	KeaTIo+rqUs8wAUpQV2kzhzQcdBzhQg5tO3pBcwFjn0AglxJ9stUIoFtLu3e0ZvxapOH
	AWAKQKEYtAP8EY/AywOeZZFfemfpereEL+EpSGGbujXUcLYu0v0sYAj3wVNXLm+nJ7D8
	+HZ8G5oKO88IOVa7VM2jrr4NfEriaR9NC6w8csan+GhHxg+F9Odmoog4ZldoM+DrbehU
	K4Ub1AjKCu+jhAxYeqhWYfob9MWRjG8FIFFjFRw0PucksiLKaeAfQjvUoyDJivGVyHww
	0XAQ==
Received: by 10.52.27.82 with SMTP id r18mr2058391vdg.120.1350050020359;
	Fri, 12 Oct 2012 06:53:40 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id r17sm1020298vdj.12.2012.10.12.06.53.39
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 12 Oct 2012 06:53:40 -0700 (PDT)
Date: Fri, 12 Oct 2012 09:41:47 -0400
From: Konrad Rzeszutek Wilk 
To: David Vrabel 
Message-ID: <20121012134147.GA11778@phenom.dumpdata.com>
References: <1350046634-2462-1-git-send-email-david.vrabel@citrix.com>
	<1350046634-2462-4-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1350046634-2462-4-git-send-email-david.vrabel@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Konrad Rzeszutek Wilk , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3/3] xen/privcmd: add
 IOCTL_PRIVCMD_SYNC_WALLCLOCK to sync Xen's wallclock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 12, 2012 at 01:57:14PM +0100, David Vrabel wrote:
> From: David Vrabel 
> 
> Add a new ioctl to synchronize Xen's wallclock with the current system
> time.
> 
> This may be used by the tools to ensure that newly created domains see
> the correct wallclock time if NTP is not used in dom0 or if domains
> are started before NTP has synchronized.

So... how does this work with NTPD? As in does ntpd _not_ update the
hwclock enough?


> 
> Signed-off-by: David Vrabel 
> ---
>  arch/x86/xen/time.c   |   25 ++++++++++++++++++-------
>  drivers/xen/privcmd.c |   12 ++++++++++++
>  include/xen/privcmd.h |    8 ++++++++
>  include/xen/xen-ops.h |    2 ++
>  4 files changed, 40 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
> index 11770d0..d481ac9 100644
> --- a/arch/x86/xen/time.c
> +++ b/arch/x86/xen/time.c
> @@ -8,6 +8,7 @@
>   * Jeremy Fitzhardinge , XenSource Inc, 2007
>   */
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -192,6 +193,19 @@ static void xen_read_wallclock(struct timespec *ts)
>  	put_cpu_var(xen_vcpu);
>  }
>  
> +int xen_write_wallclock(const struct timespec *ts)
> +{
> +	struct xen_platform_op op;
> +
> +	op.cmd = XENPF_settime;
> +	op.u.settime.secs = ts->tv_sec;
> +	op.u.settime.nsecs = ts->tv_nsec;
> +	op.u.settime.system_time = xen_clocksource_read();
> +
> +	return HYPERVISOR_dom0_op(&op);
> +}
> +EXPORT_SYMBOL_GPL(xen_write_wallclock);
> +
>  static unsigned long xen_get_wallclock(void)
>  {
>  	struct timespec ts;
> @@ -202,7 +216,7 @@ static unsigned long xen_get_wallclock(void)
>  
>  static int xen_set_wallclock(unsigned long now)
>  {
> -	struct xen_platform_op op;
> +	struct timespec ts;
>  	int rc;
>  
>  	/* do nothing for domU */
> @@ -218,12 +232,9 @@ static int xen_set_wallclock(unsigned long now)
>  	 * update_persistent_wallclock() is called ~500 ms after 'now'
>  	 * so add an extra 500 ms.
>  	 */
> -	op.cmd = XENPF_settime;
> -	op.u.settime.secs = now;
> -	op.u.settime.nsecs = NSEC_PER_SEC / 2;
> -	op.u.settime.system_time = xen_clocksource_read();
> -
> -	rc = HYPERVISOR_dom0_op(&op);
> +	ts.tv_sec = now;
> +	ts.tv_nsec = NSEC_PER_SEC / 2;
> +	rc = xen_write_wallclock(&ts);
>  	WARN(rc != 0, "XENPF_settime failed: now=%ld\n", now);
>  
>  	return rc;
> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> index ccee0f1..ed2caf3 100644
> --- a/drivers/xen/privcmd.c
> +++ b/drivers/xen/privcmd.c
> @@ -338,6 +338,14 @@ out:
>  	return ret;
>  }
>  
> +static long privcmd_ioctl_sync_wallclock(void)
> +{
> +	struct timespec ts;
> +
> +	getnstimeofday(&ts);
> +	return xen_write_wallclock(&ts);
> +}
> +
>  static long privcmd_ioctl(struct file *file,
>  			  unsigned int cmd, unsigned long data)
>  {
> @@ -357,6 +365,10 @@ static long privcmd_ioctl(struct file *file,
>  		ret = privcmd_ioctl_mmap_batch(udata);
>  		break;
>  
> +	case IOCTL_PRIVCMD_SYNC_WALLCLOCK:
> +		ret = privcmd_ioctl_sync_wallclock();
> +		break;
> +
>  	default:
>  		ret = -EINVAL;
>  		break;
> diff --git a/include/xen/privcmd.h b/include/xen/privcmd.h
> index 17857fb..d17d087 100644
> --- a/include/xen/privcmd.h
> +++ b/include/xen/privcmd.h
> @@ -66,6 +66,12 @@ struct privcmd_mmapbatch {
>   * @cmd: IOCTL_PRIVCMD_HYPERCALL
>   * @arg: &privcmd_hypercall_t
>   * Return: Value returned from execution of the specified hypercall.
> + *
> + * @cmd: IOCTL_PRIVCMD_SYNC_WALLCLOCK
> + * @arg: Unused.
> + * Synchronizes the Xen wallclock with the current system time.
> + * Return: 0 on success, or -1 on error with errno set to EPERM or
> + * EACCES.
>   */
>  #define IOCTL_PRIVCMD_HYPERCALL					\
>  	_IOC(_IOC_NONE, 'P', 0, sizeof(struct privcmd_hypercall))
> @@ -73,5 +79,7 @@ struct privcmd_mmapbatch {
>  	_IOC(_IOC_NONE, 'P', 2, sizeof(struct privcmd_mmap))
>  #define IOCTL_PRIVCMD_MMAPBATCH					\
>  	_IOC(_IOC_NONE, 'P', 3, sizeof(struct privcmd_mmapbatch))
> +#define IOCTL_PRIVCMD_SYNC_WALLCLOCK				\
> +	_IOC(_IOC_NONE, 'P', 5, 0)
>  
>  #endif /* __LINUX_PUBLIC_PRIVCMD_H__ */
> diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
> index 6a198e4..eefed22 100644
> --- a/include/xen/xen-ops.h
> +++ b/include/xen/xen-ops.h
> @@ -29,4 +29,6 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
>  			       unsigned long mfn, int nr,
>  			       pgprot_t prot, unsigned domid);
>  
> +int xen_write_wallclock(const struct timespec *ts);
> +
>  #endif /* INCLUDE_XEN_OPS_H */
> -- 
> 1.7.2.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 13:54:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 13:54:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMfgP-00012N-BO; Fri, 12 Oct 2012 13:53:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMfgN-00012I-HE
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 13:53:43 +0000
Received: from [85.158.137.99:55791] by server-8.bemta-3.messagelabs.com id
	F5/35-10525-6E028705; Fri, 12 Oct 2012 13:53:42 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1350050020!16617190!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29993 invoked from network); 12 Oct 2012 13:53:41 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 13:53:41 -0000
Received: by mail-vc0-f173.google.com with SMTP id fl15so4376282vcb.32
	for ; Fri, 12 Oct 2012 06:53:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=pe+rIc+sAVkjOMZukdfx6LrxShSabVewsbpoIHItCOc=;
	b=tONfT4rMFIQvTFrZeNKeen8nOghut+gWby8Qynj4eMIvyOJI1OomSia09Me727LjU0
	KeaTIo+rqUs8wAUpQV2kzhzQcdBzhQg5tO3pBcwFjn0AglxJ9stUIoFtLu3e0ZvxapOH
	AWAKQKEYtAP8EY/AywOeZZFfemfpereEL+EpSGGbujXUcLYu0v0sYAj3wVNXLm+nJ7D8
	+HZ8G5oKO88IOVa7VM2jrr4NfEriaR9NC6w8csan+GhHxg+F9Odmoog4ZldoM+DrbehU
	K4Ub1AjKCu+jhAxYeqhWYfob9MWRjG8FIFFjFRw0PucksiLKaeAfQjvUoyDJivGVyHww
	0XAQ==
Received: by 10.52.27.82 with SMTP id r18mr2058391vdg.120.1350050020359;
	Fri, 12 Oct 2012 06:53:40 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id r17sm1020298vdj.12.2012.10.12.06.53.39
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 12 Oct 2012 06:53:40 -0700 (PDT)
Date: Fri, 12 Oct 2012 09:41:47 -0400
From: Konrad Rzeszutek Wilk 
To: David Vrabel 
Message-ID: <20121012134147.GA11778@phenom.dumpdata.com>
References: <1350046634-2462-1-git-send-email-david.vrabel@citrix.com>
	<1350046634-2462-4-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1350046634-2462-4-git-send-email-david.vrabel@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Konrad Rzeszutek Wilk , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3/3] xen/privcmd: add
 IOCTL_PRIVCMD_SYNC_WALLCLOCK to sync Xen's wallclock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 12, 2012 at 01:57:14PM +0100, David Vrabel wrote:
> From: David Vrabel 
> 
> Add a new ioctl to synchronize Xen's wallclock with the current system
> time.
> 
> This may be used by the tools to ensure that newly created domains see
> the correct wallclock time if NTP is not used in dom0 or if domains
> are started before NTP has synchronized.

So... how does this work with NTPD? As in does ntpd _not_ update the
hwclock enough?


> 
> Signed-off-by: David Vrabel 
> ---
>  arch/x86/xen/time.c   |   25 ++++++++++++++++++-------
>  drivers/xen/privcmd.c |   12 ++++++++++++
>  include/xen/privcmd.h |    8 ++++++++
>  include/xen/xen-ops.h |    2 ++
>  4 files changed, 40 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
> index 11770d0..d481ac9 100644
> --- a/arch/x86/xen/time.c
> +++ b/arch/x86/xen/time.c
> @@ -8,6 +8,7 @@
>   * Jeremy Fitzhardinge , XenSource Inc, 2007
>   */
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -192,6 +193,19 @@ static void xen_read_wallclock(struct timespec *ts)
>  	put_cpu_var(xen_vcpu);
>  }
>  
> +int xen_write_wallclock(const struct timespec *ts)
> +{
> +	struct xen_platform_op op;
> +
> +	op.cmd = XENPF_settime;
> +	op.u.settime.secs = ts->tv_sec;
> +	op.u.settime.nsecs = ts->tv_nsec;
> +	op.u.settime.system_time = xen_clocksource_read();
> +
> +	return HYPERVISOR_dom0_op(&op);
> +}
> +EXPORT_SYMBOL_GPL(xen_write_wallclock);
> +
>  static unsigned long xen_get_wallclock(void)
>  {
>  	struct timespec ts;
> @@ -202,7 +216,7 @@ static unsigned long xen_get_wallclock(void)
>  
>  static int xen_set_wallclock(unsigned long now)
>  {
> -	struct xen_platform_op op;
> +	struct timespec ts;
>  	int rc;
>  
>  	/* do nothing for domU */
> @@ -218,12 +232,9 @@ static int xen_set_wallclock(unsigned long now)
>  	 * update_persistent_wallclock() is called ~500 ms after 'now'
>  	 * so add an extra 500 ms.
>  	 */
> -	op.cmd = XENPF_settime;
> -	op.u.settime.secs = now;
> -	op.u.settime.nsecs = NSEC_PER_SEC / 2;
> -	op.u.settime.system_time = xen_clocksource_read();
> -
> -	rc = HYPERVISOR_dom0_op(&op);
> +	ts.tv_sec = now;
> +	ts.tv_nsec = NSEC_PER_SEC / 2;
> +	rc = xen_write_wallclock(&ts);
>  	WARN(rc != 0, "XENPF_settime failed: now=%ld\n", now);
>  
>  	return rc;
> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> index ccee0f1..ed2caf3 100644
> --- a/drivers/xen/privcmd.c
> +++ b/drivers/xen/privcmd.c
> @@ -338,6 +338,14 @@ out:
>  	return ret;
>  }
>  
> +static long privcmd_ioctl_sync_wallclock(void)
> +{
> +	struct timespec ts;
> +
> +	getnstimeofday(&ts);
> +	return xen_write_wallclock(&ts);
> +}
> +
>  static long privcmd_ioctl(struct file *file,
>  			  unsigned int cmd, unsigned long data)
>  {
> @@ -357,6 +365,10 @@ static long privcmd_ioctl(struct file *file,
>  		ret = privcmd_ioctl_mmap_batch(udata);
>  		break;
>  
> +	case IOCTL_PRIVCMD_SYNC_WALLCLOCK:
> +		ret = privcmd_ioctl_sync_wallclock();
> +		break;
> +
>  	default:
>  		ret = -EINVAL;
>  		break;
> diff --git a/include/xen/privcmd.h b/include/xen/privcmd.h
> index 17857fb..d17d087 100644
> --- a/include/xen/privcmd.h
> +++ b/include/xen/privcmd.h
> @@ -66,6 +66,12 @@ struct privcmd_mmapbatch {
>   * @cmd: IOCTL_PRIVCMD_HYPERCALL
>   * @arg: &privcmd_hypercall_t
>   * Return: Value returned from execution of the specified hypercall.
> + *
> + * @cmd: IOCTL_PRIVCMD_SYNC_WALLCLOCK
> + * @arg: Unused.
> + * Synchronizes the Xen wallclock with the current system time.
> + * Return: 0 on success, or -1 on error with errno set to EPERM or
> + * EACCES.
>   */
>  #define IOCTL_PRIVCMD_HYPERCALL					\
>  	_IOC(_IOC_NONE, 'P', 0, sizeof(struct privcmd_hypercall))
> @@ -73,5 +79,7 @@ struct privcmd_mmapbatch {
>  	_IOC(_IOC_NONE, 'P', 2, sizeof(struct privcmd_mmap))
>  #define IOCTL_PRIVCMD_MMAPBATCH					\
>  	_IOC(_IOC_NONE, 'P', 3, sizeof(struct privcmd_mmapbatch))
> +#define IOCTL_PRIVCMD_SYNC_WALLCLOCK				\
> +	_IOC(_IOC_NONE, 'P', 5, 0)
>  
>  #endif /* __LINUX_PUBLIC_PRIVCMD_H__ */
> diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
> index 6a198e4..eefed22 100644
> --- a/include/xen/xen-ops.h
> +++ b/include/xen/xen-ops.h
> @@ -29,4 +29,6 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
>  			       unsigned long mfn, int nr,
>  			       pgprot_t prot, unsigned domid);
>  
> +int xen_write_wallclock(const struct timespec *ts);
> +
>  #endif /* INCLUDE_XEN_OPS_H */
> -- 
> 1.7.2.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 13:57:45 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 13:57:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMfk3-00018w-W1; Fri, 12 Oct 2012 13:57:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMfk2-00018q-MF
	for xen-devel@lists.xensource.com; Fri, 12 Oct 2012 13:57:30 +0000
Received: from [85.158.138.51:4272] by server-7.bemta-3.messagelabs.com id
	AE/74-06991-9C128705; Fri, 12 Oct 2012 13:57:29 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1350050247!26063710!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODAwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32605 invoked from network); 12 Oct 2012 13:57:29 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Oct 2012 13:57:29 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9CDvNm7010333
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 12 Oct 2012 13:57:24 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9CDvMOQ002296
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 12 Oct 2012 13:57:23 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9CDvMO5024413; Fri, 12 Oct 2012 08:57:22 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Oct 2012 06:57:22 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2927C40376; Fri, 12 Oct 2012 09:45:30 -0400 (EDT)
Date: Fri, 12 Oct 2012 09:45:30 -0400
From: Konrad Rzeszutek Wilk 
To: Linus Torvalds ,
	linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Message-ID: <20121012134529.GA1560@phenom.dumpdata.com>
MIME-Version: 1.0
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Subject: [Xen-devel] [GIT PULL] (xen) stable/for-linus-3.7-uapi-tag for
	v3.7-rc0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============6709417335124633431=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============6709417335124633431==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="+HP7ph2BbKc20aGI"
Content-Disposition: inline


--+HP7ph2BbKc20aGI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hey Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-linus-3.7-uapi-tag

which has the UAPI disintegration work done by David Howells.

Please pull!

 include/uapi/xen/Kbuild    |    2 +
 include/uapi/xen/evtchn.h  |   88 +++++++++++++++++++++++++++++++++++++++
 include/uapi/xen/privcmd.h |   98 ++++++++++++++++++++++++++++++++++++++++++++
 include/xen/Kbuild         |    2 -
 include/xen/evtchn.h       |   88 ---------------------------------------
 include/xen/privcmd.h      |   98 --------------------------------------------
 6 files changed, 188 insertions(+), 188 deletions(-)

David Howells (1):
      UAPI: (Scripted) Disintegrate include/xen


--+HP7ph2BbKc20aGI
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJQeB71AAoJEFjIrFwIi8fJSwoH/Akc2Xbe7KNox4qsrIcpCFdm
QBsdNbH/VCU5IToc7hPpjobD2Zt/JDCjUNFpVwnxjUAQLfqgAvu/ifceFJVQS5zy
YCpuyqcknThVaRvfonx7sp/omXKm9XIQiGAnUGs8XscSP8x6SZlYCD1NxbtiZdY+
dSleBgcPaoW2fVmEqQVp11F5UOOeMeJ9HdWcemd3VcmL9r+73nbOTHWQwX+V+jgj
FFi/ZDdvIywwi7Z/I5FuijtxeWbE6xd+kfsf+gUwb2DUE8SZPV7rE2VApi5N5vEr
tqd0pNCHy0IW8qWRpO0cMtB0vbmYd5Yyg+YlMphMQoSPaJ32VAVOI9eLBHuUFNA=
=y67z
-----END PGP SIGNATURE-----

--+HP7ph2BbKc20aGI--


--===============6709417335124633431==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6709417335124633431==--


From xen-devel-bounces@lists.xen.org Fri Oct 12 13:57:45 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 13:57:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMfk3-00018w-W1; Fri, 12 Oct 2012 13:57:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMfk2-00018q-MF
	for xen-devel@lists.xensource.com; Fri, 12 Oct 2012 13:57:30 +0000
Received: from [85.158.138.51:4272] by server-7.bemta-3.messagelabs.com id
	AE/74-06991-9C128705; Fri, 12 Oct 2012 13:57:29 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1350050247!26063710!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODAwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32605 invoked from network); 12 Oct 2012 13:57:29 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Oct 2012 13:57:29 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9CDvNm7010333
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 12 Oct 2012 13:57:24 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9CDvMOQ002296
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 12 Oct 2012 13:57:23 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9CDvMO5024413; Fri, 12 Oct 2012 08:57:22 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Oct 2012 06:57:22 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2927C40376; Fri, 12 Oct 2012 09:45:30 -0400 (EDT)
Date: Fri, 12 Oct 2012 09:45:30 -0400
From: Konrad Rzeszutek Wilk 
To: Linus Torvalds ,
	linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Message-ID: <20121012134529.GA1560@phenom.dumpdata.com>
MIME-Version: 1.0
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Subject: [Xen-devel] [GIT PULL] (xen) stable/for-linus-3.7-uapi-tag for
	v3.7-rc0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============6709417335124633431=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============6709417335124633431==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="+HP7ph2BbKc20aGI"
Content-Disposition: inline


--+HP7ph2BbKc20aGI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hey Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-linus-3.7-uapi-tag

which has the UAPI disintegration work done by David Howells.

Please pull!

 include/uapi/xen/Kbuild    |    2 +
 include/uapi/xen/evtchn.h  |   88 +++++++++++++++++++++++++++++++++++++++
 include/uapi/xen/privcmd.h |   98 ++++++++++++++++++++++++++++++++++++++++++++
 include/xen/Kbuild         |    2 -
 include/xen/evtchn.h       |   88 ---------------------------------------
 include/xen/privcmd.h      |   98 --------------------------------------------
 6 files changed, 188 insertions(+), 188 deletions(-)

David Howells (1):
      UAPI: (Scripted) Disintegrate include/xen


--+HP7ph2BbKc20aGI
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJQeB71AAoJEFjIrFwIi8fJSwoH/Akc2Xbe7KNox4qsrIcpCFdm
QBsdNbH/VCU5IToc7hPpjobD2Zt/JDCjUNFpVwnxjUAQLfqgAvu/ifceFJVQS5zy
YCpuyqcknThVaRvfonx7sp/omXKm9XIQiGAnUGs8XscSP8x6SZlYCD1NxbtiZdY+
dSleBgcPaoW2fVmEqQVp11F5UOOeMeJ9HdWcemd3VcmL9r+73nbOTHWQwX+V+jgj
FFi/ZDdvIywwi7Z/I5FuijtxeWbE6xd+kfsf+gUwb2DUE8SZPV7rE2VApi5N5vEr
tqd0pNCHy0IW8qWRpO0cMtB0vbmYd5Yyg+YlMphMQoSPaJ32VAVOI9eLBHuUFNA=
=y67z
-----END PGP SIGNATURE-----

--+HP7ph2BbKc20aGI--


--===============6709417335124633431==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6709417335124633431==--


From xen-devel-bounces@lists.xen.org Fri Oct 12 14:02:49 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 14:02:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMfou-0001Nf-Mk; Fri, 12 Oct 2012 14:02:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMfot-0001NZ-Cg
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 14:02:31 +0000
Received: from [85.158.139.211:22884] by server-15.bemta-5.messagelabs.com id
	52/28-27811-6F228705; Fri, 12 Oct 2012 14:02:30 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1350050548!22096289!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYwMjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28012 invoked from network); 12 Oct 2012 14:02:29 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 14:02:29 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="41030540"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 14:02:23 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 12 Oct 2012
	10:02:23 -0400
Message-ID: <507822ED.2090900@citrix.com>
Date: Fri, 12 Oct 2012 15:02:21 +0100
From: David Vrabel 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk 
References: <1350046634-2462-1-git-send-email-david.vrabel@citrix.com>
	<1350046634-2462-4-git-send-email-david.vrabel@citrix.com>
	<20121012134147.GA11778@phenom.dumpdata.com>
In-Reply-To: <20121012134147.GA11778@phenom.dumpdata.com>
Cc: Konrad Rzeszutek Wilk ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 3/3] xen/privcmd: add
 IOCTL_PRIVCMD_SYNC_WALLCLOCK to sync Xen's wallclock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/10/12 14:41, Konrad Rzeszutek Wilk wrote:
> On Fri, Oct 12, 2012 at 01:57:14PM +0100, David Vrabel wrote:
>> From: David Vrabel 
>>
>> Add a new ioctl to synchronize Xen's wallclock with the current system
>> time.
>>
>> This may be used by the tools to ensure that newly created domains see
>> the correct wallclock time if NTP is not used in dom0 or if domains
>> are started before NTP has synchronized.
> 
> So... how does this work with NTPD? As in does ntpd _not_ update the
> hwclock enough?

Once NTPD is synchronized then the kernel updates the wallclock (and the
RTC with patch #1) every 11 mins.  I assume this is often enough given
how NTP adjusts the system time.

You only really need the tools to sync wallclock if system time was
stepped at start of day.  e.g., init scripts could do something like:

ntpdate pool.ntp.org
hwclock --systohc
xen-wallclock --systowc

David

>> Signed-off-by: David Vrabel 
>> ---
>>  arch/x86/xen/time.c   |   25 ++++++++++++++++++-------
>>  drivers/xen/privcmd.c |   12 ++++++++++++
>>  include/xen/privcmd.h |    8 ++++++++
>>  include/xen/xen-ops.h |    2 ++
>>  4 files changed, 40 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
>> index 11770d0..d481ac9 100644
>> --- a/arch/x86/xen/time.c
>> +++ b/arch/x86/xen/time.c
>> @@ -8,6 +8,7 @@
>>   * Jeremy Fitzhardinge , XenSource Inc, 2007
>>   */
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -192,6 +193,19 @@ static void xen_read_wallclock(struct timespec *ts)
>>  	put_cpu_var(xen_vcpu);
>>  }
>>  
>> +int xen_write_wallclock(const struct timespec *ts)
>> +{
>> +	struct xen_platform_op op;
>> +
>> +	op.cmd = XENPF_settime;
>> +	op.u.settime.secs = ts->tv_sec;
>> +	op.u.settime.nsecs = ts->tv_nsec;
>> +	op.u.settime.system_time = xen_clocksource_read();
>> +
>> +	return HYPERVISOR_dom0_op(&op);
>> +}
>> +EXPORT_SYMBOL_GPL(xen_write_wallclock);
>> +
>>  static unsigned long xen_get_wallclock(void)
>>  {
>>  	struct timespec ts;
>> @@ -202,7 +216,7 @@ static unsigned long xen_get_wallclock(void)
>>  
>>  static int xen_set_wallclock(unsigned long now)
>>  {
>> -	struct xen_platform_op op;
>> +	struct timespec ts;
>>  	int rc;
>>  
>>  	/* do nothing for domU */
>> @@ -218,12 +232,9 @@ static int xen_set_wallclock(unsigned long now)
>>  	 * update_persistent_wallclock() is called ~500 ms after 'now'
>>  	 * so add an extra 500 ms.
>>  	 */
>> -	op.cmd = XENPF_settime;
>> -	op.u.settime.secs = now;
>> -	op.u.settime.nsecs = NSEC_PER_SEC / 2;
>> -	op.u.settime.system_time = xen_clocksource_read();
>> -
>> -	rc = HYPERVISOR_dom0_op(&op);
>> +	ts.tv_sec = now;
>> +	ts.tv_nsec = NSEC_PER_SEC / 2;
>> +	rc = xen_write_wallclock(&ts);
>>  	WARN(rc != 0, "XENPF_settime failed: now=%ld\n", now);
>>  
>>  	return rc;
>> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
>> index ccee0f1..ed2caf3 100644
>> --- a/drivers/xen/privcmd.c
>> +++ b/drivers/xen/privcmd.c
>> @@ -338,6 +338,14 @@ out:
>>  	return ret;
>>  }
>>  
>> +static long privcmd_ioctl_sync_wallclock(void)
>> +{
>> +	struct timespec ts;
>> +
>> +	getnstimeofday(&ts);
>> +	return xen_write_wallclock(&ts);
>> +}
>> +
>>  static long privcmd_ioctl(struct file *file,
>>  			  unsigned int cmd, unsigned long data)
>>  {
>> @@ -357,6 +365,10 @@ static long privcmd_ioctl(struct file *file,
>>  		ret = privcmd_ioctl_mmap_batch(udata);
>>  		break;
>>  
>> +	case IOCTL_PRIVCMD_SYNC_WALLCLOCK:
>> +		ret = privcmd_ioctl_sync_wallclock();
>> +		break;
>> +
>>  	default:
>>  		ret = -EINVAL;
>>  		break;
>> diff --git a/include/xen/privcmd.h b/include/xen/privcmd.h
>> index 17857fb..d17d087 100644
>> --- a/include/xen/privcmd.h
>> +++ b/include/xen/privcmd.h
>> @@ -66,6 +66,12 @@ struct privcmd_mmapbatch {
>>   * @cmd: IOCTL_PRIVCMD_HYPERCALL
>>   * @arg: &privcmd_hypercall_t
>>   * Return: Value returned from execution of the specified hypercall.
>> + *
>> + * @cmd: IOCTL_PRIVCMD_SYNC_WALLCLOCK
>> + * @arg: Unused.
>> + * Synchronizes the Xen wallclock with the current system time.
>> + * Return: 0 on success, or -1 on error with errno set to EPERM or
>> + * EACCES.
>>   */
>>  #define IOCTL_PRIVCMD_HYPERCALL					\
>>  	_IOC(_IOC_NONE, 'P', 0, sizeof(struct privcmd_hypercall))
>> @@ -73,5 +79,7 @@ struct privcmd_mmapbatch {
>>  	_IOC(_IOC_NONE, 'P', 2, sizeof(struct privcmd_mmap))
>>  #define IOCTL_PRIVCMD_MMAPBATCH					\
>>  	_IOC(_IOC_NONE, 'P', 3, sizeof(struct privcmd_mmapbatch))
>> +#define IOCTL_PRIVCMD_SYNC_WALLCLOCK				\
>> +	_IOC(_IOC_NONE, 'P', 5, 0)
>>  
>>  #endif /* __LINUX_PUBLIC_PRIVCMD_H__ */
>> diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
>> index 6a198e4..eefed22 100644
>> --- a/include/xen/xen-ops.h
>> +++ b/include/xen/xen-ops.h
>> @@ -29,4 +29,6 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
>>  			       unsigned long mfn, int nr,
>>  			       pgprot_t prot, unsigned domid);
>>  
>> +int xen_write_wallclock(const struct timespec *ts);
>> +
>>  #endif /* INCLUDE_XEN_OPS_H */
>> -- 
>> 1.7.2.5
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 14:02:49 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 14:02:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMfou-0001Nf-Mk; Fri, 12 Oct 2012 14:02:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMfot-0001NZ-Cg
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 14:02:31 +0000
Received: from [85.158.139.211:22884] by server-15.bemta-5.messagelabs.com id
	52/28-27811-6F228705; Fri, 12 Oct 2012 14:02:30 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1350050548!22096289!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYwMjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28012 invoked from network); 12 Oct 2012 14:02:29 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 14:02:29 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="41030540"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 14:02:23 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 12 Oct 2012
	10:02:23 -0400
Message-ID: <507822ED.2090900@citrix.com>
Date: Fri, 12 Oct 2012 15:02:21 +0100
From: David Vrabel 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk 
References: <1350046634-2462-1-git-send-email-david.vrabel@citrix.com>
	<1350046634-2462-4-git-send-email-david.vrabel@citrix.com>
	<20121012134147.GA11778@phenom.dumpdata.com>
In-Reply-To: <20121012134147.GA11778@phenom.dumpdata.com>
Cc: Konrad Rzeszutek Wilk ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 3/3] xen/privcmd: add
 IOCTL_PRIVCMD_SYNC_WALLCLOCK to sync Xen's wallclock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/10/12 14:41, Konrad Rzeszutek Wilk wrote:
> On Fri, Oct 12, 2012 at 01:57:14PM +0100, David Vrabel wrote:
>> From: David Vrabel 
>>
>> Add a new ioctl to synchronize Xen's wallclock with the current system
>> time.
>>
>> This may be used by the tools to ensure that newly created domains see
>> the correct wallclock time if NTP is not used in dom0 or if domains
>> are started before NTP has synchronized.
> 
> So... how does this work with NTPD? As in does ntpd _not_ update the
> hwclock enough?

Once NTPD is synchronized then the kernel updates the wallclock (and the
RTC with patch #1) every 11 mins.  I assume this is often enough given
how NTP adjusts the system time.

You only really need the tools to sync wallclock if system time was
stepped at start of day.  e.g., init scripts could do something like:

ntpdate pool.ntp.org
hwclock --systohc
xen-wallclock --systowc

David

>> Signed-off-by: David Vrabel 
>> ---
>>  arch/x86/xen/time.c   |   25 ++++++++++++++++++-------
>>  drivers/xen/privcmd.c |   12 ++++++++++++
>>  include/xen/privcmd.h |    8 ++++++++
>>  include/xen/xen-ops.h |    2 ++
>>  4 files changed, 40 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
>> index 11770d0..d481ac9 100644
>> --- a/arch/x86/xen/time.c
>> +++ b/arch/x86/xen/time.c
>> @@ -8,6 +8,7 @@
>>   * Jeremy Fitzhardinge , XenSource Inc, 2007
>>   */
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -192,6 +193,19 @@ static void xen_read_wallclock(struct timespec *ts)
>>  	put_cpu_var(xen_vcpu);
>>  }
>>  
>> +int xen_write_wallclock(const struct timespec *ts)
>> +{
>> +	struct xen_platform_op op;
>> +
>> +	op.cmd = XENPF_settime;
>> +	op.u.settime.secs = ts->tv_sec;
>> +	op.u.settime.nsecs = ts->tv_nsec;
>> +	op.u.settime.system_time = xen_clocksource_read();
>> +
>> +	return HYPERVISOR_dom0_op(&op);
>> +}
>> +EXPORT_SYMBOL_GPL(xen_write_wallclock);
>> +
>>  static unsigned long xen_get_wallclock(void)
>>  {
>>  	struct timespec ts;
>> @@ -202,7 +216,7 @@ static unsigned long xen_get_wallclock(void)
>>  
>>  static int xen_set_wallclock(unsigned long now)
>>  {
>> -	struct xen_platform_op op;
>> +	struct timespec ts;
>>  	int rc;
>>  
>>  	/* do nothing for domU */
>> @@ -218,12 +232,9 @@ static int xen_set_wallclock(unsigned long now)
>>  	 * update_persistent_wallclock() is called ~500 ms after 'now'
>>  	 * so add an extra 500 ms.
>>  	 */
>> -	op.cmd = XENPF_settime;
>> -	op.u.settime.secs = now;
>> -	op.u.settime.nsecs = NSEC_PER_SEC / 2;
>> -	op.u.settime.system_time = xen_clocksource_read();
>> -
>> -	rc = HYPERVISOR_dom0_op(&op);
>> +	ts.tv_sec = now;
>> +	ts.tv_nsec = NSEC_PER_SEC / 2;
>> +	rc = xen_write_wallclock(&ts);
>>  	WARN(rc != 0, "XENPF_settime failed: now=%ld\n", now);
>>  
>>  	return rc;
>> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
>> index ccee0f1..ed2caf3 100644
>> --- a/drivers/xen/privcmd.c
>> +++ b/drivers/xen/privcmd.c
>> @@ -338,6 +338,14 @@ out:
>>  	return ret;
>>  }
>>  
>> +static long privcmd_ioctl_sync_wallclock(void)
>> +{
>> +	struct timespec ts;
>> +
>> +	getnstimeofday(&ts);
>> +	return xen_write_wallclock(&ts);
>> +}
>> +
>>  static long privcmd_ioctl(struct file *file,
>>  			  unsigned int cmd, unsigned long data)
>>  {
>> @@ -357,6 +365,10 @@ static long privcmd_ioctl(struct file *file,
>>  		ret = privcmd_ioctl_mmap_batch(udata);
>>  		break;
>>  
>> +	case IOCTL_PRIVCMD_SYNC_WALLCLOCK:
>> +		ret = privcmd_ioctl_sync_wallclock();
>> +		break;
>> +
>>  	default:
>>  		ret = -EINVAL;
>>  		break;
>> diff --git a/include/xen/privcmd.h b/include/xen/privcmd.h
>> index 17857fb..d17d087 100644
>> --- a/include/xen/privcmd.h
>> +++ b/include/xen/privcmd.h
>> @@ -66,6 +66,12 @@ struct privcmd_mmapbatch {
>>   * @cmd: IOCTL_PRIVCMD_HYPERCALL
>>   * @arg: &privcmd_hypercall_t
>>   * Return: Value returned from execution of the specified hypercall.
>> + *
>> + * @cmd: IOCTL_PRIVCMD_SYNC_WALLCLOCK
>> + * @arg: Unused.
>> + * Synchronizes the Xen wallclock with the current system time.
>> + * Return: 0 on success, or -1 on error with errno set to EPERM or
>> + * EACCES.
>>   */
>>  #define IOCTL_PRIVCMD_HYPERCALL					\
>>  	_IOC(_IOC_NONE, 'P', 0, sizeof(struct privcmd_hypercall))
>> @@ -73,5 +79,7 @@ struct privcmd_mmapbatch {
>>  	_IOC(_IOC_NONE, 'P', 2, sizeof(struct privcmd_mmap))
>>  #define IOCTL_PRIVCMD_MMAPBATCH					\
>>  	_IOC(_IOC_NONE, 'P', 3, sizeof(struct privcmd_mmapbatch))
>> +#define IOCTL_PRIVCMD_SYNC_WALLCLOCK				\
>> +	_IOC(_IOC_NONE, 'P', 5, 0)
>>  
>>  #endif /* __LINUX_PUBLIC_PRIVCMD_H__ */
>> diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
>> index 6a198e4..eefed22 100644
>> --- a/include/xen/xen-ops.h
>> +++ b/include/xen/xen-ops.h
>> @@ -29,4 +29,6 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
>>  			       unsigned long mfn, int nr,
>>  			       pgprot_t prot, unsigned domid);
>>  
>> +int xen_write_wallclock(const struct timespec *ts);
>> +
>>  #endif /* INCLUDE_XEN_OPS_H */
>> -- 
>> 1.7.2.5
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 14:14:45 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 14:14:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMg0Q-0001aK-3j; Fri, 12 Oct 2012 14:14:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMg0O-0001aF-5k
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 14:14:24 +0000
Received: from [85.158.137.99:39386] by server-15.bemta-3.messagelabs.com id
	C4/89-10261-FB528705; Fri, 12 Oct 2012 14:14:23 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-217.messagelabs.com!1350051262!16218430!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NTM0NTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NTM0NTE=\n,BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15624 invoked from network); 12 Oct 2012 14:14:22 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-6.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Oct 2012 14:14:22 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHji0PEzM=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-090-010.pools.arcor-ip.net [88.65.90.10])
	by smtp.strato.de (josoe mo6) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id z02996o9CDqv1v
	for ; Fri, 12 Oct 2012 16:14:22 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id E58A6183A7
	for ; Fri, 12 Oct 2012 16:14:21 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 597f0885494d0441b10c06938c62d50d4efb3fea
Message-Id: <597f0885494d0441b10c.1350051258@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Fri, 12 Oct 2012 16:14:18 +0200
From: Olaf Hering 
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] hotplug/Linux: remove hotplug support,
	rely on udev instead
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 Makefile                              |   1 -
 README                                |   8 +++---
 install.sh                            |  14 ------------
 tools/hotplug/Linux/Makefile          |  34 +-----------------------------
 tools/hotplug/Linux/xen-backend.agent |  39 -----------------------------------
 5 files changed, 5 insertions(+), 91 deletions(-)


# HG changeset patch
# User Olaf Hering 
# Date 1350048922 -7200
# Node ID 597f0885494d0441b10c06938c62d50d4efb3fea
# Parent  e0e1350dfe9b7a6cacb1378f75d8e6536d22eb2d
hotplug/Linux: remove hotplug support, rely on udev instead

Hotplug has been replaced by udev since several years. Remove the
hotplug related files and install udev unconditionally.

This makes it possible to remove udev from rpm BuildRequires which
reduces the buildtime dependency chain. For openSuSE:Factory it was
done just now:
http://lists.opensuse.org/opensuse-buildservice/2012-10/msg00085.html

The patch by itself will have no practical impact unless someone
attempts to build and run a Xen dom0 on a really old base system.

Signed-off-by: Olaf Hering 

diff -r e0e1350dfe9b -r 597f0885494d Makefile
--- a/Makefile
+++ b/Makefile
@@ -223,7 +223,6 @@ uninstall:
 	$(MAKE) -C xen uninstall
 	rm -rf $(D)$(CONFIG_DIR)/init.d/xendomains $(D)$(CONFIG_DIR)/init.d/xend
 	rm -rf $(D)$(CONFIG_DIR)/init.d/xencommons $(D)$(CONFIG_DIR)/init.d/xen-watchdog
-	rm -rf $(D)$(CONFIG_DIR)/hotplug/xen-backend.agent
 	rm -f  $(D)$(CONFIG_DIR)/udev/rules.d/xen-backend.rules
 	rm -f  $(D)$(CONFIG_DIR)/udev/rules.d/xend.rules
 	rm -f  $(D)$(SYSCONFIG_DIR)/xendomains
diff -r e0e1350dfe9b -r 597f0885494d README
--- a/README
+++ b/README
@@ -54,7 +54,7 @@ provided by your OS distributor:
     * pkg-config
     * bridge-utils package (/sbin/brctl)
     * iproute package (/sbin/ip)
-    * hotplug or udev
+    * udev
     * GNU bison and GNU flex
     * GNU gettext
     * 16-bit x86 assembler, loader and compiler (dev86 rpm or bin86 & bcc debs)
@@ -120,9 +120,9 @@ 4. To rebuild an existing tree without m
 
    make install and make dist differ in that make install does the
    right things for your local machine (installing the appropriate
-   version of hotplug or udev scripts, for example), but make dist
-   includes all versions of those scripts, so that you can copy the dist
-   directory to another machine and install from that distribution.
+   version of udev scripts, for example), but make dist includes all
+   versions of those scripts, so that you can copy the dist directory
+   to another machine and install from that distribution.
    
 Python Runtime Libraries
 ========================
diff -r e0e1350dfe9b -r 597f0885494d install.sh
--- a/install.sh
+++ b/install.sh
@@ -27,20 +27,6 @@ tmp="`mktemp -d`"
 echo "Installing Xen from '$src' to '$dst'..."
 (cd $src; tar -cf - * ) | tar -C "$tmp" -xf -
 
-[ -x "$(which udevinfo)" ] && \
-  UDEV_VERSION=$(udevinfo -V | sed -e 's/^[^0-9]* \([0-9]\{1,\}\)[^0-9]\{0,\}/\1/')
-
-[ -z "$UDEV_VERSION" -a -x /sbin/udevadm ] && \
-  UDEV_VERSION=$(/sbin/udevadm info -V | awk '{print $NF}')
-
-if [ -n "$UDEV_VERSION" ] && [ $UDEV_VERSION -ge 059 ]; then
-  echo " - installing for udev-based system"
-  rm -rf "$tmp/etc/hotplug"
-else
-  echo " - installing for hotplug-based system"
-  rm -rf "$tmp/etc/udev"
-fi
-
 echo " - modifying permissions"
 chmod -R a+rX "$tmp"
 
diff -r e0e1350dfe9b -r 597f0885494d tools/hotplug/Linux/Makefile
--- a/tools/hotplug/Linux/Makefile
+++ b/tools/hotplug/Linux/Makefile
@@ -27,32 +27,9 @@ XEN_SCRIPT_DATA += xen-hotplug-common.sh
 XEN_SCRIPT_DATA += block-common.sh vtpm-common.sh vtpm-hotplug-common.sh
 XEN_SCRIPT_DATA += vtpm-migration.sh vtpm-impl
 
-XEN_HOTPLUG_DIR = $(CONFIG_DIR)/hotplug
-XEN_HOTPLUG_SCRIPTS = xen-backend.agent
-
-UDEVVER = 0
-ifeq ($(shell [ -x /sbin/udevadm ] && echo 1),1)
-UDEVVER = $(shell /sbin/udevadm info -V | sed -e 's/^[^0-9]* \([0-9]\{1,\}\)[^0-9]\{0,\}/\1/' )
-endif
-ifeq ($(shell [ -x /usr/bin/udevinfo ] && echo 1),1)
-UDEVVER = $(shell /usr/bin/udevinfo -V | sed -e 's/^[^0-9]* \([0-9]\{1,\}\)[^0-9]\{0,\}/\1/' )
-endif
-
 UDEV_RULES_DIR = $(CONFIG_DIR)/udev
 UDEV_RULES = xen-backend.rules xend.rules
 
-DI = $(if $(DISTDIR),$(shell readlink -f $(DISTDIR)),)
-DE = $(if $(DESTDIR),$(shell readlink -f $(DESTDIR)),)
-ifeq ($(findstring $(DI),$(DE)),$(DI))
-HOTPLUGS=install-hotplug install-udev
-else
-ifeq ($(shell [ $(UDEVVER) -ge 059 ] && echo 1),1)
-HOTPLUGS=install-udev
-else
-HOTPLUGS=install-hotplug
-endif
-endif
-
 .PHONY: all
 all:
 
@@ -60,7 +37,7 @@ all:
 build:
 
 .PHONY: install
-install: all install-initd install-scripts $(HOTPLUGS)
+install: all install-initd install-scripts install-udev
 
 # See docs/misc/distro_mapping.txt for INITD_DIR location
 .PHONY: install-initd
@@ -87,15 +64,6 @@ install-scripts:
 	    $(INSTALL_DATA) $$i $(DESTDIR)$(XEN_SCRIPT_DIR); \
 	done
 
-.PHONY: install-hotplug
-install-hotplug:
-	[ -d $(DESTDIR)$(XEN_HOTPLUG_DIR) ] || \
-		$(INSTALL_DIR) $(DESTDIR)$(XEN_HOTPLUG_DIR)
-	set -e; for i in $(XEN_HOTPLUG_SCRIPTS); \
-	    do \
-	    $(INSTALL_PROG) $$i $(DESTDIR)$(XEN_HOTPLUG_DIR); \
-	done
-
 .PHONY: install-udev
 install-udev:
 	[ -d $(DESTDIR)$(UDEV_RULES_DIR) ] || \
diff -r e0e1350dfe9b -r 597f0885494d tools/hotplug/Linux/xen-backend.agent
--- a/tools/hotplug/Linux/xen-backend.agent
+++ /dev/null
@@ -1,39 +0,0 @@
-#! /bin/bash
-
-PATH=/etc/xen/scripts:$PATH
-
-. /etc/xen/scripts/locking.sh
-
-claim_lock xenbus_hotplug_global
-
-case "$XENBUS_TYPE" in
-  tap)
-    /etc/xen/scripts/blktap "$ACTION"
-    ;;
-  vbd)
-    /etc/xen/scripts/block "$ACTION"
-    ;;
-  vtpm)
-    /etc/xen/scripts/vtpm "$ACTION"
-    ;;
-  vif)
-    [ -n "$script" ] && $script "$ACTION"
-    ;;
-  vscsi)
-    /etc/xen/scripts/vscsi "$ACTION"
-    ;;
-esac
-
-case "$ACTION" in
-  add)
-    ;;
-  remove)
-    /etc/xen/scripts/xen-hotplug-cleanup
-    ;;
-  online)
-    ;;
-  offline)
-    ;;
-esac
-
-release_lock xenbus_hotplug_global

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 14:14:45 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 14:14:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMg0Q-0001aK-3j; Fri, 12 Oct 2012 14:14:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMg0O-0001aF-5k
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 14:14:24 +0000
Received: from [85.158.137.99:39386] by server-15.bemta-3.messagelabs.com id
	C4/89-10261-FB528705; Fri, 12 Oct 2012 14:14:23 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-217.messagelabs.com!1350051262!16218430!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NTM0NTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NTM0NTE=\n,BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15624 invoked from network); 12 Oct 2012 14:14:22 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-6.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Oct 2012 14:14:22 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHji0PEzM=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-090-010.pools.arcor-ip.net [88.65.90.10])
	by smtp.strato.de (josoe mo6) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id z02996o9CDqv1v
	for ; Fri, 12 Oct 2012 16:14:22 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id E58A6183A7
	for ; Fri, 12 Oct 2012 16:14:21 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 597f0885494d0441b10c06938c62d50d4efb3fea
Message-Id: <597f0885494d0441b10c.1350051258@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Fri, 12 Oct 2012 16:14:18 +0200
From: Olaf Hering 
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] hotplug/Linux: remove hotplug support,
	rely on udev instead
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 Makefile                              |   1 -
 README                                |   8 +++---
 install.sh                            |  14 ------------
 tools/hotplug/Linux/Makefile          |  34 +-----------------------------
 tools/hotplug/Linux/xen-backend.agent |  39 -----------------------------------
 5 files changed, 5 insertions(+), 91 deletions(-)


# HG changeset patch
# User Olaf Hering 
# Date 1350048922 -7200
# Node ID 597f0885494d0441b10c06938c62d50d4efb3fea
# Parent  e0e1350dfe9b7a6cacb1378f75d8e6536d22eb2d
hotplug/Linux: remove hotplug support, rely on udev instead

Hotplug has been replaced by udev since several years. Remove the
hotplug related files and install udev unconditionally.

This makes it possible to remove udev from rpm BuildRequires which
reduces the buildtime dependency chain. For openSuSE:Factory it was
done just now:
http://lists.opensuse.org/opensuse-buildservice/2012-10/msg00085.html

The patch by itself will have no practical impact unless someone
attempts to build and run a Xen dom0 on a really old base system.

Signed-off-by: Olaf Hering 

diff -r e0e1350dfe9b -r 597f0885494d Makefile
--- a/Makefile
+++ b/Makefile
@@ -223,7 +223,6 @@ uninstall:
 	$(MAKE) -C xen uninstall
 	rm -rf $(D)$(CONFIG_DIR)/init.d/xendomains $(D)$(CONFIG_DIR)/init.d/xend
 	rm -rf $(D)$(CONFIG_DIR)/init.d/xencommons $(D)$(CONFIG_DIR)/init.d/xen-watchdog
-	rm -rf $(D)$(CONFIG_DIR)/hotplug/xen-backend.agent
 	rm -f  $(D)$(CONFIG_DIR)/udev/rules.d/xen-backend.rules
 	rm -f  $(D)$(CONFIG_DIR)/udev/rules.d/xend.rules
 	rm -f  $(D)$(SYSCONFIG_DIR)/xendomains
diff -r e0e1350dfe9b -r 597f0885494d README
--- a/README
+++ b/README
@@ -54,7 +54,7 @@ provided by your OS distributor:
     * pkg-config
     * bridge-utils package (/sbin/brctl)
     * iproute package (/sbin/ip)
-    * hotplug or udev
+    * udev
     * GNU bison and GNU flex
     * GNU gettext
     * 16-bit x86 assembler, loader and compiler (dev86 rpm or bin86 & bcc debs)
@@ -120,9 +120,9 @@ 4. To rebuild an existing tree without m
 
    make install and make dist differ in that make install does the
    right things for your local machine (installing the appropriate
-   version of hotplug or udev scripts, for example), but make dist
-   includes all versions of those scripts, so that you can copy the dist
-   directory to another machine and install from that distribution.
+   version of udev scripts, for example), but make dist includes all
+   versions of those scripts, so that you can copy the dist directory
+   to another machine and install from that distribution.
    
 Python Runtime Libraries
 ========================
diff -r e0e1350dfe9b -r 597f0885494d install.sh
--- a/install.sh
+++ b/install.sh
@@ -27,20 +27,6 @@ tmp="`mktemp -d`"
 echo "Installing Xen from '$src' to '$dst'..."
 (cd $src; tar -cf - * ) | tar -C "$tmp" -xf -
 
-[ -x "$(which udevinfo)" ] && \
-  UDEV_VERSION=$(udevinfo -V | sed -e 's/^[^0-9]* \([0-9]\{1,\}\)[^0-9]\{0,\}/\1/')
-
-[ -z "$UDEV_VERSION" -a -x /sbin/udevadm ] && \
-  UDEV_VERSION=$(/sbin/udevadm info -V | awk '{print $NF}')
-
-if [ -n "$UDEV_VERSION" ] && [ $UDEV_VERSION -ge 059 ]; then
-  echo " - installing for udev-based system"
-  rm -rf "$tmp/etc/hotplug"
-else
-  echo " - installing for hotplug-based system"
-  rm -rf "$tmp/etc/udev"
-fi
-
 echo " - modifying permissions"
 chmod -R a+rX "$tmp"
 
diff -r e0e1350dfe9b -r 597f0885494d tools/hotplug/Linux/Makefile
--- a/tools/hotplug/Linux/Makefile
+++ b/tools/hotplug/Linux/Makefile
@@ -27,32 +27,9 @@ XEN_SCRIPT_DATA += xen-hotplug-common.sh
 XEN_SCRIPT_DATA += block-common.sh vtpm-common.sh vtpm-hotplug-common.sh
 XEN_SCRIPT_DATA += vtpm-migration.sh vtpm-impl
 
-XEN_HOTPLUG_DIR = $(CONFIG_DIR)/hotplug
-XEN_HOTPLUG_SCRIPTS = xen-backend.agent
-
-UDEVVER = 0
-ifeq ($(shell [ -x /sbin/udevadm ] && echo 1),1)
-UDEVVER = $(shell /sbin/udevadm info -V | sed -e 's/^[^0-9]* \([0-9]\{1,\}\)[^0-9]\{0,\}/\1/' )
-endif
-ifeq ($(shell [ -x /usr/bin/udevinfo ] && echo 1),1)
-UDEVVER = $(shell /usr/bin/udevinfo -V | sed -e 's/^[^0-9]* \([0-9]\{1,\}\)[^0-9]\{0,\}/\1/' )
-endif
-
 UDEV_RULES_DIR = $(CONFIG_DIR)/udev
 UDEV_RULES = xen-backend.rules xend.rules
 
-DI = $(if $(DISTDIR),$(shell readlink -f $(DISTDIR)),)
-DE = $(if $(DESTDIR),$(shell readlink -f $(DESTDIR)),)
-ifeq ($(findstring $(DI),$(DE)),$(DI))
-HOTPLUGS=install-hotplug install-udev
-else
-ifeq ($(shell [ $(UDEVVER) -ge 059 ] && echo 1),1)
-HOTPLUGS=install-udev
-else
-HOTPLUGS=install-hotplug
-endif
-endif
-
 .PHONY: all
 all:
 
@@ -60,7 +37,7 @@ all:
 build:
 
 .PHONY: install
-install: all install-initd install-scripts $(HOTPLUGS)
+install: all install-initd install-scripts install-udev
 
 # See docs/misc/distro_mapping.txt for INITD_DIR location
 .PHONY: install-initd
@@ -87,15 +64,6 @@ install-scripts:
 	    $(INSTALL_DATA) $$i $(DESTDIR)$(XEN_SCRIPT_DIR); \
 	done
 
-.PHONY: install-hotplug
-install-hotplug:
-	[ -d $(DESTDIR)$(XEN_HOTPLUG_DIR) ] || \
-		$(INSTALL_DIR) $(DESTDIR)$(XEN_HOTPLUG_DIR)
-	set -e; for i in $(XEN_HOTPLUG_SCRIPTS); \
-	    do \
-	    $(INSTALL_PROG) $$i $(DESTDIR)$(XEN_HOTPLUG_DIR); \
-	done
-
 .PHONY: install-udev
 install-udev:
 	[ -d $(DESTDIR)$(UDEV_RULES_DIR) ] || \
diff -r e0e1350dfe9b -r 597f0885494d tools/hotplug/Linux/xen-backend.agent
--- a/tools/hotplug/Linux/xen-backend.agent
+++ /dev/null
@@ -1,39 +0,0 @@
-#! /bin/bash
-
-PATH=/etc/xen/scripts:$PATH
-
-. /etc/xen/scripts/locking.sh
-
-claim_lock xenbus_hotplug_global
-
-case "$XENBUS_TYPE" in
-  tap)
-    /etc/xen/scripts/blktap "$ACTION"
-    ;;
-  vbd)
-    /etc/xen/scripts/block "$ACTION"
-    ;;
-  vtpm)
-    /etc/xen/scripts/vtpm "$ACTION"
-    ;;
-  vif)
-    [ -n "$script" ] && $script "$ACTION"
-    ;;
-  vscsi)
-    /etc/xen/scripts/vscsi "$ACTION"
-    ;;
-esac
-
-case "$ACTION" in
-  add)
-    ;;
-  remove)
-    /etc/xen/scripts/xen-hotplug-cleanup
-    ;;
-  online)
-    ;;
-  offline)
-    ;;
-esac
-
-release_lock xenbus_hotplug_global

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 14:30:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 14:30:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMgFM-0001kV-IR; Fri, 12 Oct 2012 14:29:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMgFL-0001kQ-7P
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 14:29:51 +0000
Received: from [85.158.139.211:16434] by server-6.bemta-5.messagelabs.com id
	97/28-08519-E5928705; Fri, 12 Oct 2012 14:29:50 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1350052188!22070941!1
X-Originating-IP: [209.85.219.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 435 invoked from network); 12 Oct 2012 14:29:49 -0000
Received: from mail-oa0-f45.google.com (HELO mail-oa0-f45.google.com)
	(209.85.219.45)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 14:29:49 -0000
Received: by mail-oa0-f45.google.com with SMTP id i18so3851210oag.32
	for ; Fri, 12 Oct 2012 07:29:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=f6C0a0cv0vuPrx0NsQt5HsMcMweaxzVjBMFkwJF0s6g=;
	b=SBjJBskgvOB2zCILjf0xzeg58d/VmrunNAGFk3JOmmLVpHG0aKQB6IlhU+DCNWowAn
	zZMfz20To26/RqxZh+M/YmXVK+bnwhYg/gBtLVmhkIST4yske/Ke6UTGRL+6biWhoQFL
	yW8sLdKBrWpfmRDZS5BfeWsOfOnGt5q1w2sjCY3jhRssT8tYhZvdYcvjqCPMkExg6xu6
	sDc20J9rbdtNCB+Z05J5VCE9jUatiZWiw080MwcH6QJzhpUoV5Y6AvF+0A4rh5gWMVzh
	rwjkkuqRl8mdLATDwuzJZxvJQ8WjzRWQEhR/UNqGwuOjbommn8xcuH7daHtWGgHi6WLK
	e7gA==
MIME-Version: 1.0
Received: by 10.182.110.67 with SMTP id hy3mr3676157obb.52.1350052187944; Fri,
	12 Oct 2012 07:29:47 -0700 (PDT)
Received: by 10.60.47.227 with HTTP; Fri, 12 Oct 2012 07:29:47 -0700 (PDT)
In-Reply-To: <507822ED.2090900@citrix.com>
References: <1350046634-2462-1-git-send-email-david.vrabel@citrix.com>
	<1350046634-2462-4-git-send-email-david.vrabel@citrix.com>
	<20121012134147.GA11778@phenom.dumpdata.com>
	<507822ED.2090900@citrix.com>
Date: Fri, 12 Oct 2012 10:29:47 -0400
X-Google-Sender-Auth: k7q6yjotedHEfE5LIENqJm8mVd0
Message-ID: 
From: Konrad Rzeszutek Wilk 
To: David Vrabel 
Cc: "xen-devel@lists.xen.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 3/3] xen/privcmd: add
 IOCTL_PRIVCMD_SYNC_WALLCLOCK to sync Xen's wallclock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 12, 2012 at 10:02 AM, David Vrabel  wrote:
> On 12/10/12 14:41, Konrad Rzeszutek Wilk wrote:
>> On Fri, Oct 12, 2012 at 01:57:14PM +0100, David Vrabel wrote:
>>> From: David Vrabel 
>>>
>>> Add a new ioctl to synchronize Xen's wallclock with the current system
>>> time.
>>>
>>> This may be used by the tools to ensure that newly created domains see
>>> the correct wallclock time if NTP is not used in dom0 or if domains
>>> are started before NTP has synchronized.
>>
>> So... how does this work with NTPD? As in does ntpd _not_ update the
>> hwclock enough?
>
> Once NTPD is synchronized then the kernel updates the wallclock (and the
> RTC with patch #1) every 11 mins.  I assume this is often enough given
> how NTP adjusts the system time.
>
> You only really need the tools to sync wallclock if system time was
> stepped at start of day.  e.g., init scripts could do something like:
>
> ntpdate pool.ntp.org
> hwclock --systohc
> xen-wallclock --systowc

I think I am missing something. The hwclock should end up in the
xen_set_wallclock call. And from there on, the ntpd would update the
wallclock if it got skewed enough? Or is the system time not calling
the wall-clock enough? If that is the case, would just adding this in
the crontab be enough:

*/11 * * * * hwclock --systohc

?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 14:30:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 14:30:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMgFM-0001kV-IR; Fri, 12 Oct 2012 14:29:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMgFL-0001kQ-7P
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 14:29:51 +0000
Received: from [85.158.139.211:16434] by server-6.bemta-5.messagelabs.com id
	97/28-08519-E5928705; Fri, 12 Oct 2012 14:29:50 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1350052188!22070941!1
X-Originating-IP: [209.85.219.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 435 invoked from network); 12 Oct 2012 14:29:49 -0000
Received: from mail-oa0-f45.google.com (HELO mail-oa0-f45.google.com)
	(209.85.219.45)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 14:29:49 -0000
Received: by mail-oa0-f45.google.com with SMTP id i18so3851210oag.32
	for ; Fri, 12 Oct 2012 07:29:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=f6C0a0cv0vuPrx0NsQt5HsMcMweaxzVjBMFkwJF0s6g=;
	b=SBjJBskgvOB2zCILjf0xzeg58d/VmrunNAGFk3JOmmLVpHG0aKQB6IlhU+DCNWowAn
	zZMfz20To26/RqxZh+M/YmXVK+bnwhYg/gBtLVmhkIST4yske/Ke6UTGRL+6biWhoQFL
	yW8sLdKBrWpfmRDZS5BfeWsOfOnGt5q1w2sjCY3jhRssT8tYhZvdYcvjqCPMkExg6xu6
	sDc20J9rbdtNCB+Z05J5VCE9jUatiZWiw080MwcH6QJzhpUoV5Y6AvF+0A4rh5gWMVzh
	rwjkkuqRl8mdLATDwuzJZxvJQ8WjzRWQEhR/UNqGwuOjbommn8xcuH7daHtWGgHi6WLK
	e7gA==
MIME-Version: 1.0
Received: by 10.182.110.67 with SMTP id hy3mr3676157obb.52.1350052187944; Fri,
	12 Oct 2012 07:29:47 -0700 (PDT)
Received: by 10.60.47.227 with HTTP; Fri, 12 Oct 2012 07:29:47 -0700 (PDT)
In-Reply-To: <507822ED.2090900@citrix.com>
References: <1350046634-2462-1-git-send-email-david.vrabel@citrix.com>
	<1350046634-2462-4-git-send-email-david.vrabel@citrix.com>
	<20121012134147.GA11778@phenom.dumpdata.com>
	<507822ED.2090900@citrix.com>
Date: Fri, 12 Oct 2012 10:29:47 -0400
X-Google-Sender-Auth: k7q6yjotedHEfE5LIENqJm8mVd0
Message-ID: 
From: Konrad Rzeszutek Wilk 
To: David Vrabel 
Cc: "xen-devel@lists.xen.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 3/3] xen/privcmd: add
 IOCTL_PRIVCMD_SYNC_WALLCLOCK to sync Xen's wallclock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 12, 2012 at 10:02 AM, David Vrabel  wrote:
> On 12/10/12 14:41, Konrad Rzeszutek Wilk wrote:
>> On Fri, Oct 12, 2012 at 01:57:14PM +0100, David Vrabel wrote:
>>> From: David Vrabel 
>>>
>>> Add a new ioctl to synchronize Xen's wallclock with the current system
>>> time.
>>>
>>> This may be used by the tools to ensure that newly created domains see
>>> the correct wallclock time if NTP is not used in dom0 or if domains
>>> are started before NTP has synchronized.
>>
>> So... how does this work with NTPD? As in does ntpd _not_ update the
>> hwclock enough?
>
> Once NTPD is synchronized then the kernel updates the wallclock (and the
> RTC with patch #1) every 11 mins.  I assume this is often enough given
> how NTP adjusts the system time.
>
> You only really need the tools to sync wallclock if system time was
> stepped at start of day.  e.g., init scripts could do something like:
>
> ntpdate pool.ntp.org
> hwclock --systohc
> xen-wallclock --systowc

I think I am missing something. The hwclock should end up in the
xen_set_wallclock call. And from there on, the ntpd would update the
wallclock if it got skewed enough? Or is the system time not calling
the wall-clock enough? If that is the case, would just adding this in
the crontab be enough:

*/11 * * * * hwclock --systohc

?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 14:37:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 14:37:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMgME-0001uL-IA; Fri, 12 Oct 2012 14:36:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMgMC-0001uG-Q9
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 14:36:57 +0000
Received: from [85.158.143.35:3184] by server-2.bemta-4.messagelabs.com id
	D9/B8-25171-80B28705; Fri, 12 Oct 2012 14:36:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1350052615!11089380!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQzMTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28611 invoked from network); 12 Oct 2012 14:36:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 14:36:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="15130421"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 14:36:55 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 12 Oct 2012 15:36:55 +0100
Message-ID: <1350052613.14806.109.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Olaf Hering 
Date: Fri, 12 Oct 2012 15:36:53 +0100
In-Reply-To: <597f0885494d0441b10c.1350051258@probook.site>
References: <597f0885494d0441b10c.1350051258@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] hotplug/Linux: remove hotplug support,
 rely on udev instead
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-12 at 15:14 +0100, Olaf Hering wrote:
> Makefile                              |   1 -
>  README                                |   8 +++---
>  install.sh                            |  14 ------------
>  tools/hotplug/Linux/Makefile          |  34 +-----------------------------
>  tools/hotplug/Linux/xen-backend.agent |  39 -----------------------------------
>  5 files changed, 5 insertions(+), 91 deletions(-)
> 
> 
> # HG changeset patch
> # User Olaf Hering 
> # Date 1350048922 -7200
> # Node ID 597f0885494d0441b10c06938c62d50d4efb3fea
> # Parent  e0e1350dfe9b7a6cacb1378f75d8e6536d22eb2d
> hotplug/Linux: remove hotplug support, rely on udev instead
> 
> Hotplug has been replaced by udev since several years. Remove the
> hotplug related files and install udev unconditionally.
> 
> This makes it possible to remove udev from rpm BuildRequires which
> reduces the buildtime dependency chain. For openSuSE:Factory it was
> done just now:
> http://lists.opensuse.org/opensuse-buildservice/2012-10/msg00085.html
> 
> The patch by itself will have no practical impact unless someone
> attempts to build and run a Xen dom0 on a really old base system.

Does anyone have any idea what sort of timeframe hotplug agent stuff
really died in, just so we can document something?

RHEL5, SLES10 and Debian Stable all have udev AFAIK, which is about as
old as we care about for the dom0.

> Signed-off-by: Olaf Hering 

Acked-by: Ian Campbell 
> 
> diff -r e0e1350dfe9b -r 597f0885494d Makefile
> --- a/Makefile
> +++ b/Makefile
> @@ -223,7 +223,6 @@ uninstall:
>  	$(MAKE) -C xen uninstall
>  	rm -rf $(D)$(CONFIG_DIR)/init.d/xendomains $(D)$(CONFIG_DIR)/init.d/xend
>  	rm -rf $(D)$(CONFIG_DIR)/init.d/xencommons $(D)$(CONFIG_DIR)/init.d/xen-watchdog
> -	rm -rf $(D)$(CONFIG_DIR)/hotplug/xen-backend.agent
>  	rm -f  $(D)$(CONFIG_DIR)/udev/rules.d/xen-backend.rules
>  	rm -f  $(D)$(CONFIG_DIR)/udev/rules.d/xend.rules
>  	rm -f  $(D)$(SYSCONFIG_DIR)/xendomains
> diff -r e0e1350dfe9b -r 597f0885494d README
> --- a/README
> +++ b/README
> @@ -54,7 +54,7 @@ provided by your OS distributor:
>      * pkg-config
>      * bridge-utils package (/sbin/brctl)
>      * iproute package (/sbin/ip)
> -    * hotplug or udev
> +    * udev
>      * GNU bison and GNU flex
>      * GNU gettext
>      * 16-bit x86 assembler, loader and compiler (dev86 rpm or bin86 & bcc debs)
> @@ -120,9 +120,9 @@ 4. To rebuild an existing tree without m
>  
>     make install and make dist differ in that make install does the
>     right things for your local machine (installing the appropriate
> -   version of hotplug or udev scripts, for example), but make dist
> -   includes all versions of those scripts, so that you can copy the dist
> -   directory to another machine and install from that distribution.
> +   version of udev scripts, for example), but make dist includes all
> +   versions of those scripts, so that you can copy the dist directory
> +   to another machine and install from that distribution.
>     
>  Python Runtime Libraries
>  ========================
> diff -r e0e1350dfe9b -r 597f0885494d install.sh
> --- a/install.sh
> +++ b/install.sh
> @@ -27,20 +27,6 @@ tmp="`mktemp -d`"
>  echo "Installing Xen from '$src' to '$dst'..."
>  (cd $src; tar -cf - * ) | tar -C "$tmp" -xf -
>  
> -[ -x "$(which udevinfo)" ] && \
> -  UDEV_VERSION=$(udevinfo -V | sed -e 's/^[^0-9]* \([0-9]\{1,\}\)[^0-9]\{0,\}/\1/')
> -
> -[ -z "$UDEV_VERSION" -a -x /sbin/udevadm ] && \
> -  UDEV_VERSION=$(/sbin/udevadm info -V | awk '{print $NF}')
> -
> -if [ -n "$UDEV_VERSION" ] && [ $UDEV_VERSION -ge 059 ]; then
> -  echo " - installing for udev-based system"
> -  rm -rf "$tmp/etc/hotplug"
> -else
> -  echo " - installing for hotplug-based system"
> -  rm -rf "$tmp/etc/udev"
> -fi
> -
>  echo " - modifying permissions"
>  chmod -R a+rX "$tmp"
>  
> diff -r e0e1350dfe9b -r 597f0885494d tools/hotplug/Linux/Makefile
> --- a/tools/hotplug/Linux/Makefile
> +++ b/tools/hotplug/Linux/Makefile
> @@ -27,32 +27,9 @@ XEN_SCRIPT_DATA += xen-hotplug-common.sh
>  XEN_SCRIPT_DATA += block-common.sh vtpm-common.sh vtpm-hotplug-common.sh
>  XEN_SCRIPT_DATA += vtpm-migration.sh vtpm-impl
>  
> -XEN_HOTPLUG_DIR = $(CONFIG_DIR)/hotplug
> -XEN_HOTPLUG_SCRIPTS = xen-backend.agent
> -
> -UDEVVER = 0
> -ifeq ($(shell [ -x /sbin/udevadm ] && echo 1),1)
> -UDEVVER = $(shell /sbin/udevadm info -V | sed -e 's/^[^0-9]* \([0-9]\{1,\}\)[^0-9]\{0,\}/\1/' )
> -endif
> -ifeq ($(shell [ -x /usr/bin/udevinfo ] && echo 1),1)
> -UDEVVER = $(shell /usr/bin/udevinfo -V | sed -e 's/^[^0-9]* \([0-9]\{1,\}\)[^0-9]\{0,\}/\1/' )
> -endif
> -
>  UDEV_RULES_DIR = $(CONFIG_DIR)/udev
>  UDEV_RULES = xen-backend.rules xend.rules
>  
> -DI = $(if $(DISTDIR),$(shell readlink -f $(DISTDIR)),)
> -DE = $(if $(DESTDIR),$(shell readlink -f $(DESTDIR)),)
> -ifeq ($(findstring $(DI),$(DE)),$(DI))
> -HOTPLUGS=install-hotplug install-udev
> -else
> -ifeq ($(shell [ $(UDEVVER) -ge 059 ] && echo 1),1)
> -HOTPLUGS=install-udev
> -else
> -HOTPLUGS=install-hotplug
> -endif
> -endif
> -
>  .PHONY: all
>  all:
>  
> @@ -60,7 +37,7 @@ all:
>  build:
>  
>  .PHONY: install
> -install: all install-initd install-scripts $(HOTPLUGS)
> +install: all install-initd install-scripts install-udev
>  
>  # See docs/misc/distro_mapping.txt for INITD_DIR location
>  .PHONY: install-initd
> @@ -87,15 +64,6 @@ install-scripts:
>  	    $(INSTALL_DATA) $$i $(DESTDIR)$(XEN_SCRIPT_DIR); \
>  	done
>  
> -.PHONY: install-hotplug
> -install-hotplug:
> -	[ -d $(DESTDIR)$(XEN_HOTPLUG_DIR) ] || \
> -		$(INSTALL_DIR) $(DESTDIR)$(XEN_HOTPLUG_DIR)
> -	set -e; for i in $(XEN_HOTPLUG_SCRIPTS); \
> -	    do \
> -	    $(INSTALL_PROG) $$i $(DESTDIR)$(XEN_HOTPLUG_DIR); \
> -	done
> -
>  .PHONY: install-udev
>  install-udev:
>  	[ -d $(DESTDIR)$(UDEV_RULES_DIR) ] || \
> diff -r e0e1350dfe9b -r 597f0885494d tools/hotplug/Linux/xen-backend.agent
> --- a/tools/hotplug/Linux/xen-backend.agent
> +++ /dev/null
> @@ -1,39 +0,0 @@
> -#! /bin/bash
> -
> -PATH=/etc/xen/scripts:$PATH
> -
> -. /etc/xen/scripts/locking.sh
> -
> -claim_lock xenbus_hotplug_global
> -
> -case "$XENBUS_TYPE" in
> -  tap)
> -    /etc/xen/scripts/blktap "$ACTION"
> -    ;;
> -  vbd)
> -    /etc/xen/scripts/block "$ACTION"
> -    ;;
> -  vtpm)
> -    /etc/xen/scripts/vtpm "$ACTION"
> -    ;;
> -  vif)
> -    [ -n "$script" ] && $script "$ACTION"
> -    ;;
> -  vscsi)
> -    /etc/xen/scripts/vscsi "$ACTION"
> -    ;;
> -esac
> -
> -case "$ACTION" in
> -  add)
> -    ;;
> -  remove)
> -    /etc/xen/scripts/xen-hotplug-cleanup
> -    ;;
> -  online)
> -    ;;
> -  offline)
> -    ;;
> -esac
> -
> -release_lock xenbus_hotplug_global
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 14:37:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 14:37:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMgME-0001uL-IA; Fri, 12 Oct 2012 14:36:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMgMC-0001uG-Q9
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 14:36:57 +0000
Received: from [85.158.143.35:3184] by server-2.bemta-4.messagelabs.com id
	D9/B8-25171-80B28705; Fri, 12 Oct 2012 14:36:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1350052615!11089380!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQzMTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28611 invoked from network); 12 Oct 2012 14:36:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 14:36:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="15130421"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 14:36:55 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 12 Oct 2012 15:36:55 +0100
Message-ID: <1350052613.14806.109.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Olaf Hering 
Date: Fri, 12 Oct 2012 15:36:53 +0100
In-Reply-To: <597f0885494d0441b10c.1350051258@probook.site>
References: <597f0885494d0441b10c.1350051258@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] hotplug/Linux: remove hotplug support,
 rely on udev instead
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-12 at 15:14 +0100, Olaf Hering wrote:
> Makefile                              |   1 -
>  README                                |   8 +++---
>  install.sh                            |  14 ------------
>  tools/hotplug/Linux/Makefile          |  34 +-----------------------------
>  tools/hotplug/Linux/xen-backend.agent |  39 -----------------------------------
>  5 files changed, 5 insertions(+), 91 deletions(-)
> 
> 
> # HG changeset patch
> # User Olaf Hering 
> # Date 1350048922 -7200
> # Node ID 597f0885494d0441b10c06938c62d50d4efb3fea
> # Parent  e0e1350dfe9b7a6cacb1378f75d8e6536d22eb2d
> hotplug/Linux: remove hotplug support, rely on udev instead
> 
> Hotplug has been replaced by udev since several years. Remove the
> hotplug related files and install udev unconditionally.
> 
> This makes it possible to remove udev from rpm BuildRequires which
> reduces the buildtime dependency chain. For openSuSE:Factory it was
> done just now:
> http://lists.opensuse.org/opensuse-buildservice/2012-10/msg00085.html
> 
> The patch by itself will have no practical impact unless someone
> attempts to build and run a Xen dom0 on a really old base system.

Does anyone have any idea what sort of timeframe hotplug agent stuff
really died in, just so we can document something?

RHEL5, SLES10 and Debian Stable all have udev AFAIK, which is about as
old as we care about for the dom0.

> Signed-off-by: Olaf Hering 

Acked-by: Ian Campbell 
> 
> diff -r e0e1350dfe9b -r 597f0885494d Makefile
> --- a/Makefile
> +++ b/Makefile
> @@ -223,7 +223,6 @@ uninstall:
>  	$(MAKE) -C xen uninstall
>  	rm -rf $(D)$(CONFIG_DIR)/init.d/xendomains $(D)$(CONFIG_DIR)/init.d/xend
>  	rm -rf $(D)$(CONFIG_DIR)/init.d/xencommons $(D)$(CONFIG_DIR)/init.d/xen-watchdog
> -	rm -rf $(D)$(CONFIG_DIR)/hotplug/xen-backend.agent
>  	rm -f  $(D)$(CONFIG_DIR)/udev/rules.d/xen-backend.rules
>  	rm -f  $(D)$(CONFIG_DIR)/udev/rules.d/xend.rules
>  	rm -f  $(D)$(SYSCONFIG_DIR)/xendomains
> diff -r e0e1350dfe9b -r 597f0885494d README
> --- a/README
> +++ b/README
> @@ -54,7 +54,7 @@ provided by your OS distributor:
>      * pkg-config
>      * bridge-utils package (/sbin/brctl)
>      * iproute package (/sbin/ip)
> -    * hotplug or udev
> +    * udev
>      * GNU bison and GNU flex
>      * GNU gettext
>      * 16-bit x86 assembler, loader and compiler (dev86 rpm or bin86 & bcc debs)
> @@ -120,9 +120,9 @@ 4. To rebuild an existing tree without m
>  
>     make install and make dist differ in that make install does the
>     right things for your local machine (installing the appropriate
> -   version of hotplug or udev scripts, for example), but make dist
> -   includes all versions of those scripts, so that you can copy the dist
> -   directory to another machine and install from that distribution.
> +   version of udev scripts, for example), but make dist includes all
> +   versions of those scripts, so that you can copy the dist directory
> +   to another machine and install from that distribution.
>     
>  Python Runtime Libraries
>  ========================
> diff -r e0e1350dfe9b -r 597f0885494d install.sh
> --- a/install.sh
> +++ b/install.sh
> @@ -27,20 +27,6 @@ tmp="`mktemp -d`"
>  echo "Installing Xen from '$src' to '$dst'..."
>  (cd $src; tar -cf - * ) | tar -C "$tmp" -xf -
>  
> -[ -x "$(which udevinfo)" ] && \
> -  UDEV_VERSION=$(udevinfo -V | sed -e 's/^[^0-9]* \([0-9]\{1,\}\)[^0-9]\{0,\}/\1/')
> -
> -[ -z "$UDEV_VERSION" -a -x /sbin/udevadm ] && \
> -  UDEV_VERSION=$(/sbin/udevadm info -V | awk '{print $NF}')
> -
> -if [ -n "$UDEV_VERSION" ] && [ $UDEV_VERSION -ge 059 ]; then
> -  echo " - installing for udev-based system"
> -  rm -rf "$tmp/etc/hotplug"
> -else
> -  echo " - installing for hotplug-based system"
> -  rm -rf "$tmp/etc/udev"
> -fi
> -
>  echo " - modifying permissions"
>  chmod -R a+rX "$tmp"
>  
> diff -r e0e1350dfe9b -r 597f0885494d tools/hotplug/Linux/Makefile
> --- a/tools/hotplug/Linux/Makefile
> +++ b/tools/hotplug/Linux/Makefile
> @@ -27,32 +27,9 @@ XEN_SCRIPT_DATA += xen-hotplug-common.sh
>  XEN_SCRIPT_DATA += block-common.sh vtpm-common.sh vtpm-hotplug-common.sh
>  XEN_SCRIPT_DATA += vtpm-migration.sh vtpm-impl
>  
> -XEN_HOTPLUG_DIR = $(CONFIG_DIR)/hotplug
> -XEN_HOTPLUG_SCRIPTS = xen-backend.agent
> -
> -UDEVVER = 0
> -ifeq ($(shell [ -x /sbin/udevadm ] && echo 1),1)
> -UDEVVER = $(shell /sbin/udevadm info -V | sed -e 's/^[^0-9]* \([0-9]\{1,\}\)[^0-9]\{0,\}/\1/' )
> -endif
> -ifeq ($(shell [ -x /usr/bin/udevinfo ] && echo 1),1)
> -UDEVVER = $(shell /usr/bin/udevinfo -V | sed -e 's/^[^0-9]* \([0-9]\{1,\}\)[^0-9]\{0,\}/\1/' )
> -endif
> -
>  UDEV_RULES_DIR = $(CONFIG_DIR)/udev
>  UDEV_RULES = xen-backend.rules xend.rules
>  
> -DI = $(if $(DISTDIR),$(shell readlink -f $(DISTDIR)),)
> -DE = $(if $(DESTDIR),$(shell readlink -f $(DESTDIR)),)
> -ifeq ($(findstring $(DI),$(DE)),$(DI))
> -HOTPLUGS=install-hotplug install-udev
> -else
> -ifeq ($(shell [ $(UDEVVER) -ge 059 ] && echo 1),1)
> -HOTPLUGS=install-udev
> -else
> -HOTPLUGS=install-hotplug
> -endif
> -endif
> -
>  .PHONY: all
>  all:
>  
> @@ -60,7 +37,7 @@ all:
>  build:
>  
>  .PHONY: install
> -install: all install-initd install-scripts $(HOTPLUGS)
> +install: all install-initd install-scripts install-udev
>  
>  # See docs/misc/distro_mapping.txt for INITD_DIR location
>  .PHONY: install-initd
> @@ -87,15 +64,6 @@ install-scripts:
>  	    $(INSTALL_DATA) $$i $(DESTDIR)$(XEN_SCRIPT_DIR); \
>  	done
>  
> -.PHONY: install-hotplug
> -install-hotplug:
> -	[ -d $(DESTDIR)$(XEN_HOTPLUG_DIR) ] || \
> -		$(INSTALL_DIR) $(DESTDIR)$(XEN_HOTPLUG_DIR)
> -	set -e; for i in $(XEN_HOTPLUG_SCRIPTS); \
> -	    do \
> -	    $(INSTALL_PROG) $$i $(DESTDIR)$(XEN_HOTPLUG_DIR); \
> -	done
> -
>  .PHONY: install-udev
>  install-udev:
>  	[ -d $(DESTDIR)$(UDEV_RULES_DIR) ] || \
> diff -r e0e1350dfe9b -r 597f0885494d tools/hotplug/Linux/xen-backend.agent
> --- a/tools/hotplug/Linux/xen-backend.agent
> +++ /dev/null
> @@ -1,39 +0,0 @@
> -#! /bin/bash
> -
> -PATH=/etc/xen/scripts:$PATH
> -
> -. /etc/xen/scripts/locking.sh
> -
> -claim_lock xenbus_hotplug_global
> -
> -case "$XENBUS_TYPE" in
> -  tap)
> -    /etc/xen/scripts/blktap "$ACTION"
> -    ;;
> -  vbd)
> -    /etc/xen/scripts/block "$ACTION"
> -    ;;
> -  vtpm)
> -    /etc/xen/scripts/vtpm "$ACTION"
> -    ;;
> -  vif)
> -    [ -n "$script" ] && $script "$ACTION"
> -    ;;
> -  vscsi)
> -    /etc/xen/scripts/vscsi "$ACTION"
> -    ;;
> -esac
> -
> -case "$ACTION" in
> -  add)
> -    ;;
> -  remove)
> -    /etc/xen/scripts/xen-hotplug-cleanup
> -    ;;
> -  online)
> -    ;;
> -  offline)
> -    ;;
> -esac
> -
> -release_lock xenbus_hotplug_global
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 14:47:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 14:47:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMgVo-00023f-Ll; Fri, 12 Oct 2012 14:46:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMgVn-00023a-Fh
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 14:46:51 +0000
Received: from [85.158.138.51:47597] by server-4.bemta-3.messagelabs.com id
	82/0D-01405-A5D28705; Fri, 12 Oct 2012 14:46:50 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1350053207!34094281!1
X-Originating-IP: [216.32.181.186]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16555 invoked from network); 12 Oct 2012 14:46:49 -0000
Received: from ch1ehsobe006.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.186)
	by server-8.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	12 Oct 2012 14:46:49 -0000
Received: from mail241-ch1-R.bigfish.com (10.43.68.229) by
	CH1EHSOBE005.bigfish.com (10.43.70.55) with Microsoft SMTP Server id
	14.1.225.23; Fri, 12 Oct 2012 14:46:44 +0000
Received: from mail241-ch1 (localhost [127.0.0.1])	by
	mail241-ch1-R.bigfish.com (Postfix) with ESMTP id 46885A8010F	for
	; Fri, 12 Oct 2012 14:46:44 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzc85fhc85dhzz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12bdh137ah1441h34h1155h)
Received: from mail241-ch1 (localhost.localdomain [127.0.0.1]) by mail241-ch1
	(MessageSwitch) id 1350053203205327_16670;
	Fri, 12 Oct 2012 14:46:43 +0000 (UTC)
Received: from CH1EHSMHS001.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.244])	by mail241-ch1.bigfish.com (Postfix) with ESMTP id
	2669F940048	for ;
	Fri, 12 Oct 2012 14:46:43 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS001.bigfish.com (10.43.70.1) with Microsoft SMTP Server id
	14.1.225.23; Fri, 12 Oct 2012 14:46:40 +0000
X-WSS-ID: 0MBSBPR-02-16I-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 26141C809A	for ; Fri, 12 Oct 2012
	09:46:38 -0500 (CDT)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 12 Oct 2012 09:47:24 -0500
Received: from STOREXDAG01.amd.com (10.1.13.10) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Fri, 12 Oct 2012 09:46:37 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag01.amd.com
	(10.1.13.10) with Microsoft SMTP Server id 14.1.323.3; Fri, 12 Oct 2012
	10:46:36 -0400
Message-ID: <50782D4B.50607@amd.com>
Date: Fri, 12 Oct 2012 16:46:35 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" 
Content-Type: multipart/mixed; boundary="------------010209020108070809080102"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] x86/MCE: Implement clearbank callback for AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------010209020108070809080102
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit


Implement clearbank callbank for AMD.

Signed-off-by: Christoph Egger 

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------010209020108070809080102
Content-Type: text/plain; charset="us-ascii"; name="xen_mce_clearbank.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_mce_clearbank.diff"
Content-Description: xen_mce_clearbank.diff

diff -r 6b73078a4403 xen/arch/x86/cpu/mcheck/amd_k8.c
--- a/xen/arch/x86/cpu/mcheck/amd_k8.c	Fri Oct 12 14:38:20 2012 +0200
+++ b/xen/arch/x86/cpu/mcheck/amd_k8.c	Fri Oct 12 15:20:08 2012 +0200
@@ -72,7 +72,31 @@
 /* Machine Check Handler for AMD K8 family series */
 static void k8_machine_check(struct cpu_user_regs *regs, long error_code)
 {
-	mcheck_cmn_handler(regs, error_code, mca_allbanks, NULL);
+	mcheck_cmn_handler(regs, error_code, mca_allbanks,
+	    __get_cpu_var(mce_clear_banks));
+}
+
+static int k8_need_clearbank_scan(enum mca_source who, uint64_t status)
+{
+	switch (who) {
+	case MCA_MCE_SCAN:
+	case MCA_MCE_HANDLER:
+		break;
+	default:
+		return 1;
+	}
+
+	/* For fatal error, it shouldn't be cleared so that sticky bank
+	 * have chance to be handled after reboot by polling.
+	 */
+	if ( (status & MCi_STATUS_UC) && (status & MCi_STATUS_PCC) )
+		return 0;
+	/* Spurious need clear bank */
+	if ( !(status & MCi_STATUS_OVER)
+	    && (status & MCi_STATUS_UC) && !(status & MCi_STATUS_EN))
+		return 1;
+
+	return 1;
 }
 
 /* AMD K8 machine check */
@@ -85,6 +109,7 @@ enum mcheck_type amd_k8_mcheck_init(stru
 
 	mce_handler_init();
 	x86_mce_vector_register(k8_machine_check);
+	mce_need_clearbank_register(k8_need_clearbank_scan);
 
 	for (i = 0; i < nr_mce_banks; i++) {
 		if (quirkflag == MCEQUIRK_K8_GART && i == 4) {
diff -r 6b73078a4403 xen/arch/x86/cpu/mcheck/mce.c
--- a/xen/arch/x86/cpu/mcheck/mce.c	Fri Oct 12 14:38:20 2012 +0200
+++ b/xen/arch/x86/cpu/mcheck/mce.c	Fri Oct 12 15:20:08 2012 +0200
@@ -35,6 +35,10 @@ bool_t is_mc_panic;
 unsigned int __read_mostly nr_mce_banks;
 unsigned int __read_mostly firstbank;
 
+DEFINE_PER_CPU(struct mca_banks *, poll_bankmask);
+DEFINE_PER_CPU(struct mca_banks *, no_cmci_banks);
+DEFINE_PER_CPU(struct mca_banks *, mce_clear_banks);
+
 static void intpose_init(void);
 static void mcinfo_clear(struct mc_info *);
 struct mca_banks *mca_allbanks;
diff -r 6b73078a4403 xen/arch/x86/cpu/mcheck/mce.h
--- a/xen/arch/x86/cpu/mcheck/mce.h	Fri Oct 12 14:38:20 2012 +0200
+++ b/xen/arch/x86/cpu/mcheck/mce.h	Fri Oct 12 15:20:08 2012 +0200
@@ -122,6 +122,7 @@ struct mca_summary {
 
 DECLARE_PER_CPU(struct mca_banks *, poll_bankmask);
 DECLARE_PER_CPU(struct mca_banks *, no_cmci_banks);
+DECLARE_PER_CPU(struct mca_banks *, mce_clear_banks);
 
 extern bool_t cmci_support;
 extern bool_t is_mc_panic;
diff -r 6b73078a4403 xen/arch/x86/cpu/mcheck/mce_intel.c
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c	Fri Oct 12 14:38:20 2012 +0200
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c	Fri Oct 12 15:20:08 2012 +0200
@@ -21,9 +21,7 @@
 #include "vmce.h"
 #include "mcaction.h"
 
-DEFINE_PER_CPU(struct mca_banks *, mce_banks_owned);
-DEFINE_PER_CPU(struct mca_banks *, no_cmci_banks);
-DEFINE_PER_CPU(struct mca_banks *, mce_clear_banks);
+static DEFINE_PER_CPU(struct mca_banks *, mce_banks_owned);
 bool_t __read_mostly cmci_support = 0;
 static bool_t __read_mostly ser_support = 0;
 static bool_t __read_mostly mce_force_broadcast;
diff -r 6b73078a4403 xen/arch/x86/cpu/mcheck/mctelem.h
--- a/xen/arch/x86/cpu/mcheck/mctelem.h	Fri Oct 12 14:38:20 2012 +0200
+++ b/xen/arch/x86/cpu/mcheck/mctelem.h	Fri Oct 12 15:20:08 2012 +0200
@@ -23,7 +23,7 @@
  * urgent uses, intended for use from machine check exception handlers,
  * and non-urgent uses intended for use from error pollers.
  * Associated with each logout entry of whatever class is a data area
- * sized per the single argument to mctelem_init.  mcelem_init should be
+ * sized per the single argument to mctelem_init.  mctelem_init should be
  * called from MCA init code before anybody has the chance to change the
  * machine check vector with mcheck_mca_logout or to use mcheck_mca_logout.
  *
@@ -45,7 +45,7 @@
  * which will return a cookie referencing the oldest (first committed)
  * entry of the requested class.  Access the associated data using
  * mctelem_dataptr and when finished use mctelem_consume_oldest_end - in the
- * begin .. end bracket you are guaranteed that the entry canot be freed
+ * begin .. end bracket you are guaranteed that the entry cannot be freed
  * even if it is ack'd elsewhere).  Once the ultimate consumer of the
  * telemetry has processed it to stable storage it should acknowledge
  * the telemetry quoting the cookie id, at which point we will free
diff -r 6b73078a4403 xen/arch/x86/cpu/mcheck/non-fatal.c
--- a/xen/arch/x86/cpu/mcheck/non-fatal.c	Fri Oct 12 14:38:20 2012 +0200
+++ b/xen/arch/x86/cpu/mcheck/non-fatal.c	Fri Oct 12 15:20:08 2012 +0200
@@ -23,7 +23,6 @@
 #include "mce.h"
 #include "vmce.h"
 
-DEFINE_PER_CPU(struct mca_banks *, poll_bankmask);
 static struct timer mce_timer;
 
 #define MCE_PERIOD MILLISECS(8000)

--------------010209020108070809080102
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------010209020108070809080102--


From xen-devel-bounces@lists.xen.org Fri Oct 12 14:47:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 14:47:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMgVo-00023f-Ll; Fri, 12 Oct 2012 14:46:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMgVn-00023a-Fh
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 14:46:51 +0000
Received: from [85.158.138.51:47597] by server-4.bemta-3.messagelabs.com id
	82/0D-01405-A5D28705; Fri, 12 Oct 2012 14:46:50 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1350053207!34094281!1
X-Originating-IP: [216.32.181.186]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16555 invoked from network); 12 Oct 2012 14:46:49 -0000
Received: from ch1ehsobe006.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.186)
	by server-8.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	12 Oct 2012 14:46:49 -0000
Received: from mail241-ch1-R.bigfish.com (10.43.68.229) by
	CH1EHSOBE005.bigfish.com (10.43.70.55) with Microsoft SMTP Server id
	14.1.225.23; Fri, 12 Oct 2012 14:46:44 +0000
Received: from mail241-ch1 (localhost [127.0.0.1])	by
	mail241-ch1-R.bigfish.com (Postfix) with ESMTP id 46885A8010F	for
	; Fri, 12 Oct 2012 14:46:44 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzc85fhc85dhzz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12bdh137ah1441h34h1155h)
Received: from mail241-ch1 (localhost.localdomain [127.0.0.1]) by mail241-ch1
	(MessageSwitch) id 1350053203205327_16670;
	Fri, 12 Oct 2012 14:46:43 +0000 (UTC)
Received: from CH1EHSMHS001.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.244])	by mail241-ch1.bigfish.com (Postfix) with ESMTP id
	2669F940048	for ;
	Fri, 12 Oct 2012 14:46:43 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS001.bigfish.com (10.43.70.1) with Microsoft SMTP Server id
	14.1.225.23; Fri, 12 Oct 2012 14:46:40 +0000
X-WSS-ID: 0MBSBPR-02-16I-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 26141C809A	for ; Fri, 12 Oct 2012
	09:46:38 -0500 (CDT)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 12 Oct 2012 09:47:24 -0500
Received: from STOREXDAG01.amd.com (10.1.13.10) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Fri, 12 Oct 2012 09:46:37 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag01.amd.com
	(10.1.13.10) with Microsoft SMTP Server id 14.1.323.3; Fri, 12 Oct 2012
	10:46:36 -0400
Message-ID: <50782D4B.50607@amd.com>
Date: Fri, 12 Oct 2012 16:46:35 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" 
Content-Type: multipart/mixed; boundary="------------010209020108070809080102"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] x86/MCE: Implement clearbank callback for AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------010209020108070809080102
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit


Implement clearbank callbank for AMD.

Signed-off-by: Christoph Egger 

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------010209020108070809080102
Content-Type: text/plain; charset="us-ascii"; name="xen_mce_clearbank.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_mce_clearbank.diff"
Content-Description: xen_mce_clearbank.diff

diff -r 6b73078a4403 xen/arch/x86/cpu/mcheck/amd_k8.c
--- a/xen/arch/x86/cpu/mcheck/amd_k8.c	Fri Oct 12 14:38:20 2012 +0200
+++ b/xen/arch/x86/cpu/mcheck/amd_k8.c	Fri Oct 12 15:20:08 2012 +0200
@@ -72,7 +72,31 @@
 /* Machine Check Handler for AMD K8 family series */
 static void k8_machine_check(struct cpu_user_regs *regs, long error_code)
 {
-	mcheck_cmn_handler(regs, error_code, mca_allbanks, NULL);
+	mcheck_cmn_handler(regs, error_code, mca_allbanks,
+	    __get_cpu_var(mce_clear_banks));
+}
+
+static int k8_need_clearbank_scan(enum mca_source who, uint64_t status)
+{
+	switch (who) {
+	case MCA_MCE_SCAN:
+	case MCA_MCE_HANDLER:
+		break;
+	default:
+		return 1;
+	}
+
+	/* For fatal error, it shouldn't be cleared so that sticky bank
+	 * have chance to be handled after reboot by polling.
+	 */
+	if ( (status & MCi_STATUS_UC) && (status & MCi_STATUS_PCC) )
+		return 0;
+	/* Spurious need clear bank */
+	if ( !(status & MCi_STATUS_OVER)
+	    && (status & MCi_STATUS_UC) && !(status & MCi_STATUS_EN))
+		return 1;
+
+	return 1;
 }
 
 /* AMD K8 machine check */
@@ -85,6 +109,7 @@ enum mcheck_type amd_k8_mcheck_init(stru
 
 	mce_handler_init();
 	x86_mce_vector_register(k8_machine_check);
+	mce_need_clearbank_register(k8_need_clearbank_scan);
 
 	for (i = 0; i < nr_mce_banks; i++) {
 		if (quirkflag == MCEQUIRK_K8_GART && i == 4) {
diff -r 6b73078a4403 xen/arch/x86/cpu/mcheck/mce.c
--- a/xen/arch/x86/cpu/mcheck/mce.c	Fri Oct 12 14:38:20 2012 +0200
+++ b/xen/arch/x86/cpu/mcheck/mce.c	Fri Oct 12 15:20:08 2012 +0200
@@ -35,6 +35,10 @@ bool_t is_mc_panic;
 unsigned int __read_mostly nr_mce_banks;
 unsigned int __read_mostly firstbank;
 
+DEFINE_PER_CPU(struct mca_banks *, poll_bankmask);
+DEFINE_PER_CPU(struct mca_banks *, no_cmci_banks);
+DEFINE_PER_CPU(struct mca_banks *, mce_clear_banks);
+
 static void intpose_init(void);
 static void mcinfo_clear(struct mc_info *);
 struct mca_banks *mca_allbanks;
diff -r 6b73078a4403 xen/arch/x86/cpu/mcheck/mce.h
--- a/xen/arch/x86/cpu/mcheck/mce.h	Fri Oct 12 14:38:20 2012 +0200
+++ b/xen/arch/x86/cpu/mcheck/mce.h	Fri Oct 12 15:20:08 2012 +0200
@@ -122,6 +122,7 @@ struct mca_summary {
 
 DECLARE_PER_CPU(struct mca_banks *, poll_bankmask);
 DECLARE_PER_CPU(struct mca_banks *, no_cmci_banks);
+DECLARE_PER_CPU(struct mca_banks *, mce_clear_banks);
 
 extern bool_t cmci_support;
 extern bool_t is_mc_panic;
diff -r 6b73078a4403 xen/arch/x86/cpu/mcheck/mce_intel.c
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c	Fri Oct 12 14:38:20 2012 +0200
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c	Fri Oct 12 15:20:08 2012 +0200
@@ -21,9 +21,7 @@
 #include "vmce.h"
 #include "mcaction.h"
 
-DEFINE_PER_CPU(struct mca_banks *, mce_banks_owned);
-DEFINE_PER_CPU(struct mca_banks *, no_cmci_banks);
-DEFINE_PER_CPU(struct mca_banks *, mce_clear_banks);
+static DEFINE_PER_CPU(struct mca_banks *, mce_banks_owned);
 bool_t __read_mostly cmci_support = 0;
 static bool_t __read_mostly ser_support = 0;
 static bool_t __read_mostly mce_force_broadcast;
diff -r 6b73078a4403 xen/arch/x86/cpu/mcheck/mctelem.h
--- a/xen/arch/x86/cpu/mcheck/mctelem.h	Fri Oct 12 14:38:20 2012 +0200
+++ b/xen/arch/x86/cpu/mcheck/mctelem.h	Fri Oct 12 15:20:08 2012 +0200
@@ -23,7 +23,7 @@
  * urgent uses, intended for use from machine check exception handlers,
  * and non-urgent uses intended for use from error pollers.
  * Associated with each logout entry of whatever class is a data area
- * sized per the single argument to mctelem_init.  mcelem_init should be
+ * sized per the single argument to mctelem_init.  mctelem_init should be
  * called from MCA init code before anybody has the chance to change the
  * machine check vector with mcheck_mca_logout or to use mcheck_mca_logout.
  *
@@ -45,7 +45,7 @@
  * which will return a cookie referencing the oldest (first committed)
  * entry of the requested class.  Access the associated data using
  * mctelem_dataptr and when finished use mctelem_consume_oldest_end - in the
- * begin .. end bracket you are guaranteed that the entry canot be freed
+ * begin .. end bracket you are guaranteed that the entry cannot be freed
  * even if it is ack'd elsewhere).  Once the ultimate consumer of the
  * telemetry has processed it to stable storage it should acknowledge
  * the telemetry quoting the cookie id, at which point we will free
diff -r 6b73078a4403 xen/arch/x86/cpu/mcheck/non-fatal.c
--- a/xen/arch/x86/cpu/mcheck/non-fatal.c	Fri Oct 12 14:38:20 2012 +0200
+++ b/xen/arch/x86/cpu/mcheck/non-fatal.c	Fri Oct 12 15:20:08 2012 +0200
@@ -23,7 +23,6 @@
 #include "mce.h"
 #include "vmce.h"
 
-DEFINE_PER_CPU(struct mca_banks *, poll_bankmask);
 static struct timer mce_timer;
 
 #define MCE_PERIOD MILLISECS(8000)

--------------010209020108070809080102
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------010209020108070809080102--


From xen-devel-bounces@lists.xen.org Fri Oct 12 14:47:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 14:47:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMgVt-00024I-8D; Fri, 12 Oct 2012 14:46:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMgVr-000244-LA
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 14:46:55 +0000
Received: from [85.158.137.99:54966] by server-13.bemta-3.messagelabs.com id
	0F/F5-26794-E5D28705; Fri, 12 Oct 2012 14:46:54 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-217.messagelabs.com!1350053214!21328069!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NTM0NTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NTM0NTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17230 invoked from network); 12 Oct 2012 14:46:54 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-14.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Oct 2012 14:46:54 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHji0PEzM=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-090-010.pools.arcor-ip.net [88.65.90.10])
	by smtp.strato.de (jorabe mo22) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id R0599eo9CEjSAv ;
	Fri, 12 Oct 2012 16:46:54 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 8E79918642; Fri, 12 Oct 2012 16:46:53 +0200 (CEST)
Date: Fri, 12 Oct 2012 16:46:53 +0200
From: Olaf Hering 
To: Ian Campbell 
Message-ID: <20121012144653.GA22206@aepfle.de>
References: <597f0885494d0441b10c.1350051258@probook.site>
	<1350052613.14806.109.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1350052613.14806.109.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] hotplug/Linux: remove hotplug support,
 rely on udev instead
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 12, Ian Campbell wrote:

> On Fri, 2012-10-12 at 15:14 +0100, Olaf Hering wrote:
> > The patch by itself will have no practical impact unless someone
> > attempts to build and run a Xen dom0 on a really old base system.
> 
> Does anyone have any idea what sort of timeframe hotplug agent stuff
> really died in, just so we can document something?

SLES9 (back in 2007) had an early version of udev, hotplug was still in
use. It looks like hotplug.rpm was finally dropped from SuSE Linux in 2005.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 14:47:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 14:47:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMgVt-00024I-8D; Fri, 12 Oct 2012 14:46:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMgVr-000244-LA
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 14:46:55 +0000
Received: from [85.158.137.99:54966] by server-13.bemta-3.messagelabs.com id
	0F/F5-26794-E5D28705; Fri, 12 Oct 2012 14:46:54 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-217.messagelabs.com!1350053214!21328069!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NTM0NTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NTM0NTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17230 invoked from network); 12 Oct 2012 14:46:54 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-14.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Oct 2012 14:46:54 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHji0PEzM=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-090-010.pools.arcor-ip.net [88.65.90.10])
	by smtp.strato.de (jorabe mo22) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id R0599eo9CEjSAv ;
	Fri, 12 Oct 2012 16:46:54 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 8E79918642; Fri, 12 Oct 2012 16:46:53 +0200 (CEST)
Date: Fri, 12 Oct 2012 16:46:53 +0200
From: Olaf Hering 
To: Ian Campbell 
Message-ID: <20121012144653.GA22206@aepfle.de>
References: <597f0885494d0441b10c.1350051258@probook.site>
	<1350052613.14806.109.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1350052613.14806.109.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] hotplug/Linux: remove hotplug support,
 rely on udev instead
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 12, Ian Campbell wrote:

> On Fri, 2012-10-12 at 15:14 +0100, Olaf Hering wrote:
> > The patch by itself will have no practical impact unless someone
> > attempts to build and run a Xen dom0 on a really old base system.
> 
> Does anyone have any idea what sort of timeframe hotplug agent stuff
> really died in, just so we can document something?

SLES9 (back in 2007) had an early version of udev, hotplug was still in
use. It looks like hotplug.rpm was finally dropped from SuSE Linux in 2005.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 15:01:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 15:01:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMgjJ-0002PA-K3; Fri, 12 Oct 2012 15:00:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMgjH-0002P2-CW
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 15:00:47 +0000
Received: from [85.158.139.211:22483] by server-10.bemta-5.messagelabs.com id
	9E/EF-06995-E9038705; Fri, 12 Oct 2012 15:00:46 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1350054044!18125570!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYwMjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3225 invoked from network); 12 Oct 2012 15:00:45 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 15:00:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="41038810"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 14:59:27 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 12 Oct 2012
	10:59:26 -0400
Message-ID: <5078304D.1050807@citrix.com>
Date: Fri, 12 Oct 2012 15:59:25 +0100
From: David Vrabel 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk 
References: <1350046634-2462-1-git-send-email-david.vrabel@citrix.com>	<1350046634-2462-4-git-send-email-david.vrabel@citrix.com>	<20121012134147.GA11778@phenom.dumpdata.com>	<507822ED.2090900@citrix.com>
	
In-Reply-To: 
Cc: "xen-devel@lists.xen.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 3/3] xen/privcmd: add
 IOCTL_PRIVCMD_SYNC_WALLCLOCK to sync Xen's wallclock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/10/12 15:29, Konrad Rzeszutek Wilk wrote:
> On Fri, Oct 12, 2012 at 10:02 AM, David Vrabel  wrote:
>> On 12/10/12 14:41, Konrad Rzeszutek Wilk wrote:
>>> On Fri, Oct 12, 2012 at 01:57:14PM +0100, David Vrabel wrote:
>>>> From: David Vrabel 
>>>>
>>>> Add a new ioctl to synchronize Xen's wallclock with the current system
>>>> time.
>>>>
>>>> This may be used by the tools to ensure that newly created domains see
>>>> the correct wallclock time if NTP is not used in dom0 or if domains
>>>> are started before NTP has synchronized.
>>>
>>> So... how does this work with NTPD? As in does ntpd _not_ update the
>>> hwclock enough?
>>
>> Once NTPD is synchronized then the kernel updates the wallclock (and the
>> RTC with patch #1) every 11 mins.  I assume this is often enough given
>> how NTP adjusts the system time.
>>
>> You only really need the tools to sync wallclock if system time was
>> stepped at start of day.  e.g., init scripts could do something like:
>>
>> ntpdate pool.ntp.org
>> hwclock --systohc
>> xen-wallclock --systowc
> 
> I think I am missing something. The hwclock should end up in the
> xen_set_wallclock call. And from there on, the ntpd would update the
> wallclock if it got skewed enough? Or is the system time not calling
> the wall-clock enough? If that is the case, would just adding this in
> the crontab be enough:

hwclock talks to /dev/rtc which writes to the CMOS directly and does not
call update_persistent_clock() (or xen_set_wallclock()).

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 15:01:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 15:01:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMgjJ-0002PA-K3; Fri, 12 Oct 2012 15:00:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMgjH-0002P2-CW
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 15:00:47 +0000
Received: from [85.158.139.211:22483] by server-10.bemta-5.messagelabs.com id
	9E/EF-06995-E9038705; Fri, 12 Oct 2012 15:00:46 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1350054044!18125570!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYwMjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3225 invoked from network); 12 Oct 2012 15:00:45 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 15:00:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="41038810"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 14:59:27 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 12 Oct 2012
	10:59:26 -0400
Message-ID: <5078304D.1050807@citrix.com>
Date: Fri, 12 Oct 2012 15:59:25 +0100
From: David Vrabel 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk 
References: <1350046634-2462-1-git-send-email-david.vrabel@citrix.com>	<1350046634-2462-4-git-send-email-david.vrabel@citrix.com>	<20121012134147.GA11778@phenom.dumpdata.com>	<507822ED.2090900@citrix.com>
	
In-Reply-To: 
Cc: "xen-devel@lists.xen.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 3/3] xen/privcmd: add
 IOCTL_PRIVCMD_SYNC_WALLCLOCK to sync Xen's wallclock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/10/12 15:29, Konrad Rzeszutek Wilk wrote:
> On Fri, Oct 12, 2012 at 10:02 AM, David Vrabel  wrote:
>> On 12/10/12 14:41, Konrad Rzeszutek Wilk wrote:
>>> On Fri, Oct 12, 2012 at 01:57:14PM +0100, David Vrabel wrote:
>>>> From: David Vrabel 
>>>>
>>>> Add a new ioctl to synchronize Xen's wallclock with the current system
>>>> time.
>>>>
>>>> This may be used by the tools to ensure that newly created domains see
>>>> the correct wallclock time if NTP is not used in dom0 or if domains
>>>> are started before NTP has synchronized.
>>>
>>> So... how does this work with NTPD? As in does ntpd _not_ update the
>>> hwclock enough?
>>
>> Once NTPD is synchronized then the kernel updates the wallclock (and the
>> RTC with patch #1) every 11 mins.  I assume this is often enough given
>> how NTP adjusts the system time.
>>
>> You only really need the tools to sync wallclock if system time was
>> stepped at start of day.  e.g., init scripts could do something like:
>>
>> ntpdate pool.ntp.org
>> hwclock --systohc
>> xen-wallclock --systowc
> 
> I think I am missing something. The hwclock should end up in the
> xen_set_wallclock call. And from there on, the ntpd would update the
> wallclock if it got skewed enough? Or is the system time not calling
> the wall-clock enough? If that is the case, would just adding this in
> the crontab be enough:

hwclock talks to /dev/rtc which writes to the CMOS directly and does not
call update_persistent_clock() (or xen_set_wallclock()).

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 15:09:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 15:09:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMgrT-0002ZW-Iv; Fri, 12 Oct 2012 15:09:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMgrS-0002ZR-7d
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 15:09:14 +0000
Received: from [85.158.137.99:9870] by server-2.bemta-3.messagelabs.com id
	69/61-00604-99238705; Fri, 12 Oct 2012 15:09:13 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1350054551!18997551!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgwNzQ3OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15216 invoked from network); 12 Oct 2012 15:09:12 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-15.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Oct 2012 15:09:12 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9CF97rj008045
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 12 Oct 2012 15:09:08 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9CF97Mo003554
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 12 Oct 2012 15:09:07 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9CF97hb025098; Fri, 12 Oct 2012 10:09:07 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Oct 2012 08:09:07 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 414694037A; Fri, 12 Oct 2012 10:57:16 -0400 (EDT)
Date: Fri, 12 Oct 2012 10:57:16 -0400
From: Konrad Rzeszutek Wilk 
To: David Vrabel 
Message-ID: <20121012145716.GA20842@phenom.dumpdata.com>
References: <1350046634-2462-1-git-send-email-david.vrabel@citrix.com>
	<1350046634-2462-2-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1350046634-2462-2-git-send-email-david.vrabel@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/3] xen: sync the CMOS RTC as well as the
	Xen wallclock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 12, 2012 at 01:57:12PM +0100, David Vrabel wrote:
> From: David Vrabel 
> 
> If NTP is used in dom0 and it is synchronized to its clock source,
> then the kernel will periodically synchronize the Xen wallclock with
> the system time.  Updates to the Xen wallclock do not persist across
> reboots, so also synchronize the CMOS RTC (as on bare metal).
> 
> Signed-off-by: David Vrabel 
> ---
>  arch/x86/xen/time.c |    5 +++++
>  1 files changed, 5 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
> index 0296a95..5e7f536 100644
> --- a/arch/x86/xen/time.c
> +++ b/arch/x86/xen/time.c
> @@ -14,6 +14,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -208,6 +209,10 @@ static int xen_set_wallclock(unsigned long now)
>  	if (!xen_initial_domain())
>  		return -1;
>  
> +	/* Set the hardware RTC. */
> +	mach_set_rtc_mmss(now);

So how does this work? Is the hypervisor traping on the RTC CMOS clock?

> +
> +	/* Set the Xen wallclock. */
>  	op.cmd = XENPF_settime;
>  	op.u.settime.secs = now;
>  	op.u.settime.nsecs = 0;
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 15:09:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 15:09:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMgrT-0002ZW-Iv; Fri, 12 Oct 2012 15:09:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMgrS-0002ZR-7d
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 15:09:14 +0000
Received: from [85.158.137.99:9870] by server-2.bemta-3.messagelabs.com id
	69/61-00604-99238705; Fri, 12 Oct 2012 15:09:13 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1350054551!18997551!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgwNzQ3OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15216 invoked from network); 12 Oct 2012 15:09:12 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-15.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Oct 2012 15:09:12 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9CF97rj008045
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 12 Oct 2012 15:09:08 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9CF97Mo003554
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 12 Oct 2012 15:09:07 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9CF97hb025098; Fri, 12 Oct 2012 10:09:07 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Oct 2012 08:09:07 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 414694037A; Fri, 12 Oct 2012 10:57:16 -0400 (EDT)
Date: Fri, 12 Oct 2012 10:57:16 -0400
From: Konrad Rzeszutek Wilk 
To: David Vrabel 
Message-ID: <20121012145716.GA20842@phenom.dumpdata.com>
References: <1350046634-2462-1-git-send-email-david.vrabel@citrix.com>
	<1350046634-2462-2-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1350046634-2462-2-git-send-email-david.vrabel@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/3] xen: sync the CMOS RTC as well as the
	Xen wallclock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 12, 2012 at 01:57:12PM +0100, David Vrabel wrote:
> From: David Vrabel 
> 
> If NTP is used in dom0 and it is synchronized to its clock source,
> then the kernel will periodically synchronize the Xen wallclock with
> the system time.  Updates to the Xen wallclock do not persist across
> reboots, so also synchronize the CMOS RTC (as on bare metal).
> 
> Signed-off-by: David Vrabel 
> ---
>  arch/x86/xen/time.c |    5 +++++
>  1 files changed, 5 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
> index 0296a95..5e7f536 100644
> --- a/arch/x86/xen/time.c
> +++ b/arch/x86/xen/time.c
> @@ -14,6 +14,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -208,6 +209,10 @@ static int xen_set_wallclock(unsigned long now)
>  	if (!xen_initial_domain())
>  		return -1;
>  
> +	/* Set the hardware RTC. */
> +	mach_set_rtc_mmss(now);

So how does this work? Is the hypervisor traping on the RTC CMOS clock?

> +
> +	/* Set the Xen wallclock. */
>  	op.cmd = XENPF_settime;
>  	op.u.settime.secs = now;
>  	op.u.settime.nsecs = 0;
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 15:15:12 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 15:15:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMgwv-0002i0-Br; Fri, 12 Oct 2012 15:14:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMgwu-0002hv-6l
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 15:14:52 +0000
Received: from [85.158.143.35:28817] by server-3.bemta-4.messagelabs.com id
	05/AE-10075-BE338705; Fri, 12 Oct 2012 15:14:51 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1350054889!14441354!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgwNzQ3OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30863 invoked from network); 12 Oct 2012 15:14:50 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Oct 2012 15:14:50 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9CFEiRd014717
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 12 Oct 2012 15:14:44 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9CFEh4O008395
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 12 Oct 2012 15:14:43 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9CFEg3G029748; Fri, 12 Oct 2012 10:14:42 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Oct 2012 08:14:42 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id CBCDF4037A; Fri, 12 Oct 2012 11:02:51 -0400 (EDT)
Date: Fri, 12 Oct 2012 11:02:51 -0400
From: Konrad Rzeszutek Wilk 
To: David Vrabel 
Message-ID: <20121012150251.GB20842@phenom.dumpdata.com>
References: <1350046634-2462-1-git-send-email-david.vrabel@citrix.com>
	<1350046634-2462-4-git-send-email-david.vrabel@citrix.com>
	<20121012134147.GA11778@phenom.dumpdata.com>
	<507822ED.2090900@citrix.com>
	
	<5078304D.1050807@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5078304D.1050807@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Rzeszutek Wilk ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 3/3] xen/privcmd: add
 IOCTL_PRIVCMD_SYNC_WALLCLOCK to sync Xen's wallclock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 12, 2012 at 03:59:25PM +0100, David Vrabel wrote:
> On 12/10/12 15:29, Konrad Rzeszutek Wilk wrote:
> > On Fri, Oct 12, 2012 at 10:02 AM, David Vrabel  wrote:
> >> On 12/10/12 14:41, Konrad Rzeszutek Wilk wrote:
> >>> On Fri, Oct 12, 2012 at 01:57:14PM +0100, David Vrabel wrote:
> >>>> From: David Vrabel 
> >>>>
> >>>> Add a new ioctl to synchronize Xen's wallclock with the current system
> >>>> time.
> >>>>
> >>>> This may be used by the tools to ensure that newly created domains see
> >>>> the correct wallclock time if NTP is not used in dom0 or if domains
> >>>> are started before NTP has synchronized.
> >>>
> >>> So... how does this work with NTPD? As in does ntpd _not_ update the
> >>> hwclock enough?
> >>
> >> Once NTPD is synchronized then the kernel updates the wallclock (and the
> >> RTC with patch #1) every 11 mins.  I assume this is often enough given
> >> how NTP adjusts the system time.
> >>
> >> You only really need the tools to sync wallclock if system time was
> >> stepped at start of day.  e.g., init scripts could do something like:
> >>
> >> ntpdate pool.ntp.org
> >> hwclock --systohc
> >> xen-wallclock --systowc
> > 
> > I think I am missing something. The hwclock should end up in the
> > xen_set_wallclock call. And from there on, the ntpd would update the
> > wallclock if it got skewed enough? Or is the system time not calling
> > the wall-clock enough? If that is the case, would just adding this in
> > the crontab be enough:
> 
> hwclock talks to /dev/rtc which writes to the CMOS directly and does not
> call update_persistent_clock() (or xen_set_wallclock()).

/me scratches his head.

I recall that the update_persistent_clock() was being called.. with
hwclock -w (which is the same as --systohc).

That seems like a bug in the generic code - I would think that
hwclock would update the wallclock, not just the RTC.

Oh, it is whoever calls 'adjtimex' syscall ends up calling in
update_persistent_clock(). So .. ntpdate or ntpd don't call that?

Somebody does.. I hope?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 15:15:12 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 15:15:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMgwv-0002i0-Br; Fri, 12 Oct 2012 15:14:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMgwu-0002hv-6l
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 15:14:52 +0000
Received: from [85.158.143.35:28817] by server-3.bemta-4.messagelabs.com id
	05/AE-10075-BE338705; Fri, 12 Oct 2012 15:14:51 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1350054889!14441354!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgwNzQ3OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30863 invoked from network); 12 Oct 2012 15:14:50 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Oct 2012 15:14:50 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9CFEiRd014717
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 12 Oct 2012 15:14:44 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9CFEh4O008395
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 12 Oct 2012 15:14:43 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9CFEg3G029748; Fri, 12 Oct 2012 10:14:42 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Oct 2012 08:14:42 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id CBCDF4037A; Fri, 12 Oct 2012 11:02:51 -0400 (EDT)
Date: Fri, 12 Oct 2012 11:02:51 -0400
From: Konrad Rzeszutek Wilk 
To: David Vrabel 
Message-ID: <20121012150251.GB20842@phenom.dumpdata.com>
References: <1350046634-2462-1-git-send-email-david.vrabel@citrix.com>
	<1350046634-2462-4-git-send-email-david.vrabel@citrix.com>
	<20121012134147.GA11778@phenom.dumpdata.com>
	<507822ED.2090900@citrix.com>
	
	<5078304D.1050807@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5078304D.1050807@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Rzeszutek Wilk ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 3/3] xen/privcmd: add
 IOCTL_PRIVCMD_SYNC_WALLCLOCK to sync Xen's wallclock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 12, 2012 at 03:59:25PM +0100, David Vrabel wrote:
> On 12/10/12 15:29, Konrad Rzeszutek Wilk wrote:
> > On Fri, Oct 12, 2012 at 10:02 AM, David Vrabel  wrote:
> >> On 12/10/12 14:41, Konrad Rzeszutek Wilk wrote:
> >>> On Fri, Oct 12, 2012 at 01:57:14PM +0100, David Vrabel wrote:
> >>>> From: David Vrabel 
> >>>>
> >>>> Add a new ioctl to synchronize Xen's wallclock with the current system
> >>>> time.
> >>>>
> >>>> This may be used by the tools to ensure that newly created domains see
> >>>> the correct wallclock time if NTP is not used in dom0 or if domains
> >>>> are started before NTP has synchronized.
> >>>
> >>> So... how does this work with NTPD? As in does ntpd _not_ update the
> >>> hwclock enough?
> >>
> >> Once NTPD is synchronized then the kernel updates the wallclock (and the
> >> RTC with patch #1) every 11 mins.  I assume this is often enough given
> >> how NTP adjusts the system time.
> >>
> >> You only really need the tools to sync wallclock if system time was
> >> stepped at start of day.  e.g., init scripts could do something like:
> >>
> >> ntpdate pool.ntp.org
> >> hwclock --systohc
> >> xen-wallclock --systowc
> > 
> > I think I am missing something. The hwclock should end up in the
> > xen_set_wallclock call. And from there on, the ntpd would update the
> > wallclock if it got skewed enough? Or is the system time not calling
> > the wall-clock enough? If that is the case, would just adding this in
> > the crontab be enough:
> 
> hwclock talks to /dev/rtc which writes to the CMOS directly and does not
> call update_persistent_clock() (or xen_set_wallclock()).

/me scratches his head.

I recall that the update_persistent_clock() was being called.. with
hwclock -w (which is the same as --systohc).

That seems like a bug in the generic code - I would think that
hwclock would update the wallclock, not just the RTC.

Oh, it is whoever calls 'adjtimex' syscall ends up calling in
update_persistent_clock(). So .. ntpdate or ntpd don't call that?

Somebody does.. I hope?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 15:22:34 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 15:22:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMh43-0002rS-8i; Fri, 12 Oct 2012 15:22:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMh41-0002rM-3p
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 15:22:13 +0000
Received: from [85.158.143.99:21177] by server-2.bemta-4.messagelabs.com id
	55/CE-25171-4A538705; Fri, 12 Oct 2012 15:22:12 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-12.tower-216.messagelabs.com!1350055331!25778582!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMzk2MzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32284 invoked from network); 12 Oct 2012 15:22:11 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.119) by server-12.tower-216.messagelabs.com with SMTP;
	12 Oct 2012 15:22:11 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id B66BF5EC079;
	Fri, 12 Oct 2012 08:22:10 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=Q9yjztxRDvmXIsoGCjX+OJ
	vyOkGmczhvi/8vbtq8lZKUlyuxdbvqUXCPrwYeALRWwIsDrAgvnNrqwtcTBym9oY
	OwFgv2FQqPRRRmf7cbGv/JVlPQvXwYnDcwWLgzG4vPpfXZCr5d8b9niUk8ihw9K2
	VZtAyoblAr7z3LOWVHkCk=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=QW/UMn5iTUjD
	iwiPbf30UbHavgU=; b=Vir6VdpY1S9vrogSrtLNh1zjxnitwzddJJ1eYajMBkwT
	6jKX24oRpjw5Qmuz17oBYjrjXP5icz8sinoPVij25ugqtKy/Q1vOIFc4WKrSAUaF
	RbyR/cxW1ijsYm//5w1Rr6BL/+dKk5zgqeQax2SYJ4I+HCge2qRYWdqqDLib1mE=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPSA id 321515EC072; 
	Fri, 12 Oct 2012 08:22:10 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 5171750d133ef2c27ac89f1816699f5a1c62bc69
Message-Id: <5171750d133ef2c27ac8.1350055853@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 12 Oct 2012 11:30:53 -0400
From: Andres Lagar-Cavilla 
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH] Synchronize privcmd header constants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 tools/include/xen-sys/Linux/privcmd.h |   3 +++
 tools/libxc/xc_linux_osdep.c          |  10 +++++-----
 xen/include/public/domctl.h           |   1 -
 3 files changed, 8 insertions(+), 6 deletions(-)


Since Linux's git commit ceb90fa0a8008059ecbbf9114cb89dc71a730bb6, the
privcmd.h interface between Linux and libxc specifies two new constants,
PRIVCMD_MMAPBATCH_MFN_ERROR and PRIVCMD_MMAPBATCH_PAGED_ERROR. These constants
represent the error codes encoded in the top nibble of an mfn slot passed to
the legacy MMAPBATCH ioctl.

In particular, libxenctrl checks for the equivalent of the latter constant when
dealing with paged out frames that might be the target of a foreign map.

Previously, the relevant constant was defined in the domctl hypervisor
interface header (XEN_DOMCTL_PFINFO_PAGEDTAB). Because this top-nibble encoding
is a contract between the dom0 kernel and libxc, a domctl.h definition is
misplaced.

- Sync the privcmd.h header to that now available in upstream Linux
- Update libxc appropriately
- Remove the unnecessary constant in domctl.h

Signed-off-by: Andres Lagar-Cavilla 

diff -r 4eed5e64544f -r 5171750d133e tools/include/xen-sys/Linux/privcmd.h
--- a/tools/include/xen-sys/Linux/privcmd.h
+++ b/tools/include/xen-sys/Linux/privcmd.h
@@ -64,6 +64,9 @@ typedef struct privcmd_mmapbatch {
 	xen_pfn_t __user *arr; /* array of mfns - top nibble set on err */
 } privcmd_mmapbatch_t; 
 
+#define PRIVCMD_MMAPBATCH_MFN_ERROR     0xf0000000U
+#define PRIVCMD_MMAPBATCH_PAGED_ERROR   0x80000000U
+
 typedef struct privcmd_mmapbatch_v2 {
 	unsigned int num; /* number of pages to populate */
 	domid_t dom;      /* target domain */
diff -r 4eed5e64544f -r 5171750d133e tools/libxc/xc_linux_osdep.c
--- a/tools/libxc/xc_linux_osdep.c
+++ b/tools/libxc/xc_linux_osdep.c
@@ -129,7 +129,7 @@ static int xc_map_foreign_batch_single(i
 
     do
     {
-        *mfn ^= XEN_DOMCTL_PFINFO_PAGEDTAB;
+        *mfn ^= PRIVCMD_MMAPBATCH_PAGED_ERROR;
         usleep(100);
         rc = ioctl(fd, IOCTL_PRIVCMD_MMAPBATCH, &ioctlx);
     }
@@ -166,8 +166,8 @@ static void *linux_privcmd_map_foreign_b
 
         for ( i = 0; i < num; i++ )
         {
-            if ( (arr[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) ==
-                 XEN_DOMCTL_PFINFO_PAGEDTAB )
+            if ( (arr[i] & PRIVCMD_MMAPBATCH_MFN_ERROR) ==
+                           PRIVCMD_MMAPBATCH_PAGED_ERROR )
             {
                 unsigned long paged_addr = (unsigned long)addr + (i << XC_PAGE_SHIFT);
                 rc = xc_map_foreign_batch_single(fd, dom, &arr[i],
@@ -323,12 +323,12 @@ static void *linux_privcmd_map_foreign_b
             default:
                 err[i] = -EINVAL;
                 continue;
-            case XEN_DOMCTL_PFINFO_PAGEDTAB:
+            case PRIVCMD_MMAPBATCH_PAGED_ERROR:
                 if ( rc != -ENOENT )
                 {
                     err[i] = rc ?: -EINVAL;
                     continue;
-                 }
+                }
                 rc = xc_map_foreign_batch_single(fd, dom, pfn + i,
                         (unsigned long)addr + ((unsigned long)i<
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 15:22:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMh43-0002rS-8i; Fri, 12 Oct 2012 15:22:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMh41-0002rM-3p
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 15:22:13 +0000
Received: from [85.158.143.99:21177] by server-2.bemta-4.messagelabs.com id
	55/CE-25171-4A538705; Fri, 12 Oct 2012 15:22:12 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-12.tower-216.messagelabs.com!1350055331!25778582!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMzk2MzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32284 invoked from network); 12 Oct 2012 15:22:11 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.119) by server-12.tower-216.messagelabs.com with SMTP;
	12 Oct 2012 15:22:11 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id B66BF5EC079;
	Fri, 12 Oct 2012 08:22:10 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=Q9yjztxRDvmXIsoGCjX+OJ
	vyOkGmczhvi/8vbtq8lZKUlyuxdbvqUXCPrwYeALRWwIsDrAgvnNrqwtcTBym9oY
	OwFgv2FQqPRRRmf7cbGv/JVlPQvXwYnDcwWLgzG4vPpfXZCr5d8b9niUk8ihw9K2
	VZtAyoblAr7z3LOWVHkCk=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=QW/UMn5iTUjD
	iwiPbf30UbHavgU=; b=Vir6VdpY1S9vrogSrtLNh1zjxnitwzddJJ1eYajMBkwT
	6jKX24oRpjw5Qmuz17oBYjrjXP5icz8sinoPVij25ugqtKy/Q1vOIFc4WKrSAUaF
	RbyR/cxW1ijsYm//5w1Rr6BL/+dKk5zgqeQax2SYJ4I+HCge2qRYWdqqDLib1mE=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPSA id 321515EC072; 
	Fri, 12 Oct 2012 08:22:10 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 5171750d133ef2c27ac89f1816699f5a1c62bc69
Message-Id: <5171750d133ef2c27ac8.1350055853@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 12 Oct 2012 11:30:53 -0400
From: Andres Lagar-Cavilla 
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH] Synchronize privcmd header constants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 tools/include/xen-sys/Linux/privcmd.h |   3 +++
 tools/libxc/xc_linux_osdep.c          |  10 +++++-----
 xen/include/public/domctl.h           |   1 -
 3 files changed, 8 insertions(+), 6 deletions(-)


Since Linux's git commit ceb90fa0a8008059ecbbf9114cb89dc71a730bb6, the
privcmd.h interface between Linux and libxc specifies two new constants,
PRIVCMD_MMAPBATCH_MFN_ERROR and PRIVCMD_MMAPBATCH_PAGED_ERROR. These constants
represent the error codes encoded in the top nibble of an mfn slot passed to
the legacy MMAPBATCH ioctl.

In particular, libxenctrl checks for the equivalent of the latter constant when
dealing with paged out frames that might be the target of a foreign map.

Previously, the relevant constant was defined in the domctl hypervisor
interface header (XEN_DOMCTL_PFINFO_PAGEDTAB). Because this top-nibble encoding
is a contract between the dom0 kernel and libxc, a domctl.h definition is
misplaced.

- Sync the privcmd.h header to that now available in upstream Linux
- Update libxc appropriately
- Remove the unnecessary constant in domctl.h

Signed-off-by: Andres Lagar-Cavilla 

diff -r 4eed5e64544f -r 5171750d133e tools/include/xen-sys/Linux/privcmd.h
--- a/tools/include/xen-sys/Linux/privcmd.h
+++ b/tools/include/xen-sys/Linux/privcmd.h
@@ -64,6 +64,9 @@ typedef struct privcmd_mmapbatch {
 	xen_pfn_t __user *arr; /* array of mfns - top nibble set on err */
 } privcmd_mmapbatch_t; 
 
+#define PRIVCMD_MMAPBATCH_MFN_ERROR     0xf0000000U
+#define PRIVCMD_MMAPBATCH_PAGED_ERROR   0x80000000U
+
 typedef struct privcmd_mmapbatch_v2 {
 	unsigned int num; /* number of pages to populate */
 	domid_t dom;      /* target domain */
diff -r 4eed5e64544f -r 5171750d133e tools/libxc/xc_linux_osdep.c
--- a/tools/libxc/xc_linux_osdep.c
+++ b/tools/libxc/xc_linux_osdep.c
@@ -129,7 +129,7 @@ static int xc_map_foreign_batch_single(i
 
     do
     {
-        *mfn ^= XEN_DOMCTL_PFINFO_PAGEDTAB;
+        *mfn ^= PRIVCMD_MMAPBATCH_PAGED_ERROR;
         usleep(100);
         rc = ioctl(fd, IOCTL_PRIVCMD_MMAPBATCH, &ioctlx);
     }
@@ -166,8 +166,8 @@ static void *linux_privcmd_map_foreign_b
 
         for ( i = 0; i < num; i++ )
         {
-            if ( (arr[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) ==
-                 XEN_DOMCTL_PFINFO_PAGEDTAB )
+            if ( (arr[i] & PRIVCMD_MMAPBATCH_MFN_ERROR) ==
+                           PRIVCMD_MMAPBATCH_PAGED_ERROR )
             {
                 unsigned long paged_addr = (unsigned long)addr + (i << XC_PAGE_SHIFT);
                 rc = xc_map_foreign_batch_single(fd, dom, &arr[i],
@@ -323,12 +323,12 @@ static void *linux_privcmd_map_foreign_b
             default:
                 err[i] = -EINVAL;
                 continue;
-            case XEN_DOMCTL_PFINFO_PAGEDTAB:
+            case PRIVCMD_MMAPBATCH_PAGED_ERROR:
                 if ( rc != -ENOENT )
                 {
                     err[i] = rc ?: -EINVAL;
                     continue;
-                 }
+                }
                 rc = xc_map_foreign_batch_single(fd, dom, pfn + i,
                         (unsigned long)addr + ((unsigned long)i<
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 15:26:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMh8B-0002z1-38; Fri, 12 Oct 2012 15:26:31 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from ) id 1TMh6Z-0002wm-MN
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 15:24:51 +0000
X-Env-Sender: jking@internap.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1350055485!4660564!1
X-Originating-IP: [209.171.54.144]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjE3MS41NC4xNDQgPT4gMTI0NDky\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11984 invoked from network); 12 Oct 2012 15:24:45 -0000
Received: from cx295.800onemail.com (HELO cx295.800onemail.com)
	(209.171.54.144) by server-10.tower-27.messagelabs.com with SMTP;
	12 Oct 2012 15:24:45 -0000
Received: from EX13-N05.exchserver.com ([10.7.5.66])
	by cx295.800onemail.com (8.13.8/8.13.8) with ESMTP id q9CFOiLp012055
	for ; Fri, 12 Oct 2012 11:24:44 -0400
Received: from EX53.exchserver.com ([169.254.1.126]) by
	EX13-N05.exchserver.com ([10.7.40.160]) with mapi;
	Fri, 12 Oct 2012 11:24:44 -0400
From: James King 
To: "xen-devel@lists.xen.org" 
Date: Fri, 12 Oct 2012 11:24:47 -0400
Thread-Topic: agent corrupts /etc/shadow in CentOS 6
Thread-Index: Ac2ojbRgd1DrzIPbQwy8KSR8CiWHTg==
Message-ID: <40AC2ED0-ADA3-4880-8A55-EF29F17D954E@internap.com>
Accept-Language: en-US, en-CA
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-CA
x-crx-noroute: SMTP reroute not required
MIME-Version: 1.0
X-Mailman-Approved-At: Fri, 12 Oct 2012 15:26:30 +0000
Subject: [Xen-devel] agent corrupts /etc/shadow in CentOS 6
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I'm working on an issue we noticed in openstack where setting the root pass=
word on a CentOS 6 image through the XenAPI would corrupt the guest image's=
 /etc/shadow file.

1. set the root password through XenAPI
2. log in to the account
3. `passwd` -- you should get an error.

To fix you can `rm /etc/shadow; pwconv`

I've tested against an Ubuntu XCP image and everything is fine there=85 see=
ms to only affect CentOS 6
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 15:26:48 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 15:26:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMh8B-0002z1-38; Fri, 12 Oct 2012 15:26:31 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from ) id 1TMh6Z-0002wm-MN
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 15:24:51 +0000
X-Env-Sender: jking@internap.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1350055485!4660564!1
X-Originating-IP: [209.171.54.144]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjE3MS41NC4xNDQgPT4gMTI0NDky\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11984 invoked from network); 12 Oct 2012 15:24:45 -0000
Received: from cx295.800onemail.com (HELO cx295.800onemail.com)
	(209.171.54.144) by server-10.tower-27.messagelabs.com with SMTP;
	12 Oct 2012 15:24:45 -0000
Received: from EX13-N05.exchserver.com ([10.7.5.66])
	by cx295.800onemail.com (8.13.8/8.13.8) with ESMTP id q9CFOiLp012055
	for ; Fri, 12 Oct 2012 11:24:44 -0400
Received: from EX53.exchserver.com ([169.254.1.126]) by
	EX13-N05.exchserver.com ([10.7.40.160]) with mapi;
	Fri, 12 Oct 2012 11:24:44 -0400
From: James King 
To: "xen-devel@lists.xen.org" 
Date: Fri, 12 Oct 2012 11:24:47 -0400
Thread-Topic: agent corrupts /etc/shadow in CentOS 6
Thread-Index: Ac2ojbRgd1DrzIPbQwy8KSR8CiWHTg==
Message-ID: <40AC2ED0-ADA3-4880-8A55-EF29F17D954E@internap.com>
Accept-Language: en-US, en-CA
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-CA
x-crx-noroute: SMTP reroute not required
MIME-Version: 1.0
X-Mailman-Approved-At: Fri, 12 Oct 2012 15:26:30 +0000
Subject: [Xen-devel] agent corrupts /etc/shadow in CentOS 6
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I'm working on an issue we noticed in openstack where setting the root pass=
word on a CentOS 6 image through the XenAPI would corrupt the guest image's=
 /etc/shadow file.

1. set the root password through XenAPI
2. log in to the account
3. `passwd` -- you should get an error.

To fix you can `rm /etc/shadow; pwconv`

I've tested against an Ubuntu XCP image and everything is fine there=85 see=
ms to only affect CentOS 6
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 15:38:47 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 15:38:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMhJn-0003Ao-B7; Fri, 12 Oct 2012 15:38:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMhJl-0003Aj-U9
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 15:38:30 +0000
Received: from [85.158.143.35:45466] by server-3.bemta-4.messagelabs.com id
	92/A8-10075-57938705; Fri, 12 Oct 2012 15:38:29 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-3.tower-21.messagelabs.com!1350056297!14444604!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3785 invoked from network); 12 Oct 2012 15:38:18 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 15:38:18 -0000
Received: by mail-ie0-f173.google.com with SMTP id 17so6315437iea.32
	for ; Fri, 12 Oct 2012 08:38:17 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=from:content-type:content-transfer-encoding:subject:date:message-id
	:cc:to:mime-version:x-mailer:x-gm-message-state;
	bh=gt1hiB0Oqkp7DtXNuYZVlMyM2+akOH8NhvPqHt40vIY=;
	b=StlhXQjt4sbY1OwfMN+wCsIppMjRpx2d5dH23AjywweBrXSEHrIinciiMlK0sZrCdv
	S2xE2HW8HWzQIHNhAzmJ0djKICxIndneqEyulU22uiSZOB8Bddlv64YZHLvzNI8Oy2U5
	kFoUJFNIaSv1c2+L8OnVmtUHyD1hg70x9xnOv+DpOcm3P5eq5F86CJrwvh91j15ZHSsQ
	h1L9ni/NsbKA676n5dlgz2Pvth6EPh08+707n2xzte1pPgj4xI3dAF3Qya9AXkFpWtG6
	/ODA8pqRt0MbyWQFvUKQ1eaMcjWLgRK9s8AR8CvninnUjjxWNe8CVZYGYT8dSGqgANmg
	27UQ==
Received: by 10.50.151.238 with SMTP id ut14mr2500704igb.58.1350056297132;
	Fri, 12 Oct 2012 08:38:17 -0700 (PDT)
Received: from [192.168.3.238] ([206.223.182.18])
	by mx.google.com with ESMTPS id uj11sm1749183igb.15.2012.10.12.08.38.15
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 12 Oct 2012 08:38:16 -0700 (PDT)
From: Andres Lagar-Cavilla 
Date: Fri, 12 Oct 2012 11:38:14 -0400
Message-Id: <9105FC08-5D2C-440C-A0F7-C2F2D010E899@gridcentric.ca>
To: xen-devel@lists.xen.org
Mime-Version: 1.0 (Apple Message framework v1085)
X-Mailer: Apple Mail (2.1085)
X-Gm-Message-State: ALoCoQkRs8GaOCrHIuPittdVxyRSyV25vI+HwfeNG0eXm+O6Iq5Dphq8toFzIsU9RoIxoLD/vl9i
Cc: Olaf Hering , Keir Fraser ,
	Ian Campbell ,
	George Dunlap ,
	Tim Deegan , Jan Beulich 
Subject: [Xen-devel] Wait queue support for 4.3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

During the last Xen Summit there were informal discussions about the status of wait queues in the hypervisor.

To recap:
1. Wait queues are used in mem event, when events generated by a vcpu overflow the ring size
2. We would like to use wait queues when the hypervisor needs a paged out frame (say for hvm_copy)
3. We would like to use wait queues to avoid the two decoupled mmio emulation passes
4. We would like to use wait queues when the hypervisor needs write access to a shared frame (say for hvm copy), and unsharing temporarily fails with ENOMEM.

Conceivably more uses for wait queues may come down the line.

Use-cases 2. and 4. were left out of the time frame of 4.2, because a vcpu cannot go to sleep on a wait queue while holding a spinlock, and such situations would frequently arise. Preliminary patches from Tim Deegan have floated on the list (http://lists.xen.org/archives/html/xen-devel/2012-02/msg02133.html). We would like this functionality to be present on the mm side for 4.3, and then proceed to remove the "thinking" that consumers of the p2m interface now need to perform.
 
The current maintainer (effectively) for wait queues is Keir. Keir, any ideas on a schedule for the cleanup?

Thanks
Andres


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 15:38:47 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 15:38:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMhJn-0003Ao-B7; Fri, 12 Oct 2012 15:38:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMhJl-0003Aj-U9
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 15:38:30 +0000
Received: from [85.158.143.35:45466] by server-3.bemta-4.messagelabs.com id
	92/A8-10075-57938705; Fri, 12 Oct 2012 15:38:29 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-3.tower-21.messagelabs.com!1350056297!14444604!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3785 invoked from network); 12 Oct 2012 15:38:18 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 15:38:18 -0000
Received: by mail-ie0-f173.google.com with SMTP id 17so6315437iea.32
	for ; Fri, 12 Oct 2012 08:38:17 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=from:content-type:content-transfer-encoding:subject:date:message-id
	:cc:to:mime-version:x-mailer:x-gm-message-state;
	bh=gt1hiB0Oqkp7DtXNuYZVlMyM2+akOH8NhvPqHt40vIY=;
	b=StlhXQjt4sbY1OwfMN+wCsIppMjRpx2d5dH23AjywweBrXSEHrIinciiMlK0sZrCdv
	S2xE2HW8HWzQIHNhAzmJ0djKICxIndneqEyulU22uiSZOB8Bddlv64YZHLvzNI8Oy2U5
	kFoUJFNIaSv1c2+L8OnVmtUHyD1hg70x9xnOv+DpOcm3P5eq5F86CJrwvh91j15ZHSsQ
	h1L9ni/NsbKA676n5dlgz2Pvth6EPh08+707n2xzte1pPgj4xI3dAF3Qya9AXkFpWtG6
	/ODA8pqRt0MbyWQFvUKQ1eaMcjWLgRK9s8AR8CvninnUjjxWNe8CVZYGYT8dSGqgANmg
	27UQ==
Received: by 10.50.151.238 with SMTP id ut14mr2500704igb.58.1350056297132;
	Fri, 12 Oct 2012 08:38:17 -0700 (PDT)
Received: from [192.168.3.238] ([206.223.182.18])
	by mx.google.com with ESMTPS id uj11sm1749183igb.15.2012.10.12.08.38.15
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 12 Oct 2012 08:38:16 -0700 (PDT)
From: Andres Lagar-Cavilla 
Date: Fri, 12 Oct 2012 11:38:14 -0400
Message-Id: <9105FC08-5D2C-440C-A0F7-C2F2D010E899@gridcentric.ca>
To: xen-devel@lists.xen.org
Mime-Version: 1.0 (Apple Message framework v1085)
X-Mailer: Apple Mail (2.1085)
X-Gm-Message-State: ALoCoQkRs8GaOCrHIuPittdVxyRSyV25vI+HwfeNG0eXm+O6Iq5Dphq8toFzIsU9RoIxoLD/vl9i
Cc: Olaf Hering , Keir Fraser ,
	Ian Campbell ,
	George Dunlap ,
	Tim Deegan , Jan Beulich 
Subject: [Xen-devel] Wait queue support for 4.3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

During the last Xen Summit there were informal discussions about the status of wait queues in the hypervisor.

To recap:
1. Wait queues are used in mem event, when events generated by a vcpu overflow the ring size
2. We would like to use wait queues when the hypervisor needs a paged out frame (say for hvm_copy)
3. We would like to use wait queues to avoid the two decoupled mmio emulation passes
4. We would like to use wait queues when the hypervisor needs write access to a shared frame (say for hvm copy), and unsharing temporarily fails with ENOMEM.

Conceivably more uses for wait queues may come down the line.

Use-cases 2. and 4. were left out of the time frame of 4.2, because a vcpu cannot go to sleep on a wait queue while holding a spinlock, and such situations would frequently arise. Preliminary patches from Tim Deegan have floated on the list (http://lists.xen.org/archives/html/xen-devel/2012-02/msg02133.html). We would like this functionality to be present on the mm side for 4.3, and then proceed to remove the "thinking" that consumers of the p2m interface now need to perform.
 
The current maintainer (effectively) for wait queues is Keir. Keir, any ideas on a schedule for the cleanup?

Thanks
Andres


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 15:45:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 15:45:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMhPq-0003Lb-El; Fri, 12 Oct 2012 15:44:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMhPo-0003LO-Hj; Fri, 12 Oct 2012 15:44:44 +0000
Received: from [85.158.139.211:6259] by server-7.bemta-5.messagelabs.com id
	08/B3-20187-BEA38705; Fri, 12 Oct 2012 15:44:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1350056683!21650292!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQzMTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30163 invoked from network); 12 Oct 2012 15:44:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 15:44:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="15132581"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 15:44:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 12 Oct 2012 16:44:42 +0100
Message-ID: <1350056681.14806.118.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: James King 
Date: Fri, 12 Oct 2012 16:44:41 +0100
In-Reply-To: <40AC2ED0-ADA3-4880-8A55-EF29F17D954E@internap.com>
References: <40AC2ED0-ADA3-4880-8A55-EF29F17D954E@internap.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-api@lists.xen.org, "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] agent corrupts /etc/shadow in CentOS 6
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Q0NpbmcgeGVuLWFwaSBsaXN0IHdoZXJlIFhlbkFQSS9YQ1AgZGV2ZWxvcG1lbnQgaGFwcGVucy4K
Ck9uIEZyaSwgMjAxMi0xMC0xMiBhdCAxNjoyNCArMDEwMCwgSmFtZXMgS2luZyB3cm90ZToKPiBJ
J20gd29ya2luZyBvbiBhbiBpc3N1ZSB3ZSBub3RpY2VkIGluIG9wZW5zdGFjayB3aGVyZSBzZXR0
aW5nIHRoZSByb290IHBhc3N3b3JkIG9uIGEgQ2VudE9TIDYgaW1hZ2UgdGhyb3VnaCB0aGUgWGVu
QVBJIHdvdWxkIGNvcnJ1cHQgdGhlIGd1ZXN0IGltYWdlJ3MgL2V0Yy9zaGFkb3cgZmlsZS4KPiAK
PiAxLiBzZXQgdGhlIHJvb3QgcGFzc3dvcmQgdGhyb3VnaCBYZW5BUEkKPiAyLiBsb2cgaW4gdG8g
dGhlIGFjY291bnQKPiAzLiBgcGFzc3dkYCAtLSB5b3Ugc2hvdWxkIGdldCBhbiBlcnJvci4KPiAK
PiBUbyBmaXggeW91IGNhbiBgcm0gL2V0Yy9zaGFkb3c7IHB3Y29udmAKPiAKPiBJJ3ZlIHRlc3Rl
ZCBhZ2FpbnN0IGFuIFVidW50dSBYQ1AgaW1hZ2UgYW5kIGV2ZXJ5dGhpbmcgaXMgZmluZSB0aGVy
ZeKApiBzZWVtcyB0byBvbmx5IGFmZmVjdCBDZW50T1MgNgo+IF9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gWGVuLWRldmVsIG1haWxpbmcgbGlzdAo+IFhl
bi1kZXZlbEBsaXN0cy54ZW4ub3JnCj4gaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCgoK
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZl
bCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5v
cmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Fri Oct 12 15:45:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 15:45:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMhPq-0003Lb-El; Fri, 12 Oct 2012 15:44:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMhPo-0003LO-Hj; Fri, 12 Oct 2012 15:44:44 +0000
Received: from [85.158.139.211:6259] by server-7.bemta-5.messagelabs.com id
	08/B3-20187-BEA38705; Fri, 12 Oct 2012 15:44:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1350056683!21650292!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQzMTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30163 invoked from network); 12 Oct 2012 15:44:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 15:44:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="15132581"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 15:44:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 12 Oct 2012 16:44:42 +0100
Message-ID: <1350056681.14806.118.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: James King 
Date: Fri, 12 Oct 2012 16:44:41 +0100
In-Reply-To: <40AC2ED0-ADA3-4880-8A55-EF29F17D954E@internap.com>
References: <40AC2ED0-ADA3-4880-8A55-EF29F17D954E@internap.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-api@lists.xen.org, "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] agent corrupts /etc/shadow in CentOS 6
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Q0NpbmcgeGVuLWFwaSBsaXN0IHdoZXJlIFhlbkFQSS9YQ1AgZGV2ZWxvcG1lbnQgaGFwcGVucy4K
Ck9uIEZyaSwgMjAxMi0xMC0xMiBhdCAxNjoyNCArMDEwMCwgSmFtZXMgS2luZyB3cm90ZToKPiBJ
J20gd29ya2luZyBvbiBhbiBpc3N1ZSB3ZSBub3RpY2VkIGluIG9wZW5zdGFjayB3aGVyZSBzZXR0
aW5nIHRoZSByb290IHBhc3N3b3JkIG9uIGEgQ2VudE9TIDYgaW1hZ2UgdGhyb3VnaCB0aGUgWGVu
QVBJIHdvdWxkIGNvcnJ1cHQgdGhlIGd1ZXN0IGltYWdlJ3MgL2V0Yy9zaGFkb3cgZmlsZS4KPiAK
PiAxLiBzZXQgdGhlIHJvb3QgcGFzc3dvcmQgdGhyb3VnaCBYZW5BUEkKPiAyLiBsb2cgaW4gdG8g
dGhlIGFjY291bnQKPiAzLiBgcGFzc3dkYCAtLSB5b3Ugc2hvdWxkIGdldCBhbiBlcnJvci4KPiAK
PiBUbyBmaXggeW91IGNhbiBgcm0gL2V0Yy9zaGFkb3c7IHB3Y29udmAKPiAKPiBJJ3ZlIHRlc3Rl
ZCBhZ2FpbnN0IGFuIFVidW50dSBYQ1AgaW1hZ2UgYW5kIGV2ZXJ5dGhpbmcgaXMgZmluZSB0aGVy
ZeKApiBzZWVtcyB0byBvbmx5IGFmZmVjdCBDZW50T1MgNgo+IF9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gWGVuLWRldmVsIG1haWxpbmcgbGlzdAo+IFhl
bi1kZXZlbEBsaXN0cy54ZW4ub3JnCj4gaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCgoK
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZl
bCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5v
cmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Fri Oct 12 15:46:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 15:46:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMhRH-0003Ss-UD; Fri, 12 Oct 2012 15:46:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMhRG-0003Sj-Ow
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 15:46:15 +0000
Received: from [85.158.143.35:29507] by server-1.bemta-4.messagelabs.com id
	17/34-19551-64B38705; Fri, 12 Oct 2012 15:46:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1350056772!5055931!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQzMTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21726 invoked from network); 12 Oct 2012 15:46:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 15:46:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="15132624"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 15:45:40 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 12 Oct 2012 16:45:40 +0100
Message-ID: <1350056739.14806.119.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Ian Jackson , Roger Pau Monne
	
Date: Fri, 12 Oct 2012 16:45:39 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel 
Subject: [Xen-devel] Unable to start a domain with no disks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Trying to start a very simple domain with no disk from:
        name="x"
        memory=128
        kernel="/scratch/debian/squeeze/amd64/vmlinuz"
        ramdisk="/scratch/debian/squeeze/amd64/initrd.gz"
        extra="console=hvc0"
        vcpus=1
Results in:
        xl: libxl_event.c:1522: libxl__ao_complete_check_progress_reports: Assertion `ao->in_initiator' failed.
if I try to autoconnnect the console (ie. xl cr -c).

If I don't try and auto connect to the console then everything is fine
and I can subsequently use "xl cons" to connect.

Backtrace is:
        xl: libxl_event.c:1522: libxl__ao_complete_check_progress_reports: Assertion `ao->in_initiator' failed.
        
        Program received signal SIGABRT, Aborted.
        0xff7fe424 in __kernel_vsyscall ()
        (gdb) bt
        #0  0xff7fe424 in __kernel_vsyscall ()
        #1  0xb7e18781 in raise () from /lib/i686/cmov/libc.so.6
        #2  0xb7e1bbb2 in abort () from /lib/i686/cmov/libc.so.6
        #3  0xb7e118e8 in __assert_fail () from /lib/i686/cmov/libc.so.6
        #4  0xb7faf7c1 in libxl__ao_complete_check_progress_reports (egc=0xbffff42c, ao=0x806a870) at libxl_event.c:1522
        #5  0xb7fb035b in egc_run_callbacks (egc=0xbffff42c) at libxl_event.c:1095
        #6  libxl__egc_cleanup (egc=0xbffff42c) at libxl_event.c:1116
        #7  0xb7f95059 in do_domain_create (ctx=, d_config=, domid=0xbffff74c, restore_fd=-1, ao_how=0x0, aop_console_how=0xbffff54c) at libxl_create.c:1197
        #8  0xb7f9510f in libxl_domain_create_new (ctx=0x806a030, d_config=0xbffff59c, domid=0xbffff74c, ao_how=0x0, aop_console_how=0xbffff54c) at libxl_create.c:1218
        #9  0x0805c5a7 in create_domain (dom_info=) at xl_cmdimpl.c:1932
        #10 0x0805ded2 in main_create (argc=3, argv=0xbffffe5a) at xl_cmdimpl.c:3973
        #11 0x0804d41e in main (argc=4, argv=0xbffffd24) at xl.c:285

Full log follows below. Any ideas?

Ian.



        # xl -vvv cr -c x
        Parsing config from x
        libxl: debug: libxl_create.c:1184:do_domain_create: ao 0x806a870: create: how=(nil) callback=(nil) poller=0x806a8b0
        libxl: debug: libxl_create.c:677:initiate_domain_create: running bootloader
        libxl: debug: libxl_bootloader.c:327:libxl__bootloader_run: no bootloader configured, using user supplied kernel
        libxl: debug: libxl_event.c:561:libxl__ev_xswatch_deregister: watch w=0x806aa84: deregister unregistered
        libxl: debug: libxl_numa.c:435:libxl__get_numa_candidate: New best NUMA placement candidate found: nr_nodes=1, nr_cpus=4, nr_vcpus=5, free_memkb=3467
        libxl: detail: libxl_dom.c:192:numa_place_domain: NUMA placement candidate with 1 nodes, 4 cpus and 3467 KB free selected
        domainbuilder: detail: xc_dom_allocate: cmdline="console=hvc0", features="(null)"
        libxl: debug: libxl_dom.c:380:libxl__build_pv: pv kernel mapped 0 path /scratch/debian/squeeze/amd64/vmlinuz
        
        domainbuilder: detail: xc_dom_kernel_file: filename="/scratch/debian/squeeze/amd64/vmlinuz"
        domainbuilder: detail: xc_dom_malloc_filemap    : 2367 kB
        domainbuilder: detail: xc_dom_ramdisk_file: filename="/scratch/debian/squeeze/amd64/initrd.gz"
        domainbuilder: detail: xc_dom_malloc_filemap    : 19090 kB
        domainbuilder: detail: xc_dom_boot_xen_init: ver 4.3, caps xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 
        domainbuilder: detail: xc_dom_parse_image: called
        domainbuilder: detail: xc_dom_find_loader: trying ELF-generic loader ... 
        domainbuilder: detail: loader probe failed
        domainbuilder: detail: xc_dom_find_loader: trying Linux bzImage loader ... 
        domainbuilder: detail: xc_dom_malloc            : 11914 kB
        domainbuilder: detail: xc_dom_do_gunzip: unzip ok, 0x2485c8 -> 0xba2b00
        domainbuilder: detail: loader probe OK
        xc: detail: elf_parse_binary: phdr: paddr=0x1000000 memsz=0x42d000
        xc: detail: elf_parse_binary: phdr: paddr=0x142d000 memsz=0xd6150
        xc: detail: elf_parse_binary: phdr: paddr=0x1504000 memsz=0x888
        xc: detail: elf_parse_binary: phdr: paddr=0x1505000 memsz=0x160d8
        xc: detail: elf_parse_binary: phdr: paddr=0x151c000 memsz=0x1de000
        xc: detail: elf_parse_binary: memory: 0x1000000 -> 0x16fa000
        xc: detail: elf_xen_parse_note: GUEST_OS = "linux"
        xc: detail: elf_xen_parse_note: GUEST_VERSION = "2.6"
        xc: detail: elf_xen_parse_note: XEN_VERSION = "xen-3.0"
        xc: detail: elf_xen_parse_note: VIRT_BASE = 0xffffffff80000000
        xc: detail: elf_xen_parse_note: ENTRY = 0xffffffff8151c200
        xc: detail: elf_xen_parse_note: HYPERCALL_PAGE = 0xffffffff81009000
        xc: detail: elf_xen_parse_note: FEATURES = "!writable_page_tables|pae_pgdir_above_4gb"
        xc: detail: elf_xen_parse_note: PAE_MODE = "yes"
        xc: detail: elf_xen_parse_note: LOADER = "generic"
        xc: detail: elf_xen_parse_note: unknown xen elf note (0xd)
        xc: detail: elf_xen_parse_note: SUSPEND_CANCEL = 0x1
        xc: detail: elf_xen_parse_note: HV_START_LOW = 0xffff800000000000
        xc: detail: elf_xen_parse_note: PADDR_OFFSET = 0x0
        xc: detail: elf_xen_addr_calc_check: addresses:
        xc: detail:     virt_base        = 0xffffffff80000000
        xc: detail:     elf_paddr_offset = 0x0
        xc: detail:     virt_offset      = 0xffffffff80000000
        xc: detail:     virt_kstart      = 0xffffffff81000000
        xc: detail:     virt_kend        = 0xffffffff816fa000
        xc: detail:     virt_entry       = 0xffffffff8151c200
        xc: detail:     p2m_base         = 0xffffffffffffffff
        domainbuilder: detail: xc_dom_parse_elf_kernel: xen-3.0-x86_64: 0xffffffff81000000 -> 0xffffffff816fa000
        domainbuilder: detail: xc_dom_mem_init: mem 128 MB, pages 0x8000 pages, 4k each
        domainbuilder: detail: xc_dom_mem_init: 0x8000 pages
        domainbuilder: detail: xc_dom_boot_mem_init: called
        domainbuilder: detail: x86_compat: guest xen-3.0-x86_64, address size 64
        domainbuilder: detail: xc_dom_malloc            : 128 kB
        domainbuilder: detail: xc_dom_build_image: called
        domainbuilder: detail: xc_dom_alloc_segment:   kernel       : 0xffffffff81000000 -> 0xffffffff816fa000  (pfn 0x1000 + 0x6fa pages)
        domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x1000+0x6fa at 0xb4ce6000
        xc: detail: elf_load_binary: phdr 0 at 0x0xb4ce6000 -> 0x0xb5113000
        xc: detail: elf_load_binary: phdr 1 at 0x0xb5113000 -> 0x0xb51e9150
        xc: detail: elf_load_binary: phdr 2 at 0x0xb51ea000 -> 0x0xb51ea888
        xc: detail: elf_load_binary: phdr 3 at 0x0xb51eb000 -> 0x0xb52010d8
        xc: detail: elf_load_binary: phdr 4 at 0x0xb5202000 -> 0x0xb5288000
        domainbuilder: detail: xc_dom_alloc_segment:   ramdisk      : 0xffffffff816fa000 -> 0xffffffff8481c000  (pfn 0x16fa + 0x3122 pages)
        domainbuilder: detail: xc_dom_malloc            : 294 kB
        domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x16fa+0x3122 at 0xb1b7a000
        domainbuilder: detail: xc_dom_do_gunzip: unzip ok, 0x12a4954 -> 0x3121e10
        domainbuilder: detail: xc_dom_alloc_segment:   phys2mach    : 0xffffffff8481c000 -> 0xffffffff8485c000  (pfn 0x481c + 0x40 pages)
        domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x481c+0x40 at 0xb1b3a000
        domainbuilder: detail: xc_dom_alloc_page   :   start info   : 0xffffffff8485c000 (pfn 0x485c)
        domainbuilder: detail: xc_dom_alloc_page   :   xenstore     : 0xffffffff8485d000 (pfn 0x485d)
        domainbuilder: detail: xc_dom_alloc_page   :   console      : 0xffffffff8485e000 (pfn 0x485e)
        domainbuilder: detail: nr_page_tables: 0x0000ffffffffffff/48: 0xffff000000000000 -> 0xffffffffffffffff, 1 table(s)
        domainbuilder: detail: nr_page_tables: 0x0000007fffffffff/39: 0xffffff8000000000 -> 0xffffffffffffffff, 1 table(s)
        domainbuilder: detail: nr_page_tables: 0x000000003fffffff/30: 0xffffffff80000000 -> 0xffffffffbfffffff, 1 table(s)
        domainbuilder: detail: nr_page_tables: 0x00000000001fffff/21: 0xffffffff80000000 -> 0xffffffff84bfffff, 38 table(s)
        domainbuilder: detail: xc_dom_alloc_segment:   page tables  : 0xffffffff8485f000 -> 0xffffffff84888000  (pfn 0x485f + 0x29 pages)
        domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x485f+0x29 at 0xb1b11000
        domainbuilder: detail: xc_dom_alloc_page   :   boot stack   : 0xffffffff84888000 (pfn 0x4888)
        domainbuilder: detail: xc_dom_build_image  : virt_alloc_end : 0xffffffff84889000
        domainbuilder: detail: xc_dom_build_image  : virt_pgtab_end : 0xffffffff84c00000
        domainbuilder: detail: xc_dom_boot_image: called
        domainbuilder: detail: arch_setup_bootearly: doing nothing
        domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-x86_64 <= matches
        domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-x86_32p
        domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_32
        domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_32p
        domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_64
        domainbuilder: detail: xc_dom_update_guest_p2m: dst 64bit, pages 0x8000
        domainbuilder: detail: clear_page: pfn 0x485e, mfn 0xdc43d
        domainbuilder: detail: clear_page: pfn 0x485d, mfn 0xdc43e
        domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x485c+0x1 at 0xb1b0e000
        domainbuilder: detail: start_info_x86_64: called
        domainbuilder: detail: setup_hypercall_page: vaddr=0xffffffff81009000 pfn=0x1009
        domainbuilder: detail: domain builder memory footprint
        domainbuilder: detail:    allocated
        domainbuilder: detail:       malloc             : 12383 kB
        domainbuilder: detail:       anon mmap          : 0 bytes
        domainbuilder: detail:    mapped
        domainbuilder: detail:       file mmap          : 21457 kB
        domainbuilder: detail:       domU mmap          : 56 MB
        domainbuilder: detail: arch_setup_bootlate: shared_info: pfn 0x0, mfn 0xdccc8
        domainbuilder: detail: shared_info_x86_64: called
        domainbuilder: detail: vcpu_x86_64: called
        domainbuilder: detail: vcpu_x86_64: cr3: pfn 0x485f mfn 0xdc43c
        domainbuilder: detail: launch_vm: called, ctxt=0xbfd9c2ec
        domainbuilder: detail: xc_dom_release: called
        libxl: debug: libxl_event.c:1677:libxl__ao_progress_report: ao 0x806a870: progress report: callback queued aop=0x806c010
        libxl: debug: libxl_event.c:1497:libxl__ao_complete: ao 0x806a870: complete, rc=0
        libxl: debug: libxl_create.c:1197:do_domain_create: ao 0x806a870: inprogress: poller=0x806a8b0, flags=ic
        libxl: debug: libxl_event.c:1469:libxl__ao__destroy: ao 0x806a870: destroy
        libxl: debug: libxl_event.c:1090:egc_run_callbacks: ao 0x806a870: progress report: callback aop=0x806c010
        xl: libxl_event.c:1522: libxl__ao_complete_check_progress_reports: Assertion `ao->in_initiator' failed.
        Aborted
        


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 15:46:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 15:46:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMhRH-0003Ss-UD; Fri, 12 Oct 2012 15:46:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMhRG-0003Sj-Ow
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 15:46:15 +0000
Received: from [85.158.143.35:29507] by server-1.bemta-4.messagelabs.com id
	17/34-19551-64B38705; Fri, 12 Oct 2012 15:46:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1350056772!5055931!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQzMTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21726 invoked from network); 12 Oct 2012 15:46:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 15:46:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="15132624"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 15:45:40 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 12 Oct 2012 16:45:40 +0100
Message-ID: <1350056739.14806.119.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Ian Jackson , Roger Pau Monne
	
Date: Fri, 12 Oct 2012 16:45:39 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel 
Subject: [Xen-devel] Unable to start a domain with no disks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Trying to start a very simple domain with no disk from:
        name="x"
        memory=128
        kernel="/scratch/debian/squeeze/amd64/vmlinuz"
        ramdisk="/scratch/debian/squeeze/amd64/initrd.gz"
        extra="console=hvc0"
        vcpus=1
Results in:
        xl: libxl_event.c:1522: libxl__ao_complete_check_progress_reports: Assertion `ao->in_initiator' failed.
if I try to autoconnnect the console (ie. xl cr -c).

If I don't try and auto connect to the console then everything is fine
and I can subsequently use "xl cons" to connect.

Backtrace is:
        xl: libxl_event.c:1522: libxl__ao_complete_check_progress_reports: Assertion `ao->in_initiator' failed.
        
        Program received signal SIGABRT, Aborted.
        0xff7fe424 in __kernel_vsyscall ()
        (gdb) bt
        #0  0xff7fe424 in __kernel_vsyscall ()
        #1  0xb7e18781 in raise () from /lib/i686/cmov/libc.so.6
        #2  0xb7e1bbb2 in abort () from /lib/i686/cmov/libc.so.6
        #3  0xb7e118e8 in __assert_fail () from /lib/i686/cmov/libc.so.6
        #4  0xb7faf7c1 in libxl__ao_complete_check_progress_reports (egc=0xbffff42c, ao=0x806a870) at libxl_event.c:1522
        #5  0xb7fb035b in egc_run_callbacks (egc=0xbffff42c) at libxl_event.c:1095
        #6  libxl__egc_cleanup (egc=0xbffff42c) at libxl_event.c:1116
        #7  0xb7f95059 in do_domain_create (ctx=, d_config=, domid=0xbffff74c, restore_fd=-1, ao_how=0x0, aop_console_how=0xbffff54c) at libxl_create.c:1197
        #8  0xb7f9510f in libxl_domain_create_new (ctx=0x806a030, d_config=0xbffff59c, domid=0xbffff74c, ao_how=0x0, aop_console_how=0xbffff54c) at libxl_create.c:1218
        #9  0x0805c5a7 in create_domain (dom_info=) at xl_cmdimpl.c:1932
        #10 0x0805ded2 in main_create (argc=3, argv=0xbffffe5a) at xl_cmdimpl.c:3973
        #11 0x0804d41e in main (argc=4, argv=0xbffffd24) at xl.c:285

Full log follows below. Any ideas?

Ian.



        # xl -vvv cr -c x
        Parsing config from x
        libxl: debug: libxl_create.c:1184:do_domain_create: ao 0x806a870: create: how=(nil) callback=(nil) poller=0x806a8b0
        libxl: debug: libxl_create.c:677:initiate_domain_create: running bootloader
        libxl: debug: libxl_bootloader.c:327:libxl__bootloader_run: no bootloader configured, using user supplied kernel
        libxl: debug: libxl_event.c:561:libxl__ev_xswatch_deregister: watch w=0x806aa84: deregister unregistered
        libxl: debug: libxl_numa.c:435:libxl__get_numa_candidate: New best NUMA placement candidate found: nr_nodes=1, nr_cpus=4, nr_vcpus=5, free_memkb=3467
        libxl: detail: libxl_dom.c:192:numa_place_domain: NUMA placement candidate with 1 nodes, 4 cpus and 3467 KB free selected
        domainbuilder: detail: xc_dom_allocate: cmdline="console=hvc0", features="(null)"
        libxl: debug: libxl_dom.c:380:libxl__build_pv: pv kernel mapped 0 path /scratch/debian/squeeze/amd64/vmlinuz
        
        domainbuilder: detail: xc_dom_kernel_file: filename="/scratch/debian/squeeze/amd64/vmlinuz"
        domainbuilder: detail: xc_dom_malloc_filemap    : 2367 kB
        domainbuilder: detail: xc_dom_ramdisk_file: filename="/scratch/debian/squeeze/amd64/initrd.gz"
        domainbuilder: detail: xc_dom_malloc_filemap    : 19090 kB
        domainbuilder: detail: xc_dom_boot_xen_init: ver 4.3, caps xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 
        domainbuilder: detail: xc_dom_parse_image: called
        domainbuilder: detail: xc_dom_find_loader: trying ELF-generic loader ... 
        domainbuilder: detail: loader probe failed
        domainbuilder: detail: xc_dom_find_loader: trying Linux bzImage loader ... 
        domainbuilder: detail: xc_dom_malloc            : 11914 kB
        domainbuilder: detail: xc_dom_do_gunzip: unzip ok, 0x2485c8 -> 0xba2b00
        domainbuilder: detail: loader probe OK
        xc: detail: elf_parse_binary: phdr: paddr=0x1000000 memsz=0x42d000
        xc: detail: elf_parse_binary: phdr: paddr=0x142d000 memsz=0xd6150
        xc: detail: elf_parse_binary: phdr: paddr=0x1504000 memsz=0x888
        xc: detail: elf_parse_binary: phdr: paddr=0x1505000 memsz=0x160d8
        xc: detail: elf_parse_binary: phdr: paddr=0x151c000 memsz=0x1de000
        xc: detail: elf_parse_binary: memory: 0x1000000 -> 0x16fa000
        xc: detail: elf_xen_parse_note: GUEST_OS = "linux"
        xc: detail: elf_xen_parse_note: GUEST_VERSION = "2.6"
        xc: detail: elf_xen_parse_note: XEN_VERSION = "xen-3.0"
        xc: detail: elf_xen_parse_note: VIRT_BASE = 0xffffffff80000000
        xc: detail: elf_xen_parse_note: ENTRY = 0xffffffff8151c200
        xc: detail: elf_xen_parse_note: HYPERCALL_PAGE = 0xffffffff81009000
        xc: detail: elf_xen_parse_note: FEATURES = "!writable_page_tables|pae_pgdir_above_4gb"
        xc: detail: elf_xen_parse_note: PAE_MODE = "yes"
        xc: detail: elf_xen_parse_note: LOADER = "generic"
        xc: detail: elf_xen_parse_note: unknown xen elf note (0xd)
        xc: detail: elf_xen_parse_note: SUSPEND_CANCEL = 0x1
        xc: detail: elf_xen_parse_note: HV_START_LOW = 0xffff800000000000
        xc: detail: elf_xen_parse_note: PADDR_OFFSET = 0x0
        xc: detail: elf_xen_addr_calc_check: addresses:
        xc: detail:     virt_base        = 0xffffffff80000000
        xc: detail:     elf_paddr_offset = 0x0
        xc: detail:     virt_offset      = 0xffffffff80000000
        xc: detail:     virt_kstart      = 0xffffffff81000000
        xc: detail:     virt_kend        = 0xffffffff816fa000
        xc: detail:     virt_entry       = 0xffffffff8151c200
        xc: detail:     p2m_base         = 0xffffffffffffffff
        domainbuilder: detail: xc_dom_parse_elf_kernel: xen-3.0-x86_64: 0xffffffff81000000 -> 0xffffffff816fa000
        domainbuilder: detail: xc_dom_mem_init: mem 128 MB, pages 0x8000 pages, 4k each
        domainbuilder: detail: xc_dom_mem_init: 0x8000 pages
        domainbuilder: detail: xc_dom_boot_mem_init: called
        domainbuilder: detail: x86_compat: guest xen-3.0-x86_64, address size 64
        domainbuilder: detail: xc_dom_malloc            : 128 kB
        domainbuilder: detail: xc_dom_build_image: called
        domainbuilder: detail: xc_dom_alloc_segment:   kernel       : 0xffffffff81000000 -> 0xffffffff816fa000  (pfn 0x1000 + 0x6fa pages)
        domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x1000+0x6fa at 0xb4ce6000
        xc: detail: elf_load_binary: phdr 0 at 0x0xb4ce6000 -> 0x0xb5113000
        xc: detail: elf_load_binary: phdr 1 at 0x0xb5113000 -> 0x0xb51e9150
        xc: detail: elf_load_binary: phdr 2 at 0x0xb51ea000 -> 0x0xb51ea888
        xc: detail: elf_load_binary: phdr 3 at 0x0xb51eb000 -> 0x0xb52010d8
        xc: detail: elf_load_binary: phdr 4 at 0x0xb5202000 -> 0x0xb5288000
        domainbuilder: detail: xc_dom_alloc_segment:   ramdisk      : 0xffffffff816fa000 -> 0xffffffff8481c000  (pfn 0x16fa + 0x3122 pages)
        domainbuilder: detail: xc_dom_malloc            : 294 kB
        domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x16fa+0x3122 at 0xb1b7a000
        domainbuilder: detail: xc_dom_do_gunzip: unzip ok, 0x12a4954 -> 0x3121e10
        domainbuilder: detail: xc_dom_alloc_segment:   phys2mach    : 0xffffffff8481c000 -> 0xffffffff8485c000  (pfn 0x481c + 0x40 pages)
        domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x481c+0x40 at 0xb1b3a000
        domainbuilder: detail: xc_dom_alloc_page   :   start info   : 0xffffffff8485c000 (pfn 0x485c)
        domainbuilder: detail: xc_dom_alloc_page   :   xenstore     : 0xffffffff8485d000 (pfn 0x485d)
        domainbuilder: detail: xc_dom_alloc_page   :   console      : 0xffffffff8485e000 (pfn 0x485e)
        domainbuilder: detail: nr_page_tables: 0x0000ffffffffffff/48: 0xffff000000000000 -> 0xffffffffffffffff, 1 table(s)
        domainbuilder: detail: nr_page_tables: 0x0000007fffffffff/39: 0xffffff8000000000 -> 0xffffffffffffffff, 1 table(s)
        domainbuilder: detail: nr_page_tables: 0x000000003fffffff/30: 0xffffffff80000000 -> 0xffffffffbfffffff, 1 table(s)
        domainbuilder: detail: nr_page_tables: 0x00000000001fffff/21: 0xffffffff80000000 -> 0xffffffff84bfffff, 38 table(s)
        domainbuilder: detail: xc_dom_alloc_segment:   page tables  : 0xffffffff8485f000 -> 0xffffffff84888000  (pfn 0x485f + 0x29 pages)
        domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x485f+0x29 at 0xb1b11000
        domainbuilder: detail: xc_dom_alloc_page   :   boot stack   : 0xffffffff84888000 (pfn 0x4888)
        domainbuilder: detail: xc_dom_build_image  : virt_alloc_end : 0xffffffff84889000
        domainbuilder: detail: xc_dom_build_image  : virt_pgtab_end : 0xffffffff84c00000
        domainbuilder: detail: xc_dom_boot_image: called
        domainbuilder: detail: arch_setup_bootearly: doing nothing
        domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-x86_64 <= matches
        domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-x86_32p
        domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_32
        domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_32p
        domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_64
        domainbuilder: detail: xc_dom_update_guest_p2m: dst 64bit, pages 0x8000
        domainbuilder: detail: clear_page: pfn 0x485e, mfn 0xdc43d
        domainbuilder: detail: clear_page: pfn 0x485d, mfn 0xdc43e
        domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x485c+0x1 at 0xb1b0e000
        domainbuilder: detail: start_info_x86_64: called
        domainbuilder: detail: setup_hypercall_page: vaddr=0xffffffff81009000 pfn=0x1009
        domainbuilder: detail: domain builder memory footprint
        domainbuilder: detail:    allocated
        domainbuilder: detail:       malloc             : 12383 kB
        domainbuilder: detail:       anon mmap          : 0 bytes
        domainbuilder: detail:    mapped
        domainbuilder: detail:       file mmap          : 21457 kB
        domainbuilder: detail:       domU mmap          : 56 MB
        domainbuilder: detail: arch_setup_bootlate: shared_info: pfn 0x0, mfn 0xdccc8
        domainbuilder: detail: shared_info_x86_64: called
        domainbuilder: detail: vcpu_x86_64: called
        domainbuilder: detail: vcpu_x86_64: cr3: pfn 0x485f mfn 0xdc43c
        domainbuilder: detail: launch_vm: called, ctxt=0xbfd9c2ec
        domainbuilder: detail: xc_dom_release: called
        libxl: debug: libxl_event.c:1677:libxl__ao_progress_report: ao 0x806a870: progress report: callback queued aop=0x806c010
        libxl: debug: libxl_event.c:1497:libxl__ao_complete: ao 0x806a870: complete, rc=0
        libxl: debug: libxl_create.c:1197:do_domain_create: ao 0x806a870: inprogress: poller=0x806a8b0, flags=ic
        libxl: debug: libxl_event.c:1469:libxl__ao__destroy: ao 0x806a870: destroy
        libxl: debug: libxl_event.c:1090:egc_run_callbacks: ao 0x806a870: progress report: callback aop=0x806c010
        xl: libxl_event.c:1522: libxl__ao_complete_check_progress_reports: Assertion `ao->in_initiator' failed.
        Aborted
        


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 15:50:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 15:50:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMhVJ-0003fH-JX; Fri, 12 Oct 2012 15:50:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMhVI-0003fA-4N
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 15:50:24 +0000
Received: from [85.158.143.99:2522] by server-3.bemta-4.messagelabs.com id
	87/C4-10075-F3C38705; Fri, 12 Oct 2012 15:50:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1350057022!28615784!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQzMTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27523 invoked from network); 12 Oct 2012 15:50:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 15:50:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="15132759"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 15:50:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 12 Oct 2012 16:50:21 +0100
Message-ID: <1350057020.14806.120.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Ian Jackson 
Date: Fri, 12 Oct 2012 16:50:20 +0100
In-Reply-To: <1350056739.14806.119.camel@zakaz.uk.xensource.com>
References: <1350056739.14806.119.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel , Roger Pau Monne 
Subject: Re: [Xen-devel] Unable to start a domain with no disks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-12 at 16:45 +0100, Ian Campbell wrote:
> Trying to start a very simple domain with no disk from:
>         name="x"
>         memory=128
>         kernel="/scratch/debian/squeeze/amd64/vmlinuz"
>         ramdisk="/scratch/debian/squeeze/amd64/initrd.gz"
>         extra="console=hvc0"
>         vcpus=1
> Results in:
>         xl: libxl_event.c:1522: libxl__ao_complete_check_progress_reports: Assertion `ao->in_initiator' failed.
> if I try to autoconnnect the console (ie. xl cr -c).
> 
> If I don't try and auto connect to the console then everything is fine
> and I can subsequently use "xl cons" to connect.

This makes the issue go away but since this function also free's the ao
I think there must be a use after free somewhere.

diff -r 8aadb3204cfa tools/libxl/libxl_event.c
--- a/tools/libxl/libxl_event.c	Thu Sep 06 21:41:27 2012 +0200
+++ b/tools/libxl/libxl_event.c	Fri Oct 12 16:49:23 2012 +0100
@@ -1468,6 +1468,7 @@ void libxl__ao__destroy(libxl_ctx *ctx, 
     if (!ao) return;
     LOG(DEBUG,"ao %p: destroy",ao);
     if (ao->poller) libxl__poller_put(ctx, ao->poller);
+    ao->poller = NULL;
     ao->magic = LIBXL__AO_MAGIC_DESTROYED;
     libxl__free_all(&ao->gc);
     free(ao);

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 15:50:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 15:50:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMhVJ-0003fH-JX; Fri, 12 Oct 2012 15:50:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMhVI-0003fA-4N
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 15:50:24 +0000
Received: from [85.158.143.99:2522] by server-3.bemta-4.messagelabs.com id
	87/C4-10075-F3C38705; Fri, 12 Oct 2012 15:50:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1350057022!28615784!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQzMTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27523 invoked from network); 12 Oct 2012 15:50:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 15:50:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="15132759"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 15:50:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 12 Oct 2012 16:50:21 +0100
Message-ID: <1350057020.14806.120.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Ian Jackson 
Date: Fri, 12 Oct 2012 16:50:20 +0100
In-Reply-To: <1350056739.14806.119.camel@zakaz.uk.xensource.com>
References: <1350056739.14806.119.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel , Roger Pau Monne 
Subject: Re: [Xen-devel] Unable to start a domain with no disks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-12 at 16:45 +0100, Ian Campbell wrote:
> Trying to start a very simple domain with no disk from:
>         name="x"
>         memory=128
>         kernel="/scratch/debian/squeeze/amd64/vmlinuz"
>         ramdisk="/scratch/debian/squeeze/amd64/initrd.gz"
>         extra="console=hvc0"
>         vcpus=1
> Results in:
>         xl: libxl_event.c:1522: libxl__ao_complete_check_progress_reports: Assertion `ao->in_initiator' failed.
> if I try to autoconnnect the console (ie. xl cr -c).
> 
> If I don't try and auto connect to the console then everything is fine
> and I can subsequently use "xl cons" to connect.

This makes the issue go away but since this function also free's the ao
I think there must be a use after free somewhere.

diff -r 8aadb3204cfa tools/libxl/libxl_event.c
--- a/tools/libxl/libxl_event.c	Thu Sep 06 21:41:27 2012 +0200
+++ b/tools/libxl/libxl_event.c	Fri Oct 12 16:49:23 2012 +0100
@@ -1468,6 +1468,7 @@ void libxl__ao__destroy(libxl_ctx *ctx, 
     if (!ao) return;
     LOG(DEBUG,"ao %p: destroy",ao);
     if (ao->poller) libxl__poller_put(ctx, ao->poller);
+    ao->poller = NULL;
     ao->magic = LIBXL__AO_MAGIC_DESTROYED;
     libxl__free_all(&ao->gc);
     free(ao);

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 16:07:00 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 16:07:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMhl3-0004Go-5Y; Fri, 12 Oct 2012 16:06:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMhl1-0004Gj-Kn
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 16:06:39 +0000
Received: from [85.158.137.99:8922] by server-5.bemta-3.messagelabs.com id
	43/3F-12440-E0048705; Fri, 12 Oct 2012 16:06:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1350057998!16018429!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQzMTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19896 invoked from network); 12 Oct 2012 16:06:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 16:06:38 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="15133217"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 16:06:03 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 12 Oct 2012 17:06:03 +0100
Message-ID: <1350057962.14806.122.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Ian Jackson 
Date: Fri, 12 Oct 2012 17:06:02 +0100
In-Reply-To: <1350057020.14806.120.camel@zakaz.uk.xensource.com>
References: <1350056739.14806.119.camel@zakaz.uk.xensource.com>
	<1350057020.14806.120.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Roger Pau Monne , xen-devel 
Subject: Re: [Xen-devel] Unable to start a domain with no disks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-12 at 16:50 +0100, Ian Campbell wrote:
> On Fri, 2012-10-12 at 16:45 +0100, Ian Campbell wrote:
> > Trying to start a very simple domain with no disk from:
> >         name="x"
> >         memory=128
> >         kernel="/scratch/debian/squeeze/amd64/vmlinuz"
> >         ramdisk="/scratch/debian/squeeze/amd64/initrd.gz"
> >         extra="console=hvc0"
> >         vcpus=1
> > Results in:
> >         xl: libxl_event.c:1522: libxl__ao_complete_check_progress_reports: Assertion `ao->in_initiator' failed.
> > if I try to autoconnnect the console (ie. xl cr -c).
> > 
> > If I don't try and auto connect to the console then everything is fine
> > and I can subsequently use "xl cons" to connect.
> 
> This makes the issue go away but since this function also free's the ao
> I think there must be a use after free somewhere.

valgrind shows a couple of these sorts of use after free:
==5986== Invalid read of size 4
==5986==    at 0x4079323: libxl__egc_cleanup (libxl_event.c:1091)
==5986==    by 0x405E088: do_domain_create (libxl_create.c:1204)
==5986==    by 0x405E13E: libxl_domain_create_new (libxl_create.c:1225)
==5986==    by 0x805C5A6: create_domain (xl_cmdimpl.c:1932)
==5986==    by 0x805DED1: main_create (xl_cmdimpl.c:3973)
==5986==    by 0x804D41D: main (xl.c:285)
==5986==  Address 0x42af134 is 28 bytes inside a block of size 1,780 free'd
==5986==    at 0x4024F99: free (vg_replace_malloc.c:446)
==5986==    by 0x406E5A4: libxl__free_all (libxl_internal.c:74)
==5986==    by 0x4077B31: libxl__ao__destroy (libxl_event.c:1472)
==5986==    by 0x4079881: libxl__ao_inprogress (libxl_event.c:1638)
==5986==    by 0x405E042: do_domain_create (libxl_create.c:1204)
==5986==    by 0x405E13E: libxl_domain_create_new (libxl_create.c:1225)
==5986==    by 0x805C5A6: create_domain (xl_cmdimpl.c:1932)
==5986==    by 0x805DED1: main_create (xl_cmdimpl.c:3973)
==5986==    by 0x804D41D: main (xl.c:285)

And a bunch of:
==5986== Invalid read of size 4
==5986==    at 0x4079378: libxl__egc_cleanup (libxl_event.c:1094)
==5986==    by 0x405E088: do_domain_create (libxl_create.c:1204)
==5986==    by 0x405E13E: libxl_domain_create_new (libxl_create.c:1225)
==5986==    by 0x805C5A6: create_domain (xl_cmdimpl.c:1932)
==5986==    by 0x805DED1: main_create (xl_cmdimpl.c:3973)
==5986==    by 0x804D41D: main (xl.c:285)
==5986==  Address 0x42aef60 is 8 bytes inside a block of size 56 free'd
==5986==    at 0x4024F99: free (vg_replace_malloc.c:446)
==5986==    by 0x4077B39: libxl__ao__destroy (libxl_event.c:1473)
==5986==    by 0x4079881: libxl__ao_inprogress (libxl_event.c:1638)
==5986==    by 0x405E042: do_domain_create (libxl_create.c:1204)
==5986==    by 0x405E13E: libxl_domain_create_new (libxl_create.c:1225)
==5986==    by 0x805C5A6: create_domain (xl_cmdimpl.c:1932)
==5986==    by 0x805DED1: main_create (xl_cmdimpl.c:3973)
==5986==    by 0x804D41D: main (xl.c:285)

The last of which is:
==5986== Invalid read of size 4
==5986==    at 0x40787BC: libxl__ao_complete_check_progress_reports (libxl_event.c:1521)
==5986==    by 0x407938A: libxl__egc_cleanup (libxl_event.c:1095)
==5986==    by 0x405E088: do_domain_create (libxl_create.c:1204)
==5986==    by 0x405E13E: libxl_domain_create_new (libxl_create.c:1225)
==5986==    by 0x805C5A6: create_domain (xl_cmdimpl.c:1932)
==5986==    by 0x805DED1: main_create (xl_cmdimpl.c:3973)
==5986==    by 0x804D41D: main (xl.c:285)
==5986==  Address 0x42aef80 is 40 bytes inside a block of size 56 free'd
==5986==    at 0x4024F99: free (vg_replace_malloc.c:446)
==5986==    by 0x4077B39: libxl__ao__destroy (libxl_event.c:1473)
==5986==    by 0x4079881: libxl__ao_inprogress (libxl_event.c:1638)
==5986==    by 0x405E042: do_domain_create (libxl_create.c:1204)
==5986==    by 0x405E13E: libxl_domain_create_new (libxl_create.c:1225)
==5986==    by 0x805C5A6: create_domain (xl_cmdimpl.c:1932)
==5986==    by 0x805DED1: main_create (xl_cmdimpl.c:3973)
==5986==    by 0x804D41D: main (xl.c:285)
==5986== 
xl: libxl_event.c:1522: libxl__ao_complete_check_progress_reports: Assertion `ao->in_initiator' failed.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 16:07:00 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 16:07:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMhl3-0004Go-5Y; Fri, 12 Oct 2012 16:06:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMhl1-0004Gj-Kn
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 16:06:39 +0000
Received: from [85.158.137.99:8922] by server-5.bemta-3.messagelabs.com id
	43/3F-12440-E0048705; Fri, 12 Oct 2012 16:06:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1350057998!16018429!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQzMTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19896 invoked from network); 12 Oct 2012 16:06:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 16:06:38 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="15133217"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 16:06:03 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 12 Oct 2012 17:06:03 +0100
Message-ID: <1350057962.14806.122.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Ian Jackson 
Date: Fri, 12 Oct 2012 17:06:02 +0100
In-Reply-To: <1350057020.14806.120.camel@zakaz.uk.xensource.com>
References: <1350056739.14806.119.camel@zakaz.uk.xensource.com>
	<1350057020.14806.120.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Roger Pau Monne , xen-devel 
Subject: Re: [Xen-devel] Unable to start a domain with no disks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-12 at 16:50 +0100, Ian Campbell wrote:
> On Fri, 2012-10-12 at 16:45 +0100, Ian Campbell wrote:
> > Trying to start a very simple domain with no disk from:
> >         name="x"
> >         memory=128
> >         kernel="/scratch/debian/squeeze/amd64/vmlinuz"
> >         ramdisk="/scratch/debian/squeeze/amd64/initrd.gz"
> >         extra="console=hvc0"
> >         vcpus=1
> > Results in:
> >         xl: libxl_event.c:1522: libxl__ao_complete_check_progress_reports: Assertion `ao->in_initiator' failed.
> > if I try to autoconnnect the console (ie. xl cr -c).
> > 
> > If I don't try and auto connect to the console then everything is fine
> > and I can subsequently use "xl cons" to connect.
> 
> This makes the issue go away but since this function also free's the ao
> I think there must be a use after free somewhere.

valgrind shows a couple of these sorts of use after free:
==5986== Invalid read of size 4
==5986==    at 0x4079323: libxl__egc_cleanup (libxl_event.c:1091)
==5986==    by 0x405E088: do_domain_create (libxl_create.c:1204)
==5986==    by 0x405E13E: libxl_domain_create_new (libxl_create.c:1225)
==5986==    by 0x805C5A6: create_domain (xl_cmdimpl.c:1932)
==5986==    by 0x805DED1: main_create (xl_cmdimpl.c:3973)
==5986==    by 0x804D41D: main (xl.c:285)
==5986==  Address 0x42af134 is 28 bytes inside a block of size 1,780 free'd
==5986==    at 0x4024F99: free (vg_replace_malloc.c:446)
==5986==    by 0x406E5A4: libxl__free_all (libxl_internal.c:74)
==5986==    by 0x4077B31: libxl__ao__destroy (libxl_event.c:1472)
==5986==    by 0x4079881: libxl__ao_inprogress (libxl_event.c:1638)
==5986==    by 0x405E042: do_domain_create (libxl_create.c:1204)
==5986==    by 0x405E13E: libxl_domain_create_new (libxl_create.c:1225)
==5986==    by 0x805C5A6: create_domain (xl_cmdimpl.c:1932)
==5986==    by 0x805DED1: main_create (xl_cmdimpl.c:3973)
==5986==    by 0x804D41D: main (xl.c:285)

And a bunch of:
==5986== Invalid read of size 4
==5986==    at 0x4079378: libxl__egc_cleanup (libxl_event.c:1094)
==5986==    by 0x405E088: do_domain_create (libxl_create.c:1204)
==5986==    by 0x405E13E: libxl_domain_create_new (libxl_create.c:1225)
==5986==    by 0x805C5A6: create_domain (xl_cmdimpl.c:1932)
==5986==    by 0x805DED1: main_create (xl_cmdimpl.c:3973)
==5986==    by 0x804D41D: main (xl.c:285)
==5986==  Address 0x42aef60 is 8 bytes inside a block of size 56 free'd
==5986==    at 0x4024F99: free (vg_replace_malloc.c:446)
==5986==    by 0x4077B39: libxl__ao__destroy (libxl_event.c:1473)
==5986==    by 0x4079881: libxl__ao_inprogress (libxl_event.c:1638)
==5986==    by 0x405E042: do_domain_create (libxl_create.c:1204)
==5986==    by 0x405E13E: libxl_domain_create_new (libxl_create.c:1225)
==5986==    by 0x805C5A6: create_domain (xl_cmdimpl.c:1932)
==5986==    by 0x805DED1: main_create (xl_cmdimpl.c:3973)
==5986==    by 0x804D41D: main (xl.c:285)

The last of which is:
==5986== Invalid read of size 4
==5986==    at 0x40787BC: libxl__ao_complete_check_progress_reports (libxl_event.c:1521)
==5986==    by 0x407938A: libxl__egc_cleanup (libxl_event.c:1095)
==5986==    by 0x405E088: do_domain_create (libxl_create.c:1204)
==5986==    by 0x405E13E: libxl_domain_create_new (libxl_create.c:1225)
==5986==    by 0x805C5A6: create_domain (xl_cmdimpl.c:1932)
==5986==    by 0x805DED1: main_create (xl_cmdimpl.c:3973)
==5986==    by 0x804D41D: main (xl.c:285)
==5986==  Address 0x42aef80 is 40 bytes inside a block of size 56 free'd
==5986==    at 0x4024F99: free (vg_replace_malloc.c:446)
==5986==    by 0x4077B39: libxl__ao__destroy (libxl_event.c:1473)
==5986==    by 0x4079881: libxl__ao_inprogress (libxl_event.c:1638)
==5986==    by 0x405E042: do_domain_create (libxl_create.c:1204)
==5986==    by 0x405E13E: libxl_domain_create_new (libxl_create.c:1225)
==5986==    by 0x805C5A6: create_domain (xl_cmdimpl.c:1932)
==5986==    by 0x805DED1: main_create (xl_cmdimpl.c:3973)
==5986==    by 0x804D41D: main (xl.c:285)
==5986== 
xl: libxl_event.c:1522: libxl__ao_complete_check_progress_reports: Assertion `ao->in_initiator' failed.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 16:11:54 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 16:11:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMhpq-0004Om-SY; Fri, 12 Oct 2012 16:11:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMhpp-0004Og-Ab
	for xen-devel@lists.xensource.com; Fri, 12 Oct 2012 16:11:37 +0000
Received: from [85.158.138.51:10139] by server-3.bemta-3.messagelabs.com id
	89/C7-09368-83148705; Fri, 12 Oct 2012 16:11:36 +0000
X-Env-Sender: Jacob.Shin@amd.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1350058291!34082604!1
X-Originating-IP: [216.32.180.31]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31860 invoked from network); 12 Oct 2012 16:11:35 -0000
Received: from va3ehsobe005.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.31)
	by server-2.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	12 Oct 2012 16:11:35 -0000
Received: from mail214-va3-R.bigfish.com (10.7.14.236) by
	VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id
	14.1.225.23; Fri, 12 Oct 2012 16:11:31 +0000
Received: from mail214-va3 (localhost [127.0.0.1])	by
	mail214-va3-R.bigfish.com (Postfix) with ESMTP id DCB5488020A	for
	; Fri, 12 Oct 2012 16:11:30 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202h1d1ah1d2ahzz8275bhz2dh668h839h944hd25hd2bhf0ah107ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1155h)
Received: from mail214-va3 (localhost.localdomain [127.0.0.1]) by mail214-va3
	(MessageSwitch) id 1350058288374753_22801;
	Fri, 12 Oct 2012 16:11:28 +0000 (UTC)
Received: from VA3EHSMHS029.bigfish.com (unknown [10.7.14.237])	by
	mail214-va3.bigfish.com (Postfix) with ESMTP id 59AE3D4003F	for
	; Fri, 12 Oct 2012 16:11:28 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS029.bigfish.com (10.7.99.39) with Microsoft SMTP Server id
	14.1.225.23; Fri, 12 Oct 2012 16:11:27 +0000
X-WSS-ID: 0MBSFN2-02-2HX-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1) with ESMTP id 202F5C8098	for ;
	Fri, 12 Oct 2012 11:11:25 -0500 (CDT)
Received: from SAUSEXDAG06.amd.com (163.181.55.7) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 12 Oct 2012 11:12:12 -0500
Received: from jshin-Toonie (163.181.55.254) by sausexdag06.amd.com
	(163.181.55.7) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Fri, 12 Oct 2012 11:11:25 -0500
Date: Fri, 12 Oct 2012 11:11:14 -0500
From: Jacob Shin 
To: 
Message-ID: <20121012161114.GA21661@jshin-Toonie>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] x86/xenoprof: Fix kernel/user mode detection
	for HVM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

x86/xenoprof: Fix kernel/user mode detection for HVM

While trying oprofile under Xen, I noticed that HVM passive domain's kernel 
addresses were showing up as user application. It turns out under HVM 
get_cpu_user_regs()->cs contains 0x0000beef.

Signed-off-by: Jacob Shin 

diff -r e0e1350dfe9b xen/arch/x86/oprofile/xenoprof.c
--- a/xen/arch/x86/oprofile/xenoprof.c	Thu Oct 11 15:57:00 2012 +0100
+++ b/xen/arch/x86/oprofile/xenoprof.c	Fri Oct 12 10:48:37 2012 -0500
@@ -81,7 +81,11 @@ int xenoprofile_get_mode(const struct vc
         return 2;
 
     if ( is_hvm_vcpu(v) )
-        return ((regs->cs & 3) != 3);
+    {
+        struct segment_register cs;
+        hvm_get_segment_register((struct vcpu *)v, x86_seg_cs, &cs);
+        return ((cs.sel & 3) != 3);
+    }
 
     return guest_kernel_mode(v, regs);  
 }


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 16:11:54 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 16:11:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMhpq-0004Om-SY; Fri, 12 Oct 2012 16:11:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMhpp-0004Og-Ab
	for xen-devel@lists.xensource.com; Fri, 12 Oct 2012 16:11:37 +0000
Received: from [85.158.138.51:10139] by server-3.bemta-3.messagelabs.com id
	89/C7-09368-83148705; Fri, 12 Oct 2012 16:11:36 +0000
X-Env-Sender: Jacob.Shin@amd.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1350058291!34082604!1
X-Originating-IP: [216.32.180.31]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31860 invoked from network); 12 Oct 2012 16:11:35 -0000
Received: from va3ehsobe005.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.31)
	by server-2.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	12 Oct 2012 16:11:35 -0000
Received: from mail214-va3-R.bigfish.com (10.7.14.236) by
	VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id
	14.1.225.23; Fri, 12 Oct 2012 16:11:31 +0000
Received: from mail214-va3 (localhost [127.0.0.1])	by
	mail214-va3-R.bigfish.com (Postfix) with ESMTP id DCB5488020A	for
	; Fri, 12 Oct 2012 16:11:30 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202h1d1ah1d2ahzz8275bhz2dh668h839h944hd25hd2bhf0ah107ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1155h)
Received: from mail214-va3 (localhost.localdomain [127.0.0.1]) by mail214-va3
	(MessageSwitch) id 1350058288374753_22801;
	Fri, 12 Oct 2012 16:11:28 +0000 (UTC)
Received: from VA3EHSMHS029.bigfish.com (unknown [10.7.14.237])	by
	mail214-va3.bigfish.com (Postfix) with ESMTP id 59AE3D4003F	for
	; Fri, 12 Oct 2012 16:11:28 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS029.bigfish.com (10.7.99.39) with Microsoft SMTP Server id
	14.1.225.23; Fri, 12 Oct 2012 16:11:27 +0000
X-WSS-ID: 0MBSFN2-02-2HX-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1) with ESMTP id 202F5C8098	for ;
	Fri, 12 Oct 2012 11:11:25 -0500 (CDT)
Received: from SAUSEXDAG06.amd.com (163.181.55.7) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 12 Oct 2012 11:12:12 -0500
Received: from jshin-Toonie (163.181.55.254) by sausexdag06.amd.com
	(163.181.55.7) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Fri, 12 Oct 2012 11:11:25 -0500
Date: Fri, 12 Oct 2012 11:11:14 -0500
From: Jacob Shin 
To: 
Message-ID: <20121012161114.GA21661@jshin-Toonie>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] x86/xenoprof: Fix kernel/user mode detection
	for HVM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

x86/xenoprof: Fix kernel/user mode detection for HVM

While trying oprofile under Xen, I noticed that HVM passive domain's kernel 
addresses were showing up as user application. It turns out under HVM 
get_cpu_user_regs()->cs contains 0x0000beef.

Signed-off-by: Jacob Shin 

diff -r e0e1350dfe9b xen/arch/x86/oprofile/xenoprof.c
--- a/xen/arch/x86/oprofile/xenoprof.c	Thu Oct 11 15:57:00 2012 +0100
+++ b/xen/arch/x86/oprofile/xenoprof.c	Fri Oct 12 10:48:37 2012 -0500
@@ -81,7 +81,11 @@ int xenoprofile_get_mode(const struct vc
         return 2;
 
     if ( is_hvm_vcpu(v) )
-        return ((regs->cs & 3) != 3);
+    {
+        struct segment_register cs;
+        hvm_get_segment_register((struct vcpu *)v, x86_seg_cs, &cs);
+        return ((cs.sel & 3) != 3);
+    }
 
     return guest_kernel_mode(v, regs);  
 }


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 16:13:47 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 16:13:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMhre-0004WA-IV; Fri, 12 Oct 2012 16:13:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMhrc-0004Vv-P3
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 16:13:28 +0000
Received: from [85.158.138.51:17379] by server-16.bemta-3.messagelabs.com id
	F3/10-16565-8A148705; Fri, 12 Oct 2012 16:13:28 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1350058405!27829840!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYwMjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31009 invoked from network); 12 Oct 2012 16:13:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 16:13:27 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="41049477"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 16:13:25 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Fri, 12 Oct 2012
	12:13:25 -0400
Message-ID: <507841A4.8090108@citrix.com>
Date: Fri, 12 Oct 2012 17:13:24 +0100
From: David Vrabel 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk 
References: <1350046634-2462-1-git-send-email-david.vrabel@citrix.com>
	<1350046634-2462-2-git-send-email-david.vrabel@citrix.com>
	<20121012145716.GA20842@phenom.dumpdata.com>
In-Reply-To: <20121012145716.GA20842@phenom.dumpdata.com>
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 1/3] xen: sync the CMOS RTC as well as the
	Xen wallclock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/10/12 15:57, Konrad Rzeszutek Wilk wrote:
> On Fri, Oct 12, 2012 at 01:57:12PM +0100, David Vrabel wrote:
>> From: David Vrabel 
>>
>> If NTP is used in dom0 and it is synchronized to its clock source,
>> then the kernel will periodically synchronize the Xen wallclock with
>> the system time.  Updates to the Xen wallclock do not persist across
>> reboots, so also synchronize the CMOS RTC (as on bare metal).
>>
>> Signed-off-by: David Vrabel 
>> ---
>>  arch/x86/xen/time.c |    5 +++++
>>  1 files changed, 5 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
>> index 0296a95..5e7f536 100644
>> --- a/arch/x86/xen/time.c
>> +++ b/arch/x86/xen/time.c
>> @@ -14,6 +14,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  
>>  #include 
>>  #include 
>> @@ -208,6 +209,10 @@ static int xen_set_wallclock(unsigned long now)
>>  	if (!xen_initial_domain())
>>  		return -1;
>>  
>> +	/* Set the hardware RTC. */
>> +	mach_set_rtc_mmss(now);
> 
> So how does this work? Is the hypervisor traping on the RTC CMOS clock?

It's works the same as with the RTC driver.  I think the hypervisor
allows dom0 access to the relevant I/O ports.

It's worth pointing out that mach_set_rtc_mmss() only sets the minutes
and seconds so it doesn't handle big step changes which is why
update_persistent_clock() is only called once NTP is synchronized.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 16:13:47 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 16:13:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMhre-0004WA-IV; Fri, 12 Oct 2012 16:13:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMhrc-0004Vv-P3
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 16:13:28 +0000
Received: from [85.158.138.51:17379] by server-16.bemta-3.messagelabs.com id
	F3/10-16565-8A148705; Fri, 12 Oct 2012 16:13:28 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1350058405!27829840!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYwMjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31009 invoked from network); 12 Oct 2012 16:13:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 16:13:27 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="41049477"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 16:13:25 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Fri, 12 Oct 2012
	12:13:25 -0400
Message-ID: <507841A4.8090108@citrix.com>
Date: Fri, 12 Oct 2012 17:13:24 +0100
From: David Vrabel 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk 
References: <1350046634-2462-1-git-send-email-david.vrabel@citrix.com>
	<1350046634-2462-2-git-send-email-david.vrabel@citrix.com>
	<20121012145716.GA20842@phenom.dumpdata.com>
In-Reply-To: <20121012145716.GA20842@phenom.dumpdata.com>
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 1/3] xen: sync the CMOS RTC as well as the
	Xen wallclock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/10/12 15:57, Konrad Rzeszutek Wilk wrote:
> On Fri, Oct 12, 2012 at 01:57:12PM +0100, David Vrabel wrote:
>> From: David Vrabel 
>>
>> If NTP is used in dom0 and it is synchronized to its clock source,
>> then the kernel will periodically synchronize the Xen wallclock with
>> the system time.  Updates to the Xen wallclock do not persist across
>> reboots, so also synchronize the CMOS RTC (as on bare metal).
>>
>> Signed-off-by: David Vrabel 
>> ---
>>  arch/x86/xen/time.c |    5 +++++
>>  1 files changed, 5 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
>> index 0296a95..5e7f536 100644
>> --- a/arch/x86/xen/time.c
>> +++ b/arch/x86/xen/time.c
>> @@ -14,6 +14,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  
>>  #include 
>>  #include 
>> @@ -208,6 +209,10 @@ static int xen_set_wallclock(unsigned long now)
>>  	if (!xen_initial_domain())
>>  		return -1;
>>  
>> +	/* Set the hardware RTC. */
>> +	mach_set_rtc_mmss(now);
> 
> So how does this work? Is the hypervisor traping on the RTC CMOS clock?

It's works the same as with the RTC driver.  I think the hypervisor
allows dom0 access to the relevant I/O ports.

It's worth pointing out that mach_set_rtc_mmss() only sets the minutes
and seconds so it doesn't handle big step changes which is why
update_persistent_clock() is only called once NTP is synchronized.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 16:14:38 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 16:14:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMhsW-0004aW-05; Fri, 12 Oct 2012 16:14:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMhsU-0004aH-Jd
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 16:14:22 +0000
Received: from [85.158.143.35:8886] by server-2.bemta-4.messagelabs.com id
	6E/84-25171-DD148705; Fri, 12 Oct 2012 16:14:21 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1350058458!13761503!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODIwNTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26994 invoked from network); 12 Oct 2012 16:14:20 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 16:14:20 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="211125389"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 16:14:18 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Fri, 12 Oct 2012
	12:14:18 -0400
Message-ID: <507841D8.6090205@citrix.com>
Date: Fri, 12 Oct 2012 17:14:16 +0100
From: David Vrabel 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk 
References: <1350046634-2462-1-git-send-email-david.vrabel@citrix.com>
	<1350046634-2462-4-git-send-email-david.vrabel@citrix.com>
	<20121012134147.GA11778@phenom.dumpdata.com>
	<507822ED.2090900@citrix.com>
	
	<5078304D.1050807@citrix.com>
	<20121012150251.GB20842@phenom.dumpdata.com>
In-Reply-To: <20121012150251.GB20842@phenom.dumpdata.com>
Cc: Konrad Rzeszutek Wilk ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 3/3] xen/privcmd: add
 IOCTL_PRIVCMD_SYNC_WALLCLOCK to sync Xen's wallclock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/10/12 16:02, Konrad Rzeszutek Wilk wrote:
> On Fri, Oct 12, 2012 at 03:59:25PM +0100, David Vrabel wrote:
>> On 12/10/12 15:29, Konrad Rzeszutek Wilk wrote:
>>> On Fri, Oct 12, 2012 at 10:02 AM, David Vrabel  wrote:
>>>> On 12/10/12 14:41, Konrad Rzeszutek Wilk wrote:
>>>>> On Fri, Oct 12, 2012 at 01:57:14PM +0100, David Vrabel wrote:
>>>>>> From: David Vrabel 
>>>>>>
>>>>>> Add a new ioctl to synchronize Xen's wallclock with the current system
>>>>>> time.
>>>>>>
>>>>>> This may be used by the tools to ensure that newly created domains see
>>>>>> the correct wallclock time if NTP is not used in dom0 or if domains
>>>>>> are started before NTP has synchronized.
>>>>>
>>>>> So... how does this work with NTPD? As in does ntpd _not_ update the
>>>>> hwclock enough?
>>>>
>>>> Once NTPD is synchronized then the kernel updates the wallclock (and the
>>>> RTC with patch #1) every 11 mins.  I assume this is often enough given
>>>> how NTP adjusts the system time.
>>>>
>>>> You only really need the tools to sync wallclock if system time was
>>>> stepped at start of day.  e.g., init scripts could do something like:
>>>>
>>>> ntpdate pool.ntp.org
>>>> hwclock --systohc
>>>> xen-wallclock --systowc
>>>
>>> I think I am missing something. The hwclock should end up in the
>>> xen_set_wallclock call. And from there on, the ntpd would update the
>>> wallclock if it got skewed enough? Or is the system time not calling
>>> the wall-clock enough? If that is the case, would just adding this in
>>> the crontab be enough:
>>
>> hwclock talks to /dev/rtc which writes to the CMOS directly and does not
>> call update_persistent_clock() (or xen_set_wallclock()).
> 
> /me scratches his head.
> 
> I recall that the update_persistent_clock() was being called.. with
> hwclock -w (which is the same as --systohc).

No,

> That seems like a bug in the generic code - I would think that
> hwclock would update the wallclock, not just the RTC.

If we wanted hwclock to also update the xen wallclock we would need a
xen-specific rtc driver that updated both rtc and wallclock.

> Oh, it is whoever calls 'adjtimex' syscall ends up calling in
> update_persistent_clock(). So .. ntpdate or ntpd don't call that?

ntpd does call adjtimex so if you are running ntpd and it is
synchronized to its clock source you do get the periodic sync of the
wallclock.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 16:14:38 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 16:14:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMhsW-0004aW-05; Fri, 12 Oct 2012 16:14:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMhsU-0004aH-Jd
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 16:14:22 +0000
Received: from [85.158.143.35:8886] by server-2.bemta-4.messagelabs.com id
	6E/84-25171-DD148705; Fri, 12 Oct 2012 16:14:21 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1350058458!13761503!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODIwNTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26994 invoked from network); 12 Oct 2012 16:14:20 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 16:14:20 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="211125389"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 16:14:18 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Fri, 12 Oct 2012
	12:14:18 -0400
Message-ID: <507841D8.6090205@citrix.com>
Date: Fri, 12 Oct 2012 17:14:16 +0100
From: David Vrabel 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk 
References: <1350046634-2462-1-git-send-email-david.vrabel@citrix.com>
	<1350046634-2462-4-git-send-email-david.vrabel@citrix.com>
	<20121012134147.GA11778@phenom.dumpdata.com>
	<507822ED.2090900@citrix.com>
	
	<5078304D.1050807@citrix.com>
	<20121012150251.GB20842@phenom.dumpdata.com>
In-Reply-To: <20121012150251.GB20842@phenom.dumpdata.com>
Cc: Konrad Rzeszutek Wilk ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 3/3] xen/privcmd: add
 IOCTL_PRIVCMD_SYNC_WALLCLOCK to sync Xen's wallclock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/10/12 16:02, Konrad Rzeszutek Wilk wrote:
> On Fri, Oct 12, 2012 at 03:59:25PM +0100, David Vrabel wrote:
>> On 12/10/12 15:29, Konrad Rzeszutek Wilk wrote:
>>> On Fri, Oct 12, 2012 at 10:02 AM, David Vrabel  wrote:
>>>> On 12/10/12 14:41, Konrad Rzeszutek Wilk wrote:
>>>>> On Fri, Oct 12, 2012 at 01:57:14PM +0100, David Vrabel wrote:
>>>>>> From: David Vrabel 
>>>>>>
>>>>>> Add a new ioctl to synchronize Xen's wallclock with the current system
>>>>>> time.
>>>>>>
>>>>>> This may be used by the tools to ensure that newly created domains see
>>>>>> the correct wallclock time if NTP is not used in dom0 or if domains
>>>>>> are started before NTP has synchronized.
>>>>>
>>>>> So... how does this work with NTPD? As in does ntpd _not_ update the
>>>>> hwclock enough?
>>>>
>>>> Once NTPD is synchronized then the kernel updates the wallclock (and the
>>>> RTC with patch #1) every 11 mins.  I assume this is often enough given
>>>> how NTP adjusts the system time.
>>>>
>>>> You only really need the tools to sync wallclock if system time was
>>>> stepped at start of day.  e.g., init scripts could do something like:
>>>>
>>>> ntpdate pool.ntp.org
>>>> hwclock --systohc
>>>> xen-wallclock --systowc
>>>
>>> I think I am missing something. The hwclock should end up in the
>>> xen_set_wallclock call. And from there on, the ntpd would update the
>>> wallclock if it got skewed enough? Or is the system time not calling
>>> the wall-clock enough? If that is the case, would just adding this in
>>> the crontab be enough:
>>
>> hwclock talks to /dev/rtc which writes to the CMOS directly and does not
>> call update_persistent_clock() (or xen_set_wallclock()).
> 
> /me scratches his head.
> 
> I recall that the update_persistent_clock() was being called.. with
> hwclock -w (which is the same as --systohc).

No,

> That seems like a bug in the generic code - I would think that
> hwclock would update the wallclock, not just the RTC.

If we wanted hwclock to also update the xen wallclock we would need a
xen-specific rtc driver that updated both rtc and wallclock.

> Oh, it is whoever calls 'adjtimex' syscall ends up calling in
> update_persistent_clock(). So .. ntpdate or ntpd don't call that?

ntpd does call adjtimex so if you are running ntpd and it is
synchronized to its clock source you do get the periodic sync of the
wallclock.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 16:25:38 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 16:25:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMi39-0004sg-5X; Fri, 12 Oct 2012 16:25:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMi37-0004sb-I5
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 16:25:21 +0000
Received: from [85.158.137.99:20168] by server-10.bemta-3.messagelabs.com id
	1A/76-27386-07448705; Fri, 12 Oct 2012 16:25:20 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1350059118!16020551!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYwMjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5183 invoked from network); 12 Oct 2012 16:25:20 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 16:25:20 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="41050875"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 16:25:08 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 12 Oct 2012
	12:25:08 -0400
Message-ID: <50784462.3060203@citrix.com>
Date: Fri, 12 Oct 2012 17:25:06 +0100
From: David Vrabel 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: David Vrabel 
References: <1350046634-2462-1-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1350046634-2462-1-git-send-email-david.vrabel@citrix.com>
Cc: Konrad Rzeszutek Wilk ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 0/3] xen: fix various wallclock problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/10/12 13:57, David Vrabel wrote:
> This series (with some toolstack updates) corrects a number of cases
> where a guest can see an incorrect wallclock time.
> 
> 1. Systems with NTP won't periodically synchronize the hardware RTC so
> the wallclock may be incorrect after a reboot.
> 
> 2. The wallclock is always ~500 ms behind the correct time.
> 
> 3. If the system time was stepped and NTP isn't synchronized yet, the
> wallclock will still have the incorrect time.  The fix for this
> requires the toolstack to synchronize the wallclock -- patch #3
> provides the mechanism for this.

These tables should help.

Before:

              |                Updates
Process	      | System Time?  Xen Wallclock?  Hardware Clock?
-------------------------------------------------------------
date -s       | X
hwclock -w    |                               X
ntpd          | X             X[*]
ntpdate       | X

After this (and the toolstack) patches:

              |                Updates
Process	      | System Time?  Xen Wallclock?  Hardware Clock?
-------------------------------------------------------------
date -s       | X
hwclock -w    |                               X
ntpd          | X             X[*]            X[*]
ntpdate       | X
xen-wallclock |               X

[*] every 11 minutes.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 16:25:38 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 16:25:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMi39-0004sg-5X; Fri, 12 Oct 2012 16:25:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMi37-0004sb-I5
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 16:25:21 +0000
Received: from [85.158.137.99:20168] by server-10.bemta-3.messagelabs.com id
	1A/76-27386-07448705; Fri, 12 Oct 2012 16:25:20 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1350059118!16020551!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYwMjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5183 invoked from network); 12 Oct 2012 16:25:20 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 16:25:20 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="41050875"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 16:25:08 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Fri, 12 Oct 2012
	12:25:08 -0400
Message-ID: <50784462.3060203@citrix.com>
Date: Fri, 12 Oct 2012 17:25:06 +0100
From: David Vrabel 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: David Vrabel 
References: <1350046634-2462-1-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1350046634-2462-1-git-send-email-david.vrabel@citrix.com>
Cc: Konrad Rzeszutek Wilk ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 0/3] xen: fix various wallclock problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/10/12 13:57, David Vrabel wrote:
> This series (with some toolstack updates) corrects a number of cases
> where a guest can see an incorrect wallclock time.
> 
> 1. Systems with NTP won't periodically synchronize the hardware RTC so
> the wallclock may be incorrect after a reboot.
> 
> 2. The wallclock is always ~500 ms behind the correct time.
> 
> 3. If the system time was stepped and NTP isn't synchronized yet, the
> wallclock will still have the incorrect time.  The fix for this
> requires the toolstack to synchronize the wallclock -- patch #3
> provides the mechanism for this.

These tables should help.

Before:

              |                Updates
Process	      | System Time?  Xen Wallclock?  Hardware Clock?
-------------------------------------------------------------
date -s       | X
hwclock -w    |                               X
ntpd          | X             X[*]
ntpdate       | X

After this (and the toolstack) patches:

              |                Updates
Process	      | System Time?  Xen Wallclock?  Hardware Clock?
-------------------------------------------------------------
date -s       | X
hwclock -w    |                               X
ntpd          | X             X[*]            X[*]
ntpdate       | X
xen-wallclock |               X

[*] every 11 minutes.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 16:28:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 16:28:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMi5p-0004zL-No; Fri, 12 Oct 2012 16:28:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMi5o-0004zF-J7
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 16:28:08 +0000
Received: from [85.158.143.99:9529] by server-2.bemta-4.messagelabs.com id
	28/00-25171-71548705; Fri, 12 Oct 2012 16:28:07 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1350059286!22669382!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODAwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7648 invoked from network); 12 Oct 2012 16:28:07 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Oct 2012 16:28:07 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9CGS21E031082
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 12 Oct 2012 16:28:03 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9CGS1ac000529
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 12 Oct 2012 16:28:02 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9CGS1nW012181; Fri, 12 Oct 2012 11:28:01 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Oct 2012 09:28:01 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 6FBF74037A; Fri, 12 Oct 2012 12:16:10 -0400 (EDT)
Date: Fri, 12 Oct 2012 12:16:10 -0400
From: Konrad Rzeszutek Wilk 
To: David Vrabel 
Message-ID: <20121012161610.GA7880@phenom.dumpdata.com>
References: <1350046634-2462-1-git-send-email-david.vrabel@citrix.com>
	<1350046634-2462-4-git-send-email-david.vrabel@citrix.com>
	<20121012134147.GA11778@phenom.dumpdata.com>
	<507822ED.2090900@citrix.com>
	
	<5078304D.1050807@citrix.com>
	<20121012150251.GB20842@phenom.dumpdata.com>
	<507841D8.6090205@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <507841D8.6090205@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Konrad Rzeszutek Wilk ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 3/3] xen/privcmd: add
 IOCTL_PRIVCMD_SYNC_WALLCLOCK to sync Xen's wallclock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 12, 2012 at 05:14:16PM +0100, David Vrabel wrote:
> On 12/10/12 16:02, Konrad Rzeszutek Wilk wrote:
> > On Fri, Oct 12, 2012 at 03:59:25PM +0100, David Vrabel wrote:
> >> On 12/10/12 15:29, Konrad Rzeszutek Wilk wrote:
> >>> On Fri, Oct 12, 2012 at 10:02 AM, David Vrabel  wrote:
> >>>> On 12/10/12 14:41, Konrad Rzeszutek Wilk wrote:
> >>>>> On Fri, Oct 12, 2012 at 01:57:14PM +0100, David Vrabel wrote:
> >>>>>> From: David Vrabel 
> >>>>>>
> >>>>>> Add a new ioctl to synchronize Xen's wallclock with the current system
> >>>>>> time.
> >>>>>>
> >>>>>> This may be used by the tools to ensure that newly created domains see
> >>>>>> the correct wallclock time if NTP is not used in dom0 or if domains
> >>>>>> are started before NTP has synchronized.
> >>>>>
> >>>>> So... how does this work with NTPD? As in does ntpd _not_ update the
> >>>>> hwclock enough?
> >>>>
> >>>> Once NTPD is synchronized then the kernel updates the wallclock (and the
> >>>> RTC with patch #1) every 11 mins.  I assume this is often enough given
> >>>> how NTP adjusts the system time.
> >>>>
> >>>> You only really need the tools to sync wallclock if system time was
> >>>> stepped at start of day.  e.g., init scripts could do something like:
> >>>>
> >>>> ntpdate pool.ntp.org
> >>>> hwclock --systohc
> >>>> xen-wallclock --systowc
> >>>
> >>> I think I am missing something. The hwclock should end up in the
> >>> xen_set_wallclock call. And from there on, the ntpd would update the
> >>> wallclock if it got skewed enough? Or is the system time not calling
> >>> the wall-clock enough? If that is the case, would just adding this in
> >>> the crontab be enough:
> >>
> >> hwclock talks to /dev/rtc which writes to the CMOS directly and does not
> >> call update_persistent_clock() (or xen_set_wallclock()).
> > 
> > /me scratches his head.
> > 
> > I recall that the update_persistent_clock() was being called.. with
> > hwclock -w (which is the same as --systohc).
> 
> No,
> 
> > That seems like a bug in the generic code - I would think that
> > hwclock would update the wallclock, not just the RTC.
> 
> If we wanted hwclock to also update the xen wallclock we would need a
> xen-specific rtc driver that updated both rtc and wallclock.
> 
> > Oh, it is whoever calls 'adjtimex' syscall ends up calling in
> > update_persistent_clock(). So .. ntpdate or ntpd don't call that?
> 
> ntpd does call adjtimex so if you are running ntpd and it is
> synchronized to its clock source you do get the periodic sync of the
> wallclock.

So, having both ntpd (which calls call adjtimex) - which would run in the
background; and hwclock run at startup - (which updates the RTC, which ends
 - I hope - being trapped by the hypervisor), we end up with the correct
time, right?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 16:28:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 16:28:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMi5p-0004zL-No; Fri, 12 Oct 2012 16:28:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMi5o-0004zF-J7
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 16:28:08 +0000
Received: from [85.158.143.99:9529] by server-2.bemta-4.messagelabs.com id
	28/00-25171-71548705; Fri, 12 Oct 2012 16:28:07 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1350059286!22669382!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODAwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7648 invoked from network); 12 Oct 2012 16:28:07 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Oct 2012 16:28:07 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9CGS21E031082
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 12 Oct 2012 16:28:03 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9CGS1ac000529
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 12 Oct 2012 16:28:02 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9CGS1nW012181; Fri, 12 Oct 2012 11:28:01 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Oct 2012 09:28:01 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 6FBF74037A; Fri, 12 Oct 2012 12:16:10 -0400 (EDT)
Date: Fri, 12 Oct 2012 12:16:10 -0400
From: Konrad Rzeszutek Wilk 
To: David Vrabel 
Message-ID: <20121012161610.GA7880@phenom.dumpdata.com>
References: <1350046634-2462-1-git-send-email-david.vrabel@citrix.com>
	<1350046634-2462-4-git-send-email-david.vrabel@citrix.com>
	<20121012134147.GA11778@phenom.dumpdata.com>
	<507822ED.2090900@citrix.com>
	
	<5078304D.1050807@citrix.com>
	<20121012150251.GB20842@phenom.dumpdata.com>
	<507841D8.6090205@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <507841D8.6090205@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Konrad Rzeszutek Wilk ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 3/3] xen/privcmd: add
 IOCTL_PRIVCMD_SYNC_WALLCLOCK to sync Xen's wallclock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 12, 2012 at 05:14:16PM +0100, David Vrabel wrote:
> On 12/10/12 16:02, Konrad Rzeszutek Wilk wrote:
> > On Fri, Oct 12, 2012 at 03:59:25PM +0100, David Vrabel wrote:
> >> On 12/10/12 15:29, Konrad Rzeszutek Wilk wrote:
> >>> On Fri, Oct 12, 2012 at 10:02 AM, David Vrabel  wrote:
> >>>> On 12/10/12 14:41, Konrad Rzeszutek Wilk wrote:
> >>>>> On Fri, Oct 12, 2012 at 01:57:14PM +0100, David Vrabel wrote:
> >>>>>> From: David Vrabel 
> >>>>>>
> >>>>>> Add a new ioctl to synchronize Xen's wallclock with the current system
> >>>>>> time.
> >>>>>>
> >>>>>> This may be used by the tools to ensure that newly created domains see
> >>>>>> the correct wallclock time if NTP is not used in dom0 or if domains
> >>>>>> are started before NTP has synchronized.
> >>>>>
> >>>>> So... how does this work with NTPD? As in does ntpd _not_ update the
> >>>>> hwclock enough?
> >>>>
> >>>> Once NTPD is synchronized then the kernel updates the wallclock (and the
> >>>> RTC with patch #1) every 11 mins.  I assume this is often enough given
> >>>> how NTP adjusts the system time.
> >>>>
> >>>> You only really need the tools to sync wallclock if system time was
> >>>> stepped at start of day.  e.g., init scripts could do something like:
> >>>>
> >>>> ntpdate pool.ntp.org
> >>>> hwclock --systohc
> >>>> xen-wallclock --systowc
> >>>
> >>> I think I am missing something. The hwclock should end up in the
> >>> xen_set_wallclock call. And from there on, the ntpd would update the
> >>> wallclock if it got skewed enough? Or is the system time not calling
> >>> the wall-clock enough? If that is the case, would just adding this in
> >>> the crontab be enough:
> >>
> >> hwclock talks to /dev/rtc which writes to the CMOS directly and does not
> >> call update_persistent_clock() (or xen_set_wallclock()).
> > 
> > /me scratches his head.
> > 
> > I recall that the update_persistent_clock() was being called.. with
> > hwclock -w (which is the same as --systohc).
> 
> No,
> 
> > That seems like a bug in the generic code - I would think that
> > hwclock would update the wallclock, not just the RTC.
> 
> If we wanted hwclock to also update the xen wallclock we would need a
> xen-specific rtc driver that updated both rtc and wallclock.
> 
> > Oh, it is whoever calls 'adjtimex' syscall ends up calling in
> > update_persistent_clock(). So .. ntpdate or ntpd don't call that?
> 
> ntpd does call adjtimex so if you are running ntpd and it is
> synchronized to its clock source you do get the periodic sync of the
> wallclock.

So, having both ntpd (which calls call adjtimex) - which would run in the
background; and hwclock run at startup - (which updates the RTC, which ends
 - I hope - being trapped by the hypervisor), we end up with the correct
time, right?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 16:30:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 16:30:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMi7Y-000565-7a; Fri, 12 Oct 2012 16:29:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMi7V-00055w-UF
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 16:29:54 +0000
Received: from [85.158.139.83:23572] by server-3.bemta-5.messagelabs.com id
	68/50-09712-18548705; Fri, 12 Oct 2012 16:29:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1350059392!32425874!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQzMTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8882 invoked from network); 12 Oct 2012 16:29:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 16:29:52 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="15133757"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 16:29:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 12 Oct 2012 17:29:51 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TMi7T-00067t-Mi; Fri, 12 Oct 2012 16:29:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TMi7T-0007iM-Io;
	Fri, 12 Oct 2012 17:29:51 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20600.17791.486117.993788@mariner.uk.xensource.com>
Date: Fri, 12 Oct 2012 17:29:51 +0100
To: Ian Campbell 
In-Reply-To: <1350057962.14806.122.camel@zakaz.uk.xensource.com>
References: <1350056739.14806.119.camel@zakaz.uk.xensource.com>
	<1350057020.14806.120.camel@zakaz.uk.xensource.com>
	<1350057962.14806.122.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Roger Pau Monne , xen-devel 
Subject: Re: [Xen-devel] Unable to start a domain with no disks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] Unable to start a domain with no disks"):
> On Fri, 2012-10-12 at 16:50 +0100, Ian Campbell wrote:
> > On Fri, 2012-10-12 at 16:45 +0100, Ian Campbell wrote:
> > > Trying to start a very simple domain with no disk from:

> > This makes the issue go away but since this function also free's the ao
> > I think there must be a use after free somewhere.

In this case what happens is that the tty available event gets queued
in the outer egc, which survives until after libxl__ao_inprogress has
returned.  You only see the bug with no disks because with disks the
events are only generated later in the event loop inside
libxl__ao_inprogress.

Ian.


Subject: [PATCH] libxl: ao: cope with fast ao completion with progess events

There are two egcs in an ao initiator: the one in the AO_CREATE
function, and the one in libxl__ao_inprogress.  If synchronous ao
operation generates progress events and completes immediately, the
progress callbacks end up queued in the outer egc.  These callbacks
are currently only called after libxl__ao_inprogress has returned, and
keep the ao alive until they happen.  This is not good because the
principle is that a synchronous ao is not supposed to survive beyond
libxl__ao_inprogress's return.

The fix is to ensure that the callbacks queued in the outer egc are
called early enough that they don't preserve the ao.  This is
straightforward in the AO_INPROGRESS macro because AO_CREATE's egc is
not used inside that macro other than to destroy it.  All we have to
do is destroy it a bit sooner.

This involves unlocking and relocking the ctx since EGC_FREE expects
to be called with the lock released but libxl__ao_inprogress needs it
locked.  The is hole in our lock tenure is fine - libxl__ao_inprogress
has such holes already.

It is still possible to use the CTX_LOCK macros for this unlock/lock
because the gc we are using is destroyed only afterwards by
libxl__ao_inprogress.

Signed-off-by: Ian Jackson 

diff -r 8aadb3204cfa tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Sep 06 21:41:27 2012 +0200
+++ b/tools/libxl/libxl_internal.h	Fri Oct 12 17:20:10 2012 +0100
@@ -1709,10 +1709,12 @@ _hidden void libxl__egc_cleanup(libxl__e
 
 #define AO_INPROGRESS ({                                        \
         libxl_ctx *ao__ctx = libxl__gc_owner(&ao->gc);          \
+        CTX_UNLOCK;                                             \
+        EGC_FREE;                                               \
+        CTX_LOCK;                                               \
         int ao__rc = libxl__ao_inprogress(ao,                   \
                                __FILE__, __LINE__, __func__);   \
         libxl__ctx_unlock(ao__ctx); /* gc is now invalid */     \
-        EGC_FREE;                                               \
         (ao__rc);                                               \
    })
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 16:30:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 16:30:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMi7Y-000565-7a; Fri, 12 Oct 2012 16:29:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMi7V-00055w-UF
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 16:29:54 +0000
Received: from [85.158.139.83:23572] by server-3.bemta-5.messagelabs.com id
	68/50-09712-18548705; Fri, 12 Oct 2012 16:29:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1350059392!32425874!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQzMTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8882 invoked from network); 12 Oct 2012 16:29:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 16:29:52 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="15133757"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 16:29:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 12 Oct 2012 17:29:51 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TMi7T-00067t-Mi; Fri, 12 Oct 2012 16:29:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TMi7T-0007iM-Io;
	Fri, 12 Oct 2012 17:29:51 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20600.17791.486117.993788@mariner.uk.xensource.com>
Date: Fri, 12 Oct 2012 17:29:51 +0100
To: Ian Campbell 
In-Reply-To: <1350057962.14806.122.camel@zakaz.uk.xensource.com>
References: <1350056739.14806.119.camel@zakaz.uk.xensource.com>
	<1350057020.14806.120.camel@zakaz.uk.xensource.com>
	<1350057962.14806.122.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Roger Pau Monne , xen-devel 
Subject: Re: [Xen-devel] Unable to start a domain with no disks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] Unable to start a domain with no disks"):
> On Fri, 2012-10-12 at 16:50 +0100, Ian Campbell wrote:
> > On Fri, 2012-10-12 at 16:45 +0100, Ian Campbell wrote:
> > > Trying to start a very simple domain with no disk from:

> > This makes the issue go away but since this function also free's the ao
> > I think there must be a use after free somewhere.

In this case what happens is that the tty available event gets queued
in the outer egc, which survives until after libxl__ao_inprogress has
returned.  You only see the bug with no disks because with disks the
events are only generated later in the event loop inside
libxl__ao_inprogress.

Ian.


Subject: [PATCH] libxl: ao: cope with fast ao completion with progess events

There are two egcs in an ao initiator: the one in the AO_CREATE
function, and the one in libxl__ao_inprogress.  If synchronous ao
operation generates progress events and completes immediately, the
progress callbacks end up queued in the outer egc.  These callbacks
are currently only called after libxl__ao_inprogress has returned, and
keep the ao alive until they happen.  This is not good because the
principle is that a synchronous ao is not supposed to survive beyond
libxl__ao_inprogress's return.

The fix is to ensure that the callbacks queued in the outer egc are
called early enough that they don't preserve the ao.  This is
straightforward in the AO_INPROGRESS macro because AO_CREATE's egc is
not used inside that macro other than to destroy it.  All we have to
do is destroy it a bit sooner.

This involves unlocking and relocking the ctx since EGC_FREE expects
to be called with the lock released but libxl__ao_inprogress needs it
locked.  The is hole in our lock tenure is fine - libxl__ao_inprogress
has such holes already.

It is still possible to use the CTX_LOCK macros for this unlock/lock
because the gc we are using is destroyed only afterwards by
libxl__ao_inprogress.

Signed-off-by: Ian Jackson 

diff -r 8aadb3204cfa tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Sep 06 21:41:27 2012 +0200
+++ b/tools/libxl/libxl_internal.h	Fri Oct 12 17:20:10 2012 +0100
@@ -1709,10 +1709,12 @@ _hidden void libxl__egc_cleanup(libxl__e
 
 #define AO_INPROGRESS ({                                        \
         libxl_ctx *ao__ctx = libxl__gc_owner(&ao->gc);          \
+        CTX_UNLOCK;                                             \
+        EGC_FREE;                                               \
+        CTX_LOCK;                                               \
         int ao__rc = libxl__ao_inprogress(ao,                   \
                                __FILE__, __LINE__, __func__);   \
         libxl__ctx_unlock(ao__ctx); /* gc is now invalid */     \
-        EGC_FREE;                                               \
         (ao__rc);                                               \
    })
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 16:30:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 16:30:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMi87-00059b-LA; Fri, 12 Oct 2012 16:30:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMi86-00059S-Ec
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 16:30:30 +0000
Received: from [85.158.139.83:4551] by server-14.bemta-5.messagelabs.com id
	9B/C9-22559-5A548705; Fri, 12 Oct 2012 16:30:29 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1350059427!34616044!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYwMjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16769 invoked from network); 12 Oct 2012 16:30:29 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 16:30:29 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="41051597"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 16:30:04 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Fri, 12 Oct 2012
	12:30:04 -0400
Message-ID: <5078458B.7090901@citrix.com>
Date: Fri, 12 Oct 2012 17:30:03 +0100
From: David Vrabel 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk 
References: <1350046634-2462-1-git-send-email-david.vrabel@citrix.com>
	<1350046634-2462-4-git-send-email-david.vrabel@citrix.com>
	<20121012134147.GA11778@phenom.dumpdata.com>
	<507822ED.2090900@citrix.com>
	
	<5078304D.1050807@citrix.com>
	<20121012150251.GB20842@phenom.dumpdata.com>
	<507841D8.6090205@citrix.com>
	<20121012161610.GA7880@phenom.dumpdata.com>
In-Reply-To: <20121012161610.GA7880@phenom.dumpdata.com>
Cc: Konrad Rzeszutek Wilk ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 3/3] xen/privcmd: add
 IOCTL_PRIVCMD_SYNC_WALLCLOCK to sync Xen's wallclock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/10/12 17:16, Konrad Rzeszutek Wilk wrote:
> 
> So, having both ntpd (which calls call adjtimex) - which would run in the
> background; and hwclock run at startup - (which updates the RTC, which ends
>  - I hope - being trapped by the hypervisor), we end up with the correct
> time, right?

Yes, unless you start a guest before ntpd has synchronized.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 16:30:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 16:30:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMi87-00059b-LA; Fri, 12 Oct 2012 16:30:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMi86-00059S-Ec
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 16:30:30 +0000
Received: from [85.158.139.83:4551] by server-14.bemta-5.messagelabs.com id
	9B/C9-22559-5A548705; Fri, 12 Oct 2012 16:30:29 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1350059427!34616044!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYwMjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16769 invoked from network); 12 Oct 2012 16:30:29 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 16:30:29 -0000
X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="41051597"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 16:30:04 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Fri, 12 Oct 2012
	12:30:04 -0400
Message-ID: <5078458B.7090901@citrix.com>
Date: Fri, 12 Oct 2012 17:30:03 +0100
From: David Vrabel 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk 
References: <1350046634-2462-1-git-send-email-david.vrabel@citrix.com>
	<1350046634-2462-4-git-send-email-david.vrabel@citrix.com>
	<20121012134147.GA11778@phenom.dumpdata.com>
	<507822ED.2090900@citrix.com>
	
	<5078304D.1050807@citrix.com>
	<20121012150251.GB20842@phenom.dumpdata.com>
	<507841D8.6090205@citrix.com>
	<20121012161610.GA7880@phenom.dumpdata.com>
In-Reply-To: <20121012161610.GA7880@phenom.dumpdata.com>
Cc: Konrad Rzeszutek Wilk ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 3/3] xen/privcmd: add
 IOCTL_PRIVCMD_SYNC_WALLCLOCK to sync Xen's wallclock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/10/12 17:16, Konrad Rzeszutek Wilk wrote:
> 
> So, having both ntpd (which calls call adjtimex) - which would run in the
> background; and hwclock run at startup - (which updates the RTC, which ends
>  - I hope - being trapped by the hypervisor), we end up with the correct
> time, right?

Yes, unless you start a guest before ntpd has synchronized.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 16:30:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 16:30:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMi8J-0005Bc-2Q; Fri, 12 Oct 2012 16:30:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMi8H-0005Av-Om
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 16:30:41 +0000
Received: from [85.158.138.51:27881] by server-1.bemta-3.messagelabs.com id
	30/1A-31728-1B548705; Fri, 12 Oct 2012 16:30:41 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1350059440!25283443!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23554 invoked from network); 12 Oct 2012 16:30:40 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 16:30:40 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so2054457eek.32
	for ; Fri, 12 Oct 2012 09:30:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=xFhIdqk6VReb2LzQHJ5b15SvqUIaDYm7Ej0uEFj9Tz0=;
	b=iYb3InKIgXkokOGz6tQRrH1WEGr2f/m9y0KPl80dOGN9oVnSKBJ+N4Z0DjtoGYtc6o
	cF22/lxU5+5mlz7x+oNvnGtMYoV8kWKhhJBkQhvOmM/yP1QZNyoIG/MFpv5LveiLISPO
	QBTFIZ3DcikBBIm+P013WLjcb/L7VaFcWU2m/Tyg91Yh+HzQp1g4IBLD3HMTwF52X1ZU
	O3ylfDind/GRxYKEjjn0unjIDhqHqIWBOUaSvqJS0DsZLeI+gi+rnqeTT5u38ibWoLCV
	2cuTUonSpb2B9lJqY50zqEyd9b6J2l/TdyejY7mC5CsqWyJvVcr0xTXPv8BliRz7/g3M
	96bQ==
Received: by 10.14.213.197 with SMTP id a45mr7652589eep.3.1350059440154;
	Fri, 12 Oct 2012 09:30:40 -0700 (PDT)
Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com.
	[86.183.156.141])
	by mx.google.com with ESMTPS id x42sm12432993eel.11.2012.10.12.09.30.36
	(version=SSLv3 cipher=OTHER); Fri, 12 Oct 2012 09:30:39 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Fri, 12 Oct 2012 17:30:34 +0100
From: Keir Fraser 
To: Andres Lagar-Cavilla , 
Message-ID: 
Thread-Topic: Wait queue support for 4.3
Thread-Index: Ac2oluci6vwM9eG78kGPHOUlC5XXAw==
In-Reply-To: <9105FC08-5D2C-440C-A0F7-C2F2D010E899@gridcentric.ca>
Mime-version: 1.0
Cc: George Dunlap , Olaf Hering ,
	Tim Deegan , Ian Campbell ,
	Jan Beulich 
Subject: Re: [Xen-devel] Wait queue support for 4.3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/10/2012 16:38, "Andres Lagar-Cavilla"  wrote:

> During the last Xen Summit there were informal discussions about the status of
> wait queues in the hypervisor.
> 
> To recap:
> 1. Wait queues are used in mem event, when events generated by a vcpu overflow
> the ring size
> 2. We would like to use wait queues when the hypervisor needs a paged out
> frame (say for hvm_copy)
> 3. We would like to use wait queues to avoid the two decoupled mmio emulation
> passes
> 4. We would like to use wait queues when the hypervisor needs write access to
> a shared frame (say for hvm copy), and unsharing temporarily fails with
> ENOMEM.
> 
> Conceivably more uses for wait queues may come down the line.
> 
> Use-cases 2. and 4. were left out of the time frame of 4.2, because a vcpu
> cannot go to sleep on a wait queue while holding a spinlock, and such
> situations would frequently arise. Preliminary patches from Tim Deegan have
> floated on the list
> (http://lists.xen.org/archives/html/xen-devel/2012-02/msg02133.html). We would
> like this functionality to be present on the mm side for 4.3, and then proceed
> to remove the "thinking" that consumers of the p2m interface now need to
> perform.
>  
> The current maintainer (effectively) for wait queues is Keir. Keir, any ideas
> on a schedule for the cleanup?

I maintain the wait-queue mechanism, but not every (potential) user of it!
The only use-case above that might fall into my domain is 3, I think.

 -- Keir

> Thanks
> Andres
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 16:30:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 16:30:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMi8J-0005Bc-2Q; Fri, 12 Oct 2012 16:30:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMi8H-0005Av-Om
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 16:30:41 +0000
Received: from [85.158.138.51:27881] by server-1.bemta-3.messagelabs.com id
	30/1A-31728-1B548705; Fri, 12 Oct 2012 16:30:41 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1350059440!25283443!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23554 invoked from network); 12 Oct 2012 16:30:40 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 16:30:40 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so2054457eek.32
	for ; Fri, 12 Oct 2012 09:30:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=xFhIdqk6VReb2LzQHJ5b15SvqUIaDYm7Ej0uEFj9Tz0=;
	b=iYb3InKIgXkokOGz6tQRrH1WEGr2f/m9y0KPl80dOGN9oVnSKBJ+N4Z0DjtoGYtc6o
	cF22/lxU5+5mlz7x+oNvnGtMYoV8kWKhhJBkQhvOmM/yP1QZNyoIG/MFpv5LveiLISPO
	QBTFIZ3DcikBBIm+P013WLjcb/L7VaFcWU2m/Tyg91Yh+HzQp1g4IBLD3HMTwF52X1ZU
	O3ylfDind/GRxYKEjjn0unjIDhqHqIWBOUaSvqJS0DsZLeI+gi+rnqeTT5u38ibWoLCV
	2cuTUonSpb2B9lJqY50zqEyd9b6J2l/TdyejY7mC5CsqWyJvVcr0xTXPv8BliRz7/g3M
	96bQ==
Received: by 10.14.213.197 with SMTP id a45mr7652589eep.3.1350059440154;
	Fri, 12 Oct 2012 09:30:40 -0700 (PDT)
Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com.
	[86.183.156.141])
	by mx.google.com with ESMTPS id x42sm12432993eel.11.2012.10.12.09.30.36
	(version=SSLv3 cipher=OTHER); Fri, 12 Oct 2012 09:30:39 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Fri, 12 Oct 2012 17:30:34 +0100
From: Keir Fraser 
To: Andres Lagar-Cavilla , 
Message-ID: 
Thread-Topic: Wait queue support for 4.3
Thread-Index: Ac2oluci6vwM9eG78kGPHOUlC5XXAw==
In-Reply-To: <9105FC08-5D2C-440C-A0F7-C2F2D010E899@gridcentric.ca>
Mime-version: 1.0
Cc: George Dunlap , Olaf Hering ,
	Tim Deegan , Ian Campbell ,
	Jan Beulich 
Subject: Re: [Xen-devel] Wait queue support for 4.3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/10/2012 16:38, "Andres Lagar-Cavilla"  wrote:

> During the last Xen Summit there were informal discussions about the status of
> wait queues in the hypervisor.
> 
> To recap:
> 1. Wait queues are used in mem event, when events generated by a vcpu overflow
> the ring size
> 2. We would like to use wait queues when the hypervisor needs a paged out
> frame (say for hvm_copy)
> 3. We would like to use wait queues to avoid the two decoupled mmio emulation
> passes
> 4. We would like to use wait queues when the hypervisor needs write access to
> a shared frame (say for hvm copy), and unsharing temporarily fails with
> ENOMEM.
> 
> Conceivably more uses for wait queues may come down the line.
> 
> Use-cases 2. and 4. were left out of the time frame of 4.2, because a vcpu
> cannot go to sleep on a wait queue while holding a spinlock, and such
> situations would frequently arise. Preliminary patches from Tim Deegan have
> floated on the list
> (http://lists.xen.org/archives/html/xen-devel/2012-02/msg02133.html). We would
> like this functionality to be present on the mm side for 4.3, and then proceed
> to remove the "thinking" that consumers of the p2m interface now need to
> perform.
>  
> The current maintainer (effectively) for wait queues is Keir. Keir, any ideas
> on a schedule for the cleanup?

I maintain the wait-queue mechanism, but not every (potential) user of it!
The only use-case above that might fall into my domain is 3, I think.

 -- Keir

> Thanks
> Andres
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 16:44:03 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 16:44:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMiKy-0005ct-Oz; Fri, 12 Oct 2012 16:43:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMiKx-0005cm-PT
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 16:43:47 +0000
Received: from [85.158.137.99:28223] by server-10.bemta-3.messagelabs.com id
	D1/19-27386-2C848705; Fri, 12 Oct 2012 16:43:46 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-14.tower-217.messagelabs.com!1350060224!21341920!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8239 invoked from network); 12 Oct 2012 16:43:45 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 16:43:45 -0000
Received: by mail-ie0-f173.google.com with SMTP id 17so6447026iea.32
	for ; Fri, 12 Oct 2012 09:43:44 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=JpBTvsclYQG2yO1rLduKS91rTpWul5x+nxSZhVCNrdw=;
	b=AQnDjSAc+UpxYnv0GPgLykQDF2yReE/qJqwBkmJPmmbDN4S6XaZ1eHxH9WEA80l0fu
	dAihAvN/fPQgWbSTmBLKRix0ookAblin5WqarV9JF0igaJSd/tUQ25xyXjllTif6iGUd
	pxo1fVOs2YxLn51/mxe8eW4KxflCd2aj3Z2ZXWMOk2mgvgwc6aTswdXL5aRsvqQ5ly7k
	QSrEORqc3ZaEwm993J7hshy3dFOdME1AhJ2nQNP08PhpWvx1D5iqtpkHcCc1Vq1sJ9dJ
	OlRb7hrMha7J+OHHshg+BrQFCq8OOioBz3YJhT7NTolJ8w2JCXNQqIRmRIHxmclIrZab
	Y86w==
Received: by 10.50.219.170 with SMTP id pp10mr2654524igc.53.1350060223894;
	Fri, 12 Oct 2012 09:43:43 -0700 (PDT)
Received: from [192.168.3.238] ([206.223.182.18])
	by mx.google.com with ESMTPS id wh5sm1817202igb.17.2012.10.12.09.43.41
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 12 Oct 2012 09:43:42 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1085)
From: Andres Lagar-Cavilla 
In-Reply-To: 
Date: Fri, 12 Oct 2012 12:43:40 -0400
Message-Id: 
References: 
To: Keir Fraser 
X-Mailer: Apple Mail (2.1085)
X-Gm-Message-State: ALoCoQkrdxBPS/6WInmR1sVDn9idMtJKoGLgRycJ/Ipwrtj8ZTvBR/ekwfXEFJ2BOclZcKBXG5LB
Cc: Olaf Hering , Ian Campbell ,
	George Dunlap ,
	Tim Deegan , xen-devel@lists.xen.org,
	Jan Beulich 
Subject: Re: [Xen-devel] Wait queue support for 4.3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Oct 12, 2012, at 12:30 PM, Keir Fraser wrote:

> On 12/10/2012 16:38, "Andres Lagar-Cavilla"  wrote:
> 
>> During the last Xen Summit there were informal discussions about the status of
>> wait queues in the hypervisor.
>> 
>> To recap:
>> 1. Wait queues are used in mem event, when events generated by a vcpu overflow
>> the ring size
>> 2. We would like to use wait queues when the hypervisor needs a paged out
>> frame (say for hvm_copy)
>> 3. We would like to use wait queues to avoid the two decoupled mmio emulation
>> passes
>> 4. We would like to use wait queues when the hypervisor needs write access to
>> a shared frame (say for hvm copy), and unsharing temporarily fails with
>> ENOMEM.
>> 
>> Conceivably more uses for wait queues may come down the line.
>> 
>> Use-cases 2. and 4. were left out of the time frame of 4.2, because a vcpu
>> cannot go to sleep on a wait queue while holding a spinlock, and such
>> situations would frequently arise. Preliminary patches from Tim Deegan have
>> floated on the list
>> (http://lists.xen.org/archives/html/xen-devel/2012-02/msg02133.html). We would
>> like this functionality to be present on the mm side for 4.3, and then proceed
>> to remove the "thinking" that consumers of the p2m interface now need to
>> perform.
>> 
>> The current maintainer (effectively) for wait queues is Keir. Keir, any ideas
>> on a schedule for the cleanup?
> 
> I maintain the wait-queue mechanism, but not every (potential) user of it!

That's the end of my cunning scheme. It was worth a try ...

> The only use-case above that might fall into my domain is 3, I think.

So perhaps mm should wait for that to happen to then tackle wait queues for paging/sharing?

Thanks,
Andres

> 
> -- Keir
> 
>> Thanks
>> Andres
>> 
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 16:44:03 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 16:44:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMiKy-0005ct-Oz; Fri, 12 Oct 2012 16:43:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMiKx-0005cm-PT
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 16:43:47 +0000
Received: from [85.158.137.99:28223] by server-10.bemta-3.messagelabs.com id
	D1/19-27386-2C848705; Fri, 12 Oct 2012 16:43:46 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-14.tower-217.messagelabs.com!1350060224!21341920!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8239 invoked from network); 12 Oct 2012 16:43:45 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 16:43:45 -0000
Received: by mail-ie0-f173.google.com with SMTP id 17so6447026iea.32
	for ; Fri, 12 Oct 2012 09:43:44 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=JpBTvsclYQG2yO1rLduKS91rTpWul5x+nxSZhVCNrdw=;
	b=AQnDjSAc+UpxYnv0GPgLykQDF2yReE/qJqwBkmJPmmbDN4S6XaZ1eHxH9WEA80l0fu
	dAihAvN/fPQgWbSTmBLKRix0ookAblin5WqarV9JF0igaJSd/tUQ25xyXjllTif6iGUd
	pxo1fVOs2YxLn51/mxe8eW4KxflCd2aj3Z2ZXWMOk2mgvgwc6aTswdXL5aRsvqQ5ly7k
	QSrEORqc3ZaEwm993J7hshy3dFOdME1AhJ2nQNP08PhpWvx1D5iqtpkHcCc1Vq1sJ9dJ
	OlRb7hrMha7J+OHHshg+BrQFCq8OOioBz3YJhT7NTolJ8w2JCXNQqIRmRIHxmclIrZab
	Y86w==
Received: by 10.50.219.170 with SMTP id pp10mr2654524igc.53.1350060223894;
	Fri, 12 Oct 2012 09:43:43 -0700 (PDT)
Received: from [192.168.3.238] ([206.223.182.18])
	by mx.google.com with ESMTPS id wh5sm1817202igb.17.2012.10.12.09.43.41
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 12 Oct 2012 09:43:42 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1085)
From: Andres Lagar-Cavilla 
In-Reply-To: 
Date: Fri, 12 Oct 2012 12:43:40 -0400
Message-Id: 
References: 
To: Keir Fraser 
X-Mailer: Apple Mail (2.1085)
X-Gm-Message-State: ALoCoQkrdxBPS/6WInmR1sVDn9idMtJKoGLgRycJ/Ipwrtj8ZTvBR/ekwfXEFJ2BOclZcKBXG5LB
Cc: Olaf Hering , Ian Campbell ,
	George Dunlap ,
	Tim Deegan , xen-devel@lists.xen.org,
	Jan Beulich 
Subject: Re: [Xen-devel] Wait queue support for 4.3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Oct 12, 2012, at 12:30 PM, Keir Fraser wrote:

> On 12/10/2012 16:38, "Andres Lagar-Cavilla"  wrote:
> 
>> During the last Xen Summit there were informal discussions about the status of
>> wait queues in the hypervisor.
>> 
>> To recap:
>> 1. Wait queues are used in mem event, when events generated by a vcpu overflow
>> the ring size
>> 2. We would like to use wait queues when the hypervisor needs a paged out
>> frame (say for hvm_copy)
>> 3. We would like to use wait queues to avoid the two decoupled mmio emulation
>> passes
>> 4. We would like to use wait queues when the hypervisor needs write access to
>> a shared frame (say for hvm copy), and unsharing temporarily fails with
>> ENOMEM.
>> 
>> Conceivably more uses for wait queues may come down the line.
>> 
>> Use-cases 2. and 4. were left out of the time frame of 4.2, because a vcpu
>> cannot go to sleep on a wait queue while holding a spinlock, and such
>> situations would frequently arise. Preliminary patches from Tim Deegan have
>> floated on the list
>> (http://lists.xen.org/archives/html/xen-devel/2012-02/msg02133.html). We would
>> like this functionality to be present on the mm side for 4.3, and then proceed
>> to remove the "thinking" that consumers of the p2m interface now need to
>> perform.
>> 
>> The current maintainer (effectively) for wait queues is Keir. Keir, any ideas
>> on a schedule for the cleanup?
> 
> I maintain the wait-queue mechanism, but not every (potential) user of it!

That's the end of my cunning scheme. It was worth a try ...

> The only use-case above that might fall into my domain is 3, I think.

So perhaps mm should wait for that to happen to then tackle wait queues for paging/sharing?

Thanks,
Andres

> 
> -- Keir
> 
>> Thanks
>> Andres
>> 
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 17:27:03 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 17:27:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMj0S-0005tz-Re; Fri, 12 Oct 2012 17:26:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMj0R-0005tu-DN
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 17:26:39 +0000
Received: from [85.158.143.35:35469] by server-2.bemta-4.messagelabs.com id
	DB/04-25171-EC258705; Fri, 12 Oct 2012 17:26:38 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1350062790!6410286!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27724 invoked from network); 12 Oct 2012 17:26:32 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 17:26:32 -0000
Received: by mail-wg0-f51.google.com with SMTP id ed3so1853387wgb.32
	for ; Fri, 12 Oct 2012 10:26:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=tosP0qcaqeYprfMiQhrzafAgvgswzQnSZdZCTXzniYc=;
	b=GYl0CTPE08wzlh1p9PexZDGnIazl3b3ws/Mp6f06Gw+KaOIL6+Cy79pL6+3LxKRU3N
	pmWDe53U6vId9bdcfOkoGGNE+UMgf8sLFTLZ9IsbrKy6jlk9yFzaV1ugFMbJA1zsdgkd
	oSdiA69VvFcRM3UOKIklC/xB+h1aaSozsZpZsOudJyPjf00c8XAW0/Wc19ic8WY14l7N
	aCKceUTT7o84qPAmcrt4Jfu7arRBjP+x34sfoUp1xI9DdTX6vVKaTgV+wdBBX7xxR3TU
	w1hGXzG75tj1pvwsin/TU2fGRei58MqUeEDG0gTrxkDNOzp60fpDuuuZINZCiA43/kql
	/hvg==
Received: by 10.216.193.220 with SMTP id k70mr3281674wen.35.1350062787182;
	Fri, 12 Oct 2012 10:26:27 -0700 (PDT)
Received: from [192.168.1.69]
	(host86-183-156-141.range86-183.btcentralplus.com. [86.183.156.141])
	by mx.google.com with ESMTPS id b3sm4175896wie.0.2012.10.12.10.26.22
	(version=SSLv3 cipher=OTHER); Fri, 12 Oct 2012 10:26:25 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Fri, 12 Oct 2012 18:26:17 +0100
From: Keir Fraser 
To: Andres Lagar-Cavilla 
Message-ID: 
Thread-Topic: Wait queue support for 4.3
Thread-Index: Ac2onq+4Dv0ZJmwsck+hn/eDxcSAjA==
In-Reply-To: 
Mime-version: 1.0
Cc: Olaf Hering , Ian Campbell ,
	George Dunlap ,
	Tim Deegan , xen-devel@lists.xen.org,
	Jan Beulich 
Subject: Re: [Xen-devel] Wait queue support for 4.3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/10/2012 17:43, "Andres Lagar-Cavilla"  wrote:

>>> The current maintainer (effectively) for wait queues is Keir. Keir, any
>>> ideas
>>> on a schedule for the cleanup?
>> 
>> I maintain the wait-queue mechanism, but not every (potential) user of it!
> 
> That's the end of my cunning scheme. It was worth a try ...
> 
>> The only use-case above that might fall into my domain is 3, I think.
> 
> So perhaps mm should wait for that to happen to then tackle wait queues for
> paging/sharing?

I don't see any dependency. And Tim has already proposed patches for
use-case 2, in fact, as you noted. So, shouldn't they simply be polished up
and applied as soon as possible? Basically, for mm type things, Tim is your
man, either as author or reviewer.

 -- Keir

> Thanks,
> Andres



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 17:27:03 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 17:27:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMj0S-0005tz-Re; Fri, 12 Oct 2012 17:26:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMj0R-0005tu-DN
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 17:26:39 +0000
Received: from [85.158.143.35:35469] by server-2.bemta-4.messagelabs.com id
	DB/04-25171-EC258705; Fri, 12 Oct 2012 17:26:38 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1350062790!6410286!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27724 invoked from network); 12 Oct 2012 17:26:32 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 17:26:32 -0000
Received: by mail-wg0-f51.google.com with SMTP id ed3so1853387wgb.32
	for ; Fri, 12 Oct 2012 10:26:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=tosP0qcaqeYprfMiQhrzafAgvgswzQnSZdZCTXzniYc=;
	b=GYl0CTPE08wzlh1p9PexZDGnIazl3b3ws/Mp6f06Gw+KaOIL6+Cy79pL6+3LxKRU3N
	pmWDe53U6vId9bdcfOkoGGNE+UMgf8sLFTLZ9IsbrKy6jlk9yFzaV1ugFMbJA1zsdgkd
	oSdiA69VvFcRM3UOKIklC/xB+h1aaSozsZpZsOudJyPjf00c8XAW0/Wc19ic8WY14l7N
	aCKceUTT7o84qPAmcrt4Jfu7arRBjP+x34sfoUp1xI9DdTX6vVKaTgV+wdBBX7xxR3TU
	w1hGXzG75tj1pvwsin/TU2fGRei58MqUeEDG0gTrxkDNOzp60fpDuuuZINZCiA43/kql
	/hvg==
Received: by 10.216.193.220 with SMTP id k70mr3281674wen.35.1350062787182;
	Fri, 12 Oct 2012 10:26:27 -0700 (PDT)
Received: from [192.168.1.69]
	(host86-183-156-141.range86-183.btcentralplus.com. [86.183.156.141])
	by mx.google.com with ESMTPS id b3sm4175896wie.0.2012.10.12.10.26.22
	(version=SSLv3 cipher=OTHER); Fri, 12 Oct 2012 10:26:25 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Fri, 12 Oct 2012 18:26:17 +0100
From: Keir Fraser 
To: Andres Lagar-Cavilla 
Message-ID: 
Thread-Topic: Wait queue support for 4.3
Thread-Index: Ac2onq+4Dv0ZJmwsck+hn/eDxcSAjA==
In-Reply-To: 
Mime-version: 1.0
Cc: Olaf Hering , Ian Campbell ,
	George Dunlap ,
	Tim Deegan , xen-devel@lists.xen.org,
	Jan Beulich 
Subject: Re: [Xen-devel] Wait queue support for 4.3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/10/2012 17:43, "Andres Lagar-Cavilla"  wrote:

>>> The current maintainer (effectively) for wait queues is Keir. Keir, any
>>> ideas
>>> on a schedule for the cleanup?
>> 
>> I maintain the wait-queue mechanism, but not every (potential) user of it!
> 
> That's the end of my cunning scheme. It was worth a try ...
> 
>> The only use-case above that might fall into my domain is 3, I think.
> 
> So perhaps mm should wait for that to happen to then tackle wait queues for
> paging/sharing?

I don't see any dependency. And Tim has already proposed patches for
use-case 2, in fact, as you noted. So, shouldn't they simply be polished up
and applied as soon as possible? Basically, for mm type things, Tim is your
man, either as author or reviewer.

 -- Keir

> Thanks,
> Andres



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 17:32:51 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 17:32:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMj65-00062M-LU; Fri, 12 Oct 2012 17:32:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMj63-00062E-U7
	for xen-devel@lists.xensource.com; Fri, 12 Oct 2012 17:32:28 +0000
Received: from [85.158.137.99:17594] by server-14.bemta-3.messagelabs.com id
	DB/B7-17276-B2458705; Fri, 12 Oct 2012 17:32:27 +0000
X-Env-Sender: dcm@mccr.org
X-Msg-Ref: server-4.tower-217.messagelabs.com!1350063145!21398216!1
X-Originating-IP: [204.13.248.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA0LjEzLjI0OC42NiA9PiAxODgwNjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29363 invoked from network); 12 Oct 2012 17:32:26 -0000
Received: from mho-03-ewr.mailhop.org (HELO mho-01-ewr.mailhop.org)
	(204.13.248.66)
	by server-4.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Oct 2012 17:32:26 -0000
Received: from [67.21.176.24] (helo=magnum.int.mccr.org)
	by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256)
	(Exim 4.72) (envelope-from )
	id 1TMj61-0005sx-CV; Fri, 12 Oct 2012 17:32:25 +0000
X-Mail-Handler: Dyn Standard SMTP by Dyn
X-Originating-IP: 67.21.176.24
X-Report-Abuse-To: abuse@dyndns.com (see
	http://www.dyndns.com/services/sendlabs/outbound_abuse.html for
	abuse reporting information)
X-MHO-User: U2FsdGVkX19sME5r86Wz5EkzBz/6N6KjvJbi4ArqCcU=
From: Dave McCracken 
To: George Dunlap ,Keir Fraser 
Date: Fri, 12 Oct 2012 12:32:22 -0500
Message-Id: <20121012173222.31965.33368.sendpatchset@magnum.int.mccr.org>
Cc: Xen Developers List 
Subject: [Xen-devel] [PATCH] Make restore work properly with PV superpage
	flag
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

For PV guests, the superpage flag means to unconditionally allocate all
pages as superpages, which is required for Linux hugepages to work.  Support
for this on restore was not supported.  This patch adds proper support for
the superpage flag on restore.

For HVM guests, the superpage flag has been used to mean attempt to allocate
superpages if possible on restore.  This functionality has been preserved.

Signed-off-by: Dave McCracken 

--------

 xc_domain_restore.c |  130 ++++++++++++++++++++++++++++++++++++++++------------
 1 file changed, 101 insertions(+), 29 deletions(-)


--- xen-unstable/tools/libxc/xc_domain_restore.c	2012-08-18 10:04:53.000000000 -0500
+++ xen-unstable-restore//tools/libxc/xc_domain_restore.c	2012-08-20 07:24:22.000000000 -0500
@@ -23,6 +23,19 @@
  *
  */
 
+/*
+ * The superpages flag in restore has two different meanings depending on
+ * the type of domain.
+ *
+ * For an HVM domain, the flag means to look for properly aligned contiguous
+ * pages and try to allocate a superpage to satisfy it.  If that fails,
+ * fall back to small pages.
+ *
+ * For a PV domain, the flag means allocate all memory as superpages.  If that
+ * fails, the restore fails.  This behavior is required for PV guests who
+ * want to use superpages.
+ */
+
 #include 
 #include 
 
@@ -41,6 +54,9 @@ struct restore_ctx {
     xen_pfn_t *live_p2m; /* Live mapping of the table mapping each PFN to its current MFN. */
     xen_pfn_t *p2m; /* A table mapping each PFN to its new MFN. */
     xen_pfn_t *p2m_batch; /* A table of P2M mappings in the current region.  */
+    xen_pfn_t *p2m_saved_batch; /* Copy of p2m_batch array for pv superpage alloc */
+    int superpages; /* Superpage allocation has been requested */
+    int hvm;    /* This is an hvm domain */
     int completed; /* Set when a consistent image is available */
     int last_checkpoint; /* Set when we should commit to the current checkpoint when it completes. */
     int compressing; /* Set when sender signals that pages would be sent compressed (for Remus) */
@@ -49,11 +65,6 @@ struct restore_ctx {
 
 #define HEARTBEAT_MS 1000
 
-#define SUPERPAGE_PFN_SHIFT  9
-#define SUPERPAGE_NR_PFNS    (1UL << SUPERPAGE_PFN_SHIFT)
-
-#define SUPER_PAGE_START(pfn)    (((pfn) & (SUPERPAGE_NR_PFNS-1)) == 0 )
-
 #ifndef __MINIOS__
 static ssize_t rdexact(xc_interface *xch, struct restore_ctx *ctx,
                        int fd, void* buf, size_t size)
@@ -103,6 +114,49 @@ static ssize_t rdexact(xc_interface *xch
 #else
 #define RDEXACT read_exact
 #endif
+
+#define SUPERPAGE_PFN_SHIFT  9
+#define SUPERPAGE_NR_PFNS    (1UL << SUPERPAGE_PFN_SHIFT)
+#define SUPERPAGE(_pfn) ((_pfn) & (~(SUPERPAGE_NR_PFNS-1)))
+#define SUPER_PAGE_START(pfn)    (((pfn) & (SUPERPAGE_NR_PFNS-1)) == 0 )
+
+/*
+** When we're restoring into a pv superpage-allocated guest, we take
+** a copy of the p2m_batch array to preserve the pfn, then allocate the
+** corresponding superpages.  We then fill in the p2m array using the saved
+** pfns.
+*/
+static int alloc_superpage_mfns(
+    xc_interface *xch, uint32_t dom, struct restore_ctx *ctx, int nr_mfns)
+{
+    int i, j, max = 0;
+    unsigned long pfn, base_pfn, mfn;
+    
+    for (i = 0; i < nr_mfns; i++)
+    {
+        pfn = ctx->p2m_batch[i];
+        base_pfn = SUPERPAGE(pfn);
+        if (ctx->p2m[base_pfn] != (INVALID_P2M_ENTRY-2))
+        {
+            ctx->p2m_saved_batch[max] = base_pfn;
+            ctx->p2m_batch[max] = base_pfn;
+            max++;
+            ctx->p2m[base_pfn] = INVALID_P2M_ENTRY-2;
+        }
+    }
+    if (xc_domain_populate_physmap_exact(xch, dom, max, SUPERPAGE_PFN_SHIFT,
+                                         0, ctx->p2m_batch) != 0)
+        return 1;
+
+    for (i = 0; i < max; i++)
+    {
+        mfn = ctx->p2m_batch[i];
+        pfn = ctx->p2m_saved_batch[i];
+        for (j = 0; j < SUPERPAGE_NR_PFNS; j++)
+            ctx->p2m[pfn++] = mfn++;
+    }
+    return 0;
+}
 /*
 ** In the state file (or during transfer), all page-table pages are
 ** converted into a 'canonical' form where references to actual mfns
@@ -113,7 +167,7 @@ static ssize_t rdexact(xc_interface *xch
 static int uncanonicalize_pagetable(
     xc_interface *xch, uint32_t dom, struct restore_ctx *ctx, void *page)
 {
-    int i, pte_last, nr_mfns = 0;
+    int i, rc, pte_last, nr_mfns = 0;
     unsigned long pfn;
     uint64_t pte;
     struct domain_info_context *dinfo = &ctx->dinfo;
@@ -152,13 +206,20 @@ static int uncanonicalize_pagetable(
     }
 
     /* Allocate the requisite number of mfns. */
-    if ( nr_mfns &&
-         (xc_domain_populate_physmap_exact(xch, dom, nr_mfns, 0, 0,
-                                            ctx->p2m_batch) != 0) )
-    { 
-        ERROR("Failed to allocate memory for batch.!\n"); 
-        errno = ENOMEM;
-        return 0; 
+    if (nr_mfns)
+    {
+        if (!ctx->hvm && ctx->superpages)
+            rc = alloc_superpage_mfns(xch, dom, ctx, nr_mfns);
+        else
+            rc = xc_domain_populate_physmap_exact(xch, dom, nr_mfns, 0, 0,
+                                                  ctx->p2m_batch);
+    
+        if (rc)
+        {
+            ERROR("Failed to allocate memory for batch.!\n"); 
+            errno = ENOMEM;
+            return 0; 
+        }
     }
     
     /* Second pass: uncanonicalize each present PTE */
@@ -1018,8 +1079,8 @@ static int pagebuf_get(xc_interface *xch
 
 static int apply_batch(xc_interface *xch, uint32_t dom, struct restore_ctx *ctx,
                        xen_pfn_t* region_mfn, unsigned long* pfn_type, int pae_extended_cr3,
-                       unsigned int hvm, struct xc_mmu* mmu,
-                       pagebuf_t* pagebuf, int curbatch, int superpages)
+                       struct xc_mmu* mmu,
+                       pagebuf_t* pagebuf, int curbatch)
 {
     int i, j, curpage, nr_mfns;
     int k, scount;
@@ -1061,7 +1122,7 @@ static int apply_batch(xc_interface *xch
                 /* Is this the next expected continuation? */
                 if ( pfn == superpage_start + scount )
                 {
-                    if ( !superpages )
+                    if ( !ctx->superpages )
                     {
                         ERROR("Unexpexted codepath with no superpages");
                         return -1;
@@ -1114,16 +1175,17 @@ static int apply_batch(xc_interface *xch
             }
 
             /* Are we ready to start a new superpage candidate? */
-            if ( superpages && SUPER_PAGE_START(pfn) )
+            if ( ctx->hvm && ctx->superpages && SUPER_PAGE_START(pfn) )
             {
                 superpage_start=pfn;
                 scount++;
-                continue;
             }
-            
-            /* Add the current pfn to pfn_batch */
-            ctx->p2m_batch[nr_mfns++] = pfn; 
-            ctx->p2m[pfn]--;
+            else
+            {
+                /* Add the current pfn to pfn_batch */
+                ctx->p2m_batch[nr_mfns++] = pfn; 
+                ctx->p2m[pfn]--;
+            }
         }
     }
 
@@ -1144,9 +1206,14 @@ static int apply_batch(xc_interface *xch
     {
         DPRINTF("Mapping order 0,  %d; first pfn %lx\n", nr_mfns, ctx->p2m_batch[0]);
     
-        if(xc_domain_populate_physmap_exact(xch, dom, nr_mfns, 0,
-                                            0, ctx->p2m_batch) != 0) 
-        { 
+        if (!ctx->hvm && ctx->superpages)
+            rc = alloc_superpage_mfns(xch, dom, ctx, nr_mfns);
+        else
+            rc = xc_domain_populate_physmap_exact(xch, dom, nr_mfns, 0, 0,
+                                                  ctx->p2m_batch);
+    
+        if (rc)
+        {
             ERROR("Failed to allocate memory for batch.!\n"); 
             errno = ENOMEM;
             return -1;
@@ -1175,7 +1242,7 @@ static int apply_batch(xc_interface *xch
              || pagetype == XEN_DOMCTL_PFINFO_XALLOC )
             region_mfn[i] = ~0UL; /* map will fail but we don't care */
         else
-            region_mfn[i] = hvm ? pfn : ctx->p2m[pfn]; 
+            region_mfn[i] = ctx->hvm ? pfn : ctx->p2m[pfn]; 
     }
 
     /* Map relevant mfns */
@@ -1298,7 +1365,7 @@ static int apply_batch(xc_interface *xch
             }
         }
 
-        if ( !hvm &&
+        if ( !ctx->hvm &&
              xc_add_mmu_update(xch, mmu,
                                (((unsigned long long)mfn) << PAGE_SHIFT)
                                | MMU_MACHPHYS_UPDATE, pfn) )
@@ -1389,6 +1456,9 @@ int xc_domain_restore(xc_interface *xch,
 
     memset(ctx, 0, sizeof(*ctx));
 
+    ctx->superpages = superpages;
+    ctx->hvm = hvm;
+
     ctxt = xc_hypercall_buffer_alloc(xch, ctxt, sizeof(*ctxt));
 
     if ( ctxt == NULL )
@@ -1452,6 +1522,9 @@ int xc_domain_restore(xc_interface *xch,
 
     region_mfn = malloc(ROUNDUP(MAX_BATCH_SIZE * sizeof(xen_pfn_t), PAGE_SHIFT));
     ctx->p2m_batch = malloc(ROUNDUP(MAX_BATCH_SIZE * sizeof(xen_pfn_t), PAGE_SHIFT));
+    if (!ctx->hvm && ctx->superpages)
+        ctx->p2m_saved_batch =
+            malloc(ROUNDUP(MAX_BATCH_SIZE * sizeof(xen_pfn_t), PAGE_SHIFT));
 
     if ( (ctx->p2m == NULL) || (pfn_type == NULL) ||
          (region_mfn == NULL) || (ctx->p2m_batch == NULL) )
@@ -1575,8 +1648,7 @@ int xc_domain_restore(xc_interface *xch,
             int brc;
 
             brc = apply_batch(xch, dom, ctx, region_mfn, pfn_type,
-                              pae_extended_cr3, hvm, mmu, &pagebuf, curbatch,
-                              superpages);
+                              pae_extended_cr3, mmu, &pagebuf, curbatch);
             if ( brc < 0 )
                 goto out;
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 17:32:51 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 17:32:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMj65-00062M-LU; Fri, 12 Oct 2012 17:32:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMj63-00062E-U7
	for xen-devel@lists.xensource.com; Fri, 12 Oct 2012 17:32:28 +0000
Received: from [85.158.137.99:17594] by server-14.bemta-3.messagelabs.com id
	DB/B7-17276-B2458705; Fri, 12 Oct 2012 17:32:27 +0000
X-Env-Sender: dcm@mccr.org
X-Msg-Ref: server-4.tower-217.messagelabs.com!1350063145!21398216!1
X-Originating-IP: [204.13.248.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA0LjEzLjI0OC42NiA9PiAxODgwNjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29363 invoked from network); 12 Oct 2012 17:32:26 -0000
Received: from mho-03-ewr.mailhop.org (HELO mho-01-ewr.mailhop.org)
	(204.13.248.66)
	by server-4.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Oct 2012 17:32:26 -0000
Received: from [67.21.176.24] (helo=magnum.int.mccr.org)
	by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256)
	(Exim 4.72) (envelope-from )
	id 1TMj61-0005sx-CV; Fri, 12 Oct 2012 17:32:25 +0000
X-Mail-Handler: Dyn Standard SMTP by Dyn
X-Originating-IP: 67.21.176.24
X-Report-Abuse-To: abuse@dyndns.com (see
	http://www.dyndns.com/services/sendlabs/outbound_abuse.html for
	abuse reporting information)
X-MHO-User: U2FsdGVkX19sME5r86Wz5EkzBz/6N6KjvJbi4ArqCcU=
From: Dave McCracken 
To: George Dunlap ,Keir Fraser 
Date: Fri, 12 Oct 2012 12:32:22 -0500
Message-Id: <20121012173222.31965.33368.sendpatchset@magnum.int.mccr.org>
Cc: Xen Developers List 
Subject: [Xen-devel] [PATCH] Make restore work properly with PV superpage
	flag
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

For PV guests, the superpage flag means to unconditionally allocate all
pages as superpages, which is required for Linux hugepages to work.  Support
for this on restore was not supported.  This patch adds proper support for
the superpage flag on restore.

For HVM guests, the superpage flag has been used to mean attempt to allocate
superpages if possible on restore.  This functionality has been preserved.

Signed-off-by: Dave McCracken 

--------

 xc_domain_restore.c |  130 ++++++++++++++++++++++++++++++++++++++++------------
 1 file changed, 101 insertions(+), 29 deletions(-)


--- xen-unstable/tools/libxc/xc_domain_restore.c	2012-08-18 10:04:53.000000000 -0500
+++ xen-unstable-restore//tools/libxc/xc_domain_restore.c	2012-08-20 07:24:22.000000000 -0500
@@ -23,6 +23,19 @@
  *
  */
 
+/*
+ * The superpages flag in restore has two different meanings depending on
+ * the type of domain.
+ *
+ * For an HVM domain, the flag means to look for properly aligned contiguous
+ * pages and try to allocate a superpage to satisfy it.  If that fails,
+ * fall back to small pages.
+ *
+ * For a PV domain, the flag means allocate all memory as superpages.  If that
+ * fails, the restore fails.  This behavior is required for PV guests who
+ * want to use superpages.
+ */
+
 #include 
 #include 
 
@@ -41,6 +54,9 @@ struct restore_ctx {
     xen_pfn_t *live_p2m; /* Live mapping of the table mapping each PFN to its current MFN. */
     xen_pfn_t *p2m; /* A table mapping each PFN to its new MFN. */
     xen_pfn_t *p2m_batch; /* A table of P2M mappings in the current region.  */
+    xen_pfn_t *p2m_saved_batch; /* Copy of p2m_batch array for pv superpage alloc */
+    int superpages; /* Superpage allocation has been requested */
+    int hvm;    /* This is an hvm domain */
     int completed; /* Set when a consistent image is available */
     int last_checkpoint; /* Set when we should commit to the current checkpoint when it completes. */
     int compressing; /* Set when sender signals that pages would be sent compressed (for Remus) */
@@ -49,11 +65,6 @@ struct restore_ctx {
 
 #define HEARTBEAT_MS 1000
 
-#define SUPERPAGE_PFN_SHIFT  9
-#define SUPERPAGE_NR_PFNS    (1UL << SUPERPAGE_PFN_SHIFT)
-
-#define SUPER_PAGE_START(pfn)    (((pfn) & (SUPERPAGE_NR_PFNS-1)) == 0 )
-
 #ifndef __MINIOS__
 static ssize_t rdexact(xc_interface *xch, struct restore_ctx *ctx,
                        int fd, void* buf, size_t size)
@@ -103,6 +114,49 @@ static ssize_t rdexact(xc_interface *xch
 #else
 #define RDEXACT read_exact
 #endif
+
+#define SUPERPAGE_PFN_SHIFT  9
+#define SUPERPAGE_NR_PFNS    (1UL << SUPERPAGE_PFN_SHIFT)
+#define SUPERPAGE(_pfn) ((_pfn) & (~(SUPERPAGE_NR_PFNS-1)))
+#define SUPER_PAGE_START(pfn)    (((pfn) & (SUPERPAGE_NR_PFNS-1)) == 0 )
+
+/*
+** When we're restoring into a pv superpage-allocated guest, we take
+** a copy of the p2m_batch array to preserve the pfn, then allocate the
+** corresponding superpages.  We then fill in the p2m array using the saved
+** pfns.
+*/
+static int alloc_superpage_mfns(
+    xc_interface *xch, uint32_t dom, struct restore_ctx *ctx, int nr_mfns)
+{
+    int i, j, max = 0;
+    unsigned long pfn, base_pfn, mfn;
+    
+    for (i = 0; i < nr_mfns; i++)
+    {
+        pfn = ctx->p2m_batch[i];
+        base_pfn = SUPERPAGE(pfn);
+        if (ctx->p2m[base_pfn] != (INVALID_P2M_ENTRY-2))
+        {
+            ctx->p2m_saved_batch[max] = base_pfn;
+            ctx->p2m_batch[max] = base_pfn;
+            max++;
+            ctx->p2m[base_pfn] = INVALID_P2M_ENTRY-2;
+        }
+    }
+    if (xc_domain_populate_physmap_exact(xch, dom, max, SUPERPAGE_PFN_SHIFT,
+                                         0, ctx->p2m_batch) != 0)
+        return 1;
+
+    for (i = 0; i < max; i++)
+    {
+        mfn = ctx->p2m_batch[i];
+        pfn = ctx->p2m_saved_batch[i];
+        for (j = 0; j < SUPERPAGE_NR_PFNS; j++)
+            ctx->p2m[pfn++] = mfn++;
+    }
+    return 0;
+}
 /*
 ** In the state file (or during transfer), all page-table pages are
 ** converted into a 'canonical' form where references to actual mfns
@@ -113,7 +167,7 @@ static ssize_t rdexact(xc_interface *xch
 static int uncanonicalize_pagetable(
     xc_interface *xch, uint32_t dom, struct restore_ctx *ctx, void *page)
 {
-    int i, pte_last, nr_mfns = 0;
+    int i, rc, pte_last, nr_mfns = 0;
     unsigned long pfn;
     uint64_t pte;
     struct domain_info_context *dinfo = &ctx->dinfo;
@@ -152,13 +206,20 @@ static int uncanonicalize_pagetable(
     }
 
     /* Allocate the requisite number of mfns. */
-    if ( nr_mfns &&
-         (xc_domain_populate_physmap_exact(xch, dom, nr_mfns, 0, 0,
-                                            ctx->p2m_batch) != 0) )
-    { 
-        ERROR("Failed to allocate memory for batch.!\n"); 
-        errno = ENOMEM;
-        return 0; 
+    if (nr_mfns)
+    {
+        if (!ctx->hvm && ctx->superpages)
+            rc = alloc_superpage_mfns(xch, dom, ctx, nr_mfns);
+        else
+            rc = xc_domain_populate_physmap_exact(xch, dom, nr_mfns, 0, 0,
+                                                  ctx->p2m_batch);
+    
+        if (rc)
+        {
+            ERROR("Failed to allocate memory for batch.!\n"); 
+            errno = ENOMEM;
+            return 0; 
+        }
     }
     
     /* Second pass: uncanonicalize each present PTE */
@@ -1018,8 +1079,8 @@ static int pagebuf_get(xc_interface *xch
 
 static int apply_batch(xc_interface *xch, uint32_t dom, struct restore_ctx *ctx,
                        xen_pfn_t* region_mfn, unsigned long* pfn_type, int pae_extended_cr3,
-                       unsigned int hvm, struct xc_mmu* mmu,
-                       pagebuf_t* pagebuf, int curbatch, int superpages)
+                       struct xc_mmu* mmu,
+                       pagebuf_t* pagebuf, int curbatch)
 {
     int i, j, curpage, nr_mfns;
     int k, scount;
@@ -1061,7 +1122,7 @@ static int apply_batch(xc_interface *xch
                 /* Is this the next expected continuation? */
                 if ( pfn == superpage_start + scount )
                 {
-                    if ( !superpages )
+                    if ( !ctx->superpages )
                     {
                         ERROR("Unexpexted codepath with no superpages");
                         return -1;
@@ -1114,16 +1175,17 @@ static int apply_batch(xc_interface *xch
             }
 
             /* Are we ready to start a new superpage candidate? */
-            if ( superpages && SUPER_PAGE_START(pfn) )
+            if ( ctx->hvm && ctx->superpages && SUPER_PAGE_START(pfn) )
             {
                 superpage_start=pfn;
                 scount++;
-                continue;
             }
-            
-            /* Add the current pfn to pfn_batch */
-            ctx->p2m_batch[nr_mfns++] = pfn; 
-            ctx->p2m[pfn]--;
+            else
+            {
+                /* Add the current pfn to pfn_batch */
+                ctx->p2m_batch[nr_mfns++] = pfn; 
+                ctx->p2m[pfn]--;
+            }
         }
     }
 
@@ -1144,9 +1206,14 @@ static int apply_batch(xc_interface *xch
     {
         DPRINTF("Mapping order 0,  %d; first pfn %lx\n", nr_mfns, ctx->p2m_batch[0]);
     
-        if(xc_domain_populate_physmap_exact(xch, dom, nr_mfns, 0,
-                                            0, ctx->p2m_batch) != 0) 
-        { 
+        if (!ctx->hvm && ctx->superpages)
+            rc = alloc_superpage_mfns(xch, dom, ctx, nr_mfns);
+        else
+            rc = xc_domain_populate_physmap_exact(xch, dom, nr_mfns, 0, 0,
+                                                  ctx->p2m_batch);
+    
+        if (rc)
+        {
             ERROR("Failed to allocate memory for batch.!\n"); 
             errno = ENOMEM;
             return -1;
@@ -1175,7 +1242,7 @@ static int apply_batch(xc_interface *xch
              || pagetype == XEN_DOMCTL_PFINFO_XALLOC )
             region_mfn[i] = ~0UL; /* map will fail but we don't care */
         else
-            region_mfn[i] = hvm ? pfn : ctx->p2m[pfn]; 
+            region_mfn[i] = ctx->hvm ? pfn : ctx->p2m[pfn]; 
     }
 
     /* Map relevant mfns */
@@ -1298,7 +1365,7 @@ static int apply_batch(xc_interface *xch
             }
         }
 
-        if ( !hvm &&
+        if ( !ctx->hvm &&
              xc_add_mmu_update(xch, mmu,
                                (((unsigned long long)mfn) << PAGE_SHIFT)
                                | MMU_MACHPHYS_UPDATE, pfn) )
@@ -1389,6 +1456,9 @@ int xc_domain_restore(xc_interface *xch,
 
     memset(ctx, 0, sizeof(*ctx));
 
+    ctx->superpages = superpages;
+    ctx->hvm = hvm;
+
     ctxt = xc_hypercall_buffer_alloc(xch, ctxt, sizeof(*ctxt));
 
     if ( ctxt == NULL )
@@ -1452,6 +1522,9 @@ int xc_domain_restore(xc_interface *xch,
 
     region_mfn = malloc(ROUNDUP(MAX_BATCH_SIZE * sizeof(xen_pfn_t), PAGE_SHIFT));
     ctx->p2m_batch = malloc(ROUNDUP(MAX_BATCH_SIZE * sizeof(xen_pfn_t), PAGE_SHIFT));
+    if (!ctx->hvm && ctx->superpages)
+        ctx->p2m_saved_batch =
+            malloc(ROUNDUP(MAX_BATCH_SIZE * sizeof(xen_pfn_t), PAGE_SHIFT));
 
     if ( (ctx->p2m == NULL) || (pfn_type == NULL) ||
          (region_mfn == NULL) || (ctx->p2m_batch == NULL) )
@@ -1575,8 +1648,7 @@ int xc_domain_restore(xc_interface *xch,
             int brc;
 
             brc = apply_batch(xch, dom, ctx, region_mfn, pfn_type,
-                              pae_extended_cr3, hvm, mmu, &pagebuf, curbatch,
-                              superpages);
+                              pae_extended_cr3, mmu, &pagebuf, curbatch);
             if ( brc < 0 )
                 goto out;
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 18:15:40 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 18:15:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMjlT-0006KQ-B3; Fri, 12 Oct 2012 18:15:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMjlS-0006KL-Ek
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 18:15:14 +0000
Received: from [85.158.143.99:19008] by server-3.bemta-4.messagelabs.com id
	D8/A0-10075-13E58705; Fri, 12 Oct 2012 18:15:13 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-216.messagelabs.com!1350065712!33582997!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MzEzMTU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MzEzMTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22659 invoked from network); 12 Oct 2012 18:15:12 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Oct 2012 18:15:12 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHji0PEzM=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-090-010.pools.arcor-ip.net [88.65.90.10])
	by smtp.strato.de (jorabe mo41) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id i05eaeo9CHt7nu
	for ; Fri, 12 Oct 2012 20:15:11 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 2E4FB18642; Fri, 12 Oct 2012 20:15:11 +0200 (CEST)
Date: Fri, 12 Oct 2012 20:15:11 +0200
From: Olaf Hering 
To: xen-devel@lists.xen.org
Message-ID: <20121012181510.GA18284@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Subject: [Xen-devel] no xl monitor process with xl create -V
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


When I create a HVM guest with 'xl -v -v create -d -V -f cfg' there is
no xl process to monitor the guest. As a result a guest shutdown is not
handled. Without the -V option the xl process exists and after guest
shutdown the domain disappears.

Any idea how to fix this? Its with 4.2.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 18:15:40 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 18:15:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMjlT-0006KQ-B3; Fri, 12 Oct 2012 18:15:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMjlS-0006KL-Ek
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 18:15:14 +0000
Received: from [85.158.143.99:19008] by server-3.bemta-4.messagelabs.com id
	D8/A0-10075-13E58705; Fri, 12 Oct 2012 18:15:13 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-216.messagelabs.com!1350065712!33582997!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MzEzMTU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MzEzMTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22659 invoked from network); 12 Oct 2012 18:15:12 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Oct 2012 18:15:12 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHji0PEzM=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-090-010.pools.arcor-ip.net [88.65.90.10])
	by smtp.strato.de (jorabe mo41) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id i05eaeo9CHt7nu
	for ; Fri, 12 Oct 2012 20:15:11 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 2E4FB18642; Fri, 12 Oct 2012 20:15:11 +0200 (CEST)
Date: Fri, 12 Oct 2012 20:15:11 +0200
From: Olaf Hering 
To: xen-devel@lists.xen.org
Message-ID: <20121012181510.GA18284@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Subject: [Xen-devel] no xl monitor process with xl create -V
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


When I create a HVM guest with 'xl -v -v create -d -V -f cfg' there is
no xl process to monitor the guest. As a result a guest shutdown is not
handled. Without the -V option the xl process exists and after guest
shutdown the domain disappears.

Any idea how to fix this? Its with 4.2.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 18:41:51 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 18:41:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMkAl-0006Vb-JB; Fri, 12 Oct 2012 18:41:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMkAk-0006VW-7U
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 18:41:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1350067275!11146888!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQzMTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15206 invoked from network); 12 Oct 2012 18:41:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 18:41:15 -0000
X-IronPort-AV: E=Sophos;i="4.80,577,1344211200"; d="scan'208";a="15135894"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 18:41:15 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 12 Oct 2012 19:41:15 +0100
Message-ID: <1350067274.6952.117.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Olaf Hering 
Date: Fri, 12 Oct 2012 19:41:14 +0100
In-Reply-To: <20121012181510.GA18284@aepfle.de>
References: <20121012181510.GA18284@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] no xl monitor process with xl create -V
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-12 at 19:15 +0100, Olaf Hering wrote:
> When I create a HVM guest with 'xl -v -v create -d -V -f cfg' there is
> no xl process to monitor the guest. As a result a guest shutdown is not
> handled. Without the -V option the xl process exists and after guest
> shutdown the domain disappears.

Sounds like a bug in the implementation of -V to me.

> Any idea how to fix this? Its with 4.2.

Is it exiting deliberately or crashing? What do the logs say?

Ian



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 18:41:51 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 18:41:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMkAl-0006Vb-JB; Fri, 12 Oct 2012 18:41:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMkAk-0006VW-7U
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 18:41:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1350067275!11146888!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQzMTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15206 invoked from network); 12 Oct 2012 18:41:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 18:41:15 -0000
X-IronPort-AV: E=Sophos;i="4.80,577,1344211200"; d="scan'208";a="15135894"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Oct 2012 18:41:15 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 12 Oct 2012 19:41:15 +0100
Message-ID: <1350067274.6952.117.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Olaf Hering 
Date: Fri, 12 Oct 2012 19:41:14 +0100
In-Reply-To: <20121012181510.GA18284@aepfle.de>
References: <20121012181510.GA18284@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] no xl monitor process with xl create -V
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-12 at 19:15 +0100, Olaf Hering wrote:
> When I create a HVM guest with 'xl -v -v create -d -V -f cfg' there is
> no xl process to monitor the guest. As a result a guest shutdown is not
> handled. Without the -V option the xl process exists and after guest
> shutdown the domain disappears.

Sounds like a bug in the implementation of -V to me.

> Any idea how to fix this? Its with 4.2.

Is it exiting deliberately or crashing? What do the logs say?

Ian



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 18:50:15 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 18:50:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMkJ1-0006ex-Mn; Fri, 12 Oct 2012 18:49:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMkFx-0006dY-55
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 18:46:45 +0000
Received: from [85.158.139.211:24995] by server-2.bemta-5.messagelabs.com id
	60/E7-02746-49568705; Fri, 12 Oct 2012 18:46:44 +0000
X-Env-Sender: artnapor@yahoo.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1350067600!22126486!1
X-Originating-IP: [98.138.90.158]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_60_70, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_12, ML_RADAR_SPEW_LINKS_14,
	ML_RADAR_SPEW_LINKS_6,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25917 invoked from network); 12 Oct 2012 18:46:42 -0000
Received: from nm10-vm2.bullet.mail.ne1.yahoo.com (HELO
	nm10-vm2.bullet.mail.ne1.yahoo.com) (98.138.90.158)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Oct 2012 18:46:42 -0000
Received: from [98.138.90.57] by nm10.bullet.mail.ne1.yahoo.com with NNFMP;
	12 Oct 2012 18:46:40 -0000
Received: from [98.138.87.2] by tm10.bullet.mail.ne1.yahoo.com with NNFMP;
	12 Oct 2012 18:46:40 -0000
Received: from [127.0.0.1] by omp1002.mail.ne1.yahoo.com with NNFMP;
	12 Oct 2012 18:46:40 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 666499.11590.bm@omp1002.mail.ne1.yahoo.com
Received: (qmail 30466 invoked by uid 60001); 12 Oct 2012 18:46:40 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024;
	t=1350067600; bh=w3LSEv4TO7SJd+ZjNhywQkSq2qAwU54dHxt94BMDn9k=;
	h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type;
	b=c2x3LcaRibDX9d/PnKAkJs1loCKF9ruQiCP1VQsVnP2/AQVYdQ0FKfEE3XlizIlO2XuZ6G8hLNqQ4Jfe57iy09qtYIZhXyFEHxddW4jP1Rt0QbCgKpmDygbIb6f1R5W/5f5m2UlGmZ/VvWRhZ+GOew7sWK9VNfq8Wq8ZiG9MDsE=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type;
	b=K+nz3dxFza9H02kI3tCGD3m2lKeFgcu0JRTTs+pn5afpiBe5SPSpPjAt9FXxMmPLMXDkReyTxme3zXMqhCNgjD6vplfs37Wt7EjbCZv/bOfNSHAUvQmqIS9cxeTSTiygJ8kLqjiaMLPowGmf7uovBt1gJnXeDfmggAFDdeOd/Uo=;
X-YMail-OSG: I43GKzMVM1mVMahYvdggvAd5aTL4uoI.GEHsmdcxDOn7xIp
	LBgezTz1EXHh89U2uLa26Oue4TMLcayp3cWbrrIRYHoyDAQhgeO271dH_nWe
	F4By_1sMturwUqvZIFSZYF7HX67dXU9SIqs9X3qBRS1BospfjbPJEFcfKsSQ
	UbBh9K7DeL45oe5RUrPjlO.kpHGF0aGCMyTSY0UZ_NPDdizHSLP21QwBrBv.
	SSWL9GOmVbPaw4QcDeKg6vu17f7SYIZl04UguDEoBH9RqV4EcInBlDImI7Ac
	JARcvOfdZhMkMoA.fosD0kSC.85_aRtOTNcjqdQjIwfrieWJx_i_08UHcCdM
	SVyQT2.UumxgydrX8_REaRWDVExWSCo_P3Rhm1OKke.nWM66lFly2DLoDlhI
	FEeEgMrwBGl4bn1qMBCnvO_vjmw.C9ddv8NfRRnoLLfcQwjuWkaj2nmqUIT1
	9Yo4ZvotiEbjVu1J0NIsfcEnTQey5zqDZUzNjbvmikxdP6zVY.GHihzVVE7g
	KfP05tcQ-
Received: from [50.58.96.2] by web121005.mail.ne1.yahoo.com via HTTP;
	Fri, 12 Oct 2012 11:46:40 PDT
X-Rocket-MIMEInfo: 001.001,
	U2FtcGxlIGNvZGUgd291bGQgYmUgZ3JlYXQgaWYgaXQgY2FuIGJlIGZvcndhcmRlZCB0byB0aGUgbGlzdC4gCgpUaGFua3MKQXJ0CgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwogRnJvbTogUm9zcyBQaGlsaXBzb24gPFJvc3MuUGhpbGlwc29uQGNpdHJpeC5jb20.ClRvOiBBcnQgTmFwb3IgPGFydG5hcG9yQHlhaG9vLmNvbT47ICJ4ZW4tZGV2ZWxAbGlzdHMueGVuLm9yZyIgPHhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnPiAKU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDEwLCAyMDEyIDExOjABMAEBAQE-
X-Mailer: YahooMailWebService/0.8.123.450
References: <1346343064.91089.YahooMailNeo@web121001.mail.ne1.yahoo.com>
	<831D55AF5A11D64C9B4B43F59EEBF720A31BCC42AB@FTLPMAILBOX02.citrite.net>
	<1346437375.61994.YahooMailNeo@web121001.mail.ne1.yahoo.com>
	<831D55AF5A11D64C9B4B43F59EEBF720A31BCC442E@FTLPMAILBOX02.citrite.net>
	<1349805295.77475.YahooMailNeo@web121002.mail.ne1.yahoo.com>
	<831D55AF5A11D64C9B4B43F59EEBF720A31C4E5D51@FTLPMAILBOX02.citrite.net>
	<1349812653.76722.YahooMailNeo@web121001.mail.ne1.yahoo.com>
	<831D55AF5A11D64C9B4B43F59EEBF720A31C6A4C96@FTLPMAILBOX02.citrite.net>
Message-ID: <1350067600.22418.YahooMailNeo@web121005.mail.ne1.yahoo.com>
Date: Fri, 12 Oct 2012 11:46:40 -0700 (PDT)
From: Art Napor 
To: Ross Philipson ,
	"xen-devel@lists.xen.org" 
In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720A31C6A4C96@FTLPMAILBOX02.citrite.net>
MIME-Version: 1.0
X-Mailman-Approved-At: Fri, 12 Oct 2012 18:49:54 +0000
Subject: Re: [Xen-devel] [PATCH v3 01/04] HVM firmware passthrough HVM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Art Napor 
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============7771013552937689304=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7771013552937689304==
Content-Type: multipart/alternative; boundary="-406315465-933205781-1350067600=:22418"

---406315465-933205781-1350067600=:22418
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Sample code would be great if it can be forwarded to the list. =0A=0AThanks=
=0AArt=0A=0A=0A=0A=0A________________________________=0A From: Ross Philips=
on =0ATo: Art Napor ; "xen-d=
evel@lists.xen.org"  =0ASent: Wednesday, October 1=
0, 2012 11:00 AM=0ASubject: RE: [Xen-devel]  [PATCH v3 01/04] HVM firmware =
passthrough HVM=0A =0A=0AIt looks like this thread fell off the xen-devel l=
ist =E2=80=93 putting it back. I am not sure what you mean by hard-coded. N=
ewer kernels expose the DMI/SMBIOS information in sysfs. I could send out s=
ome sample code that does this.=0A=C2=A0=0AGeneral question for xen-devel: =
Is it ok to forward sample code to the list? I am not sure what the rules o=
f engagement are concerning that.=0A=C2=A0=0AThanks=0ARoss=0A=C2=A0=0AFrom:=
Art Napor [mailto:artnapor@yahoo.com] =0ASent: Tuesday, October 09, 2012 3:=
58 PM=0ATo: Ross Philipson=0ASubject: Re: [Xen-devel] [PATCH v3 01/04] HVM =
firmware passthrough HVM=0A=C2=A0=0ARoss,=0A=C2=A0=0AI wish I could say yes=
. I think I see where these are intended to be loaded in from the fourth pa=
tch in the v3 series. I guess I'm not clear on how the tool stack would rea=
d these in. Would these values be hard coded in from /sysfs or could these =
be configured in xen.cfg or other arguments passed in? =0A=C2=A0=0A=C2=A0=
=0A+#define HVM_XS_HVMLOADER=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "hvmloader"=0A+#define HVM_XS_BIOS=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "hvmloader/bios"=0A+#define HVM_XS_=
GENERATION_ID_ADDRESS=C2=A0=C2=A0 "hvmloader/generation-id-address"=0A+=0A+=
/* The following values allow additional ACPI tables to be added to the=0A+=
 * virtual ACPI BIOS that hvmloader constructs. The values specify the gues=
t=0A+ * physical address and length of a block of ACPI tables to add. The f=
ormat of=0A+ * the block is simply concatenated raw tables (which specify t=
heir own length=0A+ * in the ACPI header).=0A+ */=0A+#define HVM_XS_ACPI_PT=
_ADDRESS=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "hvmloader/acpi/ad=
dress"=0A+#define HVM_XS_ACPI_PT_LENGTH=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 "hvmloader/acpi/length"=0A+=0A+/* Any number of SMBIOS t=
ypes can be passed through to an HVM guest using=0A+ * the following xensto=
re values. The values specify the guest physical=0A+ * address and length o=
f a block of SMBIOS structures for hvmloader to use.=0A+ * The block is for=
matted in the following way:=0A+ *=0A+ * ..=
.=0A+ *=0A+ * Each length separator is a 32b integer indicating the length =
of the next=0A+ * SMBIOS structure. For DMTF defined types (0 - 121), the p=
assed in struct=0A+ * will replace the default structure in hvmloader. In a=
ddition, any=0A+ * OEM/vendortypes (128 - 255) will all be added.=0A+ */=0A=
+#define HVM_XS_SMBIOS_PT_ADDRESS=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "hvml=
oader/smbios/address"=0A+#define HVM_XS_SMBIOS_PT_LENGTH=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 "hvmloader/smbios/length"=0A+=0A+/* Set to 1 to en=
able SMBIOS default portable battery (type 22) values. */=0A+#define HVM_XS=
_SMBIOS_DEFAULT_BATTERY=C2=A0 "hvmloader/smbios/default_battery"=0A+=0A+/* =
The following xenstore values are used to override some of the default=0A+ =
* string values in the SMBIOS table constructed in hvmloader.=0A+ */=0A+#de=
fine HVM_XS_BIOS_STRINGS=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 "bios-strings"=0A+#define HVM_XS_BIOS_VENDOR=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "bios-strings/bio=
s-vendor"=0A+#define HVM_XS_BIOS_VERSION=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "bios-strings/bios-version"=0A+#define HV=
M_XS_SYSTEM_MANUFACTURER=C2=A0=C2=A0=C2=A0=C2=A0 "bios-strings/system-manuf=
acturer"=0A+#define HVM_XS_SYSTEM_PRODUCT_NAME=C2=A0=C2=A0=C2=A0=C2=A0 "bio=
s-strings/system-product-name"=0A+#define HVM_XS_SYSTEM_VERSION=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "bios-strings/system-version"=0A=
+#define HVM_XS_SYSTEM_SERIAL_NUMBER=C2=A0=C2=A0=C2=A0 "bios-strings/system=
-serial-number"=0A+#define HVM_XS_ENCLOSURE_MANUFACTURER=C2=A0 "bios-string=
s/enclosure-manufacturer"=0A+#define HVM_XS_ENCLOSURE_SERIAL_NUMBER "bios-s=
trings/enclosure-serial-number"=0A+#define HVM_XS_BATTERY_MANUFACTURER=C2=
=A0=C2=A0=C2=A0 "bios-strings/battery-manufacturer"=0A+#define HVM_XS_BATTE=
RY_DEVICE_NAME=C2=A0=C2=A0=C2=A0=C2=A0 "bios-strings/battery-device-name"=
=0A+=0A+/* Up to 100 OEM strings can be set in xenstore using values of the=
 form=0A=C2=A0=0A=0A________________________________=0A=0AFrom:Ross Philips=
on =0ATo: Art Napor  =0ASent=
: Tuesday, October 9, 2012 2:06 PM=0ASubject: RE: [Xen-devel] [PATCH v3 01/=
04] HVM firmware passthrough HVM=0A=C2=A0=0AHi,=0A=C2=A0=0ASo the patches t=
o xen are only part of what you need to make it all work. Something in your=
 toolstack needs to load the tables you want into the new guest. There was =
no really good place to do this in the xen tools so I did not push. I am gu=
essing e.g. somewhere in you dom0 tools, you would call dmidecode or read t=
he tables from sysfs, form the set of tables for the guest that you want an=
d pass them in to the libxc domain creator function. Does that make sense?=
=0A=C2=A0=0AThanks=0ARoss=0A=C2=A0=0AFrom:Art Napor [mailto:artnapor@yahoo.=
com] =0ASent: Tuesday, October 09, 2012 1:55 PM=0ATo: Ross Philipson=0ASubj=
ect: Re: [Xen-devel] [PATCH v3 01/04] HVM firmware passthrough HVM=0A=C2=A0=
=0ARoss,=0A=C2=A0=0AThanks again for the information. I was able to apply t=
he SMBIOS patch series cleanly to 4.1.2 and v3 of your later patch series t=
o 4.2 and 4.3 testing. Is there an option or flag that needs to be set to e=
nable the HVM passthrough? I believe the patches applied cleanly - I didn't=
 notice any rejects. I have smbios loaded in the Dom0 /sys/firmware/smbios =
and /sys/class/dmi/. A Centos 5 DomU with the patched Xen 4.2/4.3 appears t=
o still report the standard Xen bios information via dmidecode. =0A=C2=A0=
=0A=C2=A0=0A=0A________________________________=0A=0AFrom:Ross Philipson =0ATo: Art Napor ; "xen-devel@=
lists.xen.org"  =0ASent: Friday, August 31, 2012 4=
:36 PM=0ASubject: RE: [Xen-devel] [PATCH v3 01/04] HVM firmware passthrough=
 HVM=0A=0A> I also came across the earlier smbios passthrough patch series.=
 I'm looking to be able to pass the DMI block from the Dom0 to the DomU whe=
n. Your earlier smbios patch series applied cleanly built against to 4.1.2,=
 but the Dom0 smbios data didn't seem to make it into the HVM DomU. =0A=0A>=
 Are there any version or other changset limitations that would prevent the=
 patches from being manually applied to 4.1? =0A=0A> http://lists.xen.org/a=
rchives/html/xen-devel/2012-02/msg01754.html=0A=0AWell there were some tool=
 stack changes (in libxl) that happened right around the time I was making =
the patches so I had to change things to match that. So in an older branch =
you might have to change the way the BIOS blobs get sent in to the domain b=
uilding code.=0A=0AThe rest of the code to load the BIOS bits into the new =
guests memory and the changes to hvmloader to process them should apply cle=
anly I think.=0A=0ANote that the last patch set for this (v3) does support =
passing in both SMBIOS structures and ACPI tables so you can use that patch=
 set.=0A=0AThanks=0ARoss
---406315465-933205781-1350067600=:22418
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Sample code would be =
great if it can be forwarded to the list. 

Thanks
Art


  
 
 
  
  From: Ross Philipson <Ross.Philipson@citrix.c=
om>
 To: Art Napor &=
lt;artnapor@yahoo.com>; "xen-devel@lists.xen.org" <xen-devel@lists.xe=
n.org> 
 Sent: Wedne=
sday, October 10, 2012 11:00 AM
 S=
ubject: RE: [Xen-devel]  [PATCH v3 01/04] HVM firmware passthrou=
gh HVM

  
 
=0A
It looks like this thread fell =
off the xen-devel list =E2=80=93 putting it back. I am not sure what you me=
an by hard-coded. Newer kernels expose the DMI/SMBIOS information in sysfs.=
 I could send out some sample code that does this.
  
General question for xen-devel: Is it ok to forward sample code to the lis=
t? I am not sure what the rules of engagement are concerning that.
  
Thanks
Ross
  
From: Art =
Napor [mailto:artnapor@yahoo.com] 
Sent: Tuesday, October 09, 201=
2 3:58 PM
To: Ross Philipson
Subject: Re: [Xen-devel] [=
PATCH v3 01/04] HVM firmware passthrough HVM
  
Ross,
  
I wish I could say yes. I think I see where these are=
 intended to be loaded in from the fourth patch in the v3 series. I guess I=
'm not clear on how the tool stack would read these in. Would these values =
be hard coded in from /sysfs or could these be configured in xen.cfg or oth=
er arguments passed in? 
  
  
+#define HVM_XS_HVMLOADER       &nb=
sp;       "hvmloader"
+#define HVM_XS_BIOS=
            &nb=
sp;       "hvmloader/bios"
+#define HVM_XS=
_GENERATION_ID_ADDRESS   "hvmloader/generation-id-address"
++/* The following values allow additional ACPI tables to be added to the<=
br>+ * virtual ACPI BIOS that hvmloader constructs. The values specify the =
guest
+ * physical address and length of a block of ACPI tables to add. =
The format of
+ * the block is simply concatenated raw tables (which spe=
cify their own length
+ * in the ACPI header).
+ */
+#define HVM_X=
S_ACPI_PT_ADDRESS         "hvmloade=
r/acpi/address"
+#define
 HVM_XS_ACPI_PT_LENGTH         =
; "hvmloader/acpi/length"
+
+/* Any number of SMBIOS types can be pas=
sed through to an HVM guest using
+ * the following xenstore values. The=
 values specify the guest physical
+ * address and length of a block of =
SMBIOS structures for hvmloader to use.
+ * The block is formatted in th=
e following way:
+ *
+ * <length><struct><length>&l=
t;struct>...
+ *
+ * Each length separator is a 32b integer indica=
ting the length of the next
+ * SMBIOS structure. For DMTF defined types=
 (0 - 121), the passed in struct
+ * will replace the default structure =
in hvmloader. In addition, any
+ * OEM/vendortypes (128 - 255) will all =
be added.
+ */
+#define HVM_XS_SMBIOS_PT_ADDRESS   &nb=
sp;   "hvmloader/smbios/address"
+#define HVM_XS_SMBIOS_PT_LEN=
GTH       
 "hvmloader/smbios/length"
+
+/* Set to 1 to enable SMBIOS default po=
rtable battery (type 22) values. */
+#define HVM_XS_SMBIOS_DEFAULT_BATTE=
RY  "hvmloader/smbios/default_battery"
+
+/* The following xenst=
ore values are used to override some of the default
+ * string values in=
 the SMBIOS table constructed in hvmloader.
+ */
+#define HVM_XS_BIOS=
_STRINGS            =
"bios-strings"
+#define HVM_XS_BIOS_VENDOR     =
        "bios-strings/bios-vendor"
+#=
define HVM_XS_BIOS_VERSION        &=
nbsp;   "bios-strings/bios-version"
+#define HVM_XS_SYSTEM_MAN=
UFACTURER     "bios-strings/system-manufacturer"
+#d=
efine HVM_XS_SYSTEM_PRODUCT_NAME     "bios-strings/syst=
em-product-name"
+#define
 HVM_XS_SYSTEM_VERSION         =
; "bios-strings/system-version"
+#define HVM_XS_SYSTEM_SERIAL_NUMBER&nbs=
p;   "bios-strings/system-serial-number"
+#define HVM_XS_ENCLO=
SURE_MANUFACTURER  "bios-strings/enclosure-manufacturer"
+#define H=
VM_XS_ENCLOSURE_SERIAL_NUMBER "bios-strings/enclosure-serial-number"
+#d=
efine HVM_XS_BATTERY_MANUFACTURER    "bios-strings/battery-m=
anufacturer"
+#define HVM_XS_BATTERY_DEVICE_NAME    =
 "bios-strings/battery-device-name"
+
+/* Up to 100 OEM strings can b=
e set in xenstore using values of the form
  
From: Ross Philipson <Ross.Philipson@citrix.com>
To: Art=
 Napor <artnapor@yahoo.com> 
Sent: Tuesday, October 9, 2012=
 2:06 PM
Subject: RE: [Xen-devel] [PATCH v3 01/04] HVM firmware p=
assthrough HVM
  
=

Hi=
,
 
So the patches to xen are only part of w=
hat you need to make it all work. Something in your toolstack needs to load=
 the tables you want into the new guest. There was no really good place to =
do this in the xen tools so I did not push. I am guessing e.g. somewhere in=
 you dom0 tools, you would call dmidecode or read the tables from sysfs, fo=
rm the set of tables for the guest that you want and pass them in to the li=
bxc domain creator function. Does that make sense?
 
Thanks
<=
/div>
Ross
&nbs=
p;
From: Art Napor [mailt=
o:artnapor@yahoo.com] 
Sent: Tuesday, October 09, 2012 1:55 PMTo: Ross Philipson
Subject: Re: [Xen-devel] [PATCH v3 01/=
04] HVM firmware passthrough HVM=

 
<=
div>
Ross,
 
Thanks again for the information. I was able to apply the SMBIOS patch=
 series cleanly to 4.1.2 and v3 of your later patch series to 4.2 and 4.3 t=
esting. Is there an option or flag that needs to be set to enable the HVM p=
assthrough? I believe the patches applied cleanly - I didn't notice any rej=
ects. I have smbios loaded in the Dom0 /sys/firmware/smbios and /sys/class/=
dmi/. A Centos 5 DomU with the patched Xen 4.2/4.3 appears to still report =
the standard Xen bios information via dmidecode. 
 
<=
div>
 
<=
div>
From: Ross Phili=
pson <Ross.Philipson@citrix.com>
To: Art Napor <artnapor=
@yahoo.com>; "xen-devel@lists.xen.org" <xen-devel@lists.xen.org> <=
br>Sent: Friday, August 31, 2012 4:36 PM
Subject: RE: [Xen=
-devel] [PATCH v3 01/04]
 HVM firmware passthrough HVM

> I also came across the earlier smbios passthroug=
h patch series. I'm looking to be able to pass the DMI block from the Dom0 =
to the DomU when. Your earlier smbios patch series applied cleanly built ag=
ainst to 4.1.2, but the Dom0 smbios data didn't seem to make it into the HV=
M DomU. 

> Are there any version or other changset limitations th=
at would prevent the patches from being manually applied to 4.1? 

&g=
t; http://lists.xen.org/archives/htm=
l/xen-devel/2012-02/msg01754.html

Well there were some tool stac=
k changes (in libxl) that happened right around the time I was making the p=
atches so
 I had to change things to match that. So in an older branch you might have=
 to change the way the BIOS blobs get sent in to the domain building code.<=
br>
The rest of the code to load the BIOS bits into the new guests memor=
y and the changes to hvmloader to process them should apply cleanly I think=
.

Note that the last patch set for this (v3) does support passing in=
 both SMBIOS structures and ACPI tables so you can use that patch set.
<=
br>Thanks
Ross


  


 
 
  

---406315465-933205781-1350067600=:22418--


--===============7771013552937689304==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7771013552937689304==--


From xen-devel-bounces@lists.xen.org Fri Oct 12 18:50:15 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 18:50:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMkJ1-0006ex-Mn; Fri, 12 Oct 2012 18:49:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMkFx-0006dY-55
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 18:46:45 +0000
Received: from [85.158.139.211:24995] by server-2.bemta-5.messagelabs.com id
	60/E7-02746-49568705; Fri, 12 Oct 2012 18:46:44 +0000
X-Env-Sender: artnapor@yahoo.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1350067600!22126486!1
X-Originating-IP: [98.138.90.158]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_60_70, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_12, ML_RADAR_SPEW_LINKS_14,
	ML_RADAR_SPEW_LINKS_6,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25917 invoked from network); 12 Oct 2012 18:46:42 -0000
Received: from nm10-vm2.bullet.mail.ne1.yahoo.com (HELO
	nm10-vm2.bullet.mail.ne1.yahoo.com) (98.138.90.158)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Oct 2012 18:46:42 -0000
Received: from [98.138.90.57] by nm10.bullet.mail.ne1.yahoo.com with NNFMP;
	12 Oct 2012 18:46:40 -0000
Received: from [98.138.87.2] by tm10.bullet.mail.ne1.yahoo.com with NNFMP;
	12 Oct 2012 18:46:40 -0000
Received: from [127.0.0.1] by omp1002.mail.ne1.yahoo.com with NNFMP;
	12 Oct 2012 18:46:40 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 666499.11590.bm@omp1002.mail.ne1.yahoo.com
Received: (qmail 30466 invoked by uid 60001); 12 Oct 2012 18:46:40 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024;
	t=1350067600; bh=w3LSEv4TO7SJd+ZjNhywQkSq2qAwU54dHxt94BMDn9k=;
	h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type;
	b=c2x3LcaRibDX9d/PnKAkJs1loCKF9ruQiCP1VQsVnP2/AQVYdQ0FKfEE3XlizIlO2XuZ6G8hLNqQ4Jfe57iy09qtYIZhXyFEHxddW4jP1Rt0QbCgKpmDygbIb6f1R5W/5f5m2UlGmZ/VvWRhZ+GOew7sWK9VNfq8Wq8ZiG9MDsE=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type;
	b=K+nz3dxFza9H02kI3tCGD3m2lKeFgcu0JRTTs+pn5afpiBe5SPSpPjAt9FXxMmPLMXDkReyTxme3zXMqhCNgjD6vplfs37Wt7EjbCZv/bOfNSHAUvQmqIS9cxeTSTiygJ8kLqjiaMLPowGmf7uovBt1gJnXeDfmggAFDdeOd/Uo=;
X-YMail-OSG: I43GKzMVM1mVMahYvdggvAd5aTL4uoI.GEHsmdcxDOn7xIp
	LBgezTz1EXHh89U2uLa26Oue4TMLcayp3cWbrrIRYHoyDAQhgeO271dH_nWe
	F4By_1sMturwUqvZIFSZYF7HX67dXU9SIqs9X3qBRS1BospfjbPJEFcfKsSQ
	UbBh9K7DeL45oe5RUrPjlO.kpHGF0aGCMyTSY0UZ_NPDdizHSLP21QwBrBv.
	SSWL9GOmVbPaw4QcDeKg6vu17f7SYIZl04UguDEoBH9RqV4EcInBlDImI7Ac
	JARcvOfdZhMkMoA.fosD0kSC.85_aRtOTNcjqdQjIwfrieWJx_i_08UHcCdM
	SVyQT2.UumxgydrX8_REaRWDVExWSCo_P3Rhm1OKke.nWM66lFly2DLoDlhI
	FEeEgMrwBGl4bn1qMBCnvO_vjmw.C9ddv8NfRRnoLLfcQwjuWkaj2nmqUIT1
	9Yo4ZvotiEbjVu1J0NIsfcEnTQey5zqDZUzNjbvmikxdP6zVY.GHihzVVE7g
	KfP05tcQ-
Received: from [50.58.96.2] by web121005.mail.ne1.yahoo.com via HTTP;
	Fri, 12 Oct 2012 11:46:40 PDT
X-Rocket-MIMEInfo: 001.001,
	U2FtcGxlIGNvZGUgd291bGQgYmUgZ3JlYXQgaWYgaXQgY2FuIGJlIGZvcndhcmRlZCB0byB0aGUgbGlzdC4gCgpUaGFua3MKQXJ0CgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwogRnJvbTogUm9zcyBQaGlsaXBzb24gPFJvc3MuUGhpbGlwc29uQGNpdHJpeC5jb20.ClRvOiBBcnQgTmFwb3IgPGFydG5hcG9yQHlhaG9vLmNvbT47ICJ4ZW4tZGV2ZWxAbGlzdHMueGVuLm9yZyIgPHhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnPiAKU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDEwLCAyMDEyIDExOjABMAEBAQE-
X-Mailer: YahooMailWebService/0.8.123.450
References: <1346343064.91089.YahooMailNeo@web121001.mail.ne1.yahoo.com>
	<831D55AF5A11D64C9B4B43F59EEBF720A31BCC42AB@FTLPMAILBOX02.citrite.net>
	<1346437375.61994.YahooMailNeo@web121001.mail.ne1.yahoo.com>
	<831D55AF5A11D64C9B4B43F59EEBF720A31BCC442E@FTLPMAILBOX02.citrite.net>
	<1349805295.77475.YahooMailNeo@web121002.mail.ne1.yahoo.com>
	<831D55AF5A11D64C9B4B43F59EEBF720A31C4E5D51@FTLPMAILBOX02.citrite.net>
	<1349812653.76722.YahooMailNeo@web121001.mail.ne1.yahoo.com>
	<831D55AF5A11D64C9B4B43F59EEBF720A31C6A4C96@FTLPMAILBOX02.citrite.net>
Message-ID: <1350067600.22418.YahooMailNeo@web121005.mail.ne1.yahoo.com>
Date: Fri, 12 Oct 2012 11:46:40 -0700 (PDT)
From: Art Napor 
To: Ross Philipson ,
	"xen-devel@lists.xen.org" 
In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720A31C6A4C96@FTLPMAILBOX02.citrite.net>
MIME-Version: 1.0
X-Mailman-Approved-At: Fri, 12 Oct 2012 18:49:54 +0000
Subject: Re: [Xen-devel] [PATCH v3 01/04] HVM firmware passthrough HVM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Art Napor 
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============7771013552937689304=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7771013552937689304==
Content-Type: multipart/alternative; boundary="-406315465-933205781-1350067600=:22418"

---406315465-933205781-1350067600=:22418
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Sample code would be great if it can be forwarded to the list. =0A=0AThanks=
=0AArt=0A=0A=0A=0A=0A________________________________=0A From: Ross Philips=
on =0ATo: Art Napor ; "xen-d=
evel@lists.xen.org"  =0ASent: Wednesday, October 1=
0, 2012 11:00 AM=0ASubject: RE: [Xen-devel]  [PATCH v3 01/04] HVM firmware =
passthrough HVM=0A =0A=0AIt looks like this thread fell off the xen-devel l=
ist =E2=80=93 putting it back. I am not sure what you mean by hard-coded. N=
ewer kernels expose the DMI/SMBIOS information in sysfs. I could send out s=
ome sample code that does this.=0A=C2=A0=0AGeneral question for xen-devel: =
Is it ok to forward sample code to the list? I am not sure what the rules o=
f engagement are concerning that.=0A=C2=A0=0AThanks=0ARoss=0A=C2=A0=0AFrom:=
Art Napor [mailto:artnapor@yahoo.com] =0ASent: Tuesday, October 09, 2012 3:=
58 PM=0ATo: Ross Philipson=0ASubject: Re: [Xen-devel] [PATCH v3 01/04] HVM =
firmware passthrough HVM=0A=C2=A0=0ARoss,=0A=C2=A0=0AI wish I could say yes=
. I think I see where these are intended to be loaded in from the fourth pa=
tch in the v3 series. I guess I'm not clear on how the tool stack would rea=
d these in. Would these values be hard coded in from /sysfs or could these =
be configured in xen.cfg or other arguments passed in? =0A=C2=A0=0A=C2=A0=
=0A+#define HVM_XS_HVMLOADER=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "hvmloader"=0A+#define HVM_XS_BIOS=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "hvmloader/bios"=0A+#define HVM_XS_=
GENERATION_ID_ADDRESS=C2=A0=C2=A0 "hvmloader/generation-id-address"=0A+=0A+=
/* The following values allow additional ACPI tables to be added to the=0A+=
 * virtual ACPI BIOS that hvmloader constructs. The values specify the gues=
t=0A+ * physical address and length of a block of ACPI tables to add. The f=
ormat of=0A+ * the block is simply concatenated raw tables (which specify t=
heir own length=0A+ * in the ACPI header).=0A+ */=0A+#define HVM_XS_ACPI_PT=
_ADDRESS=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "hvmloader/acpi/ad=
dress"=0A+#define HVM_XS_ACPI_PT_LENGTH=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 "hvmloader/acpi/length"=0A+=0A+/* Any number of SMBIOS t=
ypes can be passed through to an HVM guest using=0A+ * the following xensto=
re values. The values specify the guest physical=0A+ * address and length o=
f a block of SMBIOS structures for hvmloader to use.=0A+ * The block is for=
matted in the following way:=0A+ *=0A+ * ..=
.=0A+ *=0A+ * Each length separator is a 32b integer indicating the length =
of the next=0A+ * SMBIOS structure. For DMTF defined types (0 - 121), the p=
assed in struct=0A+ * will replace the default structure in hvmloader. In a=
ddition, any=0A+ * OEM/vendortypes (128 - 255) will all be added.=0A+ */=0A=
+#define HVM_XS_SMBIOS_PT_ADDRESS=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "hvml=
oader/smbios/address"=0A+#define HVM_XS_SMBIOS_PT_LENGTH=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 "hvmloader/smbios/length"=0A+=0A+/* Set to 1 to en=
able SMBIOS default portable battery (type 22) values. */=0A+#define HVM_XS=
_SMBIOS_DEFAULT_BATTERY=C2=A0 "hvmloader/smbios/default_battery"=0A+=0A+/* =
The following xenstore values are used to override some of the default=0A+ =
* string values in the SMBIOS table constructed in hvmloader.=0A+ */=0A+#de=
fine HVM_XS_BIOS_STRINGS=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 "bios-strings"=0A+#define HVM_XS_BIOS_VENDOR=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "bios-strings/bio=
s-vendor"=0A+#define HVM_XS_BIOS_VERSION=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "bios-strings/bios-version"=0A+#define HV=
M_XS_SYSTEM_MANUFACTURER=C2=A0=C2=A0=C2=A0=C2=A0 "bios-strings/system-manuf=
acturer"=0A+#define HVM_XS_SYSTEM_PRODUCT_NAME=C2=A0=C2=A0=C2=A0=C2=A0 "bio=
s-strings/system-product-name"=0A+#define HVM_XS_SYSTEM_VERSION=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "bios-strings/system-version"=0A=
+#define HVM_XS_SYSTEM_SERIAL_NUMBER=C2=A0=C2=A0=C2=A0 "bios-strings/system=
-serial-number"=0A+#define HVM_XS_ENCLOSURE_MANUFACTURER=C2=A0 "bios-string=
s/enclosure-manufacturer"=0A+#define HVM_XS_ENCLOSURE_SERIAL_NUMBER "bios-s=
trings/enclosure-serial-number"=0A+#define HVM_XS_BATTERY_MANUFACTURER=C2=
=A0=C2=A0=C2=A0 "bios-strings/battery-manufacturer"=0A+#define HVM_XS_BATTE=
RY_DEVICE_NAME=C2=A0=C2=A0=C2=A0=C2=A0 "bios-strings/battery-device-name"=
=0A+=0A+/* Up to 100 OEM strings can be set in xenstore using values of the=
 form=0A=C2=A0=0A=0A________________________________=0A=0AFrom:Ross Philips=
on =0ATo: Art Napor  =0ASent=
: Tuesday, October 9, 2012 2:06 PM=0ASubject: RE: [Xen-devel] [PATCH v3 01/=
04] HVM firmware passthrough HVM=0A=C2=A0=0AHi,=0A=C2=A0=0ASo the patches t=
o xen are only part of what you need to make it all work. Something in your=
 toolstack needs to load the tables you want into the new guest. There was =
no really good place to do this in the xen tools so I did not push. I am gu=
essing e.g. somewhere in you dom0 tools, you would call dmidecode or read t=
he tables from sysfs, form the set of tables for the guest that you want an=
d pass them in to the libxc domain creator function. Does that make sense?=
=0A=C2=A0=0AThanks=0ARoss=0A=C2=A0=0AFrom:Art Napor [mailto:artnapor@yahoo.=
com] =0ASent: Tuesday, October 09, 2012 1:55 PM=0ATo: Ross Philipson=0ASubj=
ect: Re: [Xen-devel] [PATCH v3 01/04] HVM firmware passthrough HVM=0A=C2=A0=
=0ARoss,=0A=C2=A0=0AThanks again for the information. I was able to apply t=
he SMBIOS patch series cleanly to 4.1.2 and v3 of your later patch series t=
o 4.2 and 4.3 testing. Is there an option or flag that needs to be set to e=
nable the HVM passthrough? I believe the patches applied cleanly - I didn't=
 notice any rejects. I have smbios loaded in the Dom0 /sys/firmware/smbios =
and /sys/class/dmi/. A Centos 5 DomU with the patched Xen 4.2/4.3 appears t=
o still report the standard Xen bios information via dmidecode. =0A=C2=A0=
=0A=C2=A0=0A=0A________________________________=0A=0AFrom:Ross Philipson =0ATo: Art Napor ; "xen-devel@=
lists.xen.org"  =0ASent: Friday, August 31, 2012 4=
:36 PM=0ASubject: RE: [Xen-devel] [PATCH v3 01/04] HVM firmware passthrough=
 HVM=0A=0A> I also came across the earlier smbios passthrough patch series.=
 I'm looking to be able to pass the DMI block from the Dom0 to the DomU whe=
n. Your earlier smbios patch series applied cleanly built against to 4.1.2,=
 but the Dom0 smbios data didn't seem to make it into the HVM DomU. =0A=0A>=
 Are there any version or other changset limitations that would prevent the=
 patches from being manually applied to 4.1? =0A=0A> http://lists.xen.org/a=
rchives/html/xen-devel/2012-02/msg01754.html=0A=0AWell there were some tool=
 stack changes (in libxl) that happened right around the time I was making =
the patches so I had to change things to match that. So in an older branch =
you might have to change the way the BIOS blobs get sent in to the domain b=
uilding code.=0A=0AThe rest of the code to load the BIOS bits into the new =
guests memory and the changes to hvmloader to process them should apply cle=
anly I think.=0A=0ANote that the last patch set for this (v3) does support =
passing in both SMBIOS structures and ACPI tables so you can use that patch=
 set.=0A=0AThanks=0ARoss
---406315465-933205781-1350067600=:22418
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Sample code would be =
great if it can be forwarded to the list. 

Thanks
Art


  
 
 
  
  From: Ross Philipson <Ross.Philipson@citrix.c=
om>
 To: Art Napor &=
lt;artnapor@yahoo.com>; "xen-devel@lists.xen.org" <xen-devel@lists.xe=
n.org> 
 Sent: Wedne=
sday, October 10, 2012 11:00 AM
 S=
ubject: RE: [Xen-devel]  [PATCH v3 01/04] HVM firmware passthrou=
gh HVM

  
 
=0A
It looks like this thread fell =
off the xen-devel list =E2=80=93 putting it back. I am not sure what you me=
an by hard-coded. Newer kernels expose the DMI/SMBIOS information in sysfs.=
 I could send out some sample code that does this.
  
General question for xen-devel: Is it ok to forward sample code to the lis=
t? I am not sure what the rules of engagement are concerning that.
  
Thanks
Ross
  
From: Art =
Napor [mailto:artnapor@yahoo.com] 
Sent: Tuesday, October 09, 201=
2 3:58 PM
To: Ross Philipson
Subject: Re: [Xen-devel] [=
PATCH v3 01/04] HVM firmware passthrough HVM
  
Ross,
  
I wish I could say yes. I think I see where these are=
 intended to be loaded in from the fourth patch in the v3 series. I guess I=
'm not clear on how the tool stack would read these in. Would these values =
be hard coded in from /sysfs or could these be configured in xen.cfg or oth=
er arguments passed in? 
  
  
+#define HVM_XS_HVMLOADER       &nb=
sp;       "hvmloader"
+#define HVM_XS_BIOS=
            &nb=
sp;       "hvmloader/bios"
+#define HVM_XS=
_GENERATION_ID_ADDRESS   "hvmloader/generation-id-address"
++/* The following values allow additional ACPI tables to be added to the<=
br>+ * virtual ACPI BIOS that hvmloader constructs. The values specify the =
guest
+ * physical address and length of a block of ACPI tables to add. =
The format of
+ * the block is simply concatenated raw tables (which spe=
cify their own length
+ * in the ACPI header).
+ */
+#define HVM_X=
S_ACPI_PT_ADDRESS         "hvmloade=
r/acpi/address"
+#define
 HVM_XS_ACPI_PT_LENGTH         =
; "hvmloader/acpi/length"
+
+/* Any number of SMBIOS types can be pas=
sed through to an HVM guest using
+ * the following xenstore values. The=
 values specify the guest physical
+ * address and length of a block of =
SMBIOS structures for hvmloader to use.
+ * The block is formatted in th=
e following way:
+ *
+ * <length><struct><length>&l=
t;struct>...
+ *
+ * Each length separator is a 32b integer indica=
ting the length of the next
+ * SMBIOS structure. For DMTF defined types=
 (0 - 121), the passed in struct
+ * will replace the default structure =
in hvmloader. In addition, any
+ * OEM/vendortypes (128 - 255) will all =
be added.
+ */
+#define HVM_XS_SMBIOS_PT_ADDRESS   &nb=
sp;   "hvmloader/smbios/address"
+#define HVM_XS_SMBIOS_PT_LEN=
GTH       
 "hvmloader/smbios/length"
+
+/* Set to 1 to enable SMBIOS default po=
rtable battery (type 22) values. */
+#define HVM_XS_SMBIOS_DEFAULT_BATTE=
RY  "hvmloader/smbios/default_battery"
+
+/* The following xenst=
ore values are used to override some of the default
+ * string values in=
 the SMBIOS table constructed in hvmloader.
+ */
+#define HVM_XS_BIOS=
_STRINGS            =
"bios-strings"
+#define HVM_XS_BIOS_VENDOR     =
        "bios-strings/bios-vendor"
+#=
define HVM_XS_BIOS_VERSION        &=
nbsp;   "bios-strings/bios-version"
+#define HVM_XS_SYSTEM_MAN=
UFACTURER     "bios-strings/system-manufacturer"
+#d=
efine HVM_XS_SYSTEM_PRODUCT_NAME     "bios-strings/syst=
em-product-name"
+#define
 HVM_XS_SYSTEM_VERSION         =
; "bios-strings/system-version"
+#define HVM_XS_SYSTEM_SERIAL_NUMBER&nbs=
p;   "bios-strings/system-serial-number"
+#define HVM_XS_ENCLO=
SURE_MANUFACTURER  "bios-strings/enclosure-manufacturer"
+#define H=
VM_XS_ENCLOSURE_SERIAL_NUMBER "bios-strings/enclosure-serial-number"
+#d=
efine HVM_XS_BATTERY_MANUFACTURER    "bios-strings/battery-m=
anufacturer"
+#define HVM_XS_BATTERY_DEVICE_NAME    =
 "bios-strings/battery-device-name"
+
+/* Up to 100 OEM strings can b=
e set in xenstore using values of the form
  
From: Ross Philipson <Ross.Philipson@citrix.com>
To: Art=
 Napor <artnapor@yahoo.com> 
Sent: Tuesday, October 9, 2012=
 2:06 PM
Subject: RE: [Xen-devel] [PATCH v3 01/04] HVM firmware p=
assthrough HVM
  
=

Hi=
,
 
So the patches to xen are only part of w=
hat you need to make it all work. Something in your toolstack needs to load=
 the tables you want into the new guest. There was no really good place to =
do this in the xen tools so I did not push. I am guessing e.g. somewhere in=
 you dom0 tools, you would call dmidecode or read the tables from sysfs, fo=
rm the set of tables for the guest that you want and pass them in to the li=
bxc domain creator function. Does that make sense?
 
Thanks
<=
/div>
Ross
&nbs=
p;
From: Art Napor [mailt=
o:artnapor@yahoo.com] 
Sent: Tuesday, October 09, 2012 1:55 PMTo: Ross Philipson
Subject: Re: [Xen-devel] [PATCH v3 01/=
04] HVM firmware passthrough HVM=

 
<=
div>
Ross,
 
Thanks again for the information. I was able to apply the SMBIOS patch=
 series cleanly to 4.1.2 and v3 of your later patch series to 4.2 and 4.3 t=
esting. Is there an option or flag that needs to be set to enable the HVM p=
assthrough? I believe the patches applied cleanly - I didn't notice any rej=
ects. I have smbios loaded in the Dom0 /sys/firmware/smbios and /sys/class/=
dmi/. A Centos 5 DomU with the patched Xen 4.2/4.3 appears to still report =
the standard Xen bios information via dmidecode. 
 
<=
div>
 
<=
div>
From: Ross Phili=
pson <Ross.Philipson@citrix.com>
To: Art Napor <artnapor=
@yahoo.com>; "xen-devel@lists.xen.org" <xen-devel@lists.xen.org> <=
br>Sent: Friday, August 31, 2012 4:36 PM
Subject: RE: [Xen=
-devel] [PATCH v3 01/04]
 HVM firmware passthrough HVM

> I also came across the earlier smbios passthroug=
h patch series. I'm looking to be able to pass the DMI block from the Dom0 =
to the DomU when. Your earlier smbios patch series applied cleanly built ag=
ainst to 4.1.2, but the Dom0 smbios data didn't seem to make it into the HV=
M DomU. 

> Are there any version or other changset limitations th=
at would prevent the patches from being manually applied to 4.1? 

&g=
t; http://lists.xen.org/archives/htm=
l/xen-devel/2012-02/msg01754.html

Well there were some tool stac=
k changes (in libxl) that happened right around the time I was making the p=
atches so
 I had to change things to match that. So in an older branch you might have=
 to change the way the BIOS blobs get sent in to the domain building code.<=
br>
The rest of the code to load the BIOS bits into the new guests memor=
y and the changes to hvmloader to process them should apply cleanly I think=
.

Note that the last patch set for this (v3) does support passing in=
 both SMBIOS structures and ACPI tables so you can use that patch set.
<=
br>Thanks
Ross


  


 
 
  

---406315465-933205781-1350067600=:22418--


--===============7771013552937689304==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7771013552937689304==--


From xen-devel-bounces@lists.xen.org Fri Oct 12 18:53:06 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 18:53:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMkLl-0006m1-E7; Fri, 12 Oct 2012 18:52:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMkLk-0006lv-U4
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 18:52:45 +0000
Received: from [85.158.143.99:36475] by server-2.bemta-4.messagelabs.com id
	BF/F6-25171-CF668705; Fri, 12 Oct 2012 18:52:44 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-216.messagelabs.com!1350067962!27484392!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDE0NDQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDE0NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23907 invoked from network); 12 Oct 2012 18:52:43 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Oct 2012 18:52:43 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHji0PEzM=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-090-010.pools.arcor-ip.net [88.65.90.10])
	by smtp.strato.de (jored mo11) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 00649co9CGmlZb ;
	Fri, 12 Oct 2012 20:52:42 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id DEC8E18642; Fri, 12 Oct 2012 20:52:41 +0200 (CEST)
Date: Fri, 12 Oct 2012 20:52:41 +0200
From: Olaf Hering 
To: Ian Campbell 
Message-ID: <20121012185241.GA24569@aepfle.de>
References: <20121012181510.GA18284@aepfle.de>
	<1350067274.6952.117.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1350067274.6952.117.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] no xl monitor process with xl create -V
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 12, Ian Campbell wrote:

> On Fri, 2012-10-12 at 19:15 +0100, Olaf Hering wrote:
> > When I create a HVM guest with 'xl -v -v create -d -V -f cfg' there is
> > no xl process to monitor the guest. As a result a guest shutdown is not
> > handled. Without the -V option the xl process exists and after guest
> > shutdown the domain disappears.
> 
> Sounds like a bug in the implementation of -V to me.
> 
> > Any idea how to fix this? Its with 4.2.
> 
> Is it exiting deliberately or crashing? What do the logs say?

There is no xl logfile, and nothing which indicates an error. I suspect
something does 'exec vncviewer' within xl.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 18:53:06 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 18:53:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMkLl-0006m1-E7; Fri, 12 Oct 2012 18:52:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMkLk-0006lv-U4
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 18:52:45 +0000
Received: from [85.158.143.99:36475] by server-2.bemta-4.messagelabs.com id
	BF/F6-25171-CF668705; Fri, 12 Oct 2012 18:52:44 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-216.messagelabs.com!1350067962!27484392!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDE0NDQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDE0NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23907 invoked from network); 12 Oct 2012 18:52:43 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Oct 2012 18:52:43 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHji0PEzM=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-090-010.pools.arcor-ip.net [88.65.90.10])
	by smtp.strato.de (jored mo11) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 00649co9CGmlZb ;
	Fri, 12 Oct 2012 20:52:42 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id DEC8E18642; Fri, 12 Oct 2012 20:52:41 +0200 (CEST)
Date: Fri, 12 Oct 2012 20:52:41 +0200
From: Olaf Hering 
To: Ian Campbell 
Message-ID: <20121012185241.GA24569@aepfle.de>
References: <20121012181510.GA18284@aepfle.de>
	<1350067274.6952.117.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1350067274.6952.117.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] no xl monitor process with xl create -V
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 12, Ian Campbell wrote:

> On Fri, 2012-10-12 at 19:15 +0100, Olaf Hering wrote:
> > When I create a HVM guest with 'xl -v -v create -d -V -f cfg' there is
> > no xl process to monitor the guest. As a result a guest shutdown is not
> > handled. Without the -V option the xl process exists and after guest
> > shutdown the domain disappears.
> 
> Sounds like a bug in the implementation of -V to me.
> 
> > Any idea how to fix this? Its with 4.2.
> 
> Is it exiting deliberately or crashing? What do the logs say?

There is no xl logfile, and nothing which indicates an error. I suspect
something does 'exec vncviewer' within xl.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 18:54:07 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 18:54:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMkMn-0006s4-T0; Fri, 12 Oct 2012 18:53:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMkMn-0006rt-0O
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 18:53:49 +0000
Received: from [85.158.139.83:33852] by server-5.bemta-5.messagelabs.com id
	43/5E-19238-C3768705; Fri, 12 Oct 2012 18:53:48 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-12.tower-182.messagelabs.com!1350068026!34462581!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16903 invoked from network); 12 Oct 2012 18:53:47 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 18:53:47 -0000
Received: by mail-ie0-f173.google.com with SMTP id 17so6683979iea.32
	for ; Fri, 12 Oct 2012 11:53:46 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=loVgQ7sTmB2iHvhc7O5GfErr/sa3exYsTp3ZWYXYl2c=;
	b=Mx83PCzoxw9+nv4CITDEimLfuUsl3KDzL8hYK390wi7vGWQH8yJKSsDHprMLtZaymq
	/qBAdf17AXL1JXFbrAAlooI0TSQoJ5D+jxwAwfF0fYv/Gs7XJF9zwYucTJgsiI6Y+1GP
	ex19bEohTd93RPBp/sFxRCLYVXA6pOU4q9SD+8LA/MiZYwAWqiCl4F7SMLiFYMeBZpaX
	uJnL1ZJ4wH6pBG2x//E9JoxY2DqygvLOtXCMD3QjjU2VjLmnqMd8SAODTpTfb0sTWGTr
	JjoDNyYUiE3oEKQs2lxHOMisaPsuT4BYgU8TQxcABFMpkNdGX71xdt4iKGJ8q8g/Y3nz
	n6WQ==
Received: by 10.50.16.172 with SMTP id h12mr3100861igd.41.1350068025931;
	Fri, 12 Oct 2012 11:53:45 -0700 (PDT)
Received: from [192.168.4.87] ([206.223.182.18])
	by mx.google.com with ESMTPS id gz10sm2307196igc.9.2012.10.12.11.53.42
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 12 Oct 2012 11:53:44 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1085)
From: Andres Lagar-Cavilla 
In-Reply-To: 
Date: Fri, 12 Oct 2012 14:53:41 -0400
Message-Id: <680D4CF9-84B5-4DB7-B083-6B7560B39562@gridcentric.ca>
References: 
To: Keir Fraser 
X-Mailer: Apple Mail (2.1085)
X-Gm-Message-State: ALoCoQmpmVw4gk5fENAG1WY1VSi/yBvLHbn/qqlgxkK167NwlpQMihv6k6TG0jbl3beZ/Gk+VZtT
Cc: Olaf Hering , Ian Campbell ,
	George Dunlap ,
	Tim Deegan , xen-devel@lists.xen.org,
	Jan Beulich 
Subject: Re: [Xen-devel] Wait queue support for 4.3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Oct 12, 2012, at 1:26 PM, Keir Fraser wrote:

> On 12/10/2012 17:43, "Andres Lagar-Cavilla"  wrote:
> 
>>>> The current maintainer (effectively) for wait queues is Keir. Keir, any
>>>> ideas
>>>> on a schedule for the cleanup?
>>> 
>>> I maintain the wait-queue mechanism, but not every (potential) user of it!
>> 
>> That's the end of my cunning scheme. It was worth a try ...
>> 
>>> The only use-case above that might fall into my domain is 3, I think.
>> 
>> So perhaps mm should wait for that to happen to then tackle wait queues for
>> paging/sharing?
> 
> I don't see any dependency. And Tim has already proposed patches for
> use-case 2, in fact, as you noted. So, shouldn't they simply be polished up
> and applied as soon as possible? Basically, for mm type things, Tim is your
> man, either as author or reviewer.

Ok. Wanted to ascertain where we stand on things.

Tim's patches crash guests because there are all sorts of spinlocks being held. That's the gist of the mm work that needs to be done. And a separate discussion.

Thanks
Andres

> 
> -- Keir
> 
>> Thanks,
>> Andres
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 18:54:07 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 18:54:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMkMn-0006s4-T0; Fri, 12 Oct 2012 18:53:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMkMn-0006rt-0O
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 18:53:49 +0000
Received: from [85.158.139.83:33852] by server-5.bemta-5.messagelabs.com id
	43/5E-19238-C3768705; Fri, 12 Oct 2012 18:53:48 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-12.tower-182.messagelabs.com!1350068026!34462581!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16903 invoked from network); 12 Oct 2012 18:53:47 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 18:53:47 -0000
Received: by mail-ie0-f173.google.com with SMTP id 17so6683979iea.32
	for ; Fri, 12 Oct 2012 11:53:46 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=loVgQ7sTmB2iHvhc7O5GfErr/sa3exYsTp3ZWYXYl2c=;
	b=Mx83PCzoxw9+nv4CITDEimLfuUsl3KDzL8hYK390wi7vGWQH8yJKSsDHprMLtZaymq
	/qBAdf17AXL1JXFbrAAlooI0TSQoJ5D+jxwAwfF0fYv/Gs7XJF9zwYucTJgsiI6Y+1GP
	ex19bEohTd93RPBp/sFxRCLYVXA6pOU4q9SD+8LA/MiZYwAWqiCl4F7SMLiFYMeBZpaX
	uJnL1ZJ4wH6pBG2x//E9JoxY2DqygvLOtXCMD3QjjU2VjLmnqMd8SAODTpTfb0sTWGTr
	JjoDNyYUiE3oEKQs2lxHOMisaPsuT4BYgU8TQxcABFMpkNdGX71xdt4iKGJ8q8g/Y3nz
	n6WQ==
Received: by 10.50.16.172 with SMTP id h12mr3100861igd.41.1350068025931;
	Fri, 12 Oct 2012 11:53:45 -0700 (PDT)
Received: from [192.168.4.87] ([206.223.182.18])
	by mx.google.com with ESMTPS id gz10sm2307196igc.9.2012.10.12.11.53.42
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 12 Oct 2012 11:53:44 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1085)
From: Andres Lagar-Cavilla 
In-Reply-To: 
Date: Fri, 12 Oct 2012 14:53:41 -0400
Message-Id: <680D4CF9-84B5-4DB7-B083-6B7560B39562@gridcentric.ca>
References: 
To: Keir Fraser 
X-Mailer: Apple Mail (2.1085)
X-Gm-Message-State: ALoCoQmpmVw4gk5fENAG1WY1VSi/yBvLHbn/qqlgxkK167NwlpQMihv6k6TG0jbl3beZ/Gk+VZtT
Cc: Olaf Hering , Ian Campbell ,
	George Dunlap ,
	Tim Deegan , xen-devel@lists.xen.org,
	Jan Beulich 
Subject: Re: [Xen-devel] Wait queue support for 4.3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Oct 12, 2012, at 1:26 PM, Keir Fraser wrote:

> On 12/10/2012 17:43, "Andres Lagar-Cavilla"  wrote:
> 
>>>> The current maintainer (effectively) for wait queues is Keir. Keir, any
>>>> ideas
>>>> on a schedule for the cleanup?
>>> 
>>> I maintain the wait-queue mechanism, but not every (potential) user of it!
>> 
>> That's the end of my cunning scheme. It was worth a try ...
>> 
>>> The only use-case above that might fall into my domain is 3, I think.
>> 
>> So perhaps mm should wait for that to happen to then tackle wait queues for
>> paging/sharing?
> 
> I don't see any dependency. And Tim has already proposed patches for
> use-case 2, in fact, as you noted. So, shouldn't they simply be polished up
> and applied as soon as possible? Basically, for mm type things, Tim is your
> man, either as author or reviewer.

Ok. Wanted to ascertain where we stand on things.

Tim's patches crash guests because there are all sorts of spinlocks being held. That's the gist of the mm work that needs to be done. And a separate discussion.

Thanks
Andres

> 
> -- Keir
> 
>> Thanks,
>> Andres
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 19:06:45 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 19:06:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMkZ2-0007A0-6d; Fri, 12 Oct 2012 19:06:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMkZ0-00079u-GK
	for Xen-devel@lists.xensource.com; Fri, 12 Oct 2012 19:06:26 +0000
Received: from [85.158.143.35:25289] by server-2.bemta-4.messagelabs.com id
	33/CE-25171-13A68705; Fri, 12 Oct 2012 19:06:25 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1350068783!18572337!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODAwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15501 invoked from network); 12 Oct 2012 19:06:25 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Oct 2012 19:06:25 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9CJ6L7r001220
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 12 Oct 2012 19:06:22 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9CJ6KcL007177
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 12 Oct 2012 19:06:21 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9CJ6KWX029886; Fri, 12 Oct 2012 14:06:20 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Oct 2012 12:06:20 -0700
Date: Fri, 12 Oct 2012 12:06:19 -0700
From: Mukesh Rathor 
To: Ian Campbell 
Message-ID: <20121012120619.6d8f3317@mantra.us.oracle.com>
In-Reply-To: <1350031937.14806.49.camel@zakaz.uk.xensource.com>
References: <20121011145711.0d9c27df@mantra.us.oracle.com>
	<1350031937.14806.49.camel@zakaz.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V2 2/7]: PVH: use native irq, enable callback,
 use HVM ring ops, ...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 12 Oct 2012 09:52:17 +0100
Ian Campbell  wrote:

> >  drivers/xen/cpu_hotplug.c            |    4 +++-
> >  drivers/xen/events.c                 |    9 ++++++++-
> >  drivers/xen/xenbus/xenbus_client.c   |    3 ++-
> >  7 files changed, 27 insertions(+), 8 deletions(-)
> > 
> > diff --git a/arch/x86/include/asm/xen/interface.h
> > b/arch/x86/include/asm/xen/interface.h index 555f94d..f11edb0 100644
> > --- a/arch/x86/include/asm/xen/interface.h
> > +++ b/arch/x86/include/asm/xen/interface.h
> > @@ -143,7 +143,13 @@ struct vcpu_guest_context {
> >      struct cpu_user_regs user_regs;         /* User-level CPU
> > registers     */ struct trap_info trap_ctxt[256];        /* Virtual
> > IDT                  */ unsigned long ldt_base, ldt_ents;       /*
> > LDT (linear address, # ents) */
> > -    unsigned long gdt_frames[16], gdt_ents; /* GDT (machine
> > frames, # ents) */
> > +    union {
> > +	struct {
> > +		/* PV: GDT (machine frames, # ents).*/
> > +		unsigned long gdt_frames[16], gdt_ents;
> > +	} s;
> > +	unsigned long gdtaddr, gdtsz;	    /* PVH: GDTR addr
> > and size */
> 
> I've pointed out a few times that I think this is wrong -- gdtaddr and
> gdtsz will overlap each other in the union. I'm not sure how it even
> works, unless the hypervisor is ignoring one or the other. You need:
> 
> union {
> 	struct {
> 		unsigned long gdt_frames[16], gdt_ents;
> 	} pv;
> 	struct {
> 		unsigned long gdtaddr, gdtsz;
> 	} pvh;
> } gdt;
> 
> (I've gone with naming the union gdt instead of u. You might want
> therefore to also drop the gdt prefix from the members?)

Is it worth it, I mean, making it a union. Would you be OK if I just
used gdt_frames[0] and gdt_ends for gdtaddr and size?

thanks
Mukesh



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 19:06:45 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 19:06:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMkZ2-0007A0-6d; Fri, 12 Oct 2012 19:06:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMkZ0-00079u-GK
	for Xen-devel@lists.xensource.com; Fri, 12 Oct 2012 19:06:26 +0000
Received: from [85.158.143.35:25289] by server-2.bemta-4.messagelabs.com id
	33/CE-25171-13A68705; Fri, 12 Oct 2012 19:06:25 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1350068783!18572337!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODAwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15501 invoked from network); 12 Oct 2012 19:06:25 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Oct 2012 19:06:25 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9CJ6L7r001220
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 12 Oct 2012 19:06:22 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9CJ6KcL007177
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 12 Oct 2012 19:06:21 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9CJ6KWX029886; Fri, 12 Oct 2012 14:06:20 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Oct 2012 12:06:20 -0700
Date: Fri, 12 Oct 2012 12:06:19 -0700
From: Mukesh Rathor 
To: Ian Campbell 
Message-ID: <20121012120619.6d8f3317@mantra.us.oracle.com>
In-Reply-To: <1350031937.14806.49.camel@zakaz.uk.xensource.com>
References: <20121011145711.0d9c27df@mantra.us.oracle.com>
	<1350031937.14806.49.camel@zakaz.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V2 2/7]: PVH: use native irq, enable callback,
 use HVM ring ops, ...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 12 Oct 2012 09:52:17 +0100
Ian Campbell  wrote:

> >  drivers/xen/cpu_hotplug.c            |    4 +++-
> >  drivers/xen/events.c                 |    9 ++++++++-
> >  drivers/xen/xenbus/xenbus_client.c   |    3 ++-
> >  7 files changed, 27 insertions(+), 8 deletions(-)
> > 
> > diff --git a/arch/x86/include/asm/xen/interface.h
> > b/arch/x86/include/asm/xen/interface.h index 555f94d..f11edb0 100644
> > --- a/arch/x86/include/asm/xen/interface.h
> > +++ b/arch/x86/include/asm/xen/interface.h
> > @@ -143,7 +143,13 @@ struct vcpu_guest_context {
> >      struct cpu_user_regs user_regs;         /* User-level CPU
> > registers     */ struct trap_info trap_ctxt[256];        /* Virtual
> > IDT                  */ unsigned long ldt_base, ldt_ents;       /*
> > LDT (linear address, # ents) */
> > -    unsigned long gdt_frames[16], gdt_ents; /* GDT (machine
> > frames, # ents) */
> > +    union {
> > +	struct {
> > +		/* PV: GDT (machine frames, # ents).*/
> > +		unsigned long gdt_frames[16], gdt_ents;
> > +	} s;
> > +	unsigned long gdtaddr, gdtsz;	    /* PVH: GDTR addr
> > and size */
> 
> I've pointed out a few times that I think this is wrong -- gdtaddr and
> gdtsz will overlap each other in the union. I'm not sure how it even
> works, unless the hypervisor is ignoring one or the other. You need:
> 
> union {
> 	struct {
> 		unsigned long gdt_frames[16], gdt_ents;
> 	} pv;
> 	struct {
> 		unsigned long gdtaddr, gdtsz;
> 	} pvh;
> } gdt;
> 
> (I've gone with naming the union gdt instead of u. You might want
> therefore to also drop the gdt prefix from the members?)

Is it worth it, I mean, making it a union. Would you be OK if I just
used gdt_frames[0] and gdt_ends for gdtaddr and size?

thanks
Mukesh



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 19:34:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 19:34:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMl01-0007Lp-Gn; Fri, 12 Oct 2012 19:34:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMkzz-0007Lk-Sp
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 19:34:20 +0000
Received: from [85.158.139.211:22620] by server-3.bemta-5.messagelabs.com id
	3A/B7-09712-BB078705; Fri, 12 Oct 2012 19:34:19 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1350070458!18149991!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17687 invoked from network); 12 Oct 2012 19:34:18 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 19:34:18 -0000
Received: by mail-wi0-f173.google.com with SMTP id hm4so131818wib.14
	for ; Fri, 12 Oct 2012 12:34:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=2efrUJuQHQKtdqKDxe4SEt6txYBkoPcw0S0pQzdaZTo=;
	b=Nn8da3pOZ7c+QkISihZJlGeuaXJMOQViVqfpAKzkvoaCZJb2p3n4A+0YPAFmHnmeuw
	rllcNzE/9CVi+V0bWdMEiU7e213Wty6NO98IINQXG0uI6Br0wIqu76g0XXPLo+uQshEk
	3iJLh41ogrIHxw2ikeOAcVsV+0wDqGmI7s7IsZjwgbUb21xDQdPRWnR4iFHl0aJPZK1Q
	aXZEOoUWaycK9UqxgRiJF9j4NRk++gfCvmDWfNqeiY572w9H47Wx2HO9THqAeWUBb7W1
	R4/S/SvX8+LoDfj5mX9rE+ipwHazGckJBIH8tW75PGyz8bdMmI9sCu6jsccamLhRdEtb
	Crww==
Received: by 10.216.210.1 with SMTP id t1mr3307850weo.16.1350070458403;
	Fri, 12 Oct 2012 12:34:18 -0700 (PDT)
Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com.
	[86.183.156.141])
	by mx.google.com with ESMTPS id w8sm4688756wif.4.2012.10.12.12.34.15
	(version=SSLv3 cipher=OTHER); Fri, 12 Oct 2012 12:34:17 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Fri, 12 Oct 2012 20:34:10 +0100
From: Keir Fraser 
To: Andres Lagar-Cavilla 
Message-ID: 
Thread-Topic: Wait queue support for 4.3
Thread-Index: Ac2osI0vKH0i8KBbJkC8l/hi67syQA==
In-Reply-To: <680D4CF9-84B5-4DB7-B083-6B7560B39562@gridcentric.ca>
Mime-version: 1.0
Cc: Olaf Hering , Ian Campbell ,
	George Dunlap ,
	Tim Deegan , xen-devel@lists.xen.org,
	Jan Beulich 
Subject: Re: [Xen-devel] Wait queue support for 4.3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/10/2012 19:53, "Andres Lagar-Cavilla"  wrote:

>> I don't see any dependency. And Tim has already proposed patches for
>> use-case 2, in fact, as you noted. So, shouldn't they simply be polished up
>> and applied as soon as possible? Basically, for mm type things, Tim is your
>> man, either as author or reviewer.
> 
> Ok. Wanted to ascertain where we stand on things.
> 
> Tim's patches crash guests because there are all sorts of spinlocks being
> held. That's the gist of the mm work that needs to be done. And a separate
> discussion.

Yes, that's a *mm* can of worms. :) Tim is the first port of call, and
working out who actually does the work, and what work that is, will be the
the ensuing discussion.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 19:34:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 19:34:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMl01-0007Lp-Gn; Fri, 12 Oct 2012 19:34:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMkzz-0007Lk-Sp
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 19:34:20 +0000
Received: from [85.158.139.211:22620] by server-3.bemta-5.messagelabs.com id
	3A/B7-09712-BB078705; Fri, 12 Oct 2012 19:34:19 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1350070458!18149991!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17687 invoked from network); 12 Oct 2012 19:34:18 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Oct 2012 19:34:18 -0000
Received: by mail-wi0-f173.google.com with SMTP id hm4so131818wib.14
	for ; Fri, 12 Oct 2012 12:34:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=2efrUJuQHQKtdqKDxe4SEt6txYBkoPcw0S0pQzdaZTo=;
	b=Nn8da3pOZ7c+QkISihZJlGeuaXJMOQViVqfpAKzkvoaCZJb2p3n4A+0YPAFmHnmeuw
	rllcNzE/9CVi+V0bWdMEiU7e213Wty6NO98IINQXG0uI6Br0wIqu76g0XXPLo+uQshEk
	3iJLh41ogrIHxw2ikeOAcVsV+0wDqGmI7s7IsZjwgbUb21xDQdPRWnR4iFHl0aJPZK1Q
	aXZEOoUWaycK9UqxgRiJF9j4NRk++gfCvmDWfNqeiY572w9H47Wx2HO9THqAeWUBb7W1
	R4/S/SvX8+LoDfj5mX9rE+ipwHazGckJBIH8tW75PGyz8bdMmI9sCu6jsccamLhRdEtb
	Crww==
Received: by 10.216.210.1 with SMTP id t1mr3307850weo.16.1350070458403;
	Fri, 12 Oct 2012 12:34:18 -0700 (PDT)
Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com.
	[86.183.156.141])
	by mx.google.com with ESMTPS id w8sm4688756wif.4.2012.10.12.12.34.15
	(version=SSLv3 cipher=OTHER); Fri, 12 Oct 2012 12:34:17 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Fri, 12 Oct 2012 20:34:10 +0100
From: Keir Fraser 
To: Andres Lagar-Cavilla 
Message-ID: 
Thread-Topic: Wait queue support for 4.3
Thread-Index: Ac2osI0vKH0i8KBbJkC8l/hi67syQA==
In-Reply-To: <680D4CF9-84B5-4DB7-B083-6B7560B39562@gridcentric.ca>
Mime-version: 1.0
Cc: Olaf Hering , Ian Campbell ,
	George Dunlap ,
	Tim Deegan , xen-devel@lists.xen.org,
	Jan Beulich 
Subject: Re: [Xen-devel] Wait queue support for 4.3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/10/2012 19:53, "Andres Lagar-Cavilla"  wrote:

>> I don't see any dependency. And Tim has already proposed patches for
>> use-case 2, in fact, as you noted. So, shouldn't they simply be polished up
>> and applied as soon as possible? Basically, for mm type things, Tim is your
>> man, either as author or reviewer.
> 
> Ok. Wanted to ascertain where we stand on things.
> 
> Tim's patches crash guests because there are all sorts of spinlocks being
> held. That's the gist of the mm work that needs to be done. And a separate
> discussion.

Yes, that's a *mm* can of worms. :) Tim is the first port of call, and
working out who actually does the work, and what work that is, will be the
the ensuing discussion.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 21:19:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 21:19:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMmcy-0007l0-Gy; Fri, 12 Oct 2012 21:18:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMmcw-0007kv-Ty
	for Xen-devel@lists.xensource.com; Fri, 12 Oct 2012 21:18:39 +0000
Received: from [85.158.137.99:52364] by server-12.bemta-3.messagelabs.com id
	A4/8D-27853-E2988705; Fri, 12 Oct 2012 21:18:38 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1350076716!20174622!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgwNzQ3OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15052 invoked from network); 12 Oct 2012 21:18:37 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Oct 2012 21:18:37 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9CLIWnU026178
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 12 Oct 2012 21:18:33 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9CLIWTX021600
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 12 Oct 2012 21:18:32 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9CLIVE2012233; Fri, 12 Oct 2012 16:18:31 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Oct 2012 14:18:31 -0700
Date: Fri, 12 Oct 2012 14:18:30 -0700
From: Mukesh Rathor 
To: Ian Campbell 
Message-ID: <20121012141830.514c68c2@mantra.us.oracle.com>
In-Reply-To: <1350033511.14806.64.camel@zakaz.uk.xensource.com>
References: <20121011144929.06e71a9e@mantra.us.oracle.com>
	<1350033511.14806.64.camel@zakaz.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V2 0/7]: PVH: PV guest with extensions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 12 Oct 2012 10:18:31 +0100
Ian Campbell  wrote:

> On Thu, 2012-10-11 at 22:49 +0100, Mukesh Rathor wrote:
> > Hi guys,
> > 
> > Ok, I've made all the changes from prev RFC patch submissions.
> > Tested all the combinations. The patches are organized slightly
> > differently from prev version because of the nature of changes
> > after last review. I am building xen patch just for the
> > corresponding header file changes. Following that I'll refresh xen
> > tree, debug, test, and send patches.
> > 
> > For linux kernel mailing list introduction, PVH is a PV guest that
> > can run in an HVM container, uses native pagetables, uses callback
> > vector, native IDT, and native syscalls.
> > 
> > They were built on top of 89d0307af2b9957d59bfb2a86aaa57464ff921de
> > commit.
> 
> I took a (fairly quick) look. I had a few comments but overall looks
> pretty good, thanks!
> 
> I'm constantly amazed by how small this patchset is. I suspect you are
> going to make up for it in the hypervisor side ;-)

Hehe... yes! The patch has become almost half since I first got it
working. Each review trims it down :).

thanks
Mukesh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 21:19:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 21:19:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMmcy-0007l0-Gy; Fri, 12 Oct 2012 21:18:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMmcw-0007kv-Ty
	for Xen-devel@lists.xensource.com; Fri, 12 Oct 2012 21:18:39 +0000
Received: from [85.158.137.99:52364] by server-12.bemta-3.messagelabs.com id
	A4/8D-27853-E2988705; Fri, 12 Oct 2012 21:18:38 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1350076716!20174622!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgwNzQ3OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15052 invoked from network); 12 Oct 2012 21:18:37 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Oct 2012 21:18:37 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9CLIWnU026178
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 12 Oct 2012 21:18:33 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9CLIWTX021600
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 12 Oct 2012 21:18:32 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9CLIVE2012233; Fri, 12 Oct 2012 16:18:31 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Oct 2012 14:18:31 -0700
Date: Fri, 12 Oct 2012 14:18:30 -0700
From: Mukesh Rathor 
To: Ian Campbell 
Message-ID: <20121012141830.514c68c2@mantra.us.oracle.com>
In-Reply-To: <1350033511.14806.64.camel@zakaz.uk.xensource.com>
References: <20121011144929.06e71a9e@mantra.us.oracle.com>
	<1350033511.14806.64.camel@zakaz.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V2 0/7]: PVH: PV guest with extensions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 12 Oct 2012 10:18:31 +0100
Ian Campbell  wrote:

> On Thu, 2012-10-11 at 22:49 +0100, Mukesh Rathor wrote:
> > Hi guys,
> > 
> > Ok, I've made all the changes from prev RFC patch submissions.
> > Tested all the combinations. The patches are organized slightly
> > differently from prev version because of the nature of changes
> > after last review. I am building xen patch just for the
> > corresponding header file changes. Following that I'll refresh xen
> > tree, debug, test, and send patches.
> > 
> > For linux kernel mailing list introduction, PVH is a PV guest that
> > can run in an HVM container, uses native pagetables, uses callback
> > vector, native IDT, and native syscalls.
> > 
> > They were built on top of 89d0307af2b9957d59bfb2a86aaa57464ff921de
> > commit.
> 
> I took a (fairly quick) look. I had a few comments but overall looks
> pretty good, thanks!
> 
> I'm constantly amazed by how small this patchset is. I suspect you are
> going to make up for it in the hypervisor side ;-)

Hehe... yes! The patch has become almost half since I first got it
working. Each review trims it down :).

thanks
Mukesh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 21:22:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 21:22:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMmgP-0007rN-4d; Fri, 12 Oct 2012 21:22:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMmgN-0007rD-VD
	for Xen-devel@lists.xensource.com; Fri, 12 Oct 2012 21:22:12 +0000
Received: from [85.158.139.83:31383] by server-13.bemta-5.messagelabs.com id
	13/00-29905-30A88705; Fri, 12 Oct 2012 21:22:11 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1350076929!27434455!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODAwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1160 invoked from network); 12 Oct 2012 21:22:10 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Oct 2012 21:22:10 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9CLM6Z2026328
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 12 Oct 2012 21:22:07 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9CLM5dR006925
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 12 Oct 2012 21:22:06 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9CLM57h005071; Fri, 12 Oct 2012 16:22:06 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Oct 2012 14:22:05 -0700
Date: Fri, 12 Oct 2012 14:22:04 -0700
From: Mukesh Rathor 
To: Ian Campbell 
Message-ID: <20121012142204.47b9d780@mantra.us.oracle.com>
In-Reply-To: <1350031728.14806.45.camel@zakaz.uk.xensource.com>
References: <20121011145317.51655302@mantra.us.oracle.com>
	<1350031728.14806.45.camel@zakaz.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V2 1/7]: PVH: basic and header changes,
 elfnote changes, ...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 12 Oct 2012 09:48:48 +0100
Ian Campbell  wrote:

> > index fdce49c..9323b8c 100644
> > --- a/arch/x86/xen/Kconfig
> > +++ b/arch/x86/xen/Kconfig
> > @@ -50,3 +50,13 @@ config XEN_DEBUG_FS
> >  	  Enable statistics output and various tuning options in
> > debugfs. Enabling this option may incur a significant performance
> > overhead. 
> > +config XEN_X86_PVH
> > +	bool "Support for running as a PVH guest (EXPERIMENTAL)"
> > +	depends on X86_64 && XEN && INTEL_IOMMU && EXPERIMENTAL
> 
> OOI why does the kernel side require an INTEL_IOMMU? I can see why the
> hypervisor would need it but the guests (including dom0) can't
> actually see the underlying IOMMU, can they?

Well, the kernel requires the hypervisor to have it, but I guess
thats not what this is referring to. The tools can decide that.
I'll take it out.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 21:22:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 21:22:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMmgP-0007rN-4d; Fri, 12 Oct 2012 21:22:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMmgN-0007rD-VD
	for Xen-devel@lists.xensource.com; Fri, 12 Oct 2012 21:22:12 +0000
Received: from [85.158.139.83:31383] by server-13.bemta-5.messagelabs.com id
	13/00-29905-30A88705; Fri, 12 Oct 2012 21:22:11 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1350076929!27434455!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODAwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1160 invoked from network); 12 Oct 2012 21:22:10 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Oct 2012 21:22:10 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9CLM6Z2026328
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 12 Oct 2012 21:22:07 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9CLM5dR006925
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 12 Oct 2012 21:22:06 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9CLM57h005071; Fri, 12 Oct 2012 16:22:06 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Oct 2012 14:22:05 -0700
Date: Fri, 12 Oct 2012 14:22:04 -0700
From: Mukesh Rathor 
To: Ian Campbell 
Message-ID: <20121012142204.47b9d780@mantra.us.oracle.com>
In-Reply-To: <1350031728.14806.45.camel@zakaz.uk.xensource.com>
References: <20121011145317.51655302@mantra.us.oracle.com>
	<1350031728.14806.45.camel@zakaz.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V2 1/7]: PVH: basic and header changes,
 elfnote changes, ...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 12 Oct 2012 09:48:48 +0100
Ian Campbell  wrote:

> > index fdce49c..9323b8c 100644
> > --- a/arch/x86/xen/Kconfig
> > +++ b/arch/x86/xen/Kconfig
> > @@ -50,3 +50,13 @@ config XEN_DEBUG_FS
> >  	  Enable statistics output and various tuning options in
> > debugfs. Enabling this option may incur a significant performance
> > overhead. 
> > +config XEN_X86_PVH
> > +	bool "Support for running as a PVH guest (EXPERIMENTAL)"
> > +	depends on X86_64 && XEN && INTEL_IOMMU && EXPERIMENTAL
> 
> OOI why does the kernel side require an INTEL_IOMMU? I can see why the
> hypervisor would need it but the guests (including dom0) can't
> actually see the underlying IOMMU, can they?

Well, the kernel requires the hypervisor to have it, but I guess
thats not what this is referring to. The tools can decide that.
I'll take it out.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 22:37:33 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 22:37:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMnql-0008Cj-Sx; Fri, 12 Oct 2012 22:36:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMnqj-0008Cb-Ti
	for Xen-devel@lists.xensource.com; Fri, 12 Oct 2012 22:36:58 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1350081406!2026140!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODAwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32594 invoked from network); 12 Oct 2012 22:36:48 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Oct 2012 22:36:48 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9CMai6B014302
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 12 Oct 2012 22:36:44 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9CMah6o002274
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 12 Oct 2012 22:36:43 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9CMagHQ012750; Fri, 12 Oct 2012 17:36:42 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Oct 2012 15:36:42 -0700
Date: Fri, 12 Oct 2012 15:36:41 -0700
From: Mukesh Rathor 
To: Ian Campbell 
Message-ID: <20121012153641.2b915219@mantra.us.oracle.com>
In-Reply-To: <1350032276.14806.53.camel@zakaz.uk.xensource.com>
References: <20121011145817.0d744c99@mantra.us.oracle.com>
	<1350032276.14806.53.camel@zakaz.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V2 3/7]: PVH:  mmu related changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 12 Oct 2012 09:57:56 +0100
Ian Campbell  wrote:

> On Thu, 2012-10-11 at 22:58 +0100, Mukesh Rathor wrote:
> > @@ -2177,8 +2210,19 @@ static const struct pv_mmu_ops xen_mmu_ops
> > __initconst = {
> > 
> >  void __init xen_init_mmu_ops(void)
> >  {
> > -       x86_init.mapping.pagetable_reserve =
> > xen_mapping_pagetable_reserve; x86_init.paging.pagetable_init =
> > xen_pagetable_init; +
> > +       if (xen_feature(XENFEAT_auto_translated_physmap)) {
> > +               pv_mmu_ops.flush_tlb_others = xen_flush_tlb_others;
> > +
> > +               /* For PCI devices to map iomem. */
> > +               if (xen_initial_domain()) {
> > +                       pv_mmu_ops.set_pte = native_set_pte;
> > +                       pv_mmu_ops.set_pte_at = native_set_pte_at;
> 
> What do these end up being for the !xen_initial_domain case? I'd have
> expected native_FOO.

Yeah, right, we kept on changing the functions that they were set
to, until it came down to just native_*. I just didn't think it didnt
being set. Too much too fast... ok, time to slow down... :) :)..

thanks
Mukesh


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 22:37:33 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 22:37:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMnql-0008Cj-Sx; Fri, 12 Oct 2012 22:36:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMnqj-0008Cb-Ti
	for Xen-devel@lists.xensource.com; Fri, 12 Oct 2012 22:36:58 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1350081406!2026140!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODAwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32594 invoked from network); 12 Oct 2012 22:36:48 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Oct 2012 22:36:48 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9CMai6B014302
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 12 Oct 2012 22:36:44 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9CMah6o002274
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 12 Oct 2012 22:36:43 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9CMagHQ012750; Fri, 12 Oct 2012 17:36:42 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Oct 2012 15:36:42 -0700
Date: Fri, 12 Oct 2012 15:36:41 -0700
From: Mukesh Rathor 
To: Ian Campbell 
Message-ID: <20121012153641.2b915219@mantra.us.oracle.com>
In-Reply-To: <1350032276.14806.53.camel@zakaz.uk.xensource.com>
References: <20121011145817.0d744c99@mantra.us.oracle.com>
	<1350032276.14806.53.camel@zakaz.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V2 3/7]: PVH:  mmu related changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 12 Oct 2012 09:57:56 +0100
Ian Campbell  wrote:

> On Thu, 2012-10-11 at 22:58 +0100, Mukesh Rathor wrote:
> > @@ -2177,8 +2210,19 @@ static const struct pv_mmu_ops xen_mmu_ops
> > __initconst = {
> > 
> >  void __init xen_init_mmu_ops(void)
> >  {
> > -       x86_init.mapping.pagetable_reserve =
> > xen_mapping_pagetable_reserve; x86_init.paging.pagetable_init =
> > xen_pagetable_init; +
> > +       if (xen_feature(XENFEAT_auto_translated_physmap)) {
> > +               pv_mmu_ops.flush_tlb_others = xen_flush_tlb_others;
> > +
> > +               /* For PCI devices to map iomem. */
> > +               if (xen_initial_domain()) {
> > +                       pv_mmu_ops.set_pte = native_set_pte;
> > +                       pv_mmu_ops.set_pte_at = native_set_pte_at;
> 
> What do these end up being for the !xen_initial_domain case? I'd have
> expected native_FOO.

Yeah, right, we kept on changing the functions that they were set
to, until it came down to just native_*. I just didn't think it didnt
being set. Too much too fast... ok, time to slow down... :) :)..

thanks
Mukesh


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 22:40:03 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 22:40:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMntF-0008Hr-Ef; Fri, 12 Oct 2012 22:39:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMntE-0008Hl-EP
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 22:39:32 +0000
Received: from [85.158.139.211:11589] by server-15.bemta-5.messagelabs.com id
	E5/8D-27811-32C98705; Fri, 12 Oct 2012 22:39:31 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1350081569!22126324!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODAwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18616 invoked from network); 12 Oct 2012 22:39:31 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Oct 2012 22:39:31 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9CMdR75015839
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 12 Oct 2012 22:39:28 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9CMdRWu009514
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 12 Oct 2012 22:39:27 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9CMdRsL013468; Fri, 12 Oct 2012 17:39:27 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Oct 2012 15:39:26 -0700
Date: Fri, 12 Oct 2012 15:39:25 -0700
From: Mukesh Rathor 
To: tupeng212 
Message-ID: <20121012153925.012846e4@mantra.us.oracle.com>
In-Reply-To: <201210122024123436447@gmail.com>
References: 
	<201210122024123436447@gmail.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Keir Fraser , xen-devel 
Subject: Re: [Xen-devel] alloc_heap_pages is low efficient with more CPUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 12 Oct 2012 20:24:16 +0800
tupeng212  wrote:

> With 16 CPUs you find domain startup takes 3s always. 
> :No
> With 16CPUs, first 0.3s, second 3s
> With 64CPUs, first 3s, second 30s.
> 
> With 64 CPUs you find it takes 3s first time, then 30s in future? 
> : Yes

...........

I had seen this a while ago, it was always page scrubbing. That
algoright was changed IIRC, so not sure if still could be the cause.

My 2 cents,
thanks
Mukesh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 12 22:40:03 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 12 Oct 2012 22:40:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMntF-0008Hr-Ef; Fri, 12 Oct 2012 22:39:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMntE-0008Hl-EP
	for xen-devel@lists.xen.org; Fri, 12 Oct 2012 22:39:32 +0000
Received: from [85.158.139.211:11589] by server-15.bemta-5.messagelabs.com id
	E5/8D-27811-32C98705; Fri, 12 Oct 2012 22:39:31 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1350081569!22126324!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODAwNTkz\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18616 invoked from network); 12 Oct 2012 22:39:31 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Oct 2012 22:39:31 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9CMdR75015839
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 12 Oct 2012 22:39:28 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9CMdRWu009514
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 12 Oct 2012 22:39:27 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9CMdRsL013468; Fri, 12 Oct 2012 17:39:27 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 12 Oct 2012 15:39:26 -0700
Date: Fri, 12 Oct 2012 15:39:25 -0700
From: Mukesh Rathor 
To: tupeng212 
Message-ID: <20121012153925.012846e4@mantra.us.oracle.com>
In-Reply-To: <201210122024123436447@gmail.com>
References: 
	<201210122024123436447@gmail.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Keir Fraser , xen-devel 
Subject: Re: [Xen-devel] alloc_heap_pages is low efficient with more CPUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 12 Oct 2012 20:24:16 +0800
tupeng212  wrote:

> With 16 CPUs you find domain startup takes 3s always. 
> :No
> With 16CPUs, first 0.3s, second 3s
> With 64CPUs, first 3s, second 30s.
> 
> With 64 CPUs you find it takes 3s first time, then 30s in future? 
> : Yes

...........

I had seen this a while ago, it was always page scrubbing. That
algoright was changed IIRC, so not sure if still could be the cause.

My 2 cents,
thanks
Mukesh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 13 02:17:39 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Oct 2012 02:17:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMrHj-000532-C3; Sat, 13 Oct 2012 02:17:03 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMrHh-00052x-AR
	for xen-devel@lists.xensource.com; Sat, 13 Oct 2012 02:17:01 +0000
X-Env-Sender: linus971@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1350094614!8408180!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2555 invoked from network); 13 Oct 2012 02:16:54 -0000
Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com)
	(74.125.82.43)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Oct 2012 02:16:54 -0000
Received: by mail-wg0-f43.google.com with SMTP id dq11so2460840wgb.24
	for ;
	Fri, 12 Oct 2012 19:16:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=DUz7WwvVwytR42I40xqWyOctxMMNnEHEDtU+/b80wrQ=;
	b=Eawx76bplW8judppPMVkK32jrpg7AW0EFEVD0B/szpwKboFE60cWDIc7vkEsTQZlxt
	mmOVq4SP1JxZ8Go2za18CDc2ARPFVIBqyXTk5ngABe9KQQ8UW1eXAl4i5hhCdTCmRxgx
	h77zbrc+OOrr8ycDfYpk2rClaR57AuEntvLmPQJQASrHNnswv3EsJFIWz0eRWcDMQu3r
	TFZlaRFbzZw6zBWSYDVDkFxCiw6CoOmOEMmhv8R5h9Ec0HeK/344ck/Wk0TkMgEbYDC7
	e7J3/5RNHuvwODXPyjDcOgJTrwlVGShpldibcc5IQuLPUdq9sfLerM2oHpRXMqBBsCnG
	mbOA==
Received: by 10.180.77.38 with SMTP id p6mr9823297wiw.1.1350094614243; Fri, 12
	Oct 2012 19:16:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.195.164 with HTTP; Fri, 12 Oct 2012 19:16:34 -0700 (PDT)
In-Reply-To: <20121012134529.GA1560@phenom.dumpdata.com>
References: <20121012134529.GA1560@phenom.dumpdata.com>
From: Linus Torvalds 
Date: Sat, 13 Oct 2012 11:16:34 +0900
X-Google-Sender-Auth: 2HqzI1SK8hCBG-Ykfx9xpSR-QAY
Message-ID: 
To: Konrad Rzeszutek Wilk 
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [GIT PULL] (xen) stable/for-linus-3.7-uapi-tag for
	v3.7-rc0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 12, 2012 at 10:45 PM, Konrad Rzeszutek Wilk
 wrote:
>
> Please pull!

Btw, please use the -M switch to get renames as renames (and
--summary). You diffstat:

>  include/uapi/xen/Kbuild    |    2 +
>  include/uapi/xen/evtchn.h  |   88 +++++++++++++++++++++++++++++++++++++++
>  include/uapi/xen/privcmd.h |   98 ++++++++++++++++++++++++++++++++++++++++++++
>  include/xen/Kbuild         |    2 -
>  include/xen/evtchn.h       |   88 ---------------------------------------
>  include/xen/privcmd.h      |   98 --------------------------------------------
>  6 files changed, 188 insertions(+), 188 deletions(-)

is misleading, the correct one is much simpler:

 include/{ => uapi}/xen/evtchn.h  | 0
 include/{ => uapi}/xen/privcmd.h | 0
 include/xen/Kbuild               | 2 --
 4 files changed, 2 insertions(+), 2 deletions(-)
 rename include/{ => uapi}/xen/evtchn.h (100%)
 rename include/{ => uapi}/xen/privcmd.h (100%)

Thanks,

                Linus

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 13 02:17:39 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Oct 2012 02:17:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMrHj-000532-C3; Sat, 13 Oct 2012 02:17:03 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMrHh-00052x-AR
	for xen-devel@lists.xensource.com; Sat, 13 Oct 2012 02:17:01 +0000
X-Env-Sender: linus971@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1350094614!8408180!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2555 invoked from network); 13 Oct 2012 02:16:54 -0000
Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com)
	(74.125.82.43)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Oct 2012 02:16:54 -0000
Received: by mail-wg0-f43.google.com with SMTP id dq11so2460840wgb.24
	for ;
	Fri, 12 Oct 2012 19:16:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=DUz7WwvVwytR42I40xqWyOctxMMNnEHEDtU+/b80wrQ=;
	b=Eawx76bplW8judppPMVkK32jrpg7AW0EFEVD0B/szpwKboFE60cWDIc7vkEsTQZlxt
	mmOVq4SP1JxZ8Go2za18CDc2ARPFVIBqyXTk5ngABe9KQQ8UW1eXAl4i5hhCdTCmRxgx
	h77zbrc+OOrr8ycDfYpk2rClaR57AuEntvLmPQJQASrHNnswv3EsJFIWz0eRWcDMQu3r
	TFZlaRFbzZw6zBWSYDVDkFxCiw6CoOmOEMmhv8R5h9Ec0HeK/344ck/Wk0TkMgEbYDC7
	e7J3/5RNHuvwODXPyjDcOgJTrwlVGShpldibcc5IQuLPUdq9sfLerM2oHpRXMqBBsCnG
	mbOA==
Received: by 10.180.77.38 with SMTP id p6mr9823297wiw.1.1350094614243; Fri, 12
	Oct 2012 19:16:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.195.164 with HTTP; Fri, 12 Oct 2012 19:16:34 -0700 (PDT)
In-Reply-To: <20121012134529.GA1560@phenom.dumpdata.com>
References: <20121012134529.GA1560@phenom.dumpdata.com>
From: Linus Torvalds 
Date: Sat, 13 Oct 2012 11:16:34 +0900
X-Google-Sender-Auth: 2HqzI1SK8hCBG-Ykfx9xpSR-QAY
Message-ID: 
To: Konrad Rzeszutek Wilk 
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [GIT PULL] (xen) stable/for-linus-3.7-uapi-tag for
	v3.7-rc0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 12, 2012 at 10:45 PM, Konrad Rzeszutek Wilk
 wrote:
>
> Please pull!

Btw, please use the -M switch to get renames as renames (and
--summary). You diffstat:

>  include/uapi/xen/Kbuild    |    2 +
>  include/uapi/xen/evtchn.h  |   88 +++++++++++++++++++++++++++++++++++++++
>  include/uapi/xen/privcmd.h |   98 ++++++++++++++++++++++++++++++++++++++++++++
>  include/xen/Kbuild         |    2 -
>  include/xen/evtchn.h       |   88 ---------------------------------------
>  include/xen/privcmd.h      |   98 --------------------------------------------
>  6 files changed, 188 insertions(+), 188 deletions(-)

is misleading, the correct one is much simpler:

 include/{ => uapi}/xen/evtchn.h  | 0
 include/{ => uapi}/xen/privcmd.h | 0
 include/xen/Kbuild               | 2 --
 4 files changed, 2 insertions(+), 2 deletions(-)
 rename include/{ => uapi}/xen/evtchn.h (100%)
 rename include/{ => uapi}/xen/privcmd.h (100%)

Thanks,

                Linus

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 13 04:51:53 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Oct 2012 04:51:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMtgy-0005XL-3G; Sat, 13 Oct 2012 04:51:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMtgw-0005XG-9B
	for xen-devel@lists.xensource.com; Sat, 13 Oct 2012 04:51:14 +0000
Received: from [85.158.139.83:8117] by server-3.bemta-5.messagelabs.com id
	CA/E6-09712-143F8705; Sat, 13 Oct 2012 04:51:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1350103872!30140402!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQyMDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18869 invoked from network); 13 Oct 2012 04:51:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Oct 2012 04:51:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,580,1344211200"; d="scan'208";a="15141424"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Oct 2012 04:51:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sat, 13 Oct 2012 05:51:12 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TMtgt-0001pg-KN;
	Sat, 13 Oct 2012 04:51:11 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TMtgt-0008SV-C2;
	Sat, 13 Oct 2012 05:51:11 +0100
To: 
Message-ID: 
From: xen.org 
Date: Sat, 13 Oct 2012 05:51:11 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13958: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13958 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13958/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install     fail pass in 13957
 test-amd64-i386-xl-credit2    3 host-install(3)  broken in 13957 pass in 13958

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13957
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13957
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13957
 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail in 13957 like 13956

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  e0e1350dfe9b
baseline version:
 xen                  e0e1350dfe9b

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 13 04:51:53 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Oct 2012 04:51:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMtgy-0005XL-3G; Sat, 13 Oct 2012 04:51:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMtgw-0005XG-9B
	for xen-devel@lists.xensource.com; Sat, 13 Oct 2012 04:51:14 +0000
Received: from [85.158.139.83:8117] by server-3.bemta-5.messagelabs.com id
	CA/E6-09712-143F8705; Sat, 13 Oct 2012 04:51:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1350103872!30140402!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQyMDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18869 invoked from network); 13 Oct 2012 04:51:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Oct 2012 04:51:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,580,1344211200"; d="scan'208";a="15141424"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Oct 2012 04:51:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sat, 13 Oct 2012 05:51:12 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TMtgt-0001pg-KN;
	Sat, 13 Oct 2012 04:51:11 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TMtgt-0008SV-C2;
	Sat, 13 Oct 2012 05:51:11 +0100
To: 
Message-ID: 
From: xen.org 
Date: Sat, 13 Oct 2012 05:51:11 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13958: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13958 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13958/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install     fail pass in 13957
 test-amd64-i386-xl-credit2    3 host-install(3)  broken in 13957 pass in 13958

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13957
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13957
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13957
 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail in 13957 like 13956

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  e0e1350dfe9b
baseline version:
 xen                  e0e1350dfe9b

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 13 06:04:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Oct 2012 06:04:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMup3-00063V-Mk; Sat, 13 Oct 2012 06:03:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMup1-00063Q-QA
	for xen-devel@lists.xen.org; Sat, 13 Oct 2012 06:03:40 +0000
Received: from [85.158.138.51:10734] by server-7.bemta-3.messagelabs.com id
	30/66-06991-B3409705; Sat, 13 Oct 2012 06:03:39 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1350108218!32425874!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19125 invoked from network); 13 Oct 2012 06:03:38 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Oct 2012 06:03:38 -0000
Received: by mail-wi0-f173.google.com with SMTP id hm4so140094wib.14
	for ; Fri, 12 Oct 2012 23:03:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=CTDCFFNy9vZGo7vKTTDHDDlnFLQPNorMerYo0hHzo+s=;
	b=CzoEde5IuspGPg1pCBtI4sAh4QPTz01X+v+H5Uapxegy6YLGcPwBbe2vyrEYJct1na
	1shLaVmw6nQ5z60eFNuYjsbgGJpWYKMc3+b01b4Kre/Xtu/+GgPbj20GsmJLB9iacYmE
	Ge8LuhVNuzw+rCVZQFWR5IT1ISnKuCO+rQfyuhpTJLxraA0ezu7UVDMZP2wKBwNnIEMb
	dzOs+kBtq6zz+8AGhiHqYiaEfo0FvT250qqzY3n9ycNG9besSl5I0QRr6l7X6L7XgftY
	wxLvzzwCVpjlDTOq3/jKfQn4L4UntxH05db71JwMds3BxTVxQrjmCx5OPuHnE+2VZT0x
	ZXNw==
Received: by 10.180.84.41 with SMTP id v9mr10612019wiy.8.1350108218155;
	Fri, 12 Oct 2012 23:03:38 -0700 (PDT)
Received: from [192.168.1.69]
	(host86-183-156-141.range86-183.btcentralplus.com. [86.183.156.141])
	by mx.google.com with ESMTPS id cu1sm1201407wib.6.2012.10.12.23.03.36
	(version=SSLv3 cipher=OTHER); Fri, 12 Oct 2012 23:03:37 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Sat, 13 Oct 2012 07:03:30 +0100
From: Keir Fraser 
To: Mukesh Rathor , tupeng212 
Message-ID: 
Thread-Topic: [Xen-devel] alloc_heap_pages is low efficient with more CPUs
Thread-Index: Ac2pCHflfx8hdg+JxEacF67a9ay1yg==
In-Reply-To: <20121012153925.012846e4@mantra.us.oracle.com>
Mime-version: 1.0
Cc: xen-devel 
Subject: Re: [Xen-devel] alloc_heap_pages is low efficient with more CPUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/10/2012 23:39, "Mukesh Rathor"  wrote:

> On Fri, 12 Oct 2012 20:24:16 +0800
> tupeng212  wrote:
> 
>> With 16 CPUs you find domain startup takes 3s always.
>> :No
>> With 16CPUs, first 0.3s, second 3s
>> With 64CPUs, first 3s, second 30s.
>> 
>> With 64 CPUs you find it takes 3s first time, then 30s in future?
>> : Yes
> 
> ...........
> 
> I had seen this a while ago, it was always page scrubbing. That
> algoright was changed IIRC, so not sure if still could be the cause.

Tupeng,

If the tlbflush_filter() and cpumask_or() lines are commented out from the
if(need_tlbflush) block in alloc_heap_pages(), what are the domain creation
times like then? By the way it looks like you are not using xen-unstable or
xen-4.2, can you try with one of these later versions of Xen?

 -- Keir

> My 2 cents,
> thanks
> Mukesh



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 13 06:04:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Oct 2012 06:04:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMup3-00063V-Mk; Sat, 13 Oct 2012 06:03:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMup1-00063Q-QA
	for xen-devel@lists.xen.org; Sat, 13 Oct 2012 06:03:40 +0000
Received: from [85.158.138.51:10734] by server-7.bemta-3.messagelabs.com id
	30/66-06991-B3409705; Sat, 13 Oct 2012 06:03:39 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1350108218!32425874!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19125 invoked from network); 13 Oct 2012 06:03:38 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Oct 2012 06:03:38 -0000
Received: by mail-wi0-f173.google.com with SMTP id hm4so140094wib.14
	for ; Fri, 12 Oct 2012 23:03:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=CTDCFFNy9vZGo7vKTTDHDDlnFLQPNorMerYo0hHzo+s=;
	b=CzoEde5IuspGPg1pCBtI4sAh4QPTz01X+v+H5Uapxegy6YLGcPwBbe2vyrEYJct1na
	1shLaVmw6nQ5z60eFNuYjsbgGJpWYKMc3+b01b4Kre/Xtu/+GgPbj20GsmJLB9iacYmE
	Ge8LuhVNuzw+rCVZQFWR5IT1ISnKuCO+rQfyuhpTJLxraA0ezu7UVDMZP2wKBwNnIEMb
	dzOs+kBtq6zz+8AGhiHqYiaEfo0FvT250qqzY3n9ycNG9besSl5I0QRr6l7X6L7XgftY
	wxLvzzwCVpjlDTOq3/jKfQn4L4UntxH05db71JwMds3BxTVxQrjmCx5OPuHnE+2VZT0x
	ZXNw==
Received: by 10.180.84.41 with SMTP id v9mr10612019wiy.8.1350108218155;
	Fri, 12 Oct 2012 23:03:38 -0700 (PDT)
Received: from [192.168.1.69]
	(host86-183-156-141.range86-183.btcentralplus.com. [86.183.156.141])
	by mx.google.com with ESMTPS id cu1sm1201407wib.6.2012.10.12.23.03.36
	(version=SSLv3 cipher=OTHER); Fri, 12 Oct 2012 23:03:37 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Sat, 13 Oct 2012 07:03:30 +0100
From: Keir Fraser 
To: Mukesh Rathor , tupeng212 
Message-ID: 
Thread-Topic: [Xen-devel] alloc_heap_pages is low efficient with more CPUs
Thread-Index: Ac2pCHflfx8hdg+JxEacF67a9ay1yg==
In-Reply-To: <20121012153925.012846e4@mantra.us.oracle.com>
Mime-version: 1.0
Cc: xen-devel 
Subject: Re: [Xen-devel] alloc_heap_pages is low efficient with more CPUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/10/2012 23:39, "Mukesh Rathor"  wrote:

> On Fri, 12 Oct 2012 20:24:16 +0800
> tupeng212  wrote:
> 
>> With 16 CPUs you find domain startup takes 3s always.
>> :No
>> With 16CPUs, first 0.3s, second 3s
>> With 64CPUs, first 3s, second 30s.
>> 
>> With 64 CPUs you find it takes 3s first time, then 30s in future?
>> : Yes
> 
> ...........
> 
> I had seen this a while ago, it was always page scrubbing. That
> algoright was changed IIRC, so not sure if still could be the cause.

Tupeng,

If the tlbflush_filter() and cpumask_or() lines are commented out from the
if(need_tlbflush) block in alloc_heap_pages(), what are the domain creation
times like then? By the way it looks like you are not using xen-unstable or
xen-4.2, can you try with one of these later versions of Xen?

 -- Keir

> My 2 cents,
> thanks
> Mukesh



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 13 06:47:33 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Oct 2012 06:47:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMvUy-0006GX-Av; Sat, 13 Oct 2012 06:47:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMvUx-0006GS-2v
	for xen-devel@lists.xen.org; Sat, 13 Oct 2012 06:46:59 +0000
Received: from [85.158.143.99:28059] by server-3.bemta-4.messagelabs.com id
	C3/F7-10075-26E09705; Sat, 13 Oct 2012 06:46:58 +0000
X-Env-Sender: tupeng212@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1350110815!33939200!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_50_60,HTML_MESSAGE,
	MAILTO_TO_SPAM_ADDR,MIME_BOUND_NEXTPART,ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29313 invoked from network); 13 Oct 2012 06:46:57 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Oct 2012 06:46:57 -0000
Received: by mail-pb0-f45.google.com with SMTP id rp2so3553180pbb.32
	for ; Fri, 12 Oct 2012 23:46:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=date:from:to:cc:reply-to:subject:references:x-priority:x-guid
	:x-has-attach:x-mailer:mime-version:message-id:content-type;
	bh=ffumLQxBAWG/cxxaOwsD+Kz/78owlJG1eZ1MsTpgIPc=;
	b=e7jCKO7vVmprbUqsYpjkuYzMTMuiXDBZCdgYhULrJrxvUtEP2WNnO9O0epNfs59q6X
	fQmSdsi+Pp3o4j2jozGnRq9nxecXEs+LUF6puoCgtEZ+JsleqmFvg81TLw5WGm21cEM1
	U31aYNfZq+ZtEJACJ8lbrX2i1ogRO5QdbPVvHFIECZkIKmD7znu+Uk60UjdHSZtqTkrK
	2SCfqS+kTV61BGhZw+d9cGycDTcIAdMlVqO+DinTUklHmuht5HoALcHlZ4wRE4ZJK7xV
	vlkEvWsqSfmkpNzsMePUlBKgqFI0Rrw8S1HONqDe2mC6r4PmkUfxMJxcgX+jaVo78era
	nNHA==
Received: by 10.68.200.72 with SMTP id jq8mr19995941pbc.38.1350110814906;
	Fri, 12 Oct 2012 23:46:54 -0700 (PDT)
Received: from root ([183.128.153.197])
	by mx.google.com with ESMTPS id c1sm5552366pay.19.2012.10.12.23.46.52
	(version=SSLv3 cipher=OTHER); Fri, 12 Oct 2012 23:46:54 -0700 (PDT)
Date: Sat, 13 Oct 2012 14:46:54 +0800
From: tupeng212 
To: "Keir Fraser" 
References: 
X-Priority: 3
X-GUID: 92108DFE-140A-4514-9B46-3BFF88DD1B03
X-Has-Attach: no
X-Mailer: Foxmail 7.0.1.87[cn]
Mime-Version: 1.0
Message-ID: <2012101314464865629623@gmail.com>
Cc: xen-devel 
Subject: Re: [Xen-devel] alloc_heap_pages is low efficient with more CPUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: tupeng212 
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1305624968587899190=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.

--===============1305624968587899190==
Content-Type: multipart/alternative;
	boundary="----=_001_NextPart606012520113_=----"

This is a multi-part message in MIME format.

------=_001_NextPart606012520113_=----
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64

V2hhdCBpZiB5b3UgcmVwbGFjZSB0bGJmbHVzaF9maWx0ZXIoKSBjYWxsIHdpdGggY3B1c19jbGVh
cigmZXh0cmFfY3B1c19tYXNrKT8gDQo6ICB5b3UgbWVhbiBqdXN0IGNsZWFyIGl0LCAgbWF5YmUg
YSBsaXR0bGUgdmlvbGVudC4uLCAgeW91ICdkIGxpa2UgdG8gZG8gaXQgYXQgYW55IG90aGVyIHBs
YWNlLg0KDQpJIGFzc3VtZSB5b3Ugc2VlIGxvdHMgb2YgbG9vcGluZyBpbiBvbmUgb2YgdGhvc2Ug
dHdvIGZ1bmN0aW9ucywgYnV0IG9ubHkgc2luZ2xlLXBhZ2UtYXQtYS10aW1lIGNhbGxzIGludG8g
YWxsb2NfZG9taGVhcF9wYWdlcygpLT5hbGxvY19oZWFwX3BhZ2VzKCk/DQo6ICBJbiBwb3B1bGF0
ZV9waHlzbWFwLCAgYWxsIHBhZ2VzIGFyZSAyTSBzaXplLCANCnN0YXRpYyB2b2lkIHBvcHVsYXRl
X3BoeXNtYXAoc3RydWN0IG1lbW9wX2FyZ3MgKmEpIA0Kew0KICAgIGZvciAoIGkgPSBhLT5ucl9k
b25lOyBpIDwgYS0+bnJfZXh0ZW50czsgaSsrICkNCiAgICB7DQpwYWdlID0gYWxsb2NfZG9taGVh
cF9wYWdlcyhkLCBhLT5leHRlbnRfb3JkZXIsIGEtPm1lbWZsYWdzKSAtPmFsbG9jX2hlYXBfcGFn
ZXMgOyAgLy9hLT5leHRlbnRfb3JkZXIgPSA5LCBhbHdheXMgMk0gc2l6ZQ0KfQ0KLy95b3UgbWVh
biBtb3ZlIHRoYXQgYmxvY2sgYW5kIFRMQi1mbHVzaCBoZXJlIHRvIGF2b2lkIGZvciBsb29wID8N
Cn0NCg0KDQoNCnR1cGVuZzIxMg0KDQpGcm9tOiBLZWlyIEZyYXNlcg0KRGF0ZTogMjAxMi0xMC0x
MyAxNDozMA0KVG86IHR1cGVuZzIxMg0KU3ViamVjdDogUmU6IFtYZW4tZGV2ZWxdIGFsbG9jX2hl
YXBfcGFnZXMgaXMgbG93IGVmZmljaWVudCB3aXRoIG1vcmUgQ1BVcw0KV2hhdCBpZiB5b3UgcmVw
bGFjZSB0bGJmbHVzaF9maWx0ZXIoKSBjYWxsIHdpdGggY3B1c19jbGVhcigmZXh0cmFfY3B1c19t
YXNrKT8gU2VlbXMgYSBiaXQgc2lsbHkgdG8gZG8sIGJ1dCBJ4oCZZCBsaWtlIHRvIGtub3cgaG93
IG11Y2ggYSBmZXcgY3B1bWFzayBvcGVyYXRpb25zIHBlciBwYWdlIGlzIGNvc3RpbmcgKG1vc3Qg
YXJlIG9mIGNvdXJzZSBtdWNoIHF1aWNrZXIgdGhhbiB0bGJmbHVzaF9maWx0ZXIgYXMgdGhleSBv
cGVyYXRlIG9uIDY0IGJpdHMgcGVyIGl0ZXJhdGlvbiwgcmF0aGVyIHRoYW4gb25lIGJpdCBwZXIg
aXRlcmF0aW9uKS4NCg0KSWYgdGhhdCBpcyBzdWl0YWJseSBmYXN0LCBJIHRoaW5rIHdlIGNhbiBo
YXZlIGEgZ28gYXQgZml4aW5nIHRoaXMgYnkgcHVsbGluZyB0aGUgVExCLWZsdXNoIGxvZ2ljIG91
dCBvZiBhbGxvY19oZWFwX3BhZ2VzKCkgYW5kIGludG8gdGhlIGxvb3BzIGluIGluY3Jld2FzZV9y
ZXNlcnZhdGlvbigpIGFuZCBwb3B1bGF0ZV9waHlzbWFwKCkgaW4gY29tbW9uL21lbW9yeS5jLiBJ
IGFzc3VtZSB5b3Ugc2VlIGxvdHMgb2YgbG9vcGluZyBpbiBvbmUgb2YgdGhvc2UgdHdvIGZ1bmN0
aW9ucywgYnV0IG9ubHkgc2luZ2xlLXBhZ2UtYXQtYS10aW1lIGNhbGxzIGludG8gYWxsb2NfZG9t
aGVhcF9wYWdlcygpLT5hbGxvY19oZWFwX3BhZ2VzKCk/DQoNCiAgLS0gS2Vpcg0KDQpPbiAxMy8x
MC8yMDEyIDA3OjIxLCAidHVwZW5nMjEyIiA8dHVwZW5nMjEyQGdtYWlsLmNvbT4gd3JvdGU6DQoN
Cg0KSWYgdGhlIHRsYmZsdXNoX2ZpbHRlcigpIGFuZCBjcHVtYXNrX29yKCkgbGluZXMgYXJlIGNv
bW1lbnRlZCBvdXQgZnJvbSB0aGUNCmlmKG5lZWRfdGxiZmx1c2gpIGJsb2NrIGluIGFsbG9jX2hl
YXBfcGFnZXMoKSwgd2hhdCBhcmUgdGhlIGRvbWFpbiBjcmVhdGlvbg0KdGltZXMgbGlrZSB0aGVu
PyANCjogWW91IG1lYW4gcmVtb3ZpbmcgdGhlc2UgY29kZSBmcm9tIGFsbG9jX2hlYXBfcGFnZXMs
IHRoZW4gdHJ5IGl0Lg0KSSBkaWRuJ3QgZG8gaXQgYXMgeW91IHNhaWQsIGJ1dCBJIGNhbGN1bGF0
ZWQgdGhlIHdob2xlIHRpbWUgb2YgaWYobmVlZF90bGJmbHVzaCkgYmxvY2sNCmJ5IHVzaW5nIHRp
bWUxPU5PVygpIC4uLmJsb2NrIC4uLiB0aW1lMj1OT1coKSwgdGltZT10aW1lMi10aW1lMSwgaXRz
IHVuaXQgaXMgbnMsIGFuZCBzID0gbnMgKiAxMF45DQppdCBvY2N1cHkgaGlnaCByYXRlIG9mIHRo
ZSB3aG9sZSB0aW1lLiB3aG9sZSBzdGFydGluZyB0aW1lIGlzIDMwcywgdGhlbiB0aGlzIGJsb2Nr
IG1heSBiZSAyOXMuDQogDQpCeSB0aGUgd2F5IGl0IGxvb2tzIGxpa2UgeW91IGFyZSBub3QgdXNp
bmcgeGVuLXVuc3RhYmxlIG9yDQp4ZW4tNC4yLCBjYW4geW91IHRyeSB3aXRoIG9uZSBvZiB0aGVz
ZSBsYXRlciB2ZXJzaW9ucyBvZiBYZW4/DQo6IGZvcnR1bmF0ZWx5LCBvdGhlciBncm91cHMgaGF2
ZSB0byB1c2UgeGVuLTQuMiwgd2UgaGF2ZSByZXBlYXRlZCB0aGlzIGV4cGVyaW1lbnQgb24gDQp0
aGF0IHNvdXJjZSBjb2RlIHRvbywgaXQgY2hhbmdlZCBub3RoaW5nLCB0aW1lIGlzIHN0aWxsIHZl
cnkgbG9uZyBpbiBzZWNvbmQgc3RhcnRpbmcuDQogDQoNCg0KdHVwZW5nDQogDQog

------=_001_NextPart606012520113_=----
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

=EF=BB=BF
Re: [Xen-devel] alloc_heap_pages is low efficient with =
more CPUs






What if you repl=
ace=20
tlbflush_filter() call with cpus_clear(&extra_cpus_mask)?=20



:  you mean=
 just=20
clear it,  maybe a little violent..,  you 'd like to do it at an=
y=20
other place.


&n=
bsp;


I assume you see=
 lots of=20
looping in one of those two functions, but only single-page-at-a-time call=
s into=20
alloc_domheap_pages()->alloc_heap_pages()?
:  In populate_physmap=
, =20
all pages are 2M size, 


static void populate_physmap(struct memop_args *a=
)=20



{




    for ( i =3D a->nr_done=
; i < a->nr_extents; i++ )


    {

page =3D alloc_domheap_pages(d, =
a->extent_order, a->memflags)=20
->alloc_heap_pages ;  //a->extent_order =3D 9, always 2M size

}


//you mean move that block and TLB-flush h=
ere to=20
avoid for loop ?


}





tupeng212


 





Date: 2012-10-13 14:30


To: tupeng212<=
/DIV>

Subject: Re: [Xen-devel] alloc_heap_pages is low efficien=
t with=20
more CPUs




tupeng212@gmail.com>=20
wrote:



If the=20
  tlbflush_filter() and cpumask_or() lines are commented out from=20
  the
if(need_tlbflush) block in alloc_heap_pages(), what are the domai=
n=20
  creation
times like then? 
: You mean removing these code from=20
  alloc_heap_pages, then try it.
I didn't do it as you said, but I calc=
ulated=20
  the whole time of if(need_tlbflush) block
by using time1=3DNOW() ...b=
lock ...=20
  time2=3DNOW(), time=3Dtime2-time1, its unit is ns, and s =3D ns * 10^9it occupy=20
  high rate of the whole time. whole starting time is 30s, then this block=
 may=20
  be 29s.
 
By the way it looks like you are not using xen-unst=
able=20
  or
xen-4.2, can you try with one of these later versions of Xen?
:=
=20
  fortunately, other groups have to use xen-4.2, we have repeated this=20
  experiment on 
that source code too, it changed nothing, time is stil=
l very=20
  long in second starting.
 

  

  tupeng
 
 



------=_001_NextPart606012520113_=------



--===============1305624968587899190==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1305624968587899190==--



From xen-devel-bounces@lists.xen.org Sat Oct 13 06:47:33 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Oct 2012 06:47:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMvUy-0006GX-Av; Sat, 13 Oct 2012 06:47:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMvUx-0006GS-2v
	for xen-devel@lists.xen.org; Sat, 13 Oct 2012 06:46:59 +0000
Received: from [85.158.143.99:28059] by server-3.bemta-4.messagelabs.com id
	C3/F7-10075-26E09705; Sat, 13 Oct 2012 06:46:58 +0000
X-Env-Sender: tupeng212@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1350110815!33939200!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_50_60,HTML_MESSAGE,
	MAILTO_TO_SPAM_ADDR,MIME_BOUND_NEXTPART,ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29313 invoked from network); 13 Oct 2012 06:46:57 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Oct 2012 06:46:57 -0000
Received: by mail-pb0-f45.google.com with SMTP id rp2so3553180pbb.32
	for ; Fri, 12 Oct 2012 23:46:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=date:from:to:cc:reply-to:subject:references:x-priority:x-guid
	:x-has-attach:x-mailer:mime-version:message-id:content-type;
	bh=ffumLQxBAWG/cxxaOwsD+Kz/78owlJG1eZ1MsTpgIPc=;
	b=e7jCKO7vVmprbUqsYpjkuYzMTMuiXDBZCdgYhULrJrxvUtEP2WNnO9O0epNfs59q6X
	fQmSdsi+Pp3o4j2jozGnRq9nxecXEs+LUF6puoCgtEZ+JsleqmFvg81TLw5WGm21cEM1
	U31aYNfZq+ZtEJACJ8lbrX2i1ogRO5QdbPVvHFIECZkIKmD7znu+Uk60UjdHSZtqTkrK
	2SCfqS+kTV61BGhZw+d9cGycDTcIAdMlVqO+DinTUklHmuht5HoALcHlZ4wRE4ZJK7xV
	vlkEvWsqSfmkpNzsMePUlBKgqFI0Rrw8S1HONqDe2mC6r4PmkUfxMJxcgX+jaVo78era
	nNHA==
Received: by 10.68.200.72 with SMTP id jq8mr19995941pbc.38.1350110814906;
	Fri, 12 Oct 2012 23:46:54 -0700 (PDT)
Received: from root ([183.128.153.197])
	by mx.google.com with ESMTPS id c1sm5552366pay.19.2012.10.12.23.46.52
	(version=SSLv3 cipher=OTHER); Fri, 12 Oct 2012 23:46:54 -0700 (PDT)
Date: Sat, 13 Oct 2012 14:46:54 +0800
From: tupeng212 
To: "Keir Fraser" 
References: 
X-Priority: 3
X-GUID: 92108DFE-140A-4514-9B46-3BFF88DD1B03
X-Has-Attach: no
X-Mailer: Foxmail 7.0.1.87[cn]
Mime-Version: 1.0
Message-ID: <2012101314464865629623@gmail.com>
Cc: xen-devel 
Subject: Re: [Xen-devel] alloc_heap_pages is low efficient with more CPUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: tupeng212 
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1305624968587899190=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.

--===============1305624968587899190==
Content-Type: multipart/alternative;
	boundary="----=_001_NextPart606012520113_=----"

This is a multi-part message in MIME format.

------=_001_NextPart606012520113_=----
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64

V2hhdCBpZiB5b3UgcmVwbGFjZSB0bGJmbHVzaF9maWx0ZXIoKSBjYWxsIHdpdGggY3B1c19jbGVh
cigmZXh0cmFfY3B1c19tYXNrKT8gDQo6ICB5b3UgbWVhbiBqdXN0IGNsZWFyIGl0LCAgbWF5YmUg
YSBsaXR0bGUgdmlvbGVudC4uLCAgeW91ICdkIGxpa2UgdG8gZG8gaXQgYXQgYW55IG90aGVyIHBs
YWNlLg0KDQpJIGFzc3VtZSB5b3Ugc2VlIGxvdHMgb2YgbG9vcGluZyBpbiBvbmUgb2YgdGhvc2Ug
dHdvIGZ1bmN0aW9ucywgYnV0IG9ubHkgc2luZ2xlLXBhZ2UtYXQtYS10aW1lIGNhbGxzIGludG8g
YWxsb2NfZG9taGVhcF9wYWdlcygpLT5hbGxvY19oZWFwX3BhZ2VzKCk/DQo6ICBJbiBwb3B1bGF0
ZV9waHlzbWFwLCAgYWxsIHBhZ2VzIGFyZSAyTSBzaXplLCANCnN0YXRpYyB2b2lkIHBvcHVsYXRl
X3BoeXNtYXAoc3RydWN0IG1lbW9wX2FyZ3MgKmEpIA0Kew0KICAgIGZvciAoIGkgPSBhLT5ucl9k
b25lOyBpIDwgYS0+bnJfZXh0ZW50czsgaSsrICkNCiAgICB7DQpwYWdlID0gYWxsb2NfZG9taGVh
cF9wYWdlcyhkLCBhLT5leHRlbnRfb3JkZXIsIGEtPm1lbWZsYWdzKSAtPmFsbG9jX2hlYXBfcGFn
ZXMgOyAgLy9hLT5leHRlbnRfb3JkZXIgPSA5LCBhbHdheXMgMk0gc2l6ZQ0KfQ0KLy95b3UgbWVh
biBtb3ZlIHRoYXQgYmxvY2sgYW5kIFRMQi1mbHVzaCBoZXJlIHRvIGF2b2lkIGZvciBsb29wID8N
Cn0NCg0KDQoNCnR1cGVuZzIxMg0KDQpGcm9tOiBLZWlyIEZyYXNlcg0KRGF0ZTogMjAxMi0xMC0x
MyAxNDozMA0KVG86IHR1cGVuZzIxMg0KU3ViamVjdDogUmU6IFtYZW4tZGV2ZWxdIGFsbG9jX2hl
YXBfcGFnZXMgaXMgbG93IGVmZmljaWVudCB3aXRoIG1vcmUgQ1BVcw0KV2hhdCBpZiB5b3UgcmVw
bGFjZSB0bGJmbHVzaF9maWx0ZXIoKSBjYWxsIHdpdGggY3B1c19jbGVhcigmZXh0cmFfY3B1c19t
YXNrKT8gU2VlbXMgYSBiaXQgc2lsbHkgdG8gZG8sIGJ1dCBJ4oCZZCBsaWtlIHRvIGtub3cgaG93
IG11Y2ggYSBmZXcgY3B1bWFzayBvcGVyYXRpb25zIHBlciBwYWdlIGlzIGNvc3RpbmcgKG1vc3Qg
YXJlIG9mIGNvdXJzZSBtdWNoIHF1aWNrZXIgdGhhbiB0bGJmbHVzaF9maWx0ZXIgYXMgdGhleSBv
cGVyYXRlIG9uIDY0IGJpdHMgcGVyIGl0ZXJhdGlvbiwgcmF0aGVyIHRoYW4gb25lIGJpdCBwZXIg
aXRlcmF0aW9uKS4NCg0KSWYgdGhhdCBpcyBzdWl0YWJseSBmYXN0LCBJIHRoaW5rIHdlIGNhbiBo
YXZlIGEgZ28gYXQgZml4aW5nIHRoaXMgYnkgcHVsbGluZyB0aGUgVExCLWZsdXNoIGxvZ2ljIG91
dCBvZiBhbGxvY19oZWFwX3BhZ2VzKCkgYW5kIGludG8gdGhlIGxvb3BzIGluIGluY3Jld2FzZV9y
ZXNlcnZhdGlvbigpIGFuZCBwb3B1bGF0ZV9waHlzbWFwKCkgaW4gY29tbW9uL21lbW9yeS5jLiBJ
IGFzc3VtZSB5b3Ugc2VlIGxvdHMgb2YgbG9vcGluZyBpbiBvbmUgb2YgdGhvc2UgdHdvIGZ1bmN0
aW9ucywgYnV0IG9ubHkgc2luZ2xlLXBhZ2UtYXQtYS10aW1lIGNhbGxzIGludG8gYWxsb2NfZG9t
aGVhcF9wYWdlcygpLT5hbGxvY19oZWFwX3BhZ2VzKCk/DQoNCiAgLS0gS2Vpcg0KDQpPbiAxMy8x
MC8yMDEyIDA3OjIxLCAidHVwZW5nMjEyIiA8dHVwZW5nMjEyQGdtYWlsLmNvbT4gd3JvdGU6DQoN
Cg0KSWYgdGhlIHRsYmZsdXNoX2ZpbHRlcigpIGFuZCBjcHVtYXNrX29yKCkgbGluZXMgYXJlIGNv
bW1lbnRlZCBvdXQgZnJvbSB0aGUNCmlmKG5lZWRfdGxiZmx1c2gpIGJsb2NrIGluIGFsbG9jX2hl
YXBfcGFnZXMoKSwgd2hhdCBhcmUgdGhlIGRvbWFpbiBjcmVhdGlvbg0KdGltZXMgbGlrZSB0aGVu
PyANCjogWW91IG1lYW4gcmVtb3ZpbmcgdGhlc2UgY29kZSBmcm9tIGFsbG9jX2hlYXBfcGFnZXMs
IHRoZW4gdHJ5IGl0Lg0KSSBkaWRuJ3QgZG8gaXQgYXMgeW91IHNhaWQsIGJ1dCBJIGNhbGN1bGF0
ZWQgdGhlIHdob2xlIHRpbWUgb2YgaWYobmVlZF90bGJmbHVzaCkgYmxvY2sNCmJ5IHVzaW5nIHRp
bWUxPU5PVygpIC4uLmJsb2NrIC4uLiB0aW1lMj1OT1coKSwgdGltZT10aW1lMi10aW1lMSwgaXRz
IHVuaXQgaXMgbnMsIGFuZCBzID0gbnMgKiAxMF45DQppdCBvY2N1cHkgaGlnaCByYXRlIG9mIHRo
ZSB3aG9sZSB0aW1lLiB3aG9sZSBzdGFydGluZyB0aW1lIGlzIDMwcywgdGhlbiB0aGlzIGJsb2Nr
IG1heSBiZSAyOXMuDQogDQpCeSB0aGUgd2F5IGl0IGxvb2tzIGxpa2UgeW91IGFyZSBub3QgdXNp
bmcgeGVuLXVuc3RhYmxlIG9yDQp4ZW4tNC4yLCBjYW4geW91IHRyeSB3aXRoIG9uZSBvZiB0aGVz
ZSBsYXRlciB2ZXJzaW9ucyBvZiBYZW4/DQo6IGZvcnR1bmF0ZWx5LCBvdGhlciBncm91cHMgaGF2
ZSB0byB1c2UgeGVuLTQuMiwgd2UgaGF2ZSByZXBlYXRlZCB0aGlzIGV4cGVyaW1lbnQgb24gDQp0
aGF0IHNvdXJjZSBjb2RlIHRvbywgaXQgY2hhbmdlZCBub3RoaW5nLCB0aW1lIGlzIHN0aWxsIHZl
cnkgbG9uZyBpbiBzZWNvbmQgc3RhcnRpbmcuDQogDQoNCg0KdHVwZW5nDQogDQog

------=_001_NextPart606012520113_=----
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

=EF=BB=BF
Re: [Xen-devel] alloc_heap_pages is low efficient with =
more CPUs






What if you repl=
ace=20
tlbflush_filter() call with cpus_clear(&extra_cpus_mask)?=20



:  you mean=
 just=20
clear it,  maybe a little violent..,  you 'd like to do it at an=
y=20
other place.


&n=
bsp;


I assume you see=
 lots of=20
looping in one of those two functions, but only single-page-at-a-time call=
s into=20
alloc_domheap_pages()->alloc_heap_pages()?
:  In populate_physmap=
, =20
all pages are 2M size, 


static void populate_physmap(struct memop_args *a=
)=20



{




    for ( i =3D a->nr_done=
; i < a->nr_extents; i++ )


    {

page =3D alloc_domheap_pages(d, =
a->extent_order, a->memflags)=20
->alloc_heap_pages ;  //a->extent_order =3D 9, always 2M size

}


//you mean move that block and TLB-flush h=
ere to=20
avoid for loop ?


}





tupeng212


 





Date: 2012-10-13 14:30


To: tupeng212<=
/DIV>

Subject: Re: [Xen-devel] alloc_heap_pages is low efficien=
t with=20
more CPUs




tupeng212@gmail.com>=20
wrote:



If the=20
  tlbflush_filter() and cpumask_or() lines are commented out from=20
  the
if(need_tlbflush) block in alloc_heap_pages(), what are the domai=
n=20
  creation
times like then? 
: You mean removing these code from=20
  alloc_heap_pages, then try it.
I didn't do it as you said, but I calc=
ulated=20
  the whole time of if(need_tlbflush) block
by using time1=3DNOW() ...b=
lock ...=20
  time2=3DNOW(), time=3Dtime2-time1, its unit is ns, and s =3D ns * 10^9it occupy=20
  high rate of the whole time. whole starting time is 30s, then this block=
 may=20
  be 29s.
 
By the way it looks like you are not using xen-unst=
able=20
  or
xen-4.2, can you try with one of these later versions of Xen?
:=
=20
  fortunately, other groups have to use xen-4.2, we have repeated this=20
  experiment on 
that source code too, it changed nothing, time is stil=
l very=20
  long in second starting.
 

  

  tupeng
 
 



------=_001_NextPart606012520113_=------



--===============1305624968587899190==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1305624968587899190==--



From xen-devel-bounces@lists.xen.org Sat Oct 13 07:20:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Oct 2012 07:20:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMw19-0006dZ-8m; Sat, 13 Oct 2012 07:20:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMw17-0006dU-GP
	for xen-devel@lists.xen.org; Sat, 13 Oct 2012 07:20:13 +0000
Received: from [85.158.143.99:61698] by server-1.bemta-4.messagelabs.com id
	32/B5-19551-C2619705; Sat, 13 Oct 2012 07:20:12 +0000
X-Env-Sender: tupeng212@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1350112808!26957318!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=HTML_MESSAGE,
	MIME_BASE64_TEXT, MIME_BOUND_NEXTPART, ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP, spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25672 invoked from network); 13 Oct 2012 07:20:10 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Oct 2012 07:20:10 -0000
Received: by mail-pb0-f45.google.com with SMTP id rp2so3567444pbb.32
	for ; Sat, 13 Oct 2012 00:20:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=date:from:to:cc:reply-to:subject:references:x-priority:x-guid
	:x-has-attach:x-mailer:mime-version:message-id:content-type;
	bh=gZAvRdVVn4QsTtyyHY7VWlxXroD66ippzT5gOAGQrkk=;
	b=WBaAufdCyOpJxZDxLMw9a0QWfQI0VOH1RfIICvr8zRe/9hPHv9GvWL2FwtPSglsaPw
	fenIl9Luiyigimde35qriPNxZBnXtYpv5GB4G2XlxBI/9eZRTkkS6KFiLCPhaL/65X+i
	HCxi0uHzV8LGr4hXCeCO8Y4O5uCep9pwGamby1qIhGfLdt+OY5EPWKZe+HMvvUDutd30
	BBuyS8xUjC9VY/nTCddkgYdOUSI/ML65ZMCI/kBHJNkJKN7dyEUYbqXavOM//3fQ9h8/
	2xn/CjXlHR8dojNX19m0NtGd4A1nRK7kZcubBxU4Y/IQxECfrX+b4LvI4Zqzu9YSzt7N
	hpGw==
Received: by 10.66.79.166 with SMTP id k6mr17272366pax.25.1350112807650;
	Sat, 13 Oct 2012 00:20:07 -0700 (PDT)
Received: from root ([183.128.153.197])
	by mx.google.com with ESMTPS id vu7sm5668710pbc.9.2012.10.13.00.20.04
	(version=SSLv3 cipher=OTHER); Sat, 13 Oct 2012 00:20:06 -0700 (PDT)
Date: Sat, 13 Oct 2012 15:20:06 +0800
From: tupeng212 
To: "Keir Fraser" 
References: 
X-Priority: 3
X-GUID: D26C8FFD-2FAB-4E0A-AAE3-CCC7D502070B
X-Has-Attach: no
X-Mailer: Foxmail 7.0.1.87[cn]
Mime-Version: 1.0
Message-ID: <2012101315200385948426@gmail.com>
Cc: xen-devel 
Subject: Re: [Xen-devel] alloc_heap_pages is low efficient with more CPUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: tupeng212 
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============5113940801194745422=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.

--===============5113940801194745422==
Content-Type: multipart/alternative;
	boundary="----=_001_NextPart145575654011_=----"

This is a multi-part message in MIME format.

------=_001_NextPart145575654011_=----
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: base64

LyogQWxsb2NhdGUgMl5Ab3JkZXIgY29udGlndW91cyBwYWdlcy4gKi8NCnN0YXRpYyBzdHJ1Y3Qg
cGFnZV9pbmZvICphbGxvY19oZWFwX3BhZ2VzKA0KICAgIHVuc2lnbmVkIGludCB6b25lX2xvLCB1
bnNpZ25lZCBpbnQgem9uZV9oaSwNCiAgICB1bnNpZ25lZCBpbnQgbm9kZSwgdW5zaWduZWQgaW50
IG9yZGVyLCB1bnNpZ25lZCBpbnQgbWVtZmxhZ3MpDQp7DQogICAgY3B1c19jbGVhcihtYXNrKTsN
CiAgICBmb3IgKCBpID0gMDsgaSA8ICgxIDw8IG9yZGVyKTsgaSsrICkNCiAgICB7ICAgIA0KICAg
ICAgICBpZiAoIHBnW2ldLnUuZnJlZS5uZWVkX3RsYmZsdXNoICkNCiAgICAgICAgew0KICAgICAg
ICAgICAgLyogQWRkIGluIGV4dHJhIENQVXMgdGhhdCBuZWVkIGZsdXNoaW5nIGJlY2F1c2Ugb2Yg
dGhpcyBwYWdlLiAqLw0KICAgICAgICAgICAgY3B1c19hbmRub3QoZXh0cmFfY3B1c19tYXNrLCBj
cHVfb25saW5lX21hcCwgbWFzayk7DQogICAgICAgICAgICB0bGJmbHVzaF9maWx0ZXIoZXh0cmFf
Y3B1c19tYXNrLCBwZ1tpXS50bGJmbHVzaF90aW1lc3RhbXApOw0KICAgICAgICAgICAgY3B1c19v
cihtYXNrLCBtYXNrLCBleHRyYV9jcHVzX21hc2spOw0KICAgICAgICB9DQogICAgfQ0KICAgIGlm
ICggdW5saWtlbHkoIWNwdXNfZW1wdHkobWFzaykpICkNCiAgICB7DQogICAgICAgIHBlcmZjX2lu
Y3IobmVlZF9mbHVzaF90bGJfZmx1c2gpOw0KICAgICAgICBmbHVzaF90bGJfbWFzaygmbWFzayk7
DQogICAgfQ0KICAgIHJldHVybiBwZzsNCn0NCg0KSXMgdGhpcyBlcXVhbCB0byA6IGluIHBnWzE8
PG9yZGVyLTFdLnUuZnJlZS5uZWVkX3RsYmZsdXNoLCBpZiB3ZSBjb21wdXRlIG1hc2s9MCwgdGhl
biBmbHVzaCBUTEIgbWFzayA/IA==

------=_001_NextPart145575654011_=----
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable











/* Allocate 2^@order contiguous pages. */

static struct page_info *alloc_heap_pages(


    unsigned int zone_lo, unsigned=
 int zone_hi,


    unsigned int node, unsigned&nb=
sp;int order, unsigned int memflags)


{




    cpus_clear(mask);


    for ( i =3D 0; i&nbs=
p;< (1 << order); i++ )


    {    


        if ( pg[i].=
u.free.need_tlbflush )


        {


           &nb=
sp;/* Add in extra CPUs that need flush=
ing because of this page. */


           &nb=
sp;cpus_andnot(extra_cpus_mask, cpu_online_map, mask);


           &nb=
sp;tlbflush_filter(extra_cpus_mask, pg[i].tlbflush_timestamp);


           &nb=
sp;cpus_or(mask, mask, extra_cpus_mask);


        }


    }




    if ( unlikely(!cpus_empty(mask))&nb=
sp;)


    {


        perfc_incr(need_flush=
_tlb_flush);


        flush_tlb_mask(&m=
ask);


    }


    return pg;


}


 


Is this equal to : in pg[1<<order-1].u.free.need_tlbflush, if=
 we=20
compute mask=3D0, then flush TLB mask ? 


 


------=_001_NextPart145575654011_=------



--===============5113940801194745422==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5113940801194745422==--



From xen-devel-bounces@lists.xen.org Sat Oct 13 07:20:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Oct 2012 07:20:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMw19-0006dZ-8m; Sat, 13 Oct 2012 07:20:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMw17-0006dU-GP
	for xen-devel@lists.xen.org; Sat, 13 Oct 2012 07:20:13 +0000
Received: from [85.158.143.99:61698] by server-1.bemta-4.messagelabs.com id
	32/B5-19551-C2619705; Sat, 13 Oct 2012 07:20:12 +0000
X-Env-Sender: tupeng212@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1350112808!26957318!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=HTML_MESSAGE,
	MIME_BASE64_TEXT, MIME_BOUND_NEXTPART, ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP, spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25672 invoked from network); 13 Oct 2012 07:20:10 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Oct 2012 07:20:10 -0000
Received: by mail-pb0-f45.google.com with SMTP id rp2so3567444pbb.32
	for ; Sat, 13 Oct 2012 00:20:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=date:from:to:cc:reply-to:subject:references:x-priority:x-guid
	:x-has-attach:x-mailer:mime-version:message-id:content-type;
	bh=gZAvRdVVn4QsTtyyHY7VWlxXroD66ippzT5gOAGQrkk=;
	b=WBaAufdCyOpJxZDxLMw9a0QWfQI0VOH1RfIICvr8zRe/9hPHv9GvWL2FwtPSglsaPw
	fenIl9Luiyigimde35qriPNxZBnXtYpv5GB4G2XlxBI/9eZRTkkS6KFiLCPhaL/65X+i
	HCxi0uHzV8LGr4hXCeCO8Y4O5uCep9pwGamby1qIhGfLdt+OY5EPWKZe+HMvvUDutd30
	BBuyS8xUjC9VY/nTCddkgYdOUSI/ML65ZMCI/kBHJNkJKN7dyEUYbqXavOM//3fQ9h8/
	2xn/CjXlHR8dojNX19m0NtGd4A1nRK7kZcubBxU4Y/IQxECfrX+b4LvI4Zqzu9YSzt7N
	hpGw==
Received: by 10.66.79.166 with SMTP id k6mr17272366pax.25.1350112807650;
	Sat, 13 Oct 2012 00:20:07 -0700 (PDT)
Received: from root ([183.128.153.197])
	by mx.google.com with ESMTPS id vu7sm5668710pbc.9.2012.10.13.00.20.04
	(version=SSLv3 cipher=OTHER); Sat, 13 Oct 2012 00:20:06 -0700 (PDT)
Date: Sat, 13 Oct 2012 15:20:06 +0800
From: tupeng212 
To: "Keir Fraser" 
References: 
X-Priority: 3
X-GUID: D26C8FFD-2FAB-4E0A-AAE3-CCC7D502070B
X-Has-Attach: no
X-Mailer: Foxmail 7.0.1.87[cn]
Mime-Version: 1.0
Message-ID: <2012101315200385948426@gmail.com>
Cc: xen-devel 
Subject: Re: [Xen-devel] alloc_heap_pages is low efficient with more CPUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: tupeng212 
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============5113940801194745422=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.

--===============5113940801194745422==
Content-Type: multipart/alternative;
	boundary="----=_001_NextPart145575654011_=----"

This is a multi-part message in MIME format.

------=_001_NextPart145575654011_=----
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: base64

LyogQWxsb2NhdGUgMl5Ab3JkZXIgY29udGlndW91cyBwYWdlcy4gKi8NCnN0YXRpYyBzdHJ1Y3Qg
cGFnZV9pbmZvICphbGxvY19oZWFwX3BhZ2VzKA0KICAgIHVuc2lnbmVkIGludCB6b25lX2xvLCB1
bnNpZ25lZCBpbnQgem9uZV9oaSwNCiAgICB1bnNpZ25lZCBpbnQgbm9kZSwgdW5zaWduZWQgaW50
IG9yZGVyLCB1bnNpZ25lZCBpbnQgbWVtZmxhZ3MpDQp7DQogICAgY3B1c19jbGVhcihtYXNrKTsN
CiAgICBmb3IgKCBpID0gMDsgaSA8ICgxIDw8IG9yZGVyKTsgaSsrICkNCiAgICB7ICAgIA0KICAg
ICAgICBpZiAoIHBnW2ldLnUuZnJlZS5uZWVkX3RsYmZsdXNoICkNCiAgICAgICAgew0KICAgICAg
ICAgICAgLyogQWRkIGluIGV4dHJhIENQVXMgdGhhdCBuZWVkIGZsdXNoaW5nIGJlY2F1c2Ugb2Yg
dGhpcyBwYWdlLiAqLw0KICAgICAgICAgICAgY3B1c19hbmRub3QoZXh0cmFfY3B1c19tYXNrLCBj
cHVfb25saW5lX21hcCwgbWFzayk7DQogICAgICAgICAgICB0bGJmbHVzaF9maWx0ZXIoZXh0cmFf
Y3B1c19tYXNrLCBwZ1tpXS50bGJmbHVzaF90aW1lc3RhbXApOw0KICAgICAgICAgICAgY3B1c19v
cihtYXNrLCBtYXNrLCBleHRyYV9jcHVzX21hc2spOw0KICAgICAgICB9DQogICAgfQ0KICAgIGlm
ICggdW5saWtlbHkoIWNwdXNfZW1wdHkobWFzaykpICkNCiAgICB7DQogICAgICAgIHBlcmZjX2lu
Y3IobmVlZF9mbHVzaF90bGJfZmx1c2gpOw0KICAgICAgICBmbHVzaF90bGJfbWFzaygmbWFzayk7
DQogICAgfQ0KICAgIHJldHVybiBwZzsNCn0NCg0KSXMgdGhpcyBlcXVhbCB0byA6IGluIHBnWzE8
PG9yZGVyLTFdLnUuZnJlZS5uZWVkX3RsYmZsdXNoLCBpZiB3ZSBjb21wdXRlIG1hc2s9MCwgdGhl
biBmbHVzaCBUTEIgbWFzayA/IA==

------=_001_NextPart145575654011_=----
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable











/* Allocate 2^@order contiguous pages. */

static struct page_info *alloc_heap_pages(


    unsigned int zone_lo, unsigned=
 int zone_hi,


    unsigned int node, unsigned&nb=
sp;int order, unsigned int memflags)


{




    cpus_clear(mask);


    for ( i =3D 0; i&nbs=
p;< (1 << order); i++ )


    {    


        if ( pg[i].=
u.free.need_tlbflush )


        {


           &nb=
sp;/* Add in extra CPUs that need flush=
ing because of this page. */


           &nb=
sp;cpus_andnot(extra_cpus_mask, cpu_online_map, mask);


           &nb=
sp;tlbflush_filter(extra_cpus_mask, pg[i].tlbflush_timestamp);


           &nb=
sp;cpus_or(mask, mask, extra_cpus_mask);


        }


    }




    if ( unlikely(!cpus_empty(mask))&nb=
sp;)


    {


        perfc_incr(need_flush=
_tlb_flush);


        flush_tlb_mask(&m=
ask);


    }


    return pg;


}


 


Is this equal to : in pg[1<<order-1].u.free.need_tlbflush, if=
 we=20
compute mask=3D0, then flush TLB mask ? 


 


------=_001_NextPart145575654011_=------



--===============5113940801194745422==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5113940801194745422==--



From xen-devel-bounces@lists.xen.org Sat Oct 13 09:00:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Oct 2012 09:00:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TMxZO-0007SG-JZ; Sat, 13 Oct 2012 08:59:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TMxZM-0007SB-LH
	for xen-devel@lists.xen.org; Sat, 13 Oct 2012 08:59:41 +0000
Received: from [85.158.139.83:41108] by server-13.bemta-5.messagelabs.com id
	F5/BB-29905-B7D29705; Sat, 13 Oct 2012 08:59:39 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1350118778!34122910!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	MAILTO_TO_SPAM_ADDR,MIME_QP_LONG_LINE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3681 invoked from network); 13 Oct 2012 08:59:38 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Oct 2012 08:59:38 -0000
Received: by mail-wi0-f173.google.com with SMTP id hm4so222503wib.14
	for ; Sat, 13 Oct 2012 01:59:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type;
	bh=OiKz+sqXG92SdIVffWQbN8qF1dukltfzs2aB0sHQCMY=;
	b=FZ0FDEVQhwGDua67So2hL359UOKSsKkhiF9Ry5DjgyI4mjkm0j5WOuMapmQQxAFrQT
	OFz5NXYDIkmhGmYc6HAQTA+fvpE2qakVmy4I9KZg/4mdbP5VYHDTacjdvJ578G6TgqVV
	c+QnR+WjPrgL9wcEDMlNKwuQpFFMlkk6VBQOsB7YdWr48n8mIHGjuoVTzhyEU1m0HYA3
	1ToB4NAB706XyWU2LN4Bwvx9tg3UUdbryMYUQ+wMxmGyyd6rchQc+xevvBGNIOayEg0D
	xSYx+BxhlBRjALEOVSvOlHK5DXf93DDT9C4/QcUQXmZ//gljHUazY2q1upsAq8xbA2on
	Q5Yg==
Received: by 10.180.79.202 with SMTP id l10mr11348199wix.9.1350118778256;
	Sat, 13 Oct 2012 01:59:38 -0700 (PDT)
Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com.
	[86.183.156.141])
	by mx.google.com with ESMTPS id p4sm2261239wix.0.2012.10.13.01.59.34
	(version=SSLv3 cipher=OTHER); Sat, 13 Oct 2012 01:59:36 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Sat, 13 Oct 2012 09:59:19 +0100
From: Keir Fraser 
To: tupeng212 
Message-ID: 
Thread-Topic: [Xen-devel] alloc_heap_pages is low efficient with more CPUs
Thread-Index: Ac2pIQeX6HxWHUTuf0G4n/Wqknktzg==
In-Reply-To: <2012101314464865629623@gmail.com>
Mime-version: 1.0
Content-type: multipart/mixed;
	boundary="B_3432967176_20080749"
Cc: xen-devel 
Subject: Re: [Xen-devel] alloc_heap_pages is low efficient with more CPUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3432967176_20080749
Content-type: multipart/alternative;
	boundary="B_3432967176_20047710"


--B_3432967176_20047710
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

If the allocations are 2M size, we can do better quite easily I think.
Please try the attached patch.

 -- Keir

On 13/10/2012 07:46, "tupeng212"  wrote:

> What if you replace tlbflush_filter() call with cpus_clear(&extra_cpus_ma=
sk)?
> :  you mean just clear it,  maybe a little violent..,  you 'd like to do =
it at
> any other place.
> =20
> I assume you see lots of looping in one of those two functions, but only
> single-page-at-a-time calls into alloc_domheap_pages()->alloc_heap_pages(=
)?
> :  In populate_physmap,  all pages are 2M size,
> static void populate_physmap(struct memop_args *a)
> {
>     for ( i =3D a->nr_done; i < a->nr_extents; i++ )
>     {
> page =3D alloc_domheap_pages(d, a->extent_order, a->memflags) ->alloc_heap_=
pages
> ;  //a->extent_order =3D 9, always 2M size
> }
> //you mean move that block and TLB-flush here to avoid for loop ?
> }
>=20
> tupeng212
> =20
> From: Keir Fraser 
> Date: 2012-10-13 14:30
> To: tupeng212 
> Subject: Re: [Xen-devel] alloc_heap_pages is low efficient with more CPUs
> What if you replace tlbflush_filter() call with cpus_clear(&extra_cpus_ma=
sk)?
> Seems a bit silly to do, but I=B9d like to know how much a few cpumask
> operations per page is costing (most are of course much quicker than
> tlbflush_filter as they operate on 64 bits per iteration, rather than one=
 bit
> per iteration).
>=20
> If that is suitably fast, I think we can have a go at fixing this by pull=
ing
> the TLB-flush logic out of alloc_heap_pages() and into the loops in
> increwase_reservation() and populate_physmap() in common/memory.c. I assu=
me
> you see lots of looping in one of those two functions, but only
> single-page-at-a-time calls into alloc_domheap_pages()->alloc_heap_pages(=
)?
>=20
>   -- Keir
>=20
> On 13/10/2012 07:21, "tupeng212"  wrote:
>=20
>> If the  tlbflush_filter() and cpumask_or() lines are commented out from =
 the
>> if(need_tlbflush) block in alloc_heap_pages(), what are the domain  crea=
tion
>> times like then?
>> : You mean removing these code from  alloc_heap_pages, then try it.
>> I didn't do it as you said, but I calculated  the whole time of
>> if(need_tlbflush) block
>> by using time1=3DNOW() ...block ...  time2=3DNOW(), time=3Dtime2-time1, its un=
it is
>> ns, and s =3D ns * 10^9
>> it occupy  high rate of the whole time. whole starting time is 30s, then=
 this
>> block may  be 29s.
>> =20
>> By the way it looks like you are not using xen-unstable  or
>> xen-4.2, can you try with one of these later versions of Xen?
>> :  fortunately, other groups have to use xen-4.2, we have repeated this
>> experiment on=20
>> that source code too, it changed nothing, time is still very  long in se=
cond
>> starting.
>> =20
>> =20
>>=20
>>  tupeng
>> =20
>> =20
>>=20
>=20


--B_3432967176_20047710
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable



Re: [Xen-devel] alloc_heap_pages is low efficient with more CPUs</TI=
TLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>If the allocations are 2M size, we can do better quite easily I think. Ple=
ase try the attached patch.<BR>
<BR>
 -- Keir<BR>
<BR>
On 13/10/2012 07:46, "tupeng212" <<a href=3D"tupeng212@gmail.com=
">tupeng212@gmail.com</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'><FONT COLOR=3D"#000080">What if you replace tlbflu=
sh_filter() call with cpus_clear(&extra_cpus_mask)? <BR>
:  you mean just clear it,  maybe a little violent..,  you '=
d like to do it at any other place.<BR>
</FONT></SPAN><FONT COLOR=3D"#000080"><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:1=
0pt'> <BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:11pt'>I assume you see lots of looping=
 in one of those two functions, but only single-page-at-a-time calls into al=
loc_domheap_pages()->alloc_heap_pages()?<BR>
:  In populate_physmap,  all pages are 2M size, <BR>
</SPAN><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'>static void populate_phy=
smap(struct memop_args *a) <BR>
{<BR>
    for ( i =3D a->nr_done; i < a->nr_extents; i=
++ )<BR>
    {<BR>
page =3D alloc_domheap_pages(d, a->extent_order, a->memflags) ->allo=
c_heap_pages ;  //a->extent_order =3D 9, always 2M size<BR>
}<BR>
//you mean move that block and TLB-flush here to avoid for loop ?<BR>
}<BR>
<HR ALIGN=3DLEFT SIZE=3D"1" WIDTH=3D"100%">tupeng212<BR>
 <BR>
</SPAN></FONT></FONT><FONT SIZE=3D"1"><SPAN STYLE=3D'font-size:9pt'><B>From:</B=
> Keir Fraser <<a href=3D"mailto:keir.xen@gmail.com">mailto:keir.xen@gmail.=
com</a>> <BR>
<B>Date:</B> 2012-10-13 14:30<BR>
<B>To:</B> tupeng212 <<a href=3D"mailto:tupeng212@gmail.com">mailto:tupeng=
212@gmail.com</a>> <BR>
<B>Subject:</B> Re: [Xen-devel] alloc_heap_pages is low efficient with more=
 CPUs<BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:11pt'>What if you replace tlbflush_fil=
ter() call with cpus_clear(&extra_cpus_mask)? Seems a bit silly to do, b=
ut I’d like to know how much a few cpumask operations per page is cost=
ing (most are of course much quicker than tlbflush_filter as they operate on=
 64 bits per iteration, rather than one bit per iteration).<BR>
<BR>
If that is suitably fast, I think we can have a go at fixing this by pullin=
g the TLB-flush logic out of alloc_heap_pages() and into the loops in increw=
ase_reservation() and populate_physmap() in common/memory.c. I assume you se=
e lots of looping in one of those two functions, but only single-page-at-a-t=
ime calls into alloc_domheap_pages()->alloc_heap_pages()?<BR>
<BR>
  -- Keir<BR>
<BR>
On 13/10/2012 07:21, "tupeng212" <<a href=3D"tupeng212@gmail.com=
">tupeng212@gmail.com</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
FONT COLOR=3D"#000080"><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'>If the &nbs=
p;tlbflush_filter() and cpumask_or() lines are commented out from  the<=
BR>
if(need_tlbflush) block in alloc_heap_pages(), what are the domain  cr=
eation<BR>
times like then? <BR>
: You mean removing these code from  alloc_heap_pages, then try it.<BR=
>
I didn't do it as you said, but I calculated  the whole time of if(nee=
d_tlbflush) block<BR>
by using time1=3DNOW() ...block ...  time2=3DNOW(), time=3Dtime2-time1, its =
unit is ns, and s =3D ns * 10^9<BR>
it occupy  high rate of the whole time. whole starting time is 30s, th=
en this block may  be 29s.<BR>
 <BR>
By the way it looks like you are not using xen-unstable  or<BR>
xen-4.2, can you try with one of these later versions of Xen?<BR>
:  fortunately, other groups have to use xen-4.2, we have repeated thi=
s  experiment on <BR>
that source code too, it changed nothing, time is still very  long in =
second starting.<BR>
 <BR>
 <BR>
<HR ALIGN=3DLEFT SIZE=3D"1" WIDTH=3D"100%"> tupeng<BR>
 <BR>
 <BR>
<BR>
</SPAN></FONT></FONT></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helv=
etica, Arial"><FONT COLOR=3D"#000080"><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10=
pt'><BR>
</SPAN></FONT></FONT></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--B_3432967176_20047710--


--B_3432967176_20080749
Content-type: application/octet-stream; name="00-reduce-tlbflush_filter"
Content-disposition: attachment;
	filename="00-reduce-tlbflush_filter"
Content-transfer-encoding: base64


ZGlmZiAtciBhMTU1OTZhNjE5ZWQgeGVuL2NvbW1vbi9wYWdlX2FsbG9jLmMKLS0tIGEveGVu
L2NvbW1vbi9wYWdlX2FsbG9jLmMJVGh1IE9jdCAwNCAxMDo0NDo0MyAyMDEyICswMjAwCisr
KyBiL3hlbi9jb21tb24vcGFnZV9hbGxvYy5jCVNhdCBPY3QgMTMgMDk6NTc6MjYgMjAxMiAr
MDEwMApAQCAtMzAzLDkgKzMwMywxMCBAQCBzdGF0aWMgc3RydWN0IHBhZ2VfaW5mbyAqYWxs
b2NfaGVhcF9wYWdlCiAgICAgdW5zaWduZWQgaW50IGZpcnN0X25vZGUsIGksIGosIHpvbmUg
PSAwLCBub2RlbWFza19yZXRyeSA9IDA7CiAgICAgdW5zaWduZWQgaW50IG5vZGUgPSAodWlu
dDhfdCkoKG1lbWZsYWdzID4+IF9NRU1GX25vZGUpIC0gMSk7CiAgICAgdW5zaWduZWQgbG9u
ZyByZXF1ZXN0ID0gMVVMIDw8IG9yZGVyOwotICAgIGNwdW1hc2tfdCBleHRyYV9jcHVzX21h
c2ssIG1hc2s7CiAgICAgc3RydWN0IHBhZ2VfaW5mbyAqcGc7CiAgICAgbm9kZW1hc2tfdCBu
b2RlbWFzayA9IChkICE9IE5VTEwgKSA/IGQtPm5vZGVfYWZmaW5pdHkgOiBub2RlX29ubGlu
ZV9tYXA7CisgICAgYm9vbF90IG5lZWRfdGxiZmx1c2ggPSAwOworICAgIHVpbnQzMl90IHRs
YmZsdXNoX3RpbWVzdGFtcCA9IDA7CiAKICAgICBpZiAoIG5vZGUgPT0gTlVNQV9OT19OT0RF
ICkKICAgICB7CkBAIC00MTcsMjAgKzQxOCwxOSBAQCBzdGF0aWMgc3RydWN0IHBhZ2VfaW5m
byAqYWxsb2NfaGVhcF9wYWdlCiAgICAgaWYgKCBkICE9IE5VTEwgKQogICAgICAgICBkLT5s
YXN0X2FsbG9jX25vZGUgPSBub2RlOwogCi0gICAgY3B1c19jbGVhcihtYXNrKTsKLQogICAg
IGZvciAoIGkgPSAwOyBpIDwgKDEgPDwgb3JkZXIpOyBpKysgKQogICAgIHsKICAgICAgICAg
LyogUmVmZXJlbmNlIGNvdW50IG11c3QgY29udGludW91c2x5IGJlIHplcm8gZm9yIGZyZWUg
cGFnZXMuICovCiAgICAgICAgIEJVR19PTihwZ1tpXS5jb3VudF9pbmZvICE9IFBHQ19zdGF0
ZV9mcmVlKTsKICAgICAgICAgcGdbaV0uY291bnRfaW5mbyA9IFBHQ19zdGF0ZV9pbnVzZTsK
IAotICAgICAgICBpZiAoIHBnW2ldLnUuZnJlZS5uZWVkX3RsYmZsdXNoICkKKyAgICAgICAg
aWYgKCBwZ1tpXS51LmZyZWUubmVlZF90bGJmbHVzaCAmJgorICAgICAgICAgICAgIChwZ1tp
XS50bGJmbHVzaF90aW1lc3RhbXAgPD0gdGxiZmx1c2hfY3VycmVudF90aW1lKCkpICYmCisg
ICAgICAgICAgICAgKCFuZWVkX3RsYmZsdXNoIHx8CisgICAgICAgICAgICAgIChwZ1tpXS50
bGJmbHVzaF90aW1lc3RhbXAgPiB0bGJmbHVzaF90aW1lc3RhbXApKSApCiAgICAgICAgIHsK
LSAgICAgICAgICAgIC8qIEFkZCBpbiBleHRyYSBDUFVzIHRoYXQgbmVlZCBmbHVzaGluZyBi
ZWNhdXNlIG9mIHRoaXMgcGFnZS4gKi8KLSAgICAgICAgICAgIGNwdXNfYW5kbm90KGV4dHJh
X2NwdXNfbWFzaywgY3B1X29ubGluZV9tYXAsIG1hc2spOwotICAgICAgICAgICAgdGxiZmx1
c2hfZmlsdGVyKGV4dHJhX2NwdXNfbWFzaywgcGdbaV0udGxiZmx1c2hfdGltZXN0YW1wKTsK
LSAgICAgICAgICAgIGNwdXNfb3IobWFzaywgbWFzaywgZXh0cmFfY3B1c19tYXNrKTsKKyAg
ICAgICAgICAgIG5lZWRfdGxiZmx1c2ggPSAxOworICAgICAgICAgICAgdGxiZmx1c2hfdGlt
ZXN0YW1wID0gcGdbaV0udGxiZmx1c2hfdGltZXN0YW1wOwogICAgICAgICB9CiAKICAgICAg
ICAgLyogSW5pdGlhbGlzZSBmaWVsZHMgd2hpY2ggaGF2ZSBvdGhlciB1c2VzIGZvciBmcmVl
IHBhZ2VzLiAqLwpAQCAtNDQwLDEwICs0NDAsMTUgQEAgc3RhdGljIHN0cnVjdCBwYWdlX2lu
Zm8gKmFsbG9jX2hlYXBfcGFnZQogCiAgICAgc3Bpbl91bmxvY2soJmhlYXBfbG9jayk7CiAK
LSAgICBpZiAoIHVubGlrZWx5KCFjcHVzX2VtcHR5KG1hc2spKSApCisgICAgaWYgKCBuZWVk
X3RsYmZsdXNoICkKICAgICB7Ci0gICAgICAgIHBlcmZjX2luY3IobmVlZF9mbHVzaF90bGJf
Zmx1c2gpOwotICAgICAgICBmbHVzaF90bGJfbWFzaygmbWFzayk7CisgICAgICAgIGNwdW1h
c2tfdCBtYXNrID0gY3B1X29ubGluZV9tYXA7CisgICAgICAgIHRsYmZsdXNoX2ZpbHRlciht
YXNrLCB0bGJmbHVzaF90aW1lc3RhbXApOworICAgICAgICBpZiAoICFjcHVzX2VtcHR5KG1h
c2spICkKKyAgICAgICAgeworICAgICAgICAgICAgcGVyZmNfaW5jcihuZWVkX2ZsdXNoX3Rs
Yl9mbHVzaCk7CisgICAgICAgICAgICBmbHVzaF90bGJfbWFzaygmbWFzayk7CisgICAgICAg
IH0KICAgICB9CiAKICAgICByZXR1cm4gcGc7Cg==
--B_3432967176_20080749
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--B_3432967176_20080749--




From xen-devel-bounces@lists.xen.org Sat Oct 13 09:00:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Oct 2012 09:00:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMxZO-0007SG-JZ; Sat, 13 Oct 2012 08:59:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TMxZM-0007SB-LH
	for xen-devel@lists.xen.org; Sat, 13 Oct 2012 08:59:41 +0000
Received: from [85.158.139.83:41108] by server-13.bemta-5.messagelabs.com id
	F5/BB-29905-B7D29705; Sat, 13 Oct 2012 08:59:39 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1350118778!34122910!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	MAILTO_TO_SPAM_ADDR,MIME_QP_LONG_LINE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3681 invoked from network); 13 Oct 2012 08:59:38 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Oct 2012 08:59:38 -0000
Received: by mail-wi0-f173.google.com with SMTP id hm4so222503wib.14
	for <xen-devel@lists.xen.org>; Sat, 13 Oct 2012 01:59:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type;
	bh=OiKz+sqXG92SdIVffWQbN8qF1dukltfzs2aB0sHQCMY=;
	b=FZ0FDEVQhwGDua67So2hL359UOKSsKkhiF9Ry5DjgyI4mjkm0j5WOuMapmQQxAFrQT
	OFz5NXYDIkmhGmYc6HAQTA+fvpE2qakVmy4I9KZg/4mdbP5VYHDTacjdvJ578G6TgqVV
	c+QnR+WjPrgL9wcEDMlNKwuQpFFMlkk6VBQOsB7YdWr48n8mIHGjuoVTzhyEU1m0HYA3
	1ToB4NAB706XyWU2LN4Bwvx9tg3UUdbryMYUQ+wMxmGyyd6rchQc+xevvBGNIOayEg0D
	xSYx+BxhlBRjALEOVSvOlHK5DXf93DDT9C4/QcUQXmZ//gljHUazY2q1upsAq8xbA2on
	Q5Yg==
Received: by 10.180.79.202 with SMTP id l10mr11348199wix.9.1350118778256;
	Sat, 13 Oct 2012 01:59:38 -0700 (PDT)
Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com.
	[86.183.156.141])
	by mx.google.com with ESMTPS id p4sm2261239wix.0.2012.10.13.01.59.34
	(version=SSLv3 cipher=OTHER); Sat, 13 Oct 2012 01:59:36 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Sat, 13 Oct 2012 09:59:19 +0100
From: Keir Fraser <keir@xen.org>
To: tupeng212 <tupeng212@gmail.com>
Message-ID: <CC9EEBF9.4EE4D%keir@xen.org>
Thread-Topic: [Xen-devel] alloc_heap_pages is low efficient with more CPUs
Thread-Index: Ac2pIQeX6HxWHUTuf0G4n/Wqknktzg==
In-Reply-To: <2012101314464865629623@gmail.com>
Mime-version: 1.0
Content-type: multipart/mixed;
	boundary="B_3432967176_20080749"
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] alloc_heap_pages is low efficient with more CPUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3432967176_20080749
Content-type: multipart/alternative;
	boundary="B_3432967176_20047710"


--B_3432967176_20047710
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

If the allocations are 2M size, we can do better quite easily I think.
Please try the attached patch.

 -- Keir

On 13/10/2012 07:46, "tupeng212" <tupeng212@gmail.com> wrote:

> What if you replace tlbflush_filter() call with cpus_clear(&extra_cpus_ma=
sk)?
> :  you mean just clear it,  maybe a little violent..,  you 'd like to do =
it at
> any other place.
> =20
> I assume you see lots of looping in one of those two functions, but only
> single-page-at-a-time calls into alloc_domheap_pages()->alloc_heap_pages(=
)?
> :  In populate_physmap,  all pages are 2M size,
> static void populate_physmap(struct memop_args *a)
> {
>     for ( i =3D a->nr_done; i < a->nr_extents; i++ )
>     {
> page =3D alloc_domheap_pages(d, a->extent_order, a->memflags) ->alloc_heap_=
pages
> ;  //a->extent_order =3D 9, always 2M size
> }
> //you mean move that block and TLB-flush here to avoid for loop ?
> }
>=20
> tupeng212
> =20
> From: Keir Fraser <mailto:keir.xen@gmail.com>
> Date: 2012-10-13 14:30
> To: tupeng212 <mailto:tupeng212@gmail.com>
> Subject: Re: [Xen-devel] alloc_heap_pages is low efficient with more CPUs
> What if you replace tlbflush_filter() call with cpus_clear(&extra_cpus_ma=
sk)?
> Seems a bit silly to do, but I=B9d like to know how much a few cpumask
> operations per page is costing (most are of course much quicker than
> tlbflush_filter as they operate on 64 bits per iteration, rather than one=
 bit
> per iteration).
>=20
> If that is suitably fast, I think we can have a go at fixing this by pull=
ing
> the TLB-flush logic out of alloc_heap_pages() and into the loops in
> increwase_reservation() and populate_physmap() in common/memory.c. I assu=
me
> you see lots of looping in one of those two functions, but only
> single-page-at-a-time calls into alloc_domheap_pages()->alloc_heap_pages(=
)?
>=20
>   -- Keir
>=20
> On 13/10/2012 07:21, "tupeng212" <tupeng212@gmail.com> wrote:
>=20
>> If the  tlbflush_filter() and cpumask_or() lines are commented out from =
 the
>> if(need_tlbflush) block in alloc_heap_pages(), what are the domain  crea=
tion
>> times like then?
>> : You mean removing these code from  alloc_heap_pages, then try it.
>> I didn't do it as you said, but I calculated  the whole time of
>> if(need_tlbflush) block
>> by using time1=3DNOW() ...block ...  time2=3DNOW(), time=3Dtime2-time1, its un=
it is
>> ns, and s =3D ns * 10^9
>> it occupy  high rate of the whole time. whole starting time is 30s, then=
 this
>> block may  be 29s.
>> =20
>> By the way it looks like you are not using xen-unstable  or
>> xen-4.2, can you try with one of these later versions of Xen?
>> :  fortunately, other groups have to use xen-4.2, we have repeated this
>> experiment on=20
>> that source code too, it changed nothing, time is still very  long in se=
cond
>> starting.
>> =20
>> =20
>>=20
>>  tupeng
>> =20
>> =20
>>=20
>=20


--B_3432967176_20047710
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [Xen-devel] alloc_heap_pages is low efficient with more CPUs</TI=
TLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>If the allocations are 2M size, we can do better quite easily I think. Ple=
ase try the attached patch.<BR>
<BR>
 -- Keir<BR>
<BR>
On 13/10/2012 07:46, "tupeng212" <<a href=3D"tupeng212@gmail.com=
">tupeng212@gmail.com</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'><FONT COLOR=3D"#000080">What if you replace tlbflu=
sh_filter() call with cpus_clear(&extra_cpus_mask)? <BR>
:  you mean just clear it,  maybe a little violent..,  you '=
d like to do it at any other place.<BR>
</FONT></SPAN><FONT COLOR=3D"#000080"><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:1=
0pt'> <BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:11pt'>I assume you see lots of looping=
 in one of those two functions, but only single-page-at-a-time calls into al=
loc_domheap_pages()->alloc_heap_pages()?<BR>
:  In populate_physmap,  all pages are 2M size, <BR>
</SPAN><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'>static void populate_phy=
smap(struct memop_args *a) <BR>
{<BR>
    for ( i =3D a->nr_done; i < a->nr_extents; i=
++ )<BR>
    {<BR>
page =3D alloc_domheap_pages(d, a->extent_order, a->memflags) ->allo=
c_heap_pages ;  //a->extent_order =3D 9, always 2M size<BR>
}<BR>
//you mean move that block and TLB-flush here to avoid for loop ?<BR>
}<BR>
<HR ALIGN=3DLEFT SIZE=3D"1" WIDTH=3D"100%">tupeng212<BR>
 <BR>
</SPAN></FONT></FONT><FONT SIZE=3D"1"><SPAN STYLE=3D'font-size:9pt'><B>From:</B=
> Keir Fraser <<a href=3D"mailto:keir.xen@gmail.com">mailto:keir.xen@gmail.=
com</a>> <BR>
<B>Date:</B> 2012-10-13 14:30<BR>
<B>To:</B> tupeng212 <<a href=3D"mailto:tupeng212@gmail.com">mailto:tupeng=
212@gmail.com</a>> <BR>
<B>Subject:</B> Re: [Xen-devel] alloc_heap_pages is low efficient with more=
 CPUs<BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:11pt'>What if you replace tlbflush_fil=
ter() call with cpus_clear(&extra_cpus_mask)? Seems a bit silly to do, b=
ut I’d like to know how much a few cpumask operations per page is cost=
ing (most are of course much quicker than tlbflush_filter as they operate on=
 64 bits per iteration, rather than one bit per iteration).<BR>
<BR>
If that is suitably fast, I think we can have a go at fixing this by pullin=
g the TLB-flush logic out of alloc_heap_pages() and into the loops in increw=
ase_reservation() and populate_physmap() in common/memory.c. I assume you se=
e lots of looping in one of those two functions, but only single-page-at-a-t=
ime calls into alloc_domheap_pages()->alloc_heap_pages()?<BR>
<BR>
  -- Keir<BR>
<BR>
On 13/10/2012 07:21, "tupeng212" <<a href=3D"tupeng212@gmail.com=
">tupeng212@gmail.com</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
FONT COLOR=3D"#000080"><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'>If the &nbs=
p;tlbflush_filter() and cpumask_or() lines are commented out from  the<=
BR>
if(need_tlbflush) block in alloc_heap_pages(), what are the domain  cr=
eation<BR>
times like then? <BR>
: You mean removing these code from  alloc_heap_pages, then try it.<BR=
>
I didn't do it as you said, but I calculated  the whole time of if(nee=
d_tlbflush) block<BR>
by using time1=3DNOW() ...block ...  time2=3DNOW(), time=3Dtime2-time1, its =
unit is ns, and s =3D ns * 10^9<BR>
it occupy  high rate of the whole time. whole starting time is 30s, th=
en this block may  be 29s.<BR>
 <BR>
By the way it looks like you are not using xen-unstable  or<BR>
xen-4.2, can you try with one of these later versions of Xen?<BR>
:  fortunately, other groups have to use xen-4.2, we have repeated thi=
s  experiment on <BR>
that source code too, it changed nothing, time is still very  long in =
second starting.<BR>
 <BR>
 <BR>
<HR ALIGN=3DLEFT SIZE=3D"1" WIDTH=3D"100%"> tupeng<BR>
 <BR>
 <BR>
<BR>
</SPAN></FONT></FONT></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helv=
etica, Arial"><FONT COLOR=3D"#000080"><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10=
pt'><BR>
</SPAN></FONT></FONT></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--B_3432967176_20047710--


--B_3432967176_20080749
Content-type: application/octet-stream; name="00-reduce-tlbflush_filter"
Content-disposition: attachment;
	filename="00-reduce-tlbflush_filter"
Content-transfer-encoding: base64


ZGlmZiAtciBhMTU1OTZhNjE5ZWQgeGVuL2NvbW1vbi9wYWdlX2FsbG9jLmMKLS0tIGEveGVu
L2NvbW1vbi9wYWdlX2FsbG9jLmMJVGh1IE9jdCAwNCAxMDo0NDo0MyAyMDEyICswMjAwCisr
KyBiL3hlbi9jb21tb24vcGFnZV9hbGxvYy5jCVNhdCBPY3QgMTMgMDk6NTc6MjYgMjAxMiAr
MDEwMApAQCAtMzAzLDkgKzMwMywxMCBAQCBzdGF0aWMgc3RydWN0IHBhZ2VfaW5mbyAqYWxs
b2NfaGVhcF9wYWdlCiAgICAgdW5zaWduZWQgaW50IGZpcnN0X25vZGUsIGksIGosIHpvbmUg
PSAwLCBub2RlbWFza19yZXRyeSA9IDA7CiAgICAgdW5zaWduZWQgaW50IG5vZGUgPSAodWlu
dDhfdCkoKG1lbWZsYWdzID4+IF9NRU1GX25vZGUpIC0gMSk7CiAgICAgdW5zaWduZWQgbG9u
ZyByZXF1ZXN0ID0gMVVMIDw8IG9yZGVyOwotICAgIGNwdW1hc2tfdCBleHRyYV9jcHVzX21h
c2ssIG1hc2s7CiAgICAgc3RydWN0IHBhZ2VfaW5mbyAqcGc7CiAgICAgbm9kZW1hc2tfdCBu
b2RlbWFzayA9IChkICE9IE5VTEwgKSA/IGQtPm5vZGVfYWZmaW5pdHkgOiBub2RlX29ubGlu
ZV9tYXA7CisgICAgYm9vbF90IG5lZWRfdGxiZmx1c2ggPSAwOworICAgIHVpbnQzMl90IHRs
YmZsdXNoX3RpbWVzdGFtcCA9IDA7CiAKICAgICBpZiAoIG5vZGUgPT0gTlVNQV9OT19OT0RF
ICkKICAgICB7CkBAIC00MTcsMjAgKzQxOCwxOSBAQCBzdGF0aWMgc3RydWN0IHBhZ2VfaW5m
byAqYWxsb2NfaGVhcF9wYWdlCiAgICAgaWYgKCBkICE9IE5VTEwgKQogICAgICAgICBkLT5s
YXN0X2FsbG9jX25vZGUgPSBub2RlOwogCi0gICAgY3B1c19jbGVhcihtYXNrKTsKLQogICAg
IGZvciAoIGkgPSAwOyBpIDwgKDEgPDwgb3JkZXIpOyBpKysgKQogICAgIHsKICAgICAgICAg
LyogUmVmZXJlbmNlIGNvdW50IG11c3QgY29udGludW91c2x5IGJlIHplcm8gZm9yIGZyZWUg
cGFnZXMuICovCiAgICAgICAgIEJVR19PTihwZ1tpXS5jb3VudF9pbmZvICE9IFBHQ19zdGF0
ZV9mcmVlKTsKICAgICAgICAgcGdbaV0uY291bnRfaW5mbyA9IFBHQ19zdGF0ZV9pbnVzZTsK
IAotICAgICAgICBpZiAoIHBnW2ldLnUuZnJlZS5uZWVkX3RsYmZsdXNoICkKKyAgICAgICAg
aWYgKCBwZ1tpXS51LmZyZWUubmVlZF90bGJmbHVzaCAmJgorICAgICAgICAgICAgIChwZ1tp
XS50bGJmbHVzaF90aW1lc3RhbXAgPD0gdGxiZmx1c2hfY3VycmVudF90aW1lKCkpICYmCisg
ICAgICAgICAgICAgKCFuZWVkX3RsYmZsdXNoIHx8CisgICAgICAgICAgICAgIChwZ1tpXS50
bGJmbHVzaF90aW1lc3RhbXAgPiB0bGJmbHVzaF90aW1lc3RhbXApKSApCiAgICAgICAgIHsK
LSAgICAgICAgICAgIC8qIEFkZCBpbiBleHRyYSBDUFVzIHRoYXQgbmVlZCBmbHVzaGluZyBi
ZWNhdXNlIG9mIHRoaXMgcGFnZS4gKi8KLSAgICAgICAgICAgIGNwdXNfYW5kbm90KGV4dHJh
X2NwdXNfbWFzaywgY3B1X29ubGluZV9tYXAsIG1hc2spOwotICAgICAgICAgICAgdGxiZmx1
c2hfZmlsdGVyKGV4dHJhX2NwdXNfbWFzaywgcGdbaV0udGxiZmx1c2hfdGltZXN0YW1wKTsK
LSAgICAgICAgICAgIGNwdXNfb3IobWFzaywgbWFzaywgZXh0cmFfY3B1c19tYXNrKTsKKyAg
ICAgICAgICAgIG5lZWRfdGxiZmx1c2ggPSAxOworICAgICAgICAgICAgdGxiZmx1c2hfdGlt
ZXN0YW1wID0gcGdbaV0udGxiZmx1c2hfdGltZXN0YW1wOwogICAgICAgICB9CiAKICAgICAg
ICAgLyogSW5pdGlhbGlzZSBmaWVsZHMgd2hpY2ggaGF2ZSBvdGhlciB1c2VzIGZvciBmcmVl
IHBhZ2VzLiAqLwpAQCAtNDQwLDEwICs0NDAsMTUgQEAgc3RhdGljIHN0cnVjdCBwYWdlX2lu
Zm8gKmFsbG9jX2hlYXBfcGFnZQogCiAgICAgc3Bpbl91bmxvY2soJmhlYXBfbG9jayk7CiAK
LSAgICBpZiAoIHVubGlrZWx5KCFjcHVzX2VtcHR5KG1hc2spKSApCisgICAgaWYgKCBuZWVk
X3RsYmZsdXNoICkKICAgICB7Ci0gICAgICAgIHBlcmZjX2luY3IobmVlZF9mbHVzaF90bGJf
Zmx1c2gpOwotICAgICAgICBmbHVzaF90bGJfbWFzaygmbWFzayk7CisgICAgICAgIGNwdW1h
c2tfdCBtYXNrID0gY3B1X29ubGluZV9tYXA7CisgICAgICAgIHRsYmZsdXNoX2ZpbHRlciht
YXNrLCB0bGJmbHVzaF90aW1lc3RhbXApOworICAgICAgICBpZiAoICFjcHVzX2VtcHR5KG1h
c2spICkKKyAgICAgICAgeworICAgICAgICAgICAgcGVyZmNfaW5jcihuZWVkX2ZsdXNoX3Rs
Yl9mbHVzaCk7CisgICAgICAgICAgICBmbHVzaF90bGJfbWFzaygmbWFzayk7CisgICAgICAg
IH0KICAgICB9CiAKICAgICByZXR1cm4gcGc7Cg==
--B_3432967176_20080749
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--B_3432967176_20080749--




From xen-devel-bounces@lists.xen.org Sat Oct 13 09:00:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Oct 2012 09:00:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMxZb-0007Sm-22; Sat, 13 Oct 2012 08:59:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TMxZZ-0007Sf-O0
	for xen-devel@lists.xen.org; Sat, 13 Oct 2012 08:59:53 +0000
Received: from [85.158.143.99:9174] by server-1.bemta-4.messagelabs.com id
	1C/C1-19551-88D29705; Sat, 13 Oct 2012 08:59:52 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1350118792!27528461!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR, RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9508 invoked from network); 13 Oct 2012 08:59:52 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Oct 2012 08:59:52 -0000
Received: by mail-wg0-f51.google.com with SMTP id ed3so2176692wgb.32
	for <xen-devel@lists.xen.org>; Sat, 13 Oct 2012 01:59:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=5y1KwIaQRHDe+2LNJK27Di0xkWFQMuesSBPj2QToNUs=;
	b=UsQBmxGJFjvzh8OuXbzpJuHFLlgDXti49be1GAOWCf3HT8/r6cbGdiT2gO5hkmJ6RI
	8Xm3KcST0IPXbwtudVwg1xcZ4BkT7k8UYVjvT+J/lox9JpzHVy97bJoZwmyldA1ndJ8E
	rtKbMzD/FSUuT8Bbgz/GcBdjA3PMoxNIenhfUGd2pVVg4oPwogzukcKfXgLocRE8RRLA
	5XOG4Lxq2rg5lHw6jKrVo4e8Xx9/BMTXg1Wz4VG7eW3x4sQK3xAg2BIxyjWe+WoyNiGx
	iP2/75QJCoVTD/dm8aTU0aMRfnz2Zokmf/zgt5lWP+7R9dYzDVL6hp07dFWV0IJbQ4Wx
	i1TQ==
Received: by 10.216.198.66 with SMTP id u44mr3960542wen.133.1350118792106;
	Sat, 13 Oct 2012 01:59:52 -0700 (PDT)
Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com.
	[86.183.156.141])
	by mx.google.com with ESMTPS id dt9sm1944918wib.1.2012.10.13.01.59.51
	(version=SSLv3 cipher=OTHER); Sat, 13 Oct 2012 01:59:51 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Sat, 13 Oct 2012 09:59:45 +0100
From: Keir Fraser <keir@xen.org>
To: tupeng212 <tupeng212@gmail.com>
Message-ID: <CC9EEC11.4EE4E%keir@xen.org>
Thread-Topic: [Xen-devel] alloc_heap_pages is low efficient with more CPUs
Thread-Index: Ac2pIRcWEdxf/Aiulk6RYcpdwngjPA==
In-Reply-To: <2012101315200385948426@gmail.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] alloc_heap_pages is low efficient with more CPUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 13/10/2012 08:20, "tupeng212" <tupeng212@gmail.com> wrote:

> /* Allocate 2^@order contiguous pages. */
> static struct page_info *alloc_heap_pages(
>     unsigned int zone_lo, unsigned int zone_hi,
>     unsigned int node, unsigned int order, unsigned int memflags)
> {
>     cpus_clear(mask);
>     for ( i = 0; i < (1 << order); i++ )
>     {    
>         if ( pg[i].u.free.need_tlbflush )
>         {
>             /* Add in extra CPUs that need flushing because of this page. */
>             cpus_andnot(extra_cpus_mask, cpu_online_map, mask);
>             tlbflush_filter(extra_cpus_mask, pg[i].tlbflush_timestamp);
>             cpus_or(mask, mask, extra_cpus_mask);
>         }
>     }
>     if ( unlikely(!cpus_empty(mask)) )
>     {
>         perfc_incr(need_flush_tlb_flush);
>         flush_tlb_mask(&mask);
>     }
>     return pg;
> }
>  
> Is this equal to : in pg[1<<order-1].u.free.need_tlbflush, if we compute
> mask=0, then flush TLB mask ?

No!

 -- Keir




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 13 09:00:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Oct 2012 09:00:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMxZb-0007Sm-22; Sat, 13 Oct 2012 08:59:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TMxZZ-0007Sf-O0
	for xen-devel@lists.xen.org; Sat, 13 Oct 2012 08:59:53 +0000
Received: from [85.158.143.99:9174] by server-1.bemta-4.messagelabs.com id
	1C/C1-19551-88D29705; Sat, 13 Oct 2012 08:59:52 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1350118792!27528461!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR, RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9508 invoked from network); 13 Oct 2012 08:59:52 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Oct 2012 08:59:52 -0000
Received: by mail-wg0-f51.google.com with SMTP id ed3so2176692wgb.32
	for <xen-devel@lists.xen.org>; Sat, 13 Oct 2012 01:59:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=5y1KwIaQRHDe+2LNJK27Di0xkWFQMuesSBPj2QToNUs=;
	b=UsQBmxGJFjvzh8OuXbzpJuHFLlgDXti49be1GAOWCf3HT8/r6cbGdiT2gO5hkmJ6RI
	8Xm3KcST0IPXbwtudVwg1xcZ4BkT7k8UYVjvT+J/lox9JpzHVy97bJoZwmyldA1ndJ8E
	rtKbMzD/FSUuT8Bbgz/GcBdjA3PMoxNIenhfUGd2pVVg4oPwogzukcKfXgLocRE8RRLA
	5XOG4Lxq2rg5lHw6jKrVo4e8Xx9/BMTXg1Wz4VG7eW3x4sQK3xAg2BIxyjWe+WoyNiGx
	iP2/75QJCoVTD/dm8aTU0aMRfnz2Zokmf/zgt5lWP+7R9dYzDVL6hp07dFWV0IJbQ4Wx
	i1TQ==
Received: by 10.216.198.66 with SMTP id u44mr3960542wen.133.1350118792106;
	Sat, 13 Oct 2012 01:59:52 -0700 (PDT)
Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com.
	[86.183.156.141])
	by mx.google.com with ESMTPS id dt9sm1944918wib.1.2012.10.13.01.59.51
	(version=SSLv3 cipher=OTHER); Sat, 13 Oct 2012 01:59:51 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Sat, 13 Oct 2012 09:59:45 +0100
From: Keir Fraser <keir@xen.org>
To: tupeng212 <tupeng212@gmail.com>
Message-ID: <CC9EEC11.4EE4E%keir@xen.org>
Thread-Topic: [Xen-devel] alloc_heap_pages is low efficient with more CPUs
Thread-Index: Ac2pIRcWEdxf/Aiulk6RYcpdwngjPA==
In-Reply-To: <2012101315200385948426@gmail.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] alloc_heap_pages is low efficient with more CPUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 13/10/2012 08:20, "tupeng212" <tupeng212@gmail.com> wrote:

> /* Allocate 2^@order contiguous pages. */
> static struct page_info *alloc_heap_pages(
>     unsigned int zone_lo, unsigned int zone_hi,
>     unsigned int node, unsigned int order, unsigned int memflags)
> {
>     cpus_clear(mask);
>     for ( i = 0; i < (1 << order); i++ )
>     {    
>         if ( pg[i].u.free.need_tlbflush )
>         {
>             /* Add in extra CPUs that need flushing because of this page. */
>             cpus_andnot(extra_cpus_mask, cpu_online_map, mask);
>             tlbflush_filter(extra_cpus_mask, pg[i].tlbflush_timestamp);
>             cpus_or(mask, mask, extra_cpus_mask);
>         }
>     }
>     if ( unlikely(!cpus_empty(mask)) )
>     {
>         perfc_incr(need_flush_tlb_flush);
>         flush_tlb_mask(&mask);
>     }
>     return pg;
> }
>  
> Is this equal to : in pg[1<<order-1].u.free.need_tlbflush, if we compute
> mask=0, then flush TLB mask ?

No!

 -- Keir




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 13 09:25:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Oct 2012 09:25:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMxxQ-0007nZ-CT; Sat, 13 Oct 2012 09:24:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <topperxin@126.com>) id 1TMxtI-0007mm-Tt
	for xen-devel@lists.xensource.com; Sat, 13 Oct 2012 09:20:17 +0000
X-Env-Sender: topperxin@126.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1350120006!9895821!1
X-Originating-IP: [220.181.15.35]
X-SpamReason: No, hits=1.1 required=7.0 tests=BODY_DONG,HTML_40_50,
	HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27385 invoked from network); 13 Oct 2012 09:20:09 -0000
Received: from m15-35.126.com (HELO m15-35.126.com) (220.181.15.35)
	by server-12.tower-27.messagelabs.com with SMTP;
	13 Oct 2012 09:20:09 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com;
	s=s110527; h=Received:Date:From:To:Subject:Content-Type:
	MIME-Version:Message-ID; bh=xnifPzGf0GvIQszSigjNed37mkf9iEg5hekc
	W6aAzxE=; b=cQBIQO1yeCE1IV05+40gOWuNc+s2gMlZhj3I+B+vuz1D7pPM90xi
	0OEbkJ+KRyTz5xVJGVKAhcUExD/Pqy+VzVtPqVR682SG4ZkI8GSrqolZRHfWt7iy
	72uJVfPKa/rRs+8DQ+FDhEU7BSfprW8gWFV/yQwV59WshW47uYStU5g=
Received: from topperxin$126.com ( [175.195.53.49] ) by ajax-webmail-wmsvr35
	(Coremail) ; Sat, 13 Oct 2012 17:20:04 +0800 (CST)
X-Originating-IP: [175.195.53.49]
Date: Sat, 13 Oct 2012 17:20:04 +0800 (CST)
From: topperxin <topperxin@126.com>
To: xen-devel <xen-devel@lists.xensource.com>
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	20120914(19817.4926.4909) Copyright (c) 2002-2012 www.mailtech.cn
	126com
X-CM-CTRLDATA: JUNJlWZvb3Rlcl9odG09MTAxMTo4MQ==
MIME-Version: 1.0
Message-ID: <5266476.1b4039.13a596c5c9c.Coremail.topperxin@126.com>
X-CM-TRANSID: I8qowEBp+UBFMnlQatomAA--.6515W
X-CM-SenderInfo: xwrs1vhu0l0qqrswhudrp/1tbiZwRHDk3AOOB80gAAsR
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
X-Mailman-Approved-At: Sat, 13 Oct 2012 09:24:31 +0000
Subject: [Xen-devel] error: xl pci-attach assign pci to vm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2009813881142081188=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2009813881142081188==
Content-Type: multipart/alternative; 
	boundary="----=_Part_6712308_2043723236.1350120004763"

------=_Part_6712308_2043723236.1350120004763
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: 7bit

Hi all
       Now I'm dong the sriov on the xen 4.1
       when I try to do the following cmd: 
       I got some errors like below:
       # xl pci-attach 7 0000:03:10.2
       libxl: error: libxl_pci.c:750:libxl_device_pci_reset The kernel doesn't support reset from sysfs for PCI device 0000:03:10.2
       libxl: error: libxl_device.c:470:libxl__wait_for_device_model Device Model not ready


       what's wrong?
       The guest os I'm using is Centos 6.3, hvm type, I have already installed the pv-drivers for it. when I execute lspci in the vm, it looks no problem.
       what's wrong, please help, thanks.


------=_Part_6712308_2043723236.1350120004763
Content-Type: text/html; charset=GBK
Content-Transfer-Encoding: 7bit

<div style="line-height:1.7;color:#000000;font-size:14px;font-family:arial"><div>Hi all</div><div>       Now I'm dong the sriov on the xen 4.1</div><div>       when I try to do the following cmd: </div><div>       I got some errors like below:</div><div>       # xl pci-attach 7 0000:03:10.2</div><div>       libxl: error: libxl_pci.c:750:libxl_device_pci_reset The kernel doesn't support reset from sysfs for PCI device 0000:03:10.2</div><div>       libxl: error: libxl_device.c:470:libxl__wait_for_device_model Device Model not ready</div><div><br></div><div>       what's wrong?</div><div>       The guest os I'm using is Centos 6.3, hvm type, I have already installed the pv-drivers for it. when I execute lspci in the vm, it looks no problem.</div><div>       what's wrong, please help, thanks.</div><div><br></div></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"></span></span>
------=_Part_6712308_2043723236.1350120004763--



--===============2009813881142081188==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2009813881142081188==--



From xen-devel-bounces@lists.xen.org Sat Oct 13 09:25:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Oct 2012 09:25:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMxxQ-0007nZ-CT; Sat, 13 Oct 2012 09:24:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <topperxin@126.com>) id 1TMxtI-0007mm-Tt
	for xen-devel@lists.xensource.com; Sat, 13 Oct 2012 09:20:17 +0000
X-Env-Sender: topperxin@126.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1350120006!9895821!1
X-Originating-IP: [220.181.15.35]
X-SpamReason: No, hits=1.1 required=7.0 tests=BODY_DONG,HTML_40_50,
	HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27385 invoked from network); 13 Oct 2012 09:20:09 -0000
Received: from m15-35.126.com (HELO m15-35.126.com) (220.181.15.35)
	by server-12.tower-27.messagelabs.com with SMTP;
	13 Oct 2012 09:20:09 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com;
	s=s110527; h=Received:Date:From:To:Subject:Content-Type:
	MIME-Version:Message-ID; bh=xnifPzGf0GvIQszSigjNed37mkf9iEg5hekc
	W6aAzxE=; b=cQBIQO1yeCE1IV05+40gOWuNc+s2gMlZhj3I+B+vuz1D7pPM90xi
	0OEbkJ+KRyTz5xVJGVKAhcUExD/Pqy+VzVtPqVR682SG4ZkI8GSrqolZRHfWt7iy
	72uJVfPKa/rRs+8DQ+FDhEU7BSfprW8gWFV/yQwV59WshW47uYStU5g=
Received: from topperxin$126.com ( [175.195.53.49] ) by ajax-webmail-wmsvr35
	(Coremail) ; Sat, 13 Oct 2012 17:20:04 +0800 (CST)
X-Originating-IP: [175.195.53.49]
Date: Sat, 13 Oct 2012 17:20:04 +0800 (CST)
From: topperxin <topperxin@126.com>
To: xen-devel <xen-devel@lists.xensource.com>
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	20120914(19817.4926.4909) Copyright (c) 2002-2012 www.mailtech.cn
	126com
X-CM-CTRLDATA: JUNJlWZvb3Rlcl9odG09MTAxMTo4MQ==
MIME-Version: 1.0
Message-ID: <5266476.1b4039.13a596c5c9c.Coremail.topperxin@126.com>
X-CM-TRANSID: I8qowEBp+UBFMnlQatomAA--.6515W
X-CM-SenderInfo: xwrs1vhu0l0qqrswhudrp/1tbiZwRHDk3AOOB80gAAsR
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
X-Mailman-Approved-At: Sat, 13 Oct 2012 09:24:31 +0000
Subject: [Xen-devel] error: xl pci-attach assign pci to vm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2009813881142081188=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2009813881142081188==
Content-Type: multipart/alternative; 
	boundary="----=_Part_6712308_2043723236.1350120004763"

------=_Part_6712308_2043723236.1350120004763
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: 7bit

Hi all
       Now I'm dong the sriov on the xen 4.1
       when I try to do the following cmd: 
       I got some errors like below:
       # xl pci-attach 7 0000:03:10.2
       libxl: error: libxl_pci.c:750:libxl_device_pci_reset The kernel doesn't support reset from sysfs for PCI device 0000:03:10.2
       libxl: error: libxl_device.c:470:libxl__wait_for_device_model Device Model not ready


       what's wrong?
       The guest os I'm using is Centos 6.3, hvm type, I have already installed the pv-drivers for it. when I execute lspci in the vm, it looks no problem.
       what's wrong, please help, thanks.


------=_Part_6712308_2043723236.1350120004763
Content-Type: text/html; charset=GBK
Content-Transfer-Encoding: 7bit

<div style="line-height:1.7;color:#000000;font-size:14px;font-family:arial"><div>Hi all</div><div>       Now I'm dong the sriov on the xen 4.1</div><div>       when I try to do the following cmd: </div><div>       I got some errors like below:</div><div>       # xl pci-attach 7 0000:03:10.2</div><div>       libxl: error: libxl_pci.c:750:libxl_device_pci_reset The kernel doesn't support reset from sysfs for PCI device 0000:03:10.2</div><div>       libxl: error: libxl_device.c:470:libxl__wait_for_device_model Device Model not ready</div><div><br></div><div>       what's wrong?</div><div>       The guest os I'm using is Centos 6.3, hvm type, I have already installed the pv-drivers for it. when I execute lspci in the vm, it looks no problem.</div><div>       what's wrong, please help, thanks.</div><div><br></div></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"></span></span>
------=_Part_6712308_2043723236.1350120004763--



--===============2009813881142081188==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2009813881142081188==--



From xen-devel-bounces@lists.xen.org Sat Oct 13 10:16:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Oct 2012 10:16:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMykw-00085Q-FU; Sat, 13 Oct 2012 10:15:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <blauwirbel@gmail.com>) id 1TMyku-00085L-2g
	for xen-devel@lists.xensource.com; Sat, 13 Oct 2012 10:15:40 +0000
Received: from [85.158.139.211:4027] by server-4.bemta-5.messagelabs.com id
	1A/DF-18688-B4F39705; Sat, 13 Oct 2012 10:15:39 +0000
X-Env-Sender: blauwirbel@gmail.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1350123333!22222383!1
X-Originating-IP: [209.85.223.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25508 invoked from network); 13 Oct 2012 10:15:35 -0000
Received: from mail-ie0-f171.google.com (HELO mail-ie0-f171.google.com)
	(209.85.223.171)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Oct 2012 10:15:35 -0000
Received: by mail-ie0-f171.google.com with SMTP id s9so7200604iec.30
	for <xen-devel@lists.xensource.com>;
	Sat, 13 Oct 2012 03:15:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=opNRFxNopqY9LAxxRKw5lJMid5phKG91OeN8y5sCBas=;
	b=oD4mUiUOqDi2VU+o0CPeqmYFUEc2BR+XCYMMKoRrov2hQbnQwUvJAXBPf+oKZLLLiI
	hsByxQjh8yyvhlui2knKm6m/1qMkXVxz4EaOZ1aJryObvcjFLB/bHiPs3xzJ48NElKjC
	FkHNSlW8341+2pgvg5Kpp/fasnhH8waWtoaHQTwuB/ehnJKMkPTjjsLifEgjxjlN/5QO
	pwRNsghSJFLaH3ZAPwWBN7bGAPxrRktzU0NiZjOoN+qPgbtdUqdNqJ8mW8q0h6Dk+AUN
	rP5uGZff6x1DODfoIzgd/HZrW5nP2UoGcIxVCETYmUQ5mM3FkZQWZCtxSrJkpWk30rmq
	CJGw==
Received: by 10.50.33.169 with SMTP id s9mr4438077igi.19.1350123333435; Sat,
	13 Oct 2012 03:15:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.53.130 with HTTP; Sat, 13 Oct 2012 03:15:13 -0700 (PDT)
In-Reply-To: <1349469866-1542-1-git-send-email-ehabkost@redhat.com>
References: <1349469866-1542-1-git-send-email-ehabkost@redhat.com>
From: Blue Swirl <blauwirbel@gmail.com>
Date: Sat, 13 Oct 2012 10:15:13 +0000
Message-ID: <CAAu8pHsSjdg1WGdgaTO78sbDvnWE9mrLb6RxOi1N8yQwzmvzVw@mail.gmail.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Evgeny Voevodin <e.voevodin@samsung.com>, qemu-devel@nongnu.org,
	Peter Crosthwaite <peter.crosthwaite@petalogix.com>,
	Max Filippov <jcmvbkbc@gmail.com>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	Guan Xuetao <gxt@mprc.pku.edu.cn>, xen-devel@lists.xensource.com,
	Igor Mitsyanko <i.mitsyanko@samsung.com>,
	Magnus Damm <magnus.damm@gmail.com>, Alexander Graf <agraf@suse.de>,
	=?UTF-8?Q?Herv=C3=A9_Poussineau?= <hpoussin@reactos.org>,
	Maksim Kozlov <m.kozlov@samsung.com>,
	Andrzej Zaborowski <balrogg@gmail.com>,
	Fabien Chouteau <chouteau@adacore.com>, Jan Kiszka <jan.kiszka@web.de>,
	Paul Brook <paul@codesourcery.com>, Anthony Liguori <aliguori@us.ibm.com>,
	Michael Walle <michael@walle.cc>, qemu-ppc@nongnu.org,
	Dmitry Solodkiy <d.solodkiy@samsung.com>,
	Aurelien Jarno <aurelien@aurel32.net>
Subject: Re: [Xen-devel] [QEMU PATCH] create struct for machine
	initialization arguments (v3)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 5, 2012 at 8:44 PM, Eduardo Habkost <ehabkost@redhat.com> wrote:
> This should help us to:
> - More easily add or remove machine initialization arguments without
>   having to change every single machine init function;
> - More easily make mechanical changes involving the machine init
>   functions in the future;
> - Let machine initialization forward the init arguments to other
>   functions more easily.
>
> This change was half-mechanical process: first the struct was added with
> the local ram_size, boot_device, kernel_*, initrd_*, and cpu_model local
> variable initialization to all functions. Then the compiler helped me
> locate the local variables that are unused, so they could be removed.
>
> Changes v2 -> v3:
>  - Fix typo (missing dot) on main()
>  - Fix another mistake on xen_init_pv() (I had forgotten to add local variables
>    to replace the old function arguments)
>
> Changes v1 -> v2:
>  - Fix mistake on the conversion of pc_xen_hvm_init() and xen_init_pv()

Changelog should be below --- line so that it will be clipped by git am.

The patch does not apply (hw/xilinx_zynq.c), please rebase.

>
> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> ---
>  hw/alpha_dp264.c              |  12 ++--
>  hw/an5206.c                   |   8 +--
>  hw/axis_dev88.c               |   9 +--
>  hw/boards.h                   |  16 +++--
>  hw/collie.c                   |   9 +--
>  hw/dummy_m68k.c               |   8 +--
>  hw/exynos4_boards.c           |  16 ++---
>  hw/gumstix.c                  |  11 +---
>  hw/highbank.c                 |  10 ++--
>  hw/integratorcp.c             |  10 ++--
>  hw/kzm.c                      |  10 ++--
>  hw/leon3.c                    |  10 ++--
>  hw/lm32_boards.c              |  18 +++---
>  hw/mainstone.c                |  10 ++--
>  hw/mcf5208.c                  |   8 +--
>  hw/milkymist.c                |  10 ++--
>  hw/mips_fulong2e.c            |   9 ++-
>  hw/mips_jazz.c                |  14 ++---
>  hw/mips_malta.c               |  10 ++--
>  hw/mips_mipssim.c             |  10 ++--
>  hw/mips_r4k.c                 |  10 ++--
>  hw/musicpal.c                 |   9 +--
>  hw/nseries.c                  |  22 ++++---
>  hw/null-machine.c             |   7 +--
>  hw/omap_sx1.c                 |  22 ++++---
>  hw/openrisc_sim.c             |  10 ++--
>  hw/palm.c                     |   9 +--
>  hw/pc_piix.c                  |  50 ++++++++--------
>  hw/petalogix_ml605_mmu.c      |   8 +--
>  hw/petalogix_s3adsp1800_mmu.c |   8 +--
>  hw/ppc/e500plat.c             |  13 +++--
>  hw/ppc/mpc8544ds.c            |  13 +++--
>  hw/ppc405_boards.c            |  25 ++++----
>  hw/ppc440_bamboo.c            |  12 ++--
>  hw/ppc_newworld.c             |  13 +++--
>  hw/ppc_oldworld.c             |  13 +++--
>  hw/ppc_prep.c                 |  13 +++--
>  hw/puv3.c                     |   8 ++-
>  hw/r2d.c                      |   9 +--
>  hw/realview.c                 |  44 +++++++++-----
>  hw/s390-virtio.c              |  13 +++--
>  hw/shix.c                     |   6 +-
>  hw/spapr.c                    |  13 +++--
>  hw/spitz.c                    |  40 ++++++++-----
>  hw/stellaris.c                |  14 ++---
>  hw/sun4m.c                    | 133 ++++++++++++++++++++++++++----------------
>  hw/sun4u.c                    |  39 ++++++++-----
>  hw/tosa.c                     |   9 +--
>  hw/versatilepb.c              |  22 ++++---
>  hw/vexpress.c                 |  26 +++++----
>  hw/virtex_ml507.c             |  10 ++--
>  hw/xen_machine_pv.c           |  11 ++--
>  hw/xilinx_zynq.c              |   9 ++-
>  hw/xtensa_lx60.c              |  22 ++++---
>  hw/xtensa_sim.c               |  11 ++--
>  hw/z2.c                       |   9 +--
>  vl.c                          |   9 ++-
>  57 files changed, 518 insertions(+), 414 deletions(-)
>
> diff --git a/hw/alpha_dp264.c b/hw/alpha_dp264.c
> index 9eb939f..2c2e237 100644
> --- a/hw/alpha_dp264.c
> +++ b/hw/alpha_dp264.c
> @@ -42,13 +42,13 @@ static int clipper_pci_map_irq(PCIDevice *d, int irq_num)
>      return (slot + 1) * 4 + irq_num;
>  }
>
> -static void clipper_init(ram_addr_t ram_size,
> -                         const char *boot_device,
> -                         const char *kernel_filename,
> -                         const char *kernel_cmdline,
> -                         const char *initrd_filename,
> -                         const char *cpu_model)
> +static void clipper_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      CPUAlphaState *cpus[4];
>      PCIBus *pci_bus;
>      ISABus *isa_bus;
> diff --git a/hw/an5206.c b/hw/an5206.c
> index 25407c0..042c5fc 100644
> --- a/hw/an5206.c
> +++ b/hw/an5206.c
> @@ -19,11 +19,11 @@
>
>  /* Board init.  */
>
> -static void an5206_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void an5206_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
>      CPUM68KState *env;
>      int kernel_size;
>      uint64_t elf_entry;
> diff --git a/hw/axis_dev88.c b/hw/axis_dev88.c
> index eab6327..2fd7356 100644
> --- a/hw/axis_dev88.c
> +++ b/hw/axis_dev88.c
> @@ -242,11 +242,12 @@ static const MemoryRegionOps gpio_ops = {
>  static struct cris_load_info li;
>
>  static
> -void axisdev88_init (ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +void axisdev88_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
>      CRISCPU *cpu;
>      CPUCRISState *env;
>      DeviceState *dev;
> diff --git a/hw/boards.h b/hw/boards.h
> index a2e0a54..813d0e5 100644
> --- a/hw/boards.h
> +++ b/hw/boards.h
> @@ -5,12 +5,16 @@
>
>  #include "qdev.h"
>
> -typedef void QEMUMachineInitFunc(ram_addr_t ram_size,
> -                                 const char *boot_device,
> -                                 const char *kernel_filename,
> -                                 const char *kernel_cmdline,
> -                                 const char *initrd_filename,
> -                                 const char *cpu_model);
> +typedef struct QEMUMachineInitArgs {
> +    ram_addr_t ram_size;
> +    const char *boot_device;
> +    const char *kernel_filename;
> +    const char *kernel_cmdline;
> +    const char *initrd_filename;
> +    const char *cpu_model;
> +} QEMUMachineInitArgs;
> +
> +typedef void QEMUMachineInitFunc(QEMUMachineInitArgs *args);
>
>  typedef void QEMUMachineResetFunc(void);
>
> diff --git a/hw/collie.c b/hw/collie.c
> index 56f89a9..695982a 100644
> --- a/hw/collie.c
> +++ b/hw/collie.c
> @@ -23,11 +23,12 @@ static struct arm_boot_info collie_binfo = {
>      .ram_size = 0x20000000,
>  };
>
> -static void collie_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void collie_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      StrongARMState *s;
>      DriveInfo *dinfo;
>      MemoryRegion *sysmem = get_system_memory();
> diff --git a/hw/dummy_m68k.c b/hw/dummy_m68k.c
> index 7cc7a99..f436a0c 100644
> --- a/hw/dummy_m68k.c
> +++ b/hw/dummy_m68k.c
> @@ -16,11 +16,11 @@
>
>  /* Board init.  */
>
> -static void dummy_m68k_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void dummy_m68k_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
>      CPUM68KState *env;
>      MemoryRegion *address_space_mem =  get_system_memory();
>      MemoryRegion *ram = g_new(MemoryRegion, 1);
> diff --git a/hw/exynos4_boards.c b/hw/exynos4_boards.c
> index 4bb0a60..4951064 100644
> --- a/hw/exynos4_boards.c
> +++ b/hw/exynos4_boards.c
> @@ -130,22 +130,22 @@ static Exynos4210State *exynos4_boards_init_common(
>              exynos4_board_ram_size[board_type]);
>  }
>
> -static void nuri_init(ram_addr_t ram_size,
> -        const char *boot_device,
> -        const char *kernel_filename, const char *kernel_cmdline,
> -        const char *initrd_filename, const char *cpu_model)
> +static void nuri_init(QEMUMachineInitArgs *args)
>  {
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      exynos4_boards_init_common(kernel_filename, kernel_cmdline,
>                  initrd_filename, EXYNOS4_BOARD_NURI);
>
>      arm_load_kernel(arm_env_get_cpu(first_cpu), &exynos4_board_binfo);
>  }
>
> -static void smdkc210_init(ram_addr_t ram_size,
> -        const char *boot_device,
> -        const char *kernel_filename, const char *kernel_cmdline,
> -        const char *initrd_filename, const char *cpu_model)
> +static void smdkc210_init(QEMUMachineInitArgs *args)
>  {
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      Exynos4210State *s = exynos4_boards_init_common(kernel_filename,
>              kernel_cmdline, initrd_filename, EXYNOS4_BOARD_SMDKC210);
>
> diff --git a/hw/gumstix.c b/hw/gumstix.c
> index 13a36ea..4103a88 100644
> --- a/hw/gumstix.c
> +++ b/hw/gumstix.c
> @@ -45,10 +45,7 @@
>
>  static const int sector_len = 128 * 1024;
>
> -static void connex_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void connex_init(QEMUMachineInitArgs *args)
>  {
>      PXA2xxState *cpu;
>      DriveInfo *dinfo;
> @@ -84,11 +81,9 @@ static void connex_init(ram_addr_t ram_size,
>                      qdev_get_gpio_in(cpu->gpio, 36));
>  }
>
> -static void verdex_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void verdex_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
>      PXA2xxState *cpu;
>      DriveInfo *dinfo;
>      int be;
> diff --git a/hw/highbank.c b/hw/highbank.c
> index 11aa131..15036b6 100644
> --- a/hw/highbank.c
> +++ b/hw/highbank.c
> @@ -187,11 +187,13 @@ static struct arm_boot_info highbank_binfo;
>   * 32-bit host, set the reg value of memory to 0xf7ff00000 in the
>   * device tree and pass -m 2047 to QEMU.
>   */
> -static void highbank_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void highbank_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      DeviceState *dev;
>      SysBusDevice *busdev;
>      qemu_irq *irqp;
> diff --git a/hw/integratorcp.c b/hw/integratorcp.c
> index d0e2e90..ac0ea83 100644
> --- a/hw/integratorcp.c
> +++ b/hw/integratorcp.c
> @@ -438,11 +438,13 @@ static struct arm_boot_info integrator_binfo = {
>      .board_id = 0x113,
>  };
>
> -static void integratorcp_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void integratorcp_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      ARMCPU *cpu;
>      MemoryRegion *address_space_mem = get_system_memory();
>      MemoryRegion *ram = g_new(MemoryRegion, 1);
> diff --git a/hw/kzm.c b/hw/kzm.c
> index 68cd1b4..d1266d9 100644
> --- a/hw/kzm.c
> +++ b/hw/kzm.c
> @@ -70,11 +70,13 @@ static struct arm_boot_info kzm_binfo = {
>      .board_id = 1722,
>  };
>
> -static void kzm_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void kzm_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      ARMCPU *cpu;
>      MemoryRegion *address_space_mem = get_system_memory();
>      MemoryRegion *ram = g_new(MemoryRegion, 1);
> diff --git a/hw/leon3.c b/hw/leon3.c
> index 878d3aa..6486b7b 100644
> --- a/hw/leon3.c
> +++ b/hw/leon3.c
> @@ -94,13 +94,11 @@ static void leon3_set_pil_in(void *opaque, uint32_t pil_in)
>      }
>  }
>
> -static void leon3_generic_hw_init(ram_addr_t  ram_size,
> -                                  const char *boot_device,
> -                                  const char *kernel_filename,
> -                                  const char *kernel_cmdline,
> -                                  const char *initrd_filename,
> -                                  const char *cpu_model)
> +static void leon3_generic_hw_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
>      SPARCCPU *cpu;
>      CPUSPARCState   *env;
>      MemoryRegion *address_space_mem = get_system_memory();
> diff --git a/hw/lm32_boards.c b/hw/lm32_boards.c
> index b76d800..c5a62c8 100644
> --- a/hw/lm32_boards.c
> +++ b/hw/lm32_boards.c
> @@ -69,12 +69,10 @@ static void main_cpu_reset(void *opaque)
>      env->deba = reset_info->flash_base;
>  }
>
> -static void lm32_evr_init(ram_addr_t ram_size_not_used,
> -                          const char *boot_device,
> -                          const char *kernel_filename,
> -                          const char *kernel_cmdline,
> -                          const char *initrd_filename, const char *cpu_model)
> +static void lm32_evr_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
>      LM32CPU *cpu;
>      CPULM32State *env;
>      DriveInfo *dinfo;
> @@ -159,12 +157,12 @@ static void lm32_evr_init(ram_addr_t ram_size_not_used,
>      qemu_register_reset(main_cpu_reset, reset_info);
>  }
>
> -static void lm32_uclinux_init(ram_addr_t ram_size_not_used,
> -                          const char *boot_device,
> -                          const char *kernel_filename,
> -                          const char *kernel_cmdline,
> -                          const char *initrd_filename, const char *cpu_model)
> +static void lm32_uclinux_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      LM32CPU *cpu;
>      CPULM32State *env;
>      DriveInfo *dinfo;
> diff --git a/hw/mainstone.c b/hw/mainstone.c
> index 97687b6..c0d6034 100644
> --- a/hw/mainstone.c
> +++ b/hw/mainstone.c
> @@ -171,11 +171,13 @@ static void mainstone_common_init(MemoryRegion *address_space_mem,
>      arm_load_kernel(mpu->cpu, &mainstone_binfo);
>  }
>
> -static void mainstone_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void mainstone_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      mainstone_common_init(get_system_memory(), ram_size, kernel_filename,
>                  kernel_cmdline, initrd_filename, cpu_model, mainstone, 0x196);
>  }
> diff --git a/hw/mcf5208.c b/hw/mcf5208.c
> index ee25b1b..688bc3c 100644
> --- a/hw/mcf5208.c
> +++ b/hw/mcf5208.c
> @@ -187,11 +187,11 @@ static void mcf5208_sys_init(MemoryRegion *address_space, qemu_irq *pic)
>      }
>  }
>
> -static void mcf5208evb_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void mcf5208evb_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
>      CPUM68KState *env;
>      int kernel_size;
>      uint64_t elf_entry;
> diff --git a/hw/milkymist.c b/hw/milkymist.c
> index 2e7235b..ca9ed43 100644
> --- a/hw/milkymist.c
> +++ b/hw/milkymist.c
> @@ -73,12 +73,12 @@ static void main_cpu_reset(void *opaque)
>  }
>
>  static void
> -milkymist_init(ram_addr_t ram_size_not_used,
> -                          const char *boot_device,
> -                          const char *kernel_filename,
> -                          const char *kernel_cmdline,
> -                          const char *initrd_filename, const char *cpu_model)
> +milkymist_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      LM32CPU *cpu;
>      CPULM32State *env;
>      int kernel_size;
> diff --git a/hw/mips_fulong2e.c b/hw/mips_fulong2e.c
> index 38e4b86..af7bb50 100644
> --- a/hw/mips_fulong2e.c
> +++ b/hw/mips_fulong2e.c
> @@ -256,10 +256,13 @@ static void cpu_request_exit(void *opaque, int irq, int level)
>      }
>  }
>
> -static void mips_fulong2e_init(ram_addr_t ram_size, const char *boot_device,
> -                        const char *kernel_filename, const char *kernel_cmdline,
> -                        const char *initrd_filename, const char *cpu_model)
> +static void mips_fulong2e_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      char *filename;
>      MemoryRegion *address_space_mem = get_system_memory();
>      MemoryRegion *ram = g_new(MemoryRegion, 1);
> diff --git a/hw/mips_jazz.c b/hw/mips_jazz.c
> index db927f1..14df4d7 100644
> --- a/hw/mips_jazz.c
> +++ b/hw/mips_jazz.c
> @@ -302,21 +302,19 @@ static void mips_jazz_init(MemoryRegion *address_space,
>  }
>
>  static
> -void mips_magnum_init (ram_addr_t ram_size,
> -                       const char *boot_device,
> -                       const char *kernel_filename, const char *kernel_cmdline,
> -                       const char *initrd_filename, const char *cpu_model)
> +void mips_magnum_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
>          mips_jazz_init(get_system_memory(), get_system_io(),
>                         ram_size, cpu_model, JAZZ_MAGNUM);
>  }
>
>  static
> -void mips_pica61_init (ram_addr_t ram_size,
> -                       const char *boot_device,
> -                       const char *kernel_filename, const char *kernel_cmdline,
> -                       const char *initrd_filename, const char *cpu_model)
> +void mips_pica61_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
>      mips_jazz_init(get_system_memory(), get_system_io(),
>                     ram_size, cpu_model, JAZZ_PICA61);
>  }
> diff --git a/hw/mips_malta.c b/hw/mips_malta.c
> index ad23f26..14151f9 100644
> --- a/hw/mips_malta.c
> +++ b/hw/mips_malta.c
> @@ -777,11 +777,13 @@ static void cpu_request_exit(void *opaque, int irq, int level)
>  }
>
>  static
> -void mips_malta_init (ram_addr_t ram_size,
> -                      const char *boot_device,
> -                      const char *kernel_filename, const char *kernel_cmdline,
> -                      const char *initrd_filename, const char *cpu_model)
> +void mips_malta_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      char *filename;
>      pflash_t *fl;
>      MemoryRegion *system_memory = get_system_memory();
> diff --git a/hw/mips_mipssim.c b/hw/mips_mipssim.c
> index 830f635..a1d3945 100644
> --- a/hw/mips_mipssim.c
> +++ b/hw/mips_mipssim.c
> @@ -131,11 +131,13 @@ static void mipsnet_init(int base, qemu_irq irq, NICInfo *nd)
>  }
>
>  static void
> -mips_mipssim_init (ram_addr_t ram_size,
> -                   const char *boot_device,
> -                   const char *kernel_filename, const char *kernel_cmdline,
> -                   const char *initrd_filename, const char *cpu_model)
> +mips_mipssim_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      char *filename;
>      MemoryRegion *address_space_mem = get_system_memory();
>      MemoryRegion *ram = g_new(MemoryRegion, 1);
> diff --git a/hw/mips_r4k.c b/hw/mips_r4k.c
> index 967a76e..b73cdc3 100644
> --- a/hw/mips_r4k.c
> +++ b/hw/mips_r4k.c
> @@ -151,11 +151,13 @@ static void main_cpu_reset(void *opaque)
>
>  static const int sector_len = 32 * 1024;
>  static
> -void mips_r4k_init (ram_addr_t ram_size,
> -                    const char *boot_device,
> -                    const char *kernel_filename, const char *kernel_cmdline,
> -                    const char *initrd_filename, const char *cpu_model)
> +void mips_r4k_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      char *filename;
>      MemoryRegion *address_space_mem = get_system_memory();
>      MemoryRegion *ram = g_new(MemoryRegion, 1);
> diff --git a/hw/musicpal.c b/hw/musicpal.c
> index f305e21..f06814c 100644
> --- a/hw/musicpal.c
> +++ b/hw/musicpal.c
> @@ -1508,11 +1508,12 @@ static struct arm_boot_info musicpal_binfo = {
>      .board_id = 0x20e,
>  };
>
> -static void musicpal_init(ram_addr_t ram_size,
> -               const char *boot_device,
> -               const char *kernel_filename, const char *kernel_cmdline,
> -               const char *initrd_filename, const char *cpu_model)
> +static void musicpal_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      ARMCPU *cpu;
>      qemu_irq *cpu_pic;
>      qemu_irq pic[32];
> diff --git a/hw/nseries.c b/hw/nseries.c
> index 6df71eb..7ada90d 100644
> --- a/hw/nseries.c
> +++ b/hw/nseries.c
> @@ -1397,21 +1397,27 @@ static struct arm_boot_info n810_binfo = {
>      .atag_board = n810_atag_setup,
>  };
>
> -static void n800_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void n800_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      return n8x0_init(ram_size, boot_device,
>                      kernel_filename, kernel_cmdline, initrd_filename,
>                      cpu_model, &n800_binfo, 800);
>  }
>
> -static void n810_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void n810_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      return n8x0_init(ram_size, boot_device,
>                      kernel_filename, kernel_cmdline, initrd_filename,
>                      cpu_model, &n810_binfo, 810);
> diff --git a/hw/null-machine.c b/hw/null-machine.c
> index 69910d3..d813c08 100644
> --- a/hw/null-machine.c
> +++ b/hw/null-machine.c
> @@ -15,12 +15,7 @@
>  #include "hw/hw.h"
>  #include "hw/boards.h"
>
> -static void machine_none_init(ram_addr_t ram_size,
> -                              const char *boot_device,
> -                              const char *kernel_filename,
> -                              const char *kernel_cmdline,
> -                              const char *initrd_filename,
> -                              const char *cpu_model)
> +static void machine_none_init(QEMUMachineInitArgs *args)
>  {
>  }
>
> diff --git a/hw/omap_sx1.c b/hw/omap_sx1.c
> index abca341..ad17487 100644
> --- a/hw/omap_sx1.c
> +++ b/hw/omap_sx1.c
> @@ -209,20 +209,26 @@ static void sx1_init(ram_addr_t ram_size,
>      //~ qemu_console_resize(ds, 640, 480);
>  }
>
> -static void sx1_init_v1(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void sx1_init_v1(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sx1_init(ram_size, boot_device, kernel_filename,
>                  kernel_cmdline, initrd_filename, cpu_model, 1);
>  }
>
> -static void sx1_init_v2(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void sx1_init_v2(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sx1_init(ram_size, boot_device, kernel_filename,
>                  kernel_cmdline, initrd_filename, cpu_model, 2);
>  }
> diff --git a/hw/openrisc_sim.c b/hw/openrisc_sim.c
> index 55e97f0..e96a944 100644
> --- a/hw/openrisc_sim.c
> +++ b/hw/openrisc_sim.c
> @@ -90,13 +90,11 @@ static void cpu_openrisc_load_kernel(ram_addr_t ram_size,
>      cpu->env.pc = entry;
>  }
>
> -static void openrisc_sim_init(ram_addr_t ram_size,
> -                              const char *boot_device,
> -                              const char *kernel_filename,
> -                              const char *kernel_cmdline,
> -                              const char *initrd_filename,
> -                              const char *cpu_model)
> +static void openrisc_sim_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
>     OpenRISCCPU *cpu = NULL;
>      MemoryRegion *ram;
>      int n;
> diff --git a/hw/palm.c b/hw/palm.c
> index bacdc90..032b8d6 100644
> --- a/hw/palm.c
> +++ b/hw/palm.c
> @@ -190,11 +190,12 @@ static struct arm_boot_info palmte_binfo = {
>      .board_id = 0x331,
>  };
>
> -static void palmte_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void palmte_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      MemoryRegion *address_space_mem = get_system_memory();
>      struct omap_mpu_state_s *mpu;
>      int flash_size = 0x00800000;
> diff --git a/hw/pc_piix.c b/hw/pc_piix.c
> index fd5898f..c9fca05 100644
> --- a/hw/pc_piix.c
> +++ b/hw/pc_piix.c
> @@ -287,13 +287,14 @@ static void pc_init1(MemoryRegion *system_memory,
>      }
>  }
>
> -static void pc_init_pci(ram_addr_t ram_size,
> -                        const char *boot_device,
> -                        const char *kernel_filename,
> -                        const char *kernel_cmdline,
> -                        const char *initrd_filename,
> -                        const char *cpu_model)
> +static void pc_init_pci(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      pc_init1(get_system_memory(),
>               get_system_io(),
>               ram_size, boot_device,
> @@ -301,13 +302,14 @@ static void pc_init_pci(ram_addr_t ram_size,
>               initrd_filename, cpu_model, 1, 1);
>  }
>
> -static void pc_init_pci_no_kvmclock(ram_addr_t ram_size,
> -                                    const char *boot_device,
> -                                    const char *kernel_filename,
> -                                    const char *kernel_cmdline,
> -                                    const char *initrd_filename,
> -                                    const char *cpu_model)
> +static void pc_init_pci_no_kvmclock(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      pc_init1(get_system_memory(),
>               get_system_io(),
>               ram_size, boot_device,
> @@ -315,13 +317,14 @@ static void pc_init_pci_no_kvmclock(ram_addr_t ram_size,
>               initrd_filename, cpu_model, 1, 0);
>  }
>
> -static void pc_init_isa(ram_addr_t ram_size,
> -                        const char *boot_device,
> -                        const char *kernel_filename,
> -                        const char *kernel_cmdline,
> -                        const char *initrd_filename,
> -                        const char *cpu_model)
> +static void pc_init_isa(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      if (cpu_model == NULL)
>          cpu_model = "486";
>      pc_init1(get_system_memory(),
> @@ -332,19 +335,12 @@ static void pc_init_isa(ram_addr_t ram_size,
>  }
>
>  #ifdef CONFIG_XEN
> -static void pc_xen_hvm_init(ram_addr_t ram_size,
> -                            const char *boot_device,
> -                            const char *kernel_filename,
> -                            const char *kernel_cmdline,
> -                            const char *initrd_filename,
> -                            const char *cpu_model)
> +static void pc_xen_hvm_init(QEMUMachineInitArgs *args)
>  {
>      if (xen_hvm_init() != 0) {
>          hw_error("xen hardware virtual machine initialisation failed");
>      }
> -    pc_init_pci_no_kvmclock(ram_size, boot_device,
> -                            kernel_filename, kernel_cmdline,
> -                            initrd_filename, cpu_model);
> +    pc_init_pci_no_kvmclock(args);
>      xen_vcpu_init();
>  }
>  #endif
> diff --git a/hw/petalogix_ml605_mmu.c b/hw/petalogix_ml605_mmu.c
> index dced648..ace0187 100644
> --- a/hw/petalogix_ml605_mmu.c
> +++ b/hw/petalogix_ml605_mmu.c
> @@ -70,12 +70,10 @@ static void machine_cpu_reset(MicroBlazeCPU *cpu)
>  }
>
>  static void
> -petalogix_ml605_init(ram_addr_t ram_size,
> -                          const char *boot_device,
> -                          const char *kernel_filename,
> -                          const char *kernel_cmdline,
> -                          const char *initrd_filename, const char *cpu_model)
> +petalogix_ml605_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
>      MemoryRegion *address_space_mem = get_system_memory();
>      DeviceState *dev, *dma, *eth0;
>      MicroBlazeCPU *cpu;
> diff --git a/hw/petalogix_s3adsp1800_mmu.c b/hw/petalogix_s3adsp1800_mmu.c
> index 2cf6882..71c32ce 100644
> --- a/hw/petalogix_s3adsp1800_mmu.c
> +++ b/hw/petalogix_s3adsp1800_mmu.c
> @@ -57,12 +57,10 @@ static void machine_cpu_reset(MicroBlazeCPU *cpu)
>  }
>
>  static void
> -petalogix_s3adsp1800_init(ram_addr_t ram_size,
> -                          const char *boot_device,
> -                          const char *kernel_filename,
> -                          const char *kernel_cmdline,
> -                          const char *initrd_filename, const char *cpu_model)
> +petalogix_s3adsp1800_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
>      DeviceState *dev;
>      MicroBlazeCPU *cpu;
>      CPUMBState *env;
> diff --git a/hw/ppc/e500plat.c b/hw/ppc/e500plat.c
> index 60a5cb3..4cfb940 100644
> --- a/hw/ppc/e500plat.c
> +++ b/hw/ppc/e500plat.c
> @@ -25,13 +25,14 @@ static void e500plat_fixup_devtree(PPCE500Params *params, void *fdt)
>                           sizeof(compatible));
>  }
>
> -static void e500plat_init(ram_addr_t ram_size,
> -                           const char *boot_device,
> -                           const char *kernel_filename,
> -                           const char *kernel_cmdline,
> -                           const char *initrd_filename,
> -                           const char *cpu_model)
> +static void e500plat_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *boot_device = args->boot_device;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      PPCE500Params params = {
>          .ram_size = ram_size,
>          .boot_device = boot_device,
> diff --git a/hw/ppc/mpc8544ds.c b/hw/ppc/mpc8544ds.c
> index 984d21c..e651661 100644
> --- a/hw/ppc/mpc8544ds.c
> +++ b/hw/ppc/mpc8544ds.c
> @@ -25,13 +25,14 @@ static void mpc8544ds_fixup_devtree(PPCE500Params *params, void *fdt)
>                           sizeof(compatible));
>  }
>
> -static void mpc8544ds_init(ram_addr_t ram_size,
> -                           const char *boot_device,
> -                           const char *kernel_filename,
> -                           const char *kernel_cmdline,
> -                           const char *initrd_filename,
> -                           const char *cpu_model)
> +static void mpc8544ds_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *boot_device = args->boot_device;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      PPCE500Params params = {
>          .ram_size = ram_size,
>          .boot_device = boot_device,
> diff --git a/hw/ppc405_boards.c b/hw/ppc405_boards.c
> index 476775d..e848cb0 100644
> --- a/hw/ppc405_boards.c
> +++ b/hw/ppc405_boards.c
> @@ -158,7 +158,7 @@ static void ref405ep_fpga_reset (void *opaque)
>      fpga->reg1 = 0x0F;
>  }
>
> -static void ref405ep_fpga_init (MemoryRegion *sysmem, uint32_t base)
> +static void ref405ep_fpga_init(MemoryRegion *sysmem, uint32_t base)
>  {
>      ref405ep_fpga_t *fpga;
>      MemoryRegion *fpga_memory = g_new(MemoryRegion, 1);
> @@ -170,13 +170,12 @@ static void ref405ep_fpga_init (MemoryRegion *sysmem, uint32_t base)
>      qemu_register_reset(&ref405ep_fpga_reset, fpga);
>  }
>
> -static void ref405ep_init (ram_addr_t ram_size,
> -                           const char *boot_device,
> -                           const char *kernel_filename,
> -                           const char *kernel_cmdline,
> -                           const char *initrd_filename,
> -                           const char *cpu_model)
> +static void ref405ep_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      char *filename;
>      ppc4xx_bd_info_t bd;
>      CPUPPCState *env;
> @@ -484,7 +483,7 @@ static void taihu_cpld_reset (void *opaque)
>      cpld->reg1 = 0x80;
>  }
>
> -static void taihu_cpld_init (MemoryRegion *sysmem, uint32_t base)
> +static void taihu_cpld_init(MemoryRegion *sysmem, uint32_t base)
>  {
>      taihu_cpld_t *cpld;
>      MemoryRegion *cpld_memory = g_new(MemoryRegion, 1);
> @@ -495,13 +494,11 @@ static void taihu_cpld_init (MemoryRegion *sysmem, uint32_t base)
>      qemu_register_reset(&taihu_cpld_reset, cpld);
>  }
>
> -static void taihu_405ep_init(ram_addr_t ram_size,
> -                             const char *boot_device,
> -                             const char *kernel_filename,
> -                             const char *kernel_cmdline,
> -                             const char *initrd_filename,
> -                             const char *cpu_model)
> +static void taihu_405ep_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *initrd_filename = args->initrd_filename;
>      char *filename;
>      qemu_irq *pic;
>      MemoryRegion *sysmem = get_system_memory();
> diff --git a/hw/ppc440_bamboo.c b/hw/ppc440_bamboo.c
> index c198071..78e7985 100644
> --- a/hw/ppc440_bamboo.c
> +++ b/hw/ppc440_bamboo.c
> @@ -157,13 +157,13 @@ static void main_cpu_reset(void *opaque)
>      mmubooke_create_initial_mapping(env, 0, 0);
>  }
>
> -static void bamboo_init(ram_addr_t ram_size,
> -                        const char *boot_device,
> -                        const char *kernel_filename,
> -                        const char *kernel_cmdline,
> -                        const char *initrd_filename,
> -                        const char *cpu_model)
> +static void bamboo_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      unsigned int pci_irq_nrs[4] = { 28, 27, 26, 25 };
>      MemoryRegion *address_space_mem = get_system_memory();
>      MemoryRegion *ram_memories
> diff --git a/hw/ppc_newworld.c b/hw/ppc_newworld.c
> index e95cfe8..e7c0747 100644
> --- a/hw/ppc_newworld.c
> +++ b/hw/ppc_newworld.c
> @@ -129,13 +129,14 @@ static void ppc_core99_reset(void *opaque)
>  }
>
>  /* PowerPC Mac99 hardware initialisation */
> -static void ppc_core99_init (ram_addr_t ram_size,
> -                             const char *boot_device,
> -                             const char *kernel_filename,
> -                             const char *kernel_cmdline,
> -                             const char *initrd_filename,
> -                             const char *cpu_model)
> +static void ppc_core99_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      PowerPCCPU *cpu = NULL;
>      CPUPPCState *env = NULL;
>      char *filename;
> diff --git a/hw/ppc_oldworld.c b/hw/ppc_oldworld.c
> index 1dcd8a6..d9f76a8 100644
> --- a/hw/ppc_oldworld.c
> +++ b/hw/ppc_oldworld.c
> @@ -72,13 +72,14 @@ static void ppc_heathrow_reset(void *opaque)
>      cpu_reset(CPU(cpu));
>  }
>
> -static void ppc_heathrow_init (ram_addr_t ram_size,
> -                               const char *boot_device,
> -                               const char *kernel_filename,
> -                               const char *kernel_cmdline,
> -                               const char *initrd_filename,
> -                               const char *cpu_model)
> +static void ppc_heathrow_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      MemoryRegion *sysmem = get_system_memory();
>      PowerPCCPU *cpu = NULL;
>      CPUPPCState *env = NULL;
> diff --git a/hw/ppc_prep.c b/hw/ppc_prep.c
> index 592b7b2..f51f78a 100644
> --- a/hw/ppc_prep.c
> +++ b/hw/ppc_prep.c
> @@ -448,13 +448,14 @@ static void ppc_prep_reset(void *opaque)
>  }
>
>  /* PowerPC PREP hardware initialisation */
> -static void ppc_prep_init (ram_addr_t ram_size,
> -                           const char *boot_device,
> -                           const char *kernel_filename,
> -                           const char *kernel_cmdline,
> -                           const char *initrd_filename,
> -                           const char *cpu_model)
> +static void ppc_prep_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      MemoryRegion *sysmem = get_system_memory();
>      PowerPCCPU *cpu = NULL;
>      CPUPPCState *env = NULL;
> diff --git a/hw/puv3.c b/hw/puv3.c
> index 43f7216..764799c 100644
> --- a/hw/puv3.c
> +++ b/hw/puv3.c
> @@ -91,10 +91,12 @@ static void puv3_load_kernel(const char *kernel_filename)
>      graphic_console_init(NULL, NULL, NULL, NULL, NULL);
>  }
>
> -static void puv3_init(ram_addr_t ram_size, const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void puv3_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *initrd_filename = args->initrd_filename;
>      CPUUniCore32State *env;
>
>      if (initrd_filename) {
> diff --git a/hw/r2d.c b/hw/r2d.c
> index 0f16e81..5daa42f 100644
> --- a/hw/r2d.c
> +++ b/hw/r2d.c
> @@ -219,11 +219,12 @@ static struct QEMU_PACKED
>      char kernel_cmdline[256];
>  } boot_params;
>
> -static void r2d_init(ram_addr_t ram_size,
> -              const char *boot_device,
> -             const char *kernel_filename, const char *kernel_cmdline,
> -             const char *initrd_filename, const char *cpu_model)
> +static void r2d_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      SuperHCPU *cpu;
>      CPUSH4State *env;
>      ResetData *reset_info;
> diff --git a/hw/realview.c b/hw/realview.c
> index 19db4d0..8dc4be6 100644
> --- a/hw/realview.c
> +++ b/hw/realview.c
> @@ -330,11 +330,14 @@ static void realview_init(ram_addr_t ram_size,
>      arm_load_kernel(arm_env_get_cpu(first_cpu), &realview_binfo);
>  }
>
> -static void realview_eb_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void realview_eb_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      if (!cpu_model) {
>          cpu_model = "arm926";
>      }
> @@ -342,11 +345,14 @@ static void realview_eb_init(ram_addr_t ram_size,
>                    initrd_filename, cpu_model, BOARD_EB);
>  }
>
> -static void realview_eb_mpcore_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void realview_eb_mpcore_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      if (!cpu_model) {
>          cpu_model = "arm11mpcore";
>      }
> @@ -354,11 +360,14 @@ static void realview_eb_mpcore_init(ram_addr_t ram_size,
>                    initrd_filename, cpu_model, BOARD_EB_MPCORE);
>  }
>
> -static void realview_pb_a8_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void realview_pb_a8_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      if (!cpu_model) {
>          cpu_model = "cortex-a8";
>      }
> @@ -366,11 +375,14 @@ static void realview_pb_a8_init(ram_addr_t ram_size,
>                    initrd_filename, cpu_model, BOARD_PB_A8);
>  }
>
> -static void realview_pbx_a9_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void realview_pbx_a9_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      if (!cpu_model) {
>          cpu_model = "cortex-a9";
>      }
> diff --git a/hw/s390-virtio.c b/hw/s390-virtio.c
> index 47eed35..39ff178 100644
> --- a/hw/s390-virtio.c
> +++ b/hw/s390-virtio.c
> @@ -151,13 +151,14 @@ unsigned s390_del_running_cpu(CPUS390XState *env)
>  }
>
>  /* PC hardware initialisation */
> -static void s390_init(ram_addr_t my_ram_size,
> -                      const char *boot_device,
> -                      const char *kernel_filename,
> -                      const char *kernel_cmdline,
> -                      const char *initrd_filename,
> -                      const char *cpu_model)
> +static void s390_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t my_ram_size = args->ram_size;
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      CPUS390XState *env = NULL;
>      MemoryRegion *sysmem = get_system_memory();
>      MemoryRegion *ram = g_new(MemoryRegion, 1);
> diff --git a/hw/shix.c b/hw/shix.c
> index dd9ce17..b56dd54 100644
> --- a/hw/shix.c
> +++ b/hw/shix.c
> @@ -37,11 +37,9 @@
>  #define BIOS_FILENAME "shix_bios.bin"
>  #define BIOS_ADDRESS 0xA0000000
>
> -static void shix_init(ram_addr_t ram_size,
> -               const char *boot_device,
> -              const char *kernel_filename, const char *kernel_cmdline,
> -              const char *initrd_filename, const char *cpu_model)
> +static void shix_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
>      int ret;
>      CPUSH4State *env;
>      struct SH7750State *s;
> diff --git a/hw/spapr.c b/hw/spapr.c
> index c34b767..8921c4d 100644
> --- a/hw/spapr.c
> +++ b/hw/spapr.c
> @@ -603,13 +603,14 @@ static int spapr_vga_init(PCIBus *pci_bus)
>  }
>
>  /* pSeries LPAR / sPAPR hardware init */
> -static void ppc_spapr_init(ram_addr_t ram_size,
> -                           const char *boot_device,
> -                           const char *kernel_filename,
> -                           const char *kernel_cmdline,
> -                           const char *initrd_filename,
> -                           const char *cpu_model)
> +static void ppc_spapr_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      PowerPCCPU *cpu;
>      CPUPPCState *env;
>      PCIHostState *phb;
> diff --git a/hw/spitz.c b/hw/spitz.c
> index 20e7835..df829b3 100644
> --- a/hw/spitz.c
> +++ b/hw/spitz.c
> @@ -936,38 +936,46 @@ static void spitz_common_init(ram_addr_t ram_size,
>      sl_bootparam_write(SL_PXA_PARAM_BASE);
>  }
>
> -static void spitz_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void spitz_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      spitz_common_init(ram_size, kernel_filename,
>                  kernel_cmdline, initrd_filename, cpu_model, spitz, 0x2c9);
>  }
>
> -static void borzoi_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void borzoi_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      spitz_common_init(ram_size, kernel_filename,
>                  kernel_cmdline, initrd_filename, cpu_model, borzoi, 0x33f);
>  }
>
> -static void akita_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void akita_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      spitz_common_init(ram_size, kernel_filename,
>                  kernel_cmdline, initrd_filename, cpu_model, akita, 0x2e8);
>  }
>
> -static void terrier_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void terrier_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      spitz_common_init(ram_size, kernel_filename,
>                  kernel_cmdline, initrd_filename, cpu_model, terrier, 0x33f);
>  }
> diff --git a/hw/stellaris.c b/hw/stellaris.c
> index 562fbbf..b79c7fb 100644
> --- a/hw/stellaris.c
> +++ b/hw/stellaris.c
> @@ -1358,19 +1358,17 @@ static void stellaris_init(const char *kernel_filename, const char *cpu_model,
>  }
>
>  /* FIXME: Figure out how to generate these from stellaris_boards.  */
> -static void lm3s811evb_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void lm3s811evb_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
>      stellaris_init(kernel_filename, cpu_model, &stellaris_boards[0]);
>  }
>
> -static void lm3s6965evb_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void lm3s6965evb_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
>      stellaris_init(kernel_filename, cpu_model, &stellaris_boards[1]);
>  }
>
> diff --git a/hw/sun4m.c b/hw/sun4m.c
> index c98cd5e..22e011f 100644
> --- a/hw/sun4m.c
> +++ b/hw/sun4m.c
> @@ -1303,92 +1303,118 @@ static const struct sun4m_hwdef sun4m_hwdefs[] = {
>  };
>
>  /* SPARCstation 5 hardware initialisation */
> -static void ss5_init(ram_addr_t RAM_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void ss5_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sun4m_hw_init(&sun4m_hwdefs[0], RAM_size, boot_device, kernel_filename,
>                    kernel_cmdline, initrd_filename, cpu_model);
>  }
>
>  /* SPARCstation 10 hardware initialisation */
> -static void ss10_init(ram_addr_t RAM_size,
> -                      const char *boot_device,
> -                      const char *kernel_filename, const char *kernel_cmdline,
> -                      const char *initrd_filename, const char *cpu_model)
> +static void ss10_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sun4m_hw_init(&sun4m_hwdefs[1], RAM_size, boot_device, kernel_filename,
>                    kernel_cmdline, initrd_filename, cpu_model);
>  }
>
>  /* SPARCserver 600MP hardware initialisation */
> -static void ss600mp_init(ram_addr_t RAM_size,
> -                         const char *boot_device,
> -                         const char *kernel_filename,
> -                         const char *kernel_cmdline,
> -                         const char *initrd_filename, const char *cpu_model)
> +static void ss600mp_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sun4m_hw_init(&sun4m_hwdefs[2], RAM_size, boot_device, kernel_filename,
>                    kernel_cmdline, initrd_filename, cpu_model);
>  }
>
>  /* SPARCstation 20 hardware initialisation */
> -static void ss20_init(ram_addr_t RAM_size,
> -                      const char *boot_device,
> -                      const char *kernel_filename, const char *kernel_cmdline,
> -                      const char *initrd_filename, const char *cpu_model)
> +static void ss20_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sun4m_hw_init(&sun4m_hwdefs[3], RAM_size, boot_device, kernel_filename,
>                    kernel_cmdline, initrd_filename, cpu_model);
>  }
>
>  /* SPARCstation Voyager hardware initialisation */
> -static void vger_init(ram_addr_t RAM_size,
> -                      const char *boot_device,
> -                      const char *kernel_filename, const char *kernel_cmdline,
> -                      const char *initrd_filename, const char *cpu_model)
> +static void vger_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sun4m_hw_init(&sun4m_hwdefs[4], RAM_size, boot_device, kernel_filename,
>                    kernel_cmdline, initrd_filename, cpu_model);
>  }
>
>  /* SPARCstation LX hardware initialisation */
> -static void ss_lx_init(ram_addr_t RAM_size,
> -                       const char *boot_device,
> -                       const char *kernel_filename, const char *kernel_cmdline,
> -                       const char *initrd_filename, const char *cpu_model)
> +static void ss_lx_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sun4m_hw_init(&sun4m_hwdefs[5], RAM_size, boot_device, kernel_filename,
>                    kernel_cmdline, initrd_filename, cpu_model);
>  }
>
>  /* SPARCstation 4 hardware initialisation */
> -static void ss4_init(ram_addr_t RAM_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void ss4_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sun4m_hw_init(&sun4m_hwdefs[6], RAM_size, boot_device, kernel_filename,
>                    kernel_cmdline, initrd_filename, cpu_model);
>  }
>
>  /* SPARCClassic hardware initialisation */
> -static void scls_init(ram_addr_t RAM_size,
> -                      const char *boot_device,
> -                      const char *kernel_filename, const char *kernel_cmdline,
> -                      const char *initrd_filename, const char *cpu_model)
> +static void scls_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sun4m_hw_init(&sun4m_hwdefs[7], RAM_size, boot_device, kernel_filename,
>                    kernel_cmdline, initrd_filename, cpu_model);
>  }
>
>  /* SPARCbook hardware initialisation */
> -static void sbook_init(ram_addr_t RAM_size,
> -                       const char *boot_device,
> -                       const char *kernel_filename, const char *kernel_cmdline,
> -                       const char *initrd_filename, const char *cpu_model)
> +static void sbook_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sun4m_hw_init(&sun4m_hwdefs[8], RAM_size, boot_device, kernel_filename,
>                    kernel_cmdline, initrd_filename, cpu_model);
>  }
> @@ -1651,21 +1677,27 @@ static void sun4d_hw_init(const struct sun4d_hwdef *hwdef, ram_addr_t RAM_size,
>  }
>
>  /* SPARCserver 1000 hardware initialisation */
> -static void ss1000_init(ram_addr_t RAM_size,
> -                        const char *boot_device,
> -                        const char *kernel_filename, const char *kernel_cmdline,
> -                        const char *initrd_filename, const char *cpu_model)
> +static void ss1000_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sun4d_hw_init(&sun4d_hwdefs[0], RAM_size, boot_device, kernel_filename,
>                    kernel_cmdline, initrd_filename, cpu_model);
>  }
>
>  /* SPARCcenter 2000 hardware initialisation */
> -static void ss2000_init(ram_addr_t RAM_size,
> -                        const char *boot_device,
> -                        const char *kernel_filename, const char *kernel_cmdline,
> -                        const char *initrd_filename, const char *cpu_model)
> +static void ss2000_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sun4d_hw_init(&sun4d_hwdefs[1], RAM_size, boot_device, kernel_filename,
>                    kernel_cmdline, initrd_filename, cpu_model);
>  }
> @@ -1845,11 +1877,14 @@ static void sun4c_hw_init(const struct sun4c_hwdef *hwdef, ram_addr_t RAM_size,
>  }
>
>  /* SPARCstation 2 hardware initialisation */
> -static void ss2_init(ram_addr_t RAM_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void ss2_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sun4c_hw_init(&sun4c_hwdefs[0], RAM_size, boot_device, kernel_filename,
>                    kernel_cmdline, initrd_filename, cpu_model);
>  }
> diff --git a/hw/sun4u.c b/hw/sun4u.c
> index 07cd042..379768c 100644
> --- a/hw/sun4u.c
> +++ b/hw/sun4u.c
> @@ -930,31 +930,40 @@ static const struct hwdef hwdefs[] = {
>  };
>
>  /* Sun4u hardware initialisation */
> -static void sun4u_init(ram_addr_t RAM_size,
> -                       const char *boot_devices,
> -                       const char *kernel_filename, const char *kernel_cmdline,
> -                       const char *initrd_filename, const char *cpu_model)
> -{
> +static void sun4u_init(QEMUMachineInitArgs *args)
> +{
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_devices = args->boot_device;
>      sun4uv_init(get_system_memory(), RAM_size, boot_devices, kernel_filename,
>                  kernel_cmdline, initrd_filename, cpu_model, &hwdefs[0]);
>  }
>
>  /* Sun4v hardware initialisation */
> -static void sun4v_init(ram_addr_t RAM_size,
> -                       const char *boot_devices,
> -                       const char *kernel_filename, const char *kernel_cmdline,
> -                       const char *initrd_filename, const char *cpu_model)
> -{
> +static void sun4v_init(QEMUMachineInitArgs *args)
> +{
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_devices = args->boot_device;
>      sun4uv_init(get_system_memory(), RAM_size, boot_devices, kernel_filename,
>                  kernel_cmdline, initrd_filename, cpu_model, &hwdefs[1]);
>  }
>
>  /* Niagara hardware initialisation */
> -static void niagara_init(ram_addr_t RAM_size,
> -                         const char *boot_devices,
> -                         const char *kernel_filename, const char *kernel_cmdline,
> -                         const char *initrd_filename, const char *cpu_model)
> -{
> +static void niagara_init(QEMUMachineInitArgs *args)
> +{
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_devices = args->boot_device;
>      sun4uv_init(get_system_memory(), RAM_size, boot_devices, kernel_filename,
>                  kernel_cmdline, initrd_filename, cpu_model, &hwdefs[2]);
>  }
> diff --git a/hw/tosa.c b/hw/tosa.c
> index 297a8c2..512278c 100644
> --- a/hw/tosa.c
> +++ b/hw/tosa.c
> @@ -205,11 +205,12 @@ static struct arm_boot_info tosa_binfo = {
>      .ram_size = 0x04000000,
>  };
>
> -static void tosa_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void tosa_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      MemoryRegion *address_space_mem = get_system_memory();
>      MemoryRegion *rom = g_new(MemoryRegion, 1);
>      PXA2xxState *mpu;
> diff --git a/hw/versatilepb.c b/hw/versatilepb.c
> index 7a92034..686dcc7 100644
> --- a/hw/versatilepb.c
> +++ b/hw/versatilepb.c
> @@ -342,22 +342,28 @@ static void versatile_init(ram_addr_t ram_size,
>      arm_load_kernel(cpu, &versatile_binfo);
>  }
>
> -static void vpb_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void vpb_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      versatile_init(ram_size,
>                     boot_device,
>                     kernel_filename, kernel_cmdline,
>                     initrd_filename, cpu_model, 0x183);
>  }
>
> -static void vab_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void vab_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      versatile_init(ram_size,
>                     boot_device,
>                     kernel_filename, kernel_cmdline,
> diff --git a/hw/vexpress.c b/hw/vexpress.c
> index 3596d1e..36503d6 100644
> --- a/hw/vexpress.c
> +++ b/hw/vexpress.c
> @@ -467,25 +467,27 @@ static void vexpress_common_init(const VEDBoardInfo *daughterboard,
>      arm_load_kernel(arm_env_get_cpu(first_cpu), &vexpress_binfo);
>  }
>
> -static void vexpress_a9_init(ram_addr_t ram_size,
> -                             const char *boot_device,
> -                             const char *kernel_filename,
> -                             const char *kernel_cmdline,
> -                             const char *initrd_filename,
> -                             const char *cpu_model)
> +static void vexpress_a9_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      vexpress_common_init(&a9_daughterboard,
>                           ram_size, boot_device, kernel_filename,
>                           kernel_cmdline, initrd_filename, cpu_model);
>  }
>
> -static void vexpress_a15_init(ram_addr_t ram_size,
> -                              const char *boot_device,
> -                              const char *kernel_filename,
> -                              const char *kernel_cmdline,
> -                              const char *initrd_filename,
> -                              const char *cpu_model)
> +static void vexpress_a15_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      vexpress_common_init(&a15_daughterboard,
>                           ram_size, boot_device, kernel_filename,
>                           kernel_cmdline, initrd_filename, cpu_model);
> diff --git a/hw/virtex_ml507.c b/hw/virtex_ml507.c
> index 79bc0d1..a09b27a 100644
> --- a/hw/virtex_ml507.c
> +++ b/hw/virtex_ml507.c
> @@ -183,12 +183,12 @@ static int xilinx_load_device_tree(target_phys_addr_t addr,
>      return fdt_size;
>  }
>
> -static void virtex_init(ram_addr_t ram_size,
> -                        const char *boot_device,
> -                        const char *kernel_filename,
> -                        const char *kernel_cmdline,
> -                        const char *initrd_filename, const char *cpu_model)
> +static void virtex_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
>      MemoryRegion *address_space_mem = get_system_memory();
>      DeviceState *dev;
>      PowerPCCPU *cpu;
> diff --git a/hw/xen_machine_pv.c b/hw/xen_machine_pv.c
> index 4b72aa7..4264703 100644
> --- a/hw/xen_machine_pv.c
> +++ b/hw/xen_machine_pv.c
> @@ -29,13 +29,12 @@
>  #include "xen_domainbuild.h"
>  #include "blockdev.h"
>
> -static void xen_init_pv(ram_addr_t ram_size,
> -                       const char *boot_device,
> -                       const char *kernel_filename,
> -                       const char *kernel_cmdline,
> -                       const char *initrd_filename,
> -                       const char *cpu_model)
> +static void xen_init_pv(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      X86CPU *cpu;
>      CPUX86State *env;
>      DriveInfo *dinfo;
> diff --git a/hw/xilinx_zynq.c b/hw/xilinx_zynq.c
> index 7e6c273..83f322e 100644
> --- a/hw/xilinx_zynq.c
> +++ b/hw/xilinx_zynq.c
> @@ -46,10 +46,13 @@ static void gem_init(NICInfo *nd, uint32_t base, qemu_irq irq)
>      sysbus_connect_irq(s, 0, irq);
>  }
>
> -static void zynq_init(ram_addr_t ram_size, const char *boot_device,
> -                        const char *kernel_filename, const char *kernel_cmdline,
> -                        const char *initrd_filename, const char *cpu_model)
> +static void zynq_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      ARMCPU *cpu;
>      MemoryRegion *address_space_mem = get_system_memory();
>      MemoryRegion *ext_ram = g_new(MemoryRegion, 1);
> diff --git a/hw/xtensa_lx60.c b/hw/xtensa_lx60.c
> index 3653f65..1fd2c47 100644
> --- a/hw/xtensa_lx60.c
> +++ b/hw/xtensa_lx60.c
> @@ -268,11 +268,14 @@ static void lx_init(const LxBoardDesc *board,
>      }
>  }
>
> -static void xtensa_lx60_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void xtensa_lx60_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      static const LxBoardDesc lx60_board = {
>          .flash_size = 0x400000,
>          .flash_sector_size = 0x10000,
> @@ -283,11 +286,14 @@ static void xtensa_lx60_init(ram_addr_t ram_size,
>              initrd_filename, cpu_model);
>  }
>
> -static void xtensa_lx200_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void xtensa_lx200_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      static const LxBoardDesc lx200_board = {
>          .flash_size = 0x1000000,
>          .flash_sector_size = 0x20000,
> diff --git a/hw/xtensa_sim.c b/hw/xtensa_sim.c
> index 831460b..2e846d8 100644
> --- a/hw/xtensa_sim.c
> +++ b/hw/xtensa_sim.c
> @@ -96,11 +96,14 @@ static void sim_init(ram_addr_t ram_size,
>      }
>  }
>
> -static void xtensa_sim_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void xtensa_sim_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      if (!cpu_model) {
>          cpu_model = XTENSA_DEFAULT_CPU_MODEL;
>      }
> diff --git a/hw/z2.c b/hw/z2.c
> index 289cee9..0927bad 100644
> --- a/hw/z2.c
> +++ b/hw/z2.c
> @@ -294,11 +294,12 @@ static TypeInfo aer915_info = {
>      .class_init    = aer915_class_init,
>  };
>
> -static void z2_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void z2_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      MemoryRegion *address_space_mem = get_system_memory();
>      uint32_t sector_len = 0x10000;
>      PXA2xxState *mpu;
> diff --git a/vl.c b/vl.c
> index 8d305ca..b05e224 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -3624,8 +3624,13 @@ int main(int argc, char **argv, char **envp)
>
>      qdev_machine_init();
>
> -    machine->init(ram_size, boot_devices,
> -                  kernel_filename, kernel_cmdline, initrd_filename, cpu_model);
> +    QEMUMachineInitArgs args = { .ram_size = ram_size,
> +                                 .boot_device = boot_devices,
> +                                 .kernel_filename = kernel_filename,
> +                                 .kernel_cmdline = kernel_cmdline,
> +                                 .initrd_filename = initrd_filename,
> +                                 .cpu_model = cpu_model };
> +    machine->init(&args);
>
>      cpu_synchronize_all_post_init();
>
> --
> 1.7.11.4
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 13 10:16:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Oct 2012 10:16:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TMykw-00085Q-FU; Sat, 13 Oct 2012 10:15:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <blauwirbel@gmail.com>) id 1TMyku-00085L-2g
	for xen-devel@lists.xensource.com; Sat, 13 Oct 2012 10:15:40 +0000
Received: from [85.158.139.211:4027] by server-4.bemta-5.messagelabs.com id
	1A/DF-18688-B4F39705; Sat, 13 Oct 2012 10:15:39 +0000
X-Env-Sender: blauwirbel@gmail.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1350123333!22222383!1
X-Originating-IP: [209.85.223.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25508 invoked from network); 13 Oct 2012 10:15:35 -0000
Received: from mail-ie0-f171.google.com (HELO mail-ie0-f171.google.com)
	(209.85.223.171)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Oct 2012 10:15:35 -0000
Received: by mail-ie0-f171.google.com with SMTP id s9so7200604iec.30
	for <xen-devel@lists.xensource.com>;
	Sat, 13 Oct 2012 03:15:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=opNRFxNopqY9LAxxRKw5lJMid5phKG91OeN8y5sCBas=;
	b=oD4mUiUOqDi2VU+o0CPeqmYFUEc2BR+XCYMMKoRrov2hQbnQwUvJAXBPf+oKZLLLiI
	hsByxQjh8yyvhlui2knKm6m/1qMkXVxz4EaOZ1aJryObvcjFLB/bHiPs3xzJ48NElKjC
	FkHNSlW8341+2pgvg5Kpp/fasnhH8waWtoaHQTwuB/ehnJKMkPTjjsLifEgjxjlN/5QO
	pwRNsghSJFLaH3ZAPwWBN7bGAPxrRktzU0NiZjOoN+qPgbtdUqdNqJ8mW8q0h6Dk+AUN
	rP5uGZff6x1DODfoIzgd/HZrW5nP2UoGcIxVCETYmUQ5mM3FkZQWZCtxSrJkpWk30rmq
	CJGw==
Received: by 10.50.33.169 with SMTP id s9mr4438077igi.19.1350123333435; Sat,
	13 Oct 2012 03:15:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.53.130 with HTTP; Sat, 13 Oct 2012 03:15:13 -0700 (PDT)
In-Reply-To: <1349469866-1542-1-git-send-email-ehabkost@redhat.com>
References: <1349469866-1542-1-git-send-email-ehabkost@redhat.com>
From: Blue Swirl <blauwirbel@gmail.com>
Date: Sat, 13 Oct 2012 10:15:13 +0000
Message-ID: <CAAu8pHsSjdg1WGdgaTO78sbDvnWE9mrLb6RxOi1N8yQwzmvzVw@mail.gmail.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Evgeny Voevodin <e.voevodin@samsung.com>, qemu-devel@nongnu.org,
	Peter Crosthwaite <peter.crosthwaite@petalogix.com>,
	Max Filippov <jcmvbkbc@gmail.com>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	Guan Xuetao <gxt@mprc.pku.edu.cn>, xen-devel@lists.xensource.com,
	Igor Mitsyanko <i.mitsyanko@samsung.com>,
	Magnus Damm <magnus.damm@gmail.com>, Alexander Graf <agraf@suse.de>,
	=?UTF-8?Q?Herv=C3=A9_Poussineau?= <hpoussin@reactos.org>,
	Maksim Kozlov <m.kozlov@samsung.com>,
	Andrzej Zaborowski <balrogg@gmail.com>,
	Fabien Chouteau <chouteau@adacore.com>, Jan Kiszka <jan.kiszka@web.de>,
	Paul Brook <paul@codesourcery.com>, Anthony Liguori <aliguori@us.ibm.com>,
	Michael Walle <michael@walle.cc>, qemu-ppc@nongnu.org,
	Dmitry Solodkiy <d.solodkiy@samsung.com>,
	Aurelien Jarno <aurelien@aurel32.net>
Subject: Re: [Xen-devel] [QEMU PATCH] create struct for machine
	initialization arguments (v3)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 5, 2012 at 8:44 PM, Eduardo Habkost <ehabkost@redhat.com> wrote:
> This should help us to:
> - More easily add or remove machine initialization arguments without
>   having to change every single machine init function;
> - More easily make mechanical changes involving the machine init
>   functions in the future;
> - Let machine initialization forward the init arguments to other
>   functions more easily.
>
> This change was half-mechanical process: first the struct was added with
> the local ram_size, boot_device, kernel_*, initrd_*, and cpu_model local
> variable initialization to all functions. Then the compiler helped me
> locate the local variables that are unused, so they could be removed.
>
> Changes v2 -> v3:
>  - Fix typo (missing dot) on main()
>  - Fix another mistake on xen_init_pv() (I had forgotten to add local variables
>    to replace the old function arguments)
>
> Changes v1 -> v2:
>  - Fix mistake on the conversion of pc_xen_hvm_init() and xen_init_pv()

Changelog should be below --- line so that it will be clipped by git am.

The patch does not apply (hw/xilinx_zynq.c), please rebase.

>
> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> ---
>  hw/alpha_dp264.c              |  12 ++--
>  hw/an5206.c                   |   8 +--
>  hw/axis_dev88.c               |   9 +--
>  hw/boards.h                   |  16 +++--
>  hw/collie.c                   |   9 +--
>  hw/dummy_m68k.c               |   8 +--
>  hw/exynos4_boards.c           |  16 ++---
>  hw/gumstix.c                  |  11 +---
>  hw/highbank.c                 |  10 ++--
>  hw/integratorcp.c             |  10 ++--
>  hw/kzm.c                      |  10 ++--
>  hw/leon3.c                    |  10 ++--
>  hw/lm32_boards.c              |  18 +++---
>  hw/mainstone.c                |  10 ++--
>  hw/mcf5208.c                  |   8 +--
>  hw/milkymist.c                |  10 ++--
>  hw/mips_fulong2e.c            |   9 ++-
>  hw/mips_jazz.c                |  14 ++---
>  hw/mips_malta.c               |  10 ++--
>  hw/mips_mipssim.c             |  10 ++--
>  hw/mips_r4k.c                 |  10 ++--
>  hw/musicpal.c                 |   9 +--
>  hw/nseries.c                  |  22 ++++---
>  hw/null-machine.c             |   7 +--
>  hw/omap_sx1.c                 |  22 ++++---
>  hw/openrisc_sim.c             |  10 ++--
>  hw/palm.c                     |   9 +--
>  hw/pc_piix.c                  |  50 ++++++++--------
>  hw/petalogix_ml605_mmu.c      |   8 +--
>  hw/petalogix_s3adsp1800_mmu.c |   8 +--
>  hw/ppc/e500plat.c             |  13 +++--
>  hw/ppc/mpc8544ds.c            |  13 +++--
>  hw/ppc405_boards.c            |  25 ++++----
>  hw/ppc440_bamboo.c            |  12 ++--
>  hw/ppc_newworld.c             |  13 +++--
>  hw/ppc_oldworld.c             |  13 +++--
>  hw/ppc_prep.c                 |  13 +++--
>  hw/puv3.c                     |   8 ++-
>  hw/r2d.c                      |   9 +--
>  hw/realview.c                 |  44 +++++++++-----
>  hw/s390-virtio.c              |  13 +++--
>  hw/shix.c                     |   6 +-
>  hw/spapr.c                    |  13 +++--
>  hw/spitz.c                    |  40 ++++++++-----
>  hw/stellaris.c                |  14 ++---
>  hw/sun4m.c                    | 133 ++++++++++++++++++++++++++----------------
>  hw/sun4u.c                    |  39 ++++++++-----
>  hw/tosa.c                     |   9 +--
>  hw/versatilepb.c              |  22 ++++---
>  hw/vexpress.c                 |  26 +++++----
>  hw/virtex_ml507.c             |  10 ++--
>  hw/xen_machine_pv.c           |  11 ++--
>  hw/xilinx_zynq.c              |   9 ++-
>  hw/xtensa_lx60.c              |  22 ++++---
>  hw/xtensa_sim.c               |  11 ++--
>  hw/z2.c                       |   9 +--
>  vl.c                          |   9 ++-
>  57 files changed, 518 insertions(+), 414 deletions(-)
>
> diff --git a/hw/alpha_dp264.c b/hw/alpha_dp264.c
> index 9eb939f..2c2e237 100644
> --- a/hw/alpha_dp264.c
> +++ b/hw/alpha_dp264.c
> @@ -42,13 +42,13 @@ static int clipper_pci_map_irq(PCIDevice *d, int irq_num)
>      return (slot + 1) * 4 + irq_num;
>  }
>
> -static void clipper_init(ram_addr_t ram_size,
> -                         const char *boot_device,
> -                         const char *kernel_filename,
> -                         const char *kernel_cmdline,
> -                         const char *initrd_filename,
> -                         const char *cpu_model)
> +static void clipper_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      CPUAlphaState *cpus[4];
>      PCIBus *pci_bus;
>      ISABus *isa_bus;
> diff --git a/hw/an5206.c b/hw/an5206.c
> index 25407c0..042c5fc 100644
> --- a/hw/an5206.c
> +++ b/hw/an5206.c
> @@ -19,11 +19,11 @@
>
>  /* Board init.  */
>
> -static void an5206_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void an5206_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
>      CPUM68KState *env;
>      int kernel_size;
>      uint64_t elf_entry;
> diff --git a/hw/axis_dev88.c b/hw/axis_dev88.c
> index eab6327..2fd7356 100644
> --- a/hw/axis_dev88.c
> +++ b/hw/axis_dev88.c
> @@ -242,11 +242,12 @@ static const MemoryRegionOps gpio_ops = {
>  static struct cris_load_info li;
>
>  static
> -void axisdev88_init (ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +void axisdev88_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
>      CRISCPU *cpu;
>      CPUCRISState *env;
>      DeviceState *dev;
> diff --git a/hw/boards.h b/hw/boards.h
> index a2e0a54..813d0e5 100644
> --- a/hw/boards.h
> +++ b/hw/boards.h
> @@ -5,12 +5,16 @@
>
>  #include "qdev.h"
>
> -typedef void QEMUMachineInitFunc(ram_addr_t ram_size,
> -                                 const char *boot_device,
> -                                 const char *kernel_filename,
> -                                 const char *kernel_cmdline,
> -                                 const char *initrd_filename,
> -                                 const char *cpu_model);
> +typedef struct QEMUMachineInitArgs {
> +    ram_addr_t ram_size;
> +    const char *boot_device;
> +    const char *kernel_filename;
> +    const char *kernel_cmdline;
> +    const char *initrd_filename;
> +    const char *cpu_model;
> +} QEMUMachineInitArgs;
> +
> +typedef void QEMUMachineInitFunc(QEMUMachineInitArgs *args);
>
>  typedef void QEMUMachineResetFunc(void);
>
> diff --git a/hw/collie.c b/hw/collie.c
> index 56f89a9..695982a 100644
> --- a/hw/collie.c
> +++ b/hw/collie.c
> @@ -23,11 +23,12 @@ static struct arm_boot_info collie_binfo = {
>      .ram_size = 0x20000000,
>  };
>
> -static void collie_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void collie_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      StrongARMState *s;
>      DriveInfo *dinfo;
>      MemoryRegion *sysmem = get_system_memory();
> diff --git a/hw/dummy_m68k.c b/hw/dummy_m68k.c
> index 7cc7a99..f436a0c 100644
> --- a/hw/dummy_m68k.c
> +++ b/hw/dummy_m68k.c
> @@ -16,11 +16,11 @@
>
>  /* Board init.  */
>
> -static void dummy_m68k_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void dummy_m68k_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
>      CPUM68KState *env;
>      MemoryRegion *address_space_mem =  get_system_memory();
>      MemoryRegion *ram = g_new(MemoryRegion, 1);
> diff --git a/hw/exynos4_boards.c b/hw/exynos4_boards.c
> index 4bb0a60..4951064 100644
> --- a/hw/exynos4_boards.c
> +++ b/hw/exynos4_boards.c
> @@ -130,22 +130,22 @@ static Exynos4210State *exynos4_boards_init_common(
>              exynos4_board_ram_size[board_type]);
>  }
>
> -static void nuri_init(ram_addr_t ram_size,
> -        const char *boot_device,
> -        const char *kernel_filename, const char *kernel_cmdline,
> -        const char *initrd_filename, const char *cpu_model)
> +static void nuri_init(QEMUMachineInitArgs *args)
>  {
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      exynos4_boards_init_common(kernel_filename, kernel_cmdline,
>                  initrd_filename, EXYNOS4_BOARD_NURI);
>
>      arm_load_kernel(arm_env_get_cpu(first_cpu), &exynos4_board_binfo);
>  }
>
> -static void smdkc210_init(ram_addr_t ram_size,
> -        const char *boot_device,
> -        const char *kernel_filename, const char *kernel_cmdline,
> -        const char *initrd_filename, const char *cpu_model)
> +static void smdkc210_init(QEMUMachineInitArgs *args)
>  {
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      Exynos4210State *s = exynos4_boards_init_common(kernel_filename,
>              kernel_cmdline, initrd_filename, EXYNOS4_BOARD_SMDKC210);
>
> diff --git a/hw/gumstix.c b/hw/gumstix.c
> index 13a36ea..4103a88 100644
> --- a/hw/gumstix.c
> +++ b/hw/gumstix.c
> @@ -45,10 +45,7 @@
>
>  static const int sector_len = 128 * 1024;
>
> -static void connex_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void connex_init(QEMUMachineInitArgs *args)
>  {
>      PXA2xxState *cpu;
>      DriveInfo *dinfo;
> @@ -84,11 +81,9 @@ static void connex_init(ram_addr_t ram_size,
>                      qdev_get_gpio_in(cpu->gpio, 36));
>  }
>
> -static void verdex_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void verdex_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
>      PXA2xxState *cpu;
>      DriveInfo *dinfo;
>      int be;
> diff --git a/hw/highbank.c b/hw/highbank.c
> index 11aa131..15036b6 100644
> --- a/hw/highbank.c
> +++ b/hw/highbank.c
> @@ -187,11 +187,13 @@ static struct arm_boot_info highbank_binfo;
>   * 32-bit host, set the reg value of memory to 0xf7ff00000 in the
>   * device tree and pass -m 2047 to QEMU.
>   */
> -static void highbank_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void highbank_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      DeviceState *dev;
>      SysBusDevice *busdev;
>      qemu_irq *irqp;
> diff --git a/hw/integratorcp.c b/hw/integratorcp.c
> index d0e2e90..ac0ea83 100644
> --- a/hw/integratorcp.c
> +++ b/hw/integratorcp.c
> @@ -438,11 +438,13 @@ static struct arm_boot_info integrator_binfo = {
>      .board_id = 0x113,
>  };
>
> -static void integratorcp_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void integratorcp_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      ARMCPU *cpu;
>      MemoryRegion *address_space_mem = get_system_memory();
>      MemoryRegion *ram = g_new(MemoryRegion, 1);
> diff --git a/hw/kzm.c b/hw/kzm.c
> index 68cd1b4..d1266d9 100644
> --- a/hw/kzm.c
> +++ b/hw/kzm.c
> @@ -70,11 +70,13 @@ static struct arm_boot_info kzm_binfo = {
>      .board_id = 1722,
>  };
>
> -static void kzm_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void kzm_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      ARMCPU *cpu;
>      MemoryRegion *address_space_mem = get_system_memory();
>      MemoryRegion *ram = g_new(MemoryRegion, 1);
> diff --git a/hw/leon3.c b/hw/leon3.c
> index 878d3aa..6486b7b 100644
> --- a/hw/leon3.c
> +++ b/hw/leon3.c
> @@ -94,13 +94,11 @@ static void leon3_set_pil_in(void *opaque, uint32_t pil_in)
>      }
>  }
>
> -static void leon3_generic_hw_init(ram_addr_t  ram_size,
> -                                  const char *boot_device,
> -                                  const char *kernel_filename,
> -                                  const char *kernel_cmdline,
> -                                  const char *initrd_filename,
> -                                  const char *cpu_model)
> +static void leon3_generic_hw_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
>      SPARCCPU *cpu;
>      CPUSPARCState   *env;
>      MemoryRegion *address_space_mem = get_system_memory();
> diff --git a/hw/lm32_boards.c b/hw/lm32_boards.c
> index b76d800..c5a62c8 100644
> --- a/hw/lm32_boards.c
> +++ b/hw/lm32_boards.c
> @@ -69,12 +69,10 @@ static void main_cpu_reset(void *opaque)
>      env->deba = reset_info->flash_base;
>  }
>
> -static void lm32_evr_init(ram_addr_t ram_size_not_used,
> -                          const char *boot_device,
> -                          const char *kernel_filename,
> -                          const char *kernel_cmdline,
> -                          const char *initrd_filename, const char *cpu_model)
> +static void lm32_evr_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
>      LM32CPU *cpu;
>      CPULM32State *env;
>      DriveInfo *dinfo;
> @@ -159,12 +157,12 @@ static void lm32_evr_init(ram_addr_t ram_size_not_used,
>      qemu_register_reset(main_cpu_reset, reset_info);
>  }
>
> -static void lm32_uclinux_init(ram_addr_t ram_size_not_used,
> -                          const char *boot_device,
> -                          const char *kernel_filename,
> -                          const char *kernel_cmdline,
> -                          const char *initrd_filename, const char *cpu_model)
> +static void lm32_uclinux_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      LM32CPU *cpu;
>      CPULM32State *env;
>      DriveInfo *dinfo;
> diff --git a/hw/mainstone.c b/hw/mainstone.c
> index 97687b6..c0d6034 100644
> --- a/hw/mainstone.c
> +++ b/hw/mainstone.c
> @@ -171,11 +171,13 @@ static void mainstone_common_init(MemoryRegion *address_space_mem,
>      arm_load_kernel(mpu->cpu, &mainstone_binfo);
>  }
>
> -static void mainstone_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void mainstone_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      mainstone_common_init(get_system_memory(), ram_size, kernel_filename,
>                  kernel_cmdline, initrd_filename, cpu_model, mainstone, 0x196);
>  }
> diff --git a/hw/mcf5208.c b/hw/mcf5208.c
> index ee25b1b..688bc3c 100644
> --- a/hw/mcf5208.c
> +++ b/hw/mcf5208.c
> @@ -187,11 +187,11 @@ static void mcf5208_sys_init(MemoryRegion *address_space, qemu_irq *pic)
>      }
>  }
>
> -static void mcf5208evb_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void mcf5208evb_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
>      CPUM68KState *env;
>      int kernel_size;
>      uint64_t elf_entry;
> diff --git a/hw/milkymist.c b/hw/milkymist.c
> index 2e7235b..ca9ed43 100644
> --- a/hw/milkymist.c
> +++ b/hw/milkymist.c
> @@ -73,12 +73,12 @@ static void main_cpu_reset(void *opaque)
>  }
>
>  static void
> -milkymist_init(ram_addr_t ram_size_not_used,
> -                          const char *boot_device,
> -                          const char *kernel_filename,
> -                          const char *kernel_cmdline,
> -                          const char *initrd_filename, const char *cpu_model)
> +milkymist_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      LM32CPU *cpu;
>      CPULM32State *env;
>      int kernel_size;
> diff --git a/hw/mips_fulong2e.c b/hw/mips_fulong2e.c
> index 38e4b86..af7bb50 100644
> --- a/hw/mips_fulong2e.c
> +++ b/hw/mips_fulong2e.c
> @@ -256,10 +256,13 @@ static void cpu_request_exit(void *opaque, int irq, int level)
>      }
>  }
>
> -static void mips_fulong2e_init(ram_addr_t ram_size, const char *boot_device,
> -                        const char *kernel_filename, const char *kernel_cmdline,
> -                        const char *initrd_filename, const char *cpu_model)
> +static void mips_fulong2e_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      char *filename;
>      MemoryRegion *address_space_mem = get_system_memory();
>      MemoryRegion *ram = g_new(MemoryRegion, 1);
> diff --git a/hw/mips_jazz.c b/hw/mips_jazz.c
> index db927f1..14df4d7 100644
> --- a/hw/mips_jazz.c
> +++ b/hw/mips_jazz.c
> @@ -302,21 +302,19 @@ static void mips_jazz_init(MemoryRegion *address_space,
>  }
>
>  static
> -void mips_magnum_init (ram_addr_t ram_size,
> -                       const char *boot_device,
> -                       const char *kernel_filename, const char *kernel_cmdline,
> -                       const char *initrd_filename, const char *cpu_model)
> +void mips_magnum_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
>          mips_jazz_init(get_system_memory(), get_system_io(),
>                         ram_size, cpu_model, JAZZ_MAGNUM);
>  }
>
>  static
> -void mips_pica61_init (ram_addr_t ram_size,
> -                       const char *boot_device,
> -                       const char *kernel_filename, const char *kernel_cmdline,
> -                       const char *initrd_filename, const char *cpu_model)
> +void mips_pica61_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
>      mips_jazz_init(get_system_memory(), get_system_io(),
>                     ram_size, cpu_model, JAZZ_PICA61);
>  }
> diff --git a/hw/mips_malta.c b/hw/mips_malta.c
> index ad23f26..14151f9 100644
> --- a/hw/mips_malta.c
> +++ b/hw/mips_malta.c
> @@ -777,11 +777,13 @@ static void cpu_request_exit(void *opaque, int irq, int level)
>  }
>
>  static
> -void mips_malta_init (ram_addr_t ram_size,
> -                      const char *boot_device,
> -                      const char *kernel_filename, const char *kernel_cmdline,
> -                      const char *initrd_filename, const char *cpu_model)
> +void mips_malta_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      char *filename;
>      pflash_t *fl;
>      MemoryRegion *system_memory = get_system_memory();
> diff --git a/hw/mips_mipssim.c b/hw/mips_mipssim.c
> index 830f635..a1d3945 100644
> --- a/hw/mips_mipssim.c
> +++ b/hw/mips_mipssim.c
> @@ -131,11 +131,13 @@ static void mipsnet_init(int base, qemu_irq irq, NICInfo *nd)
>  }
>
>  static void
> -mips_mipssim_init (ram_addr_t ram_size,
> -                   const char *boot_device,
> -                   const char *kernel_filename, const char *kernel_cmdline,
> -                   const char *initrd_filename, const char *cpu_model)
> +mips_mipssim_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      char *filename;
>      MemoryRegion *address_space_mem = get_system_memory();
>      MemoryRegion *ram = g_new(MemoryRegion, 1);
> diff --git a/hw/mips_r4k.c b/hw/mips_r4k.c
> index 967a76e..b73cdc3 100644
> --- a/hw/mips_r4k.c
> +++ b/hw/mips_r4k.c
> @@ -151,11 +151,13 @@ static void main_cpu_reset(void *opaque)
>
>  static const int sector_len = 32 * 1024;
>  static
> -void mips_r4k_init (ram_addr_t ram_size,
> -                    const char *boot_device,
> -                    const char *kernel_filename, const char *kernel_cmdline,
> -                    const char *initrd_filename, const char *cpu_model)
> +void mips_r4k_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      char *filename;
>      MemoryRegion *address_space_mem = get_system_memory();
>      MemoryRegion *ram = g_new(MemoryRegion, 1);
> diff --git a/hw/musicpal.c b/hw/musicpal.c
> index f305e21..f06814c 100644
> --- a/hw/musicpal.c
> +++ b/hw/musicpal.c
> @@ -1508,11 +1508,12 @@ static struct arm_boot_info musicpal_binfo = {
>      .board_id = 0x20e,
>  };
>
> -static void musicpal_init(ram_addr_t ram_size,
> -               const char *boot_device,
> -               const char *kernel_filename, const char *kernel_cmdline,
> -               const char *initrd_filename, const char *cpu_model)
> +static void musicpal_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      ARMCPU *cpu;
>      qemu_irq *cpu_pic;
>      qemu_irq pic[32];
> diff --git a/hw/nseries.c b/hw/nseries.c
> index 6df71eb..7ada90d 100644
> --- a/hw/nseries.c
> +++ b/hw/nseries.c
> @@ -1397,21 +1397,27 @@ static struct arm_boot_info n810_binfo = {
>      .atag_board = n810_atag_setup,
>  };
>
> -static void n800_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void n800_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      return n8x0_init(ram_size, boot_device,
>                      kernel_filename, kernel_cmdline, initrd_filename,
>                      cpu_model, &n800_binfo, 800);
>  }
>
> -static void n810_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void n810_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      return n8x0_init(ram_size, boot_device,
>                      kernel_filename, kernel_cmdline, initrd_filename,
>                      cpu_model, &n810_binfo, 810);
> diff --git a/hw/null-machine.c b/hw/null-machine.c
> index 69910d3..d813c08 100644
> --- a/hw/null-machine.c
> +++ b/hw/null-machine.c
> @@ -15,12 +15,7 @@
>  #include "hw/hw.h"
>  #include "hw/boards.h"
>
> -static void machine_none_init(ram_addr_t ram_size,
> -                              const char *boot_device,
> -                              const char *kernel_filename,
> -                              const char *kernel_cmdline,
> -                              const char *initrd_filename,
> -                              const char *cpu_model)
> +static void machine_none_init(QEMUMachineInitArgs *args)
>  {
>  }
>
> diff --git a/hw/omap_sx1.c b/hw/omap_sx1.c
> index abca341..ad17487 100644
> --- a/hw/omap_sx1.c
> +++ b/hw/omap_sx1.c
> @@ -209,20 +209,26 @@ static void sx1_init(ram_addr_t ram_size,
>      //~ qemu_console_resize(ds, 640, 480);
>  }
>
> -static void sx1_init_v1(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void sx1_init_v1(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sx1_init(ram_size, boot_device, kernel_filename,
>                  kernel_cmdline, initrd_filename, cpu_model, 1);
>  }
>
> -static void sx1_init_v2(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void sx1_init_v2(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sx1_init(ram_size, boot_device, kernel_filename,
>                  kernel_cmdline, initrd_filename, cpu_model, 2);
>  }
> diff --git a/hw/openrisc_sim.c b/hw/openrisc_sim.c
> index 55e97f0..e96a944 100644
> --- a/hw/openrisc_sim.c
> +++ b/hw/openrisc_sim.c
> @@ -90,13 +90,11 @@ static void cpu_openrisc_load_kernel(ram_addr_t ram_size,
>      cpu->env.pc = entry;
>  }
>
> -static void openrisc_sim_init(ram_addr_t ram_size,
> -                              const char *boot_device,
> -                              const char *kernel_filename,
> -                              const char *kernel_cmdline,
> -                              const char *initrd_filename,
> -                              const char *cpu_model)
> +static void openrisc_sim_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
>     OpenRISCCPU *cpu = NULL;
>      MemoryRegion *ram;
>      int n;
> diff --git a/hw/palm.c b/hw/palm.c
> index bacdc90..032b8d6 100644
> --- a/hw/palm.c
> +++ b/hw/palm.c
> @@ -190,11 +190,12 @@ static struct arm_boot_info palmte_binfo = {
>      .board_id = 0x331,
>  };
>
> -static void palmte_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void palmte_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      MemoryRegion *address_space_mem = get_system_memory();
>      struct omap_mpu_state_s *mpu;
>      int flash_size = 0x00800000;
> diff --git a/hw/pc_piix.c b/hw/pc_piix.c
> index fd5898f..c9fca05 100644
> --- a/hw/pc_piix.c
> +++ b/hw/pc_piix.c
> @@ -287,13 +287,14 @@ static void pc_init1(MemoryRegion *system_memory,
>      }
>  }
>
> -static void pc_init_pci(ram_addr_t ram_size,
> -                        const char *boot_device,
> -                        const char *kernel_filename,
> -                        const char *kernel_cmdline,
> -                        const char *initrd_filename,
> -                        const char *cpu_model)
> +static void pc_init_pci(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      pc_init1(get_system_memory(),
>               get_system_io(),
>               ram_size, boot_device,
> @@ -301,13 +302,14 @@ static void pc_init_pci(ram_addr_t ram_size,
>               initrd_filename, cpu_model, 1, 1);
>  }
>
> -static void pc_init_pci_no_kvmclock(ram_addr_t ram_size,
> -                                    const char *boot_device,
> -                                    const char *kernel_filename,
> -                                    const char *kernel_cmdline,
> -                                    const char *initrd_filename,
> -                                    const char *cpu_model)
> +static void pc_init_pci_no_kvmclock(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      pc_init1(get_system_memory(),
>               get_system_io(),
>               ram_size, boot_device,
> @@ -315,13 +317,14 @@ static void pc_init_pci_no_kvmclock(ram_addr_t ram_size,
>               initrd_filename, cpu_model, 1, 0);
>  }
>
> -static void pc_init_isa(ram_addr_t ram_size,
> -                        const char *boot_device,
> -                        const char *kernel_filename,
> -                        const char *kernel_cmdline,
> -                        const char *initrd_filename,
> -                        const char *cpu_model)
> +static void pc_init_isa(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      if (cpu_model == NULL)
>          cpu_model = "486";
>      pc_init1(get_system_memory(),
> @@ -332,19 +335,12 @@ static void pc_init_isa(ram_addr_t ram_size,
>  }
>
>  #ifdef CONFIG_XEN
> -static void pc_xen_hvm_init(ram_addr_t ram_size,
> -                            const char *boot_device,
> -                            const char *kernel_filename,
> -                            const char *kernel_cmdline,
> -                            const char *initrd_filename,
> -                            const char *cpu_model)
> +static void pc_xen_hvm_init(QEMUMachineInitArgs *args)
>  {
>      if (xen_hvm_init() != 0) {
>          hw_error("xen hardware virtual machine initialisation failed");
>      }
> -    pc_init_pci_no_kvmclock(ram_size, boot_device,
> -                            kernel_filename, kernel_cmdline,
> -                            initrd_filename, cpu_model);
> +    pc_init_pci_no_kvmclock(args);
>      xen_vcpu_init();
>  }
>  #endif
> diff --git a/hw/petalogix_ml605_mmu.c b/hw/petalogix_ml605_mmu.c
> index dced648..ace0187 100644
> --- a/hw/petalogix_ml605_mmu.c
> +++ b/hw/petalogix_ml605_mmu.c
> @@ -70,12 +70,10 @@ static void machine_cpu_reset(MicroBlazeCPU *cpu)
>  }
>
>  static void
> -petalogix_ml605_init(ram_addr_t ram_size,
> -                          const char *boot_device,
> -                          const char *kernel_filename,
> -                          const char *kernel_cmdline,
> -                          const char *initrd_filename, const char *cpu_model)
> +petalogix_ml605_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
>      MemoryRegion *address_space_mem = get_system_memory();
>      DeviceState *dev, *dma, *eth0;
>      MicroBlazeCPU *cpu;
> diff --git a/hw/petalogix_s3adsp1800_mmu.c b/hw/petalogix_s3adsp1800_mmu.c
> index 2cf6882..71c32ce 100644
> --- a/hw/petalogix_s3adsp1800_mmu.c
> +++ b/hw/petalogix_s3adsp1800_mmu.c
> @@ -57,12 +57,10 @@ static void machine_cpu_reset(MicroBlazeCPU *cpu)
>  }
>
>  static void
> -petalogix_s3adsp1800_init(ram_addr_t ram_size,
> -                          const char *boot_device,
> -                          const char *kernel_filename,
> -                          const char *kernel_cmdline,
> -                          const char *initrd_filename, const char *cpu_model)
> +petalogix_s3adsp1800_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
>      DeviceState *dev;
>      MicroBlazeCPU *cpu;
>      CPUMBState *env;
> diff --git a/hw/ppc/e500plat.c b/hw/ppc/e500plat.c
> index 60a5cb3..4cfb940 100644
> --- a/hw/ppc/e500plat.c
> +++ b/hw/ppc/e500plat.c
> @@ -25,13 +25,14 @@ static void e500plat_fixup_devtree(PPCE500Params *params, void *fdt)
>                           sizeof(compatible));
>  }
>
> -static void e500plat_init(ram_addr_t ram_size,
> -                           const char *boot_device,
> -                           const char *kernel_filename,
> -                           const char *kernel_cmdline,
> -                           const char *initrd_filename,
> -                           const char *cpu_model)
> +static void e500plat_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *boot_device = args->boot_device;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      PPCE500Params params = {
>          .ram_size = ram_size,
>          .boot_device = boot_device,
> diff --git a/hw/ppc/mpc8544ds.c b/hw/ppc/mpc8544ds.c
> index 984d21c..e651661 100644
> --- a/hw/ppc/mpc8544ds.c
> +++ b/hw/ppc/mpc8544ds.c
> @@ -25,13 +25,14 @@ static void mpc8544ds_fixup_devtree(PPCE500Params *params, void *fdt)
>                           sizeof(compatible));
>  }
>
> -static void mpc8544ds_init(ram_addr_t ram_size,
> -                           const char *boot_device,
> -                           const char *kernel_filename,
> -                           const char *kernel_cmdline,
> -                           const char *initrd_filename,
> -                           const char *cpu_model)
> +static void mpc8544ds_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *boot_device = args->boot_device;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      PPCE500Params params = {
>          .ram_size = ram_size,
>          .boot_device = boot_device,
> diff --git a/hw/ppc405_boards.c b/hw/ppc405_boards.c
> index 476775d..e848cb0 100644
> --- a/hw/ppc405_boards.c
> +++ b/hw/ppc405_boards.c
> @@ -158,7 +158,7 @@ static void ref405ep_fpga_reset (void *opaque)
>      fpga->reg1 = 0x0F;
>  }
>
> -static void ref405ep_fpga_init (MemoryRegion *sysmem, uint32_t base)
> +static void ref405ep_fpga_init(MemoryRegion *sysmem, uint32_t base)
>  {
>      ref405ep_fpga_t *fpga;
>      MemoryRegion *fpga_memory = g_new(MemoryRegion, 1);
> @@ -170,13 +170,12 @@ static void ref405ep_fpga_init (MemoryRegion *sysmem, uint32_t base)
>      qemu_register_reset(&ref405ep_fpga_reset, fpga);
>  }
>
> -static void ref405ep_init (ram_addr_t ram_size,
> -                           const char *boot_device,
> -                           const char *kernel_filename,
> -                           const char *kernel_cmdline,
> -                           const char *initrd_filename,
> -                           const char *cpu_model)
> +static void ref405ep_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      char *filename;
>      ppc4xx_bd_info_t bd;
>      CPUPPCState *env;
> @@ -484,7 +483,7 @@ static void taihu_cpld_reset (void *opaque)
>      cpld->reg1 = 0x80;
>  }
>
> -static void taihu_cpld_init (MemoryRegion *sysmem, uint32_t base)
> +static void taihu_cpld_init(MemoryRegion *sysmem, uint32_t base)
>  {
>      taihu_cpld_t *cpld;
>      MemoryRegion *cpld_memory = g_new(MemoryRegion, 1);
> @@ -495,13 +494,11 @@ static void taihu_cpld_init (MemoryRegion *sysmem, uint32_t base)
>      qemu_register_reset(&taihu_cpld_reset, cpld);
>  }
>
> -static void taihu_405ep_init(ram_addr_t ram_size,
> -                             const char *boot_device,
> -                             const char *kernel_filename,
> -                             const char *kernel_cmdline,
> -                             const char *initrd_filename,
> -                             const char *cpu_model)
> +static void taihu_405ep_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *initrd_filename = args->initrd_filename;
>      char *filename;
>      qemu_irq *pic;
>      MemoryRegion *sysmem = get_system_memory();
> diff --git a/hw/ppc440_bamboo.c b/hw/ppc440_bamboo.c
> index c198071..78e7985 100644
> --- a/hw/ppc440_bamboo.c
> +++ b/hw/ppc440_bamboo.c
> @@ -157,13 +157,13 @@ static void main_cpu_reset(void *opaque)
>      mmubooke_create_initial_mapping(env, 0, 0);
>  }
>
> -static void bamboo_init(ram_addr_t ram_size,
> -                        const char *boot_device,
> -                        const char *kernel_filename,
> -                        const char *kernel_cmdline,
> -                        const char *initrd_filename,
> -                        const char *cpu_model)
> +static void bamboo_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      unsigned int pci_irq_nrs[4] = { 28, 27, 26, 25 };
>      MemoryRegion *address_space_mem = get_system_memory();
>      MemoryRegion *ram_memories
> diff --git a/hw/ppc_newworld.c b/hw/ppc_newworld.c
> index e95cfe8..e7c0747 100644
> --- a/hw/ppc_newworld.c
> +++ b/hw/ppc_newworld.c
> @@ -129,13 +129,14 @@ static void ppc_core99_reset(void *opaque)
>  }
>
>  /* PowerPC Mac99 hardware initialisation */
> -static void ppc_core99_init (ram_addr_t ram_size,
> -                             const char *boot_device,
> -                             const char *kernel_filename,
> -                             const char *kernel_cmdline,
> -                             const char *initrd_filename,
> -                             const char *cpu_model)
> +static void ppc_core99_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      PowerPCCPU *cpu = NULL;
>      CPUPPCState *env = NULL;
>      char *filename;
> diff --git a/hw/ppc_oldworld.c b/hw/ppc_oldworld.c
> index 1dcd8a6..d9f76a8 100644
> --- a/hw/ppc_oldworld.c
> +++ b/hw/ppc_oldworld.c
> @@ -72,13 +72,14 @@ static void ppc_heathrow_reset(void *opaque)
>      cpu_reset(CPU(cpu));
>  }
>
> -static void ppc_heathrow_init (ram_addr_t ram_size,
> -                               const char *boot_device,
> -                               const char *kernel_filename,
> -                               const char *kernel_cmdline,
> -                               const char *initrd_filename,
> -                               const char *cpu_model)
> +static void ppc_heathrow_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      MemoryRegion *sysmem = get_system_memory();
>      PowerPCCPU *cpu = NULL;
>      CPUPPCState *env = NULL;
> diff --git a/hw/ppc_prep.c b/hw/ppc_prep.c
> index 592b7b2..f51f78a 100644
> --- a/hw/ppc_prep.c
> +++ b/hw/ppc_prep.c
> @@ -448,13 +448,14 @@ static void ppc_prep_reset(void *opaque)
>  }
>
>  /* PowerPC PREP hardware initialisation */
> -static void ppc_prep_init (ram_addr_t ram_size,
> -                           const char *boot_device,
> -                           const char *kernel_filename,
> -                           const char *kernel_cmdline,
> -                           const char *initrd_filename,
> -                           const char *cpu_model)
> +static void ppc_prep_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      MemoryRegion *sysmem = get_system_memory();
>      PowerPCCPU *cpu = NULL;
>      CPUPPCState *env = NULL;
> diff --git a/hw/puv3.c b/hw/puv3.c
> index 43f7216..764799c 100644
> --- a/hw/puv3.c
> +++ b/hw/puv3.c
> @@ -91,10 +91,12 @@ static void puv3_load_kernel(const char *kernel_filename)
>      graphic_console_init(NULL, NULL, NULL, NULL, NULL);
>  }
>
> -static void puv3_init(ram_addr_t ram_size, const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void puv3_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *initrd_filename = args->initrd_filename;
>      CPUUniCore32State *env;
>
>      if (initrd_filename) {
> diff --git a/hw/r2d.c b/hw/r2d.c
> index 0f16e81..5daa42f 100644
> --- a/hw/r2d.c
> +++ b/hw/r2d.c
> @@ -219,11 +219,12 @@ static struct QEMU_PACKED
>      char kernel_cmdline[256];
>  } boot_params;
>
> -static void r2d_init(ram_addr_t ram_size,
> -              const char *boot_device,
> -             const char *kernel_filename, const char *kernel_cmdline,
> -             const char *initrd_filename, const char *cpu_model)
> +static void r2d_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      SuperHCPU *cpu;
>      CPUSH4State *env;
>      ResetData *reset_info;
> diff --git a/hw/realview.c b/hw/realview.c
> index 19db4d0..8dc4be6 100644
> --- a/hw/realview.c
> +++ b/hw/realview.c
> @@ -330,11 +330,14 @@ static void realview_init(ram_addr_t ram_size,
>      arm_load_kernel(arm_env_get_cpu(first_cpu), &realview_binfo);
>  }
>
> -static void realview_eb_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void realview_eb_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      if (!cpu_model) {
>          cpu_model = "arm926";
>      }
> @@ -342,11 +345,14 @@ static void realview_eb_init(ram_addr_t ram_size,
>                    initrd_filename, cpu_model, BOARD_EB);
>  }
>
> -static void realview_eb_mpcore_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void realview_eb_mpcore_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      if (!cpu_model) {
>          cpu_model = "arm11mpcore";
>      }
> @@ -354,11 +360,14 @@ static void realview_eb_mpcore_init(ram_addr_t ram_size,
>                    initrd_filename, cpu_model, BOARD_EB_MPCORE);
>  }
>
> -static void realview_pb_a8_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void realview_pb_a8_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      if (!cpu_model) {
>          cpu_model = "cortex-a8";
>      }
> @@ -366,11 +375,14 @@ static void realview_pb_a8_init(ram_addr_t ram_size,
>                    initrd_filename, cpu_model, BOARD_PB_A8);
>  }
>
> -static void realview_pbx_a9_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void realview_pbx_a9_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      if (!cpu_model) {
>          cpu_model = "cortex-a9";
>      }
> diff --git a/hw/s390-virtio.c b/hw/s390-virtio.c
> index 47eed35..39ff178 100644
> --- a/hw/s390-virtio.c
> +++ b/hw/s390-virtio.c
> @@ -151,13 +151,14 @@ unsigned s390_del_running_cpu(CPUS390XState *env)
>  }
>
>  /* PC hardware initialisation */
> -static void s390_init(ram_addr_t my_ram_size,
> -                      const char *boot_device,
> -                      const char *kernel_filename,
> -                      const char *kernel_cmdline,
> -                      const char *initrd_filename,
> -                      const char *cpu_model)
> +static void s390_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t my_ram_size = args->ram_size;
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      CPUS390XState *env = NULL;
>      MemoryRegion *sysmem = get_system_memory();
>      MemoryRegion *ram = g_new(MemoryRegion, 1);
> diff --git a/hw/shix.c b/hw/shix.c
> index dd9ce17..b56dd54 100644
> --- a/hw/shix.c
> +++ b/hw/shix.c
> @@ -37,11 +37,9 @@
>  #define BIOS_FILENAME "shix_bios.bin"
>  #define BIOS_ADDRESS 0xA0000000
>
> -static void shix_init(ram_addr_t ram_size,
> -               const char *boot_device,
> -              const char *kernel_filename, const char *kernel_cmdline,
> -              const char *initrd_filename, const char *cpu_model)
> +static void shix_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
>      int ret;
>      CPUSH4State *env;
>      struct SH7750State *s;
> diff --git a/hw/spapr.c b/hw/spapr.c
> index c34b767..8921c4d 100644
> --- a/hw/spapr.c
> +++ b/hw/spapr.c
> @@ -603,13 +603,14 @@ static int spapr_vga_init(PCIBus *pci_bus)
>  }
>
>  /* pSeries LPAR / sPAPR hardware init */
> -static void ppc_spapr_init(ram_addr_t ram_size,
> -                           const char *boot_device,
> -                           const char *kernel_filename,
> -                           const char *kernel_cmdline,
> -                           const char *initrd_filename,
> -                           const char *cpu_model)
> +static void ppc_spapr_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      PowerPCCPU *cpu;
>      CPUPPCState *env;
>      PCIHostState *phb;
> diff --git a/hw/spitz.c b/hw/spitz.c
> index 20e7835..df829b3 100644
> --- a/hw/spitz.c
> +++ b/hw/spitz.c
> @@ -936,38 +936,46 @@ static void spitz_common_init(ram_addr_t ram_size,
>      sl_bootparam_write(SL_PXA_PARAM_BASE);
>  }
>
> -static void spitz_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void spitz_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      spitz_common_init(ram_size, kernel_filename,
>                  kernel_cmdline, initrd_filename, cpu_model, spitz, 0x2c9);
>  }
>
> -static void borzoi_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void borzoi_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      spitz_common_init(ram_size, kernel_filename,
>                  kernel_cmdline, initrd_filename, cpu_model, borzoi, 0x33f);
>  }
>
> -static void akita_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void akita_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      spitz_common_init(ram_size, kernel_filename,
>                  kernel_cmdline, initrd_filename, cpu_model, akita, 0x2e8);
>  }
>
> -static void terrier_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void terrier_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      spitz_common_init(ram_size, kernel_filename,
>                  kernel_cmdline, initrd_filename, cpu_model, terrier, 0x33f);
>  }
> diff --git a/hw/stellaris.c b/hw/stellaris.c
> index 562fbbf..b79c7fb 100644
> --- a/hw/stellaris.c
> +++ b/hw/stellaris.c
> @@ -1358,19 +1358,17 @@ static void stellaris_init(const char *kernel_filename, const char *cpu_model,
>  }
>
>  /* FIXME: Figure out how to generate these from stellaris_boards.  */
> -static void lm3s811evb_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void lm3s811evb_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
>      stellaris_init(kernel_filename, cpu_model, &stellaris_boards[0]);
>  }
>
> -static void lm3s6965evb_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void lm3s6965evb_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
>      stellaris_init(kernel_filename, cpu_model, &stellaris_boards[1]);
>  }
>
> diff --git a/hw/sun4m.c b/hw/sun4m.c
> index c98cd5e..22e011f 100644
> --- a/hw/sun4m.c
> +++ b/hw/sun4m.c
> @@ -1303,92 +1303,118 @@ static const struct sun4m_hwdef sun4m_hwdefs[] = {
>  };
>
>  /* SPARCstation 5 hardware initialisation */
> -static void ss5_init(ram_addr_t RAM_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void ss5_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sun4m_hw_init(&sun4m_hwdefs[0], RAM_size, boot_device, kernel_filename,
>                    kernel_cmdline, initrd_filename, cpu_model);
>  }
>
>  /* SPARCstation 10 hardware initialisation */
> -static void ss10_init(ram_addr_t RAM_size,
> -                      const char *boot_device,
> -                      const char *kernel_filename, const char *kernel_cmdline,
> -                      const char *initrd_filename, const char *cpu_model)
> +static void ss10_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sun4m_hw_init(&sun4m_hwdefs[1], RAM_size, boot_device, kernel_filename,
>                    kernel_cmdline, initrd_filename, cpu_model);
>  }
>
>  /* SPARCserver 600MP hardware initialisation */
> -static void ss600mp_init(ram_addr_t RAM_size,
> -                         const char *boot_device,
> -                         const char *kernel_filename,
> -                         const char *kernel_cmdline,
> -                         const char *initrd_filename, const char *cpu_model)
> +static void ss600mp_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sun4m_hw_init(&sun4m_hwdefs[2], RAM_size, boot_device, kernel_filename,
>                    kernel_cmdline, initrd_filename, cpu_model);
>  }
>
>  /* SPARCstation 20 hardware initialisation */
> -static void ss20_init(ram_addr_t RAM_size,
> -                      const char *boot_device,
> -                      const char *kernel_filename, const char *kernel_cmdline,
> -                      const char *initrd_filename, const char *cpu_model)
> +static void ss20_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sun4m_hw_init(&sun4m_hwdefs[3], RAM_size, boot_device, kernel_filename,
>                    kernel_cmdline, initrd_filename, cpu_model);
>  }
>
>  /* SPARCstation Voyager hardware initialisation */
> -static void vger_init(ram_addr_t RAM_size,
> -                      const char *boot_device,
> -                      const char *kernel_filename, const char *kernel_cmdline,
> -                      const char *initrd_filename, const char *cpu_model)
> +static void vger_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sun4m_hw_init(&sun4m_hwdefs[4], RAM_size, boot_device, kernel_filename,
>                    kernel_cmdline, initrd_filename, cpu_model);
>  }
>
>  /* SPARCstation LX hardware initialisation */
> -static void ss_lx_init(ram_addr_t RAM_size,
> -                       const char *boot_device,
> -                       const char *kernel_filename, const char *kernel_cmdline,
> -                       const char *initrd_filename, const char *cpu_model)
> +static void ss_lx_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sun4m_hw_init(&sun4m_hwdefs[5], RAM_size, boot_device, kernel_filename,
>                    kernel_cmdline, initrd_filename, cpu_model);
>  }
>
>  /* SPARCstation 4 hardware initialisation */
> -static void ss4_init(ram_addr_t RAM_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void ss4_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sun4m_hw_init(&sun4m_hwdefs[6], RAM_size, boot_device, kernel_filename,
>                    kernel_cmdline, initrd_filename, cpu_model);
>  }
>
>  /* SPARCClassic hardware initialisation */
> -static void scls_init(ram_addr_t RAM_size,
> -                      const char *boot_device,
> -                      const char *kernel_filename, const char *kernel_cmdline,
> -                      const char *initrd_filename, const char *cpu_model)
> +static void scls_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sun4m_hw_init(&sun4m_hwdefs[7], RAM_size, boot_device, kernel_filename,
>                    kernel_cmdline, initrd_filename, cpu_model);
>  }
>
>  /* SPARCbook hardware initialisation */
> -static void sbook_init(ram_addr_t RAM_size,
> -                       const char *boot_device,
> -                       const char *kernel_filename, const char *kernel_cmdline,
> -                       const char *initrd_filename, const char *cpu_model)
> +static void sbook_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sun4m_hw_init(&sun4m_hwdefs[8], RAM_size, boot_device, kernel_filename,
>                    kernel_cmdline, initrd_filename, cpu_model);
>  }
> @@ -1651,21 +1677,27 @@ static void sun4d_hw_init(const struct sun4d_hwdef *hwdef, ram_addr_t RAM_size,
>  }
>
>  /* SPARCserver 1000 hardware initialisation */
> -static void ss1000_init(ram_addr_t RAM_size,
> -                        const char *boot_device,
> -                        const char *kernel_filename, const char *kernel_cmdline,
> -                        const char *initrd_filename, const char *cpu_model)
> +static void ss1000_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sun4d_hw_init(&sun4d_hwdefs[0], RAM_size, boot_device, kernel_filename,
>                    kernel_cmdline, initrd_filename, cpu_model);
>  }
>
>  /* SPARCcenter 2000 hardware initialisation */
> -static void ss2000_init(ram_addr_t RAM_size,
> -                        const char *boot_device,
> -                        const char *kernel_filename, const char *kernel_cmdline,
> -                        const char *initrd_filename, const char *cpu_model)
> +static void ss2000_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sun4d_hw_init(&sun4d_hwdefs[1], RAM_size, boot_device, kernel_filename,
>                    kernel_cmdline, initrd_filename, cpu_model);
>  }
> @@ -1845,11 +1877,14 @@ static void sun4c_hw_init(const struct sun4c_hwdef *hwdef, ram_addr_t RAM_size,
>  }
>
>  /* SPARCstation 2 hardware initialisation */
> -static void ss2_init(ram_addr_t RAM_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void ss2_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sun4c_hw_init(&sun4c_hwdefs[0], RAM_size, boot_device, kernel_filename,
>                    kernel_cmdline, initrd_filename, cpu_model);
>  }
> diff --git a/hw/sun4u.c b/hw/sun4u.c
> index 07cd042..379768c 100644
> --- a/hw/sun4u.c
> +++ b/hw/sun4u.c
> @@ -930,31 +930,40 @@ static const struct hwdef hwdefs[] = {
>  };
>
>  /* Sun4u hardware initialisation */
> -static void sun4u_init(ram_addr_t RAM_size,
> -                       const char *boot_devices,
> -                       const char *kernel_filename, const char *kernel_cmdline,
> -                       const char *initrd_filename, const char *cpu_model)
> -{
> +static void sun4u_init(QEMUMachineInitArgs *args)
> +{
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_devices = args->boot_device;
>      sun4uv_init(get_system_memory(), RAM_size, boot_devices, kernel_filename,
>                  kernel_cmdline, initrd_filename, cpu_model, &hwdefs[0]);
>  }
>
>  /* Sun4v hardware initialisation */
> -static void sun4v_init(ram_addr_t RAM_size,
> -                       const char *boot_devices,
> -                       const char *kernel_filename, const char *kernel_cmdline,
> -                       const char *initrd_filename, const char *cpu_model)
> -{
> +static void sun4v_init(QEMUMachineInitArgs *args)
> +{
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_devices = args->boot_device;
>      sun4uv_init(get_system_memory(), RAM_size, boot_devices, kernel_filename,
>                  kernel_cmdline, initrd_filename, cpu_model, &hwdefs[1]);
>  }
>
>  /* Niagara hardware initialisation */
> -static void niagara_init(ram_addr_t RAM_size,
> -                         const char *boot_devices,
> -                         const char *kernel_filename, const char *kernel_cmdline,
> -                         const char *initrd_filename, const char *cpu_model)
> -{
> +static void niagara_init(QEMUMachineInitArgs *args)
> +{
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_devices = args->boot_device;
>      sun4uv_init(get_system_memory(), RAM_size, boot_devices, kernel_filename,
>                  kernel_cmdline, initrd_filename, cpu_model, &hwdefs[2]);
>  }
> diff --git a/hw/tosa.c b/hw/tosa.c
> index 297a8c2..512278c 100644
> --- a/hw/tosa.c
> +++ b/hw/tosa.c
> @@ -205,11 +205,12 @@ static struct arm_boot_info tosa_binfo = {
>      .ram_size = 0x04000000,
>  };
>
> -static void tosa_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void tosa_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      MemoryRegion *address_space_mem = get_system_memory();
>      MemoryRegion *rom = g_new(MemoryRegion, 1);
>      PXA2xxState *mpu;
> diff --git a/hw/versatilepb.c b/hw/versatilepb.c
> index 7a92034..686dcc7 100644
> --- a/hw/versatilepb.c
> +++ b/hw/versatilepb.c
> @@ -342,22 +342,28 @@ static void versatile_init(ram_addr_t ram_size,
>      arm_load_kernel(cpu, &versatile_binfo);
>  }
>
> -static void vpb_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void vpb_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      versatile_init(ram_size,
>                     boot_device,
>                     kernel_filename, kernel_cmdline,
>                     initrd_filename, cpu_model, 0x183);
>  }
>
> -static void vab_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void vab_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      versatile_init(ram_size,
>                     boot_device,
>                     kernel_filename, kernel_cmdline,
> diff --git a/hw/vexpress.c b/hw/vexpress.c
> index 3596d1e..36503d6 100644
> --- a/hw/vexpress.c
> +++ b/hw/vexpress.c
> @@ -467,25 +467,27 @@ static void vexpress_common_init(const VEDBoardInfo *daughterboard,
>      arm_load_kernel(arm_env_get_cpu(first_cpu), &vexpress_binfo);
>  }
>
> -static void vexpress_a9_init(ram_addr_t ram_size,
> -                             const char *boot_device,
> -                             const char *kernel_filename,
> -                             const char *kernel_cmdline,
> -                             const char *initrd_filename,
> -                             const char *cpu_model)
> +static void vexpress_a9_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      vexpress_common_init(&a9_daughterboard,
>                           ram_size, boot_device, kernel_filename,
>                           kernel_cmdline, initrd_filename, cpu_model);
>  }
>
> -static void vexpress_a15_init(ram_addr_t ram_size,
> -                              const char *boot_device,
> -                              const char *kernel_filename,
> -                              const char *kernel_cmdline,
> -                              const char *initrd_filename,
> -                              const char *cpu_model)
> +static void vexpress_a15_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      vexpress_common_init(&a15_daughterboard,
>                           ram_size, boot_device, kernel_filename,
>                           kernel_cmdline, initrd_filename, cpu_model);
> diff --git a/hw/virtex_ml507.c b/hw/virtex_ml507.c
> index 79bc0d1..a09b27a 100644
> --- a/hw/virtex_ml507.c
> +++ b/hw/virtex_ml507.c
> @@ -183,12 +183,12 @@ static int xilinx_load_device_tree(target_phys_addr_t addr,
>      return fdt_size;
>  }
>
> -static void virtex_init(ram_addr_t ram_size,
> -                        const char *boot_device,
> -                        const char *kernel_filename,
> -                        const char *kernel_cmdline,
> -                        const char *initrd_filename, const char *cpu_model)
> +static void virtex_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
>      MemoryRegion *address_space_mem = get_system_memory();
>      DeviceState *dev;
>      PowerPCCPU *cpu;
> diff --git a/hw/xen_machine_pv.c b/hw/xen_machine_pv.c
> index 4b72aa7..4264703 100644
> --- a/hw/xen_machine_pv.c
> +++ b/hw/xen_machine_pv.c
> @@ -29,13 +29,12 @@
>  #include "xen_domainbuild.h"
>  #include "blockdev.h"
>
> -static void xen_init_pv(ram_addr_t ram_size,
> -                       const char *boot_device,
> -                       const char *kernel_filename,
> -                       const char *kernel_cmdline,
> -                       const char *initrd_filename,
> -                       const char *cpu_model)
> +static void xen_init_pv(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      X86CPU *cpu;
>      CPUX86State *env;
>      DriveInfo *dinfo;
> diff --git a/hw/xilinx_zynq.c b/hw/xilinx_zynq.c
> index 7e6c273..83f322e 100644
> --- a/hw/xilinx_zynq.c
> +++ b/hw/xilinx_zynq.c
> @@ -46,10 +46,13 @@ static void gem_init(NICInfo *nd, uint32_t base, qemu_irq irq)
>      sysbus_connect_irq(s, 0, irq);
>  }
>
> -static void zynq_init(ram_addr_t ram_size, const char *boot_device,
> -                        const char *kernel_filename, const char *kernel_cmdline,
> -                        const char *initrd_filename, const char *cpu_model)
> +static void zynq_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      ARMCPU *cpu;
>      MemoryRegion *address_space_mem = get_system_memory();
>      MemoryRegion *ext_ram = g_new(MemoryRegion, 1);
> diff --git a/hw/xtensa_lx60.c b/hw/xtensa_lx60.c
> index 3653f65..1fd2c47 100644
> --- a/hw/xtensa_lx60.c
> +++ b/hw/xtensa_lx60.c
> @@ -268,11 +268,14 @@ static void lx_init(const LxBoardDesc *board,
>      }
>  }
>
> -static void xtensa_lx60_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void xtensa_lx60_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      static const LxBoardDesc lx60_board = {
>          .flash_size = 0x400000,
>          .flash_sector_size = 0x10000,
> @@ -283,11 +286,14 @@ static void xtensa_lx60_init(ram_addr_t ram_size,
>              initrd_filename, cpu_model);
>  }
>
> -static void xtensa_lx200_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void xtensa_lx200_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      static const LxBoardDesc lx200_board = {
>          .flash_size = 0x1000000,
>          .flash_sector_size = 0x20000,
> diff --git a/hw/xtensa_sim.c b/hw/xtensa_sim.c
> index 831460b..2e846d8 100644
> --- a/hw/xtensa_sim.c
> +++ b/hw/xtensa_sim.c
> @@ -96,11 +96,14 @@ static void sim_init(ram_addr_t ram_size,
>      }
>  }
>
> -static void xtensa_sim_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void xtensa_sim_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      if (!cpu_model) {
>          cpu_model = XTENSA_DEFAULT_CPU_MODEL;
>      }
> diff --git a/hw/z2.c b/hw/z2.c
> index 289cee9..0927bad 100644
> --- a/hw/z2.c
> +++ b/hw/z2.c
> @@ -294,11 +294,12 @@ static TypeInfo aer915_info = {
>      .class_init    = aer915_class_init,
>  };
>
> -static void z2_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void z2_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      MemoryRegion *address_space_mem = get_system_memory();
>      uint32_t sector_len = 0x10000;
>      PXA2xxState *mpu;
> diff --git a/vl.c b/vl.c
> index 8d305ca..b05e224 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -3624,8 +3624,13 @@ int main(int argc, char **argv, char **envp)
>
>      qdev_machine_init();
>
> -    machine->init(ram_size, boot_devices,
> -                  kernel_filename, kernel_cmdline, initrd_filename, cpu_model);
> +    QEMUMachineInitArgs args = { .ram_size = ram_size,
> +                                 .boot_device = boot_devices,
> +                                 .kernel_filename = kernel_filename,
> +                                 .kernel_cmdline = kernel_cmdline,
> +                                 .initrd_filename = initrd_filename,
> +                                 .cpu_model = cpu_model };
> +    machine->init(&args);
>
>      cpu_synchronize_all_post_init();
>
> --
> 1.7.11.4
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 13 14:42:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Oct 2012 14:42:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TN2uQ-00029R-3w; Sat, 13 Oct 2012 14:41:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TN2uO-00029M-4B
	for xen-devel@lists.xensource.com; Sat, 13 Oct 2012 14:41:44 +0000
Received: from [85.158.139.211:63687] by server-14.bemta-5.messagelabs.com id
	93/D5-22559-7AD79705; Sat, 13 Oct 2012 14:41:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1350139302!22119366!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQyMjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26161 invoked from network); 13 Oct 2012 14:41:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Oct 2012 14:41:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,580,1344211200"; d="scan'208";a="15143784"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Oct 2012 14:41:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sat, 13 Oct 2012 15:41:42 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1TN2uL-00050O-IU;
	Sat, 13 Oct 2012 14:41:41 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TN2uL-0007IH-Bo;
	Sat, 13 Oct 2012 15:41:41 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13959-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 13 Oct 2012 15:41:41 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 13959: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13959 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13959/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-multivcpu 14 guest-localmigrate/x10    fail REGR. vs. 13948

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore         fail REGR. vs. 13948
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13948
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13948

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 linux                40e6f9362555294cf1ce8abb1981b11d622e04d6
baseline version:
 linux                24e842ae6cb8179126246ebcbfc477b36a7b8719

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 40e6f9362555294cf1ce8abb1981b11d622e04d6
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Oct 13 05:37:00 2012 +0900

    Linux 3.0.46

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 13 14:42:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Oct 2012 14:42:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TN2uQ-00029R-3w; Sat, 13 Oct 2012 14:41:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TN2uO-00029M-4B
	for xen-devel@lists.xensource.com; Sat, 13 Oct 2012 14:41:44 +0000
Received: from [85.158.139.211:63687] by server-14.bemta-5.messagelabs.com id
	93/D5-22559-7AD79705; Sat, 13 Oct 2012 14:41:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1350139302!22119366!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQyMjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26161 invoked from network); 13 Oct 2012 14:41:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Oct 2012 14:41:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,580,1344211200"; d="scan'208";a="15143784"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Oct 2012 14:41:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sat, 13 Oct 2012 15:41:42 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1TN2uL-00050O-IU;
	Sat, 13 Oct 2012 14:41:41 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TN2uL-0007IH-Bo;
	Sat, 13 Oct 2012 15:41:41 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13959-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 13 Oct 2012 15:41:41 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 13959: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13959 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13959/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-multivcpu 14 guest-localmigrate/x10    fail REGR. vs. 13948

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore         fail REGR. vs. 13948
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13948
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13948

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 linux                40e6f9362555294cf1ce8abb1981b11d622e04d6
baseline version:
 linux                24e842ae6cb8179126246ebcbfc477b36a7b8719

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 40e6f9362555294cf1ce8abb1981b11d622e04d6
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Oct 13 05:37:00 2012 +0900

    Linux 3.0.46

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 13 16:00:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Oct 2012 16:00:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TN47h-0002f8-Mx; Sat, 13 Oct 2012 15:59:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1TN47g-0002f0-6d
	for xen-devel@lists.xen.org; Sat, 13 Oct 2012 15:59:32 +0000
Received: from [85.158.143.99:62315] by server-1.bemta-4.messagelabs.com id
	D7/BE-19551-3EF89705; Sat, 13 Oct 2012 15:59:31 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-216.messagelabs.com!1350143970!27733576!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MzI4MjA=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MzI4MjA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32357 invoked from network); 13 Oct 2012 15:59:30 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Oct 2012 15:59:30 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHjC0PEDTh
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-092-134.pools.arcor-ip.net [88.65.92.134])
	by smtp.strato.de (josoe mo27) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id k02e9fo9DEsV6g
	for <xen-devel@lists.xen.org>; Sat, 13 Oct 2012 17:59:30 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 38C1A183A7
	for <xen-devel@lists.xen.org>; Sat, 13 Oct 2012 17:59:29 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 5aa14d5afe6b1f35b23029ae90b7edb20367bbeb
Message-Id: <5aa14d5afe6b1f35b230.1350143968@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sat, 13 Oct 2012 17:59:28 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] hotplug/Linux: close lockfd after lock attempt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1350143934 -7200
# Node ID 5aa14d5afe6b1f35b23029ae90b7edb20367bbeb
# Parent  e0e1350dfe9b7a6cacb1378f75d8e6536d22eb2d
hotplug/Linux: close lockfd after lock attempt

When a HVM guest is shutdown some of the 'remove' events can not claim
the lock for some reason. Instead they try to grab the lock in a busy
loop, until udev reaps the xen-hotplug-cleanup helper.
After analyzing the resulting logfile its not obvious what the cause is.
The only explanation is that bash (?) gets confused if the same lockfd
is opened again and again. Closing it in each iteration seem to fix the
issue.

This was observed with sles11sp2 and 4.2 xend.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r e0e1350dfe9b -r 5aa14d5afe6b tools/hotplug/Linux/locking.sh
--- a/tools/hotplug/Linux/locking.sh
+++ b/tools/hotplug/Linux/locking.sh
@@ -59,6 +59,7 @@ claim_lock()
             print "y\n" if $fd_inum eq $file_inum;
                              ' "$_lockfile" )
         if [ x$rightfile = xy ]; then break; fi
+        eval "exec $_lockfd<&-"
     done
 }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 13 16:00:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Oct 2012 16:00:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TN47h-0002f8-Mx; Sat, 13 Oct 2012 15:59:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1TN47g-0002f0-6d
	for xen-devel@lists.xen.org; Sat, 13 Oct 2012 15:59:32 +0000
Received: from [85.158.143.99:62315] by server-1.bemta-4.messagelabs.com id
	D7/BE-19551-3EF89705; Sat, 13 Oct 2012 15:59:31 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-216.messagelabs.com!1350143970!27733576!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MzI4MjA=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MzI4MjA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32357 invoked from network); 13 Oct 2012 15:59:30 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Oct 2012 15:59:30 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHjC0PEDTh
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-092-134.pools.arcor-ip.net [88.65.92.134])
	by smtp.strato.de (josoe mo27) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id k02e9fo9DEsV6g
	for <xen-devel@lists.xen.org>; Sat, 13 Oct 2012 17:59:30 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 38C1A183A7
	for <xen-devel@lists.xen.org>; Sat, 13 Oct 2012 17:59:29 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 5aa14d5afe6b1f35b23029ae90b7edb20367bbeb
Message-Id: <5aa14d5afe6b1f35b230.1350143968@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sat, 13 Oct 2012 17:59:28 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] hotplug/Linux: close lockfd after lock attempt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1350143934 -7200
# Node ID 5aa14d5afe6b1f35b23029ae90b7edb20367bbeb
# Parent  e0e1350dfe9b7a6cacb1378f75d8e6536d22eb2d
hotplug/Linux: close lockfd after lock attempt

When a HVM guest is shutdown some of the 'remove' events can not claim
the lock for some reason. Instead they try to grab the lock in a busy
loop, until udev reaps the xen-hotplug-cleanup helper.
After analyzing the resulting logfile its not obvious what the cause is.
The only explanation is that bash (?) gets confused if the same lockfd
is opened again and again. Closing it in each iteration seem to fix the
issue.

This was observed with sles11sp2 and 4.2 xend.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r e0e1350dfe9b -r 5aa14d5afe6b tools/hotplug/Linux/locking.sh
--- a/tools/hotplug/Linux/locking.sh
+++ b/tools/hotplug/Linux/locking.sh
@@ -59,6 +59,7 @@ claim_lock()
             print "y\n" if $fd_inum eq $file_inum;
                              ' "$_lockfile" )
         if [ x$rightfile = xy ]; then break; fi
+        eval "exec $_lockfd<&-"
     done
 }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 13 22:36:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Oct 2012 22:36:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNAJP-0004Nx-Jo; Sat, 13 Oct 2012 22:36:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1TNAJN-0004Ns-Cf
	for xen-devel@lists.xen.org; Sat, 13 Oct 2012 22:36:01 +0000
Received: from [85.158.143.99:14879] by server-3.bemta-4.messagelabs.com id
	6D/3E-10075-0DCE9705; Sat, 13 Oct 2012 22:36:00 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-216.messagelabs.com!1350167759!27886815!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDMwMDE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDMwMDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15715 invoked from network); 13 Oct 2012 22:36:00 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Oct 2012 22:36:00 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr3s7pE3/i
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-067-216.pools.arcor-ip.net [84.57.67.216])
	by smtp.strato.de (joses mo19) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id C06bdao9DMTfLK
	for <xen-devel@lists.xen.org>; Sun, 14 Oct 2012 00:35:59 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 016CA18642; Sun, 14 Oct 2012 00:35:58 +0200 (CEST)
Date: Sun, 14 Oct 2012 00:35:58 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Message-ID: <20121013223558.GA19665@aepfle.de>
References: <5aa14d5afe6b1f35b230.1350143968@probook.site>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5aa14d5afe6b1f35b230.1350143968@probook.site>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Subject: Re: [Xen-devel] [PATCH] hotplug/Linux: close lockfd after lock
 attempt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Oct 13, Olaf Hering wrote:

> hotplug/Linux: close lockfd after lock attempt
> 
> When a HVM guest is shutdown some of the 'remove' events can not claim
> the lock for some reason. Instead they try to grab the lock in a busy
> loop, until udev reaps the xen-hotplug-cleanup helper.
> After analyzing the resulting logfile its not obvious what the cause is.
> The only explanation is that bash (?) gets confused if the same lockfd
> is opened again and again. Closing it in each iteration seem to fix the
> issue.

Can be reproduced with this testcase on sles11sp2, not on openSuSE 11.4:

 # cat test.sh
set -x
source locking.sh

l=lock
claim_lock $l
sleep 1
release_lock $l


 # bash test.sh & bash test.sh & bash test.sh & bash test.sh &


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 13 22:36:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 13 Oct 2012 22:36:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNAJP-0004Nx-Jo; Sat, 13 Oct 2012 22:36:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1TNAJN-0004Ns-Cf
	for xen-devel@lists.xen.org; Sat, 13 Oct 2012 22:36:01 +0000
Received: from [85.158.143.99:14879] by server-3.bemta-4.messagelabs.com id
	6D/3E-10075-0DCE9705; Sat, 13 Oct 2012 22:36:00 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-216.messagelabs.com!1350167759!27886815!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDMwMDE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDMwMDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15715 invoked from network); 13 Oct 2012 22:36:00 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Oct 2012 22:36:00 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr3s7pE3/i
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-067-216.pools.arcor-ip.net [84.57.67.216])
	by smtp.strato.de (joses mo19) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id C06bdao9DMTfLK
	for <xen-devel@lists.xen.org>; Sun, 14 Oct 2012 00:35:59 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 016CA18642; Sun, 14 Oct 2012 00:35:58 +0200 (CEST)
Date: Sun, 14 Oct 2012 00:35:58 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Message-ID: <20121013223558.GA19665@aepfle.de>
References: <5aa14d5afe6b1f35b230.1350143968@probook.site>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5aa14d5afe6b1f35b230.1350143968@probook.site>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Subject: Re: [Xen-devel] [PATCH] hotplug/Linux: close lockfd after lock
 attempt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Oct 13, Olaf Hering wrote:

> hotplug/Linux: close lockfd after lock attempt
> 
> When a HVM guest is shutdown some of the 'remove' events can not claim
> the lock for some reason. Instead they try to grab the lock in a busy
> loop, until udev reaps the xen-hotplug-cleanup helper.
> After analyzing the resulting logfile its not obvious what the cause is.
> The only explanation is that bash (?) gets confused if the same lockfd
> is opened again and again. Closing it in each iteration seem to fix the
> issue.

Can be reproduced with this testcase on sles11sp2, not on openSuSE 11.4:

 # cat test.sh
set -x
source locking.sh

l=lock
claim_lock $l
sleep 1
release_lock $l


 # bash test.sh & bash test.sh & bash test.sh & bash test.sh &


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 14 00:00:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Oct 2012 00:00:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNBc4-0004hT-2R; Sat, 13 Oct 2012 23:59:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rdunlap@xenotime.net>) id 1TNBc2-0004hO-Fz
	for xen-devel@lists.xensource.com; Sat, 13 Oct 2012 23:59:22 +0000
Received: from [85.158.143.35:25459] by server-2.bemta-4.messagelabs.com id
	F8/6E-25171-9500A705; Sat, 13 Oct 2012 23:59:21 +0000
X-Env-Sender: rdunlap@xenotime.net
X-Msg-Ref: server-10.tower-21.messagelabs.com!1350172760!11359792!1
X-Originating-IP: [173.254.64.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAxNzMuMjU0LjY0LjEwID0+IDU3ODY=\n,sa_preprocessor: 
	QmFkIElQOiAxNzMuMjU0LjY0LjEwID0+IDU3ODY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30793 invoked from network); 13 Oct 2012 23:59:20 -0000
Received: from oproxy11-pub.bluehost.com (HELO oproxy11-pub.bluehost.com)
	(173.254.64.10) by server-10.tower-21.messagelabs.com with SMTP;
	13 Oct 2012 23:59:20 -0000
Received: (qmail 4035 invoked by uid 0); 13 Oct 2012 23:59:19 -0000
Received: from unknown (HELO box742.bluehost.com) (66.147.244.242)
	by oproxy11.bluehost.com with SMTP; 13 Oct 2012 23:59:19 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenotime.net;
	s=default; 
	h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID;
	bh=6EETM2xHegz98RCx/s/+KgI5Nyvq5A5VMPuWNGzpd1Y=; 
	b=GHBn/LRVHxdTZWoHjDKM767kn3je10PTW9uWyhN59UAG12YfbQpSrdS9Q9YN2mdl2W4Ggrf99vRk/q6IqABckNdDYFZXSYWyzktkQIDAo+90dJ2g+V+IXyuccdUUO1wb;
Received: from [50.53.38.135] (port=37175 helo=[192.168.1.7])
	by box742.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256)
	(Exim 4.76) (envelope-from <rdunlap@xenotime.net>)
	id 1TNBbz-0002UG-M7; Sat, 13 Oct 2012 17:59:19 -0600
Message-ID: <507A004F.4080102@xenotime.net>
Date: Sat, 13 Oct 2012 16:59:11 -0700
From: Randy Dunlap <rdunlap@xenotime.net>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.15) Gecko/20110323 Thunderbird/3.1.9
MIME-Version: 1.0
To: Linus Torvalds <torvalds@linux-foundation.org>
References: <20121012134529.GA1560@phenom.dumpdata.com>
	<CA+55aFzfmJNTtrnRsEkb6B0=eTHNGuA+jBa1METOK3ycxNsM8g@mail.gmail.com>
In-Reply-To: <CA+55aFzfmJNTtrnRsEkb6B0=eTHNGuA+jBa1METOK3ycxNsM8g@mail.gmail.com>
X-Identified-User: {1807:box742.bluehost.com:xenotime:xenotime.net}
	{sentby:smtp auth 50.53.38.135 authed with
	rdunlap@xenotime.net}
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [GIT PULL] (xen) stable/for-linus-3.7-uapi-tag for
	v3.7-rc0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/12/2012 07:16 PM, Linus Torvalds wrote:

> On Fri, Oct 12, 2012 at 10:45 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
>>
>> Please pull!
> 
> Btw, please use the -M switch to get renames as renames (and
> --summary). You diffstat:
> 
>>  include/uapi/xen/Kbuild    |    2 +
>>  include/uapi/xen/evtchn.h  |   88 +++++++++++++++++++++++++++++++++++++++
>>  include/uapi/xen/privcmd.h |   98 ++++++++++++++++++++++++++++++++++++++++++++
>>  include/xen/Kbuild         |    2 -
>>  include/xen/evtchn.h       |   88 ---------------------------------------
>>  include/xen/privcmd.h      |   98 --------------------------------------------
>>  6 files changed, 188 insertions(+), 188 deletions(-)
> 
> is misleading, the correct one is much simpler:
> 
>  include/{ => uapi}/xen/evtchn.h  | 0
>  include/{ => uapi}/xen/privcmd.h | 0
>  include/xen/Kbuild               | 2 --
>  4 files changed, 2 insertions(+), 2 deletions(-)
>  rename include/{ => uapi}/xen/evtchn.h (100%)
>  rename include/{ => uapi}/xen/privcmd.h (100%)


showing once again that people don't read documentation  :(

(see Documentation/SubmittingPatches)

-- 
~Randy

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 14 00:00:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Oct 2012 00:00:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNBc4-0004hT-2R; Sat, 13 Oct 2012 23:59:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rdunlap@xenotime.net>) id 1TNBc2-0004hO-Fz
	for xen-devel@lists.xensource.com; Sat, 13 Oct 2012 23:59:22 +0000
Received: from [85.158.143.35:25459] by server-2.bemta-4.messagelabs.com id
	F8/6E-25171-9500A705; Sat, 13 Oct 2012 23:59:21 +0000
X-Env-Sender: rdunlap@xenotime.net
X-Msg-Ref: server-10.tower-21.messagelabs.com!1350172760!11359792!1
X-Originating-IP: [173.254.64.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAxNzMuMjU0LjY0LjEwID0+IDU3ODY=\n,sa_preprocessor: 
	QmFkIElQOiAxNzMuMjU0LjY0LjEwID0+IDU3ODY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30793 invoked from network); 13 Oct 2012 23:59:20 -0000
Received: from oproxy11-pub.bluehost.com (HELO oproxy11-pub.bluehost.com)
	(173.254.64.10) by server-10.tower-21.messagelabs.com with SMTP;
	13 Oct 2012 23:59:20 -0000
Received: (qmail 4035 invoked by uid 0); 13 Oct 2012 23:59:19 -0000
Received: from unknown (HELO box742.bluehost.com) (66.147.244.242)
	by oproxy11.bluehost.com with SMTP; 13 Oct 2012 23:59:19 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenotime.net;
	s=default; 
	h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID;
	bh=6EETM2xHegz98RCx/s/+KgI5Nyvq5A5VMPuWNGzpd1Y=; 
	b=GHBn/LRVHxdTZWoHjDKM767kn3je10PTW9uWyhN59UAG12YfbQpSrdS9Q9YN2mdl2W4Ggrf99vRk/q6IqABckNdDYFZXSYWyzktkQIDAo+90dJ2g+V+IXyuccdUUO1wb;
Received: from [50.53.38.135] (port=37175 helo=[192.168.1.7])
	by box742.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256)
	(Exim 4.76) (envelope-from <rdunlap@xenotime.net>)
	id 1TNBbz-0002UG-M7; Sat, 13 Oct 2012 17:59:19 -0600
Message-ID: <507A004F.4080102@xenotime.net>
Date: Sat, 13 Oct 2012 16:59:11 -0700
From: Randy Dunlap <rdunlap@xenotime.net>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.15) Gecko/20110323 Thunderbird/3.1.9
MIME-Version: 1.0
To: Linus Torvalds <torvalds@linux-foundation.org>
References: <20121012134529.GA1560@phenom.dumpdata.com>
	<CA+55aFzfmJNTtrnRsEkb6B0=eTHNGuA+jBa1METOK3ycxNsM8g@mail.gmail.com>
In-Reply-To: <CA+55aFzfmJNTtrnRsEkb6B0=eTHNGuA+jBa1METOK3ycxNsM8g@mail.gmail.com>
X-Identified-User: {1807:box742.bluehost.com:xenotime:xenotime.net}
	{sentby:smtp auth 50.53.38.135 authed with
	rdunlap@xenotime.net}
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [GIT PULL] (xen) stable/for-linus-3.7-uapi-tag for
	v3.7-rc0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/12/2012 07:16 PM, Linus Torvalds wrote:

> On Fri, Oct 12, 2012 at 10:45 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
>>
>> Please pull!
> 
> Btw, please use the -M switch to get renames as renames (and
> --summary). You diffstat:
> 
>>  include/uapi/xen/Kbuild    |    2 +
>>  include/uapi/xen/evtchn.h  |   88 +++++++++++++++++++++++++++++++++++++++
>>  include/uapi/xen/privcmd.h |   98 ++++++++++++++++++++++++++++++++++++++++++++
>>  include/xen/Kbuild         |    2 -
>>  include/xen/evtchn.h       |   88 ---------------------------------------
>>  include/xen/privcmd.h      |   98 --------------------------------------------
>>  6 files changed, 188 insertions(+), 188 deletions(-)
> 
> is misleading, the correct one is much simpler:
> 
>  include/{ => uapi}/xen/evtchn.h  | 0
>  include/{ => uapi}/xen/privcmd.h | 0
>  include/xen/Kbuild               | 2 --
>  4 files changed, 2 insertions(+), 2 deletions(-)
>  rename include/{ => uapi}/xen/evtchn.h (100%)
>  rename include/{ => uapi}/xen/privcmd.h (100%)


showing once again that people don't read documentation  :(

(see Documentation/SubmittingPatches)

-- 
~Randy

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 14 00:18:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Oct 2012 00:18:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNBuT-0005J3-Rp; Sun, 14 Oct 2012 00:18:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <netwiz@crc.id.au>) id 1TNBuR-0005Iy-PB
	for xen-devel@lists.xensource.com; Sun, 14 Oct 2012 00:18:24 +0000
Received: from [85.158.143.99:48989] by server-3.bemta-4.messagelabs.com id
	1A/00-10075-EC40A705; Sun, 14 Oct 2012 00:18:22 +0000
X-Env-Sender: netwiz@crc.id.au
X-Msg-Ref: server-16.tower-216.messagelabs.com!1350173900!22768589!1
X-Originating-IP: [203.56.246.92]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_8,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22426 invoked from network); 14 Oct 2012 00:18:21 -0000
Received: from mail.crc.id.au (HELO mail.crc.id.au) (203.56.246.92)
	by server-16.tower-216.messagelabs.com with SMTP;
	14 Oct 2012 00:18:21 -0000
Received: from [IPv6:2002:cb38:f71b:2:cd93:cd0c:11ac:939] (unknown
	[IPv6:2002:cb38:f71b:2:cd93:cd0c:11ac:939])
	by mail.crc.id.au (Postfix) with ESMTPSA id BA17ED5
	for <xen-devel@lists.xensource.com>;
	Sun, 14 Oct 2012 11:18:15 +1100 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crc.id.au; s=default;
	t=1350173895; bh=zyblcWtnvmun+d68QD9gC23SxFtZ30n/2SDVE49zxcE=;
	h=Date:From:To:Subject;
	b=pT1i3m8MSEXzTjT/UA2FJh00hbcH/GfpmsXtjJ+I0srTOM4cJc6usjHIto18E3mYN
	/4Juy/UA9KK5sPLlGZz8ezTLfVUQNB2C4km0w27+ZOaoWPb1io1dcd37CLm42+CID6
	HnSyv+FV28Jlvv6MBwcD+pSsBXUckB/pF1lga+zw=
Message-ID: <507A04D9.8030408@crc.id.au>
Date: Sun, 14 Oct 2012 11:18:33 +1100
From: Steven Haigh <netwiz@crc.id.au>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] xend running on EL5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0745154376752478885=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============0745154376752478885==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000605000205060109030604"

This is a cryptographically signed message in MIME format.

--------------ms000605000205060109030604
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi guys,

I've been trying to get my Xen 4.2 RPMs to build on both EL5 and EL6=20
systems. I'm just about there but I've noticed one issue which I'm not=20
100% sure of the best way to resolve.

/usr/sbin/xend is a simple python launcher that runs fine as is on EL6,=20
but in EL5 it comes up with:

# service xend start
Starting xend daemon: Unknown option: -s
Unknown option: -s
usage: /usr/bin/python [option] ... [-c cmd | -m mod | file | -] [arg] ..=
=2E
Try `python -h' for more information.

The standard hashbang line for xend is:
#!/usr/bin/python -Es

EL5 seems to run python 2.4.3 which doesn't have the -s option.

So, what would be the best way to work around this?

  I could patch out the -s when building the RPMs, however would that=20
have any effect on EL6 systems?

--=20
Steven Haigh

Email: netwiz@crc.id.au
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299


--------------ms000605000205060109030604
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOSjCC
BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr
lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM
zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6
qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD
kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95
m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD
CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy
6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI
zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf
KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR
z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9
sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie
uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t
w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ
G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t
5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIIDjCCBvagAwIBAgIDA7ikMA0GCSqGSIb3DQEB
BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g
Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTIwMjEzMTMzODE0
WhcNMTMwMjEzMTc1NjUzWjBXMRkwFwYDVQQNExB3bjVlU1RNM2RWOUIwMEk5MRkwFwYDVQQD
DBBuZXR3aXpAY3JjLmlkLmF1MR8wHQYJKoZIhvcNAQkBFhBuZXR3aXpAY3JjLmlkLmF1MIIC
IjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAzTaLiL78pm4Hqp7Pou4C60jt2wdvDiPt
Sq6hspKk6oaST7BFeDOfoed3mvzytkjNr3C1gds3zsHulAMzRjuX2M1zPkfaj5QFkmlqQcxr
+tnaf8QFpn9PrUcjpbYDYPxdcGR+SeClKzmjdxicHuYDrD8YXnbk+k8dWDaCuv5sKRQHJmIR
maqUIGoVML+/kUR+sqkMpnbhOsL+E84Hg4fxLzpV3Tjf9bZbKgaspvg+BeJJCYKThBxMnZJI
cQ9JzDGL4rO2BEuTXI9Ofl0+AAttBEpZeqc2rePCfA9NivKTCZ0qaFKmvM5SN7TiZUqv80rD
ewTp+OLXNZEd5aa5jEDPNlznkcX0WfuKCmtyIEzT7PgHl1tOWTx7nw6FVWcB8qjC6xlyaL6W
1oS7Om3b2ka+9vSiz7DrPZzUDZuS91Fr2zIIMrrRzhN8q/JdQf8lGTydpmoRUB0z+BAcH8V/
nOcMMDogqV6/dCfywi7zFQK4AsiPSpyBAZyO53J4uPgoIzSpFj54f83KRIobHCWDU1BaU2+6
CfEoAD3iMId1tcFWTXikEThL+3oHQullq9EbPR4f3ToAU7aTZYWG4KNKrmG93KAfyCUFb+bf
mt3hf1BprKIUJnpOxdZHi0KwLXVwURiB4XQKZpEWL8mRbHRdxVATKrrJAHOFTl3/s37VLprP
J9kCAwEAAaOCA6swggOnMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsG
AQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUS9is0NdoOI3DZ/36Zlq78IrSedgwHwYDVR0j
BBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwGwYDVR0RBBQwEoEQbmV0d2l6QGNyYy5pZC5h
dTCCAiEGA1UdIASCAhgwggIUMIICEAYLKwYBBAGBtTcBAgIwggH/MC4GCCsGAQUFBwIBFiJo
dHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0
ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVp
cmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0
aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5
IG9ibGlnYXRpb25zLjCBnAYIKwYBBQUHAgIwgY8wJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlv
biBBdXRob3JpdHkwAwIBAhpkTGlhYmlsaXR5IGFuZCB3YXJyYW50aWVzIGFyZSBsaW1pdGVk
ISBTZWUgc2VjdGlvbiAiTGVnYWwgYW5kIExpbWl0YXRpb25zIiBvZiB0aGUgU3RhcnRDb20g
Q0EgcG9saWN5LjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j
cnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz
cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNV
HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBABL6
TyHlAHW0kkHb0ZLcd/pn7Ue0B5mIWBhmta4dK8qd0hXw+/lhpWaJWR/RltCSPabxSd+Lm9Iw
NWm7WP73GHAGby0TC+siwDJSk7CwDBqnVM1T3XQ5TgjfVX7h9qjVixsSWzAD++dXFmpf/344
Uf3zcG/hKJSeRtOvM/88nn4eJtrn7QFnIm4AJpHEgrqwU/0pmQBLwmEYS1G5cr04Oact2v6W
L3JHOlEP8lPBAO9GtZD8UZGmBoDTNG0Rf4TnVTBGdw1sLZqpXnkcVI+rDUaFk/jb7AtCB30N
8tbm2I5ALevgjv+vNMZIQD/0AgOaylGrQwbP852lgOvMo2AdpGExggTdMIIE2QIBATCBlDCB
jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy
ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz
IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMDuKQwCQYFKw4DAhoFAKCCAh0w
GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMDE0MDAxODMz
WjAjBgkqhkiG9w0BCQQxFgQUenOqCM6RuTWKt7SHcmm7ySkPHbQwbAYJKoZIhvcNAQkPMV8w
XTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA
gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpQYJKwYBBAGCNxAE
MYGXMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwO4pDCBpwYLKoZI
hvcNAQkQAgsxgZeggZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu
MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQD
Ey9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDA7ik
MA0GCSqGSIb3DQEBAQUABIICAFm4Kz+rv+MTtCvZSTBfcO4MoAbOgulzZtsYLihrT4KcIsb9
pZ3OpuOlOfYjVIFpt49SsdBhowMn0tDfUBa7ALxR4yO0WiDHAxGQ9vpBYA3kLCjYhKvE3Daj
QkK6cdEPYT3OTtewynoRkpZN59T/ToRUW2oSowd1Qciv9sib77m3dxSQy8psQ+Z0RbBmVjEC
K4VVUDfBQKy5vJfkyQNPBCZ/dHC9I3lem29OkZaPwhYflYxbnZklqaP1pFZjPYP8bF1n56eg
rD28e/zDNVWz22thUaNFJLG/rRKJfMSR+twsJsF8JcM/Q64nHePo3LVKQiJhlxu5E3gnDpPt
zNBoixpEszQ7+QcMpyxY/gHyb8ie64+NVogUc0bGoqzmFCoWFkhGTa1Ic8kbHfsE0eCZoCxY
IupNdkfOFebAN18BBxQj0xYbQ0uyA/tKzs1MsTUE6OY6NgVMuk+X1FAoMDxRXSsdLLWbYWix
bPanqzv/OA1YZOyjtgkeM4h10QY0iGKYjUK1uIxDanE5F6ZkonhO2akkDmDNAOh3i4MJf/3T
gA6DXZulRy1qqfNRxrIFArlOfcjRNFE7Bs+h15rwG40zYTX2JL9FqoORYU3o+9AcvEOf/gZ+
YeF+pcPb5kT5gvQf3AtxlSWAKuyn6aCBw7xfO45owt2RQNH4Bhb9O6Ohc4gSAAAAAAAA
--------------ms000605000205060109030604--


--===============0745154376752478885==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0745154376752478885==--


From xen-devel-bounces@lists.xen.org Sun Oct 14 00:18:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Oct 2012 00:18:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNBuT-0005J3-Rp; Sun, 14 Oct 2012 00:18:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <netwiz@crc.id.au>) id 1TNBuR-0005Iy-PB
	for xen-devel@lists.xensource.com; Sun, 14 Oct 2012 00:18:24 +0000
Received: from [85.158.143.99:48989] by server-3.bemta-4.messagelabs.com id
	1A/00-10075-EC40A705; Sun, 14 Oct 2012 00:18:22 +0000
X-Env-Sender: netwiz@crc.id.au
X-Msg-Ref: server-16.tower-216.messagelabs.com!1350173900!22768589!1
X-Originating-IP: [203.56.246.92]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_8,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22426 invoked from network); 14 Oct 2012 00:18:21 -0000
Received: from mail.crc.id.au (HELO mail.crc.id.au) (203.56.246.92)
	by server-16.tower-216.messagelabs.com with SMTP;
	14 Oct 2012 00:18:21 -0000
Received: from [IPv6:2002:cb38:f71b:2:cd93:cd0c:11ac:939] (unknown
	[IPv6:2002:cb38:f71b:2:cd93:cd0c:11ac:939])
	by mail.crc.id.au (Postfix) with ESMTPSA id BA17ED5
	for <xen-devel@lists.xensource.com>;
	Sun, 14 Oct 2012 11:18:15 +1100 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crc.id.au; s=default;
	t=1350173895; bh=zyblcWtnvmun+d68QD9gC23SxFtZ30n/2SDVE49zxcE=;
	h=Date:From:To:Subject;
	b=pT1i3m8MSEXzTjT/UA2FJh00hbcH/GfpmsXtjJ+I0srTOM4cJc6usjHIto18E3mYN
	/4Juy/UA9KK5sPLlGZz8ezTLfVUQNB2C4km0w27+ZOaoWPb1io1dcd37CLm42+CID6
	HnSyv+FV28Jlvv6MBwcD+pSsBXUckB/pF1lga+zw=
Message-ID: <507A04D9.8030408@crc.id.au>
Date: Sun, 14 Oct 2012 11:18:33 +1100
From: Steven Haigh <netwiz@crc.id.au>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] xend running on EL5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0745154376752478885=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============0745154376752478885==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000605000205060109030604"

This is a cryptographically signed message in MIME format.

--------------ms000605000205060109030604
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi guys,

I've been trying to get my Xen 4.2 RPMs to build on both EL5 and EL6=20
systems. I'm just about there but I've noticed one issue which I'm not=20
100% sure of the best way to resolve.

/usr/sbin/xend is a simple python launcher that runs fine as is on EL6,=20
but in EL5 it comes up with:

# service xend start
Starting xend daemon: Unknown option: -s
Unknown option: -s
usage: /usr/bin/python [option] ... [-c cmd | -m mod | file | -] [arg] ..=
=2E
Try `python -h' for more information.

The standard hashbang line for xend is:
#!/usr/bin/python -Es

EL5 seems to run python 2.4.3 which doesn't have the -s option.

So, what would be the best way to work around this?

  I could patch out the -s when building the RPMs, however would that=20
have any effect on EL6 systems?

--=20
Steven Haigh

Email: netwiz@crc.id.au
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299


--------------ms000605000205060109030604
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOSjCC
BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr
lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM
zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6
qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD
kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95
m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD
CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy
6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI
zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf
KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR
z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9
sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie
uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t
w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ
G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t
5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIIDjCCBvagAwIBAgIDA7ikMA0GCSqGSIb3DQEB
BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g
Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTIwMjEzMTMzODE0
WhcNMTMwMjEzMTc1NjUzWjBXMRkwFwYDVQQNExB3bjVlU1RNM2RWOUIwMEk5MRkwFwYDVQQD
DBBuZXR3aXpAY3JjLmlkLmF1MR8wHQYJKoZIhvcNAQkBFhBuZXR3aXpAY3JjLmlkLmF1MIIC
IjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAzTaLiL78pm4Hqp7Pou4C60jt2wdvDiPt
Sq6hspKk6oaST7BFeDOfoed3mvzytkjNr3C1gds3zsHulAMzRjuX2M1zPkfaj5QFkmlqQcxr
+tnaf8QFpn9PrUcjpbYDYPxdcGR+SeClKzmjdxicHuYDrD8YXnbk+k8dWDaCuv5sKRQHJmIR
maqUIGoVML+/kUR+sqkMpnbhOsL+E84Hg4fxLzpV3Tjf9bZbKgaspvg+BeJJCYKThBxMnZJI
cQ9JzDGL4rO2BEuTXI9Ofl0+AAttBEpZeqc2rePCfA9NivKTCZ0qaFKmvM5SN7TiZUqv80rD
ewTp+OLXNZEd5aa5jEDPNlznkcX0WfuKCmtyIEzT7PgHl1tOWTx7nw6FVWcB8qjC6xlyaL6W
1oS7Om3b2ka+9vSiz7DrPZzUDZuS91Fr2zIIMrrRzhN8q/JdQf8lGTydpmoRUB0z+BAcH8V/
nOcMMDogqV6/dCfywi7zFQK4AsiPSpyBAZyO53J4uPgoIzSpFj54f83KRIobHCWDU1BaU2+6
CfEoAD3iMId1tcFWTXikEThL+3oHQullq9EbPR4f3ToAU7aTZYWG4KNKrmG93KAfyCUFb+bf
mt3hf1BprKIUJnpOxdZHi0KwLXVwURiB4XQKZpEWL8mRbHRdxVATKrrJAHOFTl3/s37VLprP
J9kCAwEAAaOCA6swggOnMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsG
AQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUS9is0NdoOI3DZ/36Zlq78IrSedgwHwYDVR0j
BBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwGwYDVR0RBBQwEoEQbmV0d2l6QGNyYy5pZC5h
dTCCAiEGA1UdIASCAhgwggIUMIICEAYLKwYBBAGBtTcBAgIwggH/MC4GCCsGAQUFBwIBFiJo
dHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0
ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVp
cmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0
aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5
IG9ibGlnYXRpb25zLjCBnAYIKwYBBQUHAgIwgY8wJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlv
biBBdXRob3JpdHkwAwIBAhpkTGlhYmlsaXR5IGFuZCB3YXJyYW50aWVzIGFyZSBsaW1pdGVk
ISBTZWUgc2VjdGlvbiAiTGVnYWwgYW5kIExpbWl0YXRpb25zIiBvZiB0aGUgU3RhcnRDb20g
Q0EgcG9saWN5LjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j
cnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz
cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNV
HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBABL6
TyHlAHW0kkHb0ZLcd/pn7Ue0B5mIWBhmta4dK8qd0hXw+/lhpWaJWR/RltCSPabxSd+Lm9Iw
NWm7WP73GHAGby0TC+siwDJSk7CwDBqnVM1T3XQ5TgjfVX7h9qjVixsSWzAD++dXFmpf/344
Uf3zcG/hKJSeRtOvM/88nn4eJtrn7QFnIm4AJpHEgrqwU/0pmQBLwmEYS1G5cr04Oact2v6W
L3JHOlEP8lPBAO9GtZD8UZGmBoDTNG0Rf4TnVTBGdw1sLZqpXnkcVI+rDUaFk/jb7AtCB30N
8tbm2I5ALevgjv+vNMZIQD/0AgOaylGrQwbP852lgOvMo2AdpGExggTdMIIE2QIBATCBlDCB
jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy
ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz
IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMDuKQwCQYFKw4DAhoFAKCCAh0w
GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMDE0MDAxODMz
WjAjBgkqhkiG9w0BCQQxFgQUenOqCM6RuTWKt7SHcmm7ySkPHbQwbAYJKoZIhvcNAQkPMV8w
XTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA
gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpQYJKwYBBAGCNxAE
MYGXMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwO4pDCBpwYLKoZI
hvcNAQkQAgsxgZeggZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu
MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQD
Ey9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDA7ik
MA0GCSqGSIb3DQEBAQUABIICAFm4Kz+rv+MTtCvZSTBfcO4MoAbOgulzZtsYLihrT4KcIsb9
pZ3OpuOlOfYjVIFpt49SsdBhowMn0tDfUBa7ALxR4yO0WiDHAxGQ9vpBYA3kLCjYhKvE3Daj
QkK6cdEPYT3OTtewynoRkpZN59T/ToRUW2oSowd1Qciv9sib77m3dxSQy8psQ+Z0RbBmVjEC
K4VVUDfBQKy5vJfkyQNPBCZ/dHC9I3lem29OkZaPwhYflYxbnZklqaP1pFZjPYP8bF1n56eg
rD28e/zDNVWz22thUaNFJLG/rRKJfMSR+twsJsF8JcM/Q64nHePo3LVKQiJhlxu5E3gnDpPt
zNBoixpEszQ7+QcMpyxY/gHyb8ie64+NVogUc0bGoqzmFCoWFkhGTa1Ic8kbHfsE0eCZoCxY
IupNdkfOFebAN18BBxQj0xYbQ0uyA/tKzs1MsTUE6OY6NgVMuk+X1FAoMDxRXSsdLLWbYWix
bPanqzv/OA1YZOyjtgkeM4h10QY0iGKYjUK1uIxDanE5F6ZkonhO2akkDmDNAOh3i4MJf/3T
gA6DXZulRy1qqfNRxrIFArlOfcjRNFE7Bs+h15rwG40zYTX2JL9FqoORYU3o+9AcvEOf/gZ+
YeF+pcPb5kT5gvQf3AtxlSWAKuyn6aCBw7xfO45owt2RQNH4Bhb9O6Ohc4gSAAAAAAAA
--------------ms000605000205060109030604--


--===============0745154376752478885==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0745154376752478885==--


From xen-devel-bounces@lists.xen.org Sun Oct 14 04:41:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Oct 2012 04:41:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNG0S-00028m-Hp; Sun, 14 Oct 2012 04:40:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TNG0Q-00028h-To
	for xen-devel@lists.xensource.com; Sun, 14 Oct 2012 04:40:51 +0000
Received: from [85.158.138.51:40106] by server-8.bemta-3.messagelabs.com id
	D8/1D-10525-2524A705; Sun, 14 Oct 2012 04:40:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1350189649!34360404!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQyMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13742 invoked from network); 14 Oct 2012 04:40:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Oct 2012 04:40:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,583,1344211200"; d="scan'208";a="15149746"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Oct 2012 04:40:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sun, 14 Oct 2012 05:40:47 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1TNG0N-0000wy-Jl;
	Sun, 14 Oct 2012 04:40:47 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TNG0N-0001jO-9X;
	Sun, 14 Oct 2012 05:40:47 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13960-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 14 Oct 2012 05:40:47 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13960: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13960 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13960/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13958
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13958
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13958
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13957

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  e0e1350dfe9b
baseline version:
 xen                  e0e1350dfe9b

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 14 04:41:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Oct 2012 04:41:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNG0S-00028m-Hp; Sun, 14 Oct 2012 04:40:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TNG0Q-00028h-To
	for xen-devel@lists.xensource.com; Sun, 14 Oct 2012 04:40:51 +0000
Received: from [85.158.138.51:40106] by server-8.bemta-3.messagelabs.com id
	D8/1D-10525-2524A705; Sun, 14 Oct 2012 04:40:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1350189649!34360404!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQyMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13742 invoked from network); 14 Oct 2012 04:40:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Oct 2012 04:40:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,583,1344211200"; d="scan'208";a="15149746"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Oct 2012 04:40:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sun, 14 Oct 2012 05:40:47 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1TNG0N-0000wy-Jl;
	Sun, 14 Oct 2012 04:40:47 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TNG0N-0001jO-9X;
	Sun, 14 Oct 2012 05:40:47 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13960-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 14 Oct 2012 05:40:47 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13960: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13960 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13960/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13958
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13958
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13958
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13957

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  e0e1350dfe9b
baseline version:
 xen                  e0e1350dfe9b

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 14 05:17:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Oct 2012 05:17:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNGZ5-0002ZC-M3; Sun, 14 Oct 2012 05:16:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zpengxen@gmail.com>) id 1TNGZ4-0002Z7-78
	for xen-devel@lists.xensource.com; Sun, 14 Oct 2012 05:16:38 +0000
Received: from [85.158.137.99:54410] by server-8.bemta-3.messagelabs.com id
	B0/E5-10525-4BA4A705; Sun, 14 Oct 2012 05:16:36 +0000
X-Env-Sender: zpengxen@gmail.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1350191794!21382051!1
X-Originating-IP: [209.85.223.171]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19203 invoked from network); 14 Oct 2012 05:16:36 -0000
Received: from mail-ie0-f171.google.com (HELO mail-ie0-f171.google.com)
	(209.85.223.171)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Oct 2012 05:16:36 -0000
Received: by mail-ie0-f171.google.com with SMTP id s9so7916152iec.30
	for <xen-devel@lists.xensource.com>;
	Sat, 13 Oct 2012 22:16:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=U4Fp4MJjxYvlW26y1tKOH9Ap5+EZxDxkp12OmCf6hYU=;
	b=UqsY4LG1FAdo7NCrhtNZDm1O54f3vf0nXEO/AC+SnX21GYaiNOCJPtHM+EejfsPssf
	SnbZr3DS1k2I+7h3IHB6yZ2FnuMnUiMAipz9pE/mmjgYuyxqaVZmgTWMMTj3z6Vz6Kni
	rZvmql1oYqScMDR1rNa8v92YfL9jiOjD1p7wp1Uga2oZd7T2b2rynT/VCf9ZiMJu428+
	lwT8mWuvCcpzvN5AKUx999zECH2mJTvpvCSNxiC+XJpKz8P3YXjHG2zZMNfGFnratuWF
	+Fs/SX+/P33cIVk3Wo7WTVH0Oj8Ij4gzXJq6gYGG/3KEkdIh44Cp1tfgswzCpQ+n2wQ5
	yYdQ==
MIME-Version: 1.0
Received: by 10.42.97.74 with SMTP id m10mr6389672icn.42.1350191794229; Sat,
	13 Oct 2012 22:16:34 -0700 (PDT)
Received: by 10.50.128.137 with HTTP; Sat, 13 Oct 2012 22:16:34 -0700 (PDT)
In-Reply-To: <CAFLBxZZfh0eXszeVvZ6WYDuGV6cDcvcgpOByf8FWz9EOvOUorQ@mail.gmail.com>
References: <CAAh7U5MHRnwwK-X==Hh7F2uy94i4yYU3oFFQEesowUtPQGf6Eg@mail.gmail.com>
	<1338987918.32319.84.camel@zakaz.uk.xensource.com>
	<CAAh7U5PYuJJcrAVCzVPLR0vZ1PLpS5mNqsrBmToTsm2KW46_wQ@mail.gmail.com>
	<1339049291.6557.11.camel@dagon.hellion.org.uk>
	<CAAh7U5O2FCeT7Mzp5KNkxqcX5B037YUmqef=TJTrQ9b=JgsHZA@mail.gmail.com>
	<1341325462.21547.20.camel@zakaz.uk.xensource.com>
	<CAFLBxZZfh0eXszeVvZ6WYDuGV6cDcvcgpOByf8FWz9EOvOUorQ@mail.gmail.com>
Date: Sun, 14 Oct 2012 13:16:34 +0800
Message-ID: <CAAh7U5PBASWB6Y6P-Sz3yg2Z1xv-JYAMtFSYGWe=3oov3h32dQ@mail.gmail.com>
From: ZhouPeng <zpengxen@gmail.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Cc: "Xen-Devel \(E-mail\)" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/3] tools:libxl: Add qxl vga interface
 support v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Oct 11, 2012 at 12:50 AM, George Dunlap
<George.Dunlap@eu.citrix.com> wrote:
> On Tue, Jul 3, 2012 at 3:24 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> On Tue, 2012-07-03 at 12:30 +0100, ZhouPeng wrote:
>>> qxl support and docs accordingly
>>> v3
>>> --
>>>
>>> tools:libxl: Add qxl vga interface support for upstream-qemu-xen.
>>>
>>> Usage:
>>>   qxl=1|0
>>>
>>> Signed-off-by: Zhou Peng <ailvpeng25@gmail.com>
>>
>> Thanks. As previously mentioned we think this is 4.3 material. Please
>> could you resubmit (or otherwise remind us) once the 4.3 development
>> branch has opened.
>
> Now that 4.3 development has started, what's the status of this patch?
>  Does it need a refresh?

I will have a test with the latest Xen to response to you.
> Zhou Peng, if you're planning to get this
> working for 4.3, can I add this to my 4.3 feature tracking list?

I think it's ok to add to 4.3 feature tracking list.

Thanks,
- Zhou Peng
>
> Thanks,
>  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 14 05:17:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Oct 2012 05:17:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNGZ5-0002ZC-M3; Sun, 14 Oct 2012 05:16:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zpengxen@gmail.com>) id 1TNGZ4-0002Z7-78
	for xen-devel@lists.xensource.com; Sun, 14 Oct 2012 05:16:38 +0000
Received: from [85.158.137.99:54410] by server-8.bemta-3.messagelabs.com id
	B0/E5-10525-4BA4A705; Sun, 14 Oct 2012 05:16:36 +0000
X-Env-Sender: zpengxen@gmail.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1350191794!21382051!1
X-Originating-IP: [209.85.223.171]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19203 invoked from network); 14 Oct 2012 05:16:36 -0000
Received: from mail-ie0-f171.google.com (HELO mail-ie0-f171.google.com)
	(209.85.223.171)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Oct 2012 05:16:36 -0000
Received: by mail-ie0-f171.google.com with SMTP id s9so7916152iec.30
	for <xen-devel@lists.xensource.com>;
	Sat, 13 Oct 2012 22:16:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=U4Fp4MJjxYvlW26y1tKOH9Ap5+EZxDxkp12OmCf6hYU=;
	b=UqsY4LG1FAdo7NCrhtNZDm1O54f3vf0nXEO/AC+SnX21GYaiNOCJPtHM+EejfsPssf
	SnbZr3DS1k2I+7h3IHB6yZ2FnuMnUiMAipz9pE/mmjgYuyxqaVZmgTWMMTj3z6Vz6Kni
	rZvmql1oYqScMDR1rNa8v92YfL9jiOjD1p7wp1Uga2oZd7T2b2rynT/VCf9ZiMJu428+
	lwT8mWuvCcpzvN5AKUx999zECH2mJTvpvCSNxiC+XJpKz8P3YXjHG2zZMNfGFnratuWF
	+Fs/SX+/P33cIVk3Wo7WTVH0Oj8Ij4gzXJq6gYGG/3KEkdIh44Cp1tfgswzCpQ+n2wQ5
	yYdQ==
MIME-Version: 1.0
Received: by 10.42.97.74 with SMTP id m10mr6389672icn.42.1350191794229; Sat,
	13 Oct 2012 22:16:34 -0700 (PDT)
Received: by 10.50.128.137 with HTTP; Sat, 13 Oct 2012 22:16:34 -0700 (PDT)
In-Reply-To: <CAFLBxZZfh0eXszeVvZ6WYDuGV6cDcvcgpOByf8FWz9EOvOUorQ@mail.gmail.com>
References: <CAAh7U5MHRnwwK-X==Hh7F2uy94i4yYU3oFFQEesowUtPQGf6Eg@mail.gmail.com>
	<1338987918.32319.84.camel@zakaz.uk.xensource.com>
	<CAAh7U5PYuJJcrAVCzVPLR0vZ1PLpS5mNqsrBmToTsm2KW46_wQ@mail.gmail.com>
	<1339049291.6557.11.camel@dagon.hellion.org.uk>
	<CAAh7U5O2FCeT7Mzp5KNkxqcX5B037YUmqef=TJTrQ9b=JgsHZA@mail.gmail.com>
	<1341325462.21547.20.camel@zakaz.uk.xensource.com>
	<CAFLBxZZfh0eXszeVvZ6WYDuGV6cDcvcgpOByf8FWz9EOvOUorQ@mail.gmail.com>
Date: Sun, 14 Oct 2012 13:16:34 +0800
Message-ID: <CAAh7U5PBASWB6Y6P-Sz3yg2Z1xv-JYAMtFSYGWe=3oov3h32dQ@mail.gmail.com>
From: ZhouPeng <zpengxen@gmail.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Cc: "Xen-Devel \(E-mail\)" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/3] tools:libxl: Add qxl vga interface
 support v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Oct 11, 2012 at 12:50 AM, George Dunlap
<George.Dunlap@eu.citrix.com> wrote:
> On Tue, Jul 3, 2012 at 3:24 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> On Tue, 2012-07-03 at 12:30 +0100, ZhouPeng wrote:
>>> qxl support and docs accordingly
>>> v3
>>> --
>>>
>>> tools:libxl: Add qxl vga interface support for upstream-qemu-xen.
>>>
>>> Usage:
>>>   qxl=1|0
>>>
>>> Signed-off-by: Zhou Peng <ailvpeng25@gmail.com>
>>
>> Thanks. As previously mentioned we think this is 4.3 material. Please
>> could you resubmit (or otherwise remind us) once the 4.3 development
>> branch has opened.
>
> Now that 4.3 development has started, what's the status of this patch?
>  Does it need a refresh?

I will have a test with the latest Xen to response to you.
> Zhou Peng, if you're planning to get this
> working for 4.3, can I add this to my 4.3 feature tracking list?

I think it's ok to add to 4.3 feature tracking list.

Thanks,
- Zhou Peng
>
> Thanks,
>  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 14 08:21:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Oct 2012 08:21:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNJRI-0003oD-M2; Sun, 14 Oct 2012 08:20:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <m.a.young@durham.ac.uk>) id 1TNJRH-0003o5-1v
	for xen-devel@lists.xensource.com; Sun, 14 Oct 2012 08:20:47 +0000
Received: from [85.158.138.51:47159] by server-7.bemta-3.messagelabs.com id
	E4/CF-06991-ED57A705; Sun, 14 Oct 2012 08:20:46 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-3.tower-174.messagelabs.com!1350202844!26208278!1
X-Originating-IP: [129.234.248.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMiA9PiA4NzA5Mg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19330 invoked from network); 14 Oct 2012 08:20:44 -0000
Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Oct 2012 08:20:44 -0000
Received: from smtphost3.dur.ac.uk (smtphost3.dur.ac.uk [129.234.252.3])
	by hermes2.dur.ac.uk (8.13.8/8.13.8) with ESMTP id q9E8K8PI011239;
	Sun, 14 Oct 2012 09:20:12 +0100
Received: from procyon.dur.ac.uk (procyon.dur.ac.uk [129.234.250.129])
	by smtphost3.dur.ac.uk (8.14.4/8.14.4) with ESMTP id q9E8K5BM014916
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 14 Oct 2012 09:20:05 +0100
Received: from procyon.dur.ac.uk (localhost [127.0.0.1])
	by procyon.dur.ac.uk (8.14.3/8.11.1) with ESMTP id q9E8K52o030522;
	Sun, 14 Oct 2012 09:20:05 +0100
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	q9E8K4Wl030452; Sun, 14 Oct 2012 09:20:05 +0100
Date: Sun, 14 Oct 2012 09:20:04 +0100 (BST)
From: M A Young <m.a.young@durham.ac.uk>
To: Steven Haigh <netwiz@crc.id.au>
In-Reply-To: <507A04D9.8030408@crc.id.au>
Message-ID: <alpine.DEB.2.00.1210140913001.16924@procyon.dur.ac.uk>
References: <507A04D9.8030408@crc.id.au>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: q9E8K8PI011239
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] xend running on EL5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On Sun, 14 Oct 2012, Steven Haigh wrote:

> Hi guys,
>
> I've been trying to get my Xen 4.2 RPMs to build on both EL5 and EL6 systems. 
> I'm just about there but I've noticed one issue which I'm not 100% sure of 
> the best way to resolve.
>
> /usr/sbin/xend is a simple python launcher that runs fine as is on EL6, but 
> in EL5 it comes up with:
>
> # service xend start
> Starting xend daemon: Unknown option: -s
> Unknown option: -s
> usage: /usr/bin/python [option] ... [-c cmd | -m mod | file | -] [arg] ...
> Try `python -h' for more information.
>
> The standard hashbang line for xend is:
> #!/usr/bin/python -Es
>
> EL5 seems to run python 2.4.3 which doesn't have the -s option.

That isn't a standard xen line, it is a hack I put into the Fedora code to 
try to get xend to work better with selinux in recent Fedora versions (the 
switch to systemd might also have been a factor). You can probably safely 
throw away the xend.selinux.fixes.patch (or that part of it) for EL5 and 
EL6 as I think the selinux problems came later.

 	Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 14 08:21:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Oct 2012 08:21:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNJRI-0003oD-M2; Sun, 14 Oct 2012 08:20:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <m.a.young@durham.ac.uk>) id 1TNJRH-0003o5-1v
	for xen-devel@lists.xensource.com; Sun, 14 Oct 2012 08:20:47 +0000
Received: from [85.158.138.51:47159] by server-7.bemta-3.messagelabs.com id
	E4/CF-06991-ED57A705; Sun, 14 Oct 2012 08:20:46 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-3.tower-174.messagelabs.com!1350202844!26208278!1
X-Originating-IP: [129.234.248.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMiA9PiA4NzA5Mg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19330 invoked from network); 14 Oct 2012 08:20:44 -0000
Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Oct 2012 08:20:44 -0000
Received: from smtphost3.dur.ac.uk (smtphost3.dur.ac.uk [129.234.252.3])
	by hermes2.dur.ac.uk (8.13.8/8.13.8) with ESMTP id q9E8K8PI011239;
	Sun, 14 Oct 2012 09:20:12 +0100
Received: from procyon.dur.ac.uk (procyon.dur.ac.uk [129.234.250.129])
	by smtphost3.dur.ac.uk (8.14.4/8.14.4) with ESMTP id q9E8K5BM014916
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 14 Oct 2012 09:20:05 +0100
Received: from procyon.dur.ac.uk (localhost [127.0.0.1])
	by procyon.dur.ac.uk (8.14.3/8.11.1) with ESMTP id q9E8K52o030522;
	Sun, 14 Oct 2012 09:20:05 +0100
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	q9E8K4Wl030452; Sun, 14 Oct 2012 09:20:05 +0100
Date: Sun, 14 Oct 2012 09:20:04 +0100 (BST)
From: M A Young <m.a.young@durham.ac.uk>
To: Steven Haigh <netwiz@crc.id.au>
In-Reply-To: <507A04D9.8030408@crc.id.au>
Message-ID: <alpine.DEB.2.00.1210140913001.16924@procyon.dur.ac.uk>
References: <507A04D9.8030408@crc.id.au>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: q9E8K8PI011239
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] xend running on EL5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On Sun, 14 Oct 2012, Steven Haigh wrote:

> Hi guys,
>
> I've been trying to get my Xen 4.2 RPMs to build on both EL5 and EL6 systems. 
> I'm just about there but I've noticed one issue which I'm not 100% sure of 
> the best way to resolve.
>
> /usr/sbin/xend is a simple python launcher that runs fine as is on EL6, but 
> in EL5 it comes up with:
>
> # service xend start
> Starting xend daemon: Unknown option: -s
> Unknown option: -s
> usage: /usr/bin/python [option] ... [-c cmd | -m mod | file | -] [arg] ...
> Try `python -h' for more information.
>
> The standard hashbang line for xend is:
> #!/usr/bin/python -Es
>
> EL5 seems to run python 2.4.3 which doesn't have the -s option.

That isn't a standard xen line, it is a hack I put into the Fedora code to 
try to get xend to work better with selinux in recent Fedora versions (the 
switch to systemd might also have been a factor). You can probably safely 
throw away the xend.selinux.fixes.patch (or that part of it) for EL5 and 
EL6 as I think the selinux problems came later.

 	Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 14 10:09:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Oct 2012 10:09:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNL8D-0004Fq-7x; Sun, 14 Oct 2012 10:09:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ferdinand@outlook.com>) id 1TNL8B-0004Fl-SH
	for xen-devel@lists.xen.org; Sun, 14 Oct 2012 10:09:12 +0000
Received: from [85.158.143.35:33173] by server-3.bemta-4.messagelabs.com id
	9B/53-10075-74F8A705; Sun, 14 Oct 2012 10:09:11 +0000
X-Env-Sender: ferdinand@outlook.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1350209350!13898856!1
X-Originating-IP: [65.55.111.162]
X-SpamReason: No, hits=0.1 required=7.0 tests=FORGED_HOTMAIL_RCVD,
	ML_RADAR_SPEW_LINKS_12,MSGID_FROM_MTA_HEADER,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19721 invoked from network); 14 Oct 2012 10:09:10 -0000
Received: from blu0-omc4-s23.blu0.hotmail.com (HELO
	blu0-omc4-s23.blu0.hotmail.com) (65.55.111.162)
	by server-16.tower-21.messagelabs.com with SMTP;
	14 Oct 2012 10:09:10 -0000
Received: from BLU0-SMTP466 ([65.55.111.136]) by
	blu0-omc4-s23.blu0.hotmail.com with Microsoft
	SMTPSVC(6.0.3790.4675); Sun, 14 Oct 2012 03:09:09 -0700
X-Originating-IP: [149.172.106.110]
X-EIP: [8jhTTXETJzIEfHQSZ1D4lzt08Woz9uqK3SB2MH0hu1A=]
X-Originating-Email: [ferdinand@outlook.com]
Message-ID: <BLU0-SMTP46659547706BEDEFF6CAD76A5720@phx.gbl>
Received: from [192.168.178.21] ([149.172.106.110]) by
	BLU0-SMTP466.blu0.hotmail.com over TLS secured channel with
	Microsoft SMTPSVC(6.0.3790.4675); Sun, 14 Oct 2012 03:09:08 -0700
Date: Sun, 14 Oct 2012 12:09:14 +0200
From: =?ISO-8859-1?Q?Ferdinand_N=F6lscher?= <ferdinand@outlook.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.7) Gecko/20120922 Icedove/10.0.7
MIME-Version: 1.0
To: xen-devel@lists.xen.org
Content-Type: multipart/mixed; boundary="------------090602030209000605020505"
X-OriginalArrivalTime: 14 Oct 2012 10:09:08.0997 (UTC)
	FILETIME=[F3701B50:01CDA9F3]
Subject: [Xen-devel] Xen primary VGA pass through problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------090602030209000605020505
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

Hi!

Recently, I tried setting up VGA pass through with my machine. The set 
up is as follows:
I have two AMD vga adapters - I want to pass through the second one.

I compiled xen 4.2 from source and set everything up.
Attached to this message, you can find my windows 7 domU configuration file.

Whenever I want to pass through the device, I use "xl pci-assignable-add 
BDF" to unbind the adapter, before I create the domU. Pciback is loaded 
as module and is not compiled statically in the kernel.

Unless I do not specify "gfx_passthru = 1" in my configuration file, 
this works fine. The vga adapter gets detected and I can use it as 
secondary vga, with very limited performance.
If I do set "gfx_passthru = 1" the domU doesnt boot at all. It just 
switches state from "r" (for running) to "-----" (which is nothing, i 
guess?) every few seconds. I can't find anything in the logs indicating 
an error.

Any ideas on how to fix that?

kind regards,
Ferdinand

--------------090602030209000605020505
Content-Type: text/plain; name="win7-vga.cfg"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="win7-vga.cfg"

kernel = "/usr/lib/xen/boot/hvmloader"
builder='hvm'
memory = 3096
vcpus=6

shadow_memory = 8
name = "xenwin7"

vif = [ 'ip=10.0.0.2 bridge=xenbr0' ]
dhcp = "off"

acpi = 1
apic = 1
disk = [ 'file:/home/user/vms/windows7/xenwin7.img,hda,w' ]

device_model = '/usr/lib/xen/bin/qemu-dm'


boot="cd"
sdl=0
vnc=0
# vncpasswd='1234'
# vncdisplay = 1

serial='pty'
usbdevice='tablet'

# vga pass-through stuff
gfx_passthru=0
pci = [ '02:00.0', '02:00.1' ]
pci_msitranslate = 1
pci_power_mgmt = 1

acpi_s3 = 1
acpi_s4 = 1

--------------090602030209000605020505
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------090602030209000605020505--


From xen-devel-bounces@lists.xen.org Sun Oct 14 10:09:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Oct 2012 10:09:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNL8D-0004Fq-7x; Sun, 14 Oct 2012 10:09:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ferdinand@outlook.com>) id 1TNL8B-0004Fl-SH
	for xen-devel@lists.xen.org; Sun, 14 Oct 2012 10:09:12 +0000
Received: from [85.158.143.35:33173] by server-3.bemta-4.messagelabs.com id
	9B/53-10075-74F8A705; Sun, 14 Oct 2012 10:09:11 +0000
X-Env-Sender: ferdinand@outlook.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1350209350!13898856!1
X-Originating-IP: [65.55.111.162]
X-SpamReason: No, hits=0.1 required=7.0 tests=FORGED_HOTMAIL_RCVD,
	ML_RADAR_SPEW_LINKS_12,MSGID_FROM_MTA_HEADER,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19721 invoked from network); 14 Oct 2012 10:09:10 -0000
Received: from blu0-omc4-s23.blu0.hotmail.com (HELO
	blu0-omc4-s23.blu0.hotmail.com) (65.55.111.162)
	by server-16.tower-21.messagelabs.com with SMTP;
	14 Oct 2012 10:09:10 -0000
Received: from BLU0-SMTP466 ([65.55.111.136]) by
	blu0-omc4-s23.blu0.hotmail.com with Microsoft
	SMTPSVC(6.0.3790.4675); Sun, 14 Oct 2012 03:09:09 -0700
X-Originating-IP: [149.172.106.110]
X-EIP: [8jhTTXETJzIEfHQSZ1D4lzt08Woz9uqK3SB2MH0hu1A=]
X-Originating-Email: [ferdinand@outlook.com]
Message-ID: <BLU0-SMTP46659547706BEDEFF6CAD76A5720@phx.gbl>
Received: from [192.168.178.21] ([149.172.106.110]) by
	BLU0-SMTP466.blu0.hotmail.com over TLS secured channel with
	Microsoft SMTPSVC(6.0.3790.4675); Sun, 14 Oct 2012 03:09:08 -0700
Date: Sun, 14 Oct 2012 12:09:14 +0200
From: =?ISO-8859-1?Q?Ferdinand_N=F6lscher?= <ferdinand@outlook.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.7) Gecko/20120922 Icedove/10.0.7
MIME-Version: 1.0
To: xen-devel@lists.xen.org
Content-Type: multipart/mixed; boundary="------------090602030209000605020505"
X-OriginalArrivalTime: 14 Oct 2012 10:09:08.0997 (UTC)
	FILETIME=[F3701B50:01CDA9F3]
Subject: [Xen-devel] Xen primary VGA pass through problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------090602030209000605020505
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

Hi!

Recently, I tried setting up VGA pass through with my machine. The set 
up is as follows:
I have two AMD vga adapters - I want to pass through the second one.

I compiled xen 4.2 from source and set everything up.
Attached to this message, you can find my windows 7 domU configuration file.

Whenever I want to pass through the device, I use "xl pci-assignable-add 
BDF" to unbind the adapter, before I create the domU. Pciback is loaded 
as module and is not compiled statically in the kernel.

Unless I do not specify "gfx_passthru = 1" in my configuration file, 
this works fine. The vga adapter gets detected and I can use it as 
secondary vga, with very limited performance.
If I do set "gfx_passthru = 1" the domU doesnt boot at all. It just 
switches state from "r" (for running) to "-----" (which is nothing, i 
guess?) every few seconds. I can't find anything in the logs indicating 
an error.

Any ideas on how to fix that?

kind regards,
Ferdinand

--------------090602030209000605020505
Content-Type: text/plain; name="win7-vga.cfg"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="win7-vga.cfg"

kernel = "/usr/lib/xen/boot/hvmloader"
builder='hvm'
memory = 3096
vcpus=6

shadow_memory = 8
name = "xenwin7"

vif = [ 'ip=10.0.0.2 bridge=xenbr0' ]
dhcp = "off"

acpi = 1
apic = 1
disk = [ 'file:/home/user/vms/windows7/xenwin7.img,hda,w' ]

device_model = '/usr/lib/xen/bin/qemu-dm'


boot="cd"
sdl=0
vnc=0
# vncpasswd='1234'
# vncdisplay = 1

serial='pty'
usbdevice='tablet'

# vga pass-through stuff
gfx_passthru=0
pci = [ '02:00.0', '02:00.1' ]
pci_msitranslate = 1
pci_power_mgmt = 1

acpi_s3 = 1
acpi_s4 = 1

--------------090602030209000605020505
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------090602030209000605020505--


From xen-devel-bounces@lists.xen.org Sun Oct 14 10:45:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Oct 2012 10:45:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNLga-0004SY-AA; Sun, 14 Oct 2012 10:44:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1TNLgY-0004ST-P7
	for xen-devel@lists.xensource.com; Sun, 14 Oct 2012 10:44:42 +0000
Received: from [85.158.139.211:23680] by server-7.bemta-5.messagelabs.com id
	1D/CF-20187-A979A705; Sun, 14 Oct 2012 10:44:42 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-15.tower-206.messagelabs.com!1350211481!22292689!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MjgwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4363 invoked from network); 14 Oct 2012 10:44:41 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Oct 2012 10:44:41 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 31A0C1F2C;
	Sun, 14 Oct 2012 13:44:39 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id A42EF20058; Sun, 14 Oct 2012 13:44:39 +0300 (EEST)
Date: Sun, 14 Oct 2012 13:44:39 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: M A Young <m.a.young@durham.ac.uk>
Message-ID: <20121014104439.GB8912@reaktio.net>
References: <507A04D9.8030408@crc.id.au>
	<alpine.DEB.2.00.1210140913001.16924@procyon.dur.ac.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1210140913001.16924@procyon.dur.ac.uk>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xensource.com, Steven Haigh <netwiz@crc.id.au>
Subject: Re: [Xen-devel] xend running on EL5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Oct 14, 2012 at 09:20:04AM +0100, M A Young wrote:
> 
> 
> On Sun, 14 Oct 2012, Steven Haigh wrote:
> 
> >Hi guys,
> >
> >I've been trying to get my Xen 4.2 RPMs to build on both EL5 and
> >EL6 systems. I'm just about there but I've noticed one issue which
> >I'm not 100% sure of the best way to resolve.
> >
> >/usr/sbin/xend is a simple python launcher that runs fine as is on
> >EL6, but in EL5 it comes up with:
> >
> ># service xend start
> >Starting xend daemon: Unknown option: -s
> >Unknown option: -s
> >usage: /usr/bin/python [option] ... [-c cmd | -m mod | file | -] [arg] ...
> >Try `python -h' for more information.
> >
> >The standard hashbang line for xend is:
> >#!/usr/bin/python -Es
> >
> >EL5 seems to run python 2.4.3 which doesn't have the -s option.
> 
> That isn't a standard xen line, it is a hack I put into the Fedora
> code to try to get xend to work better with selinux in recent Fedora
> versions (the switch to systemd might also have been a factor). You
> can probably safely throw away the xend.selinux.fixes.patch (or that
> part of it) for EL5 and EL6 as I think the selinux problems came
> later.
> 

For rhel5 you might also want this patch:

"libfsimage: add ext4 support for CentOS 5.x":
http://xenbits.xen.org/hg/xen-unstable.hg/rev/98e1ba6a672a

which adds pygrub ext4 support on el5 using e4fsprogs.

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 14 10:45:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Oct 2012 10:45:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNLga-0004SY-AA; Sun, 14 Oct 2012 10:44:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1TNLgY-0004ST-P7
	for xen-devel@lists.xensource.com; Sun, 14 Oct 2012 10:44:42 +0000
Received: from [85.158.139.211:23680] by server-7.bemta-5.messagelabs.com id
	1D/CF-20187-A979A705; Sun, 14 Oct 2012 10:44:42 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-15.tower-206.messagelabs.com!1350211481!22292689!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MjgwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4363 invoked from network); 14 Oct 2012 10:44:41 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Oct 2012 10:44:41 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 31A0C1F2C;
	Sun, 14 Oct 2012 13:44:39 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id A42EF20058; Sun, 14 Oct 2012 13:44:39 +0300 (EEST)
Date: Sun, 14 Oct 2012 13:44:39 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: M A Young <m.a.young@durham.ac.uk>
Message-ID: <20121014104439.GB8912@reaktio.net>
References: <507A04D9.8030408@crc.id.au>
	<alpine.DEB.2.00.1210140913001.16924@procyon.dur.ac.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1210140913001.16924@procyon.dur.ac.uk>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xensource.com, Steven Haigh <netwiz@crc.id.au>
Subject: Re: [Xen-devel] xend running on EL5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Oct 14, 2012 at 09:20:04AM +0100, M A Young wrote:
> 
> 
> On Sun, 14 Oct 2012, Steven Haigh wrote:
> 
> >Hi guys,
> >
> >I've been trying to get my Xen 4.2 RPMs to build on both EL5 and
> >EL6 systems. I'm just about there but I've noticed one issue which
> >I'm not 100% sure of the best way to resolve.
> >
> >/usr/sbin/xend is a simple python launcher that runs fine as is on
> >EL6, but in EL5 it comes up with:
> >
> ># service xend start
> >Starting xend daemon: Unknown option: -s
> >Unknown option: -s
> >usage: /usr/bin/python [option] ... [-c cmd | -m mod | file | -] [arg] ...
> >Try `python -h' for more information.
> >
> >The standard hashbang line for xend is:
> >#!/usr/bin/python -Es
> >
> >EL5 seems to run python 2.4.3 which doesn't have the -s option.
> 
> That isn't a standard xen line, it is a hack I put into the Fedora
> code to try to get xend to work better with selinux in recent Fedora
> versions (the switch to systemd might also have been a factor). You
> can probably safely throw away the xend.selinux.fixes.patch (or that
> part of it) for EL5 and EL6 as I think the selinux problems came
> later.
> 

For rhel5 you might also want this patch:

"libfsimage: add ext4 support for CentOS 5.x":
http://xenbits.xen.org/hg/xen-unstable.hg/rev/98e1ba6a672a

which adds pygrub ext4 support on el5 using e4fsprogs.

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 14 11:03:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Oct 2012 11:03:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNLyV-0004ec-0T; Sun, 14 Oct 2012 11:03:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1TNLyT-0004eX-IY
	for Xen-devel@lists.xen.org; Sun, 14 Oct 2012 11:03:13 +0000
Received: from [85.158.138.51:14072] by server-6.bemta-3.messagelabs.com id
	91/A2-32375-0FB9A705; Sun, 14 Oct 2012 11:03:12 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-15.tower-174.messagelabs.com!1350212591!32512621!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MjgwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15535 invoked from network); 14 Oct 2012 11:03:12 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Oct 2012 11:03:12 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 7D8341413;
	Sun, 14 Oct 2012 14:03:11 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 4530620058; Sun, 14 Oct 2012 14:03:11 +0300 (EEST)
Date: Sun, 14 Oct 2012 14:03:11 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20121014110311.GD8912@reaktio.net>
References: <CAN=sCCEuPqhapvBR2eSTvALQeKbwshmT5=MvSiX3FoMW+vg_aA@mail.gmail.com>
	<1349263669.650.131.camel@zakaz.uk.xensource.com>
	<CAN=sCCGSvu9_xLXnMRhKY6fr1WD+ittsjpKRF6fVFnwtgB9niQ@mail.gmail.com>
	<1349266207.650.137.camel@zakaz.uk.xensource.com>
	<CAN=sCCEtV1PS-a7MtSjsX=XKRqQCoabvNUY-F1xD-sjMmrJE+A@mail.gmail.com>
	<CAN=sCCFcsZUZYKiOVqOF=DzM8VpSEEOSUfmjLh2+DKOrkG+b2g@mail.gmail.com>
	<CAN=sCCGWU4Wpg9QfFaoPLUBmo_rXTf4h=F4g+ES0CHFhGU=0KQ@mail.gmail.com>
	<1349278604.650.162.camel@zakaz.uk.xensource.com>
	<CAN=sCCEO63JgWCUbosP5+exL4aU=yjaM_VPOxbjh6=C6r8CAhg@mail.gmail.com>
	<1349282150.650.181.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1349282150.650.181.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Valtteri Kiviniemi <kiviniemi.valtteri@gmail.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0, xl toolstack cant launch older domUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 03, 2012 at 05:35:50PM +0100, Ian Campbell wrote:
> On Wed, 2012-10-03 at 16:39 +0100, Valtteri Kiviniemi wrote:
> > Hypervisor is 64bit, dom0 is 64bit but the domU is 32bit. If this is
> > what you meant?
> 
> It is.
> 
> I think the underlying bug here is that your 32bit domU kernel predates
> the ability to run 32 bit guests on 64 bit hypervisors. Guest kernels
> are supposed to write that protocol node themselves.
> 
> It appears that xend includes some sort of workaround for this which xl
> does not.
> 

So from a user's point-of-view this is a regression in xl..
similar workaround probably should be added in xl to be able to run old guests? 

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 14 11:03:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Oct 2012 11:03:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNLyV-0004ec-0T; Sun, 14 Oct 2012 11:03:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1TNLyT-0004eX-IY
	for Xen-devel@lists.xen.org; Sun, 14 Oct 2012 11:03:13 +0000
Received: from [85.158.138.51:14072] by server-6.bemta-3.messagelabs.com id
	91/A2-32375-0FB9A705; Sun, 14 Oct 2012 11:03:12 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-15.tower-174.messagelabs.com!1350212591!32512621!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MjgwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15535 invoked from network); 14 Oct 2012 11:03:12 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Oct 2012 11:03:12 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 7D8341413;
	Sun, 14 Oct 2012 14:03:11 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 4530620058; Sun, 14 Oct 2012 14:03:11 +0300 (EEST)
Date: Sun, 14 Oct 2012 14:03:11 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20121014110311.GD8912@reaktio.net>
References: <CAN=sCCEuPqhapvBR2eSTvALQeKbwshmT5=MvSiX3FoMW+vg_aA@mail.gmail.com>
	<1349263669.650.131.camel@zakaz.uk.xensource.com>
	<CAN=sCCGSvu9_xLXnMRhKY6fr1WD+ittsjpKRF6fVFnwtgB9niQ@mail.gmail.com>
	<1349266207.650.137.camel@zakaz.uk.xensource.com>
	<CAN=sCCEtV1PS-a7MtSjsX=XKRqQCoabvNUY-F1xD-sjMmrJE+A@mail.gmail.com>
	<CAN=sCCFcsZUZYKiOVqOF=DzM8VpSEEOSUfmjLh2+DKOrkG+b2g@mail.gmail.com>
	<CAN=sCCGWU4Wpg9QfFaoPLUBmo_rXTf4h=F4g+ES0CHFhGU=0KQ@mail.gmail.com>
	<1349278604.650.162.camel@zakaz.uk.xensource.com>
	<CAN=sCCEO63JgWCUbosP5+exL4aU=yjaM_VPOxbjh6=C6r8CAhg@mail.gmail.com>
	<1349282150.650.181.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1349282150.650.181.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Valtteri Kiviniemi <kiviniemi.valtteri@gmail.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0, xl toolstack cant launch older domUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 03, 2012 at 05:35:50PM +0100, Ian Campbell wrote:
> On Wed, 2012-10-03 at 16:39 +0100, Valtteri Kiviniemi wrote:
> > Hypervisor is 64bit, dom0 is 64bit but the domU is 32bit. If this is
> > what you meant?
> 
> It is.
> 
> I think the underlying bug here is that your 32bit domU kernel predates
> the ability to run 32 bit guests on 64 bit hypervisors. Guest kernels
> are supposed to write that protocol node themselves.
> 
> It appears that xend includes some sort of workaround for this which xl
> does not.
> 

So from a user's point-of-view this is a regression in xl..
similar workaround probably should be added in xl to be able to run old guests? 

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 14 11:11:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Oct 2012 11:11:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNM5l-0004ni-U8; Sun, 14 Oct 2012 11:10:45 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1TNM5k-0004nd-Hp
	for xen-devel@lists.xen.org; Sun, 14 Oct 2012 11:10:44 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-6.tower-27.messagelabs.com!1350213036!3448747!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MjgwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15928 invoked from network); 14 Oct 2012 11:10:37 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Oct 2012 11:10:37 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id BB64028C9;
	Sun, 14 Oct 2012 14:10:35 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 4696B20058; Sun, 14 Oct 2012 14:10:35 +0300 (EEST)
Date: Sun, 14 Oct 2012 14:10:35 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20121014111035.GE8912@reaktio.net>
References: <20120905030239.GJ8912@reaktio.net>
	<1346846602-1109-1-git-send-email-roger.pau@citrix.com>
	<1347613534.24226.167.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347613534.24226.167.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel <xen-devel@lists.xen.org>, Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libfsimage: add ext4 support for CentOS 5.x
 / Xen 4.2.1 backport
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 14, 2012 at 10:05:34AM +0100, Ian Campbell wrote:
> On Wed, 2012-09-05 at 13:03 +0100, Roger Pau Monne wrote:
> > CentOS 5.x forked e2fs ext4 support into a different package called
> > e4fs, and so headers and library names changed from ext2fs to ext4fs.
> > Check if ext4fs/ext2fs.h and -lext4fs work, and use that instead of
> > ext2fs to build libfsimage. This patch assumes that if the ext4fs
> > library is present it should always be used instead of ext2fs.
> > 
> > This patch includes a rework of the ext2fs check, a new ext4fs check
> > and a minor modification in libfsimage to use the correct library.
> > 
> > Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
> > ---
> > Please re-run autogen.sh after applying
> 
> Done & acked + applied. Thanks.
>

Hello,

Now that this patch has been in xen-unstable for a while
I'd like to request Xen 4.2.1 backport..

Thanks,

-- Pasi



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 14 11:11:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Oct 2012 11:11:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNM5l-0004ni-U8; Sun, 14 Oct 2012 11:10:45 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1TNM5k-0004nd-Hp
	for xen-devel@lists.xen.org; Sun, 14 Oct 2012 11:10:44 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-6.tower-27.messagelabs.com!1350213036!3448747!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MjgwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15928 invoked from network); 14 Oct 2012 11:10:37 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Oct 2012 11:10:37 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id BB64028C9;
	Sun, 14 Oct 2012 14:10:35 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 4696B20058; Sun, 14 Oct 2012 14:10:35 +0300 (EEST)
Date: Sun, 14 Oct 2012 14:10:35 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20121014111035.GE8912@reaktio.net>
References: <20120905030239.GJ8912@reaktio.net>
	<1346846602-1109-1-git-send-email-roger.pau@citrix.com>
	<1347613534.24226.167.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347613534.24226.167.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel <xen-devel@lists.xen.org>, Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libfsimage: add ext4 support for CentOS 5.x
 / Xen 4.2.1 backport
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 14, 2012 at 10:05:34AM +0100, Ian Campbell wrote:
> On Wed, 2012-09-05 at 13:03 +0100, Roger Pau Monne wrote:
> > CentOS 5.x forked e2fs ext4 support into a different package called
> > e4fs, and so headers and library names changed from ext2fs to ext4fs.
> > Check if ext4fs/ext2fs.h and -lext4fs work, and use that instead of
> > ext2fs to build libfsimage. This patch assumes that if the ext4fs
> > library is present it should always be used instead of ext2fs.
> > 
> > This patch includes a rework of the ext2fs check, a new ext4fs check
> > and a minor modification in libfsimage to use the correct library.
> > 
> > Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
> > ---
> > Please re-run autogen.sh after applying
> 
> Done & acked + applied. Thanks.
>

Hello,

Now that this patch has been in xen-unstable for a while
I'd like to request Xen 4.2.1 backport..

Thanks,

-- Pasi



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 14 11:26:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Oct 2012 11:26:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNMKc-0004xn-Ca; Sun, 14 Oct 2012 11:26:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <netwiz@crc.id.au>) id 1TNMKa-0004xi-KD
	for xen-devel@lists.xen.org; Sun, 14 Oct 2012 11:26:05 +0000
Received: from [85.158.138.51:55342] by server-7.bemta-3.messagelabs.com id
	70/48-06991-B41AA705; Sun, 14 Oct 2012 11:26:03 +0000
X-Env-Sender: netwiz@crc.id.au
X-Msg-Ref: server-5.tower-174.messagelabs.com!1350213953!34381501!1
X-Originating-IP: [203.56.246.92]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_8,
	spamassassin: ,
	async_handler: YXN5bmNfZGVsYXk6IDcwNDQ3NzUgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23163 invoked from network); 14 Oct 2012 11:25:54 -0000
Received: from mail.crc.id.au (HELO mail.crc.id.au) (203.56.246.92)
	by server-5.tower-174.messagelabs.com with SMTP;
	14 Oct 2012 11:25:54 -0000
Received: from [IPv6:2002:cb38:f71b:2:e5cd:d7ed:95cf:5689] (unknown
	[IPv6:2002:cb38:f71b:2:e5cd:d7ed:95cf:5689])
	by mail.crc.id.au (Postfix) with ESMTPSA id F36F8D5
	for <xen-devel@lists.xen.org>; Sun, 14 Oct 2012 22:25:49 +1100 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crc.id.au; s=default;
	t=1350213950; bh=LvjytYOqRcxhoH4kupW+XqWoBPwELJ4uBPOVuECi264=;
	h=Date:From:To:Subject:References:In-Reply-To;
	b=Oxw25Ed8sT63y1MuoKj0J9L6610L+eXBE4cHOM5oB78QnVbqB+0xjCGncIPPvqd9Z
	UyZ1s3uT0nRolGRNG5fEQE0VxvIlXXbv9hgmkoW+OTuQHSv9jK3sy+LQ3qy9AdB9vS
	+1ZlpZvJGJhIbMR0FcXWC7Zp71iqxMlz9fLBUW7E=
Message-ID: <507AA14E.3060706@crc.id.au>
Date: Sun, 14 Oct 2012 22:26:06 +1100
From: Steven Haigh <netwiz@crc.id.au>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <20120905030239.GJ8912@reaktio.net>
	<1346846602-1109-1-git-send-email-roger.pau@citrix.com>
	<1347613534.24226.167.camel@zakaz.uk.xensource.com>
	<20121014111035.GE8912@reaktio.net>
In-Reply-To: <20121014111035.GE8912@reaktio.net>
Subject: Re: [Xen-devel] [PATCH] libfsimage: add ext4 support for CentOS 5.x
 / Xen 4.2.1 backport
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7883047813441151202=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============7883047813441151202==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020908050806080805070700"

This is a cryptographically signed message in MIME format.

--------------ms020908050806080805070700
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

On 14/10/2012 10:10 PM, Pasi K=E4rkk=E4inen wrote:
> On Fri, Sep 14, 2012 at 10:05:34AM +0100, Ian Campbell wrote:
>> On Wed, 2012-09-05 at 13:03 +0100, Roger Pau Monne wrote:
>>> CentOS 5.x forked e2fs ext4 support into a different package called
>>> e4fs, and so headers and library names changed from ext2fs to ext4fs.=

>>> Check if ext4fs/ext2fs.h and -lext4fs work, and use that instead of
>>> ext2fs to build libfsimage. This patch assumes that if the ext4fs
>>> library is present it should always be used instead of ext2fs.
>>>
>>> This patch includes a rework of the ext2fs check, a new ext4fs check
>>> and a minor modification in libfsimage to use the correct library.
>>>
>>> Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
>>> ---
>>> Please re-run autogen.sh after applying
>>
>> Done & acked + applied. Thanks.
>>
>
> Hello,
>
> Now that this patch has been in xen-unstable for a while
> I'd like to request Xen 4.2.1 backport..

I agree. I've been slamming my head against a wall trying to package=20
4.2.0 for CentOS 5 for a few days now. Its kinda working, but not=20
really. Having some fixes like this may end up making a few headaches=20
I'm having go away...

--=20
Steven Haigh

Email: netwiz@crc.id.au
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299


--------------ms020908050806080805070700
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOSjCC
BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr
lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM
zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6
qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD
kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95
m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD
CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy
6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI
zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf
KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR
z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9
sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie
uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t
w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ
G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t
5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIIDjCCBvagAwIBAgIDA7ikMA0GCSqGSIb3DQEB
BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g
Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTIwMjEzMTMzODE0
WhcNMTMwMjEzMTc1NjUzWjBXMRkwFwYDVQQNExB3bjVlU1RNM2RWOUIwMEk5MRkwFwYDVQQD
DBBuZXR3aXpAY3JjLmlkLmF1MR8wHQYJKoZIhvcNAQkBFhBuZXR3aXpAY3JjLmlkLmF1MIIC
IjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAzTaLiL78pm4Hqp7Pou4C60jt2wdvDiPt
Sq6hspKk6oaST7BFeDOfoed3mvzytkjNr3C1gds3zsHulAMzRjuX2M1zPkfaj5QFkmlqQcxr
+tnaf8QFpn9PrUcjpbYDYPxdcGR+SeClKzmjdxicHuYDrD8YXnbk+k8dWDaCuv5sKRQHJmIR
maqUIGoVML+/kUR+sqkMpnbhOsL+E84Hg4fxLzpV3Tjf9bZbKgaspvg+BeJJCYKThBxMnZJI
cQ9JzDGL4rO2BEuTXI9Ofl0+AAttBEpZeqc2rePCfA9NivKTCZ0qaFKmvM5SN7TiZUqv80rD
ewTp+OLXNZEd5aa5jEDPNlznkcX0WfuKCmtyIEzT7PgHl1tOWTx7nw6FVWcB8qjC6xlyaL6W
1oS7Om3b2ka+9vSiz7DrPZzUDZuS91Fr2zIIMrrRzhN8q/JdQf8lGTydpmoRUB0z+BAcH8V/
nOcMMDogqV6/dCfywi7zFQK4AsiPSpyBAZyO53J4uPgoIzSpFj54f83KRIobHCWDU1BaU2+6
CfEoAD3iMId1tcFWTXikEThL+3oHQullq9EbPR4f3ToAU7aTZYWG4KNKrmG93KAfyCUFb+bf
mt3hf1BprKIUJnpOxdZHi0KwLXVwURiB4XQKZpEWL8mRbHRdxVATKrrJAHOFTl3/s37VLprP
J9kCAwEAAaOCA6swggOnMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsG
AQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUS9is0NdoOI3DZ/36Zlq78IrSedgwHwYDVR0j
BBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwGwYDVR0RBBQwEoEQbmV0d2l6QGNyYy5pZC5h
dTCCAiEGA1UdIASCAhgwggIUMIICEAYLKwYBBAGBtTcBAgIwggH/MC4GCCsGAQUFBwIBFiJo
dHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0
ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVp
cmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0
aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5
IG9ibGlnYXRpb25zLjCBnAYIKwYBBQUHAgIwgY8wJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlv
biBBdXRob3JpdHkwAwIBAhpkTGlhYmlsaXR5IGFuZCB3YXJyYW50aWVzIGFyZSBsaW1pdGVk
ISBTZWUgc2VjdGlvbiAiTGVnYWwgYW5kIExpbWl0YXRpb25zIiBvZiB0aGUgU3RhcnRDb20g
Q0EgcG9saWN5LjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j
cnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz
cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNV
HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBABL6
TyHlAHW0kkHb0ZLcd/pn7Ue0B5mIWBhmta4dK8qd0hXw+/lhpWaJWR/RltCSPabxSd+Lm9Iw
NWm7WP73GHAGby0TC+siwDJSk7CwDBqnVM1T3XQ5TgjfVX7h9qjVixsSWzAD++dXFmpf/344
Uf3zcG/hKJSeRtOvM/88nn4eJtrn7QFnIm4AJpHEgrqwU/0pmQBLwmEYS1G5cr04Oact2v6W
L3JHOlEP8lPBAO9GtZD8UZGmBoDTNG0Rf4TnVTBGdw1sLZqpXnkcVI+rDUaFk/jb7AtCB30N
8tbm2I5ALevgjv+vNMZIQD/0AgOaylGrQwbP852lgOvMo2AdpGExggTdMIIE2QIBATCBlDCB
jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy
ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz
IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMDuKQwCQYFKw4DAhoFAKCCAh0w
GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMDE0MTEyNjA2
WjAjBgkqhkiG9w0BCQQxFgQUB3lsG3rBpIf4dvReB8kqpxrQnygwbAYJKoZIhvcNAQkPMV8w
XTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA
gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpQYJKwYBBAGCNxAE
MYGXMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwO4pDCBpwYLKoZI
hvcNAQkQAgsxgZeggZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu
MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQD
Ey9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDA7ik
MA0GCSqGSIb3DQEBAQUABIICALs/oCi7Z7ZzY4f3BQftZ4/NGzPBVcooUN+5NAROyhzWOjWp
AMA1abEBFVbr630TogC/TLd+bYLT5LUSGgEFadZpvKc5BwORjdyi8LFYI/IKsWULoZk0n5h5
RSjX+ImX3bpMN2X0gnE2Wz1m38ueuiZRwZjvr1/b5wJr+y0e/L9iurpD4KQc9nJRZNy90hsc
Hi6vzSaePMwMXwa2ERQfaq+O3GuU1JH+gXh5e3WVxzRl6rUuEzRUOkGgi7KxjQaDYIdXHbcC
eUiHEFynMjlAjbRZZSHMxglHGXP0oDfxk8p95UxzLoo8zTLuzUGVdyTg71TOuUjeDC3MzSzD
2AnB62CRu/P5AjQ32ZxUJUj8SB9FJF0Bn9yB3z2HMe7YnJ+S1f1qayNzFPwCIn2QtLRhRFP3
9kTaQpwTfmB4V5N1znZlJ7oh8l2lGhglTKzrHBFHClklfdAHsRlQY0Dc+dEOu1XKWcBo/JQB
DP6Ct/v9jTBpcBW4AcYg9pD8sai9yd0MwrjZuzj1SKHh6VDtV0bu5MHnst2b8uC/u5lUDeCQ
73kt30Ir22Lq5WH5h4k1z5BgyfqDSjkFCGR2ulPQ4HtGd5OJR2DwG2gU5pOKAL3fvs+8re81
U4MlRQyEu5esiBAX1w+I26FXlQJs+deDZqBpK2k9IEuxJw93k8NpnaW1qnKkAAAAAAAA
--------------ms020908050806080805070700--


--===============7883047813441151202==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7883047813441151202==--


From xen-devel-bounces@lists.xen.org Sun Oct 14 11:26:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Oct 2012 11:26:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNMKc-0004xn-Ca; Sun, 14 Oct 2012 11:26:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <netwiz@crc.id.au>) id 1TNMKa-0004xi-KD
	for xen-devel@lists.xen.org; Sun, 14 Oct 2012 11:26:05 +0000
Received: from [85.158.138.51:55342] by server-7.bemta-3.messagelabs.com id
	70/48-06991-B41AA705; Sun, 14 Oct 2012 11:26:03 +0000
X-Env-Sender: netwiz@crc.id.au
X-Msg-Ref: server-5.tower-174.messagelabs.com!1350213953!34381501!1
X-Originating-IP: [203.56.246.92]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_8,
	spamassassin: ,
	async_handler: YXN5bmNfZGVsYXk6IDcwNDQ3NzUgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23163 invoked from network); 14 Oct 2012 11:25:54 -0000
Received: from mail.crc.id.au (HELO mail.crc.id.au) (203.56.246.92)
	by server-5.tower-174.messagelabs.com with SMTP;
	14 Oct 2012 11:25:54 -0000
Received: from [IPv6:2002:cb38:f71b:2:e5cd:d7ed:95cf:5689] (unknown
	[IPv6:2002:cb38:f71b:2:e5cd:d7ed:95cf:5689])
	by mail.crc.id.au (Postfix) with ESMTPSA id F36F8D5
	for <xen-devel@lists.xen.org>; Sun, 14 Oct 2012 22:25:49 +1100 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crc.id.au; s=default;
	t=1350213950; bh=LvjytYOqRcxhoH4kupW+XqWoBPwELJ4uBPOVuECi264=;
	h=Date:From:To:Subject:References:In-Reply-To;
	b=Oxw25Ed8sT63y1MuoKj0J9L6610L+eXBE4cHOM5oB78QnVbqB+0xjCGncIPPvqd9Z
	UyZ1s3uT0nRolGRNG5fEQE0VxvIlXXbv9hgmkoW+OTuQHSv9jK3sy+LQ3qy9AdB9vS
	+1ZlpZvJGJhIbMR0FcXWC7Zp71iqxMlz9fLBUW7E=
Message-ID: <507AA14E.3060706@crc.id.au>
Date: Sun, 14 Oct 2012 22:26:06 +1100
From: Steven Haigh <netwiz@crc.id.au>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <20120905030239.GJ8912@reaktio.net>
	<1346846602-1109-1-git-send-email-roger.pau@citrix.com>
	<1347613534.24226.167.camel@zakaz.uk.xensource.com>
	<20121014111035.GE8912@reaktio.net>
In-Reply-To: <20121014111035.GE8912@reaktio.net>
Subject: Re: [Xen-devel] [PATCH] libfsimage: add ext4 support for CentOS 5.x
 / Xen 4.2.1 backport
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7883047813441151202=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============7883047813441151202==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020908050806080805070700"

This is a cryptographically signed message in MIME format.

--------------ms020908050806080805070700
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

On 14/10/2012 10:10 PM, Pasi K=E4rkk=E4inen wrote:
> On Fri, Sep 14, 2012 at 10:05:34AM +0100, Ian Campbell wrote:
>> On Wed, 2012-09-05 at 13:03 +0100, Roger Pau Monne wrote:
>>> CentOS 5.x forked e2fs ext4 support into a different package called
>>> e4fs, and so headers and library names changed from ext2fs to ext4fs.=

>>> Check if ext4fs/ext2fs.h and -lext4fs work, and use that instead of
>>> ext2fs to build libfsimage. This patch assumes that if the ext4fs
>>> library is present it should always be used instead of ext2fs.
>>>
>>> This patch includes a rework of the ext2fs check, a new ext4fs check
>>> and a minor modification in libfsimage to use the correct library.
>>>
>>> Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
>>> ---
>>> Please re-run autogen.sh after applying
>>
>> Done & acked + applied. Thanks.
>>
>
> Hello,
>
> Now that this patch has been in xen-unstable for a while
> I'd like to request Xen 4.2.1 backport..

I agree. I've been slamming my head against a wall trying to package=20
4.2.0 for CentOS 5 for a few days now. Its kinda working, but not=20
really. Having some fixes like this may end up making a few headaches=20
I'm having go away...

--=20
Steven Haigh

Email: netwiz@crc.id.au
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299


--------------ms020908050806080805070700
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOSjCC
BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr
lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM
zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6
qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD
kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95
m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD
CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy
6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI
zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf
KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR
z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9
sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie
uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t
w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ
G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t
5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIIDjCCBvagAwIBAgIDA7ikMA0GCSqGSIb3DQEB
BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g
Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTIwMjEzMTMzODE0
WhcNMTMwMjEzMTc1NjUzWjBXMRkwFwYDVQQNExB3bjVlU1RNM2RWOUIwMEk5MRkwFwYDVQQD
DBBuZXR3aXpAY3JjLmlkLmF1MR8wHQYJKoZIhvcNAQkBFhBuZXR3aXpAY3JjLmlkLmF1MIIC
IjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAzTaLiL78pm4Hqp7Pou4C60jt2wdvDiPt
Sq6hspKk6oaST7BFeDOfoed3mvzytkjNr3C1gds3zsHulAMzRjuX2M1zPkfaj5QFkmlqQcxr
+tnaf8QFpn9PrUcjpbYDYPxdcGR+SeClKzmjdxicHuYDrD8YXnbk+k8dWDaCuv5sKRQHJmIR
maqUIGoVML+/kUR+sqkMpnbhOsL+E84Hg4fxLzpV3Tjf9bZbKgaspvg+BeJJCYKThBxMnZJI
cQ9JzDGL4rO2BEuTXI9Ofl0+AAttBEpZeqc2rePCfA9NivKTCZ0qaFKmvM5SN7TiZUqv80rD
ewTp+OLXNZEd5aa5jEDPNlznkcX0WfuKCmtyIEzT7PgHl1tOWTx7nw6FVWcB8qjC6xlyaL6W
1oS7Om3b2ka+9vSiz7DrPZzUDZuS91Fr2zIIMrrRzhN8q/JdQf8lGTydpmoRUB0z+BAcH8V/
nOcMMDogqV6/dCfywi7zFQK4AsiPSpyBAZyO53J4uPgoIzSpFj54f83KRIobHCWDU1BaU2+6
CfEoAD3iMId1tcFWTXikEThL+3oHQullq9EbPR4f3ToAU7aTZYWG4KNKrmG93KAfyCUFb+bf
mt3hf1BprKIUJnpOxdZHi0KwLXVwURiB4XQKZpEWL8mRbHRdxVATKrrJAHOFTl3/s37VLprP
J9kCAwEAAaOCA6swggOnMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsG
AQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUS9is0NdoOI3DZ/36Zlq78IrSedgwHwYDVR0j
BBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwGwYDVR0RBBQwEoEQbmV0d2l6QGNyYy5pZC5h
dTCCAiEGA1UdIASCAhgwggIUMIICEAYLKwYBBAGBtTcBAgIwggH/MC4GCCsGAQUFBwIBFiJo
dHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0
ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVp
cmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0
aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5
IG9ibGlnYXRpb25zLjCBnAYIKwYBBQUHAgIwgY8wJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlv
biBBdXRob3JpdHkwAwIBAhpkTGlhYmlsaXR5IGFuZCB3YXJyYW50aWVzIGFyZSBsaW1pdGVk
ISBTZWUgc2VjdGlvbiAiTGVnYWwgYW5kIExpbWl0YXRpb25zIiBvZiB0aGUgU3RhcnRDb20g
Q0EgcG9saWN5LjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j
cnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz
cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNV
HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBABL6
TyHlAHW0kkHb0ZLcd/pn7Ue0B5mIWBhmta4dK8qd0hXw+/lhpWaJWR/RltCSPabxSd+Lm9Iw
NWm7WP73GHAGby0TC+siwDJSk7CwDBqnVM1T3XQ5TgjfVX7h9qjVixsSWzAD++dXFmpf/344
Uf3zcG/hKJSeRtOvM/88nn4eJtrn7QFnIm4AJpHEgrqwU/0pmQBLwmEYS1G5cr04Oact2v6W
L3JHOlEP8lPBAO9GtZD8UZGmBoDTNG0Rf4TnVTBGdw1sLZqpXnkcVI+rDUaFk/jb7AtCB30N
8tbm2I5ALevgjv+vNMZIQD/0AgOaylGrQwbP852lgOvMo2AdpGExggTdMIIE2QIBATCBlDCB
jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy
ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz
IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMDuKQwCQYFKw4DAhoFAKCCAh0w
GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMDE0MTEyNjA2
WjAjBgkqhkiG9w0BCQQxFgQUB3lsG3rBpIf4dvReB8kqpxrQnygwbAYJKoZIhvcNAQkPMV8w
XTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA
gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpQYJKwYBBAGCNxAE
MYGXMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwO4pDCBpwYLKoZI
hvcNAQkQAgsxgZeggZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu
MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQD
Ey9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDA7ik
MA0GCSqGSIb3DQEBAQUABIICALs/oCi7Z7ZzY4f3BQftZ4/NGzPBVcooUN+5NAROyhzWOjWp
AMA1abEBFVbr630TogC/TLd+bYLT5LUSGgEFadZpvKc5BwORjdyi8LFYI/IKsWULoZk0n5h5
RSjX+ImX3bpMN2X0gnE2Wz1m38ueuiZRwZjvr1/b5wJr+y0e/L9iurpD4KQc9nJRZNy90hsc
Hi6vzSaePMwMXwa2ERQfaq+O3GuU1JH+gXh5e3WVxzRl6rUuEzRUOkGgi7KxjQaDYIdXHbcC
eUiHEFynMjlAjbRZZSHMxglHGXP0oDfxk8p95UxzLoo8zTLuzUGVdyTg71TOuUjeDC3MzSzD
2AnB62CRu/P5AjQ32ZxUJUj8SB9FJF0Bn9yB3z2HMe7YnJ+S1f1qayNzFPwCIn2QtLRhRFP3
9kTaQpwTfmB4V5N1znZlJ7oh8l2lGhglTKzrHBFHClklfdAHsRlQY0Dc+dEOu1XKWcBo/JQB
DP6Ct/v9jTBpcBW4AcYg9pD8sai9yd0MwrjZuzj1SKHh6VDtV0bu5MHnst2b8uC/u5lUDeCQ
73kt30Ir22Lq5WH5h4k1z5BgyfqDSjkFCGR2ulPQ4HtGd5OJR2DwG2gU5pOKAL3fvs+8re81
U4MlRQyEu5esiBAX1w+I26FXlQJs+deDZqBpK2k9IEuxJw93k8NpnaW1qnKkAAAAAAAA
--------------ms020908050806080805070700--


--===============7883047813441151202==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7883047813441151202==--


From xen-devel-bounces@lists.xen.org Sun Oct 14 15:12:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Oct 2012 15:12:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNPrY-0006nU-1P; Sun, 14 Oct 2012 15:12:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TNPrW-0006nP-58
	for xen-devel@lists.xensource.com; Sun, 14 Oct 2012 15:12:18 +0000
Received: from [85.158.139.211:54770] by server-3.bemta-5.messagelabs.com id
	DE/46-09712-156DA705; Sun, 14 Oct 2012 15:12:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1350227536!21799578!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13641 invoked from network); 14 Oct 2012 15:12:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Oct 2012 15:12:16 -0000
X-IronPort-AV: E=Sophos;i="4.80,583,1344211200"; d="scan'208";a="15152436"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Oct 2012 15:12:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sun, 14 Oct 2012 16:12:16 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1TNPrT-0004PT-VE;
	Sun, 14 Oct 2012 15:12:16 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TNPrT-0006Bs-Mz;
	Sun, 14 Oct 2012 16:12:15 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13961-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 14 Oct 2012 16:12:15 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 13961: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13961 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13961/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                    fail pass in 13959
 test-amd64-i386-xl-multivcpu 14 guest-localmigrate/x10 fail in 13959 pass in 13961

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore         fail REGR. vs. 13948
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13948
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13948

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 linux                40e6f9362555294cf1ce8abb1981b11d622e04d6
baseline version:
 linux                24e842ae6cb8179126246ebcbfc477b36a7b8719

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=linux-3.0
+ revision=40e6f9362555294cf1ce8abb1981b11d622e04d6
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push linux-3.0 40e6f9362555294cf1ce8abb1981b11d622e04d6
+ branch=linux-3.0
+ revision=40e6f9362555294cf1ce8abb1981b11d622e04d6
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=linux
+ xenbranch=xen-unstable
+ '[' xlinux = xlinux ']'
+ linuxbranch=linux-3.0
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.linux-3.0
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux-3.0
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree linux-3.0
+ case $1 in
+ : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
+ : linux-3.0.y
+ : linux-3.0.y
+ : git
+ : git
+ : git://xenbits.xen.org/linux-pvops.git
+ : xen@xenbits.xensource.com:git/linux-pvops.git
+ : tested/linux-3.0
+ : tested/linux-3.0
+ return 0
+ cd /export/home/osstest/repos/linux
+ git push xen@xenbits.xensource.com:git/linux-pvops.git 40e6f9362555294cf1ce8abb1981b11d622e04d6:tested/linux-3.0
Counting objects: 1   
Counting objects: 517   
Counting objects: 574, done.
Compressing objects:   1% (1/83)   
Compressing objects:   2% (2/83)   
Compressing objects:   3% (3/83)   
Compressing objects:   4% (4/83)   
Compressing objects:   6% (5/83)   
Compressing objects:   7% (6/83)   
Compressing objects:   8% (7/83)   
Compressing objects:   9% (8/83)   
Compressing objects:  10% (9/83)   
Compressing objects:  12% (10/83)   
Compressing objects:  13% (11/83)   
Compressing objects:  14% (12/83)   
Compressing objects:  15% (13/83)   
Compressing objects:  16% (14/83)   
Compressing objects:  18% (15/83)   
Compressing objects:  19% (16/83)   
Compressing objects:  20% (17/83)   
Compressing objects:  21% (18/83)   
Compressing objects:  22% (19/83)   
Compressing objects:  24% (20/83)   
Compressing objects:  25% (21/83)   
Compressing objects:  26% (22/83)   
Compressing objects:  27% (23/83)   
Compressing objects:  28% (24/83)   
Compressing objects:  30% (25/83)   
Compressing objects:  31% (26/83)   
Compressing objects:  32% (27/83)   
Compressing objects:  33% (28/83)   
Compressing objects:  34% (29/83)   
Compressing objects:  36% (30/83)   
Compressing objects:  37% (31/83)   
Compressing objects:  38% (32/83)   
Compressing objects:  39% (33/83)   
Compressing objects:  40% (34/83)   
Compressing objects:  42% (35/83)   
Compressing objects:  43% (36/83)   
Compressing objects:  44% (37/83)   
Compressing objects:  45% (38/83)   
Compressing objects:  46% (39/83)   
Compressing objects:  48% (40/83)   
Compressing objects:  49% (41/83)   
Compressing objects:  50% (42/83)   
Compressing objects:  51% (43/83)   
Compressing objects:  53% (44/83)   
Compressing objects:  54% (45/83)   
Compressing objects:  55% (46/83)   
Compressing objects:  56% (47/83)   
Compressing objects:  57% (48/83)   
Compressing objects:  59% (49/83)   
Compressing objects:  60% (50/83)   
Compressing objects:  61% (51/83)   
Compressing objects:  62% (52/83)   
Compressing objects:  63% (53/83)   
Compressing objects:  65% (54/83)   
Compressing objects:  66% (55/83)   
Compressing objects:  67% (56/83)   
Compressing objects:  68% (57/83)   
Compressing objects:  69% (58/83)   
Compressing objects:  71% (59/83)   
Compressing objects:  72% (60/83)   
Compressing objects:  73% (61/83)   
Compressing objects:  74% (62/83)   
Compressing objects:  75% (63/83)   
Compressing objects:  77% (64/83)   
Compressing objects:  78% (65/83)   
Compressing objects:  79% (66/83)   
Compressing objects:  80% (67/83)   
Compressing objects:  81% (68/83)   
Compressing objects:  83% (69/83)   
Compressing objects:  84% (70/83)   
Compressing objects:  85% (71/83)   
Compressing objects:  86% (72/83)   
Compressing objects:  87% (73/83)   
Compressing objects:  89% (74/83)   
Compressing objects:  90% (75/83)   
Compressing objects:  91% (76/83)   
Compressing objects:  92% (77/83)   
Compressing objects:  93% (78/83)   
Compressing objects:  95% (79/83)   
Compressing objects:  96% (80/83)   
Compressing objects:  97% (81/83)   
Compressing objects:  98% (82/83)   
Compressing objects: 100% (83/83)   
Compressing objects: 100% (83/83), done.
Writing objects:   0% (1/455)   
Writing objects:   1% (5/455)   
Writing objects:   2% (10/455)   
Writing objects:   3% (14/455)   
Writing objects:   4% (19/455)   
Writing objects:   5% (23/455)   
Writing objects:   6% (28/455)   
Writing objects:   7% (32/455)   
Writing objects:   8% (37/455)   
Writing objects:   9% (41/455)   
Writing objects:  10% (46/455)   
Writing objects:  11% (52/455)   
Writing objects:  12% (55/455)   
Writing objects:  13% (60/455)   
Writing objects:  14% (64/455)   
Writing objects:  15% (69/455)   
Writing objects:  16% (73/455)   
Writing objects:  17% (78/455)   
Writing objects:  18% (82/455)   
Writing objects:  19% (87/455)   
Writing objects:  20% (91/455)   
Writing objects:  21% (96/455)   
Writing objects:  22% (101/455)   
Writing objects:  23% (105/455)   
Writing objects:  24% (110/455)   
Writing objects:  25% (114/455)   
Writing objects:  26% (119/455)   
Writing objects:  27% (123/455)   
Writing objects:  28% (128/455)   
Writing objects:  29% (132/455)   
Writing objects:  30% (137/455)   
Writing objects:  31% (142/455)   
Writing objects:  32% (146/455)   
Writing objects:  33% (151/455)   
Writing objects:  34% (155/455)   
Writing objects:  35% (160/455)   
Writing objects:  36% (164/455)   
Writing objects:  37% (169/455)   
Writing objects:  38% (173/455)   
Writing objects:  39% (178/455)   
Writing objects:  40% (182/455)   
Writing objects:  41% (187/455)   
Writing objects:  42% (192/455)   
Writing objects:  43% (196/455)   
Writing objects:  44% (201/455)   
Writing objects:  45% (205/455)   
Writing objects:  46% (210/455)   
Writing objects:  47% (214/455)   
Writing objects:  48% (219/455)   
Writing objects:  49% (223/455)   
Writing objects:  50% (228/455)   
Writing objects:  51% (233/455)   
Writing objects:  52% (237/455)   
Writing objects:  53% (242/455)   
Writing objects:  54% (246/455)   
Writing objects:  55% (251/455)   
Writing objects:  56% (255/455)   
Writing objects:  57% (260/455)   
Writing objects:  58% (264/455)   
Writing objects:  59% (269/455)   
Writing objects:  60% (273/455)   
Writing objects:  61% (278/455)   
Writing objects:  62% (283/455)   
Writing objects:  63% (287/455)   
Writing objects:  64% (292/455)   
Writing objects:  65% (296/455)   
Writing objects:  66% (301/455)   
Writing objects:  67% (305/455)   
Writing objects:  68% (310/455)   
Writing objects:  69% (314/455)   
Writing objects:  70% (319/455)   
Writing objects:  71% (324/455)   
Writing objects:  72% (328/455)   
Writing objects:  73% (333/455)   
Writing objects:  74% (337/455)   
Writing objects:  75% (342/455)   
Writing objects:  76% (346/455)   
Writing objects:  77% (351/455)   
Writing objects:  78% (355/455)   
Writing objects:  79% (360/455)   
Writing objects:  80% (364/455)   
Writing objects:  81% (369/455)   
Writing objects:  82% (374/455)   
Writing objects:  83% (378/455)   
Writing objects:  84% (383/455)   
Writing objects:  85% (387/455)   
Writing objects:  86% (392/455)   
Writing objects:  87% (396/455)   
Writing objects:  88% (401/455)   
Writing objects:  89% (405/455)   
Writing objects:  90% (410/455)   
Writing objects:  91% (415/455)   
Writing objects:  92% (419/455)   
Writing objects:  93% (424/455)   
Writing objects:  94% (428/455)   
Writing objects:  95% (433/455)   
Writing objects:  96% (437/455)   
Writing objects:  97% (442/455)   
Writing objects:  98% (446/455)   
Writing objects:  99% (451/455)   
Writing objects: 100% (455/455)   
Writing objects: 100% (455/455), 86.34 KiB, done.
Total 455 (delta 371), reused 455 (delta 371)
To xen@xenbits.xensource.com:git/linux-pvops.git
   24e842a..40e6f93  40e6f9362555294cf1ce8abb1981b11d622e04d6 -> tested/linux-3.0
+ exit 0

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 14 15:12:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Oct 2012 15:12:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNPrY-0006nU-1P; Sun, 14 Oct 2012 15:12:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TNPrW-0006nP-58
	for xen-devel@lists.xensource.com; Sun, 14 Oct 2012 15:12:18 +0000
Received: from [85.158.139.211:54770] by server-3.bemta-5.messagelabs.com id
	DE/46-09712-156DA705; Sun, 14 Oct 2012 15:12:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1350227536!21799578!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13641 invoked from network); 14 Oct 2012 15:12:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Oct 2012 15:12:16 -0000
X-IronPort-AV: E=Sophos;i="4.80,583,1344211200"; d="scan'208";a="15152436"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Oct 2012 15:12:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sun, 14 Oct 2012 16:12:16 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1TNPrT-0004PT-VE;
	Sun, 14 Oct 2012 15:12:16 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TNPrT-0006Bs-Mz;
	Sun, 14 Oct 2012 16:12:15 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13961-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 14 Oct 2012 16:12:15 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 13961: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13961 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13961/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                    fail pass in 13959
 test-amd64-i386-xl-multivcpu 14 guest-localmigrate/x10 fail in 13959 pass in 13961

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore         fail REGR. vs. 13948
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13948
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13948

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 linux                40e6f9362555294cf1ce8abb1981b11d622e04d6
baseline version:
 linux                24e842ae6cb8179126246ebcbfc477b36a7b8719

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=linux-3.0
+ revision=40e6f9362555294cf1ce8abb1981b11d622e04d6
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push linux-3.0 40e6f9362555294cf1ce8abb1981b11d622e04d6
+ branch=linux-3.0
+ revision=40e6f9362555294cf1ce8abb1981b11d622e04d6
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=linux
+ xenbranch=xen-unstable
+ '[' xlinux = xlinux ']'
+ linuxbranch=linux-3.0
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.linux-3.0
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux-3.0
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree linux-3.0
+ case $1 in
+ : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
+ : linux-3.0.y
+ : linux-3.0.y
+ : git
+ : git
+ : git://xenbits.xen.org/linux-pvops.git
+ : xen@xenbits.xensource.com:git/linux-pvops.git
+ : tested/linux-3.0
+ : tested/linux-3.0
+ return 0
+ cd /export/home/osstest/repos/linux
+ git push xen@xenbits.xensource.com:git/linux-pvops.git 40e6f9362555294cf1ce8abb1981b11d622e04d6:tested/linux-3.0
Counting objects: 1   
Counting objects: 517   
Counting objects: 574, done.
Compressing objects:   1% (1/83)   
Compressing objects:   2% (2/83)   
Compressing objects:   3% (3/83)   
Compressing objects:   4% (4/83)   
Compressing objects:   6% (5/83)   
Compressing objects:   7% (6/83)   
Compressing objects:   8% (7/83)   
Compressing objects:   9% (8/83)   
Compressing objects:  10% (9/83)   
Compressing objects:  12% (10/83)   
Compressing objects:  13% (11/83)   
Compressing objects:  14% (12/83)   
Compressing objects:  15% (13/83)   
Compressing objects:  16% (14/83)   
Compressing objects:  18% (15/83)   
Compressing objects:  19% (16/83)   
Compressing objects:  20% (17/83)   
Compressing objects:  21% (18/83)   
Compressing objects:  22% (19/83)   
Compressing objects:  24% (20/83)   
Compressing objects:  25% (21/83)   
Compressing objects:  26% (22/83)   
Compressing objects:  27% (23/83)   
Compressing objects:  28% (24/83)   
Compressing objects:  30% (25/83)   
Compressing objects:  31% (26/83)   
Compressing objects:  32% (27/83)   
Compressing objects:  33% (28/83)   
Compressing objects:  34% (29/83)   
Compressing objects:  36% (30/83)   
Compressing objects:  37% (31/83)   
Compressing objects:  38% (32/83)   
Compressing objects:  39% (33/83)   
Compressing objects:  40% (34/83)   
Compressing objects:  42% (35/83)   
Compressing objects:  43% (36/83)   
Compressing objects:  44% (37/83)   
Compressing objects:  45% (38/83)   
Compressing objects:  46% (39/83)   
Compressing objects:  48% (40/83)   
Compressing objects:  49% (41/83)   
Compressing objects:  50% (42/83)   
Compressing objects:  51% (43/83)   
Compressing objects:  53% (44/83)   
Compressing objects:  54% (45/83)   
Compressing objects:  55% (46/83)   
Compressing objects:  56% (47/83)   
Compressing objects:  57% (48/83)   
Compressing objects:  59% (49/83)   
Compressing objects:  60% (50/83)   
Compressing objects:  61% (51/83)   
Compressing objects:  62% (52/83)   
Compressing objects:  63% (53/83)   
Compressing objects:  65% (54/83)   
Compressing objects:  66% (55/83)   
Compressing objects:  67% (56/83)   
Compressing objects:  68% (57/83)   
Compressing objects:  69% (58/83)   
Compressing objects:  71% (59/83)   
Compressing objects:  72% (60/83)   
Compressing objects:  73% (61/83)   
Compressing objects:  74% (62/83)   
Compressing objects:  75% (63/83)   
Compressing objects:  77% (64/83)   
Compressing objects:  78% (65/83)   
Compressing objects:  79% (66/83)   
Compressing objects:  80% (67/83)   
Compressing objects:  81% (68/83)   
Compressing objects:  83% (69/83)   
Compressing objects:  84% (70/83)   
Compressing objects:  85% (71/83)   
Compressing objects:  86% (72/83)   
Compressing objects:  87% (73/83)   
Compressing objects:  89% (74/83)   
Compressing objects:  90% (75/83)   
Compressing objects:  91% (76/83)   
Compressing objects:  92% (77/83)   
Compressing objects:  93% (78/83)   
Compressing objects:  95% (79/83)   
Compressing objects:  96% (80/83)   
Compressing objects:  97% (81/83)   
Compressing objects:  98% (82/83)   
Compressing objects: 100% (83/83)   
Compressing objects: 100% (83/83), done.
Writing objects:   0% (1/455)   
Writing objects:   1% (5/455)   
Writing objects:   2% (10/455)   
Writing objects:   3% (14/455)   
Writing objects:   4% (19/455)   
Writing objects:   5% (23/455)   
Writing objects:   6% (28/455)   
Writing objects:   7% (32/455)   
Writing objects:   8% (37/455)   
Writing objects:   9% (41/455)   
Writing objects:  10% (46/455)   
Writing objects:  11% (52/455)   
Writing objects:  12% (55/455)   
Writing objects:  13% (60/455)   
Writing objects:  14% (64/455)   
Writing objects:  15% (69/455)   
Writing objects:  16% (73/455)   
Writing objects:  17% (78/455)   
Writing objects:  18% (82/455)   
Writing objects:  19% (87/455)   
Writing objects:  20% (91/455)   
Writing objects:  21% (96/455)   
Writing objects:  22% (101/455)   
Writing objects:  23% (105/455)   
Writing objects:  24% (110/455)   
Writing objects:  25% (114/455)   
Writing objects:  26% (119/455)   
Writing objects:  27% (123/455)   
Writing objects:  28% (128/455)   
Writing objects:  29% (132/455)   
Writing objects:  30% (137/455)   
Writing objects:  31% (142/455)   
Writing objects:  32% (146/455)   
Writing objects:  33% (151/455)   
Writing objects:  34% (155/455)   
Writing objects:  35% (160/455)   
Writing objects:  36% (164/455)   
Writing objects:  37% (169/455)   
Writing objects:  38% (173/455)   
Writing objects:  39% (178/455)   
Writing objects:  40% (182/455)   
Writing objects:  41% (187/455)   
Writing objects:  42% (192/455)   
Writing objects:  43% (196/455)   
Writing objects:  44% (201/455)   
Writing objects:  45% (205/455)   
Writing objects:  46% (210/455)   
Writing objects:  47% (214/455)   
Writing objects:  48% (219/455)   
Writing objects:  49% (223/455)   
Writing objects:  50% (228/455)   
Writing objects:  51% (233/455)   
Writing objects:  52% (237/455)   
Writing objects:  53% (242/455)   
Writing objects:  54% (246/455)   
Writing objects:  55% (251/455)   
Writing objects:  56% (255/455)   
Writing objects:  57% (260/455)   
Writing objects:  58% (264/455)   
Writing objects:  59% (269/455)   
Writing objects:  60% (273/455)   
Writing objects:  61% (278/455)   
Writing objects:  62% (283/455)   
Writing objects:  63% (287/455)   
Writing objects:  64% (292/455)   
Writing objects:  65% (296/455)   
Writing objects:  66% (301/455)   
Writing objects:  67% (305/455)   
Writing objects:  68% (310/455)   
Writing objects:  69% (314/455)   
Writing objects:  70% (319/455)   
Writing objects:  71% (324/455)   
Writing objects:  72% (328/455)   
Writing objects:  73% (333/455)   
Writing objects:  74% (337/455)   
Writing objects:  75% (342/455)   
Writing objects:  76% (346/455)   
Writing objects:  77% (351/455)   
Writing objects:  78% (355/455)   
Writing objects:  79% (360/455)   
Writing objects:  80% (364/455)   
Writing objects:  81% (369/455)   
Writing objects:  82% (374/455)   
Writing objects:  83% (378/455)   
Writing objects:  84% (383/455)   
Writing objects:  85% (387/455)   
Writing objects:  86% (392/455)   
Writing objects:  87% (396/455)   
Writing objects:  88% (401/455)   
Writing objects:  89% (405/455)   
Writing objects:  90% (410/455)   
Writing objects:  91% (415/455)   
Writing objects:  92% (419/455)   
Writing objects:  93% (424/455)   
Writing objects:  94% (428/455)   
Writing objects:  95% (433/455)   
Writing objects:  96% (437/455)   
Writing objects:  97% (442/455)   
Writing objects:  98% (446/455)   
Writing objects:  99% (451/455)   
Writing objects: 100% (455/455)   
Writing objects: 100% (455/455), 86.34 KiB, done.
Total 455 (delta 371), reused 455 (delta 371)
To xen@xenbits.xensource.com:git/linux-pvops.git
   24e842a..40e6f93  40e6f9362555294cf1ce8abb1981b11d622e04d6 -> tested/linux-3.0
+ exit 0

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 14 17:03:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Oct 2012 17:03:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNRb2-0008Jj-9p; Sun, 14 Oct 2012 17:03:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <singapore.mr.teo.en.ming@gmail.com>)
	id 1TNRb1-0008Jb-1t; Sun, 14 Oct 2012 17:03:23 +0000
Received: from [85.158.139.83:64036] by server-5.bemta-5.messagelabs.com id
	A6/1C-19238-950FA705; Sun, 14 Oct 2012 17:03:21 +0000
X-Env-Sender: singapore.mr.teo.en.ming@gmail.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1350234198!27578115!1
X-Originating-IP: [209.85.210.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12187 invoked from network); 14 Oct 2012 17:03:20 -0000
Received: from mail-da0-f45.google.com (HELO mail-da0-f45.google.com)
	(209.85.210.45)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Oct 2012 17:03:20 -0000
Received: by mail-da0-f45.google.com with SMTP id n15so2166028dad.32
	for <multiple recipients>; Sun, 14 Oct 2012 10:03:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:subject
	:content-type:content-transfer-encoding;
	bh=OzfwOHa5zwefnp4VmJJgVhnAqNSkusYcJSb2flzjgN4=;
	b=IEXSLUK47wcGiofAIunxLFyDuRfj+/YJcIJxmNoJT94AAsX+nTZWqc9XwQesnuMXpZ
	Lsq4YczEtX/ZlgprRRir8VP2pmhmKgkGA09zoXLi25dx3Ij2h4Mp43hI1nxeoPzqQC0D
	KQTGItNWHFJcl7YgjyissDScb1NeyONy37kn4VfydsZZOCO7pDgSTiqrRgY6/9HZFWGv
	husBHOShS9Gt0zRtk57rp9x/qMUVhy2nd+tUPjguw/c7CA2Gxl3Ru77ZgY6L8/WELOq6
	fvzD5c4BLbbvTQJhTD12WXitAroBTWbx2XuLZxAuKAAlS9zYDfZRQ23SpNYoh3s6nxab
	iygA==
Received: by 10.68.234.71 with SMTP id uc7mr30286128pbc.72.1350234198367;
	Sun, 14 Oct 2012 10:03:18 -0700 (PDT)
Received: from [192.168.1.5] (cm152.gamma205.maxonline.com.sg.
	[202.156.205.152])
	by mx.google.com with ESMTPS id i2sm7674982pay.31.2012.10.14.10.03.15
	(version=SSLv3 cipher=OTHER); Sun, 14 Oct 2012 10:03:17 -0700 (PDT)
Message-ID: <507AF052.4040209@gmail.com>
Date: Mon, 15 Oct 2012 01:03:14 +0800
From: "Teo En Ming (Zhang Enming)" <singapore.mr.teo.en.ming@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: "xen-users@lists.xen.org" <xen-users@lists.xen.org>, 
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Teo En Ming (Zhang Enming)" <singapore.mr.teo.en.ming@gmail.com>, 
	Ian Campbell <Ian.Campbell@citrix.com>, konrad@kernel.org
Subject: [Xen-devel] Unable to Start Windows XP HVM domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

I am unable to start Windows XP HVM domU in an X environment.

Here is the error output:

teo-en-ming@ubuntu-12041-amd64-server:/etc/xen$ sudo xl -vvv create 
/etc/xen/windowsxp
Parsing config from /etc/xen/windowsxp
libxl: debug: libxl_create.c:1191:do_domain_create: ao 0x178ab50: 
create: how=(nil) callback=(nil) poller=0x178a350
libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk 
vdev=hda spec.backend=unknown
libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=hda, 
backend phy unsuitable as phys path not a block device
libxl: debug: libxl_device.c:184:disk_try_backend: Disk vdev=hda, 
backend tap unsuitable because blktap not available
libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk 
vdev=hda, using backend qdisk
libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk 
vdev=hdc spec.backend=unknown
libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=hdc, 
backend phy unsuitable as phys path not a block device
libxl: debug: libxl_device.c:184:disk_try_backend: Disk vdev=hdc, 
backend tap unsuitable because blktap not available
libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk 
vdev=hdc, using backend qdisk
libxl: debug: libxl_create.c:677:initiate_domain_create: running bootloader
libxl: debug: libxl_bootloader.c:321:libxl__bootloader_run: not a PV 
domain, skipping bootloader
libxl: debug: libxl_event.c:561:libxl__ev_xswatch_deregister: watch 
w=0x178aed0: deregister unregistered
libxl: debug: libxl_numa.c:435:libxl__get_numa_candidate: New best NUMA 
placement candidate found: nr_nodes=1, nr_cpus=2, nr_vcpus=4, 
free_memkb=2278
libxl: detail: libxl_dom.c:192:numa_place_domain: NUMA placement 
candidate with 1 nodes, 2 cpus and 2278 KB free selected
xc: detail: elf_parse_binary: phdr: paddr=0x100000 memsz=0xad98c
xc: detail: elf_parse_binary: memory: 0x100000 -> 0x1ad98c
xc: info: VIRTUAL MEMORY ARRANGEMENT:
   Loader:        0000000000100000->00000000001ad98c
   TOTAL:         0000000000000000->000000003f800000
   ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
   4KB PAGES: 0x0000000000000200
   2MB PAGES: 0x00000000000001fb
   1GB PAGES: 0x0000000000000000
xc: detail: elf_load_binary: phdr 0 at 0x0x7fbc63478000 -> 0x0x7fbc6351c803
libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk 
vdev=hda spec.backend=qdisk
libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk 
vdev=hdc spec.backend=qdisk
libxl: debug: libxl_dm.c:1134:libxl__spawn_local_dm: Spawning 
device-model /usr/lib/xen/bin/qemu-dm with arguments:
libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm: 
/usr/lib/xen/bin/qemu-dm
libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   -d
libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   12
libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   -domain-name
libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   WindowsXP
libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   -vnc
libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   192.168.1.2:0
libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   -vncunused
libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   -videoram
libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   8
libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   -boot
libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   dc
libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   -usb
libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   -usbdevice
libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   tablet
libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   -acpi
libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   -vcpus
libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   2
libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   -vcpu_avail
libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   0x03
libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   -net
libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   none
libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   -M
libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   xenfv
libxl: debug: libxl_event.c:512:libxl__ev_xswatch_register: watch 
w=0x178b108 wpath=/local/domain/0/device-model/12/state token=3/0: 
register slotnum=3
libxl: debug: libxl_create.c:1204:do_domain_create: ao 0x178ab50: 
inprogress: poller=0x178a350, flags=i
libxl: debug: libxl_event.c:457:watchfd_callback: watch w=0x178b108 
wpath=/local/domain/0/device-model/12/state token=3/0: event 
epath=/local/domain/0/device-model/12/state
libxl: debug: libxl_event.c:549:libxl__ev_xswatch_deregister: watch 
w=0x178b108 wpath=/local/domain/0/device-model/12/state token=3/0: 
deregister slotnum=3
libxl: error: libxl_dm.c:1203:device_model_spawn_outcome: domain 12 
device model: spawn failed (rc=-3)
libxl: debug: libxl_event.c:1667:libxl__ao_progress_report: ao 
0x178ab50: progress report: ignored
libxl: debug: libxl_event.c:1497:libxl__ao_complete: ao 0x178ab50: 
complete, rc=0
libxl: debug: libxl_event.c:1469:libxl__ao__destroy: ao 0x178ab50: destroy
Daemon running with PID 4480
xc: debug: hypercall buffer: total allocations:750 total releases:750
xc: debug: hypercall buffer: current allocations:0 maximum allocations:4
xc: debug: hypercall buffer: cache current size:4
xc: debug: hypercall buffer: cache hits:742 misses:4 toobig:4

My Windows XP HVM domU config is:

# XL domain configuration file for Windows XP Home Edition SP3 HVM domU
# Please refer to "man xl.cfg" for further explanations.
# See also docs/misc/xl-network-configuration.markdown and
# docs/misc/xl-disk-configuration.txt
# Written by Teo En Ming (Zhang Enming)
# Email: teo.en.ming@gmail.com
# Mobile Phone: +65-8369-2618
# Country: Singapore
# Date: 18 Mar 2012 Sun
name="WindowsXP"
builder="hvm"
vcpus=2
memory=1024
on_poweroff="destroy"
on_reboot="restart"
on_crash="destroy"
disk=[ 'format=raw, vdev=hda, access=rw, 
target=/etc/xen/images/windowsxp.img', 'format=raw, vdev=hdc, access=ro, 
devtype=cdrom, target=/home/teo-en-ming/windowsxp.iso' ]
#vif=[ 'bridge=eth0,type=ioemu,model=rtl8139' ]
#boot=[c|d|n]
#Selects the emulated virtual device to boot from. Options are hard disk 
(c), cd-rom (d) or network/PXE (n).
#Multiple options can be given and will be attempted in the order they 
are given. e.g. to boot from cd-rom
#but fallback to the hard disk you can give dc. The default is cd.
boot="dc"
acpi=1
#xen_platform_pci=1
#viridian=1
#stdvga=1
vnc=1
vnclisten="192.168.1.2"
vncdisplay=0
vncunused=1
vncpasswd=""
sdl=0
usb=1
usbdevice="tablet"
# Enable Xen VGA Passthrough
gfx_passthru=0
# VGA Passthrough Gigabyte Geforce GTX 560 1 GB GDDR5 PCI Express x16 
VGA card.
#pci = [ 
'01:00.0','01:00.1','00:1b.0','00:1a.0','00:1a.1','00:1a.2','00:1a.7','00:1d.0','00:1d.1','00:1d.2','00:1d.7' 
]
#pci = [ '01:00.0','01:00.1','00:1b.0' ]

# PCI Passthrough Intel HD Audio Controller.
#pci = [ '00:1b.0' ]
# PCI Passthrough all the USB Controllers.
# pci = [ 
'00:1a.0','00:1a.1','00:1a.2','00:1a.7','00:1d.0','00:1d.1','00:1d.2','00:1d.7' 
]

I am using Xen 4.3-unstable changeset 26004 and Linux dom0 kernel 3.6.1.

May I know what is the problem? Please advise.

Thank you very much.

-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 14 17:03:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Oct 2012 17:03:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNRb2-0008Jj-9p; Sun, 14 Oct 2012 17:03:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <singapore.mr.teo.en.ming@gmail.com>)
	id 1TNRb1-0008Jb-1t; Sun, 14 Oct 2012 17:03:23 +0000
Received: from [85.158.139.83:64036] by server-5.bemta-5.messagelabs.com id
	A6/1C-19238-950FA705; Sun, 14 Oct 2012 17:03:21 +0000
X-Env-Sender: singapore.mr.teo.en.ming@gmail.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1350234198!27578115!1
X-Originating-IP: [209.85.210.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12187 invoked from network); 14 Oct 2012 17:03:20 -0000
Received: from mail-da0-f45.google.com (HELO mail-da0-f45.google.com)
	(209.85.210.45)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Oct 2012 17:03:20 -0000
Received: by mail-da0-f45.google.com with SMTP id n15so2166028dad.32
	for <multiple recipients>; Sun, 14 Oct 2012 10:03:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:subject
	:content-type:content-transfer-encoding;
	bh=OzfwOHa5zwefnp4VmJJgVhnAqNSkusYcJSb2flzjgN4=;
	b=IEXSLUK47wcGiofAIunxLFyDuRfj+/YJcIJxmNoJT94AAsX+nTZWqc9XwQesnuMXpZ
	Lsq4YczEtX/ZlgprRRir8VP2pmhmKgkGA09zoXLi25dx3Ij2h4Mp43hI1nxeoPzqQC0D
	KQTGItNWHFJcl7YgjyissDScb1NeyONy37kn4VfydsZZOCO7pDgSTiqrRgY6/9HZFWGv
	husBHOShS9Gt0zRtk57rp9x/qMUVhy2nd+tUPjguw/c7CA2Gxl3Ru77ZgY6L8/WELOq6
	fvzD5c4BLbbvTQJhTD12WXitAroBTWbx2XuLZxAuKAAlS9zYDfZRQ23SpNYoh3s6nxab
	iygA==
Received: by 10.68.234.71 with SMTP id uc7mr30286128pbc.72.1350234198367;
	Sun, 14 Oct 2012 10:03:18 -0700 (PDT)
Received: from [192.168.1.5] (cm152.gamma205.maxonline.com.sg.
	[202.156.205.152])
	by mx.google.com with ESMTPS id i2sm7674982pay.31.2012.10.14.10.03.15
	(version=SSLv3 cipher=OTHER); Sun, 14 Oct 2012 10:03:17 -0700 (PDT)
Message-ID: <507AF052.4040209@gmail.com>
Date: Mon, 15 Oct 2012 01:03:14 +0800
From: "Teo En Ming (Zhang Enming)" <singapore.mr.teo.en.ming@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: "xen-users@lists.xen.org" <xen-users@lists.xen.org>, 
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Teo En Ming (Zhang Enming)" <singapore.mr.teo.en.ming@gmail.com>, 
	Ian Campbell <Ian.Campbell@citrix.com>, konrad@kernel.org
Subject: [Xen-devel] Unable to Start Windows XP HVM domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

I am unable to start Windows XP HVM domU in an X environment.

Here is the error output:

teo-en-ming@ubuntu-12041-amd64-server:/etc/xen$ sudo xl -vvv create 
/etc/xen/windowsxp
Parsing config from /etc/xen/windowsxp
libxl: debug: libxl_create.c:1191:do_domain_create: ao 0x178ab50: 
create: how=(nil) callback=(nil) poller=0x178a350
libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk 
vdev=hda spec.backend=unknown
libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=hda, 
backend phy unsuitable as phys path not a block device
libxl: debug: libxl_device.c:184:disk_try_backend: Disk vdev=hda, 
backend tap unsuitable because blktap not available
libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk 
vdev=hda, using backend qdisk
libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk 
vdev=hdc spec.backend=unknown
libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=hdc, 
backend phy unsuitable as phys path not a block device
libxl: debug: libxl_device.c:184:disk_try_backend: Disk vdev=hdc, 
backend tap unsuitable because blktap not available
libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk 
vdev=hdc, using backend qdisk
libxl: debug: libxl_create.c:677:initiate_domain_create: running bootloader
libxl: debug: libxl_bootloader.c:321:libxl__bootloader_run: not a PV 
domain, skipping bootloader
libxl: debug: libxl_event.c:561:libxl__ev_xswatch_deregister: watch 
w=0x178aed0: deregister unregistered
libxl: debug: libxl_numa.c:435:libxl__get_numa_candidate: New best NUMA 
placement candidate found: nr_nodes=1, nr_cpus=2, nr_vcpus=4, 
free_memkb=2278
libxl: detail: libxl_dom.c:192:numa_place_domain: NUMA placement 
candidate with 1 nodes, 2 cpus and 2278 KB free selected
xc: detail: elf_parse_binary: phdr: paddr=0x100000 memsz=0xad98c
xc: detail: elf_parse_binary: memory: 0x100000 -> 0x1ad98c
xc: info: VIRTUAL MEMORY ARRANGEMENT:
   Loader:        0000000000100000->00000000001ad98c
   TOTAL:         0000000000000000->000000003f800000
   ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
   4KB PAGES: 0x0000000000000200
   2MB PAGES: 0x00000000000001fb
   1GB PAGES: 0x0000000000000000
xc: detail: elf_load_binary: phdr 0 at 0x0x7fbc63478000 -> 0x0x7fbc6351c803
libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk 
vdev=hda spec.backend=qdisk
libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk 
vdev=hdc spec.backend=qdisk
libxl: debug: libxl_dm.c:1134:libxl__spawn_local_dm: Spawning 
device-model /usr/lib/xen/bin/qemu-dm with arguments:
libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm: 
/usr/lib/xen/bin/qemu-dm
libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   -d
libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   12
libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   -domain-name
libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   WindowsXP
libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   -vnc
libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   192.168.1.2:0
libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   -vncunused
libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   -videoram
libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   8
libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   -boot
libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   dc
libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   -usb
libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   -usbdevice
libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   tablet
libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   -acpi
libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   -vcpus
libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   2
libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   -vcpu_avail
libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   0x03
libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   -net
libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   none
libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   -M
libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   xenfv
libxl: debug: libxl_event.c:512:libxl__ev_xswatch_register: watch 
w=0x178b108 wpath=/local/domain/0/device-model/12/state token=3/0: 
register slotnum=3
libxl: debug: libxl_create.c:1204:do_domain_create: ao 0x178ab50: 
inprogress: poller=0x178a350, flags=i
libxl: debug: libxl_event.c:457:watchfd_callback: watch w=0x178b108 
wpath=/local/domain/0/device-model/12/state token=3/0: event 
epath=/local/domain/0/device-model/12/state
libxl: debug: libxl_event.c:549:libxl__ev_xswatch_deregister: watch 
w=0x178b108 wpath=/local/domain/0/device-model/12/state token=3/0: 
deregister slotnum=3
libxl: error: libxl_dm.c:1203:device_model_spawn_outcome: domain 12 
device model: spawn failed (rc=-3)
libxl: debug: libxl_event.c:1667:libxl__ao_progress_report: ao 
0x178ab50: progress report: ignored
libxl: debug: libxl_event.c:1497:libxl__ao_complete: ao 0x178ab50: 
complete, rc=0
libxl: debug: libxl_event.c:1469:libxl__ao__destroy: ao 0x178ab50: destroy
Daemon running with PID 4480
xc: debug: hypercall buffer: total allocations:750 total releases:750
xc: debug: hypercall buffer: current allocations:0 maximum allocations:4
xc: debug: hypercall buffer: cache current size:4
xc: debug: hypercall buffer: cache hits:742 misses:4 toobig:4

My Windows XP HVM domU config is:

# XL domain configuration file for Windows XP Home Edition SP3 HVM domU
# Please refer to "man xl.cfg" for further explanations.
# See also docs/misc/xl-network-configuration.markdown and
# docs/misc/xl-disk-configuration.txt
# Written by Teo En Ming (Zhang Enming)
# Email: teo.en.ming@gmail.com
# Mobile Phone: +65-8369-2618
# Country: Singapore
# Date: 18 Mar 2012 Sun
name="WindowsXP"
builder="hvm"
vcpus=2
memory=1024
on_poweroff="destroy"
on_reboot="restart"
on_crash="destroy"
disk=[ 'format=raw, vdev=hda, access=rw, 
target=/etc/xen/images/windowsxp.img', 'format=raw, vdev=hdc, access=ro, 
devtype=cdrom, target=/home/teo-en-ming/windowsxp.iso' ]
#vif=[ 'bridge=eth0,type=ioemu,model=rtl8139' ]
#boot=[c|d|n]
#Selects the emulated virtual device to boot from. Options are hard disk 
(c), cd-rom (d) or network/PXE (n).
#Multiple options can be given and will be attempted in the order they 
are given. e.g. to boot from cd-rom
#but fallback to the hard disk you can give dc. The default is cd.
boot="dc"
acpi=1
#xen_platform_pci=1
#viridian=1
#stdvga=1
vnc=1
vnclisten="192.168.1.2"
vncdisplay=0
vncunused=1
vncpasswd=""
sdl=0
usb=1
usbdevice="tablet"
# Enable Xen VGA Passthrough
gfx_passthru=0
# VGA Passthrough Gigabyte Geforce GTX 560 1 GB GDDR5 PCI Express x16 
VGA card.
#pci = [ 
'01:00.0','01:00.1','00:1b.0','00:1a.0','00:1a.1','00:1a.2','00:1a.7','00:1d.0','00:1d.1','00:1d.2','00:1d.7' 
]
#pci = [ '01:00.0','01:00.1','00:1b.0' ]

# PCI Passthrough Intel HD Audio Controller.
#pci = [ '00:1b.0' ]
# PCI Passthrough all the USB Controllers.
# pci = [ 
'00:1a.0','00:1a.1','00:1a.2','00:1a.7','00:1d.0','00:1d.1','00:1d.2','00:1d.7' 
]

I am using Xen 4.3-unstable changeset 26004 and Linux dom0 kernel 3.6.1.

May I know what is the problem? Please advise.

Thank you very much.

-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 14 17:20:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Oct 2012 17:20:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNRqz-0000Mq-L2; Sun, 14 Oct 2012 17:19:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <singapore.mr.teo.en.ming@gmail.com>)
	id 1TNRqx-0000Me-6b; Sun, 14 Oct 2012 17:19:51 +0000
Received: from [85.158.137.99:12827] by server-14.bemta-3.messagelabs.com id
	2B/F1-17276-634FA705; Sun, 14 Oct 2012 17:19:50 +0000
X-Env-Sender: singapore.mr.teo.en.ming@gmail.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1350235186!21416200!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24526 invoked from network); 14 Oct 2012 17:19:48 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Oct 2012 17:19:48 -0000
Received: by mail-pb0-f45.google.com with SMTP id rp2so4248692pbb.32
	for <multiple recipients>; Sun, 14 Oct 2012 10:19:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=7mNBv1892Js2suRRftop+CIFsY33Jhgrq/4JadXYQKU=;
	b=vr12074FNrdGlY7vU2XVY/7Yc4g74mdflW5lZj4zsnPO0E4efsiEAxMZZMmUYmyqJM
	C/N+t0z5LR4Oh6yynfHhOmWR6s/KTmcrc4zJ4VkXudx18XvK0IPwcXp2twvjN8TqrGNm
	6S7otv/NM1kEyhoK7gdBQaqbQeBeiLepspvnp64lpUgKkFwbBclk0hcdrKZB1pBS1Jx7
	hE/MglaA+2dWJWM3JaGVVZ/lzD8sZa/anEFUxV9JQ+r8DG2vsNOPPzdkLlRrXo0OFicP
	X1BTwY8diE+YIB5ZL8yiHLsiW4KwIUKei7YLtYJA/A5F0cpVy65qo/Csup2cu3VlHKHr
	pxsA==
Received: by 10.68.216.74 with SMTP id oo10mr30921344pbc.92.1350235186099;
	Sun, 14 Oct 2012 10:19:46 -0700 (PDT)
Received: from [192.168.1.5] (cm152.gamma205.maxonline.com.sg.
	[202.156.205.152])
	by mx.google.com with ESMTPS id g1sm7693833paz.18.2012.10.14.10.19.43
	(version=SSLv3 cipher=OTHER); Sun, 14 Oct 2012 10:19:45 -0700 (PDT)
Message-ID: <507AF42D.8000401@gmail.com>
Date: Mon, 15 Oct 2012 01:19:41 +0800
From: "Teo En Ming (Zhang Enming)" <singapore.mr.teo.en.ming@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: "Teo En Ming (Zhang Enming)" <singapore.mr.teo.en.ming@gmail.com>
References: <507AF052.4040209@gmail.com>
In-Reply-To: <507AF052.4040209@gmail.com>
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>, konrad@kernel.org,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Unable to Start Windows XP HVM domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/15/2012 01:03 AM, Teo En Ming (Zhang Enming) wrote:
> Hi,
>
> I am unable to start Windows XP HVM domU in an X environment.
>
> Here is the error output:
>
> teo-en-ming@ubuntu-12041-amd64-server:/etc/xen$ sudo xl -vvv create 
> /etc/xen/windowsxp
> Parsing config from /etc/xen/windowsxp
> libxl: debug: libxl_create.c:1191:do_domain_create: ao 0x178ab50: 
> create: how=(nil) callback=(nil) poller=0x178a350
> libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk 
> vdev=hda spec.backend=unknown
> libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=hda, 
> backend phy unsuitable as phys path not a block device
> libxl: debug: libxl_device.c:184:disk_try_backend: Disk vdev=hda, 
> backend tap unsuitable because blktap not available
> libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk 
> vdev=hda, using backend qdisk
> libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk 
> vdev=hdc spec.backend=unknown
> libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=hdc, 
> backend phy unsuitable as phys path not a block device
> libxl: debug: libxl_device.c:184:disk_try_backend: Disk vdev=hdc, 
> backend tap unsuitable because blktap not available
> libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk 
> vdev=hdc, using backend qdisk
> libxl: debug: libxl_create.c:677:initiate_domain_create: running 
> bootloader
> libxl: debug: libxl_bootloader.c:321:libxl__bootloader_run: not a PV 
> domain, skipping bootloader
> libxl: debug: libxl_event.c:561:libxl__ev_xswatch_deregister: watch 
> w=0x178aed0: deregister unregistered
> libxl: debug: libxl_numa.c:435:libxl__get_numa_candidate: New best 
> NUMA placement candidate found: nr_nodes=1, nr_cpus=2, nr_vcpus=4, 
> free_memkb=2278
> libxl: detail: libxl_dom.c:192:numa_place_domain: NUMA placement 
> candidate with 1 nodes, 2 cpus and 2278 KB free selected
> xc: detail: elf_parse_binary: phdr: paddr=0x100000 memsz=0xad98c
> xc: detail: elf_parse_binary: memory: 0x100000 -> 0x1ad98c
> xc: info: VIRTUAL MEMORY ARRANGEMENT:
>   Loader:        0000000000100000->00000000001ad98c
>   TOTAL:         0000000000000000->000000003f800000
>   ENTRY ADDRESS: 0000000000100000
> xc: info: PHYSICAL MEMORY ALLOCATION:
>   4KB PAGES: 0x0000000000000200
>   2MB PAGES: 0x00000000000001fb
>   1GB PAGES: 0x0000000000000000
> xc: detail: elf_load_binary: phdr 0 at 0x0x7fbc63478000 -> 
> 0x0x7fbc6351c803
> libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk 
> vdev=hda spec.backend=qdisk
> libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk 
> vdev=hdc spec.backend=qdisk
> libxl: debug: libxl_dm.c:1134:libxl__spawn_local_dm: Spawning 
> device-model /usr/lib/xen/bin/qemu-dm with arguments:
> libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm: 
> /usr/lib/xen/bin/qemu-dm
> libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   -d
> libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   12
> libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm: -domain-name
> libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   WindowsXP
> libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   -vnc
> libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm: 192.168.1.2:0
> libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   -vncunused
> libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   -videoram
> libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   8
> libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   -boot
> libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   dc
> libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   -usb
> libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   -usbdevice
> libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   tablet
> libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   -acpi
> libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   -vcpus
> libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   2
> libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   -vcpu_avail
> libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   0x03
> libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   -net
> libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   none
> libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   -M
> libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   xenfv
> libxl: debug: libxl_event.c:512:libxl__ev_xswatch_register: watch 
> w=0x178b108 wpath=/local/domain/0/device-model/12/state token=3/0: 
> register slotnum=3
> libxl: debug: libxl_create.c:1204:do_domain_create: ao 0x178ab50: 
> inprogress: poller=0x178a350, flags=i
> libxl: debug: libxl_event.c:457:watchfd_callback: watch w=0x178b108 
> wpath=/local/domain/0/device-model/12/state token=3/0: event 
> epath=/local/domain/0/device-model/12/state
> libxl: debug: libxl_event.c:549:libxl__ev_xswatch_deregister: watch 
> w=0x178b108 wpath=/local/domain/0/device-model/12/state token=3/0: 
> deregister slotnum=3
> libxl: error: libxl_dm.c:1203:device_model_spawn_outcome: domain 12 
> device model: spawn failed (rc=-3)
> libxl: debug: libxl_event.c:1667:libxl__ao_progress_report: ao 
> 0x178ab50: progress report: ignored
> libxl: debug: libxl_event.c:1497:libxl__ao_complete: ao 0x178ab50: 
> complete, rc=0
> libxl: debug: libxl_event.c:1469:libxl__ao__destroy: ao 0x178ab50: 
> destroy
> Daemon running with PID 4480
> xc: debug: hypercall buffer: total allocations:750 total releases:750
> xc: debug: hypercall buffer: current allocations:0 maximum allocations:4
> xc: debug: hypercall buffer: cache current size:4
> xc: debug: hypercall buffer: cache hits:742 misses:4 toobig:4
>
> My Windows XP HVM domU config is:
>
> # XL domain configuration file for Windows XP Home Edition SP3 HVM domU
> # Please refer to "man xl.cfg" for further explanations.
> # See also docs/misc/xl-network-configuration.markdown and
> # docs/misc/xl-disk-configuration.txt
> # Written by Teo En Ming (Zhang Enming)
> # Email: teo.en.ming@gmail.com
> # Mobile Phone: +65-8369-2618
> # Country: Singapore
> # Date: 18 Mar 2012 Sun
> name="WindowsXP"
> builder="hvm"
> vcpus=2
> memory=1024
> on_poweroff="destroy"
> on_reboot="restart"
> on_crash="destroy"
> disk=[ 'format=raw, vdev=hda, access=rw, 
> target=/etc/xen/images/windowsxp.img', 'format=raw, vdev=hdc, 
> access=ro, devtype=cdrom, target=/home/teo-en-ming/windowsxp.iso' ]
> #vif=[ 'bridge=eth0,type=ioemu,model=rtl8139' ]
> #boot=[c|d|n]
> #Selects the emulated virtual device to boot from. Options are hard 
> disk (c), cd-rom (d) or network/PXE (n).
> #Multiple options can be given and will be attempted in the order they 
> are given. e.g. to boot from cd-rom
> #but fallback to the hard disk you can give dc. The default is cd.
> boot="dc"
> acpi=1
> #xen_platform_pci=1
> #viridian=1
> #stdvga=1
> vnc=1
> vnclisten="192.168.1.2"
> vncdisplay=0
> vncunused=1
> vncpasswd=""
> sdl=0
> usb=1
> usbdevice="tablet"
> # Enable Xen VGA Passthrough
> gfx_passthru=0
> # VGA Passthrough Gigabyte Geforce GTX 560 1 GB GDDR5 PCI Express x16 
> VGA card.
> #pci = [ 
> '01:00.0','01:00.1','00:1b.0','00:1a.0','00:1a.1','00:1a.2','00:1a.7','00:1d.0','00:1d.1','00:1d.2','00:1d.7' 
> ]
> #pci = [ '01:00.0','01:00.1','00:1b.0' ]
>
> # PCI Passthrough Intel HD Audio Controller.
> #pci = [ '00:1b.0' ]
> # PCI Passthrough all the USB Controllers.
> # pci = [ 
> '00:1a.0','00:1a.1','00:1a.2','00:1a.7','00:1d.0','00:1d.1','00:1d.2','00:1d.7' 
> ]
>
> I am using Xen 4.3-unstable changeset 26004 and Linux dom0 kernel 3.6.1.
>
> May I know what is the problem? Please advise.
>
> Thank you very much.
>

I have pasted troubleshooting logs here:

qemu-dm-WindowsXP.log:

domid: 12
-videoram option does not work with cirrus vga device model. Videoram 
set to 4M.
Strip off blktap sub-type prefix to /etc/xen/images/windowsxp.img (drv 
'aio')
Using file /etc/xen/images/windowsxp.img in read-write mode
Strip off blktap sub-type prefix to /home/teo-en-ming/windowsxp.iso (drv 
'aio')
Using file /home/teo-en-ming/windowsxp.iso in read-only mode
Watching /local/domain/0/device-model/12/logdirty/cmd
Watching /local/domain/0/device-model/12/command
Watching /local/domain/12/cpu
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = 536562e3-8bbb-4d20-bcd4-4de60e86b0a0
populating video RAM at ff000000
mapping video RAM from ff000000
Register xen platform.
Done register platform.
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw 
state.
xs_read(/local/domain/0/device-model/12/xen_extended_power_mgmt): read error
bind() failed

xl-WindowsXP.log:

Waiting for domain WindowsXP (domid 12) to die [pid 4481]
libxl: debug: libxl_event.c:512:libxl__ev_xswatch_register: watch 
w=0x178bd00 wpath=@releaseDomain token=3/0: register slotnum=3
libxl: debug: libxl_event.c:512:libxl__ev_xswatch_register: watch 
w=0x178a970 wpath=/local/domain/12/device/vbd/5632/eject token=2/1: 
register slotnum=2
libxl: debug: libxl_event.c:457:watchfd_callback: watch w=0x178bd00 
wpath=@releaseDomain token=3/0: event epath=@releaseDomain
libxl: debug: libxl.c:997:domain_death_xswatch_callback: 
[evg=0x1789b90:12] from domid=12 nentries=1 rc=1
libxl: debug: libxl.c:1008:domain_death_xswatch_callback: 
[evg=0x1789b90:12]   got=domaininfos[0] got->domain=12
libxl: debug: libxl.c:1035:domain_death_xswatch_callback:  exists 
shutdown_reported=0 dominf.flags=ffff0002
libxl: debug: libxl.c:1001:domain_death_xswatch_callback: [evg=0] all 
reported
libxl: debug: libxl.c:1064:domain_death_xswatch_callback: domain death 
search done
libxl: debug: libxl_event.c:457:watchfd_callback: watch w=0x178a970 
wpath=/local/domain/12/device/vbd/5632/eject token=2/1: event 
epath=/local/domain/12/device/vbd/5632/eject
libxl: debug: libxl_event.c:457:watchfd_callback: watch w=0x178a970 
wpath=/local/domain/12/device/vbd/5632/eject token=2/1: event 
epath=/local/domain/12/device/vbd/5632/eject
libxl: debug: libxl_event.c:457:watchfd_callback: watch w=0x178a970 
wpath=/local/domain/12/device/vbd/5632/eject token=2/1: event 
epath=/local/domain/12/device/vbd/5632/eject
libxl: debug: libxl_event.c:457:watchfd_callback: watch w=0x178a970 
wpath=/local/domain/12/device/vbd/5632/eject token=2/1: event 
epath=/local/domain/12/device/vbd/5632/eject
libxl: debug: libxl_event.c:457:watchfd_callback: watch w=0x178bd00 
wpath=@releaseDomain token=3/0: event epath=@releaseDomain
libxl: debug: libxl.c:997:domain_death_xswatch_callback: 
[evg=0x1789b90:12] from domid=12 nentries=1 rc=1
libxl: debug: libxl.c:1008:domain_death_xswatch_callback: 
[evg=0x1789b90:12]   got=domaininfos[0] got->domain=12
libxl: debug: libxl.c:1035:domain_death_xswatch_callback:  exists 
shutdown_reported=0 dominf.flags=ffff000b
libxl: debug: libxl.c:953:domain_death_occurred: dying
libxl: debug: libxl.c:1001:domain_death_xswatch_callback: [evg=0] all 
reported
libxl: debug: libxl.c:1064:domain_death_xswatch_callback: domain death 
search done
Domain 12 has been destroyed.
libxl: debug: libxl_event.c:549:libxl__ev_xswatch_deregister: watch 
w=0x178bd00 wpath=@releaseDomain token=3/0: deregister slotnum=3
libxl: debug: libxl_event.c:549:libxl__ev_xswatch_deregister: watch 
w=0x178a970 wpath=/local/domain/12/device/vbd/5632/eject token=2/1: 
deregister slotnum=2
xc: debug: hypercall buffer: total allocations:4 total releases:4
xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
xc: debug: hypercall buffer: cache current size:2
xc: debug: hypercall buffer: cache hits:2 misses:2 toobig:0

-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 14 17:20:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Oct 2012 17:20:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNRqz-0000Mq-L2; Sun, 14 Oct 2012 17:19:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <singapore.mr.teo.en.ming@gmail.com>)
	id 1TNRqx-0000Me-6b; Sun, 14 Oct 2012 17:19:51 +0000
Received: from [85.158.137.99:12827] by server-14.bemta-3.messagelabs.com id
	2B/F1-17276-634FA705; Sun, 14 Oct 2012 17:19:50 +0000
X-Env-Sender: singapore.mr.teo.en.ming@gmail.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1350235186!21416200!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24526 invoked from network); 14 Oct 2012 17:19:48 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Oct 2012 17:19:48 -0000
Received: by mail-pb0-f45.google.com with SMTP id rp2so4248692pbb.32
	for <multiple recipients>; Sun, 14 Oct 2012 10:19:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=7mNBv1892Js2suRRftop+CIFsY33Jhgrq/4JadXYQKU=;
	b=vr12074FNrdGlY7vU2XVY/7Yc4g74mdflW5lZj4zsnPO0E4efsiEAxMZZMmUYmyqJM
	C/N+t0z5LR4Oh6yynfHhOmWR6s/KTmcrc4zJ4VkXudx18XvK0IPwcXp2twvjN8TqrGNm
	6S7otv/NM1kEyhoK7gdBQaqbQeBeiLepspvnp64lpUgKkFwbBclk0hcdrKZB1pBS1Jx7
	hE/MglaA+2dWJWM3JaGVVZ/lzD8sZa/anEFUxV9JQ+r8DG2vsNOPPzdkLlRrXo0OFicP
	X1BTwY8diE+YIB5ZL8yiHLsiW4KwIUKei7YLtYJA/A5F0cpVy65qo/Csup2cu3VlHKHr
	pxsA==
Received: by 10.68.216.74 with SMTP id oo10mr30921344pbc.92.1350235186099;
	Sun, 14 Oct 2012 10:19:46 -0700 (PDT)
Received: from [192.168.1.5] (cm152.gamma205.maxonline.com.sg.
	[202.156.205.152])
	by mx.google.com with ESMTPS id g1sm7693833paz.18.2012.10.14.10.19.43
	(version=SSLv3 cipher=OTHER); Sun, 14 Oct 2012 10:19:45 -0700 (PDT)
Message-ID: <507AF42D.8000401@gmail.com>
Date: Mon, 15 Oct 2012 01:19:41 +0800
From: "Teo En Ming (Zhang Enming)" <singapore.mr.teo.en.ming@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: "Teo En Ming (Zhang Enming)" <singapore.mr.teo.en.ming@gmail.com>
References: <507AF052.4040209@gmail.com>
In-Reply-To: <507AF052.4040209@gmail.com>
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>, konrad@kernel.org,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Unable to Start Windows XP HVM domU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/15/2012 01:03 AM, Teo En Ming (Zhang Enming) wrote:
> Hi,
>
> I am unable to start Windows XP HVM domU in an X environment.
>
> Here is the error output:
>
> teo-en-ming@ubuntu-12041-amd64-server:/etc/xen$ sudo xl -vvv create 
> /etc/xen/windowsxp
> Parsing config from /etc/xen/windowsxp
> libxl: debug: libxl_create.c:1191:do_domain_create: ao 0x178ab50: 
> create: how=(nil) callback=(nil) poller=0x178a350
> libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk 
> vdev=hda spec.backend=unknown
> libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=hda, 
> backend phy unsuitable as phys path not a block device
> libxl: debug: libxl_device.c:184:disk_try_backend: Disk vdev=hda, 
> backend tap unsuitable because blktap not available
> libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk 
> vdev=hda, using backend qdisk
> libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk 
> vdev=hdc spec.backend=unknown
> libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=hdc, 
> backend phy unsuitable as phys path not a block device
> libxl: debug: libxl_device.c:184:disk_try_backend: Disk vdev=hdc, 
> backend tap unsuitable because blktap not available
> libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk 
> vdev=hdc, using backend qdisk
> libxl: debug: libxl_create.c:677:initiate_domain_create: running 
> bootloader
> libxl: debug: libxl_bootloader.c:321:libxl__bootloader_run: not a PV 
> domain, skipping bootloader
> libxl: debug: libxl_event.c:561:libxl__ev_xswatch_deregister: watch 
> w=0x178aed0: deregister unregistered
> libxl: debug: libxl_numa.c:435:libxl__get_numa_candidate: New best 
> NUMA placement candidate found: nr_nodes=1, nr_cpus=2, nr_vcpus=4, 
> free_memkb=2278
> libxl: detail: libxl_dom.c:192:numa_place_domain: NUMA placement 
> candidate with 1 nodes, 2 cpus and 2278 KB free selected
> xc: detail: elf_parse_binary: phdr: paddr=0x100000 memsz=0xad98c
> xc: detail: elf_parse_binary: memory: 0x100000 -> 0x1ad98c
> xc: info: VIRTUAL MEMORY ARRANGEMENT:
>   Loader:        0000000000100000->00000000001ad98c
>   TOTAL:         0000000000000000->000000003f800000
>   ENTRY ADDRESS: 0000000000100000
> xc: info: PHYSICAL MEMORY ALLOCATION:
>   4KB PAGES: 0x0000000000000200
>   2MB PAGES: 0x00000000000001fb
>   1GB PAGES: 0x0000000000000000
> xc: detail: elf_load_binary: phdr 0 at 0x0x7fbc63478000 -> 
> 0x0x7fbc6351c803
> libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk 
> vdev=hda spec.backend=qdisk
> libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk 
> vdev=hdc spec.backend=qdisk
> libxl: debug: libxl_dm.c:1134:libxl__spawn_local_dm: Spawning 
> device-model /usr/lib/xen/bin/qemu-dm with arguments:
> libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm: 
> /usr/lib/xen/bin/qemu-dm
> libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   -d
> libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   12
> libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm: -domain-name
> libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   WindowsXP
> libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   -vnc
> libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm: 192.168.1.2:0
> libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   -vncunused
> libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   -videoram
> libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   8
> libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   -boot
> libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   dc
> libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   -usb
> libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   -usbdevice
> libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   tablet
> libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   -acpi
> libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   -vcpus
> libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   2
> libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   -vcpu_avail
> libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   0x03
> libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   -net
> libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   none
> libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   -M
> libxl: debug: libxl_dm.c:1136:libxl__spawn_local_dm:   xenfv
> libxl: debug: libxl_event.c:512:libxl__ev_xswatch_register: watch 
> w=0x178b108 wpath=/local/domain/0/device-model/12/state token=3/0: 
> register slotnum=3
> libxl: debug: libxl_create.c:1204:do_domain_create: ao 0x178ab50: 
> inprogress: poller=0x178a350, flags=i
> libxl: debug: libxl_event.c:457:watchfd_callback: watch w=0x178b108 
> wpath=/local/domain/0/device-model/12/state token=3/0: event 
> epath=/local/domain/0/device-model/12/state
> libxl: debug: libxl_event.c:549:libxl__ev_xswatch_deregister: watch 
> w=0x178b108 wpath=/local/domain/0/device-model/12/state token=3/0: 
> deregister slotnum=3
> libxl: error: libxl_dm.c:1203:device_model_spawn_outcome: domain 12 
> device model: spawn failed (rc=-3)
> libxl: debug: libxl_event.c:1667:libxl__ao_progress_report: ao 
> 0x178ab50: progress report: ignored
> libxl: debug: libxl_event.c:1497:libxl__ao_complete: ao 0x178ab50: 
> complete, rc=0
> libxl: debug: libxl_event.c:1469:libxl__ao__destroy: ao 0x178ab50: 
> destroy
> Daemon running with PID 4480
> xc: debug: hypercall buffer: total allocations:750 total releases:750
> xc: debug: hypercall buffer: current allocations:0 maximum allocations:4
> xc: debug: hypercall buffer: cache current size:4
> xc: debug: hypercall buffer: cache hits:742 misses:4 toobig:4
>
> My Windows XP HVM domU config is:
>
> # XL domain configuration file for Windows XP Home Edition SP3 HVM domU
> # Please refer to "man xl.cfg" for further explanations.
> # See also docs/misc/xl-network-configuration.markdown and
> # docs/misc/xl-disk-configuration.txt
> # Written by Teo En Ming (Zhang Enming)
> # Email: teo.en.ming@gmail.com
> # Mobile Phone: +65-8369-2618
> # Country: Singapore
> # Date: 18 Mar 2012 Sun
> name="WindowsXP"
> builder="hvm"
> vcpus=2
> memory=1024
> on_poweroff="destroy"
> on_reboot="restart"
> on_crash="destroy"
> disk=[ 'format=raw, vdev=hda, access=rw, 
> target=/etc/xen/images/windowsxp.img', 'format=raw, vdev=hdc, 
> access=ro, devtype=cdrom, target=/home/teo-en-ming/windowsxp.iso' ]
> #vif=[ 'bridge=eth0,type=ioemu,model=rtl8139' ]
> #boot=[c|d|n]
> #Selects the emulated virtual device to boot from. Options are hard 
> disk (c), cd-rom (d) or network/PXE (n).
> #Multiple options can be given and will be attempted in the order they 
> are given. e.g. to boot from cd-rom
> #but fallback to the hard disk you can give dc. The default is cd.
> boot="dc"
> acpi=1
> #xen_platform_pci=1
> #viridian=1
> #stdvga=1
> vnc=1
> vnclisten="192.168.1.2"
> vncdisplay=0
> vncunused=1
> vncpasswd=""
> sdl=0
> usb=1
> usbdevice="tablet"
> # Enable Xen VGA Passthrough
> gfx_passthru=0
> # VGA Passthrough Gigabyte Geforce GTX 560 1 GB GDDR5 PCI Express x16 
> VGA card.
> #pci = [ 
> '01:00.0','01:00.1','00:1b.0','00:1a.0','00:1a.1','00:1a.2','00:1a.7','00:1d.0','00:1d.1','00:1d.2','00:1d.7' 
> ]
> #pci = [ '01:00.0','01:00.1','00:1b.0' ]
>
> # PCI Passthrough Intel HD Audio Controller.
> #pci = [ '00:1b.0' ]
> # PCI Passthrough all the USB Controllers.
> # pci = [ 
> '00:1a.0','00:1a.1','00:1a.2','00:1a.7','00:1d.0','00:1d.1','00:1d.2','00:1d.7' 
> ]
>
> I am using Xen 4.3-unstable changeset 26004 and Linux dom0 kernel 3.6.1.
>
> May I know what is the problem? Please advise.
>
> Thank you very much.
>

I have pasted troubleshooting logs here:

qemu-dm-WindowsXP.log:

domid: 12
-videoram option does not work with cirrus vga device model. Videoram 
set to 4M.
Strip off blktap sub-type prefix to /etc/xen/images/windowsxp.img (drv 
'aio')
Using file /etc/xen/images/windowsxp.img in read-write mode
Strip off blktap sub-type prefix to /home/teo-en-ming/windowsxp.iso (drv 
'aio')
Using file /home/teo-en-ming/windowsxp.iso in read-only mode
Watching /local/domain/0/device-model/12/logdirty/cmd
Watching /local/domain/0/device-model/12/command
Watching /local/domain/12/cpu
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = 536562e3-8bbb-4d20-bcd4-4de60e86b0a0
populating video RAM at ff000000
mapping video RAM from ff000000
Register xen platform.
Done register platform.
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw 
state.
xs_read(/local/domain/0/device-model/12/xen_extended_power_mgmt): read error
bind() failed

xl-WindowsXP.log:

Waiting for domain WindowsXP (domid 12) to die [pid 4481]
libxl: debug: libxl_event.c:512:libxl__ev_xswatch_register: watch 
w=0x178bd00 wpath=@releaseDomain token=3/0: register slotnum=3
libxl: debug: libxl_event.c:512:libxl__ev_xswatch_register: watch 
w=0x178a970 wpath=/local/domain/12/device/vbd/5632/eject token=2/1: 
register slotnum=2
libxl: debug: libxl_event.c:457:watchfd_callback: watch w=0x178bd00 
wpath=@releaseDomain token=3/0: event epath=@releaseDomain
libxl: debug: libxl.c:997:domain_death_xswatch_callback: 
[evg=0x1789b90:12] from domid=12 nentries=1 rc=1
libxl: debug: libxl.c:1008:domain_death_xswatch_callback: 
[evg=0x1789b90:12]   got=domaininfos[0] got->domain=12
libxl: debug: libxl.c:1035:domain_death_xswatch_callback:  exists 
shutdown_reported=0 dominf.flags=ffff0002
libxl: debug: libxl.c:1001:domain_death_xswatch_callback: [evg=0] all 
reported
libxl: debug: libxl.c:1064:domain_death_xswatch_callback: domain death 
search done
libxl: debug: libxl_event.c:457:watchfd_callback: watch w=0x178a970 
wpath=/local/domain/12/device/vbd/5632/eject token=2/1: event 
epath=/local/domain/12/device/vbd/5632/eject
libxl: debug: libxl_event.c:457:watchfd_callback: watch w=0x178a970 
wpath=/local/domain/12/device/vbd/5632/eject token=2/1: event 
epath=/local/domain/12/device/vbd/5632/eject
libxl: debug: libxl_event.c:457:watchfd_callback: watch w=0x178a970 
wpath=/local/domain/12/device/vbd/5632/eject token=2/1: event 
epath=/local/domain/12/device/vbd/5632/eject
libxl: debug: libxl_event.c:457:watchfd_callback: watch w=0x178a970 
wpath=/local/domain/12/device/vbd/5632/eject token=2/1: event 
epath=/local/domain/12/device/vbd/5632/eject
libxl: debug: libxl_event.c:457:watchfd_callback: watch w=0x178bd00 
wpath=@releaseDomain token=3/0: event epath=@releaseDomain
libxl: debug: libxl.c:997:domain_death_xswatch_callback: 
[evg=0x1789b90:12] from domid=12 nentries=1 rc=1
libxl: debug: libxl.c:1008:domain_death_xswatch_callback: 
[evg=0x1789b90:12]   got=domaininfos[0] got->domain=12
libxl: debug: libxl.c:1035:domain_death_xswatch_callback:  exists 
shutdown_reported=0 dominf.flags=ffff000b
libxl: debug: libxl.c:953:domain_death_occurred: dying
libxl: debug: libxl.c:1001:domain_death_xswatch_callback: [evg=0] all 
reported
libxl: debug: libxl.c:1064:domain_death_xswatch_callback: domain death 
search done
Domain 12 has been destroyed.
libxl: debug: libxl_event.c:549:libxl__ev_xswatch_deregister: watch 
w=0x178bd00 wpath=@releaseDomain token=3/0: deregister slotnum=3
libxl: debug: libxl_event.c:549:libxl__ev_xswatch_deregister: watch 
w=0x178a970 wpath=/local/domain/12/device/vbd/5632/eject token=2/1: 
deregister slotnum=2
xc: debug: hypercall buffer: total allocations:4 total releases:4
xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
xc: debug: hypercall buffer: cache current size:2
xc: debug: hypercall buffer: cache hits:2 misses:2 toobig:0

-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 14 22:47:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Oct 2012 22:47:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNWxj-0002qj-I9; Sun, 14 Oct 2012 22:47:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1TNWxh-0002qb-Va
	for xen-devel@lists.xen.org; Sun, 14 Oct 2012 22:47:10 +0000
Received: from [85.158.139.83:19328] by server-16.bemta-5.messagelabs.com id
	10/41-10155-DE04B705; Sun, 14 Oct 2012 22:47:09 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-9.tower-182.messagelabs.com!1350254828!34147189!1
X-Originating-IP: [78.47.43.170]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11736 invoked from network); 14 Oct 2012 22:47:08 -0000
Received: from mail.vido.info (HELO mail.vido.info) (78.47.43.170)
	by server-9.tower-182.messagelabs.com with SMTP;
	14 Oct 2012 22:47:08 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id 28D8ED342A5;
	Mon, 15 Oct 2012 00:47:08 +0200 (CEST)
X-Virus-Scanned: by amavis at mail.vido.info
Received: from mail.vido.info ([127.0.0.1])
	by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id uuPSOtg69TUs; Mon, 15 Oct 2012 00:47:06 +0200 (CEST)
Received: from pc.localnet
	(HSI-KBW-37-49-87-213.hsi14.kabel-badenwuerttemberg.de
	[37.49.87.213])
	by mail.vido.info (Postfix) with ESMTPSA id 02C82D34202;
	Mon, 15 Oct 2012 00:47:05 +0200 (CEST)
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT Service
To: xen-devel@lists.xen.org
Date: Mon, 15 Oct 2012 00:47:04 +0200
User-Agent: KMail/1.13.7 (Linux/3.6.0-rc5; KDE/4.8.4; x86_64; ; )
References: <BLU0-SMTP46659547706BEDEFF6CAD76A5720@phx.gbl>
In-Reply-To: <BLU0-SMTP46659547706BEDEFF6CAD76A5720@phx.gbl>
MIME-Version: 1.0
Message-Id: <201210150047.05039.tobias.geiger@vido.info>
Cc: Ferdinand =?iso-8859-15?q?N=F6lscher?= <ferdinand@outlook.com>
Subject: Re: [Xen-devel] Xen primary VGA pass through problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Am Sonntag 14 Oktober 2012, 12:09:14 schrieb Ferdinand N=F6lscher:
> Hi!
> =

> Recently, I tried setting up VGA pass through with my machine. The set
> up is as follows:
> I have two AMD vga adapters - I want to pass through the second one.
> =

> I compiled xen 4.2 from source and set everything up.
> Attached to this message, you can find my windows 7 domU configuration
> file.
> =

> Whenever I want to pass through the device, I use "xl pci-assignable-add
> BDF" to unbind the adapter, before I create the domU. Pciback is loaded
> as module and is not compiled statically in the kernel.
> =

> Unless I do not specify "gfx_passthru =3D 1" in my configuration file,
> this works fine. The vga adapter gets detected and I can use it as
> secondary vga, with very limited performance.
> If I do set "gfx_passthru =3D 1" the domU doesnt boot at all. It just
> switches state from "r" (for running) to "-----" (which is nothing, i
> guess?) every few seconds. I can't find anything in the logs indicating
> an error.
> =

> Any ideas on how to fix that?
> =

> kind regards,
> Ferdinand

Hi Ferdinand,

can you try with gfx_passthru =3D 0 and eject the device after booting domu?
the secondary amd should show up within the devicemanager icon in the taskb=
ar, =

there you can eject it.

Here this trick helps for the poor performance problem - although this only =

shows up after a domU reboot - performance is fine until the first domu reb=
oot =

here, so i wonder if this tricks helps with our scenario...

Greetings
Tobias

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 14 22:47:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 14 Oct 2012 22:47:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNWxj-0002qj-I9; Sun, 14 Oct 2012 22:47:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1TNWxh-0002qb-Va
	for xen-devel@lists.xen.org; Sun, 14 Oct 2012 22:47:10 +0000
Received: from [85.158.139.83:19328] by server-16.bemta-5.messagelabs.com id
	10/41-10155-DE04B705; Sun, 14 Oct 2012 22:47:09 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-9.tower-182.messagelabs.com!1350254828!34147189!1
X-Originating-IP: [78.47.43.170]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11736 invoked from network); 14 Oct 2012 22:47:08 -0000
Received: from mail.vido.info (HELO mail.vido.info) (78.47.43.170)
	by server-9.tower-182.messagelabs.com with SMTP;
	14 Oct 2012 22:47:08 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id 28D8ED342A5;
	Mon, 15 Oct 2012 00:47:08 +0200 (CEST)
X-Virus-Scanned: by amavis at mail.vido.info
Received: from mail.vido.info ([127.0.0.1])
	by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id uuPSOtg69TUs; Mon, 15 Oct 2012 00:47:06 +0200 (CEST)
Received: from pc.localnet
	(HSI-KBW-37-49-87-213.hsi14.kabel-badenwuerttemberg.de
	[37.49.87.213])
	by mail.vido.info (Postfix) with ESMTPSA id 02C82D34202;
	Mon, 15 Oct 2012 00:47:05 +0200 (CEST)
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT Service
To: xen-devel@lists.xen.org
Date: Mon, 15 Oct 2012 00:47:04 +0200
User-Agent: KMail/1.13.7 (Linux/3.6.0-rc5; KDE/4.8.4; x86_64; ; )
References: <BLU0-SMTP46659547706BEDEFF6CAD76A5720@phx.gbl>
In-Reply-To: <BLU0-SMTP46659547706BEDEFF6CAD76A5720@phx.gbl>
MIME-Version: 1.0
Message-Id: <201210150047.05039.tobias.geiger@vido.info>
Cc: Ferdinand =?iso-8859-15?q?N=F6lscher?= <ferdinand@outlook.com>
Subject: Re: [Xen-devel] Xen primary VGA pass through problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Am Sonntag 14 Oktober 2012, 12:09:14 schrieb Ferdinand N=F6lscher:
> Hi!
> =

> Recently, I tried setting up VGA pass through with my machine. The set
> up is as follows:
> I have two AMD vga adapters - I want to pass through the second one.
> =

> I compiled xen 4.2 from source and set everything up.
> Attached to this message, you can find my windows 7 domU configuration
> file.
> =

> Whenever I want to pass through the device, I use "xl pci-assignable-add
> BDF" to unbind the adapter, before I create the domU. Pciback is loaded
> as module and is not compiled statically in the kernel.
> =

> Unless I do not specify "gfx_passthru =3D 1" in my configuration file,
> this works fine. The vga adapter gets detected and I can use it as
> secondary vga, with very limited performance.
> If I do set "gfx_passthru =3D 1" the domU doesnt boot at all. It just
> switches state from "r" (for running) to "-----" (which is nothing, i
> guess?) every few seconds. I can't find anything in the logs indicating
> an error.
> =

> Any ideas on how to fix that?
> =

> kind regards,
> Ferdinand

Hi Ferdinand,

can you try with gfx_passthru =3D 0 and eject the device after booting domu?
the secondary amd should show up within the devicemanager icon in the taskb=
ar, =

there you can eject it.

Here this trick helps for the poor performance problem - although this only =

shows up after a domU reboot - performance is fine until the first domu reb=
oot =

here, so i wonder if this tricks helps with our scenario...

Greetings
Tobias

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 04:53:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 04:53:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNcfl-0000Vv-TZ; Mon, 15 Oct 2012 04:53:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TNcfk-0000Vq-88
	for xen-devel@lists.xensource.com; Mon, 15 Oct 2012 04:53:00 +0000
Received: from [85.158.138.51:7395] by server-3.bemta-3.messagelabs.com id
	4F/11-09368-AA69B705; Mon, 15 Oct 2012 04:52:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1350276778!15658536!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxNzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28619 invoked from network); 15 Oct 2012 04:52:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 04:52:58 -0000
X-IronPort-AV: E=Sophos;i="4.80,586,1344211200"; d="scan'208";a="15158447"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 04:52:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Mon, 15 Oct 2012 05:52:58 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1TNcfh-0000PD-M7;
	Mon, 15 Oct 2012 04:52:57 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TNcfh-0002cx-FR;
	Mon, 15 Oct 2012 05:52:57 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13962-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 15 Oct 2012 05:52:57 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13962: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13962 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13962/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13960
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13960
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13960
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13960

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  e0e1350dfe9b
baseline version:
 xen                  e0e1350dfe9b

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 04:53:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 04:53:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNcfl-0000Vv-TZ; Mon, 15 Oct 2012 04:53:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TNcfk-0000Vq-88
	for xen-devel@lists.xensource.com; Mon, 15 Oct 2012 04:53:00 +0000
Received: from [85.158.138.51:7395] by server-3.bemta-3.messagelabs.com id
	4F/11-09368-AA69B705; Mon, 15 Oct 2012 04:52:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1350276778!15658536!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxNzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28619 invoked from network); 15 Oct 2012 04:52:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 04:52:58 -0000
X-IronPort-AV: E=Sophos;i="4.80,586,1344211200"; d="scan'208";a="15158447"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 04:52:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Mon, 15 Oct 2012 05:52:58 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1TNcfh-0000PD-M7;
	Mon, 15 Oct 2012 04:52:57 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TNcfh-0002cx-FR;
	Mon, 15 Oct 2012 05:52:57 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13962-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 15 Oct 2012 05:52:57 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13962: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13962 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13962/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13960
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13960
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13960
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13960

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  e0e1350dfe9b
baseline version:
 xen                  e0e1350dfe9b

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 06:44:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 06:44:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNePD-0001CD-JZ; Mon, 15 Oct 2012 06:44:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xinxinjin89@gmail.com>) id 1TNePC-0001C8-NF
	for Xen-devel@lists.xen.org; Mon, 15 Oct 2012 06:44:02 +0000
Received: from [85.158.137.99:61647] by server-1.bemta-3.messagelabs.com id
	C1/2E-31728-1B0BB705; Mon, 15 Oct 2012 06:44:01 +0000
X-Env-Sender: xinxinjin89@gmail.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1350283439!21571118!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26987 invoked from network); 15 Oct 2012 06:44:00 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 06:44:00 -0000
Received: by mail-qc0-f173.google.com with SMTP id b12so4769142qca.32
	for <Xen-devel@lists.xen.org>; Sun, 14 Oct 2012 23:43:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=oy1NflWi73zs6HpdybsJhQsTO2RLaLRYICs31nf1u8E=;
	b=aCYVL6SEDzUw/MvnZR17Z4aEeZewjBWJ4kBNES5NqhKu1KyW0hjuAEfatC4QgXdocR
	p6D+ahu1BJfDU9HfvCSDVFRklXR9xDRyMILtT4CO4PxSQ2WVHZo13FVd3ye6AjuFysGr
	R4bpudehWKDwHMeeWmeUVRS2nY9obJzRQi2MiCdqVukCL9NaZjniM9h4aGI07bhVqb0R
	HwjiJ//ZJ6bhEQy54BpzuB8Hx+5GJHnU8iUX2oOCeq0m+uBaCzHi+BWv3kgOL3IlBRyP
	NomjtA/3huuXRFEtIWfM0c7mQbYkyFRM1MXrBqA62BQJUgw9TH85N88Ip1m9sXsBNXfY
	u2AA==
MIME-Version: 1.0
Received: by 10.229.77.21 with SMTP id e21mr5249606qck.70.1350283439185; Sun,
	14 Oct 2012 23:43:59 -0700 (PDT)
Received: by 10.229.74.9 with HTTP; Sun, 14 Oct 2012 23:43:58 -0700 (PDT)
Date: Sun, 14 Oct 2012 23:43:58 -0700
Message-ID: <CAJJWZcwhKx6Fz6R9atAUbOSOuVRzRg8Dc8tOO2DLFUNcp5rZwA@mail.gmail.com>
From: Xinxin Jin <xinxinjin89@gmail.com>
To: Xen-devel@lists.xen.org
Subject: [Xen-devel] put_page in ptwr_do_page_fault
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0646616157076212817=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0646616157076212817==
Content-Type: multipart/alternative; boundary=002354333626bd1ea404cc135c33

--002354333626bd1ea404cc135c33
Content-Type: text/plain; charset=ISO-8859-1

Hi all,
I am trying to understand write page table handler for PV guests. I got the
core of ptwr_do_page_fault is x86_emulate() which will emulate the write
operation in Xen. But why after that Xen calls  put_page() to free the page
mapped to the PTE ? The code snapshot is as follows:

int ptwr_do_page_fault(struct vcpu *v, unsigned long addr,
                       struct cpu_user_regs *regs)
{
    struct domain *d = v->domain;
    struct page_info *page;
    l1_pgentry_t      pte;
    struct ptwr_emulate_ctxt ptwr_ctxt;
    int rc;

    /* Attempt to read the PTE that maps the VA being accessed. */
    guest_get_eff_l1e(v, addr, &pte);

    ......

    page = l1e_get_page(pte);

    ......

    rc = x86_emulate(&ptwr_ctxt.ctxt, &ptwr_emulate_ops);

    page_unlock(page);
    put_page(page);

    ......
}

Thanks a lot,
-- 
Xinxin

--002354333626bd1ea404cc135c33
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div><div>Hi all,</div><div>I am trying to understand write page table hand=
ler for PV guests. I got the core of ptwr_do_page_fault is x86_emulate() wh=
ich will emulate the write operation in Xen. But why after that Xen calls=
=A0=A0put_page() to free the page mapped to the PTE ? The code snapshot is =
as follows:=A0</div>
<div><br></div><div>int ptwr_do_page_fault(struct vcpu *v, unsigned long ad=
dr,</div><div>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0struct cpu_use=
r_regs *regs)</div><div>{</div><div>=A0 =A0 struct domain *d =3D v->doma=
in;</div><div>=A0 =A0 struct page_info *page;</div>
<div>=A0 =A0 l1_pgentry_t =A0 =A0 =A0pte;</div><div>=A0 =A0 struct ptwr_emu=
late_ctxt ptwr_ctxt;</div><div>=A0 =A0 int rc;</div><div><br></div><div>=A0=
 =A0 /* Attempt to read the PTE that maps the VA being accessed. */</div><d=
iv>=A0 =A0 guest_get_eff_l1e(v, addr, &pte);</div>
<div><br></div><div>=A0 =A0 ......</div><div><br></div><div>=A0 =A0 page =
=3D l1e_get_page(pte);=A0</div></div><div>=A0 =A0=A0</div><div>=A0 =A0 ....=
..</div><div><br></div><div>=A0 =A0 rc =3D x86_emulate(&ptwr_ctxt.ctxt,=
 &ptwr_emulate_ops);</div>
<div>=A0=A0</div><div>=A0 =A0 page_unlock(page);</div><div>=A0 =A0 put_page=
(page);</div><div><br></div><div>=A0 =A0 ......</div><div>}</div><div><br><=
/div><div>Thanks a lot,</div>-- <br>Xinxin<br>
<br>

--002354333626bd1ea404cc135c33--


--===============0646616157076212817==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0646616157076212817==--


From xen-devel-bounces@lists.xen.org Mon Oct 15 06:44:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 06:44:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNePD-0001CD-JZ; Mon, 15 Oct 2012 06:44:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xinxinjin89@gmail.com>) id 1TNePC-0001C8-NF
	for Xen-devel@lists.xen.org; Mon, 15 Oct 2012 06:44:02 +0000
Received: from [85.158.137.99:61647] by server-1.bemta-3.messagelabs.com id
	C1/2E-31728-1B0BB705; Mon, 15 Oct 2012 06:44:01 +0000
X-Env-Sender: xinxinjin89@gmail.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1350283439!21571118!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26987 invoked from network); 15 Oct 2012 06:44:00 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 06:44:00 -0000
Received: by mail-qc0-f173.google.com with SMTP id b12so4769142qca.32
	for <Xen-devel@lists.xen.org>; Sun, 14 Oct 2012 23:43:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=oy1NflWi73zs6HpdybsJhQsTO2RLaLRYICs31nf1u8E=;
	b=aCYVL6SEDzUw/MvnZR17Z4aEeZewjBWJ4kBNES5NqhKu1KyW0hjuAEfatC4QgXdocR
	p6D+ahu1BJfDU9HfvCSDVFRklXR9xDRyMILtT4CO4PxSQ2WVHZo13FVd3ye6AjuFysGr
	R4bpudehWKDwHMeeWmeUVRS2nY9obJzRQi2MiCdqVukCL9NaZjniM9h4aGI07bhVqb0R
	HwjiJ//ZJ6bhEQy54BpzuB8Hx+5GJHnU8iUX2oOCeq0m+uBaCzHi+BWv3kgOL3IlBRyP
	NomjtA/3huuXRFEtIWfM0c7mQbYkyFRM1MXrBqA62BQJUgw9TH85N88Ip1m9sXsBNXfY
	u2AA==
MIME-Version: 1.0
Received: by 10.229.77.21 with SMTP id e21mr5249606qck.70.1350283439185; Sun,
	14 Oct 2012 23:43:59 -0700 (PDT)
Received: by 10.229.74.9 with HTTP; Sun, 14 Oct 2012 23:43:58 -0700 (PDT)
Date: Sun, 14 Oct 2012 23:43:58 -0700
Message-ID: <CAJJWZcwhKx6Fz6R9atAUbOSOuVRzRg8Dc8tOO2DLFUNcp5rZwA@mail.gmail.com>
From: Xinxin Jin <xinxinjin89@gmail.com>
To: Xen-devel@lists.xen.org
Subject: [Xen-devel] put_page in ptwr_do_page_fault
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0646616157076212817=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0646616157076212817==
Content-Type: multipart/alternative; boundary=002354333626bd1ea404cc135c33

--002354333626bd1ea404cc135c33
Content-Type: text/plain; charset=ISO-8859-1

Hi all,
I am trying to understand write page table handler for PV guests. I got the
core of ptwr_do_page_fault is x86_emulate() which will emulate the write
operation in Xen. But why after that Xen calls  put_page() to free the page
mapped to the PTE ? The code snapshot is as follows:

int ptwr_do_page_fault(struct vcpu *v, unsigned long addr,
                       struct cpu_user_regs *regs)
{
    struct domain *d = v->domain;
    struct page_info *page;
    l1_pgentry_t      pte;
    struct ptwr_emulate_ctxt ptwr_ctxt;
    int rc;

    /* Attempt to read the PTE that maps the VA being accessed. */
    guest_get_eff_l1e(v, addr, &pte);

    ......

    page = l1e_get_page(pte);

    ......

    rc = x86_emulate(&ptwr_ctxt.ctxt, &ptwr_emulate_ops);

    page_unlock(page);
    put_page(page);

    ......
}

Thanks a lot,
-- 
Xinxin

--002354333626bd1ea404cc135c33
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div><div>Hi all,</div><div>I am trying to understand write page table hand=
ler for PV guests. I got the core of ptwr_do_page_fault is x86_emulate() wh=
ich will emulate the write operation in Xen. But why after that Xen calls=
=A0=A0put_page() to free the page mapped to the PTE ? The code snapshot is =
as follows:=A0</div>
<div><br></div><div>int ptwr_do_page_fault(struct vcpu *v, unsigned long ad=
dr,</div><div>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0struct cpu_use=
r_regs *regs)</div><div>{</div><div>=A0 =A0 struct domain *d =3D v->doma=
in;</div><div>=A0 =A0 struct page_info *page;</div>
<div>=A0 =A0 l1_pgentry_t =A0 =A0 =A0pte;</div><div>=A0 =A0 struct ptwr_emu=
late_ctxt ptwr_ctxt;</div><div>=A0 =A0 int rc;</div><div><br></div><div>=A0=
 =A0 /* Attempt to read the PTE that maps the VA being accessed. */</div><d=
iv>=A0 =A0 guest_get_eff_l1e(v, addr, &pte);</div>
<div><br></div><div>=A0 =A0 ......</div><div><br></div><div>=A0 =A0 page =
=3D l1e_get_page(pte);=A0</div></div><div>=A0 =A0=A0</div><div>=A0 =A0 ....=
..</div><div><br></div><div>=A0 =A0 rc =3D x86_emulate(&ptwr_ctxt.ctxt,=
 &ptwr_emulate_ops);</div>
<div>=A0=A0</div><div>=A0 =A0 page_unlock(page);</div><div>=A0 =A0 put_page=
(page);</div><div><br></div><div>=A0 =A0 ......</div><div>}</div><div><br><=
/div><div>Thanks a lot,</div>-- <br>Xinxin<br>
<br>

--002354333626bd1ea404cc135c33--


--===============0646616157076212817==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0646616157076212817==--


From xen-devel-bounces@lists.xen.org Mon Oct 15 07:40:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 07:40:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNfHO-0001k9-BP; Mon, 15 Oct 2012 07:40:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olivier.hanesse@gmail.com>)
	id 1TNfHM-0001jx-FS; Mon, 15 Oct 2012 07:40:00 +0000
Received: from [85.158.143.99:6500] by server-2.bemta-4.messagelabs.com id
	81/AF-25171-FCDBB705; Mon, 15 Oct 2012 07:39:59 +0000
X-Env-Sender: olivier.hanesse@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1350286797!24335990!1
X-Originating-IP: [209.85.219.43]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11803 invoked from network); 15 Oct 2012 07:39:58 -0000
Received: from mail-oa0-f43.google.com (HELO mail-oa0-f43.google.com)
	(209.85.219.43)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 07:39:58 -0000
Received: by mail-oa0-f43.google.com with SMTP id k1so6385816oag.30
	for <multiple recipients>; Mon, 15 Oct 2012 00:39:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=JTiJ40M0EWP9mRiFlwJhRlVh0ZqEJ2krunasXtIPcLQ=;
	b=SkMJ3B+aLFQ8PX9GQ1BloEtBcHboq21dbbwLT4iJ+baSEa0m0BmVR1GiQVm+IU5x0f
	TpwSl02retpodFxjZNjNTgm5C++cyWp+3sVswJA07MB96+S5IG3snrEQ5oLoRJ7ggTfs
	iyU3ITFnbRsFKsBasDSvwH84cI23Cw4ZLAtUED4Gph2oS4tP8set2vsiCs15p8e5DC/0
	HVNMVHSBuxbip3RDYbp2p/4sVhc/rFciVAgpVPrmORgUehCiv8MBberYwST3Y/6jAPmc
	E23PlU1WXDpZ9ueo2qyl4alLh52WhBbNFXmY7NJk7XU8CIPQ/uLGRzj+VoyNllkykE70
	TZzw==
MIME-Version: 1.0
Received: by 10.182.145.9 with SMTP id sq9mr9019510obb.42.1350286796969; Mon,
	15 Oct 2012 00:39:56 -0700 (PDT)
Received: by 10.76.33.199 with HTTP; Mon, 15 Oct 2012 00:39:56 -0700 (PDT)
In-Reply-To: <CAE17a0WvLyduj4V68qPJRLcjc5V7xZ=iTNprKWJyGAX_6RXC+Q@mail.gmail.com>
References: <AANLkTikptc2POrKQgJuoVZRdwJTo64DJ_hm12KuPky4D@mail.gmail.com>
	<b1ca6ddc-ca69-447e-93e9-8d36d1ff4a43@default>
	<AANLkTinK94GDOF_GeaVs50wK0u8EdZ2rtzPuh65ca8qR@mail.gmail.com>
	<CAE17a0UPyzsNn=ps9MxarkGg=ns8dCpVz0qBDvesT2AOskwfVg@mail.gmail.com>
	<65395f62-74e5-4910-b701-8df629c2ce3b@default>
	<CABx4GKrQxOOQo_uUXSFvy0nzdMp1A_qc=_e4K+88GkB7xv=9nw@mail.gmail.com>
	<CAE17a0VkMuUEG9VaM7AFrwcsEjVBq9RfvTWz1_KmscAyCxeAbA@mail.gmail.com>
	<CABx4GKqrTEV7CEnAVUfYr-+yky8N5P1U29xDbrESH-mHB0iZhQ@mail.gmail.com>
	<CAE17a0UYwqLxoZaVDgQCvUR2KQK4vvP3bkvsdrwgnsUp33xuNQ@mail.gmail.com>
	<CAE17a0UQocJjZc38c2805uYvdwR7e447UGH9ywcxMw1Ge3imfg@mail.gmail.com>
	<20120930151314.GU8912@reaktio.net>
	<CAE17a0WWvpwW-V5hQOgL1CiuVZFKyzhZVZfTVq74ZsJUo1SE8w@mail.gmail.com>
	<CAE17a0WvLyduj4V68qPJRLcjc5V7xZ=iTNprKWJyGAX_6RXC+Q@mail.gmail.com>
Date: Mon, 15 Oct 2012 09:39:56 +0200
Message-ID: <CABx4GKr-AxZmCyGmd4qenMtgdo2Yg+UnT4ymbONjBtuS+w=g7Q@mail.gmail.com>
From: Olivier Hanesse <olivier.hanesse@gmail.com>
To: Mauro <mrsanna1@gmail.com>
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>, Jeremy Fitzhardinge <jeremy@goop.org>,
	Keir Fraser <keir.xen@gmail.com>,
	Xen Users <xen-users@lists.xensource.com>,
	Mark Adams <mark@campbell-lange.net>
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3773458365543498546=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3773458365543498546==
Content-Type: multipart/alternative; boundary=f46d0446317ce0d64a04cc1424ae

--f46d0446317ce0d64a04cc1424ae
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello,

Strange things on this rainy morning, I got this bug again on another
hardware, and Xen hypervisor from Wheezy and kernel from Squeeze.

ii  linux-image-2.6.32-5-xen-amd64      2.6.32-46                  Linux
2.6.32 for 64-bit PCs, Xen dom0 support
ii  xen-hypervisor-4.1-amd64               4.1.3-2                      Xen
Hypervisor on AMD64

I've upgraded this server last week. I don't know if it is linked or not,
but I didn't get any 'time wrap' on this server for more than 250days.
Maybe it is related to the upgrade process. Before the upgrade, my version
were :

ii  linux-image-2.6.32-5-xen-amd64   2.6.32-41squeeze2            Linux
2.6.32 for 64-bit PCs, Xen dom0 support
ii  xen-hypervisor-4.1-amd64            4.1.2-2                      Xen
Hypervisor on AMD64

I only upgraded half of my servers, so I will wait a little bit to upgrade
the other half and see if this issue occurs again only on updated servers.

For the record, always the same errors :

xm dmesg =3D> (XEN) Platform timer appears to have unexpectedly wrapped 10 =
or
more times.

/var/log/*   =3D> Oct 14 22:46:07 eul2400468 kernel: [734618.562219]
Clocksource tsc unstable (delta =3D -2999660313370 ns)

I thought it was this issue was hardware related, maybe not.

Olivier

2012/9/30 Mauro <mrsanna1@gmail.com>

> On 30 September 2012 21:23, Mauro <mrsanna1@gmail.com> wrote:
> > On 30 September 2012 17:13, Pasi K=E4rkk=E4inen <pasik@iki.fi> wrote:
> >> On Sat, Sep 29, 2012 at 02:19:55PM +0200, Mauro wrote:
> >>> It's happened another time, system date 50 minutes ahead.
> >>> There is really no solution?
> >>>
> >>
> >> Try with a recent Xen hypervisor version. Xen 4.1.3 or 4.2.0.
> >> It helps a lot to know if the issue is still in the latest hypervisor
> versions or not.
>
> There is someone that had the problem and solved using a recent xen
> hypervisor?
>

--f46d0446317ce0d64a04cc1424ae
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello,=A0<div><br></div><div>Strange things on this rainy morning, I got th=
is bug again on another hardware, and Xen hypervisor from Wheezy and kernel=
 from Squeeze.</div><div><br></div><div><div>ii =A0linux-image-2.6.32-5-xen=
-amd64 =A0 =A0 =A02.6.32-46 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Linux 2.6.32=
 for 64-bit PCs, Xen dom0 support</div>
<div>ii =A0xen-hypervisor-4.1-amd64 =A0 =A0 =A0 =A0 =A0 =A0 =A0 4.1.3-2 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Xen Hypervisor on AMD64</div><div><=
br></div><div>I've upgraded this server last week. I don't know if =
it is linked or not, but I didn't get any 'time wrap' on this s=
erver for more than 250days.</div>
<div>Maybe it is related to the upgrade process.=A0Before the upgrade, my v=
ersion were :</div><div><br></div><div><div>ii =A0linux-image-2.6.32-5-xen-=
amd64 =A0 2.6.32-41squeeze2 =A0 =A0 =A0 =A0 =A0 =A0Linux 2.6.32 for 64-bit =
PCs, Xen dom0 support</div>
<div>ii =A0xen-hypervisor-4.1-amd64 =A0 =A0 =A0 =A0 =A0 =A04.1.2-2 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Xen Hypervisor on AMD64</div></div><div>=
<br></div><div>I only upgraded half of my servers, so I will wait a little =
bit to upgrade the other half and see if this issue occurs again only on up=
dated servers.</div>
<div><br></div><div>For the record, always the same errors :=A0</div><div><=
br></div><div>xm dmesg =3D>=A0(XEN) Platform timer appears to have unexp=
ectedly wrapped 10 or more times.</div><div>=A0</div><div><div>/var/log/* =
=A0 =3D> Oct 14 22:46:07 eul2400468 kernel: [734618.562219] Clocksource =
tsc unstable (delta =3D -2999660313370 ns)</div>
</div><div><br></div><div>I thought it was this issue was hardware related,=
 maybe not.</div><div><br></div><div>Olivier</div><br><div class=3D"gmail_q=
uote">2012/9/30 Mauro <span dir=3D"ltr"><<a href=3D"mailto:mrsanna1@gmai=
l.com" target=3D"_blank">mrsanna1@gmail.com</a>></span><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On 30 September 2012 21:23=
, Mauro <<a href=3D"mailto:mrsanna1@gmail.com">mrsanna1@gmail.com</a>>=
; wrote:<br>

> On 30 September 2012 17:13, Pasi K=E4rkk=E4inen <<a href=3D"mailto:=
pasik@iki.fi">pasik@iki.fi</a>> wrote:<br>
>> On Sat, Sep 29, 2012 at 02:19:55PM +0200, Mauro wrote:<br>
>>> It's happened another time, system date 50 minutes ahead.<=
br>
>>> There is really no solution?<br>
>>><br>
>><br>
>> Try with a recent Xen hypervisor version. Xen 4.1.3 or 4.2.0.<br>
>> It helps a lot to know if the issue is still in the latest hypervi=
sor versions or not.<br>
<br>
</div>There is someone that had the problem and solved using a recent xen h=
ypervisor?<br>
</blockquote></div><br></div>

--f46d0446317ce0d64a04cc1424ae--


--===============3773458365543498546==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3773458365543498546==--


From xen-devel-bounces@lists.xen.org Mon Oct 15 07:40:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 07:40:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNfHO-0001k9-BP; Mon, 15 Oct 2012 07:40:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olivier.hanesse@gmail.com>)
	id 1TNfHM-0001jx-FS; Mon, 15 Oct 2012 07:40:00 +0000
Received: from [85.158.143.99:6500] by server-2.bemta-4.messagelabs.com id
	81/AF-25171-FCDBB705; Mon, 15 Oct 2012 07:39:59 +0000
X-Env-Sender: olivier.hanesse@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1350286797!24335990!1
X-Originating-IP: [209.85.219.43]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11803 invoked from network); 15 Oct 2012 07:39:58 -0000
Received: from mail-oa0-f43.google.com (HELO mail-oa0-f43.google.com)
	(209.85.219.43)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 07:39:58 -0000
Received: by mail-oa0-f43.google.com with SMTP id k1so6385816oag.30
	for <multiple recipients>; Mon, 15 Oct 2012 00:39:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=JTiJ40M0EWP9mRiFlwJhRlVh0ZqEJ2krunasXtIPcLQ=;
	b=SkMJ3B+aLFQ8PX9GQ1BloEtBcHboq21dbbwLT4iJ+baSEa0m0BmVR1GiQVm+IU5x0f
	TpwSl02retpodFxjZNjNTgm5C++cyWp+3sVswJA07MB96+S5IG3snrEQ5oLoRJ7ggTfs
	iyU3ITFnbRsFKsBasDSvwH84cI23Cw4ZLAtUED4Gph2oS4tP8set2vsiCs15p8e5DC/0
	HVNMVHSBuxbip3RDYbp2p/4sVhc/rFciVAgpVPrmORgUehCiv8MBberYwST3Y/6jAPmc
	E23PlU1WXDpZ9ueo2qyl4alLh52WhBbNFXmY7NJk7XU8CIPQ/uLGRzj+VoyNllkykE70
	TZzw==
MIME-Version: 1.0
Received: by 10.182.145.9 with SMTP id sq9mr9019510obb.42.1350286796969; Mon,
	15 Oct 2012 00:39:56 -0700 (PDT)
Received: by 10.76.33.199 with HTTP; Mon, 15 Oct 2012 00:39:56 -0700 (PDT)
In-Reply-To: <CAE17a0WvLyduj4V68qPJRLcjc5V7xZ=iTNprKWJyGAX_6RXC+Q@mail.gmail.com>
References: <AANLkTikptc2POrKQgJuoVZRdwJTo64DJ_hm12KuPky4D@mail.gmail.com>
	<b1ca6ddc-ca69-447e-93e9-8d36d1ff4a43@default>
	<AANLkTinK94GDOF_GeaVs50wK0u8EdZ2rtzPuh65ca8qR@mail.gmail.com>
	<CAE17a0UPyzsNn=ps9MxarkGg=ns8dCpVz0qBDvesT2AOskwfVg@mail.gmail.com>
	<65395f62-74e5-4910-b701-8df629c2ce3b@default>
	<CABx4GKrQxOOQo_uUXSFvy0nzdMp1A_qc=_e4K+88GkB7xv=9nw@mail.gmail.com>
	<CAE17a0VkMuUEG9VaM7AFrwcsEjVBq9RfvTWz1_KmscAyCxeAbA@mail.gmail.com>
	<CABx4GKqrTEV7CEnAVUfYr-+yky8N5P1U29xDbrESH-mHB0iZhQ@mail.gmail.com>
	<CAE17a0UYwqLxoZaVDgQCvUR2KQK4vvP3bkvsdrwgnsUp33xuNQ@mail.gmail.com>
	<CAE17a0UQocJjZc38c2805uYvdwR7e447UGH9ywcxMw1Ge3imfg@mail.gmail.com>
	<20120930151314.GU8912@reaktio.net>
	<CAE17a0WWvpwW-V5hQOgL1CiuVZFKyzhZVZfTVq74ZsJUo1SE8w@mail.gmail.com>
	<CAE17a0WvLyduj4V68qPJRLcjc5V7xZ=iTNprKWJyGAX_6RXC+Q@mail.gmail.com>
Date: Mon, 15 Oct 2012 09:39:56 +0200
Message-ID: <CABx4GKr-AxZmCyGmd4qenMtgdo2Yg+UnT4ymbONjBtuS+w=g7Q@mail.gmail.com>
From: Olivier Hanesse <olivier.hanesse@gmail.com>
To: Mauro <mrsanna1@gmail.com>
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>, Jeremy Fitzhardinge <jeremy@goop.org>,
	Keir Fraser <keir.xen@gmail.com>,
	Xen Users <xen-users@lists.xensource.com>,
	Mark Adams <mark@campbell-lange.net>
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3773458365543498546=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3773458365543498546==
Content-Type: multipart/alternative; boundary=f46d0446317ce0d64a04cc1424ae

--f46d0446317ce0d64a04cc1424ae
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello,

Strange things on this rainy morning, I got this bug again on another
hardware, and Xen hypervisor from Wheezy and kernel from Squeeze.

ii  linux-image-2.6.32-5-xen-amd64      2.6.32-46                  Linux
2.6.32 for 64-bit PCs, Xen dom0 support
ii  xen-hypervisor-4.1-amd64               4.1.3-2                      Xen
Hypervisor on AMD64

I've upgraded this server last week. I don't know if it is linked or not,
but I didn't get any 'time wrap' on this server for more than 250days.
Maybe it is related to the upgrade process. Before the upgrade, my version
were :

ii  linux-image-2.6.32-5-xen-amd64   2.6.32-41squeeze2            Linux
2.6.32 for 64-bit PCs, Xen dom0 support
ii  xen-hypervisor-4.1-amd64            4.1.2-2                      Xen
Hypervisor on AMD64

I only upgraded half of my servers, so I will wait a little bit to upgrade
the other half and see if this issue occurs again only on updated servers.

For the record, always the same errors :

xm dmesg =3D> (XEN) Platform timer appears to have unexpectedly wrapped 10 =
or
more times.

/var/log/*   =3D> Oct 14 22:46:07 eul2400468 kernel: [734618.562219]
Clocksource tsc unstable (delta =3D -2999660313370 ns)

I thought it was this issue was hardware related, maybe not.

Olivier

2012/9/30 Mauro <mrsanna1@gmail.com>

> On 30 September 2012 21:23, Mauro <mrsanna1@gmail.com> wrote:
> > On 30 September 2012 17:13, Pasi K=E4rkk=E4inen <pasik@iki.fi> wrote:
> >> On Sat, Sep 29, 2012 at 02:19:55PM +0200, Mauro wrote:
> >>> It's happened another time, system date 50 minutes ahead.
> >>> There is really no solution?
> >>>
> >>
> >> Try with a recent Xen hypervisor version. Xen 4.1.3 or 4.2.0.
> >> It helps a lot to know if the issue is still in the latest hypervisor
> versions or not.
>
> There is someone that had the problem and solved using a recent xen
> hypervisor?
>

--f46d0446317ce0d64a04cc1424ae
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello,=A0<div><br></div><div>Strange things on this rainy morning, I got th=
is bug again on another hardware, and Xen hypervisor from Wheezy and kernel=
 from Squeeze.</div><div><br></div><div><div>ii =A0linux-image-2.6.32-5-xen=
-amd64 =A0 =A0 =A02.6.32-46 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Linux 2.6.32=
 for 64-bit PCs, Xen dom0 support</div>
<div>ii =A0xen-hypervisor-4.1-amd64 =A0 =A0 =A0 =A0 =A0 =A0 =A0 4.1.3-2 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Xen Hypervisor on AMD64</div><div><=
br></div><div>I've upgraded this server last week. I don't know if =
it is linked or not, but I didn't get any 'time wrap' on this s=
erver for more than 250days.</div>
<div>Maybe it is related to the upgrade process.=A0Before the upgrade, my v=
ersion were :</div><div><br></div><div><div>ii =A0linux-image-2.6.32-5-xen-=
amd64 =A0 2.6.32-41squeeze2 =A0 =A0 =A0 =A0 =A0 =A0Linux 2.6.32 for 64-bit =
PCs, Xen dom0 support</div>
<div>ii =A0xen-hypervisor-4.1-amd64 =A0 =A0 =A0 =A0 =A0 =A04.1.2-2 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Xen Hypervisor on AMD64</div></div><div>=
<br></div><div>I only upgraded half of my servers, so I will wait a little =
bit to upgrade the other half and see if this issue occurs again only on up=
dated servers.</div>
<div><br></div><div>For the record, always the same errors :=A0</div><div><=
br></div><div>xm dmesg =3D>=A0(XEN) Platform timer appears to have unexp=
ectedly wrapped 10 or more times.</div><div>=A0</div><div><div>/var/log/* =
=A0 =3D> Oct 14 22:46:07 eul2400468 kernel: [734618.562219] Clocksource =
tsc unstable (delta =3D -2999660313370 ns)</div>
</div><div><br></div><div>I thought it was this issue was hardware related,=
 maybe not.</div><div><br></div><div>Olivier</div><br><div class=3D"gmail_q=
uote">2012/9/30 Mauro <span dir=3D"ltr"><<a href=3D"mailto:mrsanna1@gmai=
l.com" target=3D"_blank">mrsanna1@gmail.com</a>></span><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On 30 September 2012 21:23=
, Mauro <<a href=3D"mailto:mrsanna1@gmail.com">mrsanna1@gmail.com</a>>=
; wrote:<br>

> On 30 September 2012 17:13, Pasi K=E4rkk=E4inen <<a href=3D"mailto:=
pasik@iki.fi">pasik@iki.fi</a>> wrote:<br>
>> On Sat, Sep 29, 2012 at 02:19:55PM +0200, Mauro wrote:<br>
>>> It's happened another time, system date 50 minutes ahead.<=
br>
>>> There is really no solution?<br>
>>><br>
>><br>
>> Try with a recent Xen hypervisor version. Xen 4.1.3 or 4.2.0.<br>
>> It helps a lot to know if the issue is still in the latest hypervi=
sor versions or not.<br>
<br>
</div>There is someone that had the problem and solved using a recent xen h=
ypervisor?<br>
</blockquote></div><br></div>

--f46d0446317ce0d64a04cc1424ae--


--===============3773458365543498546==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3773458365543498546==--


From xen-devel-bounces@lists.xen.org Mon Oct 15 07:53:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 07:53:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNfTZ-0001tj-NN; Mon, 15 Oct 2012 07:52:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TNfTX-0001te-Oz
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 07:52:36 +0000
Received: from [85.158.139.211:5676] by server-7.bemta-5.messagelabs.com id
	FD/29-23102-2C0CB705; Mon, 15 Oct 2012 07:52:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1350287554!22285882!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxNzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20772 invoked from network); 15 Oct 2012 07:52:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 07:52:34 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="15161346"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 07:52:33 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 08:52:33 +0100
Message-ID: <1350287553.14440.0.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
Date: Mon, 15 Oct 2012 08:52:33 +0100
In-Reply-To: <20121014111035.GE8912@reaktio.net>
References: <20120905030239.GJ8912@reaktio.net>
	<1346846602-1109-1-git-send-email-roger.pau@citrix.com>
	<1347613534.24226.167.camel@zakaz.uk.xensource.com>
	<20121014111035.GE8912@reaktio.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>, Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libfsimage: add ext4 support for CentOS 5.x
 / Xen 4.2.1 backport
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, 2012-10-14 at 12:10 +0100, Pasi K=E4rkk=E4inen wrote:
> On Fri, Sep 14, 2012 at 10:05:34AM +0100, Ian Campbell wrote:
> > On Wed, 2012-09-05 at 13:03 +0100, Roger Pau Monne wrote:
> > > CentOS 5.x forked e2fs ext4 support into a different package called
> > > e4fs, and so headers and library names changed from ext2fs to ext4fs.
> > > Check if ext4fs/ext2fs.h and -lext4fs work, and use that instead of
> > > ext2fs to build libfsimage. This patch assumes that if the ext4fs
> > > library is present it should always be used instead of ext2fs.
> > > =

> > > This patch includes a rework of the ext2fs check, a new ext4fs check
> > > and a minor modification in libfsimage to use the correct library.
> > > =

> > > Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
> > > ---
> > > Please re-run autogen.sh after applying
> > =

> > Done & acked + applied. Thanks.
> >
> =

> Hello,
> =

> Now that this patch has been in xen-unstable for a while
> I'd like to request Xen 4.2.1 backport..

Ian Jackson deals with backports, not me.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 07:53:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 07:53:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNfTZ-0001tj-NN; Mon, 15 Oct 2012 07:52:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TNfTX-0001te-Oz
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 07:52:36 +0000
Received: from [85.158.139.211:5676] by server-7.bemta-5.messagelabs.com id
	FD/29-23102-2C0CB705; Mon, 15 Oct 2012 07:52:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1350287554!22285882!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxNzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20772 invoked from network); 15 Oct 2012 07:52:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 07:52:34 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="15161346"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 07:52:33 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 08:52:33 +0100
Message-ID: <1350287553.14440.0.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
Date: Mon, 15 Oct 2012 08:52:33 +0100
In-Reply-To: <20121014111035.GE8912@reaktio.net>
References: <20120905030239.GJ8912@reaktio.net>
	<1346846602-1109-1-git-send-email-roger.pau@citrix.com>
	<1347613534.24226.167.camel@zakaz.uk.xensource.com>
	<20121014111035.GE8912@reaktio.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>, Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libfsimage: add ext4 support for CentOS 5.x
 / Xen 4.2.1 backport
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, 2012-10-14 at 12:10 +0100, Pasi K=E4rkk=E4inen wrote:
> On Fri, Sep 14, 2012 at 10:05:34AM +0100, Ian Campbell wrote:
> > On Wed, 2012-09-05 at 13:03 +0100, Roger Pau Monne wrote:
> > > CentOS 5.x forked e2fs ext4 support into a different package called
> > > e4fs, and so headers and library names changed from ext2fs to ext4fs.
> > > Check if ext4fs/ext2fs.h and -lext4fs work, and use that instead of
> > > ext2fs to build libfsimage. This patch assumes that if the ext4fs
> > > library is present it should always be used instead of ext2fs.
> > > =

> > > This patch includes a rework of the ext2fs check, a new ext4fs check
> > > and a minor modification in libfsimage to use the correct library.
> > > =

> > > Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
> > > ---
> > > Please re-run autogen.sh after applying
> > =

> > Done & acked + applied. Thanks.
> >
> =

> Hello,
> =

> Now that this patch has been in xen-unstable for a while
> I'd like to request Xen 4.2.1 backport..

Ian Jackson deals with backports, not me.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 07:57:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 07:57:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNfXN-00020Q-Co; Mon, 15 Oct 2012 07:56:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TNfXL-00020J-PZ
	for Xen-devel@lists.xen.org; Mon, 15 Oct 2012 07:56:31 +0000
Received: from [85.158.143.99:26658] by server-2.bemta-4.messagelabs.com id
	A8/05-25171-FA1CB705; Mon, 15 Oct 2012 07:56:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1350287790!25933207!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxNzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12756 invoked from network); 15 Oct 2012 07:56:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 07:56:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="15161455"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 07:56:30 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 08:56:30 +0100
Message-ID: <1350287790.14440.1.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
Date: Mon, 15 Oct 2012 08:56:30 +0100
In-Reply-To: <20121014110311.GD8912@reaktio.net>
References: <CAN=sCCEuPqhapvBR2eSTvALQeKbwshmT5=MvSiX3FoMW+vg_aA@mail.gmail.com>
	<1349263669.650.131.camel@zakaz.uk.xensource.com>
	<CAN=sCCGSvu9_xLXnMRhKY6fr1WD+ittsjpKRF6fVFnwtgB9niQ@mail.gmail.com>
	<1349266207.650.137.camel@zakaz.uk.xensource.com>
	<CAN=sCCEtV1PS-a7MtSjsX=XKRqQCoabvNUY-F1xD-sjMmrJE+A@mail.gmail.com>
	<CAN=sCCFcsZUZYKiOVqOF=DzM8VpSEEOSUfmjLh2+DKOrkG+b2g@mail.gmail.com>
	<CAN=sCCGWU4Wpg9QfFaoPLUBmo_rXTf4h=F4g+ES0CHFhGU=0KQ@mail.gmail.com>
	<1349278604.650.162.camel@zakaz.uk.xensource.com>
	<CAN=sCCEO63JgWCUbosP5+exL4aU=yjaM_VPOxbjh6=C6r8CAhg@mail.gmail.com>
	<1349282150.650.181.camel@zakaz.uk.xensource.com>
	<20121014110311.GD8912@reaktio.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Valtteri Kiviniemi <kiviniemi.valtteri@gmail.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0, xl toolstack cant launch older domUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, 2012-10-14 at 12:03 +0100, Pasi K=E4rkk=E4inen wrote:
> On Wed, Oct 03, 2012 at 05:35:50PM +0100, Ian Campbell wrote:
> > On Wed, 2012-10-03 at 16:39 +0100, Valtteri Kiviniemi wrote:
> > > Hypervisor is 64bit, dom0 is 64bit but the domU is 32bit. If this is
> > > what you meant?
> > =

> > It is.
> > =

> > I think the underlying bug here is that your 32bit domU kernel predates
> > the ability to run 32 bit guests on 64 bit hypervisors. Guest kernels
> > are supposed to write that protocol node themselves.
> > =

> > It appears that xend includes some sort of workaround for this which xl
> > does not.
> > =

> =

> So from a user's point-of-view this is a regression in xl..
> similar workaround probably should be added in xl to be able to run old g=
uests? =


I don't know when I'm going to have time to look into this. Patches
gratefully received.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 07:57:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 07:57:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNfXN-00020Q-Co; Mon, 15 Oct 2012 07:56:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TNfXL-00020J-PZ
	for Xen-devel@lists.xen.org; Mon, 15 Oct 2012 07:56:31 +0000
Received: from [85.158.143.99:26658] by server-2.bemta-4.messagelabs.com id
	A8/05-25171-FA1CB705; Mon, 15 Oct 2012 07:56:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1350287790!25933207!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxNzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12756 invoked from network); 15 Oct 2012 07:56:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 07:56:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="15161455"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 07:56:30 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 08:56:30 +0100
Message-ID: <1350287790.14440.1.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
Date: Mon, 15 Oct 2012 08:56:30 +0100
In-Reply-To: <20121014110311.GD8912@reaktio.net>
References: <CAN=sCCEuPqhapvBR2eSTvALQeKbwshmT5=MvSiX3FoMW+vg_aA@mail.gmail.com>
	<1349263669.650.131.camel@zakaz.uk.xensource.com>
	<CAN=sCCGSvu9_xLXnMRhKY6fr1WD+ittsjpKRF6fVFnwtgB9niQ@mail.gmail.com>
	<1349266207.650.137.camel@zakaz.uk.xensource.com>
	<CAN=sCCEtV1PS-a7MtSjsX=XKRqQCoabvNUY-F1xD-sjMmrJE+A@mail.gmail.com>
	<CAN=sCCFcsZUZYKiOVqOF=DzM8VpSEEOSUfmjLh2+DKOrkG+b2g@mail.gmail.com>
	<CAN=sCCGWU4Wpg9QfFaoPLUBmo_rXTf4h=F4g+ES0CHFhGU=0KQ@mail.gmail.com>
	<1349278604.650.162.camel@zakaz.uk.xensource.com>
	<CAN=sCCEO63JgWCUbosP5+exL4aU=yjaM_VPOxbjh6=C6r8CAhg@mail.gmail.com>
	<1349282150.650.181.camel@zakaz.uk.xensource.com>
	<20121014110311.GD8912@reaktio.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Valtteri Kiviniemi <kiviniemi.valtteri@gmail.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0, xl toolstack cant launch older domUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, 2012-10-14 at 12:03 +0100, Pasi K=E4rkk=E4inen wrote:
> On Wed, Oct 03, 2012 at 05:35:50PM +0100, Ian Campbell wrote:
> > On Wed, 2012-10-03 at 16:39 +0100, Valtteri Kiviniemi wrote:
> > > Hypervisor is 64bit, dom0 is 64bit but the domU is 32bit. If this is
> > > what you meant?
> > =

> > It is.
> > =

> > I think the underlying bug here is that your 32bit domU kernel predates
> > the ability to run 32 bit guests on 64 bit hypervisors. Guest kernels
> > are supposed to write that protocol node themselves.
> > =

> > It appears that xend includes some sort of workaround for this which xl
> > does not.
> > =

> =

> So from a user's point-of-view this is a regression in xl..
> similar workaround probably should be added in xl to be able to run old g=
uests? =


I don't know when I'm going to have time to look into this. Patches
gratefully received.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 08:00:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 08:00:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNfb6-0002e3-ID; Mon, 15 Oct 2012 08:00:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TNfb5-0002du-T9
	for Xen-devel@lists.xen.org; Mon, 15 Oct 2012 08:00:24 +0000
Received: from [85.158.137.99:30636] by server-10.bemta-3.messagelabs.com id
	89/D4-27386-692CB705; Mon, 15 Oct 2012 08:00:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1350288022!20367198!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxNzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25730 invoked from network); 15 Oct 2012 08:00:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 08:00:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="15161549"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 08:00:21 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 09:00:21 +0100
Message-ID: <1350288020.14440.4.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Xinxin Jin <xinxinjin89@gmail.com>
Date: Mon, 15 Oct 2012 09:00:20 +0100
In-Reply-To: <CAJJWZcwhKx6Fz6R9atAUbOSOuVRzRg8Dc8tOO2DLFUNcp5rZwA@mail.gmail.com>
References: <CAJJWZcwhKx6Fz6R9atAUbOSOuVRzRg8Dc8tOO2DLFUNcp5rZwA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] put_page in ptwr_do_page_fault
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-10-15 at 07:43 +0100, Xinxin Jin wrote:
> Hi all,
> I am trying to understand write page table handler for PV guests. I
> got the core of ptwr_do_page_fault is x86_emulate() which will emulate
> the write operation in Xen. But why after that Xen calls  put_page()
> to free the page mapped to the PTE ? The code snapshot is as follows: 

The put_page balances the get_page inside get_page_from_pagenr which is
in the code you trimmed out below.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 08:00:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 08:00:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNfb6-0002e3-ID; Mon, 15 Oct 2012 08:00:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TNfb5-0002du-T9
	for Xen-devel@lists.xen.org; Mon, 15 Oct 2012 08:00:24 +0000
Received: from [85.158.137.99:30636] by server-10.bemta-3.messagelabs.com id
	89/D4-27386-692CB705; Mon, 15 Oct 2012 08:00:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1350288022!20367198!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxNzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25730 invoked from network); 15 Oct 2012 08:00:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 08:00:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="15161549"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 08:00:21 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 09:00:21 +0100
Message-ID: <1350288020.14440.4.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Xinxin Jin <xinxinjin89@gmail.com>
Date: Mon, 15 Oct 2012 09:00:20 +0100
In-Reply-To: <CAJJWZcwhKx6Fz6R9atAUbOSOuVRzRg8Dc8tOO2DLFUNcp5rZwA@mail.gmail.com>
References: <CAJJWZcwhKx6Fz6R9atAUbOSOuVRzRg8Dc8tOO2DLFUNcp5rZwA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] put_page in ptwr_do_page_fault
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-10-15 at 07:43 +0100, Xinxin Jin wrote:
> Hi all,
> I am trying to understand write page table handler for PV guests. I
> got the core of ptwr_do_page_fault is x86_emulate() which will emulate
> the write operation in Xen. But why after that Xen calls  put_page()
> to free the page mapped to the PTE ? The code snapshot is as follows: 

The put_page balances the get_page inside get_page_from_pagenr which is
in the code you trimmed out below.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 08:01:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 08:01:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNfbo-0002iW-Vm; Mon, 15 Oct 2012 08:01:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TNfbo-0002iH-5l
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 08:01:08 +0000
Received: from [85.158.139.211:21727] by server-10.bemta-5.messagelabs.com id
	FF/3E-01025-3C2CB705; Mon, 15 Oct 2012 08:01:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1350288066!22320584!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxNzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10414 invoked from network); 15 Oct 2012 08:01:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 08:01:06 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="15161564"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 08:01:06 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 09:01:06 +0100
Message-ID: <1350288065.14440.5.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Mon, 15 Oct 2012 09:01:05 +0100
In-Reply-To: <20121013223558.GA19665@aepfle.de>
References: <5aa14d5afe6b1f35b230.1350143968@probook.site>
	<20121013223558.GA19665@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] hotplug/Linux: close lockfd after lock
 attempt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 2012-10-13 at 23:35 +0100, Olaf Hering wrote:
> On Sat, Oct 13, Olaf Hering wrote:
> 
> > hotplug/Linux: close lockfd after lock attempt
> > 
> > When a HVM guest is shutdown some of the 'remove' events can not claim
> > the lock for some reason. Instead they try to grab the lock in a busy
> > loop, until udev reaps the xen-hotplug-cleanup helper.
> > After analyzing the resulting logfile its not obvious what the cause is.
> > The only explanation is that bash (?) gets confused if the same lockfd
> > is opened again and again. Closing it in each iteration seem to fix the
> > issue.
> 
> Can be reproduced with this testcase on sles11sp2, not on openSuSE 11.4:

So this is a bash bug? Have you reported it against bash?

Ian.

> 
>  # cat test.sh
> set -x
> source locking.sh
> 
> l=lock
> claim_lock $l
> sleep 1
> release_lock $l
> 
> 
>  # bash test.sh & bash test.sh & bash test.sh & bash test.sh &
> 
> 
> Olaf
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 08:01:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 08:01:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNfbo-0002iW-Vm; Mon, 15 Oct 2012 08:01:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TNfbo-0002iH-5l
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 08:01:08 +0000
Received: from [85.158.139.211:21727] by server-10.bemta-5.messagelabs.com id
	FF/3E-01025-3C2CB705; Mon, 15 Oct 2012 08:01:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1350288066!22320584!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxNzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10414 invoked from network); 15 Oct 2012 08:01:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 08:01:06 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="15161564"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 08:01:06 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 09:01:06 +0100
Message-ID: <1350288065.14440.5.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Mon, 15 Oct 2012 09:01:05 +0100
In-Reply-To: <20121013223558.GA19665@aepfle.de>
References: <5aa14d5afe6b1f35b230.1350143968@probook.site>
	<20121013223558.GA19665@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] hotplug/Linux: close lockfd after lock
 attempt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 2012-10-13 at 23:35 +0100, Olaf Hering wrote:
> On Sat, Oct 13, Olaf Hering wrote:
> 
> > hotplug/Linux: close lockfd after lock attempt
> > 
> > When a HVM guest is shutdown some of the 'remove' events can not claim
> > the lock for some reason. Instead they try to grab the lock in a busy
> > loop, until udev reaps the xen-hotplug-cleanup helper.
> > After analyzing the resulting logfile its not obvious what the cause is.
> > The only explanation is that bash (?) gets confused if the same lockfd
> > is opened again and again. Closing it in each iteration seem to fix the
> > issue.
> 
> Can be reproduced with this testcase on sles11sp2, not on openSuSE 11.4:

So this is a bash bug? Have you reported it against bash?

Ian.

> 
>  # cat test.sh
> set -x
> source locking.sh
> 
> l=lock
> claim_lock $l
> sleep 1
> release_lock $l
> 
> 
>  # bash test.sh & bash test.sh & bash test.sh & bash test.sh &
> 
> 
> Olaf
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 08:02:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 08:02:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNfcn-0002pR-Dw; Mon, 15 Oct 2012 08:02:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TNfcm-0002pF-5r
	for xen-devel@lists.xensource.com; Mon, 15 Oct 2012 08:02:08 +0000
Received: from [85.158.137.99:49865] by server-15.bemta-3.messagelabs.com id
	AA/B9-10261-FF2CB705; Mon, 15 Oct 2012 08:02:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1350288126!16236602!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxNzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29483 invoked from network); 15 Oct 2012 08:02:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 08:02:06 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="15161591"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 08:02:06 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 09:02:06 +0100
Message-ID: <1350288126.14440.6.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: topperxin <topperxin@126.com>
Date: Mon, 15 Oct 2012 09:02:06 +0100
In-Reply-To: <5266476.1b4039.13a596c5c9c.Coremail.topperxin@126.com>
References: <5266476.1b4039.13a596c5c9c.Coremail.topperxin@126.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] error: xl pci-attach assign pci to vm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 2012-10-13 at 10:20 +0100, topperxin wrote:
> Hi all
>        Now I'm dong the sriov on the xen 4.1

xl's pci passthrough support in 4.1 is a bit flakey. I recommend you
either use xend with 4.1 or upgrade to 4.2 where xl works pretty well.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 08:02:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 08:02:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNfcn-0002pR-Dw; Mon, 15 Oct 2012 08:02:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TNfcm-0002pF-5r
	for xen-devel@lists.xensource.com; Mon, 15 Oct 2012 08:02:08 +0000
Received: from [85.158.137.99:49865] by server-15.bemta-3.messagelabs.com id
	AA/B9-10261-FF2CB705; Mon, 15 Oct 2012 08:02:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1350288126!16236602!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxNzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29483 invoked from network); 15 Oct 2012 08:02:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 08:02:06 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="15161591"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 08:02:06 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 09:02:06 +0100
Message-ID: <1350288126.14440.6.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: topperxin <topperxin@126.com>
Date: Mon, 15 Oct 2012 09:02:06 +0100
In-Reply-To: <5266476.1b4039.13a596c5c9c.Coremail.topperxin@126.com>
References: <5266476.1b4039.13a596c5c9c.Coremail.topperxin@126.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] error: xl pci-attach assign pci to vm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 2012-10-13 at 10:20 +0100, topperxin wrote:
> Hi all
>        Now I'm dong the sriov on the xen 4.1

xl's pci passthrough support in 4.1 is a bit flakey. I recommend you
either use xend with 4.1 or upgrade to 4.2 where xl works pretty well.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 08:06:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 08:06:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNfgV-00038C-3A; Mon, 15 Oct 2012 08:05:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Philippe.Simonet@swisscom.com>)
	id 1TNfgT-00037z-7t; Mon, 15 Oct 2012 08:05:57 +0000
Received: from [85.158.139.83:40805] by server-10.bemta-5.messagelabs.com id
	A0/99-01025-4E3CB705; Mon, 15 Oct 2012 08:05:56 +0000
X-Env-Sender: Philippe.Simonet@swisscom.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1350288355!35135736!1
X-Originating-IP: [193.222.81.100]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkzLjIyMi44MS4xMDAgPT4gOTgwNjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21131 invoked from network); 15 Oct 2012 08:05:55 -0000
Received: from outmail100.swisscom.com (HELO mail.swisscom.com)
	(193.222.81.100)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Oct 2012 08:05:55 -0000
Received: by mail.swisscom.com; Mon, 15 Oct 2012 10:05:44 +0200
From: <Philippe.Simonet@swisscom.com>
To: <olivier.hanesse@gmail.com>, <mrsanna1@gmail.com>
Thread-Topic: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
Thread-Index: AQHNqqhpLRDmAIyqN0ORwzY4mO953pe6AR6g
Date: Mon, 15 Oct 2012 08:05:43 +0000
Message-ID: <FF93AF260AC2BB499A119CC65B092CF73148901B@sg000713.corproot.net>
References: <AANLkTikptc2POrKQgJuoVZRdwJTo64DJ_hm12KuPky4D@mail.gmail.com>
	<b1ca6ddc-ca69-447e-93e9-8d36d1ff4a43@default>
	<AANLkTinK94GDOF_GeaVs50wK0u8EdZ2rtzPuh65ca8qR@mail.gmail.com>
	<CAE17a0UPyzsNn=ps9MxarkGg=ns8dCpVz0qBDvesT2AOskwfVg@mail.gmail.com>
	<65395f62-74e5-4910-b701-8df629c2ce3b@default>
	<CABx4GKrQxOOQo_uUXSFvy0nzdMp1A_qc=_e4K+88GkB7xv=9nw@mail.gmail.com>
	<CAE17a0VkMuUEG9VaM7AFrwcsEjVBq9RfvTWz1_KmscAyCxeAbA@mail.gmail.com>
	<CABx4GKqrTEV7CEnAVUfYr-+yky8N5P1U29xDbrESH-mHB0iZhQ@mail.gmail.com>
	<CAE17a0UYwqLxoZaVDgQCvUR2KQK4vvP3bkvsdrwgnsUp33xuNQ@mail.gmail.com>
	<CAE17a0UQocJjZc38c2805uYvdwR7e447UGH9ywcxMw1Ge3imfg@mail.gmail.com>
	<20120930151314.GU8912@reaktio.net>
	<CAE17a0WWvpwW-V5hQOgL1CiuVZFKyzhZVZfTVq74ZsJUo1SE8w@mail.gmail.com>
	<CAE17a0WvLyduj4V68qPJRLcjc5V7xZ=iTNprKWJyGAX_6RXC+Q@mail.gmail.com>
	<CABx4GKr-AxZmCyGmd4qenMtgdo2Yg+UnT4ymbONjBtuS+w=g7Q@mail.gmail.com>
In-Reply-To: <CABx4GKr-AxZmCyGmd4qenMtgdo2Yg+UnT4ymbONjBtuS+w=g7Q@mail.gmail.com>
Accept-Language: en-US, de-CH
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.65.122.36]
MIME-Version: 1.0
Cc: dan.magenheimer@oracle.com, xen-devel@lists.xensource.com, keir@xen.org,
	jeremy@goop.org, keir.xen@gmail.com,
	xen-users@lists.xensource.com, mark@campbell-lange.net
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2670730164236996525=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2670730164236996525==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_FF93AF260AC2BB499A119CC65B092CF73148901Bsg000713corproo_"

--_000_FF93AF260AC2BB499A119CC65B092CF73148901Bsg000713corproo_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Oliver

bad news, this means that xen 4.1xxx doesn't solve this issue ...

on my side, on my  hardware that produce this bug ,I never had the problem =
whit this combination : (100% WHEEZY)
ii  xen-hypervisor-4.1-amd64                  4.1.3-2                   amd=
64        Xen Hypervisor on AMD64
ii  linux-image-3.2.0-3-amd64                 3.2.23-1                  amd=
64        Linux 3.2 for 64-bit PCs

                (this was because I had a great hope that 4.1.xxx solved th=
e problem ...)

Philippe



From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-bounces@lists.xen.o=
rg] On Behalf Of Olivier Hanesse
Sent: Monday, October 15, 2012 9:40 AM
To: Mauro
Cc: Dan Magenheimer; xen-devel@lists.xensource.com; Keir Fraser; Jeremy Fit=
zhardinge; Keir Fraser; Xen Users; Mark Adams
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems

Hello,

Strange things on this rainy morning, I got this bug again on another hardw=
are, and Xen hypervisor from Wheezy and kernel from Squeeze.

ii  linux-image-2.6.32-5-xen-amd64      2.6.32-46                  Linux 2.=
6.32 for 64-bit PCs, Xen dom0 support
ii  xen-hypervisor-4.1-amd64               4.1.3-2                      Xen=
 Hypervisor on AMD64

I've upgraded this server last week. I don't know if it is linked or not, b=
ut I didn't get any 'time wrap' on this server for more than 250days.
Maybe it is related to the upgrade process. Before the upgrade, my version =
were :

ii  linux-image-2.6.32-5-xen-amd64   2.6.32-41squeeze2            Linux 2.6=
.32 for 64-bit PCs, Xen dom0 support
ii  xen-hypervisor-4.1-amd64            4.1.2-2                      Xen Hy=
pervisor on AMD64

I only upgraded half of my servers, so I will wait a little bit to upgrade =
the other half and see if this issue occurs again only on updated servers.

For the record, always the same errors :

xm dmesg =3D> (XEN) Platform timer appears to have unexpectedly wrapped 10 =
or more times.

/var/log/*   =3D> Oct 14 22:46:07 eul2400468 kernel: [734618.562219] Clocks=
ource tsc unstable (delta =3D -2999660313370 ns)

I thought it was this issue was hardware related, maybe not.

Olivier

2012/9/30 Mauro <mrsanna1@gmail.com<mailto:mrsanna1@gmail.com>>
On 30 September 2012 21:23, Mauro <mrsanna1@gmail.com<mailto:mrsanna1@gmail=
.com>> wrote:
> On 30 September 2012 17:13, Pasi K=E4rkk=E4inen <pasik@iki.fi<mailto:pasi=
k@iki.fi>> wrote:
>> On Sat, Sep 29, 2012 at 02:19:55PM +0200, Mauro wrote:
>>> It's happened another time, system date 50 minutes ahead.
>>> There is really no solution?
>>>
>>
>> Try with a recent Xen hypervisor version. Xen 4.1.3 or 4.2.0.
>> It helps a lot to know if the issue is still in the latest hypervisor ve=
rsions or not.
There is someone that had the problem and solved using a recent xen hypervi=
sor?


--_000_FF93AF260AC2BB499A119CC65B092CF73148901Bsg000713corproo_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";
	mso-fareast-language:EN-US;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"FR-CH" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:"Calibri","sans-serif";color:#1F497D">Hi Oliver<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:"Calibri","sans-serif";color:#1F497D"><o:p> =
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:"Calibri","sans-serif";color:#1F497D">bad news, =
this means that xen 4.1xxx doesn’t solve this issue …<o:p></o:p=
></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:"Calibri","sans-serif";color:#1F497D"><o:p> =
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:"Calibri","sans-serif";color:#1F497D">on my side=
, on my  hardware that produce this bug ,I never had the problem whit =
this combination : (100% WHEEZY)<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:"Calibri","sans-serif";color:#1F497D">ii  x=
en-hypervisor-4.1-amd64         &nb=
sp;        4.1.3-2   =
;            &n=
bsp;   amd64        Xen Hyperv=
isor on AMD64<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:"Calibri","sans-serif";color:#1F497D">ii  l=
inux-image-3.2.0-3-amd64        &nb=
sp;        3.2.23-1   &nb=
sp;            =
  amd64        Linux 3.2 for 64-bit=
 PCs<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:"Calibri","sans-serif";color:#1F497D"><o:p> =
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:"Calibri","sans-serif";color:#1F497D"> &nbs=
p;            &=
nbsp; (this was because I had a great hope that 4.1.xxx solved the problem =
…)<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:"Calibri","sans-serif";color:#1F497D"><o:p> =
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:"Calibri","sans-serif";color:#1F497D">Philippe<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:"Calibri","sans-serif";color:#1F497D"><o:p> =
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:"Calibri","sans-serif";color:#1F497D"><o:p> =
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:"Calibri","sans-serif";color:#1F497D"><o:p> =
;</o:p></span></p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal"><b><span lang=3D"EN-US" style=3D"font-size:10.0pt;fo=
nt-family:"Tahoma","sans-serif"">From:</span></b><span =
lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:"Tahoma",&qu=
ot;sans-serif""> xen-devel-bounces@lists.xen.org [mailto:xen-devel-bou=
nces@lists.xen.org]
<b>On Behalf Of </b>Olivier Hanesse<br>
<b>Sent:</b> Monday, October 15, 2012 9:40 AM<br>
<b>To:</b> Mauro<br>
<b>Cc:</b> Dan Magenheimer; xen-devel@lists.xensource.com; Keir Fraser; Jer=
emy Fitzhardinge; Keir Fraser; Xen Users; Mark Adams<br>
<b>Subject:</b> Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems<o:p></o:=
p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoNormal">Hello, <o:p></o:p></p>
<div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class=3D"MsoNormal">Strange things on this rainy morning, I got this bug=
 again on another hardware, and Xen hypervisor from Wheezy and kernel from =
Squeeze.<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<p class=3D"MsoNormal">ii  linux-image-2.6.32-5-xen-amd64    =
;  2.6.32-46                 &=
nbsp;Linux 2.6.32 for 64-bit PCs, Xen dom0 support<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">ii  xen-hypervisor-4.1-amd64     &nbs=
p;         4.1.3-2           &=
nbsp;          Xen Hypervisor on AMD64<o:p></o:p><=
/p>
</div>
<div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class=3D"MsoNormal">I've upgraded this server last week. I don't know if=
 it is linked or not, but I didn't get any 'time wrap' on this server for m=
ore than 250days.<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">Maybe it is related to the upgrade process. Bef=
ore the upgrade, my version were :<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<p class=3D"MsoNormal">ii  linux-image-2.6.32-5-xen-amd64   2.6.3=
2-41squeeze2            Linux 2.6.32 for 64-b=
it PCs, Xen dom0 support<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">ii  xen-hypervisor-4.1-amd64     &nbs=
p;      4.1.2-2             &n=
bsp;        Xen Hypervisor on AMD64<o:p></o:p></p>
</div>
</div>
<div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class=3D"MsoNormal">I only upgraded half of my servers, so I will wait a=
 little bit to upgrade the other half and see if this issue occurs again on=
ly on updated servers.<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class=3D"MsoNormal">For the record, always the same errors : <o:p><=
/o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class=3D"MsoNormal">xm dmesg =3D> (XEN) Platform timer appears t=
o have unexpectedly wrapped 10 or more times.<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"> <o:p></o:p></p>
</div>
<div>
<div>
<p class=3D"MsoNormal">/var/log/*   =3D> Oct 14 22:46:07 eul2400468=
 kernel: [734618.562219] Clocksource tsc unstable (delta =3D -2999660313370=
 ns)<o:p></o:p></p>
</div>
</div>
<div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class=3D"MsoNormal">I thought it was this issue was hardware related, ma=
ybe not.<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class=3D"MsoNormal">Olivier<o:p></o:p></p>
</div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<div>
<p class=3D"MsoNormal">2012/9/30 Mauro <<a href=3D"mailto:mrsanna1@gmail=
.com" target=3D"_blank">mrsanna1@gmail.com</a>><o:p></o:p></p>
<div>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">On 30 September 2012 =
21:23, Mauro <<a href=3D"mailto:mrsanna1@gmail.com">mrsanna1@gmail.com</=
a>> wrote:<br>
> On 30 September 2012 17:13, Pasi K=E4rkk=E4inen <<a href=3D"mailto:=
pasik@iki.fi">pasik@iki.fi</a>> wrote:<br>
>> On Sat, Sep 29, 2012 at 02:19:55PM +0200, Mauro wrote:<br>
>>> It's happened another time, system date 50 minutes ahead.<br>
>>> There is really no solution?<br>
>>><br>
>><br>
>> Try with a recent Xen hypervisor version. Xen 4.1.3 or 4.2.0.<br>
>> It helps a lot to know if the issue is still in the latest hypervi=
sor versions or not.<o:p></o:p></p>
</div>
<p class=3D"MsoNormal">There is someone that had the problem and solved usi=
ng a recent xen hypervisor?<o:p></o:p></p>
</div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</body>
</html>

--_000_FF93AF260AC2BB499A119CC65B092CF73148901Bsg000713corproo_--


--===============2670730164236996525==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2670730164236996525==--


From xen-devel-bounces@lists.xen.org Mon Oct 15 08:06:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 08:06:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNfgV-00038C-3A; Mon, 15 Oct 2012 08:05:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Philippe.Simonet@swisscom.com>)
	id 1TNfgT-00037z-7t; Mon, 15 Oct 2012 08:05:57 +0000
Received: from [85.158.139.83:40805] by server-10.bemta-5.messagelabs.com id
	A0/99-01025-4E3CB705; Mon, 15 Oct 2012 08:05:56 +0000
X-Env-Sender: Philippe.Simonet@swisscom.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1350288355!35135736!1
X-Originating-IP: [193.222.81.100]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkzLjIyMi44MS4xMDAgPT4gOTgwNjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21131 invoked from network); 15 Oct 2012 08:05:55 -0000
Received: from outmail100.swisscom.com (HELO mail.swisscom.com)
	(193.222.81.100)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Oct 2012 08:05:55 -0000
Received: by mail.swisscom.com; Mon, 15 Oct 2012 10:05:44 +0200
From: <Philippe.Simonet@swisscom.com>
To: <olivier.hanesse@gmail.com>, <mrsanna1@gmail.com>
Thread-Topic: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
Thread-Index: AQHNqqhpLRDmAIyqN0ORwzY4mO953pe6AR6g
Date: Mon, 15 Oct 2012 08:05:43 +0000
Message-ID: <FF93AF260AC2BB499A119CC65B092CF73148901B@sg000713.corproot.net>
References: <AANLkTikptc2POrKQgJuoVZRdwJTo64DJ_hm12KuPky4D@mail.gmail.com>
	<b1ca6ddc-ca69-447e-93e9-8d36d1ff4a43@default>
	<AANLkTinK94GDOF_GeaVs50wK0u8EdZ2rtzPuh65ca8qR@mail.gmail.com>
	<CAE17a0UPyzsNn=ps9MxarkGg=ns8dCpVz0qBDvesT2AOskwfVg@mail.gmail.com>
	<65395f62-74e5-4910-b701-8df629c2ce3b@default>
	<CABx4GKrQxOOQo_uUXSFvy0nzdMp1A_qc=_e4K+88GkB7xv=9nw@mail.gmail.com>
	<CAE17a0VkMuUEG9VaM7AFrwcsEjVBq9RfvTWz1_KmscAyCxeAbA@mail.gmail.com>
	<CABx4GKqrTEV7CEnAVUfYr-+yky8N5P1U29xDbrESH-mHB0iZhQ@mail.gmail.com>
	<CAE17a0UYwqLxoZaVDgQCvUR2KQK4vvP3bkvsdrwgnsUp33xuNQ@mail.gmail.com>
	<CAE17a0UQocJjZc38c2805uYvdwR7e447UGH9ywcxMw1Ge3imfg@mail.gmail.com>
	<20120930151314.GU8912@reaktio.net>
	<CAE17a0WWvpwW-V5hQOgL1CiuVZFKyzhZVZfTVq74ZsJUo1SE8w@mail.gmail.com>
	<CAE17a0WvLyduj4V68qPJRLcjc5V7xZ=iTNprKWJyGAX_6RXC+Q@mail.gmail.com>
	<CABx4GKr-AxZmCyGmd4qenMtgdo2Yg+UnT4ymbONjBtuS+w=g7Q@mail.gmail.com>
In-Reply-To: <CABx4GKr-AxZmCyGmd4qenMtgdo2Yg+UnT4ymbONjBtuS+w=g7Q@mail.gmail.com>
Accept-Language: en-US, de-CH
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.65.122.36]
MIME-Version: 1.0
Cc: dan.magenheimer@oracle.com, xen-devel@lists.xensource.com, keir@xen.org,
	jeremy@goop.org, keir.xen@gmail.com,
	xen-users@lists.xensource.com, mark@campbell-lange.net
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2670730164236996525=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2670730164236996525==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_FF93AF260AC2BB499A119CC65B092CF73148901Bsg000713corproo_"

--_000_FF93AF260AC2BB499A119CC65B092CF73148901Bsg000713corproo_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Oliver

bad news, this means that xen 4.1xxx doesn't solve this issue ...

on my side, on my  hardware that produce this bug ,I never had the problem =
whit this combination : (100% WHEEZY)
ii  xen-hypervisor-4.1-amd64                  4.1.3-2                   amd=
64        Xen Hypervisor on AMD64
ii  linux-image-3.2.0-3-amd64                 3.2.23-1                  amd=
64        Linux 3.2 for 64-bit PCs

                (this was because I had a great hope that 4.1.xxx solved th=
e problem ...)

Philippe



From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-bounces@lists.xen.o=
rg] On Behalf Of Olivier Hanesse
Sent: Monday, October 15, 2012 9:40 AM
To: Mauro
Cc: Dan Magenheimer; xen-devel@lists.xensource.com; Keir Fraser; Jeremy Fit=
zhardinge; Keir Fraser; Xen Users; Mark Adams
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems

Hello,

Strange things on this rainy morning, I got this bug again on another hardw=
are, and Xen hypervisor from Wheezy and kernel from Squeeze.

ii  linux-image-2.6.32-5-xen-amd64      2.6.32-46                  Linux 2.=
6.32 for 64-bit PCs, Xen dom0 support
ii  xen-hypervisor-4.1-amd64               4.1.3-2                      Xen=
 Hypervisor on AMD64

I've upgraded this server last week. I don't know if it is linked or not, b=
ut I didn't get any 'time wrap' on this server for more than 250days.
Maybe it is related to the upgrade process. Before the upgrade, my version =
were :

ii  linux-image-2.6.32-5-xen-amd64   2.6.32-41squeeze2            Linux 2.6=
.32 for 64-bit PCs, Xen dom0 support
ii  xen-hypervisor-4.1-amd64            4.1.2-2                      Xen Hy=
pervisor on AMD64

I only upgraded half of my servers, so I will wait a little bit to upgrade =
the other half and see if this issue occurs again only on updated servers.

For the record, always the same errors :

xm dmesg =3D> (XEN) Platform timer appears to have unexpectedly wrapped 10 =
or more times.

/var/log/*   =3D> Oct 14 22:46:07 eul2400468 kernel: [734618.562219] Clocks=
ource tsc unstable (delta =3D -2999660313370 ns)

I thought it was this issue was hardware related, maybe not.

Olivier

2012/9/30 Mauro <mrsanna1@gmail.com<mailto:mrsanna1@gmail.com>>
On 30 September 2012 21:23, Mauro <mrsanna1@gmail.com<mailto:mrsanna1@gmail=
.com>> wrote:
> On 30 September 2012 17:13, Pasi K=E4rkk=E4inen <pasik@iki.fi<mailto:pasi=
k@iki.fi>> wrote:
>> On Sat, Sep 29, 2012 at 02:19:55PM +0200, Mauro wrote:
>>> It's happened another time, system date 50 minutes ahead.
>>> There is really no solution?
>>>
>>
>> Try with a recent Xen hypervisor version. Xen 4.1.3 or 4.2.0.
>> It helps a lot to know if the issue is still in the latest hypervisor ve=
rsions or not.
There is someone that had the problem and solved using a recent xen hypervi=
sor?


--_000_FF93AF260AC2BB499A119CC65B092CF73148901Bsg000713corproo_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";
	mso-fareast-language:EN-US;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"FR-CH" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:"Calibri","sans-serif";color:#1F497D">Hi Oliver<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:"Calibri","sans-serif";color:#1F497D"><o:p> =
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:"Calibri","sans-serif";color:#1F497D">bad news, =
this means that xen 4.1xxx doesn’t solve this issue …<o:p></o:p=
></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:"Calibri","sans-serif";color:#1F497D"><o:p> =
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:"Calibri","sans-serif";color:#1F497D">on my side=
, on my  hardware that produce this bug ,I never had the problem whit =
this combination : (100% WHEEZY)<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:"Calibri","sans-serif";color:#1F497D">ii  x=
en-hypervisor-4.1-amd64         &nb=
sp;        4.1.3-2   =
;            &n=
bsp;   amd64        Xen Hyperv=
isor on AMD64<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:"Calibri","sans-serif";color:#1F497D">ii  l=
inux-image-3.2.0-3-amd64        &nb=
sp;        3.2.23-1   &nb=
sp;            =
  amd64        Linux 3.2 for 64-bit=
 PCs<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:"Calibri","sans-serif";color:#1F497D"><o:p> =
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:"Calibri","sans-serif";color:#1F497D"> &nbs=
p;            &=
nbsp; (this was because I had a great hope that 4.1.xxx solved the problem =
…)<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:"Calibri","sans-serif";color:#1F497D"><o:p> =
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:"Calibri","sans-serif";color:#1F497D">Philippe<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:"Calibri","sans-serif";color:#1F497D"><o:p> =
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:"Calibri","sans-serif";color:#1F497D"><o:p> =
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:"Calibri","sans-serif";color:#1F497D"><o:p> =
;</o:p></span></p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal"><b><span lang=3D"EN-US" style=3D"font-size:10.0pt;fo=
nt-family:"Tahoma","sans-serif"">From:</span></b><span =
lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:"Tahoma",&qu=
ot;sans-serif""> xen-devel-bounces@lists.xen.org [mailto:xen-devel-bou=
nces@lists.xen.org]
<b>On Behalf Of </b>Olivier Hanesse<br>
<b>Sent:</b> Monday, October 15, 2012 9:40 AM<br>
<b>To:</b> Mauro<br>
<b>Cc:</b> Dan Magenheimer; xen-devel@lists.xensource.com; Keir Fraser; Jer=
emy Fitzhardinge; Keir Fraser; Xen Users; Mark Adams<br>
<b>Subject:</b> Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems<o:p></o:=
p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoNormal">Hello, <o:p></o:p></p>
<div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class=3D"MsoNormal">Strange things on this rainy morning, I got this bug=
 again on another hardware, and Xen hypervisor from Wheezy and kernel from =
Squeeze.<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<p class=3D"MsoNormal">ii  linux-image-2.6.32-5-xen-amd64    =
;  2.6.32-46                 &=
nbsp;Linux 2.6.32 for 64-bit PCs, Xen dom0 support<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">ii  xen-hypervisor-4.1-amd64     &nbs=
p;         4.1.3-2           &=
nbsp;          Xen Hypervisor on AMD64<o:p></o:p><=
/p>
</div>
<div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class=3D"MsoNormal">I've upgraded this server last week. I don't know if=
 it is linked or not, but I didn't get any 'time wrap' on this server for m=
ore than 250days.<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">Maybe it is related to the upgrade process. Bef=
ore the upgrade, my version were :<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<p class=3D"MsoNormal">ii  linux-image-2.6.32-5-xen-amd64   2.6.3=
2-41squeeze2            Linux 2.6.32 for 64-b=
it PCs, Xen dom0 support<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal">ii  xen-hypervisor-4.1-amd64     &nbs=
p;      4.1.2-2             &n=
bsp;        Xen Hypervisor on AMD64<o:p></o:p></p>
</div>
</div>
<div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class=3D"MsoNormal">I only upgraded half of my servers, so I will wait a=
 little bit to upgrade the other half and see if this issue occurs again on=
ly on updated servers.<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class=3D"MsoNormal">For the record, always the same errors : <o:p><=
/o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class=3D"MsoNormal">xm dmesg =3D> (XEN) Platform timer appears t=
o have unexpectedly wrapped 10 or more times.<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"> <o:p></o:p></p>
</div>
<div>
<div>
<p class=3D"MsoNormal">/var/log/*   =3D> Oct 14 22:46:07 eul2400468=
 kernel: [734618.562219] Clocksource tsc unstable (delta =3D -2999660313370=
 ns)<o:p></o:p></p>
</div>
</div>
<div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class=3D"MsoNormal">I thought it was this issue was hardware related, ma=
ybe not.<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class=3D"MsoNormal">Olivier<o:p></o:p></p>
</div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<div>
<p class=3D"MsoNormal">2012/9/30 Mauro <<a href=3D"mailto:mrsanna1@gmail=
.com" target=3D"_blank">mrsanna1@gmail.com</a>><o:p></o:p></p>
<div>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">On 30 September 2012 =
21:23, Mauro <<a href=3D"mailto:mrsanna1@gmail.com">mrsanna1@gmail.com</=
a>> wrote:<br>
> On 30 September 2012 17:13, Pasi K=E4rkk=E4inen <<a href=3D"mailto:=
pasik@iki.fi">pasik@iki.fi</a>> wrote:<br>
>> On Sat, Sep 29, 2012 at 02:19:55PM +0200, Mauro wrote:<br>
>>> It's happened another time, system date 50 minutes ahead.<br>
>>> There is really no solution?<br>
>>><br>
>><br>
>> Try with a recent Xen hypervisor version. Xen 4.1.3 or 4.2.0.<br>
>> It helps a lot to know if the issue is still in the latest hypervi=
sor versions or not.<o:p></o:p></p>
</div>
<p class=3D"MsoNormal">There is someone that had the problem and solved usi=
ng a recent xen hypervisor?<o:p></o:p></p>
</div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</body>
</html>

--_000_FF93AF260AC2BB499A119CC65B092CF73148901Bsg000713corproo_--


--===============2670730164236996525==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2670730164236996525==--


From xen-devel-bounces@lists.xen.org Mon Oct 15 08:13:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 08:13:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNfnf-0003at-3a; Mon, 15 Oct 2012 08:13:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xinxinjin89@gmail.com>) id 1TNfne-0003an-FU
	for Xen-devel@lists.xen.org; Mon, 15 Oct 2012 08:13:22 +0000
Received: from [85.158.138.51:27126] by server-9.bemta-3.messagelabs.com id
	F0/C6-16841-1A5CB705; Mon, 15 Oct 2012 08:13:21 +0000
X-Env-Sender: xinxinjin89@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1350288796!34457929!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13670 invoked from network); 15 Oct 2012 08:13:21 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 08:13:21 -0000
Received: by mail-qc0-f173.google.com with SMTP id b12so4820831qca.32
	for <Xen-devel@lists.xen.org>; Mon, 15 Oct 2012 01:13:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=LTNvyA6ahLo6dTo7YSNIcMe+/IDwwBPIgwBMQG8JFO0=;
	b=MvVt6lGMsZ31TavG/0MYJIhYzoDM7cpgP5l+7fbp0DpMh0WgMTHbTEsiz6mWf8YE2o
	rKe/c7HfaeeCEFJXc0Umypeh63v+oGJpNRtub3dh5VXz7MHIIs+g5Q7vMj4fIefsP/sH
	foGzi1rXUkn/XVYOBNp7L2GhR6gA4guigfNcAOYxwSyPvQv9H6COHE8SeYQvRfeJstvH
	a379mQhAXPF5A5m8urLoVZ1DMBzFcgan6yd/Iyfs0H3wx6+XpH8Yxwy/VmBP0WWwujZQ
	hNcZlBie4KGgIoY2xLYUITlSgt+uqBkW6QAMH1pvnedjMpWX3t5Ce2pMeHCz11a4estL
	uffg==
MIME-Version: 1.0
Received: by 10.49.72.3 with SMTP id z3mr26179726qeu.19.1350288795830; Mon, 15
	Oct 2012 01:13:15 -0700 (PDT)
Received: by 10.229.74.9 with HTTP; Mon, 15 Oct 2012 01:13:15 -0700 (PDT)
In-Reply-To: <1350288020.14440.4.camel@dagon.hellion.org.uk>
References: <CAJJWZcwhKx6Fz6R9atAUbOSOuVRzRg8Dc8tOO2DLFUNcp5rZwA@mail.gmail.com>
	<1350288020.14440.4.camel@dagon.hellion.org.uk>
Date: Mon, 15 Oct 2012 01:13:15 -0700
Message-ID: <CAJJWZcxRKKzDMdcC8=10m-cpnDaoQjL+e5Bn-1By1KigX3r5Ew@mail.gmail.com>
From: Xinxin Jin <xinxinjin89@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] put_page in ptwr_do_page_fault
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0006713232336029964=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0006713232336029964==
Content-Type: multipart/alternative; boundary=047d7b6da0f00508bd04cc149cba

--047d7b6da0f00508bd04cc149cba
Content-Type: text/plain; charset=ISO-8859-1

Hmmm, put_page() release the page, but seems get_page_from_pagenr() does
not allocate a page ? Thanks !

On Mon, Oct 15, 2012 at 1:00 AM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> On Mon, 2012-10-15 at 07:43 +0100, Xinxin Jin wrote:
> > Hi all,
> > I am trying to understand write page table handler for PV guests. I
> > got the core of ptwr_do_page_fault is x86_emulate() which will emulate
> > the write operation in Xen. But why after that Xen calls  put_page()
> > to free the page mapped to the PTE ? The code snapshot is as follows:
>
> The put_page balances the get_page inside get_page_from_pagenr which is
> in the code you trimmed out below.
>
> Ian.
>
>
>
>


-- 
Xinxin

--047d7b6da0f00508bd04cc149cba
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hmmm, put_page() release the page, but seems=A0get_page_from_pagenr()=A0doe=
s not allocate a page ? Thanks !<br><br><div class=3D"gmail_quote">On Mon, =
Oct 15, 2012 at 1:00 AM, Ian Campbell <span dir=3D"ltr"><<a href=3D"mail=
to:Ian.Campbell@citrix.com" target=3D"_blank">Ian.Campbell@citrix.com</a>&g=
t;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Mon, 2012-10-15 at 07:4=
3 +0100, Xinxin Jin wrote:<br>
> Hi all,<br>
> I am trying to understand write page table handler for PV guests. I<br=
>
> got the core of ptwr_do_page_fault is x86_emulate() which will emulate=
<br>
> the write operation in Xen. But why after that Xen calls =A0put_page()=
<br>
> to free the page mapped to the PTE ? The code snapshot is as follows:<=
br>
<br>
</div>The put_page balances the get_page inside get_page_from_pagenr which =
is<br>
in the code you trimmed out below.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Ian.<br>
<br>
<br>
<br>
</font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b=
r>Xinxin<br>

--047d7b6da0f00508bd04cc149cba--


--===============0006713232336029964==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0006713232336029964==--


From xen-devel-bounces@lists.xen.org Mon Oct 15 08:13:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 08:13:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNfnf-0003at-3a; Mon, 15 Oct 2012 08:13:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xinxinjin89@gmail.com>) id 1TNfne-0003an-FU
	for Xen-devel@lists.xen.org; Mon, 15 Oct 2012 08:13:22 +0000
Received: from [85.158.138.51:27126] by server-9.bemta-3.messagelabs.com id
	F0/C6-16841-1A5CB705; Mon, 15 Oct 2012 08:13:21 +0000
X-Env-Sender: xinxinjin89@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1350288796!34457929!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13670 invoked from network); 15 Oct 2012 08:13:21 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 08:13:21 -0000
Received: by mail-qc0-f173.google.com with SMTP id b12so4820831qca.32
	for <Xen-devel@lists.xen.org>; Mon, 15 Oct 2012 01:13:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=LTNvyA6ahLo6dTo7YSNIcMe+/IDwwBPIgwBMQG8JFO0=;
	b=MvVt6lGMsZ31TavG/0MYJIhYzoDM7cpgP5l+7fbp0DpMh0WgMTHbTEsiz6mWf8YE2o
	rKe/c7HfaeeCEFJXc0Umypeh63v+oGJpNRtub3dh5VXz7MHIIs+g5Q7vMj4fIefsP/sH
	foGzi1rXUkn/XVYOBNp7L2GhR6gA4guigfNcAOYxwSyPvQv9H6COHE8SeYQvRfeJstvH
	a379mQhAXPF5A5m8urLoVZ1DMBzFcgan6yd/Iyfs0H3wx6+XpH8Yxwy/VmBP0WWwujZQ
	hNcZlBie4KGgIoY2xLYUITlSgt+uqBkW6QAMH1pvnedjMpWX3t5Ce2pMeHCz11a4estL
	uffg==
MIME-Version: 1.0
Received: by 10.49.72.3 with SMTP id z3mr26179726qeu.19.1350288795830; Mon, 15
	Oct 2012 01:13:15 -0700 (PDT)
Received: by 10.229.74.9 with HTTP; Mon, 15 Oct 2012 01:13:15 -0700 (PDT)
In-Reply-To: <1350288020.14440.4.camel@dagon.hellion.org.uk>
References: <CAJJWZcwhKx6Fz6R9atAUbOSOuVRzRg8Dc8tOO2DLFUNcp5rZwA@mail.gmail.com>
	<1350288020.14440.4.camel@dagon.hellion.org.uk>
Date: Mon, 15 Oct 2012 01:13:15 -0700
Message-ID: <CAJJWZcxRKKzDMdcC8=10m-cpnDaoQjL+e5Bn-1By1KigX3r5Ew@mail.gmail.com>
From: Xinxin Jin <xinxinjin89@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] put_page in ptwr_do_page_fault
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0006713232336029964=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0006713232336029964==
Content-Type: multipart/alternative; boundary=047d7b6da0f00508bd04cc149cba

--047d7b6da0f00508bd04cc149cba
Content-Type: text/plain; charset=ISO-8859-1

Hmmm, put_page() release the page, but seems get_page_from_pagenr() does
not allocate a page ? Thanks !

On Mon, Oct 15, 2012 at 1:00 AM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> On Mon, 2012-10-15 at 07:43 +0100, Xinxin Jin wrote:
> > Hi all,
> > I am trying to understand write page table handler for PV guests. I
> > got the core of ptwr_do_page_fault is x86_emulate() which will emulate
> > the write operation in Xen. But why after that Xen calls  put_page()
> > to free the page mapped to the PTE ? The code snapshot is as follows:
>
> The put_page balances the get_page inside get_page_from_pagenr which is
> in the code you trimmed out below.
>
> Ian.
>
>
>
>


-- 
Xinxin

--047d7b6da0f00508bd04cc149cba
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hmmm, put_page() release the page, but seems=A0get_page_from_pagenr()=A0doe=
s not allocate a page ? Thanks !<br><br><div class=3D"gmail_quote">On Mon, =
Oct 15, 2012 at 1:00 AM, Ian Campbell <span dir=3D"ltr"><<a href=3D"mail=
to:Ian.Campbell@citrix.com" target=3D"_blank">Ian.Campbell@citrix.com</a>&g=
t;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Mon, 2012-10-15 at 07:4=
3 +0100, Xinxin Jin wrote:<br>
> Hi all,<br>
> I am trying to understand write page table handler for PV guests. I<br=
>
> got the core of ptwr_do_page_fault is x86_emulate() which will emulate=
<br>
> the write operation in Xen. But why after that Xen calls =A0put_page()=
<br>
> to free the page mapped to the PTE ? The code snapshot is as follows:<=
br>
<br>
</div>The put_page balances the get_page inside get_page_from_pagenr which =
is<br>
in the code you trimmed out below.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Ian.<br>
<br>
<br>
<br>
</font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b=
r>Xinxin<br>

--047d7b6da0f00508bd04cc149cba--


--===============0006713232336029964==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0006713232336029964==--


From xen-devel-bounces@lists.xen.org Mon Oct 15 08:39:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 08:39:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNgCh-0004YV-Tr; Mon, 15 Oct 2012 08:39:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TNgCh-0004YQ-5I
	for Xen-devel@lists.xen.org; Mon, 15 Oct 2012 08:39:15 +0000
Received: from [85.158.138.51:17376] by server-7.bemta-3.messagelabs.com id
	DE/AC-06991-2BBCB705; Mon, 15 Oct 2012 08:39:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1350290353!25499447!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxNzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32733 invoked from network); 15 Oct 2012 08:39:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 08:39:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="15162657"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 08:39:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 09:39:13 +0100
Message-ID: <1350290351.14806.124.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Xinxin Jin <xinxinjin89@gmail.com>
Date: Mon, 15 Oct 2012 09:39:11 +0100
In-Reply-To: <CAJJWZcxRKKzDMdcC8=10m-cpnDaoQjL+e5Bn-1By1KigX3r5Ew@mail.gmail.com>
References: <CAJJWZcwhKx6Fz6R9atAUbOSOuVRzRg8Dc8tOO2DLFUNcp5rZwA@mail.gmail.com>
	<1350288020.14440.4.camel@dagon.hellion.org.uk>
	<CAJJWZcxRKKzDMdcC8=10m-cpnDaoQjL+e5Bn-1By1KigX3r5Ew@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] put_page in ptwr_do_page_fault
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Please don't top post.

On Mon, 2012-10-15 at 09:13 +0100, Xinxin Jin wrote:
> Hmmm, put_page() release the page, but seems get_page_from_pagenr()
> does not allocate a page ? Thanks !

It's implementing reference counting.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 08:39:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 08:39:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNgCh-0004YV-Tr; Mon, 15 Oct 2012 08:39:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TNgCh-0004YQ-5I
	for Xen-devel@lists.xen.org; Mon, 15 Oct 2012 08:39:15 +0000
Received: from [85.158.138.51:17376] by server-7.bemta-3.messagelabs.com id
	DE/AC-06991-2BBCB705; Mon, 15 Oct 2012 08:39:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1350290353!25499447!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxNzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32733 invoked from network); 15 Oct 2012 08:39:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 08:39:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="15162657"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 08:39:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 09:39:13 +0100
Message-ID: <1350290351.14806.124.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Xinxin Jin <xinxinjin89@gmail.com>
Date: Mon, 15 Oct 2012 09:39:11 +0100
In-Reply-To: <CAJJWZcxRKKzDMdcC8=10m-cpnDaoQjL+e5Bn-1By1KigX3r5Ew@mail.gmail.com>
References: <CAJJWZcwhKx6Fz6R9atAUbOSOuVRzRg8Dc8tOO2DLFUNcp5rZwA@mail.gmail.com>
	<1350288020.14440.4.camel@dagon.hellion.org.uk>
	<CAJJWZcxRKKzDMdcC8=10m-cpnDaoQjL+e5Bn-1By1KigX3r5Ew@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] put_page in ptwr_do_page_fault
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Please don't top post.

On Mon, 2012-10-15 at 09:13 +0100, Xinxin Jin wrote:
> Hmmm, put_page() release the page, but seems get_page_from_pagenr()
> does not allocate a page ? Thanks !

It's implementing reference counting.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 08:43:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 08:43:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNgGJ-0004lW-6J; Mon, 15 Oct 2012 08:42:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1TNgGI-0004lA-6F
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 08:42:58 +0000
Received: from [85.158.143.99:56506] by server-3.bemta-4.messagelabs.com id
	ED/97-10075-E8CCB705; Mon, 15 Oct 2012 08:42:54 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-216.messagelabs.com!1350290573!28004761!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MzMxMDQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MzMxMDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9758 invoked from network); 15 Oct 2012 08:42:54 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Oct 2012 08:42:54 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGjy0PFENx
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-081-177.pools.arcor-ip.net [88.65.81.177])
	by smtp.strato.de (jorabe mo10) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 9057c6o9F8P3M6 ;
	Mon, 15 Oct 2012 10:42:53 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 3452318642; Mon, 15 Oct 2012 10:42:53 +0200 (CEST)
Date: Mon, 15 Oct 2012 10:42:53 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20121015084252.GA27650@aepfle.de>
References: <5aa14d5afe6b1f35b230.1350143968@probook.site>
	<20121013223558.GA19665@aepfle.de>
	<1350288065.14440.5.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1350288065.14440.5.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] hotplug/Linux: close lockfd after lock
 attempt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 15, Ian Campbell wrote:

> On Sat, 2012-10-13 at 23:35 +0100, Olaf Hering wrote:
> > On Sat, Oct 13, Olaf Hering wrote:
> > 
> > > hotplug/Linux: close lockfd after lock attempt
> > > 
> > > When a HVM guest is shutdown some of the 'remove' events can not claim
> > > the lock for some reason. Instead they try to grab the lock in a busy
> > > loop, until udev reaps the xen-hotplug-cleanup helper.
> > > After analyzing the resulting logfile its not obvious what the cause is.
> > > The only explanation is that bash (?) gets confused if the same lockfd
> > > is opened again and again. Closing it in each iteration seem to fix the
> > > issue.
> > 
> > Can be reproduced with this testcase on sles11sp2, not on openSuSE 11.4:
> 
> So this is a bash bug? Have you reported it against bash?

It does not happen with a newer bash: bash 3.2 from sles11sp2 fails,
bash 4.1 from openSuSE 11.4 works.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 08:43:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 08:43:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNgGJ-0004lW-6J; Mon, 15 Oct 2012 08:42:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1TNgGI-0004lA-6F
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 08:42:58 +0000
Received: from [85.158.143.99:56506] by server-3.bemta-4.messagelabs.com id
	ED/97-10075-E8CCB705; Mon, 15 Oct 2012 08:42:54 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-216.messagelabs.com!1350290573!28004761!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MzMxMDQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MzMxMDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9758 invoked from network); 15 Oct 2012 08:42:54 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Oct 2012 08:42:54 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGjy0PFENx
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-081-177.pools.arcor-ip.net [88.65.81.177])
	by smtp.strato.de (jorabe mo10) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 9057c6o9F8P3M6 ;
	Mon, 15 Oct 2012 10:42:53 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 3452318642; Mon, 15 Oct 2012 10:42:53 +0200 (CEST)
Date: Mon, 15 Oct 2012 10:42:53 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20121015084252.GA27650@aepfle.de>
References: <5aa14d5afe6b1f35b230.1350143968@probook.site>
	<20121013223558.GA19665@aepfle.de>
	<1350288065.14440.5.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1350288065.14440.5.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] hotplug/Linux: close lockfd after lock
 attempt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 15, Ian Campbell wrote:

> On Sat, 2012-10-13 at 23:35 +0100, Olaf Hering wrote:
> > On Sat, Oct 13, Olaf Hering wrote:
> > 
> > > hotplug/Linux: close lockfd after lock attempt
> > > 
> > > When a HVM guest is shutdown some of the 'remove' events can not claim
> > > the lock for some reason. Instead they try to grab the lock in a busy
> > > loop, until udev reaps the xen-hotplug-cleanup helper.
> > > After analyzing the resulting logfile its not obvious what the cause is.
> > > The only explanation is that bash (?) gets confused if the same lockfd
> > > is opened again and again. Closing it in each iteration seem to fix the
> > > issue.
> > 
> > Can be reproduced with this testcase on sles11sp2, not on openSuSE 11.4:
> 
> So this is a bash bug? Have you reported it against bash?

It does not happen with a newer bash: bash 3.2 from sles11sp2 fails,
bash 4.1 from openSuSE 11.4 works.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 08:58:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 08:58:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNgVB-0005CG-MR; Mon, 15 Oct 2012 08:58:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TNgVA-0005CB-D3
	for Xen-devel@lists.xensource.com; Mon, 15 Oct 2012 08:58:20 +0000
Received: from [85.158.143.99:47661] by server-3.bemta-4.messagelabs.com id
	BB/34-10075-B20DB705; Mon, 15 Oct 2012 08:58:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1350291499!34106737!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxNzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19479 invoked from network); 15 Oct 2012 08:58:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 08:58:19 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="15163228"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 08:58:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 09:58:18 +0100
Message-ID: <1350291497.18058.5.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Mon, 15 Oct 2012 09:58:17 +0100
In-Reply-To: <20121012120619.6d8f3317@mantra.us.oracle.com>
References: <20121011145711.0d9c27df@mantra.us.oracle.com>
	<1350031937.14806.49.camel@zakaz.uk.xensource.com>
	<20121012120619.6d8f3317@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH V2 2/7]: PVH: use native irq, enable callback,
 use HVM ring ops, ...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-12 at 20:06 +0100, Mukesh Rathor wrote:
> On Fri, 12 Oct 2012 09:52:17 +0100
> Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> > >  drivers/xen/cpu_hotplug.c            |    4 +++-
> > >  drivers/xen/events.c                 |    9 ++++++++-
> > >  drivers/xen/xenbus/xenbus_client.c   |    3 ++-
> > >  7 files changed, 27 insertions(+), 8 deletions(-)
> > > 
> > > diff --git a/arch/x86/include/asm/xen/interface.h
> > > b/arch/x86/include/asm/xen/interface.h index 555f94d..f11edb0 100644
> > > --- a/arch/x86/include/asm/xen/interface.h
> > > +++ b/arch/x86/include/asm/xen/interface.h
> > > @@ -143,7 +143,13 @@ struct vcpu_guest_context {
> > >      struct cpu_user_regs user_regs;         /* User-level CPU
> > > registers     */ struct trap_info trap_ctxt[256];        /* Virtual
> > > IDT                  */ unsigned long ldt_base, ldt_ents;       /*
> > > LDT (linear address, # ents) */
> > > -    unsigned long gdt_frames[16], gdt_ents; /* GDT (machine
> > > frames, # ents) */
> > > +    union {
> > > +	struct {
> > > +		/* PV: GDT (machine frames, # ents).*/
> > > +		unsigned long gdt_frames[16], gdt_ents;
> > > +	} s;
> > > +	unsigned long gdtaddr, gdtsz;	    /* PVH: GDTR addr
> > > and size */
> > 
> > I've pointed out a few times that I think this is wrong -- gdtaddr and
> > gdtsz will overlap each other in the union. I'm not sure how it even
> > works, unless the hypervisor is ignoring one or the other. You need:
> > 
> > union {
> > 	struct {
> > 		unsigned long gdt_frames[16], gdt_ents;
> > 	} pv;
> > 	struct {
> > 		unsigned long gdtaddr, gdtsz;
> > 	} pvh;
> > } gdt;
> > 
> > (I've gone with naming the union gdt instead of u. You might want
> > therefore to also drop the gdt prefix from the members?)
> 
> Is it worth it, I mean, making it a union. Would you be OK if I just
> used gdt_frames[0] and gdt_ends for gdtaddr and size?

What's the problem with making it a union? Seems like you are 80% of the
way there.

Why is this different between PV and PVH in the first place (at the API
level I mean, obviously the handling in the h/v will differ)?

At the very least gdtsz and gdt_ents are the same thing with different
units AFAICT and so can be combined.

How come you don't need the same stuff for ldt*?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 08:58:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 08:58:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNgVB-0005CG-MR; Mon, 15 Oct 2012 08:58:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TNgVA-0005CB-D3
	for Xen-devel@lists.xensource.com; Mon, 15 Oct 2012 08:58:20 +0000
Received: from [85.158.143.99:47661] by server-3.bemta-4.messagelabs.com id
	BB/34-10075-B20DB705; Mon, 15 Oct 2012 08:58:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1350291499!34106737!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxNzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19479 invoked from network); 15 Oct 2012 08:58:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 08:58:19 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="15163228"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 08:58:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 09:58:18 +0100
Message-ID: <1350291497.18058.5.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Mon, 15 Oct 2012 09:58:17 +0100
In-Reply-To: <20121012120619.6d8f3317@mantra.us.oracle.com>
References: <20121011145711.0d9c27df@mantra.us.oracle.com>
	<1350031937.14806.49.camel@zakaz.uk.xensource.com>
	<20121012120619.6d8f3317@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH V2 2/7]: PVH: use native irq, enable callback,
 use HVM ring ops, ...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-12 at 20:06 +0100, Mukesh Rathor wrote:
> On Fri, 12 Oct 2012 09:52:17 +0100
> Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> > >  drivers/xen/cpu_hotplug.c            |    4 +++-
> > >  drivers/xen/events.c                 |    9 ++++++++-
> > >  drivers/xen/xenbus/xenbus_client.c   |    3 ++-
> > >  7 files changed, 27 insertions(+), 8 deletions(-)
> > > 
> > > diff --git a/arch/x86/include/asm/xen/interface.h
> > > b/arch/x86/include/asm/xen/interface.h index 555f94d..f11edb0 100644
> > > --- a/arch/x86/include/asm/xen/interface.h
> > > +++ b/arch/x86/include/asm/xen/interface.h
> > > @@ -143,7 +143,13 @@ struct vcpu_guest_context {
> > >      struct cpu_user_regs user_regs;         /* User-level CPU
> > > registers     */ struct trap_info trap_ctxt[256];        /* Virtual
> > > IDT                  */ unsigned long ldt_base, ldt_ents;       /*
> > > LDT (linear address, # ents) */
> > > -    unsigned long gdt_frames[16], gdt_ents; /* GDT (machine
> > > frames, # ents) */
> > > +    union {
> > > +	struct {
> > > +		/* PV: GDT (machine frames, # ents).*/
> > > +		unsigned long gdt_frames[16], gdt_ents;
> > > +	} s;
> > > +	unsigned long gdtaddr, gdtsz;	    /* PVH: GDTR addr
> > > and size */
> > 
> > I've pointed out a few times that I think this is wrong -- gdtaddr and
> > gdtsz will overlap each other in the union. I'm not sure how it even
> > works, unless the hypervisor is ignoring one or the other. You need:
> > 
> > union {
> > 	struct {
> > 		unsigned long gdt_frames[16], gdt_ents;
> > 	} pv;
> > 	struct {
> > 		unsigned long gdtaddr, gdtsz;
> > 	} pvh;
> > } gdt;
> > 
> > (I've gone with naming the union gdt instead of u. You might want
> > therefore to also drop the gdt prefix from the members?)
> 
> Is it worth it, I mean, making it a union. Would you be OK if I just
> used gdt_frames[0] and gdt_ends for gdtaddr and size?

What's the problem with making it a union? Seems like you are 80% of the
way there.

Why is this different between PV and PVH in the first place (at the API
level I mean, obviously the handling in the h/v will differ)?

At the very least gdtsz and gdt_ents are the same thing with different
units AFAICT and so can be combined.

How come you don't need the same stuff for ldt*?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 09:17:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 09:17:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNgnj-0005m1-8y; Mon, 15 Oct 2012 09:17:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TNgnh-0005lw-Ve
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 09:17:30 +0000
Received: from [85.158.143.99:31750] by server-3.bemta-4.messagelabs.com id
	41/4B-10075-9A4DB705; Mon, 15 Oct 2012 09:17:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1350292648!24351543!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32515 invoked from network); 15 Oct 2012 09:17:28 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-216.messagelabs.com with SMTP;
	15 Oct 2012 09:17:28 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 15 Oct 2012 10:17:28 +0100
Message-Id: <507BF0C502000078000A1484@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 15 Oct 2012 10:17:25 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <patchbomb.1349720160@andrewcoop.uk.xensource.com>
	<477ccdb9870ed68e33c5.1349720162@andrewcoop.uk.xensource.com>
In-Reply-To: <477ccdb9870ed68e33c5.1349720162@andrewcoop.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2 of 3] xen/debug: Introduce ASSERT_PRINTK()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 08.10.12 at 20:16, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> This is a variant of ASSERT() which takes a predicate, and a variable
> number of arguments which get fed to prink() before the BUG().
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> 
> --
> This does use C99 varadic macros, but given that we use other C99
> features without #ifdef guards, I felt it not necessary to guard this as
> well.
> 
> diff -r 2927e18e9a7c -r 477ccdb9870e xen/include/xen/lib.h
> --- a/xen/include/xen/lib.h
> +++ b/xen/include/xen/lib.h
> @@ -38,11 +38,26 @@ do {                                    
>  } while (0)
>  #endif
>  
> +#ifndef assert_printk_failed
> +#define assert_printk_failed(p, ...)                            \
> +do {                                                            \
> +    printk("Assertion '%s' failed, line %d, file %s\n", p ,     \
> +                   __LINE__, __FILE__);                         \
> +    printk(__VA_ARGS__);                                        \

The first argument here necessarily is a format string, so it
should also be enforced that way. Which then opens the
question whether the two printk()-s shouldn't be folded (at the
price of requiring the format string to be a literal).

I wonder though whether we wouldn't be better off following
Linux'es WARN() et al infrastructure, rather than extending the
ASSERT() one.

Jan

> +    BUG();                                                      \
> +} while (0)
> +#endif /* assert_printk_failed */
> +
>  #ifdef CONFIG_ASSERTS
>  #define ASSERT(p) \
>      do { if ( unlikely(!(p)) ) assert_failed(#p); } while (0)
> +
> +#define ASSERT_PRINTK(p, ...)                                   \
> +    do { if ( unlikely(!(p)) )                                  \
> +            assert_printk_failed(#p, __VA_ARGS__); } while (0)
>  #else
>  #define ASSERT(p) do { if ( 0 && (p) ); } while (0)
> +#define ASSERT_PRINTK(p, ...) do { if ( 0 && (p) ); } while (0)
>  #endif
>  
>  #define ABS(_x) ({                              \




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 09:17:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 09:17:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNgnj-0005m1-8y; Mon, 15 Oct 2012 09:17:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TNgnh-0005lw-Ve
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 09:17:30 +0000
Received: from [85.158.143.99:31750] by server-3.bemta-4.messagelabs.com id
	41/4B-10075-9A4DB705; Mon, 15 Oct 2012 09:17:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1350292648!24351543!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32515 invoked from network); 15 Oct 2012 09:17:28 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-216.messagelabs.com with SMTP;
	15 Oct 2012 09:17:28 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 15 Oct 2012 10:17:28 +0100
Message-Id: <507BF0C502000078000A1484@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 15 Oct 2012 10:17:25 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <patchbomb.1349720160@andrewcoop.uk.xensource.com>
	<477ccdb9870ed68e33c5.1349720162@andrewcoop.uk.xensource.com>
In-Reply-To: <477ccdb9870ed68e33c5.1349720162@andrewcoop.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2 of 3] xen/debug: Introduce ASSERT_PRINTK()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 08.10.12 at 20:16, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> This is a variant of ASSERT() which takes a predicate, and a variable
> number of arguments which get fed to prink() before the BUG().
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> 
> --
> This does use C99 varadic macros, but given that we use other C99
> features without #ifdef guards, I felt it not necessary to guard this as
> well.
> 
> diff -r 2927e18e9a7c -r 477ccdb9870e xen/include/xen/lib.h
> --- a/xen/include/xen/lib.h
> +++ b/xen/include/xen/lib.h
> @@ -38,11 +38,26 @@ do {                                    
>  } while (0)
>  #endif
>  
> +#ifndef assert_printk_failed
> +#define assert_printk_failed(p, ...)                            \
> +do {                                                            \
> +    printk("Assertion '%s' failed, line %d, file %s\n", p ,     \
> +                   __LINE__, __FILE__);                         \
> +    printk(__VA_ARGS__);                                        \

The first argument here necessarily is a format string, so it
should also be enforced that way. Which then opens the
question whether the two printk()-s shouldn't be folded (at the
price of requiring the format string to be a literal).

I wonder though whether we wouldn't be better off following
Linux'es WARN() et al infrastructure, rather than extending the
ASSERT() one.

Jan

> +    BUG();                                                      \
> +} while (0)
> +#endif /* assert_printk_failed */
> +
>  #ifdef CONFIG_ASSERTS
>  #define ASSERT(p) \
>      do { if ( unlikely(!(p)) ) assert_failed(#p); } while (0)
> +
> +#define ASSERT_PRINTK(p, ...)                                   \
> +    do { if ( unlikely(!(p)) )                                  \
> +            assert_printk_failed(#p, __VA_ARGS__); } while (0)
>  #else
>  #define ASSERT(p) do { if ( 0 && (p) ); } while (0)
> +#define ASSERT_PRINTK(p, ...) do { if ( 0 && (p) ); } while (0)
>  #endif
>  
>  #define ABS(_x) ({                              \




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 09:19:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 09:19:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNgp5-0005qk-Ps; Mon, 15 Oct 2012 09:18:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TNgp4-0005qP-Fh
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 09:18:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1350292727!4879514!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4686 invoked from network); 15 Oct 2012 09:18:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 09:18:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="15163879"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 09:18:47 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 10:18:47 +0100
Message-ID: <1350292726.18058.6.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 15 Oct 2012 10:18:46 +0100
In-Reply-To: <20600.17791.486117.993788@mariner.uk.xensource.com>
References: <1350056739.14806.119.camel@zakaz.uk.xensource.com>
	<1350057020.14806.120.camel@zakaz.uk.xensource.com>
	<1350057962.14806.122.camel@zakaz.uk.xensource.com>
	<20600.17791.486117.993788@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Unable to start a domain with no disks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-12 at 17:29 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] Unable to start a domain with no disks"):
> > On Fri, 2012-10-12 at 16:50 +0100, Ian Campbell wrote:
> > > On Fri, 2012-10-12 at 16:45 +0100, Ian Campbell wrote:
> > > > Trying to start a very simple domain with no disk from:
> 
> > > This makes the issue go away but since this function also free's the ao
> > > I think there must be a use after free somewhere.
> 
> In this case what happens is that the tty available event gets queued
> in the outer egc, which survives until after libxl__ao_inprogress has
> returned.  You only see the bug with no disks because with disks the
> events are only generated later in the event loop inside
> libxl__ao_inprogress.
> 
> Ian.
> 
> 
> Subject: [PATCH] libxl: ao: cope with fast ao completion with progess events
> 
> There are two egcs in an ao initiator: the one in the AO_CREATE
> function, and the one in libxl__ao_inprogress.  If synchronous ao
> operation generates progress events and completes immediately, the
> progress callbacks end up queued in the outer egc.  These callbacks
> are currently only called after libxl__ao_inprogress has returned, and
> keep the ao alive until they happen.  This is not good because the
> principle is that a synchronous ao is not supposed to survive beyond
> libxl__ao_inprogress's return.
> 
> The fix is to ensure that the callbacks queued in the outer egc are
> called early enough that they don't preserve the ao.  This is
> straightforward in the AO_INPROGRESS macro because AO_CREATE's egc is
> not used inside that macro other than to destroy it.  All we have to
> do is destroy it a bit sooner.
> 
> This involves unlocking and relocking the ctx since EGC_FREE expects
> to be called with the lock released but libxl__ao_inprogress needs it
> locked.  The is hole in our lock tenure is fine - libxl__ao_inprogress
> has such holes already.
> 
> It is still possible to use the CTX_LOCK macros for this unlock/lock
> because the gc we are using is destroyed only afterwards by
> libxl__ao_inprogress.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> diff -r 8aadb3204cfa tools/libxl/libxl_internal.h
> --- a/tools/libxl/libxl_internal.h	Thu Sep 06 21:41:27 2012 +0200
> +++ b/tools/libxl/libxl_internal.h	Fri Oct 12 17:20:10 2012 +0100
> @@ -1709,10 +1709,12 @@ _hidden void libxl__egc_cleanup(libxl__e
>  
>  #define AO_INPROGRESS ({                                        \
>          libxl_ctx *ao__ctx = libxl__gc_owner(&ao->gc);          \
> +        CTX_UNLOCK;                                             \
> +        EGC_FREE;                                               \
> +        CTX_LOCK;                                               \
>          int ao__rc = libxl__ao_inprogress(ao,                   \
>                                 __FILE__, __LINE__, __func__);   \
>          libxl__ctx_unlock(ao__ctx); /* gc is now invalid */     \
> -        EGC_FREE;                                               \
>          (ao__rc);                                               \
>     })
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 09:19:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 09:19:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNgp5-0005qk-Ps; Mon, 15 Oct 2012 09:18:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TNgp4-0005qP-Fh
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 09:18:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1350292727!4879514!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4686 invoked from network); 15 Oct 2012 09:18:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 09:18:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="15163879"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 09:18:47 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 10:18:47 +0100
Message-ID: <1350292726.18058.6.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 15 Oct 2012 10:18:46 +0100
In-Reply-To: <20600.17791.486117.993788@mariner.uk.xensource.com>
References: <1350056739.14806.119.camel@zakaz.uk.xensource.com>
	<1350057020.14806.120.camel@zakaz.uk.xensource.com>
	<1350057962.14806.122.camel@zakaz.uk.xensource.com>
	<20600.17791.486117.993788@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Unable to start a domain with no disks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-12 at 17:29 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] Unable to start a domain with no disks"):
> > On Fri, 2012-10-12 at 16:50 +0100, Ian Campbell wrote:
> > > On Fri, 2012-10-12 at 16:45 +0100, Ian Campbell wrote:
> > > > Trying to start a very simple domain with no disk from:
> 
> > > This makes the issue go away but since this function also free's the ao
> > > I think there must be a use after free somewhere.
> 
> In this case what happens is that the tty available event gets queued
> in the outer egc, which survives until after libxl__ao_inprogress has
> returned.  You only see the bug with no disks because with disks the
> events are only generated later in the event loop inside
> libxl__ao_inprogress.
> 
> Ian.
> 
> 
> Subject: [PATCH] libxl: ao: cope with fast ao completion with progess events
> 
> There are two egcs in an ao initiator: the one in the AO_CREATE
> function, and the one in libxl__ao_inprogress.  If synchronous ao
> operation generates progress events and completes immediately, the
> progress callbacks end up queued in the outer egc.  These callbacks
> are currently only called after libxl__ao_inprogress has returned, and
> keep the ao alive until they happen.  This is not good because the
> principle is that a synchronous ao is not supposed to survive beyond
> libxl__ao_inprogress's return.
> 
> The fix is to ensure that the callbacks queued in the outer egc are
> called early enough that they don't preserve the ao.  This is
> straightforward in the AO_INPROGRESS macro because AO_CREATE's egc is
> not used inside that macro other than to destroy it.  All we have to
> do is destroy it a bit sooner.
> 
> This involves unlocking and relocking the ctx since EGC_FREE expects
> to be called with the lock released but libxl__ao_inprogress needs it
> locked.  The is hole in our lock tenure is fine - libxl__ao_inprogress
> has such holes already.
> 
> It is still possible to use the CTX_LOCK macros for this unlock/lock
> because the gc we are using is destroyed only afterwards by
> libxl__ao_inprogress.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> diff -r 8aadb3204cfa tools/libxl/libxl_internal.h
> --- a/tools/libxl/libxl_internal.h	Thu Sep 06 21:41:27 2012 +0200
> +++ b/tools/libxl/libxl_internal.h	Fri Oct 12 17:20:10 2012 +0100
> @@ -1709,10 +1709,12 @@ _hidden void libxl__egc_cleanup(libxl__e
>  
>  #define AO_INPROGRESS ({                                        \
>          libxl_ctx *ao__ctx = libxl__gc_owner(&ao->gc);          \
> +        CTX_UNLOCK;                                             \
> +        EGC_FREE;                                               \
> +        CTX_LOCK;                                               \
>          int ao__rc = libxl__ao_inprogress(ao,                   \
>                                 __FILE__, __LINE__, __func__);   \
>          libxl__ctx_unlock(ao__ctx); /* gc is now invalid */     \
> -        EGC_FREE;                                               \
>          (ao__rc);                                               \
>     })
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 09:24:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 09:24:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNgu4-000635-M7; Mon, 15 Oct 2012 09:24:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TNgu2-00062y-VH
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 09:24:03 +0000
Received: from [85.158.143.35:53832] by server-1.bemta-4.messagelabs.com id
	91/D6-19551-236DB705; Mon, 15 Oct 2012 09:24:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1350293039!11487363!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11033 invoked from network); 15 Oct 2012 09:24:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-21.messagelabs.com with SMTP;
	15 Oct 2012 09:24:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 15 Oct 2012 10:23:59 +0100
Message-Id: <507BF24D02000078000A1497@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 15 Oct 2012 10:23:57 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <patchbomb.1349720160@andrewcoop.uk.xensource.com>
	<0a1a3f35f56a1a2b3b8f.1349720163@andrewcoop.uk.xensource.com>
In-Reply-To: <0a1a3f35f56a1a2b3b8f.1349720163@andrewcoop.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3 of 3] xen/debug: Introduce ASSERT_RUN()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 08.10.12 at 20:16, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> This is a variant of ASSERT() which takes a predicate, a function an
> argument for the function.  It is designed for debugging in situations
> where ASSERT_PRINTK() is perhaps not powerful enough.
> 
> It will run the given function with the given argument before the BUG()
> which kills Xen.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> 
> diff -r 477ccdb9870e -r 0a1a3f35f56a xen/include/xen/lib.h
> --- a/xen/include/xen/lib.h
> +++ b/xen/include/xen/lib.h
> @@ -48,6 +48,16 @@ do {                                    
>  } while (0)
>  #endif /* assert_printk_failed */
>  
> +#ifndef assert_run_failed
> +#define assert_run_failed(p, func, arg)                         \
> +do {                                                            \
> +    printk("Assertion '%s' failed, line %d, file %s\n", p ,     \
> +                   __LINE__, __FILE__);                         \
> +    (func)((arg));                                              \

Quite a few pointless parentheses here.

> +    BUG();                                                      \
> +} while (0)
> +#endif /* assert_run_failed */
> +
>  #ifdef CONFIG_ASSERTS
>  #define ASSERT(p) \
>      do { if ( unlikely(!(p)) ) assert_failed(#p); } while (0)
> @@ -55,9 +65,15 @@ do {                                    
>  #define ASSERT_PRINTK(p, ...)                                   \
>      do { if ( unlikely(!(p)) )                                  \
>              assert_printk_failed(#p, __VA_ARGS__); } while (0)
> +
> +/* func expected to be void, taking a single void * argument */
> +#define ASSERT_RUN(p, func, arg)                                \

Since the user of the construct specifies both func and arg, I don't
see the need to specify what type they are. Nor is it meaningful
here whether the function returns void (it would at most need to
be stated - I'd consider this mostly obvious - that an eventual
return value doesn't get used).

> +    do { if ( unlikely(!(p)) )                                  \
> +            assert_run_failed(#p, func, arg); } while (0)
>  #else
>  #define ASSERT(p) do { if ( 0 && (p) ); } while (0)
>  #define ASSERT_PRINTK(p, ...) do { if ( 0 && (p) ); } while (0)
> +#define ASSERT_RUN(p, func, arg) do { if ( 0 && (p) ); } while (0)

You shall evaluate func and arg (i.e. invoke func(arg)) in the
(dead) if() body, to both avoid the need for #ifdef-s at use
sites and check type compatibility even in non-debug (or non-
assert, following your earlier patch) builds.

Jan

>  #endif
>  
>  #define ABS(_x) ({                              \




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 09:24:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 09:24:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNgu4-000635-M7; Mon, 15 Oct 2012 09:24:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TNgu2-00062y-VH
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 09:24:03 +0000
Received: from [85.158.143.35:53832] by server-1.bemta-4.messagelabs.com id
	91/D6-19551-236DB705; Mon, 15 Oct 2012 09:24:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1350293039!11487363!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11033 invoked from network); 15 Oct 2012 09:24:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-21.messagelabs.com with SMTP;
	15 Oct 2012 09:24:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 15 Oct 2012 10:23:59 +0100
Message-Id: <507BF24D02000078000A1497@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 15 Oct 2012 10:23:57 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <patchbomb.1349720160@andrewcoop.uk.xensource.com>
	<0a1a3f35f56a1a2b3b8f.1349720163@andrewcoop.uk.xensource.com>
In-Reply-To: <0a1a3f35f56a1a2b3b8f.1349720163@andrewcoop.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3 of 3] xen/debug: Introduce ASSERT_RUN()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 08.10.12 at 20:16, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> This is a variant of ASSERT() which takes a predicate, a function an
> argument for the function.  It is designed for debugging in situations
> where ASSERT_PRINTK() is perhaps not powerful enough.
> 
> It will run the given function with the given argument before the BUG()
> which kills Xen.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> 
> diff -r 477ccdb9870e -r 0a1a3f35f56a xen/include/xen/lib.h
> --- a/xen/include/xen/lib.h
> +++ b/xen/include/xen/lib.h
> @@ -48,6 +48,16 @@ do {                                    
>  } while (0)
>  #endif /* assert_printk_failed */
>  
> +#ifndef assert_run_failed
> +#define assert_run_failed(p, func, arg)                         \
> +do {                                                            \
> +    printk("Assertion '%s' failed, line %d, file %s\n", p ,     \
> +                   __LINE__, __FILE__);                         \
> +    (func)((arg));                                              \

Quite a few pointless parentheses here.

> +    BUG();                                                      \
> +} while (0)
> +#endif /* assert_run_failed */
> +
>  #ifdef CONFIG_ASSERTS
>  #define ASSERT(p) \
>      do { if ( unlikely(!(p)) ) assert_failed(#p); } while (0)
> @@ -55,9 +65,15 @@ do {                                    
>  #define ASSERT_PRINTK(p, ...)                                   \
>      do { if ( unlikely(!(p)) )                                  \
>              assert_printk_failed(#p, __VA_ARGS__); } while (0)
> +
> +/* func expected to be void, taking a single void * argument */
> +#define ASSERT_RUN(p, func, arg)                                \

Since the user of the construct specifies both func and arg, I don't
see the need to specify what type they are. Nor is it meaningful
here whether the function returns void (it would at most need to
be stated - I'd consider this mostly obvious - that an eventual
return value doesn't get used).

> +    do { if ( unlikely(!(p)) )                                  \
> +            assert_run_failed(#p, func, arg); } while (0)
>  #else
>  #define ASSERT(p) do { if ( 0 && (p) ); } while (0)
>  #define ASSERT_PRINTK(p, ...) do { if ( 0 && (p) ); } while (0)
> +#define ASSERT_RUN(p, func, arg) do { if ( 0 && (p) ); } while (0)

You shall evaluate func and arg (i.e. invoke func(arg)) in the
(dead) if() body, to both avoid the need for #ifdef-s at use
sites and check type compatibility even in non-debug (or non-
assert, following your earlier patch) builds.

Jan

>  #endif
>  
>  #define ABS(_x) ({                              \




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 09:25:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 09:25:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNgvN-00068U-5I; Mon, 15 Oct 2012 09:25:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TNgvM-00068K-KS
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 09:25:24 +0000
Received: from [85.158.139.211:19233] by server-2.bemta-5.messagelabs.com id
	45/D8-10520-386DB705; Mon, 15 Oct 2012 09:25:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1350293122!22320096!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3262 invoked from network); 15 Oct 2012 09:25:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 09:25:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="15164066"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 09:25:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 10:25:22 +0100
Message-ID: <1350293121.18058.10.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 15 Oct 2012 10:25:21 +0100
In-Reply-To: <1350046634-2462-3-git-send-email-david.vrabel@citrix.com>
References: <1350046634-2462-1-git-send-email-david.vrabel@citrix.com>
	<1350046634-2462-3-git-send-email-david.vrabel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/3] xen: add correct 500 ms offset when
 setting Xen wallclock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-12 at 13:57 +0100, David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> update_persistent_wallclock() (and hence xet_set_wallclock()) is
> called 500 ms after the second.

The comment in sync_cmos_clock says it is called 500ms before the next
second.

I only mention it to double check that the right semantics for
set_wallclock are being implemented, i.e. that we are compensating in
the right direction.

>   xen_set_wallclock() was not
> considering this so the Xen wallclock would end up ~500 ms behind the
> correct time.
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> ---
>  arch/x86/xen/time.c |    9 +++++++--
>  1 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
> index 5e7f536..11770d0 100644
> --- a/arch/x86/xen/time.c
> +++ b/arch/x86/xen/time.c
> @@ -212,10 +212,15 @@ static int xen_set_wallclock(unsigned long now)
>  	/* Set the hardware RTC. */
>  	mach_set_rtc_mmss(now);
>  
> -	/* Set the Xen wallclock. */
> +	/*
> +	 * Set the Xen wallclock.
> +	 *
> +	 * update_persistent_wallclock() is called ~500 ms after 'now'
> +	 * so add an extra 500 ms.
> +	 */
>  	op.cmd = XENPF_settime;
>  	op.u.settime.secs = now;
> -	op.u.settime.nsecs = 0;
> +	op.u.settime.nsecs = NSEC_PER_SEC / 2;
>  	op.u.settime.system_time = xen_clocksource_read();
>  
>  	rc = HYPERVISOR_dom0_op(&op);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 09:25:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 09:25:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNgvN-00068U-5I; Mon, 15 Oct 2012 09:25:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TNgvM-00068K-KS
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 09:25:24 +0000
Received: from [85.158.139.211:19233] by server-2.bemta-5.messagelabs.com id
	45/D8-10520-386DB705; Mon, 15 Oct 2012 09:25:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1350293122!22320096!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3262 invoked from network); 15 Oct 2012 09:25:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 09:25:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="15164066"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 09:25:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 10:25:22 +0100
Message-ID: <1350293121.18058.10.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 15 Oct 2012 10:25:21 +0100
In-Reply-To: <1350046634-2462-3-git-send-email-david.vrabel@citrix.com>
References: <1350046634-2462-1-git-send-email-david.vrabel@citrix.com>
	<1350046634-2462-3-git-send-email-david.vrabel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/3] xen: add correct 500 ms offset when
 setting Xen wallclock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-12 at 13:57 +0100, David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> update_persistent_wallclock() (and hence xet_set_wallclock()) is
> called 500 ms after the second.

The comment in sync_cmos_clock says it is called 500ms before the next
second.

I only mention it to double check that the right semantics for
set_wallclock are being implemented, i.e. that we are compensating in
the right direction.

>   xen_set_wallclock() was not
> considering this so the Xen wallclock would end up ~500 ms behind the
> correct time.
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> ---
>  arch/x86/xen/time.c |    9 +++++++--
>  1 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
> index 5e7f536..11770d0 100644
> --- a/arch/x86/xen/time.c
> +++ b/arch/x86/xen/time.c
> @@ -212,10 +212,15 @@ static int xen_set_wallclock(unsigned long now)
>  	/* Set the hardware RTC. */
>  	mach_set_rtc_mmss(now);
>  
> -	/* Set the Xen wallclock. */
> +	/*
> +	 * Set the Xen wallclock.
> +	 *
> +	 * update_persistent_wallclock() is called ~500 ms after 'now'
> +	 * so add an extra 500 ms.
> +	 */
>  	op.cmd = XENPF_settime;
>  	op.u.settime.secs = now;
> -	op.u.settime.nsecs = 0;
> +	op.u.settime.nsecs = NSEC_PER_SEC / 2;
>  	op.u.settime.system_time = xen_clocksource_read();
>  
>  	rc = HYPERVISOR_dom0_op(&op);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 09:29:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 09:29:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNgyv-0006Hr-PG; Mon, 15 Oct 2012 09:29:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1TNgyu-0006Hk-UV
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 09:29:05 +0000
Received: from [85.158.143.99:34442] by server-2.bemta-4.messagelabs.com id
	17/42-25171-067DB705; Mon, 15 Oct 2012 09:29:04 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1350293341!26603073!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYzMzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30701 invoked from network); 15 Oct 2012 09:29:02 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 09:29:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="41196660"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 09:29:00 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 05:29:00 -0400
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1TNgyq-00027g-8x;
	Mon, 15 Oct 2012 10:29:00 +0100
Message-ID: <507BD75C.7010905@citrix.com>
Date: Mon, 15 Oct 2012 10:29:00 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <patchbomb.1349720160@andrewcoop.uk.xensource.com>
	<477ccdb9870ed68e33c5.1349720162@andrewcoop.uk.xensource.com>
	<507BF0C502000078000A1484@nat28.tlf.novell.com>
In-Reply-To: <507BF0C502000078000A1484@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.5
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 3] xen/debug: Introduce ASSERT_PRINTK()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 15/10/12 10:17, Jan Beulich wrote:
>>>> On 08.10.12 at 20:16, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> This is a variant of ASSERT() which takes a predicate, and a variable
>> number of arguments which get fed to prink() before the BUG().
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>
>> --
>> This does use C99 varadic macros, but given that we use other C99
>> features without #ifdef guards, I felt it not necessary to guard this as
>> well.
>>
>> diff -r 2927e18e9a7c -r 477ccdb9870e xen/include/xen/lib.h
>> --- a/xen/include/xen/lib.h
>> +++ b/xen/include/xen/lib.h
>> @@ -38,11 +38,26 @@ do {                                    
>>  } while (0)
>>  #endif
>>  
>> +#ifndef assert_printk_failed
>> +#define assert_printk_failed(p, ...)                            \
>> +do {                                                            \
>> +    printk("Assertion '%s' failed, line %d, file %s\n", p ,     \
>> +                   __LINE__, __FILE__);                         \
>> +    printk(__VA_ARGS__);                                        \
> The first argument here necessarily is a format string, so it
> should also be enforced that way.

Except for the trailing comma issue present in C99 varadic macros, which
is why it is specified this way.

#define COMMA(fmt, ...) printf(fmt, _VA_ARGS__);

Calling COMMA("foobar") will expand to 'printf("foobar",);' leading to a
syntax error.  There is a GCCism which fixes this issue, but it is not
portable.


>  Which then opens the
> question whether the two printk()-s shouldn't be folded (at the
> price of requiring the format string to be a literal).

I would err away from that option if possible, just for flexibility sake.

>
> I wonder though whether we wouldn't be better off following
> Linux'es WARN() et al infrastructure, rather than extending the
> ASSERT() one.
>
> Jan

Keir implied that this might like to be extended to BUG()s and WARN()s,
which I am happy to do if that is the consensus.

~Andrew

>
>> +    BUG();                                                      \
>> +} while (0)
>> +#endif /* assert_printk_failed */
>> +
>>  #ifdef CONFIG_ASSERTS
>>  #define ASSERT(p) \
>>      do { if ( unlikely(!(p)) ) assert_failed(#p); } while (0)
>> +
>> +#define ASSERT_PRINTK(p, ...)                                   \
>> +    do { if ( unlikely(!(p)) )                                  \
>> +            assert_printk_failed(#p, __VA_ARGS__); } while (0)
>>  #else
>>  #define ASSERT(p) do { if ( 0 && (p) ); } while (0)
>> +#define ASSERT_PRINTK(p, ...) do { if ( 0 && (p) ); } while (0)
>>  #endif
>>  
>>  #define ABS(_x) ({                              \
>
>

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 09:29:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 09:29:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNgyv-0006Hr-PG; Mon, 15 Oct 2012 09:29:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1TNgyu-0006Hk-UV
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 09:29:05 +0000
Received: from [85.158.143.99:34442] by server-2.bemta-4.messagelabs.com id
	17/42-25171-067DB705; Mon, 15 Oct 2012 09:29:04 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1350293341!26603073!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYzMzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30701 invoked from network); 15 Oct 2012 09:29:02 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 09:29:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="41196660"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 09:29:00 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 05:29:00 -0400
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1TNgyq-00027g-8x;
	Mon, 15 Oct 2012 10:29:00 +0100
Message-ID: <507BD75C.7010905@citrix.com>
Date: Mon, 15 Oct 2012 10:29:00 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <patchbomb.1349720160@andrewcoop.uk.xensource.com>
	<477ccdb9870ed68e33c5.1349720162@andrewcoop.uk.xensource.com>
	<507BF0C502000078000A1484@nat28.tlf.novell.com>
In-Reply-To: <507BF0C502000078000A1484@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.5
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 3] xen/debug: Introduce ASSERT_PRINTK()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 15/10/12 10:17, Jan Beulich wrote:
>>>> On 08.10.12 at 20:16, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> This is a variant of ASSERT() which takes a predicate, and a variable
>> number of arguments which get fed to prink() before the BUG().
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>
>> --
>> This does use C99 varadic macros, but given that we use other C99
>> features without #ifdef guards, I felt it not necessary to guard this as
>> well.
>>
>> diff -r 2927e18e9a7c -r 477ccdb9870e xen/include/xen/lib.h
>> --- a/xen/include/xen/lib.h
>> +++ b/xen/include/xen/lib.h
>> @@ -38,11 +38,26 @@ do {                                    
>>  } while (0)
>>  #endif
>>  
>> +#ifndef assert_printk_failed
>> +#define assert_printk_failed(p, ...)                            \
>> +do {                                                            \
>> +    printk("Assertion '%s' failed, line %d, file %s\n", p ,     \
>> +                   __LINE__, __FILE__);                         \
>> +    printk(__VA_ARGS__);                                        \
> The first argument here necessarily is a format string, so it
> should also be enforced that way.

Except for the trailing comma issue present in C99 varadic macros, which
is why it is specified this way.

#define COMMA(fmt, ...) printf(fmt, _VA_ARGS__);

Calling COMMA("foobar") will expand to 'printf("foobar",);' leading to a
syntax error.  There is a GCCism which fixes this issue, but it is not
portable.


>  Which then opens the
> question whether the two printk()-s shouldn't be folded (at the
> price of requiring the format string to be a literal).

I would err away from that option if possible, just for flexibility sake.

>
> I wonder though whether we wouldn't be better off following
> Linux'es WARN() et al infrastructure, rather than extending the
> ASSERT() one.
>
> Jan

Keir implied that this might like to be extended to BUG()s and WARN()s,
which I am happy to do if that is the consensus.

~Andrew

>
>> +    BUG();                                                      \
>> +} while (0)
>> +#endif /* assert_printk_failed */
>> +
>>  #ifdef CONFIG_ASSERTS
>>  #define ASSERT(p) \
>>      do { if ( unlikely(!(p)) ) assert_failed(#p); } while (0)
>> +
>> +#define ASSERT_PRINTK(p, ...)                                   \
>> +    do { if ( unlikely(!(p)) )                                  \
>> +            assert_printk_failed(#p, __VA_ARGS__); } while (0)
>>  #else
>>  #define ASSERT(p) do { if ( 0 && (p) ); } while (0)
>> +#define ASSERT_PRINTK(p, ...) do { if ( 0 && (p) ); } while (0)
>>  #endif
>>  
>>  #define ABS(_x) ({                              \
>
>

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 09:30:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 09:30:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNgzy-0006Nn-Dl; Mon, 15 Oct 2012 09:30:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TNgzw-0006NV-DH
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 09:30:08 +0000
Received: from [85.158.143.35:24177] by server-2.bemta-4.messagelabs.com id
	C8/F3-25171-F97DB705; Mon, 15 Oct 2012 09:30:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1350293261!5295227!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18307 invoked from network); 15 Oct 2012 09:27:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 09:27:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="15164166"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 09:26:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 10:26:59 +0100
Message-ID: <1350293217.18058.11.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 15 Oct 2012 10:26:57 +0100
In-Reply-To: <50784462.3060203@citrix.com>
References: <1350046634-2462-1-git-send-email-david.vrabel@citrix.com>
	<50784462.3060203@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 0/3] xen: fix various wallclock problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-12 at 17:25 +0100, David Vrabel wrote:
> On 12/10/12 13:57, David Vrabel wrote:
> > This series (with some toolstack updates) corrects a number of cases
> > where a guest can see an incorrect wallclock time.
> > 
> > 1. Systems with NTP won't periodically synchronize the hardware RTC so
> > the wallclock may be incorrect after a reboot.
> > 
> > 2. The wallclock is always ~500 ms behind the correct time.
> > 
> > 3. If the system time was stepped and NTP isn't synchronized yet, the
> > wallclock will still have the incorrect time.  The fix for this
> > requires the toolstack to synchronize the wallclock -- patch #3
> > provides the mechanism for this.
> 
> These tables should help.
> 
> Before:
> 
>               |                Updates
> Process	      | System Time?  Xen Wallclock?  Hardware Clock?
> -------------------------------------------------------------
> date -s       | X
> hwclock -w    |                               X
> ntpd          | X             X[*]
> ntpdate       | X

What does the equivalent table for native look like?

Is the "updated hardware clock" column in that caseis union of xen
wallclock and hardware clock columns here?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 09:30:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 09:30:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNgzy-0006Nn-Dl; Mon, 15 Oct 2012 09:30:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TNgzw-0006NV-DH
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 09:30:08 +0000
Received: from [85.158.143.35:24177] by server-2.bemta-4.messagelabs.com id
	C8/F3-25171-F97DB705; Mon, 15 Oct 2012 09:30:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1350293261!5295227!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18307 invoked from network); 15 Oct 2012 09:27:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 09:27:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="15164166"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 09:26:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 10:26:59 +0100
Message-ID: <1350293217.18058.11.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 15 Oct 2012 10:26:57 +0100
In-Reply-To: <50784462.3060203@citrix.com>
References: <1350046634-2462-1-git-send-email-david.vrabel@citrix.com>
	<50784462.3060203@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 0/3] xen: fix various wallclock problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-12 at 17:25 +0100, David Vrabel wrote:
> On 12/10/12 13:57, David Vrabel wrote:
> > This series (with some toolstack updates) corrects a number of cases
> > where a guest can see an incorrect wallclock time.
> > 
> > 1. Systems with NTP won't periodically synchronize the hardware RTC so
> > the wallclock may be incorrect after a reboot.
> > 
> > 2. The wallclock is always ~500 ms behind the correct time.
> > 
> > 3. If the system time was stepped and NTP isn't synchronized yet, the
> > wallclock will still have the incorrect time.  The fix for this
> > requires the toolstack to synchronize the wallclock -- patch #3
> > provides the mechanism for this.
> 
> These tables should help.
> 
> Before:
> 
>               |                Updates
> Process	      | System Time?  Xen Wallclock?  Hardware Clock?
> -------------------------------------------------------------
> date -s       | X
> hwclock -w    |                               X
> ntpd          | X             X[*]
> ntpdate       | X

What does the equivalent table for native look like?

Is the "updated hardware clock" column in that caseis union of xen
wallclock and hardware clock columns here?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 09:32:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 09:32:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNh2O-0006YM-WA; Mon, 15 Oct 2012 09:32:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TNh2N-0006YF-S4
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 09:32:39 +0000
Received: from [85.158.143.99:53284] by server-2.bemta-4.messagelabs.com id
	9B/A8-25171-738DB705; Mon, 15 Oct 2012 09:32:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1350293558!26007499!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8665 invoked from network); 15 Oct 2012 09:32:38 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-216.messagelabs.com with SMTP;
	15 Oct 2012 09:32:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 15 Oct 2012 10:32:36 +0100
Message-Id: <507BF45002000078000A14BD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 15 Oct 2012 10:32:31 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <patchbomb.1349720160@andrewcoop.uk.xensource.com>
	<477ccdb9870ed68e33c5.1349720162@andrewcoop.uk.xensource.com>
	<507BF0C502000078000A1484@nat28.tlf.novell.com>
	<507BD75C.7010905@citrix.com>
In-Reply-To: <507BD75C.7010905@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 3] xen/debug: Introduce ASSERT_PRINTK()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.10.12 at 11:29, Andrew Cooper <andrew.cooper3@citrix.com> wrote:

> On 15/10/12 10:17, Jan Beulich wrote:
>>>>> On 08.10.12 at 20:16, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>> This is a variant of ASSERT() which takes a predicate, and a variable
>>> number of arguments which get fed to prink() before the BUG().
>>>
>>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>>
>>> --
>>> This does use C99 varadic macros, but given that we use other C99
>>> features without #ifdef guards, I felt it not necessary to guard this as
>>> well.
>>>
>>> diff -r 2927e18e9a7c -r 477ccdb9870e xen/include/xen/lib.h
>>> --- a/xen/include/xen/lib.h
>>> +++ b/xen/include/xen/lib.h
>>> @@ -38,11 +38,26 @@ do {                                    
>>>  } while (0)
>>>  #endif
>>>  
>>> +#ifndef assert_printk_failed
>>> +#define assert_printk_failed(p, ...)                            \
>>> +do {                                                            \
>>> +    printk("Assertion '%s' failed, line %d, file %s\n", p ,     \
>>> +                   __LINE__, __FILE__);                         \
>>> +    printk(__VA_ARGS__);                                        \
>> The first argument here necessarily is a format string, so it
>> should also be enforced that way.
> 
> Except for the trailing comma issue present in C99 varadic macros, which
> is why it is specified this way.
> 
> #define COMMA(fmt, ...) printf(fmt, _VA_ARGS__);
> 
> Calling COMMA("foobar") will expand to 'printf("foobar",);' leading to a
> syntax error.  There is a GCCism which fixes this issue, but it is not
> portable.

But this is not a public header, so gcc-isms are no problem.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 09:32:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 09:32:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNh2O-0006YM-WA; Mon, 15 Oct 2012 09:32:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TNh2N-0006YF-S4
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 09:32:39 +0000
Received: from [85.158.143.99:53284] by server-2.bemta-4.messagelabs.com id
	9B/A8-25171-738DB705; Mon, 15 Oct 2012 09:32:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1350293558!26007499!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8665 invoked from network); 15 Oct 2012 09:32:38 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-216.messagelabs.com with SMTP;
	15 Oct 2012 09:32:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 15 Oct 2012 10:32:36 +0100
Message-Id: <507BF45002000078000A14BD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 15 Oct 2012 10:32:31 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <patchbomb.1349720160@andrewcoop.uk.xensource.com>
	<477ccdb9870ed68e33c5.1349720162@andrewcoop.uk.xensource.com>
	<507BF0C502000078000A1484@nat28.tlf.novell.com>
	<507BD75C.7010905@citrix.com>
In-Reply-To: <507BD75C.7010905@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 3] xen/debug: Introduce ASSERT_PRINTK()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.10.12 at 11:29, Andrew Cooper <andrew.cooper3@citrix.com> wrote:

> On 15/10/12 10:17, Jan Beulich wrote:
>>>>> On 08.10.12 at 20:16, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>> This is a variant of ASSERT() which takes a predicate, and a variable
>>> number of arguments which get fed to prink() before the BUG().
>>>
>>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>>
>>> --
>>> This does use C99 varadic macros, but given that we use other C99
>>> features without #ifdef guards, I felt it not necessary to guard this as
>>> well.
>>>
>>> diff -r 2927e18e9a7c -r 477ccdb9870e xen/include/xen/lib.h
>>> --- a/xen/include/xen/lib.h
>>> +++ b/xen/include/xen/lib.h
>>> @@ -38,11 +38,26 @@ do {                                    
>>>  } while (0)
>>>  #endif
>>>  
>>> +#ifndef assert_printk_failed
>>> +#define assert_printk_failed(p, ...)                            \
>>> +do {                                                            \
>>> +    printk("Assertion '%s' failed, line %d, file %s\n", p ,     \
>>> +                   __LINE__, __FILE__);                         \
>>> +    printk(__VA_ARGS__);                                        \
>> The first argument here necessarily is a format string, so it
>> should also be enforced that way.
> 
> Except for the trailing comma issue present in C99 varadic macros, which
> is why it is specified this way.
> 
> #define COMMA(fmt, ...) printf(fmt, _VA_ARGS__);
> 
> Calling COMMA("foobar") will expand to 'printf("foobar",);' leading to a
> syntax error.  There is a GCCism which fixes this issue, but it is not
> portable.

But this is not a public header, so gcc-isms are no problem.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 09:35:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 09:35:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNh57-0006lk-8w; Mon, 15 Oct 2012 09:35:29 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TNh55-0006kS-H9
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 09:35:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1350293721!13263094!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26177 invoked from network); 15 Oct 2012 09:35:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 09:35:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="15164492"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 09:35:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 10:35:21 +0100
Message-ID: <1350293719.18058.13.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 15 Oct 2012 10:35:19 +0100
In-Reply-To: <1350046970-2591-3-git-send-email-david.vrabel@citrix.com>
References: <1350046970-2591-1-git-send-email-david.vrabel@citrix.com>
	<1350046970-2591-3-git-send-email-david.vrabel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/2] tools/misc: add xen-wallclock command
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-12 at 14:02 +0100, David Vrabel wrote:
> +int main(int argc, char *argv[])
> +{
> +    const static char sopts[] = "w";
> +    const static struct option lopts[] = {
> +        { "help", 0, NULL, 0 },
> +        { "systowc", 0, NULL, 'w' },
> +        { 0, 0, NULL, 0 },
> +    };
> +    int opt, opt_idx;
> +
> +    int systowc = 0;
> +    xc_interface *xch;
> +
> +    exe_name = argv[0];
> +
> +    while ( (opt = getopt_long(argc, argv, sopts, lopts, &opt_idx)) != -1 )
> +    {
> +        switch ( opt )
> +        {
> +        case 'w':
> +            systowc = 1;
> +            break;
> +        case 0:
> +            switch (opt_idx)
> +            {
> +            case 0:
> +                help();
> +            }
> +            break;
> +        default:
> +            usage(stderr);
> +            exit(1);
> +        }
> +    }
> +
> +    /* Valid combination of options? i.e., --systowc */
> +    if (!systowc)
> +    {
> +        usage(stderr);
> +        exit(1);
> +    }
> +
> +    xch = xc_interface_open(NULL, NULL, 0);
> +    if (xch == NULL)
> +    {

I forget: Does xc_interface_open log on error?

> +        exit(1);
> +    }
> +    xc_wallclock_sync(xch);

Worth logging if this fails?

I suppose we want to hold off on this and the first patch until the
Linux side is agreed and committed?

> +    xc_interface_close(xch);
> +
> +    return 0;
> +}



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 09:35:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 09:35:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNh57-0006lk-8w; Mon, 15 Oct 2012 09:35:29 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TNh55-0006kS-H9
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 09:35:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1350293721!13263094!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26177 invoked from network); 15 Oct 2012 09:35:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 09:35:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="15164492"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 09:35:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 10:35:21 +0100
Message-ID: <1350293719.18058.13.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 15 Oct 2012 10:35:19 +0100
In-Reply-To: <1350046970-2591-3-git-send-email-david.vrabel@citrix.com>
References: <1350046970-2591-1-git-send-email-david.vrabel@citrix.com>
	<1350046970-2591-3-git-send-email-david.vrabel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/2] tools/misc: add xen-wallclock command
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-12 at 14:02 +0100, David Vrabel wrote:
> +int main(int argc, char *argv[])
> +{
> +    const static char sopts[] = "w";
> +    const static struct option lopts[] = {
> +        { "help", 0, NULL, 0 },
> +        { "systowc", 0, NULL, 'w' },
> +        { 0, 0, NULL, 0 },
> +    };
> +    int opt, opt_idx;
> +
> +    int systowc = 0;
> +    xc_interface *xch;
> +
> +    exe_name = argv[0];
> +
> +    while ( (opt = getopt_long(argc, argv, sopts, lopts, &opt_idx)) != -1 )
> +    {
> +        switch ( opt )
> +        {
> +        case 'w':
> +            systowc = 1;
> +            break;
> +        case 0:
> +            switch (opt_idx)
> +            {
> +            case 0:
> +                help();
> +            }
> +            break;
> +        default:
> +            usage(stderr);
> +            exit(1);
> +        }
> +    }
> +
> +    /* Valid combination of options? i.e., --systowc */
> +    if (!systowc)
> +    {
> +        usage(stderr);
> +        exit(1);
> +    }
> +
> +    xch = xc_interface_open(NULL, NULL, 0);
> +    if (xch == NULL)
> +    {

I forget: Does xc_interface_open log on error?

> +        exit(1);
> +    }
> +    xc_wallclock_sync(xch);

Worth logging if this fails?

I suppose we want to hold off on this and the first patch until the
Linux side is agreed and committed?

> +    xc_interface_close(xch);
> +
> +    return 0;
> +}



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 09:37:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 09:37:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNh7G-00071d-QR; Mon, 15 Oct 2012 09:37:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1TNh7F-00071P-9N
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 09:37:41 +0000
Received: from [85.158.143.99:18638] by server-3.bemta-4.messagelabs.com id
	75/DD-10075-469DB705; Mon, 15 Oct 2012 09:37:40 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1350293852!28013737!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYzMzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16313 invoked from network); 15 Oct 2012 09:37:34 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 09:37:34 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="41197425"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 09:37:32 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 05:37:31 -0400
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1TNh75-0002FI-NL;
	Mon, 15 Oct 2012 10:37:31 +0100
Message-ID: <507BD95B.7070003@citrix.com>
Date: Mon, 15 Oct 2012 10:37:31 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <patchbomb.1349720160@andrewcoop.uk.xensource.com>
	<0a1a3f35f56a1a2b3b8f.1349720163@andrewcoop.uk.xensource.com>
	<507BF24D02000078000A1497@nat28.tlf.novell.com>
In-Reply-To: <507BF24D02000078000A1497@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.5
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 3 of 3] xen/debug: Introduce ASSERT_RUN()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 15/10/12 10:23, Jan Beulich wrote:
>>>> On 08.10.12 at 20:16, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> This is a variant of ASSERT() which takes a predicate, a function an
>> argument for the function.  It is designed for debugging in situations
>> where ASSERT_PRINTK() is perhaps not powerful enough.
>>
>> It will run the given function with the given argument before the BUG()
>> which kills Xen.
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>
>> diff -r 477ccdb9870e -r 0a1a3f35f56a xen/include/xen/lib.h
>> --- a/xen/include/xen/lib.h
>> +++ b/xen/include/xen/lib.h
>> @@ -48,6 +48,16 @@ do {                                    
>>  } while (0)
>>  #endif /* assert_printk_failed */
>>  
>> +#ifndef assert_run_failed
>> +#define assert_run_failed(p, func, arg)                         \
>> +do {                                                            \
>> +    printk("Assertion '%s' failed, line %d, file %s\n", p ,     \
>> +                   __LINE__, __FILE__);                         \
>> +    (func)((arg));                                              \
> Quite a few pointless parentheses here.

Ok

>
>> +    BUG();                                                      \
>> +} while (0)
>> +#endif /* assert_run_failed */
>> +
>>  #ifdef CONFIG_ASSERTS
>>  #define ASSERT(p) \
>>      do { if ( unlikely(!(p)) ) assert_failed(#p); } while (0)
>> @@ -55,9 +65,15 @@ do {                                    
>>  #define ASSERT_PRINTK(p, ...)                                   \
>>      do { if ( unlikely(!(p)) )                                  \
>>              assert_printk_failed(#p, __VA_ARGS__); } while (0)
>> +
>> +/* func expected to be void, taking a single void * argument */
>> +#define ASSERT_RUN(p, func, arg)                                \
> Since the user of the construct specifies both func and arg, I don't
> see the need to specify what type they are. Nor is it meaningful
> here whether the function returns void (it would at most need to
> be stated - I'd consider this mostly obvious - that an eventual
> return value doesn't get used).

Good point

>
>> +    do { if ( unlikely(!(p)) )                                  \
>> +            assert_run_failed(#p, func, arg); } while (0)
>>  #else
>>  #define ASSERT(p) do { if ( 0 && (p) ); } while (0)
>>  #define ASSERT_PRINTK(p, ...) do { if ( 0 && (p) ); } while (0)
>> +#define ASSERT_RUN(p, func, arg) do { if ( 0 && (p) ); } while (0)
> You shall evaluate func and arg (i.e. invoke func(arg)) in the
> (dead) if() body, to both avoid the need for #ifdef-s at use
> sites and check type compatibility even in non-debug (or non-
> assert, following your earlier patch) builds.
>
> Jan

I presume that you mean I should?  Why would that prevent the need for
#ifdefs? I can see the argument for type compatibility.

~Andrew

>
>>  #endif
>>  
>>  #define ABS(_x) ({                              \
>
>

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 09:37:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 09:37:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNh7G-00071d-QR; Mon, 15 Oct 2012 09:37:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1TNh7F-00071P-9N
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 09:37:41 +0000
Received: from [85.158.143.99:18638] by server-3.bemta-4.messagelabs.com id
	75/DD-10075-469DB705; Mon, 15 Oct 2012 09:37:40 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1350293852!28013737!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYzMzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16313 invoked from network); 15 Oct 2012 09:37:34 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 09:37:34 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="41197425"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 09:37:32 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 05:37:31 -0400
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1TNh75-0002FI-NL;
	Mon, 15 Oct 2012 10:37:31 +0100
Message-ID: <507BD95B.7070003@citrix.com>
Date: Mon, 15 Oct 2012 10:37:31 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <patchbomb.1349720160@andrewcoop.uk.xensource.com>
	<0a1a3f35f56a1a2b3b8f.1349720163@andrewcoop.uk.xensource.com>
	<507BF24D02000078000A1497@nat28.tlf.novell.com>
In-Reply-To: <507BF24D02000078000A1497@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.5
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 3 of 3] xen/debug: Introduce ASSERT_RUN()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 15/10/12 10:23, Jan Beulich wrote:
>>>> On 08.10.12 at 20:16, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> This is a variant of ASSERT() which takes a predicate, a function an
>> argument for the function.  It is designed for debugging in situations
>> where ASSERT_PRINTK() is perhaps not powerful enough.
>>
>> It will run the given function with the given argument before the BUG()
>> which kills Xen.
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>
>> diff -r 477ccdb9870e -r 0a1a3f35f56a xen/include/xen/lib.h
>> --- a/xen/include/xen/lib.h
>> +++ b/xen/include/xen/lib.h
>> @@ -48,6 +48,16 @@ do {                                    
>>  } while (0)
>>  #endif /* assert_printk_failed */
>>  
>> +#ifndef assert_run_failed
>> +#define assert_run_failed(p, func, arg)                         \
>> +do {                                                            \
>> +    printk("Assertion '%s' failed, line %d, file %s\n", p ,     \
>> +                   __LINE__, __FILE__);                         \
>> +    (func)((arg));                                              \
> Quite a few pointless parentheses here.

Ok

>
>> +    BUG();                                                      \
>> +} while (0)
>> +#endif /* assert_run_failed */
>> +
>>  #ifdef CONFIG_ASSERTS
>>  #define ASSERT(p) \
>>      do { if ( unlikely(!(p)) ) assert_failed(#p); } while (0)
>> @@ -55,9 +65,15 @@ do {                                    
>>  #define ASSERT_PRINTK(p, ...)                                   \
>>      do { if ( unlikely(!(p)) )                                  \
>>              assert_printk_failed(#p, __VA_ARGS__); } while (0)
>> +
>> +/* func expected to be void, taking a single void * argument */
>> +#define ASSERT_RUN(p, func, arg)                                \
> Since the user of the construct specifies both func and arg, I don't
> see the need to specify what type they are. Nor is it meaningful
> here whether the function returns void (it would at most need to
> be stated - I'd consider this mostly obvious - that an eventual
> return value doesn't get used).

Good point

>
>> +    do { if ( unlikely(!(p)) )                                  \
>> +            assert_run_failed(#p, func, arg); } while (0)
>>  #else
>>  #define ASSERT(p) do { if ( 0 && (p) ); } while (0)
>>  #define ASSERT_PRINTK(p, ...) do { if ( 0 && (p) ); } while (0)
>> +#define ASSERT_RUN(p, func, arg) do { if ( 0 && (p) ); } while (0)
> You shall evaluate func and arg (i.e. invoke func(arg)) in the
> (dead) if() body, to both avoid the need for #ifdef-s at use
> sites and check type compatibility even in non-debug (or non-
> assert, following your earlier patch) builds.
>
> Jan

I presume that you mean I should?  Why would that prevent the need for
#ifdefs? I can see the argument for type compatibility.

~Andrew

>
>>  #endif
>>  
>>  #define ABS(_x) ({                              \
>
>

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 09:40:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 09:40:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNh9r-0007LN-JI; Mon, 15 Oct 2012 09:40:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mrsanna1@gmail.com>)
	id 1TNh8y-0007Cy-1m; Mon, 15 Oct 2012 09:39:28 +0000
Received: from [85.158.143.35:33562] by server-2.bemta-4.messagelabs.com id
	B0/E3-25171-FC9DB705; Mon, 15 Oct 2012 09:39:27 +0000
X-Env-Sender: mrsanna1@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1350293963!14372120!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24605 invoked from network); 15 Oct 2012 09:39:25 -0000
Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com)
	(209.85.212.43)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 09:39:25 -0000
Received: by mail-vb0-f43.google.com with SMTP id fq11so6252994vbb.30
	for <multiple recipients>; Mon, 15 Oct 2012 02:39:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=vINeOYpc47SNrMBm0U7ufEVf2lkR4HYAzDuQx1w9Ji4=;
	b=RYYRXwgI5BI/3jAOIcpzVRfKAM3NkBhIeT2Hw/MqBE26tt3EZ2NGP2Km1N52J3mk0b
	7f8w9DTrwfqVmtGEK6S9uhbWWNnp/Ti/NFdfbwGvm85dLZjTw2Qv1UH7ndikZlmf/iig
	ExXojYMkgdKNCZvViZW4xkWre6EE0v9ALnarFwJ7N7E5tp17glJNJiKI1+GsM0wCSF6h
	hyueNXrPWGqu6ov1BPskFkj+oqn8sRkXPqu8rE7LD7Q5KrrjiQ4nIrXaiNMnhfxqE7n8
	2GyhO3dleHZhMj0ijES3O82iqZNgWCNPaFB0ycobo63d8dSpT4C8BbnGOwmJ0SpgOtCB
	Hf+w==
MIME-Version: 1.0
Received: by 10.220.231.138 with SMTP id jq10mr6384946vcb.29.1350293963223;
	Mon, 15 Oct 2012 02:39:23 -0700 (PDT)
Received: by 10.58.207.75 with HTTP; Mon, 15 Oct 2012 02:39:23 -0700 (PDT)
In-Reply-To: <FF93AF260AC2BB499A119CC65B092CF73148901B@sg000713.corproot.net>
References: <AANLkTikptc2POrKQgJuoVZRdwJTo64DJ_hm12KuPky4D@mail.gmail.com>
	<b1ca6ddc-ca69-447e-93e9-8d36d1ff4a43@default>
	<AANLkTinK94GDOF_GeaVs50wK0u8EdZ2rtzPuh65ca8qR@mail.gmail.com>
	<CAE17a0UPyzsNn=ps9MxarkGg=ns8dCpVz0qBDvesT2AOskwfVg@mail.gmail.com>
	<65395f62-74e5-4910-b701-8df629c2ce3b@default>
	<CABx4GKrQxOOQo_uUXSFvy0nzdMp1A_qc=_e4K+88GkB7xv=9nw@mail.gmail.com>
	<CAE17a0VkMuUEG9VaM7AFrwcsEjVBq9RfvTWz1_KmscAyCxeAbA@mail.gmail.com>
	<CABx4GKqrTEV7CEnAVUfYr-+yky8N5P1U29xDbrESH-mHB0iZhQ@mail.gmail.com>
	<CAE17a0UYwqLxoZaVDgQCvUR2KQK4vvP3bkvsdrwgnsUp33xuNQ@mail.gmail.com>
	<CAE17a0UQocJjZc38c2805uYvdwR7e447UGH9ywcxMw1Ge3imfg@mail.gmail.com>
	<20120930151314.GU8912@reaktio.net>
	<CAE17a0WWvpwW-V5hQOgL1CiuVZFKyzhZVZfTVq74ZsJUo1SE8w@mail.gmail.com>
	<CAE17a0WvLyduj4V68qPJRLcjc5V7xZ=iTNprKWJyGAX_6RXC+Q@mail.gmail.com>
	<CABx4GKr-AxZmCyGmd4qenMtgdo2Yg+UnT4ymbONjBtuS+w=g7Q@mail.gmail.com>
	<FF93AF260AC2BB499A119CC65B092CF73148901B@sg000713.corproot.net>
Date: Mon, 15 Oct 2012 11:39:23 +0200
Message-ID: <CAE17a0UZDEaXOVLYoeUwELYE+F1wkFpGKG8q2VTRFBvCyC8D3Q@mail.gmail.com>
From: Mauro <mrsanna1@gmail.com>
To: Philippe.Simonet@swisscom.com
X-Mailman-Approved-At: Mon, 15 Oct 2012 09:40:21 +0000
Cc: dan.magenheimer@oracle.com, xen-devel@lists.xensource.com, keir@xen.org,
	jeremy@goop.org, olivier.hanesse@gmail.com, keir.xen@gmail.com,
	xen-users@lists.xensource.com, mark@campbell-lange.net
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

cmVhbGx5IHJlYWxseSBiYWQgbmV3cywgSSBob3BlIHRoaXMgYW5ub3lpbmcgcHJvYmxlbSB3aWxs
IGJlIHJlc29sdmVkIHZlcnkgc29vbi4KCgpPbiAxNSBPY3RvYmVyIDIwMTIgMTA6MDUsICA8UGhp
bGlwcGUuU2ltb25ldEBzd2lzc2NvbS5jb20+IHdyb3RlOgo+IEhpIE9saXZlcgo+Cj4KPgo+IGJh
ZCBuZXdzLCB0aGlzIG1lYW5zIHRoYXQgeGVuIDQuMXh4eCBkb2VzbuKAmXQgc29sdmUgdGhpcyBp
c3N1ZSDigKYKPgo+Cj4KPiBvbiBteSBzaWRlLCBvbiBteSAgaGFyZHdhcmUgdGhhdCBwcm9kdWNl
IHRoaXMgYnVnICxJIG5ldmVyIGhhZCB0aGUgcHJvYmxlbQo+IHdoaXQgdGhpcyBjb21iaW5hdGlv
biA6ICgxMDAlIFdIRUVaWSkKPgo+IGlpICB4ZW4taHlwZXJ2aXNvci00LjEtYW1kNjQgICAgICAg
ICAgICAgICAgICA0LjEuMy0yCj4gYW1kNjQgICAgICAgIFhlbiBIeXBlcnZpc29yIG9uIEFNRDY0
Cj4KPiBpaSAgbGludXgtaW1hZ2UtMy4yLjAtMy1hbWQ2NCAgICAgICAgICAgICAgICAgMy4yLjIz
LTEKPiBhbWQ2NCAgICAgICAgTGludXggMy4yIGZvciA2NC1iaXQgUENzCj4KPgo+Cj4gICAgICAg
ICAgICAgICAgICh0aGlzIHdhcyBiZWNhdXNlIEkgaGFkIGEgZ3JlYXQgaG9wZSB0aGF0IDQuMS54
eHggc29sdmVkIHRoZQo+IHByb2JsZW0g4oCmKQo+Cj4KPgo+IFBoaWxpcHBlCj4KPgo+Cj4KPgo+
Cj4KPiBGcm9tOiB4ZW4tZGV2ZWwtYm91bmNlc0BsaXN0cy54ZW4ub3JnCj4gW21haWx0bzp4ZW4t
ZGV2ZWwtYm91bmNlc0BsaXN0cy54ZW4ub3JnXSBPbiBCZWhhbGYgT2YgT2xpdmllciBIYW5lc3Nl
Cj4gU2VudDogTW9uZGF5LCBPY3RvYmVyIDE1LCAyMDEyIDk6NDAgQU0KPiBUbzogTWF1cm8KPiBD
YzogRGFuIE1hZ2VuaGVpbWVyOyB4ZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbTsgS2VpciBG
cmFzZXI7IEplcmVteQo+IEZpdHpoYXJkaW5nZTsgS2VpciBGcmFzZXI7IFhlbiBVc2VyczsgTWFy
ayBBZGFtcwo+IFN1YmplY3Q6IFJlOiBbWGVuLWRldmVsXSBbWGVuLXVzZXJzXSBSZTogWGVuIDQg
VFNDIHByb2JsZW1zCj4KPgo+Cj4gSGVsbG8sCj4KPgo+Cj4gU3RyYW5nZSB0aGluZ3Mgb24gdGhp
cyByYWlueSBtb3JuaW5nLCBJIGdvdCB0aGlzIGJ1ZyBhZ2FpbiBvbiBhbm90aGVyCj4gaGFyZHdh
cmUsIGFuZCBYZW4gaHlwZXJ2aXNvciBmcm9tIFdoZWV6eSBhbmQga2VybmVsIGZyb20gU3F1ZWV6
ZS4KPgo+Cj4KPiBpaSAgbGludXgtaW1hZ2UtMi42LjMyLTUteGVuLWFtZDY0ICAgICAgMi42LjMy
LTQ2ICAgICAgICAgICAgICAgICAgTGludXgKPiAyLjYuMzIgZm9yIDY0LWJpdCBQQ3MsIFhlbiBk
b20wIHN1cHBvcnQKPgo+IGlpICB4ZW4taHlwZXJ2aXNvci00LjEtYW1kNjQgICAgICAgICAgICAg
ICA0LjEuMy0yICAgICAgICAgICAgICAgICAgICAgIFhlbgo+IEh5cGVydmlzb3Igb24gQU1ENjQK
Pgo+Cj4KPiBJJ3ZlIHVwZ3JhZGVkIHRoaXMgc2VydmVyIGxhc3Qgd2Vlay4gSSBkb24ndCBrbm93
IGlmIGl0IGlzIGxpbmtlZCBvciBub3QsCj4gYnV0IEkgZGlkbid0IGdldCBhbnkgJ3RpbWUgd3Jh
cCcgb24gdGhpcyBzZXJ2ZXIgZm9yIG1vcmUgdGhhbiAyNTBkYXlzLgo+Cj4gTWF5YmUgaXQgaXMg
cmVsYXRlZCB0byB0aGUgdXBncmFkZSBwcm9jZXNzLiBCZWZvcmUgdGhlIHVwZ3JhZGUsIG15IHZl
cnNpb24KPiB3ZXJlIDoKPgo+Cj4KPiBpaSAgbGludXgtaW1hZ2UtMi42LjMyLTUteGVuLWFtZDY0
ICAgMi42LjMyLTQxc3F1ZWV6ZTIgICAgICAgICAgICBMaW51eAo+IDIuNi4zMiBmb3IgNjQtYml0
IFBDcywgWGVuIGRvbTAgc3VwcG9ydAo+Cj4gaWkgIHhlbi1oeXBlcnZpc29yLTQuMS1hbWQ2NCAg
ICAgICAgICAgIDQuMS4yLTIgICAgICAgICAgICAgICAgICAgICAgWGVuCj4gSHlwZXJ2aXNvciBv
biBBTUQ2NAo+Cj4KPgo+IEkgb25seSB1cGdyYWRlZCBoYWxmIG9mIG15IHNlcnZlcnMsIHNvIEkg
d2lsbCB3YWl0IGEgbGl0dGxlIGJpdCB0byB1cGdyYWRlCj4gdGhlIG90aGVyIGhhbGYgYW5kIHNl
ZSBpZiB0aGlzIGlzc3VlIG9jY3VycyBhZ2FpbiBvbmx5IG9uIHVwZGF0ZWQgc2VydmVycy4KPgo+
Cj4KPiBGb3IgdGhlIHJlY29yZCwgYWx3YXlzIHRoZSBzYW1lIGVycm9ycyA6Cj4KPgo+Cj4geG0g
ZG1lc2cgPT4gKFhFTikgUGxhdGZvcm0gdGltZXIgYXBwZWFycyB0byBoYXZlIHVuZXhwZWN0ZWRs
eSB3cmFwcGVkIDEwIG9yCj4gbW9yZSB0aW1lcy4KPgo+Cj4KPiAvdmFyL2xvZy8qICAgPT4gT2N0
IDE0IDIyOjQ2OjA3IGV1bDI0MDA0Njgga2VybmVsOiBbNzM0NjE4LjU2MjIxOV0KPiBDbG9ja3Nv
dXJjZSB0c2MgdW5zdGFibGUgKGRlbHRhID0gLTI5OTk2NjAzMTMzNzAgbnMpCj4KPgo+Cj4gSSB0
aG91Z2h0IGl0IHdhcyB0aGlzIGlzc3VlIHdhcyBoYXJkd2FyZSByZWxhdGVkLCBtYXliZSBub3Qu
Cj4KPgo+Cj4gT2xpdmllcgo+Cj4KPgo+IDIwMTIvOS8zMCBNYXVybyA8bXJzYW5uYTFAZ21haWwu
Y29tPgo+Cj4gT24gMzAgU2VwdGVtYmVyIDIwMTIgMjE6MjMsIE1hdXJvIDxtcnNhbm5hMUBnbWFp
bC5jb20+IHdyb3RlOgo+PiBPbiAzMCBTZXB0ZW1iZXIgMjAxMiAxNzoxMywgUGFzaSBLw6Rya2vD
pGluZW4gPHBhc2lrQGlraS5maT4gd3JvdGU6Cj4+PiBPbiBTYXQsIFNlcCAyOSwgMjAxMiBhdCAw
MjoxOTo1NVBNICswMjAwLCBNYXVybyB3cm90ZToKPj4+PiBJdCdzIGhhcHBlbmVkIGFub3RoZXIg
dGltZSwgc3lzdGVtIGRhdGUgNTAgbWludXRlcyBhaGVhZC4KPj4+PiBUaGVyZSBpcyByZWFsbHkg
bm8gc29sdXRpb24/Cj4+Pj4KPj4+Cj4+PiBUcnkgd2l0aCBhIHJlY2VudCBYZW4gaHlwZXJ2aXNv
ciB2ZXJzaW9uLiBYZW4gNC4xLjMgb3IgNC4yLjAuCj4+PiBJdCBoZWxwcyBhIGxvdCB0byBrbm93
IGlmIHRoZSBpc3N1ZSBpcyBzdGlsbCBpbiB0aGUgbGF0ZXN0IGh5cGVydmlzb3IKPj4+IHZlcnNp
b25zIG9yIG5vdC4KPgo+IFRoZXJlIGlzIHNvbWVvbmUgdGhhdCBoYWQgdGhlIHByb2JsZW0gYW5k
IHNvbHZlZCB1c2luZyBhIHJlY2VudCB4ZW4KPiBoeXBlcnZpc29yPwo+Cj4KCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxp
c3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVs
Cg==

From xen-devel-bounces@lists.xen.org Mon Oct 15 09:40:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 09:40:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNh9r-0007LN-JI; Mon, 15 Oct 2012 09:40:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mrsanna1@gmail.com>)
	id 1TNh8y-0007Cy-1m; Mon, 15 Oct 2012 09:39:28 +0000
Received: from [85.158.143.35:33562] by server-2.bemta-4.messagelabs.com id
	B0/E3-25171-FC9DB705; Mon, 15 Oct 2012 09:39:27 +0000
X-Env-Sender: mrsanna1@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1350293963!14372120!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24605 invoked from network); 15 Oct 2012 09:39:25 -0000
Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com)
	(209.85.212.43)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 09:39:25 -0000
Received: by mail-vb0-f43.google.com with SMTP id fq11so6252994vbb.30
	for <multiple recipients>; Mon, 15 Oct 2012 02:39:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=vINeOYpc47SNrMBm0U7ufEVf2lkR4HYAzDuQx1w9Ji4=;
	b=RYYRXwgI5BI/3jAOIcpzVRfKAM3NkBhIeT2Hw/MqBE26tt3EZ2NGP2Km1N52J3mk0b
	7f8w9DTrwfqVmtGEK6S9uhbWWNnp/Ti/NFdfbwGvm85dLZjTw2Qv1UH7ndikZlmf/iig
	ExXojYMkgdKNCZvViZW4xkWre6EE0v9ALnarFwJ7N7E5tp17glJNJiKI1+GsM0wCSF6h
	hyueNXrPWGqu6ov1BPskFkj+oqn8sRkXPqu8rE7LD7Q5KrrjiQ4nIrXaiNMnhfxqE7n8
	2GyhO3dleHZhMj0ijES3O82iqZNgWCNPaFB0ycobo63d8dSpT4C8BbnGOwmJ0SpgOtCB
	Hf+w==
MIME-Version: 1.0
Received: by 10.220.231.138 with SMTP id jq10mr6384946vcb.29.1350293963223;
	Mon, 15 Oct 2012 02:39:23 -0700 (PDT)
Received: by 10.58.207.75 with HTTP; Mon, 15 Oct 2012 02:39:23 -0700 (PDT)
In-Reply-To: <FF93AF260AC2BB499A119CC65B092CF73148901B@sg000713.corproot.net>
References: <AANLkTikptc2POrKQgJuoVZRdwJTo64DJ_hm12KuPky4D@mail.gmail.com>
	<b1ca6ddc-ca69-447e-93e9-8d36d1ff4a43@default>
	<AANLkTinK94GDOF_GeaVs50wK0u8EdZ2rtzPuh65ca8qR@mail.gmail.com>
	<CAE17a0UPyzsNn=ps9MxarkGg=ns8dCpVz0qBDvesT2AOskwfVg@mail.gmail.com>
	<65395f62-74e5-4910-b701-8df629c2ce3b@default>
	<CABx4GKrQxOOQo_uUXSFvy0nzdMp1A_qc=_e4K+88GkB7xv=9nw@mail.gmail.com>
	<CAE17a0VkMuUEG9VaM7AFrwcsEjVBq9RfvTWz1_KmscAyCxeAbA@mail.gmail.com>
	<CABx4GKqrTEV7CEnAVUfYr-+yky8N5P1U29xDbrESH-mHB0iZhQ@mail.gmail.com>
	<CAE17a0UYwqLxoZaVDgQCvUR2KQK4vvP3bkvsdrwgnsUp33xuNQ@mail.gmail.com>
	<CAE17a0UQocJjZc38c2805uYvdwR7e447UGH9ywcxMw1Ge3imfg@mail.gmail.com>
	<20120930151314.GU8912@reaktio.net>
	<CAE17a0WWvpwW-V5hQOgL1CiuVZFKyzhZVZfTVq74ZsJUo1SE8w@mail.gmail.com>
	<CAE17a0WvLyduj4V68qPJRLcjc5V7xZ=iTNprKWJyGAX_6RXC+Q@mail.gmail.com>
	<CABx4GKr-AxZmCyGmd4qenMtgdo2Yg+UnT4ymbONjBtuS+w=g7Q@mail.gmail.com>
	<FF93AF260AC2BB499A119CC65B092CF73148901B@sg000713.corproot.net>
Date: Mon, 15 Oct 2012 11:39:23 +0200
Message-ID: <CAE17a0UZDEaXOVLYoeUwELYE+F1wkFpGKG8q2VTRFBvCyC8D3Q@mail.gmail.com>
From: Mauro <mrsanna1@gmail.com>
To: Philippe.Simonet@swisscom.com
X-Mailman-Approved-At: Mon, 15 Oct 2012 09:40:21 +0000
Cc: dan.magenheimer@oracle.com, xen-devel@lists.xensource.com, keir@xen.org,
	jeremy@goop.org, olivier.hanesse@gmail.com, keir.xen@gmail.com,
	xen-users@lists.xensource.com, mark@campbell-lange.net
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

cmVhbGx5IHJlYWxseSBiYWQgbmV3cywgSSBob3BlIHRoaXMgYW5ub3lpbmcgcHJvYmxlbSB3aWxs
IGJlIHJlc29sdmVkIHZlcnkgc29vbi4KCgpPbiAxNSBPY3RvYmVyIDIwMTIgMTA6MDUsICA8UGhp
bGlwcGUuU2ltb25ldEBzd2lzc2NvbS5jb20+IHdyb3RlOgo+IEhpIE9saXZlcgo+Cj4KPgo+IGJh
ZCBuZXdzLCB0aGlzIG1lYW5zIHRoYXQgeGVuIDQuMXh4eCBkb2VzbuKAmXQgc29sdmUgdGhpcyBp
c3N1ZSDigKYKPgo+Cj4KPiBvbiBteSBzaWRlLCBvbiBteSAgaGFyZHdhcmUgdGhhdCBwcm9kdWNl
IHRoaXMgYnVnICxJIG5ldmVyIGhhZCB0aGUgcHJvYmxlbQo+IHdoaXQgdGhpcyBjb21iaW5hdGlv
biA6ICgxMDAlIFdIRUVaWSkKPgo+IGlpICB4ZW4taHlwZXJ2aXNvci00LjEtYW1kNjQgICAgICAg
ICAgICAgICAgICA0LjEuMy0yCj4gYW1kNjQgICAgICAgIFhlbiBIeXBlcnZpc29yIG9uIEFNRDY0
Cj4KPiBpaSAgbGludXgtaW1hZ2UtMy4yLjAtMy1hbWQ2NCAgICAgICAgICAgICAgICAgMy4yLjIz
LTEKPiBhbWQ2NCAgICAgICAgTGludXggMy4yIGZvciA2NC1iaXQgUENzCj4KPgo+Cj4gICAgICAg
ICAgICAgICAgICh0aGlzIHdhcyBiZWNhdXNlIEkgaGFkIGEgZ3JlYXQgaG9wZSB0aGF0IDQuMS54
eHggc29sdmVkIHRoZQo+IHByb2JsZW0g4oCmKQo+Cj4KPgo+IFBoaWxpcHBlCj4KPgo+Cj4KPgo+
Cj4KPiBGcm9tOiB4ZW4tZGV2ZWwtYm91bmNlc0BsaXN0cy54ZW4ub3JnCj4gW21haWx0bzp4ZW4t
ZGV2ZWwtYm91bmNlc0BsaXN0cy54ZW4ub3JnXSBPbiBCZWhhbGYgT2YgT2xpdmllciBIYW5lc3Nl
Cj4gU2VudDogTW9uZGF5LCBPY3RvYmVyIDE1LCAyMDEyIDk6NDAgQU0KPiBUbzogTWF1cm8KPiBD
YzogRGFuIE1hZ2VuaGVpbWVyOyB4ZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbTsgS2VpciBG
cmFzZXI7IEplcmVteQo+IEZpdHpoYXJkaW5nZTsgS2VpciBGcmFzZXI7IFhlbiBVc2VyczsgTWFy
ayBBZGFtcwo+IFN1YmplY3Q6IFJlOiBbWGVuLWRldmVsXSBbWGVuLXVzZXJzXSBSZTogWGVuIDQg
VFNDIHByb2JsZW1zCj4KPgo+Cj4gSGVsbG8sCj4KPgo+Cj4gU3RyYW5nZSB0aGluZ3Mgb24gdGhp
cyByYWlueSBtb3JuaW5nLCBJIGdvdCB0aGlzIGJ1ZyBhZ2FpbiBvbiBhbm90aGVyCj4gaGFyZHdh
cmUsIGFuZCBYZW4gaHlwZXJ2aXNvciBmcm9tIFdoZWV6eSBhbmQga2VybmVsIGZyb20gU3F1ZWV6
ZS4KPgo+Cj4KPiBpaSAgbGludXgtaW1hZ2UtMi42LjMyLTUteGVuLWFtZDY0ICAgICAgMi42LjMy
LTQ2ICAgICAgICAgICAgICAgICAgTGludXgKPiAyLjYuMzIgZm9yIDY0LWJpdCBQQ3MsIFhlbiBk
b20wIHN1cHBvcnQKPgo+IGlpICB4ZW4taHlwZXJ2aXNvci00LjEtYW1kNjQgICAgICAgICAgICAg
ICA0LjEuMy0yICAgICAgICAgICAgICAgICAgICAgIFhlbgo+IEh5cGVydmlzb3Igb24gQU1ENjQK
Pgo+Cj4KPiBJJ3ZlIHVwZ3JhZGVkIHRoaXMgc2VydmVyIGxhc3Qgd2Vlay4gSSBkb24ndCBrbm93
IGlmIGl0IGlzIGxpbmtlZCBvciBub3QsCj4gYnV0IEkgZGlkbid0IGdldCBhbnkgJ3RpbWUgd3Jh
cCcgb24gdGhpcyBzZXJ2ZXIgZm9yIG1vcmUgdGhhbiAyNTBkYXlzLgo+Cj4gTWF5YmUgaXQgaXMg
cmVsYXRlZCB0byB0aGUgdXBncmFkZSBwcm9jZXNzLiBCZWZvcmUgdGhlIHVwZ3JhZGUsIG15IHZl
cnNpb24KPiB3ZXJlIDoKPgo+Cj4KPiBpaSAgbGludXgtaW1hZ2UtMi42LjMyLTUteGVuLWFtZDY0
ICAgMi42LjMyLTQxc3F1ZWV6ZTIgICAgICAgICAgICBMaW51eAo+IDIuNi4zMiBmb3IgNjQtYml0
IFBDcywgWGVuIGRvbTAgc3VwcG9ydAo+Cj4gaWkgIHhlbi1oeXBlcnZpc29yLTQuMS1hbWQ2NCAg
ICAgICAgICAgIDQuMS4yLTIgICAgICAgICAgICAgICAgICAgICAgWGVuCj4gSHlwZXJ2aXNvciBv
biBBTUQ2NAo+Cj4KPgo+IEkgb25seSB1cGdyYWRlZCBoYWxmIG9mIG15IHNlcnZlcnMsIHNvIEkg
d2lsbCB3YWl0IGEgbGl0dGxlIGJpdCB0byB1cGdyYWRlCj4gdGhlIG90aGVyIGhhbGYgYW5kIHNl
ZSBpZiB0aGlzIGlzc3VlIG9jY3VycyBhZ2FpbiBvbmx5IG9uIHVwZGF0ZWQgc2VydmVycy4KPgo+
Cj4KPiBGb3IgdGhlIHJlY29yZCwgYWx3YXlzIHRoZSBzYW1lIGVycm9ycyA6Cj4KPgo+Cj4geG0g
ZG1lc2cgPT4gKFhFTikgUGxhdGZvcm0gdGltZXIgYXBwZWFycyB0byBoYXZlIHVuZXhwZWN0ZWRs
eSB3cmFwcGVkIDEwIG9yCj4gbW9yZSB0aW1lcy4KPgo+Cj4KPiAvdmFyL2xvZy8qICAgPT4gT2N0
IDE0IDIyOjQ2OjA3IGV1bDI0MDA0Njgga2VybmVsOiBbNzM0NjE4LjU2MjIxOV0KPiBDbG9ja3Nv
dXJjZSB0c2MgdW5zdGFibGUgKGRlbHRhID0gLTI5OTk2NjAzMTMzNzAgbnMpCj4KPgo+Cj4gSSB0
aG91Z2h0IGl0IHdhcyB0aGlzIGlzc3VlIHdhcyBoYXJkd2FyZSByZWxhdGVkLCBtYXliZSBub3Qu
Cj4KPgo+Cj4gT2xpdmllcgo+Cj4KPgo+IDIwMTIvOS8zMCBNYXVybyA8bXJzYW5uYTFAZ21haWwu
Y29tPgo+Cj4gT24gMzAgU2VwdGVtYmVyIDIwMTIgMjE6MjMsIE1hdXJvIDxtcnNhbm5hMUBnbWFp
bC5jb20+IHdyb3RlOgo+PiBPbiAzMCBTZXB0ZW1iZXIgMjAxMiAxNzoxMywgUGFzaSBLw6Rya2vD
pGluZW4gPHBhc2lrQGlraS5maT4gd3JvdGU6Cj4+PiBPbiBTYXQsIFNlcCAyOSwgMjAxMiBhdCAw
MjoxOTo1NVBNICswMjAwLCBNYXVybyB3cm90ZToKPj4+PiBJdCdzIGhhcHBlbmVkIGFub3RoZXIg
dGltZSwgc3lzdGVtIGRhdGUgNTAgbWludXRlcyBhaGVhZC4KPj4+PiBUaGVyZSBpcyByZWFsbHkg
bm8gc29sdXRpb24/Cj4+Pj4KPj4+Cj4+PiBUcnkgd2l0aCBhIHJlY2VudCBYZW4gaHlwZXJ2aXNv
ciB2ZXJzaW9uLiBYZW4gNC4xLjMgb3IgNC4yLjAuCj4+PiBJdCBoZWxwcyBhIGxvdCB0byBrbm93
IGlmIHRoZSBpc3N1ZSBpcyBzdGlsbCBpbiB0aGUgbGF0ZXN0IGh5cGVydmlzb3IKPj4+IHZlcnNp
b25zIG9yIG5vdC4KPgo+IFRoZXJlIGlzIHNvbWVvbmUgdGhhdCBoYWQgdGhlIHByb2JsZW0gYW5k
IHNvbHZlZCB1c2luZyBhIHJlY2VudCB4ZW4KPiBoeXBlcnZpc29yPwo+Cj4KCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxp
c3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVs
Cg==

From xen-devel-bounces@lists.xen.org Mon Oct 15 09:43:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 09:43:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNhCH-0007gB-6w; Mon, 15 Oct 2012 09:42:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TNhCF-0007fv-CQ
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 09:42:51 +0000
Received: from [85.158.143.99:42811] by server-3.bemta-4.messagelabs.com id
	AF/06-10075-A9ADB705; Mon, 15 Oct 2012 09:42:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1350294169!27696641!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19046 invoked from network); 15 Oct 2012 09:42:49 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-216.messagelabs.com with SMTP;
	15 Oct 2012 09:42:49 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 15 Oct 2012 10:42:49 +0100
Message-Id: <507BF6B402000078000A14D8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 15 Oct 2012 10:42:44 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <patchbomb.1349720160@andrewcoop.uk.xensource.com>
	<0a1a3f35f56a1a2b3b8f.1349720163@andrewcoop.uk.xensource.com>
	<507BF24D02000078000A1497@nat28.tlf.novell.com>
	<507BD95B.7070003@citrix.com>
In-Reply-To: <507BD95B.7070003@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 3 of 3] xen/debug: Introduce ASSERT_RUN()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.10.12 at 11:37, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> I presume that you mean I should?  Why would that prevent the need for
> #ifdefs? I can see the argument for type compatibility.

Because if func is a static function defined for use just in an
ASSERT_RUN(), the compiler would warn about it being unused
in non-debug builds.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 09:43:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 09:43:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNhCH-0007gB-6w; Mon, 15 Oct 2012 09:42:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TNhCF-0007fv-CQ
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 09:42:51 +0000
Received: from [85.158.143.99:42811] by server-3.bemta-4.messagelabs.com id
	AF/06-10075-A9ADB705; Mon, 15 Oct 2012 09:42:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1350294169!27696641!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19046 invoked from network); 15 Oct 2012 09:42:49 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-216.messagelabs.com with SMTP;
	15 Oct 2012 09:42:49 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 15 Oct 2012 10:42:49 +0100
Message-Id: <507BF6B402000078000A14D8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 15 Oct 2012 10:42:44 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <patchbomb.1349720160@andrewcoop.uk.xensource.com>
	<0a1a3f35f56a1a2b3b8f.1349720163@andrewcoop.uk.xensource.com>
	<507BF24D02000078000A1497@nat28.tlf.novell.com>
	<507BD95B.7070003@citrix.com>
In-Reply-To: <507BD95B.7070003@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 3 of 3] xen/debug: Introduce ASSERT_RUN()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.10.12 at 11:37, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> I presume that you mean I should?  Why would that prevent the need for
> #ifdefs? I can see the argument for type compatibility.

Because if func is a static function defined for use just in an
ASSERT_RUN(), the compiler would warn about it being unused
in non-debug builds.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 09:52:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 09:52:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNhLJ-00083t-7e; Mon, 15 Oct 2012 09:52:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1TNhLH-00083l-CQ
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 09:52:11 +0000
Received: from [85.158.139.211:20832] by server-6.bemta-5.messagelabs.com id
	AB/8B-32589-ACCDB705; Mon, 15 Oct 2012 09:52:10 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1350294728!20824491!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYzNjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22131 invoked from network); 15 Oct 2012 09:52:10 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 09:52:10 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="41198301"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 09:52:08 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 05:52:07 -0400
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1TNhLD-0002RH-MX;
	Mon, 15 Oct 2012 10:52:07 +0100
Message-ID: <507BDCC7.8030306@citrix.com>
Date: Mon, 15 Oct 2012 10:52:07 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <patchbomb.1349720160@andrewcoop.uk.xensource.com>
	<0a1a3f35f56a1a2b3b8f.1349720163@andrewcoop.uk.xensource.com>
	<507BF24D02000078000A1497@nat28.tlf.novell.com>
	<507BD95B.7070003@citrix.com>
	<507BF6B402000078000A14D8@nat28.tlf.novell.com>
In-Reply-To: <507BF6B402000078000A14D8@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.5
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 3 of 3] xen/debug: Introduce ASSERT_RUN()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 15/10/12 10:42, Jan Beulich wrote:
>>>> On 15.10.12 at 11:37, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> I presume that you mean I should?  Why would that prevent the need for
>> #ifdefs? I can see the argument for type compatibility.
> Because if func is a static function defined for use just in an
> ASSERT_RUN(), the compiler would warn about it being unused
> in non-debug builds.
>
> Jan
>

Ah yes.  I see now.

As I am going to respin these patches, would you like BUG and WARN
variants (of at least the PRINTK version) ?

~Andrew

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 09:52:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 09:52:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNhLJ-00083t-7e; Mon, 15 Oct 2012 09:52:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1TNhLH-00083l-CQ
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 09:52:11 +0000
Received: from [85.158.139.211:20832] by server-6.bemta-5.messagelabs.com id
	AB/8B-32589-ACCDB705; Mon, 15 Oct 2012 09:52:10 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1350294728!20824491!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYzNjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22131 invoked from network); 15 Oct 2012 09:52:10 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 09:52:10 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="41198301"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 09:52:08 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 05:52:07 -0400
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<andrew.cooper3@citrix.com>)	id 1TNhLD-0002RH-MX;
	Mon, 15 Oct 2012 10:52:07 +0100
Message-ID: <507BDCC7.8030306@citrix.com>
Date: Mon, 15 Oct 2012 10:52:07 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <patchbomb.1349720160@andrewcoop.uk.xensource.com>
	<0a1a3f35f56a1a2b3b8f.1349720163@andrewcoop.uk.xensource.com>
	<507BF24D02000078000A1497@nat28.tlf.novell.com>
	<507BD95B.7070003@citrix.com>
	<507BF6B402000078000A14D8@nat28.tlf.novell.com>
In-Reply-To: <507BF6B402000078000A14D8@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.5
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 3 of 3] xen/debug: Introduce ASSERT_RUN()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 15/10/12 10:42, Jan Beulich wrote:
>>>> On 15.10.12 at 11:37, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> I presume that you mean I should?  Why would that prevent the need for
>> #ifdefs? I can see the argument for type compatibility.
> Because if func is a static function defined for use just in an
> ASSERT_RUN(), the compiler would warn about it being unused
> in non-debug builds.
>
> Jan
>

Ah yes.  I see now.

As I am going to respin these patches, would you like BUG and WARN
variants (of at least the PRINTK version) ?

~Andrew

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 09:56:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 09:56:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNhPg-0008GA-2K; Mon, 15 Oct 2012 09:56:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gabrielx.wu@intel.com>) id 1TNhPf-0008G3-7w
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 09:56:43 +0000
Received: from [85.158.143.99:14544] by server-3.bemta-4.messagelabs.com id
	85/4D-10075-ADDDB705; Mon, 15 Oct 2012 09:56:42 +0000
X-Env-Sender: gabrielx.wu@intel.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1350295001!34116033!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMyOTA4NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5588 invoked from network); 15 Oct 2012 09:56:41 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-15.tower-216.messagelabs.com with SMTP;
	15 Oct 2012 09:56:41 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 15 Oct 2012 02:56:40 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,587,1344236400"; d="scan'208";a="233982454"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by fmsmga001.fm.intel.com with ESMTP; 15 Oct 2012 02:56:40 -0700
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 15 Oct 2012 02:56:40 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.92]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.239]) with mapi id
	14.01.0355.002; Mon, 15 Oct 2012 17:56:38 +0800
From: "Wu, GabrielX" <gabrielx.wu@intel.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: VMX status report. Xen:26042 & Dom0:3.6.1
Thread-Index: AQHNQKNIzN9DYzRe7EmcNins26UkQJb+skTggBKA8xCABFRNQIAVWItggAQG5GCADlPDsIAacyQwgBT48ZCAFeXQ0IAWO4fggADtiSCAH4HfcIABva3w
Date: Mon, 15 Oct 2012 09:56:37 +0000
Message-ID: <E4558C0C96688748837EB1B05BEED75A0FD76081@SHSMSX102.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "Ren, Yongjie" <yongjie.ren@intel.com>, "Liu,
	SongtaoX" <songtaox.liu@intel.com>, "Liu,
	RongrongX" <rongrongx.liu@intel.com>, "Zhou, Chao" <chao.zhou@intel.com>
Subject: [Xen-devel] VMX status report. Xen:26042 & Dom0:3.6.1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,

This is the test report of xen-unstable tree, one issue found and one issue fixed.

Version Info:
=================================================================
xen-changeset:   26042:3696dd6a7836
Dom0:          linux.git  3.6.1
=================================================================

New issue(1)
==============
1. xl pci-list shows one PCI device (PF or VF) could be assigned to two different guests
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1834

Fixed issue(1)
==============
1. Fail to probe NIC driver in domu
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1824

Old issues(8)
==============
1. [ACPI] System cann't resume after do suspend
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1707
2. [XL]"xl vcpu-set" causes dom0 crash or panic
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1730
3. [VT-D]fail to detach NIC from guest  
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1736
4. Sometimes Xen panic on ia32pae Sandybridge when restore guest
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1747
5. after detaching a VF from a guest, shutdown the guest is very slow
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1812
6. Poor performance when do guest save/restore and migration with linux 3.1 dom0
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1784
7. vcpu-set doesn't take effect on guest
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822
8. Dom0 cannot be shutdown before PCI device detachment from guest
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1826


Best Regards,
Ronghui Wu(Gabriel)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 09:56:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 09:56:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNhPg-0008GA-2K; Mon, 15 Oct 2012 09:56:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gabrielx.wu@intel.com>) id 1TNhPf-0008G3-7w
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 09:56:43 +0000
Received: from [85.158.143.99:14544] by server-3.bemta-4.messagelabs.com id
	85/4D-10075-ADDDB705; Mon, 15 Oct 2012 09:56:42 +0000
X-Env-Sender: gabrielx.wu@intel.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1350295001!34116033!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMyOTA4NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5588 invoked from network); 15 Oct 2012 09:56:41 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-15.tower-216.messagelabs.com with SMTP;
	15 Oct 2012 09:56:41 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 15 Oct 2012 02:56:40 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,587,1344236400"; d="scan'208";a="233982454"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by fmsmga001.fm.intel.com with ESMTP; 15 Oct 2012 02:56:40 -0700
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 15 Oct 2012 02:56:40 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.92]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.239]) with mapi id
	14.01.0355.002; Mon, 15 Oct 2012 17:56:38 +0800
From: "Wu, GabrielX" <gabrielx.wu@intel.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: VMX status report. Xen:26042 & Dom0:3.6.1
Thread-Index: AQHNQKNIzN9DYzRe7EmcNins26UkQJb+skTggBKA8xCABFRNQIAVWItggAQG5GCADlPDsIAacyQwgBT48ZCAFeXQ0IAWO4fggADtiSCAH4HfcIABva3w
Date: Mon, 15 Oct 2012 09:56:37 +0000
Message-ID: <E4558C0C96688748837EB1B05BEED75A0FD76081@SHSMSX102.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "Ren, Yongjie" <yongjie.ren@intel.com>, "Liu,
	SongtaoX" <songtaox.liu@intel.com>, "Liu,
	RongrongX" <rongrongx.liu@intel.com>, "Zhou, Chao" <chao.zhou@intel.com>
Subject: [Xen-devel] VMX status report. Xen:26042 & Dom0:3.6.1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,

This is the test report of xen-unstable tree, one issue found and one issue fixed.

Version Info:
=================================================================
xen-changeset:   26042:3696dd6a7836
Dom0:          linux.git  3.6.1
=================================================================

New issue(1)
==============
1. xl pci-list shows one PCI device (PF or VF) could be assigned to two different guests
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1834

Fixed issue(1)
==============
1. Fail to probe NIC driver in domu
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1824

Old issues(8)
==============
1. [ACPI] System cann't resume after do suspend
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1707
2. [XL]"xl vcpu-set" causes dom0 crash or panic
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1730
3. [VT-D]fail to detach NIC from guest  
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1736
4. Sometimes Xen panic on ia32pae Sandybridge when restore guest
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1747
5. after detaching a VF from a guest, shutdown the guest is very slow
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1812
6. Poor performance when do guest save/restore and migration with linux 3.1 dom0
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1784
7. vcpu-set doesn't take effect on guest
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822
8. Dom0 cannot be shutdown before PCI device detachment from guest
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1826


Best Regards,
Ronghui Wu(Gabriel)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 09:59:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 09:59:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNhSA-0008ND-Kn; Mon, 15 Oct 2012 09:59:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TNhS8-0008N5-Om
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 09:59:16 +0000
Received: from [85.158.137.99:48490] by server-13.bemta-3.messagelabs.com id
	DF/A0-26794-37EDB705; Mon, 15 Oct 2012 09:59:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1350295155!18451991!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4737 invoked from network); 15 Oct 2012 09:59:15 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-217.messagelabs.com with SMTP;
	15 Oct 2012 09:59:15 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 15 Oct 2012 10:59:14 +0100
Message-Id: <507BFA9002000078000A14F3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 15 Oct 2012 10:59:12 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <patchbomb.1349720160@andrewcoop.uk.xensource.com>
	<0a1a3f35f56a1a2b3b8f.1349720163@andrewcoop.uk.xensource.com>
	<507BF24D02000078000A1497@nat28.tlf.novell.com>
	<507BD95B.7070003@citrix.com>
	<507BF6B402000078000A14D8@nat28.tlf.novell.com>
	<507BDCC7.8030306@citrix.com>
In-Reply-To: <507BDCC7.8030306@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 3 of 3] xen/debug: Introduce ASSERT_RUN()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.10.12 at 11:52, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> As I am going to respin these patches, would you like BUG and WARN
> variants (of at least the PRINTK version) ?

For WARN, yes (but in its Linux incarnation, i.e. without any PRINTK
in the name). For a BUG() variant I'm not that sure of its usefulness.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 09:59:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 09:59:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNhSA-0008ND-Kn; Mon, 15 Oct 2012 09:59:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TNhS8-0008N5-Om
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 09:59:16 +0000
Received: from [85.158.137.99:48490] by server-13.bemta-3.messagelabs.com id
	DF/A0-26794-37EDB705; Mon, 15 Oct 2012 09:59:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1350295155!18451991!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4737 invoked from network); 15 Oct 2012 09:59:15 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-217.messagelabs.com with SMTP;
	15 Oct 2012 09:59:15 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 15 Oct 2012 10:59:14 +0100
Message-Id: <507BFA9002000078000A14F3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 15 Oct 2012 10:59:12 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <patchbomb.1349720160@andrewcoop.uk.xensource.com>
	<0a1a3f35f56a1a2b3b8f.1349720163@andrewcoop.uk.xensource.com>
	<507BF24D02000078000A1497@nat28.tlf.novell.com>
	<507BD95B.7070003@citrix.com>
	<507BF6B402000078000A14D8@nat28.tlf.novell.com>
	<507BDCC7.8030306@citrix.com>
In-Reply-To: <507BDCC7.8030306@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 3 of 3] xen/debug: Introduce ASSERT_RUN()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.10.12 at 11:52, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> As I am going to respin these patches, would you like BUG and WARN
> variants (of at least the PRINTK version) ?

For WARN, yes (but in its Linux incarnation, i.e. without any PRINTK
in the name). For a BUG() variant I'm not that sure of its usefulness.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 10:00:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 10:00:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNhTZ-000065-38; Mon, 15 Oct 2012 10:00:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1TNhTY-00005z-6Y
	for xen-devel@lists.xensource.com; Mon, 15 Oct 2012 10:00:44 +0000
Received: from [85.158.143.99:17453] by server-1.bemta-4.messagelabs.com id
	C8/54-19551-BCEDB705; Mon, 15 Oct 2012 10:00:43 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1350295238!24358747!1
X-Originating-IP: [216.32.180.14]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29654 invoked from network); 15 Oct 2012 10:00:40 -0000
Received: from va3ehsobe004.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.14)
	by server-8.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	15 Oct 2012 10:00:40 -0000
Received: from mail251-va3-R.bigfish.com (10.7.14.242) by
	VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id
	14.1.225.23; Mon, 15 Oct 2012 10:00:38 +0000
Received: from mail251-va3 (localhost [127.0.0.1])	by
	mail251-va3-R.bigfish.com (Postfix) with ESMTP id 581BA920279;
	Mon, 15 Oct 2012 10:00:38 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: -7
X-BigFish: VPS-7(zzbb2dI98dI9371I1dbaI1432I1418I4015Izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh137ah13b6h1441h1155h)
Received: from mail251-va3 (localhost.localdomain [127.0.0.1]) by mail251-va3
	(MessageSwitch) id 1350295236841903_6720;
	Mon, 15 Oct 2012 10:00:36 +0000 (UTC)
Received: from VA3EHSMHS006.bigfish.com (unknown [10.7.14.241])	by
	mail251-va3.bigfish.com (Postfix) with ESMTP id CB584104005F;
	Mon, 15 Oct 2012 10:00:36 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS006.bigfish.com (10.7.99.16) with Microsoft SMTP Server id
	14.1.225.23; Mon, 15 Oct 2012 10:00:35 +0000
X-WSS-ID: 0MBXIGU-02-0H3-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 227DAC80A7;	Mon, 15 Oct 2012 05:00:30 -0500 (CDT)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Mon, 15 Oct 2012 05:16:16 -0500
Received: from STOREXDAG04.amd.com (10.1.13.13) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Mon, 15 Oct 2012 05:00:33 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexdag04.amd.com
	(10.1.13.13) with Microsoft SMTP Server id 14.1.323.3; Mon, 15 Oct 2012
	06:00:32 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 0311E49C35C; Mon, 15 Oct 2012
	11:00:32 +0100 (BST)
Message-ID: <507BDED1.6020005@amd.com>
Date: Mon, 15 Oct 2012 12:00:49 +0200
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120421 Thunderbird/12.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <5063155A.4070307@amd.com>
	<50642A2A020000780009E32D@nat28.tlf.novell.com>
In-Reply-To: <50642A2A020000780009E32D@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	IanCampbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2 of 6 V6] amd iommu: call
	guest_iommu_set_base from hvmloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/27/2012 10:27 AM, Jan Beulich wrote:
>>>> On 26.09.12 at 16:46, Wei Wang<wei.wang2@amd.com>  wrote:
>> @@ -3834,6 +3835,9 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
>>              case HVM_PARAM_BUFIOREQ_EVTCHN:
>>                  rc = -EINVAL;
>>                  break;
>> +            case HVM_PARAM_IOMMU_BASE:
>> +                rc = guest_iommu_set_base(d, a.value);
>
> This suggests that you're allowing for only a single IOMMU per
> guest - is that not going to become an issue sooner or later?
>
> Jan
>
>> +                break;
>>              }
>>
>>              if ( rc == 0 )
>
>
>

HI Jan,
I think that one iommu per guest is probably enough. Because guest IVRS 
table is totally virtual, it does not reflect any pci relationship of 
real systems. Even if qemu supports multi pci buses, we can still 
virtually group them together into one virtual IVRS table. It might be 
an issue if qemu uses multi pci segments, but so far even hardware iommu 
only uses segment 0. Additionally, the guest iommu is only used by ats 
capable GPUs. Normal passthrough device should not make use of it. So,, 
What do you think?

Thanks,
Wei


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 10:00:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 10:00:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNhTZ-000065-38; Mon, 15 Oct 2012 10:00:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1TNhTY-00005z-6Y
	for xen-devel@lists.xensource.com; Mon, 15 Oct 2012 10:00:44 +0000
Received: from [85.158.143.99:17453] by server-1.bemta-4.messagelabs.com id
	C8/54-19551-BCEDB705; Mon, 15 Oct 2012 10:00:43 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1350295238!24358747!1
X-Originating-IP: [216.32.180.14]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29654 invoked from network); 15 Oct 2012 10:00:40 -0000
Received: from va3ehsobe004.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.14)
	by server-8.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	15 Oct 2012 10:00:40 -0000
Received: from mail251-va3-R.bigfish.com (10.7.14.242) by
	VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id
	14.1.225.23; Mon, 15 Oct 2012 10:00:38 +0000
Received: from mail251-va3 (localhost [127.0.0.1])	by
	mail251-va3-R.bigfish.com (Postfix) with ESMTP id 581BA920279;
	Mon, 15 Oct 2012 10:00:38 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: -7
X-BigFish: VPS-7(zzbb2dI98dI9371I1dbaI1432I1418I4015Izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh137ah13b6h1441h1155h)
Received: from mail251-va3 (localhost.localdomain [127.0.0.1]) by mail251-va3
	(MessageSwitch) id 1350295236841903_6720;
	Mon, 15 Oct 2012 10:00:36 +0000 (UTC)
Received: from VA3EHSMHS006.bigfish.com (unknown [10.7.14.241])	by
	mail251-va3.bigfish.com (Postfix) with ESMTP id CB584104005F;
	Mon, 15 Oct 2012 10:00:36 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS006.bigfish.com (10.7.99.16) with Microsoft SMTP Server id
	14.1.225.23; Mon, 15 Oct 2012 10:00:35 +0000
X-WSS-ID: 0MBXIGU-02-0H3-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 227DAC80A7;	Mon, 15 Oct 2012 05:00:30 -0500 (CDT)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Mon, 15 Oct 2012 05:16:16 -0500
Received: from STOREXDAG04.amd.com (10.1.13.13) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Mon, 15 Oct 2012 05:00:33 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexdag04.amd.com
	(10.1.13.13) with Microsoft SMTP Server id 14.1.323.3; Mon, 15 Oct 2012
	06:00:32 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 0311E49C35C; Mon, 15 Oct 2012
	11:00:32 +0100 (BST)
Message-ID: <507BDED1.6020005@amd.com>
Date: Mon, 15 Oct 2012 12:00:49 +0200
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120421 Thunderbird/12.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <5063155A.4070307@amd.com>
	<50642A2A020000780009E32D@nat28.tlf.novell.com>
In-Reply-To: <50642A2A020000780009E32D@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	IanCampbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2 of 6 V6] amd iommu: call
	guest_iommu_set_base from hvmloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/27/2012 10:27 AM, Jan Beulich wrote:
>>>> On 26.09.12 at 16:46, Wei Wang<wei.wang2@amd.com>  wrote:
>> @@ -3834,6 +3835,9 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
>>              case HVM_PARAM_BUFIOREQ_EVTCHN:
>>                  rc = -EINVAL;
>>                  break;
>> +            case HVM_PARAM_IOMMU_BASE:
>> +                rc = guest_iommu_set_base(d, a.value);
>
> This suggests that you're allowing for only a single IOMMU per
> guest - is that not going to become an issue sooner or later?
>
> Jan
>
>> +                break;
>>              }
>>
>>              if ( rc == 0 )
>
>
>

HI Jan,
I think that one iommu per guest is probably enough. Because guest IVRS 
table is totally virtual, it does not reflect any pci relationship of 
real systems. Even if qemu supports multi pci buses, we can still 
virtually group them together into one virtual IVRS table. It might be 
an issue if qemu uses multi pci segments, but so far even hardware iommu 
only uses segment 0. Additionally, the guest iommu is only used by ats 
capable GPUs. Normal passthrough device should not make use of it. So,, 
What do you think?

Thanks,
Wei


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 10:10:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 10:10:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNhcV-0000Qg-Ia; Mon, 15 Oct 2012 10:09:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TNhcU-0000Q3-25
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 10:09:58 +0000
Received: from [85.158.137.99:18925] by server-12.bemta-3.messagelabs.com id
	0F/35-27853-5F0EB705; Mon, 15 Oct 2012 10:09:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1350295794!21576414!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYzNjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5071 invoked from network); 15 Oct 2012 10:09:56 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 10:09:56 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="41199649"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 10:09:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 06:09:50 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1TNhcM-0002h0-5l;
	Mon, 15 Oct 2012 11:09:50 +0100
MIME-Version: 1.0
X-Mercurial-Node: 2329dca4ef449979b1403c4bb002fcb70c578b35
Message-ID: <2329dca4ef449979b140.1350295791@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1350295789@cosworth.uk.xensource.com>
References: <patchbomb.1350295789@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 15 Oct 2012 11:09:51 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com, linux@eikelenboom.it
Subject: [Xen-devel] [PATCH 2 of 5] xl: Introduce xl shutdown --all support
 for xm compatibility
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Sander Eikelenboom <linux@eikelenboom.it>
# Date 1346960487 -7200
# Node ID 2329dca4ef449979b1403c4bb002fcb70c578b35
# Parent  65e301c71ca41af8cf0aaea653cd9e8d08bca2f7
xl: Introduce xl shutdown --all support for xm compatibility

Based on a patch by Sander Eikelenboom

Signed-off-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>


---

Changed since v3: (ijc)
  * Rebased. -w already implemented.
  * Shutdown domains in //.

Changed since v2:
  * fix error occuring when using both -a and -w options
    * Due to mixing local and global domid variable


Changed since v1:
  * address review comments.
    * Change shutdown_domain to take domid instead of domname
    * Docs: Make it more clear -a only shuts down GUEST domains

diff -r 65e301c71ca4 -r 2329dca4ef44 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Mon Oct 15 09:43:10 2012 +0100
+++ b/docs/man/xl.pod.1	Thu Sep 06 21:41:27 2012 +0200
@@ -527,7 +527,7 @@ List specifically for that domain. Other
 
 =back
 
-=item B<shutdown> [I<OPTIONS>] I<domain-id>
+=item B<shutdown> [I<OPTIONS>] I<-a|domain-id>
 
 Gracefully shuts down a domain.  This coordinates with the domain OS
 to perform graceful shutdown, so there is no guarantee that it will
@@ -550,6 +550,11 @@ B<OPTIONS>
 
 =over 4
 
+=item B<-a>, B<--all>
+
+Shutdown all guest domains.  Often used when doing a complete shutdown
+of a Xen system.
+
 =item B<-w>, B<--wait>
 
 Wait for the domain to complete shutdown before returning.
diff -r 65e301c71ca4 -r 2329dca4ef44 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Oct 15 09:43:10 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Thu Sep 06 21:41:27 2012 +0200
@@ -2713,12 +2713,46 @@ static void destroy_domain(uint32_t domi
     if (rc) { fprintf(stderr,"destroy failed (rc=%d)\n",rc); exit(-1); }
 }
 
-static void shutdown_domain(uint32_t domid, int wait_for_it,
+static void wait_for_domain_deaths(libxl_evgen_domain_death **deathws, int nr)
+{
+    int rc, count = 0;
+    LOG("Waiting for %d domains to shutdown", nr);
+    while(1 && count < nr) {
+        libxl_event *event;
+        rc = libxl_event_wait(ctx, &event, LIBXL_EVENTMASK_ALL, 0,0);
+        if (rc) {
+            LOG("Failed to get event, quitting (rc=%d)", rc);
+            exit(-1);
+        }
+
+        switch (event->type) {
+        case LIBXL_EVENT_TYPE_DOMAIN_DEATH:
+            LOG("Domain %d has been destroyed", event->domid);
+            libxl_evdisable_domain_death(ctx, deathws[event->for_user]);
+            count++;
+            break;
+        case LIBXL_EVENT_TYPE_DOMAIN_SHUTDOWN:
+            LOG("Domain %d has been shut down, reason code %d",
+                event->domid, event->u.domain_shutdown.shutdown_reason);
+            libxl_evdisable_domain_death(ctx, deathws[event->for_user]);
+            count++;
+            break;
+        default:
+            LOG("Unexpected event type %d", event->type);
+            break;
+        }
+        libxl_event_free(ctx, event);
+    }
+}
+
+static void shutdown_domain(uint32_t domid,
+                            libxl_evgen_domain_death **deathw,
+                            libxl_ev_user for_user,
                             int fallback_trigger)
 {
     int rc;
-    libxl_event *event;
-
+
+    fprintf(stderr, "Shutting down domain %d\n", domid);
     rc=libxl_domain_shutdown(ctx, domid);
     if (rc == ERROR_NOPARAVIRT) {
         if (fallback_trigger) {
@@ -2731,44 +2765,19 @@ static void shutdown_domain(uint32_t dom
             fprintf(stderr, "Use \"-F\" to fallback to ACPI power event.\n");
         }
     }
+
     if (rc) {
         fprintf(stderr,"shutdown failed (rc=%d)\n",rc);exit(-1);
     }
 
-    if (wait_for_it) {
-        libxl_evgen_domain_death *deathw;
-
-        rc = libxl_evenable_domain_death(ctx, domid, 0, &deathw);
+    if (deathw) {
+        rc = libxl_evenable_domain_death(ctx, domid, for_user, deathw);
         if (rc) {
             fprintf(stderr,"wait for death failed (evgen, rc=%d)\n",rc);
             exit(-1);
         }
-
-        for (;;) {
-            rc = domain_wait_event(domid, &event);
-            if (rc) exit(-1);
-
-            switch (event->type) {
-
-            case LIBXL_EVENT_TYPE_DOMAIN_DEATH:
-                LOG("Domain %d has been destroyed", domid);
-                goto done;
-
-            case LIBXL_EVENT_TYPE_DOMAIN_SHUTDOWN:
-                LOG("Domain %d has been shut down, reason code %d %x", domid,
-                    event->u.domain_shutdown.shutdown_reason,
-                    event->u.domain_shutdown.shutdown_reason);
-                goto done;
-
-            default:
-                LOG("Unexpected event type %d", event->type);
-                break;
-            }
-            libxl_event_free(ctx, event);
-        }
-    done:
-        libxl_event_free(ctx, event);
-        libxl_evdisable_domain_death(ctx, deathw);
+        printf("Waiting for domain %d death %p %"PRIx64"\n",
+               domid, *deathw, for_user);
     }
 }
 
@@ -3706,18 +3715,21 @@ int main_destroy(int argc, char **argv)
 
 int main_shutdown(int argc, char **argv)
 {
-    int opt;
-    int wait_for_it = 0;
+    int opt, i, nb_domain;
+    int wait_for_it = 0, all =0;
     int fallback_trigger = 0;
     static struct option long_options[] = {
+        {"all", 0, 0, 'a'},
         {"wait", 0, 0, 'w'},
         {0, 0, 0, 0}
     };
 
-    while ((opt = getopt_long(argc, argv, "wF", long_options, NULL)) != -1) {
+    while ((opt = getopt_long(argc, argv, "awF", long_options, NULL)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
+        case 'a':
+            all = 1;
         case 'w':
             wait_for_it = 1;
             break;
@@ -3727,7 +3739,44 @@ int main_shutdown(int argc, char **argv)
         }
     }
 
-    shutdown_domain(find_domain(argv[optind]), wait_for_it, fallback_trigger);
+    if (!argv[optind] && !all) {
+        fprintf(stderr, "You must specify -a or a domain id.\n\n");
+        return opt;
+    }
+
+    if (all) {
+        libxl_dominfo *dominfo;
+        libxl_evgen_domain_death **deathws = NULL;
+        if (!(dominfo = libxl_list_domain(ctx, &nb_domain))) {
+            fprintf(stderr, "libxl_list_domain failed.\n");
+            return -1;
+        }
+
+        if (wait_for_it)
+            deathws = calloc(nb_domain, sizeof(deathws));
+
+        for (i = 0; i<nb_domain; i++) {
+            if (dominfo[i].domid == 0)
+                continue;
+            shutdown_domain(dominfo[i].domid,
+                            deathws ? &deathws[i] : NULL, i,
+                            fallback_trigger);
+        }
+
+        wait_for_domain_deaths(deathws, nb_domain - 1 /* not dom 0 */);
+        libxl_dominfo_list_free(dominfo, nb_domain);
+    } else {
+        libxl_evgen_domain_death *deathw = NULL;
+        uint32_t domid = find_domain(argv[optind]);
+
+        shutdown_domain(domid, wait_for_it ? &deathw : NULL, 0,
+                        fallback_trigger);
+
+        if (wait_for_it)
+            wait_for_domain_deaths(&deathw, 1);
+    }
+
+
     return 0;
 }
 
diff -r 65e301c71ca4 -r 2329dca4ef44 tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c	Mon Oct 15 09:43:10 2012 +0100
+++ b/tools/libxl/xl_cmdtable.c	Thu Sep 06 21:41:27 2012 +0200
@@ -60,11 +60,12 @@ struct cmd_spec cmd_table[] = {
     { "shutdown",
       &main_shutdown, 0, 1,
       "Issue a shutdown signal to a domain",
-      "[options] <Domain>",
+      "[options] <-a|Domain>",
+      "-a, --all               Shutdown all guest domains.\n"
       "-h                      Print this help.\n"
       "-F                      Fallback to ACPI power event for HVM guests with\n"
       "                        no PV drivers.\n"
-      "-w, --wait              Wait for guest to shutdown.\n"
+      "-w, --wait              Wait for guest(s) to shutdown.\n"
     },
     { "reboot",
       &main_reboot, 0, 1,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 10:10:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 10:10:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNhcV-0000Qg-Ia; Mon, 15 Oct 2012 10:09:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TNhcU-0000Q3-25
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 10:09:58 +0000
Received: from [85.158.137.99:18925] by server-12.bemta-3.messagelabs.com id
	0F/35-27853-5F0EB705; Mon, 15 Oct 2012 10:09:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1350295794!21576414!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYzNjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5071 invoked from network); 15 Oct 2012 10:09:56 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 10:09:56 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="41199649"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 10:09:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 06:09:50 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1TNhcM-0002h0-5l;
	Mon, 15 Oct 2012 11:09:50 +0100
MIME-Version: 1.0
X-Mercurial-Node: 2329dca4ef449979b1403c4bb002fcb70c578b35
Message-ID: <2329dca4ef449979b140.1350295791@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1350295789@cosworth.uk.xensource.com>
References: <patchbomb.1350295789@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 15 Oct 2012 11:09:51 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com, linux@eikelenboom.it
Subject: [Xen-devel] [PATCH 2 of 5] xl: Introduce xl shutdown --all support
 for xm compatibility
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Sander Eikelenboom <linux@eikelenboom.it>
# Date 1346960487 -7200
# Node ID 2329dca4ef449979b1403c4bb002fcb70c578b35
# Parent  65e301c71ca41af8cf0aaea653cd9e8d08bca2f7
xl: Introduce xl shutdown --all support for xm compatibility

Based on a patch by Sander Eikelenboom

Signed-off-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>


---

Changed since v3: (ijc)
  * Rebased. -w already implemented.
  * Shutdown domains in //.

Changed since v2:
  * fix error occuring when using both -a and -w options
    * Due to mixing local and global domid variable


Changed since v1:
  * address review comments.
    * Change shutdown_domain to take domid instead of domname
    * Docs: Make it more clear -a only shuts down GUEST domains

diff -r 65e301c71ca4 -r 2329dca4ef44 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Mon Oct 15 09:43:10 2012 +0100
+++ b/docs/man/xl.pod.1	Thu Sep 06 21:41:27 2012 +0200
@@ -527,7 +527,7 @@ List specifically for that domain. Other
 
 =back
 
-=item B<shutdown> [I<OPTIONS>] I<domain-id>
+=item B<shutdown> [I<OPTIONS>] I<-a|domain-id>
 
 Gracefully shuts down a domain.  This coordinates with the domain OS
 to perform graceful shutdown, so there is no guarantee that it will
@@ -550,6 +550,11 @@ B<OPTIONS>
 
 =over 4
 
+=item B<-a>, B<--all>
+
+Shutdown all guest domains.  Often used when doing a complete shutdown
+of a Xen system.
+
 =item B<-w>, B<--wait>
 
 Wait for the domain to complete shutdown before returning.
diff -r 65e301c71ca4 -r 2329dca4ef44 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Oct 15 09:43:10 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Thu Sep 06 21:41:27 2012 +0200
@@ -2713,12 +2713,46 @@ static void destroy_domain(uint32_t domi
     if (rc) { fprintf(stderr,"destroy failed (rc=%d)\n",rc); exit(-1); }
 }
 
-static void shutdown_domain(uint32_t domid, int wait_for_it,
+static void wait_for_domain_deaths(libxl_evgen_domain_death **deathws, int nr)
+{
+    int rc, count = 0;
+    LOG("Waiting for %d domains to shutdown", nr);
+    while(1 && count < nr) {
+        libxl_event *event;
+        rc = libxl_event_wait(ctx, &event, LIBXL_EVENTMASK_ALL, 0,0);
+        if (rc) {
+            LOG("Failed to get event, quitting (rc=%d)", rc);
+            exit(-1);
+        }
+
+        switch (event->type) {
+        case LIBXL_EVENT_TYPE_DOMAIN_DEATH:
+            LOG("Domain %d has been destroyed", event->domid);
+            libxl_evdisable_domain_death(ctx, deathws[event->for_user]);
+            count++;
+            break;
+        case LIBXL_EVENT_TYPE_DOMAIN_SHUTDOWN:
+            LOG("Domain %d has been shut down, reason code %d",
+                event->domid, event->u.domain_shutdown.shutdown_reason);
+            libxl_evdisable_domain_death(ctx, deathws[event->for_user]);
+            count++;
+            break;
+        default:
+            LOG("Unexpected event type %d", event->type);
+            break;
+        }
+        libxl_event_free(ctx, event);
+    }
+}
+
+static void shutdown_domain(uint32_t domid,
+                            libxl_evgen_domain_death **deathw,
+                            libxl_ev_user for_user,
                             int fallback_trigger)
 {
     int rc;
-    libxl_event *event;
-
+
+    fprintf(stderr, "Shutting down domain %d\n", domid);
     rc=libxl_domain_shutdown(ctx, domid);
     if (rc == ERROR_NOPARAVIRT) {
         if (fallback_trigger) {
@@ -2731,44 +2765,19 @@ static void shutdown_domain(uint32_t dom
             fprintf(stderr, "Use \"-F\" to fallback to ACPI power event.\n");
         }
     }
+
     if (rc) {
         fprintf(stderr,"shutdown failed (rc=%d)\n",rc);exit(-1);
     }
 
-    if (wait_for_it) {
-        libxl_evgen_domain_death *deathw;
-
-        rc = libxl_evenable_domain_death(ctx, domid, 0, &deathw);
+    if (deathw) {
+        rc = libxl_evenable_domain_death(ctx, domid, for_user, deathw);
         if (rc) {
             fprintf(stderr,"wait for death failed (evgen, rc=%d)\n",rc);
             exit(-1);
         }
-
-        for (;;) {
-            rc = domain_wait_event(domid, &event);
-            if (rc) exit(-1);
-
-            switch (event->type) {
-
-            case LIBXL_EVENT_TYPE_DOMAIN_DEATH:
-                LOG("Domain %d has been destroyed", domid);
-                goto done;
-
-            case LIBXL_EVENT_TYPE_DOMAIN_SHUTDOWN:
-                LOG("Domain %d has been shut down, reason code %d %x", domid,
-                    event->u.domain_shutdown.shutdown_reason,
-                    event->u.domain_shutdown.shutdown_reason);
-                goto done;
-
-            default:
-                LOG("Unexpected event type %d", event->type);
-                break;
-            }
-            libxl_event_free(ctx, event);
-        }
-    done:
-        libxl_event_free(ctx, event);
-        libxl_evdisable_domain_death(ctx, deathw);
+        printf("Waiting for domain %d death %p %"PRIx64"\n",
+               domid, *deathw, for_user);
     }
 }
 
@@ -3706,18 +3715,21 @@ int main_destroy(int argc, char **argv)
 
 int main_shutdown(int argc, char **argv)
 {
-    int opt;
-    int wait_for_it = 0;
+    int opt, i, nb_domain;
+    int wait_for_it = 0, all =0;
     int fallback_trigger = 0;
     static struct option long_options[] = {
+        {"all", 0, 0, 'a'},
         {"wait", 0, 0, 'w'},
         {0, 0, 0, 0}
     };
 
-    while ((opt = getopt_long(argc, argv, "wF", long_options, NULL)) != -1) {
+    while ((opt = getopt_long(argc, argv, "awF", long_options, NULL)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
+        case 'a':
+            all = 1;
         case 'w':
             wait_for_it = 1;
             break;
@@ -3727,7 +3739,44 @@ int main_shutdown(int argc, char **argv)
         }
     }
 
-    shutdown_domain(find_domain(argv[optind]), wait_for_it, fallback_trigger);
+    if (!argv[optind] && !all) {
+        fprintf(stderr, "You must specify -a or a domain id.\n\n");
+        return opt;
+    }
+
+    if (all) {
+        libxl_dominfo *dominfo;
+        libxl_evgen_domain_death **deathws = NULL;
+        if (!(dominfo = libxl_list_domain(ctx, &nb_domain))) {
+            fprintf(stderr, "libxl_list_domain failed.\n");
+            return -1;
+        }
+
+        if (wait_for_it)
+            deathws = calloc(nb_domain, sizeof(deathws));
+
+        for (i = 0; i<nb_domain; i++) {
+            if (dominfo[i].domid == 0)
+                continue;
+            shutdown_domain(dominfo[i].domid,
+                            deathws ? &deathws[i] : NULL, i,
+                            fallback_trigger);
+        }
+
+        wait_for_domain_deaths(deathws, nb_domain - 1 /* not dom 0 */);
+        libxl_dominfo_list_free(dominfo, nb_domain);
+    } else {
+        libxl_evgen_domain_death *deathw = NULL;
+        uint32_t domid = find_domain(argv[optind]);
+
+        shutdown_domain(domid, wait_for_it ? &deathw : NULL, 0,
+                        fallback_trigger);
+
+        if (wait_for_it)
+            wait_for_domain_deaths(&deathw, 1);
+    }
+
+
     return 0;
 }
 
diff -r 65e301c71ca4 -r 2329dca4ef44 tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c	Mon Oct 15 09:43:10 2012 +0100
+++ b/tools/libxl/xl_cmdtable.c	Thu Sep 06 21:41:27 2012 +0200
@@ -60,11 +60,12 @@ struct cmd_spec cmd_table[] = {
     { "shutdown",
       &main_shutdown, 0, 1,
       "Issue a shutdown signal to a domain",
-      "[options] <Domain>",
+      "[options] <-a|Domain>",
+      "-a, --all               Shutdown all guest domains.\n"
       "-h                      Print this help.\n"
       "-F                      Fallback to ACPI power event for HVM guests with\n"
       "                        no PV drivers.\n"
-      "-w, --wait              Wait for guest to shutdown.\n"
+      "-w, --wait              Wait for guest(s) to shutdown.\n"
     },
     { "reboot",
       &main_reboot, 0, 1,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 10:10:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 10:10:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNhcU-0000Q9-KM; Mon, 15 Oct 2012 10:09:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TNhcS-0000Pr-Kk
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 10:09:57 +0000
Received: from [85.158.137.99:8162] by server-10.bemta-3.messagelabs.com id
	73/AB-27386-3F0EB705; Mon, 15 Oct 2012 10:09:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1350295792!21494822!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYzNjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3890 invoked from network); 15 Oct 2012 10:09:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 10:09:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="41199646"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 10:09:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 06:09:50 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1TNhcM-0002h0-5A;
	Mon, 15 Oct 2012 11:09:50 +0100
MIME-Version: 1.0
X-Mercurial-Node: 65e301c71ca41af8cf0aaea653cd9e8d08bca2f7
Message-ID: <65e301c71ca41af8cf0a.1350295790@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1350295789@cosworth.uk.xensource.com>
References: <patchbomb.1350295789@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 15 Oct 2012 11:09:50 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com, linux@eikelenboom.it
Subject: [Xen-devel] [PATCH 1 of 5] libxl: propagate user supplied values
 into event for_user field
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Ian Campbell <ijc@hellion.org.uk>
# Date 1350290590 -3600
# Node ID 65e301c71ca41af8cf0aaea653cd9e8d08bca2f7
# Parent  de18f0577d3ff521822dd3760fbfe5e08a771f9d
libxl: propagate user supplied values into event for_user field.

This was ommited in the majority of cases. Add as a parameter to
libxl__event_new and the NEW_EVENT wrapper to help prevent it being
forgotten in the future.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
This should be backported to 4.2.

diff -r de18f0577d3f -r 65e301c71ca4 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Fri Oct 12 15:58:22 2012 +0100
+++ b/tools/libxl/libxl.c	Mon Oct 15 09:43:10 2012 +0100
@@ -955,7 +955,7 @@ static void domain_death_occurred(libxl_
     libxl_evgen_domain_death *evg_next = LIBXL_TAILQ_NEXT(evg, entry);
     *evg_upd = evg_next;
 
-    libxl_event *ev = NEW_EVENT(egc, DOMAIN_DEATH, evg->domid);
+    libxl_event *ev = NEW_EVENT(egc, DOMAIN_DEATH, evg->domid, evg->user);
 
     libxl__event_occurred(egc, ev);
 
@@ -1041,8 +1041,9 @@ static void domain_death_xswatch_callbac
 
             if (!evg->shutdown_reported &&
                 (got->flags & XEN_DOMINF_shutdown)) {
-                libxl_event *ev = NEW_EVENT(egc, DOMAIN_SHUTDOWN, got->domain);
-                
+                libxl_event *ev = NEW_EVENT(egc, DOMAIN_SHUTDOWN,
+                                            got->domain, evg->user);
+
                 LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, " shutdown reporting");
 
                 ev->u.domain_shutdown.shutdown_reason =
@@ -1141,7 +1142,7 @@ static void disk_eject_xswatch_callback(
         return;
     }
 
-    libxl_event *ev = NEW_EVENT(egc, DISK_EJECT, evg->domid);
+    libxl_event *ev = NEW_EVENT(egc, DISK_EJECT, evg->domid, evg->user);
     libxl_device_disk *disk = &ev->u.disk_eject.disk;
     
     backend = libxl__xs_read(gc, XBT_NULL,
diff -r de18f0577d3f -r 65e301c71ca4 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Fri Oct 12 15:58:22 2012 +0100
+++ b/tools/libxl/libxl_create.c	Mon Oct 15 09:43:10 2012 +0100
@@ -705,7 +705,8 @@ static void domcreate_console_available(
                                         libxl__domain_create_state *dcs) {
     libxl__ao_progress_report(egc, dcs->ao, &dcs->aop_console_how,
                               NEW_EVENT(egc, DOMAIN_CREATE_CONSOLE_AVAILABLE,
-                                        dcs->guest_domid));
+                                        dcs->guest_domid,
+                                        dcs->aop_console_how.for_event));
 }
 
 static void domcreate_bootloader_done(libxl__egc *egc,
diff -r de18f0577d3f -r 65e301c71ca4 tools/libxl/libxl_event.c
--- a/tools/libxl/libxl_event.c	Fri Oct 12 15:58:22 2012 +0100
+++ b/tools/libxl/libxl_event.c	Mon Oct 15 09:43:10 2012 +0100
@@ -1157,7 +1157,8 @@ void libxl_event_free(libxl_ctx *ctx, li
 }
 
 libxl_event *libxl__event_new(libxl__egc *egc,
-                              libxl_event_type type, uint32_t domid)
+                              libxl_event_type type, uint32_t domid,
+                              libxl_ev_user for_user)
 {
     EGC_GC;
     libxl_event *ev;
@@ -1168,6 +1169,7 @@ libxl_event *libxl__event_new(libxl__egc
     libxl_event_init_type(ev, type);
 
     ev->domid = domid;
+    ev->for_user = for_user;
 
     return ev;
 }
@@ -1528,9 +1530,8 @@ void libxl__ao_complete_check_progress_r
         LIBXL_TAILQ_INSERT_TAIL(&egc->aos_for_callback, ao, entry_for_callback);
     } else {
         libxl_event *ev;
-        ev = NEW_EVENT(egc, OPERATION_COMPLETE, ao->domid);
+        ev = NEW_EVENT(egc, OPERATION_COMPLETE, ao->domid, ao->how.u.for_event);
         if (ev) {
-            ev->for_user = ao->how.u.for_event;
             ev->u.operation_complete.rc = ao->rc;
             libxl__event_occurred(egc, ev);
         }
@@ -1662,7 +1663,6 @@ void libxl__ao_progress_report(libxl__eg
         const libxl_asyncprogress_how *how, libxl_event *ev)
 {
     AO_GC;
-    ev->for_user = how->for_event;
     if (how->callback == dummy_asyncprogress_callback_ignore) {
         LOG(DEBUG,"ao %p: progress report: ignored",ao);
         libxl_event_free(CTX,ev);
diff -r de18f0577d3f -r 65e301c71ca4 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Fri Oct 12 15:58:22 2012 +0100
+++ b/tools/libxl/libxl_internal.h	Mon Oct 15 09:43:10 2012 +0100
@@ -783,13 +783,14 @@ _hidden void libxl__event_occurred(libxl
    * event should be suitable for passing to libxl_event_free. */
 
 _hidden libxl_event *libxl__event_new(libxl__egc*, libxl_event_type,
-                                      uint32_t domid);
+                                      uint32_t domid,
+                                      libxl_ev_user for_user);
   /* Convenience function.
    * Allocates a new libxl_event, fills in domid and type.
    * Cannot fail. */
 
-#define NEW_EVENT(egc, type, domid)                              \
-    libxl__event_new((egc), LIBXL_EVENT_TYPE_##type, (domid))
+#define NEW_EVENT(egc, type, domid, user)                        \
+    libxl__event_new((egc), LIBXL_EVENT_TYPE_##type, (domid), (user))
     /* Convenience macro. */
 
 /*

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 10:10:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 10:10:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNhcU-0000Q9-KM; Mon, 15 Oct 2012 10:09:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TNhcS-0000Pr-Kk
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 10:09:57 +0000
Received: from [85.158.137.99:8162] by server-10.bemta-3.messagelabs.com id
	73/AB-27386-3F0EB705; Mon, 15 Oct 2012 10:09:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1350295792!21494822!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYzNjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3890 invoked from network); 15 Oct 2012 10:09:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 10:09:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="41199646"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 10:09:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 06:09:50 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1TNhcM-0002h0-5A;
	Mon, 15 Oct 2012 11:09:50 +0100
MIME-Version: 1.0
X-Mercurial-Node: 65e301c71ca41af8cf0aaea653cd9e8d08bca2f7
Message-ID: <65e301c71ca41af8cf0a.1350295790@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1350295789@cosworth.uk.xensource.com>
References: <patchbomb.1350295789@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 15 Oct 2012 11:09:50 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com, linux@eikelenboom.it
Subject: [Xen-devel] [PATCH 1 of 5] libxl: propagate user supplied values
 into event for_user field
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Ian Campbell <ijc@hellion.org.uk>
# Date 1350290590 -3600
# Node ID 65e301c71ca41af8cf0aaea653cd9e8d08bca2f7
# Parent  de18f0577d3ff521822dd3760fbfe5e08a771f9d
libxl: propagate user supplied values into event for_user field.

This was ommited in the majority of cases. Add as a parameter to
libxl__event_new and the NEW_EVENT wrapper to help prevent it being
forgotten in the future.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
This should be backported to 4.2.

diff -r de18f0577d3f -r 65e301c71ca4 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Fri Oct 12 15:58:22 2012 +0100
+++ b/tools/libxl/libxl.c	Mon Oct 15 09:43:10 2012 +0100
@@ -955,7 +955,7 @@ static void domain_death_occurred(libxl_
     libxl_evgen_domain_death *evg_next = LIBXL_TAILQ_NEXT(evg, entry);
     *evg_upd = evg_next;
 
-    libxl_event *ev = NEW_EVENT(egc, DOMAIN_DEATH, evg->domid);
+    libxl_event *ev = NEW_EVENT(egc, DOMAIN_DEATH, evg->domid, evg->user);
 
     libxl__event_occurred(egc, ev);
 
@@ -1041,8 +1041,9 @@ static void domain_death_xswatch_callbac
 
             if (!evg->shutdown_reported &&
                 (got->flags & XEN_DOMINF_shutdown)) {
-                libxl_event *ev = NEW_EVENT(egc, DOMAIN_SHUTDOWN, got->domain);
-                
+                libxl_event *ev = NEW_EVENT(egc, DOMAIN_SHUTDOWN,
+                                            got->domain, evg->user);
+
                 LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, " shutdown reporting");
 
                 ev->u.domain_shutdown.shutdown_reason =
@@ -1141,7 +1142,7 @@ static void disk_eject_xswatch_callback(
         return;
     }
 
-    libxl_event *ev = NEW_EVENT(egc, DISK_EJECT, evg->domid);
+    libxl_event *ev = NEW_EVENT(egc, DISK_EJECT, evg->domid, evg->user);
     libxl_device_disk *disk = &ev->u.disk_eject.disk;
     
     backend = libxl__xs_read(gc, XBT_NULL,
diff -r de18f0577d3f -r 65e301c71ca4 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Fri Oct 12 15:58:22 2012 +0100
+++ b/tools/libxl/libxl_create.c	Mon Oct 15 09:43:10 2012 +0100
@@ -705,7 +705,8 @@ static void domcreate_console_available(
                                         libxl__domain_create_state *dcs) {
     libxl__ao_progress_report(egc, dcs->ao, &dcs->aop_console_how,
                               NEW_EVENT(egc, DOMAIN_CREATE_CONSOLE_AVAILABLE,
-                                        dcs->guest_domid));
+                                        dcs->guest_domid,
+                                        dcs->aop_console_how.for_event));
 }
 
 static void domcreate_bootloader_done(libxl__egc *egc,
diff -r de18f0577d3f -r 65e301c71ca4 tools/libxl/libxl_event.c
--- a/tools/libxl/libxl_event.c	Fri Oct 12 15:58:22 2012 +0100
+++ b/tools/libxl/libxl_event.c	Mon Oct 15 09:43:10 2012 +0100
@@ -1157,7 +1157,8 @@ void libxl_event_free(libxl_ctx *ctx, li
 }
 
 libxl_event *libxl__event_new(libxl__egc *egc,
-                              libxl_event_type type, uint32_t domid)
+                              libxl_event_type type, uint32_t domid,
+                              libxl_ev_user for_user)
 {
     EGC_GC;
     libxl_event *ev;
@@ -1168,6 +1169,7 @@ libxl_event *libxl__event_new(libxl__egc
     libxl_event_init_type(ev, type);
 
     ev->domid = domid;
+    ev->for_user = for_user;
 
     return ev;
 }
@@ -1528,9 +1530,8 @@ void libxl__ao_complete_check_progress_r
         LIBXL_TAILQ_INSERT_TAIL(&egc->aos_for_callback, ao, entry_for_callback);
     } else {
         libxl_event *ev;
-        ev = NEW_EVENT(egc, OPERATION_COMPLETE, ao->domid);
+        ev = NEW_EVENT(egc, OPERATION_COMPLETE, ao->domid, ao->how.u.for_event);
         if (ev) {
-            ev->for_user = ao->how.u.for_event;
             ev->u.operation_complete.rc = ao->rc;
             libxl__event_occurred(egc, ev);
         }
@@ -1662,7 +1663,6 @@ void libxl__ao_progress_report(libxl__eg
         const libxl_asyncprogress_how *how, libxl_event *ev)
 {
     AO_GC;
-    ev->for_user = how->for_event;
     if (how->callback == dummy_asyncprogress_callback_ignore) {
         LOG(DEBUG,"ao %p: progress report: ignored",ao);
         libxl_event_free(CTX,ev);
diff -r de18f0577d3f -r 65e301c71ca4 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Fri Oct 12 15:58:22 2012 +0100
+++ b/tools/libxl/libxl_internal.h	Mon Oct 15 09:43:10 2012 +0100
@@ -783,13 +783,14 @@ _hidden void libxl__event_occurred(libxl
    * event should be suitable for passing to libxl_event_free. */
 
 _hidden libxl_event *libxl__event_new(libxl__egc*, libxl_event_type,
-                                      uint32_t domid);
+                                      uint32_t domid,
+                                      libxl_ev_user for_user);
   /* Convenience function.
    * Allocates a new libxl_event, fills in domid and type.
    * Cannot fail. */
 
-#define NEW_EVENT(egc, type, domid)                              \
-    libxl__event_new((egc), LIBXL_EVENT_TYPE_##type, (domid))
+#define NEW_EVENT(egc, type, domid, user)                        \
+    libxl__event_new((egc), LIBXL_EVENT_TYPE_##type, (domid), (user))
     /* Convenience macro. */
 
 /*

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 10:10:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 10:10:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNhcX-0000R7-1o; Mon, 15 Oct 2012 10:10:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TNhcV-0000QE-53
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 10:09:59 +0000
Received: from [85.158.137.99:60123] by server-1.bemta-3.messagelabs.com id
	74/C9-31728-6F0EB705; Mon, 15 Oct 2012 10:09:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1350295792!21494822!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYzNjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3962 invoked from network); 15 Oct 2012 10:09:56 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 10:09:56 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="41199651"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 10:09:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 06:09:50 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1TNhcM-0002h0-7S;
	Mon, 15 Oct 2012 11:09:50 +0100
MIME-Version: 1.0
X-Mercurial-Node: 22688187afa84747de9b820cb29addbd65385042
Message-ID: <22688187afa84747de9b.1350295794@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1350295789@cosworth.uk.xensource.com>
References: <patchbomb.1350295789@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 15 Oct 2012 11:09:54 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com, linux@eikelenboom.it
Subject: [Xen-devel] [PATCH 5 of 5] xl: Introduce helper macro for option
	parsing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Ian Campbell <ijc@hellion.org.uk>
# Date 1350295720 -3600
# Node ID 22688187afa84747de9b820cb29addbd65385042
# Parent  bbb839ceb966cc265e5d2ca530ba0f2bf823176a
xl: Introduce helper macro for option parsing.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r bbb839ceb966 -r 22688187afa8 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Oct 15 11:08:39 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Mon Oct 15 11:08:40 2012 +0100
@@ -2281,6 +2281,11 @@ static int def_getopt(int argc, char * c
     return -1;
 }
 
+#define FOREACH_OPT(_opt, _opts, _lopts, _help, _req)           \
+    while (((_opt) = def_getopt(argc, argv, (_opts), (_lopts),  \
+                                (_help), (_req))) != -1)        \
+        switch (opt)
+
 static int set_memory_max(uint32_t domid, const char *mem)
 {
     int64_t memorykb;
@@ -2304,8 +2309,10 @@ int main_memmax(int argc, char **argv)
     char *mem;
     int rc;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "mem-max", 2)) != -1)
+    FOREACH_OPT(opt, "", NULL, "mem-max", 2) {
+    case 0: case 2:
         return opt;
+    }
 
     domid = find_domain(argv[optind]);
     mem = argv[optind + 1];
@@ -2338,8 +2345,10 @@ int main_memset(int argc, char **argv)
     int opt = 0;
     const char *mem;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "mem-set", 2)) != -1)
+    FOREACH_OPT(opt, "", NULL, "mem-set", 2) {
+    case 0: case 2:
         return opt;
+    }
 
     domid = find_domain(argv[optind]);
     mem = argv[optind + 1];
@@ -2377,8 +2386,10 @@ int main_cd_eject(int argc, char **argv)
     int opt = 0;
     const char *virtdev;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "cd-eject", 2)) != -1)
-        return opt;
+    FOREACH_OPT(opt, "", NULL, "cd-eject", 2) {
+        case 0: case 2:
+            return opt;
+    }
 
     domid = find_domain(argv[optind]);
     virtdev = argv[optind + 1];
@@ -2394,8 +2405,10 @@ int main_cd_insert(int argc, char **argv
     const char *virtdev;
     char *file = NULL; /* modified by cd_insert tokenising it */
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "cd-insert", 3)) != -1)
+    FOREACH_OPT(opt, "", NULL, "cd-insert", 3) {
+    case 0: case 2:
         return opt;
+    }
 
     domid = find_domain(argv[optind]);
     virtdev = argv[optind + 1];
@@ -2411,24 +2424,22 @@ int main_console(int argc, char **argv)
     int opt = 0, num = 0;
     libxl_console_type type = 0;
 
-    while ((opt = def_getopt(argc, argv, "n:t:", NULL, "console", 1)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        case 't':
-            if (!strcmp(optarg, "pv"))
-                type = LIBXL_CONSOLE_TYPE_PV;
-            else if (!strcmp(optarg, "serial"))
-                type = LIBXL_CONSOLE_TYPE_SERIAL;
-            else {
-                fprintf(stderr, "console type supported are: pv, serial\n");
-                return 2;
-            }
-            break;
-        case 'n':
-            num = atoi(optarg);
-            break;
+    FOREACH_OPT(opt, "n:t:", NULL, "console", 1) {
+    case 0: case 2:
+        return opt;
+    case 't':
+        if (!strcmp(optarg, "pv"))
+            type = LIBXL_CONSOLE_TYPE_PV;
+        else if (!strcmp(optarg, "serial"))
+            type = LIBXL_CONSOLE_TYPE_SERIAL;
+        else {
+            fprintf(stderr, "console type supported are: pv, serial\n");
+            return 2;
         }
+        break;
+    case 'n':
+        num = atoi(optarg);
+        break;
     }
 
     domid = find_domain(argv[optind]);
@@ -2451,14 +2462,12 @@ int main_vncviewer(int argc, char **argv
     uint32_t domid;
     int opt, autopass = 0;
 
-    while ((opt = def_getopt(argc, argv, "ah", opts, "vncviewer", 1)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        case 'a':
-            autopass = 1;
-            break;
-        }
+    FOREACH_OPT(opt, "ah", opts, "vncviewer", 1) {
+    case 0: case 2:
+        return opt;
+    case 'a':
+        autopass = 1;
+        break;
     }
 
     domid = find_domain(argv[optind]);
@@ -2491,8 +2500,10 @@ int main_pcilist(int argc, char **argv)
     uint32_t domid;
     int opt;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "pci-list", 1)) != -1)
+    FOREACH_OPT(opt, "", NULL, "pci-list", 1) {
+    case 0: case 2:
         return opt;
+    }
 
     domid = find_domain(argv[optind]);
 
@@ -2530,14 +2541,12 @@ int main_pcidetach(int argc, char **argv
     int force = 0;
     const char *bdf = NULL;
 
-    while ((opt = def_getopt(argc, argv, "f", NULL, "pci-detach", 2)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        case 'f':
-            force = 1;
-            break;
-        }
+    FOREACH_OPT(opt, "f", NULL, "pci-detach", 2) {
+    case 0: case 2:
+        return opt;
+    case 'f':
+        force = 1;
+        break;
     }
 
     domid = find_domain(argv[optind]);
@@ -2572,8 +2581,10 @@ int main_pciattach(int argc, char **argv
     int opt;
     const char *bdf = NULL, *vs = NULL;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "pci-attach", 2)) != -1)
+    FOREACH_OPT(opt, "", NULL, "pci-attach", 2) {
+    case 0: case 2:
         return opt;
+    }
 
     domid = find_domain(argv[optind]);
     bdf = argv[optind + 1];
@@ -2606,8 +2617,10 @@ int main_pciassignable_list(int argc, ch
 {
     int opt;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "pci-assignable-list", 0)) != -1)
+    FOREACH_OPT(opt, "", NULL, "pci-assignable-list", 0) {
+    case 0: case 2:
         return opt;
+    }
 
     pciassignable_list();
     return 0;
@@ -2638,11 +2651,9 @@ int main_pciassignable_add(int argc, cha
     int opt;
     const char *bdf = NULL;
 
-    while ((opt = def_getopt(argc, argv, "", NULL, "pci-assignable-add", 1)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        }
+    FOREACH_OPT(opt, "", NULL, "pci-assignable-add", 1) {
+    case 0: case 2:
+        return opt;
     }
 
     bdf = argv[optind];
@@ -2677,14 +2688,12 @@ int main_pciassignable_remove(int argc, 
     const char *bdf = NULL;
     int rebind = 0;
 
-    while ((opt = def_getopt(argc, argv, "r", NULL, "pci-assignable-remove", 1)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        case 'r':
-            rebind=1;
-            break;
-        }
+    FOREACH_OPT(opt, "r", NULL, "pci-assignable-remove", 1) {
+    case 0: case 2:
+        return opt;
+    case 'r':
+        rebind=1;
+        break;
     }
 
     bdf = argv[optind];
@@ -3495,34 +3504,31 @@ int main_restore(int argc, char **argv)
         {0, 0, 0, 0}
     };
 
-    while ((opt = def_getopt(argc, argv, "FhcpdeVA",
-                             opts, "restore", 1)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        case 'c':
-            console_autoconnect = 1;
-            break;
-        case 'p':
-            paused = 1;
-            break;
-        case 'd':
-            debug = 1;
-            break;
-        case 'F':
-            daemonize = 0;
-            break;
-        case 'e':
-            daemonize = 0;
-            monitor = 0;
-            break;
-        case 'V':
-            vnc = 1;
-            break;
-        case 'A':
-            vnc = vncautopass = 1;
-            break;
-        }
+    FOREACH_OPT(opt, "FhcpdeVA", opts, "restore", 1) {
+    case 0: case 2:
+        return opt;
+    case 'c':
+        console_autoconnect = 1;
+        break;
+    case 'p':
+        paused = 1;
+        break;
+    case 'd':
+        debug = 1;
+        break;
+    case 'F':
+        daemonize = 0;
+        break;
+    case 'e':
+        daemonize = 0;
+        monitor = 0;
+        break;
+    case 'V':
+        vnc = 1;
+        break;
+    case 'A':
+        vnc = vncautopass = 1;
+        break;
     }
 
     if (argc-optind == 1) {
@@ -3559,24 +3565,22 @@ int main_migrate_receive(int argc, char 
     int debug = 0, daemonize = 1, monitor = 1, remus = 0;
     int opt;
 
-    while ((opt = def_getopt(argc, argv, "Fedr", NULL, "migrate-receive", 0)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        case 'F':
-            daemonize = 0;
-            break;
-        case 'e':
-            daemonize = 0;
-            monitor = 0;
-            break;
-        case 'd':
-            debug = 1;
-            break;
-        case 'r':
-            remus = 1;
-            break;
-        }
+    FOREACH_OPT(opt, "Fedr", NULL, "migrate-receive", 0) {
+    case 0: case 2:
+        return opt;
+    case 'F':
+        daemonize = 0;
+        break;
+    case 'e':
+        daemonize = 0;
+        monitor = 0;
+        break;
+    case 'd':
+        debug = 1;
+        break;
+    case 'r':
+        remus = 1;
+        break;
     }
 
     if (argc-optind != 0) {
@@ -3598,14 +3602,12 @@ int main_save(int argc, char **argv)
     int checkpoint = 0;
     int opt;
 
-    while ((opt = def_getopt(argc, argv, "c", NULL, "save", 2)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        case 'c':
-            checkpoint = 1;
-            break;
-        }
+    FOREACH_OPT(opt, "c", NULL, "save", 2) {
+    case 0: case 2:
+        return opt;
+    case 'c':
+        checkpoint = 1;
+        break;
     }
 
     if (argc-optind > 3) {
@@ -3631,27 +3633,25 @@ int main_migrate(int argc, char **argv)
     char *host;
     int opt, daemonize = 1, monitor = 1, debug = 0;
 
-    while ((opt = def_getopt(argc, argv, "FC:s:ed", NULL, "migrate", 2)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        case 'C':
-            config_filename = optarg;
-            break;
-        case 's':
-            ssh_command = optarg;
-            break;
-        case 'F':
-            daemonize = 0;
-            break;
-        case 'e':
-            daemonize = 0;
-            monitor = 0;
-            break;
-        case 'd':
-            debug = 1;
-            break;
-        }
+    FOREACH_OPT(opt, "FC:s:ed", NULL, "migrate", 2) {
+    case 0: case 2:
+        return opt;
+    case 'C':
+        config_filename = optarg;
+        break;
+    case 's':
+        ssh_command = optarg;
+        break;
+    case 'F':
+        daemonize = 0;
+        break;
+    case 'e':
+        daemonize = 0;
+        monitor = 0;
+        break;
+    case 'd':
+        debug = 1;
+        break;
     }
 
     domid = find_domain(argv[optind]);
@@ -3675,8 +3675,10 @@ int main_dump_core(int argc, char **argv
 {
     int opt;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "dump-core", 2)) != -1)
+    FOREACH_OPT(opt, "", NULL, "dump-core", 2) {
+    case 0: case 2:
         return opt;
+    }
 
     core_dump_domain(find_domain(argv[optind]), argv[optind + 1]);
     return 0;
@@ -3686,8 +3688,10 @@ int main_pause(int argc, char **argv)
 {
     int opt;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "pause", 1)) != -1)
+    FOREACH_OPT(opt, "", NULL, "pause", 1) {
+    case 0: case 2:
         return opt;
+    }
 
     pause_domain(find_domain(argv[optind]));
 
@@ -3698,8 +3702,10 @@ int main_unpause(int argc, char **argv)
 {
     int opt;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "unpause", 1)) != -1)
+    FOREACH_OPT(opt, "", NULL, "unpause", 1) {
+    case 0: case 2:
         return opt;
+    }
 
     unpause_domain(find_domain(argv[optind]));
 
@@ -3710,8 +3716,10 @@ int main_destroy(int argc, char **argv)
 {
     int opt;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "destroy", 1)) != -1)
+    FOREACH_OPT(opt, "", NULL, "destroy", 1) {
+    case 0: case 2:
         return opt;
+    }
 
     destroy_domain(find_domain(argv[optind]));
     return 0;
@@ -3815,23 +3823,18 @@ int main_list(int argc, char **argv)
     libxl_dominfo *info, *info_free=0;
     int nb_domain, rc;
 
-    while ((opt = def_getopt(argc, argv, "lvhZ", opts, "list", 0)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        case 'l':
-            details = 1;
-            break;
-        case 'h':
-            help("list");
-            return 0;
-        case 'v':
-            verbose = 1;
-            break;
-        case 'Z':
-            context = 1;
-            break;
-        }
+    FOREACH_OPT(opt, "lvhZ", opts, "list", 0) {
+    case 0: case 2:
+        return opt;
+    case 'l':
+        details = 1;
+        break;
+    case 'v':
+        verbose = 1;
+        break;
+    case 'Z':
+        context = 1;
+        break;
     }
 
     if (optind >= argc) {
@@ -3877,8 +3880,10 @@ int main_vm_list(int argc, char **argv)
 {
     int opt;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "vm-list", 0)) != -1)
+    FOREACH_OPT(opt, "", NULL, "vm-list", 0) {
+    case 0: case 2:
         return opt;
+    }
 
     list_vm();
     return 0;
@@ -3908,45 +3913,40 @@ int main_create(int argc, char **argv)
         argc--; argv++;
     }
 
-    while ((opt = def_getopt(argc, argv, "Fhnqf:pcdeVA", opts, "create", 0)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        case 'f':
-            filename = optarg;
-            break;
-        case 'p':
-            paused = 1;
-            break;
-        case 'c':
-            console_autoconnect = 1;
-            break;
-        case 'd':
-            debug = 1;
-            break;
-        case 'F':
-            daemonize = 0;
-            break;
-        case 'e':
-            daemonize = 0;
-            monitor = 0;
-            break;
-        case 'h':
-            help("create");
-            return 0;
-        case 'n':
-            dryrun_only = 1;
-            break;
-        case 'q':
-            quiet = 1;
-            break;
-        case 'V':
-            vnc = 1;
-            break;
-        case 'A':
-            vnc = vncautopass = 1;
-            break;
-        }
+    FOREACH_OPT(opt, "Fhnqf:pcdeVA", opts, "create", 0) {
+    case 0: case 2:
+        return opt;
+    case 'f':
+        filename = optarg;
+        break;
+    case 'p':
+        paused = 1;
+        break;
+    case 'c':
+        console_autoconnect = 1;
+        break;
+    case 'd':
+        debug = 1;
+        break;
+    case 'F':
+        daemonize = 0;
+        break;
+    case 'e':
+        daemonize = 0;
+        monitor = 0;
+        break;
+    case 'n':
+        dryrun_only = 1;
+        break;
+    case 'q':
+        quiet = 1;
+        break;
+    case 'V':
+        vnc = 1;
+        break;
+    case 'A':
+        vnc = vncautopass = 1;
+        break;
     }
 
     extra_config[0] = '\0';
@@ -4014,17 +4014,15 @@ int main_config_update(int argc, char **
         argc--; argv++;
     }
 
-    while ((opt = def_getopt(argc, argv, "dhqf:", opts, "config_update", 0)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        case 'd':
-            debug = 1;
-            break;
-        case 'f':
-            filename = optarg;
-            break;
-        }
+    FOREACH_OPT(opt, "dhqf:", opts, "config_update", 0) {
+    case 0: case 2:
+        return opt;
+    case 'd':
+        debug = 1;
+        break;
+    case 'f':
+        filename = optarg;
+        break;
     }
 
     extra_config[0] = '\0';
@@ -4112,8 +4110,11 @@ int main_button_press(int argc, char **a
     fprintf(stderr, "WARNING: \"button-press\" is deprecated. "
             "Please use \"trigger\"\n");
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "button-press", 2)) != -1)
+
+    FOREACH_OPT(opt, "", NULL, "button-press", 2) {
+    case 0: case 2:
         return opt;
+    }
 
     button_press(find_domain(argv[optind]), argv[optind + 1]);
 
@@ -4253,8 +4254,10 @@ int main_vcpulist(int argc, char **argv)
 {
     int opt;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "cpu-list", 0)) != -1)
+    FOREACH_OPT(opt, "", NULL, "cpu-list", 0) {
+    case 0: case 2:
         return opt;
+    }
 
     vcpulist(argc - optind, argv + optind);
     return 0;
@@ -4314,8 +4317,10 @@ int main_vcpupin(int argc, char **argv)
 {
     int opt;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "vcpu-pin", 3)) != -1)
+    FOREACH_OPT(opt, "", NULL, "vcpu-pin", 3) {
+    case 0: case 2:
         return opt;
+    }
 
     vcpupin(find_domain(argv[optind]), argv[optind+1] , argv[optind+2]);
     return 0;
@@ -4350,8 +4355,10 @@ int main_vcpuset(int argc, char **argv)
 {
     int opt;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "vcpu-set", 2)) != -1)
+    FOREACH_OPT(opt, "", NULL, "vcpu-set", 2) {
+    case 0: case 2:
         return opt;
+    }
 
     vcpuset(find_domain(argv[optind]), argv[optind+1]);
     return 0;
@@ -4533,14 +4540,12 @@ int main_info(int argc, char **argv)
     };
     int numa = 0;
 
-    while ((opt = def_getopt(argc, argv, "hn", opts, "info", 0)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        case 'n':
-            numa = 1;
-            break;
-        }
+    FOREACH_OPT(opt, "hn", opts, "info", 0) {
+    case 0: case 2:
+        return opt;
+    case 'n':
+        numa = 1;
+        break;
     }
 
     print_info(numa);
@@ -4574,8 +4579,10 @@ int main_sharing(int argc, char **argv)
     libxl_dominfo *info, *info_free = NULL;
     int nb_domain, rc;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "sharing", 0)) != -1)
+    FOREACH_OPT(opt, "", NULL, "sharing", 0) {
+    case 0: case 2:
         return opt;
+    }
 
     if (optind >= argc) {
         info = libxl_list_domain(ctx, &nb_domain);
@@ -4855,36 +4862,34 @@ int main_sched_credit(int argc, char **a
         {0, 0, 0, 0}
     };
 
-    while ((opt = def_getopt(argc, argv, "d:w:c:p:t:r:hs", opts, "sched-credit", 0)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        case 'd':
-            dom = optarg;
-            break;
-        case 'w':
-            weight = strtol(optarg, NULL, 10);
-            opt_w = 1;
-            break;
-        case 'c':
-            cap = strtol(optarg, NULL, 10);
-            opt_c = 1;
-            break;
-        case 't':
-            tslice = strtol(optarg, NULL, 10);
-            opt_t = 1;
-            break;
-        case 'r':
-            ratelimit = strtol(optarg, NULL, 10);
-            opt_r = 1;
-            break;
-        case 's':
-            opt_s = 1;
-            break;
-        case 'p':
-            cpupool = optarg;
-            break;
-        }
+    FOREACH_OPT(opt, "d:w:c:p:t:r:hs", opts, "sched-credit", 0) {
+    case 0: case 2:
+        return opt;
+    case 'd':
+        dom = optarg;
+        break;
+    case 'w':
+        weight = strtol(optarg, NULL, 10);
+        opt_w = 1;
+        break;
+    case 'c':
+        cap = strtol(optarg, NULL, 10);
+        opt_c = 1;
+        break;
+    case 't':
+        tslice = strtol(optarg, NULL, 10);
+        opt_t = 1;
+        break;
+    case 'r':
+        ratelimit = strtol(optarg, NULL, 10);
+        opt_r = 1;
+        break;
+    case 's':
+        opt_s = 1;
+        break;
+    case 'p':
+        cpupool = optarg;
+        break;
     }
 
     if ((cpupool || opt_s) && (dom || opt_w || opt_c)) {
@@ -4974,21 +4979,19 @@ int main_sched_credit2(int argc, char **
         {0, 0, 0, 0}
     };
 
-    while ((opt = def_getopt(argc, argv, "d:w:p:h", opts, "sched-credit2", 0)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        case 'd':
-            dom = optarg;
-            break;
-        case 'w':
-            weight = strtol(optarg, NULL, 10);
-            opt_w = 1;
-            break;
-        case 'p':
-            cpupool = optarg;
-            break;
-        }
+    FOREACH_OPT(opt, "d:w:p:h", opts, "sched-credit2", 0) {
+    case 0: case 2:
+        return opt;
+    case 'd':
+        dom = optarg;
+        break;
+    case 'w':
+        weight = strtol(optarg, NULL, 10);
+        opt_w = 1;
+        break;
+    case 'p':
+        cpupool = optarg;
+        break;
     }
 
     if (cpupool && (dom || opt_w)) {
@@ -5049,37 +5052,35 @@ int main_sched_sedf(int argc, char **arg
         {0, 0, 0, 0}
     };
 
-    while ((opt = def_getopt(argc, argv, "d:p:s:l:e:w:c:h", opts, "sched-sedf", 0)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        case 'd':
-            dom = optarg;
-            break;
-        case 'p':
-            period = strtol(optarg, NULL, 10);
-            opt_p = 1;
-            break;
-        case 's':
-            slice = strtol(optarg, NULL, 10);
-            opt_s = 1;
-            break;
-        case 'l':
-            latency = strtol(optarg, NULL, 10);
-            opt_l = 1;
-            break;
-        case 'e':
-            extra = strtol(optarg, NULL, 10);
-            opt_e = 1;
-            break;
-        case 'w':
-            weight = strtol(optarg, NULL, 10);
-            opt_w = 1;
-            break;
-        case 'c':
-            cpupool = optarg;
-            break;
-        }
+    FOREACH_OPT(opt, "d:p:s:l:e:w:c:h", opts, "sched-sedf", 0) {
+    case 0: case 2:
+        return opt;
+    case 'd':
+        dom = optarg;
+        break;
+    case 'p':
+        period = strtol(optarg, NULL, 10);
+        opt_p = 1;
+        break;
+    case 's':
+        slice = strtol(optarg, NULL, 10);
+        opt_s = 1;
+        break;
+    case 'l':
+        latency = strtol(optarg, NULL, 10);
+        opt_l = 1;
+        break;
+    case 'e':
+        extra = strtol(optarg, NULL, 10);
+        opt_e = 1;
+        break;
+    case 'w':
+        weight = strtol(optarg, NULL, 10);
+        opt_w = 1;
+        break;
+    case 'c':
+        cpupool = optarg;
+        break;
     }
 
     if (cpupool && (dom || opt_p || opt_s || opt_l || opt_e || opt_w)) {
@@ -5146,8 +5147,10 @@ int main_domid(int argc, char **argv)
     int opt;
     const char *domname = NULL;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "domid", 1)) != -1)
+    FOREACH_OPT(opt, "", NULL, "domid", 1) {
+    case 0: case 2:
         return opt;
+    }
 
     domname = argv[optind];
 
@@ -5168,8 +5171,10 @@ int main_domname(int argc, char **argv)
     char *domname = NULL;
     char *endptr = NULL;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "domname", 1)) != -1)
+    FOREACH_OPT(opt, "", NULL, "domname", 1) {
+    case 0: case 2:
         return opt;
+    }
 
     domid = strtol(argv[optind], &endptr, 10);
     if (domid == 0 && !strcmp(endptr, argv[optind])) {
@@ -5196,8 +5201,10 @@ int main_rename(int argc, char **argv)
     int opt;
     const char *dom, *new_name;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "rename", 2)) != -1)
+    FOREACH_OPT(opt, "", NULL, "rename", 2) {
+    case 0: case 2:
         return opt;
+    }
 
     dom = argv[optind++];
     new_name = argv[optind];
@@ -5220,8 +5227,10 @@ int main_trigger(int argc, char **argv)
     const char *trigger_name = NULL;
     libxl_trigger trigger;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "trigger", 2)) != -1)
+    FOREACH_OPT(opt, "", NULL, "trigger", 2) {
+    case 0: case 2:
         return opt;
+    }
 
     domid = find_domain(argv[optind++]);
 
@@ -5250,8 +5259,10 @@ int main_sysrq(int argc, char **argv)
     int opt;
     const char *sysrq = NULL;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "sysrq", 2)) != -1)
+    FOREACH_OPT(opt, "", NULL, "sysrq", 2) {
+    case 0: case 2:
         return opt;
+    }
 
     domid = find_domain(argv[optind++]);
 
@@ -5273,8 +5284,10 @@ int main_debug_keys(int argc, char **arg
     int opt;
     char *keys;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "debug-keys", 1)) != -1)
+    FOREACH_OPT(opt, "", NULL, "debug-keys", 1) {
+    case 0: case 2:
         return opt;
+    }
 
     keys = argv[optind];
 
@@ -5293,14 +5306,12 @@ int main_dmesg(int argc, char **argv)
     char *line;
     int opt, ret = 1;
 
-    while ((opt = def_getopt(argc, argv, "c", NULL, "dmesg", 0)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        case 'c':
-            clear = 1;
-            break;
-        }
+    FOREACH_OPT(opt, "c", NULL, "dmesg", 0) {
+    case 0: case 2:
+        return opt;
+    case 'c':
+        clear = 1;
+        break;
     }
 
     cr = libxl_xen_console_read_start(ctx, clear);
@@ -5319,8 +5330,10 @@ int main_top(int argc, char **argv)
 {
     int opt;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "top", 0)) != -1)
+    FOREACH_OPT(opt, "", NULL, "top", 0) {
+    case 0: case 2:
         return opt;
+    }
 
     return system("xentop");
 }
@@ -5336,8 +5349,10 @@ int main_networkattach(int argc, char **
     int i;
     unsigned int val;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "network-attach", 1)) != -1)
+    FOREACH_OPT(opt, "", NULL, "network-attach", 1) {
+    case 0: case 2:
         return opt;
+    }
 
     if (argc-optind > 11) {
         help("network-attach");
@@ -5423,8 +5438,10 @@ int main_networklist(int argc, char **ar
     libxl_nicinfo nicinfo;
     int nb, i;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "network-list", 1)) != -1)
+    FOREACH_OPT(opt, "", NULL, "network-list", 1) {
+    case 0: case 2:
         return opt;
+    }
 
     /*      Idx  BE   MAC   Hdl  Sta  evch txr/rxr  BE-path */
     printf("%-3s %-2s %-17s %-6s %-5s %-6s %5s/%-5s %-30s\n",
@@ -5460,8 +5477,10 @@ int main_networkdetach(int argc, char **
     int opt;
     libxl_device_nic nic;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "network-detach", 2)) != -1)
+    FOREACH_OPT(opt, "", NULL, "network-detach", 2) {
+    case 0: case 2:
         return opt;
+    }
 
     domid = find_domain(argv[optind]);
 
@@ -5491,8 +5510,10 @@ int main_blockattach(int argc, char **ar
     libxl_device_disk disk = { 0 };
     XLU_Config *config = 0;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "block-attach", 2)) != -1)
+    FOREACH_OPT(opt, "", NULL, "block-attach", 2) {
+    case 0: case 2:
         return opt;
+    }
 
     if (domain_qualifier_to_domid(argv[optind], &fe_domid, 0) < 0) {
         fprintf(stderr, "%s is an invalid domain identifier\n", argv[optind]);
@@ -5526,8 +5547,10 @@ int main_blocklist(int argc, char **argv
     libxl_device_disk *disks;
     libxl_diskinfo diskinfo;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "block-list", 1)) != -1)
+    FOREACH_OPT(opt, "", NULL, "block-list", 1) {
+    case 0: case 2:
         return opt;
+    }
 
     printf("%-5s %-3s %-6s %-5s %-6s %-8s %-30s\n",
            "Vdev", "BE", "handle", "state", "evt-ch", "ring-ref", "BE-path");
@@ -5562,8 +5585,10 @@ int main_blockdetach(int argc, char **ar
     int opt, rc = 0;
     libxl_device_disk disk;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "block-detach", 2)) != -1)
+    FOREACH_OPT(opt, "", NULL, "block-detach", 2) {
+    case 0: case 2:
         return opt;
+    }
 
     domid = find_domain(argv[optind]);
 
@@ -5746,14 +5771,12 @@ int main_uptime(int argc, char **argv)
     int nb_doms = 0;
     int opt;
 
-    while ((opt = def_getopt(argc, argv, "s", NULL, "uptime", 1)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        case 's':
-            short_mode = 1;
-            break;
-        }
+    FOREACH_OPT(opt, "s", NULL, "uptime", 1) {
+    case 0: case 2:
+        return opt;
+    case 's':
+        short_mode = 1;
+        break;
     }
 
     for (;(dom = argv[optind]) != NULL; nb_doms++,optind++)
@@ -5773,17 +5796,15 @@ int main_tmem_list(int argc, char **argv
     int all = 0;
     int opt;
 
-    while ((opt = def_getopt(argc, argv, "al", NULL, "tmem-list", 0)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        case 'l':
-            use_long = 1;
-            break;
-        case 'a':
-            all = 1;
-            break;
-        }
+    FOREACH_OPT(opt, "al", NULL, "tmem-list", 0) {
+    case 0: case 2:
+        return opt;
+    case 'l':
+        use_long = 1;
+        break;
+    case 'a':
+        all = 1;
+        break;
     }
 
     dom = argv[optind];
@@ -5814,14 +5835,12 @@ int main_tmem_freeze(int argc, char **ar
     int all = 0;
     int opt;
 
-    while ((opt = def_getopt(argc, argv, "a", NULL, "tmem-freeze", 0)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        case 'a':
-            all = 1;
-            break;
-        }
+    FOREACH_OPT(opt, "a", NULL, "tmem-freeze", 0) {
+    case 0: case 2:
+        return opt;
+    case 'a':
+        all = 1;
+        break;
     }
 
     dom = argv[optind];
@@ -5847,14 +5866,12 @@ int main_tmem_thaw(int argc, char **argv
     int all = 0;
     int opt;
 
-    while ((opt = def_getopt(argc, argv, "a", NULL, "tmem-thaw", 0)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        case 'a':
-            all = 1;
-            break;
-        }
+    FOREACH_OPT(opt, "a", NULL, "tmem-thaw", 0) {
+    case 0: case 2:
+        return opt;
+    case 'a':
+        all = 1;
+        break;
     }
 
     dom = argv[optind];
@@ -5882,26 +5899,24 @@ int main_tmem_set(int argc, char **argv)
     int all = 0;
     int opt;
 
-    while ((opt = def_getopt(argc, argv, "aw:c:p:", NULL, "tmem-set", 0)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        case 'a':
-            all = 1;
-            break;
-        case 'w':
-            weight = strtol(optarg, NULL, 10);
-            opt_w = 1;
-            break;
-        case 'c':
-            cap = strtol(optarg, NULL, 10);
-            opt_c = 1;
-            break;
-        case 'p':
-            compress = strtol(optarg, NULL, 10);
-            opt_p = 1;
-            break;
-        }
+    FOREACH_OPT(opt, "aw:c:p:", NULL, "tmem-set", 0) {
+    case 0: case 2:
+        return opt;
+    case 'a':
+        all = 1;
+        break;
+    case 'w':
+        weight = strtol(optarg, NULL, 10);
+        opt_w = 1;
+        break;
+    case 'c':
+        cap = strtol(optarg, NULL, 10);
+        opt_c = 1;
+        break;
+    case 'p':
+        compress = strtol(optarg, NULL, 10);
+        opt_p = 1;
+        break;
     }
 
     dom = argv[optind];
@@ -5943,20 +5958,18 @@ int main_tmem_shared_auth(int argc, char
     int all = 0;
     int opt;
 
-    while ((opt = def_getopt(argc, argv, "au:A:", NULL, "tmem-shared-auth", 0)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        case 'a':
-            all = 1;
-            break;
-        case 'u':
-            uuid = optarg;
-            break;
-        case 'A':
-            autharg = optarg;
-            break;
-        }
+    FOREACH_OPT(opt, "au:A:", NULL, "tmem-shared-auth", 0) {
+    case 0: case 2:
+        return opt;
+    case 'a':
+        all = 1;
+        break;
+    case 'u':
+        uuid = optarg;
+        break;
+    case 'A':
+        autharg = optarg;
+        break;
     }
 
     dom = argv[optind];
@@ -5993,8 +6006,10 @@ int main_tmem_freeable(int argc, char **
     int opt;
     int mb;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "tmem-freeable", 0)) != -1)
+    FOREACH_OPT(opt, "", NULL, "tmem-freeale", 0) {
+    case 0: case 2:
         return opt;
+    }
 
     mb = libxl_tmem_freeable(ctx);
     if (mb == -1)
@@ -6033,17 +6048,15 @@ int main_cpupoolcreate(int argc, char **
     libxl_cputopology *topology;
     int rc = -ERROR_FAIL;
 
-    while ((opt = def_getopt(argc, argv, "hnf:", opts, "cpupool-create", 0)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        case 'f':
-            filename = optarg;
-            break;
-        case 'n':
-            dryrun_only = 1;
-            break;
-        }
+    FOREACH_OPT(opt, "hnf:", opts, "cpupool-create", 0) {
+    case 0: case 2:
+        return opt;
+    case 'f':
+        filename = optarg;
+        break;
+    case 'n':
+        dryrun_only = 1;
+        break;
     }
 
     memset(extra_config, 0, sizeof(extra_config));
@@ -6218,14 +6231,12 @@ int main_cpupoollist(int argc, char **ar
     char *name;
     int ret = 0;
 
-    while ((opt = def_getopt(argc, argv, "hc", opts, "cpupool-list", 1)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            break;
-        case 'c':
-            opt_cpus = 1;
-            break;
-        }
+    FOREACH_OPT(opt, "hc", opts, "cpupool-list", 1) {
+    case 0: case 2:
+        break;
+    case 'c':
+        opt_cpus = 1;
+        break;
     }
 
     if (optind < argc) {
@@ -6285,8 +6296,10 @@ int main_cpupooldestroy(int argc, char *
     const char *pool;
     uint32_t poolid;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "cpupool-destroy", 1)) != -1)
+    FOREACH_OPT(opt, "", NULL, "cpupool-destroy", 1) {
+    case 0: case 2:
         return opt;
+    }
 
     pool = argv[optind];
 
@@ -6306,8 +6319,10 @@ int main_cpupoolrename(int argc, char **
     const char *new_name;
     uint32_t poolid;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "cpupool-rename", 2)) != -1)
+    FOREACH_OPT(opt, "", NULL, "cpupool-rename", 2) {
+    case 0: case 2:
         return opt;
+    }
 
     pool = argv[optind++];
 
@@ -6336,8 +6351,10 @@ int main_cpupoolcpuadd(int argc, char **
     int node;
     int n;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "cpupool-cpu-add", 2)) != -1)
+    FOREACH_OPT(opt, "", NULL, "cpupool-cpu-add", 2) {
+    case 0: case 2:
         return opt;
+    }
 
     pool = argv[optind++];
     node = -1;
@@ -6380,8 +6397,10 @@ int main_cpupoolcpuremove(int argc, char
     int node;
     int n;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "cpupool-cpu-remove", 2)) != -1)
+    FOREACH_OPT(opt, "", NULL, "cpupool-cpu-remove", 2) {
+    case 0: case 2:
         return opt;
+    }
 
     pool = argv[optind++];
     node = -1;
@@ -6423,8 +6442,10 @@ int main_cpupoolmigrate(int argc, char *
     const char *dom;
     uint32_t domid;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "cpupool-migrate", 2)) != -1)
+    FOREACH_OPT(opt, "", NULL, "cpupool-migrate", 2) {
+    case 0: case 2:
         return opt;
+    }
 
     dom = argv[optind++];
     pool = argv[optind];
@@ -6463,8 +6484,11 @@ int main_cpupoolnumasplit(int argc, char
     libxl_cputopology *topology;
     libxl_dominfo info;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "cpupool-numa-split", 0)) != -1)
+    FOREACH_OPT(opt, "", NULL, "cpupool-numa-split", 0) {
+    case 0: case 2:
         return opt;
+    }
+
     ret = 0;
 
     poolinfo = libxl_list_cpupool(ctx, &n_pools);
@@ -6716,27 +6740,24 @@ int main_remus(int argc, char **argv)
     r_info.blackhole = 0;
     r_info.compression = 1;
 
-    while ((opt = def_getopt(argc, argv, "bui:s:e", NULL, "remus", 2)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-
-        case 'i':
-	    r_info.interval = atoi(optarg);
-            break;
-        case 'b':
-            r_info.blackhole = 1;
-            break;
-        case 'u':
-	    r_info.compression = 0;
-            break;
-        case 's':
-            ssh_command = optarg;
-            break;
-        case 'e':
-            daemonize = 0;
-            break;
-        }
+    FOREACH_OPT(opt, "bui:s:e", NULL, "remus", 2) {
+    case 0: case 2:
+        return opt;
+    case 'i':
+        r_info.interval = atoi(optarg);
+        break;
+    case 'b':
+        r_info.blackhole = 1;
+        break;
+    case 'u':
+        r_info.compression = 0;
+        break;
+    case 's':
+        ssh_command = optarg;
+        break;
+    case 'e':
+        daemonize = 0;
+        break;
     }
 
     domid = find_domain(argv[optind]);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 10:10:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 10:10:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNhcT-0000Px-7v; Mon, 15 Oct 2012 10:09:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TNhcR-0000Pm-Pf
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 10:09:55 +0000
Received: from [85.158.137.99:59848] by server-16.bemta-3.messagelabs.com id
	58/90-16565-2F0EB705; Mon, 15 Oct 2012 10:09:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1350295792!21494822!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYzNjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3818 invoked from network); 15 Oct 2012 10:09:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 10:09:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="41199645"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 10:09:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 06:09:50 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1TNhcM-0002h0-4d;
	Mon, 15 Oct 2012 11:09:50 +0100
MIME-Version: 1.0
Message-ID: <patchbomb.1350295789@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 15 Oct 2012 11:09:49 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com, linux@eikelenboom.it
Subject: [Xen-devel] [PATCH 0 of 5] xl shutdown compatibility with xm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The following implements xm compatibility for the xl shutdown command
and a prerequisite bug fix.

In particular add --all and --wait which are used by the xendomains
initscript. It also adds the same options to xl reboot.

Lastly it cleans up and simplifies option parsing.

The xl shutdown/reboot patches should go into 4.2.1, the option
parsing cleanups should not.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 10:10:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 10:10:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNhcV-0000QN-0n; Mon, 15 Oct 2012 10:09:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TNhcT-0000Ps-HK
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 10:09:57 +0000
Received: from [85.158.137.99:18893] by server-6.bemta-3.messagelabs.com id
	69/D8-32375-4F0EB705; Mon, 15 Oct 2012 10:09:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1350295792!21494822!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYzNjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3931 invoked from network); 15 Oct 2012 10:09:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 10:09:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="41199647"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 10:09:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 06:09:50 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1TNhcM-0002h0-6H;
	Mon, 15 Oct 2012 11:09:50 +0100
MIME-Version: 1.0
X-Mercurial-Node: 5a24315f39c035e5e5b773ebca676d5248a41252
Message-ID: <5a24315f39c035e5e5b7.1350295792@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1350295789@cosworth.uk.xensource.com>
References: <patchbomb.1350295789@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 15 Oct 2012 11:09:52 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com, linux@eikelenboom.it
Subject: [Xen-devel] [PATCH 3 of 5] xl: Add --wait and --all to xl reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Ian Campbell <ijc@hellion.org.uk>
# Date 1350295718 -3600
# Node ID 5a24315f39c035e5e5b773ebca676d5248a41252
# Parent  2329dca4ef449979b1403c4bb002fcb70c578b35
xl: Add --wait and --all to xl reboot.

Inspired by a patch by Sander Eikelenboom.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 2329dca4ef44 -r 5a24315f39c0 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Sep 06 21:41:27 2012 +0200
+++ b/tools/libxl/xl_cmdimpl.c	Mon Oct 15 11:08:38 2012 +0100
@@ -2716,7 +2716,7 @@ static void destroy_domain(uint32_t domi
 static void wait_for_domain_deaths(libxl_evgen_domain_death **deathws, int nr)
 {
     int rc, count = 0;
-    LOG("Waiting for %d domains to shutdown", nr);
+    LOG("Waiting for %d domains", nr);
     while(1 && count < nr) {
         libxl_event *event;
         rc = libxl_event_wait(ctx, &event, LIBXL_EVENTMASK_ALL, 0,0);
@@ -2776,15 +2776,15 @@ static void shutdown_domain(uint32_t dom
             fprintf(stderr,"wait for death failed (evgen, rc=%d)\n",rc);
             exit(-1);
         }
-        printf("Waiting for domain %d death %p %"PRIx64"\n",
-               domid, *deathw, for_user);
-    }
-}
-
-static void reboot_domain(uint32_t domid, int fallback_trigger)
+    }
+}
+
+static void reboot_domain(uint32_t domid, libxl_evgen_domain_death **deathw,
+                          libxl_ev_user for_user, int fallback_trigger)
 {
     int rc;
 
+    fprintf(stderr, "Rebooting domain %d\n", domid);
     rc=libxl_domain_reboot(ctx, domid);
     if (rc == ERROR_NOPARAVIRT) {
         if (fallback_trigger) {
@@ -2800,6 +2800,14 @@ static void reboot_domain(uint32_t domid
     if (rc) {
         fprintf(stderr,"reboot failed (rc=%d)\n",rc);exit(-1);
     }
+
+    if (deathw) {
+        rc = libxl_evenable_domain_death(ctx, domid, for_user, deathw);
+        if (rc) {
+            fprintf(stderr,"wait for death failed (evgen, rc=%d)\n",rc);
+            exit(-1);
+        }
+    }
 }
 
 static void list_domains_details(const libxl_dominfo *info, int nb_domain)
@@ -3713,8 +3721,11 @@ int main_destroy(int argc, char **argv)
     return 0;
 }
 
-int main_shutdown(int argc, char **argv)
-{
+static int main_shutdown_or_reboot(int reboot, int argc, char **argv)
+{
+    void (*fn)(uint32_t domid,
+               libxl_evgen_domain_death **, libxl_ev_user, int) =
+        reboot ? &reboot_domain : &shutdown_domain;
     int opt, i, nb_domain;
     int wait_for_it = 0, all =0;
     int fallback_trigger = 0;
@@ -3730,6 +3741,7 @@ int main_shutdown(int argc, char **argv)
             return opt;
         case 'a':
             all = 1;
+            break;
         case 'w':
             wait_for_it = 1;
             break;
@@ -3758,9 +3770,8 @@ int main_shutdown(int argc, char **argv)
         for (i = 0; i<nb_domain; i++) {
             if (dominfo[i].domid == 0)
                 continue;
-            shutdown_domain(dominfo[i].domid,
-                            deathws ? &deathws[i] : NULL, i,
-                            fallback_trigger);
+            fn(dominfo[i].domid, deathws ? &deathws[i] : NULL, i,
+               fallback_trigger);
         }
 
         wait_for_domain_deaths(deathws, nb_domain - 1 /* not dom 0 */);
@@ -3769,8 +3780,7 @@ int main_shutdown(int argc, char **argv)
         libxl_evgen_domain_death *deathw = NULL;
         uint32_t domid = find_domain(argv[optind]);
 
-        shutdown_domain(domid, wait_for_it ? &deathw : NULL, 0,
-                        fallback_trigger);
+        fn(domid, wait_for_it ? &deathw : NULL, 0, fallback_trigger);
 
         if (wait_for_it)
             wait_for_domain_deaths(&deathw, 1);
@@ -3780,23 +3790,14 @@ int main_shutdown(int argc, char **argv)
     return 0;
 }
 
+int main_shutdown(int argc, char **argv)
+{
+    return main_shutdown_or_reboot(0, argc, argv);
+}
+
 int main_reboot(int argc, char **argv)
 {
-    int opt;
-    int fallback_trigger = 0;
-
-    while ((opt = def_getopt(argc, argv, "F", "reboot", 1)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        case 'F':
-            fallback_trigger = 1;
-            break;
-        }
-    }
-
-    reboot_domain(find_domain(argv[optind]), fallback_trigger);
-    return 0;
+    return main_shutdown_or_reboot(1, argc, argv);
 }
 
 int main_list(int argc, char **argv)
diff -r 2329dca4ef44 -r 5a24315f39c0 tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c	Thu Sep 06 21:41:27 2012 +0200
+++ b/tools/libxl/xl_cmdtable.c	Mon Oct 15 11:08:38 2012 +0100
@@ -70,10 +70,12 @@ struct cmd_spec cmd_table[] = {
     { "reboot",
       &main_reboot, 0, 1,
       "Issue a reboot signal to a domain",
-      "[options] <Domain>",
+      "[options] <-a|Domain>",
+      "-a, --all               Shutdown all guest domains.\n"
       "-h                      Print this help.\n"
       "-F                      Fallback to ACPI reset event for HVM guests with\n"
       "                        no PV drivers.\n"
+      "-w, --wait              Wait for guest(s) to reboot.\n"
     },
     { "pci-attach",
       &main_pciattach, 0, 1,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 10:10:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 10:10:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNhcX-0000R7-1o; Mon, 15 Oct 2012 10:10:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TNhcV-0000QE-53
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 10:09:59 +0000
Received: from [85.158.137.99:60123] by server-1.bemta-3.messagelabs.com id
	74/C9-31728-6F0EB705; Mon, 15 Oct 2012 10:09:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1350295792!21494822!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYzNjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3962 invoked from network); 15 Oct 2012 10:09:56 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 10:09:56 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="41199651"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 10:09:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 06:09:50 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1TNhcM-0002h0-7S;
	Mon, 15 Oct 2012 11:09:50 +0100
MIME-Version: 1.0
X-Mercurial-Node: 22688187afa84747de9b820cb29addbd65385042
Message-ID: <22688187afa84747de9b.1350295794@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1350295789@cosworth.uk.xensource.com>
References: <patchbomb.1350295789@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 15 Oct 2012 11:09:54 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com, linux@eikelenboom.it
Subject: [Xen-devel] [PATCH 5 of 5] xl: Introduce helper macro for option
	parsing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Ian Campbell <ijc@hellion.org.uk>
# Date 1350295720 -3600
# Node ID 22688187afa84747de9b820cb29addbd65385042
# Parent  bbb839ceb966cc265e5d2ca530ba0f2bf823176a
xl: Introduce helper macro for option parsing.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r bbb839ceb966 -r 22688187afa8 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Oct 15 11:08:39 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Mon Oct 15 11:08:40 2012 +0100
@@ -2281,6 +2281,11 @@ static int def_getopt(int argc, char * c
     return -1;
 }
 
+#define FOREACH_OPT(_opt, _opts, _lopts, _help, _req)           \
+    while (((_opt) = def_getopt(argc, argv, (_opts), (_lopts),  \
+                                (_help), (_req))) != -1)        \
+        switch (opt)
+
 static int set_memory_max(uint32_t domid, const char *mem)
 {
     int64_t memorykb;
@@ -2304,8 +2309,10 @@ int main_memmax(int argc, char **argv)
     char *mem;
     int rc;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "mem-max", 2)) != -1)
+    FOREACH_OPT(opt, "", NULL, "mem-max", 2) {
+    case 0: case 2:
         return opt;
+    }
 
     domid = find_domain(argv[optind]);
     mem = argv[optind + 1];
@@ -2338,8 +2345,10 @@ int main_memset(int argc, char **argv)
     int opt = 0;
     const char *mem;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "mem-set", 2)) != -1)
+    FOREACH_OPT(opt, "", NULL, "mem-set", 2) {
+    case 0: case 2:
         return opt;
+    }
 
     domid = find_domain(argv[optind]);
     mem = argv[optind + 1];
@@ -2377,8 +2386,10 @@ int main_cd_eject(int argc, char **argv)
     int opt = 0;
     const char *virtdev;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "cd-eject", 2)) != -1)
-        return opt;
+    FOREACH_OPT(opt, "", NULL, "cd-eject", 2) {
+        case 0: case 2:
+            return opt;
+    }
 
     domid = find_domain(argv[optind]);
     virtdev = argv[optind + 1];
@@ -2394,8 +2405,10 @@ int main_cd_insert(int argc, char **argv
     const char *virtdev;
     char *file = NULL; /* modified by cd_insert tokenising it */
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "cd-insert", 3)) != -1)
+    FOREACH_OPT(opt, "", NULL, "cd-insert", 3) {
+    case 0: case 2:
         return opt;
+    }
 
     domid = find_domain(argv[optind]);
     virtdev = argv[optind + 1];
@@ -2411,24 +2424,22 @@ int main_console(int argc, char **argv)
     int opt = 0, num = 0;
     libxl_console_type type = 0;
 
-    while ((opt = def_getopt(argc, argv, "n:t:", NULL, "console", 1)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        case 't':
-            if (!strcmp(optarg, "pv"))
-                type = LIBXL_CONSOLE_TYPE_PV;
-            else if (!strcmp(optarg, "serial"))
-                type = LIBXL_CONSOLE_TYPE_SERIAL;
-            else {
-                fprintf(stderr, "console type supported are: pv, serial\n");
-                return 2;
-            }
-            break;
-        case 'n':
-            num = atoi(optarg);
-            break;
+    FOREACH_OPT(opt, "n:t:", NULL, "console", 1) {
+    case 0: case 2:
+        return opt;
+    case 't':
+        if (!strcmp(optarg, "pv"))
+            type = LIBXL_CONSOLE_TYPE_PV;
+        else if (!strcmp(optarg, "serial"))
+            type = LIBXL_CONSOLE_TYPE_SERIAL;
+        else {
+            fprintf(stderr, "console type supported are: pv, serial\n");
+            return 2;
         }
+        break;
+    case 'n':
+        num = atoi(optarg);
+        break;
     }
 
     domid = find_domain(argv[optind]);
@@ -2451,14 +2462,12 @@ int main_vncviewer(int argc, char **argv
     uint32_t domid;
     int opt, autopass = 0;
 
-    while ((opt = def_getopt(argc, argv, "ah", opts, "vncviewer", 1)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        case 'a':
-            autopass = 1;
-            break;
-        }
+    FOREACH_OPT(opt, "ah", opts, "vncviewer", 1) {
+    case 0: case 2:
+        return opt;
+    case 'a':
+        autopass = 1;
+        break;
     }
 
     domid = find_domain(argv[optind]);
@@ -2491,8 +2500,10 @@ int main_pcilist(int argc, char **argv)
     uint32_t domid;
     int opt;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "pci-list", 1)) != -1)
+    FOREACH_OPT(opt, "", NULL, "pci-list", 1) {
+    case 0: case 2:
         return opt;
+    }
 
     domid = find_domain(argv[optind]);
 
@@ -2530,14 +2541,12 @@ int main_pcidetach(int argc, char **argv
     int force = 0;
     const char *bdf = NULL;
 
-    while ((opt = def_getopt(argc, argv, "f", NULL, "pci-detach", 2)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        case 'f':
-            force = 1;
-            break;
-        }
+    FOREACH_OPT(opt, "f", NULL, "pci-detach", 2) {
+    case 0: case 2:
+        return opt;
+    case 'f':
+        force = 1;
+        break;
     }
 
     domid = find_domain(argv[optind]);
@@ -2572,8 +2581,10 @@ int main_pciattach(int argc, char **argv
     int opt;
     const char *bdf = NULL, *vs = NULL;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "pci-attach", 2)) != -1)
+    FOREACH_OPT(opt, "", NULL, "pci-attach", 2) {
+    case 0: case 2:
         return opt;
+    }
 
     domid = find_domain(argv[optind]);
     bdf = argv[optind + 1];
@@ -2606,8 +2617,10 @@ int main_pciassignable_list(int argc, ch
 {
     int opt;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "pci-assignable-list", 0)) != -1)
+    FOREACH_OPT(opt, "", NULL, "pci-assignable-list", 0) {
+    case 0: case 2:
         return opt;
+    }
 
     pciassignable_list();
     return 0;
@@ -2638,11 +2651,9 @@ int main_pciassignable_add(int argc, cha
     int opt;
     const char *bdf = NULL;
 
-    while ((opt = def_getopt(argc, argv, "", NULL, "pci-assignable-add", 1)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        }
+    FOREACH_OPT(opt, "", NULL, "pci-assignable-add", 1) {
+    case 0: case 2:
+        return opt;
     }
 
     bdf = argv[optind];
@@ -2677,14 +2688,12 @@ int main_pciassignable_remove(int argc, 
     const char *bdf = NULL;
     int rebind = 0;
 
-    while ((opt = def_getopt(argc, argv, "r", NULL, "pci-assignable-remove", 1)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        case 'r':
-            rebind=1;
-            break;
-        }
+    FOREACH_OPT(opt, "r", NULL, "pci-assignable-remove", 1) {
+    case 0: case 2:
+        return opt;
+    case 'r':
+        rebind=1;
+        break;
     }
 
     bdf = argv[optind];
@@ -3495,34 +3504,31 @@ int main_restore(int argc, char **argv)
         {0, 0, 0, 0}
     };
 
-    while ((opt = def_getopt(argc, argv, "FhcpdeVA",
-                             opts, "restore", 1)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        case 'c':
-            console_autoconnect = 1;
-            break;
-        case 'p':
-            paused = 1;
-            break;
-        case 'd':
-            debug = 1;
-            break;
-        case 'F':
-            daemonize = 0;
-            break;
-        case 'e':
-            daemonize = 0;
-            monitor = 0;
-            break;
-        case 'V':
-            vnc = 1;
-            break;
-        case 'A':
-            vnc = vncautopass = 1;
-            break;
-        }
+    FOREACH_OPT(opt, "FhcpdeVA", opts, "restore", 1) {
+    case 0: case 2:
+        return opt;
+    case 'c':
+        console_autoconnect = 1;
+        break;
+    case 'p':
+        paused = 1;
+        break;
+    case 'd':
+        debug = 1;
+        break;
+    case 'F':
+        daemonize = 0;
+        break;
+    case 'e':
+        daemonize = 0;
+        monitor = 0;
+        break;
+    case 'V':
+        vnc = 1;
+        break;
+    case 'A':
+        vnc = vncautopass = 1;
+        break;
     }
 
     if (argc-optind == 1) {
@@ -3559,24 +3565,22 @@ int main_migrate_receive(int argc, char 
     int debug = 0, daemonize = 1, monitor = 1, remus = 0;
     int opt;
 
-    while ((opt = def_getopt(argc, argv, "Fedr", NULL, "migrate-receive", 0)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        case 'F':
-            daemonize = 0;
-            break;
-        case 'e':
-            daemonize = 0;
-            monitor = 0;
-            break;
-        case 'd':
-            debug = 1;
-            break;
-        case 'r':
-            remus = 1;
-            break;
-        }
+    FOREACH_OPT(opt, "Fedr", NULL, "migrate-receive", 0) {
+    case 0: case 2:
+        return opt;
+    case 'F':
+        daemonize = 0;
+        break;
+    case 'e':
+        daemonize = 0;
+        monitor = 0;
+        break;
+    case 'd':
+        debug = 1;
+        break;
+    case 'r':
+        remus = 1;
+        break;
     }
 
     if (argc-optind != 0) {
@@ -3598,14 +3602,12 @@ int main_save(int argc, char **argv)
     int checkpoint = 0;
     int opt;
 
-    while ((opt = def_getopt(argc, argv, "c", NULL, "save", 2)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        case 'c':
-            checkpoint = 1;
-            break;
-        }
+    FOREACH_OPT(opt, "c", NULL, "save", 2) {
+    case 0: case 2:
+        return opt;
+    case 'c':
+        checkpoint = 1;
+        break;
     }
 
     if (argc-optind > 3) {
@@ -3631,27 +3633,25 @@ int main_migrate(int argc, char **argv)
     char *host;
     int opt, daemonize = 1, monitor = 1, debug = 0;
 
-    while ((opt = def_getopt(argc, argv, "FC:s:ed", NULL, "migrate", 2)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        case 'C':
-            config_filename = optarg;
-            break;
-        case 's':
-            ssh_command = optarg;
-            break;
-        case 'F':
-            daemonize = 0;
-            break;
-        case 'e':
-            daemonize = 0;
-            monitor = 0;
-            break;
-        case 'd':
-            debug = 1;
-            break;
-        }
+    FOREACH_OPT(opt, "FC:s:ed", NULL, "migrate", 2) {
+    case 0: case 2:
+        return opt;
+    case 'C':
+        config_filename = optarg;
+        break;
+    case 's':
+        ssh_command = optarg;
+        break;
+    case 'F':
+        daemonize = 0;
+        break;
+    case 'e':
+        daemonize = 0;
+        monitor = 0;
+        break;
+    case 'd':
+        debug = 1;
+        break;
     }
 
     domid = find_domain(argv[optind]);
@@ -3675,8 +3675,10 @@ int main_dump_core(int argc, char **argv
 {
     int opt;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "dump-core", 2)) != -1)
+    FOREACH_OPT(opt, "", NULL, "dump-core", 2) {
+    case 0: case 2:
         return opt;
+    }
 
     core_dump_domain(find_domain(argv[optind]), argv[optind + 1]);
     return 0;
@@ -3686,8 +3688,10 @@ int main_pause(int argc, char **argv)
 {
     int opt;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "pause", 1)) != -1)
+    FOREACH_OPT(opt, "", NULL, "pause", 1) {
+    case 0: case 2:
         return opt;
+    }
 
     pause_domain(find_domain(argv[optind]));
 
@@ -3698,8 +3702,10 @@ int main_unpause(int argc, char **argv)
 {
     int opt;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "unpause", 1)) != -1)
+    FOREACH_OPT(opt, "", NULL, "unpause", 1) {
+    case 0: case 2:
         return opt;
+    }
 
     unpause_domain(find_domain(argv[optind]));
 
@@ -3710,8 +3716,10 @@ int main_destroy(int argc, char **argv)
 {
     int opt;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "destroy", 1)) != -1)
+    FOREACH_OPT(opt, "", NULL, "destroy", 1) {
+    case 0: case 2:
         return opt;
+    }
 
     destroy_domain(find_domain(argv[optind]));
     return 0;
@@ -3815,23 +3823,18 @@ int main_list(int argc, char **argv)
     libxl_dominfo *info, *info_free=0;
     int nb_domain, rc;
 
-    while ((opt = def_getopt(argc, argv, "lvhZ", opts, "list", 0)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        case 'l':
-            details = 1;
-            break;
-        case 'h':
-            help("list");
-            return 0;
-        case 'v':
-            verbose = 1;
-            break;
-        case 'Z':
-            context = 1;
-            break;
-        }
+    FOREACH_OPT(opt, "lvhZ", opts, "list", 0) {
+    case 0: case 2:
+        return opt;
+    case 'l':
+        details = 1;
+        break;
+    case 'v':
+        verbose = 1;
+        break;
+    case 'Z':
+        context = 1;
+        break;
     }
 
     if (optind >= argc) {
@@ -3877,8 +3880,10 @@ int main_vm_list(int argc, char **argv)
 {
     int opt;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "vm-list", 0)) != -1)
+    FOREACH_OPT(opt, "", NULL, "vm-list", 0) {
+    case 0: case 2:
         return opt;
+    }
 
     list_vm();
     return 0;
@@ -3908,45 +3913,40 @@ int main_create(int argc, char **argv)
         argc--; argv++;
     }
 
-    while ((opt = def_getopt(argc, argv, "Fhnqf:pcdeVA", opts, "create", 0)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        case 'f':
-            filename = optarg;
-            break;
-        case 'p':
-            paused = 1;
-            break;
-        case 'c':
-            console_autoconnect = 1;
-            break;
-        case 'd':
-            debug = 1;
-            break;
-        case 'F':
-            daemonize = 0;
-            break;
-        case 'e':
-            daemonize = 0;
-            monitor = 0;
-            break;
-        case 'h':
-            help("create");
-            return 0;
-        case 'n':
-            dryrun_only = 1;
-            break;
-        case 'q':
-            quiet = 1;
-            break;
-        case 'V':
-            vnc = 1;
-            break;
-        case 'A':
-            vnc = vncautopass = 1;
-            break;
-        }
+    FOREACH_OPT(opt, "Fhnqf:pcdeVA", opts, "create", 0) {
+    case 0: case 2:
+        return opt;
+    case 'f':
+        filename = optarg;
+        break;
+    case 'p':
+        paused = 1;
+        break;
+    case 'c':
+        console_autoconnect = 1;
+        break;
+    case 'd':
+        debug = 1;
+        break;
+    case 'F':
+        daemonize = 0;
+        break;
+    case 'e':
+        daemonize = 0;
+        monitor = 0;
+        break;
+    case 'n':
+        dryrun_only = 1;
+        break;
+    case 'q':
+        quiet = 1;
+        break;
+    case 'V':
+        vnc = 1;
+        break;
+    case 'A':
+        vnc = vncautopass = 1;
+        break;
     }
 
     extra_config[0] = '\0';
@@ -4014,17 +4014,15 @@ int main_config_update(int argc, char **
         argc--; argv++;
     }
 
-    while ((opt = def_getopt(argc, argv, "dhqf:", opts, "config_update", 0)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        case 'd':
-            debug = 1;
-            break;
-        case 'f':
-            filename = optarg;
-            break;
-        }
+    FOREACH_OPT(opt, "dhqf:", opts, "config_update", 0) {
+    case 0: case 2:
+        return opt;
+    case 'd':
+        debug = 1;
+        break;
+    case 'f':
+        filename = optarg;
+        break;
     }
 
     extra_config[0] = '\0';
@@ -4112,8 +4110,11 @@ int main_button_press(int argc, char **a
     fprintf(stderr, "WARNING: \"button-press\" is deprecated. "
             "Please use \"trigger\"\n");
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "button-press", 2)) != -1)
+
+    FOREACH_OPT(opt, "", NULL, "button-press", 2) {
+    case 0: case 2:
         return opt;
+    }
 
     button_press(find_domain(argv[optind]), argv[optind + 1]);
 
@@ -4253,8 +4254,10 @@ int main_vcpulist(int argc, char **argv)
 {
     int opt;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "cpu-list", 0)) != -1)
+    FOREACH_OPT(opt, "", NULL, "cpu-list", 0) {
+    case 0: case 2:
         return opt;
+    }
 
     vcpulist(argc - optind, argv + optind);
     return 0;
@@ -4314,8 +4317,10 @@ int main_vcpupin(int argc, char **argv)
 {
     int opt;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "vcpu-pin", 3)) != -1)
+    FOREACH_OPT(opt, "", NULL, "vcpu-pin", 3) {
+    case 0: case 2:
         return opt;
+    }
 
     vcpupin(find_domain(argv[optind]), argv[optind+1] , argv[optind+2]);
     return 0;
@@ -4350,8 +4355,10 @@ int main_vcpuset(int argc, char **argv)
 {
     int opt;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "vcpu-set", 2)) != -1)
+    FOREACH_OPT(opt, "", NULL, "vcpu-set", 2) {
+    case 0: case 2:
         return opt;
+    }
 
     vcpuset(find_domain(argv[optind]), argv[optind+1]);
     return 0;
@@ -4533,14 +4540,12 @@ int main_info(int argc, char **argv)
     };
     int numa = 0;
 
-    while ((opt = def_getopt(argc, argv, "hn", opts, "info", 0)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        case 'n':
-            numa = 1;
-            break;
-        }
+    FOREACH_OPT(opt, "hn", opts, "info", 0) {
+    case 0: case 2:
+        return opt;
+    case 'n':
+        numa = 1;
+        break;
     }
 
     print_info(numa);
@@ -4574,8 +4579,10 @@ int main_sharing(int argc, char **argv)
     libxl_dominfo *info, *info_free = NULL;
     int nb_domain, rc;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "sharing", 0)) != -1)
+    FOREACH_OPT(opt, "", NULL, "sharing", 0) {
+    case 0: case 2:
         return opt;
+    }
 
     if (optind >= argc) {
         info = libxl_list_domain(ctx, &nb_domain);
@@ -4855,36 +4862,34 @@ int main_sched_credit(int argc, char **a
         {0, 0, 0, 0}
     };
 
-    while ((opt = def_getopt(argc, argv, "d:w:c:p:t:r:hs", opts, "sched-credit", 0)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        case 'd':
-            dom = optarg;
-            break;
-        case 'w':
-            weight = strtol(optarg, NULL, 10);
-            opt_w = 1;
-            break;
-        case 'c':
-            cap = strtol(optarg, NULL, 10);
-            opt_c = 1;
-            break;
-        case 't':
-            tslice = strtol(optarg, NULL, 10);
-            opt_t = 1;
-            break;
-        case 'r':
-            ratelimit = strtol(optarg, NULL, 10);
-            opt_r = 1;
-            break;
-        case 's':
-            opt_s = 1;
-            break;
-        case 'p':
-            cpupool = optarg;
-            break;
-        }
+    FOREACH_OPT(opt, "d:w:c:p:t:r:hs", opts, "sched-credit", 0) {
+    case 0: case 2:
+        return opt;
+    case 'd':
+        dom = optarg;
+        break;
+    case 'w':
+        weight = strtol(optarg, NULL, 10);
+        opt_w = 1;
+        break;
+    case 'c':
+        cap = strtol(optarg, NULL, 10);
+        opt_c = 1;
+        break;
+    case 't':
+        tslice = strtol(optarg, NULL, 10);
+        opt_t = 1;
+        break;
+    case 'r':
+        ratelimit = strtol(optarg, NULL, 10);
+        opt_r = 1;
+        break;
+    case 's':
+        opt_s = 1;
+        break;
+    case 'p':
+        cpupool = optarg;
+        break;
     }
 
     if ((cpupool || opt_s) && (dom || opt_w || opt_c)) {
@@ -4974,21 +4979,19 @@ int main_sched_credit2(int argc, char **
         {0, 0, 0, 0}
     };
 
-    while ((opt = def_getopt(argc, argv, "d:w:p:h", opts, "sched-credit2", 0)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        case 'd':
-            dom = optarg;
-            break;
-        case 'w':
-            weight = strtol(optarg, NULL, 10);
-            opt_w = 1;
-            break;
-        case 'p':
-            cpupool = optarg;
-            break;
-        }
+    FOREACH_OPT(opt, "d:w:p:h", opts, "sched-credit2", 0) {
+    case 0: case 2:
+        return opt;
+    case 'd':
+        dom = optarg;
+        break;
+    case 'w':
+        weight = strtol(optarg, NULL, 10);
+        opt_w = 1;
+        break;
+    case 'p':
+        cpupool = optarg;
+        break;
     }
 
     if (cpupool && (dom || opt_w)) {
@@ -5049,37 +5052,35 @@ int main_sched_sedf(int argc, char **arg
         {0, 0, 0, 0}
     };
 
-    while ((opt = def_getopt(argc, argv, "d:p:s:l:e:w:c:h", opts, "sched-sedf", 0)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        case 'd':
-            dom = optarg;
-            break;
-        case 'p':
-            period = strtol(optarg, NULL, 10);
-            opt_p = 1;
-            break;
-        case 's':
-            slice = strtol(optarg, NULL, 10);
-            opt_s = 1;
-            break;
-        case 'l':
-            latency = strtol(optarg, NULL, 10);
-            opt_l = 1;
-            break;
-        case 'e':
-            extra = strtol(optarg, NULL, 10);
-            opt_e = 1;
-            break;
-        case 'w':
-            weight = strtol(optarg, NULL, 10);
-            opt_w = 1;
-            break;
-        case 'c':
-            cpupool = optarg;
-            break;
-        }
+    FOREACH_OPT(opt, "d:p:s:l:e:w:c:h", opts, "sched-sedf", 0) {
+    case 0: case 2:
+        return opt;
+    case 'd':
+        dom = optarg;
+        break;
+    case 'p':
+        period = strtol(optarg, NULL, 10);
+        opt_p = 1;
+        break;
+    case 's':
+        slice = strtol(optarg, NULL, 10);
+        opt_s = 1;
+        break;
+    case 'l':
+        latency = strtol(optarg, NULL, 10);
+        opt_l = 1;
+        break;
+    case 'e':
+        extra = strtol(optarg, NULL, 10);
+        opt_e = 1;
+        break;
+    case 'w':
+        weight = strtol(optarg, NULL, 10);
+        opt_w = 1;
+        break;
+    case 'c':
+        cpupool = optarg;
+        break;
     }
 
     if (cpupool && (dom || opt_p || opt_s || opt_l || opt_e || opt_w)) {
@@ -5146,8 +5147,10 @@ int main_domid(int argc, char **argv)
     int opt;
     const char *domname = NULL;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "domid", 1)) != -1)
+    FOREACH_OPT(opt, "", NULL, "domid", 1) {
+    case 0: case 2:
         return opt;
+    }
 
     domname = argv[optind];
 
@@ -5168,8 +5171,10 @@ int main_domname(int argc, char **argv)
     char *domname = NULL;
     char *endptr = NULL;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "domname", 1)) != -1)
+    FOREACH_OPT(opt, "", NULL, "domname", 1) {
+    case 0: case 2:
         return opt;
+    }
 
     domid = strtol(argv[optind], &endptr, 10);
     if (domid == 0 && !strcmp(endptr, argv[optind])) {
@@ -5196,8 +5201,10 @@ int main_rename(int argc, char **argv)
     int opt;
     const char *dom, *new_name;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "rename", 2)) != -1)
+    FOREACH_OPT(opt, "", NULL, "rename", 2) {
+    case 0: case 2:
         return opt;
+    }
 
     dom = argv[optind++];
     new_name = argv[optind];
@@ -5220,8 +5227,10 @@ int main_trigger(int argc, char **argv)
     const char *trigger_name = NULL;
     libxl_trigger trigger;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "trigger", 2)) != -1)
+    FOREACH_OPT(opt, "", NULL, "trigger", 2) {
+    case 0: case 2:
         return opt;
+    }
 
     domid = find_domain(argv[optind++]);
 
@@ -5250,8 +5259,10 @@ int main_sysrq(int argc, char **argv)
     int opt;
     const char *sysrq = NULL;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "sysrq", 2)) != -1)
+    FOREACH_OPT(opt, "", NULL, "sysrq", 2) {
+    case 0: case 2:
         return opt;
+    }
 
     domid = find_domain(argv[optind++]);
 
@@ -5273,8 +5284,10 @@ int main_debug_keys(int argc, char **arg
     int opt;
     char *keys;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "debug-keys", 1)) != -1)
+    FOREACH_OPT(opt, "", NULL, "debug-keys", 1) {
+    case 0: case 2:
         return opt;
+    }
 
     keys = argv[optind];
 
@@ -5293,14 +5306,12 @@ int main_dmesg(int argc, char **argv)
     char *line;
     int opt, ret = 1;
 
-    while ((opt = def_getopt(argc, argv, "c", NULL, "dmesg", 0)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        case 'c':
-            clear = 1;
-            break;
-        }
+    FOREACH_OPT(opt, "c", NULL, "dmesg", 0) {
+    case 0: case 2:
+        return opt;
+    case 'c':
+        clear = 1;
+        break;
     }
 
     cr = libxl_xen_console_read_start(ctx, clear);
@@ -5319,8 +5330,10 @@ int main_top(int argc, char **argv)
 {
     int opt;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "top", 0)) != -1)
+    FOREACH_OPT(opt, "", NULL, "top", 0) {
+    case 0: case 2:
         return opt;
+    }
 
     return system("xentop");
 }
@@ -5336,8 +5349,10 @@ int main_networkattach(int argc, char **
     int i;
     unsigned int val;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "network-attach", 1)) != -1)
+    FOREACH_OPT(opt, "", NULL, "network-attach", 1) {
+    case 0: case 2:
         return opt;
+    }
 
     if (argc-optind > 11) {
         help("network-attach");
@@ -5423,8 +5438,10 @@ int main_networklist(int argc, char **ar
     libxl_nicinfo nicinfo;
     int nb, i;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "network-list", 1)) != -1)
+    FOREACH_OPT(opt, "", NULL, "network-list", 1) {
+    case 0: case 2:
         return opt;
+    }
 
     /*      Idx  BE   MAC   Hdl  Sta  evch txr/rxr  BE-path */
     printf("%-3s %-2s %-17s %-6s %-5s %-6s %5s/%-5s %-30s\n",
@@ -5460,8 +5477,10 @@ int main_networkdetach(int argc, char **
     int opt;
     libxl_device_nic nic;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "network-detach", 2)) != -1)
+    FOREACH_OPT(opt, "", NULL, "network-detach", 2) {
+    case 0: case 2:
         return opt;
+    }
 
     domid = find_domain(argv[optind]);
 
@@ -5491,8 +5510,10 @@ int main_blockattach(int argc, char **ar
     libxl_device_disk disk = { 0 };
     XLU_Config *config = 0;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "block-attach", 2)) != -1)
+    FOREACH_OPT(opt, "", NULL, "block-attach", 2) {
+    case 0: case 2:
         return opt;
+    }
 
     if (domain_qualifier_to_domid(argv[optind], &fe_domid, 0) < 0) {
         fprintf(stderr, "%s is an invalid domain identifier\n", argv[optind]);
@@ -5526,8 +5547,10 @@ int main_blocklist(int argc, char **argv
     libxl_device_disk *disks;
     libxl_diskinfo diskinfo;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "block-list", 1)) != -1)
+    FOREACH_OPT(opt, "", NULL, "block-list", 1) {
+    case 0: case 2:
         return opt;
+    }
 
     printf("%-5s %-3s %-6s %-5s %-6s %-8s %-30s\n",
            "Vdev", "BE", "handle", "state", "evt-ch", "ring-ref", "BE-path");
@@ -5562,8 +5585,10 @@ int main_blockdetach(int argc, char **ar
     int opt, rc = 0;
     libxl_device_disk disk;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "block-detach", 2)) != -1)
+    FOREACH_OPT(opt, "", NULL, "block-detach", 2) {
+    case 0: case 2:
         return opt;
+    }
 
     domid = find_domain(argv[optind]);
 
@@ -5746,14 +5771,12 @@ int main_uptime(int argc, char **argv)
     int nb_doms = 0;
     int opt;
 
-    while ((opt = def_getopt(argc, argv, "s", NULL, "uptime", 1)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        case 's':
-            short_mode = 1;
-            break;
-        }
+    FOREACH_OPT(opt, "s", NULL, "uptime", 1) {
+    case 0: case 2:
+        return opt;
+    case 's':
+        short_mode = 1;
+        break;
     }
 
     for (;(dom = argv[optind]) != NULL; nb_doms++,optind++)
@@ -5773,17 +5796,15 @@ int main_tmem_list(int argc, char **argv
     int all = 0;
     int opt;
 
-    while ((opt = def_getopt(argc, argv, "al", NULL, "tmem-list", 0)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        case 'l':
-            use_long = 1;
-            break;
-        case 'a':
-            all = 1;
-            break;
-        }
+    FOREACH_OPT(opt, "al", NULL, "tmem-list", 0) {
+    case 0: case 2:
+        return opt;
+    case 'l':
+        use_long = 1;
+        break;
+    case 'a':
+        all = 1;
+        break;
     }
 
     dom = argv[optind];
@@ -5814,14 +5835,12 @@ int main_tmem_freeze(int argc, char **ar
     int all = 0;
     int opt;
 
-    while ((opt = def_getopt(argc, argv, "a", NULL, "tmem-freeze", 0)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        case 'a':
-            all = 1;
-            break;
-        }
+    FOREACH_OPT(opt, "a", NULL, "tmem-freeze", 0) {
+    case 0: case 2:
+        return opt;
+    case 'a':
+        all = 1;
+        break;
     }
 
     dom = argv[optind];
@@ -5847,14 +5866,12 @@ int main_tmem_thaw(int argc, char **argv
     int all = 0;
     int opt;
 
-    while ((opt = def_getopt(argc, argv, "a", NULL, "tmem-thaw", 0)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        case 'a':
-            all = 1;
-            break;
-        }
+    FOREACH_OPT(opt, "a", NULL, "tmem-thaw", 0) {
+    case 0: case 2:
+        return opt;
+    case 'a':
+        all = 1;
+        break;
     }
 
     dom = argv[optind];
@@ -5882,26 +5899,24 @@ int main_tmem_set(int argc, char **argv)
     int all = 0;
     int opt;
 
-    while ((opt = def_getopt(argc, argv, "aw:c:p:", NULL, "tmem-set", 0)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        case 'a':
-            all = 1;
-            break;
-        case 'w':
-            weight = strtol(optarg, NULL, 10);
-            opt_w = 1;
-            break;
-        case 'c':
-            cap = strtol(optarg, NULL, 10);
-            opt_c = 1;
-            break;
-        case 'p':
-            compress = strtol(optarg, NULL, 10);
-            opt_p = 1;
-            break;
-        }
+    FOREACH_OPT(opt, "aw:c:p:", NULL, "tmem-set", 0) {
+    case 0: case 2:
+        return opt;
+    case 'a':
+        all = 1;
+        break;
+    case 'w':
+        weight = strtol(optarg, NULL, 10);
+        opt_w = 1;
+        break;
+    case 'c':
+        cap = strtol(optarg, NULL, 10);
+        opt_c = 1;
+        break;
+    case 'p':
+        compress = strtol(optarg, NULL, 10);
+        opt_p = 1;
+        break;
     }
 
     dom = argv[optind];
@@ -5943,20 +5958,18 @@ int main_tmem_shared_auth(int argc, char
     int all = 0;
     int opt;
 
-    while ((opt = def_getopt(argc, argv, "au:A:", NULL, "tmem-shared-auth", 0)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        case 'a':
-            all = 1;
-            break;
-        case 'u':
-            uuid = optarg;
-            break;
-        case 'A':
-            autharg = optarg;
-            break;
-        }
+    FOREACH_OPT(opt, "au:A:", NULL, "tmem-shared-auth", 0) {
+    case 0: case 2:
+        return opt;
+    case 'a':
+        all = 1;
+        break;
+    case 'u':
+        uuid = optarg;
+        break;
+    case 'A':
+        autharg = optarg;
+        break;
     }
 
     dom = argv[optind];
@@ -5993,8 +6006,10 @@ int main_tmem_freeable(int argc, char **
     int opt;
     int mb;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "tmem-freeable", 0)) != -1)
+    FOREACH_OPT(opt, "", NULL, "tmem-freeale", 0) {
+    case 0: case 2:
         return opt;
+    }
 
     mb = libxl_tmem_freeable(ctx);
     if (mb == -1)
@@ -6033,17 +6048,15 @@ int main_cpupoolcreate(int argc, char **
     libxl_cputopology *topology;
     int rc = -ERROR_FAIL;
 
-    while ((opt = def_getopt(argc, argv, "hnf:", opts, "cpupool-create", 0)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        case 'f':
-            filename = optarg;
-            break;
-        case 'n':
-            dryrun_only = 1;
-            break;
-        }
+    FOREACH_OPT(opt, "hnf:", opts, "cpupool-create", 0) {
+    case 0: case 2:
+        return opt;
+    case 'f':
+        filename = optarg;
+        break;
+    case 'n':
+        dryrun_only = 1;
+        break;
     }
 
     memset(extra_config, 0, sizeof(extra_config));
@@ -6218,14 +6231,12 @@ int main_cpupoollist(int argc, char **ar
     char *name;
     int ret = 0;
 
-    while ((opt = def_getopt(argc, argv, "hc", opts, "cpupool-list", 1)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            break;
-        case 'c':
-            opt_cpus = 1;
-            break;
-        }
+    FOREACH_OPT(opt, "hc", opts, "cpupool-list", 1) {
+    case 0: case 2:
+        break;
+    case 'c':
+        opt_cpus = 1;
+        break;
     }
 
     if (optind < argc) {
@@ -6285,8 +6296,10 @@ int main_cpupooldestroy(int argc, char *
     const char *pool;
     uint32_t poolid;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "cpupool-destroy", 1)) != -1)
+    FOREACH_OPT(opt, "", NULL, "cpupool-destroy", 1) {
+    case 0: case 2:
         return opt;
+    }
 
     pool = argv[optind];
 
@@ -6306,8 +6319,10 @@ int main_cpupoolrename(int argc, char **
     const char *new_name;
     uint32_t poolid;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "cpupool-rename", 2)) != -1)
+    FOREACH_OPT(opt, "", NULL, "cpupool-rename", 2) {
+    case 0: case 2:
         return opt;
+    }
 
     pool = argv[optind++];
 
@@ -6336,8 +6351,10 @@ int main_cpupoolcpuadd(int argc, char **
     int node;
     int n;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "cpupool-cpu-add", 2)) != -1)
+    FOREACH_OPT(opt, "", NULL, "cpupool-cpu-add", 2) {
+    case 0: case 2:
         return opt;
+    }
 
     pool = argv[optind++];
     node = -1;
@@ -6380,8 +6397,10 @@ int main_cpupoolcpuremove(int argc, char
     int node;
     int n;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "cpupool-cpu-remove", 2)) != -1)
+    FOREACH_OPT(opt, "", NULL, "cpupool-cpu-remove", 2) {
+    case 0: case 2:
         return opt;
+    }
 
     pool = argv[optind++];
     node = -1;
@@ -6423,8 +6442,10 @@ int main_cpupoolmigrate(int argc, char *
     const char *dom;
     uint32_t domid;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "cpupool-migrate", 2)) != -1)
+    FOREACH_OPT(opt, "", NULL, "cpupool-migrate", 2) {
+    case 0: case 2:
         return opt;
+    }
 
     dom = argv[optind++];
     pool = argv[optind];
@@ -6463,8 +6484,11 @@ int main_cpupoolnumasplit(int argc, char
     libxl_cputopology *topology;
     libxl_dominfo info;
 
-    if ((opt = def_getopt(argc, argv, "", NULL, "cpupool-numa-split", 0)) != -1)
+    FOREACH_OPT(opt, "", NULL, "cpupool-numa-split", 0) {
+    case 0: case 2:
         return opt;
+    }
+
     ret = 0;
 
     poolinfo = libxl_list_cpupool(ctx, &n_pools);
@@ -6716,27 +6740,24 @@ int main_remus(int argc, char **argv)
     r_info.blackhole = 0;
     r_info.compression = 1;
 
-    while ((opt = def_getopt(argc, argv, "bui:s:e", NULL, "remus", 2)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-
-        case 'i':
-	    r_info.interval = atoi(optarg);
-            break;
-        case 'b':
-            r_info.blackhole = 1;
-            break;
-        case 'u':
-	    r_info.compression = 0;
-            break;
-        case 's':
-            ssh_command = optarg;
-            break;
-        case 'e':
-            daemonize = 0;
-            break;
-        }
+    FOREACH_OPT(opt, "bui:s:e", NULL, "remus", 2) {
+    case 0: case 2:
+        return opt;
+    case 'i':
+        r_info.interval = atoi(optarg);
+        break;
+    case 'b':
+        r_info.blackhole = 1;
+        break;
+    case 'u':
+        r_info.compression = 0;
+        break;
+    case 's':
+        ssh_command = optarg;
+        break;
+    case 'e':
+        daemonize = 0;
+        break;
     }
 
     domid = find_domain(argv[optind]);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 10:10:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 10:10:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNhcT-0000Px-7v; Mon, 15 Oct 2012 10:09:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TNhcR-0000Pm-Pf
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 10:09:55 +0000
Received: from [85.158.137.99:59848] by server-16.bemta-3.messagelabs.com id
	58/90-16565-2F0EB705; Mon, 15 Oct 2012 10:09:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1350295792!21494822!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYzNjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3818 invoked from network); 15 Oct 2012 10:09:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 10:09:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="41199645"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 10:09:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 06:09:50 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1TNhcM-0002h0-4d;
	Mon, 15 Oct 2012 11:09:50 +0100
MIME-Version: 1.0
Message-ID: <patchbomb.1350295789@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 15 Oct 2012 11:09:49 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com, linux@eikelenboom.it
Subject: [Xen-devel] [PATCH 0 of 5] xl shutdown compatibility with xm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The following implements xm compatibility for the xl shutdown command
and a prerequisite bug fix.

In particular add --all and --wait which are used by the xendomains
initscript. It also adds the same options to xl reboot.

Lastly it cleans up and simplifies option parsing.

The xl shutdown/reboot patches should go into 4.2.1, the option
parsing cleanups should not.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 10:10:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 10:10:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNhcV-0000QN-0n; Mon, 15 Oct 2012 10:09:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TNhcT-0000Ps-HK
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 10:09:57 +0000
Received: from [85.158.137.99:18893] by server-6.bemta-3.messagelabs.com id
	69/D8-32375-4F0EB705; Mon, 15 Oct 2012 10:09:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1350295792!21494822!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYzNjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3931 invoked from network); 15 Oct 2012 10:09:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 10:09:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="41199647"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 10:09:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 06:09:50 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1TNhcM-0002h0-6H;
	Mon, 15 Oct 2012 11:09:50 +0100
MIME-Version: 1.0
X-Mercurial-Node: 5a24315f39c035e5e5b773ebca676d5248a41252
Message-ID: <5a24315f39c035e5e5b7.1350295792@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1350295789@cosworth.uk.xensource.com>
References: <patchbomb.1350295789@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 15 Oct 2012 11:09:52 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com, linux@eikelenboom.it
Subject: [Xen-devel] [PATCH 3 of 5] xl: Add --wait and --all to xl reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Ian Campbell <ijc@hellion.org.uk>
# Date 1350295718 -3600
# Node ID 5a24315f39c035e5e5b773ebca676d5248a41252
# Parent  2329dca4ef449979b1403c4bb002fcb70c578b35
xl: Add --wait and --all to xl reboot.

Inspired by a patch by Sander Eikelenboom.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 2329dca4ef44 -r 5a24315f39c0 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Sep 06 21:41:27 2012 +0200
+++ b/tools/libxl/xl_cmdimpl.c	Mon Oct 15 11:08:38 2012 +0100
@@ -2716,7 +2716,7 @@ static void destroy_domain(uint32_t domi
 static void wait_for_domain_deaths(libxl_evgen_domain_death **deathws, int nr)
 {
     int rc, count = 0;
-    LOG("Waiting for %d domains to shutdown", nr);
+    LOG("Waiting for %d domains", nr);
     while(1 && count < nr) {
         libxl_event *event;
         rc = libxl_event_wait(ctx, &event, LIBXL_EVENTMASK_ALL, 0,0);
@@ -2776,15 +2776,15 @@ static void shutdown_domain(uint32_t dom
             fprintf(stderr,"wait for death failed (evgen, rc=%d)\n",rc);
             exit(-1);
         }
-        printf("Waiting for domain %d death %p %"PRIx64"\n",
-               domid, *deathw, for_user);
-    }
-}
-
-static void reboot_domain(uint32_t domid, int fallback_trigger)
+    }
+}
+
+static void reboot_domain(uint32_t domid, libxl_evgen_domain_death **deathw,
+                          libxl_ev_user for_user, int fallback_trigger)
 {
     int rc;
 
+    fprintf(stderr, "Rebooting domain %d\n", domid);
     rc=libxl_domain_reboot(ctx, domid);
     if (rc == ERROR_NOPARAVIRT) {
         if (fallback_trigger) {
@@ -2800,6 +2800,14 @@ static void reboot_domain(uint32_t domid
     if (rc) {
         fprintf(stderr,"reboot failed (rc=%d)\n",rc);exit(-1);
     }
+
+    if (deathw) {
+        rc = libxl_evenable_domain_death(ctx, domid, for_user, deathw);
+        if (rc) {
+            fprintf(stderr,"wait for death failed (evgen, rc=%d)\n",rc);
+            exit(-1);
+        }
+    }
 }
 
 static void list_domains_details(const libxl_dominfo *info, int nb_domain)
@@ -3713,8 +3721,11 @@ int main_destroy(int argc, char **argv)
     return 0;
 }
 
-int main_shutdown(int argc, char **argv)
-{
+static int main_shutdown_or_reboot(int reboot, int argc, char **argv)
+{
+    void (*fn)(uint32_t domid,
+               libxl_evgen_domain_death **, libxl_ev_user, int) =
+        reboot ? &reboot_domain : &shutdown_domain;
     int opt, i, nb_domain;
     int wait_for_it = 0, all =0;
     int fallback_trigger = 0;
@@ -3730,6 +3741,7 @@ int main_shutdown(int argc, char **argv)
             return opt;
         case 'a':
             all = 1;
+            break;
         case 'w':
             wait_for_it = 1;
             break;
@@ -3758,9 +3770,8 @@ int main_shutdown(int argc, char **argv)
         for (i = 0; i<nb_domain; i++) {
             if (dominfo[i].domid == 0)
                 continue;
-            shutdown_domain(dominfo[i].domid,
-                            deathws ? &deathws[i] : NULL, i,
-                            fallback_trigger);
+            fn(dominfo[i].domid, deathws ? &deathws[i] : NULL, i,
+               fallback_trigger);
         }
 
         wait_for_domain_deaths(deathws, nb_domain - 1 /* not dom 0 */);
@@ -3769,8 +3780,7 @@ int main_shutdown(int argc, char **argv)
         libxl_evgen_domain_death *deathw = NULL;
         uint32_t domid = find_domain(argv[optind]);
 
-        shutdown_domain(domid, wait_for_it ? &deathw : NULL, 0,
-                        fallback_trigger);
+        fn(domid, wait_for_it ? &deathw : NULL, 0, fallback_trigger);
 
         if (wait_for_it)
             wait_for_domain_deaths(&deathw, 1);
@@ -3780,23 +3790,14 @@ int main_shutdown(int argc, char **argv)
     return 0;
 }
 
+int main_shutdown(int argc, char **argv)
+{
+    return main_shutdown_or_reboot(0, argc, argv);
+}
+
 int main_reboot(int argc, char **argv)
 {
-    int opt;
-    int fallback_trigger = 0;
-
-    while ((opt = def_getopt(argc, argv, "F", "reboot", 1)) != -1) {
-        switch (opt) {
-        case 0: case 2:
-            return opt;
-        case 'F':
-            fallback_trigger = 1;
-            break;
-        }
-    }
-
-    reboot_domain(find_domain(argv[optind]), fallback_trigger);
-    return 0;
+    return main_shutdown_or_reboot(1, argc, argv);
 }
 
 int main_list(int argc, char **argv)
diff -r 2329dca4ef44 -r 5a24315f39c0 tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c	Thu Sep 06 21:41:27 2012 +0200
+++ b/tools/libxl/xl_cmdtable.c	Mon Oct 15 11:08:38 2012 +0100
@@ -70,10 +70,12 @@ struct cmd_spec cmd_table[] = {
     { "reboot",
       &main_reboot, 0, 1,
       "Issue a reboot signal to a domain",
-      "[options] <Domain>",
+      "[options] <-a|Domain>",
+      "-a, --all               Shutdown all guest domains.\n"
       "-h                      Print this help.\n"
       "-F                      Fallback to ACPI reset event for HVM guests with\n"
       "                        no PV drivers.\n"
+      "-w, --wait              Wait for guest(s) to reboot.\n"
     },
     { "pci-attach",
       &main_pciattach, 0, 1,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 10:10:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 10:10:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNhcZ-0000SK-7S; Mon, 15 Oct 2012 10:10:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TNhcW-0000Qe-1X
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 10:10:02 +0000
Received: from [85.158.137.99:60220] by server-3.bemta-3.messagelabs.com id
	BE/AB-09368-7F0EB705; Mon, 15 Oct 2012 10:09:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1350295794!21576414!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYzNjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5132 invoked from network); 15 Oct 2012 10:09:57 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 10:09:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="41199650"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 10:09:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 06:09:50 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1TNhcM-0002h0-6n;
	Mon, 15 Oct 2012 11:09:50 +0100
MIME-Version: 1.0
X-Mercurial-Node: bbb839ceb966cc265e5d2ca530ba0f2bf823176a
Message-ID: <bbb839ceb966cc265e5d.1350295793@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1350295789@cosworth.uk.xensource.com>
References: <patchbomb.1350295789@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 15 Oct 2012 11:09:53 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com, linux@eikelenboom.it
Subject: [Xen-devel] [PATCH 4 of 5] xl: allow def_getopt to handle long
	options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Ian Campbell <ijc@hellion.org.uk>
# Date 1350295719 -3600
# Node ID bbb839ceb966cc265e5d2ca530ba0f2bf823176a
# Parent  5a24315f39c035e5e5b773ebca676d5248a41252
xl: allow def_getopt to handle long options

Improves consistency of option parsing and error handling.

Consistently support --help for all options.

Many users of getopt_long were needlessly passing an option_index
pointer which was not used.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 5a24315f39c0 -r bbb839ceb966 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Oct 15 11:08:38 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Mon Oct 15 11:08:39 2012 +0100
@@ -2241,19 +2241,34 @@ static int64_t parse_mem_size_kb(const c
     return kbytes;
 }
 
-static int def_getopt(int argc, char * const argv[], const char *optstring,
+#define COMMON_LONG_OPTS {"help", 0, 0, 'h'}
+
+static int def_getopt(int argc, char * const argv[],
+                      const char *optstring,
+                      const struct option *longopts,
                       const char* helpstr, int reqargs)
 {
     int opt;
+    const struct option def_options[] = {
+        COMMON_LONG_OPTS,
+        {0, 0, 0, 0}
+    };
+
+    if (!longopts)
+        longopts = def_options;
 
     opterr = 0;
-    while ((opt = getopt(argc, argv, optstring)) == '?') {
+    while ((opt = getopt_long(argc, argv, optstring, longopts, NULL)) == '?') {
         if (optopt == 'h') {
             help(helpstr);
             return 0;
         }
         fprintf(stderr, "option `%c' not supported.\n", optopt);
     }
+    if (opt == 'h') {
+        help(helpstr);
+        return 0;
+    }
     if (opt != -1)
         return opt;
 
@@ -2289,7 +2304,7 @@ int main_memmax(int argc, char **argv)
     char *mem;
     int rc;
 
-    if ((opt = def_getopt(argc, argv, "", "mem-max", 2)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "mem-max", 2)) != -1)
         return opt;
 
     domid = find_domain(argv[optind]);
@@ -2323,7 +2338,7 @@ int main_memset(int argc, char **argv)
     int opt = 0;
     const char *mem;
 
-    if ((opt = def_getopt(argc, argv, "", "mem-set", 2)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "mem-set", 2)) != -1)
         return opt;
 
     domid = find_domain(argv[optind]);
@@ -2362,7 +2377,7 @@ int main_cd_eject(int argc, char **argv)
     int opt = 0;
     const char *virtdev;
 
-    if ((opt = def_getopt(argc, argv, "", "cd-eject", 2)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "cd-eject", 2)) != -1)
         return opt;
 
     domid = find_domain(argv[optind]);
@@ -2379,7 +2394,7 @@ int main_cd_insert(int argc, char **argv
     const char *virtdev;
     char *file = NULL; /* modified by cd_insert tokenising it */
 
-    if ((opt = def_getopt(argc, argv, "", "cd-insert", 3)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "cd-insert", 3)) != -1)
         return opt;
 
     domid = find_domain(argv[optind]);
@@ -2396,7 +2411,7 @@ int main_console(int argc, char **argv)
     int opt = 0, num = 0;
     libxl_console_type type = 0;
 
-    while ((opt = def_getopt(argc, argv, "n:t:", "console", 1)) != -1) {
+    while ((opt = def_getopt(argc, argv, "n:t:", NULL, "console", 1)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
@@ -2427,36 +2442,23 @@ int main_console(int argc, char **argv)
 
 int main_vncviewer(int argc, char **argv)
 {
-    static const struct option long_options[] = {
+    static const struct option opts[] = {
         {"autopass", 0, 0, 'a'},
         {"vncviewer-autopass", 0, 0, 'a'},
-        {"help", 0, 0, 'h'},
+        COMMON_LONG_OPTS,
         {0, 0, 0, 0}
     };
     uint32_t domid;
     int opt, autopass = 0;
 
-    while (1) {
-        opt = getopt_long(argc, argv, "ah", long_options, NULL);
-        if (opt == -1)
-            break;
-
+    while ((opt = def_getopt(argc, argv, "ah", opts, "vncviewer", 1)) != -1) {
         switch (opt) {
+        case 0: case 2:
+            return opt;
         case 'a':
             autopass = 1;
             break;
-        case 'h':
-            help("vncviewer");
-            return 0;
-        default:
-            fprintf(stderr, "option `%c' not supported.\n", optopt);
-            break;
-        }
-    }
-
-    if (argc - optind != 1) {
-        help("vncviewer");
-        return 2;
+        }
     }
 
     domid = find_domain(argv[optind]);
@@ -2489,7 +2491,7 @@ int main_pcilist(int argc, char **argv)
     uint32_t domid;
     int opt;
 
-    if ((opt = def_getopt(argc, argv, "", "pci-list", 1)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "pci-list", 1)) != -1)
         return opt;
 
     domid = find_domain(argv[optind]);
@@ -2528,7 +2530,7 @@ int main_pcidetach(int argc, char **argv
     int force = 0;
     const char *bdf = NULL;
 
-    while ((opt = def_getopt(argc, argv, "f", "pci-detach", 2)) != -1) {
+    while ((opt = def_getopt(argc, argv, "f", NULL, "pci-detach", 2)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
@@ -2570,7 +2572,7 @@ int main_pciattach(int argc, char **argv
     int opt;
     const char *bdf = NULL, *vs = NULL;
 
-    if ((opt = def_getopt(argc, argv, "", "pci-attach", 2)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "pci-attach", 2)) != -1)
         return opt;
 
     domid = find_domain(argv[optind]);
@@ -2604,7 +2606,7 @@ int main_pciassignable_list(int argc, ch
 {
     int opt;
 
-    if ((opt = def_getopt(argc, argv, "", "pci-assignable-list", 0)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "pci-assignable-list", 0)) != -1)
         return opt;
 
     pciassignable_list();
@@ -2636,7 +2638,7 @@ int main_pciassignable_add(int argc, cha
     int opt;
     const char *bdf = NULL;
 
-    while ((opt = def_getopt(argc, argv, "", "pci-assignable-add", 1)) != -1) {
+    while ((opt = def_getopt(argc, argv, "", NULL, "pci-assignable-add", 1)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
@@ -2675,7 +2677,7 @@ int main_pciassignable_remove(int argc, 
     const char *bdf = NULL;
     int rebind = 0;
 
-    while ((opt = def_getopt(argc, argv, "r", "pci-assignable-remove", 1)) != -1) {
+    while ((opt = def_getopt(argc, argv, "r", NULL, "pci-assignable-remove", 1)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
@@ -3486,24 +3488,18 @@ int main_restore(int argc, char **argv)
     int paused = 0, debug = 0, daemonize = 1, monitor = 1,
         console_autoconnect = 0, vnc = 0, vncautopass = 0;
     int opt, rc;
-    int option_index = 0;
-    static struct option long_options[] = {
+    static struct option opts[] = {
         {"vncviewer", 0, 0, 'V'},
         {"vncviewer-autopass", 0, 0, 'A'},
+        COMMON_LONG_OPTS,
         {0, 0, 0, 0}
     };
 
-    while (1) {
-        opt = getopt_long(argc, argv, "FhcpdeVA", long_options, &option_index);
-        if (opt == -1)
-            break;
-
+    while ((opt = def_getopt(argc, argv, "FhcpdeVA",
+                             opts, "restore", 1)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
-        case 'h':
-            help("restore");
-            return 2;
         case 'c':
             console_autoconnect = 1;
             break;
@@ -3563,7 +3559,7 @@ int main_migrate_receive(int argc, char 
     int debug = 0, daemonize = 1, monitor = 1, remus = 0;
     int opt;
 
-    while ((opt = def_getopt(argc, argv, "Fedr", "migrate-receive", 0)) != -1) {
+    while ((opt = def_getopt(argc, argv, "Fedr", NULL, "migrate-receive", 0)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
@@ -3602,7 +3598,7 @@ int main_save(int argc, char **argv)
     int checkpoint = 0;
     int opt;
 
-    while ((opt = def_getopt(argc, argv, "c", "save", 2)) != -1) {
+    while ((opt = def_getopt(argc, argv, "c", NULL, "save", 2)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
@@ -3635,7 +3631,7 @@ int main_migrate(int argc, char **argv)
     char *host;
     int opt, daemonize = 1, monitor = 1, debug = 0;
 
-    while ((opt = def_getopt(argc, argv, "FC:s:ed", "migrate", 2)) != -1) {
+    while ((opt = def_getopt(argc, argv, "FC:s:ed", NULL, "migrate", 2)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
@@ -3679,7 +3675,7 @@ int main_dump_core(int argc, char **argv
 {
     int opt;
 
-    if ((opt = def_getopt(argc, argv, "", "dump-core", 2)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "dump-core", 2)) != -1)
         return opt;
 
     core_dump_domain(find_domain(argv[optind]), argv[optind + 1]);
@@ -3690,7 +3686,7 @@ int main_pause(int argc, char **argv)
 {
     int opt;
 
-    if ((opt = def_getopt(argc, argv, "", "pause", 1)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "pause", 1)) != -1)
         return opt;
 
     pause_domain(find_domain(argv[optind]));
@@ -3702,7 +3698,7 @@ int main_unpause(int argc, char **argv)
 {
     int opt;
 
-    if ((opt = def_getopt(argc, argv, "", "unpause", 1)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "unpause", 1)) != -1)
         return opt;
 
     unpause_domain(find_domain(argv[optind]));
@@ -3714,7 +3710,7 @@ int main_destroy(int argc, char **argv)
 {
     int opt;
 
-    if ((opt = def_getopt(argc, argv, "", "destroy", 1)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "destroy", 1)) != -1)
         return opt;
 
     destroy_domain(find_domain(argv[optind]));
@@ -3723,19 +3719,21 @@ int main_destroy(int argc, char **argv)
 
 static int main_shutdown_or_reboot(int reboot, int argc, char **argv)
 {
+    const char *what = reboot ? "reboot" : "shutdown";
     void (*fn)(uint32_t domid,
                libxl_evgen_domain_death **, libxl_ev_user, int) =
         reboot ? &reboot_domain : &shutdown_domain;
     int opt, i, nb_domain;
     int wait_for_it = 0, all =0;
     int fallback_trigger = 0;
-    static struct option long_options[] = {
+    static struct option opts[] = {
         {"all", 0, 0, 'a'},
         {"wait", 0, 0, 'w'},
+        COMMON_LONG_OPTS,
         {0, 0, 0, 0}
     };
 
-    while ((opt = getopt_long(argc, argv, "awF", long_options, NULL)) != -1) {
+    while ((opt = def_getopt(argc, argv, "awF", opts, what, 0)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
@@ -3805,12 +3803,11 @@ int main_list(int argc, char **argv)
     int opt, verbose = 0;
     int context = 0;
     int details = 0;
-    int option_index = 0;
-    static struct option long_options[] = {
+    static struct option opts[] = {
         {"long", 0, 0, 'l'},
-        {"help", 0, 0, 'h'},
         {"verbose", 0, 0, 'v'},
         {"context", 0, 0, 'Z'},
+        COMMON_LONG_OPTS,
         {0, 0, 0, 0}
     };
 
@@ -3818,12 +3815,10 @@ int main_list(int argc, char **argv)
     libxl_dominfo *info, *info_free=0;
     int nb_domain, rc;
 
-    while (1) {
-        opt = getopt_long(argc, argv, "lvhZ", long_options, &option_index);
-        if (opt == -1)
-            break;
-
+    while ((opt = def_getopt(argc, argv, "lvhZ", opts, "list", 0)) != -1) {
         switch (opt) {
+        case 0: case 2:
+            return opt;
         case 'l':
             details = 1;
             break;
@@ -3836,9 +3831,6 @@ int main_list(int argc, char **argv)
         case 'Z':
             context = 1;
             break;
-        default:
-            fprintf(stderr, "option `%c' not supported.\n", optopt);
-            break;
         }
     }
 
@@ -3885,7 +3877,7 @@ int main_vm_list(int argc, char **argv)
 {
     int opt;
 
-    if ((opt = def_getopt(argc, argv, "", "vm-list", 0)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "vm-list", 0)) != -1)
         return opt;
 
     list_vm();
@@ -3901,14 +3893,13 @@ int main_create(int argc, char **argv)
     int paused = 0, debug = 0, daemonize = 1, console_autoconnect = 0,
         quiet = 0, monitor = 1, vnc = 0, vncautopass = 0;
     int opt, rc;
-    int option_index = 0;
-    static struct option long_options[] = {
+    static struct option opts[] = {
         {"dryrun", 0, 0, 'n'},
         {"quiet", 0, 0, 'q'},
-        {"help", 0, 0, 'h'},
         {"defconfig", 1, 0, 'f'},
         {"vncviewer", 0, 0, 'V'},
         {"vncviewer-autopass", 0, 0, 'A'},
+        COMMON_LONG_OPTS,
         {0, 0, 0, 0}
     };
 
@@ -3917,12 +3908,10 @@ int main_create(int argc, char **argv)
         argc--; argv++;
     }
 
-    while (1) {
-        opt = getopt_long(argc, argv, "Fhnqf:pcdeVA", long_options, &option_index);
-        if (opt == -1)
-            break;
-
+    while ((opt = def_getopt(argc, argv, "Fhnqf:pcdeVA", opts, "create", 0)) != -1) {
         switch (opt) {
+        case 0: case 2:
+            return opt;
         case 'f':
             filename = optarg;
             break;
@@ -3957,9 +3946,6 @@ int main_create(int argc, char **argv)
         case 'A':
             vnc = vncautopass = 1;
             break;
-        default:
-            fprintf(stderr, "option `%c' not supported.\n", optopt);
-            break;
         }
     }
 
@@ -4007,11 +3993,10 @@ int main_config_update(int argc, char **
     int config_len = 0;
     libxl_domain_config d_config;
     int opt, rc;
-    int option_index = 0;
     int debug = 0;
-    static struct option long_options[] = {
-        {"help", 0, 0, 'h'},
+    static struct option opts[] = {
         {"defconfig", 1, 0, 'f'},
+        COMMON_LONG_OPTS,
         {0, 0, 0, 0}
     };
 
@@ -4029,24 +4014,16 @@ int main_config_update(int argc, char **
         argc--; argv++;
     }
 
-    while (1) {
-        opt = getopt_long(argc, argv, "dhqf:", long_options, &option_index);
-        if (opt == -1)
-            break;
-
+    while ((opt = def_getopt(argc, argv, "dhqf:", opts, "config_update", 0)) != -1) {
         switch (opt) {
+        case 0: case 2:
+            return opt;
         case 'd':
             debug = 1;
             break;
         case 'f':
             filename = optarg;
             break;
-        case 'h':
-            help("create");
-            return 0;
-        default:
-            fprintf(stderr, "option `%c' not supported.\n", optopt);
-            break;
         }
     }
 
@@ -4135,7 +4112,7 @@ int main_button_press(int argc, char **a
     fprintf(stderr, "WARNING: \"button-press\" is deprecated. "
             "Please use \"trigger\"\n");
 
-    if ((opt = def_getopt(argc, argv, "", "button-press", 2)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "button-press", 2)) != -1)
         return opt;
 
     button_press(find_domain(argv[optind]), argv[optind + 1]);
@@ -4276,7 +4253,7 @@ int main_vcpulist(int argc, char **argv)
 {
     int opt;
 
-    if ((opt = def_getopt(argc, argv, "", "cpu-list", 0)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "cpu-list", 0)) != -1)
         return opt;
 
     vcpulist(argc - optind, argv + optind);
@@ -4337,7 +4314,7 @@ int main_vcpupin(int argc, char **argv)
 {
     int opt;
 
-    if ((opt = def_getopt(argc, argv, "", "vcpu-pin", 3)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "vcpu-pin", 3)) != -1)
         return opt;
 
     vcpupin(find_domain(argv[optind]), argv[optind+1] , argv[optind+2]);
@@ -4373,7 +4350,7 @@ int main_vcpuset(int argc, char **argv)
 {
     int opt;
 
-    if ((opt = def_getopt(argc, argv, "", "vcpu-set", 2)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "vcpu-set", 2)) != -1)
         return opt;
 
     vcpuset(find_domain(argv[optind]), argv[optind+1]);
@@ -4549,25 +4526,20 @@ static void print_info(int numa)
 int main_info(int argc, char **argv)
 {
     int opt;
-    int option_index = 0;
-    static struct option long_options[] = {
-        {"help", 0, 0, 'h'},
+    static struct option opts[] = {
         {"numa", 0, 0, 'n'},
+        COMMON_LONG_OPTS,
         {0, 0, 0, 0}
     };
     int numa = 0;
 
-    while ((opt = getopt_long(argc, argv, "hn", long_options, &option_index)) != -1) {
+    while ((opt = def_getopt(argc, argv, "hn", opts, "info", 0)) != -1) {
         switch (opt) {
-        case 'h':
-            help("info");
-            return 0;
+        case 0: case 2:
+            return opt;
         case 'n':
             numa = 1;
             break;
-        default:
-            fprintf(stderr, "option `%c' not supported.\n", optopt);
-            break;
         }
     }
 
@@ -4602,7 +4574,7 @@ int main_sharing(int argc, char **argv)
     libxl_dominfo *info, *info_free = NULL;
     int nb_domain, rc;
 
-    if ((opt = def_getopt(argc, argv, "", "sharing", 0)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "sharing", 0)) != -1)
         return opt;
 
     if (optind >= argc) {
@@ -4871,8 +4843,7 @@ int main_sched_credit(int argc, char **a
     int opt_s = 0;
     int tslice = 0, opt_t = 0, ratelimit = 0, opt_r = 0;
     int opt, rc;
-    int option_index = 0;
-    static struct option long_options[] = {
+    static struct option opts[] = {
         {"domain", 1, 0, 'd'},
         {"weight", 1, 0, 'w'},
         {"cap", 1, 0, 'c'},
@@ -4880,15 +4851,11 @@ int main_sched_credit(int argc, char **a
         {"tslice_ms", 1, 0, 't'},
         {"ratelimit_us", 1, 0, 'r'},
         {"cpupool", 1, 0, 'p'},
-        {"help", 0, 0, 'h'},
+        COMMON_LONG_OPTS,
         {0, 0, 0, 0}
     };
 
-    while (1) {
-        opt = getopt_long(argc, argv, "d:w:c:p:t:r:hs", long_options,
-                          &option_index);
-        if (opt == -1)
-            break;
+    while ((opt = def_getopt(argc, argv, "d:w:c:p:t:r:hs", opts, "sched-credit", 0)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
@@ -4917,9 +4884,6 @@ int main_sched_credit(int argc, char **a
         case 'p':
             cpupool = optarg;
             break;
-        case 'h':
-            help("sched-credit");
-            return 0;
         }
     }
 
@@ -5002,19 +4966,15 @@ int main_sched_credit2(int argc, char **
     const char *cpupool = NULL;
     int weight = 256, opt_w = 0;
     int opt, rc;
-    int option_index = 0;
-    static struct option long_options[] = {
+    static struct option opts[] = {
         {"domain", 1, 0, 'd'},
         {"weight", 1, 0, 'w'},
         {"cpupool", 1, 0, 'p'},
-        {"help", 0, 0, 'h'},
+        COMMON_LONG_OPTS,
         {0, 0, 0, 0}
     };
 
-    while (1) {
-        opt = getopt_long(argc, argv, "d:w:p:h", long_options, &option_index);
-        if (opt == -1)
-            break;
+    while ((opt = def_getopt(argc, argv, "d:w:p:h", opts, "sched-credit2", 0)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
@@ -5028,9 +4988,6 @@ int main_sched_credit2(int argc, char **
         case 'p':
             cpupool = optarg;
             break;
-        case 'h':
-            help("sched-credit");
-            return 0;
         }
     }
 
@@ -5081,23 +5038,18 @@ int main_sched_sedf(int argc, char **arg
     int extra = 0, opt_e = 0;
     int weight = 0, opt_w = 0;
     int opt, rc;
-    int option_index = 0;
-    static struct option long_options[] = {
+    static struct option opts[] = {
         {"period", 1, 0, 'p'},
         {"slice", 1, 0, 's'},
         {"latency", 1, 0, 'l'},
         {"extra", 1, 0, 'e'},
         {"weight", 1, 0, 'w'},
         {"cpupool", 1, 0, 'c'},
-        {"help", 0, 0, 'h'},
+        COMMON_LONG_OPTS,
         {0, 0, 0, 0}
     };
 
-    while (1) {
-        opt = getopt_long(argc, argv, "d:p:s:l:e:w:c:h", long_options,
-                          &option_index);
-        if (opt == -1)
-            break;
+    while ((opt = def_getopt(argc, argv, "d:p:s:l:e:w:c:h", opts, "sched-sedf", 0)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
@@ -5127,9 +5079,6 @@ int main_sched_sedf(int argc, char **arg
         case 'c':
             cpupool = optarg;
             break;
-        case 'h':
-            help("sched-sedf");
-            return 0;
         }
     }
 
@@ -5197,7 +5146,7 @@ int main_domid(int argc, char **argv)
     int opt;
     const char *domname = NULL;
 
-    if ((opt = def_getopt(argc, argv, "", "domid", 1)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "domid", 1)) != -1)
         return opt;
 
     domname = argv[optind];
@@ -5219,7 +5168,7 @@ int main_domname(int argc, char **argv)
     char *domname = NULL;
     char *endptr = NULL;
 
-    if ((opt = def_getopt(argc, argv, "", "domname", 1)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "domname", 1)) != -1)
         return opt;
 
     domid = strtol(argv[optind], &endptr, 10);
@@ -5247,7 +5196,7 @@ int main_rename(int argc, char **argv)
     int opt;
     const char *dom, *new_name;
 
-    if ((opt = def_getopt(argc, argv, "", "rename", 2)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "rename", 2)) != -1)
         return opt;
 
     dom = argv[optind++];
@@ -5271,7 +5220,7 @@ int main_trigger(int argc, char **argv)
     const char *trigger_name = NULL;
     libxl_trigger trigger;
 
-    if ((opt = def_getopt(argc, argv, "", "trigger", 2)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "trigger", 2)) != -1)
         return opt;
 
     domid = find_domain(argv[optind++]);
@@ -5301,7 +5250,7 @@ int main_sysrq(int argc, char **argv)
     int opt;
     const char *sysrq = NULL;
 
-    if ((opt = def_getopt(argc, argv, "", "sysrq", 2)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "sysrq", 2)) != -1)
         return opt;
 
     domid = find_domain(argv[optind++]);
@@ -5324,7 +5273,7 @@ int main_debug_keys(int argc, char **arg
     int opt;
     char *keys;
 
-    if ((opt = def_getopt(argc, argv, "", "debug-keys", 1)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "debug-keys", 1)) != -1)
         return opt;
 
     keys = argv[optind];
@@ -5344,7 +5293,7 @@ int main_dmesg(int argc, char **argv)
     char *line;
     int opt, ret = 1;
 
-    while ((opt = def_getopt(argc, argv, "c", "dmesg", 0)) != -1) {
+    while ((opt = def_getopt(argc, argv, "c", NULL, "dmesg", 0)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
@@ -5370,7 +5319,7 @@ int main_top(int argc, char **argv)
 {
     int opt;
 
-    if ((opt = def_getopt(argc, argv, "", "top", 0)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "top", 0)) != -1)
         return opt;
 
     return system("xentop");
@@ -5387,7 +5336,7 @@ int main_networkattach(int argc, char **
     int i;
     unsigned int val;
 
-    if ((opt = def_getopt(argc, argv, "", "network-attach", 1)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "network-attach", 1)) != -1)
         return opt;
 
     if (argc-optind > 11) {
@@ -5474,7 +5423,7 @@ int main_networklist(int argc, char **ar
     libxl_nicinfo nicinfo;
     int nb, i;
 
-    if ((opt = def_getopt(argc, argv, "", "network-list", 1)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "network-list", 1)) != -1)
         return opt;
 
     /*      Idx  BE   MAC   Hdl  Sta  evch txr/rxr  BE-path */
@@ -5511,7 +5460,7 @@ int main_networkdetach(int argc, char **
     int opt;
     libxl_device_nic nic;
 
-    if ((opt = def_getopt(argc, argv, "", "network-detach", 2)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "network-detach", 2)) != -1)
         return opt;
 
     domid = find_domain(argv[optind]);
@@ -5542,7 +5491,7 @@ int main_blockattach(int argc, char **ar
     libxl_device_disk disk = { 0 };
     XLU_Config *config = 0;
 
-    if ((opt = def_getopt(argc, argv, "", "block-attach", 2)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "block-attach", 2)) != -1)
         return opt;
 
     if (domain_qualifier_to_domid(argv[optind], &fe_domid, 0) < 0) {
@@ -5577,7 +5526,7 @@ int main_blocklist(int argc, char **argv
     libxl_device_disk *disks;
     libxl_diskinfo diskinfo;
 
-    if ((opt = def_getopt(argc, argv, "", "block-list", 1)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "block-list", 1)) != -1)
         return opt;
 
     printf("%-5s %-3s %-6s %-5s %-6s %-8s %-30s\n",
@@ -5613,7 +5562,7 @@ int main_blockdetach(int argc, char **ar
     int opt, rc = 0;
     libxl_device_disk disk;
 
-    if ((opt = def_getopt(argc, argv, "", "block-detach", 2)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "block-detach", 2)) != -1)
         return opt;
 
     domid = find_domain(argv[optind]);
@@ -5797,7 +5746,7 @@ int main_uptime(int argc, char **argv)
     int nb_doms = 0;
     int opt;
 
-    while ((opt = def_getopt(argc, argv, "s", "uptime", 1)) != -1) {
+    while ((opt = def_getopt(argc, argv, "s", NULL, "uptime", 1)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
@@ -5824,7 +5773,7 @@ int main_tmem_list(int argc, char **argv
     int all = 0;
     int opt;
 
-    while ((opt = def_getopt(argc, argv, "al", "tmem-list", 0)) != -1) {
+    while ((opt = def_getopt(argc, argv, "al", NULL, "tmem-list", 0)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
@@ -5865,7 +5814,7 @@ int main_tmem_freeze(int argc, char **ar
     int all = 0;
     int opt;
 
-    while ((opt = def_getopt(argc, argv, "a", "tmem-freeze", 0)) != -1) {
+    while ((opt = def_getopt(argc, argv, "a", NULL, "tmem-freeze", 0)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
@@ -5898,7 +5847,7 @@ int main_tmem_thaw(int argc, char **argv
     int all = 0;
     int opt;
 
-    while ((opt = def_getopt(argc, argv, "a", "tmem-thaw", 0)) != -1) {
+    while ((opt = def_getopt(argc, argv, "a", NULL, "tmem-thaw", 0)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
@@ -5933,7 +5882,7 @@ int main_tmem_set(int argc, char **argv)
     int all = 0;
     int opt;
 
-    while ((opt = def_getopt(argc, argv, "aw:c:p:", "tmem-set", 0)) != -1) {
+    while ((opt = def_getopt(argc, argv, "aw:c:p:", NULL, "tmem-set", 0)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
@@ -5994,7 +5943,7 @@ int main_tmem_shared_auth(int argc, char
     int all = 0;
     int opt;
 
-    while ((opt = def_getopt(argc, argv, "au:A:", "tmem-shared-auth", 0)) != -1) {
+    while ((opt = def_getopt(argc, argv, "au:A:", NULL, "tmem-shared-auth", 0)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
@@ -6044,7 +5993,7 @@ int main_tmem_freeable(int argc, char **
     int opt;
     int mb;
 
-    if ((opt = def_getopt(argc, argv, "", "tmem-freeable", 0)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "tmem-freeable", 0)) != -1)
         return opt;
 
     mb = libxl_tmem_freeable(ctx);
@@ -6061,11 +6010,10 @@ int main_cpupoolcreate(int argc, char **
     const char *p;
     char extra_config[1024];
     int opt;
-    int option_index = 0;
-    static struct option long_options[] = {
-        {"help", 0, 0, 'h'},
+    static struct option opts[] = {
         {"defconfig", 1, 0, 'f'},
         {"dryrun", 0, 0, 'n'},
+        COMMON_LONG_OPTS,
         {0, 0, 0, 0}
     };
     int ret;
@@ -6083,26 +6031,18 @@ int main_cpupoolcreate(int argc, char **
     libxl_bitmap cpumap;
     libxl_uuid uuid;
     libxl_cputopology *topology;
-    int rc = -ERROR_FAIL; 
-
-    while (1) {
-        opt = getopt_long(argc, argv, "hnf:", long_options, &option_index);
-        if (opt == -1)
-            break;
-
+    int rc = -ERROR_FAIL;
+
+    while ((opt = def_getopt(argc, argv, "hnf:", opts, "cpupool-create", 0)) != -1) {
         switch (opt) {
+        case 0: case 2:
+            return opt;
         case 'f':
             filename = optarg;
             break;
-        case 'h':
-            help("cpupool-create");
-            return 0;
         case 'n':
             dryrun_only = 1;
             break;
-        default:
-            fprintf(stderr, "option `%c' not supported.\n", optopt);
-            break;
         }
     }
 
@@ -6265,10 +6205,9 @@ out:
 int main_cpupoollist(int argc, char **argv)
 {
     int opt;
-    int option_index = 0;
-    static struct option long_options[] = {
-        {"help", 0, 0, 'h'},
+    static struct option opts[] = {
         {"cpus", 0, 0, 'c'},
+        COMMON_LONG_OPTS,
         {0, 0, 0, 0}
     };
     int opt_cpus = 0;
@@ -6279,28 +6218,16 @@ int main_cpupoollist(int argc, char **ar
     char *name;
     int ret = 0;
 
-    while (1) {
-        opt = getopt_long(argc, argv, "hc", long_options, &option_index);
-        if (opt == -1)
+    while ((opt = def_getopt(argc, argv, "hc", opts, "cpupool-list", 1)) != -1) {
+        switch (opt) {
+        case 0: case 2:
             break;
-
-        switch (opt) {
-        case 'h':
-            help("cpupool-list");
-            return 0;
         case 'c':
             opt_cpus = 1;
             break;
-        default:
-            fprintf(stderr, "option `%c' not supported.\n", optopt);
-            break;
-        }
-    }
-
-    if ((optind + 1) < argc) {
-        help("cpupool-list");
-        return -ERROR_FAIL;
-    }
+        }
+    }
+
     if (optind < argc) {
         pool = argv[optind];
         if (libxl_name_to_cpupoolid(ctx, pool, &poolid)) {
@@ -6358,7 +6285,7 @@ int main_cpupooldestroy(int argc, char *
     const char *pool;
     uint32_t poolid;
 
-    if ((opt = def_getopt(argc, argv, "", "cpupool-destroy", 1)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "cpupool-destroy", 1)) != -1)
         return opt;
 
     pool = argv[optind];
@@ -6379,7 +6306,7 @@ int main_cpupoolrename(int argc, char **
     const char *new_name;
     uint32_t poolid;
 
-    if ((opt = def_getopt(argc, argv, "", "cpupool-rename", 2)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "cpupool-rename", 2)) != -1)
         return opt;
 
     pool = argv[optind++];
@@ -6409,7 +6336,7 @@ int main_cpupoolcpuadd(int argc, char **
     int node;
     int n;
 
-    if ((opt = def_getopt(argc, argv, "", "cpupool-cpu-add", 2)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "cpupool-cpu-add", 2)) != -1)
         return opt;
 
     pool = argv[optind++];
@@ -6453,7 +6380,7 @@ int main_cpupoolcpuremove(int argc, char
     int node;
     int n;
 
-    if ((opt = def_getopt(argc, argv, "", "cpupool-cpu-remove", 2)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "cpupool-cpu-remove", 2)) != -1)
         return opt;
 
     pool = argv[optind++];
@@ -6496,7 +6423,7 @@ int main_cpupoolmigrate(int argc, char *
     const char *dom;
     uint32_t domid;
 
-    if ((opt = def_getopt(argc, argv, "", "cpupool-migrate", 2)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "cpupool-migrate", 2)) != -1)
         return opt;
 
     dom = argv[optind++];
@@ -6536,7 +6463,7 @@ int main_cpupoolnumasplit(int argc, char
     libxl_cputopology *topology;
     libxl_dominfo info;
 
-    if ((opt = def_getopt(argc, argv, "", "cpupool-numa-split", 0)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "cpupool-numa-split", 0)) != -1)
         return opt;
     ret = 0;
 
@@ -6789,7 +6716,7 @@ int main_remus(int argc, char **argv)
     r_info.blackhole = 0;
     r_info.compression = 1;
 
-    while ((opt = def_getopt(argc, argv, "bui:s:e", "remus", 2)) != -1) {
+    while ((opt = def_getopt(argc, argv, "bui:s:e", NULL, "remus", 2)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 10:10:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 10:10:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNhcZ-0000SK-7S; Mon, 15 Oct 2012 10:10:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TNhcW-0000Qe-1X
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 10:10:02 +0000
Received: from [85.158.137.99:60220] by server-3.bemta-3.messagelabs.com id
	BE/AB-09368-7F0EB705; Mon, 15 Oct 2012 10:09:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1350295794!21576414!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYzNjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5132 invoked from network); 15 Oct 2012 10:09:57 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 10:09:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="41199650"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 10:09:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 06:09:50 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1TNhcM-0002h0-6n;
	Mon, 15 Oct 2012 11:09:50 +0100
MIME-Version: 1.0
X-Mercurial-Node: bbb839ceb966cc265e5d2ca530ba0f2bf823176a
Message-ID: <bbb839ceb966cc265e5d.1350295793@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1350295789@cosworth.uk.xensource.com>
References: <patchbomb.1350295789@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 15 Oct 2012 11:09:53 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com, linux@eikelenboom.it
Subject: [Xen-devel] [PATCH 4 of 5] xl: allow def_getopt to handle long
	options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Ian Campbell <ijc@hellion.org.uk>
# Date 1350295719 -3600
# Node ID bbb839ceb966cc265e5d2ca530ba0f2bf823176a
# Parent  5a24315f39c035e5e5b773ebca676d5248a41252
xl: allow def_getopt to handle long options

Improves consistency of option parsing and error handling.

Consistently support --help for all options.

Many users of getopt_long were needlessly passing an option_index
pointer which was not used.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 5a24315f39c0 -r bbb839ceb966 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Oct 15 11:08:38 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Mon Oct 15 11:08:39 2012 +0100
@@ -2241,19 +2241,34 @@ static int64_t parse_mem_size_kb(const c
     return kbytes;
 }
 
-static int def_getopt(int argc, char * const argv[], const char *optstring,
+#define COMMON_LONG_OPTS {"help", 0, 0, 'h'}
+
+static int def_getopt(int argc, char * const argv[],
+                      const char *optstring,
+                      const struct option *longopts,
                       const char* helpstr, int reqargs)
 {
     int opt;
+    const struct option def_options[] = {
+        COMMON_LONG_OPTS,
+        {0, 0, 0, 0}
+    };
+
+    if (!longopts)
+        longopts = def_options;
 
     opterr = 0;
-    while ((opt = getopt(argc, argv, optstring)) == '?') {
+    while ((opt = getopt_long(argc, argv, optstring, longopts, NULL)) == '?') {
         if (optopt == 'h') {
             help(helpstr);
             return 0;
         }
         fprintf(stderr, "option `%c' not supported.\n", optopt);
     }
+    if (opt == 'h') {
+        help(helpstr);
+        return 0;
+    }
     if (opt != -1)
         return opt;
 
@@ -2289,7 +2304,7 @@ int main_memmax(int argc, char **argv)
     char *mem;
     int rc;
 
-    if ((opt = def_getopt(argc, argv, "", "mem-max", 2)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "mem-max", 2)) != -1)
         return opt;
 
     domid = find_domain(argv[optind]);
@@ -2323,7 +2338,7 @@ int main_memset(int argc, char **argv)
     int opt = 0;
     const char *mem;
 
-    if ((opt = def_getopt(argc, argv, "", "mem-set", 2)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "mem-set", 2)) != -1)
         return opt;
 
     domid = find_domain(argv[optind]);
@@ -2362,7 +2377,7 @@ int main_cd_eject(int argc, char **argv)
     int opt = 0;
     const char *virtdev;
 
-    if ((opt = def_getopt(argc, argv, "", "cd-eject", 2)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "cd-eject", 2)) != -1)
         return opt;
 
     domid = find_domain(argv[optind]);
@@ -2379,7 +2394,7 @@ int main_cd_insert(int argc, char **argv
     const char *virtdev;
     char *file = NULL; /* modified by cd_insert tokenising it */
 
-    if ((opt = def_getopt(argc, argv, "", "cd-insert", 3)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "cd-insert", 3)) != -1)
         return opt;
 
     domid = find_domain(argv[optind]);
@@ -2396,7 +2411,7 @@ int main_console(int argc, char **argv)
     int opt = 0, num = 0;
     libxl_console_type type = 0;
 
-    while ((opt = def_getopt(argc, argv, "n:t:", "console", 1)) != -1) {
+    while ((opt = def_getopt(argc, argv, "n:t:", NULL, "console", 1)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
@@ -2427,36 +2442,23 @@ int main_console(int argc, char **argv)
 
 int main_vncviewer(int argc, char **argv)
 {
-    static const struct option long_options[] = {
+    static const struct option opts[] = {
         {"autopass", 0, 0, 'a'},
         {"vncviewer-autopass", 0, 0, 'a'},
-        {"help", 0, 0, 'h'},
+        COMMON_LONG_OPTS,
         {0, 0, 0, 0}
     };
     uint32_t domid;
     int opt, autopass = 0;
 
-    while (1) {
-        opt = getopt_long(argc, argv, "ah", long_options, NULL);
-        if (opt == -1)
-            break;
-
+    while ((opt = def_getopt(argc, argv, "ah", opts, "vncviewer", 1)) != -1) {
         switch (opt) {
+        case 0: case 2:
+            return opt;
         case 'a':
             autopass = 1;
             break;
-        case 'h':
-            help("vncviewer");
-            return 0;
-        default:
-            fprintf(stderr, "option `%c' not supported.\n", optopt);
-            break;
-        }
-    }
-
-    if (argc - optind != 1) {
-        help("vncviewer");
-        return 2;
+        }
     }
 
     domid = find_domain(argv[optind]);
@@ -2489,7 +2491,7 @@ int main_pcilist(int argc, char **argv)
     uint32_t domid;
     int opt;
 
-    if ((opt = def_getopt(argc, argv, "", "pci-list", 1)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "pci-list", 1)) != -1)
         return opt;
 
     domid = find_domain(argv[optind]);
@@ -2528,7 +2530,7 @@ int main_pcidetach(int argc, char **argv
     int force = 0;
     const char *bdf = NULL;
 
-    while ((opt = def_getopt(argc, argv, "f", "pci-detach", 2)) != -1) {
+    while ((opt = def_getopt(argc, argv, "f", NULL, "pci-detach", 2)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
@@ -2570,7 +2572,7 @@ int main_pciattach(int argc, char **argv
     int opt;
     const char *bdf = NULL, *vs = NULL;
 
-    if ((opt = def_getopt(argc, argv, "", "pci-attach", 2)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "pci-attach", 2)) != -1)
         return opt;
 
     domid = find_domain(argv[optind]);
@@ -2604,7 +2606,7 @@ int main_pciassignable_list(int argc, ch
 {
     int opt;
 
-    if ((opt = def_getopt(argc, argv, "", "pci-assignable-list", 0)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "pci-assignable-list", 0)) != -1)
         return opt;
 
     pciassignable_list();
@@ -2636,7 +2638,7 @@ int main_pciassignable_add(int argc, cha
     int opt;
     const char *bdf = NULL;
 
-    while ((opt = def_getopt(argc, argv, "", "pci-assignable-add", 1)) != -1) {
+    while ((opt = def_getopt(argc, argv, "", NULL, "pci-assignable-add", 1)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
@@ -2675,7 +2677,7 @@ int main_pciassignable_remove(int argc, 
     const char *bdf = NULL;
     int rebind = 0;
 
-    while ((opt = def_getopt(argc, argv, "r", "pci-assignable-remove", 1)) != -1) {
+    while ((opt = def_getopt(argc, argv, "r", NULL, "pci-assignable-remove", 1)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
@@ -3486,24 +3488,18 @@ int main_restore(int argc, char **argv)
     int paused = 0, debug = 0, daemonize = 1, monitor = 1,
         console_autoconnect = 0, vnc = 0, vncautopass = 0;
     int opt, rc;
-    int option_index = 0;
-    static struct option long_options[] = {
+    static struct option opts[] = {
         {"vncviewer", 0, 0, 'V'},
         {"vncviewer-autopass", 0, 0, 'A'},
+        COMMON_LONG_OPTS,
         {0, 0, 0, 0}
     };
 
-    while (1) {
-        opt = getopt_long(argc, argv, "FhcpdeVA", long_options, &option_index);
-        if (opt == -1)
-            break;
-
+    while ((opt = def_getopt(argc, argv, "FhcpdeVA",
+                             opts, "restore", 1)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
-        case 'h':
-            help("restore");
-            return 2;
         case 'c':
             console_autoconnect = 1;
             break;
@@ -3563,7 +3559,7 @@ int main_migrate_receive(int argc, char 
     int debug = 0, daemonize = 1, monitor = 1, remus = 0;
     int opt;
 
-    while ((opt = def_getopt(argc, argv, "Fedr", "migrate-receive", 0)) != -1) {
+    while ((opt = def_getopt(argc, argv, "Fedr", NULL, "migrate-receive", 0)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
@@ -3602,7 +3598,7 @@ int main_save(int argc, char **argv)
     int checkpoint = 0;
     int opt;
 
-    while ((opt = def_getopt(argc, argv, "c", "save", 2)) != -1) {
+    while ((opt = def_getopt(argc, argv, "c", NULL, "save", 2)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
@@ -3635,7 +3631,7 @@ int main_migrate(int argc, char **argv)
     char *host;
     int opt, daemonize = 1, monitor = 1, debug = 0;
 
-    while ((opt = def_getopt(argc, argv, "FC:s:ed", "migrate", 2)) != -1) {
+    while ((opt = def_getopt(argc, argv, "FC:s:ed", NULL, "migrate", 2)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
@@ -3679,7 +3675,7 @@ int main_dump_core(int argc, char **argv
 {
     int opt;
 
-    if ((opt = def_getopt(argc, argv, "", "dump-core", 2)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "dump-core", 2)) != -1)
         return opt;
 
     core_dump_domain(find_domain(argv[optind]), argv[optind + 1]);
@@ -3690,7 +3686,7 @@ int main_pause(int argc, char **argv)
 {
     int opt;
 
-    if ((opt = def_getopt(argc, argv, "", "pause", 1)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "pause", 1)) != -1)
         return opt;
 
     pause_domain(find_domain(argv[optind]));
@@ -3702,7 +3698,7 @@ int main_unpause(int argc, char **argv)
 {
     int opt;
 
-    if ((opt = def_getopt(argc, argv, "", "unpause", 1)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "unpause", 1)) != -1)
         return opt;
 
     unpause_domain(find_domain(argv[optind]));
@@ -3714,7 +3710,7 @@ int main_destroy(int argc, char **argv)
 {
     int opt;
 
-    if ((opt = def_getopt(argc, argv, "", "destroy", 1)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "destroy", 1)) != -1)
         return opt;
 
     destroy_domain(find_domain(argv[optind]));
@@ -3723,19 +3719,21 @@ int main_destroy(int argc, char **argv)
 
 static int main_shutdown_or_reboot(int reboot, int argc, char **argv)
 {
+    const char *what = reboot ? "reboot" : "shutdown";
     void (*fn)(uint32_t domid,
                libxl_evgen_domain_death **, libxl_ev_user, int) =
         reboot ? &reboot_domain : &shutdown_domain;
     int opt, i, nb_domain;
     int wait_for_it = 0, all =0;
     int fallback_trigger = 0;
-    static struct option long_options[] = {
+    static struct option opts[] = {
         {"all", 0, 0, 'a'},
         {"wait", 0, 0, 'w'},
+        COMMON_LONG_OPTS,
         {0, 0, 0, 0}
     };
 
-    while ((opt = getopt_long(argc, argv, "awF", long_options, NULL)) != -1) {
+    while ((opt = def_getopt(argc, argv, "awF", opts, what, 0)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
@@ -3805,12 +3803,11 @@ int main_list(int argc, char **argv)
     int opt, verbose = 0;
     int context = 0;
     int details = 0;
-    int option_index = 0;
-    static struct option long_options[] = {
+    static struct option opts[] = {
         {"long", 0, 0, 'l'},
-        {"help", 0, 0, 'h'},
         {"verbose", 0, 0, 'v'},
         {"context", 0, 0, 'Z'},
+        COMMON_LONG_OPTS,
         {0, 0, 0, 0}
     };
 
@@ -3818,12 +3815,10 @@ int main_list(int argc, char **argv)
     libxl_dominfo *info, *info_free=0;
     int nb_domain, rc;
 
-    while (1) {
-        opt = getopt_long(argc, argv, "lvhZ", long_options, &option_index);
-        if (opt == -1)
-            break;
-
+    while ((opt = def_getopt(argc, argv, "lvhZ", opts, "list", 0)) != -1) {
         switch (opt) {
+        case 0: case 2:
+            return opt;
         case 'l':
             details = 1;
             break;
@@ -3836,9 +3831,6 @@ int main_list(int argc, char **argv)
         case 'Z':
             context = 1;
             break;
-        default:
-            fprintf(stderr, "option `%c' not supported.\n", optopt);
-            break;
         }
     }
 
@@ -3885,7 +3877,7 @@ int main_vm_list(int argc, char **argv)
 {
     int opt;
 
-    if ((opt = def_getopt(argc, argv, "", "vm-list", 0)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "vm-list", 0)) != -1)
         return opt;
 
     list_vm();
@@ -3901,14 +3893,13 @@ int main_create(int argc, char **argv)
     int paused = 0, debug = 0, daemonize = 1, console_autoconnect = 0,
         quiet = 0, monitor = 1, vnc = 0, vncautopass = 0;
     int opt, rc;
-    int option_index = 0;
-    static struct option long_options[] = {
+    static struct option opts[] = {
         {"dryrun", 0, 0, 'n'},
         {"quiet", 0, 0, 'q'},
-        {"help", 0, 0, 'h'},
         {"defconfig", 1, 0, 'f'},
         {"vncviewer", 0, 0, 'V'},
         {"vncviewer-autopass", 0, 0, 'A'},
+        COMMON_LONG_OPTS,
         {0, 0, 0, 0}
     };
 
@@ -3917,12 +3908,10 @@ int main_create(int argc, char **argv)
         argc--; argv++;
     }
 
-    while (1) {
-        opt = getopt_long(argc, argv, "Fhnqf:pcdeVA", long_options, &option_index);
-        if (opt == -1)
-            break;
-
+    while ((opt = def_getopt(argc, argv, "Fhnqf:pcdeVA", opts, "create", 0)) != -1) {
         switch (opt) {
+        case 0: case 2:
+            return opt;
         case 'f':
             filename = optarg;
             break;
@@ -3957,9 +3946,6 @@ int main_create(int argc, char **argv)
         case 'A':
             vnc = vncautopass = 1;
             break;
-        default:
-            fprintf(stderr, "option `%c' not supported.\n", optopt);
-            break;
         }
     }
 
@@ -4007,11 +3993,10 @@ int main_config_update(int argc, char **
     int config_len = 0;
     libxl_domain_config d_config;
     int opt, rc;
-    int option_index = 0;
     int debug = 0;
-    static struct option long_options[] = {
-        {"help", 0, 0, 'h'},
+    static struct option opts[] = {
         {"defconfig", 1, 0, 'f'},
+        COMMON_LONG_OPTS,
         {0, 0, 0, 0}
     };
 
@@ -4029,24 +4014,16 @@ int main_config_update(int argc, char **
         argc--; argv++;
     }
 
-    while (1) {
-        opt = getopt_long(argc, argv, "dhqf:", long_options, &option_index);
-        if (opt == -1)
-            break;
-
+    while ((opt = def_getopt(argc, argv, "dhqf:", opts, "config_update", 0)) != -1) {
         switch (opt) {
+        case 0: case 2:
+            return opt;
         case 'd':
             debug = 1;
             break;
         case 'f':
             filename = optarg;
             break;
-        case 'h':
-            help("create");
-            return 0;
-        default:
-            fprintf(stderr, "option `%c' not supported.\n", optopt);
-            break;
         }
     }
 
@@ -4135,7 +4112,7 @@ int main_button_press(int argc, char **a
     fprintf(stderr, "WARNING: \"button-press\" is deprecated. "
             "Please use \"trigger\"\n");
 
-    if ((opt = def_getopt(argc, argv, "", "button-press", 2)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "button-press", 2)) != -1)
         return opt;
 
     button_press(find_domain(argv[optind]), argv[optind + 1]);
@@ -4276,7 +4253,7 @@ int main_vcpulist(int argc, char **argv)
 {
     int opt;
 
-    if ((opt = def_getopt(argc, argv, "", "cpu-list", 0)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "cpu-list", 0)) != -1)
         return opt;
 
     vcpulist(argc - optind, argv + optind);
@@ -4337,7 +4314,7 @@ int main_vcpupin(int argc, char **argv)
 {
     int opt;
 
-    if ((opt = def_getopt(argc, argv, "", "vcpu-pin", 3)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "vcpu-pin", 3)) != -1)
         return opt;
 
     vcpupin(find_domain(argv[optind]), argv[optind+1] , argv[optind+2]);
@@ -4373,7 +4350,7 @@ int main_vcpuset(int argc, char **argv)
 {
     int opt;
 
-    if ((opt = def_getopt(argc, argv, "", "vcpu-set", 2)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "vcpu-set", 2)) != -1)
         return opt;
 
     vcpuset(find_domain(argv[optind]), argv[optind+1]);
@@ -4549,25 +4526,20 @@ static void print_info(int numa)
 int main_info(int argc, char **argv)
 {
     int opt;
-    int option_index = 0;
-    static struct option long_options[] = {
-        {"help", 0, 0, 'h'},
+    static struct option opts[] = {
         {"numa", 0, 0, 'n'},
+        COMMON_LONG_OPTS,
         {0, 0, 0, 0}
     };
     int numa = 0;
 
-    while ((opt = getopt_long(argc, argv, "hn", long_options, &option_index)) != -1) {
+    while ((opt = def_getopt(argc, argv, "hn", opts, "info", 0)) != -1) {
         switch (opt) {
-        case 'h':
-            help("info");
-            return 0;
+        case 0: case 2:
+            return opt;
         case 'n':
             numa = 1;
             break;
-        default:
-            fprintf(stderr, "option `%c' not supported.\n", optopt);
-            break;
         }
     }
 
@@ -4602,7 +4574,7 @@ int main_sharing(int argc, char **argv)
     libxl_dominfo *info, *info_free = NULL;
     int nb_domain, rc;
 
-    if ((opt = def_getopt(argc, argv, "", "sharing", 0)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "sharing", 0)) != -1)
         return opt;
 
     if (optind >= argc) {
@@ -4871,8 +4843,7 @@ int main_sched_credit(int argc, char **a
     int opt_s = 0;
     int tslice = 0, opt_t = 0, ratelimit = 0, opt_r = 0;
     int opt, rc;
-    int option_index = 0;
-    static struct option long_options[] = {
+    static struct option opts[] = {
         {"domain", 1, 0, 'd'},
         {"weight", 1, 0, 'w'},
         {"cap", 1, 0, 'c'},
@@ -4880,15 +4851,11 @@ int main_sched_credit(int argc, char **a
         {"tslice_ms", 1, 0, 't'},
         {"ratelimit_us", 1, 0, 'r'},
         {"cpupool", 1, 0, 'p'},
-        {"help", 0, 0, 'h'},
+        COMMON_LONG_OPTS,
         {0, 0, 0, 0}
     };
 
-    while (1) {
-        opt = getopt_long(argc, argv, "d:w:c:p:t:r:hs", long_options,
-                          &option_index);
-        if (opt == -1)
-            break;
+    while ((opt = def_getopt(argc, argv, "d:w:c:p:t:r:hs", opts, "sched-credit", 0)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
@@ -4917,9 +4884,6 @@ int main_sched_credit(int argc, char **a
         case 'p':
             cpupool = optarg;
             break;
-        case 'h':
-            help("sched-credit");
-            return 0;
         }
     }
 
@@ -5002,19 +4966,15 @@ int main_sched_credit2(int argc, char **
     const char *cpupool = NULL;
     int weight = 256, opt_w = 0;
     int opt, rc;
-    int option_index = 0;
-    static struct option long_options[] = {
+    static struct option opts[] = {
         {"domain", 1, 0, 'd'},
         {"weight", 1, 0, 'w'},
         {"cpupool", 1, 0, 'p'},
-        {"help", 0, 0, 'h'},
+        COMMON_LONG_OPTS,
         {0, 0, 0, 0}
     };
 
-    while (1) {
-        opt = getopt_long(argc, argv, "d:w:p:h", long_options, &option_index);
-        if (opt == -1)
-            break;
+    while ((opt = def_getopt(argc, argv, "d:w:p:h", opts, "sched-credit2", 0)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
@@ -5028,9 +4988,6 @@ int main_sched_credit2(int argc, char **
         case 'p':
             cpupool = optarg;
             break;
-        case 'h':
-            help("sched-credit");
-            return 0;
         }
     }
 
@@ -5081,23 +5038,18 @@ int main_sched_sedf(int argc, char **arg
     int extra = 0, opt_e = 0;
     int weight = 0, opt_w = 0;
     int opt, rc;
-    int option_index = 0;
-    static struct option long_options[] = {
+    static struct option opts[] = {
         {"period", 1, 0, 'p'},
         {"slice", 1, 0, 's'},
         {"latency", 1, 0, 'l'},
         {"extra", 1, 0, 'e'},
         {"weight", 1, 0, 'w'},
         {"cpupool", 1, 0, 'c'},
-        {"help", 0, 0, 'h'},
+        COMMON_LONG_OPTS,
         {0, 0, 0, 0}
     };
 
-    while (1) {
-        opt = getopt_long(argc, argv, "d:p:s:l:e:w:c:h", long_options,
-                          &option_index);
-        if (opt == -1)
-            break;
+    while ((opt = def_getopt(argc, argv, "d:p:s:l:e:w:c:h", opts, "sched-sedf", 0)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
@@ -5127,9 +5079,6 @@ int main_sched_sedf(int argc, char **arg
         case 'c':
             cpupool = optarg;
             break;
-        case 'h':
-            help("sched-sedf");
-            return 0;
         }
     }
 
@@ -5197,7 +5146,7 @@ int main_domid(int argc, char **argv)
     int opt;
     const char *domname = NULL;
 
-    if ((opt = def_getopt(argc, argv, "", "domid", 1)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "domid", 1)) != -1)
         return opt;
 
     domname = argv[optind];
@@ -5219,7 +5168,7 @@ int main_domname(int argc, char **argv)
     char *domname = NULL;
     char *endptr = NULL;
 
-    if ((opt = def_getopt(argc, argv, "", "domname", 1)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "domname", 1)) != -1)
         return opt;
 
     domid = strtol(argv[optind], &endptr, 10);
@@ -5247,7 +5196,7 @@ int main_rename(int argc, char **argv)
     int opt;
     const char *dom, *new_name;
 
-    if ((opt = def_getopt(argc, argv, "", "rename", 2)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "rename", 2)) != -1)
         return opt;
 
     dom = argv[optind++];
@@ -5271,7 +5220,7 @@ int main_trigger(int argc, char **argv)
     const char *trigger_name = NULL;
     libxl_trigger trigger;
 
-    if ((opt = def_getopt(argc, argv, "", "trigger", 2)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "trigger", 2)) != -1)
         return opt;
 
     domid = find_domain(argv[optind++]);
@@ -5301,7 +5250,7 @@ int main_sysrq(int argc, char **argv)
     int opt;
     const char *sysrq = NULL;
 
-    if ((opt = def_getopt(argc, argv, "", "sysrq", 2)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "sysrq", 2)) != -1)
         return opt;
 
     domid = find_domain(argv[optind++]);
@@ -5324,7 +5273,7 @@ int main_debug_keys(int argc, char **arg
     int opt;
     char *keys;
 
-    if ((opt = def_getopt(argc, argv, "", "debug-keys", 1)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "debug-keys", 1)) != -1)
         return opt;
 
     keys = argv[optind];
@@ -5344,7 +5293,7 @@ int main_dmesg(int argc, char **argv)
     char *line;
     int opt, ret = 1;
 
-    while ((opt = def_getopt(argc, argv, "c", "dmesg", 0)) != -1) {
+    while ((opt = def_getopt(argc, argv, "c", NULL, "dmesg", 0)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
@@ -5370,7 +5319,7 @@ int main_top(int argc, char **argv)
 {
     int opt;
 
-    if ((opt = def_getopt(argc, argv, "", "top", 0)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "top", 0)) != -1)
         return opt;
 
     return system("xentop");
@@ -5387,7 +5336,7 @@ int main_networkattach(int argc, char **
     int i;
     unsigned int val;
 
-    if ((opt = def_getopt(argc, argv, "", "network-attach", 1)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "network-attach", 1)) != -1)
         return opt;
 
     if (argc-optind > 11) {
@@ -5474,7 +5423,7 @@ int main_networklist(int argc, char **ar
     libxl_nicinfo nicinfo;
     int nb, i;
 
-    if ((opt = def_getopt(argc, argv, "", "network-list", 1)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "network-list", 1)) != -1)
         return opt;
 
     /*      Idx  BE   MAC   Hdl  Sta  evch txr/rxr  BE-path */
@@ -5511,7 +5460,7 @@ int main_networkdetach(int argc, char **
     int opt;
     libxl_device_nic nic;
 
-    if ((opt = def_getopt(argc, argv, "", "network-detach", 2)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "network-detach", 2)) != -1)
         return opt;
 
     domid = find_domain(argv[optind]);
@@ -5542,7 +5491,7 @@ int main_blockattach(int argc, char **ar
     libxl_device_disk disk = { 0 };
     XLU_Config *config = 0;
 
-    if ((opt = def_getopt(argc, argv, "", "block-attach", 2)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "block-attach", 2)) != -1)
         return opt;
 
     if (domain_qualifier_to_domid(argv[optind], &fe_domid, 0) < 0) {
@@ -5577,7 +5526,7 @@ int main_blocklist(int argc, char **argv
     libxl_device_disk *disks;
     libxl_diskinfo diskinfo;
 
-    if ((opt = def_getopt(argc, argv, "", "block-list", 1)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "block-list", 1)) != -1)
         return opt;
 
     printf("%-5s %-3s %-6s %-5s %-6s %-8s %-30s\n",
@@ -5613,7 +5562,7 @@ int main_blockdetach(int argc, char **ar
     int opt, rc = 0;
     libxl_device_disk disk;
 
-    if ((opt = def_getopt(argc, argv, "", "block-detach", 2)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "block-detach", 2)) != -1)
         return opt;
 
     domid = find_domain(argv[optind]);
@@ -5797,7 +5746,7 @@ int main_uptime(int argc, char **argv)
     int nb_doms = 0;
     int opt;
 
-    while ((opt = def_getopt(argc, argv, "s", "uptime", 1)) != -1) {
+    while ((opt = def_getopt(argc, argv, "s", NULL, "uptime", 1)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
@@ -5824,7 +5773,7 @@ int main_tmem_list(int argc, char **argv
     int all = 0;
     int opt;
 
-    while ((opt = def_getopt(argc, argv, "al", "tmem-list", 0)) != -1) {
+    while ((opt = def_getopt(argc, argv, "al", NULL, "tmem-list", 0)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
@@ -5865,7 +5814,7 @@ int main_tmem_freeze(int argc, char **ar
     int all = 0;
     int opt;
 
-    while ((opt = def_getopt(argc, argv, "a", "tmem-freeze", 0)) != -1) {
+    while ((opt = def_getopt(argc, argv, "a", NULL, "tmem-freeze", 0)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
@@ -5898,7 +5847,7 @@ int main_tmem_thaw(int argc, char **argv
     int all = 0;
     int opt;
 
-    while ((opt = def_getopt(argc, argv, "a", "tmem-thaw", 0)) != -1) {
+    while ((opt = def_getopt(argc, argv, "a", NULL, "tmem-thaw", 0)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
@@ -5933,7 +5882,7 @@ int main_tmem_set(int argc, char **argv)
     int all = 0;
     int opt;
 
-    while ((opt = def_getopt(argc, argv, "aw:c:p:", "tmem-set", 0)) != -1) {
+    while ((opt = def_getopt(argc, argv, "aw:c:p:", NULL, "tmem-set", 0)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
@@ -5994,7 +5943,7 @@ int main_tmem_shared_auth(int argc, char
     int all = 0;
     int opt;
 
-    while ((opt = def_getopt(argc, argv, "au:A:", "tmem-shared-auth", 0)) != -1) {
+    while ((opt = def_getopt(argc, argv, "au:A:", NULL, "tmem-shared-auth", 0)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
@@ -6044,7 +5993,7 @@ int main_tmem_freeable(int argc, char **
     int opt;
     int mb;
 
-    if ((opt = def_getopt(argc, argv, "", "tmem-freeable", 0)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "tmem-freeable", 0)) != -1)
         return opt;
 
     mb = libxl_tmem_freeable(ctx);
@@ -6061,11 +6010,10 @@ int main_cpupoolcreate(int argc, char **
     const char *p;
     char extra_config[1024];
     int opt;
-    int option_index = 0;
-    static struct option long_options[] = {
-        {"help", 0, 0, 'h'},
+    static struct option opts[] = {
         {"defconfig", 1, 0, 'f'},
         {"dryrun", 0, 0, 'n'},
+        COMMON_LONG_OPTS,
         {0, 0, 0, 0}
     };
     int ret;
@@ -6083,26 +6031,18 @@ int main_cpupoolcreate(int argc, char **
     libxl_bitmap cpumap;
     libxl_uuid uuid;
     libxl_cputopology *topology;
-    int rc = -ERROR_FAIL; 
-
-    while (1) {
-        opt = getopt_long(argc, argv, "hnf:", long_options, &option_index);
-        if (opt == -1)
-            break;
-
+    int rc = -ERROR_FAIL;
+
+    while ((opt = def_getopt(argc, argv, "hnf:", opts, "cpupool-create", 0)) != -1) {
         switch (opt) {
+        case 0: case 2:
+            return opt;
         case 'f':
             filename = optarg;
             break;
-        case 'h':
-            help("cpupool-create");
-            return 0;
         case 'n':
             dryrun_only = 1;
             break;
-        default:
-            fprintf(stderr, "option `%c' not supported.\n", optopt);
-            break;
         }
     }
 
@@ -6265,10 +6205,9 @@ out:
 int main_cpupoollist(int argc, char **argv)
 {
     int opt;
-    int option_index = 0;
-    static struct option long_options[] = {
-        {"help", 0, 0, 'h'},
+    static struct option opts[] = {
         {"cpus", 0, 0, 'c'},
+        COMMON_LONG_OPTS,
         {0, 0, 0, 0}
     };
     int opt_cpus = 0;
@@ -6279,28 +6218,16 @@ int main_cpupoollist(int argc, char **ar
     char *name;
     int ret = 0;
 
-    while (1) {
-        opt = getopt_long(argc, argv, "hc", long_options, &option_index);
-        if (opt == -1)
+    while ((opt = def_getopt(argc, argv, "hc", opts, "cpupool-list", 1)) != -1) {
+        switch (opt) {
+        case 0: case 2:
             break;
-
-        switch (opt) {
-        case 'h':
-            help("cpupool-list");
-            return 0;
         case 'c':
             opt_cpus = 1;
             break;
-        default:
-            fprintf(stderr, "option `%c' not supported.\n", optopt);
-            break;
-        }
-    }
-
-    if ((optind + 1) < argc) {
-        help("cpupool-list");
-        return -ERROR_FAIL;
-    }
+        }
+    }
+
     if (optind < argc) {
         pool = argv[optind];
         if (libxl_name_to_cpupoolid(ctx, pool, &poolid)) {
@@ -6358,7 +6285,7 @@ int main_cpupooldestroy(int argc, char *
     const char *pool;
     uint32_t poolid;
 
-    if ((opt = def_getopt(argc, argv, "", "cpupool-destroy", 1)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "cpupool-destroy", 1)) != -1)
         return opt;
 
     pool = argv[optind];
@@ -6379,7 +6306,7 @@ int main_cpupoolrename(int argc, char **
     const char *new_name;
     uint32_t poolid;
 
-    if ((opt = def_getopt(argc, argv, "", "cpupool-rename", 2)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "cpupool-rename", 2)) != -1)
         return opt;
 
     pool = argv[optind++];
@@ -6409,7 +6336,7 @@ int main_cpupoolcpuadd(int argc, char **
     int node;
     int n;
 
-    if ((opt = def_getopt(argc, argv, "", "cpupool-cpu-add", 2)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "cpupool-cpu-add", 2)) != -1)
         return opt;
 
     pool = argv[optind++];
@@ -6453,7 +6380,7 @@ int main_cpupoolcpuremove(int argc, char
     int node;
     int n;
 
-    if ((opt = def_getopt(argc, argv, "", "cpupool-cpu-remove", 2)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "cpupool-cpu-remove", 2)) != -1)
         return opt;
 
     pool = argv[optind++];
@@ -6496,7 +6423,7 @@ int main_cpupoolmigrate(int argc, char *
     const char *dom;
     uint32_t domid;
 
-    if ((opt = def_getopt(argc, argv, "", "cpupool-migrate", 2)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "cpupool-migrate", 2)) != -1)
         return opt;
 
     dom = argv[optind++];
@@ -6536,7 +6463,7 @@ int main_cpupoolnumasplit(int argc, char
     libxl_cputopology *topology;
     libxl_dominfo info;
 
-    if ((opt = def_getopt(argc, argv, "", "cpupool-numa-split", 0)) != -1)
+    if ((opt = def_getopt(argc, argv, "", NULL, "cpupool-numa-split", 0)) != -1)
         return opt;
     ret = 0;
 
@@ -6789,7 +6716,7 @@ int main_remus(int argc, char **argv)
     r_info.blackhole = 0;
     r_info.compression = 1;
 
-    while ((opt = def_getopt(argc, argv, "bui:s:e", "remus", 2)) != -1) {
+    while ((opt = def_getopt(argc, argv, "bui:s:e", NULL, "remus", 2)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 10:11:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 10:11:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNhe9-0000wb-Vq; Mon, 15 Oct 2012 10:11:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TNhe9-0000wP-7B
	for xen-devel@lists.xensource.com; Mon, 15 Oct 2012 10:11:41 +0000
Received: from [85.158.143.99:18600] by server-2.bemta-4.messagelabs.com id
	CB/3B-25171-C51EB705; Mon, 15 Oct 2012 10:11:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1350295899!34118902!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8791 invoked from network); 15 Oct 2012 10:11:40 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-216.messagelabs.com with SMTP;
	15 Oct 2012 10:11:40 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 15 Oct 2012 11:11:39 +0100
Message-Id: <507BFD7802000078000A1526@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 15 Oct 2012 11:11:36 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <5063155A.4070307@amd.com>
	<50642A2A020000780009E32D@nat28.tlf.novell.com>
	<507BDED1.6020005@amd.com>
In-Reply-To: <507BDED1.6020005@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	IanCampbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2 of 6 V6] amd iommu: call
 guest_iommu_set_base from hvmloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.10.12 at 12:00, Wei Wang <wei.wang2@amd.com> wrote:
> On 09/27/2012 10:27 AM, Jan Beulich wrote:
>>>>> On 26.09.12 at 16:46, Wei Wang<wei.wang2@amd.com>  wrote:
>>> @@ -3834,6 +3835,9 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) 
> arg)
>>>              case HVM_PARAM_BUFIOREQ_EVTCHN:
>>>                  rc = -EINVAL;
>>>                  break;
>>> +            case HVM_PARAM_IOMMU_BASE:
>>> +                rc = guest_iommu_set_base(d, a.value);
>>
>> This suggests that you're allowing for only a single IOMMU per
>> guest - is that not going to become an issue sooner or later?
>
> I think that one iommu per guest is probably enough. Because guest IVRS 
> table is totally virtual, it does not reflect any pci relationship of 
> real systems. Even if qemu supports multi pci buses, we can still 
> virtually group them together into one virtual IVRS table. It might be 
> an issue if qemu uses multi pci segments, but so far even hardware iommu 
> only uses segment 0. Additionally, the guest iommu is only used by ats 
> capable GPUs. Normal passthrough device should not make use of it. So,, 
> What do you think?

Especially the multi-segment aspect makes me think that the
interface should allow for multiple IOMMUs, even if the
implementation supports only one for now.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 10:11:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 10:11:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNhe9-0000wb-Vq; Mon, 15 Oct 2012 10:11:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TNhe9-0000wP-7B
	for xen-devel@lists.xensource.com; Mon, 15 Oct 2012 10:11:41 +0000
Received: from [85.158.143.99:18600] by server-2.bemta-4.messagelabs.com id
	CB/3B-25171-C51EB705; Mon, 15 Oct 2012 10:11:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1350295899!34118902!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8791 invoked from network); 15 Oct 2012 10:11:40 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-216.messagelabs.com with SMTP;
	15 Oct 2012 10:11:40 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 15 Oct 2012 11:11:39 +0100
Message-Id: <507BFD7802000078000A1526@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 15 Oct 2012 11:11:36 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <5063155A.4070307@amd.com>
	<50642A2A020000780009E32D@nat28.tlf.novell.com>
	<507BDED1.6020005@amd.com>
In-Reply-To: <507BDED1.6020005@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	IanCampbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2 of 6 V6] amd iommu: call
 guest_iommu_set_base from hvmloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.10.12 at 12:00, Wei Wang <wei.wang2@amd.com> wrote:
> On 09/27/2012 10:27 AM, Jan Beulich wrote:
>>>>> On 26.09.12 at 16:46, Wei Wang<wei.wang2@amd.com>  wrote:
>>> @@ -3834,6 +3835,9 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) 
> arg)
>>>              case HVM_PARAM_BUFIOREQ_EVTCHN:
>>>                  rc = -EINVAL;
>>>                  break;
>>> +            case HVM_PARAM_IOMMU_BASE:
>>> +                rc = guest_iommu_set_base(d, a.value);
>>
>> This suggests that you're allowing for only a single IOMMU per
>> guest - is that not going to become an issue sooner or later?
>
> I think that one iommu per guest is probably enough. Because guest IVRS 
> table is totally virtual, it does not reflect any pci relationship of 
> real systems. Even if qemu supports multi pci buses, we can still 
> virtually group them together into one virtual IVRS table. It might be 
> an issue if qemu uses multi pci segments, but so far even hardware iommu 
> only uses segment 0. Additionally, the guest iommu is only used by ats 
> capable GPUs. Normal passthrough device should not make use of it. So,, 
> What do you think?

Especially the multi-segment aspect makes me think that the
interface should allow for multiple IOMMUs, even if the
implementation supports only one for now.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 10:14:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 10:14:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNhh8-0001MF-Ju; Mon, 15 Oct 2012 10:14:46 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <pebolle@tiscali.nl>) id 1TNhWV-0000I1-0a
	for xen-devel@lists.xensource.com; Mon, 15 Oct 2012 10:03:47 +0000
X-Env-Sender: pebolle@tiscali.nl
X-Msg-Ref: server-6.tower-27.messagelabs.com!1350295390!3539916!1
X-Originating-IP: [213.75.39.4]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTMuNzUuMzkuNCA9PiA2MDc1NzQ=\n,sa_preprocessor: 
	QmFkIElQOiAyMTMuNzUuMzkuNCA9PiA2MDc1NzQ=\n,BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21698 invoked from network); 15 Oct 2012 10:03:11 -0000
Received: from cpsmtpb-ews01.kpnxchange.com (HELO
	cpsmtpb-ews01.kpnxchange.com) (213.75.39.4)
	by server-6.tower-27.messagelabs.com with SMTP;
	15 Oct 2012 10:03:11 -0000
Received: from cpsps-ews24.kpnxchange.com ([10.94.84.190]) by
	cpsmtpb-ews01.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.4675); 
	Mon, 15 Oct 2012 12:03:05 +0200
Received: from CPSMTPM-TLF103.kpnxchange.com ([195.121.3.6]) by
	cpsps-ews24.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); 
	Mon, 15 Oct 2012 12:03:04 +0200
Received: from [192.168.1.101] ([212.123.169.34]) by
	CPSMTPM-TLF103.kpnxchange.com with Microsoft
	SMTPSVC(7.5.7601.17514); Mon, 15 Oct 2012 12:03:10 +0200
Message-ID: <1350295389.1516.27.camel@x61.thuisdomein>
From: Paul Bolle <pebolle@tiscali.nl>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Jeremy Fitzhardinge
	<jeremy@goop.org>
Date: Mon, 15 Oct 2012 12:03:09 +0200
X-Mailer: Evolution 3.4.4 (3.4.4-2.fc17) 
Mime-Version: 1.0
X-OriginalArrivalTime: 15 Oct 2012 10:03:10.0468 (UTC)
	FILETIME=[4826AC40:01CDAABC]
X-RcptDomain: lists.xensource.com
X-Mailman-Approved-At: Mon, 15 Oct 2012 10:14:45 +0000
Cc: xen-devel@lists.xensource.com, virtualization@lists.linux-foundation.org,
	linux-kernel@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>
Subject: [Xen-devel] [PATCH] xen/xenbus: silence GCC warning
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Q29tcGlsaW5nIHhlbmJ1c194cy5vIHRyaWdnZXJzIHRoaXMgR0NDIHdhcm5pbmc6CiAgICBkcml2
ZXJzL3hlbi94ZW5idXMveGVuYnVzX3hzLmM6NjI4OjEzOiB3YXJuaW5nOiBmdW5jdGlvbiBkZWNs
YXJhdGlvbiBpc27igJl0IGEgcHJvdG90eXBlIFstV3N0cmljdC1wcm90b3R5cGVzXQoKQWRkIHRo
ZSBvYnZpb3VzIGFuZCB0cml2aWFsIGZpeC4KCldoaWxlIHdlJ3JlIHRvdWNoaW5nIHRoaXMgZnVu
Y3Rpb24gYWRkIHNvbWUgZXF1YWxseSBvYnZpb3VzIGFuZCB0cml2aWFsCndoaXRlc3BhY2UgZml4
ZXMuCgpTaWduZWQtb2ZmLWJ5OiBQYXVsIEJvbGxlIDxwZWJvbGxlQHRpc2NhbGkubmw+Ci0tLQow
KSBUcmlnZ2VyZWQgYnkgY29tcGlsaW5nIHYzLjctcmMxIHVzaW5nIChiYXNpY2FsbHkpIEZlZG9y
YSAxNydzIGN1cnJlbnQKY29uZmlnLiBDb21waWxlIHRlc3RlZCBvbmx5LgoKMSkgT2JsaWdhdG9y
eSByZWZlcmVuY2U6IGh0dHBzOi8vbHduLm5ldC9BcnRpY2xlcy80ODc0OTMvIC4KCiBkcml2ZXJz
L3hlbi94ZW5idXMveGVuYnVzX3hzLmMgfCA1ICsrKy0tCiAxIGZpbGUgY2hhbmdlZCwgMyBpbnNl
cnRpb25zKCspLCAyIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVuL3hlbmJ1
cy94ZW5idXNfeHMuYyBiL2RyaXZlcnMveGVuL3hlbmJ1cy94ZW5idXNfeHMuYwppbmRleCA0ODIy
MGUxLi43YTJiMGRhIDEwMDY0NAotLS0gYS9kcml2ZXJzL3hlbi94ZW5idXMveGVuYnVzX3hzLmMK
KysrIGIvZHJpdmVycy94ZW4veGVuYnVzL3hlbmJ1c194cy5jCkBAIC02MTksMTMgKzYxOSwxNCBA
QCBzdGF0aWMgc3RydWN0IHhlbmJ1c193YXRjaCAqZmluZF93YXRjaChjb25zdCBjaGFyICp0b2tl
bikKIAogCXJldHVybiBOVUxMOwogfQorCiAvKgogICogQ2VydGFpbiBvbGRlciBYZW5CdXMgdG9v
bHN0YWNrIGNhbm5vdCBoYW5kbGUgcmVhZGluZyB2YWx1ZXMgdGhhdCBhcmUKICAqIG5vdCBwb3B1
bGF0ZWQuIFNvbWUgWGVuIDMuNCBpbnN0YWxsYXRpb24gYXJlIGluY2FwYWJsZSBvZiBkb2luZyB0
aGlzCiAgKiBzbyBpZiB3ZSBhcmUgcnVubmluZyBvbiBhbnl0aGluZyBvbGRlciB0aGFuIDQgZG8g
bm90IGF0dGVtcHQgdG8gcmVhZAogICogY29udHJvbC9wbGF0Zm9ybS1mZWF0dXJlLXhzX3Jlc2V0
X3dhdGNoZXMuCiAgKi8KLXN0YXRpYyBib29sIHhlbl9zdHJpY3RfeGVuYnVzX3F1aXJrKCkKK3N0
YXRpYyBib29sIHhlbl9zdHJpY3RfeGVuYnVzX3F1aXJrKHZvaWQpCiB7CiAJdWludDMyX3QgZWF4
LCBlYngsIGVjeCwgZWR4LCBiYXNlOwogCkBAIC02MzUsOCArNjM2LDggQEAgc3RhdGljIGJvb2wg
eGVuX3N0cmljdF94ZW5idXNfcXVpcmsoKQogCWlmICgoZWF4ID4+IDE2KSA8IDQpCiAJCXJldHVy
biB0cnVlOwogCXJldHVybiBmYWxzZTsKLQogfQorCiBzdGF0aWMgdm9pZCB4c19yZXNldF93YXRj
aGVzKHZvaWQpCiB7CiAJaW50IGVyciwgc3VwcG9ydGVkID0gMDsKLS0gCjEuNy4xMS43CgoKX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1h
aWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94
ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Mon Oct 15 10:14:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 10:14:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNhh8-0001MF-Ju; Mon, 15 Oct 2012 10:14:46 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <pebolle@tiscali.nl>) id 1TNhWV-0000I1-0a
	for xen-devel@lists.xensource.com; Mon, 15 Oct 2012 10:03:47 +0000
X-Env-Sender: pebolle@tiscali.nl
X-Msg-Ref: server-6.tower-27.messagelabs.com!1350295390!3539916!1
X-Originating-IP: [213.75.39.4]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTMuNzUuMzkuNCA9PiA2MDc1NzQ=\n,sa_preprocessor: 
	QmFkIElQOiAyMTMuNzUuMzkuNCA9PiA2MDc1NzQ=\n,BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21698 invoked from network); 15 Oct 2012 10:03:11 -0000
Received: from cpsmtpb-ews01.kpnxchange.com (HELO
	cpsmtpb-ews01.kpnxchange.com) (213.75.39.4)
	by server-6.tower-27.messagelabs.com with SMTP;
	15 Oct 2012 10:03:11 -0000
Received: from cpsps-ews24.kpnxchange.com ([10.94.84.190]) by
	cpsmtpb-ews01.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.4675); 
	Mon, 15 Oct 2012 12:03:05 +0200
Received: from CPSMTPM-TLF103.kpnxchange.com ([195.121.3.6]) by
	cpsps-ews24.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); 
	Mon, 15 Oct 2012 12:03:04 +0200
Received: from [192.168.1.101] ([212.123.169.34]) by
	CPSMTPM-TLF103.kpnxchange.com with Microsoft
	SMTPSVC(7.5.7601.17514); Mon, 15 Oct 2012 12:03:10 +0200
Message-ID: <1350295389.1516.27.camel@x61.thuisdomein>
From: Paul Bolle <pebolle@tiscali.nl>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Jeremy Fitzhardinge
	<jeremy@goop.org>
Date: Mon, 15 Oct 2012 12:03:09 +0200
X-Mailer: Evolution 3.4.4 (3.4.4-2.fc17) 
Mime-Version: 1.0
X-OriginalArrivalTime: 15 Oct 2012 10:03:10.0468 (UTC)
	FILETIME=[4826AC40:01CDAABC]
X-RcptDomain: lists.xensource.com
X-Mailman-Approved-At: Mon, 15 Oct 2012 10:14:45 +0000
Cc: xen-devel@lists.xensource.com, virtualization@lists.linux-foundation.org,
	linux-kernel@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>
Subject: [Xen-devel] [PATCH] xen/xenbus: silence GCC warning
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Q29tcGlsaW5nIHhlbmJ1c194cy5vIHRyaWdnZXJzIHRoaXMgR0NDIHdhcm5pbmc6CiAgICBkcml2
ZXJzL3hlbi94ZW5idXMveGVuYnVzX3hzLmM6NjI4OjEzOiB3YXJuaW5nOiBmdW5jdGlvbiBkZWNs
YXJhdGlvbiBpc27igJl0IGEgcHJvdG90eXBlIFstV3N0cmljdC1wcm90b3R5cGVzXQoKQWRkIHRo
ZSBvYnZpb3VzIGFuZCB0cml2aWFsIGZpeC4KCldoaWxlIHdlJ3JlIHRvdWNoaW5nIHRoaXMgZnVu
Y3Rpb24gYWRkIHNvbWUgZXF1YWxseSBvYnZpb3VzIGFuZCB0cml2aWFsCndoaXRlc3BhY2UgZml4
ZXMuCgpTaWduZWQtb2ZmLWJ5OiBQYXVsIEJvbGxlIDxwZWJvbGxlQHRpc2NhbGkubmw+Ci0tLQow
KSBUcmlnZ2VyZWQgYnkgY29tcGlsaW5nIHYzLjctcmMxIHVzaW5nIChiYXNpY2FsbHkpIEZlZG9y
YSAxNydzIGN1cnJlbnQKY29uZmlnLiBDb21waWxlIHRlc3RlZCBvbmx5LgoKMSkgT2JsaWdhdG9y
eSByZWZlcmVuY2U6IGh0dHBzOi8vbHduLm5ldC9BcnRpY2xlcy80ODc0OTMvIC4KCiBkcml2ZXJz
L3hlbi94ZW5idXMveGVuYnVzX3hzLmMgfCA1ICsrKy0tCiAxIGZpbGUgY2hhbmdlZCwgMyBpbnNl
cnRpb25zKCspLCAyIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVuL3hlbmJ1
cy94ZW5idXNfeHMuYyBiL2RyaXZlcnMveGVuL3hlbmJ1cy94ZW5idXNfeHMuYwppbmRleCA0ODIy
MGUxLi43YTJiMGRhIDEwMDY0NAotLS0gYS9kcml2ZXJzL3hlbi94ZW5idXMveGVuYnVzX3hzLmMK
KysrIGIvZHJpdmVycy94ZW4veGVuYnVzL3hlbmJ1c194cy5jCkBAIC02MTksMTMgKzYxOSwxNCBA
QCBzdGF0aWMgc3RydWN0IHhlbmJ1c193YXRjaCAqZmluZF93YXRjaChjb25zdCBjaGFyICp0b2tl
bikKIAogCXJldHVybiBOVUxMOwogfQorCiAvKgogICogQ2VydGFpbiBvbGRlciBYZW5CdXMgdG9v
bHN0YWNrIGNhbm5vdCBoYW5kbGUgcmVhZGluZyB2YWx1ZXMgdGhhdCBhcmUKICAqIG5vdCBwb3B1
bGF0ZWQuIFNvbWUgWGVuIDMuNCBpbnN0YWxsYXRpb24gYXJlIGluY2FwYWJsZSBvZiBkb2luZyB0
aGlzCiAgKiBzbyBpZiB3ZSBhcmUgcnVubmluZyBvbiBhbnl0aGluZyBvbGRlciB0aGFuIDQgZG8g
bm90IGF0dGVtcHQgdG8gcmVhZAogICogY29udHJvbC9wbGF0Zm9ybS1mZWF0dXJlLXhzX3Jlc2V0
X3dhdGNoZXMuCiAgKi8KLXN0YXRpYyBib29sIHhlbl9zdHJpY3RfeGVuYnVzX3F1aXJrKCkKK3N0
YXRpYyBib29sIHhlbl9zdHJpY3RfeGVuYnVzX3F1aXJrKHZvaWQpCiB7CiAJdWludDMyX3QgZWF4
LCBlYngsIGVjeCwgZWR4LCBiYXNlOwogCkBAIC02MzUsOCArNjM2LDggQEAgc3RhdGljIGJvb2wg
eGVuX3N0cmljdF94ZW5idXNfcXVpcmsoKQogCWlmICgoZWF4ID4+IDE2KSA8IDQpCiAJCXJldHVy
biB0cnVlOwogCXJldHVybiBmYWxzZTsKLQogfQorCiBzdGF0aWMgdm9pZCB4c19yZXNldF93YXRj
aGVzKHZvaWQpCiB7CiAJaW50IGVyciwgc3VwcG9ydGVkID0gMDsKLS0gCjEuNy4xMS43CgoKX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1h
aWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94
ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Mon Oct 15 10:18:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 10:18:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNhkL-0001YX-7Z; Mon, 15 Oct 2012 10:18:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TNhkJ-0001YO-Sr
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 10:18:03 +0000
Received: from [85.158.143.99:48942] by server-2.bemta-4.messagelabs.com id
	31/E4-25171-BD2EB705; Mon, 15 Oct 2012 10:18:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1350296282!26610614!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5628 invoked from network); 15 Oct 2012 10:18:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 10:18:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="15166611"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 10:17:31 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 11:17:31 +0100
Message-ID: <1350296250.18058.18.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julian Seward <jseward@acm.org>
Date: Mon, 15 Oct 2012 11:17:30 +0100
In-Reply-To: <201210111836.53184.jseward@acm.org>
References: <1349696046.18008.116.camel@zakaz.uk.xensource.com>
	<1349696067-4273-1-git-send-email-ian.campbell@citrix.com>
	<201210111836.53184.jseward@acm.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "valgrind-developers@lists.sourceforge.net"
	<valgrind-developers@lists.sourceforge.net>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Valgrind-developers] [PATCH 1/4] Useful messages
 for sys/domctl interface_version mismatch.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-11 at 17:36 +0100, Julian Seward wrote:
> Please: file a bug report and attach the patches to it.  Else they
> are pretty much guaranteed to wind up at /dev/null, because nobody
> tracks patches on the list AFAIK.

Bart indicated that he intended to apply these.

I'll attach patches to a bug in the future though, thanks for the tip. 

I'll do it for these too if Bart wants me to.

Thanks,
Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 10:18:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 10:18:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNhkL-0001YX-7Z; Mon, 15 Oct 2012 10:18:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TNhkJ-0001YO-Sr
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 10:18:03 +0000
Received: from [85.158.143.99:48942] by server-2.bemta-4.messagelabs.com id
	31/E4-25171-BD2EB705; Mon, 15 Oct 2012 10:18:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1350296282!26610614!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5628 invoked from network); 15 Oct 2012 10:18:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 10:18:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="15166611"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 10:17:31 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 11:17:31 +0100
Message-ID: <1350296250.18058.18.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julian Seward <jseward@acm.org>
Date: Mon, 15 Oct 2012 11:17:30 +0100
In-Reply-To: <201210111836.53184.jseward@acm.org>
References: <1349696046.18008.116.camel@zakaz.uk.xensource.com>
	<1349696067-4273-1-git-send-email-ian.campbell@citrix.com>
	<201210111836.53184.jseward@acm.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "valgrind-developers@lists.sourceforge.net"
	<valgrind-developers@lists.sourceforge.net>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Valgrind-developers] [PATCH 1/4] Useful messages
 for sys/domctl interface_version mismatch.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-11 at 17:36 +0100, Julian Seward wrote:
> Please: file a bug report and attach the patches to it.  Else they
> are pretty much guaranteed to wind up at /dev/null, because nobody
> tracks patches on the list AFAIK.

Bart indicated that he intended to apply these.

I'll attach patches to a bug in the future though, thanks for the tip. 

I'll do it for these too if Bart wants me to.

Thanks,
Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 10:26:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 10:26:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNhs1-0001it-52; Mon, 15 Oct 2012 10:26:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TNhs0-0001io-9O
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 10:26:00 +0000
Received: from [85.158.143.99:30088] by server-1.bemta-4.messagelabs.com id
	73/40-19551-7B4EB705; Mon, 15 Oct 2012 10:25:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1350296759!28849993!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11554 invoked from network); 15 Oct 2012 10:25:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 10:25:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="15166835"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 10:25:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 11:25:58 +0100
Message-ID: <1350296757.18058.21.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Date: Mon, 15 Oct 2012 11:25:57 +0100
In-Reply-To: <20120913160032.GA29082@elgon.mountain>
References: <20120913160032.GA29082@elgon.mountain>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] potential integer overflow in xenbus_file_write()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-09-13 at 19:00 +0300, Dan Carpenter wrote:
> Hi,

Thanks Dan. I'm not sure anyone from Xen-land really monitors
virtualization@. Adding xen-devel and Konrad.

> 
> I was reading some code and had a question in xenbus_file_write()
> 
> drivers/xen/xenbus/xenbus_dev_frontend.c
>    461          if ((len + u->len) > sizeof(u->u.buffer)) {
>                      ^^^^^^^^^^^^
> Can this addition overflow?

len is a size_t and u->len is an unsigned int, so I expect so.

>   Should the test be something like:
> 
> 	if (len > sizeof(u->u.buffer) || len + u->len > sizeof(u->u.buffer)) {

I think that would do it.

Ian.

>    462                  /* On error, dump existing buffer */
>    463                  u->len = 0;
>    464                  rc = -EINVAL;
>    465                  goto out;
>    466          }
>    467  
>    468          ret = copy_from_user(u->u.buffer + u->len, ubuf, len);
>    469  
> 
> regards,
> dan carpenter
> _______________________________________________
> Virtualization mailing list
> Virtualization@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/virtualization
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 10:26:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 10:26:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNhs1-0001it-52; Mon, 15 Oct 2012 10:26:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TNhs0-0001io-9O
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 10:26:00 +0000
Received: from [85.158.143.99:30088] by server-1.bemta-4.messagelabs.com id
	73/40-19551-7B4EB705; Mon, 15 Oct 2012 10:25:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1350296759!28849993!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11554 invoked from network); 15 Oct 2012 10:25:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 10:25:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="15166835"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 10:25:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 11:25:58 +0100
Message-ID: <1350296757.18058.21.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Date: Mon, 15 Oct 2012 11:25:57 +0100
In-Reply-To: <20120913160032.GA29082@elgon.mountain>
References: <20120913160032.GA29082@elgon.mountain>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] potential integer overflow in xenbus_file_write()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-09-13 at 19:00 +0300, Dan Carpenter wrote:
> Hi,

Thanks Dan. I'm not sure anyone from Xen-land really monitors
virtualization@. Adding xen-devel and Konrad.

> 
> I was reading some code and had a question in xenbus_file_write()
> 
> drivers/xen/xenbus/xenbus_dev_frontend.c
>    461          if ((len + u->len) > sizeof(u->u.buffer)) {
>                      ^^^^^^^^^^^^
> Can this addition overflow?

len is a size_t and u->len is an unsigned int, so I expect so.

>   Should the test be something like:
> 
> 	if (len > sizeof(u->u.buffer) || len + u->len > sizeof(u->u.buffer)) {

I think that would do it.

Ian.

>    462                  /* On error, dump existing buffer */
>    463                  u->len = 0;
>    464                  rc = -EINVAL;
>    465                  goto out;
>    466          }
>    467  
>    468          ret = copy_from_user(u->u.buffer + u->len, ubuf, len);
>    469  
> 
> regards,
> dan carpenter
> _______________________________________________
> Virtualization mailing list
> Virtualization@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/virtualization
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 10:28:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 10:28:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNhu9-0001pW-M4; Mon, 15 Oct 2012 10:28:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TNhu8-0001pL-LX
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 10:28:12 +0000
Received: from [85.158.143.99:44748] by server-3.bemta-4.messagelabs.com id
	0D/36-10075-C35EB705; Mon, 15 Oct 2012 10:28:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1350296891!27140436!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 391 invoked from network); 15 Oct 2012 10:28:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 10:28:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="15166888"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 10:27:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 11:27:49 +0100
Message-ID: <1350296868.18058.24.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Date: Mon, 15 Oct 2012 11:27:48 +0100
In-Reply-To: <20120914112427.GA1454@elgon.mountain>
References: <20120914112427.GA1454@elgon.mountain>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Tang Liang <liang.tang@oracle.com>, xen-devel <xen-devel@lists.xen.org>,
	Jeremy Fitzhardinge <jeremy@xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] memory corruption in HYPERVISOR_physdev_op()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-09-14 at 14:24 +0300, Dan Carpenter wrote:
> Hi Jeremy,

Jeremy doesn't work on Xen much any more. Adding Konrad and the
xen-devel@ list.

> My static analyzer complains about potential memory corruption in
> HYPERVISOR_physdev_op()
> 
> arch/x86/include/asm/xen/hypercall.h
>    389  static inline int
>    390  HYPERVISOR_physdev_op(int cmd, void *arg)
>    391  {
>    392          int rc = _hypercall2(int, physdev_op, cmd, arg);
>    393          if (unlikely(rc == -ENOSYS)) {
>    394                  struct physdev_op op;
>    395                  op.cmd = cmd;
>    396                  memcpy(&op.u, arg, sizeof(op.u));
>    397                  rc = _hypercall1(int, physdev_op_compat, &op);
>    398                  memcpy(arg, &op.u, sizeof(op.u));
>                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Some of the arg buffers are not as large as sizeof(op.u) which is either
> 12 or 16 depending on the size of longs in struct physdev_apic.

Nasty!

> 
>    399          }
>    400          return rc;
>    401  }
> 
> One example of this is in xen_initdom_restore_msi_irqs().
> 
> arch/x86/pci/xen.c
>    337                  struct physdev_pci_device restore_ext;
>    338  
>    339                  restore_ext.seg = pci_domain_nr(dev->bus);
>    340                  restore_ext.bus = dev->bus->number;
>    341                  restore_ext.devfn = dev->devfn;
>    342                  ret = HYPERVISOR_physdev_op(PHYSDEVOP_restore_msi_ext,
>    343                                          &restore_ext);
>                                                 ^^^^^^^^^^^^
> There are only 4 bytes here.
> 
>    344                  if (ret == -ENOSYS)
>                             ^^^^^^^^^^^^^^
> If we hit this condition, we have corrupted some memory.

I can see the memory corruption but how does it relate to ret ==
-ENOSYS?

> 
>    345                          pci_seg_supported = false;
> 
> regards,
> dan carpenter
> _______________________________________________
> Virtualization mailing list
> Virtualization@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/virtualization
> 

-- 
Ian Campbell
Current Noise: Therapy? - Femtex

Riffle West Virginia is so small that the Boy Scout had to double as the
town drunk.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 10:28:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 10:28:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNhu9-0001pW-M4; Mon, 15 Oct 2012 10:28:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TNhu8-0001pL-LX
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 10:28:12 +0000
Received: from [85.158.143.99:44748] by server-3.bemta-4.messagelabs.com id
	0D/36-10075-C35EB705; Mon, 15 Oct 2012 10:28:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1350296891!27140436!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 391 invoked from network); 15 Oct 2012 10:28:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 10:28:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="15166888"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 10:27:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 11:27:49 +0100
Message-ID: <1350296868.18058.24.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Date: Mon, 15 Oct 2012 11:27:48 +0100
In-Reply-To: <20120914112427.GA1454@elgon.mountain>
References: <20120914112427.GA1454@elgon.mountain>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Tang Liang <liang.tang@oracle.com>, xen-devel <xen-devel@lists.xen.org>,
	Jeremy Fitzhardinge <jeremy@xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] memory corruption in HYPERVISOR_physdev_op()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-09-14 at 14:24 +0300, Dan Carpenter wrote:
> Hi Jeremy,

Jeremy doesn't work on Xen much any more. Adding Konrad and the
xen-devel@ list.

> My static analyzer complains about potential memory corruption in
> HYPERVISOR_physdev_op()
> 
> arch/x86/include/asm/xen/hypercall.h
>    389  static inline int
>    390  HYPERVISOR_physdev_op(int cmd, void *arg)
>    391  {
>    392          int rc = _hypercall2(int, physdev_op, cmd, arg);
>    393          if (unlikely(rc == -ENOSYS)) {
>    394                  struct physdev_op op;
>    395                  op.cmd = cmd;
>    396                  memcpy(&op.u, arg, sizeof(op.u));
>    397                  rc = _hypercall1(int, physdev_op_compat, &op);
>    398                  memcpy(arg, &op.u, sizeof(op.u));
>                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Some of the arg buffers are not as large as sizeof(op.u) which is either
> 12 or 16 depending on the size of longs in struct physdev_apic.

Nasty!

> 
>    399          }
>    400          return rc;
>    401  }
> 
> One example of this is in xen_initdom_restore_msi_irqs().
> 
> arch/x86/pci/xen.c
>    337                  struct physdev_pci_device restore_ext;
>    338  
>    339                  restore_ext.seg = pci_domain_nr(dev->bus);
>    340                  restore_ext.bus = dev->bus->number;
>    341                  restore_ext.devfn = dev->devfn;
>    342                  ret = HYPERVISOR_physdev_op(PHYSDEVOP_restore_msi_ext,
>    343                                          &restore_ext);
>                                                 ^^^^^^^^^^^^
> There are only 4 bytes here.
> 
>    344                  if (ret == -ENOSYS)
>                             ^^^^^^^^^^^^^^
> If we hit this condition, we have corrupted some memory.

I can see the memory corruption but how does it relate to ret ==
-ENOSYS?

> 
>    345                          pci_seg_supported = false;
> 
> regards,
> dan carpenter
> _______________________________________________
> Virtualization mailing list
> Virtualization@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/virtualization
> 

-- 
Ian Campbell
Current Noise: Therapy? - Femtex

Riffle West Virginia is so small that the Boy Scout had to double as the
town drunk.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 10:32:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 10:32:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNhy0-00020C-BT; Mon, 15 Oct 2012 10:32:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>)
	id 1TNhxy-0001zz-Qd; Mon, 15 Oct 2012 10:32:11 +0000
Received: from [85.158.137.99:53491] by server-14.bemta-3.messagelabs.com id
	62/42-17276-926EB705; Mon, 15 Oct 2012 10:32:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1350297129!16263255!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19588 invoked from network); 15 Oct 2012 10:32:09 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-217.messagelabs.com with SMTP;
	15 Oct 2012 10:32:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 15 Oct 2012 11:32:09 +0100
Message-Id: <507C024602000078000A155C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 15 Oct 2012 11:32:06 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Mauro" <mrsanna1@gmail.com>, "Olivier Hanesse" <olivier.hanesse@gmail.com>
References: <AANLkTikptc2POrKQgJuoVZRdwJTo64DJ_hm12KuPky4D@mail.gmail.com>
	<b1ca6ddc-ca69-447e-93e9-8d36d1ff4a43@default>
	<AANLkTinK94GDOF_GeaVs50wK0u8EdZ2rtzPuh65ca8qR@mail.gmail.com>
	<CAE17a0UPyzsNn=ps9MxarkGg=ns8dCpVz0qBDvesT2AOskwfVg@mail.gmail.com>
	<65395f62-74e5-4910-b701-8df629c2ce3b@default>
	<CABx4GKrQxOOQo_uUXSFvy0nzdMp1A_qc=_e4K+88GkB7xv=9nw@mail.gmail.com>
	<CAE17a0VkMuUEG9VaM7AFrwcsEjVBq9RfvTWz1_KmscAyCxeAbA@mail.gmail.com>
	<CABx4GKqrTEV7CEnAVUfYr-+yky8N5P1U29xDbrESH-mHB0iZhQ@mail.gmail.com>
	<CAE17a0UYwqLxoZaVDgQCvUR2KQK4vvP3bkvsdrwgnsUp33xuNQ@mail.gmail.com>
	<CAE17a0UQocJjZc38c2805uYvdwR7e447UGH9ywcxMw1Ge3imfg@mail.gmail.com>
	<20120930151314.GU8912@reaktio.net>
	<CAE17a0WWvpwW-V5hQOgL1CiuVZFKyzhZVZfTVq74ZsJUo1SE8w@mail.gmail.com>
	<CAE17a0WvLyduj4V68qPJRLcjc5V7xZ=iTNprKWJyGAX_6RXC+Q@mail.gmail.com>
	<CABx4GKr-AxZmCyGmd4qenMtgdo2Yg+UnT4ymbONjBtuS+w=g7Q@mail.gmail.com>
In-Reply-To: <CABx4GKr-AxZmCyGmd4qenMtgdo2Yg+UnT4ymbONjBtuS+w=g7Q@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>, Jeremy Fitzhardinge <jeremy@goop.org>,
	Keir Fraser <keir.xen@gmail.com>,
	Xen Users <xen-users@lists.xensource.com>,
	Mark Adams <mark@campbell-lange.net>
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.10.12 at 09:39, Olivier Hanesse <olivier.hanesse@gmail.com> wrote:
> For the record, always the same errors :
> 
> xm dmesg => (XEN) Platform timer appears to have unexpectedly wrapped 10 or
> more times.

This is what needs to be analyzed: For it to happen, timer softirqs
must not occur for quite long a period of time, and it needs to be
determined what that is. Since only very few people can actually
see this problem, we depend on at least some data collection
(including figuring out what hardware and/or software components
are involved in surfacing the problem) being done by them.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 10:32:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 10:32:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNhy0-00020C-BT; Mon, 15 Oct 2012 10:32:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>)
	id 1TNhxy-0001zz-Qd; Mon, 15 Oct 2012 10:32:11 +0000
Received: from [85.158.137.99:53491] by server-14.bemta-3.messagelabs.com id
	62/42-17276-926EB705; Mon, 15 Oct 2012 10:32:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1350297129!16263255!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19588 invoked from network); 15 Oct 2012 10:32:09 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-217.messagelabs.com with SMTP;
	15 Oct 2012 10:32:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 15 Oct 2012 11:32:09 +0100
Message-Id: <507C024602000078000A155C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 15 Oct 2012 11:32:06 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Mauro" <mrsanna1@gmail.com>, "Olivier Hanesse" <olivier.hanesse@gmail.com>
References: <AANLkTikptc2POrKQgJuoVZRdwJTo64DJ_hm12KuPky4D@mail.gmail.com>
	<b1ca6ddc-ca69-447e-93e9-8d36d1ff4a43@default>
	<AANLkTinK94GDOF_GeaVs50wK0u8EdZ2rtzPuh65ca8qR@mail.gmail.com>
	<CAE17a0UPyzsNn=ps9MxarkGg=ns8dCpVz0qBDvesT2AOskwfVg@mail.gmail.com>
	<65395f62-74e5-4910-b701-8df629c2ce3b@default>
	<CABx4GKrQxOOQo_uUXSFvy0nzdMp1A_qc=_e4K+88GkB7xv=9nw@mail.gmail.com>
	<CAE17a0VkMuUEG9VaM7AFrwcsEjVBq9RfvTWz1_KmscAyCxeAbA@mail.gmail.com>
	<CABx4GKqrTEV7CEnAVUfYr-+yky8N5P1U29xDbrESH-mHB0iZhQ@mail.gmail.com>
	<CAE17a0UYwqLxoZaVDgQCvUR2KQK4vvP3bkvsdrwgnsUp33xuNQ@mail.gmail.com>
	<CAE17a0UQocJjZc38c2805uYvdwR7e447UGH9ywcxMw1Ge3imfg@mail.gmail.com>
	<20120930151314.GU8912@reaktio.net>
	<CAE17a0WWvpwW-V5hQOgL1CiuVZFKyzhZVZfTVq74ZsJUo1SE8w@mail.gmail.com>
	<CAE17a0WvLyduj4V68qPJRLcjc5V7xZ=iTNprKWJyGAX_6RXC+Q@mail.gmail.com>
	<CABx4GKr-AxZmCyGmd4qenMtgdo2Yg+UnT4ymbONjBtuS+w=g7Q@mail.gmail.com>
In-Reply-To: <CABx4GKr-AxZmCyGmd4qenMtgdo2Yg+UnT4ymbONjBtuS+w=g7Q@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>, Jeremy Fitzhardinge <jeremy@goop.org>,
	Keir Fraser <keir.xen@gmail.com>,
	Xen Users <xen-users@lists.xensource.com>,
	Mark Adams <mark@campbell-lange.net>
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.10.12 at 09:39, Olivier Hanesse <olivier.hanesse@gmail.com> wrote:
> For the record, always the same errors :
> 
> xm dmesg => (XEN) Platform timer appears to have unexpectedly wrapped 10 or
> more times.

This is what needs to be analyzed: For it to happen, timer softirqs
must not occur for quite long a period of time, and it needs to be
determined what that is. Since only very few people can actually
see this problem, we depend on at least some data collection
(including figuring out what hardware and/or software components
are involved in surfacing the problem) being done by them.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 10:32:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 10:32:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNhyR-000247-En; Mon, 15 Oct 2012 10:32:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1TNhyQ-00023v-Jn
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 10:32:38 +0000
Received: from [85.158.143.99:6321] by server-2.bemta-4.messagelabs.com id
	9D/2D-25171-546EB705; Mon, 15 Oct 2012 10:32:37 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-6.tower-216.messagelabs.com!1350297156!27141194!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18495 invoked from network); 15 Oct 2012 10:32:37 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-6.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	15 Oct 2012 10:32:37 -0000
Received: from 50-66-ftth.onsneteindhoven.nl ([88.159.66.50]:56738
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from <linux@eikelenboom.it>)
	id 1TNhzz-0001T1-7Q; Mon, 15 Oct 2012 12:34:15 +0200
Date: Mon, 15 Oct 2012 12:32:35 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <692244188.20121015123235@eikelenboom.it>
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <patchbomb.1350295789@cosworth.uk.xensource.com>
References: <patchbomb.1350295789@cosworth.uk.xensource.com>
MIME-Version: 1.0
Cc: ian.jackson@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl shutdown compatibility with xm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Hi Ian,

Great thanks !
Only thing i was wondering about:

Shouldn't the "-F" option be dropped in favour of always trying the "acpi fallback" when the pv shutdown fails.

This because the shutdown scripts still don't work for domains without pv shutdown and i don't see a down side to just trying that as fallback.

--

Sander


Monday, October 15, 2012, 12:09:49 PM, you wrote:

> The following implements xm compatibility for the xl shutdown command
> and a prerequisite bug fix.

> In particular add --all and --wait which are used by the xendomains
> initscript. It also adds the same options to xl reboot.

> Lastly it cleans up and simplifies option parsing.

> The xl shutdown/reboot patches should go into 4.2.1, the option
> parsing cleanups should not.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 10:32:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 10:32:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNhyR-000247-En; Mon, 15 Oct 2012 10:32:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1TNhyQ-00023v-Jn
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 10:32:38 +0000
Received: from [85.158.143.99:6321] by server-2.bemta-4.messagelabs.com id
	9D/2D-25171-546EB705; Mon, 15 Oct 2012 10:32:37 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-6.tower-216.messagelabs.com!1350297156!27141194!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18495 invoked from network); 15 Oct 2012 10:32:37 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-6.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	15 Oct 2012 10:32:37 -0000
Received: from 50-66-ftth.onsneteindhoven.nl ([88.159.66.50]:56738
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from <linux@eikelenboom.it>)
	id 1TNhzz-0001T1-7Q; Mon, 15 Oct 2012 12:34:15 +0200
Date: Mon, 15 Oct 2012 12:32:35 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <692244188.20121015123235@eikelenboom.it>
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <patchbomb.1350295789@cosworth.uk.xensource.com>
References: <patchbomb.1350295789@cosworth.uk.xensource.com>
MIME-Version: 1.0
Cc: ian.jackson@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl shutdown compatibility with xm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Hi Ian,

Great thanks !
Only thing i was wondering about:

Shouldn't the "-F" option be dropped in favour of always trying the "acpi fallback" when the pv shutdown fails.

This because the shutdown scripts still don't work for domains without pv shutdown and i don't see a down side to just trying that as fallback.

--

Sander


Monday, October 15, 2012, 12:09:49 PM, you wrote:

> The following implements xm compatibility for the xl shutdown command
> and a prerequisite bug fix.

> In particular add --all and --wait which are used by the xendomains
> initscript. It also adds the same options to xl reboot.

> Lastly it cleans up and simplifies option parsing.

> The xl shutdown/reboot patches should go into 4.2.1, the option
> parsing cleanups should not.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 10:38:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 10:38:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNi42-0002eC-8u; Mon, 15 Oct 2012 10:38:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TNi40-0002e7-EK
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 10:38:24 +0000
Received: from [85.158.139.83:12347] by server-15.bemta-5.messagelabs.com id
	0E/3B-28599-F97EB705; Mon, 15 Oct 2012 10:38:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1350297503!32038674!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8630 invoked from network); 15 Oct 2012 10:38:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 10:38:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="15167189"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 10:37:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 11:37:58 +0100
Message-ID: <1350297477.18058.27.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Date: Mon, 15 Oct 2012 11:37:57 +0100
In-Reply-To: <692244188.20121015123235@eikelenboom.it>
References: <patchbomb.1350295789@cosworth.uk.xensource.com>
	<692244188.20121015123235@eikelenboom.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl shutdown compatibility with xm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-10-15 at 11:32 +0100, Sander Eikelenboom wrote:
> Hi Ian,
> 
> Great thanks !
> Only thing i was wondering about:
> 
> Shouldn't the "-F" option be dropped in favour of always trying the
> "acpi fallback" when the pv shutdown fails.
> 
> This because the shutdown scripts still don't work for domains without
> pv shutdown and i don't see a down side to just trying that as
> fallback.

It is guess OS dependent what the ACPI button press event does, it can
reboot, shutdown or hibernate etc depending on the OS type and its
configuration. (in theory I suppose it is completely arbitrary e.g. it
could be configured to eject the CD-ROM or something equally random).

Therefore the user needs to be aware of when they can safely use it.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 10:38:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 10:38:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNi42-0002eC-8u; Mon, 15 Oct 2012 10:38:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TNi40-0002e7-EK
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 10:38:24 +0000
Received: from [85.158.139.83:12347] by server-15.bemta-5.messagelabs.com id
	0E/3B-28599-F97EB705; Mon, 15 Oct 2012 10:38:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1350297503!32038674!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8630 invoked from network); 15 Oct 2012 10:38:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 10:38:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="15167189"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 10:37:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 11:37:58 +0100
Message-ID: <1350297477.18058.27.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Date: Mon, 15 Oct 2012 11:37:57 +0100
In-Reply-To: <692244188.20121015123235@eikelenboom.it>
References: <patchbomb.1350295789@cosworth.uk.xensource.com>
	<692244188.20121015123235@eikelenboom.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl shutdown compatibility with xm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-10-15 at 11:32 +0100, Sander Eikelenboom wrote:
> Hi Ian,
> 
> Great thanks !
> Only thing i was wondering about:
> 
> Shouldn't the "-F" option be dropped in favour of always trying the
> "acpi fallback" when the pv shutdown fails.
> 
> This because the shutdown scripts still don't work for domains without
> pv shutdown and i don't see a down side to just trying that as
> fallback.

It is guess OS dependent what the ACPI button press event does, it can
reboot, shutdown or hibernate etc depending on the OS type and its
configuration. (in theory I suppose it is completely arbitrary e.g. it
could be configured to eject the CD-ROM or something equally random).

Therefore the user needs to be aware of when they can safely use it.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 10:48:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 10:48:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNiDv-0002sM-CV; Mon, 15 Oct 2012 10:48:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TNiDt-0002sH-Q7
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 10:48:38 +0000
Received: from [85.158.139.83:33769] by server-12.bemta-5.messagelabs.com id
	9C/FA-26919-40AEB705; Mon, 15 Oct 2012 10:48:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1350298116!32685665!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32360 invoked from network); 15 Oct 2012 10:48:36 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-182.messagelabs.com with SMTP;
	15 Oct 2012 10:48:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 15 Oct 2012 11:48:35 +0100
Message-Id: <507C062002000078000A1574@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 15 Oct 2012 11:48:32 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"Dan Carpenter" <dan.carpenter@oracle.com>
References: <20120914112427.GA1454@elgon.mountain>
	<1350296868.18058.24.camel@zakaz.uk.xensource.com>
In-Reply-To: <1350296868.18058.24.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tang Liang <liang.tang@oracle.com>, xen-devel <xen-devel@lists.xen.org>,
	Jeremy Fitzhardinge <jeremy@xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] memory corruption in HYPERVISOR_physdev_op()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.10.12 at 12:27, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Fri, 2012-09-14 at 14:24 +0300, Dan Carpenter wrote:
>> My static analyzer complains about potential memory corruption in
>> HYPERVISOR_physdev_op()
>> 
>> arch/x86/include/asm/xen/hypercall.h
>>    389  static inline int
>>    390  HYPERVISOR_physdev_op(int cmd, void *arg)
>>    391  {
>>    392          int rc = _hypercall2(int, physdev_op, cmd, arg);
>>    393          if (unlikely(rc == -ENOSYS)) {
>>    394                  struct physdev_op op;
>>    395                  op.cmd = cmd;
>>    396                  memcpy(&op.u, arg, sizeof(op.u));
>>    397                  rc = _hypercall1(int, physdev_op_compat, &op);
>>    398                  memcpy(arg, &op.u, sizeof(op.u));
>>                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> Some of the arg buffers are not as large as sizeof(op.u) which is either
>> 12 or 16 depending on the size of longs in struct physdev_apic.
> 
> Nasty!

Wasn't it that pv-ops expects Xen 4.0.1 or newer anyway? If so,
what does this code exist for in the first place (it's framed by
#if CONFIG_XEN_COMPAT <= 0x030002 in the Xenified kernel)?

>>    399          }
>>    400          return rc;
>>    401  }
>> 
>> One example of this is in xen_initdom_restore_msi_irqs().
>> 
>> arch/x86/pci/xen.c
>>    337                  struct physdev_pci_device restore_ext;
>>    338  
>>    339                  restore_ext.seg = pci_domain_nr(dev->bus);
>>    340                  restore_ext.bus = dev->bus->number;
>>    341                  restore_ext.devfn = dev->devfn;
>>    342                  ret = 
> HYPERVISOR_physdev_op(PHYSDEVOP_restore_msi_ext,
>>    343                                          &restore_ext);
>>                                                 ^^^^^^^^^^^^
>> There are only 4 bytes here.
>> 
>>    344                  if (ret == -ENOSYS)
>>                             ^^^^^^^^^^^^^^
>> If we hit this condition, we have corrupted some memory.
> 
> I can see the memory corruption but how does it relate to ret ==
> -ENOSYS?

The (supposedly) corrupting code site inside an

	if (unlikely(rc == -ENOSYS)) {

Supposedly because as long as the argument passed to the
function is in memory accessed by the local CPU only and
doesn't overlap with storage used for "rc" (e.g. living in a
register), there's no corruption possible afaict - the second
memcpy() would just copy back what the first one obtained
from there.

Fixing this other than by removing the broken code would be
pretty hard I'm afraid (and I tend to leave the code untouched
altogether in the Xenified tree).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 10:48:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 10:48:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNiDv-0002sM-CV; Mon, 15 Oct 2012 10:48:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TNiDt-0002sH-Q7
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 10:48:38 +0000
Received: from [85.158.139.83:33769] by server-12.bemta-5.messagelabs.com id
	9C/FA-26919-40AEB705; Mon, 15 Oct 2012 10:48:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1350298116!32685665!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32360 invoked from network); 15 Oct 2012 10:48:36 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-182.messagelabs.com with SMTP;
	15 Oct 2012 10:48:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 15 Oct 2012 11:48:35 +0100
Message-Id: <507C062002000078000A1574@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 15 Oct 2012 11:48:32 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"Dan Carpenter" <dan.carpenter@oracle.com>
References: <20120914112427.GA1454@elgon.mountain>
	<1350296868.18058.24.camel@zakaz.uk.xensource.com>
In-Reply-To: <1350296868.18058.24.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tang Liang <liang.tang@oracle.com>, xen-devel <xen-devel@lists.xen.org>,
	Jeremy Fitzhardinge <jeremy@xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] memory corruption in HYPERVISOR_physdev_op()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.10.12 at 12:27, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Fri, 2012-09-14 at 14:24 +0300, Dan Carpenter wrote:
>> My static analyzer complains about potential memory corruption in
>> HYPERVISOR_physdev_op()
>> 
>> arch/x86/include/asm/xen/hypercall.h
>>    389  static inline int
>>    390  HYPERVISOR_physdev_op(int cmd, void *arg)
>>    391  {
>>    392          int rc = _hypercall2(int, physdev_op, cmd, arg);
>>    393          if (unlikely(rc == -ENOSYS)) {
>>    394                  struct physdev_op op;
>>    395                  op.cmd = cmd;
>>    396                  memcpy(&op.u, arg, sizeof(op.u));
>>    397                  rc = _hypercall1(int, physdev_op_compat, &op);
>>    398                  memcpy(arg, &op.u, sizeof(op.u));
>>                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> Some of the arg buffers are not as large as sizeof(op.u) which is either
>> 12 or 16 depending on the size of longs in struct physdev_apic.
> 
> Nasty!

Wasn't it that pv-ops expects Xen 4.0.1 or newer anyway? If so,
what does this code exist for in the first place (it's framed by
#if CONFIG_XEN_COMPAT <= 0x030002 in the Xenified kernel)?

>>    399          }
>>    400          return rc;
>>    401  }
>> 
>> One example of this is in xen_initdom_restore_msi_irqs().
>> 
>> arch/x86/pci/xen.c
>>    337                  struct physdev_pci_device restore_ext;
>>    338  
>>    339                  restore_ext.seg = pci_domain_nr(dev->bus);
>>    340                  restore_ext.bus = dev->bus->number;
>>    341                  restore_ext.devfn = dev->devfn;
>>    342                  ret = 
> HYPERVISOR_physdev_op(PHYSDEVOP_restore_msi_ext,
>>    343                                          &restore_ext);
>>                                                 ^^^^^^^^^^^^
>> There are only 4 bytes here.
>> 
>>    344                  if (ret == -ENOSYS)
>>                             ^^^^^^^^^^^^^^
>> If we hit this condition, we have corrupted some memory.
> 
> I can see the memory corruption but how does it relate to ret ==
> -ENOSYS?

The (supposedly) corrupting code site inside an

	if (unlikely(rc == -ENOSYS)) {

Supposedly because as long as the argument passed to the
function is in memory accessed by the local CPU only and
doesn't overlap with storage used for "rc" (e.g. living in a
register), there's no corruption possible afaict - the second
memcpy() would just copy back what the first one obtained
from there.

Fixing this other than by removing the broken code would be
pretty hard I'm afraid (and I tend to leave the code untouched
altogether in the Xenified tree).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 10:53:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 10:53:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNiIr-00033u-7w; Mon, 15 Oct 2012 10:53:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TNiIq-00033n-Ey
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 10:53:44 +0000
Received: from [85.158.137.99:49014] by server-16.bemta-3.messagelabs.com id
	DE/0A-16565-73BEB705; Mon, 15 Oct 2012 10:53:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1350298423!18461242!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9556 invoked from network); 15 Oct 2012 10:53:43 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-217.messagelabs.com with SMTP;
	15 Oct 2012 10:53:43 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 15 Oct 2012 11:53:42 +0100
Message-Id: <507C075302000078000A1593@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 15 Oct 2012 11:53:39 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Allan Scheid" <avs.009@gmail.com>
References: <CANchcZy0qiahQ86wGzW3YjfvkF1mW_KKNxkfruM0N+_ELzow4A@mail.gmail.com>
In-Reply-To: <CANchcZy0qiahQ86wGzW3YjfvkF1mW_KKNxkfruM0N+_ELzow4A@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2 with EFI on IBM x3650 ACPI Bug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 11.10.12 at 06:09, Allan Scheid <avs.009@gmail.com> wrote:
> Hellow all, i need help to fix this bug:
> 
> ACPI BIOS Bug: Error: A valid RSDP was not found (20120711/tbxfroot-219)
> 
> Because of this first errors i get this after, and it causes don't work USB
> ports and some PCI cards on the system:
> 
> can't find IRQ for PCI INT A; please try using pci=biosirq
> 
> Kernel: 3.6.1-xen self compiled (work perfect without xen multiboot)
> Xen Version: 4.2
> Grub2 EFI: 1.99-23

If you really boot vie grub2, then that is your problem - you
ought to boot directly from EFI. Please check the available
documentation (http://xenbits.xen.org/docs/unstable/misc/efi.html).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 10:53:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 10:53:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNiIr-00033u-7w; Mon, 15 Oct 2012 10:53:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TNiIq-00033n-Ey
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 10:53:44 +0000
Received: from [85.158.137.99:49014] by server-16.bemta-3.messagelabs.com id
	DE/0A-16565-73BEB705; Mon, 15 Oct 2012 10:53:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1350298423!18461242!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9556 invoked from network); 15 Oct 2012 10:53:43 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-217.messagelabs.com with SMTP;
	15 Oct 2012 10:53:43 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 15 Oct 2012 11:53:42 +0100
Message-Id: <507C075302000078000A1593@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 15 Oct 2012 11:53:39 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Allan Scheid" <avs.009@gmail.com>
References: <CANchcZy0qiahQ86wGzW3YjfvkF1mW_KKNxkfruM0N+_ELzow4A@mail.gmail.com>
In-Reply-To: <CANchcZy0qiahQ86wGzW3YjfvkF1mW_KKNxkfruM0N+_ELzow4A@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2 with EFI on IBM x3650 ACPI Bug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 11.10.12 at 06:09, Allan Scheid <avs.009@gmail.com> wrote:
> Hellow all, i need help to fix this bug:
> 
> ACPI BIOS Bug: Error: A valid RSDP was not found (20120711/tbxfroot-219)
> 
> Because of this first errors i get this after, and it causes don't work USB
> ports and some PCI cards on the system:
> 
> can't find IRQ for PCI INT A; please try using pci=biosirq
> 
> Kernel: 3.6.1-xen self compiled (work perfect without xen multiboot)
> Xen Version: 4.2
> Grub2 EFI: 1.99-23

If you really boot vie grub2, then that is your problem - you
ought to boot directly from EFI. Please check the available
documentation (http://xenbits.xen.org/docs/unstable/misc/efi.html).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 11:00:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 11:00:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNiOn-0003Eu-1B; Mon, 15 Oct 2012 10:59:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TNiOl-0003Ep-Kr
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 10:59:51 +0000
Received: from [85.158.143.35:7117] by server-2.bemta-4.messagelabs.com id
	37/97-25171-6ACEB705; Mon, 15 Oct 2012 10:59:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1350298710!14387316!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23751 invoked from network); 15 Oct 2012 10:58:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 10:58:38 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="15167672"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 10:58:18 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 11:58:18 +0100
Message-ID: <1350298696.18058.33.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 15 Oct 2012 11:58:16 +0100
In-Reply-To: <507C062002000078000A1574@nat28.tlf.novell.com>
References: <20120914112427.GA1454@elgon.mountain>
	<1350296868.18058.24.camel@zakaz.uk.xensource.com>
	<507C062002000078000A1574@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge <jeremy@xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>, Tang Liang <liang.tang@oracle.com>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	Dan Carpenter <dan.carpenter@oracle.com>
Subject: Re: [Xen-devel] memory corruption in HYPERVISOR_physdev_op()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-10-15 at 11:48 +0100, Jan Beulich wrote:
> >>> On 15.10.12 at 12:27, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Fri, 2012-09-14 at 14:24 +0300, Dan Carpenter wrote:
> >> My static analyzer complains about potential memory corruption in
> >> HYPERVISOR_physdev_op()
> >> 
> >> arch/x86/include/asm/xen/hypercall.h
> >>    389  static inline int
> >>    390  HYPERVISOR_physdev_op(int cmd, void *arg)
> >>    391  {
> >>    392          int rc = _hypercall2(int, physdev_op, cmd, arg);
> >>    393          if (unlikely(rc == -ENOSYS)) {
> >>    394                  struct physdev_op op;
> >>    395                  op.cmd = cmd;
> >>    396                  memcpy(&op.u, arg, sizeof(op.u));
> >>    397                  rc = _hypercall1(int, physdev_op_compat, &op);
> >>    398                  memcpy(arg, &op.u, sizeof(op.u));
> >>                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >> Some of the arg buffers are not as large as sizeof(op.u) which is either
> >> 12 or 16 depending on the size of longs in struct physdev_apic.
> > 
> > Nasty!
> 
> Wasn't it that pv-ops expects Xen 4.0.1 or newer anyway? If so,
> what does this code exist for in the first place (it's framed by
> #if CONFIG_XEN_COMPAT <= 0x030002 in the Xenified kernel)?

I think the 4.0.1 or newer requirement is for dom0 only. I guess physdev
op is only used in dom0 though? Or does passthrough need it?

> 
> >>    399          }
> >>    400          return rc;
> >>    401  }
> >> 
> >> One example of this is in xen_initdom_restore_msi_irqs().
> >> 
> >> arch/x86/pci/xen.c
> >>    337                  struct physdev_pci_device restore_ext;
> >>    338  
> >>    339                  restore_ext.seg = pci_domain_nr(dev->bus);
> >>    340                  restore_ext.bus = dev->bus->number;
> >>    341                  restore_ext.devfn = dev->devfn;
> >>    342                  ret = 
> > HYPERVISOR_physdev_op(PHYSDEVOP_restore_msi_ext,
> >>    343                                          &restore_ext);
> >>                                                 ^^^^^^^^^^^^
> >> There are only 4 bytes here.
> >> 
> >>    344                  if (ret == -ENOSYS)
> >>                             ^^^^^^^^^^^^^^
> >> If we hit this condition, we have corrupted some memory.
> > 
> > I can see the memory corruption but how does it relate to ret ==
> > -ENOSYS?
> 
> The (supposedly) corrupting code site inside an
> 
> 	if (unlikely(rc == -ENOSYS)) {

Ah, for some reason I assumed this was in the eventual caller, even
though it was staring me right in the face in the full quote.

> Supposedly because as long as the argument passed to the
> function is in memory accessed by the local CPU only and
> doesn't overlap with storage used for "rc" (e.g. living in a
> register), there's no corruption possible afaict - the second
> memcpy() would just copy back what the first one obtained
> from there.
> 
> Fixing this other than by removing the broken code would be
> pretty hard I'm afraid (and I tend to leave the code untouched
> altogether in the Xenified tree).

Given that it is compat code the list of subops which needs to supported
in this case is small and finite so a simple lookup table or even switch
stmt for the size might be an option.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 11:00:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 11:00:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNiOn-0003Eu-1B; Mon, 15 Oct 2012 10:59:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TNiOl-0003Ep-Kr
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 10:59:51 +0000
Received: from [85.158.143.35:7117] by server-2.bemta-4.messagelabs.com id
	37/97-25171-6ACEB705; Mon, 15 Oct 2012 10:59:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1350298710!14387316!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23751 invoked from network); 15 Oct 2012 10:58:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 10:58:38 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="15167672"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 10:58:18 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 11:58:18 +0100
Message-ID: <1350298696.18058.33.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 15 Oct 2012 11:58:16 +0100
In-Reply-To: <507C062002000078000A1574@nat28.tlf.novell.com>
References: <20120914112427.GA1454@elgon.mountain>
	<1350296868.18058.24.camel@zakaz.uk.xensource.com>
	<507C062002000078000A1574@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge <jeremy@xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>, Tang Liang <liang.tang@oracle.com>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	Dan Carpenter <dan.carpenter@oracle.com>
Subject: Re: [Xen-devel] memory corruption in HYPERVISOR_physdev_op()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-10-15 at 11:48 +0100, Jan Beulich wrote:
> >>> On 15.10.12 at 12:27, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Fri, 2012-09-14 at 14:24 +0300, Dan Carpenter wrote:
> >> My static analyzer complains about potential memory corruption in
> >> HYPERVISOR_physdev_op()
> >> 
> >> arch/x86/include/asm/xen/hypercall.h
> >>    389  static inline int
> >>    390  HYPERVISOR_physdev_op(int cmd, void *arg)
> >>    391  {
> >>    392          int rc = _hypercall2(int, physdev_op, cmd, arg);
> >>    393          if (unlikely(rc == -ENOSYS)) {
> >>    394                  struct physdev_op op;
> >>    395                  op.cmd = cmd;
> >>    396                  memcpy(&op.u, arg, sizeof(op.u));
> >>    397                  rc = _hypercall1(int, physdev_op_compat, &op);
> >>    398                  memcpy(arg, &op.u, sizeof(op.u));
> >>                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >> Some of the arg buffers are not as large as sizeof(op.u) which is either
> >> 12 or 16 depending on the size of longs in struct physdev_apic.
> > 
> > Nasty!
> 
> Wasn't it that pv-ops expects Xen 4.0.1 or newer anyway? If so,
> what does this code exist for in the first place (it's framed by
> #if CONFIG_XEN_COMPAT <= 0x030002 in the Xenified kernel)?

I think the 4.0.1 or newer requirement is for dom0 only. I guess physdev
op is only used in dom0 though? Or does passthrough need it?

> 
> >>    399          }
> >>    400          return rc;
> >>    401  }
> >> 
> >> One example of this is in xen_initdom_restore_msi_irqs().
> >> 
> >> arch/x86/pci/xen.c
> >>    337                  struct physdev_pci_device restore_ext;
> >>    338  
> >>    339                  restore_ext.seg = pci_domain_nr(dev->bus);
> >>    340                  restore_ext.bus = dev->bus->number;
> >>    341                  restore_ext.devfn = dev->devfn;
> >>    342                  ret = 
> > HYPERVISOR_physdev_op(PHYSDEVOP_restore_msi_ext,
> >>    343                                          &restore_ext);
> >>                                                 ^^^^^^^^^^^^
> >> There are only 4 bytes here.
> >> 
> >>    344                  if (ret == -ENOSYS)
> >>                             ^^^^^^^^^^^^^^
> >> If we hit this condition, we have corrupted some memory.
> > 
> > I can see the memory corruption but how does it relate to ret ==
> > -ENOSYS?
> 
> The (supposedly) corrupting code site inside an
> 
> 	if (unlikely(rc == -ENOSYS)) {

Ah, for some reason I assumed this was in the eventual caller, even
though it was staring me right in the face in the full quote.

> Supposedly because as long as the argument passed to the
> function is in memory accessed by the local CPU only and
> doesn't overlap with storage used for "rc" (e.g. living in a
> register), there's no corruption possible afaict - the second
> memcpy() would just copy back what the first one obtained
> from there.
> 
> Fixing this other than by removing the broken code would be
> pretty hard I'm afraid (and I tend to leave the code untouched
> altogether in the Xenified tree).

Given that it is compat code the list of subops which needs to supported
in this case is small and finite so a simple lookup table or even switch
stmt for the size might be an option.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 11:12:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 11:12:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNial-0003VZ-B4; Mon, 15 Oct 2012 11:12:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TNiaj-0003VU-J8
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 11:12:13 +0000
Received: from [85.158.138.51:17042] by server-5.bemta-3.messagelabs.com id
	A3/17-12440-C8FEB705; Mon, 15 Oct 2012 11:12:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1350299532!28072620!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19045 invoked from network); 15 Oct 2012 11:12:12 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-174.messagelabs.com with SMTP;
	15 Oct 2012 11:12:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 15 Oct 2012 12:12:11 +0100
Message-Id: <507C0BA702000078000A15A9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 15 Oct 2012 12:12:07 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <5073DAFB.4040004@amd.com>
In-Reply-To: <5073DAFB.4040004@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86/amd: Fix xen_apic_write warnings in Dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 09.10.12 at 10:06, Wei Wang <wei.wang2@amd.com> wrote:
>--- a/xen/arch/x86/cpu/amd.c
>+++ b/xen/arch/x86/cpu/amd.c
>@@ -485,6 +485,17 @@ static void __devinit init_amd(struct cpuinfo_x86 *c)
> 	if (c->x86 > 0x11)
> 		set_bit(X86_FEATURE_ARAT, c->x86_capability);
> 
>+	/* 
>+	 * Prior to Family 0x14, perf counters are not reset during warm reboot.  
>+	 * We have to reset them manually.
>+	 */
>+	if (c->x86 < 0x14) {
>+		wrmsrl(MSR_K7_PERFCTR0, 0);
>+		wrmsrl(MSR_K7_PERFCTR1, 0);
>+		wrmsrl(MSR_K7_PERFCTR2, 0);
>+		wrmsrl(MSR_K7_PERFCTR3, 0);
>+	}

This collides with the NMI watchdog setup: smp_callin() calls
setup_local_APIC() _before_ calling smp_store_cpu_info(), and
hence you write zero again to an MSR possibly already in use.
Since setup_k7_watchdog() itself does the clearing of the MSRs
in question already, I would think that the most simple
adjustment to your patch would be to make the condition

	if (nmi_watchdog != NMI_LOCAL_APIC && c->x86 < 0x14) {

If you agree (and Keir doesn't object), I would commit it that way.

Jan

>+
> 	if (cpuid_edx(0x80000007) & (1 << 10)) {
> 		rdmsr(MSR_K7_HWCR, l, h);
> 		l |= (1 << 27); /* Enable read-only APERF/MPERF bit */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 11:12:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 11:12:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNial-0003VZ-B4; Mon, 15 Oct 2012 11:12:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TNiaj-0003VU-J8
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 11:12:13 +0000
Received: from [85.158.138.51:17042] by server-5.bemta-3.messagelabs.com id
	A3/17-12440-C8FEB705; Mon, 15 Oct 2012 11:12:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1350299532!28072620!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19045 invoked from network); 15 Oct 2012 11:12:12 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-174.messagelabs.com with SMTP;
	15 Oct 2012 11:12:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 15 Oct 2012 12:12:11 +0100
Message-Id: <507C0BA702000078000A15A9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 15 Oct 2012 12:12:07 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <5073DAFB.4040004@amd.com>
In-Reply-To: <5073DAFB.4040004@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86/amd: Fix xen_apic_write warnings in Dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 09.10.12 at 10:06, Wei Wang <wei.wang2@amd.com> wrote:
>--- a/xen/arch/x86/cpu/amd.c
>+++ b/xen/arch/x86/cpu/amd.c
>@@ -485,6 +485,17 @@ static void __devinit init_amd(struct cpuinfo_x86 *c)
> 	if (c->x86 > 0x11)
> 		set_bit(X86_FEATURE_ARAT, c->x86_capability);
> 
>+	/* 
>+	 * Prior to Family 0x14, perf counters are not reset during warm reboot.  
>+	 * We have to reset them manually.
>+	 */
>+	if (c->x86 < 0x14) {
>+		wrmsrl(MSR_K7_PERFCTR0, 0);
>+		wrmsrl(MSR_K7_PERFCTR1, 0);
>+		wrmsrl(MSR_K7_PERFCTR2, 0);
>+		wrmsrl(MSR_K7_PERFCTR3, 0);
>+	}

This collides with the NMI watchdog setup: smp_callin() calls
setup_local_APIC() _before_ calling smp_store_cpu_info(), and
hence you write zero again to an MSR possibly already in use.
Since setup_k7_watchdog() itself does the clearing of the MSRs
in question already, I would think that the most simple
adjustment to your patch would be to make the condition

	if (nmi_watchdog != NMI_LOCAL_APIC && c->x86 < 0x14) {

If you agree (and Keir doesn't object), I would commit it that way.

Jan

>+
> 	if (cpuid_edx(0x80000007) & (1 << 10)) {
> 		rdmsr(MSR_K7_HWCR, l, h);
> 		l |= (1 << 27); /* Enable read-only APERF/MPERF bit */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 11:22:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 11:22:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNijx-0003fL-Ei; Mon, 15 Oct 2012 11:21:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1TNijv-0003fG-O5
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 11:21:43 +0000
Received: from [85.158.138.51:2143] by server-10.bemta-3.messagelabs.com id
	EE/D6-27386-6C1FB705; Mon, 15 Oct 2012 11:21:42 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-11.tower-174.messagelabs.com!1350300102!34395007!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16276 invoked from network); 15 Oct 2012 11:21:42 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-11.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	15 Oct 2012 11:21:42 -0000
Received: from 50-66-ftth.onsneteindhoven.nl ([88.159.66.50]:57039
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from <linux@eikelenboom.it>)
	id 1TNilT-0001i1-K2; Mon, 15 Oct 2012 13:23:19 +0200
Date: Mon, 15 Oct 2012 13:21:40 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <751865457.20121015132140@eikelenboom.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1350297477.18058.27.camel@zakaz.uk.xensource.com>
References: <patchbomb.1350295789@cosworth.uk.xensource.com>
	<692244188.20121015123235@eikelenboom.it>
	<1350297477.18058.27.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl shutdown compatibility with xm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Monday, October 15, 2012, 12:37:57 PM, you wrote:

> On Mon, 2012-10-15 at 11:32 +0100, Sander Eikelenboom wrote:
>> Hi Ian,
>> 
>> Great thanks !
>> Only thing i was wondering about:
>> 
>> Shouldn't the "-F" option be dropped in favour of always trying the
>> "acpi fallback" when the pv shutdown fails.
>> 
>> This because the shutdown scripts still don't work for domains without
>> pv shutdown and i don't see a down side to just trying that as
>> fallback.

> It is guess OS dependent what the ACPI button press event does, it can
> reboot, shutdown or hibernate etc depending on the OS type and its
> configuration. (in theory I suppose it is completely arbitrary e.g. it
> could be configured to eject the CD-ROM or something equally random).

> Therefore the user needs to be aware of when they can safely use it.

Well yes and no:
    - can't remember having (to make) that choice with xm ?
    - On shutdown with xl as toolstack and when the guest doesn't support pv shutdown, the init.d/xendomains script doesn't even attempt to shutdown this guest by acpi fallback.
    - As a result when using xl as toolstack, the guest is terminated non gracefully when the whole machine finally shutsdown, which seems less desirable then at least *trying* to shut it down gracefully by using the acpi button.

> Ian.





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 11:22:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 11:22:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNijx-0003fL-Ei; Mon, 15 Oct 2012 11:21:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1TNijv-0003fG-O5
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 11:21:43 +0000
Received: from [85.158.138.51:2143] by server-10.bemta-3.messagelabs.com id
	EE/D6-27386-6C1FB705; Mon, 15 Oct 2012 11:21:42 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-11.tower-174.messagelabs.com!1350300102!34395007!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16276 invoked from network); 15 Oct 2012 11:21:42 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-11.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	15 Oct 2012 11:21:42 -0000
Received: from 50-66-ftth.onsneteindhoven.nl ([88.159.66.50]:57039
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from <linux@eikelenboom.it>)
	id 1TNilT-0001i1-K2; Mon, 15 Oct 2012 13:23:19 +0200
Date: Mon, 15 Oct 2012 13:21:40 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <751865457.20121015132140@eikelenboom.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1350297477.18058.27.camel@zakaz.uk.xensource.com>
References: <patchbomb.1350295789@cosworth.uk.xensource.com>
	<692244188.20121015123235@eikelenboom.it>
	<1350297477.18058.27.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl shutdown compatibility with xm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Monday, October 15, 2012, 12:37:57 PM, you wrote:

> On Mon, 2012-10-15 at 11:32 +0100, Sander Eikelenboom wrote:
>> Hi Ian,
>> 
>> Great thanks !
>> Only thing i was wondering about:
>> 
>> Shouldn't the "-F" option be dropped in favour of always trying the
>> "acpi fallback" when the pv shutdown fails.
>> 
>> This because the shutdown scripts still don't work for domains without
>> pv shutdown and i don't see a down side to just trying that as
>> fallback.

> It is guess OS dependent what the ACPI button press event does, it can
> reboot, shutdown or hibernate etc depending on the OS type and its
> configuration. (in theory I suppose it is completely arbitrary e.g. it
> could be configured to eject the CD-ROM or something equally random).

> Therefore the user needs to be aware of when they can safely use it.

Well yes and no:
    - can't remember having (to make) that choice with xm ?
    - On shutdown with xl as toolstack and when the guest doesn't support pv shutdown, the init.d/xendomains script doesn't even attempt to shutdown this guest by acpi fallback.
    - As a result when using xl as toolstack, the guest is terminated non gracefully when the whole machine finally shutsdown, which seems less desirable then at least *trying* to shut it down gracefully by using the acpi button.

> Ian.





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 11:27:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 11:27:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNip6-0003uZ-Ul; Mon, 15 Oct 2012 11:27:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1TNip5-0003uO-Gw
	for Xen-devel@lists.xen.org; Mon, 15 Oct 2012 11:27:03 +0000
Received: from [85.158.143.99:41574] by server-3.bemta-4.messagelabs.com id
	66/17-10075-603FB705; Mon, 15 Oct 2012 11:27:02 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1350300421!28032208!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20973 invoked from network); 15 Oct 2012 11:27:02 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 11:27:02 -0000
Received: by mail-vc0-f173.google.com with SMTP id fl15so7025456vcb.32
	for <Xen-devel@lists.xen.org>; Mon, 15 Oct 2012 04:27:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=4f9Efdopf3nRuGkDURjUuQV6w+wlNNKTGAD8HdxBovU=;
	b=cWZOzutoTjtfav5/wo8hjDd1l0p/a6wi+lr1XfQSK14G7rgmiyr99HPkYSMPNKHnEr
	w27RizmTVRoafp+DGPEuioj+qc1XizyKQPK5gvMw8gnLLYgOOCHTPPv9LSkgvv7r6dAw
	amiL37S+LFZRNCanb5ixguMiqpjBRGrnMfZRa0euzWLXSKJmStNfvAnapySqcyZjSPbM
	ccrUvNoooBYWFxqYotz1N2ykYFypPNC980gp+jeRTVM3MCVMcjuY10KqAVumxyLkusX2
	9DY9LrDcPcrUnj6TQ1E9RLMI+4MKlkI/5jZgpvyT6cUMezZWigS+URRXVP5DeE97Vakm
	5nTg==
MIME-Version: 1.0
Received: by 10.52.71.9 with SMTP id q9mr5302978vdu.36.1350300420988; Mon, 15
	Oct 2012 04:27:00 -0700 (PDT)
Received: by 10.58.231.138 with HTTP; Mon, 15 Oct 2012 04:27:00 -0700 (PDT)
In-Reply-To: <1350287790.14440.1.camel@dagon.hellion.org.uk>
References: <CAN=sCCEuPqhapvBR2eSTvALQeKbwshmT5=MvSiX3FoMW+vg_aA@mail.gmail.com>
	<1349263669.650.131.camel@zakaz.uk.xensource.com>
	<CAN=sCCGSvu9_xLXnMRhKY6fr1WD+ittsjpKRF6fVFnwtgB9niQ@mail.gmail.com>
	<1349266207.650.137.camel@zakaz.uk.xensource.com>
	<CAN=sCCEtV1PS-a7MtSjsX=XKRqQCoabvNUY-F1xD-sjMmrJE+A@mail.gmail.com>
	<CAN=sCCFcsZUZYKiOVqOF=DzM8VpSEEOSUfmjLh2+DKOrkG+b2g@mail.gmail.com>
	<CAN=sCCGWU4Wpg9QfFaoPLUBmo_rXTf4h=F4g+ES0CHFhGU=0KQ@mail.gmail.com>
	<1349278604.650.162.camel@zakaz.uk.xensource.com>
	<CAN=sCCEO63JgWCUbosP5+exL4aU=yjaM_VPOxbjh6=C6r8CAhg@mail.gmail.com>
	<1349282150.650.181.camel@zakaz.uk.xensource.com>
	<20121014110311.GD8912@reaktio.net>
	<1350287790.14440.1.camel@dagon.hellion.org.uk>
Date: Mon, 15 Oct 2012 12:27:00 +0100
X-Google-Sender-Auth: J_agwPlMKMKCAa2oo_6kWQi2aO0
Message-ID: <CAFLBxZbpXLhX8ij4YqAm+3oEJbeAGEZz2=O8YVfc4tj8pRBCbg@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Valtteri Kiviniemi <kiviniemi.valtteri@gmail.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0, xl toolstack cant launch older domUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 15, 2012 at 8:56 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > It appears that xend includes some sort of workaround for this which xl
>> > does not.
>> >
>>
>> So from a user's point-of-view this is a regression in xl..
>> similar workaround probably should be added in xl to be able to run old guests?
>
> I don't know when I'm going to have time to look into this. Patches
> gratefully received.

I suppose this kind of thing should be tracked, to make sure it
doesn't fall on the floor.  I'll add it to my list (with no owner
ATM).

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 11:27:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 11:27:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNip6-0003uZ-Ul; Mon, 15 Oct 2012 11:27:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1TNip5-0003uO-Gw
	for Xen-devel@lists.xen.org; Mon, 15 Oct 2012 11:27:03 +0000
Received: from [85.158.143.99:41574] by server-3.bemta-4.messagelabs.com id
	66/17-10075-603FB705; Mon, 15 Oct 2012 11:27:02 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1350300421!28032208!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20973 invoked from network); 15 Oct 2012 11:27:02 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 11:27:02 -0000
Received: by mail-vc0-f173.google.com with SMTP id fl15so7025456vcb.32
	for <Xen-devel@lists.xen.org>; Mon, 15 Oct 2012 04:27:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=4f9Efdopf3nRuGkDURjUuQV6w+wlNNKTGAD8HdxBovU=;
	b=cWZOzutoTjtfav5/wo8hjDd1l0p/a6wi+lr1XfQSK14G7rgmiyr99HPkYSMPNKHnEr
	w27RizmTVRoafp+DGPEuioj+qc1XizyKQPK5gvMw8gnLLYgOOCHTPPv9LSkgvv7r6dAw
	amiL37S+LFZRNCanb5ixguMiqpjBRGrnMfZRa0euzWLXSKJmStNfvAnapySqcyZjSPbM
	ccrUvNoooBYWFxqYotz1N2ykYFypPNC980gp+jeRTVM3MCVMcjuY10KqAVumxyLkusX2
	9DY9LrDcPcrUnj6TQ1E9RLMI+4MKlkI/5jZgpvyT6cUMezZWigS+URRXVP5DeE97Vakm
	5nTg==
MIME-Version: 1.0
Received: by 10.52.71.9 with SMTP id q9mr5302978vdu.36.1350300420988; Mon, 15
	Oct 2012 04:27:00 -0700 (PDT)
Received: by 10.58.231.138 with HTTP; Mon, 15 Oct 2012 04:27:00 -0700 (PDT)
In-Reply-To: <1350287790.14440.1.camel@dagon.hellion.org.uk>
References: <CAN=sCCEuPqhapvBR2eSTvALQeKbwshmT5=MvSiX3FoMW+vg_aA@mail.gmail.com>
	<1349263669.650.131.camel@zakaz.uk.xensource.com>
	<CAN=sCCGSvu9_xLXnMRhKY6fr1WD+ittsjpKRF6fVFnwtgB9niQ@mail.gmail.com>
	<1349266207.650.137.camel@zakaz.uk.xensource.com>
	<CAN=sCCEtV1PS-a7MtSjsX=XKRqQCoabvNUY-F1xD-sjMmrJE+A@mail.gmail.com>
	<CAN=sCCFcsZUZYKiOVqOF=DzM8VpSEEOSUfmjLh2+DKOrkG+b2g@mail.gmail.com>
	<CAN=sCCGWU4Wpg9QfFaoPLUBmo_rXTf4h=F4g+ES0CHFhGU=0KQ@mail.gmail.com>
	<1349278604.650.162.camel@zakaz.uk.xensource.com>
	<CAN=sCCEO63JgWCUbosP5+exL4aU=yjaM_VPOxbjh6=C6r8CAhg@mail.gmail.com>
	<1349282150.650.181.camel@zakaz.uk.xensource.com>
	<20121014110311.GD8912@reaktio.net>
	<1350287790.14440.1.camel@dagon.hellion.org.uk>
Date: Mon, 15 Oct 2012 12:27:00 +0100
X-Google-Sender-Auth: J_agwPlMKMKCAa2oo_6kWQi2aO0
Message-ID: <CAFLBxZbpXLhX8ij4YqAm+3oEJbeAGEZz2=O8YVfc4tj8pRBCbg@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Valtteri Kiviniemi <kiviniemi.valtteri@gmail.com>,
	"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0, xl toolstack cant launch older domUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 15, 2012 at 8:56 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > It appears that xend includes some sort of workaround for this which xl
>> > does not.
>> >
>>
>> So from a user's point-of-view this is a regression in xl..
>> similar workaround probably should be added in xl to be able to run old guests?
>
> I don't know when I'm going to have time to look into this. Patches
> gratefully received.

I suppose this kind of thing should be tracked, to make sure it
doesn't fall on the floor.  I'll add it to my list (with no owner
ATM).

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 11:30:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 11:30:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNisM-00047W-Iw; Mon, 15 Oct 2012 11:30:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mrsanna1@gmail.com>)
	id 1TNimh-0003lN-CE; Mon, 15 Oct 2012 11:24:35 +0000
Received: from [85.158.139.211:40246] by server-2.bemta-5.messagelabs.com id
	7A/3B-10520-272FB705; Mon, 15 Oct 2012 11:24:34 +0000
X-Env-Sender: mrsanna1@gmail.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1350300272!21890620!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26695 invoked from network); 15 Oct 2012 11:24:33 -0000
Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com)
	(209.85.212.43)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 11:24:33 -0000
Received: by mail-vb0-f43.google.com with SMTP id fq11so6368153vbb.30
	for <multiple recipients>; Mon, 15 Oct 2012 04:24:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=L2TGyE+3bbbOkgzJX4E1lR6luEbxECJh5H974N+/XGU=;
	b=UwSAu4zk7pHsvPaMZUf3f2y3HlvInwHBTg9/URxHUxAGhIMO1f9noROd2eOzt/F/vC
	zonIQGwmBTJ9np2oMd+EJg53d8Xnqz7x2Dvg+V1kN2DJlDTGDUW4dygIfjAdmsQwz2ON
	zLv56qEKhz9HREPaOThav4jM07vIH7G7O4jmroyEyWyXK8wRTY6HctjOcGwpo+QNieux
	0q1XCG1SBV1XkDqA6uOWHi10va/9KDi6Ir9h0DEVAqnpBtU1iJmoD5yTYpuGa8sUc5y7
	QF0VbsOFAJZy2ZXpV2Nw7viSGvGZNXv0Qd7qohNFyey/CnL1ZHvCiSBfSZp+R+ooNjhp
	TrdA==
MIME-Version: 1.0
Received: by 10.220.247.140 with SMTP id mc12mr6543255vcb.0.1350300272353;
	Mon, 15 Oct 2012 04:24:32 -0700 (PDT)
Received: by 10.58.207.75 with HTTP; Mon, 15 Oct 2012 04:24:32 -0700 (PDT)
In-Reply-To: <507C024602000078000A155C@nat28.tlf.novell.com>
References: <AANLkTikptc2POrKQgJuoVZRdwJTo64DJ_hm12KuPky4D@mail.gmail.com>
	<b1ca6ddc-ca69-447e-93e9-8d36d1ff4a43@default>
	<AANLkTinK94GDOF_GeaVs50wK0u8EdZ2rtzPuh65ca8qR@mail.gmail.com>
	<CAE17a0UPyzsNn=ps9MxarkGg=ns8dCpVz0qBDvesT2AOskwfVg@mail.gmail.com>
	<65395f62-74e5-4910-b701-8df629c2ce3b@default>
	<CABx4GKrQxOOQo_uUXSFvy0nzdMp1A_qc=_e4K+88GkB7xv=9nw@mail.gmail.com>
	<CAE17a0VkMuUEG9VaM7AFrwcsEjVBq9RfvTWz1_KmscAyCxeAbA@mail.gmail.com>
	<CABx4GKqrTEV7CEnAVUfYr-+yky8N5P1U29xDbrESH-mHB0iZhQ@mail.gmail.com>
	<CAE17a0UYwqLxoZaVDgQCvUR2KQK4vvP3bkvsdrwgnsUp33xuNQ@mail.gmail.com>
	<CAE17a0UQocJjZc38c2805uYvdwR7e447UGH9ywcxMw1Ge3imfg@mail.gmail.com>
	<20120930151314.GU8912@reaktio.net>
	<CAE17a0WWvpwW-V5hQOgL1CiuVZFKyzhZVZfTVq74ZsJUo1SE8w@mail.gmail.com>
	<CAE17a0WvLyduj4V68qPJRLcjc5V7xZ=iTNprKWJyGAX_6RXC+Q@mail.gmail.com>
	<CABx4GKr-AxZmCyGmd4qenMtgdo2Yg+UnT4ymbONjBtuS+w=g7Q@mail.gmail.com>
	<507C024602000078000A155C@nat28.tlf.novell.com>
Date: Mon, 15 Oct 2012 13:24:32 +0200
Message-ID: <CAE17a0VUOoqtGbghmmXq_4SWQUH3dwBHPoezH1j98efFEAUVvQ@mail.gmail.com>
From: Mauro <mrsanna1@gmail.com>
To: Jan Beulich <JBeulich@suse.com>
X-Mailman-Approved-At: Mon, 15 Oct 2012 11:30:25 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>, Dan Magenheimer <dan.magenheimer@oracle.com>,
	Olivier Hanesse <olivier.hanesse@gmail.com>,
	Keir Fraser <keir.xen@gmail.com>,
	Xen Users <xen-users@lists.xensource.com>,
	Mark Adams <mark@campbell-lange.net>
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 15 October 2012 12:32, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 15.10.12 at 09:39, Olivier Hanesse <olivier.hanesse@gmail.com> wrote:
>> For the record, always the same errors :
>>
>> xm dmesg => (XEN) Platform timer appears to have unexpectedly wrapped 10 or
>> more times.
>
> This is what needs to be analyzed: For it to happen, timer softirqs
> must not occur for quite long a period of time, and it needs to be
> determined what that is. Since only very few people can actually
> see this problem, we depend on at least some data collection
> (including figuring out what hardware and/or software components
> are involved in surfacing the problem) being done by them.

I have the problem on this hardware type:

Hp Proliant DL580 G5 with four Intel(R) Xeon(R) CPU E7330  @ 2.40GHz.
It seem that
GRUB_CMDLINE_XEN="clocksource=pit cpuidle=0"
put in in /etc/default/grup (I use linux debian)
solves the problem for me.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 11:30:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 11:30:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNisM-00047W-Iw; Mon, 15 Oct 2012 11:30:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mrsanna1@gmail.com>)
	id 1TNimh-0003lN-CE; Mon, 15 Oct 2012 11:24:35 +0000
Received: from [85.158.139.211:40246] by server-2.bemta-5.messagelabs.com id
	7A/3B-10520-272FB705; Mon, 15 Oct 2012 11:24:34 +0000
X-Env-Sender: mrsanna1@gmail.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1350300272!21890620!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26695 invoked from network); 15 Oct 2012 11:24:33 -0000
Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com)
	(209.85.212.43)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 11:24:33 -0000
Received: by mail-vb0-f43.google.com with SMTP id fq11so6368153vbb.30
	for <multiple recipients>; Mon, 15 Oct 2012 04:24:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=L2TGyE+3bbbOkgzJX4E1lR6luEbxECJh5H974N+/XGU=;
	b=UwSAu4zk7pHsvPaMZUf3f2y3HlvInwHBTg9/URxHUxAGhIMO1f9noROd2eOzt/F/vC
	zonIQGwmBTJ9np2oMd+EJg53d8Xnqz7x2Dvg+V1kN2DJlDTGDUW4dygIfjAdmsQwz2ON
	zLv56qEKhz9HREPaOThav4jM07vIH7G7O4jmroyEyWyXK8wRTY6HctjOcGwpo+QNieux
	0q1XCG1SBV1XkDqA6uOWHi10va/9KDi6Ir9h0DEVAqnpBtU1iJmoD5yTYpuGa8sUc5y7
	QF0VbsOFAJZy2ZXpV2Nw7viSGvGZNXv0Qd7qohNFyey/CnL1ZHvCiSBfSZp+R+ooNjhp
	TrdA==
MIME-Version: 1.0
Received: by 10.220.247.140 with SMTP id mc12mr6543255vcb.0.1350300272353;
	Mon, 15 Oct 2012 04:24:32 -0700 (PDT)
Received: by 10.58.207.75 with HTTP; Mon, 15 Oct 2012 04:24:32 -0700 (PDT)
In-Reply-To: <507C024602000078000A155C@nat28.tlf.novell.com>
References: <AANLkTikptc2POrKQgJuoVZRdwJTo64DJ_hm12KuPky4D@mail.gmail.com>
	<b1ca6ddc-ca69-447e-93e9-8d36d1ff4a43@default>
	<AANLkTinK94GDOF_GeaVs50wK0u8EdZ2rtzPuh65ca8qR@mail.gmail.com>
	<CAE17a0UPyzsNn=ps9MxarkGg=ns8dCpVz0qBDvesT2AOskwfVg@mail.gmail.com>
	<65395f62-74e5-4910-b701-8df629c2ce3b@default>
	<CABx4GKrQxOOQo_uUXSFvy0nzdMp1A_qc=_e4K+88GkB7xv=9nw@mail.gmail.com>
	<CAE17a0VkMuUEG9VaM7AFrwcsEjVBq9RfvTWz1_KmscAyCxeAbA@mail.gmail.com>
	<CABx4GKqrTEV7CEnAVUfYr-+yky8N5P1U29xDbrESH-mHB0iZhQ@mail.gmail.com>
	<CAE17a0UYwqLxoZaVDgQCvUR2KQK4vvP3bkvsdrwgnsUp33xuNQ@mail.gmail.com>
	<CAE17a0UQocJjZc38c2805uYvdwR7e447UGH9ywcxMw1Ge3imfg@mail.gmail.com>
	<20120930151314.GU8912@reaktio.net>
	<CAE17a0WWvpwW-V5hQOgL1CiuVZFKyzhZVZfTVq74ZsJUo1SE8w@mail.gmail.com>
	<CAE17a0WvLyduj4V68qPJRLcjc5V7xZ=iTNprKWJyGAX_6RXC+Q@mail.gmail.com>
	<CABx4GKr-AxZmCyGmd4qenMtgdo2Yg+UnT4ymbONjBtuS+w=g7Q@mail.gmail.com>
	<507C024602000078000A155C@nat28.tlf.novell.com>
Date: Mon, 15 Oct 2012 13:24:32 +0200
Message-ID: <CAE17a0VUOoqtGbghmmXq_4SWQUH3dwBHPoezH1j98efFEAUVvQ@mail.gmail.com>
From: Mauro <mrsanna1@gmail.com>
To: Jan Beulich <JBeulich@suse.com>
X-Mailman-Approved-At: Mon, 15 Oct 2012 11:30:25 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>, Dan Magenheimer <dan.magenheimer@oracle.com>,
	Olivier Hanesse <olivier.hanesse@gmail.com>,
	Keir Fraser <keir.xen@gmail.com>,
	Xen Users <xen-users@lists.xensource.com>,
	Mark Adams <mark@campbell-lange.net>
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 15 October 2012 12:32, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 15.10.12 at 09:39, Olivier Hanesse <olivier.hanesse@gmail.com> wrote:
>> For the record, always the same errors :
>>
>> xm dmesg => (XEN) Platform timer appears to have unexpectedly wrapped 10 or
>> more times.
>
> This is what needs to be analyzed: For it to happen, timer softirqs
> must not occur for quite long a period of time, and it needs to be
> determined what that is. Since only very few people can actually
> see this problem, we depend on at least some data collection
> (including figuring out what hardware and/or software components
> are involved in surfacing the problem) being done by them.

I have the problem on this hardware type:

Hp Proliant DL580 G5 with four Intel(R) Xeon(R) CPU E7330  @ 2.40GHz.
It seem that
GRUB_CMDLINE_XEN="clocksource=pit cpuidle=0"
put in in /etc/default/grup (I use linux debian)
solves the problem for me.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 11:46:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 11:46:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNj79-0004Vh-7E; Mon, 15 Oct 2012 11:45:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TNj77-0004Vc-Q1
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 11:45:41 +0000
Received: from [85.158.143.35:58446] by server-3.bemta-4.messagelabs.com id
	92/84-10075-567FB705; Mon, 15 Oct 2012 11:45:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1350301536!14394755!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8678 invoked from network); 15 Oct 2012 11:45:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 11:45:37 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="15169014"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 11:45:35 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 12:45:35 +0100
Message-ID: <1350301533.18058.35.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Date: Mon, 15 Oct 2012 12:45:33 +0100
In-Reply-To: <751865457.20121015132140@eikelenboom.it>
References: <patchbomb.1350295789@cosworth.uk.xensource.com>
	<692244188.20121015123235@eikelenboom.it>
	<1350297477.18058.27.camel@zakaz.uk.xensource.com>
	<751865457.20121015132140@eikelenboom.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl shutdown compatibility with xm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-10-15 at 12:21 +0100, Sander Eikelenboom wrote:
> Monday, October 15, 2012, 12:37:57 PM, you wrote:
> 
> > On Mon, 2012-10-15 at 11:32 +0100, Sander Eikelenboom wrote:
> >> Hi Ian,
> >> 
> >> Great thanks !
> >> Only thing i was wondering about:
> >> 
> >> Shouldn't the "-F" option be dropped in favour of always trying the
> >> "acpi fallback" when the pv shutdown fails.
> >> 
> >> This because the shutdown scripts still don't work for domains without
> >> pv shutdown and i don't see a down side to just trying that as
> >> fallback.
> 
> > It is guess OS dependent what the ACPI button press event does, it can
> > reboot, shutdown or hibernate etc depending on the OS type and its
> > configuration. (in theory I suppose it is completely arbitrary e.g. it
> > could be configured to eject the CD-ROM or something equally random).
> 
> > Therefore the user needs to be aware of when they can safely use it.
> 
> Well yes and no:
>     - can't remember having (to make) that choice with xm ?

Looks like xend uses SCHEDOP_remote_shutdown. It's unclear to me why
this is better than just shooting the domain with destroy...

>     - On shutdown with xl as toolstack and when the guest doesn't
> support pv shutdown, the init.d/xendomains script doesn't even attempt
> to shutdown this guest by acpi fallback.
>     - As a result when using xl as toolstack, the guest is terminated
> non gracefully when the whole machine finally shutsdown, which seems
> less desirable then at least *trying* to shut it down gracefully by
> using the acpi button.

Using the ACPI fallback is a decision which can only be made locally
with full knowledge of the configuration of the guests.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 11:46:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 11:46:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNj79-0004Vh-7E; Mon, 15 Oct 2012 11:45:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TNj77-0004Vc-Q1
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 11:45:41 +0000
Received: from [85.158.143.35:58446] by server-3.bemta-4.messagelabs.com id
	92/84-10075-567FB705; Mon, 15 Oct 2012 11:45:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1350301536!14394755!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8678 invoked from network); 15 Oct 2012 11:45:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 11:45:37 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="15169014"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 11:45:35 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 12:45:35 +0100
Message-ID: <1350301533.18058.35.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Date: Mon, 15 Oct 2012 12:45:33 +0100
In-Reply-To: <751865457.20121015132140@eikelenboom.it>
References: <patchbomb.1350295789@cosworth.uk.xensource.com>
	<692244188.20121015123235@eikelenboom.it>
	<1350297477.18058.27.camel@zakaz.uk.xensource.com>
	<751865457.20121015132140@eikelenboom.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl shutdown compatibility with xm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-10-15 at 12:21 +0100, Sander Eikelenboom wrote:
> Monday, October 15, 2012, 12:37:57 PM, you wrote:
> 
> > On Mon, 2012-10-15 at 11:32 +0100, Sander Eikelenboom wrote:
> >> Hi Ian,
> >> 
> >> Great thanks !
> >> Only thing i was wondering about:
> >> 
> >> Shouldn't the "-F" option be dropped in favour of always trying the
> >> "acpi fallback" when the pv shutdown fails.
> >> 
> >> This because the shutdown scripts still don't work for domains without
> >> pv shutdown and i don't see a down side to just trying that as
> >> fallback.
> 
> > It is guess OS dependent what the ACPI button press event does, it can
> > reboot, shutdown or hibernate etc depending on the OS type and its
> > configuration. (in theory I suppose it is completely arbitrary e.g. it
> > could be configured to eject the CD-ROM or something equally random).
> 
> > Therefore the user needs to be aware of when they can safely use it.
> 
> Well yes and no:
>     - can't remember having (to make) that choice with xm ?

Looks like xend uses SCHEDOP_remote_shutdown. It's unclear to me why
this is better than just shooting the domain with destroy...

>     - On shutdown with xl as toolstack and when the guest doesn't
> support pv shutdown, the init.d/xendomains script doesn't even attempt
> to shutdown this guest by acpi fallback.
>     - As a result when using xl as toolstack, the guest is terminated
> non gracefully when the whole machine finally shutsdown, which seems
> less desirable then at least *trying* to shut it down gracefully by
> using the acpi button.

Using the ACPI fallback is a decision which can only be made locally
with full knowledge of the configuration of the guests.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 11:51:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 11:51:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNjCt-0004fb-0U; Mon, 15 Oct 2012 11:51:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TNjCr-0004fU-FT
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 11:51:37 +0000
Received: from [85.158.143.99:62465] by server-2.bemta-4.messagelabs.com id
	16/77-25171-8C8FB705; Mon, 15 Oct 2012 11:51:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1350301895!34135038!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2420 invoked from network); 15 Oct 2012 11:51:35 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-216.messagelabs.com with SMTP;
	15 Oct 2012 11:51:35 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 15 Oct 2012 12:51:37 +0100
Message-Id: <507C14E402000078000A15CE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 15 Oct 2012 12:51:32 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <20121012161114.GA21661@jshin-Toonie>
In-Reply-To: <20121012161114.GA21661@jshin-Toonie>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part6F5E49D4.1__="
Cc: Jacob Shin <jacob.shin@amd.com>
Subject: [Xen-devel] [PATCH,
 v2] x86/xenoprof: fix kernel/user mode detection for HVM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part6F5E49D4.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

While trying oprofile under Xen, I noticed that HVM passive domain's
kernel addresses were showing up as user application. It turns out
under HVM get_cpu_user_regs()->cs contains 0x0000beef.

Signed-off-by: Jacob Shin <jacob.shin@amd.com>

Don't cast away const-ness. Use SS instead of CS to determine ring.
Special-case real and protected mode.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/oprofile/xenoprof.c
+++ b/xen/arch/x86/oprofile/xenoprof.c
@@ -74,16 +74,26 @@ int compat_oprof_arch_counter(XEN_GUEST_
     return 0;
 }
=20
-int xenoprofile_get_mode(const struct vcpu *v,
-                         const struct cpu_user_regs *regs)
+int xenoprofile_get_mode(struct vcpu *curr, const struct cpu_user_regs =
*regs)
 {
     if ( !guest_mode(regs) )
         return 2;
=20
-    if ( is_hvm_vcpu(v) )
-        return ((regs->cs & 3) !=3D 3);
+    if ( !is_hvm_vcpu(curr) )
+        return guest_kernel_mode(curr, regs);
=20
-    return guest_kernel_mode(v, regs); =20
+    switch ( hvm_guest_x86_mode(curr) )
+    {
+        struct segment_register ss;
+
+    case 0: /* real mode */
+        return 1;
+    case 1: /* vm86 mode */
+        return 0;
+    default:
+        hvm_get_segment_register(curr, x86_seg_ss, &ss);
+        return (ss.sel & 3) !=3D 3;
+    }
 }
=20
 /*
--- a/xen/include/asm-x86/xenoprof.h
+++ b/xen/include/asm-x86/xenoprof.h
@@ -51,7 +51,7 @@ struct cpu_user_regs;
 void ibs_init(void);
 extern u32 ibs_caps;
=20
-int xenoprofile_get_mode(const struct vcpu *, const struct cpu_user_regs =
*);
+int xenoprofile_get_mode(struct vcpu *, const struct cpu_user_regs *);
=20
 static inline int xenoprof_backtrace_supported(void)
 {




--=__Part6F5E49D4.1__=
Content-Type: text/plain; name="x86-oprof-hvm-mode.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-oprof-hvm-mode.patch"

x86/xenoprof: fix kernel/user mode detection for HVM=0A=0AWhile trying =
oprofile under Xen, I noticed that HVM passive domain's=0Akernel addresses =
were showing up as user application. It turns out=0Aunder HVM get_cpu_user_=
regs()->cs contains 0x0000beef.=0A=0ASigned-off-by: Jacob Shin <jacob.shin@=
amd.com>=0A=0ADon't cast away const-ness. Use SS instead of CS to =
determine ring.=0ASpecial-case real and protected mode.=0A=0ASigned-off-by:=
 Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/oprofile/xenoprof.=
c=0A+++ b/xen/arch/x86/oprofile/xenoprof.c=0A@@ -74,16 +74,26 @@ int =
compat_oprof_arch_counter(XEN_GUEST_=0A     return 0;=0A }=0A =0A-int =
xenoprofile_get_mode(const struct vcpu *v,=0A-                         =
const struct cpu_user_regs *regs)=0A+int xenoprofile_get_mode(struct vcpu =
*curr, const struct cpu_user_regs *regs)=0A {=0A     if ( !guest_mode(regs)=
 )=0A         return 2;=0A =0A-    if ( is_hvm_vcpu(v) )=0A-        return =
((regs->cs & 3) !=3D 3);=0A+    if ( !is_hvm_vcpu(curr) )=0A+        =
return guest_kernel_mode(curr, regs);=0A =0A-    return guest_kernel_mode(v=
, regs);  =0A+    switch ( hvm_guest_x86_mode(curr) )=0A+    {=0A+        =
struct segment_register ss;=0A+=0A+    case 0: /* real mode */=0A+        =
return 1;=0A+    case 1: /* vm86 mode */=0A+        return 0;=0A+    =
default:=0A+        hvm_get_segment_register(curr, x86_seg_ss, &ss);=0A+   =
     return (ss.sel & 3) !=3D 3;=0A+    }=0A }=0A =0A /*=0A--- a/xen/includ=
e/asm-x86/xenoprof.h=0A+++ b/xen/include/asm-x86/xenoprof.h=0A@@ -51,7 =
+51,7 @@ struct cpu_user_regs;=0A void ibs_init(void);=0A extern u32 =
ibs_caps;=0A =0A-int xenoprofile_get_mode(const struct vcpu *, const =
struct cpu_user_regs *);=0A+int xenoprofile_get_mode(struct vcpu *, const =
struct cpu_user_regs *);=0A =0A static inline int xenoprof_backtrace_suppor=
ted(void)=0A {=0A
--=__Part6F5E49D4.1__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__Part6F5E49D4.1__=--


From xen-devel-bounces@lists.xen.org Mon Oct 15 11:51:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 11:51:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNjCt-0004fb-0U; Mon, 15 Oct 2012 11:51:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TNjCr-0004fU-FT
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 11:51:37 +0000
Received: from [85.158.143.99:62465] by server-2.bemta-4.messagelabs.com id
	16/77-25171-8C8FB705; Mon, 15 Oct 2012 11:51:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1350301895!34135038!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2420 invoked from network); 15 Oct 2012 11:51:35 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-216.messagelabs.com with SMTP;
	15 Oct 2012 11:51:35 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 15 Oct 2012 12:51:37 +0100
Message-Id: <507C14E402000078000A15CE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 15 Oct 2012 12:51:32 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <20121012161114.GA21661@jshin-Toonie>
In-Reply-To: <20121012161114.GA21661@jshin-Toonie>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part6F5E49D4.1__="
Cc: Jacob Shin <jacob.shin@amd.com>
Subject: [Xen-devel] [PATCH,
 v2] x86/xenoprof: fix kernel/user mode detection for HVM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part6F5E49D4.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

While trying oprofile under Xen, I noticed that HVM passive domain's
kernel addresses were showing up as user application. It turns out
under HVM get_cpu_user_regs()->cs contains 0x0000beef.

Signed-off-by: Jacob Shin <jacob.shin@amd.com>

Don't cast away const-ness. Use SS instead of CS to determine ring.
Special-case real and protected mode.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/oprofile/xenoprof.c
+++ b/xen/arch/x86/oprofile/xenoprof.c
@@ -74,16 +74,26 @@ int compat_oprof_arch_counter(XEN_GUEST_
     return 0;
 }
=20
-int xenoprofile_get_mode(const struct vcpu *v,
-                         const struct cpu_user_regs *regs)
+int xenoprofile_get_mode(struct vcpu *curr, const struct cpu_user_regs =
*regs)
 {
     if ( !guest_mode(regs) )
         return 2;
=20
-    if ( is_hvm_vcpu(v) )
-        return ((regs->cs & 3) !=3D 3);
+    if ( !is_hvm_vcpu(curr) )
+        return guest_kernel_mode(curr, regs);
=20
-    return guest_kernel_mode(v, regs); =20
+    switch ( hvm_guest_x86_mode(curr) )
+    {
+        struct segment_register ss;
+
+    case 0: /* real mode */
+        return 1;
+    case 1: /* vm86 mode */
+        return 0;
+    default:
+        hvm_get_segment_register(curr, x86_seg_ss, &ss);
+        return (ss.sel & 3) !=3D 3;
+    }
 }
=20
 /*
--- a/xen/include/asm-x86/xenoprof.h
+++ b/xen/include/asm-x86/xenoprof.h
@@ -51,7 +51,7 @@ struct cpu_user_regs;
 void ibs_init(void);
 extern u32 ibs_caps;
=20
-int xenoprofile_get_mode(const struct vcpu *, const struct cpu_user_regs =
*);
+int xenoprofile_get_mode(struct vcpu *, const struct cpu_user_regs *);
=20
 static inline int xenoprof_backtrace_supported(void)
 {




--=__Part6F5E49D4.1__=
Content-Type: text/plain; name="x86-oprof-hvm-mode.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-oprof-hvm-mode.patch"

x86/xenoprof: fix kernel/user mode detection for HVM=0A=0AWhile trying =
oprofile under Xen, I noticed that HVM passive domain's=0Akernel addresses =
were showing up as user application. It turns out=0Aunder HVM get_cpu_user_=
regs()->cs contains 0x0000beef.=0A=0ASigned-off-by: Jacob Shin <jacob.shin@=
amd.com>=0A=0ADon't cast away const-ness. Use SS instead of CS to =
determine ring.=0ASpecial-case real and protected mode.=0A=0ASigned-off-by:=
 Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/oprofile/xenoprof.=
c=0A+++ b/xen/arch/x86/oprofile/xenoprof.c=0A@@ -74,16 +74,26 @@ int =
compat_oprof_arch_counter(XEN_GUEST_=0A     return 0;=0A }=0A =0A-int =
xenoprofile_get_mode(const struct vcpu *v,=0A-                         =
const struct cpu_user_regs *regs)=0A+int xenoprofile_get_mode(struct vcpu =
*curr, const struct cpu_user_regs *regs)=0A {=0A     if ( !guest_mode(regs)=
 )=0A         return 2;=0A =0A-    if ( is_hvm_vcpu(v) )=0A-        return =
((regs->cs & 3) !=3D 3);=0A+    if ( !is_hvm_vcpu(curr) )=0A+        =
return guest_kernel_mode(curr, regs);=0A =0A-    return guest_kernel_mode(v=
, regs);  =0A+    switch ( hvm_guest_x86_mode(curr) )=0A+    {=0A+        =
struct segment_register ss;=0A+=0A+    case 0: /* real mode */=0A+        =
return 1;=0A+    case 1: /* vm86 mode */=0A+        return 0;=0A+    =
default:=0A+        hvm_get_segment_register(curr, x86_seg_ss, &ss);=0A+   =
     return (ss.sel & 3) !=3D 3;=0A+    }=0A }=0A =0A /*=0A--- a/xen/includ=
e/asm-x86/xenoprof.h=0A+++ b/xen/include/asm-x86/xenoprof.h=0A@@ -51,7 =
+51,7 @@ struct cpu_user_regs;=0A void ibs_init(void);=0A extern u32 =
ibs_caps;=0A =0A-int xenoprofile_get_mode(const struct vcpu *, const =
struct cpu_user_regs *);=0A+int xenoprofile_get_mode(struct vcpu *, const =
struct cpu_user_regs *);=0A =0A static inline int xenoprof_backtrace_suppor=
ted(void)=0A {=0A
--=__Part6F5E49D4.1__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__Part6F5E49D4.1__=--


From xen-devel-bounces@lists.xen.org Mon Oct 15 12:09:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 12:09:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNjUF-00056u-9S; Mon, 15 Oct 2012 12:09:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TNjUD-00056p-TV
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 12:09:34 +0000
Received: from [85.158.143.99:11550] by server-3.bemta-4.messagelabs.com id
	95/C9-10075-DFCFB705; Mon, 15 Oct 2012 12:09:33 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1350302972!34198588!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8551 invoked from network); 15 Oct 2012 12:09:32 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 12:09:32 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so3083274eek.32
	for <xen-devel@lists.xen.org>; Mon, 15 Oct 2012 05:09:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=G39zri2LZ26lJiRTNeejgbeOdiJAh/tK2IqH+tV13hM=;
	b=blIedIErnBI2NIksE1WYo/alhYRcnLT6rwf63DkK8osUyCS7L++ETvwXALKdTyOGSg
	QNNY1+pWXg6431xe+5fkVT9HkuinMct7yrc4Iz0XvJQffP8MafQ1Vkr1d+zLCwJ4ti9t
	sZS5/YsJJQoax/B75M7VR9zNhCZdRx9gYmU5RRaFn/XWjWFyZWAs1XOsI6jFctFlTksA
	4DEV5/4LVpOIdZ4ORa8wG+4fSGSTYVFucIcFOyRyp4FBKj6D9kohvIrtI2Q127m0Zane
	6/3uJmxXFJVlsipKLZD30nYiuXNoQS+TGLItvXj4LsCOBMczWiTtIa75k7Yq1UD4y1tm
	f5Lg==
Received: by 10.14.215.69 with SMTP id d45mr15271025eep.16.1350302958342;
	Mon, 15 Oct 2012 05:09:18 -0700 (PDT)
Received: from [192.168.1.69]
	(host86-183-156-141.range86-183.btcentralplus.com. [86.183.156.141])
	by mx.google.com with ESMTPS id i41sm24669509eem.7.2012.10.15.05.09.12
	(version=SSLv3 cipher=OTHER); Mon, 15 Oct 2012 05:09:16 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Mon, 15 Oct 2012 13:09:11 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CCA1BB77.41B08%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH, v2] x86/xenoprof: fix kernel/user mode
	detection for HVM
Thread-Index: Ac2qzeKUWrYDDFbt20OaHQt3yaCPHw==
In-Reply-To: <507C14E402000078000A15CE@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Jacob Shin <jacob.shin@amd.com>
Subject: Re: [Xen-devel] [PATCH,
 v2] x86/xenoprof: fix kernel/user mode detection for HVM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 15/10/2012 12:51, "Jan Beulich" <JBeulich@suse.com> wrote:

> While trying oprofile under Xen, I noticed that HVM passive domain's
> kernel addresses were showing up as user application. It turns out
> under HVM get_cpu_user_regs()->cs contains 0x0000beef.
> 
> Signed-off-by: Jacob Shin <jacob.shin@amd.com>
> 
> Don't cast away const-ness. Use SS instead of CS to determine ring.
> Special-case real and protected mode.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/oprofile/xenoprof.c
> +++ b/xen/arch/x86/oprofile/xenoprof.c
> @@ -74,16 +74,26 @@ int compat_oprof_arch_counter(XEN_GUEST_
>      return 0;
>  }
>  
> -int xenoprofile_get_mode(const struct vcpu *v,
> -                         const struct cpu_user_regs *regs)
> +int xenoprofile_get_mode(struct vcpu *curr, const struct cpu_user_regs *regs)
>  {
>      if ( !guest_mode(regs) )
>          return 2;
>  
> -    if ( is_hvm_vcpu(v) )
> -        return ((regs->cs & 3) != 3);
> +    if ( !is_hvm_vcpu(curr) )
> +        return guest_kernel_mode(curr, regs);
>  
> -    return guest_kernel_mode(v, regs);
> +    switch ( hvm_guest_x86_mode(curr) )
> +    {
> +        struct segment_register ss;
> +
> +    case 0: /* real mode */
> +        return 1;
> +    case 1: /* vm86 mode */
> +        return 0;
> +    default:
> +        hvm_get_segment_register(curr, x86_seg_ss, &ss);
> +        return (ss.sel & 3) != 3;
> +    }
>  }
>  
>  /*
> --- a/xen/include/asm-x86/xenoprof.h
> +++ b/xen/include/asm-x86/xenoprof.h
> @@ -51,7 +51,7 @@ struct cpu_user_regs;
>  void ibs_init(void);
>  extern u32 ibs_caps;
>  
> -int xenoprofile_get_mode(const struct vcpu *, const struct cpu_user_regs *);
> +int xenoprofile_get_mode(struct vcpu *, const struct cpu_user_regs *);
>  
>  static inline int xenoprof_backtrace_supported(void)
>  {
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 12:09:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 12:09:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNjUF-00056u-9S; Mon, 15 Oct 2012 12:09:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TNjUD-00056p-TV
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 12:09:34 +0000
Received: from [85.158.143.99:11550] by server-3.bemta-4.messagelabs.com id
	95/C9-10075-DFCFB705; Mon, 15 Oct 2012 12:09:33 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1350302972!34198588!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8551 invoked from network); 15 Oct 2012 12:09:32 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 12:09:32 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so3083274eek.32
	for <xen-devel@lists.xen.org>; Mon, 15 Oct 2012 05:09:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=G39zri2LZ26lJiRTNeejgbeOdiJAh/tK2IqH+tV13hM=;
	b=blIedIErnBI2NIksE1WYo/alhYRcnLT6rwf63DkK8osUyCS7L++ETvwXALKdTyOGSg
	QNNY1+pWXg6431xe+5fkVT9HkuinMct7yrc4Iz0XvJQffP8MafQ1Vkr1d+zLCwJ4ti9t
	sZS5/YsJJQoax/B75M7VR9zNhCZdRx9gYmU5RRaFn/XWjWFyZWAs1XOsI6jFctFlTksA
	4DEV5/4LVpOIdZ4ORa8wG+4fSGSTYVFucIcFOyRyp4FBKj6D9kohvIrtI2Q127m0Zane
	6/3uJmxXFJVlsipKLZD30nYiuXNoQS+TGLItvXj4LsCOBMczWiTtIa75k7Yq1UD4y1tm
	f5Lg==
Received: by 10.14.215.69 with SMTP id d45mr15271025eep.16.1350302958342;
	Mon, 15 Oct 2012 05:09:18 -0700 (PDT)
Received: from [192.168.1.69]
	(host86-183-156-141.range86-183.btcentralplus.com. [86.183.156.141])
	by mx.google.com with ESMTPS id i41sm24669509eem.7.2012.10.15.05.09.12
	(version=SSLv3 cipher=OTHER); Mon, 15 Oct 2012 05:09:16 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Mon, 15 Oct 2012 13:09:11 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CCA1BB77.41B08%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH, v2] x86/xenoprof: fix kernel/user mode
	detection for HVM
Thread-Index: Ac2qzeKUWrYDDFbt20OaHQt3yaCPHw==
In-Reply-To: <507C14E402000078000A15CE@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Jacob Shin <jacob.shin@amd.com>
Subject: Re: [Xen-devel] [PATCH,
 v2] x86/xenoprof: fix kernel/user mode detection for HVM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 15/10/2012 12:51, "Jan Beulich" <JBeulich@suse.com> wrote:

> While trying oprofile under Xen, I noticed that HVM passive domain's
> kernel addresses were showing up as user application. It turns out
> under HVM get_cpu_user_regs()->cs contains 0x0000beef.
> 
> Signed-off-by: Jacob Shin <jacob.shin@amd.com>
> 
> Don't cast away const-ness. Use SS instead of CS to determine ring.
> Special-case real and protected mode.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/oprofile/xenoprof.c
> +++ b/xen/arch/x86/oprofile/xenoprof.c
> @@ -74,16 +74,26 @@ int compat_oprof_arch_counter(XEN_GUEST_
>      return 0;
>  }
>  
> -int xenoprofile_get_mode(const struct vcpu *v,
> -                         const struct cpu_user_regs *regs)
> +int xenoprofile_get_mode(struct vcpu *curr, const struct cpu_user_regs *regs)
>  {
>      if ( !guest_mode(regs) )
>          return 2;
>  
> -    if ( is_hvm_vcpu(v) )
> -        return ((regs->cs & 3) != 3);
> +    if ( !is_hvm_vcpu(curr) )
> +        return guest_kernel_mode(curr, regs);
>  
> -    return guest_kernel_mode(v, regs);
> +    switch ( hvm_guest_x86_mode(curr) )
> +    {
> +        struct segment_register ss;
> +
> +    case 0: /* real mode */
> +        return 1;
> +    case 1: /* vm86 mode */
> +        return 0;
> +    default:
> +        hvm_get_segment_register(curr, x86_seg_ss, &ss);
> +        return (ss.sel & 3) != 3;
> +    }
>  }
>  
>  /*
> --- a/xen/include/asm-x86/xenoprof.h
> +++ b/xen/include/asm-x86/xenoprof.h
> @@ -51,7 +51,7 @@ struct cpu_user_regs;
>  void ibs_init(void);
>  extern u32 ibs_caps;
>  
> -int xenoprofile_get_mode(const struct vcpu *, const struct cpu_user_regs *);
> +int xenoprofile_get_mode(struct vcpu *, const struct cpu_user_regs *);
>  
>  static inline int xenoprof_backtrace_supported(void)
>  {
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 12:10:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 12:10:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNjUP-00057R-Lu; Mon, 15 Oct 2012 12:09:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TNjUO-00057L-Uz
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 12:09:45 +0000
Received: from [85.158.143.99:12195] by server-3.bemta-4.messagelabs.com id
	BD/1A-10075-80DFB705; Mon, 15 Oct 2012 12:09:44 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1350302972!34198588!2
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9096 invoked from network); 15 Oct 2012 12:09:43 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 12:09:43 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so3083274eek.32
	for <xen-devel@lists.xen.org>; Mon, 15 Oct 2012 05:09:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=OaEoCcoHhVAf6+AYBzheNzp+22d4AgKqE5FU6p/y5EE=;
	b=qFyE+rx/H0BGfrq05aguzjVt7vf5Baxs57OqvyDd4bBSt/GhARPx53OzO3fnH+b71V
	9b0gKhYzQbCoZOOD3OdCQWp/G+qbwq5dY+UKLpur2awEb+ux8sCCxu352ujfStxEULE4
	zDV6Zi49tNzv2NSgJ4XpBKcKr8dk3qAhcSrKMFl4HT/tLmrLsraheGGTivIEDZBL5RLN
	EKa2JYx9z8P+ovnCceYu6wBbG0Z4GkuoPdKUqAIAkhXAzY1gdehhRamTpAnR1N6JgGyu
	fwtQ0vB1fkSByaxn9IrtwIM/grFPuTkKHbxQSUADDV3kg+HAM9mqGz1JUNM8bXwTEdMq
	bsTw==
Received: by 10.14.193.129 with SMTP id k1mr15319285een.13.1350302983702;
	Mon, 15 Oct 2012 05:09:43 -0700 (PDT)
Received: from [192.168.1.69]
	(host86-183-156-141.range86-183.btcentralplus.com. [86.183.156.141])
	by mx.google.com with ESMTPS id s1sm24673919eem.9.2012.10.15.05.09.40
	(version=SSLv3 cipher=OTHER); Mon, 15 Oct 2012 05:09:42 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Mon, 15 Oct 2012 13:09:38 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	Wei Wang <wei.wang2@amd.com>
Message-ID: <CCA1BB92.41B09%keir.xen@gmail.com>
Thread-Topic: [PATCH] x86/amd: Fix xen_apic_write warnings in Dom0
Thread-Index: Ac2qzfKsR66/SZ1rOEq9NX4RHfQslg==
In-Reply-To: <507C0BA702000078000A15A9@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Keir Fraser <keir@xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86/amd: Fix xen_apic_write warnings in Dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 15/10/2012 12:12, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 09.10.12 at 10:06, Wei Wang <wei.wang2@amd.com> wrote:
>> --- a/xen/arch/x86/cpu/amd.c
>> +++ b/xen/arch/x86/cpu/amd.c
>> @@ -485,6 +485,17 @@ static void __devinit init_amd(struct cpuinfo_x86 *c)
>> if (c->x86 > 0x11)
>> set_bit(X86_FEATURE_ARAT, c->x86_capability);
>> 
>> + /* 
>> +  * Prior to Family 0x14, perf counters are not reset during warm reboot.
>> +  * We have to reset them manually.
>> +  */
>> + if (c->x86 < 0x14) {
>> +  wrmsrl(MSR_K7_PERFCTR0, 0);
>> +  wrmsrl(MSR_K7_PERFCTR1, 0);
>> +  wrmsrl(MSR_K7_PERFCTR2, 0);
>> +  wrmsrl(MSR_K7_PERFCTR3, 0);
>> + }
> 
> This collides with the NMI watchdog setup: smp_callin() calls
> setup_local_APIC() _before_ calling smp_store_cpu_info(), and
> hence you write zero again to an MSR possibly already in use.
> Since setup_k7_watchdog() itself does the clearing of the MSRs
> in question already, I would think that the most simple
> adjustment to your patch would be to make the condition
> 
> if (nmi_watchdog != NMI_LOCAL_APIC && c->x86 < 0x14) {
> 
> If you agree (and Keir doesn't object), I would commit it that way.

Sounds good.

Acked-by: Keir Fraser <keir@xen.org>

> Jan
> 
>> +
>> if (cpuid_edx(0x80000007) & (1 << 10)) {
>> rdmsr(MSR_K7_HWCR, l, h);
>> l |= (1 << 27); /* Enable read-only APERF/MPERF bit */
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 12:10:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 12:10:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNjUP-00057R-Lu; Mon, 15 Oct 2012 12:09:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TNjUO-00057L-Uz
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 12:09:45 +0000
Received: from [85.158.143.99:12195] by server-3.bemta-4.messagelabs.com id
	BD/1A-10075-80DFB705; Mon, 15 Oct 2012 12:09:44 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1350302972!34198588!2
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9096 invoked from network); 15 Oct 2012 12:09:43 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 12:09:43 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so3083274eek.32
	for <xen-devel@lists.xen.org>; Mon, 15 Oct 2012 05:09:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=OaEoCcoHhVAf6+AYBzheNzp+22d4AgKqE5FU6p/y5EE=;
	b=qFyE+rx/H0BGfrq05aguzjVt7vf5Baxs57OqvyDd4bBSt/GhARPx53OzO3fnH+b71V
	9b0gKhYzQbCoZOOD3OdCQWp/G+qbwq5dY+UKLpur2awEb+ux8sCCxu352ujfStxEULE4
	zDV6Zi49tNzv2NSgJ4XpBKcKr8dk3qAhcSrKMFl4HT/tLmrLsraheGGTivIEDZBL5RLN
	EKa2JYx9z8P+ovnCceYu6wBbG0Z4GkuoPdKUqAIAkhXAzY1gdehhRamTpAnR1N6JgGyu
	fwtQ0vB1fkSByaxn9IrtwIM/grFPuTkKHbxQSUADDV3kg+HAM9mqGz1JUNM8bXwTEdMq
	bsTw==
Received: by 10.14.193.129 with SMTP id k1mr15319285een.13.1350302983702;
	Mon, 15 Oct 2012 05:09:43 -0700 (PDT)
Received: from [192.168.1.69]
	(host86-183-156-141.range86-183.btcentralplus.com. [86.183.156.141])
	by mx.google.com with ESMTPS id s1sm24673919eem.9.2012.10.15.05.09.40
	(version=SSLv3 cipher=OTHER); Mon, 15 Oct 2012 05:09:42 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Mon, 15 Oct 2012 13:09:38 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	Wei Wang <wei.wang2@amd.com>
Message-ID: <CCA1BB92.41B09%keir.xen@gmail.com>
Thread-Topic: [PATCH] x86/amd: Fix xen_apic_write warnings in Dom0
Thread-Index: Ac2qzfKsR66/SZ1rOEq9NX4RHfQslg==
In-Reply-To: <507C0BA702000078000A15A9@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Keir Fraser <keir@xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86/amd: Fix xen_apic_write warnings in Dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 15/10/2012 12:12, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 09.10.12 at 10:06, Wei Wang <wei.wang2@amd.com> wrote:
>> --- a/xen/arch/x86/cpu/amd.c
>> +++ b/xen/arch/x86/cpu/amd.c
>> @@ -485,6 +485,17 @@ static void __devinit init_amd(struct cpuinfo_x86 *c)
>> if (c->x86 > 0x11)
>> set_bit(X86_FEATURE_ARAT, c->x86_capability);
>> 
>> + /* 
>> +  * Prior to Family 0x14, perf counters are not reset during warm reboot.
>> +  * We have to reset them manually.
>> +  */
>> + if (c->x86 < 0x14) {
>> +  wrmsrl(MSR_K7_PERFCTR0, 0);
>> +  wrmsrl(MSR_K7_PERFCTR1, 0);
>> +  wrmsrl(MSR_K7_PERFCTR2, 0);
>> +  wrmsrl(MSR_K7_PERFCTR3, 0);
>> + }
> 
> This collides with the NMI watchdog setup: smp_callin() calls
> setup_local_APIC() _before_ calling smp_store_cpu_info(), and
> hence you write zero again to an MSR possibly already in use.
> Since setup_k7_watchdog() itself does the clearing of the MSRs
> in question already, I would think that the most simple
> adjustment to your patch would be to make the condition
> 
> if (nmi_watchdog != NMI_LOCAL_APIC && c->x86 < 0x14) {
> 
> If you agree (and Keir doesn't object), I would commit it that way.

Sounds good.

Acked-by: Keir Fraser <keir@xen.org>

> Jan
> 
>> +
>> if (cpuid_edx(0x80000007) & (1 << 10)) {
>> rdmsr(MSR_K7_HWCR, l, h);
>> l |= (1 << 27); /* Enable read-only APERF/MPERF bit */
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 12:17:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 12:17:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNjc4-0005Om-KC; Mon, 15 Oct 2012 12:17:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1TNjc2-0005Oh-UD
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 12:17:39 +0000
Received: from [85.158.138.51:40535] by server-15.bemta-3.messagelabs.com id
	43/2E-10261-2EEFB705; Mon, 15 Oct 2012 12:17:38 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1350303451!34325656!1
X-Originating-IP: [213.199.154.204]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6433 invoked from network); 15 Oct 2012 12:17:36 -0000
Received: from am1ehsobe001.messaging.microsoft.com (HELO
	am1outboundpool.messaging.microsoft.com) (213.199.154.204)
	by server-16.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	15 Oct 2012 12:17:36 -0000
Received: from mail24-am1-R.bigfish.com (10.3.201.228) by
	AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id
	14.1.225.23; Mon, 15 Oct 2012 12:17:31 +0000
Received: from mail24-am1 (localhost [127.0.0.1])	by mail24-am1-R.bigfish.com
	(Postfix) with ESMTP id 586FCC00A2;
	Mon, 15 Oct 2012 12:17:31 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: -5
X-BigFish: VPS-5(zzbb2dI98dI9371I1432I4015Izz1202h1d1ah1d2ahzz8275bh8275dhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh137ah13b6h1441h1155h)
Received: from mail24-am1 (localhost.localdomain [127.0.0.1]) by mail24-am1
	(MessageSwitch) id 1350303449891120_12595;
	Mon, 15 Oct 2012 12:17:29 +0000 (UTC)
Received: from AM1EHSMHS014.bigfish.com (unknown [10.3.201.226])	by
	mail24-am1.bigfish.com (Postfix) with ESMTP id D6E4F48006E;
	Mon, 15 Oct 2012 12:17:29 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS014.bigfish.com (10.3.207.152) with Microsoft SMTP Server id
	14.1.225.23; Mon, 15 Oct 2012 12:17:28 +0000
X-WSS-ID: 0MBXOSY-02-6I2-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 21B2FC80AE;	Mon, 15 Oct 2012 07:17:21 -0500 (CDT)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Mon, 15 Oct 2012 07:33:07 -0500
Received: from STOREXDAG03.amd.com (10.1.13.12) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Mon, 15 Oct 2012 07:17:24 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexdag03.amd.com
	(10.1.13.12) with Microsoft SMTP Server id 14.1.323.3; Mon, 15 Oct 2012
	08:17:23 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 31FA449C35C; Mon, 15 Oct 2012
	13:17:23 +0100 (BST)
Message-ID: <507BFEE4.3090601@amd.com>
Date: Mon, 15 Oct 2012 14:17:40 +0200
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120421 Thunderbird/12.0
MIME-Version: 1.0
To: Keir Fraser <keir.xen@gmail.com>
References: <CCA1BB92.41B09%keir.xen@gmail.com>
In-Reply-To: <CCA1BB92.41B09%keir.xen@gmail.com>
X-OriginatorOrg: amd.com
Cc: Keir Fraser <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86/amd: Fix xen_apic_write warnings in Dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/15/2012 02:09 PM, Keir Fraser wrote:
> On 15/10/2012 12:12, "Jan Beulich"<JBeulich@suse.com>  wrote:
>
>>>>> On 09.10.12 at 10:06, Wei Wang<wei.wang2@amd.com>  wrote:
>>> --- a/xen/arch/x86/cpu/amd.c
>>> +++ b/xen/arch/x86/cpu/amd.c
>>> @@ -485,6 +485,17 @@ static void __devinit init_amd(struct cpuinfo_x86 *c)
>>> if (c->x86>  0x11)
>>> set_bit(X86_FEATURE_ARAT, c->x86_capability);
>>>
>>> + /*
>>> +  * Prior to Family 0x14, perf counters are not reset during warm reboot.
>>> +  * We have to reset them manually.
>>> +  */
>>> + if (c->x86<  0x14) {
>>> +  wrmsrl(MSR_K7_PERFCTR0, 0);
>>> +  wrmsrl(MSR_K7_PERFCTR1, 0);
>>> +  wrmsrl(MSR_K7_PERFCTR2, 0);
>>> +  wrmsrl(MSR_K7_PERFCTR3, 0);
>>> + }
>>
>> This collides with the NMI watchdog setup: smp_callin() calls
>> setup_local_APIC() _before_ calling smp_store_cpu_info(), and
>> hence you write zero again to an MSR possibly already in use.
>> Since setup_k7_watchdog() itself does the clearing of the MSRs
>> in question already, I would think that the most simple
>> adjustment to your patch would be to make the condition
>>
>> if (nmi_watchdog != NMI_LOCAL_APIC&&  c->x86<  0x14) {
>>
>> If you agree (and Keir doesn't object), I would commit it that way.
>
> Sounds good.
>
> Acked-by: Keir Fraser<keir@xen.org>

Sounds good to me too. Acked
Thanks,
Wei

>> Jan
>>
>>> +
>>> if (cpuid_edx(0x80000007)&  (1<<  10)) {
>>> rdmsr(MSR_K7_HWCR, l, h);
>>> l |= (1<<  27); /* Enable read-only APERF/MPERF bit */
>>
>>
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 12:17:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 12:17:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNjc4-0005Om-KC; Mon, 15 Oct 2012 12:17:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1TNjc2-0005Oh-UD
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 12:17:39 +0000
Received: from [85.158.138.51:40535] by server-15.bemta-3.messagelabs.com id
	43/2E-10261-2EEFB705; Mon, 15 Oct 2012 12:17:38 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1350303451!34325656!1
X-Originating-IP: [213.199.154.204]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6433 invoked from network); 15 Oct 2012 12:17:36 -0000
Received: from am1ehsobe001.messaging.microsoft.com (HELO
	am1outboundpool.messaging.microsoft.com) (213.199.154.204)
	by server-16.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	15 Oct 2012 12:17:36 -0000
Received: from mail24-am1-R.bigfish.com (10.3.201.228) by
	AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id
	14.1.225.23; Mon, 15 Oct 2012 12:17:31 +0000
Received: from mail24-am1 (localhost [127.0.0.1])	by mail24-am1-R.bigfish.com
	(Postfix) with ESMTP id 586FCC00A2;
	Mon, 15 Oct 2012 12:17:31 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: -5
X-BigFish: VPS-5(zzbb2dI98dI9371I1432I4015Izz1202h1d1ah1d2ahzz8275bh8275dhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh137ah13b6h1441h1155h)
Received: from mail24-am1 (localhost.localdomain [127.0.0.1]) by mail24-am1
	(MessageSwitch) id 1350303449891120_12595;
	Mon, 15 Oct 2012 12:17:29 +0000 (UTC)
Received: from AM1EHSMHS014.bigfish.com (unknown [10.3.201.226])	by
	mail24-am1.bigfish.com (Postfix) with ESMTP id D6E4F48006E;
	Mon, 15 Oct 2012 12:17:29 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS014.bigfish.com (10.3.207.152) with Microsoft SMTP Server id
	14.1.225.23; Mon, 15 Oct 2012 12:17:28 +0000
X-WSS-ID: 0MBXOSY-02-6I2-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 21B2FC80AE;	Mon, 15 Oct 2012 07:17:21 -0500 (CDT)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Mon, 15 Oct 2012 07:33:07 -0500
Received: from STOREXDAG03.amd.com (10.1.13.12) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Mon, 15 Oct 2012 07:17:24 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexdag03.amd.com
	(10.1.13.12) with Microsoft SMTP Server id 14.1.323.3; Mon, 15 Oct 2012
	08:17:23 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 31FA449C35C; Mon, 15 Oct 2012
	13:17:23 +0100 (BST)
Message-ID: <507BFEE4.3090601@amd.com>
Date: Mon, 15 Oct 2012 14:17:40 +0200
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120421 Thunderbird/12.0
MIME-Version: 1.0
To: Keir Fraser <keir.xen@gmail.com>
References: <CCA1BB92.41B09%keir.xen@gmail.com>
In-Reply-To: <CCA1BB92.41B09%keir.xen@gmail.com>
X-OriginatorOrg: amd.com
Cc: Keir Fraser <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86/amd: Fix xen_apic_write warnings in Dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/15/2012 02:09 PM, Keir Fraser wrote:
> On 15/10/2012 12:12, "Jan Beulich"<JBeulich@suse.com>  wrote:
>
>>>>> On 09.10.12 at 10:06, Wei Wang<wei.wang2@amd.com>  wrote:
>>> --- a/xen/arch/x86/cpu/amd.c
>>> +++ b/xen/arch/x86/cpu/amd.c
>>> @@ -485,6 +485,17 @@ static void __devinit init_amd(struct cpuinfo_x86 *c)
>>> if (c->x86>  0x11)
>>> set_bit(X86_FEATURE_ARAT, c->x86_capability);
>>>
>>> + /*
>>> +  * Prior to Family 0x14, perf counters are not reset during warm reboot.
>>> +  * We have to reset them manually.
>>> +  */
>>> + if (c->x86<  0x14) {
>>> +  wrmsrl(MSR_K7_PERFCTR0, 0);
>>> +  wrmsrl(MSR_K7_PERFCTR1, 0);
>>> +  wrmsrl(MSR_K7_PERFCTR2, 0);
>>> +  wrmsrl(MSR_K7_PERFCTR3, 0);
>>> + }
>>
>> This collides with the NMI watchdog setup: smp_callin() calls
>> setup_local_APIC() _before_ calling smp_store_cpu_info(), and
>> hence you write zero again to an MSR possibly already in use.
>> Since setup_k7_watchdog() itself does the clearing of the MSRs
>> in question already, I would think that the most simple
>> adjustment to your patch would be to make the condition
>>
>> if (nmi_watchdog != NMI_LOCAL_APIC&&  c->x86<  0x14) {
>>
>> If you agree (and Keir doesn't object), I would commit it that way.
>
> Sounds good.
>
> Acked-by: Keir Fraser<keir@xen.org>

Sounds good to me too. Acked
Thanks,
Wei

>> Jan
>>
>>> +
>>> if (cpuid_edx(0x80000007)&  (1<<  10)) {
>>> rdmsr(MSR_K7_HWCR, l, h);
>>> l |= (1<<  27); /* Enable read-only APERF/MPERF bit */
>>
>>
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 12:22:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 12:22:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNjg4-0005kZ-Hv; Mon, 15 Oct 2012 12:21:48 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1TNjg2-0005ju-Cg
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 12:21:46 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1350303698!14672368!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODI0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31262 invoked from network); 15 Oct 2012 12:21:39 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 12:21:39 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="211277471"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 12:21:38 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Mon, 15 Oct 2012
	08:21:38 -0400
Message-ID: <507BFFD0.2010707@citrix.com>
Date: Mon, 15 Oct 2012 13:21:36 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1350046634-2462-1-git-send-email-david.vrabel@citrix.com>	
	<1350046634-2462-3-git-send-email-david.vrabel@citrix.com>
	<1350293121.18058.10.camel@zakaz.uk.xensource.com>
In-Reply-To: <1350293121.18058.10.camel@zakaz.uk.xensource.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/3] xen: add correct 500 ms offset when
 setting Xen wallclock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 15/10/12 10:25, Ian Campbell wrote:
> On Fri, 2012-10-12 at 13:57 +0100, David Vrabel wrote:
>> From: David Vrabel <david.vrabel@citrix.com>
>>
>> update_persistent_wallclock() (and hence xet_set_wallclock()) is
>> called 500 ms after the second.
> 
> The comment in sync_cmos_clock says it is called 500ms before the next
> second.

This is the same thing, right?

> I only mention it to double check that the right semantics for
> set_wallclock are being implemented, i.e. that we are compensating in
> the right direction.

I'll add some debug code to make sure.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 12:22:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 12:22:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNjg4-0005kZ-Hv; Mon, 15 Oct 2012 12:21:48 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1TNjg2-0005ju-Cg
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 12:21:46 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1350303698!14672368!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODI0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31262 invoked from network); 15 Oct 2012 12:21:39 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 12:21:39 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="211277471"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 12:21:38 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Mon, 15 Oct 2012
	08:21:38 -0400
Message-ID: <507BFFD0.2010707@citrix.com>
Date: Mon, 15 Oct 2012 13:21:36 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1350046634-2462-1-git-send-email-david.vrabel@citrix.com>	
	<1350046634-2462-3-git-send-email-david.vrabel@citrix.com>
	<1350293121.18058.10.camel@zakaz.uk.xensource.com>
In-Reply-To: <1350293121.18058.10.camel@zakaz.uk.xensource.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/3] xen: add correct 500 ms offset when
 setting Xen wallclock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 15/10/12 10:25, Ian Campbell wrote:
> On Fri, 2012-10-12 at 13:57 +0100, David Vrabel wrote:
>> From: David Vrabel <david.vrabel@citrix.com>
>>
>> update_persistent_wallclock() (and hence xet_set_wallclock()) is
>> called 500 ms after the second.
> 
> The comment in sync_cmos_clock says it is called 500ms before the next
> second.

This is the same thing, right?

> I only mention it to double check that the right semantics for
> set_wallclock are being implemented, i.e. that we are compensating in
> the right direction.

I'll add some debug code to make sure.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 12:23:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 12:23:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNjhn-0005xH-1r; Mon, 15 Oct 2012 12:23:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1TNjhl-0005x5-Vk
	for xen-devel@lists.xensource.com; Mon, 15 Oct 2012 12:23:34 +0000
Received: from [85.158.139.83:61085] by server-9.bemta-5.messagelabs.com id
	1C/B3-23053-5400C705; Mon, 15 Oct 2012 12:23:33 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1350303811!34339872!1
X-Originating-IP: [216.32.180.30]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17032 invoked from network); 15 Oct 2012 12:23:32 -0000
Received: from va3ehsobe010.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.30)
	by server-13.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	15 Oct 2012 12:23:32 -0000
Received: from mail231-va3-R.bigfish.com (10.7.14.235) by
	VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id
	14.1.225.23; Mon, 15 Oct 2012 12:23:30 +0000
Received: from mail231-va3 (localhost [127.0.0.1])	by
	mail231-va3-R.bigfish.com (Postfix) with ESMTP id A43A5C400ED;
	Mon, 15 Oct 2012 12:23:30 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: -7
X-BigFish: VPS-7(zzbb2dI98dI9371I1dbaI1432I1418I4015Izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh137ah13b6h1441h1155h)
Received: from mail231-va3 (localhost.localdomain [127.0.0.1]) by mail231-va3
	(MessageSwitch) id 1350303807672832_23102;
	Mon, 15 Oct 2012 12:23:27 +0000 (UTC)
Received: from VA3EHSMHS036.bigfish.com (unknown [10.7.14.250])	by
	mail231-va3.bigfish.com (Postfix) with ESMTP id 979D6C006A;
	Mon, 15 Oct 2012 12:23:27 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS036.bigfish.com (10.7.99.46) with Microsoft SMTP Server id
	14.1.225.23; Mon, 15 Oct 2012 12:23:25 +0000
X-WSS-ID: 0MBXP2Z-01-75J-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2F3B110280E8;	Mon, 15 Oct 2012 07:23:23 -0500 (CDT)
Received: from SAUSEXDAG05.amd.com (163.181.55.6) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Mon, 15 Oct 2012 07:39:06 -0500
Received: from STOREXDAG01.amd.com (10.1.13.10) by sausexdag05.amd.com
	(163.181.55.6) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Mon, 15 Oct 2012 07:23:23 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexdag01.amd.com
	(10.1.13.10) with Microsoft SMTP Server id 14.1.323.3; Mon, 15 Oct 2012
	08:23:22 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id B2C1F49C35C; Mon, 15 Oct 2012
	13:23:21 +0100 (BST)
Message-ID: <507C004B.20003@amd.com>
Date: Mon, 15 Oct 2012 14:23:39 +0200
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120421 Thunderbird/12.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <5063155A.4070307@amd.com>
	<50642A2A020000780009E32D@nat28.tlf.novell.com>
	<507BDED1.6020005@amd.com>
	<507BFD7802000078000A1526@nat28.tlf.novell.com>
In-Reply-To: <507BFD7802000078000A1526@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	IanCampbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2 of 6 V6] amd iommu: call
	guest_iommu_set_base from hvmloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/15/2012 12:11 PM, Jan Beulich wrote:
>>>> On 15.10.12 at 12:00, Wei Wang<wei.wang2@amd.com>  wrote:
>> On 09/27/2012 10:27 AM, Jan Beulich wrote:
>>>>>> On 26.09.12 at 16:46, Wei Wang<wei.wang2@amd.com>   wrote:
>>>> @@ -3834,6 +3835,9 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void)
>> arg)
>>>>               case HVM_PARAM_BUFIOREQ_EVTCHN:
>>>>                   rc = -EINVAL;
>>>>                   break;
>>>> +            case HVM_PARAM_IOMMU_BASE:
>>>> +                rc = guest_iommu_set_base(d, a.value);
>>>
>>> This suggests that you're allowing for only a single IOMMU per
>>> guest - is that not going to become an issue sooner or later?
>>
>> I think that one iommu per guest is probably enough. Because guest IVRS
>> table is totally virtual, it does not reflect any pci relationship of
>> real systems. Even if qemu supports multi pci buses, we can still
>> virtually group them together into one virtual IVRS table. It might be
>> an issue if qemu uses multi pci segments, but so far even hardware iommu
>> only uses segment 0. Additionally, the guest iommu is only used by ats
>> capable GPUs. Normal passthrough device should not make use of it. So,,
>> What do you think?
>
> Especially the multi-segment aspect makes me think that the
> interface should allow for multiple IOMMUs, even if the
> implementation supports only one for now.

Ok, then I will rework the interface to take iommu segment as an 
additional parameter.
Thanks,
Wei

> Jan
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 12:23:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 12:23:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNjhn-0005xH-1r; Mon, 15 Oct 2012 12:23:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1TNjhl-0005x5-Vk
	for xen-devel@lists.xensource.com; Mon, 15 Oct 2012 12:23:34 +0000
Received: from [85.158.139.83:61085] by server-9.bemta-5.messagelabs.com id
	1C/B3-23053-5400C705; Mon, 15 Oct 2012 12:23:33 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1350303811!34339872!1
X-Originating-IP: [216.32.180.30]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17032 invoked from network); 15 Oct 2012 12:23:32 -0000
Received: from va3ehsobe010.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.30)
	by server-13.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	15 Oct 2012 12:23:32 -0000
Received: from mail231-va3-R.bigfish.com (10.7.14.235) by
	VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id
	14.1.225.23; Mon, 15 Oct 2012 12:23:30 +0000
Received: from mail231-va3 (localhost [127.0.0.1])	by
	mail231-va3-R.bigfish.com (Postfix) with ESMTP id A43A5C400ED;
	Mon, 15 Oct 2012 12:23:30 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: -7
X-BigFish: VPS-7(zzbb2dI98dI9371I1dbaI1432I1418I4015Izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh137ah13b6h1441h1155h)
Received: from mail231-va3 (localhost.localdomain [127.0.0.1]) by mail231-va3
	(MessageSwitch) id 1350303807672832_23102;
	Mon, 15 Oct 2012 12:23:27 +0000 (UTC)
Received: from VA3EHSMHS036.bigfish.com (unknown [10.7.14.250])	by
	mail231-va3.bigfish.com (Postfix) with ESMTP id 979D6C006A;
	Mon, 15 Oct 2012 12:23:27 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS036.bigfish.com (10.7.99.46) with Microsoft SMTP Server id
	14.1.225.23; Mon, 15 Oct 2012 12:23:25 +0000
X-WSS-ID: 0MBXP2Z-01-75J-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2F3B110280E8;	Mon, 15 Oct 2012 07:23:23 -0500 (CDT)
Received: from SAUSEXDAG05.amd.com (163.181.55.6) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Mon, 15 Oct 2012 07:39:06 -0500
Received: from STOREXDAG01.amd.com (10.1.13.10) by sausexdag05.amd.com
	(163.181.55.6) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Mon, 15 Oct 2012 07:23:23 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexdag01.amd.com
	(10.1.13.10) with Microsoft SMTP Server id 14.1.323.3; Mon, 15 Oct 2012
	08:23:22 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id B2C1F49C35C; Mon, 15 Oct 2012
	13:23:21 +0100 (BST)
Message-ID: <507C004B.20003@amd.com>
Date: Mon, 15 Oct 2012 14:23:39 +0200
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120421 Thunderbird/12.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <5063155A.4070307@amd.com>
	<50642A2A020000780009E32D@nat28.tlf.novell.com>
	<507BDED1.6020005@amd.com>
	<507BFD7802000078000A1526@nat28.tlf.novell.com>
In-Reply-To: <507BFD7802000078000A1526@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	IanCampbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2 of 6 V6] amd iommu: call
	guest_iommu_set_base from hvmloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/15/2012 12:11 PM, Jan Beulich wrote:
>>>> On 15.10.12 at 12:00, Wei Wang<wei.wang2@amd.com>  wrote:
>> On 09/27/2012 10:27 AM, Jan Beulich wrote:
>>>>>> On 26.09.12 at 16:46, Wei Wang<wei.wang2@amd.com>   wrote:
>>>> @@ -3834,6 +3835,9 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void)
>> arg)
>>>>               case HVM_PARAM_BUFIOREQ_EVTCHN:
>>>>                   rc = -EINVAL;
>>>>                   break;
>>>> +            case HVM_PARAM_IOMMU_BASE:
>>>> +                rc = guest_iommu_set_base(d, a.value);
>>>
>>> This suggests that you're allowing for only a single IOMMU per
>>> guest - is that not going to become an issue sooner or later?
>>
>> I think that one iommu per guest is probably enough. Because guest IVRS
>> table is totally virtual, it does not reflect any pci relationship of
>> real systems. Even if qemu supports multi pci buses, we can still
>> virtually group them together into one virtual IVRS table. It might be
>> an issue if qemu uses multi pci segments, but so far even hardware iommu
>> only uses segment 0. Additionally, the guest iommu is only used by ats
>> capable GPUs. Normal passthrough device should not make use of it. So,,
>> What do you think?
>
> Especially the multi-segment aspect makes me think that the
> interface should allow for multiple IOMMUs, even if the
> implementation supports only one for now.

Ok, then I will rework the interface to take iommu segment as an 
additional parameter.
Thanks,
Wei

> Jan
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 12:23:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 12:23:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNjhs-0005y5-Dx; Mon, 15 Oct 2012 12:23:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1TNjhr-0005xk-15
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 12:23:39 +0000
Received: from [85.158.137.99:61524] by server-7.bemta-3.messagelabs.com id
	C6/33-06991-A400C705; Mon, 15 Oct 2012 12:23:38 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1350303816!21598869!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYzNjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3813 invoked from network); 15 Oct 2012 12:23:37 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 12:23:37 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="41210189"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 12:23:35 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Mon, 15 Oct 2012
	08:23:35 -0400
Message-ID: <507C0046.5050700@citrix.com>
Date: Mon, 15 Oct 2012 13:23:34 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1350046634-2462-1-git-send-email-david.vrabel@citrix.com>	
	<50784462.3060203@citrix.com>
	<1350293217.18058.11.camel@zakaz.uk.xensource.com>
In-Reply-To: <1350293217.18058.11.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 0/3] xen: fix various wallclock problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 15/10/12 10:26, Ian Campbell wrote:
> On Fri, 2012-10-12 at 17:25 +0100, David Vrabel wrote:
>> On 12/10/12 13:57, David Vrabel wrote:
>>> This series (with some toolstack updates) corrects a number of cases
>>> where a guest can see an incorrect wallclock time.
>>>
>>> 1. Systems with NTP won't periodically synchronize the hardware RTC so
>>> the wallclock may be incorrect after a reboot.
>>>
>>> 2. The wallclock is always ~500 ms behind the correct time.
>>>
>>> 3. If the system time was stepped and NTP isn't synchronized yet, the
>>> wallclock will still have the incorrect time.  The fix for this
>>> requires the toolstack to synchronize the wallclock -- patch #3
>>> provides the mechanism for this.
>>
>> These tables should help.
>>
>> Before:
>>
>>               |                Updates
>> Process	      | System Time?  Xen Wallclock?  Hardware Clock?
>> -------------------------------------------------------------
>> date -s       | X
>> hwclock -w    |                               X
>> ntpd          | X             X[*]
>> ntpdate       | X
> 
> What does the equivalent table for native look like?
> 
> Is the "updated hardware clock" column in that caseis union of xen
> wallclock and hardware clock columns here?

Yes.

              |         Updates
Process	      | System Time?  Hardware Clock?
---------------------------------------------
date -s       | X
hwclock -w    |               X
ntpd          | X             X[*]
ntpdate       | X

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 12:23:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 12:23:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNjhs-0005y5-Dx; Mon, 15 Oct 2012 12:23:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1TNjhr-0005xk-15
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 12:23:39 +0000
Received: from [85.158.137.99:61524] by server-7.bemta-3.messagelabs.com id
	C6/33-06991-A400C705; Mon, 15 Oct 2012 12:23:38 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1350303816!21598869!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYzNjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3813 invoked from network); 15 Oct 2012 12:23:37 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 12:23:37 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="41210189"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 12:23:35 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Mon, 15 Oct 2012
	08:23:35 -0400
Message-ID: <507C0046.5050700@citrix.com>
Date: Mon, 15 Oct 2012 13:23:34 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1350046634-2462-1-git-send-email-david.vrabel@citrix.com>	
	<50784462.3060203@citrix.com>
	<1350293217.18058.11.camel@zakaz.uk.xensource.com>
In-Reply-To: <1350293217.18058.11.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 0/3] xen: fix various wallclock problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 15/10/12 10:26, Ian Campbell wrote:
> On Fri, 2012-10-12 at 17:25 +0100, David Vrabel wrote:
>> On 12/10/12 13:57, David Vrabel wrote:
>>> This series (with some toolstack updates) corrects a number of cases
>>> where a guest can see an incorrect wallclock time.
>>>
>>> 1. Systems with NTP won't periodically synchronize the hardware RTC so
>>> the wallclock may be incorrect after a reboot.
>>>
>>> 2. The wallclock is always ~500 ms behind the correct time.
>>>
>>> 3. If the system time was stepped and NTP isn't synchronized yet, the
>>> wallclock will still have the incorrect time.  The fix for this
>>> requires the toolstack to synchronize the wallclock -- patch #3
>>> provides the mechanism for this.
>>
>> These tables should help.
>>
>> Before:
>>
>>               |                Updates
>> Process	      | System Time?  Xen Wallclock?  Hardware Clock?
>> -------------------------------------------------------------
>> date -s       | X
>> hwclock -w    |                               X
>> ntpd          | X             X[*]
>> ntpdate       | X
> 
> What does the equivalent table for native look like?
> 
> Is the "updated hardware clock" column in that caseis union of xen
> wallclock and hardware clock columns here?

Yes.

              |         Updates
Process	      | System Time?  Hardware Clock?
---------------------------------------------
date -s       | X
hwclock -w    |               X
ntpd          | X             X[*]
ntpdate       | X

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 12:25:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 12:25:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNjjU-0006Dh-UR; Mon, 15 Oct 2012 12:25:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1TNjjT-0006DD-Iw
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 12:25:19 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1350303912!13287640!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYzNjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1230 invoked from network); 15 Oct 2012 12:25:13 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 12:25:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="41210301"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 12:25:11 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Mon, 15 Oct 2012
	08:25:11 -0400
Message-ID: <507C00A6.3020001@citrix.com>
Date: Mon, 15 Oct 2012 13:25:10 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1350046970-2591-1-git-send-email-david.vrabel@citrix.com>	
	<1350046970-2591-3-git-send-email-david.vrabel@citrix.com>
	<1350293719.18058.13.camel@zakaz.uk.xensource.com>
In-Reply-To: <1350293719.18058.13.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/2] tools/misc: add xen-wallclock command
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 15/10/12 10:35, Ian Campbell wrote:
> On Fri, 2012-10-12 at 14:02 +0100, David Vrabel wrote:
>> +int main(int argc, char *argv[])
>> +{
>> +    const static char sopts[] = "w";
>> +    const static struct option lopts[] = {
>> +        { "help", 0, NULL, 0 },
>> +        { "systowc", 0, NULL, 'w' },
>> +        { 0, 0, NULL, 0 },
>> +    };
>> +    int opt, opt_idx;
>> +
>> +    int systowc = 0;
>> +    xc_interface *xch;
>> +
>> +    exe_name = argv[0];
>> +
>> +    while ( (opt = getopt_long(argc, argv, sopts, lopts, &opt_idx)) != -1 )
>> +    {
>> +        switch ( opt )
>> +        {
>> +        case 'w':
>> +            systowc = 1;
>> +            break;
>> +        case 0:
>> +            switch (opt_idx)
>> +            {
>> +            case 0:
>> +                help();
>> +            }
>> +            break;
>> +        default:
>> +            usage(stderr);
>> +            exit(1);
>> +        }
>> +    }
>> +
>> +    /* Valid combination of options? i.e., --systowc */
>> +    if (!systowc)
>> +    {
>> +        usage(stderr);
>> +        exit(1);
>> +    }
>> +
>> +    xch = xc_interface_open(NULL, NULL, 0);
>> +    if (xch == NULL)
>> +    {
> 
> I forget: Does xc_interface_open log on error?

Yes.

>> +        exit(1);
>> +    }
>> +    xc_wallclock_sync(xch);
> 
> Worth logging if this fails?

Yes.

> I suppose we want to hold off on this and the first patch until the
> Linux side is agreed and committed?

Yes.

>> +    xc_interface_close(xch);
>> +
>> +    return 0;
>> +}

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 12:25:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 12:25:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNjjU-0006Dh-UR; Mon, 15 Oct 2012 12:25:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1TNjjT-0006DD-Iw
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 12:25:19 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1350303912!13287640!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYzNjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1230 invoked from network); 15 Oct 2012 12:25:13 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 12:25:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="41210301"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 12:25:11 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Mon, 15 Oct 2012
	08:25:11 -0400
Message-ID: <507C00A6.3020001@citrix.com>
Date: Mon, 15 Oct 2012 13:25:10 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1350046970-2591-1-git-send-email-david.vrabel@citrix.com>	
	<1350046970-2591-3-git-send-email-david.vrabel@citrix.com>
	<1350293719.18058.13.camel@zakaz.uk.xensource.com>
In-Reply-To: <1350293719.18058.13.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/2] tools/misc: add xen-wallclock command
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 15/10/12 10:35, Ian Campbell wrote:
> On Fri, 2012-10-12 at 14:02 +0100, David Vrabel wrote:
>> +int main(int argc, char *argv[])
>> +{
>> +    const static char sopts[] = "w";
>> +    const static struct option lopts[] = {
>> +        { "help", 0, NULL, 0 },
>> +        { "systowc", 0, NULL, 'w' },
>> +        { 0, 0, NULL, 0 },
>> +    };
>> +    int opt, opt_idx;
>> +
>> +    int systowc = 0;
>> +    xc_interface *xch;
>> +
>> +    exe_name = argv[0];
>> +
>> +    while ( (opt = getopt_long(argc, argv, sopts, lopts, &opt_idx)) != -1 )
>> +    {
>> +        switch ( opt )
>> +        {
>> +        case 'w':
>> +            systowc = 1;
>> +            break;
>> +        case 0:
>> +            switch (opt_idx)
>> +            {
>> +            case 0:
>> +                help();
>> +            }
>> +            break;
>> +        default:
>> +            usage(stderr);
>> +            exit(1);
>> +        }
>> +    }
>> +
>> +    /* Valid combination of options? i.e., --systowc */
>> +    if (!systowc)
>> +    {
>> +        usage(stderr);
>> +        exit(1);
>> +    }
>> +
>> +    xch = xc_interface_open(NULL, NULL, 0);
>> +    if (xch == NULL)
>> +    {
> 
> I forget: Does xc_interface_open log on error?

Yes.

>> +        exit(1);
>> +    }
>> +    xc_wallclock_sync(xch);
> 
> Worth logging if this fails?

Yes.

> I suppose we want to hold off on this and the first patch until the
> Linux side is agreed and committed?

Yes.

>> +    xc_interface_close(xch);
>> +
>> +    return 0;
>> +}

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 12:28:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 12:28:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNjlw-0006U8-Kg; Mon, 15 Oct 2012 12:27:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TNjlv-0006Tt-6f
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 12:27:51 +0000
Received: from [85.158.139.211:7088] by server-9.bemta-5.messagelabs.com id
	E5/4C-23053-6410C705; Mon, 15 Oct 2012 12:27:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1350304069!22316327!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12018 invoked from network); 15 Oct 2012 12:27:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 12:27:50 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="15170071"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 12:27:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 13:27:49 +0100
Message-ID: <1350304068.18058.41.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 15 Oct 2012 13:27:48 +0100
In-Reply-To: <507BFFD0.2010707@citrix.com>
References: <1350046634-2462-1-git-send-email-david.vrabel@citrix.com>
	<1350046634-2462-3-git-send-email-david.vrabel@citrix.com>
	<1350293121.18058.10.camel@zakaz.uk.xensource.com>
	<507BFFD0.2010707@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/3] xen: add correct 500 ms offset when
 setting Xen wallclock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-10-15 at 13:21 +0100, David Vrabel wrote:
> On 15/10/12 10:25, Ian Campbell wrote:
> > On Fri, 2012-10-12 at 13:57 +0100, David Vrabel wrote:
> >> From: David Vrabel <david.vrabel@citrix.com>
> >>
> >> update_persistent_wallclock() (and hence xet_set_wallclock()) is
> >> called 500 ms after the second.
> > 
> > The comment in sync_cmos_clock says it is called 500ms before the next
> > second.
> 
> This is the same thing, right?

It matters in the native case, where, If I'm reading it right, things
are setup such thatthe time change happens on the next second tick over.
I just wanted to check it did/didn't matter here as well.

> 
> > I only mention it to double check that the right semantics for
> > set_wallclock are being implemented, i.e. that we are compensating in
> > the right direction.
> 
> I'll add some debug code to make sure.
> 
> David



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 12:28:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 12:28:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNjlw-0006U8-Kg; Mon, 15 Oct 2012 12:27:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TNjlv-0006Tt-6f
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 12:27:51 +0000
Received: from [85.158.139.211:7088] by server-9.bemta-5.messagelabs.com id
	E5/4C-23053-6410C705; Mon, 15 Oct 2012 12:27:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1350304069!22316327!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12018 invoked from network); 15 Oct 2012 12:27:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 12:27:50 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="15170071"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 12:27:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 13:27:49 +0100
Message-ID: <1350304068.18058.41.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 15 Oct 2012 13:27:48 +0100
In-Reply-To: <507BFFD0.2010707@citrix.com>
References: <1350046634-2462-1-git-send-email-david.vrabel@citrix.com>
	<1350046634-2462-3-git-send-email-david.vrabel@citrix.com>
	<1350293121.18058.10.camel@zakaz.uk.xensource.com>
	<507BFFD0.2010707@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/3] xen: add correct 500 ms offset when
 setting Xen wallclock
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-10-15 at 13:21 +0100, David Vrabel wrote:
> On 15/10/12 10:25, Ian Campbell wrote:
> > On Fri, 2012-10-12 at 13:57 +0100, David Vrabel wrote:
> >> From: David Vrabel <david.vrabel@citrix.com>
> >>
> >> update_persistent_wallclock() (and hence xet_set_wallclock()) is
> >> called 500 ms after the second.
> > 
> > The comment in sync_cmos_clock says it is called 500ms before the next
> > second.
> 
> This is the same thing, right?

It matters in the native case, where, If I'm reading it right, things
are setup such thatthe time change happens on the next second tick over.
I just wanted to check it did/didn't matter here as well.

> 
> > I only mention it to double check that the right semantics for
> > set_wallclock are being implemented, i.e. that we are compensating in
> > the right direction.
> 
> I'll add some debug code to make sure.
> 
> David



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 12:47:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 12:47:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNk4O-0006zi-C6; Mon, 15 Oct 2012 12:46:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TNk4N-0006zd-48
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 12:46:55 +0000
Received: from [85.158.139.83:12646] by server-15.bemta-5.messagelabs.com id
	E1/A7-28599-EB50C705; Mon, 15 Oct 2012 12:46:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1350305213!30376172!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27361 invoked from network); 15 Oct 2012 12:46:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-182.messagelabs.com with SMTP;
	15 Oct 2012 12:46:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 15 Oct 2012 13:46:55 +0100
Message-Id: <507C21D902000078000A1630@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 15 Oct 2012 13:46:49 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <20120914112427.GA1454@elgon.mountain>
	<1350296868.18058.24.camel@zakaz.uk.xensource.com>
	<507C062002000078000A1574@nat28.tlf.novell.com>
	<1350298696.18058.33.camel@zakaz.uk.xensource.com>
In-Reply-To: <1350298696.18058.33.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeremy Fitzhardinge <jeremy@xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>, Tang Liang <liang.tang@oracle.com>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	Dan Carpenter <dan.carpenter@oracle.com>
Subject: Re: [Xen-devel] memory corruption in HYPERVISOR_physdev_op()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.10.12 at 12:58, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Mon, 2012-10-15 at 11:48 +0100, Jan Beulich wrote:
>> >>> On 15.10.12 at 12:27, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > On Fri, 2012-09-14 at 14:24 +0300, Dan Carpenter wrote:
>> >> My static analyzer complains about potential memory corruption in
>> >> HYPERVISOR_physdev_op()
>> >> 
>> >> arch/x86/include/asm/xen/hypercall.h
>> >>    389  static inline int
>> >>    390  HYPERVISOR_physdev_op(int cmd, void *arg)
>> >>    391  {
>> >>    392          int rc = _hypercall2(int, physdev_op, cmd, arg);
>> >>    393          if (unlikely(rc == -ENOSYS)) {
>> >>    394                  struct physdev_op op;
>> >>    395                  op.cmd = cmd;
>> >>    396                  memcpy(&op.u, arg, sizeof(op.u));
>> >>    397                  rc = _hypercall1(int, physdev_op_compat, &op);
>> >>    398                  memcpy(arg, &op.u, sizeof(op.u));
>> >>                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> >> Some of the arg buffers are not as large as sizeof(op.u) which is either
>> >> 12 or 16 depending on the size of longs in struct physdev_apic.
>> > 
>> > Nasty!
>> 
>> Wasn't it that pv-ops expects Xen 4.0.1 or newer anyway? If so,
>> what does this code exist for in the first place (it's framed by
>> #if CONFIG_XEN_COMPAT <= 0x030002 in the Xenified kernel)?
> 
> I think the 4.0.1 or newer requirement is for dom0 only. I guess physdev
> op is only used in dom0 though? Or does passthrough need it?

No, it's only platform_op that is Dom0-only.

>> > I can see the memory corruption but how does it relate to ret ==
>> > -ENOSYS?
>> 
>> The (supposedly) corrupting code site inside an
>> 
>> 	if (unlikely(rc == -ENOSYS)) {
> 
> Ah, for some reason I assumed this was in the eventual caller, even
> though it was staring me right in the face in the full quote.

I think Dan's reference was to an eventual caller - it would see
the -ENOSYS, as the compat call wouldn't return anything else
than the modern one, and the modern one (to enter the code
in question) must have returned -ENOSYS.

>> Fixing this other than by removing the broken code would be
>> pretty hard I'm afraid (and I tend to leave the code untouched
>> altogether in the Xenified tree).
> 
> Given that it is compat code the list of subops which needs to supported
> in this case is small and finite so a simple lookup table or even switch
> stmt for the size might be an option.

Ugly, particularly for an inline function. But possible of course.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 12:47:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 12:47:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNk4O-0006zi-C6; Mon, 15 Oct 2012 12:46:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TNk4N-0006zd-48
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 12:46:55 +0000
Received: from [85.158.139.83:12646] by server-15.bemta-5.messagelabs.com id
	E1/A7-28599-EB50C705; Mon, 15 Oct 2012 12:46:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1350305213!30376172!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27361 invoked from network); 15 Oct 2012 12:46:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-182.messagelabs.com with SMTP;
	15 Oct 2012 12:46:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 15 Oct 2012 13:46:55 +0100
Message-Id: <507C21D902000078000A1630@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 15 Oct 2012 13:46:49 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <20120914112427.GA1454@elgon.mountain>
	<1350296868.18058.24.camel@zakaz.uk.xensource.com>
	<507C062002000078000A1574@nat28.tlf.novell.com>
	<1350298696.18058.33.camel@zakaz.uk.xensource.com>
In-Reply-To: <1350298696.18058.33.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeremy Fitzhardinge <jeremy@xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>, Tang Liang <liang.tang@oracle.com>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	Dan Carpenter <dan.carpenter@oracle.com>
Subject: Re: [Xen-devel] memory corruption in HYPERVISOR_physdev_op()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.10.12 at 12:58, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Mon, 2012-10-15 at 11:48 +0100, Jan Beulich wrote:
>> >>> On 15.10.12 at 12:27, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > On Fri, 2012-09-14 at 14:24 +0300, Dan Carpenter wrote:
>> >> My static analyzer complains about potential memory corruption in
>> >> HYPERVISOR_physdev_op()
>> >> 
>> >> arch/x86/include/asm/xen/hypercall.h
>> >>    389  static inline int
>> >>    390  HYPERVISOR_physdev_op(int cmd, void *arg)
>> >>    391  {
>> >>    392          int rc = _hypercall2(int, physdev_op, cmd, arg);
>> >>    393          if (unlikely(rc == -ENOSYS)) {
>> >>    394                  struct physdev_op op;
>> >>    395                  op.cmd = cmd;
>> >>    396                  memcpy(&op.u, arg, sizeof(op.u));
>> >>    397                  rc = _hypercall1(int, physdev_op_compat, &op);
>> >>    398                  memcpy(arg, &op.u, sizeof(op.u));
>> >>                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> >> Some of the arg buffers are not as large as sizeof(op.u) which is either
>> >> 12 or 16 depending on the size of longs in struct physdev_apic.
>> > 
>> > Nasty!
>> 
>> Wasn't it that pv-ops expects Xen 4.0.1 or newer anyway? If so,
>> what does this code exist for in the first place (it's framed by
>> #if CONFIG_XEN_COMPAT <= 0x030002 in the Xenified kernel)?
> 
> I think the 4.0.1 or newer requirement is for dom0 only. I guess physdev
> op is only used in dom0 though? Or does passthrough need it?

No, it's only platform_op that is Dom0-only.

>> > I can see the memory corruption but how does it relate to ret ==
>> > -ENOSYS?
>> 
>> The (supposedly) corrupting code site inside an
>> 
>> 	if (unlikely(rc == -ENOSYS)) {
> 
> Ah, for some reason I assumed this was in the eventual caller, even
> though it was staring me right in the face in the full quote.

I think Dan's reference was to an eventual caller - it would see
the -ENOSYS, as the compat call wouldn't return anything else
than the modern one, and the modern one (to enter the code
in question) must have returned -ENOSYS.

>> Fixing this other than by removing the broken code would be
>> pretty hard I'm afraid (and I tend to leave the code untouched
>> altogether in the Xenified tree).
> 
> Given that it is compat code the list of subops which needs to supported
> in this case is small and finite so a simple lookup table or even switch
> stmt for the size might be an option.

Ugly, particularly for an inline function. But possible of course.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 12:49:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 12:49:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNk6h-00075i-UN; Mon, 15 Oct 2012 12:49:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>)
	id 1TNk6g-00075X-4K; Mon, 15 Oct 2012 12:49:18 +0000
Received: from [85.158.139.83:61776] by server-12.bemta-5.messagelabs.com id
	7C/09-26919-D460C705; Mon, 15 Oct 2012 12:49:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1350305356!35188860!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4957 invoked from network); 15 Oct 2012 12:49:17 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-182.messagelabs.com with SMTP;
	15 Oct 2012 12:49:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 15 Oct 2012 13:49:19 +0100
Message-Id: <507C226A02000078000A1657@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 15 Oct 2012 13:49:14 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Mauro" <mrsanna1@gmail.com>
References: <AANLkTikptc2POrKQgJuoVZRdwJTo64DJ_hm12KuPky4D@mail.gmail.com>
	<b1ca6ddc-ca69-447e-93e9-8d36d1ff4a43@default>
	<AANLkTinK94GDOF_GeaVs50wK0u8EdZ2rtzPuh65ca8qR@mail.gmail.com>
	<CAE17a0UPyzsNn=ps9MxarkGg=ns8dCpVz0qBDvesT2AOskwfVg@mail.gmail.com>
	<65395f62-74e5-4910-b701-8df629c2ce3b@default>
	<CABx4GKrQxOOQo_uUXSFvy0nzdMp1A_qc=_e4K+88GkB7xv=9nw@mail.gmail.com>
	<CAE17a0VkMuUEG9VaM7AFrwcsEjVBq9RfvTWz1_KmscAyCxeAbA@mail.gmail.com>
	<CABx4GKqrTEV7CEnAVUfYr-+yky8N5P1U29xDbrESH-mHB0iZhQ@mail.gmail.com>
	<CAE17a0UYwqLxoZaVDgQCvUR2KQK4vvP3bkvsdrwgnsUp33xuNQ@mail.gmail.com>
	<CAE17a0UQocJjZc38c2805uYvdwR7e447UGH9ywcxMw1Ge3imfg@mail.gmail.com>
	<20120930151314.GU8912@reaktio.net>
	<CAE17a0WWvpwW-V5hQOgL1CiuVZFKyzhZVZfTVq74ZsJUo1SE8w@mail.gmail.com>
	<CAE17a0WvLyduj4V68qPJRLcjc5V7xZ=iTNprKWJyGAX_6RXC+Q@mail.gmail.com>
	<CABx4GKr-AxZmCyGmd4qenMtgdo2Yg+UnT4ymbONjBtuS+w=g7Q@mail.gmail.com>
	<507C024602000078000A155C@nat28.tlf.novell.com>
	<CAE17a0VUOoqtGbghmmXq_4SWQUH3dwBHPoezH1j98efFEAUVvQ@mail.gmail.com>
In-Reply-To: <CAE17a0VUOoqtGbghmmXq_4SWQUH3dwBHPoezH1j98efFEAUVvQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>, Dan Magenheimer <dan.magenheimer@oracle.com>,
	Olivier Hanesse <olivier.hanesse@gmail.com>,
	Keir Fraser <keir.xen@gmail.com>,
	Xen Users <xen-users@lists.xensource.com>,
	Mark Adams <mark@campbell-lange.net>
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.10.12 at 13:24, Mauro <mrsanna1@gmail.com> wrote:
> I have the problem on this hardware type:
> 
> Hp Proliant DL580 G5 with four Intel(R) Xeon(R) CPU E7330  @ 2.40GHz.
> It seem that
> GRUB_CMDLINE_XEN="clocksource=pit cpuidle=0"
> put in in /etc/default/grup (I use linux debian)
> solves the problem for me.

Did you check whether either or both options on their own also
make the problem go away?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 12:49:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 12:49:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNk6h-00075i-UN; Mon, 15 Oct 2012 12:49:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>)
	id 1TNk6g-00075X-4K; Mon, 15 Oct 2012 12:49:18 +0000
Received: from [85.158.139.83:61776] by server-12.bemta-5.messagelabs.com id
	7C/09-26919-D460C705; Mon, 15 Oct 2012 12:49:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1350305356!35188860!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4957 invoked from network); 15 Oct 2012 12:49:17 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-182.messagelabs.com with SMTP;
	15 Oct 2012 12:49:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 15 Oct 2012 13:49:19 +0100
Message-Id: <507C226A02000078000A1657@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 15 Oct 2012 13:49:14 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Mauro" <mrsanna1@gmail.com>
References: <AANLkTikptc2POrKQgJuoVZRdwJTo64DJ_hm12KuPky4D@mail.gmail.com>
	<b1ca6ddc-ca69-447e-93e9-8d36d1ff4a43@default>
	<AANLkTinK94GDOF_GeaVs50wK0u8EdZ2rtzPuh65ca8qR@mail.gmail.com>
	<CAE17a0UPyzsNn=ps9MxarkGg=ns8dCpVz0qBDvesT2AOskwfVg@mail.gmail.com>
	<65395f62-74e5-4910-b701-8df629c2ce3b@default>
	<CABx4GKrQxOOQo_uUXSFvy0nzdMp1A_qc=_e4K+88GkB7xv=9nw@mail.gmail.com>
	<CAE17a0VkMuUEG9VaM7AFrwcsEjVBq9RfvTWz1_KmscAyCxeAbA@mail.gmail.com>
	<CABx4GKqrTEV7CEnAVUfYr-+yky8N5P1U29xDbrESH-mHB0iZhQ@mail.gmail.com>
	<CAE17a0UYwqLxoZaVDgQCvUR2KQK4vvP3bkvsdrwgnsUp33xuNQ@mail.gmail.com>
	<CAE17a0UQocJjZc38c2805uYvdwR7e447UGH9ywcxMw1Ge3imfg@mail.gmail.com>
	<20120930151314.GU8912@reaktio.net>
	<CAE17a0WWvpwW-V5hQOgL1CiuVZFKyzhZVZfTVq74ZsJUo1SE8w@mail.gmail.com>
	<CAE17a0WvLyduj4V68qPJRLcjc5V7xZ=iTNprKWJyGAX_6RXC+Q@mail.gmail.com>
	<CABx4GKr-AxZmCyGmd4qenMtgdo2Yg+UnT4ymbONjBtuS+w=g7Q@mail.gmail.com>
	<507C024602000078000A155C@nat28.tlf.novell.com>
	<CAE17a0VUOoqtGbghmmXq_4SWQUH3dwBHPoezH1j98efFEAUVvQ@mail.gmail.com>
In-Reply-To: <CAE17a0VUOoqtGbghmmXq_4SWQUH3dwBHPoezH1j98efFEAUVvQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>, Dan Magenheimer <dan.magenheimer@oracle.com>,
	Olivier Hanesse <olivier.hanesse@gmail.com>,
	Keir Fraser <keir.xen@gmail.com>,
	Xen Users <xen-users@lists.xensource.com>,
	Mark Adams <mark@campbell-lange.net>
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.10.12 at 13:24, Mauro <mrsanna1@gmail.com> wrote:
> I have the problem on this hardware type:
> 
> Hp Proliant DL580 G5 with four Intel(R) Xeon(R) CPU E7330  @ 2.40GHz.
> It seem that
> GRUB_CMDLINE_XEN="clocksource=pit cpuidle=0"
> put in in /etc/default/grup (I use linux debian)
> solves the problem for me.

Did you check whether either or both options on their own also
make the problem go away?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 12:52:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 12:52:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNkA0-0007W1-QB; Mon, 15 Oct 2012 12:52:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TNk9z-0007Vl-Oz
	for xen-devel@lists.xensource.com; Mon, 15 Oct 2012 12:52:43 +0000
Received: from [85.158.139.83:37749] by server-13.bemta-5.messagelabs.com id
	0B/EE-30674-A170C705; Mon, 15 Oct 2012 12:52:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1350305562!34345810!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 689 invoked from network); 15 Oct 2012 12:52:42 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-182.messagelabs.com with SMTP;
	15 Oct 2012 12:52:42 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 15 Oct 2012 13:52:46 +0100
Message-Id: <507C233702000078000A1670@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 15 Oct 2012 13:52:39 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <5063155A.4070307@amd.com>
	<50642A2A020000780009E32D@nat28.tlf.novell.com>
	<507BDED1.6020005@amd.com>
	<507BFD7802000078000A1526@nat28.tlf.novell.com>
	<507C004B.20003@amd.com>
In-Reply-To: <507C004B.20003@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	IanCampbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2 of 6 V6] amd iommu: call
 guest_iommu_set_base from hvmloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.10.12 at 14:23, Wei Wang <wei.wang2@amd.com> wrote:
> On 10/15/2012 12:11 PM, Jan Beulich wrote:
>>>>> On 15.10.12 at 12:00, Wei Wang<wei.wang2@amd.com>  wrote:
>>> On 09/27/2012 10:27 AM, Jan Beulich wrote:
>>>>>>> On 26.09.12 at 16:46, Wei Wang<wei.wang2@amd.com>   wrote:
>>>>> @@ -3834,6 +3835,9 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void)
>>> arg)
>>>>>               case HVM_PARAM_BUFIOREQ_EVTCHN:
>>>>>                   rc = -EINVAL;
>>>>>                   break;
>>>>> +            case HVM_PARAM_IOMMU_BASE:
>>>>> +                rc = guest_iommu_set_base(d, a.value);
>>>>
>>>> This suggests that you're allowing for only a single IOMMU per
>>>> guest - is that not going to become an issue sooner or later?
>>>
>>> I think that one iommu per guest is probably enough. Because guest IVRS
>>> table is totally virtual, it does not reflect any pci relationship of
>>> real systems. Even if qemu supports multi pci buses, we can still
>>> virtually group them together into one virtual IVRS table. It might be
>>> an issue if qemu uses multi pci segments, but so far even hardware iommu
>>> only uses segment 0. Additionally, the guest iommu is only used by ats
>>> capable GPUs. Normal passthrough device should not make use of it. So,,
>>> What do you think?
>>
>> Especially the multi-segment aspect makes me think that the
>> interface should allow for multiple IOMMUs, even if the
>> implementation supports only one for now.
> 
> Ok, then I will rework the interface to take iommu segment as an 
> additional parameter.

That'll likely make the interface even more ugly than the more
flexible variant allowing for multiple IOMMUs independent of
the segment they're on/for. But let's see what you come up
with...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 12:52:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 12:52:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNkA0-0007W1-QB; Mon, 15 Oct 2012 12:52:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TNk9z-0007Vl-Oz
	for xen-devel@lists.xensource.com; Mon, 15 Oct 2012 12:52:43 +0000
Received: from [85.158.139.83:37749] by server-13.bemta-5.messagelabs.com id
	0B/EE-30674-A170C705; Mon, 15 Oct 2012 12:52:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1350305562!34345810!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 689 invoked from network); 15 Oct 2012 12:52:42 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-182.messagelabs.com with SMTP;
	15 Oct 2012 12:52:42 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 15 Oct 2012 13:52:46 +0100
Message-Id: <507C233702000078000A1670@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 15 Oct 2012 13:52:39 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <5063155A.4070307@amd.com>
	<50642A2A020000780009E32D@nat28.tlf.novell.com>
	<507BDED1.6020005@amd.com>
	<507BFD7802000078000A1526@nat28.tlf.novell.com>
	<507C004B.20003@amd.com>
In-Reply-To: <507C004B.20003@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	IanCampbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2 of 6 V6] amd iommu: call
 guest_iommu_set_base from hvmloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.10.12 at 14:23, Wei Wang <wei.wang2@amd.com> wrote:
> On 10/15/2012 12:11 PM, Jan Beulich wrote:
>>>>> On 15.10.12 at 12:00, Wei Wang<wei.wang2@amd.com>  wrote:
>>> On 09/27/2012 10:27 AM, Jan Beulich wrote:
>>>>>>> On 26.09.12 at 16:46, Wei Wang<wei.wang2@amd.com>   wrote:
>>>>> @@ -3834,6 +3835,9 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void)
>>> arg)
>>>>>               case HVM_PARAM_BUFIOREQ_EVTCHN:
>>>>>                   rc = -EINVAL;
>>>>>                   break;
>>>>> +            case HVM_PARAM_IOMMU_BASE:
>>>>> +                rc = guest_iommu_set_base(d, a.value);
>>>>
>>>> This suggests that you're allowing for only a single IOMMU per
>>>> guest - is that not going to become an issue sooner or later?
>>>
>>> I think that one iommu per guest is probably enough. Because guest IVRS
>>> table is totally virtual, it does not reflect any pci relationship of
>>> real systems. Even if qemu supports multi pci buses, we can still
>>> virtually group them together into one virtual IVRS table. It might be
>>> an issue if qemu uses multi pci segments, but so far even hardware iommu
>>> only uses segment 0. Additionally, the guest iommu is only used by ats
>>> capable GPUs. Normal passthrough device should not make use of it. So,,
>>> What do you think?
>>
>> Especially the multi-segment aspect makes me think that the
>> interface should allow for multiple IOMMUs, even if the
>> implementation supports only one for now.
> 
> Ok, then I will rework the interface to take iommu segment as an 
> additional parameter.

That'll likely make the interface even more ugly than the more
flexible variant allowing for multiple IOMMUs independent of
the segment they're on/for. But let's see what you come up
with...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 13:12:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 13:12:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNkSn-0008LF-7H; Mon, 15 Oct 2012 13:12:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1TNkSl-0008L8-3p
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 13:12:07 +0000
Received: from [85.158.137.99:20735] by server-14.bemta-3.messagelabs.com id
	22/8E-17276-6AB0C705; Mon, 15 Oct 2012 13:12:06 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-9.tower-217.messagelabs.com!1350306725!18483999!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1Mjk0NDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19776 invoked from network); 15 Oct 2012 13:12:06 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-9.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Oct 2012 13:12:06 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id A76242C52;
	Mon, 15 Oct 2012 16:12:04 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 7E4A420058; Mon, 15 Oct 2012 16:12:04 +0300 (EEST)
Date: Mon, 15 Oct 2012 16:12:04 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20121015131204.GG8912@reaktio.net>
References: <20120905030239.GJ8912@reaktio.net>
	<1346846602-1109-1-git-send-email-roger.pau@citrix.com>
	<1347613534.24226.167.camel@zakaz.uk.xensource.com>
	<20121014111035.GE8912@reaktio.net>
	<1350287553.14440.0.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1350287553.14440.0.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libfsimage: add ext4 support for CentOS 5.x
 / Xen 4.2.1 backport
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 15, 2012 at 08:52:33AM +0100, Ian Campbell wrote:
> On Sun, 2012-10-14 at 12:10 +0100, Pasi K=E4rkk=E4inen wrote:
> > On Fri, Sep 14, 2012 at 10:05:34AM +0100, Ian Campbell wrote:
> > > On Wed, 2012-09-05 at 13:03 +0100, Roger Pau Monne wrote:
> > > > CentOS 5.x forked e2fs ext4 support into a different package called
> > > > e4fs, and so headers and library names changed from ext2fs to ext4f=
s.
> > > > Check if ext4fs/ext2fs.h and -lext4fs work, and use that instead of
> > > > ext2fs to build libfsimage. This patch assumes that if the ext4fs
> > > > library is present it should always be used instead of ext2fs.
> > > > =

> > > > This patch includes a rework of the ext2fs check, a new ext4fs check
> > > > and a minor modification in libfsimage to use the correct library.
> > > > =

> > > > Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
> > > > ---
> > > > Please re-run autogen.sh after applying
> > > =

> > > Done & acked + applied. Thanks.
> > >
> > =

> > Hello,
> > =

> > Now that this patch has been in xen-unstable for a while
> > I'd like to request Xen 4.2.1 backport..
> =

> Ian Jackson deals with backports, not me.
> =


Added IanJ to CC list..

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 13:12:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 13:12:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNkSn-0008LF-7H; Mon, 15 Oct 2012 13:12:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1TNkSl-0008L8-3p
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 13:12:07 +0000
Received: from [85.158.137.99:20735] by server-14.bemta-3.messagelabs.com id
	22/8E-17276-6AB0C705; Mon, 15 Oct 2012 13:12:06 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-9.tower-217.messagelabs.com!1350306725!18483999!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1Mjk0NDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19776 invoked from network); 15 Oct 2012 13:12:06 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-9.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Oct 2012 13:12:06 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id A76242C52;
	Mon, 15 Oct 2012 16:12:04 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 7E4A420058; Mon, 15 Oct 2012 16:12:04 +0300 (EEST)
Date: Mon, 15 Oct 2012 16:12:04 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20121015131204.GG8912@reaktio.net>
References: <20120905030239.GJ8912@reaktio.net>
	<1346846602-1109-1-git-send-email-roger.pau@citrix.com>
	<1347613534.24226.167.camel@zakaz.uk.xensource.com>
	<20121014111035.GE8912@reaktio.net>
	<1350287553.14440.0.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1350287553.14440.0.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libfsimage: add ext4 support for CentOS 5.x
 / Xen 4.2.1 backport
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 15, 2012 at 08:52:33AM +0100, Ian Campbell wrote:
> On Sun, 2012-10-14 at 12:10 +0100, Pasi K=E4rkk=E4inen wrote:
> > On Fri, Sep 14, 2012 at 10:05:34AM +0100, Ian Campbell wrote:
> > > On Wed, 2012-09-05 at 13:03 +0100, Roger Pau Monne wrote:
> > > > CentOS 5.x forked e2fs ext4 support into a different package called
> > > > e4fs, and so headers and library names changed from ext2fs to ext4f=
s.
> > > > Check if ext4fs/ext2fs.h and -lext4fs work, and use that instead of
> > > > ext2fs to build libfsimage. This patch assumes that if the ext4fs
> > > > library is present it should always be used instead of ext2fs.
> > > > =

> > > > This patch includes a rework of the ext2fs check, a new ext4fs check
> > > > and a minor modification in libfsimage to use the correct library.
> > > > =

> > > > Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
> > > > ---
> > > > Please re-run autogen.sh after applying
> > > =

> > > Done & acked + applied. Thanks.
> > >
> > =

> > Hello,
> > =

> > Now that this patch has been in xen-unstable for a while
> > I'd like to request Xen 4.2.1 backport..
> =

> Ian Jackson deals with backports, not me.
> =


Added IanJ to CC list..

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 13:28:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 13:28:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TNkiN-0000Ej-Sc; Mon, 15 Oct 2012 13:28:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tupeng212@gmail.com>) id 1TNkiN-0000Ee-23
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 13:28:15 +0000
Received: from [85.158.137.99:7295] by server-16.bemta-3.messagelabs.com id
	16/C0-16565-E6F0C705; Mon, 15 Oct 2012 13:28:14 +0000
X-Env-Sender: tupeng212@gmail.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1350307691!16291344!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.5 required=7.0 tests=HTML_MESSAGE,
	MIME_BOUND_NEXTPART,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18742 invoked from network); 15 Oct 2012 13:28:13 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 13:28:13 -0000
Received: by mail-pb0-f45.google.com with SMTP id rp2so4935999pbb.32
	for <xen-devel@lists.xen.org>; Mon, 15 Oct 2012 06:28:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=date:from:to:cc:reply-to:subject:references:x-priority:x-guid
	:x-has-attach:x-mailer:mime-version:message-id:content-type;
	bh=TmYOjFeL7fgRTYKfHCIfviLxL1Y2G45jo9URkxQUDTk=;
	b=vYaw+v0x+oxxS/pAAjAOwuh2c9exKIYjW4KZV8zQFDq6zS++9OA0vaaQEvRUWsjqrY
	m45ohPEkFmgT1g1hyXHpQE+Gh/uHGHAclf4iDAqjeyHB7BdIZrKLfAaJ/OYrygtDHdcT
	RMd2P+JiYjb+whbK6askb06cAijvt/mbBcSGVaMvVcmIEqXnwkhDChGWD7oc1ficBBtQ
	jrKH2T9Dq7ECXSz4o0+MGK+jOcuM8Zm9S4GrdjPFEflmhygd95aj/HqcgF/4V7ChgW4S
	Y1SJwuqPW6I0VTrj5ql/otNXQDzXAbyWn/GnMaChx0q/HeJ25xAVl0IfNVbCY6yDW1fc
	mBcA==
Received: by 10.66.75.162 with SMTP id d2mr32864594paw.27.1350307691302;
	Mon, 15 Oct 2012 06:28:11 -0700 (PDT)
Received: from root ([115.199.244.139])
	by mx.google.com with ESMTPS id o5sm9091926paz.32.2012.10.15.06.27.46
	(version=SSLv3 cipher=OTHER); Mon, 15 Oct 2012 06:28:10 -0700 (PDT)
Date: Mon, 15 Oct 2012 21:27:51 +0800
From: tupeng212 <tupeng212@gmail.com>
To: "Keir Fraser" <keir@xen.org>
References: <CC9EEBF9.4EE4D%keir@xen.org>
X-Priority: 3
X-GUID: A5584935-7A94-4A1B-811C-2EAAC9AE77CA
X-Has-Attach: no
X-Mailer: Foxmail 7.0.1.91[en]
Mime-Version: 1.0
Message-ID: <201210152127478127583@gmail.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] alloc_heap_pages is low efficient with more CPUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: tupeng212 <tupeng212@gmail.com>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3212490044236287802=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.

--===============3212490044236287802==
Content-Type: multipart/alternative;
	boundary="----=_001_NextPart870663023588_=----"

This is a multi-part message in MIME format.

------=_001_NextPart870663023588_=----
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64

UGxlYXNlIHRyeSB0aGUgYXR0YWNoZWQgcGF0Y2guDQo6IEdyZWF0ISAgeW91IGhhdmUgZG9uZSBh
IGdvb2Qgam9iLCBuZWVkbGVzcyB0aW1lIGRlY3JlYXNlcyBiYWRseSB0byAxcy4NCg0KSWYgYW55
Ym9keSBoYXMgbm8gcHJvcG9zYWwsIEkgc3VnZ2VzdCB5b3UgdG8gY29tbWl0IHRoaXMgcGF0Y2gu

------=_001_NextPart870663023588_=----
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

=EF=BB=BF<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Re: [Xen-devel] alloc_heap_pages is low efficient with =
more CPUs






Please try the attached patch.:=20
Great!  you have done a good job, needless time decreases badly to=20
1s.

 


<=
SPAN=20
style=3D"FONT-SIZE: 12pt">If anybody has no proposal, I suggest you to commit this=20
patch.





------=_001_NextPart870663023588_=------



--===============3212490044236287802==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3212490044236287802==--



From xen-devel-bounces@lists.xen.org Mon Oct 15 13:28:35 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 13:28:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNkiN-0000Ej-Sc; Mon, 15 Oct 2012 13:28:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNkiN-0000Ee-23
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 13:28:15 +0000
Received: from [85.158.137.99:7295] by server-16.bemta-3.messagelabs.com id
	16/C0-16565-E6F0C705; Mon, 15 Oct 2012 13:28:14 +0000
X-Env-Sender: tupeng212@gmail.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1350307691!16291344!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.5 required=7.0 tests=HTML_MESSAGE,
	MIME_BOUND_NEXTPART,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18742 invoked from network); 15 Oct 2012 13:28:13 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 13:28:13 -0000
Received: by mail-pb0-f45.google.com with SMTP id rp2so4935999pbb.32
	for ; Mon, 15 Oct 2012 06:28:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=date:from:to:cc:reply-to:subject:references:x-priority:x-guid
	:x-has-attach:x-mailer:mime-version:message-id:content-type;
	bh=TmYOjFeL7fgRTYKfHCIfviLxL1Y2G45jo9URkxQUDTk=;
	b=vYaw+v0x+oxxS/pAAjAOwuh2c9exKIYjW4KZV8zQFDq6zS++9OA0vaaQEvRUWsjqrY
	m45ohPEkFmgT1g1hyXHpQE+Gh/uHGHAclf4iDAqjeyHB7BdIZrKLfAaJ/OYrygtDHdcT
	RMd2P+JiYjb+whbK6askb06cAijvt/mbBcSGVaMvVcmIEqXnwkhDChGWD7oc1ficBBtQ
	jrKH2T9Dq7ECXSz4o0+MGK+jOcuM8Zm9S4GrdjPFEflmhygd95aj/HqcgF/4V7ChgW4S
	Y1SJwuqPW6I0VTrj5ql/otNXQDzXAbyWn/GnMaChx0q/HeJ25xAVl0IfNVbCY6yDW1fc
	mBcA==
Received: by 10.66.75.162 with SMTP id d2mr32864594paw.27.1350307691302;
	Mon, 15 Oct 2012 06:28:11 -0700 (PDT)
Received: from root ([115.199.244.139])
	by mx.google.com with ESMTPS id o5sm9091926paz.32.2012.10.15.06.27.46
	(version=SSLv3 cipher=OTHER); Mon, 15 Oct 2012 06:28:10 -0700 (PDT)
Date: Mon, 15 Oct 2012 21:27:51 +0800
From: tupeng212 
To: "Keir Fraser" 
References: 
X-Priority: 3
X-GUID: A5584935-7A94-4A1B-811C-2EAAC9AE77CA
X-Has-Attach: no
X-Mailer: Foxmail 7.0.1.91[en]
Mime-Version: 1.0
Message-ID: <201210152127478127583@gmail.com>
Cc: xen-devel 
Subject: Re: [Xen-devel] alloc_heap_pages is low efficient with more CPUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: tupeng212 
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============3212490044236287802=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.

--===============3212490044236287802==
Content-Type: multipart/alternative;
	boundary="----=_001_NextPart870663023588_=----"

This is a multi-part message in MIME format.

------=_001_NextPart870663023588_=----
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64

UGxlYXNlIHRyeSB0aGUgYXR0YWNoZWQgcGF0Y2guDQo6IEdyZWF0ISAgeW91IGhhdmUgZG9uZSBh
IGdvb2Qgam9iLCBuZWVkbGVzcyB0aW1lIGRlY3JlYXNlcyBiYWRseSB0byAxcy4NCg0KSWYgYW55
Ym9keSBoYXMgbm8gcHJvcG9zYWwsIEkgc3VnZ2VzdCB5b3UgdG8gY29tbWl0IHRoaXMgcGF0Y2gu

------=_001_NextPart870663023588_=----
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

=EF=BB=BF
Re: [Xen-devel] alloc_heap_pages is low efficient with =
more CPUs






Please try the attached patch.:=20
Great!  you have done a good job, needless time decreases badly to=20
1s.

 


<=
SPAN=20
style=3D"FONT-SIZE: 12pt">If anybody has no proposal, I suggest you to commit this=20
patch.





------=_001_NextPart870663023588_=------



--===============3212490044236287802==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3212490044236287802==--



From xen-devel-bounces@lists.xen.org Mon Oct 15 13:31:59 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 13:31:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNklh-0000M1-Ge; Mon, 15 Oct 2012 13:31:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNklf-0000Ls-UC
	for xen-devel@lists.xensource.com; Mon, 15 Oct 2012 13:31:40 +0000
Received: from [85.158.137.99:27409] by server-10.bemta-3.messagelabs.com id
	93/A8-27386-A301C705; Mon, 15 Oct 2012 13:31:38 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1350307896!16584988!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgxMDc2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21130 invoked from network); 15 Oct 2012 13:31:38 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-3.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Oct 2012 13:31:38 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9FDVT7i004669
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 15 Oct 2012 13:31:30 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9FDVSEd000723
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 15 Oct 2012 13:31:29 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9FDVSEu012755; Mon, 15 Oct 2012 08:31:28 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 15 Oct 2012 06:31:28 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B3F8D4037A; Mon, 15 Oct 2012 09:19:30 -0400 (EDT)
Date: Mon, 15 Oct 2012 09:19:30 -0400
From: Konrad Rzeszutek Wilk 
To: liuxiaolei1124 , xen-devel@lists.xensource.com
Message-ID: <20121015131930.GC4000@phenom.dumpdata.com>
References: <6f0a356f.934c.13a62ccac9a.Coremail.liuxiaolei1124@163.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <6f0a356f.934c.13a62ccac9a.Coremail.liuxiaolei1124@163.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: Re: [Xen-devel] about the patch: persistent grant maps for xen blk
	drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 15, 2012 at 01:01:51PM +0800, liuxiaolei1124 wrote:
> Dear konrad:
>    i have seen you put the patch "persisten grant maps for xen blk drivers" into you kernel, then dom0 crash .(https://lkml.org/lkml/2012/9/21/388 )my dom0 kernel is 2.6.32.36-0.5, and i put this patch in my kernel, there is a bug too, and the stack is much like yours. And i found  a strange phenomenon. when i add a printk log  such as "printk ("enter func") " in blkif_completion or other function in xen-blkfront.c, guest run well. But after i remove this printk log, guest crash when i start.


Hey. Roger posted a follow up patch that has this fixed. You should
look at that.

Also CC-ing xen-devel here.

>     and the crash stack is :
>     blkif_int -> blkif_completion
>     guest page fault in
>  
> + if (bret->operation == BLKIF_OP_READ)
> + rq_for_each_segment(bvec, s->request, iter) {
> + shared_data = kmap_atomic
> +                                             (pfn_to_page(s->grants_used[i++]->frame));  // page fault
> + bvec_data = bvec_kmap_irq(bvec, &flags);
> + memcpy(bvec_data, shared_data + bvec->bv_offset,
> +        bvec->bv_len);
> + bvec_kunmap_irq(bvec_data, &flags);
> + kunmap_atomic(shared_data);
> + }
> 
> in kernel 2.6.32.36-0.5, my patch is :
>  
> + if (bret->operation == BLKIF_OP_READ)
> + rq_for_each_segment(bvec, s->request, iter) {
> + shared_data = kmap_atomic
> + (pfn_to_page(s->grants_used[i++]->frame), KM_USER0);
> + bvec_data = bvec_kmap_irq(bvec, &flags);
> + memcpy(bvec_data, shared_data + bvec->bv_offset,
> +        bvec->bv_len);
> + bvec_kunmap_irq(bvec_data, &flags);
> + kunmap_atomic(shared_data, KM_USER0);
> + }
> 
>    I don't know what's wrong? mybe function kmap_atomic in my patch is incorrect. I look forward toyour reply, thank you.
>  
>   Best wishes.
>   eric.liu
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 13:31:59 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 13:31:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNklh-0000M1-Ge; Mon, 15 Oct 2012 13:31:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNklf-0000Ls-UC
	for xen-devel@lists.xensource.com; Mon, 15 Oct 2012 13:31:40 +0000
Received: from [85.158.137.99:27409] by server-10.bemta-3.messagelabs.com id
	93/A8-27386-A301C705; Mon, 15 Oct 2012 13:31:38 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1350307896!16584988!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgxMDc2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21130 invoked from network); 15 Oct 2012 13:31:38 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-3.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Oct 2012 13:31:38 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9FDVT7i004669
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 15 Oct 2012 13:31:30 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9FDVSEd000723
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 15 Oct 2012 13:31:29 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9FDVSEu012755; Mon, 15 Oct 2012 08:31:28 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 15 Oct 2012 06:31:28 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B3F8D4037A; Mon, 15 Oct 2012 09:19:30 -0400 (EDT)
Date: Mon, 15 Oct 2012 09:19:30 -0400
From: Konrad Rzeszutek Wilk 
To: liuxiaolei1124 , xen-devel@lists.xensource.com
Message-ID: <20121015131930.GC4000@phenom.dumpdata.com>
References: <6f0a356f.934c.13a62ccac9a.Coremail.liuxiaolei1124@163.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <6f0a356f.934c.13a62ccac9a.Coremail.liuxiaolei1124@163.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: Re: [Xen-devel] about the patch: persistent grant maps for xen blk
	drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 15, 2012 at 01:01:51PM +0800, liuxiaolei1124 wrote:
> Dear konrad:
>    i have seen you put the patch "persisten grant maps for xen blk drivers" into you kernel, then dom0 crash .(https://lkml.org/lkml/2012/9/21/388 )my dom0 kernel is 2.6.32.36-0.5, and i put this patch in my kernel, there is a bug too, and the stack is much like yours. And i found  a strange phenomenon. when i add a printk log  such as "printk ("enter func") " in blkif_completion or other function in xen-blkfront.c, guest run well. But after i remove this printk log, guest crash when i start.


Hey. Roger posted a follow up patch that has this fixed. You should
look at that.

Also CC-ing xen-devel here.

>     and the crash stack is :
>     blkif_int -> blkif_completion
>     guest page fault in
>  
> + if (bret->operation == BLKIF_OP_READ)
> + rq_for_each_segment(bvec, s->request, iter) {
> + shared_data = kmap_atomic
> +                                             (pfn_to_page(s->grants_used[i++]->frame));  // page fault
> + bvec_data = bvec_kmap_irq(bvec, &flags);
> + memcpy(bvec_data, shared_data + bvec->bv_offset,
> +        bvec->bv_len);
> + bvec_kunmap_irq(bvec_data, &flags);
> + kunmap_atomic(shared_data);
> + }
> 
> in kernel 2.6.32.36-0.5, my patch is :
>  
> + if (bret->operation == BLKIF_OP_READ)
> + rq_for_each_segment(bvec, s->request, iter) {
> + shared_data = kmap_atomic
> + (pfn_to_page(s->grants_used[i++]->frame), KM_USER0);
> + bvec_data = bvec_kmap_irq(bvec, &flags);
> + memcpy(bvec_data, shared_data + bvec->bv_offset,
> +        bvec->bv_len);
> + bvec_kunmap_irq(bvec_data, &flags);
> + kunmap_atomic(shared_data, KM_USER0);
> + }
> 
>    I don't know what's wrong? mybe function kmap_atomic in my patch is incorrect. I look forward toyour reply, thank you.
>  
>   Best wishes.
>   eric.liu
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 13:33:33 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 13:33:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNknH-0000WW-Ao; Mon, 15 Oct 2012 13:33:19 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNknG-0000Us-9M
	for xen-devel@lists.xensource.com; Mon, 15 Oct 2012 13:33:18 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1350307977!4917315!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODAzNzcz\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23157 invoked from network); 15 Oct 2012 13:32:58 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Oct 2012 13:32:58 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9FDWrsD023859
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 15 Oct 2012 13:32:53 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9FDWpCs001740
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 15 Oct 2012 13:32:51 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9FDWoLJ027777; Mon, 15 Oct 2012 08:32:50 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 15 Oct 2012 06:32:49 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 62EFC4037A; Mon, 15 Oct 2012 09:20:52 -0400 (EDT)
Date: Mon, 15 Oct 2012 09:20:52 -0400
From: Konrad Rzeszutek Wilk 
To: Paul Bolle 
Message-ID: <20121015132052.GD4000@phenom.dumpdata.com>
References: <1350295389.1516.27.camel@x61.thuisdomein>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1350295389.1516.27.camel@x61.thuisdomein>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org,
	linux-kernel@vger.kernel.org, "H. Peter Anvin" 
Subject: Re: [Xen-devel] [PATCH] xen/xenbus: silence GCC warning
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gTW9uLCBPY3QgMTUsIDIwMTIgYXQgMTI6MDM6MDlQTSArMDIwMCwgUGF1bCBCb2xsZSB3cm90
ZToKPiBDb21waWxpbmcgeGVuYnVzX3hzLm8gdHJpZ2dlcnMgdGhpcyBHQ0Mgd2FybmluZzoKPiAg
ICAgZHJpdmVycy94ZW4veGVuYnVzL3hlbmJ1c194cy5jOjYyODoxMzogd2FybmluZzogZnVuY3Rp
b24gZGVjbGFyYXRpb24gaXNu4oCZdCBhIHByb3RvdHlwZSBbLVdzdHJpY3QtcHJvdG90eXBlc10K
PiAKPiBBZGQgdGhlIG9idmlvdXMgYW5kIHRyaXZpYWwgZml4LgoKSSBhbHJlYWR5IGdvdCB0aGUg
Zml4IGZvciB0aGlzIGluIG15IHRyZWUuIFRoYW5rcyEKCj4gCj4gV2hpbGUgd2UncmUgdG91Y2hp
bmcgdGhpcyBmdW5jdGlvbiBhZGQgc29tZSBlcXVhbGx5IG9idmlvdXMgYW5kIHRyaXZpYWwKPiB3
aGl0ZXNwYWNlIGZpeGVzLgo+IAo+IFNpZ25lZC1vZmYtYnk6IFBhdWwgQm9sbGUgPHBlYm9sbGVA
dGlzY2FsaS5ubD4KPiAtLS0KPiAwKSBUcmlnZ2VyZWQgYnkgY29tcGlsaW5nIHYzLjctcmMxIHVz
aW5nIChiYXNpY2FsbHkpIEZlZG9yYSAxNydzIGN1cnJlbnQKPiBjb25maWcuIENvbXBpbGUgdGVz
dGVkIG9ubHkuCj4gCj4gMSkgT2JsaWdhdG9yeSByZWZlcmVuY2U6IGh0dHBzOi8vbHduLm5ldC9B
cnRpY2xlcy80ODc0OTMvIC4KPiAKPiAgZHJpdmVycy94ZW4veGVuYnVzL3hlbmJ1c194cy5jIHwg
NSArKystLQo+ICAxIGZpbGUgY2hhbmdlZCwgMyBpbnNlcnRpb25zKCspLCAyIGRlbGV0aW9ucygt
KQo+IAo+IGRpZmYgLS1naXQgYS9kcml2ZXJzL3hlbi94ZW5idXMveGVuYnVzX3hzLmMgYi9kcml2
ZXJzL3hlbi94ZW5idXMveGVuYnVzX3hzLmMKPiBpbmRleCA0ODIyMGUxLi43YTJiMGRhIDEwMDY0
NAo+IC0tLSBhL2RyaXZlcnMveGVuL3hlbmJ1cy94ZW5idXNfeHMuYwo+ICsrKyBiL2RyaXZlcnMv
eGVuL3hlbmJ1cy94ZW5idXNfeHMuYwo+IEBAIC02MTksMTMgKzYxOSwxNCBAQCBzdGF0aWMgc3Ry
dWN0IHhlbmJ1c193YXRjaCAqZmluZF93YXRjaChjb25zdCBjaGFyICp0b2tlbikKPiAgCj4gIAly
ZXR1cm4gTlVMTDsKPiAgfQo+ICsKPiAgLyoKPiAgICogQ2VydGFpbiBvbGRlciBYZW5CdXMgdG9v
bHN0YWNrIGNhbm5vdCBoYW5kbGUgcmVhZGluZyB2YWx1ZXMgdGhhdCBhcmUKPiAgICogbm90IHBv
cHVsYXRlZC4gU29tZSBYZW4gMy40IGluc3RhbGxhdGlvbiBhcmUgaW5jYXBhYmxlIG9mIGRvaW5n
IHRoaXMKPiAgICogc28gaWYgd2UgYXJlIHJ1bm5pbmcgb24gYW55dGhpbmcgb2xkZXIgdGhhbiA0
IGRvIG5vdCBhdHRlbXB0IHRvIHJlYWQKPiAgICogY29udHJvbC9wbGF0Zm9ybS1mZWF0dXJlLXhz
X3Jlc2V0X3dhdGNoZXMuCj4gICAqLwo+IC1zdGF0aWMgYm9vbCB4ZW5fc3RyaWN0X3hlbmJ1c19x
dWlyaygpCj4gK3N0YXRpYyBib29sIHhlbl9zdHJpY3RfeGVuYnVzX3F1aXJrKHZvaWQpCj4gIHsK
PiAgCXVpbnQzMl90IGVheCwgZWJ4LCBlY3gsIGVkeCwgYmFzZTsKPiAgCj4gQEAgLTYzNSw4ICs2
MzYsOCBAQCBzdGF0aWMgYm9vbCB4ZW5fc3RyaWN0X3hlbmJ1c19xdWlyaygpCj4gIAlpZiAoKGVh
eCA+PiAxNikgPCA0KQo+ICAJCXJldHVybiB0cnVlOwo+ICAJcmV0dXJuIGZhbHNlOwo+IC0KPiAg
fQo+ICsKPiAgc3RhdGljIHZvaWQgeHNfcmVzZXRfd2F0Y2hlcyh2b2lkKQo+ICB7Cj4gIAlpbnQg
ZXJyLCBzdXBwb3J0ZWQgPSAwOwo+IC0tIAo+IDEuNy4xMS43CgpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1k
ZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Mon Oct 15 13:33:33 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 13:33:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNknH-0000WW-Ao; Mon, 15 Oct 2012 13:33:19 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNknG-0000Us-9M
	for xen-devel@lists.xensource.com; Mon, 15 Oct 2012 13:33:18 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1350307977!4917315!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODAzNzcz\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23157 invoked from network); 15 Oct 2012 13:32:58 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Oct 2012 13:32:58 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9FDWrsD023859
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 15 Oct 2012 13:32:53 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9FDWpCs001740
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 15 Oct 2012 13:32:51 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9FDWoLJ027777; Mon, 15 Oct 2012 08:32:50 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 15 Oct 2012 06:32:49 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 62EFC4037A; Mon, 15 Oct 2012 09:20:52 -0400 (EDT)
Date: Mon, 15 Oct 2012 09:20:52 -0400
From: Konrad Rzeszutek Wilk 
To: Paul Bolle 
Message-ID: <20121015132052.GD4000@phenom.dumpdata.com>
References: <1350295389.1516.27.camel@x61.thuisdomein>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1350295389.1516.27.camel@x61.thuisdomein>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org,
	linux-kernel@vger.kernel.org, "H. Peter Anvin" 
Subject: Re: [Xen-devel] [PATCH] xen/xenbus: silence GCC warning
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gTW9uLCBPY3QgMTUsIDIwMTIgYXQgMTI6MDM6MDlQTSArMDIwMCwgUGF1bCBCb2xsZSB3cm90
ZToKPiBDb21waWxpbmcgeGVuYnVzX3hzLm8gdHJpZ2dlcnMgdGhpcyBHQ0Mgd2FybmluZzoKPiAg
ICAgZHJpdmVycy94ZW4veGVuYnVzL3hlbmJ1c194cy5jOjYyODoxMzogd2FybmluZzogZnVuY3Rp
b24gZGVjbGFyYXRpb24gaXNu4oCZdCBhIHByb3RvdHlwZSBbLVdzdHJpY3QtcHJvdG90eXBlc10K
PiAKPiBBZGQgdGhlIG9idmlvdXMgYW5kIHRyaXZpYWwgZml4LgoKSSBhbHJlYWR5IGdvdCB0aGUg
Zml4IGZvciB0aGlzIGluIG15IHRyZWUuIFRoYW5rcyEKCj4gCj4gV2hpbGUgd2UncmUgdG91Y2hp
bmcgdGhpcyBmdW5jdGlvbiBhZGQgc29tZSBlcXVhbGx5IG9idmlvdXMgYW5kIHRyaXZpYWwKPiB3
aGl0ZXNwYWNlIGZpeGVzLgo+IAo+IFNpZ25lZC1vZmYtYnk6IFBhdWwgQm9sbGUgPHBlYm9sbGVA
dGlzY2FsaS5ubD4KPiAtLS0KPiAwKSBUcmlnZ2VyZWQgYnkgY29tcGlsaW5nIHYzLjctcmMxIHVz
aW5nIChiYXNpY2FsbHkpIEZlZG9yYSAxNydzIGN1cnJlbnQKPiBjb25maWcuIENvbXBpbGUgdGVz
dGVkIG9ubHkuCj4gCj4gMSkgT2JsaWdhdG9yeSByZWZlcmVuY2U6IGh0dHBzOi8vbHduLm5ldC9B
cnRpY2xlcy80ODc0OTMvIC4KPiAKPiAgZHJpdmVycy94ZW4veGVuYnVzL3hlbmJ1c194cy5jIHwg
NSArKystLQo+ICAxIGZpbGUgY2hhbmdlZCwgMyBpbnNlcnRpb25zKCspLCAyIGRlbGV0aW9ucygt
KQo+IAo+IGRpZmYgLS1naXQgYS9kcml2ZXJzL3hlbi94ZW5idXMveGVuYnVzX3hzLmMgYi9kcml2
ZXJzL3hlbi94ZW5idXMveGVuYnVzX3hzLmMKPiBpbmRleCA0ODIyMGUxLi43YTJiMGRhIDEwMDY0
NAo+IC0tLSBhL2RyaXZlcnMveGVuL3hlbmJ1cy94ZW5idXNfeHMuYwo+ICsrKyBiL2RyaXZlcnMv
eGVuL3hlbmJ1cy94ZW5idXNfeHMuYwo+IEBAIC02MTksMTMgKzYxOSwxNCBAQCBzdGF0aWMgc3Ry
dWN0IHhlbmJ1c193YXRjaCAqZmluZF93YXRjaChjb25zdCBjaGFyICp0b2tlbikKPiAgCj4gIAly
ZXR1cm4gTlVMTDsKPiAgfQo+ICsKPiAgLyoKPiAgICogQ2VydGFpbiBvbGRlciBYZW5CdXMgdG9v
bHN0YWNrIGNhbm5vdCBoYW5kbGUgcmVhZGluZyB2YWx1ZXMgdGhhdCBhcmUKPiAgICogbm90IHBv
cHVsYXRlZC4gU29tZSBYZW4gMy40IGluc3RhbGxhdGlvbiBhcmUgaW5jYXBhYmxlIG9mIGRvaW5n
IHRoaXMKPiAgICogc28gaWYgd2UgYXJlIHJ1bm5pbmcgb24gYW55dGhpbmcgb2xkZXIgdGhhbiA0
IGRvIG5vdCBhdHRlbXB0IHRvIHJlYWQKPiAgICogY29udHJvbC9wbGF0Zm9ybS1mZWF0dXJlLXhz
X3Jlc2V0X3dhdGNoZXMuCj4gICAqLwo+IC1zdGF0aWMgYm9vbCB4ZW5fc3RyaWN0X3hlbmJ1c19x
dWlyaygpCj4gK3N0YXRpYyBib29sIHhlbl9zdHJpY3RfeGVuYnVzX3F1aXJrKHZvaWQpCj4gIHsK
PiAgCXVpbnQzMl90IGVheCwgZWJ4LCBlY3gsIGVkeCwgYmFzZTsKPiAgCj4gQEAgLTYzNSw4ICs2
MzYsOCBAQCBzdGF0aWMgYm9vbCB4ZW5fc3RyaWN0X3hlbmJ1c19xdWlyaygpCj4gIAlpZiAoKGVh
eCA+PiAxNikgPCA0KQo+ICAJCXJldHVybiB0cnVlOwo+ICAJcmV0dXJuIGZhbHNlOwo+IC0KPiAg
fQo+ICsKPiAgc3RhdGljIHZvaWQgeHNfcmVzZXRfd2F0Y2hlcyh2b2lkKQo+ICB7Cj4gIAlpbnQg
ZXJyLCBzdXBwb3J0ZWQgPSAwOwo+IC0tIAo+IDEuNy4xMS43CgpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1k
ZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Mon Oct 15 13:42:38 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 13:42:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNkw4-0000qe-CI; Mon, 15 Oct 2012 13:42:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNkw3-0000qZ-6s
	for xen-devel@lists.xensource.com; Mon, 15 Oct 2012 13:42:23 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1350308536!3571318!1
X-Originating-IP: [216.32.181.185]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3865 invoked from network); 15 Oct 2012 13:42:17 -0000
Received: from ch1ehsobe005.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.185)
	by server-6.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	15 Oct 2012 13:42:17 -0000
Received: from mail2-ch1-R.bigfish.com (10.43.68.225) by
	CH1EHSOBE002.bigfish.com (10.43.70.52) with Microsoft SMTP Server id
	14.1.225.23; Mon, 15 Oct 2012 13:42:15 +0000
Received: from mail2-ch1 (localhost [127.0.0.1])	by mail2-ch1-R.bigfish.com
	(Postfix) with ESMTP id 7E6D8300153;
	Mon, 15 Oct 2012 13:42:15 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: 8
X-BigFish: VPS8(zzbb2dI98dI9371I1dbaI1432I1418I4015Izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh137ah13b6h1441h133w1155h)
Received: from mail2-ch1 (localhost.localdomain [127.0.0.1]) by mail2-ch1
	(MessageSwitch) id 1350308502245383_21393;
	Mon, 15 Oct 2012 13:41:42 +0000 (UTC)
Received: from CH1EHSMHS041.bigfish.com (snatpool2.int.messaging.microsoft.com
	[10.43.68.233])	by mail2-ch1.bigfish.com (Postfix) with ESMTP id
	2DCF740230; Mon, 15 Oct 2012 13:41:42 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS041.bigfish.com (10.43.69.250) with Microsoft SMTP Server id
	14.1.225.23; Mon, 15 Oct 2012 13:41:40 +0000
X-WSS-ID: 0MBXSPA-02-C53-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2B702C810F;	Mon, 15 Oct 2012 08:41:29 -0500 (CDT)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Mon, 15 Oct 2012 08:57:13 -0500
Received: from STOREXDAG01.amd.com (10.1.13.10) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Mon, 15 Oct 2012 08:41:30 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexdag01.amd.com
	(10.1.13.10) with Microsoft SMTP Server id 14.1.323.3; Mon, 15 Oct 2012
	09:41:29 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 7C35449C35C; Mon, 15 Oct 2012
	14:41:28 +0100 (BST)
Message-ID: <507C129A.2010203@amd.com>
Date: Mon, 15 Oct 2012 15:41:46 +0200
From: Wei Wang 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120421 Thunderbird/12.0
MIME-Version: 1.0
To: Jan Beulich 
References: <5063155A.4070307@amd.com>
	<50642A2A020000780009E32D@nat28.tlf.novell.com>
	<507BDED1.6020005@amd.com>
	<507BFD7802000078000A1526@nat28.tlf.novell.com>
	<507C004B.20003@amd.com>
	<507C233702000078000A1670@nat28.tlf.novell.com>
In-Reply-To: <507C233702000078000A1670@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: Keir Fraser ,
	"xen-devel@lists.xensource.com" ,
	Ian Jackson ,
	IanCampbell 
Subject: Re: [Xen-devel] [PATCH 2 of 6 V6] amd iommu: call
	guest_iommu_set_base from hvmloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/15/2012 02:52 PM, Jan Beulich wrote:
>>>> On 15.10.12 at 14:23, Wei Wang  wrote:
>> On 10/15/2012 12:11 PM, Jan Beulich wrote:
>>>>>> On 15.10.12 at 12:00, Wei Wang   wrote:
>>>> On 09/27/2012 10:27 AM, Jan Beulich wrote:
>>>>>>>> On 26.09.12 at 16:46, Wei Wang    wrote:
>>>>>> @@ -3834,6 +3835,9 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void)
>>>> arg)
>>>>>>                case HVM_PARAM_BUFIOREQ_EVTCHN:
>>>>>>                    rc = -EINVAL;
>>>>>>                    break;
>>>>>> +            case HVM_PARAM_IOMMU_BASE:
>>>>>> +                rc = guest_iommu_set_base(d, a.value);
>>>>>
>>>>> This suggests that you're allowing for only a single IOMMU per
>>>>> guest - is that not going to become an issue sooner or later?
>>>>
>>>> I think that one iommu per guest is probably enough. Because guest IVRS
>>>> table is totally virtual, it does not reflect any pci relationship of
>>>> real systems. Even if qemu supports multi pci buses, we can still
>>>> virtually group them together into one virtual IVRS table. It might be
>>>> an issue if qemu uses multi pci segments, but so far even hardware iommu
>>>> only uses segment 0. Additionally, the guest iommu is only used by ats
>>>> capable GPUs. Normal passthrough device should not make use of it. So,,
>>>> What do you think?
>>>
>>> Especially the multi-segment aspect makes me think that the
>>> interface should allow for multiple IOMMUs, even if the
>>> implementation supports only one for now.
>>
>> Ok, then I will rework the interface to take iommu segment as an
>> additional parameter.
>
> That'll likely make the interface even more ugly than the more
> flexible variant allowing for multiple IOMMUs independent of
> the segment they're on/for. But let's see what you come up
> with...

Hi Jan
My idea is to make the interface looks like that
guest_iommu_set_base(d, iommu_base, iommu_seg)

This will allow hvmloader to choose a non-zero iommu segment.
if iommu_seg > 0, then I will add a new iommu to guest iommu list and 
update iommu_segment field accordingly. But I seem to see no reason to 
add multiple guest iommus to pci segment 0.

Thanks,
Wei

> Jan
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 13:42:38 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 13:42:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNkw4-0000qe-CI; Mon, 15 Oct 2012 13:42:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNkw3-0000qZ-6s
	for xen-devel@lists.xensource.com; Mon, 15 Oct 2012 13:42:23 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1350308536!3571318!1
X-Originating-IP: [216.32.181.185]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3865 invoked from network); 15 Oct 2012 13:42:17 -0000
Received: from ch1ehsobe005.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.185)
	by server-6.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	15 Oct 2012 13:42:17 -0000
Received: from mail2-ch1-R.bigfish.com (10.43.68.225) by
	CH1EHSOBE002.bigfish.com (10.43.70.52) with Microsoft SMTP Server id
	14.1.225.23; Mon, 15 Oct 2012 13:42:15 +0000
Received: from mail2-ch1 (localhost [127.0.0.1])	by mail2-ch1-R.bigfish.com
	(Postfix) with ESMTP id 7E6D8300153;
	Mon, 15 Oct 2012 13:42:15 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: 8
X-BigFish: VPS8(zzbb2dI98dI9371I1dbaI1432I1418I4015Izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh137ah13b6h1441h133w1155h)
Received: from mail2-ch1 (localhost.localdomain [127.0.0.1]) by mail2-ch1
	(MessageSwitch) id 1350308502245383_21393;
	Mon, 15 Oct 2012 13:41:42 +0000 (UTC)
Received: from CH1EHSMHS041.bigfish.com (snatpool2.int.messaging.microsoft.com
	[10.43.68.233])	by mail2-ch1.bigfish.com (Postfix) with ESMTP id
	2DCF740230; Mon, 15 Oct 2012 13:41:42 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS041.bigfish.com (10.43.69.250) with Microsoft SMTP Server id
	14.1.225.23; Mon, 15 Oct 2012 13:41:40 +0000
X-WSS-ID: 0MBXSPA-02-C53-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2B702C810F;	Mon, 15 Oct 2012 08:41:29 -0500 (CDT)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Mon, 15 Oct 2012 08:57:13 -0500
Received: from STOREXDAG01.amd.com (10.1.13.10) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Mon, 15 Oct 2012 08:41:30 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexdag01.amd.com
	(10.1.13.10) with Microsoft SMTP Server id 14.1.323.3; Mon, 15 Oct 2012
	09:41:29 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 7C35449C35C; Mon, 15 Oct 2012
	14:41:28 +0100 (BST)
Message-ID: <507C129A.2010203@amd.com>
Date: Mon, 15 Oct 2012 15:41:46 +0200
From: Wei Wang 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120421 Thunderbird/12.0
MIME-Version: 1.0
To: Jan Beulich 
References: <5063155A.4070307@amd.com>
	<50642A2A020000780009E32D@nat28.tlf.novell.com>
	<507BDED1.6020005@amd.com>
	<507BFD7802000078000A1526@nat28.tlf.novell.com>
	<507C004B.20003@amd.com>
	<507C233702000078000A1670@nat28.tlf.novell.com>
In-Reply-To: <507C233702000078000A1670@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: Keir Fraser ,
	"xen-devel@lists.xensource.com" ,
	Ian Jackson ,
	IanCampbell 
Subject: Re: [Xen-devel] [PATCH 2 of 6 V6] amd iommu: call
	guest_iommu_set_base from hvmloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/15/2012 02:52 PM, Jan Beulich wrote:
>>>> On 15.10.12 at 14:23, Wei Wang  wrote:
>> On 10/15/2012 12:11 PM, Jan Beulich wrote:
>>>>>> On 15.10.12 at 12:00, Wei Wang   wrote:
>>>> On 09/27/2012 10:27 AM, Jan Beulich wrote:
>>>>>>>> On 26.09.12 at 16:46, Wei Wang    wrote:
>>>>>> @@ -3834,6 +3835,9 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void)
>>>> arg)
>>>>>>                case HVM_PARAM_BUFIOREQ_EVTCHN:
>>>>>>                    rc = -EINVAL;
>>>>>>                    break;
>>>>>> +            case HVM_PARAM_IOMMU_BASE:
>>>>>> +                rc = guest_iommu_set_base(d, a.value);
>>>>>
>>>>> This suggests that you're allowing for only a single IOMMU per
>>>>> guest - is that not going to become an issue sooner or later?
>>>>
>>>> I think that one iommu per guest is probably enough. Because guest IVRS
>>>> table is totally virtual, it does not reflect any pci relationship of
>>>> real systems. Even if qemu supports multi pci buses, we can still
>>>> virtually group them together into one virtual IVRS table. It might be
>>>> an issue if qemu uses multi pci segments, but so far even hardware iommu
>>>> only uses segment 0. Additionally, the guest iommu is only used by ats
>>>> capable GPUs. Normal passthrough device should not make use of it. So,,
>>>> What do you think?
>>>
>>> Especially the multi-segment aspect makes me think that the
>>> interface should allow for multiple IOMMUs, even if the
>>> implementation supports only one for now.
>>
>> Ok, then I will rework the interface to take iommu segment as an
>> additional parameter.
>
> That'll likely make the interface even more ugly than the more
> flexible variant allowing for multiple IOMMUs independent of
> the segment they're on/for. But let's see what you come up
> with...

Hi Jan
My idea is to make the interface looks like that
guest_iommu_set_base(d, iommu_base, iommu_seg)

This will allow hvmloader to choose a non-zero iommu segment.
if iommu_seg > 0, then I will add a new iommu to guest iommu list and 
update iommu_segment field accordingly. But I seem to see no reason to 
add multiple guest iommus to pci segment 0.

Thanks,
Wei

> Jan
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 13:44:54 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 13:44:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNkyF-0000ws-5W; Mon, 15 Oct 2012 13:44:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNkyC-0000w1-SE
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 13:44:37 +0000
Received: from [85.158.139.83:11927] by server-12.bemta-5.messagelabs.com id
	F1/D1-26919-4431C705; Mon, 15 Oct 2012 13:44:36 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-182.messagelabs.com!1350308675!29302743!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.9 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MzMyOTU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MzMyOTU=\n,SUBJ_HAS_UNIQ_ID
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18608 invoked from network); 15 Oct 2012 13:44:35 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Oct 2012 13:44:35 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGjy0PFENx
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-081-177.pools.arcor-ip.net [88.65.81.177])
	by smtp.strato.de (joses mo48) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id R07488o9FDEcW0
	for ; Mon, 15 Oct 2012 15:44:35 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 6471018643
	for ; Mon, 15 Oct 2012 15:44:34 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 71ecc69cf74a0845d8825c7e73f3e5ca16cd4b76
Message-Id: <71ecc69cf74a0845d882.1350308660@probook.site>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 15 Oct 2012 15:44:20 +0200
From: Olaf Hering 
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 2 of 8] blktap2/libvhd: fix rpmlint warning
 spurious-executable-perm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering 
# Date 1350303771 -7200
# Node ID 71ecc69cf74a0845d8825c7e73f3e5ca16cd4b76
# Parent  9d005c3c16b1e8563a9d850b33bc03f5cda4705f
blktap2/libvhd: fix rpmlint warning spurious-executable-perm

[ 1758s] xen-devel.x86_64: E: spurious-executable-perm (Badness: 50) /usr/lib64/libvhd.a
[ 1758s] The file is installed with executable permissions, but was identified as one
[ 1758s] that probably should not be executable.  Verify if the executable bits are
[ 1758s] desired, and remove if not. NOTE: example scripts should be packaged under
[ 1758s] %docdir/examples, which will avoid this warning.

Signed-off-by: Olaf Hering 

diff -r 9d005c3c16b1 -r 71ecc69cf74a tools/blktap2/vhd/lib/Makefile
--- a/tools/blktap2/vhd/lib/Makefile
+++ b/tools/blktap2/vhd/lib/Makefile
@@ -68,7 +68,7 @@ libvhd.so.$(LIBVHD-MAJOR).$(LIBVHD-MINOR
 
 install: all
 	$(INSTALL_DIR) -p $(DESTDIR)$(INST-DIR)
-	$(INSTALL_PROG) libvhd.a $(DESTDIR)$(INST-DIR)
+	$(INSTALL_DATA) libvhd.a $(DESTDIR)$(INST-DIR)
 	$(INSTALL_PROG) libvhd.so.$(LIBVHD-MAJOR).$(LIBVHD-MINOR) $(DESTDIR)$(INST-DIR)
 	ln -sf libvhd.so.$(LIBVHD-MAJOR).$(LIBVHD-MINOR) $(DESTDIR)$(INST-DIR)/libvhd.so.$(LIBVHD-MAJOR)
 	ln -sf libvhd.so.$(LIBVHD-MAJOR) $(DESTDIR)$(INST-DIR)/libvhd.so

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 13:44:54 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 13:44:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNkyF-0000ws-5W; Mon, 15 Oct 2012 13:44:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNkyC-0000w1-SE
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 13:44:37 +0000
Received: from [85.158.139.83:11927] by server-12.bemta-5.messagelabs.com id
	F1/D1-26919-4431C705; Mon, 15 Oct 2012 13:44:36 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-182.messagelabs.com!1350308675!29302743!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.9 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MzMyOTU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MzMyOTU=\n,SUBJ_HAS_UNIQ_ID
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18608 invoked from network); 15 Oct 2012 13:44:35 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Oct 2012 13:44:35 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGjy0PFENx
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-081-177.pools.arcor-ip.net [88.65.81.177])
	by smtp.strato.de (joses mo48) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id R07488o9FDEcW0
	for ; Mon, 15 Oct 2012 15:44:35 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 6471018643
	for ; Mon, 15 Oct 2012 15:44:34 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 71ecc69cf74a0845d8825c7e73f3e5ca16cd4b76
Message-Id: <71ecc69cf74a0845d882.1350308660@probook.site>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 15 Oct 2012 15:44:20 +0200
From: Olaf Hering 
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 2 of 8] blktap2/libvhd: fix rpmlint warning
 spurious-executable-perm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering 
# Date 1350303771 -7200
# Node ID 71ecc69cf74a0845d8825c7e73f3e5ca16cd4b76
# Parent  9d005c3c16b1e8563a9d850b33bc03f5cda4705f
blktap2/libvhd: fix rpmlint warning spurious-executable-perm

[ 1758s] xen-devel.x86_64: E: spurious-executable-perm (Badness: 50) /usr/lib64/libvhd.a
[ 1758s] The file is installed with executable permissions, but was identified as one
[ 1758s] that probably should not be executable.  Verify if the executable bits are
[ 1758s] desired, and remove if not. NOTE: example scripts should be packaged under
[ 1758s] %docdir/examples, which will avoid this warning.

Signed-off-by: Olaf Hering 

diff -r 9d005c3c16b1 -r 71ecc69cf74a tools/blktap2/vhd/lib/Makefile
--- a/tools/blktap2/vhd/lib/Makefile
+++ b/tools/blktap2/vhd/lib/Makefile
@@ -68,7 +68,7 @@ libvhd.so.$(LIBVHD-MAJOR).$(LIBVHD-MINOR
 
 install: all
 	$(INSTALL_DIR) -p $(DESTDIR)$(INST-DIR)
-	$(INSTALL_PROG) libvhd.a $(DESTDIR)$(INST-DIR)
+	$(INSTALL_DATA) libvhd.a $(DESTDIR)$(INST-DIR)
 	$(INSTALL_PROG) libvhd.so.$(LIBVHD-MAJOR).$(LIBVHD-MINOR) $(DESTDIR)$(INST-DIR)
 	ln -sf libvhd.so.$(LIBVHD-MAJOR).$(LIBVHD-MINOR) $(DESTDIR)$(INST-DIR)/libvhd.so.$(LIBVHD-MAJOR)
 	ln -sf libvhd.so.$(LIBVHD-MAJOR) $(DESTDIR)$(INST-DIR)/libvhd.so

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 13:44:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 13:44:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNkyJ-0000ys-J0; Mon, 15 Oct 2012 13:44:43 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNkyI-0000w2-0v
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 13:44:42 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-27.messagelabs.com!1350308675!9885160!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDM0NjQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDM0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22138 invoked from network); 15 Oct 2012 13:44:35 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Oct 2012 13:44:35 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGjy0PFENx
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-081-177.pools.arcor-ip.net [88.65.81.177])
	by smtp.strato.de (jorabe mo3) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id g0545ao9FDEkrc
	for ; Mon, 15 Oct 2012 15:44:35 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 8D0E918645
	for ; Mon, 15 Oct 2012 15:44:34 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: ed893d76098bf0e41cd2c1d5d0392b7f36547c45
Message-Id: 
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 15 Oct 2012 15:44:22 +0200
From: Olaf Hering 
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 4 of 8] hotplug/Linux: add sysconfig tags to
	xencommons
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering 
# Date 1350305772 -7200
# Node ID ed893d76098bf0e41cd2c1d5d0392b7f36547c45
# Parent  ba9b347a31fed0aa57604d2342117282dd38b9bc
hotplug/Linux: add sysconfig tags to xencommons

YaST2 sysconfig can logically group the various sysconfig settings if the
files are tagged. Add the missing tags to xencommons.
See for a description
http://old-en.opensuse.org/Packaging/SUSE_Package_Conventions/Sysconfig

Signed-off-by: Olaf Hering 

diff -r ba9b347a31fe -r ed893d76098b tools/hotplug/Linux/init.d/sysconfig.xencommons
--- a/tools/hotplug/Linux/init.d/sysconfig.xencommons
+++ b/tools/hotplug/Linux/init.d/sysconfig.xencommons
@@ -1,15 +1,31 @@
+## Path: System/Virtualization
+## Type: string
+## Default: "none"
+#
 # Log xenconsoled messages (cf xl dmesg)
 #XENCONSOLED_TRACE=[none|guest|hv|all]
 
+## Type: string
+## Default: xenstored
+#
 # Select xenstored implementation
 #XENSTORED=[oxenstored|xenstored]
 
+## Type: string
+## Default: Not defined, tracing off
+#
 # Log xenstored messages
 #XENSTORED_TRACE=[yes|on|1]
 
+## Type: string
+## Default: "/var/lib/xenstored"
+#
 # Running xenstored on XENSTORED_ROOTDIR
 #XENSTORED_ROOTDIR=/var/lib/xenstored
 
+## Type: string
+## Default: Not defined, xenbackendd debug mode off
+#
 # Running xenbackendd in debug mode
 #XENBACKENDD_DEBUG=[yes|on|1]
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 13:44:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 13:44:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNkyJ-0000ys-J0; Mon, 15 Oct 2012 13:44:43 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNkyI-0000w2-0v
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 13:44:42 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-27.messagelabs.com!1350308675!9885160!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDM0NjQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDM0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22138 invoked from network); 15 Oct 2012 13:44:35 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Oct 2012 13:44:35 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGjy0PFENx
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-081-177.pools.arcor-ip.net [88.65.81.177])
	by smtp.strato.de (jorabe mo3) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id g0545ao9FDEkrc
	for ; Mon, 15 Oct 2012 15:44:35 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 8D0E918645
	for ; Mon, 15 Oct 2012 15:44:34 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: ed893d76098bf0e41cd2c1d5d0392b7f36547c45
Message-Id: 
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 15 Oct 2012 15:44:22 +0200
From: Olaf Hering 
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 4 of 8] hotplug/Linux: add sysconfig tags to
	xencommons
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering 
# Date 1350305772 -7200
# Node ID ed893d76098bf0e41cd2c1d5d0392b7f36547c45
# Parent  ba9b347a31fed0aa57604d2342117282dd38b9bc
hotplug/Linux: add sysconfig tags to xencommons

YaST2 sysconfig can logically group the various sysconfig settings if the
files are tagged. Add the missing tags to xencommons.
See for a description
http://old-en.opensuse.org/Packaging/SUSE_Package_Conventions/Sysconfig

Signed-off-by: Olaf Hering 

diff -r ba9b347a31fe -r ed893d76098b tools/hotplug/Linux/init.d/sysconfig.xencommons
--- a/tools/hotplug/Linux/init.d/sysconfig.xencommons
+++ b/tools/hotplug/Linux/init.d/sysconfig.xencommons
@@ -1,15 +1,31 @@
+## Path: System/Virtualization
+## Type: string
+## Default: "none"
+#
 # Log xenconsoled messages (cf xl dmesg)
 #XENCONSOLED_TRACE=[none|guest|hv|all]
 
+## Type: string
+## Default: xenstored
+#
 # Select xenstored implementation
 #XENSTORED=[oxenstored|xenstored]
 
+## Type: string
+## Default: Not defined, tracing off
+#
 # Log xenstored messages
 #XENSTORED_TRACE=[yes|on|1]
 
+## Type: string
+## Default: "/var/lib/xenstored"
+#
 # Running xenstored on XENSTORED_ROOTDIR
 #XENSTORED_ROOTDIR=/var/lib/xenstored
 
+## Type: string
+## Default: Not defined, xenbackendd debug mode off
+#
 # Running xenbackendd in debug mode
 #XENBACKENDD_DEBUG=[yes|on|1]
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 13:44:56 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 13:44:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNkyE-0000wj-PW; Mon, 15 Oct 2012 13:44:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNkyC-0000w0-SU
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 13:44:36 +0000
Received: from [85.158.143.99:7176] by server-3.bemta-4.messagelabs.com id
	DA/54-10075-4431C705; Mon, 15 Oct 2012 13:44:36 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-216.messagelabs.com!1350308675!33560582!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MzMyOTU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MzMyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4862 invoked from network); 15 Oct 2012 13:44:36 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Oct 2012 13:44:36 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGjy0PFENx
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-081-177.pools.arcor-ip.net [88.65.81.177])
	by smtp.strato.de (josoe mo22) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id R02e02o9FChTSU
	for ; Mon, 15 Oct 2012 15:44:35 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id DEAE0183A7
	for ; Mon, 15 Oct 2012 15:44:34 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 1cded8c6fc32aef391943e7f4c207d196c9a0819
Message-Id: <1cded8c6fc32aef39194.1350308664@probook.site>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 15 Oct 2012 15:44:24 +0200
From: Olaf Hering 
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 6 of 8] stubdom: install stubdompath.sh as data
	file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering 
# Date 1350307085 -7200
# Node ID 1cded8c6fc32aef391943e7f4c207d196c9a0819
# Parent  eec0c79c0222dd843cc45bab999338eed6004e30
stubdom: install stubdompath.sh as data file

rpmlint complains a script helper which is only sourced:

[ 1875s] xen-tools.i586: W: script-without-shebang /usr/lib/xen/bin/stubdompath.sh
[ 1875s] This text file has executable bits set or is located in a path dedicated for
[ 1875s] executables, but lacks a shebang and cannot thus be executed.  If the file is
[ 1875s] meant to be an executable script, add the shebang, otherwise remove the
[ 1875s] executable bits or move the file elsewhere.

Signed-off-by: Olaf Hering 

diff -r eec0c79c0222 -r 1cded8c6fc32 stubdom/Makefile
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -386,7 +386,8 @@ install-readme:
 
 install-ioemu: ioemu-stubdom
 	$(INSTALL_DIR) "$(DESTDIR)$(LIBEXEC)"
-	$(INSTALL_PROG) stubdompath.sh stubdom-dm "$(DESTDIR)$(LIBEXEC)"
+	$(INSTALL_PROG) stubdom-dm "$(DESTDIR)$(LIBEXEC)"
+	$(INSTALL_DATA) stubdompath.sh "$(DESTDIR)$(LIBEXEC)"
 	$(INSTALL_DIR) "$(DESTDIR)$(XENFIRMWAREDIR)"
 	$(INSTALL_DATA) mini-os-$(XEN_TARGET_ARCH)-ioemu/mini-os.gz "$(DESTDIR)$(XENFIRMWAREDIR)/ioemu-stubdom.gz"
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 13:44:56 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 13:44:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNkyE-0000wj-PW; Mon, 15 Oct 2012 13:44:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNkyC-0000w0-SU
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 13:44:36 +0000
Received: from [85.158.143.99:7176] by server-3.bemta-4.messagelabs.com id
	DA/54-10075-4431C705; Mon, 15 Oct 2012 13:44:36 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-216.messagelabs.com!1350308675!33560582!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MzMyOTU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MzMyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4862 invoked from network); 15 Oct 2012 13:44:36 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Oct 2012 13:44:36 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGjy0PFENx
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-081-177.pools.arcor-ip.net [88.65.81.177])
	by smtp.strato.de (josoe mo22) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id R02e02o9FChTSU
	for ; Mon, 15 Oct 2012 15:44:35 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id DEAE0183A7
	for ; Mon, 15 Oct 2012 15:44:34 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 1cded8c6fc32aef391943e7f4c207d196c9a0819
Message-Id: <1cded8c6fc32aef39194.1350308664@probook.site>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 15 Oct 2012 15:44:24 +0200
From: Olaf Hering 
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 6 of 8] stubdom: install stubdompath.sh as data
	file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering 
# Date 1350307085 -7200
# Node ID 1cded8c6fc32aef391943e7f4c207d196c9a0819
# Parent  eec0c79c0222dd843cc45bab999338eed6004e30
stubdom: install stubdompath.sh as data file

rpmlint complains a script helper which is only sourced:

[ 1875s] xen-tools.i586: W: script-without-shebang /usr/lib/xen/bin/stubdompath.sh
[ 1875s] This text file has executable bits set or is located in a path dedicated for
[ 1875s] executables, but lacks a shebang and cannot thus be executed.  If the file is
[ 1875s] meant to be an executable script, add the shebang, otherwise remove the
[ 1875s] executable bits or move the file elsewhere.

Signed-off-by: Olaf Hering 

diff -r eec0c79c0222 -r 1cded8c6fc32 stubdom/Makefile
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -386,7 +386,8 @@ install-readme:
 
 install-ioemu: ioemu-stubdom
 	$(INSTALL_DIR) "$(DESTDIR)$(LIBEXEC)"
-	$(INSTALL_PROG) stubdompath.sh stubdom-dm "$(DESTDIR)$(LIBEXEC)"
+	$(INSTALL_PROG) stubdom-dm "$(DESTDIR)$(LIBEXEC)"
+	$(INSTALL_DATA) stubdompath.sh "$(DESTDIR)$(LIBEXEC)"
 	$(INSTALL_DIR) "$(DESTDIR)$(XENFIRMWAREDIR)"
 	$(INSTALL_DATA) mini-os-$(XEN_TARGET_ARCH)-ioemu/mini-os.gz "$(DESTDIR)$(XENFIRMWAREDIR)/ioemu-stubdom.gz"
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 13:44:57 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 13:44:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNkyF-0000xI-V8; Mon, 15 Oct 2012 13:44:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNkyD-0000wK-N7
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 13:44:37 +0000
Received: from [85.158.139.211:31906] by server-14.bemta-5.messagelabs.com id
	5E/A9-24068-5431C705; Mon, 15 Oct 2012 13:44:37 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-206.messagelabs.com!1350308676!18393063!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDM0NjQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDM0NjQ=\n,UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13531 invoked from network); 15 Oct 2012 13:44:36 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Oct 2012 13:44:36 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGjy0PFENx
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-081-177.pools.arcor-ip.net [88.65.81.177])
	by smtp.strato.de (joses mo16) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id L06b97o9FCu8Ia
	for ; Mon, 15 Oct 2012 15:44:35 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 2081918642
	for ; Mon, 15 Oct 2012 15:44:35 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: ce697a3171e3d49675e2d46ca27e74c9710ba8c8
Message-Id: 
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 15 Oct 2012 15:44:26 +0200
From: Olaf Hering 
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 8 of 8] hotplug/Linux: install sysconfig files
	as data files
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering 
# Date 1350307814 -7200
# Node ID ce697a3171e3d49675e2d46ca27e74c9710ba8c8
# Parent  588061a50040df5f1b65c4538697e2161e99e37d
hotplug/Linux: install sysconfig files as data files

rpmlint complains about wrong permissions of config files:

[  455s] xen-tools.i586: W: script-without-shebang /var/adm/fillup-templates/sysconfig.xendomains
[  455s] xen-tools.i586: W: script-without-shebang /var/adm/fillup-templates/sysconfig.xencommons
[  455s] This text file has executable bits set or is located in a path dedicated for
[  455s] executables, but lacks a shebang and cannot thus be executed.  If the file is
[  455s] meant to be an executable script, add the shebang, otherwise remove the
[  455s] executable bits or move the file elsewhere.

Signed-off-by: Olaf Hering 

diff -r 588061a50040 -r ce697a3171e3 tools/hotplug/Linux/Makefile
--- a/tools/hotplug/Linux/Makefile
+++ b/tools/hotplug/Linux/Makefile
@@ -69,9 +69,9 @@ install-initd:
 	[ -d $(DESTDIR)$(SYSCONFIG_DIR) ] || $(INSTALL_DIR) $(DESTDIR)$(SYSCONFIG_DIR)
 	$(INSTALL_PROG) $(XEND_INITD) $(DESTDIR)$(INITD_DIR)
 	$(INSTALL_PROG) $(XENDOMAINS_INITD) $(DESTDIR)$(INITD_DIR)
-	$(INSTALL_PROG) $(XENDOMAINS_SYSCONFIG) $(DESTDIR)$(SYSCONFIG_DIR)/xendomains
+	$(INSTALL_DATA) $(XENDOMAINS_SYSCONFIG) $(DESTDIR)$(SYSCONFIG_DIR)/xendomains
 	$(INSTALL_PROG) $(XENCOMMONS_INITD) $(DESTDIR)$(INITD_DIR)
-	$(INSTALL_PROG) $(XENCOMMONS_SYSCONFIG) $(DESTDIR)$(SYSCONFIG_DIR)/xencommons
+	$(INSTALL_DATA) $(XENCOMMONS_SYSCONFIG) $(DESTDIR)$(SYSCONFIG_DIR)/xencommons
 	$(INSTALL_PROG) init.d/xen-watchdog $(DESTDIR)$(INITD_DIR)
 
 .PHONY: install-scripts

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 13:44:57 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 13:44:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNkyF-0000xI-V8; Mon, 15 Oct 2012 13:44:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNkyD-0000wK-N7
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 13:44:37 +0000
Received: from [85.158.139.211:31906] by server-14.bemta-5.messagelabs.com id
	5E/A9-24068-5431C705; Mon, 15 Oct 2012 13:44:37 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-206.messagelabs.com!1350308676!18393063!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDM0NjQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDM0NjQ=\n,UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13531 invoked from network); 15 Oct 2012 13:44:36 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Oct 2012 13:44:36 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGjy0PFENx
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-081-177.pools.arcor-ip.net [88.65.81.177])
	by smtp.strato.de (joses mo16) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id L06b97o9FCu8Ia
	for ; Mon, 15 Oct 2012 15:44:35 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 2081918642
	for ; Mon, 15 Oct 2012 15:44:35 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: ce697a3171e3d49675e2d46ca27e74c9710ba8c8
Message-Id: 
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 15 Oct 2012 15:44:26 +0200
From: Olaf Hering 
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 8 of 8] hotplug/Linux: install sysconfig files
	as data files
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering 
# Date 1350307814 -7200
# Node ID ce697a3171e3d49675e2d46ca27e74c9710ba8c8
# Parent  588061a50040df5f1b65c4538697e2161e99e37d
hotplug/Linux: install sysconfig files as data files

rpmlint complains about wrong permissions of config files:

[  455s] xen-tools.i586: W: script-without-shebang /var/adm/fillup-templates/sysconfig.xendomains
[  455s] xen-tools.i586: W: script-without-shebang /var/adm/fillup-templates/sysconfig.xencommons
[  455s] This text file has executable bits set or is located in a path dedicated for
[  455s] executables, but lacks a shebang and cannot thus be executed.  If the file is
[  455s] meant to be an executable script, add the shebang, otherwise remove the
[  455s] executable bits or move the file elsewhere.

Signed-off-by: Olaf Hering 

diff -r 588061a50040 -r ce697a3171e3 tools/hotplug/Linux/Makefile
--- a/tools/hotplug/Linux/Makefile
+++ b/tools/hotplug/Linux/Makefile
@@ -69,9 +69,9 @@ install-initd:
 	[ -d $(DESTDIR)$(SYSCONFIG_DIR) ] || $(INSTALL_DIR) $(DESTDIR)$(SYSCONFIG_DIR)
 	$(INSTALL_PROG) $(XEND_INITD) $(DESTDIR)$(INITD_DIR)
 	$(INSTALL_PROG) $(XENDOMAINS_INITD) $(DESTDIR)$(INITD_DIR)
-	$(INSTALL_PROG) $(XENDOMAINS_SYSCONFIG) $(DESTDIR)$(SYSCONFIG_DIR)/xendomains
+	$(INSTALL_DATA) $(XENDOMAINS_SYSCONFIG) $(DESTDIR)$(SYSCONFIG_DIR)/xendomains
 	$(INSTALL_PROG) $(XENCOMMONS_INITD) $(DESTDIR)$(INITD_DIR)
-	$(INSTALL_PROG) $(XENCOMMONS_SYSCONFIG) $(DESTDIR)$(SYSCONFIG_DIR)/xencommons
+	$(INSTALL_DATA) $(XENCOMMONS_SYSCONFIG) $(DESTDIR)$(SYSCONFIG_DIR)/xencommons
 	$(INSTALL_PROG) init.d/xen-watchdog $(DESTDIR)$(INITD_DIR)
 
 .PHONY: install-scripts

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 13:44:59 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 13:44:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNkyE-0000wV-1W; Mon, 15 Oct 2012 13:44:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNkyC-0000w0-DG
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 13:44:36 +0000
Received: from [85.158.143.99:4057] by server-3.bemta-4.messagelabs.com id
	75/54-10075-3431C705; Mon, 15 Oct 2012 13:44:35 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-216.messagelabs.com!1350308674!33837270!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDM0NjQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDM0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28840 invoked from network); 15 Oct 2012 13:44:35 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Oct 2012 13:44:35 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGjy0PFENx
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-081-177.pools.arcor-ip.net [88.65.81.177])
	by smtp.strato.de (josoe mo16) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id L02d48o9FDdjfD
	for ; Mon, 15 Oct 2012 15:44:34 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 25650183A7
	for ; Mon, 15 Oct 2012 15:44:34 +0200 (CEST)
MIME-Version: 1.0
Message-Id: 
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 15 Oct 2012 15:44:18 +0200
From: Olaf Hering 
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 0 of 8] tools: various packaging fixes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The following changes fix some rpmlint warnings and correct the
sysconfig metadata used by YaST2.

Please consider this series also for 4.2.1 to reduce the amount of
patches in xen.src.rpm. Thanks.

Olaf

Changes:
stubdom: fix rpmlint warning spurious-executable-perm
blktap2/libvhd: fix rpmlint warning spurious-executable-perm
blktap: fix rpmlint warning spurious-executable-perm
hotplug/Linux: add sysconfig tags to xencommons
hotplug: install hotplugpath.sh as data file
stubdom: install stubdompath.sh as data file
hotplug/Linux: correct sysconfig tag in xendomains
hotplug/Linux: install sysconfig files as data files

 stubdom/Makefile                                |    5 +++--
 tools/blktap/lib/Makefile                       |   10 ++++++----
 tools/blktap2/vhd/lib/Makefile                  |    2 +-
 tools/hotplug/Linux/Makefile                    |    4 ++--
 tools/hotplug/Linux/init.d/sysconfig.xencommons |   16 ++++++++++++++++
 tools/hotplug/Linux/init.d/sysconfig.xendomains |    2 +-
 tools/hotplug/common/Makefile                   |    4 ++--
 7 files changed, 31 insertions(+), 12 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 13:44:59 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 13:44:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNkyE-0000wV-1W; Mon, 15 Oct 2012 13:44:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNkyC-0000w0-DG
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 13:44:36 +0000
Received: from [85.158.143.99:4057] by server-3.bemta-4.messagelabs.com id
	75/54-10075-3431C705; Mon, 15 Oct 2012 13:44:35 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-216.messagelabs.com!1350308674!33837270!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDM0NjQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDM0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28840 invoked from network); 15 Oct 2012 13:44:35 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Oct 2012 13:44:35 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGjy0PFENx
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-081-177.pools.arcor-ip.net [88.65.81.177])
	by smtp.strato.de (josoe mo16) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id L02d48o9FDdjfD
	for ; Mon, 15 Oct 2012 15:44:34 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 25650183A7
	for ; Mon, 15 Oct 2012 15:44:34 +0200 (CEST)
MIME-Version: 1.0
Message-Id: 
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 15 Oct 2012 15:44:18 +0200
From: Olaf Hering 
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 0 of 8] tools: various packaging fixes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The following changes fix some rpmlint warnings and correct the
sysconfig metadata used by YaST2.

Please consider this series also for 4.2.1 to reduce the amount of
patches in xen.src.rpm. Thanks.

Olaf

Changes:
stubdom: fix rpmlint warning spurious-executable-perm
blktap2/libvhd: fix rpmlint warning spurious-executable-perm
blktap: fix rpmlint warning spurious-executable-perm
hotplug/Linux: add sysconfig tags to xencommons
hotplug: install hotplugpath.sh as data file
stubdom: install stubdompath.sh as data file
hotplug/Linux: correct sysconfig tag in xendomains
hotplug/Linux: install sysconfig files as data files

 stubdom/Makefile                                |    5 +++--
 tools/blktap/lib/Makefile                       |   10 ++++++----
 tools/blktap2/vhd/lib/Makefile                  |    2 +-
 tools/hotplug/Linux/Makefile                    |    4 ++--
 tools/hotplug/Linux/init.d/sysconfig.xencommons |   16 ++++++++++++++++
 tools/hotplug/Linux/init.d/sysconfig.xendomains |    2 +-
 tools/hotplug/common/Makefile                   |    4 ++--
 7 files changed, 31 insertions(+), 12 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 13:45:00 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 13:45:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNkyE-0000wc-Dh; Mon, 15 Oct 2012 13:44:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNkyC-0000vz-Ed
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 13:44:36 +0000
Received: from [85.158.137.99:5555] by server-5.bemta-3.messagelabs.com id
	6B/3A-12440-3431C705; Mon, 15 Oct 2012 13:44:35 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-217.messagelabs.com!1350308675!19276649!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.9 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDM0NjQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDM0NjQ=\n,SUBJ_HAS_UNIQ_ID
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12313 invoked from network); 15 Oct 2012 13:44:35 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-15.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Oct 2012 13:44:35 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGjy0PFENx
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-081-177.pools.arcor-ip.net [88.65.81.177])
	by smtp.strato.de (jored mo19) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id C06634o9FDfEqh
	for ; Mon, 15 Oct 2012 15:44:34 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 4923718642
	for ; Mon, 15 Oct 2012 15:44:34 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 9d005c3c16b1e8563a9d850b33bc03f5cda4705f
Message-Id: <9d005c3c16b1e8563a9d.1350308659@probook.site>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 15 Oct 2012 15:44:19 +0200
From: Olaf Hering 
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 1 of 8] stubdom: fix rpmlint warning
	spurious-executable-perm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering 
# Date 1350303619 -7200
# Node ID 9d005c3c16b1e8563a9d850b33bc03f5cda4705f
# Parent  137dfbd3190e849b3a498d8b2ea282ebbf12e77d
stubdom: fix rpmlint warning spurious-executable-perm

[ 1758s] xen-tools.x86_64: E: spurious-executable-perm (Badness: 50) /usr/lib/xen/boot/xenstore-stubdom.gz
[ 1758s] The file is installed with executable permissions, but was identified as one
[ 1758s] that probably should not be executable.  Verify if the executable bits are
[ 1758s] desired, and remove if not. NOTE: example scripts should be packaged under
[ 1758s] %docdir/examples, which will avoid this warning.

Signed-off-by: Olaf Hering 

diff -r 137dfbd3190e -r 9d005c3c16b1 stubdom/Makefile
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -396,7 +396,7 @@ install-grub: pv-grub
 
 install-xenstore: xenstore-stubdom
 	$(INSTALL_DIR) "$(DESTDIR)/usr/lib/xen/boot"
-	$(INSTALL_PROG) mini-os-$(XEN_TARGET_ARCH)-xenstore/mini-os.gz "$(DESTDIR)/usr/lib/xen/boot/xenstore-stubdom.gz"
+	$(INSTALL_DATA) mini-os-$(XEN_TARGET_ARCH)-xenstore/mini-os.gz "$(DESTDIR)/usr/lib/xen/boot/xenstore-stubdom.gz"
 
 #######
 # clean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 13:45:00 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 13:45:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNkyE-0000wc-Dh; Mon, 15 Oct 2012 13:44:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNkyC-0000vz-Ed
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 13:44:36 +0000
Received: from [85.158.137.99:5555] by server-5.bemta-3.messagelabs.com id
	6B/3A-12440-3431C705; Mon, 15 Oct 2012 13:44:35 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-217.messagelabs.com!1350308675!19276649!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.9 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDM0NjQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDM0NjQ=\n,SUBJ_HAS_UNIQ_ID
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12313 invoked from network); 15 Oct 2012 13:44:35 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-15.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Oct 2012 13:44:35 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGjy0PFENx
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-081-177.pools.arcor-ip.net [88.65.81.177])
	by smtp.strato.de (jored mo19) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id C06634o9FDfEqh
	for ; Mon, 15 Oct 2012 15:44:34 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 4923718642
	for ; Mon, 15 Oct 2012 15:44:34 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 9d005c3c16b1e8563a9d850b33bc03f5cda4705f
Message-Id: <9d005c3c16b1e8563a9d.1350308659@probook.site>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 15 Oct 2012 15:44:19 +0200
From: Olaf Hering 
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 1 of 8] stubdom: fix rpmlint warning
	spurious-executable-perm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering 
# Date 1350303619 -7200
# Node ID 9d005c3c16b1e8563a9d850b33bc03f5cda4705f
# Parent  137dfbd3190e849b3a498d8b2ea282ebbf12e77d
stubdom: fix rpmlint warning spurious-executable-perm

[ 1758s] xen-tools.x86_64: E: spurious-executable-perm (Badness: 50) /usr/lib/xen/boot/xenstore-stubdom.gz
[ 1758s] The file is installed with executable permissions, but was identified as one
[ 1758s] that probably should not be executable.  Verify if the executable bits are
[ 1758s] desired, and remove if not. NOTE: example scripts should be packaged under
[ 1758s] %docdir/examples, which will avoid this warning.

Signed-off-by: Olaf Hering 

diff -r 137dfbd3190e -r 9d005c3c16b1 stubdom/Makefile
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -396,7 +396,7 @@ install-grub: pv-grub
 
 install-xenstore: xenstore-stubdom
 	$(INSTALL_DIR) "$(DESTDIR)/usr/lib/xen/boot"
-	$(INSTALL_PROG) mini-os-$(XEN_TARGET_ARCH)-xenstore/mini-os.gz "$(DESTDIR)/usr/lib/xen/boot/xenstore-stubdom.gz"
+	$(INSTALL_DATA) mini-os-$(XEN_TARGET_ARCH)-xenstore/mini-os.gz "$(DESTDIR)/usr/lib/xen/boot/xenstore-stubdom.gz"
 
 #######
 # clean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 13:45:01 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 13:45:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNkyF-0000x5-Hu; Mon, 15 Oct 2012 13:44:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNkyD-0000w4-0q
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 13:44:37 +0000
Received: from [85.158.138.51:18989] by server-9.bemta-3.messagelabs.com id
	18/46-16841-4431C705; Mon, 15 Oct 2012 13:44:36 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-174.messagelabs.com!1350308675!26504789!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NTU0NjA=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NTU0NjA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23336 invoked from network); 15 Oct 2012 13:44:35 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Oct 2012 13:44:35 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGjy0PFENx
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-081-177.pools.arcor-ip.net [88.65.81.177])
	by smtp.strato.de (josoe mo1) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id e028d7o9FDWYBl
	for ; Mon, 15 Oct 2012 15:44:35 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id C3C2018646
	for ; Mon, 15 Oct 2012 15:44:34 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: eec0c79c0222dd843cc45bab999338eed6004e30
Message-Id: 
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 15 Oct 2012 15:44:23 +0200
From: Olaf Hering 
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 5 of 8] hotplug: install hotplugpath.sh as data
	file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering 
# Date 1350306601 -7200
# Node ID eec0c79c0222dd843cc45bab999338eed6004e30
# Parent  ed893d76098bf0e41cd2c1d5d0392b7f36547c45
hotplug: install hotplugpath.sh as data file

rpmlint complains a script helper which is only sourced:

[ 1875s] xen-tools.i586: W: script-without-shebang /etc/xen/scripts/hotplugpath.sh
[ 1875s] This text file has executable bits set or is located in a path dedicated for
[ 1875s] executables, but lacks a shebang and cannot thus be executed.  If the file is
[ 1875s] meant to be an executable script, add the shebang, otherwise remove the
[ 1875s] executable bits or move the file elsewhere.

Signed-off-by: Olaf Hering 

diff -r ed893d76098b -r eec0c79c0222 tools/hotplug/common/Makefile
--- a/tools/hotplug/common/Makefile
+++ b/tools/hotplug/common/Makefile
@@ -6,8 +6,8 @@ HOTPLUGPATH="hotplugpath.sh"
 # OS-independent hotplug scripts go in this directory
 
 # Xen scripts to go there.
-XEN_SCRIPTS = $(HOTPLUGPATH)
-XEN_SCRIPT_DATA =
+XEN_SCRIPTS =
+XEN_SCRIPT_DATA = $(HOTPLUGPATH)
 
 genpath-target = $(call buildmakevars2file,$(HOTPLUGPATH))
 $(eval $(genpath-target))

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 13:45:01 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 13:45:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNkyF-0000x5-Hu; Mon, 15 Oct 2012 13:44:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNkyD-0000w4-0q
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 13:44:37 +0000
Received: from [85.158.138.51:18989] by server-9.bemta-3.messagelabs.com id
	18/46-16841-4431C705; Mon, 15 Oct 2012 13:44:36 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-174.messagelabs.com!1350308675!26504789!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NTU0NjA=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NTU0NjA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23336 invoked from network); 15 Oct 2012 13:44:35 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 15 Oct 2012 13:44:35 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGjy0PFENx
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-081-177.pools.arcor-ip.net [88.65.81.177])
	by smtp.strato.de (josoe mo1) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id e028d7o9FDWYBl
	for ; Mon, 15 Oct 2012 15:44:35 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id C3C2018646
	for ; Mon, 15 Oct 2012 15:44:34 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: eec0c79c0222dd843cc45bab999338eed6004e30
Message-Id: 
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 15 Oct 2012 15:44:23 +0200
From: Olaf Hering 
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 5 of 8] hotplug: install hotplugpath.sh as data
	file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering 
# Date 1350306601 -7200
# Node ID eec0c79c0222dd843cc45bab999338eed6004e30
# Parent  ed893d76098bf0e41cd2c1d5d0392b7f36547c45
hotplug: install hotplugpath.sh as data file

rpmlint complains a script helper which is only sourced:

[ 1875s] xen-tools.i586: W: script-without-shebang /etc/xen/scripts/hotplugpath.sh
[ 1875s] This text file has executable bits set or is located in a path dedicated for
[ 1875s] executables, but lacks a shebang and cannot thus be executed.  If the file is
[ 1875s] meant to be an executable script, add the shebang, otherwise remove the
[ 1875s] executable bits or move the file elsewhere.

Signed-off-by: Olaf Hering 

diff -r ed893d76098b -r eec0c79c0222 tools/hotplug/common/Makefile
--- a/tools/hotplug/common/Makefile
+++ b/tools/hotplug/common/Makefile
@@ -6,8 +6,8 @@ HOTPLUGPATH="hotplugpath.sh"
 # OS-independent hotplug scripts go in this directory
 
 # Xen scripts to go there.
-XEN_SCRIPTS = $(HOTPLUGPATH)
-XEN_SCRIPT_DATA =
+XEN_SCRIPTS =
+XEN_SCRIPT_DATA = $(HOTPLUGPATH)
 
 genpath-target = $(call buildmakevars2file,$(HOTPLUGPATH))
 $(eval $(genpath-target))

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 13:45:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 13:45:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNkyK-0000zc-Vf; Mon, 15 Oct 2012 13:44:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNkyI-0000yM-W4
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 13:44:43 +0000
Received: from [85.158.143.35:62808] by server-3.bemta-4.messagelabs.com id
	77/74-10075-A431C705; Mon, 15 Oct 2012 13:44:42 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-21.messagelabs.com!1350308675!14727667!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.9 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MzMyOTU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MzMyOTU=\n,SUBJ_HAS_UNIQ_ID,
	UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17677 invoked from network); 15 Oct 2012 13:44:37 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Oct 2012 13:44:37 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGjy0PFENx
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-081-177.pools.arcor-ip.net [88.65.81.177])
	by smtp.strato.de (jorabe mo48) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id R0600do9FD0Dwd
	for ; Mon, 15 Oct 2012 15:44:35 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 7A10A18644
	for ; Mon, 15 Oct 2012 15:44:34 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: ba9b347a31fed0aa57604d2342117282dd38b9bc
Message-Id: 
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 15 Oct 2012 15:44:21 +0200
From: Olaf Hering 
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 3 of 8] blktap: fix rpmlint warning
	spurious-executable-perm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering 
# Date 1350303963 -7200
# Node ID ba9b347a31fed0aa57604d2342117282dd38b9bc
# Parent  71ecc69cf74a0845d8825c7e73f3e5ca16cd4b76
blktap: fix rpmlint warning spurious-executable-perm

[ 1758s] xen-devel.x86_64: E: spurious-executable-perm (Badness: 50) /usr/lib64/libblktap.a
[ 1758s] The file is installed with executable permissions, but was identified as one
[ 1758s] that probably should not be executable.  Verify if the executable bits are
[ 1758s] desired, and remove if not. NOTE: example scripts should be packaged under
[ 1758s] %docdir/examples, which will avoid this warning.

Signed-off-by: Olaf Hering 

diff -r 71ecc69cf74a -r ba9b347a31fe tools/blktap/lib/Makefile
--- a/tools/blktap/lib/Makefile
+++ b/tools/blktap/lib/Makefile
@@ -23,23 +23,25 @@ OBJS     = $(SRCS:.c=.o)
 OBJS_PIC = $(SRCS:.c=.opic)
 IBINS   :=
 
-LIB      = libblktap.a libblktap.so.$(MAJOR).$(MINOR)
+LIB      = libblktap.a
+LIB_SO   = libblktap.so.$(MAJOR).$(MINOR)
 
 .PHONY: all
-all: $(LIB)
+all: $(LIB) $(LIB_SO)
 
 .PHONY: install
 install: all
 	$(INSTALL_DIR) $(DESTDIR)$(LIBDIR)
 	$(INSTALL_DIR) $(DESTDIR)$(INCLUDEDIR)
-	$(INSTALL_PROG) $(LIB) $(DESTDIR)$(LIBDIR)
+	$(INSTALL_PROG) $(LIB_SO) $(DESTDIR)$(LIBDIR)
+	$(INSTALL_DATA) $(LIB) $(DESTDIR)$(LIBDIR)
 	ln -sf libblktap.so.$(MAJOR).$(MINOR) $(DESTDIR)$(LIBDIR)/libblktap.so.$(MAJOR)
 	ln -sf libblktap.so.$(MAJOR) $(DESTDIR)$(LIBDIR)/libblktap.so
 	$(INSTALL_DATA) blktaplib.h $(DESTDIR)$(INCLUDEDIR)
 
 .PHONY: clean
 clean:
-	rm -rf *.a *.so* *.o *.opic *.rpm $(LIB) *~ $(DEPS) xen TAGS
+	rm -rf *.a *.so* *.o *.opic *.rpm $(LIB) $(LIB_SO) *~ $(DEPS) xen TAGS
 
 libblktap.so.$(MAJOR).$(MINOR): $(OBJS_PIC) 
 	$(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,$(SONAME) $(SHLIB_LDFLAGS) \

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 13:45:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 13:45:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNkyK-0000zc-Vf; Mon, 15 Oct 2012 13:44:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNkyI-0000yM-W4
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 13:44:43 +0000
Received: from [85.158.143.35:62808] by server-3.bemta-4.messagelabs.com id
	77/74-10075-A431C705; Mon, 15 Oct 2012 13:44:42 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-21.messagelabs.com!1350308675!14727667!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.9 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MzMyOTU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MzMyOTU=\n,SUBJ_HAS_UNIQ_ID,
	UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17677 invoked from network); 15 Oct 2012 13:44:37 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Oct 2012 13:44:37 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGjy0PFENx
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-081-177.pools.arcor-ip.net [88.65.81.177])
	by smtp.strato.de (jorabe mo48) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id R0600do9FD0Dwd
	for ; Mon, 15 Oct 2012 15:44:35 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 7A10A18644
	for ; Mon, 15 Oct 2012 15:44:34 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: ba9b347a31fed0aa57604d2342117282dd38b9bc
Message-Id: 
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 15 Oct 2012 15:44:21 +0200
From: Olaf Hering 
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 3 of 8] blktap: fix rpmlint warning
	spurious-executable-perm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering 
# Date 1350303963 -7200
# Node ID ba9b347a31fed0aa57604d2342117282dd38b9bc
# Parent  71ecc69cf74a0845d8825c7e73f3e5ca16cd4b76
blktap: fix rpmlint warning spurious-executable-perm

[ 1758s] xen-devel.x86_64: E: spurious-executable-perm (Badness: 50) /usr/lib64/libblktap.a
[ 1758s] The file is installed with executable permissions, but was identified as one
[ 1758s] that probably should not be executable.  Verify if the executable bits are
[ 1758s] desired, and remove if not. NOTE: example scripts should be packaged under
[ 1758s] %docdir/examples, which will avoid this warning.

Signed-off-by: Olaf Hering 

diff -r 71ecc69cf74a -r ba9b347a31fe tools/blktap/lib/Makefile
--- a/tools/blktap/lib/Makefile
+++ b/tools/blktap/lib/Makefile
@@ -23,23 +23,25 @@ OBJS     = $(SRCS:.c=.o)
 OBJS_PIC = $(SRCS:.c=.opic)
 IBINS   :=
 
-LIB      = libblktap.a libblktap.so.$(MAJOR).$(MINOR)
+LIB      = libblktap.a
+LIB_SO   = libblktap.so.$(MAJOR).$(MINOR)
 
 .PHONY: all
-all: $(LIB)
+all: $(LIB) $(LIB_SO)
 
 .PHONY: install
 install: all
 	$(INSTALL_DIR) $(DESTDIR)$(LIBDIR)
 	$(INSTALL_DIR) $(DESTDIR)$(INCLUDEDIR)
-	$(INSTALL_PROG) $(LIB) $(DESTDIR)$(LIBDIR)
+	$(INSTALL_PROG) $(LIB_SO) $(DESTDIR)$(LIBDIR)
+	$(INSTALL_DATA) $(LIB) $(DESTDIR)$(LIBDIR)
 	ln -sf libblktap.so.$(MAJOR).$(MINOR) $(DESTDIR)$(LIBDIR)/libblktap.so.$(MAJOR)
 	ln -sf libblktap.so.$(MAJOR) $(DESTDIR)$(LIBDIR)/libblktap.so
 	$(INSTALL_DATA) blktaplib.h $(DESTDIR)$(INCLUDEDIR)
 
 .PHONY: clean
 clean:
-	rm -rf *.a *.so* *.o *.opic *.rpm $(LIB) *~ $(DEPS) xen TAGS
+	rm -rf *.a *.so* *.o *.opic *.rpm $(LIB) $(LIB_SO) *~ $(DEPS) xen TAGS
 
 libblktap.so.$(MAJOR).$(MINOR): $(OBJS_PIC) 
 	$(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,$(SONAME) $(SHLIB_LDFLAGS) \

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 13:48:33 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 13:48:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNl1u-0001vJ-JX; Mon, 15 Oct 2012 13:48:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNl1u-0001v9-0y
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 13:48:26 +0000
Received: from [85.158.143.35:23858] by server-1.bemta-4.messagelabs.com id
	54/BB-19551-9241C705; Mon, 15 Oct 2012 13:48:25 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-21.messagelabs.com!1350308676!6458363!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDM0NjQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDM0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28211 invoked from network); 15 Oct 2012 13:44:37 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Oct 2012 13:44:37 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGjy0PFENx
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-081-177.pools.arcor-ip.net [88.65.81.177])
	by smtp.strato.de (jorabe mo24) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id v059e3o9FCuQcm
	for ; Mon, 15 Oct 2012 15:44:36 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id EF1C218647
	for ; Mon, 15 Oct 2012 15:44:34 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 588061a50040df5f1b65c4538697e2161e99e37d
Message-Id: <588061a50040df5f1b65.1350308665@probook.site>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 15 Oct 2012 15:44:25 +0200
From: Olaf Hering 
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 7 of 8] hotplug/Linux: correct sysconfig tag in
	xendomains
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering 
# Date 1350307322 -7200
# Node ID 588061a50040df5f1b65c4538697e2161e99e37d
# Parent  1cded8c6fc32aef391943e7f4c207d196c9a0819
hotplug/Linux: correct sysconfig tag in xendomains

Signed-off-by: Olaf Hering 

diff -r 1cded8c6fc32 -r 588061a50040 tools/hotplug/Linux/init.d/sysconfig.xendomains
--- a/tools/hotplug/Linux/init.d/sysconfig.xendomains
+++ b/tools/hotplug/Linux/init.d/sysconfig.xendomains
@@ -1,4 +1,4 @@
-## Path: System/xen
+## Path: System/Virtualization
 ## Description: xen domain start/stop on boot
 ## Type: string
 ## Default: 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 13:48:33 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 13:48:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNl1u-0001vJ-JX; Mon, 15 Oct 2012 13:48:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNl1u-0001v9-0y
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 13:48:26 +0000
Received: from [85.158.143.35:23858] by server-1.bemta-4.messagelabs.com id
	54/BB-19551-9241C705; Mon, 15 Oct 2012 13:48:25 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-21.messagelabs.com!1350308676!6458363!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDM0NjQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDM0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28211 invoked from network); 15 Oct 2012 13:44:37 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Oct 2012 13:44:37 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGjy0PFENx
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-081-177.pools.arcor-ip.net [88.65.81.177])
	by smtp.strato.de (jorabe mo24) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id v059e3o9FCuQcm
	for ; Mon, 15 Oct 2012 15:44:36 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id EF1C218647
	for ; Mon, 15 Oct 2012 15:44:34 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 588061a50040df5f1b65c4538697e2161e99e37d
Message-Id: <588061a50040df5f1b65.1350308665@probook.site>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 15 Oct 2012 15:44:25 +0200
From: Olaf Hering 
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 7 of 8] hotplug/Linux: correct sysconfig tag in
	xendomains
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering 
# Date 1350307322 -7200
# Node ID 588061a50040df5f1b65c4538697e2161e99e37d
# Parent  1cded8c6fc32aef391943e7f4c207d196c9a0819
hotplug/Linux: correct sysconfig tag in xendomains

Signed-off-by: Olaf Hering 

diff -r 1cded8c6fc32 -r 588061a50040 tools/hotplug/Linux/init.d/sysconfig.xendomains
--- a/tools/hotplug/Linux/init.d/sysconfig.xendomains
+++ b/tools/hotplug/Linux/init.d/sysconfig.xendomains
@@ -1,4 +1,4 @@
-## Path: System/xen
+## Path: System/Virtualization
 ## Description: xen domain start/stop on boot
 ## Type: string
 ## Default: 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 13:51:50 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 13:51:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNl51-0002IR-Sc; Mon, 15 Oct 2012 13:51:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from ) id 1TNl4z-0002Hp-L4
	for xen-devel@lists.xensource.com; Mon, 15 Oct 2012 13:51:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1350309091!10971570!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3876 invoked from network); 15 Oct 2012 13:51:31 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-27.messagelabs.com with SMTP;
	15 Oct 2012 13:51:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 15 Oct 2012 14:52:02 +0100
Message-Id: <507C30FF02000078000A16E4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 15 Oct 2012 14:51:27 +0100
From: "Jan Beulich" 
To: "Wei Wang" 
References: <5063155A.4070307@amd.com>
	<50642A2A020000780009E32D@nat28.tlf.novell.com>
	<507BDED1.6020005@amd.com>
	<507BFD7802000078000A1526@nat28.tlf.novell.com>
	<507C004B.20003@amd.com>
	<507C233702000078000A1670@nat28.tlf.novell.com>
	<507C129A.2010203@amd.com>
In-Reply-To: <507C129A.2010203@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser ,
	"xen-devel@lists.xensource.com" ,
	Ian Jackson ,
	IanCampbell 
Subject: Re: [Xen-devel] [PATCH 2 of 6 V6] amd iommu: call
 guest_iommu_set_base from hvmloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.10.12 at 15:41, Wei Wang  wrote:
> My idea is to make the interface looks like that
> guest_iommu_set_base(d, iommu_base, iommu_seg)

That part is obvious; the more interesting part is how you plan
on getting this fix the HVM parameter model.

> This will allow hvmloader to choose a non-zero iommu segment.
> if iommu_seg > 0, then I will add a new iommu to guest iommu list and 
> update iommu_segment field accordingly. But I seem to see no reason to 
> add multiple guest iommus to pci segment 0.

I don't see a need for this at present too, and as I said before
there's no need to implement support for multiple IOMMUs. The
interface definition, however, has to be flexible enough so we
don't need to introduce another interface in a few years time
just because right now we don't expect multiple IOMMUs to be
needed for guests (after all, there must be reasons why real
hardware frequently comes with more than one IOMMU despite
supporting only a single PCI segment - just consider the guest
visible NUMA case, where you would quite likely want an IOMMU
per guest visible node).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 13:51:50 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 13:51:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNl51-0002IR-Sc; Mon, 15 Oct 2012 13:51:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from ) id 1TNl4z-0002Hp-L4
	for xen-devel@lists.xensource.com; Mon, 15 Oct 2012 13:51:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1350309091!10971570!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3876 invoked from network); 15 Oct 2012 13:51:31 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-27.messagelabs.com with SMTP;
	15 Oct 2012 13:51:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 15 Oct 2012 14:52:02 +0100
Message-Id: <507C30FF02000078000A16E4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 15 Oct 2012 14:51:27 +0100
From: "Jan Beulich" 
To: "Wei Wang" 
References: <5063155A.4070307@amd.com>
	<50642A2A020000780009E32D@nat28.tlf.novell.com>
	<507BDED1.6020005@amd.com>
	<507BFD7802000078000A1526@nat28.tlf.novell.com>
	<507C004B.20003@amd.com>
	<507C233702000078000A1670@nat28.tlf.novell.com>
	<507C129A.2010203@amd.com>
In-Reply-To: <507C129A.2010203@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser ,
	"xen-devel@lists.xensource.com" ,
	Ian Jackson ,
	IanCampbell 
Subject: Re: [Xen-devel] [PATCH 2 of 6 V6] amd iommu: call
 guest_iommu_set_base from hvmloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.10.12 at 15:41, Wei Wang  wrote:
> My idea is to make the interface looks like that
> guest_iommu_set_base(d, iommu_base, iommu_seg)

That part is obvious; the more interesting part is how you plan
on getting this fix the HVM parameter model.

> This will allow hvmloader to choose a non-zero iommu segment.
> if iommu_seg > 0, then I will add a new iommu to guest iommu list and 
> update iommu_segment field accordingly. But I seem to see no reason to 
> add multiple guest iommus to pci segment 0.

I don't see a need for this at present too, and as I said before
there's no need to implement support for multiple IOMMUs. The
interface definition, however, has to be flexible enough so we
don't need to introduce another interface in a few years time
just because right now we don't expect multiple IOMMUs to be
needed for guests (after all, there must be reasons why real
hardware frequently comes with more than one IOMMU despite
supporting only a single PCI segment - just consider the guest
visible NUMA case, where you would quite likely want an IOMMU
per guest visible node).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 13:52:23 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 13:52:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNl5b-0002OK-AR; Mon, 15 Oct 2012 13:52:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNl5Z-0002Nx-UF
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 13:52:14 +0000
Received: from [85.158.139.211:3497] by server-15.bemta-5.messagelabs.com id
	99/C6-28599-D051C705; Mon, 15 Oct 2012 13:52:13 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1350309131!22358254!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODI0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17192 invoked from network); 15 Oct 2012 13:52:12 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 13:52:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="211287096"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 13:52:05 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 09:52:05 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TNl5R-00062J-8i;
	Mon, 15 Oct 2012 14:52:05 +0100
Message-ID: <507C13DF.4090707@eu.citrix.com>
Date: Mon, 15 Oct 2012 14:47:11 +0100
From: George Dunlap 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: Keir Fraser 
References: 
In-Reply-To: 
Cc: Olaf Hering , Ian Campbell ,
	Andres Lagar-Cavilla ,
	"Tim \(Xen.org\)" ,
	"xen-devel@lists.xen.org" ,
	Jan Beulich 
Subject: Re: [Xen-devel] Wait queue support for 4.3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/10/12 20:34, Keir Fraser wrote:
> On 12/10/2012 19:53, "Andres Lagar-Cavilla"  wrote:
>
>>> I don't see any dependency. And Tim has already proposed patches for
>>> use-case 2, in fact, as you noted. So, shouldn't they simply be polished up
>>> and applied as soon as possible? Basically, for mm type things, Tim is your
>>> man, either as author or reviewer.
>> Ok. Wanted to ascertain where we stand on things.
>>
>> Tim's patches crash guests because there are all sorts of spinlocks being
>> held. That's the gist of the mm work that needs to be done. And a separate
>> discussion.
> Yes, that's a *mm* can of worms. :) Tim is the first port of call, and
> working out who actually does the work, and what work that is, will be the
> the ensuing discussion.
So does it make sense to track this on the 4.3 feature list (obviously 
with "owner: ?" until that's sorted out)?  Andres, would the summary 
below be accurate enough?

* Waitqueues for hypervisor accesses to shared frames which fail with 
-ENOMEM
   owner: ?
   status: First draft posted back in February, much more work to do.

  -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 13:52:23 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 13:52:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNl5b-0002OK-AR; Mon, 15 Oct 2012 13:52:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNl5Z-0002Nx-UF
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 13:52:14 +0000
Received: from [85.158.139.211:3497] by server-15.bemta-5.messagelabs.com id
	99/C6-28599-D051C705; Mon, 15 Oct 2012 13:52:13 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1350309131!22358254!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODI0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17192 invoked from network); 15 Oct 2012 13:52:12 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 13:52:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,587,1344211200"; d="scan'208";a="211287096"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 13:52:05 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 09:52:05 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TNl5R-00062J-8i;
	Mon, 15 Oct 2012 14:52:05 +0100
Message-ID: <507C13DF.4090707@eu.citrix.com>
Date: Mon, 15 Oct 2012 14:47:11 +0100
From: George Dunlap 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: Keir Fraser 
References: 
In-Reply-To: 
Cc: Olaf Hering , Ian Campbell ,
	Andres Lagar-Cavilla ,
	"Tim \(Xen.org\)" ,
	"xen-devel@lists.xen.org" ,
	Jan Beulich 
Subject: Re: [Xen-devel] Wait queue support for 4.3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 12/10/12 20:34, Keir Fraser wrote:
> On 12/10/2012 19:53, "Andres Lagar-Cavilla"  wrote:
>
>>> I don't see any dependency. And Tim has already proposed patches for
>>> use-case 2, in fact, as you noted. So, shouldn't they simply be polished up
>>> and applied as soon as possible? Basically, for mm type things, Tim is your
>>> man, either as author or reviewer.
>> Ok. Wanted to ascertain where we stand on things.
>>
>> Tim's patches crash guests because there are all sorts of spinlocks being
>> held. That's the gist of the mm work that needs to be done. And a separate
>> discussion.
> Yes, that's a *mm* can of worms. :) Tim is the first port of call, and
> working out who actually does the work, and what work that is, will be the
> the ensuing discussion.
So does it make sense to track this on the 4.3 feature list (obviously 
with "owner: ?" until that's sorted out)?  Andres, would the summary 
below be accurate enough?

* Waitqueues for hypervisor accesses to shared frames which fail with 
-ENOMEM
   owner: ?
   status: First draft posted back in February, much more work to do.

  -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 14:03:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 14:03:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNlFp-0002s0-FK; Mon, 15 Oct 2012 14:02:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNlFo-0002rv-5d
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 14:02:48 +0000
Received: from [85.158.143.35:33370] by server-2.bemta-4.messagelabs.com id
	14/D6-25171-7871C705; Mon, 15 Oct 2012 14:02:47 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-21.messagelabs.com!1350309766!14419850!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3764 invoked from network); 15 Oct 2012 14:02:46 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-13.tower-21.messagelabs.com with SMTP;
	15 Oct 2012 14:02:46 -0000
X-TM-IMSS-Message-ID: 
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1;
	TLSv1/SSLv3 DHE-RSA-AES256-SHA (256/256)) id e366ad5c0003d8b8 ;
	Mon, 15 Oct 2012 10:05:39 -0400
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q9FE2j1D027126; 
	Mon, 15 Oct 2012 10:02:45 -0400
From: Daniel De Graaf 
To: xen-devel@lists.xen.org, Keir Fraser ,
	Ian.Campbell@citrix.com
Date: Mon, 15 Oct 2012 10:02:39 -0400
Message-Id: <1350309759-4635-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.7
Cc: Daniel De Graaf 
Subject: [Xen-devel] [PATCH] xen: Add versions of rcu_lock_*_domain without
	IS_PRIV
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

While this patch is a part of my XSM IS_PRIV series, I am reposting it
alone because the XSM build of xen-unstable is currently broken. I can
also repost the remaining patches series if that would be helpful.

--------------------------------->8----------------------------------

These functions will be used to avoid duplication of IS_PRIV calls
that will be introduced in XSM hooks. This also fixes a build error
with XSM enabled introduced by 25925:d1c3375c3f11 which depends on
this patch.

Signed-off-by: Daniel De Graaf 
---
 xen/common/domain.c     | 21 +++++++++++++++++++++
 xen/include/xen/sched.h | 11 +++++++++++
 2 files changed, 32 insertions(+)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index a1aa05e..52489b3 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -420,6 +420,13 @@ struct domain *rcu_lock_domain_by_id(domid_t dom)
     return d;
 }
 
+struct domain *rcu_lock_domain_by_any_id(domid_t dom)
+{
+    if ( dom == DOMID_SELF )
+        return rcu_lock_current_domain();
+    return rcu_lock_domain_by_id(dom);
+}
+
 int rcu_lock_target_domain_by_id(domid_t dom, struct domain **d)
 {
     if ( dom == DOMID_SELF )
@@ -454,6 +461,20 @@ int rcu_lock_remote_target_domain_by_id(domid_t dom, struct domain **d)
     return 0;
 }
 
+int rcu_lock_remote_domain_by_id(domid_t dom, struct domain **d)
+{
+    if ( (*d = rcu_lock_domain_by_id(dom)) == NULL )
+        return -ESRCH;
+
+    if ( *d == current->domain )
+    {
+        rcu_unlock_domain(*d);
+        return -EPERM;
+    }
+
+    return 0;
+}
+
 int domain_kill(struct domain *d)
 {
     int rc = 0;
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 53804c8..b0def4a 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -447,6 +447,11 @@ struct domain *domain_create(
 struct domain *rcu_lock_domain_by_id(domid_t dom);
 
 /*
+ * As above function, but resolves DOMID_SELF to current domain
+ */
+struct domain *rcu_lock_domain_by_any_id(domid_t dom);
+
+/*
  * As above function, but accounts for current domain context:
  *  - Translates target DOMID_SELF into caller's domain id; and
  *  - Checks that caller has permission to act on the target domain.
@@ -460,6 +465,12 @@ int rcu_lock_target_domain_by_id(domid_t dom, struct domain **d);
  */
 int rcu_lock_remote_target_domain_by_id(domid_t dom, struct domain **d);
 
+/*
+ * As rcu_lock_domain_by_id(), but will fail EPERM or ESRCH rather than resolve
+ * to local domain.
+ */
+int rcu_lock_remote_domain_by_id(domid_t dom, struct domain **d);
+
 /* Finish a RCU critical region started by rcu_lock_domain_by_id(). */
 static inline void rcu_unlock_domain(struct domain *d)
 {
-- 
1.7.11.7


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 14:03:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 14:03:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNlFp-0002s0-FK; Mon, 15 Oct 2012 14:02:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNlFo-0002rv-5d
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 14:02:48 +0000
Received: from [85.158.143.35:33370] by server-2.bemta-4.messagelabs.com id
	14/D6-25171-7871C705; Mon, 15 Oct 2012 14:02:47 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-21.messagelabs.com!1350309766!14419850!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3764 invoked from network); 15 Oct 2012 14:02:46 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-13.tower-21.messagelabs.com with SMTP;
	15 Oct 2012 14:02:46 -0000
X-TM-IMSS-Message-ID: 
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1;
	TLSv1/SSLv3 DHE-RSA-AES256-SHA (256/256)) id e366ad5c0003d8b8 ;
	Mon, 15 Oct 2012 10:05:39 -0400
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q9FE2j1D027126; 
	Mon, 15 Oct 2012 10:02:45 -0400
From: Daniel De Graaf 
To: xen-devel@lists.xen.org, Keir Fraser ,
	Ian.Campbell@citrix.com
Date: Mon, 15 Oct 2012 10:02:39 -0400
Message-Id: <1350309759-4635-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.7
Cc: Daniel De Graaf 
Subject: [Xen-devel] [PATCH] xen: Add versions of rcu_lock_*_domain without
	IS_PRIV
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

While this patch is a part of my XSM IS_PRIV series, I am reposting it
alone because the XSM build of xen-unstable is currently broken. I can
also repost the remaining patches series if that would be helpful.

--------------------------------->8----------------------------------

These functions will be used to avoid duplication of IS_PRIV calls
that will be introduced in XSM hooks. This also fixes a build error
with XSM enabled introduced by 25925:d1c3375c3f11 which depends on
this patch.

Signed-off-by: Daniel De Graaf 
---
 xen/common/domain.c     | 21 +++++++++++++++++++++
 xen/include/xen/sched.h | 11 +++++++++++
 2 files changed, 32 insertions(+)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index a1aa05e..52489b3 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -420,6 +420,13 @@ struct domain *rcu_lock_domain_by_id(domid_t dom)
     return d;
 }
 
+struct domain *rcu_lock_domain_by_any_id(domid_t dom)
+{
+    if ( dom == DOMID_SELF )
+        return rcu_lock_current_domain();
+    return rcu_lock_domain_by_id(dom);
+}
+
 int rcu_lock_target_domain_by_id(domid_t dom, struct domain **d)
 {
     if ( dom == DOMID_SELF )
@@ -454,6 +461,20 @@ int rcu_lock_remote_target_domain_by_id(domid_t dom, struct domain **d)
     return 0;
 }
 
+int rcu_lock_remote_domain_by_id(domid_t dom, struct domain **d)
+{
+    if ( (*d = rcu_lock_domain_by_id(dom)) == NULL )
+        return -ESRCH;
+
+    if ( *d == current->domain )
+    {
+        rcu_unlock_domain(*d);
+        return -EPERM;
+    }
+
+    return 0;
+}
+
 int domain_kill(struct domain *d)
 {
     int rc = 0;
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 53804c8..b0def4a 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -447,6 +447,11 @@ struct domain *domain_create(
 struct domain *rcu_lock_domain_by_id(domid_t dom);
 
 /*
+ * As above function, but resolves DOMID_SELF to current domain
+ */
+struct domain *rcu_lock_domain_by_any_id(domid_t dom);
+
+/*
  * As above function, but accounts for current domain context:
  *  - Translates target DOMID_SELF into caller's domain id; and
  *  - Checks that caller has permission to act on the target domain.
@@ -460,6 +465,12 @@ int rcu_lock_target_domain_by_id(domid_t dom, struct domain **d);
  */
 int rcu_lock_remote_target_domain_by_id(domid_t dom, struct domain **d);
 
+/*
+ * As rcu_lock_domain_by_id(), but will fail EPERM or ESRCH rather than resolve
+ * to local domain.
+ */
+int rcu_lock_remote_domain_by_id(domid_t dom, struct domain **d);
+
 /* Finish a RCU critical region started by rcu_lock_domain_by_id(). */
 static inline void rcu_unlock_domain(struct domain *d)
 {
-- 
1.7.11.7


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 14:13:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 14:13:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNlPi-0003Bj-N1; Mon, 15 Oct 2012 14:13:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNlPg-0003Bb-Ny
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 14:13:00 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-6.tower-27.messagelabs.com!1350310321!3575706!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18589 invoked from network); 15 Oct 2012 14:12:03 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 14:12:03 -0000
Received: by mail-ie0-f173.google.com with SMTP id 17so9916672iea.32
	for ; Mon, 15 Oct 2012 07:12:01 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=content-type:mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=ITARVOHxd28SP3VldfJzaKbdtjOz/gpvcrHgQo2X2iM=;
	b=WZ+sr03JMSfzQZEnIc7yutVM6NfTbcWsVdoCM3JWsHfo8uBWVlFENS826/16bQxKSR
	R5Ul0ZBqj6ZXD4ge9CDs5A9VFsJh8QuJwwUwOIr0Zxn0vhrsNrmhtgVXoQB/husMXmTG
	6s5Q/r0pRF5TtgmTqPEJruCQeje8NGcPHWzzk9XTua2xtty13Kyo8TVEbYZ+22EVw05Y
	dQV2dSy3+/pUziTdZyVWmPpQKhWnjQc2SFniztnm2UualBjVVM+Y9HVsB4KorbC4YvYy
	+4cF6y3zSvmSFaeIG+kigty2ps53WKm3zK66H5W1iAwRF/U1wFYqY+IuBDTaxY7wBqGs
	ZPxw==
Received: by 10.50.207.36 with SMTP id lt4mr8698033igc.66.1350310321607;
	Mon, 15 Oct 2012 07:12:01 -0700 (PDT)
Received: from [192.168.4.87] ([206.223.182.18])
	by mx.google.com with ESMTPS id u4sm6479846igw.6.2012.10.15.07.11.57
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 15 Oct 2012 07:11:59 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Andres Lagar-Cavilla 
In-Reply-To: <507C13DF.4090707@eu.citrix.com>
Date: Mon, 15 Oct 2012 10:12:00 -0400
Message-Id: 
References:  <507C13DF.4090707@eu.citrix.com>
To: George Dunlap 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQnc5MX4WcmBO4E9SdIqwZeEJgcMannl8mjqe+iAKdBfd8Zir0zHsxyUPAV4n68+ORNdDUKd
Cc: Olaf Hering , Keir Fraser ,
	Ian Campbell ,
	Andres Lagar-Cavilla ,
	"Tim \(Xen.org\)" ,
	"xen-devel@lists.xen.org" ,
	Jan Beulich 
Subject: Re: [Xen-devel] Wait queue support for 4.3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Oct 15, 2012, at 9:47 AM, George Dunlap  wrote:

> On 12/10/12 20:34, Keir Fraser wrote:
>> On 12/10/2012 19:53, "Andres Lagar-Cavilla"  wrote:
>> 
>>>> I don't see any dependency. And Tim has already proposed patches for
>>>> use-case 2, in fact, as you noted. So, shouldn't they simply be polished up
>>>> and applied as soon as possible? Basically, for mm type things, Tim is your
>>>> man, either as author or reviewer.
>>> Ok. Wanted to ascertain where we stand on things.
>>> 
>>> Tim's patches crash guests because there are all sorts of spinlocks being
>>> held. That's the gist of the mm work that needs to be done. And a separate
>>> discussion.
>> Yes, that's a *mm* can of worms. :) Tim is the first port of call, and
>> working out who actually does the work, and what work that is, will be the
>> the ensuing discussion.
> So does it make sense to track this on the 4.3 feature list (obviously with "owner: ?" until that's sorted out)?  Andres, would the summary below be accurate enough?
> 
> * Waitqueues for hypervisor accesses to shared frames which fail with -ENOMEM
>  owner: ?
>  status: First draft posted back in February, much more work to do.

I'd be more generic and say "wait queues for mm" (paging also needs this).

I don't know about "wait queues for mmio emulation" as a separate item.

Andres
> 
> -George
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 14:13:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 14:13:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNlPi-0003Bj-N1; Mon, 15 Oct 2012 14:13:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNlPg-0003Bb-Ny
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 14:13:00 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-6.tower-27.messagelabs.com!1350310321!3575706!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18589 invoked from network); 15 Oct 2012 14:12:03 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 14:12:03 -0000
Received: by mail-ie0-f173.google.com with SMTP id 17so9916672iea.32
	for ; Mon, 15 Oct 2012 07:12:01 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=content-type:mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=ITARVOHxd28SP3VldfJzaKbdtjOz/gpvcrHgQo2X2iM=;
	b=WZ+sr03JMSfzQZEnIc7yutVM6NfTbcWsVdoCM3JWsHfo8uBWVlFENS826/16bQxKSR
	R5Ul0ZBqj6ZXD4ge9CDs5A9VFsJh8QuJwwUwOIr0Zxn0vhrsNrmhtgVXoQB/husMXmTG
	6s5Q/r0pRF5TtgmTqPEJruCQeje8NGcPHWzzk9XTua2xtty13Kyo8TVEbYZ+22EVw05Y
	dQV2dSy3+/pUziTdZyVWmPpQKhWnjQc2SFniztnm2UualBjVVM+Y9HVsB4KorbC4YvYy
	+4cF6y3zSvmSFaeIG+kigty2ps53WKm3zK66H5W1iAwRF/U1wFYqY+IuBDTaxY7wBqGs
	ZPxw==
Received: by 10.50.207.36 with SMTP id lt4mr8698033igc.66.1350310321607;
	Mon, 15 Oct 2012 07:12:01 -0700 (PDT)
Received: from [192.168.4.87] ([206.223.182.18])
	by mx.google.com with ESMTPS id u4sm6479846igw.6.2012.10.15.07.11.57
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 15 Oct 2012 07:11:59 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Andres Lagar-Cavilla 
In-Reply-To: <507C13DF.4090707@eu.citrix.com>
Date: Mon, 15 Oct 2012 10:12:00 -0400
Message-Id: 
References:  <507C13DF.4090707@eu.citrix.com>
To: George Dunlap 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQnc5MX4WcmBO4E9SdIqwZeEJgcMannl8mjqe+iAKdBfd8Zir0zHsxyUPAV4n68+ORNdDUKd
Cc: Olaf Hering , Keir Fraser ,
	Ian Campbell ,
	Andres Lagar-Cavilla ,
	"Tim \(Xen.org\)" ,
	"xen-devel@lists.xen.org" ,
	Jan Beulich 
Subject: Re: [Xen-devel] Wait queue support for 4.3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Oct 15, 2012, at 9:47 AM, George Dunlap  wrote:

> On 12/10/12 20:34, Keir Fraser wrote:
>> On 12/10/2012 19:53, "Andres Lagar-Cavilla"  wrote:
>> 
>>>> I don't see any dependency. And Tim has already proposed patches for
>>>> use-case 2, in fact, as you noted. So, shouldn't they simply be polished up
>>>> and applied as soon as possible? Basically, for mm type things, Tim is your
>>>> man, either as author or reviewer.
>>> Ok. Wanted to ascertain where we stand on things.
>>> 
>>> Tim's patches crash guests because there are all sorts of spinlocks being
>>> held. That's the gist of the mm work that needs to be done. And a separate
>>> discussion.
>> Yes, that's a *mm* can of worms. :) Tim is the first port of call, and
>> working out who actually does the work, and what work that is, will be the
>> the ensuing discussion.
> So does it make sense to track this on the 4.3 feature list (obviously with "owner: ?" until that's sorted out)?  Andres, would the summary below be accurate enough?
> 
> * Waitqueues for hypervisor accesses to shared frames which fail with -ENOMEM
>  owner: ?
>  status: First draft posted back in February, much more work to do.

I'd be more generic and say "wait queues for mm" (paging also needs this).

I don't know about "wait queues for mmio emulation" as a separate item.

Andres
> 
> -George
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 14:31:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 14:31:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNlh0-0003aK-4K; Mon, 15 Oct 2012 14:30:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNlbo-0003O8-Mu; Mon, 15 Oct 2012 14:25:32 +0000
Received: from [85.158.137.99:22259] by server-16.bemta-3.messagelabs.com id
	00/38-16565-ADC1C705; Mon, 15 Oct 2012 14:25:30 +0000
X-Env-Sender: mrsanna1@gmail.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1350311128!19283187!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13939 invoked from network); 15 Oct 2012 14:25:29 -0000
Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com)
	(209.85.212.43)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 14:25:29 -0000
Received: by mail-vb0-f43.google.com with SMTP id fq11so6630511vbb.30
	for ; Mon, 15 Oct 2012 07:25:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=AsO55k8jhsTldI7OniaizfnzuehPDhEuO3fN8QP8f6c=;
	b=wlxIWK0fRJRRlg7Jvc0LinSDWCKjVoB4bSuuwlMKtoPB+snJNZeXq4833JJLI8ubC5
	+wSexPqokbyZfU8osJvY9QoygNUNTkKd4hBCkrlz2WVlkyGbRWIuVpZU/KDFjFcL1aLr
	xcq/7fU9Bm7RQTDVFq7vVoYJfvvFUOY5ma+f5sCPefof6U8XqiclzaoxE8k5BALSbMt4
	nwFbCtsVRnx+jsuy39y5ZSddLUog5hH2FKXnug+ecd2mhu3C6lXBbvUM4iBEUlaqCZDu
	ZYR0OqjIoXDNv649ED/x669H+hviHiFtcAwlTOcm4aOs9BTrr3Rq6pbMNjRX74VPopLB
	ZztA==
MIME-Version: 1.0
Received: by 10.58.239.162 with SMTP id vt2mr3212342vec.1.1350311127542; Mon,
	15 Oct 2012 07:25:27 -0700 (PDT)
Received: by 10.58.207.75 with HTTP; Mon, 15 Oct 2012 07:25:27 -0700 (PDT)
In-Reply-To: <507C226A02000078000A1657@nat28.tlf.novell.com>
References: 
	
	
	
	<65395f62-74e5-4910-b701-8df629c2ce3b@default>
	
	
	
	
	
	<20120930151314.GU8912@reaktio.net>
	
	
	
	<507C024602000078000A155C@nat28.tlf.novell.com>
	
	<507C226A02000078000A1657@nat28.tlf.novell.com>
Date: Mon, 15 Oct 2012 16:25:27 +0200
Message-ID: 
From: Mauro 
To: Jan Beulich 
X-Mailman-Approved-At: Mon, 15 Oct 2012 14:30:53 +0000
Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com,
	Keir Fraser , Dan Magenheimer ,
	Olivier Hanesse ,
	Keir Fraser ,
	Xen Users ,
	Mark Adams 
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 15 October 2012 14:49, Jan Beulich  wrote:
>>>> On 15.10.12 at 13:24, Mauro  wrote:
>> I have the problem on this hardware type:
>>
>> Hp Proliant DL580 G5 with four Intel(R) Xeon(R) CPU E7330  @ 2.40GHz.
>> It seem that
>> GRUB_CMDLINE_XEN="clocksource=pit cpuidle=0"
>> put in in /etc/default/grup (I use linux debian)
>> solves the problem for me.
>
> Did you check whether either or both options on their own also
> make the problem go away?

Only clocksource=pit does not solve the problem, I've not tried with
only cpuidle=0, I will try soon.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 14:31:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 14:31:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNlh0-0003aK-4K; Mon, 15 Oct 2012 14:30:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNlbo-0003O8-Mu; Mon, 15 Oct 2012 14:25:32 +0000
Received: from [85.158.137.99:22259] by server-16.bemta-3.messagelabs.com id
	00/38-16565-ADC1C705; Mon, 15 Oct 2012 14:25:30 +0000
X-Env-Sender: mrsanna1@gmail.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1350311128!19283187!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13939 invoked from network); 15 Oct 2012 14:25:29 -0000
Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com)
	(209.85.212.43)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 14:25:29 -0000
Received: by mail-vb0-f43.google.com with SMTP id fq11so6630511vbb.30
	for ; Mon, 15 Oct 2012 07:25:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=AsO55k8jhsTldI7OniaizfnzuehPDhEuO3fN8QP8f6c=;
	b=wlxIWK0fRJRRlg7Jvc0LinSDWCKjVoB4bSuuwlMKtoPB+snJNZeXq4833JJLI8ubC5
	+wSexPqokbyZfU8osJvY9QoygNUNTkKd4hBCkrlz2WVlkyGbRWIuVpZU/KDFjFcL1aLr
	xcq/7fU9Bm7RQTDVFq7vVoYJfvvFUOY5ma+f5sCPefof6U8XqiclzaoxE8k5BALSbMt4
	nwFbCtsVRnx+jsuy39y5ZSddLUog5hH2FKXnug+ecd2mhu3C6lXBbvUM4iBEUlaqCZDu
	ZYR0OqjIoXDNv649ED/x669H+hviHiFtcAwlTOcm4aOs9BTrr3Rq6pbMNjRX74VPopLB
	ZztA==
MIME-Version: 1.0
Received: by 10.58.239.162 with SMTP id vt2mr3212342vec.1.1350311127542; Mon,
	15 Oct 2012 07:25:27 -0700 (PDT)
Received: by 10.58.207.75 with HTTP; Mon, 15 Oct 2012 07:25:27 -0700 (PDT)
In-Reply-To: <507C226A02000078000A1657@nat28.tlf.novell.com>
References: 
	
	
	
	<65395f62-74e5-4910-b701-8df629c2ce3b@default>
	
	
	
	
	
	<20120930151314.GU8912@reaktio.net>
	
	
	
	<507C024602000078000A155C@nat28.tlf.novell.com>
	
	<507C226A02000078000A1657@nat28.tlf.novell.com>
Date: Mon, 15 Oct 2012 16:25:27 +0200
Message-ID: 
From: Mauro 
To: Jan Beulich 
X-Mailman-Approved-At: Mon, 15 Oct 2012 14:30:53 +0000
Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com,
	Keir Fraser , Dan Magenheimer ,
	Olivier Hanesse ,
	Keir Fraser ,
	Xen Users ,
	Mark Adams 
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 15 October 2012 14:49, Jan Beulich  wrote:
>>>> On 15.10.12 at 13:24, Mauro  wrote:
>> I have the problem on this hardware type:
>>
>> Hp Proliant DL580 G5 with four Intel(R) Xeon(R) CPU E7330  @ 2.40GHz.
>> It seem that
>> GRUB_CMDLINE_XEN="clocksource=pit cpuidle=0"
>> put in in /etc/default/grup (I use linux debian)
>> solves the problem for me.
>
> Did you check whether either or both options on their own also
> make the problem go away?

Only clocksource=pit does not solve the problem, I've not tried with
only cpuidle=0, I will try soon.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 14:45:45 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 14:45:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNlv4-0003zt-OQ; Mon, 15 Oct 2012 14:45:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNlv2-0003zo-LI
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 14:45:24 +0000
Received: from [85.158.143.99:58964] by server-2.bemta-4.messagelabs.com id
	2A/57-25171-3812C705; Mon, 15 Oct 2012 14:45:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1350312321!24404655!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19011 invoked from network); 15 Oct 2012 14:45:22 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-216.messagelabs.com with SMTP;
	15 Oct 2012 14:45:22 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 15 Oct 2012 15:47:39 +0100
Message-Id: <507C3D9C02000078000A1735@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 15 Oct 2012 15:45:16 +0100
From: "Jan Beulich" 
To: 
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part0938286C.1__="
Cc: xen-devel 
Subject: [Xen-devel] Ping: [PATCH] VT-d: drop bogus checks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part0938286C.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

There were a number of cases where an "iommu" retrieved got passed to
another function before being NULL-checked. While this by itself was
not a problem as the called function did the checks, it is confusing to
the reader and redundant in several cases (particularly with NULL-
checking the return value of iommu_ir_ctrl()). Drop the redundant
checks (also ones where the sole caller of a function did the checking
already), and at once make the three similar functions proper inline
instead of extern ones (they were prototyped in the wrong header file
anyway, so would have needed touching sooner or later).

Signed-off-by: Jan Beulich 

--- a/xen/drivers/passthrough/vtd/intremap.c
+++ b/xen/drivers/passthrough/vtd/intremap.c
@@ -217,13 +217,6 @@ static int remap_entry_to_ioapic_rte(
     unsigned long flags;
     struct ir_ctrl *ir_ctrl =3D iommu_ir_ctrl(iommu);
=20
-    if ( ir_ctrl =3D=3D NULL )
-    {
-        dprintk(XENLOG_ERR VTDPREFIX,
-                "remap_entry_to_ioapic_rte: ir_ctl is not ready\n");
-        return -EFAULT;
-    }
-
     if ( index < 0 || index > IREMAP_ENTRY_NR - 1 )
     {
         dprintk(XENLOG_ERR VTDPREFIX,
@@ -358,8 +351,7 @@ unsigned int io_apic_read_remap_rte(
     struct iommu *iommu =3D ioapic_to_iommu(IO_APIC_ID(apic));
     struct ir_ctrl *ir_ctrl =3D iommu_ir_ctrl(iommu);
=20
-    if ( !iommu || !ir_ctrl || ir_ctrl->iremap_maddr =3D=3D 0 ||
-        (ir_ctrl->iremap_num =3D=3D 0) ||
+    if ( !ir_ctrl || !ir_ctrl->iremap_maddr || !ir_ctrl->iremap_num ||
         ( (index =3D apic_pin_2_ir_idx[apic][ioapic_pin]) < 0 ) )
         return __io_apic_read(apic, reg);
=20
@@ -385,7 +377,7 @@ void io_apic_write_remap_rte(
     struct ir_ctrl *ir_ctrl =3D iommu_ir_ctrl(iommu);
     int saved_mask;
=20
-    if ( !iommu || !ir_ctrl || ir_ctrl->iremap_maddr =3D=3D 0 )
+    if ( !ir_ctrl || !ir_ctrl->iremap_maddr )
     {
         __io_apic_write(apic, reg, value);
         return;
@@ -475,13 +467,6 @@ static int remap_entry_to_msi_msg(
     unsigned long flags;
     struct ir_ctrl *ir_ctrl =3D iommu_ir_ctrl(iommu);
=20
-    if ( ir_ctrl =3D=3D NULL )
-    {
-        dprintk(XENLOG_ERR VTDPREFIX,
-                "remap_entry_to_msi_msg: ir_ctl =3D=3D NULL");
-        return -EFAULT;
-    }
-
     remap_rte =3D (struct msi_msg_remap_entry *) msg;
     index =3D (remap_rte->address_lo.index_15 << 15) |
              remap_rte->address_lo.index_0_14;
@@ -644,7 +629,7 @@ void msi_msg_read_remap_rte(
     iommu =3D drhd->iommu;
=20
     ir_ctrl =3D iommu_ir_ctrl(iommu);
-    if ( !iommu || !ir_ctrl || ir_ctrl->iremap_maddr =3D=3D 0 )
+    if ( !ir_ctrl || !ir_ctrl->iremap_maddr )
         return;
=20
     remap_entry_to_msi_msg(iommu, msg);
@@ -663,7 +648,7 @@ void msi_msg_write_remap_rte(
     iommu =3D drhd->iommu;
=20
     ir_ctrl =3D iommu_ir_ctrl(iommu);
-    if ( !iommu || !ir_ctrl || ir_ctrl->iremap_maddr =3D=3D 0 )
+    if ( !ir_ctrl || !ir_ctrl->iremap_maddr )
         return;
=20
     msi_msg_to_remap_entry(iommu, pdev, msi_desc, msg);
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -153,21 +153,6 @@ static void __init free_intel_iommu(stru
     xfree(intel);
 }
=20
-struct qi_ctrl *iommu_qi_ctrl(struct iommu *iommu)
-{
-    return iommu ? &iommu->intel->qi_ctrl : NULL;
-}
-
-struct ir_ctrl *iommu_ir_ctrl(struct iommu *iommu)
-{
-    return iommu ? &iommu->intel->ir_ctrl : NULL;
-}
-
-struct iommu_flush *iommu_get_flush(struct iommu *iommu)
-{
-    return iommu ? &iommu->intel->flush : NULL;
-}
-
 static int iommus_incoherent;
 static void __iommu_flush_cache(void *addr, unsigned int size)
 {
--- a/xen/drivers/passthrough/vtd/iommu.h
+++ b/xen/drivers/passthrough/vtd/iommu.h
@@ -20,7 +20,7 @@
 #ifndef _INTEL_IOMMU_H_
 #define _INTEL_IOMMU_H_
=20
-#include 
+#include 
=20
 /*
  * Intel IOMMU register specification per version 1.0 public spec.
@@ -510,6 +510,21 @@ struct intel_iommu {
     struct acpi_drhd_unit *drhd;
 };
=20
+static inline struct qi_ctrl *iommu_qi_ctrl(struct iommu *iommu)
+{
+    return iommu ? &iommu->intel->qi_ctrl : NULL;
+}
+
+static inline struct ir_ctrl *iommu_ir_ctrl(struct iommu *iommu)
+{
+    return iommu ? &iommu->intel->ir_ctrl : NULL;
+}
+
+static inline struct iommu_flush *iommu_get_flush(struct iommu *iommu)
+{
+    return iommu ? &iommu->intel->flush : NULL;
+}
+
 #define INTEL_IOMMU_DEBUG(fmt, args...) \
     do  \
     {   \
--- a/xen/drivers/passthrough/vtd/utils.c
+++ b/xen/drivers/passthrough/vtd/utils.c
@@ -267,8 +267,7 @@ static void dump_iommu_info(unsigned cha
         {
             iommu =3D ioapic_to_iommu(mp_ioapics[apic].mpc_apicid);
             ir_ctrl =3D iommu_ir_ctrl(iommu);
-            if ( !iommu || !ir_ctrl || ir_ctrl->iremap_maddr =3D=3D 0 ||
-                ir_ctrl->iremap_num =3D=3D 0 )
+            if ( !ir_ctrl || !ir_ctrl->iremap_maddr || !ir_ctrl->iremap_nu=
m )
                 continue;
=20
             printk( "\nRedirection table of IOAPIC %x:\n", apic);
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -106,9 +106,6 @@ struct msi_desc;
 struct msi_msg;
 void msi_msg_read_remap_rte(struct msi_desc *msi_desc, struct msi_msg =
*msg);
 void msi_msg_write_remap_rte(struct msi_desc *msi_desc, struct msi_msg =
*msg);
-struct qi_ctrl *iommu_qi_ctrl(struct iommu *iommu);
-struct ir_ctrl *iommu_ir_ctrl(struct iommu *iommu);
-struct iommu_flush *iommu_get_flush(struct iommu *iommu);
 void hvm_dpci_isairq_eoi(struct domain *d, unsigned int isairq);
 struct hvm_irq_dpci *domain_get_irq_dpci(const struct domain *);
 void free_hvm_irq_dpci(struct hvm_irq_dpci *dpci);



--=__Part0938286C.1__=
Content-Type: text/plain; name="VT-d-drop-bogus-checks.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="VT-d-drop-bogus-checks.patch"

VT-d: drop bogus checks=0A=0AThere were a number of cases where an "iommu" =
retrieved got passed to=0Aanother function before being NULL-checked. =
While this by itself was=0Anot a problem as the called function did the =
checks, it is confusing to=0Athe reader and redundant in several cases =
(particularly with NULL-=0Achecking the return value of iommu_ir_ctrl()). =
Drop the redundant=0Achecks (also ones where the sole caller of a function =
did the checking=0Aalready), and at once make the three similar functions =
proper inline=0Ainstead of extern ones (they were prototyped in the wrong =
header file=0Aanyway, so would have needed touching sooner or later).=0A=0A=
Signed-off-by: Jan Beulich =0A=0A--- a/xen/drivers/passt=
hrough/vtd/intremap.c=0A+++ b/xen/drivers/passthrough/vtd/intremap.c=0A@@ =
-217,13 +217,6 @@ static int remap_entry_to_ioapic_rte(=0A     unsigned =
long flags;=0A     struct ir_ctrl *ir_ctrl =3D iommu_ir_ctrl(iommu);=0A =
=0A-    if ( ir_ctrl =3D=3D NULL )=0A-    {=0A-        dprintk(XENLOG_ERR =
VTDPREFIX,=0A-                "remap_entry_to_ioapic_rte: ir_ctl is not =
ready\n");=0A-        return -EFAULT;=0A-    }=0A-=0A     if ( index < 0 =
|| index > IREMAP_ENTRY_NR - 1 )=0A     {=0A         dprintk(XENLOG_ERR =
VTDPREFIX,=0A@@ -358,8 +351,7 @@ unsigned int io_apic_read_remap_rte(=0A   =
  struct iommu *iommu =3D ioapic_to_iommu(IO_APIC_ID(apic));=0A     struct =
ir_ctrl *ir_ctrl =3D iommu_ir_ctrl(iommu);=0A =0A-    if ( !iommu || =
!ir_ctrl || ir_ctrl->iremap_maddr =3D=3D 0 ||=0A-        (ir_ctrl->iremap_n=
um =3D=3D 0) ||=0A+    if ( !ir_ctrl || !ir_ctrl->iremap_maddr || =
!ir_ctrl->iremap_num ||=0A         ( (index =3D apic_pin_2_ir_idx[apic][ioa=
pic_pin]) < 0 ) )=0A         return __io_apic_read(apic, reg);=0A =0A@@ =
-385,7 +377,7 @@ void io_apic_write_remap_rte(=0A     struct ir_ctrl =
*ir_ctrl =3D iommu_ir_ctrl(iommu);=0A     int saved_mask;=0A =0A-    if ( =
!iommu || !ir_ctrl || ir_ctrl->iremap_maddr =3D=3D 0 )=0A+    if ( =
!ir_ctrl || !ir_ctrl->iremap_maddr )=0A     {=0A         __io_apic_write(ap=
ic, reg, value);=0A         return;=0A@@ -475,13 +467,6 @@ static int =
remap_entry_to_msi_msg(=0A     unsigned long flags;=0A     struct ir_ctrl =
*ir_ctrl =3D iommu_ir_ctrl(iommu);=0A =0A-    if ( ir_ctrl =3D=3D NULL =
)=0A-    {=0A-        dprintk(XENLOG_ERR VTDPREFIX,=0A-                =
"remap_entry_to_msi_msg: ir_ctl =3D=3D NULL");=0A-        return =
-EFAULT;=0A-    }=0A-=0A     remap_rte =3D (struct msi_msg_remap_entry *) =
msg;=0A     index =3D (remap_rte->address_lo.index_15 << 15) |=0A          =
    remap_rte->address_lo.index_0_14;=0A@@ -644,7 +629,7 @@ void msi_msg_re=
ad_remap_rte(=0A     iommu =3D drhd->iommu;=0A =0A     ir_ctrl =3D =
iommu_ir_ctrl(iommu);=0A-    if ( !iommu || !ir_ctrl || ir_ctrl->iremap_mad=
dr =3D=3D 0 )=0A+    if ( !ir_ctrl || !ir_ctrl->iremap_maddr )=0A         =
return;=0A =0A     remap_entry_to_msi_msg(iommu, msg);=0A@@ -663,7 +648,7 =
@@ void msi_msg_write_remap_rte(=0A     iommu =3D drhd->iommu;=0A =0A     =
ir_ctrl =3D iommu_ir_ctrl(iommu);=0A-    if ( !iommu || !ir_ctrl || =
ir_ctrl->iremap_maddr =3D=3D 0 )=0A+    if ( !ir_ctrl || !ir_ctrl->iremap_m=
addr )=0A         return;=0A =0A     msi_msg_to_remap_entry(iommu, pdev, =
msi_desc, msg);=0A--- a/xen/drivers/passthrough/vtd/iommu.c=0A+++ =
b/xen/drivers/passthrough/vtd/iommu.c=0A@@ -153,21 +153,6 @@ static void =
__init free_intel_iommu(stru=0A     xfree(intel);=0A }=0A =0A-struct =
qi_ctrl *iommu_qi_ctrl(struct iommu *iommu)=0A-{=0A-    return iommu ? =
&iommu->intel->qi_ctrl : NULL;=0A-}=0A-=0A-struct ir_ctrl *iommu_ir_ctrl(st=
ruct iommu *iommu)=0A-{=0A-    return iommu ? &iommu->intel->ir_ctrl : =
NULL;=0A-}=0A-=0A-struct iommu_flush *iommu_get_flush(struct iommu =
*iommu)=0A-{=0A-    return iommu ? &iommu->intel->flush : NULL;=0A-}=0A-=0A=
 static int iommus_incoherent;=0A static void __iommu_flush_cache(void =
*addr, unsigned int size)=0A {=0A--- a/xen/drivers/passthrough/vtd/iommu.h=
=0A+++ b/xen/drivers/passthrough/vtd/iommu.h=0A@@ -20,7 +20,7 @@=0A =
#ifndef _INTEL_IOMMU_H_=0A #define _INTEL_IOMMU_H_=0A =0A-#include =
=0A+#include =0A =0A /*=0A  * Intel IOMMU =
register specification per version 1.0 public spec.=0A@@ -510,6 +510,21 @@ =
struct intel_iommu {=0A     struct acpi_drhd_unit *drhd;=0A };=0A =
=0A+static inline struct qi_ctrl *iommu_qi_ctrl(struct iommu *iommu)=0A+{=
=0A+    return iommu ? &iommu->intel->qi_ctrl : NULL;=0A+}=0A+=0A+static =
inline struct ir_ctrl *iommu_ir_ctrl(struct iommu *iommu)=0A+{=0A+    =
return iommu ? &iommu->intel->ir_ctrl : NULL;=0A+}=0A+=0A+static inline =
struct iommu_flush *iommu_get_flush(struct iommu *iommu)=0A+{=0A+    =
return iommu ? &iommu->intel->flush : NULL;=0A+}=0A+=0A #define INTEL_IOMMU=
_DEBUG(fmt, args...) \=0A     do  \=0A     {   \=0A--- a/xen/drivers/passth=
rough/vtd/utils.c=0A+++ b/xen/drivers/passthrough/vtd/utils.c=0A@@ -267,8 =
+267,7 @@ static void dump_iommu_info(unsigned cha=0A         {=0A         =
    iommu =3D ioapic_to_iommu(mp_ioapics[apic].mpc_apicid);=0A             =
ir_ctrl =3D iommu_ir_ctrl(iommu);=0A-            if ( !iommu || !ir_ctrl =
|| ir_ctrl->iremap_maddr =3D=3D 0 ||=0A-                ir_ctrl->iremap_num=
 =3D=3D 0 )=0A+            if ( !ir_ctrl || !ir_ctrl->iremap_maddr || =
!ir_ctrl->iremap_num )=0A                 continue;=0A =0A             =
printk( "\nRedirection table of IOAPIC %x:\n", apic);=0A--- a/xen/include/x=
en/iommu.h=0A+++ b/xen/include/xen/iommu.h=0A@@ -106,9 +106,6 @@ struct =
msi_desc;=0A struct msi_msg;=0A void msi_msg_read_remap_rte(struct =
msi_desc *msi_desc, struct msi_msg *msg);=0A void msi_msg_write_remap_rte(s=
truct msi_desc *msi_desc, struct msi_msg *msg);=0A-struct qi_ctrl =
*iommu_qi_ctrl(struct iommu *iommu);=0A-struct ir_ctrl *iommu_ir_ctrl(struc=
t iommu *iommu);=0A-struct iommu_flush *iommu_get_flush(struct iommu =
*iommu);=0A void hvm_dpci_isairq_eoi(struct domain *d, unsigned int =
isairq);=0A struct hvm_irq_dpci *domain_get_irq_dpci(const struct domain =
*);=0A void free_hvm_irq_dpci(struct hvm_irq_dpci *dpci);=0A
--=__Part0938286C.1__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__Part0938286C.1__=--


From xen-devel-bounces@lists.xen.org Mon Oct 15 14:45:45 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 14:45:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNlv4-0003zt-OQ; Mon, 15 Oct 2012 14:45:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNlv2-0003zo-LI
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 14:45:24 +0000
Received: from [85.158.143.99:58964] by server-2.bemta-4.messagelabs.com id
	2A/57-25171-3812C705; Mon, 15 Oct 2012 14:45:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1350312321!24404655!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19011 invoked from network); 15 Oct 2012 14:45:22 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-216.messagelabs.com with SMTP;
	15 Oct 2012 14:45:22 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 15 Oct 2012 15:47:39 +0100
Message-Id: <507C3D9C02000078000A1735@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 15 Oct 2012 15:45:16 +0100
From: "Jan Beulich" 
To: 
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part0938286C.1__="
Cc: xen-devel 
Subject: [Xen-devel] Ping: [PATCH] VT-d: drop bogus checks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part0938286C.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

There were a number of cases where an "iommu" retrieved got passed to
another function before being NULL-checked. While this by itself was
not a problem as the called function did the checks, it is confusing to
the reader and redundant in several cases (particularly with NULL-
checking the return value of iommu_ir_ctrl()). Drop the redundant
checks (also ones where the sole caller of a function did the checking
already), and at once make the three similar functions proper inline
instead of extern ones (they were prototyped in the wrong header file
anyway, so would have needed touching sooner or later).

Signed-off-by: Jan Beulich 

--- a/xen/drivers/passthrough/vtd/intremap.c
+++ b/xen/drivers/passthrough/vtd/intremap.c
@@ -217,13 +217,6 @@ static int remap_entry_to_ioapic_rte(
     unsigned long flags;
     struct ir_ctrl *ir_ctrl =3D iommu_ir_ctrl(iommu);
=20
-    if ( ir_ctrl =3D=3D NULL )
-    {
-        dprintk(XENLOG_ERR VTDPREFIX,
-                "remap_entry_to_ioapic_rte: ir_ctl is not ready\n");
-        return -EFAULT;
-    }
-
     if ( index < 0 || index > IREMAP_ENTRY_NR - 1 )
     {
         dprintk(XENLOG_ERR VTDPREFIX,
@@ -358,8 +351,7 @@ unsigned int io_apic_read_remap_rte(
     struct iommu *iommu =3D ioapic_to_iommu(IO_APIC_ID(apic));
     struct ir_ctrl *ir_ctrl =3D iommu_ir_ctrl(iommu);
=20
-    if ( !iommu || !ir_ctrl || ir_ctrl->iremap_maddr =3D=3D 0 ||
-        (ir_ctrl->iremap_num =3D=3D 0) ||
+    if ( !ir_ctrl || !ir_ctrl->iremap_maddr || !ir_ctrl->iremap_num ||
         ( (index =3D apic_pin_2_ir_idx[apic][ioapic_pin]) < 0 ) )
         return __io_apic_read(apic, reg);
=20
@@ -385,7 +377,7 @@ void io_apic_write_remap_rte(
     struct ir_ctrl *ir_ctrl =3D iommu_ir_ctrl(iommu);
     int saved_mask;
=20
-    if ( !iommu || !ir_ctrl || ir_ctrl->iremap_maddr =3D=3D 0 )
+    if ( !ir_ctrl || !ir_ctrl->iremap_maddr )
     {
         __io_apic_write(apic, reg, value);
         return;
@@ -475,13 +467,6 @@ static int remap_entry_to_msi_msg(
     unsigned long flags;
     struct ir_ctrl *ir_ctrl =3D iommu_ir_ctrl(iommu);
=20
-    if ( ir_ctrl =3D=3D NULL )
-    {
-        dprintk(XENLOG_ERR VTDPREFIX,
-                "remap_entry_to_msi_msg: ir_ctl =3D=3D NULL");
-        return -EFAULT;
-    }
-
     remap_rte =3D (struct msi_msg_remap_entry *) msg;
     index =3D (remap_rte->address_lo.index_15 << 15) |
              remap_rte->address_lo.index_0_14;
@@ -644,7 +629,7 @@ void msi_msg_read_remap_rte(
     iommu =3D drhd->iommu;
=20
     ir_ctrl =3D iommu_ir_ctrl(iommu);
-    if ( !iommu || !ir_ctrl || ir_ctrl->iremap_maddr =3D=3D 0 )
+    if ( !ir_ctrl || !ir_ctrl->iremap_maddr )
         return;
=20
     remap_entry_to_msi_msg(iommu, msg);
@@ -663,7 +648,7 @@ void msi_msg_write_remap_rte(
     iommu =3D drhd->iommu;
=20
     ir_ctrl =3D iommu_ir_ctrl(iommu);
-    if ( !iommu || !ir_ctrl || ir_ctrl->iremap_maddr =3D=3D 0 )
+    if ( !ir_ctrl || !ir_ctrl->iremap_maddr )
         return;
=20
     msi_msg_to_remap_entry(iommu, pdev, msi_desc, msg);
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -153,21 +153,6 @@ static void __init free_intel_iommu(stru
     xfree(intel);
 }
=20
-struct qi_ctrl *iommu_qi_ctrl(struct iommu *iommu)
-{
-    return iommu ? &iommu->intel->qi_ctrl : NULL;
-}
-
-struct ir_ctrl *iommu_ir_ctrl(struct iommu *iommu)
-{
-    return iommu ? &iommu->intel->ir_ctrl : NULL;
-}
-
-struct iommu_flush *iommu_get_flush(struct iommu *iommu)
-{
-    return iommu ? &iommu->intel->flush : NULL;
-}
-
 static int iommus_incoherent;
 static void __iommu_flush_cache(void *addr, unsigned int size)
 {
--- a/xen/drivers/passthrough/vtd/iommu.h
+++ b/xen/drivers/passthrough/vtd/iommu.h
@@ -20,7 +20,7 @@
 #ifndef _INTEL_IOMMU_H_
 #define _INTEL_IOMMU_H_
=20
-#include 
+#include 
=20
 /*
  * Intel IOMMU register specification per version 1.0 public spec.
@@ -510,6 +510,21 @@ struct intel_iommu {
     struct acpi_drhd_unit *drhd;
 };
=20
+static inline struct qi_ctrl *iommu_qi_ctrl(struct iommu *iommu)
+{
+    return iommu ? &iommu->intel->qi_ctrl : NULL;
+}
+
+static inline struct ir_ctrl *iommu_ir_ctrl(struct iommu *iommu)
+{
+    return iommu ? &iommu->intel->ir_ctrl : NULL;
+}
+
+static inline struct iommu_flush *iommu_get_flush(struct iommu *iommu)
+{
+    return iommu ? &iommu->intel->flush : NULL;
+}
+
 #define INTEL_IOMMU_DEBUG(fmt, args...) \
     do  \
     {   \
--- a/xen/drivers/passthrough/vtd/utils.c
+++ b/xen/drivers/passthrough/vtd/utils.c
@@ -267,8 +267,7 @@ static void dump_iommu_info(unsigned cha
         {
             iommu =3D ioapic_to_iommu(mp_ioapics[apic].mpc_apicid);
             ir_ctrl =3D iommu_ir_ctrl(iommu);
-            if ( !iommu || !ir_ctrl || ir_ctrl->iremap_maddr =3D=3D 0 ||
-                ir_ctrl->iremap_num =3D=3D 0 )
+            if ( !ir_ctrl || !ir_ctrl->iremap_maddr || !ir_ctrl->iremap_nu=
m )
                 continue;
=20
             printk( "\nRedirection table of IOAPIC %x:\n", apic);
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -106,9 +106,6 @@ struct msi_desc;
 struct msi_msg;
 void msi_msg_read_remap_rte(struct msi_desc *msi_desc, struct msi_msg =
*msg);
 void msi_msg_write_remap_rte(struct msi_desc *msi_desc, struct msi_msg =
*msg);
-struct qi_ctrl *iommu_qi_ctrl(struct iommu *iommu);
-struct ir_ctrl *iommu_ir_ctrl(struct iommu *iommu);
-struct iommu_flush *iommu_get_flush(struct iommu *iommu);
 void hvm_dpci_isairq_eoi(struct domain *d, unsigned int isairq);
 struct hvm_irq_dpci *domain_get_irq_dpci(const struct domain *);
 void free_hvm_irq_dpci(struct hvm_irq_dpci *dpci);



--=__Part0938286C.1__=
Content-Type: text/plain; name="VT-d-drop-bogus-checks.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="VT-d-drop-bogus-checks.patch"

VT-d: drop bogus checks=0A=0AThere were a number of cases where an "iommu" =
retrieved got passed to=0Aanother function before being NULL-checked. =
While this by itself was=0Anot a problem as the called function did the =
checks, it is confusing to=0Athe reader and redundant in several cases =
(particularly with NULL-=0Achecking the return value of iommu_ir_ctrl()). =
Drop the redundant=0Achecks (also ones where the sole caller of a function =
did the checking=0Aalready), and at once make the three similar functions =
proper inline=0Ainstead of extern ones (they were prototyped in the wrong =
header file=0Aanyway, so would have needed touching sooner or later).=0A=0A=
Signed-off-by: Jan Beulich =0A=0A--- a/xen/drivers/passt=
hrough/vtd/intremap.c=0A+++ b/xen/drivers/passthrough/vtd/intremap.c=0A@@ =
-217,13 +217,6 @@ static int remap_entry_to_ioapic_rte(=0A     unsigned =
long flags;=0A     struct ir_ctrl *ir_ctrl =3D iommu_ir_ctrl(iommu);=0A =
=0A-    if ( ir_ctrl =3D=3D NULL )=0A-    {=0A-        dprintk(XENLOG_ERR =
VTDPREFIX,=0A-                "remap_entry_to_ioapic_rte: ir_ctl is not =
ready\n");=0A-        return -EFAULT;=0A-    }=0A-=0A     if ( index < 0 =
|| index > IREMAP_ENTRY_NR - 1 )=0A     {=0A         dprintk(XENLOG_ERR =
VTDPREFIX,=0A@@ -358,8 +351,7 @@ unsigned int io_apic_read_remap_rte(=0A   =
  struct iommu *iommu =3D ioapic_to_iommu(IO_APIC_ID(apic));=0A     struct =
ir_ctrl *ir_ctrl =3D iommu_ir_ctrl(iommu);=0A =0A-    if ( !iommu || =
!ir_ctrl || ir_ctrl->iremap_maddr =3D=3D 0 ||=0A-        (ir_ctrl->iremap_n=
um =3D=3D 0) ||=0A+    if ( !ir_ctrl || !ir_ctrl->iremap_maddr || =
!ir_ctrl->iremap_num ||=0A         ( (index =3D apic_pin_2_ir_idx[apic][ioa=
pic_pin]) < 0 ) )=0A         return __io_apic_read(apic, reg);=0A =0A@@ =
-385,7 +377,7 @@ void io_apic_write_remap_rte(=0A     struct ir_ctrl =
*ir_ctrl =3D iommu_ir_ctrl(iommu);=0A     int saved_mask;=0A =0A-    if ( =
!iommu || !ir_ctrl || ir_ctrl->iremap_maddr =3D=3D 0 )=0A+    if ( =
!ir_ctrl || !ir_ctrl->iremap_maddr )=0A     {=0A         __io_apic_write(ap=
ic, reg, value);=0A         return;=0A@@ -475,13 +467,6 @@ static int =
remap_entry_to_msi_msg(=0A     unsigned long flags;=0A     struct ir_ctrl =
*ir_ctrl =3D iommu_ir_ctrl(iommu);=0A =0A-    if ( ir_ctrl =3D=3D NULL =
)=0A-    {=0A-        dprintk(XENLOG_ERR VTDPREFIX,=0A-                =
"remap_entry_to_msi_msg: ir_ctl =3D=3D NULL");=0A-        return =
-EFAULT;=0A-    }=0A-=0A     remap_rte =3D (struct msi_msg_remap_entry *) =
msg;=0A     index =3D (remap_rte->address_lo.index_15 << 15) |=0A          =
    remap_rte->address_lo.index_0_14;=0A@@ -644,7 +629,7 @@ void msi_msg_re=
ad_remap_rte(=0A     iommu =3D drhd->iommu;=0A =0A     ir_ctrl =3D =
iommu_ir_ctrl(iommu);=0A-    if ( !iommu || !ir_ctrl || ir_ctrl->iremap_mad=
dr =3D=3D 0 )=0A+    if ( !ir_ctrl || !ir_ctrl->iremap_maddr )=0A         =
return;=0A =0A     remap_entry_to_msi_msg(iommu, msg);=0A@@ -663,7 +648,7 =
@@ void msi_msg_write_remap_rte(=0A     iommu =3D drhd->iommu;=0A =0A     =
ir_ctrl =3D iommu_ir_ctrl(iommu);=0A-    if ( !iommu || !ir_ctrl || =
ir_ctrl->iremap_maddr =3D=3D 0 )=0A+    if ( !ir_ctrl || !ir_ctrl->iremap_m=
addr )=0A         return;=0A =0A     msi_msg_to_remap_entry(iommu, pdev, =
msi_desc, msg);=0A--- a/xen/drivers/passthrough/vtd/iommu.c=0A+++ =
b/xen/drivers/passthrough/vtd/iommu.c=0A@@ -153,21 +153,6 @@ static void =
__init free_intel_iommu(stru=0A     xfree(intel);=0A }=0A =0A-struct =
qi_ctrl *iommu_qi_ctrl(struct iommu *iommu)=0A-{=0A-    return iommu ? =
&iommu->intel->qi_ctrl : NULL;=0A-}=0A-=0A-struct ir_ctrl *iommu_ir_ctrl(st=
ruct iommu *iommu)=0A-{=0A-    return iommu ? &iommu->intel->ir_ctrl : =
NULL;=0A-}=0A-=0A-struct iommu_flush *iommu_get_flush(struct iommu =
*iommu)=0A-{=0A-    return iommu ? &iommu->intel->flush : NULL;=0A-}=0A-=0A=
 static int iommus_incoherent;=0A static void __iommu_flush_cache(void =
*addr, unsigned int size)=0A {=0A--- a/xen/drivers/passthrough/vtd/iommu.h=
=0A+++ b/xen/drivers/passthrough/vtd/iommu.h=0A@@ -20,7 +20,7 @@=0A =
#ifndef _INTEL_IOMMU_H_=0A #define _INTEL_IOMMU_H_=0A =0A-#include =
=0A+#include =0A =0A /*=0A  * Intel IOMMU =
register specification per version 1.0 public spec.=0A@@ -510,6 +510,21 @@ =
struct intel_iommu {=0A     struct acpi_drhd_unit *drhd;=0A };=0A =
=0A+static inline struct qi_ctrl *iommu_qi_ctrl(struct iommu *iommu)=0A+{=
=0A+    return iommu ? &iommu->intel->qi_ctrl : NULL;=0A+}=0A+=0A+static =
inline struct ir_ctrl *iommu_ir_ctrl(struct iommu *iommu)=0A+{=0A+    =
return iommu ? &iommu->intel->ir_ctrl : NULL;=0A+}=0A+=0A+static inline =
struct iommu_flush *iommu_get_flush(struct iommu *iommu)=0A+{=0A+    =
return iommu ? &iommu->intel->flush : NULL;=0A+}=0A+=0A #define INTEL_IOMMU=
_DEBUG(fmt, args...) \=0A     do  \=0A     {   \=0A--- a/xen/drivers/passth=
rough/vtd/utils.c=0A+++ b/xen/drivers/passthrough/vtd/utils.c=0A@@ -267,8 =
+267,7 @@ static void dump_iommu_info(unsigned cha=0A         {=0A         =
    iommu =3D ioapic_to_iommu(mp_ioapics[apic].mpc_apicid);=0A             =
ir_ctrl =3D iommu_ir_ctrl(iommu);=0A-            if ( !iommu || !ir_ctrl =
|| ir_ctrl->iremap_maddr =3D=3D 0 ||=0A-                ir_ctrl->iremap_num=
 =3D=3D 0 )=0A+            if ( !ir_ctrl || !ir_ctrl->iremap_maddr || =
!ir_ctrl->iremap_num )=0A                 continue;=0A =0A             =
printk( "\nRedirection table of IOAPIC %x:\n", apic);=0A--- a/xen/include/x=
en/iommu.h=0A+++ b/xen/include/xen/iommu.h=0A@@ -106,9 +106,6 @@ struct =
msi_desc;=0A struct msi_msg;=0A void msi_msg_read_remap_rte(struct =
msi_desc *msi_desc, struct msi_msg *msg);=0A void msi_msg_write_remap_rte(s=
truct msi_desc *msi_desc, struct msi_msg *msg);=0A-struct qi_ctrl =
*iommu_qi_ctrl(struct iommu *iommu);=0A-struct ir_ctrl *iommu_ir_ctrl(struc=
t iommu *iommu);=0A-struct iommu_flush *iommu_get_flush(struct iommu =
*iommu);=0A void hvm_dpci_isairq_eoi(struct domain *d, unsigned int =
isairq);=0A struct hvm_irq_dpci *domain_get_irq_dpci(const struct domain =
*);=0A void free_hvm_irq_dpci(struct hvm_irq_dpci *dpci);=0A
--=__Part0938286C.1__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__Part0938286C.1__=--


From xen-devel-bounces@lists.xen.org Mon Oct 15 14:46:23 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 14:46:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNlvf-000428-65; Mon, 15 Oct 2012 14:46:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNlve-00041x-36
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 14:46:02 +0000
Received: from [85.158.143.99:32729] by server-2.bemta-4.messagelabs.com id
	9F/28-25171-9A12C705; Mon, 15 Oct 2012 14:46:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1350312360!22942217!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15675 invoked from network); 15 Oct 2012 14:46:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-216.messagelabs.com with SMTP;
	15 Oct 2012 14:46:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 15 Oct 2012 15:48:19 +0100
Message-Id: <507C3DC502000078000A1739@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 15 Oct 2012 15:45:57 +0100
From: "Jan Beulich" 
To: 
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartD0E1F1B5.1__="
Cc: xen-devel 
Subject: [Xen-devel] Ping: [PATCH] IOMMU: remove vendor specific bits from
 generic code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartD0E1F1B5.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

- names of functions used independent of vendor should not have vendor
  specific names
- vendor specific declarations should not live inn generic headers
- other vendor specific items should not be used in generic code

Signed-off-by: Jan Beulich 
--
Note that this will only apply cleanly on top of "VT-d: drop bogus
checks", sent out a few minutes ago.

--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -776,7 +776,7 @@ long arch_do_domctl(
         if ( iommu_enabled )
         {
             spin_lock(&pcidevs_lock);
-            ret =3D pt_irq_create_bind_vtd(d, bind);
+            ret =3D pt_irq_create_bind(d, bind);
             spin_unlock(&pcidevs_lock);
         }
         if ( ret < 0 )
@@ -806,7 +806,7 @@ long arch_do_domctl(
         if ( iommu_enabled )
         {
             spin_lock(&pcidevs_lock);
-            ret =3D pt_irq_destroy_bind_vtd(d, bind);
+            ret =3D pt_irq_destroy_bind(d, bind);
             spin_unlock(&pcidevs_lock);
         }
         if ( ret < 0 )
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -95,7 +95,7 @@ void free_hvm_irq_dpci(struct hvm_irq_dp
     xfree(dpci);
 }
=20
-int pt_irq_create_bind_vtd(
+int pt_irq_create_bind(
     struct domain *d, xen_domctl_bind_pt_irq_t *pt_irq_bind)
 {
     struct hvm_irq_dpci *hvm_irq_dpci =3D NULL;
@@ -277,14 +277,14 @@ int pt_irq_create_bind_vtd(
         spin_unlock(&d->event_lock);
=20
         if ( iommu_verbose )
-            dprintk(VTDPREFIX,
+            dprintk(XENLOG_G_INFO,
                     "d%d: bind: m_gsi=3D%u g_gsi=3D%u device=3D%u =
intx=3D%u\n",
                     d->domain_id, pirq, guest_gsi, device, intx);
     }
     return 0;
 }
=20
-int pt_irq_destroy_bind_vtd(
+int pt_irq_destroy_bind(
     struct domain *d, xen_domctl_bind_pt_irq_t *pt_irq_bind)
 {
     struct hvm_irq_dpci *hvm_irq_dpci =3D NULL;
@@ -302,7 +302,7 @@ int pt_irq_destroy_bind_vtd(
     link =3D hvm_pci_intx_link(device, intx);
=20
     if ( iommu_verbose )
-        dprintk(VTDPREFIX,
+        dprintk(XENLOG_G_INFO,
                 "d%d: unbind: m_gsi=3D%u g_gsi=3D%u device=3D%u intx=3D%u\=
n",
                 d->domain_id, machine_gsi, guest_gsi, device, intx);
=20
@@ -360,7 +360,7 @@ int pt_irq_destroy_bind_vtd(
     spin_unlock(&d->event_lock);
=20
     if ( iommu_verbose )
-        dprintk(VTDPREFIX,
+        dprintk(XENLOG_G_INFO,
                 "d%d unmap: m_irq=3D%u device=3D%u intx=3D%u\n",
                 d->domain_id, machine_gsi, device, intx);
=20
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -364,7 +364,7 @@ int deassign_device(struct domain *d, u1
=20
     if ( pdev->domain !=3D d )
     {
-        dprintk(XENLOG_ERR VTDPREFIX,
+        dprintk(XENLOG_G_ERR,
                 "d%d: deassign a device not owned\n", d->domain_id);
         return -EINVAL;
     }
@@ -372,8 +372,8 @@ int deassign_device(struct domain *d, u1
     ret =3D hd->platform_ops->reassign_device(d, dom0, seg, bus, devfn);
     if ( ret )
     {
-        dprintk(XENLOG_ERR VTDPREFIX,
-                "d%d: Deassign device (%04x:%02x:%02x.%u) failed!\n",
+        dprintk(XENLOG_G_ERR,
+                "d%d: deassign device (%04x:%02x:%02x.%u) failed\n",
                 d->domain_id, seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));=

         return ret;
     }
--- a/xen/drivers/passthrough/vtd/extern.h
+++ b/xen/drivers/passthrough/vtd/extern.h
@@ -24,6 +24,8 @@
 #include "dmar.h"
 #include 
=20
+#define VTDPREFIX "[VT-D]"
+
 extern bool_t rwbf_quirk;
=20
 void print_iommu_regs(struct acpi_drhd_unit *drhd);
@@ -79,6 +81,15 @@ int domain_context_mapping_one(struct do
 int domain_context_unmap_one(struct domain *domain, struct iommu *iommu,
                              u8 bus, u8 devfn);
=20
+unsigned int io_apic_read_remap_rte(unsigned int apic, unsigned int reg);
+void io_apic_write_remap_rte(unsigned int apic,
+                             unsigned int reg, unsigned int value);
+
+struct msi_desc;
+struct msi_msg;
+void msi_msg_read_remap_rte(struct msi_desc *, struct msi_msg *);
+void msi_msg_write_remap_rte(struct msi_desc *, struct msi_msg *);
+
 int is_igd_vt_enabled_quirk(void);
 void platform_quirks_init(void);
 void vtd_ops_preamble_quirk(struct iommu* iommu);
--- a/xen/drivers/passthrough/vtd/iommu.h
+++ b/xen/drivers/passthrough/vtd/iommu.h
@@ -510,6 +510,22 @@ struct intel_iommu {
     struct acpi_drhd_unit *drhd;
 };
=20
+struct iommu {
+    struct list_head list;
+    void __iomem *reg; /* Pointer to hardware regs, virtual addr */
+    u32	index;         /* Sequence number of iommu */
+    u32 nr_pt_levels;
+    u64	cap;
+    u64	ecap;
+    spinlock_t lock; /* protect context, domain ids */
+    spinlock_t register_lock; /* protect iommu register handling */
+    u64 root_maddr; /* root entry machine address */
+    int irq;
+    struct intel_iommu *intel;
+    unsigned long *domid_bitmap;  /* domain id bitmap */
+    u16 *domid_map;               /* domain id mapping array */
+};
+
 static inline struct qi_ctrl *iommu_qi_ctrl(struct iommu *iommu)
 {
     return iommu ? &iommu->intel->qi_ctrl : NULL;
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -48,22 +48,6 @@ extern struct rangeset *mmio_ro_ranges;
 #define PAGE_MASK_4K        (((u64)-1) << PAGE_SHIFT_4K)
 #define PAGE_ALIGN_4K(addr) (((addr) + PAGE_SIZE_4K - 1) & PAGE_MASK_4K)
=20
-struct iommu {
-    struct list_head list;
-    void __iomem *reg; /* Pointer to hardware regs, virtual addr */
-    u32	index;         /* Sequence number of iommu */
-    u32 nr_pt_levels;
-    u64	cap;
-    u64	ecap;
-    spinlock_t lock; /* protect context, domain ids */
-    spinlock_t register_lock; /* protect iommu register handling */
-    u64 root_maddr; /* root entry machine address */
-    int irq;
-    struct intel_iommu *intel;
-    unsigned long *domid_bitmap;  /* domain id bitmap */
-    u16 *domid_map;               /* domain id mapping array */
-};
-
 int iommu_setup(void);
 int iommu_supports_eim(void);
 int iommu_enable_x2apic_IR(void);
@@ -94,25 +78,18 @@ void pt_pci_init(void);
 struct pirq;
 int hvm_do_IRQ_dpci(struct domain *, struct pirq *);
 int dpci_ioport_intercept(ioreq_t *p);
-int pt_irq_create_bind_vtd(struct domain *d,
-                           xen_domctl_bind_pt_irq_t *pt_irq_bind);
-int pt_irq_destroy_bind_vtd(struct domain *d,
-                            xen_domctl_bind_pt_irq_t *pt_irq_bind);
-unsigned int io_apic_read_remap_rte(unsigned int apic, unsigned int reg);
-void io_apic_write_remap_rte(unsigned int apic,
-                             unsigned int reg, unsigned int value);
+int pt_irq_create_bind(struct domain *, xen_domctl_bind_pt_irq_t *);
+int pt_irq_destroy_bind(struct domain *, xen_domctl_bind_pt_irq_t *);
=20
-struct msi_desc;
-struct msi_msg;
-void msi_msg_read_remap_rte(struct msi_desc *msi_desc, struct msi_msg =
*msg);
-void msi_msg_write_remap_rte(struct msi_desc *msi_desc, struct msi_msg =
*msg);
 void hvm_dpci_isairq_eoi(struct domain *d, unsigned int isairq);
 struct hvm_irq_dpci *domain_get_irq_dpci(const struct domain *);
 void free_hvm_irq_dpci(struct hvm_irq_dpci *dpci);
 bool_t pt_irq_need_timer(uint32_t flags);
=20
 #define PT_IRQ_TIME_OUT MILLISECS(8)
-#define VTDPREFIX "[VT-D]"
+
+struct msi_desc;
+struct msi_msg;
=20
 struct iommu_ops {
     int (*init)(struct domain *d);



--=__PartD0E1F1B5.1__=
Content-Type: text/plain; name="IOMMU-generalize.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="IOMMU-generalize.patch"

IOMMU: remove vendor specific bits from generic code=0A=0A- names of =
functions used independent of vendor should not have vendor=0A  specific =
names=0A- vendor specific declarations should not live inn generic =
headers=0A- other vendor specific items should not be used in generic =
code=0A=0ASigned-off-by: Jan Beulich =0A--=0ANote that =
this will only apply cleanly on top of "VT-d: drop bogus=0Achecks", sent =
out a few minutes ago.=0A=0A--- a/xen/arch/x86/domctl.c=0A+++ b/xen/arch/x8=
6/domctl.c=0A@@ -776,7 +776,7 @@ long arch_do_domctl(=0A         if ( =
iommu_enabled )=0A         {=0A             spin_lock(&pcidevs_lock);=0A-  =
          ret =3D pt_irq_create_bind_vtd(d, bind);=0A+            ret =3D =
pt_irq_create_bind(d, bind);=0A             spin_unlock(&pcidevs_lock);=0A =
        }=0A         if ( ret < 0 )=0A@@ -806,7 +806,7 @@ long arch_do_domc=
tl(=0A         if ( iommu_enabled )=0A         {=0A             spin_lock(&=
pcidevs_lock);=0A-            ret =3D pt_irq_destroy_bind_vtd(d, bind);=0A+=
            ret =3D pt_irq_destroy_bind(d, bind);=0A             spin_unloc=
k(&pcidevs_lock);=0A         }=0A         if ( ret < 0 )=0A--- a/xen/driver=
s/passthrough/io.c=0A+++ b/xen/drivers/passthrough/io.c=0A@@ -95,7 +95,7 =
@@ void free_hvm_irq_dpci(struct hvm_irq_dp=0A     xfree(dpci);=0A }=0A =
=0A-int pt_irq_create_bind_vtd(=0A+int pt_irq_create_bind(=0A     struct =
domain *d, xen_domctl_bind_pt_irq_t *pt_irq_bind)=0A {=0A     struct =
hvm_irq_dpci *hvm_irq_dpci =3D NULL;=0A@@ -277,14 +277,14 @@ int pt_irq_cre=
ate_bind_vtd(=0A         spin_unlock(&d->event_lock);=0A =0A         if ( =
iommu_verbose )=0A-            dprintk(VTDPREFIX,=0A+            dprintk(XE=
NLOG_G_INFO,=0A                     "d%d: bind: m_gsi=3D%u g_gsi=3D%u =
device=3D%u intx=3D%u\n",=0A                     d->domain_id, pirq, =
guest_gsi, device, intx);=0A     }=0A     return 0;=0A }=0A =0A-int =
pt_irq_destroy_bind_vtd(=0A+int pt_irq_destroy_bind(=0A     struct domain =
*d, xen_domctl_bind_pt_irq_t *pt_irq_bind)=0A {=0A     struct hvm_irq_dpci =
*hvm_irq_dpci =3D NULL;=0A@@ -302,7 +302,7 @@ int pt_irq_destroy_bind_vtd(=
=0A     link =3D hvm_pci_intx_link(device, intx);=0A =0A     if ( =
iommu_verbose )=0A-        dprintk(VTDPREFIX,=0A+        dprintk(XENLOG_G_I=
NFO,=0A                 "d%d: unbind: m_gsi=3D%u g_gsi=3D%u device=3D%u =
intx=3D%u\n",=0A                 d->domain_id, machine_gsi, guest_gsi, =
device, intx);=0A =0A@@ -360,7 +360,7 @@ int pt_irq_destroy_bind_vtd(=0A   =
  spin_unlock(&d->event_lock);=0A =0A     if ( iommu_verbose )=0A-        =
dprintk(VTDPREFIX,=0A+        dprintk(XENLOG_G_INFO,=0A                 =
"d%d unmap: m_irq=3D%u device=3D%u intx=3D%u\n",=0A                 =
d->domain_id, machine_gsi, device, intx);=0A =0A--- a/xen/drivers/passthrou=
gh/iommu.c=0A+++ b/xen/drivers/passthrough/iommu.c=0A@@ -364,7 +364,7 @@ =
int deassign_device(struct domain *d, u1=0A =0A     if ( pdev->domain !=3D =
d )=0A     {=0A-        dprintk(XENLOG_ERR VTDPREFIX,=0A+        dprintk(XE=
NLOG_G_ERR,=0A                 "d%d: deassign a device not owned\n", =
d->domain_id);=0A         return -EINVAL;=0A     }=0A@@ -372,8 +372,8 @@ =
int deassign_device(struct domain *d, u1=0A     ret =3D hd->platform_ops->r=
eassign_device(d, dom0, seg, bus, devfn);=0A     if ( ret )=0A     {=0A-   =
     dprintk(XENLOG_ERR VTDPREFIX,=0A-                "d%d: Deassign =
device (%04x:%02x:%02x.%u) failed!\n",=0A+        dprintk(XENLOG_G_ERR,=0A+=
                "d%d: deassign device (%04x:%02x:%02x.%u) failed\n",=0A    =
             d->domain_id, seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));=0A =
        return ret;=0A     }=0A--- a/xen/drivers/passthrough/vtd/extern.h=
=0A+++ b/xen/drivers/passthrough/vtd/extern.h=0A@@ -24,6 +24,8 @@=0A =
#include "dmar.h"=0A #include =0A =0A+#define VTDPREFIX =
"[VT-D]"=0A+=0A extern bool_t rwbf_quirk;=0A =0A void print_iommu_regs(stru=
ct acpi_drhd_unit *drhd);=0A@@ -79,6 +81,15 @@ int domain_context_mapping_o=
ne(struct do=0A int domain_context_unmap_one(struct domain *domain, struct =
iommu *iommu,=0A                              u8 bus, u8 devfn);=0A =
=0A+unsigned int io_apic_read_remap_rte(unsigned int apic, unsigned int =
reg);=0A+void io_apic_write_remap_rte(unsigned int apic,=0A+               =
              unsigned int reg, unsigned int value);=0A+=0A+struct =
msi_desc;=0A+struct msi_msg;=0A+void msi_msg_read_remap_rte(struct =
msi_desc *, struct msi_msg *);=0A+void msi_msg_write_remap_rte(struct =
msi_desc *, struct msi_msg *);=0A+=0A int is_igd_vt_enabled_quirk(void);=0A=
 void platform_quirks_init(void);=0A void vtd_ops_preamble_quirk(struct =
iommu* iommu);=0A--- a/xen/drivers/passthrough/vtd/iommu.h=0A+++ b/xen/driv=
ers/passthrough/vtd/iommu.h=0A@@ -510,6 +510,22 @@ struct intel_iommu {=0A =
    struct acpi_drhd_unit *drhd;=0A };=0A =0A+struct iommu {=0A+    struct =
list_head list;=0A+    void __iomem *reg; /* Pointer to hardware regs, =
virtual addr */=0A+    u32	index;         /* Sequence number of iommu =
*/=0A+    u32 nr_pt_levels;=0A+    u64	cap;=0A+    u64	ecap;=0A+    =
spinlock_t lock; /* protect context, domain ids */=0A+    spinlock_t =
register_lock; /* protect iommu register handling */=0A+    u64 root_maddr;=
 /* root entry machine address */=0A+    int irq;=0A+    struct intel_iommu=
 *intel;=0A+    unsigned long *domid_bitmap;  /* domain id bitmap */=0A+   =
 u16 *domid_map;               /* domain id mapping array */=0A+};=0A+=0A =
static inline struct qi_ctrl *iommu_qi_ctrl(struct iommu *iommu)=0A {=0A   =
  return iommu ? &iommu->intel->qi_ctrl : NULL;=0A--- a/xen/include/xen/iom=
mu.h=0A+++ b/xen/include/xen/iommu.h=0A@@ -48,22 +48,6 @@ extern struct =
rangeset *mmio_ro_ranges;=0A #define PAGE_MASK_4K        (((u64)-1) << =
PAGE_SHIFT_4K)=0A #define PAGE_ALIGN_4K(addr) (((addr) + PAGE_SIZE_4K - 1) =
& PAGE_MASK_4K)=0A =0A-struct iommu {=0A-    struct list_head list;=0A-    =
void __iomem *reg; /* Pointer to hardware regs, virtual addr */=0A-    u32	=
index;         /* Sequence number of iommu */=0A-    u32 nr_pt_levels;=0A- =
   u64	cap;=0A-    u64	ecap;=0A-    spinlock_t lock; /* protect context, =
domain ids */=0A-    spinlock_t register_lock; /* protect iommu register =
handling */=0A-    u64 root_maddr; /* root entry machine address */=0A-    =
int irq;=0A-    struct intel_iommu *intel;=0A-    unsigned long *domid_bitm=
ap;  /* domain id bitmap */=0A-    u16 *domid_map;               /* domain =
id mapping array */=0A-};=0A-=0A int iommu_setup(void);=0A int iommu_suppor=
ts_eim(void);=0A int iommu_enable_x2apic_IR(void);=0A@@ -94,25 +78,18 @@ =
void pt_pci_init(void);=0A struct pirq;=0A int hvm_do_IRQ_dpci(struct =
domain *, struct pirq *);=0A int dpci_ioport_intercept(ioreq_t *p);=0A-int =
pt_irq_create_bind_vtd(struct domain *d,=0A-                           =
xen_domctl_bind_pt_irq_t *pt_irq_bind);=0A-int pt_irq_destroy_bind_vtd(stru=
ct domain *d,=0A-                            xen_domctl_bind_pt_irq_t =
*pt_irq_bind);=0A-unsigned int io_apic_read_remap_rte(unsigned int apic, =
unsigned int reg);=0A-void io_apic_write_remap_rte(unsigned int apic,=0A-  =
                           unsigned int reg, unsigned int value);=0A+int =
pt_irq_create_bind(struct domain *, xen_domctl_bind_pt_irq_t *);=0A+int =
pt_irq_destroy_bind(struct domain *, xen_domctl_bind_pt_irq_t *);=0A =
=0A-struct msi_desc;=0A-struct msi_msg;=0A-void msi_msg_read_remap_rte(stru=
ct msi_desc *msi_desc, struct msi_msg *msg);=0A-void msi_msg_write_remap_rt=
e(struct msi_desc *msi_desc, struct msi_msg *msg);=0A void hvm_dpci_isairq_=
eoi(struct domain *d, unsigned int isairq);=0A struct hvm_irq_dpci =
*domain_get_irq_dpci(const struct domain *);=0A void free_hvm_irq_dpci(stru=
ct hvm_irq_dpci *dpci);=0A bool_t pt_irq_need_timer(uint32_t flags);=0A =
=0A #define PT_IRQ_TIME_OUT MILLISECS(8)=0A-#define VTDPREFIX "[VT-D]"=0A+=
=0A+struct msi_desc;=0A+struct msi_msg;=0A =0A struct iommu_ops {=0A     =
int (*init)(struct domain *d);=0A
--=__PartD0E1F1B5.1__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__PartD0E1F1B5.1__=--


From xen-devel-bounces@lists.xen.org Mon Oct 15 14:46:23 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 14:46:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNlvf-000428-65; Mon, 15 Oct 2012 14:46:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNlve-00041x-36
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 14:46:02 +0000
Received: from [85.158.143.99:32729] by server-2.bemta-4.messagelabs.com id
	9F/28-25171-9A12C705; Mon, 15 Oct 2012 14:46:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1350312360!22942217!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15675 invoked from network); 15 Oct 2012 14:46:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-216.messagelabs.com with SMTP;
	15 Oct 2012 14:46:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 15 Oct 2012 15:48:19 +0100
Message-Id: <507C3DC502000078000A1739@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 15 Oct 2012 15:45:57 +0100
From: "Jan Beulich" 
To: 
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartD0E1F1B5.1__="
Cc: xen-devel 
Subject: [Xen-devel] Ping: [PATCH] IOMMU: remove vendor specific bits from
 generic code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartD0E1F1B5.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

- names of functions used independent of vendor should not have vendor
  specific names
- vendor specific declarations should not live inn generic headers
- other vendor specific items should not be used in generic code

Signed-off-by: Jan Beulich 
--
Note that this will only apply cleanly on top of "VT-d: drop bogus
checks", sent out a few minutes ago.

--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -776,7 +776,7 @@ long arch_do_domctl(
         if ( iommu_enabled )
         {
             spin_lock(&pcidevs_lock);
-            ret =3D pt_irq_create_bind_vtd(d, bind);
+            ret =3D pt_irq_create_bind(d, bind);
             spin_unlock(&pcidevs_lock);
         }
         if ( ret < 0 )
@@ -806,7 +806,7 @@ long arch_do_domctl(
         if ( iommu_enabled )
         {
             spin_lock(&pcidevs_lock);
-            ret =3D pt_irq_destroy_bind_vtd(d, bind);
+            ret =3D pt_irq_destroy_bind(d, bind);
             spin_unlock(&pcidevs_lock);
         }
         if ( ret < 0 )
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -95,7 +95,7 @@ void free_hvm_irq_dpci(struct hvm_irq_dp
     xfree(dpci);
 }
=20
-int pt_irq_create_bind_vtd(
+int pt_irq_create_bind(
     struct domain *d, xen_domctl_bind_pt_irq_t *pt_irq_bind)
 {
     struct hvm_irq_dpci *hvm_irq_dpci =3D NULL;
@@ -277,14 +277,14 @@ int pt_irq_create_bind_vtd(
         spin_unlock(&d->event_lock);
=20
         if ( iommu_verbose )
-            dprintk(VTDPREFIX,
+            dprintk(XENLOG_G_INFO,
                     "d%d: bind: m_gsi=3D%u g_gsi=3D%u device=3D%u =
intx=3D%u\n",
                     d->domain_id, pirq, guest_gsi, device, intx);
     }
     return 0;
 }
=20
-int pt_irq_destroy_bind_vtd(
+int pt_irq_destroy_bind(
     struct domain *d, xen_domctl_bind_pt_irq_t *pt_irq_bind)
 {
     struct hvm_irq_dpci *hvm_irq_dpci =3D NULL;
@@ -302,7 +302,7 @@ int pt_irq_destroy_bind_vtd(
     link =3D hvm_pci_intx_link(device, intx);
=20
     if ( iommu_verbose )
-        dprintk(VTDPREFIX,
+        dprintk(XENLOG_G_INFO,
                 "d%d: unbind: m_gsi=3D%u g_gsi=3D%u device=3D%u intx=3D%u\=
n",
                 d->domain_id, machine_gsi, guest_gsi, device, intx);
=20
@@ -360,7 +360,7 @@ int pt_irq_destroy_bind_vtd(
     spin_unlock(&d->event_lock);
=20
     if ( iommu_verbose )
-        dprintk(VTDPREFIX,
+        dprintk(XENLOG_G_INFO,
                 "d%d unmap: m_irq=3D%u device=3D%u intx=3D%u\n",
                 d->domain_id, machine_gsi, device, intx);
=20
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -364,7 +364,7 @@ int deassign_device(struct domain *d, u1
=20
     if ( pdev->domain !=3D d )
     {
-        dprintk(XENLOG_ERR VTDPREFIX,
+        dprintk(XENLOG_G_ERR,
                 "d%d: deassign a device not owned\n", d->domain_id);
         return -EINVAL;
     }
@@ -372,8 +372,8 @@ int deassign_device(struct domain *d, u1
     ret =3D hd->platform_ops->reassign_device(d, dom0, seg, bus, devfn);
     if ( ret )
     {
-        dprintk(XENLOG_ERR VTDPREFIX,
-                "d%d: Deassign device (%04x:%02x:%02x.%u) failed!\n",
+        dprintk(XENLOG_G_ERR,
+                "d%d: deassign device (%04x:%02x:%02x.%u) failed\n",
                 d->domain_id, seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));=

         return ret;
     }
--- a/xen/drivers/passthrough/vtd/extern.h
+++ b/xen/drivers/passthrough/vtd/extern.h
@@ -24,6 +24,8 @@
 #include "dmar.h"
 #include 
=20
+#define VTDPREFIX "[VT-D]"
+
 extern bool_t rwbf_quirk;
=20
 void print_iommu_regs(struct acpi_drhd_unit *drhd);
@@ -79,6 +81,15 @@ int domain_context_mapping_one(struct do
 int domain_context_unmap_one(struct domain *domain, struct iommu *iommu,
                              u8 bus, u8 devfn);
=20
+unsigned int io_apic_read_remap_rte(unsigned int apic, unsigned int reg);
+void io_apic_write_remap_rte(unsigned int apic,
+                             unsigned int reg, unsigned int value);
+
+struct msi_desc;
+struct msi_msg;
+void msi_msg_read_remap_rte(struct msi_desc *, struct msi_msg *);
+void msi_msg_write_remap_rte(struct msi_desc *, struct msi_msg *);
+
 int is_igd_vt_enabled_quirk(void);
 void platform_quirks_init(void);
 void vtd_ops_preamble_quirk(struct iommu* iommu);
--- a/xen/drivers/passthrough/vtd/iommu.h
+++ b/xen/drivers/passthrough/vtd/iommu.h
@@ -510,6 +510,22 @@ struct intel_iommu {
     struct acpi_drhd_unit *drhd;
 };
=20
+struct iommu {
+    struct list_head list;
+    void __iomem *reg; /* Pointer to hardware regs, virtual addr */
+    u32	index;         /* Sequence number of iommu */
+    u32 nr_pt_levels;
+    u64	cap;
+    u64	ecap;
+    spinlock_t lock; /* protect context, domain ids */
+    spinlock_t register_lock; /* protect iommu register handling */
+    u64 root_maddr; /* root entry machine address */
+    int irq;
+    struct intel_iommu *intel;
+    unsigned long *domid_bitmap;  /* domain id bitmap */
+    u16 *domid_map;               /* domain id mapping array */
+};
+
 static inline struct qi_ctrl *iommu_qi_ctrl(struct iommu *iommu)
 {
     return iommu ? &iommu->intel->qi_ctrl : NULL;
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -48,22 +48,6 @@ extern struct rangeset *mmio_ro_ranges;
 #define PAGE_MASK_4K        (((u64)-1) << PAGE_SHIFT_4K)
 #define PAGE_ALIGN_4K(addr) (((addr) + PAGE_SIZE_4K - 1) & PAGE_MASK_4K)
=20
-struct iommu {
-    struct list_head list;
-    void __iomem *reg; /* Pointer to hardware regs, virtual addr */
-    u32	index;         /* Sequence number of iommu */
-    u32 nr_pt_levels;
-    u64	cap;
-    u64	ecap;
-    spinlock_t lock; /* protect context, domain ids */
-    spinlock_t register_lock; /* protect iommu register handling */
-    u64 root_maddr; /* root entry machine address */
-    int irq;
-    struct intel_iommu *intel;
-    unsigned long *domid_bitmap;  /* domain id bitmap */
-    u16 *domid_map;               /* domain id mapping array */
-};
-
 int iommu_setup(void);
 int iommu_supports_eim(void);
 int iommu_enable_x2apic_IR(void);
@@ -94,25 +78,18 @@ void pt_pci_init(void);
 struct pirq;
 int hvm_do_IRQ_dpci(struct domain *, struct pirq *);
 int dpci_ioport_intercept(ioreq_t *p);
-int pt_irq_create_bind_vtd(struct domain *d,
-                           xen_domctl_bind_pt_irq_t *pt_irq_bind);
-int pt_irq_destroy_bind_vtd(struct domain *d,
-                            xen_domctl_bind_pt_irq_t *pt_irq_bind);
-unsigned int io_apic_read_remap_rte(unsigned int apic, unsigned int reg);
-void io_apic_write_remap_rte(unsigned int apic,
-                             unsigned int reg, unsigned int value);
+int pt_irq_create_bind(struct domain *, xen_domctl_bind_pt_irq_t *);
+int pt_irq_destroy_bind(struct domain *, xen_domctl_bind_pt_irq_t *);
=20
-struct msi_desc;
-struct msi_msg;
-void msi_msg_read_remap_rte(struct msi_desc *msi_desc, struct msi_msg =
*msg);
-void msi_msg_write_remap_rte(struct msi_desc *msi_desc, struct msi_msg =
*msg);
 void hvm_dpci_isairq_eoi(struct domain *d, unsigned int isairq);
 struct hvm_irq_dpci *domain_get_irq_dpci(const struct domain *);
 void free_hvm_irq_dpci(struct hvm_irq_dpci *dpci);
 bool_t pt_irq_need_timer(uint32_t flags);
=20
 #define PT_IRQ_TIME_OUT MILLISECS(8)
-#define VTDPREFIX "[VT-D]"
+
+struct msi_desc;
+struct msi_msg;
=20
 struct iommu_ops {
     int (*init)(struct domain *d);



--=__PartD0E1F1B5.1__=
Content-Type: text/plain; name="IOMMU-generalize.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="IOMMU-generalize.patch"

IOMMU: remove vendor specific bits from generic code=0A=0A- names of =
functions used independent of vendor should not have vendor=0A  specific =
names=0A- vendor specific declarations should not live inn generic =
headers=0A- other vendor specific items should not be used in generic =
code=0A=0ASigned-off-by: Jan Beulich =0A--=0ANote that =
this will only apply cleanly on top of "VT-d: drop bogus=0Achecks", sent =
out a few minutes ago.=0A=0A--- a/xen/arch/x86/domctl.c=0A+++ b/xen/arch/x8=
6/domctl.c=0A@@ -776,7 +776,7 @@ long arch_do_domctl(=0A         if ( =
iommu_enabled )=0A         {=0A             spin_lock(&pcidevs_lock);=0A-  =
          ret =3D pt_irq_create_bind_vtd(d, bind);=0A+            ret =3D =
pt_irq_create_bind(d, bind);=0A             spin_unlock(&pcidevs_lock);=0A =
        }=0A         if ( ret < 0 )=0A@@ -806,7 +806,7 @@ long arch_do_domc=
tl(=0A         if ( iommu_enabled )=0A         {=0A             spin_lock(&=
pcidevs_lock);=0A-            ret =3D pt_irq_destroy_bind_vtd(d, bind);=0A+=
            ret =3D pt_irq_destroy_bind(d, bind);=0A             spin_unloc=
k(&pcidevs_lock);=0A         }=0A         if ( ret < 0 )=0A--- a/xen/driver=
s/passthrough/io.c=0A+++ b/xen/drivers/passthrough/io.c=0A@@ -95,7 +95,7 =
@@ void free_hvm_irq_dpci(struct hvm_irq_dp=0A     xfree(dpci);=0A }=0A =
=0A-int pt_irq_create_bind_vtd(=0A+int pt_irq_create_bind(=0A     struct =
domain *d, xen_domctl_bind_pt_irq_t *pt_irq_bind)=0A {=0A     struct =
hvm_irq_dpci *hvm_irq_dpci =3D NULL;=0A@@ -277,14 +277,14 @@ int pt_irq_cre=
ate_bind_vtd(=0A         spin_unlock(&d->event_lock);=0A =0A         if ( =
iommu_verbose )=0A-            dprintk(VTDPREFIX,=0A+            dprintk(XE=
NLOG_G_INFO,=0A                     "d%d: bind: m_gsi=3D%u g_gsi=3D%u =
device=3D%u intx=3D%u\n",=0A                     d->domain_id, pirq, =
guest_gsi, device, intx);=0A     }=0A     return 0;=0A }=0A =0A-int =
pt_irq_destroy_bind_vtd(=0A+int pt_irq_destroy_bind(=0A     struct domain =
*d, xen_domctl_bind_pt_irq_t *pt_irq_bind)=0A {=0A     struct hvm_irq_dpci =
*hvm_irq_dpci =3D NULL;=0A@@ -302,7 +302,7 @@ int pt_irq_destroy_bind_vtd(=
=0A     link =3D hvm_pci_intx_link(device, intx);=0A =0A     if ( =
iommu_verbose )=0A-        dprintk(VTDPREFIX,=0A+        dprintk(XENLOG_G_I=
NFO,=0A                 "d%d: unbind: m_gsi=3D%u g_gsi=3D%u device=3D%u =
intx=3D%u\n",=0A                 d->domain_id, machine_gsi, guest_gsi, =
device, intx);=0A =0A@@ -360,7 +360,7 @@ int pt_irq_destroy_bind_vtd(=0A   =
  spin_unlock(&d->event_lock);=0A =0A     if ( iommu_verbose )=0A-        =
dprintk(VTDPREFIX,=0A+        dprintk(XENLOG_G_INFO,=0A                 =
"d%d unmap: m_irq=3D%u device=3D%u intx=3D%u\n",=0A                 =
d->domain_id, machine_gsi, device, intx);=0A =0A--- a/xen/drivers/passthrou=
gh/iommu.c=0A+++ b/xen/drivers/passthrough/iommu.c=0A@@ -364,7 +364,7 @@ =
int deassign_device(struct domain *d, u1=0A =0A     if ( pdev->domain !=3D =
d )=0A     {=0A-        dprintk(XENLOG_ERR VTDPREFIX,=0A+        dprintk(XE=
NLOG_G_ERR,=0A                 "d%d: deassign a device not owned\n", =
d->domain_id);=0A         return -EINVAL;=0A     }=0A@@ -372,8 +372,8 @@ =
int deassign_device(struct domain *d, u1=0A     ret =3D hd->platform_ops->r=
eassign_device(d, dom0, seg, bus, devfn);=0A     if ( ret )=0A     {=0A-   =
     dprintk(XENLOG_ERR VTDPREFIX,=0A-                "d%d: Deassign =
device (%04x:%02x:%02x.%u) failed!\n",=0A+        dprintk(XENLOG_G_ERR,=0A+=
                "d%d: deassign device (%04x:%02x:%02x.%u) failed\n",=0A    =
             d->domain_id, seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));=0A =
        return ret;=0A     }=0A--- a/xen/drivers/passthrough/vtd/extern.h=
=0A+++ b/xen/drivers/passthrough/vtd/extern.h=0A@@ -24,6 +24,8 @@=0A =
#include "dmar.h"=0A #include =0A =0A+#define VTDPREFIX =
"[VT-D]"=0A+=0A extern bool_t rwbf_quirk;=0A =0A void print_iommu_regs(stru=
ct acpi_drhd_unit *drhd);=0A@@ -79,6 +81,15 @@ int domain_context_mapping_o=
ne(struct do=0A int domain_context_unmap_one(struct domain *domain, struct =
iommu *iommu,=0A                              u8 bus, u8 devfn);=0A =
=0A+unsigned int io_apic_read_remap_rte(unsigned int apic, unsigned int =
reg);=0A+void io_apic_write_remap_rte(unsigned int apic,=0A+               =
              unsigned int reg, unsigned int value);=0A+=0A+struct =
msi_desc;=0A+struct msi_msg;=0A+void msi_msg_read_remap_rte(struct =
msi_desc *, struct msi_msg *);=0A+void msi_msg_write_remap_rte(struct =
msi_desc *, struct msi_msg *);=0A+=0A int is_igd_vt_enabled_quirk(void);=0A=
 void platform_quirks_init(void);=0A void vtd_ops_preamble_quirk(struct =
iommu* iommu);=0A--- a/xen/drivers/passthrough/vtd/iommu.h=0A+++ b/xen/driv=
ers/passthrough/vtd/iommu.h=0A@@ -510,6 +510,22 @@ struct intel_iommu {=0A =
    struct acpi_drhd_unit *drhd;=0A };=0A =0A+struct iommu {=0A+    struct =
list_head list;=0A+    void __iomem *reg; /* Pointer to hardware regs, =
virtual addr */=0A+    u32	index;         /* Sequence number of iommu =
*/=0A+    u32 nr_pt_levels;=0A+    u64	cap;=0A+    u64	ecap;=0A+    =
spinlock_t lock; /* protect context, domain ids */=0A+    spinlock_t =
register_lock; /* protect iommu register handling */=0A+    u64 root_maddr;=
 /* root entry machine address */=0A+    int irq;=0A+    struct intel_iommu=
 *intel;=0A+    unsigned long *domid_bitmap;  /* domain id bitmap */=0A+   =
 u16 *domid_map;               /* domain id mapping array */=0A+};=0A+=0A =
static inline struct qi_ctrl *iommu_qi_ctrl(struct iommu *iommu)=0A {=0A   =
  return iommu ? &iommu->intel->qi_ctrl : NULL;=0A--- a/xen/include/xen/iom=
mu.h=0A+++ b/xen/include/xen/iommu.h=0A@@ -48,22 +48,6 @@ extern struct =
rangeset *mmio_ro_ranges;=0A #define PAGE_MASK_4K        (((u64)-1) << =
PAGE_SHIFT_4K)=0A #define PAGE_ALIGN_4K(addr) (((addr) + PAGE_SIZE_4K - 1) =
& PAGE_MASK_4K)=0A =0A-struct iommu {=0A-    struct list_head list;=0A-    =
void __iomem *reg; /* Pointer to hardware regs, virtual addr */=0A-    u32	=
index;         /* Sequence number of iommu */=0A-    u32 nr_pt_levels;=0A- =
   u64	cap;=0A-    u64	ecap;=0A-    spinlock_t lock; /* protect context, =
domain ids */=0A-    spinlock_t register_lock; /* protect iommu register =
handling */=0A-    u64 root_maddr; /* root entry machine address */=0A-    =
int irq;=0A-    struct intel_iommu *intel;=0A-    unsigned long *domid_bitm=
ap;  /* domain id bitmap */=0A-    u16 *domid_map;               /* domain =
id mapping array */=0A-};=0A-=0A int iommu_setup(void);=0A int iommu_suppor=
ts_eim(void);=0A int iommu_enable_x2apic_IR(void);=0A@@ -94,25 +78,18 @@ =
void pt_pci_init(void);=0A struct pirq;=0A int hvm_do_IRQ_dpci(struct =
domain *, struct pirq *);=0A int dpci_ioport_intercept(ioreq_t *p);=0A-int =
pt_irq_create_bind_vtd(struct domain *d,=0A-                           =
xen_domctl_bind_pt_irq_t *pt_irq_bind);=0A-int pt_irq_destroy_bind_vtd(stru=
ct domain *d,=0A-                            xen_domctl_bind_pt_irq_t =
*pt_irq_bind);=0A-unsigned int io_apic_read_remap_rte(unsigned int apic, =
unsigned int reg);=0A-void io_apic_write_remap_rte(unsigned int apic,=0A-  =
                           unsigned int reg, unsigned int value);=0A+int =
pt_irq_create_bind(struct domain *, xen_domctl_bind_pt_irq_t *);=0A+int =
pt_irq_destroy_bind(struct domain *, xen_domctl_bind_pt_irq_t *);=0A =
=0A-struct msi_desc;=0A-struct msi_msg;=0A-void msi_msg_read_remap_rte(stru=
ct msi_desc *msi_desc, struct msi_msg *msg);=0A-void msi_msg_write_remap_rt=
e(struct msi_desc *msi_desc, struct msi_msg *msg);=0A void hvm_dpci_isairq_=
eoi(struct domain *d, unsigned int isairq);=0A struct hvm_irq_dpci =
*domain_get_irq_dpci(const struct domain *);=0A void free_hvm_irq_dpci(stru=
ct hvm_irq_dpci *dpci);=0A bool_t pt_irq_need_timer(uint32_t flags);=0A =
=0A #define PT_IRQ_TIME_OUT MILLISECS(8)=0A-#define VTDPREFIX "[VT-D]"=0A+=
=0A+struct msi_desc;=0A+struct msi_msg;=0A =0A struct iommu_ops {=0A     =
int (*init)(struct domain *d);=0A
--=__PartD0E1F1B5.1__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__PartD0E1F1B5.1__=--


From xen-devel-bounces@lists.xen.org Mon Oct 15 15:21:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 15:21:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNmTN-0004WL-BE; Mon, 15 Oct 2012 15:20:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNmTL-0004VN-4P
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 15:20:51 +0000
Received: from [85.158.139.83:62380] by server-16.bemta-5.messagelabs.com id
	B6/B3-09196-2D92C705; Mon, 15 Oct 2012 15:20:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1350314447!30404431!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODI0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1811 invoked from network); 15 Oct 2012 15:20:49 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 15:20:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,588,1344211200"; d="scan'208";a="211302570"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 15:20:45 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 11:20:44 -0400
Received: from [10.80.246.74] (helo=army.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TNmTE-0007YE-HW;
	Mon, 15 Oct 2012 16:20:44 +0100
From: Ian Campbell 
To: 
Date: Mon, 15 Oct 2012 15:20:34 +0000
Message-ID: <1350314444-17148-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
References: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Keir Fraser , Ian Campbell ,
	Tim Deegan ,
	Stefano Stabellini ,
	Jan Beulich 
Subject: [Xen-devel] [PATCH 01/10] xen: arm: implement
	XENMEM_add_to_physmap_range
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This allows for foreign mappings as well as batching, fitting all that
into XENMEM_add_to_physmap wasn't possible.

Signed-off-by: Ian Campbell 
Cc: keir@xen.org
Cc: Jan Beulich 
Cc: Mukesh Rathor 
---
 xen/arch/arm/mm.c           |  120 ++++++++++++++++++++++++++++++++++++++-----
 xen/include/public/memory.h |   40 +++++++++++---
 xen/include/public/xen.h    |    1 +
 3 files changed, 139 insertions(+), 22 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index b0068d2..591ad3a 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -25,6 +25,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -459,37 +461,96 @@ void share_xen_page_with_guest(struct page_info *page,
     spin_unlock(&d->page_alloc_lock);
 }
 
-static int xenmem_add_to_physmap_once(
+static int xenmem_add_to_physmap_one(
     struct domain *d,
-    const struct xen_add_to_physmap *xatp)
+    uint16_t space,
+    domid_t foreign_domid,
+    unsigned long idx,
+    xen_pfn_t gpfn)
 {
     unsigned long mfn = 0;
     int rc;
 
-    switch ( xatp->space )
+    switch ( space )
     {
-        case XENMAPSPACE_shared_info:
-            if ( xatp->idx == 0 )
-                mfn = virt_to_mfn(d->shared_info);
-            break;
-        default:
-            return -ENOSYS;
+    case XENMAPSPACE_shared_info:
+        if ( idx == 0 )
+            mfn = virt_to_mfn(d->shared_info);
+        break;
+    case XENMAPSPACE_gmfn_foreign:
+    {
+        paddr_t maddr;
+        struct domain *od;
+        rc = rcu_lock_target_domain_by_id(foreign_domid, &od);
+        if ( rc < 0 )
+            return rc;
+
+        maddr = p2m_lookup(od, idx << PAGE_SHIFT);
+        if ( maddr == INVALID_PADDR )
+        {
+            dump_p2m_lookup(od, idx << PAGE_SHIFT);
+            rcu_unlock_domain(od);
+            return -EINVAL;
+        }
+
+        mfn = maddr >> PAGE_SHIFT;
+
+        rcu_unlock_domain(od);
+        break;
+    }
+
+    default:
+        return -ENOSYS;
     }
 
     domain_lock(d);
 
     /* Map at new location. */
-    rc = guest_physmap_add_page(d, xatp->gpfn, mfn, 0);
+    rc = guest_physmap_add_page(d, gpfn, mfn, 0);
 
     domain_unlock(d);
 
     return rc;
 }
 
-static int xenmem_add_to_physmap(struct domain *d,
-                                 struct xen_add_to_physmap *xatp)
+static int xenmem_add_to_physmap_range(struct domain *d,
+                                       struct xen_add_to_physmap_range *xatpr)
 {
-    return xenmem_add_to_physmap_once(d, xatp);
+    int rc;
+
+    /* Process entries in reverse order to allow continuations */
+    while ( xatpr->size > 0 )
+    {
+        xen_ulong_t idx;
+        xen_pfn_t gpfn;
+
+        rc = copy_from_guest_offset(&idx, xatpr->idxs, xatpr->size-1, 1);
+        if ( rc < 0 )
+            goto out;
+
+        rc = copy_from_guest_offset(&gpfn, xatpr->gpfns, xatpr->size-1, 1);
+        if ( rc < 0 )
+            goto out;
+
+        rc = xenmem_add_to_physmap_one(d, xatpr->space,
+                                       xatpr->foreign_domid,
+                                       idx, gpfn);
+
+        xatpr->size--;
+
+        /* Check for continuation if it's not the last interation */
+        if ( xatpr->size > 0 && hypercall_preempt_check() )
+        {
+            rc = -EAGAIN;
+            goto out;
+        }
+    }
+
+    rc = 0;
+
+out:
+    return rc;
+
 }
 
 long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
@@ -506,14 +567,45 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&xatp, arg, 1) )
             return -EFAULT;
 
+        /* This one is only supported by add_to_physmap_range */
+        if ( xatp.space == XENMAPSPACE_gmfn_foreign )
+            return -EINVAL;
+
         rc = rcu_lock_target_domain_by_id(xatp.domid, &d);
         if ( rc != 0 )
             return rc;
 
-        rc = xenmem_add_to_physmap(d, &xatp);
+        rc = xenmem_add_to_physmap_one(d, xatp.space, DOMID_INVALID,
+                                       xatp.idx, xatp.gpfn);
+
+        rcu_unlock_domain(d);
+
+        return rc;
+    }
+
+    case XENMEM_add_to_physmap_range:
+    {
+        struct xen_add_to_physmap_range xatpr;
+        struct domain *d;
+
+        if ( copy_from_guest(&xatpr, arg, 1) )
+            return -EFAULT;
+
+        rc = rcu_lock_target_domain_by_id(xatpr.domid, &d);
+        if ( rc != 0 )
+            return rc;
+
+        rc = xenmem_add_to_physmap_range(d, &xatpr);
 
         rcu_unlock_domain(d);
 
+        if ( rc && copy_to_guest(arg, &xatpr, 1) )
+            rc = -EFAULT;
+
+        if ( rc == -EAGAIN )
+            rc = hypercall_create_continuation(
+                __HYPERVISOR_memory_op, "ih", op, arg);
+
         return rc;
     }
 
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index 86d02c8..f1ddbc0 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -198,6 +198,15 @@ struct xen_machphys_mapping {
 typedef struct xen_machphys_mapping xen_machphys_mapping_t;
 DEFINE_XEN_GUEST_HANDLE(xen_machphys_mapping_t);
 
+/* Source mapping space. */
+/* ` enum phys_map_space { */
+#define XENMAPSPACE_shared_info  0 /* shared info page */
+#define XENMAPSPACE_grant_table  1 /* grant table page */
+#define XENMAPSPACE_gmfn         2 /* GMFN */
+#define XENMAPSPACE_gmfn_range   3 /* GMFN range */
+#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another dom */
+/* ` } */
+
 /*
  * Sets the GPFN at which a particular page appears in the specified guest's
  * pseudophysical address space.
@@ -211,24 +220,39 @@ struct xen_add_to_physmap {
     /* Number of pages to go through for gmfn_range */
     uint16_t    size;
 
-    /* Source mapping space. */
-#define XENMAPSPACE_shared_info 0 /* shared info page */
-#define XENMAPSPACE_grant_table 1 /* grant table page */
-#define XENMAPSPACE_gmfn        2 /* GMFN */
-#define XENMAPSPACE_gmfn_range  3 /* GMFN range */
-    unsigned int space;
+    unsigned int space; /* => enum phys_map_space */
 
 #define XENMAPIDX_grant_table_status 0x80000000
 
-    /* Index into source mapping space. */
+    /* Index into space being mapped. */
     xen_ulong_t idx;
 
-    /* GPFN where the source mapping page should appear. */
+    /* GPFN in domid where the source mapping page should appear. */
     xen_pfn_t     gpfn;
 };
 typedef struct xen_add_to_physmap xen_add_to_physmap_t;
 DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_t);
 
+/* A batched version of add_to_physmap. */
+#define XENMEM_add_to_physmap_range 23
+struct xen_add_to_physmap_range {
+    /* Which domain to change the mapping for. */
+    domid_t domid;
+    uint16_t space; /* => enum phys_map_space */
+
+    /* Number of pages to go through */
+    uint16_t size;
+    domid_t foreign_domid; /* IFF gmfn_foreign */
+
+    /* Indexes into space being mapped. */
+    XEN_GUEST_HANDLE(xen_ulong_t) idxs;
+
+    /* GPFN in domdwhere the source mapping page should appear. */
+    XEN_GUEST_HANDLE(xen_pfn_t) gpfns;
+};
+typedef struct xen_add_to_physmap_range xen_add_to_physmap_range_t;
+DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_range_t);
+
 /*
  * Unmaps the page appearing at a particular GPFN from the specified guest's
  * pseudophysical address space.
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 361398b..e42d01f 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -49,6 +49,7 @@ DEFINE_XEN_GUEST_HANDLE(void);
 
 DEFINE_XEN_GUEST_HANDLE(uint64_t);
 DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
+DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
 #endif
 
 /*
-- 
1.7.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 15:21:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 15:21:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNmTN-0004WL-BE; Mon, 15 Oct 2012 15:20:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNmTL-0004VN-4P
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 15:20:51 +0000
Received: from [85.158.139.83:62380] by server-16.bemta-5.messagelabs.com id
	B6/B3-09196-2D92C705; Mon, 15 Oct 2012 15:20:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1350314447!30404431!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODI0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1811 invoked from network); 15 Oct 2012 15:20:49 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 15:20:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,588,1344211200"; d="scan'208";a="211302570"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 15:20:45 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 11:20:44 -0400
Received: from [10.80.246.74] (helo=army.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TNmTE-0007YE-HW;
	Mon, 15 Oct 2012 16:20:44 +0100
From: Ian Campbell 
To: 
Date: Mon, 15 Oct 2012 15:20:34 +0000
Message-ID: <1350314444-17148-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
References: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Keir Fraser , Ian Campbell ,
	Tim Deegan ,
	Stefano Stabellini ,
	Jan Beulich 
Subject: [Xen-devel] [PATCH 01/10] xen: arm: implement
	XENMEM_add_to_physmap_range
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This allows for foreign mappings as well as batching, fitting all that
into XENMEM_add_to_physmap wasn't possible.

Signed-off-by: Ian Campbell 
Cc: keir@xen.org
Cc: Jan Beulich 
Cc: Mukesh Rathor 
---
 xen/arch/arm/mm.c           |  120 ++++++++++++++++++++++++++++++++++++++-----
 xen/include/public/memory.h |   40 +++++++++++---
 xen/include/public/xen.h    |    1 +
 3 files changed, 139 insertions(+), 22 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index b0068d2..591ad3a 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -25,6 +25,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -459,37 +461,96 @@ void share_xen_page_with_guest(struct page_info *page,
     spin_unlock(&d->page_alloc_lock);
 }
 
-static int xenmem_add_to_physmap_once(
+static int xenmem_add_to_physmap_one(
     struct domain *d,
-    const struct xen_add_to_physmap *xatp)
+    uint16_t space,
+    domid_t foreign_domid,
+    unsigned long idx,
+    xen_pfn_t gpfn)
 {
     unsigned long mfn = 0;
     int rc;
 
-    switch ( xatp->space )
+    switch ( space )
     {
-        case XENMAPSPACE_shared_info:
-            if ( xatp->idx == 0 )
-                mfn = virt_to_mfn(d->shared_info);
-            break;
-        default:
-            return -ENOSYS;
+    case XENMAPSPACE_shared_info:
+        if ( idx == 0 )
+            mfn = virt_to_mfn(d->shared_info);
+        break;
+    case XENMAPSPACE_gmfn_foreign:
+    {
+        paddr_t maddr;
+        struct domain *od;
+        rc = rcu_lock_target_domain_by_id(foreign_domid, &od);
+        if ( rc < 0 )
+            return rc;
+
+        maddr = p2m_lookup(od, idx << PAGE_SHIFT);
+        if ( maddr == INVALID_PADDR )
+        {
+            dump_p2m_lookup(od, idx << PAGE_SHIFT);
+            rcu_unlock_domain(od);
+            return -EINVAL;
+        }
+
+        mfn = maddr >> PAGE_SHIFT;
+
+        rcu_unlock_domain(od);
+        break;
+    }
+
+    default:
+        return -ENOSYS;
     }
 
     domain_lock(d);
 
     /* Map at new location. */
-    rc = guest_physmap_add_page(d, xatp->gpfn, mfn, 0);
+    rc = guest_physmap_add_page(d, gpfn, mfn, 0);
 
     domain_unlock(d);
 
     return rc;
 }
 
-static int xenmem_add_to_physmap(struct domain *d,
-                                 struct xen_add_to_physmap *xatp)
+static int xenmem_add_to_physmap_range(struct domain *d,
+                                       struct xen_add_to_physmap_range *xatpr)
 {
-    return xenmem_add_to_physmap_once(d, xatp);
+    int rc;
+
+    /* Process entries in reverse order to allow continuations */
+    while ( xatpr->size > 0 )
+    {
+        xen_ulong_t idx;
+        xen_pfn_t gpfn;
+
+        rc = copy_from_guest_offset(&idx, xatpr->idxs, xatpr->size-1, 1);
+        if ( rc < 0 )
+            goto out;
+
+        rc = copy_from_guest_offset(&gpfn, xatpr->gpfns, xatpr->size-1, 1);
+        if ( rc < 0 )
+            goto out;
+
+        rc = xenmem_add_to_physmap_one(d, xatpr->space,
+                                       xatpr->foreign_domid,
+                                       idx, gpfn);
+
+        xatpr->size--;
+
+        /* Check for continuation if it's not the last interation */
+        if ( xatpr->size > 0 && hypercall_preempt_check() )
+        {
+            rc = -EAGAIN;
+            goto out;
+        }
+    }
+
+    rc = 0;
+
+out:
+    return rc;
+
 }
 
 long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
@@ -506,14 +567,45 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&xatp, arg, 1) )
             return -EFAULT;
 
+        /* This one is only supported by add_to_physmap_range */
+        if ( xatp.space == XENMAPSPACE_gmfn_foreign )
+            return -EINVAL;
+
         rc = rcu_lock_target_domain_by_id(xatp.domid, &d);
         if ( rc != 0 )
             return rc;
 
-        rc = xenmem_add_to_physmap(d, &xatp);
+        rc = xenmem_add_to_physmap_one(d, xatp.space, DOMID_INVALID,
+                                       xatp.idx, xatp.gpfn);
+
+        rcu_unlock_domain(d);
+
+        return rc;
+    }
+
+    case XENMEM_add_to_physmap_range:
+    {
+        struct xen_add_to_physmap_range xatpr;
+        struct domain *d;
+
+        if ( copy_from_guest(&xatpr, arg, 1) )
+            return -EFAULT;
+
+        rc = rcu_lock_target_domain_by_id(xatpr.domid, &d);
+        if ( rc != 0 )
+            return rc;
+
+        rc = xenmem_add_to_physmap_range(d, &xatpr);
 
         rcu_unlock_domain(d);
 
+        if ( rc && copy_to_guest(arg, &xatpr, 1) )
+            rc = -EFAULT;
+
+        if ( rc == -EAGAIN )
+            rc = hypercall_create_continuation(
+                __HYPERVISOR_memory_op, "ih", op, arg);
+
         return rc;
     }
 
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index 86d02c8..f1ddbc0 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -198,6 +198,15 @@ struct xen_machphys_mapping {
 typedef struct xen_machphys_mapping xen_machphys_mapping_t;
 DEFINE_XEN_GUEST_HANDLE(xen_machphys_mapping_t);
 
+/* Source mapping space. */
+/* ` enum phys_map_space { */
+#define XENMAPSPACE_shared_info  0 /* shared info page */
+#define XENMAPSPACE_grant_table  1 /* grant table page */
+#define XENMAPSPACE_gmfn         2 /* GMFN */
+#define XENMAPSPACE_gmfn_range   3 /* GMFN range */
+#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another dom */
+/* ` } */
+
 /*
  * Sets the GPFN at which a particular page appears in the specified guest's
  * pseudophysical address space.
@@ -211,24 +220,39 @@ struct xen_add_to_physmap {
     /* Number of pages to go through for gmfn_range */
     uint16_t    size;
 
-    /* Source mapping space. */
-#define XENMAPSPACE_shared_info 0 /* shared info page */
-#define XENMAPSPACE_grant_table 1 /* grant table page */
-#define XENMAPSPACE_gmfn        2 /* GMFN */
-#define XENMAPSPACE_gmfn_range  3 /* GMFN range */
-    unsigned int space;
+    unsigned int space; /* => enum phys_map_space */
 
 #define XENMAPIDX_grant_table_status 0x80000000
 
-    /* Index into source mapping space. */
+    /* Index into space being mapped. */
     xen_ulong_t idx;
 
-    /* GPFN where the source mapping page should appear. */
+    /* GPFN in domid where the source mapping page should appear. */
     xen_pfn_t     gpfn;
 };
 typedef struct xen_add_to_physmap xen_add_to_physmap_t;
 DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_t);
 
+/* A batched version of add_to_physmap. */
+#define XENMEM_add_to_physmap_range 23
+struct xen_add_to_physmap_range {
+    /* Which domain to change the mapping for. */
+    domid_t domid;
+    uint16_t space; /* => enum phys_map_space */
+
+    /* Number of pages to go through */
+    uint16_t size;
+    domid_t foreign_domid; /* IFF gmfn_foreign */
+
+    /* Indexes into space being mapped. */
+    XEN_GUEST_HANDLE(xen_ulong_t) idxs;
+
+    /* GPFN in domdwhere the source mapping page should appear. */
+    XEN_GUEST_HANDLE(xen_pfn_t) gpfns;
+};
+typedef struct xen_add_to_physmap_range xen_add_to_physmap_range_t;
+DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_range_t);
+
 /*
  * Unmaps the page appearing at a particular GPFN from the specified guest's
  * pseudophysical address space.
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 361398b..e42d01f 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -49,6 +49,7 @@ DEFINE_XEN_GUEST_HANDLE(void);
 
 DEFINE_XEN_GUEST_HANDLE(uint64_t);
 DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
+DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
 #endif
 
 /*
-- 
1.7.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 15:21:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 15:21:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNmTQ-0004YC-7X; Mon, 15 Oct 2012 15:20:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNmTO-0004Uz-Ay
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 15:20:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1350314446!8639953!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYzNjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22188 invoked from network); 15 Oct 2012 15:20:47 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 15:20:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,588,1344211200"; d="scan'208";a="41237261"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 15:20:45 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 11:20:45 -0400
Received: from [10.80.246.74] (helo=army.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TNmTE-0007YE-Vd;
	Mon, 15 Oct 2012 16:20:44 +0100
From: Ian Campbell 
To: 
Date: Mon, 15 Oct 2012 15:20:39 +0000
Message-ID: <1350314444-17148-6-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
References: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Keir Fraser , Ian Campbell ,
	Stefano Stabellini ,
	Tim Deegan ,
	Stefano Stabellini ,
	Jan Beulich 
Subject: [Xen-devel] [PATCH 06/10] xen: introduce XEN_GUEST_HANDLE_PARAM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Stefano Stabellini 

XEN_GUEST_HANDLE_PARAM is going to be used to distinguish guest pointers
stored in memory from guest pointers as hypercall parameters.

guest_handle_* macros default to XEN_GUEST_HANDLE_PARAM as return type.
Two new guest_handle_to_param and guest_handle_from_param macros are
introduced to do conversions.

Signed-off-by: Stefano Stabellini 
Signed-off-by: Ian Campbell 
Cc: keir@xen.org
Cc: JBeulich@suse.com

---
Changes in v2:

- add 2 missing #define _XEN_GUEST_HANDLE_PARAM for the compilation of
the compat code.

Changes in v3:

- move the guest_handle_cast change into this patch;
- add a clear comment on top of guest_handle_cast;
- also s/XEN_GUEST_HANDLE/XEN_GUEST_HANDLE_PARAM in
  guest_handle_from_ptr and const_guest_handle_from_ptr;
- introduce guest_handle_from_param and guest_handle_to_param.

Changes in v4:

- make both XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM unions on ARM;
- simplify set_xen_guest_handle_raw on ARM;
- add type checking in guest_handle_to_param and guest_handle_from_param
trivial.

Changes in v5 (ijc):

- Fix arm's set_xen_guest_handle_raw which mixed up t and _t. Use a
  more unique variable name for the benefit of -Wshadow.

Changes in v6 (ijc):
- Defer change of XEN_GUEST_HANDLE_PARAM on ARM until later in order
  to not break the build during this and subsequent transitional
  patches
---
 xen/include/asm-arm/guest_access.h |   32 ++++++++++++++++++++++++++++----
 xen/include/asm-x86/guest_access.h |   29 +++++++++++++++++++++++++----
 xen/include/public/arch-arm.h      |   26 ++++++++++++++++++++++----
 xen/include/public/arch-x86/xen.h  |    9 +++++++++
 xen/include/xen/xencomm.h          |   22 +++++++++++++++++++++-
 5 files changed, 105 insertions(+), 13 deletions(-)

diff --git a/xen/include/asm-arm/guest_access.h b/xen/include/asm-arm/guest_access.h
index 0fceae6..5686217 100644
--- a/xen/include/asm-arm/guest_access.h
+++ b/xen/include/asm-arm/guest_access.h
@@ -27,16 +27,40 @@ unsigned long raw_clear_guest(void *to, unsigned len);
 #define guest_handle_add_offset(hnd, nr) ((hnd).p += (nr))
 #define guest_handle_subtract_offset(hnd, nr) ((hnd).p -= (nr))
 
-/* Cast a guest handle to the specified type of handle. */
+/* Cast a guest handle (either XEN_GUEST_HANDLE or XEN_GUEST_HANDLE_PARAM)
+ * to the specified type of XEN_GUEST_HANDLE_PARAM. */
 #define guest_handle_cast(hnd, type) ({         \
     type *_x = (hnd).p;                         \
-    (XEN_GUEST_HANDLE(type)) { _x };            \
+    (XEN_GUEST_HANDLE_PARAM(type)) { _x };            \
+})
+
+/* Cast a XEN_GUEST_HANDLE to XEN_GUEST_HANDLE_PARAM */
+#define guest_handle_to_param(hnd, type) ({                  \
+    typeof((hnd).p) _x = (hnd).p;                            \
+    XEN_GUEST_HANDLE_PARAM(type) _y = { _x };                \
+    /* type checking: make sure that the pointers inside     \
+     * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of    \
+     * the same type, then return hnd */                     \
+    (void)(&_x == &_y.p);                                    \
+    _y;                                                      \
+})
+
+
+/* Cast a XEN_GUEST_HANDLE_PARAM to XEN_GUEST_HANDLE */
+#define guest_handle_from_param(hnd, type) ({               \
+    typeof((hnd).p) _x = (hnd).p;                           \
+    XEN_GUEST_HANDLE(type) _y = { _x };                     \
+    /* type checking: make sure that the pointers inside    \
+     * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of   \
+     * the same type, then return hnd */                    \
+    (void)(&_x == &_y.p);                                   \
+    _y;                                                     \
 })
 
 #define guest_handle_from_ptr(ptr, type)        \
-    ((XEN_GUEST_HANDLE(type)) { (type *)ptr })
+    ((XEN_GUEST_HANDLE_PARAM(type)) { (type *)ptr })
 #define const_guest_handle_from_ptr(ptr, type)  \
-    ((XEN_GUEST_HANDLE(const_##type)) { (const type *)ptr })
+    ((XEN_GUEST_HANDLE_PARAM(const_##type)) { (const type *)ptr })
 
 /*
  * Copy an array of objects to guest context via a guest handle,
diff --git a/xen/include/asm-x86/guest_access.h b/xen/include/asm-x86/guest_access.h
index e3ac1d6..ca700c9 100644
--- a/xen/include/asm-x86/guest_access.h
+++ b/xen/include/asm-x86/guest_access.h
@@ -45,19 +45,40 @@
 #define guest_handle_add_offset(hnd, nr) ((hnd).p += (nr))
 #define guest_handle_subtract_offset(hnd, nr) ((hnd).p -= (nr))
 
-/* Cast a guest handle to the specified type of handle. */
+/* Cast a guest handle (either XEN_GUEST_HANDLE or XEN_GUEST_HANDLE_PARAM)
+ * to the specified type of XEN_GUEST_HANDLE_PARAM. */
 #define guest_handle_cast(hnd, type) ({         \
     type *_x = (hnd).p;                         \
-    (XEN_GUEST_HANDLE(type)) { _x };            \
+    (XEN_GUEST_HANDLE_PARAM(type)) { _x };            \
+})
+
+/* Cast a XEN_GUEST_HANDLE to XEN_GUEST_HANDLE_PARAM */
+#define guest_handle_to_param(hnd, type) ({                  \
+    /* type checking: make sure that the pointers inside     \
+     * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of    \
+     * the same type, then return hnd */                     \
+    (void)((typeof(&(hnd).p)) 0 ==                           \
+        (typeof(&((XEN_GUEST_HANDLE_PARAM(type)) {}).p)) 0); \
+    (hnd);                                                   \
+})
+
+/* Cast a XEN_GUEST_HANDLE_PARAM to XEN_GUEST_HANDLE */
+#define guest_handle_from_param(hnd, type) ({                \
+    /* type checking: make sure that the pointers inside     \
+     * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of    \
+     * the same type, then return hnd */                     \
+    (void)((typeof(&(hnd).p)) 0 ==                           \
+        (typeof(&((XEN_GUEST_HANDLE_PARAM(type)) {}).p)) 0); \
+    (hnd);                                                   \
 })
 
 #define guest_handle_for_field(hnd, type, fld)          \
     ((XEN_GUEST_HANDLE(type)) { &(hnd).p->fld })
 
 #define guest_handle_from_ptr(ptr, type)        \
-    ((XEN_GUEST_HANDLE(type)) { (type *)ptr })
+    ((XEN_GUEST_HANDLE_PARAM(type)) { (type *)ptr })
 #define const_guest_handle_from_ptr(ptr, type)  \
-    ((XEN_GUEST_HANDLE(const_##type)) { (const type *)ptr })
+    ((XEN_GUEST_HANDLE_PARAM(const_##type)) { (const type *)ptr })
 
 /*
  * Copy an array of objects to guest context via a guest handle,
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index 2ae6548..ac493a5 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -51,18 +51,36 @@
 
 #define XEN_HYPERCALL_TAG   0XEA1
 
+#define uint64_aligned_t uint64_t __attribute__((aligned(8)))
 
 #ifndef __ASSEMBLY__
-#define ___DEFINE_XEN_GUEST_HANDLE(name, type) \
-    typedef struct { type *p; } __guest_handle_ ## name
+#define ___DEFINE_XEN_GUEST_HANDLE(name, type)                  \
+    typedef union { type *p; unsigned long q; }                 \
+        __guest_handle_ ## name;                                \
+    typedef union { type *p; uint64_aligned_t q; }              \
+        __guest_handle_64_ ## name;
 
+/*
+ * XEN_GUEST_HANDLE represents a guest pointer, when passed as a field
+ * in a struct in memory. On ARM is always 8 bytes sizes and 8 bytes
+ * aligned.
+ * XEN_GUEST_HANDLE_PARAM represent a guest pointer, when passed as an
+ * hypercall argument. It is 4 bytes on aarch and 8 bytes on aarch64.
+ */
 #define __DEFINE_XEN_GUEST_HANDLE(name, type) \
     ___DEFINE_XEN_GUEST_HANDLE(name, type);   \
     ___DEFINE_XEN_GUEST_HANDLE(const_##name, const type)
 #define DEFINE_XEN_GUEST_HANDLE(name)   __DEFINE_XEN_GUEST_HANDLE(name, name)
-#define __XEN_GUEST_HANDLE(name)        __guest_handle_ ## name
+#define __XEN_GUEST_HANDLE(name)        __guest_handle_64_ ## name
 #define XEN_GUEST_HANDLE(name)          __XEN_GUEST_HANDLE(name)
-#define set_xen_guest_handle_raw(hnd, val)  do { (hnd).p = val; } while (0)
+/* this is going to be changed on 64 bit */
+#define XEN_GUEST_HANDLE_PARAM(name)   XEN_GUEST_HANDLE(name)
+#define set_xen_guest_handle_raw(hnd, val)                  \
+    do {                                                    \
+        typeof(&(hnd)) _sxghr_tmp = &(hnd);                 \
+        _sxghr_tmp->q = 0;                                  \
+        _sxghr_tmp->p = val;                                \
+    } while ( 0 )
 #ifdef __XEN_TOOLS__
 #define get_xen_guest_handle(val, hnd)  do { val = (hnd).p; } while (0)
 #endif
diff --git a/xen/include/public/arch-x86/xen.h b/xen/include/public/arch-x86/xen.h
index fff8824..f5c58a6 100644
--- a/xen/include/public/arch-x86/xen.h
+++ b/xen/include/public/arch-x86/xen.h
@@ -38,12 +38,21 @@
     typedef type * __guest_handle_ ## name
 #endif
 
+/*
+ * XEN_GUEST_HANDLE represents a guest pointer, when passed as a field
+ * in a struct in memory.
+ * XEN_GUEST_HANDLE_PARAM represent a guest pointer, when passed as an
+ * hypercall argument.
+ * XEN_GUEST_HANDLE_PARAM and XEN_GUEST_HANDLE are the same on X86 but
+ * they might not be on other architectures.
+ */
 #define __DEFINE_XEN_GUEST_HANDLE(name, type) \
     ___DEFINE_XEN_GUEST_HANDLE(name, type);   \
     ___DEFINE_XEN_GUEST_HANDLE(const_##name, const type)
 #define DEFINE_XEN_GUEST_HANDLE(name)   __DEFINE_XEN_GUEST_HANDLE(name, name)
 #define __XEN_GUEST_HANDLE(name)        __guest_handle_ ## name
 #define XEN_GUEST_HANDLE(name)          __XEN_GUEST_HANDLE(name)
+#define XEN_GUEST_HANDLE_PARAM(name)    XEN_GUEST_HANDLE(name)
 #define set_xen_guest_handle_raw(hnd, val)  do { (hnd).p = val; } while (0)
 #ifdef __XEN_TOOLS__
 #define get_xen_guest_handle(val, hnd)  do { val = (hnd).p; } while (0)
diff --git a/xen/include/xen/xencomm.h b/xen/include/xen/xencomm.h
index 730da7c..3426b8a 100644
--- a/xen/include/xen/xencomm.h
+++ b/xen/include/xen/xencomm.h
@@ -66,11 +66,31 @@ static inline unsigned long xencomm_inline_addr(const void *handle)
 /* Cast a guest handle to the specified type of handle. */
 #define guest_handle_cast(hnd, type) ({         \
     type *_x = (hnd).p;                         \
-    XEN_GUEST_HANDLE(type) _y;                  \
+    XEN_GUEST_HANDLE_PARAM(type) _y;            \
     set_xen_guest_handle(_y, _x);               \
     _y;                                         \
 })
 
+/* Cast a XEN_GUEST_HANDLE to XEN_GUEST_HANDLE_PARAM */
+#define guest_handle_to_param(hnd, type) ({                  \
+    /* type checking: make sure that the pointers inside     \
+     * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of    \
+     * the same type, then return hnd */                     \
+    (void)((typeof(&(hnd).p)) 0 ==                           \
+        (typeof(&((XEN_GUEST_HANDLE_PARAM(type)) {}).p)) 0); \
+    (hnd);                                                   \
+})
+
+/* Cast a XEN_GUEST_HANDLE_PARAM to XEN_GUEST_HANDLE */
+#define guest_handle_from_param(hnd, type) ({                \
+    /* type checking: make sure that the pointers inside     \
+     * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of    \
+     * the same type, then return hnd */                     \
+    (void)((typeof(&(hnd).p)) 0 ==                           \
+        (typeof(&((XEN_GUEST_HANDLE_PARAM(type)) {}).p)) 0); \
+    (hnd);                                                   \
+})
+
 /* Since we run in real mode, we can safely access all addresses. That also
  * means our __routines are identical to our "normal" routines. */
 #define guest_handle_okay(hnd, nr) 1
-- 
1.7.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 15:21:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 15:21:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNmTQ-0004YC-7X; Mon, 15 Oct 2012 15:20:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNmTO-0004Uz-Ay
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 15:20:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1350314446!8639953!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYzNjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22188 invoked from network); 15 Oct 2012 15:20:47 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 15:20:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,588,1344211200"; d="scan'208";a="41237261"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 15:20:45 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 11:20:45 -0400
Received: from [10.80.246.74] (helo=army.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TNmTE-0007YE-Vd;
	Mon, 15 Oct 2012 16:20:44 +0100
From: Ian Campbell 
To: 
Date: Mon, 15 Oct 2012 15:20:39 +0000
Message-ID: <1350314444-17148-6-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
References: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Keir Fraser , Ian Campbell ,
	Stefano Stabellini ,
	Tim Deegan ,
	Stefano Stabellini ,
	Jan Beulich 
Subject: [Xen-devel] [PATCH 06/10] xen: introduce XEN_GUEST_HANDLE_PARAM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Stefano Stabellini 

XEN_GUEST_HANDLE_PARAM is going to be used to distinguish guest pointers
stored in memory from guest pointers as hypercall parameters.

guest_handle_* macros default to XEN_GUEST_HANDLE_PARAM as return type.
Two new guest_handle_to_param and guest_handle_from_param macros are
introduced to do conversions.

Signed-off-by: Stefano Stabellini 
Signed-off-by: Ian Campbell 
Cc: keir@xen.org
Cc: JBeulich@suse.com

---
Changes in v2:

- add 2 missing #define _XEN_GUEST_HANDLE_PARAM for the compilation of
the compat code.

Changes in v3:

- move the guest_handle_cast change into this patch;
- add a clear comment on top of guest_handle_cast;
- also s/XEN_GUEST_HANDLE/XEN_GUEST_HANDLE_PARAM in
  guest_handle_from_ptr and const_guest_handle_from_ptr;
- introduce guest_handle_from_param and guest_handle_to_param.

Changes in v4:

- make both XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM unions on ARM;
- simplify set_xen_guest_handle_raw on ARM;
- add type checking in guest_handle_to_param and guest_handle_from_param
trivial.

Changes in v5 (ijc):

- Fix arm's set_xen_guest_handle_raw which mixed up t and _t. Use a
  more unique variable name for the benefit of -Wshadow.

Changes in v6 (ijc):
- Defer change of XEN_GUEST_HANDLE_PARAM on ARM until later in order
  to not break the build during this and subsequent transitional
  patches
---
 xen/include/asm-arm/guest_access.h |   32 ++++++++++++++++++++++++++++----
 xen/include/asm-x86/guest_access.h |   29 +++++++++++++++++++++++++----
 xen/include/public/arch-arm.h      |   26 ++++++++++++++++++++++----
 xen/include/public/arch-x86/xen.h  |    9 +++++++++
 xen/include/xen/xencomm.h          |   22 +++++++++++++++++++++-
 5 files changed, 105 insertions(+), 13 deletions(-)

diff --git a/xen/include/asm-arm/guest_access.h b/xen/include/asm-arm/guest_access.h
index 0fceae6..5686217 100644
--- a/xen/include/asm-arm/guest_access.h
+++ b/xen/include/asm-arm/guest_access.h
@@ -27,16 +27,40 @@ unsigned long raw_clear_guest(void *to, unsigned len);
 #define guest_handle_add_offset(hnd, nr) ((hnd).p += (nr))
 #define guest_handle_subtract_offset(hnd, nr) ((hnd).p -= (nr))
 
-/* Cast a guest handle to the specified type of handle. */
+/* Cast a guest handle (either XEN_GUEST_HANDLE or XEN_GUEST_HANDLE_PARAM)
+ * to the specified type of XEN_GUEST_HANDLE_PARAM. */
 #define guest_handle_cast(hnd, type) ({         \
     type *_x = (hnd).p;                         \
-    (XEN_GUEST_HANDLE(type)) { _x };            \
+    (XEN_GUEST_HANDLE_PARAM(type)) { _x };            \
+})
+
+/* Cast a XEN_GUEST_HANDLE to XEN_GUEST_HANDLE_PARAM */
+#define guest_handle_to_param(hnd, type) ({                  \
+    typeof((hnd).p) _x = (hnd).p;                            \
+    XEN_GUEST_HANDLE_PARAM(type) _y = { _x };                \
+    /* type checking: make sure that the pointers inside     \
+     * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of    \
+     * the same type, then return hnd */                     \
+    (void)(&_x == &_y.p);                                    \
+    _y;                                                      \
+})
+
+
+/* Cast a XEN_GUEST_HANDLE_PARAM to XEN_GUEST_HANDLE */
+#define guest_handle_from_param(hnd, type) ({               \
+    typeof((hnd).p) _x = (hnd).p;                           \
+    XEN_GUEST_HANDLE(type) _y = { _x };                     \
+    /* type checking: make sure that the pointers inside    \
+     * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of   \
+     * the same type, then return hnd */                    \
+    (void)(&_x == &_y.p);                                   \
+    _y;                                                     \
 })
 
 #define guest_handle_from_ptr(ptr, type)        \
-    ((XEN_GUEST_HANDLE(type)) { (type *)ptr })
+    ((XEN_GUEST_HANDLE_PARAM(type)) { (type *)ptr })
 #define const_guest_handle_from_ptr(ptr, type)  \
-    ((XEN_GUEST_HANDLE(const_##type)) { (const type *)ptr })
+    ((XEN_GUEST_HANDLE_PARAM(const_##type)) { (const type *)ptr })
 
 /*
  * Copy an array of objects to guest context via a guest handle,
diff --git a/xen/include/asm-x86/guest_access.h b/xen/include/asm-x86/guest_access.h
index e3ac1d6..ca700c9 100644
--- a/xen/include/asm-x86/guest_access.h
+++ b/xen/include/asm-x86/guest_access.h
@@ -45,19 +45,40 @@
 #define guest_handle_add_offset(hnd, nr) ((hnd).p += (nr))
 #define guest_handle_subtract_offset(hnd, nr) ((hnd).p -= (nr))
 
-/* Cast a guest handle to the specified type of handle. */
+/* Cast a guest handle (either XEN_GUEST_HANDLE or XEN_GUEST_HANDLE_PARAM)
+ * to the specified type of XEN_GUEST_HANDLE_PARAM. */
 #define guest_handle_cast(hnd, type) ({         \
     type *_x = (hnd).p;                         \
-    (XEN_GUEST_HANDLE(type)) { _x };            \
+    (XEN_GUEST_HANDLE_PARAM(type)) { _x };            \
+})
+
+/* Cast a XEN_GUEST_HANDLE to XEN_GUEST_HANDLE_PARAM */
+#define guest_handle_to_param(hnd, type) ({                  \
+    /* type checking: make sure that the pointers inside     \
+     * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of    \
+     * the same type, then return hnd */                     \
+    (void)((typeof(&(hnd).p)) 0 ==                           \
+        (typeof(&((XEN_GUEST_HANDLE_PARAM(type)) {}).p)) 0); \
+    (hnd);                                                   \
+})
+
+/* Cast a XEN_GUEST_HANDLE_PARAM to XEN_GUEST_HANDLE */
+#define guest_handle_from_param(hnd, type) ({                \
+    /* type checking: make sure that the pointers inside     \
+     * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of    \
+     * the same type, then return hnd */                     \
+    (void)((typeof(&(hnd).p)) 0 ==                           \
+        (typeof(&((XEN_GUEST_HANDLE_PARAM(type)) {}).p)) 0); \
+    (hnd);                                                   \
 })
 
 #define guest_handle_for_field(hnd, type, fld)          \
     ((XEN_GUEST_HANDLE(type)) { &(hnd).p->fld })
 
 #define guest_handle_from_ptr(ptr, type)        \
-    ((XEN_GUEST_HANDLE(type)) { (type *)ptr })
+    ((XEN_GUEST_HANDLE_PARAM(type)) { (type *)ptr })
 #define const_guest_handle_from_ptr(ptr, type)  \
-    ((XEN_GUEST_HANDLE(const_##type)) { (const type *)ptr })
+    ((XEN_GUEST_HANDLE_PARAM(const_##type)) { (const type *)ptr })
 
 /*
  * Copy an array of objects to guest context via a guest handle,
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index 2ae6548..ac493a5 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -51,18 +51,36 @@
 
 #define XEN_HYPERCALL_TAG   0XEA1
 
+#define uint64_aligned_t uint64_t __attribute__((aligned(8)))
 
 #ifndef __ASSEMBLY__
-#define ___DEFINE_XEN_GUEST_HANDLE(name, type) \
-    typedef struct { type *p; } __guest_handle_ ## name
+#define ___DEFINE_XEN_GUEST_HANDLE(name, type)                  \
+    typedef union { type *p; unsigned long q; }                 \
+        __guest_handle_ ## name;                                \
+    typedef union { type *p; uint64_aligned_t q; }              \
+        __guest_handle_64_ ## name;
 
+/*
+ * XEN_GUEST_HANDLE represents a guest pointer, when passed as a field
+ * in a struct in memory. On ARM is always 8 bytes sizes and 8 bytes
+ * aligned.
+ * XEN_GUEST_HANDLE_PARAM represent a guest pointer, when passed as an
+ * hypercall argument. It is 4 bytes on aarch and 8 bytes on aarch64.
+ */
 #define __DEFINE_XEN_GUEST_HANDLE(name, type) \
     ___DEFINE_XEN_GUEST_HANDLE(name, type);   \
     ___DEFINE_XEN_GUEST_HANDLE(const_##name, const type)
 #define DEFINE_XEN_GUEST_HANDLE(name)   __DEFINE_XEN_GUEST_HANDLE(name, name)
-#define __XEN_GUEST_HANDLE(name)        __guest_handle_ ## name
+#define __XEN_GUEST_HANDLE(name)        __guest_handle_64_ ## name
 #define XEN_GUEST_HANDLE(name)          __XEN_GUEST_HANDLE(name)
-#define set_xen_guest_handle_raw(hnd, val)  do { (hnd).p = val; } while (0)
+/* this is going to be changed on 64 bit */
+#define XEN_GUEST_HANDLE_PARAM(name)   XEN_GUEST_HANDLE(name)
+#define set_xen_guest_handle_raw(hnd, val)                  \
+    do {                                                    \
+        typeof(&(hnd)) _sxghr_tmp = &(hnd);                 \
+        _sxghr_tmp->q = 0;                                  \
+        _sxghr_tmp->p = val;                                \
+    } while ( 0 )
 #ifdef __XEN_TOOLS__
 #define get_xen_guest_handle(val, hnd)  do { val = (hnd).p; } while (0)
 #endif
diff --git a/xen/include/public/arch-x86/xen.h b/xen/include/public/arch-x86/xen.h
index fff8824..f5c58a6 100644
--- a/xen/include/public/arch-x86/xen.h
+++ b/xen/include/public/arch-x86/xen.h
@@ -38,12 +38,21 @@
     typedef type * __guest_handle_ ## name
 #endif
 
+/*
+ * XEN_GUEST_HANDLE represents a guest pointer, when passed as a field
+ * in a struct in memory.
+ * XEN_GUEST_HANDLE_PARAM represent a guest pointer, when passed as an
+ * hypercall argument.
+ * XEN_GUEST_HANDLE_PARAM and XEN_GUEST_HANDLE are the same on X86 but
+ * they might not be on other architectures.
+ */
 #define __DEFINE_XEN_GUEST_HANDLE(name, type) \
     ___DEFINE_XEN_GUEST_HANDLE(name, type);   \
     ___DEFINE_XEN_GUEST_HANDLE(const_##name, const type)
 #define DEFINE_XEN_GUEST_HANDLE(name)   __DEFINE_XEN_GUEST_HANDLE(name, name)
 #define __XEN_GUEST_HANDLE(name)        __guest_handle_ ## name
 #define XEN_GUEST_HANDLE(name)          __XEN_GUEST_HANDLE(name)
+#define XEN_GUEST_HANDLE_PARAM(name)    XEN_GUEST_HANDLE(name)
 #define set_xen_guest_handle_raw(hnd, val)  do { (hnd).p = val; } while (0)
 #ifdef __XEN_TOOLS__
 #define get_xen_guest_handle(val, hnd)  do { val = (hnd).p; } while (0)
diff --git a/xen/include/xen/xencomm.h b/xen/include/xen/xencomm.h
index 730da7c..3426b8a 100644
--- a/xen/include/xen/xencomm.h
+++ b/xen/include/xen/xencomm.h
@@ -66,11 +66,31 @@ static inline unsigned long xencomm_inline_addr(const void *handle)
 /* Cast a guest handle to the specified type of handle. */
 #define guest_handle_cast(hnd, type) ({         \
     type *_x = (hnd).p;                         \
-    XEN_GUEST_HANDLE(type) _y;                  \
+    XEN_GUEST_HANDLE_PARAM(type) _y;            \
     set_xen_guest_handle(_y, _x);               \
     _y;                                         \
 })
 
+/* Cast a XEN_GUEST_HANDLE to XEN_GUEST_HANDLE_PARAM */
+#define guest_handle_to_param(hnd, type) ({                  \
+    /* type checking: make sure that the pointers inside     \
+     * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of    \
+     * the same type, then return hnd */                     \
+    (void)((typeof(&(hnd).p)) 0 ==                           \
+        (typeof(&((XEN_GUEST_HANDLE_PARAM(type)) {}).p)) 0); \
+    (hnd);                                                   \
+})
+
+/* Cast a XEN_GUEST_HANDLE_PARAM to XEN_GUEST_HANDLE */
+#define guest_handle_from_param(hnd, type) ({                \
+    /* type checking: make sure that the pointers inside     \
+     * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of    \
+     * the same type, then return hnd */                     \
+    (void)((typeof(&(hnd).p)) 0 ==                           \
+        (typeof(&((XEN_GUEST_HANDLE_PARAM(type)) {}).p)) 0); \
+    (hnd);                                                   \
+})
+
 /* Since we run in real mode, we can safely access all addresses. That also
  * means our __routines are identical to our "normal" routines. */
 #define guest_handle_okay(hnd, nr) 1
-- 
1.7.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 15:21:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 15:21:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNmTK-0004VO-Mi; Mon, 15 Oct 2012 15:20:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNmTI-0004Uy-Vq
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 15:20:49 +0000
Received: from [85.158.138.51:16710] by server-16.bemta-3.messagelabs.com id
	39/C0-16565-FC92C705; Mon, 15 Oct 2012 15:20:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1350314445!26846382!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODI0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2846 invoked from network); 15 Oct 2012 15:20:47 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 15:20:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,588,1344211200"; d="scan'208";a="211302567"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 15:20:45 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 11:20:45 -0400
Received: from [10.80.246.74] (helo=army.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TNmTE-0007YE-PW;
	Mon, 15 Oct 2012 16:20:44 +0100
From: Ian Campbell 
To: 
Date: Mon, 15 Oct 2012 15:20:37 +0000
Message-ID: <1350314444-17148-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
References: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Keir Fraser , Ian Campbell ,
	Stefano Stabellini ,
	Tim Deegan ,
	Stefano Stabellini ,
	Jan Beulich 
Subject: [Xen-devel] [PATCH 04/10] xen: xen_ulong_t substitution
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Stefano Stabellini 

There is still an unwanted unsigned long in the xen public interface:
replace it with xen_ulong_t.

Also typedef xen_ulong_t to uint64_t on ARM.

Signed-off-by: Stefano Stabellini 
Signed-off-by: Ian Campbell 
Cc: keir@xen.org
Cc: JBeulich@suse.com
---
Changes in v2:

- do not replace the unsigned long in x86 specific calls;
- do not replace the unsigned long in multicall_entry;
- add missing include "xen.h" in version.h;
- use proper printf flag for xen_ulong_t.
---
 tools/python/xen/lowlevel/xc/xc.c |    2 +-
 xen/include/public/arch-arm.h     |    3 ++-
 xen/include/public/arch-x86/xen.h |    1 +
 xen/include/public/version.h      |    4 +++-
 4 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/tools/python/xen/lowlevel/xc/xc.c b/tools/python/xen/lowlevel/xc/xc.c
index 7c89756..e220f68 100644
--- a/tools/python/xen/lowlevel/xc/xc.c
+++ b/tools/python/xen/lowlevel/xc/xc.c
@@ -1439,7 +1439,7 @@ static PyObject *pyxc_xeninfo(XcObject *self)
     if ( xc_version(self->xc_handle, XENVER_commandline, &xen_commandline) != 0 )
         return pyxc_error_to_exception(self->xc_handle);
 
-    snprintf(str, sizeof(str), "virt_start=0x%lx", p_parms.virt_start);
+    snprintf(str, sizeof(str), "virt_start=0x%"PRI_xen_ulong, p_parms.virt_start);
 
     xen_pagesize = xc_version(self->xc_handle, XENVER_pagesize, NULL);
     if (xen_pagesize < 0 )
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index e3d4ad9..2ae6548 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -122,7 +122,8 @@ typedef uint64_t xen_pfn_t;
 /* Only one. All other VCPUS must use VCPUOP_register_vcpu_info */
 #define XEN_LEGACY_MAX_VCPUS 1
 
-typedef uint32_t xen_ulong_t;
+typedef uint64_t xen_ulong_t;
+#define PRI_xen_ulong PRIx64
 
 struct vcpu_guest_context {
 #define _VGCF_online                   0
diff --git a/xen/include/public/arch-x86/xen.h b/xen/include/public/arch-x86/xen.h
index 1c186d7..fff8824 100644
--- a/xen/include/public/arch-x86/xen.h
+++ b/xen/include/public/arch-x86/xen.h
@@ -85,6 +85,7 @@ typedef unsigned long xen_pfn_t;
 #ifndef __ASSEMBLY__
 
 typedef unsigned long xen_ulong_t;
+#define PRI_xen_ulong "lx"
 
 /*
  * ` enum neg_errnoval
diff --git a/xen/include/public/version.h b/xen/include/public/version.h
index 8742c2b..c7e6f8c 100644
--- a/xen/include/public/version.h
+++ b/xen/include/public/version.h
@@ -28,6 +28,8 @@
 #ifndef __XEN_PUBLIC_VERSION_H__
 #define __XEN_PUBLIC_VERSION_H__
 
+#include "xen.h"
+
 /* NB. All ops return zero on success, except XENVER_{version,pagesize} */
 
 /* arg == NULL; returns major:minor (16:16). */
@@ -58,7 +60,7 @@ typedef char xen_changeset_info_t[64];
 
 #define XENVER_platform_parameters 5
 struct xen_platform_parameters {
-    unsigned long virt_start;
+    xen_ulong_t virt_start;
 };
 typedef struct xen_platform_parameters xen_platform_parameters_t;
 
-- 
1.7.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 15:21:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 15:21:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNmTK-0004VO-Mi; Mon, 15 Oct 2012 15:20:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNmTI-0004Uy-Vq
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 15:20:49 +0000
Received: from [85.158.138.51:16710] by server-16.bemta-3.messagelabs.com id
	39/C0-16565-FC92C705; Mon, 15 Oct 2012 15:20:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1350314445!26846382!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODI0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2846 invoked from network); 15 Oct 2012 15:20:47 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 15:20:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,588,1344211200"; d="scan'208";a="211302567"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 15:20:45 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 11:20:45 -0400
Received: from [10.80.246.74] (helo=army.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TNmTE-0007YE-PW;
	Mon, 15 Oct 2012 16:20:44 +0100
From: Ian Campbell 
To: 
Date: Mon, 15 Oct 2012 15:20:37 +0000
Message-ID: <1350314444-17148-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
References: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Keir Fraser , Ian Campbell ,
	Stefano Stabellini ,
	Tim Deegan ,
	Stefano Stabellini ,
	Jan Beulich 
Subject: [Xen-devel] [PATCH 04/10] xen: xen_ulong_t substitution
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Stefano Stabellini 

There is still an unwanted unsigned long in the xen public interface:
replace it with xen_ulong_t.

Also typedef xen_ulong_t to uint64_t on ARM.

Signed-off-by: Stefano Stabellini 
Signed-off-by: Ian Campbell 
Cc: keir@xen.org
Cc: JBeulich@suse.com
---
Changes in v2:

- do not replace the unsigned long in x86 specific calls;
- do not replace the unsigned long in multicall_entry;
- add missing include "xen.h" in version.h;
- use proper printf flag for xen_ulong_t.
---
 tools/python/xen/lowlevel/xc/xc.c |    2 +-
 xen/include/public/arch-arm.h     |    3 ++-
 xen/include/public/arch-x86/xen.h |    1 +
 xen/include/public/version.h      |    4 +++-
 4 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/tools/python/xen/lowlevel/xc/xc.c b/tools/python/xen/lowlevel/xc/xc.c
index 7c89756..e220f68 100644
--- a/tools/python/xen/lowlevel/xc/xc.c
+++ b/tools/python/xen/lowlevel/xc/xc.c
@@ -1439,7 +1439,7 @@ static PyObject *pyxc_xeninfo(XcObject *self)
     if ( xc_version(self->xc_handle, XENVER_commandline, &xen_commandline) != 0 )
         return pyxc_error_to_exception(self->xc_handle);
 
-    snprintf(str, sizeof(str), "virt_start=0x%lx", p_parms.virt_start);
+    snprintf(str, sizeof(str), "virt_start=0x%"PRI_xen_ulong, p_parms.virt_start);
 
     xen_pagesize = xc_version(self->xc_handle, XENVER_pagesize, NULL);
     if (xen_pagesize < 0 )
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index e3d4ad9..2ae6548 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -122,7 +122,8 @@ typedef uint64_t xen_pfn_t;
 /* Only one. All other VCPUS must use VCPUOP_register_vcpu_info */
 #define XEN_LEGACY_MAX_VCPUS 1
 
-typedef uint32_t xen_ulong_t;
+typedef uint64_t xen_ulong_t;
+#define PRI_xen_ulong PRIx64
 
 struct vcpu_guest_context {
 #define _VGCF_online                   0
diff --git a/xen/include/public/arch-x86/xen.h b/xen/include/public/arch-x86/xen.h
index 1c186d7..fff8824 100644
--- a/xen/include/public/arch-x86/xen.h
+++ b/xen/include/public/arch-x86/xen.h
@@ -85,6 +85,7 @@ typedef unsigned long xen_pfn_t;
 #ifndef __ASSEMBLY__
 
 typedef unsigned long xen_ulong_t;
+#define PRI_xen_ulong "lx"
 
 /*
  * ` enum neg_errnoval
diff --git a/xen/include/public/version.h b/xen/include/public/version.h
index 8742c2b..c7e6f8c 100644
--- a/xen/include/public/version.h
+++ b/xen/include/public/version.h
@@ -28,6 +28,8 @@
 #ifndef __XEN_PUBLIC_VERSION_H__
 #define __XEN_PUBLIC_VERSION_H__
 
+#include "xen.h"
+
 /* NB. All ops return zero on success, except XENVER_{version,pagesize} */
 
 /* arg == NULL; returns major:minor (16:16). */
@@ -58,7 +60,7 @@ typedef char xen_changeset_info_t[64];
 
 #define XENVER_platform_parameters 5
 struct xen_platform_parameters {
-    unsigned long virt_start;
+    xen_ulong_t virt_start;
 };
 typedef struct xen_platform_parameters xen_platform_parameters_t;
 
-- 
1.7.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 15:21:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 15:21:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNmTM-0004WB-TQ; Mon, 15 Oct 2012 15:20:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNmTK-0004VI-TA
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 15:20:51 +0000
Received: from [85.158.138.51:16891] by server-5.bemta-3.messagelabs.com id
	0B/F7-12440-2D92C705; Mon, 15 Oct 2012 15:20:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1350314445!26846382!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODI0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2977 invoked from network); 15 Oct 2012 15:20:49 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 15:20:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,588,1344211200"; d="scan'208";a="211302571"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 15:20:45 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 11:20:45 -0400
Received: from [10.80.246.74] (helo=army.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TNmTE-0007YE-TD;
	Mon, 15 Oct 2012 16:20:44 +0100
From: Ian Campbell 
To: 
Date: Mon, 15 Oct 2012 15:20:38 +0000
Message-ID: <1350314444-17148-5-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
References: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Keir Fraser , Ian Campbell ,
	Stefano Stabellini ,
	Tim Deegan ,
	Stefano Stabellini ,
	Jan Beulich 
Subject: [Xen-devel] [PATCH 05/10] xen: change the limit of nr_extents to
	UINT_MAX >> MEMOP_EXTENT_SHIFT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Stefano Stabellini 

Currently do_memory_op has a different maximum limit for nr_extents on
32 bit and 64 bit.
Change the limit to UINT_MAX >> MEMOP_EXTENT_SHIFT, so that it is the
same in both cases.

Signed-off-by: Stefano Stabellini 
Signed-off-by: Ian Campbell 
Cc: keir@xen.org
Cc: JBeulich@suse.com
---
 xen/common/memory.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/xen/common/memory.c b/xen/common/memory.c
index 5bcb035..401d06c 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -540,7 +540,7 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE(void) arg)
             return start_extent;
 
         /* Is size too large for us to encode a continuation? */
-        if ( reservation.nr_extents > (ULONG_MAX >> MEMOP_EXTENT_SHIFT) )
+        if ( reservation.nr_extents > (UINT_MAX >> MEMOP_EXTENT_SHIFT) )
             return start_extent;
 
         if ( unlikely(start_extent >= reservation.nr_extents) )
-- 
1.7.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 15:21:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 15:21:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNmTM-0004WB-TQ; Mon, 15 Oct 2012 15:20:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNmTK-0004VI-TA
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 15:20:51 +0000
Received: from [85.158.138.51:16891] by server-5.bemta-3.messagelabs.com id
	0B/F7-12440-2D92C705; Mon, 15 Oct 2012 15:20:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1350314445!26846382!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODI0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2977 invoked from network); 15 Oct 2012 15:20:49 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 15:20:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,588,1344211200"; d="scan'208";a="211302571"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 15:20:45 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 11:20:45 -0400
Received: from [10.80.246.74] (helo=army.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TNmTE-0007YE-TD;
	Mon, 15 Oct 2012 16:20:44 +0100
From: Ian Campbell 
To: 
Date: Mon, 15 Oct 2012 15:20:38 +0000
Message-ID: <1350314444-17148-5-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
References: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Keir Fraser , Ian Campbell ,
	Stefano Stabellini ,
	Tim Deegan ,
	Stefano Stabellini ,
	Jan Beulich 
Subject: [Xen-devel] [PATCH 05/10] xen: change the limit of nr_extents to
	UINT_MAX >> MEMOP_EXTENT_SHIFT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Stefano Stabellini 

Currently do_memory_op has a different maximum limit for nr_extents on
32 bit and 64 bit.
Change the limit to UINT_MAX >> MEMOP_EXTENT_SHIFT, so that it is the
same in both cases.

Signed-off-by: Stefano Stabellini 
Signed-off-by: Ian Campbell 
Cc: keir@xen.org
Cc: JBeulich@suse.com
---
 xen/common/memory.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/xen/common/memory.c b/xen/common/memory.c
index 5bcb035..401d06c 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -540,7 +540,7 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE(void) arg)
             return start_extent;
 
         /* Is size too large for us to encode a continuation? */
-        if ( reservation.nr_extents > (ULONG_MAX >> MEMOP_EXTENT_SHIFT) )
+        if ( reservation.nr_extents > (UINT_MAX >> MEMOP_EXTENT_SHIFT) )
             return start_extent;
 
         if ( unlikely(start_extent >= reservation.nr_extents) )
-- 
1.7.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 15:21:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 15:21:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNmTN-0004Wf-O2; Mon, 15 Oct 2012 15:20:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNmTL-0004VV-Gl
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 15:20:51 +0000
Received: from [85.158.138.51:16951] by server-8.bemta-3.messagelabs.com id
	FF/9D-10525-2D92C705; Mon, 15 Oct 2012 15:20:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1350314445!26846382!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODI0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3005 invoked from network); 15 Oct 2012 15:20:50 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 15:20:50 -0000
X-IronPort-AV: E=Sophos;i="4.80,588,1344211200"; d="scan'208";a="211302572"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 15:20:45 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 11:20:45 -0400
Received: from [10.80.246.74] (helo=army.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TNmTF-0007YE-9I;
	Mon, 15 Oct 2012 16:20:45 +0100
From: Ian Campbell 
To: 
Date: Mon, 15 Oct 2012 15:20:42 +0000
Message-ID: <1350314444-17148-9-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
References: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Keir Fraser , Ian Campbell ,
	Tim Deegan ,
	Stefano Stabellini ,
	Jan Beulich 
Subject: [Xen-devel] [PATCH 09/10] xen: remove XEN_GUEST_HANDLE(ulong)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Having both this handle (always unsigned long) and
XEN_GUEST_HANDLE(xen_ulong_t) (unsigned long on x86 and explicit size
of ARM) is confusing and error prone.

Replace the two remaining uses of the ulong handle, in grant set and
x86 set_gdt hypercalls, with xen_ulong_t.

This correctly sizes the grant frame entry as 64 bit on ARM but
leaves it as unsigned long on x86 (therefore no intended change on
x86). Likewise in set_gdt there is no actual change.

Signed-off-by: Ian Campbell 
Cc: keir@xen.org
Cc: JBeulich@suse.com
---
 xen/arch/x86/mm.c                |    3 ++-
 xen/common/grant_table.c         |    2 +-
 xen/include/asm-x86/hypercall.h  |    2 +-
 xen/include/public/grant_table.h |    2 +-
 xen/include/public/xen.h         |    2 --
 5 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 191f5ea..fad3d33 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4100,7 +4100,8 @@ long set_gdt(struct vcpu *v,
 }
 
 
-long do_set_gdt(XEN_GUEST_HANDLE_PARAM(ulong) frame_list, unsigned int entries)
+long do_set_gdt(XEN_GUEST_HANDLE_PARAM(xen_ulong_t) frame_list,
+                unsigned int entries)
 {
     int nr_pages = (entries + 511) / 512;
     unsigned long frames[16];
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index f4ae9ee..7912769 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -1322,7 +1322,7 @@ gnttab_setup_table(
     struct domain *d;
     struct grant_table *gt;
     int            i;
-    unsigned long  gmfn;
+    xen_pfn_t  gmfn;
 
     if ( count != 1 )
         return -EINVAL;
diff --git a/xen/include/asm-x86/hypercall.h b/xen/include/asm-x86/hypercall.h
index bd14220..afa8ba9 100644
--- a/xen/include/asm-x86/hypercall.h
+++ b/xen/include/asm-x86/hypercall.h
@@ -33,7 +33,7 @@ do_mmu_update(
 
 extern long
 do_set_gdt(
-    XEN_GUEST_HANDLE_PARAM(ulong) frame_list,
+    XEN_GUEST_HANDLE_PARAM(xen_ulong_t) frame_list,
     unsigned int entries);
 
 extern long
diff --git a/xen/include/public/grant_table.h b/xen/include/public/grant_table.h
index 28d9476..13cc559 100644
--- a/xen/include/public/grant_table.h
+++ b/xen/include/public/grant_table.h
@@ -385,7 +385,7 @@ struct gnttab_setup_table {
     uint32_t nr_frames;
     /* OUT parameters. */
     int16_t  status;              /* => enum grant_status */
-    XEN_GUEST_HANDLE(ulong) frame_list;
+    XEN_GUEST_HANDLE(xen_pfn_t) frame_list;
 };
 typedef struct gnttab_setup_table gnttab_setup_table_t;
 DEFINE_XEN_GUEST_HANDLE(gnttab_setup_table_t);
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index e42d01f..9a5b394 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -43,8 +43,6 @@ DEFINE_XEN_GUEST_HANDLE(char);
 __DEFINE_XEN_GUEST_HANDLE(uchar, unsigned char);
 DEFINE_XEN_GUEST_HANDLE(int);
 __DEFINE_XEN_GUEST_HANDLE(uint,  unsigned int);
-DEFINE_XEN_GUEST_HANDLE(long);
-__DEFINE_XEN_GUEST_HANDLE(ulong, unsigned long);
 DEFINE_XEN_GUEST_HANDLE(void);
 
 DEFINE_XEN_GUEST_HANDLE(uint64_t);
-- 
1.7.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 15:21:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 15:21:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNmTO-0004XP-PV; Mon, 15 Oct 2012 15:20:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNmTM-0004W7-TT
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 15:20:53 +0000
Received: from [85.158.138.51:17021] by server-10.bemta-3.messagelabs.com id
	3D/8E-27386-3D92C705; Mon, 15 Oct 2012 15:20:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1350314445!26846382!6
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODI0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3059 invoked from network); 15 Oct 2012 15:20:51 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 15:20:51 -0000
X-IronPort-AV: E=Sophos;i="4.80,588,1344211200"; d="scan'208";a="211302574"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 15:20:46 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 11:20:45 -0400
Received: from [10.80.246.74] (helo=army.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TNmTF-0007YE-5i;
	Mon, 15 Oct 2012 16:20:45 +0100
From: Ian Campbell 
To: 
Date: Mon, 15 Oct 2012 15:20:41 +0000
Message-ID: <1350314444-17148-8-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
References: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Keir Fraser , Ian Campbell ,
	Stefano Stabellini ,
	Tim Deegan ,
	Stefano Stabellini ,
	Jan Beulich 
Subject: [Xen-devel] [PATCH 08/10] xen: more XEN_GUEST_HANDLE_PARAM
	substitutions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Stefano Stabellini 

More substitutions in this patch, not as obvious as the ones in the
previous patch.

Signed-off-by: Stefano Stabellini 
Signed-off-by: Ian Campbell 
Cc: keir@xen.org
Cc: JBeulich@suse.com
---
ijc v2:
  - Avoid _t suffix on variable names, use _param instead.
---
 xen/arch/x86/mm.c                        |   12 +++++++++---
 xen/arch/x86/oprofile/backtrace.c        |    5 ++++-
 xen/arch/x86/platform_hypercall.c        |   10 +++++++---
 xen/arch/x86/x86_64/cpu_idle.c           |    4 +++-
 xen/arch/x86/x86_64/cpufreq.c            |    4 +++-
 xen/arch/x86/x86_64/platform_hypercall.c |    1 +
 xen/common/compat/multicall.c            |    1 +
 xen/common/multicall.c                   |    2 +-
 8 files changed, 29 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 9a828de..191f5ea 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2913,7 +2913,9 @@ long do_mmuext_op(
         {
             cpumask_t pmask;
 
-            if ( unlikely(vcpumask_to_pcpumask(d, op.arg2.vcpumask, &pmask)) )
+            if ( unlikely(vcpumask_to_pcpumask(d,
+                            guest_handle_to_param(op.arg2.vcpumask, const_void),
+                            &pmask)) )
             {
                 okay = 0;
                 break;
@@ -4195,6 +4197,7 @@ static int handle_iomem_range(unsigned long s, unsigned long e, void *p)
     if ( s > ctxt->s )
     {
         e820entry_t ent;
+        XEN_GUEST_HANDLE_PARAM(e820entry_t) buffer_param;
         XEN_GUEST_HANDLE(e820entry_t) buffer;
 
         if ( ctxt->n + 1 >= ctxt->map.nr_entries )
@@ -4202,7 +4205,8 @@ static int handle_iomem_range(unsigned long s, unsigned long e, void *p)
         ent.addr = (uint64_t)ctxt->s << PAGE_SHIFT;
         ent.size = (uint64_t)(s - ctxt->s) << PAGE_SHIFT;
         ent.type = E820_RESERVED;
-        buffer = guest_handle_cast(ctxt->map.buffer, e820entry_t);
+        buffer_param = guest_handle_cast(ctxt->map.buffer, e820entry_t);
+        buffer = guest_handle_from_param(buffer_param, e820entry_t);
         if ( __copy_to_guest_offset(buffer, ctxt->n, &ent, 1) )
             return -EFAULT;
         ctxt->n++;
@@ -4499,6 +4503,7 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg)
     {
         struct memory_map_context ctxt;
         XEN_GUEST_HANDLE(e820entry_t) buffer;
+        XEN_GUEST_HANDLE_PARAM(e820entry_t) buffer_param;
         unsigned int i;
 
         if ( !IS_PRIV(current->domain) )
@@ -4513,7 +4518,8 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg)
         if ( ctxt.map.nr_entries < e820.nr_map + 1 )
             return -EINVAL;
 
-        buffer = guest_handle_cast(ctxt.map.buffer, e820entry_t);
+        buffer_param = guest_handle_cast(ctxt.map.buffer, e820entry_t);
+        buffer = guest_handle_from_param(buffer_param, e820entry_t);
         if ( !guest_handle_okay(buffer, ctxt.map.nr_entries) )
             return -EFAULT;
 
diff --git a/xen/arch/x86/oprofile/backtrace.c b/xen/arch/x86/oprofile/backtrace.c
index 433f881..b3ea7f3 100644
--- a/xen/arch/x86/oprofile/backtrace.c
+++ b/xen/arch/x86/oprofile/backtrace.c
@@ -74,8 +74,11 @@ dump_guest_backtrace(struct vcpu *vcpu, const struct frame_head *head,
     }
     else
     {
-        XEN_GUEST_HANDLE(const_frame_head_t) guest_head =
+        XEN_GUEST_HANDLE(const_frame_head_t) guest_head;
+        XEN_GUEST_HANDLE_PARAM(const_frame_head_t) guest_head_param =
             const_guest_handle_from_ptr(head, frame_head_t);
+        guest_head = guest_handle_from_param(guest_head_param,
+					     const_frame_head_t);
 
         /* Also check accessibility of one struct frame_head beyond */
         if (!guest_handle_okay(guest_head, 2))
diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hypercall.c
index 073a2ea..a3b5a6b 100644
--- a/xen/arch/x86/platform_hypercall.c
+++ b/xen/arch/x86/platform_hypercall.c
@@ -61,7 +61,7 @@ long cpu_down_helper(void *data);
 long core_parking_helper(void *data);
 uint32_t get_cur_idle_nums(void);
 
-ret_t do_platform_op(XEN_GUEST_HANDLE(xen_platform_op_t) u_xenpf_op)
+ret_t do_platform_op(XEN_GUEST_HANDLE_PARAM(xen_platform_op_t) u_xenpf_op)
 {
     ret_t ret = 0;
     struct xen_platform_op curop, *op = &curop;
@@ -186,7 +186,9 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xen_platform_op_t) u_xenpf_op)
             }
         }
 
-        ret = microcode_update(data, op->u.microcode.length);
+        ret = microcode_update(
+                guest_handle_to_param(data, const_void),
+                op->u.microcode.length);
         spin_unlock(&vcpu_alloc_lock);
     }
     break;
@@ -454,7 +456,9 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xen_platform_op_t) u_xenpf_op)
             XEN_GUEST_HANDLE(uint32) pdc;
 
             guest_from_compat_handle(pdc, op->u.set_pminfo.u.pdc);
-            ret = acpi_set_pdc_bits(op->u.set_pminfo.id, pdc);
+            ret = acpi_set_pdc_bits(
+                    op->u.set_pminfo.id,
+                    guest_handle_to_param(pdc, uint32));
         }
         break;
 
diff --git a/xen/arch/x86/x86_64/cpu_idle.c b/xen/arch/x86/x86_64/cpu_idle.c
index 3e7422f..dfc7e84 100644
--- a/xen/arch/x86/x86_64/cpu_idle.c
+++ b/xen/arch/x86/x86_64/cpu_idle.c
@@ -57,10 +57,12 @@ static int copy_from_compat_state(xen_processor_cx_t *xen_state,
 {
 #define XLAT_processor_cx_HNDL_dp(_d_, _s_) do { \
     XEN_GUEST_HANDLE(compat_processor_csd_t) dps; \
+    XEN_GUEST_HANDLE_PARAM(xen_processor_csd_t) dps_param; \
     if ( unlikely(!compat_handle_okay((_s_)->dp, (_s_)->dpcnt)) ) \
             return -EFAULT; \
     guest_from_compat_handle(dps, (_s_)->dp); \
-    (_d_)->dp = guest_handle_cast(dps, xen_processor_csd_t); \
+    dps_param = guest_handle_cast(dps, xen_processor_csd_t); \
+    (_d_)->dp = guest_handle_from_param(dps_param, xen_processor_csd_t); \
 } while (0)
     XLAT_processor_cx(xen_state, state);
 #undef XLAT_processor_cx_HNDL_dp
diff --git a/xen/arch/x86/x86_64/cpufreq.c b/xen/arch/x86/x86_64/cpufreq.c
index ce9864e..1956777 100644
--- a/xen/arch/x86/x86_64/cpufreq.c
+++ b/xen/arch/x86/x86_64/cpufreq.c
@@ -45,10 +45,12 @@ compat_set_px_pminfo(uint32_t cpu, struct compat_processor_performance *perf)
 
 #define XLAT_processor_performance_HNDL_states(_d_, _s_) do { \
     XEN_GUEST_HANDLE(compat_processor_px_t) states; \
+    XEN_GUEST_HANDLE_PARAM(xen_processor_px_t) states_t; \
     if ( unlikely(!compat_handle_okay((_s_)->states, (_s_)->state_count)) ) \
         return -EFAULT; \
     guest_from_compat_handle(states, (_s_)->states); \
-    (_d_)->states = guest_handle_cast(states, xen_processor_px_t); \
+    states_t = guest_handle_cast(states, xen_processor_px_t); \
+    (_d_)->states = guest_handle_from_param(states_t, xen_processor_px_t); \
 } while (0)
 
     XLAT_processor_performance(xen_perf, perf);
diff --git a/xen/arch/x86/x86_64/platform_hypercall.c b/xen/arch/x86/x86_64/platform_hypercall.c
index 188aa37..744796d 100644
--- a/xen/arch/x86/x86_64/platform_hypercall.c
+++ b/xen/arch/x86/x86_64/platform_hypercall.c
@@ -38,6 +38,7 @@ CHECK_pf_pcpu_version;
 
 #define COMPAT
 #define _XEN_GUEST_HANDLE(t) XEN_GUEST_HANDLE(t)
+#define _XEN_GUEST_HANDLE_PARAM(t) XEN_GUEST_HANDLE_PARAM(t)
 typedef int ret_t;
 
 #include "../platform_hypercall.c"
diff --git a/xen/common/compat/multicall.c b/xen/common/compat/multicall.c
index e7e2a40..3219d3c 100644
--- a/xen/common/compat/multicall.c
+++ b/xen/common/compat/multicall.c
@@ -25,6 +25,7 @@ DEFINE_XEN_GUEST_HANDLE(multicall_entry_compat_t);
 #define call                 compat_call
 #define do_multicall(l, n)   compat_multicall(_##l, n)
 #define _XEN_GUEST_HANDLE(t) XEN_GUEST_HANDLE(t)
+#define _XEN_GUEST_HANDLE_PARAM(t) XEN_GUEST_HANDLE(t)
 
 static void __trace_multicall_call(multicall_entry_t *call)
 {
diff --git a/xen/common/multicall.c b/xen/common/multicall.c
index ca1839d..7e557e5 100644
--- a/xen/common/multicall.c
+++ b/xen/common/multicall.c
@@ -35,7 +35,7 @@ static void trace_multicall_call(multicall_entry_t *call)
 
 ret_t
 do_multicall(
-    XEN_GUEST_HANDLE(multicall_entry_t) call_list, unsigned int nr_calls)
+    XEN_GUEST_HANDLE_PARAM(multicall_entry_t) call_list, unsigned int nr_calls)
 {
     struct mc_state *mcs = ¤t->mc_state;
     unsigned int     i;
-- 
1.7.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 15:21:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 15:21:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNmTN-0004Wf-O2; Mon, 15 Oct 2012 15:20:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNmTL-0004VV-Gl
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 15:20:51 +0000
Received: from [85.158.138.51:16951] by server-8.bemta-3.messagelabs.com id
	FF/9D-10525-2D92C705; Mon, 15 Oct 2012 15:20:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1350314445!26846382!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODI0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3005 invoked from network); 15 Oct 2012 15:20:50 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 15:20:50 -0000
X-IronPort-AV: E=Sophos;i="4.80,588,1344211200"; d="scan'208";a="211302572"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 15:20:45 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 11:20:45 -0400
Received: from [10.80.246.74] (helo=army.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TNmTF-0007YE-9I;
	Mon, 15 Oct 2012 16:20:45 +0100
From: Ian Campbell 
To: 
Date: Mon, 15 Oct 2012 15:20:42 +0000
Message-ID: <1350314444-17148-9-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
References: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Keir Fraser , Ian Campbell ,
	Tim Deegan ,
	Stefano Stabellini ,
	Jan Beulich 
Subject: [Xen-devel] [PATCH 09/10] xen: remove XEN_GUEST_HANDLE(ulong)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Having both this handle (always unsigned long) and
XEN_GUEST_HANDLE(xen_ulong_t) (unsigned long on x86 and explicit size
of ARM) is confusing and error prone.

Replace the two remaining uses of the ulong handle, in grant set and
x86 set_gdt hypercalls, with xen_ulong_t.

This correctly sizes the grant frame entry as 64 bit on ARM but
leaves it as unsigned long on x86 (therefore no intended change on
x86). Likewise in set_gdt there is no actual change.

Signed-off-by: Ian Campbell 
Cc: keir@xen.org
Cc: JBeulich@suse.com
---
 xen/arch/x86/mm.c                |    3 ++-
 xen/common/grant_table.c         |    2 +-
 xen/include/asm-x86/hypercall.h  |    2 +-
 xen/include/public/grant_table.h |    2 +-
 xen/include/public/xen.h         |    2 --
 5 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 191f5ea..fad3d33 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4100,7 +4100,8 @@ long set_gdt(struct vcpu *v,
 }
 
 
-long do_set_gdt(XEN_GUEST_HANDLE_PARAM(ulong) frame_list, unsigned int entries)
+long do_set_gdt(XEN_GUEST_HANDLE_PARAM(xen_ulong_t) frame_list,
+                unsigned int entries)
 {
     int nr_pages = (entries + 511) / 512;
     unsigned long frames[16];
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index f4ae9ee..7912769 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -1322,7 +1322,7 @@ gnttab_setup_table(
     struct domain *d;
     struct grant_table *gt;
     int            i;
-    unsigned long  gmfn;
+    xen_pfn_t  gmfn;
 
     if ( count != 1 )
         return -EINVAL;
diff --git a/xen/include/asm-x86/hypercall.h b/xen/include/asm-x86/hypercall.h
index bd14220..afa8ba9 100644
--- a/xen/include/asm-x86/hypercall.h
+++ b/xen/include/asm-x86/hypercall.h
@@ -33,7 +33,7 @@ do_mmu_update(
 
 extern long
 do_set_gdt(
-    XEN_GUEST_HANDLE_PARAM(ulong) frame_list,
+    XEN_GUEST_HANDLE_PARAM(xen_ulong_t) frame_list,
     unsigned int entries);
 
 extern long
diff --git a/xen/include/public/grant_table.h b/xen/include/public/grant_table.h
index 28d9476..13cc559 100644
--- a/xen/include/public/grant_table.h
+++ b/xen/include/public/grant_table.h
@@ -385,7 +385,7 @@ struct gnttab_setup_table {
     uint32_t nr_frames;
     /* OUT parameters. */
     int16_t  status;              /* => enum grant_status */
-    XEN_GUEST_HANDLE(ulong) frame_list;
+    XEN_GUEST_HANDLE(xen_pfn_t) frame_list;
 };
 typedef struct gnttab_setup_table gnttab_setup_table_t;
 DEFINE_XEN_GUEST_HANDLE(gnttab_setup_table_t);
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index e42d01f..9a5b394 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -43,8 +43,6 @@ DEFINE_XEN_GUEST_HANDLE(char);
 __DEFINE_XEN_GUEST_HANDLE(uchar, unsigned char);
 DEFINE_XEN_GUEST_HANDLE(int);
 __DEFINE_XEN_GUEST_HANDLE(uint,  unsigned int);
-DEFINE_XEN_GUEST_HANDLE(long);
-__DEFINE_XEN_GUEST_HANDLE(ulong, unsigned long);
 DEFINE_XEN_GUEST_HANDLE(void);
 
 DEFINE_XEN_GUEST_HANDLE(uint64_t);
-- 
1.7.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 15:21:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 15:21:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNmTQ-0004Yq-S2; Mon, 15 Oct 2012 15:20:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNmTP-0004VD-4Z
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 15:20:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1350314446!8639953!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYzNjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22232 invoked from network); 15 Oct 2012 15:20:48 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 15:20:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,588,1344211200"; d="scan'208";a="41237265"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 15:20:46 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 11:20:45 -0400
Received: from [10.80.246.74] (helo=army.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TNmTF-0007YE-2K;
	Mon, 15 Oct 2012 16:20:45 +0100
From: Ian Campbell 
To: 
Date: Mon, 15 Oct 2012 15:20:40 +0000
Message-ID: <1350314444-17148-7-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
References: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Keir Fraser , Ian Campbell ,
	Stefano Stabellini ,
	Tim Deegan ,
	Stefano Stabellini ,
	Jan Beulich 
Subject: [Xen-devel] [PATCH 07/10] xen: replace XEN_GUEST_HANDLE with
	XEN_GUEST_HANDLE_PARAM when appropriate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Stefano Stabellini 

Note: these changes don't make any difference on x86.

Replace XEN_GUEST_HANDLE with XEN_GUEST_HANDLE_PARAM when it is used as
an hypercall argument.

Signed-off-by: Stefano Stabellini 
Signed-off-by: Ian Campbell 
Cc: keir@xen.org
Cc: JBeulich@suse.com
---
ijc v2: - correct usage of guest handle paramters in tmem
        - defer some changes to next patch to avoid temporarily
          breaking the build.
---
 xen/arch/arm/domain.c            |    2 +-
 xen/arch/arm/domctl.c            |    2 +-
 xen/arch/arm/hvm.c               |    2 +-
 xen/arch/arm/mm.c                |    2 +-
 xen/arch/arm/physdev.c           |    2 +-
 xen/arch/arm/sysctl.c            |    2 +-
 xen/arch/x86/compat.c            |    2 +-
 xen/arch/x86/cpu/mcheck/mce.c    |    2 +-
 xen/arch/x86/domain.c            |    2 +-
 xen/arch/x86/domctl.c            |    2 +-
 xen/arch/x86/efi/runtime.c       |    2 +-
 xen/arch/x86/hvm/hvm.c           |   26 +++++++++---------
 xen/arch/x86/microcode.c         |    2 +-
 xen/arch/x86/mm.c                |   14 +++++-----
 xen/arch/x86/mm/hap/hap.c        |    2 +-
 xen/arch/x86/mm/mem_event.c      |    2 +-
 xen/arch/x86/mm/paging.c         |    2 +-
 xen/arch/x86/mm/shadow/common.c  |    2 +-
 xen/arch/x86/oprofile/xenoprof.c |    6 ++--
 xen/arch/x86/physdev.c           |    2 +-
 xen/arch/x86/sysctl.c            |    2 +-
 xen/arch/x86/traps.c             |    2 +-
 xen/arch/x86/x86_64/compat/mm.c  |   10 +++---
 xen/arch/x86/x86_64/domain.c     |    2 +-
 xen/arch/x86/x86_64/mm.c         |    2 +-
 xen/arch/x86/x86_64/traps.c      |    2 +-
 xen/common/compat/domain.c       |    2 +-
 xen/common/compat/grant_table.c  |    8 +++---
 xen/common/compat/memory.c       |    4 +-
 xen/common/domain.c              |    2 +-
 xen/common/domctl.c              |    2 +-
 xen/common/event_channel.c       |    2 +-
 xen/common/grant_table.c         |   36 +++++++++++++-------------
 xen/common/kernel.c              |    4 +-
 xen/common/kexec.c               |   17 ++++++------
 xen/common/memory.c              |    4 +-
 xen/common/schedule.c            |    2 +-
 xen/common/sysctl.c              |    2 +-
 xen/common/tmem.c                |   45 ++++++++++++++++++--------------
 xen/common/tmem_xen.c            |    8 +++---
 xen/common/xenoprof.c            |    8 +++---
 xen/drivers/acpi/pmstat.c        |    2 +-
 xen/drivers/char/console.c       |    6 ++--
 xen/drivers/passthrough/iommu.c  |    2 +-
 xen/include/asm-arm/hypercall.h  |    2 +-
 xen/include/asm-arm/mm.h         |    2 +-
 xen/include/asm-x86/hap.h        |    2 +-
 xen/include/asm-x86/hypercall.h  |   22 ++++++++--------
 xen/include/asm-x86/mem_event.h  |    2 +-
 xen/include/asm-x86/mm.h         |    8 +++---
 xen/include/asm-x86/paging.h     |    2 +-
 xen/include/asm-x86/processor.h  |    2 +-
 xen/include/asm-x86/shadow.h     |    2 +-
 xen/include/asm-x86/xenoprof.h   |    6 ++--
 xen/include/xen/acpi.h           |    4 +-
 xen/include/xen/compat.h         |    3 ++
 xen/include/xen/hypercall.h      |   52 +++++++++++++++++++-------------------
 xen/include/xen/iommu.h          |    2 +-
 xen/include/xen/tmem_xen.h       |   18 ++++++++-----
 xen/include/xsm/xsm.h            |    4 +-
 xen/xsm/dummy.c                  |    2 +-
 xen/xsm/flask/flask_op.c         |    4 +-
 xen/xsm/flask/hooks.c            |    2 +-
 xen/xsm/xsm_core.c               |    2 +-
 64 files changed, 206 insertions(+), 193 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index f47db4f..c5292c7 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -519,7 +519,7 @@ void arch_dump_domain_info(struct domain *d)
 {
 }
 
-long arch_do_vcpu_op(int cmd, struct vcpu *v, XEN_GUEST_HANDLE(void) arg)
+long arch_do_vcpu_op(int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     return -ENOSYS;
 }
diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
index 1a5f79f..cf16791 100644
--- a/xen/arch/arm/domctl.c
+++ b/xen/arch/arm/domctl.c
@@ -11,7 +11,7 @@
 #include 
 
 long arch_do_domctl(struct xen_domctl *domctl,
-                    XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
+                    XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
 {
     return -ENOSYS;
 }
diff --git a/xen/arch/arm/hvm.c b/xen/arch/arm/hvm.c
index c11378d..40f519e 100644
--- a/xen/arch/arm/hvm.c
+++ b/xen/arch/arm/hvm.c
@@ -11,7 +11,7 @@
 
 #include 
 
-long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
+long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
 
 {
     long rc = 0;
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index edd5ca7..e8fff8f 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -579,7 +579,7 @@ out:
 
 }
 
-long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
+long arch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     int rc;
 
diff --git a/xen/arch/arm/physdev.c b/xen/arch/arm/physdev.c
index bcf4337..0801e8c 100644
--- a/xen/arch/arm/physdev.c
+++ b/xen/arch/arm/physdev.c
@@ -11,7 +11,7 @@
 #include 
 
 
-int do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
+int do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     printk("%s %d cmd=%d: not implemented yet\n", __func__, __LINE__, cmd);
     return -ENOSYS;
diff --git a/xen/arch/arm/sysctl.c b/xen/arch/arm/sysctl.c
index e8e1c0d..a286abe 100644
--- a/xen/arch/arm/sysctl.c
+++ b/xen/arch/arm/sysctl.c
@@ -13,7 +13,7 @@
 #include 
 
 long arch_do_sysctl(struct xen_sysctl *sysctl,
-                    XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl)
+                    XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
 {
     return -ENOSYS;
 }
diff --git a/xen/arch/x86/compat.c b/xen/arch/x86/compat.c
index a4fda06..2d05867 100644
--- a/xen/arch/x86/compat.c
+++ b/xen/arch/x86/compat.c
@@ -27,7 +27,7 @@ ret_t do_physdev_op_compat(XEN_GUEST_HANDLE(physdev_op_t) uop)
 #ifndef COMPAT
 
 /* Legacy hypercall (as of 0x00030202). */
-long do_event_channel_op_compat(XEN_GUEST_HANDLE(evtchn_op_t) uop)
+long do_event_channel_op_compat(XEN_GUEST_HANDLE_PARAM(evtchn_op_t) uop)
 {
     struct evtchn_op op;
 
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index 6f8c6f9..75f0f73 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -1289,7 +1289,7 @@ CHECK_mcinfo_recovery;
 # undef xen_mcinfo_recovery
 
 /* Machine Check Architecture Hypercall */
-long do_mca(XEN_GUEST_HANDLE(xen_mc_t) u_xen_mc)
+long do_mca(XEN_GUEST_HANDLE_PARAM(xen_mc_t) u_xen_mc)
 {
     long ret = 0;
     struct xen_mc curop, *op = &curop;
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 58766ba..233c597 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1077,7 +1077,7 @@ map_vcpu_info(struct vcpu *v, unsigned long gfn, unsigned offset)
 
 long
 arch_do_vcpu_op(
-    int cmd, struct vcpu *v, XEN_GUEST_HANDLE(void) arg)
+    int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     long rc = 0;
 
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 24b3178..c3d6093 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -48,7 +48,7 @@ static int gdbsx_guest_mem_io(
 
 long arch_do_domctl(
     struct xen_domctl *domctl,
-    XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
+    XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
 {
     long ret = 0;
 
diff --git a/xen/arch/x86/efi/runtime.c b/xen/arch/x86/efi/runtime.c
index 1dbe2db..b2ff495 100644
--- a/xen/arch/x86/efi/runtime.c
+++ b/xen/arch/x86/efi/runtime.c
@@ -184,7 +184,7 @@ int efi_get_info(uint32_t idx, union xenpf_efi_info *info)
     return 0;
 }
 
-static long gwstrlen(XEN_GUEST_HANDLE(CHAR16) str)
+static long gwstrlen(XEN_GUEST_HANDLE_PARAM(CHAR16) str)
 {
     unsigned long len;
 
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index a5a1bcf..b83e336 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3091,14 +3091,14 @@ static int grant_table_op_is_allowed(unsigned int cmd)
 }
 
 static long hvm_grant_table_op(
-    unsigned int cmd, XEN_GUEST_HANDLE(void) uop, unsigned int count)
+    unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) uop, unsigned int count)
 {
     if ( !grant_table_op_is_allowed(cmd) )
         return -ENOSYS; /* all other commands need auditing */
     return do_grant_table_op(cmd, uop, count);
 }
 
-static long hvm_memory_op(int cmd, XEN_GUEST_HANDLE(void) arg)
+static long hvm_memory_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     long rc;
 
@@ -3116,7 +3116,7 @@ static long hvm_memory_op(int cmd, XEN_GUEST_HANDLE(void) arg)
     return do_memory_op(cmd, arg);
 }
 
-static long hvm_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
+static long hvm_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     switch ( cmd )
     {
@@ -3132,7 +3132,7 @@ static long hvm_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
 }
 
 static long hvm_vcpu_op(
-    int cmd, int vcpuid, XEN_GUEST_HANDLE(void) arg)
+    int cmd, int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     long rc;
 
@@ -3163,7 +3163,7 @@ typedef unsigned long hvm_hypercall_t(
     [ __HYPERVISOR_ ## x ] = (hvm_hypercall_t *) do_ ## x
 
 static long hvm_grant_table_op_compat32(unsigned int cmd,
-                                        XEN_GUEST_HANDLE(void) uop,
+                                        XEN_GUEST_HANDLE_PARAM(void) uop,
                                         unsigned int count)
 {
     if ( !grant_table_op_is_allowed(cmd) )
@@ -3171,7 +3171,7 @@ static long hvm_grant_table_op_compat32(unsigned int cmd,
     return compat_grant_table_op(cmd, uop, count);
 }
 
-static long hvm_memory_op_compat32(int cmd, XEN_GUEST_HANDLE(void) arg)
+static long hvm_memory_op_compat32(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     int rc;
 
@@ -3190,7 +3190,7 @@ static long hvm_memory_op_compat32(int cmd, XEN_GUEST_HANDLE(void) arg)
 }
 
 static long hvm_vcpu_op_compat32(
-    int cmd, int vcpuid, XEN_GUEST_HANDLE(void) arg)
+    int cmd, int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     long rc;
 
@@ -3214,7 +3214,7 @@ static long hvm_vcpu_op_compat32(
 }
 
 static long hvm_physdev_op_compat32(
-    int cmd, XEN_GUEST_HANDLE(void) arg)
+    int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     switch ( cmd )
     {
@@ -3380,7 +3380,7 @@ void hvm_hypercall_page_initialise(struct domain *d,
 }
 
 static int hvmop_set_pci_intx_level(
-    XEN_GUEST_HANDLE(xen_hvm_set_pci_intx_level_t) uop)
+    XEN_GUEST_HANDLE_PARAM(xen_hvm_set_pci_intx_level_t) uop)
 {
     struct xen_hvm_set_pci_intx_level op;
     struct domain *d;
@@ -3547,7 +3547,7 @@ static void hvm_s3_resume(struct domain *d)
 }
 
 static int hvmop_set_isa_irq_level(
-    XEN_GUEST_HANDLE(xen_hvm_set_isa_irq_level_t) uop)
+    XEN_GUEST_HANDLE_PARAM(xen_hvm_set_isa_irq_level_t) uop)
 {
     struct xen_hvm_set_isa_irq_level op;
     struct domain *d;
@@ -3591,7 +3591,7 @@ static int hvmop_set_isa_irq_level(
 }
 
 static int hvmop_set_pci_link_route(
-    XEN_GUEST_HANDLE(xen_hvm_set_pci_link_route_t) uop)
+    XEN_GUEST_HANDLE_PARAM(xen_hvm_set_pci_link_route_t) uop)
 {
     struct xen_hvm_set_pci_link_route op;
     struct domain *d;
@@ -3624,7 +3624,7 @@ static int hvmop_set_pci_link_route(
 }
 
 static int hvmop_inject_msi(
-    XEN_GUEST_HANDLE(xen_hvm_inject_msi_t) uop)
+    XEN_GUEST_HANDLE_PARAM(xen_hvm_inject_msi_t) uop)
 {
     struct xen_hvm_inject_msi op;
     struct domain *d;
@@ -3708,7 +3708,7 @@ static int hvm_replace_event_channel(struct vcpu *v, domid_t remote_domid,
     return 0;
 }
 
-long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
+long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
 
 {
     struct domain *curr_d = current->domain;
diff --git a/xen/arch/x86/microcode.c b/xen/arch/x86/microcode.c
index fe51034..fbbf95b 100644
--- a/xen/arch/x86/microcode.c
+++ b/xen/arch/x86/microcode.c
@@ -195,7 +195,7 @@ static long do_microcode_update(void *_info)
     return error;
 }
 
-int microcode_update(XEN_GUEST_HANDLE(const_void) buf, unsigned long len)
+int microcode_update(XEN_GUEST_HANDLE_PARAM(const_void) buf, unsigned long len)
 {
     int ret;
     struct microcode_info *info;
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 8ab92c9..9a828de 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2652,7 +2652,7 @@ static void put_pg_owner(struct domain *pg_owner)
 }
 
 static inline int vcpumask_to_pcpumask(
-    struct domain *d, XEN_GUEST_HANDLE(const_void) bmap, cpumask_t *pmask)
+    struct domain *d, XEN_GUEST_HANDLE_PARAM(const_void) bmap, cpumask_t *pmask)
 {
     unsigned int vcpu_id, vcpu_bias, offs;
     unsigned long vmask;
@@ -2692,9 +2692,9 @@ static inline int vcpumask_to_pcpumask(
 #define fixunmap_domain_page(ptr) ((void)(ptr))
 
 long do_mmuext_op(
-    XEN_GUEST_HANDLE(mmuext_op_t) uops,
+    XEN_GUEST_HANDLE_PARAM(mmuext_op_t) uops,
     unsigned int count,
-    XEN_GUEST_HANDLE(uint) pdone,
+    XEN_GUEST_HANDLE_PARAM(uint) pdone,
     unsigned int foreigndom)
 {
     struct mmuext_op op;
@@ -3151,9 +3151,9 @@ long do_mmuext_op(
 }
 
 long do_mmu_update(
-    XEN_GUEST_HANDLE(mmu_update_t) ureqs,
+    XEN_GUEST_HANDLE_PARAM(mmu_update_t) ureqs,
     unsigned int count,
-    XEN_GUEST_HANDLE(uint) pdone,
+    XEN_GUEST_HANDLE_PARAM(uint) pdone,
     unsigned int foreigndom)
 {
     struct mmu_update req;
@@ -4098,7 +4098,7 @@ long set_gdt(struct vcpu *v,
 }
 
 
-long do_set_gdt(XEN_GUEST_HANDLE(ulong) frame_list, unsigned int entries)
+long do_set_gdt(XEN_GUEST_HANDLE_PARAM(ulong) frame_list, unsigned int entries)
 {
     int nr_pages = (entries + 511) / 512;
     unsigned long frames[16];
@@ -4370,7 +4370,7 @@ static int xenmem_add_to_physmap(struct domain *d,
     return xenmem_add_to_physmap_once(d, xatp);
 }
 
-long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
+long arch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     int rc;
 
diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index d2637d3..fd99cde 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -571,7 +571,7 @@ void hap_teardown(struct domain *d)
 }
 
 int hap_domctl(struct domain *d, xen_domctl_shadow_op_t *sc,
-               XEN_GUEST_HANDLE(void) u_domctl)
+               XEN_GUEST_HANDLE_PARAM(void) u_domctl)
 {
     int rc, preempted = 0;
 
diff --git a/xen/arch/x86/mm/mem_event.c b/xen/arch/x86/mm/mem_event.c
index 942c19e..27d1cf4 100644
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -512,7 +512,7 @@ void mem_event_cleanup(struct domain *d)
 }
 
 int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
-                     XEN_GUEST_HANDLE(void) u_domctl)
+                     XEN_GUEST_HANDLE_PARAM(void) u_domctl)
 {
     int rc;
 
diff --git a/xen/arch/x86/mm/paging.c b/xen/arch/x86/mm/paging.c
index ca879f9..ea44e39 100644
--- a/xen/arch/x86/mm/paging.c
+++ b/xen/arch/x86/mm/paging.c
@@ -654,7 +654,7 @@ void paging_vcpu_init(struct vcpu *v)
 
 
 int paging_domctl(struct domain *d, xen_domctl_shadow_op_t *sc,
-                  XEN_GUEST_HANDLE(void) u_domctl)
+                  XEN_GUEST_HANDLE_PARAM(void) u_domctl)
 {
     int rc;
 
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index 3f8ad88..ce79131 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -3641,7 +3641,7 @@ out:
 
 int shadow_domctl(struct domain *d, 
                   xen_domctl_shadow_op_t *sc,
-                  XEN_GUEST_HANDLE(void) u_domctl)
+                  XEN_GUEST_HANDLE_PARAM(void) u_domctl)
 {
     int rc, preempted = 0;
 
diff --git a/xen/arch/x86/oprofile/xenoprof.c b/xen/arch/x86/oprofile/xenoprof.c
index 160abac..90ef67d 100644
--- a/xen/arch/x86/oprofile/xenoprof.c
+++ b/xen/arch/x86/oprofile/xenoprof.c
@@ -17,7 +17,7 @@
 
 #include "op_counter.h"
 
-int xenoprof_arch_counter(XEN_GUEST_HANDLE(void) arg)
+int xenoprof_arch_counter(XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     struct xenoprof_counter counter;
 
@@ -37,7 +37,7 @@ int xenoprof_arch_counter(XEN_GUEST_HANDLE(void) arg)
     return 0;
 }
 
-int xenoprof_arch_ibs_counter(XEN_GUEST_HANDLE(void) arg)
+int xenoprof_arch_ibs_counter(XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     struct xenoprof_ibs_counter ibs_counter;
 
@@ -54,7 +54,7 @@ int xenoprof_arch_ibs_counter(XEN_GUEST_HANDLE(void) arg)
     return 0;
 }
 
-int compat_oprof_arch_counter(XEN_GUEST_HANDLE(void) arg)
+int compat_oprof_arch_counter(XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     struct compat_oprof_counter counter;
 
diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index 984c813..751cbd4 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -258,7 +258,7 @@ int physdev_unmap_pirq(domid_t domid, int pirq)
 }
 #endif /* COMPAT */
 
-ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
+ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     int irq;
     ret_t ret;
diff --git a/xen/arch/x86/sysctl.c b/xen/arch/x86/sysctl.c
index 379f071..b84dd34 100644
--- a/xen/arch/x86/sysctl.c
+++ b/xen/arch/x86/sysctl.c
@@ -58,7 +58,7 @@ long cpu_down_helper(void *data)
 }
 
 long arch_do_sysctl(
-    struct xen_sysctl *sysctl, XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl)
+    struct xen_sysctl *sysctl, XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
 {
     long ret = 0;
 
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index de08e25..dfaf78e 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -3536,7 +3536,7 @@ int send_guest_trap(struct domain *d, uint16_t vcpuid, unsigned int trap_nr)
 }
 
 
-long do_set_trap_table(XEN_GUEST_HANDLE(const_trap_info_t) traps)
+long do_set_trap_table(XEN_GUEST_HANDLE_PARAM(const_trap_info_t) traps)
 {
     struct trap_info cur;
     struct vcpu *curr = current;
diff --git a/xen/arch/x86/x86_64/compat/mm.c b/xen/arch/x86/x86_64/compat/mm.c
index f497503..d1eb785 100644
--- a/xen/arch/x86/x86_64/compat/mm.c
+++ b/xen/arch/x86/x86_64/compat/mm.c
@@ -5,7 +5,7 @@
 #include 
 #include 
 
-int compat_set_gdt(XEN_GUEST_HANDLE(uint) frame_list, unsigned int entries)
+int compat_set_gdt(XEN_GUEST_HANDLE_PARAM(uint) frame_list, unsigned int entries)
 {
     unsigned int i, nr_pages = (entries + 511) / 512;
     unsigned long frames[16];
@@ -44,7 +44,7 @@ int compat_update_descriptor(u32 pa_lo, u32 pa_hi, u32 desc_lo, u32 desc_hi)
                                 desc_lo | ((u64)desc_hi << 32));
 }
 
-int compat_arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
+int compat_arch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     struct compat_machphys_mfn_list xmml;
     l2_pgentry_t l2e;
@@ -260,14 +260,14 @@ int compat_update_va_mapping_otherdomain(unsigned long va, u32 lo, u32 hi,
 
 DEFINE_XEN_GUEST_HANDLE(mmuext_op_compat_t);
 
-int compat_mmuext_op(XEN_GUEST_HANDLE(mmuext_op_compat_t) cmp_uops,
+int compat_mmuext_op(XEN_GUEST_HANDLE_PARAM(mmuext_op_compat_t) cmp_uops,
                      unsigned int count,
-                     XEN_GUEST_HANDLE(uint) pdone,
+                     XEN_GUEST_HANDLE_PARAM(uint) pdone,
                      unsigned int foreigndom)
 {
     unsigned int i, preempt_mask;
     int rc = 0;
-    XEN_GUEST_HANDLE(mmuext_op_t) nat_ops;
+    XEN_GUEST_HANDLE_PARAM(mmuext_op_t) nat_ops;
 
     preempt_mask = count & MMU_UPDATE_PREEMPTED;
     count ^= preempt_mask;
diff --git a/xen/arch/x86/x86_64/domain.c b/xen/arch/x86/x86_64/domain.c
index e746c89..144ca2d 100644
--- a/xen/arch/x86/x86_64/domain.c
+++ b/xen/arch/x86/x86_64/domain.c
@@ -23,7 +23,7 @@ CHECK_vcpu_get_physid;
 
 int
 arch_compat_vcpu_op(
-    int cmd, struct vcpu *v, XEN_GUEST_HANDLE(void) arg)
+    int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     int rc = -ENOSYS;
 
diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
index 1e001ea..35653b7 100644
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -1027,7 +1027,7 @@ void __init subarch_init_memory(void)
     }
 }
 
-long subarch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
+long subarch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     struct xen_machphys_mfn_list xmml;
     l3_pgentry_t l3e;
diff --git a/xen/arch/x86/x86_64/traps.c b/xen/arch/x86/x86_64/traps.c
index 3361d19..dfe0fac 100644
--- a/xen/arch/x86/x86_64/traps.c
+++ b/xen/arch/x86/x86_64/traps.c
@@ -519,7 +519,7 @@ static long unregister_guest_callback(struct callback_unregister *unreg)
 }
 
 
-long do_callback_op(int cmd, XEN_GUEST_HANDLE(const_void) arg)
+long do_callback_op(int cmd, XEN_GUEST_HANDLE_PARAM(const_void) arg)
 {
     long ret;
 
diff --git a/xen/common/compat/domain.c b/xen/common/compat/domain.c
index 40a0287..e4c8ceb 100644
--- a/xen/common/compat/domain.c
+++ b/xen/common/compat/domain.c
@@ -15,7 +15,7 @@
 CHECK_vcpu_set_periodic_timer;
 #undef xen_vcpu_set_periodic_timer
 
-int compat_vcpu_op(int cmd, int vcpuid, XEN_GUEST_HANDLE(void) arg)
+int compat_vcpu_op(int cmd, int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     struct domain *d = current->domain;
     struct vcpu *v;
diff --git a/xen/common/compat/grant_table.c b/xen/common/compat/grant_table.c
index edd20c6..b524955 100644
--- a/xen/common/compat/grant_table.c
+++ b/xen/common/compat/grant_table.c
@@ -52,12 +52,12 @@ CHECK_gnttab_swap_grant_ref;
 #undef xen_gnttab_swap_grant_ref
 
 int compat_grant_table_op(unsigned int cmd,
-                          XEN_GUEST_HANDLE(void) cmp_uop,
+                          XEN_GUEST_HANDLE_PARAM(void) cmp_uop,
                           unsigned int count)
 {
     int rc = 0;
     unsigned int i;
-    XEN_GUEST_HANDLE(void) cnt_uop;
+    XEN_GUEST_HANDLE_PARAM(void) cnt_uop;
 
     set_xen_guest_handle(cnt_uop, NULL);
     switch ( cmd )
@@ -206,7 +206,7 @@ int compat_grant_table_op(unsigned int cmd,
             }
             if ( rc >= 0 )
             {
-                XEN_GUEST_HANDLE(gnttab_transfer_compat_t) xfer;
+                XEN_GUEST_HANDLE_PARAM(gnttab_transfer_compat_t) xfer;
 
                 xfer = guest_handle_cast(cmp_uop, gnttab_transfer_compat_t);
                 guest_handle_add_offset(xfer, i);
@@ -251,7 +251,7 @@ int compat_grant_table_op(unsigned int cmd,
             }
             if ( rc >= 0 )
             {
-                XEN_GUEST_HANDLE(gnttab_copy_compat_t) copy;
+                XEN_GUEST_HANDLE_PARAM(gnttab_copy_compat_t) copy;
 
                 copy = guest_handle_cast(cmp_uop, gnttab_copy_compat_t);
                 guest_handle_add_offset(copy, i);
diff --git a/xen/common/compat/memory.c b/xen/common/compat/memory.c
index e7257cc..996151c 100644
--- a/xen/common/compat/memory.c
+++ b/xen/common/compat/memory.c
@@ -13,7 +13,7 @@ CHECK_TYPE(domid);
 #undef compat_domid_t
 #undef xen_domid_t
 
-int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE(void) compat)
+int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) compat)
 {
     int rc, split, op = cmd & MEMOP_CMD_MASK;
     unsigned int start_extent = cmd >> MEMOP_EXTENT_SHIFT;
@@ -22,7 +22,7 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE(void) compat)
     {
         unsigned int i, end_extent = 0;
         union {
-            XEN_GUEST_HANDLE(void) hnd;
+            XEN_GUEST_HANDLE_PARAM(void) hnd;
             struct xen_memory_reservation *rsrv;
             struct xen_memory_exchange *xchg;
             struct xen_remove_from_physmap *xrfp;
diff --git a/xen/common/domain.c b/xen/common/domain.c
index a1aa05e..6f98b54 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -806,7 +806,7 @@ void vcpu_reset(struct vcpu *v)
 }
 
 
-long do_vcpu_op(int cmd, int vcpuid, XEN_GUEST_HANDLE(void) arg)
+long do_vcpu_op(int cmd, int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     struct domain *d = current->domain;
     struct vcpu *v;
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 2b1f182..e153cb4 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -239,7 +239,7 @@ void domctl_lock_release(void)
     spin_unlock(¤t->domain->hypercall_deadlock_mutex);
 }
 
-long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
+long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
 {
     long ret = 0;
     struct xen_domctl curop, *op = &curop;
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 53777f8..a80a0d1 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -970,7 +970,7 @@ out:
 }
 
 
-long do_event_channel_op(int cmd, XEN_GUEST_HANDLE(void) arg)
+long do_event_channel_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     long rc;
 
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index c8e342b..f4ae9ee 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -833,7 +833,7 @@ __gnttab_map_grant_ref(
 
 static long
 gnttab_map_grant_ref(
-    XEN_GUEST_HANDLE(gnttab_map_grant_ref_t) uop, unsigned int count)
+    XEN_GUEST_HANDLE_PARAM(gnttab_map_grant_ref_t) uop, unsigned int count)
 {
     int i;
     struct gnttab_map_grant_ref op;
@@ -1102,7 +1102,7 @@ __gnttab_unmap_grant_ref(
 
 static long
 gnttab_unmap_grant_ref(
-    XEN_GUEST_HANDLE(gnttab_unmap_grant_ref_t) uop, unsigned int count)
+    XEN_GUEST_HANDLE_PARAM(gnttab_unmap_grant_ref_t) uop, unsigned int count)
 {
     int i, c, partial_done, done = 0;
     struct gnttab_unmap_grant_ref op;
@@ -1164,7 +1164,7 @@ __gnttab_unmap_and_replace(
 
 static long
 gnttab_unmap_and_replace(
-    XEN_GUEST_HANDLE(gnttab_unmap_and_replace_t) uop, unsigned int count)
+    XEN_GUEST_HANDLE_PARAM(gnttab_unmap_and_replace_t) uop, unsigned int count)
 {
     int i, c, partial_done, done = 0;
     struct gnttab_unmap_and_replace op;
@@ -1316,7 +1316,7 @@ active_alloc_failed:
 
 static long 
 gnttab_setup_table(
-    XEN_GUEST_HANDLE(gnttab_setup_table_t) uop, unsigned int count)
+    XEN_GUEST_HANDLE_PARAM(gnttab_setup_table_t) uop, unsigned int count)
 {
     struct gnttab_setup_table op;
     struct domain *d;
@@ -1395,7 +1395,7 @@ gnttab_setup_table(
 
 static long 
 gnttab_query_size(
-    XEN_GUEST_HANDLE(gnttab_query_size_t) uop, unsigned int count)
+    XEN_GUEST_HANDLE_PARAM(gnttab_query_size_t) uop, unsigned int count)
 {
     struct gnttab_query_size op;
     struct domain *d;
@@ -1517,7 +1517,7 @@ gnttab_prepare_for_transfer(
 
 static long
 gnttab_transfer(
-    XEN_GUEST_HANDLE(gnttab_transfer_t) uop, unsigned int count)
+    XEN_GUEST_HANDLE_PARAM(gnttab_transfer_t) uop, unsigned int count)
 {
     struct domain *d = current->domain;
     struct domain *e;
@@ -2125,7 +2125,7 @@ __gnttab_copy(
 
 static long
 gnttab_copy(
-    XEN_GUEST_HANDLE(gnttab_copy_t) uop, unsigned int count)
+    XEN_GUEST_HANDLE_PARAM(gnttab_copy_t) uop, unsigned int count)
 {
     int i;
     struct gnttab_copy op;
@@ -2144,7 +2144,7 @@ gnttab_copy(
 }
 
 static long
-gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
+gnttab_set_version(XEN_GUEST_HANDLE_PARAM(gnttab_set_version_t uop))
 {
     gnttab_set_version_t op;
     struct domain *d = current->domain;
@@ -2263,7 +2263,7 @@ out:
 }
 
 static long
-gnttab_get_status_frames(XEN_GUEST_HANDLE(gnttab_get_status_frames_t) uop,
+gnttab_get_status_frames(XEN_GUEST_HANDLE_PARAM(gnttab_get_status_frames_t) uop,
                          int count)
 {
     gnttab_get_status_frames_t op;
@@ -2327,7 +2327,7 @@ out1:
 }
 
 static long
-gnttab_get_version(XEN_GUEST_HANDLE(gnttab_get_version_t uop))
+gnttab_get_version(XEN_GUEST_HANDLE_PARAM(gnttab_get_version_t uop))
 {
     gnttab_get_version_t op;
     struct domain *d;
@@ -2412,7 +2412,7 @@ out:
 }
 
 static long
-gnttab_swap_grant_ref(XEN_GUEST_HANDLE(gnttab_swap_grant_ref_t uop),
+gnttab_swap_grant_ref(XEN_GUEST_HANDLE_PARAM(gnttab_swap_grant_ref_t uop),
                       unsigned int count)
 {
     int i;
@@ -2433,7 +2433,7 @@ gnttab_swap_grant_ref(XEN_GUEST_HANDLE(gnttab_swap_grant_ref_t uop),
 
 long
 do_grant_table_op(
-    unsigned int cmd, XEN_GUEST_HANDLE(void) uop, unsigned int count)
+    unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) uop, unsigned int count)
 {
     long rc;
     
@@ -2445,7 +2445,7 @@ do_grant_table_op(
     {
     case GNTTABOP_map_grant_ref:
     {
-        XEN_GUEST_HANDLE(gnttab_map_grant_ref_t) map =
+        XEN_GUEST_HANDLE_PARAM(gnttab_map_grant_ref_t) map =
             guest_handle_cast(uop, gnttab_map_grant_ref_t);
         if ( unlikely(!guest_handle_okay(map, count)) )
             goto out;
@@ -2459,7 +2459,7 @@ do_grant_table_op(
     }
     case GNTTABOP_unmap_grant_ref:
     {
-        XEN_GUEST_HANDLE(gnttab_unmap_grant_ref_t) unmap =
+        XEN_GUEST_HANDLE_PARAM(gnttab_unmap_grant_ref_t) unmap =
             guest_handle_cast(uop, gnttab_unmap_grant_ref_t);
         if ( unlikely(!guest_handle_okay(unmap, count)) )
             goto out;
@@ -2473,7 +2473,7 @@ do_grant_table_op(
     }
     case GNTTABOP_unmap_and_replace:
     {
-        XEN_GUEST_HANDLE(gnttab_unmap_and_replace_t) unmap =
+        XEN_GUEST_HANDLE_PARAM(gnttab_unmap_and_replace_t) unmap =
             guest_handle_cast(uop, gnttab_unmap_and_replace_t);
         if ( unlikely(!guest_handle_okay(unmap, count)) )
             goto out;
@@ -2497,7 +2497,7 @@ do_grant_table_op(
     }
     case GNTTABOP_transfer:
     {
-        XEN_GUEST_HANDLE(gnttab_transfer_t) transfer =
+        XEN_GUEST_HANDLE_PARAM(gnttab_transfer_t) transfer =
             guest_handle_cast(uop, gnttab_transfer_t);
         if ( unlikely(!guest_handle_okay(transfer, count)) )
             goto out;
@@ -2511,7 +2511,7 @@ do_grant_table_op(
     }
     case GNTTABOP_copy:
     {
-        XEN_GUEST_HANDLE(gnttab_copy_t) copy =
+        XEN_GUEST_HANDLE_PARAM(gnttab_copy_t) copy =
             guest_handle_cast(uop, gnttab_copy_t);
         if ( unlikely(!guest_handle_okay(copy, count)) )
             goto out;
@@ -2548,7 +2548,7 @@ do_grant_table_op(
     }
     case GNTTABOP_swap_grant_ref:
     {
-        XEN_GUEST_HANDLE(gnttab_swap_grant_ref_t) swap =
+        XEN_GUEST_HANDLE_PARAM(gnttab_swap_grant_ref_t) swap =
             guest_handle_cast(uop, gnttab_swap_grant_ref_t);
         if ( unlikely(!guest_handle_okay(swap, count)) )
             goto out;
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index c915bbc..55caff6 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -204,7 +204,7 @@ void __init do_initcalls(void)
  * Simple hypercalls.
  */
 
-DO(xen_version)(int cmd, XEN_GUEST_HANDLE(void) arg)
+DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     switch ( cmd )
     {
@@ -332,7 +332,7 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE(void) arg)
     return -ENOSYS;
 }
 
-DO(nmi_op)(unsigned int cmd, XEN_GUEST_HANDLE(void) arg)
+DO(nmi_op)(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     struct xennmi_callback cb;
     long rc = 0;
diff --git a/xen/common/kexec.c b/xen/common/kexec.c
index 2bc3e33..25ebd6a 100644
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -613,7 +613,7 @@ static int kexec_get_range_internal(xen_kexec_range_t *range)
     return ret;
 }
 
-static int kexec_get_range(XEN_GUEST_HANDLE(void) uarg)
+static int kexec_get_range(XEN_GUEST_HANDLE_PARAM(void) uarg)
 {
     xen_kexec_range_t range;
     int ret = -EINVAL;
@@ -629,7 +629,7 @@ static int kexec_get_range(XEN_GUEST_HANDLE(void) uarg)
     return ret;
 }
 
-static int kexec_get_range_compat(XEN_GUEST_HANDLE(void) uarg)
+static int kexec_get_range_compat(XEN_GUEST_HANDLE_PARAM(void) uarg)
 {
 #ifdef CONFIG_COMPAT
     xen_kexec_range_t range;
@@ -777,7 +777,7 @@ static int kexec_load_unload_internal(unsigned long op, xen_kexec_load_t *load)
     return ret;
 }
 
-static int kexec_load_unload(unsigned long op, XEN_GUEST_HANDLE(void) uarg)
+static int kexec_load_unload(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) uarg)
 {
     xen_kexec_load_t load;
 
@@ -788,7 +788,7 @@ static int kexec_load_unload(unsigned long op, XEN_GUEST_HANDLE(void) uarg)
 }
 
 static int kexec_load_unload_compat(unsigned long op,
-                                    XEN_GUEST_HANDLE(void) uarg)
+                                    XEN_GUEST_HANDLE_PARAM(void) uarg)
 {
 #ifdef CONFIG_COMPAT
     compat_kexec_load_t compat_load;
@@ -813,7 +813,7 @@ static int kexec_load_unload_compat(unsigned long op,
 #endif /* CONFIG_COMPAT */
 }
 
-static int kexec_exec(XEN_GUEST_HANDLE(void) uarg)
+static int kexec_exec(XEN_GUEST_HANDLE_PARAM(void) uarg)
 {
     xen_kexec_exec_t exec;
     xen_kexec_image_t *image;
@@ -845,7 +845,8 @@ static int kexec_exec(XEN_GUEST_HANDLE(void) uarg)
     return -EINVAL; /* never reached */
 }
 
-static int do_kexec_op_internal(unsigned long op, XEN_GUEST_HANDLE(void) uarg,
+static int do_kexec_op_internal(unsigned long op,
+                                XEN_GUEST_HANDLE_PARAM(void) uarg,
                                 bool_t compat)
 {
     unsigned long flags;
@@ -886,13 +887,13 @@ static int do_kexec_op_internal(unsigned long op, XEN_GUEST_HANDLE(void) uarg,
     return ret;
 }
 
-long do_kexec_op(unsigned long op, XEN_GUEST_HANDLE(void) uarg)
+long do_kexec_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) uarg)
 {
     return do_kexec_op_internal(op, uarg, 0);
 }
 
 #ifdef CONFIG_COMPAT
-int compat_kexec_op(unsigned long op, XEN_GUEST_HANDLE(void) uarg)
+int compat_kexec_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) uarg)
 {
     return do_kexec_op_internal(op, uarg, 1);
 }
diff --git a/xen/common/memory.c b/xen/common/memory.c
index 401d06c..83e2666 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -277,7 +277,7 @@ static void decrease_reservation(struct memop_args *a)
     a->nr_done = i;
 }
 
-static long memory_exchange(XEN_GUEST_HANDLE(xen_memory_exchange_t) arg)
+static long memory_exchange(XEN_GUEST_HANDLE_PARAM(xen_memory_exchange_t) arg)
 {
     struct xen_memory_exchange exch;
     PAGE_LIST_HEAD(in_chunk_list);
@@ -517,7 +517,7 @@ static long memory_exchange(XEN_GUEST_HANDLE(xen_memory_exchange_t) arg)
     return rc;
 }
 
-long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE(void) arg)
+long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     struct domain *d;
     int rc, op;
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index eee74be..00812ac 100644
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -836,7 +836,7 @@ typedef long ret_t;
 
 #endif /* !COMPAT */
 
-ret_t do_sched_op(int cmd, XEN_GUEST_HANDLE(void) arg)
+ret_t do_sched_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     ret_t ret = 0;
 
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index ea68278..47142f4 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -27,7 +27,7 @@
 #include 
 #include 
 
-long do_sysctl(XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl)
+long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
 {
     long ret = 0;
     struct xen_sysctl curop, *op = &curop;
diff --git a/xen/common/tmem.c b/xen/common/tmem.c
index ed322b6..1280537 100644
--- a/xen/common/tmem.c
+++ b/xen/common/tmem.c
@@ -1444,7 +1444,7 @@ static inline void tmem_ensure_avail_pages(void)
 /************ TMEM CORE OPERATIONS ************************************/
 
 static NOINLINE int do_tmem_put_compress(pgp_t *pgp, tmem_cli_mfn_t cmfn,
-                                         tmem_cli_va_t clibuf)
+                                         tmem_cli_va_param_t clibuf)
 {
     void *dst, *p;
     size_t size;
@@ -1488,7 +1488,7 @@ out:
 
 static NOINLINE int do_tmem_dup_put(pgp_t *pgp, tmem_cli_mfn_t cmfn,
        pagesize_t tmem_offset, pagesize_t pfn_offset, pagesize_t len,
-       tmem_cli_va_t clibuf)
+       tmem_cli_va_param_t clibuf)
 {
     pool_t *pool;
     obj_t *obj;
@@ -1579,7 +1579,7 @@ cleanup:
 static NOINLINE int do_tmem_put(pool_t *pool,
               OID *oidp, uint32_t index,
               tmem_cli_mfn_t cmfn, pagesize_t tmem_offset,
-              pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_t clibuf)
+              pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_param_t clibuf)
 {
     obj_t *obj = NULL, *objfound = NULL, *objnew = NULL;
     pgp_t *pgp = NULL, *pgpdel = NULL;
@@ -1722,7 +1722,7 @@ free:
 
 static NOINLINE int do_tmem_get(pool_t *pool, OID *oidp, uint32_t index,
               tmem_cli_mfn_t cmfn, pagesize_t tmem_offset,
-              pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_t clibuf)
+              pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_param_t clibuf)
 {
     obj_t *obj;
     pgp_t *pgp;
@@ -2066,8 +2066,8 @@ static int tmemc_flush_mem(cli_id_t cli_id, uint32_t kb)
  */
 #define BSIZE 1024
 
-static int tmemc_list_client(client_t *c, tmem_cli_va_t buf, int off, 
-                             uint32_t len, bool_t use_long)
+static int tmemc_list_client(client_t *c, tmem_cli_va_param_t buf,
+                             int off, uint32_t len, bool_t use_long)
 {
     char info[BSIZE];
     int i, n = 0, sum = 0;
@@ -2119,7 +2119,7 @@ static int tmemc_list_client(client_t *c, tmem_cli_va_t buf, int off,
     return sum;
 }
 
-static int tmemc_list_shared(tmem_cli_va_t buf, int off, uint32_t len,
+static int tmemc_list_shared(tmem_cli_va_param_t buf, int off, uint32_t len,
                               bool_t use_long)
 {
     char info[BSIZE];
@@ -2159,8 +2159,8 @@ static int tmemc_list_shared(tmem_cli_va_t buf, int off, uint32_t len,
 }
 
 #ifdef TMEM_PERF
-static int tmemc_list_global_perf(tmem_cli_va_t buf, int off, uint32_t len,
-                              bool_t use_long)
+static int tmemc_list_global_perf(tmem_cli_va_param_t buf, int off,
+                                  uint32_t len, bool_t use_long)
 {
     char info[BSIZE];
     int n = 0, sum = 0;
@@ -2194,7 +2194,7 @@ static int tmemc_list_global_perf(tmem_cli_va_t buf, int off, uint32_t len,
 #define tmemc_list_global_perf(_buf,_off,_len,_use) (0)
 #endif
 
-static int tmemc_list_global(tmem_cli_va_t buf, int off, uint32_t len,
+static int tmemc_list_global(tmem_cli_va_param_t buf, int off, uint32_t len,
                               bool_t use_long)
 {
     char info[BSIZE];
@@ -2226,7 +2226,7 @@ static int tmemc_list_global(tmem_cli_va_t buf, int off, uint32_t len,
     return sum;
 }
 
-static int tmemc_list(cli_id_t cli_id, tmem_cli_va_t buf, uint32_t len,
+static int tmemc_list(cli_id_t cli_id, tmem_cli_va_param_t buf, uint32_t len,
                                bool_t use_long)
 {
     client_t *client;
@@ -2338,7 +2338,7 @@ static NOINLINE int tmemc_shared_pool_auth(cli_id_t cli_id, uint64_t uuid_lo,
 }
 
 static NOINLINE int tmemc_save_subop(int cli_id, uint32_t pool_id,
-                        uint32_t subop, tmem_cli_va_t buf, uint32_t arg1)
+                        uint32_t subop, tmem_cli_va_param_t buf, uint32_t arg1)
 {
     client_t *client = tmh_client_from_cli_id(cli_id);
     pool_t *pool = (client == NULL || pool_id >= MAX_POOLS_PER_DOMAIN)
@@ -2427,7 +2427,7 @@ static NOINLINE int tmemc_save_subop(int cli_id, uint32_t pool_id,
 }
 
 static NOINLINE int tmemc_save_get_next_page(int cli_id, uint32_t pool_id,
-                        tmem_cli_va_t buf, uint32_t bufsize)
+                        tmem_cli_va_param_t buf, uint32_t bufsize)
 {
     client_t *client = tmh_client_from_cli_id(cli_id);
     pool_t *pool = (client == NULL || pool_id >= MAX_POOLS_PER_DOMAIN)
@@ -2479,7 +2479,7 @@ out:
     return ret;
 }
 
-static NOINLINE int tmemc_save_get_next_inv(int cli_id, tmem_cli_va_t buf,
+static NOINLINE int tmemc_save_get_next_inv(int cli_id, tmem_cli_va_param_t buf,
                         uint32_t bufsize)
 {
     client_t *client = tmh_client_from_cli_id(cli_id);
@@ -2522,7 +2522,7 @@ out:
 }
 
 static int tmemc_restore_put_page(int cli_id, uint32_t pool_id, OID *oidp,
-                      uint32_t index, tmem_cli_va_t buf, uint32_t bufsize)
+                      uint32_t index, tmem_cli_va_param_t buf, uint32_t bufsize)
 {
     client_t *client = tmh_client_from_cli_id(cli_id);
     pool_t *pool = (client == NULL || pool_id >= MAX_POOLS_PER_DOMAIN)
@@ -2566,7 +2566,8 @@ static NOINLINE int do_tmem_control(struct tmem_op *op)
         ret = tmemc_flush_mem(op->u.ctrl.cli_id,op->u.ctrl.arg1);
         break;
     case TMEMC_LIST:
-        ret = tmemc_list(op->u.ctrl.cli_id,op->u.ctrl.buf,
+        ret = tmemc_list(op->u.ctrl.cli_id,
+                         guest_handle_cast(op->u.ctrl.buf, char),
                          op->u.ctrl.arg1,op->u.ctrl.arg2);
         break;
     case TMEMC_SET_WEIGHT:
@@ -2589,20 +2590,24 @@ static NOINLINE int do_tmem_control(struct tmem_op *op)
     case TMEMC_SAVE_GET_POOL_UUID:
     case TMEMC_SAVE_END:
         ret = tmemc_save_subop(op->u.ctrl.cli_id,pool_id,subop,
-                        op->u.ctrl.buf,op->u.ctrl.arg1);
+                               guest_handle_cast(op->u.ctrl.buf, char),
+                               op->u.ctrl.arg1);
         break;
     case TMEMC_SAVE_GET_NEXT_PAGE:
         ret = tmemc_save_get_next_page(op->u.ctrl.cli_id, pool_id,
-                                       op->u.ctrl.buf, op->u.ctrl.arg1);
+                                       guest_handle_cast(op->u.ctrl.buf, char),
+                                       op->u.ctrl.arg1);
         break;
     case TMEMC_SAVE_GET_NEXT_INV:
-        ret = tmemc_save_get_next_inv(op->u.ctrl.cli_id, op->u.ctrl.buf,
+        ret = tmemc_save_get_next_inv(op->u.ctrl.cli_id,
+                                      guest_handle_cast(op->u.ctrl.buf, char),
                                       op->u.ctrl.arg1);
         break;
     case TMEMC_RESTORE_PUT_PAGE:
         ret = tmemc_restore_put_page(op->u.ctrl.cli_id,pool_id,
                                      oidp, op->u.ctrl.arg2,
-                                     op->u.ctrl.buf, op->u.ctrl.arg1);
+                                     guest_handle_cast(op->u.ctrl.buf, char),
+                                     op->u.ctrl.arg1);
         break;
     case TMEMC_RESTORE_FLUSH_PAGE:
         ret = tmemc_restore_flush_page(op->u.ctrl.cli_id,pool_id,
diff --git a/xen/common/tmem_xen.c b/xen/common/tmem_xen.c
index 9dc2a1d..25fbd6c 100644
--- a/xen/common/tmem_xen.c
+++ b/xen/common/tmem_xen.c
@@ -146,7 +146,7 @@ static inline void cli_put_page(void *cli_va, pfp_t *cli_pfp,
 
 EXPORT int tmh_copy_from_client(pfp_t *pfp,
     tmem_cli_mfn_t cmfn, pagesize_t tmem_offset,
-    pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_t clibuf)
+    pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_param_t clibuf)
 {
     unsigned long tmem_mfn, cli_mfn = 0;
     char *tmem_va, *cli_va = NULL;
@@ -194,7 +194,7 @@ EXPORT int tmh_copy_from_client(pfp_t *pfp,
 }
 
 EXPORT int tmh_compress_from_client(tmem_cli_mfn_t cmfn,
-    void **out_va, size_t *out_len, tmem_cli_va_t clibuf)
+    void **out_va, size_t *out_len, tmem_cli_va_param_t clibuf)
 {
     int ret = 0;
     unsigned char *dmem = this_cpu(dstmem);
@@ -227,7 +227,7 @@ EXPORT int tmh_compress_from_client(tmem_cli_mfn_t cmfn,
 
 EXPORT int tmh_copy_to_client(tmem_cli_mfn_t cmfn, pfp_t *pfp,
     pagesize_t tmem_offset, pagesize_t pfn_offset, pagesize_t len,
-    tmem_cli_va_t clibuf)
+    tmem_cli_va_param_t clibuf)
 {
     unsigned long tmem_mfn, cli_mfn = 0;
     char *tmem_va, *cli_va = NULL;
@@ -265,7 +265,7 @@ EXPORT int tmh_copy_to_client(tmem_cli_mfn_t cmfn, pfp_t *pfp,
 }
 
 EXPORT int tmh_decompress_to_client(tmem_cli_mfn_t cmfn, void *tmem_va,
-                                    size_t size, tmem_cli_va_t clibuf)
+                                    size_t size, tmem_cli_va_param_t clibuf)
 {
     unsigned long cli_mfn = 0;
     pfp_t *cli_pfp = NULL;
diff --git a/xen/common/xenoprof.c b/xen/common/xenoprof.c
index 44a1fae..ae0435b 100644
--- a/xen/common/xenoprof.c
+++ b/xen/common/xenoprof.c
@@ -404,7 +404,7 @@ static int add_active_list(domid_t domid)
     return 0;
 }
 
-static int add_passive_list(XEN_GUEST_HANDLE(void) arg)
+static int add_passive_list(XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     struct xenoprof_passive passive;
     struct domain *d;
@@ -585,7 +585,7 @@ void xenoprof_log_event(struct vcpu *vcpu, const struct cpu_user_regs *regs,
 
 
 
-static int xenoprof_op_init(XEN_GUEST_HANDLE(void) arg)
+static int xenoprof_op_init(XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     struct domain *d = current->domain;
     struct xenoprof_init xenoprof_init;
@@ -611,7 +611,7 @@ static int xenoprof_op_init(XEN_GUEST_HANDLE(void) arg)
 
 #endif /* !COMPAT */
 
-static int xenoprof_op_get_buffer(XEN_GUEST_HANDLE(void) arg)
+static int xenoprof_op_get_buffer(XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     struct xenoprof_get_buffer xenoprof_get_buffer;
     struct domain *d = current->domain;
@@ -662,7 +662,7 @@ static int xenoprof_op_get_buffer(XEN_GUEST_HANDLE(void) arg)
                       || (op == XENOPROF_disable_virq)  \
                       || (op == XENOPROF_get_buffer))
  
-ret_t do_xenoprof_op(int op, XEN_GUEST_HANDLE(void) arg)
+ret_t do_xenoprof_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     int ret = 0;
     
diff --git a/xen/drivers/acpi/pmstat.c b/xen/drivers/acpi/pmstat.c
index 6f266ef..bf30cc7 100644
--- a/xen/drivers/acpi/pmstat.c
+++ b/xen/drivers/acpi/pmstat.c
@@ -496,7 +496,7 @@ int do_pm_op(struct xen_sysctl_pm_op *op)
     return ret;
 }
 
-int acpi_set_pdc_bits(u32 acpi_id, XEN_GUEST_HANDLE(uint32) pdc)
+int acpi_set_pdc_bits(u32 acpi_id, XEN_GUEST_HANDLE_PARAM(uint32) pdc)
 {
     u32 bits[3];
     int ret;
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 9e1adb5..ff360fe 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -182,7 +182,7 @@ static void putchar_console_ring(int c)
 
 long read_console_ring(struct xen_sysctl_readconsole *op)
 {
-    XEN_GUEST_HANDLE(char) str;
+    XEN_GUEST_HANDLE_PARAM(char) str;
     uint32_t idx, len, max, sofar, c;
 
     str   = guest_handle_cast(op->buffer, char),
@@ -363,7 +363,7 @@ static void notify_dom0_con_ring(unsigned long unused)
 static DECLARE_SOFTIRQ_TASKLET(notify_dom0_con_ring_tasklet,
                                notify_dom0_con_ring, 0);
 
-static long guest_console_write(XEN_GUEST_HANDLE(char) buffer, int count)
+static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, int count)
 {
     char kbuf[128], *kptr;
     int kcount;
@@ -401,7 +401,7 @@ static long guest_console_write(XEN_GUEST_HANDLE(char) buffer, int count)
     return 0;
 }
 
-long do_console_io(int cmd, int count, XEN_GUEST_HANDLE(char) buffer)
+long do_console_io(int cmd, int count, XEN_GUEST_HANDLE_PARAM(char) buffer)
 {
     long rc;
     unsigned int idx, len;
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index b4cf16c..4b5f8b7 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -527,7 +527,7 @@ void iommu_crash_shutdown(void)
 
 int iommu_do_domctl(
     struct xen_domctl *domctl,
-    XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
+    XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
 {
     struct domain *d;
     u16 seg;
diff --git a/xen/include/asm-arm/hypercall.h b/xen/include/asm-arm/hypercall.h
index 454f02e..090e620 100644
--- a/xen/include/asm-arm/hypercall.h
+++ b/xen/include/asm-arm/hypercall.h
@@ -2,7 +2,7 @@
 #define __ASM_ARM_HYPERCALL_H__
 
 #include  /* for arch_do_domctl */
-int do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg);
+int do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg);
 
 #endif /* __ASM_ARM_HYPERCALL_H__ */
 /*
diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
index e4b2d97..c0f5b1f 100644
--- a/xen/include/asm-arm/mm.h
+++ b/xen/include/asm-arm/mm.h
@@ -267,7 +267,7 @@ static inline int relinquish_shared_pages(struct domain *d)
 
 
 /* Arch-specific portion of memory_op hypercall. */
-long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg);
+long arch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg);
 
 int steal_page(
     struct domain *d, struct page_info *page, unsigned int memflags);
diff --git a/xen/include/asm-x86/hap.h b/xen/include/asm-x86/hap.h
index a2532a4..916a35b 100644
--- a/xen/include/asm-x86/hap.h
+++ b/xen/include/asm-x86/hap.h
@@ -51,7 +51,7 @@ hap_unmap_domain_page(void *p)
 /************************************************/
 void  hap_domain_init(struct domain *d);
 int   hap_domctl(struct domain *d, xen_domctl_shadow_op_t *sc,
-                 XEN_GUEST_HANDLE(void) u_domctl);
+                 XEN_GUEST_HANDLE_PARAM(void) u_domctl);
 int   hap_enable(struct domain *d, u32 mode);
 void  hap_final_teardown(struct domain *d);
 void  hap_teardown(struct domain *d);
diff --git a/xen/include/asm-x86/hypercall.h b/xen/include/asm-x86/hypercall.h
index a9af426..bd14220 100644
--- a/xen/include/asm-x86/hypercall.h
+++ b/xen/include/asm-x86/hypercall.h
@@ -18,22 +18,22 @@
 
 extern long
 do_event_channel_op_compat(
-    XEN_GUEST_HANDLE(evtchn_op_t) uop);
+    XEN_GUEST_HANDLE_PARAM(evtchn_op_t) uop);
 
 extern long
 do_set_trap_table(
-    XEN_GUEST_HANDLE(const_trap_info_t) traps);
+    XEN_GUEST_HANDLE_PARAM(const_trap_info_t) traps);
 
 extern long
 do_mmu_update(
-    XEN_GUEST_HANDLE(mmu_update_t) ureqs,
+    XEN_GUEST_HANDLE_PARAM(mmu_update_t) ureqs,
     unsigned int count,
-    XEN_GUEST_HANDLE(uint) pdone,
+    XEN_GUEST_HANDLE_PARAM(uint) pdone,
     unsigned int foreigndom);
 
 extern long
 do_set_gdt(
-    XEN_GUEST_HANDLE(ulong) frame_list,
+    XEN_GUEST_HANDLE_PARAM(ulong) frame_list,
     unsigned int entries);
 
 extern long
@@ -60,7 +60,7 @@ do_update_descriptor(
     u64 desc);
 
 extern long
-do_mca(XEN_GUEST_HANDLE(xen_mc_t) u_xen_mc);
+do_mca(XEN_GUEST_HANDLE_PARAM(xen_mc_t) u_xen_mc);
 
 extern long
 do_update_va_mapping(
@@ -70,7 +70,7 @@ do_update_va_mapping(
 
 extern long
 do_physdev_op(
-    int cmd, XEN_GUEST_HANDLE(void) arg);
+    int cmd, XEN_GUEST_HANDLE_PARAM(void) arg);
 
 extern long
 do_update_va_mapping_otherdomain(
@@ -81,9 +81,9 @@ do_update_va_mapping_otherdomain(
 
 extern long
 do_mmuext_op(
-    XEN_GUEST_HANDLE(mmuext_op_t) uops,
+    XEN_GUEST_HANDLE_PARAM(mmuext_op_t) uops,
     unsigned int count,
-    XEN_GUEST_HANDLE(uint) pdone,
+    XEN_GUEST_HANDLE_PARAM(uint) pdone,
     unsigned int foreigndom);
 
 extern unsigned long
@@ -104,10 +104,10 @@ do_set_segment_base(
 extern int
 compat_physdev_op(
     int cmd,
-    XEN_GUEST_HANDLE(void) arg);
+    XEN_GUEST_HANDLE_PARAM(void) arg);
 
 extern int
 arch_compat_vcpu_op(
-    int cmd, struct vcpu *v, XEN_GUEST_HANDLE(void) arg);
+    int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg);
 
 #endif /* __ASM_X86_HYPERCALL_H__ */
diff --git a/xen/include/asm-x86/mem_event.h b/xen/include/asm-x86/mem_event.h
index 23d71c1..e17f36b 100644
--- a/xen/include/asm-x86/mem_event.h
+++ b/xen/include/asm-x86/mem_event.h
@@ -65,7 +65,7 @@ int mem_event_get_response(struct domain *d, struct mem_event_domain *med,
 struct domain *get_mem_event_op_target(uint32_t domain, int *rc);
 int do_mem_event_op(int op, uint32_t domain, void *arg);
 int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
-                     XEN_GUEST_HANDLE(void) u_domctl);
+                     XEN_GUEST_HANDLE_PARAM(void) u_domctl);
 
 #endif /* __MEM_EVENT_H__ */
 
diff --git a/xen/include/asm-x86/mm.h b/xen/include/asm-x86/mm.h
index 6e1e57c..494dad8 100644
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -555,10 +555,10 @@ void *do_page_walk(struct vcpu *v, unsigned long addr);
 int __sync_local_execstate(void);
 
 /* Arch-specific portion of memory_op hypercall. */
-long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg);
-long subarch_memory_op(int op, XEN_GUEST_HANDLE(void) arg);
-int compat_arch_memory_op(int op, XEN_GUEST_HANDLE(void));
-int compat_subarch_memory_op(int op, XEN_GUEST_HANDLE(void));
+long arch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg);
+long subarch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg);
+int compat_arch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void));
+int compat_subarch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void));
 
 int steal_page(
     struct domain *d, struct page_info *page, unsigned int memflags);
diff --git a/xen/include/asm-x86/paging.h b/xen/include/asm-x86/paging.h
index d9b6950..9a40f2c 100644
--- a/xen/include/asm-x86/paging.h
+++ b/xen/include/asm-x86/paging.h
@@ -207,7 +207,7 @@ int paging_domain_init(struct domain *d, unsigned int domcr_flags);
  * and disable ephemeral shadow modes (test mode and log-dirty mode) and
  * manipulate the log-dirty bitmap. */
 int paging_domctl(struct domain *d, xen_domctl_shadow_op_t *sc,
-                  XEN_GUEST_HANDLE(void) u_domctl);
+                  XEN_GUEST_HANDLE_PARAM(void) u_domctl);
 
 /* Call when destroying a domain */
 void paging_teardown(struct domain *d);
diff --git a/xen/include/asm-x86/processor.h b/xen/include/asm-x86/processor.h
index c969b11..637cea3 100644
--- a/xen/include/asm-x86/processor.h
+++ b/xen/include/asm-x86/processor.h
@@ -549,7 +549,7 @@ int rdmsr_hypervisor_regs(uint32_t idx, uint64_t *val);
 int wrmsr_hypervisor_regs(uint32_t idx, uint64_t val);
 
 void microcode_set_module(unsigned int);
-int microcode_update(XEN_GUEST_HANDLE(const_void), unsigned long len);
+int microcode_update(XEN_GUEST_HANDLE_PARAM(const_void), unsigned long len);
 int microcode_resume_cpu(int cpu);
 
 #endif /* !__ASSEMBLY__ */
diff --git a/xen/include/asm-x86/shadow.h b/xen/include/asm-x86/shadow.h
index 88a8cd2..2eb6efc 100644
--- a/xen/include/asm-x86/shadow.h
+++ b/xen/include/asm-x86/shadow.h
@@ -73,7 +73,7 @@ int shadow_track_dirty_vram(struct domain *d,
  * manipulate the log-dirty bitmap. */
 int shadow_domctl(struct domain *d, 
                   xen_domctl_shadow_op_t *sc,
-                  XEN_GUEST_HANDLE(void) u_domctl);
+                  XEN_GUEST_HANDLE_PARAM(void) u_domctl);
 
 /* Call when destroying a domain */
 void shadow_teardown(struct domain *d);
diff --git a/xen/include/asm-x86/xenoprof.h b/xen/include/asm-x86/xenoprof.h
index a71f020..52a6881 100644
--- a/xen/include/asm-x86/xenoprof.h
+++ b/xen/include/asm-x86/xenoprof.h
@@ -40,9 +40,9 @@ int xenoprof_arch_init(int *num_events, char *cpu_type);
 #define xenoprof_arch_disable_virq()            nmi_disable_virq()
 #define xenoprof_arch_release_counters()        nmi_release_counters()
 
-int xenoprof_arch_counter(XEN_GUEST_HANDLE(void) arg);
-int compat_oprof_arch_counter(XEN_GUEST_HANDLE(void) arg);
-int xenoprof_arch_ibs_counter(XEN_GUEST_HANDLE(void) arg);
+int xenoprof_arch_counter(XEN_GUEST_HANDLE_PARAM(void) arg);
+int compat_oprof_arch_counter(XEN_GUEST_HANDLE_PARAM(void) arg);
+int xenoprof_arch_ibs_counter(XEN_GUEST_HANDLE_PARAM(void) arg);
 
 struct vcpu;
 struct cpu_user_regs;
diff --git a/xen/include/xen/acpi.h b/xen/include/xen/acpi.h
index d7e2f94..8f3cdca 100644
--- a/xen/include/xen/acpi.h
+++ b/xen/include/xen/acpi.h
@@ -145,8 +145,8 @@ static inline unsigned int acpi_get_cstate_limit(void) { return 0; }
 static inline void acpi_set_cstate_limit(unsigned int new_limit) { return; }
 #endif
 
-#ifdef XEN_GUEST_HANDLE
-int acpi_set_pdc_bits(u32 acpi_id, XEN_GUEST_HANDLE(uint32));
+#ifdef XEN_GUEST_HANDLE_PARAM
+int acpi_set_pdc_bits(u32 acpi_id, XEN_GUEST_HANDLE_PARAM(uint32));
 #endif
 int arch_acpi_set_pdc_bits(u32 acpi_id, u32 *, u32 mask);
 
diff --git a/xen/include/xen/compat.h b/xen/include/xen/compat.h
index 857cbc7..ca60699 100644
--- a/xen/include/xen/compat.h
+++ b/xen/include/xen/compat.h
@@ -22,6 +22,9 @@
     __DEFINE_COMPAT_HANDLE(const_ ## name, const name)
 #define COMPAT_HANDLE(name)          __compat_handle_ ## name
 
+/* NB: it is assumed that if an arch uses the compat layer it does not
+ * distinguish handles from parameter handles. */
+#define COMPAT_HANDLE_PARAM(name)    __compat_handle_ ## name
 /* Is the compat handle a NULL reference? */
 #define compat_handle_is_null(hnd)        ((hnd).c == 0)
 
diff --git a/xen/include/xen/hypercall.h b/xen/include/xen/hypercall.h
index 1b71071..e315523 100644
--- a/xen/include/xen/hypercall.h
+++ b/xen/include/xen/hypercall.h
@@ -29,29 +29,29 @@ do_sched_op_compat(
 extern long
 do_sched_op(
     int cmd,
-    XEN_GUEST_HANDLE(void) arg);
+    XEN_GUEST_HANDLE_PARAM(void) arg);
 
 extern long
 do_domctl(
-    XEN_GUEST_HANDLE(xen_domctl_t) u_domctl);
+    XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl);
 
 extern long
 arch_do_domctl(
     struct xen_domctl *domctl,
-    XEN_GUEST_HANDLE(xen_domctl_t) u_domctl);
+    XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl);
 
 extern long
 do_sysctl(
-    XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl);
+    XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl);
 
 extern long
 arch_do_sysctl(
     struct xen_sysctl *sysctl,
-    XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl);
+    XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl);
 
 extern long
 do_platform_op(
-    XEN_GUEST_HANDLE(xen_platform_op_t) u_xenpf_op);
+    XEN_GUEST_HANDLE_PARAM(xen_platform_op_t) u_xenpf_op);
 
 /*
  * To allow safe resume of do_memory_op() after preemption, we need to know
@@ -64,11 +64,11 @@ do_platform_op(
 extern long
 do_memory_op(
     unsigned long cmd,
-    XEN_GUEST_HANDLE(void) arg);
+    XEN_GUEST_HANDLE_PARAM(void) arg);
 
 extern long
 do_multicall(
-    XEN_GUEST_HANDLE(multicall_entry_t) call_list,
+    XEN_GUEST_HANDLE_PARAM(multicall_entry_t) call_list,
     unsigned int nr_calls);
 
 extern long
@@ -77,23 +77,23 @@ do_set_timer_op(
 
 extern long
 do_event_channel_op(
-    int cmd, XEN_GUEST_HANDLE(void) arg);
+    int cmd, XEN_GUEST_HANDLE_PARAM(void) arg);
 
 extern long
 do_xen_version(
     int cmd,
-    XEN_GUEST_HANDLE(void) arg);
+    XEN_GUEST_HANDLE_PARAM(void) arg);
 
 extern long
 do_console_io(
     int cmd,
     int count,
-    XEN_GUEST_HANDLE(char) buffer);
+    XEN_GUEST_HANDLE_PARAM(char) buffer);
 
 extern long
 do_grant_table_op(
     unsigned int cmd,
-    XEN_GUEST_HANDLE(void) uop,
+    XEN_GUEST_HANDLE_PARAM(void) uop,
     unsigned int count);
 
 extern long
@@ -105,72 +105,72 @@ extern long
 do_vcpu_op(
     int cmd,
     int vcpuid,
-    XEN_GUEST_HANDLE(void) arg);
+    XEN_GUEST_HANDLE_PARAM(void) arg);
 
 struct vcpu;
 extern long
 arch_do_vcpu_op(int cmd,
     struct vcpu *v,
-    XEN_GUEST_HANDLE(void) arg);
+    XEN_GUEST_HANDLE_PARAM(void) arg);
 
 extern long
 do_nmi_op(
     unsigned int cmd,
-    XEN_GUEST_HANDLE(void) arg);
+    XEN_GUEST_HANDLE_PARAM(void) arg);
 
 extern long
 do_hvm_op(
     unsigned long op,
-    XEN_GUEST_HANDLE(void) arg);
+    XEN_GUEST_HANDLE_PARAM(void) arg);
 
 extern long
 do_kexec_op(
     unsigned long op,
     int arg1,
-    XEN_GUEST_HANDLE(void) arg);
+    XEN_GUEST_HANDLE_PARAM(void) arg);
 
 extern long
 do_xsm_op(
-    XEN_GUEST_HANDLE(xsm_op_t) u_xsm_op);
+    XEN_GUEST_HANDLE_PARAM(xsm_op_t) u_xsm_op);
 
 extern long
 do_tmem_op(
-    XEN_GUEST_HANDLE(tmem_op_t) uops);
+    XEN_GUEST_HANDLE_PARAM(tmem_op_t) uops);
 
 extern long
-do_xenoprof_op(int op, XEN_GUEST_HANDLE(void) arg);
+do_xenoprof_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg);
 
 #ifdef CONFIG_COMPAT
 
 extern int
 compat_memory_op(
     unsigned int cmd,
-    XEN_GUEST_HANDLE(void) arg);
+    XEN_GUEST_HANDLE_PARAM(void) arg);
 
 extern int
 compat_grant_table_op(
     unsigned int cmd,
-    XEN_GUEST_HANDLE(void) uop,
+    XEN_GUEST_HANDLE_PARAM(void) uop,
     unsigned int count);
 
 extern int
 compat_vcpu_op(
     int cmd,
     int vcpuid,
-    XEN_GUEST_HANDLE(void) arg);
+    XEN_GUEST_HANDLE_PARAM(void) arg);
 
 extern int
-compat_xenoprof_op(int op, XEN_GUEST_HANDLE(void) arg);
+compat_xenoprof_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg);
 
 extern int
 compat_xen_version(
     int cmd,
-    XEN_GUEST_HANDLE(void) arg);
+    XEN_GUEST_HANDLE_PARAM(void) arg);
 
 extern int
 compat_sched_op(
     int cmd,
-    XEN_GUEST_HANDLE(void) arg);
+    XEN_GUEST_HANDLE_PARAM(void) arg);
 
 extern int
 compat_set_timer_op(
diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index 605c7b3..773a6d7 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -156,7 +156,7 @@ void iommu_crash_shutdown(void);
 void iommu_set_dom0_mapping(struct domain *d);
 void iommu_share_p2m_table(struct domain *d);
 
-int iommu_do_domctl(struct xen_domctl *, XEN_GUEST_HANDLE(xen_domctl_t));
+int iommu_do_domctl(struct xen_domctl *, XEN_GUEST_HANDLE_PARAM(xen_domctl_t));
 
 void iommu_iotlb_flush(struct domain *d, unsigned long gfn, unsigned int page_count);
 void iommu_iotlb_flush_all(struct domain *d);
diff --git a/xen/include/xen/tmem_xen.h b/xen/include/xen/tmem_xen.h
index 9492810..36a8d9f 100644
--- a/xen/include/xen/tmem_xen.h
+++ b/xen/include/xen/tmem_xen.h
@@ -430,7 +430,8 @@ static inline void tmh_tze_copy_from_pfp(void *tva, pfp_t *pfp, pagesize_t len)
 typedef XEN_GUEST_HANDLE(void) cli_mfn_t;
 typedef XEN_GUEST_HANDLE(char) cli_va_t;
 */
-typedef XEN_GUEST_HANDLE(tmem_op_t) tmem_cli_op_t;
+typedef XEN_GUEST_HANDLE_PARAM(tmem_op_t) tmem_cli_op_t;
+typedef XEN_GUEST_HANDLE_PARAM(char) tmem_cli_va_param_t;
 
 static inline int tmh_get_tmemop_from_client(tmem_op_t *op, tmem_cli_op_t uops)
 {
@@ -466,8 +467,9 @@ static inline int tmh_get_tmemop_from_client(tmem_op_t *op, tmem_cli_op_t uops)
 
 #define tmh_cli_buf_null guest_handle_from_ptr(NULL, char)
 
-static inline void tmh_copy_to_client_buf_offset(tmem_cli_va_t clibuf, int off,
-                                           char *tmembuf, int len)
+static inline void tmh_copy_to_client_buf_offset(tmem_cli_va_param_t clibuf,
+						 int off,
+						 char *tmembuf, int len)
 {
     copy_to_guest_offset(clibuf,off,tmembuf,len);
 }
@@ -482,15 +484,17 @@ static inline void tmh_copy_to_client_buf_offset(tmem_cli_va_t clibuf, int off,
 #define tmh_cli_id_str "domid"
 #define tmh_client_str "domain"
 
-int tmh_decompress_to_client(tmem_cli_mfn_t, void *, size_t, tmem_cli_va_t);
+int tmh_decompress_to_client(tmem_cli_mfn_t, void *, size_t,
+			     tmem_cli_va_param_t);
 
-int tmh_compress_from_client(tmem_cli_mfn_t, void **, size_t *, tmem_cli_va_t);
+int tmh_compress_from_client(tmem_cli_mfn_t, void **, size_t *,
+			     tmem_cli_va_param_t);
 
 int tmh_copy_from_client(pfp_t *, tmem_cli_mfn_t, pagesize_t tmem_offset,
-    pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_t);
+    pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_param_t);
 
 int tmh_copy_to_client(tmem_cli_mfn_t, pfp_t *, pagesize_t tmem_offset,
-    pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_t);
+    pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_param_t);
 
 extern int tmh_copy_tze_to_client(tmem_cli_mfn_t cmfn, void *tmem_va, pagesize_t len);
 
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 593cdbd..a949c1e 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -139,7 +139,7 @@ struct xsm_operations {
     int (*cpupool_op)(void);
     int (*sched_op)(void);
 
-    long (*__do_xsm_op) (XEN_GUEST_HANDLE(xsm_op_t) op);
+    long (*__do_xsm_op) (XEN_GUEST_HANDLE_PARAM(xsm_op_t) op);
 
 #ifdef CONFIG_X86
     int (*shadow_control) (struct domain *d, uint32_t op);
@@ -585,7 +585,7 @@ static inline int xsm_sched_op(void)
     return xsm_call(sched_op());
 }
 
-static inline long __do_xsm_op (XEN_GUEST_HANDLE(xsm_op_t) op)
+static inline long __do_xsm_op (XEN_GUEST_HANDLE_PARAM(xsm_op_t) op)
 {
 #ifdef XSM_ENABLE
     return xsm_ops->__do_xsm_op(op);
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 4836fc0..b726eaf 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -380,7 +380,7 @@ static int dummy_sched_op (void)
     return 0;
 }
 
-static long dummy___do_xsm_op(XEN_GUEST_HANDLE(xsm_op_t) op)
+static long dummy___do_xsm_op(XEN_GUEST_HANDLE_PARAM(xsm_op_t) op)
 {
     return -ENOSYS;
 }
diff --git a/xen/xsm/flask/flask_op.c b/xen/xsm/flask/flask_op.c
index 9c8dfe7..a5d7748 100644
--- a/xen/xsm/flask/flask_op.c
+++ b/xen/xsm/flask/flask_op.c
@@ -71,7 +71,7 @@ static int domain_has_security(struct domain *d, u32 perms)
                         perms, NULL);
 }
 
-static int flask_copyin_string(XEN_GUEST_HANDLE(char) u_buf, char **buf, uint32_t size)
+static int flask_copyin_string(XEN_GUEST_HANDLE_PARAM(char) u_buf, char **buf, uint32_t size)
 {
     char *tmp = xmalloc_bytes(size + 1);
     if ( !tmp )
@@ -618,7 +618,7 @@ static int flask_relabel_domain(struct xen_flask_relabel *arg)
     return rc;
 }
 
-long do_flask_op(XEN_GUEST_HANDLE(xsm_op_t) u_flask_op)
+long do_flask_op(XEN_GUEST_HANDLE_PARAM(xsm_op_t) u_flask_op)
 {
     xen_flask_op_t op;
     int rv;
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 88fef9c..0ca10d0 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1462,7 +1462,7 @@ static int flask_vcpuextstate (struct domain *d, uint32_t cmd)
 }
 #endif
 
-long do_flask_op(XEN_GUEST_HANDLE(xsm_op_t) u_flask_op);
+long do_flask_op(XEN_GUEST_HANDLE_PARAM(xsm_op_t) u_flask_op);
 
 static struct xsm_operations flask_ops = {
     .security_domaininfo = flask_security_domaininfo,
diff --git a/xen/xsm/xsm_core.c b/xen/xsm/xsm_core.c
index 96c8669..46287cb 100644
--- a/xen/xsm/xsm_core.c
+++ b/xen/xsm/xsm_core.c
@@ -111,7 +111,7 @@ int unregister_xsm(struct xsm_operations *ops)
 
 #endif
 
-long do_xsm_op (XEN_GUEST_HANDLE(xsm_op_t) op)
+long do_xsm_op (XEN_GUEST_HANDLE_PARAM(xsm_op_t) op)
 {
     return __do_xsm_op(op);
 }
-- 
1.7.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 15:21:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 15:21:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNmTO-0004XP-PV; Mon, 15 Oct 2012 15:20:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNmTM-0004W7-TT
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 15:20:53 +0000
Received: from [85.158.138.51:17021] by server-10.bemta-3.messagelabs.com id
	3D/8E-27386-3D92C705; Mon, 15 Oct 2012 15:20:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1350314445!26846382!6
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODI0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3059 invoked from network); 15 Oct 2012 15:20:51 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 15:20:51 -0000
X-IronPort-AV: E=Sophos;i="4.80,588,1344211200"; d="scan'208";a="211302574"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 15:20:46 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 11:20:45 -0400
Received: from [10.80.246.74] (helo=army.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TNmTF-0007YE-5i;
	Mon, 15 Oct 2012 16:20:45 +0100
From: Ian Campbell 
To: 
Date: Mon, 15 Oct 2012 15:20:41 +0000
Message-ID: <1350314444-17148-8-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
References: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Keir Fraser , Ian Campbell ,
	Stefano Stabellini ,
	Tim Deegan ,
	Stefano Stabellini ,
	Jan Beulich 
Subject: [Xen-devel] [PATCH 08/10] xen: more XEN_GUEST_HANDLE_PARAM
	substitutions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Stefano Stabellini 

More substitutions in this patch, not as obvious as the ones in the
previous patch.

Signed-off-by: Stefano Stabellini 
Signed-off-by: Ian Campbell 
Cc: keir@xen.org
Cc: JBeulich@suse.com
---
ijc v2:
  - Avoid _t suffix on variable names, use _param instead.
---
 xen/arch/x86/mm.c                        |   12 +++++++++---
 xen/arch/x86/oprofile/backtrace.c        |    5 ++++-
 xen/arch/x86/platform_hypercall.c        |   10 +++++++---
 xen/arch/x86/x86_64/cpu_idle.c           |    4 +++-
 xen/arch/x86/x86_64/cpufreq.c            |    4 +++-
 xen/arch/x86/x86_64/platform_hypercall.c |    1 +
 xen/common/compat/multicall.c            |    1 +
 xen/common/multicall.c                   |    2 +-
 8 files changed, 29 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 9a828de..191f5ea 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2913,7 +2913,9 @@ long do_mmuext_op(
         {
             cpumask_t pmask;
 
-            if ( unlikely(vcpumask_to_pcpumask(d, op.arg2.vcpumask, &pmask)) )
+            if ( unlikely(vcpumask_to_pcpumask(d,
+                            guest_handle_to_param(op.arg2.vcpumask, const_void),
+                            &pmask)) )
             {
                 okay = 0;
                 break;
@@ -4195,6 +4197,7 @@ static int handle_iomem_range(unsigned long s, unsigned long e, void *p)
     if ( s > ctxt->s )
     {
         e820entry_t ent;
+        XEN_GUEST_HANDLE_PARAM(e820entry_t) buffer_param;
         XEN_GUEST_HANDLE(e820entry_t) buffer;
 
         if ( ctxt->n + 1 >= ctxt->map.nr_entries )
@@ -4202,7 +4205,8 @@ static int handle_iomem_range(unsigned long s, unsigned long e, void *p)
         ent.addr = (uint64_t)ctxt->s << PAGE_SHIFT;
         ent.size = (uint64_t)(s - ctxt->s) << PAGE_SHIFT;
         ent.type = E820_RESERVED;
-        buffer = guest_handle_cast(ctxt->map.buffer, e820entry_t);
+        buffer_param = guest_handle_cast(ctxt->map.buffer, e820entry_t);
+        buffer = guest_handle_from_param(buffer_param, e820entry_t);
         if ( __copy_to_guest_offset(buffer, ctxt->n, &ent, 1) )
             return -EFAULT;
         ctxt->n++;
@@ -4499,6 +4503,7 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg)
     {
         struct memory_map_context ctxt;
         XEN_GUEST_HANDLE(e820entry_t) buffer;
+        XEN_GUEST_HANDLE_PARAM(e820entry_t) buffer_param;
         unsigned int i;
 
         if ( !IS_PRIV(current->domain) )
@@ -4513,7 +4518,8 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg)
         if ( ctxt.map.nr_entries < e820.nr_map + 1 )
             return -EINVAL;
 
-        buffer = guest_handle_cast(ctxt.map.buffer, e820entry_t);
+        buffer_param = guest_handle_cast(ctxt.map.buffer, e820entry_t);
+        buffer = guest_handle_from_param(buffer_param, e820entry_t);
         if ( !guest_handle_okay(buffer, ctxt.map.nr_entries) )
             return -EFAULT;
 
diff --git a/xen/arch/x86/oprofile/backtrace.c b/xen/arch/x86/oprofile/backtrace.c
index 433f881..b3ea7f3 100644
--- a/xen/arch/x86/oprofile/backtrace.c
+++ b/xen/arch/x86/oprofile/backtrace.c
@@ -74,8 +74,11 @@ dump_guest_backtrace(struct vcpu *vcpu, const struct frame_head *head,
     }
     else
     {
-        XEN_GUEST_HANDLE(const_frame_head_t) guest_head =
+        XEN_GUEST_HANDLE(const_frame_head_t) guest_head;
+        XEN_GUEST_HANDLE_PARAM(const_frame_head_t) guest_head_param =
             const_guest_handle_from_ptr(head, frame_head_t);
+        guest_head = guest_handle_from_param(guest_head_param,
+					     const_frame_head_t);
 
         /* Also check accessibility of one struct frame_head beyond */
         if (!guest_handle_okay(guest_head, 2))
diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hypercall.c
index 073a2ea..a3b5a6b 100644
--- a/xen/arch/x86/platform_hypercall.c
+++ b/xen/arch/x86/platform_hypercall.c
@@ -61,7 +61,7 @@ long cpu_down_helper(void *data);
 long core_parking_helper(void *data);
 uint32_t get_cur_idle_nums(void);
 
-ret_t do_platform_op(XEN_GUEST_HANDLE(xen_platform_op_t) u_xenpf_op)
+ret_t do_platform_op(XEN_GUEST_HANDLE_PARAM(xen_platform_op_t) u_xenpf_op)
 {
     ret_t ret = 0;
     struct xen_platform_op curop, *op = &curop;
@@ -186,7 +186,9 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xen_platform_op_t) u_xenpf_op)
             }
         }
 
-        ret = microcode_update(data, op->u.microcode.length);
+        ret = microcode_update(
+                guest_handle_to_param(data, const_void),
+                op->u.microcode.length);
         spin_unlock(&vcpu_alloc_lock);
     }
     break;
@@ -454,7 +456,9 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xen_platform_op_t) u_xenpf_op)
             XEN_GUEST_HANDLE(uint32) pdc;
 
             guest_from_compat_handle(pdc, op->u.set_pminfo.u.pdc);
-            ret = acpi_set_pdc_bits(op->u.set_pminfo.id, pdc);
+            ret = acpi_set_pdc_bits(
+                    op->u.set_pminfo.id,
+                    guest_handle_to_param(pdc, uint32));
         }
         break;
 
diff --git a/xen/arch/x86/x86_64/cpu_idle.c b/xen/arch/x86/x86_64/cpu_idle.c
index 3e7422f..dfc7e84 100644
--- a/xen/arch/x86/x86_64/cpu_idle.c
+++ b/xen/arch/x86/x86_64/cpu_idle.c
@@ -57,10 +57,12 @@ static int copy_from_compat_state(xen_processor_cx_t *xen_state,
 {
 #define XLAT_processor_cx_HNDL_dp(_d_, _s_) do { \
     XEN_GUEST_HANDLE(compat_processor_csd_t) dps; \
+    XEN_GUEST_HANDLE_PARAM(xen_processor_csd_t) dps_param; \
     if ( unlikely(!compat_handle_okay((_s_)->dp, (_s_)->dpcnt)) ) \
             return -EFAULT; \
     guest_from_compat_handle(dps, (_s_)->dp); \
-    (_d_)->dp = guest_handle_cast(dps, xen_processor_csd_t); \
+    dps_param = guest_handle_cast(dps, xen_processor_csd_t); \
+    (_d_)->dp = guest_handle_from_param(dps_param, xen_processor_csd_t); \
 } while (0)
     XLAT_processor_cx(xen_state, state);
 #undef XLAT_processor_cx_HNDL_dp
diff --git a/xen/arch/x86/x86_64/cpufreq.c b/xen/arch/x86/x86_64/cpufreq.c
index ce9864e..1956777 100644
--- a/xen/arch/x86/x86_64/cpufreq.c
+++ b/xen/arch/x86/x86_64/cpufreq.c
@@ -45,10 +45,12 @@ compat_set_px_pminfo(uint32_t cpu, struct compat_processor_performance *perf)
 
 #define XLAT_processor_performance_HNDL_states(_d_, _s_) do { \
     XEN_GUEST_HANDLE(compat_processor_px_t) states; \
+    XEN_GUEST_HANDLE_PARAM(xen_processor_px_t) states_t; \
     if ( unlikely(!compat_handle_okay((_s_)->states, (_s_)->state_count)) ) \
         return -EFAULT; \
     guest_from_compat_handle(states, (_s_)->states); \
-    (_d_)->states = guest_handle_cast(states, xen_processor_px_t); \
+    states_t = guest_handle_cast(states, xen_processor_px_t); \
+    (_d_)->states = guest_handle_from_param(states_t, xen_processor_px_t); \
 } while (0)
 
     XLAT_processor_performance(xen_perf, perf);
diff --git a/xen/arch/x86/x86_64/platform_hypercall.c b/xen/arch/x86/x86_64/platform_hypercall.c
index 188aa37..744796d 100644
--- a/xen/arch/x86/x86_64/platform_hypercall.c
+++ b/xen/arch/x86/x86_64/platform_hypercall.c
@@ -38,6 +38,7 @@ CHECK_pf_pcpu_version;
 
 #define COMPAT
 #define _XEN_GUEST_HANDLE(t) XEN_GUEST_HANDLE(t)
+#define _XEN_GUEST_HANDLE_PARAM(t) XEN_GUEST_HANDLE_PARAM(t)
 typedef int ret_t;
 
 #include "../platform_hypercall.c"
diff --git a/xen/common/compat/multicall.c b/xen/common/compat/multicall.c
index e7e2a40..3219d3c 100644
--- a/xen/common/compat/multicall.c
+++ b/xen/common/compat/multicall.c
@@ -25,6 +25,7 @@ DEFINE_XEN_GUEST_HANDLE(multicall_entry_compat_t);
 #define call                 compat_call
 #define do_multicall(l, n)   compat_multicall(_##l, n)
 #define _XEN_GUEST_HANDLE(t) XEN_GUEST_HANDLE(t)
+#define _XEN_GUEST_HANDLE_PARAM(t) XEN_GUEST_HANDLE(t)
 
 static void __trace_multicall_call(multicall_entry_t *call)
 {
diff --git a/xen/common/multicall.c b/xen/common/multicall.c
index ca1839d..7e557e5 100644
--- a/xen/common/multicall.c
+++ b/xen/common/multicall.c
@@ -35,7 +35,7 @@ static void trace_multicall_call(multicall_entry_t *call)
 
 ret_t
 do_multicall(
-    XEN_GUEST_HANDLE(multicall_entry_t) call_list, unsigned int nr_calls)
+    XEN_GUEST_HANDLE_PARAM(multicall_entry_t) call_list, unsigned int nr_calls)
 {
     struct mc_state *mcs = ¤t->mc_state;
     unsigned int     i;
-- 
1.7.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 15:21:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 15:21:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNmTQ-0004Yq-S2; Mon, 15 Oct 2012 15:20:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNmTP-0004VD-4Z
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 15:20:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1350314446!8639953!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYzNjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22232 invoked from network); 15 Oct 2012 15:20:48 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 15:20:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,588,1344211200"; d="scan'208";a="41237265"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 15:20:46 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 11:20:45 -0400
Received: from [10.80.246.74] (helo=army.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TNmTF-0007YE-2K;
	Mon, 15 Oct 2012 16:20:45 +0100
From: Ian Campbell 
To: 
Date: Mon, 15 Oct 2012 15:20:40 +0000
Message-ID: <1350314444-17148-7-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
References: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Keir Fraser , Ian Campbell ,
	Stefano Stabellini ,
	Tim Deegan ,
	Stefano Stabellini ,
	Jan Beulich 
Subject: [Xen-devel] [PATCH 07/10] xen: replace XEN_GUEST_HANDLE with
	XEN_GUEST_HANDLE_PARAM when appropriate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Stefano Stabellini 

Note: these changes don't make any difference on x86.

Replace XEN_GUEST_HANDLE with XEN_GUEST_HANDLE_PARAM when it is used as
an hypercall argument.

Signed-off-by: Stefano Stabellini 
Signed-off-by: Ian Campbell 
Cc: keir@xen.org
Cc: JBeulich@suse.com
---
ijc v2: - correct usage of guest handle paramters in tmem
        - defer some changes to next patch to avoid temporarily
          breaking the build.
---
 xen/arch/arm/domain.c            |    2 +-
 xen/arch/arm/domctl.c            |    2 +-
 xen/arch/arm/hvm.c               |    2 +-
 xen/arch/arm/mm.c                |    2 +-
 xen/arch/arm/physdev.c           |    2 +-
 xen/arch/arm/sysctl.c            |    2 +-
 xen/arch/x86/compat.c            |    2 +-
 xen/arch/x86/cpu/mcheck/mce.c    |    2 +-
 xen/arch/x86/domain.c            |    2 +-
 xen/arch/x86/domctl.c            |    2 +-
 xen/arch/x86/efi/runtime.c       |    2 +-
 xen/arch/x86/hvm/hvm.c           |   26 +++++++++---------
 xen/arch/x86/microcode.c         |    2 +-
 xen/arch/x86/mm.c                |   14 +++++-----
 xen/arch/x86/mm/hap/hap.c        |    2 +-
 xen/arch/x86/mm/mem_event.c      |    2 +-
 xen/arch/x86/mm/paging.c         |    2 +-
 xen/arch/x86/mm/shadow/common.c  |    2 +-
 xen/arch/x86/oprofile/xenoprof.c |    6 ++--
 xen/arch/x86/physdev.c           |    2 +-
 xen/arch/x86/sysctl.c            |    2 +-
 xen/arch/x86/traps.c             |    2 +-
 xen/arch/x86/x86_64/compat/mm.c  |   10 +++---
 xen/arch/x86/x86_64/domain.c     |    2 +-
 xen/arch/x86/x86_64/mm.c         |    2 +-
 xen/arch/x86/x86_64/traps.c      |    2 +-
 xen/common/compat/domain.c       |    2 +-
 xen/common/compat/grant_table.c  |    8 +++---
 xen/common/compat/memory.c       |    4 +-
 xen/common/domain.c              |    2 +-
 xen/common/domctl.c              |    2 +-
 xen/common/event_channel.c       |    2 +-
 xen/common/grant_table.c         |   36 +++++++++++++-------------
 xen/common/kernel.c              |    4 +-
 xen/common/kexec.c               |   17 ++++++------
 xen/common/memory.c              |    4 +-
 xen/common/schedule.c            |    2 +-
 xen/common/sysctl.c              |    2 +-
 xen/common/tmem.c                |   45 ++++++++++++++++++--------------
 xen/common/tmem_xen.c            |    8 +++---
 xen/common/xenoprof.c            |    8 +++---
 xen/drivers/acpi/pmstat.c        |    2 +-
 xen/drivers/char/console.c       |    6 ++--
 xen/drivers/passthrough/iommu.c  |    2 +-
 xen/include/asm-arm/hypercall.h  |    2 +-
 xen/include/asm-arm/mm.h         |    2 +-
 xen/include/asm-x86/hap.h        |    2 +-
 xen/include/asm-x86/hypercall.h  |   22 ++++++++--------
 xen/include/asm-x86/mem_event.h  |    2 +-
 xen/include/asm-x86/mm.h         |    8 +++---
 xen/include/asm-x86/paging.h     |    2 +-
 xen/include/asm-x86/processor.h  |    2 +-
 xen/include/asm-x86/shadow.h     |    2 +-
 xen/include/asm-x86/xenoprof.h   |    6 ++--
 xen/include/xen/acpi.h           |    4 +-
 xen/include/xen/compat.h         |    3 ++
 xen/include/xen/hypercall.h      |   52 +++++++++++++++++++-------------------
 xen/include/xen/iommu.h          |    2 +-
 xen/include/xen/tmem_xen.h       |   18 ++++++++-----
 xen/include/xsm/xsm.h            |    4 +-
 xen/xsm/dummy.c                  |    2 +-
 xen/xsm/flask/flask_op.c         |    4 +-
 xen/xsm/flask/hooks.c            |    2 +-
 xen/xsm/xsm_core.c               |    2 +-
 64 files changed, 206 insertions(+), 193 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index f47db4f..c5292c7 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -519,7 +519,7 @@ void arch_dump_domain_info(struct domain *d)
 {
 }
 
-long arch_do_vcpu_op(int cmd, struct vcpu *v, XEN_GUEST_HANDLE(void) arg)
+long arch_do_vcpu_op(int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     return -ENOSYS;
 }
diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
index 1a5f79f..cf16791 100644
--- a/xen/arch/arm/domctl.c
+++ b/xen/arch/arm/domctl.c
@@ -11,7 +11,7 @@
 #include 
 
 long arch_do_domctl(struct xen_domctl *domctl,
-                    XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
+                    XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
 {
     return -ENOSYS;
 }
diff --git a/xen/arch/arm/hvm.c b/xen/arch/arm/hvm.c
index c11378d..40f519e 100644
--- a/xen/arch/arm/hvm.c
+++ b/xen/arch/arm/hvm.c
@@ -11,7 +11,7 @@
 
 #include 
 
-long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
+long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
 
 {
     long rc = 0;
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index edd5ca7..e8fff8f 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -579,7 +579,7 @@ out:
 
 }
 
-long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
+long arch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     int rc;
 
diff --git a/xen/arch/arm/physdev.c b/xen/arch/arm/physdev.c
index bcf4337..0801e8c 100644
--- a/xen/arch/arm/physdev.c
+++ b/xen/arch/arm/physdev.c
@@ -11,7 +11,7 @@
 #include 
 
 
-int do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
+int do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     printk("%s %d cmd=%d: not implemented yet\n", __func__, __LINE__, cmd);
     return -ENOSYS;
diff --git a/xen/arch/arm/sysctl.c b/xen/arch/arm/sysctl.c
index e8e1c0d..a286abe 100644
--- a/xen/arch/arm/sysctl.c
+++ b/xen/arch/arm/sysctl.c
@@ -13,7 +13,7 @@
 #include 
 
 long arch_do_sysctl(struct xen_sysctl *sysctl,
-                    XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl)
+                    XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
 {
     return -ENOSYS;
 }
diff --git a/xen/arch/x86/compat.c b/xen/arch/x86/compat.c
index a4fda06..2d05867 100644
--- a/xen/arch/x86/compat.c
+++ b/xen/arch/x86/compat.c
@@ -27,7 +27,7 @@ ret_t do_physdev_op_compat(XEN_GUEST_HANDLE(physdev_op_t) uop)
 #ifndef COMPAT
 
 /* Legacy hypercall (as of 0x00030202). */
-long do_event_channel_op_compat(XEN_GUEST_HANDLE(evtchn_op_t) uop)
+long do_event_channel_op_compat(XEN_GUEST_HANDLE_PARAM(evtchn_op_t) uop)
 {
     struct evtchn_op op;
 
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index 6f8c6f9..75f0f73 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -1289,7 +1289,7 @@ CHECK_mcinfo_recovery;
 # undef xen_mcinfo_recovery
 
 /* Machine Check Architecture Hypercall */
-long do_mca(XEN_GUEST_HANDLE(xen_mc_t) u_xen_mc)
+long do_mca(XEN_GUEST_HANDLE_PARAM(xen_mc_t) u_xen_mc)
 {
     long ret = 0;
     struct xen_mc curop, *op = &curop;
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 58766ba..233c597 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1077,7 +1077,7 @@ map_vcpu_info(struct vcpu *v, unsigned long gfn, unsigned offset)
 
 long
 arch_do_vcpu_op(
-    int cmd, struct vcpu *v, XEN_GUEST_HANDLE(void) arg)
+    int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     long rc = 0;
 
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 24b3178..c3d6093 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -48,7 +48,7 @@ static int gdbsx_guest_mem_io(
 
 long arch_do_domctl(
     struct xen_domctl *domctl,
-    XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
+    XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
 {
     long ret = 0;
 
diff --git a/xen/arch/x86/efi/runtime.c b/xen/arch/x86/efi/runtime.c
index 1dbe2db..b2ff495 100644
--- a/xen/arch/x86/efi/runtime.c
+++ b/xen/arch/x86/efi/runtime.c
@@ -184,7 +184,7 @@ int efi_get_info(uint32_t idx, union xenpf_efi_info *info)
     return 0;
 }
 
-static long gwstrlen(XEN_GUEST_HANDLE(CHAR16) str)
+static long gwstrlen(XEN_GUEST_HANDLE_PARAM(CHAR16) str)
 {
     unsigned long len;
 
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index a5a1bcf..b83e336 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3091,14 +3091,14 @@ static int grant_table_op_is_allowed(unsigned int cmd)
 }
 
 static long hvm_grant_table_op(
-    unsigned int cmd, XEN_GUEST_HANDLE(void) uop, unsigned int count)
+    unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) uop, unsigned int count)
 {
     if ( !grant_table_op_is_allowed(cmd) )
         return -ENOSYS; /* all other commands need auditing */
     return do_grant_table_op(cmd, uop, count);
 }
 
-static long hvm_memory_op(int cmd, XEN_GUEST_HANDLE(void) arg)
+static long hvm_memory_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     long rc;
 
@@ -3116,7 +3116,7 @@ static long hvm_memory_op(int cmd, XEN_GUEST_HANDLE(void) arg)
     return do_memory_op(cmd, arg);
 }
 
-static long hvm_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
+static long hvm_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     switch ( cmd )
     {
@@ -3132,7 +3132,7 @@ static long hvm_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
 }
 
 static long hvm_vcpu_op(
-    int cmd, int vcpuid, XEN_GUEST_HANDLE(void) arg)
+    int cmd, int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     long rc;
 
@@ -3163,7 +3163,7 @@ typedef unsigned long hvm_hypercall_t(
     [ __HYPERVISOR_ ## x ] = (hvm_hypercall_t *) do_ ## x
 
 static long hvm_grant_table_op_compat32(unsigned int cmd,
-                                        XEN_GUEST_HANDLE(void) uop,
+                                        XEN_GUEST_HANDLE_PARAM(void) uop,
                                         unsigned int count)
 {
     if ( !grant_table_op_is_allowed(cmd) )
@@ -3171,7 +3171,7 @@ static long hvm_grant_table_op_compat32(unsigned int cmd,
     return compat_grant_table_op(cmd, uop, count);
 }
 
-static long hvm_memory_op_compat32(int cmd, XEN_GUEST_HANDLE(void) arg)
+static long hvm_memory_op_compat32(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     int rc;
 
@@ -3190,7 +3190,7 @@ static long hvm_memory_op_compat32(int cmd, XEN_GUEST_HANDLE(void) arg)
 }
 
 static long hvm_vcpu_op_compat32(
-    int cmd, int vcpuid, XEN_GUEST_HANDLE(void) arg)
+    int cmd, int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     long rc;
 
@@ -3214,7 +3214,7 @@ static long hvm_vcpu_op_compat32(
 }
 
 static long hvm_physdev_op_compat32(
-    int cmd, XEN_GUEST_HANDLE(void) arg)
+    int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     switch ( cmd )
     {
@@ -3380,7 +3380,7 @@ void hvm_hypercall_page_initialise(struct domain *d,
 }
 
 static int hvmop_set_pci_intx_level(
-    XEN_GUEST_HANDLE(xen_hvm_set_pci_intx_level_t) uop)
+    XEN_GUEST_HANDLE_PARAM(xen_hvm_set_pci_intx_level_t) uop)
 {
     struct xen_hvm_set_pci_intx_level op;
     struct domain *d;
@@ -3547,7 +3547,7 @@ static void hvm_s3_resume(struct domain *d)
 }
 
 static int hvmop_set_isa_irq_level(
-    XEN_GUEST_HANDLE(xen_hvm_set_isa_irq_level_t) uop)
+    XEN_GUEST_HANDLE_PARAM(xen_hvm_set_isa_irq_level_t) uop)
 {
     struct xen_hvm_set_isa_irq_level op;
     struct domain *d;
@@ -3591,7 +3591,7 @@ static int hvmop_set_isa_irq_level(
 }
 
 static int hvmop_set_pci_link_route(
-    XEN_GUEST_HANDLE(xen_hvm_set_pci_link_route_t) uop)
+    XEN_GUEST_HANDLE_PARAM(xen_hvm_set_pci_link_route_t) uop)
 {
     struct xen_hvm_set_pci_link_route op;
     struct domain *d;
@@ -3624,7 +3624,7 @@ static int hvmop_set_pci_link_route(
 }
 
 static int hvmop_inject_msi(
-    XEN_GUEST_HANDLE(xen_hvm_inject_msi_t) uop)
+    XEN_GUEST_HANDLE_PARAM(xen_hvm_inject_msi_t) uop)
 {
     struct xen_hvm_inject_msi op;
     struct domain *d;
@@ -3708,7 +3708,7 @@ static int hvm_replace_event_channel(struct vcpu *v, domid_t remote_domid,
     return 0;
 }
 
-long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
+long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
 
 {
     struct domain *curr_d = current->domain;
diff --git a/xen/arch/x86/microcode.c b/xen/arch/x86/microcode.c
index fe51034..fbbf95b 100644
--- a/xen/arch/x86/microcode.c
+++ b/xen/arch/x86/microcode.c
@@ -195,7 +195,7 @@ static long do_microcode_update(void *_info)
     return error;
 }
 
-int microcode_update(XEN_GUEST_HANDLE(const_void) buf, unsigned long len)
+int microcode_update(XEN_GUEST_HANDLE_PARAM(const_void) buf, unsigned long len)
 {
     int ret;
     struct microcode_info *info;
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 8ab92c9..9a828de 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2652,7 +2652,7 @@ static void put_pg_owner(struct domain *pg_owner)
 }
 
 static inline int vcpumask_to_pcpumask(
-    struct domain *d, XEN_GUEST_HANDLE(const_void) bmap, cpumask_t *pmask)
+    struct domain *d, XEN_GUEST_HANDLE_PARAM(const_void) bmap, cpumask_t *pmask)
 {
     unsigned int vcpu_id, vcpu_bias, offs;
     unsigned long vmask;
@@ -2692,9 +2692,9 @@ static inline int vcpumask_to_pcpumask(
 #define fixunmap_domain_page(ptr) ((void)(ptr))
 
 long do_mmuext_op(
-    XEN_GUEST_HANDLE(mmuext_op_t) uops,
+    XEN_GUEST_HANDLE_PARAM(mmuext_op_t) uops,
     unsigned int count,
-    XEN_GUEST_HANDLE(uint) pdone,
+    XEN_GUEST_HANDLE_PARAM(uint) pdone,
     unsigned int foreigndom)
 {
     struct mmuext_op op;
@@ -3151,9 +3151,9 @@ long do_mmuext_op(
 }
 
 long do_mmu_update(
-    XEN_GUEST_HANDLE(mmu_update_t) ureqs,
+    XEN_GUEST_HANDLE_PARAM(mmu_update_t) ureqs,
     unsigned int count,
-    XEN_GUEST_HANDLE(uint) pdone,
+    XEN_GUEST_HANDLE_PARAM(uint) pdone,
     unsigned int foreigndom)
 {
     struct mmu_update req;
@@ -4098,7 +4098,7 @@ long set_gdt(struct vcpu *v,
 }
 
 
-long do_set_gdt(XEN_GUEST_HANDLE(ulong) frame_list, unsigned int entries)
+long do_set_gdt(XEN_GUEST_HANDLE_PARAM(ulong) frame_list, unsigned int entries)
 {
     int nr_pages = (entries + 511) / 512;
     unsigned long frames[16];
@@ -4370,7 +4370,7 @@ static int xenmem_add_to_physmap(struct domain *d,
     return xenmem_add_to_physmap_once(d, xatp);
 }
 
-long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
+long arch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     int rc;
 
diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index d2637d3..fd99cde 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -571,7 +571,7 @@ void hap_teardown(struct domain *d)
 }
 
 int hap_domctl(struct domain *d, xen_domctl_shadow_op_t *sc,
-               XEN_GUEST_HANDLE(void) u_domctl)
+               XEN_GUEST_HANDLE_PARAM(void) u_domctl)
 {
     int rc, preempted = 0;
 
diff --git a/xen/arch/x86/mm/mem_event.c b/xen/arch/x86/mm/mem_event.c
index 942c19e..27d1cf4 100644
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -512,7 +512,7 @@ void mem_event_cleanup(struct domain *d)
 }
 
 int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
-                     XEN_GUEST_HANDLE(void) u_domctl)
+                     XEN_GUEST_HANDLE_PARAM(void) u_domctl)
 {
     int rc;
 
diff --git a/xen/arch/x86/mm/paging.c b/xen/arch/x86/mm/paging.c
index ca879f9..ea44e39 100644
--- a/xen/arch/x86/mm/paging.c
+++ b/xen/arch/x86/mm/paging.c
@@ -654,7 +654,7 @@ void paging_vcpu_init(struct vcpu *v)
 
 
 int paging_domctl(struct domain *d, xen_domctl_shadow_op_t *sc,
-                  XEN_GUEST_HANDLE(void) u_domctl)
+                  XEN_GUEST_HANDLE_PARAM(void) u_domctl)
 {
     int rc;
 
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index 3f8ad88..ce79131 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -3641,7 +3641,7 @@ out:
 
 int shadow_domctl(struct domain *d, 
                   xen_domctl_shadow_op_t *sc,
-                  XEN_GUEST_HANDLE(void) u_domctl)
+                  XEN_GUEST_HANDLE_PARAM(void) u_domctl)
 {
     int rc, preempted = 0;
 
diff --git a/xen/arch/x86/oprofile/xenoprof.c b/xen/arch/x86/oprofile/xenoprof.c
index 160abac..90ef67d 100644
--- a/xen/arch/x86/oprofile/xenoprof.c
+++ b/xen/arch/x86/oprofile/xenoprof.c
@@ -17,7 +17,7 @@
 
 #include "op_counter.h"
 
-int xenoprof_arch_counter(XEN_GUEST_HANDLE(void) arg)
+int xenoprof_arch_counter(XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     struct xenoprof_counter counter;
 
@@ -37,7 +37,7 @@ int xenoprof_arch_counter(XEN_GUEST_HANDLE(void) arg)
     return 0;
 }
 
-int xenoprof_arch_ibs_counter(XEN_GUEST_HANDLE(void) arg)
+int xenoprof_arch_ibs_counter(XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     struct xenoprof_ibs_counter ibs_counter;
 
@@ -54,7 +54,7 @@ int xenoprof_arch_ibs_counter(XEN_GUEST_HANDLE(void) arg)
     return 0;
 }
 
-int compat_oprof_arch_counter(XEN_GUEST_HANDLE(void) arg)
+int compat_oprof_arch_counter(XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     struct compat_oprof_counter counter;
 
diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index 984c813..751cbd4 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -258,7 +258,7 @@ int physdev_unmap_pirq(domid_t domid, int pirq)
 }
 #endif /* COMPAT */
 
-ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
+ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     int irq;
     ret_t ret;
diff --git a/xen/arch/x86/sysctl.c b/xen/arch/x86/sysctl.c
index 379f071..b84dd34 100644
--- a/xen/arch/x86/sysctl.c
+++ b/xen/arch/x86/sysctl.c
@@ -58,7 +58,7 @@ long cpu_down_helper(void *data)
 }
 
 long arch_do_sysctl(
-    struct xen_sysctl *sysctl, XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl)
+    struct xen_sysctl *sysctl, XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
 {
     long ret = 0;
 
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index de08e25..dfaf78e 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -3536,7 +3536,7 @@ int send_guest_trap(struct domain *d, uint16_t vcpuid, unsigned int trap_nr)
 }
 
 
-long do_set_trap_table(XEN_GUEST_HANDLE(const_trap_info_t) traps)
+long do_set_trap_table(XEN_GUEST_HANDLE_PARAM(const_trap_info_t) traps)
 {
     struct trap_info cur;
     struct vcpu *curr = current;
diff --git a/xen/arch/x86/x86_64/compat/mm.c b/xen/arch/x86/x86_64/compat/mm.c
index f497503..d1eb785 100644
--- a/xen/arch/x86/x86_64/compat/mm.c
+++ b/xen/arch/x86/x86_64/compat/mm.c
@@ -5,7 +5,7 @@
 #include 
 #include 
 
-int compat_set_gdt(XEN_GUEST_HANDLE(uint) frame_list, unsigned int entries)
+int compat_set_gdt(XEN_GUEST_HANDLE_PARAM(uint) frame_list, unsigned int entries)
 {
     unsigned int i, nr_pages = (entries + 511) / 512;
     unsigned long frames[16];
@@ -44,7 +44,7 @@ int compat_update_descriptor(u32 pa_lo, u32 pa_hi, u32 desc_lo, u32 desc_hi)
                                 desc_lo | ((u64)desc_hi << 32));
 }
 
-int compat_arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
+int compat_arch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     struct compat_machphys_mfn_list xmml;
     l2_pgentry_t l2e;
@@ -260,14 +260,14 @@ int compat_update_va_mapping_otherdomain(unsigned long va, u32 lo, u32 hi,
 
 DEFINE_XEN_GUEST_HANDLE(mmuext_op_compat_t);
 
-int compat_mmuext_op(XEN_GUEST_HANDLE(mmuext_op_compat_t) cmp_uops,
+int compat_mmuext_op(XEN_GUEST_HANDLE_PARAM(mmuext_op_compat_t) cmp_uops,
                      unsigned int count,
-                     XEN_GUEST_HANDLE(uint) pdone,
+                     XEN_GUEST_HANDLE_PARAM(uint) pdone,
                      unsigned int foreigndom)
 {
     unsigned int i, preempt_mask;
     int rc = 0;
-    XEN_GUEST_HANDLE(mmuext_op_t) nat_ops;
+    XEN_GUEST_HANDLE_PARAM(mmuext_op_t) nat_ops;
 
     preempt_mask = count & MMU_UPDATE_PREEMPTED;
     count ^= preempt_mask;
diff --git a/xen/arch/x86/x86_64/domain.c b/xen/arch/x86/x86_64/domain.c
index e746c89..144ca2d 100644
--- a/xen/arch/x86/x86_64/domain.c
+++ b/xen/arch/x86/x86_64/domain.c
@@ -23,7 +23,7 @@ CHECK_vcpu_get_physid;
 
 int
 arch_compat_vcpu_op(
-    int cmd, struct vcpu *v, XEN_GUEST_HANDLE(void) arg)
+    int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     int rc = -ENOSYS;
 
diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
index 1e001ea..35653b7 100644
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -1027,7 +1027,7 @@ void __init subarch_init_memory(void)
     }
 }
 
-long subarch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
+long subarch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     struct xen_machphys_mfn_list xmml;
     l3_pgentry_t l3e;
diff --git a/xen/arch/x86/x86_64/traps.c b/xen/arch/x86/x86_64/traps.c
index 3361d19..dfe0fac 100644
--- a/xen/arch/x86/x86_64/traps.c
+++ b/xen/arch/x86/x86_64/traps.c
@@ -519,7 +519,7 @@ static long unregister_guest_callback(struct callback_unregister *unreg)
 }
 
 
-long do_callback_op(int cmd, XEN_GUEST_HANDLE(const_void) arg)
+long do_callback_op(int cmd, XEN_GUEST_HANDLE_PARAM(const_void) arg)
 {
     long ret;
 
diff --git a/xen/common/compat/domain.c b/xen/common/compat/domain.c
index 40a0287..e4c8ceb 100644
--- a/xen/common/compat/domain.c
+++ b/xen/common/compat/domain.c
@@ -15,7 +15,7 @@
 CHECK_vcpu_set_periodic_timer;
 #undef xen_vcpu_set_periodic_timer
 
-int compat_vcpu_op(int cmd, int vcpuid, XEN_GUEST_HANDLE(void) arg)
+int compat_vcpu_op(int cmd, int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     struct domain *d = current->domain;
     struct vcpu *v;
diff --git a/xen/common/compat/grant_table.c b/xen/common/compat/grant_table.c
index edd20c6..b524955 100644
--- a/xen/common/compat/grant_table.c
+++ b/xen/common/compat/grant_table.c
@@ -52,12 +52,12 @@ CHECK_gnttab_swap_grant_ref;
 #undef xen_gnttab_swap_grant_ref
 
 int compat_grant_table_op(unsigned int cmd,
-                          XEN_GUEST_HANDLE(void) cmp_uop,
+                          XEN_GUEST_HANDLE_PARAM(void) cmp_uop,
                           unsigned int count)
 {
     int rc = 0;
     unsigned int i;
-    XEN_GUEST_HANDLE(void) cnt_uop;
+    XEN_GUEST_HANDLE_PARAM(void) cnt_uop;
 
     set_xen_guest_handle(cnt_uop, NULL);
     switch ( cmd )
@@ -206,7 +206,7 @@ int compat_grant_table_op(unsigned int cmd,
             }
             if ( rc >= 0 )
             {
-                XEN_GUEST_HANDLE(gnttab_transfer_compat_t) xfer;
+                XEN_GUEST_HANDLE_PARAM(gnttab_transfer_compat_t) xfer;
 
                 xfer = guest_handle_cast(cmp_uop, gnttab_transfer_compat_t);
                 guest_handle_add_offset(xfer, i);
@@ -251,7 +251,7 @@ int compat_grant_table_op(unsigned int cmd,
             }
             if ( rc >= 0 )
             {
-                XEN_GUEST_HANDLE(gnttab_copy_compat_t) copy;
+                XEN_GUEST_HANDLE_PARAM(gnttab_copy_compat_t) copy;
 
                 copy = guest_handle_cast(cmp_uop, gnttab_copy_compat_t);
                 guest_handle_add_offset(copy, i);
diff --git a/xen/common/compat/memory.c b/xen/common/compat/memory.c
index e7257cc..996151c 100644
--- a/xen/common/compat/memory.c
+++ b/xen/common/compat/memory.c
@@ -13,7 +13,7 @@ CHECK_TYPE(domid);
 #undef compat_domid_t
 #undef xen_domid_t
 
-int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE(void) compat)
+int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) compat)
 {
     int rc, split, op = cmd & MEMOP_CMD_MASK;
     unsigned int start_extent = cmd >> MEMOP_EXTENT_SHIFT;
@@ -22,7 +22,7 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE(void) compat)
     {
         unsigned int i, end_extent = 0;
         union {
-            XEN_GUEST_HANDLE(void) hnd;
+            XEN_GUEST_HANDLE_PARAM(void) hnd;
             struct xen_memory_reservation *rsrv;
             struct xen_memory_exchange *xchg;
             struct xen_remove_from_physmap *xrfp;
diff --git a/xen/common/domain.c b/xen/common/domain.c
index a1aa05e..6f98b54 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -806,7 +806,7 @@ void vcpu_reset(struct vcpu *v)
 }
 
 
-long do_vcpu_op(int cmd, int vcpuid, XEN_GUEST_HANDLE(void) arg)
+long do_vcpu_op(int cmd, int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     struct domain *d = current->domain;
     struct vcpu *v;
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 2b1f182..e153cb4 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -239,7 +239,7 @@ void domctl_lock_release(void)
     spin_unlock(¤t->domain->hypercall_deadlock_mutex);
 }
 
-long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
+long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
 {
     long ret = 0;
     struct xen_domctl curop, *op = &curop;
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 53777f8..a80a0d1 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -970,7 +970,7 @@ out:
 }
 
 
-long do_event_channel_op(int cmd, XEN_GUEST_HANDLE(void) arg)
+long do_event_channel_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     long rc;
 
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index c8e342b..f4ae9ee 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -833,7 +833,7 @@ __gnttab_map_grant_ref(
 
 static long
 gnttab_map_grant_ref(
-    XEN_GUEST_HANDLE(gnttab_map_grant_ref_t) uop, unsigned int count)
+    XEN_GUEST_HANDLE_PARAM(gnttab_map_grant_ref_t) uop, unsigned int count)
 {
     int i;
     struct gnttab_map_grant_ref op;
@@ -1102,7 +1102,7 @@ __gnttab_unmap_grant_ref(
 
 static long
 gnttab_unmap_grant_ref(
-    XEN_GUEST_HANDLE(gnttab_unmap_grant_ref_t) uop, unsigned int count)
+    XEN_GUEST_HANDLE_PARAM(gnttab_unmap_grant_ref_t) uop, unsigned int count)
 {
     int i, c, partial_done, done = 0;
     struct gnttab_unmap_grant_ref op;
@@ -1164,7 +1164,7 @@ __gnttab_unmap_and_replace(
 
 static long
 gnttab_unmap_and_replace(
-    XEN_GUEST_HANDLE(gnttab_unmap_and_replace_t) uop, unsigned int count)
+    XEN_GUEST_HANDLE_PARAM(gnttab_unmap_and_replace_t) uop, unsigned int count)
 {
     int i, c, partial_done, done = 0;
     struct gnttab_unmap_and_replace op;
@@ -1316,7 +1316,7 @@ active_alloc_failed:
 
 static long 
 gnttab_setup_table(
-    XEN_GUEST_HANDLE(gnttab_setup_table_t) uop, unsigned int count)
+    XEN_GUEST_HANDLE_PARAM(gnttab_setup_table_t) uop, unsigned int count)
 {
     struct gnttab_setup_table op;
     struct domain *d;
@@ -1395,7 +1395,7 @@ gnttab_setup_table(
 
 static long 
 gnttab_query_size(
-    XEN_GUEST_HANDLE(gnttab_query_size_t) uop, unsigned int count)
+    XEN_GUEST_HANDLE_PARAM(gnttab_query_size_t) uop, unsigned int count)
 {
     struct gnttab_query_size op;
     struct domain *d;
@@ -1517,7 +1517,7 @@ gnttab_prepare_for_transfer(
 
 static long
 gnttab_transfer(
-    XEN_GUEST_HANDLE(gnttab_transfer_t) uop, unsigned int count)
+    XEN_GUEST_HANDLE_PARAM(gnttab_transfer_t) uop, unsigned int count)
 {
     struct domain *d = current->domain;
     struct domain *e;
@@ -2125,7 +2125,7 @@ __gnttab_copy(
 
 static long
 gnttab_copy(
-    XEN_GUEST_HANDLE(gnttab_copy_t) uop, unsigned int count)
+    XEN_GUEST_HANDLE_PARAM(gnttab_copy_t) uop, unsigned int count)
 {
     int i;
     struct gnttab_copy op;
@@ -2144,7 +2144,7 @@ gnttab_copy(
 }
 
 static long
-gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
+gnttab_set_version(XEN_GUEST_HANDLE_PARAM(gnttab_set_version_t uop))
 {
     gnttab_set_version_t op;
     struct domain *d = current->domain;
@@ -2263,7 +2263,7 @@ out:
 }
 
 static long
-gnttab_get_status_frames(XEN_GUEST_HANDLE(gnttab_get_status_frames_t) uop,
+gnttab_get_status_frames(XEN_GUEST_HANDLE_PARAM(gnttab_get_status_frames_t) uop,
                          int count)
 {
     gnttab_get_status_frames_t op;
@@ -2327,7 +2327,7 @@ out1:
 }
 
 static long
-gnttab_get_version(XEN_GUEST_HANDLE(gnttab_get_version_t uop))
+gnttab_get_version(XEN_GUEST_HANDLE_PARAM(gnttab_get_version_t uop))
 {
     gnttab_get_version_t op;
     struct domain *d;
@@ -2412,7 +2412,7 @@ out:
 }
 
 static long
-gnttab_swap_grant_ref(XEN_GUEST_HANDLE(gnttab_swap_grant_ref_t uop),
+gnttab_swap_grant_ref(XEN_GUEST_HANDLE_PARAM(gnttab_swap_grant_ref_t uop),
                       unsigned int count)
 {
     int i;
@@ -2433,7 +2433,7 @@ gnttab_swap_grant_ref(XEN_GUEST_HANDLE(gnttab_swap_grant_ref_t uop),
 
 long
 do_grant_table_op(
-    unsigned int cmd, XEN_GUEST_HANDLE(void) uop, unsigned int count)
+    unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) uop, unsigned int count)
 {
     long rc;
     
@@ -2445,7 +2445,7 @@ do_grant_table_op(
     {
     case GNTTABOP_map_grant_ref:
     {
-        XEN_GUEST_HANDLE(gnttab_map_grant_ref_t) map =
+        XEN_GUEST_HANDLE_PARAM(gnttab_map_grant_ref_t) map =
             guest_handle_cast(uop, gnttab_map_grant_ref_t);
         if ( unlikely(!guest_handle_okay(map, count)) )
             goto out;
@@ -2459,7 +2459,7 @@ do_grant_table_op(
     }
     case GNTTABOP_unmap_grant_ref:
     {
-        XEN_GUEST_HANDLE(gnttab_unmap_grant_ref_t) unmap =
+        XEN_GUEST_HANDLE_PARAM(gnttab_unmap_grant_ref_t) unmap =
             guest_handle_cast(uop, gnttab_unmap_grant_ref_t);
         if ( unlikely(!guest_handle_okay(unmap, count)) )
             goto out;
@@ -2473,7 +2473,7 @@ do_grant_table_op(
     }
     case GNTTABOP_unmap_and_replace:
     {
-        XEN_GUEST_HANDLE(gnttab_unmap_and_replace_t) unmap =
+        XEN_GUEST_HANDLE_PARAM(gnttab_unmap_and_replace_t) unmap =
             guest_handle_cast(uop, gnttab_unmap_and_replace_t);
         if ( unlikely(!guest_handle_okay(unmap, count)) )
             goto out;
@@ -2497,7 +2497,7 @@ do_grant_table_op(
     }
     case GNTTABOP_transfer:
     {
-        XEN_GUEST_HANDLE(gnttab_transfer_t) transfer =
+        XEN_GUEST_HANDLE_PARAM(gnttab_transfer_t) transfer =
             guest_handle_cast(uop, gnttab_transfer_t);
         if ( unlikely(!guest_handle_okay(transfer, count)) )
             goto out;
@@ -2511,7 +2511,7 @@ do_grant_table_op(
     }
     case GNTTABOP_copy:
     {
-        XEN_GUEST_HANDLE(gnttab_copy_t) copy =
+        XEN_GUEST_HANDLE_PARAM(gnttab_copy_t) copy =
             guest_handle_cast(uop, gnttab_copy_t);
         if ( unlikely(!guest_handle_okay(copy, count)) )
             goto out;
@@ -2548,7 +2548,7 @@ do_grant_table_op(
     }
     case GNTTABOP_swap_grant_ref:
     {
-        XEN_GUEST_HANDLE(gnttab_swap_grant_ref_t) swap =
+        XEN_GUEST_HANDLE_PARAM(gnttab_swap_grant_ref_t) swap =
             guest_handle_cast(uop, gnttab_swap_grant_ref_t);
         if ( unlikely(!guest_handle_okay(swap, count)) )
             goto out;
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index c915bbc..55caff6 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -204,7 +204,7 @@ void __init do_initcalls(void)
  * Simple hypercalls.
  */
 
-DO(xen_version)(int cmd, XEN_GUEST_HANDLE(void) arg)
+DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     switch ( cmd )
     {
@@ -332,7 +332,7 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE(void) arg)
     return -ENOSYS;
 }
 
-DO(nmi_op)(unsigned int cmd, XEN_GUEST_HANDLE(void) arg)
+DO(nmi_op)(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     struct xennmi_callback cb;
     long rc = 0;
diff --git a/xen/common/kexec.c b/xen/common/kexec.c
index 2bc3e33..25ebd6a 100644
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -613,7 +613,7 @@ static int kexec_get_range_internal(xen_kexec_range_t *range)
     return ret;
 }
 
-static int kexec_get_range(XEN_GUEST_HANDLE(void) uarg)
+static int kexec_get_range(XEN_GUEST_HANDLE_PARAM(void) uarg)
 {
     xen_kexec_range_t range;
     int ret = -EINVAL;
@@ -629,7 +629,7 @@ static int kexec_get_range(XEN_GUEST_HANDLE(void) uarg)
     return ret;
 }
 
-static int kexec_get_range_compat(XEN_GUEST_HANDLE(void) uarg)
+static int kexec_get_range_compat(XEN_GUEST_HANDLE_PARAM(void) uarg)
 {
 #ifdef CONFIG_COMPAT
     xen_kexec_range_t range;
@@ -777,7 +777,7 @@ static int kexec_load_unload_internal(unsigned long op, xen_kexec_load_t *load)
     return ret;
 }
 
-static int kexec_load_unload(unsigned long op, XEN_GUEST_HANDLE(void) uarg)
+static int kexec_load_unload(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) uarg)
 {
     xen_kexec_load_t load;
 
@@ -788,7 +788,7 @@ static int kexec_load_unload(unsigned long op, XEN_GUEST_HANDLE(void) uarg)
 }
 
 static int kexec_load_unload_compat(unsigned long op,
-                                    XEN_GUEST_HANDLE(void) uarg)
+                                    XEN_GUEST_HANDLE_PARAM(void) uarg)
 {
 #ifdef CONFIG_COMPAT
     compat_kexec_load_t compat_load;
@@ -813,7 +813,7 @@ static int kexec_load_unload_compat(unsigned long op,
 #endif /* CONFIG_COMPAT */
 }
 
-static int kexec_exec(XEN_GUEST_HANDLE(void) uarg)
+static int kexec_exec(XEN_GUEST_HANDLE_PARAM(void) uarg)
 {
     xen_kexec_exec_t exec;
     xen_kexec_image_t *image;
@@ -845,7 +845,8 @@ static int kexec_exec(XEN_GUEST_HANDLE(void) uarg)
     return -EINVAL; /* never reached */
 }
 
-static int do_kexec_op_internal(unsigned long op, XEN_GUEST_HANDLE(void) uarg,
+static int do_kexec_op_internal(unsigned long op,
+                                XEN_GUEST_HANDLE_PARAM(void) uarg,
                                 bool_t compat)
 {
     unsigned long flags;
@@ -886,13 +887,13 @@ static int do_kexec_op_internal(unsigned long op, XEN_GUEST_HANDLE(void) uarg,
     return ret;
 }
 
-long do_kexec_op(unsigned long op, XEN_GUEST_HANDLE(void) uarg)
+long do_kexec_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) uarg)
 {
     return do_kexec_op_internal(op, uarg, 0);
 }
 
 #ifdef CONFIG_COMPAT
-int compat_kexec_op(unsigned long op, XEN_GUEST_HANDLE(void) uarg)
+int compat_kexec_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) uarg)
 {
     return do_kexec_op_internal(op, uarg, 1);
 }
diff --git a/xen/common/memory.c b/xen/common/memory.c
index 401d06c..83e2666 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -277,7 +277,7 @@ static void decrease_reservation(struct memop_args *a)
     a->nr_done = i;
 }
 
-static long memory_exchange(XEN_GUEST_HANDLE(xen_memory_exchange_t) arg)
+static long memory_exchange(XEN_GUEST_HANDLE_PARAM(xen_memory_exchange_t) arg)
 {
     struct xen_memory_exchange exch;
     PAGE_LIST_HEAD(in_chunk_list);
@@ -517,7 +517,7 @@ static long memory_exchange(XEN_GUEST_HANDLE(xen_memory_exchange_t) arg)
     return rc;
 }
 
-long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE(void) arg)
+long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     struct domain *d;
     int rc, op;
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index eee74be..00812ac 100644
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -836,7 +836,7 @@ typedef long ret_t;
 
 #endif /* !COMPAT */
 
-ret_t do_sched_op(int cmd, XEN_GUEST_HANDLE(void) arg)
+ret_t do_sched_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     ret_t ret = 0;
 
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index ea68278..47142f4 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -27,7 +27,7 @@
 #include 
 #include 
 
-long do_sysctl(XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl)
+long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
 {
     long ret = 0;
     struct xen_sysctl curop, *op = &curop;
diff --git a/xen/common/tmem.c b/xen/common/tmem.c
index ed322b6..1280537 100644
--- a/xen/common/tmem.c
+++ b/xen/common/tmem.c
@@ -1444,7 +1444,7 @@ static inline void tmem_ensure_avail_pages(void)
 /************ TMEM CORE OPERATIONS ************************************/
 
 static NOINLINE int do_tmem_put_compress(pgp_t *pgp, tmem_cli_mfn_t cmfn,
-                                         tmem_cli_va_t clibuf)
+                                         tmem_cli_va_param_t clibuf)
 {
     void *dst, *p;
     size_t size;
@@ -1488,7 +1488,7 @@ out:
 
 static NOINLINE int do_tmem_dup_put(pgp_t *pgp, tmem_cli_mfn_t cmfn,
        pagesize_t tmem_offset, pagesize_t pfn_offset, pagesize_t len,
-       tmem_cli_va_t clibuf)
+       tmem_cli_va_param_t clibuf)
 {
     pool_t *pool;
     obj_t *obj;
@@ -1579,7 +1579,7 @@ cleanup:
 static NOINLINE int do_tmem_put(pool_t *pool,
               OID *oidp, uint32_t index,
               tmem_cli_mfn_t cmfn, pagesize_t tmem_offset,
-              pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_t clibuf)
+              pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_param_t clibuf)
 {
     obj_t *obj = NULL, *objfound = NULL, *objnew = NULL;
     pgp_t *pgp = NULL, *pgpdel = NULL;
@@ -1722,7 +1722,7 @@ free:
 
 static NOINLINE int do_tmem_get(pool_t *pool, OID *oidp, uint32_t index,
               tmem_cli_mfn_t cmfn, pagesize_t tmem_offset,
-              pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_t clibuf)
+              pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_param_t clibuf)
 {
     obj_t *obj;
     pgp_t *pgp;
@@ -2066,8 +2066,8 @@ static int tmemc_flush_mem(cli_id_t cli_id, uint32_t kb)
  */
 #define BSIZE 1024
 
-static int tmemc_list_client(client_t *c, tmem_cli_va_t buf, int off, 
-                             uint32_t len, bool_t use_long)
+static int tmemc_list_client(client_t *c, tmem_cli_va_param_t buf,
+                             int off, uint32_t len, bool_t use_long)
 {
     char info[BSIZE];
     int i, n = 0, sum = 0;
@@ -2119,7 +2119,7 @@ static int tmemc_list_client(client_t *c, tmem_cli_va_t buf, int off,
     return sum;
 }
 
-static int tmemc_list_shared(tmem_cli_va_t buf, int off, uint32_t len,
+static int tmemc_list_shared(tmem_cli_va_param_t buf, int off, uint32_t len,
                               bool_t use_long)
 {
     char info[BSIZE];
@@ -2159,8 +2159,8 @@ static int tmemc_list_shared(tmem_cli_va_t buf, int off, uint32_t len,
 }
 
 #ifdef TMEM_PERF
-static int tmemc_list_global_perf(tmem_cli_va_t buf, int off, uint32_t len,
-                              bool_t use_long)
+static int tmemc_list_global_perf(tmem_cli_va_param_t buf, int off,
+                                  uint32_t len, bool_t use_long)
 {
     char info[BSIZE];
     int n = 0, sum = 0;
@@ -2194,7 +2194,7 @@ static int tmemc_list_global_perf(tmem_cli_va_t buf, int off, uint32_t len,
 #define tmemc_list_global_perf(_buf,_off,_len,_use) (0)
 #endif
 
-static int tmemc_list_global(tmem_cli_va_t buf, int off, uint32_t len,
+static int tmemc_list_global(tmem_cli_va_param_t buf, int off, uint32_t len,
                               bool_t use_long)
 {
     char info[BSIZE];
@@ -2226,7 +2226,7 @@ static int tmemc_list_global(tmem_cli_va_t buf, int off, uint32_t len,
     return sum;
 }
 
-static int tmemc_list(cli_id_t cli_id, tmem_cli_va_t buf, uint32_t len,
+static int tmemc_list(cli_id_t cli_id, tmem_cli_va_param_t buf, uint32_t len,
                                bool_t use_long)
 {
     client_t *client;
@@ -2338,7 +2338,7 @@ static NOINLINE int tmemc_shared_pool_auth(cli_id_t cli_id, uint64_t uuid_lo,
 }
 
 static NOINLINE int tmemc_save_subop(int cli_id, uint32_t pool_id,
-                        uint32_t subop, tmem_cli_va_t buf, uint32_t arg1)
+                        uint32_t subop, tmem_cli_va_param_t buf, uint32_t arg1)
 {
     client_t *client = tmh_client_from_cli_id(cli_id);
     pool_t *pool = (client == NULL || pool_id >= MAX_POOLS_PER_DOMAIN)
@@ -2427,7 +2427,7 @@ static NOINLINE int tmemc_save_subop(int cli_id, uint32_t pool_id,
 }
 
 static NOINLINE int tmemc_save_get_next_page(int cli_id, uint32_t pool_id,
-                        tmem_cli_va_t buf, uint32_t bufsize)
+                        tmem_cli_va_param_t buf, uint32_t bufsize)
 {
     client_t *client = tmh_client_from_cli_id(cli_id);
     pool_t *pool = (client == NULL || pool_id >= MAX_POOLS_PER_DOMAIN)
@@ -2479,7 +2479,7 @@ out:
     return ret;
 }
 
-static NOINLINE int tmemc_save_get_next_inv(int cli_id, tmem_cli_va_t buf,
+static NOINLINE int tmemc_save_get_next_inv(int cli_id, tmem_cli_va_param_t buf,
                         uint32_t bufsize)
 {
     client_t *client = tmh_client_from_cli_id(cli_id);
@@ -2522,7 +2522,7 @@ out:
 }
 
 static int tmemc_restore_put_page(int cli_id, uint32_t pool_id, OID *oidp,
-                      uint32_t index, tmem_cli_va_t buf, uint32_t bufsize)
+                      uint32_t index, tmem_cli_va_param_t buf, uint32_t bufsize)
 {
     client_t *client = tmh_client_from_cli_id(cli_id);
     pool_t *pool = (client == NULL || pool_id >= MAX_POOLS_PER_DOMAIN)
@@ -2566,7 +2566,8 @@ static NOINLINE int do_tmem_control(struct tmem_op *op)
         ret = tmemc_flush_mem(op->u.ctrl.cli_id,op->u.ctrl.arg1);
         break;
     case TMEMC_LIST:
-        ret = tmemc_list(op->u.ctrl.cli_id,op->u.ctrl.buf,
+        ret = tmemc_list(op->u.ctrl.cli_id,
+                         guest_handle_cast(op->u.ctrl.buf, char),
                          op->u.ctrl.arg1,op->u.ctrl.arg2);
         break;
     case TMEMC_SET_WEIGHT:
@@ -2589,20 +2590,24 @@ static NOINLINE int do_tmem_control(struct tmem_op *op)
     case TMEMC_SAVE_GET_POOL_UUID:
     case TMEMC_SAVE_END:
         ret = tmemc_save_subop(op->u.ctrl.cli_id,pool_id,subop,
-                        op->u.ctrl.buf,op->u.ctrl.arg1);
+                               guest_handle_cast(op->u.ctrl.buf, char),
+                               op->u.ctrl.arg1);
         break;
     case TMEMC_SAVE_GET_NEXT_PAGE:
         ret = tmemc_save_get_next_page(op->u.ctrl.cli_id, pool_id,
-                                       op->u.ctrl.buf, op->u.ctrl.arg1);
+                                       guest_handle_cast(op->u.ctrl.buf, char),
+                                       op->u.ctrl.arg1);
         break;
     case TMEMC_SAVE_GET_NEXT_INV:
-        ret = tmemc_save_get_next_inv(op->u.ctrl.cli_id, op->u.ctrl.buf,
+        ret = tmemc_save_get_next_inv(op->u.ctrl.cli_id,
+                                      guest_handle_cast(op->u.ctrl.buf, char),
                                       op->u.ctrl.arg1);
         break;
     case TMEMC_RESTORE_PUT_PAGE:
         ret = tmemc_restore_put_page(op->u.ctrl.cli_id,pool_id,
                                      oidp, op->u.ctrl.arg2,
-                                     op->u.ctrl.buf, op->u.ctrl.arg1);
+                                     guest_handle_cast(op->u.ctrl.buf, char),
+                                     op->u.ctrl.arg1);
         break;
     case TMEMC_RESTORE_FLUSH_PAGE:
         ret = tmemc_restore_flush_page(op->u.ctrl.cli_id,pool_id,
diff --git a/xen/common/tmem_xen.c b/xen/common/tmem_xen.c
index 9dc2a1d..25fbd6c 100644
--- a/xen/common/tmem_xen.c
+++ b/xen/common/tmem_xen.c
@@ -146,7 +146,7 @@ static inline void cli_put_page(void *cli_va, pfp_t *cli_pfp,
 
 EXPORT int tmh_copy_from_client(pfp_t *pfp,
     tmem_cli_mfn_t cmfn, pagesize_t tmem_offset,
-    pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_t clibuf)
+    pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_param_t clibuf)
 {
     unsigned long tmem_mfn, cli_mfn = 0;
     char *tmem_va, *cli_va = NULL;
@@ -194,7 +194,7 @@ EXPORT int tmh_copy_from_client(pfp_t *pfp,
 }
 
 EXPORT int tmh_compress_from_client(tmem_cli_mfn_t cmfn,
-    void **out_va, size_t *out_len, tmem_cli_va_t clibuf)
+    void **out_va, size_t *out_len, tmem_cli_va_param_t clibuf)
 {
     int ret = 0;
     unsigned char *dmem = this_cpu(dstmem);
@@ -227,7 +227,7 @@ EXPORT int tmh_compress_from_client(tmem_cli_mfn_t cmfn,
 
 EXPORT int tmh_copy_to_client(tmem_cli_mfn_t cmfn, pfp_t *pfp,
     pagesize_t tmem_offset, pagesize_t pfn_offset, pagesize_t len,
-    tmem_cli_va_t clibuf)
+    tmem_cli_va_param_t clibuf)
 {
     unsigned long tmem_mfn, cli_mfn = 0;
     char *tmem_va, *cli_va = NULL;
@@ -265,7 +265,7 @@ EXPORT int tmh_copy_to_client(tmem_cli_mfn_t cmfn, pfp_t *pfp,
 }
 
 EXPORT int tmh_decompress_to_client(tmem_cli_mfn_t cmfn, void *tmem_va,
-                                    size_t size, tmem_cli_va_t clibuf)
+                                    size_t size, tmem_cli_va_param_t clibuf)
 {
     unsigned long cli_mfn = 0;
     pfp_t *cli_pfp = NULL;
diff --git a/xen/common/xenoprof.c b/xen/common/xenoprof.c
index 44a1fae..ae0435b 100644
--- a/xen/common/xenoprof.c
+++ b/xen/common/xenoprof.c
@@ -404,7 +404,7 @@ static int add_active_list(domid_t domid)
     return 0;
 }
 
-static int add_passive_list(XEN_GUEST_HANDLE(void) arg)
+static int add_passive_list(XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     struct xenoprof_passive passive;
     struct domain *d;
@@ -585,7 +585,7 @@ void xenoprof_log_event(struct vcpu *vcpu, const struct cpu_user_regs *regs,
 
 
 
-static int xenoprof_op_init(XEN_GUEST_HANDLE(void) arg)
+static int xenoprof_op_init(XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     struct domain *d = current->domain;
     struct xenoprof_init xenoprof_init;
@@ -611,7 +611,7 @@ static int xenoprof_op_init(XEN_GUEST_HANDLE(void) arg)
 
 #endif /* !COMPAT */
 
-static int xenoprof_op_get_buffer(XEN_GUEST_HANDLE(void) arg)
+static int xenoprof_op_get_buffer(XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     struct xenoprof_get_buffer xenoprof_get_buffer;
     struct domain *d = current->domain;
@@ -662,7 +662,7 @@ static int xenoprof_op_get_buffer(XEN_GUEST_HANDLE(void) arg)
                       || (op == XENOPROF_disable_virq)  \
                       || (op == XENOPROF_get_buffer))
  
-ret_t do_xenoprof_op(int op, XEN_GUEST_HANDLE(void) arg)
+ret_t do_xenoprof_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
     int ret = 0;
     
diff --git a/xen/drivers/acpi/pmstat.c b/xen/drivers/acpi/pmstat.c
index 6f266ef..bf30cc7 100644
--- a/xen/drivers/acpi/pmstat.c
+++ b/xen/drivers/acpi/pmstat.c
@@ -496,7 +496,7 @@ int do_pm_op(struct xen_sysctl_pm_op *op)
     return ret;
 }
 
-int acpi_set_pdc_bits(u32 acpi_id, XEN_GUEST_HANDLE(uint32) pdc)
+int acpi_set_pdc_bits(u32 acpi_id, XEN_GUEST_HANDLE_PARAM(uint32) pdc)
 {
     u32 bits[3];
     int ret;
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 9e1adb5..ff360fe 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -182,7 +182,7 @@ static void putchar_console_ring(int c)
 
 long read_console_ring(struct xen_sysctl_readconsole *op)
 {
-    XEN_GUEST_HANDLE(char) str;
+    XEN_GUEST_HANDLE_PARAM(char) str;
     uint32_t idx, len, max, sofar, c;
 
     str   = guest_handle_cast(op->buffer, char),
@@ -363,7 +363,7 @@ static void notify_dom0_con_ring(unsigned long unused)
 static DECLARE_SOFTIRQ_TASKLET(notify_dom0_con_ring_tasklet,
                                notify_dom0_con_ring, 0);
 
-static long guest_console_write(XEN_GUEST_HANDLE(char) buffer, int count)
+static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, int count)
 {
     char kbuf[128], *kptr;
     int kcount;
@@ -401,7 +401,7 @@ static long guest_console_write(XEN_GUEST_HANDLE(char) buffer, int count)
     return 0;
 }
 
-long do_console_io(int cmd, int count, XEN_GUEST_HANDLE(char) buffer)
+long do_console_io(int cmd, int count, XEN_GUEST_HANDLE_PARAM(char) buffer)
 {
     long rc;
     unsigned int idx, len;
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index b4cf16c..4b5f8b7 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -527,7 +527,7 @@ void iommu_crash_shutdown(void)
 
 int iommu_do_domctl(
     struct xen_domctl *domctl,
-    XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
+    XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
 {
     struct domain *d;
     u16 seg;
diff --git a/xen/include/asm-arm/hypercall.h b/xen/include/asm-arm/hypercall.h
index 454f02e..090e620 100644
--- a/xen/include/asm-arm/hypercall.h
+++ b/xen/include/asm-arm/hypercall.h
@@ -2,7 +2,7 @@
 #define __ASM_ARM_HYPERCALL_H__
 
 #include  /* for arch_do_domctl */
-int do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg);
+int do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg);
 
 #endif /* __ASM_ARM_HYPERCALL_H__ */
 /*
diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
index e4b2d97..c0f5b1f 100644
--- a/xen/include/asm-arm/mm.h
+++ b/xen/include/asm-arm/mm.h
@@ -267,7 +267,7 @@ static inline int relinquish_shared_pages(struct domain *d)
 
 
 /* Arch-specific portion of memory_op hypercall. */
-long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg);
+long arch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg);
 
 int steal_page(
     struct domain *d, struct page_info *page, unsigned int memflags);
diff --git a/xen/include/asm-x86/hap.h b/xen/include/asm-x86/hap.h
index a2532a4..916a35b 100644
--- a/xen/include/asm-x86/hap.h
+++ b/xen/include/asm-x86/hap.h
@@ -51,7 +51,7 @@ hap_unmap_domain_page(void *p)
 /************************************************/
 void  hap_domain_init(struct domain *d);
 int   hap_domctl(struct domain *d, xen_domctl_shadow_op_t *sc,
-                 XEN_GUEST_HANDLE(void) u_domctl);
+                 XEN_GUEST_HANDLE_PARAM(void) u_domctl);
 int   hap_enable(struct domain *d, u32 mode);
 void  hap_final_teardown(struct domain *d);
 void  hap_teardown(struct domain *d);
diff --git a/xen/include/asm-x86/hypercall.h b/xen/include/asm-x86/hypercall.h
index a9af426..bd14220 100644
--- a/xen/include/asm-x86/hypercall.h
+++ b/xen/include/asm-x86/hypercall.h
@@ -18,22 +18,22 @@
 
 extern long
 do_event_channel_op_compat(
-    XEN_GUEST_HANDLE(evtchn_op_t) uop);
+    XEN_GUEST_HANDLE_PARAM(evtchn_op_t) uop);
 
 extern long
 do_set_trap_table(
-    XEN_GUEST_HANDLE(const_trap_info_t) traps);
+    XEN_GUEST_HANDLE_PARAM(const_trap_info_t) traps);
 
 extern long
 do_mmu_update(
-    XEN_GUEST_HANDLE(mmu_update_t) ureqs,
+    XEN_GUEST_HANDLE_PARAM(mmu_update_t) ureqs,
     unsigned int count,
-    XEN_GUEST_HANDLE(uint) pdone,
+    XEN_GUEST_HANDLE_PARAM(uint) pdone,
     unsigned int foreigndom);
 
 extern long
 do_set_gdt(
-    XEN_GUEST_HANDLE(ulong) frame_list,
+    XEN_GUEST_HANDLE_PARAM(ulong) frame_list,
     unsigned int entries);
 
 extern long
@@ -60,7 +60,7 @@ do_update_descriptor(
     u64 desc);
 
 extern long
-do_mca(XEN_GUEST_HANDLE(xen_mc_t) u_xen_mc);
+do_mca(XEN_GUEST_HANDLE_PARAM(xen_mc_t) u_xen_mc);
 
 extern long
 do_update_va_mapping(
@@ -70,7 +70,7 @@ do_update_va_mapping(
 
 extern long
 do_physdev_op(
-    int cmd, XEN_GUEST_HANDLE(void) arg);
+    int cmd, XEN_GUEST_HANDLE_PARAM(void) arg);
 
 extern long
 do_update_va_mapping_otherdomain(
@@ -81,9 +81,9 @@ do_update_va_mapping_otherdomain(
 
 extern long
 do_mmuext_op(
-    XEN_GUEST_HANDLE(mmuext_op_t) uops,
+    XEN_GUEST_HANDLE_PARAM(mmuext_op_t) uops,
     unsigned int count,
-    XEN_GUEST_HANDLE(uint) pdone,
+    XEN_GUEST_HANDLE_PARAM(uint) pdone,
     unsigned int foreigndom);
 
 extern unsigned long
@@ -104,10 +104,10 @@ do_set_segment_base(
 extern int
 compat_physdev_op(
     int cmd,
-    XEN_GUEST_HANDLE(void) arg);
+    XEN_GUEST_HANDLE_PARAM(void) arg);
 
 extern int
 arch_compat_vcpu_op(
-    int cmd, struct vcpu *v, XEN_GUEST_HANDLE(void) arg);
+    int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg);
 
 #endif /* __ASM_X86_HYPERCALL_H__ */
diff --git a/xen/include/asm-x86/mem_event.h b/xen/include/asm-x86/mem_event.h
index 23d71c1..e17f36b 100644
--- a/xen/include/asm-x86/mem_event.h
+++ b/xen/include/asm-x86/mem_event.h
@@ -65,7 +65,7 @@ int mem_event_get_response(struct domain *d, struct mem_event_domain *med,
 struct domain *get_mem_event_op_target(uint32_t domain, int *rc);
 int do_mem_event_op(int op, uint32_t domain, void *arg);
 int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
-                     XEN_GUEST_HANDLE(void) u_domctl);
+                     XEN_GUEST_HANDLE_PARAM(void) u_domctl);
 
 #endif /* __MEM_EVENT_H__ */
 
diff --git a/xen/include/asm-x86/mm.h b/xen/include/asm-x86/mm.h
index 6e1e57c..494dad8 100644
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -555,10 +555,10 @@ void *do_page_walk(struct vcpu *v, unsigned long addr);
 int __sync_local_execstate(void);
 
 /* Arch-specific portion of memory_op hypercall. */
-long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg);
-long subarch_memory_op(int op, XEN_GUEST_HANDLE(void) arg);
-int compat_arch_memory_op(int op, XEN_GUEST_HANDLE(void));
-int compat_subarch_memory_op(int op, XEN_GUEST_HANDLE(void));
+long arch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg);
+long subarch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg);
+int compat_arch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void));
+int compat_subarch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void));
 
 int steal_page(
     struct domain *d, struct page_info *page, unsigned int memflags);
diff --git a/xen/include/asm-x86/paging.h b/xen/include/asm-x86/paging.h
index d9b6950..9a40f2c 100644
--- a/xen/include/asm-x86/paging.h
+++ b/xen/include/asm-x86/paging.h
@@ -207,7 +207,7 @@ int paging_domain_init(struct domain *d, unsigned int domcr_flags);
  * and disable ephemeral shadow modes (test mode and log-dirty mode) and
  * manipulate the log-dirty bitmap. */
 int paging_domctl(struct domain *d, xen_domctl_shadow_op_t *sc,
-                  XEN_GUEST_HANDLE(void) u_domctl);
+                  XEN_GUEST_HANDLE_PARAM(void) u_domctl);
 
 /* Call when destroying a domain */
 void paging_teardown(struct domain *d);
diff --git a/xen/include/asm-x86/processor.h b/xen/include/asm-x86/processor.h
index c969b11..637cea3 100644
--- a/xen/include/asm-x86/processor.h
+++ b/xen/include/asm-x86/processor.h
@@ -549,7 +549,7 @@ int rdmsr_hypervisor_regs(uint32_t idx, uint64_t *val);
 int wrmsr_hypervisor_regs(uint32_t idx, uint64_t val);
 
 void microcode_set_module(unsigned int);
-int microcode_update(XEN_GUEST_HANDLE(const_void), unsigned long len);
+int microcode_update(XEN_GUEST_HANDLE_PARAM(const_void), unsigned long len);
 int microcode_resume_cpu(int cpu);
 
 #endif /* !__ASSEMBLY__ */
diff --git a/xen/include/asm-x86/shadow.h b/xen/include/asm-x86/shadow.h
index 88a8cd2..2eb6efc 100644
--- a/xen/include/asm-x86/shadow.h
+++ b/xen/include/asm-x86/shadow.h
@@ -73,7 +73,7 @@ int shadow_track_dirty_vram(struct domain *d,
  * manipulate the log-dirty bitmap. */
 int shadow_domctl(struct domain *d, 
                   xen_domctl_shadow_op_t *sc,
-                  XEN_GUEST_HANDLE(void) u_domctl);
+                  XEN_GUEST_HANDLE_PARAM(void) u_domctl);
 
 /* Call when destroying a domain */
 void shadow_teardown(struct domain *d);
diff --git a/xen/include/asm-x86/xenoprof.h b/xen/include/asm-x86/xenoprof.h
index a71f020..52a6881 100644
--- a/xen/include/asm-x86/xenoprof.h
+++ b/xen/include/asm-x86/xenoprof.h
@@ -40,9 +40,9 @@ int xenoprof_arch_init(int *num_events, char *cpu_type);
 #define xenoprof_arch_disable_virq()            nmi_disable_virq()
 #define xenoprof_arch_release_counters()        nmi_release_counters()
 
-int xenoprof_arch_counter(XEN_GUEST_HANDLE(void) arg);
-int compat_oprof_arch_counter(XEN_GUEST_HANDLE(void) arg);
-int xenoprof_arch_ibs_counter(XEN_GUEST_HANDLE(void) arg);
+int xenoprof_arch_counter(XEN_GUEST_HANDLE_PARAM(void) arg);
+int compat_oprof_arch_counter(XEN_GUEST_HANDLE_PARAM(void) arg);
+int xenoprof_arch_ibs_counter(XEN_GUEST_HANDLE_PARAM(void) arg);
 
 struct vcpu;
 struct cpu_user_regs;
diff --git a/xen/include/xen/acpi.h b/xen/include/xen/acpi.h
index d7e2f94..8f3cdca 100644
--- a/xen/include/xen/acpi.h
+++ b/xen/include/xen/acpi.h
@@ -145,8 +145,8 @@ static inline unsigned int acpi_get_cstate_limit(void) { return 0; }
 static inline void acpi_set_cstate_limit(unsigned int new_limit) { return; }
 #endif
 
-#ifdef XEN_GUEST_HANDLE
-int acpi_set_pdc_bits(u32 acpi_id, XEN_GUEST_HANDLE(uint32));
+#ifdef XEN_GUEST_HANDLE_PARAM
+int acpi_set_pdc_bits(u32 acpi_id, XEN_GUEST_HANDLE_PARAM(uint32));
 #endif
 int arch_acpi_set_pdc_bits(u32 acpi_id, u32 *, u32 mask);
 
diff --git a/xen/include/xen/compat.h b/xen/include/xen/compat.h
index 857cbc7..ca60699 100644
--- a/xen/include/xen/compat.h
+++ b/xen/include/xen/compat.h
@@ -22,6 +22,9 @@
     __DEFINE_COMPAT_HANDLE(const_ ## name, const name)
 #define COMPAT_HANDLE(name)          __compat_handle_ ## name
 
+/* NB: it is assumed that if an arch uses the compat layer it does not
+ * distinguish handles from parameter handles. */
+#define COMPAT_HANDLE_PARAM(name)    __compat_handle_ ## name
 /* Is the compat handle a NULL reference? */
 #define compat_handle_is_null(hnd)        ((hnd).c == 0)
 
diff --git a/xen/include/xen/hypercall.h b/xen/include/xen/hypercall.h
index 1b71071..e315523 100644
--- a/xen/include/xen/hypercall.h
+++ b/xen/include/xen/hypercall.h
@@ -29,29 +29,29 @@ do_sched_op_compat(
 extern long
 do_sched_op(
     int cmd,
-    XEN_GUEST_HANDLE(void) arg);
+    XEN_GUEST_HANDLE_PARAM(void) arg);
 
 extern long
 do_domctl(
-    XEN_GUEST_HANDLE(xen_domctl_t) u_domctl);
+    XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl);
 
 extern long
 arch_do_domctl(
     struct xen_domctl *domctl,
-    XEN_GUEST_HANDLE(xen_domctl_t) u_domctl);
+    XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl);
 
 extern long
 do_sysctl(
-    XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl);
+    XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl);
 
 extern long
 arch_do_sysctl(
     struct xen_sysctl *sysctl,
-    XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl);
+    XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl);
 
 extern long
 do_platform_op(
-    XEN_GUEST_HANDLE(xen_platform_op_t) u_xenpf_op);
+    XEN_GUEST_HANDLE_PARAM(xen_platform_op_t) u_xenpf_op);
 
 /*
  * To allow safe resume of do_memory_op() after preemption, we need to know
@@ -64,11 +64,11 @@ do_platform_op(
 extern long
 do_memory_op(
     unsigned long cmd,
-    XEN_GUEST_HANDLE(void) arg);
+    XEN_GUEST_HANDLE_PARAM(void) arg);
 
 extern long
 do_multicall(
-    XEN_GUEST_HANDLE(multicall_entry_t) call_list,
+    XEN_GUEST_HANDLE_PARAM(multicall_entry_t) call_list,
     unsigned int nr_calls);
 
 extern long
@@ -77,23 +77,23 @@ do_set_timer_op(
 
 extern long
 do_event_channel_op(
-    int cmd, XEN_GUEST_HANDLE(void) arg);
+    int cmd, XEN_GUEST_HANDLE_PARAM(void) arg);
 
 extern long
 do_xen_version(
     int cmd,
-    XEN_GUEST_HANDLE(void) arg);
+    XEN_GUEST_HANDLE_PARAM(void) arg);
 
 extern long
 do_console_io(
     int cmd,
     int count,
-    XEN_GUEST_HANDLE(char) buffer);
+    XEN_GUEST_HANDLE_PARAM(char) buffer);
 
 extern long
 do_grant_table_op(
     unsigned int cmd,
-    XEN_GUEST_HANDLE(void) uop,
+    XEN_GUEST_HANDLE_PARAM(void) uop,
     unsigned int count);
 
 extern long
@@ -105,72 +105,72 @@ extern long
 do_vcpu_op(
     int cmd,
     int vcpuid,
-    XEN_GUEST_HANDLE(void) arg);
+    XEN_GUEST_HANDLE_PARAM(void) arg);
 
 struct vcpu;
 extern long
 arch_do_vcpu_op(int cmd,
     struct vcpu *v,
-    XEN_GUEST_HANDLE(void) arg);
+    XEN_GUEST_HANDLE_PARAM(void) arg);
 
 extern long
 do_nmi_op(
     unsigned int cmd,
-    XEN_GUEST_HANDLE(void) arg);
+    XEN_GUEST_HANDLE_PARAM(void) arg);
 
 extern long
 do_hvm_op(
     unsigned long op,
-    XEN_GUEST_HANDLE(void) arg);
+    XEN_GUEST_HANDLE_PARAM(void) arg);
 
 extern long
 do_kexec_op(
     unsigned long op,
     int arg1,
-    XEN_GUEST_HANDLE(void) arg);
+    XEN_GUEST_HANDLE_PARAM(void) arg);
 
 extern long
 do_xsm_op(
-    XEN_GUEST_HANDLE(xsm_op_t) u_xsm_op);
+    XEN_GUEST_HANDLE_PARAM(xsm_op_t) u_xsm_op);
 
 extern long
 do_tmem_op(
-    XEN_GUEST_HANDLE(tmem_op_t) uops);
+    XEN_GUEST_HANDLE_PARAM(tmem_op_t) uops);
 
 extern long
-do_xenoprof_op(int op, XEN_GUEST_HANDLE(void) arg);
+do_xenoprof_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg);
 
 #ifdef CONFIG_COMPAT
 
 extern int
 compat_memory_op(
     unsigned int cmd,
-    XEN_GUEST_HANDLE(void) arg);
+    XEN_GUEST_HANDLE_PARAM(void) arg);
 
 extern int
 compat_grant_table_op(
     unsigned int cmd,
-    XEN_GUEST_HANDLE(void) uop,
+    XEN_GUEST_HANDLE_PARAM(void) uop,
     unsigned int count);
 
 extern int
 compat_vcpu_op(
     int cmd,
     int vcpuid,
-    XEN_GUEST_HANDLE(void) arg);
+    XEN_GUEST_HANDLE_PARAM(void) arg);
 
 extern int
-compat_xenoprof_op(int op, XEN_GUEST_HANDLE(void) arg);
+compat_xenoprof_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg);
 
 extern int
 compat_xen_version(
     int cmd,
-    XEN_GUEST_HANDLE(void) arg);
+    XEN_GUEST_HANDLE_PARAM(void) arg);
 
 extern int
 compat_sched_op(
     int cmd,
-    XEN_GUEST_HANDLE(void) arg);
+    XEN_GUEST_HANDLE_PARAM(void) arg);
 
 extern int
 compat_set_timer_op(
diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index 605c7b3..773a6d7 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -156,7 +156,7 @@ void iommu_crash_shutdown(void);
 void iommu_set_dom0_mapping(struct domain *d);
 void iommu_share_p2m_table(struct domain *d);
 
-int iommu_do_domctl(struct xen_domctl *, XEN_GUEST_HANDLE(xen_domctl_t));
+int iommu_do_domctl(struct xen_domctl *, XEN_GUEST_HANDLE_PARAM(xen_domctl_t));
 
 void iommu_iotlb_flush(struct domain *d, unsigned long gfn, unsigned int page_count);
 void iommu_iotlb_flush_all(struct domain *d);
diff --git a/xen/include/xen/tmem_xen.h b/xen/include/xen/tmem_xen.h
index 9492810..36a8d9f 100644
--- a/xen/include/xen/tmem_xen.h
+++ b/xen/include/xen/tmem_xen.h
@@ -430,7 +430,8 @@ static inline void tmh_tze_copy_from_pfp(void *tva, pfp_t *pfp, pagesize_t len)
 typedef XEN_GUEST_HANDLE(void) cli_mfn_t;
 typedef XEN_GUEST_HANDLE(char) cli_va_t;
 */
-typedef XEN_GUEST_HANDLE(tmem_op_t) tmem_cli_op_t;
+typedef XEN_GUEST_HANDLE_PARAM(tmem_op_t) tmem_cli_op_t;
+typedef XEN_GUEST_HANDLE_PARAM(char) tmem_cli_va_param_t;
 
 static inline int tmh_get_tmemop_from_client(tmem_op_t *op, tmem_cli_op_t uops)
 {
@@ -466,8 +467,9 @@ static inline int tmh_get_tmemop_from_client(tmem_op_t *op, tmem_cli_op_t uops)
 
 #define tmh_cli_buf_null guest_handle_from_ptr(NULL, char)
 
-static inline void tmh_copy_to_client_buf_offset(tmem_cli_va_t clibuf, int off,
-                                           char *tmembuf, int len)
+static inline void tmh_copy_to_client_buf_offset(tmem_cli_va_param_t clibuf,
+						 int off,
+						 char *tmembuf, int len)
 {
     copy_to_guest_offset(clibuf,off,tmembuf,len);
 }
@@ -482,15 +484,17 @@ static inline void tmh_copy_to_client_buf_offset(tmem_cli_va_t clibuf, int off,
 #define tmh_cli_id_str "domid"
 #define tmh_client_str "domain"
 
-int tmh_decompress_to_client(tmem_cli_mfn_t, void *, size_t, tmem_cli_va_t);
+int tmh_decompress_to_client(tmem_cli_mfn_t, void *, size_t,
+			     tmem_cli_va_param_t);
 
-int tmh_compress_from_client(tmem_cli_mfn_t, void **, size_t *, tmem_cli_va_t);
+int tmh_compress_from_client(tmem_cli_mfn_t, void **, size_t *,
+			     tmem_cli_va_param_t);
 
 int tmh_copy_from_client(pfp_t *, tmem_cli_mfn_t, pagesize_t tmem_offset,
-    pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_t);
+    pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_param_t);
 
 int tmh_copy_to_client(tmem_cli_mfn_t, pfp_t *, pagesize_t tmem_offset,
-    pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_t);
+    pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_param_t);
 
 extern int tmh_copy_tze_to_client(tmem_cli_mfn_t cmfn, void *tmem_va, pagesize_t len);
 
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 593cdbd..a949c1e 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -139,7 +139,7 @@ struct xsm_operations {
     int (*cpupool_op)(void);
     int (*sched_op)(void);
 
-    long (*__do_xsm_op) (XEN_GUEST_HANDLE(xsm_op_t) op);
+    long (*__do_xsm_op) (XEN_GUEST_HANDLE_PARAM(xsm_op_t) op);
 
 #ifdef CONFIG_X86
     int (*shadow_control) (struct domain *d, uint32_t op);
@@ -585,7 +585,7 @@ static inline int xsm_sched_op(void)
     return xsm_call(sched_op());
 }
 
-static inline long __do_xsm_op (XEN_GUEST_HANDLE(xsm_op_t) op)
+static inline long __do_xsm_op (XEN_GUEST_HANDLE_PARAM(xsm_op_t) op)
 {
 #ifdef XSM_ENABLE
     return xsm_ops->__do_xsm_op(op);
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 4836fc0..b726eaf 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -380,7 +380,7 @@ static int dummy_sched_op (void)
     return 0;
 }
 
-static long dummy___do_xsm_op(XEN_GUEST_HANDLE(xsm_op_t) op)
+static long dummy___do_xsm_op(XEN_GUEST_HANDLE_PARAM(xsm_op_t) op)
 {
     return -ENOSYS;
 }
diff --git a/xen/xsm/flask/flask_op.c b/xen/xsm/flask/flask_op.c
index 9c8dfe7..a5d7748 100644
--- a/xen/xsm/flask/flask_op.c
+++ b/xen/xsm/flask/flask_op.c
@@ -71,7 +71,7 @@ static int domain_has_security(struct domain *d, u32 perms)
                         perms, NULL);
 }
 
-static int flask_copyin_string(XEN_GUEST_HANDLE(char) u_buf, char **buf, uint32_t size)
+static int flask_copyin_string(XEN_GUEST_HANDLE_PARAM(char) u_buf, char **buf, uint32_t size)
 {
     char *tmp = xmalloc_bytes(size + 1);
     if ( !tmp )
@@ -618,7 +618,7 @@ static int flask_relabel_domain(struct xen_flask_relabel *arg)
     return rc;
 }
 
-long do_flask_op(XEN_GUEST_HANDLE(xsm_op_t) u_flask_op)
+long do_flask_op(XEN_GUEST_HANDLE_PARAM(xsm_op_t) u_flask_op)
 {
     xen_flask_op_t op;
     int rv;
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 88fef9c..0ca10d0 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1462,7 +1462,7 @@ static int flask_vcpuextstate (struct domain *d, uint32_t cmd)
 }
 #endif
 
-long do_flask_op(XEN_GUEST_HANDLE(xsm_op_t) u_flask_op);
+long do_flask_op(XEN_GUEST_HANDLE_PARAM(xsm_op_t) u_flask_op);
 
 static struct xsm_operations flask_ops = {
     .security_domaininfo = flask_security_domaininfo,
diff --git a/xen/xsm/xsm_core.c b/xen/xsm/xsm_core.c
index 96c8669..46287cb 100644
--- a/xen/xsm/xsm_core.c
+++ b/xen/xsm/xsm_core.c
@@ -111,7 +111,7 @@ int unregister_xsm(struct xsm_operations *ops)
 
 #endif
 
-long do_xsm_op (XEN_GUEST_HANDLE(xsm_op_t) op)
+long do_xsm_op (XEN_GUEST_HANDLE_PARAM(xsm_op_t) op)
 {
     return __do_xsm_op(op);
 }
-- 
1.7.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 15:21:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 15:21:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNmTL-0004VY-4U; Mon, 15 Oct 2012 15:20:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNmTJ-0004V0-HB
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 15:20:49 +0000
Received: from [85.158.138.51:15512] by server-2.bemta-3.messagelabs.com id
	26/B8-00604-0D92C705; Mon, 15 Oct 2012 15:20:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1350314445!26846382!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODI0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2877 invoked from network); 15 Oct 2012 15:20:48 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 15:20:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,588,1344211200"; d="scan'208";a="211302568"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 15:20:45 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 11:20:44 -0400
Received: from [10.80.246.74] (helo=army.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TNmTE-0007YE-Jy;
	Mon, 15 Oct 2012 16:20:44 +0100
From: Ian Campbell 
To: 
Date: Mon, 15 Oct 2012 15:20:35 +0000
Message-ID: <1350314444-17148-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
References: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Keir Fraser , Ian Campbell ,
	Stefano Stabellini ,
	Tim Deegan ,
	Stefano Stabellini ,
	Jan Beulich 
Subject: [Xen-devel] [PATCH 02/10] xen/arm: grant table
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Stefano Stabellini 

Implement XENMAPSPACE_grant_table and grant_table_op.

Signed-off-by: Stefano Stabellini 
Acked-by: Tim Deegan 
[ ijc -- fixed reject in traps.c, grant table op is a 3 argument
         hypercall, rebased over "xen: arm: implement
         XENMEM_add_to_physmap_range"
]
Signed-off-by: Ian Campbell 
---
 xen/arch/arm/mm.c    |   26 ++++++++++++++++++++++++++
 xen/arch/arm/traps.c |    1 +
 2 files changed, 27 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 591ad3a..edd5ca7 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -473,6 +474,31 @@ static int xenmem_add_to_physmap_one(
 
     switch ( space )
     {
+    case XENMAPSPACE_grant_table:
+        spin_lock(&d->grant_table->lock);
+
+        if ( d->grant_table->gt_version == 0 )
+            d->grant_table->gt_version = 1;
+
+        if ( d->grant_table->gt_version == 2 &&
+                (idx & XENMAPIDX_grant_table_status) )
+        {
+            idx &= ~XENMAPIDX_grant_table_status;
+            if ( idx < nr_status_frames(d->grant_table) )
+                mfn = virt_to_mfn(d->grant_table->status[idx]);
+        }
+        else
+        {
+            if ( (idx >= nr_grant_frames(d->grant_table)) &&
+                    (idx < max_nr_grant_frames) )
+                gnttab_grow_table(d, idx + 1);
+
+            if ( idx < nr_grant_frames(d->grant_table) )
+                mfn = virt_to_mfn(d->grant_table->shared_raw[idx]);
+        }
+
+        spin_unlock(&d->grant_table->lock);
+        break;
     case XENMAPSPACE_shared_info:
         if ( idx == 0 )
             mfn = virt_to_mfn(d->shared_info);
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 98cc750..19e2081 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -438,6 +438,7 @@ static arm_hypercall_t arm_hypercall_table[] = {
     HYPERCALL(physdev_op, 2),
     HYPERCALL(sysctl, 2),
     HYPERCALL(hvm_op, 2),
+    HYPERCALL(grant_table_op, 3),
 };
 
 static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code)
-- 
1.7.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 15:21:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 15:21:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNmTL-0004VY-4U; Mon, 15 Oct 2012 15:20:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNmTJ-0004V0-HB
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 15:20:49 +0000
Received: from [85.158.138.51:15512] by server-2.bemta-3.messagelabs.com id
	26/B8-00604-0D92C705; Mon, 15 Oct 2012 15:20:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1350314445!26846382!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODI0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2877 invoked from network); 15 Oct 2012 15:20:48 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 15:20:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,588,1344211200"; d="scan'208";a="211302568"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 15:20:45 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 11:20:44 -0400
Received: from [10.80.246.74] (helo=army.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TNmTE-0007YE-Jy;
	Mon, 15 Oct 2012 16:20:44 +0100
From: Ian Campbell 
To: 
Date: Mon, 15 Oct 2012 15:20:35 +0000
Message-ID: <1350314444-17148-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
References: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Keir Fraser , Ian Campbell ,
	Stefano Stabellini ,
	Tim Deegan ,
	Stefano Stabellini ,
	Jan Beulich 
Subject: [Xen-devel] [PATCH 02/10] xen/arm: grant table
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Stefano Stabellini 

Implement XENMAPSPACE_grant_table and grant_table_op.

Signed-off-by: Stefano Stabellini 
Acked-by: Tim Deegan 
[ ijc -- fixed reject in traps.c, grant table op is a 3 argument
         hypercall, rebased over "xen: arm: implement
         XENMEM_add_to_physmap_range"
]
Signed-off-by: Ian Campbell 
---
 xen/arch/arm/mm.c    |   26 ++++++++++++++++++++++++++
 xen/arch/arm/traps.c |    1 +
 2 files changed, 27 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 591ad3a..edd5ca7 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -473,6 +474,31 @@ static int xenmem_add_to_physmap_one(
 
     switch ( space )
     {
+    case XENMAPSPACE_grant_table:
+        spin_lock(&d->grant_table->lock);
+
+        if ( d->grant_table->gt_version == 0 )
+            d->grant_table->gt_version = 1;
+
+        if ( d->grant_table->gt_version == 2 &&
+                (idx & XENMAPIDX_grant_table_status) )
+        {
+            idx &= ~XENMAPIDX_grant_table_status;
+            if ( idx < nr_status_frames(d->grant_table) )
+                mfn = virt_to_mfn(d->grant_table->status[idx]);
+        }
+        else
+        {
+            if ( (idx >= nr_grant_frames(d->grant_table)) &&
+                    (idx < max_nr_grant_frames) )
+                gnttab_grow_table(d, idx + 1);
+
+            if ( idx < nr_grant_frames(d->grant_table) )
+                mfn = virt_to_mfn(d->grant_table->shared_raw[idx]);
+        }
+
+        spin_unlock(&d->grant_table->lock);
+        break;
     case XENMAPSPACE_shared_info:
         if ( idx == 0 )
             mfn = virt_to_mfn(d->shared_info);
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 98cc750..19e2081 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -438,6 +438,7 @@ static arm_hypercall_t arm_hypercall_table[] = {
     HYPERCALL(physdev_op, 2),
     HYPERCALL(sysctl, 2),
     HYPERCALL(hvm_op, 2),
+    HYPERCALL(grant_table_op, 3),
 };
 
 static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code)
-- 
1.7.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 15:21:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 15:21:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNmTL-0004Vn-Ga; Mon, 15 Oct 2012 15:20:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNmTK-0004VA-3E
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 15:20:50 +0000
Received: from [85.158.138.51:16827] by server-4.bemta-3.messagelabs.com id
	62/22-01405-1D92C705; Mon, 15 Oct 2012 15:20:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1350314445!26846382!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODI0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2920 invoked from network); 15 Oct 2012 15:20:48 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 15:20:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,588,1344211200"; d="scan'208";a="211302569"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 15:20:45 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 11:20:45 -0400
Received: from [10.80.246.74] (helo=army.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TNmTE-0007YE-N7;
	Mon, 15 Oct 2012 16:20:44 +0100
From: Ian Campbell 
To: 
Date: Mon, 15 Oct 2012 15:20:36 +0000
Message-ID: <1350314444-17148-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
References: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Keir Fraser , Ian Campbell ,
	Tim Deegan ,
	Stefano Stabellini ,
	Jan Beulich 
Subject: [Xen-devel] [PATCH 03/10] arm: tools: add arm to foreign structs
	checking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Campbell 
---
 tools/include/xen-foreign/Makefile       |    5 ++++-
 tools/include/xen-foreign/mkheader.py    |    7 +++++++
 tools/include/xen-foreign/reference.size |   20 ++++++++++----------
 tools/include/xen-foreign/structs.py     |    7 ++++++-
 4 files changed, 27 insertions(+), 12 deletions(-)

diff --git a/tools/include/xen-foreign/Makefile b/tools/include/xen-foreign/Makefile
index 8b22b10..cfaf790 100644
--- a/tools/include/xen-foreign/Makefile
+++ b/tools/include/xen-foreign/Makefile
@@ -3,7 +3,7 @@ include $(XEN_ROOT)/tools/Rules.mk
 
 ROOT = $(XEN_ROOT)/xen/include/public
 
-architectures := x86_32 x86_64
+architectures := arm x86_32 x86_64
 headers := $(patsubst %, %.h, $(architectures))
 
 .PHONY: all clean check-headers
@@ -22,6 +22,9 @@ check-headers: checker
 	diff -u reference.size tmp.size
 	rm tmp.size
 
+arm.h: mkheader.py structs.py $(ROOT)/arch-arm.h
+	$(PYTHON) $< $* $@ $(filter %.h,$^)
+
 x86_32.h: mkheader.py structs.py $(ROOT)/arch-x86/xen-x86_32.h $(ROOT)/arch-x86/xen.h $(ROOT)/xen.h
 	$(PYTHON) $< $* $@ $(filter %.h,$^)
 
diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py
index 797a880..d189b07 100644
--- a/tools/include/xen-foreign/mkheader.py
+++ b/tools/include/xen-foreign/mkheader.py
@@ -16,6 +16,13 @@ inttypes = {};
 header = {};
 footer = {};
 
+#arm
+inttypes["arm"] = {
+    "unsigned long" : "uint32_t",
+    "long"          : "uint32_t",
+    "xen_pfn_t"     : "uint64_t",
+};
+
 # x86_32
 inttypes["x86_32"] = {
     "unsigned long" : "uint32_t",
diff --git a/tools/include/xen-foreign/reference.size b/tools/include/xen-foreign/reference.size
index fac1b1d..a2cbfd6 100644
--- a/tools/include/xen-foreign/reference.size
+++ b/tools/include/xen-foreign/reference.size
@@ -1,13 +1,13 @@
 
-structs                   |  x86_32  x86_64
+structs                   |     arm  x86_32  x86_64
 
-start_info                |    1112    1168
-trap_info                 |       8      16
-cpu_user_regs             |      68     200
-vcpu_guest_context        |    2800    5168
-arch_vcpu_info            |      24      16
-vcpu_time_info            |      32      32
-vcpu_info                 |      64      64
-arch_shared_info          |     268     280
-shared_info               |    2584    3368
+start_info                |       -    1112    1168
+trap_info                 |       -       8      16
+cpu_user_regs             |     160      68     200
+vcpu_guest_context        |     180    2800    5168
+arch_vcpu_info            |       -      24      16
+vcpu_time_info            |       -      32      32
+vcpu_info                 |       -      64      64
+arch_shared_info          |       -     268     280
+shared_info               |       -    2584    3368
 
diff --git a/tools/include/xen-foreign/structs.py b/tools/include/xen-foreign/structs.py
index 571f7bb..51a77c0 100644
--- a/tools/include/xen-foreign/structs.py
+++ b/tools/include/xen-foreign/structs.py
@@ -13,9 +13,14 @@ structs = [ "start_info",
             "arch_shared_info",
             "shared_info" ];
 
-defines = [ "__i386__",
+defines = [ "__arm__",
+            "__i386__",
             "__x86_64__",
 
+            # arm
+            # None
+
+            # x86_{32,64}
             "FLAT_RING1_CS",
             "FLAT_RING1_DS",
             "FLAT_RING1_SS",
-- 
1.7.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 15:21:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 15:21:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNmTL-0004Vn-Ga; Mon, 15 Oct 2012 15:20:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNmTK-0004VA-3E
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 15:20:50 +0000
Received: from [85.158.138.51:16827] by server-4.bemta-3.messagelabs.com id
	62/22-01405-1D92C705; Mon, 15 Oct 2012 15:20:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1350314445!26846382!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODI0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2920 invoked from network); 15 Oct 2012 15:20:48 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 15:20:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,588,1344211200"; d="scan'208";a="211302569"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 15:20:45 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 11:20:45 -0400
Received: from [10.80.246.74] (helo=army.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TNmTE-0007YE-N7;
	Mon, 15 Oct 2012 16:20:44 +0100
From: Ian Campbell 
To: 
Date: Mon, 15 Oct 2012 15:20:36 +0000
Message-ID: <1350314444-17148-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
References: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Keir Fraser , Ian Campbell ,
	Tim Deegan ,
	Stefano Stabellini ,
	Jan Beulich 
Subject: [Xen-devel] [PATCH 03/10] arm: tools: add arm to foreign structs
	checking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Campbell 
---
 tools/include/xen-foreign/Makefile       |    5 ++++-
 tools/include/xen-foreign/mkheader.py    |    7 +++++++
 tools/include/xen-foreign/reference.size |   20 ++++++++++----------
 tools/include/xen-foreign/structs.py     |    7 ++++++-
 4 files changed, 27 insertions(+), 12 deletions(-)

diff --git a/tools/include/xen-foreign/Makefile b/tools/include/xen-foreign/Makefile
index 8b22b10..cfaf790 100644
--- a/tools/include/xen-foreign/Makefile
+++ b/tools/include/xen-foreign/Makefile
@@ -3,7 +3,7 @@ include $(XEN_ROOT)/tools/Rules.mk
 
 ROOT = $(XEN_ROOT)/xen/include/public
 
-architectures := x86_32 x86_64
+architectures := arm x86_32 x86_64
 headers := $(patsubst %, %.h, $(architectures))
 
 .PHONY: all clean check-headers
@@ -22,6 +22,9 @@ check-headers: checker
 	diff -u reference.size tmp.size
 	rm tmp.size
 
+arm.h: mkheader.py structs.py $(ROOT)/arch-arm.h
+	$(PYTHON) $< $* $@ $(filter %.h,$^)
+
 x86_32.h: mkheader.py structs.py $(ROOT)/arch-x86/xen-x86_32.h $(ROOT)/arch-x86/xen.h $(ROOT)/xen.h
 	$(PYTHON) $< $* $@ $(filter %.h,$^)
 
diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py
index 797a880..d189b07 100644
--- a/tools/include/xen-foreign/mkheader.py
+++ b/tools/include/xen-foreign/mkheader.py
@@ -16,6 +16,13 @@ inttypes = {};
 header = {};
 footer = {};
 
+#arm
+inttypes["arm"] = {
+    "unsigned long" : "uint32_t",
+    "long"          : "uint32_t",
+    "xen_pfn_t"     : "uint64_t",
+};
+
 # x86_32
 inttypes["x86_32"] = {
     "unsigned long" : "uint32_t",
diff --git a/tools/include/xen-foreign/reference.size b/tools/include/xen-foreign/reference.size
index fac1b1d..a2cbfd6 100644
--- a/tools/include/xen-foreign/reference.size
+++ b/tools/include/xen-foreign/reference.size
@@ -1,13 +1,13 @@
 
-structs                   |  x86_32  x86_64
+structs                   |     arm  x86_32  x86_64
 
-start_info                |    1112    1168
-trap_info                 |       8      16
-cpu_user_regs             |      68     200
-vcpu_guest_context        |    2800    5168
-arch_vcpu_info            |      24      16
-vcpu_time_info            |      32      32
-vcpu_info                 |      64      64
-arch_shared_info          |     268     280
-shared_info               |    2584    3368
+start_info                |       -    1112    1168
+trap_info                 |       -       8      16
+cpu_user_regs             |     160      68     200
+vcpu_guest_context        |     180    2800    5168
+arch_vcpu_info            |       -      24      16
+vcpu_time_info            |       -      32      32
+vcpu_info                 |       -      64      64
+arch_shared_info          |       -     268     280
+shared_info               |       -    2584    3368
 
diff --git a/tools/include/xen-foreign/structs.py b/tools/include/xen-foreign/structs.py
index 571f7bb..51a77c0 100644
--- a/tools/include/xen-foreign/structs.py
+++ b/tools/include/xen-foreign/structs.py
@@ -13,9 +13,14 @@ structs = [ "start_info",
             "arch_shared_info",
             "shared_info" ];
 
-defines = [ "__i386__",
+defines = [ "__arm__",
+            "__i386__",
             "__x86_64__",
 
+            # arm
+            # None
+
+            # x86_{32,64}
             "FLAT_RING1_CS",
             "FLAT_RING1_DS",
             "FLAT_RING1_SS",
-- 
1.7.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 15:21:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 15:21:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNmTJ-0004V5-AV; Mon, 15 Oct 2012 15:20:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNmTH-0004Ut-IU
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 15:20:47 +0000
Received: from [85.158.139.83:62049] by server-13.bemta-5.messagelabs.com id
	81/E0-30674-EC92C705; Mon, 15 Oct 2012 15:20:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1350314446!32093059!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11556 invoked from network); 15 Oct 2012 15:20:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 15:20:46 -0000
X-IronPort-AV: E=Sophos;i="4.80,588,1344211200"; d="scan'208";a="15174943"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 15:20:20 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 16:20:19 +0100
Message-ID: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: xen-devel 
Date: Mon, 15 Oct 2012 16:20:18 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Tim Deegan , Keir Fraser ,
	Stefano Stabellini ,
	Jan Beulich 
Subject: [Xen-devel] [PATCH v2 00/10] 64 bit ARM ABI, map foreign gmfn API,
 ARM grant tables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is v2 of "Sweep through arm-for-4.3 branch + a bit extra" retitled
since most of the sweep through stuff has been swept through already and
just the bit extra remains.

I've addressed the review comments and fixed the bisection issue. A
bunch of this stuff is cross arch and/or touches common code.

The Linux side of the 64 bit ARM ABI changes are in mainline Linux
already (just a few tweaks and cleanups remain).

xen: arm: implement XENMEM_add_to_physmap_range

        New hypercall intended for use by both ARM (Linux patches exist)
        and x86 PVH (TBD)
        
xen/arm: grant table

        Simple wiring up job. Acked but depends on
        XENMEM_add_to_physmap_range.
        
arm: tools: add arm to foreign structs checking
        
        Fixes native tools build on ARM

xen: xen_ulong_t substitution
xen: change the limit of nr_extents to UINT_MAX >> MEMOP_EXTENT_SHIFT
xen: introduce XEN_GUEST_HANDLE_PARAM
xen: replace XEN_GUEST_HANDLE with XEN_GUEST_HANDLE_PARAM when appropriate
xen: more XEN_GUEST_HANDLE_PARAM substitutions
xen: remove XEN_GUEST_HANDLE(ulong)
arm: parameter guest handles are 32 bit on 32 bit hypervisor

        These are the ARM 64 bit API, mostly from Stefano and posted
        several times already.
        
Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 15:21:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 15:21:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNmTJ-0004V5-AV; Mon, 15 Oct 2012 15:20:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNmTH-0004Ut-IU
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 15:20:47 +0000
Received: from [85.158.139.83:62049] by server-13.bemta-5.messagelabs.com id
	81/E0-30674-EC92C705; Mon, 15 Oct 2012 15:20:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1350314446!32093059!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11556 invoked from network); 15 Oct 2012 15:20:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 15:20:46 -0000
X-IronPort-AV: E=Sophos;i="4.80,588,1344211200"; d="scan'208";a="15174943"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 15:20:20 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 16:20:19 +0100
Message-ID: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: xen-devel 
Date: Mon, 15 Oct 2012 16:20:18 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Tim Deegan , Keir Fraser ,
	Stefano Stabellini ,
	Jan Beulich 
Subject: [Xen-devel] [PATCH v2 00/10] 64 bit ARM ABI, map foreign gmfn API,
 ARM grant tables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is v2 of "Sweep through arm-for-4.3 branch + a bit extra" retitled
since most of the sweep through stuff has been swept through already and
just the bit extra remains.

I've addressed the review comments and fixed the bisection issue. A
bunch of this stuff is cross arch and/or touches common code.

The Linux side of the 64 bit ARM ABI changes are in mainline Linux
already (just a few tweaks and cleanups remain).

xen: arm: implement XENMEM_add_to_physmap_range

        New hypercall intended for use by both ARM (Linux patches exist)
        and x86 PVH (TBD)
        
xen/arm: grant table

        Simple wiring up job. Acked but depends on
        XENMEM_add_to_physmap_range.
        
arm: tools: add arm to foreign structs checking
        
        Fixes native tools build on ARM

xen: xen_ulong_t substitution
xen: change the limit of nr_extents to UINT_MAX >> MEMOP_EXTENT_SHIFT
xen: introduce XEN_GUEST_HANDLE_PARAM
xen: replace XEN_GUEST_HANDLE with XEN_GUEST_HANDLE_PARAM when appropriate
xen: more XEN_GUEST_HANDLE_PARAM substitutions
xen: remove XEN_GUEST_HANDLE(ulong)
arm: parameter guest handles are 32 bit on 32 bit hypervisor

        These are the ARM 64 bit API, mostly from Stefano and posted
        several times already.
        
Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 15:21:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 15:21:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNmTO-0004Wr-5W; Mon, 15 Oct 2012 15:20:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNmTL-0004VN-NL
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 15:20:51 +0000
Received: from [85.158.139.83:62466] by server-16.bemta-5.messagelabs.com id
	6F/B3-09196-3D92C705; Mon, 15 Oct 2012 15:20:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1350314447!30404431!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODI0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1869 invoked from network); 15 Oct 2012 15:20:50 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 15:20:50 -0000
X-IronPort-AV: E=Sophos;i="4.80,588,1344211200"; d="scan'208";a="211302573"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 15:20:46 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 11:20:45 -0400
Received: from [10.80.246.74] (helo=army.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TNmTF-0007YE-Cb;
	Mon, 15 Oct 2012 16:20:45 +0100
From: Ian Campbell 
To: 
Date: Mon, 15 Oct 2012 15:20:43 +0000
Message-ID: <1350314444-17148-10-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
References: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Keir Fraser , Ian Campbell ,
	Tim Deegan ,
	Stefano Stabellini ,
	Jan Beulich 
Subject: [Xen-devel] [PATCH 10/10] arm: parameter guest handles are 32 bit
	on 32 bit hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Handles within structs remain 64 bit such that they are consistently
sized on both 32 and 64 bit.

Signed-off-by: Ian Campbell 
---
 xen/include/public/arch-arm.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index ac493a5..ff02d15 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -74,7 +74,7 @@
 #define __XEN_GUEST_HANDLE(name)        __guest_handle_64_ ## name
 #define XEN_GUEST_HANDLE(name)          __XEN_GUEST_HANDLE(name)
 /* this is going to be changed on 64 bit */
-#define XEN_GUEST_HANDLE_PARAM(name)   XEN_GUEST_HANDLE(name)
+#define XEN_GUEST_HANDLE_PARAM(name)    __guest_handle_ ## name
 #define set_xen_guest_handle_raw(hnd, val)                  \
     do {                                                    \
         typeof(&(hnd)) _sxghr_tmp = &(hnd);                 \
-- 
1.7.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 15:21:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 15:21:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNmTO-0004Wr-5W; Mon, 15 Oct 2012 15:20:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNmTL-0004VN-NL
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 15:20:51 +0000
Received: from [85.158.139.83:62466] by server-16.bemta-5.messagelabs.com id
	6F/B3-09196-3D92C705; Mon, 15 Oct 2012 15:20:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1350314447!30404431!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODI0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1869 invoked from network); 15 Oct 2012 15:20:50 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 15:20:50 -0000
X-IronPort-AV: E=Sophos;i="4.80,588,1344211200"; d="scan'208";a="211302573"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 15:20:46 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 11:20:45 -0400
Received: from [10.80.246.74] (helo=army.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TNmTF-0007YE-Cb;
	Mon, 15 Oct 2012 16:20:45 +0100
From: Ian Campbell 
To: 
Date: Mon, 15 Oct 2012 15:20:43 +0000
Message-ID: <1350314444-17148-10-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
References: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Keir Fraser , Ian Campbell ,
	Tim Deegan ,
	Stefano Stabellini ,
	Jan Beulich 
Subject: [Xen-devel] [PATCH 10/10] arm: parameter guest handles are 32 bit
	on 32 bit hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Handles within structs remain 64 bit such that they are consistently
sized on both 32 and 64 bit.

Signed-off-by: Ian Campbell 
---
 xen/include/public/arch-arm.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index ac493a5..ff02d15 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -74,7 +74,7 @@
 #define __XEN_GUEST_HANDLE(name)        __guest_handle_64_ ## name
 #define XEN_GUEST_HANDLE(name)          __XEN_GUEST_HANDLE(name)
 /* this is going to be changed on 64 bit */
-#define XEN_GUEST_HANDLE_PARAM(name)   XEN_GUEST_HANDLE(name)
+#define XEN_GUEST_HANDLE_PARAM(name)    __guest_handle_ ## name
 #define set_xen_guest_handle_raw(hnd, val)                  \
     do {                                                    \
         typeof(&(hnd)) _sxghr_tmp = &(hnd);                 \
-- 
1.7.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 15:25:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 15:25:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNmXQ-0005qg-PR; Mon, 15 Oct 2012 15:25:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNmXP-0005qW-LN
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 15:25:03 +0000
Received: from [85.158.138.51:41876] by server-4.bemta-3.messagelabs.com id
	33/88-01405-ECA2C705; Mon, 15 Oct 2012 15:25:02 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1350314700!26419553!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYzNjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16380 invoked from network); 15 Oct 2012 15:25:02 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 15:25:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,588,1344211200"; d="scan'208";a="41237846"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 15:25:00 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 11:24:59 -0400
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TNmXL-0007bu-JW;
	Mon, 15 Oct 2012 16:24:59 +0100
MIME-Version: 1.0
X-Mercurial-Node: 952b1ef292469c9a9af59ab82f7e3134c2cf3a04
Message-ID: <952b1ef292469c9a9af5.1350314699@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.3.2
Date: Mon, 15 Oct 2012 16:24:59 +0100
From: Andrew Cooper 
To: xen-devel@lists.xen.org
Cc: Ian Campbell ,
	Ian Jackson 
Subject: [Xen-devel] [PATCH] build/xenstore: Correct static link failure for
	xenstore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

There is support for building xenstore clients statically.  However,
recent changes to the makefiles have rendered the static build broken.

tools/xenstore/Makefile sets LIBXENSTORE depending on whether
XENSTORE_STATIC_CLIENTS is specified, but will unconditionally try to
link against libxenstore.so by use of the LDLIBS_libxenstore variable.

This patch doubles the logic already present to select the appropriate
library target.

Signed-off-by: Andrew Cooper 

--
This is a bit of a hack, but seems to be the only reliable way,
espcially when linking with the LDLIBS_libxenstore variable in
toos/misc.

diff -r 099589002239 -r 952b1ef29246 tools/Rules.mk
--- a/tools/Rules.mk
+++ b/tools/Rules.mk
@@ -28,7 +28,11 @@ LDLIBS_libxenguest = $(XEN_LIBXC)/libxen
 SHLIB_libxenguest  = -Wl,-rpath-link=L$(XEN_LIBXC)
 
 CFLAGS_libxenstore = -I$(XEN_XENSTORE) $(CFLAGS_xeninclude)
+ifneq ($(XENSTORE_STATIC_CLIENTS),y)
 LDLIBS_libxenstore = $(XEN_XENSTORE)/libxenstore.so
+else
+LDLIBS_libxenstore = $(XEN_XENSTORE)/libxenstore.a
+endif
 SHLIB_libxenstore  = -Wl,-rpath-link=$(XEN_XENSTORE)
 
 CFLAGS_libxenstat  = -I$(XEN_LIBXENSTAT)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 15:25:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 15:25:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNmXQ-0005qg-PR; Mon, 15 Oct 2012 15:25:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNmXP-0005qW-LN
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 15:25:03 +0000
Received: from [85.158.138.51:41876] by server-4.bemta-3.messagelabs.com id
	33/88-01405-ECA2C705; Mon, 15 Oct 2012 15:25:02 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1350314700!26419553!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzYzNjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16380 invoked from network); 15 Oct 2012 15:25:02 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 15:25:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,588,1344211200"; d="scan'208";a="41237846"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 15:25:00 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 11:24:59 -0400
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TNmXL-0007bu-JW;
	Mon, 15 Oct 2012 16:24:59 +0100
MIME-Version: 1.0
X-Mercurial-Node: 952b1ef292469c9a9af59ab82f7e3134c2cf3a04
Message-ID: <952b1ef292469c9a9af5.1350314699@andrewcoop.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.3.2
Date: Mon, 15 Oct 2012 16:24:59 +0100
From: Andrew Cooper 
To: xen-devel@lists.xen.org
Cc: Ian Campbell ,
	Ian Jackson 
Subject: [Xen-devel] [PATCH] build/xenstore: Correct static link failure for
	xenstore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

There is support for building xenstore clients statically.  However,
recent changes to the makefiles have rendered the static build broken.

tools/xenstore/Makefile sets LIBXENSTORE depending on whether
XENSTORE_STATIC_CLIENTS is specified, but will unconditionally try to
link against libxenstore.so by use of the LDLIBS_libxenstore variable.

This patch doubles the logic already present to select the appropriate
library target.

Signed-off-by: Andrew Cooper 

--
This is a bit of a hack, but seems to be the only reliable way,
espcially when linking with the LDLIBS_libxenstore variable in
toos/misc.

diff -r 099589002239 -r 952b1ef29246 tools/Rules.mk
--- a/tools/Rules.mk
+++ b/tools/Rules.mk
@@ -28,7 +28,11 @@ LDLIBS_libxenguest = $(XEN_LIBXC)/libxen
 SHLIB_libxenguest  = -Wl,-rpath-link=L$(XEN_LIBXC)
 
 CFLAGS_libxenstore = -I$(XEN_XENSTORE) $(CFLAGS_xeninclude)
+ifneq ($(XENSTORE_STATIC_CLIENTS),y)
 LDLIBS_libxenstore = $(XEN_XENSTORE)/libxenstore.so
+else
+LDLIBS_libxenstore = $(XEN_XENSTORE)/libxenstore.a
+endif
 SHLIB_libxenstore  = -Wl,-rpath-link=$(XEN_XENSTORE)
 
 CFLAGS_libxenstat  = -I$(XEN_LIBXENSTAT)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 15:26:33 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 15:26:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNmYh-00062Y-Cv; Mon, 15 Oct 2012 15:26:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNmYg-00062I-4D
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 15:26:22 +0000
Received: from [85.158.143.99:24212] by server-3.bemta-4.messagelabs.com id
	00/61-10075-D1B2C705; Mon, 15 Oct 2012 15:26:21 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1350314780!33575905!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3682 invoked from network); 15 Oct 2012 15:26:20 -0000
Received: from mail-ea0-f173.google.com (HELO mail-ea0-f173.google.com)
	(209.85.215.173)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 15:26:20 -0000
Received: by mail-ea0-f173.google.com with SMTP id a1so1231647eaa.32
	for ; Mon, 15 Oct 2012 08:26:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=LDOoLBPfrhAIhv45RxcmvwYvAzRQr1XvdEV/Z2YRITo=;
	b=uD8EN35d0k09TQbXaJoET/HSny2BL9cbgBW8mzOsJCKp46TOL6+xMyLSNQDtqThQd/
	+mmw1wEZyahmR+qFGpHRvtCBtcQlpUAy2wbLdhCJx5uxMuVEeJOWHepi/gj4a9X7zr4H
	zY5t55tMcf9vs9MF5pATaEjaQhbx79w7QJRzlPos93Oso6EnllkNaAEyKOkP3cHc9Fr1
	Wp/bV4sp39dpkLtB/hMuuL293Dlxfq/zD9MY/UmGjV7yuANpY95NzVxIgyDzP9IwA341
	HWNv3r39yvP0MI0joJi9SKA5TOM8SKxbs5eTqKgQV6vL7Kf4xZVtntd68C62Dbl8KrrG
	SLFQ==
Received: by 10.14.203.65 with SMTP id e41mr1618823eeo.34.1350314780370;
	Mon, 15 Oct 2012 08:26:20 -0700 (PDT)
Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com.
	[86.183.156.141])
	by mx.google.com with ESMTPS id 42sm25498160eee.0.2012.10.15.08.26.18
	(version=SSLv3 cipher=OTHER); Mon, 15 Oct 2012 08:26:19 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Mon, 15 Oct 2012 16:26:14 +0100
From: Keir Fraser 
To: Daniel De Graaf , ,
	
Message-ID: 
Thread-Topic: [PATCH] xen: Add versions of rcu_lock_*_domain without IS_PRIV
Thread-Index: Ac2q6WmibXgI0DoYRUCTqz5CRniQmQ==
In-Reply-To: <1350309759-4635-1-git-send-email-dgdegra@tycho.nsa.gov>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] xen: Add versions of rcu_lock_*_domain
	without IS_PRIV
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Must we have two new calls for translating a domid to a domain? It's getting
to be a confusing mess isn't it? Also, here, a more consistent name for
rcu_lock_domain_by_any_id would be rcu_lock_any_domain_by_id, I think?

 -- Keir


On 15/10/2012 15:02, "Daniel De Graaf"  wrote:

> While this patch is a part of my XSM IS_PRIV series, I am reposting it
> alone because the XSM build of xen-unstable is currently broken. I can
> also repost the remaining patches series if that would be helpful.
> 
> --------------------------------->8----------------------------------
> 
> These functions will be used to avoid duplication of IS_PRIV calls
> that will be introduced in XSM hooks. This also fixes a build error
> with XSM enabled introduced by 25925:d1c3375c3f11 which depends on
> this patch.
> 
> Signed-off-by: Daniel De Graaf 
> ---
>  xen/common/domain.c     | 21 +++++++++++++++++++++
>  xen/include/xen/sched.h | 11 +++++++++++
>  2 files changed, 32 insertions(+)
> 
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index a1aa05e..52489b3 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -420,6 +420,13 @@ struct domain *rcu_lock_domain_by_id(domid_t dom)
>      return d;
>  }
>  
> +struct domain *rcu_lock_domain_by_any_id(domid_t dom)
> +{
> +    if ( dom == DOMID_SELF )
> +        return rcu_lock_current_domain();
> +    return rcu_lock_domain_by_id(dom);
> +}
> +
>  int rcu_lock_target_domain_by_id(domid_t dom, struct domain **d)
>  {
>      if ( dom == DOMID_SELF )
> @@ -454,6 +461,20 @@ int rcu_lock_remote_target_domain_by_id(domid_t dom,
> struct domain **d)
>      return 0;
>  }
>  
> +int rcu_lock_remote_domain_by_id(domid_t dom, struct domain **d)
> +{
> +    if ( (*d = rcu_lock_domain_by_id(dom)) == NULL )
> +        return -ESRCH;
> +
> +    if ( *d == current->domain )
> +    {
> +        rcu_unlock_domain(*d);
> +        return -EPERM;
> +    }
> +
> +    return 0;
> +}
> +
>  int domain_kill(struct domain *d)
>  {
>      int rc = 0;
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> index 53804c8..b0def4a 100644
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -447,6 +447,11 @@ struct domain *domain_create(
>  struct domain *rcu_lock_domain_by_id(domid_t dom);
>  
>  /*
> + * As above function, but resolves DOMID_SELF to current domain
> + */
> +struct domain *rcu_lock_domain_by_any_id(domid_t dom);
> +
> +/*
>   * As above function, but accounts for current domain context:
>   *  - Translates target DOMID_SELF into caller's domain id; and
>   *  - Checks that caller has permission to act on the target domain.
> @@ -460,6 +465,12 @@ int rcu_lock_target_domain_by_id(domid_t dom, struct
> domain **d);
>   */
>  int rcu_lock_remote_target_domain_by_id(domid_t dom, struct domain **d);
>  
> +/*
> + * As rcu_lock_domain_by_id(), but will fail EPERM or ESRCH rather than
> resolve
> + * to local domain.
> + */
> +int rcu_lock_remote_domain_by_id(domid_t dom, struct domain **d);
> +
>  /* Finish a RCU critical region started by rcu_lock_domain_by_id(). */
>  static inline void rcu_unlock_domain(struct domain *d)
>  {



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 15:26:33 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 15:26:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNmYh-00062Y-Cv; Mon, 15 Oct 2012 15:26:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNmYg-00062I-4D
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 15:26:22 +0000
Received: from [85.158.143.99:24212] by server-3.bemta-4.messagelabs.com id
	00/61-10075-D1B2C705; Mon, 15 Oct 2012 15:26:21 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1350314780!33575905!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3682 invoked from network); 15 Oct 2012 15:26:20 -0000
Received: from mail-ea0-f173.google.com (HELO mail-ea0-f173.google.com)
	(209.85.215.173)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 15:26:20 -0000
Received: by mail-ea0-f173.google.com with SMTP id a1so1231647eaa.32
	for ; Mon, 15 Oct 2012 08:26:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=LDOoLBPfrhAIhv45RxcmvwYvAzRQr1XvdEV/Z2YRITo=;
	b=uD8EN35d0k09TQbXaJoET/HSny2BL9cbgBW8mzOsJCKp46TOL6+xMyLSNQDtqThQd/
	+mmw1wEZyahmR+qFGpHRvtCBtcQlpUAy2wbLdhCJx5uxMuVEeJOWHepi/gj4a9X7zr4H
	zY5t55tMcf9vs9MF5pATaEjaQhbx79w7QJRzlPos93Oso6EnllkNaAEyKOkP3cHc9Fr1
	Wp/bV4sp39dpkLtB/hMuuL293Dlxfq/zD9MY/UmGjV7yuANpY95NzVxIgyDzP9IwA341
	HWNv3r39yvP0MI0joJi9SKA5TOM8SKxbs5eTqKgQV6vL7Kf4xZVtntd68C62Dbl8KrrG
	SLFQ==
Received: by 10.14.203.65 with SMTP id e41mr1618823eeo.34.1350314780370;
	Mon, 15 Oct 2012 08:26:20 -0700 (PDT)
Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com.
	[86.183.156.141])
	by mx.google.com with ESMTPS id 42sm25498160eee.0.2012.10.15.08.26.18
	(version=SSLv3 cipher=OTHER); Mon, 15 Oct 2012 08:26:19 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Mon, 15 Oct 2012 16:26:14 +0100
From: Keir Fraser 
To: Daniel De Graaf , ,
	
Message-ID: 
Thread-Topic: [PATCH] xen: Add versions of rcu_lock_*_domain without IS_PRIV
Thread-Index: Ac2q6WmibXgI0DoYRUCTqz5CRniQmQ==
In-Reply-To: <1350309759-4635-1-git-send-email-dgdegra@tycho.nsa.gov>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] xen: Add versions of rcu_lock_*_domain
	without IS_PRIV
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Must we have two new calls for translating a domid to a domain? It's getting
to be a confusing mess isn't it? Also, here, a more consistent name for
rcu_lock_domain_by_any_id would be rcu_lock_any_domain_by_id, I think?

 -- Keir


On 15/10/2012 15:02, "Daniel De Graaf"  wrote:

> While this patch is a part of my XSM IS_PRIV series, I am reposting it
> alone because the XSM build of xen-unstable is currently broken. I can
> also repost the remaining patches series if that would be helpful.
> 
> --------------------------------->8----------------------------------
> 
> These functions will be used to avoid duplication of IS_PRIV calls
> that will be introduced in XSM hooks. This also fixes a build error
> with XSM enabled introduced by 25925:d1c3375c3f11 which depends on
> this patch.
> 
> Signed-off-by: Daniel De Graaf 
> ---
>  xen/common/domain.c     | 21 +++++++++++++++++++++
>  xen/include/xen/sched.h | 11 +++++++++++
>  2 files changed, 32 insertions(+)
> 
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index a1aa05e..52489b3 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -420,6 +420,13 @@ struct domain *rcu_lock_domain_by_id(domid_t dom)
>      return d;
>  }
>  
> +struct domain *rcu_lock_domain_by_any_id(domid_t dom)
> +{
> +    if ( dom == DOMID_SELF )
> +        return rcu_lock_current_domain();
> +    return rcu_lock_domain_by_id(dom);
> +}
> +
>  int rcu_lock_target_domain_by_id(domid_t dom, struct domain **d)
>  {
>      if ( dom == DOMID_SELF )
> @@ -454,6 +461,20 @@ int rcu_lock_remote_target_domain_by_id(domid_t dom,
> struct domain **d)
>      return 0;
>  }
>  
> +int rcu_lock_remote_domain_by_id(domid_t dom, struct domain **d)
> +{
> +    if ( (*d = rcu_lock_domain_by_id(dom)) == NULL )
> +        return -ESRCH;
> +
> +    if ( *d == current->domain )
> +    {
> +        rcu_unlock_domain(*d);
> +        return -EPERM;
> +    }
> +
> +    return 0;
> +}
> +
>  int domain_kill(struct domain *d)
>  {
>      int rc = 0;
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> index 53804c8..b0def4a 100644
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -447,6 +447,11 @@ struct domain *domain_create(
>  struct domain *rcu_lock_domain_by_id(domid_t dom);
>  
>  /*
> + * As above function, but resolves DOMID_SELF to current domain
> + */
> +struct domain *rcu_lock_domain_by_any_id(domid_t dom);
> +
> +/*
>   * As above function, but accounts for current domain context:
>   *  - Translates target DOMID_SELF into caller's domain id; and
>   *  - Checks that caller has permission to act on the target domain.
> @@ -460,6 +465,12 @@ int rcu_lock_target_domain_by_id(domid_t dom, struct
> domain **d);
>   */
>  int rcu_lock_remote_target_domain_by_id(domid_t dom, struct domain **d);
>  
> +/*
> + * As rcu_lock_domain_by_id(), but will fail EPERM or ESRCH rather than
> resolve
> + * to local domain.
> + */
> +int rcu_lock_remote_domain_by_id(domid_t dom, struct domain **d);
> +
>  /* Finish a RCU critical region started by rcu_lock_domain_by_id(). */
>  static inline void rcu_unlock_domain(struct domain *d)
>  {



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 15:27:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 15:27:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNmZa-0006BA-Qz; Mon, 15 Oct 2012 15:27:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNmZZ-0006Am-LE
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 15:27:17 +0000
Received: from [85.158.137.99:33387] by server-7.bemta-3.messagelabs.com id
	EC/1E-06991-45B2C705; Mon, 15 Oct 2012 15:27:16 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1350314835!21691274!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16516 invoked from network); 15 Oct 2012 15:27:16 -0000
Received: from mail-ea0-f173.google.com (HELO mail-ea0-f173.google.com)
	(209.85.215.173)
	by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 15:27:16 -0000
Received: by mail-ea0-f173.google.com with SMTP id a1so1231942eaa.32
	for ; Mon, 15 Oct 2012 08:27:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=7LvrW8TCRlG8CyXUseLT96SAJmvDqfmtdXBcuLBslOU=;
	b=IhwdGGw+NYrjoqERejOIDZ6T4z5FffCuEpLwvmKH9ygYo7G/WWfyChu5SEc5N1u44s
	yrDu7YgeI6dV0n4LvONnIlw8T0NR/s7mWJqZZ8SWdhUWl4wqby+WGwOiXPf+qvgowQHF
	tie+ATcFyuZD7d4zOkDQ67Sai2TOaqRoVnInBfPnyAUWmXKlV6l3au47q9Jkd0x9MNXV
	ANsoZWuoP1dBp6Nf24CxN3bnO6UQngi04q0J2h+P1QdrpCTAKAG6Ru3AOhro/CuiTVMq
	TUOQd/uGnXADE2B0WK2UxdmgsPW9G3z1421+Laj3SmpkvoU4YE8eReeu3jQ2HJbz265O
	gzQw==
Received: by 10.14.214.2 with SMTP id b2mr7876409eep.32.1350314835617;
	Mon, 15 Oct 2012 08:27:15 -0700 (PDT)
Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com.
	[86.183.156.141])
	by mx.google.com with ESMTPS id d44sm25511657eeo.10.2012.10.15.08.27.14
	(version=SSLv3 cipher=OTHER); Mon, 15 Oct 2012 08:27:15 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Mon, 15 Oct 2012 16:27:09 +0100
From: Keir Fraser 
To: Jan Beulich ,
	
Message-ID: 
Thread-Topic: [Xen-devel] Ping: [PATCH] VT-d: drop bogus checks
Thread-Index: Ac2q6YprPZR+vs/R2k24JsMmjudmNg==
In-Reply-To: <507C3D9C02000078000A1735@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel 
Subject: Re: [Xen-devel] Ping: [PATCH] VT-d: drop bogus checks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 15/10/2012 15:45, "Jan Beulich"  wrote:

> There were a number of cases where an "iommu" retrieved got passed to
> another function before being NULL-checked. While this by itself was
> not a problem as the called function did the checks, it is confusing to
> the reader and redundant in several cases (particularly with NULL-
> checking the return value of iommu_ir_ctrl()). Drop the redundant
> checks (also ones where the sole caller of a function did the checking
> already), and at once make the three similar functions proper inline
> instead of extern ones (they were prototyped in the wrong header file
> anyway, so would have needed touching sooner or later).
> 
> Signed-off-by: Jan Beulich 

Yes, I like this sort of cleanup.

Acked-by: Keir Fraser 

> --- a/xen/drivers/passthrough/vtd/intremap.c
> +++ b/xen/drivers/passthrough/vtd/intremap.c
> @@ -217,13 +217,6 @@ static int remap_entry_to_ioapic_rte(
>      unsigned long flags;
>      struct ir_ctrl *ir_ctrl = iommu_ir_ctrl(iommu);
>  
> -    if ( ir_ctrl == NULL )
> -    {
> -        dprintk(XENLOG_ERR VTDPREFIX,
> -                "remap_entry_to_ioapic_rte: ir_ctl is not ready\n");
> -        return -EFAULT;
> -    }
> -
>      if ( index < 0 || index > IREMAP_ENTRY_NR - 1 )
>      {
>          dprintk(XENLOG_ERR VTDPREFIX,
> @@ -358,8 +351,7 @@ unsigned int io_apic_read_remap_rte(
>      struct iommu *iommu = ioapic_to_iommu(IO_APIC_ID(apic));
>      struct ir_ctrl *ir_ctrl = iommu_ir_ctrl(iommu);
>  
> -    if ( !iommu || !ir_ctrl || ir_ctrl->iremap_maddr == 0 ||
> -        (ir_ctrl->iremap_num == 0) ||
> +    if ( !ir_ctrl || !ir_ctrl->iremap_maddr || !ir_ctrl->iremap_num ||
>          ( (index = apic_pin_2_ir_idx[apic][ioapic_pin]) < 0 ) )
>          return __io_apic_read(apic, reg);
>  
> @@ -385,7 +377,7 @@ void io_apic_write_remap_rte(
>      struct ir_ctrl *ir_ctrl = iommu_ir_ctrl(iommu);
>      int saved_mask;
>  
> -    if ( !iommu || !ir_ctrl || ir_ctrl->iremap_maddr == 0 )
> +    if ( !ir_ctrl || !ir_ctrl->iremap_maddr )
>      {
>          __io_apic_write(apic, reg, value);
>          return;
> @@ -475,13 +467,6 @@ static int remap_entry_to_msi_msg(
>      unsigned long flags;
>      struct ir_ctrl *ir_ctrl = iommu_ir_ctrl(iommu);
>  
> -    if ( ir_ctrl == NULL )
> -    {
> -        dprintk(XENLOG_ERR VTDPREFIX,
> -                "remap_entry_to_msi_msg: ir_ctl == NULL");
> -        return -EFAULT;
> -    }
> -
>      remap_rte = (struct msi_msg_remap_entry *) msg;
>      index = (remap_rte->address_lo.index_15 << 15) |
>               remap_rte->address_lo.index_0_14;
> @@ -644,7 +629,7 @@ void msi_msg_read_remap_rte(
>      iommu = drhd->iommu;
>  
>      ir_ctrl = iommu_ir_ctrl(iommu);
> -    if ( !iommu || !ir_ctrl || ir_ctrl->iremap_maddr == 0 )
> +    if ( !ir_ctrl || !ir_ctrl->iremap_maddr )
>          return;
>  
>      remap_entry_to_msi_msg(iommu, msg);
> @@ -663,7 +648,7 @@ void msi_msg_write_remap_rte(
>      iommu = drhd->iommu;
>  
>      ir_ctrl = iommu_ir_ctrl(iommu);
> -    if ( !iommu || !ir_ctrl || ir_ctrl->iremap_maddr == 0 )
> +    if ( !ir_ctrl || !ir_ctrl->iremap_maddr )
>          return;
>  
>      msi_msg_to_remap_entry(iommu, pdev, msi_desc, msg);
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -153,21 +153,6 @@ static void __init free_intel_iommu(stru
>      xfree(intel);
>  }
>  
> -struct qi_ctrl *iommu_qi_ctrl(struct iommu *iommu)
> -{
> -    return iommu ? &iommu->intel->qi_ctrl : NULL;
> -}
> -
> -struct ir_ctrl *iommu_ir_ctrl(struct iommu *iommu)
> -{
> -    return iommu ? &iommu->intel->ir_ctrl : NULL;
> -}
> -
> -struct iommu_flush *iommu_get_flush(struct iommu *iommu)
> -{
> -    return iommu ? &iommu->intel->flush : NULL;
> -}
> -
>  static int iommus_incoherent;
>  static void __iommu_flush_cache(void *addr, unsigned int size)
>  {
> --- a/xen/drivers/passthrough/vtd/iommu.h
> +++ b/xen/drivers/passthrough/vtd/iommu.h
> @@ -20,7 +20,7 @@
>  #ifndef _INTEL_IOMMU_H_
>  #define _INTEL_IOMMU_H_
>  
> -#include 
> +#include 
>  
>  /*
>   * Intel IOMMU register specification per version 1.0 public spec.
> @@ -510,6 +510,21 @@ struct intel_iommu {
>      struct acpi_drhd_unit *drhd;
>  };
>  
> +static inline struct qi_ctrl *iommu_qi_ctrl(struct iommu *iommu)
> +{
> +    return iommu ? &iommu->intel->qi_ctrl : NULL;
> +}
> +
> +static inline struct ir_ctrl *iommu_ir_ctrl(struct iommu *iommu)
> +{
> +    return iommu ? &iommu->intel->ir_ctrl : NULL;
> +}
> +
> +static inline struct iommu_flush *iommu_get_flush(struct iommu *iommu)
> +{
> +    return iommu ? &iommu->intel->flush : NULL;
> +}
> +
>  #define INTEL_IOMMU_DEBUG(fmt, args...) \
>      do  \
>      {   \
> --- a/xen/drivers/passthrough/vtd/utils.c
> +++ b/xen/drivers/passthrough/vtd/utils.c
> @@ -267,8 +267,7 @@ static void dump_iommu_info(unsigned cha
>          {
>              iommu = ioapic_to_iommu(mp_ioapics[apic].mpc_apicid);
>              ir_ctrl = iommu_ir_ctrl(iommu);
> -            if ( !iommu || !ir_ctrl || ir_ctrl->iremap_maddr == 0 ||
> -                ir_ctrl->iremap_num == 0 )
> +            if ( !ir_ctrl || !ir_ctrl->iremap_maddr || !ir_ctrl->iremap_num )
>                  continue;
>  
>              printk( "\nRedirection table of IOAPIC %x:\n", apic);
> --- a/xen/include/xen/iommu.h
> +++ b/xen/include/xen/iommu.h
> @@ -106,9 +106,6 @@ struct msi_desc;
>  struct msi_msg;
>  void msi_msg_read_remap_rte(struct msi_desc *msi_desc, struct msi_msg *msg);
>  void msi_msg_write_remap_rte(struct msi_desc *msi_desc, struct msi_msg *msg);
> -struct qi_ctrl *iommu_qi_ctrl(struct iommu *iommu);
> -struct ir_ctrl *iommu_ir_ctrl(struct iommu *iommu);
> -struct iommu_flush *iommu_get_flush(struct iommu *iommu);
>  void hvm_dpci_isairq_eoi(struct domain *d, unsigned int isairq);
>  struct hvm_irq_dpci *domain_get_irq_dpci(const struct domain *);
>  void free_hvm_irq_dpci(struct hvm_irq_dpci *dpci);
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 15:27:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 15:27:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNmZa-0006BA-Qz; Mon, 15 Oct 2012 15:27:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNmZZ-0006Am-LE
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 15:27:17 +0000
Received: from [85.158.137.99:33387] by server-7.bemta-3.messagelabs.com id
	EC/1E-06991-45B2C705; Mon, 15 Oct 2012 15:27:16 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1350314835!21691274!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16516 invoked from network); 15 Oct 2012 15:27:16 -0000
Received: from mail-ea0-f173.google.com (HELO mail-ea0-f173.google.com)
	(209.85.215.173)
	by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 15:27:16 -0000
Received: by mail-ea0-f173.google.com with SMTP id a1so1231942eaa.32
	for ; Mon, 15 Oct 2012 08:27:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=7LvrW8TCRlG8CyXUseLT96SAJmvDqfmtdXBcuLBslOU=;
	b=IhwdGGw+NYrjoqERejOIDZ6T4z5FffCuEpLwvmKH9ygYo7G/WWfyChu5SEc5N1u44s
	yrDu7YgeI6dV0n4LvONnIlw8T0NR/s7mWJqZZ8SWdhUWl4wqby+WGwOiXPf+qvgowQHF
	tie+ATcFyuZD7d4zOkDQ67Sai2TOaqRoVnInBfPnyAUWmXKlV6l3au47q9Jkd0x9MNXV
	ANsoZWuoP1dBp6Nf24CxN3bnO6UQngi04q0J2h+P1QdrpCTAKAG6Ru3AOhro/CuiTVMq
	TUOQd/uGnXADE2B0WK2UxdmgsPW9G3z1421+Laj3SmpkvoU4YE8eReeu3jQ2HJbz265O
	gzQw==
Received: by 10.14.214.2 with SMTP id b2mr7876409eep.32.1350314835617;
	Mon, 15 Oct 2012 08:27:15 -0700 (PDT)
Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com.
	[86.183.156.141])
	by mx.google.com with ESMTPS id d44sm25511657eeo.10.2012.10.15.08.27.14
	(version=SSLv3 cipher=OTHER); Mon, 15 Oct 2012 08:27:15 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Mon, 15 Oct 2012 16:27:09 +0100
From: Keir Fraser 
To: Jan Beulich ,
	
Message-ID: 
Thread-Topic: [Xen-devel] Ping: [PATCH] VT-d: drop bogus checks
Thread-Index: Ac2q6YprPZR+vs/R2k24JsMmjudmNg==
In-Reply-To: <507C3D9C02000078000A1735@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel 
Subject: Re: [Xen-devel] Ping: [PATCH] VT-d: drop bogus checks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 15/10/2012 15:45, "Jan Beulich"  wrote:

> There were a number of cases where an "iommu" retrieved got passed to
> another function before being NULL-checked. While this by itself was
> not a problem as the called function did the checks, it is confusing to
> the reader and redundant in several cases (particularly with NULL-
> checking the return value of iommu_ir_ctrl()). Drop the redundant
> checks (also ones where the sole caller of a function did the checking
> already), and at once make the three similar functions proper inline
> instead of extern ones (they were prototyped in the wrong header file
> anyway, so would have needed touching sooner or later).
> 
> Signed-off-by: Jan Beulich 

Yes, I like this sort of cleanup.

Acked-by: Keir Fraser 

> --- a/xen/drivers/passthrough/vtd/intremap.c
> +++ b/xen/drivers/passthrough/vtd/intremap.c
> @@ -217,13 +217,6 @@ static int remap_entry_to_ioapic_rte(
>      unsigned long flags;
>      struct ir_ctrl *ir_ctrl = iommu_ir_ctrl(iommu);
>  
> -    if ( ir_ctrl == NULL )
> -    {
> -        dprintk(XENLOG_ERR VTDPREFIX,
> -                "remap_entry_to_ioapic_rte: ir_ctl is not ready\n");
> -        return -EFAULT;
> -    }
> -
>      if ( index < 0 || index > IREMAP_ENTRY_NR - 1 )
>      {
>          dprintk(XENLOG_ERR VTDPREFIX,
> @@ -358,8 +351,7 @@ unsigned int io_apic_read_remap_rte(
>      struct iommu *iommu = ioapic_to_iommu(IO_APIC_ID(apic));
>      struct ir_ctrl *ir_ctrl = iommu_ir_ctrl(iommu);
>  
> -    if ( !iommu || !ir_ctrl || ir_ctrl->iremap_maddr == 0 ||
> -        (ir_ctrl->iremap_num == 0) ||
> +    if ( !ir_ctrl || !ir_ctrl->iremap_maddr || !ir_ctrl->iremap_num ||
>          ( (index = apic_pin_2_ir_idx[apic][ioapic_pin]) < 0 ) )
>          return __io_apic_read(apic, reg);
>  
> @@ -385,7 +377,7 @@ void io_apic_write_remap_rte(
>      struct ir_ctrl *ir_ctrl = iommu_ir_ctrl(iommu);
>      int saved_mask;
>  
> -    if ( !iommu || !ir_ctrl || ir_ctrl->iremap_maddr == 0 )
> +    if ( !ir_ctrl || !ir_ctrl->iremap_maddr )
>      {
>          __io_apic_write(apic, reg, value);
>          return;
> @@ -475,13 +467,6 @@ static int remap_entry_to_msi_msg(
>      unsigned long flags;
>      struct ir_ctrl *ir_ctrl = iommu_ir_ctrl(iommu);
>  
> -    if ( ir_ctrl == NULL )
> -    {
> -        dprintk(XENLOG_ERR VTDPREFIX,
> -                "remap_entry_to_msi_msg: ir_ctl == NULL");
> -        return -EFAULT;
> -    }
> -
>      remap_rte = (struct msi_msg_remap_entry *) msg;
>      index = (remap_rte->address_lo.index_15 << 15) |
>               remap_rte->address_lo.index_0_14;
> @@ -644,7 +629,7 @@ void msi_msg_read_remap_rte(
>      iommu = drhd->iommu;
>  
>      ir_ctrl = iommu_ir_ctrl(iommu);
> -    if ( !iommu || !ir_ctrl || ir_ctrl->iremap_maddr == 0 )
> +    if ( !ir_ctrl || !ir_ctrl->iremap_maddr )
>          return;
>  
>      remap_entry_to_msi_msg(iommu, msg);
> @@ -663,7 +648,7 @@ void msi_msg_write_remap_rte(
>      iommu = drhd->iommu;
>  
>      ir_ctrl = iommu_ir_ctrl(iommu);
> -    if ( !iommu || !ir_ctrl || ir_ctrl->iremap_maddr == 0 )
> +    if ( !ir_ctrl || !ir_ctrl->iremap_maddr )
>          return;
>  
>      msi_msg_to_remap_entry(iommu, pdev, msi_desc, msg);
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -153,21 +153,6 @@ static void __init free_intel_iommu(stru
>      xfree(intel);
>  }
>  
> -struct qi_ctrl *iommu_qi_ctrl(struct iommu *iommu)
> -{
> -    return iommu ? &iommu->intel->qi_ctrl : NULL;
> -}
> -
> -struct ir_ctrl *iommu_ir_ctrl(struct iommu *iommu)
> -{
> -    return iommu ? &iommu->intel->ir_ctrl : NULL;
> -}
> -
> -struct iommu_flush *iommu_get_flush(struct iommu *iommu)
> -{
> -    return iommu ? &iommu->intel->flush : NULL;
> -}
> -
>  static int iommus_incoherent;
>  static void __iommu_flush_cache(void *addr, unsigned int size)
>  {
> --- a/xen/drivers/passthrough/vtd/iommu.h
> +++ b/xen/drivers/passthrough/vtd/iommu.h
> @@ -20,7 +20,7 @@
>  #ifndef _INTEL_IOMMU_H_
>  #define _INTEL_IOMMU_H_
>  
> -#include 
> +#include 
>  
>  /*
>   * Intel IOMMU register specification per version 1.0 public spec.
> @@ -510,6 +510,21 @@ struct intel_iommu {
>      struct acpi_drhd_unit *drhd;
>  };
>  
> +static inline struct qi_ctrl *iommu_qi_ctrl(struct iommu *iommu)
> +{
> +    return iommu ? &iommu->intel->qi_ctrl : NULL;
> +}
> +
> +static inline struct ir_ctrl *iommu_ir_ctrl(struct iommu *iommu)
> +{
> +    return iommu ? &iommu->intel->ir_ctrl : NULL;
> +}
> +
> +static inline struct iommu_flush *iommu_get_flush(struct iommu *iommu)
> +{
> +    return iommu ? &iommu->intel->flush : NULL;
> +}
> +
>  #define INTEL_IOMMU_DEBUG(fmt, args...) \
>      do  \
>      {   \
> --- a/xen/drivers/passthrough/vtd/utils.c
> +++ b/xen/drivers/passthrough/vtd/utils.c
> @@ -267,8 +267,7 @@ static void dump_iommu_info(unsigned cha
>          {
>              iommu = ioapic_to_iommu(mp_ioapics[apic].mpc_apicid);
>              ir_ctrl = iommu_ir_ctrl(iommu);
> -            if ( !iommu || !ir_ctrl || ir_ctrl->iremap_maddr == 0 ||
> -                ir_ctrl->iremap_num == 0 )
> +            if ( !ir_ctrl || !ir_ctrl->iremap_maddr || !ir_ctrl->iremap_num )
>                  continue;
>  
>              printk( "\nRedirection table of IOAPIC %x:\n", apic);
> --- a/xen/include/xen/iommu.h
> +++ b/xen/include/xen/iommu.h
> @@ -106,9 +106,6 @@ struct msi_desc;
>  struct msi_msg;
>  void msi_msg_read_remap_rte(struct msi_desc *msi_desc, struct msi_msg *msg);
>  void msi_msg_write_remap_rte(struct msi_desc *msi_desc, struct msi_msg *msg);
> -struct qi_ctrl *iommu_qi_ctrl(struct iommu *iommu);
> -struct ir_ctrl *iommu_ir_ctrl(struct iommu *iommu);
> -struct iommu_flush *iommu_get_flush(struct iommu *iommu);
>  void hvm_dpci_isairq_eoi(struct domain *d, unsigned int isairq);
>  struct hvm_irq_dpci *domain_get_irq_dpci(const struct domain *);
>  void free_hvm_irq_dpci(struct hvm_irq_dpci *dpci);
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 15:28:01 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 15:28:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNma9-0006HE-8O; Mon, 15 Oct 2012 15:27:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNma7-0006Gw-G1
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 15:27:51 +0000
Received: from [85.158.137.99:45235] by server-15.bemta-3.messagelabs.com id
	8C/87-10261-67B2C705; Mon, 15 Oct 2012 15:27:50 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1350314869!21545053!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25539 invoked from network); 15 Oct 2012 15:27:49 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 15:27:49 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so3211144eek.32
	for ; Mon, 15 Oct 2012 08:27:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=DDH/zbuEBG7gTRUkSyTMLKwZjbJFJHiNZecsM1bRI8c=;
	b=AYfQP2LdQ7cPQjspWVHQXlCkRdmbremOXH6Gbut65oLTW2evGIfk/a4E9erant1GH2
	JEfW/qu9NxUTVPjapqtHJybkdPSUoGyJQFo42/dryQdV8r5bfjHCwwxcT5TCH6EdM9N7
	gfX1H+fLobVNKZA7gdMRk1SGmGFE19uviS+9WnWUYjkcAxVolltq7aLZ/pS2ZtxdqIcQ
	p3FpbClxUbPq2PytNYWD3QRgAm7hCOjEZoMkvvg0HzcVnCONrGm1ZRc2zbzcLUPWj79I
	tqawO37wi+yuAxD0ynJSO/8B2dO/sv/fx8NZL020ccb341r/CrVdpuE8FxNlVEIu5bJM
	K8Fw==
Received: by 10.14.194.2 with SMTP id l2mr16319486een.12.1350314869416;
	Mon, 15 Oct 2012 08:27:49 -0700 (PDT)
Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com.
	[86.183.156.141])
	by mx.google.com with ESMTPS id e7sm25509592eep.2.2012.10.15.08.27.47
	(version=SSLv3 cipher=OTHER); Mon, 15 Oct 2012 08:27:48 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Mon, 15 Oct 2012 16:27:39 +0100
From: Keir Fraser 
To: Jan Beulich ,
	
Message-ID: 
Thread-Topic: [Xen-devel] Ping: [PATCH] IOMMU: remove vendor specific bits
	from generic code
Thread-Index: Ac2q6ZxM1dkdCNwSaEKN4h6Xxt8FgQ==
In-Reply-To: <507C3DC502000078000A1739@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel 
Subject: Re: [Xen-devel] Ping: [PATCH] IOMMU: remove vendor specific bits
 from generic code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 15/10/2012 15:45, "Jan Beulich"  wrote:

> - names of functions used independent of vendor should not have vendor
>   specific names
> - vendor specific declarations should not live inn generic headers
> - other vendor specific items should not be used in generic code
> 
> Signed-off-by: Jan Beulich 

Acked-by: Keir Fraser 

> --
> Note that this will only apply cleanly on top of "VT-d: drop bogus
> checks", sent out a few minutes ago.
> 
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -776,7 +776,7 @@ long arch_do_domctl(
>          if ( iommu_enabled )
>          {
>              spin_lock(&pcidevs_lock);
> -            ret = pt_irq_create_bind_vtd(d, bind);
> +            ret = pt_irq_create_bind(d, bind);
>              spin_unlock(&pcidevs_lock);
>          }
>          if ( ret < 0 )
> @@ -806,7 +806,7 @@ long arch_do_domctl(
>          if ( iommu_enabled )
>          {
>              spin_lock(&pcidevs_lock);
> -            ret = pt_irq_destroy_bind_vtd(d, bind);
> +            ret = pt_irq_destroy_bind(d, bind);
>              spin_unlock(&pcidevs_lock);
>          }
>          if ( ret < 0 )
> --- a/xen/drivers/passthrough/io.c
> +++ b/xen/drivers/passthrough/io.c
> @@ -95,7 +95,7 @@ void free_hvm_irq_dpci(struct hvm_irq_dp
>      xfree(dpci);
>  }
>  
> -int pt_irq_create_bind_vtd(
> +int pt_irq_create_bind(
>      struct domain *d, xen_domctl_bind_pt_irq_t *pt_irq_bind)
>  {
>      struct hvm_irq_dpci *hvm_irq_dpci = NULL;
> @@ -277,14 +277,14 @@ int pt_irq_create_bind_vtd(
>          spin_unlock(&d->event_lock);
>  
>          if ( iommu_verbose )
> -            dprintk(VTDPREFIX,
> +            dprintk(XENLOG_G_INFO,
>                      "d%d: bind: m_gsi=%u g_gsi=%u device=%u intx=%u\n",
>                      d->domain_id, pirq, guest_gsi, device, intx);
>      }
>      return 0;
>  }
>  
> -int pt_irq_destroy_bind_vtd(
> +int pt_irq_destroy_bind(
>      struct domain *d, xen_domctl_bind_pt_irq_t *pt_irq_bind)
>  {
>      struct hvm_irq_dpci *hvm_irq_dpci = NULL;
> @@ -302,7 +302,7 @@ int pt_irq_destroy_bind_vtd(
>      link = hvm_pci_intx_link(device, intx);
>  
>      if ( iommu_verbose )
> -        dprintk(VTDPREFIX,
> +        dprintk(XENLOG_G_INFO,
>                  "d%d: unbind: m_gsi=%u g_gsi=%u device=%u intx=%u\n",
>                  d->domain_id, machine_gsi, guest_gsi, device, intx);
>  
> @@ -360,7 +360,7 @@ int pt_irq_destroy_bind_vtd(
>      spin_unlock(&d->event_lock);
>  
>      if ( iommu_verbose )
> -        dprintk(VTDPREFIX,
> +        dprintk(XENLOG_G_INFO,
>                  "d%d unmap: m_irq=%u device=%u intx=%u\n",
>                  d->domain_id, machine_gsi, device, intx);
>  
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -364,7 +364,7 @@ int deassign_device(struct domain *d, u1
>  
>      if ( pdev->domain != d )
>      {
> -        dprintk(XENLOG_ERR VTDPREFIX,
> +        dprintk(XENLOG_G_ERR,
>                  "d%d: deassign a device not owned\n", d->domain_id);
>          return -EINVAL;
>      }
> @@ -372,8 +372,8 @@ int deassign_device(struct domain *d, u1
>      ret = hd->platform_ops->reassign_device(d, dom0, seg, bus, devfn);
>      if ( ret )
>      {
> -        dprintk(XENLOG_ERR VTDPREFIX,
> -                "d%d: Deassign device (%04x:%02x:%02x.%u) failed!\n",
> +        dprintk(XENLOG_G_ERR,
> +                "d%d: deassign device (%04x:%02x:%02x.%u) failed\n",
>                  d->domain_id, seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));
>          return ret;
>      }
> --- a/xen/drivers/passthrough/vtd/extern.h
> +++ b/xen/drivers/passthrough/vtd/extern.h
> @@ -24,6 +24,8 @@
>  #include "dmar.h"
>  #include 
>  
> +#define VTDPREFIX "[VT-D]"
> +
>  extern bool_t rwbf_quirk;
>  
>  void print_iommu_regs(struct acpi_drhd_unit *drhd);
> @@ -79,6 +81,15 @@ int domain_context_mapping_one(struct do
>  int domain_context_unmap_one(struct domain *domain, struct iommu *iommu,
>                               u8 bus, u8 devfn);
>  
> +unsigned int io_apic_read_remap_rte(unsigned int apic, unsigned int reg);
> +void io_apic_write_remap_rte(unsigned int apic,
> +                             unsigned int reg, unsigned int value);
> +
> +struct msi_desc;
> +struct msi_msg;
> +void msi_msg_read_remap_rte(struct msi_desc *, struct msi_msg *);
> +void msi_msg_write_remap_rte(struct msi_desc *, struct msi_msg *);
> +
>  int is_igd_vt_enabled_quirk(void);
>  void platform_quirks_init(void);
>  void vtd_ops_preamble_quirk(struct iommu* iommu);
> --- a/xen/drivers/passthrough/vtd/iommu.h
> +++ b/xen/drivers/passthrough/vtd/iommu.h
> @@ -510,6 +510,22 @@ struct intel_iommu {
>      struct acpi_drhd_unit *drhd;
>  };
>  
> +struct iommu {
> +    struct list_head list;
> +    void __iomem *reg; /* Pointer to hardware regs, virtual addr */
> +    u32 index;         /* Sequence number of iommu */
> +    u32 nr_pt_levels;
> +    u64 cap;
> +    u64 ecap;
> +    spinlock_t lock; /* protect context, domain ids */
> +    spinlock_t register_lock; /* protect iommu register handling */
> +    u64 root_maddr; /* root entry machine address */
> +    int irq;
> +    struct intel_iommu *intel;
> +    unsigned long *domid_bitmap;  /* domain id bitmap */
> +    u16 *domid_map;               /* domain id mapping array */
> +};
> +
>  static inline struct qi_ctrl *iommu_qi_ctrl(struct iommu *iommu)
>  {
>      return iommu ? &iommu->intel->qi_ctrl : NULL;
> --- a/xen/include/xen/iommu.h
> +++ b/xen/include/xen/iommu.h
> @@ -48,22 +48,6 @@ extern struct rangeset *mmio_ro_ranges;
>  #define PAGE_MASK_4K        (((u64)-1) << PAGE_SHIFT_4K)
>  #define PAGE_ALIGN_4K(addr) (((addr) + PAGE_SIZE_4K - 1) & PAGE_MASK_4K)
>  
> -struct iommu {
> -    struct list_head list;
> -    void __iomem *reg; /* Pointer to hardware regs, virtual addr */
> -    u32 index;         /* Sequence number of iommu */
> -    u32 nr_pt_levels;
> -    u64 cap;
> -    u64 ecap;
> -    spinlock_t lock; /* protect context, domain ids */
> -    spinlock_t register_lock; /* protect iommu register handling */
> -    u64 root_maddr; /* root entry machine address */
> -    int irq;
> -    struct intel_iommu *intel;
> -    unsigned long *domid_bitmap;  /* domain id bitmap */
> -    u16 *domid_map;               /* domain id mapping array */
> -};
> -
>  int iommu_setup(void);
>  int iommu_supports_eim(void);
>  int iommu_enable_x2apic_IR(void);
> @@ -94,25 +78,18 @@ void pt_pci_init(void);
>  struct pirq;
>  int hvm_do_IRQ_dpci(struct domain *, struct pirq *);
>  int dpci_ioport_intercept(ioreq_t *p);
> -int pt_irq_create_bind_vtd(struct domain *d,
> -                           xen_domctl_bind_pt_irq_t *pt_irq_bind);
> -int pt_irq_destroy_bind_vtd(struct domain *d,
> -                            xen_domctl_bind_pt_irq_t *pt_irq_bind);
> -unsigned int io_apic_read_remap_rte(unsigned int apic, unsigned int reg);
> -void io_apic_write_remap_rte(unsigned int apic,
> -                             unsigned int reg, unsigned int value);
> +int pt_irq_create_bind(struct domain *, xen_domctl_bind_pt_irq_t *);
> +int pt_irq_destroy_bind(struct domain *, xen_domctl_bind_pt_irq_t *);
>  
> -struct msi_desc;
> -struct msi_msg;
> -void msi_msg_read_remap_rte(struct msi_desc *msi_desc, struct msi_msg *msg);
> -void msi_msg_write_remap_rte(struct msi_desc *msi_desc, struct msi_msg *msg);
>  void hvm_dpci_isairq_eoi(struct domain *d, unsigned int isairq);
>  struct hvm_irq_dpci *domain_get_irq_dpci(const struct domain *);
>  void free_hvm_irq_dpci(struct hvm_irq_dpci *dpci);
>  bool_t pt_irq_need_timer(uint32_t flags);
>  
>  #define PT_IRQ_TIME_OUT MILLISECS(8)
> -#define VTDPREFIX "[VT-D]"
> +
> +struct msi_desc;
> +struct msi_msg;
>  
>  struct iommu_ops {
>      int (*init)(struct domain *d);
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 15:28:01 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 15:28:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNma9-0006HE-8O; Mon, 15 Oct 2012 15:27:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNma7-0006Gw-G1
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 15:27:51 +0000
Received: from [85.158.137.99:45235] by server-15.bemta-3.messagelabs.com id
	8C/87-10261-67B2C705; Mon, 15 Oct 2012 15:27:50 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1350314869!21545053!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25539 invoked from network); 15 Oct 2012 15:27:49 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 15:27:49 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so3211144eek.32
	for ; Mon, 15 Oct 2012 08:27:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=DDH/zbuEBG7gTRUkSyTMLKwZjbJFJHiNZecsM1bRI8c=;
	b=AYfQP2LdQ7cPQjspWVHQXlCkRdmbremOXH6Gbut65oLTW2evGIfk/a4E9erant1GH2
	JEfW/qu9NxUTVPjapqtHJybkdPSUoGyJQFo42/dryQdV8r5bfjHCwwxcT5TCH6EdM9N7
	gfX1H+fLobVNKZA7gdMRk1SGmGFE19uviS+9WnWUYjkcAxVolltq7aLZ/pS2ZtxdqIcQ
	p3FpbClxUbPq2PytNYWD3QRgAm7hCOjEZoMkvvg0HzcVnCONrGm1ZRc2zbzcLUPWj79I
	tqawO37wi+yuAxD0ynJSO/8B2dO/sv/fx8NZL020ccb341r/CrVdpuE8FxNlVEIu5bJM
	K8Fw==
Received: by 10.14.194.2 with SMTP id l2mr16319486een.12.1350314869416;
	Mon, 15 Oct 2012 08:27:49 -0700 (PDT)
Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com.
	[86.183.156.141])
	by mx.google.com with ESMTPS id e7sm25509592eep.2.2012.10.15.08.27.47
	(version=SSLv3 cipher=OTHER); Mon, 15 Oct 2012 08:27:48 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Mon, 15 Oct 2012 16:27:39 +0100
From: Keir Fraser 
To: Jan Beulich ,
	
Message-ID: 
Thread-Topic: [Xen-devel] Ping: [PATCH] IOMMU: remove vendor specific bits
	from generic code
Thread-Index: Ac2q6ZxM1dkdCNwSaEKN4h6Xxt8FgQ==
In-Reply-To: <507C3DC502000078000A1739@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel 
Subject: Re: [Xen-devel] Ping: [PATCH] IOMMU: remove vendor specific bits
 from generic code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 15/10/2012 15:45, "Jan Beulich"  wrote:

> - names of functions used independent of vendor should not have vendor
>   specific names
> - vendor specific declarations should not live inn generic headers
> - other vendor specific items should not be used in generic code
> 
> Signed-off-by: Jan Beulich 

Acked-by: Keir Fraser 

> --
> Note that this will only apply cleanly on top of "VT-d: drop bogus
> checks", sent out a few minutes ago.
> 
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -776,7 +776,7 @@ long arch_do_domctl(
>          if ( iommu_enabled )
>          {
>              spin_lock(&pcidevs_lock);
> -            ret = pt_irq_create_bind_vtd(d, bind);
> +            ret = pt_irq_create_bind(d, bind);
>              spin_unlock(&pcidevs_lock);
>          }
>          if ( ret < 0 )
> @@ -806,7 +806,7 @@ long arch_do_domctl(
>          if ( iommu_enabled )
>          {
>              spin_lock(&pcidevs_lock);
> -            ret = pt_irq_destroy_bind_vtd(d, bind);
> +            ret = pt_irq_destroy_bind(d, bind);
>              spin_unlock(&pcidevs_lock);
>          }
>          if ( ret < 0 )
> --- a/xen/drivers/passthrough/io.c
> +++ b/xen/drivers/passthrough/io.c
> @@ -95,7 +95,7 @@ void free_hvm_irq_dpci(struct hvm_irq_dp
>      xfree(dpci);
>  }
>  
> -int pt_irq_create_bind_vtd(
> +int pt_irq_create_bind(
>      struct domain *d, xen_domctl_bind_pt_irq_t *pt_irq_bind)
>  {
>      struct hvm_irq_dpci *hvm_irq_dpci = NULL;
> @@ -277,14 +277,14 @@ int pt_irq_create_bind_vtd(
>          spin_unlock(&d->event_lock);
>  
>          if ( iommu_verbose )
> -            dprintk(VTDPREFIX,
> +            dprintk(XENLOG_G_INFO,
>                      "d%d: bind: m_gsi=%u g_gsi=%u device=%u intx=%u\n",
>                      d->domain_id, pirq, guest_gsi, device, intx);
>      }
>      return 0;
>  }
>  
> -int pt_irq_destroy_bind_vtd(
> +int pt_irq_destroy_bind(
>      struct domain *d, xen_domctl_bind_pt_irq_t *pt_irq_bind)
>  {
>      struct hvm_irq_dpci *hvm_irq_dpci = NULL;
> @@ -302,7 +302,7 @@ int pt_irq_destroy_bind_vtd(
>      link = hvm_pci_intx_link(device, intx);
>  
>      if ( iommu_verbose )
> -        dprintk(VTDPREFIX,
> +        dprintk(XENLOG_G_INFO,
>                  "d%d: unbind: m_gsi=%u g_gsi=%u device=%u intx=%u\n",
>                  d->domain_id, machine_gsi, guest_gsi, device, intx);
>  
> @@ -360,7 +360,7 @@ int pt_irq_destroy_bind_vtd(
>      spin_unlock(&d->event_lock);
>  
>      if ( iommu_verbose )
> -        dprintk(VTDPREFIX,
> +        dprintk(XENLOG_G_INFO,
>                  "d%d unmap: m_irq=%u device=%u intx=%u\n",
>                  d->domain_id, machine_gsi, device, intx);
>  
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -364,7 +364,7 @@ int deassign_device(struct domain *d, u1
>  
>      if ( pdev->domain != d )
>      {
> -        dprintk(XENLOG_ERR VTDPREFIX,
> +        dprintk(XENLOG_G_ERR,
>                  "d%d: deassign a device not owned\n", d->domain_id);
>          return -EINVAL;
>      }
> @@ -372,8 +372,8 @@ int deassign_device(struct domain *d, u1
>      ret = hd->platform_ops->reassign_device(d, dom0, seg, bus, devfn);
>      if ( ret )
>      {
> -        dprintk(XENLOG_ERR VTDPREFIX,
> -                "d%d: Deassign device (%04x:%02x:%02x.%u) failed!\n",
> +        dprintk(XENLOG_G_ERR,
> +                "d%d: deassign device (%04x:%02x:%02x.%u) failed\n",
>                  d->domain_id, seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));
>          return ret;
>      }
> --- a/xen/drivers/passthrough/vtd/extern.h
> +++ b/xen/drivers/passthrough/vtd/extern.h
> @@ -24,6 +24,8 @@
>  #include "dmar.h"
>  #include 
>  
> +#define VTDPREFIX "[VT-D]"
> +
>  extern bool_t rwbf_quirk;
>  
>  void print_iommu_regs(struct acpi_drhd_unit *drhd);
> @@ -79,6 +81,15 @@ int domain_context_mapping_one(struct do
>  int domain_context_unmap_one(struct domain *domain, struct iommu *iommu,
>                               u8 bus, u8 devfn);
>  
> +unsigned int io_apic_read_remap_rte(unsigned int apic, unsigned int reg);
> +void io_apic_write_remap_rte(unsigned int apic,
> +                             unsigned int reg, unsigned int value);
> +
> +struct msi_desc;
> +struct msi_msg;
> +void msi_msg_read_remap_rte(struct msi_desc *, struct msi_msg *);
> +void msi_msg_write_remap_rte(struct msi_desc *, struct msi_msg *);
> +
>  int is_igd_vt_enabled_quirk(void);
>  void platform_quirks_init(void);
>  void vtd_ops_preamble_quirk(struct iommu* iommu);
> --- a/xen/drivers/passthrough/vtd/iommu.h
> +++ b/xen/drivers/passthrough/vtd/iommu.h
> @@ -510,6 +510,22 @@ struct intel_iommu {
>      struct acpi_drhd_unit *drhd;
>  };
>  
> +struct iommu {
> +    struct list_head list;
> +    void __iomem *reg; /* Pointer to hardware regs, virtual addr */
> +    u32 index;         /* Sequence number of iommu */
> +    u32 nr_pt_levels;
> +    u64 cap;
> +    u64 ecap;
> +    spinlock_t lock; /* protect context, domain ids */
> +    spinlock_t register_lock; /* protect iommu register handling */
> +    u64 root_maddr; /* root entry machine address */
> +    int irq;
> +    struct intel_iommu *intel;
> +    unsigned long *domid_bitmap;  /* domain id bitmap */
> +    u16 *domid_map;               /* domain id mapping array */
> +};
> +
>  static inline struct qi_ctrl *iommu_qi_ctrl(struct iommu *iommu)
>  {
>      return iommu ? &iommu->intel->qi_ctrl : NULL;
> --- a/xen/include/xen/iommu.h
> +++ b/xen/include/xen/iommu.h
> @@ -48,22 +48,6 @@ extern struct rangeset *mmio_ro_ranges;
>  #define PAGE_MASK_4K        (((u64)-1) << PAGE_SHIFT_4K)
>  #define PAGE_ALIGN_4K(addr) (((addr) + PAGE_SIZE_4K - 1) & PAGE_MASK_4K)
>  
> -struct iommu {
> -    struct list_head list;
> -    void __iomem *reg; /* Pointer to hardware regs, virtual addr */
> -    u32 index;         /* Sequence number of iommu */
> -    u32 nr_pt_levels;
> -    u64 cap;
> -    u64 ecap;
> -    spinlock_t lock; /* protect context, domain ids */
> -    spinlock_t register_lock; /* protect iommu register handling */
> -    u64 root_maddr; /* root entry machine address */
> -    int irq;
> -    struct intel_iommu *intel;
> -    unsigned long *domid_bitmap;  /* domain id bitmap */
> -    u16 *domid_map;               /* domain id mapping array */
> -};
> -
>  int iommu_setup(void);
>  int iommu_supports_eim(void);
>  int iommu_enable_x2apic_IR(void);
> @@ -94,25 +78,18 @@ void pt_pci_init(void);
>  struct pirq;
>  int hvm_do_IRQ_dpci(struct domain *, struct pirq *);
>  int dpci_ioport_intercept(ioreq_t *p);
> -int pt_irq_create_bind_vtd(struct domain *d,
> -                           xen_domctl_bind_pt_irq_t *pt_irq_bind);
> -int pt_irq_destroy_bind_vtd(struct domain *d,
> -                            xen_domctl_bind_pt_irq_t *pt_irq_bind);
> -unsigned int io_apic_read_remap_rte(unsigned int apic, unsigned int reg);
> -void io_apic_write_remap_rte(unsigned int apic,
> -                             unsigned int reg, unsigned int value);
> +int pt_irq_create_bind(struct domain *, xen_domctl_bind_pt_irq_t *);
> +int pt_irq_destroy_bind(struct domain *, xen_domctl_bind_pt_irq_t *);
>  
> -struct msi_desc;
> -struct msi_msg;
> -void msi_msg_read_remap_rte(struct msi_desc *msi_desc, struct msi_msg *msg);
> -void msi_msg_write_remap_rte(struct msi_desc *msi_desc, struct msi_msg *msg);
>  void hvm_dpci_isairq_eoi(struct domain *d, unsigned int isairq);
>  struct hvm_irq_dpci *domain_get_irq_dpci(const struct domain *);
>  void free_hvm_irq_dpci(struct hvm_irq_dpci *dpci);
>  bool_t pt_irq_need_timer(uint32_t flags);
>  
>  #define PT_IRQ_TIME_OUT MILLISECS(8)
> -#define VTDPREFIX "[VT-D]"
> +
> +struct msi_desc;
> +struct msi_msg;
>  
>  struct iommu_ops {
>      int (*init)(struct domain *d);
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 15:32:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 15:32:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNme0-00078B-OG; Mon, 15 Oct 2012 15:31:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNmdz-00077A-A8
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 15:31:51 +0000
Received: from [85.158.138.51:25213] by server-3.bemta-3.messagelabs.com id
	0B/36-09368-66C2C705; Mon, 15 Oct 2012 15:31:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1350315109!33940394!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32290 invoked from network); 15 Oct 2012 15:31:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 15:31:50 -0000
X-IronPort-AV: E=Sophos;i="4.80,588,1344211200"; d="scan'208";a="15175253"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 15:31:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 16:31:49 +0100
Message-ID: <1350315108.18058.73.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Andrew Cooper 
Date: Mon, 15 Oct 2012 16:31:48 +0100
In-Reply-To: <952b1ef292469c9a9af5.1350314699@andrewcoop.uk.xensource.com>
References: <952b1ef292469c9a9af5.1350314699@andrewcoop.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] build/xenstore: Correct static link failure
	for xenstore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-10-15 at 16:24 +0100, Andrew Cooper wrote:
> There is support for building xenstore clients statically.  However,
> recent changes to the makefiles have rendered the static build broken.
> 
> tools/xenstore/Makefile sets LIBXENSTORE depending on whether
> XENSTORE_STATIC_CLIENTS is specified, but will unconditionally try to
> link against libxenstore.so by use of the LDLIBS_libxenstore variable.
> 
> This patch doubles the logic already present to select the appropriate
> library target.
> 
> Signed-off-by: Andrew Cooper 
> 
> --
> This is a bit of a hack, but seems to be the only reliable way,
> espcially when linking with the LDLIBS_libxenstore variable in
> toos/misc.

I think it would be cleaner to define LDLIBS_libxenstore_static in
Rules.mk alongside the existing thing and make the appropriate selection
in the xenstore Makefile. That keeps the fugliness next to where it is
used.

> 
> diff -r 099589002239 -r 952b1ef29246 tools/Rules.mk
> --- a/tools/Rules.mk
> +++ b/tools/Rules.mk
> @@ -28,7 +28,11 @@ LDLIBS_libxenguest = $(XEN_LIBXC)/libxen
>  SHLIB_libxenguest  = -Wl,-rpath-link=L$(XEN_LIBXC)
>  
>  CFLAGS_libxenstore = -I$(XEN_XENSTORE) $(CFLAGS_xeninclude)
> +ifneq ($(XENSTORE_STATIC_CLIENTS),y)
>  LDLIBS_libxenstore = $(XEN_XENSTORE)/libxenstore.so
> +else
> +LDLIBS_libxenstore = $(XEN_XENSTORE)/libxenstore.a
> +endif
>  SHLIB_libxenstore  = -Wl,-rpath-link=$(XEN_XENSTORE)
>  
>  CFLAGS_libxenstat  = -I$(XEN_LIBXENSTAT)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 15:32:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 15:32:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNme0-00078B-OG; Mon, 15 Oct 2012 15:31:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNmdz-00077A-A8
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 15:31:51 +0000
Received: from [85.158.138.51:25213] by server-3.bemta-3.messagelabs.com id
	0B/36-09368-66C2C705; Mon, 15 Oct 2012 15:31:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1350315109!33940394!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32290 invoked from network); 15 Oct 2012 15:31:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 15:31:50 -0000
X-IronPort-AV: E=Sophos;i="4.80,588,1344211200"; d="scan'208";a="15175253"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 15:31:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 16:31:49 +0100
Message-ID: <1350315108.18058.73.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Andrew Cooper 
Date: Mon, 15 Oct 2012 16:31:48 +0100
In-Reply-To: <952b1ef292469c9a9af5.1350314699@andrewcoop.uk.xensource.com>
References: <952b1ef292469c9a9af5.1350314699@andrewcoop.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] build/xenstore: Correct static link failure
	for xenstore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-10-15 at 16:24 +0100, Andrew Cooper wrote:
> There is support for building xenstore clients statically.  However,
> recent changes to the makefiles have rendered the static build broken.
> 
> tools/xenstore/Makefile sets LIBXENSTORE depending on whether
> XENSTORE_STATIC_CLIENTS is specified, but will unconditionally try to
> link against libxenstore.so by use of the LDLIBS_libxenstore variable.
> 
> This patch doubles the logic already present to select the appropriate
> library target.
> 
> Signed-off-by: Andrew Cooper 
> 
> --
> This is a bit of a hack, but seems to be the only reliable way,
> espcially when linking with the LDLIBS_libxenstore variable in
> toos/misc.

I think it would be cleaner to define LDLIBS_libxenstore_static in
Rules.mk alongside the existing thing and make the appropriate selection
in the xenstore Makefile. That keeps the fugliness next to where it is
used.

> 
> diff -r 099589002239 -r 952b1ef29246 tools/Rules.mk
> --- a/tools/Rules.mk
> +++ b/tools/Rules.mk
> @@ -28,7 +28,11 @@ LDLIBS_libxenguest = $(XEN_LIBXC)/libxen
>  SHLIB_libxenguest  = -Wl,-rpath-link=L$(XEN_LIBXC)
>  
>  CFLAGS_libxenstore = -I$(XEN_XENSTORE) $(CFLAGS_xeninclude)
> +ifneq ($(XENSTORE_STATIC_CLIENTS),y)
>  LDLIBS_libxenstore = $(XEN_XENSTORE)/libxenstore.so
> +else
> +LDLIBS_libxenstore = $(XEN_XENSTORE)/libxenstore.a
> +endif
>  SHLIB_libxenstore  = -Wl,-rpath-link=$(XEN_XENSTORE)
>  
>  CFLAGS_libxenstat  = -I$(XEN_LIBXENSTAT)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 15:32:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 15:32:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNmeK-0007FL-5v; Mon, 15 Oct 2012 15:32:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from ) id 1TNmeI-0007Ci-RQ
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 15:32:11 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-27.messagelabs.com!1350315123!8641332!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30061 invoked from network); 15 Oct 2012 15:32:04 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-5.tower-27.messagelabs.com with SMTP;
	15 Oct 2012 15:32:04 -0000
X-TM-IMSS-Message-ID: 
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1;
	TLSv1/SSLv3 DHE-RSA-AES256-SHA (256/256)) id e3b8b6e00003d2d2 ;
	Mon, 15 Oct 2012 11:31:43 -0400
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q9FFVxlI000826; 
	Mon, 15 Oct 2012 11:32:00 -0400
Message-ID: <507C2C6F.2060507@tycho.nsa.gov>
Date: Mon, 15 Oct 2012 11:31:59 -0400
From: Daniel De Graaf 
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121009 Thunderbird/16.0
MIME-Version: 1.0
To: Keir Fraser 
References: 
In-Reply-To: 
Cc: Ian.Campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen: Add versions of rcu_lock_*_domain
	without IS_PRIV
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/15/2012 11:26 AM, Keir Fraser wrote:
> Must we have two new calls for translating a domid to a domain? It's getting
> to be a confusing mess isn't it? Also, here, a more consistent name for
> rcu_lock_domain_by_any_id would be rcu_lock_any_domain_by_id, I think?
> 
>  -- Keir

The original version of this patch queue removed the two _target_ calls;
that removal is not in the current versions to avoid breaking code that is
not yet converted (ARM and two other callers not converted).

The name rcu_lock_any_domain_by_id is also fine, although it seems to imply
that rcu_lock_domain_by_id cannot lock any domain, when the real difference
is if they accept DOMID_SELF (hence why I chose to say any_id). Would you
like me to send a patch changing the name?
 
> 
> On 15/10/2012 15:02, "Daniel De Graaf"  wrote:
> 
>> While this patch is a part of my XSM IS_PRIV series, I am reposting it
>> alone because the XSM build of xen-unstable is currently broken. I can
>> also repost the remaining patches series if that would be helpful.
>>
>> --------------------------------->8----------------------------------
>>
>> These functions will be used to avoid duplication of IS_PRIV calls
>> that will be introduced in XSM hooks. This also fixes a build error
>> with XSM enabled introduced by 25925:d1c3375c3f11 which depends on
>> this patch.
>>
>> Signed-off-by: Daniel De Graaf 
>> ---
>>  xen/common/domain.c     | 21 +++++++++++++++++++++
>>  xen/include/xen/sched.h | 11 +++++++++++
>>  2 files changed, 32 insertions(+)
>>
>> diff --git a/xen/common/domain.c b/xen/common/domain.c
>> index a1aa05e..52489b3 100644
>> --- a/xen/common/domain.c
>> +++ b/xen/common/domain.c
>> @@ -420,6 +420,13 @@ struct domain *rcu_lock_domain_by_id(domid_t dom)
>>      return d;
>>  }
>>  
>> +struct domain *rcu_lock_domain_by_any_id(domid_t dom)
>> +{
>> +    if ( dom == DOMID_SELF )
>> +        return rcu_lock_current_domain();
>> +    return rcu_lock_domain_by_id(dom);
>> +}
>> +
>>  int rcu_lock_target_domain_by_id(domid_t dom, struct domain **d)
>>  {
>>      if ( dom == DOMID_SELF )
>> @@ -454,6 +461,20 @@ int rcu_lock_remote_target_domain_by_id(domid_t dom,
>> struct domain **d)
>>      return 0;
>>  }
>>  
>> +int rcu_lock_remote_domain_by_id(domid_t dom, struct domain **d)
>> +{
>> +    if ( (*d = rcu_lock_domain_by_id(dom)) == NULL )
>> +        return -ESRCH;
>> +
>> +    if ( *d == current->domain )
>> +    {
>> +        rcu_unlock_domain(*d);
>> +        return -EPERM;
>> +    }
>> +
>> +    return 0;
>> +}
>> +
>>  int domain_kill(struct domain *d)
>>  {
>>      int rc = 0;
>> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
>> index 53804c8..b0def4a 100644
>> --- a/xen/include/xen/sched.h
>> +++ b/xen/include/xen/sched.h
>> @@ -447,6 +447,11 @@ struct domain *domain_create(
>>  struct domain *rcu_lock_domain_by_id(domid_t dom);
>>  
>>  /*
>> + * As above function, but resolves DOMID_SELF to current domain
>> + */
>> +struct domain *rcu_lock_domain_by_any_id(domid_t dom);
>> +
>> +/*
>>   * As above function, but accounts for current domain context:
>>   *  - Translates target DOMID_SELF into caller's domain id; and
>>   *  - Checks that caller has permission to act on the target domain.
>> @@ -460,6 +465,12 @@ int rcu_lock_target_domain_by_id(domid_t dom, struct
>> domain **d);
>>   */
>>  int rcu_lock_remote_target_domain_by_id(domid_t dom, struct domain **d);
>>  
>> +/*
>> + * As rcu_lock_domain_by_id(), but will fail EPERM or ESRCH rather than
>> resolve
>> + * to local domain.
>> + */
>> +int rcu_lock_remote_domain_by_id(domid_t dom, struct domain **d);
>> +
>>  /* Finish a RCU critical region started by rcu_lock_domain_by_id(). */
>>  static inline void rcu_unlock_domain(struct domain *d)
>>  {
> 


-- 
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 15:32:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 15:32:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNmeK-0007FL-5v; Mon, 15 Oct 2012 15:32:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from ) id 1TNmeI-0007Ci-RQ
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 15:32:11 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-27.messagelabs.com!1350315123!8641332!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30061 invoked from network); 15 Oct 2012 15:32:04 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-5.tower-27.messagelabs.com with SMTP;
	15 Oct 2012 15:32:04 -0000
X-TM-IMSS-Message-ID: 
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1;
	TLSv1/SSLv3 DHE-RSA-AES256-SHA (256/256)) id e3b8b6e00003d2d2 ;
	Mon, 15 Oct 2012 11:31:43 -0400
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q9FFVxlI000826; 
	Mon, 15 Oct 2012 11:32:00 -0400
Message-ID: <507C2C6F.2060507@tycho.nsa.gov>
Date: Mon, 15 Oct 2012 11:31:59 -0400
From: Daniel De Graaf 
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121009 Thunderbird/16.0
MIME-Version: 1.0
To: Keir Fraser 
References: 
In-Reply-To: 
Cc: Ian.Campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen: Add versions of rcu_lock_*_domain
	without IS_PRIV
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/15/2012 11:26 AM, Keir Fraser wrote:
> Must we have two new calls for translating a domid to a domain? It's getting
> to be a confusing mess isn't it? Also, here, a more consistent name for
> rcu_lock_domain_by_any_id would be rcu_lock_any_domain_by_id, I think?
> 
>  -- Keir

The original version of this patch queue removed the two _target_ calls;
that removal is not in the current versions to avoid breaking code that is
not yet converted (ARM and two other callers not converted).

The name rcu_lock_any_domain_by_id is also fine, although it seems to imply
that rcu_lock_domain_by_id cannot lock any domain, when the real difference
is if they accept DOMID_SELF (hence why I chose to say any_id). Would you
like me to send a patch changing the name?
 
> 
> On 15/10/2012 15:02, "Daniel De Graaf"  wrote:
> 
>> While this patch is a part of my XSM IS_PRIV series, I am reposting it
>> alone because the XSM build of xen-unstable is currently broken. I can
>> also repost the remaining patches series if that would be helpful.
>>
>> --------------------------------->8----------------------------------
>>
>> These functions will be used to avoid duplication of IS_PRIV calls
>> that will be introduced in XSM hooks. This also fixes a build error
>> with XSM enabled introduced by 25925:d1c3375c3f11 which depends on
>> this patch.
>>
>> Signed-off-by: Daniel De Graaf 
>> ---
>>  xen/common/domain.c     | 21 +++++++++++++++++++++
>>  xen/include/xen/sched.h | 11 +++++++++++
>>  2 files changed, 32 insertions(+)
>>
>> diff --git a/xen/common/domain.c b/xen/common/domain.c
>> index a1aa05e..52489b3 100644
>> --- a/xen/common/domain.c
>> +++ b/xen/common/domain.c
>> @@ -420,6 +420,13 @@ struct domain *rcu_lock_domain_by_id(domid_t dom)
>>      return d;
>>  }
>>  
>> +struct domain *rcu_lock_domain_by_any_id(domid_t dom)
>> +{
>> +    if ( dom == DOMID_SELF )
>> +        return rcu_lock_current_domain();
>> +    return rcu_lock_domain_by_id(dom);
>> +}
>> +
>>  int rcu_lock_target_domain_by_id(domid_t dom, struct domain **d)
>>  {
>>      if ( dom == DOMID_SELF )
>> @@ -454,6 +461,20 @@ int rcu_lock_remote_target_domain_by_id(domid_t dom,
>> struct domain **d)
>>      return 0;
>>  }
>>  
>> +int rcu_lock_remote_domain_by_id(domid_t dom, struct domain **d)
>> +{
>> +    if ( (*d = rcu_lock_domain_by_id(dom)) == NULL )
>> +        return -ESRCH;
>> +
>> +    if ( *d == current->domain )
>> +    {
>> +        rcu_unlock_domain(*d);
>> +        return -EPERM;
>> +    }
>> +
>> +    return 0;
>> +}
>> +
>>  int domain_kill(struct domain *d)
>>  {
>>      int rc = 0;
>> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
>> index 53804c8..b0def4a 100644
>> --- a/xen/include/xen/sched.h
>> +++ b/xen/include/xen/sched.h
>> @@ -447,6 +447,11 @@ struct domain *domain_create(
>>  struct domain *rcu_lock_domain_by_id(domid_t dom);
>>  
>>  /*
>> + * As above function, but resolves DOMID_SELF to current domain
>> + */
>> +struct domain *rcu_lock_domain_by_any_id(domid_t dom);
>> +
>> +/*
>>   * As above function, but accounts for current domain context:
>>   *  - Translates target DOMID_SELF into caller's domain id; and
>>   *  - Checks that caller has permission to act on the target domain.
>> @@ -460,6 +465,12 @@ int rcu_lock_target_domain_by_id(domid_t dom, struct
>> domain **d);
>>   */
>>  int rcu_lock_remote_target_domain_by_id(domid_t dom, struct domain **d);
>>  
>> +/*
>> + * As rcu_lock_domain_by_id(), but will fail EPERM or ESRCH rather than
>> resolve
>> + * to local domain.
>> + */
>> +int rcu_lock_remote_domain_by_id(domid_t dom, struct domain **d);
>> +
>>  /* Finish a RCU critical region started by rcu_lock_domain_by_id(). */
>>  static inline void rcu_unlock_domain(struct domain *d)
>>  {
> 


-- 
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 15:43:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 15:43:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNmol-0008B7-Gf; Mon, 15 Oct 2012 15:42:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNmok-0008B1-Ic
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 15:42:58 +0000
Received: from [85.158.137.99:26529] by server-7.bemta-3.messagelabs.com id
	29/74-06991-10F2C705; Mon, 15 Oct 2012 15:42:57 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1350315775!20444019!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODI0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30030 invoked from network); 15 Oct 2012 15:42:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 15:42:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,588,1344211200"; d="scan'208";a="211305648"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 15:42:55 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 11:42:54 -0400
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TNmog-0008A6-Ja;
	Mon, 15 Oct 2012 16:42:54 +0100
Message-ID: <507C2EFE.8060806@citrix.com>
Date: Mon, 15 Oct 2012 16:42:54 +0100
From: Andrew Cooper 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Ian Campbell 
References: <952b1ef292469c9a9af5.1350314699@andrewcoop.uk.xensource.com>
	<1350315108.18058.73.camel@zakaz.uk.xensource.com>
In-Reply-To: <1350315108.18058.73.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.5
Cc: Ian Jackson ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] build/xenstore: Correct static link failure
	for xenstore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 15/10/12 16:31, Ian Campbell wrote:
> On Mon, 2012-10-15 at 16:24 +0100, Andrew Cooper wrote:
>> There is support for building xenstore clients statically.  However,
>> recent changes to the makefiles have rendered the static build broken.
>>
>> tools/xenstore/Makefile sets LIBXENSTORE depending on whether
>> XENSTORE_STATIC_CLIENTS is specified, but will unconditionally try to
>> link against libxenstore.so by use of the LDLIBS_libxenstore variable.
>>
>> This patch doubles the logic already present to select the appropriate
>> library target.
>>
>> Signed-off-by: Andrew Cooper 
>>
>> --
>> This is a bit of a hack, but seems to be the only reliable way,
>> espcially when linking with the LDLIBS_libxenstore variable in
>> toos/misc.
> I think it would be cleaner to define LDLIBS_libxenstore_static in
> Rules.mk alongside the existing thing and make the appropriate selection
> in the xenstore Makefile. That keeps the fugliness next to where it is
> used.

But that then requires patching for *every* consumer of
LDLIBS_libxenstore, which is a substantially larger and more invasive.

~Andrew

>
>> diff -r 099589002239 -r 952b1ef29246 tools/Rules.mk
>> --- a/tools/Rules.mk
>> +++ b/tools/Rules.mk
>> @@ -28,7 +28,11 @@ LDLIBS_libxenguest = $(XEN_LIBXC)/libxen
>>  SHLIB_libxenguest  = -Wl,-rpath-link=L$(XEN_LIBXC)
>>  
>>  CFLAGS_libxenstore = -I$(XEN_XENSTORE) $(CFLAGS_xeninclude)
>> +ifneq ($(XENSTORE_STATIC_CLIENTS),y)
>>  LDLIBS_libxenstore = $(XEN_XENSTORE)/libxenstore.so
>> +else
>> +LDLIBS_libxenstore = $(XEN_XENSTORE)/libxenstore.a
>> +endif
>>  SHLIB_libxenstore  = -Wl,-rpath-link=$(XEN_XENSTORE)
>>  
>>  CFLAGS_libxenstat  = -I$(XEN_LIBXENSTAT)
>

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 15:43:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 15:43:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNmol-0008B7-Gf; Mon, 15 Oct 2012 15:42:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNmok-0008B1-Ic
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 15:42:58 +0000
Received: from [85.158.137.99:26529] by server-7.bemta-3.messagelabs.com id
	29/74-06991-10F2C705; Mon, 15 Oct 2012 15:42:57 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1350315775!20444019!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODI0MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30030 invoked from network); 15 Oct 2012 15:42:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 15:42:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,588,1344211200"; d="scan'208";a="211305648"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 15:42:55 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 11:42:54 -0400
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TNmog-0008A6-Ja;
	Mon, 15 Oct 2012 16:42:54 +0100
Message-ID: <507C2EFE.8060806@citrix.com>
Date: Mon, 15 Oct 2012 16:42:54 +0100
From: Andrew Cooper 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Ian Campbell 
References: <952b1ef292469c9a9af5.1350314699@andrewcoop.uk.xensource.com>
	<1350315108.18058.73.camel@zakaz.uk.xensource.com>
In-Reply-To: <1350315108.18058.73.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.5
Cc: Ian Jackson ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] build/xenstore: Correct static link failure
	for xenstore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 15/10/12 16:31, Ian Campbell wrote:
> On Mon, 2012-10-15 at 16:24 +0100, Andrew Cooper wrote:
>> There is support for building xenstore clients statically.  However,
>> recent changes to the makefiles have rendered the static build broken.
>>
>> tools/xenstore/Makefile sets LIBXENSTORE depending on whether
>> XENSTORE_STATIC_CLIENTS is specified, but will unconditionally try to
>> link against libxenstore.so by use of the LDLIBS_libxenstore variable.
>>
>> This patch doubles the logic already present to select the appropriate
>> library target.
>>
>> Signed-off-by: Andrew Cooper 
>>
>> --
>> This is a bit of a hack, but seems to be the only reliable way,
>> espcially when linking with the LDLIBS_libxenstore variable in
>> toos/misc.
> I think it would be cleaner to define LDLIBS_libxenstore_static in
> Rules.mk alongside the existing thing and make the appropriate selection
> in the xenstore Makefile. That keeps the fugliness next to where it is
> used.

But that then requires patching for *every* consumer of
LDLIBS_libxenstore, which is a substantially larger and more invasive.

~Andrew

>
>> diff -r 099589002239 -r 952b1ef29246 tools/Rules.mk
>> --- a/tools/Rules.mk
>> +++ b/tools/Rules.mk
>> @@ -28,7 +28,11 @@ LDLIBS_libxenguest = $(XEN_LIBXC)/libxen
>>  SHLIB_libxenguest  = -Wl,-rpath-link=L$(XEN_LIBXC)
>>  
>>  CFLAGS_libxenstore = -I$(XEN_XENSTORE) $(CFLAGS_xeninclude)
>> +ifneq ($(XENSTORE_STATIC_CLIENTS),y)
>>  LDLIBS_libxenstore = $(XEN_XENSTORE)/libxenstore.so
>> +else
>> +LDLIBS_libxenstore = $(XEN_XENSTORE)/libxenstore.a
>> +endif
>>  SHLIB_libxenstore  = -Wl,-rpath-link=$(XEN_XENSTORE)
>>  
>>  CFLAGS_libxenstat  = -I$(XEN_LIBXENSTAT)
>

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 15:46:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 15:46:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNmro-0008U1-RK; Mon, 15 Oct 2012 15:46:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNmrn-0008Tq-W2
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 15:46:08 +0000
Received: from [85.158.143.99:4342] by server-3.bemta-4.messagelabs.com id
	1B/9A-10075-FBF2C705; Mon, 15 Oct 2012 15:46:07 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1350315966!28898564!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR, RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2970 invoked from network); 15 Oct 2012 15:46:06 -0000
Received: from mail-ea0-f173.google.com (HELO mail-ea0-f173.google.com)
	(209.85.215.173)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 15:46:06 -0000
Received: by mail-ea0-f173.google.com with SMTP id a1so1237935eaa.32
	for ; Mon, 15 Oct 2012 08:46:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type;
	bh=qGCFgypB/5SeJBhauV7daxqvtl5g2d5VbarvmU6cZyA=;
	b=cRUkcoJVUANmDpduheSi2A/K+Sc1kWwOGOk7Na1iMlCailXIfSaRr+mnQI1BhOzXLv
	Z70Y69NxCNkSHGxhl/cYkqrgpddy63LJpTKdfBQyHf5YPJ7VcLmYV+JzQMmZ+7Y2zAd0
	H9pldNVFksi6UxYvUQPmt8XFZKly3l6UIBnGd3xQHmdb9xYP3FTrc8ACKXFWJ3SQ3Yzt
	AJIjj7ZcUpQJovNJcnpSs7QPw+x1XFZV6tPk2lB8EosA7gn5+OQffaMqSYjf+X3D2/5f
	pIYxU3ZirlRcX6IqPrO5a91pm1TsdM38SZM8l3z/M2rA1nJfVeH3CfFwWC5PJbWI2vRL
	T/sA==
Received: by 10.14.194.72 with SMTP id l48mr16435643een.9.1350315966234;
	Mon, 15 Oct 2012 08:46:06 -0700 (PDT)
Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com.
	[86.183.156.141])
	by mx.google.com with ESMTPS id 42sm25583423eee.0.2012.10.15.08.46.03
	(version=SSLv3 cipher=OTHER); Mon, 15 Oct 2012 08:46:04 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Mon, 15 Oct 2012 16:45:57 +0100
From: Keir Fraser 
To: tupeng212 
Message-ID: 
Thread-Topic: [Xen-devel] alloc_heap_pages is low efficient with more CPUs
Thread-Index: Ac2q7CrCExH23rm/tkiC9JNAARv1qQ==
In-Reply-To: <201210152127478127583@gmail.com>
Mime-version: 1.0
Content-type: multipart/mixed;
	boundary="B_3433164363_31918899"
Cc: Jan Beulich , xen-devel 
Subject: Re: [Xen-devel] alloc_heap_pages is low efficient with more CPUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3433164363_31918899
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

On 15/10/2012 14:27, "tupeng212"  wrote:

> Please try the attached patch.
> : Great!  you have done a good job, needless time decreases badly to 1s.
>  
> If anybody has no proposal, I suggest you to commit this patch.

I have applied it to xen-unstable. It probably makes sense to put it in 4.1
and 4.2 as well (cc'ed Jan, and attaching the backport for 4.1 again).

 -- Keir



--B_3433164363_31918899
Content-type: application/octet-stream; name="00-reduce-tlbflush_filter"
Content-disposition: attachment;
	filename="00-reduce-tlbflush_filter"
Content-transfer-encoding: base64


ZGlmZiAtciBhMTU1OTZhNjE5ZWQgeGVuL2NvbW1vbi9wYWdlX2FsbG9jLmMKLS0tIGEveGVu
L2NvbW1vbi9wYWdlX2FsbG9jLmMJVGh1IE9jdCAwNCAxMDo0NDo0MyAyMDEyICswMjAwCisr
KyBiL3hlbi9jb21tb24vcGFnZV9hbGxvYy5jCVNhdCBPY3QgMTMgMDk6NTc6MjYgMjAxMiAr
MDEwMApAQCAtMzAzLDkgKzMwMywxMCBAQCBzdGF0aWMgc3RydWN0IHBhZ2VfaW5mbyAqYWxs
b2NfaGVhcF9wYWdlCiAgICAgdW5zaWduZWQgaW50IGZpcnN0X25vZGUsIGksIGosIHpvbmUg
PSAwLCBub2RlbWFza19yZXRyeSA9IDA7CiAgICAgdW5zaWduZWQgaW50IG5vZGUgPSAodWlu
dDhfdCkoKG1lbWZsYWdzID4+IF9NRU1GX25vZGUpIC0gMSk7CiAgICAgdW5zaWduZWQgbG9u
ZyByZXF1ZXN0ID0gMVVMIDw8IG9yZGVyOwotICAgIGNwdW1hc2tfdCBleHRyYV9jcHVzX21h
c2ssIG1hc2s7CiAgICAgc3RydWN0IHBhZ2VfaW5mbyAqcGc7CiAgICAgbm9kZW1hc2tfdCBu
b2RlbWFzayA9IChkICE9IE5VTEwgKSA/IGQtPm5vZGVfYWZmaW5pdHkgOiBub2RlX29ubGlu
ZV9tYXA7CisgICAgYm9vbF90IG5lZWRfdGxiZmx1c2ggPSAwOworICAgIHVpbnQzMl90IHRs
YmZsdXNoX3RpbWVzdGFtcCA9IDA7CiAKICAgICBpZiAoIG5vZGUgPT0gTlVNQV9OT19OT0RF
ICkKICAgICB7CkBAIC00MTcsMjAgKzQxOCwxOSBAQCBzdGF0aWMgc3RydWN0IHBhZ2VfaW5m
byAqYWxsb2NfaGVhcF9wYWdlCiAgICAgaWYgKCBkICE9IE5VTEwgKQogICAgICAgICBkLT5s
YXN0X2FsbG9jX25vZGUgPSBub2RlOwogCi0gICAgY3B1c19jbGVhcihtYXNrKTsKLQogICAg
IGZvciAoIGkgPSAwOyBpIDwgKDEgPDwgb3JkZXIpOyBpKysgKQogICAgIHsKICAgICAgICAg
LyogUmVmZXJlbmNlIGNvdW50IG11c3QgY29udGludW91c2x5IGJlIHplcm8gZm9yIGZyZWUg
cGFnZXMuICovCiAgICAgICAgIEJVR19PTihwZ1tpXS5jb3VudF9pbmZvICE9IFBHQ19zdGF0
ZV9mcmVlKTsKICAgICAgICAgcGdbaV0uY291bnRfaW5mbyA9IFBHQ19zdGF0ZV9pbnVzZTsK
IAotICAgICAgICBpZiAoIHBnW2ldLnUuZnJlZS5uZWVkX3RsYmZsdXNoICkKKyAgICAgICAg
aWYgKCBwZ1tpXS51LmZyZWUubmVlZF90bGJmbHVzaCAmJgorICAgICAgICAgICAgIChwZ1tp
XS50bGJmbHVzaF90aW1lc3RhbXAgPD0gdGxiZmx1c2hfY3VycmVudF90aW1lKCkpICYmCisg
ICAgICAgICAgICAgKCFuZWVkX3RsYmZsdXNoIHx8CisgICAgICAgICAgICAgIChwZ1tpXS50
bGJmbHVzaF90aW1lc3RhbXAgPiB0bGJmbHVzaF90aW1lc3RhbXApKSApCiAgICAgICAgIHsK
LSAgICAgICAgICAgIC8qIEFkZCBpbiBleHRyYSBDUFVzIHRoYXQgbmVlZCBmbHVzaGluZyBi
ZWNhdXNlIG9mIHRoaXMgcGFnZS4gKi8KLSAgICAgICAgICAgIGNwdXNfYW5kbm90KGV4dHJh
X2NwdXNfbWFzaywgY3B1X29ubGluZV9tYXAsIG1hc2spOwotICAgICAgICAgICAgdGxiZmx1
c2hfZmlsdGVyKGV4dHJhX2NwdXNfbWFzaywgcGdbaV0udGxiZmx1c2hfdGltZXN0YW1wKTsK
LSAgICAgICAgICAgIGNwdXNfb3IobWFzaywgbWFzaywgZXh0cmFfY3B1c19tYXNrKTsKKyAg
ICAgICAgICAgIG5lZWRfdGxiZmx1c2ggPSAxOworICAgICAgICAgICAgdGxiZmx1c2hfdGlt
ZXN0YW1wID0gcGdbaV0udGxiZmx1c2hfdGltZXN0YW1wOwogICAgICAgICB9CiAKICAgICAg
ICAgLyogSW5pdGlhbGlzZSBmaWVsZHMgd2hpY2ggaGF2ZSBvdGhlciB1c2VzIGZvciBmcmVl
IHBhZ2VzLiAqLwpAQCAtNDQwLDEwICs0NDAsMTUgQEAgc3RhdGljIHN0cnVjdCBwYWdlX2lu
Zm8gKmFsbG9jX2hlYXBfcGFnZQogCiAgICAgc3Bpbl91bmxvY2soJmhlYXBfbG9jayk7CiAK
LSAgICBpZiAoIHVubGlrZWx5KCFjcHVzX2VtcHR5KG1hc2spKSApCisgICAgaWYgKCBuZWVk
X3RsYmZsdXNoICkKICAgICB7Ci0gICAgICAgIHBlcmZjX2luY3IobmVlZF9mbHVzaF90bGJf
Zmx1c2gpOwotICAgICAgICBmbHVzaF90bGJfbWFzaygmbWFzayk7CisgICAgICAgIGNwdW1h
c2tfdCBtYXNrID0gY3B1X29ubGluZV9tYXA7CisgICAgICAgIHRsYmZsdXNoX2ZpbHRlciht
YXNrLCB0bGJmbHVzaF90aW1lc3RhbXApOworICAgICAgICBpZiAoICFjcHVzX2VtcHR5KG1h
c2spICkKKyAgICAgICAgeworICAgICAgICAgICAgcGVyZmNfaW5jcihuZWVkX2ZsdXNoX3Rs
Yl9mbHVzaCk7CisgICAgICAgICAgICBmbHVzaF90bGJfbWFzaygmbWFzayk7CisgICAgICAg
IH0KICAgICB9CiAKICAgICByZXR1cm4gcGc7Cg==
--B_3433164363_31918899
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--B_3433164363_31918899--




From xen-devel-bounces@lists.xen.org Mon Oct 15 15:46:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 15:46:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNmro-0008U1-RK; Mon, 15 Oct 2012 15:46:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNmrn-0008Tq-W2
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 15:46:08 +0000
Received: from [85.158.143.99:4342] by server-3.bemta-4.messagelabs.com id
	1B/9A-10075-FBF2C705; Mon, 15 Oct 2012 15:46:07 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1350315966!28898564!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR, RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2970 invoked from network); 15 Oct 2012 15:46:06 -0000
Received: from mail-ea0-f173.google.com (HELO mail-ea0-f173.google.com)
	(209.85.215.173)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 15:46:06 -0000
Received: by mail-ea0-f173.google.com with SMTP id a1so1237935eaa.32
	for ; Mon, 15 Oct 2012 08:46:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type;
	bh=qGCFgypB/5SeJBhauV7daxqvtl5g2d5VbarvmU6cZyA=;
	b=cRUkcoJVUANmDpduheSi2A/K+Sc1kWwOGOk7Na1iMlCailXIfSaRr+mnQI1BhOzXLv
	Z70Y69NxCNkSHGxhl/cYkqrgpddy63LJpTKdfBQyHf5YPJ7VcLmYV+JzQMmZ+7Y2zAd0
	H9pldNVFksi6UxYvUQPmt8XFZKly3l6UIBnGd3xQHmdb9xYP3FTrc8ACKXFWJ3SQ3Yzt
	AJIjj7ZcUpQJovNJcnpSs7QPw+x1XFZV6tPk2lB8EosA7gn5+OQffaMqSYjf+X3D2/5f
	pIYxU3ZirlRcX6IqPrO5a91pm1TsdM38SZM8l3z/M2rA1nJfVeH3CfFwWC5PJbWI2vRL
	T/sA==
Received: by 10.14.194.72 with SMTP id l48mr16435643een.9.1350315966234;
	Mon, 15 Oct 2012 08:46:06 -0700 (PDT)
Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com.
	[86.183.156.141])
	by mx.google.com with ESMTPS id 42sm25583423eee.0.2012.10.15.08.46.03
	(version=SSLv3 cipher=OTHER); Mon, 15 Oct 2012 08:46:04 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Mon, 15 Oct 2012 16:45:57 +0100
From: Keir Fraser 
To: tupeng212 
Message-ID: 
Thread-Topic: [Xen-devel] alloc_heap_pages is low efficient with more CPUs
Thread-Index: Ac2q7CrCExH23rm/tkiC9JNAARv1qQ==
In-Reply-To: <201210152127478127583@gmail.com>
Mime-version: 1.0
Content-type: multipart/mixed;
	boundary="B_3433164363_31918899"
Cc: Jan Beulich , xen-devel 
Subject: Re: [Xen-devel] alloc_heap_pages is low efficient with more CPUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3433164363_31918899
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

On 15/10/2012 14:27, "tupeng212"  wrote:

> Please try the attached patch.
> : Great!  you have done a good job, needless time decreases badly to 1s.
>  
> If anybody has no proposal, I suggest you to commit this patch.

I have applied it to xen-unstable. It probably makes sense to put it in 4.1
and 4.2 as well (cc'ed Jan, and attaching the backport for 4.1 again).

 -- Keir



--B_3433164363_31918899
Content-type: application/octet-stream; name="00-reduce-tlbflush_filter"
Content-disposition: attachment;
	filename="00-reduce-tlbflush_filter"
Content-transfer-encoding: base64


ZGlmZiAtciBhMTU1OTZhNjE5ZWQgeGVuL2NvbW1vbi9wYWdlX2FsbG9jLmMKLS0tIGEveGVu
L2NvbW1vbi9wYWdlX2FsbG9jLmMJVGh1IE9jdCAwNCAxMDo0NDo0MyAyMDEyICswMjAwCisr
KyBiL3hlbi9jb21tb24vcGFnZV9hbGxvYy5jCVNhdCBPY3QgMTMgMDk6NTc6MjYgMjAxMiAr
MDEwMApAQCAtMzAzLDkgKzMwMywxMCBAQCBzdGF0aWMgc3RydWN0IHBhZ2VfaW5mbyAqYWxs
b2NfaGVhcF9wYWdlCiAgICAgdW5zaWduZWQgaW50IGZpcnN0X25vZGUsIGksIGosIHpvbmUg
PSAwLCBub2RlbWFza19yZXRyeSA9IDA7CiAgICAgdW5zaWduZWQgaW50IG5vZGUgPSAodWlu
dDhfdCkoKG1lbWZsYWdzID4+IF9NRU1GX25vZGUpIC0gMSk7CiAgICAgdW5zaWduZWQgbG9u
ZyByZXF1ZXN0ID0gMVVMIDw8IG9yZGVyOwotICAgIGNwdW1hc2tfdCBleHRyYV9jcHVzX21h
c2ssIG1hc2s7CiAgICAgc3RydWN0IHBhZ2VfaW5mbyAqcGc7CiAgICAgbm9kZW1hc2tfdCBu
b2RlbWFzayA9IChkICE9IE5VTEwgKSA/IGQtPm5vZGVfYWZmaW5pdHkgOiBub2RlX29ubGlu
ZV9tYXA7CisgICAgYm9vbF90IG5lZWRfdGxiZmx1c2ggPSAwOworICAgIHVpbnQzMl90IHRs
YmZsdXNoX3RpbWVzdGFtcCA9IDA7CiAKICAgICBpZiAoIG5vZGUgPT0gTlVNQV9OT19OT0RF
ICkKICAgICB7CkBAIC00MTcsMjAgKzQxOCwxOSBAQCBzdGF0aWMgc3RydWN0IHBhZ2VfaW5m
byAqYWxsb2NfaGVhcF9wYWdlCiAgICAgaWYgKCBkICE9IE5VTEwgKQogICAgICAgICBkLT5s
YXN0X2FsbG9jX25vZGUgPSBub2RlOwogCi0gICAgY3B1c19jbGVhcihtYXNrKTsKLQogICAg
IGZvciAoIGkgPSAwOyBpIDwgKDEgPDwgb3JkZXIpOyBpKysgKQogICAgIHsKICAgICAgICAg
LyogUmVmZXJlbmNlIGNvdW50IG11c3QgY29udGludW91c2x5IGJlIHplcm8gZm9yIGZyZWUg
cGFnZXMuICovCiAgICAgICAgIEJVR19PTihwZ1tpXS5jb3VudF9pbmZvICE9IFBHQ19zdGF0
ZV9mcmVlKTsKICAgICAgICAgcGdbaV0uY291bnRfaW5mbyA9IFBHQ19zdGF0ZV9pbnVzZTsK
IAotICAgICAgICBpZiAoIHBnW2ldLnUuZnJlZS5uZWVkX3RsYmZsdXNoICkKKyAgICAgICAg
aWYgKCBwZ1tpXS51LmZyZWUubmVlZF90bGJmbHVzaCAmJgorICAgICAgICAgICAgIChwZ1tp
XS50bGJmbHVzaF90aW1lc3RhbXAgPD0gdGxiZmx1c2hfY3VycmVudF90aW1lKCkpICYmCisg
ICAgICAgICAgICAgKCFuZWVkX3RsYmZsdXNoIHx8CisgICAgICAgICAgICAgIChwZ1tpXS50
bGJmbHVzaF90aW1lc3RhbXAgPiB0bGJmbHVzaF90aW1lc3RhbXApKSApCiAgICAgICAgIHsK
LSAgICAgICAgICAgIC8qIEFkZCBpbiBleHRyYSBDUFVzIHRoYXQgbmVlZCBmbHVzaGluZyBi
ZWNhdXNlIG9mIHRoaXMgcGFnZS4gKi8KLSAgICAgICAgICAgIGNwdXNfYW5kbm90KGV4dHJh
X2NwdXNfbWFzaywgY3B1X29ubGluZV9tYXAsIG1hc2spOwotICAgICAgICAgICAgdGxiZmx1
c2hfZmlsdGVyKGV4dHJhX2NwdXNfbWFzaywgcGdbaV0udGxiZmx1c2hfdGltZXN0YW1wKTsK
LSAgICAgICAgICAgIGNwdXNfb3IobWFzaywgbWFzaywgZXh0cmFfY3B1c19tYXNrKTsKKyAg
ICAgICAgICAgIG5lZWRfdGxiZmx1c2ggPSAxOworICAgICAgICAgICAgdGxiZmx1c2hfdGlt
ZXN0YW1wID0gcGdbaV0udGxiZmx1c2hfdGltZXN0YW1wOwogICAgICAgICB9CiAKICAgICAg
ICAgLyogSW5pdGlhbGlzZSBmaWVsZHMgd2hpY2ggaGF2ZSBvdGhlciB1c2VzIGZvciBmcmVl
IHBhZ2VzLiAqLwpAQCAtNDQwLDEwICs0NDAsMTUgQEAgc3RhdGljIHN0cnVjdCBwYWdlX2lu
Zm8gKmFsbG9jX2hlYXBfcGFnZQogCiAgICAgc3Bpbl91bmxvY2soJmhlYXBfbG9jayk7CiAK
LSAgICBpZiAoIHVubGlrZWx5KCFjcHVzX2VtcHR5KG1hc2spKSApCisgICAgaWYgKCBuZWVk
X3RsYmZsdXNoICkKICAgICB7Ci0gICAgICAgIHBlcmZjX2luY3IobmVlZF9mbHVzaF90bGJf
Zmx1c2gpOwotICAgICAgICBmbHVzaF90bGJfbWFzaygmbWFzayk7CisgICAgICAgIGNwdW1h
c2tfdCBtYXNrID0gY3B1X29ubGluZV9tYXA7CisgICAgICAgIHRsYmZsdXNoX2ZpbHRlciht
YXNrLCB0bGJmbHVzaF90aW1lc3RhbXApOworICAgICAgICBpZiAoICFjcHVzX2VtcHR5KG1h
c2spICkKKyAgICAgICAgeworICAgICAgICAgICAgcGVyZmNfaW5jcihuZWVkX2ZsdXNoX3Rs
Yl9mbHVzaCk7CisgICAgICAgICAgICBmbHVzaF90bGJfbWFzaygmbWFzayk7CisgICAgICAg
IH0KICAgICB9CiAKICAgICByZXR1cm4gcGc7Cg==
--B_3433164363_31918899
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--B_3433164363_31918899--




From xen-devel-bounces@lists.xen.org Mon Oct 15 15:48:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 15:48:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNmtJ-0000ET-BR; Mon, 15 Oct 2012 15:47:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNmtI-0000EE-9M
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 15:47:40 +0000
Received: from [85.158.138.51:32332] by server-11.bemta-3.messagelabs.com id
	C9/6C-24008-B103C705; Mon, 15 Oct 2012 15:47:39 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1350316058!33942806!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20149 invoked from network); 15 Oct 2012 15:47:38 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 15:47:38 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so3223995eek.32
	for ; Mon, 15 Oct 2012 08:47:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=EHXm4zOKxsjEwk5KqjooJzhYo4CX8fwrWScesDnYHA4=;
	b=O0YDR/Ho81woiZQxsYUqY7dz3LvWKF4TLxj/lVfcBnC3zFhXQm0sSM3iBFI07VHJHU
	6LTwlBluy82ttcoGvJ2usNcKyqoTIjdwU82w/1pA1LvpCKI5iYAeCfaduPFvul/Xm88q
	aWUM9S7nS5W3AMOWXSm1c1gd4rDqHb416Eb+nf923pJG5tXwk/KEEuPcF1dsEpa/6vzJ
	8/9pOI5Pb3WCCddkxHleEbyyVIVCMls3gqWsUdeQrsaqLjMRAc5Tzezz+RYwLw6fvrgs
	FYQeEmc3jrrELviI4LEkQ/TujoddZhiGFja/qb6WGFcb9A8dMQFWrxOR/mx5nxXnzGXa
	iXRA==
Received: by 10.14.4.198 with SMTP id 46mr16383146eej.11.1350316058230;
	Mon, 15 Oct 2012 08:47:38 -0700 (PDT)
Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com.
	[86.183.156.141])
	by mx.google.com with ESMTPS id 42sm25589737eee.0.2012.10.15.08.47.30
	(version=SSLv3 cipher=OTHER); Mon, 15 Oct 2012 08:47:37 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Mon, 15 Oct 2012 16:47:26 +0100
From: Keir Fraser 
To: Daniel De Graaf 
Message-ID: 
Thread-Topic: [PATCH] xen: Add versions of rcu_lock_*_domain without IS_PRIV
Thread-Index: Ac2q7F/OIhdiu8Fxd0+lDaksbEJa8Q==
In-Reply-To: <507C2C6F.2060507@tycho.nsa.gov>
Mime-version: 1.0
Cc: Ian.Campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen: Add versions of rcu_lock_*_domain
	without IS_PRIV
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 15/10/2012 16:31, "Daniel De Graaf"  wrote:

> On 10/15/2012 11:26 AM, Keir Fraser wrote:
>> Must we have two new calls for translating a domid to a domain? It's getting
>> to be a confusing mess isn't it? Also, here, a more consistent name for
>> rcu_lock_domain_by_any_id would be rcu_lock_any_domain_by_id, I think?
>> 
>>  -- Keir
> 
> The original version of this patch queue removed the two _target_ calls;
> that removal is not in the current versions to avoid breaking code that is
> not yet converted (ARM and two other callers not converted).
> 
> The name rcu_lock_any_domain_by_id is also fine, although it seems to imply
> that rcu_lock_domain_by_id cannot lock any domain, when the real difference
> is if they accept DOMID_SELF (hence why I chose to say any_id). Would you
> like me to send a patch changing the name?

Oh I see. No I think that's fine then.

 -- Keir

>> 
>> On 15/10/2012 15:02, "Daniel De Graaf"  wrote:
>> 
>>> While this patch is a part of my XSM IS_PRIV series, I am reposting it
>>> alone because the XSM build of xen-unstable is currently broken. I can
>>> also repost the remaining patches series if that would be helpful.
>>> 
>>> --------------------------------->8----------------------------------
>>> 
>>> These functions will be used to avoid duplication of IS_PRIV calls
>>> that will be introduced in XSM hooks. This also fixes a build error
>>> with XSM enabled introduced by 25925:d1c3375c3f11 which depends on
>>> this patch.
>>> 
>>> Signed-off-by: Daniel De Graaf 
>>> ---
>>>  xen/common/domain.c     | 21 +++++++++++++++++++++
>>>  xen/include/xen/sched.h | 11 +++++++++++
>>>  2 files changed, 32 insertions(+)
>>> 
>>> diff --git a/xen/common/domain.c b/xen/common/domain.c
>>> index a1aa05e..52489b3 100644
>>> --- a/xen/common/domain.c
>>> +++ b/xen/common/domain.c
>>> @@ -420,6 +420,13 @@ struct domain *rcu_lock_domain_by_id(domid_t dom)
>>>      return d;
>>>  }
>>>  
>>> +struct domain *rcu_lock_domain_by_any_id(domid_t dom)
>>> +{
>>> +    if ( dom == DOMID_SELF )
>>> +        return rcu_lock_current_domain();
>>> +    return rcu_lock_domain_by_id(dom);
>>> +}
>>> +
>>>  int rcu_lock_target_domain_by_id(domid_t dom, struct domain **d)
>>>  {
>>>      if ( dom == DOMID_SELF )
>>> @@ -454,6 +461,20 @@ int rcu_lock_remote_target_domain_by_id(domid_t dom,
>>> struct domain **d)
>>>      return 0;
>>>  }
>>>  
>>> +int rcu_lock_remote_domain_by_id(domid_t dom, struct domain **d)
>>> +{
>>> +    if ( (*d = rcu_lock_domain_by_id(dom)) == NULL )
>>> +        return -ESRCH;
>>> +
>>> +    if ( *d == current->domain )
>>> +    {
>>> +        rcu_unlock_domain(*d);
>>> +        return -EPERM;
>>> +    }
>>> +
>>> +    return 0;
>>> +}
>>> +
>>>  int domain_kill(struct domain *d)
>>>  {
>>>      int rc = 0;
>>> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
>>> index 53804c8..b0def4a 100644
>>> --- a/xen/include/xen/sched.h
>>> +++ b/xen/include/xen/sched.h
>>> @@ -447,6 +447,11 @@ struct domain *domain_create(
>>>  struct domain *rcu_lock_domain_by_id(domid_t dom);
>>>  
>>>  /*
>>> + * As above function, but resolves DOMID_SELF to current domain
>>> + */
>>> +struct domain *rcu_lock_domain_by_any_id(domid_t dom);
>>> +
>>> +/*
>>>   * As above function, but accounts for current domain context:
>>>   *  - Translates target DOMID_SELF into caller's domain id; and
>>>   *  - Checks that caller has permission to act on the target domain.
>>> @@ -460,6 +465,12 @@ int rcu_lock_target_domain_by_id(domid_t dom, struct
>>> domain **d);
>>>   */
>>>  int rcu_lock_remote_target_domain_by_id(domid_t dom, struct domain **d);
>>>  
>>> +/*
>>> + * As rcu_lock_domain_by_id(), but will fail EPERM or ESRCH rather than
>>> resolve
>>> + * to local domain.
>>> + */
>>> +int rcu_lock_remote_domain_by_id(domid_t dom, struct domain **d);
>>> +
>>>  /* Finish a RCU critical region started by rcu_lock_domain_by_id(). */
>>>  static inline void rcu_unlock_domain(struct domain *d)
>>>  {
>> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 15:48:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 15:48:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNmtJ-0000ET-BR; Mon, 15 Oct 2012 15:47:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNmtI-0000EE-9M
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 15:47:40 +0000
Received: from [85.158.138.51:32332] by server-11.bemta-3.messagelabs.com id
	C9/6C-24008-B103C705; Mon, 15 Oct 2012 15:47:39 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1350316058!33942806!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20149 invoked from network); 15 Oct 2012 15:47:38 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 15:47:38 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so3223995eek.32
	for ; Mon, 15 Oct 2012 08:47:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=EHXm4zOKxsjEwk5KqjooJzhYo4CX8fwrWScesDnYHA4=;
	b=O0YDR/Ho81woiZQxsYUqY7dz3LvWKF4TLxj/lVfcBnC3zFhXQm0sSM3iBFI07VHJHU
	6LTwlBluy82ttcoGvJ2usNcKyqoTIjdwU82w/1pA1LvpCKI5iYAeCfaduPFvul/Xm88q
	aWUM9S7nS5W3AMOWXSm1c1gd4rDqHb416Eb+nf923pJG5tXwk/KEEuPcF1dsEpa/6vzJ
	8/9pOI5Pb3WCCddkxHleEbyyVIVCMls3gqWsUdeQrsaqLjMRAc5Tzezz+RYwLw6fvrgs
	FYQeEmc3jrrELviI4LEkQ/TujoddZhiGFja/qb6WGFcb9A8dMQFWrxOR/mx5nxXnzGXa
	iXRA==
Received: by 10.14.4.198 with SMTP id 46mr16383146eej.11.1350316058230;
	Mon, 15 Oct 2012 08:47:38 -0700 (PDT)
Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com.
	[86.183.156.141])
	by mx.google.com with ESMTPS id 42sm25589737eee.0.2012.10.15.08.47.30
	(version=SSLv3 cipher=OTHER); Mon, 15 Oct 2012 08:47:37 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Mon, 15 Oct 2012 16:47:26 +0100
From: Keir Fraser 
To: Daniel De Graaf 
Message-ID: 
Thread-Topic: [PATCH] xen: Add versions of rcu_lock_*_domain without IS_PRIV
Thread-Index: Ac2q7F/OIhdiu8Fxd0+lDaksbEJa8Q==
In-Reply-To: <507C2C6F.2060507@tycho.nsa.gov>
Mime-version: 1.0
Cc: Ian.Campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen: Add versions of rcu_lock_*_domain
	without IS_PRIV
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 15/10/2012 16:31, "Daniel De Graaf"  wrote:

> On 10/15/2012 11:26 AM, Keir Fraser wrote:
>> Must we have two new calls for translating a domid to a domain? It's getting
>> to be a confusing mess isn't it? Also, here, a more consistent name for
>> rcu_lock_domain_by_any_id would be rcu_lock_any_domain_by_id, I think?
>> 
>>  -- Keir
> 
> The original version of this patch queue removed the two _target_ calls;
> that removal is not in the current versions to avoid breaking code that is
> not yet converted (ARM and two other callers not converted).
> 
> The name rcu_lock_any_domain_by_id is also fine, although it seems to imply
> that rcu_lock_domain_by_id cannot lock any domain, when the real difference
> is if they accept DOMID_SELF (hence why I chose to say any_id). Would you
> like me to send a patch changing the name?

Oh I see. No I think that's fine then.

 -- Keir

>> 
>> On 15/10/2012 15:02, "Daniel De Graaf"  wrote:
>> 
>>> While this patch is a part of my XSM IS_PRIV series, I am reposting it
>>> alone because the XSM build of xen-unstable is currently broken. I can
>>> also repost the remaining patches series if that would be helpful.
>>> 
>>> --------------------------------->8----------------------------------
>>> 
>>> These functions will be used to avoid duplication of IS_PRIV calls
>>> that will be introduced in XSM hooks. This also fixes a build error
>>> with XSM enabled introduced by 25925:d1c3375c3f11 which depends on
>>> this patch.
>>> 
>>> Signed-off-by: Daniel De Graaf 
>>> ---
>>>  xen/common/domain.c     | 21 +++++++++++++++++++++
>>>  xen/include/xen/sched.h | 11 +++++++++++
>>>  2 files changed, 32 insertions(+)
>>> 
>>> diff --git a/xen/common/domain.c b/xen/common/domain.c
>>> index a1aa05e..52489b3 100644
>>> --- a/xen/common/domain.c
>>> +++ b/xen/common/domain.c
>>> @@ -420,6 +420,13 @@ struct domain *rcu_lock_domain_by_id(domid_t dom)
>>>      return d;
>>>  }
>>>  
>>> +struct domain *rcu_lock_domain_by_any_id(domid_t dom)
>>> +{
>>> +    if ( dom == DOMID_SELF )
>>> +        return rcu_lock_current_domain();
>>> +    return rcu_lock_domain_by_id(dom);
>>> +}
>>> +
>>>  int rcu_lock_target_domain_by_id(domid_t dom, struct domain **d)
>>>  {
>>>      if ( dom == DOMID_SELF )
>>> @@ -454,6 +461,20 @@ int rcu_lock_remote_target_domain_by_id(domid_t dom,
>>> struct domain **d)
>>>      return 0;
>>>  }
>>>  
>>> +int rcu_lock_remote_domain_by_id(domid_t dom, struct domain **d)
>>> +{
>>> +    if ( (*d = rcu_lock_domain_by_id(dom)) == NULL )
>>> +        return -ESRCH;
>>> +
>>> +    if ( *d == current->domain )
>>> +    {
>>> +        rcu_unlock_domain(*d);
>>> +        return -EPERM;
>>> +    }
>>> +
>>> +    return 0;
>>> +}
>>> +
>>>  int domain_kill(struct domain *d)
>>>  {
>>>      int rc = 0;
>>> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
>>> index 53804c8..b0def4a 100644
>>> --- a/xen/include/xen/sched.h
>>> +++ b/xen/include/xen/sched.h
>>> @@ -447,6 +447,11 @@ struct domain *domain_create(
>>>  struct domain *rcu_lock_domain_by_id(domid_t dom);
>>>  
>>>  /*
>>> + * As above function, but resolves DOMID_SELF to current domain
>>> + */
>>> +struct domain *rcu_lock_domain_by_any_id(domid_t dom);
>>> +
>>> +/*
>>>   * As above function, but accounts for current domain context:
>>>   *  - Translates target DOMID_SELF into caller's domain id; and
>>>   *  - Checks that caller has permission to act on the target domain.
>>> @@ -460,6 +465,12 @@ int rcu_lock_target_domain_by_id(domid_t dom, struct
>>> domain **d);
>>>   */
>>>  int rcu_lock_remote_target_domain_by_id(domid_t dom, struct domain **d);
>>>  
>>> +/*
>>> + * As rcu_lock_domain_by_id(), but will fail EPERM or ESRCH rather than
>>> resolve
>>> + * to local domain.
>>> + */
>>> +int rcu_lock_remote_domain_by_id(domid_t dom, struct domain **d);
>>> +
>>>  /* Finish a RCU critical region started by rcu_lock_domain_by_id(). */
>>>  static inline void rcu_unlock_domain(struct domain *d)
>>>  {
>> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 15:49:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 15:49:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNmuR-0000Nr-Ql; Mon, 15 Oct 2012 15:48:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNmuQ-0000Na-25
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 15:48:50 +0000
Received: from [85.158.137.99:62251] by server-9.bemta-3.messagelabs.com id
	05/32-16841-1603C705; Mon, 15 Oct 2012 15:48:49 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1350316128!21656416!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23240 invoked from network); 15 Oct 2012 15:48:48 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 15:48:48 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so3224708eek.32
	for ; Mon, 15 Oct 2012 08:48:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=CrC11lw4c+xQNT8DwHgXsVL260M6EOI3bCxzd/5zFhw=;
	b=wTvq7l7ROkTuTnIlWjt/0goIQhJspywZaerjD539u2Qw+14p50qj/IerbPjlFv7E1n
	9Up5FVgVOk4LZpI4NI5zbaFPhpKr7jf6VD4hl6Qc5F6O2hszAEo92HbvabvxCaaiBchf
	gZfP/G3H4y586V81LZwebg0yLSR5EhZfRl0KtqQcptyVh9oPR54sQNI8DKg01Cegcnb4
	2lMGPQL+wmtjjcM+CuBOa04xtwwPqS6uIwcn+0eyvorhQt10yrjE2m8dcSpQLdCzKwNI
	b4jLg6ZY4XXpmq1d25YxXRCPiVOI5Vvw9Z8HdMHuL26c1IsC54KGKZmUZhqsxL0v5+lr
	86lQ==
Received: by 10.14.209.129 with SMTP id s1mr16393743eeo.24.1350316128394;
	Mon, 15 Oct 2012 08:48:48 -0700 (PDT)
Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com.
	[86.183.156.141])
	by mx.google.com with ESMTPS id v3sm25598298een.1.2012.10.15.08.48.45
	(version=SSLv3 cipher=OTHER); Mon, 15 Oct 2012 08:48:46 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Mon, 15 Oct 2012 16:48:38 +0100
From: Keir Fraser 
To: Ian Campbell , xen-devel 
Message-ID: 
Thread-Topic: [PATCH v2 00/10] 64 bit ARM ABI, map foreign gmfn API, ARM grant
	tables
Thread-Index: Ac2q7Iq55xa7YN9YNkSOn30nYk56KA==
In-Reply-To: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Cc: Tim Deegan ,
	Stefano Stabellini ,
	Jan Beulich 
Subject: Re: [Xen-devel] [PATCH v2 00/10] 64 bit ARM ABI,
 map foreign gmfn API, ARM grant tables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 15/10/2012 16:20, "Ian Campbell"  wrote:

> This is v2 of "Sweep through arm-for-4.3 branch + a bit extra" retitled
> since most of the sweep through stuff has been swept through already and
> just the bit extra remains.
> 
> I've addressed the review comments and fixed the bisection issue. A
> bunch of this stuff is cross arch and/or touches common code.

Those bits are fine by me, now.

Acked-by: Keir Fraser 

> The Linux side of the 64 bit ARM ABI changes are in mainline Linux
> already (just a few tweaks and cleanups remain).
> 
> xen: arm: implement XENMEM_add_to_physmap_range
> 
>         New hypercall intended for use by both ARM (Linux patches exist)
>         and x86 PVH (TBD)
>         
> xen/arm: grant table
> 
>         Simple wiring up job. Acked but depends on
>         XENMEM_add_to_physmap_range.
>         
> arm: tools: add arm to foreign structs checking
>         
>         Fixes native tools build on ARM
> 
> xen: xen_ulong_t substitution
> xen: change the limit of nr_extents to UINT_MAX >> MEMOP_EXTENT_SHIFT
> xen: introduce XEN_GUEST_HANDLE_PARAM
> xen: replace XEN_GUEST_HANDLE with XEN_GUEST_HANDLE_PARAM when appropriate
> xen: more XEN_GUEST_HANDLE_PARAM substitutions
> xen: remove XEN_GUEST_HANDLE(ulong)
> arm: parameter guest handles are 32 bit on 32 bit hypervisor
> 
>         These are the ARM 64 bit API, mostly from Stefano and posted
>         several times already.
>         
> Ian.
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 15:49:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 15:49:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNmuR-0000Nr-Ql; Mon, 15 Oct 2012 15:48:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNmuQ-0000Na-25
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 15:48:50 +0000
Received: from [85.158.137.99:62251] by server-9.bemta-3.messagelabs.com id
	05/32-16841-1603C705; Mon, 15 Oct 2012 15:48:49 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1350316128!21656416!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23240 invoked from network); 15 Oct 2012 15:48:48 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 15:48:48 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so3224708eek.32
	for ; Mon, 15 Oct 2012 08:48:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=CrC11lw4c+xQNT8DwHgXsVL260M6EOI3bCxzd/5zFhw=;
	b=wTvq7l7ROkTuTnIlWjt/0goIQhJspywZaerjD539u2Qw+14p50qj/IerbPjlFv7E1n
	9Up5FVgVOk4LZpI4NI5zbaFPhpKr7jf6VD4hl6Qc5F6O2hszAEo92HbvabvxCaaiBchf
	gZfP/G3H4y586V81LZwebg0yLSR5EhZfRl0KtqQcptyVh9oPR54sQNI8DKg01Cegcnb4
	2lMGPQL+wmtjjcM+CuBOa04xtwwPqS6uIwcn+0eyvorhQt10yrjE2m8dcSpQLdCzKwNI
	b4jLg6ZY4XXpmq1d25YxXRCPiVOI5Vvw9Z8HdMHuL26c1IsC54KGKZmUZhqsxL0v5+lr
	86lQ==
Received: by 10.14.209.129 with SMTP id s1mr16393743eeo.24.1350316128394;
	Mon, 15 Oct 2012 08:48:48 -0700 (PDT)
Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com.
	[86.183.156.141])
	by mx.google.com with ESMTPS id v3sm25598298een.1.2012.10.15.08.48.45
	(version=SSLv3 cipher=OTHER); Mon, 15 Oct 2012 08:48:46 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Mon, 15 Oct 2012 16:48:38 +0100
From: Keir Fraser 
To: Ian Campbell , xen-devel 
Message-ID: 
Thread-Topic: [PATCH v2 00/10] 64 bit ARM ABI, map foreign gmfn API, ARM grant
	tables
Thread-Index: Ac2q7Iq55xa7YN9YNkSOn30nYk56KA==
In-Reply-To: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Cc: Tim Deegan ,
	Stefano Stabellini ,
	Jan Beulich 
Subject: Re: [Xen-devel] [PATCH v2 00/10] 64 bit ARM ABI,
 map foreign gmfn API, ARM grant tables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 15/10/2012 16:20, "Ian Campbell"  wrote:

> This is v2 of "Sweep through arm-for-4.3 branch + a bit extra" retitled
> since most of the sweep through stuff has been swept through already and
> just the bit extra remains.
> 
> I've addressed the review comments and fixed the bisection issue. A
> bunch of this stuff is cross arch and/or touches common code.

Those bits are fine by me, now.

Acked-by: Keir Fraser 

> The Linux side of the 64 bit ARM ABI changes are in mainline Linux
> already (just a few tweaks and cleanups remain).
> 
> xen: arm: implement XENMEM_add_to_physmap_range
> 
>         New hypercall intended for use by both ARM (Linux patches exist)
>         and x86 PVH (TBD)
>         
> xen/arm: grant table
> 
>         Simple wiring up job. Acked but depends on
>         XENMEM_add_to_physmap_range.
>         
> arm: tools: add arm to foreign structs checking
>         
>         Fixes native tools build on ARM
> 
> xen: xen_ulong_t substitution
> xen: change the limit of nr_extents to UINT_MAX >> MEMOP_EXTENT_SHIFT
> xen: introduce XEN_GUEST_HANDLE_PARAM
> xen: replace XEN_GUEST_HANDLE with XEN_GUEST_HANDLE_PARAM when appropriate
> xen: more XEN_GUEST_HANDLE_PARAM substitutions
> xen: remove XEN_GUEST_HANDLE(ulong)
> arm: parameter guest handles are 32 bit on 32 bit hypervisor
> 
>         These are the ARM 64 bit API, mostly from Stefano and posted
>         several times already.
>         
> Ian.
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 15:54:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 15:54:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNmzR-0000np-Nj; Mon, 15 Oct 2012 15:54:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNmzQ-0000nL-Hh
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 15:54:00 +0000
Received: from [85.158.139.83:50197] by server-5.bemta-5.messagelabs.com id
	EC/59-09732-7913C705; Mon, 15 Oct 2012 15:53:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1350316438!29326163!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12322 invoked from network); 15 Oct 2012 15:53:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 15:53:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,588,1344211200"; d="scan'208";a="15175806"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 15:53:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 16:53:57 +0100
Message-ID: <1350316435.18058.80.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Andrew Cooper 
Date: Mon, 15 Oct 2012 16:53:55 +0100
In-Reply-To: <507C2EFE.8060806@citrix.com>
References: <952b1ef292469c9a9af5.1350314699@andrewcoop.uk.xensource.com>
	<1350315108.18058.73.camel@zakaz.uk.xensource.com>
	<507C2EFE.8060806@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] build/xenstore: Correct static link failure
	for xenstore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-10-15 at 16:42 +0100, Andrew Cooper wrote:
> On 15/10/12 16:31, Ian Campbell wrote:
> > On Mon, 2012-10-15 at 16:24 +0100, Andrew Cooper wrote:
> >> There is support for building xenstore clients statically.  However,
> >> recent changes to the makefiles have rendered the static build broken.
> >>
> >> tools/xenstore/Makefile sets LIBXENSTORE depending on whether
> >> XENSTORE_STATIC_CLIENTS is specified, but will unconditionally try to
> >> link against libxenstore.so by use of the LDLIBS_libxenstore variable.
> >>
> >> This patch doubles the logic already present to select the appropriate
> >> library target.
> >>
> >> Signed-off-by: Andrew Cooper 
> >>
> >> --
> >> This is a bit of a hack, but seems to be the only reliable way,
> >> espcially when linking with the LDLIBS_libxenstore variable in
> >> toos/misc.
> > I think it would be cleaner to define LDLIBS_libxenstore_static in
> > Rules.mk alongside the existing thing and make the appropriate selection
> > in the xenstore Makefile. That keeps the fugliness next to where it is
> > used.
> 
> But that then requires patching for *every* consumer of
> LDLIBS_libxenstore, which is a substantially larger and more invasive.

99% of them will continue to use LDLIBS_libxenstore, as they should.

The only place it needs to use LDLIBS_libxenstore_static is when
building the xenstore command line tools in tools/xenstore/Makefile.
Perhaps init-xenstore-domain and xenstore-control need it to, but that
shiould be all

However taking  a step back I think the underlying bug here is actually
the use of $(LDLIBS_libxenstore) where we should be using $(LIBXENSTORE)
when linking and not just as a dependency.

Ian.


> 
> ~Andrew
> 
> >
> >> diff -r 099589002239 -r 952b1ef29246 tools/Rules.mk
> >> --- a/tools/Rules.mk
> >> +++ b/tools/Rules.mk
> >> @@ -28,7 +28,11 @@ LDLIBS_libxenguest = $(XEN_LIBXC)/libxen
> >>  SHLIB_libxenguest  = -Wl,-rpath-link=L$(XEN_LIBXC)
> >>  
> >>  CFLAGS_libxenstore = -I$(XEN_XENSTORE) $(CFLAGS_xeninclude)
> >> +ifneq ($(XENSTORE_STATIC_CLIENTS),y)
> >>  LDLIBS_libxenstore = $(XEN_XENSTORE)/libxenstore.so
> >> +else
> >> +LDLIBS_libxenstore = $(XEN_XENSTORE)/libxenstore.a
> >> +endif
> >>  SHLIB_libxenstore  = -Wl,-rpath-link=$(XEN_XENSTORE)
> >>  
> >>  CFLAGS_libxenstat  = -I$(XEN_LIBXENSTAT)
> >
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 15:54:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 15:54:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNmzR-0000np-Nj; Mon, 15 Oct 2012 15:54:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNmzQ-0000nL-Hh
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 15:54:00 +0000
Received: from [85.158.139.83:50197] by server-5.bemta-5.messagelabs.com id
	EC/59-09732-7913C705; Mon, 15 Oct 2012 15:53:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1350316438!29326163!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12322 invoked from network); 15 Oct 2012 15:53:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 15:53:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,588,1344211200"; d="scan'208";a="15175806"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 15:53:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 16:53:57 +0100
Message-ID: <1350316435.18058.80.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Andrew Cooper 
Date: Mon, 15 Oct 2012 16:53:55 +0100
In-Reply-To: <507C2EFE.8060806@citrix.com>
References: <952b1ef292469c9a9af5.1350314699@andrewcoop.uk.xensource.com>
	<1350315108.18058.73.camel@zakaz.uk.xensource.com>
	<507C2EFE.8060806@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] build/xenstore: Correct static link failure
	for xenstore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-10-15 at 16:42 +0100, Andrew Cooper wrote:
> On 15/10/12 16:31, Ian Campbell wrote:
> > On Mon, 2012-10-15 at 16:24 +0100, Andrew Cooper wrote:
> >> There is support for building xenstore clients statically.  However,
> >> recent changes to the makefiles have rendered the static build broken.
> >>
> >> tools/xenstore/Makefile sets LIBXENSTORE depending on whether
> >> XENSTORE_STATIC_CLIENTS is specified, but will unconditionally try to
> >> link against libxenstore.so by use of the LDLIBS_libxenstore variable.
> >>
> >> This patch doubles the logic already present to select the appropriate
> >> library target.
> >>
> >> Signed-off-by: Andrew Cooper 
> >>
> >> --
> >> This is a bit of a hack, but seems to be the only reliable way,
> >> espcially when linking with the LDLIBS_libxenstore variable in
> >> toos/misc.
> > I think it would be cleaner to define LDLIBS_libxenstore_static in
> > Rules.mk alongside the existing thing and make the appropriate selection
> > in the xenstore Makefile. That keeps the fugliness next to where it is
> > used.
> 
> But that then requires patching for *every* consumer of
> LDLIBS_libxenstore, which is a substantially larger and more invasive.

99% of them will continue to use LDLIBS_libxenstore, as they should.

The only place it needs to use LDLIBS_libxenstore_static is when
building the xenstore command line tools in tools/xenstore/Makefile.
Perhaps init-xenstore-domain and xenstore-control need it to, but that
shiould be all

However taking  a step back I think the underlying bug here is actually
the use of $(LDLIBS_libxenstore) where we should be using $(LIBXENSTORE)
when linking and not just as a dependency.

Ian.


> 
> ~Andrew
> 
> >
> >> diff -r 099589002239 -r 952b1ef29246 tools/Rules.mk
> >> --- a/tools/Rules.mk
> >> +++ b/tools/Rules.mk
> >> @@ -28,7 +28,11 @@ LDLIBS_libxenguest = $(XEN_LIBXC)/libxen
> >>  SHLIB_libxenguest  = -Wl,-rpath-link=L$(XEN_LIBXC)
> >>  
> >>  CFLAGS_libxenstore = -I$(XEN_XENSTORE) $(CFLAGS_xeninclude)
> >> +ifneq ($(XENSTORE_STATIC_CLIENTS),y)
> >>  LDLIBS_libxenstore = $(XEN_XENSTORE)/libxenstore.so
> >> +else
> >> +LDLIBS_libxenstore = $(XEN_XENSTORE)/libxenstore.a
> >> +endif
> >>  SHLIB_libxenstore  = -Wl,-rpath-link=$(XEN_XENSTORE)
> >>  
> >>  CFLAGS_libxenstat  = -I$(XEN_LIBXENSTAT)
> >
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 16:06:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 16:06:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNnAu-0001dg-1e; Mon, 15 Oct 2012 16:05:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNnAt-0001dT-2w
	for xen-devel@lists.xensource.com; Mon, 15 Oct 2012 16:05:51 +0000
Received: from [85.158.138.51:37416] by server-14.bemta-3.messagelabs.com id
	07/67-17276-E543C705; Mon, 15 Oct 2012 16:05:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1350317149!32770946!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11338 invoked from network); 15 Oct 2012 16:05:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 16:05:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,588,1344211200"; d="scan'208";a="15176099"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 16:05:48 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 17:05:48 +0100
Message-ID: <1350317146.18058.83.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Mon, 15 Oct 2012 17:05:46 +0100
In-Reply-To: <1349890849-17471-2-git-send-email-konrad.wilk@oracle.com>
References: <1349890849-17471-1-git-send-email-konrad.wilk@oracle.com>
	<1349890849-17471-2-git-send-email-konrad.wilk@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Olaf Hering ,
	"xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	"stable@vger.kernel.org" 
Subject: Re: [Xen-devel] [PATCH 1/3] xen/pv-on-hvm kexec: add quirk for Xen
 3.4 and shutdown watches.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-10 at 18:40 +0100, Konrad Rzeszutek Wilk wrote:
> The commit 254d1a3f02ebc10ccc6e4903394d8d3f484f715e, titled
> "xen/pv-on-hvm kexec: shutdown watches from old kernel" assumes that the
> XenBus backend can deal with reading of values from:
>  "control/platform-feature-xs_reset_watches":
> 
>     ... a patch for xenstored is required so that it
>     accepts the XS_RESET_WATCHES request from a client (see changeset
>     23839:42a45baf037d in xen-unstable.hg). Without the patch for xenstored
>     the registration of watches will fail and some features of a PVonHVM
>     guest are not available. The guest is still able to boot, but repeated
>     kexec boots will fail."
> 
> Sadly this is not true when using a Xen 3.4 hypervisor and booting a PVHVM
> guest. We end up hanging at:
> 
>   err = xenbus_scanf(XBT_NIL, "control",
>                         "platform-feature-xs_reset_watches", "%d", &supported);
> 
> This can easily be seen with guests hanging at xenbus_init:
> 
> NX (Execute Disable) protection: active
> SMBIOS 2.4 present.
> DMI: Xen HVM domU, BIOS 3.4.0 05/13/2011
> Hypervisor detected: Xen HVM
> Xen version 3.4.
> Xen Platform PCI: I/O protocol version 1
> ... snip ..
> calling  xenbus_init+0x0/0x27e @ 1
> 
> Reverting the commit or using the attached patch fixes the issue. This fix
> checks whether the hypervisor is older than 4.0 and if so does not try to
> perform the read.
> 
> Fixes-Oracle-Bug: 14708233
> CC: stable@vger.kernel.org
> CC: Olaf Hering 
> Signed-off-by: Konrad Rzeszutek Wilk 
> ---
>  drivers/xen/xenbus/xenbus_xs.c |   15 +++++++++++++++
>  1 files changed, 15 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
> index bce15cf..91f513b 100644
> --- a/drivers/xen/xenbus/xenbus_xs.c
> +++ b/drivers/xen/xenbus/xenbus_xs.c
> @@ -47,6 +47,7 @@
>  #include 
>  #include 
>  #include "xenbus_comms.h"
> +#include 
>  
>  struct xs_stored_msg {
>  	struct list_head list;
> @@ -617,7 +618,18 @@ static struct xenbus_watch *find_watch(const char *token)
>  
>  	return NULL;
>  }
> +static bool xen_strict_xenbus_quirk()
> +{
> +	uint32_t eax, ebx, ecx, edx, base;
> +
> +	base = xen_cpuid_base();
> +	cpuid(base + 1, &eax, &ebx, &ecx, &edx);

This breaks on ARM because this is an x86 specific function. Can we
ifdef it or properly wrap it in an arch interface please.

> +
> +	if ((eax >> 16) < 4)
> +		return true;
> +	return false;
>  
> +}
>  static void xs_reset_watches(void)
>  {
>  	int err, supported = 0;
> @@ -625,6 +637,9 @@ static void xs_reset_watches(void)
>  	if (!xen_hvm_domain())
>  		return;
>  
> +	if (xen_strict_xenbus_quirk())
> +		return;
> +
>  	err = xenbus_scanf(XBT_NIL, "control",
>  			"platform-feature-xs_reset_watches", "%d", &supported);
>  	if (err != 1 || !supported)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 16:06:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 16:06:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNnAu-0001dg-1e; Mon, 15 Oct 2012 16:05:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNnAt-0001dT-2w
	for xen-devel@lists.xensource.com; Mon, 15 Oct 2012 16:05:51 +0000
Received: from [85.158.138.51:37416] by server-14.bemta-3.messagelabs.com id
	07/67-17276-E543C705; Mon, 15 Oct 2012 16:05:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1350317149!32770946!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11338 invoked from network); 15 Oct 2012 16:05:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 16:05:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,588,1344211200"; d="scan'208";a="15176099"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 16:05:48 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 17:05:48 +0100
Message-ID: <1350317146.18058.83.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Mon, 15 Oct 2012 17:05:46 +0100
In-Reply-To: <1349890849-17471-2-git-send-email-konrad.wilk@oracle.com>
References: <1349890849-17471-1-git-send-email-konrad.wilk@oracle.com>
	<1349890849-17471-2-git-send-email-konrad.wilk@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Olaf Hering ,
	"xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	"stable@vger.kernel.org" 
Subject: Re: [Xen-devel] [PATCH 1/3] xen/pv-on-hvm kexec: add quirk for Xen
 3.4 and shutdown watches.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-10 at 18:40 +0100, Konrad Rzeszutek Wilk wrote:
> The commit 254d1a3f02ebc10ccc6e4903394d8d3f484f715e, titled
> "xen/pv-on-hvm kexec: shutdown watches from old kernel" assumes that the
> XenBus backend can deal with reading of values from:
>  "control/platform-feature-xs_reset_watches":
> 
>     ... a patch for xenstored is required so that it
>     accepts the XS_RESET_WATCHES request from a client (see changeset
>     23839:42a45baf037d in xen-unstable.hg). Without the patch for xenstored
>     the registration of watches will fail and some features of a PVonHVM
>     guest are not available. The guest is still able to boot, but repeated
>     kexec boots will fail."
> 
> Sadly this is not true when using a Xen 3.4 hypervisor and booting a PVHVM
> guest. We end up hanging at:
> 
>   err = xenbus_scanf(XBT_NIL, "control",
>                         "platform-feature-xs_reset_watches", "%d", &supported);
> 
> This can easily be seen with guests hanging at xenbus_init:
> 
> NX (Execute Disable) protection: active
> SMBIOS 2.4 present.
> DMI: Xen HVM domU, BIOS 3.4.0 05/13/2011
> Hypervisor detected: Xen HVM
> Xen version 3.4.
> Xen Platform PCI: I/O protocol version 1
> ... snip ..
> calling  xenbus_init+0x0/0x27e @ 1
> 
> Reverting the commit or using the attached patch fixes the issue. This fix
> checks whether the hypervisor is older than 4.0 and if so does not try to
> perform the read.
> 
> Fixes-Oracle-Bug: 14708233
> CC: stable@vger.kernel.org
> CC: Olaf Hering 
> Signed-off-by: Konrad Rzeszutek Wilk 
> ---
>  drivers/xen/xenbus/xenbus_xs.c |   15 +++++++++++++++
>  1 files changed, 15 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
> index bce15cf..91f513b 100644
> --- a/drivers/xen/xenbus/xenbus_xs.c
> +++ b/drivers/xen/xenbus/xenbus_xs.c
> @@ -47,6 +47,7 @@
>  #include 
>  #include 
>  #include "xenbus_comms.h"
> +#include 
>  
>  struct xs_stored_msg {
>  	struct list_head list;
> @@ -617,7 +618,18 @@ static struct xenbus_watch *find_watch(const char *token)
>  
>  	return NULL;
>  }
> +static bool xen_strict_xenbus_quirk()
> +{
> +	uint32_t eax, ebx, ecx, edx, base;
> +
> +	base = xen_cpuid_base();
> +	cpuid(base + 1, &eax, &ebx, &ecx, &edx);

This breaks on ARM because this is an x86 specific function. Can we
ifdef it or properly wrap it in an arch interface please.

> +
> +	if ((eax >> 16) < 4)
> +		return true;
> +	return false;
>  
> +}
>  static void xs_reset_watches(void)
>  {
>  	int err, supported = 0;
> @@ -625,6 +637,9 @@ static void xs_reset_watches(void)
>  	if (!xen_hvm_domain())
>  		return;
>  
> +	if (xen_strict_xenbus_quirk())
> +		return;
> +
>  	err = xenbus_scanf(XBT_NIL, "control",
>  			"platform-feature-xs_reset_watches", "%d", &supported);
>  	if (err != 1 || !supported)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 16:14:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 16:14:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNnJ9-0001pz-5L; Mon, 15 Oct 2012 16:14:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNnJ7-0001pu-OB
	for xen-devel@lists.xensource.com; Mon, 15 Oct 2012 16:14:21 +0000
Received: from [85.158.143.35:58163] by server-3.bemta-4.messagelabs.com id
	2C/0D-10075-D563C705; Mon, 15 Oct 2012 16:14:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1350317660!14437587!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26019 invoked from network); 15 Oct 2012 16:14:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 16:14:20 -0000
X-IronPort-AV: E=Sophos;i="4.80,588,1344211200"; d="scan'208";a="15176276"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 16:14:20 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 17:14:20 +0100
Message-ID: <1350317658.18058.84.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Mon, 15 Oct 2012 17:14:18 +0100
In-Reply-To: <1350317146.18058.83.camel@zakaz.uk.xensource.com>
References: <1349890849-17471-1-git-send-email-konrad.wilk@oracle.com>
	<1349890849-17471-2-git-send-email-konrad.wilk@oracle.com>
	<1350317146.18058.83.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Olaf Hering ,
	"xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	"stable@vger.kernel.org" 
Subject: Re: [Xen-devel] [PATCH 1/3] xen/pv-on-hvm kexec: add quirk for Xen
 3.4 and shutdown watches.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-10-15 at 17:05 +0100, Ian Campbell wrote:
> 
> > +static bool xen_strict_xenbus_quirk()
> > +{
> > +     uint32_t eax, ebx, ecx, edx, base;
> > +
> > +     base = xen_cpuid_base();
> > +     cpuid(base + 1, &eax, &ebx, &ecx, &edx);
> 
> This breaks on ARM because this is an x86 specific function. Can we
> ifdef it or properly wrap it in an arch interface please. 

Quick-n-dirty fix. 

8<----------------------------

>From fe19515d8f7bed49c4474f475e6a8cbbdc5eb3f2 Mon Sep 17 00:00:00 2001
From: Ian Campbell 
Date: Mon, 15 Oct 2012 17:06:47 +0100
Subject: [PATCH] xen: fix build on ARM

xen_strict_xenbus_quirk is x86 specific.

Signed-off-by: Ian Campbell 
---
 drivers/xen/xenbus/xenbus_xs.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
index 48220e1..b46ad11 100644
--- a/drivers/xen/xenbus/xenbus_xs.c
+++ b/drivers/xen/xenbus/xenbus_xs.c
@@ -619,6 +619,8 @@ static struct xenbus_watch *find_watch(const char *token)
 
 	return NULL;
 }
+
+#ifdef CONFIG_X86
 /*
  * Certain older XenBus toolstack cannot handle reading values that are
  * not populated. Some Xen 3.4 installation are incapable of doing this
@@ -637,6 +639,10 @@ static bool xen_strict_xenbus_quirk()
 	return false;
 
 }
+#else
+static bool xen_strict_xenbus_quirk(void) { return false; }
+#endif
+
 static void xs_reset_watches(void)
 {
 	int err, supported = 0;
-- 
1.7.2.5




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 16:14:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 16:14:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNnJ9-0001pz-5L; Mon, 15 Oct 2012 16:14:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNnJ7-0001pu-OB
	for xen-devel@lists.xensource.com; Mon, 15 Oct 2012 16:14:21 +0000
Received: from [85.158.143.35:58163] by server-3.bemta-4.messagelabs.com id
	2C/0D-10075-D563C705; Mon, 15 Oct 2012 16:14:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1350317660!14437587!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26019 invoked from network); 15 Oct 2012 16:14:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 16:14:20 -0000
X-IronPort-AV: E=Sophos;i="4.80,588,1344211200"; d="scan'208";a="15176276"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 16:14:20 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 17:14:20 +0100
Message-ID: <1350317658.18058.84.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Mon, 15 Oct 2012 17:14:18 +0100
In-Reply-To: <1350317146.18058.83.camel@zakaz.uk.xensource.com>
References: <1349890849-17471-1-git-send-email-konrad.wilk@oracle.com>
	<1349890849-17471-2-git-send-email-konrad.wilk@oracle.com>
	<1350317146.18058.83.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Olaf Hering ,
	"xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	"stable@vger.kernel.org" 
Subject: Re: [Xen-devel] [PATCH 1/3] xen/pv-on-hvm kexec: add quirk for Xen
 3.4 and shutdown watches.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-10-15 at 17:05 +0100, Ian Campbell wrote:
> 
> > +static bool xen_strict_xenbus_quirk()
> > +{
> > +     uint32_t eax, ebx, ecx, edx, base;
> > +
> > +     base = xen_cpuid_base();
> > +     cpuid(base + 1, &eax, &ebx, &ecx, &edx);
> 
> This breaks on ARM because this is an x86 specific function. Can we
> ifdef it or properly wrap it in an arch interface please. 

Quick-n-dirty fix. 

8<----------------------------

>From fe19515d8f7bed49c4474f475e6a8cbbdc5eb3f2 Mon Sep 17 00:00:00 2001
From: Ian Campbell 
Date: Mon, 15 Oct 2012 17:06:47 +0100
Subject: [PATCH] xen: fix build on ARM

xen_strict_xenbus_quirk is x86 specific.

Signed-off-by: Ian Campbell 
---
 drivers/xen/xenbus/xenbus_xs.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
index 48220e1..b46ad11 100644
--- a/drivers/xen/xenbus/xenbus_xs.c
+++ b/drivers/xen/xenbus/xenbus_xs.c
@@ -619,6 +619,8 @@ static struct xenbus_watch *find_watch(const char *token)
 
 	return NULL;
 }
+
+#ifdef CONFIG_X86
 /*
  * Certain older XenBus toolstack cannot handle reading values that are
  * not populated. Some Xen 3.4 installation are incapable of doing this
@@ -637,6 +639,10 @@ static bool xen_strict_xenbus_quirk()
 	return false;
 
 }
+#else
+static bool xen_strict_xenbus_quirk(void) { return false; }
+#endif
+
 static void xs_reset_watches(void)
 {
 	int err, supported = 0;
-- 
1.7.2.5




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 16:15:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 16:15:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNnKU-0001vZ-NQ; Mon, 15 Oct 2012 16:15:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNnKT-0001vS-RS
	for Xen-devel@lists.xensource.com; Mon, 15 Oct 2012 16:15:45 +0000
Received: from [85.158.139.83:5014] by server-7.bemta-5.messagelabs.com id
	55/D1-23102-1B63C705; Mon, 15 Oct 2012 16:15:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1350317744!30987347!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1292 invoked from network); 15 Oct 2012 16:15:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 16:15:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,588,1344211200"; d="scan'208";a="15176303"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 16:15:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 17:15:44 +0100
Message-ID: <1350317743.18058.85.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Mukesh Rathor 
Date: Mon, 15 Oct 2012 17:15:43 +0100
In-Reply-To: <20121011144929.06e71a9e@mantra.us.oracle.com>
References: <20121011144929.06e71a9e@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V2 0/7]: PVH: PV guest with extensions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-11 at 22:49 +0100, Mukesh Rathor wrote:
> Hi guys,
> 
> Ok, I've made all the changes from prev RFC patch submissions. Tested
> all the combinations. The patches are organized slightly differently
> from prev version because of the nature of changes after last review. I
> am building xen patch just for the corresponding header file changes.
> Following that I'll refresh xen tree, debug, test, and send patches.
> 
> For linux kernel mailing list introduction, PVH is a PV guest that can
> run in an HVM container, uses native pagetables, uses callback vector,
> native IDT, and native syscalls.
> 
> They were built on top of 89d0307af2b9957d59bfb2a86aaa57464ff921de
> commit.

Are they in a git branch anywhere?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 16:15:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 16:15:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNnKU-0001vZ-NQ; Mon, 15 Oct 2012 16:15:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNnKT-0001vS-RS
	for Xen-devel@lists.xensource.com; Mon, 15 Oct 2012 16:15:45 +0000
Received: from [85.158.139.83:5014] by server-7.bemta-5.messagelabs.com id
	55/D1-23102-1B63C705; Mon, 15 Oct 2012 16:15:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1350317744!30987347!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1292 invoked from network); 15 Oct 2012 16:15:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 16:15:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,588,1344211200"; d="scan'208";a="15176303"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 16:15:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 15 Oct 2012 17:15:44 +0100
Message-ID: <1350317743.18058.85.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Mukesh Rathor 
Date: Mon, 15 Oct 2012 17:15:43 +0100
In-Reply-To: <20121011144929.06e71a9e@mantra.us.oracle.com>
References: <20121011144929.06e71a9e@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V2 0/7]: PVH: PV guest with extensions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-11 at 22:49 +0100, Mukesh Rathor wrote:
> Hi guys,
> 
> Ok, I've made all the changes from prev RFC patch submissions. Tested
> all the combinations. The patches are organized slightly differently
> from prev version because of the nature of changes after last review. I
> am building xen patch just for the corresponding header file changes.
> Following that I'll refresh xen tree, debug, test, and send patches.
> 
> For linux kernel mailing list introduction, PVH is a PV guest that can
> run in an HVM container, uses native pagetables, uses callback vector,
> native IDT, and native syscalls.
> 
> They were built on top of 89d0307af2b9957d59bfb2a86aaa57464ff921de
> commit.

Are they in a git branch anywhere?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 16:19:23 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 16:19:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNnNo-0002AI-B5; Mon, 15 Oct 2012 16:19:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNnNn-0002AD-4Q
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 16:19:11 +0000
Received: from [85.158.143.35:16611] by server-1.bemta-4.messagelabs.com id
	53/2A-19551-E773C705; Mon, 15 Oct 2012 16:19:10 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1350317946!14439761!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3804 invoked from network); 15 Oct 2012 16:19:07 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 16:19:07 -0000
Received: by mail-vc0-f173.google.com with SMTP id fl15so7479886vcb.32
	for ; Mon, 15 Oct 2012 09:19:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:date:x-google-sender-auth:message-id:subject
	:from:to:content-type;
	bh=bYnR00Po6TyjD+BdBzb0uEEZ/jZUnkTV1Sf+IHWwYgM=;
	b=XUFwx+e9bb8Eo7LUvO68ZsthF0B7OY7USRToMR0BVukdGkW1guUePnoaCM+qjefLnu
	mxdOEp+d1q0KJvhvZZX6vdoUmD1mAMUnfIZ4JXaGOvYFP5WdzoNSncb/8N14SJguWes7
	FHY6KPUi945cQhzo2Br9NYXV47RkdSPt+H+eWLZcTqcTf1a8uqxKz9jFIAOMfgWv3TKE
	AtSCcerwe7zNhYamBCdD/kXmH7ic5p897gO6oOHgNBIMDexo59NL7svqrOBWT+e6B3Rm
	UnUX3qQYEtf6rRojYZ3sDAjPK/02px1RQa+VpTi/CzZ521qtvK0K2Q5nZLLxLwi96wMk
	VQPA==
MIME-Version: 1.0
Received: by 10.52.71.9 with SMTP id q9mr5673625vdu.36.1350317945901; Mon, 15
	Oct 2012 09:19:05 -0700 (PDT)
Received: by 10.58.231.138 with HTTP; Mon, 15 Oct 2012 09:19:05 -0700 (PDT)
Date: Mon, 15 Oct 2012 17:19:05 +0100
X-Google-Sender-Auth: ywCZMan_3JhYLuCc1FH6HfASYWM
Message-ID: 
From: George Dunlap 
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Xen 4.3 development update, 15 Oct
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This information will be mirrored on the Xen 4.3 Roadmap wiki page:
 http://wiki.xen.org/wiki/Xen_Roadmap/4.3

= Timeline =

We are planning on a 9-month release cycle.  Based on that, below are
our estimated dates:
* Feature Freeze: 25 March 2013
* First RC: 6 May 2013
* Release: 17 June 2013

The RCs and release will of course depend on stability and bugs, and
will therefore be fairly unpredictable.  The feature freeze may be
slipped for especially important features which are near completion.

= Feature tracking =

Below is a list of features we're tracking for this release. Please
respond to this mail with any updates to the status.

There are a number of items whose owners are marked as "?".  If you
are working on this, or know who is working on it, please respond and
let me know.  Alternately, if you would *like* to work on it, please
let me know as well.

And if there is something you're working on you'd like tracked, please
respond, and I will add it to the list.

NB: Several of the items on this list are from external projects:
linux, qemu, and libvirt.  These are not part of the Xen tree, but are
directly related to our users' experience (e.g., work in Linux or
qemu) or to integration with other important projects (e.g., libvirt
bindings).  Since all of these are part of the Xen community work, and
comes from the same pool of labor, it makes sense to track the
progress here, even though they won't explicitly be released as part
of 4.3.

== Completed ==

* Linux console improvements
  -EHCI debug port

* Default to QEMU upstream (partial)
 - pci pass-thru (external)
 - enable dirtybit tracking during migration (external)

* CPUID-based idle (don't rely on ACPI info f/ dom0)

== Bugs ==

* xl, compat mode, and older kernels
  owner: ?
  Many older 32-bit PV kernels that can run on a 64-bit hypervisor with
  xend do not work when started with xl.  The following work-around seems to
  work:
    xl create -p lightning.cfg
    xenstore-write /local/domain/$(xl domid
lightning)/device/vbd/51713/protocol x86_32-abi
    xl unpause lightning
  This node is normally written by the guest kernel, but for older kernels
  seems not to be.  xend must have a work-around; port this work-around to xl.

== Not yet complete ==

* PVH mode (w/ Linux)
  owner: mukesh@oracle
  Linux: 3rd draft patches posted.
  Xen: Patches being cleaned up for submission

* Event channel scalability
  owner: attilio@citrix
  status: initial design proposed
  Increase limit on event channels (currently 1024 for 32-bit guests,
  4096 for 64-bit guests)

* ARM server port
  owner: ijc@citrix
  status: Core hypervisor patches accepted; Linux paches pending

* NUMA scheduler affinity
  critical
  owner: dario@citrix
  status: Patches posted

* NUMA Memory migration
  owner: dario@citrix
  status: ?

* blktap3
  owner: thanos@citrix
  status: in progress

* Default to QEMU upstream
 - qemu-based stubdom (Linux or BSD libc)
   owner: anthony@citrix
   status: in progress
   qemu-upstream needs a more fully-featured libc than exists in
   mini-os.  Either work on a minimalist linux-based stubdom with
   glibc, or port one of the BSD libcs to minios.

 - xl cd-{insert,eject} (external)
   status: intilal implementation submitted

* Persistent grants (external)
  owner: roger.pau@citrix
  status: Initial implementation posted

* Multi-page blk rings (external)
 - blkback in kernel (konrad@oracle, ?@intel)
 - qemu blkback
  status: ?

* Multi-page net protocol (external)
  owner: ijc@citrix or annie.li@oracle
  status: Initial patches posted (by Wei Liu)
  expand the network ring protocol to allow multiple pages for
  increased throughput

* Scalability: 16TiB of RAM
  owner: jan@suse
  status: Not started

* vTPM updates
  owner: Matthew Fioravante @ Johns Hopkins
  status: v2 patches submitted
  - Allow all vTPM components to run in stub domains for increased security
  - Update vtpm to 0.7.1 from 0.5.x

* libvirt/libxl integration (external)
 - Migration
   owner: cyliu@suse (?)
   status: first draft implemented, not yet submitted
 - Itemize other things that need work
   To begin with, we need someone to go and make some lists:
   - Features available in libvirt/KVM not available in libvirt/libxl
     See http://libvirt.org/hvsupport.html
   - Features available in xl/Xen but not available in libvirt/Xen

* V4V: Inter-domain communication
  owner (Xen): jean.guyader@citrix.com
  status (Xen): patches submitted
  owner (Linux driver):  stefano.panella@citrix
  status (Linux driver): in progress

* Wait queues for mm (NEW)
  owner: ?
  status: Draft posted Feb 2012; more work to do.

* xl vm-{export,import}
  owner: ?
  status: ?
  Allow xl to import and export VMs to other formats; particularly
  ovf, perhaps the XenServer format, or more.

* xl PVUSB pass-through for both PV and HVM guests
  owner: ?
  status: ?
  xm/xend supports PVUSB pass-through to guests with PVUSB drivers
(both PV and HVM guests).
  - port the xm/xend functionality to xl.
  - this PVUSB feature does not require support or emulation from Qemu.
  - upstream the Linux frontend/backend drivers. Current
work-in-progress versions are in Konrad's git tree.
  - James Harper's GPLPV drivers for Windows include PVUSB frontend drivers.

* xl USB pass-through for HVM guests using Qemu USB emulation
  owner: ?
  status: ?
  xm/xend with qemu-traditional supports USB passthrough to HVM guests
using the Qemu emulated USB controller.
  The HVM guest does not need any special drivers for this feature.
  So basicly the qemu cmdline needs to have:
     -usb -usbdevice host:xxxx:yyyy
  - port the xm/xend functionality to xl.
  - make sure USB passthrough with xl works with both qemu-traditional
and qemu-upstream.

* xl QXL Spice support (NEW)
  owner: Zhou Peng
  status: Patches against 4.2-unstable posted, need refresh & resubmit

* openvswitch toostack integration
  owner: roger@citrix
  status: Sample script posted by Bastian ("[RFC] openvswitch support script")

* Rationalized backend scripts (incl. driver domains)
  owner: roger@citrix
  status: ?

* Linux console improvements
  owner: ?
  status: Stalled (see below)
  -xHCI debug port (Needs hardware)
  -Firewire (needs hardware)

* Remove hardcoded mobprobe's in xencommons
  owner: ?
  status: ?

* Make storage migration possible
  owner: ?
  status: ?
  There needs to be a way, either via command-line or via some hooks,
  that someone can build a "storage migration" feature on top of libxl
  or xl.

* Full-VM snapshotting
  owner: ?
  status: ?
  Have a way of coordinating the taking and restoring of VM memory and
  disk snapshots.  This would involve some investigation into the best
  way to accomplish this.

* VM Cloning
  owner: ?
  status: May need review
  Again, a way of coordinating the memory and disk aspects.  Research
  into the best way to do this would probably go along with the
  snapshotting feature.

* Memory: Replace PoD with paging mechanism
  owner: george@citrix
  status: May need review

* PV audio (audio for stubdom qemu)
  owner: stefano.panella@citrix
  status: ?

* Managed domains?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 16:19:23 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 16:19:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNnNo-0002AI-B5; Mon, 15 Oct 2012 16:19:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNnNn-0002AD-4Q
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 16:19:11 +0000
Received: from [85.158.143.35:16611] by server-1.bemta-4.messagelabs.com id
	53/2A-19551-E773C705; Mon, 15 Oct 2012 16:19:10 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1350317946!14439761!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3804 invoked from network); 15 Oct 2012 16:19:07 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 16:19:07 -0000
Received: by mail-vc0-f173.google.com with SMTP id fl15so7479886vcb.32
	for ; Mon, 15 Oct 2012 09:19:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:date:x-google-sender-auth:message-id:subject
	:from:to:content-type;
	bh=bYnR00Po6TyjD+BdBzb0uEEZ/jZUnkTV1Sf+IHWwYgM=;
	b=XUFwx+e9bb8Eo7LUvO68ZsthF0B7OY7USRToMR0BVukdGkW1guUePnoaCM+qjefLnu
	mxdOEp+d1q0KJvhvZZX6vdoUmD1mAMUnfIZ4JXaGOvYFP5WdzoNSncb/8N14SJguWes7
	FHY6KPUi945cQhzo2Br9NYXV47RkdSPt+H+eWLZcTqcTf1a8uqxKz9jFIAOMfgWv3TKE
	AtSCcerwe7zNhYamBCdD/kXmH7ic5p897gO6oOHgNBIMDexo59NL7svqrOBWT+e6B3Rm
	UnUX3qQYEtf6rRojYZ3sDAjPK/02px1RQa+VpTi/CzZ521qtvK0K2Q5nZLLxLwi96wMk
	VQPA==
MIME-Version: 1.0
Received: by 10.52.71.9 with SMTP id q9mr5673625vdu.36.1350317945901; Mon, 15
	Oct 2012 09:19:05 -0700 (PDT)
Received: by 10.58.231.138 with HTTP; Mon, 15 Oct 2012 09:19:05 -0700 (PDT)
Date: Mon, 15 Oct 2012 17:19:05 +0100
X-Google-Sender-Auth: ywCZMan_3JhYLuCc1FH6HfASYWM
Message-ID: 
From: George Dunlap 
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Xen 4.3 development update, 15 Oct
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This information will be mirrored on the Xen 4.3 Roadmap wiki page:
 http://wiki.xen.org/wiki/Xen_Roadmap/4.3

= Timeline =

We are planning on a 9-month release cycle.  Based on that, below are
our estimated dates:
* Feature Freeze: 25 March 2013
* First RC: 6 May 2013
* Release: 17 June 2013

The RCs and release will of course depend on stability and bugs, and
will therefore be fairly unpredictable.  The feature freeze may be
slipped for especially important features which are near completion.

= Feature tracking =

Below is a list of features we're tracking for this release. Please
respond to this mail with any updates to the status.

There are a number of items whose owners are marked as "?".  If you
are working on this, or know who is working on it, please respond and
let me know.  Alternately, if you would *like* to work on it, please
let me know as well.

And if there is something you're working on you'd like tracked, please
respond, and I will add it to the list.

NB: Several of the items on this list are from external projects:
linux, qemu, and libvirt.  These are not part of the Xen tree, but are
directly related to our users' experience (e.g., work in Linux or
qemu) or to integration with other important projects (e.g., libvirt
bindings).  Since all of these are part of the Xen community work, and
comes from the same pool of labor, it makes sense to track the
progress here, even though they won't explicitly be released as part
of 4.3.

== Completed ==

* Linux console improvements
  -EHCI debug port

* Default to QEMU upstream (partial)
 - pci pass-thru (external)
 - enable dirtybit tracking during migration (external)

* CPUID-based idle (don't rely on ACPI info f/ dom0)

== Bugs ==

* xl, compat mode, and older kernels
  owner: ?
  Many older 32-bit PV kernels that can run on a 64-bit hypervisor with
  xend do not work when started with xl.  The following work-around seems to
  work:
    xl create -p lightning.cfg
    xenstore-write /local/domain/$(xl domid
lightning)/device/vbd/51713/protocol x86_32-abi
    xl unpause lightning
  This node is normally written by the guest kernel, but for older kernels
  seems not to be.  xend must have a work-around; port this work-around to xl.

== Not yet complete ==

* PVH mode (w/ Linux)
  owner: mukesh@oracle
  Linux: 3rd draft patches posted.
  Xen: Patches being cleaned up for submission

* Event channel scalability
  owner: attilio@citrix
  status: initial design proposed
  Increase limit on event channels (currently 1024 for 32-bit guests,
  4096 for 64-bit guests)

* ARM server port
  owner: ijc@citrix
  status: Core hypervisor patches accepted; Linux paches pending

* NUMA scheduler affinity
  critical
  owner: dario@citrix
  status: Patches posted

* NUMA Memory migration
  owner: dario@citrix
  status: ?

* blktap3
  owner: thanos@citrix
  status: in progress

* Default to QEMU upstream
 - qemu-based stubdom (Linux or BSD libc)
   owner: anthony@citrix
   status: in progress
   qemu-upstream needs a more fully-featured libc than exists in
   mini-os.  Either work on a minimalist linux-based stubdom with
   glibc, or port one of the BSD libcs to minios.

 - xl cd-{insert,eject} (external)
   status: intilal implementation submitted

* Persistent grants (external)
  owner: roger.pau@citrix
  status: Initial implementation posted

* Multi-page blk rings (external)
 - blkback in kernel (konrad@oracle, ?@intel)
 - qemu blkback
  status: ?

* Multi-page net protocol (external)
  owner: ijc@citrix or annie.li@oracle
  status: Initial patches posted (by Wei Liu)
  expand the network ring protocol to allow multiple pages for
  increased throughput

* Scalability: 16TiB of RAM
  owner: jan@suse
  status: Not started

* vTPM updates
  owner: Matthew Fioravante @ Johns Hopkins
  status: v2 patches submitted
  - Allow all vTPM components to run in stub domains for increased security
  - Update vtpm to 0.7.1 from 0.5.x

* libvirt/libxl integration (external)
 - Migration
   owner: cyliu@suse (?)
   status: first draft implemented, not yet submitted
 - Itemize other things that need work
   To begin with, we need someone to go and make some lists:
   - Features available in libvirt/KVM not available in libvirt/libxl
     See http://libvirt.org/hvsupport.html
   - Features available in xl/Xen but not available in libvirt/Xen

* V4V: Inter-domain communication
  owner (Xen): jean.guyader@citrix.com
  status (Xen): patches submitted
  owner (Linux driver):  stefano.panella@citrix
  status (Linux driver): in progress

* Wait queues for mm (NEW)
  owner: ?
  status: Draft posted Feb 2012; more work to do.

* xl vm-{export,import}
  owner: ?
  status: ?
  Allow xl to import and export VMs to other formats; particularly
  ovf, perhaps the XenServer format, or more.

* xl PVUSB pass-through for both PV and HVM guests
  owner: ?
  status: ?
  xm/xend supports PVUSB pass-through to guests with PVUSB drivers
(both PV and HVM guests).
  - port the xm/xend functionality to xl.
  - this PVUSB feature does not require support or emulation from Qemu.
  - upstream the Linux frontend/backend drivers. Current
work-in-progress versions are in Konrad's git tree.
  - James Harper's GPLPV drivers for Windows include PVUSB frontend drivers.

* xl USB pass-through for HVM guests using Qemu USB emulation
  owner: ?
  status: ?
  xm/xend with qemu-traditional supports USB passthrough to HVM guests
using the Qemu emulated USB controller.
  The HVM guest does not need any special drivers for this feature.
  So basicly the qemu cmdline needs to have:
     -usb -usbdevice host:xxxx:yyyy
  - port the xm/xend functionality to xl.
  - make sure USB passthrough with xl works with both qemu-traditional
and qemu-upstream.

* xl QXL Spice support (NEW)
  owner: Zhou Peng
  status: Patches against 4.2-unstable posted, need refresh & resubmit

* openvswitch toostack integration
  owner: roger@citrix
  status: Sample script posted by Bastian ("[RFC] openvswitch support script")

* Rationalized backend scripts (incl. driver domains)
  owner: roger@citrix
  status: ?

* Linux console improvements
  owner: ?
  status: Stalled (see below)
  -xHCI debug port (Needs hardware)
  -Firewire (needs hardware)

* Remove hardcoded mobprobe's in xencommons
  owner: ?
  status: ?

* Make storage migration possible
  owner: ?
  status: ?
  There needs to be a way, either via command-line or via some hooks,
  that someone can build a "storage migration" feature on top of libxl
  or xl.

* Full-VM snapshotting
  owner: ?
  status: ?
  Have a way of coordinating the taking and restoring of VM memory and
  disk snapshots.  This would involve some investigation into the best
  way to accomplish this.

* VM Cloning
  owner: ?
  status: May need review
  Again, a way of coordinating the memory and disk aspects.  Research
  into the best way to do this would probably go along with the
  snapshotting feature.

* Memory: Replace PoD with paging mechanism
  owner: george@citrix
  status: May need review

* PV audio (audio for stubdom qemu)
  owner: stefano.panella@citrix
  status: ?

* Managed domains?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 16:21:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 16:21:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNnPs-0002HY-Rt; Mon, 15 Oct 2012 16:21:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNnPr-0002HQ-IO
	for xen-devel@lists.xensource.com; Mon, 15 Oct 2012 16:21:19 +0000
Received: from [85.158.139.83:35597] by server-2.bemta-5.messagelabs.com id
	02/B7-10520-EF73C705; Mon, 15 Oct 2012 16:21:18 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1350318076!29330103!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgxMDc2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19060 invoked from network); 15 Oct 2012 16:21:18 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Oct 2012 16:21:18 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9FGLCDt008318
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 15 Oct 2012 16:21:12 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9FGLA0T005343
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 15 Oct 2012 16:21:11 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9FGLAJI005415; Mon, 15 Oct 2012 11:21:10 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 15 Oct 2012 09:21:10 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E92A4402A8; Mon, 15 Oct 2012 12:09:12 -0400 (EDT)
Date: Mon, 15 Oct 2012 12:09:12 -0400
From: Konrad Rzeszutek Wilk 
To: Ian Campbell 
Message-ID: <20121015160912.GA26765@phenom.dumpdata.com>
References: <1349890849-17471-1-git-send-email-konrad.wilk@oracle.com>
	<1349890849-17471-2-git-send-email-konrad.wilk@oracle.com>
	<1350317146.18058.83.camel@zakaz.uk.xensource.com>
	<1350317658.18058.84.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1350317658.18058.84.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Olaf Hering ,
	"xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	"stable@vger.kernel.org" 
Subject: Re: [Xen-devel] [PATCH 1/3] xen/pv-on-hvm kexec: add quirk for Xen
 3.4 and shutdown watches.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 15, 2012 at 05:14:18PM +0100, Ian Campbell wrote:
> On Mon, 2012-10-15 at 17:05 +0100, Ian Campbell wrote:
> > 
> > > +static bool xen_strict_xenbus_quirk()
> > > +{
> > > +     uint32_t eax, ebx, ecx, edx, base;
> > > +
> > > +     base = xen_cpuid_base();
> > > +     cpuid(base + 1, &eax, &ebx, &ecx, &edx);
> > 
> > This breaks on ARM because this is an x86 specific function. Can we
> > ifdef it or properly wrap it in an arch interface please. 
> 
> Quick-n-dirty fix. 

applied. Thx
> 
> 8<----------------------------
> 
> >From fe19515d8f7bed49c4474f475e6a8cbbdc5eb3f2 Mon Sep 17 00:00:00 2001
> From: Ian Campbell 
> Date: Mon, 15 Oct 2012 17:06:47 +0100
> Subject: [PATCH] xen: fix build on ARM
> 
> xen_strict_xenbus_quirk is x86 specific.
> 
> Signed-off-by: Ian Campbell 
> ---
>  drivers/xen/xenbus/xenbus_xs.c |    6 ++++++
>  1 files changed, 6 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
> index 48220e1..b46ad11 100644
> --- a/drivers/xen/xenbus/xenbus_xs.c
> +++ b/drivers/xen/xenbus/xenbus_xs.c
> @@ -619,6 +619,8 @@ static struct xenbus_watch *find_watch(const char *token)
>  
>  	return NULL;
>  }
> +
> +#ifdef CONFIG_X86
>  /*
>   * Certain older XenBus toolstack cannot handle reading values that are
>   * not populated. Some Xen 3.4 installation are incapable of doing this
> @@ -637,6 +639,10 @@ static bool xen_strict_xenbus_quirk()
>  	return false;
>  
>  }
> +#else
> +static bool xen_strict_xenbus_quirk(void) { return false; }
> +#endif
> +
>  static void xs_reset_watches(void)
>  {
>  	int err, supported = 0;
> -- 
> 1.7.2.5
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 16:21:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 16:21:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNnPs-0002HY-Rt; Mon, 15 Oct 2012 16:21:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNnPr-0002HQ-IO
	for xen-devel@lists.xensource.com; Mon, 15 Oct 2012 16:21:19 +0000
Received: from [85.158.139.83:35597] by server-2.bemta-5.messagelabs.com id
	02/B7-10520-EF73C705; Mon, 15 Oct 2012 16:21:18 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1350318076!29330103!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgxMDc2Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19060 invoked from network); 15 Oct 2012 16:21:18 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Oct 2012 16:21:18 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9FGLCDt008318
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 15 Oct 2012 16:21:12 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9FGLA0T005343
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 15 Oct 2012 16:21:11 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9FGLAJI005415; Mon, 15 Oct 2012 11:21:10 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 15 Oct 2012 09:21:10 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E92A4402A8; Mon, 15 Oct 2012 12:09:12 -0400 (EDT)
Date: Mon, 15 Oct 2012 12:09:12 -0400
From: Konrad Rzeszutek Wilk 
To: Ian Campbell 
Message-ID: <20121015160912.GA26765@phenom.dumpdata.com>
References: <1349890849-17471-1-git-send-email-konrad.wilk@oracle.com>
	<1349890849-17471-2-git-send-email-konrad.wilk@oracle.com>
	<1350317146.18058.83.camel@zakaz.uk.xensource.com>
	<1350317658.18058.84.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1350317658.18058.84.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Olaf Hering ,
	"xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	"stable@vger.kernel.org" 
Subject: Re: [Xen-devel] [PATCH 1/3] xen/pv-on-hvm kexec: add quirk for Xen
 3.4 and shutdown watches.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 15, 2012 at 05:14:18PM +0100, Ian Campbell wrote:
> On Mon, 2012-10-15 at 17:05 +0100, Ian Campbell wrote:
> > 
> > > +static bool xen_strict_xenbus_quirk()
> > > +{
> > > +     uint32_t eax, ebx, ecx, edx, base;
> > > +
> > > +     base = xen_cpuid_base();
> > > +     cpuid(base + 1, &eax, &ebx, &ecx, &edx);
> > 
> > This breaks on ARM because this is an x86 specific function. Can we
> > ifdef it or properly wrap it in an arch interface please. 
> 
> Quick-n-dirty fix. 

applied. Thx
> 
> 8<----------------------------
> 
> >From fe19515d8f7bed49c4474f475e6a8cbbdc5eb3f2 Mon Sep 17 00:00:00 2001
> From: Ian Campbell 
> Date: Mon, 15 Oct 2012 17:06:47 +0100
> Subject: [PATCH] xen: fix build on ARM
> 
> xen_strict_xenbus_quirk is x86 specific.
> 
> Signed-off-by: Ian Campbell 
> ---
>  drivers/xen/xenbus/xenbus_xs.c |    6 ++++++
>  1 files changed, 6 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
> index 48220e1..b46ad11 100644
> --- a/drivers/xen/xenbus/xenbus_xs.c
> +++ b/drivers/xen/xenbus/xenbus_xs.c
> @@ -619,6 +619,8 @@ static struct xenbus_watch *find_watch(const char *token)
>  
>  	return NULL;
>  }
> +
> +#ifdef CONFIG_X86
>  /*
>   * Certain older XenBus toolstack cannot handle reading values that are
>   * not populated. Some Xen 3.4 installation are incapable of doing this
> @@ -637,6 +639,10 @@ static bool xen_strict_xenbus_quirk()
>  	return false;
>  
>  }
> +#else
> +static bool xen_strict_xenbus_quirk(void) { return false; }
> +#endif
> +
>  static void xs_reset_watches(void)
>  {
>  	int err, supported = 0;
> -- 
> 1.7.2.5
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 16:51:22 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 16:51:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNnsY-0003Ky-MV; Mon, 15 Oct 2012 16:50:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNnsW-0003Kt-Lu
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 16:50:56 +0000
Received: from [85.158.143.99:15071] by server-1.bemta-4.messagelabs.com id
	B0/75-19551-FEE3C705; Mon, 15 Oct 2012 16:50:55 +0000
X-Env-Sender: gaumless@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1350319854!27197217!1
X-Originating-IP: [209.85.210.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5329 invoked from network); 15 Oct 2012 16:50:55 -0000
Received: from mail-ia0-f173.google.com (HELO mail-ia0-f173.google.com)
	(209.85.210.173)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 16:50:55 -0000
Received: by mail-ia0-f173.google.com with SMTP id m10so4828962iam.32
	for ; Mon, 15 Oct 2012 09:50:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:subject
	:content-type:content-transfer-encoding;
	bh=hWii4NjECm5wskSOZdbwa8Q+X85oY0YpemdYT/ynzX8=;
	b=iElchbob4rFLwDUV1aYFpv/ITfubvuOeZaBnZvCioT4AOGGmFVEtlZ5TVYY4uQieNl
	KpUUiqzlH9yPyrhVKeuRwklmrZpLMtP2xrZ7u2m031kbtADeVXOPHFjN+1jmu6UlP0WT
	BPbztMlLj2R+ENb9cdMKjph8d6IdI5UiYnfk3tskmwnt2fOYzxV5pmcg99AJvVjX/YT+
	8puSPBSs7UTS7UEsEbQh0tpM5mI00Ho5y3GzUQsryWW8d9VcCCH+1yV0KPC7g0Hdhb0s
	1YFzS/xpgBAoX6QKiAZ5osiCx9vp0pQFrmaukG+Kyu9+4fSGI+l2DcVgxXb1Rz3PSHRu
	B2Cg==
Received: by 10.50.236.74 with SMTP id us10mr9456606igc.5.1350319852916;
	Mon, 15 Oct 2012 09:50:52 -0700 (PDT)
Received: from [172.20.201.211]
	(75-148-42-21-Colorado.hfc.comcastbusiness.net. [75.148.42.21])
	by mx.google.com with ESMTPS id hg2sm6360392igc.3.2012.10.15.09.50.50
	(version=SSLv3 cipher=OTHER); Mon, 15 Oct 2012 09:50:51 -0700 (PDT)
Message-ID: <507C3EE9.9040806@gmail.com>
Date: Mon, 15 Oct 2012 10:50:49 -0600
From: Martin Roth 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Sharing MMIO page with DomU on a system with no IOMMU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi -
I'm trying to share an MMIO page from Dom0 running linux with a DomU 
running an RTOS so that I can access the GPIO registers directly. The 
system I need to get this working on does not have an IOMMU. I'm aware 
of the security issues of sharing this area, but don't believe it's an 
issue in this case.  I've got a Linux module set up and can share memory 
between the two domains using the grant table, but I haven't been able 
to get this to work for the MMIO page.

Can anyone give me a pointer on how I should go about doing this?  I 
need the area to actually be shared between both domains, not simply 
owned by the RTOS.


Thanks.
Martin Roth


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 16:51:22 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 16:51:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNnsY-0003Ky-MV; Mon, 15 Oct 2012 16:50:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNnsW-0003Kt-Lu
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 16:50:56 +0000
Received: from [85.158.143.99:15071] by server-1.bemta-4.messagelabs.com id
	B0/75-19551-FEE3C705; Mon, 15 Oct 2012 16:50:55 +0000
X-Env-Sender: gaumless@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1350319854!27197217!1
X-Originating-IP: [209.85.210.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5329 invoked from network); 15 Oct 2012 16:50:55 -0000
Received: from mail-ia0-f173.google.com (HELO mail-ia0-f173.google.com)
	(209.85.210.173)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 16:50:55 -0000
Received: by mail-ia0-f173.google.com with SMTP id m10so4828962iam.32
	for ; Mon, 15 Oct 2012 09:50:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:subject
	:content-type:content-transfer-encoding;
	bh=hWii4NjECm5wskSOZdbwa8Q+X85oY0YpemdYT/ynzX8=;
	b=iElchbob4rFLwDUV1aYFpv/ITfubvuOeZaBnZvCioT4AOGGmFVEtlZ5TVYY4uQieNl
	KpUUiqzlH9yPyrhVKeuRwklmrZpLMtP2xrZ7u2m031kbtADeVXOPHFjN+1jmu6UlP0WT
	BPbztMlLj2R+ENb9cdMKjph8d6IdI5UiYnfk3tskmwnt2fOYzxV5pmcg99AJvVjX/YT+
	8puSPBSs7UTS7UEsEbQh0tpM5mI00Ho5y3GzUQsryWW8d9VcCCH+1yV0KPC7g0Hdhb0s
	1YFzS/xpgBAoX6QKiAZ5osiCx9vp0pQFrmaukG+Kyu9+4fSGI+l2DcVgxXb1Rz3PSHRu
	B2Cg==
Received: by 10.50.236.74 with SMTP id us10mr9456606igc.5.1350319852916;
	Mon, 15 Oct 2012 09:50:52 -0700 (PDT)
Received: from [172.20.201.211]
	(75-148-42-21-Colorado.hfc.comcastbusiness.net. [75.148.42.21])
	by mx.google.com with ESMTPS id hg2sm6360392igc.3.2012.10.15.09.50.50
	(version=SSLv3 cipher=OTHER); Mon, 15 Oct 2012 09:50:51 -0700 (PDT)
Message-ID: <507C3EE9.9040806@gmail.com>
Date: Mon, 15 Oct 2012 10:50:49 -0600
From: Martin Roth 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Sharing MMIO page with DomU on a system with no IOMMU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi -
I'm trying to share an MMIO page from Dom0 running linux with a DomU 
running an RTOS so that I can access the GPIO registers directly. The 
system I need to get this working on does not have an IOMMU. I'm aware 
of the security issues of sharing this area, but don't believe it's an 
issue in this case.  I've got a Linux module set up and can share memory 
between the two domains using the grant table, but I haven't been able 
to get this to work for the MMIO page.

Can anyone give me a pointer on how I should go about doing this?  I 
need the area to actually be shared between both domains, not simply 
owned by the RTOS.


Thanks.
Martin Roth


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 18:10:28 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 18:10:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNp72-00042V-7o; Mon, 15 Oct 2012 18:10:00 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNp70-00042Q-Kf
	for xen-devel@lists.xensource.com; Mon, 15 Oct 2012 18:09:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1350324591!11421067!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8215 invoked from network); 15 Oct 2012 18:09:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 18:09:51 -0000
X-IronPort-AV: E=Sophos;i="4.80,588,1344211200"; d="scan'208";a="15178382"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 18:09:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Mon, 15 Oct 2012 19:09:50 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TNp6s-00067w-EK;
	Mon, 15 Oct 2012 18:09:50 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TNp6s-0005u9-5h;
	Mon, 15 Oct 2012 19:09:50 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Mon, 15 Oct 2012 19:09:50 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13963: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13963 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13963/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 13962

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13962
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13962
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13962
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13962

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  14e32621dbaf
baseline version:
 xen                  e0e1350dfe9b

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell 
  Jacob Shin 
  Jan Beulich 
  Keir Fraser 
  Tim Deegan 
  Wei Wang 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26055:14e32621dbaf
tag:         tip
user:        Jacob Shin 
date:        Mon Oct 15 15:04:51 2012 +0200
    
    x86/xenoprof: fix kernel/user mode detection for HVM
    
    While trying oprofile under Xen, I noticed that HVM passive domain's
    kernel addresses were showing up as user application. It turns out
    under HVM get_cpu_user_regs()->cs contains 0x0000beef.
    
    Signed-off-by: Jacob Shin 
    
    Don't cast away const-ness. Use SS instead of CS to determine ring.
    Special-case real and protected mode.
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    Committed-by: Jan Beulich 
    
    
changeset:   26054:983108e1b56b
user:        Wei Wang 
date:        Mon Oct 15 15:03:36 2012 +0200
    
    x86/amd: Fix xen_apic_write warnings in Dom0
    
    [    0.020294] ------------[ cut here ]------------
    [    0.020311] WARNING: at arch/x86/xen/enlighten.c:730
    xen_apic_write+0x15/0x17()
    [    0.020318] Hardware name: empty
    [    0.020323] Modules linked in:
    [    0.020334] Pid: 1, comm: swapper/0 Not tainted 3.3.8 #7
    [    0.020340] Call Trace:
    [    0.020354]  [] warn_slowpath_common+0x80/0x98
    [    0.020369]  [] warn_slowpath_null+0x15/0x17
    [    0.020378]  [] xen_apic_write+0x15/0x17
    [    0.020392]  [] perf_events_lapic_init+0x2e/0x30
    [    0.020410]  [] init_hw_perf_events+0x250/0x407
    [    0.020419]  [] ? check_bugs+0x2d/0x2d
    [    0.020430]  [] do_one_initcall+0x7a/0x131
    [    0.020444]  [] kernel_init+0x91/0x15d
    [    0.020456]  [] kernel_thread_helper+0x4/0x10
    [    0.020471]  [] ? retint_restore_args+0x5/0x6
    [    0.020481]  [] ? gs_change+0x13/0x13
    [    0.020500] ---[ end trace a7919e7f17c0a725 ]---
    
    Kernel function check_hw_exists() writes 0xabcd to msr 0xc0010201 (Performance Event
    Counter 0) and read it again to check if it is running as dom0. Early amd cpus does
    not reset perf counters during warm reboot. If the kernel is booted with bare metal
    and then as a dom0, the content of msr 0xc0010201 will stay and the checking will
    pass and PMU will be enabled unexpectedly.
    
    Signed-off-by: Wei Wang 
    
    Don't reset the counters when used for the NMI watchdog.
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    Committed-by: Jan Beulich 
    
    
changeset:   26053:137dfbd3190e
user:        Jan Beulich 
date:        Mon Oct 15 12:59:14 2012 +0200
    
    AMD IOMMU: fix find_iommu_from_bdf_cap()
    
    The arguments passed for the "cap_offset" parameter get read from 16-
    bit fields, so the parameter should also have (at least) 16 bits.
    
    While fixing this I also noticed that this was yet another case where
    PCI segment information wasn't properly propagated, so a respective
    first parameter gets added to the function at once.
    
    Signed-off-by: Jan Beulich 
    Acked-by: Wei Wang 
    
    
changeset:   26052:e0e1350dfe9b
user:        Ian Campbell 
date:        Thu Oct 11 15:57:00 2012 +0100
    
    arm: mark heap and frametable limits as read mostly
    
    These are used in virt_to_page and page_to_virt so I imagine there's
    some small benefit to this (but I've not measured)
    
    Signed-off-by: Ian Campbell 
    Acked-by: Tim Deegan 
    Committed-by: Ian Campbell 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 18:10:28 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 18:10:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNp72-00042V-7o; Mon, 15 Oct 2012 18:10:00 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNp70-00042Q-Kf
	for xen-devel@lists.xensource.com; Mon, 15 Oct 2012 18:09:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1350324591!11421067!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8215 invoked from network); 15 Oct 2012 18:09:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Oct 2012 18:09:51 -0000
X-IronPort-AV: E=Sophos;i="4.80,588,1344211200"; d="scan'208";a="15178382"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Oct 2012 18:09:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Mon, 15 Oct 2012 19:09:50 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TNp6s-00067w-EK;
	Mon, 15 Oct 2012 18:09:50 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TNp6s-0005u9-5h;
	Mon, 15 Oct 2012 19:09:50 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Mon, 15 Oct 2012 19:09:50 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13963: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13963 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13963/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 13962

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13962
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13962
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13962
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13962

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  14e32621dbaf
baseline version:
 xen                  e0e1350dfe9b

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell 
  Jacob Shin 
  Jan Beulich 
  Keir Fraser 
  Tim Deegan 
  Wei Wang 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26055:14e32621dbaf
tag:         tip
user:        Jacob Shin 
date:        Mon Oct 15 15:04:51 2012 +0200
    
    x86/xenoprof: fix kernel/user mode detection for HVM
    
    While trying oprofile under Xen, I noticed that HVM passive domain's
    kernel addresses were showing up as user application. It turns out
    under HVM get_cpu_user_regs()->cs contains 0x0000beef.
    
    Signed-off-by: Jacob Shin 
    
    Don't cast away const-ness. Use SS instead of CS to determine ring.
    Special-case real and protected mode.
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    Committed-by: Jan Beulich 
    
    
changeset:   26054:983108e1b56b
user:        Wei Wang 
date:        Mon Oct 15 15:03:36 2012 +0200
    
    x86/amd: Fix xen_apic_write warnings in Dom0
    
    [    0.020294] ------------[ cut here ]------------
    [    0.020311] WARNING: at arch/x86/xen/enlighten.c:730
    xen_apic_write+0x15/0x17()
    [    0.020318] Hardware name: empty
    [    0.020323] Modules linked in:
    [    0.020334] Pid: 1, comm: swapper/0 Not tainted 3.3.8 #7
    [    0.020340] Call Trace:
    [    0.020354]  [] warn_slowpath_common+0x80/0x98
    [    0.020369]  [] warn_slowpath_null+0x15/0x17
    [    0.020378]  [] xen_apic_write+0x15/0x17
    [    0.020392]  [] perf_events_lapic_init+0x2e/0x30
    [    0.020410]  [] init_hw_perf_events+0x250/0x407
    [    0.020419]  [] ? check_bugs+0x2d/0x2d
    [    0.020430]  [] do_one_initcall+0x7a/0x131
    [    0.020444]  [] kernel_init+0x91/0x15d
    [    0.020456]  [] kernel_thread_helper+0x4/0x10
    [    0.020471]  [] ? retint_restore_args+0x5/0x6
    [    0.020481]  [] ? gs_change+0x13/0x13
    [    0.020500] ---[ end trace a7919e7f17c0a725 ]---
    
    Kernel function check_hw_exists() writes 0xabcd to msr 0xc0010201 (Performance Event
    Counter 0) and read it again to check if it is running as dom0. Early amd cpus does
    not reset perf counters during warm reboot. If the kernel is booted with bare metal
    and then as a dom0, the content of msr 0xc0010201 will stay and the checking will
    pass and PMU will be enabled unexpectedly.
    
    Signed-off-by: Wei Wang 
    
    Don't reset the counters when used for the NMI watchdog.
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    Committed-by: Jan Beulich 
    
    
changeset:   26053:137dfbd3190e
user:        Jan Beulich 
date:        Mon Oct 15 12:59:14 2012 +0200
    
    AMD IOMMU: fix find_iommu_from_bdf_cap()
    
    The arguments passed for the "cap_offset" parameter get read from 16-
    bit fields, so the parameter should also have (at least) 16 bits.
    
    While fixing this I also noticed that this was yet another case where
    PCI segment information wasn't properly propagated, so a respective
    first parameter gets added to the function at once.
    
    Signed-off-by: Jan Beulich 
    Acked-by: Wei Wang 
    
    
changeset:   26052:e0e1350dfe9b
user:        Ian Campbell 
date:        Thu Oct 11 15:57:00 2012 +0100
    
    arm: mark heap and frametable limits as read mostly
    
    These are used in virt_to_page and page_to_virt so I imagine there's
    some small benefit to this (but I've not measured)
    
    Signed-off-by: Ian Campbell 
    Acked-by: Tim Deegan 
    Committed-by: Ian Campbell 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 18:13:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 18:13:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNp9u-000488-QK; Mon, 15 Oct 2012 18:12:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNp9u-000483-8I
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 18:12:58 +0000
Received: from [85.158.143.35:40232] by server-3.bemta-4.messagelabs.com id
	16/E2-10075-9225C705; Mon, 15 Oct 2012 18:12:57 +0000
X-Env-Sender: bvanassche@acm.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1350324777!15317612!1
X-Originating-IP: [195.130.132.50]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk1LjEzMC4xMzIuNTAgPT4gMjczODU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5540 invoked from network); 15 Oct 2012 18:12:57 -0000
Received: from jacques.telenet-ops.be (HELO jacques.telenet-ops.be)
	(195.130.132.50) by server-8.tower-21.messagelabs.com with SMTP;
	15 Oct 2012 18:12:57 -0000
Received: from [192.168.1.106] ([178.119.64.133])
	by jacques.telenet-ops.be with bizsmtp
	id BWCw1k00E2sVyXE0JWCwJ4; Mon, 15 Oct 2012 20:12:56 +0200
Message-ID: <507C5227.7020404@acm.org>
Date: Mon, 15 Oct 2012 20:12:55 +0200
From: Bart Van Assche 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120825 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell 
References: <1349696046.18008.116.camel@zakaz.uk.xensource.com>
	<1349696067-4273-1-git-send-email-ian.campbell@citrix.com>
	<201210111836.53184.jseward@acm.org>
	<1350296250.18058.18.camel@zakaz.uk.xensource.com>
In-Reply-To: <1350296250.18058.18.camel@zakaz.uk.xensource.com>
Cc: "valgrind-developers@lists.sourceforge.net"
	,
	Julian Seward , xen-devel 
Subject: Re: [Xen-devel] [Valgrind-developers] [PATCH 1/4] Useful messages
 for sys/domctl interface_version mismatch.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/15/12 12:17, Ian Campbell wrote:
> On Thu, 2012-10-11 at 17:36 +0100, Julian Seward wrote:
>> Please: file a bug report and attach the patches to it.  Else they
>> are pretty much guaranteed to wind up at /dev/null, because nobody
>> tracks patches on the list AFAIK.
>
> Bart indicated that he intended to apply these.
>
> I'll attach patches to a bug in the future though, thanks for the tip.
>
> I'll do it for these too if Bart wants me to.

I'll pick the patches from the mailing list this time. But next time 
please file a bug report. As you might have noticed Julian uses the 
bugzilla ticket numbers to track issues in the NEWS file, and also to 
keep track of which issues have been fixed in which branch.

Bart.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 18:13:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 18:13:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNp9u-000488-QK; Mon, 15 Oct 2012 18:12:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNp9u-000483-8I
	for xen-devel@lists.xen.org; Mon, 15 Oct 2012 18:12:58 +0000
Received: from [85.158.143.35:40232] by server-3.bemta-4.messagelabs.com id
	16/E2-10075-9225C705; Mon, 15 Oct 2012 18:12:57 +0000
X-Env-Sender: bvanassche@acm.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1350324777!15317612!1
X-Originating-IP: [195.130.132.50]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk1LjEzMC4xMzIuNTAgPT4gMjczODU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5540 invoked from network); 15 Oct 2012 18:12:57 -0000
Received: from jacques.telenet-ops.be (HELO jacques.telenet-ops.be)
	(195.130.132.50) by server-8.tower-21.messagelabs.com with SMTP;
	15 Oct 2012 18:12:57 -0000
Received: from [192.168.1.106] ([178.119.64.133])
	by jacques.telenet-ops.be with bizsmtp
	id BWCw1k00E2sVyXE0JWCwJ4; Mon, 15 Oct 2012 20:12:56 +0200
Message-ID: <507C5227.7020404@acm.org>
Date: Mon, 15 Oct 2012 20:12:55 +0200
From: Bart Van Assche 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120825 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell 
References: <1349696046.18008.116.camel@zakaz.uk.xensource.com>
	<1349696067-4273-1-git-send-email-ian.campbell@citrix.com>
	<201210111836.53184.jseward@acm.org>
	<1350296250.18058.18.camel@zakaz.uk.xensource.com>
In-Reply-To: <1350296250.18058.18.camel@zakaz.uk.xensource.com>
Cc: "valgrind-developers@lists.sourceforge.net"
	,
	Julian Seward , xen-devel 
Subject: Re: [Xen-devel] [Valgrind-developers] [PATCH 1/4] Useful messages
 for sys/domctl interface_version mismatch.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/15/12 12:17, Ian Campbell wrote:
> On Thu, 2012-10-11 at 17:36 +0100, Julian Seward wrote:
>> Please: file a bug report and attach the patches to it.  Else they
>> are pretty much guaranteed to wind up at /dev/null, because nobody
>> tracks patches on the list AFAIK.
>
> Bart indicated that he intended to apply these.
>
> I'll attach patches to a bug in the future though, thanks for the tip.
>
> I'll do it for these too if Bart wants me to.

I'll pick the patches from the mailing list this time. But next time 
please file a bug report. As you might have noticed Julian uses the 
bugzilla ticket numbers to track issues in the NEWS file, and also to 
keep track of which issues have been fixed in which branch.

Bart.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 20:27:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 20:27:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNrFe-0005Lk-PA; Mon, 15 Oct 2012 20:27:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNrFb-0005Lf-Mk
	for xen-devel@lists.xensource.com; Mon, 15 Oct 2012 20:27:00 +0000
Received: from [85.158.139.211:14199] by server-8.bemta-5.messagelabs.com id
	63/50-23193-2917C705; Mon, 15 Oct 2012 20:26:58 +0000
X-Env-Sender: ehabkost@redhat.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1350332816!22371664!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTg0NjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7183 invoked from network); 15 Oct 2012 20:26:57 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-206.messagelabs.com with SMTP;
	15 Oct 2012 20:26:57 -0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q9FKQIvE024730
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 15 Oct 2012 16:26:19 -0400
Received: from blackpad.lan.raisama.net (vpn1-4-48.gru2.redhat.com
	[10.97.4.48])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q9FKQEIO010629; Mon, 15 Oct 2012 16:26:15 -0400
Received: by blackpad.lan.raisama.net (Postfix, from userid 500)
	id 777E6203604; Mon, 15 Oct 2012 17:27:05 -0300 (BRT)
From: Eduardo Habkost 
To: qemu-devel@nongnu.org
Date: Mon, 15 Oct 2012 17:22:02 -0300
Message-Id: <1350332522-26635-1-git-send-email-ehabkost@redhat.com>
Signed-off-by: Eduardo Habkost 
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: Peter Maydell ,
	Evgeny Voevodin ,
	Peter Crosthwaite ,
	Max Filippov ,
	"Edgar E. Iglesias" ,
	Guan Xuetao , xen-devel@lists.xensource.com,
	Igor Mitsyanko ,
	Magnus Damm , Alexander Graf ,
	=?UTF-8?q?Herv=C3=A9=20Poussineau?= ,
	Maksim Kozlov ,
	Andrzej Zaborowski ,
	Fabien Chouteau , Jan Kiszka ,
	Paul Brook , Blue Swirl ,
	Anthony Liguori ,
	Michael Walle , qemu-ppc@nongnu.org,
	Dmitry Solodkiy ,
	Aurelien Jarno 
Subject: [Xen-devel] [QEMU PATCH v4] create struct for machine
	initialization arguments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This should help us to:
- More easily add or remove machine initialization arguments without
  having to change every single machine init function;
- More easily make mechanical changes involving the machine init
  functions in the future;
- Let machine initialization forward the init arguments to other
  functions more easily.

This change was half-mechanical process: first the struct was added with
the local ram_size, boot_device, kernel_*, initrd_*, and cpu_model local
variable initialization to all functions. Then the compiler helped me
locate the local variables that are unused, so they could be removed.

---

Changes v3 -> v4:
 - Rebase against latest qemu.git master, solved conflicts at
   hw/xilinx_zynq.c

Changes v2 -> v3:
 - Fix typo (missing dot) on main()
 - Fix another mistake on xen_init_pv()

Changes v1 -> v2:
 - Fix mistake on the conversion of pc_xen_hvm_init() and xen_init_pv()


 hw/alpha_dp264.c              |  12 ++--
 hw/an5206.c                   |   8 +--
 hw/axis_dev88.c               |   9 +--
 hw/boards.h                   |  16 +++--
 hw/collie.c                   |   9 +--
 hw/dummy_m68k.c               |   8 +--
 hw/exynos4_boards.c           |  16 ++---
 hw/gumstix.c                  |  11 +---
 hw/highbank.c                 |  10 ++--
 hw/integratorcp.c             |  10 ++--
 hw/kzm.c                      |  10 ++--
 hw/leon3.c                    |  10 ++--
 hw/lm32_boards.c              |  18 +++---
 hw/mainstone.c                |  10 ++--
 hw/mcf5208.c                  |   8 +--
 hw/milkymist.c                |  10 ++--
 hw/mips_fulong2e.c            |   9 ++-
 hw/mips_jazz.c                |  14 ++---
 hw/mips_malta.c               |  10 ++--
 hw/mips_mipssim.c             |  10 ++--
 hw/mips_r4k.c                 |  10 ++--
 hw/musicpal.c                 |   9 +--
 hw/nseries.c                  |  22 ++++---
 hw/null-machine.c             |   7 +--
 hw/omap_sx1.c                 |  22 ++++---
 hw/openrisc_sim.c             |  10 ++--
 hw/palm.c                     |   9 +--
 hw/pc_piix.c                  |  50 ++++++++--------
 hw/petalogix_ml605_mmu.c      |   8 +--
 hw/petalogix_s3adsp1800_mmu.c |   8 +--
 hw/ppc/e500plat.c             |  13 +++--
 hw/ppc/mpc8544ds.c            |  13 +++--
 hw/ppc405_boards.c            |  25 ++++----
 hw/ppc440_bamboo.c            |  12 ++--
 hw/ppc_newworld.c             |  13 +++--
 hw/ppc_oldworld.c             |  13 +++--
 hw/ppc_prep.c                 |  13 +++--
 hw/puv3.c                     |   8 ++-
 hw/r2d.c                      |   9 +--
 hw/realview.c                 |  44 +++++++++-----
 hw/s390-virtio.c              |  13 +++--
 hw/shix.c                     |   6 +-
 hw/spapr.c                    |  13 +++--
 hw/spitz.c                    |  40 ++++++++-----
 hw/stellaris.c                |  14 ++---
 hw/sun4m.c                    | 133 ++++++++++++++++++++++++++----------------
 hw/sun4u.c                    |  39 ++++++++-----
 hw/tosa.c                     |   9 +--
 hw/versatilepb.c              |  22 ++++---
 hw/vexpress.c                 |  26 +++++----
 hw/virtex_ml507.c             |  10 ++--
 hw/xen_machine_pv.c           |  11 ++--
 hw/xilinx_zynq.c              |   9 ++-
 hw/xtensa_lx60.c              |  22 ++++---
 hw/xtensa_sim.c               |  11 ++--
 hw/z2.c                       |   9 +--
 vl.c                          |   9 ++-
 57 files changed, 518 insertions(+), 414 deletions(-)

diff --git a/hw/alpha_dp264.c b/hw/alpha_dp264.c
index 5ea04c7..8f082a6 100644
--- a/hw/alpha_dp264.c
+++ b/hw/alpha_dp264.c
@@ -42,13 +42,13 @@ static int clipper_pci_map_irq(PCIDevice *d, int irq_num)
     return (slot + 1) * 4 + irq_num;
 }
 
-static void clipper_init(ram_addr_t ram_size,
-                         const char *boot_device,
-                         const char *kernel_filename,
-                         const char *kernel_cmdline,
-                         const char *initrd_filename,
-                         const char *cpu_model)
+static void clipper_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     CPUAlphaState *cpus[4];
     PCIBus *pci_bus;
     ISABus *isa_bus;
diff --git a/hw/an5206.c b/hw/an5206.c
index 25407c0..042c5fc 100644
--- a/hw/an5206.c
+++ b/hw/an5206.c
@@ -19,11 +19,11 @@
 
 /* Board init.  */
 
-static void an5206_init(ram_addr_t ram_size,
-                     const char *boot_device,
-                     const char *kernel_filename, const char *kernel_cmdline,
-                     const char *initrd_filename, const char *cpu_model)
+static void an5206_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
     CPUM68KState *env;
     int kernel_size;
     uint64_t elf_entry;
diff --git a/hw/axis_dev88.c b/hw/axis_dev88.c
index eab6327..2fd7356 100644
--- a/hw/axis_dev88.c
+++ b/hw/axis_dev88.c
@@ -242,11 +242,12 @@ static const MemoryRegionOps gpio_ops = {
 static struct cris_load_info li;
 
 static
-void axisdev88_init (ram_addr_t ram_size,
-                     const char *boot_device,
-                     const char *kernel_filename, const char *kernel_cmdline,
-                     const char *initrd_filename, const char *cpu_model)
+void axisdev88_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
     CRISCPU *cpu;
     CPUCRISState *env;
     DeviceState *dev;
diff --git a/hw/boards.h b/hw/boards.h
index a2e0a54..813d0e5 100644
--- a/hw/boards.h
+++ b/hw/boards.h
@@ -5,12 +5,16 @@
 
 #include "qdev.h"
 
-typedef void QEMUMachineInitFunc(ram_addr_t ram_size,
-                                 const char *boot_device,
-                                 const char *kernel_filename,
-                                 const char *kernel_cmdline,
-                                 const char *initrd_filename,
-                                 const char *cpu_model);
+typedef struct QEMUMachineInitArgs {
+    ram_addr_t ram_size;
+    const char *boot_device;
+    const char *kernel_filename;
+    const char *kernel_cmdline;
+    const char *initrd_filename;
+    const char *cpu_model;
+} QEMUMachineInitArgs;
+
+typedef void QEMUMachineInitFunc(QEMUMachineInitArgs *args);
 
 typedef void QEMUMachineResetFunc(void);
 
diff --git a/hw/collie.c b/hw/collie.c
index 56f89a9..695982a 100644
--- a/hw/collie.c
+++ b/hw/collie.c
@@ -23,11 +23,12 @@ static struct arm_boot_info collie_binfo = {
     .ram_size = 0x20000000,
 };
 
-static void collie_init(ram_addr_t ram_size,
-                const char *boot_device,
-                const char *kernel_filename, const char *kernel_cmdline,
-                const char *initrd_filename, const char *cpu_model)
+static void collie_init(QEMUMachineInitArgs *args)
 {
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     StrongARMState *s;
     DriveInfo *dinfo;
     MemoryRegion *sysmem = get_system_memory();
diff --git a/hw/dummy_m68k.c b/hw/dummy_m68k.c
index 7cc7a99..f436a0c 100644
--- a/hw/dummy_m68k.c
+++ b/hw/dummy_m68k.c
@@ -16,11 +16,11 @@
 
 /* Board init.  */
 
-static void dummy_m68k_init(ram_addr_t ram_size,
-                     const char *boot_device,
-                     const char *kernel_filename, const char *kernel_cmdline,
-                     const char *initrd_filename, const char *cpu_model)
+static void dummy_m68k_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
     CPUM68KState *env;
     MemoryRegion *address_space_mem =  get_system_memory();
     MemoryRegion *ram = g_new(MemoryRegion, 1);
diff --git a/hw/exynos4_boards.c b/hw/exynos4_boards.c
index 4bb0a60..4951064 100644
--- a/hw/exynos4_boards.c
+++ b/hw/exynos4_boards.c
@@ -130,22 +130,22 @@ static Exynos4210State *exynos4_boards_init_common(
             exynos4_board_ram_size[board_type]);
 }
 
-static void nuri_init(ram_addr_t ram_size,
-        const char *boot_device,
-        const char *kernel_filename, const char *kernel_cmdline,
-        const char *initrd_filename, const char *cpu_model)
+static void nuri_init(QEMUMachineInitArgs *args)
 {
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     exynos4_boards_init_common(kernel_filename, kernel_cmdline,
                 initrd_filename, EXYNOS4_BOARD_NURI);
 
     arm_load_kernel(arm_env_get_cpu(first_cpu), &exynos4_board_binfo);
 }
 
-static void smdkc210_init(ram_addr_t ram_size,
-        const char *boot_device,
-        const char *kernel_filename, const char *kernel_cmdline,
-        const char *initrd_filename, const char *cpu_model)
+static void smdkc210_init(QEMUMachineInitArgs *args)
 {
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     Exynos4210State *s = exynos4_boards_init_common(kernel_filename,
             kernel_cmdline, initrd_filename, EXYNOS4_BOARD_SMDKC210);
 
diff --git a/hw/gumstix.c b/hw/gumstix.c
index 13a36ea..4103a88 100644
--- a/hw/gumstix.c
+++ b/hw/gumstix.c
@@ -45,10 +45,7 @@
 
 static const int sector_len = 128 * 1024;
 
-static void connex_init(ram_addr_t ram_size,
-                const char *boot_device,
-                const char *kernel_filename, const char *kernel_cmdline,
-                const char *initrd_filename, const char *cpu_model)
+static void connex_init(QEMUMachineInitArgs *args)
 {
     PXA2xxState *cpu;
     DriveInfo *dinfo;
@@ -84,11 +81,9 @@ static void connex_init(ram_addr_t ram_size,
                     qdev_get_gpio_in(cpu->gpio, 36));
 }
 
-static void verdex_init(ram_addr_t ram_size,
-                const char *boot_device,
-                const char *kernel_filename, const char *kernel_cmdline,
-                const char *initrd_filename, const char *cpu_model)
+static void verdex_init(QEMUMachineInitArgs *args)
 {
+    const char *cpu_model = args->cpu_model;
     PXA2xxState *cpu;
     DriveInfo *dinfo;
     int be;
diff --git a/hw/highbank.c b/hw/highbank.c
index 11aa131..15036b6 100644
--- a/hw/highbank.c
+++ b/hw/highbank.c
@@ -187,11 +187,13 @@ static struct arm_boot_info highbank_binfo;
  * 32-bit host, set the reg value of memory to 0xf7ff00000 in the
  * device tree and pass -m 2047 to QEMU.
  */
-static void highbank_init(ram_addr_t ram_size,
-                     const char *boot_device,
-                     const char *kernel_filename, const char *kernel_cmdline,
-                     const char *initrd_filename, const char *cpu_model)
+static void highbank_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     DeviceState *dev;
     SysBusDevice *busdev;
     qemu_irq *irqp;
diff --git a/hw/integratorcp.c b/hw/integratorcp.c
index d0e2e90..ac0ea83 100644
--- a/hw/integratorcp.c
+++ b/hw/integratorcp.c
@@ -438,11 +438,13 @@ static struct arm_boot_info integrator_binfo = {
     .board_id = 0x113,
 };
 
-static void integratorcp_init(ram_addr_t ram_size,
-                     const char *boot_device,
-                     const char *kernel_filename, const char *kernel_cmdline,
-                     const char *initrd_filename, const char *cpu_model)
+static void integratorcp_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     ARMCPU *cpu;
     MemoryRegion *address_space_mem = get_system_memory();
     MemoryRegion *ram = g_new(MemoryRegion, 1);
diff --git a/hw/kzm.c b/hw/kzm.c
index 68cd1b4..d1266d9 100644
--- a/hw/kzm.c
+++ b/hw/kzm.c
@@ -70,11 +70,13 @@ static struct arm_boot_info kzm_binfo = {
     .board_id = 1722,
 };
 
-static void kzm_init(ram_addr_t ram_size,
-                     const char *boot_device,
-                     const char *kernel_filename, const char *kernel_cmdline,
-                     const char *initrd_filename, const char *cpu_model)
+static void kzm_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     ARMCPU *cpu;
     MemoryRegion *address_space_mem = get_system_memory();
     MemoryRegion *ram = g_new(MemoryRegion, 1);
diff --git a/hw/leon3.c b/hw/leon3.c
index 7a9729d..7742738 100644
--- a/hw/leon3.c
+++ b/hw/leon3.c
@@ -94,13 +94,11 @@ static void leon3_set_pil_in(void *opaque, uint32_t pil_in)
     }
 }
 
-static void leon3_generic_hw_init(ram_addr_t  ram_size,
-                                  const char *boot_device,
-                                  const char *kernel_filename,
-                                  const char *kernel_cmdline,
-                                  const char *initrd_filename,
-                                  const char *cpu_model)
+static void leon3_generic_hw_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
     SPARCCPU *cpu;
     CPUSPARCState   *env;
     MemoryRegion *address_space_mem = get_system_memory();
diff --git a/hw/lm32_boards.c b/hw/lm32_boards.c
index b76d800..c5a62c8 100644
--- a/hw/lm32_boards.c
+++ b/hw/lm32_boards.c
@@ -69,12 +69,10 @@ static void main_cpu_reset(void *opaque)
     env->deba = reset_info->flash_base;
 }
 
-static void lm32_evr_init(ram_addr_t ram_size_not_used,
-                          const char *boot_device,
-                          const char *kernel_filename,
-                          const char *kernel_cmdline,
-                          const char *initrd_filename, const char *cpu_model)
+static void lm32_evr_init(QEMUMachineInitArgs *args)
 {
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
     LM32CPU *cpu;
     CPULM32State *env;
     DriveInfo *dinfo;
@@ -159,12 +157,12 @@ static void lm32_evr_init(ram_addr_t ram_size_not_used,
     qemu_register_reset(main_cpu_reset, reset_info);
 }
 
-static void lm32_uclinux_init(ram_addr_t ram_size_not_used,
-                          const char *boot_device,
-                          const char *kernel_filename,
-                          const char *kernel_cmdline,
-                          const char *initrd_filename, const char *cpu_model)
+static void lm32_uclinux_init(QEMUMachineInitArgs *args)
 {
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     LM32CPU *cpu;
     CPULM32State *env;
     DriveInfo *dinfo;
diff --git a/hw/mainstone.c b/hw/mainstone.c
index 97687b6..c0d6034 100644
--- a/hw/mainstone.c
+++ b/hw/mainstone.c
@@ -171,11 +171,13 @@ static void mainstone_common_init(MemoryRegion *address_space_mem,
     arm_load_kernel(mpu->cpu, &mainstone_binfo);
 }
 
-static void mainstone_init(ram_addr_t ram_size,
-                const char *boot_device,
-                const char *kernel_filename, const char *kernel_cmdline,
-                const char *initrd_filename, const char *cpu_model)
+static void mainstone_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     mainstone_common_init(get_system_memory(), ram_size, kernel_filename,
                 kernel_cmdline, initrd_filename, cpu_model, mainstone, 0x196);
 }
diff --git a/hw/mcf5208.c b/hw/mcf5208.c
index ee25b1b..688bc3c 100644
--- a/hw/mcf5208.c
+++ b/hw/mcf5208.c
@@ -187,11 +187,11 @@ static void mcf5208_sys_init(MemoryRegion *address_space, qemu_irq *pic)
     }
 }
 
-static void mcf5208evb_init(ram_addr_t ram_size,
-                     const char *boot_device,
-                     const char *kernel_filename, const char *kernel_cmdline,
-                     const char *initrd_filename, const char *cpu_model)
+static void mcf5208evb_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
     CPUM68KState *env;
     int kernel_size;
     uint64_t elf_entry;
diff --git a/hw/milkymist.c b/hw/milkymist.c
index 2e7235b..ca9ed43 100644
--- a/hw/milkymist.c
+++ b/hw/milkymist.c
@@ -73,12 +73,12 @@ static void main_cpu_reset(void *opaque)
 }
 
 static void
-milkymist_init(ram_addr_t ram_size_not_used,
-                          const char *boot_device,
-                          const char *kernel_filename,
-                          const char *kernel_cmdline,
-                          const char *initrd_filename, const char *cpu_model)
+milkymist_init(QEMUMachineInitArgs *args)
 {
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     LM32CPU *cpu;
     CPULM32State *env;
     int kernel_size;
diff --git a/hw/mips_fulong2e.c b/hw/mips_fulong2e.c
index d4a8672..fb50a1f 100644
--- a/hw/mips_fulong2e.c
+++ b/hw/mips_fulong2e.c
@@ -256,10 +256,13 @@ static void cpu_request_exit(void *opaque, int irq, int level)
     }
 }
 
-static void mips_fulong2e_init(ram_addr_t ram_size, const char *boot_device,
-                        const char *kernel_filename, const char *kernel_cmdline,
-                        const char *initrd_filename, const char *cpu_model)
+static void mips_fulong2e_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     char *filename;
     MemoryRegion *address_space_mem = get_system_memory();
     MemoryRegion *ram = g_new(MemoryRegion, 1);
diff --git a/hw/mips_jazz.c b/hw/mips_jazz.c
index db927f1..14df4d7 100644
--- a/hw/mips_jazz.c
+++ b/hw/mips_jazz.c
@@ -302,21 +302,19 @@ static void mips_jazz_init(MemoryRegion *address_space,
 }
 
 static
-void mips_magnum_init (ram_addr_t ram_size,
-                       const char *boot_device,
-                       const char *kernel_filename, const char *kernel_cmdline,
-                       const char *initrd_filename, const char *cpu_model)
+void mips_magnum_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
         mips_jazz_init(get_system_memory(), get_system_io(),
                        ram_size, cpu_model, JAZZ_MAGNUM);
 }
 
 static
-void mips_pica61_init (ram_addr_t ram_size,
-                       const char *boot_device,
-                       const char *kernel_filename, const char *kernel_cmdline,
-                       const char *initrd_filename, const char *cpu_model)
+void mips_pica61_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
     mips_jazz_init(get_system_memory(), get_system_io(),
                    ram_size, cpu_model, JAZZ_PICA61);
 }
diff --git a/hw/mips_malta.c b/hw/mips_malta.c
index 632b466..ad4910f 100644
--- a/hw/mips_malta.c
+++ b/hw/mips_malta.c
@@ -775,11 +775,13 @@ static void cpu_request_exit(void *opaque, int irq, int level)
 }
 
 static
-void mips_malta_init (ram_addr_t ram_size,
-                      const char *boot_device,
-                      const char *kernel_filename, const char *kernel_cmdline,
-                      const char *initrd_filename, const char *cpu_model)
+void mips_malta_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     char *filename;
     pflash_t *fl;
     MemoryRegion *system_memory = get_system_memory();
diff --git a/hw/mips_mipssim.c b/hw/mips_mipssim.c
index 830f635..a1d3945 100644
--- a/hw/mips_mipssim.c
+++ b/hw/mips_mipssim.c
@@ -131,11 +131,13 @@ static void mipsnet_init(int base, qemu_irq irq, NICInfo *nd)
 }
 
 static void
-mips_mipssim_init (ram_addr_t ram_size,
-                   const char *boot_device,
-                   const char *kernel_filename, const char *kernel_cmdline,
-                   const char *initrd_filename, const char *cpu_model)
+mips_mipssim_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     char *filename;
     MemoryRegion *address_space_mem = get_system_memory();
     MemoryRegion *ram = g_new(MemoryRegion, 1);
diff --git a/hw/mips_r4k.c b/hw/mips_r4k.c
index 967a76e..b73cdc3 100644
--- a/hw/mips_r4k.c
+++ b/hw/mips_r4k.c
@@ -151,11 +151,13 @@ static void main_cpu_reset(void *opaque)
 
 static const int sector_len = 32 * 1024;
 static
-void mips_r4k_init (ram_addr_t ram_size,
-                    const char *boot_device,
-                    const char *kernel_filename, const char *kernel_cmdline,
-                    const char *initrd_filename, const char *cpu_model)
+void mips_r4k_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     char *filename;
     MemoryRegion *address_space_mem = get_system_memory();
     MemoryRegion *ram = g_new(MemoryRegion, 1);
diff --git a/hw/musicpal.c b/hw/musicpal.c
index f305e21..f06814c 100644
--- a/hw/musicpal.c
+++ b/hw/musicpal.c
@@ -1508,11 +1508,12 @@ static struct arm_boot_info musicpal_binfo = {
     .board_id = 0x20e,
 };
 
-static void musicpal_init(ram_addr_t ram_size,
-               const char *boot_device,
-               const char *kernel_filename, const char *kernel_cmdline,
-               const char *initrd_filename, const char *cpu_model)
+static void musicpal_init(QEMUMachineInitArgs *args)
 {
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     ARMCPU *cpu;
     qemu_irq *cpu_pic;
     qemu_irq pic[32];
diff --git a/hw/nseries.c b/hw/nseries.c
index 6df71eb..7ada90d 100644
--- a/hw/nseries.c
+++ b/hw/nseries.c
@@ -1397,21 +1397,27 @@ static struct arm_boot_info n810_binfo = {
     .atag_board = n810_atag_setup,
 };
 
-static void n800_init(ram_addr_t ram_size,
-                const char *boot_device,
-                const char *kernel_filename, const char *kernel_cmdline,
-                const char *initrd_filename, const char *cpu_model)
+static void n800_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     return n8x0_init(ram_size, boot_device,
                     kernel_filename, kernel_cmdline, initrd_filename,
                     cpu_model, &n800_binfo, 800);
 }
 
-static void n810_init(ram_addr_t ram_size,
-                const char *boot_device,
-                const char *kernel_filename, const char *kernel_cmdline,
-                const char *initrd_filename, const char *cpu_model)
+static void n810_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     return n8x0_init(ram_size, boot_device,
                     kernel_filename, kernel_cmdline, initrd_filename,
                     cpu_model, &n810_binfo, 810);
diff --git a/hw/null-machine.c b/hw/null-machine.c
index 69910d3..d813c08 100644
--- a/hw/null-machine.c
+++ b/hw/null-machine.c
@@ -15,12 +15,7 @@
 #include "hw/hw.h"
 #include "hw/boards.h"
 
-static void machine_none_init(ram_addr_t ram_size,
-                              const char *boot_device,
-                              const char *kernel_filename,
-                              const char *kernel_cmdline,
-                              const char *initrd_filename,
-                              const char *cpu_model)
+static void machine_none_init(QEMUMachineInitArgs *args)
 {
 }
 
diff --git a/hw/omap_sx1.c b/hw/omap_sx1.c
index abca341..ad17487 100644
--- a/hw/omap_sx1.c
+++ b/hw/omap_sx1.c
@@ -209,20 +209,26 @@ static void sx1_init(ram_addr_t ram_size,
     //~ qemu_console_resize(ds, 640, 480);
 }
 
-static void sx1_init_v1(ram_addr_t ram_size,
-                const char *boot_device,
-                const char *kernel_filename, const char *kernel_cmdline,
-                const char *initrd_filename, const char *cpu_model)
+static void sx1_init_v1(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     sx1_init(ram_size, boot_device, kernel_filename,
                 kernel_cmdline, initrd_filename, cpu_model, 1);
 }
 
-static void sx1_init_v2(ram_addr_t ram_size,
-                const char *boot_device,
-                const char *kernel_filename, const char *kernel_cmdline,
-                const char *initrd_filename, const char *cpu_model)
+static void sx1_init_v2(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     sx1_init(ram_size, boot_device, kernel_filename,
                 kernel_cmdline, initrd_filename, cpu_model, 2);
 }
diff --git a/hw/openrisc_sim.c b/hw/openrisc_sim.c
index 55e97f0..e96a944 100644
--- a/hw/openrisc_sim.c
+++ b/hw/openrisc_sim.c
@@ -90,13 +90,11 @@ static void cpu_openrisc_load_kernel(ram_addr_t ram_size,
     cpu->env.pc = entry;
 }
 
-static void openrisc_sim_init(ram_addr_t ram_size,
-                              const char *boot_device,
-                              const char *kernel_filename,
-                              const char *kernel_cmdline,
-                              const char *initrd_filename,
-                              const char *cpu_model)
+static void openrisc_sim_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
    OpenRISCCPU *cpu = NULL;
     MemoryRegion *ram;
     int n;
diff --git a/hw/palm.c b/hw/palm.c
index bacdc90..032b8d6 100644
--- a/hw/palm.c
+++ b/hw/palm.c
@@ -190,11 +190,12 @@ static struct arm_boot_info palmte_binfo = {
     .board_id = 0x331,
 };
 
-static void palmte_init(ram_addr_t ram_size,
-                const char *boot_device,
-                const char *kernel_filename, const char *kernel_cmdline,
-                const char *initrd_filename, const char *cpu_model)
+static void palmte_init(QEMUMachineInitArgs *args)
 {
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     MemoryRegion *address_space_mem = get_system_memory();
     struct omap_mpu_state_s *mpu;
     int flash_size = 0x00800000;
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index 82364ab..36e165f 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -287,13 +287,14 @@ static void pc_init1(MemoryRegion *system_memory,
     }
 }
 
-static void pc_init_pci(ram_addr_t ram_size,
-                        const char *boot_device,
-                        const char *kernel_filename,
-                        const char *kernel_cmdline,
-                        const char *initrd_filename,
-                        const char *cpu_model)
+static void pc_init_pci(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     pc_init1(get_system_memory(),
              get_system_io(),
              ram_size, boot_device,
@@ -301,13 +302,14 @@ static void pc_init_pci(ram_addr_t ram_size,
              initrd_filename, cpu_model, 1, 1);
 }
 
-static void pc_init_pci_no_kvmclock(ram_addr_t ram_size,
-                                    const char *boot_device,
-                                    const char *kernel_filename,
-                                    const char *kernel_cmdline,
-                                    const char *initrd_filename,
-                                    const char *cpu_model)
+static void pc_init_pci_no_kvmclock(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     pc_init1(get_system_memory(),
              get_system_io(),
              ram_size, boot_device,
@@ -315,13 +317,14 @@ static void pc_init_pci_no_kvmclock(ram_addr_t ram_size,
              initrd_filename, cpu_model, 1, 0);
 }
 
-static void pc_init_isa(ram_addr_t ram_size,
-                        const char *boot_device,
-                        const char *kernel_filename,
-                        const char *kernel_cmdline,
-                        const char *initrd_filename,
-                        const char *cpu_model)
+static void pc_init_isa(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     if (cpu_model == NULL)
         cpu_model = "486";
     pc_init1(get_system_memory(),
@@ -332,19 +335,12 @@ static void pc_init_isa(ram_addr_t ram_size,
 }
 
 #ifdef CONFIG_XEN
-static void pc_xen_hvm_init(ram_addr_t ram_size,
-                            const char *boot_device,
-                            const char *kernel_filename,
-                            const char *kernel_cmdline,
-                            const char *initrd_filename,
-                            const char *cpu_model)
+static void pc_xen_hvm_init(QEMUMachineInitArgs *args)
 {
     if (xen_hvm_init() != 0) {
         hw_error("xen hardware virtual machine initialisation failed");
     }
-    pc_init_pci_no_kvmclock(ram_size, boot_device,
-                            kernel_filename, kernel_cmdline,
-                            initrd_filename, cpu_model);
+    pc_init_pci_no_kvmclock(args);
     xen_vcpu_init();
 }
 #endif
diff --git a/hw/petalogix_ml605_mmu.c b/hw/petalogix_ml605_mmu.c
index b9bfbed..39df251 100644
--- a/hw/petalogix_ml605_mmu.c
+++ b/hw/petalogix_ml605_mmu.c
@@ -73,12 +73,10 @@ static void machine_cpu_reset(MicroBlazeCPU *cpu)
 }
 
 static void
-petalogix_ml605_init(ram_addr_t ram_size,
-                          const char *boot_device,
-                          const char *kernel_filename,
-                          const char *kernel_cmdline,
-                          const char *initrd_filename, const char *cpu_model)
+petalogix_ml605_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
     MemoryRegion *address_space_mem = get_system_memory();
     DeviceState *dev, *dma, *eth0;
     MicroBlazeCPU *cpu;
diff --git a/hw/petalogix_s3adsp1800_mmu.c b/hw/petalogix_s3adsp1800_mmu.c
index 2cf6882..71c32ce 100644
--- a/hw/petalogix_s3adsp1800_mmu.c
+++ b/hw/petalogix_s3adsp1800_mmu.c
@@ -57,12 +57,10 @@ static void machine_cpu_reset(MicroBlazeCPU *cpu)
 }
 
 static void
-petalogix_s3adsp1800_init(ram_addr_t ram_size,
-                          const char *boot_device,
-                          const char *kernel_filename,
-                          const char *kernel_cmdline,
-                          const char *initrd_filename, const char *cpu_model)
+petalogix_s3adsp1800_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
     DeviceState *dev;
     MicroBlazeCPU *cpu;
     CPUMBState *env;
diff --git a/hw/ppc/e500plat.c b/hw/ppc/e500plat.c
index 60a5cb3..4cfb940 100644
--- a/hw/ppc/e500plat.c
+++ b/hw/ppc/e500plat.c
@@ -25,13 +25,14 @@ static void e500plat_fixup_devtree(PPCE500Params *params, void *fdt)
                          sizeof(compatible));
 }
 
-static void e500plat_init(ram_addr_t ram_size,
-                           const char *boot_device,
-                           const char *kernel_filename,
-                           const char *kernel_cmdline,
-                           const char *initrd_filename,
-                           const char *cpu_model)
+static void e500plat_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *boot_device = args->boot_device;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     PPCE500Params params = {
         .ram_size = ram_size,
         .boot_device = boot_device,
diff --git a/hw/ppc/mpc8544ds.c b/hw/ppc/mpc8544ds.c
index 984d21c..e651661 100644
--- a/hw/ppc/mpc8544ds.c
+++ b/hw/ppc/mpc8544ds.c
@@ -25,13 +25,14 @@ static void mpc8544ds_fixup_devtree(PPCE500Params *params, void *fdt)
                          sizeof(compatible));
 }
 
-static void mpc8544ds_init(ram_addr_t ram_size,
-                           const char *boot_device,
-                           const char *kernel_filename,
-                           const char *kernel_cmdline,
-                           const char *initrd_filename,
-                           const char *cpu_model)
+static void mpc8544ds_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *boot_device = args->boot_device;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     PPCE500Params params = {
         .ram_size = ram_size,
         .boot_device = boot_device,
diff --git a/hw/ppc405_boards.c b/hw/ppc405_boards.c
index 476775d..e848cb0 100644
--- a/hw/ppc405_boards.c
+++ b/hw/ppc405_boards.c
@@ -158,7 +158,7 @@ static void ref405ep_fpga_reset (void *opaque)
     fpga->reg1 = 0x0F;
 }
 
-static void ref405ep_fpga_init (MemoryRegion *sysmem, uint32_t base)
+static void ref405ep_fpga_init(MemoryRegion *sysmem, uint32_t base)
 {
     ref405ep_fpga_t *fpga;
     MemoryRegion *fpga_memory = g_new(MemoryRegion, 1);
@@ -170,13 +170,12 @@ static void ref405ep_fpga_init (MemoryRegion *sysmem, uint32_t base)
     qemu_register_reset(&ref405ep_fpga_reset, fpga);
 }
 
-static void ref405ep_init (ram_addr_t ram_size,
-                           const char *boot_device,
-                           const char *kernel_filename,
-                           const char *kernel_cmdline,
-                           const char *initrd_filename,
-                           const char *cpu_model)
+static void ref405ep_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     char *filename;
     ppc4xx_bd_info_t bd;
     CPUPPCState *env;
@@ -484,7 +483,7 @@ static void taihu_cpld_reset (void *opaque)
     cpld->reg1 = 0x80;
 }
 
-static void taihu_cpld_init (MemoryRegion *sysmem, uint32_t base)
+static void taihu_cpld_init(MemoryRegion *sysmem, uint32_t base)
 {
     taihu_cpld_t *cpld;
     MemoryRegion *cpld_memory = g_new(MemoryRegion, 1);
@@ -495,13 +494,11 @@ static void taihu_cpld_init (MemoryRegion *sysmem, uint32_t base)
     qemu_register_reset(&taihu_cpld_reset, cpld);
 }
 
-static void taihu_405ep_init(ram_addr_t ram_size,
-                             const char *boot_device,
-                             const char *kernel_filename,
-                             const char *kernel_cmdline,
-                             const char *initrd_filename,
-                             const char *cpu_model)
+static void taihu_405ep_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *kernel_filename = args->kernel_filename;
+    const char *initrd_filename = args->initrd_filename;
     char *filename;
     qemu_irq *pic;
     MemoryRegion *sysmem = get_system_memory();
diff --git a/hw/ppc440_bamboo.c b/hw/ppc440_bamboo.c
index c198071..78e7985 100644
--- a/hw/ppc440_bamboo.c
+++ b/hw/ppc440_bamboo.c
@@ -157,13 +157,13 @@ static void main_cpu_reset(void *opaque)
     mmubooke_create_initial_mapping(env, 0, 0);
 }
 
-static void bamboo_init(ram_addr_t ram_size,
-                        const char *boot_device,
-                        const char *kernel_filename,
-                        const char *kernel_cmdline,
-                        const char *initrd_filename,
-                        const char *cpu_model)
+static void bamboo_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     unsigned int pci_irq_nrs[4] = { 28, 27, 26, 25 };
     MemoryRegion *address_space_mem = get_system_memory();
     MemoryRegion *ram_memories
diff --git a/hw/ppc_newworld.c b/hw/ppc_newworld.c
index b8d3c9c..a265445 100644
--- a/hw/ppc_newworld.c
+++ b/hw/ppc_newworld.c
@@ -128,13 +128,14 @@ static void ppc_core99_reset(void *opaque)
 }
 
 /* PowerPC Mac99 hardware initialisation */
-static void ppc_core99_init (ram_addr_t ram_size,
-                             const char *boot_device,
-                             const char *kernel_filename,
-                             const char *kernel_cmdline,
-                             const char *initrd_filename,
-                             const char *cpu_model)
+static void ppc_core99_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     PowerPCCPU *cpu = NULL;
     CPUPPCState *env = NULL;
     char *filename;
diff --git a/hw/ppc_oldworld.c b/hw/ppc_oldworld.c
index 2c4a478..de33408 100644
--- a/hw/ppc_oldworld.c
+++ b/hw/ppc_oldworld.c
@@ -71,13 +71,14 @@ static void ppc_heathrow_reset(void *opaque)
     cpu_reset(CPU(cpu));
 }
 
-static void ppc_heathrow_init (ram_addr_t ram_size,
-                               const char *boot_device,
-                               const char *kernel_filename,
-                               const char *kernel_cmdline,
-                               const char *initrd_filename,
-                               const char *cpu_model)
+static void ppc_heathrow_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     MemoryRegion *sysmem = get_system_memory();
     PowerPCCPU *cpu = NULL;
     CPUPPCState *env = NULL;
diff --git a/hw/ppc_prep.c b/hw/ppc_prep.c
index 1544430..b426891 100644
--- a/hw/ppc_prep.c
+++ b/hw/ppc_prep.c
@@ -447,13 +447,14 @@ static void ppc_prep_reset(void *opaque)
 }
 
 /* PowerPC PREP hardware initialisation */
-static void ppc_prep_init (ram_addr_t ram_size,
-                           const char *boot_device,
-                           const char *kernel_filename,
-                           const char *kernel_cmdline,
-                           const char *initrd_filename,
-                           const char *cpu_model)
+static void ppc_prep_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     MemoryRegion *sysmem = get_system_memory();
     PowerPCCPU *cpu = NULL;
     CPUPPCState *env = NULL;
diff --git a/hw/puv3.c b/hw/puv3.c
index 43f7216..764799c 100644
--- a/hw/puv3.c
+++ b/hw/puv3.c
@@ -91,10 +91,12 @@ static void puv3_load_kernel(const char *kernel_filename)
     graphic_console_init(NULL, NULL, NULL, NULL, NULL);
 }
 
-static void puv3_init(ram_addr_t ram_size, const char *boot_device,
-                     const char *kernel_filename, const char *kernel_cmdline,
-                     const char *initrd_filename, const char *cpu_model)
+static void puv3_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *initrd_filename = args->initrd_filename;
     CPUUniCore32State *env;
 
     if (initrd_filename) {
diff --git a/hw/r2d.c b/hw/r2d.c
index 1bc191f..3cb6942 100644
--- a/hw/r2d.c
+++ b/hw/r2d.c
@@ -219,11 +219,12 @@ static struct QEMU_PACKED
     char kernel_cmdline[256];
 } boot_params;
 
-static void r2d_init(ram_addr_t ram_size,
-              const char *boot_device,
-	      const char *kernel_filename, const char *kernel_cmdline,
-	      const char *initrd_filename, const char *cpu_model)
+static void r2d_init(QEMUMachineInitArgs *args)
 {
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     SuperHCPU *cpu;
     CPUSH4State *env;
     ResetData *reset_info;
diff --git a/hw/realview.c b/hw/realview.c
index 19db4d0..8dc4be6 100644
--- a/hw/realview.c
+++ b/hw/realview.c
@@ -330,11 +330,14 @@ static void realview_init(ram_addr_t ram_size,
     arm_load_kernel(arm_env_get_cpu(first_cpu), &realview_binfo);
 }
 
-static void realview_eb_init(ram_addr_t ram_size,
-                     const char *boot_device,
-                     const char *kernel_filename, const char *kernel_cmdline,
-                     const char *initrd_filename, const char *cpu_model)
+static void realview_eb_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     if (!cpu_model) {
         cpu_model = "arm926";
     }
@@ -342,11 +345,14 @@ static void realview_eb_init(ram_addr_t ram_size,
                   initrd_filename, cpu_model, BOARD_EB);
 }
 
-static void realview_eb_mpcore_init(ram_addr_t ram_size,
-                     const char *boot_device,
-                     const char *kernel_filename, const char *kernel_cmdline,
-                     const char *initrd_filename, const char *cpu_model)
+static void realview_eb_mpcore_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     if (!cpu_model) {
         cpu_model = "arm11mpcore";
     }
@@ -354,11 +360,14 @@ static void realview_eb_mpcore_init(ram_addr_t ram_size,
                   initrd_filename, cpu_model, BOARD_EB_MPCORE);
 }
 
-static void realview_pb_a8_init(ram_addr_t ram_size,
-                     const char *boot_device,
-                     const char *kernel_filename, const char *kernel_cmdline,
-                     const char *initrd_filename, const char *cpu_model)
+static void realview_pb_a8_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     if (!cpu_model) {
         cpu_model = "cortex-a8";
     }
@@ -366,11 +375,14 @@ static void realview_pb_a8_init(ram_addr_t ram_size,
                   initrd_filename, cpu_model, BOARD_PB_A8);
 }
 
-static void realview_pbx_a9_init(ram_addr_t ram_size,
-                     const char *boot_device,
-                     const char *kernel_filename, const char *kernel_cmdline,
-                     const char *initrd_filename, const char *cpu_model)
+static void realview_pbx_a9_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     if (!cpu_model) {
         cpu_model = "cortex-a9";
     }
diff --git a/hw/s390-virtio.c b/hw/s390-virtio.c
index 47eed35..39ff178 100644
--- a/hw/s390-virtio.c
+++ b/hw/s390-virtio.c
@@ -151,13 +151,14 @@ unsigned s390_del_running_cpu(CPUS390XState *env)
 }
 
 /* PC hardware initialisation */
-static void s390_init(ram_addr_t my_ram_size,
-                      const char *boot_device,
-                      const char *kernel_filename,
-                      const char *kernel_cmdline,
-                      const char *initrd_filename,
-                      const char *cpu_model)
+static void s390_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t my_ram_size = args->ram_size;
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     CPUS390XState *env = NULL;
     MemoryRegion *sysmem = get_system_memory();
     MemoryRegion *ram = g_new(MemoryRegion, 1);
diff --git a/hw/shix.c b/hw/shix.c
index dd9ce17..b56dd54 100644
--- a/hw/shix.c
+++ b/hw/shix.c
@@ -37,11 +37,9 @@
 #define BIOS_FILENAME "shix_bios.bin"
 #define BIOS_ADDRESS 0xA0000000
 
-static void shix_init(ram_addr_t ram_size,
-               const char *boot_device,
-	       const char *kernel_filename, const char *kernel_cmdline,
-	       const char *initrd_filename, const char *cpu_model)
+static void shix_init(QEMUMachineInitArgs *args)
 {
+    const char *cpu_model = args->cpu_model;
     int ret;
     CPUSH4State *env;
     struct SH7750State *s;
diff --git a/hw/spapr.c b/hw/spapr.c
index 09b8e99..637b3fb 100644
--- a/hw/spapr.c
+++ b/hw/spapr.c
@@ -665,13 +665,14 @@ static int spapr_vga_init(PCIBus *pci_bus)
 }
 
 /* pSeries LPAR / sPAPR hardware init */
-static void ppc_spapr_init(ram_addr_t ram_size,
-                           const char *boot_device,
-                           const char *kernel_filename,
-                           const char *kernel_cmdline,
-                           const char *initrd_filename,
-                           const char *cpu_model)
+static void ppc_spapr_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     PowerPCCPU *cpu;
     CPUPPCState *env;
     PCIHostState *phb;
diff --git a/hw/spitz.c b/hw/spitz.c
index 24346dc..2942626 100644
--- a/hw/spitz.c
+++ b/hw/spitz.c
@@ -936,38 +936,46 @@ static void spitz_common_init(ram_addr_t ram_size,
     sl_bootparam_write(SL_PXA_PARAM_BASE);
 }
 
-static void spitz_init(ram_addr_t ram_size,
-                const char *boot_device,
-                const char *kernel_filename, const char *kernel_cmdline,
-                const char *initrd_filename, const char *cpu_model)
+static void spitz_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     spitz_common_init(ram_size, kernel_filename,
                 kernel_cmdline, initrd_filename, cpu_model, spitz, 0x2c9);
 }
 
-static void borzoi_init(ram_addr_t ram_size,
-                const char *boot_device,
-                const char *kernel_filename, const char *kernel_cmdline,
-                const char *initrd_filename, const char *cpu_model)
+static void borzoi_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     spitz_common_init(ram_size, kernel_filename,
                 kernel_cmdline, initrd_filename, cpu_model, borzoi, 0x33f);
 }
 
-static void akita_init(ram_addr_t ram_size,
-                const char *boot_device,
-                const char *kernel_filename, const char *kernel_cmdline,
-                const char *initrd_filename, const char *cpu_model)
+static void akita_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     spitz_common_init(ram_size, kernel_filename,
                 kernel_cmdline, initrd_filename, cpu_model, akita, 0x2e8);
 }
 
-static void terrier_init(ram_addr_t ram_size,
-                const char *boot_device,
-                const char *kernel_filename, const char *kernel_cmdline,
-                const char *initrd_filename, const char *cpu_model)
+static void terrier_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     spitz_common_init(ram_size, kernel_filename,
                 kernel_cmdline, initrd_filename, cpu_model, terrier, 0x33f);
 }
diff --git a/hw/stellaris.c b/hw/stellaris.c
index 353ca4c..bfb18b0 100644
--- a/hw/stellaris.c
+++ b/hw/stellaris.c
@@ -1313,19 +1313,17 @@ static void stellaris_init(const char *kernel_filename, const char *cpu_model,
 }
 
 /* FIXME: Figure out how to generate these from stellaris_boards.  */
-static void lm3s811evb_init(ram_addr_t ram_size,
-                     const char *boot_device,
-                     const char *kernel_filename, const char *kernel_cmdline,
-                     const char *initrd_filename, const char *cpu_model)
+static void lm3s811evb_init(QEMUMachineInitArgs *args)
 {
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
     stellaris_init(kernel_filename, cpu_model, &stellaris_boards[0]);
 }
 
-static void lm3s6965evb_init(ram_addr_t ram_size,
-                     const char *boot_device,
-                     const char *kernel_filename, const char *kernel_cmdline,
-                     const char *initrd_filename, const char *cpu_model)
+static void lm3s6965evb_init(QEMUMachineInitArgs *args)
 {
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
     stellaris_init(kernel_filename, cpu_model, &stellaris_boards[1]);
 }
 
diff --git a/hw/sun4m.c b/hw/sun4m.c
index a04b485..dbe93f9 100644
--- a/hw/sun4m.c
+++ b/hw/sun4m.c
@@ -1306,92 +1306,118 @@ static const struct sun4m_hwdef sun4m_hwdefs[] = {
 };
 
 /* SPARCstation 5 hardware initialisation */
-static void ss5_init(ram_addr_t RAM_size,
-                     const char *boot_device,
-                     const char *kernel_filename, const char *kernel_cmdline,
-                     const char *initrd_filename, const char *cpu_model)
+static void ss5_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t RAM_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     sun4m_hw_init(&sun4m_hwdefs[0], RAM_size, boot_device, kernel_filename,
                   kernel_cmdline, initrd_filename, cpu_model);
 }
 
 /* SPARCstation 10 hardware initialisation */
-static void ss10_init(ram_addr_t RAM_size,
-                      const char *boot_device,
-                      const char *kernel_filename, const char *kernel_cmdline,
-                      const char *initrd_filename, const char *cpu_model)
+static void ss10_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t RAM_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     sun4m_hw_init(&sun4m_hwdefs[1], RAM_size, boot_device, kernel_filename,
                   kernel_cmdline, initrd_filename, cpu_model);
 }
 
 /* SPARCserver 600MP hardware initialisation */
-static void ss600mp_init(ram_addr_t RAM_size,
-                         const char *boot_device,
-                         const char *kernel_filename,
-                         const char *kernel_cmdline,
-                         const char *initrd_filename, const char *cpu_model)
+static void ss600mp_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t RAM_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     sun4m_hw_init(&sun4m_hwdefs[2], RAM_size, boot_device, kernel_filename,
                   kernel_cmdline, initrd_filename, cpu_model);
 }
 
 /* SPARCstation 20 hardware initialisation */
-static void ss20_init(ram_addr_t RAM_size,
-                      const char *boot_device,
-                      const char *kernel_filename, const char *kernel_cmdline,
-                      const char *initrd_filename, const char *cpu_model)
+static void ss20_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t RAM_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     sun4m_hw_init(&sun4m_hwdefs[3], RAM_size, boot_device, kernel_filename,
                   kernel_cmdline, initrd_filename, cpu_model);
 }
 
 /* SPARCstation Voyager hardware initialisation */
-static void vger_init(ram_addr_t RAM_size,
-                      const char *boot_device,
-                      const char *kernel_filename, const char *kernel_cmdline,
-                      const char *initrd_filename, const char *cpu_model)
+static void vger_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t RAM_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     sun4m_hw_init(&sun4m_hwdefs[4], RAM_size, boot_device, kernel_filename,
                   kernel_cmdline, initrd_filename, cpu_model);
 }
 
 /* SPARCstation LX hardware initialisation */
-static void ss_lx_init(ram_addr_t RAM_size,
-                       const char *boot_device,
-                       const char *kernel_filename, const char *kernel_cmdline,
-                       const char *initrd_filename, const char *cpu_model)
+static void ss_lx_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t RAM_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     sun4m_hw_init(&sun4m_hwdefs[5], RAM_size, boot_device, kernel_filename,
                   kernel_cmdline, initrd_filename, cpu_model);
 }
 
 /* SPARCstation 4 hardware initialisation */
-static void ss4_init(ram_addr_t RAM_size,
-                     const char *boot_device,
-                     const char *kernel_filename, const char *kernel_cmdline,
-                     const char *initrd_filename, const char *cpu_model)
+static void ss4_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t RAM_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     sun4m_hw_init(&sun4m_hwdefs[6], RAM_size, boot_device, kernel_filename,
                   kernel_cmdline, initrd_filename, cpu_model);
 }
 
 /* SPARCClassic hardware initialisation */
-static void scls_init(ram_addr_t RAM_size,
-                      const char *boot_device,
-                      const char *kernel_filename, const char *kernel_cmdline,
-                      const char *initrd_filename, const char *cpu_model)
+static void scls_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t RAM_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     sun4m_hw_init(&sun4m_hwdefs[7], RAM_size, boot_device, kernel_filename,
                   kernel_cmdline, initrd_filename, cpu_model);
 }
 
 /* SPARCbook hardware initialisation */
-static void sbook_init(ram_addr_t RAM_size,
-                       const char *boot_device,
-                       const char *kernel_filename, const char *kernel_cmdline,
-                       const char *initrd_filename, const char *cpu_model)
+static void sbook_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t RAM_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     sun4m_hw_init(&sun4m_hwdefs[8], RAM_size, boot_device, kernel_filename,
                   kernel_cmdline, initrd_filename, cpu_model);
 }
@@ -1654,21 +1680,27 @@ static void sun4d_hw_init(const struct sun4d_hwdef *hwdef, ram_addr_t RAM_size,
 }
 
 /* SPARCserver 1000 hardware initialisation */
-static void ss1000_init(ram_addr_t RAM_size,
-                        const char *boot_device,
-                        const char *kernel_filename, const char *kernel_cmdline,
-                        const char *initrd_filename, const char *cpu_model)
+static void ss1000_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t RAM_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     sun4d_hw_init(&sun4d_hwdefs[0], RAM_size, boot_device, kernel_filename,
                   kernel_cmdline, initrd_filename, cpu_model);
 }
 
 /* SPARCcenter 2000 hardware initialisation */
-static void ss2000_init(ram_addr_t RAM_size,
-                        const char *boot_device,
-                        const char *kernel_filename, const char *kernel_cmdline,
-                        const char *initrd_filename, const char *cpu_model)
+static void ss2000_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t RAM_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     sun4d_hw_init(&sun4d_hwdefs[1], RAM_size, boot_device, kernel_filename,
                   kernel_cmdline, initrd_filename, cpu_model);
 }
@@ -1848,11 +1880,14 @@ static void sun4c_hw_init(const struct sun4c_hwdef *hwdef, ram_addr_t RAM_size,
 }
 
 /* SPARCstation 2 hardware initialisation */
-static void ss2_init(ram_addr_t RAM_size,
-                     const char *boot_device,
-                     const char *kernel_filename, const char *kernel_cmdline,
-                     const char *initrd_filename, const char *cpu_model)
+static void ss2_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t RAM_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     sun4c_hw_init(&sun4c_hwdefs[0], RAM_size, boot_device, kernel_filename,
                   kernel_cmdline, initrd_filename, cpu_model);
 }
diff --git a/hw/sun4u.c b/hw/sun4u.c
index 940db33..abf68cf 100644
--- a/hw/sun4u.c
+++ b/hw/sun4u.c
@@ -933,31 +933,40 @@ static const struct hwdef hwdefs[] = {
 };
 
 /* Sun4u hardware initialisation */
-static void sun4u_init(ram_addr_t RAM_size,
-                       const char *boot_devices,
-                       const char *kernel_filename, const char *kernel_cmdline,
-                       const char *initrd_filename, const char *cpu_model)
-{
+static void sun4u_init(QEMUMachineInitArgs *args)
+{
+    ram_addr_t RAM_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_devices = args->boot_device;
     sun4uv_init(get_system_memory(), RAM_size, boot_devices, kernel_filename,
                 kernel_cmdline, initrd_filename, cpu_model, &hwdefs[0]);
 }
 
 /* Sun4v hardware initialisation */
-static void sun4v_init(ram_addr_t RAM_size,
-                       const char *boot_devices,
-                       const char *kernel_filename, const char *kernel_cmdline,
-                       const char *initrd_filename, const char *cpu_model)
-{
+static void sun4v_init(QEMUMachineInitArgs *args)
+{
+    ram_addr_t RAM_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_devices = args->boot_device;
     sun4uv_init(get_system_memory(), RAM_size, boot_devices, kernel_filename,
                 kernel_cmdline, initrd_filename, cpu_model, &hwdefs[1]);
 }
 
 /* Niagara hardware initialisation */
-static void niagara_init(ram_addr_t RAM_size,
-                         const char *boot_devices,
-                         const char *kernel_filename, const char *kernel_cmdline,
-                         const char *initrd_filename, const char *cpu_model)
-{
+static void niagara_init(QEMUMachineInitArgs *args)
+{
+    ram_addr_t RAM_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_devices = args->boot_device;
     sun4uv_init(get_system_memory(), RAM_size, boot_devices, kernel_filename,
                 kernel_cmdline, initrd_filename, cpu_model, &hwdefs[2]);
 }
diff --git a/hw/tosa.c b/hw/tosa.c
index 297a8c2..512278c 100644
--- a/hw/tosa.c
+++ b/hw/tosa.c
@@ -205,11 +205,12 @@ static struct arm_boot_info tosa_binfo = {
     .ram_size = 0x04000000,
 };
 
-static void tosa_init(ram_addr_t ram_size,
-                const char *boot_device,
-                const char *kernel_filename, const char *kernel_cmdline,
-                const char *initrd_filename, const char *cpu_model)
+static void tosa_init(QEMUMachineInitArgs *args)
 {
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     MemoryRegion *address_space_mem = get_system_memory();
     MemoryRegion *rom = g_new(MemoryRegion, 1);
     PXA2xxState *mpu;
diff --git a/hw/versatilepb.c b/hw/versatilepb.c
index 7b1b025..756ec29 100644
--- a/hw/versatilepb.c
+++ b/hw/versatilepb.c
@@ -348,22 +348,28 @@ static void versatile_init(ram_addr_t ram_size,
     arm_load_kernel(cpu, &versatile_binfo);
 }
 
-static void vpb_init(ram_addr_t ram_size,
-                     const char *boot_device,
-                     const char *kernel_filename, const char *kernel_cmdline,
-                     const char *initrd_filename, const char *cpu_model)
+static void vpb_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     versatile_init(ram_size,
                    boot_device,
                    kernel_filename, kernel_cmdline,
                    initrd_filename, cpu_model, 0x183);
 }
 
-static void vab_init(ram_addr_t ram_size,
-                     const char *boot_device,
-                     const char *kernel_filename, const char *kernel_cmdline,
-                     const char *initrd_filename, const char *cpu_model)
+static void vab_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     versatile_init(ram_size,
                    boot_device,
                    kernel_filename, kernel_cmdline,
diff --git a/hw/vexpress.c b/hw/vexpress.c
index 3596d1e..36503d6 100644
--- a/hw/vexpress.c
+++ b/hw/vexpress.c
@@ -467,25 +467,27 @@ static void vexpress_common_init(const VEDBoardInfo *daughterboard,
     arm_load_kernel(arm_env_get_cpu(first_cpu), &vexpress_binfo);
 }
 
-static void vexpress_a9_init(ram_addr_t ram_size,
-                             const char *boot_device,
-                             const char *kernel_filename,
-                             const char *kernel_cmdline,
-                             const char *initrd_filename,
-                             const char *cpu_model)
+static void vexpress_a9_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     vexpress_common_init(&a9_daughterboard,
                          ram_size, boot_device, kernel_filename,
                          kernel_cmdline, initrd_filename, cpu_model);
 }
 
-static void vexpress_a15_init(ram_addr_t ram_size,
-                              const char *boot_device,
-                              const char *kernel_filename,
-                              const char *kernel_cmdline,
-                              const char *initrd_filename,
-                              const char *cpu_model)
+static void vexpress_a15_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     vexpress_common_init(&a15_daughterboard,
                          ram_size, boot_device, kernel_filename,
                          kernel_cmdline, initrd_filename, cpu_model);
diff --git a/hw/virtex_ml507.c b/hw/virtex_ml507.c
index 79bc0d1..a09b27a 100644
--- a/hw/virtex_ml507.c
+++ b/hw/virtex_ml507.c
@@ -183,12 +183,12 @@ static int xilinx_load_device_tree(target_phys_addr_t addr,
     return fdt_size;
 }
 
-static void virtex_init(ram_addr_t ram_size,
-                        const char *boot_device,
-                        const char *kernel_filename,
-                        const char *kernel_cmdline,
-                        const char *initrd_filename, const char *cpu_model)
+static void virtex_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
     MemoryRegion *address_space_mem = get_system_memory();
     DeviceState *dev;
     PowerPCCPU *cpu;
diff --git a/hw/xen_machine_pv.c b/hw/xen_machine_pv.c
index 4b72aa7..4264703 100644
--- a/hw/xen_machine_pv.c
+++ b/hw/xen_machine_pv.c
@@ -29,13 +29,12 @@
 #include "xen_domainbuild.h"
 #include "blockdev.h"
 
-static void xen_init_pv(ram_addr_t ram_size,
-			const char *boot_device,
-			const char *kernel_filename,
-			const char *kernel_cmdline,
-			const char *initrd_filename,
-			const char *cpu_model)
+static void xen_init_pv(QEMUMachineInitArgs *args)
 {
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     X86CPU *cpu;
     CPUX86State *env;
     DriveInfo *dinfo;
diff --git a/hw/xilinx_zynq.c b/hw/xilinx_zynq.c
index fd46ba2..c55dafb 100644
--- a/hw/xilinx_zynq.c
+++ b/hw/xilinx_zynq.c
@@ -77,10 +77,13 @@ static inline void zynq_init_spi_flashes(uint32_t base_addr, qemu_irq irq)
 
 }
 
-static void zynq_init(ram_addr_t ram_size, const char *boot_device,
-                        const char *kernel_filename, const char *kernel_cmdline,
-                        const char *initrd_filename, const char *cpu_model)
+static void zynq_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     ARMCPU *cpu;
     MemoryRegion *address_space_mem = get_system_memory();
     MemoryRegion *ext_ram = g_new(MemoryRegion, 1);
diff --git a/hw/xtensa_lx60.c b/hw/xtensa_lx60.c
index 3653f65..1fd2c47 100644
--- a/hw/xtensa_lx60.c
+++ b/hw/xtensa_lx60.c
@@ -268,11 +268,14 @@ static void lx_init(const LxBoardDesc *board,
     }
 }
 
-static void xtensa_lx60_init(ram_addr_t ram_size,
-                     const char *boot_device,
-                     const char *kernel_filename, const char *kernel_cmdline,
-                     const char *initrd_filename, const char *cpu_model)
+static void xtensa_lx60_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     static const LxBoardDesc lx60_board = {
         .flash_size = 0x400000,
         .flash_sector_size = 0x10000,
@@ -283,11 +286,14 @@ static void xtensa_lx60_init(ram_addr_t ram_size,
             initrd_filename, cpu_model);
 }
 
-static void xtensa_lx200_init(ram_addr_t ram_size,
-                     const char *boot_device,
-                     const char *kernel_filename, const char *kernel_cmdline,
-                     const char *initrd_filename, const char *cpu_model)
+static void xtensa_lx200_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     static const LxBoardDesc lx200_board = {
         .flash_size = 0x1000000,
         .flash_sector_size = 0x20000,
diff --git a/hw/xtensa_sim.c b/hw/xtensa_sim.c
index 831460b..2e846d8 100644
--- a/hw/xtensa_sim.c
+++ b/hw/xtensa_sim.c
@@ -96,11 +96,14 @@ static void sim_init(ram_addr_t ram_size,
     }
 }
 
-static void xtensa_sim_init(ram_addr_t ram_size,
-                     const char *boot_device,
-                     const char *kernel_filename, const char *kernel_cmdline,
-                     const char *initrd_filename, const char *cpu_model)
+static void xtensa_sim_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     if (!cpu_model) {
         cpu_model = XTENSA_DEFAULT_CPU_MODEL;
     }
diff --git a/hw/z2.c b/hw/z2.c
index 076fad2..f62b806 100644
--- a/hw/z2.c
+++ b/hw/z2.c
@@ -295,11 +295,12 @@ static TypeInfo aer915_info = {
     .class_init    = aer915_class_init,
 };
 
-static void z2_init(ram_addr_t ram_size,
-                const char *boot_device,
-                const char *kernel_filename, const char *kernel_cmdline,
-                const char *initrd_filename, const char *cpu_model)
+static void z2_init(QEMUMachineInitArgs *args)
 {
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     MemoryRegion *address_space_mem = get_system_memory();
     uint32_t sector_len = 0x10000;
     PXA2xxState *mpu;
diff --git a/vl.c b/vl.c
index 5b357a3..ee3c43a 100644
--- a/vl.c
+++ b/vl.c
@@ -3638,8 +3638,13 @@ int main(int argc, char **argv, char **envp)
 
     qdev_machine_init();
 
-    machine->init(ram_size, boot_devices,
-                  kernel_filename, kernel_cmdline, initrd_filename, cpu_model);
+    QEMUMachineInitArgs args = { .ram_size = ram_size,
+                                 .boot_device = boot_devices,
+                                 .kernel_filename = kernel_filename,
+                                 .kernel_cmdline = kernel_cmdline,
+                                 .initrd_filename = initrd_filename,
+                                 .cpu_model = cpu_model };
+    machine->init(&args);
 
     cpu_synchronize_all_post_init();
 
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 20:27:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 20:27:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNrFe-0005Lk-PA; Mon, 15 Oct 2012 20:27:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNrFb-0005Lf-Mk
	for xen-devel@lists.xensource.com; Mon, 15 Oct 2012 20:27:00 +0000
Received: from [85.158.139.211:14199] by server-8.bemta-5.messagelabs.com id
	63/50-23193-2917C705; Mon, 15 Oct 2012 20:26:58 +0000
X-Env-Sender: ehabkost@redhat.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1350332816!22371664!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTg0NjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7183 invoked from network); 15 Oct 2012 20:26:57 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-206.messagelabs.com with SMTP;
	15 Oct 2012 20:26:57 -0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q9FKQIvE024730
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 15 Oct 2012 16:26:19 -0400
Received: from blackpad.lan.raisama.net (vpn1-4-48.gru2.redhat.com
	[10.97.4.48])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q9FKQEIO010629; Mon, 15 Oct 2012 16:26:15 -0400
Received: by blackpad.lan.raisama.net (Postfix, from userid 500)
	id 777E6203604; Mon, 15 Oct 2012 17:27:05 -0300 (BRT)
From: Eduardo Habkost 
To: qemu-devel@nongnu.org
Date: Mon, 15 Oct 2012 17:22:02 -0300
Message-Id: <1350332522-26635-1-git-send-email-ehabkost@redhat.com>
Signed-off-by: Eduardo Habkost 
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: Peter Maydell ,
	Evgeny Voevodin ,
	Peter Crosthwaite ,
	Max Filippov ,
	"Edgar E. Iglesias" ,
	Guan Xuetao , xen-devel@lists.xensource.com,
	Igor Mitsyanko ,
	Magnus Damm , Alexander Graf ,
	=?UTF-8?q?Herv=C3=A9=20Poussineau?= ,
	Maksim Kozlov ,
	Andrzej Zaborowski ,
	Fabien Chouteau , Jan Kiszka ,
	Paul Brook , Blue Swirl ,
	Anthony Liguori ,
	Michael Walle , qemu-ppc@nongnu.org,
	Dmitry Solodkiy ,
	Aurelien Jarno 
Subject: [Xen-devel] [QEMU PATCH v4] create struct for machine
	initialization arguments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This should help us to:
- More easily add or remove machine initialization arguments without
  having to change every single machine init function;
- More easily make mechanical changes involving the machine init
  functions in the future;
- Let machine initialization forward the init arguments to other
  functions more easily.

This change was half-mechanical process: first the struct was added with
the local ram_size, boot_device, kernel_*, initrd_*, and cpu_model local
variable initialization to all functions. Then the compiler helped me
locate the local variables that are unused, so they could be removed.

---

Changes v3 -> v4:
 - Rebase against latest qemu.git master, solved conflicts at
   hw/xilinx_zynq.c

Changes v2 -> v3:
 - Fix typo (missing dot) on main()
 - Fix another mistake on xen_init_pv()

Changes v1 -> v2:
 - Fix mistake on the conversion of pc_xen_hvm_init() and xen_init_pv()


 hw/alpha_dp264.c              |  12 ++--
 hw/an5206.c                   |   8 +--
 hw/axis_dev88.c               |   9 +--
 hw/boards.h                   |  16 +++--
 hw/collie.c                   |   9 +--
 hw/dummy_m68k.c               |   8 +--
 hw/exynos4_boards.c           |  16 ++---
 hw/gumstix.c                  |  11 +---
 hw/highbank.c                 |  10 ++--
 hw/integratorcp.c             |  10 ++--
 hw/kzm.c                      |  10 ++--
 hw/leon3.c                    |  10 ++--
 hw/lm32_boards.c              |  18 +++---
 hw/mainstone.c                |  10 ++--
 hw/mcf5208.c                  |   8 +--
 hw/milkymist.c                |  10 ++--
 hw/mips_fulong2e.c            |   9 ++-
 hw/mips_jazz.c                |  14 ++---
 hw/mips_malta.c               |  10 ++--
 hw/mips_mipssim.c             |  10 ++--
 hw/mips_r4k.c                 |  10 ++--
 hw/musicpal.c                 |   9 +--
 hw/nseries.c                  |  22 ++++---
 hw/null-machine.c             |   7 +--
 hw/omap_sx1.c                 |  22 ++++---
 hw/openrisc_sim.c             |  10 ++--
 hw/palm.c                     |   9 +--
 hw/pc_piix.c                  |  50 ++++++++--------
 hw/petalogix_ml605_mmu.c      |   8 +--
 hw/petalogix_s3adsp1800_mmu.c |   8 +--
 hw/ppc/e500plat.c             |  13 +++--
 hw/ppc/mpc8544ds.c            |  13 +++--
 hw/ppc405_boards.c            |  25 ++++----
 hw/ppc440_bamboo.c            |  12 ++--
 hw/ppc_newworld.c             |  13 +++--
 hw/ppc_oldworld.c             |  13 +++--
 hw/ppc_prep.c                 |  13 +++--
 hw/puv3.c                     |   8 ++-
 hw/r2d.c                      |   9 +--
 hw/realview.c                 |  44 +++++++++-----
 hw/s390-virtio.c              |  13 +++--
 hw/shix.c                     |   6 +-
 hw/spapr.c                    |  13 +++--
 hw/spitz.c                    |  40 ++++++++-----
 hw/stellaris.c                |  14 ++---
 hw/sun4m.c                    | 133 ++++++++++++++++++++++++++----------------
 hw/sun4u.c                    |  39 ++++++++-----
 hw/tosa.c                     |   9 +--
 hw/versatilepb.c              |  22 ++++---
 hw/vexpress.c                 |  26 +++++----
 hw/virtex_ml507.c             |  10 ++--
 hw/xen_machine_pv.c           |  11 ++--
 hw/xilinx_zynq.c              |   9 ++-
 hw/xtensa_lx60.c              |  22 ++++---
 hw/xtensa_sim.c               |  11 ++--
 hw/z2.c                       |   9 +--
 vl.c                          |   9 ++-
 57 files changed, 518 insertions(+), 414 deletions(-)

diff --git a/hw/alpha_dp264.c b/hw/alpha_dp264.c
index 5ea04c7..8f082a6 100644
--- a/hw/alpha_dp264.c
+++ b/hw/alpha_dp264.c
@@ -42,13 +42,13 @@ static int clipper_pci_map_irq(PCIDevice *d, int irq_num)
     return (slot + 1) * 4 + irq_num;
 }
 
-static void clipper_init(ram_addr_t ram_size,
-                         const char *boot_device,
-                         const char *kernel_filename,
-                         const char *kernel_cmdline,
-                         const char *initrd_filename,
-                         const char *cpu_model)
+static void clipper_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     CPUAlphaState *cpus[4];
     PCIBus *pci_bus;
     ISABus *isa_bus;
diff --git a/hw/an5206.c b/hw/an5206.c
index 25407c0..042c5fc 100644
--- a/hw/an5206.c
+++ b/hw/an5206.c
@@ -19,11 +19,11 @@
 
 /* Board init.  */
 
-static void an5206_init(ram_addr_t ram_size,
-                     const char *boot_device,
-                     const char *kernel_filename, const char *kernel_cmdline,
-                     const char *initrd_filename, const char *cpu_model)
+static void an5206_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
     CPUM68KState *env;
     int kernel_size;
     uint64_t elf_entry;
diff --git a/hw/axis_dev88.c b/hw/axis_dev88.c
index eab6327..2fd7356 100644
--- a/hw/axis_dev88.c
+++ b/hw/axis_dev88.c
@@ -242,11 +242,12 @@ static const MemoryRegionOps gpio_ops = {
 static struct cris_load_info li;
 
 static
-void axisdev88_init (ram_addr_t ram_size,
-                     const char *boot_device,
-                     const char *kernel_filename, const char *kernel_cmdline,
-                     const char *initrd_filename, const char *cpu_model)
+void axisdev88_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
     CRISCPU *cpu;
     CPUCRISState *env;
     DeviceState *dev;
diff --git a/hw/boards.h b/hw/boards.h
index a2e0a54..813d0e5 100644
--- a/hw/boards.h
+++ b/hw/boards.h
@@ -5,12 +5,16 @@
 
 #include "qdev.h"
 
-typedef void QEMUMachineInitFunc(ram_addr_t ram_size,
-                                 const char *boot_device,
-                                 const char *kernel_filename,
-                                 const char *kernel_cmdline,
-                                 const char *initrd_filename,
-                                 const char *cpu_model);
+typedef struct QEMUMachineInitArgs {
+    ram_addr_t ram_size;
+    const char *boot_device;
+    const char *kernel_filename;
+    const char *kernel_cmdline;
+    const char *initrd_filename;
+    const char *cpu_model;
+} QEMUMachineInitArgs;
+
+typedef void QEMUMachineInitFunc(QEMUMachineInitArgs *args);
 
 typedef void QEMUMachineResetFunc(void);
 
diff --git a/hw/collie.c b/hw/collie.c
index 56f89a9..695982a 100644
--- a/hw/collie.c
+++ b/hw/collie.c
@@ -23,11 +23,12 @@ static struct arm_boot_info collie_binfo = {
     .ram_size = 0x20000000,
 };
 
-static void collie_init(ram_addr_t ram_size,
-                const char *boot_device,
-                const char *kernel_filename, const char *kernel_cmdline,
-                const char *initrd_filename, const char *cpu_model)
+static void collie_init(QEMUMachineInitArgs *args)
 {
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     StrongARMState *s;
     DriveInfo *dinfo;
     MemoryRegion *sysmem = get_system_memory();
diff --git a/hw/dummy_m68k.c b/hw/dummy_m68k.c
index 7cc7a99..f436a0c 100644
--- a/hw/dummy_m68k.c
+++ b/hw/dummy_m68k.c
@@ -16,11 +16,11 @@
 
 /* Board init.  */
 
-static void dummy_m68k_init(ram_addr_t ram_size,
-                     const char *boot_device,
-                     const char *kernel_filename, const char *kernel_cmdline,
-                     const char *initrd_filename, const char *cpu_model)
+static void dummy_m68k_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
     CPUM68KState *env;
     MemoryRegion *address_space_mem =  get_system_memory();
     MemoryRegion *ram = g_new(MemoryRegion, 1);
diff --git a/hw/exynos4_boards.c b/hw/exynos4_boards.c
index 4bb0a60..4951064 100644
--- a/hw/exynos4_boards.c
+++ b/hw/exynos4_boards.c
@@ -130,22 +130,22 @@ static Exynos4210State *exynos4_boards_init_common(
             exynos4_board_ram_size[board_type]);
 }
 
-static void nuri_init(ram_addr_t ram_size,
-        const char *boot_device,
-        const char *kernel_filename, const char *kernel_cmdline,
-        const char *initrd_filename, const char *cpu_model)
+static void nuri_init(QEMUMachineInitArgs *args)
 {
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     exynos4_boards_init_common(kernel_filename, kernel_cmdline,
                 initrd_filename, EXYNOS4_BOARD_NURI);
 
     arm_load_kernel(arm_env_get_cpu(first_cpu), &exynos4_board_binfo);
 }
 
-static void smdkc210_init(ram_addr_t ram_size,
-        const char *boot_device,
-        const char *kernel_filename, const char *kernel_cmdline,
-        const char *initrd_filename, const char *cpu_model)
+static void smdkc210_init(QEMUMachineInitArgs *args)
 {
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     Exynos4210State *s = exynos4_boards_init_common(kernel_filename,
             kernel_cmdline, initrd_filename, EXYNOS4_BOARD_SMDKC210);
 
diff --git a/hw/gumstix.c b/hw/gumstix.c
index 13a36ea..4103a88 100644
--- a/hw/gumstix.c
+++ b/hw/gumstix.c
@@ -45,10 +45,7 @@
 
 static const int sector_len = 128 * 1024;
 
-static void connex_init(ram_addr_t ram_size,
-                const char *boot_device,
-                const char *kernel_filename, const char *kernel_cmdline,
-                const char *initrd_filename, const char *cpu_model)
+static void connex_init(QEMUMachineInitArgs *args)
 {
     PXA2xxState *cpu;
     DriveInfo *dinfo;
@@ -84,11 +81,9 @@ static void connex_init(ram_addr_t ram_size,
                     qdev_get_gpio_in(cpu->gpio, 36));
 }
 
-static void verdex_init(ram_addr_t ram_size,
-                const char *boot_device,
-                const char *kernel_filename, const char *kernel_cmdline,
-                const char *initrd_filename, const char *cpu_model)
+static void verdex_init(QEMUMachineInitArgs *args)
 {
+    const char *cpu_model = args->cpu_model;
     PXA2xxState *cpu;
     DriveInfo *dinfo;
     int be;
diff --git a/hw/highbank.c b/hw/highbank.c
index 11aa131..15036b6 100644
--- a/hw/highbank.c
+++ b/hw/highbank.c
@@ -187,11 +187,13 @@ static struct arm_boot_info highbank_binfo;
  * 32-bit host, set the reg value of memory to 0xf7ff00000 in the
  * device tree and pass -m 2047 to QEMU.
  */
-static void highbank_init(ram_addr_t ram_size,
-                     const char *boot_device,
-                     const char *kernel_filename, const char *kernel_cmdline,
-                     const char *initrd_filename, const char *cpu_model)
+static void highbank_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     DeviceState *dev;
     SysBusDevice *busdev;
     qemu_irq *irqp;
diff --git a/hw/integratorcp.c b/hw/integratorcp.c
index d0e2e90..ac0ea83 100644
--- a/hw/integratorcp.c
+++ b/hw/integratorcp.c
@@ -438,11 +438,13 @@ static struct arm_boot_info integrator_binfo = {
     .board_id = 0x113,
 };
 
-static void integratorcp_init(ram_addr_t ram_size,
-                     const char *boot_device,
-                     const char *kernel_filename, const char *kernel_cmdline,
-                     const char *initrd_filename, const char *cpu_model)
+static void integratorcp_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     ARMCPU *cpu;
     MemoryRegion *address_space_mem = get_system_memory();
     MemoryRegion *ram = g_new(MemoryRegion, 1);
diff --git a/hw/kzm.c b/hw/kzm.c
index 68cd1b4..d1266d9 100644
--- a/hw/kzm.c
+++ b/hw/kzm.c
@@ -70,11 +70,13 @@ static struct arm_boot_info kzm_binfo = {
     .board_id = 1722,
 };
 
-static void kzm_init(ram_addr_t ram_size,
-                     const char *boot_device,
-                     const char *kernel_filename, const char *kernel_cmdline,
-                     const char *initrd_filename, const char *cpu_model)
+static void kzm_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     ARMCPU *cpu;
     MemoryRegion *address_space_mem = get_system_memory();
     MemoryRegion *ram = g_new(MemoryRegion, 1);
diff --git a/hw/leon3.c b/hw/leon3.c
index 7a9729d..7742738 100644
--- a/hw/leon3.c
+++ b/hw/leon3.c
@@ -94,13 +94,11 @@ static void leon3_set_pil_in(void *opaque, uint32_t pil_in)
     }
 }
 
-static void leon3_generic_hw_init(ram_addr_t  ram_size,
-                                  const char *boot_device,
-                                  const char *kernel_filename,
-                                  const char *kernel_cmdline,
-                                  const char *initrd_filename,
-                                  const char *cpu_model)
+static void leon3_generic_hw_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
     SPARCCPU *cpu;
     CPUSPARCState   *env;
     MemoryRegion *address_space_mem = get_system_memory();
diff --git a/hw/lm32_boards.c b/hw/lm32_boards.c
index b76d800..c5a62c8 100644
--- a/hw/lm32_boards.c
+++ b/hw/lm32_boards.c
@@ -69,12 +69,10 @@ static void main_cpu_reset(void *opaque)
     env->deba = reset_info->flash_base;
 }
 
-static void lm32_evr_init(ram_addr_t ram_size_not_used,
-                          const char *boot_device,
-                          const char *kernel_filename,
-                          const char *kernel_cmdline,
-                          const char *initrd_filename, const char *cpu_model)
+static void lm32_evr_init(QEMUMachineInitArgs *args)
 {
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
     LM32CPU *cpu;
     CPULM32State *env;
     DriveInfo *dinfo;
@@ -159,12 +157,12 @@ static void lm32_evr_init(ram_addr_t ram_size_not_used,
     qemu_register_reset(main_cpu_reset, reset_info);
 }
 
-static void lm32_uclinux_init(ram_addr_t ram_size_not_used,
-                          const char *boot_device,
-                          const char *kernel_filename,
-                          const char *kernel_cmdline,
-                          const char *initrd_filename, const char *cpu_model)
+static void lm32_uclinux_init(QEMUMachineInitArgs *args)
 {
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     LM32CPU *cpu;
     CPULM32State *env;
     DriveInfo *dinfo;
diff --git a/hw/mainstone.c b/hw/mainstone.c
index 97687b6..c0d6034 100644
--- a/hw/mainstone.c
+++ b/hw/mainstone.c
@@ -171,11 +171,13 @@ static void mainstone_common_init(MemoryRegion *address_space_mem,
     arm_load_kernel(mpu->cpu, &mainstone_binfo);
 }
 
-static void mainstone_init(ram_addr_t ram_size,
-                const char *boot_device,
-                const char *kernel_filename, const char *kernel_cmdline,
-                const char *initrd_filename, const char *cpu_model)
+static void mainstone_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     mainstone_common_init(get_system_memory(), ram_size, kernel_filename,
                 kernel_cmdline, initrd_filename, cpu_model, mainstone, 0x196);
 }
diff --git a/hw/mcf5208.c b/hw/mcf5208.c
index ee25b1b..688bc3c 100644
--- a/hw/mcf5208.c
+++ b/hw/mcf5208.c
@@ -187,11 +187,11 @@ static void mcf5208_sys_init(MemoryRegion *address_space, qemu_irq *pic)
     }
 }
 
-static void mcf5208evb_init(ram_addr_t ram_size,
-                     const char *boot_device,
-                     const char *kernel_filename, const char *kernel_cmdline,
-                     const char *initrd_filename, const char *cpu_model)
+static void mcf5208evb_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
     CPUM68KState *env;
     int kernel_size;
     uint64_t elf_entry;
diff --git a/hw/milkymist.c b/hw/milkymist.c
index 2e7235b..ca9ed43 100644
--- a/hw/milkymist.c
+++ b/hw/milkymist.c
@@ -73,12 +73,12 @@ static void main_cpu_reset(void *opaque)
 }
 
 static void
-milkymist_init(ram_addr_t ram_size_not_used,
-                          const char *boot_device,
-                          const char *kernel_filename,
-                          const char *kernel_cmdline,
-                          const char *initrd_filename, const char *cpu_model)
+milkymist_init(QEMUMachineInitArgs *args)
 {
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     LM32CPU *cpu;
     CPULM32State *env;
     int kernel_size;
diff --git a/hw/mips_fulong2e.c b/hw/mips_fulong2e.c
index d4a8672..fb50a1f 100644
--- a/hw/mips_fulong2e.c
+++ b/hw/mips_fulong2e.c
@@ -256,10 +256,13 @@ static void cpu_request_exit(void *opaque, int irq, int level)
     }
 }
 
-static void mips_fulong2e_init(ram_addr_t ram_size, const char *boot_device,
-                        const char *kernel_filename, const char *kernel_cmdline,
-                        const char *initrd_filename, const char *cpu_model)
+static void mips_fulong2e_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     char *filename;
     MemoryRegion *address_space_mem = get_system_memory();
     MemoryRegion *ram = g_new(MemoryRegion, 1);
diff --git a/hw/mips_jazz.c b/hw/mips_jazz.c
index db927f1..14df4d7 100644
--- a/hw/mips_jazz.c
+++ b/hw/mips_jazz.c
@@ -302,21 +302,19 @@ static void mips_jazz_init(MemoryRegion *address_space,
 }
 
 static
-void mips_magnum_init (ram_addr_t ram_size,
-                       const char *boot_device,
-                       const char *kernel_filename, const char *kernel_cmdline,
-                       const char *initrd_filename, const char *cpu_model)
+void mips_magnum_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
         mips_jazz_init(get_system_memory(), get_system_io(),
                        ram_size, cpu_model, JAZZ_MAGNUM);
 }
 
 static
-void mips_pica61_init (ram_addr_t ram_size,
-                       const char *boot_device,
-                       const char *kernel_filename, const char *kernel_cmdline,
-                       const char *initrd_filename, const char *cpu_model)
+void mips_pica61_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
     mips_jazz_init(get_system_memory(), get_system_io(),
                    ram_size, cpu_model, JAZZ_PICA61);
 }
diff --git a/hw/mips_malta.c b/hw/mips_malta.c
index 632b466..ad4910f 100644
--- a/hw/mips_malta.c
+++ b/hw/mips_malta.c
@@ -775,11 +775,13 @@ static void cpu_request_exit(void *opaque, int irq, int level)
 }
 
 static
-void mips_malta_init (ram_addr_t ram_size,
-                      const char *boot_device,
-                      const char *kernel_filename, const char *kernel_cmdline,
-                      const char *initrd_filename, const char *cpu_model)
+void mips_malta_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     char *filename;
     pflash_t *fl;
     MemoryRegion *system_memory = get_system_memory();
diff --git a/hw/mips_mipssim.c b/hw/mips_mipssim.c
index 830f635..a1d3945 100644
--- a/hw/mips_mipssim.c
+++ b/hw/mips_mipssim.c
@@ -131,11 +131,13 @@ static void mipsnet_init(int base, qemu_irq irq, NICInfo *nd)
 }
 
 static void
-mips_mipssim_init (ram_addr_t ram_size,
-                   const char *boot_device,
-                   const char *kernel_filename, const char *kernel_cmdline,
-                   const char *initrd_filename, const char *cpu_model)
+mips_mipssim_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     char *filename;
     MemoryRegion *address_space_mem = get_system_memory();
     MemoryRegion *ram = g_new(MemoryRegion, 1);
diff --git a/hw/mips_r4k.c b/hw/mips_r4k.c
index 967a76e..b73cdc3 100644
--- a/hw/mips_r4k.c
+++ b/hw/mips_r4k.c
@@ -151,11 +151,13 @@ static void main_cpu_reset(void *opaque)
 
 static const int sector_len = 32 * 1024;
 static
-void mips_r4k_init (ram_addr_t ram_size,
-                    const char *boot_device,
-                    const char *kernel_filename, const char *kernel_cmdline,
-                    const char *initrd_filename, const char *cpu_model)
+void mips_r4k_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     char *filename;
     MemoryRegion *address_space_mem = get_system_memory();
     MemoryRegion *ram = g_new(MemoryRegion, 1);
diff --git a/hw/musicpal.c b/hw/musicpal.c
index f305e21..f06814c 100644
--- a/hw/musicpal.c
+++ b/hw/musicpal.c
@@ -1508,11 +1508,12 @@ static struct arm_boot_info musicpal_binfo = {
     .board_id = 0x20e,
 };
 
-static void musicpal_init(ram_addr_t ram_size,
-               const char *boot_device,
-               const char *kernel_filename, const char *kernel_cmdline,
-               const char *initrd_filename, const char *cpu_model)
+static void musicpal_init(QEMUMachineInitArgs *args)
 {
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     ARMCPU *cpu;
     qemu_irq *cpu_pic;
     qemu_irq pic[32];
diff --git a/hw/nseries.c b/hw/nseries.c
index 6df71eb..7ada90d 100644
--- a/hw/nseries.c
+++ b/hw/nseries.c
@@ -1397,21 +1397,27 @@ static struct arm_boot_info n810_binfo = {
     .atag_board = n810_atag_setup,
 };
 
-static void n800_init(ram_addr_t ram_size,
-                const char *boot_device,
-                const char *kernel_filename, const char *kernel_cmdline,
-                const char *initrd_filename, const char *cpu_model)
+static void n800_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     return n8x0_init(ram_size, boot_device,
                     kernel_filename, kernel_cmdline, initrd_filename,
                     cpu_model, &n800_binfo, 800);
 }
 
-static void n810_init(ram_addr_t ram_size,
-                const char *boot_device,
-                const char *kernel_filename, const char *kernel_cmdline,
-                const char *initrd_filename, const char *cpu_model)
+static void n810_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     return n8x0_init(ram_size, boot_device,
                     kernel_filename, kernel_cmdline, initrd_filename,
                     cpu_model, &n810_binfo, 810);
diff --git a/hw/null-machine.c b/hw/null-machine.c
index 69910d3..d813c08 100644
--- a/hw/null-machine.c
+++ b/hw/null-machine.c
@@ -15,12 +15,7 @@
 #include "hw/hw.h"
 #include "hw/boards.h"
 
-static void machine_none_init(ram_addr_t ram_size,
-                              const char *boot_device,
-                              const char *kernel_filename,
-                              const char *kernel_cmdline,
-                              const char *initrd_filename,
-                              const char *cpu_model)
+static void machine_none_init(QEMUMachineInitArgs *args)
 {
 }
 
diff --git a/hw/omap_sx1.c b/hw/omap_sx1.c
index abca341..ad17487 100644
--- a/hw/omap_sx1.c
+++ b/hw/omap_sx1.c
@@ -209,20 +209,26 @@ static void sx1_init(ram_addr_t ram_size,
     //~ qemu_console_resize(ds, 640, 480);
 }
 
-static void sx1_init_v1(ram_addr_t ram_size,
-                const char *boot_device,
-                const char *kernel_filename, const char *kernel_cmdline,
-                const char *initrd_filename, const char *cpu_model)
+static void sx1_init_v1(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     sx1_init(ram_size, boot_device, kernel_filename,
                 kernel_cmdline, initrd_filename, cpu_model, 1);
 }
 
-static void sx1_init_v2(ram_addr_t ram_size,
-                const char *boot_device,
-                const char *kernel_filename, const char *kernel_cmdline,
-                const char *initrd_filename, const char *cpu_model)
+static void sx1_init_v2(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     sx1_init(ram_size, boot_device, kernel_filename,
                 kernel_cmdline, initrd_filename, cpu_model, 2);
 }
diff --git a/hw/openrisc_sim.c b/hw/openrisc_sim.c
index 55e97f0..e96a944 100644
--- a/hw/openrisc_sim.c
+++ b/hw/openrisc_sim.c
@@ -90,13 +90,11 @@ static void cpu_openrisc_load_kernel(ram_addr_t ram_size,
     cpu->env.pc = entry;
 }
 
-static void openrisc_sim_init(ram_addr_t ram_size,
-                              const char *boot_device,
-                              const char *kernel_filename,
-                              const char *kernel_cmdline,
-                              const char *initrd_filename,
-                              const char *cpu_model)
+static void openrisc_sim_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
    OpenRISCCPU *cpu = NULL;
     MemoryRegion *ram;
     int n;
diff --git a/hw/palm.c b/hw/palm.c
index bacdc90..032b8d6 100644
--- a/hw/palm.c
+++ b/hw/palm.c
@@ -190,11 +190,12 @@ static struct arm_boot_info palmte_binfo = {
     .board_id = 0x331,
 };
 
-static void palmte_init(ram_addr_t ram_size,
-                const char *boot_device,
-                const char *kernel_filename, const char *kernel_cmdline,
-                const char *initrd_filename, const char *cpu_model)
+static void palmte_init(QEMUMachineInitArgs *args)
 {
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     MemoryRegion *address_space_mem = get_system_memory();
     struct omap_mpu_state_s *mpu;
     int flash_size = 0x00800000;
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index 82364ab..36e165f 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -287,13 +287,14 @@ static void pc_init1(MemoryRegion *system_memory,
     }
 }
 
-static void pc_init_pci(ram_addr_t ram_size,
-                        const char *boot_device,
-                        const char *kernel_filename,
-                        const char *kernel_cmdline,
-                        const char *initrd_filename,
-                        const char *cpu_model)
+static void pc_init_pci(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     pc_init1(get_system_memory(),
              get_system_io(),
              ram_size, boot_device,
@@ -301,13 +302,14 @@ static void pc_init_pci(ram_addr_t ram_size,
              initrd_filename, cpu_model, 1, 1);
 }
 
-static void pc_init_pci_no_kvmclock(ram_addr_t ram_size,
-                                    const char *boot_device,
-                                    const char *kernel_filename,
-                                    const char *kernel_cmdline,
-                                    const char *initrd_filename,
-                                    const char *cpu_model)
+static void pc_init_pci_no_kvmclock(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     pc_init1(get_system_memory(),
              get_system_io(),
              ram_size, boot_device,
@@ -315,13 +317,14 @@ static void pc_init_pci_no_kvmclock(ram_addr_t ram_size,
              initrd_filename, cpu_model, 1, 0);
 }
 
-static void pc_init_isa(ram_addr_t ram_size,
-                        const char *boot_device,
-                        const char *kernel_filename,
-                        const char *kernel_cmdline,
-                        const char *initrd_filename,
-                        const char *cpu_model)
+static void pc_init_isa(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     if (cpu_model == NULL)
         cpu_model = "486";
     pc_init1(get_system_memory(),
@@ -332,19 +335,12 @@ static void pc_init_isa(ram_addr_t ram_size,
 }
 
 #ifdef CONFIG_XEN
-static void pc_xen_hvm_init(ram_addr_t ram_size,
-                            const char *boot_device,
-                            const char *kernel_filename,
-                            const char *kernel_cmdline,
-                            const char *initrd_filename,
-                            const char *cpu_model)
+static void pc_xen_hvm_init(QEMUMachineInitArgs *args)
 {
     if (xen_hvm_init() != 0) {
         hw_error("xen hardware virtual machine initialisation failed");
     }
-    pc_init_pci_no_kvmclock(ram_size, boot_device,
-                            kernel_filename, kernel_cmdline,
-                            initrd_filename, cpu_model);
+    pc_init_pci_no_kvmclock(args);
     xen_vcpu_init();
 }
 #endif
diff --git a/hw/petalogix_ml605_mmu.c b/hw/petalogix_ml605_mmu.c
index b9bfbed..39df251 100644
--- a/hw/petalogix_ml605_mmu.c
+++ b/hw/petalogix_ml605_mmu.c
@@ -73,12 +73,10 @@ static void machine_cpu_reset(MicroBlazeCPU *cpu)
 }
 
 static void
-petalogix_ml605_init(ram_addr_t ram_size,
-                          const char *boot_device,
-                          const char *kernel_filename,
-                          const char *kernel_cmdline,
-                          const char *initrd_filename, const char *cpu_model)
+petalogix_ml605_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
     MemoryRegion *address_space_mem = get_system_memory();
     DeviceState *dev, *dma, *eth0;
     MicroBlazeCPU *cpu;
diff --git a/hw/petalogix_s3adsp1800_mmu.c b/hw/petalogix_s3adsp1800_mmu.c
index 2cf6882..71c32ce 100644
--- a/hw/petalogix_s3adsp1800_mmu.c
+++ b/hw/petalogix_s3adsp1800_mmu.c
@@ -57,12 +57,10 @@ static void machine_cpu_reset(MicroBlazeCPU *cpu)
 }
 
 static void
-petalogix_s3adsp1800_init(ram_addr_t ram_size,
-                          const char *boot_device,
-                          const char *kernel_filename,
-                          const char *kernel_cmdline,
-                          const char *initrd_filename, const char *cpu_model)
+petalogix_s3adsp1800_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
     DeviceState *dev;
     MicroBlazeCPU *cpu;
     CPUMBState *env;
diff --git a/hw/ppc/e500plat.c b/hw/ppc/e500plat.c
index 60a5cb3..4cfb940 100644
--- a/hw/ppc/e500plat.c
+++ b/hw/ppc/e500plat.c
@@ -25,13 +25,14 @@ static void e500plat_fixup_devtree(PPCE500Params *params, void *fdt)
                          sizeof(compatible));
 }
 
-static void e500plat_init(ram_addr_t ram_size,
-                           const char *boot_device,
-                           const char *kernel_filename,
-                           const char *kernel_cmdline,
-                           const char *initrd_filename,
-                           const char *cpu_model)
+static void e500plat_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *boot_device = args->boot_device;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     PPCE500Params params = {
         .ram_size = ram_size,
         .boot_device = boot_device,
diff --git a/hw/ppc/mpc8544ds.c b/hw/ppc/mpc8544ds.c
index 984d21c..e651661 100644
--- a/hw/ppc/mpc8544ds.c
+++ b/hw/ppc/mpc8544ds.c
@@ -25,13 +25,14 @@ static void mpc8544ds_fixup_devtree(PPCE500Params *params, void *fdt)
                          sizeof(compatible));
 }
 
-static void mpc8544ds_init(ram_addr_t ram_size,
-                           const char *boot_device,
-                           const char *kernel_filename,
-                           const char *kernel_cmdline,
-                           const char *initrd_filename,
-                           const char *cpu_model)
+static void mpc8544ds_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *boot_device = args->boot_device;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     PPCE500Params params = {
         .ram_size = ram_size,
         .boot_device = boot_device,
diff --git a/hw/ppc405_boards.c b/hw/ppc405_boards.c
index 476775d..e848cb0 100644
--- a/hw/ppc405_boards.c
+++ b/hw/ppc405_boards.c
@@ -158,7 +158,7 @@ static void ref405ep_fpga_reset (void *opaque)
     fpga->reg1 = 0x0F;
 }
 
-static void ref405ep_fpga_init (MemoryRegion *sysmem, uint32_t base)
+static void ref405ep_fpga_init(MemoryRegion *sysmem, uint32_t base)
 {
     ref405ep_fpga_t *fpga;
     MemoryRegion *fpga_memory = g_new(MemoryRegion, 1);
@@ -170,13 +170,12 @@ static void ref405ep_fpga_init (MemoryRegion *sysmem, uint32_t base)
     qemu_register_reset(&ref405ep_fpga_reset, fpga);
 }
 
-static void ref405ep_init (ram_addr_t ram_size,
-                           const char *boot_device,
-                           const char *kernel_filename,
-                           const char *kernel_cmdline,
-                           const char *initrd_filename,
-                           const char *cpu_model)
+static void ref405ep_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     char *filename;
     ppc4xx_bd_info_t bd;
     CPUPPCState *env;
@@ -484,7 +483,7 @@ static void taihu_cpld_reset (void *opaque)
     cpld->reg1 = 0x80;
 }
 
-static void taihu_cpld_init (MemoryRegion *sysmem, uint32_t base)
+static void taihu_cpld_init(MemoryRegion *sysmem, uint32_t base)
 {
     taihu_cpld_t *cpld;
     MemoryRegion *cpld_memory = g_new(MemoryRegion, 1);
@@ -495,13 +494,11 @@ static void taihu_cpld_init (MemoryRegion *sysmem, uint32_t base)
     qemu_register_reset(&taihu_cpld_reset, cpld);
 }
 
-static void taihu_405ep_init(ram_addr_t ram_size,
-                             const char *boot_device,
-                             const char *kernel_filename,
-                             const char *kernel_cmdline,
-                             const char *initrd_filename,
-                             const char *cpu_model)
+static void taihu_405ep_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *kernel_filename = args->kernel_filename;
+    const char *initrd_filename = args->initrd_filename;
     char *filename;
     qemu_irq *pic;
     MemoryRegion *sysmem = get_system_memory();
diff --git a/hw/ppc440_bamboo.c b/hw/ppc440_bamboo.c
index c198071..78e7985 100644
--- a/hw/ppc440_bamboo.c
+++ b/hw/ppc440_bamboo.c
@@ -157,13 +157,13 @@ static void main_cpu_reset(void *opaque)
     mmubooke_create_initial_mapping(env, 0, 0);
 }
 
-static void bamboo_init(ram_addr_t ram_size,
-                        const char *boot_device,
-                        const char *kernel_filename,
-                        const char *kernel_cmdline,
-                        const char *initrd_filename,
-                        const char *cpu_model)
+static void bamboo_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     unsigned int pci_irq_nrs[4] = { 28, 27, 26, 25 };
     MemoryRegion *address_space_mem = get_system_memory();
     MemoryRegion *ram_memories
diff --git a/hw/ppc_newworld.c b/hw/ppc_newworld.c
index b8d3c9c..a265445 100644
--- a/hw/ppc_newworld.c
+++ b/hw/ppc_newworld.c
@@ -128,13 +128,14 @@ static void ppc_core99_reset(void *opaque)
 }
 
 /* PowerPC Mac99 hardware initialisation */
-static void ppc_core99_init (ram_addr_t ram_size,
-                             const char *boot_device,
-                             const char *kernel_filename,
-                             const char *kernel_cmdline,
-                             const char *initrd_filename,
-                             const char *cpu_model)
+static void ppc_core99_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     PowerPCCPU *cpu = NULL;
     CPUPPCState *env = NULL;
     char *filename;
diff --git a/hw/ppc_oldworld.c b/hw/ppc_oldworld.c
index 2c4a478..de33408 100644
--- a/hw/ppc_oldworld.c
+++ b/hw/ppc_oldworld.c
@@ -71,13 +71,14 @@ static void ppc_heathrow_reset(void *opaque)
     cpu_reset(CPU(cpu));
 }
 
-static void ppc_heathrow_init (ram_addr_t ram_size,
-                               const char *boot_device,
-                               const char *kernel_filename,
-                               const char *kernel_cmdline,
-                               const char *initrd_filename,
-                               const char *cpu_model)
+static void ppc_heathrow_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     MemoryRegion *sysmem = get_system_memory();
     PowerPCCPU *cpu = NULL;
     CPUPPCState *env = NULL;
diff --git a/hw/ppc_prep.c b/hw/ppc_prep.c
index 1544430..b426891 100644
--- a/hw/ppc_prep.c
+++ b/hw/ppc_prep.c
@@ -447,13 +447,14 @@ static void ppc_prep_reset(void *opaque)
 }
 
 /* PowerPC PREP hardware initialisation */
-static void ppc_prep_init (ram_addr_t ram_size,
-                           const char *boot_device,
-                           const char *kernel_filename,
-                           const char *kernel_cmdline,
-                           const char *initrd_filename,
-                           const char *cpu_model)
+static void ppc_prep_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     MemoryRegion *sysmem = get_system_memory();
     PowerPCCPU *cpu = NULL;
     CPUPPCState *env = NULL;
diff --git a/hw/puv3.c b/hw/puv3.c
index 43f7216..764799c 100644
--- a/hw/puv3.c
+++ b/hw/puv3.c
@@ -91,10 +91,12 @@ static void puv3_load_kernel(const char *kernel_filename)
     graphic_console_init(NULL, NULL, NULL, NULL, NULL);
 }
 
-static void puv3_init(ram_addr_t ram_size, const char *boot_device,
-                     const char *kernel_filename, const char *kernel_cmdline,
-                     const char *initrd_filename, const char *cpu_model)
+static void puv3_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *initrd_filename = args->initrd_filename;
     CPUUniCore32State *env;
 
     if (initrd_filename) {
diff --git a/hw/r2d.c b/hw/r2d.c
index 1bc191f..3cb6942 100644
--- a/hw/r2d.c
+++ b/hw/r2d.c
@@ -219,11 +219,12 @@ static struct QEMU_PACKED
     char kernel_cmdline[256];
 } boot_params;
 
-static void r2d_init(ram_addr_t ram_size,
-              const char *boot_device,
-	      const char *kernel_filename, const char *kernel_cmdline,
-	      const char *initrd_filename, const char *cpu_model)
+static void r2d_init(QEMUMachineInitArgs *args)
 {
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     SuperHCPU *cpu;
     CPUSH4State *env;
     ResetData *reset_info;
diff --git a/hw/realview.c b/hw/realview.c
index 19db4d0..8dc4be6 100644
--- a/hw/realview.c
+++ b/hw/realview.c
@@ -330,11 +330,14 @@ static void realview_init(ram_addr_t ram_size,
     arm_load_kernel(arm_env_get_cpu(first_cpu), &realview_binfo);
 }
 
-static void realview_eb_init(ram_addr_t ram_size,
-                     const char *boot_device,
-                     const char *kernel_filename, const char *kernel_cmdline,
-                     const char *initrd_filename, const char *cpu_model)
+static void realview_eb_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     if (!cpu_model) {
         cpu_model = "arm926";
     }
@@ -342,11 +345,14 @@ static void realview_eb_init(ram_addr_t ram_size,
                   initrd_filename, cpu_model, BOARD_EB);
 }
 
-static void realview_eb_mpcore_init(ram_addr_t ram_size,
-                     const char *boot_device,
-                     const char *kernel_filename, const char *kernel_cmdline,
-                     const char *initrd_filename, const char *cpu_model)
+static void realview_eb_mpcore_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     if (!cpu_model) {
         cpu_model = "arm11mpcore";
     }
@@ -354,11 +360,14 @@ static void realview_eb_mpcore_init(ram_addr_t ram_size,
                   initrd_filename, cpu_model, BOARD_EB_MPCORE);
 }
 
-static void realview_pb_a8_init(ram_addr_t ram_size,
-                     const char *boot_device,
-                     const char *kernel_filename, const char *kernel_cmdline,
-                     const char *initrd_filename, const char *cpu_model)
+static void realview_pb_a8_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     if (!cpu_model) {
         cpu_model = "cortex-a8";
     }
@@ -366,11 +375,14 @@ static void realview_pb_a8_init(ram_addr_t ram_size,
                   initrd_filename, cpu_model, BOARD_PB_A8);
 }
 
-static void realview_pbx_a9_init(ram_addr_t ram_size,
-                     const char *boot_device,
-                     const char *kernel_filename, const char *kernel_cmdline,
-                     const char *initrd_filename, const char *cpu_model)
+static void realview_pbx_a9_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     if (!cpu_model) {
         cpu_model = "cortex-a9";
     }
diff --git a/hw/s390-virtio.c b/hw/s390-virtio.c
index 47eed35..39ff178 100644
--- a/hw/s390-virtio.c
+++ b/hw/s390-virtio.c
@@ -151,13 +151,14 @@ unsigned s390_del_running_cpu(CPUS390XState *env)
 }
 
 /* PC hardware initialisation */
-static void s390_init(ram_addr_t my_ram_size,
-                      const char *boot_device,
-                      const char *kernel_filename,
-                      const char *kernel_cmdline,
-                      const char *initrd_filename,
-                      const char *cpu_model)
+static void s390_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t my_ram_size = args->ram_size;
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     CPUS390XState *env = NULL;
     MemoryRegion *sysmem = get_system_memory();
     MemoryRegion *ram = g_new(MemoryRegion, 1);
diff --git a/hw/shix.c b/hw/shix.c
index dd9ce17..b56dd54 100644
--- a/hw/shix.c
+++ b/hw/shix.c
@@ -37,11 +37,9 @@
 #define BIOS_FILENAME "shix_bios.bin"
 #define BIOS_ADDRESS 0xA0000000
 
-static void shix_init(ram_addr_t ram_size,
-               const char *boot_device,
-	       const char *kernel_filename, const char *kernel_cmdline,
-	       const char *initrd_filename, const char *cpu_model)
+static void shix_init(QEMUMachineInitArgs *args)
 {
+    const char *cpu_model = args->cpu_model;
     int ret;
     CPUSH4State *env;
     struct SH7750State *s;
diff --git a/hw/spapr.c b/hw/spapr.c
index 09b8e99..637b3fb 100644
--- a/hw/spapr.c
+++ b/hw/spapr.c
@@ -665,13 +665,14 @@ static int spapr_vga_init(PCIBus *pci_bus)
 }
 
 /* pSeries LPAR / sPAPR hardware init */
-static void ppc_spapr_init(ram_addr_t ram_size,
-                           const char *boot_device,
-                           const char *kernel_filename,
-                           const char *kernel_cmdline,
-                           const char *initrd_filename,
-                           const char *cpu_model)
+static void ppc_spapr_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     PowerPCCPU *cpu;
     CPUPPCState *env;
     PCIHostState *phb;
diff --git a/hw/spitz.c b/hw/spitz.c
index 24346dc..2942626 100644
--- a/hw/spitz.c
+++ b/hw/spitz.c
@@ -936,38 +936,46 @@ static void spitz_common_init(ram_addr_t ram_size,
     sl_bootparam_write(SL_PXA_PARAM_BASE);
 }
 
-static void spitz_init(ram_addr_t ram_size,
-                const char *boot_device,
-                const char *kernel_filename, const char *kernel_cmdline,
-                const char *initrd_filename, const char *cpu_model)
+static void spitz_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     spitz_common_init(ram_size, kernel_filename,
                 kernel_cmdline, initrd_filename, cpu_model, spitz, 0x2c9);
 }
 
-static void borzoi_init(ram_addr_t ram_size,
-                const char *boot_device,
-                const char *kernel_filename, const char *kernel_cmdline,
-                const char *initrd_filename, const char *cpu_model)
+static void borzoi_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     spitz_common_init(ram_size, kernel_filename,
                 kernel_cmdline, initrd_filename, cpu_model, borzoi, 0x33f);
 }
 
-static void akita_init(ram_addr_t ram_size,
-                const char *boot_device,
-                const char *kernel_filename, const char *kernel_cmdline,
-                const char *initrd_filename, const char *cpu_model)
+static void akita_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     spitz_common_init(ram_size, kernel_filename,
                 kernel_cmdline, initrd_filename, cpu_model, akita, 0x2e8);
 }
 
-static void terrier_init(ram_addr_t ram_size,
-                const char *boot_device,
-                const char *kernel_filename, const char *kernel_cmdline,
-                const char *initrd_filename, const char *cpu_model)
+static void terrier_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     spitz_common_init(ram_size, kernel_filename,
                 kernel_cmdline, initrd_filename, cpu_model, terrier, 0x33f);
 }
diff --git a/hw/stellaris.c b/hw/stellaris.c
index 353ca4c..bfb18b0 100644
--- a/hw/stellaris.c
+++ b/hw/stellaris.c
@@ -1313,19 +1313,17 @@ static void stellaris_init(const char *kernel_filename, const char *cpu_model,
 }
 
 /* FIXME: Figure out how to generate these from stellaris_boards.  */
-static void lm3s811evb_init(ram_addr_t ram_size,
-                     const char *boot_device,
-                     const char *kernel_filename, const char *kernel_cmdline,
-                     const char *initrd_filename, const char *cpu_model)
+static void lm3s811evb_init(QEMUMachineInitArgs *args)
 {
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
     stellaris_init(kernel_filename, cpu_model, &stellaris_boards[0]);
 }
 
-static void lm3s6965evb_init(ram_addr_t ram_size,
-                     const char *boot_device,
-                     const char *kernel_filename, const char *kernel_cmdline,
-                     const char *initrd_filename, const char *cpu_model)
+static void lm3s6965evb_init(QEMUMachineInitArgs *args)
 {
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
     stellaris_init(kernel_filename, cpu_model, &stellaris_boards[1]);
 }
 
diff --git a/hw/sun4m.c b/hw/sun4m.c
index a04b485..dbe93f9 100644
--- a/hw/sun4m.c
+++ b/hw/sun4m.c
@@ -1306,92 +1306,118 @@ static const struct sun4m_hwdef sun4m_hwdefs[] = {
 };
 
 /* SPARCstation 5 hardware initialisation */
-static void ss5_init(ram_addr_t RAM_size,
-                     const char *boot_device,
-                     const char *kernel_filename, const char *kernel_cmdline,
-                     const char *initrd_filename, const char *cpu_model)
+static void ss5_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t RAM_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     sun4m_hw_init(&sun4m_hwdefs[0], RAM_size, boot_device, kernel_filename,
                   kernel_cmdline, initrd_filename, cpu_model);
 }
 
 /* SPARCstation 10 hardware initialisation */
-static void ss10_init(ram_addr_t RAM_size,
-                      const char *boot_device,
-                      const char *kernel_filename, const char *kernel_cmdline,
-                      const char *initrd_filename, const char *cpu_model)
+static void ss10_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t RAM_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     sun4m_hw_init(&sun4m_hwdefs[1], RAM_size, boot_device, kernel_filename,
                   kernel_cmdline, initrd_filename, cpu_model);
 }
 
 /* SPARCserver 600MP hardware initialisation */
-static void ss600mp_init(ram_addr_t RAM_size,
-                         const char *boot_device,
-                         const char *kernel_filename,
-                         const char *kernel_cmdline,
-                         const char *initrd_filename, const char *cpu_model)
+static void ss600mp_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t RAM_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     sun4m_hw_init(&sun4m_hwdefs[2], RAM_size, boot_device, kernel_filename,
                   kernel_cmdline, initrd_filename, cpu_model);
 }
 
 /* SPARCstation 20 hardware initialisation */
-static void ss20_init(ram_addr_t RAM_size,
-                      const char *boot_device,
-                      const char *kernel_filename, const char *kernel_cmdline,
-                      const char *initrd_filename, const char *cpu_model)
+static void ss20_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t RAM_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     sun4m_hw_init(&sun4m_hwdefs[3], RAM_size, boot_device, kernel_filename,
                   kernel_cmdline, initrd_filename, cpu_model);
 }
 
 /* SPARCstation Voyager hardware initialisation */
-static void vger_init(ram_addr_t RAM_size,
-                      const char *boot_device,
-                      const char *kernel_filename, const char *kernel_cmdline,
-                      const char *initrd_filename, const char *cpu_model)
+static void vger_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t RAM_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     sun4m_hw_init(&sun4m_hwdefs[4], RAM_size, boot_device, kernel_filename,
                   kernel_cmdline, initrd_filename, cpu_model);
 }
 
 /* SPARCstation LX hardware initialisation */
-static void ss_lx_init(ram_addr_t RAM_size,
-                       const char *boot_device,
-                       const char *kernel_filename, const char *kernel_cmdline,
-                       const char *initrd_filename, const char *cpu_model)
+static void ss_lx_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t RAM_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     sun4m_hw_init(&sun4m_hwdefs[5], RAM_size, boot_device, kernel_filename,
                   kernel_cmdline, initrd_filename, cpu_model);
 }
 
 /* SPARCstation 4 hardware initialisation */
-static void ss4_init(ram_addr_t RAM_size,
-                     const char *boot_device,
-                     const char *kernel_filename, const char *kernel_cmdline,
-                     const char *initrd_filename, const char *cpu_model)
+static void ss4_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t RAM_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     sun4m_hw_init(&sun4m_hwdefs[6], RAM_size, boot_device, kernel_filename,
                   kernel_cmdline, initrd_filename, cpu_model);
 }
 
 /* SPARCClassic hardware initialisation */
-static void scls_init(ram_addr_t RAM_size,
-                      const char *boot_device,
-                      const char *kernel_filename, const char *kernel_cmdline,
-                      const char *initrd_filename, const char *cpu_model)
+static void scls_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t RAM_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     sun4m_hw_init(&sun4m_hwdefs[7], RAM_size, boot_device, kernel_filename,
                   kernel_cmdline, initrd_filename, cpu_model);
 }
 
 /* SPARCbook hardware initialisation */
-static void sbook_init(ram_addr_t RAM_size,
-                       const char *boot_device,
-                       const char *kernel_filename, const char *kernel_cmdline,
-                       const char *initrd_filename, const char *cpu_model)
+static void sbook_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t RAM_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     sun4m_hw_init(&sun4m_hwdefs[8], RAM_size, boot_device, kernel_filename,
                   kernel_cmdline, initrd_filename, cpu_model);
 }
@@ -1654,21 +1680,27 @@ static void sun4d_hw_init(const struct sun4d_hwdef *hwdef, ram_addr_t RAM_size,
 }
 
 /* SPARCserver 1000 hardware initialisation */
-static void ss1000_init(ram_addr_t RAM_size,
-                        const char *boot_device,
-                        const char *kernel_filename, const char *kernel_cmdline,
-                        const char *initrd_filename, const char *cpu_model)
+static void ss1000_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t RAM_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     sun4d_hw_init(&sun4d_hwdefs[0], RAM_size, boot_device, kernel_filename,
                   kernel_cmdline, initrd_filename, cpu_model);
 }
 
 /* SPARCcenter 2000 hardware initialisation */
-static void ss2000_init(ram_addr_t RAM_size,
-                        const char *boot_device,
-                        const char *kernel_filename, const char *kernel_cmdline,
-                        const char *initrd_filename, const char *cpu_model)
+static void ss2000_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t RAM_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     sun4d_hw_init(&sun4d_hwdefs[1], RAM_size, boot_device, kernel_filename,
                   kernel_cmdline, initrd_filename, cpu_model);
 }
@@ -1848,11 +1880,14 @@ static void sun4c_hw_init(const struct sun4c_hwdef *hwdef, ram_addr_t RAM_size,
 }
 
 /* SPARCstation 2 hardware initialisation */
-static void ss2_init(ram_addr_t RAM_size,
-                     const char *boot_device,
-                     const char *kernel_filename, const char *kernel_cmdline,
-                     const char *initrd_filename, const char *cpu_model)
+static void ss2_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t RAM_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     sun4c_hw_init(&sun4c_hwdefs[0], RAM_size, boot_device, kernel_filename,
                   kernel_cmdline, initrd_filename, cpu_model);
 }
diff --git a/hw/sun4u.c b/hw/sun4u.c
index 940db33..abf68cf 100644
--- a/hw/sun4u.c
+++ b/hw/sun4u.c
@@ -933,31 +933,40 @@ static const struct hwdef hwdefs[] = {
 };
 
 /* Sun4u hardware initialisation */
-static void sun4u_init(ram_addr_t RAM_size,
-                       const char *boot_devices,
-                       const char *kernel_filename, const char *kernel_cmdline,
-                       const char *initrd_filename, const char *cpu_model)
-{
+static void sun4u_init(QEMUMachineInitArgs *args)
+{
+    ram_addr_t RAM_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_devices = args->boot_device;
     sun4uv_init(get_system_memory(), RAM_size, boot_devices, kernel_filename,
                 kernel_cmdline, initrd_filename, cpu_model, &hwdefs[0]);
 }
 
 /* Sun4v hardware initialisation */
-static void sun4v_init(ram_addr_t RAM_size,
-                       const char *boot_devices,
-                       const char *kernel_filename, const char *kernel_cmdline,
-                       const char *initrd_filename, const char *cpu_model)
-{
+static void sun4v_init(QEMUMachineInitArgs *args)
+{
+    ram_addr_t RAM_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_devices = args->boot_device;
     sun4uv_init(get_system_memory(), RAM_size, boot_devices, kernel_filename,
                 kernel_cmdline, initrd_filename, cpu_model, &hwdefs[1]);
 }
 
 /* Niagara hardware initialisation */
-static void niagara_init(ram_addr_t RAM_size,
-                         const char *boot_devices,
-                         const char *kernel_filename, const char *kernel_cmdline,
-                         const char *initrd_filename, const char *cpu_model)
-{
+static void niagara_init(QEMUMachineInitArgs *args)
+{
+    ram_addr_t RAM_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_devices = args->boot_device;
     sun4uv_init(get_system_memory(), RAM_size, boot_devices, kernel_filename,
                 kernel_cmdline, initrd_filename, cpu_model, &hwdefs[2]);
 }
diff --git a/hw/tosa.c b/hw/tosa.c
index 297a8c2..512278c 100644
--- a/hw/tosa.c
+++ b/hw/tosa.c
@@ -205,11 +205,12 @@ static struct arm_boot_info tosa_binfo = {
     .ram_size = 0x04000000,
 };
 
-static void tosa_init(ram_addr_t ram_size,
-                const char *boot_device,
-                const char *kernel_filename, const char *kernel_cmdline,
-                const char *initrd_filename, const char *cpu_model)
+static void tosa_init(QEMUMachineInitArgs *args)
 {
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     MemoryRegion *address_space_mem = get_system_memory();
     MemoryRegion *rom = g_new(MemoryRegion, 1);
     PXA2xxState *mpu;
diff --git a/hw/versatilepb.c b/hw/versatilepb.c
index 7b1b025..756ec29 100644
--- a/hw/versatilepb.c
+++ b/hw/versatilepb.c
@@ -348,22 +348,28 @@ static void versatile_init(ram_addr_t ram_size,
     arm_load_kernel(cpu, &versatile_binfo);
 }
 
-static void vpb_init(ram_addr_t ram_size,
-                     const char *boot_device,
-                     const char *kernel_filename, const char *kernel_cmdline,
-                     const char *initrd_filename, const char *cpu_model)
+static void vpb_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     versatile_init(ram_size,
                    boot_device,
                    kernel_filename, kernel_cmdline,
                    initrd_filename, cpu_model, 0x183);
 }
 
-static void vab_init(ram_addr_t ram_size,
-                     const char *boot_device,
-                     const char *kernel_filename, const char *kernel_cmdline,
-                     const char *initrd_filename, const char *cpu_model)
+static void vab_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     versatile_init(ram_size,
                    boot_device,
                    kernel_filename, kernel_cmdline,
diff --git a/hw/vexpress.c b/hw/vexpress.c
index 3596d1e..36503d6 100644
--- a/hw/vexpress.c
+++ b/hw/vexpress.c
@@ -467,25 +467,27 @@ static void vexpress_common_init(const VEDBoardInfo *daughterboard,
     arm_load_kernel(arm_env_get_cpu(first_cpu), &vexpress_binfo);
 }
 
-static void vexpress_a9_init(ram_addr_t ram_size,
-                             const char *boot_device,
-                             const char *kernel_filename,
-                             const char *kernel_cmdline,
-                             const char *initrd_filename,
-                             const char *cpu_model)
+static void vexpress_a9_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     vexpress_common_init(&a9_daughterboard,
                          ram_size, boot_device, kernel_filename,
                          kernel_cmdline, initrd_filename, cpu_model);
 }
 
-static void vexpress_a15_init(ram_addr_t ram_size,
-                              const char *boot_device,
-                              const char *kernel_filename,
-                              const char *kernel_cmdline,
-                              const char *initrd_filename,
-                              const char *cpu_model)
+static void vexpress_a15_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     vexpress_common_init(&a15_daughterboard,
                          ram_size, boot_device, kernel_filename,
                          kernel_cmdline, initrd_filename, cpu_model);
diff --git a/hw/virtex_ml507.c b/hw/virtex_ml507.c
index 79bc0d1..a09b27a 100644
--- a/hw/virtex_ml507.c
+++ b/hw/virtex_ml507.c
@@ -183,12 +183,12 @@ static int xilinx_load_device_tree(target_phys_addr_t addr,
     return fdt_size;
 }
 
-static void virtex_init(ram_addr_t ram_size,
-                        const char *boot_device,
-                        const char *kernel_filename,
-                        const char *kernel_cmdline,
-                        const char *initrd_filename, const char *cpu_model)
+static void virtex_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
     MemoryRegion *address_space_mem = get_system_memory();
     DeviceState *dev;
     PowerPCCPU *cpu;
diff --git a/hw/xen_machine_pv.c b/hw/xen_machine_pv.c
index 4b72aa7..4264703 100644
--- a/hw/xen_machine_pv.c
+++ b/hw/xen_machine_pv.c
@@ -29,13 +29,12 @@
 #include "xen_domainbuild.h"
 #include "blockdev.h"
 
-static void xen_init_pv(ram_addr_t ram_size,
-			const char *boot_device,
-			const char *kernel_filename,
-			const char *kernel_cmdline,
-			const char *initrd_filename,
-			const char *cpu_model)
+static void xen_init_pv(QEMUMachineInitArgs *args)
 {
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     X86CPU *cpu;
     CPUX86State *env;
     DriveInfo *dinfo;
diff --git a/hw/xilinx_zynq.c b/hw/xilinx_zynq.c
index fd46ba2..c55dafb 100644
--- a/hw/xilinx_zynq.c
+++ b/hw/xilinx_zynq.c
@@ -77,10 +77,13 @@ static inline void zynq_init_spi_flashes(uint32_t base_addr, qemu_irq irq)
 
 }
 
-static void zynq_init(ram_addr_t ram_size, const char *boot_device,
-                        const char *kernel_filename, const char *kernel_cmdline,
-                        const char *initrd_filename, const char *cpu_model)
+static void zynq_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     ARMCPU *cpu;
     MemoryRegion *address_space_mem = get_system_memory();
     MemoryRegion *ext_ram = g_new(MemoryRegion, 1);
diff --git a/hw/xtensa_lx60.c b/hw/xtensa_lx60.c
index 3653f65..1fd2c47 100644
--- a/hw/xtensa_lx60.c
+++ b/hw/xtensa_lx60.c
@@ -268,11 +268,14 @@ static void lx_init(const LxBoardDesc *board,
     }
 }
 
-static void xtensa_lx60_init(ram_addr_t ram_size,
-                     const char *boot_device,
-                     const char *kernel_filename, const char *kernel_cmdline,
-                     const char *initrd_filename, const char *cpu_model)
+static void xtensa_lx60_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     static const LxBoardDesc lx60_board = {
         .flash_size = 0x400000,
         .flash_sector_size = 0x10000,
@@ -283,11 +286,14 @@ static void xtensa_lx60_init(ram_addr_t ram_size,
             initrd_filename, cpu_model);
 }
 
-static void xtensa_lx200_init(ram_addr_t ram_size,
-                     const char *boot_device,
-                     const char *kernel_filename, const char *kernel_cmdline,
-                     const char *initrd_filename, const char *cpu_model)
+static void xtensa_lx200_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     static const LxBoardDesc lx200_board = {
         .flash_size = 0x1000000,
         .flash_sector_size = 0x20000,
diff --git a/hw/xtensa_sim.c b/hw/xtensa_sim.c
index 831460b..2e846d8 100644
--- a/hw/xtensa_sim.c
+++ b/hw/xtensa_sim.c
@@ -96,11 +96,14 @@ static void sim_init(ram_addr_t ram_size,
     }
 }
 
-static void xtensa_sim_init(ram_addr_t ram_size,
-                     const char *boot_device,
-                     const char *kernel_filename, const char *kernel_cmdline,
-                     const char *initrd_filename, const char *cpu_model)
+static void xtensa_sim_init(QEMUMachineInitArgs *args)
 {
+    ram_addr_t ram_size = args->ram_size;
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
+    const char *boot_device = args->boot_device;
     if (!cpu_model) {
         cpu_model = XTENSA_DEFAULT_CPU_MODEL;
     }
diff --git a/hw/z2.c b/hw/z2.c
index 076fad2..f62b806 100644
--- a/hw/z2.c
+++ b/hw/z2.c
@@ -295,11 +295,12 @@ static TypeInfo aer915_info = {
     .class_init    = aer915_class_init,
 };
 
-static void z2_init(ram_addr_t ram_size,
-                const char *boot_device,
-                const char *kernel_filename, const char *kernel_cmdline,
-                const char *initrd_filename, const char *cpu_model)
+static void z2_init(QEMUMachineInitArgs *args)
 {
+    const char *cpu_model = args->cpu_model;
+    const char *kernel_filename = args->kernel_filename;
+    const char *kernel_cmdline = args->kernel_cmdline;
+    const char *initrd_filename = args->initrd_filename;
     MemoryRegion *address_space_mem = get_system_memory();
     uint32_t sector_len = 0x10000;
     PXA2xxState *mpu;
diff --git a/vl.c b/vl.c
index 5b357a3..ee3c43a 100644
--- a/vl.c
+++ b/vl.c
@@ -3638,8 +3638,13 @@ int main(int argc, char **argv, char **envp)
 
     qdev_machine_init();
 
-    machine->init(ram_size, boot_devices,
-                  kernel_filename, kernel_cmdline, initrd_filename, cpu_model);
+    QEMUMachineInitArgs args = { .ram_size = ram_size,
+                                 .boot_device = boot_devices,
+                                 .kernel_filename = kernel_filename,
+                                 .kernel_cmdline = kernel_cmdline,
+                                 .initrd_filename = initrd_filename,
+                                 .cpu_model = cpu_model };
+    machine->init(&args);
 
     cpu_synchronize_all_post_init();
 
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 22:50:28 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 22:50:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNtTv-0006Si-CR; Mon, 15 Oct 2012 22:49:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNtTt-0006Sa-LJ
	for Xen-devel@lists.xensource.com; Mon, 15 Oct 2012 22:49:53 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1350341386!2307130!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgxMjEzMw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26261 invoked from network); 15 Oct 2012 22:49:47 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Oct 2012 22:49:47 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9FMngsG014890
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 15 Oct 2012 22:49:43 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9FMnfip000796
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 15 Oct 2012 22:49:42 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9FMnf0q008836; Mon, 15 Oct 2012 17:49:41 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 15 Oct 2012 15:49:41 -0700
Date: Mon, 15 Oct 2012 15:49:40 -0700
From: Mukesh Rathor 
To: Ian Campbell 
Message-ID: <20121015154940.4033c64f@mantra.us.oracle.com>
In-Reply-To: <1350317743.18058.85.camel@zakaz.uk.xensource.com>
References: <20121011144929.06e71a9e@mantra.us.oracle.com>
	<1350317743.18058.85.camel@zakaz.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V2 0/7]: PVH: PV guest with extensions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 15 Oct 2012 17:15:43 +0100
Ian Campbell  wrote:

> On Thu, 2012-10-11 at 22:49 +0100, Mukesh Rathor wrote:
> > Hi guys,
> > 
> > Ok, I've made all the changes from prev RFC patch submissions.
> > Tested all the combinations. The patches are organized slightly
> > differently from prev version because of the nature of changes
> > after last review. I am building xen patch just for the
> > corresponding header file changes. Following that I'll refresh xen
> > tree, debug, test, and send patches.
> > 
> > For linux kernel mailing list introduction, PVH is a PV guest that
> > can run in an HVM container, uses native pagetables, uses callback
> > vector, native IDT, and native syscalls.
> > 
> > They were built on top of 89d0307af2b9957d59bfb2a86aaa57464ff921de
> > commit.
> 
> Are they in a git branch anywhere?
> 

not in a public accessible location. we are very close to getting this
done (it appears ;)), and once konrad puts in his tree it should be
publicly available.

thanks
mukesh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 15 22:50:28 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 15 Oct 2012 22:50:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNtTv-0006Si-CR; Mon, 15 Oct 2012 22:49:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNtTt-0006Sa-LJ
	for Xen-devel@lists.xensource.com; Mon, 15 Oct 2012 22:49:53 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1350341386!2307130!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgxMjEzMw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26261 invoked from network); 15 Oct 2012 22:49:47 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Oct 2012 22:49:47 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9FMngsG014890
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 15 Oct 2012 22:49:43 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9FMnfip000796
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 15 Oct 2012 22:49:42 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9FMnf0q008836; Mon, 15 Oct 2012 17:49:41 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 15 Oct 2012 15:49:41 -0700
Date: Mon, 15 Oct 2012 15:49:40 -0700
From: Mukesh Rathor 
To: Ian Campbell 
Message-ID: <20121015154940.4033c64f@mantra.us.oracle.com>
In-Reply-To: <1350317743.18058.85.camel@zakaz.uk.xensource.com>
References: <20121011144929.06e71a9e@mantra.us.oracle.com>
	<1350317743.18058.85.camel@zakaz.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V2 0/7]: PVH: PV guest with extensions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 15 Oct 2012 17:15:43 +0100
Ian Campbell  wrote:

> On Thu, 2012-10-11 at 22:49 +0100, Mukesh Rathor wrote:
> > Hi guys,
> > 
> > Ok, I've made all the changes from prev RFC patch submissions.
> > Tested all the combinations. The patches are organized slightly
> > differently from prev version because of the nature of changes
> > after last review. I am building xen patch just for the
> > corresponding header file changes. Following that I'll refresh xen
> > tree, debug, test, and send patches.
> > 
> > For linux kernel mailing list introduction, PVH is a PV guest that
> > can run in an HVM container, uses native pagetables, uses callback
> > vector, native IDT, and native syscalls.
> > 
> > They were built on top of 89d0307af2b9957d59bfb2a86aaa57464ff921de
> > commit.
> 
> Are they in a git branch anywhere?
> 

not in a public accessible location. we are very close to getting this
done (it appears ;)), and once konrad puts in his tree it should be
publicly available.

thanks
mukesh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 01:02:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 01:02:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNvXK-0005bW-Iu; Tue, 16 Oct 2012 01:01:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNvXI-00058T-5o
	for xen-devel@lists.xensource.com; Tue, 16 Oct 2012 01:01:32 +0000
Received: from [85.158.137.99:56314] by server-9.bemta-3.messagelabs.com id
	DE/67-16841-BE1BC705; Tue, 16 Oct 2012 01:01:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1350349290!16630810!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4991 invoked from network); 16 Oct 2012 01:01:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 01:01:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,592,1344211200"; d="scan'208";a="15182895"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Oct 2012 01:01:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 16 Oct 2012 02:01:29 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TNvXF-0008Jr-0p;
	Tue, 16 Oct 2012 01:01:29 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TNvXF-0004Nl-0F;
	Tue, 16 Oct 2012 02:01:29 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Tue, 16 Oct 2012 02:01:29 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13964: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13964 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13964/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops              4 kernel-build              fail REGR. vs. 13962
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 13962
 build-i386                    4 xen-build                 fail REGR. vs. 13962

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13962
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13962
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13962
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13962

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  c1c549c4fe9e
baseline version:
 xen                  e0e1350dfe9b

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf 
  Ian Campbell 
  Jacob Shin 
  Jan Beulich 
  Keir Fraser 
  Tim Deegan 
  Wei Wang 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             fail    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26059:c1c549c4fe9e
tag:         tip
user:        Daniel De Graaf 
date:        Mon Oct 15 16:51:44 2012 +0100
    
    xen: Add versions of rcu_lock_*_domain without IS_PRIV
    
    These functions will be used to avoid duplication of IS_PRIV calls
    that will be introduced in XSM hooks. This also fixes a build error
    with XSM enabled introduced by 25925:d1c3375c3f11 which depends on
    this patch.
    
    Signed-off-by: Daniel De Graaf 
    Committed-by: Keir Fraser 
    
    
changeset:   26058:37bb894121c7
user:        Jan Beulich 
date:        Mon Oct 15 17:41:39 2012 +0200
    
    IOMMU: remove vendor specific bits from generic code
    
    - names of functions used independent of vendor should not have vendor
      specific names
    - vendor specific declarations should not live inn generic headers
    - other vendor specific items should not be used in generic code
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    
    
changeset:   26057:2e8a6c8fa89c
user:        Jan Beulich 
date:        Mon Oct 15 17:39:32 2012 +0200
    
    VT-d: drop bogus checks
    
    There were a number of cases where an "iommu" retrieved got passed to
    another function before being NULL-checked. While this by itself was
    not a problem as the called function did the checks, it is confusing to
    the reader and redundant in several cases (particularly with NULL-
    checking the return value of iommu_ir_ctrl()). Drop the redundant
    checks (also ones where the sole caller of a function did the checking
    already), and at once make the three similar functions proper inline
    instead of extern ones (they were prototyped in the wrong header file
    anyway, so would have needed touching sooner or later).
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    
    
changeset:   26056:177fdda0be56
user:        Keir Fraser 
date:        Mon Oct 15 16:38:11 2012 +0100
    
    More efficient TLB-flush filtering in alloc_heap_pages().
    
    Rather than per-cpu filtering for every page in a super-page
    allocation, simply remember the most recent TLB timestamp across all
    allocated pages, and filter on that, just once, at the end of the
    function.
    
    For large-CPU systems, doing 2MB allocations during domain creation,
    this cuts down the domain creation time *massively*.
    
    TODO: It may make sense to move the filtering out into some callers,
    such as memory.c:populate_physmap() and
    memory.c:increase_reservation(), so that the filtering can be moved
    outside their loops, too.
    
    Signed-off-by: Keir Fraser 
    
    
changeset:   26055:14e32621dbaf
user:        Jacob Shin 
date:        Mon Oct 15 15:04:51 2012 +0200
    
    x86/xenoprof: fix kernel/user mode detection for HVM
    
    While trying oprofile under Xen, I noticed that HVM passive domain's
    kernel addresses were showing up as user application. It turns out
    under HVM get_cpu_user_regs()->cs contains 0x0000beef.
    
    Signed-off-by: Jacob Shin 
    
    Don't cast away const-ness. Use SS instead of CS to determine ring.
    Special-case real and protected mode.
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    Committed-by: Jan Beulich 
    
    
changeset:   26054:983108e1b56b
user:        Wei Wang 
date:        Mon Oct 15 15:03:36 2012 +0200
    
    x86/amd: Fix xen_apic_write warnings in Dom0
    
    [    0.020294] ------------[ cut here ]------------
    [    0.020311] WARNING: at arch/x86/xen/enlighten.c:730
    xen_apic_write+0x15/0x17()
    [    0.020318] Hardware name: empty
    [    0.020323] Modules linked in:
    [    0.020334] Pid: 1, comm: swapper/0 Not tainted 3.3.8 #7
    [    0.020340] Call Trace:
    [    0.020354]  [] warn_slowpath_common+0x80/0x98
    [    0.020369]  [] warn_slowpath_null+0x15/0x17
    [    0.020378]  [] xen_apic_write+0x15/0x17
    [    0.020392]  [] perf_events_lapic_init+0x2e/0x30
    [    0.020410]  [] init_hw_perf_events+0x250/0x407
    [    0.020419]  [] ? check_bugs+0x2d/0x2d
    [    0.020430]  [] do_one_initcall+0x7a/0x131
    [    0.020444]  [] kernel_init+0x91/0x15d
    [    0.020456]  [] kernel_thread_helper+0x4/0x10
    [    0.020471]  [] ? retint_restore_args+0x5/0x6
    [    0.020481]  [] ? gs_change+0x13/0x13
    [    0.020500] ---[ end trace a7919e7f17c0a725 ]---
    
    Kernel function check_hw_exists() writes 0xabcd to msr 0xc0010201 (Performance Event
    Counter 0) and read it again to check if it is running as dom0. Early amd cpus does
    not reset perf counters during warm reboot. If the kernel is booted with bare metal
    and then as a dom0, the content of msr 0xc0010201 will stay and the checking will
    pass and PMU will be enabled unexpectedly.
    
    Signed-off-by: Wei Wang 
    
    Don't reset the counters when used for the NMI watchdog.
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    Committed-by: Jan Beulich 
    
    
changeset:   26053:137dfbd3190e
user:        Jan Beulich 
date:        Mon Oct 15 12:59:14 2012 +0200
    
    AMD IOMMU: fix find_iommu_from_bdf_cap()
    
    The arguments passed for the "cap_offset" parameter get read from 16-
    bit fields, so the parameter should also have (at least) 16 bits.
    
    While fixing this I also noticed that this was yet another case where
    PCI segment information wasn't properly propagated, so a respective
    first parameter gets added to the function at once.
    
    Signed-off-by: Jan Beulich 
    Acked-by: Wei Wang 
    
    
changeset:   26052:e0e1350dfe9b
user:        Ian Campbell 
date:        Thu Oct 11 15:57:00 2012 +0100
    
    arm: mark heap and frametable limits as read mostly
    
    These are used in virt_to_page and page_to_virt so I imagine there's
    some small benefit to this (but I've not measured)
    
    Signed-off-by: Ian Campbell 
    Acked-by: Tim Deegan 
    Committed-by: Ian Campbell 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 01:02:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 01:02:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNvXK-0005bW-Iu; Tue, 16 Oct 2012 01:01:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNvXI-00058T-5o
	for xen-devel@lists.xensource.com; Tue, 16 Oct 2012 01:01:32 +0000
Received: from [85.158.137.99:56314] by server-9.bemta-3.messagelabs.com id
	DE/67-16841-BE1BC705; Tue, 16 Oct 2012 01:01:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1350349290!16630810!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQxMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4991 invoked from network); 16 Oct 2012 01:01:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 01:01:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,592,1344211200"; d="scan'208";a="15182895"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Oct 2012 01:01:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 16 Oct 2012 02:01:29 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TNvXF-0008Jr-0p;
	Tue, 16 Oct 2012 01:01:29 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TNvXF-0004Nl-0F;
	Tue, 16 Oct 2012 02:01:29 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Tue, 16 Oct 2012 02:01:29 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13964: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13964 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13964/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops              4 kernel-build              fail REGR. vs. 13962
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 13962
 build-i386                    4 xen-build                 fail REGR. vs. 13962

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13962
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13962
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13962
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13962

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  c1c549c4fe9e
baseline version:
 xen                  e0e1350dfe9b

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf 
  Ian Campbell 
  Jacob Shin 
  Jan Beulich 
  Keir Fraser 
  Tim Deegan 
  Wei Wang 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             fail    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26059:c1c549c4fe9e
tag:         tip
user:        Daniel De Graaf 
date:        Mon Oct 15 16:51:44 2012 +0100
    
    xen: Add versions of rcu_lock_*_domain without IS_PRIV
    
    These functions will be used to avoid duplication of IS_PRIV calls
    that will be introduced in XSM hooks. This also fixes a build error
    with XSM enabled introduced by 25925:d1c3375c3f11 which depends on
    this patch.
    
    Signed-off-by: Daniel De Graaf 
    Committed-by: Keir Fraser 
    
    
changeset:   26058:37bb894121c7
user:        Jan Beulich 
date:        Mon Oct 15 17:41:39 2012 +0200
    
    IOMMU: remove vendor specific bits from generic code
    
    - names of functions used independent of vendor should not have vendor
      specific names
    - vendor specific declarations should not live inn generic headers
    - other vendor specific items should not be used in generic code
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    
    
changeset:   26057:2e8a6c8fa89c
user:        Jan Beulich 
date:        Mon Oct 15 17:39:32 2012 +0200
    
    VT-d: drop bogus checks
    
    There were a number of cases where an "iommu" retrieved got passed to
    another function before being NULL-checked. While this by itself was
    not a problem as the called function did the checks, it is confusing to
    the reader and redundant in several cases (particularly with NULL-
    checking the return value of iommu_ir_ctrl()). Drop the redundant
    checks (also ones where the sole caller of a function did the checking
    already), and at once make the three similar functions proper inline
    instead of extern ones (they were prototyped in the wrong header file
    anyway, so would have needed touching sooner or later).
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    
    
changeset:   26056:177fdda0be56
user:        Keir Fraser 
date:        Mon Oct 15 16:38:11 2012 +0100
    
    More efficient TLB-flush filtering in alloc_heap_pages().
    
    Rather than per-cpu filtering for every page in a super-page
    allocation, simply remember the most recent TLB timestamp across all
    allocated pages, and filter on that, just once, at the end of the
    function.
    
    For large-CPU systems, doing 2MB allocations during domain creation,
    this cuts down the domain creation time *massively*.
    
    TODO: It may make sense to move the filtering out into some callers,
    such as memory.c:populate_physmap() and
    memory.c:increase_reservation(), so that the filtering can be moved
    outside their loops, too.
    
    Signed-off-by: Keir Fraser 
    
    
changeset:   26055:14e32621dbaf
user:        Jacob Shin 
date:        Mon Oct 15 15:04:51 2012 +0200
    
    x86/xenoprof: fix kernel/user mode detection for HVM
    
    While trying oprofile under Xen, I noticed that HVM passive domain's
    kernel addresses were showing up as user application. It turns out
    under HVM get_cpu_user_regs()->cs contains 0x0000beef.
    
    Signed-off-by: Jacob Shin 
    
    Don't cast away const-ness. Use SS instead of CS to determine ring.
    Special-case real and protected mode.
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    Committed-by: Jan Beulich 
    
    
changeset:   26054:983108e1b56b
user:        Wei Wang 
date:        Mon Oct 15 15:03:36 2012 +0200
    
    x86/amd: Fix xen_apic_write warnings in Dom0
    
    [    0.020294] ------------[ cut here ]------------
    [    0.020311] WARNING: at arch/x86/xen/enlighten.c:730
    xen_apic_write+0x15/0x17()
    [    0.020318] Hardware name: empty
    [    0.020323] Modules linked in:
    [    0.020334] Pid: 1, comm: swapper/0 Not tainted 3.3.8 #7
    [    0.020340] Call Trace:
    [    0.020354]  [] warn_slowpath_common+0x80/0x98
    [    0.020369]  [] warn_slowpath_null+0x15/0x17
    [    0.020378]  [] xen_apic_write+0x15/0x17
    [    0.020392]  [] perf_events_lapic_init+0x2e/0x30
    [    0.020410]  [] init_hw_perf_events+0x250/0x407
    [    0.020419]  [] ? check_bugs+0x2d/0x2d
    [    0.020430]  [] do_one_initcall+0x7a/0x131
    [    0.020444]  [] kernel_init+0x91/0x15d
    [    0.020456]  [] kernel_thread_helper+0x4/0x10
    [    0.020471]  [] ? retint_restore_args+0x5/0x6
    [    0.020481]  [] ? gs_change+0x13/0x13
    [    0.020500] ---[ end trace a7919e7f17c0a725 ]---
    
    Kernel function check_hw_exists() writes 0xabcd to msr 0xc0010201 (Performance Event
    Counter 0) and read it again to check if it is running as dom0. Early amd cpus does
    not reset perf counters during warm reboot. If the kernel is booted with bare metal
    and then as a dom0, the content of msr 0xc0010201 will stay and the checking will
    pass and PMU will be enabled unexpectedly.
    
    Signed-off-by: Wei Wang 
    
    Don't reset the counters when used for the NMI watchdog.
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    Committed-by: Jan Beulich 
    
    
changeset:   26053:137dfbd3190e
user:        Jan Beulich 
date:        Mon Oct 15 12:59:14 2012 +0200
    
    AMD IOMMU: fix find_iommu_from_bdf_cap()
    
    The arguments passed for the "cap_offset" parameter get read from 16-
    bit fields, so the parameter should also have (at least) 16 bits.
    
    While fixing this I also noticed that this was yet another case where
    PCI segment information wasn't properly propagated, so a respective
    first parameter gets added to the function at once.
    
    Signed-off-by: Jan Beulich 
    Acked-by: Wei Wang 
    
    
changeset:   26052:e0e1350dfe9b
user:        Ian Campbell 
date:        Thu Oct 11 15:57:00 2012 +0100
    
    arm: mark heap and frametable limits as read mostly
    
    These are used in virt_to_page and page_to_virt so I imagine there's
    some small benefit to this (but I've not measured)
    
    Signed-off-by: Ian Campbell 
    Acked-by: Tim Deegan 
    Committed-by: Ian Campbell 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 02:40:51 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 02:40:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNx4c-0003mF-9o; Tue, 16 Oct 2012 02:40:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNx4a-0003m7-VF
	for xen-devel@lists.xensource.com; Tue, 16 Oct 2012 02:40:01 +0000
X-Env-Sender: joe.jin@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1350355193!10075781!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgxMjEzMw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24069 invoked from network); 16 Oct 2012 02:39:54 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Oct 2012 02:39:54 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9G2dpae021202
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for ; Tue, 16 Oct 2012 02:39:52 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9G2doJR003141
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Tue, 16 Oct 2012 02:39:51 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9G2doDI007035
	for ; Mon, 15 Oct 2012 21:39:50 -0500
Received: from [10.182.38.26] (/10.182.38.26)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 15 Oct 2012 19:39:50 -0700
Message-ID: <507CC8F4.4080103@oracle.com>
Date: Tue, 16 Oct 2012 10:39:48 +0800
From: Joe Jin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121009 Thunderbird/16.0
MIME-Version: 1.0
To: chuang cao ,
	Konrad Rzeszutek Wilk 
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "xen-devel@lists.xensource.com" 
Subject: [Xen-devel] [PATCH] tools: xend: fix wrong condition check for xml
	file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Konrad,

Would you please review below fix?

Thanks,
Joe


In commit e8d40584, it intended to check xml file size and when empty will
return, the condition should be "if os.path.getsize(xml_path) == 0" rather
then "if not os.path.getsize(xml_path) == 0".

Signed-off-by: Chuang Cao 
Signed-off-by: Joe Jin 
---
 tools/python/xen/xend/XendStateStore.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/python/xen/xend/XendStateStore.py b/tools/python/xen/xend/XendStateStore.py
index 17a29f1..a66181d 100644
--- a/tools/python/xen/xend/XendStateStore.py
+++ b/tools/python/xen/xend/XendStateStore.py
@@ -101,7 +101,7 @@ class XendStateStore:
         if not os.path.exists(xml_path):
             return {}
 
-        if not os.path.getsize(xml_path) == 0:
+        if os.path.getsize(xml_path) == 0:
             return {}
 
         dom = minidom.parse(xml_path)
-- 
1.7.11.7


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 02:40:51 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 02:40:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TNx4c-0003mF-9o; Tue, 16 Oct 2012 02:40:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNx4a-0003m7-VF
	for xen-devel@lists.xensource.com; Tue, 16 Oct 2012 02:40:01 +0000
X-Env-Sender: joe.jin@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1350355193!10075781!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgxMjEzMw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24069 invoked from network); 16 Oct 2012 02:39:54 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Oct 2012 02:39:54 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9G2dpae021202
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for ; Tue, 16 Oct 2012 02:39:52 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9G2doJR003141
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Tue, 16 Oct 2012 02:39:51 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9G2doDI007035
	for ; Mon, 15 Oct 2012 21:39:50 -0500
Received: from [10.182.38.26] (/10.182.38.26)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 15 Oct 2012 19:39:50 -0700
Message-ID: <507CC8F4.4080103@oracle.com>
Date: Tue, 16 Oct 2012 10:39:48 +0800
From: Joe Jin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121009 Thunderbird/16.0
MIME-Version: 1.0
To: chuang cao ,
	Konrad Rzeszutek Wilk 
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "xen-devel@lists.xensource.com" 
Subject: [Xen-devel] [PATCH] tools: xend: fix wrong condition check for xml
	file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Konrad,

Would you please review below fix?

Thanks,
Joe


In commit e8d40584, it intended to check xml file size and when empty will
return, the condition should be "if os.path.getsize(xml_path) == 0" rather
then "if not os.path.getsize(xml_path) == 0".

Signed-off-by: Chuang Cao 
Signed-off-by: Joe Jin 
---
 tools/python/xen/xend/XendStateStore.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/python/xen/xend/XendStateStore.py b/tools/python/xen/xend/XendStateStore.py
index 17a29f1..a66181d 100644
--- a/tools/python/xen/xend/XendStateStore.py
+++ b/tools/python/xen/xend/XendStateStore.py
@@ -101,7 +101,7 @@ class XendStateStore:
         if not os.path.exists(xml_path):
             return {}
 
-        if not os.path.getsize(xml_path) == 0:
+        if os.path.getsize(xml_path) == 0:
             return {}
 
         dom = minidom.parse(xml_path)
-- 
1.7.11.7


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 06:53:13 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 06:53:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO10l-00055P-7I; Tue, 16 Oct 2012 06:52:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO10k-00055K-69
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 06:52:18 +0000
Received: from [85.158.139.211:17391] by server-2.bemta-5.messagelabs.com id
	FB/A0-10520-1240D705; Tue, 16 Oct 2012 06:52:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1350370336!20948955!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20933 invoked from network); 16 Oct 2012 06:52:16 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-206.messagelabs.com with SMTP;
	16 Oct 2012 06:52:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 16 Oct 2012 07:52:15 +0100
Message-Id: <507D203D02000078000A197B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 16 Oct 2012 07:52:13 +0100
From: "Jan Beulich" 
To: "George Dunlap" 
References: 
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.3 development update, 15 Oct
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.10.12 at 18:19, George Dunlap  wrote:
> == Completed ==
> 
> * Linux console improvements

Here and below, please do s/Linux/Serial/ (functionality has nothing
to do with Linux).

Jan

>   -EHCI debug port




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 06:53:13 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 06:53:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO10l-00055P-7I; Tue, 16 Oct 2012 06:52:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO10k-00055K-69
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 06:52:18 +0000
Received: from [85.158.139.211:17391] by server-2.bemta-5.messagelabs.com id
	FB/A0-10520-1240D705; Tue, 16 Oct 2012 06:52:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1350370336!20948955!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20933 invoked from network); 16 Oct 2012 06:52:16 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-206.messagelabs.com with SMTP;
	16 Oct 2012 06:52:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 16 Oct 2012 07:52:15 +0100
Message-Id: <507D203D02000078000A197B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 16 Oct 2012 07:52:13 +0100
From: "Jan Beulich" 
To: "George Dunlap" 
References: 
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.3 development update, 15 Oct
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.10.12 at 18:19, George Dunlap  wrote:
> == Completed ==
> 
> * Linux console improvements

Here and below, please do s/Linux/Serial/ (functionality has nothing
to do with Linux).

Jan

>   -EHCI debug port




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 07:09:35 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 07:09:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO1Gc-0005Uo-Pt; Tue, 16 Oct 2012 07:08:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO1Ga-0005Uj-MW
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 07:08:40 +0000
Received: from [85.158.137.99:46582] by server-8.bemta-3.messagelabs.com id
	2E/A5-10525-7F70D705; Tue, 16 Oct 2012 07:08:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1350371319!20496286!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5642 invoked from network); 16 Oct 2012 07:08:39 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-217.messagelabs.com with SMTP;
	16 Oct 2012 07:08:39 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 16 Oct 2012 08:08:38 +0100
Message-Id: <507D241302000078000A198A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 16 Oct 2012 08:08:35 +0100
From: "Jan Beulich" 
To: "Martin Roth" 
References: <507C3EE9.9040806@gmail.com>
In-Reply-To: <507C3EE9.9040806@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Jackson ,
	Ian Campbell , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Sharing MMIO page with DomU on a system with no
 IOMMU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.10.12 at 18:50, Martin Roth  wrote:
> I'm trying to share an MMIO page from Dom0 running linux with a DomU 
> running an RTOS so that I can access the GPIO registers directly. The 
> system I need to get this working on does not have an IOMMU. I'm aware 
> of the security issues of sharing this area, but don't believe it's an 
> issue in this case.  I've got a Linux module set up and can share memory 
> between the two domains using the grant table, but I haven't been able 
> to get this to work for the MMIO page.
> 
> Can anyone give me a pointer on how I should go about doing this?  I 
> need the area to actually be shared between both domains, not simply 
> owned by the RTOS.

Looks like you have to assign the PCI device providing the GPIOs
to the guest, as there doesn't currently appear to be a way to
allow guest access to individual MMIO pages (lacking the MMIO
counterpart to the iports= and irqs= domain config settings).

Ian, Ian - am I overlooking something?

And of course - sharing the MMIO page between Dom0 and guest
is a questionable intention in any case - you rather want it owned
by the DomU, and Dom0 then shouldn't access it at all. Otherwise,
how would you expect accesses to be coordinated?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 07:09:35 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 07:09:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO1Gc-0005Uo-Pt; Tue, 16 Oct 2012 07:08:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO1Ga-0005Uj-MW
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 07:08:40 +0000
Received: from [85.158.137.99:46582] by server-8.bemta-3.messagelabs.com id
	2E/A5-10525-7F70D705; Tue, 16 Oct 2012 07:08:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1350371319!20496286!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5642 invoked from network); 16 Oct 2012 07:08:39 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-217.messagelabs.com with SMTP;
	16 Oct 2012 07:08:39 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 16 Oct 2012 08:08:38 +0100
Message-Id: <507D241302000078000A198A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 16 Oct 2012 08:08:35 +0100
From: "Jan Beulich" 
To: "Martin Roth" 
References: <507C3EE9.9040806@gmail.com>
In-Reply-To: <507C3EE9.9040806@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Jackson ,
	Ian Campbell , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Sharing MMIO page with DomU on a system with no
 IOMMU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.10.12 at 18:50, Martin Roth  wrote:
> I'm trying to share an MMIO page from Dom0 running linux with a DomU 
> running an RTOS so that I can access the GPIO registers directly. The 
> system I need to get this working on does not have an IOMMU. I'm aware 
> of the security issues of sharing this area, but don't believe it's an 
> issue in this case.  I've got a Linux module set up and can share memory 
> between the two domains using the grant table, but I haven't been able 
> to get this to work for the MMIO page.
> 
> Can anyone give me a pointer on how I should go about doing this?  I 
> need the area to actually be shared between both domains, not simply 
> owned by the RTOS.

Looks like you have to assign the PCI device providing the GPIOs
to the guest, as there doesn't currently appear to be a way to
allow guest access to individual MMIO pages (lacking the MMIO
counterpart to the iports= and irqs= domain config settings).

Ian, Ian - am I overlooking something?

And of course - sharing the MMIO page between Dom0 and guest
is a questionable intention in any case - you rather want it owned
by the DomU, and Dom0 then shouldn't access it at all. Otherwise,
how would you expect accesses to be coordinated?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 07:13:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 07:13:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO1K7-0005nk-5d; Tue, 16 Oct 2012 07:12:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO1K4-0005nL-SQ
	for xen-devel@lists.xensource.com; Tue, 16 Oct 2012 07:12:17 +0000
Received: from [85.158.143.99:12936] by server-2.bemta-4.messagelabs.com id
	01/2C-22268-0D80D705; Tue, 16 Oct 2012 07:12:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1350371535!28973076!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQyNjc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13695 invoked from network); 16 Oct 2012 07:12:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 07:12:15 -0000
X-IronPort-AV: E=Sophos;i="4.80,593,1344211200"; d="scan'208";a="15193626"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Oct 2012 07:12:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 16 Oct 2012 08:12:15 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TO1K2-0002GN-Eq;
	Tue, 16 Oct 2012 07:12:14 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TO1K2-0003Jp-BN;
	Tue, 16 Oct 2012 08:12:14 +0100
To: 
Message-ID: 
From: xen.org 
Date: Tue, 16 Oct 2012 08:12:14 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13967: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13967 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13967/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13962
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13962
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13962
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13962

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  c1c549c4fe9e
baseline version:
 xen                  e0e1350dfe9b

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf 
  Ian Campbell 
  Jacob Shin 
  Jan Beulich 
  Keir Fraser 
  Tim Deegan 
  Wei Wang 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=c1c549c4fe9e
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable c1c549c4fe9e
+ branch=xen-unstable
+ revision=c1c549c4fe9e
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r c1c549c4fe9e ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 7 changesets with 18 changes to 16 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 07:13:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 07:13:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO1K7-0005nk-5d; Tue, 16 Oct 2012 07:12:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO1K4-0005nL-SQ
	for xen-devel@lists.xensource.com; Tue, 16 Oct 2012 07:12:17 +0000
Received: from [85.158.143.99:12936] by server-2.bemta-4.messagelabs.com id
	01/2C-22268-0D80D705; Tue, 16 Oct 2012 07:12:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1350371535!28973076!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQyNjc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13695 invoked from network); 16 Oct 2012 07:12:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 07:12:15 -0000
X-IronPort-AV: E=Sophos;i="4.80,593,1344211200"; d="scan'208";a="15193626"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Oct 2012 07:12:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 16 Oct 2012 08:12:15 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TO1K2-0002GN-Eq;
	Tue, 16 Oct 2012 07:12:14 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TO1K2-0003Jp-BN;
	Tue, 16 Oct 2012 08:12:14 +0100
To: 
Message-ID: 
From: xen.org 
Date: Tue, 16 Oct 2012 08:12:14 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13967: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13967 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13967/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13962
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13962
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13962
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13962

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  c1c549c4fe9e
baseline version:
 xen                  e0e1350dfe9b

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf 
  Ian Campbell 
  Jacob Shin 
  Jan Beulich 
  Keir Fraser 
  Tim Deegan 
  Wei Wang 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=c1c549c4fe9e
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable c1c549c4fe9e
+ branch=xen-unstable
+ revision=c1c549c4fe9e
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r c1c549c4fe9e ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 7 changesets with 18 changes to 16 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 07:20:01 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 07:20:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO1Qt-00060x-AD; Tue, 16 Oct 2012 07:19:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO1Qr-00060s-Rv
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 07:19:18 +0000
Received: from [85.158.138.51:58414] by server-11.bemta-3.messagelabs.com id
	8E/6E-24008-57A0D705; Tue, 16 Oct 2012 07:19:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1350371956!34420371!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQyNjc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8523 invoked from network); 16 Oct 2012 07:19:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 07:19:16 -0000
X-IronPort-AV: E=Sophos;i="4.80,593,1344211200"; d="scan'208";a="15193776"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Oct 2012 07:19:16 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 16 Oct 2012 08:19:16 +0100
Message-ID: <1350371955.14440.11.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Jan Beulich 
Date: Tue, 16 Oct 2012 08:19:15 +0100
In-Reply-To: <507D241302000078000A198A@nat28.tlf.novell.com>
References: <507C3EE9.9040806@gmail.com>
	<507D241302000078000A198A@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Martin Roth , Ian Jackson ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Sharing MMIO page with DomU on a system with no
 IOMMU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-16 at 08:08 +0100, Jan Beulich wrote:
> >>> On 15.10.12 at 18:50, Martin Roth  wrote:
> > I'm trying to share an MMIO page from Dom0 running linux with a DomU 
> > running an RTOS so that I can access the GPIO registers directly. The 
> > system I need to get this working on does not have an IOMMU. I'm aware 
> > of the security issues of sharing this area, but don't believe it's an 
> > issue in this case.  I've got a Linux module set up and can share memory 
> > between the two domains using the grant table, but I haven't been able 
> > to get this to work for the MMIO page.
> > 
> > Can anyone give me a pointer on how I should go about doing this?  I 
> > need the area to actually be shared between both domains, not simply 
> > owned by the RTOS.
> 
> Looks like you have to assign the PCI device providing the GPIOs
> to the guest, as there doesn't currently appear to be a way to
> allow guest access to individual MMIO pages (lacking the MMIO
> counterpart to the iports= and irqs= domain config settings).
> 
> Ian, Ian - am I overlooking something?

iomem= support was committed to xl in xen-unstable last week or the week
before. I think it already existed in xend.

> 
> And of course - sharing the MMIO page between Dom0 and guest
> is a questionable intention in any case - you rather want it owned
> by the DomU, and Dom0 then shouldn't access it at all. Otherwise,
> how would you expect accesses to be coordinated?
> 
> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 07:20:01 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 07:20:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO1Qt-00060x-AD; Tue, 16 Oct 2012 07:19:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO1Qr-00060s-Rv
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 07:19:18 +0000
Received: from [85.158.138.51:58414] by server-11.bemta-3.messagelabs.com id
	8E/6E-24008-57A0D705; Tue, 16 Oct 2012 07:19:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1350371956!34420371!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQyNjc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8523 invoked from network); 16 Oct 2012 07:19:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 07:19:16 -0000
X-IronPort-AV: E=Sophos;i="4.80,593,1344211200"; d="scan'208";a="15193776"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Oct 2012 07:19:16 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 16 Oct 2012 08:19:16 +0100
Message-ID: <1350371955.14440.11.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Jan Beulich 
Date: Tue, 16 Oct 2012 08:19:15 +0100
In-Reply-To: <507D241302000078000A198A@nat28.tlf.novell.com>
References: <507C3EE9.9040806@gmail.com>
	<507D241302000078000A198A@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Martin Roth , Ian Jackson ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Sharing MMIO page with DomU on a system with no
 IOMMU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-16 at 08:08 +0100, Jan Beulich wrote:
> >>> On 15.10.12 at 18:50, Martin Roth  wrote:
> > I'm trying to share an MMIO page from Dom0 running linux with a DomU 
> > running an RTOS so that I can access the GPIO registers directly. The 
> > system I need to get this working on does not have an IOMMU. I'm aware 
> > of the security issues of sharing this area, but don't believe it's an 
> > issue in this case.  I've got a Linux module set up and can share memory 
> > between the two domains using the grant table, but I haven't been able 
> > to get this to work for the MMIO page.
> > 
> > Can anyone give me a pointer on how I should go about doing this?  I 
> > need the area to actually be shared between both domains, not simply 
> > owned by the RTOS.
> 
> Looks like you have to assign the PCI device providing the GPIOs
> to the guest, as there doesn't currently appear to be a way to
> allow guest access to individual MMIO pages (lacking the MMIO
> counterpart to the iports= and irqs= domain config settings).
> 
> Ian, Ian - am I overlooking something?

iomem= support was committed to xl in xen-unstable last week or the week
before. I think it already existed in xend.

> 
> And of course - sharing the MMIO page between Dom0 and guest
> is a questionable intention in any case - you rather want it owned
> by the DomU, and Dom0 then shouldn't access it at all. Otherwise,
> how would you expect accesses to be coordinated?
> 
> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 07:52:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 07:52:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO1wF-0006Gn-9B; Tue, 16 Oct 2012 07:51:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO1wE-0006Gi-K6
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 07:51:42 +0000
Received: from [85.158.138.51:28286] by server-9.bemta-3.messagelabs.com id
	F3/90-16841-D021D705; Tue, 16 Oct 2012 07:51:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1350373901!26477831!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17498 invoked from network); 16 Oct 2012 07:51:41 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-174.messagelabs.com with SMTP;
	16 Oct 2012 07:51:41 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 16 Oct 2012 08:51:40 +0100
Message-Id: <507D2E2902000078000A19B7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 16 Oct 2012 08:51:37 +0100
From: "Jan Beulich" 
To: "Keir Fraser" 
References: <201210152127478127583@gmail.com> 
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: tupeng212 , xen-devel 
Subject: Re: [Xen-devel] alloc_heap_pages is low efficient with more CPUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.10.12 at 17:45, Keir Fraser  wrote:
> On 15/10/2012 14:27, "tupeng212"  wrote:
> 
>> Please try the attached patch.
>> : Great!  you have done a good job, needless time decreases badly to 1s.
>>  
>> If anybody has no proposal, I suggest you to commit this patch.
> 
> I have applied it to xen-unstable. It probably makes sense to put it in 4.1
> and 4.2 as well (cc'ed Jan, and attaching the backport for 4.1 again).

Will do, but do you have an explanation how this simple, memory
only operation (64 CPUs isn't that many) has this dramatic an
effect on performance. Are we bouncing cache lines this badly? If
so, which one(s)? I don't see what would be written frequently
from multiple CPUs here - tlbflush_filter() itself only reads global
variables, but never writes them.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 07:52:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 07:52:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO1wF-0006Gn-9B; Tue, 16 Oct 2012 07:51:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO1wE-0006Gi-K6
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 07:51:42 +0000
Received: from [85.158.138.51:28286] by server-9.bemta-3.messagelabs.com id
	F3/90-16841-D021D705; Tue, 16 Oct 2012 07:51:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1350373901!26477831!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17498 invoked from network); 16 Oct 2012 07:51:41 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-174.messagelabs.com with SMTP;
	16 Oct 2012 07:51:41 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 16 Oct 2012 08:51:40 +0100
Message-Id: <507D2E2902000078000A19B7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 16 Oct 2012 08:51:37 +0100
From: "Jan Beulich" 
To: "Keir Fraser" 
References: <201210152127478127583@gmail.com> 
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: tupeng212 , xen-devel 
Subject: Re: [Xen-devel] alloc_heap_pages is low efficient with more CPUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.10.12 at 17:45, Keir Fraser  wrote:
> On 15/10/2012 14:27, "tupeng212"  wrote:
> 
>> Please try the attached patch.
>> : Great!  you have done a good job, needless time decreases badly to 1s.
>>  
>> If anybody has no proposal, I suggest you to commit this patch.
> 
> I have applied it to xen-unstable. It probably makes sense to put it in 4.1
> and 4.2 as well (cc'ed Jan, and attaching the backport for 4.1 again).

Will do, but do you have an explanation how this simple, memory
only operation (64 CPUs isn't that many) has this dramatic an
effect on performance. Are we bouncing cache lines this badly? If
so, which one(s)? I don't see what would be written frequently
from multiple CPUs here - tlbflush_filter() itself only reads global
variables, but never writes them.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 07:56:20 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 07:56:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO203-0006NP-UE; Tue, 16 Oct 2012 07:55:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO202-0006NH-H7
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 07:55:38 +0000
Received: from [85.158.138.51:56843] by server-9.bemta-3.messagelabs.com id
	45/B6-16841-9F21D705; Tue, 16 Oct 2012 07:55:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1350374136!32823184!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28601 invoked from network); 16 Oct 2012 07:55:37 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-174.messagelabs.com with SMTP;
	16 Oct 2012 07:55:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 16 Oct 2012 08:55:36 +0100
Message-Id: <507D2F1602000078000A19BA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 16 Oct 2012 08:55:34 +0100
From: "Jan Beulich" 
To: "Ian Campbell" 
References: <507C3EE9.9040806@gmail.com>
	<507D241302000078000A198A@nat28.tlf.novell.com>
	<1350371955.14440.11.camel@dagon.hellion.org.uk>
In-Reply-To: <1350371955.14440.11.camel@dagon.hellion.org.uk>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Martin Roth , Ian Jackson ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Sharing MMIO page with DomU on a system with no
 IOMMU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 16.10.12 at 09:19, Ian Campbell  wrote:
> On Tue, 2012-10-16 at 08:08 +0100, Jan Beulich wrote:
>> >>> On 15.10.12 at 18:50, Martin Roth  wrote:
>> > I'm trying to share an MMIO page from Dom0 running linux with a DomU 
>> > running an RTOS so that I can access the GPIO registers directly. The 
>> > system I need to get this working on does not have an IOMMU. I'm aware 
>> > of the security issues of sharing this area, but don't believe it's an 
>> > issue in this case.  I've got a Linux module set up and can share memory 
>> > between the two domains using the grant table, but I haven't been able 
>> > to get this to work for the MMIO page.
>> > 
>> > Can anyone give me a pointer on how I should go about doing this?  I 
>> > need the area to actually be shared between both domains, not simply 
>> > owned by the RTOS.
>> 
>> Looks like you have to assign the PCI device providing the GPIOs
>> to the guest, as there doesn't currently appear to be a way to
>> allow guest access to individual MMIO pages (lacking the MMIO
>> counterpart to the iports= and irqs= domain config settings).
>> 
>> Ian, Ian - am I overlooking something?
> 
> iomem= support was committed to xl in xen-unstable last week or the week
> before. I think it already existed in xend.

I fail to spot anything like that in xend - the only use of
domain_iomem_permission() is in server\pciif.py afaics.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 07:56:20 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 07:56:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO203-0006NP-UE; Tue, 16 Oct 2012 07:55:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO202-0006NH-H7
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 07:55:38 +0000
Received: from [85.158.138.51:56843] by server-9.bemta-3.messagelabs.com id
	45/B6-16841-9F21D705; Tue, 16 Oct 2012 07:55:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1350374136!32823184!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28601 invoked from network); 16 Oct 2012 07:55:37 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-174.messagelabs.com with SMTP;
	16 Oct 2012 07:55:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 16 Oct 2012 08:55:36 +0100
Message-Id: <507D2F1602000078000A19BA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 16 Oct 2012 08:55:34 +0100
From: "Jan Beulich" 
To: "Ian Campbell" 
References: <507C3EE9.9040806@gmail.com>
	<507D241302000078000A198A@nat28.tlf.novell.com>
	<1350371955.14440.11.camel@dagon.hellion.org.uk>
In-Reply-To: <1350371955.14440.11.camel@dagon.hellion.org.uk>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Martin Roth , Ian Jackson ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Sharing MMIO page with DomU on a system with no
 IOMMU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 16.10.12 at 09:19, Ian Campbell  wrote:
> On Tue, 2012-10-16 at 08:08 +0100, Jan Beulich wrote:
>> >>> On 15.10.12 at 18:50, Martin Roth  wrote:
>> > I'm trying to share an MMIO page from Dom0 running linux with a DomU 
>> > running an RTOS so that I can access the GPIO registers directly. The 
>> > system I need to get this working on does not have an IOMMU. I'm aware 
>> > of the security issues of sharing this area, but don't believe it's an 
>> > issue in this case.  I've got a Linux module set up and can share memory 
>> > between the two domains using the grant table, but I haven't been able 
>> > to get this to work for the MMIO page.
>> > 
>> > Can anyone give me a pointer on how I should go about doing this?  I 
>> > need the area to actually be shared between both domains, not simply 
>> > owned by the RTOS.
>> 
>> Looks like you have to assign the PCI device providing the GPIOs
>> to the guest, as there doesn't currently appear to be a way to
>> allow guest access to individual MMIO pages (lacking the MMIO
>> counterpart to the iports= and irqs= domain config settings).
>> 
>> Ian, Ian - am I overlooking something?
> 
> iomem= support was committed to xl in xen-unstable last week or the week
> before. I think it already existed in xend.

I fail to spot anything like that in xend - the only use of
domain_iomem_permission() is in server\pciif.py afaics.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 08:02:00 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 08:02:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO25a-0006yz-TS; Tue, 16 Oct 2012 08:01:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO25Z-0006yt-In
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 08:01:21 +0000
Received: from [85.158.138.51:10686] by server-3.bemta-3.messagelabs.com id
	E7/B3-09368-0541D705; Tue, 16 Oct 2012 08:01:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1350374480!26905596!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQyNjc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27589 invoked from network); 16 Oct 2012 08:01:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 08:01:20 -0000
X-IronPort-AV: E=Sophos;i="4.80,593,1344211200"; d="scan'208";a="15194642"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Oct 2012 08:01:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 16 Oct 2012 09:01:19 +0100
Message-ID: <1350374477.18058.86.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Jan Beulich 
Date: Tue, 16 Oct 2012 09:01:17 +0100
In-Reply-To: <507D2F1602000078000A19BA@nat28.tlf.novell.com>
References: <507C3EE9.9040806@gmail.com>
	<507D241302000078000A198A@nat28.tlf.novell.com>
	<1350371955.14440.11.camel@dagon.hellion.org.uk>
	<507D2F1602000078000A19BA@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Martin Roth , Ian Jackson ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Sharing MMIO page with DomU on a system with no
 IOMMU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-16 at 08:55 +0100, Jan Beulich wrote:
> >>> On 16.10.12 at 09:19, Ian Campbell  wrote:
> > On Tue, 2012-10-16 at 08:08 +0100, Jan Beulich wrote:
> >> >>> On 15.10.12 at 18:50, Martin Roth  wrote:
> >> > I'm trying to share an MMIO page from Dom0 running linux with a DomU 
> >> > running an RTOS so that I can access the GPIO registers directly. The 
> >> > system I need to get this working on does not have an IOMMU. I'm aware 
> >> > of the security issues of sharing this area, but don't believe it's an 
> >> > issue in this case.  I've got a Linux module set up and can share memory 
> >> > between the two domains using the grant table, but I haven't been able 
> >> > to get this to work for the MMIO page.
> >> > 
> >> > Can anyone give me a pointer on how I should go about doing this?  I 
> >> > need the area to actually be shared between both domains, not simply 
> >> > owned by the RTOS.
> >> 
> >> Looks like you have to assign the PCI device providing the GPIOs
> >> to the guest, as there doesn't currently appear to be a way to
> >> allow guest access to individual MMIO pages (lacking the MMIO
> >> counterpart to the iports= and irqs= domain config settings).
> >> 
> >> Ian, Ian - am I overlooking something?
> > 
> > iomem= support was committed to xl in xen-unstable last week or the week
> > before. I think it already existed in xend.
> 
> I fail to spot anything like that in xend - the only use of
> domain_iomem_permission() is in server\pciif.py afaics.

You are right. I saw iomem in the grep output and neglected to look at
the path.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 08:02:00 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 08:02:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO25a-0006yz-TS; Tue, 16 Oct 2012 08:01:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO25Z-0006yt-In
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 08:01:21 +0000
Received: from [85.158.138.51:10686] by server-3.bemta-3.messagelabs.com id
	E7/B3-09368-0541D705; Tue, 16 Oct 2012 08:01:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1350374480!26905596!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQyNjc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27589 invoked from network); 16 Oct 2012 08:01:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 08:01:20 -0000
X-IronPort-AV: E=Sophos;i="4.80,593,1344211200"; d="scan'208";a="15194642"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Oct 2012 08:01:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 16 Oct 2012 09:01:19 +0100
Message-ID: <1350374477.18058.86.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Jan Beulich 
Date: Tue, 16 Oct 2012 09:01:17 +0100
In-Reply-To: <507D2F1602000078000A19BA@nat28.tlf.novell.com>
References: <507C3EE9.9040806@gmail.com>
	<507D241302000078000A198A@nat28.tlf.novell.com>
	<1350371955.14440.11.camel@dagon.hellion.org.uk>
	<507D2F1602000078000A19BA@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Martin Roth , Ian Jackson ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Sharing MMIO page with DomU on a system with no
 IOMMU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-16 at 08:55 +0100, Jan Beulich wrote:
> >>> On 16.10.12 at 09:19, Ian Campbell  wrote:
> > On Tue, 2012-10-16 at 08:08 +0100, Jan Beulich wrote:
> >> >>> On 15.10.12 at 18:50, Martin Roth  wrote:
> >> > I'm trying to share an MMIO page from Dom0 running linux with a DomU 
> >> > running an RTOS so that I can access the GPIO registers directly. The 
> >> > system I need to get this working on does not have an IOMMU. I'm aware 
> >> > of the security issues of sharing this area, but don't believe it's an 
> >> > issue in this case.  I've got a Linux module set up and can share memory 
> >> > between the two domains using the grant table, but I haven't been able 
> >> > to get this to work for the MMIO page.
> >> > 
> >> > Can anyone give me a pointer on how I should go about doing this?  I 
> >> > need the area to actually be shared between both domains, not simply 
> >> > owned by the RTOS.
> >> 
> >> Looks like you have to assign the PCI device providing the GPIOs
> >> to the guest, as there doesn't currently appear to be a way to
> >> allow guest access to individual MMIO pages (lacking the MMIO
> >> counterpart to the iports= and irqs= domain config settings).
> >> 
> >> Ian, Ian - am I overlooking something?
> > 
> > iomem= support was committed to xl in xen-unstable last week or the week
> > before. I think it already existed in xend.
> 
> I fail to spot anything like that in xend - the only use of
> domain_iomem_permission() is in server\pciif.py afaics.

You are right. I saw iomem in the grep output and neglected to look at
the path.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 08:04:21 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 08:04:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO27o-00075A-Ek; Tue, 16 Oct 2012 08:03:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO27n-000755-LB
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 08:03:39 +0000
Received: from [85.158.143.35:18258] by server-2.bemta-4.messagelabs.com id
	22/CE-22268-AD41D705; Tue, 16 Oct 2012 08:03:38 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1350374602!13134570!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2743 invoked from network); 16 Oct 2012 08:03:22 -0000
Received: from mail-ea0-f173.google.com (HELO mail-ea0-f173.google.com)
	(209.85.215.173)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 08:03:22 -0000
Received: by mail-ea0-f173.google.com with SMTP id a1so1451292eaa.32
	for ; Tue, 16 Oct 2012 01:03:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=jlXE+16RJisngmQ5NrcmWU9yZ1xY8x2H88C1aaECHzk=;
	b=hLrVh6ED3em5VWPeZ3AUMQnUKHqNSBxsM2fW5CpyEmKdYUCVazLyzS638C9Q4WlUE4
	ZmEUcNt+VIYjjHLbD5XbEdFUs9mNUkm5WU0X2pGbL6KsDSBsgSwWcDtbrTx2lydPHOnO
	UYk/HrSVFmMrH2T/alSdnS4My8UEGZi2Uo5TBwh04cNcOO87XjMK+65mqr7oo6mujuXc
	3okwDl9fREIXvbf52woPnDH+cTPfd+Gli6fFRsHbIa93jIWAmoefX5fAl26PX5FfPU5k
	imLlM9IC/aZBH7CjPj1aCOii6zl6Q551HQmmIi96Jy0f/TYxpfv1qVH8MTYvhuhOWmPg
	Ea5Q==
Received: by 10.14.205.3 with SMTP id i3mr19477974eeo.18.1350374601904;
	Tue, 16 Oct 2012 01:03:21 -0700 (PDT)
Received: from [192.168.1.69]
	(host86-183-156-141.range86-183.btcentralplus.com. [86.183.156.141])
	by mx.google.com with ESMTPS id d44sm28664657eeo.10.2012.10.16.01.03.20
	(version=SSLv3 cipher=OTHER); Tue, 16 Oct 2012 01:03:21 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Tue, 16 Oct 2012 09:03:17 +0100
From: Keir Fraser 
To: Jan Beulich 
Message-ID: 
Thread-Topic: [Xen-devel] alloc_heap_pages is low efficient with more CPUs
Thread-Index: Ac2rdLLsUIiHLv/EEEmPME4sCqzrEA==
In-Reply-To: <507D2E2902000078000A19B7@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: tupeng212 , xen-devel 
Subject: Re: [Xen-devel] alloc_heap_pages is low efficient with more CPUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 16/10/2012 08:51, "Jan Beulich"  wrote:

>>>> On 15.10.12 at 17:45, Keir Fraser  wrote:
>> On 15/10/2012 14:27, "tupeng212"  wrote:
>> 
>>> Please try the attached patch.
>>> : Great!  you have done a good job, needless time decreases badly to 1s.
>>>  
>>> If anybody has no proposal, I suggest you to commit this patch.
>> 
>> I have applied it to xen-unstable. It probably makes sense to put it in 4.1
>> and 4.2 as well (cc'ed Jan, and attaching the backport for 4.1 again).
> 
> Will do, but do you have an explanation how this simple, memory
> only operation (64 CPUs isn't that many) has this dramatic an
> effect on performance. Are we bouncing cache lines this badly? If
> so, which one(s)? I don't see what would be written frequently
> from multiple CPUs here - tlbflush_filter() itself only reads global
> variables, but never writes them.

It's just the small factors multiplying up. A 40G domain is 10M page
allocations, each of which does 64x per-cpu cpumask bitops and timestamp
compares. That's going on for a billion (10^9) times round
tlbflush_filter()s loop. Each iteration need only take a few CPU cycles for
the effect to actually be noticeable. If the stuff being touched were not in
the cache (which of course it is, since this path is so hot and not touching
much memory) it would probably take an hour to create the domain!

 -- Keir

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 08:04:21 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 08:04:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO27o-00075A-Ek; Tue, 16 Oct 2012 08:03:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO27n-000755-LB
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 08:03:39 +0000
Received: from [85.158.143.35:18258] by server-2.bemta-4.messagelabs.com id
	22/CE-22268-AD41D705; Tue, 16 Oct 2012 08:03:38 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1350374602!13134570!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2743 invoked from network); 16 Oct 2012 08:03:22 -0000
Received: from mail-ea0-f173.google.com (HELO mail-ea0-f173.google.com)
	(209.85.215.173)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 08:03:22 -0000
Received: by mail-ea0-f173.google.com with SMTP id a1so1451292eaa.32
	for ; Tue, 16 Oct 2012 01:03:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=jlXE+16RJisngmQ5NrcmWU9yZ1xY8x2H88C1aaECHzk=;
	b=hLrVh6ED3em5VWPeZ3AUMQnUKHqNSBxsM2fW5CpyEmKdYUCVazLyzS638C9Q4WlUE4
	ZmEUcNt+VIYjjHLbD5XbEdFUs9mNUkm5WU0X2pGbL6KsDSBsgSwWcDtbrTx2lydPHOnO
	UYk/HrSVFmMrH2T/alSdnS4My8UEGZi2Uo5TBwh04cNcOO87XjMK+65mqr7oo6mujuXc
	3okwDl9fREIXvbf52woPnDH+cTPfd+Gli6fFRsHbIa93jIWAmoefX5fAl26PX5FfPU5k
	imLlM9IC/aZBH7CjPj1aCOii6zl6Q551HQmmIi96Jy0f/TYxpfv1qVH8MTYvhuhOWmPg
	Ea5Q==
Received: by 10.14.205.3 with SMTP id i3mr19477974eeo.18.1350374601904;
	Tue, 16 Oct 2012 01:03:21 -0700 (PDT)
Received: from [192.168.1.69]
	(host86-183-156-141.range86-183.btcentralplus.com. [86.183.156.141])
	by mx.google.com with ESMTPS id d44sm28664657eeo.10.2012.10.16.01.03.20
	(version=SSLv3 cipher=OTHER); Tue, 16 Oct 2012 01:03:21 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Tue, 16 Oct 2012 09:03:17 +0100
From: Keir Fraser 
To: Jan Beulich 
Message-ID: 
Thread-Topic: [Xen-devel] alloc_heap_pages is low efficient with more CPUs
Thread-Index: Ac2rdLLsUIiHLv/EEEmPME4sCqzrEA==
In-Reply-To: <507D2E2902000078000A19B7@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: tupeng212 , xen-devel 
Subject: Re: [Xen-devel] alloc_heap_pages is low efficient with more CPUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 16/10/2012 08:51, "Jan Beulich"  wrote:

>>>> On 15.10.12 at 17:45, Keir Fraser  wrote:
>> On 15/10/2012 14:27, "tupeng212"  wrote:
>> 
>>> Please try the attached patch.
>>> : Great!  you have done a good job, needless time decreases badly to 1s.
>>>  
>>> If anybody has no proposal, I suggest you to commit this patch.
>> 
>> I have applied it to xen-unstable. It probably makes sense to put it in 4.1
>> and 4.2 as well (cc'ed Jan, and attaching the backport for 4.1 again).
> 
> Will do, but do you have an explanation how this simple, memory
> only operation (64 CPUs isn't that many) has this dramatic an
> effect on performance. Are we bouncing cache lines this badly? If
> so, which one(s)? I don't see what would be written frequently
> from multiple CPUs here - tlbflush_filter() itself only reads global
> variables, but never writes them.

It's just the small factors multiplying up. A 40G domain is 10M page
allocations, each of which does 64x per-cpu cpumask bitops and timestamp
compares. That's going on for a billion (10^9) times round
tlbflush_filter()s loop. Each iteration need only take a few CPU cycles for
the effect to actually be noticeable. If the stuff being touched were not in
the cache (which of course it is, since this path is so hot and not touching
much memory) it would probably take an hour to create the domain!

 -- Keir

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 08:29:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 08:29:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO2WK-0007NA-KT; Tue, 16 Oct 2012 08:29:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO2WJ-0007N5-LU
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 08:28:59 +0000
Received: from [85.158.138.51:46929] by server-11.bemta-3.messagelabs.com id
	64/D4-24008-ACA1D705; Tue, 16 Oct 2012 08:28:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1350376137!34593915!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1054 invoked from network); 16 Oct 2012 08:28:58 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-174.messagelabs.com with SMTP;
	16 Oct 2012 08:28:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 16 Oct 2012 09:28:58 +0100
Message-Id: <507D36E702000078000A19F0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 16 Oct 2012 09:28:54 +0100
From: "Jan Beulich" 
To: "Keir Fraser" 
References: <507D2E2902000078000A19B7@nat28.tlf.novell.com>
	
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: tupeng212 , xen-devel 
Subject: Re: [Xen-devel] alloc_heap_pages is low efficient with more CPUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 16.10.12 at 10:03, Keir Fraser  wrote:
> On 16/10/2012 08:51, "Jan Beulich"  wrote:
> 
>>>>> On 15.10.12 at 17:45, Keir Fraser  wrote:
>>> On 15/10/2012 14:27, "tupeng212"  wrote:
>>> 
>>>> Please try the attached patch.
>>>> : Great!  you have done a good job, needless time decreases badly to 1s.
>>>>  
>>>> If anybody has no proposal, I suggest you to commit this patch.
>>> 
>>> I have applied it to xen-unstable. It probably makes sense to put it in 4.1
>>> and 4.2 as well (cc'ed Jan, and attaching the backport for 4.1 again).
>> 
>> Will do, but do you have an explanation how this simple, memory
>> only operation (64 CPUs isn't that many) has this dramatic an
>> effect on performance. Are we bouncing cache lines this badly? If
>> so, which one(s)? I don't see what would be written frequently
>> from multiple CPUs here - tlbflush_filter() itself only reads global
>> variables, but never writes them.
> 
> It's just the small factors multiplying up. A 40G domain is 10M page
> allocations, each of which does 64x per-cpu cpumask bitops and timestamp
> compares. That's going on for a billion (10^9) times round
> tlbflush_filter()s loop. Each iteration need only take a few CPU cycles for
> the effect to actually be noticeable. If the stuff being touched were not in
> the cache (which of course it is, since this path is so hot and not touching
> much memory) it would probably take an hour to create the domain!

Which means that your TODO remark in the change description
is more than a nice-to-have, since
- in the fallback case using 4k allocations your change doesn't
  win anything
- even larger domains would still suffer from this very problem
  (albeit in 4.2 we try 1G allocations first, so your change should
  have an even more visible effect there, as long as falling back
  to smaller chunks isn't needed)

One question of course is whether, for sufficiently large allocation
requests on sufficiently large systems, trying to avoid the TLB
flush is worth it at all, considering that determining where to skip
the flushes is costing so much more than the flushes themselves.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 08:29:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 08:29:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO2WK-0007NA-KT; Tue, 16 Oct 2012 08:29:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO2WJ-0007N5-LU
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 08:28:59 +0000
Received: from [85.158.138.51:46929] by server-11.bemta-3.messagelabs.com id
	64/D4-24008-ACA1D705; Tue, 16 Oct 2012 08:28:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1350376137!34593915!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1054 invoked from network); 16 Oct 2012 08:28:58 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-174.messagelabs.com with SMTP;
	16 Oct 2012 08:28:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 16 Oct 2012 09:28:58 +0100
Message-Id: <507D36E702000078000A19F0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 16 Oct 2012 09:28:54 +0100
From: "Jan Beulich" 
To: "Keir Fraser" 
References: <507D2E2902000078000A19B7@nat28.tlf.novell.com>
	
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: tupeng212 , xen-devel 
Subject: Re: [Xen-devel] alloc_heap_pages is low efficient with more CPUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 16.10.12 at 10:03, Keir Fraser  wrote:
> On 16/10/2012 08:51, "Jan Beulich"  wrote:
> 
>>>>> On 15.10.12 at 17:45, Keir Fraser  wrote:
>>> On 15/10/2012 14:27, "tupeng212"  wrote:
>>> 
>>>> Please try the attached patch.
>>>> : Great!  you have done a good job, needless time decreases badly to 1s.
>>>>  
>>>> If anybody has no proposal, I suggest you to commit this patch.
>>> 
>>> I have applied it to xen-unstable. It probably makes sense to put it in 4.1
>>> and 4.2 as well (cc'ed Jan, and attaching the backport for 4.1 again).
>> 
>> Will do, but do you have an explanation how this simple, memory
>> only operation (64 CPUs isn't that many) has this dramatic an
>> effect on performance. Are we bouncing cache lines this badly? If
>> so, which one(s)? I don't see what would be written frequently
>> from multiple CPUs here - tlbflush_filter() itself only reads global
>> variables, but never writes them.
> 
> It's just the small factors multiplying up. A 40G domain is 10M page
> allocations, each of which does 64x per-cpu cpumask bitops and timestamp
> compares. That's going on for a billion (10^9) times round
> tlbflush_filter()s loop. Each iteration need only take a few CPU cycles for
> the effect to actually be noticeable. If the stuff being touched were not in
> the cache (which of course it is, since this path is so hot and not touching
> much memory) it would probably take an hour to create the domain!

Which means that your TODO remark in the change description
is more than a nice-to-have, since
- in the fallback case using 4k allocations your change doesn't
  win anything
- even larger domains would still suffer from this very problem
  (albeit in 4.2 we try 1G allocations first, so your change should
  have an even more visible effect there, as long as falling back
  to smaller chunks isn't needed)

One question of course is whether, for sufficiently large allocation
requests on sufficiently large systems, trying to avoid the TLB
flush is worth it at all, considering that determining where to skip
the flushes is costing so much more than the flushes themselves.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 08:54:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 08:54:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO2tr-0007lC-Ff; Tue, 16 Oct 2012 08:53:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO2tp-0007l7-CS
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 08:53:17 +0000
Received: from [85.158.139.211:50305] by server-2.bemta-5.messagelabs.com id
	96/AA-10520-C702D705; Tue, 16 Oct 2012 08:53:16 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1350377595!21468976!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15732 invoked from network); 16 Oct 2012 08:53:16 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 08:53:16 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so3605006eek.32
	for ; Tue, 16 Oct 2012 01:53:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=uY6fbtgclnrfG0wDzt71960DSw8rFqYAoLDcXtDge1k=;
	b=T2dnDaAlnjNO/OvtOhjD+8Kaz1tnWHufWMpjX843PLQdWDIk2pYMs8ApbOOC0xAVkC
	NQUuhHSiG+GkVv7LdF+RbXkkA7mLwtSqZg3GE1mTAGlRVCcuXAu2M68l3ya9qcJp3jAl
	qC8X1uS6vqV0iGfg8dQ0MhIv+l2VuYIK1u1gHGlb2v7o16zrEqRjK3MmKDnUhsXocQDA
	AN9ux3chWRXfW4if1FQyXZp6SMst/7KRdsElWAONZ4PX0//RH5GrPvzPCqAwvNI/t/Q/
	qnQnWWE9ugSD9wNKSkIdgFl662HECk/f2ZHwaM8qenaWK2TRjLqSdBITSmO6owBNyR7c
	NlBQ==
Received: by 10.14.203.65 with SMTP id e41mr5152673eeo.34.1350377595793;
	Tue, 16 Oct 2012 01:53:15 -0700 (PDT)
Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com.
	[86.183.156.141])
	by mx.google.com with ESMTPS id s1sm28862226eem.9.2012.10.16.01.53.13
	(version=SSLv3 cipher=OTHER); Tue, 16 Oct 2012 01:53:15 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Tue, 16 Oct 2012 09:53:08 +0100
From: Keir Fraser 
To: Jan Beulich 
Message-ID: 
Thread-Topic: [Xen-devel] alloc_heap_pages is low efficient with more CPUs
Thread-Index: Ac2re6my8tVS/Z1CVUa03bWv7r++Fg==
In-Reply-To: <507D36E702000078000A19F0@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: tupeng212 , xen-devel 
Subject: Re: [Xen-devel] alloc_heap_pages is low efficient with more CPUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 16/10/2012 09:28, "Jan Beulich"  wrote:

>> It's just the small factors multiplying up. A 40G domain is 10M page
>> allocations, each of which does 64x per-cpu cpumask bitops and timestamp
>> compares. That's going on for a billion (10^9) times round
>> tlbflush_filter()s loop. Each iteration need only take a few CPU cycles for
>> the effect to actually be noticeable. If the stuff being touched were not in
>> the cache (which of course it is, since this path is so hot and not touching
>> much memory) it would probably take an hour to create the domain!
> 
> Which means that your TODO remark in the change description
> is more than a nice-to-have, since
> - in the fallback case using 4k allocations your change doesn't
>   win anything
> - even larger domains would still suffer from this very problem
>   (albeit in 4.2 we try 1G allocations first, so your change should
>   have an even more visible effect there, as long as falling back
>   to smaller chunks isn't needed)

Agreed. This is a simple starting point which is also easy to backport
though, and solves the immediate observed problem.

> One question of course is whether, for sufficiently large allocation
> requests on sufficiently large systems, trying to avoid the TLB
> flush is worth it at all, considering that determining where to skip
> the flushes is costing so much more than the flushes themselves.

It might be a simpler option. I'll see how doing it the filtering way looks.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 08:54:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 08:54:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO2tr-0007lC-Ff; Tue, 16 Oct 2012 08:53:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO2tp-0007l7-CS
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 08:53:17 +0000
Received: from [85.158.139.211:50305] by server-2.bemta-5.messagelabs.com id
	96/AA-10520-C702D705; Tue, 16 Oct 2012 08:53:16 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1350377595!21468976!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15732 invoked from network); 16 Oct 2012 08:53:16 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 08:53:16 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so3605006eek.32
	for ; Tue, 16 Oct 2012 01:53:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=uY6fbtgclnrfG0wDzt71960DSw8rFqYAoLDcXtDge1k=;
	b=T2dnDaAlnjNO/OvtOhjD+8Kaz1tnWHufWMpjX843PLQdWDIk2pYMs8ApbOOC0xAVkC
	NQUuhHSiG+GkVv7LdF+RbXkkA7mLwtSqZg3GE1mTAGlRVCcuXAu2M68l3ya9qcJp3jAl
	qC8X1uS6vqV0iGfg8dQ0MhIv+l2VuYIK1u1gHGlb2v7o16zrEqRjK3MmKDnUhsXocQDA
	AN9ux3chWRXfW4if1FQyXZp6SMst/7KRdsElWAONZ4PX0//RH5GrPvzPCqAwvNI/t/Q/
	qnQnWWE9ugSD9wNKSkIdgFl662HECk/f2ZHwaM8qenaWK2TRjLqSdBITSmO6owBNyR7c
	NlBQ==
Received: by 10.14.203.65 with SMTP id e41mr5152673eeo.34.1350377595793;
	Tue, 16 Oct 2012 01:53:15 -0700 (PDT)
Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com.
	[86.183.156.141])
	by mx.google.com with ESMTPS id s1sm28862226eem.9.2012.10.16.01.53.13
	(version=SSLv3 cipher=OTHER); Tue, 16 Oct 2012 01:53:15 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Tue, 16 Oct 2012 09:53:08 +0100
From: Keir Fraser 
To: Jan Beulich 
Message-ID: 
Thread-Topic: [Xen-devel] alloc_heap_pages is low efficient with more CPUs
Thread-Index: Ac2re6my8tVS/Z1CVUa03bWv7r++Fg==
In-Reply-To: <507D36E702000078000A19F0@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: tupeng212 , xen-devel 
Subject: Re: [Xen-devel] alloc_heap_pages is low efficient with more CPUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 16/10/2012 09:28, "Jan Beulich"  wrote:

>> It's just the small factors multiplying up. A 40G domain is 10M page
>> allocations, each of which does 64x per-cpu cpumask bitops and timestamp
>> compares. That's going on for a billion (10^9) times round
>> tlbflush_filter()s loop. Each iteration need only take a few CPU cycles for
>> the effect to actually be noticeable. If the stuff being touched were not in
>> the cache (which of course it is, since this path is so hot and not touching
>> much memory) it would probably take an hour to create the domain!
> 
> Which means that your TODO remark in the change description
> is more than a nice-to-have, since
> - in the fallback case using 4k allocations your change doesn't
>   win anything
> - even larger domains would still suffer from this very problem
>   (albeit in 4.2 we try 1G allocations first, so your change should
>   have an even more visible effect there, as long as falling back
>   to smaller chunks isn't needed)

Agreed. This is a simple starting point which is also easy to backport
though, and solves the immediate observed problem.

> One question of course is whether, for sufficiently large allocation
> requests on sufficiently large systems, trying to avoid the TLB
> flush is worth it at all, considering that determining where to skip
> the flushes is costing so much more than the flushes themselves.

It might be a simpler option. I'll see how doing it the filtering way looks.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 08:55:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 08:55:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO2vO-0007pp-V8; Tue, 16 Oct 2012 08:54:54 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from ) id 1TO2vO-0007pQ-49
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 08:54:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1350377667!2357168!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11262 invoked from network); 16 Oct 2012 08:54:27 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-27.messagelabs.com with SMTP;
	16 Oct 2012 08:54:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 16 Oct 2012 09:54:26 +0100
Message-Id: <507D3CDF02000078000A1A11@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 16 Oct 2012 09:54:23 +0100
From: "Jan Beulich" 
To: "Ian Campbell" ,
	"Dan Carpenter" 
References: <20120913160032.GA29082@elgon.mountain>
	<1350296757.18058.21.camel@zakaz.uk.xensource.com>
In-Reply-To: <1350296757.18058.21.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel ,
	Konrad Rzeszutek Wilk ,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] potential integer overflow in xenbus_file_write()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.10.12 at 12:25, Ian Campbell  wrote:
> On Thu, 2012-09-13 at 19:00 +0300, Dan Carpenter wrote:
>> Hi,
> 
> Thanks Dan. I'm not sure anyone from Xen-land really monitors
> virtualization@. Adding xen-devel and Konrad.
> 
>> 
>> I was reading some code and had a question in xenbus_file_write()
>> 
>> drivers/xen/xenbus/xenbus_dev_frontend.c
>>    461          if ((len + u->len) > sizeof(u->u.buffer)) {
>>                      ^^^^^^^^^^^^
>> Can this addition overflow?
> 
> len is a size_t and u->len is an unsigned int, so I expect so.
> 
>>   Should the test be something like:
>> 
>> 	if (len > sizeof(u->u.buffer) || len + u->len > sizeof(u->u.buffer)) {
> 
> I think that would do it.

Actually, it can remain a single range check:

	if (len > sizeof(u->u.buffer) - u->len) {

because the rest of the code guarantees u->len to be less or
equal to sizeof(u->u.buffer) at all times.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 08:55:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 08:55:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO2vO-0007pp-V8; Tue, 16 Oct 2012 08:54:54 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from ) id 1TO2vO-0007pQ-49
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 08:54:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1350377667!2357168!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11262 invoked from network); 16 Oct 2012 08:54:27 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-27.messagelabs.com with SMTP;
	16 Oct 2012 08:54:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 16 Oct 2012 09:54:26 +0100
Message-Id: <507D3CDF02000078000A1A11@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 16 Oct 2012 09:54:23 +0100
From: "Jan Beulich" 
To: "Ian Campbell" ,
	"Dan Carpenter" 
References: <20120913160032.GA29082@elgon.mountain>
	<1350296757.18058.21.camel@zakaz.uk.xensource.com>
In-Reply-To: <1350296757.18058.21.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel ,
	Konrad Rzeszutek Wilk ,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] potential integer overflow in xenbus_file_write()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.10.12 at 12:25, Ian Campbell  wrote:
> On Thu, 2012-09-13 at 19:00 +0300, Dan Carpenter wrote:
>> Hi,
> 
> Thanks Dan. I'm not sure anyone from Xen-land really monitors
> virtualization@. Adding xen-devel and Konrad.
> 
>> 
>> I was reading some code and had a question in xenbus_file_write()
>> 
>> drivers/xen/xenbus/xenbus_dev_frontend.c
>>    461          if ((len + u->len) > sizeof(u->u.buffer)) {
>>                      ^^^^^^^^^^^^
>> Can this addition overflow?
> 
> len is a size_t and u->len is an unsigned int, so I expect so.
> 
>>   Should the test be something like:
>> 
>> 	if (len > sizeof(u->u.buffer) || len + u->len > sizeof(u->u.buffer)) {
> 
> I think that would do it.

Actually, it can remain a single range check:

	if (len > sizeof(u->u.buffer) - u->len) {

because the rest of the code guarantees u->len to be less or
equal to sizeof(u->u.buffer) at all times.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 08:59:51 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 08:59:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO2zZ-00083r-Qz; Tue, 16 Oct 2012 08:59:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO2zX-00083l-Pj
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 08:59:11 +0000
Received: from [85.158.139.211:11457] by server-10.bemta-5.messagelabs.com id
	38/81-01025-ED12D705; Tue, 16 Oct 2012 08:59:10 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-5.tower-206.messagelabs.com!1350377950!22436124!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11098 invoked from network); 16 Oct 2012 08:59:10 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-5.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	16 Oct 2012 08:59:10 -0000
Received: from 50-66-ftth.onsneteindhoven.nl ([88.159.66.50]:49300
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TO318-00032y-PI; Tue, 16 Oct 2012 11:00:50 +0200
Date: Tue, 16 Oct 2012 10:59:07 +0200
From: Sander Eikelenboom 
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1612556249.20121016105907@eikelenboom.it>
To: Ian Campbell 
In-Reply-To: <1350301533.18058.35.camel@zakaz.uk.xensource.com>
References: 
	<692244188.20121015123235@eikelenboom.it>
	<1350297477.18058.27.camel@zakaz.uk.xensource.com>
	<751865457.20121015132140@eikelenboom.it>
	<1350301533.18058.35.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl shutdown compatibility with xm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Monday, October 15, 2012, 1:45:33 PM, you wrote:

> On Mon, 2012-10-15 at 12:21 +0100, Sander Eikelenboom wrote:
>> Monday, October 15, 2012, 12:37:57 PM, you wrote:
>> 
>> > On Mon, 2012-10-15 at 11:32 +0100, Sander Eikelenboom wrote:
>> >> Hi Ian,
>> >> 
>> >> Great thanks !
>> >> Only thing i was wondering about:
>> >> 
>> >> Shouldn't the "-F" option be dropped in favour of always trying the
>> >> "acpi fallback" when the pv shutdown fails.
>> >> 
>> >> This because the shutdown scripts still don't work for domains without
>> >> pv shutdown and i don't see a down side to just trying that as
>> >> fallback.
>> 
>> > It is guess OS dependent what the ACPI button press event does, it can
>> > reboot, shutdown or hibernate etc depending on the OS type and its
>> > configuration. (in theory I suppose it is completely arbitrary e.g. it
>> > could be configured to eject the CD-ROM or something equally random).
>> 
>> > Therefore the user needs to be aware of when they can safely use it.
>> 
>> Well yes and no:
>>     - can't remember having (to make) that choice with xm ?

> Looks like xend uses SCHEDOP_remote_shutdown. It's unclear to me why
> this is better than just shooting the domain with destroy...

>>     - On shutdown with xl as toolstack and when the guest doesn't
>> support pv shutdown, the init.d/xendomains script doesn't even attempt
>> to shutdown this guest by acpi fallback.
>>     - As a result when using xl as toolstack, the guest is terminated
>> non gracefully when the whole machine finally shutsdown, which seems
>> less desirable then at least *trying* to shut it down gracefully by
>> using the acpi button.

> Using the ACPI fallback is a decision which can only be made locally
> with full knowledge of the configuration of the guests.

I'm not totally convinced (yet):
  - In case of a system shutdown, it seems better to at least *try* instead of just halting the system without shutting such a guest down.
      For the shutdown scripts the problems is that there is no way to give it the "full knowledge" of how to shutdown a particular guest.
      It would be possible to use the -F flag in the sysconfig xendomains file, since the pv shutdown is always tried first.

  - Not everyone seems to be aware, say an IanJ ;-)
      Under the assumption that the guests in the xen-test-harness do react in the right way to a acpi powerbutton event,
      it seems the "never passes" in  "Guest-stop" row of http://www.chiark.greenend.org.uk/~xensrcts/logs/13967/
      Will probably pass when the -F option will be used, see http://www.chiark.greenend.org.uk/~xensrcts/logs/13967/test-amd64-i386-xl-win7-amd64/13.ts-guest-stop.log

--
Sander

> Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 08:59:51 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 08:59:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO2zZ-00083r-Qz; Tue, 16 Oct 2012 08:59:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO2zX-00083l-Pj
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 08:59:11 +0000
Received: from [85.158.139.211:11457] by server-10.bemta-5.messagelabs.com id
	38/81-01025-ED12D705; Tue, 16 Oct 2012 08:59:10 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-5.tower-206.messagelabs.com!1350377950!22436124!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11098 invoked from network); 16 Oct 2012 08:59:10 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-5.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	16 Oct 2012 08:59:10 -0000
Received: from 50-66-ftth.onsneteindhoven.nl ([88.159.66.50]:49300
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TO318-00032y-PI; Tue, 16 Oct 2012 11:00:50 +0200
Date: Tue, 16 Oct 2012 10:59:07 +0200
From: Sander Eikelenboom 
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1612556249.20121016105907@eikelenboom.it>
To: Ian Campbell 
In-Reply-To: <1350301533.18058.35.camel@zakaz.uk.xensource.com>
References: 
	<692244188.20121015123235@eikelenboom.it>
	<1350297477.18058.27.camel@zakaz.uk.xensource.com>
	<751865457.20121015132140@eikelenboom.it>
	<1350301533.18058.35.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl shutdown compatibility with xm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Monday, October 15, 2012, 1:45:33 PM, you wrote:

> On Mon, 2012-10-15 at 12:21 +0100, Sander Eikelenboom wrote:
>> Monday, October 15, 2012, 12:37:57 PM, you wrote:
>> 
>> > On Mon, 2012-10-15 at 11:32 +0100, Sander Eikelenboom wrote:
>> >> Hi Ian,
>> >> 
>> >> Great thanks !
>> >> Only thing i was wondering about:
>> >> 
>> >> Shouldn't the "-F" option be dropped in favour of always trying the
>> >> "acpi fallback" when the pv shutdown fails.
>> >> 
>> >> This because the shutdown scripts still don't work for domains without
>> >> pv shutdown and i don't see a down side to just trying that as
>> >> fallback.
>> 
>> > It is guess OS dependent what the ACPI button press event does, it can
>> > reboot, shutdown or hibernate etc depending on the OS type and its
>> > configuration. (in theory I suppose it is completely arbitrary e.g. it
>> > could be configured to eject the CD-ROM or something equally random).
>> 
>> > Therefore the user needs to be aware of when they can safely use it.
>> 
>> Well yes and no:
>>     - can't remember having (to make) that choice with xm ?

> Looks like xend uses SCHEDOP_remote_shutdown. It's unclear to me why
> this is better than just shooting the domain with destroy...

>>     - On shutdown with xl as toolstack and when the guest doesn't
>> support pv shutdown, the init.d/xendomains script doesn't even attempt
>> to shutdown this guest by acpi fallback.
>>     - As a result when using xl as toolstack, the guest is terminated
>> non gracefully when the whole machine finally shutsdown, which seems
>> less desirable then at least *trying* to shut it down gracefully by
>> using the acpi button.

> Using the ACPI fallback is a decision which can only be made locally
> with full knowledge of the configuration of the guests.

I'm not totally convinced (yet):
  - In case of a system shutdown, it seems better to at least *try* instead of just halting the system without shutting such a guest down.
      For the shutdown scripts the problems is that there is no way to give it the "full knowledge" of how to shutdown a particular guest.
      It would be possible to use the -F flag in the sysconfig xendomains file, since the pv shutdown is always tried first.

  - Not everyone seems to be aware, say an IanJ ;-)
      Under the assumption that the guests in the xen-test-harness do react in the right way to a acpi powerbutton event,
      it seems the "never passes" in  "Guest-stop" row of http://www.chiark.greenend.org.uk/~xensrcts/logs/13967/
      Will probably pass when the -F option will be used, see http://www.chiark.greenend.org.uk/~xensrcts/logs/13967/test-amd64-i386-xl-win7-amd64/13.ts-guest-stop.log

--
Sander

> Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 09:07:53 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 09:07:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO37M-0008Ia-8d; Tue, 16 Oct 2012 09:07:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO37K-0008IV-GP
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 09:07:14 +0000
Received: from [85.158.143.99:43214] by server-3.bemta-4.messagelabs.com id
	6C/AF-03544-1C32D705; Tue, 16 Oct 2012 09:07:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1350378432!26099862!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20478 invoked from network); 16 Oct 2012 09:07:12 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-216.messagelabs.com with SMTP;
	16 Oct 2012 09:07:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 16 Oct 2012 10:07:12 +0100
Message-Id: <507D3FDD02000078000A1A2C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 16 Oct 2012 10:07:09 +0100
From: "Jan Beulich" 
To: "Ian Campbell" ,
	"Dan Carpenter" 
References: <20120914112427.GA1454@elgon.mountain>
	<1350296868.18058.24.camel@zakaz.uk.xensource.com>
In-Reply-To: <1350296868.18058.24.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tang Liang , xen-devel ,
	Jeremy Fitzhardinge ,
	Konrad Rzeszutek Wilk ,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] memory corruption in HYPERVISOR_physdev_op()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.10.12 at 12:27, Ian Campbell  wrote:
>> My static analyzer complains about potential memory corruption in
>> HYPERVISOR_physdev_op()
>> 
>> arch/x86/include/asm/xen/hypercall.h
>>    389  static inline int
>>    390  HYPERVISOR_physdev_op(int cmd, void *arg)
>>    391  {
>>    392          int rc = _hypercall2(int, physdev_op, cmd, arg);
>>    393          if (unlikely(rc == -ENOSYS)) {
>>    394                  struct physdev_op op;
>>    395                  op.cmd = cmd;
>>    396                  memcpy(&op.u, arg, sizeof(op.u));
>>    397                  rc = _hypercall1(int, physdev_op_compat, &op);
>>    398                  memcpy(arg, &op.u, sizeof(op.u));
>>                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> Some of the arg buffers are not as large as sizeof(op.u) which is either
>> 12 or 16 depending on the size of longs in struct physdev_apic.
> 
> Nasty!

Doesn't the same problem also exist for
HYPERVISOR_event_channel_op() then, at least theoretically
(EVTCHNOP_reset is apparently the only addition here so far,
but is being used by the tools only afaics)?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 09:07:53 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 09:07:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO37M-0008Ia-8d; Tue, 16 Oct 2012 09:07:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO37K-0008IV-GP
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 09:07:14 +0000
Received: from [85.158.143.99:43214] by server-3.bemta-4.messagelabs.com id
	6C/AF-03544-1C32D705; Tue, 16 Oct 2012 09:07:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1350378432!26099862!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20478 invoked from network); 16 Oct 2012 09:07:12 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-216.messagelabs.com with SMTP;
	16 Oct 2012 09:07:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 16 Oct 2012 10:07:12 +0100
Message-Id: <507D3FDD02000078000A1A2C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 16 Oct 2012 10:07:09 +0100
From: "Jan Beulich" 
To: "Ian Campbell" ,
	"Dan Carpenter" 
References: <20120914112427.GA1454@elgon.mountain>
	<1350296868.18058.24.camel@zakaz.uk.xensource.com>
In-Reply-To: <1350296868.18058.24.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tang Liang , xen-devel ,
	Jeremy Fitzhardinge ,
	Konrad Rzeszutek Wilk ,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] memory corruption in HYPERVISOR_physdev_op()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.10.12 at 12:27, Ian Campbell  wrote:
>> My static analyzer complains about potential memory corruption in
>> HYPERVISOR_physdev_op()
>> 
>> arch/x86/include/asm/xen/hypercall.h
>>    389  static inline int
>>    390  HYPERVISOR_physdev_op(int cmd, void *arg)
>>    391  {
>>    392          int rc = _hypercall2(int, physdev_op, cmd, arg);
>>    393          if (unlikely(rc == -ENOSYS)) {
>>    394                  struct physdev_op op;
>>    395                  op.cmd = cmd;
>>    396                  memcpy(&op.u, arg, sizeof(op.u));
>>    397                  rc = _hypercall1(int, physdev_op_compat, &op);
>>    398                  memcpy(arg, &op.u, sizeof(op.u));
>>                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> Some of the arg buffers are not as large as sizeof(op.u) which is either
>> 12 or 16 depending on the size of longs in struct physdev_apic.
> 
> Nasty!

Doesn't the same problem also exist for
HYPERVISOR_event_channel_op() then, at least theoretically
(EVTCHNOP_reset is apparently the only addition here so far,
but is being used by the tools only afaics)?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 09:14:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 09:14:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO3Dl-0008Ty-3b; Tue, 16 Oct 2012 09:13:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO3Dj-0008Ts-DM
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 09:13:51 +0000
Received: from [85.158.139.211:52012] by server-9.bemta-5.messagelabs.com id
	A3/C2-23053-E452D705; Tue, 16 Oct 2012 09:13:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1350378829!22416200!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2MDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 876 invoked from network); 16 Oct 2012 09:13:49 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-206.messagelabs.com with SMTP;
	16 Oct 2012 09:13:49 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 16 Oct 2012 10:13:49 +0100
Message-Id: <507D416902000078000A1A57@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 16 Oct 2012 10:13:45 +0100
From: "Jan Beulich" 
To: "Ian Campbell" ,
	"Dan Carpenter" ,
	"Jan Beulich" 
References: <20120914112427.GA1454@elgon.mountain>
	<1350296868.18058.24.camel@zakaz.uk.xensource.com>
	<507D3FDD02000078000A1A2C@nat28.tlf.novell.com>
In-Reply-To: <507D3FDD02000078000A1A2C@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tang Liang , xen-devel ,
	Jeremy Fitzhardinge ,
	Konrad Rzeszutek Wilk ,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] memory corruption in HYPERVISOR_physdev_op()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 16.10.12 at 11:07, "Jan Beulich"  wrote:
>>>> On 15.10.12 at 12:27, Ian Campbell  wrote:
>>> My static analyzer complains about potential memory corruption in
>>> HYPERVISOR_physdev_op()
>>> 
>>> arch/x86/include/asm/xen/hypercall.h
>>>    389  static inline int
>>>    390  HYPERVISOR_physdev_op(int cmd, void *arg)
>>>    391  {
>>>    392          int rc = _hypercall2(int, physdev_op, cmd, arg);
>>>    393          if (unlikely(rc == -ENOSYS)) {
>>>    394                  struct physdev_op op;
>>>    395                  op.cmd = cmd;
>>>    396                  memcpy(&op.u, arg, sizeof(op.u));
>>>    397                  rc = _hypercall1(int, physdev_op_compat, &op);
>>>    398                  memcpy(arg, &op.u, sizeof(op.u));
>>>                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> Some of the arg buffers are not as large as sizeof(op.u) which is either
>>> 12 or 16 depending on the size of longs in struct physdev_apic.
>> 
>> Nasty!
> 
> Doesn't the same problem also exist for
> HYPERVISOR_event_channel_op() then, at least theoretically
> (EVTCHNOP_reset is apparently the only addition here so far,
> but is being used by the tools only afaics)?

Actually, the problem isn't tied to new additions of sub-hypercalls
(I was wrongly implying this from the example originally provided),
and should be visible e.g. on any use of EVTCHNOP_unmask.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 09:14:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 09:14:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO3Dl-0008Ty-3b; Tue, 16 Oct 2012 09:13:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO3Dj-0008Ts-DM
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 09:13:51 +0000
Received: from [85.158.139.211:52012] by server-9.bemta-5.messagelabs.com id
	A3/C2-23053-E452D705; Tue, 16 Oct 2012 09:13:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1350378829!22416200!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2MDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 876 invoked from network); 16 Oct 2012 09:13:49 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-206.messagelabs.com with SMTP;
	16 Oct 2012 09:13:49 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 16 Oct 2012 10:13:49 +0100
Message-Id: <507D416902000078000A1A57@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 16 Oct 2012 10:13:45 +0100
From: "Jan Beulich" 
To: "Ian Campbell" ,
	"Dan Carpenter" ,
	"Jan Beulich" 
References: <20120914112427.GA1454@elgon.mountain>
	<1350296868.18058.24.camel@zakaz.uk.xensource.com>
	<507D3FDD02000078000A1A2C@nat28.tlf.novell.com>
In-Reply-To: <507D3FDD02000078000A1A2C@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tang Liang , xen-devel ,
	Jeremy Fitzhardinge ,
	Konrad Rzeszutek Wilk ,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] memory corruption in HYPERVISOR_physdev_op()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 16.10.12 at 11:07, "Jan Beulich"  wrote:
>>>> On 15.10.12 at 12:27, Ian Campbell  wrote:
>>> My static analyzer complains about potential memory corruption in
>>> HYPERVISOR_physdev_op()
>>> 
>>> arch/x86/include/asm/xen/hypercall.h
>>>    389  static inline int
>>>    390  HYPERVISOR_physdev_op(int cmd, void *arg)
>>>    391  {
>>>    392          int rc = _hypercall2(int, physdev_op, cmd, arg);
>>>    393          if (unlikely(rc == -ENOSYS)) {
>>>    394                  struct physdev_op op;
>>>    395                  op.cmd = cmd;
>>>    396                  memcpy(&op.u, arg, sizeof(op.u));
>>>    397                  rc = _hypercall1(int, physdev_op_compat, &op);
>>>    398                  memcpy(arg, &op.u, sizeof(op.u));
>>>                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> Some of the arg buffers are not as large as sizeof(op.u) which is either
>>> 12 or 16 depending on the size of longs in struct physdev_apic.
>> 
>> Nasty!
> 
> Doesn't the same problem also exist for
> HYPERVISOR_event_channel_op() then, at least theoretically
> (EVTCHNOP_reset is apparently the only addition here so far,
> but is being used by the tools only afaics)?

Actually, the problem isn't tied to new additions of sub-hypercalls
(I was wrongly implying this from the example originally provided),
and should be visible e.g. on any use of EVTCHNOP_unmask.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 09:44:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 09:44:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO3gL-0000Hs-LD; Tue, 16 Oct 2012 09:43:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO3gK-0000Hn-68
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 09:43:24 +0000
Received: from [85.158.143.35:9023] by server-1.bemta-4.messagelabs.com id
	DE/35-19134-B3C2D705; Tue, 16 Oct 2012 09:43:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1350380602!14547731!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQzMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17435 invoked from network); 16 Oct 2012 09:43:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 09:43:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,593,1344211200"; d="scan'208";a="15197747"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Oct 2012 09:43:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 16 Oct 2012 10:43:21 +0100
Message-ID: <1350380600.18058.109.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Sander Eikelenboom 
Date: Tue, 16 Oct 2012 10:43:20 +0100
In-Reply-To: <1612556249.20121016105907@eikelenboom.it>
References: 
	<692244188.20121015123235@eikelenboom.it>
	<1350297477.18058.27.camel@zakaz.uk.xensource.com>
	<751865457.20121015132140@eikelenboom.it>
	<1350301533.18058.35.camel@zakaz.uk.xensource.com>
	<1612556249.20121016105907@eikelenboom.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl shutdown compatibility with xm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-16 at 09:59 +0100, Sander Eikelenboom wrote:
> Monday, October 15, 2012, 1:45:33 PM, you wrote:
> 
> > On Mon, 2012-10-15 at 12:21 +0100, Sander Eikelenboom wrote:
> >> Monday, October 15, 2012, 12:37:57 PM, you wrote:
> >> 
> >> > On Mon, 2012-10-15 at 11:32 +0100, Sander Eikelenboom wrote:
> >> >> Hi Ian,
> >> >> 
> >> >> Great thanks !
> >> >> Only thing i was wondering about:
> >> >> 
> >> >> Shouldn't the "-F" option be dropped in favour of always trying the
> >> >> "acpi fallback" when the pv shutdown fails.
> >> >> 
> >> >> This because the shutdown scripts still don't work for domains without
> >> >> pv shutdown and i don't see a down side to just trying that as
> >> >> fallback.
> >> 
> >> > It is guess OS dependent what the ACPI button press event does, it can
> >> > reboot, shutdown or hibernate etc depending on the OS type and its
> >> > configuration. (in theory I suppose it is completely arbitrary e.g. it
> >> > could be configured to eject the CD-ROM or something equally random).
> >> 
> >> > Therefore the user needs to be aware of when they can safely use it.
> >> 
> >> Well yes and no:
> >>     - can't remember having (to make) that choice with xm ?
> 
> > Looks like xend uses SCHEDOP_remote_shutdown. It's unclear to me why
> > this is better than just shooting the domain with destroy...
> 
> >>     - On shutdown with xl as toolstack and when the guest doesn't
> >> support pv shutdown, the init.d/xendomains script doesn't even attempt
> >> to shutdown this guest by acpi fallback.
> >>     - As a result when using xl as toolstack, the guest is terminated
> >> non gracefully when the whole machine finally shutsdown, which seems
> >> less desirable then at least *trying* to shut it down gracefully by
> >> using the acpi button.
> 
> > Using the ACPI fallback is a decision which can only be made locally
> > with full knowledge of the configuration of the guests.
> 
> I'm not totally convinced (yet):
>   - In case of a system shutdown, it seems better to at least *try* instead of just halting the system without shutting such a guest down.

You might as well do xl shutdown, wait a bit, xl destroy in the
initscript. "xm shutdown" is effectively "xm destroy" for guests without
PV drivers.

>       For the shutdown scripts the problems is that there is no way to give it the "full knowledge" of how to shutdown a particular guest.
>       It would be possible to use the -F flag in the sysconfig xendomains file, since the pv shutdown is always tried first.

It would be possible for an individual administrator to add -F if that
is compatible with their configuration. It would be inappropriate for
upstream to do this by default because we *don't know* what -F does to
an arbitrary guest.

>   - Not everyone seems to be aware, say an IanJ ;-)
>       Under the assumption that the guests in the xen-test-harness do react in the right way to a acpi powerbutton event,
>       it seems the "never passes" in  "Guest-stop" row of http://www.chiark.greenend.org.uk/~xensrcts/logs/13967/
>       Will probably pass when the -F option will be used, see http://www.chiark.greenend.org.uk/~xensrcts/logs/13967/test-amd64-i386-xl-win7-amd64/13.ts-guest-stop.log

Ian J is well aware that -F could help here (this is the main reason I
implemented this option). It would be appropriate here because we can
control the guest OS configuration in the harness (and if we can't we
shouldn't use -F).

He just hasn't implemented it in the harness yet (TBH I suspect he has
forgotten ;-)).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 09:44:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 09:44:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO3gL-0000Hs-LD; Tue, 16 Oct 2012 09:43:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO3gK-0000Hn-68
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 09:43:24 +0000
Received: from [85.158.143.35:9023] by server-1.bemta-4.messagelabs.com id
	DE/35-19134-B3C2D705; Tue, 16 Oct 2012 09:43:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1350380602!14547731!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQzMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17435 invoked from network); 16 Oct 2012 09:43:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 09:43:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,593,1344211200"; d="scan'208";a="15197747"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Oct 2012 09:43:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 16 Oct 2012 10:43:21 +0100
Message-ID: <1350380600.18058.109.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Sander Eikelenboom 
Date: Tue, 16 Oct 2012 10:43:20 +0100
In-Reply-To: <1612556249.20121016105907@eikelenboom.it>
References: 
	<692244188.20121015123235@eikelenboom.it>
	<1350297477.18058.27.camel@zakaz.uk.xensource.com>
	<751865457.20121015132140@eikelenboom.it>
	<1350301533.18058.35.camel@zakaz.uk.xensource.com>
	<1612556249.20121016105907@eikelenboom.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl shutdown compatibility with xm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-16 at 09:59 +0100, Sander Eikelenboom wrote:
> Monday, October 15, 2012, 1:45:33 PM, you wrote:
> 
> > On Mon, 2012-10-15 at 12:21 +0100, Sander Eikelenboom wrote:
> >> Monday, October 15, 2012, 12:37:57 PM, you wrote:
> >> 
> >> > On Mon, 2012-10-15 at 11:32 +0100, Sander Eikelenboom wrote:
> >> >> Hi Ian,
> >> >> 
> >> >> Great thanks !
> >> >> Only thing i was wondering about:
> >> >> 
> >> >> Shouldn't the "-F" option be dropped in favour of always trying the
> >> >> "acpi fallback" when the pv shutdown fails.
> >> >> 
> >> >> This because the shutdown scripts still don't work for domains without
> >> >> pv shutdown and i don't see a down side to just trying that as
> >> >> fallback.
> >> 
> >> > It is guess OS dependent what the ACPI button press event does, it can
> >> > reboot, shutdown or hibernate etc depending on the OS type and its
> >> > configuration. (in theory I suppose it is completely arbitrary e.g. it
> >> > could be configured to eject the CD-ROM or something equally random).
> >> 
> >> > Therefore the user needs to be aware of when they can safely use it.
> >> 
> >> Well yes and no:
> >>     - can't remember having (to make) that choice with xm ?
> 
> > Looks like xend uses SCHEDOP_remote_shutdown. It's unclear to me why
> > this is better than just shooting the domain with destroy...
> 
> >>     - On shutdown with xl as toolstack and when the guest doesn't
> >> support pv shutdown, the init.d/xendomains script doesn't even attempt
> >> to shutdown this guest by acpi fallback.
> >>     - As a result when using xl as toolstack, the guest is terminated
> >> non gracefully when the whole machine finally shutsdown, which seems
> >> less desirable then at least *trying* to shut it down gracefully by
> >> using the acpi button.
> 
> > Using the ACPI fallback is a decision which can only be made locally
> > with full knowledge of the configuration of the guests.
> 
> I'm not totally convinced (yet):
>   - In case of a system shutdown, it seems better to at least *try* instead of just halting the system without shutting such a guest down.

You might as well do xl shutdown, wait a bit, xl destroy in the
initscript. "xm shutdown" is effectively "xm destroy" for guests without
PV drivers.

>       For the shutdown scripts the problems is that there is no way to give it the "full knowledge" of how to shutdown a particular guest.
>       It would be possible to use the -F flag in the sysconfig xendomains file, since the pv shutdown is always tried first.

It would be possible for an individual administrator to add -F if that
is compatible with their configuration. It would be inappropriate for
upstream to do this by default because we *don't know* what -F does to
an arbitrary guest.

>   - Not everyone seems to be aware, say an IanJ ;-)
>       Under the assumption that the guests in the xen-test-harness do react in the right way to a acpi powerbutton event,
>       it seems the "never passes" in  "Guest-stop" row of http://www.chiark.greenend.org.uk/~xensrcts/logs/13967/
>       Will probably pass when the -F option will be used, see http://www.chiark.greenend.org.uk/~xensrcts/logs/13967/test-amd64-i386-xl-win7-amd64/13.ts-guest-stop.log

Ian J is well aware that -F could help here (this is the main reason I
implemented this option). It would be appropriate here because we can
control the guest OS configuration in the harness (and if we can't we
shouldn't use -F).

He just hasn't implemented it in the harness yet (TBH I suspect he has
forgotten ;-)).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 09:58:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 09:58:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO3ty-0000T0-2a; Tue, 16 Oct 2012 09:57:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNysW-0004P7-8q
	for xen-devel@lists.xensource.com; Tue, 16 Oct 2012 04:35:40 +0000
Received: from [85.158.137.99:61863] by server-1.bemta-3.messagelabs.com id
	B2/C3-31728-B14EC705; Tue, 16 Oct 2012 04:35:39 +0000
X-Env-Sender: liuxiaolei1124@163.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1350362127!16909508!1
X-Originating-IP: [220.181.13.140]
X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_50_60,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23918 invoked from network); 16 Oct 2012 04:35:35 -0000
Received: from m13-140.163.com (HELO m13-140.163.com) (220.181.13.140)
	by server-7.tower-217.messagelabs.com with SMTP;
	16 Oct 2012 04:35:35 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com;
	s=s110527; h=Received:Date:From:To:Cc:Subject:In-Reply-To:
	References:Content-Type:MIME-Version:Message-ID; bh=LL2ysPAzOyji
	RNgqjfMVkBHvCsjvu8rXaP0gfd0730I=; b=Y4TfBCsJf8IzyT3awb6FJQd8yB+0
	yq5yJSQ0Gj+DXYKghd9eRN0+aUoLNTBZw7+zxV1LCZbD5G+g8QoZPmXxuT3X+Ckp
	1d9+eXJDzELgLGUYMxT2XDJE15Q4I8J+sdlYS1qJ78vYZ0nRkrrx/v2cGuMuqyps
	/rccWJmLCQToX8o=
Received: from liuxiaolei1124$163.com ( [60.186.104.99] ) by
	ajax-webmail-wmsvr140 (Coremail) ; Tue, 16 Oct 2012 12:35:23 +0800 (CST)
X-Originating-IP: [60.186.104.99]
Date: Tue, 16 Oct 2012 12:35:23 +0800 (CST)
From: liuxiaolei1124  
To: "Konrad Rzeszutek Wilk" 
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	20120914(19817.4926.4909) Copyright (c) 2002-2012 www.mailtech.cn
	163com
In-Reply-To: <20121015131930.GC4000@phenom.dumpdata.com>
References: <6f0a356f.934c.13a62ccac9a.Coremail.liuxiaolei1124@163.com>
	<20121015131930.GC4000@phenom.dumpdata.com>
X-CM-CTRLDATA: Asylt2Zvb3Rlcl9odG09MTcxNjo4MQ==
MIME-Version: 1.0
Message-ID: <77e737b0.1e761.13a67dacdbc.Coremail.liuxiaolei1124@163.com>
X-CM-TRANSID: jMGowEDpo0EM5HxQnAcmAA--.391W
X-CM-SenderInfo: xolx5x5drovxarrskqqrwthudrp/1tbiDh1KgU9o0bGHtgACss
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
X-Mailman-Approved-At: Tue, 16 Oct 2012 09:57:28 +0000
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] about the patch: persistent grant maps for xen blk
	drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============6915251232989150392=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6915251232989150392==
Content-Type: multipart/alternative; 
	boundary="----=_Part_468477_806710113.1350362123708"

------=_Part_468477_806710113.1350362123708
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: 7bit










At 2012-10-15 21:19:30,"Konrad Rzeszutek Wilk"  wrote:
>On Mon, Oct 15, 2012 at 01:01:51PM +0800, liuxiaolei1124 wrote:
>> Dear konrad:
>>    i have seen you put the patch "persisten grant maps for xen blk drivers" into you kernel, then dom0 crash .(https://lkml.org/lkml/2012/9/21/388 )my dom0 kernel is 2.6.32.36-0.5, and i put this patch in my kernel, there is a bug too, and the stack is much like yours. And i found  a strange phenomenon. when i add a printk log  such as "printk ("enter func") " in blkif_completion or other function in xen-blkfront.c, guest run well. But after i remove this printk log, guest crash when i start.
>
>
>Hey. Roger posted a follow up patch that has this fixed. You should
>look at that.
sorry, but i can't find the patch Roger posted, could you show me the link of the patch? thank you.
Best wishes.
eric.liu

------=_Part_468477_806710113.1350362123708
Content-Type: text/html; charset=GBK
Content-Transfer-Encoding: 7bit















At 2012-10-15 21:19:30,"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com> wrote:
>On Mon, Oct 15, 2012 at 01:01:51PM +0800, liuxiaolei1124 wrote:
>> Dear konrad:
>>    i have seen you put the patch "persisten grant maps for xen blk drivers" into you kernel, then dom0 crash .(https://lkml.org/lkml/2012/9/21/388 )my dom0 kernel is 2.6.32.36-0.5, and i put this patch in my kernel, there is a bug too, and the stack is much like yours. And i found  a strange phenomenon. when i add a printk log  such as "printk ("enter func") " in blkif_completion or other function in xen-blkfront.c, guest run well. But after i remove this printk log, guest crash when i start.
>
>
>Hey. Roger posted a follow up patch that has this fixed. You should
>look at that.
sorry, but i can't find the patch Roger posted, could you show me the link of the patch? thank you.
Best wishes.
eric.liu




------=_Part_468477_806710113.1350362123708--



--===============6915251232989150392==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6915251232989150392==--



From xen-devel-bounces@lists.xen.org Tue Oct 16 09:58:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 09:58:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO3ty-0000T0-2a; Tue, 16 Oct 2012 09:57:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TNysW-0004P7-8q
	for xen-devel@lists.xensource.com; Tue, 16 Oct 2012 04:35:40 +0000
Received: from [85.158.137.99:61863] by server-1.bemta-3.messagelabs.com id
	B2/C3-31728-B14EC705; Tue, 16 Oct 2012 04:35:39 +0000
X-Env-Sender: liuxiaolei1124@163.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1350362127!16909508!1
X-Originating-IP: [220.181.13.140]
X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_50_60,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23918 invoked from network); 16 Oct 2012 04:35:35 -0000
Received: from m13-140.163.com (HELO m13-140.163.com) (220.181.13.140)
	by server-7.tower-217.messagelabs.com with SMTP;
	16 Oct 2012 04:35:35 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com;
	s=s110527; h=Received:Date:From:To:Cc:Subject:In-Reply-To:
	References:Content-Type:MIME-Version:Message-ID; bh=LL2ysPAzOyji
	RNgqjfMVkBHvCsjvu8rXaP0gfd0730I=; b=Y4TfBCsJf8IzyT3awb6FJQd8yB+0
	yq5yJSQ0Gj+DXYKghd9eRN0+aUoLNTBZw7+zxV1LCZbD5G+g8QoZPmXxuT3X+Ckp
	1d9+eXJDzELgLGUYMxT2XDJE15Q4I8J+sdlYS1qJ78vYZ0nRkrrx/v2cGuMuqyps
	/rccWJmLCQToX8o=
Received: from liuxiaolei1124$163.com ( [60.186.104.99] ) by
	ajax-webmail-wmsvr140 (Coremail) ; Tue, 16 Oct 2012 12:35:23 +0800 (CST)
X-Originating-IP: [60.186.104.99]
Date: Tue, 16 Oct 2012 12:35:23 +0800 (CST)
From: liuxiaolei1124  
To: "Konrad Rzeszutek Wilk" 
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	20120914(19817.4926.4909) Copyright (c) 2002-2012 www.mailtech.cn
	163com
In-Reply-To: <20121015131930.GC4000@phenom.dumpdata.com>
References: <6f0a356f.934c.13a62ccac9a.Coremail.liuxiaolei1124@163.com>
	<20121015131930.GC4000@phenom.dumpdata.com>
X-CM-CTRLDATA: Asylt2Zvb3Rlcl9odG09MTcxNjo4MQ==
MIME-Version: 1.0
Message-ID: <77e737b0.1e761.13a67dacdbc.Coremail.liuxiaolei1124@163.com>
X-CM-TRANSID: jMGowEDpo0EM5HxQnAcmAA--.391W
X-CM-SenderInfo: xolx5x5drovxarrskqqrwthudrp/1tbiDh1KgU9o0bGHtgACss
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
X-Mailman-Approved-At: Tue, 16 Oct 2012 09:57:28 +0000
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] about the patch: persistent grant maps for xen blk
	drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============6915251232989150392=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6915251232989150392==
Content-Type: multipart/alternative; 
	boundary="----=_Part_468477_806710113.1350362123708"

------=_Part_468477_806710113.1350362123708
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: 7bit










At 2012-10-15 21:19:30,"Konrad Rzeszutek Wilk"  wrote:
>On Mon, Oct 15, 2012 at 01:01:51PM +0800, liuxiaolei1124 wrote:
>> Dear konrad:
>>    i have seen you put the patch "persisten grant maps for xen blk drivers" into you kernel, then dom0 crash .(https://lkml.org/lkml/2012/9/21/388 )my dom0 kernel is 2.6.32.36-0.5, and i put this patch in my kernel, there is a bug too, and the stack is much like yours. And i found  a strange phenomenon. when i add a printk log  such as "printk ("enter func") " in blkif_completion or other function in xen-blkfront.c, guest run well. But after i remove this printk log, guest crash when i start.
>
>
>Hey. Roger posted a follow up patch that has this fixed. You should
>look at that.
sorry, but i can't find the patch Roger posted, could you show me the link of the patch? thank you.
Best wishes.
eric.liu

------=_Part_468477_806710113.1350362123708
Content-Type: text/html; charset=GBK
Content-Transfer-Encoding: 7bit















At 2012-10-15 21:19:30,"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com> wrote:
>On Mon, Oct 15, 2012 at 01:01:51PM +0800, liuxiaolei1124 wrote:
>> Dear konrad:
>>    i have seen you put the patch "persisten grant maps for xen blk drivers" into you kernel, then dom0 crash .(https://lkml.org/lkml/2012/9/21/388 )my dom0 kernel is 2.6.32.36-0.5, and i put this patch in my kernel, there is a bug too, and the stack is much like yours. And i found  a strange phenomenon. when i add a printk log  such as "printk ("enter func") " in blkif_completion or other function in xen-blkfront.c, guest run well. But after i remove this printk log, guest crash when i start.
>
>
>Hey. Roger posted a follow up patch that has this fixed. You should
>look at that.
sorry, but i can't find the patch Roger posted, could you show me the link of the patch? thank you.
Best wishes.
eric.liu




------=_Part_468477_806710113.1350362123708--



--===============6915251232989150392==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6915251232989150392==--



From xen-devel-bounces@lists.xen.org Tue Oct 16 10:08:20 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 10:08:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO43k-0000i8-7Y; Tue, 16 Oct 2012 10:07:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO43i-0000i3-K7
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 10:07:34 +0000
Received: from [193.109.254.147:25626] by server-13.bemta-14.messagelabs.com
	id 72/BE-21440-5E13D705; Tue, 16 Oct 2012 10:07:33 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-5.tower-27.messagelabs.com!1350382014!8746231!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15135 invoked from network); 16 Oct 2012 10:06:55 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-5.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	16 Oct 2012 10:06:55 -0000
Received: from 50-66-ftth.onsneteindhoven.nl ([88.159.66.50]:50081
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TO44f-0003LZ-JN; Tue, 16 Oct 2012 12:08:33 +0200
Date: Tue, 16 Oct 2012 12:06:50 +0200
From: Sander Eikelenboom 
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1911892756.20121016120650@eikelenboom.it>
To: Ian Campbell 
In-Reply-To: <1350380600.18058.109.camel@zakaz.uk.xensource.com>
References: 
	<692244188.20121015123235@eikelenboom.it>
	<1350297477.18058.27.camel@zakaz.uk.xensource.com>
	<751865457.20121015132140@eikelenboom.it>
	<1350301533.18058.35.camel@zakaz.uk.xensource.com>
	<1612556249.20121016105907@eikelenboom.it>
	<1350380600.18058.109.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl shutdown compatibility with xm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Tuesday, October 16, 2012, 11:43:20 AM, you wrote:

> On Tue, 2012-10-16 at 09:59 +0100, Sander Eikelenboom wrote:
>> Monday, October 15, 2012, 1:45:33 PM, you wrote:
>> 
>> > On Mon, 2012-10-15 at 12:21 +0100, Sander Eikelenboom wrote:
>> >> Monday, October 15, 2012, 12:37:57 PM, you wrote:
>> >> 
>> >> > On Mon, 2012-10-15 at 11:32 +0100, Sander Eikelenboom wrote:
>> >> >> Hi Ian,
>> >> >> 
>> >> >> Great thanks !
>> >> >> Only thing i was wondering about:
>> >> >> 
>> >> >> Shouldn't the "-F" option be dropped in favour of always trying the
>> >> >> "acpi fallback" when the pv shutdown fails.
>> >> >> 
>> >> >> This because the shutdown scripts still don't work for domains without
>> >> >> pv shutdown and i don't see a down side to just trying that as
>> >> >> fallback.
>> >> 
>> >> > It is guess OS dependent what the ACPI button press event does, it can
>> >> > reboot, shutdown or hibernate etc depending on the OS type and its
>> >> > configuration. (in theory I suppose it is completely arbitrary e.g. it
>> >> > could be configured to eject the CD-ROM or something equally random).
>> >> 
>> >> > Therefore the user needs to be aware of when they can safely use it.
>> >> 
>> >> Well yes and no:
>> >>     - can't remember having (to make) that choice with xm ?
>> 
>> > Looks like xend uses SCHEDOP_remote_shutdown. It's unclear to me why
>> > this is better than just shooting the domain with destroy...
>> 
>> >>     - On shutdown with xl as toolstack and when the guest doesn't
>> >> support pv shutdown, the init.d/xendomains script doesn't even attempt
>> >> to shutdown this guest by acpi fallback.
>> >>     - As a result when using xl as toolstack, the guest is terminated
>> >> non gracefully when the whole machine finally shutsdown, which seems
>> >> less desirable then at least *trying* to shut it down gracefully by
>> >> using the acpi button.
>> 
>> > Using the ACPI fallback is a decision which can only be made locally
>> > with full knowledge of the configuration of the guests.
>> 
>> I'm not totally convinced (yet):
>>   - In case of a system shutdown, it seems better to at least *try* instead of just halting the system without shutting such a guest down.

> You might as well do xl shutdown, wait a bit, xl destroy in the
> initscript. "xm shutdown" is effectively "xm destroy" for guests without
> PV drivers.

>>       For the shutdown scripts the problems is that there is no way to give it the "full knowledge" of how to shutdown a particular guest.
>>       It would be possible to use the -F flag in the sysconfig xendomains file, since the pv shutdown is always tried first.

> It would be possible for an individual administrator to add -F if that
> is compatible with their configuration. It would be inappropriate for
> upstream to do this by default because we *don't know* what -F does to
> an arbitrary guest.

It's just that i think upstream should use sensible defaults that work in the majority of cases (unless it will have a devastating effect in de minority of cases).
In this case both hvm guests with fairly old windows and linux install seem to respond correctly to the acpi powerbutton, so perhaps the majority of cases.
In the minority of cases it will perhaps do something else, but could/will that really be more devastating than the pulling the rug from under a guests feet when the machine powers down without the guest being shutdown ?

But any how, since it's not acceptable to upstream i will keep it in my private scripts and shut up :-)


>>   - Not everyone seems to be aware, say an IanJ ;-)
>>       Under the assumption that the guests in the xen-test-harness do react in the right way to a acpi powerbutton event,
>>       it seems the "never passes" in  "Guest-stop" row of http://www.chiark.greenend.org.uk/~xensrcts/logs/13967/
>>       Will probably pass when the -F option will be used, see http://www.chiark.greenend.org.uk/~xensrcts/logs/13967/test-amd64-i386-xl-win7-amd64/13.ts-guest-stop.log

> Ian J is well aware that -F could help here (this is the main reason I
> implemented this option). It would be appropriate here because we can
> control the guest OS configuration in the harness (and if we can't we
> shouldn't use -F).

> He just hasn't implemented it in the harness yet (TBH I suspect he has
> forgotten ;-)).

> Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 10:08:20 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 10:08:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO43k-0000i8-7Y; Tue, 16 Oct 2012 10:07:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO43i-0000i3-K7
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 10:07:34 +0000
Received: from [193.109.254.147:25626] by server-13.bemta-14.messagelabs.com
	id 72/BE-21440-5E13D705; Tue, 16 Oct 2012 10:07:33 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-5.tower-27.messagelabs.com!1350382014!8746231!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15135 invoked from network); 16 Oct 2012 10:06:55 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-5.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	16 Oct 2012 10:06:55 -0000
Received: from 50-66-ftth.onsneteindhoven.nl ([88.159.66.50]:50081
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TO44f-0003LZ-JN; Tue, 16 Oct 2012 12:08:33 +0200
Date: Tue, 16 Oct 2012 12:06:50 +0200
From: Sander Eikelenboom 
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1911892756.20121016120650@eikelenboom.it>
To: Ian Campbell 
In-Reply-To: <1350380600.18058.109.camel@zakaz.uk.xensource.com>
References: 
	<692244188.20121015123235@eikelenboom.it>
	<1350297477.18058.27.camel@zakaz.uk.xensource.com>
	<751865457.20121015132140@eikelenboom.it>
	<1350301533.18058.35.camel@zakaz.uk.xensource.com>
	<1612556249.20121016105907@eikelenboom.it>
	<1350380600.18058.109.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl shutdown compatibility with xm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Tuesday, October 16, 2012, 11:43:20 AM, you wrote:

> On Tue, 2012-10-16 at 09:59 +0100, Sander Eikelenboom wrote:
>> Monday, October 15, 2012, 1:45:33 PM, you wrote:
>> 
>> > On Mon, 2012-10-15 at 12:21 +0100, Sander Eikelenboom wrote:
>> >> Monday, October 15, 2012, 12:37:57 PM, you wrote:
>> >> 
>> >> > On Mon, 2012-10-15 at 11:32 +0100, Sander Eikelenboom wrote:
>> >> >> Hi Ian,
>> >> >> 
>> >> >> Great thanks !
>> >> >> Only thing i was wondering about:
>> >> >> 
>> >> >> Shouldn't the "-F" option be dropped in favour of always trying the
>> >> >> "acpi fallback" when the pv shutdown fails.
>> >> >> 
>> >> >> This because the shutdown scripts still don't work for domains without
>> >> >> pv shutdown and i don't see a down side to just trying that as
>> >> >> fallback.
>> >> 
>> >> > It is guess OS dependent what the ACPI button press event does, it can
>> >> > reboot, shutdown or hibernate etc depending on the OS type and its
>> >> > configuration. (in theory I suppose it is completely arbitrary e.g. it
>> >> > could be configured to eject the CD-ROM or something equally random).
>> >> 
>> >> > Therefore the user needs to be aware of when they can safely use it.
>> >> 
>> >> Well yes and no:
>> >>     - can't remember having (to make) that choice with xm ?
>> 
>> > Looks like xend uses SCHEDOP_remote_shutdown. It's unclear to me why
>> > this is better than just shooting the domain with destroy...
>> 
>> >>     - On shutdown with xl as toolstack and when the guest doesn't
>> >> support pv shutdown, the init.d/xendomains script doesn't even attempt
>> >> to shutdown this guest by acpi fallback.
>> >>     - As a result when using xl as toolstack, the guest is terminated
>> >> non gracefully when the whole machine finally shutsdown, which seems
>> >> less desirable then at least *trying* to shut it down gracefully by
>> >> using the acpi button.
>> 
>> > Using the ACPI fallback is a decision which can only be made locally
>> > with full knowledge of the configuration of the guests.
>> 
>> I'm not totally convinced (yet):
>>   - In case of a system shutdown, it seems better to at least *try* instead of just halting the system without shutting such a guest down.

> You might as well do xl shutdown, wait a bit, xl destroy in the
> initscript. "xm shutdown" is effectively "xm destroy" for guests without
> PV drivers.

>>       For the shutdown scripts the problems is that there is no way to give it the "full knowledge" of how to shutdown a particular guest.
>>       It would be possible to use the -F flag in the sysconfig xendomains file, since the pv shutdown is always tried first.

> It would be possible for an individual administrator to add -F if that
> is compatible with their configuration. It would be inappropriate for
> upstream to do this by default because we *don't know* what -F does to
> an arbitrary guest.

It's just that i think upstream should use sensible defaults that work in the majority of cases (unless it will have a devastating effect in de minority of cases).
In this case both hvm guests with fairly old windows and linux install seem to respond correctly to the acpi powerbutton, so perhaps the majority of cases.
In the minority of cases it will perhaps do something else, but could/will that really be more devastating than the pulling the rug from under a guests feet when the machine powers down without the guest being shutdown ?

But any how, since it's not acceptable to upstream i will keep it in my private scripts and shut up :-)


>>   - Not everyone seems to be aware, say an IanJ ;-)
>>       Under the assumption that the guests in the xen-test-harness do react in the right way to a acpi powerbutton event,
>>       it seems the "never passes" in  "Guest-stop" row of http://www.chiark.greenend.org.uk/~xensrcts/logs/13967/
>>       Will probably pass when the -F option will be used, see http://www.chiark.greenend.org.uk/~xensrcts/logs/13967/test-amd64-i386-xl-win7-amd64/13.ts-guest-stop.log

> Ian J is well aware that -F could help here (this is the main reason I
> implemented this option). It would be appropriate here because we can
> control the guest OS configuration in the harness (and if we can't we
> shouldn't use -F).

> He just hasn't implemented it in the harness yet (TBH I suspect he has
> forgotten ;-)).

> Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 10:35:34 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 10:35:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO4U3-0000y6-PN; Tue, 16 Oct 2012 10:34:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO4U1-0000xv-Ps
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 10:34:45 +0000
Received: from [85.158.143.35:53829] by server-1.bemta-4.messagelabs.com id
	A2/D9-19134-5483D705; Tue, 16 Oct 2012 10:34:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1350383684!6818453!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQzMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17255 invoked from network); 16 Oct 2012 10:34:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 10:34:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,593,1344211200"; d="scan'208";a="15199243"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Oct 2012 10:34:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 16 Oct 2012 11:34:42 +0100
Message-ID: <1350383681.18058.113.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Bart Van Assche 
Date: Tue, 16 Oct 2012 11:34:41 +0100
In-Reply-To: <507C5227.7020404@acm.org>
References: <1349696046.18008.116.camel@zakaz.uk.xensource.com>
	<1349696067-4273-1-git-send-email-ian.campbell@citrix.com>
	<201210111836.53184.jseward@acm.org>
	<1350296250.18058.18.camel@zakaz.uk.xensource.com>
	<507C5227.7020404@acm.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "valgrind-developers@lists.sourceforge.net"
	,
	Julian Seward , xen-devel 
Subject: Re: [Xen-devel] [Valgrind-developers] [PATCH 1/4] Useful messages
 for sys/domctl interface_version mismatch.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-10-15 at 19:12 +0100, Bart Van Assche wrote:
> On 10/15/12 12:17, Ian Campbell wrote:
> > On Thu, 2012-10-11 at 17:36 +0100, Julian Seward wrote:
> >> Please: file a bug report and attach the patches to it.  Else they
> >> are pretty much guaranteed to wind up at /dev/null, because nobody
> >> tracks patches on the list AFAIK.
> >
> > Bart indicated that he intended to apply these.
> >
> > I'll attach patches to a bug in the future though, thanks for the tip.
> >
> > I'll do it for these too if Bart wants me to.
> 
> I'll pick the patches from the mailing list this time.

Thanks.

>  But next time 
> please file a bug report. As you might have noticed Julian uses the 
> bugzilla ticket numbers to track issues in the NEWS file, and also to 
> keep track of which issues have been fixed in which branch.

I hadn't noticed this, but I have now ;-)

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 10:35:34 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 10:35:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO4U3-0000y6-PN; Tue, 16 Oct 2012 10:34:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO4U1-0000xv-Ps
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 10:34:45 +0000
Received: from [85.158.143.35:53829] by server-1.bemta-4.messagelabs.com id
	A2/D9-19134-5483D705; Tue, 16 Oct 2012 10:34:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1350383684!6818453!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQzMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17255 invoked from network); 16 Oct 2012 10:34:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 10:34:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,593,1344211200"; d="scan'208";a="15199243"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Oct 2012 10:34:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 16 Oct 2012 11:34:42 +0100
Message-ID: <1350383681.18058.113.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Bart Van Assche 
Date: Tue, 16 Oct 2012 11:34:41 +0100
In-Reply-To: <507C5227.7020404@acm.org>
References: <1349696046.18008.116.camel@zakaz.uk.xensource.com>
	<1349696067-4273-1-git-send-email-ian.campbell@citrix.com>
	<201210111836.53184.jseward@acm.org>
	<1350296250.18058.18.camel@zakaz.uk.xensource.com>
	<507C5227.7020404@acm.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "valgrind-developers@lists.sourceforge.net"
	,
	Julian Seward , xen-devel 
Subject: Re: [Xen-devel] [Valgrind-developers] [PATCH 1/4] Useful messages
 for sys/domctl interface_version mismatch.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-10-15 at 19:12 +0100, Bart Van Assche wrote:
> On 10/15/12 12:17, Ian Campbell wrote:
> > On Thu, 2012-10-11 at 17:36 +0100, Julian Seward wrote:
> >> Please: file a bug report and attach the patches to it.  Else they
> >> are pretty much guaranteed to wind up at /dev/null, because nobody
> >> tracks patches on the list AFAIK.
> >
> > Bart indicated that he intended to apply these.
> >
> > I'll attach patches to a bug in the future though, thanks for the tip.
> >
> > I'll do it for these too if Bart wants me to.
> 
> I'll pick the patches from the mailing list this time.

Thanks.

>  But next time 
> please file a bug report. As you might have noticed Julian uses the 
> bugzilla ticket numbers to track issues in the NEWS file, and also to 
> keep track of which issues have been fixed in which branch.

I hadn't noticed this, but I have now ;-)

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 10:37:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 10:37:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO4Vx-00013e-9e; Tue, 16 Oct 2012 10:36:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO4Vw-00013Y-L0
	for xen-devel@lists.xensource.com; Tue, 16 Oct 2012 10:36:44 +0000
Received: from [85.158.139.83:14434] by server-3.bemta-5.messagelabs.com id
	0D/54-28618-BB83D705; Tue, 16 Oct 2012 10:36:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1350383802!32220565!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQzMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28966 invoked from network); 16 Oct 2012 10:36:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 10:36:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,593,1344211200"; d="scan'208";a="15199297"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Oct 2012 10:36:42 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 16 Oct 2012 11:36:42 +0100
Message-ID: <1350383800.18058.114.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Tue, 16 Oct 2012 11:36:40 +0100
In-Reply-To: 
References: 
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	Keir Fraser , "Tim Deegan \(3P\)" 
Subject: Re: [Xen-devel] [PATCH v3 0/6] ARM hypercall ABI: 64 bit ready
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-08-16 at 15:48 +0100, Stefano Stabellini wrote:
> In this version of the patch series I have introduced conversion macros
> to convert a XEN_GUEST_HANDLE_PARAM into a XEN_GUEST_HANDLE a vice
> versa. Most of the problematic cases come from xen/arch/x86 code, in
> order to spot them I wrote a simple debug patch that change the
> definition of XEN_GUEST_HANDLE_PARAM to be different from
> XEN_GUEST_HANDLE on x86 too. I am attaching the debug patch to this
> email. 

This (quoted below) seems like a useful patch from the PoV of catching
these sorts of things early on x86 before they break ARM.

It doesn't seem like it should have any impact on the generated code,
should we perhaps apply it?

I needed the addition of the following to actually make it work though.

diff --git a/xen/include/asm-x86/guest_access.h b/xen/include/asm-x86/guest_acce
index ca700c9..33b4afd 100644
--- a/xen/include/asm-x86/guest_access.h
+++ b/xen/include/asm-x86/guest_access.h
@@ -54,22 +54,24 @@
 
 /* Cast a XEN_GUEST_HANDLE to XEN_GUEST_HANDLE_PARAM */
 #define guest_handle_to_param(hnd, type) ({                  \
+    typeof((hnd).p) _x = (hnd).p;                            \
+    XEN_GUEST_HANDLE_PARAM(type) _y = { _x };                \
     /* type checking: make sure that the pointers inside     \
      * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of    \
      * the same type, then return hnd */                     \
-    (void)((typeof(&(hnd).p)) 0 ==                           \
-        (typeof(&((XEN_GUEST_HANDLE_PARAM(type)) {}).p)) 0); \
-    (hnd);                                                   \
+    (void)(&_x == &_y.p);                                    \
+    _y;                                                      \
 })
 
 /* Cast a XEN_GUEST_HANDLE_PARAM to XEN_GUEST_HANDLE */
-#define guest_handle_from_param(hnd, type) ({                \
-    /* type checking: make sure that the pointers inside     \
-     * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of    \
-     * the same type, then return hnd */                     \
-    (void)((typeof(&(hnd).p)) 0 ==                           \
-        (typeof(&((XEN_GUEST_HANDLE_PARAM(type)) {}).p)) 0); \
-    (hnd);                                                   \
+#define guest_handle_from_param(hnd, type) ({               \
+    typeof((hnd).p) _x = (hnd).p;                           \
+    XEN_GUEST_HANDLE(type) _y = { _x };                     \
+    /* type checking: make sure that the pointers inside    \
+     * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of   \
+     * the same type, then return hnd */                    \
+    (void)(&_x == &_y.p);                                   \
+    _y;                                                     \
 })
 
 #define guest_handle_for_field(hnd, type, fld)          \


> diff --git a/xen/include/public/arch-x86/xen.h b/xen/include/public/arch-x86/xen.h
> index 0e10260..08a788e 100644
> --- a/xen/include/public/arch-x86/xen.h
> +++ b/xen/include/public/arch-x86/xen.h
> @@ -32,7 +32,8 @@
>  /* Structural guest handles introduced in 0x00030201. */
>  #if __XEN_INTERFACE_VERSION__ >= 0x00030201
>  #define ___DEFINE_XEN_GUEST_HANDLE(name, type) \
> -    typedef struct { type *p; } __guest_handle_ ## name
> +    typedef struct { type *p; } __guest_handle_ ## name; \
> +    typedef struct { type *p; } __guest_handle_param_ ## name
>  #else
>  #define ___DEFINE_XEN_GUEST_HANDLE(name, type) \
>      typedef type * __guest_handle_ ## name
> @@ -52,7 +53,7 @@
>  #define DEFINE_XEN_GUEST_HANDLE(name)   __DEFINE_XEN_GUEST_HANDLE(name, name)
>  #define __XEN_GUEST_HANDLE(name)        __guest_handle_ ## name
>  #define XEN_GUEST_HANDLE(name)          __XEN_GUEST_HANDLE(name)
> -#define XEN_GUEST_HANDLE_PARAM(name)    XEN_GUEST_HANDLE(name)
> +#define XEN_GUEST_HANDLE_PARAM(name)    __guest_handle_param_ ## name
>  #define set_xen_guest_handle_raw(hnd, val)  do { (hnd).p = val; } while (0)
>  #ifdef __XEN_TOOLS__
>  #define get_xen_guest_handle(val, hnd)  do { val = (hnd).p; } while (0)
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 10:37:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 10:37:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO4Vx-00013e-9e; Tue, 16 Oct 2012 10:36:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO4Vw-00013Y-L0
	for xen-devel@lists.xensource.com; Tue, 16 Oct 2012 10:36:44 +0000
Received: from [85.158.139.83:14434] by server-3.bemta-5.messagelabs.com id
	0D/54-28618-BB83D705; Tue, 16 Oct 2012 10:36:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1350383802!32220565!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQzMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28966 invoked from network); 16 Oct 2012 10:36:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 10:36:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,593,1344211200"; d="scan'208";a="15199297"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Oct 2012 10:36:42 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 16 Oct 2012 11:36:42 +0100
Message-ID: <1350383800.18058.114.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Tue, 16 Oct 2012 11:36:40 +0100
In-Reply-To: 
References: 
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	Keir Fraser , "Tim Deegan \(3P\)" 
Subject: Re: [Xen-devel] [PATCH v3 0/6] ARM hypercall ABI: 64 bit ready
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-08-16 at 15:48 +0100, Stefano Stabellini wrote:
> In this version of the patch series I have introduced conversion macros
> to convert a XEN_GUEST_HANDLE_PARAM into a XEN_GUEST_HANDLE a vice
> versa. Most of the problematic cases come from xen/arch/x86 code, in
> order to spot them I wrote a simple debug patch that change the
> definition of XEN_GUEST_HANDLE_PARAM to be different from
> XEN_GUEST_HANDLE on x86 too. I am attaching the debug patch to this
> email. 

This (quoted below) seems like a useful patch from the PoV of catching
these sorts of things early on x86 before they break ARM.

It doesn't seem like it should have any impact on the generated code,
should we perhaps apply it?

I needed the addition of the following to actually make it work though.

diff --git a/xen/include/asm-x86/guest_access.h b/xen/include/asm-x86/guest_acce
index ca700c9..33b4afd 100644
--- a/xen/include/asm-x86/guest_access.h
+++ b/xen/include/asm-x86/guest_access.h
@@ -54,22 +54,24 @@
 
 /* Cast a XEN_GUEST_HANDLE to XEN_GUEST_HANDLE_PARAM */
 #define guest_handle_to_param(hnd, type) ({                  \
+    typeof((hnd).p) _x = (hnd).p;                            \
+    XEN_GUEST_HANDLE_PARAM(type) _y = { _x };                \
     /* type checking: make sure that the pointers inside     \
      * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of    \
      * the same type, then return hnd */                     \
-    (void)((typeof(&(hnd).p)) 0 ==                           \
-        (typeof(&((XEN_GUEST_HANDLE_PARAM(type)) {}).p)) 0); \
-    (hnd);                                                   \
+    (void)(&_x == &_y.p);                                    \
+    _y;                                                      \
 })
 
 /* Cast a XEN_GUEST_HANDLE_PARAM to XEN_GUEST_HANDLE */
-#define guest_handle_from_param(hnd, type) ({                \
-    /* type checking: make sure that the pointers inside     \
-     * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of    \
-     * the same type, then return hnd */                     \
-    (void)((typeof(&(hnd).p)) 0 ==                           \
-        (typeof(&((XEN_GUEST_HANDLE_PARAM(type)) {}).p)) 0); \
-    (hnd);                                                   \
+#define guest_handle_from_param(hnd, type) ({               \
+    typeof((hnd).p) _x = (hnd).p;                           \
+    XEN_GUEST_HANDLE(type) _y = { _x };                     \
+    /* type checking: make sure that the pointers inside    \
+     * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of   \
+     * the same type, then return hnd */                    \
+    (void)(&_x == &_y.p);                                   \
+    _y;                                                     \
 })
 
 #define guest_handle_for_field(hnd, type, fld)          \


> diff --git a/xen/include/public/arch-x86/xen.h b/xen/include/public/arch-x86/xen.h
> index 0e10260..08a788e 100644
> --- a/xen/include/public/arch-x86/xen.h
> +++ b/xen/include/public/arch-x86/xen.h
> @@ -32,7 +32,8 @@
>  /* Structural guest handles introduced in 0x00030201. */
>  #if __XEN_INTERFACE_VERSION__ >= 0x00030201
>  #define ___DEFINE_XEN_GUEST_HANDLE(name, type) \
> -    typedef struct { type *p; } __guest_handle_ ## name
> +    typedef struct { type *p; } __guest_handle_ ## name; \
> +    typedef struct { type *p; } __guest_handle_param_ ## name
>  #else
>  #define ___DEFINE_XEN_GUEST_HANDLE(name, type) \
>      typedef type * __guest_handle_ ## name
> @@ -52,7 +53,7 @@
>  #define DEFINE_XEN_GUEST_HANDLE(name)   __DEFINE_XEN_GUEST_HANDLE(name, name)
>  #define __XEN_GUEST_HANDLE(name)        __guest_handle_ ## name
>  #define XEN_GUEST_HANDLE(name)          __XEN_GUEST_HANDLE(name)
> -#define XEN_GUEST_HANDLE_PARAM(name)    XEN_GUEST_HANDLE(name)
> +#define XEN_GUEST_HANDLE_PARAM(name)    __guest_handle_param_ ## name
>  #define set_xen_guest_handle_raw(hnd, val)  do { (hnd).p = val; } while (0)
>  #ifdef __XEN_TOOLS__
>  #define get_xen_guest_handle(val, hnd)  do { val = (hnd).p; } while (0)
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 10:43:26 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 10:43:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO4bl-0001Gg-8q; Tue, 16 Oct 2012 10:42:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO4bk-0001Ga-75
	for xen-devel@lists.xensource.com; Tue, 16 Oct 2012 10:42:44 +0000
Received: from [85.158.139.83:12707] by server-5.bemta-5.messagelabs.com id
	62/D1-09732-32A3D705; Tue, 16 Oct 2012 10:42:43 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1350384160!32221548!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjE5MzA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16795 invoked from network); 16 Oct 2012 10:42:41 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-2.tower-182.messagelabs.com with SMTP;
	16 Oct 2012 10:42:41 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 16 Oct 2012 03:42:38 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,593,1344236400"; d="scan'208";a="156690735"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by AZSMGA002.ch.intel.com with ESMTP; 16 Oct 2012 03:42:38 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 16 Oct 2012 03:42:38 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.162]) with mapi id
	14.01.0355.002; Tue, 16 Oct 2012 18:42:36 +0800
From: "Liu, Jinsong" 
To: Ian Jackson , Ian Campbell
	, "xen-devel@lists.xensource.com"
	
Thread-Topic: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration when
	vMCE	occur
Thread-Index: Ac2m9gA+ufJylTqUQruxPOzNlQzaHQElHhYg
Date: Tue, 16 Oct 2012 10:42:35 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Christoph Egger ,
	"Keir \(Xen.org\)" , Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration when
	vMCE	occur
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, Campbell, Jackson

Any more comments?

Thanks,
Jinsong

Liu, Jinsong wrote:
> Xen/MCE: Abort live migration when vMCE occur
> 
> This patch monitor the critical area of live migration (from vMCE
> point of view, 
> the copypages stage of migration is the critical area while other
> areas are not). 
> 
> If a vMCE occur at the critical area of live migration, there is risk
> that error 
> data may be copied to the target. Currently we don't have convenient
> way to handle 
> this case, so for the sake of safe, we abort it and try migration
> later (at that 
> time broken page would not be mapped and copied to the target).
> 
> Signed-off-by: Liu, Jinsong 
> 
> diff -r e27a6d53ac15 tools/libxc/xc_domain.c
> --- a/tools/libxc/xc_domain.c	Thu Oct 11 01:52:33 2012 +0800
> +++ b/tools/libxc/xc_domain.c	Thu Oct 11 05:12:48 2012 +0800
> @@ -283,6 +283,30 @@
>      return ret;
>  }
> 
> +/* Start vmce monitor */
> +int xc_domain_vmce_monitor_start(xc_interface *xch,
> +                                 uint32_t domid)
> +{
> +    DECLARE_DOMCTL;
> +
> +    domctl.cmd = XEN_DOMCTL_vmce_monitor_start;
> +    domctl.domain = (domid_t)domid;
> +
> +    return do_domctl(xch, &domctl);
> +}
> +
> +/* End vmce monitor */
> +int xc_domain_vmce_monitor_end(xc_interface *xch,
> +                               uint32_t domid)
> +{
> +    DECLARE_DOMCTL;
> +
> +    domctl.cmd = XEN_DOMCTL_vmce_monitor_end;
> +    domctl.domain = (domid_t)domid;
> +
> +    return do_domctl(xch, &domctl);
> +}
> +
>  /* get info from hvm guest for save */
>  int xc_domain_hvm_getcontext(xc_interface *xch,
>                               uint32_t domid,
> diff -r e27a6d53ac15 tools/libxc/xc_domain_save.c
> --- a/tools/libxc/xc_domain_save.c	Thu Oct 11 01:52:33 2012 +0800
> +++ b/tools/libxc/xc_domain_save.c	Thu Oct 11 05:12:48 2012 +0800
> @@ -895,6 +895,8 @@
>       */
>      int compressing = 0;
> 
> +    int vmce_while_monitor = 0;
> +
>      int completed = 0;
> 
>      if ( hvm && !callbacks->switch_qemu_logdirty )
> @@ -1109,6 +1111,12 @@
>          goto out;
>      }
> 
> +    if ( xc_domain_vmce_monitor_start(xch, dom) )
> +    {
> +        PERROR("Error when start vmce monitor\n");
> +        goto out;
> +    }
> +
>    copypages:
>  #define wrexact(fd, buf, len) write_buffer(xch, last_iter, ob, (fd),
>  (buf), (len)) #define wruncached(fd, live, buf, len)
> write_uncached(xch, last_iter, ob, (fd), (buf), (len)) @@ -1571,6
> +1579,18 @@ 
> 
>      DPRINTF("All memory is saved\n");
> 
> +    vmce_while_monitor = xc_domain_vmce_monitor_end(xch, dom);
> +    if ( vmce_while_monitor < 0 )
> +    {
> +        PERROR("Error when end vmce monitor\n");
> +        goto out;
> +    }
> +    else if ( vmce_while_monitor > 0 )
> +    {
> +        fprintf(stderr, "vMCE occurred, abort this time and try
> later.\n"); +        goto out;
> +    }
> +
>      /* After last_iter, buffer the rest of pagebuf & tailbuf data
> into a 
>       * separate output buffer and flush it after the compressed page
>       chunks. */
> diff -r e27a6d53ac15 tools/libxc/xenctrl.h
> --- a/tools/libxc/xenctrl.h	Thu Oct 11 01:52:33 2012 +0800
> +++ b/tools/libxc/xenctrl.h	Thu Oct 11 05:12:48 2012 +0800
> @@ -575,6 +575,26 @@
>                            xc_domaininfo_t *info);
> 
>  /**
> + * This function start monitor vmce event.
> + * @parm xch a handle to an open hypervisor interface
> + * @parm domid the domain id monitored
> + * @return <0 on failure, 0 on success
> + */
> +int xc_domain_vmce_monitor_start(xc_interface *xch,
> +                                 uint32_t domid);
> +
> +/**
> + * This function end monitor vmce event
> + * @parm xch a handle to an open hypervisor interface
> + * @parm domid the domain id monitored
> + * @return < 0 on failure, >= 0 on success while
> + *   = 0 on no vmce occurred
> + *   > 0 on vmce occurred
> + */
> +int xc_domain_vmce_monitor_end(xc_interface *xch,
> +                               uint32_t domid);
> +
> +/**
>   * This function returns information about the context of a hvm
> domain 
>   * @parm xch a handle to an open hypervisor interface
>   * @parm domid the domain to get information from
> diff -r e27a6d53ac15 xen/arch/x86/cpu/mcheck/mce_intel.c
> --- a/xen/arch/x86/cpu/mcheck/mce_intel.c	Thu Oct 11 01:52:33 2012
> +0800 +++ b/xen/arch/x86/cpu/mcheck/mce_intel.c	Thu Oct 11 05:12:48
> 2012 +0800 @@ -359,6 +359,12 @@
>                      goto vmce_failed;
>                  }
> 
> +                if ( unlikely(d->arch.vmce_monitor) )
> +                {
> +                    /* vMCE occur when guest migration */
> +                    d->arch.vmce_monitor = 1;
> +                }
> +
>                  /* We will inject vMCE to DOMU*/
>                  if ( inject_vmce(d, VMCE_INJECT_BROADCAST) < 0 )
>                  {
> diff -r e27a6d53ac15 xen/arch/x86/domctl.c
> --- a/xen/arch/x86/domctl.c	Thu Oct 11 01:52:33 2012 +0800
> +++ b/xen/arch/x86/domctl.c	Thu Oct 11 05:12:48 2012 +0800
> @@ -1568,6 +1568,47 @@
>      }
>      break;
> 
> +    case XEN_DOMCTL_vmce_monitor_start:
> +    {
> +        struct domain *d;
> +
> +        d = rcu_lock_domain_by_id(domctl->domain);
> +        if ( d != NULL )
> +        {
> +            if ( d->arch.vmce_monitor )
> +                ret = -EBUSY;
> +            else
> +                d->arch.vmce_monitor = -1;
> +
> +            rcu_unlock_domain(d);
> +        }
> +        else
> +            ret = -ESRCH;
> +    }
> +    break;
> +
> +    case XEN_DOMCTL_vmce_monitor_end:
> +    {
> +        struct domain *d;
> +
> +        d = rcu_lock_domain_by_id(domctl->domain);
> +        if ( d != NULL)
> +        {
> +            if ( !d->arch.vmce_monitor )
> +                ret = -EINVAL;
> +            else
> +            {
> +                ret = d->arch.vmce_monitor > 0 ? 1 : 0;
> +                d->arch.vmce_monitor = 0;
> +            }
> +
> +            rcu_unlock_domain(d);
> +        }
> +        else
> +            ret = -ESRCH;
> +    }
> +    break;
> +
>      default:
>          ret = iommu_do_domctl(domctl, u_domctl);
>          break;
> diff -r e27a6d53ac15 xen/include/asm-x86/domain.h
> --- a/xen/include/asm-x86/domain.h	Thu Oct 11 01:52:33 2012 +0800
> +++ b/xen/include/asm-x86/domain.h	Thu Oct 11 05:12:48 2012 +0800
> @@ -279,6 +279,11 @@
>      bool_t has_32bit_shinfo;
>      /* Domain cannot handle spurious page faults? */
>      bool_t suppress_spurious_page_faults;
> +    /* Monitoring guest memory copy of migration
> +     * = 0 - not monitoring
> +     * < 0 - monitoring
> +     * > 0 - vMCE occurred while monitoring */
> +    s8 vmce_monitor;
> 
>      /* Continuable domain_relinquish_resources(). */
>      enum {
> diff -r e27a6d53ac15 xen/include/public/domctl.h
> --- a/xen/include/public/domctl.h	Thu Oct 11 01:52:33 2012 +0800
> +++ b/xen/include/public/domctl.h	Thu Oct 11 05:12:48 2012 +0800
> @@ -900,6 +900,8 @@
>  #define XEN_DOMCTL_set_access_required           64
>  #define XEN_DOMCTL_audit_p2m                     65
>  #define XEN_DOMCTL_set_virq_handler              66
> +#define XEN_DOMCTL_vmce_monitor_start            67
> +#define XEN_DOMCTL_vmce_monitor_end              68
>  #define XEN_DOMCTL_gdbsx_guestmemio            1000
>  #define XEN_DOMCTL_gdbsx_pausevcpu             1001
>  #define XEN_DOMCTL_gdbsx_unpausevcpu           1002


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 10:43:26 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 10:43:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO4bl-0001Gg-8q; Tue, 16 Oct 2012 10:42:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO4bk-0001Ga-75
	for xen-devel@lists.xensource.com; Tue, 16 Oct 2012 10:42:44 +0000
Received: from [85.158.139.83:12707] by server-5.bemta-5.messagelabs.com id
	62/D1-09732-32A3D705; Tue, 16 Oct 2012 10:42:43 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1350384160!32221548!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjE5MzA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16795 invoked from network); 16 Oct 2012 10:42:41 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-2.tower-182.messagelabs.com with SMTP;
	16 Oct 2012 10:42:41 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 16 Oct 2012 03:42:38 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,593,1344236400"; d="scan'208";a="156690735"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by AZSMGA002.ch.intel.com with ESMTP; 16 Oct 2012 03:42:38 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 16 Oct 2012 03:42:38 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.162]) with mapi id
	14.01.0355.002; Tue, 16 Oct 2012 18:42:36 +0800
From: "Liu, Jinsong" 
To: Ian Jackson , Ian Campbell
	, "xen-devel@lists.xensource.com"
	
Thread-Topic: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration when
	vMCE	occur
Thread-Index: Ac2m9gA+ufJylTqUQruxPOzNlQzaHQElHhYg
Date: Tue, 16 Oct 2012 10:42:35 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Christoph Egger ,
	"Keir \(Xen.org\)" , Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration when
	vMCE	occur
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, Campbell, Jackson

Any more comments?

Thanks,
Jinsong

Liu, Jinsong wrote:
> Xen/MCE: Abort live migration when vMCE occur
> 
> This patch monitor the critical area of live migration (from vMCE
> point of view, 
> the copypages stage of migration is the critical area while other
> areas are not). 
> 
> If a vMCE occur at the critical area of live migration, there is risk
> that error 
> data may be copied to the target. Currently we don't have convenient
> way to handle 
> this case, so for the sake of safe, we abort it and try migration
> later (at that 
> time broken page would not be mapped and copied to the target).
> 
> Signed-off-by: Liu, Jinsong 
> 
> diff -r e27a6d53ac15 tools/libxc/xc_domain.c
> --- a/tools/libxc/xc_domain.c	Thu Oct 11 01:52:33 2012 +0800
> +++ b/tools/libxc/xc_domain.c	Thu Oct 11 05:12:48 2012 +0800
> @@ -283,6 +283,30 @@
>      return ret;
>  }
> 
> +/* Start vmce monitor */
> +int xc_domain_vmce_monitor_start(xc_interface *xch,
> +                                 uint32_t domid)
> +{
> +    DECLARE_DOMCTL;
> +
> +    domctl.cmd = XEN_DOMCTL_vmce_monitor_start;
> +    domctl.domain = (domid_t)domid;
> +
> +    return do_domctl(xch, &domctl);
> +}
> +
> +/* End vmce monitor */
> +int xc_domain_vmce_monitor_end(xc_interface *xch,
> +                               uint32_t domid)
> +{
> +    DECLARE_DOMCTL;
> +
> +    domctl.cmd = XEN_DOMCTL_vmce_monitor_end;
> +    domctl.domain = (domid_t)domid;
> +
> +    return do_domctl(xch, &domctl);
> +}
> +
>  /* get info from hvm guest for save */
>  int xc_domain_hvm_getcontext(xc_interface *xch,
>                               uint32_t domid,
> diff -r e27a6d53ac15 tools/libxc/xc_domain_save.c
> --- a/tools/libxc/xc_domain_save.c	Thu Oct 11 01:52:33 2012 +0800
> +++ b/tools/libxc/xc_domain_save.c	Thu Oct 11 05:12:48 2012 +0800
> @@ -895,6 +895,8 @@
>       */
>      int compressing = 0;
> 
> +    int vmce_while_monitor = 0;
> +
>      int completed = 0;
> 
>      if ( hvm && !callbacks->switch_qemu_logdirty )
> @@ -1109,6 +1111,12 @@
>          goto out;
>      }
> 
> +    if ( xc_domain_vmce_monitor_start(xch, dom) )
> +    {
> +        PERROR("Error when start vmce monitor\n");
> +        goto out;
> +    }
> +
>    copypages:
>  #define wrexact(fd, buf, len) write_buffer(xch, last_iter, ob, (fd),
>  (buf), (len)) #define wruncached(fd, live, buf, len)
> write_uncached(xch, last_iter, ob, (fd), (buf), (len)) @@ -1571,6
> +1579,18 @@ 
> 
>      DPRINTF("All memory is saved\n");
> 
> +    vmce_while_monitor = xc_domain_vmce_monitor_end(xch, dom);
> +    if ( vmce_while_monitor < 0 )
> +    {
> +        PERROR("Error when end vmce monitor\n");
> +        goto out;
> +    }
> +    else if ( vmce_while_monitor > 0 )
> +    {
> +        fprintf(stderr, "vMCE occurred, abort this time and try
> later.\n"); +        goto out;
> +    }
> +
>      /* After last_iter, buffer the rest of pagebuf & tailbuf data
> into a 
>       * separate output buffer and flush it after the compressed page
>       chunks. */
> diff -r e27a6d53ac15 tools/libxc/xenctrl.h
> --- a/tools/libxc/xenctrl.h	Thu Oct 11 01:52:33 2012 +0800
> +++ b/tools/libxc/xenctrl.h	Thu Oct 11 05:12:48 2012 +0800
> @@ -575,6 +575,26 @@
>                            xc_domaininfo_t *info);
> 
>  /**
> + * This function start monitor vmce event.
> + * @parm xch a handle to an open hypervisor interface
> + * @parm domid the domain id monitored
> + * @return <0 on failure, 0 on success
> + */
> +int xc_domain_vmce_monitor_start(xc_interface *xch,
> +                                 uint32_t domid);
> +
> +/**
> + * This function end monitor vmce event
> + * @parm xch a handle to an open hypervisor interface
> + * @parm domid the domain id monitored
> + * @return < 0 on failure, >= 0 on success while
> + *   = 0 on no vmce occurred
> + *   > 0 on vmce occurred
> + */
> +int xc_domain_vmce_monitor_end(xc_interface *xch,
> +                               uint32_t domid);
> +
> +/**
>   * This function returns information about the context of a hvm
> domain 
>   * @parm xch a handle to an open hypervisor interface
>   * @parm domid the domain to get information from
> diff -r e27a6d53ac15 xen/arch/x86/cpu/mcheck/mce_intel.c
> --- a/xen/arch/x86/cpu/mcheck/mce_intel.c	Thu Oct 11 01:52:33 2012
> +0800 +++ b/xen/arch/x86/cpu/mcheck/mce_intel.c	Thu Oct 11 05:12:48
> 2012 +0800 @@ -359,6 +359,12 @@
>                      goto vmce_failed;
>                  }
> 
> +                if ( unlikely(d->arch.vmce_monitor) )
> +                {
> +                    /* vMCE occur when guest migration */
> +                    d->arch.vmce_monitor = 1;
> +                }
> +
>                  /* We will inject vMCE to DOMU*/
>                  if ( inject_vmce(d, VMCE_INJECT_BROADCAST) < 0 )
>                  {
> diff -r e27a6d53ac15 xen/arch/x86/domctl.c
> --- a/xen/arch/x86/domctl.c	Thu Oct 11 01:52:33 2012 +0800
> +++ b/xen/arch/x86/domctl.c	Thu Oct 11 05:12:48 2012 +0800
> @@ -1568,6 +1568,47 @@
>      }
>      break;
> 
> +    case XEN_DOMCTL_vmce_monitor_start:
> +    {
> +        struct domain *d;
> +
> +        d = rcu_lock_domain_by_id(domctl->domain);
> +        if ( d != NULL )
> +        {
> +            if ( d->arch.vmce_monitor )
> +                ret = -EBUSY;
> +            else
> +                d->arch.vmce_monitor = -1;
> +
> +            rcu_unlock_domain(d);
> +        }
> +        else
> +            ret = -ESRCH;
> +    }
> +    break;
> +
> +    case XEN_DOMCTL_vmce_monitor_end:
> +    {
> +        struct domain *d;
> +
> +        d = rcu_lock_domain_by_id(domctl->domain);
> +        if ( d != NULL)
> +        {
> +            if ( !d->arch.vmce_monitor )
> +                ret = -EINVAL;
> +            else
> +            {
> +                ret = d->arch.vmce_monitor > 0 ? 1 : 0;
> +                d->arch.vmce_monitor = 0;
> +            }
> +
> +            rcu_unlock_domain(d);
> +        }
> +        else
> +            ret = -ESRCH;
> +    }
> +    break;
> +
>      default:
>          ret = iommu_do_domctl(domctl, u_domctl);
>          break;
> diff -r e27a6d53ac15 xen/include/asm-x86/domain.h
> --- a/xen/include/asm-x86/domain.h	Thu Oct 11 01:52:33 2012 +0800
> +++ b/xen/include/asm-x86/domain.h	Thu Oct 11 05:12:48 2012 +0800
> @@ -279,6 +279,11 @@
>      bool_t has_32bit_shinfo;
>      /* Domain cannot handle spurious page faults? */
>      bool_t suppress_spurious_page_faults;
> +    /* Monitoring guest memory copy of migration
> +     * = 0 - not monitoring
> +     * < 0 - monitoring
> +     * > 0 - vMCE occurred while monitoring */
> +    s8 vmce_monitor;
> 
>      /* Continuable domain_relinquish_resources(). */
>      enum {
> diff -r e27a6d53ac15 xen/include/public/domctl.h
> --- a/xen/include/public/domctl.h	Thu Oct 11 01:52:33 2012 +0800
> +++ b/xen/include/public/domctl.h	Thu Oct 11 05:12:48 2012 +0800
> @@ -900,6 +900,8 @@
>  #define XEN_DOMCTL_set_access_required           64
>  #define XEN_DOMCTL_audit_p2m                     65
>  #define XEN_DOMCTL_set_virq_handler              66
> +#define XEN_DOMCTL_vmce_monitor_start            67
> +#define XEN_DOMCTL_vmce_monitor_end              68
>  #define XEN_DOMCTL_gdbsx_guestmemio            1000
>  #define XEN_DOMCTL_gdbsx_pausevcpu             1001
>  #define XEN_DOMCTL_gdbsx_unpausevcpu           1002


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 10:46:39 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 10:46:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO4er-0001OK-UE; Tue, 16 Oct 2012 10:45:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO4eq-0001O9-1L
	for xen-devel@lists.xensource.com; Tue, 16 Oct 2012 10:45:56 +0000
Received: from [85.158.143.35:51846] by server-3.bemta-4.messagelabs.com id
	39/3D-03544-3EA3D705; Tue, 16 Oct 2012 10:45:55 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1350384278!13164059!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDM1MjY5OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16476 invoked from network); 16 Oct 2012 10:44:40 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-3.tower-21.messagelabs.com with SMTP;
	16 Oct 2012 10:44:40 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 16 Oct 2012 03:44:24 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,593,1344236400"; d="scan'208";a="235666025"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by fmsmga002.fm.intel.com with ESMTP; 16 Oct 2012 03:44:23 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 16 Oct 2012 03:44:23 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.162]) with mapi id
	14.01.0355.002; Tue, 16 Oct 2012 18:44:21 +0800
From: "Liu, Jinsong" 
To: Ian Jackson , Ian Campbell
	, "xen-devel@lists.xensource.com"
	
Thread-Topic: [Xen-devel] [PATCH 5/5] X86/vMCE: guest broken page handling
	when	migration
Thread-Index: Ac2m9jfAoZM8E5DcSNaYfyzWUUgTXwElL7mw
Date: Tue, 16 Oct 2012 10:44:21 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Christoph Egger ,
	"Keir \(Xen.org\)" , Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 5/5] X86/vMCE: guest broken page handling
 when	migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ping?

Thanks,
Jinsong

Liu, Jinsong wrote:
> X86/vMCE: guest broken page handling when migration
> 
> This patch is used to handle guest broken page when migration.
> 
> At sender, the broken page would not be mapped, and the error page
> content would not be copied to target, otherwise it may trigger more
> serious error (i.e. SRAR error). While its pfn_type and pfn number
> would be transferred to target so that target take appropriate action.
> 
> At target, it would set p2m as p2m_ram_broken for broken page, so that
> if guest access the broken page again, it would kill guest as
> expected. 
> 
> Signed-off-by: Liu, Jinsong 
> 
> diff -r 090447c780db tools/libxc/xc_domain.c
> --- a/tools/libxc/xc_domain.c	Thu Oct 11 05:12:48 2012 +0800
> +++ b/tools/libxc/xc_domain.c	Thu Oct 11 05:49:39 2012 +0800
> @@ -307,6 +307,22 @@
>      return do_domctl(xch, &domctl);
>  }
> 
> +/* set broken page p2m */
> +int xc_set_broken_page_p2m(xc_interface *xch,
> +                           uint32_t domid,
> +                           unsigned long pfn)
> +{
> +    int ret;
> +    DECLARE_DOMCTL;
> +
> +    domctl.cmd = XEN_DOMCTL_set_broken_page_p2m;
> +    domctl.domain = (domid_t)domid;
> +    domctl.u.set_broken_page_p2m.pfn = pfn;
> +    ret = do_domctl(xch, &domctl);
> +
> +    return ret ? -1 : 0;
> +}
> +
>  /* get info from hvm guest for save */
>  int xc_domain_hvm_getcontext(xc_interface *xch,
>                               uint32_t domid,
> diff -r 090447c780db tools/libxc/xc_domain_restore.c
> --- a/tools/libxc/xc_domain_restore.c	Thu Oct 11 05:12:48 2012 +0800
> +++ b/tools/libxc/xc_domain_restore.c	Thu Oct 11 05:49:39 2012 +0800
> @@ -962,9 +962,15 @@
> 
>      countpages = count;
>      for (i = oldcount; i < buf->nr_pages; ++i)
> -        if ((buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) ==
> XEN_DOMCTL_PFINFO_XTAB 
> -            ||(buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) ==
> XEN_DOMCTL_PFINFO_XALLOC) +    {
> +        unsigned long pagetype;
> +
> +        pagetype = buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK;
> +        if ( pagetype == XEN_DOMCTL_PFINFO_XTAB ||
> +             pagetype == XEN_DOMCTL_PFINFO_BROKEN ||
> +             pagetype == XEN_DOMCTL_PFINFO_XALLOC )
>              --countpages;
> +    }
> 
>      if (!countpages)
>          return count;
> @@ -1200,6 +1206,17 @@
>              /* a bogus/unmapped/allocate-only page: skip it */
>              continue;
> 
> +        if ( pagetype == XEN_DOMCTL_PFINFO_BROKEN )
> +        {
> +            if ( xc_set_broken_page_p2m(xch, dom, pfn) )
> +            {
> +                ERROR("Set p2m for broken page failed, "
> +                      "dom=%d, pfn=%lx\n", dom, pfn);
> +                goto err_mapped;
> +            }
> +            continue;
> +        }
> +
>          if (pfn_err[i])
>          {
>              ERROR("unexpected PFN mapping failure pfn %lx map_mfn
> %lx p2m_mfn %lx", 
> diff -r 090447c780db tools/libxc/xc_domain_save.c
> --- a/tools/libxc/xc_domain_save.c	Thu Oct 11 05:12:48 2012 +0800
> +++ b/tools/libxc/xc_domain_save.c	Thu Oct 11 05:49:39 2012 +0800
> @@ -1285,6 +1285,13 @@
>                  if ( !hvm )
>                      gmfn = pfn_to_mfn(gmfn);
> 
> +                if ( pfn_type[j] == XEN_DOMCTL_PFINFO_BROKEN )
> +                {
> +                    pfn_type[j] |= pfn_batch[j];
> +                    ++run;
> +                    continue;
> +                }
> +
>                  if ( pfn_err[j] )
>                  {
>                      if ( pfn_type[j] == XEN_DOMCTL_PFINFO_XTAB )
> @@ -1379,8 +1386,12 @@
>                      }
>                  }
> 
> -                /* skip pages that aren't present or are alloc-only
> */ +                /*
> +                 * skip pages that aren't present,
> +                 * or are broken, or are alloc-only
> +                 */
>                  if ( pagetype == XEN_DOMCTL_PFINFO_XTAB
> +                    || pagetype == XEN_DOMCTL_PFINFO_BROKEN
>                      || pagetype == XEN_DOMCTL_PFINFO_XALLOC )
>                      continue;
> 
> diff -r 090447c780db tools/libxc/xenctrl.h
> --- a/tools/libxc/xenctrl.h	Thu Oct 11 05:12:48 2012 +0800
> +++ b/tools/libxc/xenctrl.h	Thu Oct 11 05:49:39 2012 +0800
> @@ -595,6 +595,17 @@
>                                 uint32_t domid);
> 
>  /**
> + * This function set p2m for broken page
> + * &parm xch a handle to an open hypervisor interface
> + * @parm domid the domain id which broken page belong to
> + * @parm pfn the pfn number of the broken page
> + * @return 0 on success, -1 on failure
> + */
> +int xc_set_broken_page_p2m(xc_interface *xch,
> +                           uint32_t domid,
> +                           unsigned long pfn);
> +
> +/**
>   * This function returns information about the context of a hvm
> domain 
>   * @parm xch a handle to an open hypervisor interface
>   * @parm domid the domain to get information from
> diff -r 090447c780db xen/arch/x86/domctl.c
> --- a/xen/arch/x86/domctl.c	Thu Oct 11 05:12:48 2012 +0800
> +++ b/xen/arch/x86/domctl.c	Thu Oct 11 05:49:39 2012 +0800
> @@ -209,12 +209,18 @@
>                  for ( j = 0; j < k; j++ )
>                  {
>                      unsigned long type = 0;
> +                    p2m_type_t t;
> 
> -                    page = get_page_from_gfn(d, arr[j], NULL,
> P2M_ALLOC); +                    page = get_page_from_gfn(d, arr[j],
> &t, P2M_ALLOC); 
> 
>                      if ( unlikely(!page) ||
>                           unlikely(is_xen_heap_page(page)) )
> -                        type = XEN_DOMCTL_PFINFO_XTAB;
> +                    {
> +                        if ( p2m_is_broken(t) )
> +                            type = XEN_DOMCTL_PFINFO_BROKEN;
> +                        else
> +                            type = XEN_DOMCTL_PFINFO_XTAB;
> +                    }
>                      else
>                      {
>                          switch( page->u.inuse.type_info &
> PGT_type_mask ) @@ -235,6 +241,9 @@
> 
>                          if ( page->u.inuse.type_info & PGT_pinned )
>                              type |= XEN_DOMCTL_PFINFO_LPINTAB;
> +
> +                        if ( page->count_info & PGC_broken )
> +                            type = XEN_DOMCTL_PFINFO_BROKEN;
>                      }
> 
>                      if ( page )
> @@ -1609,6 +1618,28 @@
>      }
>      break;
> 
> +    case XEN_DOMCTL_set_broken_page_p2m:
> +    {
> +        struct domain *d;
> +        p2m_type_t pt;
> +        unsigned long pfn;
> +
> +        d = rcu_lock_domain_by_id(domctl->domain);
> +        if ( d != NULL )
> +        {
> +            pfn = domctl->u.set_broken_page_p2m.pfn;
> +
> +            get_gfn_query(d, pfn, &pt);
> +            p2m_change_type(d, pfn, pt, p2m_ram_broken);
> +            put_gfn(d, pfn);
> +
> +            rcu_unlock_domain(d);
> +        }
> +        else
> +            ret = -ESRCH;
> +    }
> +    break;
> +
>      default:
>          ret = iommu_do_domctl(domctl, u_domctl);
>          break;
> diff -r 090447c780db xen/include/public/domctl.h
> --- a/xen/include/public/domctl.h	Thu Oct 11 05:12:48 2012 +0800
> +++ b/xen/include/public/domctl.h	Thu Oct 11 05:49:39 2012 +0800
> @@ -136,6 +136,7 @@
>  #define XEN_DOMCTL_PFINFO_LPINTAB (0x1U<<31)
>  #define XEN_DOMCTL_PFINFO_XTAB    (0xfU<<28) /* invalid page */
>  #define XEN_DOMCTL_PFINFO_XALLOC  (0xeU<<28) /* allocate-only page */
> +#define XEN_DOMCTL_PFINFO_BROKEN  (0xdU<<28) /* broken page */
>  #define XEN_DOMCTL_PFINFO_PAGEDTAB (0x8U<<28)
>  #define XEN_DOMCTL_PFINFO_LTAB_MASK (0xfU<<28)
> 
> @@ -835,6 +836,12 @@
>  typedef struct xen_domctl_set_access_required
>  xen_domctl_set_access_required_t;
> DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_access_required_t); 
> 
> +struct xen_domctl_set_broken_page_p2m {
> +    uint64_aligned_t pfn;
> +};
> +typedef struct xen_domctl_set_broken_page_p2m
> xen_domctl_set_broken_page_p2m_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_broken_page_p2m_t); +
>  struct xen_domctl {
>      uint32_t cmd;
>  #define XEN_DOMCTL_createdomain                   1
> @@ -902,6 +909,7 @@
>  #define XEN_DOMCTL_set_virq_handler              66
>  #define XEN_DOMCTL_vmce_monitor_start            67
>  #define XEN_DOMCTL_vmce_monitor_end              68
> +#define XEN_DOMCTL_set_broken_page_p2m           69
>  #define XEN_DOMCTL_gdbsx_guestmemio            1000
>  #define XEN_DOMCTL_gdbsx_pausevcpu             1001
>  #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
> @@ -957,6 +965,7 @@
>          struct xen_domctl_audit_p2m         audit_p2m;
>          struct xen_domctl_set_virq_handler  set_virq_handler;
>          struct xen_domctl_gdbsx_memio       gdbsx_guest_memio;
> +        struct xen_domctl_set_broken_page_p2m set_broken_page_p2m;
>          struct xen_domctl_gdbsx_pauseunp_vcpu gdbsx_pauseunp_vcpu;
>          struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
>          uint8_t                             pad[128];


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 10:46:39 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 10:46:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO4er-0001OK-UE; Tue, 16 Oct 2012 10:45:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO4eq-0001O9-1L
	for xen-devel@lists.xensource.com; Tue, 16 Oct 2012 10:45:56 +0000
Received: from [85.158.143.35:51846] by server-3.bemta-4.messagelabs.com id
	39/3D-03544-3EA3D705; Tue, 16 Oct 2012 10:45:55 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1350384278!13164059!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDM1MjY5OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16476 invoked from network); 16 Oct 2012 10:44:40 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-3.tower-21.messagelabs.com with SMTP;
	16 Oct 2012 10:44:40 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 16 Oct 2012 03:44:24 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,593,1344236400"; d="scan'208";a="235666025"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by fmsmga002.fm.intel.com with ESMTP; 16 Oct 2012 03:44:23 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 16 Oct 2012 03:44:23 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.162]) with mapi id
	14.01.0355.002; Tue, 16 Oct 2012 18:44:21 +0800
From: "Liu, Jinsong" 
To: Ian Jackson , Ian Campbell
	, "xen-devel@lists.xensource.com"
	
Thread-Topic: [Xen-devel] [PATCH 5/5] X86/vMCE: guest broken page handling
	when	migration
Thread-Index: Ac2m9jfAoZM8E5DcSNaYfyzWUUgTXwElL7mw
Date: Tue, 16 Oct 2012 10:44:21 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Christoph Egger ,
	"Keir \(Xen.org\)" , Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 5/5] X86/vMCE: guest broken page handling
 when	migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ping?

Thanks,
Jinsong

Liu, Jinsong wrote:
> X86/vMCE: guest broken page handling when migration
> 
> This patch is used to handle guest broken page when migration.
> 
> At sender, the broken page would not be mapped, and the error page
> content would not be copied to target, otherwise it may trigger more
> serious error (i.e. SRAR error). While its pfn_type and pfn number
> would be transferred to target so that target take appropriate action.
> 
> At target, it would set p2m as p2m_ram_broken for broken page, so that
> if guest access the broken page again, it would kill guest as
> expected. 
> 
> Signed-off-by: Liu, Jinsong 
> 
> diff -r 090447c780db tools/libxc/xc_domain.c
> --- a/tools/libxc/xc_domain.c	Thu Oct 11 05:12:48 2012 +0800
> +++ b/tools/libxc/xc_domain.c	Thu Oct 11 05:49:39 2012 +0800
> @@ -307,6 +307,22 @@
>      return do_domctl(xch, &domctl);
>  }
> 
> +/* set broken page p2m */
> +int xc_set_broken_page_p2m(xc_interface *xch,
> +                           uint32_t domid,
> +                           unsigned long pfn)
> +{
> +    int ret;
> +    DECLARE_DOMCTL;
> +
> +    domctl.cmd = XEN_DOMCTL_set_broken_page_p2m;
> +    domctl.domain = (domid_t)domid;
> +    domctl.u.set_broken_page_p2m.pfn = pfn;
> +    ret = do_domctl(xch, &domctl);
> +
> +    return ret ? -1 : 0;
> +}
> +
>  /* get info from hvm guest for save */
>  int xc_domain_hvm_getcontext(xc_interface *xch,
>                               uint32_t domid,
> diff -r 090447c780db tools/libxc/xc_domain_restore.c
> --- a/tools/libxc/xc_domain_restore.c	Thu Oct 11 05:12:48 2012 +0800
> +++ b/tools/libxc/xc_domain_restore.c	Thu Oct 11 05:49:39 2012 +0800
> @@ -962,9 +962,15 @@
> 
>      countpages = count;
>      for (i = oldcount; i < buf->nr_pages; ++i)
> -        if ((buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) ==
> XEN_DOMCTL_PFINFO_XTAB 
> -            ||(buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) ==
> XEN_DOMCTL_PFINFO_XALLOC) +    {
> +        unsigned long pagetype;
> +
> +        pagetype = buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK;
> +        if ( pagetype == XEN_DOMCTL_PFINFO_XTAB ||
> +             pagetype == XEN_DOMCTL_PFINFO_BROKEN ||
> +             pagetype == XEN_DOMCTL_PFINFO_XALLOC )
>              --countpages;
> +    }
> 
>      if (!countpages)
>          return count;
> @@ -1200,6 +1206,17 @@
>              /* a bogus/unmapped/allocate-only page: skip it */
>              continue;
> 
> +        if ( pagetype == XEN_DOMCTL_PFINFO_BROKEN )
> +        {
> +            if ( xc_set_broken_page_p2m(xch, dom, pfn) )
> +            {
> +                ERROR("Set p2m for broken page failed, "
> +                      "dom=%d, pfn=%lx\n", dom, pfn);
> +                goto err_mapped;
> +            }
> +            continue;
> +        }
> +
>          if (pfn_err[i])
>          {
>              ERROR("unexpected PFN mapping failure pfn %lx map_mfn
> %lx p2m_mfn %lx", 
> diff -r 090447c780db tools/libxc/xc_domain_save.c
> --- a/tools/libxc/xc_domain_save.c	Thu Oct 11 05:12:48 2012 +0800
> +++ b/tools/libxc/xc_domain_save.c	Thu Oct 11 05:49:39 2012 +0800
> @@ -1285,6 +1285,13 @@
>                  if ( !hvm )
>                      gmfn = pfn_to_mfn(gmfn);
> 
> +                if ( pfn_type[j] == XEN_DOMCTL_PFINFO_BROKEN )
> +                {
> +                    pfn_type[j] |= pfn_batch[j];
> +                    ++run;
> +                    continue;
> +                }
> +
>                  if ( pfn_err[j] )
>                  {
>                      if ( pfn_type[j] == XEN_DOMCTL_PFINFO_XTAB )
> @@ -1379,8 +1386,12 @@
>                      }
>                  }
> 
> -                /* skip pages that aren't present or are alloc-only
> */ +                /*
> +                 * skip pages that aren't present,
> +                 * or are broken, or are alloc-only
> +                 */
>                  if ( pagetype == XEN_DOMCTL_PFINFO_XTAB
> +                    || pagetype == XEN_DOMCTL_PFINFO_BROKEN
>                      || pagetype == XEN_DOMCTL_PFINFO_XALLOC )
>                      continue;
> 
> diff -r 090447c780db tools/libxc/xenctrl.h
> --- a/tools/libxc/xenctrl.h	Thu Oct 11 05:12:48 2012 +0800
> +++ b/tools/libxc/xenctrl.h	Thu Oct 11 05:49:39 2012 +0800
> @@ -595,6 +595,17 @@
>                                 uint32_t domid);
> 
>  /**
> + * This function set p2m for broken page
> + * &parm xch a handle to an open hypervisor interface
> + * @parm domid the domain id which broken page belong to
> + * @parm pfn the pfn number of the broken page
> + * @return 0 on success, -1 on failure
> + */
> +int xc_set_broken_page_p2m(xc_interface *xch,
> +                           uint32_t domid,
> +                           unsigned long pfn);
> +
> +/**
>   * This function returns information about the context of a hvm
> domain 
>   * @parm xch a handle to an open hypervisor interface
>   * @parm domid the domain to get information from
> diff -r 090447c780db xen/arch/x86/domctl.c
> --- a/xen/arch/x86/domctl.c	Thu Oct 11 05:12:48 2012 +0800
> +++ b/xen/arch/x86/domctl.c	Thu Oct 11 05:49:39 2012 +0800
> @@ -209,12 +209,18 @@
>                  for ( j = 0; j < k; j++ )
>                  {
>                      unsigned long type = 0;
> +                    p2m_type_t t;
> 
> -                    page = get_page_from_gfn(d, arr[j], NULL,
> P2M_ALLOC); +                    page = get_page_from_gfn(d, arr[j],
> &t, P2M_ALLOC); 
> 
>                      if ( unlikely(!page) ||
>                           unlikely(is_xen_heap_page(page)) )
> -                        type = XEN_DOMCTL_PFINFO_XTAB;
> +                    {
> +                        if ( p2m_is_broken(t) )
> +                            type = XEN_DOMCTL_PFINFO_BROKEN;
> +                        else
> +                            type = XEN_DOMCTL_PFINFO_XTAB;
> +                    }
>                      else
>                      {
>                          switch( page->u.inuse.type_info &
> PGT_type_mask ) @@ -235,6 +241,9 @@
> 
>                          if ( page->u.inuse.type_info & PGT_pinned )
>                              type |= XEN_DOMCTL_PFINFO_LPINTAB;
> +
> +                        if ( page->count_info & PGC_broken )
> +                            type = XEN_DOMCTL_PFINFO_BROKEN;
>                      }
> 
>                      if ( page )
> @@ -1609,6 +1618,28 @@
>      }
>      break;
> 
> +    case XEN_DOMCTL_set_broken_page_p2m:
> +    {
> +        struct domain *d;
> +        p2m_type_t pt;
> +        unsigned long pfn;
> +
> +        d = rcu_lock_domain_by_id(domctl->domain);
> +        if ( d != NULL )
> +        {
> +            pfn = domctl->u.set_broken_page_p2m.pfn;
> +
> +            get_gfn_query(d, pfn, &pt);
> +            p2m_change_type(d, pfn, pt, p2m_ram_broken);
> +            put_gfn(d, pfn);
> +
> +            rcu_unlock_domain(d);
> +        }
> +        else
> +            ret = -ESRCH;
> +    }
> +    break;
> +
>      default:
>          ret = iommu_do_domctl(domctl, u_domctl);
>          break;
> diff -r 090447c780db xen/include/public/domctl.h
> --- a/xen/include/public/domctl.h	Thu Oct 11 05:12:48 2012 +0800
> +++ b/xen/include/public/domctl.h	Thu Oct 11 05:49:39 2012 +0800
> @@ -136,6 +136,7 @@
>  #define XEN_DOMCTL_PFINFO_LPINTAB (0x1U<<31)
>  #define XEN_DOMCTL_PFINFO_XTAB    (0xfU<<28) /* invalid page */
>  #define XEN_DOMCTL_PFINFO_XALLOC  (0xeU<<28) /* allocate-only page */
> +#define XEN_DOMCTL_PFINFO_BROKEN  (0xdU<<28) /* broken page */
>  #define XEN_DOMCTL_PFINFO_PAGEDTAB (0x8U<<28)
>  #define XEN_DOMCTL_PFINFO_LTAB_MASK (0xfU<<28)
> 
> @@ -835,6 +836,12 @@
>  typedef struct xen_domctl_set_access_required
>  xen_domctl_set_access_required_t;
> DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_access_required_t); 
> 
> +struct xen_domctl_set_broken_page_p2m {
> +    uint64_aligned_t pfn;
> +};
> +typedef struct xen_domctl_set_broken_page_p2m
> xen_domctl_set_broken_page_p2m_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_broken_page_p2m_t); +
>  struct xen_domctl {
>      uint32_t cmd;
>  #define XEN_DOMCTL_createdomain                   1
> @@ -902,6 +909,7 @@
>  #define XEN_DOMCTL_set_virq_handler              66
>  #define XEN_DOMCTL_vmce_monitor_start            67
>  #define XEN_DOMCTL_vmce_monitor_end              68
> +#define XEN_DOMCTL_set_broken_page_p2m           69
>  #define XEN_DOMCTL_gdbsx_guestmemio            1000
>  #define XEN_DOMCTL_gdbsx_pausevcpu             1001
>  #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
> @@ -957,6 +965,7 @@
>          struct xen_domctl_audit_p2m         audit_p2m;
>          struct xen_domctl_set_virq_handler  set_virq_handler;
>          struct xen_domctl_gdbsx_memio       gdbsx_guest_memio;
> +        struct xen_domctl_set_broken_page_p2m set_broken_page_p2m;
>          struct xen_domctl_gdbsx_pauseunp_vcpu gdbsx_pauseunp_vcpu;
>          struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
>          uint8_t                             pad[128];


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 10:56:26 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 10:56:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO4oN-0001co-FU; Tue, 16 Oct 2012 10:55:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO4ZW-0001Dp-UZ
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 10:40:27 +0000
Received: from [85.158.143.35:23803] by server-3.bemta-4.messagelabs.com id
	E7/84-03544-A993D705; Tue, 16 Oct 2012 10:40:26 +0000
X-Env-Sender: jseward@acm.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1350384023!18979866!1
X-Originating-IP: [67.58.97.34]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4124 invoked from network); 16 Oct 2012 10:40:25 -0000
Received: from server.rebelnetworks.com (HELO server.rebelnetworks.com)
	(67.58.97.34)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Oct 2012 10:40:25 -0000
Received: from p5492f51c.dip.t-dialin.net ([84.146.245.28]:41792
	helo=phoenix.localnet)
	by server.rebelnetworks.com with esmtpa (Exim 4.77)
	(envelope-from )
	id 1TO4ZL-00016e-0Y; Tue, 16 Oct 2012 06:40:15 -0400
From: Julian Seward 
To: Ian Campbell 
Date: Tue, 16 Oct 2012 12:33:31 +0200
User-Agent: KMail/1.13.5 (Linux/2.6.32-41-generic; KDE/4.4.5; x86_64; ; )
References: <1349696046.18008.116.camel@zakaz.uk.xensource.com>
	<507C5227.7020404@acm.org>
	<1350383681.18058.113.camel@zakaz.uk.xensource.com>
In-Reply-To: <1350383681.18058.113.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Message-Id: <201210161233.32304.jseward@acm.org>
X-Rebelnetworks-MailScanner-Information: Please contact the ISP for more
	information
X-Rebelnetworks-MailScanner-ID: 1TO4ZL-00016e-0Y
X-Rebelnetworks-MailScanner: Not scanned: please contact your Internet E-Mail
	Service Provider for details
X-Rebelnetworks-MailScanner-SpamCheck: 
X-Rebelnetworks-MailScanner-From: jseward@acm.org
X-Spam-Status: No
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.rebelnetworks.com
X-AntiAbuse: Original Domain - lists.xen.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - acm.org
X-Mailman-Approved-At: Tue, 16 Oct 2012 10:55:47 +0000
Cc: "valgrind-developers@lists.sourceforge.net"
	,
	Bart Van Assche , xen-devel 
Subject: Re: [Xen-devel] [Valgrind-developers] [PATCH 1/4] Useful messages
	for sys/domctl interface_version mismatch.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tuesday, October 16, 2012, Ian Campbell wrote:
> On Mon, 2012-10-15 at 19:12 +0100, Bart Van Assche wrote:

> > please file a bug report. As you might have noticed Julian uses the
> > bugzilla ticket numbers to track issues in the NEWS file, and also to
> > keep track of which issues have been fixed in which branch.

And also docs/internals/3_8_BUGSTATUS.txt tracks the current not-fixed
bug set.

J

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 10:56:26 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 10:56:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO4oN-0001co-FU; Tue, 16 Oct 2012 10:55:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO4ZW-0001Dp-UZ
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 10:40:27 +0000
Received: from [85.158.143.35:23803] by server-3.bemta-4.messagelabs.com id
	E7/84-03544-A993D705; Tue, 16 Oct 2012 10:40:26 +0000
X-Env-Sender: jseward@acm.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1350384023!18979866!1
X-Originating-IP: [67.58.97.34]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4124 invoked from network); 16 Oct 2012 10:40:25 -0000
Received: from server.rebelnetworks.com (HELO server.rebelnetworks.com)
	(67.58.97.34)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Oct 2012 10:40:25 -0000
Received: from p5492f51c.dip.t-dialin.net ([84.146.245.28]:41792
	helo=phoenix.localnet)
	by server.rebelnetworks.com with esmtpa (Exim 4.77)
	(envelope-from )
	id 1TO4ZL-00016e-0Y; Tue, 16 Oct 2012 06:40:15 -0400
From: Julian Seward 
To: Ian Campbell 
Date: Tue, 16 Oct 2012 12:33:31 +0200
User-Agent: KMail/1.13.5 (Linux/2.6.32-41-generic; KDE/4.4.5; x86_64; ; )
References: <1349696046.18008.116.camel@zakaz.uk.xensource.com>
	<507C5227.7020404@acm.org>
	<1350383681.18058.113.camel@zakaz.uk.xensource.com>
In-Reply-To: <1350383681.18058.113.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Message-Id: <201210161233.32304.jseward@acm.org>
X-Rebelnetworks-MailScanner-Information: Please contact the ISP for more
	information
X-Rebelnetworks-MailScanner-ID: 1TO4ZL-00016e-0Y
X-Rebelnetworks-MailScanner: Not scanned: please contact your Internet E-Mail
	Service Provider for details
X-Rebelnetworks-MailScanner-SpamCheck: 
X-Rebelnetworks-MailScanner-From: jseward@acm.org
X-Spam-Status: No
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.rebelnetworks.com
X-AntiAbuse: Original Domain - lists.xen.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - acm.org
X-Mailman-Approved-At: Tue, 16 Oct 2012 10:55:47 +0000
Cc: "valgrind-developers@lists.sourceforge.net"
	,
	Bart Van Assche , xen-devel 
Subject: Re: [Xen-devel] [Valgrind-developers] [PATCH 1/4] Useful messages
	for sys/domctl interface_version mismatch.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tuesday, October 16, 2012, Ian Campbell wrote:
> On Mon, 2012-10-15 at 19:12 +0100, Bart Van Assche wrote:

> > please file a bug report. As you might have noticed Julian uses the
> > bugzilla ticket numbers to track issues in the NEWS file, and also to
> > keep track of which issues have been fixed in which branch.

And also docs/internals/3_8_BUGSTATUS.txt tracks the current not-fixed
bug set.

J

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 11:49:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 11:49:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO5eI-0001zZ-MC; Tue, 16 Oct 2012 11:49:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO5eH-0001zU-98
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 11:49:25 +0000
Received: from [85.158.139.83:40772] by server-4.bemta-5.messagelabs.com id
	05/B4-01455-4C94D705; Tue, 16 Oct 2012 11:49:24 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1350388162!21003466!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25570 invoked from network); 16 Oct 2012 11:49:23 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 11:49:23 -0000
Received: by mail-vb0-f45.google.com with SMTP id p1so7875866vbi.32
	for ; Tue, 16 Oct 2012 04:49:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=UQxVwfH0VALuCpBApHS/2woD/VDpy0CGiGnQ8ZZPdNA=;
	b=hRBDWjVvrpGaMsPM7I8wXNc3cT2VD3MJ6TibiIpwnNfUuVxgobVMYAiFnv5TkrYeh3
	aPOgVvCFzR7em1DVD7CdcIZHHskdVv3tSAcrEwbchc1D0TYVzBxcR9YBkYghFQTkj0je
	yWch9t+TkpXc4gBakupKV9ciuOGkGeZCanR9k1mJHSR6yS29YfO9rCCdGL7NDb6P1ASl
	C3ir/DDeQuhqXq/Hv+mcnQDYchGOhZdBoaRGYNkmnNm8NjSkT4QbL4bK/4CD/7GD+36w
	0pmw/iMpKzHo/f0uxFSEX/LsQjb9iyiXtdmtLRXnwsT+RQmCbITxJqaEGRZOwxAOA6G9
	kV9Q==
MIME-Version: 1.0
Received: by 10.52.69.47 with SMTP id b15mr6770232vdu.116.1350388162147; Tue,
	16 Oct 2012 04:49:22 -0700 (PDT)
Received: by 10.58.231.138 with HTTP; Tue, 16 Oct 2012 04:49:21 -0700 (PDT)
In-Reply-To: <58b5a25d-ccdd-4d0c-a0d9-9c249825f7f1@default>
References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default>
	<20581.55931.246130.308384@mariner.uk.xensource.com>
	<8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default>
	<20121002091017.GA95926@ocelot.phlegethon.org>
	<66cc0085-1216-40f7-8059-eaf615202c12@default>
	<20121002201624.GA98445@ocelot.phlegethon.org>
	
	<20121004100645.GC38243@ocelot.phlegethon.org>
	<1349345864.650.247.camel@zakaz.uk.xensource.com>
	<239799F4-AF29-494F-86D2-ADF45ACA8792@gridcentric.ca>
	<3e5cf0ba-4241-4f00-bef6-aaff2cc23419@default>
	<506EC710.3020606@eu.citrix.com>
	<58b5a25d-ccdd-4d0c-a0d9-9c249825f7f1@default>
Date: Tue, 16 Oct 2012 12:49:21 +0100
X-Google-Sender-Auth: Smjd4N6rs2bcOL9G22HzOOFX1LE
Message-ID: 
From: George Dunlap 
To: Dan Magenheimer 
Cc: Olaf Hering , "Keir \(Xen.org\)" ,
	Ian Campbell ,
	Konrad Wilk ,
	Andres Lagar-Cavilla ,
	"Tim \(Xen.org\)" , xen-devel@lists.xen.org,
	George Shuklin ,
	Dario Faggioli , Kurt Hackel ,
	Ian Jackson 
Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and
	xl)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 8, 2012 at 2:02 AM, Dan Magenheimer
 wrote:
> Tmem really is a breakthrough on memory management in a virtualized
> system.  I realize that many people are in the "if it doesn't
> work on Windows, I don't care" camp.  And others never thought
> it would make it into upstream Linux (or don't care because it isn't
> completely functional in any distros yet... other than Oracle's..
> but since all parts are now upstream, it will be soon).  But there
> probably are also many that just don't understand it... I guess I need
> to work on fixing that.  Any thoughts on how to start?

Well, I'm sorry to say this, but to start I think you need to work on
your communication.  I had read this entire thread 2 or 3 times before
writing my last response; and I have now read this e-mail half a dozen
times, and I'm still don't have a good idea what it is you're talking
about.  If I didn't respect you, I would have just given up on the 2nd
try.

In my summary, I mentioned just 2 things: the problem of domain
creation, and the solution of a hypercall to allocate a big chunk of
memory to a domain.  You answered by saying it was a good summary.
But then you said:

> I'm just proposing an extension to the
> existing mechanism and I am quite convinced that the hypervisor must
> be involved (e.g. a new hypercall) for the extension to work properly.

Now you're talking about an extension... then you mention a "memory
scheduler" (which we don't yet have), and say:

> ...there is inadequate information from
> any VM to drive automatic memory allocation decisions and, even if
> there was, it just doesn't scale.

But you don't say where or who *could* have adequate information;
which again hints at something else which you have in mind, but you
haven't actually talked about very explicitly yet.  If you have been
trying to talk about it, and it wasn't in my summary, why didn't you
say something about it, instead of saying, "Yes that's right"?  And if
you haven't talked about it, why are you speaking as though we all
know already what you're talking about?

Furthermore, you say things like this:

> IMHO, the example you give for asking a memory controller for GiB
> of memory is equally silly.  Outside of some geek with a handful
> of VMs on a single machine, there is inadequate information from
> any VM to drive automatic memory allocation decisions and, even if
> there was, it just doesn't scale.  It doesn't scale either up, to
> many VMs across many physical machines, or down, to instantaneous
> needs of one-page-at-a-time requests for unsharing or for tmem.

What do you mean, "doesn't scale up or across"?  Why not?  Why is
there inadequate information inside dom0 for a toolstack-based memory
controller?  And if there's not enough information there, who *does*
have the information?  It's just a bunch of vague assertions with no
justification and no alternative proposed.  It doesn't bring any light
to the discussion (which is no doubt why the thread has died without
conclusion).

Nor does saying "see above" and "see below", when "above" and "below"
are still equally unenlightening.

Maybe your grand designs for a "memory scheduler", where memory pages
hop back and forth at millisecond quanta based on instantaneous data,
between page sharing, paging, tmem, and so on, is a good one.  But
that's not what we have now.  And that's not even what you're trying
to promote.  Instead, you're trying to push a single hypercall that
you think will be necessary for such a scheduler.

Doesn't it make sense to *first* talk about your grand vision and come
up with a reasonable plan for it, *then* propose an implementation?
If in the course of your 15-patch series introducing a "memory
scheduler", you also introduce a "reservation" hypercall, then
everyone can see exactly what it accomplishes, and actually see if
it's necessary, or if some other design would work better.

Does that make sense?

If I still haven't understood where you're coming from, then I am
sorry; but I have tried pretty hard, and I'm not the only one having
that problem.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 11:49:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 11:49:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO5eI-0001zZ-MC; Tue, 16 Oct 2012 11:49:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO5eH-0001zU-98
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 11:49:25 +0000
Received: from [85.158.139.83:40772] by server-4.bemta-5.messagelabs.com id
	05/B4-01455-4C94D705; Tue, 16 Oct 2012 11:49:24 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1350388162!21003466!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25570 invoked from network); 16 Oct 2012 11:49:23 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 11:49:23 -0000
Received: by mail-vb0-f45.google.com with SMTP id p1so7875866vbi.32
	for ; Tue, 16 Oct 2012 04:49:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=UQxVwfH0VALuCpBApHS/2woD/VDpy0CGiGnQ8ZZPdNA=;
	b=hRBDWjVvrpGaMsPM7I8wXNc3cT2VD3MJ6TibiIpwnNfUuVxgobVMYAiFnv5TkrYeh3
	aPOgVvCFzR7em1DVD7CdcIZHHskdVv3tSAcrEwbchc1D0TYVzBxcR9YBkYghFQTkj0je
	yWch9t+TkpXc4gBakupKV9ciuOGkGeZCanR9k1mJHSR6yS29YfO9rCCdGL7NDb6P1ASl
	C3ir/DDeQuhqXq/Hv+mcnQDYchGOhZdBoaRGYNkmnNm8NjSkT4QbL4bK/4CD/7GD+36w
	0pmw/iMpKzHo/f0uxFSEX/LsQjb9iyiXtdmtLRXnwsT+RQmCbITxJqaEGRZOwxAOA6G9
	kV9Q==
MIME-Version: 1.0
Received: by 10.52.69.47 with SMTP id b15mr6770232vdu.116.1350388162147; Tue,
	16 Oct 2012 04:49:22 -0700 (PDT)
Received: by 10.58.231.138 with HTTP; Tue, 16 Oct 2012 04:49:21 -0700 (PDT)
In-Reply-To: <58b5a25d-ccdd-4d0c-a0d9-9c249825f7f1@default>
References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default>
	<20581.55931.246130.308384@mariner.uk.xensource.com>
	<8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default>
	<20121002091017.GA95926@ocelot.phlegethon.org>
	<66cc0085-1216-40f7-8059-eaf615202c12@default>
	<20121002201624.GA98445@ocelot.phlegethon.org>
	
	<20121004100645.GC38243@ocelot.phlegethon.org>
	<1349345864.650.247.camel@zakaz.uk.xensource.com>
	<239799F4-AF29-494F-86D2-ADF45ACA8792@gridcentric.ca>
	<3e5cf0ba-4241-4f00-bef6-aaff2cc23419@default>
	<506EC710.3020606@eu.citrix.com>
	<58b5a25d-ccdd-4d0c-a0d9-9c249825f7f1@default>
Date: Tue, 16 Oct 2012 12:49:21 +0100
X-Google-Sender-Auth: Smjd4N6rs2bcOL9G22HzOOFX1LE
Message-ID: 
From: George Dunlap 
To: Dan Magenheimer 
Cc: Olaf Hering , "Keir \(Xen.org\)" ,
	Ian Campbell ,
	Konrad Wilk ,
	Andres Lagar-Cavilla ,
	"Tim \(Xen.org\)" , xen-devel@lists.xen.org,
	George Shuklin ,
	Dario Faggioli , Kurt Hackel ,
	Ian Jackson 
Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and
	xl)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 8, 2012 at 2:02 AM, Dan Magenheimer
 wrote:
> Tmem really is a breakthrough on memory management in a virtualized
> system.  I realize that many people are in the "if it doesn't
> work on Windows, I don't care" camp.  And others never thought
> it would make it into upstream Linux (or don't care because it isn't
> completely functional in any distros yet... other than Oracle's..
> but since all parts are now upstream, it will be soon).  But there
> probably are also many that just don't understand it... I guess I need
> to work on fixing that.  Any thoughts on how to start?

Well, I'm sorry to say this, but to start I think you need to work on
your communication.  I had read this entire thread 2 or 3 times before
writing my last response; and I have now read this e-mail half a dozen
times, and I'm still don't have a good idea what it is you're talking
about.  If I didn't respect you, I would have just given up on the 2nd
try.

In my summary, I mentioned just 2 things: the problem of domain
creation, and the solution of a hypercall to allocate a big chunk of
memory to a domain.  You answered by saying it was a good summary.
But then you said:

> I'm just proposing an extension to the
> existing mechanism and I am quite convinced that the hypervisor must
> be involved (e.g. a new hypercall) for the extension to work properly.

Now you're talking about an extension... then you mention a "memory
scheduler" (which we don't yet have), and say:

> ...there is inadequate information from
> any VM to drive automatic memory allocation decisions and, even if
> there was, it just doesn't scale.

But you don't say where or who *could* have adequate information;
which again hints at something else which you have in mind, but you
haven't actually talked about very explicitly yet.  If you have been
trying to talk about it, and it wasn't in my summary, why didn't you
say something about it, instead of saying, "Yes that's right"?  And if
you haven't talked about it, why are you speaking as though we all
know already what you're talking about?

Furthermore, you say things like this:

> IMHO, the example you give for asking a memory controller for GiB
> of memory is equally silly.  Outside of some geek with a handful
> of VMs on a single machine, there is inadequate information from
> any VM to drive automatic memory allocation decisions and, even if
> there was, it just doesn't scale.  It doesn't scale either up, to
> many VMs across many physical machines, or down, to instantaneous
> needs of one-page-at-a-time requests for unsharing or for tmem.

What do you mean, "doesn't scale up or across"?  Why not?  Why is
there inadequate information inside dom0 for a toolstack-based memory
controller?  And if there's not enough information there, who *does*
have the information?  It's just a bunch of vague assertions with no
justification and no alternative proposed.  It doesn't bring any light
to the discussion (which is no doubt why the thread has died without
conclusion).

Nor does saying "see above" and "see below", when "above" and "below"
are still equally unenlightening.

Maybe your grand designs for a "memory scheduler", where memory pages
hop back and forth at millisecond quanta based on instantaneous data,
between page sharing, paging, tmem, and so on, is a good one.  But
that's not what we have now.  And that's not even what you're trying
to promote.  Instead, you're trying to push a single hypercall that
you think will be necessary for such a scheduler.

Doesn't it make sense to *first* talk about your grand vision and come
up with a reasonable plan for it, *then* propose an implementation?
If in the course of your 15-patch series introducing a "memory
scheduler", you also introduce a "reservation" hypercall, then
everyone can see exactly what it accomplishes, and actually see if
it's necessary, or if some other design would work better.

Does that make sense?

If I still haven't understood where you're coming from, then I am
sorry; but I have tried pretty hard, and I'm not the only one having
that problem.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 12:19:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 12:19:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO66q-0002Hw-MY; Tue, 16 Oct 2012 12:18:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO66p-0002Hr-M8
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 12:18:55 +0000
Received: from [85.158.143.35:15175] by server-1.bemta-4.messagelabs.com id
	17/EE-19134-EA05D705; Tue, 16 Oct 2012 12:18:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1350389934!14208305!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2MDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27183 invoked from network); 16 Oct 2012 12:18:54 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-21.messagelabs.com with SMTP;
	16 Oct 2012 12:18:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 16 Oct 2012 13:21:30 +0100
Message-Id: <507D6CCC02000078000A1B07@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 16 Oct 2012 13:18:52 +0100
From: "Jan Beulich" 
To: "xen-devel" 
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartA99889BC.0__="
Subject: [Xen-devel] [PATCH] linux-2.6.18/xenbus: fix overflow check in
 xenbus_dev_write()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartA99889BC.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Reported-by: Dan Carpenter 
Signed-off-by: Jan Beulich 

--- a/drivers/xen/xenbus/xenbus_dev.c
+++ b/drivers/xen/xenbus/xenbus_dev.c
@@ -239,7 +239,7 @@ static ssize_t xenbus_dev_write(struct f
 	if (!is_xenstored_ready())
 		return -ENODEV;
=20
-	if ((len + u->len) > sizeof(u->u.buffer)) {
+	if (len > sizeof(u->u.buffer) - u->len) {
 		rc =3D -EINVAL;
 		goto out;
 	}




--=__PartA99889BC.0__=
Content-Type: text/plain; name="xen-xenbus-dev-write-buflen.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-xenbus-dev-write-buflen.patch"

xenbus: fix overflow check in xenbus_dev_write()=0A=0AReported-by: Dan =
Carpenter =0ASigned-off-by: Jan Beulich =
=0A=0A--- a/drivers/xen/xenbus/xenbus_dev.c=0A+++ =
b/drivers/xen/xenbus/xenbus_dev.c=0A@@ -239,7 +239,7 @@ static ssize_t =
xenbus_dev_write(struct f=0A 	if (!is_xenstored_ready())=0A 		=
return -ENODEV;=0A =0A-	if ((len + u->len) > sizeof(u->u.buffer)) {=0A+	if =
(len > sizeof(u->u.buffer) - u->len) {=0A 		rc =3D -EINVAL;=0A =
		goto out;=0A 	}=0A
--=__PartA99889BC.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__PartA99889BC.0__=--


From xen-devel-bounces@lists.xen.org Tue Oct 16 12:19:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 12:19:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO66q-0002Hw-MY; Tue, 16 Oct 2012 12:18:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO66p-0002Hr-M8
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 12:18:55 +0000
Received: from [85.158.143.35:15175] by server-1.bemta-4.messagelabs.com id
	17/EE-19134-EA05D705; Tue, 16 Oct 2012 12:18:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1350389934!14208305!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2MDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27183 invoked from network); 16 Oct 2012 12:18:54 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-21.messagelabs.com with SMTP;
	16 Oct 2012 12:18:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 16 Oct 2012 13:21:30 +0100
Message-Id: <507D6CCC02000078000A1B07@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 16 Oct 2012 13:18:52 +0100
From: "Jan Beulich" 
To: "xen-devel" 
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartA99889BC.0__="
Subject: [Xen-devel] [PATCH] linux-2.6.18/xenbus: fix overflow check in
 xenbus_dev_write()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartA99889BC.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Reported-by: Dan Carpenter 
Signed-off-by: Jan Beulich 

--- a/drivers/xen/xenbus/xenbus_dev.c
+++ b/drivers/xen/xenbus/xenbus_dev.c
@@ -239,7 +239,7 @@ static ssize_t xenbus_dev_write(struct f
 	if (!is_xenstored_ready())
 		return -ENODEV;
=20
-	if ((len + u->len) > sizeof(u->u.buffer)) {
+	if (len > sizeof(u->u.buffer) - u->len) {
 		rc =3D -EINVAL;
 		goto out;
 	}




--=__PartA99889BC.0__=
Content-Type: text/plain; name="xen-xenbus-dev-write-buflen.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-xenbus-dev-write-buflen.patch"

xenbus: fix overflow check in xenbus_dev_write()=0A=0AReported-by: Dan =
Carpenter =0ASigned-off-by: Jan Beulich =
=0A=0A--- a/drivers/xen/xenbus/xenbus_dev.c=0A+++ =
b/drivers/xen/xenbus/xenbus_dev.c=0A@@ -239,7 +239,7 @@ static ssize_t =
xenbus_dev_write(struct f=0A 	if (!is_xenstored_ready())=0A 		=
return -ENODEV;=0A =0A-	if ((len + u->len) > sizeof(u->u.buffer)) {=0A+	if =
(len > sizeof(u->u.buffer) - u->len) {=0A 		rc =3D -EINVAL;=0A =
		goto out;=0A 	}=0A
--=__PartA99889BC.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__PartA99889BC.0__=--


From xen-devel-bounces@lists.xen.org Tue Oct 16 12:29:46 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 12:29:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO6Gv-0002Ro-W7; Tue, 16 Oct 2012 12:29:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO6Gu-0002Rj-NA
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 12:29:21 +0000
Received: from [85.158.139.211:47226] by server-1.bemta-5.messagelabs.com id
	2A/F5-21640-0235D705; Tue, 16 Oct 2012 12:29:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1350390559!22505914!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2MDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3342 invoked from network); 16 Oct 2012 12:29:19 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-206.messagelabs.com with SMTP;
	16 Oct 2012 12:29:19 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 16 Oct 2012 13:31:54 +0100
Message-Id: <507D6F3D02000078000A1B13@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 16 Oct 2012 13:29:17 +0100
From: "Jan Beulich" 
To: "xen-devel" 
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part1B2A3B0D.0__="
Cc: Dan Carpenter 
Subject: [Xen-devel] [PATCH] linux-2.6.18: fix hypercall fallback code for
 very old hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part1B2A3B0D.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

While copying the argument structures in HYPERVISOR_event_channel_op()
and HYPERVISOR_physdev_op() into the local variable is sufficiently
safe even if the actual structure is smaller than the container one,
copying back eventual output values the same way isn't: This may
collide with on-stack variables (particularly "rc") which may change
between the first and second memcpy() (i.e. the second memcpy() could
discard that change).

Move the fallback code into out-of-line functions, and handle all of
the operations known by this old a hypervisor individually: Some don't
require copying back anything at all, and for the rest use the
individual argument structures' sizes rather than the containter's.

Reported-by: Dan Carpenter 
Signed-off-by: Jan Beulich 

--- a/drivers/xen/core/Makefile
+++ b/drivers/xen/core/Makefile
@@ -2,7 +2,7 @@
 # Makefile for the linux kernel.
 #
=20
-obj-y :=3D evtchn.o gnttab.o features.o reboot.o machine_reboot.o
+obj-y :=3D evtchn.o gnttab.o features.o reboot.o machine_reboot.o =
fallback.o
=20
 obj-$(CONFIG_PCI)		+=3D pci.o
 obj-$(CONFIG_XEN_PRIVILEGED_GUEST) +=3D firmware.o
--- /dev/null
+++ b/drivers/xen/core/fallback.c
@@ -0,0 +1,88 @@
+#include 
+#include 
+#include 
+#include 
+
+#if CONFIG_XEN_COMPAT <=3D 0x030002
+
+#include 
+#include 
+
+int HYPERVISOR_event_channel_op_compat(int cmd, void *arg)
+{
+	struct evtchn_op op;
+	int rc;
+
+	op.cmd =3D cmd;
+	memcpy(&op.u, arg, sizeof(op.u));
+	rc =3D _hypercall1(int, event_channel_op_compat, &op);
+
+	switch (cmd) {
+	case EVTCHNOP_close:
+	case EVTCHNOP_send:
+	case EVTCHNOP_bind_vcpu:
+	case EVTCHNOP_unmask:
+		/* no output */
+		break;
+
+#define COPY_BACK(eop) \
+	case EVTCHNOP_##eop: \
+		memcpy(arg, &op.u.eop, sizeof(op.u.eop)); \
+		break
+
+	COPY_BACK(bind_interdomain);
+	COPY_BACK(bind_virq);
+	COPY_BACK(bind_pirq);
+	COPY_BACK(status);
+	COPY_BACK(alloc_unbound);
+	COPY_BACK(bind_ipi);
+#undef COPY_BACK
+
+	default:
+		WARN_ON(rc !=3D -ENOSYS);
+		break;
+	}
+
+	return rc;
+}
+
+int HYPERVISOR_physdev_op_compat(int cmd, void *arg)
+{
+	struct physdev_op op;
+	int rc;
+
+	op.cmd =3D cmd;
+	memcpy(&op.u, arg, sizeof(op.u));
+	rc =3D _hypercall1(int, physdev_op_compat, &op);
+
+	switch (cmd) {
+	case PHYSDEVOP_IRQ_UNMASK_NOTIFY:
+	case PHYSDEVOP_set_iopl:
+	case PHYSDEVOP_set_iobitmap:
+	case PHYSDEVOP_apic_write:
+		/* no output */
+		break;
+
+#define COPY_BACK(pop) \
+	case PHYSDEVOP_##pop: \
+		memcpy(arg, &op.u.pop, sizeof(op.u.pop)); \
+		break
+
+	COPY_BACK(irq_status_query);
+#define apic_read apic_op
+	COPY_BACK(apic_read);
+#undef apic_read
+#define ASSIGN_VECTOR irq_op
+	COPY_BACK(ASSIGN_VECTOR);
+#undef ASSIGN_VECTOR
+#undef COPY_BACK
+
+	default:
+		WARN_ON(rc !=3D -ENOSYS);
+		break;
+	}
+
+	return rc;
+}
+
+#endif /* CONFIG_XEN_COMPAT <=3D 0x030002 */
--- a/include/asm-i386/mach-xen/asm/hypercall.h
+++ b/include/asm-i386/mach-xen/asm/hypercall.h
@@ -33,7 +33,6 @@
 #ifndef __HYPERCALL_H__
 #define __HYPERCALL_H__
=20
-#include  /* memcpy() */
 #include 
=20
 #ifndef __HYPERVISOR_H__
@@ -128,6 +127,11 @@
 	__res;							\
 })
=20
+#if CONFIG_XEN_COMPAT <=3D 0x030002
+int __must_check HYPERVISOR_event_channel_op_compat(int, void *);
+int __must_check HYPERVISOR_physdev_op_compat(int, void *);
+#endif
+
 static inline int __must_check
 HYPERVISOR_set_trap_table(
 	const trap_info_t *table)
@@ -267,13 +271,8 @@ HYPERVISOR_event_channel_op(
 	int rc =3D _hypercall2(int, event_channel_op, cmd, arg);
=20
 #if CONFIG_XEN_COMPAT <=3D 0x030002
-	if (unlikely(rc =3D=3D -ENOSYS)) {
-		struct evtchn_op op;
-		op.cmd =3D cmd;
-		memcpy(&op.u, arg, sizeof(op.u));
-		rc =3D _hypercall1(int, event_channel_op_compat, &op);
-		memcpy(arg, &op.u, sizeof(op.u));
-	}
+	if (unlikely(rc =3D=3D -ENOSYS))
+		rc =3D HYPERVISOR_event_channel_op_compat(cmd, arg);
 #endif
=20
 	return rc;
@@ -300,13 +299,8 @@ HYPERVISOR_physdev_op(
 	int rc =3D _hypercall2(int, physdev_op, cmd, arg);
=20
 #if CONFIG_XEN_COMPAT <=3D 0x030002
-	if (unlikely(rc =3D=3D -ENOSYS)) {
-		struct physdev_op op;
-		op.cmd =3D cmd;
-		memcpy(&op.u, arg, sizeof(op.u));
-		rc =3D _hypercall1(int, physdev_op_compat, &op);
-		memcpy(arg, &op.u, sizeof(op.u));
-	}
+	if (unlikely(rc =3D=3D -ENOSYS))
+		rc =3D HYPERVISOR_physdev_op_compat(cmd, arg);
 #endif
=20
 	return rc;
--- a/include/asm-i386/mach-xen/asm/hypervisor.h
+++ b/include/asm-i386/mach-xen/asm/hypervisor.h
@@ -39,8 +39,6 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
 #include 



--=__Part1B2A3B0D.0__=
Content-Type: text/plain; name="xen-hypercall-fallback.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-hypercall-fallback.patch"

fix hypercall fallback code for very old hypervisors=0A=0AWhile copying =
the argument structures in HYPERVISOR_event_channel_op()=0Aand HYPERVISOR_p=
hysdev_op() into the local variable is sufficiently=0Asafe even if the =
actual structure is smaller than the container one,=0Acopying back =
eventual output values the same way isn't: This may=0Acollide with =
on-stack variables (particularly "rc") which may change=0Abetween the =
first and second memcpy() (i.e. the second memcpy() could=0Adiscard that =
change).=0A=0AMove the fallback code into out-of-line functions, and =
handle all of=0Athe operations known by this old a hypervisor individually:=
 Some don't=0Arequire copying back anything at all, and for the rest use =
the=0Aindividual argument structures' sizes rather than the containter's.=
=0A=0AReported-by: Dan Carpenter =0ASigned-off-by=
: Jan Beulich =0A=0A--- a/drivers/xen/core/Makefile=0A++=
+ b/drivers/xen/core/Makefile=0A@@ -2,7 +2,7 @@=0A # Makefile for the =
linux kernel.=0A #=0A =0A-obj-y :=3D evtchn.o gnttab.o features.o reboot.o =
machine_reboot.o=0A+obj-y :=3D evtchn.o gnttab.o features.o reboot.o =
machine_reboot.o fallback.o=0A =0A obj-$(CONFIG_PCI)		+=3D =
pci.o=0A obj-$(CONFIG_XEN_PRIVILEGED_GUEST) +=3D firmware.o=0A--- =
/dev/null=0A+++ b/drivers/xen/core/fallback.c=0A@@ -0,0 +1,88 @@=0A+#includ=
e =0A+#include =0A+#include =0A+=
#include =0A+=0A+#if CONFIG_XEN_COMPAT <=3D 0x030002=0A+=
=0A+#include =0A+#include =0A+=0A+int HYPERVISOR_event_channel_op_compat(int cmd, void =
*arg)=0A+{=0A+	struct evtchn_op op;=0A+	int rc;=0A+=0A+	op.cmd =3D =
cmd;=0A+	memcpy(&op.u, arg, sizeof(op.u));=0A+	rc =3D _hypercall1(=
int, event_channel_op_compat, &op);=0A+=0A+	switch (cmd) {=0A+	=
case EVTCHNOP_close:=0A+	case EVTCHNOP_send:=0A+	case EVTCHNOP_bind_=
vcpu:=0A+	case EVTCHNOP_unmask:=0A+		/* no output =
*/=0A+		break;=0A+=0A+#define COPY_BACK(eop) \=0A+	case =
EVTCHNOP_##eop: \=0A+		memcpy(arg, &op.u.eop, sizeof(op.u.eop)); =
\=0A+		break=0A+=0A+	COPY_BACK(bind_interdomain);=0A+	=
COPY_BACK(bind_virq);=0A+	COPY_BACK(bind_pirq);=0A+	COPY_BACK(s=
tatus);=0A+	COPY_BACK(alloc_unbound);=0A+	COPY_BACK(bind_ipi);=0A+#un=
def COPY_BACK=0A+=0A+	default:=0A+		WARN_ON(rc !=3D =
-ENOSYS);=0A+		break;=0A+	}=0A+=0A+	return rc;=0A+}=0A+=
=0A+int HYPERVISOR_physdev_op_compat(int cmd, void *arg)=0A+{=0A+	=
struct physdev_op op;=0A+	int rc;=0A+=0A+	op.cmd =3D cmd;=0A+	=
memcpy(&op.u, arg, sizeof(op.u));=0A+	rc =3D _hypercall1(int, physdev_op_=
compat, &op);=0A+=0A+	switch (cmd) {=0A+	case PHYSDEVOP_IRQ_UNMASK_N=
OTIFY:=0A+	case PHYSDEVOP_set_iopl:=0A+	case PHYSDEVOP_set_iobitmap=
:=0A+	case PHYSDEVOP_apic_write:=0A+		/* no output */=0A+		=
break;=0A+=0A+#define COPY_BACK(pop) \=0A+	case PHYSDEVOP_##pop: =
\=0A+		memcpy(arg, &op.u.pop, sizeof(op.u.pop)); \=0A+		=
break=0A+=0A+	COPY_BACK(irq_status_query);=0A+#define apic_read =
apic_op=0A+	COPY_BACK(apic_read);=0A+#undef apic_read=0A+#define =
ASSIGN_VECTOR irq_op=0A+	COPY_BACK(ASSIGN_VECTOR);=0A+#undef =
ASSIGN_VECTOR=0A+#undef COPY_BACK=0A+=0A+	default:=0A+		=
WARN_ON(rc !=3D -ENOSYS);=0A+		break;=0A+	}=0A+=0A+	=
return rc;=0A+}=0A+=0A+#endif /* CONFIG_XEN_COMPAT <=3D 0x030002 */=0A--- =
a/include/asm-i386/mach-xen/asm/hypercall.h=0A+++ b/include/asm-i386/mach-x=
en/asm/hypercall.h=0A@@ -33,7 +33,6 @@=0A #ifndef __HYPERCALL_H__=0A =
#define __HYPERCALL_H__=0A =0A-#include  /* memcpy() */=0A =
#include =0A =0A #ifndef __HYPERVISOR_H__=0A@@ -128,6 =
+127,11 @@=0A 	__res;							=
\=0A })=0A =0A+#if CONFIG_XEN_COMPAT <=3D 0x030002=0A+int __must_check =
HYPERVISOR_event_channel_op_compat(int, void *);=0A+int __must_check =
HYPERVISOR_physdev_op_compat(int, void *);=0A+#endif=0A+=0A static inline =
int __must_check=0A HYPERVISOR_set_trap_table(=0A 	const trap_info_t =
*table)=0A@@ -267,13 +271,8 @@ HYPERVISOR_event_channel_op(=0A 	int rc =3D =
_hypercall2(int, event_channel_op, cmd, arg);=0A =0A #if CONFIG_XEN_COMPAT =
<=3D 0x030002=0A-	if (unlikely(rc =3D=3D -ENOSYS)) {=0A-		=
struct evtchn_op op;=0A-		op.cmd =3D cmd;=0A-		=
memcpy(&op.u, arg, sizeof(op.u));=0A-		rc =3D _hypercall1(int, =
event_channel_op_compat, &op);=0A-		memcpy(arg, &op.u, =
sizeof(op.u));=0A-	}=0A+	if (unlikely(rc =3D=3D -ENOSYS))=0A+		=
rc =3D HYPERVISOR_event_channel_op_compat(cmd, arg);=0A #endif=0A =0A 	=
return rc;=0A@@ -300,13 +299,8 @@ HYPERVISOR_physdev_op(=0A 	int rc =3D =
_hypercall2(int, physdev_op, cmd, arg);=0A =0A #if CONFIG_XEN_COMPAT <=3D =
0x030002=0A-	if (unlikely(rc =3D=3D -ENOSYS)) {=0A-		struct =
physdev_op op;=0A-		op.cmd =3D cmd;=0A-		memcpy(&op.=
u, arg, sizeof(op.u));=0A-		rc =3D _hypercall1(int, physdev_op_=
compat, &op);=0A-		memcpy(arg, &op.u, sizeof(op.u));=0A-	=
}=0A+	if (unlikely(rc =3D=3D -ENOSYS))=0A+		rc =3D HYPERVISOR_p=
hysdev_op_compat(cmd, arg);=0A #endif=0A =0A 	return rc;=0A--- a/include/=
asm-i386/mach-xen/asm/hypervisor.h=0A+++ b/include/asm-i386/mach-xen/asm/hy=
pervisor.h=0A@@ -39,8 +39,6 @@=0A #include =0A #include =
=0A #include =0A-#include =
=0A-#include =0A =
#include =0A #include =0A =
#include =0A
--=__Part1B2A3B0D.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__Part1B2A3B0D.0__=--


From xen-devel-bounces@lists.xen.org Tue Oct 16 12:29:46 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 12:29:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO6Gv-0002Ro-W7; Tue, 16 Oct 2012 12:29:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO6Gu-0002Rj-NA
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 12:29:21 +0000
Received: from [85.158.139.211:47226] by server-1.bemta-5.messagelabs.com id
	2A/F5-21640-0235D705; Tue, 16 Oct 2012 12:29:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1350390559!22505914!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2MDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3342 invoked from network); 16 Oct 2012 12:29:19 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-206.messagelabs.com with SMTP;
	16 Oct 2012 12:29:19 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 16 Oct 2012 13:31:54 +0100
Message-Id: <507D6F3D02000078000A1B13@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 16 Oct 2012 13:29:17 +0100
From: "Jan Beulich" 
To: "xen-devel" 
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part1B2A3B0D.0__="
Cc: Dan Carpenter 
Subject: [Xen-devel] [PATCH] linux-2.6.18: fix hypercall fallback code for
 very old hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part1B2A3B0D.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

While copying the argument structures in HYPERVISOR_event_channel_op()
and HYPERVISOR_physdev_op() into the local variable is sufficiently
safe even if the actual structure is smaller than the container one,
copying back eventual output values the same way isn't: This may
collide with on-stack variables (particularly "rc") which may change
between the first and second memcpy() (i.e. the second memcpy() could
discard that change).

Move the fallback code into out-of-line functions, and handle all of
the operations known by this old a hypervisor individually: Some don't
require copying back anything at all, and for the rest use the
individual argument structures' sizes rather than the containter's.

Reported-by: Dan Carpenter 
Signed-off-by: Jan Beulich 

--- a/drivers/xen/core/Makefile
+++ b/drivers/xen/core/Makefile
@@ -2,7 +2,7 @@
 # Makefile for the linux kernel.
 #
=20
-obj-y :=3D evtchn.o gnttab.o features.o reboot.o machine_reboot.o
+obj-y :=3D evtchn.o gnttab.o features.o reboot.o machine_reboot.o =
fallback.o
=20
 obj-$(CONFIG_PCI)		+=3D pci.o
 obj-$(CONFIG_XEN_PRIVILEGED_GUEST) +=3D firmware.o
--- /dev/null
+++ b/drivers/xen/core/fallback.c
@@ -0,0 +1,88 @@
+#include 
+#include 
+#include 
+#include 
+
+#if CONFIG_XEN_COMPAT <=3D 0x030002
+
+#include 
+#include 
+
+int HYPERVISOR_event_channel_op_compat(int cmd, void *arg)
+{
+	struct evtchn_op op;
+	int rc;
+
+	op.cmd =3D cmd;
+	memcpy(&op.u, arg, sizeof(op.u));
+	rc =3D _hypercall1(int, event_channel_op_compat, &op);
+
+	switch (cmd) {
+	case EVTCHNOP_close:
+	case EVTCHNOP_send:
+	case EVTCHNOP_bind_vcpu:
+	case EVTCHNOP_unmask:
+		/* no output */
+		break;
+
+#define COPY_BACK(eop) \
+	case EVTCHNOP_##eop: \
+		memcpy(arg, &op.u.eop, sizeof(op.u.eop)); \
+		break
+
+	COPY_BACK(bind_interdomain);
+	COPY_BACK(bind_virq);
+	COPY_BACK(bind_pirq);
+	COPY_BACK(status);
+	COPY_BACK(alloc_unbound);
+	COPY_BACK(bind_ipi);
+#undef COPY_BACK
+
+	default:
+		WARN_ON(rc !=3D -ENOSYS);
+		break;
+	}
+
+	return rc;
+}
+
+int HYPERVISOR_physdev_op_compat(int cmd, void *arg)
+{
+	struct physdev_op op;
+	int rc;
+
+	op.cmd =3D cmd;
+	memcpy(&op.u, arg, sizeof(op.u));
+	rc =3D _hypercall1(int, physdev_op_compat, &op);
+
+	switch (cmd) {
+	case PHYSDEVOP_IRQ_UNMASK_NOTIFY:
+	case PHYSDEVOP_set_iopl:
+	case PHYSDEVOP_set_iobitmap:
+	case PHYSDEVOP_apic_write:
+		/* no output */
+		break;
+
+#define COPY_BACK(pop) \
+	case PHYSDEVOP_##pop: \
+		memcpy(arg, &op.u.pop, sizeof(op.u.pop)); \
+		break
+
+	COPY_BACK(irq_status_query);
+#define apic_read apic_op
+	COPY_BACK(apic_read);
+#undef apic_read
+#define ASSIGN_VECTOR irq_op
+	COPY_BACK(ASSIGN_VECTOR);
+#undef ASSIGN_VECTOR
+#undef COPY_BACK
+
+	default:
+		WARN_ON(rc !=3D -ENOSYS);
+		break;
+	}
+
+	return rc;
+}
+
+#endif /* CONFIG_XEN_COMPAT <=3D 0x030002 */
--- a/include/asm-i386/mach-xen/asm/hypercall.h
+++ b/include/asm-i386/mach-xen/asm/hypercall.h
@@ -33,7 +33,6 @@
 #ifndef __HYPERCALL_H__
 #define __HYPERCALL_H__
=20
-#include  /* memcpy() */
 #include 
=20
 #ifndef __HYPERVISOR_H__
@@ -128,6 +127,11 @@
 	__res;							\
 })
=20
+#if CONFIG_XEN_COMPAT <=3D 0x030002
+int __must_check HYPERVISOR_event_channel_op_compat(int, void *);
+int __must_check HYPERVISOR_physdev_op_compat(int, void *);
+#endif
+
 static inline int __must_check
 HYPERVISOR_set_trap_table(
 	const trap_info_t *table)
@@ -267,13 +271,8 @@ HYPERVISOR_event_channel_op(
 	int rc =3D _hypercall2(int, event_channel_op, cmd, arg);
=20
 #if CONFIG_XEN_COMPAT <=3D 0x030002
-	if (unlikely(rc =3D=3D -ENOSYS)) {
-		struct evtchn_op op;
-		op.cmd =3D cmd;
-		memcpy(&op.u, arg, sizeof(op.u));
-		rc =3D _hypercall1(int, event_channel_op_compat, &op);
-		memcpy(arg, &op.u, sizeof(op.u));
-	}
+	if (unlikely(rc =3D=3D -ENOSYS))
+		rc =3D HYPERVISOR_event_channel_op_compat(cmd, arg);
 #endif
=20
 	return rc;
@@ -300,13 +299,8 @@ HYPERVISOR_physdev_op(
 	int rc =3D _hypercall2(int, physdev_op, cmd, arg);
=20
 #if CONFIG_XEN_COMPAT <=3D 0x030002
-	if (unlikely(rc =3D=3D -ENOSYS)) {
-		struct physdev_op op;
-		op.cmd =3D cmd;
-		memcpy(&op.u, arg, sizeof(op.u));
-		rc =3D _hypercall1(int, physdev_op_compat, &op);
-		memcpy(arg, &op.u, sizeof(op.u));
-	}
+	if (unlikely(rc =3D=3D -ENOSYS))
+		rc =3D HYPERVISOR_physdev_op_compat(cmd, arg);
 #endif
=20
 	return rc;
--- a/include/asm-i386/mach-xen/asm/hypervisor.h
+++ b/include/asm-i386/mach-xen/asm/hypervisor.h
@@ -39,8 +39,6 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
 #include 



--=__Part1B2A3B0D.0__=
Content-Type: text/plain; name="xen-hypercall-fallback.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-hypercall-fallback.patch"

fix hypercall fallback code for very old hypervisors=0A=0AWhile copying =
the argument structures in HYPERVISOR_event_channel_op()=0Aand HYPERVISOR_p=
hysdev_op() into the local variable is sufficiently=0Asafe even if the =
actual structure is smaller than the container one,=0Acopying back =
eventual output values the same way isn't: This may=0Acollide with =
on-stack variables (particularly "rc") which may change=0Abetween the =
first and second memcpy() (i.e. the second memcpy() could=0Adiscard that =
change).=0A=0AMove the fallback code into out-of-line functions, and =
handle all of=0Athe operations known by this old a hypervisor individually:=
 Some don't=0Arequire copying back anything at all, and for the rest use =
the=0Aindividual argument structures' sizes rather than the containter's.=
=0A=0AReported-by: Dan Carpenter =0ASigned-off-by=
: Jan Beulich =0A=0A--- a/drivers/xen/core/Makefile=0A++=
+ b/drivers/xen/core/Makefile=0A@@ -2,7 +2,7 @@=0A # Makefile for the =
linux kernel.=0A #=0A =0A-obj-y :=3D evtchn.o gnttab.o features.o reboot.o =
machine_reboot.o=0A+obj-y :=3D evtchn.o gnttab.o features.o reboot.o =
machine_reboot.o fallback.o=0A =0A obj-$(CONFIG_PCI)		+=3D =
pci.o=0A obj-$(CONFIG_XEN_PRIVILEGED_GUEST) +=3D firmware.o=0A--- =
/dev/null=0A+++ b/drivers/xen/core/fallback.c=0A@@ -0,0 +1,88 @@=0A+#includ=
e =0A+#include =0A+#include =0A+=
#include =0A+=0A+#if CONFIG_XEN_COMPAT <=3D 0x030002=0A+=
=0A+#include =0A+#include =0A+=0A+int HYPERVISOR_event_channel_op_compat(int cmd, void =
*arg)=0A+{=0A+	struct evtchn_op op;=0A+	int rc;=0A+=0A+	op.cmd =3D =
cmd;=0A+	memcpy(&op.u, arg, sizeof(op.u));=0A+	rc =3D _hypercall1(=
int, event_channel_op_compat, &op);=0A+=0A+	switch (cmd) {=0A+	=
case EVTCHNOP_close:=0A+	case EVTCHNOP_send:=0A+	case EVTCHNOP_bind_=
vcpu:=0A+	case EVTCHNOP_unmask:=0A+		/* no output =
*/=0A+		break;=0A+=0A+#define COPY_BACK(eop) \=0A+	case =
EVTCHNOP_##eop: \=0A+		memcpy(arg, &op.u.eop, sizeof(op.u.eop)); =
\=0A+		break=0A+=0A+	COPY_BACK(bind_interdomain);=0A+	=
COPY_BACK(bind_virq);=0A+	COPY_BACK(bind_pirq);=0A+	COPY_BACK(s=
tatus);=0A+	COPY_BACK(alloc_unbound);=0A+	COPY_BACK(bind_ipi);=0A+#un=
def COPY_BACK=0A+=0A+	default:=0A+		WARN_ON(rc !=3D =
-ENOSYS);=0A+		break;=0A+	}=0A+=0A+	return rc;=0A+}=0A+=
=0A+int HYPERVISOR_physdev_op_compat(int cmd, void *arg)=0A+{=0A+	=
struct physdev_op op;=0A+	int rc;=0A+=0A+	op.cmd =3D cmd;=0A+	=
memcpy(&op.u, arg, sizeof(op.u));=0A+	rc =3D _hypercall1(int, physdev_op_=
compat, &op);=0A+=0A+	switch (cmd) {=0A+	case PHYSDEVOP_IRQ_UNMASK_N=
OTIFY:=0A+	case PHYSDEVOP_set_iopl:=0A+	case PHYSDEVOP_set_iobitmap=
:=0A+	case PHYSDEVOP_apic_write:=0A+		/* no output */=0A+		=
break;=0A+=0A+#define COPY_BACK(pop) \=0A+	case PHYSDEVOP_##pop: =
\=0A+		memcpy(arg, &op.u.pop, sizeof(op.u.pop)); \=0A+		=
break=0A+=0A+	COPY_BACK(irq_status_query);=0A+#define apic_read =
apic_op=0A+	COPY_BACK(apic_read);=0A+#undef apic_read=0A+#define =
ASSIGN_VECTOR irq_op=0A+	COPY_BACK(ASSIGN_VECTOR);=0A+#undef =
ASSIGN_VECTOR=0A+#undef COPY_BACK=0A+=0A+	default:=0A+		=
WARN_ON(rc !=3D -ENOSYS);=0A+		break;=0A+	}=0A+=0A+	=
return rc;=0A+}=0A+=0A+#endif /* CONFIG_XEN_COMPAT <=3D 0x030002 */=0A--- =
a/include/asm-i386/mach-xen/asm/hypercall.h=0A+++ b/include/asm-i386/mach-x=
en/asm/hypercall.h=0A@@ -33,7 +33,6 @@=0A #ifndef __HYPERCALL_H__=0A =
#define __HYPERCALL_H__=0A =0A-#include  /* memcpy() */=0A =
#include =0A =0A #ifndef __HYPERVISOR_H__=0A@@ -128,6 =
+127,11 @@=0A 	__res;							=
\=0A })=0A =0A+#if CONFIG_XEN_COMPAT <=3D 0x030002=0A+int __must_check =
HYPERVISOR_event_channel_op_compat(int, void *);=0A+int __must_check =
HYPERVISOR_physdev_op_compat(int, void *);=0A+#endif=0A+=0A static inline =
int __must_check=0A HYPERVISOR_set_trap_table(=0A 	const trap_info_t =
*table)=0A@@ -267,13 +271,8 @@ HYPERVISOR_event_channel_op(=0A 	int rc =3D =
_hypercall2(int, event_channel_op, cmd, arg);=0A =0A #if CONFIG_XEN_COMPAT =
<=3D 0x030002=0A-	if (unlikely(rc =3D=3D -ENOSYS)) {=0A-		=
struct evtchn_op op;=0A-		op.cmd =3D cmd;=0A-		=
memcpy(&op.u, arg, sizeof(op.u));=0A-		rc =3D _hypercall1(int, =
event_channel_op_compat, &op);=0A-		memcpy(arg, &op.u, =
sizeof(op.u));=0A-	}=0A+	if (unlikely(rc =3D=3D -ENOSYS))=0A+		=
rc =3D HYPERVISOR_event_channel_op_compat(cmd, arg);=0A #endif=0A =0A 	=
return rc;=0A@@ -300,13 +299,8 @@ HYPERVISOR_physdev_op(=0A 	int rc =3D =
_hypercall2(int, physdev_op, cmd, arg);=0A =0A #if CONFIG_XEN_COMPAT <=3D =
0x030002=0A-	if (unlikely(rc =3D=3D -ENOSYS)) {=0A-		struct =
physdev_op op;=0A-		op.cmd =3D cmd;=0A-		memcpy(&op.=
u, arg, sizeof(op.u));=0A-		rc =3D _hypercall1(int, physdev_op_=
compat, &op);=0A-		memcpy(arg, &op.u, sizeof(op.u));=0A-	=
}=0A+	if (unlikely(rc =3D=3D -ENOSYS))=0A+		rc =3D HYPERVISOR_p=
hysdev_op_compat(cmd, arg);=0A #endif=0A =0A 	return rc;=0A--- a/include/=
asm-i386/mach-xen/asm/hypervisor.h=0A+++ b/include/asm-i386/mach-xen/asm/hy=
pervisor.h=0A@@ -39,8 +39,6 @@=0A #include =0A #include =
=0A #include =0A-#include =
=0A-#include =0A =
#include =0A #include =0A =
#include =0A
--=__Part1B2A3B0D.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__Part1B2A3B0D.0__=--


From xen-devel-bounces@lists.xen.org Tue Oct 16 13:00:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 13:00:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO6ki-0002kg-Fw; Tue, 16 Oct 2012 13:00:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO6kg-0002kb-LE
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 13:00:06 +0000
Received: from [193.109.254.147:46606] by server-6.bemta-14.messagelabs.com id
	DF/0E-17826-55A5D705; Tue, 16 Oct 2012 13:00:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1350392404!11533297!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQzMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3929 invoked from network); 16 Oct 2012 13:00:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 13:00:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,593,1344211200"; d="scan'208";a="15203278"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Oct 2012 13:00:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 16 Oct 2012 14:00:04 +0100
Message-ID: <1350392403.18058.116.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Jan Beulich 
Date: Tue, 16 Oct 2012 14:00:03 +0100
In-Reply-To: <507D6CCC02000078000A1B07@nat28.tlf.novell.com>
References: <507D6CCC02000078000A1B07@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk ,
	xen-devel 
Subject: Re: [Xen-devel] [PATCH] linux-2.6.18/xenbus: fix overflow check in
 xenbus_dev_write()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-16 at 13:18 +0100, Jan Beulich wrote:
> Reported-by: Dan Carpenter 
> Signed-off-by: Jan Beulich 

Acked-by: Ian Campbell 

CC-ing Konrad since I think that modulo tweaking the path this ought to
apply as is to upstream kernels.

> 
> --- a/drivers/xen/xenbus/xenbus_dev.c
> +++ b/drivers/xen/xenbus/xenbus_dev.c
> @@ -239,7 +239,7 @@ static ssize_t xenbus_dev_write(struct f
>  	if (!is_xenstored_ready())
>  		return -ENODEV;
>  
> -	if ((len + u->len) > sizeof(u->u.buffer)) {
> +	if (len > sizeof(u->u.buffer) - u->len) {
>  		rc = -EINVAL;
>  		goto out;
>  	}
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 13:00:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 13:00:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO6ki-0002kg-Fw; Tue, 16 Oct 2012 13:00:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO6kg-0002kb-LE
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 13:00:06 +0000
Received: from [193.109.254.147:46606] by server-6.bemta-14.messagelabs.com id
	DF/0E-17826-55A5D705; Tue, 16 Oct 2012 13:00:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1350392404!11533297!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQzMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3929 invoked from network); 16 Oct 2012 13:00:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 13:00:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,593,1344211200"; d="scan'208";a="15203278"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Oct 2012 13:00:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 16 Oct 2012 14:00:04 +0100
Message-ID: <1350392403.18058.116.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Jan Beulich 
Date: Tue, 16 Oct 2012 14:00:03 +0100
In-Reply-To: <507D6CCC02000078000A1B07@nat28.tlf.novell.com>
References: <507D6CCC02000078000A1B07@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk ,
	xen-devel 
Subject: Re: [Xen-devel] [PATCH] linux-2.6.18/xenbus: fix overflow check in
 xenbus_dev_write()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-16 at 13:18 +0100, Jan Beulich wrote:
> Reported-by: Dan Carpenter 
> Signed-off-by: Jan Beulich 

Acked-by: Ian Campbell 

CC-ing Konrad since I think that modulo tweaking the path this ought to
apply as is to upstream kernels.

> 
> --- a/drivers/xen/xenbus/xenbus_dev.c
> +++ b/drivers/xen/xenbus/xenbus_dev.c
> @@ -239,7 +239,7 @@ static ssize_t xenbus_dev_write(struct f
>  	if (!is_xenstored_ready())
>  		return -ENODEV;
>  
> -	if ((len + u->len) > sizeof(u->u.buffer)) {
> +	if (len > sizeof(u->u.buffer) - u->len) {
>  		rc = -EINVAL;
>  		goto out;
>  	}
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 13:03:23 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 13:03:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO6nW-0002sP-3C; Tue, 16 Oct 2012 13:03:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO6nU-0002sJ-O4
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 13:03:01 +0000
Received: from [85.158.139.211:17707] by server-12.bemta-5.messagelabs.com id
	FD/1D-26919-30B5D705; Tue, 16 Oct 2012 13:02:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1350392578!22525462!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQzMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31684 invoked from network); 16 Oct 2012 13:02:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 13:02:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,593,1344211200"; d="scan'208";a="15203375"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Oct 2012 13:02:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 16 Oct 2012 14:02:58 +0100
Message-ID: <1350392576.18058.118.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Jan Beulich 
Date: Tue, 16 Oct 2012 14:02:56 +0100
In-Reply-To: <507D6F3D02000078000A1B13@nat28.tlf.novell.com>
References: <507D6F3D02000078000A1B13@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk ,
	Dan Carpenter ,
	xen-devel 
Subject: Re: [Xen-devel] [PATCH] linux-2.6.18: fix hypercall fallback code
 for very old hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-16 at 13:29 +0100, Jan Beulich wrote:
> While copying the argument structures in HYPERVISOR_event_channel_op()
> and HYPERVISOR_physdev_op() into the local variable is sufficiently
> safe even if the actual structure is smaller than the container one,
> copying back eventual output values the same way isn't: This may
> collide with on-stack variables (particularly "rc") which may change
> between the first and second memcpy() (i.e. the second memcpy() could
> discard that change).
> 
> Move the fallback code into out-of-line functions, and handle all of
> the operations known by this old a hypervisor individually: Some don't
> require copying back anything at all, and for the rest use the
> individual argument structures' sizes rather than the containter's.

CC-ing Konrad (and therefore not trimming quotes)

Typo: "containers"

> Reported-by: Dan Carpenter 
> Signed-off-by: Jan Beulich 
> 
> --- a/drivers/xen/core/Makefile
> +++ b/drivers/xen/core/Makefile
> @@ -2,7 +2,7 @@
>  # Makefile for the linux kernel.
>  #
>  
> -obj-y := evtchn.o gnttab.o features.o reboot.o machine_reboot.o
> +obj-y := evtchn.o gnttab.o features.o reboot.o machine_reboot.o fallback.o
>  
>  obj-$(CONFIG_PCI)		+= pci.o
>  obj-$(CONFIG_XEN_PRIVILEGED_GUEST) += firmware.o
> --- /dev/null
> +++ b/drivers/xen/core/fallback.c
> @@ -0,0 +1,88 @@
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#if CONFIG_XEN_COMPAT <= 0x030002
> +
> +#include 
> +#include 
> +
> +int HYPERVISOR_event_channel_op_compat(int cmd, void *arg)
> +{
> +	struct evtchn_op op;
> +	int rc;
> +
> +	op.cmd = cmd;
> +	memcpy(&op.u, arg, sizeof(op.u));
> +	rc = _hypercall1(int, event_channel_op_compat, &op);
> +
> +	switch (cmd) {
> +	case EVTCHNOP_close:
> +	case EVTCHNOP_send:
> +	case EVTCHNOP_bind_vcpu:
> +	case EVTCHNOP_unmask:
> +		/* no output */
> +		break;
> +
> +#define COPY_BACK(eop) \
> +	case EVTCHNOP_##eop: \
> +		memcpy(arg, &op.u.eop, sizeof(op.u.eop)); \
> +		break
> +
> +	COPY_BACK(bind_interdomain);
> +	COPY_BACK(bind_virq);
> +	COPY_BACK(bind_pirq);
> +	COPY_BACK(status);
> +	COPY_BACK(alloc_unbound);
> +	COPY_BACK(bind_ipi);
> +#undef COPY_BACK
> +
> +	default:
> +		WARN_ON(rc != -ENOSYS);
> +		break;
> +	}
> +
> +	return rc;
> +}
> +
> +int HYPERVISOR_physdev_op_compat(int cmd, void *arg)
> +{
> +	struct physdev_op op;
> +	int rc;
> +
> +	op.cmd = cmd;
> +	memcpy(&op.u, arg, sizeof(op.u));
> +	rc = _hypercall1(int, physdev_op_compat, &op);
> +
> +	switch (cmd) {
> +	case PHYSDEVOP_IRQ_UNMASK_NOTIFY:
> +	case PHYSDEVOP_set_iopl:
> +	case PHYSDEVOP_set_iobitmap:
> +	case PHYSDEVOP_apic_write:
> +		/* no output */
> +		break;
> +
> +#define COPY_BACK(pop) \
> +	case PHYSDEVOP_##pop: \
> +		memcpy(arg, &op.u.pop, sizeof(op.u.pop)); \
> +		break
> +
> +	COPY_BACK(irq_status_query);
> +#define apic_read apic_op
> +	COPY_BACK(apic_read);
> +#undef apic_read
> +#define ASSIGN_VECTOR irq_op
> +	COPY_BACK(ASSIGN_VECTOR);
> +#undef ASSIGN_VECTOR
> +#undef COPY_BACK

I think rather than this def/undef dance either a two argument macro or
open coding the two cases would be cleaner.

> +
> +	default:
> +		WARN_ON(rc != -ENOSYS);
> +		break;
> +	}
> +
> +	return rc;
> +}
> +
> +#endif /* CONFIG_XEN_COMPAT <= 0x030002 */
> --- a/include/asm-i386/mach-xen/asm/hypercall.h
> +++ b/include/asm-i386/mach-xen/asm/hypercall.h
> @@ -33,7 +33,6 @@
>  #ifndef __HYPERCALL_H__
>  #define __HYPERCALL_H__
>  
> -#include  /* memcpy() */
>  #include 
>  
>  #ifndef __HYPERVISOR_H__
> @@ -128,6 +127,11 @@
>  	__res;							\
>  })
>  
> +#if CONFIG_XEN_COMPAT <= 0x030002
> +int __must_check HYPERVISOR_event_channel_op_compat(int, void *);
> +int __must_check HYPERVISOR_physdev_op_compat(int, void *);
> +#endif
> +
>  static inline int __must_check
>  HYPERVISOR_set_trap_table(
>  	const trap_info_t *table)
> @@ -267,13 +271,8 @@ HYPERVISOR_event_channel_op(
>  	int rc = _hypercall2(int, event_channel_op, cmd, arg);
>  
>  #if CONFIG_XEN_COMPAT <= 0x030002
> -	if (unlikely(rc == -ENOSYS)) {
> -		struct evtchn_op op;
> -		op.cmd = cmd;
> -		memcpy(&op.u, arg, sizeof(op.u));
> -		rc = _hypercall1(int, event_channel_op_compat, &op);
> -		memcpy(arg, &op.u, sizeof(op.u));
> -	}
> +	if (unlikely(rc == -ENOSYS))
> +		rc = HYPERVISOR_event_channel_op_compat(cmd, arg);
>  #endif
>  
>  	return rc;
> @@ -300,13 +299,8 @@ HYPERVISOR_physdev_op(
>  	int rc = _hypercall2(int, physdev_op, cmd, arg);
>  
>  #if CONFIG_XEN_COMPAT <= 0x030002
> -	if (unlikely(rc == -ENOSYS)) {
> -		struct physdev_op op;
> -		op.cmd = cmd;
> -		memcpy(&op.u, arg, sizeof(op.u));
> -		rc = _hypercall1(int, physdev_op_compat, &op);
> -		memcpy(arg, &op.u, sizeof(op.u));
> -	}
> +	if (unlikely(rc == -ENOSYS))
> +		rc = HYPERVISOR_physdev_op_compat(cmd, arg);
>  #endif
>  
>  	return rc;
> --- a/include/asm-i386/mach-xen/asm/hypervisor.h
> +++ b/include/asm-i386/mach-xen/asm/hypervisor.h
> @@ -39,8 +39,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
> -#include 
>  #include 
>  #include 
>  #include 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 13:03:23 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 13:03:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO6nW-0002sP-3C; Tue, 16 Oct 2012 13:03:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO6nU-0002sJ-O4
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 13:03:01 +0000
Received: from [85.158.139.211:17707] by server-12.bemta-5.messagelabs.com id
	FD/1D-26919-30B5D705; Tue, 16 Oct 2012 13:02:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1350392578!22525462!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQzMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31684 invoked from network); 16 Oct 2012 13:02:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 13:02:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,593,1344211200"; d="scan'208";a="15203375"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Oct 2012 13:02:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 16 Oct 2012 14:02:58 +0100
Message-ID: <1350392576.18058.118.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Jan Beulich 
Date: Tue, 16 Oct 2012 14:02:56 +0100
In-Reply-To: <507D6F3D02000078000A1B13@nat28.tlf.novell.com>
References: <507D6F3D02000078000A1B13@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk ,
	Dan Carpenter ,
	xen-devel 
Subject: Re: [Xen-devel] [PATCH] linux-2.6.18: fix hypercall fallback code
 for very old hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-16 at 13:29 +0100, Jan Beulich wrote:
> While copying the argument structures in HYPERVISOR_event_channel_op()
> and HYPERVISOR_physdev_op() into the local variable is sufficiently
> safe even if the actual structure is smaller than the container one,
> copying back eventual output values the same way isn't: This may
> collide with on-stack variables (particularly "rc") which may change
> between the first and second memcpy() (i.e. the second memcpy() could
> discard that change).
> 
> Move the fallback code into out-of-line functions, and handle all of
> the operations known by this old a hypervisor individually: Some don't
> require copying back anything at all, and for the rest use the
> individual argument structures' sizes rather than the containter's.

CC-ing Konrad (and therefore not trimming quotes)

Typo: "containers"

> Reported-by: Dan Carpenter 
> Signed-off-by: Jan Beulich 
> 
> --- a/drivers/xen/core/Makefile
> +++ b/drivers/xen/core/Makefile
> @@ -2,7 +2,7 @@
>  # Makefile for the linux kernel.
>  #
>  
> -obj-y := evtchn.o gnttab.o features.o reboot.o machine_reboot.o
> +obj-y := evtchn.o gnttab.o features.o reboot.o machine_reboot.o fallback.o
>  
>  obj-$(CONFIG_PCI)		+= pci.o
>  obj-$(CONFIG_XEN_PRIVILEGED_GUEST) += firmware.o
> --- /dev/null
> +++ b/drivers/xen/core/fallback.c
> @@ -0,0 +1,88 @@
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#if CONFIG_XEN_COMPAT <= 0x030002
> +
> +#include 
> +#include 
> +
> +int HYPERVISOR_event_channel_op_compat(int cmd, void *arg)
> +{
> +	struct evtchn_op op;
> +	int rc;
> +
> +	op.cmd = cmd;
> +	memcpy(&op.u, arg, sizeof(op.u));
> +	rc = _hypercall1(int, event_channel_op_compat, &op);
> +
> +	switch (cmd) {
> +	case EVTCHNOP_close:
> +	case EVTCHNOP_send:
> +	case EVTCHNOP_bind_vcpu:
> +	case EVTCHNOP_unmask:
> +		/* no output */
> +		break;
> +
> +#define COPY_BACK(eop) \
> +	case EVTCHNOP_##eop: \
> +		memcpy(arg, &op.u.eop, sizeof(op.u.eop)); \
> +		break
> +
> +	COPY_BACK(bind_interdomain);
> +	COPY_BACK(bind_virq);
> +	COPY_BACK(bind_pirq);
> +	COPY_BACK(status);
> +	COPY_BACK(alloc_unbound);
> +	COPY_BACK(bind_ipi);
> +#undef COPY_BACK
> +
> +	default:
> +		WARN_ON(rc != -ENOSYS);
> +		break;
> +	}
> +
> +	return rc;
> +}
> +
> +int HYPERVISOR_physdev_op_compat(int cmd, void *arg)
> +{
> +	struct physdev_op op;
> +	int rc;
> +
> +	op.cmd = cmd;
> +	memcpy(&op.u, arg, sizeof(op.u));
> +	rc = _hypercall1(int, physdev_op_compat, &op);
> +
> +	switch (cmd) {
> +	case PHYSDEVOP_IRQ_UNMASK_NOTIFY:
> +	case PHYSDEVOP_set_iopl:
> +	case PHYSDEVOP_set_iobitmap:
> +	case PHYSDEVOP_apic_write:
> +		/* no output */
> +		break;
> +
> +#define COPY_BACK(pop) \
> +	case PHYSDEVOP_##pop: \
> +		memcpy(arg, &op.u.pop, sizeof(op.u.pop)); \
> +		break
> +
> +	COPY_BACK(irq_status_query);
> +#define apic_read apic_op
> +	COPY_BACK(apic_read);
> +#undef apic_read
> +#define ASSIGN_VECTOR irq_op
> +	COPY_BACK(ASSIGN_VECTOR);
> +#undef ASSIGN_VECTOR
> +#undef COPY_BACK

I think rather than this def/undef dance either a two argument macro or
open coding the two cases would be cleaner.

> +
> +	default:
> +		WARN_ON(rc != -ENOSYS);
> +		break;
> +	}
> +
> +	return rc;
> +}
> +
> +#endif /* CONFIG_XEN_COMPAT <= 0x030002 */
> --- a/include/asm-i386/mach-xen/asm/hypercall.h
> +++ b/include/asm-i386/mach-xen/asm/hypercall.h
> @@ -33,7 +33,6 @@
>  #ifndef __HYPERCALL_H__
>  #define __HYPERCALL_H__
>  
> -#include  /* memcpy() */
>  #include 
>  
>  #ifndef __HYPERVISOR_H__
> @@ -128,6 +127,11 @@
>  	__res;							\
>  })
>  
> +#if CONFIG_XEN_COMPAT <= 0x030002
> +int __must_check HYPERVISOR_event_channel_op_compat(int, void *);
> +int __must_check HYPERVISOR_physdev_op_compat(int, void *);
> +#endif
> +
>  static inline int __must_check
>  HYPERVISOR_set_trap_table(
>  	const trap_info_t *table)
> @@ -267,13 +271,8 @@ HYPERVISOR_event_channel_op(
>  	int rc = _hypercall2(int, event_channel_op, cmd, arg);
>  
>  #if CONFIG_XEN_COMPAT <= 0x030002
> -	if (unlikely(rc == -ENOSYS)) {
> -		struct evtchn_op op;
> -		op.cmd = cmd;
> -		memcpy(&op.u, arg, sizeof(op.u));
> -		rc = _hypercall1(int, event_channel_op_compat, &op);
> -		memcpy(arg, &op.u, sizeof(op.u));
> -	}
> +	if (unlikely(rc == -ENOSYS))
> +		rc = HYPERVISOR_event_channel_op_compat(cmd, arg);
>  #endif
>  
>  	return rc;
> @@ -300,13 +299,8 @@ HYPERVISOR_physdev_op(
>  	int rc = _hypercall2(int, physdev_op, cmd, arg);
>  
>  #if CONFIG_XEN_COMPAT <= 0x030002
> -	if (unlikely(rc == -ENOSYS)) {
> -		struct physdev_op op;
> -		op.cmd = cmd;
> -		memcpy(&op.u, arg, sizeof(op.u));
> -		rc = _hypercall1(int, physdev_op_compat, &op);
> -		memcpy(arg, &op.u, sizeof(op.u));
> -	}
> +	if (unlikely(rc == -ENOSYS))
> +		rc = HYPERVISOR_physdev_op_compat(cmd, arg);
>  #endif
>  
>  	return rc;
> --- a/include/asm-i386/mach-xen/asm/hypervisor.h
> +++ b/include/asm-i386/mach-xen/asm/hypervisor.h
> @@ -39,8 +39,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
> -#include 
>  #include 
>  #include 
>  #include 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 13:46:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 13:46:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO7TW-0003Jq-FR; Tue, 16 Oct 2012 13:46:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO7TV-0003Jl-58
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 13:46:25 +0000
Received: from [85.158.143.99:39158] by server-2.bemta-4.messagelabs.com id
	73/7F-22268-0356D705; Tue, 16 Oct 2012 13:46:24 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1350395183!29038376!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2MDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4178 invoked from network); 16 Oct 2012 13:46:23 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-216.messagelabs.com with SMTP;
	16 Oct 2012 13:46:23 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 16 Oct 2012 14:46:22 +0100
Message-Id: <507D814D02000078000A1B51@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 16 Oct 2012 14:46:21 +0100
From: "Jan Beulich" 
To: "xen-devel" 
References: <507D6F3D02000078000A1B13@nat28.tlf.novell.com>
In-Reply-To: <507D6F3D02000078000A1B13@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part1D2C3D3D.1__="
Cc: Ian Campbell ,
	Dan Carpenter 
Subject: [Xen-devel] [PATCH,
 v2] linux-2.6.18: fix hypercall fallback code for very old
 hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part1D2C3D3D.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

While copying the argument structures in HYPERVISOR_event_channel_op()
and HYPERVISOR_physdev_op() into the local variable is sufficiently
safe even if the actual structure is smaller than the container one,
copying back eventual output values the same way isn't: This may
collide with on-stack variables (particularly "rc") which may change
between the first and second memcpy() (i.e. the second memcpy() could
discard that change).

Move the fallback code into out-of-line functions, and handle all of
the operations known by this old a hypervisor individually: Some don't
require copying back anything at all, and for the rest use the
individual argument structures' sizes rather than the container's.

Reported-by: Dan Carpenter 
Signed-off-by: Jan Beulich 
---
v2: Reduce #define/#undef usage in HYPERVISOR_physdev_op_compat().

--- a/drivers/xen/core/Makefile
+++ b/drivers/xen/core/Makefile
@@ -2,7 +2,7 @@
 # Makefile for the linux kernel.
 #
=20
-obj-y :=3D evtchn.o gnttab.o features.o reboot.o machine_reboot.o
+obj-y :=3D evtchn.o gnttab.o features.o reboot.o machine_reboot.o =
fallback.o
=20
 obj-$(CONFIG_PCI)		+=3D pci.o
 obj-$(CONFIG_XEN_PRIVILEGED_GUEST) +=3D firmware.o
--- /dev/null
+++ b/drivers/xen/core/fallback.c
@@ -0,0 +1,84 @@
+#include 
+#include 
+#include 
+#include 
+
+#if 1//temp CONFIG_XEN_COMPAT <=3D 0x030002
+
+#include 
+#include 
+
+int HYPERVISOR_event_channel_op_compat(int cmd, void *arg)
+{
+	struct evtchn_op op;
+	int rc;
+
+	op.cmd =3D cmd;
+	memcpy(&op.u, arg, sizeof(op.u));
+	rc =3D _hypercall1(int, event_channel_op_compat, &op);
+
+	switch (cmd) {
+	case EVTCHNOP_close:
+	case EVTCHNOP_send:
+	case EVTCHNOP_bind_vcpu:
+	case EVTCHNOP_unmask:
+		/* no output */
+		break;
+
+#define COPY_BACK(eop) \
+	case EVTCHNOP_##eop: \
+		memcpy(arg, &op.u.eop, sizeof(op.u.eop)); \
+		break
+
+	COPY_BACK(bind_interdomain);
+	COPY_BACK(bind_virq);
+	COPY_BACK(bind_pirq);
+	COPY_BACK(status);
+	COPY_BACK(alloc_unbound);
+	COPY_BACK(bind_ipi);
+#undef COPY_BACK
+
+	default:
+		WARN_ON(rc !=3D -ENOSYS);
+		break;
+	}
+
+	return rc;
+}
+
+int HYPERVISOR_physdev_op_compat(int cmd, void *arg)
+{
+	struct physdev_op op;
+	int rc;
+
+	op.cmd =3D cmd;
+	memcpy(&op.u, arg, sizeof(op.u));
+	rc =3D _hypercall1(int, physdev_op_compat, &op);
+
+	switch (cmd) {
+	case PHYSDEVOP_IRQ_UNMASK_NOTIFY:
+	case PHYSDEVOP_set_iopl:
+	case PHYSDEVOP_set_iobitmap:
+	case PHYSDEVOP_apic_write:
+		/* no output */
+		break;
+
+#define COPY_BACK(pop, fld) \
+	case PHYSDEVOP_##pop: \
+		memcpy(arg, &op.u.fld, sizeof(op.u.fld)); \
+		break
+
+	COPY_BACK(irq_status_query, irq_status_query);
+	COPY_BACK(apic_read, apic_op);
+	COPY_BACK(ASSIGN_VECTOR, irq_op);
+#undef COPY_BACK
+
+	default:
+		WARN_ON(rc !=3D -ENOSYS);
+		break;
+	}
+
+	return rc;
+}
+
+#endif /* CONFIG_XEN_COMPAT <=3D 0x030002 */
--- a/include/asm-i386/mach-xen/asm/hypercall.h
+++ b/include/asm-i386/mach-xen/asm/hypercall.h
@@ -33,7 +33,6 @@
 #ifndef __HYPERCALL_H__
 #define __HYPERCALL_H__
=20
-#include  /* memcpy() */
 #include 
=20
 #ifndef __HYPERVISOR_H__
@@ -128,6 +127,11 @@
 	__res;							\
 })
=20
+#if CONFIG_XEN_COMPAT <=3D 0x030002
+int __must_check HYPERVISOR_event_channel_op_compat(int, void *);
+int __must_check HYPERVISOR_physdev_op_compat(int, void *);
+#endif
+
 static inline int __must_check
 HYPERVISOR_set_trap_table(
 	const trap_info_t *table)
@@ -267,13 +271,8 @@ HYPERVISOR_event_channel_op(
 	int rc =3D _hypercall2(int, event_channel_op, cmd, arg);
=20
 #if CONFIG_XEN_COMPAT <=3D 0x030002
-	if (unlikely(rc =3D=3D -ENOSYS)) {
-		struct evtchn_op op;
-		op.cmd =3D cmd;
-		memcpy(&op.u, arg, sizeof(op.u));
-		rc =3D _hypercall1(int, event_channel_op_compat, &op);
-		memcpy(arg, &op.u, sizeof(op.u));
-	}
+	if (unlikely(rc =3D=3D -ENOSYS))
+		rc =3D HYPERVISOR_event_channel_op_compat(cmd, arg);
 #endif
=20
 	return rc;
@@ -300,13 +299,8 @@ HYPERVISOR_physdev_op(
 	int rc =3D _hypercall2(int, physdev_op, cmd, arg);
=20
 #if CONFIG_XEN_COMPAT <=3D 0x030002
-	if (unlikely(rc =3D=3D -ENOSYS)) {
-		struct physdev_op op;
-		op.cmd =3D cmd;
-		memcpy(&op.u, arg, sizeof(op.u));
-		rc =3D _hypercall1(int, physdev_op_compat, &op);
-		memcpy(arg, &op.u, sizeof(op.u));
-	}
+	if (unlikely(rc =3D=3D -ENOSYS))
+		rc =3D HYPERVISOR_physdev_op_compat(cmd, arg);
 #endif
=20
 	return rc;
--- a/include/asm-i386/mach-xen/asm/hypervisor.h
+++ b/include/asm-i386/mach-xen/asm/hypervisor.h
@@ -39,8 +39,6 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
 #include 



--=__Part1D2C3D3D.1__=
Content-Type: text/plain; name="xen-hypercall-fallback.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-hypercall-fallback.patch"

fix hypercall fallback code for very old hypervisors=0A=0AWhile copying =
the argument structures in HYPERVISOR_event_channel_op()=0Aand HYPERVISOR_p=
hysdev_op() into the local variable is sufficiently=0Asafe even if the =
actual structure is smaller than the container one,=0Acopying back =
eventual output values the same way isn't: This may=0Acollide with =
on-stack variables (particularly "rc") which may change=0Abetween the =
first and second memcpy() (i.e. the second memcpy() could=0Adiscard that =
change).=0A=0AMove the fallback code into out-of-line functions, and =
handle all of=0Athe operations known by this old a hypervisor individually:=
 Some don't=0Arequire copying back anything at all, and for the rest use =
the=0Aindividual argument structures' sizes rather than the container's.=0A=
=0AReported-by: Dan Carpenter =0ASigned-off-by: =
Jan Beulich =0A---=0Av2: Reduce #define/#undef usage in =
HYPERVISOR_physdev_op_compat().=0A=0A--- a/drivers/xen/core/Makefile=0A+++ =
b/drivers/xen/core/Makefile=0A@@ -2,7 +2,7 @@=0A # Makefile for the linux =
kernel.=0A #=0A =0A-obj-y :=3D evtchn.o gnttab.o features.o reboot.o =
machine_reboot.o=0A+obj-y :=3D evtchn.o gnttab.o features.o reboot.o =
machine_reboot.o fallback.o=0A =0A obj-$(CONFIG_PCI)		+=3D =
pci.o=0A obj-$(CONFIG_XEN_PRIVILEGED_GUEST) +=3D firmware.o=0A--- =
/dev/null=0A+++ b/drivers/xen/core/fallback.c=0A@@ -0,0 +1,84 @@=0A+#includ=
e =0A+#include =0A+#include =0A+=
#include =0A+=0A+#if 1//temp CONFIG_XEN_COMPAT <=3D =
0x030002=0A+=0A+#include =0A+#include =
=0A+=0A+int HYPERVISOR_event_channel_op_compat(int=
 cmd, void *arg)=0A+{=0A+	struct evtchn_op op;=0A+	int =
rc;=0A+=0A+	op.cmd =3D cmd;=0A+	memcpy(&op.u, arg, sizeof(op.u));=
=0A+	rc =3D _hypercall1(int, event_channel_op_compat, &op);=0A+=0A+	=
switch (cmd) {=0A+	case EVTCHNOP_close:=0A+	case EVTCHNOP_send:=
=0A+	case EVTCHNOP_bind_vcpu:=0A+	case EVTCHNOP_unmask:=0A+		=
/* no output */=0A+		break;=0A+=0A+#define COPY_BACK(eop) \=0A+	=
case EVTCHNOP_##eop: \=0A+		memcpy(arg, &op.u.eop, sizeof(op.u.=
eop)); \=0A+		break=0A+=0A+	COPY_BACK(bind_interdomain);=0A+	=
COPY_BACK(bind_virq);=0A+	COPY_BACK(bind_pirq);=0A+	COPY_BACK(s=
tatus);=0A+	COPY_BACK(alloc_unbound);=0A+	COPY_BACK(bind_ipi);=0A+#un=
def COPY_BACK=0A+=0A+	default:=0A+		WARN_ON(rc !=3D =
-ENOSYS);=0A+		break;=0A+	}=0A+=0A+	return rc;=0A+}=0A+=
=0A+int HYPERVISOR_physdev_op_compat(int cmd, void *arg)=0A+{=0A+	=
struct physdev_op op;=0A+	int rc;=0A+=0A+	op.cmd =3D cmd;=0A+	=
memcpy(&op.u, arg, sizeof(op.u));=0A+	rc =3D _hypercall1(int, physdev_op_=
compat, &op);=0A+=0A+	switch (cmd) {=0A+	case PHYSDEVOP_IRQ_UNMASK_N=
OTIFY:=0A+	case PHYSDEVOP_set_iopl:=0A+	case PHYSDEVOP_set_iobitmap=
:=0A+	case PHYSDEVOP_apic_write:=0A+		/* no output */=0A+		=
break;=0A+=0A+#define COPY_BACK(pop, fld) \=0A+	case PHYSDEVOP_##pop: =
\=0A+		memcpy(arg, &op.u.fld, sizeof(op.u.fld)); \=0A+		=
break=0A+=0A+	COPY_BACK(irq_status_query, irq_status_query);=0A+	=
COPY_BACK(apic_read, apic_op);=0A+	COPY_BACK(ASSIGN_VECTOR, =
irq_op);=0A+#undef COPY_BACK=0A+=0A+	default:=0A+		WARN_ON(rc =
!=3D -ENOSYS);=0A+		break;=0A+	}=0A+=0A+	return =
rc;=0A+}=0A+=0A+#endif /* CONFIG_XEN_COMPAT <=3D 0x030002 */=0A--- =
a/include/asm-i386/mach-xen/asm/hypercall.h=0A+++ b/include/asm-i386/mach-x=
en/asm/hypercall.h=0A@@ -33,7 +33,6 @@=0A #ifndef __HYPERCALL_H__=0A =
#define __HYPERCALL_H__=0A =0A-#include  /* memcpy() */=0A =
#include =0A =0A #ifndef __HYPERVISOR_H__=0A@@ -128,6 =
+127,11 @@=0A 	__res;							=
\=0A })=0A =0A+#if CONFIG_XEN_COMPAT <=3D 0x030002=0A+int __must_check =
HYPERVISOR_event_channel_op_compat(int, void *);=0A+int __must_check =
HYPERVISOR_physdev_op_compat(int, void *);=0A+#endif=0A+=0A static inline =
int __must_check=0A HYPERVISOR_set_trap_table(=0A 	const trap_info_t =
*table)=0A@@ -267,13 +271,8 @@ HYPERVISOR_event_channel_op(=0A 	int rc =3D =
_hypercall2(int, event_channel_op, cmd, arg);=0A =0A #if CONFIG_XEN_COMPAT =
<=3D 0x030002=0A-	if (unlikely(rc =3D=3D -ENOSYS)) {=0A-		=
struct evtchn_op op;=0A-		op.cmd =3D cmd;=0A-		=
memcpy(&op.u, arg, sizeof(op.u));=0A-		rc =3D _hypercall1(int, =
event_channel_op_compat, &op);=0A-		memcpy(arg, &op.u, =
sizeof(op.u));=0A-	}=0A+	if (unlikely(rc =3D=3D -ENOSYS))=0A+		=
rc =3D HYPERVISOR_event_channel_op_compat(cmd, arg);=0A #endif=0A =0A 	=
return rc;=0A@@ -300,13 +299,8 @@ HYPERVISOR_physdev_op(=0A 	int rc =3D =
_hypercall2(int, physdev_op, cmd, arg);=0A =0A #if CONFIG_XEN_COMPAT <=3D =
0x030002=0A-	if (unlikely(rc =3D=3D -ENOSYS)) {=0A-		struct =
physdev_op op;=0A-		op.cmd =3D cmd;=0A-		memcpy(&op.=
u, arg, sizeof(op.u));=0A-		rc =3D _hypercall1(int, physdev_op_=
compat, &op);=0A-		memcpy(arg, &op.u, sizeof(op.u));=0A-	=
}=0A+	if (unlikely(rc =3D=3D -ENOSYS))=0A+		rc =3D HYPERVISOR_p=
hysdev_op_compat(cmd, arg);=0A #endif=0A =0A 	return rc;=0A--- a/include/=
asm-i386/mach-xen/asm/hypervisor.h=0A+++ b/include/asm-i386/mach-xen/asm/hy=
pervisor.h=0A@@ -39,8 +39,6 @@=0A #include =0A #include =
=0A #include =0A-#include =
=0A-#include =0A =
#include =0A #include =0A =
#include =0A
--=__Part1D2C3D3D.1__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__Part1D2C3D3D.1__=--


From xen-devel-bounces@lists.xen.org Tue Oct 16 13:46:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 13:46:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO7TW-0003Jq-FR; Tue, 16 Oct 2012 13:46:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO7TV-0003Jl-58
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 13:46:25 +0000
Received: from [85.158.143.99:39158] by server-2.bemta-4.messagelabs.com id
	73/7F-22268-0356D705; Tue, 16 Oct 2012 13:46:24 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1350395183!29038376!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2MDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4178 invoked from network); 16 Oct 2012 13:46:23 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-216.messagelabs.com with SMTP;
	16 Oct 2012 13:46:23 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 16 Oct 2012 14:46:22 +0100
Message-Id: <507D814D02000078000A1B51@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 16 Oct 2012 14:46:21 +0100
From: "Jan Beulich" 
To: "xen-devel" 
References: <507D6F3D02000078000A1B13@nat28.tlf.novell.com>
In-Reply-To: <507D6F3D02000078000A1B13@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part1D2C3D3D.1__="
Cc: Ian Campbell ,
	Dan Carpenter 
Subject: [Xen-devel] [PATCH,
 v2] linux-2.6.18: fix hypercall fallback code for very old
 hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part1D2C3D3D.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

While copying the argument structures in HYPERVISOR_event_channel_op()
and HYPERVISOR_physdev_op() into the local variable is sufficiently
safe even if the actual structure is smaller than the container one,
copying back eventual output values the same way isn't: This may
collide with on-stack variables (particularly "rc") which may change
between the first and second memcpy() (i.e. the second memcpy() could
discard that change).

Move the fallback code into out-of-line functions, and handle all of
the operations known by this old a hypervisor individually: Some don't
require copying back anything at all, and for the rest use the
individual argument structures' sizes rather than the container's.

Reported-by: Dan Carpenter 
Signed-off-by: Jan Beulich 
---
v2: Reduce #define/#undef usage in HYPERVISOR_physdev_op_compat().

--- a/drivers/xen/core/Makefile
+++ b/drivers/xen/core/Makefile
@@ -2,7 +2,7 @@
 # Makefile for the linux kernel.
 #
=20
-obj-y :=3D evtchn.o gnttab.o features.o reboot.o machine_reboot.o
+obj-y :=3D evtchn.o gnttab.o features.o reboot.o machine_reboot.o =
fallback.o
=20
 obj-$(CONFIG_PCI)		+=3D pci.o
 obj-$(CONFIG_XEN_PRIVILEGED_GUEST) +=3D firmware.o
--- /dev/null
+++ b/drivers/xen/core/fallback.c
@@ -0,0 +1,84 @@
+#include 
+#include 
+#include 
+#include 
+
+#if 1//temp CONFIG_XEN_COMPAT <=3D 0x030002
+
+#include 
+#include 
+
+int HYPERVISOR_event_channel_op_compat(int cmd, void *arg)
+{
+	struct evtchn_op op;
+	int rc;
+
+	op.cmd =3D cmd;
+	memcpy(&op.u, arg, sizeof(op.u));
+	rc =3D _hypercall1(int, event_channel_op_compat, &op);
+
+	switch (cmd) {
+	case EVTCHNOP_close:
+	case EVTCHNOP_send:
+	case EVTCHNOP_bind_vcpu:
+	case EVTCHNOP_unmask:
+		/* no output */
+		break;
+
+#define COPY_BACK(eop) \
+	case EVTCHNOP_##eop: \
+		memcpy(arg, &op.u.eop, sizeof(op.u.eop)); \
+		break
+
+	COPY_BACK(bind_interdomain);
+	COPY_BACK(bind_virq);
+	COPY_BACK(bind_pirq);
+	COPY_BACK(status);
+	COPY_BACK(alloc_unbound);
+	COPY_BACK(bind_ipi);
+#undef COPY_BACK
+
+	default:
+		WARN_ON(rc !=3D -ENOSYS);
+		break;
+	}
+
+	return rc;
+}
+
+int HYPERVISOR_physdev_op_compat(int cmd, void *arg)
+{
+	struct physdev_op op;
+	int rc;
+
+	op.cmd =3D cmd;
+	memcpy(&op.u, arg, sizeof(op.u));
+	rc =3D _hypercall1(int, physdev_op_compat, &op);
+
+	switch (cmd) {
+	case PHYSDEVOP_IRQ_UNMASK_NOTIFY:
+	case PHYSDEVOP_set_iopl:
+	case PHYSDEVOP_set_iobitmap:
+	case PHYSDEVOP_apic_write:
+		/* no output */
+		break;
+
+#define COPY_BACK(pop, fld) \
+	case PHYSDEVOP_##pop: \
+		memcpy(arg, &op.u.fld, sizeof(op.u.fld)); \
+		break
+
+	COPY_BACK(irq_status_query, irq_status_query);
+	COPY_BACK(apic_read, apic_op);
+	COPY_BACK(ASSIGN_VECTOR, irq_op);
+#undef COPY_BACK
+
+	default:
+		WARN_ON(rc !=3D -ENOSYS);
+		break;
+	}
+
+	return rc;
+}
+
+#endif /* CONFIG_XEN_COMPAT <=3D 0x030002 */
--- a/include/asm-i386/mach-xen/asm/hypercall.h
+++ b/include/asm-i386/mach-xen/asm/hypercall.h
@@ -33,7 +33,6 @@
 #ifndef __HYPERCALL_H__
 #define __HYPERCALL_H__
=20
-#include  /* memcpy() */
 #include 
=20
 #ifndef __HYPERVISOR_H__
@@ -128,6 +127,11 @@
 	__res;							\
 })
=20
+#if CONFIG_XEN_COMPAT <=3D 0x030002
+int __must_check HYPERVISOR_event_channel_op_compat(int, void *);
+int __must_check HYPERVISOR_physdev_op_compat(int, void *);
+#endif
+
 static inline int __must_check
 HYPERVISOR_set_trap_table(
 	const trap_info_t *table)
@@ -267,13 +271,8 @@ HYPERVISOR_event_channel_op(
 	int rc =3D _hypercall2(int, event_channel_op, cmd, arg);
=20
 #if CONFIG_XEN_COMPAT <=3D 0x030002
-	if (unlikely(rc =3D=3D -ENOSYS)) {
-		struct evtchn_op op;
-		op.cmd =3D cmd;
-		memcpy(&op.u, arg, sizeof(op.u));
-		rc =3D _hypercall1(int, event_channel_op_compat, &op);
-		memcpy(arg, &op.u, sizeof(op.u));
-	}
+	if (unlikely(rc =3D=3D -ENOSYS))
+		rc =3D HYPERVISOR_event_channel_op_compat(cmd, arg);
 #endif
=20
 	return rc;
@@ -300,13 +299,8 @@ HYPERVISOR_physdev_op(
 	int rc =3D _hypercall2(int, physdev_op, cmd, arg);
=20
 #if CONFIG_XEN_COMPAT <=3D 0x030002
-	if (unlikely(rc =3D=3D -ENOSYS)) {
-		struct physdev_op op;
-		op.cmd =3D cmd;
-		memcpy(&op.u, arg, sizeof(op.u));
-		rc =3D _hypercall1(int, physdev_op_compat, &op);
-		memcpy(arg, &op.u, sizeof(op.u));
-	}
+	if (unlikely(rc =3D=3D -ENOSYS))
+		rc =3D HYPERVISOR_physdev_op_compat(cmd, arg);
 #endif
=20
 	return rc;
--- a/include/asm-i386/mach-xen/asm/hypervisor.h
+++ b/include/asm-i386/mach-xen/asm/hypervisor.h
@@ -39,8 +39,6 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
 #include 



--=__Part1D2C3D3D.1__=
Content-Type: text/plain; name="xen-hypercall-fallback.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-hypercall-fallback.patch"

fix hypercall fallback code for very old hypervisors=0A=0AWhile copying =
the argument structures in HYPERVISOR_event_channel_op()=0Aand HYPERVISOR_p=
hysdev_op() into the local variable is sufficiently=0Asafe even if the =
actual structure is smaller than the container one,=0Acopying back =
eventual output values the same way isn't: This may=0Acollide with =
on-stack variables (particularly "rc") which may change=0Abetween the =
first and second memcpy() (i.e. the second memcpy() could=0Adiscard that =
change).=0A=0AMove the fallback code into out-of-line functions, and =
handle all of=0Athe operations known by this old a hypervisor individually:=
 Some don't=0Arequire copying back anything at all, and for the rest use =
the=0Aindividual argument structures' sizes rather than the container's.=0A=
=0AReported-by: Dan Carpenter =0ASigned-off-by: =
Jan Beulich =0A---=0Av2: Reduce #define/#undef usage in =
HYPERVISOR_physdev_op_compat().=0A=0A--- a/drivers/xen/core/Makefile=0A+++ =
b/drivers/xen/core/Makefile=0A@@ -2,7 +2,7 @@=0A # Makefile for the linux =
kernel.=0A #=0A =0A-obj-y :=3D evtchn.o gnttab.o features.o reboot.o =
machine_reboot.o=0A+obj-y :=3D evtchn.o gnttab.o features.o reboot.o =
machine_reboot.o fallback.o=0A =0A obj-$(CONFIG_PCI)		+=3D =
pci.o=0A obj-$(CONFIG_XEN_PRIVILEGED_GUEST) +=3D firmware.o=0A--- =
/dev/null=0A+++ b/drivers/xen/core/fallback.c=0A@@ -0,0 +1,84 @@=0A+#includ=
e =0A+#include =0A+#include =0A+=
#include =0A+=0A+#if 1//temp CONFIG_XEN_COMPAT <=3D =
0x030002=0A+=0A+#include =0A+#include =
=0A+=0A+int HYPERVISOR_event_channel_op_compat(int=
 cmd, void *arg)=0A+{=0A+	struct evtchn_op op;=0A+	int =
rc;=0A+=0A+	op.cmd =3D cmd;=0A+	memcpy(&op.u, arg, sizeof(op.u));=
=0A+	rc =3D _hypercall1(int, event_channel_op_compat, &op);=0A+=0A+	=
switch (cmd) {=0A+	case EVTCHNOP_close:=0A+	case EVTCHNOP_send:=
=0A+	case EVTCHNOP_bind_vcpu:=0A+	case EVTCHNOP_unmask:=0A+		=
/* no output */=0A+		break;=0A+=0A+#define COPY_BACK(eop) \=0A+	=
case EVTCHNOP_##eop: \=0A+		memcpy(arg, &op.u.eop, sizeof(op.u.=
eop)); \=0A+		break=0A+=0A+	COPY_BACK(bind_interdomain);=0A+	=
COPY_BACK(bind_virq);=0A+	COPY_BACK(bind_pirq);=0A+	COPY_BACK(s=
tatus);=0A+	COPY_BACK(alloc_unbound);=0A+	COPY_BACK(bind_ipi);=0A+#un=
def COPY_BACK=0A+=0A+	default:=0A+		WARN_ON(rc !=3D =
-ENOSYS);=0A+		break;=0A+	}=0A+=0A+	return rc;=0A+}=0A+=
=0A+int HYPERVISOR_physdev_op_compat(int cmd, void *arg)=0A+{=0A+	=
struct physdev_op op;=0A+	int rc;=0A+=0A+	op.cmd =3D cmd;=0A+	=
memcpy(&op.u, arg, sizeof(op.u));=0A+	rc =3D _hypercall1(int, physdev_op_=
compat, &op);=0A+=0A+	switch (cmd) {=0A+	case PHYSDEVOP_IRQ_UNMASK_N=
OTIFY:=0A+	case PHYSDEVOP_set_iopl:=0A+	case PHYSDEVOP_set_iobitmap=
:=0A+	case PHYSDEVOP_apic_write:=0A+		/* no output */=0A+		=
break;=0A+=0A+#define COPY_BACK(pop, fld) \=0A+	case PHYSDEVOP_##pop: =
\=0A+		memcpy(arg, &op.u.fld, sizeof(op.u.fld)); \=0A+		=
break=0A+=0A+	COPY_BACK(irq_status_query, irq_status_query);=0A+	=
COPY_BACK(apic_read, apic_op);=0A+	COPY_BACK(ASSIGN_VECTOR, =
irq_op);=0A+#undef COPY_BACK=0A+=0A+	default:=0A+		WARN_ON(rc =
!=3D -ENOSYS);=0A+		break;=0A+	}=0A+=0A+	return =
rc;=0A+}=0A+=0A+#endif /* CONFIG_XEN_COMPAT <=3D 0x030002 */=0A--- =
a/include/asm-i386/mach-xen/asm/hypercall.h=0A+++ b/include/asm-i386/mach-x=
en/asm/hypercall.h=0A@@ -33,7 +33,6 @@=0A #ifndef __HYPERCALL_H__=0A =
#define __HYPERCALL_H__=0A =0A-#include  /* memcpy() */=0A =
#include =0A =0A #ifndef __HYPERVISOR_H__=0A@@ -128,6 =
+127,11 @@=0A 	__res;							=
\=0A })=0A =0A+#if CONFIG_XEN_COMPAT <=3D 0x030002=0A+int __must_check =
HYPERVISOR_event_channel_op_compat(int, void *);=0A+int __must_check =
HYPERVISOR_physdev_op_compat(int, void *);=0A+#endif=0A+=0A static inline =
int __must_check=0A HYPERVISOR_set_trap_table(=0A 	const trap_info_t =
*table)=0A@@ -267,13 +271,8 @@ HYPERVISOR_event_channel_op(=0A 	int rc =3D =
_hypercall2(int, event_channel_op, cmd, arg);=0A =0A #if CONFIG_XEN_COMPAT =
<=3D 0x030002=0A-	if (unlikely(rc =3D=3D -ENOSYS)) {=0A-		=
struct evtchn_op op;=0A-		op.cmd =3D cmd;=0A-		=
memcpy(&op.u, arg, sizeof(op.u));=0A-		rc =3D _hypercall1(int, =
event_channel_op_compat, &op);=0A-		memcpy(arg, &op.u, =
sizeof(op.u));=0A-	}=0A+	if (unlikely(rc =3D=3D -ENOSYS))=0A+		=
rc =3D HYPERVISOR_event_channel_op_compat(cmd, arg);=0A #endif=0A =0A 	=
return rc;=0A@@ -300,13 +299,8 @@ HYPERVISOR_physdev_op(=0A 	int rc =3D =
_hypercall2(int, physdev_op, cmd, arg);=0A =0A #if CONFIG_XEN_COMPAT <=3D =
0x030002=0A-	if (unlikely(rc =3D=3D -ENOSYS)) {=0A-		struct =
physdev_op op;=0A-		op.cmd =3D cmd;=0A-		memcpy(&op.=
u, arg, sizeof(op.u));=0A-		rc =3D _hypercall1(int, physdev_op_=
compat, &op);=0A-		memcpy(arg, &op.u, sizeof(op.u));=0A-	=
}=0A+	if (unlikely(rc =3D=3D -ENOSYS))=0A+		rc =3D HYPERVISOR_p=
hysdev_op_compat(cmd, arg);=0A #endif=0A =0A 	return rc;=0A--- a/include/=
asm-i386/mach-xen/asm/hypervisor.h=0A+++ b/include/asm-i386/mach-xen/asm/hy=
pervisor.h=0A@@ -39,8 +39,6 @@=0A #include =0A #include =
=0A #include =0A-#include =
=0A-#include =0A =
#include =0A #include =0A =
#include =0A
--=__Part1D2C3D3D.1__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__Part1D2C3D3D.1__=--


From xen-devel-bounces@lists.xen.org Tue Oct 16 14:21:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 14:21:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO80e-0003h9-JE; Tue, 16 Oct 2012 14:20:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO80c-0003h4-V0
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 14:20:39 +0000
Received: from [85.158.137.99:41671] by server-8.bemta-3.messagelabs.com id
	C0/99-10525-63D6D705; Tue, 16 Oct 2012 14:20:38 +0000
X-Env-Sender: lersek@redhat.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1350397233!21810616!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTgxNzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31710 invoked from network); 16 Oct 2012 14:20:37 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-217.messagelabs.com with SMTP;
	16 Oct 2012 14:20:37 -0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q9GEKVSF018674
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 16 Oct 2012 10:20:32 -0400
Received: from lacos-laptop.usersys.redhat.com (vpn1-7-174.ams2.redhat.com
	[10.36.7.174])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q9GEKPjx025801; Tue, 16 Oct 2012 10:20:26 -0400
Message-ID: <507D6D84.8050602@redhat.com>
Date: Tue, 16 Oct 2012 16:21:56 +0200
From: Laszlo Ersek 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.7) Gecko/20120825 Thunderbird/10.0.7
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk , xen-devel@lists.xen.org
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: Igor Mammedov , Drew Jones ,
	Paolo Bonzini 
Subject: [Xen-devel] PV passthrough of sibling igbvf's
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

this is with reference to
 -- RHEL-5.9 Beta
host & guest. Nonetheless I think my question applies to current
upstream Linux -- if not, I'd greatly appreciate commit hashes.

Consider several igbvf's that belong to the same PF (port): they are
functions that share a (bus, device) pair (aka "slot") in dom0. The VPCI
implementation of pciback_add_pci_dev() [drivers/xen/pciback/vpci.c]
will assign these sibling functions to the same virtual slot. In other
words, VFs that are siblings in dom0 end up as siblings in the PV domU.

(Upstream path and function: "drivers/xen/xen-pciback/vpci.c",
__xen_pcibk_add_pci_dev().)

This logic appears to date back to
.


The RHEL-5.9 Beta PV domU does something like this:

  pci_scan_slot
    /* for each function: */
      pci_scan_single_device
         pci_scan_device
           pci_bus_read_config_dword(bus, devfn, PCI_VENDOR_ID, &l)
           pci_setup_device
             pci_read_config_byte(dev, PCI_HEADER_TYPE, &hdr_type)
             dev->multifunction = !!(hdr_type & 0x80);
      if (dev_scanned && !dev->multifunc && func == 0): break

Current upstream Linux has gone through several changes here, but the
gist is the same: if function 0 is successfully scanned and it
explicitly reports itself non-multi (--> no_next_fn()), then the rest of
the functions on the slot is skipped.

Problem is, function 0 of the igbvf I'm looking at reports itself as
non-multifunction, and thus the domU doesn't find the rest of the
passed-through functions.


pciback seems to have no overlay for PCI_HEADER_TYPE in array
"header_common" [upstream: drivers/xen/xen-pciback/conf_space_header.c],
thus pciback_config_read() / xen_pcibk_config_read() pass through the
header type transparently when the domU reads it in pci_setup_device().


I wonder if

- a new dom0 overlay should be introduced for PCI_HEADER_TYPE, to the
tune of upstream Linux commit fd5b221b (ie. vendor-id/device-id), that
would perhaps check the # of sibling functions in the given vpci slot,
and fake the MSB in "hdr_type",

- or the domU's slot scanning logic should be changed,

- or the igbvf I'm looking at reports an incorrect "hdr_type" (in which
case we'd still have to fake something). The legacy
"/etc/xen/xend-pci-quirks.sxp" interface is only suitable for giving
extra write access to the domU, thus not good enough here.

Thanks a lot!
Laszlo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 14:21:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 14:21:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO80e-0003h9-JE; Tue, 16 Oct 2012 14:20:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO80c-0003h4-V0
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 14:20:39 +0000
Received: from [85.158.137.99:41671] by server-8.bemta-3.messagelabs.com id
	C0/99-10525-63D6D705; Tue, 16 Oct 2012 14:20:38 +0000
X-Env-Sender: lersek@redhat.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1350397233!21810616!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTgxNzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31710 invoked from network); 16 Oct 2012 14:20:37 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-217.messagelabs.com with SMTP;
	16 Oct 2012 14:20:37 -0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q9GEKVSF018674
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 16 Oct 2012 10:20:32 -0400
Received: from lacos-laptop.usersys.redhat.com (vpn1-7-174.ams2.redhat.com
	[10.36.7.174])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q9GEKPjx025801; Tue, 16 Oct 2012 10:20:26 -0400
Message-ID: <507D6D84.8050602@redhat.com>
Date: Tue, 16 Oct 2012 16:21:56 +0200
From: Laszlo Ersek 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.7) Gecko/20120825 Thunderbird/10.0.7
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk , xen-devel@lists.xen.org
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: Igor Mammedov , Drew Jones ,
	Paolo Bonzini 
Subject: [Xen-devel] PV passthrough of sibling igbvf's
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

this is with reference to
 -- RHEL-5.9 Beta
host & guest. Nonetheless I think my question applies to current
upstream Linux -- if not, I'd greatly appreciate commit hashes.

Consider several igbvf's that belong to the same PF (port): they are
functions that share a (bus, device) pair (aka "slot") in dom0. The VPCI
implementation of pciback_add_pci_dev() [drivers/xen/pciback/vpci.c]
will assign these sibling functions to the same virtual slot. In other
words, VFs that are siblings in dom0 end up as siblings in the PV domU.

(Upstream path and function: "drivers/xen/xen-pciback/vpci.c",
__xen_pcibk_add_pci_dev().)

This logic appears to date back to
.


The RHEL-5.9 Beta PV domU does something like this:

  pci_scan_slot
    /* for each function: */
      pci_scan_single_device
         pci_scan_device
           pci_bus_read_config_dword(bus, devfn, PCI_VENDOR_ID, &l)
           pci_setup_device
             pci_read_config_byte(dev, PCI_HEADER_TYPE, &hdr_type)
             dev->multifunction = !!(hdr_type & 0x80);
      if (dev_scanned && !dev->multifunc && func == 0): break

Current upstream Linux has gone through several changes here, but the
gist is the same: if function 0 is successfully scanned and it
explicitly reports itself non-multi (--> no_next_fn()), then the rest of
the functions on the slot is skipped.

Problem is, function 0 of the igbvf I'm looking at reports itself as
non-multifunction, and thus the domU doesn't find the rest of the
passed-through functions.


pciback seems to have no overlay for PCI_HEADER_TYPE in array
"header_common" [upstream: drivers/xen/xen-pciback/conf_space_header.c],
thus pciback_config_read() / xen_pcibk_config_read() pass through the
header type transparently when the domU reads it in pci_setup_device().


I wonder if

- a new dom0 overlay should be introduced for PCI_HEADER_TYPE, to the
tune of upstream Linux commit fd5b221b (ie. vendor-id/device-id), that
would perhaps check the # of sibling functions in the given vpci slot,
and fake the MSB in "hdr_type",

- or the domU's slot scanning logic should be changed,

- or the igbvf I'm looking at reports an incorrect "hdr_type" (in which
case we'd still have to fake something). The legacy
"/etc/xen/xend-pci-quirks.sxp" interface is only suitable for giving
extra write access to the domU, thus not good enough here.

Thanks a lot!
Laszlo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 14:38:47 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 14:38:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO8Hk-0003vC-2v; Tue, 16 Oct 2012 14:38:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO8Hi-0003v7-FL
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 14:38:18 +0000
Received: from [85.158.143.35:14028] by server-1.bemta-4.messagelabs.com id
	C6/8B-19134-9517D705; Tue, 16 Oct 2012 14:38:17 +0000
X-Env-Sender: tupeng212@gmail.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1350398295!15731413!1
X-Originating-IP: [209.85.220.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=HTML_MESSAGE,
	MIME_BASE64_TEXT, MIME_BOUND_NEXTPART, ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP, spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6960 invoked from network); 16 Oct 2012 14:38:17 -0000
Received: from mail-pa0-f45.google.com (HELO mail-pa0-f45.google.com)
	(209.85.220.45)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 14:38:17 -0000
Received: by mail-pa0-f45.google.com with SMTP id fb10so5999183pad.32
	for ; Tue, 16 Oct 2012 07:38:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=date:from:to:cc:reply-to:subject:x-priority:x-guid:x-has-attach
	:x-mailer:mime-version:message-id:content-type;
	bh=9/1jWKVJw+zpDMzfOEcapPS4yr7Djc0UIPkTR1iC334=;
	b=zFK/+i/WqjaLF671Iyr3P09ELu77SJ4OKE8roC7/j36TtujlAwrNywbKoVt6KdWwqz
	MjmDPcniWZxCD0oVOshMBdORCBNWOk+PG2rS6YdxE95LOXfc/HhMPLHJszD7bqh43gam
	7qJBU75wz5pW9iK9IkF9FQ7yAmNcerK3U2TLcFlWhqOorOXPnVv/w9Qe8P3hIgcetoTI
	bqkJuvC5QsY41jZILPsNIL+hKA/2l0RonxVnODanPdfAYP/RjeeJgGN8xGbq24nvZnL2
	HqfIOxTj4u4+OtZHKgtvrgOMee4M8qHPCnS50eyLq8TwWUM/hJrria1ImWxmf2Zjr8Ml
	F3+Q==
Received: by 10.66.73.226 with SMTP id o2mr42092131pav.83.1350398295032;
	Tue, 16 Oct 2012 07:38:15 -0700 (PDT)
Received: from root ([115.199.246.228])
	by mx.google.com with ESMTPS id j9sm10942945paw.2.2012.10.16.07.38.10
	(version=SSLv3 cipher=OTHER); Tue, 16 Oct 2012 07:38:14 -0700 (PDT)
Date: Tue, 16 Oct 2012 22:38:17 +0800
From: tupeng212 
To: "Jan Beulich" , 
	"Keir Fraser" 
X-Priority: 3
X-GUID: F4B55B03-BBF1-401B-BD70-09177AB3DF71
X-Has-Attach: no
X-Mailer: Foxmail 7.0.1.91[en]
Mime-Version: 1.0
Message-ID: <201210162238055789394@gmail.com>
Cc: xen-devel 
Subject: Re: [Xen-devel] gnttab: don't use domain lock for serialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: tupeng212 
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============8103105338649812131=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.

--===============8103105338649812131==
Content-Type: multipart/alternative;
	boundary="----=_001_NextPart682606167853_=----"

This is a multi-part message in MIME format.

------=_001_NextPart682606167853_=----
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: base64

eGVuL2NvbW1vbi9ncmFudF90YWJsZS5jIA0KMTc0IHN0YXRpYyBpbmxpbmUgdm9pZCANCjE3NSBk
b3VibGVfZ3RfbG9jayhzdHJ1Y3QgZ3JhbnRfdGFibGUgKmxndCwgc3RydWN0IGdyYW50X3RhYmxl
ICpyZ3QpIA0KMTc2IHsgDQoxNzcgaWYgKCBsZ3QgPCByZ3QgKSANCjE3OCB7IA0KMTc5IHNwaW5f
bG9jaygmbGd0LT5sb2NrKTsgDQoxODAgc3Bpbl9sb2NrKCZyZ3QtPmxvY2spOyANCjE4MSB9IA0K
MTgyIGVsc2UgDQoxODMgeyANCjE4NCBpZiAoIGxndCAhPSByZ3QgKSANCjE4NSAgICAgc3Bpbl9s
b2NrKCZyZ3QtPmxvY2spOyANCjE4NiBzcGluX2xvY2soJmxndC0+bG9jayk7IC8vaGVyZSBpZiB0
aGUgc2FtZSwgd2UganVzdCBsb2NrIG9uY2UuDQoxODcgfSANCjE4OCB9DQoNCkkgaGF2ZSBhIHF1
ZXN0aW9uLCB3aGVuIGxndCA9PSByZ3QgPyANCnJlbW90ZSBkb21haW4ncyBncmFudF90YWJsZSBp
cyBjcmVhdGVkIGJ5IGl0c2VsZiwgc28gaG93IHRoZXkgZ2V0IHRoZSBzYW1lPw0KVGhhbmtzIGEg
bG90IQ0KDQoNCg0KDQp0dXBlbmcyMTI=

------=_001_NextPart682606167853_=----
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable









xen/common/grant_table.c 




174 static inline void 


175 double_gt_lock(struct grant_table *lgt, struc=
t grant_table *rgt) 


176 { 


177 if ( lgt < rgt ) 


178 { 


179 spin_lock(&lgt->lock); 


180 spin_lock(&rgt->lock); 


181 } 


182 else 


183 { 


184 if ( lgt !=3D rgt ) 


185     spin_lock(&rgt->lock); <=
/DIV>

186 spin_lock(&lgt->lock); //here if the same, we ju=
st=20
lock once.


187 } 


188 }


 


I have a question, when lgt =3D=3D rgt ? 


remote domain's grant_table is created by itself, so how they get the=
 
same?


Thanks a lot!


 





tupeng212


------=_001_NextPart682606167853_=------



--===============8103105338649812131==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8103105338649812131==--



From xen-devel-bounces@lists.xen.org Tue Oct 16 14:38:47 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 14:38:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO8Hk-0003vC-2v; Tue, 16 Oct 2012 14:38:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO8Hi-0003v7-FL
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 14:38:18 +0000
Received: from [85.158.143.35:14028] by server-1.bemta-4.messagelabs.com id
	C6/8B-19134-9517D705; Tue, 16 Oct 2012 14:38:17 +0000
X-Env-Sender: tupeng212@gmail.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1350398295!15731413!1
X-Originating-IP: [209.85.220.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=HTML_MESSAGE,
	MIME_BASE64_TEXT, MIME_BOUND_NEXTPART, ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP, spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6960 invoked from network); 16 Oct 2012 14:38:17 -0000
Received: from mail-pa0-f45.google.com (HELO mail-pa0-f45.google.com)
	(209.85.220.45)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 14:38:17 -0000
Received: by mail-pa0-f45.google.com with SMTP id fb10so5999183pad.32
	for ; Tue, 16 Oct 2012 07:38:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=date:from:to:cc:reply-to:subject:x-priority:x-guid:x-has-attach
	:x-mailer:mime-version:message-id:content-type;
	bh=9/1jWKVJw+zpDMzfOEcapPS4yr7Djc0UIPkTR1iC334=;
	b=zFK/+i/WqjaLF671Iyr3P09ELu77SJ4OKE8roC7/j36TtujlAwrNywbKoVt6KdWwqz
	MjmDPcniWZxCD0oVOshMBdORCBNWOk+PG2rS6YdxE95LOXfc/HhMPLHJszD7bqh43gam
	7qJBU75wz5pW9iK9IkF9FQ7yAmNcerK3U2TLcFlWhqOorOXPnVv/w9Qe8P3hIgcetoTI
	bqkJuvC5QsY41jZILPsNIL+hKA/2l0RonxVnODanPdfAYP/RjeeJgGN8xGbq24nvZnL2
	HqfIOxTj4u4+OtZHKgtvrgOMee4M8qHPCnS50eyLq8TwWUM/hJrria1ImWxmf2Zjr8Ml
	F3+Q==
Received: by 10.66.73.226 with SMTP id o2mr42092131pav.83.1350398295032;
	Tue, 16 Oct 2012 07:38:15 -0700 (PDT)
Received: from root ([115.199.246.228])
	by mx.google.com with ESMTPS id j9sm10942945paw.2.2012.10.16.07.38.10
	(version=SSLv3 cipher=OTHER); Tue, 16 Oct 2012 07:38:14 -0700 (PDT)
Date: Tue, 16 Oct 2012 22:38:17 +0800
From: tupeng212 
To: "Jan Beulich" , 
	"Keir Fraser" 
X-Priority: 3
X-GUID: F4B55B03-BBF1-401B-BD70-09177AB3DF71
X-Has-Attach: no
X-Mailer: Foxmail 7.0.1.91[en]
Mime-Version: 1.0
Message-ID: <201210162238055789394@gmail.com>
Cc: xen-devel 
Subject: Re: [Xen-devel] gnttab: don't use domain lock for serialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: tupeng212 
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============8103105338649812131=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.

--===============8103105338649812131==
Content-Type: multipart/alternative;
	boundary="----=_001_NextPart682606167853_=----"

This is a multi-part message in MIME format.

------=_001_NextPart682606167853_=----
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: base64

eGVuL2NvbW1vbi9ncmFudF90YWJsZS5jIA0KMTc0IHN0YXRpYyBpbmxpbmUgdm9pZCANCjE3NSBk
b3VibGVfZ3RfbG9jayhzdHJ1Y3QgZ3JhbnRfdGFibGUgKmxndCwgc3RydWN0IGdyYW50X3RhYmxl
ICpyZ3QpIA0KMTc2IHsgDQoxNzcgaWYgKCBsZ3QgPCByZ3QgKSANCjE3OCB7IA0KMTc5IHNwaW5f
bG9jaygmbGd0LT5sb2NrKTsgDQoxODAgc3Bpbl9sb2NrKCZyZ3QtPmxvY2spOyANCjE4MSB9IA0K
MTgyIGVsc2UgDQoxODMgeyANCjE4NCBpZiAoIGxndCAhPSByZ3QgKSANCjE4NSAgICAgc3Bpbl9s
b2NrKCZyZ3QtPmxvY2spOyANCjE4NiBzcGluX2xvY2soJmxndC0+bG9jayk7IC8vaGVyZSBpZiB0
aGUgc2FtZSwgd2UganVzdCBsb2NrIG9uY2UuDQoxODcgfSANCjE4OCB9DQoNCkkgaGF2ZSBhIHF1
ZXN0aW9uLCB3aGVuIGxndCA9PSByZ3QgPyANCnJlbW90ZSBkb21haW4ncyBncmFudF90YWJsZSBp
cyBjcmVhdGVkIGJ5IGl0c2VsZiwgc28gaG93IHRoZXkgZ2V0IHRoZSBzYW1lPw0KVGhhbmtzIGEg
bG90IQ0KDQoNCg0KDQp0dXBlbmcyMTI=

------=_001_NextPart682606167853_=----
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable









xen/common/grant_table.c 




174 static inline void 


175 double_gt_lock(struct grant_table *lgt, struc=
t grant_table *rgt) 


176 { 


177 if ( lgt < rgt ) 


178 { 


179 spin_lock(&lgt->lock); 


180 spin_lock(&rgt->lock); 


181 } 


182 else 


183 { 


184 if ( lgt !=3D rgt ) 


185     spin_lock(&rgt->lock); <=
/DIV>

186 spin_lock(&lgt->lock); //here if the same, we ju=
st=20
lock once.


187 } 


188 }


 


I have a question, when lgt =3D=3D rgt ? 


remote domain's grant_table is created by itself, so how they get the=
 
same?


Thanks a lot!


 





tupeng212


------=_001_NextPart682606167853_=------



--===============8103105338649812131==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8103105338649812131==--



From xen-devel-bounces@lists.xen.org Tue Oct 16 14:42:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 14:42:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO8LW-00049w-Jk; Tue, 16 Oct 2012 14:42:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO8LU-00049e-Gs
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 14:42:12 +0000
Received: from [85.158.139.211:36620] by server-3.bemta-5.messagelabs.com id
	C5/08-28618-3427D705; Tue, 16 Oct 2012 14:42:11 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1350398529!22552223!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzY3MTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6320 invoked from network); 16 Oct 2012 14:42:11 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 14:42:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,593,1344211200"; d="scan'208";a="41374220"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Oct 2012 14:42:09 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 16 Oct 2012 10:42:08 -0400
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TO8LQ-000506-Kw;
	Tue, 16 Oct 2012 15:42:08 +0100
Message-ID: <507D7240.2010305@citrix.com>
Date: Tue, 16 Oct 2012 15:42:08 +0100
From: Andrew Cooper 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Laszlo Ersek 
References: <507D6D84.8050602@redhat.com>
In-Reply-To: <507D6D84.8050602@redhat.com>
X-Enigmail-Version: 1.4.5
Cc: Igor Mammedov , Drew Jones ,
	"xen-devel@lists.xen.org" ,
	Paolo Bonzini ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] PV passthrough of sibling igbvf's
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 16/10/12 15:21, Laszlo Ersek wrote:
> Hi,
>
> this is with reference to
>  -- RHEL-5.9 Beta
> host & guest. Nonetheless I think my question applies to current
> upstream Linux -- if not, I'd greatly appreciate commit hashes.
>
> Consider several igbvf's that belong to the same PF (port): they are
> functions that share a (bus, device) pair (aka "slot") in dom0. The VPCI
> implementation of pciback_add_pci_dev() [drivers/xen/pciback/vpci.c]
> will assign these sibling functions to the same virtual slot. In other
> words, VFs that are siblings in dom0 end up as siblings in the PV domU.
>
> (Upstream path and function: "drivers/xen/xen-pciback/vpci.c",
> __xen_pcibk_add_pci_dev().)
>
> This logic appears to date back to
> .
>
>
> The RHEL-5.9 Beta PV domU does something like this:
>
>   pci_scan_slot
>     /* for each function: */
>       pci_scan_single_device
>          pci_scan_device
>            pci_bus_read_config_dword(bus, devfn, PCI_VENDOR_ID, &l)
>            pci_setup_device
>              pci_read_config_byte(dev, PCI_HEADER_TYPE, &hdr_type)
>              dev->multifunction = !!(hdr_type & 0x80);
>       if (dev_scanned && !dev->multifunc && func == 0): break
>
> Current upstream Linux has gone through several changes here, but the
> gist is the same: if function 0 is successfully scanned and it
> explicitly reports itself non-multi (--> no_next_fn()), then the rest of
> the functions on the slot is skipped.
>
> Problem is, function 0 of the igbvf I'm looking at reports itself as
> non-multifunction, and thus the domU doesn't find the rest of the
> passed-through functions.

Which is correct, because the virtual function itself is only a single
function.

I would hazard a guess that the real bug is trying to fake up 8
individual virtual functions as an 8-fuction device, which seems like a
toolstack bug to me.

While it would certainly be possible to trap and emulate reads like
this, I would think it would be decidedly hacky, thus preferably avoided.

~Andrew

>
>
> pciback seems to have no overlay for PCI_HEADER_TYPE in array
> "header_common" [upstream: drivers/xen/xen-pciback/conf_space_header.c],
> thus pciback_config_read() / xen_pcibk_config_read() pass through the
> header type transparently when the domU reads it in pci_setup_device().
>
>
> I wonder if
>
> - a new dom0 overlay should be introduced for PCI_HEADER_TYPE, to the
> tune of upstream Linux commit fd5b221b (ie. vendor-id/device-id), that
> would perhaps check the # of sibling functions in the given vpci slot,
> and fake the MSB in "hdr_type",
>
> - or the domU's slot scanning logic should be changed,
>
> - or the igbvf I'm looking at reports an incorrect "hdr_type" (in which
> case we'd still have to fake something). The legacy
> "/etc/xen/xend-pci-quirks.sxp" interface is only suitable for giving
> extra write access to the domU, thus not good enough here.
>
> Thanks a lot!
> Laszlo
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 14:42:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 14:42:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO8LW-00049w-Jk; Tue, 16 Oct 2012 14:42:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO8LU-00049e-Gs
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 14:42:12 +0000
Received: from [85.158.139.211:36620] by server-3.bemta-5.messagelabs.com id
	C5/08-28618-3427D705; Tue, 16 Oct 2012 14:42:11 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1350398529!22552223!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzY3MTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6320 invoked from network); 16 Oct 2012 14:42:11 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 14:42:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,593,1344211200"; d="scan'208";a="41374220"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Oct 2012 14:42:09 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 16 Oct 2012 10:42:08 -0400
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TO8LQ-000506-Kw;
	Tue, 16 Oct 2012 15:42:08 +0100
Message-ID: <507D7240.2010305@citrix.com>
Date: Tue, 16 Oct 2012 15:42:08 +0100
From: Andrew Cooper 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Laszlo Ersek 
References: <507D6D84.8050602@redhat.com>
In-Reply-To: <507D6D84.8050602@redhat.com>
X-Enigmail-Version: 1.4.5
Cc: Igor Mammedov , Drew Jones ,
	"xen-devel@lists.xen.org" ,
	Paolo Bonzini ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] PV passthrough of sibling igbvf's
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 16/10/12 15:21, Laszlo Ersek wrote:
> Hi,
>
> this is with reference to
>  -- RHEL-5.9 Beta
> host & guest. Nonetheless I think my question applies to current
> upstream Linux -- if not, I'd greatly appreciate commit hashes.
>
> Consider several igbvf's that belong to the same PF (port): they are
> functions that share a (bus, device) pair (aka "slot") in dom0. The VPCI
> implementation of pciback_add_pci_dev() [drivers/xen/pciback/vpci.c]
> will assign these sibling functions to the same virtual slot. In other
> words, VFs that are siblings in dom0 end up as siblings in the PV domU.
>
> (Upstream path and function: "drivers/xen/xen-pciback/vpci.c",
> __xen_pcibk_add_pci_dev().)
>
> This logic appears to date back to
> .
>
>
> The RHEL-5.9 Beta PV domU does something like this:
>
>   pci_scan_slot
>     /* for each function: */
>       pci_scan_single_device
>          pci_scan_device
>            pci_bus_read_config_dword(bus, devfn, PCI_VENDOR_ID, &l)
>            pci_setup_device
>              pci_read_config_byte(dev, PCI_HEADER_TYPE, &hdr_type)
>              dev->multifunction = !!(hdr_type & 0x80);
>       if (dev_scanned && !dev->multifunc && func == 0): break
>
> Current upstream Linux has gone through several changes here, but the
> gist is the same: if function 0 is successfully scanned and it
> explicitly reports itself non-multi (--> no_next_fn()), then the rest of
> the functions on the slot is skipped.
>
> Problem is, function 0 of the igbvf I'm looking at reports itself as
> non-multifunction, and thus the domU doesn't find the rest of the
> passed-through functions.

Which is correct, because the virtual function itself is only a single
function.

I would hazard a guess that the real bug is trying to fake up 8
individual virtual functions as an 8-fuction device, which seems like a
toolstack bug to me.

While it would certainly be possible to trap and emulate reads like
this, I would think it would be decidedly hacky, thus preferably avoided.

~Andrew

>
>
> pciback seems to have no overlay for PCI_HEADER_TYPE in array
> "header_common" [upstream: drivers/xen/xen-pciback/conf_space_header.c],
> thus pciback_config_read() / xen_pcibk_config_read() pass through the
> header type transparently when the domU reads it in pci_setup_device().
>
>
> I wonder if
>
> - a new dom0 overlay should be introduced for PCI_HEADER_TYPE, to the
> tune of upstream Linux commit fd5b221b (ie. vendor-id/device-id), that
> would perhaps check the # of sibling functions in the given vpci slot,
> and fake the MSB in "hdr_type",
>
> - or the domU's slot scanning logic should be changed,
>
> - or the igbvf I'm looking at reports an incorrect "hdr_type" (in which
> case we'd still have to fake something). The legacy
> "/etc/xen/xend-pci-quirks.sxp" interface is only suitable for giving
> extra write access to the domU, thus not good enough here.
>
> Thanks a lot!
> Laszlo
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 14:45:40 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 14:45:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO8OU-0004Ks-83; Tue, 16 Oct 2012 14:45:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO8OT-0004Km-Gq
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 14:45:17 +0000
Received: from [85.158.139.211:12627] by server-11.bemta-5.messagelabs.com id
	09/C7-14870-CF27D705; Tue, 16 Oct 2012 14:45:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1350398715!18557373!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQzMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18935 invoked from network); 16 Oct 2012 14:45:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 14:45:16 -0000
X-IronPort-AV: E=Sophos;i="4.80,593,1344211200"; d="scan'208";a="15206199"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Oct 2012 14:45:14 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 16 Oct 2012 15:45:14 +0100
Message-ID: <1350398712.18058.120.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Keir Fraser 
Date: Tue, 16 Oct 2012 15:45:12 +0100
In-Reply-To: 
References: 
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	"Tim \(Xen.org\)" , Jan
	Beulich , xen-devel 
Subject: Re: [Xen-devel] [PATCH v2 00/10] 64 bit ARM ABI,
 map foreign gmfn API, ARM grant tables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-10-15 at 16:48 +0100, Keir Fraser wrote:
> On 15/10/2012 16:20, "Ian Campbell"  wrote:
> 
> > This is v2 of "Sweep through arm-for-4.3 branch + a bit extra" retitled
> > since most of the sweep through stuff has been swept through already and
> > just the bit extra remains.
> > 
> > I've addressed the review comments and fixed the bisection issue. A
> > bunch of this stuff is cross arch and/or touches common code.
> 
> Those bits are fine by me, now.
> 
> Acked-by: Keir Fraser 

Thanks, I'll give it a while for others to comment and plan to shovel it
in tomorrow or Thursday unless there are objections.

> 
> > The Linux side of the 64 bit ARM ABI changes are in mainline Linux
> > already (just a few tweaks and cleanups remain).
> > 
> > xen: arm: implement XENMEM_add_to_physmap_range
> > 
> >         New hypercall intended for use by both ARM (Linux patches exist)
> >         and x86 PVH (TBD)
> >         
> > xen/arm: grant table
> > 
> >         Simple wiring up job. Acked but depends on
> >         XENMEM_add_to_physmap_range.
> >         
> > arm: tools: add arm to foreign structs checking
> >         
> >         Fixes native tools build on ARM
> > 
> > xen: xen_ulong_t substitution
> > xen: change the limit of nr_extents to UINT_MAX >> MEMOP_EXTENT_SHIFT
> > xen: introduce XEN_GUEST_HANDLE_PARAM
> > xen: replace XEN_GUEST_HANDLE with XEN_GUEST_HANDLE_PARAM when appropriate
> > xen: more XEN_GUEST_HANDLE_PARAM substitutions
> > xen: remove XEN_GUEST_HANDLE(ulong)
> > arm: parameter guest handles are 32 bit on 32 bit hypervisor
> > 
> >         These are the ARM 64 bit API, mostly from Stefano and posted
> >         several times already.
> >         
> > Ian.
> > 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 14:45:40 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 14:45:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO8OU-0004Ks-83; Tue, 16 Oct 2012 14:45:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO8OT-0004Km-Gq
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 14:45:17 +0000
Received: from [85.158.139.211:12627] by server-11.bemta-5.messagelabs.com id
	09/C7-14870-CF27D705; Tue, 16 Oct 2012 14:45:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1350398715!18557373!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQzMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18935 invoked from network); 16 Oct 2012 14:45:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 14:45:16 -0000
X-IronPort-AV: E=Sophos;i="4.80,593,1344211200"; d="scan'208";a="15206199"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Oct 2012 14:45:14 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 16 Oct 2012 15:45:14 +0100
Message-ID: <1350398712.18058.120.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Keir Fraser 
Date: Tue, 16 Oct 2012 15:45:12 +0100
In-Reply-To: 
References: 
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	"Tim \(Xen.org\)" , Jan
	Beulich , xen-devel 
Subject: Re: [Xen-devel] [PATCH v2 00/10] 64 bit ARM ABI,
 map foreign gmfn API, ARM grant tables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-10-15 at 16:48 +0100, Keir Fraser wrote:
> On 15/10/2012 16:20, "Ian Campbell"  wrote:
> 
> > This is v2 of "Sweep through arm-for-4.3 branch + a bit extra" retitled
> > since most of the sweep through stuff has been swept through already and
> > just the bit extra remains.
> > 
> > I've addressed the review comments and fixed the bisection issue. A
> > bunch of this stuff is cross arch and/or touches common code.
> 
> Those bits are fine by me, now.
> 
> Acked-by: Keir Fraser 

Thanks, I'll give it a while for others to comment and plan to shovel it
in tomorrow or Thursday unless there are objections.

> 
> > The Linux side of the 64 bit ARM ABI changes are in mainline Linux
> > already (just a few tweaks and cleanups remain).
> > 
> > xen: arm: implement XENMEM_add_to_physmap_range
> > 
> >         New hypercall intended for use by both ARM (Linux patches exist)
> >         and x86 PVH (TBD)
> >         
> > xen/arm: grant table
> > 
> >         Simple wiring up job. Acked but depends on
> >         XENMEM_add_to_physmap_range.
> >         
> > arm: tools: add arm to foreign structs checking
> >         
> >         Fixes native tools build on ARM
> > 
> > xen: xen_ulong_t substitution
> > xen: change the limit of nr_extents to UINT_MAX >> MEMOP_EXTENT_SHIFT
> > xen: introduce XEN_GUEST_HANDLE_PARAM
> > xen: replace XEN_GUEST_HANDLE with XEN_GUEST_HANDLE_PARAM when appropriate
> > xen: more XEN_GUEST_HANDLE_PARAM substitutions
> > xen: remove XEN_GUEST_HANDLE(ulong)
> > arm: parameter guest handles are 32 bit on 32 bit hypervisor
> > 
> >         These are the ARM 64 bit API, mostly from Stefano and posted
> >         several times already.
> >         
> > Ian.
> > 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 14:47:01 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 14:47:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO8Pm-0004SE-O6; Tue, 16 Oct 2012 14:46:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO8Pl-0004S4-Rp
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 14:46:38 +0000
Received: from [85.158.139.211:22320] by server-13.bemta-5.messagelabs.com id
	B1/5E-30674-D437D705; Tue, 16 Oct 2012 14:46:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1350398796!22551948!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2MDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23709 invoked from network); 16 Oct 2012 14:46:36 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-206.messagelabs.com with SMTP;
	16 Oct 2012 14:46:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 16 Oct 2012 15:46:35 +0100
Message-Id: <507D8F6802000078000A1B88@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 16 Oct 2012 15:46:32 +0100
From: "Jan Beulich" 
To: "xen-devel" 
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part6E5F4E58.1__="
Cc: ying.huang@intel.com
Subject: [Xen-devel] [PATCH] ACPI: fix APEI related table size checking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part6E5F4E58.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Huang Ying's machine:

erst_tab->header_length =3D=3D sizeof(struct acpi_table_einj)

but Yinghai reported that on his machine,

erst_tab->header_length =3D=3D sizeof(struct acpi_table_einj) -
sizeof(struct acpi_table_header)

To make erst table size checking code works on all systems, both
testing are treated as PASS.

Same situation applies to einj_tab->header_length, so corresponding
table size checking is changed in similar way too.

Originally-by: Yinghai Lu 
Signed-off-by: Huang Ying 

- use switch() for better readability
- add comment explaining why a formally invalid size it also being
  accepted
- check erst_tab->header.length before even looking at
  erst_tab->header_length
- prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)

Signed-off-by: Jan Beulich 

--- a/xen/drivers/acpi/apei/erst.c
+++ b/xen/drivers/acpi/apei/erst.c
@@ -715,12 +715,23 @@ int erst_clear(u64 record_id)
=20
 static int __init erst_check_table(struct acpi_table_erst *erst_tab)
 {
-	if (erst_tab->header_length !=3D sizeof(struct acpi_table_erst))
+	if (erst_tab->header.length < sizeof(*erst_tab))
 		return -EINVAL;
-	if (erst_tab->header.length < sizeof(struct acpi_table_erst))
+
+	switch (erst_tab->header_length) {
+	case sizeof(*erst_tab) - sizeof(erst_tab->header):
+	/*
+	 * While invalid per specification, there are (early?) systems
+	 * indicating the full header size here, so accept that value too.
+	 */
+	case sizeof(*erst_tab):
+		break;
+	default:
 		return -EINVAL;
+	}
+
 	if (erst_tab->entries !=3D
-	    (erst_tab->header.length - sizeof(struct acpi_table_erst)) /
+	    (erst_tab->header.length - sizeof(*erst_tab)) /
 	    sizeof(struct acpi_erst_entry))
 		return -EINVAL;
=20




--=__Part6E5F4E58.1__=
Content-Type: text/plain; name="ACPI-ERST-header-length.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="ACPI-ERST-header-length.patch"

ACPI: fix APEI related table size checking

On Huang Ying's machine:

erst_tab->header_length =3D=3D sizeof(struct acpi_table_einj)

but Yinghai reported that on his machine,

erst_tab->header_length =3D=3D sizeof(struct acpi_table_einj) -
sizeof(struct acpi_table_header)

To make erst table size checking code works on all systems, both
testing are treated as PASS.

Same situation applies to einj_tab->header_length, so corresponding
table size checking is changed in similar way too.

Originally-by: Yinghai Lu 
Signed-off-by: Huang Ying 

- use switch() for better readability
- add comment explaining why a formally invalid size it also being
  accepted
- check erst_tab->header.length before even looking at
  erst_tab->header_length
- prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)

Signed-off-by: Jan Beulich 

--- a/xen/drivers/acpi/apei/erst.c
+++ b/xen/drivers/acpi/apei/erst.c
@@ -715,12 +715,23 @@ int erst_clear(u64 record_id)
=20
 static int __init erst_check_table(struct acpi_table_erst *erst_tab)
 {
-	if (erst_tab->header_length !=3D sizeof(struct acpi_table_erst))
+	if (erst_tab->header.length < sizeof(*erst_tab))
 		return -EINVAL;
-	if (erst_tab->header.length < sizeof(struct acpi_table_erst))
+
+	switch (erst_tab->header_length) {
+	case sizeof(*erst_tab) - sizeof(erst_tab->header):
+	/*
+	 * While invalid per specification, there are (early?) systems
+	 * indicating the full header size here, so accept that value too.
+	 */
+	case sizeof(*erst_tab):
+		break;
+	default:
 		return -EINVAL;
+	}
+
 	if (erst_tab->entries !=3D
-	    (erst_tab->header.length - sizeof(struct acpi_table_erst)) /
+	    (erst_tab->header.length - sizeof(*erst_tab)) /
 	    sizeof(struct acpi_erst_entry))
 		return -EINVAL;
=20

--=__Part6E5F4E58.1__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__Part6E5F4E58.1__=--


From xen-devel-bounces@lists.xen.org Tue Oct 16 14:47:01 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 14:47:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO8Pm-0004SE-O6; Tue, 16 Oct 2012 14:46:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO8Pl-0004S4-Rp
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 14:46:38 +0000
Received: from [85.158.139.211:22320] by server-13.bemta-5.messagelabs.com id
	B1/5E-30674-D437D705; Tue, 16 Oct 2012 14:46:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1350398796!22551948!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2MDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23709 invoked from network); 16 Oct 2012 14:46:36 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-206.messagelabs.com with SMTP;
	16 Oct 2012 14:46:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 16 Oct 2012 15:46:35 +0100
Message-Id: <507D8F6802000078000A1B88@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 16 Oct 2012 15:46:32 +0100
From: "Jan Beulich" 
To: "xen-devel" 
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part6E5F4E58.1__="
Cc: ying.huang@intel.com
Subject: [Xen-devel] [PATCH] ACPI: fix APEI related table size checking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part6E5F4E58.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Huang Ying's machine:

erst_tab->header_length =3D=3D sizeof(struct acpi_table_einj)

but Yinghai reported that on his machine,

erst_tab->header_length =3D=3D sizeof(struct acpi_table_einj) -
sizeof(struct acpi_table_header)

To make erst table size checking code works on all systems, both
testing are treated as PASS.

Same situation applies to einj_tab->header_length, so corresponding
table size checking is changed in similar way too.

Originally-by: Yinghai Lu 
Signed-off-by: Huang Ying 

- use switch() for better readability
- add comment explaining why a formally invalid size it also being
  accepted
- check erst_tab->header.length before even looking at
  erst_tab->header_length
- prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)

Signed-off-by: Jan Beulich 

--- a/xen/drivers/acpi/apei/erst.c
+++ b/xen/drivers/acpi/apei/erst.c
@@ -715,12 +715,23 @@ int erst_clear(u64 record_id)
=20
 static int __init erst_check_table(struct acpi_table_erst *erst_tab)
 {
-	if (erst_tab->header_length !=3D sizeof(struct acpi_table_erst))
+	if (erst_tab->header.length < sizeof(*erst_tab))
 		return -EINVAL;
-	if (erst_tab->header.length < sizeof(struct acpi_table_erst))
+
+	switch (erst_tab->header_length) {
+	case sizeof(*erst_tab) - sizeof(erst_tab->header):
+	/*
+	 * While invalid per specification, there are (early?) systems
+	 * indicating the full header size here, so accept that value too.
+	 */
+	case sizeof(*erst_tab):
+		break;
+	default:
 		return -EINVAL;
+	}
+
 	if (erst_tab->entries !=3D
-	    (erst_tab->header.length - sizeof(struct acpi_table_erst)) /
+	    (erst_tab->header.length - sizeof(*erst_tab)) /
 	    sizeof(struct acpi_erst_entry))
 		return -EINVAL;
=20




--=__Part6E5F4E58.1__=
Content-Type: text/plain; name="ACPI-ERST-header-length.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="ACPI-ERST-header-length.patch"

ACPI: fix APEI related table size checking

On Huang Ying's machine:

erst_tab->header_length =3D=3D sizeof(struct acpi_table_einj)

but Yinghai reported that on his machine,

erst_tab->header_length =3D=3D sizeof(struct acpi_table_einj) -
sizeof(struct acpi_table_header)

To make erst table size checking code works on all systems, both
testing are treated as PASS.

Same situation applies to einj_tab->header_length, so corresponding
table size checking is changed in similar way too.

Originally-by: Yinghai Lu 
Signed-off-by: Huang Ying 

- use switch() for better readability
- add comment explaining why a formally invalid size it also being
  accepted
- check erst_tab->header.length before even looking at
  erst_tab->header_length
- prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)

Signed-off-by: Jan Beulich 

--- a/xen/drivers/acpi/apei/erst.c
+++ b/xen/drivers/acpi/apei/erst.c
@@ -715,12 +715,23 @@ int erst_clear(u64 record_id)
=20
 static int __init erst_check_table(struct acpi_table_erst *erst_tab)
 {
-	if (erst_tab->header_length !=3D sizeof(struct acpi_table_erst))
+	if (erst_tab->header.length < sizeof(*erst_tab))
 		return -EINVAL;
-	if (erst_tab->header.length < sizeof(struct acpi_table_erst))
+
+	switch (erst_tab->header_length) {
+	case sizeof(*erst_tab) - sizeof(erst_tab->header):
+	/*
+	 * While invalid per specification, there are (early?) systems
+	 * indicating the full header size here, so accept that value too.
+	 */
+	case sizeof(*erst_tab):
+		break;
+	default:
 		return -EINVAL;
+	}
+
 	if (erst_tab->entries !=3D
-	    (erst_tab->header.length - sizeof(struct acpi_table_erst)) /
+	    (erst_tab->header.length - sizeof(*erst_tab)) /
 	    sizeof(struct acpi_erst_entry))
 		return -EINVAL;
=20

--=__Part6E5F4E58.1__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__Part6E5F4E58.1__=--


From xen-devel-bounces@lists.xen.org Tue Oct 16 14:50:26 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 14:50:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO8T8-0004gl-E0; Tue, 16 Oct 2012 14:50:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO8T7-0004gg-9E
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 14:50:05 +0000
Received: from [85.158.139.211:61204] by server-6.bemta-5.messagelabs.com id
	7D/D6-32589-C147D705; Tue, 16 Oct 2012 14:50:04 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1350399003!22471898!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2MDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2391 invoked from network); 16 Oct 2012 14:50:03 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-206.messagelabs.com with SMTP;
	16 Oct 2012 14:50:03 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 16 Oct 2012 15:50:02 +0100
Message-Id: <507D903602000078000A1B8B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 16 Oct 2012 15:49:58 +0100
From: "Jan Beulich" 
To: "tupeng212" 
References: <201210162238055789394@gmail.com>
In-Reply-To: <201210162238055789394@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser , xen-devel 
Subject: Re: [Xen-devel] gnttab: don't use domain lock for serialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 16.10.12 at 16:38, tupeng212  wrote:
> xen/common/grant_table.c 
> 174 static inline void 
> 175 double_gt_lock(struct grant_table *lgt, struct grant_table *rgt) 
> 176 { 
> 177 if ( lgt < rgt ) 
> 178 { 
> 179 spin_lock(&lgt->lock); 
> 180 spin_lock(&rgt->lock); 
> 181 } 
> 182 else 
> 183 { 
> 184 if ( lgt != rgt ) 
> 185     spin_lock(&rgt->lock); 
> 186 spin_lock(&lgt->lock); //here if the same, we just lock once.
> 187 } 
> 188 }
> 
> I have a question, when lgt == rgt ? 
> remote domain's grant_table is created by itself, so how they get the same?

If backend and frontend are in the same domain (e.g. vbd
attached locally to Dom0), both domains (and hence both grant
tables) involved are the same.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 14:50:26 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 14:50:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO8T8-0004gl-E0; Tue, 16 Oct 2012 14:50:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO8T7-0004gg-9E
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 14:50:05 +0000
Received: from [85.158.139.211:61204] by server-6.bemta-5.messagelabs.com id
	7D/D6-32589-C147D705; Tue, 16 Oct 2012 14:50:04 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1350399003!22471898!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2MDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2391 invoked from network); 16 Oct 2012 14:50:03 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-206.messagelabs.com with SMTP;
	16 Oct 2012 14:50:03 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 16 Oct 2012 15:50:02 +0100
Message-Id: <507D903602000078000A1B8B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 16 Oct 2012 15:49:58 +0100
From: "Jan Beulich" 
To: "tupeng212" 
References: <201210162238055789394@gmail.com>
In-Reply-To: <201210162238055789394@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser , xen-devel 
Subject: Re: [Xen-devel] gnttab: don't use domain lock for serialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 16.10.12 at 16:38, tupeng212  wrote:
> xen/common/grant_table.c 
> 174 static inline void 
> 175 double_gt_lock(struct grant_table *lgt, struct grant_table *rgt) 
> 176 { 
> 177 if ( lgt < rgt ) 
> 178 { 
> 179 spin_lock(&lgt->lock); 
> 180 spin_lock(&rgt->lock); 
> 181 } 
> 182 else 
> 183 { 
> 184 if ( lgt != rgt ) 
> 185     spin_lock(&rgt->lock); 
> 186 spin_lock(&lgt->lock); //here if the same, we just lock once.
> 187 } 
> 188 }
> 
> I have a question, when lgt == rgt ? 
> remote domain's grant_table is created by itself, so how they get the same?

If backend and frontend are in the same domain (e.g. vbd
attached locally to Dom0), both domains (and hence both grant
tables) involved are the same.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 14:58:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 14:58:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO8aW-0004zH-OP; Tue, 16 Oct 2012 14:57:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO8aV-0004zC-6b
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 14:57:43 +0000
Received: from [85.158.143.99:57956] by server-1.bemta-4.messagelabs.com id
	1F/78-19134-6E57D705; Tue, 16 Oct 2012 14:57:42 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1350399460!28221085!1
X-Originating-IP: [209.85.216.52]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26349 invoked from network); 16 Oct 2012 14:57:41 -0000
Received: from mail-qa0-f52.google.com (HELO mail-qa0-f52.google.com)
	(209.85.216.52)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 14:57:41 -0000
Received: by mail-qa0-f52.google.com with SMTP id g24so2478963qab.11
	for ; Tue, 16 Oct 2012 07:57:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=/bawzX1ybVt6AD434t25pw4wxGa84TdT2WeRZdlrUpQ=;
	b=kTxL4K41V7PC4ZVgQuX5yKIaAdccTaU4mcQa+QWlGGs0ajkenASEwTbmDuO5RvDhxX
	aOzHZNvuE9AyTy0G9tIjZtoao53nE4g2TgGJVxdniYPd9BDk6S6VJ3kkXF8bbpBVG0Km
	4GSGQAA2upc8ctyODTwJf/BA5ldgwTsbknL8YGSEE0pEU5nbjIRCF6ct6qG2NVQx0fXN
	8pxGA1sy+yX0vjcBCyDjF0+IJoskTSakWs3c1W+AGXaYFEtMHj0rMkUIp/BDJo4THsbQ
	O21N2ADV91NdZsY/y+2J0R69Xdzbm9PlIgWTHJ25cOW23h1vzmZ5BcGlIQ2wJzqnATL1
	ohrw==
Received: by 10.224.180.16 with SMTP id bs16mr26576183qab.58.1350399459958;
	Tue, 16 Oct 2012 07:57:39 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id gx8sm18605421qab.12.2012.10.16.07.57.39
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 16 Oct 2012 07:57:39 -0700 (PDT)
Date: Tue, 16 Oct 2012 10:45:38 -0400
From: Konrad Rzeszutek Wilk 
To: George Dunlap , annie.li@oracle.com
Message-ID: <20121016144537.GA10883@phenom.dumpdata.com>
References: 
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.3 development update, 15 Oct
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> == Not yet complete ==
> 
> * PVH mode (w/ Linux)
>   owner: mukesh@oracle
>   Linux: 3rd draft patches posted.
>   Xen: Patches being cleaned up for submission
> 
> * Event channel scalability
>   owner: attilio@citrix
>   status: initial design proposed
>   Increase limit on event channels (currently 1024 for 32-bit guests,
>   4096 for 64-bit guests)
> 
> * ARM server port
>   owner: ijc@citrix
>   status: Core hypervisor patches accepted; Linux paches pending

Ian,
Are these the ones that interact with the PVH ones?
> * blktap3
> * Multi-page blk rings (external)
>  - blkback in kernel (konrad@oracle, ?@intel)
>  - qemu blkback
>   status: ?

Nothing yet.
> 
> * Multi-page net protocol (external)
>   owner: ijc@citrix or annie.li@oracle
>   status: Initial patches posted (by Wei Liu)
>   expand the network ring protocol to allow multiple pages for
>   increased throughput

We are cleaning them up to get Ian's input. There are .. many things
here for this TODO - there is the feature persistent grant which gives a big
performance boost. Then there is the Wei Liu patches which need
some rework (they were RFC). The persistent grant (which is what
Annie is working on right now) nicely fit on top of Wei Liu's, but since
they (the RFC patches - which split the netback into per-vif threads)
are not yet ready - annie is looking to see if she can do some lookup
using the old netback mechanism.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 14:58:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 14:58:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO8aW-0004zH-OP; Tue, 16 Oct 2012 14:57:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO8aV-0004zC-6b
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 14:57:43 +0000
Received: from [85.158.143.99:57956] by server-1.bemta-4.messagelabs.com id
	1F/78-19134-6E57D705; Tue, 16 Oct 2012 14:57:42 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1350399460!28221085!1
X-Originating-IP: [209.85.216.52]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26349 invoked from network); 16 Oct 2012 14:57:41 -0000
Received: from mail-qa0-f52.google.com (HELO mail-qa0-f52.google.com)
	(209.85.216.52)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 14:57:41 -0000
Received: by mail-qa0-f52.google.com with SMTP id g24so2478963qab.11
	for ; Tue, 16 Oct 2012 07:57:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=/bawzX1ybVt6AD434t25pw4wxGa84TdT2WeRZdlrUpQ=;
	b=kTxL4K41V7PC4ZVgQuX5yKIaAdccTaU4mcQa+QWlGGs0ajkenASEwTbmDuO5RvDhxX
	aOzHZNvuE9AyTy0G9tIjZtoao53nE4g2TgGJVxdniYPd9BDk6S6VJ3kkXF8bbpBVG0Km
	4GSGQAA2upc8ctyODTwJf/BA5ldgwTsbknL8YGSEE0pEU5nbjIRCF6ct6qG2NVQx0fXN
	8pxGA1sy+yX0vjcBCyDjF0+IJoskTSakWs3c1W+AGXaYFEtMHj0rMkUIp/BDJo4THsbQ
	O21N2ADV91NdZsY/y+2J0R69Xdzbm9PlIgWTHJ25cOW23h1vzmZ5BcGlIQ2wJzqnATL1
	ohrw==
Received: by 10.224.180.16 with SMTP id bs16mr26576183qab.58.1350399459958;
	Tue, 16 Oct 2012 07:57:39 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id gx8sm18605421qab.12.2012.10.16.07.57.39
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 16 Oct 2012 07:57:39 -0700 (PDT)
Date: Tue, 16 Oct 2012 10:45:38 -0400
From: Konrad Rzeszutek Wilk 
To: George Dunlap , annie.li@oracle.com
Message-ID: <20121016144537.GA10883@phenom.dumpdata.com>
References: 
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.3 development update, 15 Oct
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> == Not yet complete ==
> 
> * PVH mode (w/ Linux)
>   owner: mukesh@oracle
>   Linux: 3rd draft patches posted.
>   Xen: Patches being cleaned up for submission
> 
> * Event channel scalability
>   owner: attilio@citrix
>   status: initial design proposed
>   Increase limit on event channels (currently 1024 for 32-bit guests,
>   4096 for 64-bit guests)
> 
> * ARM server port
>   owner: ijc@citrix
>   status: Core hypervisor patches accepted; Linux paches pending

Ian,
Are these the ones that interact with the PVH ones?
> * blktap3
> * Multi-page blk rings (external)
>  - blkback in kernel (konrad@oracle, ?@intel)
>  - qemu blkback
>   status: ?

Nothing yet.
> 
> * Multi-page net protocol (external)
>   owner: ijc@citrix or annie.li@oracle
>   status: Initial patches posted (by Wei Liu)
>   expand the network ring protocol to allow multiple pages for
>   increased throughput

We are cleaning them up to get Ian's input. There are .. many things
here for this TODO - there is the feature persistent grant which gives a big
performance boost. Then there is the Wei Liu patches which need
some rework (they were RFC). The persistent grant (which is what
Annie is working on right now) nicely fit on top of Wei Liu's, but since
they (the RFC patches - which split the netback into per-vif threads)
are not yet ready - annie is looking to see if she can do some lookup
using the old netback mechanism.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 15:03:12 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 15:03:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO8fZ-0005CN-Kt; Tue, 16 Oct 2012 15:02:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO8fY-0005CA-8w
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 15:02:56 +0000
Received: from [85.158.138.51:32001] by server-9.bemta-3.messagelabs.com id
	22/0D-16841-F177D705; Tue, 16 Oct 2012 15:02:55 +0000
X-Env-Sender: lersek@redhat.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1350399774!34497959!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTgxNzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11164 invoked from network); 16 Oct 2012 15:02:54 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-2.tower-174.messagelabs.com with SMTP;
	16 Oct 2012 15:02:54 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q9GF2qSr005539
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 16 Oct 2012 11:02:52 -0400
Received: from lacos-laptop.usersys.redhat.com (vpn1-7-174.ams2.redhat.com
	[10.36.7.174])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q9GF2onl015257; Tue, 16 Oct 2012 11:02:50 -0400
Message-ID: <507D7774.2050902@redhat.com>
Date: Tue, 16 Oct 2012 17:04:20 +0200
From: Laszlo Ersek 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.7) Gecko/20120825 Thunderbird/10.0.7
MIME-Version: 1.0
To: Andrew Cooper 
References: <507D6D84.8050602@redhat.com> <507D7240.2010305@citrix.com>
In-Reply-To: <507D7240.2010305@citrix.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: Igor Mammedov , Drew Jones ,
	"xen-devel@lists.xen.org" ,
	Paolo Bonzini ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] PV passthrough of sibling igbvf's
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

On 10/16/12 16:42, Andrew Cooper wrote:

> I would hazard a guess that the real bug is trying to fake up 8
> individual virtual functions as an 8-fuction device, which seems like a
> toolstack bug to me.

I believe that comes from:

>> The VPCI
>> implementation of pciback_add_pci_dev() [drivers/xen/pciback/vpci.c]
>> will assign these sibling functions to the same virtual slot. In other
>> words, VFs that are siblings in dom0 end up as siblings in the PV domU.

This grouping-together of virtual functions is the same in current
upstream Linux:

>> (Upstream path and function: "drivers/xen/xen-pciback/vpci.c",
>> __xen_pcibk_add_pci_dev().)

(+ match_slot())

>>
>> This logic appears to date back to
>> .

A closer pointer into the changeset:

http://xenbits.xensource.com/xen-unstable.hg/rev/5b433b4fca34#l16.85

The patch doesn't seem to justify the grouping specifically, thus I did
not even try to refute it.

Now that you point it out, match_slot() is probably insufficient grounds
to group functions together. Maybe we should check *additionally* if the
device being passed through is multi-function. I'll try it.

Thanks!
Laszlo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 15:03:12 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 15:03:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO8fZ-0005CN-Kt; Tue, 16 Oct 2012 15:02:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO8fY-0005CA-8w
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 15:02:56 +0000
Received: from [85.158.138.51:32001] by server-9.bemta-3.messagelabs.com id
	22/0D-16841-F177D705; Tue, 16 Oct 2012 15:02:55 +0000
X-Env-Sender: lersek@redhat.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1350399774!34497959!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTgxNzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11164 invoked from network); 16 Oct 2012 15:02:54 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-2.tower-174.messagelabs.com with SMTP;
	16 Oct 2012 15:02:54 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q9GF2qSr005539
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 16 Oct 2012 11:02:52 -0400
Received: from lacos-laptop.usersys.redhat.com (vpn1-7-174.ams2.redhat.com
	[10.36.7.174])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q9GF2onl015257; Tue, 16 Oct 2012 11:02:50 -0400
Message-ID: <507D7774.2050902@redhat.com>
Date: Tue, 16 Oct 2012 17:04:20 +0200
From: Laszlo Ersek 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.7) Gecko/20120825 Thunderbird/10.0.7
MIME-Version: 1.0
To: Andrew Cooper 
References: <507D6D84.8050602@redhat.com> <507D7240.2010305@citrix.com>
In-Reply-To: <507D7240.2010305@citrix.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: Igor Mammedov , Drew Jones ,
	"xen-devel@lists.xen.org" ,
	Paolo Bonzini ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] PV passthrough of sibling igbvf's
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

On 10/16/12 16:42, Andrew Cooper wrote:

> I would hazard a guess that the real bug is trying to fake up 8
> individual virtual functions as an 8-fuction device, which seems like a
> toolstack bug to me.

I believe that comes from:

>> The VPCI
>> implementation of pciback_add_pci_dev() [drivers/xen/pciback/vpci.c]
>> will assign these sibling functions to the same virtual slot. In other
>> words, VFs that are siblings in dom0 end up as siblings in the PV domU.

This grouping-together of virtual functions is the same in current
upstream Linux:

>> (Upstream path and function: "drivers/xen/xen-pciback/vpci.c",
>> __xen_pcibk_add_pci_dev().)

(+ match_slot())

>>
>> This logic appears to date back to
>> .

A closer pointer into the changeset:

http://xenbits.xensource.com/xen-unstable.hg/rev/5b433b4fca34#l16.85

The patch doesn't seem to justify the grouping specifically, thus I did
not even try to refute it.

Now that you point it out, match_slot() is probably insufficient grounds
to group functions together. Maybe we should check *additionally* if the
device being passed through is multi-function. I'll try it.

Thanks!
Laszlo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 15:03:59 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 15:03:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO8gJ-0005GG-2l; Tue, 16 Oct 2012 15:03:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO8gH-0005G4-Fe
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 15:03:41 +0000
Received: from [85.158.139.211:13651] by server-5.bemta-5.messagelabs.com id
	48/5E-09732-C477D705; Tue, 16 Oct 2012 15:03:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1350399820!22527046!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQzMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6434 invoked from network); 16 Oct 2012 15:03:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 15:03:40 -0000
X-IronPort-AV: E=Sophos;i="4.80,593,1344211200"; d="scan'208";a="15206775"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Oct 2012 15:03:35 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 16 Oct 2012 16:03:35 +0100
Message-ID: <1350399813.18058.122.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Tue, 16 Oct 2012 16:03:33 +0100
In-Reply-To: <20121016144537.GA10883@phenom.dumpdata.com>
References: 
	<20121016144537.GA10883@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: George Dunlap ,
	"annie.li@oracle.com" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Xen 4.3 development update, 15 Oct
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-16 at 15:45 +0100, Konrad Rzeszutek Wilk wrote:
> > * ARM server port
> >   owner: ijc@citrix
> >   status: Core hypervisor patches accepted; Linux paches pending
> 
> Ian,
> Are these the ones that interact with the PVH ones?

Some of the ARM functionality builds on the PVH stuff (e.g. the privcmd
stuff) but other bits are independent of PVH.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 15:03:59 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 15:03:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO8gJ-0005GG-2l; Tue, 16 Oct 2012 15:03:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO8gH-0005G4-Fe
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 15:03:41 +0000
Received: from [85.158.139.211:13651] by server-5.bemta-5.messagelabs.com id
	48/5E-09732-C477D705; Tue, 16 Oct 2012 15:03:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1350399820!22527046!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQzMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6434 invoked from network); 16 Oct 2012 15:03:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 15:03:40 -0000
X-IronPort-AV: E=Sophos;i="4.80,593,1344211200"; d="scan'208";a="15206775"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Oct 2012 15:03:35 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 16 Oct 2012 16:03:35 +0100
Message-ID: <1350399813.18058.122.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Tue, 16 Oct 2012 16:03:33 +0100
In-Reply-To: <20121016144537.GA10883@phenom.dumpdata.com>
References: 
	<20121016144537.GA10883@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: George Dunlap ,
	"annie.li@oracle.com" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Xen 4.3 development update, 15 Oct
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-16 at 15:45 +0100, Konrad Rzeszutek Wilk wrote:
> > * ARM server port
> >   owner: ijc@citrix
> >   status: Core hypervisor patches accepted; Linux paches pending
> 
> Ian,
> Are these the ones that interact with the PVH ones?

Some of the ARM functionality builds on the PVH stuff (e.g. the privcmd
stuff) but other bits are independent of PVH.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 15:05:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 15:05:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO8hm-0005QQ-7z; Tue, 16 Oct 2012 15:05:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO8hk-0005QJ-Lt
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 15:05:12 +0000
Received: from [85.158.143.99:14978] by server-3.bemta-4.messagelabs.com id
	28/DD-03544-7A77D705; Tue, 16 Oct 2012 15:05:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1350399907!26814320!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2MDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26931 invoked from network); 16 Oct 2012 15:05:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-216.messagelabs.com with SMTP;
	16 Oct 2012 15:05:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 16 Oct 2012 16:05:07 +0100
Message-Id: <507D93C102000078000A1BAB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 16 Oct 2012 16:05:05 +0100
From: "Jan Beulich" 
To: "xen-devel" 
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] [PATCH 0/3] x86: HPET adjustments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

1: obtain proper lock for changing IRQ affinity
2: allow use for broadcast when interrupt remapping is in effect
3: cache MSI message last written

Signed-off-by: Jan Beulich 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 15:05:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 15:05:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO8hm-0005QQ-7z; Tue, 16 Oct 2012 15:05:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO8hk-0005QJ-Lt
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 15:05:12 +0000
Received: from [85.158.143.99:14978] by server-3.bemta-4.messagelabs.com id
	28/DD-03544-7A77D705; Tue, 16 Oct 2012 15:05:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1350399907!26814320!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2MDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26931 invoked from network); 16 Oct 2012 15:05:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-216.messagelabs.com with SMTP;
	16 Oct 2012 15:05:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 16 Oct 2012 16:05:07 +0100
Message-Id: <507D93C102000078000A1BAB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 16 Oct 2012 16:05:05 +0100
From: "Jan Beulich" 
To: "xen-devel" 
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] [PATCH 0/3] x86: HPET adjustments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

1: obtain proper lock for changing IRQ affinity
2: allow use for broadcast when interrupt remapping is in effect
3: cache MSI message last written

Signed-off-by: Jan Beulich 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 15:09:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 15:09:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO8ll-0005gW-3V; Tue, 16 Oct 2012 15:09:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO8lj-0005gP-UH
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 15:09:20 +0000
Received: from [85.158.143.99:60443] by server-1.bemta-4.messagelabs.com id
	3A/FA-19134-F987D705; Tue, 16 Oct 2012 15:09:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1350400158!26160374!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2MDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32395 invoked from network); 16 Oct 2012 15:09:18 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-216.messagelabs.com with SMTP;
	16 Oct 2012 15:09:18 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 16 Oct 2012 16:09:17 +0100
Message-Id: <507D94BD02000078000A1BBD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 16 Oct 2012 16:09:17 +0100
From: "Jan Beulich" 
To: "xen-devel" 
References: <507D93C102000078000A1BAB@nat28.tlf.novell.com>
In-Reply-To: <507D93C102000078000A1BAB@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartB081908D.0__="
Subject: [Xen-devel] [PATCH 1/3] x86/HPET: obtain proper lock for changing
 IRQ affinity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartB081908D.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

The IRQ descriptor lock should be held while adjusting the affinity of
any IRQ; the HPET channel lock isn't sufficient to protect namely
against races with moving the IRQ to a different CPU.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/hpet.c
+++ b/xen/arch/x86/hpet.c
@@ -436,6 +436,16 @@ static struct hpet_event_channel *hpet_g
     return ch;
 }
=20
+static void _hpet_msi_set_affinity(const struct hpet_event_channel *ch)
+{
+    struct irq_desc *desc =3D irq_to_desc(ch->irq);
+
+    ASSERT(!local_irq_is_enabled());
+    spin_lock(&desc->lock);
+    hpet_msi_set_affinity(desc, cpumask_of(ch->cpu));
+    spin_unlock(&desc->lock);
+}
+
 static void hpet_attach_channel(unsigned int cpu,
                                 struct hpet_event_channel *ch)
 {
@@ -450,7 +460,7 @@ static void hpet_attach_channel(unsigned
     if ( ch->cpu !=3D cpu )
         return;
=20
-    hpet_msi_set_affinity(irq_to_desc(ch->irq), cpumask_of(ch->cpu));
+    _hpet_msi_set_affinity(ch);
 }
=20
 static void hpet_detach_channel(unsigned int cpu,
@@ -472,7 +482,7 @@ static void hpet_detach_channel(unsigned
     }
=20
     ch->cpu =3D cpumask_first(ch->cpumask);
-    hpet_msi_set_affinity(irq_to_desc(ch->irq), cpumask_of(ch->cpu));
+    _hpet_msi_set_affinity(ch);
 }
=20
 #include 




--=__PartB081908D.0__=
Content-Type: text/plain; name="x86-HPET-affinity-lock.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-HPET-affinity-lock.patch"

x86/HPET: obtain proper lock for changing IRQ affinity=0A=0AThe IRQ =
descriptor lock should be held while adjusting the affinity of=0Aany IRQ; =
the HPET channel lock isn't sufficient to protect namely=0Aagainst races =
with moving the IRQ to a different CPU.=0A=0ASigned-off-by: Jan Beulich =
=0A=0A--- a/xen/arch/x86/hpet.c=0A+++ b/xen/arch/x86/hpe=
t.c=0A@@ -436,6 +436,16 @@ static struct hpet_event_channel *hpet_g=0A     =
return ch;=0A }=0A =0A+static void _hpet_msi_set_affinity(const struct =
hpet_event_channel *ch)=0A+{=0A+    struct irq_desc *desc =3D irq_to_desc(c=
h->irq);=0A+=0A+    ASSERT(!local_irq_is_enabled());=0A+    spin_lock(&desc=
->lock);=0A+    hpet_msi_set_affinity(desc, cpumask_of(ch->cpu));=0A+    =
spin_unlock(&desc->lock);=0A+}=0A+=0A static void hpet_attach_channel(unsig=
ned int cpu,=0A                                 struct hpet_event_channel =
*ch)=0A {=0A@@ -450,7 +460,7 @@ static void hpet_attach_channel(unsigned=0A=
     if ( ch->cpu !=3D cpu )=0A         return;=0A =0A-    hpet_msi_set_aff=
inity(irq_to_desc(ch->irq), cpumask_of(ch->cpu));=0A+    _hpet_msi_set_affi=
nity(ch);=0A }=0A =0A static void hpet_detach_channel(unsigned int =
cpu,=0A@@ -472,7 +482,7 @@ static void hpet_detach_channel(unsigned=0A     =
}=0A =0A     ch->cpu =3D cpumask_first(ch->cpumask);=0A-    hpet_msi_set_af=
finity(irq_to_desc(ch->irq), cpumask_of(ch->cpu));=0A+    _hpet_msi_set_aff=
inity(ch);=0A }=0A =0A #include =0A
--=__PartB081908D.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__PartB081908D.0__=--


From xen-devel-bounces@lists.xen.org Tue Oct 16 15:09:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 15:09:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO8ll-0005gW-3V; Tue, 16 Oct 2012 15:09:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO8lj-0005gP-UH
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 15:09:20 +0000
Received: from [85.158.143.99:60443] by server-1.bemta-4.messagelabs.com id
	3A/FA-19134-F987D705; Tue, 16 Oct 2012 15:09:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1350400158!26160374!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2MDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32395 invoked from network); 16 Oct 2012 15:09:18 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-216.messagelabs.com with SMTP;
	16 Oct 2012 15:09:18 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 16 Oct 2012 16:09:17 +0100
Message-Id: <507D94BD02000078000A1BBD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 16 Oct 2012 16:09:17 +0100
From: "Jan Beulich" 
To: "xen-devel" 
References: <507D93C102000078000A1BAB@nat28.tlf.novell.com>
In-Reply-To: <507D93C102000078000A1BAB@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartB081908D.0__="
Subject: [Xen-devel] [PATCH 1/3] x86/HPET: obtain proper lock for changing
 IRQ affinity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartB081908D.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

The IRQ descriptor lock should be held while adjusting the affinity of
any IRQ; the HPET channel lock isn't sufficient to protect namely
against races with moving the IRQ to a different CPU.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/hpet.c
+++ b/xen/arch/x86/hpet.c
@@ -436,6 +436,16 @@ static struct hpet_event_channel *hpet_g
     return ch;
 }
=20
+static void _hpet_msi_set_affinity(const struct hpet_event_channel *ch)
+{
+    struct irq_desc *desc =3D irq_to_desc(ch->irq);
+
+    ASSERT(!local_irq_is_enabled());
+    spin_lock(&desc->lock);
+    hpet_msi_set_affinity(desc, cpumask_of(ch->cpu));
+    spin_unlock(&desc->lock);
+}
+
 static void hpet_attach_channel(unsigned int cpu,
                                 struct hpet_event_channel *ch)
 {
@@ -450,7 +460,7 @@ static void hpet_attach_channel(unsigned
     if ( ch->cpu !=3D cpu )
         return;
=20
-    hpet_msi_set_affinity(irq_to_desc(ch->irq), cpumask_of(ch->cpu));
+    _hpet_msi_set_affinity(ch);
 }
=20
 static void hpet_detach_channel(unsigned int cpu,
@@ -472,7 +482,7 @@ static void hpet_detach_channel(unsigned
     }
=20
     ch->cpu =3D cpumask_first(ch->cpumask);
-    hpet_msi_set_affinity(irq_to_desc(ch->irq), cpumask_of(ch->cpu));
+    _hpet_msi_set_affinity(ch);
 }
=20
 #include 




--=__PartB081908D.0__=
Content-Type: text/plain; name="x86-HPET-affinity-lock.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-HPET-affinity-lock.patch"

x86/HPET: obtain proper lock for changing IRQ affinity=0A=0AThe IRQ =
descriptor lock should be held while adjusting the affinity of=0Aany IRQ; =
the HPET channel lock isn't sufficient to protect namely=0Aagainst races =
with moving the IRQ to a different CPU.=0A=0ASigned-off-by: Jan Beulich =
=0A=0A--- a/xen/arch/x86/hpet.c=0A+++ b/xen/arch/x86/hpe=
t.c=0A@@ -436,6 +436,16 @@ static struct hpet_event_channel *hpet_g=0A     =
return ch;=0A }=0A =0A+static void _hpet_msi_set_affinity(const struct =
hpet_event_channel *ch)=0A+{=0A+    struct irq_desc *desc =3D irq_to_desc(c=
h->irq);=0A+=0A+    ASSERT(!local_irq_is_enabled());=0A+    spin_lock(&desc=
->lock);=0A+    hpet_msi_set_affinity(desc, cpumask_of(ch->cpu));=0A+    =
spin_unlock(&desc->lock);=0A+}=0A+=0A static void hpet_attach_channel(unsig=
ned int cpu,=0A                                 struct hpet_event_channel =
*ch)=0A {=0A@@ -450,7 +460,7 @@ static void hpet_attach_channel(unsigned=0A=
     if ( ch->cpu !=3D cpu )=0A         return;=0A =0A-    hpet_msi_set_aff=
inity(irq_to_desc(ch->irq), cpumask_of(ch->cpu));=0A+    _hpet_msi_set_affi=
nity(ch);=0A }=0A =0A static void hpet_detach_channel(unsigned int =
cpu,=0A@@ -472,7 +482,7 @@ static void hpet_detach_channel(unsigned=0A     =
}=0A =0A     ch->cpu =3D cpumask_first(ch->cpumask);=0A-    hpet_msi_set_af=
finity(irq_to_desc(ch->irq), cpumask_of(ch->cpu));=0A+    _hpet_msi_set_aff=
inity(ch);=0A }=0A =0A #include =0A
--=__PartB081908D.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__PartB081908D.0__=--


From xen-devel-bounces@lists.xen.org Tue Oct 16 15:10:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 15:10:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO8mr-0005lv-Qs; Tue, 16 Oct 2012 15:10:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO8mq-0005lo-M7
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 15:10:29 +0000
Received: from [85.158.143.99:6354] by server-2.bemta-4.messagelabs.com id
	52/90-22268-4E87D705; Tue, 16 Oct 2012 15:10:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1350400224!23102281!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2MDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6250 invoked from network); 16 Oct 2012 15:10:25 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-216.messagelabs.com with SMTP;
	16 Oct 2012 15:10:25 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 16 Oct 2012 16:10:24 +0100
Message-Id: <507D94FE02000078000A1BC1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 16 Oct 2012 16:10:22 +0100
From: "Jan Beulich" 
To: "xen-devel" 
References: <507D93C102000078000A1BAB@nat28.tlf.novell.com>
In-Reply-To: <507D93C102000078000A1BAB@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartF3C2D3CE.1__="
Cc: xiantao.zhang@intel.com
Subject: [Xen-devel] [PATCH 2/3] x86/HPET: allow use for broadcast when
 interrupt remapping is in effect
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartF3C2D3CE.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This requires some additions to the VT-d side; AMD IOMMUs use the
"normal" MSI message format even when interrupt remapping is enabled,
thus making adjustments here unnecessary.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/acpi/boot.c
+++ b/xen/arch/x86/acpi/boot.c
@@ -276,6 +276,7 @@ static int __init acpi_parse_hpet(struct
 	}
=20
 	hpet_address =3D hpet_tbl->address.address;
+	hpet_blockid =3D hpet_tbl->sequence;
 	printk(KERN_INFO PREFIX "HPET id: %#x base: %#lx\n",
 	       hpet_tbl->id, hpet_address);
=20
--- a/xen/arch/x86/hpet.c
+++ b/xen/arch/x86/hpet.c
@@ -40,7 +40,7 @@ struct hpet_event_channel
=20
     unsigned int idx;   /* physical channel idx */
     unsigned int cpu;   /* msi target */
-    int irq;            /* msi irq */
+    struct msi_desc msi;/* msi state */
     unsigned int flags; /* HPET_EVT_x */
 } __cacheline_aligned;
 static struct hpet_event_channel *__read_mostly hpet_events;
@@ -51,6 +51,7 @@ static unsigned int __read_mostly num_hp
 DEFINE_PER_CPU(struct hpet_event_channel *, cpu_bc_channel);
=20
 unsigned long __read_mostly hpet_address;
+u8 __initdata hpet_blockid;
=20
 /*
  * force_hpet_broadcast: by default legacy hpet broadcast will be stopped
@@ -252,6 +253,8 @@ static void hpet_msi_mask(struct irq_des
=20
 static void hpet_msi_write(struct hpet_event_channel *ch, struct msi_msg =
*msg)
 {
+    if ( iommu_intremap )
+        iommu_update_ire_from_msi(&ch->msi, msg);
     hpet_write32(msg->data, HPET_Tn_ROUTE(ch->idx));
     hpet_write32(msg->address_lo, HPET_Tn_ROUTE(ch->idx) + 4);
 }
@@ -261,6 +264,8 @@ static void hpet_msi_read(struct hpet_ev
     msg->data =3D hpet_read32(HPET_Tn_ROUTE(ch->idx));
     msg->address_lo =3D hpet_read32(HPET_Tn_ROUTE(ch->idx) + 4);
     msg->address_hi =3D 0;
+    if ( iommu_intremap )
+        iommu_read_msi_from_ire(&ch->msi, msg);
 }
=20
 static unsigned int hpet_msi_startup(struct irq_desc *desc)
@@ -292,6 +297,7 @@ static void hpet_msi_set_affinity(struct
     msg.data |=3D MSI_DATA_VECTOR(desc->arch.vector);
     msg.address_lo &=3D ~MSI_ADDR_DEST_ID_MASK;
     msg.address_lo |=3D MSI_ADDR_DEST_ID(dest);
+    msg.dest32 =3D dest;
     hpet_msi_write(desc->action->dev_id, &msg);
 }
=20
@@ -316,35 +322,48 @@ static void __hpet_setup_msi_irq(struct=20
     hpet_msi_write(desc->action->dev_id, &msg);
 }
=20
-static int __init hpet_setup_msi_irq(unsigned int irq, struct hpet_event_c=
hannel *ch)
+static int __init hpet_setup_msi_irq(struct hpet_event_channel *ch)
 {
     int ret;
-    irq_desc_t *desc =3D irq_to_desc(irq);
+    irq_desc_t *desc =3D irq_to_desc(ch->msi.irq);
+
+    if ( iommu_intremap )
+    {
+        ch->msi.hpet_id =3D hpet_blockid;
+        ret =3D iommu_setup_hpet_msi(&ch->msi);
+        if ( ret )
+            return ret;
+    }
=20
     desc->handler =3D &hpet_msi_type;
-    ret =3D request_irq(irq, hpet_interrupt_handler, 0, "HPET", ch);
+    ret =3D request_irq(ch->msi.irq, hpet_interrupt_handler, 0, "HPET", =
ch);
     if ( ret < 0 )
+    {
+        if ( iommu_intremap )
+            iommu_update_ire_from_msi(&ch->msi, NULL);
         return ret;
+    }
=20
     __hpet_setup_msi_irq(desc);
=20
     return 0;
 }
=20
-static int __init hpet_assign_irq(unsigned int idx)
+static int __init hpet_assign_irq(struct hpet_event_channel *ch)
 {
     int irq;
=20
     if ( (irq =3D create_irq(NUMA_NO_NODE)) < 0 )
         return irq;
=20
-    if ( hpet_setup_msi_irq(irq, hpet_events + idx) )
+    ch->msi.irq =3D irq;
+    if ( hpet_setup_msi_irq(ch) )
     {
         destroy_irq(irq);
         return -EINVAL;
     }
=20
-    return irq;
+    return 0;
 }
=20
 static void __init hpet_fsb_cap_lookup(void)
@@ -352,14 +371,6 @@ static void __init hpet_fsb_cap_lookup(v
     u32 id;
     unsigned int i, num_chs;
=20
-    /* TODO. */
-    if ( iommu_intremap )
-    {
-        printk(XENLOG_INFO "HPET's MSI mode hasn't been supported when "
-            "Interrupt Remapping is enabled.\n");
-        return;
-    }
-
     id =3D hpet_read32(HPET_ID);
=20
     num_chs =3D ((id & HPET_ID_NUMBER) >> HPET_ID_NUMBER_SHIFT);
@@ -391,8 +402,8 @@ static void __init hpet_fsb_cap_lookup(v
         ch->flags =3D 0;
         ch->idx =3D i;
=20
-        if ( (ch->irq =3D hpet_assign_irq(num_hpets_used++)) < 0 )
-            num_hpets_used--;
+        if ( hpet_assign_irq(ch) =3D=3D 0 )
+            num_hpets_used++;
     }
=20
     printk(XENLOG_INFO "HPET: %u timers (%u will be used for broadcast)\n"=
,
@@ -438,7 +449,7 @@ static struct hpet_event_channel *hpet_g
=20
 static void _hpet_msi_set_affinity(const struct hpet_event_channel *ch)
 {
-    struct irq_desc *desc =3D irq_to_desc(ch->irq);
+    struct irq_desc *desc =3D irq_to_desc(ch->msi.irq);
=20
     ASSERT(!local_irq_is_enabled());
     spin_lock(&desc->lock);
@@ -530,7 +541,7 @@ void __init hpet_broadcast_init(void)
             hpet_events =3D xzalloc(struct hpet_event_channel);
         if ( !hpet_events || !zalloc_cpumask_var(&hpet_events->cpumask) )
             return;
-        hpet_events->irq =3D -1;
+        hpet_events->msi.irq =3D -1;
=20
         /* Start HPET legacy interrupts */
         cfg |=3D HPET_CFG_LEGACY;
@@ -598,8 +609,8 @@ void hpet_broadcast_resume(void)
=20
     for ( i =3D 0; i < n; i++ )
     {
-        if ( hpet_events[i].irq >=3D 0 )
-            __hpet_setup_msi_irq(irq_to_desc(hpet_events[i].irq));
+        if ( hpet_events[i].msi.irq >=3D 0 )
+            __hpet_setup_msi_irq(irq_to_desc(hpet_events[i].msi.irq));
=20
         /* set HPET Tn as oneshot */
         cfg =3D hpet_read32(HPET_Tn_CFG(hpet_events[i].idx));
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -495,6 +495,12 @@ unsigned int iommu_read_apic_from_ire(un
     return ops->read_apic_from_ire(apic, reg);
 }
=20
+int __init iommu_setup_hpet_msi(struct msi_desc *msi)
+{
+    const struct iommu_ops *ops =3D iommu_get_ops();
+    return ops->setup_hpet_msi ? ops->setup_hpet_msi(msi) : 0;
+}
+
 void iommu_resume()
 {
     const struct iommu_ops *ops =3D iommu_get_ops();
--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -147,6 +147,34 @@ struct iommu * ioapic_to_iommu(unsigned=20
     return NULL;
 }
=20
+static bool_t acpi_hpet_device_match(
+    struct list_head *list, unsigned int hpet_id)
+{
+    struct acpi_hpet_unit *hpet;
+
+    list_for_each_entry( hpet, list, list )
+        if (hpet->id =3D=3D hpet_id)
+            return 1;
+    return 0;
+}
+
+struct acpi_drhd_unit *hpet_to_drhd(unsigned int hpet_id)
+{
+    struct acpi_drhd_unit *drhd;
+
+    list_for_each_entry( drhd, &acpi_drhd_units, list )
+        if ( acpi_hpet_device_match(&drhd->hpet_list, hpet_id) )
+            return drhd;
+    return NULL;
+}
+
+struct iommu *hpet_to_iommu(unsigned int hpet_id)
+{
+    struct acpi_drhd_unit *drhd =3D hpet_to_drhd(hpet_id);
+
+    return drhd ? drhd->iommu : NULL;
+}
+
 static int __init acpi_register_atsr_unit(struct acpi_atsr_unit *atsr)
 {
     /*
@@ -330,6 +358,22 @@ static int __init acpi_parse_dev_scope(
             if ( iommu_verbose )
                 dprintk(VTDPREFIX, " MSI HPET: %04x:%02x:%02x.%u\n",
                         seg, bus, path->dev, path->fn);
+
+            if ( type =3D=3D DMAR_TYPE )
+            {
+                struct acpi_drhd_unit *drhd =3D acpi_entry;
+                struct acpi_hpet_unit *acpi_hpet_unit;
+
+                acpi_hpet_unit =3D xmalloc(struct acpi_hpet_unit);
+                if ( !acpi_hpet_unit )
+                    return -ENOMEM;
+                acpi_hpet_unit->id =3D acpi_scope->enumeration_id;
+                acpi_hpet_unit->bus =3D bus;
+                acpi_hpet_unit->dev =3D path->dev;
+                acpi_hpet_unit->func =3D path->fn;
+                list_add(&acpi_hpet_unit->list, &drhd->hpet_list);
+            }
+
             break;
=20
         case ACPI_DMAR_SCOPE_TYPE_ENDPOINT:
@@ -407,6 +451,7 @@ acpi_parse_one_drhd(struct acpi_dmar_hea
     dmaru->segment =3D drhd->segment;
     dmaru->include_all =3D drhd->flags & ACPI_DMAR_INCLUDE_ALL;
     INIT_LIST_HEAD(&dmaru->ioapic_list);
+    INIT_LIST_HEAD(&dmaru->hpet_list);
     if ( iommu_verbose )
         dprintk(VTDPREFIX, "  dmaru->address =3D %"PRIx64"\n",
                 dmaru->address);
--- a/xen/drivers/passthrough/vtd/dmar.h
+++ b/xen/drivers/passthrough/vtd/dmar.h
@@ -39,6 +39,19 @@ struct acpi_ioapic_unit {
     }ioapic;
 };
=20
+struct acpi_hpet_unit {
+    struct list_head list;
+    unsigned int id;
+    union {
+        u16 bdf;
+        struct {
+            u16 func: 3,
+                dev:  5,
+                bus:  8;
+        };
+    };
+};
+
 struct dmar_scope {
     DECLARE_BITMAP(buses, 256);         /* buses owned by this unit */
     u16    *devices;                    /* devices owned by this unit */
@@ -53,6 +66,7 @@ struct acpi_drhd_unit {
     u8     include_all:1;
     struct iommu *iommu;
     struct list_head ioapic_list;
+    struct list_head hpet_list;
 };
=20
 struct acpi_rmrr_unit {
--- a/xen/drivers/passthrough/vtd/extern.h
+++ b/xen/drivers/passthrough/vtd/extern.h
@@ -54,7 +54,9 @@ int iommu_flush_iec_index(struct iommu *
 void clear_fault_bits(struct iommu *iommu);
=20
 struct iommu * ioapic_to_iommu(unsigned int apic_id);
+struct iommu * hpet_to_iommu(unsigned int hpet_id);
 struct acpi_drhd_unit * ioapic_to_drhd(unsigned int apic_id);
+struct acpi_drhd_unit * hpet_to_drhd(unsigned int hpet_id);
 struct acpi_drhd_unit * iommu_to_drhd(struct iommu *iommu);
 struct acpi_rhsa_unit * drhd_to_rhsa(struct acpi_drhd_unit *drhd);
=20
@@ -90,6 +92,8 @@ struct msi_msg;
 void msi_msg_read_remap_rte(struct msi_desc *, struct msi_msg *);
 void msi_msg_write_remap_rte(struct msi_desc *, struct msi_msg *);
=20
+int intel_setup_hpet_msi(struct msi_desc *);
+
 int is_igd_vt_enabled_quirk(void);
 void platform_quirks_init(void);
 void vtd_ops_preamble_quirk(struct iommu* iommu);
--- a/xen/drivers/passthrough/vtd/intremap.c
+++ b/xen/drivers/passthrough/vtd/intremap.c
@@ -107,6 +107,19 @@ static u16 apicid_to_bdf(int apic_id)
     return 0;
 }
=20
+static u16 hpetid_to_bdf(unsigned int hpet_id)
+{
+    struct acpi_drhd_unit *drhd =3D hpet_to_drhd(hpet_id);
+    struct acpi_hpet_unit *acpi_hpet_unit;
+
+    list_for_each_entry ( acpi_hpet_unit, &drhd->hpet_list, list )
+        if ( acpi_hpet_unit->id =3D=3D hpet_id )
+            return acpi_hpet_unit->bdf;
+
+    dprintk(XENLOG_ERR VTDPREFIX, "Didn't find the bdf for HPET %u!\n", =
hpet_id);
+    return 0;
+}
+
 static void set_ire_sid(struct iremap_entry *ire,
                         unsigned int svt, unsigned int sq, unsigned int =
sid)
 {
@@ -121,6 +134,16 @@ static void set_ioapic_source_id(int api
                 apicid_to_bdf(apic_id));
 }
=20
+static void set_hpet_source_id(unsigned int id, struct iremap_entry *ire)
+{
+    /*
+     * Should really use SQ_ALL_16. Some platforms are broken.
+     * While we figure out the right quirks for these broken platforms, =
use
+     * SQ_13_IGNORE_3 for now.
+     */
+    set_ire_sid(ire, SVT_VERIFY_SID_SQ, SQ_13_IGNORE_3, hpetid_to_bdf(id))=
;
+}
+
 int iommu_supports_eim(void)
 {
     struct acpi_drhd_unit *drhd;
@@ -592,7 +615,10 @@ static int msi_msg_to_remap_entry(
         new_ire.lo.dst =3D ((msg->address_lo >> MSI_ADDR_DEST_ID_SHIFT)
                           & 0xff) << 8;
=20
-    set_msi_source_id(pdev, &new_ire);
+    if ( pdev )
+        set_msi_source_id(pdev, &new_ire);
+    else
+        set_hpet_source_id(msi_desc->hpet_id, &new_ire);
     new_ire.hi.res_1 =3D 0;
     new_ire.lo.p =3D 1;    /* finally, set present bit */
=20
@@ -624,7 +650,9 @@ void msi_msg_read_remap_rte(
     struct iommu *iommu =3D NULL;
     struct ir_ctrl *ir_ctrl;
=20
-    if ( (drhd =3D acpi_find_matched_drhd_unit(pdev)) =3D=3D NULL )
+    drhd =3D pdev ? acpi_find_matched_drhd_unit(pdev)
+                : hpet_to_drhd(msi_desc->hpet_id);
+    if ( !drhd )
         return;
     iommu =3D drhd->iommu;
=20
@@ -643,7 +671,9 @@ void msi_msg_write_remap_rte(
     struct iommu *iommu =3D NULL;
     struct ir_ctrl *ir_ctrl;
=20
-    if ( (drhd =3D acpi_find_matched_drhd_unit(pdev)) =3D=3D NULL )
+    drhd =3D pdev ? acpi_find_matched_drhd_unit(pdev)
+                : hpet_to_drhd(msi_desc->hpet_id);
+    if ( !drhd )
         return;
     iommu =3D drhd->iommu;
=20
@@ -654,6 +684,32 @@ void msi_msg_write_remap_rte(
     msi_msg_to_remap_entry(iommu, pdev, msi_desc, msg);
 }
=20
+int __init intel_setup_hpet_msi(struct msi_desc *msi_desc)
+{
+    struct iommu *iommu =3D hpet_to_iommu(msi_desc->hpet_id);
+    struct ir_ctrl *ir_ctrl =3D iommu_ir_ctrl(iommu);
+    unsigned long flags;
+    int rc =3D 0;
+
+    if ( !ir_ctrl || !ir_ctrl->iremap_maddr )
+        return 0;
+
+    spin_lock_irqsave(&ir_ctrl->iremap_lock, flags);
+    msi_desc->remap_index =3D alloc_remap_entry(iommu);
+    if ( msi_desc->remap_index >=3D IREMAP_ENTRY_NR )
+    {
+        dprintk(XENLOG_ERR VTDPREFIX,
+                "%s: intremap index (%d) is larger than"
+                " the maximum index (%d)!\n",
+                __func__, msi_desc->remap_index, IREMAP_ENTRY_NR - 1);
+        msi_desc->remap_index =3D -1;
+        rc =3D -ENXIO;
+    }
+    spin_unlock_irqrestore(&ir_ctrl->iremap_lock, flags);
+
+    return rc;
+}
+
 int enable_intremap(struct iommu *iommu, int eim)
 {
     struct acpi_drhd_unit *drhd;
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -2396,6 +2396,7 @@ const struct iommu_ops intel_iommu_ops =3D
     .update_ire_from_msi =3D msi_msg_write_remap_rte,
     .read_apic_from_ire =3D io_apic_read_remap_rte,
     .read_msi_from_ire =3D msi_msg_read_remap_rte,
+    .setup_hpet_msi =3D intel_setup_hpet_msi,
     .suspend =3D vtd_suspend,
     .resume =3D vtd_resume,
     .share_p2m =3D iommu_set_pgd,
--- a/xen/include/asm-x86/hpet.h
+++ b/xen/include/asm-x86/hpet.h
@@ -53,6 +53,7 @@
     (*(volatile u32 *)(fix_to_virt(FIX_HPET_BASE) + (x)) =3D (y))
=20
 extern unsigned long hpet_address;
+extern u8 hpet_blockid;
=20
 /*
  * Detect and initialise HPET hardware: return counter update frequency.
--- a/xen/include/asm-x86/msi.h
+++ b/xen/include/asm-x86/msi.h
@@ -97,7 +97,10 @@ struct msi_desc {
=20
 	struct list_head list;
=20
-	void __iomem *mask_base;        /* va for the entry in mask table =
*/
+	union {
+		void __iomem *mask_base;/* va for the entry in mask table =
*/
+		unsigned int hpet_id;   /* HPET (dev is NULL)             =
*/
+	};
 	struct pci_dev *dev;
 	int irq;
=20
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -109,6 +109,7 @@ struct iommu_ops {
     void (*update_ire_from_msi)(struct msi_desc *msi_desc, struct msi_msg =
*msg);
     void (*read_msi_from_ire)(struct msi_desc *msi_desc, struct msi_msg =
*msg);
     unsigned int (*read_apic_from_ire)(unsigned int apic, unsigned int =
reg);
+    int (*setup_hpet_msi)(struct msi_desc *);
     void (*suspend)(void);
     void (*resume)(void);
     void (*share_p2m)(struct domain *d);
@@ -122,6 +123,7 @@ void iommu_update_ire_from_apic(unsigned
 void iommu_update_ire_from_msi(struct msi_desc *msi_desc, struct msi_msg =
*msg);
 void iommu_read_msi_from_ire(struct msi_desc *msi_desc, struct msi_msg =
*msg);
 unsigned int iommu_read_apic_from_ire(unsigned int apic, unsigned int =
reg);
+int iommu_setup_hpet_msi(struct msi_desc *);
=20
 void iommu_suspend(void);
 void iommu_resume(void);



--=__PartF3C2D3CE.1__=
Content-Type: text/plain; name="x86-HPET-intremap.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-HPET-intremap.patch"

x86/HPET: allow use for broadcast when interrupt remapping is in =
effect=0A=0AThis requires some additions to the VT-d side; AMD IOMMUs use =
the=0A"normal" MSI message format even when interrupt remapping is =
enabled,=0Athus making adjustments here unnecessary.=0A=0ASigned-off-by: =
Jan Beulich =0A=0A--- a/xen/arch/x86/acpi/boot.c=0A+++ =
b/xen/arch/x86/acpi/boot.c=0A@@ -276,6 +276,7 @@ static int __init =
acpi_parse_hpet(struct=0A 	}=0A =0A 	hpet_address =3D hpet_tbl->=
address.address;=0A+	hpet_blockid =3D hpet_tbl->sequence;=0A 	=
printk(KERN_INFO PREFIX "HPET id: %#x base: %#lx\n",=0A 	       =
hpet_tbl->id, hpet_address);=0A =0A--- a/xen/arch/x86/hpet.c=0A+++ =
b/xen/arch/x86/hpet.c=0A@@ -40,7 +40,7 @@ struct hpet_event_channel=0A =0A =
    unsigned int idx;   /* physical channel idx */=0A     unsigned int =
cpu;   /* msi target */=0A-    int irq;            /* msi irq */=0A+    =
struct msi_desc msi;/* msi state */=0A     unsigned int flags; /* =
HPET_EVT_x */=0A } __cacheline_aligned;=0A static struct hpet_event_channel=
 *__read_mostly hpet_events;=0A@@ -51,6 +51,7 @@ static unsigned int =
__read_mostly num_hp=0A DEFINE_PER_CPU(struct hpet_event_channel *, =
cpu_bc_channel);=0A =0A unsigned long __read_mostly hpet_address;=0A+u8 =
__initdata hpet_blockid;=0A =0A /*=0A  * force_hpet_broadcast: by default =
legacy hpet broadcast will be stopped=0A@@ -252,6 +253,8 @@ static void =
hpet_msi_mask(struct irq_des=0A =0A static void hpet_msi_write(struct =
hpet_event_channel *ch, struct msi_msg *msg)=0A {=0A+    if ( iommu_intrema=
p )=0A+        iommu_update_ire_from_msi(&ch->msi, msg);=0A     hpet_write3=
2(msg->data, HPET_Tn_ROUTE(ch->idx));=0A     hpet_write32(msg->address_lo, =
HPET_Tn_ROUTE(ch->idx) + 4);=0A }=0A@@ -261,6 +264,8 @@ static void =
hpet_msi_read(struct hpet_ev=0A     msg->data =3D hpet_read32(HPET_Tn_ROUTE=
(ch->idx));=0A     msg->address_lo =3D hpet_read32(HPET_Tn_ROUTE(ch->idx) =
+ 4);=0A     msg->address_hi =3D 0;=0A+    if ( iommu_intremap )=0A+       =
 iommu_read_msi_from_ire(&ch->msi, msg);=0A }=0A =0A static unsigned int =
hpet_msi_startup(struct irq_desc *desc)=0A@@ -292,6 +297,7 @@ static void =
hpet_msi_set_affinity(struct=0A     msg.data |=3D MSI_DATA_VECTOR(desc->arc=
h.vector);=0A     msg.address_lo &=3D ~MSI_ADDR_DEST_ID_MASK;=0A     =
msg.address_lo |=3D MSI_ADDR_DEST_ID(dest);=0A+    msg.dest32 =3D dest;=0A =
    hpet_msi_write(desc->action->dev_id, &msg);=0A }=0A =0A@@ -316,35 =
+322,48 @@ static void __hpet_setup_msi_irq(struct =0A     hpet_msi_write(d=
esc->action->dev_id, &msg);=0A }=0A =0A-static int __init hpet_setup_msi_ir=
q(unsigned int irq, struct hpet_event_channel *ch)=0A+static int __init =
hpet_setup_msi_irq(struct hpet_event_channel *ch)=0A {=0A     int ret;=0A- =
   irq_desc_t *desc =3D irq_to_desc(irq);=0A+    irq_desc_t *desc =3D =
irq_to_desc(ch->msi.irq);=0A+=0A+    if ( iommu_intremap )=0A+    {=0A+    =
    ch->msi.hpet_id =3D hpet_blockid;=0A+        ret =3D iommu_setup_hpet_m=
si(&ch->msi);=0A+        if ( ret )=0A+            return ret;=0A+    }=0A =
=0A     desc->handler =3D &hpet_msi_type;=0A-    ret =3D request_irq(irq, =
hpet_interrupt_handler, 0, "HPET", ch);=0A+    ret =3D request_irq(ch->msi.=
irq, hpet_interrupt_handler, 0, "HPET", ch);=0A     if ( ret < 0 )=0A+    =
{=0A+        if ( iommu_intremap )=0A+            iommu_update_ire_from_msi=
(&ch->msi, NULL);=0A         return ret;=0A+    }=0A =0A     __hpet_setup_m=
si_irq(desc);=0A =0A     return 0;=0A }=0A =0A-static int __init hpet_assig=
n_irq(unsigned int idx)=0A+static int __init hpet_assign_irq(struct =
hpet_event_channel *ch)=0A {=0A     int irq;=0A =0A     if ( (irq =3D =
create_irq(NUMA_NO_NODE)) < 0 )=0A         return irq;=0A =0A-    if ( =
hpet_setup_msi_irq(irq, hpet_events + idx) )=0A+    ch->msi.irq =3D =
irq;=0A+    if ( hpet_setup_msi_irq(ch) )=0A     {=0A         destroy_irq(i=
rq);=0A         return -EINVAL;=0A     }=0A =0A-    return irq;=0A+    =
return 0;=0A }=0A =0A static void __init hpet_fsb_cap_lookup(void)=0A@@ =
-352,14 +371,6 @@ static void __init hpet_fsb_cap_lookup(v=0A     u32 =
id;=0A     unsigned int i, num_chs;=0A =0A-    /* TODO. */=0A-    if ( =
iommu_intremap )=0A-    {=0A-        printk(XENLOG_INFO "HPET's MSI mode =
hasn't been supported when "=0A-            "Interrupt Remapping is =
enabled.\n");=0A-        return;=0A-    }=0A-=0A     id =3D hpet_read32(HPE=
T_ID);=0A =0A     num_chs =3D ((id & HPET_ID_NUMBER) >> HPET_ID_NUMBER_SHIF=
T);=0A@@ -391,8 +402,8 @@ static void __init hpet_fsb_cap_lookup(v=0A      =
   ch->flags =3D 0;=0A         ch->idx =3D i;=0A =0A-        if ( (ch->irq =
=3D hpet_assign_irq(num_hpets_used++)) < 0 )=0A-            num_hpets_used-=
-;=0A+        if ( hpet_assign_irq(ch) =3D=3D 0 )=0A+            num_hpets_=
used++;=0A     }=0A =0A     printk(XENLOG_INFO "HPET: %u timers (%u will =
be used for broadcast)\n",=0A@@ -438,7 +449,7 @@ static struct hpet_event_c=
hannel *hpet_g=0A =0A static void _hpet_msi_set_affinity(const struct =
hpet_event_channel *ch)=0A {=0A-    struct irq_desc *desc =3D irq_to_desc(c=
h->irq);=0A+    struct irq_desc *desc =3D irq_to_desc(ch->msi.irq);=0A =0A =
    ASSERT(!local_irq_is_enabled());=0A     spin_lock(&desc->lock);=0A@@ =
-530,7 +541,7 @@ void __init hpet_broadcast_init(void)=0A             =
hpet_events =3D xzalloc(struct hpet_event_channel);=0A         if ( =
!hpet_events || !zalloc_cpumask_var(&hpet_events->cpumask) )=0A            =
 return;=0A-        hpet_events->irq =3D -1;=0A+        hpet_events->msi.ir=
q =3D -1;=0A =0A         /* Start HPET legacy interrupts */=0A         cfg =
|=3D HPET_CFG_LEGACY;=0A@@ -598,8 +609,8 @@ void hpet_broadcast_resume(void=
)=0A =0A     for ( i =3D 0; i < n; i++ )=0A     {=0A-        if ( =
hpet_events[i].irq >=3D 0 )=0A-            __hpet_setup_msi_irq(irq_to_desc=
(hpet_events[i].irq));=0A+        if ( hpet_events[i].msi.irq >=3D 0 )=0A+ =
           __hpet_setup_msi_irq(irq_to_desc(hpet_events[i].msi.irq));=0A =
=0A         /* set HPET Tn as oneshot */=0A         cfg =3D hpet_read32(HPE=
T_Tn_CFG(hpet_events[i].idx));=0A--- a/xen/drivers/passthrough/iommu.c=0A++=
+ b/xen/drivers/passthrough/iommu.c=0A@@ -495,6 +495,12 @@ unsigned int =
iommu_read_apic_from_ire(un=0A     return ops->read_apic_from_ire(apic, =
reg);=0A }=0A =0A+int __init iommu_setup_hpet_msi(struct msi_desc =
*msi)=0A+{=0A+    const struct iommu_ops *ops =3D iommu_get_ops();=0A+    =
return ops->setup_hpet_msi ? ops->setup_hpet_msi(msi) : 0;=0A+}=0A+=0A =
void iommu_resume()=0A {=0A     const struct iommu_ops *ops =3D iommu_get_o=
ps();=0A--- a/xen/drivers/passthrough/vtd/dmar.c=0A+++ b/xen/drivers/passth=
rough/vtd/dmar.c=0A@@ -147,6 +147,34 @@ struct iommu * ioapic_to_iommu(unsi=
gned =0A     return NULL;=0A }=0A =0A+static bool_t acpi_hpet_device_match(=
=0A+    struct list_head *list, unsigned int hpet_id)=0A+{=0A+    struct =
acpi_hpet_unit *hpet;=0A+=0A+    list_for_each_entry( hpet, list, list =
)=0A+        if (hpet->id =3D=3D hpet_id)=0A+            return 1;=0A+    =
return 0;=0A+}=0A+=0A+struct acpi_drhd_unit *hpet_to_drhd(unsigned int =
hpet_id)=0A+{=0A+    struct acpi_drhd_unit *drhd;=0A+=0A+    list_for_each_=
entry( drhd, &acpi_drhd_units, list )=0A+        if ( acpi_hpet_device_matc=
h(&drhd->hpet_list, hpet_id) )=0A+            return drhd;=0A+    return =
NULL;=0A+}=0A+=0A+struct iommu *hpet_to_iommu(unsigned int hpet_id)=0A+{=0A=
+    struct acpi_drhd_unit *drhd =3D hpet_to_drhd(hpet_id);=0A+=0A+    =
return drhd ? drhd->iommu : NULL;=0A+}=0A+=0A static int __init acpi_regist=
er_atsr_unit(struct acpi_atsr_unit *atsr)=0A {=0A     /*=0A@@ -330,6 =
+358,22 @@ static int __init acpi_parse_dev_scope(=0A             if ( =
iommu_verbose )=0A                 dprintk(VTDPREFIX, " MSI HPET: =
%04x:%02x:%02x.%u\n",=0A                         seg, bus, path->dev, =
path->fn);=0A+=0A+            if ( type =3D=3D DMAR_TYPE )=0A+            =
{=0A+                struct acpi_drhd_unit *drhd =3D acpi_entry;=0A+       =
         struct acpi_hpet_unit *acpi_hpet_unit;=0A+=0A+                =
acpi_hpet_unit =3D xmalloc(struct acpi_hpet_unit);=0A+                if ( =
!acpi_hpet_unit )=0A+                    return -ENOMEM;=0A+               =
 acpi_hpet_unit->id =3D acpi_scope->enumeration_id;=0A+                =
acpi_hpet_unit->bus =3D bus;=0A+                acpi_hpet_unit->dev =3D =
path->dev;=0A+                acpi_hpet_unit->func =3D path->fn;=0A+       =
         list_add(&acpi_hpet_unit->list, &drhd->hpet_list);=0A+            =
}=0A+=0A             break;=0A =0A         case ACPI_DMAR_SCOPE_TYPE_ENDPOI=
NT:=0A@@ -407,6 +451,7 @@ acpi_parse_one_drhd(struct acpi_dmar_hea=0A     =
dmaru->segment =3D drhd->segment;=0A     dmaru->include_all =3D drhd->flags=
 & ACPI_DMAR_INCLUDE_ALL;=0A     INIT_LIST_HEAD(&dmaru->ioapic_list);=0A+  =
  INIT_LIST_HEAD(&dmaru->hpet_list);=0A     if ( iommu_verbose )=0A        =
 dprintk(VTDPREFIX, "  dmaru->address =3D %"PRIx64"\n",=0A                 =
dmaru->address);=0A--- a/xen/drivers/passthrough/vtd/dmar.h=0A+++ =
b/xen/drivers/passthrough/vtd/dmar.h=0A@@ -39,6 +39,19 @@ struct acpi_ioapi=
c_unit {=0A     }ioapic;=0A };=0A =0A+struct acpi_hpet_unit {=0A+    =
struct list_head list;=0A+    unsigned int id;=0A+    union {=0A+        =
u16 bdf;=0A+        struct {=0A+            u16 func: 3,=0A+               =
 dev:  5,=0A+                bus:  8;=0A+        };=0A+    };=0A+};=0A+=0A =
struct dmar_scope {=0A     DECLARE_BITMAP(buses, 256);         /* buses =
owned by this unit */=0A     u16    *devices;                    /* =
devices owned by this unit */=0A@@ -53,6 +66,7 @@ struct acpi_drhd_unit =
{=0A     u8     include_all:1;=0A     struct iommu *iommu;=0A     struct =
list_head ioapic_list;=0A+    struct list_head hpet_list;=0A };=0A =0A =
struct acpi_rmrr_unit {=0A--- a/xen/drivers/passthrough/vtd/extern.h=0A+++ =
b/xen/drivers/passthrough/vtd/extern.h=0A@@ -54,7 +54,9 @@ int iommu_flush_=
iec_index(struct iommu *=0A void clear_fault_bits(struct iommu *iommu);=0A =
=0A struct iommu * ioapic_to_iommu(unsigned int apic_id);=0A+struct iommu =
* hpet_to_iommu(unsigned int hpet_id);=0A struct acpi_drhd_unit * =
ioapic_to_drhd(unsigned int apic_id);=0A+struct acpi_drhd_unit * hpet_to_dr=
hd(unsigned int hpet_id);=0A struct acpi_drhd_unit * iommu_to_drhd(struct =
iommu *iommu);=0A struct acpi_rhsa_unit * drhd_to_rhsa(struct acpi_drhd_uni=
t *drhd);=0A =0A@@ -90,6 +92,8 @@ struct msi_msg;=0A void msi_msg_read_rema=
p_rte(struct msi_desc *, struct msi_msg *);=0A void msi_msg_write_remap_rte=
(struct msi_desc *, struct msi_msg *);=0A =0A+int intel_setup_hpet_msi(stru=
ct msi_desc *);=0A+=0A int is_igd_vt_enabled_quirk(void);=0A void =
platform_quirks_init(void);=0A void vtd_ops_preamble_quirk(struct iommu* =
iommu);=0A--- a/xen/drivers/passthrough/vtd/intremap.c=0A+++ b/xen/drivers/=
passthrough/vtd/intremap.c=0A@@ -107,6 +107,19 @@ static u16 apicid_to_bdf(=
int apic_id)=0A     return 0;=0A }=0A =0A+static u16 hpetid_to_bdf(unsigned=
 int hpet_id)=0A+{=0A+    struct acpi_drhd_unit *drhd =3D hpet_to_drhd(hpet=
_id);=0A+    struct acpi_hpet_unit *acpi_hpet_unit;=0A+=0A+    list_for_eac=
h_entry ( acpi_hpet_unit, &drhd->hpet_list, list )=0A+        if ( =
acpi_hpet_unit->id =3D=3D hpet_id )=0A+            return acpi_hpet_unit->b=
df;=0A+=0A+    dprintk(XENLOG_ERR VTDPREFIX, "Didn't find the bdf for HPET =
%u!\n", hpet_id);=0A+    return 0;=0A+}=0A+=0A static void set_ire_sid(stru=
ct iremap_entry *ire,=0A                         unsigned int svt, =
unsigned int sq, unsigned int sid)=0A {=0A@@ -121,6 +134,16 @@ static void =
set_ioapic_source_id(int api=0A                 apicid_to_bdf(apic_id));=0A=
 }=0A =0A+static void set_hpet_source_id(unsigned int id, struct iremap_ent=
ry *ire)=0A+{=0A+    /*=0A+     * Should really use SQ_ALL_16. Some =
platforms are broken.=0A+     * While we figure out the right quirks for =
these broken platforms, use=0A+     * SQ_13_IGNORE_3 for now.=0A+     =
*/=0A+    set_ire_sid(ire, SVT_VERIFY_SID_SQ, SQ_13_IGNORE_3, hpetid_to_bdf=
(id));=0A+}=0A+=0A int iommu_supports_eim(void)=0A {=0A     struct =
acpi_drhd_unit *drhd;=0A@@ -592,7 +615,10 @@ static int msi_msg_to_remap_en=
try(=0A         new_ire.lo.dst =3D ((msg->address_lo >> MSI_ADDR_DEST_ID_SH=
IFT)=0A                           & 0xff) << 8;=0A =0A-    set_msi_source_i=
d(pdev, &new_ire);=0A+    if ( pdev )=0A+        set_msi_source_id(pdev, =
&new_ire);=0A+    else=0A+        set_hpet_source_id(msi_desc->hpet_id, =
&new_ire);=0A     new_ire.hi.res_1 =3D 0;=0A     new_ire.lo.p =3D 1;    /* =
finally, set present bit */=0A =0A@@ -624,7 +650,9 @@ void msi_msg_read_rem=
ap_rte(=0A     struct iommu *iommu =3D NULL;=0A     struct ir_ctrl =
*ir_ctrl;=0A =0A-    if ( (drhd =3D acpi_find_matched_drhd_unit(pdev)) =
=3D=3D NULL )=0A+    drhd =3D pdev ? acpi_find_matched_drhd_unit(pdev)=0A+ =
               : hpet_to_drhd(msi_desc->hpet_id);=0A+    if ( !drhd )=0A   =
      return;=0A     iommu =3D drhd->iommu;=0A =0A@@ -643,7 +671,9 @@ void =
msi_msg_write_remap_rte(=0A     struct iommu *iommu =3D NULL;=0A     =
struct ir_ctrl *ir_ctrl;=0A =0A-    if ( (drhd =3D acpi_find_matched_drhd_u=
nit(pdev)) =3D=3D NULL )=0A+    drhd =3D pdev ? acpi_find_matched_drhd_unit=
(pdev)=0A+                : hpet_to_drhd(msi_desc->hpet_id);=0A+    if ( =
!drhd )=0A         return;=0A     iommu =3D drhd->iommu;=0A =0A@@ -654,6 =
+684,32 @@ void msi_msg_write_remap_rte(=0A     msi_msg_to_remap_entry(iomm=
u, pdev, msi_desc, msg);=0A }=0A =0A+int __init intel_setup_hpet_msi(struct=
 msi_desc *msi_desc)=0A+{=0A+    struct iommu *iommu =3D hpet_to_iommu(msi_=
desc->hpet_id);=0A+    struct ir_ctrl *ir_ctrl =3D iommu_ir_ctrl(iommu);=0A=
+    unsigned long flags;=0A+    int rc =3D 0;=0A+=0A+    if ( !ir_ctrl || =
!ir_ctrl->iremap_maddr )=0A+        return 0;=0A+=0A+    spin_lock_irqsave(=
&ir_ctrl->iremap_lock, flags);=0A+    msi_desc->remap_index =3D alloc_remap=
_entry(iommu);=0A+    if ( msi_desc->remap_index >=3D IREMAP_ENTRY_NR =
)=0A+    {=0A+        dprintk(XENLOG_ERR VTDPREFIX,=0A+                =
"%s: intremap index (%d) is larger than"=0A+                " the maximum =
index (%d)!\n",=0A+                __func__, msi_desc->remap_index, =
IREMAP_ENTRY_NR - 1);=0A+        msi_desc->remap_index =3D -1;=0A+        =
rc =3D -ENXIO;=0A+    }=0A+    spin_unlock_irqrestore(&ir_ctrl->iremap_lock=
, flags);=0A+=0A+    return rc;=0A+}=0A+=0A int enable_intremap(struct =
iommu *iommu, int eim)=0A {=0A     struct acpi_drhd_unit *drhd;=0A--- =
a/xen/drivers/passthrough/vtd/iommu.c=0A+++ b/xen/drivers/passthrough/vtd/i=
ommu.c=0A@@ -2396,6 +2396,7 @@ const struct iommu_ops intel_iommu_ops =
=3D=0A     .update_ire_from_msi =3D msi_msg_write_remap_rte,=0A     =
.read_apic_from_ire =3D io_apic_read_remap_rte,=0A     .read_msi_from_ire =
=3D msi_msg_read_remap_rte,=0A+    .setup_hpet_msi =3D intel_setup_hpet_msi=
,=0A     .suspend =3D vtd_suspend,=0A     .resume =3D vtd_resume,=0A     =
.share_p2m =3D iommu_set_pgd,=0A--- a/xen/include/asm-x86/hpet.h=0A+++ =
b/xen/include/asm-x86/hpet.h=0A@@ -53,6 +53,7 @@=0A     (*(volatile u32 =
*)(fix_to_virt(FIX_HPET_BASE) + (x)) =3D (y))=0A =0A extern unsigned long =
hpet_address;=0A+extern u8 hpet_blockid;=0A =0A /*=0A  * Detect and =
initialise HPET hardware: return counter update frequency.=0A--- a/xen/incl=
ude/asm-x86/msi.h=0A+++ b/xen/include/asm-x86/msi.h=0A@@ -97,7 +97,10 @@ =
struct msi_desc {=0A =0A 	struct list_head list;=0A =0A-	void =
__iomem *mask_base;        /* va for the entry in mask table */=0A+	=
union {=0A+		void __iomem *mask_base;/* va for the entry in =
mask table */=0A+		unsigned int hpet_id;   /* HPET (dev is =
NULL)             */=0A+	};=0A 	struct pci_dev *dev;=0A 	=
int irq;=0A =0A--- a/xen/include/xen/iommu.h=0A+++ b/xen/include/xen/iommu.=
h=0A@@ -109,6 +109,7 @@ struct iommu_ops {=0A     void (*update_ire_from_ms=
i)(struct msi_desc *msi_desc, struct msi_msg *msg);=0A     void (*read_msi_=
from_ire)(struct msi_desc *msi_desc, struct msi_msg *msg);=0A     unsigned =
int (*read_apic_from_ire)(unsigned int apic, unsigned int reg);=0A+    int =
(*setup_hpet_msi)(struct msi_desc *);=0A     void (*suspend)(void);=0A     =
void (*resume)(void);=0A     void (*share_p2m)(struct domain *d);=0A@@ =
-122,6 +123,7 @@ void iommu_update_ire_from_apic(unsigned=0A void =
iommu_update_ire_from_msi(struct msi_desc *msi_desc, struct msi_msg =
*msg);=0A void iommu_read_msi_from_ire(struct msi_desc *msi_desc, struct =
msi_msg *msg);=0A unsigned int iommu_read_apic_from_ire(unsigned int apic, =
unsigned int reg);=0A+int iommu_setup_hpet_msi(struct msi_desc *);=0A =0A =
void iommu_suspend(void);=0A void iommu_resume(void);=0A
--=__PartF3C2D3CE.1__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__PartF3C2D3CE.1__=--


From xen-devel-bounces@lists.xen.org Tue Oct 16 15:10:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 15:10:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO8mr-0005lv-Qs; Tue, 16 Oct 2012 15:10:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO8mq-0005lo-M7
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 15:10:29 +0000
Received: from [85.158.143.99:6354] by server-2.bemta-4.messagelabs.com id
	52/90-22268-4E87D705; Tue, 16 Oct 2012 15:10:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1350400224!23102281!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2MDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6250 invoked from network); 16 Oct 2012 15:10:25 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-216.messagelabs.com with SMTP;
	16 Oct 2012 15:10:25 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 16 Oct 2012 16:10:24 +0100
Message-Id: <507D94FE02000078000A1BC1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 16 Oct 2012 16:10:22 +0100
From: "Jan Beulich" 
To: "xen-devel" 
References: <507D93C102000078000A1BAB@nat28.tlf.novell.com>
In-Reply-To: <507D93C102000078000A1BAB@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartF3C2D3CE.1__="
Cc: xiantao.zhang@intel.com
Subject: [Xen-devel] [PATCH 2/3] x86/HPET: allow use for broadcast when
 interrupt remapping is in effect
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartF3C2D3CE.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This requires some additions to the VT-d side; AMD IOMMUs use the
"normal" MSI message format even when interrupt remapping is enabled,
thus making adjustments here unnecessary.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/acpi/boot.c
+++ b/xen/arch/x86/acpi/boot.c
@@ -276,6 +276,7 @@ static int __init acpi_parse_hpet(struct
 	}
=20
 	hpet_address =3D hpet_tbl->address.address;
+	hpet_blockid =3D hpet_tbl->sequence;
 	printk(KERN_INFO PREFIX "HPET id: %#x base: %#lx\n",
 	       hpet_tbl->id, hpet_address);
=20
--- a/xen/arch/x86/hpet.c
+++ b/xen/arch/x86/hpet.c
@@ -40,7 +40,7 @@ struct hpet_event_channel
=20
     unsigned int idx;   /* physical channel idx */
     unsigned int cpu;   /* msi target */
-    int irq;            /* msi irq */
+    struct msi_desc msi;/* msi state */
     unsigned int flags; /* HPET_EVT_x */
 } __cacheline_aligned;
 static struct hpet_event_channel *__read_mostly hpet_events;
@@ -51,6 +51,7 @@ static unsigned int __read_mostly num_hp
 DEFINE_PER_CPU(struct hpet_event_channel *, cpu_bc_channel);
=20
 unsigned long __read_mostly hpet_address;
+u8 __initdata hpet_blockid;
=20
 /*
  * force_hpet_broadcast: by default legacy hpet broadcast will be stopped
@@ -252,6 +253,8 @@ static void hpet_msi_mask(struct irq_des
=20
 static void hpet_msi_write(struct hpet_event_channel *ch, struct msi_msg =
*msg)
 {
+    if ( iommu_intremap )
+        iommu_update_ire_from_msi(&ch->msi, msg);
     hpet_write32(msg->data, HPET_Tn_ROUTE(ch->idx));
     hpet_write32(msg->address_lo, HPET_Tn_ROUTE(ch->idx) + 4);
 }
@@ -261,6 +264,8 @@ static void hpet_msi_read(struct hpet_ev
     msg->data =3D hpet_read32(HPET_Tn_ROUTE(ch->idx));
     msg->address_lo =3D hpet_read32(HPET_Tn_ROUTE(ch->idx) + 4);
     msg->address_hi =3D 0;
+    if ( iommu_intremap )
+        iommu_read_msi_from_ire(&ch->msi, msg);
 }
=20
 static unsigned int hpet_msi_startup(struct irq_desc *desc)
@@ -292,6 +297,7 @@ static void hpet_msi_set_affinity(struct
     msg.data |=3D MSI_DATA_VECTOR(desc->arch.vector);
     msg.address_lo &=3D ~MSI_ADDR_DEST_ID_MASK;
     msg.address_lo |=3D MSI_ADDR_DEST_ID(dest);
+    msg.dest32 =3D dest;
     hpet_msi_write(desc->action->dev_id, &msg);
 }
=20
@@ -316,35 +322,48 @@ static void __hpet_setup_msi_irq(struct=20
     hpet_msi_write(desc->action->dev_id, &msg);
 }
=20
-static int __init hpet_setup_msi_irq(unsigned int irq, struct hpet_event_c=
hannel *ch)
+static int __init hpet_setup_msi_irq(struct hpet_event_channel *ch)
 {
     int ret;
-    irq_desc_t *desc =3D irq_to_desc(irq);
+    irq_desc_t *desc =3D irq_to_desc(ch->msi.irq);
+
+    if ( iommu_intremap )
+    {
+        ch->msi.hpet_id =3D hpet_blockid;
+        ret =3D iommu_setup_hpet_msi(&ch->msi);
+        if ( ret )
+            return ret;
+    }
=20
     desc->handler =3D &hpet_msi_type;
-    ret =3D request_irq(irq, hpet_interrupt_handler, 0, "HPET", ch);
+    ret =3D request_irq(ch->msi.irq, hpet_interrupt_handler, 0, "HPET", =
ch);
     if ( ret < 0 )
+    {
+        if ( iommu_intremap )
+            iommu_update_ire_from_msi(&ch->msi, NULL);
         return ret;
+    }
=20
     __hpet_setup_msi_irq(desc);
=20
     return 0;
 }
=20
-static int __init hpet_assign_irq(unsigned int idx)
+static int __init hpet_assign_irq(struct hpet_event_channel *ch)
 {
     int irq;
=20
     if ( (irq =3D create_irq(NUMA_NO_NODE)) < 0 )
         return irq;
=20
-    if ( hpet_setup_msi_irq(irq, hpet_events + idx) )
+    ch->msi.irq =3D irq;
+    if ( hpet_setup_msi_irq(ch) )
     {
         destroy_irq(irq);
         return -EINVAL;
     }
=20
-    return irq;
+    return 0;
 }
=20
 static void __init hpet_fsb_cap_lookup(void)
@@ -352,14 +371,6 @@ static void __init hpet_fsb_cap_lookup(v
     u32 id;
     unsigned int i, num_chs;
=20
-    /* TODO. */
-    if ( iommu_intremap )
-    {
-        printk(XENLOG_INFO "HPET's MSI mode hasn't been supported when "
-            "Interrupt Remapping is enabled.\n");
-        return;
-    }
-
     id =3D hpet_read32(HPET_ID);
=20
     num_chs =3D ((id & HPET_ID_NUMBER) >> HPET_ID_NUMBER_SHIFT);
@@ -391,8 +402,8 @@ static void __init hpet_fsb_cap_lookup(v
         ch->flags =3D 0;
         ch->idx =3D i;
=20
-        if ( (ch->irq =3D hpet_assign_irq(num_hpets_used++)) < 0 )
-            num_hpets_used--;
+        if ( hpet_assign_irq(ch) =3D=3D 0 )
+            num_hpets_used++;
     }
=20
     printk(XENLOG_INFO "HPET: %u timers (%u will be used for broadcast)\n"=
,
@@ -438,7 +449,7 @@ static struct hpet_event_channel *hpet_g
=20
 static void _hpet_msi_set_affinity(const struct hpet_event_channel *ch)
 {
-    struct irq_desc *desc =3D irq_to_desc(ch->irq);
+    struct irq_desc *desc =3D irq_to_desc(ch->msi.irq);
=20
     ASSERT(!local_irq_is_enabled());
     spin_lock(&desc->lock);
@@ -530,7 +541,7 @@ void __init hpet_broadcast_init(void)
             hpet_events =3D xzalloc(struct hpet_event_channel);
         if ( !hpet_events || !zalloc_cpumask_var(&hpet_events->cpumask) )
             return;
-        hpet_events->irq =3D -1;
+        hpet_events->msi.irq =3D -1;
=20
         /* Start HPET legacy interrupts */
         cfg |=3D HPET_CFG_LEGACY;
@@ -598,8 +609,8 @@ void hpet_broadcast_resume(void)
=20
     for ( i =3D 0; i < n; i++ )
     {
-        if ( hpet_events[i].irq >=3D 0 )
-            __hpet_setup_msi_irq(irq_to_desc(hpet_events[i].irq));
+        if ( hpet_events[i].msi.irq >=3D 0 )
+            __hpet_setup_msi_irq(irq_to_desc(hpet_events[i].msi.irq));
=20
         /* set HPET Tn as oneshot */
         cfg =3D hpet_read32(HPET_Tn_CFG(hpet_events[i].idx));
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -495,6 +495,12 @@ unsigned int iommu_read_apic_from_ire(un
     return ops->read_apic_from_ire(apic, reg);
 }
=20
+int __init iommu_setup_hpet_msi(struct msi_desc *msi)
+{
+    const struct iommu_ops *ops =3D iommu_get_ops();
+    return ops->setup_hpet_msi ? ops->setup_hpet_msi(msi) : 0;
+}
+
 void iommu_resume()
 {
     const struct iommu_ops *ops =3D iommu_get_ops();
--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -147,6 +147,34 @@ struct iommu * ioapic_to_iommu(unsigned=20
     return NULL;
 }
=20
+static bool_t acpi_hpet_device_match(
+    struct list_head *list, unsigned int hpet_id)
+{
+    struct acpi_hpet_unit *hpet;
+
+    list_for_each_entry( hpet, list, list )
+        if (hpet->id =3D=3D hpet_id)
+            return 1;
+    return 0;
+}
+
+struct acpi_drhd_unit *hpet_to_drhd(unsigned int hpet_id)
+{
+    struct acpi_drhd_unit *drhd;
+
+    list_for_each_entry( drhd, &acpi_drhd_units, list )
+        if ( acpi_hpet_device_match(&drhd->hpet_list, hpet_id) )
+            return drhd;
+    return NULL;
+}
+
+struct iommu *hpet_to_iommu(unsigned int hpet_id)
+{
+    struct acpi_drhd_unit *drhd =3D hpet_to_drhd(hpet_id);
+
+    return drhd ? drhd->iommu : NULL;
+}
+
 static int __init acpi_register_atsr_unit(struct acpi_atsr_unit *atsr)
 {
     /*
@@ -330,6 +358,22 @@ static int __init acpi_parse_dev_scope(
             if ( iommu_verbose )
                 dprintk(VTDPREFIX, " MSI HPET: %04x:%02x:%02x.%u\n",
                         seg, bus, path->dev, path->fn);
+
+            if ( type =3D=3D DMAR_TYPE )
+            {
+                struct acpi_drhd_unit *drhd =3D acpi_entry;
+                struct acpi_hpet_unit *acpi_hpet_unit;
+
+                acpi_hpet_unit =3D xmalloc(struct acpi_hpet_unit);
+                if ( !acpi_hpet_unit )
+                    return -ENOMEM;
+                acpi_hpet_unit->id =3D acpi_scope->enumeration_id;
+                acpi_hpet_unit->bus =3D bus;
+                acpi_hpet_unit->dev =3D path->dev;
+                acpi_hpet_unit->func =3D path->fn;
+                list_add(&acpi_hpet_unit->list, &drhd->hpet_list);
+            }
+
             break;
=20
         case ACPI_DMAR_SCOPE_TYPE_ENDPOINT:
@@ -407,6 +451,7 @@ acpi_parse_one_drhd(struct acpi_dmar_hea
     dmaru->segment =3D drhd->segment;
     dmaru->include_all =3D drhd->flags & ACPI_DMAR_INCLUDE_ALL;
     INIT_LIST_HEAD(&dmaru->ioapic_list);
+    INIT_LIST_HEAD(&dmaru->hpet_list);
     if ( iommu_verbose )
         dprintk(VTDPREFIX, "  dmaru->address =3D %"PRIx64"\n",
                 dmaru->address);
--- a/xen/drivers/passthrough/vtd/dmar.h
+++ b/xen/drivers/passthrough/vtd/dmar.h
@@ -39,6 +39,19 @@ struct acpi_ioapic_unit {
     }ioapic;
 };
=20
+struct acpi_hpet_unit {
+    struct list_head list;
+    unsigned int id;
+    union {
+        u16 bdf;
+        struct {
+            u16 func: 3,
+                dev:  5,
+                bus:  8;
+        };
+    };
+};
+
 struct dmar_scope {
     DECLARE_BITMAP(buses, 256);         /* buses owned by this unit */
     u16    *devices;                    /* devices owned by this unit */
@@ -53,6 +66,7 @@ struct acpi_drhd_unit {
     u8     include_all:1;
     struct iommu *iommu;
     struct list_head ioapic_list;
+    struct list_head hpet_list;
 };
=20
 struct acpi_rmrr_unit {
--- a/xen/drivers/passthrough/vtd/extern.h
+++ b/xen/drivers/passthrough/vtd/extern.h
@@ -54,7 +54,9 @@ int iommu_flush_iec_index(struct iommu *
 void clear_fault_bits(struct iommu *iommu);
=20
 struct iommu * ioapic_to_iommu(unsigned int apic_id);
+struct iommu * hpet_to_iommu(unsigned int hpet_id);
 struct acpi_drhd_unit * ioapic_to_drhd(unsigned int apic_id);
+struct acpi_drhd_unit * hpet_to_drhd(unsigned int hpet_id);
 struct acpi_drhd_unit * iommu_to_drhd(struct iommu *iommu);
 struct acpi_rhsa_unit * drhd_to_rhsa(struct acpi_drhd_unit *drhd);
=20
@@ -90,6 +92,8 @@ struct msi_msg;
 void msi_msg_read_remap_rte(struct msi_desc *, struct msi_msg *);
 void msi_msg_write_remap_rte(struct msi_desc *, struct msi_msg *);
=20
+int intel_setup_hpet_msi(struct msi_desc *);
+
 int is_igd_vt_enabled_quirk(void);
 void platform_quirks_init(void);
 void vtd_ops_preamble_quirk(struct iommu* iommu);
--- a/xen/drivers/passthrough/vtd/intremap.c
+++ b/xen/drivers/passthrough/vtd/intremap.c
@@ -107,6 +107,19 @@ static u16 apicid_to_bdf(int apic_id)
     return 0;
 }
=20
+static u16 hpetid_to_bdf(unsigned int hpet_id)
+{
+    struct acpi_drhd_unit *drhd =3D hpet_to_drhd(hpet_id);
+    struct acpi_hpet_unit *acpi_hpet_unit;
+
+    list_for_each_entry ( acpi_hpet_unit, &drhd->hpet_list, list )
+        if ( acpi_hpet_unit->id =3D=3D hpet_id )
+            return acpi_hpet_unit->bdf;
+
+    dprintk(XENLOG_ERR VTDPREFIX, "Didn't find the bdf for HPET %u!\n", =
hpet_id);
+    return 0;
+}
+
 static void set_ire_sid(struct iremap_entry *ire,
                         unsigned int svt, unsigned int sq, unsigned int =
sid)
 {
@@ -121,6 +134,16 @@ static void set_ioapic_source_id(int api
                 apicid_to_bdf(apic_id));
 }
=20
+static void set_hpet_source_id(unsigned int id, struct iremap_entry *ire)
+{
+    /*
+     * Should really use SQ_ALL_16. Some platforms are broken.
+     * While we figure out the right quirks for these broken platforms, =
use
+     * SQ_13_IGNORE_3 for now.
+     */
+    set_ire_sid(ire, SVT_VERIFY_SID_SQ, SQ_13_IGNORE_3, hpetid_to_bdf(id))=
;
+}
+
 int iommu_supports_eim(void)
 {
     struct acpi_drhd_unit *drhd;
@@ -592,7 +615,10 @@ static int msi_msg_to_remap_entry(
         new_ire.lo.dst =3D ((msg->address_lo >> MSI_ADDR_DEST_ID_SHIFT)
                           & 0xff) << 8;
=20
-    set_msi_source_id(pdev, &new_ire);
+    if ( pdev )
+        set_msi_source_id(pdev, &new_ire);
+    else
+        set_hpet_source_id(msi_desc->hpet_id, &new_ire);
     new_ire.hi.res_1 =3D 0;
     new_ire.lo.p =3D 1;    /* finally, set present bit */
=20
@@ -624,7 +650,9 @@ void msi_msg_read_remap_rte(
     struct iommu *iommu =3D NULL;
     struct ir_ctrl *ir_ctrl;
=20
-    if ( (drhd =3D acpi_find_matched_drhd_unit(pdev)) =3D=3D NULL )
+    drhd =3D pdev ? acpi_find_matched_drhd_unit(pdev)
+                : hpet_to_drhd(msi_desc->hpet_id);
+    if ( !drhd )
         return;
     iommu =3D drhd->iommu;
=20
@@ -643,7 +671,9 @@ void msi_msg_write_remap_rte(
     struct iommu *iommu =3D NULL;
     struct ir_ctrl *ir_ctrl;
=20
-    if ( (drhd =3D acpi_find_matched_drhd_unit(pdev)) =3D=3D NULL )
+    drhd =3D pdev ? acpi_find_matched_drhd_unit(pdev)
+                : hpet_to_drhd(msi_desc->hpet_id);
+    if ( !drhd )
         return;
     iommu =3D drhd->iommu;
=20
@@ -654,6 +684,32 @@ void msi_msg_write_remap_rte(
     msi_msg_to_remap_entry(iommu, pdev, msi_desc, msg);
 }
=20
+int __init intel_setup_hpet_msi(struct msi_desc *msi_desc)
+{
+    struct iommu *iommu =3D hpet_to_iommu(msi_desc->hpet_id);
+    struct ir_ctrl *ir_ctrl =3D iommu_ir_ctrl(iommu);
+    unsigned long flags;
+    int rc =3D 0;
+
+    if ( !ir_ctrl || !ir_ctrl->iremap_maddr )
+        return 0;
+
+    spin_lock_irqsave(&ir_ctrl->iremap_lock, flags);
+    msi_desc->remap_index =3D alloc_remap_entry(iommu);
+    if ( msi_desc->remap_index >=3D IREMAP_ENTRY_NR )
+    {
+        dprintk(XENLOG_ERR VTDPREFIX,
+                "%s: intremap index (%d) is larger than"
+                " the maximum index (%d)!\n",
+                __func__, msi_desc->remap_index, IREMAP_ENTRY_NR - 1);
+        msi_desc->remap_index =3D -1;
+        rc =3D -ENXIO;
+    }
+    spin_unlock_irqrestore(&ir_ctrl->iremap_lock, flags);
+
+    return rc;
+}
+
 int enable_intremap(struct iommu *iommu, int eim)
 {
     struct acpi_drhd_unit *drhd;
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -2396,6 +2396,7 @@ const struct iommu_ops intel_iommu_ops =3D
     .update_ire_from_msi =3D msi_msg_write_remap_rte,
     .read_apic_from_ire =3D io_apic_read_remap_rte,
     .read_msi_from_ire =3D msi_msg_read_remap_rte,
+    .setup_hpet_msi =3D intel_setup_hpet_msi,
     .suspend =3D vtd_suspend,
     .resume =3D vtd_resume,
     .share_p2m =3D iommu_set_pgd,
--- a/xen/include/asm-x86/hpet.h
+++ b/xen/include/asm-x86/hpet.h
@@ -53,6 +53,7 @@
     (*(volatile u32 *)(fix_to_virt(FIX_HPET_BASE) + (x)) =3D (y))
=20
 extern unsigned long hpet_address;
+extern u8 hpet_blockid;
=20
 /*
  * Detect and initialise HPET hardware: return counter update frequency.
--- a/xen/include/asm-x86/msi.h
+++ b/xen/include/asm-x86/msi.h
@@ -97,7 +97,10 @@ struct msi_desc {
=20
 	struct list_head list;
=20
-	void __iomem *mask_base;        /* va for the entry in mask table =
*/
+	union {
+		void __iomem *mask_base;/* va for the entry in mask table =
*/
+		unsigned int hpet_id;   /* HPET (dev is NULL)             =
*/
+	};
 	struct pci_dev *dev;
 	int irq;
=20
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -109,6 +109,7 @@ struct iommu_ops {
     void (*update_ire_from_msi)(struct msi_desc *msi_desc, struct msi_msg =
*msg);
     void (*read_msi_from_ire)(struct msi_desc *msi_desc, struct msi_msg =
*msg);
     unsigned int (*read_apic_from_ire)(unsigned int apic, unsigned int =
reg);
+    int (*setup_hpet_msi)(struct msi_desc *);
     void (*suspend)(void);
     void (*resume)(void);
     void (*share_p2m)(struct domain *d);
@@ -122,6 +123,7 @@ void iommu_update_ire_from_apic(unsigned
 void iommu_update_ire_from_msi(struct msi_desc *msi_desc, struct msi_msg =
*msg);
 void iommu_read_msi_from_ire(struct msi_desc *msi_desc, struct msi_msg =
*msg);
 unsigned int iommu_read_apic_from_ire(unsigned int apic, unsigned int =
reg);
+int iommu_setup_hpet_msi(struct msi_desc *);
=20
 void iommu_suspend(void);
 void iommu_resume(void);



--=__PartF3C2D3CE.1__=
Content-Type: text/plain; name="x86-HPET-intremap.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-HPET-intremap.patch"

x86/HPET: allow use for broadcast when interrupt remapping is in =
effect=0A=0AThis requires some additions to the VT-d side; AMD IOMMUs use =
the=0A"normal" MSI message format even when interrupt remapping is =
enabled,=0Athus making adjustments here unnecessary.=0A=0ASigned-off-by: =
Jan Beulich =0A=0A--- a/xen/arch/x86/acpi/boot.c=0A+++ =
b/xen/arch/x86/acpi/boot.c=0A@@ -276,6 +276,7 @@ static int __init =
acpi_parse_hpet(struct=0A 	}=0A =0A 	hpet_address =3D hpet_tbl->=
address.address;=0A+	hpet_blockid =3D hpet_tbl->sequence;=0A 	=
printk(KERN_INFO PREFIX "HPET id: %#x base: %#lx\n",=0A 	       =
hpet_tbl->id, hpet_address);=0A =0A--- a/xen/arch/x86/hpet.c=0A+++ =
b/xen/arch/x86/hpet.c=0A@@ -40,7 +40,7 @@ struct hpet_event_channel=0A =0A =
    unsigned int idx;   /* physical channel idx */=0A     unsigned int =
cpu;   /* msi target */=0A-    int irq;            /* msi irq */=0A+    =
struct msi_desc msi;/* msi state */=0A     unsigned int flags; /* =
HPET_EVT_x */=0A } __cacheline_aligned;=0A static struct hpet_event_channel=
 *__read_mostly hpet_events;=0A@@ -51,6 +51,7 @@ static unsigned int =
__read_mostly num_hp=0A DEFINE_PER_CPU(struct hpet_event_channel *, =
cpu_bc_channel);=0A =0A unsigned long __read_mostly hpet_address;=0A+u8 =
__initdata hpet_blockid;=0A =0A /*=0A  * force_hpet_broadcast: by default =
legacy hpet broadcast will be stopped=0A@@ -252,6 +253,8 @@ static void =
hpet_msi_mask(struct irq_des=0A =0A static void hpet_msi_write(struct =
hpet_event_channel *ch, struct msi_msg *msg)=0A {=0A+    if ( iommu_intrema=
p )=0A+        iommu_update_ire_from_msi(&ch->msi, msg);=0A     hpet_write3=
2(msg->data, HPET_Tn_ROUTE(ch->idx));=0A     hpet_write32(msg->address_lo, =
HPET_Tn_ROUTE(ch->idx) + 4);=0A }=0A@@ -261,6 +264,8 @@ static void =
hpet_msi_read(struct hpet_ev=0A     msg->data =3D hpet_read32(HPET_Tn_ROUTE=
(ch->idx));=0A     msg->address_lo =3D hpet_read32(HPET_Tn_ROUTE(ch->idx) =
+ 4);=0A     msg->address_hi =3D 0;=0A+    if ( iommu_intremap )=0A+       =
 iommu_read_msi_from_ire(&ch->msi, msg);=0A }=0A =0A static unsigned int =
hpet_msi_startup(struct irq_desc *desc)=0A@@ -292,6 +297,7 @@ static void =
hpet_msi_set_affinity(struct=0A     msg.data |=3D MSI_DATA_VECTOR(desc->arc=
h.vector);=0A     msg.address_lo &=3D ~MSI_ADDR_DEST_ID_MASK;=0A     =
msg.address_lo |=3D MSI_ADDR_DEST_ID(dest);=0A+    msg.dest32 =3D dest;=0A =
    hpet_msi_write(desc->action->dev_id, &msg);=0A }=0A =0A@@ -316,35 =
+322,48 @@ static void __hpet_setup_msi_irq(struct =0A     hpet_msi_write(d=
esc->action->dev_id, &msg);=0A }=0A =0A-static int __init hpet_setup_msi_ir=
q(unsigned int irq, struct hpet_event_channel *ch)=0A+static int __init =
hpet_setup_msi_irq(struct hpet_event_channel *ch)=0A {=0A     int ret;=0A- =
   irq_desc_t *desc =3D irq_to_desc(irq);=0A+    irq_desc_t *desc =3D =
irq_to_desc(ch->msi.irq);=0A+=0A+    if ( iommu_intremap )=0A+    {=0A+    =
    ch->msi.hpet_id =3D hpet_blockid;=0A+        ret =3D iommu_setup_hpet_m=
si(&ch->msi);=0A+        if ( ret )=0A+            return ret;=0A+    }=0A =
=0A     desc->handler =3D &hpet_msi_type;=0A-    ret =3D request_irq(irq, =
hpet_interrupt_handler, 0, "HPET", ch);=0A+    ret =3D request_irq(ch->msi.=
irq, hpet_interrupt_handler, 0, "HPET", ch);=0A     if ( ret < 0 )=0A+    =
{=0A+        if ( iommu_intremap )=0A+            iommu_update_ire_from_msi=
(&ch->msi, NULL);=0A         return ret;=0A+    }=0A =0A     __hpet_setup_m=
si_irq(desc);=0A =0A     return 0;=0A }=0A =0A-static int __init hpet_assig=
n_irq(unsigned int idx)=0A+static int __init hpet_assign_irq(struct =
hpet_event_channel *ch)=0A {=0A     int irq;=0A =0A     if ( (irq =3D =
create_irq(NUMA_NO_NODE)) < 0 )=0A         return irq;=0A =0A-    if ( =
hpet_setup_msi_irq(irq, hpet_events + idx) )=0A+    ch->msi.irq =3D =
irq;=0A+    if ( hpet_setup_msi_irq(ch) )=0A     {=0A         destroy_irq(i=
rq);=0A         return -EINVAL;=0A     }=0A =0A-    return irq;=0A+    =
return 0;=0A }=0A =0A static void __init hpet_fsb_cap_lookup(void)=0A@@ =
-352,14 +371,6 @@ static void __init hpet_fsb_cap_lookup(v=0A     u32 =
id;=0A     unsigned int i, num_chs;=0A =0A-    /* TODO. */=0A-    if ( =
iommu_intremap )=0A-    {=0A-        printk(XENLOG_INFO "HPET's MSI mode =
hasn't been supported when "=0A-            "Interrupt Remapping is =
enabled.\n");=0A-        return;=0A-    }=0A-=0A     id =3D hpet_read32(HPE=
T_ID);=0A =0A     num_chs =3D ((id & HPET_ID_NUMBER) >> HPET_ID_NUMBER_SHIF=
T);=0A@@ -391,8 +402,8 @@ static void __init hpet_fsb_cap_lookup(v=0A      =
   ch->flags =3D 0;=0A         ch->idx =3D i;=0A =0A-        if ( (ch->irq =
=3D hpet_assign_irq(num_hpets_used++)) < 0 )=0A-            num_hpets_used-=
-;=0A+        if ( hpet_assign_irq(ch) =3D=3D 0 )=0A+            num_hpets_=
used++;=0A     }=0A =0A     printk(XENLOG_INFO "HPET: %u timers (%u will =
be used for broadcast)\n",=0A@@ -438,7 +449,7 @@ static struct hpet_event_c=
hannel *hpet_g=0A =0A static void _hpet_msi_set_affinity(const struct =
hpet_event_channel *ch)=0A {=0A-    struct irq_desc *desc =3D irq_to_desc(c=
h->irq);=0A+    struct irq_desc *desc =3D irq_to_desc(ch->msi.irq);=0A =0A =
    ASSERT(!local_irq_is_enabled());=0A     spin_lock(&desc->lock);=0A@@ =
-530,7 +541,7 @@ void __init hpet_broadcast_init(void)=0A             =
hpet_events =3D xzalloc(struct hpet_event_channel);=0A         if ( =
!hpet_events || !zalloc_cpumask_var(&hpet_events->cpumask) )=0A            =
 return;=0A-        hpet_events->irq =3D -1;=0A+        hpet_events->msi.ir=
q =3D -1;=0A =0A         /* Start HPET legacy interrupts */=0A         cfg =
|=3D HPET_CFG_LEGACY;=0A@@ -598,8 +609,8 @@ void hpet_broadcast_resume(void=
)=0A =0A     for ( i =3D 0; i < n; i++ )=0A     {=0A-        if ( =
hpet_events[i].irq >=3D 0 )=0A-            __hpet_setup_msi_irq(irq_to_desc=
(hpet_events[i].irq));=0A+        if ( hpet_events[i].msi.irq >=3D 0 )=0A+ =
           __hpet_setup_msi_irq(irq_to_desc(hpet_events[i].msi.irq));=0A =
=0A         /* set HPET Tn as oneshot */=0A         cfg =3D hpet_read32(HPE=
T_Tn_CFG(hpet_events[i].idx));=0A--- a/xen/drivers/passthrough/iommu.c=0A++=
+ b/xen/drivers/passthrough/iommu.c=0A@@ -495,6 +495,12 @@ unsigned int =
iommu_read_apic_from_ire(un=0A     return ops->read_apic_from_ire(apic, =
reg);=0A }=0A =0A+int __init iommu_setup_hpet_msi(struct msi_desc =
*msi)=0A+{=0A+    const struct iommu_ops *ops =3D iommu_get_ops();=0A+    =
return ops->setup_hpet_msi ? ops->setup_hpet_msi(msi) : 0;=0A+}=0A+=0A =
void iommu_resume()=0A {=0A     const struct iommu_ops *ops =3D iommu_get_o=
ps();=0A--- a/xen/drivers/passthrough/vtd/dmar.c=0A+++ b/xen/drivers/passth=
rough/vtd/dmar.c=0A@@ -147,6 +147,34 @@ struct iommu * ioapic_to_iommu(unsi=
gned =0A     return NULL;=0A }=0A =0A+static bool_t acpi_hpet_device_match(=
=0A+    struct list_head *list, unsigned int hpet_id)=0A+{=0A+    struct =
acpi_hpet_unit *hpet;=0A+=0A+    list_for_each_entry( hpet, list, list =
)=0A+        if (hpet->id =3D=3D hpet_id)=0A+            return 1;=0A+    =
return 0;=0A+}=0A+=0A+struct acpi_drhd_unit *hpet_to_drhd(unsigned int =
hpet_id)=0A+{=0A+    struct acpi_drhd_unit *drhd;=0A+=0A+    list_for_each_=
entry( drhd, &acpi_drhd_units, list )=0A+        if ( acpi_hpet_device_matc=
h(&drhd->hpet_list, hpet_id) )=0A+            return drhd;=0A+    return =
NULL;=0A+}=0A+=0A+struct iommu *hpet_to_iommu(unsigned int hpet_id)=0A+{=0A=
+    struct acpi_drhd_unit *drhd =3D hpet_to_drhd(hpet_id);=0A+=0A+    =
return drhd ? drhd->iommu : NULL;=0A+}=0A+=0A static int __init acpi_regist=
er_atsr_unit(struct acpi_atsr_unit *atsr)=0A {=0A     /*=0A@@ -330,6 =
+358,22 @@ static int __init acpi_parse_dev_scope(=0A             if ( =
iommu_verbose )=0A                 dprintk(VTDPREFIX, " MSI HPET: =
%04x:%02x:%02x.%u\n",=0A                         seg, bus, path->dev, =
path->fn);=0A+=0A+            if ( type =3D=3D DMAR_TYPE )=0A+            =
{=0A+                struct acpi_drhd_unit *drhd =3D acpi_entry;=0A+       =
         struct acpi_hpet_unit *acpi_hpet_unit;=0A+=0A+                =
acpi_hpet_unit =3D xmalloc(struct acpi_hpet_unit);=0A+                if ( =
!acpi_hpet_unit )=0A+                    return -ENOMEM;=0A+               =
 acpi_hpet_unit->id =3D acpi_scope->enumeration_id;=0A+                =
acpi_hpet_unit->bus =3D bus;=0A+                acpi_hpet_unit->dev =3D =
path->dev;=0A+                acpi_hpet_unit->func =3D path->fn;=0A+       =
         list_add(&acpi_hpet_unit->list, &drhd->hpet_list);=0A+            =
}=0A+=0A             break;=0A =0A         case ACPI_DMAR_SCOPE_TYPE_ENDPOI=
NT:=0A@@ -407,6 +451,7 @@ acpi_parse_one_drhd(struct acpi_dmar_hea=0A     =
dmaru->segment =3D drhd->segment;=0A     dmaru->include_all =3D drhd->flags=
 & ACPI_DMAR_INCLUDE_ALL;=0A     INIT_LIST_HEAD(&dmaru->ioapic_list);=0A+  =
  INIT_LIST_HEAD(&dmaru->hpet_list);=0A     if ( iommu_verbose )=0A        =
 dprintk(VTDPREFIX, "  dmaru->address =3D %"PRIx64"\n",=0A                 =
dmaru->address);=0A--- a/xen/drivers/passthrough/vtd/dmar.h=0A+++ =
b/xen/drivers/passthrough/vtd/dmar.h=0A@@ -39,6 +39,19 @@ struct acpi_ioapi=
c_unit {=0A     }ioapic;=0A };=0A =0A+struct acpi_hpet_unit {=0A+    =
struct list_head list;=0A+    unsigned int id;=0A+    union {=0A+        =
u16 bdf;=0A+        struct {=0A+            u16 func: 3,=0A+               =
 dev:  5,=0A+                bus:  8;=0A+        };=0A+    };=0A+};=0A+=0A =
struct dmar_scope {=0A     DECLARE_BITMAP(buses, 256);         /* buses =
owned by this unit */=0A     u16    *devices;                    /* =
devices owned by this unit */=0A@@ -53,6 +66,7 @@ struct acpi_drhd_unit =
{=0A     u8     include_all:1;=0A     struct iommu *iommu;=0A     struct =
list_head ioapic_list;=0A+    struct list_head hpet_list;=0A };=0A =0A =
struct acpi_rmrr_unit {=0A--- a/xen/drivers/passthrough/vtd/extern.h=0A+++ =
b/xen/drivers/passthrough/vtd/extern.h=0A@@ -54,7 +54,9 @@ int iommu_flush_=
iec_index(struct iommu *=0A void clear_fault_bits(struct iommu *iommu);=0A =
=0A struct iommu * ioapic_to_iommu(unsigned int apic_id);=0A+struct iommu =
* hpet_to_iommu(unsigned int hpet_id);=0A struct acpi_drhd_unit * =
ioapic_to_drhd(unsigned int apic_id);=0A+struct acpi_drhd_unit * hpet_to_dr=
hd(unsigned int hpet_id);=0A struct acpi_drhd_unit * iommu_to_drhd(struct =
iommu *iommu);=0A struct acpi_rhsa_unit * drhd_to_rhsa(struct acpi_drhd_uni=
t *drhd);=0A =0A@@ -90,6 +92,8 @@ struct msi_msg;=0A void msi_msg_read_rema=
p_rte(struct msi_desc *, struct msi_msg *);=0A void msi_msg_write_remap_rte=
(struct msi_desc *, struct msi_msg *);=0A =0A+int intel_setup_hpet_msi(stru=
ct msi_desc *);=0A+=0A int is_igd_vt_enabled_quirk(void);=0A void =
platform_quirks_init(void);=0A void vtd_ops_preamble_quirk(struct iommu* =
iommu);=0A--- a/xen/drivers/passthrough/vtd/intremap.c=0A+++ b/xen/drivers/=
passthrough/vtd/intremap.c=0A@@ -107,6 +107,19 @@ static u16 apicid_to_bdf(=
int apic_id)=0A     return 0;=0A }=0A =0A+static u16 hpetid_to_bdf(unsigned=
 int hpet_id)=0A+{=0A+    struct acpi_drhd_unit *drhd =3D hpet_to_drhd(hpet=
_id);=0A+    struct acpi_hpet_unit *acpi_hpet_unit;=0A+=0A+    list_for_eac=
h_entry ( acpi_hpet_unit, &drhd->hpet_list, list )=0A+        if ( =
acpi_hpet_unit->id =3D=3D hpet_id )=0A+            return acpi_hpet_unit->b=
df;=0A+=0A+    dprintk(XENLOG_ERR VTDPREFIX, "Didn't find the bdf for HPET =
%u!\n", hpet_id);=0A+    return 0;=0A+}=0A+=0A static void set_ire_sid(stru=
ct iremap_entry *ire,=0A                         unsigned int svt, =
unsigned int sq, unsigned int sid)=0A {=0A@@ -121,6 +134,16 @@ static void =
set_ioapic_source_id(int api=0A                 apicid_to_bdf(apic_id));=0A=
 }=0A =0A+static void set_hpet_source_id(unsigned int id, struct iremap_ent=
ry *ire)=0A+{=0A+    /*=0A+     * Should really use SQ_ALL_16. Some =
platforms are broken.=0A+     * While we figure out the right quirks for =
these broken platforms, use=0A+     * SQ_13_IGNORE_3 for now.=0A+     =
*/=0A+    set_ire_sid(ire, SVT_VERIFY_SID_SQ, SQ_13_IGNORE_3, hpetid_to_bdf=
(id));=0A+}=0A+=0A int iommu_supports_eim(void)=0A {=0A     struct =
acpi_drhd_unit *drhd;=0A@@ -592,7 +615,10 @@ static int msi_msg_to_remap_en=
try(=0A         new_ire.lo.dst =3D ((msg->address_lo >> MSI_ADDR_DEST_ID_SH=
IFT)=0A                           & 0xff) << 8;=0A =0A-    set_msi_source_i=
d(pdev, &new_ire);=0A+    if ( pdev )=0A+        set_msi_source_id(pdev, =
&new_ire);=0A+    else=0A+        set_hpet_source_id(msi_desc->hpet_id, =
&new_ire);=0A     new_ire.hi.res_1 =3D 0;=0A     new_ire.lo.p =3D 1;    /* =
finally, set present bit */=0A =0A@@ -624,7 +650,9 @@ void msi_msg_read_rem=
ap_rte(=0A     struct iommu *iommu =3D NULL;=0A     struct ir_ctrl =
*ir_ctrl;=0A =0A-    if ( (drhd =3D acpi_find_matched_drhd_unit(pdev)) =
=3D=3D NULL )=0A+    drhd =3D pdev ? acpi_find_matched_drhd_unit(pdev)=0A+ =
               : hpet_to_drhd(msi_desc->hpet_id);=0A+    if ( !drhd )=0A   =
      return;=0A     iommu =3D drhd->iommu;=0A =0A@@ -643,7 +671,9 @@ void =
msi_msg_write_remap_rte(=0A     struct iommu *iommu =3D NULL;=0A     =
struct ir_ctrl *ir_ctrl;=0A =0A-    if ( (drhd =3D acpi_find_matched_drhd_u=
nit(pdev)) =3D=3D NULL )=0A+    drhd =3D pdev ? acpi_find_matched_drhd_unit=
(pdev)=0A+                : hpet_to_drhd(msi_desc->hpet_id);=0A+    if ( =
!drhd )=0A         return;=0A     iommu =3D drhd->iommu;=0A =0A@@ -654,6 =
+684,32 @@ void msi_msg_write_remap_rte(=0A     msi_msg_to_remap_entry(iomm=
u, pdev, msi_desc, msg);=0A }=0A =0A+int __init intel_setup_hpet_msi(struct=
 msi_desc *msi_desc)=0A+{=0A+    struct iommu *iommu =3D hpet_to_iommu(msi_=
desc->hpet_id);=0A+    struct ir_ctrl *ir_ctrl =3D iommu_ir_ctrl(iommu);=0A=
+    unsigned long flags;=0A+    int rc =3D 0;=0A+=0A+    if ( !ir_ctrl || =
!ir_ctrl->iremap_maddr )=0A+        return 0;=0A+=0A+    spin_lock_irqsave(=
&ir_ctrl->iremap_lock, flags);=0A+    msi_desc->remap_index =3D alloc_remap=
_entry(iommu);=0A+    if ( msi_desc->remap_index >=3D IREMAP_ENTRY_NR =
)=0A+    {=0A+        dprintk(XENLOG_ERR VTDPREFIX,=0A+                =
"%s: intremap index (%d) is larger than"=0A+                " the maximum =
index (%d)!\n",=0A+                __func__, msi_desc->remap_index, =
IREMAP_ENTRY_NR - 1);=0A+        msi_desc->remap_index =3D -1;=0A+        =
rc =3D -ENXIO;=0A+    }=0A+    spin_unlock_irqrestore(&ir_ctrl->iremap_lock=
, flags);=0A+=0A+    return rc;=0A+}=0A+=0A int enable_intremap(struct =
iommu *iommu, int eim)=0A {=0A     struct acpi_drhd_unit *drhd;=0A--- =
a/xen/drivers/passthrough/vtd/iommu.c=0A+++ b/xen/drivers/passthrough/vtd/i=
ommu.c=0A@@ -2396,6 +2396,7 @@ const struct iommu_ops intel_iommu_ops =
=3D=0A     .update_ire_from_msi =3D msi_msg_write_remap_rte,=0A     =
.read_apic_from_ire =3D io_apic_read_remap_rte,=0A     .read_msi_from_ire =
=3D msi_msg_read_remap_rte,=0A+    .setup_hpet_msi =3D intel_setup_hpet_msi=
,=0A     .suspend =3D vtd_suspend,=0A     .resume =3D vtd_resume,=0A     =
.share_p2m =3D iommu_set_pgd,=0A--- a/xen/include/asm-x86/hpet.h=0A+++ =
b/xen/include/asm-x86/hpet.h=0A@@ -53,6 +53,7 @@=0A     (*(volatile u32 =
*)(fix_to_virt(FIX_HPET_BASE) + (x)) =3D (y))=0A =0A extern unsigned long =
hpet_address;=0A+extern u8 hpet_blockid;=0A =0A /*=0A  * Detect and =
initialise HPET hardware: return counter update frequency.=0A--- a/xen/incl=
ude/asm-x86/msi.h=0A+++ b/xen/include/asm-x86/msi.h=0A@@ -97,7 +97,10 @@ =
struct msi_desc {=0A =0A 	struct list_head list;=0A =0A-	void =
__iomem *mask_base;        /* va for the entry in mask table */=0A+	=
union {=0A+		void __iomem *mask_base;/* va for the entry in =
mask table */=0A+		unsigned int hpet_id;   /* HPET (dev is =
NULL)             */=0A+	};=0A 	struct pci_dev *dev;=0A 	=
int irq;=0A =0A--- a/xen/include/xen/iommu.h=0A+++ b/xen/include/xen/iommu.=
h=0A@@ -109,6 +109,7 @@ struct iommu_ops {=0A     void (*update_ire_from_ms=
i)(struct msi_desc *msi_desc, struct msi_msg *msg);=0A     void (*read_msi_=
from_ire)(struct msi_desc *msi_desc, struct msi_msg *msg);=0A     unsigned =
int (*read_apic_from_ire)(unsigned int apic, unsigned int reg);=0A+    int =
(*setup_hpet_msi)(struct msi_desc *);=0A     void (*suspend)(void);=0A     =
void (*resume)(void);=0A     void (*share_p2m)(struct domain *d);=0A@@ =
-122,6 +123,7 @@ void iommu_update_ire_from_apic(unsigned=0A void =
iommu_update_ire_from_msi(struct msi_desc *msi_desc, struct msi_msg =
*msg);=0A void iommu_read_msi_from_ire(struct msi_desc *msi_desc, struct =
msi_msg *msg);=0A unsigned int iommu_read_apic_from_ire(unsigned int apic, =
unsigned int reg);=0A+int iommu_setup_hpet_msi(struct msi_desc *);=0A =0A =
void iommu_suspend(void);=0A void iommu_resume(void);=0A
--=__PartF3C2D3CE.1__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__PartF3C2D3CE.1__=--


From xen-devel-bounces@lists.xen.org Tue Oct 16 15:11:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 15:11:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO8nY-0005qE-F8; Tue, 16 Oct 2012 15:11:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO8nW-0005pv-Jj
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 15:11:10 +0000
Received: from [85.158.143.99:4090] by server-3.bemta-4.messagelabs.com id
	E0/07-03544-D097D705; Tue, 16 Oct 2012 15:11:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1350400269!23102409!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2MDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9662 invoked from network); 16 Oct 2012 15:11:09 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-216.messagelabs.com with SMTP;
	16 Oct 2012 15:11:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 16 Oct 2012 16:11:08 +0100
Message-Id: <507D952802000078000A1BC5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 16 Oct 2012 16:11:04 +0100
From: "Jan Beulich" 
To: "xen-devel" 
References: <507D93C102000078000A1BAB@nat28.tlf.novell.com>
In-Reply-To: <507D93C102000078000A1BAB@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part24150418.0__="
Subject: [Xen-devel] [PATCH 3/3] x86/HPET: cache MSI message last written
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part24150418.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Rather than spending measurable amounts of time reading back the most
recently written message, cache it in space previously unused, and thus
accelerate the CPU's entering of the intended C-state.

hpet_msi_read() ends up being unused after this change, but rather than
removing the function, it's being marked "unused" in order - that way
it can easily get used again should a new need for it arise.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/hpet.c
+++ b/xen/arch/x86/hpet.c
@@ -253,17 +253,19 @@ static void hpet_msi_mask(struct irq_des
=20
 static void hpet_msi_write(struct hpet_event_channel *ch, struct msi_msg =
*msg)
 {
+    ch->msi.msg =3D *msg;
     if ( iommu_intremap )
         iommu_update_ire_from_msi(&ch->msi, msg);
     hpet_write32(msg->data, HPET_Tn_ROUTE(ch->idx));
     hpet_write32(msg->address_lo, HPET_Tn_ROUTE(ch->idx) + 4);
 }
=20
-static void hpet_msi_read(struct hpet_event_channel *ch, struct msi_msg =
*msg)
+static void __attribute__((__unused__))
+hpet_msi_read(struct hpet_event_channel *ch, struct msi_msg *msg)
 {
     msg->data =3D hpet_read32(HPET_Tn_ROUTE(ch->idx));
     msg->address_lo =3D hpet_read32(HPET_Tn_ROUTE(ch->idx) + 4);
-    msg->address_hi =3D 0;
+    msg->address_hi =3D MSI_ADDR_BASE_HI;
     if ( iommu_intremap )
         iommu_read_msi_from_ire(&ch->msi, msg);
 }
@@ -285,20 +287,19 @@ static void hpet_msi_ack(struct irq_desc
=20
 static void hpet_msi_set_affinity(struct irq_desc *desc, const cpumask_t =
*mask)
 {
-    struct msi_msg msg;
-    unsigned int dest;
+    struct hpet_event_channel *ch =3D desc->action->dev_id;
+    struct msi_msg msg =3D ch->msi.msg;
=20
-    dest =3D set_desc_affinity(desc, mask);
-    if (dest =3D=3D BAD_APICID)
+    msg.dest32 =3D set_desc_affinity(desc, mask);
+    if ( msg.dest32 =3D=3D BAD_APICID )
         return;
=20
-    hpet_msi_read(desc->action->dev_id, &msg);
     msg.data &=3D ~MSI_DATA_VECTOR_MASK;
     msg.data |=3D MSI_DATA_VECTOR(desc->arch.vector);
     msg.address_lo &=3D ~MSI_ADDR_DEST_ID_MASK;
-    msg.address_lo |=3D MSI_ADDR_DEST_ID(dest);
-    msg.dest32 =3D dest;
-    hpet_msi_write(desc->action->dev_id, &msg);
+    msg.address_lo |=3D MSI_ADDR_DEST_ID(msg.dest32);
+    if ( msg.data !=3D ch->msi.msg.data || msg.dest32 !=3D ch->msi.msg.des=
t32 )
+        hpet_msi_write(ch, &msg);
 }
=20
 /*




--=__Part24150418.0__=
Content-Type: text/plain; name="x86-HPET-msg-cache.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-HPET-msg-cache.patch"

x86/HPET: cache MSI message last written=0A=0ARather than spending =
measurable amounts of time reading back the most=0Arecently written =
message, cache it in space previously unused, and thus=0Aaccelerate the =
CPU's entering of the intended C-state.=0A=0Ahpet_msi_read() ends up being =
unused after this change, but rather than=0Aremoving the function, it's =
being marked "unused" in order - that way=0Ait can easily get used again =
should a new need for it arise.=0A=0ASigned-off-by: Jan Beulich =0A=0A--- a/xen/arch/x86/hpet.c=0A+++ b/xen/arch/x86/hpet.c=0A@@ =
-253,17 +253,19 @@ static void hpet_msi_mask(struct irq_des=0A =0A static =
void hpet_msi_write(struct hpet_event_channel *ch, struct msi_msg *msg)=0A =
{=0A+    ch->msi.msg =3D *msg;=0A     if ( iommu_intremap )=0A         =
iommu_update_ire_from_msi(&ch->msi, msg);=0A     hpet_write32(msg->data, =
HPET_Tn_ROUTE(ch->idx));=0A     hpet_write32(msg->address_lo, HPET_Tn_ROUTE=
(ch->idx) + 4);=0A }=0A =0A-static void hpet_msi_read(struct hpet_event_cha=
nnel *ch, struct msi_msg *msg)=0A+static void __attribute__((__unused__))=
=0A+hpet_msi_read(struct hpet_event_channel *ch, struct msi_msg *msg)=0A =
{=0A     msg->data =3D hpet_read32(HPET_Tn_ROUTE(ch->idx));=0A     =
msg->address_lo =3D hpet_read32(HPET_Tn_ROUTE(ch->idx) + 4);=0A-    =
msg->address_hi =3D 0;=0A+    msg->address_hi =3D MSI_ADDR_BASE_HI;=0A     =
if ( iommu_intremap )=0A         iommu_read_msi_from_ire(&ch->msi, =
msg);=0A }=0A@@ -285,20 +287,19 @@ static void hpet_msi_ack(struct =
irq_desc=0A =0A static void hpet_msi_set_affinity(struct irq_desc *desc, =
const cpumask_t *mask)=0A {=0A-    struct msi_msg msg;=0A-    unsigned int =
dest;=0A+    struct hpet_event_channel *ch =3D desc->action->dev_id;=0A+   =
 struct msi_msg msg =3D ch->msi.msg;=0A =0A-    dest =3D set_desc_affinity(=
desc, mask);=0A-    if (dest =3D=3D BAD_APICID)=0A+    msg.dest32 =3D =
set_desc_affinity(desc, mask);=0A+    if ( msg.dest32 =3D=3D BAD_APICID =
)=0A         return;=0A =0A-    hpet_msi_read(desc->action->dev_id, =
&msg);=0A     msg.data &=3D ~MSI_DATA_VECTOR_MASK;=0A     msg.data |=3D =
MSI_DATA_VECTOR(desc->arch.vector);=0A     msg.address_lo &=3D ~MSI_ADDR_DE=
ST_ID_MASK;=0A-    msg.address_lo |=3D MSI_ADDR_DEST_ID(dest);=0A-    =
msg.dest32 =3D dest;=0A-    hpet_msi_write(desc->action->dev_id, &msg);=0A+=
    msg.address_lo |=3D MSI_ADDR_DEST_ID(msg.dest32);=0A+    if ( msg.data =
!=3D ch->msi.msg.data || msg.dest32 !=3D ch->msi.msg.dest32 )=0A+        =
hpet_msi_write(ch, &msg);=0A }=0A =0A /*=0A
--=__Part24150418.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__Part24150418.0__=--


From xen-devel-bounces@lists.xen.org Tue Oct 16 15:11:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 15:11:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO8nY-0005qE-F8; Tue, 16 Oct 2012 15:11:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO8nW-0005pv-Jj
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 15:11:10 +0000
Received: from [85.158.143.99:4090] by server-3.bemta-4.messagelabs.com id
	E0/07-03544-D097D705; Tue, 16 Oct 2012 15:11:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1350400269!23102409!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2MDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9662 invoked from network); 16 Oct 2012 15:11:09 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-216.messagelabs.com with SMTP;
	16 Oct 2012 15:11:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 16 Oct 2012 16:11:08 +0100
Message-Id: <507D952802000078000A1BC5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 16 Oct 2012 16:11:04 +0100
From: "Jan Beulich" 
To: "xen-devel" 
References: <507D93C102000078000A1BAB@nat28.tlf.novell.com>
In-Reply-To: <507D93C102000078000A1BAB@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part24150418.0__="
Subject: [Xen-devel] [PATCH 3/3] x86/HPET: cache MSI message last written
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part24150418.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Rather than spending measurable amounts of time reading back the most
recently written message, cache it in space previously unused, and thus
accelerate the CPU's entering of the intended C-state.

hpet_msi_read() ends up being unused after this change, but rather than
removing the function, it's being marked "unused" in order - that way
it can easily get used again should a new need for it arise.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/hpet.c
+++ b/xen/arch/x86/hpet.c
@@ -253,17 +253,19 @@ static void hpet_msi_mask(struct irq_des
=20
 static void hpet_msi_write(struct hpet_event_channel *ch, struct msi_msg =
*msg)
 {
+    ch->msi.msg =3D *msg;
     if ( iommu_intremap )
         iommu_update_ire_from_msi(&ch->msi, msg);
     hpet_write32(msg->data, HPET_Tn_ROUTE(ch->idx));
     hpet_write32(msg->address_lo, HPET_Tn_ROUTE(ch->idx) + 4);
 }
=20
-static void hpet_msi_read(struct hpet_event_channel *ch, struct msi_msg =
*msg)
+static void __attribute__((__unused__))
+hpet_msi_read(struct hpet_event_channel *ch, struct msi_msg *msg)
 {
     msg->data =3D hpet_read32(HPET_Tn_ROUTE(ch->idx));
     msg->address_lo =3D hpet_read32(HPET_Tn_ROUTE(ch->idx) + 4);
-    msg->address_hi =3D 0;
+    msg->address_hi =3D MSI_ADDR_BASE_HI;
     if ( iommu_intremap )
         iommu_read_msi_from_ire(&ch->msi, msg);
 }
@@ -285,20 +287,19 @@ static void hpet_msi_ack(struct irq_desc
=20
 static void hpet_msi_set_affinity(struct irq_desc *desc, const cpumask_t =
*mask)
 {
-    struct msi_msg msg;
-    unsigned int dest;
+    struct hpet_event_channel *ch =3D desc->action->dev_id;
+    struct msi_msg msg =3D ch->msi.msg;
=20
-    dest =3D set_desc_affinity(desc, mask);
-    if (dest =3D=3D BAD_APICID)
+    msg.dest32 =3D set_desc_affinity(desc, mask);
+    if ( msg.dest32 =3D=3D BAD_APICID )
         return;
=20
-    hpet_msi_read(desc->action->dev_id, &msg);
     msg.data &=3D ~MSI_DATA_VECTOR_MASK;
     msg.data |=3D MSI_DATA_VECTOR(desc->arch.vector);
     msg.address_lo &=3D ~MSI_ADDR_DEST_ID_MASK;
-    msg.address_lo |=3D MSI_ADDR_DEST_ID(dest);
-    msg.dest32 =3D dest;
-    hpet_msi_write(desc->action->dev_id, &msg);
+    msg.address_lo |=3D MSI_ADDR_DEST_ID(msg.dest32);
+    if ( msg.data !=3D ch->msi.msg.data || msg.dest32 !=3D ch->msi.msg.des=
t32 )
+        hpet_msi_write(ch, &msg);
 }
=20
 /*




--=__Part24150418.0__=
Content-Type: text/plain; name="x86-HPET-msg-cache.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-HPET-msg-cache.patch"

x86/HPET: cache MSI message last written=0A=0ARather than spending =
measurable amounts of time reading back the most=0Arecently written =
message, cache it in space previously unused, and thus=0Aaccelerate the =
CPU's entering of the intended C-state.=0A=0Ahpet_msi_read() ends up being =
unused after this change, but rather than=0Aremoving the function, it's =
being marked "unused" in order - that way=0Ait can easily get used again =
should a new need for it arise.=0A=0ASigned-off-by: Jan Beulich =0A=0A--- a/xen/arch/x86/hpet.c=0A+++ b/xen/arch/x86/hpet.c=0A@@ =
-253,17 +253,19 @@ static void hpet_msi_mask(struct irq_des=0A =0A static =
void hpet_msi_write(struct hpet_event_channel *ch, struct msi_msg *msg)=0A =
{=0A+    ch->msi.msg =3D *msg;=0A     if ( iommu_intremap )=0A         =
iommu_update_ire_from_msi(&ch->msi, msg);=0A     hpet_write32(msg->data, =
HPET_Tn_ROUTE(ch->idx));=0A     hpet_write32(msg->address_lo, HPET_Tn_ROUTE=
(ch->idx) + 4);=0A }=0A =0A-static void hpet_msi_read(struct hpet_event_cha=
nnel *ch, struct msi_msg *msg)=0A+static void __attribute__((__unused__))=
=0A+hpet_msi_read(struct hpet_event_channel *ch, struct msi_msg *msg)=0A =
{=0A     msg->data =3D hpet_read32(HPET_Tn_ROUTE(ch->idx));=0A     =
msg->address_lo =3D hpet_read32(HPET_Tn_ROUTE(ch->idx) + 4);=0A-    =
msg->address_hi =3D 0;=0A+    msg->address_hi =3D MSI_ADDR_BASE_HI;=0A     =
if ( iommu_intremap )=0A         iommu_read_msi_from_ire(&ch->msi, =
msg);=0A }=0A@@ -285,20 +287,19 @@ static void hpet_msi_ack(struct =
irq_desc=0A =0A static void hpet_msi_set_affinity(struct irq_desc *desc, =
const cpumask_t *mask)=0A {=0A-    struct msi_msg msg;=0A-    unsigned int =
dest;=0A+    struct hpet_event_channel *ch =3D desc->action->dev_id;=0A+   =
 struct msi_msg msg =3D ch->msi.msg;=0A =0A-    dest =3D set_desc_affinity(=
desc, mask);=0A-    if (dest =3D=3D BAD_APICID)=0A+    msg.dest32 =3D =
set_desc_affinity(desc, mask);=0A+    if ( msg.dest32 =3D=3D BAD_APICID =
)=0A         return;=0A =0A-    hpet_msi_read(desc->action->dev_id, =
&msg);=0A     msg.data &=3D ~MSI_DATA_VECTOR_MASK;=0A     msg.data |=3D =
MSI_DATA_VECTOR(desc->arch.vector);=0A     msg.address_lo &=3D ~MSI_ADDR_DE=
ST_ID_MASK;=0A-    msg.address_lo |=3D MSI_ADDR_DEST_ID(dest);=0A-    =
msg.dest32 =3D dest;=0A-    hpet_msi_write(desc->action->dev_id, &msg);=0A+=
    msg.address_lo |=3D MSI_ADDR_DEST_ID(msg.dest32);=0A+    if ( msg.data =
!=3D ch->msi.msg.data || msg.dest32 !=3D ch->msi.msg.dest32 )=0A+        =
hpet_msi_write(ch, &msg);=0A }=0A =0A /*=0A
--=__Part24150418.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__Part24150418.0__=--


From xen-devel-bounces@lists.xen.org Tue Oct 16 15:12:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 15:12:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO8ol-0005z2-W7; Tue, 16 Oct 2012 15:12:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO8ok-0005yg-G8
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 15:12:26 +0000
Received: from [85.158.139.211:18077] by server-6.bemta-5.messagelabs.com id
	CB/61-32589-9597D705; Tue, 16 Oct 2012 15:12:25 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1350400345!22557163!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2950 invoked from network); 16 Oct 2012 15:12:25 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 15:12:25 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so3827875eek.32
	for ; Tue, 16 Oct 2012 08:12:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=JvdXRaFZtDBqJ9o1zktorrGhGWiHm/RjNOKQh5ZPtpU=;
	b=ulcN3M/lHdApZNPqxqMaSj7G/FjDaTa3n/aTk0WFBKyZmAesl7J9bq0xItVZmFYRnQ
	zl1fxEHVcWRFC9dvfOYsyevT0YLX6dMgmIpu/RO5cfc7i4QBTUiRtAleUk0UKAUWkAPX
	KwKYr/RedgAscuaBBLTUMtrWTgWdovp5OK20efHiZuR4hOQPPALt9+X9QKp4id18EWdy
	g2ls2/NueEouK6kGZa0mzJBQREKv731o2itxzL6lzEQN742yK+DZ8V529MmD8QEHMziM
	qi4SUEvVfKzL8/ok1ya6ETcVRLaqvivkHrYEhWlzaVAtVSFwVNaexEUtwH2vq8f4BF2J
	Au5g==
Received: by 10.14.213.65 with SMTP id z41mr21426881eeo.29.1350400344880;
	Tue, 16 Oct 2012 08:12:24 -0700 (PDT)
Received: from [192.168.1.69]
	(host86-183-156-141.range86-183.btcentralplus.com. [86.183.156.141])
	by mx.google.com with ESMTPS id d44sm30424825eeo.10.2012.10.16.08.12.22
	(version=SSLv3 cipher=OTHER); Tue, 16 Oct 2012 08:12:23 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Tue, 16 Oct 2012 16:12:19 +0100
From: Keir Fraser 
To: Jan Beulich ,
	xen-devel 
Message-ID: 
Thread-Topic: [Xen-devel] [PATCH] ACPI: fix APEI related table size checking
Thread-Index: Ac2rsKJZUuhBikxPC0CNAV4FlwAxZw==
In-Reply-To: <507D8F6802000078000A1B88@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: ying.huang@intel.com
Subject: Re: [Xen-devel] [PATCH] ACPI: fix APEI related table size checking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 16/10/2012 15:46, "Jan Beulich"  wrote:

> On Huang Ying's machine:
> 
> erst_tab->header_length == sizeof(struct acpi_table_einj)
> 
> but Yinghai reported that on his machine,
> 
> erst_tab->header_length == sizeof(struct acpi_table_einj) -
> sizeof(struct acpi_table_header)
> 
> To make erst table size checking code works on all systems, both
> testing are treated as PASS.
> 
> Same situation applies to einj_tab->header_length, so corresponding
> table size checking is changed in similar way too.
> 
> Originally-by: Yinghai Lu 
> Signed-off-by: Huang Ying 
> 
> - use switch() for better readability
> - add comment explaining why a formally invalid size it also being
>   accepted
> - check erst_tab->header.length before even looking at
>   erst_tab->header_length
> - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
> 
> Signed-off-by: Jan Beulich 

Acked-by: Keir Fraser 

> --- a/xen/drivers/acpi/apei/erst.c
> +++ b/xen/drivers/acpi/apei/erst.c
> @@ -715,12 +715,23 @@ int erst_clear(u64 record_id)
>  
>  static int __init erst_check_table(struct acpi_table_erst *erst_tab)
>  {
> - if (erst_tab->header_length != sizeof(struct acpi_table_erst))
> + if (erst_tab->header.length < sizeof(*erst_tab))
> return -EINVAL;
> - if (erst_tab->header.length < sizeof(struct acpi_table_erst))
> +
> + switch (erst_tab->header_length) {
> + case sizeof(*erst_tab) - sizeof(erst_tab->header):
> + /*
> +  * While invalid per specification, there are (early?) systems
> +  * indicating the full header size here, so accept that value too.
> +  */
> + case sizeof(*erst_tab):
> +  break;
> + default:
> return -EINVAL;
> + }
> +
> if (erst_tab->entries !=
> -     (erst_tab->header.length - sizeof(struct acpi_table_erst)) /
> +     (erst_tab->header.length - sizeof(*erst_tab)) /
>    sizeof(struct acpi_erst_entry))
> return -EINVAL;
>  
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 15:12:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 15:12:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO8ol-0005z2-W7; Tue, 16 Oct 2012 15:12:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO8ok-0005yg-G8
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 15:12:26 +0000
Received: from [85.158.139.211:18077] by server-6.bemta-5.messagelabs.com id
	CB/61-32589-9597D705; Tue, 16 Oct 2012 15:12:25 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1350400345!22557163!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2950 invoked from network); 16 Oct 2012 15:12:25 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 15:12:25 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so3827875eek.32
	for ; Tue, 16 Oct 2012 08:12:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=JvdXRaFZtDBqJ9o1zktorrGhGWiHm/RjNOKQh5ZPtpU=;
	b=ulcN3M/lHdApZNPqxqMaSj7G/FjDaTa3n/aTk0WFBKyZmAesl7J9bq0xItVZmFYRnQ
	zl1fxEHVcWRFC9dvfOYsyevT0YLX6dMgmIpu/RO5cfc7i4QBTUiRtAleUk0UKAUWkAPX
	KwKYr/RedgAscuaBBLTUMtrWTgWdovp5OK20efHiZuR4hOQPPALt9+X9QKp4id18EWdy
	g2ls2/NueEouK6kGZa0mzJBQREKv731o2itxzL6lzEQN742yK+DZ8V529MmD8QEHMziM
	qi4SUEvVfKzL8/ok1ya6ETcVRLaqvivkHrYEhWlzaVAtVSFwVNaexEUtwH2vq8f4BF2J
	Au5g==
Received: by 10.14.213.65 with SMTP id z41mr21426881eeo.29.1350400344880;
	Tue, 16 Oct 2012 08:12:24 -0700 (PDT)
Received: from [192.168.1.69]
	(host86-183-156-141.range86-183.btcentralplus.com. [86.183.156.141])
	by mx.google.com with ESMTPS id d44sm30424825eeo.10.2012.10.16.08.12.22
	(version=SSLv3 cipher=OTHER); Tue, 16 Oct 2012 08:12:23 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Tue, 16 Oct 2012 16:12:19 +0100
From: Keir Fraser 
To: Jan Beulich ,
	xen-devel 
Message-ID: 
Thread-Topic: [Xen-devel] [PATCH] ACPI: fix APEI related table size checking
Thread-Index: Ac2rsKJZUuhBikxPC0CNAV4FlwAxZw==
In-Reply-To: <507D8F6802000078000A1B88@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: ying.huang@intel.com
Subject: Re: [Xen-devel] [PATCH] ACPI: fix APEI related table size checking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 16/10/2012 15:46, "Jan Beulich"  wrote:

> On Huang Ying's machine:
> 
> erst_tab->header_length == sizeof(struct acpi_table_einj)
> 
> but Yinghai reported that on his machine,
> 
> erst_tab->header_length == sizeof(struct acpi_table_einj) -
> sizeof(struct acpi_table_header)
> 
> To make erst table size checking code works on all systems, both
> testing are treated as PASS.
> 
> Same situation applies to einj_tab->header_length, so corresponding
> table size checking is changed in similar way too.
> 
> Originally-by: Yinghai Lu 
> Signed-off-by: Huang Ying 
> 
> - use switch() for better readability
> - add comment explaining why a formally invalid size it also being
>   accepted
> - check erst_tab->header.length before even looking at
>   erst_tab->header_length
> - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
> 
> Signed-off-by: Jan Beulich 

Acked-by: Keir Fraser 

> --- a/xen/drivers/acpi/apei/erst.c
> +++ b/xen/drivers/acpi/apei/erst.c
> @@ -715,12 +715,23 @@ int erst_clear(u64 record_id)
>  
>  static int __init erst_check_table(struct acpi_table_erst *erst_tab)
>  {
> - if (erst_tab->header_length != sizeof(struct acpi_table_erst))
> + if (erst_tab->header.length < sizeof(*erst_tab))
> return -EINVAL;
> - if (erst_tab->header.length < sizeof(struct acpi_table_erst))
> +
> + switch (erst_tab->header_length) {
> + case sizeof(*erst_tab) - sizeof(erst_tab->header):
> + /*
> +  * While invalid per specification, there are (early?) systems
> +  * indicating the full header size here, so accept that value too.
> +  */
> + case sizeof(*erst_tab):
> +  break;
> + default:
> return -EINVAL;
> + }
> +
> if (erst_tab->entries !=
> -     (erst_tab->header.length - sizeof(struct acpi_table_erst)) /
> +     (erst_tab->header.length - sizeof(*erst_tab)) /
>    sizeof(struct acpi_erst_entry))
> return -EINVAL;
>  
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 15:38:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 15:38:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO9DM-0006RU-7d; Tue, 16 Oct 2012 15:37:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO9DK-0006RP-VN
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 15:37:51 +0000
Received: from [85.158.143.99:11004] by server-2.bemta-4.messagelabs.com id
	A1/05-22268-E4F7D705; Tue, 16 Oct 2012 15:37:50 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1350401867!24567656!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzY3MTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8292 invoked from network); 16 Oct 2012 15:37:49 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 15:37:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,593,1344211200"; d="scan'208";a="41384356"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Oct 2012 15:37:47 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 16 Oct 2012 11:37:46 -0400
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TO9DG-0005tD-Pp;
	Tue, 16 Oct 2012 16:37:46 +0100
Message-ID: <507D7F4A.8020409@citrix.com>
Date: Tue, 16 Oct 2012 16:37:46 +0100
From: Andrew Cooper 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Laszlo Ersek 
References: <507D6D84.8050602@redhat.com> <507D7240.2010305@citrix.com>
	<507D7774.2050902@redhat.com>
In-Reply-To: <507D7774.2050902@redhat.com>
X-Enigmail-Version: 1.4.5
Cc: Igor Mammedov , Drew Jones ,
	"xen-devel@lists.xen.org" ,
	Paolo Bonzini ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] PV passthrough of sibling igbvf's
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 16/10/12 16:04, Laszlo Ersek wrote:
> A closer pointer into the changeset:
>
> http://xenbits.xensource.com/xen-unstable.hg/rev/5b433b4fca34#l16.85
>
> The patch doesn't seem to justify the grouping specifically, thus I did
> not even try to refute it.
>
> Now that you point it out, match_slot() is probably insufficient grounds
> to group functions together. Maybe we should check *additionally* if the
> device being passed through is multi-function. I'll try it.

While that would hopefully solve the bug you have discovered, it does
raise some more queries.

What should we do when passing through only the first function of a
multifunction device, specifically in reference to domain
disagregation?  I would like to hope things would just work, but I am
somewhat doubtful.

For SRIOV hardware, passing the physical function through should be fine
(even though it is a multifunction device), as it is specifically
designed to work in this way.  For a CNA however, the chances of getting
it working at all with different functions in different domains is
unlikely at best.

I just wanted to put these thoughts out in case anyone has any bright
ideas about how to solve them.

~Andrew

>
> Thanks!
> Laszlo

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 15:38:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 15:38:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO9DM-0006RU-7d; Tue, 16 Oct 2012 15:37:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO9DK-0006RP-VN
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 15:37:51 +0000
Received: from [85.158.143.99:11004] by server-2.bemta-4.messagelabs.com id
	A1/05-22268-E4F7D705; Tue, 16 Oct 2012 15:37:50 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1350401867!24567656!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzY3MTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8292 invoked from network); 16 Oct 2012 15:37:49 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 15:37:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,593,1344211200"; d="scan'208";a="41384356"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Oct 2012 15:37:47 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 16 Oct 2012 11:37:46 -0400
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TO9DG-0005tD-Pp;
	Tue, 16 Oct 2012 16:37:46 +0100
Message-ID: <507D7F4A.8020409@citrix.com>
Date: Tue, 16 Oct 2012 16:37:46 +0100
From: Andrew Cooper 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Laszlo Ersek 
References: <507D6D84.8050602@redhat.com> <507D7240.2010305@citrix.com>
	<507D7774.2050902@redhat.com>
In-Reply-To: <507D7774.2050902@redhat.com>
X-Enigmail-Version: 1.4.5
Cc: Igor Mammedov , Drew Jones ,
	"xen-devel@lists.xen.org" ,
	Paolo Bonzini ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] PV passthrough of sibling igbvf's
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 16/10/12 16:04, Laszlo Ersek wrote:
> A closer pointer into the changeset:
>
> http://xenbits.xensource.com/xen-unstable.hg/rev/5b433b4fca34#l16.85
>
> The patch doesn't seem to justify the grouping specifically, thus I did
> not even try to refute it.
>
> Now that you point it out, match_slot() is probably insufficient grounds
> to group functions together. Maybe we should check *additionally* if the
> device being passed through is multi-function. I'll try it.

While that would hopefully solve the bug you have discovered, it does
raise some more queries.

What should we do when passing through only the first function of a
multifunction device, specifically in reference to domain
disagregation?  I would like to hope things would just work, but I am
somewhat doubtful.

For SRIOV hardware, passing the physical function through should be fine
(even though it is a multifunction device), as it is specifically
designed to work in this way.  For a CNA however, the chances of getting
it working at all with different functions in different domains is
unlikely at best.

I just wanted to put these thoughts out in case anyone has any bright
ideas about how to solve them.

~Andrew

>
> Thanks!
> Laszlo

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 15:42:06 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 15:42:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO9HC-0006ZR-1n; Tue, 16 Oct 2012 15:41:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO9HA-0006ZH-IB
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 15:41:48 +0000
Received: from [85.158.143.35:64818] by server-1.bemta-4.messagelabs.com id
	D8/7A-19134-B308D705; Tue, 16 Oct 2012 15:41:47 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1350402106!14244297!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 463 invoked from network); 16 Oct 2012 15:41:47 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 15:41:47 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so3846783eek.32
	for ; Tue, 16 Oct 2012 08:41:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=Vh7fUhC7GcvnUr2XMYKoEqRtMA4r92Dm9oMGl1MMQ+Y=;
	b=mf0r9OKVSzqw6NbmM8g6xKG/kkzxTa8NwMFF4dgBvQFQk8LyP6WTUuwx9wdzkOlYJv
	iNwnt4hR24Rw1ZL/nDnaqtbSoJ12Hmzs4ehgK6JSXBitsEY+0LObB04O0hL0NPG0WkoC
	Ld4TYAHinoa8GrY/N9LFwVn3h3D8Lvv/8rZkaI5V9SFkmCXB6x1VFwHlzcdD8/yzeiES
	jL4bQgwbOtpcvVvgKkW/PzFs/kiV7vidSM7DmC9qnSexW55lMJmk6siAjjJHERggZC+3
	WKfUeUI+KT5j+mCcx7/qjKZ6E9Ol39OHjgCYJXkUKhASC/qT0xHAWjvfylPn7Co+asug
	i62w==
Received: by 10.14.203.70 with SMTP id e46mr22010977eeo.2.1350402106780;
	Tue, 16 Oct 2012 08:41:46 -0700 (PDT)
Received: from [192.168.1.69]
	(host86-183-156-141.range86-183.btcentralplus.com. [86.183.156.141])
	by mx.google.com with ESMTPS id z43sm12033906een.16.2012.10.16.08.41.45
	(version=SSLv3 cipher=OTHER); Tue, 16 Oct 2012 08:41:46 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Tue, 16 Oct 2012 16:41:43 +0100
From: Keir Fraser 
To: Jan Beulich ,
	xen-devel 
Message-ID: 
Thread-Topic: [Xen-devel] [PATCH 1/3] x86/HPET: obtain proper lock for
	changing IRQ affinity
Thread-Index: Ac2rtL3GMveDDpFsOk6tKmDccVX+Gg==
In-Reply-To: <507D94BD02000078000A1BBD@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 1/3] x86/HPET: obtain proper lock for
 changing IRQ affinity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 16/10/2012 16:09, "Jan Beulich"  wrote:

> The IRQ descriptor lock should be held while adjusting the affinity of
> any IRQ; the HPET channel lock isn't sufficient to protect namely
> against races with moving the IRQ to a different CPU.
> 
> Signed-off-by: Jan Beulich 

Would be more usual for the underscore-prefixed name to be the one that
doesn't take locks?

 -- Keir

> --- a/xen/arch/x86/hpet.c
> +++ b/xen/arch/x86/hpet.c
> @@ -436,6 +436,16 @@ static struct hpet_event_channel *hpet_g
>      return ch;
>  }
>  
> +static void _hpet_msi_set_affinity(const struct hpet_event_channel *ch)
> +{
> +    struct irq_desc *desc = irq_to_desc(ch->irq);
> +
> +    ASSERT(!local_irq_is_enabled());
> +    spin_lock(&desc->lock);
> +    hpet_msi_set_affinity(desc, cpumask_of(ch->cpu));
> +    spin_unlock(&desc->lock);
> +}
> +
>  static void hpet_attach_channel(unsigned int cpu,
>                                  struct hpet_event_channel *ch)
>  {
> @@ -450,7 +460,7 @@ static void hpet_attach_channel(unsigned
>      if ( ch->cpu != cpu )
>          return;
>  
> -    hpet_msi_set_affinity(irq_to_desc(ch->irq), cpumask_of(ch->cpu));
> +    _hpet_msi_set_affinity(ch);
>  }
>  
>  static void hpet_detach_channel(unsigned int cpu,
> @@ -472,7 +482,7 @@ static void hpet_detach_channel(unsigned
>      }
>  
>      ch->cpu = cpumask_first(ch->cpumask);
> -    hpet_msi_set_affinity(irq_to_desc(ch->irq), cpumask_of(ch->cpu));
> +    _hpet_msi_set_affinity(ch);
>  }
>  
>  #include 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 15:42:06 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 15:42:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO9HC-0006ZR-1n; Tue, 16 Oct 2012 15:41:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO9HA-0006ZH-IB
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 15:41:48 +0000
Received: from [85.158.143.35:64818] by server-1.bemta-4.messagelabs.com id
	D8/7A-19134-B308D705; Tue, 16 Oct 2012 15:41:47 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1350402106!14244297!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 463 invoked from network); 16 Oct 2012 15:41:47 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 15:41:47 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so3846783eek.32
	for ; Tue, 16 Oct 2012 08:41:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=Vh7fUhC7GcvnUr2XMYKoEqRtMA4r92Dm9oMGl1MMQ+Y=;
	b=mf0r9OKVSzqw6NbmM8g6xKG/kkzxTa8NwMFF4dgBvQFQk8LyP6WTUuwx9wdzkOlYJv
	iNwnt4hR24Rw1ZL/nDnaqtbSoJ12Hmzs4ehgK6JSXBitsEY+0LObB04O0hL0NPG0WkoC
	Ld4TYAHinoa8GrY/N9LFwVn3h3D8Lvv/8rZkaI5V9SFkmCXB6x1VFwHlzcdD8/yzeiES
	jL4bQgwbOtpcvVvgKkW/PzFs/kiV7vidSM7DmC9qnSexW55lMJmk6siAjjJHERggZC+3
	WKfUeUI+KT5j+mCcx7/qjKZ6E9Ol39OHjgCYJXkUKhASC/qT0xHAWjvfylPn7Co+asug
	i62w==
Received: by 10.14.203.70 with SMTP id e46mr22010977eeo.2.1350402106780;
	Tue, 16 Oct 2012 08:41:46 -0700 (PDT)
Received: from [192.168.1.69]
	(host86-183-156-141.range86-183.btcentralplus.com. [86.183.156.141])
	by mx.google.com with ESMTPS id z43sm12033906een.16.2012.10.16.08.41.45
	(version=SSLv3 cipher=OTHER); Tue, 16 Oct 2012 08:41:46 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Tue, 16 Oct 2012 16:41:43 +0100
From: Keir Fraser 
To: Jan Beulich ,
	xen-devel 
Message-ID: 
Thread-Topic: [Xen-devel] [PATCH 1/3] x86/HPET: obtain proper lock for
	changing IRQ affinity
Thread-Index: Ac2rtL3GMveDDpFsOk6tKmDccVX+Gg==
In-Reply-To: <507D94BD02000078000A1BBD@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 1/3] x86/HPET: obtain proper lock for
 changing IRQ affinity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 16/10/2012 16:09, "Jan Beulich"  wrote:

> The IRQ descriptor lock should be held while adjusting the affinity of
> any IRQ; the HPET channel lock isn't sufficient to protect namely
> against races with moving the IRQ to a different CPU.
> 
> Signed-off-by: Jan Beulich 

Would be more usual for the underscore-prefixed name to be the one that
doesn't take locks?

 -- Keir

> --- a/xen/arch/x86/hpet.c
> +++ b/xen/arch/x86/hpet.c
> @@ -436,6 +436,16 @@ static struct hpet_event_channel *hpet_g
>      return ch;
>  }
>  
> +static void _hpet_msi_set_affinity(const struct hpet_event_channel *ch)
> +{
> +    struct irq_desc *desc = irq_to_desc(ch->irq);
> +
> +    ASSERT(!local_irq_is_enabled());
> +    spin_lock(&desc->lock);
> +    hpet_msi_set_affinity(desc, cpumask_of(ch->cpu));
> +    spin_unlock(&desc->lock);
> +}
> +
>  static void hpet_attach_channel(unsigned int cpu,
>                                  struct hpet_event_channel *ch)
>  {
> @@ -450,7 +460,7 @@ static void hpet_attach_channel(unsigned
>      if ( ch->cpu != cpu )
>          return;
>  
> -    hpet_msi_set_affinity(irq_to_desc(ch->irq), cpumask_of(ch->cpu));
> +    _hpet_msi_set_affinity(ch);
>  }
>  
>  static void hpet_detach_channel(unsigned int cpu,
> @@ -472,7 +482,7 @@ static void hpet_detach_channel(unsigned
>      }
>  
>      ch->cpu = cpumask_first(ch->cpumask);
> -    hpet_msi_set_affinity(irq_to_desc(ch->irq), cpumask_of(ch->cpu));
> +    _hpet_msi_set_affinity(ch);
>  }
>  
>  #include 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 15:49:35 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 15:49:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO9OQ-0006mo-RK; Tue, 16 Oct 2012 15:49:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO9OP-0006mj-3a
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 15:49:17 +0000
Received: from [85.158.139.211:40474] by server-15.bemta-5.messagelabs.com id
	FA/22-28599-CF18D705; Tue, 16 Oct 2012 15:49:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1350402554!22519858!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODI3MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23596 invoked from network); 16 Oct 2012 15:49:15 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 15:49:15 -0000
X-IronPort-AV: E=Sophos;i="4.80,593,1344211200"; d="scan'208";a="211440108"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Oct 2012 15:49:13 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 16 Oct 2012 11:49:13 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TO9OL-00063q-5q;
	Tue, 16 Oct 2012 16:49:13 +0100
MIME-Version: 1.0
X-Mercurial-Node: fd0989ae4407fe630b93e9dd8ec15eea07c7825b
Message-ID: 
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 16 Oct 2012 16:49:12 +0100
From: Ian Campbell 
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH] libxl: Use libxl__realloc in a couple of places
 in libxl_events.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Ian Campbell 
# Date 1350402378 -3600
# Node ID fd0989ae4407fe630b93e9dd8ec15eea07c7825b
# Parent  33487389f7f24f91ee4ff03bddfd8eb0b2c47ce1
libxl: Use libxl__realloc in a couple of places in libxl_events.c

This avoids us having to think about the error handling on failure.

Signed-off-by: Ian Campbell 

diff -r 33487389f7f2 -r fd0989ae4407 tools/libxl/libxl_event.c
--- a/tools/libxl/libxl_event.c	Tue Oct 16 16:45:43 2012 +0100
+++ b/tools/libxl/libxl_event.c	Tue Oct 16 16:46:18 2012 +0100
@@ -489,7 +489,8 @@ int libxl__ev_xswatch_register(libxl__gc
         int newarraysize = (CTX->watch_nslots + 1) << 2;
         int i;
         libxl__ev_watch_slot *newarray =
-            realloc(CTX->watch_slots, sizeof(*newarray) * newarraysize);
+            libxl__realloc(NOGC,
+                           CTX->watch_slots, sizeof(*newarray) * newarraysize);
         if (!newarray) goto out_nomem;
         for (i = CTX->watch_nslots; i < newarraysize; i++)
             LIBXL_SLIST_INSERT_HEAD(&CTX->watch_freeslots,
@@ -1343,7 +1344,7 @@ static int eventloop_iteration(libxl__eg
 
         struct pollfd *newarray =
             (nfds > INT_MAX / sizeof(struct pollfd) / 2) ? 0 :
-            realloc(poller->fd_polls, sizeof(*newarray) * nfds);
+            libxl__realloc(NOGC, poller->fd_polls, sizeof(*newarray) * nfds);
 
         if (!newarray) { rc = ERROR_NOMEM; goto out; }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 15:49:35 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 15:49:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO9OQ-0006mo-RK; Tue, 16 Oct 2012 15:49:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO9OP-0006mj-3a
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 15:49:17 +0000
Received: from [85.158.139.211:40474] by server-15.bemta-5.messagelabs.com id
	FA/22-28599-CF18D705; Tue, 16 Oct 2012 15:49:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1350402554!22519858!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODI3MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23596 invoked from network); 16 Oct 2012 15:49:15 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 15:49:15 -0000
X-IronPort-AV: E=Sophos;i="4.80,593,1344211200"; d="scan'208";a="211440108"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Oct 2012 15:49:13 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 16 Oct 2012 11:49:13 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TO9OL-00063q-5q;
	Tue, 16 Oct 2012 16:49:13 +0100
MIME-Version: 1.0
X-Mercurial-Node: fd0989ae4407fe630b93e9dd8ec15eea07c7825b
Message-ID: 
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 16 Oct 2012 16:49:12 +0100
From: Ian Campbell 
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH] libxl: Use libxl__realloc in a couple of places
 in libxl_events.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Ian Campbell 
# Date 1350402378 -3600
# Node ID fd0989ae4407fe630b93e9dd8ec15eea07c7825b
# Parent  33487389f7f24f91ee4ff03bddfd8eb0b2c47ce1
libxl: Use libxl__realloc in a couple of places in libxl_events.c

This avoids us having to think about the error handling on failure.

Signed-off-by: Ian Campbell 

diff -r 33487389f7f2 -r fd0989ae4407 tools/libxl/libxl_event.c
--- a/tools/libxl/libxl_event.c	Tue Oct 16 16:45:43 2012 +0100
+++ b/tools/libxl/libxl_event.c	Tue Oct 16 16:46:18 2012 +0100
@@ -489,7 +489,8 @@ int libxl__ev_xswatch_register(libxl__gc
         int newarraysize = (CTX->watch_nslots + 1) << 2;
         int i;
         libxl__ev_watch_slot *newarray =
-            realloc(CTX->watch_slots, sizeof(*newarray) * newarraysize);
+            libxl__realloc(NOGC,
+                           CTX->watch_slots, sizeof(*newarray) * newarraysize);
         if (!newarray) goto out_nomem;
         for (i = CTX->watch_nslots; i < newarraysize; i++)
             LIBXL_SLIST_INSERT_HEAD(&CTX->watch_freeslots,
@@ -1343,7 +1344,7 @@ static int eventloop_iteration(libxl__eg
 
         struct pollfd *newarray =
             (nfds > INT_MAX / sizeof(struct pollfd) / 2) ? 0 :
-            realloc(poller->fd_polls, sizeof(*newarray) * nfds);
+            libxl__realloc(NOGC, poller->fd_polls, sizeof(*newarray) * nfds);
 
         if (!newarray) { rc = ERROR_NOMEM; goto out; }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 15:49:47 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 15:49:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO9Ob-0006nG-7p; Tue, 16 Oct 2012 15:49:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO9Oa-0006n9-0m
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 15:49:28 +0000
Received: from [85.158.137.99:9150] by server-4.bemta-3.messagelabs.com id
	E1/61-01405-7028D705; Tue, 16 Oct 2012 15:49:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1350402565!21796828!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzY3MTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29133 invoked from network); 16 Oct 2012 15:49:26 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 15:49:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,593,1344211200"; d="scan'208";a="41386790"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Oct 2012 15:49:24 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 16 Oct 2012 11:49:24 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TO9OW-00063w-9m;
	Tue, 16 Oct 2012 16:49:24 +0100
MIME-Version: 1.0
X-Mercurial-Node: b180301556af546c4ef054d36015391284622e9e
Message-ID: 
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 16 Oct 2012 16:49:24 +0100
From: Ian Campbell 
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH] xl: Do not leak events when a domain exits
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Ian Campbell 
# Date 1350402554 -3600
# Node ID b180301556af546c4ef054d36015391284622e9e
# Parent  fd0989ae4407fe630b93e9dd8ec15eea07c7825b
xl: Do not leak events when a domain exits.

The goto in both of these places misses the event free which would
normally clean up.

==8655== 80 bytes in 1 blocks are definitely lost in loss record 1 of 1
==8655==    at 0x4024370: calloc (vg_replace_malloc.c:593)
==8655==    by 0x406EAAE: libxl__zalloc (libxl_internal.c:83)
==8655==    by 0x4078173: libxl__event_new (libxl_event.c:1167)
==8655==    by 0x4056373: domain_death_occurred (libxl.c:958)
==8655==    by 0x4058D06: domain_death_xswatch_callback (libxl.c:1038)
==8655==    by 0x4078EB5: watchfd_callback (libxl_event.c:458)
==8655==    by 0x407839E: afterpoll_internal (libxl_event.c:949)
==8655==    by 0x4079142: eventloop_iteration (libxl_event.c:1371)
==8655==    by 0x40799BB: libxl_event_wait (libxl_event.c:1396)
==8655==    by 0x805CC67: create_domain (xl_cmdimpl.c:1698)
==8655==    by 0x805E001: main_create (xl_cmdimpl.c:3986)
==8655==    by 0x804D43D: main (xl.c:285)


Signed-off-by: Ian Campbell 

diff -r fd0989ae4407 -r b180301556af tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Oct 16 16:46:18 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Tue Oct 16 16:49:14 2012 +0100
@@ -2118,6 +2118,7 @@ start:
 
             case 0:
                 LOG("Done. Exiting now");
+                libxl_event_free(ctx, event);
                 ret = 0;
                 goto out;
 
@@ -2127,6 +2128,7 @@ start:
 
         case LIBXL_EVENT_TYPE_DOMAIN_DEATH:
             LOG("Domain %d has been destroyed.", domid);
+            libxl_event_free(ctx, event);
             ret = 0;
             goto out;
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 15:49:47 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 15:49:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO9Ob-0006nG-7p; Tue, 16 Oct 2012 15:49:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO9Oa-0006n9-0m
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 15:49:28 +0000
Received: from [85.158.137.99:9150] by server-4.bemta-3.messagelabs.com id
	E1/61-01405-7028D705; Tue, 16 Oct 2012 15:49:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1350402565!21796828!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzY3MTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29133 invoked from network); 16 Oct 2012 15:49:26 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 15:49:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,593,1344211200"; d="scan'208";a="41386790"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Oct 2012 15:49:24 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 16 Oct 2012 11:49:24 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TO9OW-00063w-9m;
	Tue, 16 Oct 2012 16:49:24 +0100
MIME-Version: 1.0
X-Mercurial-Node: b180301556af546c4ef054d36015391284622e9e
Message-ID: 
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 16 Oct 2012 16:49:24 +0100
From: Ian Campbell 
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH] xl: Do not leak events when a domain exits
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Ian Campbell 
# Date 1350402554 -3600
# Node ID b180301556af546c4ef054d36015391284622e9e
# Parent  fd0989ae4407fe630b93e9dd8ec15eea07c7825b
xl: Do not leak events when a domain exits.

The goto in both of these places misses the event free which would
normally clean up.

==8655== 80 bytes in 1 blocks are definitely lost in loss record 1 of 1
==8655==    at 0x4024370: calloc (vg_replace_malloc.c:593)
==8655==    by 0x406EAAE: libxl__zalloc (libxl_internal.c:83)
==8655==    by 0x4078173: libxl__event_new (libxl_event.c:1167)
==8655==    by 0x4056373: domain_death_occurred (libxl.c:958)
==8655==    by 0x4058D06: domain_death_xswatch_callback (libxl.c:1038)
==8655==    by 0x4078EB5: watchfd_callback (libxl_event.c:458)
==8655==    by 0x407839E: afterpoll_internal (libxl_event.c:949)
==8655==    by 0x4079142: eventloop_iteration (libxl_event.c:1371)
==8655==    by 0x40799BB: libxl_event_wait (libxl_event.c:1396)
==8655==    by 0x805CC67: create_domain (xl_cmdimpl.c:1698)
==8655==    by 0x805E001: main_create (xl_cmdimpl.c:3986)
==8655==    by 0x804D43D: main (xl.c:285)


Signed-off-by: Ian Campbell 

diff -r fd0989ae4407 -r b180301556af tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Oct 16 16:46:18 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Tue Oct 16 16:49:14 2012 +0100
@@ -2118,6 +2118,7 @@ start:
 
             case 0:
                 LOG("Done. Exiting now");
+                libxl_event_free(ctx, event);
                 ret = 0;
                 goto out;
 
@@ -2127,6 +2128,7 @@ start:
 
         case LIBXL_EVENT_TYPE_DOMAIN_DEATH:
             LOG("Domain %d has been destroyed.", domid);
+            libxl_event_free(ctx, event);
             ret = 0;
             goto out;
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 15:53:51 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 15:53:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO9SW-00072z-Ak; Tue, 16 Oct 2012 15:53:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO9Q6-0006vb-7g
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 15:51:02 +0000
Received: from [85.158.143.99:7228] by server-3.bemta-4.messagelabs.com id
	9F/1E-03544-5628D705; Tue, 16 Oct 2012 15:51:01 +0000
X-Env-Sender: tpopusher@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1350402658!34325587!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_50_60,HTML_MESSAGE,
	MIME_BASE64_TEXT, MIME_BOUND_NEXTPART, ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP, spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6986 invoked from network); 16 Oct 2012 15:51:00 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 15:51:00 -0000
Received: by mail-pb0-f45.google.com with SMTP id rp2so6138627pbb.32
	for ; Tue, 16 Oct 2012 08:50:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=date:from:to:reply-to:subject:x-priority:x-has-attach:x-mailer
	:mime-version:message-id:content-type;
	bh=HjRiBFz/j2rzoL5qf6wXBfak/9/i9x/K4W/mndKq8ZY=;
	b=W8cJ9bMRea3mgzWGvCSl4aaO8Y5TaczX8EnzwHA5/dTAhY6HX/XtN8iEVeOI5MSgMd
	XT4XN40VQSGPVnRaoVfyKSFmwc+k5AKUx2YuiDuxWU1k9Vh4a9MUXwM8tXAITlwLRZxL
	t9ajct4AKfP6fQpqMPqHZdWTvnnC5JAw/fOeNefLXTyjj0cBCGBh7mcZ3Jxm97xHRSa7
	AZjHeuovvh4rgkuDz4a2W/srqVQGJmGVqalAXnS267eZwcLvvtwgSxPqwCp2jSJ1/G2v
	VghCRM3+RLMIjCQd7l/tSvO1jbio2grkfFijXEQD2hgDosOd1GfUuAVs533SmqVgeG1q
	vTJg==
Received: by 10.68.209.230 with SMTP id mp6mr2688705pbc.8.1350402658150;
	Tue, 16 Oct 2012 08:50:58 -0700 (PDT)
Received: from root ([115.199.246.228])
	by mx.google.com with ESMTPS id j9sm11031243paw.2.2012.10.16.08.50.54
	(version=SSLv3 cipher=OTHER); Tue, 16 Oct 2012 08:50:57 -0700 (PDT)
Date: Tue, 16 Oct 2012 23:51:01 +0800
From: tpopusher 
To: xen-devel 
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7.0.1.91[en]
Mime-Version: 1.0
Message-ID: <201210162350525313259@gmail.com>
X-Mailman-Approved-At: Tue, 16 Oct 2012 15:53:31 +0000
Subject: [Xen-devel] Meet a bit problem in Xen's gdb_stub
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: tpopusher 
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============9125333409360002451=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.

--===============9125333409360002451==
Content-Type: multipart/alternative;
	boundary="----=_001_NextPart721483583520_=----"

This is a multi-part message in MIME format.

------=_001_NextPart721483583520_=----
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: base64

SGksIGFsbDoNClJlY2VudGx5IEkgaGF2ZSBiZWVuIHZlcnkgaW50ZXJlc3RlZCBpbiB0aGlzIHN0
dWZmLCBieSB1c2luZyBnZGIgJ3MgdGFyZ2V0IHJlbW90ZSANCkkgY2FuIGNvbm5lY3QgdG8gZ2Ri
X3N0dWIgc3VjY2Vzc2Z1bGx5LiBOb3cgSSBjb3VsZCBtYWtlIGdkYiB0byBzZXQgYnJlYWtwb2lu
dCwgY29udGludWUsDQpjdHJsK2MgdG8gY29tZSBiYWNrLCBrIHRvIHF1aXQgdG8gbm9ybWFsIGFu
ZCBjb25uZWN0IGl0IGFnYWluLiBCdXQgaXQncyBub3QgcGVyZmVjdCwgaXQgYWx3YXlzIA0KY3Jh
c2ggb2NjYXNpb25hbGx5IHdoZW4gSSBwcmVzcyAncycgdG8gc3RlcCBpbnRvLCBvciBwcmVzcyAn
bicgdG8gcGFzcyBhIGZ1Y250aW9uLg0KDQpJIGRvbid0IGtub3cgaXQncyBvciBub3QgZ2RiX3N0
dWIncyBidWcsICByaWdodCBub3cgSSBwcm9uZSB0byBzdXNwZWN0ICdNJyB3aGljaCBjb21tYW5k
DQppbnNlcnRzIGEgaW50MycweGNjJyBtYXkgaGF2ZSBzb21lIGltcGVyZmVjdC4gaWYgc28sIGhv
dyB0byBmaXggaXQsIGhvcGUgc29tZWJvZHkgd2hvIGlzDQpwcm9maWNpZW50IGF0IGl0IG9yIGhh
dmUgbWV0IHRoZSBzYW1lIHByb2JsZW0gY2FuIGhlbHAgbWUsIHRoYW5rcyBhIGxvdCENCg0KDQoN
Cg0KdHBvcHVzaGVy

------=_001_NextPart721483583520_=----
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable









Hi, all:


Recently I have been very interested in th=
is=20
stuff, by using gdb 's target remote 


I can connect to gdb_stub successfully. Now I could make gdb=20
to set breakpoint, continue,


ctrl+c to come back, k to quit to normal and connect it again. But it=
's not=20
perfect, it always 


crash occasionally when I press 's' to step into, or p=
ress=20
'n' to pass a fucntion.


 


I don't know it's or not gdb_stub's bug,&n=
bsp;=20
right now I prone to suspect 'M' which command


inserts a int3'0xcc' may have some imperfect. if so, how to fix it, h=
ope=20
somebody who is


proficient at it or have met the same problem can help me, thanks a=20
lot!


 





tpopusher


------=_001_NextPart721483583520_=------



--===============9125333409360002451==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============9125333409360002451==--



From xen-devel-bounces@lists.xen.org Tue Oct 16 15:53:51 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 15:53:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO9SW-00072z-Ak; Tue, 16 Oct 2012 15:53:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO9Q6-0006vb-7g
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 15:51:02 +0000
Received: from [85.158.143.99:7228] by server-3.bemta-4.messagelabs.com id
	9F/1E-03544-5628D705; Tue, 16 Oct 2012 15:51:01 +0000
X-Env-Sender: tpopusher@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1350402658!34325587!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_50_60,HTML_MESSAGE,
	MIME_BASE64_TEXT, MIME_BOUND_NEXTPART, ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP, spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6986 invoked from network); 16 Oct 2012 15:51:00 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 15:51:00 -0000
Received: by mail-pb0-f45.google.com with SMTP id rp2so6138627pbb.32
	for ; Tue, 16 Oct 2012 08:50:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=date:from:to:reply-to:subject:x-priority:x-has-attach:x-mailer
	:mime-version:message-id:content-type;
	bh=HjRiBFz/j2rzoL5qf6wXBfak/9/i9x/K4W/mndKq8ZY=;
	b=W8cJ9bMRea3mgzWGvCSl4aaO8Y5TaczX8EnzwHA5/dTAhY6HX/XtN8iEVeOI5MSgMd
	XT4XN40VQSGPVnRaoVfyKSFmwc+k5AKUx2YuiDuxWU1k9Vh4a9MUXwM8tXAITlwLRZxL
	t9ajct4AKfP6fQpqMPqHZdWTvnnC5JAw/fOeNefLXTyjj0cBCGBh7mcZ3Jxm97xHRSa7
	AZjHeuovvh4rgkuDz4a2W/srqVQGJmGVqalAXnS267eZwcLvvtwgSxPqwCp2jSJ1/G2v
	VghCRM3+RLMIjCQd7l/tSvO1jbio2grkfFijXEQD2hgDosOd1GfUuAVs533SmqVgeG1q
	vTJg==
Received: by 10.68.209.230 with SMTP id mp6mr2688705pbc.8.1350402658150;
	Tue, 16 Oct 2012 08:50:58 -0700 (PDT)
Received: from root ([115.199.246.228])
	by mx.google.com with ESMTPS id j9sm11031243paw.2.2012.10.16.08.50.54
	(version=SSLv3 cipher=OTHER); Tue, 16 Oct 2012 08:50:57 -0700 (PDT)
Date: Tue, 16 Oct 2012 23:51:01 +0800
From: tpopusher 
To: xen-devel 
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7.0.1.91[en]
Mime-Version: 1.0
Message-ID: <201210162350525313259@gmail.com>
X-Mailman-Approved-At: Tue, 16 Oct 2012 15:53:31 +0000
Subject: [Xen-devel] Meet a bit problem in Xen's gdb_stub
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: tpopusher 
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============9125333409360002451=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.

--===============9125333409360002451==
Content-Type: multipart/alternative;
	boundary="----=_001_NextPart721483583520_=----"

This is a multi-part message in MIME format.

------=_001_NextPart721483583520_=----
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: base64

SGksIGFsbDoNClJlY2VudGx5IEkgaGF2ZSBiZWVuIHZlcnkgaW50ZXJlc3RlZCBpbiB0aGlzIHN0
dWZmLCBieSB1c2luZyBnZGIgJ3MgdGFyZ2V0IHJlbW90ZSANCkkgY2FuIGNvbm5lY3QgdG8gZ2Ri
X3N0dWIgc3VjY2Vzc2Z1bGx5LiBOb3cgSSBjb3VsZCBtYWtlIGdkYiB0byBzZXQgYnJlYWtwb2lu
dCwgY29udGludWUsDQpjdHJsK2MgdG8gY29tZSBiYWNrLCBrIHRvIHF1aXQgdG8gbm9ybWFsIGFu
ZCBjb25uZWN0IGl0IGFnYWluLiBCdXQgaXQncyBub3QgcGVyZmVjdCwgaXQgYWx3YXlzIA0KY3Jh
c2ggb2NjYXNpb25hbGx5IHdoZW4gSSBwcmVzcyAncycgdG8gc3RlcCBpbnRvLCBvciBwcmVzcyAn
bicgdG8gcGFzcyBhIGZ1Y250aW9uLg0KDQpJIGRvbid0IGtub3cgaXQncyBvciBub3QgZ2RiX3N0
dWIncyBidWcsICByaWdodCBub3cgSSBwcm9uZSB0byBzdXNwZWN0ICdNJyB3aGljaCBjb21tYW5k
DQppbnNlcnRzIGEgaW50MycweGNjJyBtYXkgaGF2ZSBzb21lIGltcGVyZmVjdC4gaWYgc28sIGhv
dyB0byBmaXggaXQsIGhvcGUgc29tZWJvZHkgd2hvIGlzDQpwcm9maWNpZW50IGF0IGl0IG9yIGhh
dmUgbWV0IHRoZSBzYW1lIHByb2JsZW0gY2FuIGhlbHAgbWUsIHRoYW5rcyBhIGxvdCENCg0KDQoN
Cg0KdHBvcHVzaGVy

------=_001_NextPart721483583520_=----
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable









Hi, all:


Recently I have been very interested in th=
is=20
stuff, by using gdb 's target remote 


I can connect to gdb_stub successfully. Now I could make gdb=20
to set breakpoint, continue,


ctrl+c to come back, k to quit to normal and connect it again. But it=
's not=20
perfect, it always 


crash occasionally when I press 's' to step into, or p=
ress=20
'n' to pass a fucntion.


 


I don't know it's or not gdb_stub's bug,&n=
bsp;=20
right now I prone to suspect 'M' which command


inserts a int3'0xcc' may have some imperfect. if so, how to fix it, h=
ope=20
somebody who is


proficient at it or have met the same problem can help me, thanks a=20
lot!


 





tpopusher


------=_001_NextPart721483583520_=------



--===============9125333409360002451==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============9125333409360002451==--



From xen-devel-bounces@lists.xen.org Tue Oct 16 16:11:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 16:11:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO9jz-0007iq-5M; Tue, 16 Oct 2012 16:11:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO9jx-0007il-6T
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 16:11:33 +0000
Received: from [85.158.138.51:47767] by server-7.bemta-3.messagelabs.com id
	7E/E3-06991-3378D705; Tue, 16 Oct 2012 16:11:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1350403891!32903238!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2MDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16901 invoked from network); 16 Oct 2012 16:11:31 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-174.messagelabs.com with SMTP;
	16 Oct 2012 16:11:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 16 Oct 2012 17:11:30 +0100
Message-Id: <507DA35102000078000A1C26@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 16 Oct 2012 17:11:29 +0100
From: "Jan Beulich" 
To: "Keir Fraser" 
References: <507D94BD02000078000A1BBD@nat28.tlf.novell.com>
	
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel 
Subject: Re: [Xen-devel] [PATCH 1/3] x86/HPET: obtain proper lock for
 changing IRQ affinity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 16.10.12 at 17:41, Keir Fraser  wrote:
> On 16/10/2012 16:09, "Jan Beulich"  wrote:
> 
>> The IRQ descriptor lock should be held while adjusting the affinity of
>> any IRQ; the HPET channel lock isn't sufficient to protect namely
>> against races with moving the IRQ to a different CPU.
>> 
>> Signed-off-by: Jan Beulich 
> 
> Would be more usual for the underscore-prefixed name to be the one that
> doesn't take locks?

Will make the patch bigger, but I can certainly do that. I specifically
picked only a single underscore to distinguish this a little from the
"usual" case.

Jan

>> --- a/xen/arch/x86/hpet.c
>> +++ b/xen/arch/x86/hpet.c
>> @@ -436,6 +436,16 @@ static struct hpet_event_channel *hpet_g
>>      return ch;
>>  }
>>  
>> +static void _hpet_msi_set_affinity(const struct hpet_event_channel *ch)
>> +{
>> +    struct irq_desc *desc = irq_to_desc(ch->irq);
>> +
>> +    ASSERT(!local_irq_is_enabled());
>> +    spin_lock(&desc->lock);
>> +    hpet_msi_set_affinity(desc, cpumask_of(ch->cpu));
>> +    spin_unlock(&desc->lock);
>> +}
>> +
>>  static void hpet_attach_channel(unsigned int cpu,
>>                                  struct hpet_event_channel *ch)
>>  {
>> @@ -450,7 +460,7 @@ static void hpet_attach_channel(unsigned
>>      if ( ch->cpu != cpu )
>>          return;
>>  
>> -    hpet_msi_set_affinity(irq_to_desc(ch->irq), cpumask_of(ch->cpu));
>> +    _hpet_msi_set_affinity(ch);
>>  }
>>  
>>  static void hpet_detach_channel(unsigned int cpu,
>> @@ -472,7 +482,7 @@ static void hpet_detach_channel(unsigned
>>      }
>>  
>>      ch->cpu = cpumask_first(ch->cpumask);
>> -    hpet_msi_set_affinity(irq_to_desc(ch->irq), cpumask_of(ch->cpu));
>> +    _hpet_msi_set_affinity(ch);
>>  }
>>  
>>  #include 
>> 
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org 
>> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 16:11:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 16:11:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO9jz-0007iq-5M; Tue, 16 Oct 2012 16:11:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO9jx-0007il-6T
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 16:11:33 +0000
Received: from [85.158.138.51:47767] by server-7.bemta-3.messagelabs.com id
	7E/E3-06991-3378D705; Tue, 16 Oct 2012 16:11:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1350403891!32903238!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM2MDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16901 invoked from network); 16 Oct 2012 16:11:31 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-174.messagelabs.com with SMTP;
	16 Oct 2012 16:11:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 16 Oct 2012 17:11:30 +0100
Message-Id: <507DA35102000078000A1C26@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 16 Oct 2012 17:11:29 +0100
From: "Jan Beulich" 
To: "Keir Fraser" 
References: <507D94BD02000078000A1BBD@nat28.tlf.novell.com>
	
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel 
Subject: Re: [Xen-devel] [PATCH 1/3] x86/HPET: obtain proper lock for
 changing IRQ affinity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 16.10.12 at 17:41, Keir Fraser  wrote:
> On 16/10/2012 16:09, "Jan Beulich"  wrote:
> 
>> The IRQ descriptor lock should be held while adjusting the affinity of
>> any IRQ; the HPET channel lock isn't sufficient to protect namely
>> against races with moving the IRQ to a different CPU.
>> 
>> Signed-off-by: Jan Beulich 
> 
> Would be more usual for the underscore-prefixed name to be the one that
> doesn't take locks?

Will make the patch bigger, but I can certainly do that. I specifically
picked only a single underscore to distinguish this a little from the
"usual" case.

Jan

>> --- a/xen/arch/x86/hpet.c
>> +++ b/xen/arch/x86/hpet.c
>> @@ -436,6 +436,16 @@ static struct hpet_event_channel *hpet_g
>>      return ch;
>>  }
>>  
>> +static void _hpet_msi_set_affinity(const struct hpet_event_channel *ch)
>> +{
>> +    struct irq_desc *desc = irq_to_desc(ch->irq);
>> +
>> +    ASSERT(!local_irq_is_enabled());
>> +    spin_lock(&desc->lock);
>> +    hpet_msi_set_affinity(desc, cpumask_of(ch->cpu));
>> +    spin_unlock(&desc->lock);
>> +}
>> +
>>  static void hpet_attach_channel(unsigned int cpu,
>>                                  struct hpet_event_channel *ch)
>>  {
>> @@ -450,7 +460,7 @@ static void hpet_attach_channel(unsigned
>>      if ( ch->cpu != cpu )
>>          return;
>>  
>> -    hpet_msi_set_affinity(irq_to_desc(ch->irq), cpumask_of(ch->cpu));
>> +    _hpet_msi_set_affinity(ch);
>>  }
>>  
>>  static void hpet_detach_channel(unsigned int cpu,
>> @@ -472,7 +482,7 @@ static void hpet_detach_channel(unsigned
>>      }
>>  
>>      ch->cpu = cpumask_first(ch->cpumask);
>> -    hpet_msi_set_affinity(irq_to_desc(ch->irq), cpumask_of(ch->cpu));
>> +    _hpet_msi_set_affinity(ch);
>>  }
>>  
>>  #include 
>> 
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org 
>> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 16:27:26 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 16:27:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO9z0-0007wY-4g; Tue, 16 Oct 2012 16:27:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO9yy-0007wT-I0
	for Xen-devel@lists.xensource.com; Tue, 16 Oct 2012 16:27:04 +0000
Received: from [85.158.143.99:28222] by server-1.bemta-4.messagelabs.com id
	FD/FF-19134-7DA8D705; Tue, 16 Oct 2012 16:27:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1350404823!24573825!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQzMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18978 invoked from network); 16 Oct 2012 16:27:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 16:27:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,593,1344211200"; d="scan'208";a="15208854"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Oct 2012 16:27:03 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 16 Oct 2012 17:27:03 +0100
Message-ID: <1350404821.2460.3.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Mukesh Rathor 
Date: Tue, 16 Oct 2012 17:27:01 +0100
In-Reply-To: <1350032276.14806.53.camel@zakaz.uk.xensource.com>
References: <20121011145817.0d744c99@mantra.us.oracle.com>
	<1350032276.14806.53.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" , Konrad
	Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V2 3/7]: PVH:  mmu related changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-12 at 09:57 +0100, Ian Campbell wrote:
> > +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma)
> > +{
> > +       int numpgs = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
> > +       struct page **pages = vma ? vma->vm_private_data : NULL;
> 
> I thought we agreed to keep uses of vm_private_data in the privcmd
> driver?
> 
> I think you should just add pages and nr as direct parameters to this
> function, which is symmetric with the map call.

I had to look at this while rebasing my arm patches, turned out to be
fairly simple. Feel free to either fold in or badger me for a proper
commit message.

Signed-off-by: Ian Campbell 

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 018cbf0..1c5812b 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -2655,11 +2655,9 @@ out:
 EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
 
 /* Returns: 0 success */
-int xen_unmap_domain_mfn_range(struct vm_area_struct *vma)
+int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
+			       struct page **pages, int numpgs)
 {
-	int numpgs = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
-	struct page **pages = vma ? vma->vm_private_data : NULL;
-
 	if (!pages || !xen_feature(XENFEAT_auto_translated_physmap))
 		return 0;
 
diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 641a420..a1ca5ab 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -498,7 +498,7 @@ static void privcmd_close(struct vm_area_struct *vma)
 	if (!pages || !numpgs || !xen_feature(XENFEAT_auto_translated_physmap))
 		return;
 
-	xen_unmap_domain_mfn_range(vma);
+	xen_unmap_domain_mfn_range(vma, pages, numpgs);
 	while (numpgs--)
 		free_xenballooned_pages(1, &pages[numpgs]);
 	kfree(pages);
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index db3b3b7..dc63e80 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -29,6 +29,7 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 			       xen_pfn_t mfn, int nr,
 			       pgprot_t prot, unsigned domid,
 			       struct page **pages);
-int xen_unmap_domain_mfn_range(struct vm_area_struct *vma);
+int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
+			       struct page **pages, int nr);
 
 #endif /* INCLUDE_XEN_OPS_H */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 16:27:26 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 16:27:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TO9z0-0007wY-4g; Tue, 16 Oct 2012 16:27:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TO9yy-0007wT-I0
	for Xen-devel@lists.xensource.com; Tue, 16 Oct 2012 16:27:04 +0000
Received: from [85.158.143.99:28222] by server-1.bemta-4.messagelabs.com id
	FD/FF-19134-7DA8D705; Tue, 16 Oct 2012 16:27:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1350404823!24573825!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQzMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18978 invoked from network); 16 Oct 2012 16:27:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 16:27:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,593,1344211200"; d="scan'208";a="15208854"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Oct 2012 16:27:03 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 16 Oct 2012 17:27:03 +0100
Message-ID: <1350404821.2460.3.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Mukesh Rathor 
Date: Tue, 16 Oct 2012 17:27:01 +0100
In-Reply-To: <1350032276.14806.53.camel@zakaz.uk.xensource.com>
References: <20121011145817.0d744c99@mantra.us.oracle.com>
	<1350032276.14806.53.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" , Konrad
	Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V2 3/7]: PVH:  mmu related changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-12 at 09:57 +0100, Ian Campbell wrote:
> > +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma)
> > +{
> > +       int numpgs = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
> > +       struct page **pages = vma ? vma->vm_private_data : NULL;
> 
> I thought we agreed to keep uses of vm_private_data in the privcmd
> driver?
> 
> I think you should just add pages and nr as direct parameters to this
> function, which is symmetric with the map call.

I had to look at this while rebasing my arm patches, turned out to be
fairly simple. Feel free to either fold in or badger me for a proper
commit message.

Signed-off-by: Ian Campbell 

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 018cbf0..1c5812b 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -2655,11 +2655,9 @@ out:
 EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
 
 /* Returns: 0 success */
-int xen_unmap_domain_mfn_range(struct vm_area_struct *vma)
+int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
+			       struct page **pages, int numpgs)
 {
-	int numpgs = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
-	struct page **pages = vma ? vma->vm_private_data : NULL;
-
 	if (!pages || !xen_feature(XENFEAT_auto_translated_physmap))
 		return 0;
 
diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 641a420..a1ca5ab 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -498,7 +498,7 @@ static void privcmd_close(struct vm_area_struct *vma)
 	if (!pages || !numpgs || !xen_feature(XENFEAT_auto_translated_physmap))
 		return;
 
-	xen_unmap_domain_mfn_range(vma);
+	xen_unmap_domain_mfn_range(vma, pages, numpgs);
 	while (numpgs--)
 		free_xenballooned_pages(1, &pages[numpgs]);
 	kfree(pages);
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index db3b3b7..dc63e80 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -29,6 +29,7 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 			       xen_pfn_t mfn, int nr,
 			       pgprot_t prot, unsigned domid,
 			       struct page **pages);
-int xen_unmap_domain_mfn_range(struct vm_area_struct *vma);
+int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
+			       struct page **pages, int nr);
 
 #endif /* INCLUDE_XEN_OPS_H */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 17:28:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 17:28:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOAvj-0008Pi-O6; Tue, 16 Oct 2012 17:27:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOAvg-0008Pa-Ak
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 17:27:46 +0000
Received: from [85.158.138.51:18898] by server-2.bemta-3.messagelabs.com id
	04/66-00604-E099D705; Tue, 16 Oct 2012 17:27:42 +0000
X-Env-Sender: stse@fsing.rootsland.net
X-Msg-Ref: server-2.tower-174.messagelabs.com!1350408461!34515821!1
X-Originating-IP: [62.141.37.30]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9081 invoked from network); 16 Oct 2012 17:27:42 -0000
Received: from fsing.rootsland.net (HELO fsing.rootsland.net) (62.141.37.30)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Oct 2012 17:27:42 -0000
Received: from osgiliath.gondor (osgiliath.gondor [IPv6:2a01:198:492::10])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "Stephan Seitz", Issuer "CAcert Class 3 Root" (verified OK))
	by fsing.rootsland.net (Postfix) with ESMTPS id 94A36C950025
	for ; Tue, 16 Oct 2012 19:27:41 +0200 (CEST)
X-DKIM: OpenDKIM Filter v2.6.2 fsing.rootsland.net 94A36C950025
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fsing.rootsland.net;
	s=mail20100714; t=1350408461;
	bh=LQy0ezGLFUyky7EzWe0+p0E6II/mKlDCZvyDky8Mu2s=;
	h=Date:From:To:Subject;
	b=LkiVutxh1XNyATR8qC1lUAUldTuJ7wOYoTWFMNLCfsyxS9OF5ffsp1OBIjoHnLeqD
	vnu4yugz1PyVxEJl6QpJ7teYdsye+SFtG1wMeDoW/DloLQHoUOC/51mhJroOR7XibS
	pBUb3FupRwnMb8Qq+a4l5efYvVRtdLPZLEigBJVw=
Received: by osgiliath.gondor (Postfix, from userid 10009)
	id 5A51A600A9; Tue, 16 Oct 2012 19:27:40 +0200 (CEST)
Date: Tue, 16 Oct 2012 19:27:40 +0200
From: Stephan Seitz 
To: xen-devel 
Message-ID: <20121016T192158.GA.6e659.stse@fsing.rootsland.net>
MIME-Version: 1.0
Organization: Minas Tirith, Gondor
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: [Xen-devel] CPU microcode update under xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============4296586594468179801=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============4296586594468179801==
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
	micalg=sha1; boundary="+HP7ph2BbKc20aGI"
Content-Disposition: inline


--+HP7ph2BbKc20aGI
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi!

System: Debian/testing with selfcompiled kernel 3.5.5 (same error with=20
3.4 or 3.6)
XEN: 4.1.3

After booting the Dom0 I notice the following errors:
[    2.939078] microcode: CPU0 sig=3D0x1067a, pf=3D0x1, revision=3D0xa07
[    2.991998] microcode: CPU0 update to revision 0xa0b failed
[    2.992035] microcode: CPU1 sig=3D0x1067a, pf=3D0x1, revision=3D0xa07
[    2.995882] microcode: CPU1 update to revision 0xa0b failed
[    2.995942] microcode: Microcode Update Driver: v2.00 , Peter Oruba

If I boot the same kernel without the hypervisor the microcode update is=20
successful.

stse@osgiliath:~$ zcat /proc/config.gz |grep MICROCODE
CONFIG_MICROCODE=3Dm
CONFIG_MICROCODE_INTEL=3Dy
# CONFIG_MICROCODE_AMD is not set
CONFIG_MICROCODE_OLD_INTERFACE=3Dy

 From /proc/cpuinfo:
Intel(R) Core(TM)2 Duo CPU     E8500  @ 3.16GHz

Do I need another driver for microcode updates under XEN, or is it=20
impossible for now?

	Stephan

--=20
| Stephan Seitz          E-Mail: stse@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |

--+HP7ph2BbKc20aGI
Content-Type: application/x-pkcs7-signature
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIIOIQYJKoZIhvcNAQcCoIIOEjCCDg4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
C4wwggYIMIID8KADAgECAgEBMA0GCSqGSIb3DQEBBAUAMHkxEDAOBgNVBAoTB1Jvb3QgQ0Ex
HjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWdu
aW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnMB4XDTA1
MTAxNDA3MzY1NVoXDTMzMDMyODA3MzY1NVowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAc
BgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMg
Um9vdDCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAKtJNRFIfNImflOUz0Op3SjX
QiqL84d4GVh8D57aiX3h++tykA10oZZkq5+gJJlz2uJVdscXe/UErEa4w75/ZI0QbCTzYZzA
8pD6Ueb1aQFjww9W4kpCz+JEjCUoqMV5CX1GuYrz6fM0KQhF5Byfy5QEHIGoFLOYZcRD7E6C
jQnRvapbjZLQ7N6QxX8KwuPr5jFaXnQ+lzNZ6MMDPWAzv/fRb0fEze5ig1JuLgiapNkVGJGm
hZJHsK5I6223IeyFGmhyNav/8BBdwPSUp2rVO5J+TJAFfpPBLIukjmJ0FXFuC3ED6q8VOJrU
0gVyb4z5K+taciX5OUbjchs+BMNkJyIQKopPWKcDrb60LhPtXapI19V91Cp7XPpGBFDkzA5C
W4zt2/LP/JaT4NsRNlRiNDiPDGCbO5dWOK3z0luLoFvqTpa4fNfVoIZwQNORKbeiPK31jLvP
GpKK5DR7wNhsX+kKwsOnIJpa3yxdUly6R9Wb7yQocDggL9V/KcCyQQNokszgnMyXS0XvOhAK
q3A6mJVwrTWx6oUrpByAITGprmB6gCZIALgBwJNjVSKRPFbnr9s6JfOPMVTqJouBWfmh0VMR
xXudA/Z0EeBtsSw/LIaRmXGapneLNGDRFLQsrJ2vjBDTn8Rq+G8T/HNZ92ZCdB6K4/jc0m+Y
nMtHmJVABfvpAgMBAAGjgb8wgbwwDwYDVR0TAQH/BAUwAwEB/zBdBggrBgEFBQcBAQRRME8w
IwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLkNBY2VydC5vcmcvMCgGCCsGAQUFBzAChhxodHRw
Oi8vd3d3LkNBY2VydC5vcmcvY2EuY3J0MEoGA1UdIARDMEEwPwYIKwYBBAGBkEowMzAxBggr
BgEFBQcCARYlaHR0cDovL3d3dy5DQWNlcnQub3JnL2luZGV4LnBocD9pZD0xMDANBgkqhkiG
9w0BAQQFAAOCAgEAfwiIodoaUEnaifuhCHLzivcexDq0eVsgMLFF3sJd02Vp8cJdVFQ8hV+5
e0KRwpn9G1Gbq0aloRBTnm2IrHNuLDOm8PSe4HXBPohFqeFmQ/5WWtF6QXj3QNpKOvELW6W7
FgbmwueTuYVNl0+xHjhDgO+bDYzvuKdgAIdXfR5EHMsj75s8mZ2vtSkcRXkWlk0nbfEcbMPC
VWSzvBTi86QfHjL8JxUFz90urj6CYXvwIRAY9kTqUzn53NCaIODGu+C7Wk/EmcgHvbW9otsu
Yg1CNEG8/4uK9VEiqogwAOKw1Ly+ZbrVA1d5m+jcyE34UO2RpVIooqz7Nlg+6ZQrkVCHG9Ze
1ozM9w8QDFJO0BZh5eUKbL8Xx3JGV5yY9WxgY3pvXrlOL8i5ubtqhbyYDe35PpeENJSuAK+h
5eeSbk698+LZFItc0usBbKAXpS0Q65x6Sr297s797SJAq3A4iPUKh2rCqwVgyUgF2lPB3kR3
arPzPDztgLymOEopJF/+WTubJXpWYwBkuV2kYn1XNk+tg+8fklOgjndX3eVhET0jAJBMPPqj
YJMEo6819g5qj09KYKeFBWxGoY/0x3bjoVlX93GyxG4UXG1tQWbfG5Ox1ADD7svPPD0hgKlf
Y2X83eBfpPQr8IVxQdRnJfsasZeu1pmCE0HSbqUbmSeA5wupqAAwggV8MIIDZKADAgECAgMA
7qMwDQYJKoZIhvcNAQEFBQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0
dHA6Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDAeFw0x
MjAyMDcwOTQ3NDVaFw0xNDAyMDYwOTQ3NDVaMHoxFjAUBgNVBAMTDVN0ZXBoYW4gU2VpdHox
JzAlBgkqhkiG9w0BCQEWGHN0c2VAZnNpbmcucm9vdHNsYW5kLm5ldDE3MDUGCSqGSIb3DQEJ
ARYoYjAyOTM1ZjY0MzY2ZWJjNTMyNzRkZWFlNzdjNTlmNWQ0NjFkMzA5MjCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBANmTAhUdu+xjRo+1NWftASWgV7mYi1Gdfdukbr0OcsYL
nxveMvFuTnwzF9IvX18nGes2PKBDtZDwO/CmzBwFw9HHi9ewy1iSJSRZ1PoklFdUts4PsqHh
SF3X9m+NOYtXTHmnzzVphwjtQW4pkzo5r2eF7SWg8sUZeIw5ZTpUa1dJZ2StXhX/4IQJS+vy
4lPBwrthxABsOYeNDVo65k+r4hwuo4LujnbEXetRfgx1nsWsfklZkPmSwKrLLiGKKl7CnLLX
z2ayURu2Z5J9GM/6DJw+BCTwgHKpPc/ERLrRHUw7W7cETaaKqpgMVE4se1v/jJo2C4oKa2qS
iJXQGvxZUzkCAwEAAaOCAS8wggErMAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1Rv
IGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDov
L3d3dy5DQWNlcnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGC
NwoDBAYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcw
AYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzBNBgNVHREERjBEgRhzdHNlQGZzaW5nLnJvb3Rz
bGFuZC5uZXSBKGIwMjkzNWY2NDM2NmViYzUzMjc0ZGVhZTc3YzU5ZjVkNDYxZDMwOTIwDQYJ
KoZIhvcNAQEFBQADggIBABULJCng9rYUzDvpGoGlmz0mxmAO459Son4/lyx8cayyucnqWMgl
/RP3rmKtLg6brRPLrowTyOEpwZ12jR/JSGWv5B8rjWza3hAWHofQ+6HfP0RPTO2vTFyUaLcD
OZ4buknqHAYaS2gp1d2KVBjvrs4QjhS65/0o6tVvA3inAIkQ1h1t9bK8UC0NiA33QIzYhJKF
p3/VTqEOKC/B44mSZ57MJ2uQ0mAUpvbQKpUE74FGIsfgKgTSoZqimsaJjYB3tn4lGzBjYVff
Hi8dmVL1Q0nb93Qae/wXvJaboVW5ztNNFdKrpoQUuNkyssNBoHRA/QPpK2RVkDK+YGza0gEb
832naD4QdZTiiPuzjfV/a8p71TTyHp1eHjvkOU8yKL9DUpLPgX06VRkm+FqjXa7xWis8Jdbl
puXokx5YHifeJjDSci/9apkncZT5tMBNQvSJvjJ+TDMxdrF0rYl8rJMRzg+ckxHeSpw396XU
V8dMgoqFZTasaXqLGDIRqmT381EjBMoZIuxhQochks3Zyq+3QG3wPz98jTQorcF7nS2xMu4O
ovLlQQw6cVAySNX6W6ywVsGbZOZ3+tEIb5WuBgQqe0/eWIt6BhDco8zDzU9dyI2cTrkxxcOp
f1gijBskSDEFwAOjBtDRTzL5vhib+TS3tCQLupcXA29M6pv92YuaDW9zMYICXTCCAlkCAQEw
WzBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQu
b3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290AgMA7qMwCQYFKw4DAhoFAKCB2DAY
BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjEwMTYxNzI3NDBa
MCMGCSqGSIb3DQEJBDEWBBSlF9ot7TAVS4DJFKU5kqlcuUM46DB5BgkqhkiG9w0BCQ8xbDBq
MAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G
CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAN
BgkqhkiG9w0BAQEFAASCAQAfDz4ZzIEc4IjguoHzCArvOoZiuq5vj0fjrWC6uH5Zvg2Bd6ok
jKz8kiIQ6Chmh58/w6jMSQn53F7f0VI4hT4+WEM1IZnJX7Srywo+v6VK2uJUCikns+w4AJfM
bHP2EWLL8iMol1Bl+COBep5JZ1Wo/bXJd+Rj5MVsAkjkMU/Jzf811veQn3SPr/9aurYhzk//
VCx3EhtsGiMSKsCrxEYMjgZQ8XhLxpYNsOV1bojWe4ElA58V+4K6KtZupzanUi4UAKys3vF5
mBqnQTfxqKpYZ1reTMlNNT/Lfs4P135ZTFKwFgmxOoA1rmgpvtHpk3b0om3URNfCRT9rZgfH
axxJ

--+HP7ph2BbKc20aGI--


--===============4296586594468179801==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4296586594468179801==--


From xen-devel-bounces@lists.xen.org Tue Oct 16 17:28:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 17:28:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOAvj-0008Pi-O6; Tue, 16 Oct 2012 17:27:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOAvg-0008Pa-Ak
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 17:27:46 +0000
Received: from [85.158.138.51:18898] by server-2.bemta-3.messagelabs.com id
	04/66-00604-E099D705; Tue, 16 Oct 2012 17:27:42 +0000
X-Env-Sender: stse@fsing.rootsland.net
X-Msg-Ref: server-2.tower-174.messagelabs.com!1350408461!34515821!1
X-Originating-IP: [62.141.37.30]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9081 invoked from network); 16 Oct 2012 17:27:42 -0000
Received: from fsing.rootsland.net (HELO fsing.rootsland.net) (62.141.37.30)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Oct 2012 17:27:42 -0000
Received: from osgiliath.gondor (osgiliath.gondor [IPv6:2a01:198:492::10])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "Stephan Seitz", Issuer "CAcert Class 3 Root" (verified OK))
	by fsing.rootsland.net (Postfix) with ESMTPS id 94A36C950025
	for ; Tue, 16 Oct 2012 19:27:41 +0200 (CEST)
X-DKIM: OpenDKIM Filter v2.6.2 fsing.rootsland.net 94A36C950025
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fsing.rootsland.net;
	s=mail20100714; t=1350408461;
	bh=LQy0ezGLFUyky7EzWe0+p0E6II/mKlDCZvyDky8Mu2s=;
	h=Date:From:To:Subject;
	b=LkiVutxh1XNyATR8qC1lUAUldTuJ7wOYoTWFMNLCfsyxS9OF5ffsp1OBIjoHnLeqD
	vnu4yugz1PyVxEJl6QpJ7teYdsye+SFtG1wMeDoW/DloLQHoUOC/51mhJroOR7XibS
	pBUb3FupRwnMb8Qq+a4l5efYvVRtdLPZLEigBJVw=
Received: by osgiliath.gondor (Postfix, from userid 10009)
	id 5A51A600A9; Tue, 16 Oct 2012 19:27:40 +0200 (CEST)
Date: Tue, 16 Oct 2012 19:27:40 +0200
From: Stephan Seitz 
To: xen-devel 
Message-ID: <20121016T192158.GA.6e659.stse@fsing.rootsland.net>
MIME-Version: 1.0
Organization: Minas Tirith, Gondor
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: [Xen-devel] CPU microcode update under xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============4296586594468179801=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============4296586594468179801==
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
	micalg=sha1; boundary="+HP7ph2BbKc20aGI"
Content-Disposition: inline


--+HP7ph2BbKc20aGI
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi!

System: Debian/testing with selfcompiled kernel 3.5.5 (same error with=20
3.4 or 3.6)
XEN: 4.1.3

After booting the Dom0 I notice the following errors:
[    2.939078] microcode: CPU0 sig=3D0x1067a, pf=3D0x1, revision=3D0xa07
[    2.991998] microcode: CPU0 update to revision 0xa0b failed
[    2.992035] microcode: CPU1 sig=3D0x1067a, pf=3D0x1, revision=3D0xa07
[    2.995882] microcode: CPU1 update to revision 0xa0b failed
[    2.995942] microcode: Microcode Update Driver: v2.00 , Peter Oruba

If I boot the same kernel without the hypervisor the microcode update is=20
successful.

stse@osgiliath:~$ zcat /proc/config.gz |grep MICROCODE
CONFIG_MICROCODE=3Dm
CONFIG_MICROCODE_INTEL=3Dy
# CONFIG_MICROCODE_AMD is not set
CONFIG_MICROCODE_OLD_INTERFACE=3Dy

 From /proc/cpuinfo:
Intel(R) Core(TM)2 Duo CPU     E8500  @ 3.16GHz

Do I need another driver for microcode updates under XEN, or is it=20
impossible for now?

	Stephan

--=20
| Stephan Seitz          E-Mail: stse@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |

--+HP7ph2BbKc20aGI
Content-Type: application/x-pkcs7-signature
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIIOIQYJKoZIhvcNAQcCoIIOEjCCDg4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
C4wwggYIMIID8KADAgECAgEBMA0GCSqGSIb3DQEBBAUAMHkxEDAOBgNVBAoTB1Jvb3QgQ0Ex
HjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWdu
aW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnMB4XDTA1
MTAxNDA3MzY1NVoXDTMzMDMyODA3MzY1NVowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAc
BgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMg
Um9vdDCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAKtJNRFIfNImflOUz0Op3SjX
QiqL84d4GVh8D57aiX3h++tykA10oZZkq5+gJJlz2uJVdscXe/UErEa4w75/ZI0QbCTzYZzA
8pD6Ueb1aQFjww9W4kpCz+JEjCUoqMV5CX1GuYrz6fM0KQhF5Byfy5QEHIGoFLOYZcRD7E6C
jQnRvapbjZLQ7N6QxX8KwuPr5jFaXnQ+lzNZ6MMDPWAzv/fRb0fEze5ig1JuLgiapNkVGJGm
hZJHsK5I6223IeyFGmhyNav/8BBdwPSUp2rVO5J+TJAFfpPBLIukjmJ0FXFuC3ED6q8VOJrU
0gVyb4z5K+taciX5OUbjchs+BMNkJyIQKopPWKcDrb60LhPtXapI19V91Cp7XPpGBFDkzA5C
W4zt2/LP/JaT4NsRNlRiNDiPDGCbO5dWOK3z0luLoFvqTpa4fNfVoIZwQNORKbeiPK31jLvP
GpKK5DR7wNhsX+kKwsOnIJpa3yxdUly6R9Wb7yQocDggL9V/KcCyQQNokszgnMyXS0XvOhAK
q3A6mJVwrTWx6oUrpByAITGprmB6gCZIALgBwJNjVSKRPFbnr9s6JfOPMVTqJouBWfmh0VMR
xXudA/Z0EeBtsSw/LIaRmXGapneLNGDRFLQsrJ2vjBDTn8Rq+G8T/HNZ92ZCdB6K4/jc0m+Y
nMtHmJVABfvpAgMBAAGjgb8wgbwwDwYDVR0TAQH/BAUwAwEB/zBdBggrBgEFBQcBAQRRME8w
IwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLkNBY2VydC5vcmcvMCgGCCsGAQUFBzAChhxodHRw
Oi8vd3d3LkNBY2VydC5vcmcvY2EuY3J0MEoGA1UdIARDMEEwPwYIKwYBBAGBkEowMzAxBggr
BgEFBQcCARYlaHR0cDovL3d3dy5DQWNlcnQub3JnL2luZGV4LnBocD9pZD0xMDANBgkqhkiG
9w0BAQQFAAOCAgEAfwiIodoaUEnaifuhCHLzivcexDq0eVsgMLFF3sJd02Vp8cJdVFQ8hV+5
e0KRwpn9G1Gbq0aloRBTnm2IrHNuLDOm8PSe4HXBPohFqeFmQ/5WWtF6QXj3QNpKOvELW6W7
FgbmwueTuYVNl0+xHjhDgO+bDYzvuKdgAIdXfR5EHMsj75s8mZ2vtSkcRXkWlk0nbfEcbMPC
VWSzvBTi86QfHjL8JxUFz90urj6CYXvwIRAY9kTqUzn53NCaIODGu+C7Wk/EmcgHvbW9otsu
Yg1CNEG8/4uK9VEiqogwAOKw1Ly+ZbrVA1d5m+jcyE34UO2RpVIooqz7Nlg+6ZQrkVCHG9Ze
1ozM9w8QDFJO0BZh5eUKbL8Xx3JGV5yY9WxgY3pvXrlOL8i5ubtqhbyYDe35PpeENJSuAK+h
5eeSbk698+LZFItc0usBbKAXpS0Q65x6Sr297s797SJAq3A4iPUKh2rCqwVgyUgF2lPB3kR3
arPzPDztgLymOEopJF/+WTubJXpWYwBkuV2kYn1XNk+tg+8fklOgjndX3eVhET0jAJBMPPqj
YJMEo6819g5qj09KYKeFBWxGoY/0x3bjoVlX93GyxG4UXG1tQWbfG5Ox1ADD7svPPD0hgKlf
Y2X83eBfpPQr8IVxQdRnJfsasZeu1pmCE0HSbqUbmSeA5wupqAAwggV8MIIDZKADAgECAgMA
7qMwDQYJKoZIhvcNAQEFBQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0
dHA6Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDAeFw0x
MjAyMDcwOTQ3NDVaFw0xNDAyMDYwOTQ3NDVaMHoxFjAUBgNVBAMTDVN0ZXBoYW4gU2VpdHox
JzAlBgkqhkiG9w0BCQEWGHN0c2VAZnNpbmcucm9vdHNsYW5kLm5ldDE3MDUGCSqGSIb3DQEJ
ARYoYjAyOTM1ZjY0MzY2ZWJjNTMyNzRkZWFlNzdjNTlmNWQ0NjFkMzA5MjCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBANmTAhUdu+xjRo+1NWftASWgV7mYi1Gdfdukbr0OcsYL
nxveMvFuTnwzF9IvX18nGes2PKBDtZDwO/CmzBwFw9HHi9ewy1iSJSRZ1PoklFdUts4PsqHh
SF3X9m+NOYtXTHmnzzVphwjtQW4pkzo5r2eF7SWg8sUZeIw5ZTpUa1dJZ2StXhX/4IQJS+vy
4lPBwrthxABsOYeNDVo65k+r4hwuo4LujnbEXetRfgx1nsWsfklZkPmSwKrLLiGKKl7CnLLX
z2ayURu2Z5J9GM/6DJw+BCTwgHKpPc/ERLrRHUw7W7cETaaKqpgMVE4se1v/jJo2C4oKa2qS
iJXQGvxZUzkCAwEAAaOCAS8wggErMAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1Rv
IGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDov
L3d3dy5DQWNlcnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGC
NwoDBAYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcw
AYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzBNBgNVHREERjBEgRhzdHNlQGZzaW5nLnJvb3Rz
bGFuZC5uZXSBKGIwMjkzNWY2NDM2NmViYzUzMjc0ZGVhZTc3YzU5ZjVkNDYxZDMwOTIwDQYJ
KoZIhvcNAQEFBQADggIBABULJCng9rYUzDvpGoGlmz0mxmAO459Son4/lyx8cayyucnqWMgl
/RP3rmKtLg6brRPLrowTyOEpwZ12jR/JSGWv5B8rjWza3hAWHofQ+6HfP0RPTO2vTFyUaLcD
OZ4buknqHAYaS2gp1d2KVBjvrs4QjhS65/0o6tVvA3inAIkQ1h1t9bK8UC0NiA33QIzYhJKF
p3/VTqEOKC/B44mSZ57MJ2uQ0mAUpvbQKpUE74FGIsfgKgTSoZqimsaJjYB3tn4lGzBjYVff
Hi8dmVL1Q0nb93Qae/wXvJaboVW5ztNNFdKrpoQUuNkyssNBoHRA/QPpK2RVkDK+YGza0gEb
832naD4QdZTiiPuzjfV/a8p71TTyHp1eHjvkOU8yKL9DUpLPgX06VRkm+FqjXa7xWis8Jdbl
puXokx5YHifeJjDSci/9apkncZT5tMBNQvSJvjJ+TDMxdrF0rYl8rJMRzg+ckxHeSpw396XU
V8dMgoqFZTasaXqLGDIRqmT381EjBMoZIuxhQochks3Zyq+3QG3wPz98jTQorcF7nS2xMu4O
ovLlQQw6cVAySNX6W6ywVsGbZOZ3+tEIb5WuBgQqe0/eWIt6BhDco8zDzU9dyI2cTrkxxcOp
f1gijBskSDEFwAOjBtDRTzL5vhib+TS3tCQLupcXA29M6pv92YuaDW9zMYICXTCCAlkCAQEw
WzBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQu
b3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290AgMA7qMwCQYFKw4DAhoFAKCB2DAY
BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjEwMTYxNzI3NDBa
MCMGCSqGSIb3DQEJBDEWBBSlF9ot7TAVS4DJFKU5kqlcuUM46DB5BgkqhkiG9w0BCQ8xbDBq
MAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G
CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAN
BgkqhkiG9w0BAQEFAASCAQAfDz4ZzIEc4IjguoHzCArvOoZiuq5vj0fjrWC6uH5Zvg2Bd6ok
jKz8kiIQ6Chmh58/w6jMSQn53F7f0VI4hT4+WEM1IZnJX7Srywo+v6VK2uJUCikns+w4AJfM
bHP2EWLL8iMol1Bl+COBep5JZ1Wo/bXJd+Rj5MVsAkjkMU/Jzf811veQn3SPr/9aurYhzk//
VCx3EhtsGiMSKsCrxEYMjgZQ8XhLxpYNsOV1bojWe4ElA58V+4K6KtZupzanUi4UAKys3vF5
mBqnQTfxqKpYZ1reTMlNNT/Lfs4P135ZTFKwFgmxOoA1rmgpvtHpk3b0om3URNfCRT9rZgfH
axxJ

--+HP7ph2BbKc20aGI--


--===============4296586594468179801==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4296586594468179801==--


From xen-devel-bounces@lists.xen.org Tue Oct 16 17:35:33 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 17:35:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOB2r-000089-N5; Tue, 16 Oct 2012 17:35:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOB2p-000084-So
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 17:35:08 +0000
Received: from [85.158.137.99:30968] by server-1.bemta-3.messagelabs.com id
	C4/CD-31728-BCA9D705; Tue, 16 Oct 2012 17:35:07 +0000
X-Env-Sender: lersek@redhat.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1350408905!17018159!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTgxNzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19290 invoked from network); 16 Oct 2012 17:35:05 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-7.tower-217.messagelabs.com with SMTP;
	16 Oct 2012 17:35:05 -0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q9GHZ05d007069
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 16 Oct 2012 13:35:00 -0400
Received: from lacos-laptop.usersys.redhat.com (vpn1-7-174.ams2.redhat.com
	[10.36.7.174])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q9GHYuji014101; Tue, 16 Oct 2012 13:34:57 -0400
From: Laszlo Ersek 
To: konrad.wilk@oracle.com, jeremy@goop.org, xen-devel@lists.xen.org,
	andrew.cooper3@citrix.com
Date: Tue, 16 Oct 2012 19:36:26 +0200
Message-Id: <1350408986-10891-1-git-send-email-lersek@redhat.com>
In-Reply-To: <507D7240.2010305@citrix.com>
References: <507D7240.2010305@citrix.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Subject: [Xen-devel] [PATCH] xen PV passthru: assign SR-IOV virtual
	functions to separate virtual slots
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

VFs are reported as single-function devices in PCI_HEADER_TYPE, which
causes pci_scan_slot() in the PV domU to skip all VFs beyond #0 in the
pciback-provided slot. Avoid this by assigning each VF to a separate
virtual slot.

Signed-off-by: Laszlo Ersek 
---
 drivers/xen/xen-pciback/vpci.c |   35 ++++++++++++++++++++---------------
 1 files changed, 20 insertions(+), 15 deletions(-)

diff --git a/drivers/xen/xen-pciback/vpci.c b/drivers/xen/xen-pciback/vpci.c
index 46d140b..489404a 100644
--- a/drivers/xen/xen-pciback/vpci.c
+++ b/drivers/xen/xen-pciback/vpci.c
@@ -89,21 +89,26 @@ static int __xen_pcibk_add_pci_dev(struct xen_pcibk_device *pdev,
 
 	mutex_lock(&vpci_dev->lock);
 
-	/* Keep multi-function devices together on the virtual PCI bus */
-	for (slot = 0; slot < PCI_SLOT_MAX; slot++) {
-		if (!list_empty(&vpci_dev->dev_list[slot])) {
-			t = list_entry(list_first(&vpci_dev->dev_list[slot]),
-				       struct pci_dev_entry, list);
-
-			if (match_slot(dev, t->dev)) {
-				pr_info(DRV_NAME ": vpci: %s: "
-					"assign to virtual slot %d func %d\n",
-					pci_name(dev), slot,
-					PCI_FUNC(dev->devfn));
-				list_add_tail(&dev_entry->list,
-					      &vpci_dev->dev_list[slot]);
-				func = PCI_FUNC(dev->devfn);
-				goto unlock;
+	/*
+	 * Keep multi-function devices together on the virtual PCI bus, except
+	 * virtual functions.
+	 */
+	if (!dev->is_virtfn) {
+		for (slot = 0; slot < PCI_SLOT_MAX; slot++) {
+			if (!list_empty(&vpci_dev->dev_list[slot])) {
+				t = list_entry(list_first(&vpci_dev->dev_list[slot]),
+					       struct pci_dev_entry, list);
+
+				if (match_slot(dev, t->dev)) {
+					pr_info(DRV_NAME ": vpci: %s: "
+						"assign to virtual slot %d func %d\n",
+						pci_name(dev), slot,
+						PCI_FUNC(dev->devfn));
+					list_add_tail(&dev_entry->list,
+						      &vpci_dev->dev_list[slot]);
+					func = PCI_FUNC(dev->devfn);
+					goto unlock;
+				}
 			}
 		}
 	}
-- 
1.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 17:35:33 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 17:35:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOB2r-000089-N5; Tue, 16 Oct 2012 17:35:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOB2p-000084-So
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 17:35:08 +0000
Received: from [85.158.137.99:30968] by server-1.bemta-3.messagelabs.com id
	C4/CD-31728-BCA9D705; Tue, 16 Oct 2012 17:35:07 +0000
X-Env-Sender: lersek@redhat.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1350408905!17018159!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTgxNzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19290 invoked from network); 16 Oct 2012 17:35:05 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-7.tower-217.messagelabs.com with SMTP;
	16 Oct 2012 17:35:05 -0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q9GHZ05d007069
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 16 Oct 2012 13:35:00 -0400
Received: from lacos-laptop.usersys.redhat.com (vpn1-7-174.ams2.redhat.com
	[10.36.7.174])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q9GHYuji014101; Tue, 16 Oct 2012 13:34:57 -0400
From: Laszlo Ersek 
To: konrad.wilk@oracle.com, jeremy@goop.org, xen-devel@lists.xen.org,
	andrew.cooper3@citrix.com
Date: Tue, 16 Oct 2012 19:36:26 +0200
Message-Id: <1350408986-10891-1-git-send-email-lersek@redhat.com>
In-Reply-To: <507D7240.2010305@citrix.com>
References: <507D7240.2010305@citrix.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Subject: [Xen-devel] [PATCH] xen PV passthru: assign SR-IOV virtual
	functions to separate virtual slots
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

VFs are reported as single-function devices in PCI_HEADER_TYPE, which
causes pci_scan_slot() in the PV domU to skip all VFs beyond #0 in the
pciback-provided slot. Avoid this by assigning each VF to a separate
virtual slot.

Signed-off-by: Laszlo Ersek 
---
 drivers/xen/xen-pciback/vpci.c |   35 ++++++++++++++++++++---------------
 1 files changed, 20 insertions(+), 15 deletions(-)

diff --git a/drivers/xen/xen-pciback/vpci.c b/drivers/xen/xen-pciback/vpci.c
index 46d140b..489404a 100644
--- a/drivers/xen/xen-pciback/vpci.c
+++ b/drivers/xen/xen-pciback/vpci.c
@@ -89,21 +89,26 @@ static int __xen_pcibk_add_pci_dev(struct xen_pcibk_device *pdev,
 
 	mutex_lock(&vpci_dev->lock);
 
-	/* Keep multi-function devices together on the virtual PCI bus */
-	for (slot = 0; slot < PCI_SLOT_MAX; slot++) {
-		if (!list_empty(&vpci_dev->dev_list[slot])) {
-			t = list_entry(list_first(&vpci_dev->dev_list[slot]),
-				       struct pci_dev_entry, list);
-
-			if (match_slot(dev, t->dev)) {
-				pr_info(DRV_NAME ": vpci: %s: "
-					"assign to virtual slot %d func %d\n",
-					pci_name(dev), slot,
-					PCI_FUNC(dev->devfn));
-				list_add_tail(&dev_entry->list,
-					      &vpci_dev->dev_list[slot]);
-				func = PCI_FUNC(dev->devfn);
-				goto unlock;
+	/*
+	 * Keep multi-function devices together on the virtual PCI bus, except
+	 * virtual functions.
+	 */
+	if (!dev->is_virtfn) {
+		for (slot = 0; slot < PCI_SLOT_MAX; slot++) {
+			if (!list_empty(&vpci_dev->dev_list[slot])) {
+				t = list_entry(list_first(&vpci_dev->dev_list[slot]),
+					       struct pci_dev_entry, list);
+
+				if (match_slot(dev, t->dev)) {
+					pr_info(DRV_NAME ": vpci: %s: "
+						"assign to virtual slot %d func %d\n",
+						pci_name(dev), slot,
+						PCI_FUNC(dev->devfn));
+					list_add_tail(&dev_entry->list,
+						      &vpci_dev->dev_list[slot]);
+					func = PCI_FUNC(dev->devfn);
+					goto unlock;
+				}
 			}
 		}
 	}
-- 
1.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 17:39:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 17:39:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOB6t-0000HK-Kr; Tue, 16 Oct 2012 17:39:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOB6s-0000HB-2j
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 17:39:18 +0000
Received: from [85.158.139.83:61922] by server-1.bemta-5.messagelabs.com id
	CC/23-21640-5CB9D705; Tue, 16 Oct 2012 17:39:17 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1350409156!27807612!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26605 invoked from network); 16 Oct 2012 17:39:16 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 17:39:16 -0000
Received: by mail-we0-f173.google.com with SMTP id t11so4726485wey.32
	for ; Tue, 16 Oct 2012 10:39:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=HLOXOskpOkN9RgBx6VXNB52/eL52YEJGCGHGSnSf5mQ=;
	b=PcmCzOq5TVwXII49cF8nmMAeDqFyY3NQiZ/637ESiZkKPvLeuxK0QZ+j+yitRi5dTX
	Nq11Lw2kbVJb1ris4+bzbCCCFzMJqlJl7/t3RbLzxW2GvpKTnKkb3Kzw3emewqr9czE+
	kI8uFTRpFBUSXUMyTsGhbchVTWox56nULiHn499rbKA6plNy1YZup4Om5uEBotKydCtA
	bgvapTiBqWj4WnsBka2u3l+VDzx+NnuwMIaBH9AA2iZ9bRvlXODhbsBfN3gWoJ+gKREs
	K18KjtVxwHLmtfVnErIYmK/UOFCBGPRG87wwJiAeJNfbvFTAs/Ai7Y0fhne0MP4kbdgw
	aaMQ==
Received: by 10.180.93.33 with SMTP id cr1mr33407932wib.8.1350409156214;
	Tue, 16 Oct 2012 10:39:16 -0700 (PDT)
Received: from [127.0.1.1] (ip-182-14.sn1.eutelia.it. [62.94.182.14])
	by mx.google.com with ESMTPS id f1sm20097740wiy.2.2012.10.16.10.39.14
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 16 Oct 2012 10:39:15 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: fcccd3353cc6f336b7b020cdb922b64f812689ce
Message-Id: 
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.2.2
Date: Tue, 16 Oct 2012 19:26:26 +0200
From: Dario Faggioli 
To: xen-devel@lists.xen.org
Cc: Andre Przywara ,
	Ian Jackson ,
	Ian Campbell 
Subject: [Xen-devel] [PATCH 1 of 3] libxl: take node distances into account
 during NUMA placement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In fact, among placement candidates with the same number of nodes, the
closer the various nodes are to each others, the better the performances
for a domain placed there.

Signed-off-by: Dario Faggioli 

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -105,6 +105,9 @@ out:
  *  - the number of vcpus runnable on the candidates is considered, and
  *    candidates with fewer of them are preferred. If two candidate have
  *    the same number of runnable vcpus,
+ *  - the sum of the node distances in the candidates is considered, and
+ *    candidates with smaller total distance are preferred. If total
+ *    distance is the same for the two candidatess,
  *  - the amount of free memory in the candidates is considered, and the
  *    candidate with greater amount of it is preferred.
  *
@@ -114,6 +117,10 @@ out:
  * overloading large (from a memory POV) nodes. That's right the effect
  * that counting the vcpus able to run on the nodes tries to prevent.
  *
+ * The relative distance within the nodes in the candidates is considered
+ * as the closer the nodes, the better for the domain ending up on the
+ * candidate.
+ *
  * Note that this completely ignore the number of nodes each candidate span,
  * as the fact that fewer nodes is better is already accounted for in the
  * algorithm.
@@ -124,6 +131,9 @@ static int numa_cmpf(const libxl__numa_c
     if (c1->nr_vcpus != c2->nr_vcpus)
         return c1->nr_vcpus - c2->nr_vcpus;
 
+    if (c1->dists_sum != c2->dists_sum)
+        return c1->dists_sum - c2->dists_sum;
+
     return c2->free_memkb - c1->free_memkb;
 }
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -2732,6 +2732,7 @@ static inline void libxl__ctx_unlock(lib
 typedef struct {
     int nr_cpus, nr_nodes;
     int nr_vcpus;
+    int dists_sum;
     uint32_t free_memkb;
     libxl_bitmap nodemap;
 } libxl__numa_candidate;
diff --git a/tools/libxl/libxl_numa.c b/tools/libxl/libxl_numa.c
--- a/tools/libxl/libxl_numa.c
+++ b/tools/libxl/libxl_numa.c
@@ -218,6 +218,40 @@ static int nodemap_to_nr_vcpus(libxl__gc
     return nr_vcpus;
 }
 
+/* Sum the relative distances of nodes in the nodemap to help finding
+ * out which candidate is the "tightest" one. */
+static int nodemap_to_dists_sum(libxl_numainfo *ninfo, libxl_bitmap *nodemap)
+{
+    int tot_dist = 0;
+    int i, j, a = 0, b;
+
+    for (i = 0; i < libxl_bitmap_count_set(nodemap); i++) {
+        while (!libxl_bitmap_test(nodemap, a))
+            a++;
+
+        /* As it is usually non-zero, we do take the latency of
+         * of a node to itself into account. */
+        b = a;
+        for (j = 0; j < libxl_bitmap_count_set(nodemap) - i; j++) {
+            while (!libxl_bitmap_test(nodemap, b))
+                b++;
+
+            /*
+             * In most architectures, going from node A to node B costs
+             * exactly as much as going from B to A does. However, let's
+             * not rely on this and consider both contributions, just to
+             * be ready for everything future might reserve for us.
+             */
+            tot_dist += ninfo[a].dists[b];
+            tot_dist += ninfo[b].dists[a];
+            b++;
+        }
+        a++;
+    }
+
+    return tot_dist;
+}
+
 /*
  * This function tries to figure out if the host has a consistent number
  * of cpus along all its NUMA nodes. In fact, if that is the case, we can
@@ -415,6 +449,7 @@ int libxl__get_numa_candidate(libxl__gc 
              */
             libxl__numa_candidate_put_nodemap(gc, &new_cndt, &nodemap);
             new_cndt.nr_vcpus = nodemap_to_nr_vcpus(gc, tinfo, &nodemap);
+            new_cndt.dists_sum = nodemap_to_dists_sum(ninfo, &nodemap);
             new_cndt.free_memkb = nodes_free_memkb;
             new_cndt.nr_nodes = libxl_bitmap_count_set(&nodemap);
             new_cndt.nr_cpus = nodes_cpus;
@@ -430,12 +465,14 @@ int libxl__get_numa_candidate(libxl__gc 
 
                 LOG(DEBUG, "New best NUMA placement candidate found: "
                            "nr_nodes=%d, nr_cpus=%d, nr_vcpus=%d, "
-                           "free_memkb=%"PRIu32"", new_cndt.nr_nodes,
-                           new_cndt.nr_cpus, new_cndt.nr_vcpus,
+                           "dists_sum=%d, free_memkb=%"PRIu32"",
+                           new_cndt.nr_nodes, new_cndt.nr_cpus,
+                           new_cndt.nr_vcpus, new_cndt.dists_sum,
                            new_cndt.free_memkb / 1024);
 
                 libxl__numa_candidate_put_nodemap(gc, cndt_out, &nodemap);
                 cndt_out->nr_vcpus = new_cndt.nr_vcpus;
+                cndt_out->dists_sum = new_cndt.dists_sum;
                 cndt_out->free_memkb = new_cndt.free_memkb;
                 cndt_out->nr_nodes = new_cndt.nr_nodes;
                 cndt_out->nr_cpus = new_cndt.nr_cpus;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 17:39:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 17:39:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOB6t-0000HK-Kr; Tue, 16 Oct 2012 17:39:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOB6s-0000HB-2j
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 17:39:18 +0000
Received: from [85.158.139.83:61922] by server-1.bemta-5.messagelabs.com id
	CC/23-21640-5CB9D705; Tue, 16 Oct 2012 17:39:17 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1350409156!27807612!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26605 invoked from network); 16 Oct 2012 17:39:16 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 17:39:16 -0000
Received: by mail-we0-f173.google.com with SMTP id t11so4726485wey.32
	for ; Tue, 16 Oct 2012 10:39:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=HLOXOskpOkN9RgBx6VXNB52/eL52YEJGCGHGSnSf5mQ=;
	b=PcmCzOq5TVwXII49cF8nmMAeDqFyY3NQiZ/637ESiZkKPvLeuxK0QZ+j+yitRi5dTX
	Nq11Lw2kbVJb1ris4+bzbCCCFzMJqlJl7/t3RbLzxW2GvpKTnKkb3Kzw3emewqr9czE+
	kI8uFTRpFBUSXUMyTsGhbchVTWox56nULiHn499rbKA6plNy1YZup4Om5uEBotKydCtA
	bgvapTiBqWj4WnsBka2u3l+VDzx+NnuwMIaBH9AA2iZ9bRvlXODhbsBfN3gWoJ+gKREs
	K18KjtVxwHLmtfVnErIYmK/UOFCBGPRG87wwJiAeJNfbvFTAs/Ai7Y0fhne0MP4kbdgw
	aaMQ==
Received: by 10.180.93.33 with SMTP id cr1mr33407932wib.8.1350409156214;
	Tue, 16 Oct 2012 10:39:16 -0700 (PDT)
Received: from [127.0.1.1] (ip-182-14.sn1.eutelia.it. [62.94.182.14])
	by mx.google.com with ESMTPS id f1sm20097740wiy.2.2012.10.16.10.39.14
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 16 Oct 2012 10:39:15 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: fcccd3353cc6f336b7b020cdb922b64f812689ce
Message-Id: 
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.2.2
Date: Tue, 16 Oct 2012 19:26:26 +0200
From: Dario Faggioli 
To: xen-devel@lists.xen.org
Cc: Andre Przywara ,
	Ian Jackson ,
	Ian Campbell 
Subject: [Xen-devel] [PATCH 1 of 3] libxl: take node distances into account
 during NUMA placement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In fact, among placement candidates with the same number of nodes, the
closer the various nodes are to each others, the better the performances
for a domain placed there.

Signed-off-by: Dario Faggioli 

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -105,6 +105,9 @@ out:
  *  - the number of vcpus runnable on the candidates is considered, and
  *    candidates with fewer of them are preferred. If two candidate have
  *    the same number of runnable vcpus,
+ *  - the sum of the node distances in the candidates is considered, and
+ *    candidates with smaller total distance are preferred. If total
+ *    distance is the same for the two candidatess,
  *  - the amount of free memory in the candidates is considered, and the
  *    candidate with greater amount of it is preferred.
  *
@@ -114,6 +117,10 @@ out:
  * overloading large (from a memory POV) nodes. That's right the effect
  * that counting the vcpus able to run on the nodes tries to prevent.
  *
+ * The relative distance within the nodes in the candidates is considered
+ * as the closer the nodes, the better for the domain ending up on the
+ * candidate.
+ *
  * Note that this completely ignore the number of nodes each candidate span,
  * as the fact that fewer nodes is better is already accounted for in the
  * algorithm.
@@ -124,6 +131,9 @@ static int numa_cmpf(const libxl__numa_c
     if (c1->nr_vcpus != c2->nr_vcpus)
         return c1->nr_vcpus - c2->nr_vcpus;
 
+    if (c1->dists_sum != c2->dists_sum)
+        return c1->dists_sum - c2->dists_sum;
+
     return c2->free_memkb - c1->free_memkb;
 }
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -2732,6 +2732,7 @@ static inline void libxl__ctx_unlock(lib
 typedef struct {
     int nr_cpus, nr_nodes;
     int nr_vcpus;
+    int dists_sum;
     uint32_t free_memkb;
     libxl_bitmap nodemap;
 } libxl__numa_candidate;
diff --git a/tools/libxl/libxl_numa.c b/tools/libxl/libxl_numa.c
--- a/tools/libxl/libxl_numa.c
+++ b/tools/libxl/libxl_numa.c
@@ -218,6 +218,40 @@ static int nodemap_to_nr_vcpus(libxl__gc
     return nr_vcpus;
 }
 
+/* Sum the relative distances of nodes in the nodemap to help finding
+ * out which candidate is the "tightest" one. */
+static int nodemap_to_dists_sum(libxl_numainfo *ninfo, libxl_bitmap *nodemap)
+{
+    int tot_dist = 0;
+    int i, j, a = 0, b;
+
+    for (i = 0; i < libxl_bitmap_count_set(nodemap); i++) {
+        while (!libxl_bitmap_test(nodemap, a))
+            a++;
+
+        /* As it is usually non-zero, we do take the latency of
+         * of a node to itself into account. */
+        b = a;
+        for (j = 0; j < libxl_bitmap_count_set(nodemap) - i; j++) {
+            while (!libxl_bitmap_test(nodemap, b))
+                b++;
+
+            /*
+             * In most architectures, going from node A to node B costs
+             * exactly as much as going from B to A does. However, let's
+             * not rely on this and consider both contributions, just to
+             * be ready for everything future might reserve for us.
+             */
+            tot_dist += ninfo[a].dists[b];
+            tot_dist += ninfo[b].dists[a];
+            b++;
+        }
+        a++;
+    }
+
+    return tot_dist;
+}
+
 /*
  * This function tries to figure out if the host has a consistent number
  * of cpus along all its NUMA nodes. In fact, if that is the case, we can
@@ -415,6 +449,7 @@ int libxl__get_numa_candidate(libxl__gc 
              */
             libxl__numa_candidate_put_nodemap(gc, &new_cndt, &nodemap);
             new_cndt.nr_vcpus = nodemap_to_nr_vcpus(gc, tinfo, &nodemap);
+            new_cndt.dists_sum = nodemap_to_dists_sum(ninfo, &nodemap);
             new_cndt.free_memkb = nodes_free_memkb;
             new_cndt.nr_nodes = libxl_bitmap_count_set(&nodemap);
             new_cndt.nr_cpus = nodes_cpus;
@@ -430,12 +465,14 @@ int libxl__get_numa_candidate(libxl__gc 
 
                 LOG(DEBUG, "New best NUMA placement candidate found: "
                            "nr_nodes=%d, nr_cpus=%d, nr_vcpus=%d, "
-                           "free_memkb=%"PRIu32"", new_cndt.nr_nodes,
-                           new_cndt.nr_cpus, new_cndt.nr_vcpus,
+                           "dists_sum=%d, free_memkb=%"PRIu32"",
+                           new_cndt.nr_nodes, new_cndt.nr_cpus,
+                           new_cndt.nr_vcpus, new_cndt.dists_sum,
                            new_cndt.free_memkb / 1024);
 
                 libxl__numa_candidate_put_nodemap(gc, cndt_out, &nodemap);
                 cndt_out->nr_vcpus = new_cndt.nr_vcpus;
+                cndt_out->dists_sum = new_cndt.dists_sum;
                 cndt_out->free_memkb = new_cndt.free_memkb;
                 cndt_out->nr_nodes = new_cndt.nr_nodes;
                 cndt_out->nr_cpus = new_cndt.nr_cpus;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 17:39:46 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 17:39:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOB6w-0000Ht-6U; Tue, 16 Oct 2012 17:39:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOB6u-0000HT-QZ
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 17:39:21 +0000
Received: from [193.109.254.147:54854] by server-4.bemta-14.messagelabs.com id
	43/AB-04248-7CB9D705; Tue, 16 Oct 2012 17:39:19 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1350409158!10277117!1
X-Originating-IP: [209.85.212.169]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 911 invoked from network); 16 Oct 2012 17:39:18 -0000
Received: from mail-wi0-f169.google.com (HELO mail-wi0-f169.google.com)
	(209.85.212.169)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 17:39:18 -0000
Received: by mail-wi0-f169.google.com with SMTP id hq4so161406wib.2
	for ; Tue, 16 Oct 2012 10:39:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=xc03R5X+z6Bw5f0cBFvLN8MJ/OW3OmwdjxzqS4iTMLk=;
	b=VrbTvN9WZEJA6dzrymrTdLuOODXDHLY2ErCVnYXxSl0WzPgPSWeUipWdbYTpZKZIrl
	TR16L6osc4GkxjJjAza7YzGicjhMcPnYSePjuBHFiKu4dxsDd/KqWiiNDfMGxeAp4nMJ
	6jBby0NmGiy4l6+RAhi0MYF78vlPMhPgEGGnYh3MrX1QuhfYa3CyaFv9qG4BFGMyRUMs
	M8qHgnH/ilT2eqx33nJw8S1jSY7idUU1cAdcZmtrbR6rZwWyBsycqFvh4x3m+XsLRxF2
	XBuY5sm4/cnlAzvWFmQH+Qw8S4ySeoxTR1GUcIZRuxMJnshxE0rX26/zyj+P++AWAL9I
	vmtg==
Received: by 10.216.201.28 with SMTP id a28mr10181509weo.74.1350409157991;
	Tue, 16 Oct 2012 10:39:17 -0700 (PDT)
Received: from [127.0.1.1] (ip-182-14.sn1.eutelia.it. [62.94.182.14])
	by mx.google.com with ESMTPS id f1sm20097740wiy.2.2012.10.16.10.39.16
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 16 Oct 2012 10:39:17 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 55f27c485238772388bb4058b1ab2d4378a7800d
Message-Id: <55f27c485238772388bb.1350408387@Solace>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.2.2
Date: Tue, 16 Oct 2012 19:26:27 +0200
From: Dario Faggioli 
To: xen-devel@lists.xen.org
Cc: Andre Przywara ,
	Ian Jackson ,
	Ian Campbell 
Subject: [Xen-devel] [PATCH 2 of 3] libxl,
 xl: user can ask for min and max nodes to use during placement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

And the placement algorithm will stick to that, or fail. This happens
adding support for "minnodes=" and "maxnodes=" in the domain config
file parser.

Signed-off-by: Dario Faggioli 

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -133,6 +133,18 @@ the same time, achieving efficient utili
 
 =back
 
+=item B
+
+Tells libxl to place the new domain on at least `N` nodes. This is only
+effective if automatic NUMA placement occurs (i.e., if no `cpus=` option
+is specified).
+
+=item B
+
+Tells libxl to place the new domain on at most `M` nodes. This is only
+effective if automatic NUMA placement occurs (i.e., if no `cpus=` option
+is specified).
+
 =head3 CPU Scheduling
 
 =over 4
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -219,6 +219,11 @@ int libxl__domain_build_info_setdefault(
 
     libxl_defbool_setdefault(&b_info->numa_placement, true);
 
+    if (!b_info->min_nodes)
+        b_info->min_nodes = 0;
+    if (!b_info->max_nodes)
+        b_info->max_nodes = 0;
+
     if (b_info->max_memkb == LIBXL_MEMKB_DEFAULT)
         b_info->max_memkb = 32 * 1024;
     if (b_info->target_memkb == LIBXL_MEMKB_DEFAULT)
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -174,7 +174,8 @@ static int numa_place_domain(libxl__gc *
     /* Find the best candidate with enough free memory and at least
      * as much pcpus as the domain has vcpus.  */
     rc = libxl__get_numa_candidate(gc, memkb, info->max_vcpus,
-                                   0, 0, &cpupool_info.cpumap,
+                                   info->min_nodes, info->max_nodes,
+                                   &cpupool_info.cpumap,
                                    numa_cmpf, &candidate, &found);
     if (rc)
         goto out;
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -262,6 +262,8 @@ libxl_domain_build_info = Struct("domain
     ("avail_vcpus",     libxl_bitmap),
     ("cpumap",          libxl_bitmap),
     ("numa_placement",  libxl_defbool),
+    ("min_nodes",       integer),
+    ("max_nodes",       integer),
     ("tsc_mode",        libxl_tsc_mode),
     ("max_memkb",       MemKB),
     ("target_memkb",    MemKB),
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -731,6 +731,11 @@ static void parse_config_data(const char
         libxl_defbool_set(&b_info->numa_placement, false);
     }
 
+    if (!xlu_cfg_get_long (config, "minnodes", &l, 0))
+        b_info->min_nodes = l;
+    if (!xlu_cfg_get_long (config, "maxnodes", &l, 0))
+        b_info->max_nodes = l;
+
     if (!xlu_cfg_get_long (config, "memory", &l, 0)) {
         b_info->max_memkb = l * 1024;
         b_info->target_memkb = b_info->max_memkb;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 17:39:46 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 17:39:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOB6w-0000Ht-6U; Tue, 16 Oct 2012 17:39:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOB6u-0000HT-QZ
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 17:39:21 +0000
Received: from [193.109.254.147:54854] by server-4.bemta-14.messagelabs.com id
	43/AB-04248-7CB9D705; Tue, 16 Oct 2012 17:39:19 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1350409158!10277117!1
X-Originating-IP: [209.85.212.169]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 911 invoked from network); 16 Oct 2012 17:39:18 -0000
Received: from mail-wi0-f169.google.com (HELO mail-wi0-f169.google.com)
	(209.85.212.169)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 17:39:18 -0000
Received: by mail-wi0-f169.google.com with SMTP id hq4so161406wib.2
	for ; Tue, 16 Oct 2012 10:39:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=xc03R5X+z6Bw5f0cBFvLN8MJ/OW3OmwdjxzqS4iTMLk=;
	b=VrbTvN9WZEJA6dzrymrTdLuOODXDHLY2ErCVnYXxSl0WzPgPSWeUipWdbYTpZKZIrl
	TR16L6osc4GkxjJjAza7YzGicjhMcPnYSePjuBHFiKu4dxsDd/KqWiiNDfMGxeAp4nMJ
	6jBby0NmGiy4l6+RAhi0MYF78vlPMhPgEGGnYh3MrX1QuhfYa3CyaFv9qG4BFGMyRUMs
	M8qHgnH/ilT2eqx33nJw8S1jSY7idUU1cAdcZmtrbR6rZwWyBsycqFvh4x3m+XsLRxF2
	XBuY5sm4/cnlAzvWFmQH+Qw8S4ySeoxTR1GUcIZRuxMJnshxE0rX26/zyj+P++AWAL9I
	vmtg==
Received: by 10.216.201.28 with SMTP id a28mr10181509weo.74.1350409157991;
	Tue, 16 Oct 2012 10:39:17 -0700 (PDT)
Received: from [127.0.1.1] (ip-182-14.sn1.eutelia.it. [62.94.182.14])
	by mx.google.com with ESMTPS id f1sm20097740wiy.2.2012.10.16.10.39.16
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 16 Oct 2012 10:39:17 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 55f27c485238772388bb4058b1ab2d4378a7800d
Message-Id: <55f27c485238772388bb.1350408387@Solace>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.2.2
Date: Tue, 16 Oct 2012 19:26:27 +0200
From: Dario Faggioli 
To: xen-devel@lists.xen.org
Cc: Andre Przywara ,
	Ian Jackson ,
	Ian Campbell 
Subject: [Xen-devel] [PATCH 2 of 3] libxl,
 xl: user can ask for min and max nodes to use during placement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

And the placement algorithm will stick to that, or fail. This happens
adding support for "minnodes=" and "maxnodes=" in the domain config
file parser.

Signed-off-by: Dario Faggioli 

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -133,6 +133,18 @@ the same time, achieving efficient utili
 
 =back
 
+=item B
+
+Tells libxl to place the new domain on at least `N` nodes. This is only
+effective if automatic NUMA placement occurs (i.e., if no `cpus=` option
+is specified).
+
+=item B
+
+Tells libxl to place the new domain on at most `M` nodes. This is only
+effective if automatic NUMA placement occurs (i.e., if no `cpus=` option
+is specified).
+
 =head3 CPU Scheduling
 
 =over 4
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -219,6 +219,11 @@ int libxl__domain_build_info_setdefault(
 
     libxl_defbool_setdefault(&b_info->numa_placement, true);
 
+    if (!b_info->min_nodes)
+        b_info->min_nodes = 0;
+    if (!b_info->max_nodes)
+        b_info->max_nodes = 0;
+
     if (b_info->max_memkb == LIBXL_MEMKB_DEFAULT)
         b_info->max_memkb = 32 * 1024;
     if (b_info->target_memkb == LIBXL_MEMKB_DEFAULT)
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -174,7 +174,8 @@ static int numa_place_domain(libxl__gc *
     /* Find the best candidate with enough free memory and at least
      * as much pcpus as the domain has vcpus.  */
     rc = libxl__get_numa_candidate(gc, memkb, info->max_vcpus,
-                                   0, 0, &cpupool_info.cpumap,
+                                   info->min_nodes, info->max_nodes,
+                                   &cpupool_info.cpumap,
                                    numa_cmpf, &candidate, &found);
     if (rc)
         goto out;
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -262,6 +262,8 @@ libxl_domain_build_info = Struct("domain
     ("avail_vcpus",     libxl_bitmap),
     ("cpumap",          libxl_bitmap),
     ("numa_placement",  libxl_defbool),
+    ("min_nodes",       integer),
+    ("max_nodes",       integer),
     ("tsc_mode",        libxl_tsc_mode),
     ("max_memkb",       MemKB),
     ("target_memkb",    MemKB),
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -731,6 +731,11 @@ static void parse_config_data(const char
         libxl_defbool_set(&b_info->numa_placement, false);
     }
 
+    if (!xlu_cfg_get_long (config, "minnodes", &l, 0))
+        b_info->min_nodes = l;
+    if (!xlu_cfg_get_long (config, "maxnodes", &l, 0))
+        b_info->max_nodes = l;
+
     if (!xlu_cfg_get_long (config, "memory", &l, 0)) {
         b_info->max_memkb = l * 1024;
         b_info->target_memkb = b_info->max_memkb;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 17:39:51 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 17:39:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOB6w-0000I0-Iv; Tue, 16 Oct 2012 17:39:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOB6v-0000HW-K3
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 17:39:21 +0000
Received: from [85.158.139.83:10974] by server-8.bemta-5.messagelabs.com id
	DE/0A-23193-8CB9D705; Tue, 16 Oct 2012 17:39:20 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1350409156!27807612!2
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26727 invoked from network); 16 Oct 2012 17:39:20 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 17:39:20 -0000
Received: by mail-we0-f173.google.com with SMTP id t11so4726485wey.32
	for ; Tue, 16 Oct 2012 10:39:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=GS/5pCo2LS2kUy0piETuWf6rQn6Rq6nBfZIoE7T0jk4=;
	b=i27rhsnwLlcIsc/gm4TTHqpAuYdN3gTa6Z1DAp9c0plnZMAsOMc8buVZxY8tz4xXx2
	Y5PgL7lfy0a2q5QA9rclzdP6qF7FarD0uFRTsZvldrxFUV3opERDu2OheKkTi8vIdz7u
	//JW4VRf0JibhyzD3q12b5gSO4wGNb3Qe2oAIHJWHVO8dkuEWaV9nqbKCvae+yrrbtmD
	RPcwznbh1ScYRlVIqvksSTKcTwbhF0fmmVu78+ATWiZzbG8nU5zzbv/H39DL8APl4Eby
	Ne8YoV9dGMgmfjMsnRHnifj7hwIPggp4YGeMrILBQoXjEQIPhJR/h5I3HOd6cAoebxFY
	0QQw==
Received: by 10.216.132.215 with SMTP id o65mr10135863wei.100.1350409159903;
	Tue, 16 Oct 2012 10:39:19 -0700 (PDT)
Received: from [127.0.1.1] (ip-182-14.sn1.eutelia.it. [62.94.182.14])
	by mx.google.com with ESMTPS id f1sm20097740wiy.2.2012.10.16.10.39.18
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 16 Oct 2012 10:39:19 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 6d7a403305dd057f61bd4686e152aaafb9760c07
Message-Id: <6d7a403305dd057f61bd.1350408388@Solace>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.2.2
Date: Tue, 16 Oct 2012 19:26:28 +0200
From: Dario Faggioli 
To: xen-devel@lists.xen.org
Cc: Andre Przywara ,
	Ian Jackson ,
	Ian Campbell 
Subject: [Xen-devel] [PATCH 3 of 3] xl: allow for node-wise specification of
	vcpu pinning
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Making it possible to use something like the following:
 * "nodes:0-3": all pCPUs of nodes 0,1,2,3;
 * "nodes:0-3,^node:2": all pCPUS of nodes 0,1,3;
 * "1,nodes:1-2,^6": pCPU 1 plus all pCPUs of nodes 1,2 but not pCPU 6;
 * ...

In both domain config file and `xl vcpu-pin'.

Signed-off-by: Dario Faggioli 

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -109,7 +109,7 @@ some cpus on its own (see below). A C cpuidb) {
+            idb = strtoul(tokb, &endptr, 10);
+            if (endptr == tokb || ida > idb) {
                 fprintf(stderr, "Error: Invalid argument.\n");
                 rc = EINVAL;
                 goto vcpp_out;
             }
         }
-        while (cpuida <= cpuidb) {
-            rmcpu == 0 ? libxl_bitmap_set(cpumap, cpuida) :
-                         libxl_bitmap_set(&exclude_cpumap, cpuida);
-            cpuida++;
-        }
-    }
-
-    /* Clear all the cpus from the removal list */
+        while (ida <= idb) {
+            if (!isnode)
+                isnot == 0 ? libxl_bitmap_set(cpumap, ida) :
+                             libxl_bitmap_set(&exclude_cpumap, ida);
+            else
+                isnot == 0 ? libxl_bitmap_set(&nodemap, ida) :
+                             libxl_bitmap_set(&exclude_nodemap, ida);
+            ida++;
+        }
+    }
+
+    /* Add the cpus that have been specified via "node:" items */
+    rc = libxl_nodemap_to_cpumap(ctx, &nodemap, &cpu_nodemap);
+    if (rc)
+        goto vcpp_out;
+    libxl_for_each_set_bit(i, cpu_nodemap) {
+        libxl_bitmap_set(cpumap, i);
+    }
+
+    /* Clear all the cpus from the removal cpu and node lists */
     libxl_for_each_set_bit(i, exclude_cpumap) {
         libxl_bitmap_reset(cpumap, i);
     }
+    rc = libxl_nodemap_to_cpumap(ctx, &exclude_nodemap, &cpu_nodemap);
+    if (rc)
+        goto vcpp_out;
+    libxl_for_each_set_bit(i, cpu_nodemap) {
+        libxl_bitmap_reset(cpumap, i);
+    }
 
 vcpp_out:
     libxl_bitmap_dispose(&exclude_cpumap);
+    libxl_bitmap_dispose(&exclude_nodemap);
+    libxl_bitmap_dispose(&nodemap);
+    libxl_bitmap_dispose(&cpu_nodemap);
 
     return rc;
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 17:39:51 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 17:39:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOB6w-0000I0-Iv; Tue, 16 Oct 2012 17:39:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOB6v-0000HW-K3
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 17:39:21 +0000
Received: from [85.158.139.83:10974] by server-8.bemta-5.messagelabs.com id
	DE/0A-23193-8CB9D705; Tue, 16 Oct 2012 17:39:20 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1350409156!27807612!2
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26727 invoked from network); 16 Oct 2012 17:39:20 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 17:39:20 -0000
Received: by mail-we0-f173.google.com with SMTP id t11so4726485wey.32
	for ; Tue, 16 Oct 2012 10:39:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=GS/5pCo2LS2kUy0piETuWf6rQn6Rq6nBfZIoE7T0jk4=;
	b=i27rhsnwLlcIsc/gm4TTHqpAuYdN3gTa6Z1DAp9c0plnZMAsOMc8buVZxY8tz4xXx2
	Y5PgL7lfy0a2q5QA9rclzdP6qF7FarD0uFRTsZvldrxFUV3opERDu2OheKkTi8vIdz7u
	//JW4VRf0JibhyzD3q12b5gSO4wGNb3Qe2oAIHJWHVO8dkuEWaV9nqbKCvae+yrrbtmD
	RPcwznbh1ScYRlVIqvksSTKcTwbhF0fmmVu78+ATWiZzbG8nU5zzbv/H39DL8APl4Eby
	Ne8YoV9dGMgmfjMsnRHnifj7hwIPggp4YGeMrILBQoXjEQIPhJR/h5I3HOd6cAoebxFY
	0QQw==
Received: by 10.216.132.215 with SMTP id o65mr10135863wei.100.1350409159903;
	Tue, 16 Oct 2012 10:39:19 -0700 (PDT)
Received: from [127.0.1.1] (ip-182-14.sn1.eutelia.it. [62.94.182.14])
	by mx.google.com with ESMTPS id f1sm20097740wiy.2.2012.10.16.10.39.18
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 16 Oct 2012 10:39:19 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 6d7a403305dd057f61bd4686e152aaafb9760c07
Message-Id: <6d7a403305dd057f61bd.1350408388@Solace>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.2.2
Date: Tue, 16 Oct 2012 19:26:28 +0200
From: Dario Faggioli 
To: xen-devel@lists.xen.org
Cc: Andre Przywara ,
	Ian Jackson ,
	Ian Campbell 
Subject: [Xen-devel] [PATCH 3 of 3] xl: allow for node-wise specification of
	vcpu pinning
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Making it possible to use something like the following:
 * "nodes:0-3": all pCPUs of nodes 0,1,2,3;
 * "nodes:0-3,^node:2": all pCPUS of nodes 0,1,3;
 * "1,nodes:1-2,^6": pCPU 1 plus all pCPUs of nodes 1,2 but not pCPU 6;
 * ...

In both domain config file and `xl vcpu-pin'.

Signed-off-by: Dario Faggioli 

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -109,7 +109,7 @@ some cpus on its own (see below). A C cpuidb) {
+            idb = strtoul(tokb, &endptr, 10);
+            if (endptr == tokb || ida > idb) {
                 fprintf(stderr, "Error: Invalid argument.\n");
                 rc = EINVAL;
                 goto vcpp_out;
             }
         }
-        while (cpuida <= cpuidb) {
-            rmcpu == 0 ? libxl_bitmap_set(cpumap, cpuida) :
-                         libxl_bitmap_set(&exclude_cpumap, cpuida);
-            cpuida++;
-        }
-    }
-
-    /* Clear all the cpus from the removal list */
+        while (ida <= idb) {
+            if (!isnode)
+                isnot == 0 ? libxl_bitmap_set(cpumap, ida) :
+                             libxl_bitmap_set(&exclude_cpumap, ida);
+            else
+                isnot == 0 ? libxl_bitmap_set(&nodemap, ida) :
+                             libxl_bitmap_set(&exclude_nodemap, ida);
+            ida++;
+        }
+    }
+
+    /* Add the cpus that have been specified via "node:" items */
+    rc = libxl_nodemap_to_cpumap(ctx, &nodemap, &cpu_nodemap);
+    if (rc)
+        goto vcpp_out;
+    libxl_for_each_set_bit(i, cpu_nodemap) {
+        libxl_bitmap_set(cpumap, i);
+    }
+
+    /* Clear all the cpus from the removal cpu and node lists */
     libxl_for_each_set_bit(i, exclude_cpumap) {
         libxl_bitmap_reset(cpumap, i);
     }
+    rc = libxl_nodemap_to_cpumap(ctx, &exclude_nodemap, &cpu_nodemap);
+    if (rc)
+        goto vcpp_out;
+    libxl_for_each_set_bit(i, cpu_nodemap) {
+        libxl_bitmap_reset(cpumap, i);
+    }
 
 vcpp_out:
     libxl_bitmap_dispose(&exclude_cpumap);
+    libxl_bitmap_dispose(&exclude_nodemap);
+    libxl_bitmap_dispose(&nodemap);
+    libxl_bitmap_dispose(&cpu_nodemap);
 
     return rc;
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 17:39:53 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 17:39:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOB7B-0000KE-13; Tue, 16 Oct 2012 17:39:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOB79-0000Ju-Mm
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 17:39:35 +0000
Received: from [193.109.254.147:55399] by server-10.bemta-14.messagelabs.com
	id 0B/84-12590-7DB9D705; Tue, 16 Oct 2012 17:39:35 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1350409173!3054897!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30483 invoked from network); 16 Oct 2012 17:39:34 -0000
Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com)
	(74.125.82.41)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 17:39:34 -0000
Received: by mail-wg0-f41.google.com with SMTP id ds1so82543wgb.2
	for ; Tue, 16 Oct 2012 10:39:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to:cc;
	bh=nUJJ2vHxey6dZSFCXe4BX+py5eNLILxc9ysAG48K1uA=;
	b=IM15+npPMHbEKg4lN+WxcvD0LCQ3Kq0uqBq3l39aU+p2usSG/9J5Ei6fmLdCquPmLP
	jVIb0uih+7ae1Y1Oe2gmwQI09cvHhHROI6mLDzvmB5ZhOZWK3Nh4NblSI+AZ2OyMDT9k
	f17LOcJhmThhsnMl+S/sCErfIjoxsZx+IOQO2kBX41WOnSkB+GKJpoWbKx1ArzX4wcUu
	Ewsoeo5G/iAu6sGfyVp5jNGQwFsgSc3lstH2q6kKSWA4W8SsWSVSFlbF8tJMBdT5i8Re
	ByDXT8B8u5YtQjgbW1oxWr1gHB2TAjpz1OSvjqndvLqXzRJwSVQrgnULDcN4zLeOXOG1
	qbnw==
Received: by 10.180.79.103 with SMTP id i7mr33408509wix.13.1350409154389;
	Tue, 16 Oct 2012 10:39:14 -0700 (PDT)
Received: from [127.0.1.1] (ip-182-14.sn1.eutelia.it. [62.94.182.14])
	by mx.google.com with ESMTPS id f1sm20097740wiy.2.2012.10.16.10.39.12
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 16 Oct 2012 10:39:13 -0700 (PDT)
MIME-Version: 1.0
Message-Id: 
User-Agent: Mercurial-patchbomb/2.2.2
Date: Tue, 16 Oct 2012 19:26:25 +0200
From: Dario Faggioli 
To: xen-devel@lists.xen.org
Cc: Andre Przywara ,
	Ian Jackson ,
	Ian Campbell 
Subject: [Xen-devel] [PATCH 0 of 3] Some small NUMA placement improvements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi everyone,

This series implements some small impovement in how NUMA is dealt at the libxl
and xl level that I had pending in one of my queues.

More specifically, it enables actually using node distances information during
automatic placement and it allows the users to ask for a minimum and a maximum
number of NUMA nodes they want the automaic placement to use.

A little bit less related to _automatic_ placement, it also enhances the syntax
of the "cpus=" config switch (as well as the one of the `xl vcpu-pin' command),
so that full nodes can be specified instead of just single CPUs.

This is all about, on one hand, keeping improving performances of the NUMA
placement mechanism and, on the other, starting to give users some knobs to
control it.

Comments appreciated, as usual. :-)

Thanks and Regards,
Dario

-- 
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 17:39:53 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 17:39:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOB7B-0000KE-13; Tue, 16 Oct 2012 17:39:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOB79-0000Ju-Mm
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 17:39:35 +0000
Received: from [193.109.254.147:55399] by server-10.bemta-14.messagelabs.com
	id 0B/84-12590-7DB9D705; Tue, 16 Oct 2012 17:39:35 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1350409173!3054897!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30483 invoked from network); 16 Oct 2012 17:39:34 -0000
Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com)
	(74.125.82.41)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 17:39:34 -0000
Received: by mail-wg0-f41.google.com with SMTP id ds1so82543wgb.2
	for ; Tue, 16 Oct 2012 10:39:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to:cc;
	bh=nUJJ2vHxey6dZSFCXe4BX+py5eNLILxc9ysAG48K1uA=;
	b=IM15+npPMHbEKg4lN+WxcvD0LCQ3Kq0uqBq3l39aU+p2usSG/9J5Ei6fmLdCquPmLP
	jVIb0uih+7ae1Y1Oe2gmwQI09cvHhHROI6mLDzvmB5ZhOZWK3Nh4NblSI+AZ2OyMDT9k
	f17LOcJhmThhsnMl+S/sCErfIjoxsZx+IOQO2kBX41WOnSkB+GKJpoWbKx1ArzX4wcUu
	Ewsoeo5G/iAu6sGfyVp5jNGQwFsgSc3lstH2q6kKSWA4W8SsWSVSFlbF8tJMBdT5i8Re
	ByDXT8B8u5YtQjgbW1oxWr1gHB2TAjpz1OSvjqndvLqXzRJwSVQrgnULDcN4zLeOXOG1
	qbnw==
Received: by 10.180.79.103 with SMTP id i7mr33408509wix.13.1350409154389;
	Tue, 16 Oct 2012 10:39:14 -0700 (PDT)
Received: from [127.0.1.1] (ip-182-14.sn1.eutelia.it. [62.94.182.14])
	by mx.google.com with ESMTPS id f1sm20097740wiy.2.2012.10.16.10.39.12
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 16 Oct 2012 10:39:13 -0700 (PDT)
MIME-Version: 1.0
Message-Id: 
User-Agent: Mercurial-patchbomb/2.2.2
Date: Tue, 16 Oct 2012 19:26:25 +0200
From: Dario Faggioli 
To: xen-devel@lists.xen.org
Cc: Andre Przywara ,
	Ian Jackson ,
	Ian Campbell 
Subject: [Xen-devel] [PATCH 0 of 3] Some small NUMA placement improvements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi everyone,

This series implements some small impovement in how NUMA is dealt at the libxl
and xl level that I had pending in one of my queues.

More specifically, it enables actually using node distances information during
automatic placement and it allows the users to ask for a minimum and a maximum
number of NUMA nodes they want the automaic placement to use.

A little bit less related to _automatic_ placement, it also enhances the syntax
of the "cpus=" config switch (as well as the one of the `xl vcpu-pin' command),
so that full nodes can be specified instead of just single CPUs.

This is all about, on one hand, keeping improving performances of the NUMA
placement mechanism and, on the other, starting to give users some knobs to
control it.

Comments appreciated, as usual. :-)

Thanks and Regards,
Dario

-- 
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 17:47:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 17:47:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOBEU-0000uM-1a; Tue, 16 Oct 2012 17:47:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOBES-0000uH-AX
	for Xen-devel@lists.xensource.com; Tue, 16 Oct 2012 17:47:08 +0000
Received: from [85.158.138.51:28867] by server-12.bemta-3.messagelabs.com id
	9D/55-27853-B9D9D705; Tue, 16 Oct 2012 17:47:07 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1350409625!34587095!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODA2NzE3\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22467 invoked from network); 16 Oct 2012 17:47:06 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Oct 2012 17:47:06 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9GHl0Kv003884
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 16 Oct 2012 17:47:01 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9GHkx6O008913
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 16 Oct 2012 17:47:00 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9GHkxmf020486; Tue, 16 Oct 2012 12:46:59 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 16 Oct 2012 10:46:58 -0700
Date: Tue, 16 Oct 2012 10:46:57 -0700
From: Mukesh Rathor 
To: Ian Campbell 
Message-ID: <20121016104657.4b2478a8@mantra.us.oracle.com>
In-Reply-To: <1350404821.2460.3.camel@zakaz.uk.xensource.com>
References: <20121011145817.0d744c99@mantra.us.oracle.com>
	<1350032276.14806.53.camel@zakaz.uk.xensource.com>
	<1350404821.2460.3.camel@zakaz.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" , Konrad
	Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V2 3/7]: PVH:  mmu related changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 16 Oct 2012 17:27:01 +0100
Ian Campbell  wrote:

> On Fri, 2012-10-12 at 09:57 +0100, Ian Campbell wrote:
> > > +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma)
> > > +{
> > > +       int numpgs = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
> > > +       struct page **pages = vma ? vma->vm_private_data : NULL;
> > 
> > I thought we agreed to keep uses of vm_private_data in the privcmd
> > driver?
> > 
> > I think you should just add pages and nr as direct parameters to
> > this function, which is symmetric with the map call.
> 
> I had to look at this while rebasing my arm patches, turned out to be
> fairly simple. Feel free to either fold in or badger me for a proper
> commit message.


I made similar change in my tree, except I am not passing vma as its
not needed. I guess you just wanna be consistend with remap, or future
use?

thanks
mukesh



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 17:47:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 17:47:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOBEU-0000uM-1a; Tue, 16 Oct 2012 17:47:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOBES-0000uH-AX
	for Xen-devel@lists.xensource.com; Tue, 16 Oct 2012 17:47:08 +0000
Received: from [85.158.138.51:28867] by server-12.bemta-3.messagelabs.com id
	9D/55-27853-B9D9D705; Tue, 16 Oct 2012 17:47:07 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1350409625!34587095!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODA2NzE3\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22467 invoked from network); 16 Oct 2012 17:47:06 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Oct 2012 17:47:06 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9GHl0Kv003884
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 16 Oct 2012 17:47:01 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9GHkx6O008913
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 16 Oct 2012 17:47:00 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9GHkxmf020486; Tue, 16 Oct 2012 12:46:59 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 16 Oct 2012 10:46:58 -0700
Date: Tue, 16 Oct 2012 10:46:57 -0700
From: Mukesh Rathor 
To: Ian Campbell 
Message-ID: <20121016104657.4b2478a8@mantra.us.oracle.com>
In-Reply-To: <1350404821.2460.3.camel@zakaz.uk.xensource.com>
References: <20121011145817.0d744c99@mantra.us.oracle.com>
	<1350032276.14806.53.camel@zakaz.uk.xensource.com>
	<1350404821.2460.3.camel@zakaz.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" , Konrad
	Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V2 3/7]: PVH:  mmu related changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 16 Oct 2012 17:27:01 +0100
Ian Campbell  wrote:

> On Fri, 2012-10-12 at 09:57 +0100, Ian Campbell wrote:
> > > +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma)
> > > +{
> > > +       int numpgs = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
> > > +       struct page **pages = vma ? vma->vm_private_data : NULL;
> > 
> > I thought we agreed to keep uses of vm_private_data in the privcmd
> > driver?
> > 
> > I think you should just add pages and nr as direct parameters to
> > this function, which is symmetric with the map call.
> 
> I had to look at this while rebasing my arm patches, turned out to be
> fairly simple. Feel free to either fold in or badger me for a proper
> commit message.


I made similar change in my tree, except I am not passing vma as its
not needed. I guess you just wanna be consistend with remap, or future
use?

thanks
mukesh



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 17:52:53 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 17:52:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOBJk-00012x-Su; Tue, 16 Oct 2012 17:52:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOBJj-00012r-SK
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 17:52:36 +0000
Received: from [85.158.137.99:12212] by server-12.bemta-3.messagelabs.com id
	A2/D9-27853-3EE9D705; Tue, 16 Oct 2012 17:52:35 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1350409944!18698180!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODA2NzE3\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28323 invoked from network); 16 Oct 2012 17:52:25 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-12.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Oct 2012 17:52:25 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9GHq9Dh009514
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 16 Oct 2012 17:52:10 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9GHq8dG010600
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 16 Oct 2012 17:52:08 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9GHq65w027980; Tue, 16 Oct 2012 12:52:07 -0500
MIME-Version: 1.0
Message-ID: 
Date: Tue, 16 Oct 2012 10:51:57 -0700 (PDT)
From: Dan Magenheimer 
To: George Dunlap 
References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default>
	<20581.55931.246130.308384@mariner.uk.xensource.com>
	<8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default>
	<20121002091017.GA95926@ocelot.phlegethon.org>
	<66cc0085-1216-40f7-8059-eaf615202c12@default>
	<20121002201624.GA98445@ocelot.phlegethon.org>
	
	<20121004100645.GC38243@ocelot.phlegethon.org>
	<1349345864.650.247.camel@zakaz.uk.xensource.com>
	<239799F4-AF29-494F-86D2-ADF45ACA8792@gridcentric.ca>
	<3e5cf0ba-4241-4f00-bef6-aaff2cc23419@default>
	<506EC710.3020606@eu.citrix.com>
	<58b5a25d-ccdd-4d0c-a0d9-9c249825f7f1@default>
	
In-Reply-To: 
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Olaf Hering , "Keir \(Xen.org\)" ,
	Ian Campbell ,
	Konrad Wilk ,
	Andres Lagar-Cavilla ,
	"Tim \(Xen.org\)" , xen-devel@lists.xen.org,
	George Shuklin ,
	Dario Faggioli , Kurt Hackel ,
	Ian Jackson 
Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and
	xl)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: George Dunlap [mailto:George.Dunlap@eu.citrix.com]
> Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl)
> 
> On Mon, Oct 8, 2012 at 2:02 AM, Dan Magenheimer
>  wrote:
> > Tmem really is a breakthrough on memory management in a virtualized
> > system.  I realize that many people are in the "if it doesn't
> > work on Windows, I don't care" camp.  And others never thought
> > it would make it into upstream Linux (or don't care because it isn't
> > completely functional in any distros yet... other than Oracle's..
> > but since all parts are now upstream, it will be soon).  But there
> > probably are also many that just don't understand it... I guess I need
> > to work on fixing that.  Any thoughts on how to start?
> 
> Well, I'm sorry to say this, but to start I think you need to work on
> your communication.  I had read this entire thread 2 or 3 times before
> writing my last response; and I have now read this e-mail half a dozen
> times, and I'm still don't have a good idea what it is you're talking
> about.  If I didn't respect you, I would have just given up on the 2nd
> try.
>   :
> If I still haven't understood where you're coming from, then I am
> sorry; but I have tried pretty hard, and I'm not the only one having
> that problem.

Hi George --

Thanks for the honest direct feedback.  I had no idea.  I have
been buried in this memory stuff since April 2008 and it is easy
for me to assume that people understand what I am talking about,
have read everything I've written about it, seen/remember my
presentations etc.  Further, the conversational delays due to timezone
differences and the fact that we all are juggling many different
deliverables makes it difficult to maintain all the context necessary
to drive/converge a complex discussion.

So I am truly sorry and I really appreciate that you've stuck with me.

Let me ponder how to improve, but try to maintain some forward
progress in the interim by continuing this thread.

There are two things being mixed here: (A) The very general concepts
of  how to deal with RAM capacity as a resource and how to best "control"
"sharing" of the resource among virtual machines; and (B) how to solve a
very specific known problem that occurs due to "races" for memory capacity.
Solving (B) requires some assumptions about (A) which is why (A)
keeps coming up.

I'll mark my comments below with (A) and (B) to make it clear
which is being discussed.

> In my summary, I mentioned just 2 things: the problem of domain
> creation, and the solution of a hypercall to allocate a big chunk of
> memory to a domain.  You answered by saying it was a good summary.
> But then you said:
> 
> > I'm just proposing an extension to the
> > existing mechanism and I am quite convinced that the hypervisor must
> > be involved (e.g. a new hypercall) for the extension to work properly.
> 
> Now you're talking about an extension...

This is (B)

Extension == new hypercall.  (It's an extension to the way memory
has previously been allocated by the hypervisor.)

> then you mention a "memory
> scheduler" (which we don't yet have), and say:
> 
> > ...there is inadequate information from
> > any VM to drive automatic memory allocation decisions and, even if
> > there was, it just doesn't scale.
> 
> But you don't say where or who *could* have adequate information;
> which again hints at something else which you have in mind, but you
> haven't actually talked about very explicitly yet.  If you have been
> trying to talk about it, and it wasn't in my summary, why didn't you
> say something about it, instead of saying, "Yes that's right"?  And if
> you haven't talked about it, why are you speaking as though we all
> know already what you're talking about?

(A)

My bad.  The premise of tmem (and IMHO the thorn in the side of
all memory capacity management in virtualized systems) is that *nobody*
has adequate information.  The guest OS has some "demand" information,
though not in any externally-communicable form, and the host/hypervisor
has "supply" information.  Tmem uses a small handful of kernel changes
and some hypercalls to tie these together in a surprisingly useful way.

> Furthermore, you say things like this:
> 
> > IMHO, the example you give for asking a memory controller for GiB
> > of memory is equally silly.  Outside of some geek with a handful
> > of VMs on a single machine, there is inadequate information from
> > any VM to drive automatic memory allocation decisions and, even if
> > there was, it just doesn't scale.  It doesn't scale either up, to
> > many VMs across many physical machines, or down, to instantaneous
> > needs of one-page-at-a-time requests for unsharing or for tmem.
> 
> What do you mean, "doesn't scale up or across"?  Why not?  Why is
> there inadequate information inside dom0 for a toolstack-based memory
> controller?  And if there's not enough information there, who *does*
> have the information?  It's just a bunch of vague assertions with no
> justification and no alternative proposed.  It doesn't bring any light
> to the discussion (which is no doubt why the thread has died without
> conclusion).

(A)

There is inadequate information period.  OS's have forever been
designed to manage a fixed amount of RAM, not to communicate very
well about if and when the OS needs more RAM (and how much) or can
get by with less RAM (and how much).  So any external "memory controller"
is (IMHO) doomed to failure, limited to approximations based on pieces of
guest-OS-externally-visible usually-out-of-date information collected
at a relatively low frequency.  Collecting/analyzing/acting-on the
information across hundreds/thousands of guests is very difficult
(doesn't "scale up"), collecting/analyzing/acting-on the information
across hundreds of machines -- each with hundreds/thousands of
guests has exponential communication and bin-packing problems
(doesn't scale "across") and, if the memory-demand is a high-frequency
stream of single pages (i.e. with page-unsharing), sampling by
the memory controller can't possibly keep up (doesn't "scale down").

This is only slightly better than a bunch of vague assertions, but if
you disagree, let's take it down a level in a separate thread.

My proposed alternative is tmem. which is why it may appear that I
haven't proposed anything... tmem already exists today.

> Nor does saying "see above" and "see below", when "above" and "below"
> are still equally unenlightening.

Oops, sorry. :-}  Just trying to avoid repeating myself.

> Maybe your grand designs for a "memory scheduler", where memory pages
> hop back and forth at millisecond quanta based on instantaneous data,
> between page sharing, paging, tmem, and so on, is a good one.  But
> that's not what we have now.

(A)

Tmem *is* essentially a memory scheduler.  A grand design is implemented,
works, and all the parts are upstream in open source.

> And that's not even what you're trying
> to promote.  Instead, you're trying to push a single hypercall that
> you think will be necessary for such a scheduler.

(B)

Strangely, tmem doesn't really need this hypercall.  It already has
a solution working in xm create called "tmem freeze/thaw".  But this
solution is a half-assed very heavy hammer.

The single "memory reservation" hypercall is intended to help solve a
known problem (IanJ said early in this thread: "This is a real problem")
with any environment where the amount of RAM used by a guest can change
dynamically without the knowledge of a not-in-hypervisor "memory controller",
and the toolstack then wishes to launch a new domain.  The problem can even
occur with multiple toolstack threads simultaneously launching domains.

After further thought, it appeared that the "memory reservation" hypercall
also eliminates the need for the half-assed tmem freeze/thaw as well.

> Doesn't it make sense to *first* talk about your grand vision and come
> up with a reasonable plan for it, *then* propose an implementation?
> If in the course of your 15-patch series introducing a "memory
> scheduler", you also introduce a "reservation" hypercall, then
> everyone can see exactly what it accomplishes, and actually see if
> it's necessary, or if some other design would work better.
> 
> Does that make sense?

If you reread my last response with the assumption in mind:

  "tmem == an instance of a memory scheduler == grand vision"

then does the discussion of the "memory reservation" hypercall
make more sense?

Thanks again for the pointed communication feedback.  Hopefully this
is a bit better and I will continue to ponder more communication
improvements.

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 17:52:53 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 17:52:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOBJk-00012x-Su; Tue, 16 Oct 2012 17:52:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOBJj-00012r-SK
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 17:52:36 +0000
Received: from [85.158.137.99:12212] by server-12.bemta-3.messagelabs.com id
	A2/D9-27853-3EE9D705; Tue, 16 Oct 2012 17:52:35 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1350409944!18698180!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODA2NzE3\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28323 invoked from network); 16 Oct 2012 17:52:25 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-12.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Oct 2012 17:52:25 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9GHq9Dh009514
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 16 Oct 2012 17:52:10 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9GHq8dG010600
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 16 Oct 2012 17:52:08 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9GHq65w027980; Tue, 16 Oct 2012 12:52:07 -0500
MIME-Version: 1.0
Message-ID: 
Date: Tue, 16 Oct 2012 10:51:57 -0700 (PDT)
From: Dan Magenheimer 
To: George Dunlap 
References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default>
	<20581.55931.246130.308384@mariner.uk.xensource.com>
	<8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default>
	<20121002091017.GA95926@ocelot.phlegethon.org>
	<66cc0085-1216-40f7-8059-eaf615202c12@default>
	<20121002201624.GA98445@ocelot.phlegethon.org>
	
	<20121004100645.GC38243@ocelot.phlegethon.org>
	<1349345864.650.247.camel@zakaz.uk.xensource.com>
	<239799F4-AF29-494F-86D2-ADF45ACA8792@gridcentric.ca>
	<3e5cf0ba-4241-4f00-bef6-aaff2cc23419@default>
	<506EC710.3020606@eu.citrix.com>
	<58b5a25d-ccdd-4d0c-a0d9-9c249825f7f1@default>
	
In-Reply-To: 
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Olaf Hering , "Keir \(Xen.org\)" ,
	Ian Campbell ,
	Konrad Wilk ,
	Andres Lagar-Cavilla ,
	"Tim \(Xen.org\)" , xen-devel@lists.xen.org,
	George Shuklin ,
	Dario Faggioli , Kurt Hackel ,
	Ian Jackson 
Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and
	xl)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: George Dunlap [mailto:George.Dunlap@eu.citrix.com]
> Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl)
> 
> On Mon, Oct 8, 2012 at 2:02 AM, Dan Magenheimer
>  wrote:
> > Tmem really is a breakthrough on memory management in a virtualized
> > system.  I realize that many people are in the "if it doesn't
> > work on Windows, I don't care" camp.  And others never thought
> > it would make it into upstream Linux (or don't care because it isn't
> > completely functional in any distros yet... other than Oracle's..
> > but since all parts are now upstream, it will be soon).  But there
> > probably are also many that just don't understand it... I guess I need
> > to work on fixing that.  Any thoughts on how to start?
> 
> Well, I'm sorry to say this, but to start I think you need to work on
> your communication.  I had read this entire thread 2 or 3 times before
> writing my last response; and I have now read this e-mail half a dozen
> times, and I'm still don't have a good idea what it is you're talking
> about.  If I didn't respect you, I would have just given up on the 2nd
> try.
>   :
> If I still haven't understood where you're coming from, then I am
> sorry; but I have tried pretty hard, and I'm not the only one having
> that problem.

Hi George --

Thanks for the honest direct feedback.  I had no idea.  I have
been buried in this memory stuff since April 2008 and it is easy
for me to assume that people understand what I am talking about,
have read everything I've written about it, seen/remember my
presentations etc.  Further, the conversational delays due to timezone
differences and the fact that we all are juggling many different
deliverables makes it difficult to maintain all the context necessary
to drive/converge a complex discussion.

So I am truly sorry and I really appreciate that you've stuck with me.

Let me ponder how to improve, but try to maintain some forward
progress in the interim by continuing this thread.

There are two things being mixed here: (A) The very general concepts
of  how to deal with RAM capacity as a resource and how to best "control"
"sharing" of the resource among virtual machines; and (B) how to solve a
very specific known problem that occurs due to "races" for memory capacity.
Solving (B) requires some assumptions about (A) which is why (A)
keeps coming up.

I'll mark my comments below with (A) and (B) to make it clear
which is being discussed.

> In my summary, I mentioned just 2 things: the problem of domain
> creation, and the solution of a hypercall to allocate a big chunk of
> memory to a domain.  You answered by saying it was a good summary.
> But then you said:
> 
> > I'm just proposing an extension to the
> > existing mechanism and I am quite convinced that the hypervisor must
> > be involved (e.g. a new hypercall) for the extension to work properly.
> 
> Now you're talking about an extension...

This is (B)

Extension == new hypercall.  (It's an extension to the way memory
has previously been allocated by the hypervisor.)

> then you mention a "memory
> scheduler" (which we don't yet have), and say:
> 
> > ...there is inadequate information from
> > any VM to drive automatic memory allocation decisions and, even if
> > there was, it just doesn't scale.
> 
> But you don't say where or who *could* have adequate information;
> which again hints at something else which you have in mind, but you
> haven't actually talked about very explicitly yet.  If you have been
> trying to talk about it, and it wasn't in my summary, why didn't you
> say something about it, instead of saying, "Yes that's right"?  And if
> you haven't talked about it, why are you speaking as though we all
> know already what you're talking about?

(A)

My bad.  The premise of tmem (and IMHO the thorn in the side of
all memory capacity management in virtualized systems) is that *nobody*
has adequate information.  The guest OS has some "demand" information,
though not in any externally-communicable form, and the host/hypervisor
has "supply" information.  Tmem uses a small handful of kernel changes
and some hypercalls to tie these together in a surprisingly useful way.

> Furthermore, you say things like this:
> 
> > IMHO, the example you give for asking a memory controller for GiB
> > of memory is equally silly.  Outside of some geek with a handful
> > of VMs on a single machine, there is inadequate information from
> > any VM to drive automatic memory allocation decisions and, even if
> > there was, it just doesn't scale.  It doesn't scale either up, to
> > many VMs across many physical machines, or down, to instantaneous
> > needs of one-page-at-a-time requests for unsharing or for tmem.
> 
> What do you mean, "doesn't scale up or across"?  Why not?  Why is
> there inadequate information inside dom0 for a toolstack-based memory
> controller?  And if there's not enough information there, who *does*
> have the information?  It's just a bunch of vague assertions with no
> justification and no alternative proposed.  It doesn't bring any light
> to the discussion (which is no doubt why the thread has died without
> conclusion).

(A)

There is inadequate information period.  OS's have forever been
designed to manage a fixed amount of RAM, not to communicate very
well about if and when the OS needs more RAM (and how much) or can
get by with less RAM (and how much).  So any external "memory controller"
is (IMHO) doomed to failure, limited to approximations based on pieces of
guest-OS-externally-visible usually-out-of-date information collected
at a relatively low frequency.  Collecting/analyzing/acting-on the
information across hundreds/thousands of guests is very difficult
(doesn't "scale up"), collecting/analyzing/acting-on the information
across hundreds of machines -- each with hundreds/thousands of
guests has exponential communication and bin-packing problems
(doesn't scale "across") and, if the memory-demand is a high-frequency
stream of single pages (i.e. with page-unsharing), sampling by
the memory controller can't possibly keep up (doesn't "scale down").

This is only slightly better than a bunch of vague assertions, but if
you disagree, let's take it down a level in a separate thread.

My proposed alternative is tmem. which is why it may appear that I
haven't proposed anything... tmem already exists today.

> Nor does saying "see above" and "see below", when "above" and "below"
> are still equally unenlightening.

Oops, sorry. :-}  Just trying to avoid repeating myself.

> Maybe your grand designs for a "memory scheduler", where memory pages
> hop back and forth at millisecond quanta based on instantaneous data,
> between page sharing, paging, tmem, and so on, is a good one.  But
> that's not what we have now.

(A)

Tmem *is* essentially a memory scheduler.  A grand design is implemented,
works, and all the parts are upstream in open source.

> And that's not even what you're trying
> to promote.  Instead, you're trying to push a single hypercall that
> you think will be necessary for such a scheduler.

(B)

Strangely, tmem doesn't really need this hypercall.  It already has
a solution working in xm create called "tmem freeze/thaw".  But this
solution is a half-assed very heavy hammer.

The single "memory reservation" hypercall is intended to help solve a
known problem (IanJ said early in this thread: "This is a real problem")
with any environment where the amount of RAM used by a guest can change
dynamically without the knowledge of a not-in-hypervisor "memory controller",
and the toolstack then wishes to launch a new domain.  The problem can even
occur with multiple toolstack threads simultaneously launching domains.

After further thought, it appeared that the "memory reservation" hypercall
also eliminates the need for the half-assed tmem freeze/thaw as well.

> Doesn't it make sense to *first* talk about your grand vision and come
> up with a reasonable plan for it, *then* propose an implementation?
> If in the course of your 15-patch series introducing a "memory
> scheduler", you also introduce a "reservation" hypercall, then
> everyone can see exactly what it accomplishes, and actually see if
> it's necessary, or if some other design would work better.
> 
> Does that make sense?

If you reread my last response with the assumption in mind:

  "tmem == an instance of a memory scheduler == grand vision"

then does the discussion of the "memory reservation" hypercall
make more sense?

Thanks again for the pointed communication feedback.  Hopefully this
is a bit better and I will continue to ponder more communication
improvements.

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 17:55:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 17:55:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOBM6-0001Ag-Le; Tue, 16 Oct 2012 17:55:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOBM4-0001AZ-Me
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 17:55:00 +0000
Received: from [193.109.254.147:52032] by server-10.bemta-14.messagelabs.com
	id DC/CE-12590-47F9D705; Tue, 16 Oct 2012 17:55:00 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1350410099!10187005!1
X-Originating-IP: [209.85.212.169]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 465 invoked from network); 16 Oct 2012 17:54:59 -0000
Received: from mail-wi0-f169.google.com (HELO mail-wi0-f169.google.com)
	(209.85.212.169)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 17:54:59 -0000
Received: by mail-wi0-f169.google.com with SMTP id hq4so178756wib.2
	for ; Tue, 16 Oct 2012 10:54:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=KzKuR9Qf/UoUCzuR82p7vIiL3kY9wGTBWMxw1io+ARA=;
	b=dJWzqxbbi5qA/FSPrcFdkbiEXD2X0NMyljjihWWz51vD2m5e+MlHFZ2DlU5TB3mDef
	dRL3ZIn2jR65Mgmll95C8LDJwxx9/UkXlToXDiL/thJLhYs4G2b/H7fMoX2uwol9d6iM
	3VC5BWKc4IZwHQxRZMDDu4N13cIdqQ/HFGAZ82ZspjHbLdfZhXO/rEMnMt5hjLFCu7AB
	VrR8rf2AGrcM0AoNfrj7refQHNGwa/qp/dMMexhvv7aa449tMxYxLHklC/WYLIKbyFZB
	0CfwprMBNuZ9+Cs6ISWIr0DwXJd8HDQRBlauQFkkKE3vnaZmjIZrXtEwPkMIZXTwpfY8
	H4jw==
MIME-Version: 1.0
Received: by 10.216.195.133 with SMTP id p5mr10193131wen.1.1350410099074; Tue,
	16 Oct 2012 10:54:59 -0700 (PDT)
Received: by 10.194.8.169 with HTTP; Tue, 16 Oct 2012 10:54:59 -0700 (PDT)
In-Reply-To: <20121016T192158.GA.6e659.stse@fsing.rootsland.net>
References: <20121016T192158.GA.6e659.stse@fsing.rootsland.net>
Date: Tue, 16 Oct 2012 13:54:59 -0400
X-Google-Sender-Auth: XIXSqC0xO5lVsH-tl4Khg58ixhk
Message-ID: 
From: Ben Guthro 
To: Stephan Seitz 
Cc: Konrad Rzeszutek Wilk ,
	xen-devel 
Subject: Re: [Xen-devel] CPU microcode update under xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is not yet merged.

You'll need to look at the following branch from Konrad:
http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=shortlog;h=refs/heads/stable/misc

primarily, the following changesets:
23757fb5d6781bf945d21d1f5373aa71122cbea9
f6c958ff0d00ffbf1cdc8fcf2f2a82f06fbbb5f4



On Tue, Oct 16, 2012 at 1:27 PM, Stephan Seitz
 wrote:
>
> Hi!
>
> System: Debian/testing with selfcompiled kernel 3.5.5 (same error with 3.4 or 3.6)
> XEN: 4.1.3
>
> After booting the Dom0 I notice the following errors:
> [    2.939078] microcode: CPU0 sig=0x1067a, pf=0x1, revision=0xa07
> [    2.991998] microcode: CPU0 update to revision 0xa0b failed
> [    2.992035] microcode: CPU1 sig=0x1067a, pf=0x1, revision=0xa07
> [    2.995882] microcode: CPU1 update to revision 0xa0b failed
> [    2.995942] microcode: Microcode Update Driver: v2.00 , Peter Oruba
>
> If I boot the same kernel without the hypervisor the microcode update is successful.
>
> stse@osgiliath:~$ zcat /proc/config.gz |grep MICROCODE
> CONFIG_MICROCODE=m
> CONFIG_MICROCODE_INTEL=y
> # CONFIG_MICROCODE_AMD is not set
> CONFIG_MICROCODE_OLD_INTERFACE=y
>
> From /proc/cpuinfo:
> Intel(R) Core(TM)2 Duo CPU     E8500  @ 3.16GHz
>
> Do I need another driver for microcode updates under XEN, or is it impossible for now?
>
>         Stephan
>
> --
> | Stephan Seitz          E-Mail: stse@fsing.rootsland.net |
> | Public Keys: http://fsing.rootsland.net/~stse/keys.html |
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 17:55:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 17:55:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOBM6-0001Ag-Le; Tue, 16 Oct 2012 17:55:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOBM4-0001AZ-Me
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 17:55:00 +0000
Received: from [193.109.254.147:52032] by server-10.bemta-14.messagelabs.com
	id DC/CE-12590-47F9D705; Tue, 16 Oct 2012 17:55:00 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1350410099!10187005!1
X-Originating-IP: [209.85.212.169]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 465 invoked from network); 16 Oct 2012 17:54:59 -0000
Received: from mail-wi0-f169.google.com (HELO mail-wi0-f169.google.com)
	(209.85.212.169)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 17:54:59 -0000
Received: by mail-wi0-f169.google.com with SMTP id hq4so178756wib.2
	for ; Tue, 16 Oct 2012 10:54:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=KzKuR9Qf/UoUCzuR82p7vIiL3kY9wGTBWMxw1io+ARA=;
	b=dJWzqxbbi5qA/FSPrcFdkbiEXD2X0NMyljjihWWz51vD2m5e+MlHFZ2DlU5TB3mDef
	dRL3ZIn2jR65Mgmll95C8LDJwxx9/UkXlToXDiL/thJLhYs4G2b/H7fMoX2uwol9d6iM
	3VC5BWKc4IZwHQxRZMDDu4N13cIdqQ/HFGAZ82ZspjHbLdfZhXO/rEMnMt5hjLFCu7AB
	VrR8rf2AGrcM0AoNfrj7refQHNGwa/qp/dMMexhvv7aa449tMxYxLHklC/WYLIKbyFZB
	0CfwprMBNuZ9+Cs6ISWIr0DwXJd8HDQRBlauQFkkKE3vnaZmjIZrXtEwPkMIZXTwpfY8
	H4jw==
MIME-Version: 1.0
Received: by 10.216.195.133 with SMTP id p5mr10193131wen.1.1350410099074; Tue,
	16 Oct 2012 10:54:59 -0700 (PDT)
Received: by 10.194.8.169 with HTTP; Tue, 16 Oct 2012 10:54:59 -0700 (PDT)
In-Reply-To: <20121016T192158.GA.6e659.stse@fsing.rootsland.net>
References: <20121016T192158.GA.6e659.stse@fsing.rootsland.net>
Date: Tue, 16 Oct 2012 13:54:59 -0400
X-Google-Sender-Auth: XIXSqC0xO5lVsH-tl4Khg58ixhk
Message-ID: 
From: Ben Guthro 
To: Stephan Seitz 
Cc: Konrad Rzeszutek Wilk ,
	xen-devel 
Subject: Re: [Xen-devel] CPU microcode update under xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is not yet merged.

You'll need to look at the following branch from Konrad:
http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=shortlog;h=refs/heads/stable/misc

primarily, the following changesets:
23757fb5d6781bf945d21d1f5373aa71122cbea9
f6c958ff0d00ffbf1cdc8fcf2f2a82f06fbbb5f4



On Tue, Oct 16, 2012 at 1:27 PM, Stephan Seitz
 wrote:
>
> Hi!
>
> System: Debian/testing with selfcompiled kernel 3.5.5 (same error with 3.4 or 3.6)
> XEN: 4.1.3
>
> After booting the Dom0 I notice the following errors:
> [    2.939078] microcode: CPU0 sig=0x1067a, pf=0x1, revision=0xa07
> [    2.991998] microcode: CPU0 update to revision 0xa0b failed
> [    2.992035] microcode: CPU1 sig=0x1067a, pf=0x1, revision=0xa07
> [    2.995882] microcode: CPU1 update to revision 0xa0b failed
> [    2.995942] microcode: Microcode Update Driver: v2.00 , Peter Oruba
>
> If I boot the same kernel without the hypervisor the microcode update is successful.
>
> stse@osgiliath:~$ zcat /proc/config.gz |grep MICROCODE
> CONFIG_MICROCODE=m
> CONFIG_MICROCODE_INTEL=y
> # CONFIG_MICROCODE_AMD is not set
> CONFIG_MICROCODE_OLD_INTERFACE=y
>
> From /proc/cpuinfo:
> Intel(R) Core(TM)2 Duo CPU     E8500  @ 3.16GHz
>
> Do I need another driver for microcode updates under XEN, or is it impossible for now?
>
>         Stephan
>
> --
> | Stephan Seitz          E-Mail: stse@fsing.rootsland.net |
> | Public Keys: http://fsing.rootsland.net/~stse/keys.html |
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 18:15:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 18:15:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOBfp-0001YW-AG; Tue, 16 Oct 2012 18:15:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOBfn-0001YR-KY
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 18:15:24 +0000
Received: from [85.158.139.83:33324] by server-9.bemta-5.messagelabs.com id
	BA/83-23053-A34AD705; Tue, 16 Oct 2012 18:15:22 +0000
X-Env-Sender: robert.phillips@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1350411318!32944314!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzY3MTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3833 invoked from network); 16 Oct 2012 18:15:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 18:15:19 -0000
X-SBRS: None
X-MesageID: 41408342
X-Ironport-Server: ftlpip01.citrite.net
X-Remote-IP: 75.150.106.249
X-Policy: $Relay
X-IronPort-AV: E=Sophos;i="4.80,595,1344211200"; d="scan'208";a="41408342"
Received: from 75-150-106-249-newengland.hfc.comcastbusiness.net (HELO
	paine.oldroadcomputing.net) ([75.150.106.249])
	by SMTP.CITRIX.COM with ESMTP; 16 Oct 2012 18:15:16 +0000
From: Robert Phillips 
To: xen-devel@lists.xen.org
Date: Tue, 16 Oct 2012 14:15:02 -0400
Message-Id: <1350411302-5470-1-git-send-email-robert.phillips@citrix.com>
X-Mailer: git-send-email 1.7.9.5
Cc: Robert Phillips ,
	Robert Phillips 
Subject: [Xen-devel] [PATCH] Provide support for multiple frame buffers in
	Xen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Robert Phillips 

Support is provided for both shadow and hardware assisted paging (HAP) modes.
This code bookkeeps the set of video frame buffers (vram),
detects when the guest has modified any of those buffers and, upon request,
returns a bitmap of the modified pages.

This lets other software components re-paint the portions of the monitor (or monitors) that have changed.
Each monitor has a frame buffer of some size at some position in guest physical memory.
The set of frame buffers being tracked can change over time as monitors are plugged and unplugged.

Signed-Off-By: Robert Phillips 
---
 xen/arch/x86/hvm/Makefile            |    3 +-
 xen/arch/x86/hvm/dirty_vram.c        |  878 ++++++++++++++++++++++++++++++++++
 xen/arch/x86/hvm/hvm.c               |    4 +-
 xen/arch/x86/mm/hap/hap.c            |  140 +-----
 xen/arch/x86/mm/paging.c             |  232 ++++-----
 xen/arch/x86/mm/shadow/common.c      |  335 +++++++------
 xen/arch/x86/mm/shadow/multi.c       |  169 +++----
 xen/arch/x86/mm/shadow/multi.h       |    7 +-
 xen/arch/x86/mm/shadow/types.h       |    1 +
 xen/include/asm-x86/hap.h            |    4 -
 xen/include/asm-x86/hvm/dirty_vram.h |  157 ++++++
 xen/include/asm-x86/hvm/domain.h     |    2 +-
 xen/include/asm-x86/paging.h         |   22 +-
 xen/include/asm-x86/shadow.h         |    6 -
 14 files changed, 1403 insertions(+), 557 deletions(-)
 create mode 100644 xen/arch/x86/hvm/dirty_vram.c
 create mode 100644 xen/include/asm-x86/hvm/dirty_vram.h

diff --git a/xen/arch/x86/hvm/Makefile b/xen/arch/x86/hvm/Makefile
index eea5555..f37736b 100644
--- a/xen/arch/x86/hvm/Makefile
+++ b/xen/arch/x86/hvm/Makefile
@@ -2,6 +2,7 @@ subdir-y += svm
 subdir-y += vmx
 
 obj-y += asid.o
+obj-y += dirty_vram.o
 obj-y += emulate.o
 obj-y += hpet.o
 obj-y += hvm.o
@@ -22,4 +23,4 @@ obj-y += vlapic.o
 obj-y += vmsi.o
 obj-y += vpic.o
 obj-y += vpt.o
-obj-y += vpmu.o
\ No newline at end of file
+obj-y += vpmu.o
diff --git a/xen/arch/x86/hvm/dirty_vram.c b/xen/arch/x86/hvm/dirty_vram.c
new file mode 100644
index 0000000..22375c2
--- /dev/null
+++ b/xen/arch/x86/hvm/dirty_vram.c
@@ -0,0 +1,878 @@
+/*
+ * arch/x86/hvm/dirty_vram.c: Bookkeep/query dirty VRAM pages
+ * with support for multiple frame buffers.
+ *
+ * Copyright (c) 2012, Citrix Systems, Inc. (Robert Phillips)
+ * 
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; if not, write to the Free Software Foundation, Inc., 59 Temple
+ * Place - Suite 330, Boston, MA 02111-1307 USA.
+ */
+
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "../mm/mm-locks.h"
+
+#define DEBUG_stop_tracking_all_vram          1
+#define DEBUG_allocating_dirty_vram_range     1
+#define DEBUG_high_water_mark_for_vram_ranges 1
+#define DEBUG_freeing_dirty_vram_range        1
+#define DEBUG_allocate_paddr_links_page       0
+#define DEBUG_update_vram_mapping             0
+
+/* Allocates domain's dirty_vram structure */
+dv_dirty_vram_t *
+dirty_vram_alloc(struct domain *d)
+{
+    dv_dirty_vram_t *dirty_vram;
+    ASSERT( paging_locked_by_me(d) );
+    dirty_vram = d->arch.hvm_domain.dirty_vram = xmalloc(dv_dirty_vram_t);
+    if ( dirty_vram )
+    {
+        memset(dirty_vram, 0, sizeof(*dirty_vram));
+        INIT_LIST_HEAD(&dirty_vram->range_head);
+        INIT_LIST_HEAD(&dirty_vram->ext_head);
+    }
+    return dirty_vram;
+}
+
+/* Returns domain's dirty_vram structure,
+ * allocating it if necessary */
+dv_dirty_vram_t *
+dirty_vram_find_or_alloc(struct domain *d)
+{
+    dv_dirty_vram_t *dirty_vram = d->arch.hvm_domain.dirty_vram;
+    ASSERT( paging_locked_by_me(d) );
+    if ( !dirty_vram )
+        dirty_vram = dirty_vram_alloc(d);
+    return dirty_vram;
+}
+
+
+/* Free domain's dirty_vram structure */
+void dirty_vram_free(struct domain *d)
+{
+    dv_dirty_vram_t *dirty_vram = d->arch.hvm_domain.dirty_vram;
+    ASSERT( paging_locked_by_me(d) );
+    if ( dirty_vram )
+    {
+        struct list_head *curr, *next;
+        /* Free all the ranges */
+        list_for_each_safe(curr, next, &dirty_vram->range_head)
+        {
+            dv_range_t *range = list_entry(curr, dv_range_t, range_link);
+#if DEBUG_stop_tracking_all_vram
+            gdprintk(XENLOG_DEBUG, "[%05lx:%05lx] stop tracking all vram\n",
+                     range->begin_pfn, range->end_pfn);
+#endif
+            xfree(range->pl_tab);
+            xfree(range);
+        }
+        /* Free all the extension pages */
+        list_for_each_safe(curr, next, &dirty_vram->ext_head)
+        {
+            xfree(curr);            
+        }
+        xfree(dirty_vram);
+        d->arch.hvm_domain.dirty_vram = NULL;
+    }
+}
+
+/* Returns dirty vram range containing gfn, NULL if none */
+struct dv_range *
+dirty_vram_range_find_gfn(struct domain *d,
+                          unsigned long gfn)
+{
+    struct dv_dirty_vram *dirty_vram = d->arch.hvm_domain.dirty_vram;
+    ASSERT( paging_locked_by_me(d) );
+    if ( dirty_vram )
+    {
+        struct list_head *curr;
+        list_for_each(curr, &dirty_vram->range_head)
+        {
+            dv_range_t *range = list_entry(curr, dv_range_t, range_link);
+            if ( gfn >= range->begin_pfn &&
+                 gfn <  range->end_pfn )
+            {
+                return range;
+            }
+        }
+    }
+    return NULL;
+}
+
+/* Returns pointer to dirty vram range matching [begin_pfn .. end_pfn ), NULL if none. */
+dv_range_t *
+dirty_vram_range_find(struct domain *d,
+                      unsigned long begin_pfn,
+                      unsigned long nr)
+{
+    unsigned long end_pfn = begin_pfn + nr;
+    dv_dirty_vram_t *dirty_vram = d->arch.hvm_domain.dirty_vram;
+    ASSERT( paging_locked_by_me(d) );
+    if ( dirty_vram )
+    {
+        struct list_head *curr;
+        list_for_each(curr, &dirty_vram->range_head)
+        {
+            dv_range_t *range = list_entry(curr, dv_range_t, range_link);
+            if ( begin_pfn == range->begin_pfn &&
+                 end_pfn   == range->end_pfn )
+            {
+                return range;
+            }
+        }
+    }
+    return NULL;
+}
+
+/* Allocate specified dirty_vram range */
+static dv_range_t *
+_dirty_vram_range_alloc(struct domain *d,
+                        unsigned long begin_pfn,
+                        unsigned long nr)
+{
+    dv_dirty_vram_t *dirty_vram = d->arch.hvm_domain.dirty_vram;
+    dv_range_t *range = NULL;
+    unsigned long end_pfn = begin_pfn + nr;
+    dv_paddr_link_t *pl_tab = NULL;
+    int i;
+    
+    ASSERT( paging_locked_by_me(d) );
+    ASSERT( dirty_vram != NULL );
+    
+#if DEBUG_allocating_dirty_vram_range
+    gdprintk(XENLOG_DEBUG,
+             "[%05lx:%05lx] Allocating dirty vram range hap:%d\n",
+             begin_pfn, end_pfn,
+             d->arch.hvm_domain.hap_enabled);
+#endif
+    
+    range = xmalloc(dv_range_t);
+    if (range == NULL)
+        goto err_out;
+    
+    memset(range, 0, sizeof(dv_range_t));
+    INIT_LIST_HEAD(&range->range_link);
+    
+    range->begin_pfn = begin_pfn;
+    range->end_pfn = end_pfn;
+
+    if (!hap_enabled(d))
+    {
+        if ( (pl_tab = xmalloc_array(dv_paddr_link_t, nr)) == NULL )
+        {
+            goto err_out;
+        }
+        for (i = 0; i != nr; i++)
+        {
+            pl_tab[i].sl1ma = INVALID_PADDR;
+            pl_tab[i].pl_next = NULL;
+        }
+    }    
+    
+    range->pl_tab = pl_tab;
+    range->mappings_hwm = 1;
+
+    list_add(&range->range_link, &dirty_vram->range_head);
+    if ( ++dirty_vram->nr_ranges > dirty_vram->ranges_hwm )
+    {
+        dirty_vram->ranges_hwm = dirty_vram->nr_ranges;
+#if DEBUG_high_water_mark_for_vram_ranges
+        gdprintk(XENLOG_DEBUG,
+                 "High water mark for number of vram ranges is now:%d\n",
+                 dirty_vram->ranges_hwm);
+#endif
+    }
+    return range;
+    
+ err_out:
+    xfree(pl_tab);
+    xfree(range);
+    return NULL;
+}
+
+
+/* Frees specified dirty_vram range */
+void dirty_vram_range_free(struct domain *d,
+                           dv_range_t *range)
+{
+    dv_dirty_vram_t *dirty_vram = d->arch.hvm_domain.dirty_vram;
+    ASSERT( paging_locked_by_me(d) );
+    if ( dirty_vram )
+    {
+        int i, nr = range->end_pfn - range->begin_pfn;
+        
+#if DEBUG_freeing_dirty_vram_range
+        gdprintk(XENLOG_DEBUG,
+                 "[%05lx:%05lx] Freeing dirty vram range\n",
+                 range->begin_pfn, range->end_pfn);
+#endif
+        
+        if (range->pl_tab)
+        {
+            for (i = 0; i != nr; i++)
+            {
+                dv_paddr_link_t *plx;
+                plx = range->pl_tab[i].pl_next;
+                /* Does current FB page have multiple mappings? */
+                if (plx) /* yes */
+                {
+                    /* Find the last element in singly-linked list */
+                    while (plx->pl_next != NULL)
+                        plx = plx->pl_next;
+                    /* Prepend whole list to the free list */
+                    plx->pl_next = dirty_vram->pl_free;
+                    dirty_vram->pl_free = range->pl_tab[i].pl_next;
+                }
+            }
+            xfree(range->pl_tab);
+            range->pl_tab = NULL;
+        }
+        
+        /* Remove range from the linked list, free it, and adjust count*/
+        list_del(&range->range_link);
+        xfree(range);
+        dirty_vram->nr_ranges--;
+    }
+}
+
+/* dirty_vram_range_alloc()
+ * This function ensures that the new range does not overlap any existing
+ * ranges -- deleting them if necessary -- and then calls _dirty_vram_range_alloc
+ * to actually allocate the new range.
+ */
+dv_range_t *
+dirty_vram_range_alloc(struct domain *d,
+                        unsigned long begin_pfn,
+                        unsigned long nr)
+{
+    unsigned long end_pfn = begin_pfn + nr;
+    dv_dirty_vram_t *dirty_vram = d->arch.hvm_domain.dirty_vram;
+    dv_range_t *range;
+    struct list_head *curr, *next;
+    
+    ASSERT( paging_locked_by_me(d) );
+    ASSERT( dirty_vram != NULL );
+    
+    /* Ranges cannot overlap so
+     * free any range that overlaps [ begin_pfn .. end_pfn ) */
+    list_for_each_safe(curr, next, &dirty_vram->range_head)
+    {
+        dv_range_t *rng = list_entry(curr, dv_range_t, range_link);
+        if ( ((rng->begin_pfn <= begin_pfn) && (begin_pfn <  rng->end_pfn)) ||
+             ((begin_pfn <= rng->begin_pfn) && (rng->begin_pfn < end_pfn)) )
+        {
+            /* Different tracking, tear the previous down. */
+            dirty_vram_range_free(d, rng);
+        }
+    }
+        
+    range = _dirty_vram_range_alloc(d, begin_pfn, nr);
+    if ( !range )
+        goto out;
+
+ out:
+    return range;
+}
+
+/* dirty_vram_range_find_or_alloc()
+ * Find the range for [begin_pfn:begin_pfn+nr).
+ * If it doesn't exists, create it.
+ */
+dv_range_t *
+dirty_vram_range_find_or_alloc(struct domain *d,
+                                unsigned long begin_pfn,
+                                unsigned long nr)
+{
+    dv_range_t *range;
+    ASSERT( paging_locked_by_me(d) );
+    range = dirty_vram_range_find(d, begin_pfn, nr);
+    if ( !range )
+        range = dirty_vram_range_alloc(d, begin_pfn, nr);
+    return range;
+}
+
+
+
+/* Allocate a dv_paddr_link struct */
+static dv_paddr_link_t *
+alloc_paddr_link(struct domain *d)
+{
+    dv_paddr_link_t * pl = NULL;
+    dv_dirty_vram_t *dirty_vram = d->arch.hvm_domain.dirty_vram;
+    
+    ASSERT( paging_locked_by_me(d) );
+    BUILD_BUG_ON(sizeof(dv_paddr_link_ext_t) > PAGE_SIZE);
+    /* Is the list of free pl's empty? */
+    if (dirty_vram->pl_free == NULL) /* yes */
+    {
+        /* Allocate another page of pl's.
+         * Link them all together and point the free list head at them */
+        int i;
+        dv_paddr_link_ext_t *ext = xmalloc(dv_paddr_link_ext_t);
+        if (ext == NULL)
+            goto out;
+
+#if DEBUG_allocate_paddr_links_page
+        gdprintk(XENLOG_DEBUG, "Allocated another page of paddr_links\n");
+#endif
+        list_add(&ext->ext_link, &dirty_vram->ext_head);
+
+        /* initialize and link together the new pl entries */
+        for (i = 0; i != ARRAY_SIZE(ext->entries); i++)
+        {
+            ext->entries[i].sl1ma = INVALID_PADDR;
+            ext->entries[i].pl_next = &ext->entries[i+1];
+        }
+        ext->entries[ARRAY_SIZE(ext->entries) - 1].pl_next = NULL;
+        dirty_vram->pl_free = &ext->entries[0];
+    }
+    pl = dirty_vram->pl_free;
+    dirty_vram->pl_free = pl->pl_next;
+
+    pl->sl1ma = INVALID_PADDR;
+    pl->pl_next = NULL;
+ out:
+    return pl;
+}
+
+
+/* Free a paddr_link struct, given address of its predecessor in linked list */
+dv_paddr_link_t *
+free_paddr_link(struct domain *d,
+                dv_paddr_link_t **ppl,
+                dv_paddr_link_t *pl)
+{
+    dv_dirty_vram_t *dirty_vram = d->arch.hvm_domain.dirty_vram;
+    dv_paddr_link_t *npl; /* next pl */
+
+    ASSERT( paging_locked_by_me(d) );
+    /* extension mapping? */
+    if (ppl) /* yes. free it */
+    {
+        pl = (*ppl);
+        (*ppl) = npl = pl->pl_next;
+    }
+    else  /* main table */
+    {
+        /* move 2nd mapping to main table.
+         * and free 2nd mapping */
+        dv_paddr_link_t * spl;
+        spl = pl->pl_next;
+        if (spl == NULL)
+        {
+            pl->sl1ma = INVALID_PADDR;
+            return pl;
+        }
+        pl->sl1ma = spl->sl1ma;
+        pl->pl_next = spl->pl_next;
+        npl = pl; /* reprocess main table entry again */
+        pl = spl;
+    }
+    pl->sl1ma = INVALID_PADDR;
+    pl->pl_next = dirty_vram->pl_free;
+    dirty_vram->pl_free = pl;
+    return npl;
+}
+
+
+/* dirty_vram_range_update()
+ * This is called whenever a level 1 page table entry is modified.
+ * If the L1PTE is being cleared, the function removes any paddr_links
+ * that refer to it.
+ * If the L1PTE is being set to a frame buffer page, a paddr_link is
+ * created for that page's entry in pl_tab.
+ * Returns 1 iff entry found and set or cleared.
+ */
+int dirty_vram_range_update(struct domain *d,
+                            unsigned long gfn,
+                            paddr_t sl1ma,
+                            int set)
+{
+    int effective = 0;
+    dv_range_t *range;
+
+    ASSERT(paging_locked_by_me(d));
+    range = dirty_vram_range_find_gfn(d, gfn);
+    if ( range )
+    {
+        unsigned long i = gfn - range->begin_pfn;
+        dv_paddr_link_t *pl = &range->pl_tab[ i ];
+        dv_paddr_link_t **ppl = NULL;
+        int len = 0;
+
+        /* find matching entry (pl), if any, and its predecessor
+         * in linked list (ppl) */
+        while (pl != NULL)
+        {
+            if (pl->sl1ma == sl1ma || pl->sl1ma == INVALID_PADDR )
+                break;
+            ppl = &pl->pl_next;
+            pl = *ppl;
+            len++;
+        }
+            
+        if (set)
+        {
+            /* Did we find sl1ma in either the main table or the linked list? */
+            if (pl == NULL) /* no, so we'll need to alloc a link */
+            {
+                ASSERT(ppl != NULL);
+                /* alloc link and append it to list */
+                (*ppl) = pl = alloc_paddr_link(d);
+                if (pl == NULL)
+                    goto out;
+            }
+            if ( pl->sl1ma != sl1ma )
+            {
+                pl->sl1ma = sl1ma;
+                range->nr_mappings++;
+            }
+            effective = 1;
+            if (len > range->mappings_hwm)
+            {
+                range->mappings_hwm = len;
+#if DEBUG_update_vram_mapping
+                gdprintk(XENLOG_DEBUG,
+                         "[%lx] set      sl1ma:%lx hwm:%d mappings:%d freepages:%d\n",
+                         gfn, sl1ma,
+                         range->mappings_hwm,
+                         range->nr_mappings,
+                         d->arch.paging.shadow.free_pages);
+#endif
+            }
+        }
+        else /* clear */
+        {
+            if (pl && pl->sl1ma == sl1ma )
+            {
+#if DEBUG_update_vram_mapping
+                gdprintk(XENLOG_DEBUG,
+                         "[%lx] clear    sl1ma:%lx mappings:%d\n",
+                         gfn, sl1ma,
+                         range->nr_mappings-1);
+#endif
+                free_paddr_link(d, ppl, pl);
+                if ( --range->nr_mappings == 0 )
+                {
+                    dirty_vram_range_free(d, range);
+                }
+                effective = 1;
+            }
+        }
+    }
+ out:
+    return effective;
+}
+
+
+/* shadow_scan_dirty_flags()
+ * This produces a dirty bitmap for the range by examining every
+ * L1PTE referenced by some dv_paddr_link in the range's pl_tab table.
+ * It tests and clears each such L1PTE's dirty flag.
+ */
+static int shadow_scan_dirty_flags(struct domain *d,
+                                   dv_range_t *range,
+                                   uint8_t *dirty_bitmap)
+{
+    int flush_tlb = 0;
+    unsigned long i;
+    unsigned long nr = range->end_pfn - range->begin_pfn;
+#ifdef __i386__
+    unsigned long map_mfn = INVALID_MFN;
+    void *map_sl1p = NULL;
+#endif
+
+    ASSERT( paging_locked_by_me(d) );
+    /* Iterate over VRAM to track dirty bits. */
+    for ( i = 0; i < nr; i++ )
+    {
+        int dirty = 0, len = 1;
+        dv_paddr_link_t *pl;
+        for (pl = &range->pl_tab[i]; pl; pl = pl->pl_next, len++)
+        {
+#ifdef __i386__
+            void *sl1p;
+            unsigned long sl1mfn;
+#endif
+            l1_pgentry_t *sl1e;
+            paddr_t sl1ma = pl->sl1ma;
+            if (sl1ma == INVALID_PADDR) /* FB page is unmapped */
+                continue;
+#ifdef __i386__
+            sl1p = map_sl1p;
+            sl1mfn = paddr_to_pfn(sl1ma);
+
+            if ( sl1mfn != map_mfn )
+            {
+                if ( map_sl1p )
+                    sh_unmap_domain_page(map_sl1p);
+                map_sl1p = sl1p = sh_map_domain_page(_mfn(sl1mfn));
+                map_mfn = sl1mfn;
+            }
+            sl1e = sl1p + (sl1ma & ~PAGE_MASK);
+#else
+            sl1e = maddr_to_virt(sl1ma);
+#endif
+            if ( l1e_get_flags(*sl1e) & _PAGE_DIRTY )
+            {
+                dirty = 1;
+                /* Clear dirty so we can detect if page gets re-dirtied */
+                /* Note: this is atomic, so we may clear a
+                 * _PAGE_ACCESSED set by another processor. */
+                l1e_remove_flags(*sl1e, _PAGE_DIRTY);
+                flush_tlb = 1;
+            }
+        } /* for */
+        if ( dirty )
+        {
+            dirty_bitmap[i >> 3] |= (1 << (i & 7));
+        }
+    }
+
+#ifdef __i386__
+    if ( map_sl1p )
+        sh_unmap_domain_page(map_sl1p);
+#endif
+    return flush_tlb;
+}
+
+
+/* shadow_track_dirty_vram()
+ * This is the API called by the guest to determine which pages in the range
+ * from [begin_pfn:begin_pfn+nr) have been dirtied since the last call.
+ * It creates the domain's dv_dirty_vram on demand. 
+ * It creates ranges on demand when some [begin_pfn:nr) is first encountered.
+ * To collect the dirty bitmask it calls shadow_scan_dirty_flags().
+ * It copies the dirty bitmask into guest storage.
+ */
+int shadow_track_dirty_vram(struct domain *d,
+                            unsigned long begin_pfn,
+                            unsigned long nr,
+                            XEN_GUEST_HANDLE_64(uint8) guest_dirty_bitmap)
+{
+    int rc = 0;
+    unsigned long end_pfn = begin_pfn + nr;
+    int flush_tlb = 0;
+    dv_range_t *range;
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+
+    if (end_pfn < begin_pfn
+            || begin_pfn > p2m->max_mapped_pfn
+            || end_pfn >= p2m->max_mapped_pfn)
+        return -EINVAL;
+
+    paging_lock(d);
+
+    if ( !nr || guest_handle_is_null(guest_dirty_bitmap) )
+    {
+        goto out;
+    }
+
+    if ( !dirty_vram_find_or_alloc(d))
+    {
+        rc = -ENOMEM;
+        goto out;
+    }
+    
+    range = dirty_vram_range_find(d, begin_pfn, nr);
+    if ( !range )
+    {
+        range = dirty_vram_range_alloc(d, begin_pfn, nr);
+        if ( range )    
+            sh_find_all_vram_mappings(d->vcpu[0], range);
+    }
+    if ( range )
+    {
+        int size = (nr + BITS_PER_LONG - 1) / BITS_PER_LONG;
+        unsigned long dirty_bitmap[size];
+        
+        memset(dirty_bitmap, 0x00, size * BYTES_PER_LONG);
+
+	flush_tlb |= shadow_scan_dirty_flags(d, range, (uint8_t*)dirty_bitmap);
+        
+        rc = -EFAULT;
+        if ( copy_to_guest(guest_dirty_bitmap,
+                           (uint8_t*)dirty_bitmap,
+                           size * BYTES_PER_LONG) == 0 )
+            rc = 0;
+    }
+    if ( flush_tlb )
+        flush_tlb_mask(d->domain_dirty_cpumask);
+
+out:
+    paging_unlock(d);
+    return rc;
+}
+
+
+/************************************************/
+/*          HAP VRAM TRACKING SUPPORT           */
+/************************************************/
+
+/* hap_enable_vram_tracking()
+ * For all ranges, mark all vram pages in range as logdirty read-only.
+ */
+static int hap_enable_vram_tracking(struct domain *d)
+{
+    int rc = 0;
+    dv_dirty_vram_t *dirty_vram;
+    struct list_head *curr;
+
+    /* turn on PG_log_dirty bit in paging mode */
+    paging_lock(d);
+    d->arch.paging.mode |= PG_log_dirty;
+    paging_unlock(d);
+
+    p2m_lock(p2m_get_hostp2m(d));
+    paging_lock(d);
+    
+    dirty_vram = d->arch.hvm_domain.dirty_vram;
+
+    /* dirty_vram != NULL iff we're tracking dirty vram.
+     * If we start tracking dirty pages for all memory then
+     * the dirty_vram structure is freed. */
+    if ( !dirty_vram )
+    {
+        rc = -EINVAL;
+        goto out;
+    }
+
+    /* set l1e entries of P2M table to be read-only. */
+    list_for_each(curr, &dirty_vram->range_head)
+      {
+	dv_range_t *range = list_entry(curr, dv_range_t, range_link);
+	gdprintk(XENLOG_DEBUG, "[%05lx:%05lx] enable  vram tracking\n",
+		 range->begin_pfn, range->end_pfn);
+	p2m_change_type_range(d, range->begin_pfn, range->end_pfn, 
+			      p2m_ram_rw, p2m_ram_logdirty);
+      }
+        
+    flush_tlb_mask(d->domain_dirty_cpumask);
+ out:
+    paging_unlock(d);
+    p2m_unlock(p2m_get_hostp2m(d));
+    if (rc) 
+    {
+        paging_lock(d);
+        d->arch.paging.mode &= ~PG_log_dirty;
+        paging_unlock(d);
+    }
+    return rc;
+}
+
+/* hap_disable_vram_tracking()
+ * For all ranges, mark all vram pages in range as logdirty read-write.
+ */
+static int hap_disable_vram_tracking(struct domain *d)
+{
+    int rc = 0;
+    dv_dirty_vram_t *dirty_vram;
+    struct list_head *curr;
+
+    paging_lock(d);
+    d->arch.paging.mode &= ~PG_log_dirty;
+    paging_unlock(d);
+
+    p2m_lock(p2m_get_hostp2m(d));
+    paging_lock(d);
+    
+    dirty_vram = d->arch.hvm_domain.dirty_vram;
+    if ( !dirty_vram )
+    {
+        rc = -EINVAL;
+        goto out;
+    }
+    
+    /* set l1e entries of P2M table with normal mode */
+    list_for_each(curr, &dirty_vram->range_head)
+      {
+	dv_range_t *range = list_entry(curr, dv_range_t, range_link);
+	gdprintk(XENLOG_DEBUG, "[%05lx:%05lx] disable vram tracking\n",
+		 range->begin_pfn, range->end_pfn);
+	p2m_change_type_range(d, range->begin_pfn, range->end_pfn, 
+			      p2m_ram_logdirty, p2m_ram_rw);
+      }
+    flush_tlb_mask(d->domain_dirty_cpumask);
+ out:
+    paging_unlock(d);
+    p2m_unlock(p2m_get_hostp2m(d));
+    if (rc) 
+    {
+        paging_lock(d);
+        d->arch.paging.mode |= PG_log_dirty;
+        paging_unlock(d);
+    }
+    return rc;
+}
+
+/* hap_clean_vram_tracking_range()
+ * For all the pages in the range specified by [begin_pfn,nr),
+ * note in the dirty bitmap any page that has been marked as read-write,
+ * which signifies that the page has been dirtied, and reset the page
+ * to ram_logdirty. 
+ */
+void hap_clean_vram_tracking_range(struct domain *d,
+                                   unsigned long begin_pfn,
+                                   unsigned long nr,
+                                   uint8_t *dirty_bitmap)
+{
+    int i;
+    unsigned long pfn;
+    dv_dirty_vram_t *dirty_vram = d->arch.hvm_domain.dirty_vram;
+    dv_range_t *range;
+
+    ASSERT(p2m_locked_by_me(p2m_get_hostp2m(d)));
+    ASSERT(paging_locked_by_me(d));
+    
+    if ( !dirty_vram )
+    {
+        gdprintk(XENLOG_DEBUG, "Should only be called while tracking dirty vram.\n");
+        return;
+    }
+
+    range = dirty_vram_range_find(d, begin_pfn, nr);
+    if (!range)
+        return;
+
+    /* set l1e entries of P2M table to be read-only. */
+    /* On first write, it page faults, its entry is changed to read-write,
+     * its bit in the dirty bitmap is set, and on retry the write succeeds. */
+    for (i = 0, pfn = range->begin_pfn; pfn < range->end_pfn; i++, pfn++)
+    {
+        p2m_type_t pt;
+        pt = p2m_change_type(d, pfn, p2m_ram_rw, p2m_ram_logdirty);
+        if (pt == p2m_ram_rw)
+            dirty_bitmap[i >> 3] |= (1 << (i & 7));
+    }
+    flush_tlb_mask(d->domain_dirty_cpumask);
+}
+
+static void hap_vram_tracking_init(struct domain *d)
+{
+    paging_log_dirty_init(d, hap_enable_vram_tracking,
+                          hap_disable_vram_tracking,
+                          NULL);
+}
+
+/* hap_track_dirty_vram()
+ * Create the domain's dv_dirty_vram struct on demand.
+ * Create a dirty vram range on demand when some [begin_pfn:begin_pfn+nr] is first encountered.
+ * Collect the guest_dirty bitmask, a bit mask of the dirties vram pages, by
+ * calling paging_log_dirty_range().
+ */
+int hap_track_dirty_vram(struct domain *d,
+                         unsigned long begin_pfn,
+                         unsigned long nr,
+                         XEN_GUEST_HANDLE_64(uint8) guest_dirty_bitmap)
+{
+    long rc = 0;
+    dv_dirty_vram_t *dirty_vram;
+    int restart_log_dirty = 0;
+
+    paging_lock(d);
+    dirty_vram = d->arch.hvm_domain.dirty_vram;
+    if ( nr )
+    {
+        dv_range_t *range = NULL;
+        int size = (nr + BITS_PER_LONG - 1) / BITS_PER_LONG;
+        unsigned long dirty_bitmap[size];
+
+        /* Already tracking dirty vram? */
+        if ( paging_mode_log_dirty(d) && dirty_vram ) /* yes */
+        {
+            /* Handle the addition of another range */
+            range = dirty_vram_range_find(d, begin_pfn, nr);
+            if ( !range )
+            {
+                rc = -ENOMEM;
+                if ( !(range = dirty_vram_range_alloc(d, begin_pfn, nr)) )
+                    goto param_fail;
+                restart_log_dirty = 1;
+            }
+        }
+        /* Just starting to track dirty vram? */
+        else if ( !paging_mode_log_dirty(d) && !dirty_vram ) /* yes */
+        {
+            rc = -ENOMEM;
+            if ( !(dirty_vram = dirty_vram_alloc(d)) )
+                goto param_fail;
+            
+            if ( !(range = dirty_vram_range_find_or_alloc(d, begin_pfn, nr)) )
+                goto param_fail;
+
+            restart_log_dirty = 1;
+            /* Initialize callbacks for vram tracking */
+            hap_vram_tracking_init(d);
+        }
+        else
+        {
+            /* Test for invalid combination */
+            if ( !paging_mode_log_dirty(d) && dirty_vram )
+                rc = -EINVAL;
+            else /* logging dirty of all memory, not tracking dirty vram */
+                rc = -ENODATA;
+            goto param_fail;
+        }
+        
+        if (restart_log_dirty) 
+        {
+            /* disable then enable log dirty */
+            paging_unlock(d);
+            if (paging_mode_log_dirty(d))
+                paging_log_dirty_disable(d);
+                    
+            rc = paging_log_dirty_enable(d);
+            paging_lock(d);
+            if (rc != 0)
+                goto param_fail;
+        }
+        
+        paging_unlock(d);
+        memset(dirty_bitmap, 0x00, size * BYTES_PER_LONG);
+	paging_log_dirty_range(d, begin_pfn, nr, (uint8_t*)dirty_bitmap);
+        rc = -EFAULT;
+        if ( copy_to_guest(guest_dirty_bitmap,
+                           (uint8_t*)dirty_bitmap,
+                           size * BYTES_PER_LONG) == 0 )
+        {
+            rc = 0;
+        }
+    }
+    else
+    {
+        /* If zero pages specified while already tracking dirty vram
+         * then stop tracking */
+        if ( paging_mode_log_dirty(d) && dirty_vram ) {
+            paging_unlock(d);
+            rc = paging_log_dirty_disable(d);
+            paging_lock(d);
+            dirty_vram_free(d);
+        } else /* benign no-op */
+        {
+            rc = 0;
+        }
+        paging_unlock(d);
+    }
+
+    return rc;
+
+param_fail:
+    dirty_vram_free(d);
+    paging_unlock(d);
+    return rc;
+}
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index a5a1bcf..55553e4 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -57,6 +57,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1433,8 +1434,7 @@ int hvm_hap_nested_page_fault(paddr_t gpa,
          */
         if ( access_w )
         {
-            paging_mark_dirty(v->domain, mfn_x(mfn));
-            p2m_change_type(v->domain, gfn, p2m_ram_logdirty, p2m_ram_rw);
+            paging_mark_dirty_hap(v->domain, gfn, mfn_x(mfn));
         }
         rc = 1;
         goto out_put_gfn;
diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index d2637d3..f31e4e5 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -41,6 +41,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "private.h"
 
@@ -53,139 +54,6 @@
 #define page_to_mfn(_pg) _mfn(__page_to_mfn(_pg))
 
 /************************************************/
-/*          HAP VRAM TRACKING SUPPORT           */
-/************************************************/
-
-static int hap_enable_vram_tracking(struct domain *d)
-{
-    struct sh_dirty_vram *dirty_vram = d->arch.hvm_domain.dirty_vram;
-
-    if ( !dirty_vram )
-        return -EINVAL;
-
-    /* turn on PG_log_dirty bit in paging mode */
-    paging_lock(d);
-    d->arch.paging.mode |= PG_log_dirty;
-    paging_unlock(d);
-
-    /* set l1e entries of P2M table to be read-only. */
-    p2m_change_type_range(d, dirty_vram->begin_pfn, dirty_vram->end_pfn, 
-                          p2m_ram_rw, p2m_ram_logdirty);
-
-    flush_tlb_mask(d->domain_dirty_cpumask);
-    return 0;
-}
-
-static int hap_disable_vram_tracking(struct domain *d)
-{
-    struct sh_dirty_vram *dirty_vram = d->arch.hvm_domain.dirty_vram;
-
-    if ( !dirty_vram )
-        return -EINVAL;
-
-    paging_lock(d);
-    d->arch.paging.mode &= ~PG_log_dirty;
-    paging_unlock(d);
-
-    /* set l1e entries of P2M table with normal mode */
-    p2m_change_type_range(d, dirty_vram->begin_pfn, dirty_vram->end_pfn, 
-                          p2m_ram_logdirty, p2m_ram_rw);
-
-    flush_tlb_mask(d->domain_dirty_cpumask);
-    return 0;
-}
-
-static void hap_clean_vram_tracking(struct domain *d)
-{
-    struct sh_dirty_vram *dirty_vram = d->arch.hvm_domain.dirty_vram;
-
-    if ( !dirty_vram )
-        return;
-
-    /* set l1e entries of P2M table to be read-only. */
-    p2m_change_type_range(d, dirty_vram->begin_pfn, dirty_vram->end_pfn, 
-                          p2m_ram_rw, p2m_ram_logdirty);
-
-    flush_tlb_mask(d->domain_dirty_cpumask);
-}
-
-static void hap_vram_tracking_init(struct domain *d)
-{
-    paging_log_dirty_init(d, hap_enable_vram_tracking,
-                          hap_disable_vram_tracking,
-                          hap_clean_vram_tracking);
-}
-
-int hap_track_dirty_vram(struct domain *d,
-                         unsigned long begin_pfn,
-                         unsigned long nr,
-                         XEN_GUEST_HANDLE_64(uint8) dirty_bitmap)
-{
-    long rc = 0;
-    struct sh_dirty_vram *dirty_vram = d->arch.hvm_domain.dirty_vram;
-
-    if ( nr )
-    {
-        if ( paging_mode_log_dirty(d) && dirty_vram )
-        {
-            if ( begin_pfn != dirty_vram->begin_pfn ||
-                 begin_pfn + nr != dirty_vram->end_pfn )
-            {
-                paging_log_dirty_disable(d);
-                dirty_vram->begin_pfn = begin_pfn;
-                dirty_vram->end_pfn = begin_pfn + nr;
-                rc = paging_log_dirty_enable(d);
-                if (rc != 0)
-                    goto param_fail;
-            }
-        }
-        else if ( !paging_mode_log_dirty(d) && !dirty_vram )
-        {
-            rc = -ENOMEM;
-            if ( (dirty_vram = xmalloc(struct sh_dirty_vram)) == NULL )
-                goto param_fail;
-
-            dirty_vram->begin_pfn = begin_pfn;
-            dirty_vram->end_pfn = begin_pfn + nr;
-            d->arch.hvm_domain.dirty_vram = dirty_vram;
-            hap_vram_tracking_init(d);
-            rc = paging_log_dirty_enable(d);
-            if (rc != 0)
-                goto param_fail;
-        }
-        else
-        {
-            if ( !paging_mode_log_dirty(d) && dirty_vram )
-                rc = -EINVAL;
-            else
-                rc = -ENODATA;
-            goto param_fail;
-        }
-        /* get the bitmap */
-        rc = paging_log_dirty_range(d, begin_pfn, nr, dirty_bitmap);
-    }
-    else
-    {
-        if ( paging_mode_log_dirty(d) && dirty_vram ) {
-            rc = paging_log_dirty_disable(d);
-            xfree(dirty_vram);
-            dirty_vram = d->arch.hvm_domain.dirty_vram = NULL;
-        } else
-            rc = 0;
-    }
-
-    return rc;
-
-param_fail:
-    if ( dirty_vram )
-    {
-        xfree(dirty_vram);
-        dirty_vram = d->arch.hvm_domain.dirty_vram = NULL;
-    }
-    return rc;
-}
-
-/************************************************/
 /*            HAP LOG DIRTY SUPPORT             */
 /************************************************/
 
@@ -223,14 +91,12 @@ static void hap_clean_dirty_bitmap(struct domain *d)
 
 void hap_logdirty_init(struct domain *d)
 {
-    struct sh_dirty_vram *dirty_vram = d->arch.hvm_domain.dirty_vram;
+    struct dv_dirty_vram *dirty_vram = d->arch.hvm_domain.dirty_vram;
     if ( paging_mode_log_dirty(d) && dirty_vram )
     {
         paging_log_dirty_disable(d);
-        xfree(dirty_vram);
-        dirty_vram = d->arch.hvm_domain.dirty_vram = NULL;
+        dirty_vram_free(d);
     }
-
     /* Reinitialize logdirty mechanism */
     paging_log_dirty_init(d, hap_enable_log_dirty,
                           hap_disable_log_dirty,
diff --git a/xen/arch/x86/mm/paging.c b/xen/arch/x86/mm/paging.c
index ca879f9..7464b07 100644
--- a/xen/arch/x86/mm/paging.c
+++ b/xen/arch/x86/mm/paging.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -278,6 +279,46 @@ out:
 }
 
 
+/* paging_mark_dirty_hap()
+ * Make a hap page writeable and mark it as dirty.
+ * This done atomically under the p2m and paging locks to avoid leaving
+ * a window where the page might be modified without being marked as dirty.
+ */
+void paging_mark_dirty_hap(struct domain *d,
+                           unsigned long pfn,
+                           unsigned long guest_mfn)
+{
+    mfn_t gmfn;
+    p2m_type_t pt;
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+    
+    if ( !paging_mode_log_dirty(d) )
+        return;
+
+    gmfn = _mfn(guest_mfn);
+
+    ASSERT( mfn_valid(gmfn) &&
+            page_get_owner(mfn_to_page(gmfn)) == d );
+
+    p2m_lock(p2m);
+    pt = p2m_change_type(d, pfn, p2m_ram_logdirty, p2m_ram_rw);
+    paging_lock(d);
+    if ( pt == p2m_ram_logdirty )
+    {
+        dv_range_t *range;
+        PAGING_DEBUG(LOGDIRTY,
+                     "marked mfn %" PRI_mfn " (pfn=%lx), dom %d\n",
+                     mfn_x(gmfn), pfn, d->domain_id);
+        d->arch.paging.log_dirty.dirty_count++;
+        range = dirty_vram_range_find_gfn(d, pfn);
+        if (range)
+            range->dirty_count++;
+    }
+    paging_mark_dirty(d, guest_mfn); 
+    paging_unlock(d);
+    p2m_unlock(p2m);
+}
+
 /* Is this guest page dirty? */
 int paging_mfn_is_dirty(struct domain *d, mfn_t gmfn)
 {
@@ -333,8 +374,11 @@ int paging_log_dirty_op(struct domain *d, struct xen_domctl_shadow_op *sc)
     mfn_t *l4, *l3, *l2;
     unsigned long *l1;
     int i4, i3, i2;
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
 
     domain_pause(d);
+    /* Locking hierarchy requires p2m lock to be taken first */
+    p2m_lock(p2m);
     paging_lock(d);
 
     clean = (sc->op == XEN_DOMCTL_SHADOW_OP_CLEAN);
@@ -345,6 +389,14 @@ int paging_log_dirty_op(struct domain *d, struct xen_domctl_shadow_op *sc)
                  d->arch.paging.log_dirty.fault_count,
                  d->arch.paging.log_dirty.dirty_count);
 
+    if (hap_enabled(d) && d->arch.hvm_domain.dirty_vram)
+    {
+        /* If we're cleaning/peeking all guest memory, we should not be tracking
+         * dirty vram. */
+        rv = -EINVAL;
+        goto out;
+    }
+
     sc->stats.fault_count = d->arch.paging.log_dirty.fault_count;
     sc->stats.dirty_count = d->arch.paging.log_dirty.dirty_count;
 
@@ -424,170 +476,60 @@ int paging_log_dirty_op(struct domain *d, struct xen_domctl_shadow_op *sc)
 
     if ( clean )
     {
-        /* We need to further call clean_dirty_bitmap() functions of specific
-         * paging modes (shadow or hap).  Safe because the domain is paused. */
-        d->arch.paging.log_dirty.clean_dirty_bitmap(d);
+        /* Is null if tracking dirty vram */
+        if (d->arch.paging.log_dirty.clean_dirty_bitmap)
+        {
+            /* We need to further call clean_dirty_bitmap() functions of specific
+             * paging modes (shadow or hap).  Safe because the domain is paused. */
+            d->arch.paging.log_dirty.clean_dirty_bitmap(d);
+        }
     }
     domain_unpause(d);
     return rv;
 
  out:
     paging_unlock(d);
+    p2m_unlock(p2m);
     domain_unpause(d);
     return rv;
 }
 
-int paging_log_dirty_range(struct domain *d,
-                            unsigned long begin_pfn,
-                            unsigned long nr,
-                            XEN_GUEST_HANDLE_64(uint8) dirty_bitmap)
+void paging_log_dirty_range(struct domain *d,
+                           unsigned long begin_pfn,
+                           unsigned long nr,
+                           uint8_t *dirty_bitmap)
 {
-    int rv = 0;
-    unsigned long pages = 0;
-    mfn_t *l4, *l3, *l2;
-    unsigned long *l1;
-    int b1, b2, b3, b4;
-    int i2, i3, i4;
-
-    d->arch.paging.log_dirty.clean_dirty_bitmap(d);
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+    dv_range_t *range;
+    unsigned int range_dirty_count = 0;
+    
+    p2m_lock(p2m);
     paging_lock(d);
 
-    PAGING_DEBUG(LOGDIRTY, "log-dirty-range: dom %u faults=%u dirty=%u\n",
-                 d->domain_id,
-                 d->arch.paging.log_dirty.fault_count,
-                 d->arch.paging.log_dirty.dirty_count);
-
-    if ( unlikely(d->arch.paging.log_dirty.failed_allocs) ) {
-        printk("%s: %d failed page allocs while logging dirty pages\n",
-               __FUNCTION__, d->arch.paging.log_dirty.failed_allocs);
-        rv = -ENOMEM;
-        goto out;
-    }
-
-    if ( !d->arch.paging.log_dirty.fault_count &&
-         !d->arch.paging.log_dirty.dirty_count ) {
-        unsigned int size = BITS_TO_LONGS(nr);
-
-        if ( clear_guest(dirty_bitmap, size * BYTES_PER_LONG) != 0 )
-            rv = -EFAULT;
-        goto out;
-    }
-    d->arch.paging.log_dirty.fault_count = 0;
-    d->arch.paging.log_dirty.dirty_count = 0;
-
-    b1 = L1_LOGDIRTY_IDX(begin_pfn);
-    b2 = L2_LOGDIRTY_IDX(begin_pfn);
-    b3 = L3_LOGDIRTY_IDX(begin_pfn);
-    b4 = L4_LOGDIRTY_IDX(begin_pfn);
-    l4 = paging_map_log_dirty_bitmap(d);
-
-    for ( i4 = b4;
-          (pages < nr) && (i4 < LOGDIRTY_NODE_ENTRIES);
-          i4++ )
+    /* Only called when tracking dirty vram in HAP mode */
+    ASSERT(hap_enabled(d) && d->arch.hvm_domain.dirty_vram);
+    
+    range = dirty_vram_range_find_gfn(d, begin_pfn);
+    if (range)
     {
-        l3 = (l4 && mfn_valid(l4[i4])) ? map_domain_page(mfn_x(l4[i4])) : NULL;
-        for ( i3 = b3;
-              (pages < nr) && (i3 < LOGDIRTY_NODE_ENTRIES);
-              i3++ )
-        {
-            l2 = ((l3 && mfn_valid(l3[i3])) ?
-                  map_domain_page(mfn_x(l3[i3])) : NULL);
-            for ( i2 = b2;
-                  (pages < nr) && (i2 < LOGDIRTY_NODE_ENTRIES);
-                  i2++ )
-            {
-                unsigned int bytes = PAGE_SIZE;
-                uint8_t *s;
-                l1 = ((l2 && mfn_valid(l2[i2])) ?
-                      map_domain_page(mfn_x(l2[i2])) : NULL);
-
-                s = ((uint8_t*)l1) + (b1 >> 3);
-                bytes -= b1 >> 3;
-
-                if ( likely(((nr - pages + 7) >> 3) < bytes) )
-                    bytes = (unsigned int)((nr - pages + 7) >> 3);
-
-                if ( !l1 )
-                {
-                    if ( clear_guest_offset(dirty_bitmap, pages >> 3,
-                                            bytes) != 0 )
-                    {
-                        rv = -EFAULT;
-                        goto out;
-                    }
-                }
-                /* begin_pfn is not 32K aligned, hence we have to bit
-                 * shift the bitmap */
-                else if ( b1 & 0x7 )
-                {
-                    int i, j;
-                    uint32_t *l = (uint32_t*) s;
-                    int bits = b1 & 0x7;
-                    int bitmask = (1 << bits) - 1;
-                    int size = (bytes + BYTES_PER_LONG - 1) / BYTES_PER_LONG;
-                    unsigned long bitmap[size];
-                    static unsigned long printed = 0;
-
-                    if ( printed != begin_pfn )
-                    {
-                        dprintk(XENLOG_DEBUG, "%s: begin_pfn %lx is not 32K aligned!\n",
-                                __FUNCTION__, begin_pfn);
-                        printed = begin_pfn;
-                    }
-
-                    for ( i = 0; i < size - 1; i++, l++ ) {
-                        bitmap[i] = ((*l) >> bits) |
-                            (((*((uint8_t*)(l + 1))) & bitmask) << (sizeof(*l) * 8 - bits));
-                    }
-                    s = (uint8_t*) l;
-                    size = BYTES_PER_LONG - ((b1 >> 3) & 0x3);
-                    bitmap[i] = 0;
-                    for ( j = 0; j < size; j++, s++ )
-                        bitmap[i] |= (*s) << (j * 8);
-                    bitmap[i] = (bitmap[i] >> bits) | (bitmask << (size * 8 - bits));
-                    if ( copy_to_guest_offset(dirty_bitmap, (pages >> 3),
-                                (uint8_t*) bitmap, bytes) != 0 )
-                    {
-                        rv = -EFAULT;
-                        goto out;
-                    }
-                }
-                else
-                {
-                    if ( copy_to_guest_offset(dirty_bitmap, pages >> 3,
-                                              s, bytes) != 0 )
-                    {
-                        rv = -EFAULT;
-                        goto out;
-                    }
-                }
-
-                pages += bytes << 3;
-                if ( l1 )
-                {
-                    clear_page(l1);
-                    unmap_domain_page(l1);
-                }
-                b1 = b1 & 0x7;
-            }
-            b2 = 0;
-            if ( l2 )
-                unmap_domain_page(l2);
-        }
-        b3 = 0;
-        if ( l3 )
-            unmap_domain_page(l3);
+        range_dirty_count = range->dirty_count;
+        range->dirty_count = 0;
     }
-    if ( l4 )
-        unmap_domain_page(l4);
-
-    paging_unlock(d);
+    
+    if ( !range_dirty_count)
+        goto out;
 
-    return rv;
+    PAGING_DEBUG(LOGDIRTY, "log-dirty-range: dom %u [%05lx:%05lx] range_dirty=%u\n",
+                 d->domain_id,
+                 begin_pfn,
+                 range->end_pfn,
+                 range_dirty_count);
 
+    hap_clean_vram_tracking_range(d, begin_pfn, nr, dirty_bitmap);
  out:
     paging_unlock(d);
-    return rv;
+    p2m_unlock(p2m);
+    return;
 }
 
 /* Note that this function takes three function pointers. Callers must supply
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index 3f8ad88..c9f3495 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -36,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "private.h"
 
@@ -3121,12 +3122,7 @@ void shadow_teardown(struct domain *d)
      * calls now that we've torn down the bitmap */
     d->arch.paging.mode &= ~PG_log_dirty;
 
-    if (d->arch.hvm_domain.dirty_vram) {
-        xfree(d->arch.hvm_domain.dirty_vram->sl1ma);
-        xfree(d->arch.hvm_domain.dirty_vram->dirty_bitmap);
-        xfree(d->arch.hvm_domain.dirty_vram);
-        d->arch.hvm_domain.dirty_vram = NULL;
-    }
+    dirty_vram_free(d);
 
     paging_unlock(d);
 
@@ -3463,179 +3459,212 @@ void shadow_clean_dirty_bitmap(struct domain *d)
 
 
 /**************************************************************************/
-/* VRAM dirty tracking support */
-int shadow_track_dirty_vram(struct domain *d,
-                            unsigned long begin_pfn,
-                            unsigned long nr,
-                            XEN_GUEST_HANDLE_64(uint8) dirty_bitmap)
-{
-    int rc;
-    unsigned long end_pfn = begin_pfn + nr;
-    unsigned long dirty_size = (nr + 7) / 8;
-    int flush_tlb = 0;
-    unsigned long i;
-    p2m_type_t t;
-    struct sh_dirty_vram *dirty_vram = d->arch.hvm_domain.dirty_vram;
-    struct p2m_domain *p2m = p2m_get_hostp2m(d);
-
-    if (end_pfn < begin_pfn
-            || begin_pfn > p2m->max_mapped_pfn
-            || end_pfn >= p2m->max_mapped_pfn)
-        return -EINVAL;
-
-    /* We perform p2m lookups, so lock the p2m upfront to avoid deadlock */
-    p2m_lock(p2m_get_hostp2m(d));
-    paging_lock(d);
+/* Support functions for shadow-based dirty VRAM code */
 
-    if ( dirty_vram && (!nr ||
-             ( begin_pfn != dirty_vram->begin_pfn
-            || end_pfn   != dirty_vram->end_pfn )) )
-    {
-        /* Different tracking, tear the previous down. */
-        gdprintk(XENLOG_INFO, "stopping tracking VRAM %lx - %lx\n", dirty_vram->begin_pfn, dirty_vram->end_pfn);
-        xfree(dirty_vram->sl1ma);
-        xfree(dirty_vram->dirty_bitmap);
-        xfree(dirty_vram);
-        dirty_vram = d->arch.hvm_domain.dirty_vram = NULL;
-    }
+#define DEBUG_unshadow_sl1ma                  0          
+#define DEBUG_unshadow_sl1ma_detail           0
+#define DEBUG_count_initial_mappings          1
 
-    if ( !nr )
+/* smfn is no longer a shadow page.  Remove it from any
+ * dirty vram range mapping. */
+void
+dirty_vram_delete_shadow(struct vcpu *v,
+                         unsigned long gfn,
+                         unsigned int shadow_type, 
+                         mfn_t smfn)
+{
+    static unsigned int l1_shadow_mask = 
+          1 << SH_type_l1_32_shadow
+        | 1 << SH_type_fl1_32_shadow
+        | 1 << SH_type_l1_pae_shadow
+        | 1 << SH_type_fl1_pae_shadow
+        | 1 << SH_type_l1_64_shadow
+        | 1 << SH_type_fl1_64_shadow
+        ;
+    struct domain *d = v->domain;
+    dv_dirty_vram_t *dirty_vram;
+    struct list_head *curr, *next;
+    
+    ASSERT(paging_locked_by_me(d));
+    /* Ignore all but level 1 shadows */
+    
+    if ((l1_shadow_mask & (1 << shadow_type)) == 0)
     {
-        rc = 0;
         goto out;
     }
 
-    /* This should happen seldomly (Video mode change),
-     * no need to be careful. */
+    dirty_vram = d->arch.hvm_domain.dirty_vram;
     if ( !dirty_vram )
     {
-        /* Throw away all the shadows rather than walking through them 
-         * up to nr times getting rid of mappings of each pfn */
-        shadow_blow_tables(d);
-
-        gdprintk(XENLOG_INFO, "tracking VRAM %lx - %lx\n", begin_pfn, end_pfn);
-
-        rc = -ENOMEM;
-        if ( (dirty_vram = xmalloc(struct sh_dirty_vram)) == NULL )
-            goto out;
-        dirty_vram->begin_pfn = begin_pfn;
-        dirty_vram->end_pfn = end_pfn;
-        d->arch.hvm_domain.dirty_vram = dirty_vram;
-
-        if ( (dirty_vram->sl1ma = xmalloc_array(paddr_t, nr)) == NULL )
-            goto out_dirty_vram;
-        memset(dirty_vram->sl1ma, ~0, sizeof(paddr_t) * nr);
-
-        if ( (dirty_vram->dirty_bitmap = xzalloc_array(uint8_t, dirty_size)) == NULL )
-            goto out_sl1ma;
-
-        dirty_vram->last_dirty = NOW();
-
-        /* Tell the caller that this time we could not track dirty bits. */
-        rc = -ENODATA;
-    }
-    else if (dirty_vram->last_dirty == -1)
-    {
-        /* still completely clean, just copy our empty bitmap */
-        rc = -EFAULT;
-        if ( copy_to_guest(dirty_bitmap, dirty_vram->dirty_bitmap, dirty_size) == 0 )
-            rc = 0;
+        goto out;
     }
-    else
+        
+    list_for_each_safe(curr, next, &dirty_vram->range_head)
     {
-        /* Iterate over VRAM to track dirty bits. */
-        for ( i = 0; i < nr; i++ ) {
-            mfn_t mfn = get_gfn_query_unlocked(d, begin_pfn + i, &t);
-            struct page_info *page;
-            int dirty = 0;
-            paddr_t sl1ma = dirty_vram->sl1ma[i];
-
-            if (mfn_x(mfn) == INVALID_MFN)
-            {
-                dirty = 1;
-            }
-            else
+        dv_range_t *range = list_entry(curr, dv_range_t, range_link);
+        unsigned long i;
+        int max_mappings = 1, mappings = 0;
+        int unshadowed = 0;
+        for (i = 0; i != range->end_pfn - range->begin_pfn; i++)
+        {
+            dv_paddr_link_t *pl = &range->pl_tab[ i ];
+            dv_paddr_link_t **ppl = NULL;
+            mappings = 0;
+            
+            while (pl != NULL)
             {
-                page = mfn_to_page(mfn);
-                switch (page->u.inuse.type_info & PGT_count_mask)
-                {
-                case 0:
-                    /* No guest reference, nothing to track. */
-                    break;
-                case 1:
-                    /* One guest reference. */
-                    if ( sl1ma == INVALID_PADDR )
-                    {
-                        /* We don't know which sl1e points to this, too bad. */
-                        dirty = 1;
-                        /* TODO: Heuristics for finding the single mapping of
-                         * this gmfn */
-                        flush_tlb |= sh_remove_all_mappings(d->vcpu[0], mfn);
-                    }
-                    else
-                    {
-                        /* Hopefully the most common case: only one mapping,
-                         * whose dirty bit we can use. */
-                        l1_pgentry_t *sl1e = maddr_to_virt(sl1ma);
-
-                        if ( l1e_get_flags(*sl1e) & _PAGE_DIRTY )
-                        {
-                            dirty = 1;
-                            /* Note: this is atomic, so we may clear a
-                             * _PAGE_ACCESSED set by another processor. */
-                            l1e_remove_flags(*sl1e, _PAGE_DIRTY);
-                            flush_tlb = 1;
-                        }
-                    }
-                    break;
-                default:
-                    /* More than one guest reference,
-                     * we don't afford tracking that. */
-                    dirty = 1;
+                paddr_t sl1ma = pl->sl1ma;
+                unsigned long sl1mn;
+                
+                if (sl1ma == INVALID_PADDR )
                     break;
+                
+                sl1mn = sl1ma >> PAGE_SHIFT;
+                if (sl1mn == mfn_x(smfn)) {
+#if DEBUG_unshadow_sl1ma_detail
+                    gdprintk(XENLOG_DEBUG,
+                             "[%lx] gfn[%lx] unshadow sl1ma:%lx\n",
+                             mfn_x(smfn),
+                             range->begin_pfn + i,
+                             sl1ma);
+#endif
+                    unshadowed++;
+                    pl = free_paddr_link(d, ppl, pl);
+                    --range->nr_mappings;
+                }
+                else
+                {
+                    ppl = &pl->pl_next;
+                    pl = *ppl;
+                    mappings++;
                 }
             }
-
-            if ( dirty )
+        }
+        if (mappings > max_mappings)
+            max_mappings = mappings;
+        
+        if (unshadowed) {
+#if DEBUG_unshadow_sl1ma
+            gdprintk(XENLOG_DEBUG,
+                     "[%lx] gfn[%05lx:%05lx] unshadowed:%d mappings:0x%x max_mappings:%d\n",
+                     mfn_x(smfn),
+                     range->begin_pfn, range->end_pfn,
+                     unshadowed, range->nr_mappings, max_mappings);
+#endif
+            if ( range->nr_mappings == 0 )
             {
-                dirty_vram->dirty_bitmap[i / 8] |= 1 << (i % 8);
-                dirty_vram->last_dirty = NOW();
+                dirty_vram_range_free(d, range);                    
             }
         }
+    }
+ out:
+    return;
+}
+
+
+typedef int (*hash_pfn_callback_t)(struct vcpu *v,
+                                   mfn_t smfn,
+                                   unsigned long begin_pfn,
+                                   unsigned long end_pfn,
+                                   int *removed);
+
+static int hash_pfn_foreach(struct vcpu *v, 
+                            unsigned int callback_mask, 
+                            hash_pfn_callback_t callbacks[], 
+                            unsigned long begin_pfn,
+                            unsigned long end_pfn)
+/* Walk the hash table looking at the types of the entries and 
+ * calling the appropriate callback function for each entry. 
+ * The mask determines which shadow types we call back for, and the array
+ * of callbacks tells us which function to call.
+ * Any callback may return non-zero to let us skip the rest of the scan. 
+ *
+ * WARNING: Callbacks MUST NOT add or remove hash entries unless they 
+ * then return non-zero to terminate the scan. */
+{
+    int i, done = 0, removed = 0;
+    struct domain *d = v->domain;
+    struct page_info *x;
+
+    /* Say we're here, to stop hash-lookups reordering the chains */
+    ASSERT(paging_locked_by_me(d));
+    ASSERT(d->arch.paging.shadow.hash_walking == 0);
+    d->arch.paging.shadow.hash_walking = 1;
 
-        rc = -EFAULT;
-        if ( copy_to_guest(dirty_bitmap, dirty_vram->dirty_bitmap, dirty_size) == 0 ) {
-            memset(dirty_vram->dirty_bitmap, 0, dirty_size);
-            if (dirty_vram->last_dirty + SECONDS(2) < NOW())
+    for ( i = 0; i < SHADOW_HASH_BUCKETS; i++ ) 
+    {
+        /* WARNING: This is not safe against changes to the hash table.
+         * The callback *must* return non-zero if it has inserted or
+         * deleted anything from the hash (lookups are OK, though). */
+        for ( x = d->arch.paging.shadow.hash_table[i]; x; x = next_shadow(x) )
+        {
+            if ( callback_mask & (1 << x->u.sh.type) )
             {
-                /* was clean for more than two seconds, try to disable guest
-                 * write access */
-                for ( i = begin_pfn; i < end_pfn; i++ ) {
-                    mfn_t mfn = get_gfn_query_unlocked(d, i, &t);
-                    if (mfn_x(mfn) != INVALID_MFN)
-                        flush_tlb |= sh_remove_write_access(d->vcpu[0], mfn, 1, 0);
-                }
-                dirty_vram->last_dirty = -1;
+                ASSERT(x->u.sh.type <= 15);
+                ASSERT(callbacks[x->u.sh.type] != NULL);
+                done = callbacks[x->u.sh.type](v, page_to_mfn(x), 
+                                               begin_pfn, end_pfn,
+                                               &removed);
+                if ( done ) break;
             }
-            rc = 0;
         }
+        if ( done ) break; 
     }
-    if ( flush_tlb )
-        flush_tlb_mask(d->domain_dirty_cpumask);
-    goto out;
+    d->arch.paging.shadow.hash_walking = 0;
+    return removed;
+}
 
-out_sl1ma:
-    xfree(dirty_vram->sl1ma);
-out_dirty_vram:
-    xfree(dirty_vram);
-    dirty_vram = d->arch.hvm_domain.dirty_vram = NULL;
+void sh_find_all_vram_mappings(struct vcpu *v,
+                               dv_range_t *range)
+{
+    /* Dispatch table for getting per-type functions */
+    static hash_pfn_callback_t callbacks[SH_type_unused] = {
+        NULL, /* none    */
+        SHADOW_INTERNAL_NAME(sh_find_vram_mappings_in_l1, 2), /* l1_32   */
+        SHADOW_INTERNAL_NAME(sh_find_vram_mappings_in_l1, 2), /* fl1_32  */
+        NULL, /* l2_32   */
+        SHADOW_INTERNAL_NAME(sh_find_vram_mappings_in_l1, 3), /* l1_pae  */
+        SHADOW_INTERNAL_NAME(sh_find_vram_mappings_in_l1, 3), /* fl1_pae */
+        NULL, /* l2_pae  */
+        NULL, /* l2h_pae */
+#if CONFIG_PAGING_LEVELS >= 4
+        SHADOW_INTERNAL_NAME(sh_find_vram_mappings_in_l1, 4), /* l1_64   */
+        SHADOW_INTERNAL_NAME(sh_find_vram_mappings_in_l1, 4), /* fl1_64  */
+#else
+        NULL, /* l1_64   */
+        NULL, /* fl1_64  */
+#endif
+        NULL, /* l2_64   */
+        NULL, /* l2h_64  */
+        NULL, /* l3_64   */
+        NULL, /* l4_64   */
+        NULL, /* p2m     */
+        NULL  /* unused  */
+    };
 
-out:
-    paging_unlock(d);
-    p2m_unlock(p2m_get_hostp2m(d));
-    return rc;
+    static unsigned int callback_mask = 
+          1 << SH_type_l1_32_shadow
+        | 1 << SH_type_fl1_32_shadow
+        | 1 << SH_type_l1_pae_shadow
+        | 1 << SH_type_fl1_pae_shadow
+        | 1 << SH_type_l1_64_shadow
+        | 1 << SH_type_fl1_64_shadow
+        ;
+
+    perfc_incr(shadow_mappings);
+
+    hash_pfn_foreach(v, callback_mask, callbacks,
+                     range->begin_pfn,
+                     range->end_pfn);
+
+#if DEBUG_count_initial_mappings
+    gdprintk(XENLOG_DEBUG, "[%05lx:%05lx] count of initial mappings:%d\n",
+             range->begin_pfn, range->end_pfn,
+             range->nr_mappings);
+#endif
 }
 
+
 /**************************************************************************/
 /* Shadow-control XEN_DOMCTL dispatcher */
 
diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index b0e6d72..f4d0603 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -149,6 +150,10 @@ delete_fl1_shadow_status(struct vcpu *v, gfn_t gfn, mfn_t smfn)
     SHADOW_PRINTK("gfn=%"SH_PRI_gfn", type=%08x, smfn=%05lx\n",
                    gfn_x(gfn), SH_type_fl1_shadow, mfn_x(smfn));
     ASSERT(mfn_to_page(smfn)->u.sh.head);
+
+    /* Removing any dv_paddr_links to the erstwhile shadow page */
+    dirty_vram_delete_shadow(v, gfn_x(gfn), SH_type_fl1_shadow, smfn);
+    
     shadow_hash_delete(v, gfn_x(gfn), SH_type_fl1_shadow, smfn);
 }
 
@@ -160,6 +165,10 @@ delete_shadow_status(struct vcpu *v, mfn_t gmfn, u32 shadow_type, mfn_t smfn)
                    v->domain->domain_id, v->vcpu_id,
                    mfn_x(gmfn), shadow_type, mfn_x(smfn));
     ASSERT(mfn_to_page(smfn)->u.sh.head);
+    
+    /* Removing any dv_paddr_links to the erstwhile shadow page */
+    dirty_vram_delete_shadow(v, mfn_x(gmfn), shadow_type, smfn);
+    
     shadow_hash_delete(v, mfn_x(gmfn), shadow_type, smfn);
     /* 32-on-64 PV guests don't own their l4 pages; see set_shadow_status */
     if ( !is_pv_32on64_vcpu(v) || shadow_type != SH_type_l4_64_shadow )
@@ -516,7 +525,6 @@ _sh_propagate(struct vcpu *v,
     guest_l1e_t guest_entry = { guest_intpte };
     shadow_l1e_t *sp = shadow_entry_ptr;
     struct domain *d = v->domain;
-    struct sh_dirty_vram *dirty_vram = d->arch.hvm_domain.dirty_vram;
     gfn_t target_gfn = guest_l1e_get_gfn(guest_entry);
     u32 pass_thru_flags;
     u32 gflags, sflags;
@@ -663,17 +671,6 @@ _sh_propagate(struct vcpu *v,
         }
     }
 
-    if ( unlikely((level == 1) && dirty_vram
-            && dirty_vram->last_dirty == -1
-            && gfn_x(target_gfn) >= dirty_vram->begin_pfn
-            && gfn_x(target_gfn) < dirty_vram->end_pfn) )
-    {
-        if ( ft & FETCH_TYPE_WRITE )
-            dirty_vram->last_dirty = NOW();
-        else
-            sflags &= ~_PAGE_RW;
-    }
-
     /* Read-only memory */
     if ( p2m_is_readonly(p2mt) ||
          (p2mt == p2m_mmio_direct &&
@@ -1072,101 +1069,57 @@ static int shadow_set_l2e(struct vcpu *v,
     return flags;
 }
 
-static inline void shadow_vram_get_l1e(shadow_l1e_t new_sl1e,
+/* shadow_vram_fix_l1e()
+ * Testing L1PTEs as they are modified, look for when they start to (or cease to)
+ * point to frame buffer pages.  If the old and new gfns differ, calls
+ * dirty_vram_range_update() to updates the dirty_vram structures
+ */
+static inline void shadow_vram_fix_l1e(shadow_l1e_t old_sl1e,
+                                       shadow_l1e_t new_sl1e,
                                        shadow_l1e_t *sl1e,
                                        mfn_t sl1mfn,
                                        struct domain *d)
 { 
-    mfn_t mfn = shadow_l1e_get_mfn(new_sl1e);
-    int flags = shadow_l1e_get_flags(new_sl1e);
-    unsigned long gfn;
-    struct sh_dirty_vram *dirty_vram = d->arch.hvm_domain.dirty_vram;
+    mfn_t new_mfn, old_mfn;
+    unsigned long new_gfn = INVALID_M2P_ENTRY, old_gfn = INVALID_M2P_ENTRY;
+    paddr_t sl1ma;
+    dv_dirty_vram_t *dirty_vram = d->arch.hvm_domain.dirty_vram;
 
-    if ( !dirty_vram         /* tracking disabled? */
-         || !(flags & _PAGE_RW) /* read-only mapping? */
-         || !mfn_valid(mfn) )   /* mfn can be invalid in mmio_direct */
+    if ( !dirty_vram )
         return;
 
-    gfn = mfn_to_gfn(d, mfn);
-    /* Page sharing not supported on shadow PTs */
-    BUG_ON(SHARED_M2P(gfn));
+    sl1ma = pfn_to_paddr(mfn_x(sl1mfn)) | ((unsigned long)sl1e & ~PAGE_MASK);
 
-    if ( (gfn >= dirty_vram->begin_pfn) && (gfn < dirty_vram->end_pfn) )
+    old_mfn = shadow_l1e_get_mfn(old_sl1e);
+
+    if ( !sh_l1e_is_magic(old_sl1e) &&
+         (l1e_get_flags(old_sl1e) & _PAGE_PRESENT) &&
+         mfn_valid(old_mfn))
     {
-        unsigned long i = gfn - dirty_vram->begin_pfn;
-        struct page_info *page = mfn_to_page(mfn);
-        
-        if ( (page->u.inuse.type_info & PGT_count_mask) == 1 )
-            /* Initial guest reference, record it */
-            dirty_vram->sl1ma[i] = pfn_to_paddr(mfn_x(sl1mfn))
-                | ((unsigned long)sl1e & ~PAGE_MASK);
+        old_gfn = mfn_to_gfn(d, old_mfn);
     }
-}
-
-static inline void shadow_vram_put_l1e(shadow_l1e_t old_sl1e,
-                                       shadow_l1e_t *sl1e,
-                                       mfn_t sl1mfn,
-                                       struct domain *d)
-{
-    mfn_t mfn = shadow_l1e_get_mfn(old_sl1e);
-    int flags = shadow_l1e_get_flags(old_sl1e);
-    unsigned long gfn;
-    struct sh_dirty_vram *dirty_vram = d->arch.hvm_domain.dirty_vram;
-
-    if ( !dirty_vram         /* tracking disabled? */
-         || !(flags & _PAGE_RW) /* read-only mapping? */
-         || !mfn_valid(mfn) )   /* mfn can be invalid in mmio_direct */
-        return;
-
-    gfn = mfn_to_gfn(d, mfn);
-    /* Page sharing not supported on shadow PTs */
-    BUG_ON(SHARED_M2P(gfn));
-
-    if ( (gfn >= dirty_vram->begin_pfn) && (gfn < dirty_vram->end_pfn) )
+    
+    new_mfn = shadow_l1e_get_mfn(new_sl1e);
+    if ( !sh_l1e_is_magic(new_sl1e) &&
+         (l1e_get_flags(new_sl1e) & _PAGE_PRESENT) &&
+         mfn_valid(new_mfn))
     {
-        unsigned long i = gfn - dirty_vram->begin_pfn;
-        struct page_info *page = mfn_to_page(mfn);
-        int dirty = 0;
-        paddr_t sl1ma = pfn_to_paddr(mfn_x(sl1mfn))
-            | ((unsigned long)sl1e & ~PAGE_MASK);
+        new_gfn = mfn_to_gfn(d, new_mfn);
+    }
 
-        if ( (page->u.inuse.type_info & PGT_count_mask) == 1 )
-        {
-            /* Last reference */
-            if ( dirty_vram->sl1ma[i] == INVALID_PADDR ) {
-                /* We didn't know it was that one, let's say it is dirty */
-                dirty = 1;
-            }
-            else
-            {
-                ASSERT(dirty_vram->sl1ma[i] == sl1ma);
-                dirty_vram->sl1ma[i] = INVALID_PADDR;
-                if ( flags & _PAGE_DIRTY )
-                    dirty = 1;
-            }
-        }
-        else
+    if (old_gfn == new_gfn) return;
+
+    if (VALID_M2P(old_gfn))
+        if (dirty_vram_range_update(d, old_gfn, sl1ma, 0/*clear*/))
         {
-            /* We had more than one reference, just consider the page dirty. */
-            dirty = 1;
-            /* Check that it's not the one we recorded. */
-            if ( dirty_vram->sl1ma[i] == sl1ma )
-            {
-                /* Too bad, we remembered the wrong one... */
-                dirty_vram->sl1ma[i] = INVALID_PADDR;
-            }
-            else
-            {
-                /* Ok, our recorded sl1e is still pointing to this page, let's
-                 * just hope it will remain. */
-            }
+            SHADOW_PRINTK("gfn %lx (mfn %lx) cleared vram pte\n", old_gfn, mfn_x(old_mfn));
         }
-        if ( dirty )
+
+    if (VALID_M2P(new_gfn))
+        if (dirty_vram_range_update(d, new_gfn, sl1ma, 1/*set*/))
         {
-            dirty_vram->dirty_bitmap[i / 8] |= 1 << (i % 8);
-            dirty_vram->last_dirty = NOW();
+            SHADOW_PRINTK("gfn %lx (mfn %lx) set vram pte\n", new_gfn, mfn_x(new_mfn));
         }
-    }
 }
 
 static int shadow_set_l1e(struct vcpu *v, 
@@ -1211,12 +1164,14 @@ static int shadow_set_l1e(struct vcpu *v,
                 shadow_l1e_remove_flags(new_sl1e, _PAGE_RW);
                 /* fall through */
             case 0:
-                shadow_vram_get_l1e(new_sl1e, sl1e, sl1mfn, d);
+                shadow_vram_fix_l1e(old_sl1e, new_sl1e, sl1e, sl1mfn, d);
                 break;
             }
         }
     } 
 
+    shadow_vram_fix_l1e(old_sl1e, new_sl1e, sl1e, sl1mfn, d);
+
     /* Write the new entry */
     shadow_write_entries(sl1e, &new_sl1e, 1, sl1mfn);
     flags |= SHADOW_SET_CHANGED;
@@ -1231,7 +1186,6 @@ static int shadow_set_l1e(struct vcpu *v,
          * trigger a flush later. */
         if ( shadow_mode_refcounts(d) ) 
         {
-            shadow_vram_put_l1e(old_sl1e, sl1e, sl1mfn, d);
             shadow_put_page_from_l1e(old_sl1e, d);
             TRACE_SHADOW_PATH_FLAG(TRCE_SFLAG_SHADOW_L1_PUT_REF);
         } 
@@ -2018,7 +1972,6 @@ void sh_destroy_l1_shadow(struct vcpu *v, mfn_t smfn)
         SHADOW_FOREACH_L1E(sl1mfn, sl1e, 0, 0, {
             if ( (shadow_l1e_get_flags(*sl1e) & _PAGE_PRESENT)
                  && !sh_l1e_is_magic(*sl1e) ) {
-                shadow_vram_put_l1e(*sl1e, sl1e, sl1mfn, d);
                 shadow_put_page_from_l1e(*sl1e, d);
             }
         });
@@ -4336,6 +4289,34 @@ int sh_rm_mappings_from_l1(struct vcpu *v, mfn_t sl1mfn, mfn_t target_mfn)
     return done;
 }
 
+
+int sh_find_vram_mappings_in_l1(struct vcpu *v,
+                                mfn_t sl1mfn,
+                                unsigned long begin_pfn,
+                                unsigned long end_pfn,
+                                int *removed)
+/* Find all VRAM mappings in this shadow l1 table */
+{
+    struct domain *d = v->domain;
+    shadow_l1e_t *sl1e;
+    int done = 0;
+    
+    SHADOW_FOREACH_L1E(sl1mfn, sl1e, 0, done, /* only returns _PAGE_PRESENT entries */
+    {
+        unsigned long gfn;
+        mfn_t gmfn = shadow_l1e_get_mfn(*sl1e);
+        if (!mfn_valid(gmfn))
+            continue;
+        gfn = mfn_to_gfn(d, gmfn);
+        if (VALID_M2P(gfn) && (begin_pfn <= gfn) && (gfn < end_pfn)) 
+        {
+            paddr_t sl1ma = pfn_to_paddr(mfn_x(sl1mfn)) | ((unsigned long)sl1e & ~PAGE_MASK);
+            dirty_vram_range_update(v->domain, gfn, sl1ma, 1/*set*/);
+        }
+    });
+    return 0;
+}
+
 /**************************************************************************/
 /* Functions to excise all pointers to shadows from higher-level shadows. */
 
diff --git a/xen/arch/x86/mm/shadow/multi.h b/xen/arch/x86/mm/shadow/multi.h
index 835121e..436a4ac 100644
--- a/xen/arch/x86/mm/shadow/multi.h
+++ b/xen/arch/x86/mm/shadow/multi.h
@@ -66,7 +66,12 @@ SHADOW_INTERNAL_NAME(sh_rm_write_access_from_l1, GUEST_LEVELS)
 extern int
 SHADOW_INTERNAL_NAME(sh_rm_mappings_from_l1, GUEST_LEVELS)
     (struct vcpu *v, mfn_t sl1mfn, mfn_t target_mfn);
-
+extern int
+SHADOW_INTERNAL_NAME(sh_find_vram_mappings_in_l1, GUEST_LEVELS)
+     (struct vcpu *v, mfn_t sl1mfn, 
+      unsigned long begin_pfn,
+      unsigned long end_pfn,
+      int *removed);
 extern void
 SHADOW_INTERNAL_NAME(sh_clear_shadow_entry, GUEST_LEVELS)
     (struct vcpu *v, void *ep, mfn_t smfn);
diff --git a/xen/arch/x86/mm/shadow/types.h b/xen/arch/x86/mm/shadow/types.h
index 43ce1db..5b0f9f7 100644
--- a/xen/arch/x86/mm/shadow/types.h
+++ b/xen/arch/x86/mm/shadow/types.h
@@ -229,6 +229,7 @@ static inline shadow_l4e_t shadow_l4e_from_mfn(mfn_t mfn, u32 flags)
 #define sh_update_cr3              INTERNAL_NAME(sh_update_cr3)
 #define sh_rm_write_access_from_l1 INTERNAL_NAME(sh_rm_write_access_from_l1)
 #define sh_rm_mappings_from_l1     INTERNAL_NAME(sh_rm_mappings_from_l1)
+#define sh_find_vram_mappings_in_l1 INTERNAL_NAME(sh_find_vram_mappings_in_l1)
 #define sh_remove_l1_shadow        INTERNAL_NAME(sh_remove_l1_shadow)
 #define sh_remove_l2_shadow        INTERNAL_NAME(sh_remove_l2_shadow)
 #define sh_remove_l3_shadow        INTERNAL_NAME(sh_remove_l3_shadow)
diff --git a/xen/include/asm-x86/hap.h b/xen/include/asm-x86/hap.h
index a2532a4..82e20c7 100644
--- a/xen/include/asm-x86/hap.h
+++ b/xen/include/asm-x86/hap.h
@@ -57,10 +57,6 @@ void  hap_final_teardown(struct domain *d);
 void  hap_teardown(struct domain *d);
 void  hap_vcpu_init(struct vcpu *v);
 void  hap_logdirty_init(struct domain *d);
-int   hap_track_dirty_vram(struct domain *d,
-                           unsigned long begin_pfn,
-                           unsigned long nr,
-                           XEN_GUEST_HANDLE_64(uint8) dirty_bitmap);
 
 extern const struct paging_mode *hap_paging_get_mode(struct vcpu *);
 
diff --git a/xen/include/asm-x86/hvm/dirty_vram.h b/xen/include/asm-x86/hvm/dirty_vram.h
new file mode 100644
index 0000000..b8b92cc
--- /dev/null
+++ b/xen/include/asm-x86/hvm/dirty_vram.h
@@ -0,0 +1,157 @@
+/******************************************************************************
+ * include/asm-x86/hvm/dirty_vram.h
+ *
+ * Interface for tracking dirty VRAM pages
+ *
+ * Copyright (c) 2012 Citrix Systems, Inc. (Robert Phillips)
+ * Parts of this code are Copyright (c) 2006 by XenSource Inc.
+ * Parts of this code are Copyright (c) 2006 by Michael A Fetterman
+ * Parts based on earlier work by Michael A Fetterman, Ian Pratt et al.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+#ifndef _DIRTY_VRAM_H
+#define _DIRTY_VRAM_H
+
+/* In shadow mode we need to bookkeep all the L1 page table entries that
+ * map a frame buffer page.  Struct dv_paddr_link does this
+ * by recording the address of a L1 page table entry for some frame buffer page.
+ * Also has a link to additional pl entries if the frame buffer page
+ * has multiple mappings */
+typedef struct dv_paddr_link {
+    paddr_t sl1ma;
+    struct dv_paddr_link *pl_next;
+} dv_paddr_link_t;
+
+/* This defines an extension page of pl entries for FB pages with multiple
+ * mappings. All such pages (of a domain) are linked together. */
+typedef struct dv_paddr_link_ext {
+    struct list_head ext_link;
+    dv_paddr_link_t entries[(PAGE_SIZE-sizeof(struct list_head))/sizeof(dv_paddr_link_t)];
+} dv_paddr_link_ext_t;
+
+/* This defines a single frame buffer range.  It bookkeeps all the level 1 PTEs
+ * that map guest pages within that range.
+ * All such ranges (of a domain) are linked together. */
+typedef struct dv_range {
+    struct list_head range_link; /* the several ranges form a linked list */
+    unsigned long begin_pfn;
+    unsigned long end_pfn;
+    dv_paddr_link_t *pl_tab; /* table has 1 pl entry per pfn in range */
+    int nr_mappings;  /* total number of mappings in this range */
+    int mappings_hwm; /* high water mark of max mapping count */
+    unsigned int dirty_count;
+} dv_range_t;
+
+/* This contains all the data structures required by a domain to
+ * bookkeep the dirty pages within its frame buffers. */
+typedef struct dv_dirty_vram {
+    struct list_head range_head; /* head of the linked list of ranges */
+    struct list_head ext_head; /* head of list of extension pages */
+    dv_paddr_link_t *pl_free; /* free list of pl's within extension pages */
+    int nr_ranges; /* bookkeeps number of ranges */
+    int ranges_hwm; /* high water mark of max number of ranges */
+} dv_dirty_vram_t;
+
+/* Allocates domain's dirty_vram structure */
+dv_dirty_vram_t *
+dirty_vram_alloc(struct domain *d);
+
+/* Returns domain's dirty_vram structure,
+ * allocating it if necessary */
+dv_dirty_vram_t *
+dirty_vram_find_or_alloc(struct domain *d);
+
+/* Frees domain's dirty_vram structure */
+void dirty_vram_free(struct domain *d);
+
+/* Returns dirty vram range containing gfn, NULL if none */
+struct dv_range *
+dirty_vram_range_find_gfn(struct domain *d,
+                          unsigned long gfn);
+
+/* Returns dirty vram range matching [ begin_pfn .. begin_pfn+nr ), NULL if none */
+dv_range_t *
+dirty_vram_range_find(struct domain *d,
+                      unsigned long begin_pfn,
+                      unsigned long nr);
+
+/* Allocate dirty vram range containing [ begin_pfn .. begin_pfn+nr ),
+ * freeing any existing range that overlaps the new range. */
+dv_range_t *
+dirty_vram_range_alloc(struct domain *d,
+                       unsigned long begin_pfn,
+                       unsigned long nr);
+
+/* Returns dirty vram range matching [ begin_pfn .. begin_pfn+nr ),
+ * creating a range if none already exists and
+ * freeing any existing range that overlaps the new range. */
+dv_range_t *
+dirty_vram_range_find_or_alloc(struct domain *d,
+                               unsigned long begin_pfn,
+                               unsigned long nr);
+
+void dirty_vram_range_free(struct domain *d,
+                           dv_range_t *range);
+
+/* Bookkeep PTE address of a frame buffer page */
+int dirty_vram_range_update(struct domain *d,
+                            unsigned long gfn,
+                            paddr_t sl1ma,
+                            int set);
+
+/* smfn is no longer a shadow page.  Remove it from any
+ * dirty vram range mapping. */
+void
+dirty_vram_delete_shadow(struct vcpu *v,
+                         unsigned long gfn,
+                         unsigned int shadow_type, 
+                         mfn_t smfn);
+
+
+/* Scan all the L1 tables looking for VRAM mappings.
+ * Record them in the domain's dv_dirty_vram structure */
+void sh_find_all_vram_mappings(struct vcpu *v,
+                               dv_range_t *range);
+
+/* Free a paddr_link struct, given address of its
+ * predecessor in singly-linked list */
+dv_paddr_link_t *
+free_paddr_link(struct domain *d,
+                dv_paddr_link_t **ppl,
+                dv_paddr_link_t *pl);
+
+
+/* Enable VRAM dirty tracking. */
+int
+shadow_track_dirty_vram(struct domain *d,
+			unsigned long first_pfn,
+			unsigned long nr,
+			XEN_GUEST_HANDLE_64(uint8) dirty_bitmap);
+
+int
+hap_track_dirty_vram(struct domain *d,
+		     unsigned long begin_pfn,
+		     unsigned long nr,
+		     XEN_GUEST_HANDLE_64(uint8) dirty_bitmap);
+
+void
+hap_clean_vram_tracking_range(struct domain *d,
+			      unsigned long begin_pfn,
+			      unsigned long nr,
+			      uint8_t *dirty_bitmap);
+
+#endif /* _DIRTY_VRAM_H */
diff --git a/xen/include/asm-x86/hvm/domain.h b/xen/include/asm-x86/hvm/domain.h
index 27b3de5..6146542 100644
--- a/xen/include/asm-x86/hvm/domain.h
+++ b/xen/include/asm-x86/hvm/domain.h
@@ -74,7 +74,7 @@ struct hvm_domain {
     struct list_head       pinned_cacheattr_ranges;
 
     /* VRAM dirty support. */
-    struct sh_dirty_vram *dirty_vram;
+    struct dv_dirty_vram * dirty_vram;
 
     /* If one of vcpus of this domain is in no_fill_mode or
      * mtrr/pat between vcpus is not the same, set is_in_uc_mode
diff --git a/xen/include/asm-x86/paging.h b/xen/include/asm-x86/paging.h
index d9b6950..fba06b0 100644
--- a/xen/include/asm-x86/paging.h
+++ b/xen/include/asm-x86/paging.h
@@ -137,10 +137,10 @@ struct paging_mode {
 void paging_free_log_dirty_bitmap(struct domain *d);
 
 /* get the dirty bitmap for a specific range of pfns */
-int paging_log_dirty_range(struct domain *d,
-                           unsigned long begin_pfn,
-                           unsigned long nr,
-                           XEN_GUEST_HANDLE_64(uint8) dirty_bitmap);
+void paging_log_dirty_range(struct domain *d,
+                            unsigned long begin_pfn,
+                            unsigned long nr,
+                            uint8_t *dirty_bitmap);
 
 /* enable log dirty */
 int paging_log_dirty_enable(struct domain *d);
@@ -161,6 +161,11 @@ void paging_mark_dirty(struct domain *d, unsigned long guest_mfn);
  * This is called from inside paging code, with the paging lock held. */
 int paging_mfn_is_dirty(struct domain *d, mfn_t gmfn);
 
+/* mark a page as dirty, from hap page fault handler */
+void paging_mark_dirty_hap(struct domain *d,
+                           unsigned long pfn,
+                           unsigned long guest_mfn);
+
 /*
  * Log-dirty radix tree indexing:
  *   All tree nodes are PAGE_SIZE bytes, mapped on-demand.
@@ -183,15 +188,6 @@ int paging_mfn_is_dirty(struct domain *d, mfn_t gmfn);
 #define L4_LOGDIRTY_IDX(pfn) 0
 #endif
 
-/* VRAM dirty tracking support */
-struct sh_dirty_vram {
-    unsigned long begin_pfn;
-    unsigned long end_pfn;
-    paddr_t *sl1ma;
-    uint8_t *dirty_bitmap;
-    s_time_t last_dirty;
-};
-
 /*****************************************************************************
  * Entry points into the paging-assistance code */
 
diff --git a/xen/include/asm-x86/shadow.h b/xen/include/asm-x86/shadow.h
index 88a8cd2..bdb8dcd 100644
--- a/xen/include/asm-x86/shadow.h
+++ b/xen/include/asm-x86/shadow.h
@@ -62,12 +62,6 @@ void shadow_vcpu_init(struct vcpu *v);
 /* Enable an arbitrary shadow mode.  Call once at domain creation. */
 int shadow_enable(struct domain *d, u32 mode);
 
-/* Enable VRAM dirty bit tracking. */
-int shadow_track_dirty_vram(struct domain *d,
-                            unsigned long first_pfn,
-                            unsigned long nr,
-                            XEN_GUEST_HANDLE_64(uint8) dirty_bitmap);
-
 /* Handler for shadow control ops: operations from user-space to enable
  * and disable ephemeral shadow modes (test mode and log-dirty mode) and
  * manipulate the log-dirty bitmap. */
-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 18:15:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 18:15:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOBfp-0001YW-AG; Tue, 16 Oct 2012 18:15:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOBfn-0001YR-KY
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 18:15:24 +0000
Received: from [85.158.139.83:33324] by server-9.bemta-5.messagelabs.com id
	BA/83-23053-A34AD705; Tue, 16 Oct 2012 18:15:22 +0000
X-Env-Sender: robert.phillips@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1350411318!32944314!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzY3MTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3833 invoked from network); 16 Oct 2012 18:15:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 18:15:19 -0000
X-SBRS: None
X-MesageID: 41408342
X-Ironport-Server: ftlpip01.citrite.net
X-Remote-IP: 75.150.106.249
X-Policy: $Relay
X-IronPort-AV: E=Sophos;i="4.80,595,1344211200"; d="scan'208";a="41408342"
Received: from 75-150-106-249-newengland.hfc.comcastbusiness.net (HELO
	paine.oldroadcomputing.net) ([75.150.106.249])
	by SMTP.CITRIX.COM with ESMTP; 16 Oct 2012 18:15:16 +0000
From: Robert Phillips 
To: xen-devel@lists.xen.org
Date: Tue, 16 Oct 2012 14:15:02 -0400
Message-Id: <1350411302-5470-1-git-send-email-robert.phillips@citrix.com>
X-Mailer: git-send-email 1.7.9.5
Cc: Robert Phillips ,
	Robert Phillips 
Subject: [Xen-devel] [PATCH] Provide support for multiple frame buffers in
	Xen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Robert Phillips 

Support is provided for both shadow and hardware assisted paging (HAP) modes.
This code bookkeeps the set of video frame buffers (vram),
detects when the guest has modified any of those buffers and, upon request,
returns a bitmap of the modified pages.

This lets other software components re-paint the portions of the monitor (or monitors) that have changed.
Each monitor has a frame buffer of some size at some position in guest physical memory.
The set of frame buffers being tracked can change over time as monitors are plugged and unplugged.

Signed-Off-By: Robert Phillips 
---
 xen/arch/x86/hvm/Makefile            |    3 +-
 xen/arch/x86/hvm/dirty_vram.c        |  878 ++++++++++++++++++++++++++++++++++
 xen/arch/x86/hvm/hvm.c               |    4 +-
 xen/arch/x86/mm/hap/hap.c            |  140 +-----
 xen/arch/x86/mm/paging.c             |  232 ++++-----
 xen/arch/x86/mm/shadow/common.c      |  335 +++++++------
 xen/arch/x86/mm/shadow/multi.c       |  169 +++----
 xen/arch/x86/mm/shadow/multi.h       |    7 +-
 xen/arch/x86/mm/shadow/types.h       |    1 +
 xen/include/asm-x86/hap.h            |    4 -
 xen/include/asm-x86/hvm/dirty_vram.h |  157 ++++++
 xen/include/asm-x86/hvm/domain.h     |    2 +-
 xen/include/asm-x86/paging.h         |   22 +-
 xen/include/asm-x86/shadow.h         |    6 -
 14 files changed, 1403 insertions(+), 557 deletions(-)
 create mode 100644 xen/arch/x86/hvm/dirty_vram.c
 create mode 100644 xen/include/asm-x86/hvm/dirty_vram.h

diff --git a/xen/arch/x86/hvm/Makefile b/xen/arch/x86/hvm/Makefile
index eea5555..f37736b 100644
--- a/xen/arch/x86/hvm/Makefile
+++ b/xen/arch/x86/hvm/Makefile
@@ -2,6 +2,7 @@ subdir-y += svm
 subdir-y += vmx
 
 obj-y += asid.o
+obj-y += dirty_vram.o
 obj-y += emulate.o
 obj-y += hpet.o
 obj-y += hvm.o
@@ -22,4 +23,4 @@ obj-y += vlapic.o
 obj-y += vmsi.o
 obj-y += vpic.o
 obj-y += vpt.o
-obj-y += vpmu.o
\ No newline at end of file
+obj-y += vpmu.o
diff --git a/xen/arch/x86/hvm/dirty_vram.c b/xen/arch/x86/hvm/dirty_vram.c
new file mode 100644
index 0000000..22375c2
--- /dev/null
+++ b/xen/arch/x86/hvm/dirty_vram.c
@@ -0,0 +1,878 @@
+/*
+ * arch/x86/hvm/dirty_vram.c: Bookkeep/query dirty VRAM pages
+ * with support for multiple frame buffers.
+ *
+ * Copyright (c) 2012, Citrix Systems, Inc. (Robert Phillips)
+ * 
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; if not, write to the Free Software Foundation, Inc., 59 Temple
+ * Place - Suite 330, Boston, MA 02111-1307 USA.
+ */
+
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "../mm/mm-locks.h"
+
+#define DEBUG_stop_tracking_all_vram          1
+#define DEBUG_allocating_dirty_vram_range     1
+#define DEBUG_high_water_mark_for_vram_ranges 1
+#define DEBUG_freeing_dirty_vram_range        1
+#define DEBUG_allocate_paddr_links_page       0
+#define DEBUG_update_vram_mapping             0
+
+/* Allocates domain's dirty_vram structure */
+dv_dirty_vram_t *
+dirty_vram_alloc(struct domain *d)
+{
+    dv_dirty_vram_t *dirty_vram;
+    ASSERT( paging_locked_by_me(d) );
+    dirty_vram = d->arch.hvm_domain.dirty_vram = xmalloc(dv_dirty_vram_t);
+    if ( dirty_vram )
+    {
+        memset(dirty_vram, 0, sizeof(*dirty_vram));
+        INIT_LIST_HEAD(&dirty_vram->range_head);
+        INIT_LIST_HEAD(&dirty_vram->ext_head);
+    }
+    return dirty_vram;
+}
+
+/* Returns domain's dirty_vram structure,
+ * allocating it if necessary */
+dv_dirty_vram_t *
+dirty_vram_find_or_alloc(struct domain *d)
+{
+    dv_dirty_vram_t *dirty_vram = d->arch.hvm_domain.dirty_vram;
+    ASSERT( paging_locked_by_me(d) );
+    if ( !dirty_vram )
+        dirty_vram = dirty_vram_alloc(d);
+    return dirty_vram;
+}
+
+
+/* Free domain's dirty_vram structure */
+void dirty_vram_free(struct domain *d)
+{
+    dv_dirty_vram_t *dirty_vram = d->arch.hvm_domain.dirty_vram;
+    ASSERT( paging_locked_by_me(d) );
+    if ( dirty_vram )
+    {
+        struct list_head *curr, *next;
+        /* Free all the ranges */
+        list_for_each_safe(curr, next, &dirty_vram->range_head)
+        {
+            dv_range_t *range = list_entry(curr, dv_range_t, range_link);
+#if DEBUG_stop_tracking_all_vram
+            gdprintk(XENLOG_DEBUG, "[%05lx:%05lx] stop tracking all vram\n",
+                     range->begin_pfn, range->end_pfn);
+#endif
+            xfree(range->pl_tab);
+            xfree(range);
+        }
+        /* Free all the extension pages */
+        list_for_each_safe(curr, next, &dirty_vram->ext_head)
+        {
+            xfree(curr);            
+        }
+        xfree(dirty_vram);
+        d->arch.hvm_domain.dirty_vram = NULL;
+    }
+}
+
+/* Returns dirty vram range containing gfn, NULL if none */
+struct dv_range *
+dirty_vram_range_find_gfn(struct domain *d,
+                          unsigned long gfn)
+{
+    struct dv_dirty_vram *dirty_vram = d->arch.hvm_domain.dirty_vram;
+    ASSERT( paging_locked_by_me(d) );
+    if ( dirty_vram )
+    {
+        struct list_head *curr;
+        list_for_each(curr, &dirty_vram->range_head)
+        {
+            dv_range_t *range = list_entry(curr, dv_range_t, range_link);
+            if ( gfn >= range->begin_pfn &&
+                 gfn <  range->end_pfn )
+            {
+                return range;
+            }
+        }
+    }
+    return NULL;
+}
+
+/* Returns pointer to dirty vram range matching [begin_pfn .. end_pfn ), NULL if none. */
+dv_range_t *
+dirty_vram_range_find(struct domain *d,
+                      unsigned long begin_pfn,
+                      unsigned long nr)
+{
+    unsigned long end_pfn = begin_pfn + nr;
+    dv_dirty_vram_t *dirty_vram = d->arch.hvm_domain.dirty_vram;
+    ASSERT( paging_locked_by_me(d) );
+    if ( dirty_vram )
+    {
+        struct list_head *curr;
+        list_for_each(curr, &dirty_vram->range_head)
+        {
+            dv_range_t *range = list_entry(curr, dv_range_t, range_link);
+            if ( begin_pfn == range->begin_pfn &&
+                 end_pfn   == range->end_pfn )
+            {
+                return range;
+            }
+        }
+    }
+    return NULL;
+}
+
+/* Allocate specified dirty_vram range */
+static dv_range_t *
+_dirty_vram_range_alloc(struct domain *d,
+                        unsigned long begin_pfn,
+                        unsigned long nr)
+{
+    dv_dirty_vram_t *dirty_vram = d->arch.hvm_domain.dirty_vram;
+    dv_range_t *range = NULL;
+    unsigned long end_pfn = begin_pfn + nr;
+    dv_paddr_link_t *pl_tab = NULL;
+    int i;
+    
+    ASSERT( paging_locked_by_me(d) );
+    ASSERT( dirty_vram != NULL );
+    
+#if DEBUG_allocating_dirty_vram_range
+    gdprintk(XENLOG_DEBUG,
+             "[%05lx:%05lx] Allocating dirty vram range hap:%d\n",
+             begin_pfn, end_pfn,
+             d->arch.hvm_domain.hap_enabled);
+#endif
+    
+    range = xmalloc(dv_range_t);
+    if (range == NULL)
+        goto err_out;
+    
+    memset(range, 0, sizeof(dv_range_t));
+    INIT_LIST_HEAD(&range->range_link);
+    
+    range->begin_pfn = begin_pfn;
+    range->end_pfn = end_pfn;
+
+    if (!hap_enabled(d))
+    {
+        if ( (pl_tab = xmalloc_array(dv_paddr_link_t, nr)) == NULL )
+        {
+            goto err_out;
+        }
+        for (i = 0; i != nr; i++)
+        {
+            pl_tab[i].sl1ma = INVALID_PADDR;
+            pl_tab[i].pl_next = NULL;
+        }
+    }    
+    
+    range->pl_tab = pl_tab;
+    range->mappings_hwm = 1;
+
+    list_add(&range->range_link, &dirty_vram->range_head);
+    if ( ++dirty_vram->nr_ranges > dirty_vram->ranges_hwm )
+    {
+        dirty_vram->ranges_hwm = dirty_vram->nr_ranges;
+#if DEBUG_high_water_mark_for_vram_ranges
+        gdprintk(XENLOG_DEBUG,
+                 "High water mark for number of vram ranges is now:%d\n",
+                 dirty_vram->ranges_hwm);
+#endif
+    }
+    return range;
+    
+ err_out:
+    xfree(pl_tab);
+    xfree(range);
+    return NULL;
+}
+
+
+/* Frees specified dirty_vram range */
+void dirty_vram_range_free(struct domain *d,
+                           dv_range_t *range)
+{
+    dv_dirty_vram_t *dirty_vram = d->arch.hvm_domain.dirty_vram;
+    ASSERT( paging_locked_by_me(d) );
+    if ( dirty_vram )
+    {
+        int i, nr = range->end_pfn - range->begin_pfn;
+        
+#if DEBUG_freeing_dirty_vram_range
+        gdprintk(XENLOG_DEBUG,
+                 "[%05lx:%05lx] Freeing dirty vram range\n",
+                 range->begin_pfn, range->end_pfn);
+#endif
+        
+        if (range->pl_tab)
+        {
+            for (i = 0; i != nr; i++)
+            {
+                dv_paddr_link_t *plx;
+                plx = range->pl_tab[i].pl_next;
+                /* Does current FB page have multiple mappings? */
+                if (plx) /* yes */
+                {
+                    /* Find the last element in singly-linked list */
+                    while (plx->pl_next != NULL)
+                        plx = plx->pl_next;
+                    /* Prepend whole list to the free list */
+                    plx->pl_next = dirty_vram->pl_free;
+                    dirty_vram->pl_free = range->pl_tab[i].pl_next;
+                }
+            }
+            xfree(range->pl_tab);
+            range->pl_tab = NULL;
+        }
+        
+        /* Remove range from the linked list, free it, and adjust count*/
+        list_del(&range->range_link);
+        xfree(range);
+        dirty_vram->nr_ranges--;
+    }
+}
+
+/* dirty_vram_range_alloc()
+ * This function ensures that the new range does not overlap any existing
+ * ranges -- deleting them if necessary -- and then calls _dirty_vram_range_alloc
+ * to actually allocate the new range.
+ */
+dv_range_t *
+dirty_vram_range_alloc(struct domain *d,
+                        unsigned long begin_pfn,
+                        unsigned long nr)
+{
+    unsigned long end_pfn = begin_pfn + nr;
+    dv_dirty_vram_t *dirty_vram = d->arch.hvm_domain.dirty_vram;
+    dv_range_t *range;
+    struct list_head *curr, *next;
+    
+    ASSERT( paging_locked_by_me(d) );
+    ASSERT( dirty_vram != NULL );
+    
+    /* Ranges cannot overlap so
+     * free any range that overlaps [ begin_pfn .. end_pfn ) */
+    list_for_each_safe(curr, next, &dirty_vram->range_head)
+    {
+        dv_range_t *rng = list_entry(curr, dv_range_t, range_link);
+        if ( ((rng->begin_pfn <= begin_pfn) && (begin_pfn <  rng->end_pfn)) ||
+             ((begin_pfn <= rng->begin_pfn) && (rng->begin_pfn < end_pfn)) )
+        {
+            /* Different tracking, tear the previous down. */
+            dirty_vram_range_free(d, rng);
+        }
+    }
+        
+    range = _dirty_vram_range_alloc(d, begin_pfn, nr);
+    if ( !range )
+        goto out;
+
+ out:
+    return range;
+}
+
+/* dirty_vram_range_find_or_alloc()
+ * Find the range for [begin_pfn:begin_pfn+nr).
+ * If it doesn't exists, create it.
+ */
+dv_range_t *
+dirty_vram_range_find_or_alloc(struct domain *d,
+                                unsigned long begin_pfn,
+                                unsigned long nr)
+{
+    dv_range_t *range;
+    ASSERT( paging_locked_by_me(d) );
+    range = dirty_vram_range_find(d, begin_pfn, nr);
+    if ( !range )
+        range = dirty_vram_range_alloc(d, begin_pfn, nr);
+    return range;
+}
+
+
+
+/* Allocate a dv_paddr_link struct */
+static dv_paddr_link_t *
+alloc_paddr_link(struct domain *d)
+{
+    dv_paddr_link_t * pl = NULL;
+    dv_dirty_vram_t *dirty_vram = d->arch.hvm_domain.dirty_vram;
+    
+    ASSERT( paging_locked_by_me(d) );
+    BUILD_BUG_ON(sizeof(dv_paddr_link_ext_t) > PAGE_SIZE);
+    /* Is the list of free pl's empty? */
+    if (dirty_vram->pl_free == NULL) /* yes */
+    {
+        /* Allocate another page of pl's.
+         * Link them all together and point the free list head at them */
+        int i;
+        dv_paddr_link_ext_t *ext = xmalloc(dv_paddr_link_ext_t);
+        if (ext == NULL)
+            goto out;
+
+#if DEBUG_allocate_paddr_links_page
+        gdprintk(XENLOG_DEBUG, "Allocated another page of paddr_links\n");
+#endif
+        list_add(&ext->ext_link, &dirty_vram->ext_head);
+
+        /* initialize and link together the new pl entries */
+        for (i = 0; i != ARRAY_SIZE(ext->entries); i++)
+        {
+            ext->entries[i].sl1ma = INVALID_PADDR;
+            ext->entries[i].pl_next = &ext->entries[i+1];
+        }
+        ext->entries[ARRAY_SIZE(ext->entries) - 1].pl_next = NULL;
+        dirty_vram->pl_free = &ext->entries[0];
+    }
+    pl = dirty_vram->pl_free;
+    dirty_vram->pl_free = pl->pl_next;
+
+    pl->sl1ma = INVALID_PADDR;
+    pl->pl_next = NULL;
+ out:
+    return pl;
+}
+
+
+/* Free a paddr_link struct, given address of its predecessor in linked list */
+dv_paddr_link_t *
+free_paddr_link(struct domain *d,
+                dv_paddr_link_t **ppl,
+                dv_paddr_link_t *pl)
+{
+    dv_dirty_vram_t *dirty_vram = d->arch.hvm_domain.dirty_vram;
+    dv_paddr_link_t *npl; /* next pl */
+
+    ASSERT( paging_locked_by_me(d) );
+    /* extension mapping? */
+    if (ppl) /* yes. free it */
+    {
+        pl = (*ppl);
+        (*ppl) = npl = pl->pl_next;
+    }
+    else  /* main table */
+    {
+        /* move 2nd mapping to main table.
+         * and free 2nd mapping */
+        dv_paddr_link_t * spl;
+        spl = pl->pl_next;
+        if (spl == NULL)
+        {
+            pl->sl1ma = INVALID_PADDR;
+            return pl;
+        }
+        pl->sl1ma = spl->sl1ma;
+        pl->pl_next = spl->pl_next;
+        npl = pl; /* reprocess main table entry again */
+        pl = spl;
+    }
+    pl->sl1ma = INVALID_PADDR;
+    pl->pl_next = dirty_vram->pl_free;
+    dirty_vram->pl_free = pl;
+    return npl;
+}
+
+
+/* dirty_vram_range_update()
+ * This is called whenever a level 1 page table entry is modified.
+ * If the L1PTE is being cleared, the function removes any paddr_links
+ * that refer to it.
+ * If the L1PTE is being set to a frame buffer page, a paddr_link is
+ * created for that page's entry in pl_tab.
+ * Returns 1 iff entry found and set or cleared.
+ */
+int dirty_vram_range_update(struct domain *d,
+                            unsigned long gfn,
+                            paddr_t sl1ma,
+                            int set)
+{
+    int effective = 0;
+    dv_range_t *range;
+
+    ASSERT(paging_locked_by_me(d));
+    range = dirty_vram_range_find_gfn(d, gfn);
+    if ( range )
+    {
+        unsigned long i = gfn - range->begin_pfn;
+        dv_paddr_link_t *pl = &range->pl_tab[ i ];
+        dv_paddr_link_t **ppl = NULL;
+        int len = 0;
+
+        /* find matching entry (pl), if any, and its predecessor
+         * in linked list (ppl) */
+        while (pl != NULL)
+        {
+            if (pl->sl1ma == sl1ma || pl->sl1ma == INVALID_PADDR )
+                break;
+            ppl = &pl->pl_next;
+            pl = *ppl;
+            len++;
+        }
+            
+        if (set)
+        {
+            /* Did we find sl1ma in either the main table or the linked list? */
+            if (pl == NULL) /* no, so we'll need to alloc a link */
+            {
+                ASSERT(ppl != NULL);
+                /* alloc link and append it to list */
+                (*ppl) = pl = alloc_paddr_link(d);
+                if (pl == NULL)
+                    goto out;
+            }
+            if ( pl->sl1ma != sl1ma )
+            {
+                pl->sl1ma = sl1ma;
+                range->nr_mappings++;
+            }
+            effective = 1;
+            if (len > range->mappings_hwm)
+            {
+                range->mappings_hwm = len;
+#if DEBUG_update_vram_mapping
+                gdprintk(XENLOG_DEBUG,
+                         "[%lx] set      sl1ma:%lx hwm:%d mappings:%d freepages:%d\n",
+                         gfn, sl1ma,
+                         range->mappings_hwm,
+                         range->nr_mappings,
+                         d->arch.paging.shadow.free_pages);
+#endif
+            }
+        }
+        else /* clear */
+        {
+            if (pl && pl->sl1ma == sl1ma )
+            {
+#if DEBUG_update_vram_mapping
+                gdprintk(XENLOG_DEBUG,
+                         "[%lx] clear    sl1ma:%lx mappings:%d\n",
+                         gfn, sl1ma,
+                         range->nr_mappings-1);
+#endif
+                free_paddr_link(d, ppl, pl);
+                if ( --range->nr_mappings == 0 )
+                {
+                    dirty_vram_range_free(d, range);
+                }
+                effective = 1;
+            }
+        }
+    }
+ out:
+    return effective;
+}
+
+
+/* shadow_scan_dirty_flags()
+ * This produces a dirty bitmap for the range by examining every
+ * L1PTE referenced by some dv_paddr_link in the range's pl_tab table.
+ * It tests and clears each such L1PTE's dirty flag.
+ */
+static int shadow_scan_dirty_flags(struct domain *d,
+                                   dv_range_t *range,
+                                   uint8_t *dirty_bitmap)
+{
+    int flush_tlb = 0;
+    unsigned long i;
+    unsigned long nr = range->end_pfn - range->begin_pfn;
+#ifdef __i386__
+    unsigned long map_mfn = INVALID_MFN;
+    void *map_sl1p = NULL;
+#endif
+
+    ASSERT( paging_locked_by_me(d) );
+    /* Iterate over VRAM to track dirty bits. */
+    for ( i = 0; i < nr; i++ )
+    {
+        int dirty = 0, len = 1;
+        dv_paddr_link_t *pl;
+        for (pl = &range->pl_tab[i]; pl; pl = pl->pl_next, len++)
+        {
+#ifdef __i386__
+            void *sl1p;
+            unsigned long sl1mfn;
+#endif
+            l1_pgentry_t *sl1e;
+            paddr_t sl1ma = pl->sl1ma;
+            if (sl1ma == INVALID_PADDR) /* FB page is unmapped */
+                continue;
+#ifdef __i386__
+            sl1p = map_sl1p;
+            sl1mfn = paddr_to_pfn(sl1ma);
+
+            if ( sl1mfn != map_mfn )
+            {
+                if ( map_sl1p )
+                    sh_unmap_domain_page(map_sl1p);
+                map_sl1p = sl1p = sh_map_domain_page(_mfn(sl1mfn));
+                map_mfn = sl1mfn;
+            }
+            sl1e = sl1p + (sl1ma & ~PAGE_MASK);
+#else
+            sl1e = maddr_to_virt(sl1ma);
+#endif
+            if ( l1e_get_flags(*sl1e) & _PAGE_DIRTY )
+            {
+                dirty = 1;
+                /* Clear dirty so we can detect if page gets re-dirtied */
+                /* Note: this is atomic, so we may clear a
+                 * _PAGE_ACCESSED set by another processor. */
+                l1e_remove_flags(*sl1e, _PAGE_DIRTY);
+                flush_tlb = 1;
+            }
+        } /* for */
+        if ( dirty )
+        {
+            dirty_bitmap[i >> 3] |= (1 << (i & 7));
+        }
+    }
+
+#ifdef __i386__
+    if ( map_sl1p )
+        sh_unmap_domain_page(map_sl1p);
+#endif
+    return flush_tlb;
+}
+
+
+/* shadow_track_dirty_vram()
+ * This is the API called by the guest to determine which pages in the range
+ * from [begin_pfn:begin_pfn+nr) have been dirtied since the last call.
+ * It creates the domain's dv_dirty_vram on demand. 
+ * It creates ranges on demand when some [begin_pfn:nr) is first encountered.
+ * To collect the dirty bitmask it calls shadow_scan_dirty_flags().
+ * It copies the dirty bitmask into guest storage.
+ */
+int shadow_track_dirty_vram(struct domain *d,
+                            unsigned long begin_pfn,
+                            unsigned long nr,
+                            XEN_GUEST_HANDLE_64(uint8) guest_dirty_bitmap)
+{
+    int rc = 0;
+    unsigned long end_pfn = begin_pfn + nr;
+    int flush_tlb = 0;
+    dv_range_t *range;
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+
+    if (end_pfn < begin_pfn
+            || begin_pfn > p2m->max_mapped_pfn
+            || end_pfn >= p2m->max_mapped_pfn)
+        return -EINVAL;
+
+    paging_lock(d);
+
+    if ( !nr || guest_handle_is_null(guest_dirty_bitmap) )
+    {
+        goto out;
+    }
+
+    if ( !dirty_vram_find_or_alloc(d))
+    {
+        rc = -ENOMEM;
+        goto out;
+    }
+    
+    range = dirty_vram_range_find(d, begin_pfn, nr);
+    if ( !range )
+    {
+        range = dirty_vram_range_alloc(d, begin_pfn, nr);
+        if ( range )    
+            sh_find_all_vram_mappings(d->vcpu[0], range);
+    }
+    if ( range )
+    {
+        int size = (nr + BITS_PER_LONG - 1) / BITS_PER_LONG;
+        unsigned long dirty_bitmap[size];
+        
+        memset(dirty_bitmap, 0x00, size * BYTES_PER_LONG);
+
+	flush_tlb |= shadow_scan_dirty_flags(d, range, (uint8_t*)dirty_bitmap);
+        
+        rc = -EFAULT;
+        if ( copy_to_guest(guest_dirty_bitmap,
+                           (uint8_t*)dirty_bitmap,
+                           size * BYTES_PER_LONG) == 0 )
+            rc = 0;
+    }
+    if ( flush_tlb )
+        flush_tlb_mask(d->domain_dirty_cpumask);
+
+out:
+    paging_unlock(d);
+    return rc;
+}
+
+
+/************************************************/
+/*          HAP VRAM TRACKING SUPPORT           */
+/************************************************/
+
+/* hap_enable_vram_tracking()
+ * For all ranges, mark all vram pages in range as logdirty read-only.
+ */
+static int hap_enable_vram_tracking(struct domain *d)
+{
+    int rc = 0;
+    dv_dirty_vram_t *dirty_vram;
+    struct list_head *curr;
+
+    /* turn on PG_log_dirty bit in paging mode */
+    paging_lock(d);
+    d->arch.paging.mode |= PG_log_dirty;
+    paging_unlock(d);
+
+    p2m_lock(p2m_get_hostp2m(d));
+    paging_lock(d);
+    
+    dirty_vram = d->arch.hvm_domain.dirty_vram;
+
+    /* dirty_vram != NULL iff we're tracking dirty vram.
+     * If we start tracking dirty pages for all memory then
+     * the dirty_vram structure is freed. */
+    if ( !dirty_vram )
+    {
+        rc = -EINVAL;
+        goto out;
+    }
+
+    /* set l1e entries of P2M table to be read-only. */
+    list_for_each(curr, &dirty_vram->range_head)
+      {
+	dv_range_t *range = list_entry(curr, dv_range_t, range_link);
+	gdprintk(XENLOG_DEBUG, "[%05lx:%05lx] enable  vram tracking\n",
+		 range->begin_pfn, range->end_pfn);
+	p2m_change_type_range(d, range->begin_pfn, range->end_pfn, 
+			      p2m_ram_rw, p2m_ram_logdirty);
+      }
+        
+    flush_tlb_mask(d->domain_dirty_cpumask);
+ out:
+    paging_unlock(d);
+    p2m_unlock(p2m_get_hostp2m(d));
+    if (rc) 
+    {
+        paging_lock(d);
+        d->arch.paging.mode &= ~PG_log_dirty;
+        paging_unlock(d);
+    }
+    return rc;
+}
+
+/* hap_disable_vram_tracking()
+ * For all ranges, mark all vram pages in range as logdirty read-write.
+ */
+static int hap_disable_vram_tracking(struct domain *d)
+{
+    int rc = 0;
+    dv_dirty_vram_t *dirty_vram;
+    struct list_head *curr;
+
+    paging_lock(d);
+    d->arch.paging.mode &= ~PG_log_dirty;
+    paging_unlock(d);
+
+    p2m_lock(p2m_get_hostp2m(d));
+    paging_lock(d);
+    
+    dirty_vram = d->arch.hvm_domain.dirty_vram;
+    if ( !dirty_vram )
+    {
+        rc = -EINVAL;
+        goto out;
+    }
+    
+    /* set l1e entries of P2M table with normal mode */
+    list_for_each(curr, &dirty_vram->range_head)
+      {
+	dv_range_t *range = list_entry(curr, dv_range_t, range_link);
+	gdprintk(XENLOG_DEBUG, "[%05lx:%05lx] disable vram tracking\n",
+		 range->begin_pfn, range->end_pfn);
+	p2m_change_type_range(d, range->begin_pfn, range->end_pfn, 
+			      p2m_ram_logdirty, p2m_ram_rw);
+      }
+    flush_tlb_mask(d->domain_dirty_cpumask);
+ out:
+    paging_unlock(d);
+    p2m_unlock(p2m_get_hostp2m(d));
+    if (rc) 
+    {
+        paging_lock(d);
+        d->arch.paging.mode |= PG_log_dirty;
+        paging_unlock(d);
+    }
+    return rc;
+}
+
+/* hap_clean_vram_tracking_range()
+ * For all the pages in the range specified by [begin_pfn,nr),
+ * note in the dirty bitmap any page that has been marked as read-write,
+ * which signifies that the page has been dirtied, and reset the page
+ * to ram_logdirty. 
+ */
+void hap_clean_vram_tracking_range(struct domain *d,
+                                   unsigned long begin_pfn,
+                                   unsigned long nr,
+                                   uint8_t *dirty_bitmap)
+{
+    int i;
+    unsigned long pfn;
+    dv_dirty_vram_t *dirty_vram = d->arch.hvm_domain.dirty_vram;
+    dv_range_t *range;
+
+    ASSERT(p2m_locked_by_me(p2m_get_hostp2m(d)));
+    ASSERT(paging_locked_by_me(d));
+    
+    if ( !dirty_vram )
+    {
+        gdprintk(XENLOG_DEBUG, "Should only be called while tracking dirty vram.\n");
+        return;
+    }
+
+    range = dirty_vram_range_find(d, begin_pfn, nr);
+    if (!range)
+        return;
+
+    /* set l1e entries of P2M table to be read-only. */
+    /* On first write, it page faults, its entry is changed to read-write,
+     * its bit in the dirty bitmap is set, and on retry the write succeeds. */
+    for (i = 0, pfn = range->begin_pfn; pfn < range->end_pfn; i++, pfn++)
+    {
+        p2m_type_t pt;
+        pt = p2m_change_type(d, pfn, p2m_ram_rw, p2m_ram_logdirty);
+        if (pt == p2m_ram_rw)
+            dirty_bitmap[i >> 3] |= (1 << (i & 7));
+    }
+    flush_tlb_mask(d->domain_dirty_cpumask);
+}
+
+static void hap_vram_tracking_init(struct domain *d)
+{
+    paging_log_dirty_init(d, hap_enable_vram_tracking,
+                          hap_disable_vram_tracking,
+                          NULL);
+}
+
+/* hap_track_dirty_vram()
+ * Create the domain's dv_dirty_vram struct on demand.
+ * Create a dirty vram range on demand when some [begin_pfn:begin_pfn+nr] is first encountered.
+ * Collect the guest_dirty bitmask, a bit mask of the dirties vram pages, by
+ * calling paging_log_dirty_range().
+ */
+int hap_track_dirty_vram(struct domain *d,
+                         unsigned long begin_pfn,
+                         unsigned long nr,
+                         XEN_GUEST_HANDLE_64(uint8) guest_dirty_bitmap)
+{
+    long rc = 0;
+    dv_dirty_vram_t *dirty_vram;
+    int restart_log_dirty = 0;
+
+    paging_lock(d);
+    dirty_vram = d->arch.hvm_domain.dirty_vram;
+    if ( nr )
+    {
+        dv_range_t *range = NULL;
+        int size = (nr + BITS_PER_LONG - 1) / BITS_PER_LONG;
+        unsigned long dirty_bitmap[size];
+
+        /* Already tracking dirty vram? */
+        if ( paging_mode_log_dirty(d) && dirty_vram ) /* yes */
+        {
+            /* Handle the addition of another range */
+            range = dirty_vram_range_find(d, begin_pfn, nr);
+            if ( !range )
+            {
+                rc = -ENOMEM;
+                if ( !(range = dirty_vram_range_alloc(d, begin_pfn, nr)) )
+                    goto param_fail;
+                restart_log_dirty = 1;
+            }
+        }
+        /* Just starting to track dirty vram? */
+        else if ( !paging_mode_log_dirty(d) && !dirty_vram ) /* yes */
+        {
+            rc = -ENOMEM;
+            if ( !(dirty_vram = dirty_vram_alloc(d)) )
+                goto param_fail;
+            
+            if ( !(range = dirty_vram_range_find_or_alloc(d, begin_pfn, nr)) )
+                goto param_fail;
+
+            restart_log_dirty = 1;
+            /* Initialize callbacks for vram tracking */
+            hap_vram_tracking_init(d);
+        }
+        else
+        {
+            /* Test for invalid combination */
+            if ( !paging_mode_log_dirty(d) && dirty_vram )
+                rc = -EINVAL;
+            else /* logging dirty of all memory, not tracking dirty vram */
+                rc = -ENODATA;
+            goto param_fail;
+        }
+        
+        if (restart_log_dirty) 
+        {
+            /* disable then enable log dirty */
+            paging_unlock(d);
+            if (paging_mode_log_dirty(d))
+                paging_log_dirty_disable(d);
+                    
+            rc = paging_log_dirty_enable(d);
+            paging_lock(d);
+            if (rc != 0)
+                goto param_fail;
+        }
+        
+        paging_unlock(d);
+        memset(dirty_bitmap, 0x00, size * BYTES_PER_LONG);
+	paging_log_dirty_range(d, begin_pfn, nr, (uint8_t*)dirty_bitmap);
+        rc = -EFAULT;
+        if ( copy_to_guest(guest_dirty_bitmap,
+                           (uint8_t*)dirty_bitmap,
+                           size * BYTES_PER_LONG) == 0 )
+        {
+            rc = 0;
+        }
+    }
+    else
+    {
+        /* If zero pages specified while already tracking dirty vram
+         * then stop tracking */
+        if ( paging_mode_log_dirty(d) && dirty_vram ) {
+            paging_unlock(d);
+            rc = paging_log_dirty_disable(d);
+            paging_lock(d);
+            dirty_vram_free(d);
+        } else /* benign no-op */
+        {
+            rc = 0;
+        }
+        paging_unlock(d);
+    }
+
+    return rc;
+
+param_fail:
+    dirty_vram_free(d);
+    paging_unlock(d);
+    return rc;
+}
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index a5a1bcf..55553e4 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -57,6 +57,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1433,8 +1434,7 @@ int hvm_hap_nested_page_fault(paddr_t gpa,
          */
         if ( access_w )
         {
-            paging_mark_dirty(v->domain, mfn_x(mfn));
-            p2m_change_type(v->domain, gfn, p2m_ram_logdirty, p2m_ram_rw);
+            paging_mark_dirty_hap(v->domain, gfn, mfn_x(mfn));
         }
         rc = 1;
         goto out_put_gfn;
diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index d2637d3..f31e4e5 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -41,6 +41,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "private.h"
 
@@ -53,139 +54,6 @@
 #define page_to_mfn(_pg) _mfn(__page_to_mfn(_pg))
 
 /************************************************/
-/*          HAP VRAM TRACKING SUPPORT           */
-/************************************************/
-
-static int hap_enable_vram_tracking(struct domain *d)
-{
-    struct sh_dirty_vram *dirty_vram = d->arch.hvm_domain.dirty_vram;
-
-    if ( !dirty_vram )
-        return -EINVAL;
-
-    /* turn on PG_log_dirty bit in paging mode */
-    paging_lock(d);
-    d->arch.paging.mode |= PG_log_dirty;
-    paging_unlock(d);
-
-    /* set l1e entries of P2M table to be read-only. */
-    p2m_change_type_range(d, dirty_vram->begin_pfn, dirty_vram->end_pfn, 
-                          p2m_ram_rw, p2m_ram_logdirty);
-
-    flush_tlb_mask(d->domain_dirty_cpumask);
-    return 0;
-}
-
-static int hap_disable_vram_tracking(struct domain *d)
-{
-    struct sh_dirty_vram *dirty_vram = d->arch.hvm_domain.dirty_vram;
-
-    if ( !dirty_vram )
-        return -EINVAL;
-
-    paging_lock(d);
-    d->arch.paging.mode &= ~PG_log_dirty;
-    paging_unlock(d);
-
-    /* set l1e entries of P2M table with normal mode */
-    p2m_change_type_range(d, dirty_vram->begin_pfn, dirty_vram->end_pfn, 
-                          p2m_ram_logdirty, p2m_ram_rw);
-
-    flush_tlb_mask(d->domain_dirty_cpumask);
-    return 0;
-}
-
-static void hap_clean_vram_tracking(struct domain *d)
-{
-    struct sh_dirty_vram *dirty_vram = d->arch.hvm_domain.dirty_vram;
-
-    if ( !dirty_vram )
-        return;
-
-    /* set l1e entries of P2M table to be read-only. */
-    p2m_change_type_range(d, dirty_vram->begin_pfn, dirty_vram->end_pfn, 
-                          p2m_ram_rw, p2m_ram_logdirty);
-
-    flush_tlb_mask(d->domain_dirty_cpumask);
-}
-
-static void hap_vram_tracking_init(struct domain *d)
-{
-    paging_log_dirty_init(d, hap_enable_vram_tracking,
-                          hap_disable_vram_tracking,
-                          hap_clean_vram_tracking);
-}
-
-int hap_track_dirty_vram(struct domain *d,
-                         unsigned long begin_pfn,
-                         unsigned long nr,
-                         XEN_GUEST_HANDLE_64(uint8) dirty_bitmap)
-{
-    long rc = 0;
-    struct sh_dirty_vram *dirty_vram = d->arch.hvm_domain.dirty_vram;
-
-    if ( nr )
-    {
-        if ( paging_mode_log_dirty(d) && dirty_vram )
-        {
-            if ( begin_pfn != dirty_vram->begin_pfn ||
-                 begin_pfn + nr != dirty_vram->end_pfn )
-            {
-                paging_log_dirty_disable(d);
-                dirty_vram->begin_pfn = begin_pfn;
-                dirty_vram->end_pfn = begin_pfn + nr;
-                rc = paging_log_dirty_enable(d);
-                if (rc != 0)
-                    goto param_fail;
-            }
-        }
-        else if ( !paging_mode_log_dirty(d) && !dirty_vram )
-        {
-            rc = -ENOMEM;
-            if ( (dirty_vram = xmalloc(struct sh_dirty_vram)) == NULL )
-                goto param_fail;
-
-            dirty_vram->begin_pfn = begin_pfn;
-            dirty_vram->end_pfn = begin_pfn + nr;
-            d->arch.hvm_domain.dirty_vram = dirty_vram;
-            hap_vram_tracking_init(d);
-            rc = paging_log_dirty_enable(d);
-            if (rc != 0)
-                goto param_fail;
-        }
-        else
-        {
-            if ( !paging_mode_log_dirty(d) && dirty_vram )
-                rc = -EINVAL;
-            else
-                rc = -ENODATA;
-            goto param_fail;
-        }
-        /* get the bitmap */
-        rc = paging_log_dirty_range(d, begin_pfn, nr, dirty_bitmap);
-    }
-    else
-    {
-        if ( paging_mode_log_dirty(d) && dirty_vram ) {
-            rc = paging_log_dirty_disable(d);
-            xfree(dirty_vram);
-            dirty_vram = d->arch.hvm_domain.dirty_vram = NULL;
-        } else
-            rc = 0;
-    }
-
-    return rc;
-
-param_fail:
-    if ( dirty_vram )
-    {
-        xfree(dirty_vram);
-        dirty_vram = d->arch.hvm_domain.dirty_vram = NULL;
-    }
-    return rc;
-}
-
-/************************************************/
 /*            HAP LOG DIRTY SUPPORT             */
 /************************************************/
 
@@ -223,14 +91,12 @@ static void hap_clean_dirty_bitmap(struct domain *d)
 
 void hap_logdirty_init(struct domain *d)
 {
-    struct sh_dirty_vram *dirty_vram = d->arch.hvm_domain.dirty_vram;
+    struct dv_dirty_vram *dirty_vram = d->arch.hvm_domain.dirty_vram;
     if ( paging_mode_log_dirty(d) && dirty_vram )
     {
         paging_log_dirty_disable(d);
-        xfree(dirty_vram);
-        dirty_vram = d->arch.hvm_domain.dirty_vram = NULL;
+        dirty_vram_free(d);
     }
-
     /* Reinitialize logdirty mechanism */
     paging_log_dirty_init(d, hap_enable_log_dirty,
                           hap_disable_log_dirty,
diff --git a/xen/arch/x86/mm/paging.c b/xen/arch/x86/mm/paging.c
index ca879f9..7464b07 100644
--- a/xen/arch/x86/mm/paging.c
+++ b/xen/arch/x86/mm/paging.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -278,6 +279,46 @@ out:
 }
 
 
+/* paging_mark_dirty_hap()
+ * Make a hap page writeable and mark it as dirty.
+ * This done atomically under the p2m and paging locks to avoid leaving
+ * a window where the page might be modified without being marked as dirty.
+ */
+void paging_mark_dirty_hap(struct domain *d,
+                           unsigned long pfn,
+                           unsigned long guest_mfn)
+{
+    mfn_t gmfn;
+    p2m_type_t pt;
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+    
+    if ( !paging_mode_log_dirty(d) )
+        return;
+
+    gmfn = _mfn(guest_mfn);
+
+    ASSERT( mfn_valid(gmfn) &&
+            page_get_owner(mfn_to_page(gmfn)) == d );
+
+    p2m_lock(p2m);
+    pt = p2m_change_type(d, pfn, p2m_ram_logdirty, p2m_ram_rw);
+    paging_lock(d);
+    if ( pt == p2m_ram_logdirty )
+    {
+        dv_range_t *range;
+        PAGING_DEBUG(LOGDIRTY,
+                     "marked mfn %" PRI_mfn " (pfn=%lx), dom %d\n",
+                     mfn_x(gmfn), pfn, d->domain_id);
+        d->arch.paging.log_dirty.dirty_count++;
+        range = dirty_vram_range_find_gfn(d, pfn);
+        if (range)
+            range->dirty_count++;
+    }
+    paging_mark_dirty(d, guest_mfn); 
+    paging_unlock(d);
+    p2m_unlock(p2m);
+}
+
 /* Is this guest page dirty? */
 int paging_mfn_is_dirty(struct domain *d, mfn_t gmfn)
 {
@@ -333,8 +374,11 @@ int paging_log_dirty_op(struct domain *d, struct xen_domctl_shadow_op *sc)
     mfn_t *l4, *l3, *l2;
     unsigned long *l1;
     int i4, i3, i2;
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
 
     domain_pause(d);
+    /* Locking hierarchy requires p2m lock to be taken first */
+    p2m_lock(p2m);
     paging_lock(d);
 
     clean = (sc->op == XEN_DOMCTL_SHADOW_OP_CLEAN);
@@ -345,6 +389,14 @@ int paging_log_dirty_op(struct domain *d, struct xen_domctl_shadow_op *sc)
                  d->arch.paging.log_dirty.fault_count,
                  d->arch.paging.log_dirty.dirty_count);
 
+    if (hap_enabled(d) && d->arch.hvm_domain.dirty_vram)
+    {
+        /* If we're cleaning/peeking all guest memory, we should not be tracking
+         * dirty vram. */
+        rv = -EINVAL;
+        goto out;
+    }
+
     sc->stats.fault_count = d->arch.paging.log_dirty.fault_count;
     sc->stats.dirty_count = d->arch.paging.log_dirty.dirty_count;
 
@@ -424,170 +476,60 @@ int paging_log_dirty_op(struct domain *d, struct xen_domctl_shadow_op *sc)
 
     if ( clean )
     {
-        /* We need to further call clean_dirty_bitmap() functions of specific
-         * paging modes (shadow or hap).  Safe because the domain is paused. */
-        d->arch.paging.log_dirty.clean_dirty_bitmap(d);
+        /* Is null if tracking dirty vram */
+        if (d->arch.paging.log_dirty.clean_dirty_bitmap)
+        {
+            /* We need to further call clean_dirty_bitmap() functions of specific
+             * paging modes (shadow or hap).  Safe because the domain is paused. */
+            d->arch.paging.log_dirty.clean_dirty_bitmap(d);
+        }
     }
     domain_unpause(d);
     return rv;
 
  out:
     paging_unlock(d);
+    p2m_unlock(p2m);
     domain_unpause(d);
     return rv;
 }
 
-int paging_log_dirty_range(struct domain *d,
-                            unsigned long begin_pfn,
-                            unsigned long nr,
-                            XEN_GUEST_HANDLE_64(uint8) dirty_bitmap)
+void paging_log_dirty_range(struct domain *d,
+                           unsigned long begin_pfn,
+                           unsigned long nr,
+                           uint8_t *dirty_bitmap)
 {
-    int rv = 0;
-    unsigned long pages = 0;
-    mfn_t *l4, *l3, *l2;
-    unsigned long *l1;
-    int b1, b2, b3, b4;
-    int i2, i3, i4;
-
-    d->arch.paging.log_dirty.clean_dirty_bitmap(d);
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+    dv_range_t *range;
+    unsigned int range_dirty_count = 0;
+    
+    p2m_lock(p2m);
     paging_lock(d);
 
-    PAGING_DEBUG(LOGDIRTY, "log-dirty-range: dom %u faults=%u dirty=%u\n",
-                 d->domain_id,
-                 d->arch.paging.log_dirty.fault_count,
-                 d->arch.paging.log_dirty.dirty_count);
-
-    if ( unlikely(d->arch.paging.log_dirty.failed_allocs) ) {
-        printk("%s: %d failed page allocs while logging dirty pages\n",
-               __FUNCTION__, d->arch.paging.log_dirty.failed_allocs);
-        rv = -ENOMEM;
-        goto out;
-    }
-
-    if ( !d->arch.paging.log_dirty.fault_count &&
-         !d->arch.paging.log_dirty.dirty_count ) {
-        unsigned int size = BITS_TO_LONGS(nr);
-
-        if ( clear_guest(dirty_bitmap, size * BYTES_PER_LONG) != 0 )
-            rv = -EFAULT;
-        goto out;
-    }
-    d->arch.paging.log_dirty.fault_count = 0;
-    d->arch.paging.log_dirty.dirty_count = 0;
-
-    b1 = L1_LOGDIRTY_IDX(begin_pfn);
-    b2 = L2_LOGDIRTY_IDX(begin_pfn);
-    b3 = L3_LOGDIRTY_IDX(begin_pfn);
-    b4 = L4_LOGDIRTY_IDX(begin_pfn);
-    l4 = paging_map_log_dirty_bitmap(d);
-
-    for ( i4 = b4;
-          (pages < nr) && (i4 < LOGDIRTY_NODE_ENTRIES);
-          i4++ )
+    /* Only called when tracking dirty vram in HAP mode */
+    ASSERT(hap_enabled(d) && d->arch.hvm_domain.dirty_vram);
+    
+    range = dirty_vram_range_find_gfn(d, begin_pfn);
+    if (range)
     {
-        l3 = (l4 && mfn_valid(l4[i4])) ? map_domain_page(mfn_x(l4[i4])) : NULL;
-        for ( i3 = b3;
-              (pages < nr) && (i3 < LOGDIRTY_NODE_ENTRIES);
-              i3++ )
-        {
-            l2 = ((l3 && mfn_valid(l3[i3])) ?
-                  map_domain_page(mfn_x(l3[i3])) : NULL);
-            for ( i2 = b2;
-                  (pages < nr) && (i2 < LOGDIRTY_NODE_ENTRIES);
-                  i2++ )
-            {
-                unsigned int bytes = PAGE_SIZE;
-                uint8_t *s;
-                l1 = ((l2 && mfn_valid(l2[i2])) ?
-                      map_domain_page(mfn_x(l2[i2])) : NULL);
-
-                s = ((uint8_t*)l1) + (b1 >> 3);
-                bytes -= b1 >> 3;
-
-                if ( likely(((nr - pages + 7) >> 3) < bytes) )
-                    bytes = (unsigned int)((nr - pages + 7) >> 3);
-
-                if ( !l1 )
-                {
-                    if ( clear_guest_offset(dirty_bitmap, pages >> 3,
-                                            bytes) != 0 )
-                    {
-                        rv = -EFAULT;
-                        goto out;
-                    }
-                }
-                /* begin_pfn is not 32K aligned, hence we have to bit
-                 * shift the bitmap */
-                else if ( b1 & 0x7 )
-                {
-                    int i, j;
-                    uint32_t *l = (uint32_t*) s;
-                    int bits = b1 & 0x7;
-                    int bitmask = (1 << bits) - 1;
-                    int size = (bytes + BYTES_PER_LONG - 1) / BYTES_PER_LONG;
-                    unsigned long bitmap[size];
-                    static unsigned long printed = 0;
-
-                    if ( printed != begin_pfn )
-                    {
-                        dprintk(XENLOG_DEBUG, "%s: begin_pfn %lx is not 32K aligned!\n",
-                                __FUNCTION__, begin_pfn);
-                        printed = begin_pfn;
-                    }
-
-                    for ( i = 0; i < size - 1; i++, l++ ) {
-                        bitmap[i] = ((*l) >> bits) |
-                            (((*((uint8_t*)(l + 1))) & bitmask) << (sizeof(*l) * 8 - bits));
-                    }
-                    s = (uint8_t*) l;
-                    size = BYTES_PER_LONG - ((b1 >> 3) & 0x3);
-                    bitmap[i] = 0;
-                    for ( j = 0; j < size; j++, s++ )
-                        bitmap[i] |= (*s) << (j * 8);
-                    bitmap[i] = (bitmap[i] >> bits) | (bitmask << (size * 8 - bits));
-                    if ( copy_to_guest_offset(dirty_bitmap, (pages >> 3),
-                                (uint8_t*) bitmap, bytes) != 0 )
-                    {
-                        rv = -EFAULT;
-                        goto out;
-                    }
-                }
-                else
-                {
-                    if ( copy_to_guest_offset(dirty_bitmap, pages >> 3,
-                                              s, bytes) != 0 )
-                    {
-                        rv = -EFAULT;
-                        goto out;
-                    }
-                }
-
-                pages += bytes << 3;
-                if ( l1 )
-                {
-                    clear_page(l1);
-                    unmap_domain_page(l1);
-                }
-                b1 = b1 & 0x7;
-            }
-            b2 = 0;
-            if ( l2 )
-                unmap_domain_page(l2);
-        }
-        b3 = 0;
-        if ( l3 )
-            unmap_domain_page(l3);
+        range_dirty_count = range->dirty_count;
+        range->dirty_count = 0;
     }
-    if ( l4 )
-        unmap_domain_page(l4);
-
-    paging_unlock(d);
+    
+    if ( !range_dirty_count)
+        goto out;
 
-    return rv;
+    PAGING_DEBUG(LOGDIRTY, "log-dirty-range: dom %u [%05lx:%05lx] range_dirty=%u\n",
+                 d->domain_id,
+                 begin_pfn,
+                 range->end_pfn,
+                 range_dirty_count);
 
+    hap_clean_vram_tracking_range(d, begin_pfn, nr, dirty_bitmap);
  out:
     paging_unlock(d);
-    return rv;
+    p2m_unlock(p2m);
+    return;
 }
 
 /* Note that this function takes three function pointers. Callers must supply
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index 3f8ad88..c9f3495 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -36,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "private.h"
 
@@ -3121,12 +3122,7 @@ void shadow_teardown(struct domain *d)
      * calls now that we've torn down the bitmap */
     d->arch.paging.mode &= ~PG_log_dirty;
 
-    if (d->arch.hvm_domain.dirty_vram) {
-        xfree(d->arch.hvm_domain.dirty_vram->sl1ma);
-        xfree(d->arch.hvm_domain.dirty_vram->dirty_bitmap);
-        xfree(d->arch.hvm_domain.dirty_vram);
-        d->arch.hvm_domain.dirty_vram = NULL;
-    }
+    dirty_vram_free(d);
 
     paging_unlock(d);
 
@@ -3463,179 +3459,212 @@ void shadow_clean_dirty_bitmap(struct domain *d)
 
 
 /**************************************************************************/
-/* VRAM dirty tracking support */
-int shadow_track_dirty_vram(struct domain *d,
-                            unsigned long begin_pfn,
-                            unsigned long nr,
-                            XEN_GUEST_HANDLE_64(uint8) dirty_bitmap)
-{
-    int rc;
-    unsigned long end_pfn = begin_pfn + nr;
-    unsigned long dirty_size = (nr + 7) / 8;
-    int flush_tlb = 0;
-    unsigned long i;
-    p2m_type_t t;
-    struct sh_dirty_vram *dirty_vram = d->arch.hvm_domain.dirty_vram;
-    struct p2m_domain *p2m = p2m_get_hostp2m(d);
-
-    if (end_pfn < begin_pfn
-            || begin_pfn > p2m->max_mapped_pfn
-            || end_pfn >= p2m->max_mapped_pfn)
-        return -EINVAL;
-
-    /* We perform p2m lookups, so lock the p2m upfront to avoid deadlock */
-    p2m_lock(p2m_get_hostp2m(d));
-    paging_lock(d);
+/* Support functions for shadow-based dirty VRAM code */
 
-    if ( dirty_vram && (!nr ||
-             ( begin_pfn != dirty_vram->begin_pfn
-            || end_pfn   != dirty_vram->end_pfn )) )
-    {
-        /* Different tracking, tear the previous down. */
-        gdprintk(XENLOG_INFO, "stopping tracking VRAM %lx - %lx\n", dirty_vram->begin_pfn, dirty_vram->end_pfn);
-        xfree(dirty_vram->sl1ma);
-        xfree(dirty_vram->dirty_bitmap);
-        xfree(dirty_vram);
-        dirty_vram = d->arch.hvm_domain.dirty_vram = NULL;
-    }
+#define DEBUG_unshadow_sl1ma                  0          
+#define DEBUG_unshadow_sl1ma_detail           0
+#define DEBUG_count_initial_mappings          1
 
-    if ( !nr )
+/* smfn is no longer a shadow page.  Remove it from any
+ * dirty vram range mapping. */
+void
+dirty_vram_delete_shadow(struct vcpu *v,
+                         unsigned long gfn,
+                         unsigned int shadow_type, 
+                         mfn_t smfn)
+{
+    static unsigned int l1_shadow_mask = 
+          1 << SH_type_l1_32_shadow
+        | 1 << SH_type_fl1_32_shadow
+        | 1 << SH_type_l1_pae_shadow
+        | 1 << SH_type_fl1_pae_shadow
+        | 1 << SH_type_l1_64_shadow
+        | 1 << SH_type_fl1_64_shadow
+        ;
+    struct domain *d = v->domain;
+    dv_dirty_vram_t *dirty_vram;
+    struct list_head *curr, *next;
+    
+    ASSERT(paging_locked_by_me(d));
+    /* Ignore all but level 1 shadows */
+    
+    if ((l1_shadow_mask & (1 << shadow_type)) == 0)
     {
-        rc = 0;
         goto out;
     }
 
-    /* This should happen seldomly (Video mode change),
-     * no need to be careful. */
+    dirty_vram = d->arch.hvm_domain.dirty_vram;
     if ( !dirty_vram )
     {
-        /* Throw away all the shadows rather than walking through them 
-         * up to nr times getting rid of mappings of each pfn */
-        shadow_blow_tables(d);
-
-        gdprintk(XENLOG_INFO, "tracking VRAM %lx - %lx\n", begin_pfn, end_pfn);
-
-        rc = -ENOMEM;
-        if ( (dirty_vram = xmalloc(struct sh_dirty_vram)) == NULL )
-            goto out;
-        dirty_vram->begin_pfn = begin_pfn;
-        dirty_vram->end_pfn = end_pfn;
-        d->arch.hvm_domain.dirty_vram = dirty_vram;
-
-        if ( (dirty_vram->sl1ma = xmalloc_array(paddr_t, nr)) == NULL )
-            goto out_dirty_vram;
-        memset(dirty_vram->sl1ma, ~0, sizeof(paddr_t) * nr);
-
-        if ( (dirty_vram->dirty_bitmap = xzalloc_array(uint8_t, dirty_size)) == NULL )
-            goto out_sl1ma;
-
-        dirty_vram->last_dirty = NOW();
-
-        /* Tell the caller that this time we could not track dirty bits. */
-        rc = -ENODATA;
-    }
-    else if (dirty_vram->last_dirty == -1)
-    {
-        /* still completely clean, just copy our empty bitmap */
-        rc = -EFAULT;
-        if ( copy_to_guest(dirty_bitmap, dirty_vram->dirty_bitmap, dirty_size) == 0 )
-            rc = 0;
+        goto out;
     }
-    else
+        
+    list_for_each_safe(curr, next, &dirty_vram->range_head)
     {
-        /* Iterate over VRAM to track dirty bits. */
-        for ( i = 0; i < nr; i++ ) {
-            mfn_t mfn = get_gfn_query_unlocked(d, begin_pfn + i, &t);
-            struct page_info *page;
-            int dirty = 0;
-            paddr_t sl1ma = dirty_vram->sl1ma[i];
-
-            if (mfn_x(mfn) == INVALID_MFN)
-            {
-                dirty = 1;
-            }
-            else
+        dv_range_t *range = list_entry(curr, dv_range_t, range_link);
+        unsigned long i;
+        int max_mappings = 1, mappings = 0;
+        int unshadowed = 0;
+        for (i = 0; i != range->end_pfn - range->begin_pfn; i++)
+        {
+            dv_paddr_link_t *pl = &range->pl_tab[ i ];
+            dv_paddr_link_t **ppl = NULL;
+            mappings = 0;
+            
+            while (pl != NULL)
             {
-                page = mfn_to_page(mfn);
-                switch (page->u.inuse.type_info & PGT_count_mask)
-                {
-                case 0:
-                    /* No guest reference, nothing to track. */
-                    break;
-                case 1:
-                    /* One guest reference. */
-                    if ( sl1ma == INVALID_PADDR )
-                    {
-                        /* We don't know which sl1e points to this, too bad. */
-                        dirty = 1;
-                        /* TODO: Heuristics for finding the single mapping of
-                         * this gmfn */
-                        flush_tlb |= sh_remove_all_mappings(d->vcpu[0], mfn);
-                    }
-                    else
-                    {
-                        /* Hopefully the most common case: only one mapping,
-                         * whose dirty bit we can use. */
-                        l1_pgentry_t *sl1e = maddr_to_virt(sl1ma);
-
-                        if ( l1e_get_flags(*sl1e) & _PAGE_DIRTY )
-                        {
-                            dirty = 1;
-                            /* Note: this is atomic, so we may clear a
-                             * _PAGE_ACCESSED set by another processor. */
-                            l1e_remove_flags(*sl1e, _PAGE_DIRTY);
-                            flush_tlb = 1;
-                        }
-                    }
-                    break;
-                default:
-                    /* More than one guest reference,
-                     * we don't afford tracking that. */
-                    dirty = 1;
+                paddr_t sl1ma = pl->sl1ma;
+                unsigned long sl1mn;
+                
+                if (sl1ma == INVALID_PADDR )
                     break;
+                
+                sl1mn = sl1ma >> PAGE_SHIFT;
+                if (sl1mn == mfn_x(smfn)) {
+#if DEBUG_unshadow_sl1ma_detail
+                    gdprintk(XENLOG_DEBUG,
+                             "[%lx] gfn[%lx] unshadow sl1ma:%lx\n",
+                             mfn_x(smfn),
+                             range->begin_pfn + i,
+                             sl1ma);
+#endif
+                    unshadowed++;
+                    pl = free_paddr_link(d, ppl, pl);
+                    --range->nr_mappings;
+                }
+                else
+                {
+                    ppl = &pl->pl_next;
+                    pl = *ppl;
+                    mappings++;
                 }
             }
-
-            if ( dirty )
+        }
+        if (mappings > max_mappings)
+            max_mappings = mappings;
+        
+        if (unshadowed) {
+#if DEBUG_unshadow_sl1ma
+            gdprintk(XENLOG_DEBUG,
+                     "[%lx] gfn[%05lx:%05lx] unshadowed:%d mappings:0x%x max_mappings:%d\n",
+                     mfn_x(smfn),
+                     range->begin_pfn, range->end_pfn,
+                     unshadowed, range->nr_mappings, max_mappings);
+#endif
+            if ( range->nr_mappings == 0 )
             {
-                dirty_vram->dirty_bitmap[i / 8] |= 1 << (i % 8);
-                dirty_vram->last_dirty = NOW();
+                dirty_vram_range_free(d, range);                    
             }
         }
+    }
+ out:
+    return;
+}
+
+
+typedef int (*hash_pfn_callback_t)(struct vcpu *v,
+                                   mfn_t smfn,
+                                   unsigned long begin_pfn,
+                                   unsigned long end_pfn,
+                                   int *removed);
+
+static int hash_pfn_foreach(struct vcpu *v, 
+                            unsigned int callback_mask, 
+                            hash_pfn_callback_t callbacks[], 
+                            unsigned long begin_pfn,
+                            unsigned long end_pfn)
+/* Walk the hash table looking at the types of the entries and 
+ * calling the appropriate callback function for each entry. 
+ * The mask determines which shadow types we call back for, and the array
+ * of callbacks tells us which function to call.
+ * Any callback may return non-zero to let us skip the rest of the scan. 
+ *
+ * WARNING: Callbacks MUST NOT add or remove hash entries unless they 
+ * then return non-zero to terminate the scan. */
+{
+    int i, done = 0, removed = 0;
+    struct domain *d = v->domain;
+    struct page_info *x;
+
+    /* Say we're here, to stop hash-lookups reordering the chains */
+    ASSERT(paging_locked_by_me(d));
+    ASSERT(d->arch.paging.shadow.hash_walking == 0);
+    d->arch.paging.shadow.hash_walking = 1;
 
-        rc = -EFAULT;
-        if ( copy_to_guest(dirty_bitmap, dirty_vram->dirty_bitmap, dirty_size) == 0 ) {
-            memset(dirty_vram->dirty_bitmap, 0, dirty_size);
-            if (dirty_vram->last_dirty + SECONDS(2) < NOW())
+    for ( i = 0; i < SHADOW_HASH_BUCKETS; i++ ) 
+    {
+        /* WARNING: This is not safe against changes to the hash table.
+         * The callback *must* return non-zero if it has inserted or
+         * deleted anything from the hash (lookups are OK, though). */
+        for ( x = d->arch.paging.shadow.hash_table[i]; x; x = next_shadow(x) )
+        {
+            if ( callback_mask & (1 << x->u.sh.type) )
             {
-                /* was clean for more than two seconds, try to disable guest
-                 * write access */
-                for ( i = begin_pfn; i < end_pfn; i++ ) {
-                    mfn_t mfn = get_gfn_query_unlocked(d, i, &t);
-                    if (mfn_x(mfn) != INVALID_MFN)
-                        flush_tlb |= sh_remove_write_access(d->vcpu[0], mfn, 1, 0);
-                }
-                dirty_vram->last_dirty = -1;
+                ASSERT(x->u.sh.type <= 15);
+                ASSERT(callbacks[x->u.sh.type] != NULL);
+                done = callbacks[x->u.sh.type](v, page_to_mfn(x), 
+                                               begin_pfn, end_pfn,
+                                               &removed);
+                if ( done ) break;
             }
-            rc = 0;
         }
+        if ( done ) break; 
     }
-    if ( flush_tlb )
-        flush_tlb_mask(d->domain_dirty_cpumask);
-    goto out;
+    d->arch.paging.shadow.hash_walking = 0;
+    return removed;
+}
 
-out_sl1ma:
-    xfree(dirty_vram->sl1ma);
-out_dirty_vram:
-    xfree(dirty_vram);
-    dirty_vram = d->arch.hvm_domain.dirty_vram = NULL;
+void sh_find_all_vram_mappings(struct vcpu *v,
+                               dv_range_t *range)
+{
+    /* Dispatch table for getting per-type functions */
+    static hash_pfn_callback_t callbacks[SH_type_unused] = {
+        NULL, /* none    */
+        SHADOW_INTERNAL_NAME(sh_find_vram_mappings_in_l1, 2), /* l1_32   */
+        SHADOW_INTERNAL_NAME(sh_find_vram_mappings_in_l1, 2), /* fl1_32  */
+        NULL, /* l2_32   */
+        SHADOW_INTERNAL_NAME(sh_find_vram_mappings_in_l1, 3), /* l1_pae  */
+        SHADOW_INTERNAL_NAME(sh_find_vram_mappings_in_l1, 3), /* fl1_pae */
+        NULL, /* l2_pae  */
+        NULL, /* l2h_pae */
+#if CONFIG_PAGING_LEVELS >= 4
+        SHADOW_INTERNAL_NAME(sh_find_vram_mappings_in_l1, 4), /* l1_64   */
+        SHADOW_INTERNAL_NAME(sh_find_vram_mappings_in_l1, 4), /* fl1_64  */
+#else
+        NULL, /* l1_64   */
+        NULL, /* fl1_64  */
+#endif
+        NULL, /* l2_64   */
+        NULL, /* l2h_64  */
+        NULL, /* l3_64   */
+        NULL, /* l4_64   */
+        NULL, /* p2m     */
+        NULL  /* unused  */
+    };
 
-out:
-    paging_unlock(d);
-    p2m_unlock(p2m_get_hostp2m(d));
-    return rc;
+    static unsigned int callback_mask = 
+          1 << SH_type_l1_32_shadow
+        | 1 << SH_type_fl1_32_shadow
+        | 1 << SH_type_l1_pae_shadow
+        | 1 << SH_type_fl1_pae_shadow
+        | 1 << SH_type_l1_64_shadow
+        | 1 << SH_type_fl1_64_shadow
+        ;
+
+    perfc_incr(shadow_mappings);
+
+    hash_pfn_foreach(v, callback_mask, callbacks,
+                     range->begin_pfn,
+                     range->end_pfn);
+
+#if DEBUG_count_initial_mappings
+    gdprintk(XENLOG_DEBUG, "[%05lx:%05lx] count of initial mappings:%d\n",
+             range->begin_pfn, range->end_pfn,
+             range->nr_mappings);
+#endif
 }
 
+
 /**************************************************************************/
 /* Shadow-control XEN_DOMCTL dispatcher */
 
diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index b0e6d72..f4d0603 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -149,6 +150,10 @@ delete_fl1_shadow_status(struct vcpu *v, gfn_t gfn, mfn_t smfn)
     SHADOW_PRINTK("gfn=%"SH_PRI_gfn", type=%08x, smfn=%05lx\n",
                    gfn_x(gfn), SH_type_fl1_shadow, mfn_x(smfn));
     ASSERT(mfn_to_page(smfn)->u.sh.head);
+
+    /* Removing any dv_paddr_links to the erstwhile shadow page */
+    dirty_vram_delete_shadow(v, gfn_x(gfn), SH_type_fl1_shadow, smfn);
+    
     shadow_hash_delete(v, gfn_x(gfn), SH_type_fl1_shadow, smfn);
 }
 
@@ -160,6 +165,10 @@ delete_shadow_status(struct vcpu *v, mfn_t gmfn, u32 shadow_type, mfn_t smfn)
                    v->domain->domain_id, v->vcpu_id,
                    mfn_x(gmfn), shadow_type, mfn_x(smfn));
     ASSERT(mfn_to_page(smfn)->u.sh.head);
+    
+    /* Removing any dv_paddr_links to the erstwhile shadow page */
+    dirty_vram_delete_shadow(v, mfn_x(gmfn), shadow_type, smfn);
+    
     shadow_hash_delete(v, mfn_x(gmfn), shadow_type, smfn);
     /* 32-on-64 PV guests don't own their l4 pages; see set_shadow_status */
     if ( !is_pv_32on64_vcpu(v) || shadow_type != SH_type_l4_64_shadow )
@@ -516,7 +525,6 @@ _sh_propagate(struct vcpu *v,
     guest_l1e_t guest_entry = { guest_intpte };
     shadow_l1e_t *sp = shadow_entry_ptr;
     struct domain *d = v->domain;
-    struct sh_dirty_vram *dirty_vram = d->arch.hvm_domain.dirty_vram;
     gfn_t target_gfn = guest_l1e_get_gfn(guest_entry);
     u32 pass_thru_flags;
     u32 gflags, sflags;
@@ -663,17 +671,6 @@ _sh_propagate(struct vcpu *v,
         }
     }
 
-    if ( unlikely((level == 1) && dirty_vram
-            && dirty_vram->last_dirty == -1
-            && gfn_x(target_gfn) >= dirty_vram->begin_pfn
-            && gfn_x(target_gfn) < dirty_vram->end_pfn) )
-    {
-        if ( ft & FETCH_TYPE_WRITE )
-            dirty_vram->last_dirty = NOW();
-        else
-            sflags &= ~_PAGE_RW;
-    }
-
     /* Read-only memory */
     if ( p2m_is_readonly(p2mt) ||
          (p2mt == p2m_mmio_direct &&
@@ -1072,101 +1069,57 @@ static int shadow_set_l2e(struct vcpu *v,
     return flags;
 }
 
-static inline void shadow_vram_get_l1e(shadow_l1e_t new_sl1e,
+/* shadow_vram_fix_l1e()
+ * Testing L1PTEs as they are modified, look for when they start to (or cease to)
+ * point to frame buffer pages.  If the old and new gfns differ, calls
+ * dirty_vram_range_update() to updates the dirty_vram structures
+ */
+static inline void shadow_vram_fix_l1e(shadow_l1e_t old_sl1e,
+                                       shadow_l1e_t new_sl1e,
                                        shadow_l1e_t *sl1e,
                                        mfn_t sl1mfn,
                                        struct domain *d)
 { 
-    mfn_t mfn = shadow_l1e_get_mfn(new_sl1e);
-    int flags = shadow_l1e_get_flags(new_sl1e);
-    unsigned long gfn;
-    struct sh_dirty_vram *dirty_vram = d->arch.hvm_domain.dirty_vram;
+    mfn_t new_mfn, old_mfn;
+    unsigned long new_gfn = INVALID_M2P_ENTRY, old_gfn = INVALID_M2P_ENTRY;
+    paddr_t sl1ma;
+    dv_dirty_vram_t *dirty_vram = d->arch.hvm_domain.dirty_vram;
 
-    if ( !dirty_vram         /* tracking disabled? */
-         || !(flags & _PAGE_RW) /* read-only mapping? */
-         || !mfn_valid(mfn) )   /* mfn can be invalid in mmio_direct */
+    if ( !dirty_vram )
         return;
 
-    gfn = mfn_to_gfn(d, mfn);
-    /* Page sharing not supported on shadow PTs */
-    BUG_ON(SHARED_M2P(gfn));
+    sl1ma = pfn_to_paddr(mfn_x(sl1mfn)) | ((unsigned long)sl1e & ~PAGE_MASK);
 
-    if ( (gfn >= dirty_vram->begin_pfn) && (gfn < dirty_vram->end_pfn) )
+    old_mfn = shadow_l1e_get_mfn(old_sl1e);
+
+    if ( !sh_l1e_is_magic(old_sl1e) &&
+         (l1e_get_flags(old_sl1e) & _PAGE_PRESENT) &&
+         mfn_valid(old_mfn))
     {
-        unsigned long i = gfn - dirty_vram->begin_pfn;
-        struct page_info *page = mfn_to_page(mfn);
-        
-        if ( (page->u.inuse.type_info & PGT_count_mask) == 1 )
-            /* Initial guest reference, record it */
-            dirty_vram->sl1ma[i] = pfn_to_paddr(mfn_x(sl1mfn))
-                | ((unsigned long)sl1e & ~PAGE_MASK);
+        old_gfn = mfn_to_gfn(d, old_mfn);
     }
-}
-
-static inline void shadow_vram_put_l1e(shadow_l1e_t old_sl1e,
-                                       shadow_l1e_t *sl1e,
-                                       mfn_t sl1mfn,
-                                       struct domain *d)
-{
-    mfn_t mfn = shadow_l1e_get_mfn(old_sl1e);
-    int flags = shadow_l1e_get_flags(old_sl1e);
-    unsigned long gfn;
-    struct sh_dirty_vram *dirty_vram = d->arch.hvm_domain.dirty_vram;
-
-    if ( !dirty_vram         /* tracking disabled? */
-         || !(flags & _PAGE_RW) /* read-only mapping? */
-         || !mfn_valid(mfn) )   /* mfn can be invalid in mmio_direct */
-        return;
-
-    gfn = mfn_to_gfn(d, mfn);
-    /* Page sharing not supported on shadow PTs */
-    BUG_ON(SHARED_M2P(gfn));
-
-    if ( (gfn >= dirty_vram->begin_pfn) && (gfn < dirty_vram->end_pfn) )
+    
+    new_mfn = shadow_l1e_get_mfn(new_sl1e);
+    if ( !sh_l1e_is_magic(new_sl1e) &&
+         (l1e_get_flags(new_sl1e) & _PAGE_PRESENT) &&
+         mfn_valid(new_mfn))
     {
-        unsigned long i = gfn - dirty_vram->begin_pfn;
-        struct page_info *page = mfn_to_page(mfn);
-        int dirty = 0;
-        paddr_t sl1ma = pfn_to_paddr(mfn_x(sl1mfn))
-            | ((unsigned long)sl1e & ~PAGE_MASK);
+        new_gfn = mfn_to_gfn(d, new_mfn);
+    }
 
-        if ( (page->u.inuse.type_info & PGT_count_mask) == 1 )
-        {
-            /* Last reference */
-            if ( dirty_vram->sl1ma[i] == INVALID_PADDR ) {
-                /* We didn't know it was that one, let's say it is dirty */
-                dirty = 1;
-            }
-            else
-            {
-                ASSERT(dirty_vram->sl1ma[i] == sl1ma);
-                dirty_vram->sl1ma[i] = INVALID_PADDR;
-                if ( flags & _PAGE_DIRTY )
-                    dirty = 1;
-            }
-        }
-        else
+    if (old_gfn == new_gfn) return;
+
+    if (VALID_M2P(old_gfn))
+        if (dirty_vram_range_update(d, old_gfn, sl1ma, 0/*clear*/))
         {
-            /* We had more than one reference, just consider the page dirty. */
-            dirty = 1;
-            /* Check that it's not the one we recorded. */
-            if ( dirty_vram->sl1ma[i] == sl1ma )
-            {
-                /* Too bad, we remembered the wrong one... */
-                dirty_vram->sl1ma[i] = INVALID_PADDR;
-            }
-            else
-            {
-                /* Ok, our recorded sl1e is still pointing to this page, let's
-                 * just hope it will remain. */
-            }
+            SHADOW_PRINTK("gfn %lx (mfn %lx) cleared vram pte\n", old_gfn, mfn_x(old_mfn));
         }
-        if ( dirty )
+
+    if (VALID_M2P(new_gfn))
+        if (dirty_vram_range_update(d, new_gfn, sl1ma, 1/*set*/))
         {
-            dirty_vram->dirty_bitmap[i / 8] |= 1 << (i % 8);
-            dirty_vram->last_dirty = NOW();
+            SHADOW_PRINTK("gfn %lx (mfn %lx) set vram pte\n", new_gfn, mfn_x(new_mfn));
         }
-    }
 }
 
 static int shadow_set_l1e(struct vcpu *v, 
@@ -1211,12 +1164,14 @@ static int shadow_set_l1e(struct vcpu *v,
                 shadow_l1e_remove_flags(new_sl1e, _PAGE_RW);
                 /* fall through */
             case 0:
-                shadow_vram_get_l1e(new_sl1e, sl1e, sl1mfn, d);
+                shadow_vram_fix_l1e(old_sl1e, new_sl1e, sl1e, sl1mfn, d);
                 break;
             }
         }
     } 
 
+    shadow_vram_fix_l1e(old_sl1e, new_sl1e, sl1e, sl1mfn, d);
+
     /* Write the new entry */
     shadow_write_entries(sl1e, &new_sl1e, 1, sl1mfn);
     flags |= SHADOW_SET_CHANGED;
@@ -1231,7 +1186,6 @@ static int shadow_set_l1e(struct vcpu *v,
          * trigger a flush later. */
         if ( shadow_mode_refcounts(d) ) 
         {
-            shadow_vram_put_l1e(old_sl1e, sl1e, sl1mfn, d);
             shadow_put_page_from_l1e(old_sl1e, d);
             TRACE_SHADOW_PATH_FLAG(TRCE_SFLAG_SHADOW_L1_PUT_REF);
         } 
@@ -2018,7 +1972,6 @@ void sh_destroy_l1_shadow(struct vcpu *v, mfn_t smfn)
         SHADOW_FOREACH_L1E(sl1mfn, sl1e, 0, 0, {
             if ( (shadow_l1e_get_flags(*sl1e) & _PAGE_PRESENT)
                  && !sh_l1e_is_magic(*sl1e) ) {
-                shadow_vram_put_l1e(*sl1e, sl1e, sl1mfn, d);
                 shadow_put_page_from_l1e(*sl1e, d);
             }
         });
@@ -4336,6 +4289,34 @@ int sh_rm_mappings_from_l1(struct vcpu *v, mfn_t sl1mfn, mfn_t target_mfn)
     return done;
 }
 
+
+int sh_find_vram_mappings_in_l1(struct vcpu *v,
+                                mfn_t sl1mfn,
+                                unsigned long begin_pfn,
+                                unsigned long end_pfn,
+                                int *removed)
+/* Find all VRAM mappings in this shadow l1 table */
+{
+    struct domain *d = v->domain;
+    shadow_l1e_t *sl1e;
+    int done = 0;
+    
+    SHADOW_FOREACH_L1E(sl1mfn, sl1e, 0, done, /* only returns _PAGE_PRESENT entries */
+    {
+        unsigned long gfn;
+        mfn_t gmfn = shadow_l1e_get_mfn(*sl1e);
+        if (!mfn_valid(gmfn))
+            continue;
+        gfn = mfn_to_gfn(d, gmfn);
+        if (VALID_M2P(gfn) && (begin_pfn <= gfn) && (gfn < end_pfn)) 
+        {
+            paddr_t sl1ma = pfn_to_paddr(mfn_x(sl1mfn)) | ((unsigned long)sl1e & ~PAGE_MASK);
+            dirty_vram_range_update(v->domain, gfn, sl1ma, 1/*set*/);
+        }
+    });
+    return 0;
+}
+
 /**************************************************************************/
 /* Functions to excise all pointers to shadows from higher-level shadows. */
 
diff --git a/xen/arch/x86/mm/shadow/multi.h b/xen/arch/x86/mm/shadow/multi.h
index 835121e..436a4ac 100644
--- a/xen/arch/x86/mm/shadow/multi.h
+++ b/xen/arch/x86/mm/shadow/multi.h
@@ -66,7 +66,12 @@ SHADOW_INTERNAL_NAME(sh_rm_write_access_from_l1, GUEST_LEVELS)
 extern int
 SHADOW_INTERNAL_NAME(sh_rm_mappings_from_l1, GUEST_LEVELS)
     (struct vcpu *v, mfn_t sl1mfn, mfn_t target_mfn);
-
+extern int
+SHADOW_INTERNAL_NAME(sh_find_vram_mappings_in_l1, GUEST_LEVELS)
+     (struct vcpu *v, mfn_t sl1mfn, 
+      unsigned long begin_pfn,
+      unsigned long end_pfn,
+      int *removed);
 extern void
 SHADOW_INTERNAL_NAME(sh_clear_shadow_entry, GUEST_LEVELS)
     (struct vcpu *v, void *ep, mfn_t smfn);
diff --git a/xen/arch/x86/mm/shadow/types.h b/xen/arch/x86/mm/shadow/types.h
index 43ce1db..5b0f9f7 100644
--- a/xen/arch/x86/mm/shadow/types.h
+++ b/xen/arch/x86/mm/shadow/types.h
@@ -229,6 +229,7 @@ static inline shadow_l4e_t shadow_l4e_from_mfn(mfn_t mfn, u32 flags)
 #define sh_update_cr3              INTERNAL_NAME(sh_update_cr3)
 #define sh_rm_write_access_from_l1 INTERNAL_NAME(sh_rm_write_access_from_l1)
 #define sh_rm_mappings_from_l1     INTERNAL_NAME(sh_rm_mappings_from_l1)
+#define sh_find_vram_mappings_in_l1 INTERNAL_NAME(sh_find_vram_mappings_in_l1)
 #define sh_remove_l1_shadow        INTERNAL_NAME(sh_remove_l1_shadow)
 #define sh_remove_l2_shadow        INTERNAL_NAME(sh_remove_l2_shadow)
 #define sh_remove_l3_shadow        INTERNAL_NAME(sh_remove_l3_shadow)
diff --git a/xen/include/asm-x86/hap.h b/xen/include/asm-x86/hap.h
index a2532a4..82e20c7 100644
--- a/xen/include/asm-x86/hap.h
+++ b/xen/include/asm-x86/hap.h
@@ -57,10 +57,6 @@ void  hap_final_teardown(struct domain *d);
 void  hap_teardown(struct domain *d);
 void  hap_vcpu_init(struct vcpu *v);
 void  hap_logdirty_init(struct domain *d);
-int   hap_track_dirty_vram(struct domain *d,
-                           unsigned long begin_pfn,
-                           unsigned long nr,
-                           XEN_GUEST_HANDLE_64(uint8) dirty_bitmap);
 
 extern const struct paging_mode *hap_paging_get_mode(struct vcpu *);
 
diff --git a/xen/include/asm-x86/hvm/dirty_vram.h b/xen/include/asm-x86/hvm/dirty_vram.h
new file mode 100644
index 0000000..b8b92cc
--- /dev/null
+++ b/xen/include/asm-x86/hvm/dirty_vram.h
@@ -0,0 +1,157 @@
+/******************************************************************************
+ * include/asm-x86/hvm/dirty_vram.h
+ *
+ * Interface for tracking dirty VRAM pages
+ *
+ * Copyright (c) 2012 Citrix Systems, Inc. (Robert Phillips)
+ * Parts of this code are Copyright (c) 2006 by XenSource Inc.
+ * Parts of this code are Copyright (c) 2006 by Michael A Fetterman
+ * Parts based on earlier work by Michael A Fetterman, Ian Pratt et al.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+#ifndef _DIRTY_VRAM_H
+#define _DIRTY_VRAM_H
+
+/* In shadow mode we need to bookkeep all the L1 page table entries that
+ * map a frame buffer page.  Struct dv_paddr_link does this
+ * by recording the address of a L1 page table entry for some frame buffer page.
+ * Also has a link to additional pl entries if the frame buffer page
+ * has multiple mappings */
+typedef struct dv_paddr_link {
+    paddr_t sl1ma;
+    struct dv_paddr_link *pl_next;
+} dv_paddr_link_t;
+
+/* This defines an extension page of pl entries for FB pages with multiple
+ * mappings. All such pages (of a domain) are linked together. */
+typedef struct dv_paddr_link_ext {
+    struct list_head ext_link;
+    dv_paddr_link_t entries[(PAGE_SIZE-sizeof(struct list_head))/sizeof(dv_paddr_link_t)];
+} dv_paddr_link_ext_t;
+
+/* This defines a single frame buffer range.  It bookkeeps all the level 1 PTEs
+ * that map guest pages within that range.
+ * All such ranges (of a domain) are linked together. */
+typedef struct dv_range {
+    struct list_head range_link; /* the several ranges form a linked list */
+    unsigned long begin_pfn;
+    unsigned long end_pfn;
+    dv_paddr_link_t *pl_tab; /* table has 1 pl entry per pfn in range */
+    int nr_mappings;  /* total number of mappings in this range */
+    int mappings_hwm; /* high water mark of max mapping count */
+    unsigned int dirty_count;
+} dv_range_t;
+
+/* This contains all the data structures required by a domain to
+ * bookkeep the dirty pages within its frame buffers. */
+typedef struct dv_dirty_vram {
+    struct list_head range_head; /* head of the linked list of ranges */
+    struct list_head ext_head; /* head of list of extension pages */
+    dv_paddr_link_t *pl_free; /* free list of pl's within extension pages */
+    int nr_ranges; /* bookkeeps number of ranges */
+    int ranges_hwm; /* high water mark of max number of ranges */
+} dv_dirty_vram_t;
+
+/* Allocates domain's dirty_vram structure */
+dv_dirty_vram_t *
+dirty_vram_alloc(struct domain *d);
+
+/* Returns domain's dirty_vram structure,
+ * allocating it if necessary */
+dv_dirty_vram_t *
+dirty_vram_find_or_alloc(struct domain *d);
+
+/* Frees domain's dirty_vram structure */
+void dirty_vram_free(struct domain *d);
+
+/* Returns dirty vram range containing gfn, NULL if none */
+struct dv_range *
+dirty_vram_range_find_gfn(struct domain *d,
+                          unsigned long gfn);
+
+/* Returns dirty vram range matching [ begin_pfn .. begin_pfn+nr ), NULL if none */
+dv_range_t *
+dirty_vram_range_find(struct domain *d,
+                      unsigned long begin_pfn,
+                      unsigned long nr);
+
+/* Allocate dirty vram range containing [ begin_pfn .. begin_pfn+nr ),
+ * freeing any existing range that overlaps the new range. */
+dv_range_t *
+dirty_vram_range_alloc(struct domain *d,
+                       unsigned long begin_pfn,
+                       unsigned long nr);
+
+/* Returns dirty vram range matching [ begin_pfn .. begin_pfn+nr ),
+ * creating a range if none already exists and
+ * freeing any existing range that overlaps the new range. */
+dv_range_t *
+dirty_vram_range_find_or_alloc(struct domain *d,
+                               unsigned long begin_pfn,
+                               unsigned long nr);
+
+void dirty_vram_range_free(struct domain *d,
+                           dv_range_t *range);
+
+/* Bookkeep PTE address of a frame buffer page */
+int dirty_vram_range_update(struct domain *d,
+                            unsigned long gfn,
+                            paddr_t sl1ma,
+                            int set);
+
+/* smfn is no longer a shadow page.  Remove it from any
+ * dirty vram range mapping. */
+void
+dirty_vram_delete_shadow(struct vcpu *v,
+                         unsigned long gfn,
+                         unsigned int shadow_type, 
+                         mfn_t smfn);
+
+
+/* Scan all the L1 tables looking for VRAM mappings.
+ * Record them in the domain's dv_dirty_vram structure */
+void sh_find_all_vram_mappings(struct vcpu *v,
+                               dv_range_t *range);
+
+/* Free a paddr_link struct, given address of its
+ * predecessor in singly-linked list */
+dv_paddr_link_t *
+free_paddr_link(struct domain *d,
+                dv_paddr_link_t **ppl,
+                dv_paddr_link_t *pl);
+
+
+/* Enable VRAM dirty tracking. */
+int
+shadow_track_dirty_vram(struct domain *d,
+			unsigned long first_pfn,
+			unsigned long nr,
+			XEN_GUEST_HANDLE_64(uint8) dirty_bitmap);
+
+int
+hap_track_dirty_vram(struct domain *d,
+		     unsigned long begin_pfn,
+		     unsigned long nr,
+		     XEN_GUEST_HANDLE_64(uint8) dirty_bitmap);
+
+void
+hap_clean_vram_tracking_range(struct domain *d,
+			      unsigned long begin_pfn,
+			      unsigned long nr,
+			      uint8_t *dirty_bitmap);
+
+#endif /* _DIRTY_VRAM_H */
diff --git a/xen/include/asm-x86/hvm/domain.h b/xen/include/asm-x86/hvm/domain.h
index 27b3de5..6146542 100644
--- a/xen/include/asm-x86/hvm/domain.h
+++ b/xen/include/asm-x86/hvm/domain.h
@@ -74,7 +74,7 @@ struct hvm_domain {
     struct list_head       pinned_cacheattr_ranges;
 
     /* VRAM dirty support. */
-    struct sh_dirty_vram *dirty_vram;
+    struct dv_dirty_vram * dirty_vram;
 
     /* If one of vcpus of this domain is in no_fill_mode or
      * mtrr/pat between vcpus is not the same, set is_in_uc_mode
diff --git a/xen/include/asm-x86/paging.h b/xen/include/asm-x86/paging.h
index d9b6950..fba06b0 100644
--- a/xen/include/asm-x86/paging.h
+++ b/xen/include/asm-x86/paging.h
@@ -137,10 +137,10 @@ struct paging_mode {
 void paging_free_log_dirty_bitmap(struct domain *d);
 
 /* get the dirty bitmap for a specific range of pfns */
-int paging_log_dirty_range(struct domain *d,
-                           unsigned long begin_pfn,
-                           unsigned long nr,
-                           XEN_GUEST_HANDLE_64(uint8) dirty_bitmap);
+void paging_log_dirty_range(struct domain *d,
+                            unsigned long begin_pfn,
+                            unsigned long nr,
+                            uint8_t *dirty_bitmap);
 
 /* enable log dirty */
 int paging_log_dirty_enable(struct domain *d);
@@ -161,6 +161,11 @@ void paging_mark_dirty(struct domain *d, unsigned long guest_mfn);
  * This is called from inside paging code, with the paging lock held. */
 int paging_mfn_is_dirty(struct domain *d, mfn_t gmfn);
 
+/* mark a page as dirty, from hap page fault handler */
+void paging_mark_dirty_hap(struct domain *d,
+                           unsigned long pfn,
+                           unsigned long guest_mfn);
+
 /*
  * Log-dirty radix tree indexing:
  *   All tree nodes are PAGE_SIZE bytes, mapped on-demand.
@@ -183,15 +188,6 @@ int paging_mfn_is_dirty(struct domain *d, mfn_t gmfn);
 #define L4_LOGDIRTY_IDX(pfn) 0
 #endif
 
-/* VRAM dirty tracking support */
-struct sh_dirty_vram {
-    unsigned long begin_pfn;
-    unsigned long end_pfn;
-    paddr_t *sl1ma;
-    uint8_t *dirty_bitmap;
-    s_time_t last_dirty;
-};
-
 /*****************************************************************************
  * Entry points into the paging-assistance code */
 
diff --git a/xen/include/asm-x86/shadow.h b/xen/include/asm-x86/shadow.h
index 88a8cd2..bdb8dcd 100644
--- a/xen/include/asm-x86/shadow.h
+++ b/xen/include/asm-x86/shadow.h
@@ -62,12 +62,6 @@ void shadow_vcpu_init(struct vcpu *v);
 /* Enable an arbitrary shadow mode.  Call once at domain creation. */
 int shadow_enable(struct domain *d, u32 mode);
 
-/* Enable VRAM dirty bit tracking. */
-int shadow_track_dirty_vram(struct domain *d,
-                            unsigned long first_pfn,
-                            unsigned long nr,
-                            XEN_GUEST_HANDLE_64(uint8) dirty_bitmap);
-
 /* Handler for shadow control ops: operations from user-space to enable
  * and disable ephemeral shadow modes (test mode and log-dirty mode) and
  * manipulate the log-dirty bitmap. */
-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 18:42:48 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 18:42:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOC60-0001z0-5k; Tue, 16 Oct 2012 18:42:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOC5z-0001yp-7V
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 18:42:27 +0000
Received: from [85.158.143.35:22483] by server-3.bemta-4.messagelabs.com id
	AC/C6-03544-29AAD705; Tue, 16 Oct 2012 18:42:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1350412945!13946004!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQzMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 398 invoked from network); 16 Oct 2012 18:42:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 18:42:25 -0000
X-IronPort-AV: E=Sophos;i="4.80,595,1344211200"; d="scan'208";a="15211032"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Oct 2012 18:42:25 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 16 Oct 2012 19:42:24 +0100
Message-ID: <1350412943.14440.13.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Ben Guthro 
Date: Tue, 16 Oct 2012 19:42:23 +0100
In-Reply-To: 
References: <20121016T192158.GA.6e659.stse@fsing.rootsland.net>
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Stephan Seitz ,
	xen-devel ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] CPU microcode update under xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On Tue, 2012-10-16 at 18:54 +0100, Ben Guthro wrote:
> This is not yet merged.

Please try and avoid top posting...

> On Tue, Oct 16, 2012 at 1:27 PM, Stephan Seitz
>  wrote:
[...]
> > Do I need another driver for microcode updates under XEN, or is it impossible for now?

There is also the option for Xen itself to load the microcode.

See the ucode option in
http://xenbits.xen.org/docs/4.2-testing/misc/xen-command-line.html

I think this is probably 4.2+ only though (not sure when it was added).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 18:42:48 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 18:42:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOC60-0001z0-5k; Tue, 16 Oct 2012 18:42:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOC5z-0001yp-7V
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 18:42:27 +0000
Received: from [85.158.143.35:22483] by server-3.bemta-4.messagelabs.com id
	AC/C6-03544-29AAD705; Tue, 16 Oct 2012 18:42:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1350412945!13946004!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQzMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 398 invoked from network); 16 Oct 2012 18:42:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 18:42:25 -0000
X-IronPort-AV: E=Sophos;i="4.80,595,1344211200"; d="scan'208";a="15211032"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Oct 2012 18:42:25 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 16 Oct 2012 19:42:24 +0100
Message-ID: <1350412943.14440.13.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Ben Guthro 
Date: Tue, 16 Oct 2012 19:42:23 +0100
In-Reply-To: 
References: <20121016T192158.GA.6e659.stse@fsing.rootsland.net>
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Stephan Seitz ,
	xen-devel ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] CPU microcode update under xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On Tue, 2012-10-16 at 18:54 +0100, Ben Guthro wrote:
> This is not yet merged.

Please try and avoid top posting...

> On Tue, Oct 16, 2012 at 1:27 PM, Stephan Seitz
>  wrote:
[...]
> > Do I need another driver for microcode updates under XEN, or is it impossible for now?

There is also the option for Xen itself to load the microcode.

See the ucode option in
http://xenbits.xen.org/docs/4.2-testing/misc/xen-command-line.html

I think this is probably 4.2+ only though (not sure when it was added).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 19:43:45 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 19:43:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOD2n-0002cw-UX; Tue, 16 Oct 2012 19:43:13 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOD2m-0002cr-Cn
	for Xen-devel@lists.xensource.com; Tue, 16 Oct 2012 19:43:12 +0000
Received: from [193.109.254.147:33897] by server-15.bemta-14.messagelabs.com
	id FD/E5-16351-FC8BD705; Tue, 16 Oct 2012 19:43:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1350416590!3763049!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQzMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16784 invoked from network); 16 Oct 2012 19:43:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 19:43:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,595,1344211200"; d="scan'208";a="15211572"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Oct 2012 19:43:09 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 16 Oct 2012 20:43:09 +0100
Message-ID: <1350416588.28188.0.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Mukesh Rathor 
Date: Tue, 16 Oct 2012 20:43:08 +0100
In-Reply-To: <20121016104657.4b2478a8@mantra.us.oracle.com>
References: <20121011145817.0d744c99@mantra.us.oracle.com>
	<1350032276.14806.53.camel@zakaz.uk.xensource.com>
	<1350404821.2460.3.camel@zakaz.uk.xensource.com>
	<20121016104657.4b2478a8@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V2 3/7]: PVH:  mmu related changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-16 at 10:46 -0700, Mukesh Rathor wrote:
> On Tue, 16 Oct 2012 17:27:01 +0100
> Ian Campbell  wrote:
> 
> > On Fri, 2012-10-12 at 09:57 +0100, Ian Campbell wrote:
> > > > +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma)
> > > > +{
> > > > +       int numpgs = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
> > > > +       struct page **pages = vma ? vma->vm_private_data : NULL;
> > > 
> > > I thought we agreed to keep uses of vm_private_data in the privcmd
> > > driver?
> > > 
> > > I think you should just add pages and nr as direct parameters to
> > > this function, which is symmetric with the map call.
> > 
> > I had to look at this while rebasing my arm patches, turned out to be
> > fairly simple. Feel free to either fold in or badger me for a proper
> > commit message.
> 
> 
> I made similar change in my tree, except I am not passing vma as its
> not needed. I guess you just wanna be consistend with remap, or future
> use?

Consistency mostly.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 19:43:45 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 19:43:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOD2n-0002cw-UX; Tue, 16 Oct 2012 19:43:13 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOD2m-0002cr-Cn
	for Xen-devel@lists.xensource.com; Tue, 16 Oct 2012 19:43:12 +0000
Received: from [193.109.254.147:33897] by server-15.bemta-14.messagelabs.com
	id FD/E5-16351-FC8BD705; Tue, 16 Oct 2012 19:43:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1350416590!3763049!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQzMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16784 invoked from network); 16 Oct 2012 19:43:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 19:43:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,595,1344211200"; d="scan'208";a="15211572"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Oct 2012 19:43:09 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 16 Oct 2012 20:43:09 +0100
Message-ID: <1350416588.28188.0.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Mukesh Rathor 
Date: Tue, 16 Oct 2012 20:43:08 +0100
In-Reply-To: <20121016104657.4b2478a8@mantra.us.oracle.com>
References: <20121011145817.0d744c99@mantra.us.oracle.com>
	<1350032276.14806.53.camel@zakaz.uk.xensource.com>
	<1350404821.2460.3.camel@zakaz.uk.xensource.com>
	<20121016104657.4b2478a8@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V2 3/7]: PVH:  mmu related changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-16 at 10:46 -0700, Mukesh Rathor wrote:
> On Tue, 16 Oct 2012 17:27:01 +0100
> Ian Campbell  wrote:
> 
> > On Fri, 2012-10-12 at 09:57 +0100, Ian Campbell wrote:
> > > > +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma)
> > > > +{
> > > > +       int numpgs = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
> > > > +       struct page **pages = vma ? vma->vm_private_data : NULL;
> > > 
> > > I thought we agreed to keep uses of vm_private_data in the privcmd
> > > driver?
> > > 
> > > I think you should just add pages and nr as direct parameters to
> > > this function, which is symmetric with the map call.
> > 
> > I had to look at this while rebasing my arm patches, turned out to be
> > fairly simple. Feel free to either fold in or badger me for a proper
> > commit message.
> 
> 
> I made similar change in my tree, except I am not passing vma as its
> not needed. I guess you just wanna be consistend with remap, or future
> use?

Consistency mostly.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 20:38:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 20:38:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TODtu-0003k0-5p; Tue, 16 Oct 2012 20:38:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TODtt-0003ju-0j
	for xen-devel@lists.xensource.com; Tue, 16 Oct 2012 20:38:05 +0000
Received: from [85.158.143.99:12654] by server-2.bemta-4.messagelabs.com id
	BD/9F-22268-CA5CD705; Tue, 16 Oct 2012 20:38:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1350419883!26847340!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQzMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21006 invoked from network); 16 Oct 2012 20:38:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 20:38:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,595,1344211200"; d="scan'208";a="15212186"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Oct 2012 20:38:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 16 Oct 2012 21:38:03 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TODtr-000092-1j;
	Tue, 16 Oct 2012 20:38:03 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TODtq-0001YT-Ln;
	Tue, 16 Oct 2012 21:38:02 +0100
To: 
Message-ID: 
From: xen.org 
Date: Tue, 16 Oct 2012 21:38:02 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13972: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13972 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13972/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 13967
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-pv            5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl           5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                fail REGR. vs. 13967
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 13967
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 13967
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 13967
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot          fail REGR. vs. 13967

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13967
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13967

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  4fc87c2f31a0
baseline version:
 xen                  c1c549c4fe9e

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf 
  Huang Ying 
  Jan Beulich 
  Keir Fraser 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26060:4fc87c2f31a0
tag:         tip
user:        Huang Ying 
date:        Tue Oct 16 17:26:36 2012 +0200
    
    ACPI: fix APEI related table size checking
    
    On Huang Ying's machine:
    
    erst_tab->header_length == sizeof(struct acpi_table_einj)
    
    but Yinghai reported that on his machine,
    
    erst_tab->header_length == sizeof(struct acpi_table_einj) -
    sizeof(struct acpi_table_header)
    
    To make erst table size checking code works on all systems, both
    testing are treated as PASS.
    
    Same situation applies to einj_tab->header_length, so corresponding
    table size checking is changed in similar way too.
    
    Originally-by: Yinghai Lu 
    Signed-off-by: Huang Ying 
    
    - use switch() for better readability
    - add comment explaining why a formally invalid size it also being
      accepted
    - check erst_tab->header.length before even looking at
      erst_tab->header_length
    - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    Committed-by: Jan Beulich 
    
    
changeset:   26059:c1c549c4fe9e
user:        Daniel De Graaf 
date:        Mon Oct 15 16:51:44 2012 +0100
    
    xen: Add versions of rcu_lock_*_domain without IS_PRIV
    
    These functions will be used to avoid duplication of IS_PRIV calls
    that will be introduced in XSM hooks. This also fixes a build error
    with XSM enabled introduced by 25925:d1c3375c3f11 which depends on
    this patch.
    
    Signed-off-by: Daniel De Graaf 
    Committed-by: Keir Fraser 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 20:38:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 20:38:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TODtu-0003k0-5p; Tue, 16 Oct 2012 20:38:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TODtt-0003ju-0j
	for xen-devel@lists.xensource.com; Tue, 16 Oct 2012 20:38:05 +0000
Received: from [85.158.143.99:12654] by server-2.bemta-4.messagelabs.com id
	BD/9F-22268-CA5CD705; Tue, 16 Oct 2012 20:38:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1350419883!26847340!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQzMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21006 invoked from network); 16 Oct 2012 20:38:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 20:38:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,595,1344211200"; d="scan'208";a="15212186"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Oct 2012 20:38:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 16 Oct 2012 21:38:03 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TODtr-000092-1j;
	Tue, 16 Oct 2012 20:38:03 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TODtq-0001YT-Ln;
	Tue, 16 Oct 2012 21:38:02 +0100
To: 
Message-ID: 
From: xen.org 
Date: Tue, 16 Oct 2012 21:38:02 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13972: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13972 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13972/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 13967
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-pv            5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl           5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                fail REGR. vs. 13967
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 13967
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 13967
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 13967
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot          fail REGR. vs. 13967

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13967
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13967

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  4fc87c2f31a0
baseline version:
 xen                  c1c549c4fe9e

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf 
  Huang Ying 
  Jan Beulich 
  Keir Fraser 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26060:4fc87c2f31a0
tag:         tip
user:        Huang Ying 
date:        Tue Oct 16 17:26:36 2012 +0200
    
    ACPI: fix APEI related table size checking
    
    On Huang Ying's machine:
    
    erst_tab->header_length == sizeof(struct acpi_table_einj)
    
    but Yinghai reported that on his machine,
    
    erst_tab->header_length == sizeof(struct acpi_table_einj) -
    sizeof(struct acpi_table_header)
    
    To make erst table size checking code works on all systems, both
    testing are treated as PASS.
    
    Same situation applies to einj_tab->header_length, so corresponding
    table size checking is changed in similar way too.
    
    Originally-by: Yinghai Lu 
    Signed-off-by: Huang Ying 
    
    - use switch() for better readability
    - add comment explaining why a formally invalid size it also being
      accepted
    - check erst_tab->header.length before even looking at
      erst_tab->header_length
    - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    Committed-by: Jan Beulich 
    
    
changeset:   26059:c1c549c4fe9e
user:        Daniel De Graaf 
date:        Mon Oct 15 16:51:44 2012 +0100
    
    xen: Add versions of rcu_lock_*_domain without IS_PRIV
    
    These functions will be used to avoid duplication of IS_PRIV calls
    that will be introduced in XSM hooks. This also fixes a build error
    with XSM enabled introduced by 25925:d1c3375c3f11 which depends on
    this patch.
    
    Signed-off-by: Daniel De Graaf 
    Committed-by: Keir Fraser 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 21:50:06 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 21:50:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOF17-0004wH-Ho; Tue, 16 Oct 2012 21:49:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOBlY-0001iz-FT
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 18:21:21 +0000
Received: from [85.158.139.211:48270] by server-11.bemta-5.messagelabs.com id
	C6/6D-14870-F95AD705; Tue, 16 Oct 2012 18:21:19 +0000
X-Env-Sender: robert.phillips@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1350411671!22550474!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODI3MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16482 invoked from network); 16 Oct 2012 18:21:12 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 18:21:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,595,1344211200"; 
	d="pdf'?scan'208";a="211462230"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Oct 2012 18:21:09 +0000
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.210]) by
	FTLPMAILMX02.citrite.net ([10.13.107.66]) with mapi; Tue, 16 Oct 2012
	14:21:09 -0400
From: Robert Phillips 
To: Robert Phillips , "xen-devel@lists.xen.org"
	
Date: Tue, 16 Oct 2012 14:21:06 -0400
Thread-Topic: [PATCH] Provide support for multiple frame buffers in Xen.
Thread-Index: Ac2ryjJfok0EFoLpROOgASMeFBLV8gAAL2CQ
Message-ID: <048EAD622912254A9DEA24C1734613C18C86D229FF@FTLPMAILBOX02.citrite.net>
References: <1350411302-5470-1-git-send-email-robert.phillips@citrix.com>
In-Reply-To: <1350411302-5470-1-git-send-email-robert.phillips@citrix.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/mixed;
	boundary="_002_048EAD622912254A9DEA24C1734613C18C86D229FFFTLPMAILBOX02_"
MIME-Version: 1.0
X-Mailman-Approved-At: Tue, 16 Oct 2012 21:49:35 +0000
Subject: Re: [Xen-devel] [PATCH] Provide support for multiple frame buffers
	in Xen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_048EAD622912254A9DEA24C1734613C18C86D229FFFTLPMAILBOX02_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Here is a document describing this patch.

Robert Phillips
Principal Software Engineer,  XenClient-Enterprise - Westford
robert.phillips@citrix.com

-----Original Message-----
From: Robert Phillips [mailto:robert.phillips@citrix.com]
Sent: Tuesday, October 16, 2012 2:15 PM
To: xen-devel@lists.xen.org
Cc: Robert Phillips; Robert Phillips
Subject: [PATCH] Provide support for multiple frame buffers in Xen.

From: Robert Phillips 

Support is provided for both shadow and hardware assisted paging (HAP) mode=
s.
This code bookkeeps the set of video frame buffers (vram),
detects when the guest has modified any of those buffers and, upon request,
returns a bitmap of the modified pages.

This lets other software components re-paint the portions of the monitor (o=
r monitors) that have changed.
Each monitor has a frame buffer of some size at some position in guest phys=
ical memory.
The set of frame buffers being tracked can change over time as monitors are=
 plugged and unplugged.

Signed-Off-By: Robert Phillips 
---
 xen/arch/x86/hvm/Makefile            |    3 +-
 xen/arch/x86/hvm/dirty_vram.c        |  878 ++++++++++++++++++++++++++++++=
++++
 xen/arch/x86/hvm/hvm.c               |    4 +-
 xen/arch/x86/mm/hap/hap.c            |  140 +-----
 xen/arch/x86/mm/paging.c             |  232 ++++-----
 xen/arch/x86/mm/shadow/common.c      |  335 +++++++------
 xen/arch/x86/mm/shadow/multi.c       |  169 +++----
 xen/arch/x86/mm/shadow/multi.h       |    7 +-
 xen/arch/x86/mm/shadow/types.h       |    1 +
 xen/include/asm-x86/hap.h            |    4 -
 xen/include/asm-x86/hvm/dirty_vram.h |  157 ++++++
 xen/include/asm-x86/hvm/domain.h     |    2 +-
 xen/include/asm-x86/paging.h         |   22 +-
 xen/include/asm-x86/shadow.h         |    6 -
 14 files changed, 1403 insertions(+), 557 deletions(-)
 create mode 100644 xen/arch/x86/hvm/dirty_vram.c
 create mode 100644 xen/include/asm-x86/hvm/dirty_vram.h

diff --git a/xen/arch/x86/hvm/Makefile b/xen/arch/x86/hvm/Makefile
index eea5555..f37736b 100644
--- a/xen/arch/x86/hvm/Makefile
+++ b/xen/arch/x86/hvm/Makefile
@@ -2,6 +2,7 @@ subdir-y +=3D svm
 subdir-y +=3D vmx

 obj-y +=3D asid.o
+obj-y +=3D dirty_vram.o
 obj-y +=3D emulate.o
 obj-y +=3D hpet.o
 obj-y +=3D hvm.o
@@ -22,4 +23,4 @@ obj-y +=3D vlapic.o
 obj-y +=3D vmsi.o
 obj-y +=3D vpic.o
 obj-y +=3D vpt.o
-obj-y +=3D vpmu.o
\ No newline at end of file
+obj-y +=3D vpmu.o
diff --git a/xen/arch/x86/hvm/dirty_vram.c b/xen/arch/x86/hvm/dirty_vram.c
new file mode 100644
index 0000000..22375c2
--- /dev/null
+++ b/xen/arch/x86/hvm/dirty_vram.c
@@ -0,0 +1,878 @@
+/*
+ * arch/x86/hvm/dirty_vram.c: Bookkeep/query dirty VRAM pages
+ * with support for multiple frame buffers.
+ *
+ * Copyright (c) 2012, Citrix Systems, Inc. (Robert Phillips)
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License f=
or
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along=
 with
+ * this program; if not, write to the Free Software Foundation, Inc., 59 T=
emple
+ * Place - Suite 330, Boston, MA 02111-1307 USA.
+ */
+
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "../mm/mm-locks.h"
+
+#define DEBUG_stop_tracking_all_vram          1
+#define DEBUG_allocating_dirty_vram_range     1
+#define DEBUG_high_water_mark_for_vram_ranges 1
+#define DEBUG_freeing_dirty_vram_range        1
+#define DEBUG_allocate_paddr_links_page       0
+#define DEBUG_update_vram_mapping             0
+
+/* Allocates domain's dirty_vram structure */
+dv_dirty_vram_t *
+dirty_vram_alloc(struct domain *d)
+{
+    dv_dirty_vram_t *dirty_vram;
+    ASSERT( paging_locked_by_me(d) );
+    dirty_vram =3D d->arch.hvm_domain.dirty_vram =3D xmalloc(dv_dirty_vram=
_t);
+    if ( dirty_vram )
+    {
+        memset(dirty_vram, 0, sizeof(*dirty_vram));
+        INIT_LIST_HEAD(&dirty_vram->range_head);
+        INIT_LIST_HEAD(&dirty_vram->ext_head);
+    }
+    return dirty_vram;
+}
+
+/* Returns domain's dirty_vram structure,
+ * allocating it if necessary */
+dv_dirty_vram_t *
+dirty_vram_find_or_alloc(struct domain *d)
+{
+    dv_dirty_vram_t *dirty_vram =3D d->arch.hvm_domain.dirty_vram;
+    ASSERT( paging_locked_by_me(d) );
+    if ( !dirty_vram )
+        dirty_vram =3D dirty_vram_alloc(d);
+    return dirty_vram;
+}
+
+
+/* Free domain's dirty_vram structure */
+void dirty_vram_free(struct domain *d)
+{
+    dv_dirty_vram_t *dirty_vram =3D d->arch.hvm_domain.dirty_vram;
+    ASSERT( paging_locked_by_me(d) );
+    if ( dirty_vram )
+    {
+        struct list_head *curr, *next;
+        /* Free all the ranges */
+        list_for_each_safe(curr, next, &dirty_vram->range_head)
+        {
+            dv_range_t *range =3D list_entry(curr, dv_range_t, range_link)=
;
+#if DEBUG_stop_tracking_all_vram
+            gdprintk(XENLOG_DEBUG, "[%05lx:%05lx] stop tracking all vram\n=
",
+                     range->begin_pfn, range->end_pfn);
+#endif
+            xfree(range->pl_tab);
+            xfree(range);
+        }
+        /* Free all the extension pages */
+        list_for_each_safe(curr, next, &dirty_vram->ext_head)
+        {
+            xfree(curr);
+        }
+        xfree(dirty_vram);
+        d->arch.hvm_domain.dirty_vram =3D NULL;
+    }
+}
+
+/* Returns dirty vram range containing gfn, NULL if none */
+struct dv_range *
+dirty_vram_range_find_gfn(struct domain *d,
+                          unsigned long gfn)
+{
+    struct dv_dirty_vram *dirty_vram =3D d->arch.hvm_domain.dirty_vram;
+    ASSERT( paging_locked_by_me(d) );
+    if ( dirty_vram )
+    {
+        struct list_head *curr;
+        list_for_each(curr, &dirty_vram->range_head)
+        {
+            dv_range_t *range =3D list_entry(curr, dv_range_t, range_link)=
;
+            if ( gfn >=3D range->begin_pfn &&
+                 gfn <  range->end_pfn )
+            {
+                return range;
+            }
+        }
+    }
+    return NULL;
+}
+
+/* Returns pointer to dirty vram range matching [begin_pfn .. end_pfn ), N=
ULL if none. */
+dv_range_t *
+dirty_vram_range_find(struct domain *d,
+                      unsigned long begin_pfn,
+                      unsigned long nr)
+{
+    unsigned long end_pfn =3D begin_pfn + nr;
+    dv_dirty_vram_t *dirty_vram =3D d->arch.hvm_domain.dirty_vram;
+    ASSERT( paging_locked_by_me(d) );
+    if ( dirty_vram )
+    {
+        struct list_head *curr;
+        list_for_each(curr, &dirty_vram->range_head)
+        {
+            dv_range_t *range =3D list_entry(curr, dv_range_t, range_link)=
;
+            if ( begin_pfn =3D=3D range->begin_pfn &&
+                 end_pfn   =3D=3D range->end_pfn )
+            {
+                return range;
+            }
+        }
+    }
+    return NULL;
+}
+
+/* Allocate specified dirty_vram range */
+static dv_range_t *
+_dirty_vram_range_alloc(struct domain *d,
+                        unsigned long begin_pfn,
+                        unsigned long nr)
+{
+    dv_dirty_vram_t *dirty_vram =3D d->arch.hvm_domain.dirty_vram;
+    dv_range_t *range =3D NULL;
+    unsigned long end_pfn =3D begin_pfn + nr;
+    dv_paddr_link_t *pl_tab =3D NULL;
+    int i;
+
+    ASSERT( paging_locked_by_me(d) );
+    ASSERT( dirty_vram !=3D NULL );
+
+#if DEBUG_allocating_dirty_vram_range
+    gdprintk(XENLOG_DEBUG,
+             "[%05lx:%05lx] Allocating dirty vram range hap:%d\n",
+             begin_pfn, end_pfn,
+             d->arch.hvm_domain.hap_enabled);
+#endif
+
+    range =3D xmalloc(dv_range_t);
+    if (range =3D=3D NULL)
+        goto err_out;
+
+    memset(range, 0, sizeof(dv_range_t));
+    INIT_LIST_HEAD(&range->range_link);
+
+    range->begin_pfn =3D begin_pfn;
+    range->end_pfn =3D end_pfn;
+
+    if (!hap_enabled(d))
+    {
+        if ( (pl_tab =3D xmalloc_array(dv_paddr_link_t, nr)) =3D=3D NULL )
+        {
+            goto err_out;
+        }
+        for (i =3D 0; i !=3D nr; i++)
+        {
+            pl_tab[i].sl1ma =3D INVALID_PADDR;
+            pl_tab[i].pl_next =3D NULL;
+        }
+    }
+
+    range->pl_tab =3D pl_tab;
+    range->mappings_hwm =3D 1;
+
+    list_add(&range->range_link, &dirty_vram->range_head);
+    if ( ++dirty_vram->nr_ranges > dirty_vram->ranges_hwm )
+    {
+        dirty_vram->ranges_hwm =3D dirty_vram->nr_ranges;
+#if DEBUG_high_water_mark_for_vram_ranges
+        gdprintk(XENLOG_DEBUG,
+                 "High water mark for number of vram ranges is now:%d\n",
+                 dirty_vram->ranges_hwm);
+#endif
+    }
+    return range;
+
+ err_out:
+    xfree(pl_tab);
+    xfree(range);
+    return NULL;
+}
+
+
+/* Frees specified dirty_vram range */
+void dirty_vram_range_free(struct domain *d,
+                           dv_range_t *range)
+{
+    dv_dirty_vram_t *dirty_vram =3D d->arch.hvm_domain.dirty_vram;
+    ASSERT( paging_locked_by_me(d) );
+    if ( dirty_vram )
+    {
+        int i, nr =3D range->end_pfn - range->begin_pfn;
+
+#if DEBUG_freeing_dirty_vram_range
+        gdprintk(XENLOG_DEBUG,
+                 "[%05lx:%05lx] Freeing dirty vram range\n",
+                 range->begin_pfn, range->end_pfn);
+#endif
+
+        if (range->pl_tab)
+        {
+            for (i =3D 0; i !=3D nr; i++)
+            {
+                dv_paddr_link_t *plx;
+                plx =3D range->pl_tab[i].pl_next;
+                /* Does current FB page have multiple mappings? */
+                if (plx) /* yes */
+                {
+                    /* Find the last element in singly-linked list */
+                    while (plx->pl_next !=3D NULL)
+                        plx =3D plx->pl_next;
+                    /* Prepend whole list to the free list */
+                    plx->pl_next =3D dirty_vram->pl_free;
+                    dirty_vram->pl_free =3D range->pl_tab[i].pl_next;
+                }
+            }
+            xfree(range->pl_tab);
+            range->pl_tab =3D NULL;
+        }
+
+        /* Remove range from the linked list, free it, and adjust count*/
+        list_del(&range->range_link);
+        xfree(range);
+        dirty_vram->nr_ranges--;
+    }
+}
+
+/* dirty_vram_range_alloc()
+ * This function ensures that the new range does not overlap any existing
+ * ranges -- deleting them if necessary -- and then calls _dirty_vram_rang=
e_alloc
+ * to actually allocate the new range.
+ */
+dv_range_t *
+dirty_vram_range_alloc(struct domain *d,
+                        unsigned long begin_pfn,
+                        unsigned long nr)
+{
+    unsigned long end_pfn =3D begin_pfn + nr;
+    dv_dirty_vram_t *dirty_vram =3D d->arch.hvm_domain.dirty_vram;
+    dv_range_t *range;
+    struct list_head *curr, *next;
+
+    ASSERT( paging_locked_by_me(d) );
+    ASSERT( dirty_vram !=3D NULL );
+
+    /* Ranges cannot overlap so
+     * free any range that overlaps [ begin_pfn .. end_pfn ) */
+    list_for_each_safe(curr, next, &dirty_vram->range_head)
+    {
+        dv_range_t *rng =3D list_entry(curr, dv_range_t, range_link);
+        if ( ((rng->begin_pfn <=3D begin_pfn) && (begin_pfn <  rng->end_pf=
n)) ||
+             ((begin_pfn <=3D rng->begin_pfn) && (rng->begin_pfn < end_pfn=
)) )
+        {
+            /* Different tracking, tear the previous down. */
+            dirty_vram_range_free(d, rng);
+        }
+    }
+
+    range =3D _dirty_vram_range_alloc(d, begin_pfn, nr);
+    if ( !range )
+        goto out;
+
+ out:
+    return range;
+}
+
+/* dirty_vram_range_find_or_alloc()
+ * Find the range for [begin_pfn:begin_pfn+nr).
+ * If it doesn't exists, create it.
+ */
+dv_range_t *
+dirty_vram_range_find_or_alloc(struct domain *d,
+                                unsigned long begin_pfn,
+                                unsigned long nr)
+{
+    dv_range_t *range;
+    ASSERT( paging_locked_by_me(d) );
+    range =3D dirty_vram_range_find(d, begin_pfn, nr);
+    if ( !range )
+        range =3D dirty_vram_range_alloc(d, begin_pfn, nr);
+    return range;
+}
+
+
+
+/* Allocate a dv_paddr_link struct */
+static dv_paddr_link_t *
+alloc_paddr_link(struct domain *d)
+{
+    dv_paddr_link_t * pl =3D NULL;
+    dv_dirty_vram_t *dirty_vram =3D d->arch.hvm_domain.dirty_vram;
+
+    ASSERT( paging_locked_by_me(d) );
+    BUILD_BUG_ON(sizeof(dv_paddr_link_ext_t) > PAGE_SIZE);
+    /* Is the list of free pl's empty? */
+    if (dirty_vram->pl_free =3D=3D NULL) /* yes */
+    {
+        /* Allocate another page of pl's.
+         * Link them all together and point the free list head at them */
+        int i;
+        dv_paddr_link_ext_t *ext =3D xmalloc(dv_paddr_link_ext_t);
+        if (ext =3D=3D NULL)
+            goto out;
+
+#if DEBUG_allocate_paddr_links_page
+        gdprintk(XENLOG_DEBUG, "Allocated another page of paddr_links\n");
+#endif
+        list_add(&ext->ext_link, &dirty_vram->ext_head);
+
+        /* initialize and link together the new pl entries */
+        for (i =3D 0; i !=3D ARRAY_SIZE(ext->entries); i++)
+        {
+            ext->entries[i].sl1ma =3D INVALID_PADDR;
+            ext->entries[i].pl_next =3D &ext->entries[i+1];
+        }
+        ext->entries[ARRAY_SIZE(ext->entries) - 1].pl_next =3D NULL;
+        dirty_vram->pl_free =3D &ext->entries[0];
+    }
+    pl =3D dirty_vram->pl_free;
+    dirty_vram->pl_free =3D pl->pl_next;
+
+    pl->sl1ma =3D INVALID_PADDR;
+    pl->pl_next =3D NULL;
+ out:
+    return pl;
+}
+
+
+/* Free a paddr_link struct, given address of its predecessor in linked li=
st */
+dv_paddr_link_t *
+free_paddr_link(struct domain *d,
+                dv_paddr_link_t **ppl,
+                dv_paddr_link_t *pl)
+{
+    dv_dirty_vram_t *dirty_vram =3D d->arch.hvm_domain.dirty_vram;
+    dv_paddr_link_t *npl; /* next pl */
+
+    ASSERT( paging_locked_by_me(d) );
+    /* extension mapping? */
+    if (ppl) /* yes. free it */
+    {
+        pl =3D (*ppl);
+        (*ppl) =3D npl =3D pl->pl_next;
+    }
+    else  /* main table */
+    {
+        /* move 2nd mapping to main table.
+         * and free 2nd mapping */
+        dv_paddr_link_t * spl;
+        spl =3D pl->pl_next;
+        if (spl =3D=3D NULL)
+        {
+            pl->sl1ma =3D INVALID_PADDR;
+            return pl;
+        }
+        pl->sl1ma =3D spl->sl1ma;
+        pl->pl_next =3D spl->pl_next;
+        npl =3D pl; /* reprocess main table entry again */
+        pl =3D spl;
+    }
+    pl->sl1ma =3D INVALID_PADDR;
+    pl->pl_next =3D dirty_vram->pl_free;
+    dirty_vram->pl_free =3D pl;
+    return npl;
+}
+
+
+/* dirty_vram_range_update()
+ * This is called whenever a level 1 page table entry is modified.
+ * If the L1PTE is being cleared, the function removes any paddr_links
+ * that refer to it.
+ * If the L1PTE is being set to a frame buffer page, a paddr_link is
+ * created for that page's entry in pl_tab.
+ * Returns 1 iff entry found and set or cleared.
+ */
+int dirty_vram_range_update(struct domain *d,
+                            unsigned long gfn,
+                            paddr_t sl1ma,
+                            int set)
+{
+    int effective =3D 0;
+    dv_range_t *range;
+
+    ASSERT(paging_locked_by_me(d));
+    range =3D dirty_vram_range_find_gfn(d, gfn);
+    if ( range )
+    {
+        unsigned long i =3D gfn - range->begin_pfn;
+        dv_paddr_link_t *pl =3D &range->pl_tab[ i ];
+        dv_paddr_link_t **ppl =3D NULL;
+        int len =3D 0;
+
+        /* find matching entry (pl), if any, and its predecessor
+         * in linked list (ppl) */
+        while (pl !=3D NULL)
+        {
+            if (pl->sl1ma =3D=3D sl1ma || pl->sl1ma =3D=3D INVALID_PADDR )
+                break;
+            ppl =3D &pl->pl_next;
+            pl =3D *ppl;
+            len++;
+        }
+
+        if (set)
+        {
+            /* Did we find sl1ma in either the main table or the linked li=
st? */
+            if (pl =3D=3D NULL) /* no, so we'll need to alloc a link */
+            {
+                ASSERT(ppl !=3D NULL);
+                /* alloc link and append it to list */
+                (*ppl) =3D pl =3D alloc_paddr_link(d);
+                if (pl =3D=3D NULL)
+                    goto out;
+            }
+            if ( pl->sl1ma !=3D sl1ma )
+            {
+                pl->sl1ma =3D sl1ma;
+                range->nr_mappings++;
+            }
+            effective =3D 1;
+            if (len > range->mappings_hwm)
+            {
+                range->mappings_hwm =3D len;
+#if DEBUG_update_vram_mapping
+                gdprintk(XENLOG_DEBUG,
+                         "[%lx] set      sl1ma:%lx hwm:%d mappings:%d free=
pages:%d\n",
+                         gfn, sl1ma,
+                         range->mappings_hwm,
+                         range->nr_mappings,
+                         d->arch.paging.shadow.free_pages);
+#endif
+            }
+        }
+        else /* clear */
+        {
+            if (pl && pl->sl1ma =3D=3D sl1ma )
+            {
+#if DEBUG_update_vram_mapping
+                gdprintk(XENLOG_DEBUG,
+                         "[%lx] clear    sl1ma:%lx mappings:%d\n",
+                         gfn, sl1ma,
+                         range->nr_mappings-1);
+#endif
+                free_paddr_link(d, ppl, pl);
+                if ( --range->nr_mappings =3D=3D 0 )
+                {
+                    dirty_vram_range_free(d, range);
+                }
+                effective =3D 1;
+            }
+        }
+    }
+ out:
+    return effective;
+}
+
+
+/* shadow_scan_dirty_flags()
+ * This produces a dirty bitmap for the range by examining every
+ * L1PTE referenced by some dv_paddr_link in the range's pl_tab table.
+ * It tests and clears each such L1PTE's dirty flag.
+ */
+static int shadow_scan_dirty_flags(struct domain *d,
+                                   dv_range_t *range,
+                                   uint8_t *dirty_bitmap)
+{
+    int flush_tlb =3D 0;
+    unsigned long i;
+    unsigned long nr =3D range->end_pfn - range->begin_pfn;
+#ifdef __i386__
+    unsigned long map_mfn =3D INVALID_MFN;
+    void *map_sl1p =3D NULL;
+#endif
+
+    ASSERT( paging_locked_by_me(d) );
+    /* Iterate over VRAM to track dirty bits. */
+    for ( i =3D 0; i < nr; i++ )
+    {
+        int dirty =3D 0, len =3D 1;
+        dv_paddr_link_t *pl;
+        for (pl =3D &range->pl_tab[i]; pl; pl =3D pl->pl_next, len++)
+        {
+#ifdef __i386__
+            void *sl1p;
+            unsigned long sl1mfn;
+#endif
+            l1_pgentry_t *sl1e;
+            paddr_t sl1ma =3D pl->sl1ma;
+            if (sl1ma =3D=3D INVALID_PADDR) /* FB page is unmapped */
+                continue;
+#ifdef __i386__
+            sl1p =3D map_sl1p;
+            sl1mfn =3D paddr_to_pfn(sl1ma);
+
+            if ( sl1mfn !=3D map_mfn )
+            {
+                if ( map_sl1p )
+                    sh_unmap_domain_page(map_sl1p);
+                map_sl1p =3D sl1p =3D sh_map_domain_page(_mfn(sl1mfn));
+                map_mfn =3D sl1mfn;
+            }
+            sl1e =3D sl1p + (sl1ma & ~PAGE_MASK);
+#else
+            sl1e =3D maddr_to_virt(sl1ma);
+#endif
+            if ( l1e_get_flags(*sl1e) & _PAGE_DIRTY )
+            {
+                dirty =3D 1;
+                /* Clear dirty so we can detect if page gets re-dirtied */
+                /* Note: this is atomic, so we may clear a
+                 * _PAGE_ACCESSED set by another processor. */
+                l1e_remove_flags(*sl1e, _PAGE_DIRTY);
+                flush_tlb =3D 1;
+            }
+        } /* for */
+        if ( dirty )
+        {
+            dirty_bitmap[i >> 3] |=3D (1 << (i & 7));
+        }
+    }
+
+#ifdef __i386__
+    if ( map_sl1p )
+        sh_unmap_domain_page(map_sl1p);
+#endif
+    return flush_tlb;
+}
+
+
+/* shadow_track_dirty_vram()
+ * This is the API called by the guest to determine which pages in the ran=
ge
+ * from [begin_pfn:begin_pfn+nr) have been dirtied since the last call.
+ * It creates the domain's dv_dirty_vram on demand.
+ * It creates ranges on demand when some [begin_pfn:nr) is first encounter=
ed.
+ * To collect the dirty bitmask it calls shadow_scan_dirty_flags().
+ * It copies the dirty bitmask into guest storage.
+ */
+int shadow_track_dirty_vram(struct domain *d,
+                            unsigned long begin_pfn,
+                            unsigned long nr,
+                            XEN_GUEST_HANDLE_64(uint8) guest_dirty_bitmap)
+{
+    int rc =3D 0;
+    unsigned long end_pfn =3D begin_pfn + nr;
+    int flush_tlb =3D 0;
+    dv_range_t *range;
+    struct p2m_domain *p2m =3D p2m_get_hostp2m(d);
+
+    if (end_pfn < begin_pfn
+            || begin_pfn > p2m->max_mapped_pfn
+            || end_pfn >=3D p2m->max_mapped_pfn)
+        return -EINVAL;
+
+    paging_lock(d);
+
+    if ( !nr || guest_handle_is_null(guest_dirty_bitmap) )
+    {
+        goto out;
+    }
+
+    if ( !dirty_vram_find_or_alloc(d))
+    {
+        rc =3D -ENOMEM;
+        goto out;
+    }
+
+    range =3D dirty_vram_range_find(d, begin_pfn, nr);
+    if ( !range )
+    {
+        range =3D dirty_vram_range_alloc(d, begin_pfn, nr);
+        if ( range )
+            sh_find_all_vram_mappings(d->vcpu[0], range);
+    }
+    if ( range )
+    {
+        int size =3D (nr + BITS_PER_LONG - 1) / BITS_PER_LONG;
+        unsigned long dirty_bitmap[size];
+
+        memset(dirty_bitmap, 0x00, size * BYTES_PER_LONG);
+
+       flush_tlb |=3D shadow_scan_dirty_flags(d, range, (uint8_t*)dirty_bi=
tmap);
+
+        rc =3D -EFAULT;
+        if ( copy_to_guest(guest_dirty_bitmap,
+                           (uint8_t*)dirty_bitmap,
+                           size * BYTES_PER_LONG) =3D=3D 0 )
+            rc =3D 0;
+    }
+    if ( flush_tlb )
+        flush_tlb_mask(d->domain_dirty_cpumask);
+
+out:
+    paging_unlock(d);
+    return rc;
+}
+
+
+/************************************************/
+/*          HAP VRAM TRACKING SUPPORT           */
+/************************************************/
+
+/* hap_enable_vram_tracking()
+ * For all ranges, mark all vram pages in range as logdirty read-only.
+ */
+static int hap_enable_vram_tracking(struct domain *d)
+{
+    int rc =3D 0;
+    dv_dirty_vram_t *dirty_vram;
+    struct list_head *curr;
+
+    /* turn on PG_log_dirty bit in paging mode */
+    paging_lock(d);
+    d->arch.paging.mode |=3D PG_log_dirty;
+    paging_unlock(d);
+
+    p2m_lock(p2m_get_hostp2m(d));
+    paging_lock(d);
+
+    dirty_vram =3D d->arch.hvm_domain.dirty_vram;
+
+    /* dirty_vram !=3D NULL iff we're tracking dirty vram.
+     * If we start tracking dirty pages for all memory then
+     * the dirty_vram structure is freed. */
+    if ( !dirty_vram )
+    {
+        rc =3D -EINVAL;
+        goto out;
+    }
+
+    /* set l1e entries of P2M table to be read-only. */
+    list_for_each(curr, &dirty_vram->range_head)
+      {
+       dv_range_t *range =3D list_entry(curr, dv_range_t, range_link);
+       gdprintk(XENLOG_DEBUG, "[%05lx:%05lx] enable  vram tracking\n",
+                range->begin_pfn, range->end_pfn);
+       p2m_change_type_range(d, range->begin_pfn, range->end_pfn,
+                             p2m_ram_rw, p2m_ram_logdirty);
+      }
+
+    flush_tlb_mask(d->domain_dirty_cpumask);
+ out:
+    paging_unlock(d);
+    p2m_unlock(p2m_get_hostp2m(d));
+    if (rc)
+    {
+        paging_lock(d);
+        d->arch.paging.mode &=3D ~PG_log_dirty;
+        paging_unlock(d);
+    }
+    return rc;
+}
+
+/* hap_disable_vram_tracking()
+ * For all ranges, mark all vram pages in range as logdirty read-write.
+ */
+static int hap_disable_vram_tracking(struct domain *d)
+{
+    int rc =3D 0;
+    dv_dirty_vram_t *dirty_vram;
+    struct list_head *curr;
+
+    paging_lock(d);
+    d->arch.paging.mode &=3D ~PG_log_dirty;
+    paging_unlock(d);
+
+    p2m_lock(p2m_get_hostp2m(d));
+    paging_lock(d);
+
+    dirty_vram =3D d->arch.hvm_domain.dirty_vram;
+    if ( !dirty_vram )
+    {
+        rc =3D -EINVAL;
+        goto out;
+    }
+
+    /* set l1e entries of P2M table with normal mode */
+    list_for_each(curr, &dirty_vram->range_head)
+      {
+       dv_range_t *range =3D list_entry(curr, dv_range_t, range_link);
+       gdprintk(XENLOG_DEBUG, "[%05lx:%05lx] disable vram tracking\n",
+                range->begin_pfn, range->end_pfn);
+       p2m_change_type_range(d, range->begin_pfn, range->end_pfn,
+                             p2m_ram_logdirty, p2m_ram_rw);
+      }
+    flush_tlb_mask(d->domain_dirty_cpumask);
+ out:
+    paging_unlock(d);
+    p2m_unlock(p2m_get_hostp2m(d));
+    if (rc)
+    {
+        paging_lock(d);
+        d->arch.paging.mode |=3D PG_log_dirty;
+        paging_unlock(d);
+    }
+    return rc;
+}
+
+/* hap_clean_vram_tracking_range()
+ * For all the pages in the range specified by [begin_pfn,nr),
+ * note in the dirty bitmap any page that has been marked as read-write,
+ * which signifies that the page has been dirtied, and reset the page
+ * to ram_logdirty.
+ */
+void hap_clean_vram_tracking_range(struct domain *d,
+                                   unsigned long begin_pfn,
+                                   unsigned long nr,
+                                   uint8_t *dirty_bitmap)
+{
+    int i;
+    unsigned long pfn;
+    dv_dirty_vram_t *dirty_vram =3D d->arch.hvm_domain.dirty_vram;
+    dv_range_t *range;
+
+    ASSERT(p2m_locked_by_me(p2m_get_hostp2m(d)));
+    ASSERT(paging_locked_by_me(d));
+
+    if ( !dirty_vram )
+    {
+        gdprintk(XENLOG_DEBUG, "Should only be called while tracking dirty=
 vram.\n");
+        return;
+    }
+
+    range =3D dirty_vram_range_find(d, begin_pfn, nr);
+    if (!range)
+        return;
+
+    /* set l1e entries of P2M table to be read-only. */
+    /* On first write, it page faults, its entry is changed to read-write,
+     * its bit in the dirty bitmap is set, and on retry the write succeeds=
. */
+    for (i =3D 0, pfn =3D range->begin_pfn; pfn < range->end_pfn; i++, pfn=
++)
+    {
+        p2m_type_t pt;
+        pt =3D p2m_change_type(d, pfn, p2m_ram_rw, p2m_ram_logdirty);
+        if (pt =3D=3D p2m_ram_rw)
+            dirty_bitmap[i >> 3] |=3D (1 << (i & 7));
+    }
+    flush_tlb_mask(d->domain_dirty_cpumask);
+}
+
+static void hap_vram_tracking_init(struct domain *d)
+{
+    paging_log_dirty_init(d, hap_enable_vram_tracking,
+                          hap_disable_vram_tracking,
+                          NULL);
+}
+
+/* hap_track_dirty_vram()
+ * Create the domain's dv_dirty_vram struct on demand.
+ * Create a dirty vram range on demand when some [begin_pfn:begin_pfn+nr] =
is first encountered.
+ * Collect the guest_dirty bitmask, a bit mask of the dirties vram pages, =
by
+ * calling paging_log_dirty_range().
+ */
+int hap_track_dirty_vram(struct domain *d,
+                         unsigned long begin_pfn,
+                         unsigned long nr,
+                         XEN_GUEST_HANDLE_64(uint8) guest_dirty_bitmap)
+{
+    long rc =3D 0;
+    dv_dirty_vram_t *dirty_vram;
+    int restart_log_dirty =3D 0;
+
+    paging_lock(d);
+    dirty_vram =3D d->arch.hvm_domain.dirty_vram;
+    if ( nr )
+    {
+        dv_range_t *range =3D NULL;
+        int size =3D (nr + BITS_PER_LONG - 1) / BITS_PER_LONG;
+        unsigned long dirty_bitmap[size];
+
+        /* Already tracking dirty vram? */
+        if ( paging_mode_log_dirty(d) && dirty_vram ) /* yes */
+        {
+            /* Handle the addition of another range */
+            range =3D dirty_vram_range_find(d, begin_pfn, nr);
+            if ( !range )
+            {
+                rc =3D -ENOMEM;
+                if ( !(range =3D dirty_vram_range_alloc(d, begin_pfn, nr))=
 )
+                    goto param_fail;
+                restart_log_dirty =3D 1;
+            }
+        }
+        /* Just starting to track dirty vram? */
+        else if ( !paging_mode_log_dirty(d) && !dirty_vram ) /* yes */
+        {
+            rc =3D -ENOMEM;
+            if ( !(dirty_vram =3D dirty_vram_alloc(d)) )
+                goto param_fail;
+
+            if ( !(range =3D dirty_vram_range_find_or_alloc(d, begin_pfn, =
nr)) )
+                goto param_fail;
+
+            restart_log_dirty =3D 1;
+            /* Initialize callbacks for vram tracking */
+            hap_vram_tracking_init(d);
+        }
+        else
+        {
+            /* Test for invalid combination */
+            if ( !paging_mode_log_dirty(d) && dirty_vram )
+                rc =3D -EINVAL;
+            else /* logging dirty of all memory, not tracking dirty vram *=
/
+                rc =3D -ENODATA;
+            goto param_fail;
+        }
+
+        if (restart_log_dirty)
+        {
+            /* disable then enable log dirty */
+            paging_unlock(d);
+            if (paging_mode_log_dirty(d))
+                paging_log_dirty_disable(d);
+
+            rc =3D paging_log_dirty_enable(d);
+            paging_lock(d);
+            if (rc !=3D 0)
+                goto param_fail;
+        }
+
+        paging_unlock(d);
+        memset(dirty_bitmap, 0x00, size * BYTES_PER_LONG);
+       paging_log_dirty_range(d, begin_pfn, nr, (uint8_t*)dirty_bitmap);
+        rc =3D -EFAULT;
+        if ( copy_to_guest(guest_dirty_bitmap,
+                           (uint8_t*)dirty_bitmap,
+                           size * BYTES_PER_LONG) =3D=3D 0 )
+        {
+            rc =3D 0;
+        }
+    }
+    else
+    {
+        /* If zero pages specified while already tracking dirty vram
+         * then stop tracking */
+        if ( paging_mode_log_dirty(d) && dirty_vram ) {
+            paging_unlock(d);
+            rc =3D paging_log_dirty_disable(d);
+            paging_lock(d);
+            dirty_vram_free(d);
+        } else /* benign no-op */
+        {
+            rc =3D 0;
+        }
+        paging_unlock(d);
+    }
+
+    return rc;
+
+param_fail:
+    dirty_vram_free(d);
+    paging_unlock(d);
+    return rc;
+}
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index a5a1bcf..55553e4 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -57,6 +57,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1433,8 +1434,7 @@ int hvm_hap_nested_page_fault(paddr_t gpa,
          */
         if ( access_w )
         {
-            paging_mark_dirty(v->domain, mfn_x(mfn));
-            p2m_change_type(v->domain, gfn, p2m_ram_logdirty, p2m_ram_rw);
+            paging_mark_dirty_hap(v->domain, gfn, mfn_x(mfn));
         }
         rc =3D 1;
         goto out_put_gfn;
diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index d2637d3..f31e4e5 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -41,6 +41,7 @@
 #include 
 #include 
 #include 
+#include 

 #include "private.h"

@@ -53,139 +54,6 @@
 #define page_to_mfn(_pg) _mfn(__page_to_mfn(_pg))

 /************************************************/
-/*          HAP VRAM TRACKING SUPPORT           */
-/************************************************/
-
-static int hap_enable_vram_tracking(struct domain *d)
-{
-    struct sh_dirty_vram *dirty_vram =3D d->arch.hvm_domain.dirty_vram;
-
-    if ( !dirty_vram )
-        return -EINVAL;
-
-    /* turn on PG_log_dirty bit in paging mode */
-    paging_lock(d);
-    d->arch.paging.mode |=3D PG_log_dirty;
-    paging_unlock(d);
-
-    /* set l1e entries of P2M table to be read-only. */
-    p2m_change_type_range(d, dirty_vram->begin_pfn, dirty_vram->end_pfn,
-                          p2m_ram_rw, p2m_ram_logdirty);
-
-    flush_tlb_mask(d->domain_dirty_cpumask);
-    return 0;
-}
-
-static int hap_disable_vram_tracking(struct domain *d)
-{
-    struct sh_dirty_vram *dirty_vram =3D d->arch.hvm_domain.dirty_vram;
-
-    if ( !dirty_vram )
-        return -EINVAL;
-
-    paging_lock(d);
-    d->arch.paging.mode &=3D ~PG_log_dirty;
-    paging_unlock(d);
-
-    /* set l1e entries of P2M table with normal mode */
-    p2m_change_type_range(d, dirty_vram->begin_pfn, dirty_vram->end_pfn,
-                          p2m_ram_logdirty, p2m_ram_rw);
-
-    flush_tlb_mask(d->domain_dirty_cpumask);
-    return 0;
-}
-
-static void hap_clean_vram_tracking(struct domain *d)
-{
-    struct sh_dirty_vram *dirty_vram =3D d->arch.hvm_domain.dirty_vram;
-
-    if ( !dirty_vram )
-        return;
-
-    /* set l1e entries of P2M table to be read-only. */
-    p2m_change_type_range(d, dirty_vram->begin_pfn, dirty_vram->end_pfn,
-                          p2m_ram_rw, p2m_ram_logdirty);
-
-    flush_tlb_mask(d->domain_dirty_cpumask);
-}
-
-static void hap_vram_tracking_init(struct domain *d)
-{
-    paging_log_dirty_init(d, hap_enable_vram_tracking,
-                          hap_disable_vram_tracking,
-                          hap_clean_vram_tracking);
-}
-
-int hap_track_dirty_vram(struct domain *d,
-                         unsigned long begin_pfn,
-                         unsigned long nr,
-                         XEN_GUEST_HANDLE_64(uint8) dirty_bitmap)
-{
-    long rc =3D 0;
-    struct sh_dirty_vram *dirty_vram =3D d->arch.hvm_domain.dirty_vram;
-
-    if ( nr )
-    {
-        if ( paging_mode_log_dirty(d) && dirty_vram )
-        {
-            if ( begin_pfn !=3D dirty_vram->begin_pfn ||
-                 begin_pfn + nr !=3D dirty_vram->end_pfn )
-            {
-                paging_log_dirty_disable(d);
-                dirty_vram->begin_pfn =3D begin_pfn;
-                dirty_vram->end_pfn =3D begin_pfn + nr;
-                rc =3D paging_log_dirty_enable(d);
-                if (rc !=3D 0)
-                    goto param_fail;
-            }
-        }
-        else if ( !paging_mode_log_dirty(d) && !dirty_vram )
-        {
-            rc =3D -ENOMEM;
-            if ( (dirty_vram =3D xmalloc(struct sh_dirty_vram)) =3D=3D NUL=
L )
-                goto param_fail;
-
-            dirty_vram->begin_pfn =3D begin_pfn;
-            dirty_vram->end_pfn =3D begin_pfn + nr;
-            d->arch.hvm_domain.dirty_vram =3D dirty_vram;
-            hap_vram_tracking_init(d);
-            rc =3D paging_log_dirty_enable(d);
-            if (rc !=3D 0)
-                goto param_fail;
-        }
-        else
-        {
-            if ( !paging_mode_log_dirty(d) && dirty_vram )
-                rc =3D -EINVAL;
-            else
-                rc =3D -ENODATA;
-            goto param_fail;
-        }
-        /* get the bitmap */
-        rc =3D paging_log_dirty_range(d, begin_pfn, nr, dirty_bitmap);
-    }
-    else
-    {
-        if ( paging_mode_log_dirty(d) && dirty_vram ) {
-            rc =3D paging_log_dirty_disable(d);
-            xfree(dirty_vram);
-            dirty_vram =3D d->arch.hvm_domain.dirty_vram =3D NULL;
-        } else
-            rc =3D 0;
-    }
-
-    return rc;
-
-param_fail:
-    if ( dirty_vram )
-    {
-        xfree(dirty_vram);
-        dirty_vram =3D d->arch.hvm_domain.dirty_vram =3D NULL;
-    }
-    return rc;
-}
-
-/************************************************/
 /*            HAP LOG DIRTY SUPPORT             */
 /************************************************/

@@ -223,14 +91,12 @@ static void hap_clean_dirty_bitmap(struct domain *d)

 void hap_logdirty_init(struct domain *d)
 {
-    struct sh_dirty_vram *dirty_vram =3D d->arch.hvm_domain.dirty_vram;
+    struct dv_dirty_vram *dirty_vram =3D d->arch.hvm_domain.dirty_vram;
     if ( paging_mode_log_dirty(d) && dirty_vram )
     {
         paging_log_dirty_disable(d);
-        xfree(dirty_vram);
-        dirty_vram =3D d->arch.hvm_domain.dirty_vram =3D NULL;
+        dirty_vram_free(d);
     }
-
     /* Reinitialize logdirty mechanism */
     paging_log_dirty_init(d, hap_enable_log_dirty,
                           hap_disable_log_dirty,
diff --git a/xen/arch/x86/mm/paging.c b/xen/arch/x86/mm/paging.c
index ca879f9..7464b07 100644
--- a/xen/arch/x86/mm/paging.c
+++ b/xen/arch/x86/mm/paging.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 

@@ -278,6 +279,46 @@ out:
 }


+/* paging_mark_dirty_hap()
+ * Make a hap page writeable and mark it as dirty.
+ * This done atomically under the p2m and paging locks to avoid leaving
+ * a window where the page might be modified without being marked as dirty=
.
+ */
+void paging_mark_dirty_hap(struct domain *d,
+                           unsigned long pfn,
+                           unsigned long guest_mfn)
+{
+    mfn_t gmfn;
+    p2m_type_t pt;
+    struct p2m_domain *p2m =3D p2m_get_hostp2m(d);
+
+    if ( !paging_mode_log_dirty(d) )
+        return;
+
+    gmfn =3D _mfn(guest_mfn);
+
+    ASSERT( mfn_valid(gmfn) &&
+            page_get_owner(mfn_to_page(gmfn)) =3D=3D d );
+
+    p2m_lock(p2m);
+    pt =3D p2m_change_type(d, pfn, p2m_ram_logdirty, p2m_ram_rw);
+    paging_lock(d);
+    if ( pt =3D=3D p2m_ram_logdirty )
+    {
+        dv_range_t *range;
+        PAGING_DEBUG(LOGDIRTY,
+                     "marked mfn %" PRI_mfn " (pfn=3D%lx), dom %d\n",
+                     mfn_x(gmfn), pfn, d->domain_id);
+        d->arch.paging.log_dirty.dirty_count++;
+        range =3D dirty_vram_range_find_gfn(d, pfn);
+        if (range)
+            range->dirty_count++;
+    }
+    paging_mark_dirty(d, guest_mfn);
+    paging_unlock(d);
+    p2m_unlock(p2m);
+}
+
 /* Is this guest page dirty? */
 int paging_mfn_is_dirty(struct domain *d, mfn_t gmfn)
 {
@@ -333,8 +374,11 @@ int paging_log_dirty_op(struct domain *d, struct xen_d=
omctl_shadow_op *sc)
     mfn_t *l4, *l3, *l2;
     unsigned long *l1;
     int i4, i3, i2;
+    struct p2m_domain *p2m =3D p2m_get_hostp2m(d);

     domain_pause(d);
+    /* Locking hierarchy requires p2m lock to be taken first */
+    p2m_lock(p2m);
     paging_lock(d);

     clean =3D (sc->op =3D=3D XEN_DOMCTL_SHADOW_OP_CLEAN);
@@ -345,6 +389,14 @@ int paging_log_dirty_op(struct domain *d, struct xen_d=
omctl_shadow_op *sc)
                  d->arch.paging.log_dirty.fault_count,
                  d->arch.paging.log_dirty.dirty_count);

+    if (hap_enabled(d) && d->arch.hvm_domain.dirty_vram)
+    {
+        /* If we're cleaning/peeking all guest memory, we should not be tr=
acking
+         * dirty vram. */
+        rv =3D -EINVAL;
+        goto out;
+    }
+
     sc->stats.fault_count =3D d->arch.paging.log_dirty.fault_count;
     sc->stats.dirty_count =3D d->arch.paging.log_dirty.dirty_count;

@@ -424,170 +476,60 @@ int paging_log_dirty_op(struct domain *d, struct xen=
_domctl_shadow_op *sc)

     if ( clean )
     {
-        /* We need to further call clean_dirty_bitmap() functions of speci=
fic
-         * paging modes (shadow or hap).  Safe because the domain is pause=
d. */
-        d->arch.paging.log_dirty.clean_dirty_bitmap(d);
+        /* Is null if tracking dirty vram */
+        if (d->arch.paging.log_dirty.clean_dirty_bitmap)
+        {
+            /* We need to further call clean_dirty_bitmap() functions of s=
pecific
+             * paging modes (shadow or hap).  Safe because the domain is p=
aused. */
+            d->arch.paging.log_dirty.clean_dirty_bitmap(d);
+        }
     }
     domain_unpause(d);
     return rv;

  out:
     paging_unlock(d);
+    p2m_unlock(p2m);
     domain_unpause(d);
     return rv;
 }

-int paging_log_dirty_range(struct domain *d,
-                            unsigned long begin_pfn,
-                            unsigned long nr,
-                            XEN_GUEST_HANDLE_64(uint8) dirty_bitmap)
+void paging_log_dirty_range(struct domain *d,
+                           unsigned long begin_pfn,
+                           unsigned long nr,
+                           uint8_t *dirty_bitmap)
 {
-    int rv =3D 0;
-    unsigned long pages =3D 0;
-    mfn_t *l4, *l3, *l2;
-    unsigned long *l1;
-    int b1, b2, b3, b4;
-    int i2, i3, i4;
-
-    d->arch.paging.log_dirty.clean_dirty_bitmap(d);
+    struct p2m_domain *p2m =3D p2m_get_hostp2m(d);
+    dv_range_t *range;
+    unsigned int range_dirty_count =3D 0;
+
+    p2m_lock(p2m);
     paging_lock(d);

-    PAGING_DEBUG(LOGDIRTY, "log-dirty-range: dom %u faults=3D%u dirty=3D%u=
\n",
-                 d->domain_id,
-                 d->arch.paging.log_dirty.fault_count,
-                 d->arch.paging.log_dirty.dirty_count);
-
-    if ( unlikely(d->arch.paging.log_dirty.failed_allocs) ) {
-        printk("%s: %d failed page allocs while logging dirty pages\n",
-               __FUNCTION__, d->arch.paging.log_dirty.failed_allocs);
-        rv =3D -ENOMEM;
-        goto out;
-    }
-
-    if ( !d->arch.paging.log_dirty.fault_count &&
-         !d->arch.paging.log_dirty.dirty_count ) {
-        unsigned int size =3D BITS_TO_LONGS(nr);
-
-        if ( clear_guest(dirty_bitmap, size * BYTES_PER_LONG) !=3D 0 )
-            rv =3D -EFAULT;
-        goto out;
-    }
-    d->arch.paging.log_dirty.fault_count =3D 0;
-    d->arch.paging.log_dirty.dirty_count =3D 0;
-
-    b1 =3D L1_LOGDIRTY_IDX(begin_pfn);
-    b2 =3D L2_LOGDIRTY_IDX(begin_pfn);
-    b3 =3D L3_LOGDIRTY_IDX(begin_pfn);
-    b4 =3D L4_LOGDIRTY_IDX(begin_pfn);
-    l4 =3D paging_map_log_dirty_bitmap(d);
-
-    for ( i4 =3D b4;
-          (pages < nr) && (i4 < LOGDIRTY_NODE_ENTRIES);
-          i4++ )
+    /* Only called when tracking dirty vram in HAP mode */
+    ASSERT(hap_enabled(d) && d->arch.hvm_domain.dirty_vram);
+
+    range =3D dirty_vram_range_find_gfn(d, begin_pfn);
+    if (range)
     {
-        l3 =3D (l4 && mfn_valid(l4[i4])) ? map_domain_page(mfn_x(l4[i4])) =
: NULL;
-        for ( i3 =3D b3;
-              (pages < nr) && (i3 < LOGDIRTY_NODE_ENTRIES);
-              i3++ )
-        {
-            l2 =3D ((l3 && mfn_valid(l3[i3])) ?
-                  map_domain_page(mfn_x(l3[i3])) : NULL);
-            for ( i2 =3D b2;
-                  (pages < nr) && (i2 < LOGDIRTY_NODE_ENTRIES);
-                  i2++ )
-            {
-                unsigned int bytes =3D PAGE_SIZE;
-                uint8_t *s;
-                l1 =3D ((l2 && mfn_valid(l2[i2])) ?
-                      map_domain_page(mfn_x(l2[i2])) : NULL);
-
-                s =3D ((uint8_t*)l1) + (b1 >> 3);
-                bytes -=3D b1 >> 3;
-
-                if ( likely(((nr - pages + 7) >> 3) < bytes) )
-                    bytes =3D (unsigned int)((nr - pages + 7) >> 3);
-
-                if ( !l1 )
-                {
-                    if ( clear_guest_offset(dirty_bitmap, pages >> 3,
-                                            bytes) !=3D 0 )
-                    {
-                        rv =3D -EFAULT;
-                        goto out;
-                    }
-                }
-                /* begin_pfn is not 32K aligned, hence we have to bit
-                 * shift the bitmap */
-                else if ( b1 & 0x7 )
-                {
-                    int i, j;
-                    uint32_t *l =3D (uint32_t*) s;
-                    int bits =3D b1 & 0x7;
-                    int bitmask =3D (1 << bits) - 1;
-                    int size =3D (bytes + BYTES_PER_LONG - 1) / BYTES_PER_=
LONG;
-                    unsigned long bitmap[size];
-                    static unsigned long printed =3D 0;
-
-                    if ( printed !=3D begin_pfn )
-                    {
-                        dprintk(XENLOG_DEBUG, "%s: begin_pfn %lx is not 32=
K aligned!\n",
-                                __FUNCTION__, begin_pfn);
-                        printed =3D begin_pfn;
-                    }
-
-                    for ( i =3D 0; i < size - 1; i++, l++ ) {
-                        bitmap[i] =3D ((*l) >> bits) |
-                            (((*((uint8_t*)(l + 1))) & bitmask) << (sizeof=
(*l) * 8 - bits));
-                    }
-                    s =3D (uint8_t*) l;
-                    size =3D BYTES_PER_LONG - ((b1 >> 3) & 0x3);
-                    bitmap[i] =3D 0;
-                    for ( j =3D 0; j < size; j++, s++ )
-                        bitmap[i] |=3D (*s) << (j * 8);
-                    bitmap[i] =3D (bitmap[i] >> bits) | (bitmask << (size =
* 8 - bits));
-                    if ( copy_to_guest_offset(dirty_bitmap, (pages >> 3),
-                                (uint8_t*) bitmap, bytes) !=3D 0 )
-                    {
-                        rv =3D -EFAULT;
-                        goto out;
-                    }
-                }
-                else
-                {
-                    if ( copy_to_guest_offset(dirty_bitmap, pages >> 3,
-                                              s, bytes) !=3D 0 )
-                    {
-                        rv =3D -EFAULT;
-                        goto out;
-                    }
-                }
-
-                pages +=3D bytes << 3;
-                if ( l1 )
-                {
-                    clear_page(l1);
-                    unmap_domain_page(l1);
-                }
-                b1 =3D b1 & 0x7;
-            }
-            b2 =3D 0;
-            if ( l2 )
-                unmap_domain_page(l2);
-        }
-        b3 =3D 0;
-        if ( l3 )
-            unmap_domain_page(l3);
+        range_dirty_count =3D range->dirty_count;
+        range->dirty_count =3D 0;
     }
-    if ( l4 )
-        unmap_domain_page(l4);
-
-    paging_unlock(d);
+
+    if ( !range_dirty_count)
+        goto out;

-    return rv;
+    PAGING_DEBUG(LOGDIRTY, "log-dirty-range: dom %u [%05lx:%05lx] range_di=
rty=3D%u\n",
+                 d->domain_id,
+                 begin_pfn,
+                 range->end_pfn,
+                 range_dirty_count);

+    hap_clean_vram_tracking_range(d, begin_pfn, nr, dirty_bitmap);
  out:
     paging_unlock(d);
-    return rv;
+    p2m_unlock(p2m);
+    return;
 }

 /* Note that this function takes three function pointers. Callers must sup=
ply
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/commo=
n.c
index 3f8ad88..c9f3495 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -36,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "private.h"

@@ -3121,12 +3122,7 @@ void shadow_teardown(struct domain *d)
      * calls now that we've torn down the bitmap */
     d->arch.paging.mode &=3D ~PG_log_dirty;

-    if (d->arch.hvm_domain.dirty_vram) {
-        xfree(d->arch.hvm_domain.dirty_vram->sl1ma);
-        xfree(d->arch.hvm_domain.dirty_vram->dirty_bitmap);
-        xfree(d->arch.hvm_domain.dirty_vram);
-        d->arch.hvm_domain.dirty_vram =3D NULL;
-    }
+    dirty_vram_free(d);

     paging_unlock(d);

@@ -3463,179 +3459,212 @@ void shadow_clean_dirty_bitmap(struct domain *d)


 /*************************************************************************=
*/
-/* VRAM dirty tracking support */
-int shadow_track_dirty_vram(struct domain *d,
-                            unsigned long begin_pfn,
-                            unsigned long nr,
-                            XEN_GUEST_HANDLE_64(uint8) dirty_bitmap)
-{
-    int rc;
-    unsigned long end_pfn =3D begin_pfn + nr;
-    unsigned long dirty_size =3D (nr + 7) / 8;
-    int flush_tlb =3D 0;
-    unsigned long i;
-    p2m_type_t t;
-    struct sh_dirty_vram *dirty_vram =3D d->arch.hvm_domain.dirty_vram;
-    struct p2m_domain *p2m =3D p2m_get_hostp2m(d);
-
-    if (end_pfn < begin_pfn
-            || begin_pfn > p2m->max_mapped_pfn
-            || end_pfn >=3D p2m->max_mapped_pfn)
-        return -EINVAL;
-
-    /* We perform p2m lookups, so lock the p2m upfront to avoid deadlock *=
/
-    p2m_lock(p2m_get_hostp2m(d));
-    paging_lock(d);
+/* Support functions for shadow-based dirty VRAM code */

-    if ( dirty_vram && (!nr ||
-             ( begin_pfn !=3D dirty_vram->begin_pfn
-            || end_pfn   !=3D dirty_vram->end_pfn )) )
-    {
-        /* Different tracking, tear the previous down. */
-        gdprintk(XENLOG_INFO, "stopping tracking VRAM %lx - %lx\n", dirty_=
vram->begin_pfn, dirty_vram->end_pfn);
-        xfree(dirty_vram->sl1ma);
-        xfree(dirty_vram->dirty_bitmap);
-        xfree(dirty_vram);
-        dirty_vram =3D d->arch.hvm_domain.dirty_vram =3D NULL;
-    }
+#define DEBUG_unshadow_sl1ma                  0
+#define DEBUG_unshadow_sl1ma_detail           0
+#define DEBUG_count_initial_mappings          1

-    if ( !nr )
+/* smfn is no longer a shadow page.  Remove it from any
+ * dirty vram range mapping. */
+void
+dirty_vram_delete_shadow(struct vcpu *v,
+                         unsigned long gfn,
+                         unsigned int shadow_type,
+                         mfn_t smfn)
+{
+    static unsigned int l1_shadow_mask =3D
+          1 << SH_type_l1_32_shadow
+        | 1 << SH_type_fl1_32_shadow
+        | 1 << SH_type_l1_pae_shadow
+        | 1 << SH_type_fl1_pae_shadow
+        | 1 << SH_type_l1_64_shadow
+        | 1 << SH_type_fl1_64_shadow
+        ;
+    struct domain *d =3D v->domain;
+    dv_dirty_vram_t *dirty_vram;
+    struct list_head *curr, *next;
+
+    ASSERT(paging_locked_by_me(d));
+    /* Ignore all but level 1 shadows */
+
+    if ((l1_shadow_mask & (1 << shadow_type)) =3D=3D 0)
     {
-        rc =3D 0;
         goto out;
     }

-    /* This should happen seldomly (Video mode change),
-     * no need to be careful. */
+    dirty_vram =3D d->arch.hvm_domain.dirty_vram;
     if ( !dirty_vram )
     {
-        /* Throw away all the shadows rather than walking through them
-         * up to nr times getting rid of mappings of each pfn */
-        shadow_blow_tables(d);
-
-        gdprintk(XENLOG_INFO, "tracking VRAM %lx - %lx\n", begin_pfn, end_=
pfn);
-
-        rc =3D -ENOMEM;
-        if ( (dirty_vram =3D xmalloc(struct sh_dirty_vram)) =3D=3D NULL )
-            goto out;
-        dirty_vram->begin_pfn =3D begin_pfn;
-        dirty_vram->end_pfn =3D end_pfn;
-        d->arch.hvm_domain.dirty_vram =3D dirty_vram;
-
-        if ( (dirty_vram->sl1ma =3D xmalloc_array(paddr_t, nr)) =3D=3D NUL=
L )
-            goto out_dirty_vram;
-        memset(dirty_vram->sl1ma, ~0, sizeof(paddr_t) * nr);
-
-        if ( (dirty_vram->dirty_bitmap =3D xzalloc_array(uint8_t, dirty_si=
ze)) =3D=3D NULL )
-            goto out_sl1ma;
-
-        dirty_vram->last_dirty =3D NOW();
-
-        /* Tell the caller that this time we could not track dirty bits. *=
/
-        rc =3D -ENODATA;
-    }
-    else if (dirty_vram->last_dirty =3D=3D -1)
-    {
-        /* still completely clean, just copy our empty bitmap */
-        rc =3D -EFAULT;
-        if ( copy_to_guest(dirty_bitmap, dirty_vram->dirty_bitmap, dirty_s=
ize) =3D=3D 0 )
-            rc =3D 0;
+        goto out;
     }
-    else
+
+    list_for_each_safe(curr, next, &dirty_vram->range_head)
     {
-        /* Iterate over VRAM to track dirty bits. */
-        for ( i =3D 0; i < nr; i++ ) {
-            mfn_t mfn =3D get_gfn_query_unlocked(d, begin_pfn + i, &t);
-            struct page_info *page;
-            int dirty =3D 0;
-            paddr_t sl1ma =3D dirty_vram->sl1ma[i];
-
-            if (mfn_x(mfn) =3D=3D INVALID_MFN)
-            {
-                dirty =3D 1;
-            }
-            else
+        dv_range_t *range =3D list_entry(curr, dv_range_t, range_link);
+        unsigned long i;
+        int max_mappings =3D 1, mappings =3D 0;
+        int unshadowed =3D 0;
+        for (i =3D 0; i !=3D range->end_pfn - range->begin_pfn; i++)
+        {
+            dv_paddr_link_t *pl =3D &range->pl_tab[ i ];
+            dv_paddr_link_t **ppl =3D NULL;
+            mappings =3D 0;
+
+            while (pl !=3D NULL)
             {
-                page =3D mfn_to_page(mfn);
-                switch (page->u.inuse.type_info & PGT_count_mask)
-                {
-                case 0:
-                    /* No guest reference, nothing to track. */
-                    break;
-                case 1:
-                    /* One guest reference. */
-                    if ( sl1ma =3D=3D INVALID_PADDR )
-                    {
-                        /* We don't know which sl1e points to this, too ba=
d. */
-                        dirty =3D 1;
-                        /* TODO: Heuristics for finding the single mapping=
 of
-                         * this gmfn */
-                        flush_tlb |=3D sh_remove_all_mappings(d->vcpu[0], =
mfn);
-                    }
-                    else
-                    {
-                        /* Hopefully the most common case: only one mappin=
g,
-                         * whose dirty bit we can use. */
-                        l1_pgentry_t *sl1e =3D maddr_to_virt(sl1ma);
-
-                        if ( l1e_get_flags(*sl1e) & _PAGE_DIRTY )
-                        {
-                            dirty =3D 1;
-                            /* Note: this is atomic, so we may clear a
-                             * _PAGE_ACCESSED set by another processor. */
-                            l1e_remove_flags(*sl1e, _PAGE_DIRTY);
-                            flush_tlb =3D 1;
-                        }
-                    }
-                    break;
-                default:
-                    /* More than one guest reference,
-                     * we don't afford tracking that. */
-                    dirty =3D 1;
+                paddr_t sl1ma =3D pl->sl1ma;
+                unsigned long sl1mn;
+
+                if (sl1ma =3D=3D INVALID_PADDR )
                     break;
+
+                sl1mn =3D sl1ma >> PAGE_SHIFT;
+                if (sl1mn =3D=3D mfn_x(smfn)) {
+#if DEBUG_unshadow_sl1ma_detail
+                    gdprintk(XENLOG_DEBUG,
+                             "[%lx] gfn[%lx] unshadow sl1ma:%lx\n",
+                             mfn_x(smfn),
+                             range->begin_pfn + i,
+                             sl1ma);
+#endif
+                    unshadowed++;
+                    pl =3D free_paddr_link(d, ppl, pl);
+                    --range->nr_mappings;
+                }
+                else
+                {
+                    ppl =3D &pl->pl_next;
+                    pl =3D *ppl;
+                    mappings++;
                 }
             }
-
-            if ( dirty )
+        }
+        if (mappings > max_mappings)
+            max_mappings =3D mappings;
+
+        if (unshadowed) {
+#if DEBUG_unshadow_sl1ma
+            gdprintk(XENLOG_DEBUG,
+                     "[%lx] gfn[%05lx:%05lx] unshadowed:%d mappings:0x%x m=
ax_mappings:%d\n",
+                     mfn_x(smfn),
+                     range->begin_pfn, range->end_pfn,
+                     unshadowed, range->nr_mappings, max_mappings);
+#endif
+            if ( range->nr_mappings =3D=3D 0 )
             {
-                dirty_vram->dirty_bitmap[i / 8] |=3D 1 << (i % 8);
-                dirty_vram->last_dirty =3D NOW();
+                dirty_vram_range_free(d, range);
             }
         }
+    }
+ out:
+    return;
+}
+
+
+typedef int (*hash_pfn_callback_t)(struct vcpu *v,
+                                   mfn_t smfn,
+                                   unsigned long begin_pfn,
+                                   unsigned long end_pfn,
+                                   int *removed);
+
+static int hash_pfn_foreach(struct vcpu *v,
+                            unsigned int callback_mask,
+                            hash_pfn_callback_t callbacks[],
+                            unsigned long begin_pfn,
+                            unsigned long end_pfn)
+/* Walk the hash table looking at the types of the entries and
+ * calling the appropriate callback function for each entry.
+ * The mask determines which shadow types we call back for, and the array
+ * of callbacks tells us which function to call.
+ * Any callback may return non-zero to let us skip the rest of the scan.
+ *
+ * WARNING: Callbacks MUST NOT add or remove hash entries unless they
+ * then return non-zero to terminate the scan. */
+{
+    int i, done =3D 0, removed =3D 0;
+    struct domain *d =3D v->domain;
+    struct page_info *x;
+
+    /* Say we're here, to stop hash-lookups reordering the chains */
+    ASSERT(paging_locked_by_me(d));
+    ASSERT(d->arch.paging.shadow.hash_walking =3D=3D 0);
+    d->arch.paging.shadow.hash_walking =3D 1;

-        rc =3D -EFAULT;
-        if ( copy_to_guest(dirty_bitmap, dirty_vram->dirty_bitmap, dirty_s=
ize) =3D=3D 0 ) {
-            memset(dirty_vram->dirty_bitmap, 0, dirty_size);
-            if (dirty_vram->last_dirty + SECONDS(2) < NOW())
+    for ( i =3D 0; i < SHADOW_HASH_BUCKETS; i++ )
+    {
+        /* WARNING: This is not safe against changes to the hash table.
+         * The callback *must* return non-zero if it has inserted or
+         * deleted anything from the hash (lookups are OK, though). */
+        for ( x =3D d->arch.paging.shadow.hash_table[i]; x; x =3D next_sha=
dow(x) )
+        {
+            if ( callback_mask & (1 << x->u.sh.type) )
             {
-                /* was clean for more than two seconds, try to disable gue=
st
-                 * write access */
-                for ( i =3D begin_pfn; i < end_pfn; i++ ) {
-                    mfn_t mfn =3D get_gfn_query_unlocked(d, i, &t);
-                    if (mfn_x(mfn) !=3D INVALID_MFN)
-                        flush_tlb |=3D sh_remove_write_access(d->vcpu[0], =
mfn, 1, 0);
-                }
-                dirty_vram->last_dirty =3D -1;
+                ASSERT(x->u.sh.type <=3D 15);
+                ASSERT(callbacks[x->u.sh.type] !=3D NULL);
+                done =3D callbacks[x->u.sh.type](v, page_to_mfn(x),
+                                               begin_pfn, end_pfn,
+                                               &removed);
+                if ( done ) break;
             }
-            rc =3D 0;
         }
+        if ( done ) break;
     }
-    if ( flush_tlb )
-        flush_tlb_mask(d->domain_dirty_cpumask);
-    goto out;
+    d->arch.paging.shadow.hash_walking =3D 0;
+    return removed;
+}

-out_sl1ma:
-    xfree(dirty_vram->sl1ma);
-out_dirty_vram:
-    xfree(dirty_vram);
-    dirty_vram =3D d->arch.hvm_domain.dirty_vram =3D NULL;
+void sh_find_all_vram_mappings(struct vcpu *v,
+                               dv_range_t *range)
+{
+    /* Dispatch table for getting per-type functions */
+    static hash_pfn_callback_t callbacks[SH_type_unused] =3D {
+        NULL, /* none    */
+        SHADOW_INTERNAL_NAME(sh_find_vram_mappings_in_l1, 2), /* l1_32   *=
/
+        SHADOW_INTERNAL_NAME(sh_find_vram_mappings_in_l1, 2), /* fl1_32  *=
/
+        NULL, /* l2_32   */
+        SHADOW_INTERNAL_NAME(sh_find_vram_mappings_in_l1, 3), /* l1_pae  *=
/
+        SHADOW_INTERNAL_NAME(sh_find_vram_mappings_in_l1, 3), /* fl1_pae *=
/
+        NULL, /* l2_pae  */
+        NULL, /* l2h_pae */
+#if CONFIG_PAGING_LEVELS >=3D 4
+        SHADOW_INTERNAL_NAME(sh_find_vram_mappings_in_l1, 4), /* l1_64   *=
/
+        SHADOW_INTERNAL_NAME(sh_find_vram_mappings_in_l1, 4), /* fl1_64  *=
/
+#else
+        NULL, /* l1_64   */
+        NULL, /* fl1_64  */
+#endif
+        NULL, /* l2_64   */
+        NULL, /* l2h_64  */
+        NULL, /* l3_64   */
+        NULL, /* l4_64   */
+        NULL, /* p2m     */
+        NULL  /* unused  */
+    };

-out:
-    paging_unlock(d);
-    p2m_unlock(p2m_get_hostp2m(d));
-    return rc;
+    static unsigned int callback_mask =3D
+          1 << SH_type_l1_32_shadow
+        | 1 << SH_type_fl1_32_shadow
+        | 1 << SH_type_l1_pae_shadow
+        | 1 << SH_type_fl1_pae_shadow
+        | 1 << SH_type_l1_64_shadow
+        | 1 << SH_type_fl1_64_shadow
+        ;
+
+    perfc_incr(shadow_mappings);
+
+    hash_pfn_foreach(v, callback_mask, callbacks,
+                     range->begin_pfn,
+                     range->end_pfn);
+
+#if DEBUG_count_initial_mappings
+    gdprintk(XENLOG_DEBUG, "[%05lx:%05lx] count of initial mappings:%d\n",
+             range->begin_pfn, range->end_pfn,
+             range->nr_mappings);
+#endif
 }

+
 /*************************************************************************=
*/
 /* Shadow-control XEN_DOMCTL dispatcher */

diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.=
c
index b0e6d72..f4d0603 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -149,6 +150,10 @@ delete_fl1_shadow_status(struct vcpu *v, gfn_t gfn, mf=
n_t smfn)
     SHADOW_PRINTK("gfn=3D%"SH_PRI_gfn", type=3D%08x, smfn=3D%05lx\n",
                    gfn_x(gfn), SH_type_fl1_shadow, mfn_x(smfn));
     ASSERT(mfn_to_page(smfn)->u.sh.head);
+
+    /* Removing any dv_paddr_links to the erstwhile shadow page */
+    dirty_vram_delete_shadow(v, gfn_x(gfn), SH_type_fl1_shadow, smfn);
+
     shadow_hash_delete(v, gfn_x(gfn), SH_type_fl1_shadow, smfn);
 }

@@ -160,6 +165,10 @@ delete_shadow_status(struct vcpu *v, mfn_t gmfn, u32 s=
hadow_type, mfn_t smfn)
                    v->domain->domain_id, v->vcpu_id,
                    mfn_x(gmfn), shadow_type, mfn_x(smfn));
     ASSERT(mfn_to_page(smfn)->u.sh.head);
+
+    /* Removing any dv_paddr_links to the erstwhile shadow page */
+    dirty_vram_delete_shadow(v, mfn_x(gmfn), shadow_type, smfn);
+
     shadow_hash_delete(v, mfn_x(gmfn), shadow_type, smfn);
     /* 32-on-64 PV guests don't own their l4 pages; see set_shadow_status =
*/
     if ( !is_pv_32on64_vcpu(v) || shadow_type !=3D SH_type_l4_64_shadow )
@@ -516,7 +525,6 @@ _sh_propagate(struct vcpu *v,
     guest_l1e_t guest_entry =3D { guest_intpte };
     shadow_l1e_t *sp =3D shadow_entry_ptr;
     struct domain *d =3D v->domain;
-    struct sh_dirty_vram *dirty_vram =3D d->arch.hvm_domain.dirty_vram;
     gfn_t target_gfn =3D guest_l1e_get_gfn(guest_entry);
     u32 pass_thru_flags;
     u32 gflags, sflags;
@@ -663,17 +671,6 @@ _sh_propagate(struct vcpu *v,
         }
     }

-    if ( unlikely((level =3D=3D 1) && dirty_vram
-            && dirty_vram->last_dirty =3D=3D -1
-            && gfn_x(target_gfn) >=3D dirty_vram->begin_pfn
-            && gfn_x(target_gfn) < dirty_vram->end_pfn) )
-    {
-        if ( ft & FETCH_TYPE_WRITE )
-            dirty_vram->last_dirty =3D NOW();
-        else
-            sflags &=3D ~_PAGE_RW;
-    }
-
     /* Read-only memory */
     if ( p2m_is_readonly(p2mt) ||
          (p2mt =3D=3D p2m_mmio_direct &&
@@ -1072,101 +1069,57 @@ static int shadow_set_l2e(struct vcpu *v,
     return flags;
 }

-static inline void shadow_vram_get_l1e(shadow_l1e_t new_sl1e,
+/* shadow_vram_fix_l1e()
+ * Testing L1PTEs as they are modified, look for when they start to (or ce=
ase to)
+ * point to frame buffer pages.  If the old and new gfns differ, calls
+ * dirty_vram_range_update() to updates the dirty_vram structures
+ */
+static inline void shadow_vram_fix_l1e(shadow_l1e_t old_sl1e,
+                                       shadow_l1e_t new_sl1e,
                                        shadow_l1e_t *sl1e,
                                        mfn_t sl1mfn,
                                        struct domain *d)
 {
-    mfn_t mfn =3D shadow_l1e_get_mfn(new_sl1e);
-    int flags =3D shadow_l1e_get_flags(new_sl1e);
-    unsigned long gfn;
-    struct sh_dirty_vram *dirty_vram =3D d->arch.hvm_domain.dirty_vram;
+    mfn_t new_mfn, old_mfn;
+    unsigned long new_gfn =3D INVALID_M2P_ENTRY, old_gfn =3D INVALID_M2P_E=
NTRY;
+    paddr_t sl1ma;
+    dv_dirty_vram_t *dirty_vram =3D d->arch.hvm_domain.dirty_vram;

-    if ( !dirty_vram         /* tracking disabled? */
-         || !(flags & _PAGE_RW) /* read-only mapping? */
-         || !mfn_valid(mfn) )   /* mfn can be invalid in mmio_direct */
+    if ( !dirty_vram )
         return;

-    gfn =3D mfn_to_gfn(d, mfn);
-    /* Page sharing not supported on shadow PTs */
-    BUG_ON(SHARED_M2P(gfn));
+    sl1ma =3D pfn_to_paddr(mfn_x(sl1mfn)) | ((unsigned long)sl1e & ~PAGE_M=
ASK);

-    if ( (gfn >=3D dirty_vram->begin_pfn) && (gfn < dirty_vram->end_pfn) )
+    old_mfn =3D shadow_l1e_get_mfn(old_sl1e);
+
+    if ( !sh_l1e_is_magic(old_sl1e) &&
+         (l1e_get_flags(old_sl1e) & _PAGE_PRESENT) &&
+         mfn_valid(old_mfn))
     {
-        unsigned long i =3D gfn - dirty_vram->begin_pfn;
-        struct page_info *page =3D mfn_to_page(mfn);
-
-        if ( (page->u.inuse.type_info & PGT_count_mask) =3D=3D 1 )
-            /* Initial guest reference, record it */
-            dirty_vram->sl1ma[i] =3D pfn_to_paddr(mfn_x(sl1mfn))
-                | ((unsigned long)sl1e & ~PAGE_MASK);
+        old_gfn =3D mfn_to_gfn(d, old_mfn);
     }
-}
-
-static inline void shadow_vram_put_l1e(shadow_l1e_t old_sl1e,
-                                       shadow_l1e_t *sl1e,
-                                       mfn_t sl1mfn,
-                                       struct domain *d)
-{
-    mfn_t mfn =3D shadow_l1e_get_mfn(old_sl1e);
-    int flags =3D shadow_l1e_get_flags(old_sl1e);
-    unsigned long gfn;
-    struct sh_dirty_vram *dirty_vram =3D d->arch.hvm_domain.dirty_vram;
-
-    if ( !dirty_vram         /* tracking disabled? */
-         || !(flags & _PAGE_RW) /* read-only mapping? */
-         || !mfn_valid(mfn) )   /* mfn can be invalid in mmio_direct */
-        return;
-
-    gfn =3D mfn_to_gfn(d, mfn);
-    /* Page sharing not supported on shadow PTs */
-    BUG_ON(SHARED_M2P(gfn));
-
-    if ( (gfn >=3D dirty_vram->begin_pfn) && (gfn < dirty_vram->end_pfn) )
+
+    new_mfn =3D shadow_l1e_get_mfn(new_sl1e);
+    if ( !sh_l1e_is_magic(new_sl1e) &&
+         (l1e_get_flags(new_sl1e) & _PAGE_PRESENT) &&
+         mfn_valid(new_mfn))
     {
-        unsigned long i =3D gfn - dirty_vram->begin_pfn;
-        struct page_info *page =3D mfn_to_page(mfn);
-        int dirty =3D 0;
-        paddr_t sl1ma =3D pfn_to_paddr(mfn_x(sl1mfn))
-            | ((unsigned long)sl1e & ~PAGE_MASK);
+        new_gfn =3D mfn_to_gfn(d, new_mfn);
+    }

-        if ( (page->u.inuse.type_info & PGT_count_mask) =3D=3D 1 )
-        {
-            /* Last reference */
-            if ( dirty_vram->sl1ma[i] =3D=3D INVALID_PADDR ) {
-                /* We didn't know it was that one, let's say it is dirty *=
/
-                dirty =3D 1;
-            }
-            else
-            {
-                ASSERT(dirty_vram->sl1ma[i] =3D=3D sl1ma);
-                dirty_vram->sl1ma[i] =3D INVALID_PADDR;
-                if ( flags & _PAGE_DIRTY )
-                    dirty =3D 1;
-            }
-        }
-        else
+    if (old_gfn =3D=3D new_gfn) return;
+
+    if (VALID_M2P(old_gfn))
+        if (dirty_vram_range_update(d, old_gfn, sl1ma, 0/*clear*/))
         {
-            /* We had more than one reference, just consider the page dirt=
y. */
-            dirty =3D 1;
-            /* Check that it's not the one we recorded. */
-            if ( dirty_vram->sl1ma[i] =3D=3D sl1ma )
-            {
-                /* Too bad, we remembered the wrong one... */
-                dirty_vram->sl1ma[i] =3D INVALID_PADDR;
-            }
-            else
-            {
-                /* Ok, our recorded sl1e is still pointing to this page, l=
et's
-                 * just hope it will remain. */
-            }
+            SHADOW_PRINTK("gfn %lx (mfn %lx) cleared vram pte\n", old_gfn,=
 mfn_x(old_mfn));
         }
-        if ( dirty )
+
+    if (VALID_M2P(new_gfn))
+        if (dirty_vram_range_update(d, new_gfn, sl1ma, 1/*set*/))
         {
-            dirty_vram->dirty_bitmap[i / 8] |=3D 1 << (i % 8);
-            dirty_vram->last_dirty =3D NOW();
+            SHADOW_PRINTK("gfn %lx (mfn %lx) set vram pte\n", new_gfn, mfn=
_x(new_mfn));
         }
-    }
 }

 static int shadow_set_l1e(struct vcpu *v,
@@ -1211,12 +1164,14 @@ static int shadow_set_l1e(struct vcpu *v,
                 shadow_l1e_remove_flags(new_sl1e, _PAGE_RW);
                 /* fall through */
             case 0:
-                shadow_vram_get_l1e(new_sl1e, sl1e, sl1mfn, d);
+                shadow_vram_fix_l1e(old_sl1e, new_sl1e, sl1e, sl1mfn, d);
                 break;
             }
         }
     }

+    shadow_vram_fix_l1e(old_sl1e, new_sl1e, sl1e, sl1mfn, d);
+
     /* Write the new entry */
     shadow_write_entries(sl1e, &new_sl1e, 1, sl1mfn);
     flags |=3D SHADOW_SET_CHANGED;
@@ -1231,7 +1186,6 @@ static int shadow_set_l1e(struct vcpu *v,
          * trigger a flush later. */
         if ( shadow_mode_refcounts(d) )
         {
-            shadow_vram_put_l1e(old_sl1e, sl1e, sl1mfn, d);
             shadow_put_page_from_l1e(old_sl1e, d);
             TRACE_SHADOW_PATH_FLAG(TRCE_SFLAG_SHADOW_L1_PUT_REF);
         }
@@ -2018,7 +1972,6 @@ void sh_destroy_l1_shadow(struct vcpu *v, mfn_t smfn)
         SHADOW_FOREACH_L1E(sl1mfn, sl1e, 0, 0, {
             if ( (shadow_l1e_get_flags(*sl1e) & _PAGE_PRESENT)
                  && !sh_l1e_is_magic(*sl1e) ) {
-                shadow_vram_put_l1e(*sl1e, sl1e, sl1mfn, d);
                 shadow_put_page_from_l1e(*sl1e, d);
             }
         });
@@ -4336,6 +4289,34 @@ int sh_rm_mappings_from_l1(struct vcpu *v, mfn_t sl1=
mfn, mfn_t target_mfn)
     return done;
 }

+
+int sh_find_vram_mappings_in_l1(struct vcpu *v,
+                                mfn_t sl1mfn,
+                                unsigned long begin_pfn,
+                                unsigned long end_pfn,
+                                int *removed)
+/* Find all VRAM mappings in this shadow l1 table */
+{
+    struct domain *d =3D v->domain;
+    shadow_l1e_t *sl1e;
+    int done =3D 0;
+
+    SHADOW_FOREACH_L1E(sl1mfn, sl1e, 0, done, /* only returns _PAGE_PRESEN=
T entries */
+    {
+        unsigned long gfn;
+        mfn_t gmfn =3D shadow_l1e_get_mfn(*sl1e);
+        if (!mfn_valid(gmfn))
+            continue;
+        gfn =3D mfn_to_gfn(d, gmfn);
+        if (VALID_M2P(gfn) && (begin_pfn <=3D gfn) && (gfn < end_pfn))
+        {
+            paddr_t sl1ma =3D pfn_to_paddr(mfn_x(sl1mfn)) | ((unsigned lon=
g)sl1e & ~PAGE_MASK);
+            dirty_vram_range_update(v->domain, gfn, sl1ma, 1/*set*/);
+        }
+    });
+    return 0;
+}
+
 /*************************************************************************=
*/
 /* Functions to excise all pointers to shadows from higher-level shadows. =
*/

diff --git a/xen/arch/x86/mm/shadow/multi.h b/xen/arch/x86/mm/shadow/multi.=
h
index 835121e..436a4ac 100644
--- a/xen/arch/x86/mm/shadow/multi.h
+++ b/xen/arch/x86/mm/shadow/multi.h
@@ -66,7 +66,12 @@ SHADOW_INTERNAL_NAME(sh_rm_write_access_from_l1, GUEST_L=
EVELS)
 extern int
 SHADOW_INTERNAL_NAME(sh_rm_mappings_from_l1, GUEST_LEVELS)
     (struct vcpu *v, mfn_t sl1mfn, mfn_t target_mfn);
-
+extern int
+SHADOW_INTERNAL_NAME(sh_find_vram_mappings_in_l1, GUEST_LEVELS)
+     (struct vcpu *v, mfn_t sl1mfn,
+      unsigned long begin_pfn,
+      unsigned long end_pfn,
+      int *removed);
 extern void
 SHADOW_INTERNAL_NAME(sh_clear_shadow_entry, GUEST_LEVELS)
     (struct vcpu *v, void *ep, mfn_t smfn);
diff --git a/xen/arch/x86/mm/shadow/types.h b/xen/arch/x86/mm/shadow/types.=
h
index 43ce1db..5b0f9f7 100644
--- a/xen/arch/x86/mm/shadow/types.h
+++ b/xen/arch/x86/mm/shadow/types.h
@@ -229,6 +229,7 @@ static inline shadow_l4e_t shadow_l4e_from_mfn(mfn_t mf=
n, u32 flags)
 #define sh_update_cr3              INTERNAL_NAME(sh_update_cr3)
 #define sh_rm_write_access_from_l1 INTERNAL_NAME(sh_rm_write_access_from_l=
1)
 #define sh_rm_mappings_from_l1     INTERNAL_NAME(sh_rm_mappings_from_l1)
+#define sh_find_vram_mappings_in_l1 INTERNAL_NAME(sh_find_vram_mappings_in=
_l1)
 #define sh_remove_l1_shadow        INTERNAL_NAME(sh_remove_l1_shadow)
 #define sh_remove_l2_shadow        INTERNAL_NAME(sh_remove_l2_shadow)
 #define sh_remove_l3_shadow        INTERNAL_NAME(sh_remove_l3_shadow)
diff --git a/xen/include/asm-x86/hap.h b/xen/include/asm-x86/hap.h
index a2532a4..82e20c7 100644
--- a/xen/include/asm-x86/hap.h
+++ b/xen/include/asm-x86/hap.h
@@ -57,10 +57,6 @@ void  hap_final_teardown(struct domain *d);
 void  hap_teardown(struct domain *d);
 void  hap_vcpu_init(struct vcpu *v);
 void  hap_logdirty_init(struct domain *d);
-int   hap_track_dirty_vram(struct domain *d,
-                           unsigned long begin_pfn,
-                           unsigned long nr,
-                           XEN_GUEST_HANDLE_64(uint8) dirty_bitmap);

 extern const struct paging_mode *hap_paging_get_mode(struct vcpu *);

diff --git a/xen/include/asm-x86/hvm/dirty_vram.h b/xen/include/asm-x86/hvm=
/dirty_vram.h
new file mode 100644
index 0000000..b8b92cc
--- /dev/null
+++ b/xen/include/asm-x86/hvm/dirty_vram.h
@@ -0,0 +1,157 @@
+/*************************************************************************=
*****
+ * include/asm-x86/hvm/dirty_vram.h
+ *
+ * Interface for tracking dirty VRAM pages
+ *
+ * Copyright (c) 2012 Citrix Systems, Inc. (Robert Phillips)
+ * Parts of this code are Copyright (c) 2006 by XenSource Inc.
+ * Parts of this code are Copyright (c) 2006 by Michael A Fetterman
+ * Parts based on earlier work by Michael A Fetterman, Ian Pratt et al.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  U=
SA
+ */
+
+#ifndef _DIRTY_VRAM_H
+#define _DIRTY_VRAM_H
+
+/* In shadow mode we need to bookkeep all the L1 page table entries that
+ * map a frame buffer page.  Struct dv_paddr_link does this
+ * by recording the address of a L1 page table entry for some frame buffer=
 page.
+ * Also has a link to additional pl entries if the frame buffer page
+ * has multiple mappings */
+typedef struct dv_paddr_link {
+    paddr_t sl1ma;
+    struct dv_paddr_link *pl_next;
+} dv_paddr_link_t;
+
+/* This defines an extension page of pl entries for FB pages with multiple
+ * mappings. All such pages (of a domain) are linked together. */
+typedef struct dv_paddr_link_ext {
+    struct list_head ext_link;
+    dv_paddr_link_t entries[(PAGE_SIZE-sizeof(struct list_head))/sizeof(dv=
_paddr_link_t)];
+} dv_paddr_link_ext_t;
+
+/* This defines a single frame buffer range.  It bookkeeps all the level 1=
 PTEs
+ * that map guest pages within that range.
+ * All such ranges (of a domain) are linked together. */
+typedef struct dv_range {
+    struct list_head range_link; /* the several ranges form a linked list =
*/
+    unsigned long begin_pfn;
+    unsigned long end_pfn;
+    dv_paddr_link_t *pl_tab; /* table has 1 pl entry per pfn in range */
+    int nr_mappings;  /* total number of mappings in this range */
+    int mappings_hwm; /* high water mark of max mapping count */
+    unsigned int dirty_count;
+} dv_range_t;
+
+/* This contains all the data structures required by a domain to
+ * bookkeep the dirty pages within its frame buffers. */
+typedef struct dv_dirty_vram {
+    struct list_head range_head; /* head of the linked list of ranges */
+    struct list_head ext_head; /* head of list of extension pages */
+    dv_paddr_link_t *pl_free; /* free list of pl's within extension pages =
*/
+    int nr_ranges; /* bookkeeps number of ranges */
+    int ranges_hwm; /* high water mark of max number of ranges */
+} dv_dirty_vram_t;
+
+/* Allocates domain's dirty_vram structure */
+dv_dirty_vram_t *
+dirty_vram_alloc(struct domain *d);
+
+/* Returns domain's dirty_vram structure,
+ * allocating it if necessary */
+dv_dirty_vram_t *
+dirty_vram_find_or_alloc(struct domain *d);
+
+/* Frees domain's dirty_vram structure */
+void dirty_vram_free(struct domain *d);
+
+/* Returns dirty vram range containing gfn, NULL if none */
+struct dv_range *
+dirty_vram_range_find_gfn(struct domain *d,
+                          unsigned long gfn);
+
+/* Returns dirty vram range matching [ begin_pfn .. begin_pfn+nr ), NULL i=
f none */
+dv_range_t *
+dirty_vram_range_find(struct domain *d,
+                      unsigned long begin_pfn,
+                      unsigned long nr);
+
+/* Allocate dirty vram range containing [ begin_pfn .. begin_pfn+nr ),
+ * freeing any existing range that overlaps the new range. */
+dv_range_t *
+dirty_vram_range_alloc(struct domain *d,
+                       unsigned long begin_pfn,
+                       unsigned long nr);
+
+/* Returns dirty vram range matching [ begin_pfn .. begin_pfn+nr ),
+ * creating a range if none already exists and
+ * freeing any existing range that overlaps the new range. */
+dv_range_t *
+dirty_vram_range_find_or_alloc(struct domain *d,
+                               unsigned long begin_pfn,
+                               unsigned long nr);
+
+void dirty_vram_range_free(struct domain *d,
+                           dv_range_t *range);
+
+/* Bookkeep PTE address of a frame buffer page */
+int dirty_vram_range_update(struct domain *d,
+                            unsigned long gfn,
+                            paddr_t sl1ma,
+                            int set);
+
+/* smfn is no longer a shadow page.  Remove it from any
+ * dirty vram range mapping. */
+void
+dirty_vram_delete_shadow(struct vcpu *v,
+                         unsigned long gfn,
+                         unsigned int shadow_type,
+                         mfn_t smfn);
+
+
+/* Scan all the L1 tables looking for VRAM mappings.
+ * Record them in the domain's dv_dirty_vram structure */
+void sh_find_all_vram_mappings(struct vcpu *v,
+                               dv_range_t *range);
+
+/* Free a paddr_link struct, given address of its
+ * predecessor in singly-linked list */
+dv_paddr_link_t *
+free_paddr_link(struct domain *d,
+                dv_paddr_link_t **ppl,
+                dv_paddr_link_t *pl);
+
+
+/* Enable VRAM dirty tracking. */
+int
+shadow_track_dirty_vram(struct domain *d,
+                       unsigned long first_pfn,
+                       unsigned long nr,
+                       XEN_GUEST_HANDLE_64(uint8) dirty_bitmap);
+
+int
+hap_track_dirty_vram(struct domain *d,
+                    unsigned long begin_pfn,
+                    unsigned long nr,
+                    XEN_GUEST_HANDLE_64(uint8) dirty_bitmap);
+
+void
+hap_clean_vram_tracking_range(struct domain *d,
+                             unsigned long begin_pfn,
+                             unsigned long nr,
+                             uint8_t *dirty_bitmap);
+
+#endif /* _DIRTY_VRAM_H */
diff --git a/xen/include/asm-x86/hvm/domain.h b/xen/include/asm-x86/hvm/dom=
ain.h
index 27b3de5..6146542 100644
--- a/xen/include/asm-x86/hvm/domain.h
+++ b/xen/include/asm-x86/hvm/domain.h
@@ -74,7 +74,7 @@ struct hvm_domain {
     struct list_head       pinned_cacheattr_ranges;

     /* VRAM dirty support. */
-    struct sh_dirty_vram *dirty_vram;
+    struct dv_dirty_vram * dirty_vram;

     /* If one of vcpus of this domain is in no_fill_mode or
      * mtrr/pat between vcpus is not the same, set is_in_uc_mode
diff --git a/xen/include/asm-x86/paging.h b/xen/include/asm-x86/paging.h
index d9b6950..fba06b0 100644
--- a/xen/include/asm-x86/paging.h
+++ b/xen/include/asm-x86/paging.h
@@ -137,10 +137,10 @@ struct paging_mode {
 void paging_free_log_dirty_bitmap(struct domain *d);

 /* get the dirty bitmap for a specific range of pfns */
-int paging_log_dirty_range(struct domain *d,
-                           unsigned long begin_pfn,
-                           unsigned long nr,
-                           XEN_GUEST_HANDLE_64(uint8) dirty_bitmap);
+void paging_log_dirty_range(struct domain *d,
+                            unsigned long begin_pfn,
+                            unsigned long nr,
+                            uint8_t *dirty_bitmap);

 /* enable log dirty */
 int paging_log_dirty_enable(struct domain *d);
@@ -161,6 +161,11 @@ void paging_mark_dirty(struct domain *d, unsigned long=
 guest_mfn);
  * This is called from inside paging code, with the paging lock held. */
 int paging_mfn_is_dirty(struct domain *d, mfn_t gmfn);

+/* mark a page as dirty, from hap page fault handler */
+void paging_mark_dirty_hap(struct domain *d,
+                           unsigned long pfn,
+                           unsigned long guest_mfn);
+
 /*
  * Log-dirty radix tree indexing:
  *   All tree nodes are PAGE_SIZE bytes, mapped on-demand.
@@ -183,15 +188,6 @@ int paging_mfn_is_dirty(struct domain *d, mfn_t gmfn);
 #define L4_LOGDIRTY_IDX(pfn) 0
 #endif

-/* VRAM dirty tracking support */
-struct sh_dirty_vram {
-    unsigned long begin_pfn;
-    unsigned long end_pfn;
-    paddr_t *sl1ma;
-    uint8_t *dirty_bitmap;
-    s_time_t last_dirty;
-};
-
 /*************************************************************************=
****
  * Entry points into the paging-assistance code */

diff --git a/xen/include/asm-x86/shadow.h b/xen/include/asm-x86/shadow.h
index 88a8cd2..bdb8dcd 100644
--- a/xen/include/asm-x86/shadow.h
+++ b/xen/include/asm-x86/shadow.h
@@ -62,12 +62,6 @@ void shadow_vcpu_init(struct vcpu *v);
 /* Enable an arbitrary shadow mode.  Call once at domain creation. */
 int shadow_enable(struct domain *d, u32 mode);

-/* Enable VRAM dirty bit tracking. */
-int shadow_track_dirty_vram(struct domain *d,
-                            unsigned long first_pfn,
-                            unsigned long nr,
-                            XEN_GUEST_HANDLE_64(uint8) dirty_bitmap);
-
 /* Handler for shadow control ops: operations from user-space to enable
  * and disable ephemeral shadow modes (test mode and log-dirty mode) and
  * manipulate the log-dirty bitmap. */
--
1.7.9.5


--_002_048EAD622912254A9DEA24C1734613C18C86D229FFFTLPMAILBOX02_
Content-Type: application/pdf; name="multi-dirty-vram.pdf"
Content-Description: multi-dirty-vram.pdf
Content-Disposition: attachment; filename="multi-dirty-vram.pdf"; size=525873;
	creation-date="Tue, 16 Oct 2012 16:27:53 GMT";
	modification-date="Tue, 16 Oct 2012 16:27:54 GMT"
Content-Transfer-Encoding: base64

JVBERi0xLjUNCiW1tbW1DQoxIDAgb2JqDQo8PC9UeXBlL0NhdGFsb2cvUGFnZXMgMiAwIFIvTGFu
Zyhlbi1VUykgL1N0cnVjdFRyZWVSb290IDQ4IDAgUi9NYXJrSW5mbzw8L01hcmtlZCB0cnVlPj4+
Pg0KZW5kb2JqDQoyIDAgb2JqDQo8PC9UeXBlL1BhZ2VzL0NvdW50IDUvS2lkc1sgMyAwIFIgMzcg
MCBSIDQwIDAgUiA0MiAwIFIgNDUgMCBSXSA+Pg0KZW5kb2JqDQozIDAgb2JqDQo8PC9UeXBlL1Bh
Z2UvUGFyZW50IDIgMCBSL1Jlc291cmNlczw8L0ZvbnQ8PC9GMSA1IDAgUi9GMiAxMCAwIFIvRjMg
MTIgMCBSL0Y0IDE3IDAgUi9GNSAxOSAwIFIvRjYgMjEgMCBSL0Y3IDI2IDAgUi9GOCAyOCAwIFIv
RjkgMzAgMCBSL0YxMCAzNSAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0lt
YWdlSV0gPj4vTWVkaWFCb3hbIDAgMCA2MTIgNzkyXSAvQ29udGVudHMgNCAwIFIvR3JvdXA8PC9U
eXBlL0dyb3VwL1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1Y3RQYXJl
bnRzIDA+Pg0KZW5kb2JqDQo0IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDM5
MjQ+Pg0Kc3RyZWFtDQp4nKVabW/bOBL+XqD/gR/tRaySoihKh4WBNC+3PdwCvd2id0C7KBRbSXRx
nKwkN9v79TczpGhSNm1vF0VqWebLcDjzzDNDsjfv2Y8/vvn54t0l4/M5e3t5wd5+eP3qzbVgaZ7w
jH24ff1KMA7/BNNpwtOM5aVK0px9eHz9iie85CnjSSrwf5kr1t7tff3L31+/+vQj54LPZyV8lno+
K+CzuDKfZW7eF2/nv7EP/3j96grEYFc/XzDmySgCGdM9MgrJE+2L+Gkymx4YMT26aiHLJE2DIVFO
kFdwI7BZUDafabuQVOLDwZXI4yspZSL+xEqyoytJuUhgK0YrKYthAbAYOZ/luKhr88mltwYzsNw3
cK4SqUcDiytpNAKD0ARiUBnuvcLPdHjhHoRVYmZlysMhimIu9zTDn9XIuEprXP4wuFfan29oUGg3
ULjesennWaILpzpezkVq5CBbHqS8HobfDms+lVGrk68wcttlDc3d6tVo9YP43PiMU+zbub8I+PmA
majATLI9uyl5kSgdrHXCxpb3O3k5F6liM56IVEjQjkjhiemSPtr69at//8DW0MGbPrfTAyrAfIni
OfyvM0G4oeFFAeMomZQFy+BrqeDnMoeJaLzbH16/+teeRelgUYoJsbsolZSS5SmsLTPYxRCpGOLS
5Jen6UxNbqZyUrf9tJiwXxP2fjrLJvfwqlnBf6sG/nuGv+6MfWzaqZCTflOtptmEXUzLCfV/xB7Y
ZgN/PbytWzadpZN366maLBLmK9E3rqzQCejBk+3TJJ3qCZ/O5ETAQ4oPb6Y5fIEHHhlGpbBhWTjM
m2jbcjQlbiPXWrIPi08TrmL9Mo6g5HXj1GHHPvzdKYLdyffszuBeXCLUDu6VZ1yoc/i75KLkaO9c
iPN5BtiiL8lzhEDrV3Mh8R24C/4mruA5hy7nc/JC0828h2GoT3FhhuXXc9MFPWg7CZ+Dn8Hc6JaC
pzgetVN8Psxg2poZi5Ia4qAgGHi4uODmF5wDRFa2E4hBE+BrMyR9BUlncjuhkQZ/keqK1gXejsvE
H/NrbI9D7EDzXrtP06RQgWaDMOJvrgQsSEXYdokO0PbfYl0ynQhxePj9Wy4VTzI92nKnN1QlT92+
gkqlujZgiQorSrMtqAjcTlAcNg2UCTsxNC+tlaTeXpmPwY5wvpI2h3Q9mNKOzqmjsq9gR2n4tNgK
LJzA9ueTdsnavwIgKIZgf2OB5Pa2bjvWrNl/avT+NbxK2FQIAKmNxST8IwRqewKcppuKFHyypF/a
J+z3FcGpWQIS1Ut2i/1ND3aDWEbP/T3r7qvlVGjz/QWREAap1gBzaAjsvmqXAEMvVVszHK/quga7
dz3JRm2eqzuYhF6jrHcIkZ8n+PNP8PX8/ecpihjFQi2SLA818QhTkkA4ft3FoAnYjQ47JtGm2WgS
iDIcQhlBWUw0xctEhZ2ow7VTYDvuehDtFHx6dAntGM0RTQewQRpvyD1AA5eX3lfssIWKMYgEoMkJ
3hxojmHGawzk1boD/IzwSdaNU+I7897DsXMnUXFhmuOzhbfBI8lTzegaHfnqJJ9IIfwXpa8l3CSF
rUDplx9PUnVaSIS/0SBAMHAQAhX4K06TpxSJ0OFQx2Nf6cW+8f5neVIOgfrDfU2uO9CHNmKEgufA
kcK+zv07dGscB7+ryS3r8ZE4TAeQwScLaJYbNwK/Zvi2mPTwUk8QB1IzDPZ9eEBpsFX9zPp7at7V
4Ih9zD3SIsckwJOMVC1KUtLTbawbJA1ZGXbbUWvYoUi4CDUwgJvISWRaBbttK9QHsTKS/2YDWIRw
GgtmBSBIGY7cIXaNzUPvi2dgHmU5FgvmbwkoQeWPO+PsM7NMZEk5Wt7n6Rltau/WBg+0i7TB9aKH
jWEvA2Gt1wT/bvONRSAQb+zOd9FdHGxTAgxLOz2OUXXsEQZwMNzcNvC1XsbMFPglUPhgmNiUQqaI
q35TijjfgPkyss3bcD1onx0sKg9jZMxegAFxdZooKVBoSH12ZcEln7HN86ACjGysRZeqf99gTO1I
ujPcmLbuNy1SflaR4lHIpnemWOEgbNhJ56Miw33Spo1VM7wb9Axh1QbTusNMAhp9uMc4L6OLUQJL
IcFaVnUfDZ9A/vL8NDUNRiIgd9S2rWUQmPKAfZm14bb1L7i+ijImY4gLVBvuocuXnErrdY8/dpDs
xXYIktNSh1PH+GwK+aiUYVucrmrWBsjQpe5RyDpqEEolabk7hAn3tL7GSR+1QEiI9UiOOLrBhGqP
agcf0J5LjxHFYZGU2Ht3kLUzRctXANwKx11A845qmZbbZXafpw6CCA8M06THrwRCiLAL9w6dhqx1
maCrkMFeVRSD7o+ZFeeJKh33m3kuR6zSxKsWyCg6SGe9jNBe7kV75MoGR6Ja5zrJRDhzZ9RkzTRu
ITIjWhB0bf6HmEByVWTRrHt6BE2bV88DhjX0W/M08Hpk+Q6mO9xr9nxPSAgNumZRYSUC/Qu3qTZ4
DPvzzQGCtWVsjTroEVCs9UToNphbOVJ5lJpD4EXW7LcNtH5kX7Miwwi5J7uJch2JwgX9okEEeBEI
57WlgobMiUvcxOBECI01E7+bYR8NAvhdNGIBFSxOFAx8UYdN+7YiDHzYJk0LMA7yGXoKPcjxOWI5
CLDA2ZrHrYVFcUdrJL8niQksH3EnaDsCg8EfIBuNFhAkFhCCQTBVfF5tYKg7BwmsWmMayTa4RvSG
1Ya0vYWMiAVmGgladEG75wXhoUbBgFztT8ayLE0KbQ817LEFYDaYel7aM43xWzrSmFw8IeYta/ZL
TRBd4VcgZEijZ8jjC7SlWRY3JmCdZSDAsUWJo9XOYVEQ03W5U+0ccg0biIfEmhl5Y45SkslvR/w0
qVcV5v2pMWHEmyd8uMQc4yMxk/vKVCJuampHGGdqARXBK3BKgOUN4jiEBeCYzy4J6brmBoxhVX+e
Ipq3NMBttXAcuAXyKQgzYdr8GFfJQElSWMH/cJWUN8TI2gUgpzJf/oDxC/w5B+x8M1DqrzADugO9
cDWxYvLlK8jYVo8oXPIJNh0bL36LGXAKVJeLUJjDe52easAyhw0qv8OAL6eZMdq+Yr/2LSxyA0qG
IASOewHfIMxmk/UdxfhDHFtrX4Zj65Kn2rBUwGXiNnyJG2KMbVnBCjo0wxZWsGmnhggAQQDjKUbl
MFOwIg/waleUA1O09bInND9b1FpbmGIrMkGD4rHNlpBMAHf0FnBMKVm8WCClTvLTTEYdGAX2SQzs
/qoCn8Oa3MefmdGAyLaEx5Bk9vxEqTUuvCdl9kNQsLyrc0pZ1eTSJ2XLqaSsP5CHCA9ly0gMFvFC
Qy6TfNR3ST4K03+JxsISzz53OjUtmf433MlYXzw7Gk/4Pam9TAvMA4JxKGN8uW8AgZQJ/i7i9rgF
RHBXKzJwzyQj8VFyDIzBBFE2B7xEibDtU7RtmcjRuJjq0X4bZF4RD/RcCb1xnz2MLRJ4m9bOArae
i478t2h1gWMNLuh72CfyAG7KPZtTcpInhc+8dEdQerc2KPi+3irhedh7jyfsq1AKSGh5OprXnDac
b48Y7DOVUk3x1R412JIu0Ddbat2eeeERxfagSeSmpks1YlMBDlrhGYl/YoYjaxrZnHHTadQ51ZHN
WQcNrHYOxaR6iyVV6jAckGEl24g+OqvZjkTD6O2pyWxcw7aHK/tOVPaW42SRpDLcEAsw+RF8kXmO
0TnoSvgSxYciRffY6RBgy9cW/ZpS1scvIIPDDnNIInfTp0h9MFeY6AST2fOgd71fXxmjSG+4jDiQ
qA22qBXS+O1CMLC25NqritIAoPD9AFWulLV2JNJlhbmpafnJXpQaqRzBJZj7sE/rk31alZjbfK9P
e733+PS+PRr06Pes2OLJkF2z5V5uTtQZ+MwCdUfFf1MtW/dsTdz40ZY67X2CbVWGtRUwMw1oaY7j
3EFdhaTlvrlD/hYtEukk1aGQ0ZPhDKxNhm1fKlN8pnzUUIb2gezwlk4Z2p0itC1uVvjDH82jifS0
PHjCpdrHGzJSGndQ0GF7zeQQByjpF+YSAxhhPOkXWdDNJP3DeaVVZ71euFKZ27baZElYaFmyjnxr
QbXo5VAW9OkTbMOirau+CXwyyhi5wITdE+yYDxQn+0Cq/0pc83r/SR/we6KR39fVkjm13jKqCbJV
g0cSbr+RbueGA+zlRFsiTj6FvvFfwqUFoVznm06JCGwLzcTlTzvOwT1QofinElSpBV5cCvoeCSCg
Kxl2oEL11JCpJR0I5pMvK1r4w4mRAkIg1+GoZ2xJpttRpbZt0NMIWZaQo0NSoycvZyMoOeJ7It3i
dcWsgFsaiBtLO+wd5GDBGEJhg7enKkry7eFArIyfIW0OZlranDxK94EJFyLsQxpd2mW1pMscdTmz
fktWhBay6DvK52O7JUyk8sc+7KUHDoFFkSXFcHOGMjKAdGvcJpjayxyGZlMCC36BB0/rHnYNxEW5
Tc5anZh8wStIvoKpTd6MuH0k+YJUIB/1PZ58KYXJ106nBqtj/bcvX/HUzOVSf4UdIe3TIpwpYcCM
sACwcMFzfcBz1Wh1YwJlUWRpmBASIyRF5cmcaDifOJwXiRxSruH81+dP0ZyI4ylq0O2gUab81NAh
lExk8b2hw+99IvZaaAl6UpX4S09wES+1003toN/ZacEqE3hcfVDWbdsMFe03NZX7qm2rbf1oe8B7
2ppBXXIkwdgnzaWuWAVOkk/7/Q/GHHRkpXeVHMYcMNZ40Nl/4abEOlVoMy5N5dfmPl1prxFxum2H
yS5ljtusMd97/dPkvJgwmstI7nrmhaa8U+DN6NS79IddLy7mIosmlubS0jjdxnz0rTI3Te1VQBB9
GAZndzcF6Zahy7+Hi4lqe3PLvyhq03F15N7nSfeRBi8BGj9Edy90JMORKx63IjNa9y0WrNnN01DA
e3jAE8kaYj7da/bwDan6P4ncY3m7XiGdoqvHtg5KDcAXV1N7aQEBjehZOyqe2tNPOrIc7j6MkdQR
vBYi27MpQlropCDhuN6dd9PiCC0RaZpkqW/Wvlbw5gRdfoqMkWvsHIxBxVFHm26QnS4ZiCbUdnXb
vKxmAwGiY1igOoxY1soR35cElYqXzHNDf77Qsgy+NeYSBFEmVMPqG+pp05kpYUZzTTP3rmk+DtmH
EdQu9F3PGiILbE113P5A4Bk0x+kyugW21Wq48bIYghxFQ/bTOfz/HlMcb2ZYYTS9N3cxgtF34tP/
AUblCmoNCmVuZHN0cmVhbQ0KZW5kb2JqDQo1IDAgb2JqDQo8PC9UeXBlL0ZvbnQvU3VidHlwZS9U
eXBlMC9CYXNlRm9udC9BQkNERUUrQ2FtYnJpYSxJdGFsaWMvRW5jb2RpbmcvSWRlbnRpdHktSC9E
ZXNjZW5kYW50Rm9udHMgNiAwIFIvVG9Vbmljb2RlIDI2OSAwIFI+Pg0KZW5kb2JqDQo2IDAgb2Jq
DQpbIDcgMCBSXSANCmVuZG9iag0KNyAwIG9iag0KPDwvQmFzZUZvbnQvQUJDREVFK0NhbWJyaWEs
SXRhbGljL1N1YnR5cGUvQ0lERm9udFR5cGUyL1R5cGUvRm9udC9DSURUb0dJRE1hcC9JZGVudGl0
eS9EVyAxMDAwL0NJRFN5c3RlbUluZm8gOCAwIFIvRm9udERlc2NyaXB0b3IgOSAwIFIvVyAyNzEg
MCBSPj4NCmVuZG9iag0KOCAwIG9iag0KPDwvT3JkZXJpbmcoSWRlbnRpdHkpIC9SZWdpc3RyeShB
ZG9iZSkgL1N1cHBsZW1lbnQgMD4+DQplbmRvYmoNCjkgMCBvYmoNCjw8L1R5cGUvRm9udERlc2Ny
aXB0b3IvRm9udE5hbWUvQUJDREVFK0NhbWJyaWEsSXRhbGljL0ZsYWdzIDMyL0l0YWxpY0FuZ2xl
IC0xMi40L0FzY2VudCA5NTAvRGVzY2VudCAtMjIyL0NhcEhlaWdodCA3NzgvQXZnV2lkdGggNTQy
L01heFdpZHRoIDIzMjcvRm9udFdlaWdodCA0MDAvWEhlaWdodCAyNTAvU3RlbVYgNTQvRm9udEJC
b3hbIC0xMTA1IC0yMjIgMTIyMiA3NzhdIC9Gb250RmlsZTIgMjcwIDAgUj4+DQplbmRvYmoNCjEw
IDAgb2JqDQo8PC9UeXBlL0ZvbnQvU3VidHlwZS9UcnVlVHlwZS9OYW1lL0YyL0Jhc2VGb250L0FC
Q0RFRStDYW1icmlhLEl0YWxpYy9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvRm9udERlc2NyaXB0
b3IgMTEgMCBSL0ZpcnN0Q2hhciA0NS9MYXN0Q2hhciA0NS9XaWR0aHMgMjcyIDAgUj4+DQplbmRv
YmoNCjExIDAgb2JqDQo8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0FCQ0RFRStDYW1i
cmlhLEl0YWxpYy9GbGFncyAzMi9JdGFsaWNBbmdsZSAtMTIuNC9Bc2NlbnQgOTUwL0Rlc2NlbnQg
LTIyMi9DYXBIZWlnaHQgNzc4L0F2Z1dpZHRoIDU0Mi9NYXhXaWR0aCAyMzI3L0ZvbnRXZWlnaHQg
NDAwL1hIZWlnaHQgMjUwL1N0ZW1WIDU0L0ZvbnRCQm94WyAtMTEwNSAtMjIyIDEyMjIgNzc4XSAv
Rm9udEZpbGUyIDI3MCAwIFI+Pg0KZW5kb2JqDQoxMiAwIG9iag0KPDwvVHlwZS9Gb250L1N1YnR5
cGUvVHlwZTAvQmFzZUZvbnQvQUJDREVFK0NhbWJyaWEvRW5jb2RpbmcvSWRlbnRpdHktSC9EZXNj
ZW5kYW50Rm9udHMgMTMgMCBSL1RvVW5pY29kZSAyNzMgMCBSPj4NCmVuZG9iag0KMTMgMCBvYmoN
ClsgMTQgMCBSXSANCmVuZG9iag0KMTQgMCBvYmoNCjw8L0Jhc2VGb250L0FCQ0RFRStDYW1icmlh
L1N1YnR5cGUvQ0lERm9udFR5cGUyL1R5cGUvRm9udC9DSURUb0dJRE1hcC9JZGVudGl0eS9EVyAx
MDAwL0NJRFN5c3RlbUluZm8gMTUgMCBSL0ZvbnREZXNjcmlwdG9yIDE2IDAgUi9XIDI3NSAwIFI+
Pg0KZW5kb2JqDQoxNSAwIG9iag0KPDwvT3JkZXJpbmcoSWRlbnRpdHkpIC9SZWdpc3RyeShBZG9i
ZSkgL1N1cHBsZW1lbnQgMD4+DQplbmRvYmoNCjE2IDAgb2JqDQo8PC9UeXBlL0ZvbnREZXNjcmlw
dG9yL0ZvbnROYW1lL0FCQ0RFRStDYW1icmlhL0ZsYWdzIDMyL0l0YWxpY0FuZ2xlIDAvQXNjZW50
IDk1MC9EZXNjZW50IC0yMjIvQ2FwSGVpZ2h0IDc3OC9BdmdXaWR0aCA2MTUvTWF4V2lkdGggNDM0
Mi9Gb250V2VpZ2h0IDQwMC9YSGVpZ2h0IDI1MC9TdGVtViA2MS9Gb250QkJveFsgLTE0NzUgLTIy
MiAyODY4IDc3OF0gL0ZvbnRGaWxlMiAyNzQgMCBSPj4NCmVuZG9iag0KMTcgMCBvYmoNCjw8L1R5
cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL05hbWUvRjQvQmFzZUZvbnQvQUJDREVFK0NhbWJyaWEv
RW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0ZvbnREZXNjcmlwdG9yIDE4IDAgUi9GaXJzdENoYXIg
MzIvTGFzdENoYXIgMzIvV2lkdGhzIDI3NiAwIFI+Pg0KZW5kb2JqDQoxOCAwIG9iag0KPDwvVHlw
ZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9BQkNERUUrQ2FtYnJpYS9GbGFncyAzMi9JdGFsaWNB
bmdsZSAwL0FzY2VudCA5NTAvRGVzY2VudCAtMjIyL0NhcEhlaWdodCA3NzgvQXZnV2lkdGggNjE1
L01heFdpZHRoIDQzNDIvRm9udFdlaWdodCA0MDAvWEhlaWdodCAyNTAvU3RlbVYgNjEvRm9udEJC
b3hbIC0xNDc1IC0yMjIgMjg2OCA3NzhdIC9Gb250RmlsZTIgMjc0IDAgUj4+DQplbmRvYmoNCjE5
IDAgb2JqDQo8PC9UeXBlL0ZvbnQvU3VidHlwZS9UcnVlVHlwZS9OYW1lL0Y1L0Jhc2VGb250L0FC
Q0RFRStDYWxpYnJpL0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9Gb250RGVzY3JpcHRvciAyMCAw
IFIvRmlyc3RDaGFyIDMyL0xhc3RDaGFyIDEyMi9XaWR0aHMgMjgwIDAgUj4+DQplbmRvYmoNCjIw
IDAgb2JqDQo8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0FCQ0RFRStDYWxpYnJpL0Zs
YWdzIDMyL0l0YWxpY0FuZ2xlIDAvQXNjZW50IDc1MC9EZXNjZW50IC0yNTAvQ2FwSGVpZ2h0IDc1
MC9BdmdXaWR0aCA1MjEvTWF4V2lkdGggMTc0My9Gb250V2VpZ2h0IDQwMC9YSGVpZ2h0IDI1MC9T
dGVtViA1Mi9Gb250QkJveFsgLTUwMyAtMjUwIDEyNDAgNzUwXSAvRm9udEZpbGUyIDI3OCAwIFI+
Pg0KZW5kb2JqDQoyMSAwIG9iag0KPDwvVHlwZS9Gb250L1N1YnR5cGUvVHlwZTAvQmFzZUZvbnQv
QUJDREVFK0NhbGlicmkvRW5jb2RpbmcvSWRlbnRpdHktSC9EZXNjZW5kYW50Rm9udHMgMjIgMCBS
L1RvVW5pY29kZSAyNzcgMCBSPj4NCmVuZG9iag0KMjIgMCBvYmoNClsgMjMgMCBSXSANCmVuZG9i
ag0KMjMgMCBvYmoNCjw8L0Jhc2VGb250L0FCQ0RFRStDYWxpYnJpL1N1YnR5cGUvQ0lERm9udFR5
cGUyL1R5cGUvRm9udC9DSURUb0dJRE1hcC9JZGVudGl0eS9EVyAxMDAwL0NJRFN5c3RlbUluZm8g
MjQgMCBSL0ZvbnREZXNjcmlwdG9yIDI1IDAgUi9XIDI3OSAwIFI+Pg0KZW5kb2JqDQoyNCAwIG9i
ag0KPDwvT3JkZXJpbmcoSWRlbnRpdHkpIC9SZWdpc3RyeShBZG9iZSkgL1N1cHBsZW1lbnQgMD4+
DQplbmRvYmoNCjI1IDAgb2JqDQo8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0FCQ0RF
RStDYWxpYnJpL0ZsYWdzIDMyL0l0YWxpY0FuZ2xlIDAvQXNjZW50IDc1MC9EZXNjZW50IC0yNTAv
Q2FwSGVpZ2h0IDc1MC9BdmdXaWR0aCA1MjEvTWF4V2lkdGggMTc0My9Gb250V2VpZ2h0IDQwMC9Y
SGVpZ2h0IDI1MC9TdGVtViA1Mi9Gb250QkJveFsgLTUwMyAtMjUwIDEyNDAgNzUwXSAvRm9udEZp
bGUyIDI3OCAwIFI+Pg0KZW5kb2JqDQoyNiAwIG9iag0KPDwvVHlwZS9Gb250L1N1YnR5cGUvVHJ1
ZVR5cGUvTmFtZS9GNy9CYXNlRm9udC9BQkNERUUrQ2FsaWJyaSxJdGFsaWMvRW5jb2RpbmcvV2lu
QW5zaUVuY29kaW5nL0ZvbnREZXNjcmlwdG9yIDI3IDAgUi9GaXJzdENoYXIgMzIvTGFzdENoYXIg
MTIxL1dpZHRocyAyODEgMCBSPj4NCmVuZG9iag0KMjcgMCBvYmoNCjw8L1R5cGUvRm9udERlc2Ny
aXB0b3IvRm9udE5hbWUvQUJDREVFK0NhbGlicmksSXRhbGljL0ZsYWdzIDMyL0l0YWxpY0FuZ2xl
IC0xMS9Bc2NlbnQgNzUwL0Rlc2NlbnQgLTI1MC9DYXBIZWlnaHQgNzUwL0F2Z1dpZHRoIDUyMS9N
YXhXaWR0aCAxOTg0L0ZvbnRXZWlnaHQgNDAwL1hIZWlnaHQgMjUwL1N0ZW1WIDUyL0ZvbnRCQm94
WyAtNzI1IC0yNTAgMTI2MCA3NTBdIC9Gb250RmlsZTIgMjgyIDAgUj4+DQplbmRvYmoNCjI4IDAg
b2JqDQo8PC9UeXBlL0ZvbnQvU3VidHlwZS9UcnVlVHlwZS9OYW1lL0Y4L0Jhc2VGb250L0FCQ0RF
RStDYW1icmlhLEJvbGQvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0ZvbnREZXNjcmlwdG9yIDI5
IDAgUi9GaXJzdENoYXIgMzIvTGFzdENoYXIgMTE5L1dpZHRocyAyODMgMCBSPj4NCmVuZG9iag0K
MjkgMCBvYmoNCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvQUJDREVFK0NhbWJyaWEs
Qm9sZC9GbGFncyAzMi9JdGFsaWNBbmdsZSAwL0FzY2VudCA5NTAvRGVzY2VudCAtMjIyL0NhcEhl
aWdodCA3NzgvQXZnV2lkdGggNjAwL01heFdpZHRoIDI0ODIvRm9udFdlaWdodCA3MDAvWEhlaWdo
dCAyNTAvU3RlbVYgNjAvRm9udEJCb3hbIC0xMTEwIC0yMjIgMTM3MyA3NzhdIC9Gb250RmlsZTIg
Mjg0IDAgUj4+DQplbmRvYmoNCjMwIDAgb2JqDQo8PC9UeXBlL0ZvbnQvU3VidHlwZS9UeXBlMC9C
YXNlRm9udC9TeW1ib2wvRW5jb2RpbmcvSWRlbnRpdHktSC9EZXNjZW5kYW50Rm9udHMgMzEgMCBS
L1RvVW5pY29kZSAyODUgMCBSPj4NCmVuZG9iag0KMzEgMCBvYmoNClsgMzIgMCBSXSANCmVuZG9i
ag0KMzIgMCBvYmoNCjw8L0Jhc2VGb250L1N5bWJvbC9TdWJ0eXBlL0NJREZvbnRUeXBlMi9UeXBl
L0ZvbnQvQ0lEVG9HSURNYXAvSWRlbnRpdHkvRFcgMTAwMC9DSURTeXN0ZW1JbmZvIDMzIDAgUi9G
b250RGVzY3JpcHRvciAzNCAwIFIvVyAyODcgMCBSPj4NCmVuZG9iag0KMzMgMCBvYmoNCjw8L09y
ZGVyaW5nKElkZW50aXR5KSAvUmVnaXN0cnkoQWRvYmUpIC9TdXBwbGVtZW50IDA+Pg0KZW5kb2Jq
DQozNCAwIG9iag0KPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9TeW1ib2wvRmxhZ3Mg
MzIvSXRhbGljQW5nbGUgMC9Bc2NlbnQgMTAwNS9EZXNjZW50IC0yMTYvQ2FwSGVpZ2h0IDY5My9B
dmdXaWR0aCA2MDAvTWF4V2lkdGggMTExMy9Gb250V2VpZ2h0IDQwMC9YSGVpZ2h0IDI1MC9TdGVt
ViA2MC9Gb250QkJveFsgMCAtMjE2IDExMTMgNjkzXSAvRm9udEZpbGUyIDI4NiAwIFI+Pg0KZW5k
b2JqDQozNSAwIG9iag0KPDwvVHlwZS9Gb250L1N1YnR5cGUvVHJ1ZVR5cGUvTmFtZS9GMTAvQmFz
ZUZvbnQvQXJpYWwvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0ZvbnREZXNjcmlwdG9yIDM2IDAg
Ui9GaXJzdENoYXIgMzIvTGFzdENoYXIgMzIvV2lkdGhzIDI4OCAwIFI+Pg0KZW5kb2JqDQozNiAw
IG9iag0KPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9BcmlhbC9GbGFncyAzMi9JdGFs
aWNBbmdsZSAwL0FzY2VudCA5MDUvRGVzY2VudCAtMjEwL0NhcEhlaWdodCA3MjgvQXZnV2lkdGgg
NDQxL01heFdpZHRoIDI2NjUvRm9udFdlaWdodCA0MDAvWEhlaWdodCAyNTAvTGVhZGluZyAzMy9T
dGVtViA0NC9Gb250QkJveFsgLTY2NSAtMjEwIDIwMDAgNzI4XSA+Pg0KZW5kb2JqDQozNyAwIG9i
ag0KPDwvVHlwZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8PC9Gb250PDwvRjkgMzAgMCBS
L0YxMCAzNSAwIFIvRjcgMjYgMCBSL0Y1IDE5IDAgUi9GOCAyOCAwIFIvRjYgMjEgMCBSPj4vRXh0
R1N0YXRlPDwvR1MzOSAzOSAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0lt
YWdlSV0gPj4vTWVkaWFCb3hbIDAgMCA2MTIgNzkyXSAvQ29udGVudHMgMzggMCBSL0dyb3VwPDwv
VHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFy
ZW50cyAxPj4NCmVuZG9iag0KMzggMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGgg
Mzc5MD4+DQpzdHJlYW0NCniclVpbb9s4Fn4v0P/ARxtIVFLUdVEESJN0posW6E6zMw/NIlBsufbW
cTKS0jT76/dcSImUQ8XFoONIIg8Pz/U7hxRvPou3b998OvtwLuTJiXh3fibeXb5+9eZ9KZSKZCIu
V69fKSHhPyVKGck4EbksI1mIy1sY99sXXYpv7etXUnzD//32+tXXt1Lmxcl/xOU/X7+6AGJMUMnn
KKaRzDyKX2diPp6aPzNTyQKY8Wfu5nrWzI+T2fXt/FjPKni8N/82u3k6+wZ/tPvk0+fIZ2WkR4xt
2rmKZ6JD2msgVYt5Puvu4K+u2oodfnyAh1vk4Aa/N2JezO7mx+lsJeYlf6ju54nLUQIc3dTwkNDD
MA7fVPiqXoqbp7mSBwpGl2WUaJ9zXG973VU3tMIh+0+0jLIRlUjMlZqJL3UN+wamt3fI6GNEvP2S
1rJSR6klezsWCSjp2sr48XaeHciyKmIwJp/2phXdugaZivXmG1BajyjZuXEMfKX+3OPQWK2iRPlj
HyuyCtY466+ZKz37LvD1Ck2D7KBB64nZepCrXts/NzgGN9ubkNg9gFyMNankYHMKsJ2kRZTkPttj
wfZjMxmVpT920aD264o2ADbZks0uUPl1iI5Vd15EcWzoNJXltCbhLJq6QiLdhraGPhyFyOVpVIzI
uUuLi09nQjghTR0a0rIsjlTCJH89fLmzfy18eTOXqMYGxds9XS/uHsAYUBrdoRFLRaVP0ASsiuWM
QiYRo4UZwrm1JxPUlNUKfh8FM3JzGJ6zPYt7iE7prIaACkPI/NAqwd1EA7+VjWhMr1tXnVhX6BM/
cDy/Zbuu7YJiCdtPwBLI0oAISgQNbVEjg8ngN9uq7ch/pu0uyaLc2m+3ucWt0vTKrA7y7gaPvTfx
d3Ax3AzyBPzD0xNOwtfobxyaefOPVYtUmxp197eRXA0c5k7wfiBloBPDoEEZuMU6ZPC6SCKZ+/sI
7VkXWZSW7liBtp2Ky8XX/fA8ZAsVpcqfRTMu1xA7n7UZEIIxLDIGfLtFvT5hVrjFVxVYQwZJkSJE
vaSxm91LyoKwquwmfweip5/RPkk1L0tKQXTD4O8SmQwNsRMaLJE85mAgNYYZJvJnhSaJsYnV2vb2
UtsYzO7Rjv0jxGmWoJ8Oa4hj0JPOSOrLHxOhL/dmsZquQ+MLhTHS24qJL+By3ROhJNgAOWNDfkl7
ucbwrK3jgiqbmixXoSVfzcg7MI3t7ihOXc1BGmJZ39eo6qWbhwbrEOs+/z3icBM4yJKYp44Mpm5N
LEFuWvZ4Zm3xvbaDo6ApG+2lhZMdLtd1wwtxPrbBiB9q69C9Phfryhg6m/htSLwQ+bPYXyuUeBUA
sjL3x/4jhC1kHBWpPza031imkR7R/bIGOVbLeTKI+0j8fgrPnxFHVbslhuk//zjF/X8KxQSVRIXy
CYfAkFZFpDwmyJzjPCHz/PJXaJ7WGNnceWzQwYV0hrDWY+o8NDbRUTySjGv4wXCLsEeFpb8XRLSH
LwoBghtlZWuUEF8VUZRRrGKIzDrX8P80K0Xz7bm3f/zG+qyQ4SUnaoDD6E6fQJX0tKyDMUZF2ln0
hW0k3jaeAxd2G3GJuJD2MdR7sw+U/Nt1hdbFhieAx1vm00TuYDxMCohsDmVMW6lk+zn/c2KHkLC8
aZzpJsKudsdzPESn7+oeH2GabwesAWA34Htg9rHyyQX9NJZRPlq6ogwBwTdzg6+NjFSvVFgXWiDk
oSPCFBic659c5lKgsiBsCMBuoXpsknRNa9ZbquQUKocWVZkNjdXNds6xUPS4rCPs9xTYXwqeWWSH
ycLaETgKVJdW2yopSXdXs4+BeYUkoO3NoykKxPAZ9355AbEO0lEIY0CsLNz5E5Yic0jQ3lBErySx
WzSKeyrafUAaUmWE6UWMo+Cb99kzThbrPEq1t/JbqdLTEw0/6kKqPJNS6hMl4TlPTzL7Oj1J8M35
yXEKv8XZiYrh9yw/OYaZMAOInEtVSppd8ORjd4riNXBUXODviUoNcXUqdZoylfIU2cH3J6UlDI8y
xkWJCrJ0ppxXF7geT5b0iCPKU5xvGKJH4mbYKfKJvGtabWAOScJod3s6fcdUkPHsPS+dStpAv3UW
nLsBWuKQsspYbAJJXFpz+IiO4VoeQKEgMJUqSmJ//mQwTsPANMl1lKvDg2SRRkqOpk0GySIHVONN
+Ero9s7G9e9gzYzF6ntTXG631GJB8PsRhin8iGDjEoZetEPx53UsxIpCSoUpou6LMcTXqxWUSPdI
2lRYCPhg2l9rCl87XEz0YJzi47MllemuNPXfDwQtKRi2osL3N5uuj5nMzsuw3aoA6oxYe4C6eyIG
naLwaKo0jTNEjg6dw/KdLiFLerOm010SR8rntl1Uuxb1ZcrcboDlbY35emTWpD+Svp594PC3HQyB
Kt7VXSjnlSCu0foNiXdIKqidDVTQj1RRona7da/dca1idSbaGkvLI25pbKmkrppxNDaZ8glhCUwk
3LvfRhyrFkSWp04rmTbK4IAMbZxQ93hcYQJQs2eNGq2zoayQm4/cMhloIuMPbd2ERJpDICl9LoMt
yjzBMsIbi/bZ3AFrVPJtEKqZ0ryXliPnwTeCYBkqUkDw3hqTgS3zUOZzCdAqQuUI9W0zLku8oH2M
wf9dSjmBcwqnPGnivZI8xMltKvHTiklN8PuOSHEitTmJsoRJlpSXZEwZh6mf2kxEOReHYiJKzGf5
3uRak6RsoqV8WJ7YYXFBiw0Z28yGhZQZUpRDFi3NokoSuzjFZjrmg2ewEOh1nhF7kAfHW5fvSXIu
OMClcLJ2WDqTJiefkwTTtzaR8p+yXxWTt3aTdw8NMCEj92ZXDmIZM2O0iRPwH2uUMvuAESQBl/J0
XyrAk3Z5+qW0Dtm5tNaLwdt27rAxcL+GF9T0azeLaouO7vUuRj1SxbC5sdFm03E7Y1vbjgrENwwD
VzNqjPUNVECtx9qergTrbI1FhMPvQWlDQ7aBUt6bNpk3NKB4rX25UOLA+DxsaWOTr9tDboaerxmG
k+gj5o3vGysHzBsIl2132nT5qm6xjubckRGXTqw9BDwbhWIXNMl78Oz6H9oLelA62E3m2zJbK8FF
fJ2ztYIdenAV3QXcT+engz2CISu9H4DQV4x52pFm5cQhaJbkyQzzaTj6pBr56l7kOMjaY4jVSeoJ
J1yu5jm2q7yxfEKzWAsCOai2obM/TmP0klQ7mIPBcBeWTL3r6DSJWsb3d33tiuaV8ZGq6dF/hBFj
pP1SB1DncqhE/3VxjrYWymJlEulkNGUyi+VheK6TNMqs0/xuAcRjbXOuOULhja2cYpFS/w2e9jH6
pS+DhLm2x1ix7jvwN+aoJh8dAw7nDS2vC1CkqbYAzTMHmpMc24iiEXZ14f17aug6GO0nKevWQttt
fcTxqQRrABV+s7AaNFjd3wNzFBQWFZ7eGCBOXYsXdKUl9g+HMlsskA8yHQLriwUDMG6v+2gJZOhi
LZUMFQSDyi0yLgiU+XTw2OeYh7dDwwSgT8ENftbcTtgOOaB8VA8IkpqriPwagnRte0TxHma3NC/F
1s2PmrDUhltKgTNWNLnCF4C/9rTgsEtgLTZwFBxdzRm+X9pTLVEtYIXFHR0sZ6PDFXJshOW2S05R
/gh5IpXfY+WAhwZddeO4MKZKVhrOJ527Ls20egbsHwD0aT5QxYsJlPwgUQZkBULSpb/nvn7obQJ7
NNIeQUEJuR+WKGVZm5kUb1xSHuSl0M7QmwYfDRZ3RVT6c4MFmqa+gDd2KCG5bRRsZUo81PGmcguW
7qKsTa3xiDrhWwdLuhcAez8aeZAn/K55wuOZlVURIhmOJX1h45zcDuU6q9EBRsO5c0CdiUR04W0A
DfAHn0qF7i/k2NTfF1jvkNdbOkbCHgUX9Mjkf2lvC6oPX9J5QRjLdGjtgZaNFQs6GBM3NfoDlqlr
vg+xFAx/BjAzRJRtqGeK/eNS+ysGi7k4juLSH0uxFvkZDsbENjQ/TTD5e/M3bedfJmkfFmu2oGfk
1gZrQJ1HakR6MnsW4ewZ4/0U23Q6owCyI5vADNbS0bo5Zg75noqUTyXcg9HYg/HGVmzk8fPVe+Mf
+wfT8g6TEMe3F9I0LgVI5gM2tCjrFbOqNe5DvZC27yqBj+KFCrq85bdPuPO08BKuOXZvwXkF/AVR
kNyqApMxBv2CF0BBX1ipmKkPvUwYtWDwduLuznSUKgr8JgFRImmGrN2H/2rUJ+xBXTH7987eeBpJ
yr9sgofS9JpuonFUWhKYYeiIPoodQdMewg9T14oSXURa+RuftOJywopVjoeyTIRAq42wkiIsJCwK
l7AFDFPudQkUDZ+DL8EW72x65lZdUzs9p9WK74MBQQriIe+UaZTmPkukBTIwspXQmbWOc4Sy3tRg
ycgIxhu7XxTkiDoAiC+5Tg7dYQFSyicVhvu6yKO8DDO5fx1MhhWnsGNpwfsVmmcyA/gEfF+u2Zxq
uuFJKty71UfqRYyENbByr7ehrW52Gzq4Yx/833Ap5oYdmEyC88vOu0KBzfW9wwaEqJtd33Rf9paC
1qNyyPFOm9apuYe0bu4g2lDVhtSRKh0lmS+akDJSlSKc9cZy338y2kCxG6XJHozt/R3tmzcr+MTA
qylDd1+wqPNJT9uFmrCLVA2XAa5msbULUMopN0X6c29A7XRvtaVD5ev+zJVC3RXNsofiqXHkzdAs
4Up3CIqBZJ4kkdI+VyEnjpMCE7839ihY9qeQE5U7+KAGU5xlCMm9aZMNpjgr8eTcY2rUJ3revdAE
qiWCvU3H17Eo2do7LRBPC1vP9CmPgC0+r9zDbIrBbjFZdX6GfslmNV3+8TB74DwNL5KMJngXJl9o
mwQvuwHs8qlO2/fEZTeloLTqzVtPm/f4oAsNmpIxhaJt3Q1o9OaJb4Zt6RN/uCZaKhsuJ11TA6Hq
Hlr2D1v6E4llzQmcr1aDT12vthgIr72bJtfAQ9vxtWSq5+mW2tWcj4i8oD2p1TKJcmnDBW7KWJTh
9gcn5olqLi98GpjDczeHh6/A5BojlTfbXpNWE3YQS1g19+ftGcL/AYpOwt8NCmVuZHN0cmVhbQ0K
ZW5kb2JqDQozOSAwIG9iag0KPDwvVHlwZS9FeHRHU3RhdGUvQk0vTm9ybWFsL2NhIDE+Pg0KZW5k
b2JqDQo0MCAwIG9iag0KPDwvVHlwZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8PC9Gb250
PDwvRjUgMTkgMCBSL0Y4IDI4IDAgUi9GNiAyMSAwIFI+Pi9FeHRHU3RhdGU8PC9HUzM5IDM5IDAg
Uj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFnZUMvSW1hZ2VJXSA+Pi9NZWRpYUJveFsg
MCAwIDYxMiA3OTJdIC9Db250ZW50cyA0MSAwIFIvR3JvdXA8PC9UeXBlL0dyb3VwL1MvVHJhbnNw
YXJlbmN5L0NTL0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1Y3RQYXJlbnRzIDI+Pg0KZW5kb2JqDQo0
MSAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA0Mzc5Pj4NCnN0cmVhbQ0KeJyt
W2tv3Mix/W7A/6E/zgQSzeabwEKALEvJXsQXTiJkL2AHBjXD0TBLjWZJyorur791qrvJbo56NHcT
LNYPqh/VVadOPbotPnwRP/304fPVz59EeHEhPn66Eh9v37/7cJMKKYMwEbeb9++kCOk/KfIoCKNE
5GEZZIW4faBxf/xbXIr7/v27UNzjlz++f/d1cdmLejd0Td0vpVyIqqvFMltU62WyWC/jRb0W1W5N
X0S3lOGifqDvj8vzdPGDvtEPN/Q5Ul8eMGrffh+quzOBxYZtTbPKRbWjSff0Py19Hi/uaNnHZaom
/frrsljUNb7v6Xsv6K+YN9BiPGCoWhZs90QLPCzPE55fdxjIAzaCtuAfVHsaglWaHS2PDXsWPl2I
5T/E7X+9f3dN6oLKZkrKyiSQSklfefdtc0/7bz2zZFgE+WzWuW+sjALpDn2uBhy37nxT4iKIMneO
7wAyCYNsNlbpovs1EOLnjTIq650tNbPFlrRVkZbaVjRDDwsLtsWOvhMoMKMmm9CCXY2fPhizKPOf
CdIWqV901e5+metFmwG79nW7EY1ac123vJQ6+Dqg1QVgdrttehojtkupYfX8lqnyIigifVLaVRta
C8noLRertq52NSAsnoAJ0sQlK4IxPFMBq4vsnbIyBv62YVW1LVZodsMjkL1u+if6vWf/AAafMPyM
x/cjnncuODvRVlhrYK12Z/gzaxt6g2ZI2n5baWczGjhXMK5YSIwgd6BvbKyBpzXDW3rK4iAyetqb
tdkxBqWrgRbmj+TzUI7SBpnZj7TSXdaL+YTQOBNh1VbNMmb8ADYVdhfP5lTNagtVMzwIdNoojKzB
wFTLp00ujfkIPesa8re1UvLaI1Uc50EYu1IF3rHEmrk71la4uP58JYTFx9Lh44JU4OHjLJLEB1gx
DCIZiTCI85h+TbNSdPevff0r0/SfSD+XX8TnR0DFayNijtTa4g2ho1ODSBam9LuS2godvzTDVhB4
ySrwtedKhQg2S9X38H2DfKBb7CuYFqAeCfpsbl8A5JDHKczAwxgVms0YAnDBuuclxB4QemFvbFYA
RNWKyYsEsRP58XnOLldNMYOHbs1mSghMwyezGoUgFh8kwaAk0B13v7QogzSx3I/kp7V+MNcgIlHo
vIM2eAsvu0c5yM5ZjEXv65VhGBAOa7et6RNvULd2cHx96QgmlYdyWtqq7lpm1kDcQEeaz34Geyqj
tjjAaEF4ZM/fHUJZgUbxszUiS7T4F4k/jDFGpxhAhs3J497g2m+LazrOF5zs9tsSawScXoibRw5M
b5kit2Lj5edPmHPG8yfokUwvWnK27wq7KP4n6XY4p4YZfry20OCKi7nfFj6Vp0Ugc1ee/6Y1viAQ
6oP5phZRkEh7KpFDGKXidvUVkdQ3Kw+S1J3FM25wIG3PFYcBhSOFnh2Iut6tcNQz39pxlgWydA9j
YtqGls4WyuwqpDW7exVC8alfPRE5mJCEfUUFzfVPD8gFdXTacsLwlm1JpanZ/mcObgqZH/DrNaRR
uNFuDRx2/Z68h34yNJzEjDnp0xj+EZwmSlrxcSAnT6v3HEAJH5AQCQf9eRQXhFEBXVME25hA2yEL
iRefMegTbf0BQ0YEeGNRLoNcukc9SuuxRetzfcUxIvPxnJJMmiazsd8WtzjmpJRN0yG/5jSfP3wd
ugp1QjM0Y0UAnVXtP5CA2+zEzsdcvGE3yuwkp7qjdVuO6FwMTJm9uH+Cx5EfKhJvgSHOt6pOVGuw
alf3REE5r6UTVTMLtDOh4JDdpwVoJJEeOeTr6kllAb14VXlgj+SIPcI8yEsbv+J/lA8is55I1EIy
UyLy3H03evEPX/woYsoHnE0o+Egu3O5eFNQNcHO1fkR/YIAqdlTWYP6jJJoFUE7eT8JBmDXBQZKa
V2zDdopsFQLVitRP6FFzxq3Zf8bwpSh3tVUBodmN+aAh6DeoICmjIDZpD2fKHQxKSQlLjloD4alw
Dlar8mSP6BzZ0Rn77R5NmqzAClGtk1lhD9rzVKBO5lKPx15tBX46y19Igy4oae9NVz3UIM95AcyS
U7A5VynVBhr7thz5S6f2Jyguz4IydWrH1Swf2jDUqoeRLneaLrU4TKvMgySPrhJteVx2rVoql3I3
s89p0xWs0/di03ISwmhBDbsT0GrVDc0KKmirjhNHPtqfSUbJ6rs2CL6Fseud59BJHCFuOYeGuroX
Rveq2mm9myraFND5a7o5rthMBrHZYzRj1U/FeF35ihVJ7JK7K3irLdQ1mTt2ZN/2xRdWJMWT0p11
lMVSP4slcYbKyqQlKYoIyjI+/d2zdZEGMpxNU5mMb0IeZO4+XxlPPflvYQGJ0vINB99VQ8GBfPeF
3Q7U/wizPjAtAMu/aiS2ykWtiO0AdsONAI3tKT1WHHxQA3y4yV6poWIZBpl0hP8pjNPri/P0p1Bm
N6HMP12cx/TnNLxI6Dd5ecF/+xTK4iqU5eWFjOjvVzmPitObC5oYhvHFfPfXKrg4zZA9OKrr/LiL
8zyQs+E+4MVFCOw4Y23gCTgNsS4rb8NlfdcPKl1qbIXn3HO7fzIptE7CpvbTcTeLqE4eXXks8cZO
FaJLs3mZUraj9q65dDHZ/ZmOkSqv3b7s1Y9VoGAW68R9PXDeX3GZQDxE+ygiwle7TNhUSEXaIeCB
djSlKhqMAlFbQls3lXfAG/TZ/C9nMQDesG24U6qZpPLlKVQ8ypl6TkOsUWyYjBz5n0Es/bgMZRjx
RKwlrxnIvBY+55m1Hk8oQ6x7IUP6nKcX5/hxUfJ2EIS2KJUzlNYALAVBMggTXkhpFrvUYit57d31
mlo2+ZpwJIrZ6EqqDXDi8lL9OLyBSEr+a4yK04K35f+zQh3eaI5Oao5YXKnj0X6jhFhcnS1OU4/w
+uSQRutllEjp3z4A9PgxpW90OJ4eqg1pmXPLhDSMxD6JWRA6ktxByfEIkvkjSJyXQWY45M+M6oG7
BRwmpz5hvRNcuRFdPPVI0kz9qv28tmLrb6ZaOGdngTOuuWihqECZ0V0zjL0mb5UblRR5Ulu8kwKc
pnxn2qsBzhcxYvRmbKVoeFxlBo7KwgbwsDohKjUoUkgdfSEboWkADNCmlwYioYwKBR8srF0tm7vA
DSPkY8q/YUJUjDjD5Dj9OG1N38P4+iInAF8ryLMbyCt8CtOchQuzZAQxgDg5Bguo8DztocBpfOok
kBp8ZUkQ5aYHtCO7Ozk84CZMfcsx4sdYvd/VDMTX0sKxF6SZ+LlruBMkDeE3htQpnx+s3igaIQRT
/qQE0WEi8PZy4qQIktg9CIKHrzuTIow7o/2dnBwwc8Y6tw/c7YQv+nZLCO7EBM4KvqQhIWznM8m0
Tjkvm7rFpyXKSREFRXbi3kWGdr4zdkpYrJr16J2hjqvWKidxQpqEgXRnHc15DXLJ7pmh151pmqku
Vz/rYgqjOxTjY/Y7ZjvzXhclOwBgx+DLbcjOCm+iWt9dZZRTEChdKX3qj/IkKFJ3rG6NZ05nnDl/
5Gqc4Q5XipFVY/ubZWkQ5u4eR4NSfiQoRXEQx5OvsROgmO8a6Is1VbVipaMPimCVLz5vcZ8lM39f
v+DekbWBOCcMZWV2HEOyzIAha9pxDMmS1BC5B+nqPYqealX3ZyieqBofu/sTwTXgyKHiNow2SGXB
i8xS6BCqLEKUp9u+KmIfgJJbweqNgFocd7I7c2PjVO/6AoZAKeeZ81vOEuZAmL5m51IAQG/ZnVEq
qgtot3UDQjZtG3VLw39qKmyvHA16gdc0g2h2Ynwb0QzNo+mG0Jq+rn/JqLdFmylbMV+DZe5V2yu3
dGffyvDFmn6J4a/hCsk+YO/or+ESDiuO4iiMoQc6ts24Qlkp9JtEy7ma1dFT+UDb/ICmu3rt6vmo
5aIyAo8oAQzGhGl2qQcFVicYGlJKnJtStQVUc+yZS8DUwsD+0dyt8zdKMq0HC+Ku6kno0Ru0Wc36
uGh+HBvSjOF5QjnjKG8wT8gh89I+9EkhBJV2nrrTjvp/EpeINo5y+6FpWzFJanv6+M7gFIvlOZLU
yWL6DdCknDu+7QFF6DRb3KHE54bqGpyvr3p24z3RMJlwai/jqUOhGzgH9puGmSL9qbdaNgdslY2m
UZ3TW+vehpA7qoW7FXx9oeoQ3aIunFLDn5GkrnqeD3tFc22imDLDV4+m07vnhsC/zo50caWkVM+e
z6EkVpHk7un+/sX7SkMGZeHMfCOaJAkOZkvKT2lYN0873ajg1kXd91Xn2ziSZZDGByJHkeTt/Tcv
UZTOJx5KfBDhC3+Ej9C6KmcR3rk1zBararWtDzOtg+sS3XI68gatWjGHkm4Y9pu20oTfm4ZQtvhl
W6tKw/+GJS5tuU+rR1Pu1DnTjpo6Timrzl39zBpqzXjhXe34aKW6xRv79wiV7JSkuS9LqOocd5+5
ewGjbuLfcI4oDHKTvxAdPJjAbl0/qtSYKKTZvEDL3PQli06JBUTd4lIo40sh1UmjyIV3b8Xs/kll
oNVQ8QM2c1vJVxhey0iU/I6o3qAbJ6zdaSysmMmSbfK48ZaACYo6ZxrP8O6T5KjLHJnWE6fpVxS3
Vve8eQ3o9W9QBw7f/KjaejdYr0sq5lxegts2H08xZ5gGkUk2+u3j47BequzweYcQYeIA48x7eyFR
yjlLoWta2u+NKtVLzmdAYMtPD0zwhIQfJtGoTsGGm7EaQT7dRkUgY1cAv9eGqEZmwt7jNSEus3xl
OYWR8sQNVLnvjHVLeOfOM2B4+5OTBP18Z7G/PS1ljkvLfru0Hu8Oa7TAn3f99OLnqOVlUU5l2Z3J
GZ6W01sgJahK7bZslakTU42OXt9XQ+P+ELf+VNCuBkPGUwq3r7vN+CShmzIfb5lK3CddWfnxR831
0j+fesYUhfQ57AnL46vl9bgjqYd/uubcxVe4JhTGSevOrkfDWnnqi0NJLJD+jheHlxvcKpNGkRPT
GW/4vjpf7FZMsziMejeUEQ/76k+J18mTBG+9ojz5Wbskuo0PHiSOl02j8ttW49U8Qdo8wbdXXLmp
Rz3KOs8GSfpBj/UA/kw4L5+t8LcWVsm7rlvOQLl2WnM1nPofp4HMiZunc5wYyHNc5tizVM7kJYYQ
t93T+FcM8Nv7d1lG8Qjv2iNkF5KYJyZAxUGSiK5+/+6XP4gdDbYNZd676slZoiYXvsmvkQERjEHF
DbiQnWw0zCTlX96/+z3bSIAncrYR7qp/mTQQRVylaw3E5IyJPK6BaNKAPbnwTXYoBglA6Yh2hder
08v0g+P///fICvD3Ccd3jmUej7Fbkc7jIuESowBFJAX/EoZq080fTh3CllNDYLn0YAyOF+f2MiFV
T6+NghLUKK2E+aA0SfHPJ5ylkt85ypxOaZ1PN+nclnsaALndMWYre0wyGzPzRHQxo9ETI/pY+HCY
HHgiT058k1/xRGLptEgmNlXvpzi2gvW+b6moSRffd7hMo9pu/X1vKpf6u+rOmQSxHXx+e7pQURhT
RHpFqDe9V2tN4+Ko1tID79UCeia/4r2HAl4h/I8vtNQbobXAA+he/Xso/QiFSgn7FcreXDo5Tb6D
KyJdRU6tr9V4YzXRBm5rYKRe7CPTq+IpL2YnL7WcroA0IuxGb1vo31BujjeWztrqn66o5x38HKsf
K+y2th9sI/lTHfh0nvs98NPQu0cu/TgVyBBxoOMxXezxb1Pyxfhoj/NMfsSur4cCYVqiJ9CpufMe
iUQG5ciSeVkWByzJI0aSdIaMZGMW0Rx5MIgDBQZNFOmMGRlpWih5TSCIrE3HMk+Gsweo58K+Q50w
hPlBDTl6cEsUnNyVxoyZtjqiHT3quHqc7ZLZdmaMvd2hDk8bxbD5P5iHhMENCmVuZHN0cmVhbQ0K
ZW5kb2JqDQo0MiAwIG9iag0KPDwvVHlwZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8PC9G
b250PDwvRjUgMTkgMCBSL0Y2IDIxIDAgUj4+L0V4dEdTdGF0ZTw8L0dTMzkgMzkgMCBSL0dTNDQg
NDQgMCBSPj4vUHJvY1NldFsvUERGL1RleHQvSW1hZ2VCL0ltYWdlQy9JbWFnZUldID4+L01lZGlh
Qm94WyAwIDAgNjEyIDc5Ml0gL0NvbnRlbnRzIDQzIDAgUi9Hcm91cDw8L1R5cGUvR3JvdXAvUy9U
cmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCPj4vVGFicy9TL1N0cnVjdFBhcmVudHMgMz4+DQplbmRv
YmoNCjQzIDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDUyNDA+Pg0Kc3RyZWFt
DQp4nNVdW4/cupF+N+D/oMfuwNYRJVKXhTGAPbYDLxBgNzGwD3FgyD0ad++023PUmjPH/37rK1IS
daG6o1Y/LBJnZqSiqlgs1p3M7y9fhGHmp8qLs9CPhRcJ5UvhhbGfCa8sXr74n794h5cvvN/+y3vz
5re/3X567wU3N96797fe792xoT02kNbgd59fvvjto/KE8On55/uXL4QX0H8INJJ+mnlJkPmh9/kH
gf31H1HmfT++fBF43/lPKc2ff3354p+rx3W0Kos/1q/lavdz/TpaPdGD41qIlbdZpyt6pFZ39Kjw
8HJf3ONVxX/k3tNhrVb7tYg03OaBRnjrbPW8O9ytY/3w2cO3v62FXBUVhj0TUFHgtwN9F+DVtvAq
gn+uETLqfL9fy9XRe8b4LUgo1yIwhOTe+l/e5/98+eIDseK/X75YjnVxpvxEMu+YYxaf8u9EkMb/
gxn2naYPyjQ/9By9daLfNqzb3e/WQq2KO0wlXO3Ar2rbMLtafipRKnylXFP5Bl7uwHzMBwvA9OYl
CHvglQHZXn6kV97driSoin79hTf+4sTKNPAz6SK2xxz6r/fhb7eevX2E2T48LI79KJVeIjJfhV7g
y1T/Dyi5/8tZ79O4eS/i0FddAEw3SuwPBIEYghBHDIjhSAdCSeWHcfcj8t8GMXMxnOdXFt8tYi0I
ENsDMpg6QLIPxFz/XfMnEV4c0xjF/IkYa5o6lFvYKjfDWx4bu8a6BSUJ/SCk4STcaTgQFOzD/JFE
9WujW/Jv9Oe++EqyywquzH/Q5vzKWqjMN2sRrh7MPugL9YWkikz6MnSR6pBpay9p7rZ7ycndaGg6
NMmOsafV3zjJHw5b0nX5gRi6IUVWER+1pt7msAHQF3tSfalWJVBr+2r3uBYxHpf54Tup9+L4yqMf
trJptRBpe08vEpaFFipmzdSq3SPbkR2webzC+WbL9sOljy7kQ5xiyft8KHm6rR3Ij94eFpGZgces
8Mvql9fMpcjvlqYxikI/jFw0vl4enfKVkyU8dawjOwLaSHiLL0uELahcNJxhJaTZKZbSFNJtAMx7
twGwPuAyAAZkwgB0PuLQ7pphtXZPh4S0AEa5p0M8NozswfRVe5RgA5yh2tVQtdNY59DTml2R1own
NPvdDs5prdZJXcS0ISF1rFOg5yvS69AqYkqpzyNSaAfFQeRpna7ZeoZOj4c6nSmercrGKf5/qNIv
Y4OkN0PLNqLRyymVPZMGEh7ppMGtsediS/0kcmF7XhhbFMR+rJz83VWFDwGYsAkz8WK0cOE9wyQk
PZMQSz9JJ0yCfj9hEtoPOE2CBpkyCfZHHCaB+TVhEZr3boNggZywB0rFlj2gYI3CkXHFlQ7sAcY6
h562B2HiiwlzsNkXCKhZhV3g5M8kUqQJPOVxIl8NhX0ZlojIj6dM5DRPFuaAUiDGQVOP+ZocS9su
TEwoUtYG48ScNM9Gys3GnJLybGCeNcWOoaft0qgAvWfTCF9Hkb29mzKLc9Enys+iMzYZZ93yw1fE
OUacxnyu4f66jL4oE37som9pZkQUsAvlQHZkF2VTILu5q9hpuUOuj92lgrNkh594iiyZdyQweEuP
5h9Dle4s34XSMy7vXZ9N2S4b0XicCNDmMlCQglJnbr9hCm+YAr+QLUHgh0On4O/F4z4nrsDh3fFq
cXZ5V22xnovzJMgwwEHLmM4WajUMa+CZm7BGakUKLRo5tOhlJEsaJpzs+7L6smbxR6Ye9O/IYSe+
7eDJh5wE0Dl/rgNcRd5VGsM96lO2QbUgQo6dYkTSUMWGHYA2JeHdc/XgJ+0F5uriax1G0KYO8pqY
Z1ebv697XTIBUQ9f65w7MkfEO3uBv6zA2i9rAL7ynL777PWWfpi4yOZdUZRL44zJS3WhhHqiEOxK
wpNEfjSsMSznUV4oQyrw4XCPU7m4xKrIF05sz1gEmjBvLEgBKcxDk9+k7cVpT721akbt3FW52aIi
kPVz0OgM0mdjS5CNc2BzBukXyqTKaHQf2U1ebrY+8XuoOXyURZt8s86JQW0g77rRa5VDWUBCO2+/
fsMfVVPvg8R/Wd2RalmYjRRbKtfEnPXDuchkgFT4OLJzioeilwQg4uVEYdC8n0gCtB9wJgE0yFQS
wP7IeBJA84vftNyy6Gjfg4wuiMFig8geSC8JIEPhZ01UJkh0I0d4JIYFv+nBJ2NeUJuNGadaa9ea
+eEritXkQ0HeOwpcO1OOgHMueSIRGOAg72TEadAaKZhk6bDKNz1Y0xxPKJ1Rmt+QpISBSG8DIT4E
IqDfs7f4/eZ19IZ+D26EIJggwnP9TL29wQ8CycwbQSOS9zcxPU3UzWv5Rn9Ivae/YzyO1Dt8C9A3
Dl1wzuxcdTGYi/EV4ZjtDy0ZSyOWKRounIgj3fVRK+K+YL7WbRhNJc27K6DBtZqurS7FbJ/rVhg4
3ARAP54OFNNttghqGpfxzmmG586vFhvirxpvKHlq2mDaKECn97ndxas9XDjgJvF/bAqn3jc4VdqZ
2LADxr0/qOPEupZgulDG9zWesZtS9yFxNKLfVtui5NoGq4vDesLzv3RPiQyh02BPidtYb4XYbIX4
I/7dCPWGd8pr/BSB3hdmm2DXqAA/+rtNSN5uvHvMrtS7FLv2ncKXbkT4Rj/D32Y3Az5rdirTlGZM
B3/4PZPAPzEQJN4mRFK6+BbN6FHkYNbpPIGcpQmnRDpQfqIGhNyWRV5xTUr3wnHyJGHJjU/sU26A
2xYH76gDzteIOGNTXfrnN/z6fWe269fHe7h1/1Hvm/JfpiOLdvb9rjy6s0YXTltmpCmHma7isPlZ
Z45AD7EgoWD6zum1zSYjU76IXGScFAO1tBjIJCU/Z0DIZ+JGYnVC6iQDrc+mgiCgcRGaKWr747xv
uwrKTMvE8QEyUCcNTZLCHd3O3lRpBo/bMYmx5EOnZ6WOEkCrNlDQnWJ1Msk0l16Jamg8Ti/5o4GQ
pBo2Ot+0uOipQKLf0MGsk6I3rM5fKnoxjYuGGog3ItaOl6RZO4+93a3pNe3mjfrC5zX9pryZtTB/
f1qbrLW2yseqdj3KvE4QdzN6tSlvk96HpiNYV++5iXd3FdmuuaR4eJ9L90/EElCzqdC+HPPvy2ur
hEQmcdFwUmSSpd13GbG7Oe6+w6VgJ6F2zdn2J8YlUG8bx1676x/41Vn+wI0ILCcfIQKe0xfwvBMq
CO2ojIcKre9iwBovaDJgqIOPpT0SGQZ+4uIp764/aFcsHjLIKMa4CbR1MrhfEPAO2OO1ix1fz6zU
0hYqJApdJH4lEuw86X0JDbK4zYiCBD0tDmKaygTrI/bZtPuW3yFltjgxivwWJ2fOSTul3bQTUjFT
aSfz3p12sj7gSjsZkIm0U+cj42knwzF+BX7JQeLJggAlPSCDqQMk+0C95FOEBrY6P4McresgjcgG
uSceK+zBZx5LMMknSW9GApURn+oHtmlePgy9qW3+6Mo9zSZPkPuSuKg7mXvSHDWSMMXRcFiYNSRb
g0dInjJeozSTao+lNk9sdAJtPOzfySrwT7IKHOHCAN0KtiT8PEx1xEvvTUitLd57bZ8aIxPDDlFo
y6P4X/ixMWGNbQo+dm2TMZ7a/AWtITXYdLTONJGpyiZtHwwuiMXwd4qHw5Bmbxur136RPwPLHIQ3
IuogshNpbDYJG8f2iUaaZgODC6zprf4QTcyyuROG9awFn7AfUZaMhdh7PgHV7ZmP4aRSEFXqMpyz
wDObpIicf4o7HSQ5SzwX4EvQ9+nA91zuWkvl5Yc740ubftoHnXswDn/tcRvVgxNldcOq1jjwCnSG
DO0d6epdE+RVWy/nSjM7ydp919/OS6ehnj1nheJF7Jqz00u5WMxSOZZLeOSTg/c6wGmCo+LO4xCX
xU0f5iM3qnOIAalVLZvwZ5BEJJEcLINtARafmaQRFKM6ZkYbKFltHl7pTASiuiPaqOVqv0Og9qNx
h/KqaR0hIbveAiTBWHhUlCWHsgfDSV4JPmWqOWyfH8VUmsOjddiJ+JSztxXHpPaJ1WYof2//C6Er
b6Y/d5YPeDcVE85fHJXw4ozNGkmMUHEOw91pNR8zeQuZcPH7U5twz5m3R51j16dnkd9LVyW8Yq0B
dhcKxISlj4hDapDZsAJRbZp0jlrbUrZvcce+GWO6vHVKSU0pB5Em7puqFV1gEyI/SaYQ78qqKYgM
qh1xpz2I17na5hUv5mP+va2v8J7Bd3h4YZ1RRnx2MJ1S1W4ivTvfBogYSTbHHM8IkMJeXR4BgxJt
gITQohcjGZA2RrJhrODEfKYOk/pQJixUwo6UbCArhGk+JceIAt2Gg0y3xT+LJAsC43tABlkHSPaB
evGSoLBUtYdzQz4y5/Dvh9V6Hi2do09GTJGMcO/B2S1w3S6WZLq78VIaRZKgQuug8WTcZDhbH1WZ
5OywaG+odo0+bWDHqf68RbVoLBHqbVlnHL1vRaHTuehyvYMmMf4BuQa6w0vVvVwOTTCb9gjH5oSL
9n7l2jcFNO9TpZXYo6ktl4+gkQXmWLSF5SNfHKEN3OKk12yPAl8MKwVlUT2VnP3OjWolxc1quG2v
aqr69660/c401z3mNQ/0vO+bHF/pHfkrpnFVj67PUWDwK23rMQCM5BokY7Pt/uLMUfQocvHGGUhd
gE6isdyBzz6AeD05IJuWDI2Z7lXoR2knljc3ZWUd52LpnLHu/J2nUpxpcJC9/BJFsbGao/jaY+K/
/CtomVRHSuO4T1VowmFbwcXCQk5eOOKcV97TkU/bZs1VN6bfRfDRWxzWGD0QYM7Qjh4IsA7vXmm3
o1pBwbxjVsvLEto6hXDhgxOclw8DnWodLX5lrh0ynUkwKdfSC2HKn+kTCaeczDIfHYIeCOy+kR1C
3M6poadH0+0LTV/qUHdwigcKrmsAMFcf2R6ymCYW4EsnDtwgtll+YVKBTL1jzm126WlP5LXhd33N
00X0TISaYRJj4DDUNFXQf6vCqOubeJ3e3kgTr94mSJfqRPTHtjJKH6z7utKsTthGiamD3oo6pa1z
riZxPEhtIwCumyabfLPp12Jq6gS4eTwRD89f2TDElhvn5BXMkww5f+LAt7xKqSUFyZOhBzGz4b5q
cqzDEs/l9psPaDgI1ieCbEcPbUk/18axf7Q0X50k4GY19Iiw/mT/lFtC2NfE8NppKZAeapIJE4cF
L14MmY3lB95SxIIVqHD7W7wqyoLr3BzXPNbNtPWJFF0x6JsCLBXmXxz5jdfpDO/2yYARr3qZ9qad
C818rMVKzT021/tC+5oTnbYXc4YMbjDS71L+1NfPxT1qOx2yND9wotIlScyPTAQm+Lkewi6nNhia
rXct63B6D6d/TN6pKBGVtz1wjXhpa/Snrl0QdBN8fHsyfgn+MRu5wfEKYqRIZ8nYxaydu33y4uUh
xMlwU25YMhbHqdirdeCEEMLnO1S7sjj20oBxHX42Z3+OV/D7AzSwOci7gq8Phahc+Mq80pdFwimq
9F023v8+oZU2YReE9n5dV0vsuoLZ5uw9XU9ugsyPhgrPUm3FZLViPv44wSUtDvwnA6Rhw+2lHhuu
U0qn2gDqunXY1Oyb5nXR1rzR7m5X98XpLjNdo28/gX4COfC8TKHf4G97BxgUTfdoNYg/3qhe30C/
tgHsYlBud5+JGXE+7ap+zwHVnRD2R7UX2mtvYNC0bkowjX0Ypdo+ARxJiDqIFncx66VPQ8QQ4w0B
CH8e9NlTOwdmqq9joZ6uf2IXs62mWLkw0RNHiUY/nrjX6YLIOPFl4prTdSJj5PjH8T3juiWY65zv
QGNzzC5LE5lt9k91Wft4zahYxOnYWSheqDP8LOPO7ExKmKP5T3WvMWSED/Y813kPXdD0OMw2bo11
+uIa2ZDMOUVOBINUvmoDk5Wtm+but5hPTRb4Qeyi5goSmEW6F3EUn/apsXPL66VicfPQyEE0E4jB
+ufVrgnNOOXy3B5G23qIhWyfWY2EBHrfmCs8q6aTvv0ix06P+oqEPjqKmT7xEZF8j/J7iNSePrPn
PiN/MVNkOHJ5ze8mENxtHnR3yJ/WxSf2HR7t1qn4/Li+CZr2FF/57RkHX4eanTqzdQSgc8sMTfkP
3PUNx4vvnG4v/f4B7a1V87WYQSNGLqJpmqWq6dus56NPAkS0DvTnFL7jbuEbWYAsagrfSZYNmoMN
SFP47sA0VebmM6bwPYDiej9DtYXvDlBTi7Y+JceIAt2Gg/qWupZ/FkkWBN9T1wUyyDpAsg/UK3xn
qS/Ou7o0TAZ1bx4sXYNPlr2FkGP3lx+3uTG3umEf3fKmM51slqgvyT+4Kt1zqYKGxGWF41SdLHQb
Tp5xW2mYDkIDQ/PcizodNHOZ+8CpuLoz7OTJh9mUZJkfChclOk3GGRb3geR76NCycJr7c0gbC5+i
RCD6HSftDVLP9O8ju++xCUco9Ih6Dcn6fL8OndLbzsn9xOStk7jbdm0FMnUqPW4CGdNSbFqrTx7w
v1RCAtSezzyQ4h3ZAyvh9uom2CdnimYuXRFy55GDLlOgb86js2C07aT6UPp9qc1je87PGNQNu7hW
2s34GHA7DpU+pgdr++fjno35rtr/cpq1ufNTEaldx/TOsWlZ16ZBqQex3cwl+zbNgNjNXIPOKesz
bTOX7Ns0A9Vp5hr0V3U+JceIAt2Gfe6bVy0A59WrHZgTd6+mkkZYV5P4UjrUcBQMDBoPlq7BJw1a
mvCczz32RaqY+5FfuSzZXHKECnArk4Ock5bMsLA54jXBQjGwZIZmx+CTespB8+et0yrMRqiEr5Jx
hGhGDqIo5nbk4/KoY8FXNp21PkugY+/Tga5tg+sfd0A6uDhsOLTT1em8av//hLg2nVo3OejcEp/F
iKFovbr8cd+vuyBA7G0I61aXk7oxCru6EacmAjmpGw3IpG60PjOhGw3UtG7sfMqpG816moOB9Wra
ABE5pNIZyJwBwlpEg0zGOhYp+gSiTU0N06KaiIcM1HQ81EEne+hqGBvdMGY6D4pl5/8AywP5PA0K
ZW5kc3RyZWFtDQplbmRvYmoNCjQ0IDAgb2JqDQo8PC9UeXBlL0V4dEdTdGF0ZS9CTS9Ob3JtYWwv
Q0EgMT4+DQplbmRvYmoNCjQ1IDAgb2JqDQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jlc291
cmNlczw8L0ZvbnQ8PC9GNSAxOSAwIFIvRjYgMjEgMCBSPj4vUHJvY1NldFsvUERGL1RleHQvSW1h
Z2VCL0ltYWdlQy9JbWFnZUldID4+L01lZGlhQm94WyAwIDAgNjEyIDc5Ml0gL0NvbnRlbnRzIDQ2
IDAgUi9Hcm91cDw8L1R5cGUvR3JvdXAvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCPj4vVGFi
cy9TL1N0cnVjdFBhcmVudHMgND4+DQplbmRvYmoNCjQ2IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVE
ZWNvZGUvTGVuZ3RoIDQ3NDQ+Pg0Kc3RyZWFtDQp4nMUda2/bOPJ7gPwHfbQXW60oknocCgNt2j3s
YfewhytwH9qFoThyY9R1c7ayaf/9zQwpiXqM5MrKHm6RJtKQMxwO503df6+voshPYuFFaehHwhNR
6MvECyM/Fd4xv776zw/e4frK++l37+XLn367+eWNF6xW3us3N95/zdhImbGhOzZQzuDX766vfvpZ
e0L48Pzd9vpKeAH8T3hx6Aeh8uIg9UPv3efrq8D7iD/+fn31fnG3lIvdsfi2XkaLP5cv1OKYfV7G
i/V2d1gqerv+Aj+O62y/Xwq1+LJ8oReb5R/eu39cX70FnP+6vpqBRpFoX3M0/vgM6BJfJAw6r4nO
e/vbjedujZh9a6JU+7E6f2+O+TJd5PNzRSkkg6GmxZaSM4A3DFM/0aVwS6F9JQaFO6w56I4N3bFn
0hxK5Scps5On4vi4KR6PIMm532HXxajjxI841Ay3XC5IywUaBnsnEzgAIvV16AW+SswPJGT7w1nv
ce/te9x73QTA1crYnSAIRBcEGGJBLEMaEFppP4yak6jvBrFrsYynVw7bHWIdCCS2BWQxNYBUG6iU
0VIBwzaqtDwbSeBHipFR1T3lMFZzQ8fPeCL85Hz9e8wO8OYjSu56+UIuUB9HAM2d+Wm0iRhYGHK0
/ejNjK5kRZTguEtZAabp43Yp5OIwN1dS5acclbwxmoos9qOIwzZmi/TcUqph6edbos7WHHE/ct40
TRfTlCVu9h0Bva4TDtvYjkRz74jC0VM3hLw2Pea1XcanXgJn3xRQUaipepGN7Uk8956EiR9ELTLA
AgVhKLx3m/eL9dyaEyCDiEFcS8MyWaxBGiKQBjyHn1Ew1nAkg0WG3vxfJBZJBMMYSucXi9QXLF/G
5CKZWy6EQldkBsMG/j1tDmxeuMDYC/4KZ9+qUMBWSY7scYffOFPWURxyptKuw08UM0NH3X3GYXl3
n59yZJS3fTwsUbRB9IsdcRJZffLghOSHTfYAPD897gEkKxAm95D/xX2OAHRs6MBktDewF59hX/JD
gW9psq1X4IB7mBNfe60z1j3986y630c4L8qZiNnEOBO9ExHMve+XuSfDau8yCiVYJhVzFH5YoIR8
WJKcociQOJo9A6kEkov7DOQrJSE8IMSTZ1aCglzKIQLgYmkFduChSssUzyV3vUaXUP6JB+O4hwOl
F152+IY05rjGr7vTUgg4fOUOeLCSj7Ap+YnWMZ3QqI/5GsRU9hP6MpCxWs282ZHyhT7PG5kBWeRH
8YAjmO9RNhxWN5QTqTNvt52ZKiVjHwPqv4QFSgV+yOyvOQD5Jsd1ktCdMvx5/Da3lCnwbJh9eA4h
U2l4tss7AzLyAfqRZWUu2JGsw3Mpm35XboO6Gy34em604DSFrL9qLQt6Yd9w6eiYDVsYdLzRW5Pz
WxgwwnjizvJ1L8cWCzpy/diK0kH1MvgNvA/cHg08iuHJvlw/OkVFDk6TIzcegCDP8id8VFmFuR0X
HWpfnhsY9PouZZrfyVYKxWde7Xs+8+pMwGVeLchA5rUxCZNWJYbRm5pdLh3VeySjCVJicUBUC6SV
UNWJwuNTFxviiIkBRNiJtmhwxA0eD7eCAPRxR1mBJJZ1qvVDdmdV13G9p/DqExuCTqVGqASDkX5q
Rl1kOTdXdBLj8DYh22NuVNQDMKPLlfmZIn0VcsSMhpZWrOqiDC9WqhNjWJqZweMWqHcj/2+xJacY
p65SxRLkhFnlHfpSZOBYOzsZb5KSO9OLt18oZ1+73WFGKve7paS9/EQhTLfYcil2OESB4LC/mB+d
Rn0/tNhTQSEkZRDQxykej7wlnkqHDMG11N+pChpHXLdMMeJwiqBox9rW2IDU1tiFcQxh0CyFtqGs
/xE0qqEukGMwg2a1s0UU0m0ZWBY8LfscihwAW+90YCyqBoxqwbSNMyrhyjhjDMUp0W7VgsZGzNhx
IwRKRp6fqLnDEBb1aV462af7zGqDL6BJn1jzNI1KkWqEZ6gct06Gr1Ymhvgad42Tobh/7Ljm6qf4
3f3u5MF/G9ulk995T2irRiK1ibTIMPATwdGSeQ9g2yLj6ZOVzLMT7SuZyALbibxbtIrhIkOl48Fe
3y212WjSR2QNPpp8JkTyHj18d8/nVS9kqk79tOswPS4VWYMNWfmop8x8IXY4K1Iy2GdfaqxodP9S
q8LDycsOuBcwJ3krEe0KHVWTuMsO3zzeizzhnlMmkzLi+ZY8pqNHZxuYGC/KFOcz7aSKsCTZXl9+
PBVIyNP9bl9mUgeFbubzApCR5Ig7xwAmTQOoE+nHCR+L2vd8LOpMwMWiFmQgFm1M0h+LWobRK2CC
DDuE1ABISBOmxOPCqBZMy+Khkymq/h4twfHQnG5OOzavO/r76n9ahtjFOLU88bg05wrhbezA2b3J
lGLBlEb0Ujpq+SxeKxWD/A27xZ/u6O/LDTJUD1s/NDH5n8jko7E53h6NSl5m8vI9miVB2Si0XNpY
riK73ZtaXozh2RGL64ikUosQqtHGbncIduejWSNF8svWo9LHgJa7mBGCxrcZ8SsuQgDBv5PBfEvh
6g4F6QQWd1fWJ70NvqBMZZ4d87sfjX42EWrT7M1Nv4QgIBUc/YjWtTxlgckUuuC0CG3SsN4DKW+K
Vl3jQ4E2Hh3BG9CLeR9oP+7myI9g7IyA1blRYn3he0SYIxa/AovdbbKSBWNvSX7rSs6JqhoFCSQ5
Tpln+qzqBg+yZre4a1uk4AHl3dixHwk2u4wTfYUQywksUEjRLYWAjllJ+CcIAyFerdRL+gefJDeB
jF8FIvo5EPpNIOJoFcHj6CYIArl6gSD4OA3wbxgV0BAh3uJkqxRep6/wTwNqJiXIMKG38ZvVC23w
4IQisCP0K0MN/E7gSWr+1sEKwWF+qV+XeIkkRBlHZjSScBOvEovLEF5ORMuD9dC6UosngL91wtWD
JkugimLM/vbz/RxHImwltbUK/XTIkTDvBxyJegLWkTAgQ46EO0m/I2FZRq80uh2dtLYDgZS0gCym
BpBqA7V9CZX4MnViS8mFeWE3tT08eNSTUDEN7/MkmOzchXgTGKZYvE5nEtjYNeox68jUfWZlqZkS
oOjG7MrOhdPcxIo0wRsKDLFsgn8qOjjQ2CbFoBvL8IfdDP+lwhEpP+1aIHR3stM9MHz9sEXer7cU
tx5zqodv7mffBjg/eKj6yZl9G4TWELsy2EZ3odvPf+kuaJCKrhZ+/iPaj9c5oo0W0Gix/ox/9xzL
Nfkn6Gus92L2QyMgPE45ascDDYO2DrV55au7ccbg4FEP7/uV76V4gUmh+KuU74XEykhgNuM8bTgH
Omq1YtDZqC+/w9AAoz5V5jxJ53mH/AlbEsouA3KIcYxJT2WUFcLB4fyEl8LUr69sNmyPdJhadYZx
g6HQlLCrVFnSDewSiOiKcrWURS1oZCkEyI0tphkiO+Xt0uQXMEYgzthQ14RWO3ONRjYbNeA3p/3Q
94aqkZdyqV9NUM4XtgizdMCKI7EEd9TEV7YSW+wqLppKbHasC6+46GJH1a7i23JgUM1OSr14O1Mb
22BLD0TLJzYrOHXp2E4Wht+pIRuaL2p68yqhBqHSm4/TtOPQW5DKoW/AVJ50NY316TtQFMQQVO3W
N4Aqf9uZSvURRXQbBvJZQgeAzRI2YMayhEHs6/M8++7VkeHB426DpOGdJm6n3gUi+YS5wtMmO6wx
x97oQNvu6eTyTvVE+kSi/Jgjb9xeG6zn2Ouka68HB48rj36aKS2I9vD4xZTzjTLY5KQ9TSKl3d/n
3e7oD6NH8Tc0pp51pL3CpBWF6qpHq2XhlZkoBy31NUNNQnORPa6MsumRNulH0lVmDKthLuRPSCa0
my2cHV3q65hD185LgiqnnBmp6sMmv/Nu0QoZTpzKbhhrwWamVGrK4TGUnuHonYG3t08dlQDHoRkS
Z/BY2yxV+so+frUSyiS0KlBMaCEOA45ZMAOBOTQnEWbyZD25LZxoZs6UogpRQ9yXUnSwA0WWXkyy
EaG0MngWhD+XSb5OtjANVkLYZzbRh0NKRqhmQlEEqxchZfZWQr4sU5CGdXZ0Uj02iUbMVmqbYAQQ
8VrT1jmPA/l2FQOL374hkgId4y4GkQKQG8LX4L54ZXY1uTFbiJTfxGahJulpBMJmMtXLwaTjxKOi
YoFV/v6NOctLSVteiqISwFD3jgUZ7N5xphno3rFQw907janY7h3LwAEvpQbgvRQXZsRLkWHk66q3
JQl8ttQmu1+LocGxO1h9VylTppEfn+emFMds8wmvnt6hk43XUONWDoLxVCbTaIuYDI2jvoplbN1T
zjNWdHwVS7QzuIfoAQ3XTzScaBG6xY5e3dVW7LLS2pW+iN+QYYh1rdxqe+EWORg1cdbyek2qhF3U
3J6c0Vc6HTN4/noAszThLQpm8wZHlT7xyoodhcB3eeW1VRdfsIY3N91KmwjqLCnufj2m+xGdyZSU
oplI3MI2Jb8UHnuVZTpK3LSYQ2lT1oVtG6P0jYgpWxGxOyVMQb6RBTpVQX6dCnl/i79+LJt9bbL8
b/iKrpId/0AP3RZktzu8o3nir1ZezPQoRePTaVk6PAPPdUDj+zESlx4tUwoMX47Y1TA7Ean2heSI
GJV6Ob/U6wibOTvRo0nQbcpAhK6f5XTZCYUQE3N3IBuSyv09sePpUyuLtK8uCewwlTXYo3DxmpTE
TvNnSDJcrqzp2mgvgfgFDaFS+oLGh8WH5fzItfKV5Lgzv6xLHWO4x+AblfXuzZaL5QKmibq25uZL
2QBJu1+nKWw2uMp3OB8aaUs7acsqj2zT2x8fKceMWVsaf6p6Y46mRxhTyrv5pUwp8GIlt9xnMOVK
kQvSj686cIeakz0Zd7A421L/1j3H8hnkUmOi5kzu9Epm60IGRjViJKQzIMMhXT3NUEhnoEZCOncq
NqSzDCzvSpbsc0hyIOxtSRfIImsAqTZQK6oLU/xc4Bn3JWX3TgaNFdzg8ZgOWBaxnxAoyk9TgPIX
eJjb1zDQYmCYdyJIU3R6ZNPQU2mF+ASrIgytbFPBdHQhjOfQjarobnng0j0K6FLA6B657etro1rx
JvZzbEgs8VupDGGjwbaR9zMucspuXcCSPPWaH7Op4zc5qWe4EnjTLlvWZBldPJVU9IdUPHQ0x4JX
vDxFPc79wjE3wSoOsPeKIdinHtd/53zKfjLeVNnvAPSgzW6r7/qYogprM6ei1+EA+nNMZisLijYj
SAdNpgUZNJnONAMm00INm8zGVKzJtPwr7zAmneqxA2DvMCadsnADRrVg2vYyFn6iHLVlQbsKRHWz
oDRYc4NHlXGYJMiw9nbD+Vo/HEubWN0bGrmyMZUWAc6a4EgZV7+GfbW88+zr5jotyczgUf3L0Ex1
2Z7bdeAL14rX6YypLskc6xb5L0t73D9h5jnPyytpJ17vTFyLTAX2FTBrGfg+TH/q+0Jq8ENIYC4Y
atgr5NPRST+RHLrVPjMf+Vov4zo0nJsE5H/CkeB73j+R0UZmTo8bDKRml4FSnmPlp33fTMCeocz7
nFfxMHZbobjOTUeaYO6MoaP+EJy3bx4cLLXPfzBANsKYIyb/WkW5p4LvnZqMHMYJwSE/wx6rsGmP
kbWxHLTHFmTQHjvTDNhjCzVsjxtT8fbYMHDAHtcAvD12YcbssYj9qiiJFyg4f151+95prOAGj5vj
CN50va++rGbHSd7uvqJnvMcuFN5ET6RPgE8sOfLGTTRxtL4NxHO0mxC0FDODxzVaP8lkobH0lT8B
L+uOydpQ20uFTmRUdtGmpPxMQvzDgjIF1dfjqmQ6pQgzupCIk8T1dUrKCG6zTVE+POZ3nvmsONp8
2kz8jCanTy7kh6LhZ+XNcyQRBcpGXbDYmYmS+Igl6sOyvFho7js6ezHgBU0lRYdw+jlS5rzgfCGh
GJ6iu8DwzP0M69P9DtwFPeAuXChM8I/oGqcmEygR4TQfu3l2tOcY96v+ojX2yBXUPkdtjfjtHlOz
NF6Z9yusjaTzd9gW03TntEbHZpb6HjNOvN3ld3Tt9ItX3Oc4y3Bj4qUcCgM0cd0PGmdHUzarr9LS
ATNdmKRnSNrz7FT1zFegdncfKm+IyhnlFVqsStDtWbHob44vv16CyU/ebZkqnVph3yGz7nPcllbm
HS23jF23RXXcFgPiui2dNLczTe22qI7bYqAabksnGd6YSvURRXQbBlb3OaM+AFH7Y31t4yMgpUEX
crjd3SGlvDja+TCTg2qgJd5CDbfEN9CpFjoHRjRcP26mAaiu7JQFhXFHK4jGKkPd2WNn9tZ89v+8
Aed7v3ifV/4AHcetd1dFcJvH+lr7ofjDwefOihcBo6g5a4e2/wFq2PWADQplbmRzdHJlYW0NCmVu
ZG9iag0KNDcgMCBvYmoNCjw8L0F1dGhvcihycGhpbGxpcHMpIC9DcmVhdG9yKP7/AE0AaQBjAHIA
bwBzAG8AZgB0AK4AIABXAG8AcgBkACAAMgAwADEAMCkgL0NyZWF0aW9uRGF0ZShEOjIwMTIxMDE2
MTIyNzU0LTA0JzAwJykgL01vZERhdGUoRDoyMDEyMTAxNjEyMjc1NC0wNCcwMCcpIC9Qcm9kdWNl
cij+/wBNAGkAYwByAG8AcwBvAGYAdACuACAAVwBvAHIAZAAgADIAMAAxADApID4+DQplbmRvYmoN
CjU1IDAgb2JqDQo8PC9UeXBlL09ialN0bS9OIDIyMC9GaXJzdCAxOTU3L0ZpbHRlci9GbGF0ZURl
Y29kZS9MZW5ndGggMzA0ND4+DQpzdHJlYW0NCnictVtLjxy3Eb4b8H/gMTkE03yTgGHAiW3YkG0I
kgAfjBzW0kQWvNoR1ivA/vf5vu7iaLxqFnvayWG32Y9ivb4qkkVO9GYyMZloTczGOtwUYzPuqnFh
MmkyrlqTrPFoRmeCxZ0zcaomeVDik4DXeBhNwouUTLZoZpPxl4op6DNVU7IzeTLVBZO9qRmfOWMn
j6cR11JNDsbaEE2e5cDzhCukgTDWo8sMwXyJpuA++GzKhGv1JldjY5xMAX2akikeV0hS0E8G84J+
Mjor4Fd8MAX9lArBQFdBV6HiNEEmi2uMENE4O2WDrp2FGWowzkHBGnGFzjUZR3lqxhUKoisXHN7T
YlRiQkfRgSuUcJHioXdQQu4JfSUKOKGz7Kk5essUFRxd8fwY/ZXKj9FhDfjY0glgC/MYPwV8Y73x
7NXahEZiIxrvLPrBn3e0oXXGezKFDXyY+KSikfgEr6JjA36NdIBDh4ny2IIGTQONfU58BRaFrxxe
FYrqwKICHNZPJkzTRD+hESGG90CIA7knVGhyUAbYB42ABoxofTLBRzasCWGiWysa9J8vJkT41ga8
ipUNsEiRrkaH2ZJpRoMqAythtlhAzwVuswGvamSjAKGwsQ2A9hT5TQXGHTsEai0xhO+iI+iJfW/5
JKBBuEG4GKCTZWSEGWDZxAjlLAAZI40Qif7Aj9Fznl8hQGZXMj4KJUyMIzoFMQJt2PAIKTqF4TLR
y4wgqmIBpeToFMaNo1MQL8nT8pApeToFMZMCIYGISoH2QTAlsCfkGX98gkYmNjLDkAoiclKhGJkR
SQWhUqoUA3hNFUFFV+WJ2IBpMtFk4Y/MPhA0iFX6FN9lRzEQetlTDEZzsHyC+I3UAirlWBliiNwE
01qGaOY38FDOjHpEVC6e4YgsUcgdmuRK7ozLCTC3iKYywRIITUS8Y4xaNKhpZSwDlQ5KFg/AOoRV
oeOYNgodh0BGo/JjNOBCPEHPCTB3CKuSMp8gh2QYgcFdMsMX8II4jHv0Uy0/Bq9KMRjwU+CrgAZj
HwatxIVDDFb24SBKdRQDlNVTDKaFwHwABWqIfIJX0bLh0IAbHWxYkyN35BomBwcv1swE7JhdKAZe
10IxoHYFM2YgNOYUhJAA1PmICZVx6wjdiRBzc4pxgW+ZmRh/jvE1MQCRvpiSmGcQeGhRHD9nJxqK
4EbsLAMBEhUNQ6dPmSIF9scc78KcwClUYH8FmJkDfqpuTolMYKRgqNrZp4xny0h0BIil+92c1njv
mEeQGyqzKFuZ382DgyffwlZhL+w5Jr5lbkyWz9jL7F2OY3Z2byK3zPQe5wQHed2cMmdDJvKolHlO
djAMWoEtYNolDkJMHm7Jm4wrDijwEZ8xGYa5l8IWookKQW4kIj7hqEfFXOVgyeRFYFMZzw4JfR8s
bcp3HFSX5JlIVPmsAlSffXZ4yrF3Ms8Ozw/P393cHV788e54eP5w//7lw1e3x7eHp6+Nn98/MdPn
n3/6yQaSL14+vL+5fXH8/eFv//i7OTz5ydh/m3NHGzu54Ot28/V/iW+4nq9Z+Ma/xDd9ILFC8vSj
78llJuAka77k5VKWS50vQOh8mftZFUrlkK8nKdeTVJXkG7tGY6fr+dh1GA4YuR2M1nGn04QdNKs4
yw1n3/3z9OqPVbq0Std4ffftKhZ8D0NITiOGq0AaMYxdhmnIcBWGI4Z5GCXfrdLNBhcziHA7nLka
BmUaqepWIyFXVdUyTgirqi7irArqR4I2OfOf6ZwuaLhg+IhyjIJdHHOX48A2SzouaUy/CgCn06yn
J7+DUdhBE3fQpB00eQdN2UFTd9DYdQRvHHSuIhpgYZVIpAvTVcObTqQB9Soav4Mm7KCJO2jSDpq8
g6bscVDdwciuQ4HFnQ1I/Yiq5csXX66TXaToj2jjFphfzTEpHEez7IUA02zrL6iaPV88W+e45HbR
Z66F9SWoqs7rqGZ5TNXZTX2ObtMs8WqOTtGxbLZyusLKy6JF9Jlrhz0JzgHw4ubn2+N6b058VRTL
Rc0GQuMe0eQtWfgxkcpoLoF+ELJH2zW2a8a+IAq6rV0SGy/LRlZcuwJ4p2nsOkRW19h7hWHQGPqd
DKPC0G41cdhuYi8AXLSZy9N9AYqmcewQ5YHGtc8wTBrDtI9hsIqGeauJ8xUmXqodos1cy+9rrIKq
dIj8QGMFVCFpDOseIttJL0MxJcqDkmbOfYzTzBV5Jgj4g+SboGBy26T4I6pJ1z0qmIj6jKiTaQZU
YRdVJ8YHVJ1AHVDlnZYUX0aZBUnl0Urp0UYFXee+x+gq29EVZaYgpVAbFXSlTeWXj6gGNkkKupLq
BdeJ5SHHoHDcbGV3RQwnsXISKycl6SV1duQ6MZzSQGcFWUmdb7tODA+oOjE8oOrE8Ei7LKNXFjtn
DVNps4fTFR6WCE4yA8/K5CyrazrXyS3nInHPBsrkKOuY6gzdQ44Kps60YyvX7VbOkjezWDsr2aro
5ZRO7iiD3FEUZBU1W3m7k6OSrcrmbOXddisXiSKpx/JwQU+CDatIJz7z0qtvM6k24kjspnaVMVF2
A2xR1lVFnfQ3F8driGyHaDBxLxL39XIC/6iPumkVeCXj6vsMy3DFEBs8LojSAB2yYqiyOKtB0Vid
i4c9RHEPUdpDlPcQlQ7RoHpRJShqM+4CJx6xWa59WPFkjSJQ3UNkO6EzUINnMBZxNUwMizENlJer
pBEqF680veZTRn2DqaOhXQ/EEZXvUOkzF559WuStfXmtWmmw62E05Gw1SA3nSGcfxc0+Egs2feaj
XH2d1VqDXQ9oZ/VVvLMKKqxeN1jPBmOOWeE4rBecrVy2W3mxXNNnPvrWlcDpyOrkjnN9vqOzU5Dl
9DFwPe+MOfYHwQ+0Qyu77flGLNf0mY8K9nVWkeU6+WZA1ck3A6pOrhgU153UuJ2TbOWUbOVVTLn1
8XsogdcwtXlEuVzRDT0s8ePF017JVnq53XVyhx/kDq9kK6/7eX0aMuaoZCu/OVtdruhGVpbSvugz
n3btSqBX3H0nd/hB7ggKsoKarfz6WmFE1Yn3AVUn3gdUnXgf2kTmcVJ7dgv9fIq4j4/NedZfMWeQ
fQnRcz6z3PeWWlvynTnDgKoTu0Hf+3WyqnVRQVfUfdeJ4SFnZSwMw13ns4+uiOEgi5UoPorKWBj1
FWEnhuNgdIgKKqK63A+dGB5yVEbAM+3QysFtt7LsFYg+89n5rgRJRVbo5JKk7/+6pCArqSNg6OSh
IUdlBEzDHeezla/IN0kwnCTzpX7G21D7Km1ZL/lzanNyya9yXkNmMG2Mbbm0xWtDVNNZl2bdAevJ
b0C0nvvOSeTpzf3DaolmsaGYUvY8xKCLR40U+aRqvmxOGKmdSzFfavlLkVmO48rRUyM1KCm61YVg
Kb0ZqUstdTGzVKeMOECqBFJtkWKL1FrsJAVKKSFYKWbYSQqRkxQyxYlWlrNWlvB2kn5keSuHdVq5
tUFv/mnKcpWpjhj2wpAv7o/HZ6fTw+HZ6fb4/c07I2MUDH68m98a2Q2ktc+YOL/94fj7w5PjH6bh
/mv0dXd6OB5+4L+v7l59uOGPLn4+/X54fnz5cPjmePPqeL+0SdPa397dvrk7Pv/lhhLywRd36OHm
4c3pTu7vH9785waN+e7H0/2vP59Ovx6+PL18/xYyzU9+++V4fFgw8/3Ny/vTxf2/fsH/i/sv39zc
nl5fPHh+++bV8eLbhQ8+e31/8/bw9ZvX7++PousP79/+9hMs0rZaTZHYmX/Jw5aff8nDVph/yXN2
wvU/CPnLGF/oZFtDdjUE8e2EOeVa9gDkZPX/FP1L//+3EBA6qUXIqb92Fq+dkPtwTo2yyEmudqCq
nXNqx4/aKaB2OKedmWlHV9qJksdHNtrBiXacYetmfNsSbxvVbfu4beK2rdXeJmTbCmwbdG3brG1e
tS2lttHzYbtlNsaf9xVaub9V3bcWjh9XZlt99HH9sVUFW22uVcxaHatVk1qNp1VeWv2jVylo6/e2
im5r27bibOu+thobrUDaOuDxPLvNftsctM0M23ytzZraXKbNMNo4/3Fy/vST/wL+zoMcDQplbmRz
dHJlYW0NCmVuZG9iag0KMjY5IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDI5
MD4+DQpzdHJlYW0NCnichVLNaoQwGLznKXLcHhYTa3cVRGjdLnjoD7V9gJh82kCNIcaDb9+YWEv3
0A0oDPPjMDEqq1OlpMXRqxl4DRa3UgkD4zAZDriBTipEEywktyvyb94zjSJnrufRQl+pdkB5jqM3
R47WzHh3L4YGblD0YgQYqTq8+yhrh+tJ6y/oQVlMUFFgAa0LemL6mfWAI2/bV8Lx0s575/lVvM8a
cOwxDWX4IGDUjINhqgOUE3cKnJ/dKRAoccHfBVfT8k9mvPrWqQmJSbEgSjxKTh6lgTvQgA4BJQE9
BJT5r6x59Cd9K5M+ell6DupyVQeeXpbJEi87xv+HZqFJlgZ1ciU0ND3+aboss1zgNjufjHGL+1v2
Uy8jSwXbj6AHvbiW5xuSXatfDQplbmRzdHJlYW0NCmVuZG9iag0KMjcwIDAgb2JqDQo8PC9GaWx0
ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDk3NzAyL0xlbmd0aDEgMjA2MzQwPj4NCnN0cmVhbQ0KeJzs
fQl8G9W197mzSJYty5JteZOXkRU7TmRbtuXdjq14SWKcQBYHrCzFiiTbSmTLSHJCKIXQEJIaSimF
JCUtUCjklXXM9iWU0kBpgX5NX1soZQtbgVJKWqBlKQT7O/fOSHaC29Ly3u/19z3d8Vz977nbuf+z
zNjEBggAZGAlQFXXmp6lxR/ZvMAbLgPIPndpV/cS87elMoBt5wOIZy5decaaN98z2QDOfxK4otKl
a9Z2LL7L+ypwB04AhK84Y42jZtU3nkwCIIdw1QHviGdszQV/Xg9gywfgrvVujUrBd1d/E6DuZ9i+
fnBsaOTLZocToOQBAP2KIU9kDPIB198WxPnGoeD2wTpN4eMAjdg2XDXs9/he7lx8G67fiv31wyhI
Oqh9CdtRbM8bHome2/K4iPtzOQBWYYs/PJoSMQQAPFdg/0Qw5PW0X97aB7AUm3mXj3jOHTMO6h/C
+ftRII16RvxX3WpdAbAJ9TVXjIUi0ent1xhQn+W0fyzsH3tid5YdoEYPwP8AKHfiez8648bIO2en
tb4HKbg1lsOv719EPx9dMrzngwWf/Fj3aJIHONDhrRScp71mqglA99MPFpzYq3sUopA7vQ/ihW+l
Y1KXQCfahRYOjOCAQQQ36VcoQ4SzyBUgQpJ4jYgMwreUT/IBDJIpLo0TRF4UNMmc8BJw0y4Qzo6t
vWKNJNHVJaOmaaqJeLTXkEdRcB1b9AFxLT0p8GIXPMhU/ZFy/7NFcyaU/fOzEuXfsQh10BfH1TM4
Vjg7nBXHxbBC45tpxwrfoci4H8EFwjLYxd8By+J9d0wL//VaJ0qiJEqi/P9VuK/StwD8bPt0jk2U
REmUREmUz174ApL/P61DoiRKoiRKoiRKoiRKoiRKoiRKoiRKoiRKoiRKovyPFI79Gw+ATOAp4gA0
5C0meUftmSkExyj/woP/B6sqM3nyBt88Z/fr/7rCrBg/47idrL4k3r6U1ZfD1+KSq/DeC/tgP2sd
+Jx6/feXf8T8P1cEuBbrYpAQUcvqIBVbFbACPOCDAIxAGLbCdrgebpeM09NsDh0jzRoTxDHRWWPI
9EfT76OND0//CNeadU17SdPLT8W96u/9VFr1HJfbf/YXNm5Yv87dv7Zv9Yrlvaf1LFu6pKuzY7Gr
vW1Ra0tzU2NDfV2ts6a6ylFZUW5fuKBsfmnJPFuxVSoqLMi35OXmZGeZMzPSTcY0Q6o+JVmXpNWI
As8RKCc5ck5nf/dmObdzQNbbumxGSdaf/vYKhwzpFqvNJDkd7gp1lCzaZcjolTNX9k+Cq9Eta+yn
Djld5kuM71px8gqL1C0LJfhlO83jk8tW91ttxqcs8X43zpHzOvutVovMleBXD3bh12keyScbV6Lc
alEkPTKs7Kf3oelXGlEIjVY31qv75cJY0+2eS8nDANNHTlHzdDJhnNTndnbJkDkJ+ldkMNNhbzeC
DK1ymR0VMSJiq4FDJpnvyiRDJuYVqPLJW9BpLzXOwUG3b7Ot2xdARn0DM5y+rTBqlSakidX9JidC
pnSv/Niq/smU5E5bpz8ZBcAEMJmcgpIUKsAlxiaJvo0wwOm7myc5SEpF+tKput303iy7Lh1AYOtC
3rAnY6bn0PSRy2Z3AU6LoQwFKUrImk5ZqyghBWSXR4ZLpcnyIxOXHTLCpgG73mfzeTb0y7wHB0wC
X9I93Cfn965chyLcCu+BYYmau4tV1HhS97A0gW06dgBrWxc1+kly37B/gLoJGbB1YZ+us3+39YhF
TsfPbtlkl1NxWOp5r1r4ie6cgESbExO7Jfl6VHdWr5XW6AQ5qPpEtw13w8W6N3dQkzjiZmPe2ONj
xnFd6pHkHZs2K77nuSzm/9YJo6x/34rWQfvgTDZRpdI3sJmqvNlDj9m9WZq41M+Oehk7Gvqr1L25
i950Ino/rMXZ6/q7h23dMxviwRHwJafOtVrlXDudODHRTVX0+FB7RWXsmNGfxoTFTlCfTtnVxz6g
j9kAd3R5utyqSB2wjk6jPQNdbrdVsTsOlbUlu8VKmzRBV9SWyJl2o/UR7DtSUd67ur+7y8JOL3Od
/YuO51iOI+5dGReTHBwz4ThuUTjqXWPrXaV4wXCsGuhTApiLWx6HquPZqkdzLEcVvKF/iW3JwMTE
Epu0ZGJgwnNoescmm2S0TUzq9RNj3QMSC3+C8vsvtchLLnPLxoFh0swsRJeTqO8tWd0rZ6xaT021
RBr2KImj3WZttFhN8TEr/1a3GnPo/RgDNOYmjG+hbnrMThZpCU01hzBDWGRjIw1ZVGhtP8aEl/kv
qzBW1uDiFho1vLukO7BGJQs9U3UemgNXqVJcxGql8XTpIRdswoa8Y1W/0pZgk+UucDnsaMcB2nMk
1mNeS3t2xHri0wdsaLec3jX/wL9n+/aEyZYuNTkY/yz1+uQjfXjGDxvlpEbV9Bmd/byFUxFn4SlK
tmMqa5Wz7Wwi5QQz5oTRJv3CJhvtstjZf8TS6paMJkx1BMcss9MIwoz6C9vjhOZRyDTKpFUmWVQO
mFdZeuezG7Ez7khS98SA6mmzj6U+DHzDc58NxxhteDyLMt6UbqMn/BlLb2rWLllC48piVUac5pYN
NDfLhrdYhfpaOvslzEQYuasYkLqlYWpsWRroYinBbZktPjT90kAXTYGoMh1iUV0ca4Xak32tovyz
OvoOdPSLLnMPN+MqroV4AqkOt2XR0tevstRoUSOK7tVDj3Jyf5zF2Bg0PgaeVa7KezwHHTUv57h7
Lsp7+05qzdqM9TXGM0Nfv7zEHltcaS+1W2Y3l53S3RPrxvTxJct59DHCQcekjexZNekie9as6z9s
BJD29PXfxRGuc6DDPTkP+/oPS/gOxKQclVIhbUi0Ab0EV7uLS2LjLYddADtYr8AErO09RIDJkmIy
At5DnCIzxmQcygRF5mIy5a2iO2cYKei3odF9smtl//nu4YkBNyUbshQHRM+2tYHM2domCafRy8k2
f4ecYuug8nYqb1fkGirX2jrQ/TE4JBrqEwM2DH9MwP1gIW7qwtRduBLp0PQ0ZtCjmHmtsqZkA96Y
YHV2t4RefBqOW0rvARQvlXd4PVQP6qY8zeU9XrecFF8Qh/TIOlxBp66AI5awOfQpgJO86KweG4Mo
xuDY4Zbddrppf4AuIEn4PrTM1ixrSpU1xVK6kcM9kW6rYY8TTYmcXLKbfuhQN5oImcSCTdzMrZCk
1aPmXht2eQckZFsA7xp0RqGUfiVbFIkfn+pCqZ/dyRa1E5QISklNlnWV9FmlZTilEhfEL63brSjP
WrvVAbi3UU5BjUpnUalOQHawq4fqgl+7UVU69CG6zKpDsNp2LsYgVZqtpMVuObWkx4MJR5mfghJb
Y2wyrpXERHSNRxSplp5cz15o+w5NH7Rtt84qFeU2fDr3U8cEC75DusA9capAXo+JM+lUaSoTT0wk
pc49QeErKTX+SYUg4dMECdSU9ngubUyvrcBJrlUvvpSVnf/kr7H64vlZli+en/vLXyHeug2rkTGs
giGstoxmWbaMXhjOi45nmvOHNmM1GMDKP5xp8Q/vOicvN5J1XmeudTve+Cy4+0ChtQk/XVnfkmxN
0lN6Q9PTDxJJTkltcv24vBq7jtx9d0YGG1L8tqWg6eOvc/auD/d8fc87+7++/x3x0DtE583xPurl
JW9qGh1299KiEjZ8wf7ikqaGa8neqzl7zr4FC5uy9xHj1e2upmeuJsff5OyuNzOzm1yPZWbSTVy2
SdzlK7tE+44LOftFFxL7BReK9hM7Ofslu3j70xeSC3eVFC3OIyvIcqiBItJNuthnA6lnn52kg30u
Iq3ss520sc9a4nS1EPueXcS+G++LcYOdeCft0jVAp6taZ2yyNJhz6s3mOnN6rTnNadbXmHXVZk2V
mXeYodK82E60JAnSiEg0YCA8ERATwoEB2gnBm8dbBBd+0h4Rv3fUghFvCbGEn1XYU4W4CrEL7xdx
VjJJdQU726yl8w1l89PSFlaVcQvthnJ7WrHNMM+WVlhkkIrSQDSKXJrRpNclp+g12iQ9L4h6IJxe
w/uKCqGsKCWtN41LgRbo4qP8rfBcmiYFUviUtBZo0bn59bqt/AE4oPtm2jOgP0wMJM2VnmYhBak5
2rxUszE7NV3ITIXFOmIAB6GHMcDX8BaQr9LW8taFrWWtpa3zWotbpdbCVktrTqu5Nb01rVXXqmnl
W6F1pbOPyOm90NvXIWcQ/FzTITvtvYd4abVcY++VdSvX908ScrkbpTK3B3N5nyzswfTdh98lrFvf
f4jk0u5dGApIiNw7sOurbru9QPbRd4cdBW65hoIrCtz4llezSrbYOuyfKhGljo6f1LZH5IXdcnm3
Ry7rHpBLbV1szClTyUmtWb0QpS0qiKqTlFXlHLkdz3iqCpM6etiVqzvoK3Gv7MMX2sKV6wfkPFsH
vp1iq37lenzR6cD4Fb8KyWAX14IR6w2gAxCyKVZ/aPCAgqffnv42rRUMMLWaYnEviIg+jv2IQfMl
MPKLpt/mXgLj9PXTfwETE9Pfu4KpL53844ip8RhKUm/26xwdcDN8HejYjTAGZ+An/d2i8r//Ixcs
D//DEXOVH8Bh/Fadlkm4FW5iP7kBuB1Xu2fWKLf6eQb0wbmwDq5HnQZhACXnQE981ACOq8YL8E6O
Sx+EN+B7GH1vkpfn2H832/lhuA6Wgx/axHfFd+Eq1OQ66IWdyMNM+Tmrn+Y8MMTQBaesNAT0N7yW
oUaUr4tRSxmuwDV3wzjsxfZuCCOrx+AIBOEbcAD1/yHcABfBlXBAcx+z2p/FSUjlmtGaSWiFrdAx
9fTUw9TW/2KpAiuU4vPkDORlA/J2P0TED0GnLcVsgF4lmCGTeh36ULLmfDAJq6b/Ku6b/iv1L+pd
fMf0H4SV0x+hWzyIvnGJ2Adl6AdVUAseV0ZmpqFYozFAud1eZcjJqap1OTCIXZYqcBqdnLMgpQxg
oT0jsybTnsI7Kyrqq5yOo+lNjvTspqMOvJpoBY6NR/OO5VH5UVOT49jPTU0mJzaqq0hdbRvX0MbX
1Zbaig2c1lZXX++sKeTMmdgw8GZzttlWR0xWE725Bk3WwnnZpZa0xW1S1bxc3UDrVzqXeNvy0+a1
lkulZm36FeTEJxrec6KR/C4rq2Rh3fxch7PJ1rs6c15N4ZcLKwucSxaUti1aUmEtn1+Wrxn9znem
XhWu+XhQ+OCj2/DY+IKJp9HsRrYWwbP4+te5tt91umQtsrZaiwoXLTLXJGl1Gl1udhaY8zS6PFSv
vYb+xK7UilctX7OosMilS19WVFTBkeaWluabu3KtLbzBaLILFZUVlTd3VaRDTrvdlA7ZTTntTidF
TU3pTTkOu9NZRRzZTuPuI1hM6aQJGwxTCWs7nSbaXW1x2T7fPm5iRWq1vEZjzszK1lqR/oaM+gab
RqMlNp63aU7tqkfrzG+wZojLSUtKqdViMd+amlRRlzI1llJampeVtSuvzFDQ1DjVNDJgySwtHTAl
084blM5bkvVVNSnEHxbXVidllq0dOPFhS3d+RYlQXa2xVHV7ufXb9tR7N35i4v5IUj++Y2r58tOk
mV6es59e5ijhq0/U46t+3/Q7/Av8UbCAE76l2sdRlKqHlHyOz+dTUuoW7HRlcMQIxbnFfPHVrlxj
qr7cWM6X73MZs5J1B7uSzZQYvPOO203gdMYAsoT85x1Pj/OOPBf+qyu5SUP2DIfzNRp0EXR03lmT
xTM20dcF7HXW1Nc34BffscH1TUNy5WLd1CvtqQO3DYxuL3eff+NA21i+TtOxYuHy05c2S02dRZ2r
ax0N6fylHcZP3K2LzQtKxOqPhcu+fPPegYduv/j0gqnJBa2205da2gevPHjG8FB+b0/nTjcovAnL
MP7n4cvCfSpvzS0l88yZGQDJKXxGxqLqnS78PkHPW5JJkvZgVxLMW2hdyC+82mU1mjNrc2r52n2u
nKx008Gu9L95cCpEFs/+wsbZRDKP/byrugnjDd2wwUnmZjabn4vZwSR91oI6/cctU5/MQfCiofpl
aZ8iWDjfurIQX8L4Wt3HO9rbTuU5t2jqZ8tcc/F8FlZVYhfwkANXqTxX5eAro2DgUnngBT6V87rG
eJLGv8hzafzZPKfj+ZxbsrLMB7uy0vQpB7v0MR7wNr5GuTwH2WS5YbeSDJDO4n9xFTfR2hoUx6T8
ZcxwylVVTlYuSdFkLqzSTf10X2qyqaw65S8tYtfDD398n9NhLCxOF6u5G5q7swskI1eno7kSn4Nc
LXqVGU5Tz5qBb6d8CiHmzINdZjgpSlTfyHai+oa/PcJNVPNS/Ugbp+hH/toydYIplzT1GOGSkwRq
U3Hvx76qahNTTTi/vLwsjdkMNUM7iC/yP8On6wOqZu0Sb8XHpLWULy6u0ulz+MzMrqpWR4vDUdvC
V/Gti3iLZoHLtYBfsM/lMjbf0tTUeLCrKa2qOCMj/WBXBtNRcUvGKHNOmlOza6pIjpK31aTNHD9m
p8+1sBtZ0tLHYRZ+8icbjT0sedscDWZOPpvN439Izrptw9nezD4TM+xPLjCYa+rnezZ3Zq6/PYLf
7dSXeYKL09ffvl80mRZU619t7NBvuG/jgI/70KBN+uLWLQHXuqlvLVvIKCYnGs6pXLbIdfFFG6d6
yYmNbmnZosV7dq6bOoO7NXtdYX5RGl+nm/pE+MquEVBswF+ANsiHu1Qb5Cbf5NLpkpIy07kMglc2
nwm35Bv51NRD02+48jOzl4HOqOMyeZ1mhyaVT3VpjPmWg135aZmUJSU5HLVDXo7xKDq03eR0Gl+L
PzRNxOlwYgKvttz3+RdFL9QyBrO1ttIZelVnvLx1if7sewd6qquGkornzR/cXGdABs3pZVUp/I/f
F3ZekPJSbf3Ky7Yuo8x8oZoRQxm5AN+1DMLdUBj3yjbRYrZw71kIQFZGRpI5PcuUZUzS6UxZfFKa
CbOxKd2lw3DWmf+I37yBq7hkGUiFPG/hLftcfJaSLdFtnszLPWrHxiePxE+iJIwYM+iUsPGc6irM
xJ9z3Sp3iZp0GzJs9PXAqbVqrcw7Mec2cDeuvn7d5uH0869Oael2lBVONJBFWVMPD5TVOSv9rYe8
/uBQ++mc1qktWbTpCx/4p86/YeWi9qXLkJ1dyM47+L66EMZVdublpuYYDGkZfE5OORHn8ZIBXzUP
dkFaXm5SUkFWdtbBruxY8sB3IycCY84jzCNiTx+MwczPNsudYVUSo7MGX0gznJ9+fNfH3oS+SVou
NJira+2+MRY7GqPDlTL1iivVc+8Gjy8luS9ZW9XGPzDFN4Yql7Z1fvWCs8hdn6y19OcvtAn4HJnY
tSVQuKqceMtr0yvm0R8YwDI8+0N49hzwq2cvwgSVl5xkNBl1RhOfnG1IMxzsyknJJEJamkmXRE2E
qmc7ae44OQPRBGv6++PdJNsgam18JUff6urT2esdf7OlZH7nms27139po85cZsc0vvy2m8uqkvkH
atxnXnT5DQ+fy/25p70AX8VeO066/I5iHr8FI9PCVA/TfT68req+JmO+EXToZTrdgvmFN7kKCvI1
2vz5AlhzTFnLOGu6lcsWMrTzs/SiKBzsSk0jOkFMSysoKnAU3Fnww4L/LNDo+YJcV66VT7OSUt7q
ys1nYUoDNOaH6lnosaiYWZ0lABPaHiVoWiSi5b9zS3eGQiAor8fZGo7TarQGDr1lfoMzi3oS33A4
Ob2sgnJJViOXhLPU3fSnK8eWt3g31lq6cuynk8ICqdLZs6GJe2V5SxEll/z8McptzaVTT01d+8Nv
9Da15Kbovl9cllrYMbKCessgeYhr5TbgW0a+y8ATjvDkoxc5cj1HOPxGa+NxO/oD/dbK2mDlLFO9
VnIveeiA+nayAr+34UEL1a5c8gjH8RpBBFGrwXcTkdfwPKeVNenQ/slP2qviCYR51fFqQmwZPL4+
cCum3vV+t9H5oFNce6KXv/fjb7zxBi5M8vlH+DFxH1u93GXW3iloOP5OcHH4gdc9R7R8IbQ/QhOL
EqV5x44bnzyGC2NqteLNzf/O5uVc0vWbl4v7pirIE/TG724v+vsXWfm/4nqLXtz1sYvPZpdPKI1f
dwp3im3iA5o8dj2RuBLXv931J82ftIWJK3H9m1+nJa7ElbgSV+JKXIkrcSWuxJW4ElfiSlyJK3El
rsSVuP63XexfW9LfAL4E60wYAAFy4Guwf/oFrA9gfRXsnH4L60tYffk0/Tem+6EQ6wO0Jq9PvwJ7
ccy7WF/C6sun38aajtnLxuzFMU9je+f0+1hfwmq6zgEmOcAkB5iEFgcX+w31VG5//N+DGiDIWspv
W/t4QcUEDPywijnQJ8fG8NCWHFaxAPnJe1QsQk6yrGINyh9TsRY+Sn5VxUmwMGWdinWwJOUFFSdr
k+N7pcCZ+nkq1kOZ/jwVx3Tm4zrHfru6Rn+Diglo9U+qmAONMRj77XwoMrpVLIDB6FOxCHrjuSrW
oPxiFWvhS8YrVZwEZuNRFevAZkpTcTK/K75XCthNNSrWQ6Zpo4pTyXLTOSo2QH36D+hfHhB0Ks8K
VnhWsMKzghWeFazwrGCFZwUrPCtY4VnBCs8KVnhWsMKzghWeFazwrOBU1RsoVnh2QwjGQYIR8MB2
/ByHCPjxMwrDEEAswSCOGMW2hCNoewz7wzg+gLIoYh/KNrG5dA6d2w1rYTksVueGZ/WMYSuEM8bB
y1YM4MoSbGN7ebGee1+lTcd6IYhzfequURwhsd/dj+DKQfUEHhznU/cKqCt41bX8rK5Eyannpv1B
hspw1gL89GPfpvhOc2k1+qmVPztHM6v72EpDKAtjO4IjwoyNKNZ07bnPruz+ab1aZjFAT6KcJcr2
G2PW8LD1lbP6ULKNnTzE/grC3CdVePacxKmf2TWk1sqpFDyOrTFWS0zbrew0/vg6dGQQR/x9Cw0z
5sagGRx4bWNXJWPUy3wogvcgG0lnjuAY+rcb6AmH2BnHcIXt7P/EoqwbQUy1GcS+cdyfzvQwvzkX
vof710AVXk2IVnxqDwk62Ulj/MUsQ/1oMa4VxM/VKBtiWkdYy8/iiP7VCWqvSlzBwyxOT+xhLCie
Qn3Az2zpY3PoKqOqjQfj/I5CBfZ5mYcooynyzPKdmM0Vjqk9Q7AF0RBDPjXKlLmzrehjc+kZIywW
lNNQPc5j+tAz9rD+mMZb2bm2Mx/eqq5IefSgfqdqo8S7wtuMP9M1uxgPQ0ziYXvG5ijrR5kVlB66
cwBlQba+n2kRG62wHECuFGmYeVqY+Zhiqa0Mb2djo0wfqmN5PO8E2YxhpiM9teIvHpWHuVafzVRM
j0Dce2esoMScwpvC54wOW9QsMBq3YYTp7ZkVS1E2d1SdFdsppMaWMm6E6Rhkp1SY7YtHcMzO1C5j
6jmVnhHm3XSVURa9SoR60Btjo0ZhJlcFVD7oqEjck8Lx54Rf9bhtTOpl5/WzmB5mnHlYNqN9J7M4
jvvRZ8HsjBZhcRyclS82MeyZdeYAY2eTmi1jOdfPZo2oGSTCmBpk2lLL+jCCAsxuQ3GmzopHxKnR
qbCkPAtnR6KXZZbZmTkWO7F4obtuVe1Hc4rEvF/xjvJZfM14TBg1+zRTn46pCPNRmrt8cVYizCpK
3lF8PMw0Hmf2nK35DFvKU0bJgTMe4z8lAykcjMJ8Nmcz4yIKJ/v5qTuMs9lKhEbUp4sXpTM2aZ61
G9VjiOnhYfO3McsqZ5krP/oxU5+88zbmmcPqs0lZZ0jlxc9WUTxgRI2q2VmD8upnsaGM387sH8JV
TuZkqZpzt8ya3YmjlWeoEhOfLZuPq5orfhRkERiLgzH1WRFgc0JsBUV3j2qLmK+Mznr+KDkqyiJ3
JD6D8jSm5tBIPM8pT/AAs8VMhorxpDyRAszGIfX9Q1mdar/tpAzkYdEUi9cR1ZMC8SdUgEWIpD6P
T/Wryjmer81zRGDPrJzTDLHncx2cqeaRGEt1uGIT1J8yv+Kk+XNHt1/1HsUinrhHKiz41UiSWL72
sDOMsLNvgdh7j+dv9lI7fPb3iFPz7VpsBeJP5zXsJNGTnnuOOd68vCw7jKrvj0qOW8HWD82yRY+a
A099UvexrBpiSBmr5M0tLO/817yL0dw28z4296oz/epq35NqqqqapBUBbzgUCQ1Gpc5QeCwU9kQD
odFKaXEwKK0ODA1HI9Jqf8Qf3ur3VXZ6RjaFAx5p2BORNvn9o5LPHwkMjfp90mAoLIVGKyLeMBWH
/R5fYHRI8oz6pGhICoZCW6ShUMgnbRvG3rFwYDSKczxRKTLiwW0igfP8kUqpJ8oW3uoPb5f8W3Fg
ZMzjjS0zFg6hblQ1HNkV8AyFRj1B1oPjowEvNoY9gXAwMOqPMDGqHBhEGPajOkE81FZ/cLsUiYZD
o0PlqEgg6JeGQ+HAeaHRKE6eNVxRiq5B9VSO4B8ZQ91QT7bCFr+EclQtIiFdw/6wFB32oL5ROik0
HsWmfyTiD26lx+obDkTYmb2BMdwTGyOhSFQaDaHWfs8mKhqlE6QA6hHwRihJqAWVBEPb/GGvJ+KX
vMOesMcb9YdVFcc3+cb9VEHcdDsugSpu8lNGcVogjBh3QC79Qf+IfxRNGBqUtoXCvorAiGeIKnUW
NUTMnKjSeEQ1otczxkhm1qF2kUJIMHqKNBZCOsqZXoyYcEVcqbilIsOh8aCPqhIJUt9BxsN+37hX
XZypFfZHxoNRRoxfdSDUYHR+VNo8jt0K57EJ4xFq0IjkC3nH2Uma2bSwf2g86AlL2/x0lxl/9J+r
Tt4WiA5LHgnHDKEu/iglYMRDZdQ1vAH/qBfl20c2hYKqJkvRc7ew7s7t4UAQLTGHm4/j4shRMBSh
NhjDqAhEkC26OtqfsTLK4gc9Kur3jNAO/7k4LhqhPheSPIERP3MoqhMGUiASRR+k3jvq36Y4kCfM
7DqCJAVoQAXG0Krbx2JcVcbjtTluwB7mOc00nuvORB+hKtVVNtWr/RVK/yxz+wPMaz2USFQB/Q2V
Cnt8/hFPeIsUoj2zmoNz54iY364dDdBwXhP1RJXYc9BkwDbwhsZHo+EAetyKEDo8PUUPemAsqPsC
4ZDUh1L0zS2R4Wh0rNnh2LZtW+VIbL9Kb2jEgfNCQ2HP2PB2hzc6iPE6eyhr02Hu0DiaeDt1ZVQL
D0l7aBAg/SOBKFVx03amcPfa5YuZe9EGJhZ0UOp3NCl4h2fNxU+M2uC4TzGZLxAZC+IGSjpCY+Px
qLNGK6XY3qFR9PiywALMF5vopJmlRmOD59SIDWcpE6MDCfMqMRjfnTGtrtXCFCgL4C5RTEtoDHTX
7Rgh20aDIc/sTVFnj5ptw1LcJpifxjBF+fxbMf/QMcP+4NgpB/ospmDEO3z+QQ96aqUnMnau+nPG
6T9/85rpnRCd8/fo6V8I1UEyZIB2ehqUnwrqUVxISoHDtwsg1wIh15FbgSO3kTsRy2QSeHIXuRvx
PeRexPeR/4P4EDmM+H7yfcQPkB8gfpAcQfwQeRjxj8gjiH9MfoL4UfIY4sfJTxH/X/IzxEfJzxH/
J/kF4l+SXyF+gjyJ+NfkKcS/IU8jfoY8i/g58hzi58nziI+RY4hfIC8hfpnbBYS7hLsEeG43txvx
Hm4P4q/w1UD4Gt4JPF/LP4X4N/xbiI8LNwARbhT+DLzwF+EviN8TO4AXO7VfB6K9Uns/8Nrv61Ef
/S/1uJf+WGo3ciOoPwvn4C7kQcbdJ5ENDnm4B/G9yAaHPBxCfBjZ4JCHBxD/ANngkIeHED+MbHDI
w48R/wTZ4JCHxxH/FNngkIejiH+ObHDIwy8R/wrZ4JCHXyN+CtngkIdnED+LbHAqDy+QF7F+CXlQ
GFDOTk9dg7UTz87xz/LPIn6Ofw7x8/zziI/xxxC/wL+A+EX+RcQv8bgC/zL/MuJX+FcQ/5b/LeJX
+VcRv8a/hvh1/nXEv+N/h/gN/g3Ev+d/j/hN/k3Ef+D/gPgtyjByeyOy+l3hu8AJNwk3Ib5ZuBnx
QeEg4v8Q/gPx94TvIb5FuAXxrcKtiG8TbkN8u3A74juEOxDLgoz1pDCJkruEuxDfLaDvCfcI9yC+
VziEex0WDqPkfuF+lHxfQF8SnhGQGeGYgB4ivCC8gPIXhRcRv0T/58PCy8LLiF8RXkH8W+G3iF8V
XkX8mvAa4teF1xH/Tvgd4jeENxD/XvgDrvaW8BZKjgvHUfJH4Y+I/yT8CfHbwtuI3xHeQfwu86j3
hPdQ8r7wPko+ED5A/KHwIeK/Cn9F/JHwEeKPhSkcOS1MAxFBRJ8SiUgQcyKHmBcF9EYsKNGIGpSk
i+mIM8QMxJliJmKzaEacJWYhzhazEeeIOYhzxVzEeWIeYotoQZwv5iMuEAsQF4qFiIvEIsSSKCG2
ilbExWIxYptoQzxPnIe4RCxBXCqWIp4vzkdcJpYhXiAuQLxQXIjYLtoRl4vliCvECsSVYiVih+hA
XCVW4SmqRYxBsUasQYlTdCKuFWsR14l1iOvFesQNYgPiRrERcZPYhLhZbEbcIrYgbhVbES8SFyFu
E9sQt4vtuLJLdKFksbgYJR00fjFyr8T4vUp7FdZ7tXux3q/dj/U12gNYf1v7bayv016H9Xe038H6
Ri16qfYmLfqn9qD2Nqzv0KIvae+nGQBjH2NQ/ys9xqD+Cf0TiJ/UP4n413qMR/1TeoxH/W/0v0H8
tP5pxM/oMTb1z+oxNvXP6TFT6Z/H7MGpWSMZ9nKvAu/dHg5C5lDYvwXq8UV4FJZgD1mzukOCLMzW
0+p/bzKomEAS5mX252tYm/5fu404ku9ZuXIZFK8+Y4UElX2reyX8/kIZweN6JhULkALpKhYxs2eo
WAOpkAlm+v8jhx2svoTVl7H6SlbvZ/W1rP4uffWAW1j9PK2JgdUuVodZzcaQp0a2jGzhklidzup8
Vpf+P/bOPi6qau37a4aZvYdBRMt8S9BMjUqwzMyKsswwXzJRtBIzNPEF3wpRUBENzaaOL4UKimRg
NpqYYSc73bsXrEZTs9GjeR/qiCeHVLIdCNpopq77u/cMBun9PPd5nj+ef57P+nxZe++11rX2Xnut
37WuDZn58w7z533mz75CXPmN1//+Zytyq/lEdu5eZVQMvxXGM4UzVhGMSXOe9HrjqRidVv+/xb/V
wvjXG9qItv9XRzeKXmKUmCKyxBJRKLaIT8Q+cUTo4qKliaWdpaslzjLIMsoyxZJlWWIpZDfxiWUf
HkwXxm/6QozfOIp25n0Lw4Ma+Ud1Zm4JV4x/OcpcCYYPtvTKa3z+cNfG5482bXz+2N7G58MblqOw
yc83Lk8+3fh80qbG9WeNalyeUde4fMGyxuUv9mlcvlQ0Ll9a1Lh8pbtx+aohjcvfvK9x+frdjcvf
2dK4fHOPxuXvb25c/tdejcs/OypCrfXnirCUjRehlgbnng9EaEiD86/HCcu2bw2NUkY32RUuwpXw
TuGx4YPCPwz3NC1gyhVFKOSdIjpAbERyRFrEhoi6Zg81G9/soya7rk60jcVGfepkWvtz+jCQmhZc
K4WLQK/NvohQIgIW/pxiIwIp+UpKM1NdIHFvgfSRkcI7tYqLHBmZHJnKz8zIxVHpUTmRI/np4mcO
x8mRyVGbozxR1VHnI0eGi/Yt29/BzwHUvjplklLrU/vE4JVGCcuBZNi+yoJZ4jL6Nlq3TzVqBZJx
H1elTO7LY95bMHXs0bll59VR57umXuv+jLFrmNoPMFLX1TEjIpNjNsV8EbM75mDMkZhTMWdjLsT2
jTkYOxrGxU6LTY+dE+vp1rTbkG6jqXd1OkLafSUdNK38OZ0NJix3mxjb17B/jXSE/saZfdandCPd
MTbWE0jcQyCNNlLMwTvjzJFYXD+ef4xg5MgeW3vsIG0lHbx/Ue9dvY/0ru59vs8IA+Nq303xe/tP
HHCwPn/8qSfq6hmaOTS3nmHRiYMTNw33Jg4euXLk+0ntkvokDh59/tldSe2SWyT3TB6Vsmt85oS9
k7sa5VPbJrVL2ZWya2ry1LSpWVMLpnqmz5qe9fz7L7ROe3DGoBmjZ0yZkT1jZbp75oGZJ2Y1y1if
sWlq8vRZGVqGNmMQ10gZmzJ2ZJzI/CFjxxxtzr65Hef2yNgx15e1aG7HrFezVs4bn30g++j8I0bp
3I4cH1hw4sUmOV1yeuRMy1mUs56j9Tn7cnyLlixyL/rhpZaLVy/WcqYtPrL4CFf35fRYfOqVs4uW
/GUzdRct2ZCz3ihZOn7RDzn7lollzmWrl3dZfsfy8cunLJ+1fAHHC5Yv5ucS8rzlRaQF5lX3ax9w
ffzy8a8fpJ5Znpucm5brya1bYVvRdEWLFR2h64qeK+JWxK8YsmIXV20rDpC6ruhKne9XjlpZvaoH
NZuuiqcmJavGUbPrqs2k0lWfrdq36uiqqjwlr11ebF5c3oC8xLyxeVPy5uQtyluftyVPy9uddzDv
h7zqvLN5F/JFvpLf5Fpqc0VxGiRTQxrpRf7Qa6eASlxznY+8xsoeaapIg5TfIBmlDc8D6++qNdJo
LeRPu3YKzP/89Ii0qPOx6eaq7pQ/x3iS4LOhz/krIzZwVhS40rQgokP+uoi0/E35Rw3Naz8gXESl
GzTZZZQHx8nQ3CLDjlnjw/rRqx8xQ1PRXlOBDXWnLDiCzcZzhhrTA1aNknw9Ita8GlCahjr9x7sY
dJXGFxnJ0HUjBfU+2C6iA+m/U3bD62wwtf2hgO8xkmmFNoZdQ+eNd7J6lvmWFq/ejUagFGj7+TW3
renRfsCa+DWZ7QcElNms88ebTja1JaDcLsPKmryodLNuQJkbvH1DjY3jNVuicqhxRbXDhdlOW3Og
4MEoT7go2HGlLPUac2pxfpN663/4CUPVArpmnuU0TA3nXdAnNPAKUecD6WpP0P6OgDczEnbOG9ei
cjq3jMpZa/wTgy5jphg28Q0H1w4y5+XumFOFI2PnxFww/ENseuEnhbuCWryJ0oA3MHXeqG1eP3vF
Rxw0/ck4rH1h1r8y47sN4Ww3XiGdMq6/8VTsOPPaF2ba3dBDXEmmnzKS4U0aehTua3TQj1zlSUxf
Nsf0JE0DHs1IXPUY/Zl2aBtzwfAtxpO/kfqG/mZBZPKbpUVRxqhHJhf1KFpXVL4mL3Jkck88QM+A
3hcdRd0HFbdGrzsGdDn7AF7jf5jwEX9KeJpG6eoa+KFGKbmFcR8N09Vt8Er/Zgr4pgytPq8/qz83
nrpRmjJjSsCP/fcJD/fvpB3/84THbJQCb+OPhAd9NfBurpWu9V4M34lvDfjVQJqW08PwrotXcxRI
668cTVtwYsEJw7ea3tZotS+QFv1gJKNtzrTijnhlo/UivKnhaQOpyPS1AT9bxNF40w8XBZNxtsCs
vyCYlpipiBZ5xRMN/4pnDXjeQLJxbnjggPc1Uov6I7x1suF9zfpdgyneTEYrW/E0Whntmga92khT
j9KLl6xvaejg+sCuCyVZvzmgNW+13pC2YcvbLd92vb3X3cQ9wq27L2+0bWxZFLUpblMf1KV602Pv
nIiqbj9gc5PNHd/e23AXG5m8OXPzqwEdCyrX+fYDSrJKFpvKNjJyccmWP/bjUdUlPnRrwJboLbve
7bE1auuG9/q8p5embuu07bNlYvmSnH3mfoVk7CiMtLwLsfF+6ReHZazwSV38Ik9abJAqXZYTUrOc
lIUhiTI3ZLjMdW4S8c53QBPxYROE8Vezh2U5kTbtLBbpo53PMkhE0faQ8RfQtPURye4n9j4svdQ7
zPkv0h+s16JRvbZBK15KPZYIWW65k+NBItqSwPGT8jPL0zASkmAUPAPPUScVCwvghPTakuVntjEw
Fp6DcZACE2ESpMrPiLr3E3Vz57QsF3cTx1vEZDD+4ngqTIPp8DwYfwGcBjMg3XxerzVDfmPNgYXy
G1szYbE1h+vgemgBN0BLaCUs9mcBe3bs2bFnx54de/alsAyK4Rj4oBJ+hOPCoh6X36gn4KT8JvRh
6AOPQF94FOKhHzwG/WEADIRB8Lj8JnCnog1jaox4OWNqjGV3xrGEcSxhHEsYxxLGsYRxLGEkPIxf
IW8imTEsYQxLGMMSxrCEMSxhDEsYwxLGsIQxLGk4E4iFD8tO9FSLlVQsvMJ80ZgvGiP9i3Cab5uZ
JJpQzxOcYzpX/2m+Od4abcppo9NGb2TZFpwTuvGmqOXFRuCJfFzVsPESM+Vwg5niNWfEAlqckLG0
cIvrgy28wRbZtDhECw8t4mnhoYVm2g/MoWyjH2WYGKculyOcJbAF9sMB2auRNWOmurB2Emvl5uga
M7XxjMz9X1oLDVr7uznnjSdI5R2cwOpJmUqr7uYqa0GtcmqV0Kcn2KebPtcG+yykz1LzDQb6bEvr
9EZ9BvsL6yO1sAnS+D1LYDzLLeuEImuFE66DFtBS1olW1Gktj4o25G15Z+3kIXEbZbdDV4iBWLgP
7oc4eACGwwh4Ep6Cp2EkJMEoeAZGw7PwHP2MgxQYDxNgIv1NglSYTP9TYCpMg+nwPLwAaTAD0mEm
9zcLMiATZnOvc2AuZMEi+nLBq/AXWAJLYRksh9cgF1ZCHm8jH1bLUrEG1sKnXP8MdsAu+Ap2w174
GvbBN+CFA/B3OAiH4Fs4zBw8Rs76EJXwE5yCn+lHh2qogdNQC3VwBs7Cr+CHc3Cee/kNLsDvcJFr
l8gvk0veewjrzw5tmA9tmYM3MifaQZQ5Nwotk2EKTKVsGkyH5+EFSIMZkA4zYRZk0C4TZsMcmAtZ
MA+y4U36KoJiWA9vwQZ4G9ywETbBO7AZSoC1YKlm1tVAHZyR5dYQsIMKrdCBe+E+6G1qgg9N8Nma
yaO25nAdXA8t4AZoCa2gtTxkawNt4Q5Za3uQNr3hIXgY+sAj0BfiZamtH/ljMAWPwXjYGA8b42Fj
PGyMh43xsDEetnTqzoRZkMn5bNrMkYW2l+mDOWXvB4PgCRgivXbmvp25bx/F8TPwrDxqT5aH7FO5
xhy2M4ftzGE7c9jOHLbP4noGzIY5kA2vAHPVvpTyZZDHcT6shjVQgL1C8nXYL6ac8bZv5NoW8o+A
eWjfD8xFO3PRXi7r7N/B9/BPOAIVtD0K/4If4Bh2fFAJP8JxQJftvC97lfTYfwKdPi5g73e4KGsV
KzDnFBuoEAph0qeEy1Lleo7REqU1522gLdwI7eBmrt8C6IlyN+c9oRfHvCPlEfK+8CjHCeRDsYV2
KGiHgnYok2AKMJ7KNJgOz8MLkAbpMBMYV4VxVTKBsVUYW2UuZME8YJyV+bAAXoTFwDtVeKcK46+g
E8rr3EMurICVsArQBwV9UFbDGijg/tAIpRDegCJgDShvU+bmeCM5819h/ivvcryV/D3YRtkH5F+S
f4V/2C8LlQNwkONDXDtG7oNK+BGOS68qAJ+jMr5qc1motiVPJB8OI+BJeIryp2EkJAHzUH2GeqPh
WUgGfIU6kbqTyFOBsVJfl7XO5rBc+pw8o5P55mS+OVnfTg/nO2EXfAVonxPtctbIUudpWRp2n/SF
4QPCWFth/YG1EMa7CxsGiYBPCGNdhLEuwvAJYUm0mYhevSxscqewsxtQwQGhEAZNoClEQDNoDtfD
DdASWslsvJMf7/Q53skrbpSr8VBpIlJ+LKKw2R46wE3QEW6GTtAZusAtEC0Lxa3QDXt34GHvJO8O
d0EPuBt6wj3QC+6FB6E3PAQPQx94BPrCoxAP/eAx6A8DYRA8DoNhCCTAUBgG7HhEMoyBsfAcjIMU
GA8TYCLPOglSYTLPPAWmwjSYDs/DC5AGMyAdUHA8oheP6MUjevGIaXjENDxiGh4xTcxjnLJhPrBT
Ei/y/Dnkq0W0WANrYSM7jk0Q2Clr4jzXfoML8DtchEtwGST7FkV+iOfR8To6Xke3RLIbieItd5Db
LTdR1pH8ZugEnaEL3ALRcCvlt7Hvuh1SaTsZpkAGZMJsmANzsZcF8yAbjsl0y49wHPCieBUfXsWH
V/FZ/Fw7J9PxJhreRAv5Re4MqYYaOA21UAdn4Cz8Cn44B+fhN3ajF+B3uAiX4DJIqdsEsCe1WaGZ
9OOZ/HgmP57Jj2fy45n8eCY/nsmPZ0rDM6XhmdJs8SLa1g8eg/7yQ9sAud02EAbB4zAYnoAhkABD
YRgkQjqeZybMgkyZjRfSbS8C7822UOp25qCdOWh/TLTAE31uZ57ZmWd25pmdeWZ/GkbJbLxSNl7J
j1dKs4+RH9uZa3bmmp25Zp8Ik4B3YJ8sd9p5B3gtP17Lj9fy47X8eC2/fQZl6TBTFtp5P/YsmAfz
gflk557sCylfBC9xvBheBhf8BZbAUuwsg9c4fh1WcC8rqb+K4wLubS3H67jXIs6Lqbee87c43kjZ
Jo7f4XgzlMC7sBXeg1LYBu/DX+ED2A4fwt/gP0CDj+ET+BQ+gzLYAZ/DF/AleGAn7IKvYDfsgb3w
NeyDb+AgHIJv4TD8J/wDyuE7+B7+CUeggmc6Cv+CH+AYz+aDSvgRjsMJ3t9JqML7/gSn5Gr7z6Dz
7L8wTtVQA2ewdxZ+Bb/8WAkX0UofGAoFwDpWCuENKAI3bIRtwPPhdXS8jo7H8Sncp8I9KhVwVH6o
nICTUCWzldNcoy/Fz/k5+aGqQrj0qU3J0Wb1BnI8vNqenLmGR9LxSDoeScf76HgfHe+j4310dYz0
qGPhOeoz3/BCOl7Ip06WHzprRLTztIgOS0JTjPg1V1j5OYiop5ZI8rAZxRpxnW6eFRrXuUIEIg6L
aRydtVSJzZafxWYrMXxID+gJ94jNIYkwHGbAPHiR6zmwEF6Gd2AzlFC2hfxd2Atfwz74hute8v1w
AP4OB+GQmGZ/U2QqishT7hPxxFwXlESOnxLd1YUijvjL61xBLLtSZDpXiXFO9mzON6EEtsA28YHz
fZHn/Kvo7vwYysRu5w7O91B3L+ynzgH5D2c1ZWc4P4uaG8/u4tlPms9ujNMI4TC/wwS+rJQzQp6r
vtQoDVtR2p3S7pR2F05K/MEY3ae+wo7hVXp9G9ywCd6RXqLGVPNtaNioM7/kEJeLFrSrM/47duOJ
lRIsbg72Vc6zS55T8pyS55A8hwyUcJ+1WDlD28PGvXJ/0aZt4/36hL1BhO+lPJlRzRTvCxee6C+w
BJbDa5ALKyFPRIl8nmS1iMODxYkCrq0lZ/+FF/OJMs53wOfwBXwJHtgJu+Ar2A174Gv4OxyEQ/Ct
6QF1ccyIw6ESfoJT8DP96vALx9X0XwOngYha1MEZOAu/gh/OwXnu6ze4AL/DRbgEl0GKOEsIo/om
FEExrIe3YAO8DW7YCJvgHdgMJaKFrRuwk7E9KJy23vAQPAx94BHoC/EiDg8UhweKs80WUbaXqc+4
KvSpqBAmolCROKUFxy2htXAqbaAt3Ajt4Bau3wb0p9Cfchf0gLsp6wl9aN+X80exlUA+lPNJ5C9A
GsyAuZAF8yAb5sMCYCeiLAbuSzHu6xV4FXjvyuvYy4UVsBJW0Zfx/7nivSurYQ0U0BfvHdWLQ/Xi
lHW0YyxRvzjlbdq4yTcC46Ywbsq7XNvG+Qeihfq6aOFcLpxObDrzOV4NvAOnR0Q5d8Iu+AqYJ86f
qVMj4lCruLD7hDOsr4gK6w88b9hwGAFPwlOQRJ1R5Ckwkff/kfk1ov5LxNVfIGpFvqwSq9lzrYEC
WqwlLwt+gfgcvoAvwQM7//RVYk/wq8Sfv0Jc+wtErdAB3RDV9FkDp6EW6uAMnIVfwQ/n4Dz38htc
gN/hIlyCyyBRB+MrxP/Jl4Fj4hbLj3Ac/HAOfmNmXxIt6r8I2LoRdQei+yqi+yqi+yqi+yqi+yqi
+yqi+yqie43oXiO614jWa+sjdTNSVc0ItZYIVTOj05ZmhFpFhFpFhFpFhFpFhFp1JTqlP4X+lLug
hxmtVhGtVhGpasEotTYYpWpmZFofhc74N6PNV69EnLVEnLVEnLVEnLVEnFVEnFVEnFVEnFVEnFVE
nBoRp0bEqRFxasxwJzPcSeSpEXXWEnVqRJ1ag6jTiDY1I9o0o7zlsooIr+pPEV4tEV4tEV4tEV5t
MMKrIsLTiPA0IrwqortaortAZHd1RKcxw51hKRxPZI50MD1K0Nf8v/DJlg/EQukSi0SEeIl8MbwM
7D/FK+Svcp19KOtPF0s5XgbLpZt16BavU55LvoJ8Jfkq4q48vG4+5/VfBQvYmRhfBgtllniD6+vg
TSiCYlgPb8EGeBvc8A5shhLYAu/CVngPSmEbvA9/hQ9gO3wIf4OP4D9Ag4/hE/iUe/4MykQ8uqDj
2eLxbPF4tng8WzyeLR5d0NEFN7qg49nixV7qf835PvJvwAsH4O9cOwiH4Fv4T+z/A8rhO/ge/glH
oAKOwr/gBzhGfR9rv5L8R8bqOGN1Ak5yzN4RrdHRGh2t8aI1XrTGg9aUojUutKYUrSlFa0rRmlK0
phStKUVrXGiN6xpfPPXgF08drdEtQmYxywotVvIQ6Ta/jNtFBPqjoz86+qOjPzr6o6M/Ovqjoz86
+qOjPzr6o6M/OvqjE0sWWnzY4DmIKQuJKQvN3wVUE9vWiO6WOvIz5H6un4PzxJfooOUiOfpntcpc
qw0UaCWiQ3oT490oXbZ2EAlR0B46wE3QEW6GTtAZusAtEA23wm1wO3SFGIiFbiIe/dNtd3LcHe6C
HnA39IR7oBfcC/fB/RAHD8CD0FuWopkuNNOFZpaimaVoZmnwi6iOZupophfN1G1GrHZBRNh/h4tw
Sbrsl0FKl2IVEeipW7GRq+QOroVyHCa95te/pjJLuY5r13OtBeU3cNyS3XEr8tbQhjpt4UZoB4yN
wtgojI3C2CiMjXIzbRkbhbFBj3WFcVEYF3TZrTAuCuOiMC4K48JOJJ6dSLzCuCiMCzuSeHYk8eh1
KXpdqvTCFmOi3M99MR4K46EwHkpvYDwUxgNN15VHqNcX+4/yHP249hj0hwHEQANp+zjHQyCBOsaX
SfalykjOk2g3Cp6B0Zw/C8kwBsbCczAOUmA8TICJQOyjTCafQrupMA2mw/PwAmVp9DOD50jnfCbM
ggzIhNkwB+ZSJwvmQTbMhwXwIuRgGx1UFgE6iN9x43fc+B03fsfNzioev+NWlvB8S2EZz03EorzG
8evkubACVsIq2ucBOogvKsUXlV719XOdzFXeBOMraDHjtR7egg3cJ/FE8IuormzCBmsP/6QraCE+
yqtspc57UEr9wNdRt8rzqpnSpc6GOTAPsgE9x5e5nc1FhJPnc/JsTq45X4UlsBSWA/eLn3Pj59zO
Ao7XQiEUcb5BZju3yizne4C+Oj+Fz+Bz+AK+BA+xz07YBV8BOuo8xHX0D//oqv8C6qyVWfhIV9j9
IiKM+RX2iMzGX3rxl96wJ7jGnMFv6mFDyYdxngjDpRsf6saHuvGhbvOr6CiZG/YMtpg/YcyfMOYP
u8Z4fKpLhLFDimaHFM0OKdpyAvxwDn5DlS6J7lariLbaQCGa6oavqsBXVeCrjuOrKvBVxm+QKtDT
CvS0Aj2tCP4GqeLKb5CEGXP50FPjtyQV9b8lYU1XsKZ9rB+f+ZV+IAzlWgFgm/dfwfuv4P0f5/0f
5/1X8P59vH8f79/4El5hfgkvhW2ygnH3Me7GF+QKxq+C8fPx/BU8/3Ge34ixCtiRFpp/k+Diroy9
hJ+78nMXfu7Czx346c1Pb3568tOTn5789ODHuh/rfqz6sejHol8olgh5yjIIUtH0E1ILSZSukOGM
q8X44mj+PtT4snDSPDpkWcBRSPC3uH7z33KzBn+nrJstysR1lieJXp+GkZAEo+AZM6J1s7eJZm8T
bUuWh21jYCw8B+MgBSbCJEiVh81707k343fcfYzfhtf/tQU9LZDV5h1VmPdg9Hyan8TMZv86/ev0
r9O/Tv86/Rv36KH/KPqPon+d/nX61+lfp3+d/nX61+lftxnPbliqwVINlmqwVIOlGizVBO7liqUa
LNVgqQZLNViqwVINlmqwVIOlGtEMS5VYqsRSJZYqsVSJpUrjLwuwUImFSixUYqESC5VYqMRCJRYq
sVDJmDcYPfPJza8S4kGLg6Mm0AJaQleIgVjoBndAHDwAD0JveBKegqdhJCTBKGCOWUbDs5AMY5jn
HHOHPptxPBaeg3GQAuNhAkyEScBd2SYzlzUogy9gD+yFH+AnOAU6/ALMb4W1plySPjUUnBAGPI8a
Aa3hZuA51EchHlh7KmtP9LQozMdI+ZOlvayzdOD4JugIN0Mn6Axd4BaIhlsBL2m5HebThqjD8iL5
MZ70Rzhufh33sYvx2frLQ7YBMBAGweMwGJ6AIZAAQ2EYJMpDyreyTjlKfgJOQhXew09+Th5SFVmn
quRN4QZoD2PkT+pYGEdZCoyHyVxPk3XiCE/mtajM2FBwQhiEQ1NoBs3hOrgeboBW0BrYP1ja8lQ3
ynJLO2xEmr/l1hihckbIywh5GSEvI+RlhLyMkJcR8jJCXkbIywh5GaFCRqjQ0gN798H98DA8AgNg
IDwOg+EJGAJDYRiMAFaUhdVkYTVZxsMEYFVZJpnruNQyGabANO5zJsyCDPrNBPZYljkwl3vOgnmQ
DfPNv0Ep522VW3Kws8jcl3p4ax7emsdSTZsa8jryM+R+OCc91las+HtlITFyYUhv6eGtenmrXt6q
l7fq5a16eate3qqXt+rlrXp5q17eqpe36rUNRwlGwxRiZe7XNh2IYW3pxNAzYRbMYY/I/dhegsX4
7b/Bl7JcIcZQiBmV/fjsA3CQ40PEm99SVk7Z93DE/KbsVY5R5oNK+BGOAxqjGH8hUyULlRrq1cGv
5rdmL7PKq/wmdVUQu1rAxrEiy5llXtXBMXE8s82rNpelzDiv2pJrbbnWnuMOHN8EHaETdIYuwF5S
jYbboSvEAntq9U64C5gP6t3QC+4F5obK3FDj4AF4EHrDQ8B8Udk3qswZtS/0B+aOytxR0XOV+aMy
f1Tmj8r8UdkDqMwhlTmkJnLPw2EEPAnE0erTMBKSYBQ8w7OOhmd5nmQYQ72x5m9wNVZUOSuqnBVV
rjL31Ilcn0SdVMomk0/n2vPAPpLVVq7OROlt1hViovUt+br1I2G1eoSVKw9xNBiGwgjjv3YXNnxO
SzxMKxkr2hDVtZUfiRvlGtFO9hGRRHBRlLeHDnATdISboRN0hi5wC0QTFd4Kz2FrHKTAeJgAE7E9
CVJhJvZnQQZkwmz6mQNzIQvm0Wc2zIcCZryCdrWRucHV72P1F7L6Pax+ndXvYfX7WP0eVr+H1e9h
9XtY/R5Wv4fV72H1+1j9Gqvf+KuvXFZqLis1l9XpY3X6WJ0+VqeP1elhdXpYnR5Wp4fVqZt7gBel
bm0nq62MgfUmud/K81pjZYz1Tllg7cFxg9G0jpPHrBMAVbBOI5/F2M+WhdYsjpdTt5h2G+RW6zvk
2+Cv8jvrp+Tlcqf1ojwW0pSdSnNW9W3mbzCrQ6qhBk5DLdTBGTgLv4IfzsF5WW1rLfvY2kBb6I/W
D0AZBsIgeBwGwxMwBBJgKAyDREiHmTALMmUsqz/XPkS67aNkrP0ZSJZ97GOk1z5ZVttnQDqgFPaF
5IuAqMG+kryAemvJ19FmPflGzjeRl0uP/Tv4Hv4JR6CCOkfhX/ADsBOwn4Qq+ZH9Jzgl19h/Bh0b
v2AfNbTXgKEU66SHvaDHVKT9RCAH4BDn35rK40NlfKiMD5XRUBYfyuJDSXSUxIeKeFARHyqSi4r4
UBAPCuJjheayQnNZobms0NwGq9HHavSxGgtZjYWsRg+rUWc16qxGYyXmshJ9rEQPK9HH6tPVGtqd
lgvVWjlbrZNl6hnOz8oE9VfZS/XL6eo5zs+zcn+T1eoF+B0uygr1ksxWL1Mu5R6HkBUOi0xwWGUv
R4hMd7BOHXZZ7lDkQocqZzscsswRyrmTOmHUaSKnO8KhKUTIVEcz6jSXFsd1UnFcz7UWMtlxA3lL
aEV5a9q1oU5b6txInXayrSOSsijqdSC/SaY4Osokx82yn6MTfXa+fM7RBW6h3q2U3wa3Y6crdmKw
E4udbti5g/I7KesOd1Heg/Z3U96T8nso70X5vZTdRz8PSM3xIM/Wm/OHZInjYXmro4+8wfEIz9ZX
5joepV087frR7rHLlY7+l99wDOCeBl7+zjFYFjueoN0Q7jNBZjuIthzDaJtI/eEy1jGC8idp/zT5
SOol0W4Uz/EMdkdT71nqJVNvLOXPUT4OOymUE7E7JlA+kXI0y1Epjzl+hONwAk5CFfwEp+Bn0OEX
qIYaOA21UAdn4Cz8Cn44B+fhN7gAvwNr33EJLoOUx0IFWID1FjpFVoROldmh0+T00OlyT+jznL8g
E0LTZK/QGTI9lLUYOlOWh86SC0Mz5OzQTFkWOpvzOdSZS50s2mXDfJkSukAmhb4o+4XmUHfh5XOh
i+Al2Tb0Zcpd8IpMDX2Vdn/BzhJpCV0qldBllL8mi0NfpzyX9itou1Lmhq6SN4TmUSdfxoauobyA
8rX0UUj5G9IVuo7yNynfIWNCd8EeuTV0L3k59/sdVHNeA+dkjDNc7nR2h7tgsNScCbLQmSyPOcfA
LI4zYL7x1RldbobH0vBW7uBfqxp/D5SKt3LhrcrxVhreSsNbaXgrDW+l4a00vJWGt9LwVhreSsNb
5eKtcs2/BZqIrUmQClf/LY0L7+TCO7nwTi68UzneqRzvVG78HQ2eQcMzaHiGf+AZNDyDG8+QimfQ
UHwNxXej+PNRfDeK70bt3Si7hrJrKLuGsmsou4ayayi7hrJrKLuGsmsou4ayayi7C2V3oewu1Nkd
/JsPL+rsRp3dqLMLdS5HnTXUWUOdNdQ5F3XWUGcNdS5HnTXU2YU6a6izG3XWUGcX6qyhxG6U2I0S
u1Fid4O/BKz/e4RUlDgVJXahxOUocTlKXI4Sl6N0XpTOg9LtQem2o3QelC4FpUtC6ZJQOi9KV4LS
aSidhtJpKJ0XpdNQujKUbjtK50HpUlC6BJQuCaXTUDovSudB6fagdNtROg9Kl4LSJaF0SShdCUq3
B6XzoHQulC4JpUtA6bajdNNRuhKUbg9K50HpFqJ0LpQuCaVLQOk6oXTbUbrpKF0xSleG0mko3WyU
zuXoTJ0uqNYt1LsVO7dh53bsdMVODOWx2OlGnTsov5Py7pTfRXkPyu9GiXpSfg/lAaXbjtKloHSH
UDovSrcHpduO0iWjdCNQukMoXTFK50LpElC6ZMdj8gGUrgql2+4YiCIO5v6eoN0QclYGSleM0iWh
dAkoXS+Urgylc6F021G6MpROQ+nyUbpilC4BpeuH0vVC6cpQuj0oXRlKl4/SFaN0SShdAkrXC7XR
UBsvaqOhNmWozXbUxoPapKA2CahNEmqjoTZe1MaD2uxBbbajNh7UJgW1SUJtklCbYtSmDLXRUJvZ
qI0rdCHtF6E8L8lOqE0JarMHtfGgNgtRGxdqk4TaJKA2nVCb7ahNGWqjoTb5qE0xapOA2vRDbXqh
NmWozR7Upgy1yUdtilGbJNQmAbVxozZu1GY+auNGbTTURkNt5qM281Ebt7AH9mzsvYw92ymRaNVF
Invj/o33xmbZPMrmiXxrLLVWyETrW1w1dtMnZWWIkDNCmglrSEuRqAwTeWqNuEc9LYaotWK4ekY8
rJ4VA9Vf/4u6uw+Pq67zPj45hWYmTaHKQ1XQsSLQUlpo2hjERmyAAE0RqgNCo7VKKyE8hIcUKNAG
iG7RtWqKWh/iQ3V3XNtbd5SCGF3rKhHrSo8QKhkxSjvAwFICYggPlpx9nZMp1L29r93L697b6/7j
ff3OnHMymTm/9+/z/f3OTFNtPE6eS82vfj41q3qPc15yzljqnHQqtSBdlWpJB9oJKvn+qYb0xNTZ
6WrHMvbVODZJW+vY5NT89AH2H+j4FPtehVfbd1CqOX1walb6ENuHOj7V8dc69jocZt/hfvb1znmD
c97o8TTnvMk5b7Z9pHOO8juPds4Mj49xbKZjs+yfjePsO96xOdo6x+Y6Vm//W9Bg3wmOvdVzn+i5
G+17u3NOwjtsL7C/SXuy93BKqi59qu1mP3Oa/ac7/ww/u9CxltQR6Xc6dpafO9vjd9l+N3LOPcc5
5zr/Pc4/3+tc4pxW57zPsaXOeb99y5zzQe0Fji137EP2X4g251ykCl6Sashcmjo7c1nqnMzlqQWZ
K1ItmSu1Vzm20rGrHbvGsVX2XefY9dobHFuTmp/psv9Gx2+23W3/h53/EcfWenyLYx917O/t/zjW
2fcJxz7lnB7H1nuuT9v3Gcc+a98Gxz6v/YJjX3TsS/Z/GV9JzU99mlkzK1b1smrpPkbVMaqZUS0V
o5oZNZ9RA4xqqBhVx6hmRrUwqoFRCxjVwKgyo+oY1cyolopRzYyaz6gBRtUxqoVRzYxqqBjVwKj5
jJrOqDpGtTCqmVENFaMaGLWbUfMZNZ1RdYxqYVQzoxoYNZ9RdYzaxag6RrUwqplRDRWjGhi1m1F1
jGphVDOjGipGNTBqN6PmM2o6oxoY1cKoFkbNZ9QCRs1n1AJGzWJUA6MaGLWAUdMZVWbUAka9llEN
jGphVDOjGhg1n1ENjCozaj6jpjOqjlEtjGpmVAOjGhhVx6hdjKpjVAujmhnVwKj5jGpgVJlRdYxq
ZlQLoxoYtYBRDYwqM6qOUc2MaqkY1cyo+YwaYFQdo1oY1cyoBkbNZ1Qdo3Yxqo5RLYxqZlRDxagG
Ru1mVB2jWhjVzKgGRjUwqo5RuxhVx6gWRjUzqoFR8xnVkLolmMam2Vaet47n1YRUaiargqRej9fp
7ep0tzrdyaZllTpdUJcH1OVBdXlQTV6lJrczqTupx+N1eLs63K0Od7JomToc198O9bdT/W1Xf7er
v63qb1x3N6q7Hepup7rbzpxJ6u52dbdV3e1Td4fU3UF1d4O6u0LdbVd3l7GnSt2N6+1G9bZDve1U
b9uZM0m9jevsRnW2Q53tVGfbWTNJnd2uzraqs3F97VRfV6mvHZX6ukx97VBf29XXVeprK1smqa8D
6utp6us2dTWvrq5RVzvV1XamHKKublNXl6mrferqoLo6UKmra9TVdnW1lS2HqKt3qacb1dM16mmn
etrOlEPU0QF1dFAdHVRDV6mh7SzpTurneN3crm52q5udDFmmbvapm0Pq5qC6uUHdXKFutquby1hS
pW7G9XKjetmhXnaql+0MmaRe9qmXg+rlQKVerlEv29XLVpYcol7epU5uVCfXqJOd6mR76htV7VFf
fH8jmbmO38/oS+5bXK1dFYUVWwpmd+1md62s6WVNnjWNrMmyppE1BdasM6PrY04nc1qZkzejK7Cn
kT0z2HMaewpmc+1mc60s6mVRnkWNLMqyqJFFi83mGs3mTmDTovSrrO9ejYPsPziay6bFZnONZnMn
sGoGqxalX+f4YTjcuvD1jr/BeW/UTtO+ybrtCOe92XlHOucoHO28GY4f43lmep5jHZ/l+GzHjsPx
js/xWuscn+v4PMfrPX6LYw04wfG3enyi/Y1GwNujJrO5Rra1phdYFzc5fjIDTvGcp6LZz5w2Flq3
fsdsrottM6xbf8C2brO5xWZzJ7BuBeuWpd89tiedG3syfY72XMff4/j52iV+X6v3816/432u31LH
3+/3LNN+0PELnLfc86xw/EOe50L72zzPRWN7zOT6GNjJwFYG5s3kCixsZOEMFp7GwoJZXLtZXCsb
e9mYZ2MjG7NsbGTjYjbOZeNsNs5g4yJrxqI1YzHzkbESGxebxTWaxZ3AyhmsXJT5uGPr8AnHP8Xs
Hr9nvee41e/4tN/1Ga/rs45t0H7e8S94ji/6+V7Hv8TyL9v/lbEnU0tYOcrIkIFl5g0xr8y6Xaxb
w7oy625nWplpu5hWZtoQ01YxrcywIYaV2bWLXWsYNSSbBpm0mT2D7BmSR4PyaBVrNjNlF1MG5c+Q
/BmQP53sGGTHkNwZlDur2DDIhiF5MyhvVrFgs57fJWOG9PjtenxIvgzKlm2yZZVc2aB3h/TukDwZ
lCer9OpmPTmkJwflx5D8GJAfHXpvUO8NyY1BubFKb5X11i69VdZbQ3prld4q66UhvVTWQ7v00Bq9
skuvDMqIIRkxICM69cSgnhiSDYOyYZUrP+TKD8qDIXkwIA86XO1BV3tIDgymNrrS/cZ/j6vd42pv
Nd43G+8bXfW8q77ZeF/myp9bGe9bK+N9q/G+0XjvrYz3zXphmV5YpBca9cJW432z8b5Rb+T1xmbj
fZkeObcy3tcb7xuN995K9WjUQ3ON9/V6abHxvt5432i89+qx9koVadRrc/XaRON9vZ5bbLx3G+8b
jPcNenGZXuzQi3P14my9ONF4X2+8bzTee/Voe6WaNOrVuXp1ovHebbxvNN579fCySlVp1Mtz9fJE
4329nl5svN9uvOeN9416vVt1OU3PNxrvfXq/o1Jd5qouTQzIGu/3G+/rWDDJeM8b7xuN99iIbkZ0
qzKNrJjLiqzxvpkZKyr3qTYY7+tZsoYl3SxpZMkMlkwx3jcb7xuN9w2MWcOYbtWmkTVzWZM13rca
7xuN997KeN/MoGUMWsSgRgZtNd43G+8bmZRn0mbjfRmbzq2M927jfYPxvoFZy5jVway5zJrNrInG
+3rjfaPx3suy9koVamTaXKZNrNwj2mC8r2fdGtZ1s66RdTNYN8V432y8bzTeNzBwDQO7VaNGFs5N
5ZN/sTpeje5lYxMb+yvVqFc1KiQ58DTz/mDO8ow5SpwHI6rNs1HTPpmwnZllZnYzcxUzB5hZZmYr
M5uYuSbJh4l6ptrVSzse50SN45Mcj7NisrF/gLF6oHaK816lB19tPnKQfQfbdwgOtT1VO34HdR0z
JzGzqnJfIc6UTmZ2MrODmSuYuZiZ65hZxcwqZs5mZiczVzGzs3IHdR0zJzGzqnJfoZOZq5jZyczF
zOxm5iRmVjHzzcyMM6g9me+83fZJeAcbF7ChiVUn238K8071vON3UKeoRE8y8xvMXKESlSpmdjKz
o2JmLzOzzJzEzLkVM7uZuZmZ7cxcwcxbmNlbuYM6iZlzK2Z2MjPOsluY2cvMLDMnMXMuM8vM7GZm
nG0DzCwzs5WZTcxck2Tb1dE6ZnYzcyDJuOscv97xOOfWyLUutt1oPnSTinGzc7vNhz6Mj7BzreO3
eO6PJvkX371cx8xJzKyq3E/YzMx2Zq5g5i3M7K3cvZzEzLkVMzuZGWfjLczsZWaWmZOSfIznR2sZ
ubZyX38bCwcq9/XjWXQHC1dUZtGDySx6j/Ylx8ecG8nCVDKb7mBhKws7Kvfxt7FwoHIfP55Vd7Bw
RWVWXWDhAAu3s3A9C1ewsLVyd2sVCwssHGDhdhauY+F6Fq5gYSsLZ1fubq1i4WYWbmPhXSzsZuF6
FraycHHFwgILB1i4nYXrWLiehStY2MrC2SwssHCAhdtZuI6Ft7BwBQtbWZit3N3qYOEgCwdZOMDC
rSxsZ+EyFsbVcTML17OwlYXt8vE0Fj5Zubs1N5l9n+Xnzn55Fr6ZhStY2MrCRZVZ+AYWbmXhNhZu
ZeFGFm5mYSsLF7FwEQu3sXCAhdsqs/HNLFzBwlYWLmLhIAu3snAbC7eyMJ6Vd7CwlYUdlXvo21g4
ULmHHs/OO1i4ojI738zCbSy8i4XdLFzPwlYWLq5YWGDhAAu3s3AdC9ezcAULW1k4m4VbWbiNhVtZ
uJGFm1nYysJFLFzEwm0sHGDhtspsfTMLV7CwNf7OUKou/usP1nLdE45MLan+aOrjNf+UWp46cp8j
yx2Rjqk6Lo5WR9awE6LRdFpbq32N9nDtEcn6fDR9rPZ47TztCdozsNj2Odr3Juvg0fQK7UXRaKbD
OvMq7bXaG7Q3paZ7z6OZj3n8Ce2tyXp0NNOr/Wo0mjojODxaGmRxFOZhOS7EZbgBn0R8x+OnUTHo
x89xL+7HA3gUj+FxPBsVq1+Illa/iD9FS9P7oYSH8QgeRRmP4XH8O57AbjyJYTyFp/EHPIM/YgTP
YhTP4Xn4PWm/Jx3/nj14CWOIoqWZFKpwMToxiGK0tCYdFWsyyOJoTMcMzEM9ToyKtS/gRfwJezAW
FVOH7v17O1WPp06qeiIqBLOSVfuy4Hjbc2zXRVcF74jywamuQnx3skX7Lo/Pdfw9KuRK+66WTdfa
v8r2dfG3qaKe1BlVO1NB1cN4BKN4ztFp0TOefWdwnBXenOhxzz4cvM32uX56eTSif0b0z0hwtXOv
8eyr1N/rbN9g380ed0f91T+20vsJHrH9KMpRf3qRunMmStGIPhnRJyP6ZESfjOiTEX0yok9G9MmI
PhnRJyP6ZESfjOiTEX0yok9G9MmIPhnRJyP6ZESfjOiTEX0yok9G9MmIPhnRJyP6ZESfjOiTEX0y
klkQ9WeacDJOwaloxmk4HWdgIVqwCGdG/VVzqnaO9VXF3/UrxVfL9iN4zPYTeCqVq/ojRu17Ds9H
a6tesH+P9iVXZWpqKcsXsnxh8r2AI1yho2wfk8yni8Fxqan6sTeYa3ue/W/zuDGaqT9XBwv0YVOU
C07Rd6fhdP25UOtKBmfa/07nnBVNC86O6oPFRsq78G7Hc/adq30PL86LaoPzPd8S57fa9168z+ta
ivfbt8zjD+CDuMC5yz3XhbjI67nYa7zM9pXaqz2+xs9c6zmvd+4N9t9k/832dePD0doJJ6WWVv9Q
b/8oNiA1tfonuC/KVd+Ph+zbiRLYVv0oynghWmjELjRiFxqxC9OLUlPTZ+K8qJj+ANqjmemLcQku
xWXowOW4AlfiKnRiJa7GNbgWq3AdrscNWI016MKNuAk3ozvKpT+Mj+DvsBa3qGkf1X4Mfx+tTX8c
6/AJfBKfQg/W41Z8Gp/BZ7EBn8Pn8QV8Eb34Er6Mr+Cr2Iiv4eupIP0Pqeb0P2rz+EZqevqfUpel
v2l7U+rs9Gb8L9vfcu63tf+cWp4uaL8jd7/r9d2GLbgdd+B7uBPfR180Lf0D/NDP/gt+hK34Mf4V
P8FPcRf68TPcjZ9jG36Bf8Mvo9r0PdiOEL/CvbgPA7gfO/BrPIBBFPEbPIjfYgi/w+/xEHZiF0pR
vUSolwj1EqFeItRLhHqJUC8R6iVCvUSolwj1EqFeItRLhHqJUC8R6iVCvUSolwj1EqFeItRLhHqJ
UC8R6iVCvUSolwj1EqFeItRLhHqJUJ+ZpRYdp04dj3mp+ZkGo/4EvBUn4m2Yj0a8HQtSQaYJJ+MU
nIpmnIbTIX8zC9GCRTgT74zWZs7C2ViMd8E4zeRwDozVzHtwHs7HEhirGWM18z4sxfthrGaM1Yyx
mrkAy7ECH8KFaMNFaMfF0ULVZ2Hmk1Ex8zlVpFoV2amK7JRCT0ueMKkcV0cDcUVIxX8b6gG5NVNm
zZRRw/JpOJjtjLie7M2Lq6MHjO9h43u44mywj7MBZ4OKswFng8TZcV+Diq9BKpPUl1nJt6N+qL4M
Jb/hIiRVCvHreVJlWv1K5tp+BJW/RKZSrVapVsvavqoXo56qP3lne2yP2Y68w0BOTohWBvtp99dO
1FZr47vdR0R3eG93qKH1XsFokr1zbMdVrtFVeYfHC7SneqxPg9OTazAz0Kcyd4usLcragqztkbUl
WRsmNVZeydkweG9yvaa5XtPk6xb5WpKvJflakq/FYEVqRtCG+B23ay+ONgWXaC9FBy7HlfZdpe3E
eO3Oy918pXb3Bqvt78KNuCnaVP2W1Az9cod+uUPebpG3W+TtJnm7Sd5uqn7M8ScwnJohT0N5GsrT
UJ6G8jSUp6E8DeVpKE9DeRrK01CehvI0lKehPA3laShPQ3kaytNQnobyNJSnoTwN5WkoT8P01/T1
11PT+DGNH9P4MY0f0/gxjR/T+DGNH9P4MS39rcSRaRyZxpFpHJkm07bItC0ybYtM2yLTtsi0LTJt
i0zbIstKsqwky0qyrCTLSrKsJMtKsqwky0qyrCTLSrKsJMtKsqwky0qyrCTLirKsKMuKsqwoy4qy
rCjLirKsKMuKsqwoy4qyrCjLirKsKMuKsqwoy4qyrCjLirKsKMuKsqwoy4qZIDUjMwH7YX9MRDXS
yKAGk1CLyTgAB2IKXoVX4yAcjENwKKbiNXgtXofDcDhejzcgizdiGt6EI/BmHImjcDSmYwaOwUwc
i1mYjeNwPOagDnMxD/XglkzcJBM3ycRNMnGTTNwkEzfJxE0ycVPmJOe8IzUjNbdqp5H4MB7BKJ4z
Gg9nvTmvWU/ReB8xy4nnkSWzjJLZRclMomQWUDQLKJoFFM0CiipCSUUoqQglFaGkIpRUhJKKUFIR
SipCSUUoqQglFaGkIpRUhJKKUFIRSipCSUUoqQglFaGkIpRUhJKKUFIRSipCSUUoqQglFaGkIpRU
hJKKUJKcRclZTB2UzLP3zb+Vidd/Xe6l41m89z8gXczSbZ8tYRZHz0uQeA7dLxln+B175/RnJN89
KCRz+CuSeVchHv9VS1zjw6p2RWFVCQ/bfgSPRrPiv2r4ymzUvufwfHRu1QuS/UXssf2Sdix6QELO
kpB9EnKWhOyTkLMkZF9lttqmv9qSKnCUdm8lOE57fFw3pOY8+9+WJGZOYq71ngpmqquDkx1XFSuz
1R6z1aVmqyXJudJsNW+2utr7vsr7znt3ayVowftfWpmthlI0J0VzZqurg1bPMz5bnerqT5WmK6Vp
QZoWpGlBmuZ41BSs8HMXatu08b1ACSdV84GECyQcx5oCCRdIOMmaD6RbIN3GZ7S4Nvn2bZGHTYFE
C6RZJVnz1jNF65liMrN9SxTurX7WN8PWN8PSdqW0XSlt89I2L23z1jxFa56iNU+x+jE/8wSG8ULU
xvE2jrdxvM16aNh6aFgi5yRyTiLnJHJOIuckck4i5yRyTiLnJHJOIuckck4i5yRyTiLnJHJOIuck
ck4i5yRyTiLnJHJOIuckck4i58xwV5vhrjbDXW2Gu9oMd7UZ7l1muKvNcFen/56lH8c6fAKfxKfQ
g/W4FZ/GZ/BZbMDn8Hl8AV9EL76EL+Mr+Co2YnyGO9WoqTNqpqbz0WBlhrvcqJlq1DQbNc1GzdTK
DHdqZYY7tTLDXakarFQNVqoGK1WDlapBr2qwUjVYaYa72gx3tapQUBUKqkJBVSioCgVVoaAqFFSF
gqpQUBUKqkJBVSioCgVVoaAqFFSFgqqQUxVyqkJOVcipCjlVIacq5FSFnKqQUxVyqkJOVcipCjlV
Iacq5FSFnKqQUxVyqkJOVcipCjlVIacq5ORZkzxrkmdN8qxJnjXJsyZ51iTPmuRZkzxrkmdN8qxJ
njXJsyZ51iTPmuRZkzxrkmdN8qxJnjXJsyZ51iTPmuRZkzxrkmdN8qxJnjXJsyZ51pQJojAzAfth
f0xENdLIoAaTUIvJOAAHYgpehVfjIByMQ3AopuI1eC1eh8NwOF6PNyCLN8KKN/MmHIE340gchaMx
HTNwDGbiWMSzcXNTFalORarLzLFdh7mY53G91jhUkfIqUl5FyqtIeRUpryLlVaS8ipTPnOScd0DW
Wu8XrfeL1vtF6/2i9X7Rer9ovV+03i9a7xet94vW+0Xr/aL8b5P/baljkzX+buk0O8nl/mQ9Hifc
6RJsfB1elGq9lURbm9xzGU+z1dIsn3wqYb1sJK83etuN3najt90IXW9UthuNBSOxYCTuMjqWGBmj
RsZlRsZX09+0b5NRsBnftj0+It6QjIjvRQW1vM7VWuJKLXGllrg6Z8v9ncm/U8+rCXk1IK8G5IPD
vfpsfF8HR2GWVz1bfh6XfJrXH8yz7222z0j+ZUKcpWEyOzUzDFbK+PH7PH2VjAxlYp9M7JOBPTKw
R971ybs+eddX/YIV/Yv4k3G/HxZFPTKuh/8h/0P+h/wP+R/yP+R/yP+Q/yH/Q/6H/A/5H/I/5H/I
/5D/If9D/of8D/kf8j/kf8j/kP8h/0P+h/wP+R/yP+R/7EAfB/o40MeBPg70caCPA30c6ONAHwf6
ONDHgT4O9GUutmrrVLUHrUNy+6xDctYhOdV2bfyXeKueiIrWIjlrkZxK26/KrrQWCVXaflV2pbVI
qNLmVdp2lTav0rartHmVtv3lXjkiejDplWO0s6wzxtckhaRXTksqZ39lrRGvMwoqYmmf+zf9KmKo
IoYqYhgst29FKhtcqG3TtsNc3/oia32RDS6zv0N7OczzrTGy1hjZfdYYheAG26vt68KNMKe3vsiq
fA+qfA+qeP0qXr+KF6p4oYoXWl9krS+y1hfZ/82Ar5ld/XfnTN9y7n+aN0n/funfL/37pX+/9O/n
f7/075f+/VI/lPqh1A+lfij1Q6kfSv1Q6odSP5T6odQPpX4o9UOpH0r9UOqHaf2afhiP4FGUYdyn
H8e/4wnsxpMYxlN4Gn/AM/gjRvAsRvEcnofrkHYd0vF12IOXMIaIWSlUIUhlrRWy1gpZa4WstULW
WiFrrZC1VshaK2StFbLWCllrhay1QtZaIWutkLVWyForZK0VstYKWWuFrLVC1loha62QtVbIWitk
rRWy1gpZa4WstULWWiFrrZC1VshaK2StFbLWCllrhay1QtZaIWutkJUvWWuFrLVC1lohK2uy1gpZ
eZOVN1lrhay1QtZaISt7stYKWWuFrGQOJXMomUPJHErmUDKHkjmUzKG1QtZaIfvyCLv+5flmPNeM
55WNLIxX4GfibCyWQTn7zmPo+dr323eB7eXOvRCX4QbzqvuYeP9fmGe1S9iLcQkuxWXowOW4Alfi
KnRiJa7GNTAazK8K5lcF86uC+VXB/KogvQvmVwXzq4L5VUGSF16ez+ydy/yzx9+R1t9l2G3Ygttx
B76HO/F9/DLKm3PkzTny5hx5c468OUfenCNvzpE358ibc+TNOfLmHHlzjrw5R96cI2/OkTfnyJtz
5M058uYceXOOvDlH3pwjL3PbZG6bzG2TuW0yt03mtsncNpnbJnPbZG6bzG2TuW0yt03mtsncNpnb
JnPbZG6bzG2TuW0yt03mtsncNpnblo6v7x68hDFE6mYKVZiVms+U+UyZn9TtvTX1VdWR+pbGa3AE
jsU8LMZ7sSJ1WaYD1+ImfAy3YoNn6dV+NVWX2i9YIKXOxmLkku9gJ9/Tju9zJcdOrXxH+yxp+S7z
yD7J8oOolKqpGk7u2QdVxq6VUmD1Er7yPe8onPDWVDDhRM94CQ/zyacqcdVvwZk4G+Nrl6sqa5d8
UunPk9Dna19J5vx/Wqv08DNfHfdnO6xP+JjnY56PeT7m+ZjnY56PeT7m+ZjnY56PeT7m+ZjnY56P
eT7m+ZjnY56PeT7m+ZjnY56P+b92lcrXPF/zfM3zNc/XPF/zfM3zNf9/YY7dw/cevvfwvYfvPXzv
4XsP33v43sP3Hr738L2H7z187+F7D997+N7D9x6+9/C9h+89fO/he0+qygymNnVm5c5hTsXOvXLn
MPl8K7lrGDTqnwWVFfaZf+5RcB7Oj/sPF6hi9+F+16UdEit9CS6FSpruwOWwOk9fiasg0dLxXQJz
pvQ1uBZW7enrcD1U1/RqrEEXbsRNuDm+9rgNW3A77sD3cCe+j1/iHmxHiF/hXniN6QHEr3MHfo0H
MIgifoMH8VsM4Xf4PR7CTsT/F8drK58bxvc1e5k9XPnssI/FwyweZvGw3h/W+8Pp+P7vVlgF6/1h
vT+s94f1/rDeH9b7w3p/WO8P6/1hvT+s94dTZ7xy7Y0269/k+p+l/f+lD/q8kx/gf7IvTk7uQ49X
wP7kfvN49etP7i/Hc74LzL8q87D/J/dz/6s52C9xD7YjxK9wL7xGo7o/Hb/OHfg1HsAgivgNHsRv
MYTf4fd4CDuxK+qP/y16vMraJ+EnvPKv06MwOd5vFRZ/4h3G1qb2T36iJT7n5b1h6pQkz+Msj92z
zkvmFuNXtpBk9/vti/8K+n1Rsfr+5JPH//mc/q7fcxu24Hbcge/hTnwfv5SZ92A7QvwK9+I+DOB+
7MCv8QAGUcRv8CB+iyH8Dr/HQ9iJXa7TQlekJ7lWC7QtyecbBaOx4Mr0Jdctl9x/DCvVrccV2lvJ
CtXxb26XvBfjElyKy9CBy3EFrsRV6MRKXI1rcC1W4TpcjxuwGmvQhRtxE27Gd/2e27AFt+MOWP+6
QgVXqGBEFozI/9nKMm7UGX82Uyj+xblEad8zJrw16p9wIoeXu9LDrvLzQVOSff2v1B373l3Jvfhf
mZ3nvPOxpJJ/y/ABfDDOwvh+494slEEX4xJcisvQgctxBa7EVeiENbwrP+zKD7vyw678sCs/7MoP
u/LDrvywKz/syg+78sOu/LArP5zu9ns+jI/g77AWt+Cj+Nh/Iyt/iH/Bj7AVP8a/4if4Ke5CP36G
u/FzbMMv8G9xvfMa7sF2hPgV7sV9GMD92IFf4wEMoojf4EH8FkP4HX6Ph7ATu1SiqrgXkuzQp673
u/TJufbEc4iZqUzyjZvHx7/hUVkdd1kdh5VP4Hom5KK1qbf/xW/PLPdsF+Ky+M5JtDu4Jr5vz4vr
krsnw4HVQtBt/DyCR1HmbsmrehiP4FGU8Rgex7/jCezGkxjGU3gaf8Az+CNG8CxG8Ryexwt4EX/C
HryEMUTRsJn6sJn6cGZBVMg04WScglPRjNNwOs7AQpgbZBZBRqSurtoZ1ZtjzTTHmln1sO1HMP5t
mKVGwtKqUY+fg5Vw8qmyFXDyyXL8+cLeddv4N0zCZP0W341I7jMln3TkAxUpXtPFdx/2+YZJmNyH
3/fOwz7fJPmbrnf+q1XvX/etgTBzFtSpzGJI5My7kcM5kMyZ9+A8mBlklqAV78X7sBTWypll+AA+
iAuwHCvwIVyINlyE9riaxt8SqHyjemfySfwhyfcG9n4zILB3P0zExay+EvGZN0Ul/VLSLyX9UnI9
Sq5HyfUouR4l16PkepRcj5LrUTLyLorKwcrkU5gB42OH5x+/01Zx6uU7bXkpO4NXc6qeTh0saWfw
a07ViO1X7rzlq/ZwJjBz3Q8TMTV1cHIP8+Joh9e4IxnDyec83sN1MvemaIeV3hwrvTmcOnhCLjXD
69/h9e/w+nd4/Tu8/h1e/w6vf4fXv8Pr3+H17/D6d6SmGwG7mb+b+bvZvpvtu5ldZnaZ0WX2lhlZ
ZmSZkWVGlhlZZmSZkWVGlhlZZmSZkWVGlhlZZmSZkWVGlhlZZmSZkWVGlhlZZmSZkWVGlhlZZmSZ
kWVGlhlZZmSZkWVJtjJZF18kc8zzUvOSu4PxncGL43u7iD9VvDK5LuPfCozv/JkHV5uLVku26vjO
2N/y7lgDToAVecaKPPM2zIc1RObt3lv8SWgTY05izEn6oklfxH8pr3+fFGrSL00MiQ3OsWQni3NM
CZkSMiVkSpt+69JvXWwZ1XddjBmt3PWOPx2MP50d1p9drBnd5xPBNsaMMmaUMaP7fuqn37v0e5d+
79LvXfq9S7936fcu/d6l37v0e5d+79LvXfq9S7936fcu/d6l37v0e5d+79LvXfq9S7936fcu/d6l
37v0e5d+79LvXfq9S7936fcu5o4yd5S5o8wdZe4oc0eZO8rc0b/mE5HUhKrdle/mqIGu9V+sexW7
LqrYlXxykHzCGte/MLHrL9a+v6Fhf03ta/o/5FRvUv9eyaT48/YHkm8ixd9Cir+B9PL4i7/3EI89
7Up5NH5d+8fH35/n6N92/P0XGZ7Z+73k4OvRncFt8u/O6Ongbuk6YPuJaHfyHePm4Eve11fxde83
zwrzxsA8MLB+DqybA3PawFo5sB4OmBV4v4H3Engfgdc+oQaTEf8NhYOQxWyvz/wx829mMOaJGXPA
jGuV8bMZ1ypj1pTxfjPeY8b7qvF+aqRhzX7YHxNRDc9dcwAOwVS8BkfiKByH4yF/amRPjbpcY65e
Y65esxRytOYSXAo5WrMmFdTqk1p9UqtPavVJrf6YnEYGftfkSfBeJpsDWMd+vfKuDvXogODWKP4r
bGHwbdcp/s773WraQLQ6eChaGuyK6oNylAueSM2ckIpOmjAl/tf/Uugw89D9k3+9vfcvTtwdDU/Q
gy9/3+/O5OhteiY++oRa98Zod6rm5Z/5duXn7vKb707OiP8V+PjrOszzeHbu3paq/Pvw8X/xm2qv
2jm2pephPILYg1Htc3g+KjK/+GcZ+8no+uTdfcb2Z727L0QnsWIKK6YEX3Nu/Dr+wTzgux7Hr+UH
jv/I/n/1+KfRPUE/7vazP9dud/xe7f34daoheED7KB7D43DFg2fsf9b2nuiKCTU8nIwsZke7Mz8w
0/khg+9KTclsiwYy93o8EJ2UGYyuzxTxO49/77hRyKgpjJrCqCmZRz2W7ZnH8DiG/exTGPGzo46/
EJ1Uk47uqcnAFarJao/GdMzAzFRDzbGYhXke10N1qzlR2xjbFe2uWRZdUfMBXGz7ElyKNdFuVk1h
1RRWTWHVFFZNqX0huqf2RfwJezAW3TM5He2enIH3PHkSvO/UxJe/9/l1/ZiMTA5MiR5IHbD3W0P6
ZnXFvOF9zMszr4d5vfHfm/BTM5gTTjjS7GeynzipcuZaZxactdpZPc6axpF6bhZqS1F77TPRCbUj
Ue/kquiE1DL1uqBOF9TpgtpcUJsLyd+7uzXq28eNfLDR/q9JxH+w75u2v/OKgdyI/zpSgR/9gVVk
0B+/Clg9Btujbwf3aq2QgwcgMQNpGUjL4CnHnq0YHBgjE2xXW8kZ/RMOHB+DE6Z7fIx2ptTY68mP
5f7PsM3jX2jHfcm//Pep9vVl3JF+jvRzpJ8jIUdCjuQz3itH8jXSoEYa1BwafbtGktUcjemYgXmo
xwmOmfHUNGpPjoZrpEXNO3G+7daop+ZDWpWkpg0duBxmczU3ONalvSnqqZXwtdKvVsLXSvjascp3
0JJPrsdHv14dz4Wp+nBI381Jpf9SlmSeTC2pmYOVqbPj1JI7SWrJnp/ov1zwKef2YD1iMz6t3YDP
4fP4QlQbfFHbiy/5rV/WfiWuCrY3ar+WvJqlwT9qv4F/wjexCZvxrTin2PXP2gK+g+/62S3a23EH
vld5zd9HX+JJbfBD7b/gR9gaVx0/89OxUtCPu/2+n2vviWqC7WM7g19p7/X4Pu2AMni/7R22H9AO
eq7fjD0fDNl+KJoa7LR/l30Pax+1r2z7Me3jkNDBsP1Pec6ntSN4diz+K0B8G+ubUDP2/ITJOCCq
nXCgkTLFsUNtH4as/dOdc4ztmY7NHns+471lvK+M95TxXjLeS+bHUEEzP8FP40oY9WZ+pv0FVNWM
qppRVXlamzEWMqprxnjgbI6zucyDtlXazC6U/OzDeARmFxnjJWO8ZNSBjCrG3dqMcZMZddzsgcO1
mRejmsxYVFNThQD7jZVq9tdORDXSHmdQY3tyVFtzgPbAsedrpuAQ24f+B3dfAh9FkcVdVd1VzfQk
4QoQUEFB5RBR40FEvFAjIscgqBjUxXUEDRAPQCMa1IAGNS4GNa6Ca7wQgrrRxV2MGq/oDioBAgj4
oRzRgBhCGA4Rkfr+Vd0zmUkmCQHc/fbr+r3p6urqqtev3vu/V9XdycFNdgfsk0AdUdYFdU9C/mRQ
d+R7gHqCcP/2aSg7HXSGnGsno60zQWfh3NmgFLRzLs71Q/487M/H8WBcMxR1Rh8stscjPwE0EXS7
PNu+A3Qn6H6cm4ayB1DvoYPFcdvk3LifQVWg7aAdoF8PVsTtB/0GOgA6eLAivsXBffEeEMYw3gvC
OMZfory5tMlEaL5Cr+pwvPMSLOFlIJWypnnQ3gU4fhv0ThjJqoFkytMVxYyHvokRDwXdmIjAMi3Y
YSg2SpBF0KYKJ0aSn+vYoItGtHXQpiJoU4WOmT6Gt1Jx0xfYfwn6SuYhfsqDpqgYKi8qhkJ0DiQr
ApIVIZ7KgyY4MdUvuO5X5OvGVocaVwFd4QkZPGHsGGuoLLJHyM/tkaDRcp19I/aRsdbtsgIjWYGR
rLDvwrn7UQexF0azCMi3rlkxWPQa3ha5LDSfofvhNQ/CaxogDrL032bdGzG6G3RE+yrm+vMUXuH4
bZAa3Q+xVyOqvO03mAVsw3VVoKBcg5FaY7RGLNJLrsFobHBHYwP8yxaMyAbPVzj+GvSNtte9sNe9
0ZEtqBp1d4Cc0dhgnyLX2L1Bp4KGgoYjbrgbdA/oAbkmlkTI6TFncbPkau0Bnkf05ejouvC3l/92
v78sk581+A3mDpzbg/0BuQI6tQ53sBp3sBq6sw46sy78DWR7+VmD30Gm4Fw/7M/HfoxcgYhoRczv
Ik92ONVjMci1siyMwyCMwyCHez0Wg3Q8q6xFWUkruQ8WskxFKCHrwDgMwhgMgvwHwSKyYBFZnpVq
DLDfBtqt5TzI82tYO5dBO5e52rkMWrhMa6GrgagFtFJxD+mmY5MlkEi92Q7KYsx2QlblkWgvPGtB
PpZ1JaI80sK64riB2YvW9m71uPgWGNTAvOuQ504tEY20AkVy0hHHIU76IB+LGyduU08846FTi9m3
RP0lPcaqdLS22EZUZrfSkdJiu6NqR8mVJEM/FkM3FhMKvws+1bN96GZFKIf2qPOr/y+Ds4avjpla
G3LOqHbIJYhH4xCPxiEejUM8God4NA7angdtz0OLc6HteVpiZfDhy/W8I09LbhX2SnprsP8OElTS
2wwUVxKsRNlW0E86GnYkugPXu1KFdeTVlywkFCnZFojjPKBIFG0P/xaSbhecC0m3O/KIW2FBeWEp
n4X82aAUXHOunmPkaXQ9X9qwpDxYUh4sKQ+WlAdLytOjcTmtRkS+A7O3IPa7lN270XUgwjetcHVn
las/KspeG0OPIiPvbeQEjOkJkbqlI/FzZZbRD9bVlJ6FImYljfgmdK5LhJ+JjKwjdTAZdGZEtK0l
5OhlrKjZtZzPZBB6EYROBKEHQehAENgehA4EER8GMe5BjHsQ4x4Ma3EQ+T0yiPEMYjyDiIWCGLsg
xiyIMQtizILA7iCwOwjsDiK+CSK+CWL8ghi/IMYtiPEKYryCGK8gxiuI8QrqVfpizMaCmI39pJ9F
JUavkrjev4/rUUcAF0ZqrFoXvWrheM5Y3pF4geHVQMyl8FYVQMmlQL6l8CwVwORqYHI1PEwFPEwF
UG8pMfXfI3TXMhDLrnNWEfSMQdnhJmJErSq46x5OPfTTXi7T9bY4Vop726vP3KpXG46DpVbAUitg
qRWw1ApYqoqo52Emt86dyRWFYyAH2YtCcQ9mUOucGRTQ+TrkR2M/FvvwDCoinrgf5xwUL1IyILZa
2Qtzm0OOR68j0RszbGhvPCgBHKj5YyvFq16RmWt0QXkP1OmF41PUOMgszO+zwIHqnWF+n4X5fRbm
91l15m8M8/0scLAOHGBcZBbm81mYz2dhPp+F+XwWOdH1ZssiYr9JTuyHsraYwbZXHOjYbxk4mBSK
/dzYahK0IQ/akAdOlkEj8hqJrfLA0TI3tpoEjpbF1JTWoTWfKB2M1L/IHhrSNxP3UQN+a8BjDfqr
IZb+W/eIlXQ8U/t3nnVcQ1pDDnGQg9LRHNer5+De83Df1WgnB+3k4F5zcK85uNdq3GsO7ikH91SN
9nNwP9Xah3wO3RwNW7pefmP8Sf6sj3YaN8hdOCoDX6PlLzhXYdwo96AEto2jSuQ2EcsYJX820oiN
OrtxfiNKi40xqH+TXE04zu7UZ50zm1BajfbSiAf1t6CVH1C6AP2Nkntx9KzqAUfqiuvl9nBfPyEX
QPnt4OgOXDdJ/d8h5P6N3FqU34E+79Lle3X5duSqwNsE9D4RLWdAHrdjdO7EPU6ShcYUCdRG7gfk
vsP1GaQljl7A0UocTcAVd8hctPi2bk1d85OqhTu8Q/6o2zaMl6Fbr6LN10h3Qo355Hj9m6h+1X8o
Qr6Nzq8jrcUIEhAjiV+MIp3FQtJZ//fjF0D1/+txtv0OybQ/wv5j7J3/clzs/Hdj2OFMtVaF1nzE
sJ9CHLBMluL8XI0bawnFmWQiaDVJpjuInwax30X8xrmgfsSvn02rEqC/9yLi945DWXzE/xQupqZ8
mLaUq+kZsowOJj3ocOxvBj3o/h/AStlHcUAM9TdX0bPwDkDvXcmjaCmXFJLZaLuY+BnBvRKaICio
JfInk0zRl2SLVFIohpICMQz7T3AuQNZbHUAP0wTrUZpkPQZ6Evf9OCm0X6NJ9jzQfJJrLwAVkTS7
mOSC80RvKunsTaNJ3ptJmncs8eFOSry3kTRI/yNw8AnoU9BnoFLQ56AlJNk8jSSL9iC1Px10Jugs
0AhwNgn7xyDRt0kqpJ8K6fu9t+C6JMROyZBoNmSXDYlmQ37ZrAPJNi7EVUdjXBnOqv9vnUxM5Pyo
58eRX3FA4oSSJAV9QjKsh0GPkkzrMbTwGmgeaL5cay8AFcu13jSSSSxc0R+1UlErNep/XaeRVMJR
ko+SfJTkqxJIrjN0aT5aWgAqRgs88ki1iTrZ5BgyB9I9ADoIkiTRTAVdDhpIElWf4LK/iEd+gP7P
xuo/CyeK10kiuFb8+MCPD7JJh2zSIZt03IEPd+BDb2noTY1tmsuRH7akNGoORhTahF7T0Gsaek1T
moWe09BzGnpOQ8+56DkXPadBy3LRexp6T0Pvaeg9Db3novd89J4PzcpFr/noNR+9FqDXAvRagF7z
oUm+KE06tm7P4R7jiQ86nap7qtNDvdaLtOwLoLP9obOJ3oHoYRTI6TEVPar7LUSPqdpuM6FlmdCy
TGhZpv7/5x+TfETpZ8KazwadA+oLSgHBqukAEqCXgi4DpYIuBw0EXQEaDBpN+tObQWNRF3Kl6chP
BN0OugN0J+gu0CTQZNB9oCzQNNCDoK24ZhvoZ7II3AXAXYDWkHy6ExREfhdoN/J7SD5sYhGQJh9I
kw/bWGQsIYvMazBa14JGga4DpYFGg64H3UACJngxwYcJPkzwYU4B3Q092gC72get34/9byRg9SR+
qxfoVIxJEu46G3edjbvOxl1n466zcdfZuOts3HU2uM0Et/ngNh/c+sGtwsJ8cJsPbv3g1g9uFZf5
4DITnGSjx2z0lo3esoGTm/T/Vy8lJ1Ih0+nxoBNAXUHdQCeCTgKdDOoO6gHqCeolU+gpMsW8Qqab
g0BXggaDhoCGgoaBfKDhoKtAI0AjZbr4HlQJ2gLaKlPEXux/kemWBUoAtQN1AY2X6Yh7W5Jy3GU5
sLM/sLPctZVcsj6EvCwOo9EKlEjyYR/ZsI9scbKsEn3lZiDweiBwAAhcrv4yFrQ213oS8cTjZD20
NxfamxvGCEd786O019Hc/tDc/tDcAq2548kMcPAY6HGgWC7oCeT/AgImgqvO5EPkS0AfAV8+1gid
CYTOBEJnAqEzgdCZ5AuUBzRSZ5IvUfdr0FJQGWg5aDVoM3r7EftKjCIHbdW6mR8ebXeUIYEAJBCA
BAJhnVxC8uEBMk0gv5lDkvl+4ue/gQ5AzxjIBAlIx4N9W1B7+Kxu2HfXHiMTHiMTHiMTHiNTwP5E
P+wvwX4E7Q0fEBDXQdrQbQHdFjeAJoAmgjJAt4PuAN2JtibhusnITwHdDboHlAm6FzQVBHQXkJ2Y
BXoV9Bbo79B91LVbg54GPQN6m1QCIQL2P7S/qARSBOwlyEN2NmTgPQ8ebBhoBGik9maZcTMhO668
Fq7OdD1NhvY0x5BlWsb5kLEvwu613ATX9/tE+F5h1wJ2jXv2Iw7xRfC0P8xTsfakNVF8YUyjeFBe
0ed6RR/p5I6lgzMuvkSOJaxWjWcA4xmA9QbAU36E/JVsrgIfo9HyerS8CHwoHtaj9UUuD1dBNtkk
wfXqfter+12vHo6V0LpfeXZXTorHTM0jJc8BFxL0l9yvE18LRCcRX29ntvg7yuHPPb1JqudUku05
jfg8p4POIt0855D+RH2T0gO1+pLWh/q0G3OAlLpPvDEXSMFcIEWv4/j1PGFu3fkn6sxFndr4rLIB
hMjXHlTHaRolqoASNUCJ9UCJSte/FQApCiKQogBIUQCkKARSFLpIUegiRWcXKQoifNwiIIWPeNBb
KnpLdSOCtJjxyDGa39i8Km+fD159itdo7w7eav1vbav10SvVRS/H74Z7o1XEV69HJRUlkaFA3GGI
VB8lhegN0SloHqjW0/tcT+9Dbz0iJBCKKxwJXBPGyhBGRmJjLFxsAA81/v1MCptjLyEMjIl9dXEv
Nub5XcxLCtlck5h3KHjXOM4FInAuAPvNjYVtUTbtd21ajaUf0vBDGv5Q1O5G2RloLV9jXydoQKbr
QTOgYwWujqVpewiN/MPQf3f0XV1rXAPSoF91R//YwxkxeKWAlnyE1OtJR0km2gM4SNsqJtJFSyUK
9VzEy3QRL5O0In8F4inU2wf6FbQf9Bvod1kqngfNAc0FvQCaB3obs9IdoBpZ6h2t/iPvYbXwtjsP
imzpJMwJShCVlyAqL0FUXsLiqMlagRKpiXlBCaL0EkTpJZh9mhjFGkTrJZgX+DD77I+IvQRzgxLM
DUoQuZdgRGswmvutx4FFT2ovlopR3W/Pp6a9gHowosn2IpJoF1MPRrUAo5rrHQxtuxkjOxY0jiZg
VAsxb4vEm3FAeTUTT9PlyShPRnky9CGZXAHr98H6fbB+H6zfB+v34U58sHAfLNwHC/fBwn3aGy/H
PuSReX2vDCv2wYp9sGIfrNgHK/ZpT+3Bvi2oGygFpDz3JdjH8N6wXh+s1wfr9cF6fbBeH6zXB+v1
wXp9sFwfLNcHy/XBcn2wXB8s1wfL9cFqfbBaH6zWB6v1wWp9zY0GYMk+WLIPluyDJfu0zirppepf
PxkXEVsmwkYTY+CmHzFlIrDTD+z0Azv9wE4/sNOPmBI2BUKPDcSU2W5MmQrvmEopSXRxNRs2UwCb
KYDNFMBmCmAzJbCZEthMCWymMGKuUwhM9SOuTERcmdhAXBmIwFe/G1cmAmP9wFg/MNYPjPXXwdiE
Q8bYO9HWJOwbx1k/4spUxJWpTeBtuYso5ZGjFQNz/cQTiSQYr0I3ZspwY8tMja9c/7dyKrdQU+4M
rUmQdiG/G57DD4VdDsNsz402IqKM6Nl0bYQRmoskh+ciag2lvxux9dcRW3+McgZ63g37KVT4yyjJ
MM4CnQPqi5EcCboaNAmUBXoI5dmg6aAc0AJQIWghzr2B/ZugL0Ffgb4GLUV5GfbLQMtBK0DloJUk
g78I7yaA4f0g9RFkP+STL0ZhFrCQJFvTMYNTK0ZP4b6ehqyU9OuvHC3S6wD/AIq8r9eJFqk1gbAN
OStJa+xqnAPmuytK85FboMbHXX1RuJYKWaaGV9PUSlqa9kydSXxoBBpYywjgigCuCHgvkl/oqGYc
0K01eV6v/Dhj9zfkX9SrPbFaKEcL5WihHC2U6nG7HhGZaqU7tKCSzIafmaPj00qgew3QvQboXgNE
rwSi1wDRa4DoXYHmlfDL5UD0DCB6BhC9BoheCUSvBKLX6HXEHBVd0t7WY7QrkD0DyJ6hdfs12tWe
B5oPWgBS/nqRwmbaFei+2JuG/c24x7GgcfQcaNN6veq13lRz5tBqZjzyJ6uYELh3FfIFevXSdHtN
QK8J6DUNvSqL8qHXBPSaENVrMU1CbwnobRF6W4TektBbCemH+09rNA50sMoHKYUi1QbnueGZv8Ke
lvB+Kq6rG9P1BblWF/YOKl5z5qA+YIUP8X6JI7/w6oBjjc4cK4TuBe48qxYvVNydBi1TFor4LCLm
9pET3BFfj9Eux2iXY7TLcUfr4c+T4M+T4M+TlNwx+uUY/fIo+Q/AsSt7jHp55Opx7aoxaAFIyRrX
u6vFJeCiBPLuCi4C0L3Z8K5ztM5VgotKcFEJDnqDg97goLerf5XgoBIcJIGDWh1UshuAfK3+VVpZ
IEf3eivdi9C7buCoNzjqDQ3wu3rXGzJajogiG9z1BnffgrtycHeR1r1erowC4C4A7gLgLlAn3gmA
uwC4C7jxzn5wF3DjHR+4C4C7ALgLgLsAuIOsEO/kKEwI62oo9onU1QRwmgBO+7ucmuC0EJxmgtM2
rt4WhvW2CzjNBpdrwOUacLkGI1kZNZKXkzXgck3EM4Fy137XgLM1rpxCIxfbPh05JUXYaG89in10
BBDL+y+J8vDOqhElnZtaMdJrg7XePWRRyouXaO9d12v307OckIfVKzf6jkKe1Jm51HrTXZCj8p4n
a7k5VhCpf3UtIKR/kQik8M/v6l/IEipdJPLr5yiPk8wI7Iu2Cle2kGuJK9eESLkSzl6WZaxElnm2
gLaCflJ+hWwhJuYDBBF9BxJPOpJhpC25mqSTQWQKeYCMIQ8hbh1PVtA4Ukxb0dZkL02kHck+egy9
kBykQ+hw2o1eSyfSHvQe+hC9kE6nM+gg+iJdSAfTTXQLvY7+hDSG/kyr6E20mu6gN9Mg3UVvoXup
pOMYYxa9k3mZl97D4lk8zWQtWUt6L2vNWtOprC1rS+9j7Vg7ej/rwDrQLHYsO4FOY91YNzqDncRO
pg+zHqwXzWG9WTJ9jJ3FzqZ5LIWdR59i57ML6LPsInYxfY5dwi6hc9jl7Ao6l13JRtIX2TXsOrqA
Xc9uo2+y8Ww8fZ9NZBn0A3YHu4uWsMnsXvoJu59l0X+zh9h0uoTNYvn0a/Yce46uYi+wF+hq9iJ7
jX7D5rMF9Du2kL1JN7C/s3fpZraYLaY/sWJWQrexT9indAcrZUvoTraULaW/sBVsHd3H1iNRtpFt
wv1XsEpmsq3sJ9aCVSHZrBrJy3ayIItje5AS2AHDYC0NYQjWwbANmyUZ8UYb1tFoZ7RnXYwkoxM7
wTjW6MpONE4yTmKnGN2NU1hvo4/Rh51hnGv0Y8nGKOMmdpYxwZjCLjDmG/PZQKPMKGNXGMuNVWyQ
sd1syYaZbcyB7C7zavN6tsD8kzmevW1mmFNZiZlj5rCv+CX8EvY1T+U+tpRfxa9ja/n1/Aa2kY/h
N7HN/BY+kf3AJ/GpbDu/n09je/h0nsv28Vm8wGD8Zf6Kkchf40uM9ryMbzTO45X8F2Mo38/3G2P4
AUGNm4QpTGOcsITHuFV4RStjvGgjUow7xXmiv/FXcYEYYDwvLhcDjRfFIHGl8ZLA7Md4RaSJccbr
4jaxwHhXvCHeMfaKd8U/jd/Fe+IDQ4qPxWemIb4QX5iWWCKWmC3EV+Ir0yOWieWmLVaKVWacWCvW
mQnie/G92UpsFBvN1qJSbDfbiB1ip9lJ7BW/mseJA0KaJ1jMYuZJFrdamydbba225plWO6u9eZaV
ZHUyz7G6WKeZ51p9rfPNQdZl1rXmcOsGa6zpt261bjczrDutSebd1t3Wfea9VpY1zXzAmmE9Yj5k
PWo9Zs6wZll55iPWB9ZH5qPWJ9an5hNWwAqYs6yV1krzSWu1tdrMs9Zb683Z1kZro/mUtdnabD5t
/WBtMZ+xdrRINJ9r0aPF6eZHLc5vMcQMtLipRba5rsXLLfaZv3mYx8Ov8vT1DOFpnvGeSfxOzz88
/+BTPf/0/Ivf53nP8x7P8rzv+ZRP83zu+YI/4lni+ZrP9Cz3rOC5npWeDfwvngpPDZ/j2efZxxd4
DngO8EKP9Ei+0KY252/YHtvmb9vxdiL/h93e7sjftzvbXflHdnf7VF5qn26fzr+yk+0z+dd2X7sv
L7MvsC/ky+yL7Yv5CvsSexAvt4fYQ/m39nB7JF9vj7Kv4xvt0faNfLM9xr6ZV9pj7XF8mz3ezuRV
9oP2g3y/Pd2ewX+zH7Ef4b/buXYuP2jPsvO4tJ+2/yqYPcd+SVj2q/YCkWAvtN8QifZb9luivV1k
F4kO9jv2OyLJft9+X3S0P7Q/EZ3sUvsL0cVeYn8putpL7WXiRHuVvVp0t7+3N4iedoVdIU7x9vOm
it7egd4rxLneYd5rxXne67xp4lLv9d4/i1Qv5k1iiHec91YxLK4irkIMj/sp7mdxVdyvcQfE1fEt
4r3iuvhL4y/FTI/1nQu0Jf1KLnsZOJtG/uc3uSR67+TkTqRpsgg5RTMc0mdTjrjHZ0FPxygvBi2L
OJ6NNFkWyQH6aLvcoH6baLsqnNvs0NHZVLuyGlTRrKsw70Padsj1t8qv5FYl/eZziC1Rp1Bbm2VQ
fif3os0q+dNhtReWZoRU65X8Z7amR1LudfffRe0TVc4ZAbkyXLfqEO5AXVmFtDmyb1USzZFTEqs1
dWX01VFnd+rr9jr5UFnt2eheQjwfLbk3zHNTsg7f/6aovZLWJi2vKrlSfu/IH/ktuqeaRhpMDPUc
W876aKfcATvajNbWxrINnGlQMsCPaQ6KNWf7o/W7duz10Zg6Z++VnWR/ea/Ol+PO17r7MtJZ5UBl
Wrc21Y6DK4WiBrvsgRprkVY6dqDadErcqxX6zq3LY8RRKXp3vEGZPu4TcW5tWJ+bQC75kf7d5l6z
tvHah77p1pTWbW3WVXu1FMPjUIueddsO5eQS3VPN4fLptgMpyU/R83LQmkPBey3b5nozepjsHfXN
se2j540Pk4tm2TQQ5wv5mdzxR3HTYL+rj1I7y6P3kS3HjEhi6v5R4QSoIudFFPRAX8nYJ9erWRy1
7wFMWSj/qUvmyXehRSoynR063yDiV5FUF+vele+GS9eirZVAsdKImnsVX1G8hc4UIfIs1n01obXh
OGBzvZIB8kP8KhrskC4d3Hh7TW/yFtCtMcrLormVreSJmjo12eL2ULwk0+WXuO8vkZuMKye756+J
cc3O2hRV7kQ9RSq5JUEpZDakMU0Oj9GOGoHwmBw84JA8UZ/bqu+pWZj+n97qaqGsgI692rx5wlHh
Y12d412N1K2j0/JnZWXy5yZ6qI2fP1MktzSXxwbaXeLq7qpGa1WFfIgbuWyBnBc3q5/39O/hza06
60RcT/yBg6uavm+kx7JwzuF5trIkhSoN4UYd7jq6dHQ21ZIdg8tQfKM9gJzpHnV2zw6XXYAEo3Xe
RUp3r2LRuRiFaG1KRLnmGbjfuQFOkl2cmOlEnI7914k3rwm35nDeMurszDBqKy4G1Lmjl1RELV9q
oPd6mzu3qj7U+ofYalmjZ0Wd46nA6hvlVJ13LDGx1iKRa1WvhZAGNRlFR82tHDn21Umdm1Wn7sqo
o7LI+1DI3LxN7pK7Mf8OKi8ACjh0dDbFaeR6Ubi8oRl3PTnFmne7M3I1l9rgRN2y0GnRQaAY7VZp
T6Vmvt+FVh90bLElGiFR8jHKPpQ/RMtYnyuNnsOGZkfyX7HvJSYfNeGcWkM6SujsSKf5qAlvP0D9
6nxobaZ2xrtXy2Nv7GuP3lZ3vTA6RqqHGyt1NFJvdJroI3i43DXQXqOrdfV89zL5lHw9lh38sVvt
vMI93thI3TrcySnyUvWr867Xr/X+Kid/lD/Wa0XqXUM+5Yg3PfZF4aMU3ZOiHs4xotgUV59nwl7n
an8+F3u1spIuy1FahqjXjWc1bdZHo2P2VoaR9GF/B9q4yo0JrtGR8xQ189Bzj3Td8ja3tforNDNx
RbocjP1MjUKRazKz6/RXEb13cu4Kp2vharZ79Ga8DeHGka0DOF4aszl3BfMPWOf/L69ThDYHweFZ
6s5/bJ3+a1vd1Uq3VPmu/sqCoNmDnehMr7w6c0FnlTzGTDuqjdk6bpscjggnR5wrPirMx+o1ev66
W+5u+OyRtHwYW2ET7e/WdSJr9UDq3/SVMXsK0RFsh7CSubNuHRnU6QjilSOTs9zXyLk9+rciAjV3
1I3rGm27tOk6/89vfpeOcMMoNaXPO3WdiFph3ThsfT5iG2z2Jr9H2vCf7jWi/8OIqmW1TkeCdUcU
BaPnBtefHa7q4wZJ1mh36JuzvjG7qWoRW/9m1CXkPx6Dx9zqrar/f7A1tGaQH5Gv1L9HilMBl/Kb
qtj41lgM6VhKjCfW4TXG5rQdPSP472xHewZ8pJuLGDX6N1iPO0fOTT7vCq8XOWMSiTQdjoi7pnXj
KK2MRL4N4EQyh91SI54h9A5L7KjoaK7x1F2vQyy201mH0HPvF/XqzjQ5yp2lV8V61ua+o7LF/Q3z
rPJIxSqFa46Rz8oMOcdpL6oVNdNfpmfk2or1E76La1eU0NIvTd5NxBxWbjuUt27qYoaSuX4nZq07
v1Krahuc1qD3VXVHpLG5shwgO8kT1bNFNU/T75qE9j10rlqvWNR5c0gfNfxEU11ZijTFnQ/O0/dQ
qlc7Nzv6WfdJZqS+oMc+GI9rQm+pRD7J1CsijT9PqYpp/aHtj1tHcld/3HgjRWONQg9nHSldJuGu
Zjo1cYe6tta6/lrOVcivdeXvrlYqmTU471aSSdWyKJLZrpxn44q1+tmMfttHr1VN0NoReoYWNS9R
825cPRv15+uzketI+gm5lrPTtrsuV7s+p1eN/htyDq3lOnIeU2e97jFIeVTo+RKksdmVd5mrlVXy
3/oZ1BaiV1pC6/6gB2L2pnpK1bJQq3OOLJ5HK9+ipNRZ+VdPnOSEcDvhZ5XhNtbKF9TKIfbFagUn
8l3a2jcV3OMvo/ekme+eHr1NW+khvakVelLk7jtrC/4/umSeXCK/UW9/HdJ6nXo+CIlGvq2hZIa0
JOI95Rr4SWUXH8fgZB7srFSvJDX6FO5/YQu/qadW1krlmsbeY6qNBjVuFkM/l0edL5KnNrP3Ku0b
FJpsRntFigPdzufy80avK43k6FBX75wVv7raJnOaybPyyzNdJF7r5oub384h9hYZHTAkvXdH4swm
Lu4ROYfVOK3eF/rgMLhwtOQQ33Fz44kjjM3qvg2uEbnq0JBKboUOKSzYUv9JT0StUCw2CXo3WKN2
NKJ+3mx9rlT+TetzmXwGVExayR/lOqRNjV4XPetac4i9OZFonVVAmdccjl0dnu0i8Rdufg1pcj39
qGyTiNJqIk9x9ke8RcR7tZ4FaJ2OGCTdtf8+B1cd3Cony1PlSc3vQF4o47QdZinemzM/dt46iyrp
2BAHdevKdP3e2gD1zO6/uzXMQb33zDsd3HpwFezqGHkYbxnJsw8675yNJNANeWMzrkyqW3Iw2BAH
MeS89X9NzhFnWv0RnDSnt9gcHE3PKL9t5JzjdzZFfLWwU24PvaXR2DuLbo3ShqJH9Rf1ycPE1E9G
48hgYpGhZBgZSIaTh8ggMgPn7iM55DGgQi55AmWzSD6ZTv5K5pLHyevkLfIkKSIlOA6Qr3C8FGkh
WUG2kjfINqRSUoX0OdlHGfmCchpHVtCWtDVZR9vSC8l6eiUdSj3UR4fTeDqCTsC5DDqd9qQv0lfo
hXQeXUAvpZvoj3QgraaSDtHfTP9JfzN9i/5meqz+Znqc/mb6Vv3N9G36m+l09e0vHW9sNzvRiWZ3
sw+dY55hnk9fMS8yB9Ii9aUvfc/8k3k3/cTMNKfSdeZMcyZdr770pd/xVJ5Kv+cD+VC6gfu4j1by
q/goukV99Uur+U38JlrDb+FT6U79va/Fs/nfmM0L+CusO5/Hf2GnqK97WRY/wA+waVwKwh5Q3/iy
h9Q3vixbeIWXPSwSRAJ7RLQR7ViO6CA6sMfFceIkliu6iz7sGXGGOIu9IFJECntJfQfMXlbfAbNX
1XfAbIEYLq5iC0WauJG9KfxiHHtH3CZuY/8U48Ud7F9isribfSjuE0+zj8XzopB9K94Qb7CfxVvi
HValvhJmO8V74j22S7wvPmC7xcfiE7ZXfCY+Y/vUF8PsVxEQS9h+9cUwO6C+GGa/i1ViFZNirfje
IGKj2G5Y6itho53YI341ksQBixnHqe+DjROttlZ74wyro9XJOFt9GWz0VV8GGwOti62xxjD1TbAx
RX0TbGRZd1v3GA9a91n3GdlWlpVlTLceth4xZthIxiPqO1cjR33hasy08+1njcftOfZc4wm7wH7J
mGW/ar9q5Nkf2h8as+1P7E+Mp+xSu9R4Wn3PajxjL7WXGs+q71mNv6rvWY3n1fesxlxvP+95xgve
872XGS96r/BeYcz3DvMOMxZ4h3uHG4XeEd4RxkLv1d5rjTe813mvM/7uvd57g1FEGF0OCzFJCuFI
EAASh6VYpD1pgWQRj07q/QIvrEileKQEnVqRlkhtsG+F8tZIiThqg2vbInXSXx+2J+2QjsW+PTmX
dEDqR5KQjicdkfqjVidyATkG6SLUOpZ0JcchnYi5Yndw1YP0BA+9SB9wdRo5HW2cgVYstHE++LkA
1hxHroA1J5ArkVrBygejf2XnbWDnI9H/1eRGXPUnJIuMIX9GDzeTcWjjVpKOVsaTyeBkCslEW/eS
+9F7FnkAvT+IlAhMeAjXzkDqA7R4mJwEvMgBXzORepBHkXoCPx4jpwJBcpF/AqkXcORJlOSR2bjq
KaSe5GmkM8kzSGcBY/LJ2UCV58g55HmkoWQO0jlAnbmkL3BmPtpfQN5EX28hnQwMWoyS98gHaOdD
4NGpwKMlyH8JVOqlUelkoNJqlH9DNqDHjUjdySZSgR5/AFqdpdGqt0ars8k+Isk5lACz+gKzOOlD
BRWEUota0IUWtAUxgVoe0o7a1CaCeqmXtKBxQDcbCNaSxNNWFKNOWwPpWgPpMM40kSaiPhLpSNtT
jDftQDuQY2gSTSLH0Y60I+lMO9FOpAs9hh5DzqPH0mPJ+fQ4ehy5kHamnckJtAvtQrrR42lPcNKL
noJ+e9PTwckZNBmtnUnPQ0l/oKoNVB0MHobQIeBhKB0KHoCw+B1BrwEn19IxqH8TvQn1/0z94OEW
eht4SKcTwEMGvRs83EOnovf76DT0+wB9CP1m02xcO51Ox7Uv0gLI5CX6EulBX6avkFOB1K+TnnQ+
XUB6Aa83kYF0M60gF9Mf6I9EYXc1uYLuoDvIlbSG1pBBdCfdSQbTIA2ifBfdhfLddDfK99A9KN9L
f8FV++g+cin9lf5KUul+up9cRn+jv5HL6QF6AOW/099RfpAeRLmkklwO38DIAGYwg1zCTGYizxlH
XjCBvMUs5OE5yOnKc5AzlOdAHp4DeXgO5OE5iP6rEWSIsd3YR1KMX01CLJOajMSZhukh7U3bbEmS
zFZma3K82cbsgHyS2Yl0VT6GdIeP6Uv6mCnm+eQ0eJrL8JtqDiTnKH9DBPzNLaSdOdYcTzqYE8yJ
pIuZYU5CfrJ5NzkBfiiT9DPvNe8lZ5tTzamks/JJ5BTlk4ihfBJpD590BX4H8StJHB/MByM/hA8h
Fh/KhxKP8lWkP3zVVTg7go8grfhIfjXy1/BrUPNafi3yo/go0kl5MtJPeTJyIjzZLfgdy8eSvnwc
H0cS+K38VtKT38ZvQz6dpyM/no8nKXwCn4AWJvKJaC2D30WO55P4ZJRP4VPAw938HuLlmTwT/d7L
p6LO/fx+tJzFs9DyND4NZ7N5Nknk0/kMXPUwfwRX5fCZaPNR/hjqP85zybH8Cf4XtDyLz8JdP8mf
xNk8ngdOZvPZKHmKP4U2n+ZPo4Vn+DNoIZ8/h2uf58+TrnwOn4PyuXwu4fwF/gJpw//G/4Y7LeAF
uPYl/hJafpm/jDqv8Fdw7Tw+Dz2+zl/HtfP5fJQv4AtR8w3+Blp4k7+Nlt/h/0TNf/F/QcKL+WLc
xXv8I3D1Mf8Ud/oZ/wK9/JsvQcmXfCnuroyvwFXlfCXkvIqvQftr+XpyLv+ObwQnm/iP4KGSb8FI
beU/kQv4Nv4zuYhX8SrwsJ3vwN3V8J1oM8iDaGEX34UWdvPdaH8P34Me9/K9qPML/wW9IM4gfVSc
gV/JJemjXBPpoaIN0gvRRgvSU3iEB+WIOcjZKuYgfRFztMFvW5GIs+1EO3Kqij9Q5zhxHH47iy4o
OV4cT7qLE0RX1On2f4m7Fjibqv3/2+ucs/fZ68yMmTEGYx6M1xjzivGaMR7jEZNXQlIhuZqLVMjt
ikKuusggV3vv8xxXKldS/678JcntIZUrJElS6YUkV5Jk/t/1m6FRSHXrv9dnlt9Ze+219t5nrfX9
fo/fWktviNIa6Y1xtqneFCkZegZKaKY3g52pZyF/to72D9bSAnla6vnUUnEXpBfqhcjZXm8Pu4Pe
GWeL9WJqrXgM7Cv1K5Gzv94fKUP0IchzrX490ofqQ6mxYjYoE8wGTzRGH4O6xuq3Ig/4De7nTn06
7Bn6vch/nz4H5czV51O+vkBfhCd19CDKDOlh6qNH9Ajscv3vuJOl+lJc9ZD+EPIs0x9G+iP6I0h5
VH+UsvTl+nJqrtgSUlbqKxE/rj+Oulbpq3DtE/oTyP+k/iRq/Kf+T8Sr9dUkFJeiWopLId6gbyC3
/rz+PHkVo6JCxaioBhjVJqqpVmJBHvAqqqt4FaUqXkUN1UosiHfr71K0Wo+FNLUeC3K+r39EafrH
+idI+VT/lHT9M/0ASf2gfhBlHtI/R54v9CO49kv9S6R/pX+FWo7rXyP/Cf0b5D+lf4c8p/UKqgfC
olGaWsuFQFoND2I0EWpo4CDN8Bpe0g3TiKJaRrQRTQ2MGCMG6TWMGuQ2Yo1YijMQKFWtAINrE4wE
lFbLqIU8iUYirq1r1EUtSUYSrk0z0pBe30hHzoZGQ5TQyMhAyc2MbOTMMXLIa+QauSTBDttRDaPA
KEL5nY2uVNPoZvRAzp5GCdU1rjD6oMy+xlWUYgwwrkbtg43rUO/1xlAqNIYZw6nIuMEYQR2NG40b
Ue9IYxSeqNQoRc4/Gn/E2dHGaKSPMcbgfsYaN6OWccY4lHyLcQtKvs24DbWPN8bjqgnGBNQLVko5
ipUiBiulFmClf6FsY5Yxi3IUN0UMboq4TJZRMzlfgsnIBXIBbPBUxOCpOAueSi0VT6V8xVOpheKp
1EbxVKS8Il9BvFluRgrYKq4CW8VVYKuIwVYpB2y1gJr6Cn2FsIt8RZTh6+DrSNm+Tr5OSOnsK6aW
vi6+LpTv6+rrSq183XzdqI3itcgDXos84LW4CryWMsFrByH9at/VSAe7xVXX+a6jPr7rfdeDU6md
3hXHLWJ2G8dcNo5ZbA1mq3HMU+OYoXZghtqRGWoiM9TOzFC7MEPtxgw1iRlqCjPUImaoLmaoceCn
eShbcdM4cNISlD8QvDOOGWcHZpwdmXEmMuPswowziRlnCnNNCf15D3iuYpxZ4Jv3wlZcsxlzzVzm
mllQp3NR3/00D/YZrrkAZxciZDPjzGXGmc2Ms2UV43wQoTXzzrbMO69h3tmOeWchBRHyKISQS2F6
CPYyhFzmo6ngo4/CXg79mwf1+zjsVQh59ARCLj1Jq2E/DZ6aC566FvYzYKu5zFaz6DmE5rQBIZOe
h15uTi8hZNLLCIrLboL9CkJzMNrNyP8qQja9Rltgb0XIArt9AynbaDve8Q4ExXR3opa3EHJpF+2B
/S5Yby5Y7/s4+yFCNrjvfjz7R/QxGPAn4MEt6TPw4GZ0kHnwYYQ29AVCazpCX8E+Tl/DPkHf4v2c
Qiig7xDa0mkw5gJNTZ0v1AR4c6Hm0lzghYo9Z1Vjz9HMnmPBnn2wFWOOhfKPYcZcE7FiybHMkqOZ
JccyS45mlhzPLDmBWXItZsmdmCUXM0vuyiy5LrPkZLDk+mDGDbQGqDddy4Dd7CxvFuDNWSg5W8vB
gJgLDh2rtQCHNsGhW4LH52v5qLGV1g52AVh1NFg1dJTWAdw6VuukdaIorbPWGenFWjHFaF20LrC7
aj1hl2hXMPPuh7i/dhXiARoYmDYIzDsazPtqlDNYG4xyrtGuhz0ULDwWLHwEzo4EF48GF/8DnnSU
dhPYdil4ebw2Brw8QbtZu5lqg52Pw7Pfok2EfTuYei1m6sVg6neCx0/RpuANTAVrrwfWfjfew3Rw
92Tm7tHM3U1tpjYT9l+0ELVXa9WBtSu+fhXz9SuYr1/FfH0A8/VBzNcHMl+/mvn6AObrg5ivD2S+
fjXz9auYr/dhvt6P+Xpf5utXMl/vw3y9H/P1vszXr2S+3ov5em/m672Yr/dmvt6L+XpvESWiwM5j
RAy1ELEiFna8iIedIBJgJ4pE2LVFbUoTySKZdJEm0hA3EU0Q54pcqiPyRT7sQlEIe7AYTP3FjeJG
xCPFSPKIm8RNiMeJcYiniCmIy0QZtIQjHGqgVrujhiIiIojLRTk1FkvFUuopHhWPwn5CPIH4SfEk
zj4jnkH+Z8WzSHlePK/2FxT/oqbiRfEi4k1iE+I3xBuId4gdiHeKnZQh3hJvwd4ldlGJ+Fh8DPtT
8RniA+IANVEr4iE+Ko4i51fiK6SfEqeou8twGVRfrYVH6a5oVzTiGFcMNXLFueKohyvNlYaUDFcG
8mS6MpGe48pBilI1g10dXR0pzTXNNY3au2a6ZiG+zzUP8bOuZxErzVMEbVMbOkepmiR3PXc9aJhk
dxPKg8JpCjsDOifPnevOpebuPHceZULzXIb0FlA+eVA+7WAXuNvDLmIV1MHdAfqno7sjtYEi6gy7
2N0Vdnd3d2rnvhzqqMDd092TNHeJewC5oZQGUrR7EPSS1329+3qKcQ91D0XKMPcwinUPh4LyQUHd
BLvUPRr2GKipWKipsVBWN0NT1YamugX2re7xsCdAX9WCvppIdd23Q2XVY5XVsZrKSnDPdM9C+fe6
78WzKMXVzHO553KKg9bqQZJVVhzrqxqevp6+sJXK6uwZCGVVA8rqaqQoNdXRM8wzDIx8uGc4WLtS
VimsmopYL8WxXkpkvVTEesnFeimOlVIcq6M4z3TPdJSp1FERK6I41kKJrHlSWPMUsdqJY7WTxGqn
iNVOHOucjqxwElnhFHmWepaitIc8D+GsUjhJrHCKWNvEsZKJY60Sx/qkA+uTjqxPElmfdGZ90oX1
STfWJ0msT1JYgaRAe5yiLM93nu8o13Pac5ryWIHkovsKMGmXjvGfdUgWSKYB2ws1kstqJKtKjUTr
0dSONUkha5JcaJKaOJsAZZLNyiRPT9QTwciVPsnT6+h1wL/r6sng4qnQJ3nQJw1wVTpUSh6rlCxW
KbmsUjJZpeSySsmDSslEmc2hUvL0XD0PZSqtksdapbneSm+NMpViydLb6WjDrFsKoVvQhlm35LFu
KdC76F2Qp6veFaV107vhKS7XeyJPiV4CBXKFfgWu6q33Rko/vR9ipXCyWeG0Y4WTywonixVOnj5M
vxEpSufk6aV6KWyldpqx2sljtZOl36bfhmcZr49HORP0CbjbifpkpJ/RP39Bzln6X2HP1mfj7Bxo
oWxooftxP/P0Miii+dBFLat00d90MBzd0m08r9JIbVkjXcMaqR1rpELWSFlnNdIy5HkYSqmAlVIu
lNJy3KHSSLn6Y/pjyLMSGimLNVIha6S2+lP6U7iHp/WnoWfW6mspFuroGTL15/TnYG/UoZxZHXVi
dRStv6y/DJXyir4Z6UoXJejb9G1I2a5vh1JSGikZGmkXcu7WdyPeo+85q5Te09+jGNZLPtZLtarp
JQG99BnKPADV5GPVFAXVdAgpn0M7+aCdvkA5Sjv59KP6UdhKQUWfVVAnoOK+gY6K1k/q36IWpaZ8
rKaiWE3VwmDsgu023BTNaiq5mpqKZjXlYzVVt5qaimUdlVBNO0UbdYw6SFfaqW417RTN2snH2ika
2ikTqqm5kQU7GzrKyzoqmnWUz8gzLoPdwmiB+2lptILdxmgDuy00VTRrKh80VR/YSk3Fs5pKYDVV
i9VUJ1ZTxaymurKaqstqKtm4ybgJVylNlcCaqpg1Vd0qTXULFFQ0K6hk43bjdtiTjEmUZdxhTKZc
teInYqWdco0FxgLoqA3GBqpjbDQ2Iv7G+JZ0r9vrRtzL25vqeF/zfkD9vR+aGnnMMeYY0s2J5kTE
G8wN1Nh8wXyBGpovmS/BfsV8hXqam83NsLeb26mBuct8my43PzQ/Qp7D5hc4e8w8hvTj5nGkfG1+
jZzfmN9QA+mVJjWV0TKaSmScjKMsmSbTkNJUNkPcXGZThlq7E2fzZSukFEgoMdlL9qJ02Uf2oUby
Snkl9ZDXymupvhwub6Ducoy8GWcnyT8hfYqcgvS75F1IuVvejfzT5XSk3COhXORfoB5z5Ww5G/Fc
eT9ipSRbQz0uRvygtKAnHWjIXGjICGylIVvKlfJxKpRrJBQE9OR6xM/LfyF+Qb5MreQmuQka8lX5
KrWX2+V2pO+VexEflAdR5hfyCLWVX8ovqZBVZWtWlVm+9r72lMsasmWVhlTqsRWrxyxfPx9GMNaQ
zXz9ff1hX+UbgPSBvsFQktf6rqW2rCGvYQ1Z6BvmuwF5/uD7AzX3lfpKqXXUgajPqWHUF1FfIP4m
6hQ1jToddZqaqrVBKT0aB6WTSM5Ra4Om7mo0BRqr6BL/u/S3PJTfBvvLVbT5+RdXTPhxeVUrL30/
02VAxQKE28+s0lmtZlFxtOKNigk/f72jik/O4x8jKv7N3iLf+1wPYJ/r4qo/tTbnWQ/U/+58hMr/
q76odxCetcoL9f1ftHKguFDpvMLfxVZ9/G945Pyyo/b/V93/jbUZL8UrCO+9an3FM95elatZnj2/
6hfVfAmzxL7Pc7bmi/pa/pZHxZLfqR79Ryl3nlmbBm899heV+f75fBEr3+6Zd1yxqvqqNlXvWZxt
2+L3beUYL+89c18/d02PiqkVU6kj/n48p2JZVYln1m8aWt1bC5/O70eo0OPt8575NceAn86C0Vzw
PvfnP0S1+MLHj89fQs2/7KiwLt6vf9y2f6K8S1mf+PxXXtSH9SeOyrWSP6vYXlX32T6gnu2nSq70
6aru2XVpR0XVXDqehS/ov4Bopy9xnsTpExUNuOYJqFuc6ekVo/jMVPVvRcmP7rayZ4lzZtapvsTX
nv6Za1TwmliX9L5+yGgugZNc6BBn12reXtVmz3njPy6T6xbn5sDVl+gBfaaGsx6Gonrqrzou5XpR
bSQ5d1Sv1tbABn5Yljj7dz4EuISaz/GoFD/PP/bXHRjnv69LPf+EinPnq4rfciZR9bJ57tlP1sWj
3UVWva3Gwy663iN0yPdjsKhYx2/9h6Ny2jlXVK5O/u6Fxu5qPOz1i9V8Ntclz6dQc8yqrzdYxUm+
94ot/vE1PziiqnKW8ui8jEs70555RML3rvzfR5/bUyt6qZbJcwEDQP5/V2SzohpU8VZlvop6nO0n
sZLnA5w5KkfOX8kVKqIuIZOo9ta4b17gmzlndrdaJ+eiuyBcSn+u/nS/DTP6+cfvx05/VE/1mdO/
72pUl6LufyrPL/r2qrOTi733830rv4p7VvFzwepE/P5r/Z1BywutkFpx9Pzvk3+xWfYrsE/177e4
5nd/Mu+51525g19QczXEan6RbL/JgTdZVvm2L4wlPzpTOfquOvfzzzz+/35H+lUHY9/b3z99tfUb
/5ur+XasKvNsK/9NZpKeT/38sAVeClKd81svr659+y+5ncqnPWdHphJwrEEV915wrlav6m+Gf/9d
8P1cKOBEZUtVK+NeeAwT5/mtt7l6Jv67pNmev5zfVrafn6VtzhxCcUvc8zvgYq9XpVQv+cWLjmFC
zVjnXLdXvfNLHLkqxBnehGtZ6YD/8/OfPlQ19/pH2HNmVDz/r6CXqp8vck9vnauvLvn4daOQ4Dlg
lXdwQWVcNQPtxYvn+nkHj0BvfW9f+A5/mZb8rY/ffw0p1SZZh/xmv8ldsOZVld/+b7MWwEVrVi1D
nMUoQbexrxeJNFGfNLUfKrnY48stMkUmeUSWyK7y/vKKlqIVmaKdKKIo0VV0pTjRW/SmeNFX9KWa
4ipxFSWIweIaqiWuFddSbTFMjKQ64iZRSqlqb1Sqz75hDcR4MZ7SxUQxkRqKP4k/USMxWUylxmK6
mEnN2GcsWywQiylH7ZNK+ew51kpExBJqLZaKh6id2i2VCtVuqVQkHhePUyf2HOssnhL/pGKxVqyj
rmK9WE+Xs/9YD/Yf6yleEi9RidgkNtMVahdV6qN2UaW+Yo94lwaL98T7NER8KD6k69l/bKj4VByk
YeKwOEo3imPiKypln7HRosLlojFqF1W6lT3HbnNFuWrQeFecK54mqb1U6Q61lypNdiW7kmmqq4Er
ne5yNXU1o2mu5q7mdA97kc1U+3TSX9Q+nfRXtUMnzVE7dNJctTcn3a/25qR5am9OKjO+8LroAW+0
N4Ee8RZ5h9Mq72jvDNrhneMtp8+9T3pPaG61Q6d2hdnGvEG7Su3Qqd1llpkPaveqHTq1+WqHTm2h
2qFTe0Dt0Kn51Q6dWlDt0KmVqx06tb+rHTq1VWqHTm29+a15SnvOrJAe7Xm1N6e2Se3NqW1We3Nq
22SybKjtVHtzanvV3pzaR7KFzNc+lh1kZ+0ztR+n9rnaj1P7Su3HqX2t9uPUvlX7cWrfqf04hab2
4xQetR+nMNR+nKJW1IGogyJR/b+2qBOtR+siWf2/tkhRe16KBmipR7ilCvZKFKI+2qub26uX26vg
9upFe80in8hGq43iVhuNVtsSLVh5LgrRCi3YjRbcDjkLRCHOthftcbYIbTqH23QbbtNZ3KbbcZsu
YE/HtuIatOwcbtlt0LKHIc9wMQJnlQdkW/aA1NgDUhOlaPEubvEGt3iNW7zBLV5yi89Gi5+MvnSn
uLPKV1ITU9EHXOgD05FzhrgHeWaiP1T6UOahPyxA/1koFqKPPSAeoBpikVhEieJv4m/oY4vRW+pz
b6nDvSWZ/Szj2c8yVSxBz2nJ3pYtxEPoPzXQfx5BrDwvk9CL/oF4BfpSMvelBO5L8dyXEtGX1qLM
Z9CjkrhHteQelcw9Kp17VD57ZDYSr4hX0D83o3c1597VuMpHc5vYRhliu9he5a/ZULwp3kSK8trM
rOa12Uq8jd7YTO1pjPhd9Mkm6JPvId6HntmUe2Y+98yG7NnZSBxA/0xXuxyjri/EEeT8UnyJkpWX
ZyZ67DGkfO/rmStAU6imi1xEMS7NpVEtl3AJqu3CQQ24P/OuyFQP/TmKYtkfNI79QVNcNdDD09gr
9DJXPPp5DPp5LcSJ6O110dvrIK6LPl+P+3xN7vO10OeboswM9Py63PPTuOfXQ89fR1HGs8az5DXW
G+thP4exwMtjQTSPBVk8FmTxWGDwWGBgLNiP+COMCNk8IggeEdwYEbqS19vN24183u7e3hTt7YMx
QucxIofHiDYYI/6Xsrxrvc9QO+8676tUwL5Bbb0fek+QpsYOcmHs6ECG2dHsRNLsbPambLOPeQN7
Dk0goUYT0jGarKYa5tPm05SkxhRKwJjyDNUx15nrqL75rLkB9vPm88iz0dyIsy+aL1I8+xilso9R
C3Oz+RrObjW3In7DfAP5t5tvwVb+RnnmbvMdSjT3mO9SsrnX3Iuz75nvoeQPzY+R8on5GbU0D5gH
kP+geRDlHzIPwf7c/By28lJqYR4xjyAFoxjK+db8lpqo3YapqdptmFrzouXNpSbd1Fh6pIeaYXQz
qaHEQRnsw9RKxshYpCtPpgwZL2tSI5kgE3Atxj6kJ8sUSpepMg3p9WUDairTZTrONpQNUXJTmVnl
85SpRkbkV55PrWS+zMdVHWQHipEdZUeqKzvJThSrdjCmmhgxu1Bt2VV2pQaym+wBu6fsiZwlsgRn
e8veFMeeUinsKXWZ7C8H4OxgORjxNfIa5MfYClv5TuXKEfJGqoURdhTSb5I3ocwxchzVk7fI2yhN
jpfjkXOCnICSJ8qJsG+Xt8NWvlaXyTvkHUjBiExqRD5AmVEHow5SMsblb2CfVF5HanQmE6Ozl9Ki
zWgf1VNjNGWQ0PLY/70V+79nsf97K/Z/b83+723Z/70N+7+3Y//31uz/3pb939uw/3s79n9vxf7v
eez/3oL93y9j//eW7P+ex/7vLdj//TL2f2/J/u/Z7P+ew/7v2ez/nsP+79ns/57Dvu3mOSii8MOo
hh/GWabTEiNvJWYob3cvI0QjUSyKKY1xIldcLi7HmKvQIp3RopDRoj2jRT6jRSMxRAxBfoUZueI6
cR3yXy+GggEp/Ehn/GjP+JFfhR9/EH8ABlRHkdFidBWW6GKsuBl2JaLcIm6FrXBFFxOAKy7GlYaM
KO5zEOVuMa0KV3TGlYaMK27GlSZiPhClEktqMJYkigeBIjXYZz9a+EUAtkKUOBESYdgKV+IYV2oy
rjRjXMmowpVlYhnQ9+Gz6FJTLAe61BCPAV1qAF1WIVae/jUZY+KAMU8j5X+BMTXY6z9arAPS1GDf
/5qMN83Ec+I5pCjUiWPUSeF5ACmMOimMOpV4kyS2iC1UV2wVW2Er7Elh7Eli1Elh1Eli1Ell1Elh
1MkUu8VucFWFN/XE+0CaJLFf7Ef8kfgIyKfwJoXxJoVnEiTzTIJkRp0koM4XqPEIsCeJsacOY08q
Y08SY08KY09j8R2wpxJ1Yhh1arncwJsYnn8Q5fK6TNgKe2JdPmBPDGNPLGNPPGNPAmNP0yrsqemq
SdKVwAhUG9gT40oC9sQAe1IQq1kLsUCgRrCbAIFieAZDlKsZcCiG5zHEMxoluLJcWUhRmBTLcxoK
eE6DabQ2WpOLUcpgfDLYz9TLfqZeY5uxjdKNHcYOxPuM90k3PjQ+RKyQqaHxqfEprj1oHER82DiM
WPmlCvZLFeyX6vUO9g4mj/cGL9CFUaqR9x7vbEpjrMr1LvEuofrev3tXUAPvY97HYK/0PgFbYVg6
Y1ghY1h7xrB89m9VGNa6CsN0xjAXY1hDYNhocrP3q2DvV4VkZUA1y7QQV+LZGnMN4rUm2iHjWSKQ
bD1s5SdbE3j2L9jKWzaOkawmI1kGe8vWNF8FnvnM183Xz0G1RHObuQ228qWNNneYb8Leae5EzrfO
ol0T8x2gXQ3GuUTzffMD2MrfNo5xrhnjnA84pxBOYVsGe+BGm1+ZXyFF+eHGsR9uTfbDjTZPmieB
yqfN04gV2imcE5Qk3UC7ekA7A7by1U1htEtitMsE2sXArgHMq80411zWkrWQkijBbGRtWQd2XSBf
bfbqTWG0ay4byyZIVx6+KYx2qTJH5iBPLjAviTEvk719U2Rb2RbltJPtkK48f1NkoSyEXSSLkF6J
iAoLY2SxLEassLAWULA77J7yCsTKUziW8S+e8a+pvAr4J+VAOfAcFKwlh8ghsJUfcZS8Tl4Peyhw
UTIuNpY3AhdjGBdryT/K0bCVl3Es42IC46IELipEVFjYlP2Oo+RUORUpyvs4lr2P49n7OIq9cePY
GzeOvXFT2Bs3hb1xY9kbNza6S3QXqsHomBTdLbobxZDm3ureSRpFUbya4Lc4Swx98JiVaQ2w1tpt
7UH2NHu1vcm6y3E7yc5IZ4azyB7nRKy8B09aqVaeNQAUv4V9HXItRY4Cp7sz0h4XLAj2D44Ozgiu
CO4JfhrSQ5mhHqEBoVGh+aFAaG1of2ht2BuuH84Ktw33Cw8KXxceEVyDa3rhmvuCK0J1Qnmh4tDY
0B2h8aGXQtsqc4YCwXmhU+FZ/qf8a+1D/uH+Df6X/Nv8u+xp/r3+/f4D/iP+4/5Tzs6ACHhV/eHl
4dWofw1qP476BwS7q9qDe1B/ILQ/uBll7gjvRt37wh8/eCyQZa0MlFgDAv0CgwKlVlRgVsCyNtjT
Aqvs1VZmYKMTscfZCwOHAqeD7mBsMDGYHMwI5vhPBboG1jnuwMLA0sA+5N4RzLfWBj4OStzBSLyD
kZGM4IpITvCFSPdI/8gk3IEeWhuJoP7R4azInnI9fF15anlmeevy9uXF5T3K48sHlA8prxNJj3wQ
2Rqur95bZF7kycin5Y0iJ0Nry8meZZeGNgS7O+nhrAcPW2S9FFqC8IgdYxXbc639Vh1rpr3KSXQy
nBX4dlZaS5z11lh8k9MQq29rhNPJbmJvsdo7bnzeZQ23s/CcO5xl1l5HWrqTb+U591l9rKesA87O
4NDgyPC04JTgrcF5wUVBB2/zteB6fKfHgidD7UOtQ8NDi/kb3RU6Ek4KT+S3mhUuCXcNl+Ib3Rrc
GZ4cXBaaHXoqeDi0NhgJNQodD74QWhnaGx6H76ZTcFJoVLhFiIKDwx2C3YNPhvqERTghPCI8N7ww
bIVDofhwk9BdoZmhA+GYUFRoCMqcEvwglIr7G2vdZQ2xvXaCXWJPxNPd5R/i5KB9TrIHOfOsQCDG
uiuQZC9Hy9jvnxlIUH+B+si3IdDE/xruZXRwSvho+ATawKrwpvDp8MaIOyLDW/zDw0vD68KHAuOC
6YGSQIdAW24RE/09Aura5YHVzkgrD+1hhmoRgS2ByYETaIXb8O8sfw/kOIp2k4q7C6A1tPDPRJ7d
gesCI+wtgZBzOIB+FJgb6VUeH9ofSYzERvJDFBkcGRkZHbk14kTWRDZH1gdHR/bgDYwoj4ocK88L
dyjvE3kh8kIoMzI0MiWyLBIpz4wsCvbC97AV731mJLm8Tnl8cEX58EhBpFPkvsiKyM7I4eD6yAwr
yopHa2htjbLGW7Ot+dZi9U37o5zN1hF/qt3P7mBP9hf7Bzhbrb32aXu3/bF91D/KcdsnnP6OYw9C
O3jSClg9nE+tmf54fx1clecMdQZbx61Tzh7nA6uRc9g55pz0k1+3xtv1/Znoia397f09/H2cNbZl
L7RDeP+zMTJMcyb5h1vb/GP9o2zLGe2/w3+Xf6Z/vvOCf7E/4F+Cs4/4Vzq32l3tUnujvc8+5MQ6
vZw11mu4ppGdZK/zj3emWHV4NFrNI9EMexxaL+EJh6AdzLbusPrge3kksCoSwRimeTQStITnkROv
WaTxmkWCZ5C7qIwC5KZl9DBGvMcQEmgNQi2ejZ3Ic69r05sIdWgvQl1eTSiJPkGoRwcRkulzhBT6
GiGVZ0KnabqWRvW1ZlomFUBz5FF7nnNcpBVqhdSB5xN35NnDnbS+Wl8q1q7U+lMXbZg2jLrxWj3d
tVKtlC7XxmpjqYc2SZtEPbUZ2kwq0R7THqPezPb7iE6iE/Vlzt+POf+V4Pw9qL8oEVfQADD/ATRI
INBQ5vzDwOHvpOHMUe8AR32V/gxeupOmgWd+QLOZVf4NfPITWsy/VljiP+I/5IAlHie/OOFyU9Cl
u+rRcleKqz5tcDV0NaQXXI1djelF8LdMeglsLZdecbd1t6XX3Z3cnWiLe5R7FP3bPc49jra6/+ye
TG+4p7in0nb3NPc0etM9030v7eQ5hbt5NuE7EEMu2sMrmezVpe6jfZBycfQBr1XyCc//+1RvpDei
z/Q2ehs6wPP2DupFehEd0rvq3elzvYfem47offX+dFwfqA+kk/o8fR59q6/QH6NT+ip9F51Ws8q0
pmpWmZahZoxpzdQsMS1TzQ/TmquZYVqWfkw/pmWr1TO0HMNt6FqumuOltTBijFStpYGgdTWuNK7U
uhljjdu17safjD9p/Yw7jSnalcbdxt3aVcZ0Y4Y2wJhp3KcNMuYY87VrjVeN17QbjC3Gm9qNxlvG
Lm2MsdvYrd1s7DH2aOOM94yPtFvATg9rk7yLvYu1qd5vvN9od5mpZqp2tznCHKFNM09KoU0HX4rV
Zivlrz0ILpSk2VD7qVoYar++FpGNZCOtXGbIDG0J2E6u9nd5mWypLZWt5WDtYTCQYdpmKPAR2lY5
Uo7U3pClslTbJsfKsdp2pbq1HdDbZdqbcqFcqB2Ri6Vf+1ICwrSvZVgu1U7Ih+XD2mm5XP5Dq5CP
yVVCk0/Jp4RHrpb/K3T5jFwnpFr1QkTJl+XLIlq+Lj8XMfILeVTkymPypGip5iSJAl8HX3dR6Ovh
6yG6+kp8fUQ3NetIlPgG+q4RV/iu9Q0T/Xw3+EaKgb5RvlHiGl+p749iCLhKN+hUTfSHplQsJZ08
RPfP+uGfVttaZW18YKi12zpkx87Pt/PL1i0otkc+MMVeZEfsrfZJe6uTWrbFyXOKnSHOcGeUM9a5
A9eswzWbrEMLetj97aHIPcW+1f7AHoycrZ1ie5m1yYl3FquyF/RwHrEOOXfY+c5LZevskdZqVfKi
sSh3l33SOo2S9y5ch3IPOEesVc5KZ0PZ0gWtnf1+gat3WBv9Wf4S65C/n3XCX4pPc3F1fuW1Dwx1
8vwnFsU7owKJgfRAfqAg0CnQPdArMNjaFBjp7+rf7d9StkU9j9/yL/XvCyT7j9o7F7S299i40l5v
v2BvtrZYO5z5qGm3temB7tY+66j9qbXRjrXT7Qx7sLXDHmk7eA877cOO7mQ6M/l+85wBTh9nvHOX
7balM3tRD+tj+z57sL3CftJOtrfy5+52JyfKOoE6juF9HVI12JOc9nYO3kwPazXedoFTx2nkjMXT
zLBjHXJS7QJ7tHq3diLuZY89z16DuJe984Gh/hi/15/g7EW+bf4k5zV/fX+T+flOwHnKOe4scdY6
p/ylznz/Rn9bu8A/CG9qnH+af7J/Fj4t96/zr0YJO5yx/tMBt/9QICOQE+jvX+VfVbbOP9E/15lt
5wfS7UXWusBQPM9Ofwt/h0BsQAZGB271X+cf4V/oD/k3+T+2Ns5f4+wCGnjAfLcSube5t4EF73Dv
IOHeCS7scu9y7wJCCOqIOAUY0pQygAA5CMm8vkkKtUNIxfmOlEY9qCfVp94I6dSX+lFDuh6hMa+3
14RGITSl0QgZNBGhGU2jGZSprdBWULZIFm0oR7QTBVTCv/z3EmXiQYz3tliJsXyV+B8aK1aL1XSr
WCPW0G3iGfEsjRfPiY10O0SUpD+7493xNJnnvd/pnu6+h6Z4unhG092eSZ5J9LDnz54/0yOeKZ6p
9Kjnbs90+gevvLXSs8DzAD3OK2w96fF7Hqb/8azzrKMNniOeb+h5/W39bXpVf0d/h17T39Xfpdf1
I/oR2qL/R/8P/dt4Bsp7q/Ev4xXayRr6XW+GN4P2snp+jxXtPnOWOYveZ0X7ARTtVvoQ6vMtOm3u
NndrbnOPuUfzmPvMfZpu7jf3a4b67VTzmp+b32im0ihaInp8d9GHe3yi+v/Bvy5Sf1rt+zfNmWQt
AbPdNm/ovGXW8blRZQPmLgZLaAFGMwhccJAVmDO07Aj4x3LwiVX3N5nnvn8T+M8ScNpt1qm5UeCM
SdbeeRnIXVqVs4P1FHjKOlX24oVQO9vmua3j9qC5UXMX37+JSz6E3OvsidZe5D/tSHDsWCcR57aA
Oe2zj4KTZKCWwJxJc/o7Bda2+THWLqeXPcs6ZbdQJYFRTbSWlB2Z39WJxbUvOJudnQjgUWXFzjK7
1Dk8Z7Azz1k2Z6h6HmcS+OUK3NMWXLke6soqO2KtLNuPp15sBcqKrUf4adbC1u0R1i5+Ewfm7FT3
C5ak3sM4e7I9F2wJ94s7XmqHrAN4pv3zp5WttDZYL9n1oQK62iVlffC+1GcvdBxKKtu/uAT5tuFZ
lqhrrSNzJtkL8Wnb/7H39WFtZPe5M6ORhBXWocShhCXEpVzqEkoJIcRLiENZQghhiUu5rtehxCV8
CF2WlfVlrxAjIUuj+ZI0GmlGglDielkvYYnjEi5hKZcSSilxHEJcr0sIIQ5hCaEu4RJKqS/X6e/M
/pE+97n/3nvb++zOc/AOOmfmd34fZ973fQ6acAPMZiCYC7PJgMMG2PBQUKDvcKhJyErc68vvOw8/
T8L1bqr2Dfc9DTWBD7P6tgCZF/cd9c2JUn8mcJAH/dn9teGKPhtfDyyjHDxV39/URwOCO+xn+m/0
x5CngrnBXPDUJHhquX8bfBMSkgF9HvdNQ6+74FUR7N3su8DXh5qCGRDnxf6N/ipF6jf3u4KnAbuu
9Jv6+yF/CKjslXdr+f9tLevMST5Uy/gY1gGQfPHd9u+7EU3MYcAsjzCH8r4sMAN8FnNNnqOXlHLm
WHEoF+U7ioOxwKeDqJc4z+0qJDOgGKBHlVLLHMtCXIkPx2fj9+OHidOJ/ERlojHRlXAmPAkpMRhX
EnOAU6YTW4l9QBaGvpT4cF9aXyaMuQljVmBMDfQ3Qm864Ykj9KX2hJErgKQGOcZ/GE+Op4rz9GJg
jPYwA+xS1OE/ps/H02mPciNgjmf11cI16/suxg/7MhOVcI3GhLOvCd29rwXOKsGCk4CRCvrM0M/R
54otyCPxQmhlzCZzzNridfGG6BgzIAt8FsxxX3HId5hj7mGcgoOTa/h0Zie2KQ3GS+Jt9BL0voxm
zQzAvUXmMG6J+2A2U3DtWN8tsGE0kdQ3CRjqIVgA1vQdJObis4n9/uT+9PgwIKYYIKgcwGWFgDrL
+h4C8rwB1j2BeYPf+tbA3v3+rH5dXOlPZQaYY5jBkVKe2PfvyBI7AX6FQ5yXhziH/IDPkgUlRSlV
ylGM5Gm6mbZJNcwhxCcG5yPwabn8WMkMmOklxkLnS+fEUuaakq2E5CWlOMBAjC2Ki5uU59hF5UZ8
PD7VVxC/F1+AuKzHN+PHiZEEATEtSpxNNCOvJhJqRCcART/qy0ZeBcvJxFNAn5mJU4mMvjPxvYSQ
GErkg0d2EhcAqSbBqGmI9yH8ZhaivJ84F7+dOIoPQORt8YHECGRDMaDI8r4qmPljlAUQr2n4fyeM
upfITZznJqUaqYY1yo/kLfkp8rw8p8SUcm400CINKl6pkp6L57B34nl8VtTBbXOZqNETyHu0kV5E
d4ZZQYMcqIeIeBMSYN9Qnyme2lebqOxzxav5LD6LNYa7UE6wtlg1txYdk/NlIVr+TkagnIh3cg/p
Ca42thM1QxZcio7Fr8Ub5EGwrpIZoM+DhXfYB/EKOOqiY/SivB8vjN3um+kvAf/EAJOjzAD8Dm0Z
7rrRd9C3jTIDPJAGmYH1xeK347N9u327iUY1fyqhVywhxW9CHE6B3THoMQw9qwHbj8EBuYLGJ4i+
h8w1qNAE2HoHPDXHzkVdEOlDZZKroi8od8FrUNuBGWVb6VcKlAJ5jsumndI5eol2MskKozyBCrdI
lYF+OolOUmaUeciLh0oTVP+qvMralFtyrjLqh1phKGVMnhDnJWfUAT3WlA05wc7FRHYwaopx0iD4
fMB/SM8pXmXXv6O0KKaAWTlQssE356D/aEyEesbiOsUsH8WSlTTWqJxhdpR6uP+KvKgsy1vR0lgO
t4ZWo+gY5DdaiVA9WmQJfjeizs7ITTLHUqUs9B3A0/4ifge/g2H4OD6O4fgkPokR+DQ+jWnwb+Hf
wkj8b/C/wbT4t/FvYzr8u/h3MT3+ffz7WBL+Fv4WdgL/Af4DzIA/wh9h7yFogsaSCYZgsGc0RZoi
7KRmVbOKvVezplnDUjTrmnXsNzSPNI+wVM2GZgN7n2ZTs4md0mxptrD3a7Y121iaZkezg/0m+Sr5
KpZOvka+hn2AfJ18Hcsgv0p+FXuWfIN8A8skv0Z+Dfsg+RfkX2BZ5DfIb2AfIt8k38ROkz8if4T9
Fvlj8sdYNvkT8ifYb5M/JX+K5ZBvk29j/4n8GfkzLJd8TD7GfofcJXexM+QeuYf9LvlP5D9heeQ/
k/+MfZj8F/JfsHzyV+SvsN/Twn9YgTZVm4r9vvaU9hRWqE3TpmEf0aZr07EibYY2A/uoNlObiRVr
s7RZ2Me0p7WnsRJttjYb+7g2R5uDndXmanOx57RntGewUm2eNg/7hDZfm4+VaQu0BdgntR/RfgQ7
p/2o9qPYp7Qf034MK9d+XPtx7A+0z2mfwyq0n9B+Ante+0ntJ7FKbbm2HPu0XtJLWJU+po9hn9Er
egWr1if0Ceyz+n79l7Ea/Z/p/wyr1X9F/xXsBf2f6/8cq9O/qn8V+7z+Nf1r2Hn96/pR7A/1t/Vv
Yn+c/P3k72NfSv675L/DWpLfSn4La03+++S/x9qSf5D8A6w9+YfJP8SM7yqC/xtFcAF7hVgkvoN1
q7qgW9UFWVUXjKm6oKzqgnHil8Qh1veuIviuIvjvSRHUdekcv9YHXrGhpvlwWAnfDA+Hb1M1PcfM
QXjT7RCTeK94OrzJ+nqyxGYh3T0pdjFr3IjoYbaZMXcoPBAeD++IBPQ61T3B+sQasSs83pMlLVCE
p0wc8hRGT7pviEt8sb8+eqHntjAclaJ3+OLoorgYXonuR4+iT2Np0ro4Ig65b0h14oOeElESH4lH
rhj0pd1NkWy5Wr5ECX5vT3os5j7gzvse+NPCh7Io+eRhqVBecBW4zcJ9+Z4rRV4RR+R1T6Hc0NPA
5sk+0Rgelzl5WL4t3O9pkO53T3efCyvUaoThTnowsH4zcgvNMTIaGQtvCsnMQc+4kC5gYpenkL3E
bEfusqlhxUVGbrgPIjOR+ciyOBJZ4/ZjTGQjVhALeUqo/VgsQkbqY/2xW8Kw+Dg25urvHqQtscnI
dmwmshubR9a7i93lPemuZe68fFN85E+T65D11COwH2bAzwj33S53kzgi1MnHYUXSUatSsgeTUsP3
pSxJJ+Ug696xLTwsXZLaPA3cRPdj7rTkkzg4F6H/QPdj6Wak1n2XzXJPuh3MhlQmXWY72QrJIi0w
y+FjvthT6DuK1sQ2/A97bscO+F1hODIflTxlVJGsk8ajR3KqnC7nxJblPLlQLpGSI/1yGV8s5MkV
4lJsV8bcN9zlwrC7yTUvLkVPiotyjlwN/r+kJPWkK6eU00q+vKmclUWY5TBHSIWUINxXGpVmcYTf
VYxKF/U0MgmRHFRsfL1ykjotXXKbfQ/cu0yxcl5okIfZBrFStEkD9ICnTRh2bUgrgXPiRPSUPCDf
9Fz2T4o0nwLZOc4fhKdc5e41dwHk6Lq7FEVQzBXPieepoZ688AqKn/uu6OTXIMIrwn1mJjwbXqDv
Qwbni0VUEjpzXwwfio3h++IFyPnh7kdiV0AK32TWwopoZMDbvJf3urJ7KsSTwjW+KrwnCnAkhMs9
A1Fb9Gx0hEnjiyP1USGS2b3lwWKGWFo0qftIvBMxRNI8WeCdO7EUapqdjZRHJzxl0XxPmb8+Rrpd
0aKIyZ0dMfc0wPUg46EO9qV7PZfEVf6htMlekhT+onxZKoyZ5TZ3Wk9DQPJv99yk9t0z3EnZIlM9
ebFtWYGMHg8IPdW8CXJnWL7fsyMNeArdBmY5sCV3hu+Fj8UMKkM8S1W+cxY+lme7H7ln5GruTs9h
d6N8TXzseijX8QXyulTIrosZTJrbHB6PVMlTTFrEAPeO0WWiJG2KQ/6YJ8s3IU6Lc9HTruxojTtF
3Io2C8PSjrjYs8Ms81XSMesLD6PY8CmewkiIu8MtRiYjD8Ukbl8Y7smCGrkbW46N8U3iBGpQGQ9j
o5GD2I3IEwmThylBbkPN7ZI32cu0Rd5TCPkw4orE/P2xUKRc3uHORryRfm4a8rxBSpbSIRf2uSJX
tlQh1UnVUqfUyZ2SKElhp9wOqUQqDA8IdeEVyP1rUF+3e8alPP4MdTKy7C7oKXORUYlO9h35H8a2
pSlpky9nOTlZTu62yVnuG0zIXy+te7KkY2FYgPVLmo2tQXvSs8lSvgk/I18KH8PDJQNqJVUp6llg
0pQa6qS8Lq8rF6Jd7E0lw/dAbnAfuA3ycMwhtEmUkqucUyrdy3K6e6b7vD8m3ecPPFkiDZbvSHvi
dHdjLDN6TlyUGsTH4tOoMVYVq41lR0pZUciLTkfnuEdSW/QB+POibyJKiHSkKlIrzkUc4lH4PqxB
xdFz1GLkTKQAfcIucFvUVnQ1QopHkZZIU7QyUs63hJXYGfdB+Bj8cls6jJ6PlUaLYuX+ye7KSCjq
7MGiHvdGzATzHZbaYvXCgifLtRF9FN2KpMQuxppiLR7MNcotxcwxR8wltTF3Y97oY3EwkBRtjHZF
B3vyuvejS5DzGdHcSDHMazOaoJIYF6zxQ65sv8lvUnXEWfJb8KR5AEgR/W3ZScB7J9T3VH5A1REz
VAXxWeyzcGSqCuIHVQUxS1UQT6sK4m+p2mE21gvY87cBefLqd5jL2O9hcUCgJYA/X8fKsNvY17FP
YjNwfArw5yJWriLQCvU9N89j38OWsUoVjVapaPQzKhqtxkn8JCDEFECdDXgeoM4WFW+2qkizDf8c
IM12FWkaVaTZoSLN/6IizU4VY76EXwd02YWPAro0q1qmRdUyQ0QZoEsR0OXnAAm+QJzHvkLUA5Z8
VcWSI0SYkLA5IkbEsQVV6byrKp2PVKVzU9U43yZmAWluq0jzF4A0N7BfIoyJn0AYEzegXYx4MiDN
/44/QxwQv8JTAECTeCYgzd/AT2vep3kWz0d4E/8Ywpv4cwhp4qWa39P8Pv5JpJvi5Ug3xf8AoU68
AqFO/HmEOvFKhDrxTwPe9OBVgDR9+OdImqTxWu3z2hfwF7Sf1zbgF7UXtI14k7ZJa8Jbkc6KW5DC
iluRworbkcKKX0PvJsFf0X5ZexN3am9pX8e9SGHFfdo97T7u1x5o/wlntP+s/RXOAXrV4VFdks6A
J3TJupP4l3UpulP4IEKv+KsIveJD6Htr8dcQesVv6Up1pfjr6Ftn8WH0TbP4V3W1uhfwUfQGMPy2
rkH3In5H9wXdF/AJ3Rd1X8S/qevUdeKTCM/ib+re0I3iU+jbWfFp3V/oZvEZ3Zzub/El3bd138Mf
6L6v+xH+QxXbbqN3SOA/B1R7gP+Dimd30fsh8F8Akn0/vqf/AODZIxXJPgUk24X/Sm/WXyEIvVV/
lSD1r+h9xAn0DZ/E+/WMniHS9IJeJH4TKcdEpv6v9X9LZOu/rf8e8Tv67+t/SBTo1/XrxHP6R/q3
iVJAso+JcrTnkvg0UpeJKqQuE59B6jJRjRAu8VmEcIkahHCJzyGES9Qi1Zl4AanORB1SnYnPn/jm
iTeJ82gfJPFHJ2ZOzBMNJ/72xCLxBbTfkfiTE/dOLBFNaKcj8acn3jrxFtGMdjQSX0L6NNGC9Gmi
FenTRBvSp4n2E784sU8YTxycOCI6Tzw58T+JK2hvImFHe/AJhwFIB+E0JBmSiG7DewzJhAvtRyQo
Q4ohlXAbnjU8S3gR1iauI6xN+BDWJvwIaxO04aOGEiJgOGsoI3j0l0eEiPYOEjHDpw01hIx2DRJf
NnzecJ4YMNQb6olBQ4PhAvEVtF+QuInwOPEqwuPEEMLjxGsIjxO3DFcNTuJ1g8vgId4weA0ccccg
GETiTcDmUWLGIBsUYtbQZxgk5gw3DK8Si4DKv0bcM9wBJL4MSPxbxKrhrwGJ/0RF4j81fNvwXWLT
8D3DCvFzwyog8V8CEi/TnAIk/rzmN9/z6fdUaT4IeLxO8yH1bWm56H0Smt955vlnPq05A2ugBXP+
GnF3vdMMcJaJ5cBKVoSdhbWqCqvDGjDiyji7gGleWbMkuMdwdos7xjRXbnCb3A5GvLLAHWAa30WL
KzAGn3HsAHzm66nmHsCZiw1hGk9tTym38G9WXY36VioMv4m/hhH4MP4GpsNwco08Uu3JQt8w+pLl
3zaiiS0yr1DzniLugE/lc8w7TsmaRT3hG/hUXws/QM34WlyzbFFgA/XyMdxMYJvP4cugxyW+DUZk
CQ+ELeEoaAgWBOuDTUFXMBbsD94KjgXng8vB3VBqKC/YEqoI1QUfhtpCnSFL6FrIB2MewZgUGOOF
/jeg92TQDL2xd3rCyJRQTmhAIIQk84plw0lQJuGki+NzuBBbJJyijdYpIeNKknBayEX3D9aHZoMF
IV/QFboH17slrKK796L7r4dSg1WhutBmaAfuvRc6hPHnKBc1L9R4FvlUrp/fEWyCE+aUat4xr3AH
vhZqhhv1X+J1wkRPkjB3fdB8z6Ww+0IleOCJ0CV0wagYnyMMCUueImFEmAYL9oWtkBjcCBaETwXL
PY/C+eFzYIEruBvuCqUKR6G68FB4JGQJT4cXww/Cq+FH4a2QEiTDj8P74ZNhOuwMVSC/hWvCjWEh
PBceDO72xtzDPUfBg1AD3xCqe2Wd66eKwTNrwYcQhRt8HvfQKQR2uTU1VsOuWe6uddZlQZHkc6yc
a5aav5LEX+6e5KuR3a5Z5pL1PrfrlJxGTwa3zNexRXyDa5ZXzHmWNfMA+PKxsI9sEp5CXNKCmcHi
4JNgKcTUBJHpR14N3lUjqgulh8p6HapX60KXQ5dCFHi+NlgLHjgTnAluB1uCu8HsYCiUFSwPboSS
Q1ywAHx0FByD2Dp6D4IPIT4Fwf5QYagEsuFmb1NoOHQbYlcNWTAJ8WoBz43CNcngxSBjzqPmubEr
T+lcbpvXoRy1ZvUM8Q3c6JUEL/pazJ3mFfOKkC8U+SFPLcXvHMJZPoc99XKMMgV34c4kapADU6EV
uNv9MOE9vH7BshEaDy2EjoULwiKKvbsO5YSaEc2CU6AFSRDeyQiUE8Kg/5Jwx1/iLxEa+R2mGnqc
E2yBDWre3An3SphXrAvQ67x1RzAKHrhWghtjOsO5IQVqQAwnhTOC5eGi8NlwPsqMcHPYFlxDmQEe
uBa+E05AZiwFzWFj2BiMQb9z4fPQazE4LzyCONSC30W4ykTIcv1c+Ch8OlgargxfCHvCUrC0N8Zd
ZIveqWPuFsxgkpvhdiEPVjiDR/LF+GTuib/BXcH7+CnzlH/FmmW1ePL9l6gnnnzewt9k8yEPbps7
qRRepFr4dSqTMvGbPMVf49a4DX6WX4BZeq3p/H2q1EZQLh9D32FP85vXBX6H8vL3fP18IV/CV1wf
hCrK8WT4L7GnXTvuMraS93ky+D3+8ArBj3sGeyT4mcEfM508x2N8Op/lGWQfeBJ8JzVPFffYro9w
265DrsnfSSeh1ci8g1Yi5HvI7n62COUBzG7UnAcVOM+nhrtgxSO1SdokDNMatAYM1z6jfQYjtO/V
vhfTvKtkvqtkvqtk/v+kZCbdO1Go4pg5YIJYy8h/tEaStNR+2VRir2/n6C0vZzvb5ghkW/esO/Z5
Z5GVsl0INJmyjCPuWfsZx7j1frtob7Jv0wnPKj3Ue5FeDZCBtECmdcd7zbpjpbybAYd7NsAEynsv
2pqNi47N9grHpscYuMUmtU4H1gK71or2cRdmolyd7By7ZB/riHUctIvOZsee3ctlmnRskt3MnnJs
OjbZIhixAWO20RjnUPt4dyl7x77GVnYUB251HHTcYtbZofYSJq91yTZoomwZrUumvY6xbtK1zqd3
mC1mPs89a1xqr+MvWw+vLHka2zuNI90F9m1no72Fu+usZIc6XNxdWPWT+VSL2TQLIyr4at7iaWRz
+cIOV/sl6712DPnHWkZLtiL7tu2slWpzWI9pCXnHlmGl7KTtQnude9Z022ZrFwHPpNOSZ5+pYxrs
a5ZJ5rLpEtN5NZ+rtdY51hlLIGRKtzWblbb+9obAdls9c83V2XGDa2pd4locO231V7YYij3F+Bx7
aE7GGlND65K9pZt0lLjWO8y8gmZk2jEu9Ta11zkaPI2eRvuofdthaVdoqWMS2ckM24pM1+wuZsqU
xcza55HFzIrtgqnEPQteyAUbNz2Npms9BHPowqw6i5k5di62V4CntowjKPbealuue5bZQfF0jNsS
ttN211WC83qMV08aJ4xLHVVXT1/NtfpcnSaKnWuvcGFcJkvYvcYl0/DV83A02jPBxmnbhMV8NQlm
f7btRk9jYBdGFbVucTP2Jldne0V7Xc8DNgmsSm5duppvG2yd5m+3LvHj7dXWe84l7x6f100al5xH
7XUmytNo7OqFuLU+gl6H/KHjNrdhrb5KePccimkYPl26soRibk/rJj2N/B69D1H3BW5BdM7AvUQ4
6wy42CNmr3Xa3uIccg6xjaa6QK2pjt7iS+gtyLJbV3M7JjvSHD56BLJ6omO0vdNKdWzTj70cfeRa
h5jvBUpRPQQu2tMCZmcjinnAZUzYz6B6sJiNI+Zjeo5eCpwJFHjmrONeLlBPT9OLAYOrhD6yuwK1
3stQN6v0IH3Hey3gNQ23X7afoSX6USA70GLKsjfRT8HjO1BvJojZHkTVB/MYQZXgyXdcNi6xE4Fb
gVv2W+yctcK80N7ADrHTTI4jmT1yDqmVc4E931YV6Geyrp+1ZLJJ7EignzsTiLVf4krZIiaZTXAk
66En2AfsabaSK2h9yp4NHLA0u0TVctmBu23FJs41ZZx4ucmsoLtC9T3siLU52JPs09ZpawVX7Gw2
cfZYR7/Dwj28mu9ppCYdClTQRtuZjsy2WEcBt9sxxh1cWUS5alX4QuMSXwc8oLOtCuUqf812wdaM
aq89p72sdZXb9qbzOYFivixQ1THGKJ6z9ANeF0jhL7VX8yWuY97H3eWWuTWoSorabZ1u74QqWeaz
+DbbKWejObWtmBftk9yTK0uocqHK27pJqBEOrNqxZDo2TRxU255j05JpyQwsB5bZ5u5yp2CfbHPY
l9khWH9WHW2BycAke9ThbS+xmB0NbI111lTi8KnttrXMOttWfzW3dYtps6dczW+LOQ5tzR1exzE7
xzWZpjp2UWMozsSOMByjMCJnDuwyCncRKoGiJlGD3KwxLrkhmx3r/IBpFlaRs9Z0rr51qZtENYvO
zBarznYBKvem6RpzG6oWKrfDYTtrmWFWnEX0UMAFGdbULl4/CSuYaG1wY8x9qFMTM8vcs51l9uzz
sBaPWMxQ5wNwrLeLlou9820MM+6ttl5Gdd+xzSxwMdMeO9dRyrmunuRCHVW2DFgzb1t9tqcmyprK
jQE+z+Qy7d6r50zDbUzrlimLYxiM6+dGuVvc/NVcs2I3Q1bVuDo5B9vMpXXcsm/bt6+eguO01dfW
b5+HNeJG9661ur0OqnSYH+ennEu05FwyQyXz951HxiLA79ecjZAB27bG1mmIEMWv8OtQubNQ7/fg
uMnnOStN6e05kDk34diBykrx7rkL3YWottFKYHfxC+DTRbuJzbB7LZnw/IhZ6yCLkxycKZ3tQlnr
GDB6mFQmHeIswRNCdEw5OpkKB2acYx+zqx0HbbWWFLZSjf1WYCYwwxkce44dxz2ugCtna9q8sGpV
s7m95a2rravGJYcSeMIKjuFAKBBCn9ETgRv0hKOQKWRKHHmBsfY2yB/xaj5rY20dVY5rtiMH1Qqr
pPG8w2dnWCdXZa12DDtuO8btpo4YZJDZWmZrtJhdna7O1kXIqgbHLHijxFHGpMPTcsF+0FHqWLen
wBjK1ty66LjvWHFU2DIcm4FR+13rOpPHPrI/Yfc7nph0AQdrZMocN+2T7KL10HQb2YietQzG6FwY
OwjP2FU0Uy6FS+MK7C3GxUAIWNk5eIaWBjbY/MB8u8jWMCsmyom+MTwFX8PXMAz/Mf5jDNc81jzG
CPK/kpOYhvxL8q8wPTlHLmHJ5A/INewD5M/Jf8A+SO6Tv8ROk/+DfIplazVaEstVmc8ZbaG2EPtd
7ae0n8LytBXaCuzD+in9FJYP90j8H9rLO4DlqdzpM8Ccvg6jEXeqVZX4F7AFbBGrUxnUH6pKfL2q
xP+Ryqb+s8qmLqhs6o9VNnUR+zmwqRdVNtWosqk/ATb1IaxJ5VHdKo/qUXkUpfIot8qjPCqP6lV5
1HWVR/lUHkWrPCqg8ihG5VGsyqM4lUfxqmYfUjV7UdXsR4ky4Ei3VY70HXUX8k9Vbf4x0uZxAmnz
uA7tQsb1SKHHk4i/Ir6Dvwdp83g6sKaf4QWqKl+EvlsA/6iqzRcTv9SQ+McRa8I/q+rxX1T1+C8h
1oS3qKp8K2JNuFHzQPMA71S1+ZdUbb5L1eZfVrV5s6rNX1G1eQt5jXTiVuBRDO5Ae53x66oG/wba
64yPqkr811Ql/uuqEj+G9jrj30B7nfEJtNcZ/6aqxM9r93Sn8L9RVfYdVWX/B8Ss8Meq1v6Pqta+
q3tO9wn8F4hf4fu653Uv4r9EyjphQMo68R6krBPJupd1LxPPIJZFnNS9ofsR8V7EqYgKxKmI55GO
TlQiHZ2oQmyK+CxiU0QNYlPEC4hNEXWITRFfRGyKuAxsSiT+VFXKaf1f698mBMSIiK+rWviEqoV/
U9XCJ1Ut/E1VC59StfC/VLXwaVUL/2+qFj6jauF/hXZgE7NoBzbxQ1Xh/omqcG+oCvdPVYV7E+3A
Jt4+8Y+G9xFbwKme1TyDOJXmFOJUmvcjTqVJQ5xKg/46/vc16cCpLmo+gNiU5g8Qm9J8BrEpTTVi
U5rPIjalqUFsSvM5YFNPNLXAeao094HtdGh+jLRhEsdw/Cw+8GsO88db/+HaM7CGZEP9F2Il2Dms
Euq+HruEXcaMWBdGOBfcmZjGOevOdGfD2aT7LPwcc+fD70bdSe5TcDbkLoGzQXcO/Es4FXcxnInu
NPiXcDIvc5iG2qPWqUM4c1LoWjbqiRv7v7Re4uq7YOEm2qe607/+K7oL5f9rI/7Rw1G02UsNeaaa
j3szqMddhZZ9mMWZXueljJdze1c7p3v3X9z0Fpi3vf2eHe+Yd7KF9HCeAbPXyjhFzxR11FXYVUg9
6u1yF7ir3E0Xmd47vUsvblJLX0ryVnnrzdsv1b50ixJ8q759v8Gf6S/1m/wOf8g/6p/3L/s36FQ6
iy6hL9MUzdED9E16nL5H36dX6HV6B8Y8hjHZMKYf+s/4t/1P/Lt0GV0HPYehZ5Y/m74WOHld9CR7
Uq8rnvTrA56sP33oyfHkXb95fdhT+NLk9XFPyZVCb+h6xctO6pHl7Euj16c8ZddnPRXXF5BNgaLA
OX8pveMPBWrgHsu+LWRR4AJdEmimL/sv0jcDXQEbvRJwBjww70vXD5vvmQ2eKd9J3ylfrq/IV+M7
77vwcq7P2Ltq9trKvJOey96xly76Es2XfUO+Ed8d34Rvzrfke9B8z9Pm63pxE3n4C/2956kjn9HT
2TvoEzyWrkLw/VMYseonwaaRwKK/NLDkr/ffCOwzKXSqP0SX+OfBHgN9k2GYfvAPxUwy88xdZpl5
yKwxu8wTFgvMMWamhR5AvmXOMFWMgxljvHQZE4PYJrxmuoKe8hbQNz0+j9h8DL/Lp3PgyOsqbL5H
CejonHaKvRMvn2w+viL2PobsL3fPvxRrHHd7vWe8xe5+77z3Yde93iTvRlvXxbUuynO/F7Kkrct7
lxpx34XMmHIX99Le2uZ092jzsOf2i5stZG+lZ8Gd0muETDryzlBb7uXeGveu+8D9xINRglOk9qnH
L266L3o4b7mbdGe3kN4bPfd6T/We9z7xPfWTgSR/mpoFZ/wF/iq62l+rZpDXP+kf86/R6ZA/ZXQD
3Ukr9DGKFxzX/pW9rwFqI7vz7BYSMDLnJYQQQhiGYUAImZH5EDIIIWOM+QrGQmYYEJL4EnSrW2Kw
EI0DErRarZZCuQjxcg5LOMJ6CcX6KIpwhHI4Qrm8HOvTsV5CCCGEsCxLvCwhhHU4wnEUudc9m5nd
urq5j7qrSl25XnW3/t2vW+/9P97/p3+/9xezyOwyR26D2+jhuWVMEJPktgMOytyjjBVwdYHRMidu
Bb3tDnYfMxNuL33KPKNfubPdPoZmepktT6gnwhPtEQG+DzIQ4880Mt3uPvca0JMwd7N7uPOhY6lz
pL3XpCNXyF3HfovYmd4ldJY7dV3FjnDnQ+eQ87WrpHYT2ICCIrTPqR5q1KgBOrrkWge6uevabzpy
5TQdNRS4VlxbQB+P7iWRBa4JssQ6Y31NlrnGGCXoc5jngech0L90j87T71F7hjwjHrR2zZPoyfUw
dCI9V7dI81znnC6m0CryPp1Ll9O6j9rpOlYXaZJmqKkqL91PD3Ue0IGgpGtngNaW00O0uktMDtIv
jBrnELpC86gp+iEYBTrpCDq68sRZR9vodnK3Ysdz4N3zGjwznknPqmfDc+o59fK9QnefV+at8Baz
+shseXu8w167dx6c2/FqvBr3uOfCG+ZVAPqpV0ofeI/dBkYJtHrOO+4d/Zr/14I8255X3hhvthfz
NruLvZHkI2sEckyOkUvkOnlEnpDnTtQZ7QqnDu+NdV5Y+iyGLk2XostYp723ro2oevrRQ+q4a5QK
6yKoSOdrik8Fu2rAmLPauUEF1weiK5SBGu/adFmBLi0bNRU75qaueXKa9HfWkfuuKFfsvSSnraqv
y1uV3TXV9bRzrnOm8zmFdfV09VFGZLML62ru2uva0d1vLHdBdRLysctfG2oZdQW5Qpy8piRXkkte
eeRSNia6cqoI53PnnPOFc9V13znifOIqcJW5tBXNxmXKTlFddlejy4zMuzq71qg9a5GL/kgEanSD
Fno7+zsnO184SecD5yvnBSWkYqgKatOZ4lR1DbskzjrntktC9XUOdY4ASxX9fkwGdcF43LlNDVBT
wN56rRFgFH5G7gKubTUlOZbMG817zss06l7gVrz+Nf+vIYj/Q/4PIZj/I/6PgK/5Mf/HwNf8hP8T
bsWrGXJBbN5bFgVHcCg4kkPB73AoOJpDwe9yKDiWQ8FxHAoWcShYzKHgBA4FSzgUfIVDwYkcCr7K
oeAkDgUncyi4hEPBag4Fl3IoWMOh4LscCi7jUHA5h4I/5FBwJYeCtRwKruJQsI5DwXoOBRu4twm1
vCyAfOs45NvJ+wvef4IecTNOvs2iWuh7XMas73MZs2ZZVAv9exbVQvPcu4Bl7l3AK+5dwD73LuCX
3LuAA+5dwK9ZVAv9hnsjcMy9EfjP3BuBE+6NwG+5NwKn7FwT6IxP873Q7wRnAJPyOUz6DodJozlM
+i6HSWM4TPoeh0ljOUwaz2FSMTfb4zo32yObm+1xg8WkcA435+MmwKTrcC4X87dyMf8WLuZv42L+
rVzMn+Bi/m1czP8+F/P/Khfzb+di/g4u5t/Jxfy/zsX8e1mUCn8jwBfwC3iGi9ivcBH7n3IR+w0u
Yv8zLmK/+daZ8PPwz1lECf+Wi9JfcFH633FzICBuDgTMIkoej0WUPD8WUfKucDMbkrmZDSnczIZU
bmaDjEWUvDQWUfLkLKLkzbGIkvcfuaj4LwFK6YdmP8Uqt/v+u+0zEZtWRhZBfqS6dJgsh3iml+gS
OBdNaiE/bUTpA7IAnJu1FgAqqLSTrADX+KCeX+VFaTNbv/KEBGiu8shYQcYCao/kQ36m7tIyUvy/
ZEWf4K3A2EAF14cINsln8fLvNz4fHW9Z1UeRYaZFdXHjIqkxbpP2hmXjJDlMjpcemf3JTXwBj0FW
TbQhgtzDLuPF+HzX664LUtjQR8oq0slmkjBOon2kt/SI3HOGIKtOCTnV0If3oH36ArUCtxtE1nXn
tGGoft+5jlL3JVg5ZsMYMpsSaUiDDlvFbPWL2IUh2s3TxbgOkdx7x84C3E6HG4acS+CeFSza8KK+
huIhRfQzbMgaa4x20hp1KU0/pseoImeOexvtq7abnuGKhqlqRXOguo8pxmylEGOoONBH6ZdskffE
1VN6Cd5jDmHm9Y/ujeKU+5X7tfuyaZEJvosx2UxeKYSJ0EgymKGadXpJs4jBTItVL51KLILlD25H
XpsW8XlSQz0wbjcso+MsdwwjpUdOpdkf7UNWsXZqBPBGg6Sg45SNYqpWqX5qCPfiRjL7zqk7BXug
VjQPudMNI4aHlUb9ElXuzq06oF5gjOnIdYgTzQd3I3G7u5xSuXXUS9zL9qlh6s4prsCp5kDkpboP
s1W9ZntkmNRHNYj1S5oDvQRjKjH9o/pedBgdRxUtq4iaOjAtUq+rxa5gVySQzTCpKT1CZsz++ihk
FTe6vNhl1wDywDXleuqady00iA02l69hU7/iajbY8BjjtmvZle0qdhGuYcpWeuSi0L56CB/Wb7mb
DCJ8vEaC2UznQAPW8E2MwWxktlqBlbt5rk1DtKvHOIeh7g0dZo6th9TSqlNTGT7q2lErDDpW8vgy
vmwYcr8wnWCM2d8QCs5NAz1A3dv3FoD8DhkCV3igu5Gkt1rYssoYmgP1UZ5G/VK1XS+ph0iN/pFn
zMjzzHqe6cc8i/pd3aZniYj+qMbTaYupnmJl3kB5Sjy0Z6JhGdz5yLpOrjljq4V67b1I5qkznN5n
RiuzTefqcfU4XUb6yGXSh/cwzXiPcwnU5aOKBjHeDHjbR0aiClRG7lSLyWxgEcV32lmZk6OsPZCH
5LEzyClnZe4M/2irGXUm4fP6/Ybh0nUyhhSTPWQf+ZScJ/PITY42kgbyDDxpGTm1AXvpOiWD0T5n
lG6qBVgU0CMFaXdCwMKKyQrjpHHS7O/0JytIytaHN6uLcUpfoC9AI/U5wB4WrevWdSydXkEpo4oq
p6dpK5lt0NH72Ko7VBdDF9DKqlVnDRVKRRtEzml61lnTnO4sUZ+5RXS484QepE+c61QuvU77W2Pd
EcgcHeXcojspUaXPfdk5Ub9CN2ouSqMMJELqgf0B63tm0FU3u87oI+eic98dTZXfeaBR3blQY+7T
ewusBIDVLZI+hl9xarLqz5mYagUjNuayusoYGUwfxXgNEcywvpHVVWZcP1gd3BiLU0wkEwnkLSSl
TAU5wNjJhXtiUsjRChJjeu5GMkTlIbPABLsP3BfAjqfU0spsvAfofxhTzPThsnujRKImtLSEWWZk
1VOYCBPpl5gBRspoGJ9us36pNEpfcOeBU4vbnWUGERbqnHbO0lqjqMGLFakHMJR+jDH0lt7f2e3s
Bfy7rD7DXtcv0vLSI30UqwN4M9auLi49omaoh9Qc9fxez51TtQJo8kO8B+9zq12HpY8+LsBe6+hZ
G99dRK1alYC/GzStj6q2s7zRARupX0TFmlBmRydkjpk9CqXaqSduFbPGbDKHVBNFUpOusAax2R9Y
7ivqlLpwxeBiV+RHvWQFeugyugy2SBcG7K3Y1eOyu0Zd41WMS+OqAHYqdsm+ukpWgHN5YCze0e+D
1m6T2a4+7HL1pmvNxXcJXYr6KGSogQCjgdTVY5aw1mrtdre7STeDFwM7XnD343vuEfzQ/cQ96eaB
Mueecb80hxiGjP1u271l9wP3kLvfvep+eF+C5BpEtBxj3Oi9Y/dzQzRud+3hU7Yp3IfvGCbxMyz0
3rAnSr8LLPaQOfP4e4I8sR5JtZAxMFJPmcdsW/BYmfF7o/dGPYOeXs80GDcjPVpPjboP1EtyjYJa
054c92uTlYnUR7WgLajnsf6RWUKNeEI84R6lp8Bz39OtP/fITbNoH9oHgJYICwQjUgQWTXc6p3GF
yUybDUNkdv0Jeuw8pwLpR3Q3PWEYwV7hkZRKHamOtN6ntzSr1WCkssZyst91PnIO0vs4v34Q7XFH
2Oy0XGOj1EgTHUTVYa/1ix1Kfaezm6bxPEpEJbLXnGZno9OKbQM6BdtwduLF1GVKVz1PW+n7OJAe
kqvf1bTjMv3gXaN+y7nkTkQpPK/uEC/W7+LS+nPsIdaPjdRDYPxkqu3GOZTSFRuG0FHsFRVRbcc1
eIXaeEeHh9VAumM8DJwxIC+xA7QP6PJ9rA5rp8dqIJO8+sw0AeRRRtdQ6fVBWBG9ZHpmfOnMcWqt
63SJc9d5RPfSj8lsegv09DGQbKA7wnXsOnRq6XBaQifRsc4lOsQ5Rp/TOcgMZvM0snMbBQGCAAgS
BAmCIFjwOcHnuH/EeBPjfhPjfhPj/oOKcUO9wHI+QfM3eJ9sn/lLpPGwYw/ya9zrOOw4BtS2HfxC
aNzoOAXnVjs2Ol4Baun+M0Attp50nABqHtTza3zausfVn7SZAfWkY7LjOaAedzwG1GDrUsfi/3Dk
+OTXh5/Zz/vp/OhszT/f4FGdBNGoB1v69Lk3fdrcluUKg7a/sqRCaouySW41VdNgyzEMV2n0vNJ+
W6P+gcFXrdRJWuzqwcoQfe5XZioMBkOFVBdi87/VZGv8uKZNUhlSHdRxYQ+2Z9v77KP2p/YFu88e
BmiWmrIv2/cckL3CrnGUdVzYZtk2GM6qmvW51cqWZUJYYags0UnYFmhiwFNnq2ldCHjuKREDvn9Z
O6mTtL4m+Hc0RBgRWe1vH3BMO2YdzxyLjiWH2bHiKHCs6yRVTxGN9mUHT59LNGtGiR5i4CsztqiW
5VtNVbJqWj1YpTHstPnrH3SGVgnbkkBRtuVUjJa+biuo1Dr2icPS14ZhlhfEPOEjjiuwzsu3mtqg
zggN0RndKfoQLem393Um2rNtZbbHVRrQz2xbQccrW4E9u4WqeloxajjsGKoMaRmoelo1ZavRjN70
dcx1PM85Zftmi2V523Fgs7YYbdNs36o09br6V7aJamUpWhl1q7zjSctox4uOl2hZx0bLwq2mluGW
0Zadls2O15rRjldVRLVSn9vR3zHC3qtOQgDPdZKOGW1/xymQlg9IUVohraarc1qWK0uqlYbDm75q
qOMCSITPySQbyGPHYQacU9rF9mFHLNhHOqz2NUeJfd5OOe47HjkGHY8dY5wM+0A5sw/bF4D2rXZs
t4y37HHng+0xdq+9xz5uP7Qb7MZbTepBwyG76U9v+m41ETIimFBUDjYEAfksAals3Q0p6Xfstr5q
PSXErQetF4TUcVIxWk0DOT13HGlGHeeGUWKg/nLLss7cySM2OSn5DD4gpUAgJckdPrFMAA0ttwJZ
zrYsVwmBRO22mlL0VpP25U1f1aH+wV1tWxlBVfQRT8sHqyIrjjWjldOdKaAHPntwZzo4DtiP7ZsO
f9CecLbVdsze7KAdWkeNo9ExYTc4JI4klrLL7FK7AlBye7EjyBHi6HV0O6IcnXYh6HeeI+eftJvV
awJ8GrXbq2TcfN23BG8BW7wkuARs8bLgMsQTBAuCufm63/x/l3sKokF5H2JAkUJeUK5C3VAPeDa7
iiyN8+vXgF9fhNKBb38Bvo316wrOr2cC/70PZcF8WABd53JY3eD8aw7nXw1cDqsanop3Harl3eDd
gOp5N3k3ISPvFi8PauAV8gohhFfMK4ZQ3ge8DyAT70PehxDGeWKc88Q2biVYN7cSrIfLefV1bj1Y
L5fz6o95C7wF6Ju8v+T9JdTP5b//Ey7D/QAXo/sWF6Mb5HLY/xveb3m/hYa4+Nu3uUxZw1ymrD/l
MmU95nfyu6A/4/JlfYfv5XuhMS5r1p9zWbN+yGXNWuGyZv2Iy5r1Yy5r1jqXNeunXNasTS5r1s+5
rFn7giPBOfRLwYXgAjr1h/xh6L/48/39of/q/5b/W9CFf5B/EPQ7/xDgiSHO7/oBj6uA+dwKLn//
fP98OMC/xL8EDvS/618Gv+VfDnzwJS6m90dcTC+Yi+l9jovphQDv+2/hz3MruELZPF1wGJunC/4i
m6cLDmfzdMFfYvN0wREBRAABfzngfkA7HBngCOiE3wkgA0j43QBXgAuOCfhaQDf8HuuD4Tjgg33w
lYC/CvgrODVgLWANlgX8NOCncFrAzwJ+BssDfh6wBV9jfTOcwfpmWMH6ZjiT9cGwkvXBcBbrg2EV
64Ph66wPhrVcpq8aLtNXLZfpq47L9FXPZfoycpm+GoR+Qj/Yyv5HCdzCrpKCbWy2dbhV2Cv8Btwm
/GPhv4a/KhwUDsJ24ZBwCHYIvyMchTuFY8I/h0nhuHAcpoTfFf472CX8nvB7MCOcFc7CHuEPhH8B
e4X/QbgIf134QrgEf0N4KDyEHwl/I/wN/M1LmZey4P5LhZcK4W9dunOpFB68dPdSGfztS9pLWvhP
L9VcqoEfX2q41AD/2SXkEgKPcLnIvgP8YR80+alXzFD+i+0zPXlbUFsI5Nfm3xbeFgXxiIs2YPfE
aVsM5Ee8buO3BQNqvy0RULvECTiCcaxNAqg1Yg8cecRL4gJQL4gN4gBQz4glQM0SS8TJ/2T0+MSf
8/v8zVwWNXaNFZROvdn+9zd4tHU4n8nqLuLlM1pFnjZvVnHegOarM2LunuaV5YfmP8kPVUzn27Im
sqwZsqYUxa5yrTyxdbhMmtWdn66YLhAqzksiM2JywR35oeXpH9cEd6bnz7QugHJIRKkn1ZNELCFh
aZZSrBOSlvuEhIDA1c7Whfxotg15vZWv8pnyxLxZ8I3n+erWYa4FTfmhBRX5TxSPsyZUvPwXit2q
iTwz+P48Yim/6IPBvKCqaSKKmCZWiDFindgiHtleAH3bbx3OCmKfWfgM9G6pYFl3OcuqCwVPBE/X
JeY/yerOmsgvym1X7OrS705mLanLdUV3yvK0txZ06pJIxaOsCaUi38by4oPB/PasibbANl5+aIas
7XJGTFvoP/Upqi2i9TA/NMuaNdF62HqY9ZgtrYd3BrOClFjheut4fnr5gyxI8ewOnaXUKlrnC7zq
FLZv2h6Wt+WhBZiKd3uS7VvWROZBlpXl7a2FzItcdeuUNqYs74OVsrD8wDxtfqg2WBupNdzpLvAW
LGc9/mC6PFEx3TpqY3LV4N5z0EdrfmjrUyC5XMW0ci1vNiMGyOOJYhr0V12eWLiuzcu84OTha91j
2wrkkUQ8ImrA502ihNC2bgLZDAIZ7dxsJEKIx8QzG0os/l5mRFTLCdjHfmAuf6Ad0Iq1Ru5Za+Ba
OBF+sxFc9Sf8ASe6C9fZTcXL6wXcGi1qz1Bk7BUYgXy2gFSOCpWAayetw3mzrAzZPXEOevckr1cx
zUoJyAjISekDV0J0ibcZVkrKNeWaYre87u6kYjdvTFOmKVOcs7IEdWbvTt49LZNWXtxayA/N6wVP
2VXs3hr/IDxjM2MT6MY0e3+WUhfaFg1a/0lfCDnQPSVxnyhjW00EgTJB0EQ30WvrL/G1Lrcus1Tr
DluIRsLcekbkEAVgbJo27BNj4PpC6zFh/SftBnpN+LcuqCdtuTp2bkkJ/F34u2Bw+h78PTBSfR/+
PsSDfwD/APKDn8PPIT68CC9CAtgH+4AzfQm/hALgFXgFCoTX4DXoLXgD3oCEfql+qdAlv5/5/QwK
8vu538+hf+X3N35/A132+1u/v4X+yO/v/P4OCvb7hd8voM/5/b3f30Mhfv/g9w/Q5/1+6fdLKJQ/
wh+BvsAf5Y9CYfwx/hj0Rf4T/hMonD/OH4e+xJ/gT0AR/En+JPRl/hR/CorkT/Onobf5s/xZKIq/
xd+C3uFv87ehaP4Ofwd6l7/L34Vi+K/4r6D3+Hv8PSiW/yv+r6A4/q/5v4ZE/H/k/yMUzz/hn0Bi
/in/FErgn/HPIImAfUF1ReAv8IcSuXH8fW4cl3Lj+FVuHE8SfF7weShZ8AXBF6AUwRcFX4RSBV8S
fAmSCb4s+DKUJnhb8DYkF7wjeAe6JnhX8C6ULnhP8B6UIYgTxEEKQbwgHsoUJAgSIKXgiuAKlCV4
X/A+pBJcFVyFrgtSBClQtkAmkEE3BHKBHMoRpAvSoZsChUAB5QqUAiV0S6ASqKA8wQ3BDSg/aCVo
BSoIWg1ahQqD1oLWoKKg9aB16CtBG0EbUHHQZtAmQKBvMOsbzPoGs/7BYFZ4zq/vU+Qn9b7Z/g+2
z8T2+LoFoG18xRJmiQSUz5IC9guWaHBu3sKzADyOz1gAmscnzcfgyMPHQD0//LH5FVd/wHwOqD7z
unkfUA/MPkAxZp/5+I2H/P/WQ34aZ63xa/z0H7Qk+/BoYUrmoVRdkHR7ILMib1KpxI04URSsSJQG
ZuwXbmc9L9y+8RQfvX1clpOZjU8ZVdciMs4LU/AwqTrrye0BvAI3ZlKgtvqqAh9oaGZrFl6AO5uy
nmPl+Jo53NxpHjRPm2nzIr6Db4LjmHnCvGTeNZ+bC5DLlhR8r/Ah24bkGQt5eyDjXKnM2saNRcF4
MNuCaweF2zVJWc8zam4fKyY16UaVpd8yVJgij5XybmAF04qRW1bLE8ukZc7yHGm3vLCoLC8tq5aN
wpS8kczDQtSyfXvA8irLhlcomKth0kCl8uPnSdW3j5tkyQ+MqsKmzMOGmBsDTeIC7e1jaXmTQhGa
VV64ensNH2V50SRsiGkS5/c0Se9iypCmvMZFywzbI4u6qdjyxByVv5lpvH1sjjXHZmK52ZmYOUeT
njeimEnqxSOznlztkUZkvcg0SIsUG7hG8QJvxjGwpzL272JGMkeiyH1fwvbt9nFSTcNAepiq+P2Q
pJNcDJfiCtyeP4978Z6k3sJtXIzLcEPtQUFOlu1OUUFJxjngvRCPSS7Cx5MkGUeFF3gwXowTCvLG
U2WQUqlIVCTiwzeeakY0uaripN7Mnqvj+FN8GV8AMpGYo8y95i2LCiXMWjNkuWwJxc/wPVRoXrEk
mmfNZkuuedGis9RZUHAPKzPafGJ+ZKLxvJpZvA/Pxg34PL6JHyIbZqv5vvmxed9cYi67i0nVmXyp
Oqn3xrFiA/DZanmYGWwZyRJZZoBkVhH1+93maeyhxWZhDM8t7ZYHDc2W0/zNm9GFakWi5SBpVhWW
9zK/x3JRMNgU2RRTesJK6VrEtYir83hY5rE0QpGbMZExgRsBX8NycpTKzMOmYHDF8H7IXaxQnRmj
CDSqsuqasi2vr0418ZvCCtHMM2mRPLZJA7RwEV9rqgD97jYfmdfBOCnCEs0lCIkEmrUWtWnRko70
W5rMz8zWxgKWMgcBKBFiibBEm5WWQMCjcpRILrIU4T782JwEOMZyRs7qtbkGmQFa3ViTxP2jE+8N
Iv1MRMpi0X4Oi/4Jh0UHOCz6LQ6LDnL//vkGkb5BpP83o6heYB+f+Lz3Tj4bXTUEIiWQH1LWwEO0
EM94hjSD/TFiAOeyjYdIMaBeISigdMZtcOQZ15FGQJUYV8CRZ/QhCkCFGRcQMaDmkEBApRhnENEn
Y8OnK1xeC84+zVH1noHdeL9KGUvbT5Ym6eQqZXrccVykkow/kG3GH6TFynNlPrE4bT8hVhyjjAbU
WepreaLsLE2bMnYjPFma0Mnexd6hJGXzCWMJSoVPjkp4Ml8mJI65sR4vSibSauS58auiibR9xIgQ
SA8ygEwha8gOcoaGoOFoLJqE5qAlqBntRc3IHjqNzqJlZUMfHKIr6HoZCe5pBvcMI1MoBOpHgdpy
5BDU7vy4JlqCDKOP0RPJZbE4flI0KHqULBVHyh+mzogWFcPXX6igFGuCJK1M5ksKTRmTh8b1iQaT
dEj2hy/i9goiUl9zbVozRSBT4LvOwHND0FgEY1tkSkTNpnS0F/Ghs6ZcUxG6YlKbylPG8jR5GtF0
nFeuyikXK+S5yc2io8ySFKvMJ88Vi5OlabEfcym1XRKhUmbzZc0l6jyNbCeJjJNW7IhmQftiWA7f
8L/hHxcpz726IvOlqhJClGTcsTxXpQQt8iIEuo/WIFMmG7Jwt8DEgL7nsK0zzYH29ID2vDadgvZc
YEIsDIvEYjAxeoT0YVJMZmoyrZpeAN4A3pqGTE9MGxjfdMD2RJnecJQnRK3oM2U0Opt6mtysBOfi
zgAPtWgZkGB62n7a/vW5nPQknegRey2zQGyXbV4tU0FxkWm9YjGrA8rolME0rVwl20l9YgiLy6sY
BvI/lvkMYSJawpNEsNcS9pFscVj8wXVe8RTb2zRtmjltOiHqalnaftyoCkJiJIFymyg8oex2gcKb
tp+ki4uMixTHxCemjCmj4/Jkm2laFaQq054iCiQboRAv2ztOC0bLopGn6H1kntOgQ6A/QF5oAac/
NPqoLBrdZeUFyhK6iE4AmS4jy+g+Mo4q0UagXWbwKQgdRBbQGrQb3QKaaAT8TEJnkWPEjpYhGNCz
cHQMnUDX0fMPRk08UyDg+zQqB6UX2QOfJeCZfcgm6p+2rypL0iXprj+Qq1Q5cceiRUSmVMWHZsni
E1VK1nKA1YyqzpPPlNGsLohHZWcZz+Mnk6XJUtFiatH1wLjjlDGx8ePy4YvraqBBgantccfSnfgD
0e71F6C1PVy/+4D+hZpSQHtEpjoTalLJH5oum6JNutR20SNW5xIes7rIamJyc0pjihXRVJakznys
i7IzeSJikESIZoG2zcnn4l+KjuJXU6x5mswSoIXhclXGc5kvbiBZqj2VJwJ7VudPxw1k5qR1JzxG
KlQ5Kea7BegRsM59xG5qRxZMD0wPgUYCfTRNmp6jWlYfAbfWEa/pFdDHYOTQNGOaQUNMD1DINIKc
YUJQtxnIbBnIaB+ULXQFU2DZJhKZN/WD8tK0DT6lS6JTxlLGkqVyVcWeWHE9OmHsalnccdpWwpZY
DLRDnPE6a/z6SGq5aiI1XTafOlNQrrN++CIhNiFWtpcQi+TF+QCPY1h+x/myZAq+MrpEnTaW+iRN
K1vIeI6I5eUiSDSWJhePimZTHot3VOdgdAgHY9sWe+3GSbZGzE/ZStuXz+Wk3BgTHeUkItL4l2m9
jZfjxDLxjfCEkPiRtIK4PNGYaFpJIsWyTVV4Kio6SghR9SrLU203nom2gJ37ZD4VJImQbSo34iJF
zwrKE8JVUOqGdFgeLY/OSbxeFBeTk6iCFOIUc15YyhjQoDlxcOqL+NXrRbI9sQG0RRV3FjeVPxi/
nSXLHk17JFpiLUSZrjD+fkwWi9nxOP4VK9k0LZD4GDsKq3LEitR2JakqQ2LkuUpGnmua43IE/oj/
kzdrV96sXfkDWrvyAOr7FIVErHPbZyKk1Ee1I5Bfam/tSO0TQHmvnYM9leMD5+y1vTlTgLKlA0yU
2pQ2W9sHqEY5S9WkjV8bAlTF20OA0tQ21loBVSQvAlRuWu816p/Zx6erUiIDYz7FbhEKPr82953J
a4lR07doceDbw2UnSc9q+6PDJIO1Q1eK5IPiwNrnaeK37QnF2pr3c2pfpfS8K7l2UVtUq64tf3+w
timppvZh4qZkMGf2Srp8sHay9mVCce32OxfvDyZulu1LtuLI+MbovdrT1HXZc5Gm1pYTnjwji466
fy1ahsrar1ykniRtvTMjX7n2IC2yIVjVV79yrb1+K74xvrH+KDG4rkKkKbAmNyXPiDeSZ942aE+M
pPH5XU3tqYgyvjIeGOui9uv65CGJC5EXku70QwMvev5KRNxQY1lqyfVYuTYlO4FKOWu8nyF/J/SK
WnRsCNWXSI6iz/R0Y1RjbKMkOrhRnnDcWCIvudtzpeltXwL1wVxj7xV14+PI/ujg1MHag8axpJqo
lbrllB3xaeJZ3VpKc/xR3U5STd1e3WH6fKpcvRw5B9p5nKCRxJaUpfT9N/bOPcqK4lr43dXVfYan
iEgQ5wXCwLxgnmcGBAQERFHeIg4PmfNiJIiIioQgIqJBRHwRQnA0SBQRERHR+EBEgkgIQYKEEERF
JIhoEAkCEjjn1v7VXE2y8t2b/PGt9a1vuc46Pza7q6urq3ZV7V1dZzrzw6IxRSsje3vsqkgWTMt4
pfiWyuP5a+NXlqwoOxVtGB/cyslaWz561Ky8nuWx+Oho08za+Lj4xIxYfFp6TacW8ZnRFvHZ0cz4
PLmnzPUFpxMrc8blt7zwTPHy0v7hFnJHRZNyZ5ZOKjmdX5M/MPNwdvu8o10Ot0+aUu7O3JHVK+9A
+1PRnul7qg9WtCxaY0q5qzTcqSp9bdGkyPHSorwp/YdGa4fWRpd1nRpuGl1ZMDkjFl0TfS3jSN6Y
3EPZM9sdja6PjolOMZ8l5d275mTMy1+Vuyh/Q0nnrMbZpwcky5qVr8g/GF4T3x/OzKwtmVdW0yrI
mJ8ISqd3OdGpRfn+oUXli/J7JVqUrCjZ1fWecFDS+bJFhW1KTxQvjC8tOhM/nT0u0bRibmZt+p6M
ecULS3dnJoYWhZtmHi7YmHEka0LlkcTW9OXhExWqQoWr8lvmzszbWnI6PZk/sPjJioK8o6XhglfG
Nquo7FRbMrNoSVav0ZUF6aVOesvSNlnNpM1zJydOlBwZ2zh3ce7M9MbVp8K1lTMrsrNeLljarkv1
zgFXJBbkLuraK7NNZpviufmNC/YOmVcZG9ozPD7WK9K88khun/xbyjt0qi2szYl1cgZsC9cWd6u+
JWtf9dTS9UXrs5tXPyn9ofrlwrzyvUVLesw3dr6nuFeekzmnIhle1mVHxvbqkdWR/Mq82qsP5l+R
Pb96+dUbqiPV91TPqF5bsqJgb6cW+WsvWVLdq5PpK8Vp+ZuzVuWr6l69Z1UvrN5c3r5V3tATebV5
tcUzytsX7C3Ym96yvEP58YK9uRvzPsx/PG9O3muxmupkdXLk/tjjPVvkDB56uLxz2bDIvNEqtiey
NJ7ebX4sO9YyfcPobsU789pU9indHWs5ulu8dXb3wilZNV2/KHSyN5btiw2MvFI2o+2M2M54WemJ
wjmRWGxY7Mmc9HjzSOe8zNIzkXVtZ0Q2RrbkbmyXKGhS0KT0RHbroYfTe0UGRyaWLUzvlbUnr03p
mLz1lXszD+cuChdVvpLdZPjcnNWZ49Nz0lWiZ97unNPdZmccN/YxpmRe7szw9PbDEnPSh+XXFE5K
1GbMS99ZOGfUrKyd2YcK5ySKqmsyFpt77pl/RVbjxHj5f6Jv9dzEpPTliUT27Oz6iS7hpqZfr89b
EO6Z3jJ3WrhFwbhEVWJ6jz7Zp81dfhieVd45b6vp2RMSY8KzErNydvU8k30oXJQ9ul2QuzFrT8Z+
GUcq+5h76h7pEytpv6doa+b67NZVK/MjFdmxVZXrIumR1rF9JfWzNmcf6tG8dGuPXUWT8p+Ub+7g
soWlbQomV4+MOtGge3b+2k4tMg5lre2/KT4/Pjk+sf3A4hnyNf11UTwWbVM+LpoXXxxfmjs/PtxY
XzJcJN/Mw+1q8/JMmV5LrEm8ltmmpE+P9p3C8cEl9cNrcveWXDnyUOR06RnTC09n9YqGr30l2je7
dbR/yZHo0IzTAw9F50Rn9Z9VND5rWNaw6IPhNeEF1xzNipTMj05vd7S0dlRRdHz6qrK10US0KD27
aEnXnHD/aJfogvyc6Kbwkow+hZmdguikAZtzt2RsiVaVjsk1vbW4Jr667Yb4xviWzGUDZsR3xQ9l
Hmg/N+9wwinfm2iYaBiv3+10/tryQ9njcofH18W3FxyPHyk5XT4ucrz9ntJlVSdKt5rxakX8lXj9
kvnFE6Jb8w+2q41ujR8PL8ue3HZGfG/53tHNKjaUnum9JHwgsSP/WMXLV3+R2F2+Nz87s2n0tbEq
fV/26ezTkcH5q7rmlFVWLStMJM60fTyzzSUtEkeLa3JPJw4n2mQ1ztqZOzOxPrFpbFrFjMKiIeMq
IqPTEgeqDxZMDm8yVvZhesuhh8O1+Xsq+2Q1K9kVM2N+bGQsJz0nf0OsW9mGyJV9J5W2iEyLzKw8
VLyz7cHy9FFjck9HVuctaeXE1hYfLJubvzx/T2xzpLVp+5cj7SMdyh6P69xDWc2yauIdYs1Gq3aZ
4R3RAyXds1oW1ZadKktGxoXXZ++PLIosGq2KPizbkN29bEPWqsjiyOLwiUiT3HUZGzN3F6wurqw6
2mNc9LXo7qyDebvj3dOX5y6NNY5dEe9TuSt3cXn9jPpl+yLbY7fEJsSmxu4pWVGRXZFdWhQ+UPhg
7qL0nbFjsVOR2aVnWrXJXGNmxJbxzuWdK2PlfcyYPbSiJHt13u52iYguM7UWezjjePracMP0SN6B
SOdYZWRFxdrM9bG5WRtyB1cfy9gfqR8riEyMTC7sUrEhtjC2PLbN3GcyXj/ePnNSXpEZD/KiZ2Jp
0ROR0dHDkbL8CRFjffFD5XtlPcX98Ptfn3z/65Pvf33y/9yvT/5hxbXxrP85nhiWM6Kv4w3LLh1s
/lXDWowYbtj08l1G17C024jO5n+6/xrHuzpZvGpAmqOuPlE83fzvaPGSEWHzv0MjWpv/7S9tNsJE
MFfvKc00/9tZfE+PDt+OEN9GE+4ObyF7Ezo7/Ryn0Rf/y/fY38mnzDf5b5zzRV26f5G2sbbfb+X6
/yJNfXtd+ZdvE/Ntbv/lePrfHfsPvv9Ouf9leVqbb3unXyOHT9Coofk0Nf+2MP9r2CjT/NuGT16j
IvMJm3+bNupiPk6jnubbgk8X8+3bqD85DDX/VjUaYz49GyXMt6H5f0/zGQ/lXysVwaHm45D/JJPL
JPMZQ779zWdKo+mmbft9v2OhbseC8pVTwL6FQvYndGB/Qkf2JxSxP6GY/Qkl7E8oZX9CGfsTytmf
EGZ/QgX7EyrZn9CJ/Qmd2Z9wMfsTurA/oSv7E7qxP+ES9id0Z39CD/Yn9GR/wqXsT+jF/oTe7E/o
w/6Ey9if0Jf9CZezP+GK71vx/4tWdNVczW8O3ZeNH+WkzfvHb72h5ltlvmPqdK98p//ntP/OV/Kp
l/hf0sk1lpp04/9Jv7juK/KK78oi//53eSjvf/j9t8q+4t8o8/9wz/9Qn//htaX+v5UnmX+3OONC
NXwioW2hAvPJCd1i/rczNEH+Rn5oamif+b98DvL5wnwLjP4ek2ZCaCFp9oWOhU6FZtTlkkzTRj7G
+RNM2mFp8oKiJlD+tVJzYd2V5TPXfOTfY+Qon23CtPTvaK5dYMqzJ6113ad93aeD/VBuSV2WZjwG
59rv36r8L96q7PquGVHk3codebdyEe9WLubdyiW8W7mUdyuX8W7lct6tHObdyhW8W7mSdyt34t3K
nXm38sW8W7kL71buyruVu/Fu5Ut4t3J33q3cg3cr9+TdypfybuVevFu5N+9W7sO7lS/j3cp9ebfy
5bxb+QrerdyPdytfxbuV+/Nu5QG8W3kg71YexLuVB/Nu5eG8WznGu5XjvFs5wbuVx/Ju5RrerXz9
95bxvWX8HyzDdfPcmUQtW5yOxj622a+ab/49+N3/vTz7Fb38i67IfMN/l6aL+fb87v//8it5Hqv7
Hqy7zj+l+fZai+u+i76T//vYt8cXfVuejmpO3edB81lgPrVwiVqmVprPHLVGvabWG2mBOb6yTjdH
bSJdLfqt5rvDfLbyqTWfNeYMOb7G9KHGdX8J9sNv/xKsx1+C1fp1vc1J42/ApvM3YLP5G7AX8Tdg
2/I3YHP566/5/PXXAv76ayF//bXD/7V8TQwq0V/qZOo9x01+gXw6td/wTOoLw1Op3YYnUtsMk6kT
ht+kPjBn9ZOUTgxe6U4z7OOONuzlDjXs7nY3HOauNOkrOTrQfdBwsupvOFHJbsBbVC/Doe6ThsPN
SOM6Y8zI4Toj3a2G/d17DMerdLmKe9ywyni7rjNdyduiB7uLDB/gWutJr51mhoGTaZjmyFvuHCmt
sdguhgso5xXuJMO+bo1hxD1sONr4yK4zS8lTvplqjmHCTRpOVRHDGpUmb8tT8rffximJ1x9Wewxn
qBny+1N1wHCJsSvXWeGNNNzqnTHcSz2s5Y7kvXpSwzD1GtyNxpQ29VpyieHy5GDDpcluhouT2YaL
kiYuT61Lvmy4KjnRcEnSXCX1eLK54YqkuVZqwdkjhrXJhoYLz54yFnENe5hzYFtIG3mVUhtePvKj
sIodVufCbKF6Bf4KzoMb5Cy13DHzgHofzUPwJDlcCUOk+RT9EXgL/BjeRZpM5KasMLyO/B5cC5+G
M+ADcDVn/QAuhgNgB46+DRvDKZR/KPLFpHmQX9eugs9xxVvh9ZCyuZfDElgDx8LR5LCEPHvC/rJC
449EJmd/LmkuJH9KqHbV1bCwNWwJ02EP0vwFuTucDW+At5HnE5B+pCvQXwfnQEru/YI0nKUegZMh
Vq2Gw7vhQDgI3gQvgvdI31FYiGoDOzqLDYtgDswXumeR20ofcT9HvhjGOZqknPfDgLJRHv0wJRyH
xoVdYS/4gKsNc0lDafUe9L3htWh+LmnUVMr2AqSlvKcgrWkiPkn5UzQFyNiY+gh+At/kKFbhRdD8
Fh6qs64dRv84LU5JXFrEtbX0AdxPztYesElvEaQ8xiuQNLvRFMHb0aD3noFhSns1+p/BdZAWV9aK
CiHl132QJ8CbYTtKVU767fBV9PcgM0p71LmHrXrz0f8Q/glNK1ifkjRAb3uftahhyNieoi3UX6Gt
2xbIC+EvHDM+e/QRz/a+NMpsS2Jt4JdolDvMyHloOsOd8CdwFiWxd/ca8kzIaKNtyvForA2jUX9A
v5k0m5AZWzwswaNHe++6BYZ2BOgELyWfEfBG+ARpsAFNfXrdYF+u8jz6FHW+lZQ3O4MMpzt3Gd4q
svH3BlHbgxj9hMeF6gzyOTDs+owPdzFOiuZX8E34llBfj9xZaDw04Snj5bhec/StuKJHzu/Ap+Dv
4HNwM/wEvs1ZLWBjeAll+ANHl6L5An4M/wK/5uh4YVAgdGMwDq+BU0n5MvJIOADN69DmvIZ89sG9
8FH4GTxMmoDaO5d7X4/8Afr98DZ4O7yF8uQiL4K2rp6iThZw7p3k8zn6ctgFXgq/ggthKdwKu8Gu
8HLYnhI+DP+q6hnNTXXlkWutQ14J74Xp8AnK8DfkKPwRXAu5R7UEvoimitI2ofbGol+MTNu5E8iN
PBWto/7IWcOpB+5Ov4fmAY4eQ6Z1PGQ9H3kW6UPIXEudgtyvGo2eVvYyoE3ZtO6+3jdMUJJV8HFy
PsK51yI3gJe7zxtqzjoKd6C3VkGd6EOwJWwIz6ds9ciZ1jGRmqTHZkwMKKQ1fazFx85928v+TPoh
aH6NJgwz4SSOYsO6NcSGjT8jcr4zwnAaMi3i/RTa0tbAj+AeuAz+jBy4d/8E5/ZAttbVhzrhTn1y
9i8gzTRGjx+nas3Rs3Y8kTFEPQX/nNwpnhUyo6h+SDR+lJQnRa9Lk+ulTsQbVB8yLt3obKaNNotV
MCJtEm9QMWsoO7renvzQyI+jf4n8HxH6s+EU2A09XpCy81EZvAP9uXCInfuQ/wQ/F99b4XcpfMgg
V8qs8UN0Pcgs4D/NVZ6Dv+Rc/BbFrKqeNX63uQryIDnq/g15COnjzmmTzyVo7nTDnGU0yqUe1kFm
WIW36VuPaxpppsNLnQmmHvBGvH5SQi+euszo7by/mvIwP7r4aeqtuhk5ZlKOkujAuyC5UPwNoYfX
pEtpkTLxf5S9o0LJ2X1G/HCNj6et79FNWtx7lTQjYJyWouZVD+6R1vfSkxcazUTrjVCTTdG/JHma
mM540Sa6Fs7Foy6Ez1ISvAu9ztqPRBbeZKEqlrhG4W+Y0cah1STNJ3AUmuPUW66k1yc5d6nUqrec
un2GlLfBX8CW6N+UiMz7jHux1nKMGlbIN5Hyh/AdGOVevpLoRuEJu39NzjIyHoh6jHyY5b2LksfE
5oWm5oUd0Z+TfF3Gc+kF6ozEOOqktI56W+zQiyLjFavL4Ciuexl8QOJKjden8Ru9MfS4+zn6AryZ
mrS2alvqSfE29Vn0b0Hr6eEFedYLqob0U28b/D1XIcLyiWJ84ikf79R4Cw6jhJA+JSsdhj+HGfDP
8DBnUbf6N/Az9LSjh/+j8Y70GIjlaEqif0caYi6fWEOfQqY/ei+hwd/zqA1NybX134gIPK7oEUF4
v4Y/hutJie/q4TN7NhYjsjBzhMO8KSQe1CuQKaeJe6UMHnobv1iZPuXZ6IZxwIzbQkYknQWpGW3j
03eRrZ9G3KStH4uv7l0F30GPt6/JxyP29DbCP8LPOYof6BEdaHxmjfeoqT1t72IZbEJKa+d70VhL
IKLRzWAIPoje+v/W0yYu9p7kKBGEtnGKjRrwoj2u4tmYgljDY9wz86PDrC0jkvX2qUmFpXk2zt1n
+wjyTmcvM53D7Cka68ljdYp4Stsy3wfxcrWNufCuPerNG4zGjvxfovGRbTmHq2ZGfhnNAbmi2gRP
wLOUgQjFOwCJ2jSxvLbxhY0Lyp3lhtyjvrDuToXN0WQjH0W2v7+28a/V94cRaoY4XVFmhf0obN7b
ACeSg+2tNjZhrcDTcDm00VNDSETvNSIlPcj4ySLbMfMraP9Ol60B+pT3unuLIz6P6G28fwUkyvCw
ZN9GcMwaHtauiUf0VDRjyK0KeapTRb+rwputokWqKJvwGzgAjoc1zlzqX+R74DzOLUQeJPSvhb3R
DIT9YTlMh+fDC2Fr2Bc2glF4rVzLWH4V3o5onoYroOK6b3OUuzBzjehnI18POde7A7aBHTgLmuij
ijFN5CXIryGPRX4eckeezbkH/AzeDrvDqdhGJVc8ieZeE9NIi4j8AJwEY7AfOT+EXAHbce7HyPnw
ajSkVJ/Ce2Efjk6HXeFP4AzYDXaCH8Kj8Beca+WGMBdeA6vhefAPlG0K6ZNoXkDjy9qmV4tmKZo0
eAFsBimt9wjyxcgrYQTNucil0NrGdfAUfJQ0c5A3IFtLGEJJvqqzPWEZ1mXnPkYVZUf+r5HtGggx
vmbsDbH2FaJPhex6F+tOHt6jt0A8DZ8xyrcrWsxB6kcQr0DZlT16q2tXF9dDxrEAPzNkVwxsvM/6
jM+46q2CtWgYo4KOyamORHCS23GR9bv4CXZFYiVkTdKj1wesJyjmbsWahmKGUvRoxbqBZuTXrLpo
5kfFCK/OygqtV0+orSds+z6159oas+mZbZVdJ8SPVXacHCHnuszUyq6FXpVqQrQlOXzM0XfJvxhe
LAzZldKH0QzkXDx2RYTicl+autV49dqO+YxgqjsafBi9FVqf+UG4hposhtRMYOdi+1vdIjS0ZoCH
pllf1XdAYhZNDrpKfGb3N9QPabz7kVcK1djkFilbqoNJsx2NXdey6z/MjHoLV3wMkn/AOrCycQRz
rk/Ovl2VYsxXzJiKecRjrTvADpVdpbwTYqva+nXMHdp6DszFIVZ0lZ2V8AR8672wWugfRR+hzHhf
Pv6VZs1Tl3Ius5smBx8q1jYV3oXHCrli/VnNIZ/JcImtB/g1PAg3Q2pS0WoKX1TZkrcSvd+do6z2
u2cl1gjwkwP8loAVvCALa8H+1T7a4kZ5NmHmJkOfvuwPxt44qhoiH4YfwP3k0EGeYug0NH8kZZw8
6YMKL1TNTAUmN7vyeaNT4charqGPJ+nb+IsWcWPJmwynEB8NF6oXKdsFnDuQsk2RpyqKVjAzo5yL
v+ryhMLHT9DWBuyqNZGgovf5dt2PaFQcVSPjq2vrF7Fmq+1a9C0yUum+3BHjmLYr3jbyImeV4q7f
pISzkTVnEae7eCma/F3uQrNur1kFVdyRtt4jq50+67p6fV09yL2v5+r0OG1Jn9XWGz/NWfgtns3Z
epKrkFnr1oshnoyiF6uDELsNrNdXzXoCHo6iPMp6R1ivT+wc7EPDir3HuOfZpzBo/BXSfxVr/iaK
l758XfKQI+sqDnOrpGEl3LNlwGfTdpTm3pWNBezTq5+n3jQaVo+V9Wbpv5rVAMVqsKa0vvWN8fp8
+qmPT+vbaIKIwLfPR7Bn90uxHE08q+2cxZq8T/6BjZgYE9KIQQLyCSi5xp8M8Mw9vFDdW1ZpfPqv
tr4ls5hmvV1bL5TxysND9nLEfw7sTMoTGZ/oTDGLKdouYLwKGJEC2jRglAhsVGVnH3sV5g5NeTSW
rJmzNGNLQF/zWZUKrNc6Bd/+SymD96I8pTV+lMgN4A/w8IkKfWZkbfsLM0JgY1jbaz4R39639Y+t
6hdZs6IdNZ6wb2Mxni/4Nn607Ujk69le2Yuz7Boa6za+jZHvRUM7ap6beIzMmnhHs6qvsSKPdvFt
bE6ZAxuDk8ZjZPCYlUK0uM9srpeKP69t7yM68G1bW0+eeURbiyWm8+3MSHsF2FuI+ShtBvqbrC2x
ksDRgL4ZDGTNwT6T4vmCGkuaML4WvquPf6gvg0dgER7XTnjMOepIbFvFuFFFj5az8EI1Xn0aXl/a
ffJE20Syom/JuTayOAj/CPfCLXAbKUtgFzhQrmX6lxxdhOZduBvNMGHwVzxDIgWFl2jGLmEVnEvK
pyCevM/VfbzTwHqb1rO9H+LZmvFWjh5DJmffRhmj0ePf+svQ4IWaPiUkHtFTrZ8M4xIRaHxyjceu
baQzAe6W6EBfRG74tNrGX/j8uhXXsh7+Wfgleuszb4d/gQfQ58DfUQ+NIfeuKElg4471pMHnDzVA
JhLxlyMTnelNMBs9KX1iH72KfL4gnwfR2AjxFfTkEJDGp2X9cokUjCVLynVo6iFzNCDqCfDzNbYU
PAyJ2gJiBN/W7S40Nq4h+jPzZhXjm7AjJEYImnP0zzCEnlhVk8azloy96d9AYjd9F+e+BLFDTbwT
YIeBteoEub1PPsTm3jjWGGtlF4o3ijXM5+vmiG30HemheIkBqw3+G5A52rfP6Htx1gxywG/0OqFh
dvP6IW8R/0Tz/FozZmpWUFVnjo5jdbQNM3s3mA4v4Syu6D1PXGNjnHmcdQNpypFvhLfDO+Cw1Dg8
OpEHwrmU8GHk5nCwaHzmRG3XxnPgJeTcHpmSqDI4A17MuU3guWhYr1B4Jt4FQvcr9D7y39A7aJrC
/nJd5ST7Gr2tgR/ALNgQerABJbFz3E85F99SH0XDiqW2o65d/avHWc1IuQn5PPg4tCv/tIVXJvXj
cXdeJezJtRT19iUpvyGNXS0kmtOFpHyZlLacjOHeRcjbkakl7xzSsEdF25W699A3hmFqYCdywGp/
E1qnmOvSvupzjuaRci2aOXAFfAJuhh/DF+FvbJ5wIRpkN4VM/ajXKZu96+FcvT6ybf0vkNtz3ePI
j0EFLyTNSXJohIwlKOZE1RU5AomOTXwh8nZy28STLGszv4bUpPFCaRebEu6AB6Wl1GlaQRPffYnm
ozo7mWjkQ8i2JC/A38Nl8G3S/4o0heTzMJoXUi3FE8ASFsN7SZOJjCWrQ/S+K9EU2esiY9VeD9qL
XuxFGCtY9/PtzpPmpKyEE0lvfTa7z6F1XQ+VPCsgKXWI9Ha/Rwz5KvSzkYdzFbujIAuNXdvvh9wX
Xg7bUM8rucpFaPpRWh/b/oor3mttlfKcJE1b2BG+JTloG/8eRjMOfgpnUSqiP03Mruuh7wyz4fWk
YS3Ff9H6V1KeEB5gyO6HYYQJ4QH6xImaEUxfLQxYhdasqwTbrXeK/jZb/+oJGalkP6HqDS+HO9Qd
JuXr6hHx5aBdE74J+XbYQ6gecA4ai3pL6sQ9xZO4s6zb2LieWEntltyUjdDPJ3+762wb+oJUpYzb
1OchNO+rToYLkWskf9UNpsPrYGvZ/ajyU7PlivAb8iknn4myG1CtJodJcJ3Qu0bO1W+7jY1mkJRE
s4rlYoGuXdu/W/aVqRGyyqoHUA9ryeFK8h8k9LLIbaTsb1Q/VTniMcoOLq+S/UvLU2OM/g3ZFale
Uqsd2fkjZf4APq1+ZDiBktzrvCVjkexgVAug5jmdffo8T/ZbmnH+JUeeWu6S8cT9RlpW9jfqW4Vq
vFzFe9RdauQNaJzURvGXRHZPyj1689DnplYZ3srzuIek7bz+stdRNxAP3/jqm6nt5Ub/caqr4Vlq
so9T4sgK1QLspKdhA3gdPE/oPSc08dpiI/8MOY09af3Ik/jL2H8b6U2wLbU0j72LX7H7MSGymYkk
usmVa2lmQ213OlWIxv312fmM25Mc2W8jUVIxJbxPclMTYQzi25t4U+ThcDzPo4eIrO1TmBx5vunS
O8w8e0wsCpnRQN1ASUZz1+enrhS7Et/VxPh9DEdhe72FHrJOpIYxhxqbcR8528vwWaHKwdrzYC/O
qk8NNOKKo9G0RT5Fbh1Y22kPe0psrohz1UJsch6cDwemVjryJF3kMc5kRyLuPY6sGBwxnJU6Ir6H
tJ37fkr2CjJiqO7UwO1yLf+XlPxiKbnCK1P3U1cR7GEoLfK0WLu/Bcs/SWkH0JpReCkpGzlTZFSn
Hedz1nZXcsumlfvyHPkO2tRLTTfyJmzyILmVcMXR5PYwdX4j9dwAjuLo05Bndqq5REB+M9qdJ1ym
PGJFreAlQvcvrE9+IzRH5dxBcCn1mUscXUM536Yvl8tKiMuamxop+3hNr5FzWUV0P3VbUIcdyEdi
4d9R8p/Lubqx9DV1G+X/ETmvIM0c7uVm5NOphx1ZR5I7upiSJEifTp4P04/OyFXUPmzjG0Z+j3sc
Svoa+ANGj2JYDtdwFfs8cTxrO1Wk7EnND6ds+KWmt4v+Gq47hRa//awZr9STSbGc5bZN3daO7G2Q
lPnYiR2xf02pWqG/G/Zh3t9GGi0jhrGHHZRtHfFUIV7NFhlbmENnyK5vdZV7jrQpfD3VCbkFFm7S
q1XsQT2EnIC1TsqRFTzJbYik1NvRr3YzDJcJdQZyROjtQH4HOxwpJTE9QjiXoxOkzGbUFju5ldav
Tl0q9ZBq68iuifMc2R9yHm3UUVpTZP0+mn5cdwJyN2QXXmpLi/5Krh6GlTDK0VEwAz5Dytuciwzf
cn8oJXQvxjbMUb86eZaY2sgmQpf0vWHUedQczXQrsHDR3EDNnEPNLHM+d+S5npz1W45O5Oq9Re/+
NdXAyI/BCo5eCLty7mzkAeQQh82dq+nLkhtX9xqnSvHofsZ1C2ll4X3cS0fku5EfE3ptnAuM/AG1
/SJ2QhrvPedrR57NibxT1rXUXZLePSRzjZnBG9A3Jbf74ePubY7sL5L0X6KZAhdJPrpp6jdik1z3
cqF/q9Se9wPSXCM1pi5DDsE3KUl3crtW1lHdPSK7czn6Im3dktxGSIt4gSttNJaj8+Fijl4vpVU3
w4Xo21OTD7i9ZVwVGp8z1/AK2FOorufcWW47Wkc4Uuh+lTrfpBldZ7eS26vwLfiQrWdsY4jcnaom
nxthD9iJOr8vddLIf6BUDbivd1Ouka313is1pj5LxUUD3yPntaksw6/pBW8nn5NeSW77qaVhtONU
9waJnpA7WWskzyHU2ATufTL6j8ROVAuO9oeDYWPGyUzSr0LTx+0naWjHPK54hhZcKL6ofpORjSdE
oXdEExolvlboRqFfCC8RBkckZWB3m7B6HNhnWD9iB9ez4qsHdl+63c1io+DLiNbZIeazw6Qez/jS
iCnS2Pmj+5ByJt4+MbjmmZSexuqB/XVGexmfQzzLCLEHJsRqubqC9KwzKCJx/QQ+vH2m0x/fmzgx
6Cb6gPXSENG3z9NJvwX+PD58iDWQ0A08l+H5pj5GGeyOCGJVzZOFEHcUcK5PeTQRrn4X3gzHErsR
S+pB8H5qwz65I+bVPEfw9lESu077Z/JkJdan9jRPjjwi6xDP+wJyC3jKHNjnJnlo2hI1Ewu7B6iT
EPJZ5FbwWUhUoi4jKiEa1XY14BTyuVIDLiXRNhJ/n/TZpFkDN5NmL3IHKae7XtZGFOvVujvn2ifd
XF3fRAntVVjh0ZRHE90HPNv1bUvZtRH7BJDdRx61pHmqEnSH7IkKaAufZ8ohnheH7NMBnidqngQF
9iktz8J81l58rhUaA+3+nDdsmZE/oYTtaAW7utVE2lFTk2aGFet6EH6OTfIcM2Qj1s+wMbv/x8GK
eCrkd0K2MR3rA35DmA7xq0M8bQnx1C8gOgthDz6xs387KdnhH+rF1eNoVnGUXyoFNg134fM8S+eR
8kL05yCn4AzIrq0Qnn+oBWl4Ihawcyxkn++Xckf2CchcaoYVD9/ulGPFyVtNzeTTf6OszNyAfCdH
6aEeqyveKuzZruOVQvZYeiNtdAyvgdXkyUqL9xS8Dt6NHdKynu2b59o+iJXa8tATA1bngkyOvgGv
ZX3ArgixvqftqshJa89oNCXnl2i6C3os3Oda6gzcABkx1Kuk70zOrDd6NXAwZATTvZGHwLHYyY+J
3/+EfD9pWGn0TrCrlrUpfT6aT7k61uhNgbkQi9L1sEzWf4Lt5FbCzLuJo6z/+DXI1j4pv29X23pz
VokwrT9HE9Cu5dq1oPfgRvI5QT5218qHpGnJaGZXPGw/fYX25Vc2ablWw7WOU0uMXd495JMG74Os
jQT2V3J21hiDN24tljUifwkkOgvsszBGaT0cDuFeVkJ2pPisROkw7MJdnIJfY5+/pVQf1a1fyV0w
LwR2T+AbjNtzGd/Y9xgwVgSscfl2XZT+FdjfbdmSNObqC20+XMuWmZnORHaSxnIqZC7TjyDfybms
w/sDkGeQD7smfJ6U+Xav9VHS00MDe192LCoijQPtU2OeS/o7OGp30jJeecvRLIR3Q2wpYG9AQOsE
2cj59iq0CL1V00PTfginQ1bCgwEcxfIDenpAGl2CXF03p58j3kJdtGvketNkD3ZakqdUD3B0F0fZ
IRCw1yUYCCcyIlE/IfvrP57eBqPtHI3G7qvsQD5dYSUsE/rpkOvqGmHod8JgEZwB3xCamE54M5oJ
yOWcdR9yIRwI+8Bx8Dh8CD5I+mI4HvaAnaE9i3KaWEM0A5DbwOuF3lnktshp8GI0F8JO8Dp4CxwJ
b4WHyPNeGIcTyaEX8q/q7FzkjpDy68Gcu4m73kpdDUHmfvX5HP0SfkRu1Ke3kaP1kF+Fv4S/QJ8B
bdlsmsuQr4Wtyf9S0rSEHmk4qkfAG9BQft/KM9FT/yYWNtYSsk+lX5Ln1z7rVyF6TWDnTVrNZ1eA
dwr5D5x7HmxOnn9Dz72bWEZKdTdHp8E5wrQ18B14F2kWQmtRLyCvQObcwFr7HcjPcRW8Ze9XyM+L
zQfn8xuE2WieYfcmreBVQ+rN60bZsARN7XnDKSctqGw5sVLvdjQROBXeiX4YxKpNjCn6KyF6Zc/F
/j1bw1i+N4qjb5L/TWiwJe9yOAj9Y8jvQ/qaWg2fhffAv3C0O/KnyA1hI3gFxOZNrH0OMaDkbH/1
04WjaLxJ8EBdu0vKM2i4X30Ju5Eno7G/i2yP/gI09D7vKmpyOXqsVNcKQ7shVh36LWloTZ+jGgsP
diDzq43APtn8xOlhyLNU3/4a4lXWoxaIPo0nrWknGN9YN0srlbXBNHZ0pE2TFTzjc/agtLJ7nH1u
Ab+5cJFdRmN3MWQu8NmVEbDLJcQz2cD6t3aPfRvJ32PnmGK+0OdI/oHdOT+GGmC08W6E06EDsVuP
VvOwKI+xRduUP6NmSmFnomNGGP8T+Axtgf2odpCaV/QL1Q8ykvh2pMohzzxkO6bRRoqxSGEbiv7u
7qIMtKnG5r1lkBb0VtX1GuFi0mNvLq3m/gT9WmT6gqlVIaOi+2PIGOIyDrv0Apc+5c6FjD8uM4WL
PbjYsLcSPgWxdh+r1naOaAafRm8t1tYAtacYZxQ2phhPvCz4RzQvchUs032UHBgNAnYHBfYX3OzL
CohiArsX0f4WzO50tb+D/i0jCXOKZ8c3Rm8vn6vYersfeQ+lpT79BsjsVQvYlxUQxft25/9xRld2
pgVEUgG7qnwsNrDzNfuNAyJ3n10EmvFWs0crYEdTYHeyMdNpn5L05epT4Ho0tq9RzhAzThptlFZE
mhR14pKGetPPc9YH6O3Y8ntkbFvhMyi7n9nG0fbX37+08Qsy3pSyv4C2uyXtL9Z5kmjGqELaUdZe
2iH/F3vfAZ5FsfV/zszszM6+bwKB0ELovYciXXovIfRQJYROaEnoJTRRioiKyEVERFQsV9RrQa+A
FRWVi6jYu2IX7Iio35mzq5Lo98m9ft9z///nuXmf/GZndnZ39syZOWVn9wxkzGS8npF9X5L9ijKJ
cQHjEsZDPGr68jZ7BWlmc1iDsSoj+wkl+y1lMmNpxh6M4bGD2fNzmrevYLySS9i3pm7k7SzGYbyX
Pb0kRxzOZhSM7KNT4XW/4+3FvM3+Scn+JRmWLIx8ng1YKjXgceeQvaaK20P924DlgkP2VdIc4jCH
sQnjDMYB3LZjvN2R8R1G9nOShHLYkDGkc02u/y5vV2HsxLiJy5sz8n0JvgrpdW4v+2lJ23EldzEq
Lqkb+dkcXspYj5F9vKTJOHyR8QI+KvQJf8slPiP7+tRKxrBO2Gvs1ZTrGe/kcvadqnwuYb+iymNs
ySVPMG7hkpAyDRgzGPcwsn9S3s11eNaVOxibMr7HeBUj+0sl+wblLK6/hjEsv5W3mYtUOpeMZeSW
KOY3j9dGKta3DX9nwPBzf83bKlw1mufW3OrwzaOtrNWHngpeYaLDt37CVdCZbFt15jobeC/bJpr9
eKIC11nofIaa19NqnrXEd3x+tqq8N937CLiH30p4k98OHuK2RfMfb3E6CZ9/H7+/cA+v6+b5ygtt
t2Q+P68dwr6Mkxl53bjXkfeytYK8cga5nTiOMZsxXLV+hDFcdf8Mr2SO8bFspeJxLv+KS3L4qAmM
b/LeLdHqfXdUd8Zq7om5KMXl/B6EPMTbvFZcsAdP83otOYTbyeuukddJItMEw+918Gpbjy0gzf5P
L5xX+Q1NL1z/HL6twP4ZNYifB4XrmsIVTew5lMO5DQv46mP5yVEP93TMsOWO7MFDXm9jwi/hhOu4
DvO1wncqJ3L/hl+hCVfhLucS1sY16+GKV0N5Yf/yCljkNmP4zma4CpS9gobX6hvmE4/fbfHYe4Cz
2LfMa1a98NspvJZeMZ0F+3ZkyFEH+Y5Kh28B8N7wyTJzL4ZvB7D/QYT9u55xHR+VxNtPMt7JeBfj
bPemLZ7g82/ktffsm8KsiE/c1ftwzT3cqub8NL+fe2YtRzj0+I0Yj9e6C24bhjxzlPENPupH3t7G
5+FvGcnbGJkD8UG+1lbeW4zLF/H2ZYzPMob0/Jj3Tne6JY1l94z4AI8plnfIHgDgqwNfEb7gY6/m
o2qENOTzvMutCr+ow/oksudcpEUeAFd/KB/L3ntxiuuHXxO6j/cm8pvL4fqrZRG3O07g9dse+xtx
N59hLd/dIEaWwshXhNN8VLo7D77GyGvLkeW4V5zb2YWvy2/mYrj6aBCPnTFcJ3zb4jAf2yXsfcZP
XYkXvvHaiekTPtfm2cDjNdjyea4Zjuu/sg8nfEcpnAEy2C/UjX0p7H9G5k8Rzn6neTTdzUfxO/ji
NebhfLdGBdnTLsK1QD/xGs7buc3h+0fhm7AbeEXKx6EHjM9/iH0yD4Raimu/e52Uar7McyM/kcHQ
6tnDJWui2fgBJ92YAuE7mxX52BNMH36jwfAacp/nCj98oyH8is4NTA3n5YPwe12Y4w8CmT0/NweS
J+aOnwpzcrLyp8P17s2BgQM6VQbSmH76CUpCHDSUg8pQAuqRRdIC2kEPGAxOPvSDLJgI0yAP5kd1
E8BAClShrfrQFFpCe+gJQ8DxZgaM5e9958MC4GX8XD8RfCgPVcHpR82gFXSAXjAURoGA/pANk2EG
zIaFUBpkz4yMHtBlQL++lWH0oAG9K8N6PoPTzi2kQjUoBQ2hNdlHXaE3ZMJokFALBpDePAVmwhxY
xLUDqADV6WyN4BxoA52gD9SGxbynFBSnvRWhBpThr5S3hc402vvCMDiPWlsHBsJ4mAqzYC4sia6b
BDGoBDWhLDSGc6ELdAe32nkMeFAXBsEEyIFcGrEFsDS7SV62FIwBYwnGFMaqjHWzs3LyZRPGtozd
GDMYhzOOy87KGy+nM+YzLmBcyriKcV129rSZ8lLG6xn3MD7F+CbjVw6VGDd9xjSVzJjCWJmxJmN9
xiaMLSfkZmWrdoy9GIcwjmWczriAcV3O5IlZajPjdsZdjLflTJ89Te1h3Mf4CONBxsOMRxlfzZmR
naPeZvyA8QTjN4ynqUquJxh9xkTGZMYUxsqMNWdQ4tVnbMLYkrEdYxfGXowZM3LHTfeGMI5kHDvT
lU9inM6Yz7iAcSnjKsZ1edQv3qWMmxm3Me5kvInxtrzJ0yd4dzPez/gQ4+OMhxify5uWPdN7mfFd
xs8YTzrUgjGel5fWWJdmrMhYk7EhY3PGdoRNdDfGPowDGDMZRzOOI2yqpzDmMi5gXM64hvHSvNkz
8/QWxu2M1zPewngH4558ooDex/gI40HGw4xHGV9ldG8PCpo/Uv6JVNKMUA2q/0tbCAl/iD6NUk0z
lU9zR0Dj2K20NFHZryW/V+tsy7yo7NdzF97vrN2zQ0UzUxLNvSX/he2fr/n7ewXNdvX/hxSh7Fmj
5OMkz+zum5AOMZI0DhPPGsucNVb5DZY+a6x5Fpj8hyhJdlWAiv/UViptVWJquYg1Z58i1PlDFCR7
6v0TKZJU/2MsdVbYmqTsKthE+sPdcACOwjH4BjU2wy44CMdhPq7EjbgT78RH8Dl8F78SSiSL6qKZ
6CIGiXEiX6wUG8VOcac4JE7LurK17CWHyylygVwjt8ib5H3yoHxZfiRPqUClqLqqteqlhqspwCsM
wQ+5TZ4unFfFi+SrF8mnF8kPOSNPnKxywbllwzwpaN6+wnlz5vUoH1TmvCJOLk29XTMsLd4pSvtE
6ZAoHVP46BJFzlZyU+HWlJlXuLWprxbOV1hfJL+jSP7uwuevcLBI/tXC16twsvDxFVsXyRehfsUX
C+crdSuS31Qkf6zw9WrMOSNPM0jN5CL54YWPr7m9cL7BzCL53CL5/ML5hoM4775fWyKkQMNVYdoo
8ff6sdEdUXp/lB6I0iO/V7tx8ShNidLqUZpW+K4b5xRuVeM7iuQfKZxvUoSKTTYXyW8pkr+lcC83
ufUMHqaNZn6RfN3CxzerXzjffEmR/ObCvdT8vsL7s4pwUdY3hfNjgyL5eJF8YuHzjyvSi+Mz3Xej
iZIT4QOyFz5hKeTieQHH3kI1T80HEdZRi9UStVQVcJ0V4L5MeiGsJtvIxZyVVFoCtN1pNttrzSZz
qdlIJRpvdRYqfzMe8Q68AwR/OV7yF9kVf5HdC88u02Rj2UQ25YhDT7rvd9NWcfDEt+Kk+E6cEt9T
XolHnG9aHBCPOY+UOAJSPC+ep/a75xY+cVAa2Q1baQZ9E05hMrXKp3Mn21tA2GvtXwl32lsJryMq
FCfZW5lkA9sr5m6Q+AS1+x5ON5s9lD5N+Xs53WxuAEG5XYSbzY2EW+iajvNToKq5FSTd7yazm9PN
5jZKN1L+dk43n1Hzjqjm36Kad0Y174pqRu01V/LVruKrXc1X+3nPNbznWt5z3Zl77PV8jzfwPe7i
e/x5z4285ybeczPvEcS1D7sV+fy9fuTv9Qv+Xr/kr8Yr/mq8Z6+xO4jr2ZvFo7yZ4xmyNQX12lpw
72ofoB+qNJUGQs/Ss+j4pWYp3fF/IgX8J1LA70cK+JWbUpibGvLMtE6n/4dn/sMz/y3PIL7IXBPa
RI046tWf5hXmjBhzRpw5I4E5I5E5oxhzRnHmjCTmjBLMGSWZM5KZM0oxZ5RmzijDnFGWOaMcc0aK
2q12E684/khl/qjA/FGR+aMS80dl5o8qzB9VmT+qMX9UZ/6owfxRk/mjFvNHbeaPOswfdZk/6jF/
1Gf+aMD80ZD5oxHzRxrzR2PmjybMH02ZP5oxf5zD/NGc+aMF80dL5o9WzB+tmT/aMH+0Zf44l/mj
HfNHe+aPDswfHZk/OjF/dGb+6ML92pX7tRv3a3fu1x7crz25X13ssvtIVrjvhK2kXwFZQKtgKWkV
F8IyWAPrac+tsBsu4Lihq1nWrIHH6beW44au47ihF8GH8BFcjAo9uASvxmvhMtyFN8Nmjoq2laOi
XcVR0bZxVLSrOSrado6Kdg1HRdvBUdGu5ahoOzkq2nUcFe16kSrawg2inWgPj4uOoiMcFJ1FZ3hS
dBXd4CnRU/SEQ6KP6AP/EIPFYDgshoqh8Iy4WDwER5ymglo8Jh5DI14QL6Av3hPvoRWfi88xIK3m
W4xxdM+4i7qGCS7qGia6qGtYzEVdw+Iu6homuahrWMJFXcOSLuoaJruoa1hKfqpSsDTpZ/OwC+ll
BdhVLVMrsLu6UF2IvVxMNuztYrJhHxeTDfu6mGyY7mKyYT8Xkw0zXEw27O9isuEAF5MNB7qYbDhI
HVaHcbA6oo7gEPWceg6HqqPqKGaqF9WLOMxFbMPhLmIbjnAR23Cki9iGo1zENhztIrbheS5iG45x
Edswy0Vsw7EuYhtmu4htOM5FbMPxzsWDE1zENpzoIrbhJM96Fid7MS+GU7xELxGnesW94pjjIrnh
NBfJDae7SG44w0Vyw5kukhvOcpHcMNdFcsM8F8kN810kN5ztIrnhHBfJDee6SG44z0Vyw/kukhsu
cJHccKGL5IaLXCQ3XOwiueESF8kNC1wkN1zqIrnhMhfJDZe7SG64wuvsncaV3o/ej6KdpmlFtNdK
a9FRW21FFx3XcdFVl9DJopuLlip66la6teilO+vOoo/urruLvjpdp4t0PVAPEv30ED1M9Nc365vF
YH2r3i2G6Jf0SyJTv6JfEcP0a/o1MVyf0CfECP2l/lKMNHPMHDHKzDMLxGiz2CwRWU7XEtlmhVkh
xpnVZo0Yb/5uDoqJ5mnztJhrjpqjYp55ybwk5ptXzCtigXndvC4WmuP+ZLHITrXbxbf2bvudbBDI
QMpZQVKQJHOD8kF5mRc0C86R+cGG4BI5J7gsuFzOC7YGW+XCYFuwTS4Krguul4uDXcGNsiC4JbhF
LgtuD/4mlwd3BXfJ84P7gvvkqmBv8LC8IHg0OCDXB48HT8kNwWfBZ/Ly4MvgS7kp1iZ2rrwi1jPW
U26J9Yv1l1fGBsYGyW2x4bHhcntsTGyMvCY2PjZe7ohNjE2U18Yfjj8hd7pIevJmF0lP3uIi6cm/
ukh68lYXSU/udpH05G3xt+LH5e0JnRM6ywec3HBrf6BHJDfSIu2jOf0P+KUE4W76r16kjtNQdkYl
ZHl4vvuCrhd4AaCX4CWA8Ip5xdjuKRnOYTxbFPDo3+5GJzzHo1PwuJTEO9+hdj2Me10P4z7Xw7jf
9TA+4HoYH6TeewIfcv2Dz3D/9HH9I5a7uxcH3J2Jp92diVfpqkN4zgSeM5HnTMFzpuQ50+c5M+A5
M8ZzZpznzASeMxN5zizOc2YJnjOTec4sx3NdBZ7rKvFcV5nnuio811Xjua46z3U1eK6ryfZYLTfL
QW03y0EdN8tBXTfLQT03y0F9tg8buDkKGrrZiWTSKe80ySQaR9DMjSM4x40jaOHGEbR24wjauHEE
bd04gvZuHEEHN46gkxtH0NmNI+jixhF0deMIurtxBL3dOII+bqSQ3kEjhfQOGimkazirZJAbKTDY
jRQYYg6ag5DpRgoMcyMFhruRAiPcSIGRbqTAKDcuYLQbF3CeGxcwxo0LyHLjArLduIDxblzAJDcu
YLIbFzDFjQvIceMCprtxATPcuIBcNy4gz40LyHfjAha6cQGL3biA5W5cwAo3LmClGxdwgRsXcKEb
F7DWjQu4yI0LWO/GBVzsxgVsYO5tdoZm1NjZZuofbo2KekY9Q7bZs+pZEOp59TxZ3S+oF9g2+3dw
7C+jSs7kljahdlzMHh8A996lJa2uEXFmY3ArZ1tDOygDHaA7pJKeQFwH6fSrBf1hJNnso+nXDMbA
eDgHJpJ+2AamQh4dMZt0iO5wFVxHo3sX3AIj4Da4h+rdC3thEuyHR2EaPAEHIR+eot8cOES/ufAM
PAfz4Ci8BovgDfqthLfgGJwPH9BvLXxCv3XwGXxDmsZJFLAJK2Nt0hzqYSO4CRtjY9iNTbE13IZt
sQPswU7YE/ZiH0yHRzEDM+BxHIij4Qkcg2PgeRyLE+EoTsap8CpOw9nwBs7FZfCBaClawpeiDfXH
V2KYyIZvxCKxEt03KDaTtrBb7MaYuFPchXFxj7gHE8W94j4sJvaJfZjkYoxhCfGOeAdLig8EaQji
Y/Exlhafis+wjPhCfIHlpCc9TJGpMhXLyyqyKqbK6rI6VpQ1ZS2sJOvJeliFOMBiVRVTSdhelVQt
sJtqpdrjVNVRjcdcNVFNwyvUDDUHt3lTvdl4vTfXm4e3ewu8hfg3b4m3BO/ylnvr8W5vg7cBH/Y2
ehvxEW+TtwUf9XZ5f8eD3l7vOL6uS+lUkaQr6sqinK6qq4lUXUPXEhV1Hd1cVNEtdUvRSLfVbUWa
bqc7icZ6uB4umuuRerRoocfoqaK1nqank4SdqS8SPfTF+iYxQb+uPxDL9Uf6Y3GR/lR/Ji7Wn+vP
xSX6a4PiUiONFFcb+hPbjTUJ4hpTyTQR15tmJkPcZwaYqeIFc4m5RHxuHjQPiS/MMfO++Ip4Wopv
aNKvJWN+HX+MbOiP9S+XE/wr/JNyi3/KVpCnbSWbpSrbbJunsu1se77KtxfYK9T59i92u9pkn7HP
qG32RfuSutq+Yl9R19jX7Btqh33LvqOus+/Zj9Qu+4n9RN0aJAfJaneQGlRQtwWVgkrqjqBKUE39
LagR1FJ3B3WChureIC1IU/uDYcEw9UAwJshSDwbZQbZ6OBgfTFSPBJODqeqxYFqQqw4G+UG+Okyj
qxRZSLezhXQX2UZ7SANWZCHtpQn3QdKAfbKQDpC9/ARpwHGykA5BIllIR0gqPE8acAmykF4mqeAi
ypXmiHJl2KYuxzZ1CnvqyssX5Cdk01yrvoSm6muvE6wkq/A+OEK6/6vwPbh4Tx6dr6poJrupTBrJ
raETjWb3nbKxMAVyYQHNQmvgUtgCO+AmuIOsgYdodB6Bl+Ftkk9fwCl0S1vjMZLksb/H7o89yOne
2EOc7os9zOn+2KOU3k9bBzi9P/YYp3tjj3O6L/YEp/tjT1K6l+o9xen9sac53Rs7xOm+2D843R97
htJ9VO8Ip/fHnuV0b+w5TvfFnud0f+wFSvdTvRc5vT/2Eqd7Yy9zui/2Cqf7Y4+AoL0HCffGqGdo
z1HC/X+CIq/xnf899npEmTciyrwZUeatiDJvR5R5J6LIuxFF3oso8n5EkQ8iinwYUeSjiCIfRxT5
NKLIZxFFjkcUORFR5POIIl9GFPkqosjXEUW+iSjybUQR0mCo1jGmyCdMkS/+JEW+iyhyKqLI9xFF
TkcU+SGiyE8hReIQ8kocQ8rERUiZuAwpE1chZeJeSJm4DikSNyFF4jakSDwIKRKPhRSJx0OKxBNC
isSLhRSJFw8pEk8KKRIvEVIkXjKiyEmmyI+OU+K+o0g88c9RJF4qpEi8dEiReJmQIvGyIUXi5UKK
xMtHFEmNKFIhokjFiCKVIopUiShSNaJItZBX4tUjytSIKFMzokytiDK1I8rUiShSL6JI/YgiDSKK
NIwo0iikSDzZUSSewhSp7DglXvdPUqRxRJEmEUWaRhRpFlHknIgiLSKKtIwo0iqiSOuIIm0iipwb
UaRdRJH2EUU6RBTpGFGkc0SRLhFFukYU6RbxSveIMj0iyvSMKNMrokzviDJpTJHmTJG2TJFOjlPc
MxPXbn5mkgl18H38CD/FU/g9/og/CUlGthGBSBCJIkmUEKVEabFGtpU5cpqcLmfImXKWzJV5Ml/O
lnPkXDlPzpcL5EK5SC6WS2SBtzS+lM6bhMc46uqH+KF7ox5p1OJJpFGHp/EH8AT9gRFKKPCFFhqs
oB8EIibiEBPFRHFIECVFMhQTq8VqSJJtZBsoITPlVCjpFXgFUCteEC8g3U5ACgTyoHxSPiWflofk
P+Rh+Yw8Ip91d0ntK+C7dHW2yavldnmN3CGvlTvldfJ6ecNv6vzP53Hac9kztOem7qmYAK5xkL8n
62qknlGj2Rn7BAjBizWoJbv4eVovfh7a7NcnPvImkDSxbHep3EXpjZzf4VLK73DPyCBR3hyV3hyV
Ighq99O0tzoUk1vlVfJiuUFeIi+Vl8mN8nK5SV4hN8u/yC3ySn4q5mgMfE9C3ip3Q1zeJe8iXVqQ
TpwqO8uusrvsKfvIdNlfDpRjZbYcJ8fLCXKinCQnyyly6u/1u7sX2cnFD5RdZBe6626yG52/hyQu
lb1lb1Cyr+wLnsyQGaDlADkADPVnFvjEWbPp/sOrd6Kju9FRval2BtXKlMPkcDlCjpSj5Gh5nhwj
s36PE/nqnV2kPmq9+6pJd9mdrt5T0tigO+lDV0+X6XT1/rI/XX2gHEhXH0vc5DMdfr16Z7p6d7p6
H7p6/9+9+u/Qw1lR1O6udPUedEVBbU+nKw6gq2hqbQHZ1+H5qY6r4fa7vWc7pvj8nfjuuvF99eY7
yuB7cWOCzu9VFOto1jLoo8UAYxjHBEzEYlgck7AElsRkLIWlsQyWxXKYguUxFStgRaxE9kkVrIrV
sDrWwJpYC2tjHaxL9kp9bIANsRGmkdXShGyWZngONscW2BJbYWtsQ/bLudgO22MH7EhWTGfsgl2x
G3bHHtgTe2Fvsmn6Yjr2I6umPw4gq2YQDsYhOBQzcRgOxxE4EkfhaDyPLJ0ssnOycRyOxwk4ESeR
vTMFp2IOWTzTcQbOxFmYi3mYj7NxDtk/83A+LsCFuAgX4xIswKW4DJfjClyJf8UT+Dl+hV+LcWK8
mCAmiklispgipoocMU1MFzPETDFL5Io8kS9mizlirpgn5osFYiFZT4vFElEgloplYrlYIVaKteK0
+EH8KH4iAY9SSCkVWUWajANfWjL0YzIuE2SiLCaLyyRZQpaUybKULC3LyLKynEyR5cl6qiArykqy
srOgZDWyoGo4+0nWlnVkXbKh6ssGsqFspHqqXqq36qP6qnTVT2Wo/mqAGqgGqcFqiBqqMtUwNVyN
UCPVKDVanafGqCw1VmWrcWq8mkBW1iQ1WU1RU1WOmqamk701U81SuSpP5avZao5aoFbqu/U9eo++
V9+n/67v13v1Pr1fP6Af1A/ph/Uj+lF9QD+mH9dP6IP6Sf2Uflof0v/Qh/Uz+oh+Vj+nn9dH9Qv6
Rfq9TL9X6fe6fkO/qd/Sb+t39Lv6PX1Mv68/0B86e0p/4uwpfZx+n+sv6PeV/lp/o7/VJ/V3+pT+
Xp/WP+gf9U8GDBpBlpYyntFkavlkaQUmZuImwSSaYqa4STIlTEmTbEqZ0qaMKWvKmRSywyqbKqaq
qWaqmxqmpqllaps6pq6pZ+qbBqahaWTSTGPTxDQlW+0c09y0MC1NK9PatDFtzbmmnWlvOpiOppPp
bLqYrqab6W56mJ6ml+lt+pi+Jt30MxmmP1l4A80gM9gMMUNNphlmhpsRZqQZZUab88wYk2XGmmwz
zow3E0yOmWammxlmppllck2eyTezTXmTaiqYimaimWQmmylmqnnTvGXeNu+Yd817zlY0H5gPzUfm
Y/OJ+dR85r/jv+u/5x/z3/c/8D/0P/I/9j/xP/OP+yf8z/0v/C/9r/yv/W/8b/2TJB6lVdaz2hrr
W2sDG7Nxm2ATbTFb3CbZErakLWVL2zK2rC1nU2x5m2or2Fq2tq1j69p6tr5tYBvaJrapPcc2ty1s
S9vKtrZtbFt7rm1nO9iutpvtbnvYnraX7WP72nTbz2bY/naAHWgH2cF2iB1qh9nhdoQdaUfZ0fY8
O8ZmBe2C9kGHoGPQKegcdAm6Bt2C7kGPoGfQK+gd9An6BulBvyAj6B8MCAYGg4LBwZBgaJBJdunw
YEQwMhgVjA7Oc/ZpMJbs03FknU4IJgaTyD6dEkwNcshCnR7MCGYGs4LcII8s1dnBnGBuMC+YHywI
FgaLgsXBkqAgWBosi/+UAAmYIBJkgkrwEnSCSfATbEIsIZ6QkNDVWbehDwtvwVugAD/D47AUv8Av
YTl7tVa6mOxwHfu2rmff1svs2/LVMrUMLfu2Auc5xAf1Tr0LH2VP1kFn9eNLfoJfCz/zG/tjhGV/
Vqv4W/GPxeL4p/Hj4kL2Z60lGb2KZHcJ0g5qQg/SRRe5FUn+p7wmg7Zs8i+rRIpDaUi1jSh/gyUN
zuyyjQlvtM1+qdueti4jWzlO5ysLFaG67ehKLGl3ZqvtTLjNdiHcbnv/ckwmb5H+QPebSspIVVGV
dJfqojppJfUF6daikWhEukFT0dQ9aiGdWf98dqjvvG8kN8oSxjDGmEjTYoxTl0uKcklOv4AP6Qd4
DV5Dmt9OvI5q3IQ3u1U3f3jWntF5ev4TZxXeJHH7byTfv0Pu/Zuk3v9P0k788H8r7/RL+hX9mj6h
vzQlWe7dRxLvQZZEB0iqKJZyT5OEc7ItlGwvn6VM+/wPZNlvJVkxkmG/Sq+fJcP/a1LsV0mVQ7I3
6UxpRrrDvaw1OI3B6QuP6kfMtFBfMDNIWzikD5tkpyuYUvp54sJJxH3THMf9LPPEvMLyzk61OXaa
nW5n2Jl2ls21eXaxXWIL7FK7zC63K+xKe7692G6wl9hL7WV2o73cbrJX/K6U/PRPyMnks5CUjWya
bczystnvSsz2JDM72k62s+1SSHb2/m+lZ+b/kvwsLD0z/zfkp95npv+hDG0HK8C9G7cODpDF8Tgc
hM7wFDwH3eAofAD94GP0YCxL2MXiXNEOlogOoissFd1FBqwSA8Qg2CCGiFFwmThPZMGVIltkwza2
768WD4tvYbsqr3rA82q+mo/Sm+BNQOVN8iah503xpqD2FnuL0TjrH33vlPcjWk3iBBO10B4W00YH
WFLHdTEso5N0KpbXFTXN67q2bolpurXuhB11T022ie6j07G3ztADMJ1k+mTsr6fqWThe55Fkz9E3
69twh75D34m7zBwzH282C81i3G0KzFK8wyw3q/FOs9ZswPvNQfMkPmSeNofxEXPEvIqPu+eA+Kz5
nrSC5/xKpBW85mf6Y/CYP8UvwOP+Cn+b8Pwd/sOiiv+Y/4bobE8F54qRwapgldge6xPrI66Jn4if
Ejvip+M/ir8mdEnoIm5jH4EgSy6RV76thceikp6FSh6HLLVarVFr1Tp1kVqvLlYb1CXqUnWZ2qgu
V5vUFWqz+ovaoq5UW9VVapu6Wm1X16gdeD6uwgvwQlyNa3AtrsOLcD1ejBvwErwUL8ONeDluwitw
M/4Ft+CVuBWvwm3yIrleLpXL5HK5Qq6U58tV8gJ5oVz9p8rWyLVyHfs3FLjvb62ArZDCnopmZOEW
QHP2VIxmT8UYqtcaUv6Vtjt/DJ879NWknOGrOcdRkzSiHPfEUzRzkZNEK9GaykhekmZEshK0OWG+
AN98ZU5CzE/0i0FxP8lPhhJ+O789lPY7+l2grN/d7w2pNGMdgyo0X31C+hnNSFCHZiQL9dwsAo1o
FmkHjd3cAefQ3NEbWvymPc25PY3EXOebovY05/a0Ik2tLWmsilq1BDxq1TLwSYKvBMttC7htCdy2
Ety2ZL+0X5ZaleJXhPLczsrczqp+P78/1PQH+kOhDre2Ibe2Mbe2Obe2Jc2dCdCWZs5kaM8t78ot
706zW3/oTXNbJqRHz2rdGxdvcsvDe/mG9T34pcRt1Sa+jWOJX8oEaV714ee3fFyZgLJ0ry0i2iu+
V033WgCGeyDG95pgHjQPQiLZU8egmDluTkFxc9qXRPUEusvqfmW/FjQnjXwotPOH+WNgPEmQ4zCN
ZMVJWEASIhmW0/xfAS6nWb8jXEX9kAl7aG7OgkMkn/LgKMmk8+F1kkNXwLFIa25LbRpH167idH/o
5Kw56O+eZcNA/x27HQ6ddT3n+5P/R7V/7YuxTNGW3BcZZ/RFy1/7AgbRnP5zmaB5vO4ZfdHSrdz3
lR8H8Gv7aWD9LLqO85TJsCXchip89bSolT9jOs9RqTye46yr7yRdnTR257+kK6RAZbKD6uN2qrES
r3VrUVwtWIvOJ7sObyS8yB0B63mOu5C0fkH2jhTtRTcxmNvQzn1xRnQlCYNiEMkW51zdBf2pxZ6v
feP7vvUDP+bHqfV1/Lp+Pb++38Bv6Dfy0+hOxvrZ/jh/vD/Bn+hP8if73/mn/O/90/4P/o/+TxYs
2oq2kq1sq9iqtpqtbmvYmnaszbbj7Hg7wU60k+xkO8Xm29l2jp1r59n5doFdaBfZVfYCe6FdbdfY
tXadvciut5vtX+wWe6Xdaq+y2+zV1t2zdTKC6EoyguhKMoLG6gnizfKkl1Sg+WIYcWID0pXyaBwu
Jk5sTzrRFWQ38sxPNulKpspSXB6VLFfnn1Hyx3Ryx6xQq3455tc1TOO471tReQKvEgL4iH6olqgl
IJy8Bakn68mg9I36RvDMfDOfZsXFZjEYs9qsBj+4LrgObLAr2AVBsDfYC7Hg0eBRapOAetEapDXc
q3tJi9CsRRQnLeIwlIS36VeWxtsxKIce6RIpqpFKg/K8/qcCr/+pTLJeQBXtaQ1VdUldEqrr0ro0
1NDVdDWoqWvpWlBLN9JpUFs31U2hrlshAPV4LVB9XgXUgFcBNeRVQGl6hB4FzXSOngUtSPovgHP1
Gr0GupKNvxO68Rqh7rxGqAevCOrFK4J6BxuDy6FPcHtwB6TzKp2MYH/wAPQPngiegoG8PmdorE2s
DWTG+sX6wTBekzOc1+GMDN9SgcfUBeYSnWuWndW7EdRbupvud8bK963QG2/Hu/Be3IsP4QE8iIfw
CB7Fl2VT+Yp8Tb4h35LvyPfk+/JD+fF/sfclYFFd2bpVxSmGmud5HpEoFoMzGoOoxHbGGNoYW7FE
RFSCRI0Qo4iARHEIMomISNAYY4gSJYoGiQIiEjXGKEEkxhhjiBpijFPrO+evY0fT9tf33Xfv7ffe
157v+/eqtdf+19rD2WftsqogyokKYjuxg9hJ7CIqid1EFbGfaCc6iEvEZeIKcZX4ibhB/EzcJu4Q
99jkI4XtzZay5WwlW83WsvVsI9vMtrLtbCe7G/s5dg92T3YwO5Tdm92X3Z8dxh7EfoF3mneGd5Z3
jtfKa/v3J63/P/mktYBBsP3YXLaALfonn2ck1zNxkjhNnCHOEuf+A58nYzpvEqf8tvvt8qvy2+9X
61fv1+x32u+cX4ffFb9Ovy6/O34POQSHwxFxFBwdx8Lx5wRyQjn9yVPSMPJENJ4870whTzrx5Klm
AXmCSeNkcXLIO7KIU8qp4Ozk7OZUcw5xjnCaOCc5ZzltnEucq+QdeYtzj8vgenN5XAlXxTVwbdwA
rovbmxvGDedGckdzJ3AncadyY7kJ3CTuIu4Sbjo3m7uWm8ct5pZxt3N3cau4+7m13HpuC/cMt5Xb
wb3C7eR2ce9wH/IIHocn4il4Op6F588L5IXy+vMG84bxRvLG86J5U3huXjwvkbeAl8pL42Xxcni5
vCJeKa+Ct5O3m1fNO8Q7wmvinSTvnjbeJd5V3nXeLd498hTmTZ65JHwV38C38QP4Ln5vfhg/nB/J
H82fwJ/En8qP5Sfwk/iL+Ev46fxs/lp+Hr+YX8bfwa/k7+XX8Ov4jfwW/hl+K7+Df4Xfye/i3+E/
FBACjkAkUAh0AovAXxAoCBX0FwwWDBOMFIwXRAumCNyCeEGiYIEgVZAmyBLkCHIFRYJSQYVgp2C3
oFpwSHBE0CQ4KTgraBNcElwVXBfcEtwTMoTeQp5QIlQJDUKbMEDoEvYWhgnDhZHC0cIJwknCqcJY
YYIwSbhIuESYLswWrhXmCYuFZcLtwl3CKuF+Ya2wXtgsPC08J2wXXhZeE94U3hY+ELFEviKBSCbS
iEwih6i7KFjUVzRIFCEaIRormiiaLIoRxYnmipJFi0VLRRmiVaL1ogJRiahCtFO0W1QtOiSqFzWL
TovOidpFl0XXRDdFd0QPxYSYIxaJFWKd2CL2F7vEvcVh4nBxpHi0eIJ4kniqOFacIE4SLxIvEaeL
s8VrxXniYnGZeLt4l3ivuEZcJ24Ut4jPitvEl8RXxdfFt8T3JOQjWyKQyCQaiUnikHSXBEv6SgZL
hklGSsZLoiVTJG5JvCRRskCSKkmTZElyJLmSIkmppEKyU7JbUi05JKmXNEtOS85J2iVXJJ2SLskd
yUMpIeVIRVKV1CC1SQOkLmlvaZg0XBopHSudKJ0sjZHGSedKk6WLpUulGdJV0vXSAmmJtFy6Q1op
3SutkdZJm6Snpa3SS9Jr0i7pHelDGSHjyEQyhUwns8j8ZYGyUFl/2WDZMNlI2XhZtGyKzC2LlyXK
FsmWyjJkObJcWZGsVFYh2ynbLauWHZIdkTXJTsrOyTpkV2Sdsi7ZHdlDOSHnyEVyhVwnt8kD5C55
b3mYPEI+Qj5WPlE+WR4jj5PPlSfLF8vT5Nny9fIieam8Qr5Tvlu+X14rr5c3y8/I2+SX5dfkN+W3
5Q8ULIWvQqBQKAwKmyJA4VL0VoQpwhWRitGKCYpJiqmKWEWCIkmxWJGmyFasVxQpyhTbFbsUVYr9
ilpFvaJZcVpxTtGuuKy4pripuK14oGQpfZUCpUypUZqUDmWgsrcyTBmhHKEcq5yonKyMUcYp5yqT
lYuVacps5VplnrJYWabcrtylrFLuV9Yq65XNyjPKVmWH8oqyU3lLeY88NnmreCqJSqUyqGyqAFWw
qr8qXDVCNVY1UTVZFaOKVyWqFqhSVemqVar1qgJViapctUNVqdqrOqSqVzWrTqvOqdpVl1XXVDdV
t1UP1Cy1r1qglqk1apPaoe6uDlb3VQ9SR6hHqieoJ6vd6gR1snqxeqk6Q71KvV5doC5Rl6t3qCvV
e9U16jp1o7pFfUbdqu5QX1F3qrvU9zQsja9GpFFodBqLxl8TqAnV9NcM1gzTjNSM10zSxGjiNHM1
yZrFmqWaDM0qzXpNgaZEU6HZqdmtqdYc0tRrmjWnNec07ZrLmmuam5rbmgdaQsvTyrQ6rUXrrw3U
hmrDtOHaSO1o7UTtFK1bG69N1C7QpmrTtFnatdoCbYm2XLtDW6ndq63R1mkbtS3aM9pWbYf2irZT
26W9o32oI3QcnUin0Ol0Fp2/LlAXquuvG6wbphupG6+L1k3Rxerm6hbolugydDm6PF2Jrly3Q1ep
26ur0dXpGnUtujO6Vl2H7oquU9elu6N7qCf0HL1Ir9Dr9Ba9vz5QH6rvrx+sj9SP1Ufrp+rj9In6
Rfql+gz9Kv16fYG+RF+u36Gv1O/V1+jr9I36Fv0Zfau+Q39F36nv0t/RPzQQBo5BZFAYdAaLwd8Q
aAg19DcMNgwzjDSMN0QbphjchnhDomGBIdWQZsgy5BhyDUWGUsN2Q6Wh2lBraDScNJwzdBiuGDoN
XYY7hodGwsgxiowKo85oMfobA42hxv7GwcZhxpHG8cZo4xSj25hgTDamGtONq4y5xmJjuXGnscpY
Y6wzNhpbjGeMrcYO4xVjp7HLeMf40ESYOCaRSWHSmSwmf1OgKdTU3zTYNMw00jTeFG2aYnKb4k2J
pgWmVFOaKcuUY8o1FZlKTRWmnabdpmrTIdMRU5PppOmsqc10yXTVdN10y3TPTKbPZp5ZYlaZDWab
OcDsMvc2h5nDzZHm0eYJ5knmqeZYc4I5ybzIvMScbs42rzXnmYvNZebt5l3mKnON+Yi52XzG3Ga+
bO403zI/sBAWnkViUVkMFpslwOKy9LaEWcItkZbRlgmWSZapljhLomWRZakly7LWUmAptVRYdlp2
W6othyxHLE2Wk5azljbLJctVy3XLLcs9K4NM5HlWiVVlNVht1gCry9rbGmYNt0Zax1qjrVOtcdZE
6yLrUmuWNceaay2yllorrDutu63V1kPWI9Ym60nrWWub9ZL1qvW69Zb1gY1l87UJbDKbxmayOWzd
bcG2vrZBtgjbCNtY20TbZFuMLc4215ZsW2xbasuwrbKttxXYSmzlth22StteW42tztZoa7GdsbXa
OmxXbJ22W7YHdsLOs8vsOrvN3t0ebO9rH2SPsI+wj7VPtE+2x9jj7Un2xfY0e7Z9vb3IXmbfbt9l
r7Lvt9fa6+3N9tP2c/YO+1X7TfsdB8Ph6xA5VA6Dw+YIcLgcvR1hjnBHpGO0Y6JjiiPWMdexwLHE
keHIceQ6ihyljgrHTsduR7XjkOOIo8lx0nHW0ea45LjquO645bhHHXycPKfEqXIanDZngNPl7O0M
c4Y7I52jnROck5xTnbHOBGeSc5FziTPdme1c68xzFjvLnNudu5xVzv3OWme9s9l52nnO2e687LxG
ZX3Mj4AfAz8B1gHrgU3AFuBp6vdoyDMIZesP9KbxE+BBYCu+S07JvuD2hY0vbHxpfT2wCdgCpFpx
YMOBhkNrLpLIhZ4HNh7YeLSmDlgPbAK2AKm2fNgIwCBEKyFkMWQxIhGDQQy9BPwS1ErQVoJaCfgl
4JeAX8I8S+KrsJTTeBBI8SigUYBBAb0CeiVkJWQVfKlgqYKlCr5U8KWCLxV8qchRp5DyqEErDVpp
0EoDex30Ouh10Oug10Ojh189xmQ5sxJYBawGHgYeBR4DngCeon7TgTy3UbbbgCtorAbWAM+TmAnW
TNRmojYTtZlgzQRrJlgzYb8SNiuhWenRkGc16v0hKvYGsDWArQGWDYixAWwNYGug2noPQ+1qjGgO
+poDeS3arkUMa9F2LfTrwLwOtevQdh1q14F5HZjXIap15DmVxWiHZS6NNUCKZwM0G8CwAfoN0OcB
8+ElHzb5sMmHl3x4yYeXfHjJJ8eYQspXIVoVolUhWhXCfiP0G6HfCP1G6IuhKYb3YmoMmd6UJYlV
wGrgYeBR4DHgCSA5txTCNgDoS2M1sAZIsfpB5oCbAxsObDi0/ijwGPAE8Dze/60GngB6NOTYMPnQ
C8AmAJuA1hwGHgUeA54AUm2FsBGBQYxWuGOZUshSRCIFgxR6GfhlqJWhrQy1MvDLwC8Dv4wae+Zf
YKmksQZ4EZ9bqAJWA2uAlF4NWQ1ZA18aWGpgqYEvDXxp4EsDXxpqtkmkPOrQSodWOrTSwd4AvQF6
A/QG6I3QGOHXSI0Jy0bd4ayewBBWBokDgeHACOBwD1IMpJxF4ihoojwIfRT00dC4gXHAeGCCB2GZ
BHmhB6FJgZxP/UILaz11/7FyqZ2IRCqqvcB8aApRWwbL417BJNZTPWI1Uv0l8ejj+5t1HJoTqD1L
WXoRsH9Er73Kx6vOywokKI0XVr2XkLJkEF6dwK+BF4AXgd8Av8VT7BPa6jvg98AfgD+ivgX1vjRS
XL7YoX3B6AtGXzD6gtGXZuTBlgdZQuPXwAtAPGnQToJ2Ek87gkONEIkfUUi1IOU6yBSHikZKjycU
gacVIaE1dZApGx2NX+MpQEW8HJrlXtj/vdqA7cAO4CXs89W01WXgFeBV4DXUn0B9Jo2t2MsPQ24D
tgM7gBRjJs3YANu3Ia+jsRXYBmwHdgCpdus87Yi+1IySWEkh1YKUD0OmOPJppPSDYTkYloNpzWHI
lM1GGluxc2I/pDQktgLbgO3ADuAl7I3VtNVl4BXgVeA11GM8mBwaW7EqD0NuA7YDO4AUI4dmFMBW
AFlGYyuwDdgO7ABS7WT0eMSil7HoZSx6GYtexoJDQyOlnwvLubCcS2sOQ6ZsDDS2Ym+hZpBAfsAD
SoAqEr2oXITMQzzlx3T5WP8R7hFPPcFsRb7iD+SAQUAh+w1Kw46BhkNnXcg2iR3AXdTdA9kXMg8y
D7IEsgSyHLIcsgqyCjIXzKR/3EeeaMh7gc7UPFpPbDpPHkt8RiIbmRAb64JNNJMYiNh8PJkr9D7Q
++B57kM04v5uQq+pEvksqaXwONnDDcjU/OiMtQmRUTIXXFzkYlziGPp2nOTgYUSpUQLCSgCPQlL2
IvPUJuiEHh08iWArAq8ItWLIYo8MSzEipUbgY7qsR+mJXEJHLqWRai33ILySiNjl4FKgRoEaUgYj
VR70lPCqhI3SI6OVErGqCOSy1NiQ2Ig1U0evoSaMhho7kxotNWDBCmZoIWvprJaS9cgJ9ajVw8dy
5DwNwHXAfOp/Hqj8inzaesoqunysr8Qedox8YnhKKufchkxsJRhWUyvJ20ZpfJA3krllDWo9mSSy
ZuI94AfUHgc5E3ID5AbI6yCvg5wLORdyPuR8yNlYtcvJGKjdzhMzmYfS2adHex6vNnrycazadIxA
OkbgA0SVAU0GNBlYqRkYazLfRn+pEhk55iSTmg3vgcg7s6iR9TqD8V0JH9ngysa4Z2Olvo3Za8B6
bcCIUqNErZzVsF0NvzlYHzn0ysnx6OBvDVqswUivQYu1kNd6ZFiuRbxU36vo8ijKSnpMPPGvp5Fq
netBeCWR2YARprg2oGYDasicHONIvmJ+xaDycqouD57zYJ2HGPOxTvPR03zEkk/Hko+1wmIUYIcs
QMtCsBRCLoJcRGfolFyM3LwYtcXwke3xBJtCZPobgcuJRyReo0afwEyQT5Ma5Lo1yEhrkCVS/5em
8awOKrukRgavH+sr8RTy1Ht71guZyR9Dpl2DbJlaxZ2UxvtLaHh0toxTArUeSfyAej5B5kAWQBZA
lkGWQVZCVkLWQNZA5oPZmxptKrtGNDLPWiZLj9YTm8Fz/qDWMtMHWT12WiZ2WqYLsfl5ThzQ+0Hv
hxzbj5ob6pSBXnM864KMuBFIzp6PLzJsLn3SOIbIKJkPLj5yaD6BcwW1oqmTBjhEHoSVCB6p/dSL
QmptMcUeHTxJYCsBL3ItciwpWeqRYSlFpDLPKkJ5FGUlPTJViE0OJjlaKz0Ir0rmMXBhLyXPGlSN
CjUqz4qmdLBQo07tkWGtRowaakWTeBzYiLXiiUXjWdFMLbIULVrqwIKMkamHrKdPIedxzqDOH0bU
GuGD7/EEGx1OMwagN1Z0A2XJ6okzgedc8uRZQefzDrAYWAIsBW4AlgHLgRXAfGAhhdTuQmILNPup
z6b47Cf5PGUxXZbQZSldbqDLMrosp0uS3ZegoiGxGFgCLAVuAJYBy4FUNCZEb0L0JkRvQtwmxG1C
3CZEbELEFthbYG+BvQW9taCVBa0saGUBvwVtLXRbqocWuocWuocWuocWuocWuocWuocWuocWuof+
6KE/euiPHvqjh/7ooT966I8e+iMCGyK2IWIbIrYhYhsitiFiGyK20fb5wEKcRZuA1PwEgCcAPAHg
CQBDABgCwBCAtgFo2x21PWksA5YDK4D5wEKsqSYg5SUEXkLgJQReQhBtCHhCwBMCnhDwhIAnBDwh
GN8QenxD6PENocc3hB7fEHp8Q+jxDaHHN4Qe32kY32kY32kY32kY32kY32kY32kY32mIYKDPeuBG
4CbgZmAucAtwK/BdYB6wAFhEIbV3sPAEJzVUHwbitxWociNdbqLLzXSZS5db6HIrXb5Ll3l0WUCX
RWTJYoUj1nDEGo5YwxFlOKIMR5ThiC8c8UXAPgL2EbCPQN8i0CoCrSLQKgJ9i0DbCLot2TffPIqB
xI3ATcDNwFzgFuBW4LvAPGABkBqd4YhhOGIYjhiGI4bhiGE4YhiOGIYjhuHU77eSuB34HjAPWAAE
J0Z8OEZ8FPhHgX8U+EeBeRSYR4F5FBhGgWEM7MfAJgpyFNpGoW0UYouia7cAtwLfBW4Dbge+B8wD
FgCp2KIQWxRiiwZ/NPijwR8N/mjwR4M/GvzR4I8GWzTYosEWjfmPptdTNL2eoun1FE2vp2h6PUXT
6ymaXk/R9HqKptdTNL2eoun15EZ8bsTnRnxuxOdGfG7E50Z8bsTnRnxuxOdGfG701o3eusHtpmN1
07G66VjddKxuOlY3HaubjtWNWFm+d7Hi7mLF3cWKu4sVdxcr7i5W3F2suLuIKQ59iEMf4tCHOEQf
h+jjEH0c4o5D3PGwj4d9POzj0ed4tIpHq3i0igd/PNrG022LgFS88XQ/4+l+xtP9jKf7GU/3M57u
Zzzdz3hPP/0MVBwkbgRuAm4G5gK3ALcCqTgSEHcC4k5A3AmIOwFxJyDuBMSdQNtvA24nfSYwjyLy
BPQlAX1J8GgwfwmYvyR4SIKHJHhIAncSuJPAnQSGJDAkwz4ZNgshL0TbhWi7ENEtpGu3ALcC3wXm
AQuAVCQLEclCRJICthSwpYAtBWwpYEsBWwrYUsCWArYUsKWALQVjnULPUQo9Ryn0HKXQc5RCz1EK
PUcp9Byl0HMUgzmKwRzFYI5iMEcxmKMYzFEM5igGcTzOgd6hy2K6LKHLUrrcQJdldFlOlxXwmkw9
wUgsBpYAS4EbgGXAcqAnR/HkJe/QZTFdltBlKV1uoMsyuiynS4/XDHjNgNcMeM2A1wx4zYDXDHjN
oJ/cnqf1O3RZTJcldFlKlxvosowuy+nS47UAXgvgtQBeC+C1AF4L4LUAXgvgdQPeqV7jQeSyuZTs
1wZ5AzCPfn+7CUjJm4CHgTuBZagto+WzJFZA3gE8hne2P/MgsuRGSuaYICNfZzXR74ofA1LyKeCv
wA7gWdSepeUvSWyF3I53yFngf+BBaJjw4vbUAr3o99KPASnZ8x57IBAZv5cQtUJaJr14SSErccL9
9++2/ft32/79u23/Xb/b5stgen5PhvXPfunm8e/QcMi7vS9r6RPfd6I0A1jLf//GEfMS4zpLxzKx
LKRFAKkLYblZcax4VgIriTy7p/jU+nxHfZP8WZfP/acvkuXpy/L3l6/x6Yv6Zvozr4A/XN2p760/
dYX8/eUb/fRF9uUfXL43n77IPj99xT/r8pM/fZGj9PS1FNfvr5P+cCWT18J/cKU86/L78x+u2X+4
3vzDtebpi/F/4/esmIx2hpYRxghnRJJPgQn4C3+P/7bfEnK/zmasZeQxihll5K6/i1HF2M+oZdST
O/xpxjkq88FvGfzvouU/hSH/GfwH36YyMfheZ4gs4i1vpne89w6fxT5LfLI5FZz3OIc41Hvu/9Xf
w2HgW1r03wtTusmS+sYX+U852ZWmjPb2C8iIzPiNzyT30TTli6RqKIvJDOK6/LzZzwm8WBo2wzXN
m/OcN5NgpvVhMYnSKNc4V/cnNLoyw1IdOY3UNYYRQz6y55GTOIN8HM8gH97k5TI/QUbIvr5a262z
j27yi0c+a9g8/NDeO5bMz0rTJEGuNGKqK81rZCmZiLBYnMD3xW1jH03edLz2cWs9GUpi0HOubt5e
LxFcqWXIvMQ3kmbNjEs2+U/vZgrq16+PadSs6Unz5s+LTTYNmZeUGBhkcOk8xvKna+YlTUueNW9u
kNllpOq9pKrf68fPm5dseuH15Lh5SbOS33AZlHxXH1ffYPJfSJAreJKSHxRMvuxFKsl/k1xvYKxI
Em8p66WoIKlLTL3wlXJenjY/btbcmcmkG5FLQCl9pD7jZ7jnzJvrfhwY5x8FZnWZPYFpnqx3zzBF
zZo5l2Q1jR3ygiuNaXHx/zaBTCab4ZXGFDJIPYeVxmQy9r3x5tlX9wzttz10Z1DrXXuvFxfW3jeW
NAx97capYVfPrPps9sjxMbcKWZ+NOvdiQk/boBmftlj3cSP3vfX6haEHd6wRjD1qf66r9Hu+1Xjq
Bdu9mMLP1UPffWeEsfDEnp6Wz0b0SJ13Xm4YsKqfqN+Fg91uxQ7owQx+9NAZWfFxAjOz+P7+3dPf
Srs7uXRZ+oqcyq7q3K2f960Yu0LpzBx9wXWbMfBW/d2Byw5l/JTQb1tg6O2qwA85b8asWxRbXDCf
n/Fh15FfTJ+Mkayefrz7+eCh6usHRuQNGBulaokd98aODzIbJw7anDY2ay77o16HU2wHx8cOLBzd
/NySkLnpw71PlZwckcGam8Eor828GEWmtwzm1mX3XMt+c0nJ4dTbCZ6L4+1LLl0228fLy7WsjNIy
iWVFrmX5S0WvnEy8MSupxDpuiWz3qJxHx7ck/c+vtzQh4zDj7bCwLPGpQbend14c7BJSMUqZzEcE
2+VFFi49pRAQCkLWrG9ZwEh85cOfW4+MLhoXEbg1YvpNF5eqFhIEeRtlPHHreFErIuX9XUtGOLpa
akYnl0U7kwNe35Px1/dH5i5ijPqh6UdV26yjgrLUX1hD6psym+9ENddtPjhx3s3pEe9FMK7nNRZ9
qavmblbzc79qNXzQ7c0bP1XM37mmvV/OwIL4mr5zTmd9aP3rxR/OzvJbl3Xw4TeMA6G//JZ6VyQJ
ZP/YLe+d8Nn+r+3ru6bDh3/s1bgTB5e+MDt2+4F9B3JCm7q8RKmLfz3dEX4x5eE33+x8ePvil/w9
iWfXfztmb9+y1B5nBn4dyo3pw9q8LN668vbk6WsqJx3o99XUVS+la0J+HVBQmsYr+8vbe7rv2/Lu
8fdbTXs/dalXmGT8gJrxt17omOL6dr3/rMzDiZd+2fZ+y9LwpAUCco9ZTO4xMfQeM83buQx7oe+T
9xGb3Gf+hXc1teH0JXea4OCg4NBevagNx+UKol6GUC9dy5b/t8TGx8Ihly4xaszY8Y/Nvf6B+T/d
ew4mVa38Xrd5RUNy9dTJXr0HFv+1cHFRt2GWym2ZUT9dH9a/4RU29+Xt+5rYzV+MXDg8ccWe745f
nPn91r8mO9+ZufmrbK8IV/1vx/Yf66/3nRgxRunLv1uljtth091nv7zih6Ojfcx9tv3Y0r3n3vAT
Zva2s1e+8H+5Qbu4pVtvnxMlLzUf+Nny43ZrOb9b3f2Tn00aNH1gQ/cXuSlvrLiZdeO1g0Mmfbt1
D/+Xl+7bOy6Zvvi+aEruuyE9/N96WftSPC844kZswrybfYtvsD4o2nKhwEckCFPNuvTG6GGyjk9W
nXx9TvFORnGP8F/HVU+6tWjo8h8CU5878OoJ9TT/D3KHcI7Ghz/6OHhXeTdLu+LqF/Tec8e17Ndn
7z2/38XWU/MDRh68/5353muGQvkp5d0jFdmYPr2QuuvJG9lnKfYNvZVQuRRLn33bR1AGRmKga4Cr
X2mf0l4ZIXHJyYn9e/acnpQQOOfxHAZOnzenZ+LsWZS2Z2LSPPfr05Pn9xwSRS68QFLlinwcIZNJ
hLn6u/o+fu1iZXSnCRcuXPgswhlJTzAl/+GGwu4zpNvn0w8mfDt/zmeFX83hZQ2oj5y/2N7S/VKf
lE2hmw9aWw5dPDf5DfFs6TgTc/onSb/5flv/5rgAhf+ZU99vDPhcxT8tfW1dt86JB++ePcrv+eGM
HnNGDe02MSl9zPOn4/UvxLz3xuScmw0Ls4+z/AM3NRQ/990nAX4XOvMvfbd49RRRVtSWC1PHLCx4
ber2V/qt++J9iZH9w2dD3/uibtwnH1a3PfBOZ9xK3vr1o2Z9qZXtc9nZqy5/rXpH2lTn1fvpzxlO
EcdzPk/jf7V91JDBr59uv7DwRvbk2cJM95qq/fv2vz9zgnnojhFx30+Y8rZs8sxFnWsne4nW+W6y
mfKvXmSIE9+7uzspcd+uS3WbFSxy99lE7j4rPLuPKJ5bOKaWYX9f/PVQY/TimWV/3IP+NblOb1e/
oN6uIFdoaB9q6+lHvvwX5DoTZs2ZMT952pzE/2iu09Zn7v0PG8NHvKZqbIkcFFV7733Z/u7BByRj
xjcu/2lQyPkXg9b7713n7jCOTd9f96dTb7Hv3Hj90NsN27/cNSsxdpEz9urefTdWfHLi+o6/Ssq5
f7Z06/n54PMTCe2Cj+e454yY8PWFn9s/3by8YenFt0ay+uT+WlviO9EQN/zE+doFk3u+uddOVE18
JV43/dHS1LDrXxL2Uf0WJvu8Wjf5XEaf7q8fE1wz9PNLXfBwU8LcxR2dg9bkl7wm+EvAGFXM1OCS
08tHP2eZHDf07fae6aKxu+9+rFmdcN2+UXrnuOirFYJbaQvm967fsLiseap3J7syI2TfndxX0l9I
j16RO7fS2D2yeV7xkI74q285cmZ79ps0pj85IrZn7Ti+/29kOyJvP/pkIWdSKQzjiY1y3tXRz+d/
Evr+nzLW1BRf2znghSH1J13qvzWQsQiegcOIYrxOnkKGMF54OhP6uzTqGRtU7ihxUF3q2APinC3T
fJiCVYlDV9+YP+Hg837sHo+qx0Wt0P3Ub92+rRO57av2DtCeur9z27F9H40za+f5zloy26vMMuyn
hKo5qZbqYV+k/7JaeMgnu/fhH5f8kPjq0M3rTze3XMip/ebTgBOpncd2BX+Z+cnx6Ud6n1KZP13Q
PqBoj3Z+iTnrXFWVZMKqW8V1M0YU+TuKp2YLBzRIZyyKPPD5B8v7j6mMiW53/fBDP/23K7ta+y27
KzWvci+d7k3kdRWxhvRMGZa1/xHr/Iy7I9pbvZLf2cOey2ve1OY/LTXyZ2Wx2NyXpcvc6X00L7j6
u8H1UQMPvrey/Wpsn9W3LHnFzZULJ4zrfzYpYrf1NrlB7SA3qPWP0yN2metfnR793UaA9MjVJ7gX
uTUFBSE9CvG8DKJeupbt+Z9Ij5wuu+elYe6QWYlxM5JMEVFDTUOjRvfv2ysipEeIq9eQHr3ChwwL
srusnj7pnu5TjyiqU6aoGUkLZk2f8U+3t5tEj915tZplM+0fOWL2SP/U4tpfK+n7YNmMUJ8jvXfb
4m77ELU++bf2/ZxiiOk+7PyfyseF7vsi4adJA6qWbxk+UOwb2Gv20Ct1YatYsaz3VLN+HPGTs/v1
sIWvlJ9JLPzTy+mikx/2uLNSf+Vat6rvPy/xjtmWNKFuQP3nz1d/UxktSvju3a8+q3u9z8FbK75Z
dtX/nPbnrl0/p209+5VX2WZ5+v2B997/Zm9wYynL/cuVRxrHa75R2XJW13LnghfTXtt244PgRfVf
JSjGWGbkx4wa1vOR9cMVnRWJB72Ot54LZh99bu3gvSVfds9I2HdcGvzm6volu5Q9gx/EHtBXDn3p
zgf3esxcPrPbO+mnJ22xPplO/b4hXM2//duNVT9fmfXtn+NG/1aQvfjCxsCnMqVn7hj/J5lS8vzE
6dP+SzKlx0zJz96sn8r/vGuftVvxn1/4l3Vhh97tVf41m51unNh1o7CiwXd1zz0nnn/ty4zUhcYL
Pyp3H0z99m5hF2do5AeyA7O6dw2aGTOh6/pbTvH6fp0t5zNHZ/02dbg1xSkf7Lv5U34QkXau115e
MeOLt3csmnb046wXNg3q3RZd7tzYv/Wg96uyit3CkYdzwt7uiim8E/vTl7/o/CuDv24K8qu5b4kb
NvLeF/Mt33fLsTDuT/zUe9eyUvn+0Lv+OcYRMewtK39dNvwH/jrfr6IHrDHM9pv1Xm1k6ktpz/+F
0XdIsXfz8+d6fjpmvt/Av+6fcquhs0+de1rpqDMDE5tfqZQuO3xma5DmoPts3unFzwe8MizKL+yE
193n/8xoXhk1LSiNKCR3rA0sJtO1LPNfeGR76iD5+1tdpcuOUE8netr8vIJ4T76PRvr9/RU3SOB6
slZO7hp/a0gEkUu9oKezqLG08X70pNnZbxIl3a4c+rCfy/1EE17QRNeE0oCl/oxRjFmM6Ywkxjy8
FRf7v8ZQwqDAEMJQyVAA5KUDxROBrAyGyoVqDSo402lJZUF+elFiQUalPlq5xNLEyBD06tea92/+
uk/+6uxTxPXp/IYbtkEnzl3IebPaOFFsV0zMIXau9RryISbMM2oSN3Surg04a/VkCbPhrS8PbR7y
FVxiOvq//8tmX5vNX5euuLLu3mSndleRDMvv/Rt+r3h59g77pavbpxwWOset9EIq/cWnqDN6S400
D5t93ak79Uifa9/eQp5uo06++S98UtzehYs8tl+52KtwUt3rryqXjFfckZb8xCTNUmD8I4qdSanB
dbaZTKVXWO/rnv+LPnoKMvxKC80XN9M+ff/Q50vqa5nb76cVqruZ31+Yfv32x6TlJZ+f9cts7y15
PPFgf3TikwfBYTsdzmX7pttqBy/wKZ4Tnm4x/ct7VbGHbbsXNjHJGzQxSSPiiM2wiYkHKMRB98SI
XkGiVNvs0MS4INZAAjklciOGfRmBdsJlWA35gdWrpaGRoYEhsE41Mo/CSIjnvP//bLxcOy+4lJ//
5tKvO6L2rZNGK51ASaQ++6dRYNXRk1fzRRu0pRZw/8hcGr59W7+Smt4536evy8XulGzVL7n9tIfV
OKDsjZNI0aW69sAIhpjcFZF2Aqab4hdWNl122GyqvCInPUci1/Lp0r/BQZKeF6Ut9kv+TlC9cryB
uV/qWvmf5B1bE9Q7dUQd9dovuxRbmO1v/b1ry3PRf09OJKe2mIWlnU3NEEmfwNr9gsHIjE+PreaF
3ceF39O8l9V6fjknpPww2etAy9/b/b7rk8x6rBraXl1RdDvwqqUsJeZDyIxbMeye6lLhkksCN8w6
dM6/p8Q8p9JAc69CWfaP52U5z1mO+t8XeveQ/8ZeoaVNHG1rk1ecupHF8q5w1kfT95YaZ9oA7RWv
6w0KZW5kc3RyZWFtDQplbmRvYmoNCjI3MSAwIG9iag0KWyAwWyA2NThdICAzWyAyMjBdICAxNlsg
NzkyXSAgMTMxWyA1MjZdICAxMzRbIDUyNF0gIDEzOVsgMjcxXSAgMTQyWyAyNjcgNzk5XSAgMTQ4
WyA0MDddICAxNTBbIDM0NSA1MzUgNDYwXSAgMTU1WyA0NjBdICA0ODZbIDMxOV0gXSANCmVuZG9i
ag0KMjcyIDAgb2JqDQpbIDMxOV0gDQplbmRvYmoNCjI3MyAwIG9iag0KPDwvRmlsdGVyL0ZsYXRl
RGVjb2RlL0xlbmd0aCAzMTU+Pg0Kc3RyZWFtDQp4nH2STW6DMBCF9z6Fl+kiApOEgISQ0iSVWPRH
pT0AsYfUUjGWcRbcvmYmTaNUiiWQPubNvCfG0bbaVUZ7Hr25XtbgeauNcjD0JyeBH+CoDRNLrrT0
Z8K37BrLotBcj4OHrjJtz4qCR++hOHg38tlG9Qd4YNGrU+C0OfLZ57YOXJ+s/YYOjOcxK0uuoA2D
nhv70nTAI2ybVyrUtR/noedP8TFa4AmyoDCyVzDYRoJrzBFYEYdT8uIpnJKBUTf1NXUdWvnVOFQv
gjqOk7hEWiEtE6KcKEUSMdGOKEVaLYgeiTKkjGamAhOcvcSv8yVotkZZlpF6dVZTXdwGzcgiza+H
Jv+H7lGWJ6TeYqB8SR/JcJ3cdRJ7ir/YXDtNv3La+GVP8uRcWBFeC9zNtBVt4HJzbG+nrun5AbWH
tMkNCmVuZHN0cmVhbQ0KZW5kb2JqDQoyNzQgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9M
ZW5ndGggOTkwNDgvTGVuZ3RoMSAyMjIxNTY+Pg0Kc3RyZWFtDQp4nOx9C1hTZ7bo+vfeCQlJSALk
AeGxwya8NhAggEQDBAiI4gMBW9CqIFHRWsWKHbW10lrUorXa1r6nZWZ8zHTmXjfanmJPZ0o7ndZ2
pGMf05npPKqtnXZarbTTTkdPDWf9OwmidR7nO/eeuff7ssh6/Ot/r7X+9e8AASAAEI+EA29tta+l
p6XdCfDaDICo39RWz6h5ul7iAV69A4A9NtVXW/farz58Fpg/7cMOBVMbZzdXn3+7F+DtLGDiNk5t
nlut2JY2D5izbwGs+8vsZmdRk+upJQDkGM7S3nlDR7ctOnEWQGUZjufrvKmHZ1nTgwCLRgFUjy3t
XnbDH1Lm3gRQfQuAtmVZx9puUAGdfz321y5buWFpxe0vfw3QtRvAFNO1pMP/yVbvERwf1wulXaiI
fcHcjWVcL6R33dCzfkGzOgWAyQIoj7l+yY2rkv538i8BnvRim/iVqzs7Ml0izr9pALsP3NCxvtvh
MA5i3fexP7+q44Yl372/eTrAUy04H9u9em3P2FbowfW00vruG5d0H+LPojjrBIAxFagtFV/+dOWN
SwoX6T1fgk0FFI7+8cFyyl+u67r5i+IzDebPrOewqAYGgoD9oh4OuAEs874ovrjP/Jk80gRgy6jG
Nhs60E8UGDCAE5biIPNxXrkJd4bsBgWoFA8rXFh+NMjJV7CUBBg9wylYBadkGe4kMGNe4MbCY89s
5nlAe8CA0h1wk46oh8nLPJDH5UGfVcylOwVW4YOfyEv9aRApcKdhw8RVcg2XlyeCciusu5qe/St0
X6nj7gHT3xonAv96YD+CxrDMdcNy9kPoYlbC7LCOcUPzuJwLlcrvQzP3LcRKWM6thWnyGLOhme2G
hcxT4OCuD+oiEIEIRCACfx+YJHjiG7ppMPwvWEoEIhCBCPx/C6wD9vyr1xCBCEQgAhGIQAQiEIEI
RCACEYhABCIQgQhEIAIRiEAEIhCBCEQgAhGIQAQiEIEIRCACEYhABCIQgQhEIAIRiEAE/q8BG8Kk
0Ke1n8ESSswB4OAxLKcBjxL9jLcadFiaDNVQBzOhGVqhA5bCcuiGdTAwFvwkNm3DX9HGj21Wwo1y
GzJ2YewvAOQHYz8Nf+GYoa+xzvFPjCf9vRWTj9hSUJIzcukbnzIP7Wci/wcWkMf7LwF5/wqFIsTV
l2kNE2TzuGT7xnBbZLoVtsF2Wdoh011wN+yGPXAPyvfBXrgfHvivrfJfCP+c5f9Z+H86Er3zlvgX
LVxw3fx5ba1zW5pmzmiYPq1+ap2vprrKW1lR7pky2V02qbSk2FVUWODMz8sVc7KzMjMc6UKanU9N
SU6yJSZYLWZTfFys0aCP0Wk10WpVlFLBsQyBXGKVrDWttSukhJp2SSv4BAMvaWeNznRKEGuzC0be
5WzLC7WSFKIEcQ1SfGPrIHjL2iSleGWTWRLrMHxux84zbXytxDnwJUzv8EtZTa12wfC2bby+DftI
iTWtdrtNYhz4moZV+JrewfslQyPq7bagZpoEja0Uh8beK0MllNnbkDa1SinhYlvb1RZ5FGBs+Ipl
ziL9hkFtQo1PgvhB0L4ngYk2Gy0DCTxSlogLMaAkjwZOicR/LpE4iZhm4pIvn4J2O1l2FRvU+lcI
tf7laFF/+yWbjgYtauf7+f6mVqMLRXnRDdKxOa2DmugaoWZJNCpAVsBgtAY1GqrAIboHibaCyAKj
rZ08yIBKh+aLpcutpbhC8u5oR0Hwod2wJu5SzdDY8M6JVYDdwlJcUAouQlLWSFHBRfDLJW+HBDv4
wdzh/p1DBljcLmr9gr/julaJ7cAGg8A6artapKSGxnmowqkQ27t46m6fTKjz+Nouvh/LtG07UsFH
nX6Z3t+1pJ2GCWkXfFinrmndZh+2SbHIayWjKOmwmW7jaRvbX2tdztNif/82XhrA5U6otVOKQWDF
pffXCjgbDla7opq6xDnuNjkap/ll53h3dPBS7+IVwdjr2BmOf3u/QdL+xY7eQf9gT7ljyJT+9hV0
ySs66DZrV/D9O5bIW90pbw3jla9d4aNIO2L0w1zsPa+1tkuovTQhbhwF1nFlX7tdShBpx/7+WrrE
Dj+uPrhkrLi0fnombCLB9dRI3haZQYvsA5zR2+FrC6lCDebRbrSm3dfWZg/6HZtKUY5tinyB76cj
RjmkeNFgfxHrhvNyG5paa302efcSU9NaftZqO4tyQ+O4mlixTb/zrC1oo4ZmoWFOMAq6wqS9JXiA
mXHPY9NQe3nUEattJChf11on1LX399cJfF1/e3/H0FjvYoE3CP2DWm1/d207Lx9/gvpndtikup1t
kqG9i0yWPUSH42ns1TU1SHFz5lNX1fFdHcHEUSnYy2x243ibxr9VHTpzGP14BuiZ6zecwbVpMTvZ
+DqaaoYwQ9gkQxk9srigua14Jjrl+JUJnpVmHNxGTw3b5qhd3hwyFkZmKHhoDpwT0uIgdjs9TzuG
vLAYC1LvnNZgmYfFtsPgdYrox3ZaMxyuMc2lNb3hmvHu7QL6zdrQ/A/ie2Js9xuFWN7tlO0vp16/
NNyCe/xrmaQqC7k+rqaVtTEhibGxVIoWMZV5JIsod6Q2wYzZbxD4E4JkECVFTeuwzdPGG4yY6gi2
qRfpCcKMekJ4hdA8CvEGiXgkYqZ6wLwqp3fWUoaV44HE1/a3hyJt4rZCl4G/6+p7wzYGAbdnC7Y3
xgp0h8fl9BbK2o46eq5s9mCL6W1SDM3NUswZmeB6bTWtPGYiPLlzZIGv5buosyW+3SenhDbbRPXQ
2Ml2H02BuGTaxBYKcaRB014ea3m5/2yg92Kg37azrWsyjuLNwR3wJTitfFpaWkNWKrOFThSdaxrd
yuX141YMt0Hn48GzSwWJr1gxUBOtZ9uuZvKGlstKEyaT68rGM0NLq1QnhgcPlqeKtonF+iuqp4Wr
MX1ssm2k1wgD1YMC2T5n0Eu2N89rPWoA4Le3tB5mCFPTXt02mI51rUd5AK+sZaiWKmmBpwVoIDja
YUYlt7cd9QL0yrWcrJDLnUMEZJ0qrCPQOcQEdYawjkEdF9R5ZV3wqaLW2oUmaBXQ6X7J29h6S1tX
f3sbNTaYgwGIkS1UgMQIFYOEUWqlaGFJtaQRqqm+kuorg3ol1UcJ1Rj+eDh4etT72wU8/piAW8FG
2mgI03BhHPzQ2Bhm0BHMvHZJ6bgOEROsWmzjMYqnY7upFNtRPVXq7eyg66BhytJcPq2zTVKND4hN
pklqHEEdGgFb1Ml96C2AnToxWDsEWUQ1Ho7eNqlNpJO2LqcD8Dw+D9ULkyVlRnBMRQadyNnWHysU
ydeJ0iFFO7ZRpsa10UQoa2xYxMnagkaK0uLKOwWs6mzn0docdDZjMHIZ9BVtC2qW4K3OZSyRMdoW
qoTgCdLooiV1Pr2romRZk48D4iuqrS24eLm0LdQA5zZIGlxRxgRThjqgdbBqGl0LvrbhUmnT5+kw
c4agSViPZ5AuWh4pCqslnWNaByacYH8NaoSycGccSyWr6BgvBrVRdOda+YG2ZWjsoLDBPgHycgW8
nVtpYIINnyG90NZ/pUKaj4lTdaVWJ6v7+1W6q3cI2kulG+dUydcux1gFHu8UNKMyY1rHjrLY4ryj
wJPAk2ormc4PkQth4XxY+GtY+Cos/CUsjIaFc2Hh07BwNiycCQufhIU/hoUPwsLpsPB+WHgvLJwK
CyfDwpth4Y2w8HpY+EVYeC0sjISF42FhICzcHRZ2hYX+sLA9LGwLC1vDwvywMC8stIWF1rDQEhYa
w8KMsNAQFqaHhdKwUBAWnGEhLyzkhgV1WIgKCwrvmCx9IdPPZfqZTEdlek6mZ2V6RqYfy/QDmZ6W
6fsyPSXTP8j0HZn+WqZvynREpsdl+qpMX5HpMZm+JNMXZfqCTIdl+pxMfyzTIzIdlOkhme6X6T6Z
Dsh0l0zvkulOme6Qab9M75Rpn0zvkOkWpN6K6XyvXNos01tlukmmi2U6R6aNMq2XabVMYyjVV3Vy
VZCK6ESsRJyNuAhxNeJmxLsRH0c8hPgc4i8QdbCI/Rivjl72C9iNOIAoIQ4jnkA8iTiKqMJRXTiq
C0d14aguHNWFo7pwVBeO6sJRXTiqC6JxDcXYuhhbF2PrYmxdjK2LsXUxROGsAryLeA6RBT3SVMRK
xEWIj3OCV1CMvkeki8MXmeGLJy6evDh6kQsydnjsxNjJsdExrrsqmnPgsoeRnkA8iTjKObxa7uRP
Rn/CyERfZeTsOLCd/sVEphVb65GeRGRw2mha5lRPEn0G0VfZuCi5rES6mbHIbR+FVEQnYiXibMRF
iEp4F+k5xDHmUW8z++5JsyXprV8iufkWs+3mWxJefwPlm76F5IZuJCtXI7l+ldl2/arNNyb2rIs3
JS1bgWTpciRLuuJtS7r61iQmrDVvrEmwb0BMqCpk7oGHEBlIQppLJeYh5mHmEdAydzG7mLuR9zM7
mJ2gBRvzEOxAxC0hfRzx3xF/i8gx+7HNQdAxj2Pf7yB/FPs+Brqxj5hdh+MF91EUHqZCVSJzO7MJ
XSwytzG3gAL5rcxGvLtEZlOIb2SulfXfYpbJfBlz7WGFyA8x3YdtvPvHzI1YT9utQj1H9dceKXS5
1VVVzBpIQHwC64fkNsux9A5KHyGyzB3MBrSoyPQip/03I6fruDnENzDXyPXrmaV4MYjMTcipfl2I
rw3xpaF2PchB1gf5auaaw1FidlUjlglspZRZwCxkFqEJ5zBNTDPyWcxsphFNqWFmIc6BaGYBTEG5
DeWbENdh+REsP4X8N8ijmeXY43o0aCeOtAR5O460GPly8DCdiO2ICxDnIM5C9DEe2Wo1jBEdJeKj
WLBcgWW663LGiFarqzKhnkAd0pcQGWYK1kdhvRs53d2kUHs7to+iVnYdjjO7q8yMM1SRH+J5yOkE
uaGyGOI52FEhTq2qxjIBBdL98pKmMC5oQPRjqYe2ZaoZgzx1FXI6UiVyuvTJIX1ZiJeGeEmI8yFe
HOpXGOIFIX12iGcxBtxCf9UqLBNIRHqUKcItWxgrk4BO0TBaRodcxaiZaNk5KkQNGt+Cq1WhczTo
HA06x4LOUaFzLOgcFdYL2MOBzkjGkVKRJ+JIScgFdEQyYiKiBVGDqAIPaSYz6c7IrBC/hlxHbUXm
hvi1yKn+HfIW5jaR/DrEPyAn6c7IqRA/ST6R+TnktP0Z8gna2ovPC4fV0XjYhgl3uLAwJOChGRob
fvLlVN6NLdjDubnuZwhL0BSHU9OEo1Q8MpySIoSVyclhZVLSuNJmCyvjE0NSryYuJHnV0SgxhBzx
Nu5AiVAdSlXRqASYDalURTkuCA43zpVXBkcEga4Ink5OcXs/stnkZX6Y7nBfM0RU3jjy+18rxClv
N7zNeCWNzv38sELEBt5Jj8fFub2POgvcjz5MxEceVogP7+HEHzzEiQ/dw4ren+UWuu/Zw4rb9zy4
h1F3Wjtf7mT5Tp0eBx99cmqqw/3zIRLtTSIP7iXipMfI/XsZ0fpARo7b8gAx7K30un+zlzxLSkku
3hciKTg8won4cHH4OGV5h0dYZLlU+SyZQabLbaYf3qwQj5L5pAXPlb4qgbTgdluAIVvJdtk525BT
594Z4tvJ3XLHXchp+e4jfQqxskpLBoCQ18hxufIN5HgMyevk+GEl9WzU4aIiN2WHWGqGI39Ikd3q
Nf7Omuh+5VVWfPUYJ3qP2dOo9sgxk0XmL6E1ZW5OlFsLz+UVuhvnoJ3moL0/wG2dfh8L7+fkuEeO
YwQdr/bJ7Y9nZlL+9HFLovuFjwnuWn34HXlir+tjh8P97sfE+6It2X1kUCEOomO8w+Xl7uFDnPjm
IYV4aBOm63dize6f/Zjwu4hhF6FD7igtk4fekSnKSynagWPvvEsh3tXPiXf2K8R+tOMX51jx83MK
8bNeRhwd4MRzaBrvmaJit/cMzka7D8xpCvLaqUFe5pGH0wyg498dIAPYk+rvw/in+rd60T63bSbi
rbiqTTjFWcRfbyab+xyp2/uIuA3xDpxlC2J2n7tvWh+7tI/U9ZHSPpLRR2yTTNZSk6nEFFts0rtM
2iKTutCkLDCxThPkm85f0PPnC84zGZkxWZn6HDEmV9SnCTHpgj4lNYZP1YPCoGA85TEaT4/nIQ+r
Nxi16miNVhml0rKcQosXhFbJ+lO7c4g+h2j0DXrMFFPAx/awP4Tf6pUa0LAa/RSYom5j56tvYh+B
R9QP6X8D2qNEQ7TeHL2NJOusUYk6k8Gii+Xidc7zq88/fn7g/C/OnzivrDzvPX/ovHT+5HkFDBHN
Yed55zNEA5VE483n/sNz3vOV50tPrifHk+XJ8KR70jy8J8Vj81g9Jk+sR+9Re5Qe1gOeRlcLkWIb
oKGlWoojyJurJZfYMMTyTVKR2CCpG+e3DhKyqw21ErMdz3OLxG0fYpDF1syb3zpEEmh1H77TwiQg
NbT33dUmismSn35rqje5TSqiwu7kNmiQiuZINqFavBqs7VkX5mt7Qir8kmEwK6NWyqntkHJr231i
WCsDWYsQbB/qNc4nAI45Ps9VZ59YRRmRJeihg/VQTU/PZQ2vMgdt/zdK8ohrL+8D4Q2HmvT8c32+
seaecDvJKlWi765sMKimTmxsqqbfSW6Q/E0NUkrj/HYpUahukI5hqbRxvqQVqnHstUHooa91a6kj
QrpBYGpaBhlKlEjmz2+t6iQB8JMLiOcR/4r4FeJfEEcRzyF+ingW8QziJ4h/RPwA8TTi+4jvIZ5C
PIn4JuIbiK8j/gLxNcQRxOOIA4h3I+5C7EfcjrgNcSvifMR5iG2IrYgtiI2IMxAbEKcjliIWIDoR
8xBzEdWIUYgK73L/F/7P/Z/5R/3n/Gf9Z/wf+z/wn/a/7z/l/4P/Hf+v/W/6R/zH/a/6X/Ef87/k
f9H/gn/Y/5z/x/4j/kH/If9+/z7/gH+X/y7/Tv8Of7//Tn+f/w7/Fn+vf7P/Vv8m/2L/HH+jv95f
7Y/xXzVi/o9D2//MNKC4Cx9cQDEXDCCGfkRsufTTdvbZoIxvr75NaVgfaLokY+9B0LHloKOjMKax
UeYkGMYGJra4yg98T4ZnUYVQ/kP21bAp1KBznHfL/Jq/Nxq88Hdrrw6vwSvw76HfGHgWjsCPQvof
wVPQhyM+C+vlchs+EN0BA0hbUDMPpsFcWAjLsWYN7IP9oV6LoR0K8QugAi3aH9K+Ch/Bv5Gvsd0j
35j/XpzlRhjCmR6B6TheBezB3d4HP4THoQG2XvZ3KN+W6UmmA1bAWjgIEvb1Q5esnQm3QT1ch2ur
QyutgVU4+zw4BE/CEhiEh1D/LDTBY8qfgIrpoZ4a+zMzeezP8u9G3I/vjm5jdrG90AO3wGPwB8C3
/HB34IW/771/AnbDg7iLO2AX+nQeW842su3jvv1H8DTa63m0zXr0ygH0x2OwmzjgYdgGm4gWvg3P
kqL/9l/pfBp24tiXw0/hKNptP/p3F1psLfrl+7j6xiu7kiwSjXGzAuaRGLgAi/6bK7k6dGMsrMeI
ux3nuRF33gpLMbrWIe9CHP/fCfgIXAHb0evfw6R4GvXVcCusInZMlS/BdmKFjdj+26i9D54hBdh2
LTxJsuA8jj8fd/kNwHxgCOUDoOeSmPGc4NlkL9Ay+3E4H4QpSYdjE/MBEYgO4+1peALn/y48QmyE
hS/hFASIkySh57LhdcSX0G7PwPNovzPYwgq/It/83aNvrAV77FAs4UK131wLRvtdl+Wm2/CkPIrn
axPG0JN41p+He+DfkO/E0gCeoAfgf2EMHMBY6sW1Xpp3HriQLqNUtkEMRgaMzztM9WOvj43I846E
ewV2jcu/xNP8WzzPjZH/YxCB/1lgor5+X/EuM02hV5CxT7gnorjAfPIlVuzHE38v0pvxa9nV+7IX
2Y8Uh8Y+VTwTqFYYFemBNYFb8C77FfwGfgE/g/fhTYzsV+FDtoD9GXuK/Zxr55SKEcV34SkuH74F
9185HreK6+LmcPu4eVy+IhPLSXhXNcG1eFe14315PeY1UOyOKuTuUVyj8LOfsxcUD2K3lZj3tmJu
uhczGT12P0GyVdECWZALBVAMDV6HyVmclZ0LucmawvziXE1+via3mCsphWyxwBUbFxdjteYXslA5
UuTEV+Xv3x4pMsYSi9uJYBgxjBhdhpEiw+9fKiwgJcUVzKQKtqQ4Q0iLYaKEktJSV1EKY4rHQgxr
MllMQgkx2o0UmUlKc066JcOmr6rgC9IT1O2eO2vqOiuS9OmeXD7DFBW7m3x9Ucl2fF1GPjSbHTkl
mQlOl1toaIpPL0q5PSU/2VWXnVFRXpdnz83MSlKu+s53Aqe5h/9jKffVhR/hBoGl/y+HW4EZLxly
oBSu904xm0pzckrZ0j3eHG1yzp6sguQ8Nm9PsjeZHPAlx2oz2Iw9Wq9Wc8CnZY232u2F5pyEWwsL
y3LEzQrnqaJYt/OU0U0pVIqQaDWcFcEallB0Jp4VjbHgdhcWuEoqmBJjcT6TWWIvMptN8UpllCnI
BbaotARrhDRllNFodhWVYjEjQxA2VOTooi0ZWPP48wtrVs7dvnPDO4+kP/idvNkrKzNuSZ02b8ue
qqn33f5IoSGzfjrbUVspmHSFvr7l1/a2pKuzf3jT9h/NZD67d2ft/FILx1y8cHFVVPVtHR23VtD/
gEQtoUZL5MA2bzPEGGL4mIEYKUahZmPUDKNSq82s3phqdBoPGZ8zKtRG8x4vqImJVeekqPeoC5JS
U1IP+FJysg/4clSsak8Oq99njIkRyD6GyVVbNgsh6yC60DhBa4hGcFG+aOGCxIsvLVwg28bqNLyE
CowVo5DPCnYj3f8kFxYYQTDGpzAWk/2S7Tj1YnN2nqcw8NvXcovs+oUL9WnO/Ndi+NKsgC9kLcXc
wBu+ltzYiyeTfVMD83y1yYH1nvock7rwMjuhDfCWV9Kn6lJY6p1SnOBVx9YnJLgcmphMNt2RfsCn
c0Chq/CAr8RiY11sgrXYqiczi4tTlWfNlhI2NrYs0eZiU3tF5ykL3azFRbcrulxQaXHRvVqdlFlc
xljcpejCLWLIX7al2EkC3uiCOdb0jZ3aCbErdbmZFo3alJ0fWOTONaiVxkDP2sBu9Iesuze0Y7KE
LCK3kyZFusZsr679+vGainSrtrAwJr1uDtn8AClxf21nz5UHhn8QuCdUNdESX7vYEbRG99gou1ex
BHNAn1fvNMSY6p15TvrbpRrOPDQ26vWgxhwHVoOVt/ZauRjWak3SpKdzSXkcy+3x5sXFJbFJe+I4
677ZFmKxZPFn9fqCrLNRUUWwr0COhFPB8+JcIEcEnpTQ8TC6qIEwCGLdWMZ65IUFcSmMq0g+CZn5
TEkxTRxmixwWaUqlKd5stgTziJCWaXwr3rdy7rpNxTdtWLe9ZvnPt8zYc0OnpW5hQ9Uyj2vlit67
Zlev+17Ht0fIpNalhRvXNSyd55m8+vaZ3fvnGZICn7cuzizoqJm6uKXYu+quhcv3zM8uIbH0jJjw
jGzC+KiAZd7JWfkqK5k0yVmRYi9k8535B3x8iZieqHASQxxbXlF+wGd0czqzooJVWSexWVmpceVx
5QWpqd4CJ24p1o3Z0eg2WsLBYcHosIyHB74wjWCAmOStWSyTMA6KMzAKTJgo2bgUlsaGnBcyWVZu
QmOFnRRH8tnMEnKqICdD2HM3z+vSc8hax5SaivcCpc5spxCYlp+bnPLUcwXpOYGtjoLc0ilnAn/M
yhaSYhVzC6My7Ektk//8YXFFjjlVVBUWavNbFwW+G1jYNrUwXVdYqBKEJF8RyQ+8PNtlz8F6TWrB
9OtINznhnZyuVxbS/4vWiFEjYfxkQBH88SiQsY+e1BvIDBga+8gbTSUmnyRzWUNjJ70+tb4+S6PJ
ZDPv93ZrejWSZljDgcagadTs1gxoFFpWo0koIPlcPpv/mJczO9IP+hwmPq4gbiBOiuMKkDBx9HuZ
mZm59VxcPJYSdKZkUx5mJdZkSDCwhgcTDHHx8aqUPqLJYIvopGo8skVFxTl9KiwdwYLKKcrHNHha
R2gk4lHF4LMaXlwjLlhTGQ5McIXDck2wKMppShQdmZiz0zIySorTHXKixrwt4MF10byO55j6ig2G
qJzLme/pr33omhk9Ffi2wZ51Tf2sRdYt7b291Z3rPUx0fGZu4FPtz1/Nryvwra64m2ubPuX6unse
11V1rS9rarq9yGmrvH1LYN/08uJUs7aQHGO6lrurE6qXFqHtl4+NcqLiAUjDDLbMm298wmDQH/QZ
TK54p9XJOh/wWs1p2amp2Wz2Xm+qIUp50BcFKhLdFxufxgrUkNQ4glCWu8XmDNsEKisnnMxxS9Bb
zWr4ACO0mAYc5mc5X0UJkzLpCcwYP59YjfbAvbuKKrgSlmN1lkzX51OU8WLpGY9WX7lguWff4Z6f
3Vy90h1jL6tx9m5d1Z07uWyyLYarbJ9RkhKrLo7+j42zarISNMXR+7iamqzzn+z7oNtkDQzOWujN
jR8ZHj6mt08uqJCjrwuj7z6MvgSww3pvNR9nTrEbWeP9XrtdY4ap/LsJ5xIYSDAk8AmjCZyaTTBz
Ztb8AAaXJoVN2evVYI0lFuyxhi2JiULsHVGyHT6Ldb9tdCcmjAQNEaaGt+VYSDgr5/NLV7tjggXQ
KPaQ4yexwSud7fVe3zvztTeuf+m2JbvmOtmL/SUbOpq2VF2vzGnxLbtZ80TNDPGrz/aevsW7+gfb
Y2/6zvzyWjJ35Z3T9j9Ec9Bs3OaHikfx2Wyll4+OUkUd9KlMhlh0s5l8KuqBN/A8P8yf4BU6lqc+
taY56nl8gEln0+9Ppp+Pse/nRabPqqc/DTCQmXq8iT4reovuU87C+KwyQiO78qyrSH56QXejmy9d
vWyJEaObw6c4VxE+rtF4p09uLqbznC4hOy+wLDfDFL0hI8Fi1HHq8nV982ZP6oxz5dvzMmy6c+y1
F79X4xNM0ZhczGneWmaBSxkVk+jKv2F7e6bmqSmFsRneRTOWU18243b/pPDhU1oCXOPNsXAJ3EFf
gikc1Xqms5slevZdltGzi5CxLNnCxPUx0aGDHR3aYLRTFF88ZTgFzgVrFpwNxm14V/i0ydINyTcs
DWIzTaRk89DSTLtFx1kL8/5UbshzBdYrfC+8cOGsNpavriNPemc5LaoS9cWSa2oEfHBAr1Qi+R2e
PDMUeE1clBK9gjEfd9AXDyZiJtCnCy1Gh9kGj1TlJcs6gnOWBJchnyWyks65tijTGCUfl888F+SZ
CnVJmTWlbG34XNCZ0UrKRexxfMI/5b1Go6L7pk8lah4JR4ssJQwtEkqAEpVLabW5ZjcpSktKD/oa
E0tMi55YuHDBQd9CPVFniXWKGmUNW/OATmlQ5/V5MHXTpVPuNWBvj6c1rk9vJzXvYv6ixsZKO63U
YKXdvrgd6vta6X6NZGYr7ayX+Sht14rOEE8V0ccjUVyzcIGcZlABla6zwVsw5CDX+F1IU2wQiIXG
nNlCUyve9RMjsjifo28o/paOvaSTHU1Wx3hm1lfa/bdaGxZ0lNV01KRGx2XkBb6VmWbRqeNsafkZ
WbVz0i/pok32tPzk7PqGDKUu3uEIrM+wW7U0Pj4uZ9M4T7nDcN2iGfWZmXM2LgtsmzGZt+AzFUZL
jY8o566uzkgy8DNmFgfuvbymrduXY9Y46mbkBu50e9JMcdFy1YQQC3mYc6KHPXCTtzyfOiAvC0ku
JSIlCUkeliHMQV8iMWU/kZWVedCXpc+N1RfoWf0DBYbSPpWqIjcnvi9taOwE9UUa/XmywUhmpDnD
vjgVuvYumV+2ftD09ivNOTFgZXNGBV0SepjlnIGbqM1UcTZHQWZmXUuGfITCJ+rjck3M9PkLikvn
VuWYVPEZzrA56m6clp1sTJ0xvSCwIxjvlxvje1yDV0gonrmyObCttgIngOCdx76NGV8HSTDNmwqY
7fd6wRyVyCbujTKYDRoy07wlmtfiuYhOicEofAo1MVtYGreoZPE8ijQGT4mXnkELCxTjNxh9Q0bk
24sJ3e1M/Infrj3W+/bvVr0a2L5lY83CKYlV3fUbbjN8Obr/9Orzfzpweg258Nrvq1btmX3vC/Pf
wDVOCzRxGvRgFpRBrzdHrZSvXhtk5Gfgo81eb4a5NNGV6mJdD+C1bHkCnxoO+sz6tC2FoUxWSPO4
Dk9PYeFksCayZX16+bam2ZvGg5760RI8U/I7T+rB8Yt6/OoO5RvTZUeEDfmPDe0Vby42PvikbZDd
TbrVFrEg0JWeZ1VxWktm3iflOn1F/cypWfsH/c/dMX19kbW82bdh4wdlcxrtKW9WeR1WDONoU3bd
ZHZefXlWYqyauq7SnWH46tP9p9YkkEXtXf/J3tlAR1WdC3ufTDJ/mUBIJmECSEcImCIGBEsjpRgw
YqhokaK1/mAmyYQMJJlxZkISRIgQkqioAfkT8adVUZEi9e96KW1TpRRbGq1WGlvkAirYFiPQFrFF
zvfsfc4kE0i7uOv71vruumvyruec/f/u/e69371PBJnifXOn1jr8uumjzBVuuYQ5vEiUFw7NzvHk
PFPkyZK3vZGbR/Tvr7mEPd2e5LbYUxpd8sMjIz27mMuhKyXdYbd/9SItY/lQc2UPHSPX8wB1jfvN
xeJieZZxlA0YP/6Kj+POMrVaY0dXnwsa//D1OdVXTRxzh2fCmNyrp+Zkjx9/pjpuz2dbrrx2lPXw
hEtHzZw29swPbrnK6+i9XA3vPIfV6WRkl4qHC7PHDLpi0LcHWX42SBOD0gd5WaGDRl4g/wxAYXFG
dvEYjZ+Uka4FrmZX0gjX11xJFuFKdxW6ZrpKXCmOFNcF+VkXWC5YU5iVnZ9iSVmTnz7o6ZycUeO0
pwX2WT5s2Hj78lHdn1QHB8R2dc/lDUvcftttxsfVbcaH1W1hebSre0mvLyi+NMZndy/6uO+tJL0k
e9KMr8+8feRMf0XwigmlLTNnP3ZN6eB5t+VeNcGbN3veLTVXfO/ZO6beeVvSwUlXDblmSv6kyy4e
/a3Som9XFQ3Ncf/21u/0Hz7pkvGFX7tkZHHplbMaCtMypZ1G6MeSXk9+iT18Y+GlA9Mtbm9m4cgx
xZmFrv7FmenrBmYnOftbNZfFait0imeKBju7bP0z3Q7HUFtK6vJBYw5eLid9r7y8jzNuMHLWL7/i
y70XX8y1TX488m00PuvCrAsHGIv76wPVUucqM2Lc5OHu1Ae0K8/8JH10wei8acMuuXpJ0d2LV1vu
teddcfstn/vPXOmLTBly4VcmXDX54SeTLpb9nc5Ne4RlB7ew8sJhF2weMmTwM0VDsriPDbdZbOsK
h2dnjtZGc/pr/bOXe4e6Yh8eLld+0vI8tXc5G/PkUZwn96zxawKmy/g1wTmX7Eyz28YvA9iyF/Zc
t81vjwFynqZrF2TkTp04ctqNI6z9ModfpF1gdY+a8PE3rf2/s27GLQsmpo2YbNlxxlK7cPKoodd8
61Kt7vKJw7MznJd+ecO1ReYF++bZxQ8u1RbOvmKE/MNmmxls2NLCHcwmxhd+JWmbsKRbvJaZljZL
Sn+Lxbat0KolpbxgtTusL+SNvVhLPzh+nPo1l/xM+tS4YGXKX+mFd+/ebWn585+/9H3yCe220+5D
fEnLdkcXDkqSDXGBE0la3kTxrmVqryZPHJSLeMygLzto0DLcohp8aIrv0jd3p9xw+hrLK/98iEZp
daVlZ9ImbmGy1bzCLKvQ0uWfvrLLP1f6giX5BZvNYVf74neYWrrL28YbLV4I2uzCwKCkrCvm5aSs
O3OJ9q5E/Vp1Qbf80xDtrnhJSo6T+2Ni+cr/MvlASvKc5LdSipRsUPJ7627bd23P2S9HNjkmOlY5
rQlJyP9AGdcttyUkIf9DpSUhCUlIQhKSkIQkJCEJSUhCEpKQhCQkIQlJSEISkpCEJCQhCUlIQhKS
kIQkJCEJSUhCEpKQhCQkIQlJSEISkpCE/O8TIf82otDk/8D9YtEuUsRUGKz/STjEMn07z2Z9G88W
9XxQ7+TZpp4rVcoqFV6tnmv0nTzX6YeEQ/uQcDbtHBGDRbZ+mGczZQbTjnyuVM9V+lGea9RzLbUG
U7dTLLNMoG6LerbSh094NtNOK3Xlc6V6rtGPi1btE7FZtFom8HxQlW9Tz5XquUo9V9PCBzybaX81
LcjnA/pJnisJryW9i2eLeq7Uu7QPqdWJTcYkTTT/p2hpSeu7/wdp/USVihn/xme5JdkMa6KfpdIM
J4l+zrCI/euyY52NZjg5rkyK8Di3mWFrXLpN/MO52wzbxajUyWbYIaalvm6GnTZnd/lUcaPLboZd
Is81xwzH+mzp7nPs/9Y4ztVshjVhc71mhpOELf2bZtgiPOlFZjg5rkyKcKXfaoatcek2cVd6pRm2
i6z0J82wQwxP/9gMOy3Lu8uniosH2M2wS7gHjDfDadqMAVeb4X5iQsZD8l/jTXaYdjbChp2NsGFn
I2zY2Qgnx5Ux7GyErXHphp2NsGFnI2zY2QgbdjbChp2NsGFnI5xmrgYZNuz8PREUtcIrqoVPNPCu
FRHh5x0VlSJA2CsqKFFD3EsJGQ+RH6Z8gLQo4XLSSlVdWUfWvUrcIGaIKWbdcFxOiFiQGrWiTLUY
oGWvqFO6ynj2rdeIy7Jlooq65abWKCW86l+KjdBylTkCH+XKTV0Bs4Uysy2/euaTcva4ZX6VCuVR
66u8/eSVdmvqq1c157R8/jbqab1ctTSXtDDxCCXCyhpRnrLtvsduaD+3X9+Is4AciTGWqNIXUrPh
U+0bYy0npU6NPKj+zd2+R2rY2dfLpn41r0HzaYzKCNcSC6mnV/V2gRqNv7sdWbKKEv9+hiqV5UJi
ohiD1CnJVxYtU2soAhWqpKxZTZkoI5IjnKvGGKKFBlJjo4gQlr2pIK8W/bKmT62bevEc+seJscjl
hK49R4dXXKlGGrNfbGbkOppCW1W8Z5E2V/U6omJ+tY/CjF7OVz4t+NSMyxH7lBWMlSLXgF/NZbmq
I1upMee4otu+NeIS8srUCjFKy5Avbu3E5tywsZzPoJhPaK4KlZu7zKgbP4vlqq4cY0TtBWM0sh8L
VX/kGKer/FiPF6hxNag1vMBsUdrRR//O7o2x3w279axn2WaRssNcleJTOmN1jPajahaMHKk5QFqV
at+vehErbVg5gK2M1LBaaWG1xoyZWqDCDapsVPVH9nF0t9+pUjUqVR/lqI314jPt0Ffr8ZaK9SPQ
vXp7ZsHYc4bdDHv29GG+6QVquucwovrti9tLUVW3xqwV0xQ095ZRrlr1sUqN0rDs7O4dHJvnMvXv
bRvjNHKq1eqWrdSo3WvsUB+rMVaqRvT4qoBpD1kq0r2Swt3nhN9ccXUqtUyN16/2dKWymU95M5nX
24q16JNnQbxHi6h9XBXnL0pV2Bc35oCyTqnpLWM+169qVZseJKIsVaF6K2e2nB0UUPM2t9tS3+3e
EWfvTsNKxlkYvxPLlGeJ98yxvRPbL1LrAnP+pE/xqtVvrI7RcfbqWTFhenaupc7dUxG1RqXvKu+2
SkTNiuF3jDUeVj2uVfMZ3/MeaxmnjOEDe1aM/ywPZNigRlyk6sxTtoiK3uv8bA21qraxQyPm6VJG
as+cTIzTJvsxV/XDp+rXqZk1xtKXf/TjqXtrrlMrs9I8m4x25pp28atWjBVQbe6qeK8h7epXe8Mo
36DmP0grvW1ytelz58fVvpLSxhlq7Inz8+a1Zs+NdVSldmBsH4TMsyKg6gRVC0bffeZcxNZKTdz5
Y/ioqNq51d01pJ1Cpg+NdPs54wQPqLno8VAxOxknUkDNcdC8fxity97X9fJAPrWbYvu12lxJge4T
KqB2iNc8j89eV/nqbOyZ93NP24nn7MeJInY+TxA3mn4kZqWv0eLlpPe9g/3mCjGs7utedcZI/eZu
8Sqf7FP9rFa9mi9idxvfv8yVtj7/u8LZPvUGYoHuE/g7yrrRXmfbmD5uV2XKA9SYd0TDj12r2g/G
2Xu66efOPo1nK88ZVCGjrOEb5yvf8v/mviX9V8+dq+9We/LN1p7zjhs79nLvtYGycDASrIh6rwyG
Q8GwLxoI1uR7p1RVeWcF5lZGI95Z/og/vMBfnn+lr7o0HPB5K30Rb6nfX+Mt90cCc2v85d6KYNgb
rLkkUhaWyWG/rzxQM9frqyn3RoPeqmBwvnduMFjuraskNxQO1ESp44t6I9U+1EQCC/2RfO/0qGp4
gT/c4PUvoGAk5CuLNRMKB+mb7BoliwK+ucEaX5XKoXw0UEak0hcIVwVq/BGVTJcDFQTDfrpTxaAW
+KsavJFoOFgzdzQdCVT5vZXBcGBhsCZK5bjiRqdkG7KfxhD81SH6Rj9VC/P9XtLpWsSLuSr9YW+0
0kd/o7JSsDZK1F8d8VctkMOaXRmIqDGXBULoJFIdjES9NUF67feVyqQaWcEboB+Bsog0Er2QKVXB
On+4zBfxe8sqfWFfWdQfNrtYW1pe65cdRGkDTdDFUr+0KNUCYcJowJb+Kn+1v4YpDFZ464Lh8ksC
1b65slPflRMRm066VBsxJ7HMF1JGVrMj58UbxMCsFG8oiDlGq34pw4Qv6e5U90xFKoO1VeWyK5Eq
uXaweNhfXltmNq66FfZHaquiyjB+cwHRg5qLot55tWQbNo9VqI3ICY14y4NltWokE1W1sH9ubZUv
7K3zSy0969Ffb1auC0QrvT4vZebSF39UGqDaJ9Pk0igL+GvKSG+oLg1WmT25mpU7X2Vf2RAOVDET
fSzzWhrHRlXBiJyDELsiEMFasnXmX1mlRu0fVlTU76uWGf56ykUjcs0Fvb5AtV8tKNknNlIgEmUN
ytVb468zFpAvrOa1GiMF5IYKhJjVhlDMVvmzjLF3b9uJsXmcKPfzhBtZI7JLX8u/fELcBPsDap36
pOlQygqjG2Ffub/aF57vDcqcuGhF314htlJvqAnIDfydqC9q7LYxcvsrBWXB2ppoOMAauzbIEpf9
ns6ai23j2YFw0DubVFbj/EhlNBqaOGZMXV1dfnVMX35ZsHoM9YJzw75QZcOYsmgFOzS+qIrLYt8L
1jKpDXLx0i0GKXPkssfg1YGo7GJpg+rwVTfMmKIWlIzgSliScqVJN1BWGVeXN/u0qrbcmKTyQCRU
hQLDATG9DE8uz2i+N6Y7WMMazwt8FQ9RKiv1NFUTK9xnj1Rx5STZDxiszNh13dqVpc22vqE6kBdA
SxRHxGSwQBvYE3U1VUFfvFL67DP9a9jbPSd4pBBOqdy/AI8jy1T6q0JnDeh8pkIZfky5v8LH2sz3
RUL1sd9xCn0ZJ0tfP5pIEnbRX9dFf0LGbwWFlieE+veftD7rxH5SLBNcLvkvyGjrz7d8Wposn2Q/
3/L9+6vy9edbPj1dlf/kfMsPGCDLW2463/KZmZTnLeRvSZNVefnb42yRIuTvStNEuhhEbIwYLCaJ
Zdw5mrlVtHADa+V2cJ+4UzxA6EGxVrSJZ8RK8aJYJX4iVotfizViL6kHxTrRpX0ovtA+0SyWCVo6
XfL01qcNidPXD31DiI1H3xT0fRt9N6OvEi0R9N2NvgeRR9G3FX3/iT752/R30PcB+j5B39+1DzWB
vlT05dD+hb31JX0zTl9/9A0l9nX0TUPf7eibj76F8rf76FuDvqfQ9xL6dqHvHfTtR9+n5Hwh1mop
Yp2Wib6voG8U+i5H35Te+iyLz0PfnfK/I6BvHfo2oe9V9L2JvvfQdxB9x9B3Gn129GWjbxj6LkHf
JPRd1Vtf8htx+tIRL7FvoO8a9FWgL4KmJvlfLND3A/S9iL430NdJysfoOyFWaxaxhrlaq12AvtHo
uxx9V6HvBvTN6a3PemGcvq+g71JiM9FXir670fcg+raibwf6OtB3gJQTok1ziJWaV6zS8tF3Lfpu
QV8AfQ3oa0Pfo+h7AX2vyX1stwq77VRRUX1RUdEpGbGeLiqsLywsPGB3CLvzw8Yy7to3sD6ns24+
bLSnUKK+tbEk3d56zG6j7uGivPT0vKIOa4qwWkva0kNtpxxW4bB57Pb61tbW9VUqI9R6qrE15EgW
juSxtF2oFFiE3VIo2lXEYREOiwrKmNUhrM532AnTlXzaaLUKq+3tyuLi4qNme/yEHDK1s5yu18tK
ycKa8naoMBYMtRV62w7Yk4U9ubDwGMkzvaqZTlopnpSiaSmWxkbR2GjXNDuhRhWxWDRHyhNPPOGw
ag77qSLTMDJmwzDF9cWyrw7NkfpzLNPbNo5kzWENtTUWetPT2w44bBgB4+Sl5ynraD3W0eKtk6wy
jjW2lRjWmWlaRxqEfseZJ7nHPKnCmvp+Y0VhkZKuA1ZbzBBdUpOtT/Ngt5TOSsM8KO3LPLKZPZSf
McGqaVZpHkzi0DRHcuPZBnLaNKfj9NSpGGjq1KmnZdR+Zmph0aIiqcHp1Jyug+2+xllKZigpbDzY
7kzRnLJ7agW1hpwO4XR82DhFDBNuFr6d5zBlTJtVs1EOK62vUm27kpMXNfGzYoEtRWWpFeVMEc6U
gmLVf6nWojm7jSajwtlttcIDtlTN5uoxmzSczS5s9n2ljGDqEanSXi91NNU7bd3pi2TNFGGzKtsR
TtZscppL5CQzZSmG9TCfTVaS5jPtl2zYz6nRqcZ4AzqtpgGdvQ3oiDNgquZMO3CgpP36wusLv4XI
/pJ+wGnFGPSyscSTLDv67wxoNw2YatNSHRgweVIRg5sxQeUVFDWdbiwqSE3RUqUF/4UJUy1aao8J
DRumnWVDm2ZzqGVW1KXCBUVLly4tKnAa6VPlEJUNmbaYDWUYNxLCizhSlA1PyYzisaqBvmyY5Ezp
sWFyspZqbeNHjkwaMWZFNdIzU7vNmJqqpfaLmbG3IVOtWqoyZOFYu7RkqkOkOg1LGrZ0q5DyelbN
Lm2pjOmyaa4eY2JNlausiTldKZorzpyGAVO67Vl4wGWhQI9BcYOpmr1fvEWlTe02zW7atKhLRZRR
sarLyJlqmpX6KZrdtKsZiflnZzIrLdaTmV7VjDIttrVpmk3ZFmumakmp3cY1rOuySeumObU0ly58
jSXtUnyNS+LCukiza2lOvcxXUlK6uLSEn2Np/bS09AOTQgWhgpv4mbF+xvqrPVd7piKFngOT0mxa
mmNSxevt7aECl9XavKc+LVWkpR5nfsY25nAh6if/c65IFZniQvQcP+Cwaw7Hol1W6+SKXR11aQ4t
LdXGTVXKFXjfN7plrvhGo8NG4UkVu3adaW8vnZRm1dKsk8pLSk6VGD/H0pK1tJSSEiEO9EqJxVSK
o5/mSO8KRdaXeXrk8x3K43ep39D1yOeNsnvOSRVvyJ+KSWmxQr7GmJSJxaJEyTEhu2fvCscUyfNl
0Z6dB+qHrNhzSm5Ca3dXK8cqfUd6aZMjtCdp9pT2dnnFbG9PS6Lz7caPnLf29uQULc3W2dnZJswb
qlOsTfpIWMoawlXCPTfsny8mVPmiNdyQnEL7zqyp8gYjuNEbfxahnxnW5D3f+OcUVTxJ3XeyhWX6
zJnFYtisb1/rFfmzZ13jFRPNErhZMcAMJzN9GWY4RbiYSiNs5c7rFlnz+bAWjerZrJ4r1HOVeq5X
z8fU8yn5ASs2q+c++dT6qWeheobVU5XR9lbPr56fZFfPDPUcop4j1XOsek5Uz6Lum/v5PAeqbx45
ohT5JyCwCr6W0bkYST914xzASDPlqLDOwESN/1YNi/AIueX/b0KDRYG4VVSJRWKF2Ci2cBPeI/aJ
o+K05tKGcL+epM3QbtWqtEXaCm2jtkXboe3R9mlHhfxTIBb5p1H4JpL9lndh9d66Tb01Z6VwqHUg
/+QKt/FLT/SOT2ztHZ+8tHd8ak3v+HXpcfEUoX2vsXf+zf16x0u39y4fXNA7/w5X7/yGV3vnL5zV
O7/Z0zu/+bXe+fe/3Dv/gRm989eV9M7fcNZ4njjdO//7Tb3zN3t752/e2jv/1VuFIykWtxL/SDi0
uPj2TXwdxMXbM4S26V7po1LWp05MrUwNp9anNqduS301dR/hE3DaNcp1mWuO61lXV5or7UZKnSv1
SGW3hFUrZ8s2U2g57VZa36fKnS31qaeloDMmlyl51hB6YMiNUlLDA4Zle7KHZudmj8ouGCjDuQNv
4inThg5cMHCfx+lJ94zyFHlKeUZVztkyCsmNiWehiveSgcMMUaVzpYaBN1Gup4WhfciogfukoD8m
bUMOX1BCb4pMGWVKVMrwmuHHsofmjsotzp2Ve1PunNwqQsW5zbltuRtyn8jdmruDtNfJP1dkuZtM
kfWqzLpnS7OStm7ZoGQPbRsyx5TXlRSP2KDGURA/6rz2vL1IO3JgTHj8E+M3jd82/tUJ3oKlBUtj
b5lb0Dpx8zcLJ2+NvacUXLk/xrTKaffGuNpbPK64dfrC4nHXPnvtq9e5r5tQPO76A7O2Xuee9dqs
vbOO3TT5po++t/e2sTL/9kHXuYlPvr3k9nm3N92+1lfk+1bpotJVZdvKtpftLuso21d2ouxUudV/
q7/UV+Sv9FeSc0KKv9Rf42+rmOCvmfu7ufsrL6uc5q+pPBp4oPKywOp5FfPfnr+/qlPmVV5G+O3q
PwRfC80LRUOvh/aEDofLI5MjocgDtfbaobX1ta8v2FfXDymoKyA1FIrWTVtYdeeuRbfeNTS0Z/Gi
yGSZs/id2vol9UuWLtm2ZP+SvzVObZzdWIGEGpc2PtV45m4PMuzuYTJtyf678+7uWDp66eFlLiS7
cbbKWbps7LJfNXma8psKm6Y1zWi6uam8KdzU2NTctLrpsdwdy73IyOUjSQs35S8fu3x78+zmtZSc
1rylqVzmNL/YtLolGcloGdIyrGV0y4SW2S0VLfUtzS1tLRtanmp5saW9ZVfLRy1dLadbna3prUNb
R7eOay1oXdz6Wp/7O7bH46XXvm19vW8xdmuf+y629+Kl1x5qfbtvMfZNn3shth+6xdhd54qx1lv3
uy7zpOduoP8fdfuf5tYzrjl4KbzfPfZZe12X3ZNxT6H0NvgP9gGWCJv2MLwZtWQe4ZiVZDv4MOUr
u+2U5lL+dZ/rstb9Mv2e6yjhMn1uj/eLieGDX1V+eF8vb3kCOf0vvKT003OUp+wyvLXykrK2rPOq
9JjSsve6YM59M/GV0usN9aTft/m+lz3R+3bdd8oYpenV1Bwp73eTjK/IxkNGTU/oic2Y9HMrRmd7
lH81586jclZMXDFzxU/xgqPuj95/sjs3t3u+C1oLultDpI8x/Xef3tXwqb28aropo5SXl36+NOZT
6ZH0tqOyPUMOS+0PFEoN5Ki+5RY/cLNaI7Me/AQPO4cQ/rDtW6b/k+tIribDq8pyMvWm7hUmfenr
cattDuEqWhjVto+cOb3WoeHR53R756qzfPK5Xln6/CeUV95hen4pG5SXHqVaaFapxXIkbV0r2x6a
lT30ocqH9kp7PXR09Y2r21Zkz9qLH91reE184TY832WGj5v/Nn73PAU/e5bgq3vJuSXw5L1k1muy
D/Fybh3DZ/srY+9YLBaXI+glu5ET/17w/P8dqTl/4STpJYZte8Swcl/Sl4XliRKKRiaH5nHaKKnr
F4rKM8c8bxCZFhNOpj3y/FE1QoZwOiGyXl2/1a8u2CdrhvbIc2bJfnUGKbnbQyxknkKexqnGm5A8
oaaqp5SlUjidZOkzjWeWudbY5ZnDGZRvnkdKlnuJN5snEtI0ozs0zTy5wqasliLLL/eu6SdX9XKv
6Qu4XazJXdMhvc6av8m0tYuNPb4uef2c9W0PD3p4xcMdG9I33Lzh2CNJj9gf6feI96G9hJLYyc6N
0x79CC8Qfcz5mOfhjvj7V/bQx+59bKPhQUyfke6JPn7v46uVTyl4fHvspuhxPn4MrxF9YsL3k78f
/kHVk84ndzy18GnX07s2RZfUNy6NyJNb2YUxqNHU9bvbs9zLV9l7eoGWrJ/U5umbtMN6p3ZE32aZ
Cdfr2zw/EpM8L8IbYlJOSIwTSdoM4abkEW7e7+mfCQs1j5tpx4VT0/QOUnZq/WnnUsIzRJ52PeEy
wvP0Q1oj78P6TqERk39r5FP9KOX3Um4cKTvJ247+GfF6+SJ4T7+R3I3kbKJnnfSsk54k095hfZsa
wXY0H1Up81RqB2U7KNtB2Y5erSVJzeQe4ov0EGU1tCYz8v76e3E97lA9PqznS518q35KTKNesv4S
Jd+l5E7V5+t5l4Fss1FpXiw1u+tFedbL+o0eySvQCe/rBXz3GiP+gFaO0Eqn2Yq0UKdpIdnKqn/b
io0WOlVPpVUOK8vMo/Q45miS6m2naQ85rk3oecQc10b0bKPWdmpZqRXtpcNsP+cafXtOSN+oZmm7
OC6scm4hA9yQrZ8QA/UO4dH3ixzmYhAM0d8Vo8i7GEbDJZAPE+EbMAm+CTfAjfBduAm+BzfDLXAr
3AZz4HYoQ085+KEC5kIlegMwD+ajvwqqoQaCEII7IAwRiEIt/VsAdVAPDfR1IdwJi2A9K/JhVsQj
vE/x/gL+Af+E06R9CWdAZ6ZzmJtBzNFgbDkEWw7FvvN4zye9CqrJq4EghOAOCEMEolALC6COOvXQ
AAvhTlhEW3fxXgzMv9bFPH4GJ+CvemeSBVLABgPZB1+DCfANmKkfYq0fynhe35+xBX4IW+EF2AY/
ghfhJf3djJfhFTio78w4BB/qOzNt+qFMOzjACanggjToB6yjzHR9W+YAyNQ7MrP0VZk1+vHMCCwA
bJt5F+/FsIz8JmjW92e26O9mriZtDeG1sA7Ww8PwKOmPwRPwfXgatsGP4GXyX4GfEP4p/Aza4ee0
9wbvX9D+bvL3EO4g7V3e/wV/h5PwOZwCXT/hFqBBElggmb2VAlawgV3f73aAE1LBBWl6p7sf4Mnc
6ZCpv+ser+90V0Id/Aza4ef6Iffr8AvCv+a9h/de+ETf6D5K/G/6Kvff4XPCp/RNWVb9UBa2zsLW
Wdg6C1tnjYCRMI78CfqqrCt4N/BeCHfCIriL/MWwBPARWXfDUn1j1jJo0rdlLYdW6t1P2QcIP6hv
8pzSd3pYyznlrNtvimT9GZGiHxU2sIMDUsEF/aA/pMMAyIQsyAZWGjv9JDu9g51+UgzW17Pbt4gL
9LfEUNr8CnjhQhgGwyEXRsBIuAjy9Kj4KoyhvbHCLS7lPQ7Gw2XwNZgAX4cCuBwmwxVQCFNgKlwJ
RXAVTIOroRimwzUwA66F62AmXA+z4DswG0rAB6VQBuXghwqYC5WMNQDydJrPWKugGmogCCG4A8IQ
gSjUwgKog3powDYL4U5YBHdhp8WwBBrRcTfjX4p3tjIrF/D28r4QhsFwyIURMBIugjz4KoziFLwY
Duol2kfwMZyEz/WSmCfIaNWfybgH7oX7YAXcDw/Ag9AGK2EVPASr9aMZa2AtrIP18DBsgEdgIzwK
z+sn8Son8Son8Son8Son8Son8Son8Son8Spb8Cpb8CpbMj7Co3wMnPMZR+AT+BP8Gf4CR+FT6ILP
8DyZeI6B+tFMD+TAfKiCoHDjVToy6wk3wEK4E7AhHqYTD9OJhzmJh9mS2aq/lbmC9PvhAXgQ2mAl
MNbMh3ivoexaWAfr4WHYQN4jsFGPZj5OmSfhKdgEz8BzsJn852EL4R/CVngBXoSX4GXaeQX+g/Br
sJ2+/JjyOwj/nL69TvgX9PWXxHdT7k3ivyLcQd5bhN8m/Ft4B34H78Fe+D10wvvwB/gj7IMPYD8c
gINwCD6Ej+BjOAxH4BP4E/wZ/gJHgdtHZhd8BsfgOJyAv8Lf4Av4B/wTTsOXcAZ0/She9Che9Che
9Che9ChetBMv2okX7cSLduJFT+JFT+JFT+JFT+JFT+JFO/CiHXjRk3jRk+4B+np3BmTqW9xu/S13
FmTDINobDEMAv+JGZxb6stCVZdF3ZqWCC9L0G7PwS1mslazBxIfAaMAzZ02EImgmrwXa5D2Tu2FU
PUvU85CwiLe4+cnUT3lPFO+JGu5JR+XfJtb+IjYnaaLGMhbGwXix2TITrocgNMBdpC+GJbAMnoZN
8Ax5z/J+DnbBL2E3vEn6r3j/GvbAb6AD3hI17tHiZneJmMYd7LC7QdS77xLjsp6Fl7mzbhTTPI+K
es9jotzzDPFnQaa/AtvFbs+PxVrPDjHOsxN2E3+T+DuUfRc6KfO+/nvP5+SdJv4lnjuNUf7ZPVLM
dF8kZmZtFtdkbeXm9wK5W8U1nhfgR2IFt+QV3JJX5JSJcnXft2EpeY98R97MKTGNEtMoMU3l5nBz
6uLmdJybU5eyLicut6fj3J6Oc3s6zs2pi1tGFydnF6dmF6dmF6dmF6fmcU7N45yaXZyaxzkxu2h9
Jq3PpPWZnFxdnFzHObm6RKq81zMPQ5mHoVlb9Y6sFxgfb498/whe1DtyyvTfG3dW+tEhrGadPOrk
Sbu638YWL9FnmXOQ0RzCmjux5k6stRNrtapb9QcyJ0vmnJ2bbFriLfnNwejzuB2z0/g6OcRZ8an6
AnmJlBnyRq1liSa+jpZjgWZogXsoey/v+2AFp8T9vB+AB6ENVoL8O/EP8ea+JPDIYh3fWesZ08N8
5WxQ99ONAo8sniN/C/wQtsILwJ1J/Ae8Bj+mDN5HcHcS3J0E9yaxC34Ju+FXgNUFdyfxG+iAt+G3
8Dv4PXwA+4E7lTgAB+FDwJMIPInoom+fwTE4Difgr/A3+DuchM/hFH3/Av4B/4TTjOFLOAM6d2h2
ucYu1yx8R6bon3Hn7eDO28Gdt4M7bwf33A5Otw5Otw7uuR0ZrJoM+p5B3zO482XQ34xOeF8/kvEH
+CPsgw9gP/wXHNQ3cs/dyD13Y6Ybb3YBK86rf+a+EIbBcOIjIA++igfiO8bN94ub7xf3GPK5rbCC
N7q5qbgLSLsc+K5xT9aPuK+AQpgCU4EbiXs6ed+Ca+BavN51vGfCLeTfCnzfuPm+cXMTcZfxrqTt
AG++od2cfu4q3tXA/dodIh7mXQvcs9lFG92N9OluWApNpLHO3KwzN+vM3QqsLTfryb0KWE9u1pN7
DayFdcCOdW+AR2AjcA93cw93Pw7cxd3cxd0/gCfhKeBe7t4Ez9MXTkE3687NunNzV3e/SpyTz83J
5/5P2M74fgw74CfwU/gZfW6Hn+vb2PXb3G9wF96p7swb3buow8no3g1v0h4nIx5hG/fojW5ORDdz
7GaO3ew+vMRG9/v68axH9M+y6HMWfc6iz1n0NYu+Zj0Pr+rHPYNgBbC/POwvDzbwMH4P4/es1494
HgfG6WGcHup5GKOHMXo47T2MxcNYPHgoD3vGw57xsF88rDkPa87zG/I64C3g5PbsI+0IsO7xWhvx
Wts8nKA5V+pHcor0z3KuwotxI83hFppzE3G+d3P41s3hWzeHb90c1kIOayGHm2mOT3m8jTl+7uzc
SHMqibMuclgXOXewl4aq0+r/w0mlLRPL9Kn4swL8WQH+rEC0spfv0fPxZ9vxZ5vwY/PwY/PwYwX4
sSh+rAA/Nk+socxafRW+LIovm4cvm4cvm4cvm4cvKxGP8n6Mth/n/QR8H34AT8JT8DRsIv8ZeBae
o93NtPU8bCH8Q9gKL8A20n7E+0XeL8HL8Aq8Cv9B+mvwn+jcDj+mXzvgZ1i1nTH8nPfr8AbshF/A
LtJ/if7dvN8k/mvCv4V34F34HeyF39NuJ+/34Q/wR9gHH5C+H/4LDsBB0g7R1oe8P0L3x5wrh+EI
4U/gT9j0z/AX7HUUPoUu+v4ZHIPjcAL+Cn+Dv8NJ+BxO0eYX8A/4Jxh+dl6cny3hhNqEry3B187j
JJunPa5v056A78MP4El4Cp6GTfAMPAvPwWZ4HuTXxyHqMobur5DDenrsS0Q7xRfKF/pi7TTvL/XF
SUn6jKRksOr/h7Z7j4+rrvM/fjKFcotc2skcbrZGCrbEFmgpRKAWitIA5ZISCzQYKjQCA1Ik4RIk
LRDcVqQgQanieImXqJvf7s6uy8qOF7yku7KrzeKoyagjNqFMA9kRAWkR6Pk9Z3qKWVb35/7x++P1
+J5zvt9zZub7fX/en8/5huqyaf8ULZn2jSg97VH8M3L4Jr6Fb+M7eAzfxffw/ahx2g+izmmD2Ix/
wb/ih3gc/xbMkAtyckHjtB8bvwVD+A9Yp2nWSY5olCMap/3MsbWaNowR5wX3/wK/xK9QxK/xJKzT
pHzRK1/kps/gSUdFjclZUVquaJQnOuWItBzRKD/0yg9p+WGV/NAoN6STp+K0YEZykfadxi7G6TgD
S/Au19+Ns7A0mpdscu857j0X50X9ckZj8gLXLtTfjOW4yH0teI/nrsDFrl2CSx2vRKu+y3C5e9/n
3iuiJfJLY3K1Me14P65CJd+ktdf63tfp/wCuxxrf4wb33ej4JtxszC3VncXVyXWe1ePZd7vOB+Sb
RvmmUb5pTH7E9XvwUdyLja7dZ74+5lkPRTk5J538pO8nvuWWtNySllvScktabknLLenkV/BVfA1/
DfEt13TKNWm5Jp38O/dntX/vO/4Dvh5tSP4jHnH8T37HN/Ao/hk5930T38K38R3QlRyUloPSclBa
DkrLQWk5KC0HrZKDVslBq+SfXvknXc0/P/abt/gdQ3jC8U/0eZOQh9LyUFoOapSDGuWgRjmoUQ5q
lIMa5aC0/NMo/zTKP43yT6P80yj/NMo/nfJPp/yTln/S8k+j/NMo/zTKP52H/k00Tw5aJQetkoMa
5aBGOahRDmqUgxrloEY5qFcO6pWDeuWg3kOfkHN+5XoJfEEeSstDaXlolTzUKQc1HrYsmicP9cpD
vXJQ42ErVbGt2rYoLf+k5Z9O+Sct/6Tln7T8s+qwq6IlclCjHNQoBzUedn0wQx6q/LvcT0bF6o7p
w9Xav/gndk2L3KfIfYrcpyiiiiKqKKKKIqVIgUXKKlqVolUpvr6L9gOZfrD6XlCMd9OKZrvoFxXj
nayib/e74ECfXHnjGORHI3xohA+NqB3LaseX1I5lteNLPGmEJ414atlTy+4sq/IPil6sWYZ01Ftz
h1FPV/9SkJnSzCkrfx0ouVqqVvej1R1w74yO+/e8TXiDOEi9ugxiqPIOsOevJfHdlfsqR0/XVHZ7
aqp/76g8YXDPO0z1bMvrZ5URuz95tHrvgpqp0eaamdHzNW/R1uOtOAqzcDSOwdswG3NwLF9vwDr3
3KGOvlO71dOewja8hB3R6LSnos3TtuFplLAd43gGz2IC/4kyfhttTr4cPe/te7O3783evjd7++73
1r3ZW/fmugZ9b9cuwCl4Fz7i2j34KD7mfFP0fPC4X5Or2SfaXrMf9scBeBMOxME4BNMwHXUIcZhv
fHj0Qs0RVvBIxxy4ZoY3gpnV/bKcWcmZlZxZyZmVnFnJmZWcWcmZlZxZyZmVtWZlbc2JnncKTsUZ
OBPn4Fych/NxAS7EclyEFbgCq1FZl2txXXVn/4Wam3AzbnF+K7pwGz7k+92ObqzFOt+VAqzGRM1d
nnM3tlLsU9iGl7AjGrQqOauSsyo5q5KzKjmrkrMqOauSsyo5q5KzKjmrkpv2XLR92svR9un7RC9M
3w/740AcFG2ZfjAOqe7Oj04/3JgjcGS0PfkrbBcJz2onoheSL4qt32OH453RFis9kXxNXxRtr6vB
lChXNzV6oc5n1O0Ln1PncyghRwk5SlhblzTOWtX5HKrIUUWubobjo407BnMcN0QTVJKrm+t4vjf3
BY5P8oZ9itZ61C127V2O3+34LCzF2bA+ddanbhmsUZ21qWuGtal7D6xP3SW4FCvxXrThcqzC+2D9
6q6ENaxrx/txFa7GNbgea3ADPogb0QHrWWc96z6E29Htt6zFOtyBO3FXNFLXg7v1fxh/5Tesxwa/
x5u+KJgQBRN193reRv334X59HzPm4659Ag9hkzEPR9uDvRMPBi2JL0YdiUejQmIQw0EiSCTODxoS
y4OGmi8Fe0W/CFKcJFQnHqbePjz6UXBEdH9wpJr4zdGWYIb+mXgL6vFWHIVZOBrH4G0QHYHoCK70
rNVox/txFa727GuQxk2efzNuwa3o8jm34UO4HVQeUHmwDg9T8tTq38YGJ0VsRsQOxhH7l+5w50Rs
rvqX4GtxHf57lA2KskFRNijKBidHWYIvJWaiPsokeGRiXjQ3cUL04cSJjs8PFpvJxYnVjq/CNcZf
r70ZXcbfrr3fvPe550vR/YmvO/+24xHtzmjzlP3xJlnCc6dtiH4x7SO4Bx/FvdiI+3A/PoYH0IsH
8XV17z/iEfxvd8cPwsE4pLpTPk9kD06/Jeqf3uP4bqyPlkynuuk+a/rD+DQy6tW/1g4gp++b2u8Z
933tZvc8rt3ifEgbRYPJADVIYAr2UlPtjanYB3w/eSAOin6UPBiHRPcnp2G6mijJPeqQAh3KtYNy
7WDVbV7U/h478fJ/28nNvb6Du9slBjnE7p3ck+Ld3MXxjm4XboO1F5GDfyL6MqIvI/oG/0v0bXS+
O/IGK7vB1WhTSdS9LI/9Aa+4plKpey1qr9sVLa2LojWpICqmaqJcKhFtTsl9qb2wt2tTo/7UPlEm
tW80mNrP+f5Re+qAaGmq1j1vMuZA1w4y5mBYq9Q059ONSRpTZ0wq2pgK9R2Kw6Ke1OHRstQR0aLU
kdGm1JujVakZ+mfqewvqo3TqrcYcZcwsY46ODk8dY9zbjJtj3LG+RwPebtxc4+ZFS1LHRQtSxxs3
X/8CzzgRC/WfpP9kz2n0nHfoP0X/qfpOg3eT1Dv1L9Z/uv4z9C/xOWf6nLP8hqXGNOHsaCB1jjHn
GrPM9fOMOd99Fzi/0PVm7fJdP01d5HpLNCt1cfRI6hL3XYqVPq/V9cuMe69xbb7n5fpXuf8K7ZV+
x2q0G/d+464y7mpjrsG1+q/zjA/gev1r9N+g/4Oec6N+9UpKvZJSr6TUK6nn8Ds8jxfwIn6Pl7AD
4jj1Mv6AV/AqXsMuRNHmMEANrH1o7UNrH+4N9Vi4D/bFfuAFYSduiorhzVF/eEuUCW+NBsMu57dF
7eGHoqXh7dGasNuYta6tM+YO3GnMXc57jLnbmA8bsz7aGG5w/0dwT5QOPxr1hPdGS8KN0YLwvujw
8GP6H3BvLx7U/3H9n4iWhQ9Fi8JN+j8VPRI+7N5PI2PsZ6JN4Wf1f879n8cX9H/RvV/Cl/X36/+K
/q+6//FobjiEn0T3hzuwM7r/0CCae2gq2nzoqTgNF2NllDl0He7AhmizOnqw5gAZKSsb9cf/Bcio
bJSWjTbIRiOyUVY2yspGWdkoKxtlZaOsbJSVjbKyUVY2yspGvbJRb/Vvwld71jVI4ybPuxncX/YZ
lX02yD4bZJ8Nss8G2WdE9hmRfUYqf0/l/FnOn+X8w5w/y/n7OX+a82e5epar93P1NEfv595Z7p3l
3lnuneXeWe6d5d5Z7p3l3lnuneXeWe6d5d4buPcG7r2BA/fHf5cc4cD9HLifA2/gwCMcOMuBsxw4
y4F7OXCWA2c58AgHznLgDRw4y4H7OXCWA2+YXnmz3Iuz7g0Ow237J/2XB6PcdpTbprltmttu4LYj
3HaE245w2xFuludmJW5Wit3sMW7Wy816uFlr7GZ93CzLzbLcLMvN8tysyM2K3CzHzR7jZj3crJOb
tXKzLDfLc7MSNyvFbvYYN+vlZj3crJWbbeFmJW5W4mYbuVkvN+vhZiPcrJObbeFmJW5W4mYD3Gwj
N+vlZj3cbA43G+FmndxskJsVuVmRm/Vxs43crIebdXKzOdxsCzcrcbMSNxvgZhu5WS836+Fmc7jZ
Fm5W4mYlbjbAzTZys15u1sPN5nCzEW7Wyc1GuFmJm5W42SPcrJeb9XCzIjfr42YbuVkPN+vlZj2p
5ZzwIve0cMKLfcYl7rsUK31Gq/GXGfde49o40eXGrXL/FX7LlZ7nHZWb9XGzPm7Ww806Yzfbws1K
3KzEzQa4WR836+VmPdxsEUfJcpQ8RylylCJHyXGUxzhKD0fp5CitHCXLUfIcpcRRSrGjPMZRejlK
D0dp5SiDHKXIUYocpY+jbOQoPRylk6PM4ShbOEqJo5Q4ygBH2chRejlKD0eZw1EGOUqRoxQ5Sh9H
6eMoPRylM3aULRylxFFKHGWAo/RxlF6O0sNR+jlKP0dJc5R0WNmJCMRzTWIiWKyeXa7KXRE0VM8b
gocT85zfH01NPBjVqn4LiUeNGY7WJ0qOd7r+atQ2pTZaP+WYYHHy1uChup3BjLqXg5Pr/oBXg7l1
r2l3aSNrEARHpWqCw1J7BzNSU4OTU/tgv2Buan/tAdpaYw7Ud5DzgzHNtenapFZMpVLuD50fisNc
O1x7hPZIvNlzZ+if6dpb8FbXjtLO0h7t3mO0bzNmjjHHut6Aua7N0x6nPd6Y+foWOD8RJ7l2srZR
+w59p+g71flpeKdri7Wna8/Qt0R7pmefZcxS15twtmvnaM/VLsN5+s/XXoALXW/WLnfvRdoWfRe7
9xLXL0Wra5dp36ttM+Zy7SpjrjDmStdX4/2uXaW9WnuNMdfqu875B7DGtRu0H9TeGI2ENwUzwpuD
k8Nb0BXMDW/Tfkh7u761+tY5vwN3udajvVv7YX3rg6PCDc4/go+6dq92o/Y+fR/T94DzXnzctU9o
H9Ju0vcpfQ87/zQ+49pntZ/Tfl7fF/R90fmX0O/aV7RfDeYGn0zcv+s5KltIYQ2JH8gIw45LlLZb
ZfUUVv8nFDZ/ksLyf4HC8m9Q2PxJCstT2Oz/h8Jm/xmF5f8CheUpbPafUViewmb/GYXlJyls9v9S
YflJCpv9ZxSW/wsUlqew2X9GYfn/QWH5Nyhs/iSF5f8HheUpbPafUVj+f1BYnsJm/0mF1VDSkmBD
op6jzaOvBznZo0Ft4tUgpK2WaqZ+RXZ+VfvHDJ2WoUeq7xtTZYV9sK/zP2bjnmomPkT2nab9YwZO
y8D5+D1icuZtl3nzMm42fn/Yk3Fnxhm3XcZ9XMYtybglGbdfxu2clHEPlnHzMm02fm/Yk2lnyrR5
GTYbvy/sybAz4wzbLsPmZdaeSZl1RGZtj98TJmfWmXFmbZdZ8zJqVkbtmZRRZ8YZdY2M+riMWpJR
SzJqv4zaMymjzpRR8zJpVibtmZRJZ8qgJRm0JIOOTMqePdXMeadseZf2jxkzLWM+LmOWZMySjNkv
Y3ZOypgHy5h5mTIb1957MuVMmfJxmbIkU5Zkyn6ZsmdSppwpU+ZlyKwM2bMnQwZfrtao86Jl6tNc
4uZoq/z3S9r52ZRjoq1UMqCe61HPpaklQy191NJILXOopZFaHqGWHjXcIxTTSTFpismo4fqoppFq
5lBNI9UMqN961G9p6slQTx/1LKWeOdTTSD2t6rdm9VszFS1JHb5rR+oIHOn6m42ZoZ2p7y2oj+ZR
05LUUfpn4ehdBWpqpaY51LSMmpZS01JqmkdNS1LzjDlu1/bU8cbNN26BZ5yIhfpP0n+y/ka8Q/8p
+k/VdxoW6X+n/sX6TscZ+pfoP9PnnBV1qd+a1W/NVNZKZVNT5/qMZa6f557zcYHzC9HsvuW77qOy
JakWxxerzS4xD5e6byVVtVLeZdTzXmpv85zL9a/Sd4X2Su1qn9Fu3PuNu8q4q6MaaptKbRvVb2n1
WyvVraG6dqqbSXUHU91UtdsjlNdJeWnKy6jd+qivkfrmUF8j9Q2o23rUbWkqzFBhHxU2UuEcKmyk
wmVUuJQKl1LhPCpcEt67a0e4cdf28L5dBSpsVbc1q9uaqXEeNS4JP6H/IWzS/yl13MPGfFp/xpvl
Z7xlfpYKPxfVUONUatyobkur21qpcg1VtlPlTKo8OGilypcocogaK3sklbeJPPWNUl6R8roor0R5
2ao/7Vf1qFFqy1f3Pw6sviXkqWyUwooU1kVVRb5UpKYsBeUpqMiLiryoi3Ky1DJCLXneM8p78rxn
DYXkKaTIc4o8p4si8hRR5DVFXtNFCVmrX+Qvlao9a9WLvKXIV4p8pYunZK1w3goXrW7R6nZZ2azV
HLGaeas5ajXzVnONFcxbwaLVK1q9rqpXdFX9YtSK5avv72urFXbeSo1apaJV6rIyI1Ymzx9G+UOe
P6yxGnmrUeQLRb7QZfZHzH7e7I+a/bzZX2PG82a8aLaLwRfMdmV3csiMrzPjm834I+J+QNwPTIr7
tNlvjeP+MbPfFcf9gLjvmxT3rVZiWRz3j4j7AXE/MCnu01alNY77yi7UgLgfsELtskezVVoS70It
i3ehBsT9gFVbY9XaZZFmK7fEyk2Nd6GWxbtQfeK+z0quspLtVnJpvAs1Nd6FGhD3A1Z1jVVtl02a
rewSKzs13oUaEPcDVnmNVW6XVZqt9BIrPTXehVom7gfE/YC4H7DyXeK+2eovEfcDcXZpp4Alsksz
FSwR9wVxv5ES5oj7AXE/IO4HqKKHKrrEfStlLIuzzAB1tIv7PnHfJ+77KKWHUroopZlSllDKweJ+
QNwPiPsBqumhmi5x30o5y6rZZnfcD4j7vklx30pFy+K4f0TcD4j7gUlxn6ao1jjuKztAfeK+j7pW
UVc7dS2Nd4CmxjtAA+J+gNLWUFq7LNRMbUuobaq47xP3feK+j/J6KK+L8popbwnlHSzuB8T9gLgf
oMIeKuwS962UuCz4Wk062lLZP6fIJ+L98t174zdTZ1d192S4uv99TDRU9YWXo2y8d7qFSktUuoZK
myd5xCCVlibtl26h0lK8X9pMpV1VvzhIXO7eK91CpSUqXUOlzVXvSFn9P+6VbnzDXmmaSjdN2ivt
jHcX9uyVzopVmn7DXml7vLuwiErnUeksKt00aa+0M95d2LNXOotKN03aK+2Mdxf27JXOilWafsNe
6SOT9kq3TNpdmLxX+ut4r3TmG/ZKN8W7CyvivdLK7sJj8e7C5L3STfHuQmWvdBGVLnrDXummeHdh
RbxXuohKS5P2KrdQaSneq2ym0q6q161Tq+zep9xCpSUqXUOlzVXf+6/7lO3xrsIiKp1HpbOodNOk
fcrOeFdhzz7lrDfsU26KdxUq+5SLqHTRG/YpN8W7Cisq+5RVv6zUTLnYL/vjXfwJSpyI970ej6vq
tZTYHu97DcR7XaOUOBrv3D8+qbpuj3ftJyhxIt7nejyustdSYnu8zzVBiROUuCmutte+YZ9rghIn
4n2uTXHVvZYSF7xhn2uUEkf/xD7Xgnifa4ISJ+J9rk1x9b2WEhfE+1wTlDgR73NtiqvwtZS4YNI+
V5ESJyhxghIfi6vxtfE+1wAlbqLEtXE1vlbWrIur8TQljlDiBCVOxPtcA3FVvnbSPtcmStxCiaOU
OEqJA2/Y56oocYQSJyhxIt7nGoir87WxEit7XKOUOBrvmj8+qUpvj3fMJyhxIt7fejyu1tdSYnu8
vzVKiaN/Yn9rQby/NUGJE/H+1qa4al9LiQsocQsljlLiKCUOvGF/q6LEEUqcoMSJeH9rIK7e1wb7
1hwUzK/8m03vdqcmng1OSEwEp06pD06o+9vgoUP/PlgdHD1pxAnVnleC1XVRMD+1b7A6Vas9RFun
rdcerX279njtQu07tIu0Z2iXY6XjNm279hrt9dobveXeGqwOb9feqf2w9h7tfdoHtZu0Ge3ntV/W
fi2YH7wrcWTUlpiJY3AiVuMqXI/bcT8eDcLED6NC4gn8tPI3aLngae32qJwYj8qpRNSWmoK98CZM
4D9Rxm/xHH6H5/ECXsTv8RJ2YCdexh/wCl7Fa9iFKGoLA9TA54Q+J/Q54d6Yin2wL/bD/uhEd9R2
6CFR4dBpmB2VDz0eJziej0V4J86MCodvg99xeAnb8UxUCOpqno6GK//WueZZWW5uUM9f1ieO92tP
CBoS8x2f7te/O9qZONusnCsbLo/6Eyu0F5uNm4zhpolb9XU5vm33v5kOTqvZGhVqnoLPrHkJOzzx
yGibud/GxZ43/9t80vOJ4zz5hGjcWmxLnOp4hXGrnV+F69ElB98ejdf9Jtpp3reZ923mfZt535Z6
j2srMBGNm/9x8z9u/sfN/7j5Hzf/4+Z/3PyPm/9x8z9u/sfN/7j5Hzf/4+Z/3PyPm/9x8z9u/sfN
/7j5Hzf/4+Z/3PyPm/9x8z9u/sfN/7j5Hzf/4+Z/m/nfVnOAX7zQL17oFy+seTZYXPPboKXmBbzk
fAd2RutrXnb+qva1oCURBle/rsb6oDZxlPmsqPJY7TxzeRyON88LnFeUeqrzRdbjDNeWRA8kmszU
OdZsmTU7z/XzjbtAe2HUkWjWXmR8i/YSXIqV7nmvz2zD5c5X6X8frsCVzldHtWa9NnGN73atHHO9
4xsr7+bB4sQtrt3qO3zIuNtdv9P1u1zrwd3R+imnBlfX/TIq1xXxm6Chblu0vm48ytU9gwmUg5Y6
81H3XNDy36LnPUFDagXeJ7LS6IjWpzpxE27GLbgVXbgNvkPqdnRjLdbhDtyJu9AD3yn1YfwV1mMD
PoJ78FHcGz2Q2oj7cD8+hgdUYr3aB/F/gqtTfxOclfpb7d8hG8xO/X1wfeofHH89uDD1j3jE8Tfw
KC/6Z22OL33Ts7+Fb+M7eAzfxffwffwAg9js9/4L/hU/xOP4N/w7foQfYwuG8B94Aj9BHj/Fzzzj
5xjGCAr4BX6JX6GIX+NJ/AZbMYoxPAXrk3oaJWzHOJ7Bs5iIakVTrWiqFU21oqlWNNWKplrRVCua
akVTrWiqFU21oqlWNNWKplrRVCuaakVTrWiqFU21oqlWNNWKplrRVCuaakVTrWiqFU21oqlWNNWK
ptrwJF7dGMwO34FFwWnh6VEuPANLcCbehXfjLCzFOUFLeC6W4TycjwtwIZqxHBehBe/BClwcrQ/F
RCgmwpVoxWV4L9ogNsJVeB+ugNgIV6Md78dVuBrXII1rcR0+gOuxBjfgg7gR9LzHpcNPRuWwLyoH
U0R4Ld/byT1LQcgXunlCNw94Uvw/KU5bxGmL3py4elJcPUmTLTTZQpMtNNlCky002UKTLTTZQpMt
NNlCky002UKTLTTZEuxbrRrnVt+0x3zmzxJnc45rOPZNHOPmoDZ4pmYrXxrFGJ7CNsT/GxQ1Lzne
gZ3yxB+iTM0r0VYeNlyzy3EUbU0k+NGU6KbEXtq9tVO1+2jrfcJRcsOx2J1XXuJn/fJKPR8bk1dy
vKySW8YSS32Tip+dre8c7XlRno8N8bHN8k0mcZGxLdWc08/PCvxsLHGZe/bM0+XGrzLmfbgCVxrT
HsxJXI00rnXvddoPYA1uwI2udWg7cZPvWs1jlf8KqprH1ie6XV+HO3Cnt77WYI616LcW/fwtz9+G
+NsQfxuq+52+F7EjmMO/xvjXGP8a419j/GuMf43xrzH+Nca/xvjXGP8a419j/GuMf43xrzH+Nca/
xvjXGP8a419j/GuMf43xrzH+Nca/xlIDfPIv1cM/GfsGTfCpPJ/K86k8n8rzqTyfyvOpPJ/KpzZH
udS/4F/xQzyOf8O/40f4MbZgCP+BJ/AT5PFT/Cwq8KcCfyrwpwJ/KvCnAn8q8KcCfyrwpwJ/KvCn
An8q8KcCfyrwpwJ/KvCnAn8q8KcCfyrwpwJ/KoQHBHPCWrwJB+IgHIxDMA3TkUQdUghxKA7D4TgC
R+LNmIGZeAvq8VYchVk4GsfgbZiNOTgWDXg75mIejsPxOAHzsQAnYiFOwsloxDtwCk7FaViEd2Ix
To+G+NwQnxvic0N8bojPDfG5IT43FDYZc3YwJ1igytiqytiqytiqstiqstiqiiioIgqqB1Vb9KJq
oVJDlWTzkixekrFLsm5B1i3IugVZt8DlS1y+xOVLXL7E5UtcvsTlS1y+xOVLXL7E5UtcvsTlS1y+
xOVLXL7E5UtcvsTlS1y+xOVLXL7E5UtcvsTlS1y+xOVLXL7E5UtcvsTlS9ywwA0LQSI4INifG40F
+1T+Nanv/hxH6HclK/r7RX8l6rPB1MQc8VmpSc8W88v1VqrEDwb1NReZjyNqRqOhmjE85Xgbno7m
Vv73alRgDSqwBvN0hHk6goMtq3m56mJDHGxZzWtVFxviYHM5WI6DzeVgOQ42l4PlVGjdr1doR3Gc
3dXZGO+uj6uzSpUcTqrOOnz/rOoskzjTN32XvqUcZU+ldl60MnG+axfovxDNri13fhFanF+CSz1j
pbbVtcvc+0eHW6liC1VsoYot5HAZa9yUaPf9r9JerU3jWvN2nfYDuN71NdobcKPrHdpO3Oy73gJV
Fberp4+mRLfr63AH7jT2Lv09QYPKrruulcP9MhrjfGNxdbeS+/Vzv37u16+6a1DdNajuGup+Z+yL
2BEN/dlKryPq4JAdHLKDQ3ZwyA4O2cEhOzhkB4fs4JAdHLKDQ3ZwyA4O2cEhOzhkB4fs4JAdHLKD
Q3ZwyA4O2cEhOzhkB4fsUOFlVHgZFV5GhZdR4WVUeIMqvIwKL5P6eBCmPoGHsAmfxKfwMD6NDD6D
z+Jz+Dz68AV8EV/Cl9GPr+Cr+Br+GgPR5tid5+9252gkriBXx+58Fnc+K3bnzbE7r47duVJFruTO
K7nzSu68kjuv5M4Z7rySO69URWZUkRlVZKiKDFWRoSoyVEWGqshQFRmqIkNVZKiKDFWRoSoyVEWG
qshQFRmqIkMuneHSGS6d4dIZLp3h0hkuneHSGS6d4dIZLp3h0hkuneHSGS6d4dIZLp3h0hkuneHS
GS6d4dIZLp3hL038pYm/NPGXJv7SxF+a+EsTf2niL038pYm/NPGXJv7SxF+a+EsTf2niL038pYm/
NPGXJv7SxF+a+EsTf2niL038pYm/NPGXJv7SxF+a+EtTeADHrMWbcCAOwsE4BNMwHUnUIYUQh+Iw
HI4jcCTejBmYibegHm/FUZiFo3EM3obZmINj0YC3Yy7m4Th4kwtPwHwswIlYiErFe7K2UfsOnOL4
VJyGRc7fqV2M06N+GaJfhuiXIfpliH4Zol+G6Jch+sMmY87GOUGDirhBRdygIm5QETeoiBtUxA0q
4gYVcYOKuEFF3KAiblARN+ypToM5NRPRQu5W8doHqk52Judq0p7Dbc6vutY5XOscHryeY53Dh9er
ybKVd0PR2yti0yI2LWLTorJXJKZFYFb0ZUXfFhFxmmgYFQ0XioZ7U//geM/71Dcc746CGdUo+G6U
lU/nx+8Ep5md08zIhdW9hVpeX8vra3l7LW+v5dNDfHpIrVvJg0Pq3X4VZyFxnF9ygmPznTjV8dmO
V/P2q6pvuDnel6v7jTc+VSyvGuJVQ7xqKPUe11bA2ysd5+g4R8c5Os7RcY6Oc3Sco+McHefoOEfH
OTrO0XGOjnN0nKPjHB3n6DhHxzk6ztFxjo5zdJyj4xwd5+g4R8c5Os7RcY6Oc9ZlKKz8r+b8PK7P
G9TnDZPq8+r/3tmk+nxIZlunPq9ktyGZbZ36vJLdcrLbOtktJ7utk91ystu6xJGcfyaOip5IHKM9
Vlut06uZLZs40XEle53n7aGy53OR2bwYu7NSm6zUJisNq7sL6u6CulvVESxUdycTV2mv1qZxrTHX
aT+A611fo70BN7reoe3E6/tIsubtxnS7tg534M5oWO2dlIGekIGekH2GZZ9h2WdY9hlWeyfV3km1
dzKVCOpTU7AX3oTdTtxGd22cuE2d3EZ7bbTXxonbaK+N9to4cVvsxG002EaDbTTYxomHOfEwJx7m
xMOceJguhznxMCceVicX1MkFdXJBnVxQJxfUyQV1ckGdXFAnF9TJBXVyQZ1cUCcX1MkFdXJBnawK
Cxam/hNl/BbP4Xd4Hi/gRfweL2EHduJl/AGv4FW8hl2IgoVhgBokMAV7YW9MxT7YF/thfxwQJNXR
SXV0Uh2dVEcn1dFJdXRSHZ1URyfV0Ul1dFIdnVRHJ9XRSXV0Uh2dVEcn1dFJdXRSHZ1URyfV0Ul1
dFIdnVRHJ9XRSXV0Uh2dVEcn1dFJdXRSHZ1URyfV0Ul1dFIdnVRHJ9XRSXV0Utwn1dFJdXRSHZ3k
AUl1dJIPJPlAUh2dVEcn1dFJnpBURyfV0UkuOcwlh7nkMJcc5pLDXHKYSw5zyWF1dFIdnQw7g/qw
O6gPbuMbHXyjg2d08IgONVymWoOeF3Vzu/Xc7gFO16E261abZSi+W+3VzUMW8pCFPGQhD1lIld08
pIOHdPCQDh7Soc7JqHMy6pyMOiejzsmoczKcMqPOyahzMuqcDNfMcM0M18yoczLqnIw6J6POyahz
MuqcjDonw1Ez6pyMOiejzslw1ww1z6fmW1+vKR5VZ+Q46Dd9n2/h2/gOHsN38T18Hz/DzzGMERTw
C/wSv0IRv8aT+A22YhRjeAqV3/s0StiOcTyDZyGL8Eyqxm/xHH6H5/ECXsTv8RJ2YCdexh/wCl7F
a9iFKKJq1CCBKdgLe2Mq9sG+2A/74yRZ4o/ZYj4P7eChHcEhqX3lmENQj7djIeST1Eq04/rgwvBW
3Il78CAy+HwwI/yy9mvBjMp/ucvlVnhjmUol5eq/S7vAleW85gfiedBbzV6J070jnF99UylXdsqD
a6mq7OpQ9Z5zq55apq4x6nIvP77IeQsq/nqJ9tLq3kY3j+2muDKPLfPYMo8tU1+Z2ir7pGXqKlNX
mbrK1FWmrjJ1lamrTF1l6ipTV5m6ytRVpq4ydZWpq0xdZeoqU1eZusrUVaauMnWVqatMXZU9hm7e
2c07u3lnN7V1U1s37+ymuG6K6+ad3Xyzm/K6+WY39XVTX5n6ytRXpr4y9ZWpr0x9Zeor880y3yzz
zTLfLPPNMt8s880y3yzzzTLfLPPNMt8s880y3yzzzTLfLFNvmXrL1Fum3jL1lqm3TL1l6i1Tb5l6
y9Rbpt4y9Zapt0y9Zeotpyrz9zRK2I7KX3WewbNROahJnB0sDJbJud1ybrec2y3ndsu53TVP4yXs
sC6LgtrEGTg7WJxQaSVUWInmyp47LsGl+i6v7K1X3pgqbz1BbaoTN+Fm3IJb0YXb8CHcjm6sxTrc
gTtxF3pwNz6Mv8J6bMBHcA8+im/6nG/h2/gOHsN38T18v7JvjJ9jGCMo4Bf4JX6FIn6NJ+FNL7UV
6o6UuiP1FCq/42mUsB3jeAbPBg3B3pV5o+7c62/oF4uTpeYpVHXlEsvMx3lqigu0F7rWXHnrdb57
rkJzVR/PVb25Cs1VaK5CcxWaq9BcheYqNFehuQrNVWiuQnMVmqvQXIXmKjRXobkKzVVorkJzFZqr
0FyF5io0V6G5Cs1VvbmqN1f15qreXNWbq3pzVW+uxLP5HMT/zzlLcIWKn2wOpiROp6PK7sDyyv9v
TNVjKtcaEue6tkKu2tvZQg6y05WG6r7BinhkZT/ZfE9ZiJM40Hv4zU4jC4n/y925QEdVnX1/n30y
iCGAZs7hnARFQOVitGpsEHUUL7xjxduoeOkIvF7GiqiRimisjpfYNr4Wa7GaegltvNEKCFGx1aBY
hUiQy3ARMYhFHCEgwyEEjCMFzvfbeyZhgLTvevt97+pa32L92XvOOXPOs5/L/3mePUnmXPhC7aZc
gW6v4t0ZbknLqOIUjl0PblB613yShk/S8EkaPknDJ2n4JA2fpOGTNHyShk/S8EkaPknDJ2n4JA2f
pOGTNHyShk/S8EkaPknDJ2n4JA2fpOGTNHySpiv36Mo9egKPrtyjL/DoCzy6co+uHF5A7x+BBaAR
LAQfg0VgMVgCloIEWAaWgxVgJfgE/C/zgl+n9d2kOWKk6EoNnjCwp7zFb8vWsJOz+8f16m8p0FHx
BHoVj17Fo1fx6FU8ageP2sGjdvDkvWQBxdIpsBV4YBtoAdtBK9gBdoJvAfcgZ3rkTI+c6ZEzPXKm
R870yJkeOdMjZ3rkTI+c6ZEzPXKmR870yJkeOdMjZ3rkTI+c6ZEzPXGz/uyyY/8/+xnmNnhuh+K7
9s8vOac/vwSZzy9VFRRnJXF5C2suZ9y3s9Qk7wP3cyy7kyR/jneq3aSc3SJWHWfVcVYdZ9VxVh1n
1XFWHWfVcVYdZ9VxVh1n1XFWHWfVcVYdZ9VxVh1n1XFWHWfVcVYdZ9VxVh1n1XFWHWfVcVYdZ9Vx
Vh1n1XFWHf+XOmXys3MN+DGIgmvBKDAajAH/CeiHHPohh37IuRHEwE3gJ+BmMBbcAsaBW8Ft4HZQ
Du4A48FPwZ1ggtol1VrFq/Rn9eu1DZT+pb+enm49/dx6eqwk/VRS/xz1w36S/ihJf5SkP0pSEyep
iZPUxElq4iQ1cZKaOElNnKQmTlKv3OI3y4lY627Ge/1Fymtzc54/1fA4tk2cbLQIy2hlvoM5PVd7
LqT3nErPORWZJiPTZGSajH9Y2i9upa+8E0yEf5Rf3IvsP+P4w/5ys0ycbA4B1PJmRAxG7uXIvRy5
lyP3cuRejtzLkXs5ci9H7uXIvRy5l4tBeG0Kb03hrSm8NIWXpg7a9/437nPDEuR68UPdFauO+FYV
JYw/ZbxTRUnGrrrjfZiIgElsMoOdUpHxb+wMyTrOOeBccB4YDv4DhMH5+GEUzZ+wbz+C+Qaw0W/I
+ZmHE7DGCfjF+uzPPKzP+mxCf06oPiPM8EcMa8XwEfVXCGL4SWo/DtHa4bj6qwa5O9Kb/RR+ksJP
UgfwSQxrx7B2DGvHsHYMa8ewdgxrx7B2DGvHsHYMa8ewdgxrx7B2DGvHsHYMa8ewdgxrx7B2DGvH
sHYMa8ewdgxrx7B2DGvHsHYMa8ewdgx/TeGvKfw1hb+m8NcU/prCX1P4a+pf4RthGil6zru1NurE
Wei9Bn3XoO8adFyDjms6son6RFdlFPWp7j1Kd2ovBVQyf8Rvsj2wDbToT3/+bdnGGQGvXQguAheD
SwA9lBMB9EMOHZZzBRgJrgQq354NI43N2QEbCzON1TtgW5S3Mf9OjMW76vCuOryrjpgrIeYU+ywi
5og3xonqE3WtS7XLpBhoEZ60CE9ahCct6qXibivAo4i5kl7Ko7aDVrAD7ATfgjbwHUiD78Eu8Hew
G+wBe4GPBQUwgAQmyAMB0AUcArqCQ0E+ONtfhPcswnsW4T2L8J5FeM8ivGcR3rNI3IMGSnI0UIIG
Sjp+dsvzLzK2+ecarYw7GJEQjZQQf8nsp13J7Cddq7OfdK3OftK1OvNJl3+d/C0aeZps8xyY4q+T
teAFv0q+RL861R8jX0Wrr4M3OP4meeZtv0XO4dr3uGaBGCEbeb0QH1wKljP/BHzqz5AbGTeBzWAb
51r9GWYXv9U8FOT7U83ejAMYy/xzqV7PNc/wr1M/Q+bMF9JZ6Fc5S/x1ToJxJcc+8cc4q8Aazq0F
65g3M6a4ZivwwA6O7eGY769zhV/lSiHdrsJxD/db3EJwJPOjwCDmJYwnMZ4MSsEP/RluGRgCzuT1
WeAcrjmPMcx4pd/qXu1Pde9inAjuBlXgUX9q8af+uuLV4DPQBD4HG/yWYtZf3AzQQfE3YKffWvwt
aAPfge/9VnG8nEIVXgteQkNTGd8AVLPyC1Fg4i8mfmIWgJ6gN/5CJexQ8TqrwDqQAluBB3YAX/Rz
u4sCN+h7rgOGA1jFHQVGA2LDvQtQtbrEhHsfqBIlxZ+KfsWrwWegCXwO8Pti/L4YryrGq4q/153L
E/4GmfY3i6D+mUn1O6Uv4U0z8bK3qUTU75Yu4NhK5qupBqi25Vf6N5prJDErt/kjZAt32e1XmQV+
nelQHQ7Q932bs+q3pLtw31a8sp/+bWi6JbMvVcIA8up/dhoLWZ+XT6DB34KnwXNgCvxXC9TvVb+s
tevImeCN7O9Zz2G+gJ6UXgPf7YfPNsnPOLaGekZLyj1bObabY3uFg+96+K6H1E1YwzEdZRFel4l8
apl8/NbBZ5ucFYyfgFVgDVgL1oFmkOL8VgAnYy3H+Q6kwR7g+034rIPP9nN7Mbr4WxE4ktdHgf7M
Sxh/yHV0fPhqk3sqx87g2hA4h3NhcJH2Vw+LO1jccW8AN4M7wF0cJ0/gvx6Wd/BhD/9twn+b8N8m
/LcJ/23CVz181cNXPXzVw1c9MQSNJtBoAnZQWk3CDh7s4MEOHlpNwAhN+KzEZ6WZDwpAT1AIikFv
MEBHdxOaShDdTUS3R3R7RLdHVHtoKIGGEmgoQUR7aCVBNDe5lxHNV4KrwbVgFBgNbgZ3gYngbnAf
qAKPCsnKEqwswcoSrCzByhL4tMSnJT4t8WmJT0t8QHHgS6xgJqP6rdX5zJVvrGaVW+C4bfToVFbY
3lN2F4eo31rC92vkm8pzWT/1Iz5dz/oKxBhj/d7dxtdgA9gIT7cxfgfSfj2cXA8fN8DFDfCw+qtL
P+VOYzQHVyvfJXqmMK8FLwLFDC/DoW9knzSH83OZzyPqFvgT9E8sL/XH5vzUcpP+qeVmomgT42aw
jfun/Ufw4RQ+nMJvU5pnG5TPMq7wWzLc6pdpXt3E8c3KX5lvBR6Awx0i19kOWsF3vCcN9vAeH41L
v6zjp5GP8sfCs01wbNNBP5F8DufOYwwzXumn8MkUPpnCJ1P4YwomkjCRhIkkTCRhItnZTzDjoyl8
NIWPpvDRFD6aEgGtrTf9nSqCO3ijV/tPhmQZa4L23pnoXulzHjlwAay00p+L7ibAWEkYazL6e5C7
DEZ3IzVjpf0fmUdg4SP9BHcebPbzV4lC7gjrgMydyriT5E413GkEd+nHXYZxlzK5bW9atvD03b6D
TE3FCX9c8d/8ocVf+jXFW/2hIkyNN4wabxg13jBqvGHUeMO4ew13HyufxmeqVY6mr36B+YscfxkZ
X2X+OnizwzfiRGG9nMv5ebxW/rEN9t0NK8NhkurENGHdfPirm45Mh8h0zGM4NoBxIHad79fjFypK
64nQenxjMlFa76wBa+mfmxk3cX6z9gnptPg1znbQCr7j2jSgNydq6/GJuOYj6l4i2CF6HaI3w0kx
v05z0njO0Rm5FfjQveBn4Bece5Rzj1H9FqifFmr/1JNIHaErkzfJQipSV9IhNIMtYljW3lNFfjae
Pf0T/QsAFZ6uQXaTIdtE1D1dhN0HRFSY+EuGp9Rf5FmIvvvJ33DdZPCkyidY9CnG34FnwLMqPvd6
8nnGGp1jquTvGf8Aapm/wHNe1M+eIF/h2B/Bn8CreMA0xungNZWHOD+LsQ68zrk3eO9bzP8M/gKU
3PVgDs96l/E97jkXvM98Hp7VgCd9BBbsbZKNe5NyEfPFYAlY6hfIBOMysJxzKxhXgk+YU0Ppv/zw
Gc9rYr6Ge33OuBZ8Af4GqK2IgTFyPfgKJMHXYCPvb0Y/m/CxzWALlfdWjntgG3K2cN8d2sMlPubs
lwm64V8FfpkJN5Dxx5jFjCobHKOigXEgNR5rcz4A88BHALs5C6l4PmZcBBbr/FrlJDi2km71U143
gc9Vjt3rOV8w/g18Cb4G34AtOudWkVGqyChV8FcJ/FUCf5U4Ozn3rcq9vHevzr9VLpW7K/d6rumP
cQ8B+aAb6A56gJ7gMPVbF3uTbiEIMu/F+1gT+XoE+XqE24f5UX6B25exH+jPsUHEwQ+YnwhOYn4y
7y0Fp3JuKMdOA6f7Ne4Z3CsEzuTcWeAc7nMu585jPpwxzGt6pX2ZkHnMd/bLgHSM7r3gZ+AXnMtm
Q2LJISNWkRGryIhVZMQqMmJV8Ya9yWJsW9wMNoFvQCdZsjdx3Ptif4y4SldZz1ExtWepF2CoF8mY
xBI1gWKlCbDShH0Zi2vf45q5XLMKdiUvU1kliEY8BXR4Cl7RTcdjgdmTTFvop/GUdMZTdIw2aYZa
6I/VWSvBuNKfQP0wmfphMpUWNTFjbtZqoY7YDlp1PQEz6RpZwk5jqbb6YcEk1ktSVSWoqhJUVQk0
nUTL6YyW0fC1zEdRMY0GMVVzMO6n8Rzmuo9zv2ivQXjvY6oO6SSjdVaHHGvQWRp0kx2aVRpVWlwF
vtDVcEGHtgoyFZXWRO6K1eq6gyBwwPBs5ZQrcdX/QKqTyExJMlOSzJSEg9XPnybJTknY0oMBkzBf
Eh9o1ln1ZcapuspOYvNmbL0aW6/GtqvN7lQeA/zV2K+ZSE5iv2ayS3NHtbxOR2uSaE0SrclMhcx5
aiuiM4nNmrHTauy0Gjutxjar3ShVw4PgIfCovxoPT+LhSTw8iYcn8fCkuFp3FI1+GzVSGzVSm5Zq
I+MmsBkgofxeWHIX+DvYQyYRwAAS5IEAUP3rIYxdQaaPbTZ7MD8MHA6CwAK9gAuKgOpz+zAeBVSG
Ohocm6lMqJfaqJfa4Ic2eKGNWqmNWqltv1WeyeuzwHngfGG5F4ALwSXgUnA5uAKMBJk+tdkdw/x6
cCO4CfwE3AbuBBNAbh97P6/j4Jcg09M2U2+1UW+1UW+1UW+1UW+1dda/9kYGYeMfDfhHA/7RgG80
4Buqql1F9kxQsdRlui3GTEWSJEOpijQhVfW4FubfA1NJcJSuDlVl2ETd9VvyomKZF6hlXiLTZ5hl
MswyOdu/KVapgUWoaUC+7s08mCMJc3gwhwdrlKBnD4+rwdtqYIvJB7FFlhXwrhrNCJcRwVeDa1UP
hdeNBjHVOTPeB37B/FHOPaa6VsXaqoYT3VhZA71kNlY531XFIWN7HB4JSjLxyNXqqjWZqN4vWl1Q
BPqDU7NXB+Q8rlygq0pqU+bb/MkiKH5D3bMUtliDdlJoY5voZ53up6wIeAm8DF4BU4kNVxRw3wI6
yRLuXcC9C6iCInSNJXSNJSLP2KhrpX48w+NOBfpIga6eMkdUj56RIyHy+H+q+hu9VAhNWpqu+jMK
1TfPw/ILsJF6V7O/WZ2V23UVTgY2ttENtTLuUP6g71YvF3LlKtV9gy+wXplfZQ4hC3ZFe919lWWb
yLJN8HSTeyTHSsAZzENgOL7SRf8U+Tx00y6tqgip97h/iiqSdQpD/0Xhwfv9tl72E66sX8ZhiDp8
Mw5L1MESddjI0d0UlQXrrJfqKdnfBVX7EqqyxnZqh6mOKK7Dhg42dPDjeM7vY9YR0XVEcR1RXId/
x4nkOuzq4OdxIq2OSKsj0uqItLpi9f0XDpqqQ1NNaKoOTTVpTanM+RlPXqN2h5incjSV0VISLXk6
m7mMRaA/OFVry0NbajcoKX5AhSupcCUVrqS6lVS3kupWUt1KKltJZSupaiVVraSKlVSxkipWUsFK
KlhJBSupXiXVq6RqlVStkqpVUrFKqlVJlSodhQ8AklPNSao5SSUnqeQklZykepNUb5LqTVK5SSo3
SeUmqdwklZukcpNUaJIKTVKdqepDikPh7VZ00AJft7JWtW/XCk+2wpOtrLGFNapObQO2ocoTXbi+
GT15XK8yRzPXNnNtsxigP8H1/MloeaLRwrhd++VktD3R2Mn4La/TmZ+o3P/TC/9cskAz7N8M40yG
3ZvpClvpBnfCNJNzdjPPVZ8Ew8jNsMlkGLcZxm2GcZth2WYYZDKM2gyjNsOozTBqM4zaLIL75fee
mRyv8/d/s+PRae4OwLGeqbwjCh4ED+lP/nb7Ndm9DF1/C4NuqEL/Da9WeiL1N7sK8C610yH1dQP0
zxrQPbW/i1dpfyX3adAdtnrnRP13/dVfi46hkVR2j2+AKBN9ibo6oq6OqKsj6uqIujq1W0JPinJ5
mqn/wrRHn5DD3freHr1Bkh5S0kM6+3HzDRyL+Q30kJIe0qGHdKh9k9S+SWpfeJpzmqf9BuRD9o5O
r0H017KZfhxbJrBlgi5lGLWn2uFJ0BUP0/uSxYy9eX0M1w1gPlCU0cUOw6YJqu9hdLLDkCCObRPY
NoFtE9SCZdSCZdSCZUgQx9YJqu9hSBHH3gnsncDeCeydwN4JMSBbBef0S/5U9OBl7I8OCkExyFTB
jt4zH8i6LmN9mQp1KvpoIFc1kKsayFUOuarhgJ7AQy8eevHIYQ3ksGxfwHsfE06nvnMY1egIqtER
SFaAZAW6Lu9N3rgS3AUmgrtBlSjgDgXcoYA7FHCHAu5QoL1vA+vZgMwbkHMDz9ugfSVFjaW8Sa07
P+uLPbFIIfNikFlnDWus4X01rK+G9VWxvqrs+qpYR5Vex6Oce0x75BN7qUHp/pvVd1GY1/ifmtf6
W4TB/1/q10lm3+jZRn3mEHOkv8W8yt9jXk30Rv0vOVpvjvK/M0f7i0QeZ7dzdBtHN3HE48hV/g6u
3cEdvubofGFyTRuvfsd1W/WdN3Q8Q90NZjNvgyHuUN+iwWwBs7Wm+gZV9areLPe3mup7VQ1ebUWe
sTzxFu44jvvf6q8zb4dZ7vCn8Q6yF7PtzHbw3tu55g5/Bq828Wosr27z7+Rur+s7EcPcYRezDVyV
4tXv/aVmLR79ghjIFS/7T+r/m8ThVoWYbd0rIlZc9LGWiT76uxengoO/c7HanSMq3EbGhYyZ71is
19+t2EP/xkv7z/bv+y2Xil5vc7xelDplIuwMEZXOUBFxTgNniqOdYerbyHnnIK46NfMNIep7ydW3
7QhTf/9j5rsHa4ShvtubLO+JUmObiBmtjDtEzCwDQ7haclQdKRWy6AL9zY0x0e2//Xbz9TnfcG6q
p/KsLkUX8rwTxX9xh0miWjzJPd9hXg/mgHdFTAoR61Ygqq0BhmsNNPpbg0WphSTW+eBH4CJRaV3M
+UuZj2Y+gfEuEbV+wzida2eAjbx3q2ixQ6Lanma49kxjiD0LvCUq3aeQ5FVR6s40XHcWeB2NvwGQ
w50nqlmhVXSpCBVdJ0qLbjSGFN3Giu8QUVa9ouhOWNwS74uw+AB8COaB+aABLBThwo9F2AqBK8FV
4Mcgqr+Ds9p6hnEWeme12DmGnWNF5bwvdOC3hKLvavRd/f/tt4X2YpX4mu9TD/jSERXmGTzx/0Ws
yHbtijw9m7NP16LAGsBTBoKNotyeJu6wZ4pJ9iwxyZ0pyt1Z4HUq+TfAPD9VdCMeegjvCHFVhKsi
ud8gytmICBzwnaYR/a2lJkejHI1yNKqv6cOrPrzqwzUW14REb/E8798N9gJfRArXg69AkvUPEIOQ
cpB1CvOx4B7QABbrb1YdhDwh5Amhm3HoZhy6GccK+rCCPvt9h+qNePF4ZDhBx9uTPOl5kX9gvCFF
PlLkI0W+ij0kyUeSfCTJR5JKJJlEDEaQJn+/GFTxN5Zj94BM7EWIPSVpPpLmI2klktYiaa2Ou1fR
3EzGWaA95lS8Xae1WZsTZ406zvp2SLqbmNsLfGEhmYVkFtJYsEJYS5ORxNJSLBZW7pNznjibJ852
36HLnydmE+URory06DJRXnQ9T+1MgkIYyhJbAPk0aPGEk8Gt4M/gL+Bt8A74GKygv18CloIEWIat
LwaX837FrRVEdQXcWkFkV+iIIUrEjcYpMC78ZsC0xqlgKDgNhETIOBOcKxqN4eA/QBicD34ELgAX
gau55scgCq4Fo8BogPWNn3Cfm8E45reDOwD+Z/wU3AkmgLvAfSAOHgAPgU285xuwRcxG8tlIPtto
gZO2g1bmO8BO5t/CUY6YTaaoJlNUE8WzzQYxu3A7ftQKyCKFO8G3oA18B9KisfDvIlS4G+wBe4Ev
QkEBTJAHAqAr6AYKQHdwGDgcz88TjTbn7Z6gEPQCR4qYfRTH+4J+vO4PfgBOBCeBk8GPwCVch7fY
l4ORvEYv9q3gNoB+hIu2K9F2JdquRNuVaLsSbVei7Uq0XYlGYmikWjN0i4igkQga0WyNRiJoJIJG
YmgihibUaiuRuBLpKpGuUhxjdPHHGX1BP9AfHA2OAceCAWAgGAQGg+P8oUaJP7Twa39c4QawETSD
TWAz+AZsASmwFXhgmz/ONkE3UAC6+0Pt3oxHgOPBKeB0MByob9TMM3rikxfBilvRQgi/HwRfRGG/
CiIwSgRG4YooXBFV/CALxCR5GLDEJPJ0RQennk/++BG4iBrjYl5fynw08wmMmfwcbedb+y3/K52H
O3i3PQdzPJODw9noVNxQTWRGiEz1rdBzicyYGC9+zv+PgV/BuJPA48x/DaaJPmI6eAfUg/c4Nhe8
z2r+ynUfMH4I5oH5oAF8xPFGQC4RH3PtYrAELAXLwCrwFXl6A9dsJG8F8IFNjFuwebsvZH0A7axF
O2vRztqOqGgQ1YFjRSm1QUXhIlEaPJIKpS9c1Q/0B4PAceB4WPVERqKfGqICbfaxqLfQZina7ENN
UUFNUUFNUUFNUWGN4Rzsad3CWEHFcy/58wHmD4GHQSX4De+bzPgk+C1A69bToJp7PsM9nmX+HHge
1IApgCxv/QHM4vybXDcbkD8tsrn1CZHDtW4xmAKj/x7Ui13wWSMVgMq1u+C1RrJ/hOwfIeNXFw2H
V68Bo8BoXfNUiIDK9tlMHstm8hh5MYGOVxEn5MIcFmpEh43oMGaVIMt1er3Hs95G6z7m9wPWTZUS
QaaYrlLqqezmiI1aJnKh28jrhbxul0vZVMkw7SAZinUF5sGs20Ar2CEasesK7LoCu64gvhuxbSO2
bSTOG7UNKoweWp4HOtVLpBO9VIoePCnMk2I8qZInxXhSpa6GspW3roru1XfaX8ZDxbN0R2nwPdgF
/u7Ptz4AH4JF1PXquPV/9RNEaX/oQT9FZLink7NU31lz0B7HcR1VfScVPfqrRX+16K82U93ryqJy
/8reT+2r7JlPoCq9S/twjJxeof4GXqaaoELLsEcF7FEBe0yDPabBHlRuYloOe1zbKXscytP78PQ+
3LGUO5ZyhwruUMG7K3hHKVf2Ef31ejpfSzVrqWYtueuI7LeOSw+Su1rL3VkFtE/eWFbeKPJGsvKW
i37/RJIOre4nQWcazEqRo7VaJKjNaq02R4pwVor9+56r4NwwnBuGa8NwbRhuDcOtYbg1Cq9G4dWo
UDXvfNAAFgL6Ifg0DJ+G4dMwfBqGP8P/IMYaWU0jq2k8MMYUh8KfUXgzDG+G4c0wvBmGN8NwZhjO
VH1XFL5UvVcUnozCk1F4MgpPhonRUnhSdTe7iKhpWZ4Mw5NheDIMR4bhyDAcGYYjw3BkGH6Mwo9h
+DEMP4bhxzD8GIYfw/Cj6uWi8GIYXgzDi2F4MQwvqk4pTPyHs/E/O8uLLcR8BVwYhgvDcGEYLgzD
hVFR0MEDrdqm5WihHC2Uo4VKVl95UPz3z8Za5YFekeOP4QPiKlOx/7OY2ucZ7dl4f8842Ddj4oh/
YMmOLNiZJTWTH6+zV2k2c+UyZ2kHc+5jzVJYU/eP4jDdOx7ImgVo7jBgAWff3oWqww7S3mHiGdix
EwYVe2DP98Ff92dT61MYNZ1h1SL1rYaF/9Id6lUeArl3OpaerJwOp4IOp4IOp0IWGHnyMGAZefRi
5XQ8FXQ8qs5qwbItdD7l9F9ha7TuDivov8rpucrpfCqw6EZ7lpFn12Hdt7QnKpZscV8n+71hBN13
OPYeepxnHIlVZ2PVSUVXikqs2ohV5xaNN47Hqmvpnds5VfGp6lgNvW9kMM/XZ3M74VJxAdwQgRsi
cEMEbojADRG4IUL8R4j/CPEfIf4jOr8vY2zP8YF/kOf7srp+oD8YBI4DKvefyHgaoH8jriO6FrhF
59+D6gHiO0J8R4jvCPEdIb4jxHeE+I4Q3xFiO0JsR4jtCLEdIbYjxHaE2I4Q1xHiOkJcR4jrCHEd
+Z/WF8R6hFiPEOsRYj0ibs5qKUTVSvUMHmf+a/AemAveR8d/5fgHjB+CeWA+oJOgSoUXgfLgj7l2
MVgCloJleg+pcr8q1RCW1m6mSq0lWmqJllqipfYApp2W079Ng2VjVKkWVap1gBVCWCFE3JZnrRCC
cWNYIgS7WLBuDNaNwboxWDeGdUJZ1g1lq6NpnVglhFVCWCWEVUJYJURlasG8MawTwjohrBPCOiGs
E8I6IawTgnljOZVpCEuFsFQoa6nQQRXYATySY5kQlgnBwlQFuRyiKkMkDh/EHaZYRY+S9X9xRGeZ
uYODc7Nxzi5lJ3sT7fVLm463fbXAwXsSalerFInUPlspEpWKMw7cPfx37xpay/4Xdw4l2ipFW6Xi
0OxeWBg9DkKPgzhTyZlKdFiZ3Y3rI7pjjYewxkP/dFdI7wj57+sMp3a3DxfP4YUDxCS9+zWP+Xy9
rzSJO0zjDq9wh0mu2jl8XczlDnO5w9zsHaYV3aR3+aLiFLzDEk9SET9PtL/DvB7MAe+C3RzbC3wx
CZ6fBM9PgucnWQOIlcFUlqcwLxOD8CILL7Lg/HI8yYL3y+H9SfD+JLzJsqZz7QzQwOvFSDjN6GHP
gLVmGi65wM3mgnLNXK/q+m8Xku8iJwwhJwwhJ5STE+ByYwg54dOi69DBjUZ/PG8FntdIThiC523U
e5YVSJqbiSqymSiMNBVIoDJQC08v5ek9eHoPnh7JZqKIzkSzdDbqz5P782T1VJen5R2Ugc7qiCrF
iZ3x4ULdlZe28122Hu7gtdzuW3Faxz7F8UDVyqGc6DyQu0ZzTXvEtnfWanfxGd0Vd3APXUg0u7IY
K4t11NS5HTEV/kH8A2d2dCblOsJVdzJbV1QD8Zhwdn84jIeE8ZAwq6vNraqy+8VhPCbMyhpZWSNe
E9Z7xkO0h4T1vvF0xhkgs38cxj5z8WGqBHLVqzp25iL5XCRvQfIWpG2Be9SurOoC1iJhLdIRFdjo
TjFNHJ/dR44iXRTpokgXRbJdSLYLyXYhWRTJokgWRbKNSLYxu38cRe/T0G0I6aJIF83ZM44iXdR+
0f8sK10LnlOKbkPZfeNGpFyI5+ThOXl4TihTx4hd6LKWGiac3UfehcRvIPELSOwi8VxxIhLHslVW
ORKXI3E5VVYPqqweVFk9slVWORKXd/j2YKycqbQi2r/HMleV1nSOzwCZiqsciVO66pqhuIjKK1N9
KZ+PaM94VVdgKw7w+2g24vrrKiwjveL7vUg/F+lnd8TBMUi/v+RCrNivRtwn+cas5OXoeXa2PlQS
lyOxllZ3JrA7Eq1ForVI1AOJeuhIzNSFLhK9jUQRJCrPRma7RP2RaIX4wT/7/CtbhQzKqUL6/IN9
stwKpDqnAmmP2LDeD+vss7TrdG+mP0vriMQp/3AfKqT2WvTnbCXoskKx2D+ptyty6u1d6HMX+qzI
Ml27J1RotpsOZmRYL1t7K+YLdeIBFTnMp+pwV3/WiAeg67noOoauK9B1j1wWFAH5or9UzvWXOi1g
O2hV+c8Iijz+CdGFStwQPURPZoXCEV1FkTiT1xeKS8k8V4pxYqiYKB4Ul4iHxS/Ej0UVlecY8s3j
4gbxBDkpJp4RM8Vtoo4YeYTKchHaWcK/arFcpMTvRNroIt40DjUOFR8a3YwCMc84zDhcNBiWYYkF
Ri+jiF6vtzFYLDZONkrF50bIGCa+MC42LhHrjYhxmUgaVxvXiQ3GDcbtYptxj/Gw+LvxiPFzo4vx
B+Mlo6sx1XjV6G6sN5qNw43N/HONLUbKKDI8wzd6SykPMU6Q3WQ34xTZXXY3fih7yp5GmTxcHm4M
kUEZNE6VtrSNodKRjnGaPEL2M06XR8ujjbPlsXKAcY4cJI8zzpPHy1IjLH8oy4yL5VB5hnGpPEue
ZVwhz5bnGCPlefI84yp5vrzAuFpeKC80ovJiGTGulZfLkcZ/yqvkNcYNcpS8xbhJ3ipvNSbI22W5
cZccL+807pYT5b3GvfJ+GTcekA/LR4yH5BOy2nhEPiufNX4lp8gpxiT5B/mK8bj8k3zVeEpOl68Z
1XKWfMt4Vr4t3zZqZb2ca7wgP5QfGlPlfLnA+KNcKBca0+USucSYIZfL5cZrcqVcacyUq2STMUuu
lV8Ys+U6ud74s0zKZuMd+Y1MGXOlJ1uMD2SrbDXmy7T0jQZTmtJYYnYxuxhLza5mVyNh5ps9jGXm
4Wahscq0zF7GatM1+xhrzH5mP2O9ebQ50PjKLDOHGM3mSHO0sdkca/7U2GG+bL5s7DGXmEuMvWbC
XGb4gUMD+dIofLTweWkW/r5wmnQKXytcKI8pXFz4mTyn8PPCbfKSwl3BLvLG4KFBW44P3h4cL+PB
CcF75MPBnwV/Jn8ZjAfjsir4YPAh+WiwMvhz+ViwKviofDw4Kfi4fCLIPzk5ODn4pHwy+FTwKflU
8LngC/Lp4EvBV+SU4LTga7I2WBd8U74crA9+JP8UXBj8WL4VXBxMyL8EVwbXyTnB5uBW2Rj81jpE
JqzuVrH8yjrC6iNbrL5WX7nD6m8dLXdax1oDZZt1nHWc/N46wTpR7rJOtobIPdZQ6wzTtM60zjQP
sc6zRppdrautqFlsjbbGmH2s660bzL5WzBpr9rdus243B1p3WOPNwdZEq8IsseJW3DzRetB6xDzJ
+i9rkllm/dp62jzNetZ63jzHqrXeMYdb71tLzTHWMmu1WW6tsdaYd1t/s9ab91gbrU3mfdYWa4v5
gOVZnvmgtdP61nzISlvfm5XWHmuv+XPbtE3zl3bADphVdje7wHzU7mEXmo/Zlt3LfMLubR9hPmn3
s48xn7JL7OPNZ+wf2KeYz9ll9hCz1j7dPt180T7THma+ZA+3h5tT7Qvsi80/2lfYI80Z9ij7BnOm
Pc6+3XzLHm/fb75jV9q/Mj+yH7efNJfZT9lPmZ/a1fYz5mr7ebvWXGO/aL9kfmlPs6ebX9kz7Vnm
1/Zs+y1zo/25/aW5yf7a/tr07I32RnObvdnebLbYW+wt5nZ7q91ittrpXkeabb1O7nVa3hG9wr2u
yju217hed+YN6TXdMfKGOd2cwrxq52zn/LzfOyOcq/KmOnc59+e96bzrvJv3rvO+89e895wPnQ/z
3nfmO4vy/uosdRJ5jc4KZ1Xex06TsyZvqbPW+TJvmZN0NuWtclLO93mfuxBL3mY3z+2S943b1e2a
t9XNd3vmeW7QDebtdHu5RXnfuke6R+Z97x7l9s/b5Q52S/L2uie5QwKGO9Q9M9DVPds9O9DDPd8d
EejpXuReEQi6V7tXB3q7UXd04Aj3eveGQF835t4c6O/e6t4WGODe4Y4PDHLvch8OHOc+7j4eGOo+
4T4ROM19xn0ucLo7xX0hcKb7svtK4Fz3T+60wHD3NfeNwPnubPetwMXuX9y/BC5133HfCUTcOe6c
wGXuPHd+4HL3I/fjwEh3iZsI/Nhd4a4MjHI/dT8LjHG/cP8WuN5tdjcFbnRTbipwU9F5RZcGflJ0
WdHlgQlF1xRdE5hYFC0aFbi7aEzRdYF7i24oujFwf9FNRbf+H+6+A06KIvv/VfUGYGHDdNVMz2yA
JS4sLLDs4gIiuCA5iAgiICIGOFRMqKcSTkHBUzxB9DzFEz1dFfTk/P3EE/VMoAIKSlyCkmFVREAU
MND/b72ZzYFN4P3+VZ+uqX5dabrrvXrf6tdV4dP81/snhd/rv9F/U/iswNrA2vD7AxsDm8P/HNgX
yAufEzgWOB4+N35A/KDwR0met9SMOee/OHAADaEr6f9D5x4oeeYecI/Az3M3Ir4Dx2xzuD+FUmSf
oXYswfF2CdoaHGuLnM+Dn+wuCbbB/c7NNWEly98dPM6scw/iOIFjT6VzfOMug/+mkqnz3O1uHn6P
VLeFZZR5MOg5vt+UjVr2mucN6tdVKSf0W9g2xaUdC1IKexrfpYO10vhQjfC70erd+U/Y/aE6taAU
k+enSqau5X9RQS0/VDlXbui3xLPIp4DHj4bOK/kv3J/Kvi/F6Tg7Cp/r7sSRW9iCajyL2e7woOz5
73bF5YqbVeLqRDfCVe5Ejn/irsFdWQOplsRnR5iyBr12F8535d8llnqQCRXUucRdXpBGMSWX/RL4
4F1fzmXtZn+EQ1PqZL52sOTzQOplIQnMtbppRerKZb7YfTqZE7wHRo5xjtzT37maOW5RXuXlP/dN
cx8Ke6sqI01uYcxdz//kcM3aWaz03cE2cNzw3l487QM4fjrt3T1Y5dFL1KChZ9zhP+8+G9LzzDr3
e/cj90P3+9+7HUFn9LUal/F5ybN8SjkaShk8dKacOw9HThFCCmpPx296qZRrCtNAdq1xc4IU/K4E
/60MlVWBhC0oab27vuAkqRy6OVsOfwe00zvcBSGa4fWc0rWgNZMhWxacnp+Lc0ehxMaYsgGhOYYH
j1CKeaf/P9Vx7tU4ppSglWi7mxXyY09bWkjOuQsgA1bxv5rnphW2vXZGfIyDa8xoGDo7ihqWucNB
K1E6j6OFo3da6AjiizyW/3m10Z6z50rKVIwvy93niqO838+5W0qcl6PZlupf692lJqyw7EJ8YTh8
5Zn+z4yVDc5YVW6Kg/naYUgrOwAJ9EIVavicwzOkS3Hf30tBjP9TUKKUma5AmoY0lxnuEBNyvIzZ
A476C4jFJbSfzowzNaQUL7+AE4IaMreXmuSPWO4Qt6Hb1Mi2YqNKOssjM2IsKTKKGNmfTkn8JBdA
oqeU1wzkWhZKE/rXIc0clFAfyMmnFuQxUma4+XaRawmOaQXjKrg3nxf8BdK+8OpkI6uCev3/HedG
lDifeepXt7E7k+PfFrvybUlKsau5FfGGu9XdavSWkppLkM6xI2Vp3e5NJc4PF8SWFx3PT/1aQd1l
jN3uD+6xEO42xyfB48w6IzFLydxy9I7S97Iod7tfo+2bgxToNgfddSGEuZC54qh7OIgSyyl7m7uN
70HJ0YnpHDNzUDxrAO7bz7j4YKiu91DzK9C1PyyW02hcQVS7O7/1fLzBZ/vcr0xYXns4zf6CWB7L
5jOMRvh+VW/eLrmWm3JWnXs1y6igpC2LL0r1it/HFfYlPksrcXUFa/MrqlTi0dppWfVdKT1qrTvN
vb/onHolyzkjz8h9rcT5znLSlWive43b04Qcf6/YlffMAe4vn/OTyr1S6457zJKCs6ZctzlYf3Cz
TuW5AXcax+dBmi0wnucGJ7uv8tkaHDmhcWcByzxzNrHCUc/IxVx3AOPQc5kyG345KMuDKMsdi6eZ
y7Rp7Hcb/QEI6ZtQLTnB31B5s91saCcB/I5lDik6NzitRN17Sp65e5i/d+fPPJu5kjM/X1I4z12E
Vu13P0Y/5t9lBTOna4pqxTV3fI+WmVnYoqXyU6/FWiqoP6vweZdx1fSRHKSZjX6Xwjq+ocx1Y9ET
Z4by56Dthjqb/YKK5gHQ1wcgNEdwXnxA0bpq+E9q5Q1f/rhUzdzLazJn4Oah5y4q9+qR4DubMlC+
6e+LaFGZOm255ZXhFhU5qu2grRlOP1bJ1L/7OHmmXei9+u8yCxPqM+W8J3G/ZIxQqtcYeujdXTD/
79T62ndAMV/i2Px7t+N3c1fVSinVlQ+LiuYs8izOuozi+mtlbg3a1L6K5yLKzLW88Khh/bUz6hV5
O1mFXAX/osataFJuHeWMxGWO0SnQoFPg61WqTp4vDGk/SYWUcty5lSqzYpfE9aRXoqz00m+2asWd
mVL/G13l5tdKy8PgzFCvGtdtjsdqUgik41eUVJ5FUpBbC7WnAhu9KnNxOeVnnT7N2XXQRX4qe9a2
kvkP17ABSeXV7R5yD5WpRzG9FlwtzVu4G/jN8eFyrvIohl4X0vUKfgtGt9Lz6aepL7fYrFrw/UWN
/0tobr8c3ODuD9kx5r9rPliUzrHva2JBGcStZ3MmqXZc5RFt0btj7pW7I4QFchD/nPHAPPe6Im/t
x5bLF4fL7mvF6ZBYe+Bfcd/B8UoBbba72J3lrnRfLJYz112GtIVvJc1MwvlUYJkM3FLijUepugvf
ve1Gf65lq2C0L6/A+vEQI6dQLcbaq5Jl9D71qxub/3aS34YYu8EUPtvLsy357zuKaZ14Djlll8hX
zZzibncy6zvBOchl7EeC/i6fT+N2ButbzqGZERxTTnlr2K5igLFr5PNAkWvLuLTs/Dmd4u/uGXOu
N7ai5Tb2bM7TGv11ScFZFupWfH+C92jAqaNuRMh2cjnfF/jQs1jOs3a5hh6aFwzqwiY2u0IbTvOG
ORdcZJ7XhUwJPovJwXfI/LTW8DyteRudw73AWC1dzPOqRWoLlTcPz34JzyO/yM+w6DztAr5urIWC
M8B7i7XE2ADs/a95FsXfwmSXmDO/zQ247YL6Or//282clsJn5imsZ1rIDiFofcFhTkUzqfwUmaso
f848yAFmjjzYsxcz9wafdHCG3Tzn8XytmI0HU3Ldp3h2PTf0JLOK1lWi7lUlz8q3JznbrpAnTpuy
UAop/v+f51s74InsZG6vJNItD0fzm+HgG+HgGwVznuMuDT01Qzdjfk4Zd9jMTK8xUujszKafXVdg
772EJdOK8ue1ioyYxhZuGe7i52WmW+u2qXmbMDLk8mizzFir41hR8bvT/KcW4u0KRrEieSbn11bm
1UrYd1ZYesh6k3vuweA45k6vWZll1lPyncfFlErJODge4sFuNaoBZbjv4PioivmCfatSWmOINyv5
7UxVXYEGn/9b4suwcvNtQM8zsnljvp1JGWnyvxmahX46nJ92YY+S7qyCdLuKvqmqjnO3G20ixBeP
hnrXMvfjCvMUe2aVsz/IHx/LuVrlt/8l8i8vounsPXN8UUbNmWS4I9ifM0nC1667pUhdSwr6/0T4
sTiC0ibi1IZTedDSIkpasVXSdQNPZ57aY/YS4PiSwh5WdVfZNrhNS5xnG+s1N/tMfc15ZlzJt8p4
FnmnNoCjIk4drlaBmbj/9d36HE/mZ5FZ/dZVtg1lPIu8//vPotCd+i94T3iqUm/ga8J5JUray6is
vPko/lqk9BvUwq9Igm8yKj9vyyNHeaO5pKkURmasGkSDqS8NobupP82gmTSF7qN5NI3m04v0AP2T
1tBC+oLy6H36Bn4LHYTfSoeEpG0iXETSYVFX1KcfRIyIo+PCFqn0s2gvuiHWXwwSjc16J6K5GCqu
EylikpghssXTYrEYIXaJfeJqXtFkIq9oMoVXNLmHVzSZwSuazOQVTe7lFU3u4xVNZsk2so2Yzatx
3O+Z7TkuHvD8bMeJX2zb1tK2E+0k6bUn2hOlY19vXy/99g32rTJg327fLpPtO+zpsjGvq9HSnm3P
lq3tB+1nZBteP6OH/ZK9QvayP7ZXySvtz1SSHM+rYrypGqvGcplqqprLt3hVjP/wqhjvqvaqvfxA
ZagM+aHKUv3lcjVQjZa5aowaI/PMehjya7MehvzWrIchD6vb1O3yqJqu7pHH1Ez1oDyhHlIPWUI9
rNZaUn2hvrCy1Xq12eqhtqptVh/1lfrK6qd2ql1Wf7Vf7bcGqjyVZw3ilTAGq+/UIetCdVgdti7i
9TCGqpPqpDVM/aYta7gO1x7rMl794lod0EnWJJ2sW1i36Fa6tXUnr34xlVe/mKGzdBfrXn2e7mbd
r3vq3tYDuq8eYv2FV794nFe/eEJfox+wntFz9HzrY17rYq1+Ui+w1umFeqG1QT+rn7U26pf0YmuT
XqqXWlv0Nr3N2qq/1F9a25wHnTnWdrPGg/WV86jzqLXDrPRg7XSedhZae5znnBesfc5LziLra+cV
5xXrW+cj5yProLPKWWV953zmfGYdMis6WN87m5xN1hGzooN11KzoYB0zKzpYP/l7+Htax/29/IOs
k/6L/BeFSf8I/8gwyz/aPzYswj/OPy4syn+1/5qw+iTFYV4dqDOFw1sUAR9GkfCa6sBHUF34OlSP
fRTv/duAfTSvJGR8HMXCR+E3jmzywGv82uQHolWIGx9PXvguZHaqOpcc+Ea47qfzKADfHdfjKZsS
4BtTIryx+GuBVqVQS7ShFaWhVW2pHUpqT51A6Uxd0Z7zqA/q7Uv90J7+8DHg3QFoheHeOHDvxWjF
MBqDXJfDR9BYGod6rqTxaMkEmoiWXEuT0ZJb6Y9owx3g8saQANNR+5/gbXD/3cg7Az4NMmAmWnAf
fCrNgm9Os+Fb0P3wKfRn+DRIhgdw9UH4ljQHvhU9BJ9Kf6GHcXUuJEhbSJD5lEGPwmfSY/Ad6a/w
qfQ4/Dn0N/gsegLerJn2JCgL4DvRU5SDEl6A9GkO6fNPakavwqfSEvo3KG/S22jDO/QfXmvrY9A/
oZVowypajTZ8Cp/KKzU1g9xag/gXtBEpN9EOtGcnfHPaRXvQqr2QaJks0dqwROtIh+g40p+gX9Cq
X8mlcwRBxnWCjAuntiJCRJAQkZB3ktd9UqKeqEfhIkpEUaSoDwlYFxIwhuqLWBFL0SIO0jAWMhC9
hFeFUkILTY7wCi/iPuGjgHCEQwnCL/yUJAIiQA1FvIinriJBJFA3kSgS6XyRJJIoWTQUDamJaCRa
og2tIGHDeV0pJTqILoib1aXqQtoOQO0DxUDUPkgMQu1mpalYSN7haINZb0qJK8QVSD9OmJXcrxZ/
QO0TxXWofZK4DbXfLu5EvXeJaahxurgbNd4j7kHeGWIG8j4tFuI+PCOeoRbiWfEPShPPiecpVeSI
F6ileFG8RK3EIrEYlF1iF/UTu8Ue6iH2in2IHxKHqL/4XnxPA8Vh8OEAcUQcoUHiqDgK+g/iB9CP
iWOg/yh+BP0ncRy5TogT1EucFCepj/hZ/Ey9xS/iF+orfhW/gv6b+A30U+IU6K5wqS9GEUk9pSUt
ukCGyTDEw2U44hEyAvFIGYk4xhhqb8YYSjdjDOIYYxDHGIM4xhjEMcZQohljaDDGmEeos2e+50mK
8CzwPEVRnr97niPted6ziHyexZ6XqZHnFc9riP+P53Vq7FnqeZ/SPB94VlJzzyrPakr1fOpZR209
6z251M6zxbMVlG2enYjv8uyhczx7Pd+T8Bz2HKdwjGRECl0mgrx2pF2HGtp17WjEY+w4SsYIZ9O5
ttlrpaOtbU1JGO0SKdVOspOotRnzyDJjHmmMeTcivMm+maLsW+xbEJ9sT6YI+1b7VqpjxkI6D2Ph
Hbh6p30nxdh32VMQn2pPRcpp9jTEp9vTyY+R8h5KtGfYM1EvxktqivHyQYRz7DnUyX7IfogamDWp
qKX9sP0w4nPtuYjPs+dRZ/sR+xGUM9+ejzIftf9Gjewn7CdBX2AvQEuesv9O9eyn7adR+0L7GaT5
h/0PlPyc/RxKft5+Hldfsl8i215kL0aul+1XkOuf9qsoc4n9L6R/zf4firf/134dJS+1l+K/v2G/
gav/tv+NlrxpvwnKMnsZynzLfgslvG2/jRLesd9D3vft96mx/YH9Aegf2h9SmL3cXk5x9gp7Bf7p
x/bHyPuJ/QlKXmmvRJpV9irk/cz+DDWusdcg71p7Leif2+uQcr29HiVssHNR8hb7S6T8yv4K93mH
vQP/Yqe9H606YH+Nf/qN/R1qOWQfBuWIfQz/7kf7BHKdtH/G3f7FPoXyXWVRFxWmIulcVUfVp0aq
gYqm81SMiqXuKk55KBtdwKbGSikvNVU+5VCc8iuMMCqgAhSv4ClKJagEilGJCuOLSlJJpI02Q22N
NoOwqWpKqaqZaoZ4c9WcWhjNhlpBs0mjlqqtags69BvqaPQb6gT9JgthJ9UZV7uoLpSmzPrGqWY1
MKQ8T2Uj3kP1QLynugBXe6le1Fz1Vn0oRfVVfVFyP9UfVweqgShhkBqE0garwbh6oboI6Yeqi5F+
mBqOci5RI5DyUjWSMtQoNRoUaFRIc4W6ArnGqXGIX6XGI80ENYHOMdoV4rep25D+dnU7KNPVdKT5
k7oH9JlqNkq4Xz2I8qFv4Z8+rB5GvXPVo0hj9h1LNauQoYUL1NOIL1QYfdQL6mXkfUUtQZn/Uq9T
plqq3sTdWKb+gzTvqvdQy/vqA8pSH6rlZo1OtQKUj9QnaOFKtRIlrFKrkH61Wo00n6pPcfUz9Rno
a9QaaqPWqrXU2uh8oKxX6xFuUBvQho1qI0rYpDYh/Wa1GW3YqrYi3Ka2kTQaISmjESKERkiRRiOk
rkYjpGhohN+Rx6yQhqvQC8kxeiElGb2Qmph10hC6WlJ9s1oaCbNaGikdoetRQ7NmGigNdAMK19E6
hurqWI1RTMdpD9IoramJ9mov6AEdII9ZUQ3pE3US0ifrxkjTRDelgG6mm6O0FroFSeiarRCm6lTk
ba1bI32abo+U6TqdknUH3QGUTJ1Jsbqj7khJ0ESzkL6T7oQSOuvOuNpFY3SDbgrNSXfT3ZCrp+4J
+gW6N1L21QNR2iA9BGmG6qEUqS/WF6OFo/UYtPxyPQ4lX6P/gNZO1Ncj5SR9Azn6Rn0LSpus/0gJ
+g49BfVO1Xejxnv0DOqqZ+p7qZu+T8+i8/VsPRs13q8fQPvn6DlI+ZB+CFf/ov8C+sP6YbRkrp6H
Wh7Rj6Dk+Xo+Sn5MP4ba/6r/ilyP68dRL3Rlamt0ZYTQlakDdOWXKFUv0osoTS/Wi0GH3gwK9GZK
NHozJUJvfpBSzQpp1NZozwihPYPyuPM4tXT+5vyN0pwnnCcQhyaN8DnneaTJcV5AGujTlGH0aco0
+jR1MPo0dTL6NCjrnHUI1zvrQYFWjbzQqpEXWjVCaNXUFlp1D2ru7+nviXgvfy9q4e/t70Np/r7+
vqD08/enDP8A/wDK9A/0D6SO/kF+cLTRv5FmhB/867/Ufyml+kf6RyLvaP9oauW/zH8ZKGP8lyPN
WP9YpIF2jhKu9l9NF/qv8V8D3U/KCayj92HtPIY18ZiQFm607RjWs2NYw+7LGnY/1rA1a9gDWMMe
xBr2haxh+1nDTmANuw9r2BZr2DGsVccgt9Gnh0FjjmFduS/ryv1YV9asKw9iXdnPunIC68eJrB83
onuhGWexZpzGmnFb1owzWDNuz5pxB+jFD4HyF/hM6MUPQ8ucC58F7RhjJD0Cn8VaciZryV1ZS+7G
WnJ31pKzWUvuwVryONaSe7KW3Ata8lP4V3+HT6Sn6XnEc6AxJ9JL8Fm0iBZTa3oZenMW9OYl0HH/
BZ9Fr9FSxN+AJp0FTXoZUMZb0Kfbsj6dAX36XUqn9+DbA+2vQPwj+PbQsj9GCz+Bbw9d26yrvgo+
Axr3atA/hZ6dQZ/DZ0Db/gKUdbQe2vwG+Exo3pvwXDfDZ1EubUf8S2jhWdDCd+HqHvhM6OJ78d/3
0X6gnAPQy7vS19DL0+hb6OXdoJcfovPpe/judJh+RPwnaOrdWVPvAU39V7qAfoPPplPQ2i8QZlGb
XkJCd+8lLGFRJmvwjYpo8FGijqgDLbkudPco1t2jRQMRjTg0doRGX49mfT2K9fVo1tejWF+PY33d
Zn1dsb7en/X1gayvD2Z93WF9PR76eiMKE8kiGfU2FimItyzQ4KVoLVqj5DYiDfihrWiHeDp0+rrQ
6TtQHZEhMlBjpuiEeGdo+VHC7HgXK86Drh8tuovuVE+cL84HPVtkQ+/vIXog3lP0Rbyf6I/4QHEh
wovEUIQXi2FIPxxIIApI4BKUM0KMQDmXissQHwNUEA1UMA5XrwI2iAI2uBr/9BoxHtr/BOCEOHEt
cIItrhfXkxdoYRL++w1iMuK3AjkoRg4DgRzuAq6YIqbgDkwFiggARUzHfbgbWCKesUQUY4m6YqaY
ifi94u/Q3Z8GZkhjzDCaMcPFjBlGM2a4jDHD5YwZxjBmGMuY4TLGDJczZhjDmGEsY4bRjBkuYcxw
KWOGEYwZRjJmuIQxw6WMGUYwZhjJmGEYY4bhjBmGMWYYzphhGGOG4bK+rE9dZLSMpnNlrIxF3CM9
iCupEPdKL+I+6aOGMkEmUIRsKBsibC6bI2wr25JPZsgMxLvILoiPkCNolLxSXonwKnkVhcvxcjzC
SXISwilyCsIn5BPU1KyTS83lQrkQ4TPyGUqRz8nn6CL5knyJGst/yX8hfE2+hqtvybeQ/h35DtJ8
Ij+hVmaFXIQbJLQKuUluolSZK3NpqNwv94OSJ7+mlmZVXEq14KiJWQ+Xmll1rboI61n1qIXVwGpA
QyyP5aFkK2AFEMZb8bja1GqK9AYdXWF1sbpQQ2uKNYV6W3+y7kE40/ozwjetN6k3Y6c+wEivAS8Z
dOQHOlpKiZ43gJGSgJGgP3k+BFJqA6S0itI9q4GX2gMvfQr6Z0BNnYCaNiC+0bMZ8VwgqCwgqC3U
3bMVOMqsqLsd8S89OxDf5dlFPT27gakuAKbaC0y1D8gqDMgK2rbnCPBVHc8Jzwmq7znpOQnKz56f
KdrzCxBXLBCXpGjbssMRjwD6igb6igQSqwMM5gUGq4d4lN0A8WjgMQU8FkOOHQtUFmBU1o9RWTdG
ZbYdsBOg3xts1p6xWZo9yZ4E7d8gsRjGYA3s2+zbEDdIbIA9BeirAdDXNFAM1upn32ffB1Qwy54F
VGBwVwJjqj6MpmIYTWlGU30YTVmMpoI4KoaxU4z9ov0iyjTYqQ/jpRhGSpoRUQIjoj6MhWIYC/kZ
C/VhLBTDKKgf4x/N+KePvdpejdI+tT/FVYN//Ix/+jDyiWGcE8NIJobRS19GL/0YvWhGLwMYvQxi
9HIhoxc/o5cExicJQCaNgXOaqCbQlQ0y6cTIJEulqBTo3y1VS+rM+CQD+KQNdPE0oJQsRimNGKV0
Ux1UB+rJWKUXY5UsYJVOSN8ZiKUjI5YkRizpjFg6AbGcBzTVDbjlfCCWXrjaW/WGnt0HiKUdI5YM
RixZjFg6MGLJYsTSDojlQpQ5BLgliXFLG8Yt6YxbOjFuSWfccj7jlgx1uboceQ166cXoJVFdqa4E
xWCYToxhLlB/UH9AyolqIv7dtepa/KPr1CSkuUHdAP3+RnUj8t6sbgblVnUrQoN2Mhnt9GS0k8ho
p5GaoWagPQbzZDHmaaPmqDmIG+STxsinHSOfDCCfx6i9+qv6K8p5HCgoHSjoadAXqmdB+QdQUEeg
oEVo4WJgoc7AQv8E/VX1KlIuAS7KBC56DW37H/W/QKevAyN1ZYzUDRjpbdzbd4CUzmeklM1IqQcj
pXGMlHoyUurFSCmDkVI3Rko9GCldwEgpEUhpLdpsMFKiWqfWIc16YKQMxki9GCNlqy1qC1qyXW0H
4t2hdgAF7VQ7qa7aq/YifkAdQGgwUn/GSFHqoDoIdHRIfQ+6QUe2Oq6Og3JCnQBeMkgpHkjpN6R0
lUtRUAEEwiBeCtNhwE4GNcUyalJFUJMEaoqG3h8D7BTL2KkesFMcKB4gqFggKIVyDIKK1T4NXYJx
VFQBjkqkOjoJaCpKN9SNUIvBVLGMqeoxplI6Racg3lK3RBqDqeJDmKqNbgOKQVaxjKycELLK0Bmo
3SAruwiaitJddVfQDZpyiqCpKN1H90EJBlNFAVMNRnsuBLKK0hfpixA3+CqK8VWsHqahRehL9CVo
zwg9EvHRejTilwFrRTHWigXWugVxg7LiGGXZjLIUo6z+jLIGMsoazCjLYZQVrx/UDyKXwVo2Y62B
jLWcENaaD2QVxcgqXj+hn0D8Sf0kNdJP6acpy6y7jdCgqSxGU5l6p95JPgzOYRThbeBtgHCYdzgo
G73f0ijvQV89CvdN9k2mCN9U31SEK30rKcX3me8zau5b61uL+DrfOrrIt963nhr7tvu2U1PfQd8h
XD3uOwH6b77fQHF9LjU3EIRSHOlIaurEOR5q5XgdLw11Ak4ASCzFAfJw2jntELZ30nE1w+kInNbF
ORdpujrngdLD6YFwiDOEkp1hzjBqZtbRphbOSGckDXFGOaNAv8q5ipo4k53bcHW68yfQ73XuBWWW
MwuU2c5spP+z82dQDHrMch4CbsxyHnGAMoAeH0No0GN3IManES50ngEO/AdwYxYQ40vUmRFjV+cN
59/Uy3nfeR/0j5yPEa5yMCIDPX5O3ZwvnC+APDc4G6i3s93ZDvoB5wDCY84xlHnCOUHZzknnJPVw
fnZ+pl6MJLszkmzkv8B/AWUxbuzKuLEbI8ZujBgbMWLMYsSY5h/lH4X4aCDGDEaMmYwYO/uv8F+B
+FX+qyibceM4xo29/OP94ynRP8E/Ebkm+SdRuv8m/03UPbApsIWaB7YFtiHcF8ijVoFvAt8gPBY4
Ts0CJwMnqRlJf65ZvzthYvJ1QC218fVWzZyPQl9UVOddf2lrzKAlTxF7nqnuXPhb81fILnCZVN89
6u5wZ51+fb5SdRwuZXOU6m7m9897Cmq+mG3ws0PHifLfhJ95h5pV6Lc6LrWaFmyp1cpVc5f8+9Rc
8Up8lSzjtN9FuQcLVkYOWbW6B4r2xupZeJr+eZoUBRxl6ubfStmj1r5zbz0rtZSyInNn5K+CVu1V
MLaUvmvBZ1dgr51TdAW10Lp4yW6/0Pmsqq21hBwTkGOqyZ9fRn5JHC7J/4oF6YpYebljqlpP9V2V
LQYVpPaxkNVQ0AI43+JR5vfMClzVJUNqgU2UDB2+KpdRxFXami4VcneWm8xPaYs545bscVPJ524x
T65MWZFaXIbw+Mj/OWTRV1nnM/c5f2SmgrzBle1L2dNXrezSLj8/39kqfhta3jpwlXlKMpQq2bTA
PVTwjVyqOzXUlmWGE0p9O5ccKt9XRn+qRA8LrodZtKVnh9/Qb6biyP9yzQeOWeIW3j9fid/arftQ
0SfL/eo0lsru6gqvlhoHy3H1wTPLCu62OTt0urvtbiw/Relx8HSueqNFSI8tqKMS359cHPpNZXm+
1s3htceC3H/I2Ibjvy9wR+K3pLU7Pwn0Smm+c+HeOQAxvq9ufLGyy27roeK/teImnD4J6gtKDl8Z
fbZyvbh0H6y8fMZdrnKucttVuXGBn2ixEsrS6UuuKFnRjjWV+mLEPNfCOyVr+UmXV2sFfF1cIldt
3SKW6CuqK3MhSQxHme8sqqRLlPe9cKVrDY4YkmV2BSvTVaPsSsqx8iTZ6b7frtZ9Tg6O66dZKaIs
pFcj7Mf3eQnl3+daHZVPd5/zV4qElC4zpbur7HtR4/4c1GtlgTZUuXw168+V3gusth2ertH1zPpa
FWqtodHPPAke+0KrdDSk04yFlWrDWVtn7UzK6crLjSqWW6I/QxfPv1Lr/6ZwHKlZf660q4WZqYr1
4nJzLal2habN3YAHN7tfuDmhs/xSeZ26CmaCUqF7TzdaRjCkSn+1azCvW9/NR2Fb8jEXI+JZ7i3l
6UtIW+YXTKcqMy9W7OlUUUaVJztrhqbqB6VU8b11ynKhVRUq/G62Ci45H4ufZvztV4pWo6+ya8PV
oKdXr74FoZm9s11vSHaF6pV0PdvjkGwoG5Ew+1+TxVY5YbKVbEXhsrVsHbLQiZQdZCbVkZ1kV4qS
PWVPipUD5UCKk4PlYPLIEfJSsuUoOYq0vFxeTl55pbyKfHK8nEB+s/81xbP9ToK8Wd5MiXKynExJ
8nZ5OzWUd8qp1EjeLWdSUzlXzqMUOV/Op1ZmL2xKZRuf1nKhfJbayOfk89TO7IhN6WZHbMqQr8pX
6Rz5unydsuQy+TZ1kv+R/6Fz5YfyQ+oqP5If0XnyE7mKupl9sSmbrX56mH2xqafcKDfRBTJXbqHe
Znds6mt2x6b+co/cQ4NknvyWBstD8igNlb/IX2iEPCVdutTsjk2j2BpotNkdmy6z6llRNMZqYEXT
WLNHNo0ze2TTVZZjOTTeamI1owlWC6sFXau36+10nf5K76TrzU7HdKPZ6ZhuMjsd081mp2O6xex0
TJP1CW99+qPX602kOd5e3j/Qo95bvA/Qm9753kW0zvuWdzl97d3oE/SD2fVYNPJ1900UKWa/YzHU
97hvoRht9jsWV5v9jsV4s9+xmGD2OxY3mv2Oxc1mv2Nxm9nvWPzR7Hcsppr9jsUMs9+xmGv2Oxbz
nDpOjHjU7HQsnnK8TqL4u9njWOQ4zZzWYpHZ41i8ZvY4Fm+a3Y3Fu2Z3Y/GheSsrVpvdjcWnZndj
8bnZ3VisM/sai01mX2ORG9gU2Cz2m/eNIi9wNHBUHDTvG8V36JEbuUdKthCTshH6ZRj3yzrcLyX3
yzrcL6O4X9ZHv+yAPmrsx6TMRB8NQx/thDSdZRdcPVeei6td0WvbcK/N4F6byr22I1uaZcpL0Xfb
cN/N4L6byrZnmWx7Jtj2TMgJ6McW9+NI7seC+3Ek9+N63I9box/fSXXlXfKukJWakFPRsy307LuR
8h45A2lmopeHo5fPBQ/MQ1+P5b4ex33d5r7uY3u2aLZn88tn0e/bsVVbW/k8en88ev+LCI2FmwYP
LEb4MjjBx5wQy5wQB05YhtLeAj9o5od2zA8NmR8asf1bY7NbPHWQq8AbrZg3mjBvNGPeaAbe2EjN
2S4uhe3i0uUW8EkL8Ml2hF+CW5LBLTsQ7gTPNGOeacRWc43lN+CcluCcQyjze3kYXH1EHkHtxpou
hXkpBrx0itpLFxyVxBzlYY7yMkc1YPs6x4oCXyWwlV2aFQ3uCoC74hAaizsFHlMINTjNy5wWA05r
gnKagt8U81sC81sd8NtXCHeA6+oz16Uy16Uy10Uy10WC675DeAi815p5TzLvhYH3BlId7yDvIIry
DvYOp/reS8CNEcyNbZgbM8CNH1Cq90PwZEe2ncj0HgRnCsOZZJn9yCnS18fXl+qZXcmpte8S30S2
rJhC0vAqRYBX36V433u+90gbjqVYcOxysn0rfCso0feRbyXiq3yrkGa1bzWurvGtoWi2wfCzDUZb
33rfRlzd4tuCcKtvK9KDtxHf49tLcb59vv3k8x3wHQA9z5eHMg/6vgflsO8otfP94PsBKY/5jqHk
H30/Iv6T7yfEjRVHW99J30mKN3KB4iAXwijZCXfCqZkT4URQI7MnOnVw6jp1qZVTz2lATZxoJ5pa
ODFODK5CdlBztvRId3yOH3Rj79HQiXcSqLHZNx15IVNAb+Y0B72FkwJ6S6cVyk91UnG1tdMaJbdz
OoBibEJSIHGyUHInpxNydXY6I26sRNKdrk5XaglJ1JsCTh+nDymnr9OXGjj9nH5kdl4fQO2dgc5A
SnIGOUPI41zkXISUQ52huGosSRy2JElzRjmXgX6FcwXCcc445IL8QvwG5wbEb3RuRAmTndvJ6/zR
uZMSnLucu3B1ijMF5Ux1piI+zZmGuLE/SXPudu6mAOQd+CiwObCZfJB6+xDfH8ijZkb2UV3IvmOU
EPgxcJy8JEUkW/pmsKVvKlv6ZrClbyZb+p7Dlr4d2dI3iy19M9nS9xy29O3Ilr5ZbOmbwZa+bdnS
tz1b+rZjS990tvRty5a+7dnStx1b+qazpW9rtvRtw5a+rdnStw1b+rZmS982bMVbt5iMNtI5soh0
jmS5XIflcnhILhu73joshZvKbJkNWWBkcZrsLXtDahiJ3Jglcmc5VA6lLiyXO7BcbipHypFIb6Rz
mhwtRyP9ZXIM5I6R1I3lWDkO6Y287hCS11fLqyFzi0rtiXJiSHZHyOvk9YgHJfgN8kbEjRyPkLdA
jlssx5uwBA8rJsGnyz+F5HgEy/EmLMfD5KPyUWg6xhY5hmW3h2W3h2W3YtndgmV3c5kjczBiGand
gO2SG7BdsoftkmPYLlmxpG4hV0BGB1hGJ7CMbiVXQzoH5Bq5hhy5Vn6OuJHUCXKdXIe4sWBOYHmd
yPI6ieV1S5bXAblVbsXYsA1SO8BS2y+/gtQOyF2Q2gFI7b0IjcVzAsvuePkdpHaAJXWS/EH+gPhJ
yOtY+Zv8DaGR2ikWbgXFslV0tBVmhSNuZHecFQnZHcsW0nEswW2W4JoleDOW4LFWjBVD9axYyPFY
luP1LRtyPNbyQo7HQo77ERpb6vpsSx1nJVkNQTGSPZbtqqOtZpDvsSzfNdtYd2Ib67p6lB5FFn8h
FMlfCEWyfVsdvU/vo8aQ9d9QhD6oDyI0Ur6JPqKPIP0xfQzhcX2cLLaEk2wJJ9kSro73Cu8VFO6d
6IW8Zonf1Pug9xFqyHI/zbvYu5gaeV/2vk7J3qXe/8fet3DFcV3pnlM8jDHGuB90gTAmCsYylgkh
DCYKkQnGMsYYE0wIoyGYEEIwxljGmG4aAg3d9ejqV3XXo1+EEIbBCktSGJkQgjEmDFZkIitYwYQo
jIKxIjNEZhQtDdElinJ3lWet3HV/wb2zor2qqao+z7332ec7W/ucnoL7nyTOwL0yH+xX54NDie8k
rqAvqbPCF9SIOmVWeOy/Z4VodVaIUGeFz8Ks8CqKVOPtCDXeTpkbAjBP/MDwA/hU5oNENQJPp0bg
aVTrr1Otf4YagXe3YQXmgLtU65+oRuPdY/id4XfwRrH7iWpknka1+A+qFv8u1b5nqFF696hReho1
Sk+nRundA1NqBNiyO8g74FOx8op9vwvu7wYrnwRWPgHulUi+FNXK36da+YfAyhvgngRbb1DteyaZ
SqZCyvvJ+8HCppGfgfv9YPENaszfPtXKZ5JZ5OfgvRL/t0+N/0tRbX0q+Sj5KKTMB1ufrFr5h9RY
wBTyK+RXoLQisgjeK3GBKWQxWQz1HiGPwHtlDkhQrX8C+TT5NHwq1v8A2P1n4V6JIIwD618F90oc
4b2q9deq1v8BNY4wjqyFOSCWrCPrII0yEySoM8EB8lvkt+BeiTKMJ79NNsH9d2BuiCVbyVa4V2aI
A2Q7+SrcKzGI96ozhF6dIWJhhvguvFdmhQfUqMR4kiZpeKPEJt6rxiZq1djEeDUmT6PG5GnUmLwU
NSYvRY3Ju1eNybt3X/m+cpSAcORi5BLCsOLXKJt6vDxRI6QIZUKnsCpWwcWL54RccVtKlnKEXMkn
jUoTwo40K+wXCoVKoVNMFUvEdkg1AymKpQohV0gJpAXyAxWB5oAvMBVYCGwEI4P7g1mB2WBLsDMo
Bufg2gzuhaJDmlBmKDu4GuyBdGmBHMjTBnmuB2ODKcHCYGXwSHA4eOLTlMHOQEdwNVQkL8pL8rK8
Kq/Lm/KWfEPk5T0/8sfJY36NkChtyJt+Uqk/1BRqV+vfCPVC/Vkhm1J7iIe6s4JzgdFQdHAsNAIl
Hg+dElKk6/IJeUno9JcIJ/z1cqU85+f89SLvPwW9L5NXoccT/kv+y/5r/l3/rQAhJAbiA7pA8uB+
P/TbbxMvy3PioJALNZdC3XxoO+ALXQuMh+PDyeHDwRbgwaf1VoSiw1PhheBq+Hx4JXwlXB2+Gr4e
vhmoGIwdTAhdDgfCdHBP4Rd80xweCq6HJ4JieNafp0jCXyCf8Gf7o/3p/lThhJAoFomysBkMBVkp
H/rTAzQgZgqN4ogYLa6JnHhGOijlS1MgrWFhUSIEVilFGIbnTtEklYqXhTqQ2llhT+gR08VLkGpH
RFKacEA6LM1KAeGYsCzGSRuB4kBpkA00BKoDHQFzwBIYCo4FRoG35wMrwcRgQvBQ8Jgq2dPBpeCN
UJ7CXaD0UGowBVJNBKZCBQFnsDHoDpwNigE6cDu4HBgPssFp+NYXyAjUBstCcYGLgcMhMnAwEAge
CK4Hd4I9oZJQeagqdDRwNYSCNcG64GJwK3AlmAu5GgKzgZvQPrfa5nQxW2yCvg2K23KLlCO1SbRk
kYaEStCMTOBWprwD9VYEGkD+lSD31pAcmglxofnQmdCgvBqqD5lCk/6mQIy0MpgymOgvF0Ab/HH+
dj/vH/FP+o8LlfKq5BN2/Bf852S3f9tfBNQKWiL760ErOBgLbqFSHAQtKvSvySF/lf+ov9c/6J/3
nxGG/aawbjAyuBlaC10I7YZuhdPCB8M54fxwbbgtbAl3BCrCPkV64bPh8fDF8Eb4dtgcNgcjwxnh
4sBG4Ep4JcQFcoDnoAuhc6FLMGJWgzeCJ8JEOCZcEW4IO8OjgdFwqZAFo++QUCMMCCLox2lhWkwX
1uUEGL8aeb/YKh4VbXKZXCddlOIlnXhNvCXFCJugATFSrTQuh0DmCzCmW6TrwpicKKeI5fIhqVlq
EEmRlK5IV4Ujwn7ppnRbjpRjhTmxQM6Sc+VC+QiMlxpxVzwlHhcnxXl5GKwBL0zLx+ROuUceEE9J
HbJbFoU5eUxaAQ6dllm5UZ6W5ySzWC/2Qq5dAEEZUrV0XtgSbsgHxDzxgsxKTmFTtUDnVOvjkyZU
q5MLlmkYehcC6ecKS/5TwSywW1j7JVj5j6p7RxGigLB6qgqh7hqNQB40iCLRGHodrNxJIB2aBtKr
uy4T1T2WBvQBEIkuASWpp5gko4+B9qE/AKWgT4DuQ38CSlV3PN6Po/H9KA0/hDPRIZyNs1GBurfw
y/hL+EvosLpv8DF1l2AhfhY/i4rwV3Elehw/j59HT6hnhBzBzbgZPYlbcSsqwZ24Ez2FB7ANleKT
+CR6RsW65UQhUYieVRFvhYp4vwqItwRVEqXE06gKcG8VqiaAUJ2KeJ8HBNuN6tW1uglw4C9QF6zM
V5EFEN0m4ojLgNYkQGsfI1ldVwdUhBYi/ovYRWHiZgRC3wPwbkBjEUkRKWg24n7ATvMRn4n4DPoZ
YKcMtBBxIOJh9E5UVFQ0ejcqJioG/SIqNioWnYuKi4pD70XdG6VF56MSowzo/eid6B30q7vi7opD
K5pfaX6FPtD8VvNbtKrFWox+rb1Teyda0+q0evQbbbL2PvRbdW/S79RdSRu6A7qH0IfqSQkf6bJ1
n0e/131B9yj6WD3/4Kq6j+gTXamuFO3ovqH7BvpPdefPNXXPzx91LboX0XXdS7p2dEPXoTOiPZ1Z
Z0a3dW/o3kB/1b2vu4CR7gPdXzCh7D/BDyv7T/BBZW8JfkTZT4KzlJ0k+HPKHhKcrU/SJ+HPK7vt
cY7+If3D+AvKbhCcp/+C/nH8qL5GX4NL9J36TvyU3qsP4VL9oH4QV+mH9T/AX9OP6kfx1/Vj+tdx
jf6H+pP4qH5C/2P8vP4j/cf424And3ALYMg/4WOJ30/8PjbCwojAJsODhgdxl+FFw4vYDAjqLtwN
eCkJ25QVL/YCFvosFmCV+yAOwir3IRwiHyEfwWHAPJ/Hg8rKFn8P1rQFeIh8jPwm/gHgjWa8SL5I
voiXyJfIl/AvyFfIV/A58jXyNfyesubE52G1GcC/JMNkGG+T3ydH8R/IMXIM/5E8Tp7E18kJcgLf
JN8gJ/H/IqfIn+I/k2+Rb+G/km+TCwQiF8l3iEhl1zsRTS6Ty8Qd5Cq5S8SQN8k/Ew+Rf0mKIB5R
9icQuUlPJj1L/EPSV5O+ShxOei7p68Rjyg4EojipLqmBeCKpMamZKE1qSXqJeDbp5aSXieeSXklq
J6r2PbOvHLQbE5WwblNQyn4UhRC7/X9f2CC0CzZBFo4L54RdkRDTxFKxWWwTzeK4c1q8KN4WL0qJ
0gGXLB1yRUuVUo1UJ7VAnl7Ic0o4Jx4Uq8UGSO0ULeKG2MCZpCzpkDgF3w1KrFK2NCyNCeekFjFN
WoSy2wSTUrJzP5Q9JN4WLkPJ69IWlLsj3ZDc0glpzj3lqpI25WjIzQk2OVsuEc7J5cIluUlu5yA3
tPHTvLJLltfkbalGGPTH+JP9af4M/0F/jv+wnOcvlYvkGfkUpIf+yJwsy/N+Qr4gbsiXob5lOVPY
lVPldHFDuCVekQpdsrvD3SGeF3iBkwaEEWFQOOU6I0wKF8SrwhpwJl7UibViBXBmAviyIV6XYqX9
UqfSfpcMJZRJjdIxYVu4JvUIM8I8tK9ZnBUXxBjxovp8WMx3FAuXxBXxJvDvHPRtUKSlXDEZ6jsi
mICTbVKClCLVQe98YkCKlBLFDLED0o6IOcIZcVQ8C5/Fgixr5DiZlJakVUmUTkt7UkialpHc6s+X
j8sFcp5cBZxqlXtlk2yDEiqkMnkEck1KdfIl+Zp8zh/v1wEnB+VBsVRucmzITWKaP0bmhV5/sbAt
brjioJRb8q6/wl8tH5XruXmxQ4yRzwhrwMshmBmw9iHtI+r/YTwJc8N9cPcgOgBWPwsoBWUD3Ye+
CJSKHgO6H5Wgp1AaegZoP3oWVaDPom8APaCeBZaBmoAeRC1AB1AH0EPIggZQJj6BT6BHiBTiUZRF
fJE4hEpVf3IZ4SH8YOODxCmw3xPEG6iVmCKm0DFimphGr8Ca/i3UTrxNLKDXoiKiIlBX1B1RdyBz
1J1Rd6LuqLui7kI9UXdH3Y2+G3VP1D2oN0ofpUd9UY9HPY4smn/R/Avq15zUnEQD6s5Zq9agTUI2
bYvWixjt97TfQz/SDmuH0YT2n7Wj6F+1Y9rj6A31fJ8p7bR2Bv1EPcdnRrugPY/e1H6k/Qid1Rl0
96N3dbd1t9EF5fg19Cs9oSfQih7+oQ/0pJ5Eq7BuvoR+rf9Qv4l+q66A/z3x84mfR5fUte/v1PXo
hsFj8KAP1fXopuFtw2/QR4bfGjbQbcNHho9wpOH3ht/jKMN/GP4DRxs+MXyC71A8ijjGsEsS+M59
ZfvKcCJYgiNEuWoJEpUYEtuGcmEDFyvU2UcBE7DMulDHzvBlfIuwxKx7RoUtUQP4UMMtejMBMZeI
VYCD6tl0sYmLZTX2Ua4GcPEYXyYsMuuOKg6wkpjKbCophS2uRiwQ25WyPQ3MDYEVm9gZUQNpl1ik
ljwC5SaI2b7zYhET8m4DnpkUZ0QTYG9elAHZwPoBcrcIdcyWuAb1TAtucVtBXp5RpSQlr31ULALs
0yDWc26pQzIDWSSa2XNkAwJaFC9I+Ww6s6n0B1BbsnRYWJYqRI1Uy4REDd3ArHOFXJmoYdYBpZVD
qxFg/zihUWhh9uyjau86hRZHnqgR3ApnhBCfpbRf2FT5ki4i+3lmU2m/WMQdAloEvmQJotjKTAs9
wqqwLuwIN+wrUIPyPC2cFvOgD9FiJiBulou1j0LNRbRZqBNLWCSwfIu9mVtk09kZ+237bTGbWwS0
tiw2gWxOCAPAsz1Ap3NKyxQCxJ4p9gp74rxos2eIZ8RtZk/MBl5VwWrEDZhyBng1CSuWNED1BxVO
QcnpgElLxTypg+sB1JjBl3GbkO4WpOrgVlkNcDULWrvFbEltYj2zx0WKl+23AePq7BapWHBLBAer
XkRoH4bR//ex///V2I9uvGNVGfv4NHoBIcvlv1//b19EjWeP1/S3DpTy846VgWrqPM9bb/BHvTkD
OQP5Xqc3wLd7RyFNNK/h07n2fo5fG6jmdyHFYW/pQA5/iVrxjTGDvjnfum9PiLYvCnlCiVAuHAWk
YWNm2Apmhs4FjDbD5AnRwjwglBG6EvIMM4PwuS5kQvoi4ahvi4ljZgATfZrSRq0II2yp2+fbTzl5
3nfA22xZopwD1b4sTyx/yUb6cu1LHtGW6lLrF86wGb51utK+yJRDeeVsvlK7cA1K3GUrfFtKrcIt
+DQxJZ69fs6X6J7ob/VV8gXe61B6ijvfsjNQPeCE3mts2dDjgLfNxw5keH39vM9tWfKJvpBvfz9y
5fFHqWIq0D9i4waKoeYTvjExhm3wrYtp9kLmAmCvasEErVDrZQahxjgxIMwAphpXMdpZ8bw4RHeK
K/ZFwGOtogX6C/xiegHt0cIu9H2GWfMd8VoGqm2pA6XWI779rl3fIesxyxJ/it/2NgutDOfNEWbs
J+wnmAKunU/tP8rbrCFo+S33bW8ONesd5ev5Kr6AzxwoHaj2DsFzujXXW+x2WpZBakO8yXOIn+R5
L8G3873eDB55872jXto6Zz3Ecx6RveI7IZzzTftOQ/8WfUu+TYbzjYFsNQIpFEBrqwCRg2TtlYBc
j/t2VO7OMDJj8m3SlfB8QzjjW1URNUjUtyxkU1fthVCW8u06tQJcqYccqcwgk0dtMGvQ+wKQ2ohw
QVhj24RLoEGTQpPQKsigN+kMaItvWkB0pHXOs2dthDYP8iP8BceKjQM9bQI9rfVarIXWSr7cE+sr
BG4V2mTg4qBvWrmg3Mv2I3QkrAUI3xZbwfNsBmDncl8jcKrNrRM3fDV8wUC19YitwHfM12ObtM18
qgNA275K70Ve4yvzlfGXfClW1rLjY935fDSMh3KbokU6W5U34Kvrb/e1+Dp50jdgbbSZxHxxnK1Q
cXyGvVAsFksFUqwQ0tkNplzsULViBLD2EKDvCXGKkWFNYwa+7oq1bKmQLo7TO75h+xHfDjMjxgN/
gLtQ2kVY/+TA+qeZzRCdoPHttnLqvGOFJx0+PhukXWSb5CddeTAqVkG2s9YU/gx/uX/Eu+Kd8KYN
jHtjvPHeZG8zf9Rm81Z7fb5IkPk4Xz6QAyNa452y7PAz8KbBW8vLvGwNuUv5OGulLd2VB+Wl8yWO
Yu+CtbI/z3vWe961a92hAvw1t4+P88XCuKn2XvResWV7r3rbgDq8N7237Vu+BBhDibamAad3w93h
S/Ga+XNuny0OxpzOe9BbwefxrdD2Qf6465r3OpTVpFgg6rxifdwrMALB6oBWp4PMC/g86xzYmqMD
TmEXEMGX8QSeQAhP4kmE8TSeRgSexbMoAv8M/wxF4nfwOygKv4vfRdH4PfweugO/j99HMfgD/AG6
E/8G/wbF4g28ge4iaIJGcQRLsOjuiKyILBQf+Xrk6+ieyB9G/gglRE5GTiJD5ErkRURGrkeuo/sj
NyI3UVrklcgt9NnITyI/QRmRN2Cx+6DmNc1rKFdj1BjRP2i6NF0oT9Ot6UaPar6r+S7K1/Rp+tAX
Nf2afnRIY9VY0Zc0lIZCBdrHtI+hL2uf0z6HDmu/pv0aekxbo61Bhdqj2qPoK9pabS0q0tZp69Dj
2nptPSrWNmgb0BPaRm0jOqL9jvY76En9T/U/RSX6N/Vvoqf0b+nfQqX6t/Vvo6f1P9P/DJXp/03/
b+gZ/Tv6d1C5/uf6n6Nn9e/q30MV+l/qL6KvJc8lz6FvJs8nz6OG5IXkBfSt5MXkRdSYfCb5DPp2
8tnks6hp3+f2ZaPv/N1v93e/3d/9dv9T/XbRLdHtf1utv5ajXBEPccuWFVuNZcWBHBoz7ci2jPe7
+2842h29tkaLxXG875bxoDXGccrodMw45tl0c3x3C7wvsExBqvq+a7ZGB2eNgTcjrmXHmf4ex5o5
2dHq1jhu9Q87451p7qPudlOhe8Q97yjpWnMSRp2HcJCeeGOao5dac6w5bhkDzhh3uTOj75pT1+2G
tLxjmxnrSnVWuBqNFZ4MS4On2HzTlMXXuc/xByyz1hV+wJPhqOKH+bHuOrOFvmhK5E/wp6l06jJ/
xLNgS3AtWmb5Tv6YJ4N3my2eBcsEnUHnc8t9tyzn2XTTojnekU1blJ46p5wTjl5TJ21xLtBD3dPW
GOOVgQLHvPWw87zTZ6adE92xfbvmK86LbpPzKnXL42Na6Hxnbd9kV2rfNU/A2UEN0rdNhQ7kGWfb
u7K7bJ4J53XPlPO2Z1ZpveWmecJTPHCJr7MNcOv8AWpQab0pEVq2aGkw6syWvknbfmh7L7/ELdN0
3y1XomnRdcB82JU7kOk6BK3L/rRtthpXp4u1HrZ2mEIu0dpm7ehqd4XMN7vSHXmuMdd+Vw8Vx6Za
xl1HXDWuAUccbWHTXcudk8aAZcqczBZ0rXmueK5Sg3wkH2sq9DjdI/095mSPzjXtIPkDfJYpgenp
KudzHVVsJn+IL2TGbNNdx/uHPbf5RMctc765w5LPLLkaLbXGCnrIU0wv8OvcKn+MaoIe1XkyvMjS
YEoxW7wkc5o/7W73ZnqzO2e8ed4C45C3xEn0u43FtLm7jlvvj7TFeuOMHZAn1dFK15orjFecNz3n
jWbPqOW8Z8W54Yp0XnHFes6aLVRm95hpzEF2TtoSqTP0St+u6YA1zbPQP2eZpdK5dcdI13HQXgsd
z2317doau1nQ4fSuo4psHSbQTZ5ZsqzQo4pkHZPmDGYTZB/tiLNNczvcDcsQ6L2t+7QjVX2qdpQ4
Bs2HHTK3bKtxHIUcmTTtOMWtmqbZdEe2o8nRZJp25DmquE1HkeMM0AUmkd5w94L+zjjjQX873IPO
UrbXWOtJNqa547pr+jedh+lZ1w23pn/Tk8ZUOg92H3CfYQbohi7efc6jo1fc2U6Lbcwy4aShPBgN
XWt9267l/kPOZPct145j0p1H9dKlllp+2phjrvAssMiUwFfS560bTCVfY3IrY4LvAX0S2VZHifmi
+5a5g6kxpVCXqctdp7p4cwxfxu31H3K08qytUPFecXt8o6OcD9HFjmhXo+20aQzG0E3g0kWP0zJF
pbsWrVcdI05Ld51p2tjsqoS6W4w5tkrg1TnXDjXouERtu/Yc1xy77nQY9WXONseIu8nc4anltsz5
3cco5Ea2GkUuXceds86znnHPgjIKPUOuBE+GJ8OYo1x9kzCmO7sHTDX8MnAu4Bx1rDlr6XF+Dsbe
kHPcuWK+aZl1pbiyLEP9B5wb9JCrzjLlaunaBbK5xL5roIvjrjLHue4W17Ajmra43K4TrtPG665C
V6XrGLfVzYI8W90XLCtskee6a9G1yC3RbeZRd7o7nc5h5lxznovA9V5q243MHfx+esq15Nnw3OQT
zMl8imvPtW6Z8EZbxvlVftO16C6n44ETN7q2wc6kGw+6Vr1F/B6M6SPmob4LoMvpth1vufkKv8Xv
0LVejXWDTnOtutZpwnjQPNu1Zlrqm3STdIXnoLvASTBjluvOHHcrPe6p9uQ4m81D5oPuC8YKptLT
5l7zxDjNHrM72nzW2WYac205ncYAswpWo9RdZVlxVjtrlW8clwcKurPcl5z5zgzbOpXqLvLkmxJc
m2Bz4t15likYo9fdJU4LTXsqHK0ggcNum9Hp5twyc8NUaIIR7mnwNHeVs3Huy+5tZzG17enwWOhk
s0+xrh4abESerY4adF9zXKAG+665690m9ykYV0VsL9vqTnVnOhtoemDQfZy+6N516tyT9BDYZ+X/
hojINyNnYZb5NSBGZf9KPOC+O9EBoCTVo5es+vL2oaeAUlRf3n2qLy9V9eWlqb68z6hevP2oHznQ
Z5ELSSgL+QGDPgoI9HX0ZXQK/QgdRnNAhYBAz6KvqBj0cfXXMIrRL9EyekLFo0+qeLRExaNPqSft
luJIHI/KcAKgz6/jTECf31FxZ7OKOF/ATwPibFER54sq4mxVEWebijhfVrHmMWwFlPkKPgEo81XV
q/ia6lX0EgWAMgVAmU8DInyGqEAjRCVgyjEVU54kPIQPvUOIhB+9q/oc31N9jh+pPsePVW/jFjFP
nEF/IM4C7rwOuHMT7SqIE8cpiBPfTWwT2/gewJ1/xAnEDeLPWEv8JQLhfYA478b3R9wTYcAPK7gT
5yq4E+criBN/MeKhiIdxQcRyxDJ+LApHReHCqDuiYvATUXdF3YufjNJGaXF5lD7KgJ9VfJe4UsGd
+DnFg4mrFA8m/pqCPnG1gj7x1xX0iWsU9In/EXBnMj6qTdGm4H9STv/EtdoWbQf+hrZT242btd/V
WnGbltJ68WuKxxMPKL5ObFV8nZhSfJ2YVX67ANu1C9p3Mad9T3se+xRfJxZ1Bl0SlnT7dCk4oEvV
PYBDgGgP4hFdli4bv67L0eXicV2e7hA+qSBafFpBtPgN5eRKPKkgWvxjXb2uHk8pZ03inyjnS+Jp
3Su6dvym8stE+C1dl64Xv62z6Cz4HZ1NZ8NndLBcxT9XMC4+q1vWvY/fVU5gxL/Qrep+j9/Tfay7
iv9dt6O7gT/S7eoJvK3i3T8pp8Xjm4B0k/CeinH/opwEj28Duj2E/6o/rH+cuENBt8TdgG4FIl4v
6WXiXn1AP0ho9UP6HxKkcoofka4/qT9JPKD/V/2PiQzFh0s8rP9Qv0N8DtDtfxFfVmIaiSLFn0s8
rvhziWLFn0s8oaBe4oiCeoknFdRLlCiol3hK8fMSpYqfl3ha8fMSZYZ5wwLxjBJ5SFQYfm54j/iq
YdnwPlGjRBsSRw0fGH5N/JMScU7UGS4ZLhHPGzYMG0S94hEmvql4hIkGxSNMfEvxCBONhpuGPxPf
NvyFxMQLgLCjiTYlqpBoV6LGiVeVeHHCSN5L3kuYSB2pJ7qUSEKim0wi9xE9ZDqZTvQp+JuwKPib
6FfwNzGg4G/CShaQjxE28ivkEwSr7EQhXEq8H+Ely8nnCJ8S40cEyBryH4mgEt1HhMlvkM8Tg0pc
H/F9BaMTwwpGJ36gYHRiRMHoxD+TFtJKjJIUaSeOkw5SIE6SEhkkpgCvDxJvkkPk94m3yBHydeJt
8ofkCeIdQOpTxLvkTwGdvwfofIn4NXkO0PklFZ1vkBfIVeJDco38kLhCfgTo/Bqg87KIe5PKk56N
2Afo/OsR9ylnwEekK6f4RTywr2xfOaz7MHIi8W/4+4XT6nW3+rtImWAT88CaFaMyVImOonrUjNoQ
QbX056MIqpEapqbhqbY1Dj6rqVl4V9GXQ43DUwk1A09FVC/8JV6opQ6hiBeqqVzqGHx3kArAdxlU
A0XDUyrVCk8kVQV//2ahsXoeNUI4cjlyQ21dqnI64Au6//MianoSqE7zPDVN3aBijSTVSBd17r3c
QNd3L1BL9KRpiFoy7kKaFiVVN20kXz5oJOk4SNFO93YvmGXmLHORuc5GsvvZQvYI28j2sG5WZIfZ
OXaJ3bLH2dPt2fY8e5G9hDlvr7c32VvtJsizAnliIU8LpGch9Ql2jN1i9z5NCTlj7al2nsmw7r54
9LWzNou1yDTLQM1MTmdi/2FTdfcGc5g+05XIFCv12yftM+x+uwlq34LyRPsZpXb7BXhassexh6DM
OPtlqHvbfq0ngV7rvUnFmueZBmqMaXtx+9VhhqYvQ9lpII9OZpRaMg0xFUbSwlm43glm1nqri2UW
jKR5pIt9uYGxMD4mjU5lJqDmq8xFLp7Tsfu5ZDaXy+EOc7VQc+On9TLX7UXcLHfW3sRdZEVuA+gK
d9XOcTe5245Iex43xGbZ8xR+cW2cmRtll7gpdotbYKrbto1kf3VrMVPB5LemMaVMqZHsG6ZJmmN3
7OV0vb2IXWZX2eVumhqg06lVuuBlgs4zT9JN9Ixxt7+0NYM6QbmpaSPZdcC4a56nNbSJLqF6Xm4w
7nafNc+3jtJFLy1TS9QyXQX8aDXu0qdaq6nT1Dp9hrnCQBuZ28xNkE8Cc5U9wN5gs0C2lWwNO6Bw
l11UJYvsGpBRr8rdIvtRe5W9HSSQy+babWwKO81usmXAh0S2007C23V7NHy7H3h2nR2G9tcxG4pG
gAa47ZmgIa122T5oH7EfZxvtBexp9jRILBs4GQJtuQ21H4P2iVSIWmodtSA6moqlUzv3GIKu712g
R+hBaqm/tDOxNU2hrgR2i7kOPYALpF9oX7Pfsp/jCC7Gfum1s/ZT9nn7LtMBeRqp0yaz7Sw1Rm2a
eVtzfzMTYIbogk91AEhkxm1Xu6uZWqaWin11+EVe1RIaxoLYX0qnghadZqZMQy+lMM2MmXF29XQd
oUI9sVy+nbPHcfH2GS4NtKKYqwC9qGYbQZ18HK1oBfS2lTvPTYCmktx1zsk52R6ulGvgKqDHIjvH
rADPc0EX4oFWQG85RyyXwR3kmrkOLsCNs1ncYarOepxqfJHrSehLpMZapl8+3DpKzVHDZhu1abPQ
cdSe2da3Tu/S88b5rvWXEs2Z3cUm88sN3edb2+hJqse421XTX0qx9Bo1TF+iL5vM9Ha/jrZRW9QW
fY6+QB2zrXTth3EyY52kTvRl2YiuZUgRT1+jC9psdOZAGZVFZ/deN5JgD24xMUx817G2beARb91l
/jd73x/VVnbn956QKUsIy2KZyF6WsCzrEEIISwnDEMJgDcMwIMseLCRZtmUkPcm2DE9Pb7B+vN8/
JJmlLsuhLMsQQijrOBzqKsTLUEoppYRDOYTjZYnjUOIQSghLKIdQQhnCsrT33d1mmvY05/SP7Tnp
Gd/zJK707nv3x/d77+fz0X1fawKzof5QCnf08MLDTHmEt7zXH+2KIlIdfTVqaLJFrdFGkYqMiZWN
VGQ33E2XRAcjM8oMFMGU2UfxQGXWkQfBzNQTecKPNZro6VDnw8yWeSWahXpX/TMEUf8X9T6MbfGx
svmxsvmxsvn/pbKZMPFbmRC7TCOfR5AGy2/aEXeCG11hfAnvwnqc3Y5cZ/R+tpTmz3EM0lelfOLY
PinpMf39wybJFe/Na9pynZB9zlFxOLAqTjN6cQ0npUQpxTHozvT2EceBDMnfJEltUhGj9+IE5ugi
/O5C++KDzbDg0zVekDOkTn+PL7uxxDEeXpMRzEJMBu+CsxYpxPMs3EEmhPPYsnBJU4+7MGzy6eRU
z0tZC8r0ezz+Nl9Z+IXPGkmx15GZkSynSuqRk5zdstG3gFtdWmwd4I9cMkoU+ZKiRnDNHu8RXkyU
+p9EW70lpArb9eaR5eQQWWmvImyRgyhYpR0bsjZgjVZHDUSPva0pLRqkd6ID2K5kizY4NuxVLium
V/rHMULWgP4ZdUaJ4/vZ/hzfktI7jj3iGHtln8SOmySiqHHUddI0ho+AT9PkoCvcuBZaZGz4odxK
+CMe34YrSW6PEM5TrIXO9C0QLREGfNLlGCc7wmt4QziP7PbkR1rkRskvD+A6pU1Ejys3qiVsRBF+
4ktydEW1Sosc7USpY8r/xN6G7Tp68V6y0ntkPwa1nHKFyZvyLNYTGHAMeEe5BM5EX1VqrNQRX2qS
HNtNY2D8nrPbTVtNu95mIg2U2g5fYLftpd5mb9RepYy9vO197JsNJ3vziGPfEoGRNQ8E13Kkx75I
jhL9pIk4IPtc8fY6x7hjL7xG+LHOcEc40/PMMWifdLT6Dh0N5D7WGdklT+27TWnhi009xKQy8mCM
TtyZkXXsGbYbbMZ2fQvObtxKdoO1Xesro02uQ2bXMeU9Ior+rn1gRHcxxvucrMSe+HT0Y3pIPqEf
EUwQJ/JB3WaIHJ+OVCljzexiHu/zh8nYLlH6UPVgk3gZ6ieK5F5ySB6xH4Sfy+FIp2Mk7JA5eZCs
kWPOoYhkL5IziGN3pt1D+O354SEmHev3GXwLvg1vocRE0qKD9gOpwn7gHIq68ZNw3/1iccI1Rb6w
t+FLjN5vIzuIUqkOLxZ3HLnifqBLsQonpXiMZCFSJMJepViFJPnzHdvkTefoA+FB1FctPhdfSOlS
Fj4rlQa2Jb2SDwxIasnmGJCq/ClSp7gijopzjkGp5cFjLM0V71sSN6U0CXvQTfaJp9g8Nu8Ylzzi
kV3vfOyIefscXSDFk5v4CfCTSWmS2Ao/kjo9HqJFehpekQ0Aq6Q588Im4FlUGCf6pWeyzn9AtIWF
8HPpWaRU6vctRPThq3JxeCKS4xoI70v94eaIhXgVvilnh4dlxOcOd0jHDyrD3f4KrO5+bgBxdLkL
gW8m+YIeLFwYSW/qcbRHqhwxrM7ZR+x6jygwso4RYsyT79jwzbpOHgi+atwaLbDvRotDVYol+4F/
EaVRjsiJ9rqMiiVHY74lbJ5oA9be4xgAdp8azItapZxoYzATmwdcDuQDgzQeDfuCkXVwpfFoRuQ4
mkRg0REf6QKsz74YzY4ao+34ib0qWI5Z/On3R6JlwWaizbdx/zDaRWR5C6NTxJgrKaoDXlgnPSVr
8BPC5pwD4Cw+3OFP9yG+ePBaHJ7GdsNHxLw0Ly1G0hxTvg2p02cI38WXlNG3t/lmnaPhtUibvSjS
Ft6UR4hSlxZcFxzAH4POIYcWML/j6IL/iWPcrmeqIn5XLkCLu7jV+9irkZdxI8E4BuWpwKC8gLeT
wM/wQfHIuyOfMADFSpKvWumvcALZwW6zrYFVwDGz5dXgBXkP7w1r8MEA+PuBQBzL4/K4OI0fYnrH
qv+JvBS84Ariqz4jXixvRJ4STGTm4cWHmeREBNTDOUQcyCcYQa558l0ZCrOKvIy8dPZRXWQ58JsD
cFa/nAQY1iRg2ltkRwBhywhb+C62CxByXuSV5xm5Any20fnCXkSuEAy56ZwLz3kT7JP+JyF/dIlZ
j25gBAb+gRkny3+AtWA90ZNozF4FZtvFKBKxgVYt0c3RQ19SZD3UH92LPH0I+iKKgJr1AFtYiC4/
TCAryRqq2D6GpYT6fUZyxTkH7GYbe+YubCwJl98/JDqJfgLMDOHhcNSTjzcA61wC45h5v1EuE6cd
reHR8BzwhhJSIzf6wpglkhg+BXVec7SHm6WX0quIWlqXtiL5hMdnCB1EKiJ14bsunX8LWHtlIB70
qd+3YK+Tc2UDmSBb5XjlO9+eNEZfdQ2KO3KDb0qaIU3eZJkkyyW9pLdXMUUEIXWC1u5GbEQL8TT8
OII5R+09ZB5ZiFuxOtcJGI9DgiBxMF+OkwkEY88nr/qWQFqWqwmbt9ujB616BmbafsLm2PM68GWy
z7cKWlEDbLEAPwxvEv20ydfuXCN6gJ/qZDew0yTZSprwQ6lHeipNhh/JBdK8Lzs8Hd4JH4GW7oav
RooiFWSzu1B6EjbdXw47iB45NVwjHTi6ws3YK8eeYwpwkBT0FfoKQdAfoT9CUPWw+i8AcxlVjyPx
6kn1PPIJ9aL6u4hW/QP1D5B09Q/VP0J+T/1j9QaSqf6pegfJAhxnF7mY+jD1IfKZs18+W47knDWf
NSO5Z91n3cjnzt47ew/JA/fo/QfaWduL5ELe9DZgTd8EpRXepIea/GVkFplDDJA9vQs1+TqoyV+D
TKoeMikTZFJmyKQsyE8Bk7oOmdRNyKRuASb1acQGORQNORQLORQHORQPOZQAOZQIOZQMOVQYcqgo
5FAPIYdqgRzqjyGHaoUc6p9A3b4N6vbtULd/qioD/CgG+dF34J7gH0N9fkfR51GVos+j8cqeYPQf
KSo9mqD6d6rvoJ9Q9HlUC3jTX6P5UJkvVO2odtB/DPX5ItXP4xD0NYUxoW9BTf4G1ORvK4wJbYDK
vF1hTCgGlfm7Z9Azn0LvQQVegAq8qPAjVII6vAx1+DDU4SNQh49CHf4h1OFbzp49ew7947OfOpuB
PlJ2GKOdUG+fUHYYo/8Wqu6TUHWfgqr7t5UdxuiMssMY/Q/KDmN0Dqru39N8SlOKvoSK+jFU1P9G
YVLoCdTV/xbq6qea2xo7+t8UPqVSae5pOFWcoqKrzisquuqCoqKrflfTqelUpSusSvV7msVzKlWG
wqFU7yocSlWnaOaqa4pmrqpX2JPKorAn1XWFPaluKuxJdUthTyocKudewJ4+UBFQFf9TqIq/rzAj
1TegHh6Devg3oR4+DPXwb0E9/BnUw/8C6uEjUA//AOrho1AP/1fKvmfVmLLvWfVdqHL/R6hyr0CV
+wdQ5X6l7HtW/fBTh9p01SrgVtlxZxRuFZekcKu4TyrcKi5Z4VZxv61wq7gUwK3scb+jsKq41xVW
FfeGwqriKhRWFXdJYVVxOoVVxb2p5c7HxVUC7nMlbh6wHjLu+1Al/gWCoiVo70dc5tqj37jj1yra
eDdVg8ThHfU68K7CW+tLwWuYMoDPOEKiykDOfz8d5AjTAb6FqO7OUeUg5zBtgncVbqVyQc5Yr6a0
IKd3joBclWke7/l/NI/+Ui0/s3vm6KNn4N7d/F8P1U9oKdR+vzk0SI/dO2C0oW1btaeASqAymcZb
iZiBmQLHMqthM2+p2WY2ynaw3VgxLdE995vvFb23TY+F9mzVoEwj00BdpMopE4YwXcwIqwkt3Upk
89iSW+o7e57VUBc/yE/xy/y2kCCUCJWCSWgWHgndwmNhTngh7IvpwpBYIdaJFtEjtohtYqfYIz4B
ZcZBmT1QxgHOj4KzR4Uh4UhMBGfaRI/wgt8Ti8QZWxm1Tx1xHlrNEY2LTVo6kU7Bxjk/nc5JXBud
xXXeI5R6NC5is84qrofO4frpIk65/pS4Lu4KCeITwSQeg3t0S4hSIylJ2Je0oFYXRYuUIWWLnVKu
VADarZef25boTnqMe0XvcgfccT3Jp/JazHDLwkzdbzZNs910HdtxK5FvNI5h2XyQ5/gw38738gP1
DbSFL2Y1Sg/bevnc0F5TA21jwryRxkBNlvgpySoFhQSJEzKlXmlQWgA1Mf1dPfhl0SKXyyaxU74r
N8tR+ZFokzvkbnlIHpUnJFLOlDVindKn0oZ0KF+UcblEOJKv3jugTuk0Op+b5xiu89oRt0iX0hXc
jLHils1TwD3lxmimsZPhGiuEU5FgM0WLsALSmq36ZneoS0lN2ve2md57B8A6dMwSlUyVUEOe1Yb5
UO/tSjaTotg+dvjaGhPPToRGPI1YOz3PgN4IjbCPQzFqGNjKGJV3L4ctpB7ZM+inrAYrYIrpSUrF
WIFlrbLdnmVqlCmjXlAr1Bq1Gep6b7sJWCGroa7SLezF0CF1AStmKU8Gk8pUsy/4BX5JnOQ3FKvg
D/kTQSOqhQvQomoEQaCART0H9nQkpog5ol58powfSJLIiP3iUyFPKBTHBBWwpB0uTdgHf+FivpAp
bIppwAIS+Bi/KgyLmHCVnxX9/IiQLHSIpWIVsMV5cVF8CcqZQC9PCNNillgh3BT6gI1uCOXC3VCv
JyM0aI81WelFet1R6T1gckMnjKGplap0YrcSmTCzzGXdpYBPZLKmxs7GRVZwrN1SWwq4Z9wk10JX
CUegTRtSmaSTMsQtKVWqluIlg2Tkl5u04ivxQCrmDvjWW4nyivyCW6d3eYTapD18Ep/B4lwnX6DY
Hl/NG3irY4UneTK0zb3kXvLx1/YZI6/lG/lUmqB7+C7HGhO2LckrfAPvBl7v57a43VtVfDZfxuvo
9bvJ0oD8WE6W3GKLFJZapZg0Lk1Js8JN0S8nSCfQDivlGvmmXChTsiD3ySpZJTRLI9KStC3clJul
eH5cHgY9fSQ1SI3AXh3ytDwntUtd0qq0J1+Q84QL0jLd1mQAXvSEnqFf0rv0AX3MWJs4dp+da9Le
egn81EDVUIXUzfpY4xNbtbHoVj/7nIqyCRTOJjMbzB5zwhWBOWY5tMqqbr2838xWso+oaU4PbGXI
sUZ13N+kHtPPqB12jd5ij9hTzMi4bzHelMYnVDfVF5oKjYdm2av38ptibM2DTspB3aWeU3N3Yndi
7MrtcrqfMdbrbj5mN9kdBjFWYEYu8d4Bl4I1eFaNWcwgM8DEmHGujmll2rk0LofLx7g7q+xN1kE1
cxVc1U2Ks1AT7LS5n7PdsnDpHFZPsndDA/ZYaIEhmSCzwGwzh+wFtpwdZbKZAkrg1IyRmeVKWTzU
HhoEvpZBaf5uDgbngvk3tAFm3w5l5m0y2GP0GA0sgH4FZpIM59NbaibplkXSKvO++jvqv4TPpz5A
ZESJvq6g3gsQ9aZD1PtpiHozIer9fYh6syHq/UOIei9C1JsDUe9nIerNhaj3cxD15kHU+wWIegsg
6v0jiHoNEPVehaj3XYh66yDqvQZRrxGiXhNEvWaIeq9D1GuFqPcGRL03Ieq9BVGvDf5yYFd9GSBd
B0S6nOrbqu8gXXCXydcUFIt8oKBY5F8rKBYZV1As8m8UFItMQt1/Aer+61D334S6/19D3X8L6v7/
WUGxyM8AilUhe2fUZ+KRffgbwH+FvwEcwt8APjyTfCYZOTqTckaD/AL+EnAKkS4CkS4K0a0Kots4
iG7VEN2eUX4JQOPPXgDoNkGTCRDqJyFCzYEI9bMQoeZChPo5iFDzIEL9vIJQ0QIFoaJ/BPd5vA33
eVTDfR7vKAgVrYG7PWo1i5q/RfVQ8aeg4k9DxZ+Bij8LFX8OKv48VPwFqPiLUPGXoOIfgYp/FCr+
fwYV/24Fs6Lvn/vxuV10Eur481DH/yuo4y9BHf+7UMd/oY3TpqPfU/Al+jOo3R9C7f5DqN0fQe3+
F1C7P1bwJfo3Cr5U/QHc6/BZuNchF+51+Bzc65Cn4EvV5xV8qcpX8KVqRMGXqn8PtfIfA8zSjQx8
hFzeyfvfjl+L38yJdCISZ84yTNIpiOrBMJ0MXodoDRJn2qNV1AnI9dJaJO5BF3UA3lWmFToN5FrA
nJoGvhOoPZCjHMvUKvjuFTUDco3UPLX+Kz72S5SVoEnIhXW9gAAjrBb+xxF34jqm1qkt6vh2Dp1r
Gb7MOFroRpqkc+l2updesCL0kqOfPsESGgawGuYik2efcCyC+7yidh2TtJauphtoN53rkBoQeoFe
ZlRYAnOBHnBMOttvCNcqsE1rkrWAaeYvWmPWQ+aFO9Ux5sIwytTC93n2TR7DUu3qjUJXqTvbkswX
mt3cBrbC7TGV1qSmIWuMmQNlnptarBlG8vIrQy//yMXwo9RLJnp5kX/Ov+Cbb79kyoXFO5nCllt7
R2M9cSxahq/Ni9XOaveyaDUa7AmuTq7dGjM3iFMNMaxS3GY7b0y7e4WXbrewi02L8WarWCbq3MuG
6uvHYlhsFcfFKXFZdGPT2E2mRIT9Q04ZDbdzHIuXGXoB9A9JvVR6pyFGL7CYFakfxhIsQyzB5LF+
R4+h2LDM1hkaWBvrYVvcXZ4dtlNIdHXWzLM9QorrmSXPued4Zi0Qsty9uN7U4h4Q8htiQtGNq+6Y
UMpmCRXsE/eI0iZX4vXSOxp3r2XYnnBt3lltnVVaJF2wJxgNrk5RK065OvF1ttOw6hx0HbtaqHVL
Cbt4O4d9WV+CmZxhppJuV2qs1JHawhKu53BhJo/rMhRwg1yMG+HGTZMNGdwUN8vOcw3uKZfa0cIt
cFqugHPTQS5IL3DcDcEdc1fb7gp11gL3kivNvVprvZbiPnQbQc3b+T5s846GL+SWLcnCM1PL7WNh
3pZ5J8/ZaDm6UwjGLZVbtRwZluDI791RWWPCWAPiaruTaakRFs3BO5meOankjkYqF1MlEzYh4aJV
aa3SPmFLnGJz7ktsp7TirLYPS5vSjrR/vUI6kk7tE+YGacKMmBuUsZaiUp/TILql5/aE24lMs7Ud
o8B49LtnhXR6gY+ybYKezhWqLh/gLdcP2KfuKbattp15QS+4x93jdK6phXnhecxoXC2uY8O2uMok
NK2Is/Q4PWWbs2eKjfZMZo5p1jtcLaZJ4ClbwO4RVwudTS/Ul9AFlmG62DakWAXdpXgMvQpKHrrU
ilUwCUwmk9mw51j0PHK2Xs6n4+kkmqPD9CAdM1vpJZg30gZ6A1xp1q1lCmkttQj8PZdJvhGl1hsG
gKVlAH/cdvTbJ2idOWgOAo/co8voIFNIbVlPrlVcq7AmWWqsSXwH08w0u6r4IXeqkbQW8ALfzQxb
s/mJ2lV+zexujPGZrnTmJqtmU7BT/iIfZW7ym0yNm+OPmoaYHf4uP+cao1e5E36U37lRwid7Vvir
nv3LFXwhM3TjkSWBza8N2gR7t3JH4JsThiUjyW3z08w0s8bvm7drZ11ZLr27WFg3B69XYKfCFjYt
HJuDlhXLphkRMxyLYrZRp1iy2CC67Qliu9grjhhyFUsWF8SNy/31ee5eMVVMdWaLCJ0qGulWMUiP
uJ6KHMwX01ZxAHxPil3inhgvvBIOgJcvGbou50PfThKrxUFr7Ma0pLphYo6kBLHA3HBZfVkNvCUm
5ooG8RA7tZ7cGHLV1c4yJnLDueBSuxKZYWaUL9Rr9JrbBHPk8vO4q63J5CaZR0xH04qt0J3qTnKV
NsaUsVcSa3FrhfzadiUJOewzewJoqdLaU1en9eS23pxrzrifJV10k2wpW8UyQpqULGmkTLaC1bMS
u2uatCLAUyfZV+w6e+DocYY5hC6jZrhqTscZOKt9wj7BtXIk12sosDi4Yq7M0cIec0lcNl3GDXAZ
1Ct6wfMI+PUYO8O1M3mmSW6J3fLOcqlcLmfkGutLuHiBcCfxfa4s3iTYBEzwWxHHM+ey0HInQeh0
PRV6hH6+kC8UngpPhEnrrDXmXhAsPC4wjbNCmzAjSI4xbMWlboy52uREOaVxxJJsTXKH9Y8Ej3vb
fWLZsYy6Etk06eb1Clcn8OFCqVKqkRyWUWzCrhFzpcfScC0ijYoLN6ZvTLPr0py05lyyCMaYNHRt
XrorNUsd4Kw16ZHbbdkUU+0JUh5IL9jO6xWyGiuRrkqC1G1qkabNiERhz51a7AV3eEOwRV1pNTmG
GH+VGXalXD/gy4EdDjv3rlUx+8wp7+Bv8tRtvdvtLmCzzAXmAraHH77eYx0xb/OjTDfT14gwUaa5
acWd7SrFdvgd/rQxdi3dWmzI5lVskbvalQIs0Mg84k1uq2efGVW+Y+4yDgZvCF9j2DTXASPoa27n
1CJsDl/JV7rL3DpsDau0dGCUNdeZ7UrnawT19Qq3tYFzN7ieXj5w9dgnsD5Xv81hagEzZqM76OYs
awZrLeJG2ESn2x02F19PMQ9aBNtdd6u73ZltmwPza/yNwveSGcpF2Kf5x65J/XPXvP6oYRt4bQmb
XrvtsjEJ1kEwX5QzJrC25jErzCYj8Djf12QCLX0MxnaF3+E2iIvM1aYhXsNfoLXMHJ/ADPEvvEks
5m43GgA6iFPvqfcQRP1z9c8R9Oyls5fg7p6PFe6PFe6PFe7fCIUbaQce9UtUXzb0y+PXMo9qVSAb
iavrxFfBu+rtA/wleN01T4HPBHw+ANjF22uWVpAj8QnCiKhsY4FUJI7QB1IDgIe8PeMbA9+Z8H7/
PqKqM5jrQK4a7/Bv/x9nlF+ykLi7ceRHO6O/dPw/H+jj6wRuwW04UdeH9+svVuzXn1Zv41t4vzfe
m+rVXfZ7daY0L2nmjFrzlLfXO1BfaKoCZepwm6kIlJmsPyXL8P76o2vgTK/BQilnelNNReb4QEog
PWALPA2MBeYDLwPrgRyQV3Izga3AcTAp4A8QQWsgxRtT6uAufnumrs9UVbHv1dWfghrolRoYs706
YuWy/52LZk6fSWx6B4gdU8qlpzoDMXfpJfGCWCNOgyPB8eBscCFYEFwKksHVoCG4fZ2wnOKW2lhI
Vdfn01fHzAumY++4N165unI93Aau1+c79g6ELl56QmaAlEsW1BRd6ySLybLgie+ltdhCKX3ha/M9
8b1yWEKZXp3vIPAqlBcqNDTWRQNPr/lDJQFbcCq4rM8Mbnh11gy8/5InuHfZcz2nLurV4f22C95W
M+ct8BfWlQdsbyxbTmuKcJt/2lSE+0H9ery66hgY0TWjsS5TabM3Senz6/neAjzRQiltBqW7vF1G
t6nKpjIjFY/9z3HJv+Pf9x/5T2sWwT0YXMLn8Zl326tjgcTrbaaquj7/hH8O7zdzhhPcYtTiev9K
9fa1Y1NafWHFfs1uze5lvynNv+mwmKpwm4EEo6SMkzJSNjBKx0Ey0B/UBaqCGcHcQFUgPxgM7AaN
gcVADyAnvcGBQEtwEJZ4CtJx4Fnglf+FNz6gxlvwxUAa+LwoUBroDzwJTAaRABOQgG3BRDy/3hY8
JIaJCWKfGCWmiaNQck3RZX9tTP8olFAde/fElGI69vn9m3hp6IJvTBmh+sL6wms2/6N32y89qV32
PfU9rT9tJkxj3nH/5qUnIQ1e59XZVF5dbaw2ZuS8AzVFZLXPZu7ytfj6ffO+9eqY7ShUDuq5HkgP
VYL3/mB84CCYCiwkO9ASaAsQYPxagw1Bd7AxGAswwYLAEyUXqAvoA5ZgcbAs4Alq/SvBrmD7tbZg
OJAVqAhgweq/t2zFpjtBe8cCPcQKjAKnO/sWVADe/4eLBIWEQfo8EgUpH2kB6QtIK9IGrq08T/ZF
uLK/Blb2WaQErO5z4G7Kyl4KV/YvwafHvoyq0TPIGzCi1CW4wurgCmuDEaUaVOWqNxC76pLqEuJU
val6E8FUb6mqEJfqHdU7yB2VXqVH7qrqVfXIPZUZmKQHrsX34VrcDJ8Ga4VPg7XBCFR/Ap8Ja4cR
qP6ZakY1g/yZ6vuq7yPdqp+ofoK8D9W6HqjWfQX+rxy9qgPVAfJV1YeqD5E+qMd9Day5aqQfxq16
DONWfR3GrXpy5pNnUpBvnNGcOYf8Cxix6l/CiFUxGLHqmzBi1TCMWPUt5bkuZATGrfoAxq36IYxb
tQrjVv0Ixq36TzBu1QaMW/UTGLdqC8at+imMW3UI1tws5ENNtiYbjdNc1HwGVWtyNXlovOYLmi+g
v6Up1BSiiZoSsC5/Aq7CyWD9bUB/Gz659TuaRk0jmqp5T/MeelYT1IRQjYbWcGgaVPQuQEXvd6Gi
lw4VPbAWaxbRDPjk1qeVSFno7yuRstAsJVIW+gdKpCw0W4mUhf7hua+c+wp68dxXz30N/cy5gXN/
juae+/q5r6N55wbPDaKfPxc79000X1mR0QIlmhZadG7r3BZarKzI6GvKioyWKCsy+rqy8qKlysqL
fklZedEyZeVFv6ysvKgFxtSywZhat2FMrQYYU8sOY2o5YEwtpzZJm4QSyv+mgfqUp6NQUomMjr6n
fV/bgz7Q9mr70ID269qvo5T2G9pvoLQ2pv0mymi/pX2GctoPtB+ggnZcO4GK2kntJBrWflv7bTSi
ndUuoFHtc+1fov9U+1fa76F/ov1Q+yHaqT3RnqB/er7yfBXadb7ufB36/nnLeSvac/7m+VvoV887
zzvRr52/d/4e2n8eP4+j//w8cZ5AB2DUrz8Hq2An0vfRWli0+yvHr12/iWIyC6zHBUQ1mQNyOUQF
eM0i88Bn6UQReQHkNGQByCUTF4kEkIsH58URCKFVzvcekQlInHefSPQdgty27xXIbXhPfMe/Mm98
9DRT+5lWGJ2sCiB0pKjq4+P//kAfl6yX7OrKdEiJukT/ZkfxXnlbeX/JTOWzq/ordyuxEnUl9nrB
W7GKnbe2r2L3Gq4IxcbXMkvWiVFd2ZXREvWlV+VtV0Yrn72mKXpcidW0VBYpZ165C77bJfZ9al8R
WGd6wKo0CY5EkFdyT/B+n8235avzVZFJvrSSGaUOJfq3TkrUr2UW71Vi5W0lM2a3UoNiK6hDVYn6
9d6KnXeNFZlXhEtZugxd8ZuCCZSpqCnpuTJHBkmODJOtxJEvnSwjuwBOGShZfz23ZLd6r9Faoq5N
Ks5+M/Pd+NqBq3rl6sr1dGUVO1c6LmVdEV5PrZm5VHfJolt9U6i11p+aw+R4xXSxVbdXWaT0xVvV
bya/tqIrI0cqseIGXxo5BdoFWkTOkgvkkq8I3L39XSPZW4l9kQBtKCYNJSlfJHxPwX0sV6JmN+iP
LiX59PUXX88ldoq1xMSV0XfmlNbWT1zqL9ETa8UN5Z1Km8u3lD5/I/dqzhcXi4aVNlfsvNP95lBt
w2uZbxVX71U+I+aI529OvDGrK6h/rKuuxOpL6st1h/W4DinO1u29Q4GxUQP8MP3aCrFZrH1NeGvb
7CZWyvvNxhJPsbF4T7esWy6aeL2g3vFOB+hr7ZsJAGnsE6e+dDBSRb4Zn40sA/2o92X5Zsh48JpC
6nyLZLbvmU8iq/Fd0k02kiQc2RaQ1n2dvnnixRVNbWttl2EZlFT70sC1WgAi7AfJ4rPpyoq1ymE4
LC4gg7pY0eiV4UvHbybr/jt75wMVR1bn++qq6goyDCKw2dA0iE3TNA3dNNXQECCEEEIyhATCEIaB
TP/vprvBmGBEBnmIGWTzIovZyMYsYsyybOTlsRjZDMtEjBgzGGPELEZeRMQYs5GNI8aIGGNk9t7v
ZZzRoz5957zz3LehTn36V7+6dev++d17f/dW09XeNLST1E7xxeKLOyNJDbn8pvJTRZF7XVurn/OV
n6Q1RFJcRawzLMtTenln1c4dO3cU9Gzpe+ZW04j1funl3SMHxvZObLMWe2gcVmt5R3a1dUc5v3V6
27Wc26R0Lm45vXOAprOpqekmqatQktr5g7MHl4iFcAc9B4NkP9BURb3aJut72g+Ok/T30KOD+vdw
B01NYU2RBwsPLh981ORoqn2mtWk3Kaf1B3ObNqxZ9mVi081E03ewLaeE9Ewpis8qPks6ppcVL5Ne
6hXFKxyv+Lzi85yguKS4xImKKcUUp1RcVVzlJMW0Yppbp5hRzHAhilnFLPc2xZxijgsV0oV07qnI
5shmLiySOGHc05Gtka1ceGRbZBv39sj2yHYuIrIjsoN7R+ThyMNcZGRnZCcXFdkV2cVFR70zSs/9
RZQpKpd7Z1RhVCGXRvrMSs4YVRVVxRVEVUdVc5ujno96niuMqouq47ZEvRD1AlcUZY+yc1ujnFFO
rjjKHeXmtkV5o7xcSZQ/ys9tV31B9QVuh+qLqi9yz6i+pPoSV6p6VfUqt1P1ZdWXuTLVV1RfIZ7Z
E1/uiS/3xJf7s/TlFBPENn/tI6Vqnuz/B/sf9Hn9hsApTgicCpwNnOP4wInADOGxwCTRDQSGAiPk
6HDgOjlqC1wPzJKjQ4FWcrQ/cC4wRo58gX5y5Ag0Bo6So5qAjRxVBnoDff+lx5M31+X2Ca4335ak
dykGTXJmgbG/8qypNU+03jFu8C/5H2WfzeULV4tDA/GFg4H4gsWAubwjJzNQFNhRNli8VFRrkn2S
sd9/xtS62epfMp3M5dM8KcsBbcCwsZGEXCwOLWrcxvnFgMM3ROricTA6qAtGkzrxBe4HQ4LhQTmo
ClYELgRGPK7goTwPTYO8mFdmai2qNW7YPOlfyj5bNkZTkOYJxJuKCweNN8s7cjvqxsoGC/1b72Z3
bQ4L3t3oCD4IPmwIDVxoWO9x+SZ9VQ2a+m7342B3Q6ZJzt6fWZC6f2u1qbWhxMBtDjPty31QuGrc
sBZfP/FuThV2lw36z+ROvzDTcDhtePv6XFX2WMORHJNpsLA1tXVjIy2LbY5tu4uGch80tAXic874
ivy59eGBxw3D9WcbeuujA/0N6gb9tpUGUyC+IWLjyDZrQ27aeKqrYTgQn7K4tTqQX94R2IDtfF14
9v66u0aDv89/Jq3NP5zauq0978zGEf/8tnb/sn85a30gjJb5dnErbxgpv0XzXN5hcuVczn2Q/aAg
N2XJdNY/7r8c4GwJgUjbRPH1QLx/1H/Rv+i/vVEycBsl6x1SN63+Xv9poyFgzcvMTstZLBvzz/of
FV8suRTYbdyQo8/R5x0pWNzKZ7uyHxgNFonUUm2gCjXVH0wLFtR3+xaCHYGjQX9wf6Az0BQ8FcwJ
Hg+qAveCg8Gx4ETwUvAKuYbUJKlLVWAlUOW/HpC29PmvuvS+hYDPo3MfDbS4jwb5YHFgMjBl7Cd1
2m80BF/bGdZQGLyxrTa4GpwL3moQGyrzgoaRvN6ytG3m1FL/ma1jabmFqxtXGoINB4qP0BoqXipe
KrzR0GyaLtGVXCqcK5zzL229m5a7VTZuyJ1usPmkbe0FuYH4vN683mxSl6bohp6GsrzRhpoGT/Zc
gUhK935DH6mp0wFfwxliie3BUmJ71cFu983AtcAM2W/6HJ40f1nwZHA6mODVe6LpEel1jvlNnuhg
a2AouC/oCp6rn05NCJ4l5dQeGAh20fz7hnwDxKYXAi3BkMAdUzHe4pP/xHd74rs98d3+PH030l56
3hz73uX7w36Ip89zmhM8ZzzDnlFyNOhUEU54LhHdoEPynCVHI55r5KjTc5R88p7Tnqvk6KqnzXOd
HJ3yDJKjVs9+TxfH75vz1JKjRo/Dc+LX/cSb/xdxW3nvzd84SpimO/9vplbThGdC9pharS2W+MTx
1Ie7mi1S9oRcYqxNnJeXLUOp1Z4bJcXJVdp7eWJGh/aeRWtqzUjzTJjv0avoFakPMx4mzmu6U7vl
088HE+fNkZ4biUsbZ7STnrnkKnm9psI04Q31qr2Z3kJvjfeAt9nbU+4v7/COei96572LpBvSkt3q
y68o8y55I3y7fVW+Wp+PXLOeXFNCrukt93uHSeir3sskZORayEVvic/sazcbdLmeU5oHmluWE0l3
09ssQ0kJxvzECFNrUkLSnGcwcX5TjqXdfCxjOuOcrtA5lreUe9JzLq+Gpsl3wtfvrSH36vFx5B6j
viGaoj2kYyTp0nqDFWU+7Z4NJD0XfJOmVl2hplr3yEhGP89DuS8pPLnIMrm5pbg3cd5SJS97JpLS
tPfSzpBSikycTxxOHNYtWs9bjmWGPL9Ijk3mqswQzw1awsmcfDtx3FKl0+gidLnaCyQlJpKWBd8d
kpZ7Xk89Xx9Sn0BS0rOWjsyKsvrWylJfVfkV72hla2VrfXf9cV/LHq7+ZP0pX379Pm+uL5+Wab1c
X1Dv8i7WH/Jx9R3WFu1NY63nbP4krSHPDc+YZ8wypI3UVGRc2tVsnbJOJc7vak6vSXrok3xFJcUo
1WXvUupDa4tpwkTsQntB9mhuWVusLXlXSclKqd2kVM86fCUdGXPGYyXFm/ZbtNap/BbNhKfbXGXh
Mh4QK5r3dGec275oOUZtJTF0a0XSIXOkOTJP7blh0W46R21N1liGtkdo76WelA9s92S7kg7l39zY
Qu+YOJ44TkqJ3Cebl5d1hRatvJR/wWLwXHKOefVek6/FmwurKCNlZqPfpIJFHfaeofXnvQ172uAz
EMtopPVH8jTq2+FzkDr2eD2+Jm+ld9b7yNtGSrbSe9qrIdplXzw5S+0h03uRhD9CtMQOvTXERoeJ
XdZWXKy47Ov0HSX1ke+97r1O7NXq7fGOk6vo3ftKOvJJORlrLSuJ1zMmSjosK9p7skbWeI5nF3iu
GGt1EanViZc9x/NvlhTrblukrWPae9YpS3vGJbpZHsvrSWoyka9cUtsHSA6u+UZ8M76bvvPpbb5j
vgHfVFL41jHSHg3y0qZumdzRHJ8YodObzV5xZ2R6G7M97b3E6567OnXibOK43Cw3kxRNJk1Q+9zc
kj2RkZZ43TpFLO6RxaA5l9Ehe5xdnlXNJXkx43jGWW1YxoSlsZ73tZDcLfj6ffeJHYbXRxNLVHl7
6ouJZZVSOyQts9bbVr+flLXGe7m+or6i3E/C6eqjSYmMEptdT+rEQ3Kw4Fuo7yItp6V+0Lfie1yf
Vp9TX13v9+bWhyQNyh55WR41tZrvyH2JZYmXZU1Jx9YxXW5JR+J4SYcxP2cpX9ISm7F06nIz9nke
eO7mLSWFkO2uZ9raLvfIS54b+TflXK1544y1paQ4TyT9k9qiNW6wTnlO7i21kHhNc5pqWmbFvZ7j
8pLmhmXIskLPbazN0+cvJFUnXrQ0es7JJUnd6c1JExaH+Z75XlKa52yBLf2w5pyxVnstaVAzkbpq
2ZFaobnheS3pSnqbzmTerY2Um7UDnlOkTc9bmjT7iJ03ZTxMmvDcSgrXPHB2bTqVcUMutDzWPbIO
WKqSBtMfWSZTjydXEZ6UK80bci9l3Epq1Uxk86TE47OvZLfqek2y2awTzRtoC7C2ZJe+0QfLy7T/
tdzR3svooK2JWhnpfyfkvvTm1If5F1JPJlc5T1qqvIv45biviV9/8p8QT/4T4j/9f0L8xu8xbtBg
/4N+lO22bZETVPHGMfLJW64ZRzheFbHrNifYrlge2+aIbtxs4wTLqGUp00DCj8pF5GjQcstG/ChL
vzWeE2JuWWZsYxwfq9GvkHNHMlZsI29pVW/+70NYSOSbHt5fdgqPy5fiHLr76jMpUmK75aHtouqx
bb5UUvlsi7bluAF7mH2DXRtzeK/NcDxm/d6SPa3JIVnnbT22XlufQWcbtl22zWpmVT5tscpHQnN2
w16b3WpqM+jsYXWjqiZDgqzVWeUipz52X/qCvd/SYSp0NlsS1D0Zeue4PGXM0femROoPuMIME64N
cQOO1xw6x4OUC7LWGWrosp/IuJy+oB6Wd8QsyTt2Fqt7rLpNoZYKs6qux1DhXHYeiT1kv5Z+ISZC
1ZTSWDab3qLqlM9naNw5un6VpDNYKgwq41m3K7FWbdJZk0MKFmo7yudj7xpC3OE7EzatN5e6VTqf
WzarVFL6ij7CoHJXu1t1VnO4u9hcmiipquJWjLo4R8y4PrPi/pZrjhD9bGyCaocx7fnHyWOZF1VD
jmij3+LP8qkjtMeTzyX1OnSmRQdfE6qTsqocCY40nSNzvb7SVZUyGXfNkeOq1YTGHtIfzlsptSZf
yT/kKFD3WKJdjTF9rvYYk6HV1ekodh11VBi7aJ62FKX0W+bSJ+Xzao9R1vUnP6A5ei7NoLKQXOl2
66zqZV1L+XzdePIcSWV/nEPdp9ZX3HccirtW21F2ILfn+ceOENVQhWT060ayfOkLlpDkc3GNtmXH
FdP6zIuWidg5w6VdRY7p2LGMymSX4VBsguNGVlP6TcfYbt3Gk6ohQ07daEyoqlEzrH6ks7qG1CY5
P+9O5pnK0+md6t6M2xli4oy+xrVgDk8ZSBmSO12PU2bqxt18RqWhwzEtn9AMO+6S3BclrrhDzDmu
GVOla0U266pSigwJ6RfipmIijCfjw8tm3Wf1fca0uKLkCZ1BPk/yV208q2rSWd1zhpDyefVh8xX3
a5YuucnSra5Rn9511FST0Zcyqb+uNhlld07s/qzdsSfdd5NvGVT6A3KRflR9Rh3hKHUdcznUES7f
puuu/phx1wnVpKPaITv2Wa64mupq7P2qqZjQmJK604ZDTlvcQGamuid2n3oxOXzTaed8bmWKVVOp
jtCF2e9ro+0n5KKNJ+P6Decssu6+QZd1wpyWIsUNqK7ZRkmbGd90VfW4VLItxU6TNiAZSu1h+kfJ
1aQlmAsG1OO0xSRlGl1JzZkHMg+rfCpf7LRtmVz3KPOA7bTtak3QHqnula+pPXFTtjPlS7r7Kl/y
quFS7APZXL6UItlu2+PTzckhtovl8+XzpEVqNZWa2RSDRVY9VjWpmmJu01Zm9tt32HfE7rdPWTpi
liytZtl5xj616arztr7PFa9uMx9yqvVt9iJTYQpnLnXqnT32Ipe2pjJlKHbCKaqOOg/HaOKGnBcN
Cc5Ql1X7mibUPuD02Hpizrg2mEqy7pi77Pc3LdtX7OSestbQZegy5hgH60b1R0yFpH0W6o8Yc+Ic
Zjn5RmZobIehNOaIIcdcajir8slDyeExEe6ElCE36RUyNLp+eUY+YVDJ9wyX3IcyZnW71VfdHapO
9ZmYeUOIWkxu1Te7o22n4xyWELnFtmzIcVe4ozMPu9Ns19379H3uUuM+Q0VeU/oFVVPWHZ01Zbcm
NDkk43Zd0F3g9svW2LvurvQZc/fm47scapN+1nAyfci9P+Vx+oKhIuaIbijREDtnzKmprDssa/WF
5gp7p/2oszB9KH3IWalfdLZZ09Q9zsuZ4/Zau8O5mBJmSFN7Mi6aq3Ujcefp7lDV9bpaVCt1NaoV
Y0HsQ4OK1MERuquXHV2qa+R4xN3tPq6ZNS05wktvumpTOEt0Zq9p2RGdfszRFTuXHm+67PAn845W
R5fjpON4VqRmubYj8c7eQse5pGHSkvsdE3l31Ldty3tCNGWOs6RddhsmHIPp8VUTjlPmc+pR4z7S
97gc+x2XskYcc45bjg5VY1lzmUd3wdKhulZZqBklNTpqvOReNZx0jbjO73Fl3HYeTlzJ0maMZt10
3axrc90h2z25yZBjiDZHy2bXgOuC+rBryjiYdU/XaZp36FLumPfpqtwPPaLrvnF/Spgj2pQZZ3ZN
uq7phyvizRW2R6bm2A7NcGyC+5QlzX3OLDvCY0/tmkxcyV1vmk0Pc9/YFIy9S2rj1qZ53R1zmuVK
5mn3tFHOWNI1ua+kPCY976WdCbFzapH0uyfdg6oN2uLkYveD2ui6ZvfEXr3qmHE/sZsxQ2ndYfVF
XX7MYX2u2qQ2aUKdQSdhTJ+zjIwRxzIua4bt5+0X4sLkC+kLG0+6du86ar+nnjXkOK9nhJpmYwf1
Qeeo3Wf3Oa/aG+1NziWrKmO8ID52wmV2rk8armsrLHQ8NN1WNRrSUoayGu1DzgOZon3GftN4qa4t
62bG9aybcZ32Bfsd4w17lW6HfjRZNkxnhmaGpsy48tM3xHbEHjekGa7UnUnZ4axx7UixZmoc0SkX
UoZcRc4+Z6/ztCZoKFX3qHtilrJOZO2ImU8ZcT7aWGCf1D7YeEs1FBdZIKWEaYZNty0JiSvpU9oC
FxdzW9Ym7pYHNGrnaOIdzbC+19gRN+DMdZZYJlQcGfuGDXKK1p4fc9m+25kp77CPxO4zedJ9To1z
1t7iklyRLkOcltRuhelwyoIzQl9oKnOs2tuTp50azXLiSuIKXWVRLDz5H4cn/+Pw5H8c/tP8j8Nv
rM8+NfWH5xXrFyyZnLD+Znga+eTXXw/XEl5NvkF0l1Maky+Ro4nkGXI0Fh5KPvn1IzVh5Gjo6cfk
k19/+rmH5Kjv6aXnXiNHx5M7yVH307fI5xs9x69nFYoZfgbP/HO5nSRdpv/N3vtbx8E/4po3wv2u
sLa1/Q35wO8Ic2DtvgfW9j6y16x90vOn33LuT9n/mHT/rnDNZG/jdoY6sIWFVpGthXy2k6MqsreH
dmI7GnqMbCfIZ0toP9kcoZE4S7d+sg+E1iKGIfI5EnqebJGhF8heRY4jyTYJ0k8mHQOHyOZA/FMk
limynUe8tWQjV5K6NfwZfRMgPyqfS8P3AYxRJVGVnAnfB8jD9wHy8X2ATfg+QAG+D7AZ3wcoxPcB
tuD7AEX4PsBWfB+gGN8H2IbvA5Tg+wDb8X2AHfg+wDP4PkDpf/n8K/huUUSLHiNjOrdu32/th8je
SvaOteOut+h/O2zHW87/vp2e7yb78d9z/uTaTuVTb4mva+2ef+r+h9Ly1jz+MeHeSNPvytPvC9/x
lnv8qelqfYs8SPazvz4OKi/TTdottSsvKi9KkVIYOeqUqqSjZKslmqOSj2iqpBZojkknpH7JgWva
yfFuaUAakhxES6+okkbIdh6kn0y6AB6TwrBNYpuSJkncRezuiK1RasTnCdyHbtfewikSulaaWdtu
rm0LaxtNMw11R7pHP0lbLPj/5H2teVF5pKXSt7YW4K2tm/HW1kK8tXUL3tpahLe2bsVbW4vx1tZt
eGtrCd7auh1vbd2Bt7Y+g7e2luKtrTvx1tYyvLV1F97auhtvbS3HW1sr8NbWPXhrazXe2urCW1vd
eGurB29t9eKtrT68tbUeb231Pyn3/0flrlAYFEfg5V3l0knp31rbH74pC/Fspzp8vqHTvhmG1/zm
Nb9r5yPIXra2R/z+8G/cjxfZrlh9U4Y+4jfD0PNETleosekVer6RbE1gC9/Od/KdCjV/lD/GnyBy
IznfyXRE249wTeT4KPkcIPsQ2QawNZHzTUR/goYhFvr2tV9nXPj1rzMK4pg4wa3DrzOG49cZY/Hr
jO/ErzMm4NcZE/HrjEn4XcYU/C6jAb/LmIbfZTTidxlN/5djJ/77Kv3FJPpH5UpKhQ0chz4ajAf1
lK+vgK9Bkw/5NniT2Ew84jnMYlNUgdfANoT5BjgNfgf6QnAEPEbJ7wbNYDH0g+AtsAt6NeRl8BI0
zZD7wCbQD94DZ8FVhHSBIWAuiHkMPwd2gL3gUfAOpWAA94GPaU5RSofXSikUObqAMiwAE0AeHAMP
gIhndT2I2H61BDkM8kNOIWzC9z+tYNYaSckLsZDPge/D91E0IMLw/wMcAs+Cn6FX8d0c6TX5r0Lz
CVwrrZGeXYb+Efg6+CXwR+B5hMyB/FFwOzRJkP8J/Dj4d+BFnM0FcVb4a/AvQRfCfAXcBo4g/ccg
lyLMZ/D/bcOYzTWDiF+B/CoQhvRKlO8G63EV7i50I7b3g++lc1Pl30B+DbyHmCsRUg0+C24EM8Fi
UAVuAQvADhBWLRxFbJ8GTyDOv4UeqRU+AvrAzyLMceSuH0R6+JfBOhBx8qxk/jv4YbCekdo2jzvy
H0R+f8WdJlwFH4L/Tu1c8T0q80+B74L+x0gbSltk6fkO5CtI1SehyUfMKB9BDzrB9yuI1y2UIORL
YDj0sDexi57lR3Et8sv/M/gFhGlF+HUIOQHNLsgDkA0IeRnyh0BWJjdApJC/ypFZvPBF5LcC3A8+
g/A9CDMJvoqYPwB9O4jUCjakIQryu8AYELHx34ecAh4CWQ16cRWLJxEMQ3ic5cehQRpEWJqAOhX+
FUQK+VOQ85DaIsiFIGt3qHeBB38KPgfuAL8Mvh1piEBs0PBnQFi1gPiV/wJZCU5DgzhFxCmyMrTj
7KuMimrCNpx9Hpo+XPVXIGxDdEN/CbwKPdq+MpTZAwhrV354rY4oF3FtGvQhCIP+X1gPwvKFAHgA
YZAXJVqr+DTkaJxFr8IjX8oN0FSBzdwe8CXCBiorRWh84HspxXjI6yj5W4wKJeH36FX8TZx9Bfwi
+CVcdRDyPsp1I4yKByT8zxHDY9zxach3wWvgV8A74DS4Cv6CyfS+pN+j8jnE/yMQ4YUl8CHONlFK
WZQKJ+gC3SDL9XXIu8EKaL4BvgqynH4d/Aw4C34L/DbChKPEopDfi5BxlXABfD/4AbAF6WEl+deg
Z02m5XAM13rBTdCbwWfBFxA/yopYCOXzICv5GvA50A7uQQpPMPJvIxoH9A7c69OQz4DHQRN4Cnf/
Ia6aAv8n9IsoH9Qjz0rs38FahJ+B/pvg9xF+L3KKvAinwSDSfx5hvgdND4iciszGbkADG5DaERLl
w7MyRAmTkXQPxtA9GE+pnoN8k/s2R0comh6knLRfqv8aZCPkfoT/JfgTxWcIkQthDsTdRSvIg/8K
/Y9BlubbiO0n4H1okF/lr0DYp5LV6WXEgFpTwqL474I/xVlYo9gFwj5FlI+yCLKXqyNhGiFHgJ24
ipUnS9UnwL8BB3At2pSI2le2Qv8+kFk1NMpPQf4ouBW9wRT4cY74fuKLrJ9/vZ9ofgC9R5FGezlK
IWX1BpH3QV+LkBjFePRpvIOGEV+hYZQYcZTo85UfYOMXzu5anSRyAHIW9YcFEf1PB3eFMJKSb8fZ
p6kvx7MUop/nWT//8dUF2nvgrBNpqwZZSg5RWZkKmsEMnA3ibAPkBsi7QYyYfA0jzj4D/jdo0Ifz
h5kG7KZeMSGV0d/yeyglP821yEbbeeR6H+5eCz6L8O/nThC24KpcRugxAirLuUe09KDPVFhRzkTD
v4BS0lAqmX9YDX0dWMbtR7vAuEzTIHzw9e1Ej/GOzwa9uMsWlhfOQ0cKOrMQvKsn6TgLojaFR6jl
X1A/h38vrqpFjcdTj1pEbYplICsxjODi+6m1CMcRPpPdC/EchIxakExI27nVWFpHuNdHUGI/B1Gz
4mZ6F+L3Um9ZBerAr4IoT9HFrA4xW+m8QNhHyVvp/IhvY7WGsx8Cm6D5Nq66TkOKF8AEWp5iMiX/
Assp+G52FfRuOhsSPo68RKKW61EaJQjzC+Roic5E+OdWO6mNISS8R8G3SsY4wQYeBMuhr1/9HPI+
ifIncxP+H1jecdZG64V/kdqY0AgZnjNfijtuBbfRuZs4g6uYJ9OJVJlw1sWIUkV6lMzG3NSTFM+g
DHuQzmO49kcsBhDWKybAGuGJKeFXC2gvAps1rLVB8LvgbfBtCJ+KGL4OspgHQeRRYB4ys5m9IHwb
4X/h2ndAw/ycn0E/CcKLFth853M4C39M/Cbogf69IJNPg2jvAlqxMIaQzM/EjEacZnUBYn4koE8T
FsCTCAOvTETfKPwEMnxd/oeQ4bELfsgRIPoosRD6WchLIOZ6IuZxAspW+Dw0d0HMrQTmJzO/9zoI
L13AXFJk1oteRURI8Vvg34McQrI5F0sbegOReeOrkOF/igpo4FUKmHuKmJUImG8KDvBT0H8DhE8u
Irz4NZyFJykI0GSAbKYAWbCAHHqYd0KGp8rDb+d/CaKEecyJyHhNiVLiYQM86lRg6UwH/wLcibO9
4OdgyahlHn6ywGaamAHxrI4wh+LR4ngT+AL4K6QZfYKIeYSIWZXI6vEA4qkGmffOfOaDONsFmY2J
qAv+Aghb4jEj4FF6POvDf8pHE65AbsU87n2gF3wWPAJ+CsTdRaRZ1OFeZhA9rcjqhVk1enXBiXKA
hYvMhuHP8/dBzEl5tB0xei02Ui887JNnM3FW2hi7RdYW0H6FZBDjmhAHsnkf+iiR9QZorYIRsf0b
+BgaWI7AxlZ2X1ipgFmqwGbibOUBc0AB7V3AqogA6+VZ+A9gJoVVCwH1JbAeI3TNxihRsyJmQMSf
pDLuooyBb1MK5q/5OS/Bxqi8Hz6SDnIAHlEZmAONBcwFJVAJZoIJIDxDAfMFMktl4alHzfzVH0Dz
YbAX98IsgFjjHozCVH8AMkvbu8EPQcP8UgEMAbMRQyTke5CRZgHeoMhmWJ+EZhv4M3AXWIg4mY8a
zr+bo/NlGv5laN4OIj08SoPHfId4I3tQ75TvAdVgB8jmZfB+hVhQC74TeszCROROxFyDZ94+PGHh
CPztj0BuA5k3/h2ER9mK74CGefVs5vgSeAhnt0OuBt8FaqB/CvJXQRbmRRA1K8CjFlD+4gdBNpv4
MuRiEHUhIhcCbEzJejnWmjBH5tk4gjFxHebR62Dn62CZPFtjYS23kbV6hGcrYB8DPwm/4gHiZ74l
ehsl85/ZVVgH47E+xmO9gsdKC4/+h8cqH48eT0KbXYfeSYm2qcR6mhI9ofTd1VaOzjdp+M1U5j0s
DPwWtoKEMU5CCkW2soRRg8f6J4/+R8SamIh1DJF5vGzlYQddUxWepxSxtibCi+ATQKSER+/Nw8Pn
se7Hs3HwKXCCXsvDc+CxGiO0vB5B0wC9BjG/CH6Uch36PfEpnEV6FGx8xPotrwWZB4IyFNnYx8Zi
eClKtn6C3k9ifT56Hgk9iZLNNbD+KWKFRGTrMBjZBYw+4kuYGSUgVTxK4AFkrDDz31y9Svvk1000
PdCwuU8HyMaR6yDGDiX8FiV8CQm1r2S5QNr4CmgwDipR8iKzojkQ66ICVjJJO6UxsNJGnywyH+MB
swSEwR3Fn4NYMVYy/Q+QfmZjsF4lPFgR63giG3Nl6NmqeBbyxdYGUcICG21HoT8Ffg1EyQjbQNSa
EAO+DWfRjnh4IGIb1ShboM/FLABjkAjrkuALSfAnJaxVSuNI8zGEwWq8oELMdvoMhfTqhEqUsxIl
pvwhYpbBZ8B8MB1MQWzt9ImMGICGtWgT5KOvSyQG5ufUcNkYiwmVzCNlq38RuAtGNwlUvLJ6ECR5
UbyMHJ1HCuGHkJGLprCUPssQMc7y8Dl5tkKI1Usl6lR8CD2eO4iYwYlsTscsmV17B2Q+KlsBhpfL
L6K3gVcgsvXSAuTo7UgJykRRj3kQvDUeXpaCeZK4Oy8hJLxx8RoID5yHp8fjKuUB6LEmr4T3JZ6D
zOY1jLAQEb4Ej9YqYr4pwUNQIjYRfZ2ImYWEpyoiW78N0vm+yPxGtqaN9XOezYXhRUhsLjDEbAlx
okVLFtoe+Sy0ysOri0RmK+3Mm2JzKzafRW2KbJWb1eno618gMvpnHi2Fxzq2ErMYJfOQWVlhLBDZ
ujqeKCnRKkX04fSZOEdXO6kG44XI2hdWeiVWzmytmz3pYOlndf2PlOswHr2NlRj8TIk9cYAXLeLp
wDq26g5vU0SvImGWJDE/Df6/gNjIPIWutLBWA99bgI0J8FpF9mwC5S+wX0dhTxPw9EqEbSvZbJ2t
Qu/j5sld2CjDSgMzKSVbY0GOJNSLhLVoCX2XhFV6iT1Fwtq+yHpyrIqIzB7wtELC3EQJ6xKxpkH8
CqpnT3/Y7OkA9bQFPMniX6bp4b8AfodS+AR97kk8QKr5BqUSfYgIf1UJ31VicxzW56CvE5kFJnJn
yVnW+8XQclOixJQocxEtS8msDr20eIiGEeEnCKx2MF5LbMRksw82QjHfFXoJbVnECCgyy0FvILB5
H2ZPIuxKhB8isXbB7ovykWCxIlvzZ3dn49c4o+IQCYP4JfThSqyiSOjlJMhKjJISm2vgGaIS/a2I
MUvAjF6JEpMwjxZf4Gph+bXIXS1CUn6AUsk0eymFH6/xPuytFmVbC7ulIZ+jDGlkpE+Qyd3p2Xfh
qh+Bd8Hvgd/E2V3gc2syiVlsxdkT0HwfZNciDevUlLwT3IOz/ZDzIDeDQwj/L5D3Q34V/CLSuQB+
Dvn9NMJcBnvBfwAHcfZ1yC8hfDTkv4L+RWi+BI0ZtIC3wDaweO1aMlMTPwE5iDQMMhIPUSFuhP5j
iM0OuRt8H+6CkGIsuB48hGu/DU6DP4P+GcSgRDlEQL8bMmLjn0Js56B/BeEzUJJWyNtw7Wdx9jE0
nWAq9NXg30GDcluHa8mMjPIM+ClwBmFQa9IYOI5rv4GzP8TZHzDS7zaQHo/Kfw8OgN9C+A9CngSR
ZgnlJrGSR3jpIoiUiMO4KgeaI9BshuZZ0AZG4mwCZJZrFfjP0NRCrgHDwK8iPLMWGXIZ9O9GXn4J
DayC+C1UDoe+Ad54A/2ehgj/U2jEeu8VqlGin1ey1Sq2DnyIkZ4V8iF/DMR6oPAd+CoJ6AkboH8R
PoAOo/xB0AG6aUiBPY9+DRr08MI/4aoRcAJEryK+AhnegjAF9oCdrwfpnBeyD/wgI1L4MmT0n8Kz
kK3Q74FchTVt9hyhDemsREpYmjPBErAM9IKbwefAOBAlwH8UcSIGwQ1WQ78FshYyD7JV33DojZC3
0lQRj30H0URB3wLGgmpwF7gbKWTPVRWshCGjJPlb/8HeuUBZVZyJuqr23ud0n3ef96vPObSIvEUk
iM1DBGwRW8QWoUWCCAiIiB1AREQkjEFEggwShhBCCFEkBJEQRaKGICJBJAQJQYLEYYwhBIkiyygh
hJ6qb7d3pO+sO85dc9esu9bI8ju1a9euXfuvx676699/86SjiL+FnD+GvyeGsHWemJ3If6CRnnUF
8f0gdWStJj5AuIwwsy/rGWJ+5dYCMb+lPOuJYQVn7SfG3THfRfxaYha6LYQYZGhZlOSvPPsHxFyO
Jv864rcRk4BFWCLlu5w9DN+Gv+GsK40svBFeCi8ijTtv7E642lCeI9yOsk0iZQ/uPozwrbCXS9qM
28baw95uW+LaMeTzOnwJboK0PfUDSFtVj1F+6kuNYx3X4O5AcfYI/MilqR1N07Z3kfIUKZkrKi9n
PyGmfxMbNHsS5umsE+TDjMtyiBlOPR7n2h83ZnX4QdrAbfA+OIOUrWGMmDYwQ25niB9FTDfycbWy
nYjvxBji2lrQ362hjCGuPpN1pdXNrU3k4K4szpDbLEgPUrQ0dWOT5M1dfJw9Ch+Bdxja/0iY8cQa
yd2/QkwXNx5OgsNhbyS5lfT0Qas78d2p3yDyCRLDrMzyEC7CLBxPDrsJT4YLKckQwg2U9q9cewkx
syFnFZK3fDwjKxr1F8Yf9lDKWOOXMfMsQzvhuNY7rMXse01Kzztc+1X1sKGxxFPDYb2h3Vc9qXkx
ZJ1iZwi3NLT+bqjuE8c0L6Jd9Xf3UiGzdzWenLuR5x2ExzR207yV8t9EzE3qSjMeEu4Ou5DnxbAC
toG3GbtBfe08M3LCe8iN9qYSxhJPXU8ONXC4oXWludZeJUPC6K9Mmn5igY4R5qw9mpTMxtU0clsG
v821NcYKUXVVrXT4I+ypPsG+6JPGkWaNY2wIVRu1SRgtkynhNjhA90i9Eue+V4lXianW/Aq8EXZj
l22gsUtUtY0v8FwvcMeDpvzyr2Y0NvaE1sfwvKHqb+5ojZJrdPgGYm5o3GHGQML9jJytiwhf3bjR
1KPZWdNrbVOSNtRaT2Npqeeuu2iTZm/6crMiUKxB7MrGnmYehTyHis7CaGyWUrY+vFP6cBdN6/fw
hLEW07mtMrN9Yj7GimwQOXfmLksbWwqzP9vSlB/prcSq8G3sEoeasJ75m7VMW3Mvm1051eXvSxgl
JjMmmH2HlZTqSZOD7a7OBpmwGgOHwFGwPfvILUjpaiy/ZfYr1bXQ1a735I69ebrejbWaVewm9BA1
PO9JeoSmNcXQXtQ4RBid6gIjh7/3M3UE+9K2e7gtnKuG8aSjCY/jjmPc3NgzDZJnAHZHt3MFT+dq
wH7Civ4btNLZjRvMeE54hJimOU8cFsYO80PNBxo17Vupo9saze72bTzvUpOz8zvKvNiUWa/EjUxu
Zh1Xi7RP0cL7mhhPW8JnKWFvaq0HtbZFTBfGfsnU0TiuetoYweo6MjVYz7OMpL7ijbPoEWbE8JPP
AO44ktzuRs4DkW13WMfZEbCjWek446nZAbSKGlgNu8Ir0T12hXdy1Y2wFn7QpAMx6+KvmvR2wDyR
tdVoSPTY2NbUNdemZdr0VsjaVhWIr6ac7m71Gcr/N5ODXTI9S/eCXdDkvwDJjOOJnkCedzYuFkYz
bPYHLdr/WZO/9QGcy/i8mKe7ltL2YHxoDXsbWuWs329Fq3MTaQbCy+A1SLs/JRlGzKWUQZiatdJ/
3254fhrSMOX8lPJ/CDvLKvqCuaoN+aRomV2JuQXez1v7Gc5+xDhwA/HVYqt+ui6ig+ZYdE1teE89
aGy51bUybPqIoVXVaEbv7kh1mEmvhmH/+Rbhe+F00SiMTtXk1t+ktI8TP1ZWml5jqOVmwjcT3kP4
OG3vdlMS9Qa8nbOvmDLrNmDa5NTGvuZs48WUKmbqGtaISzUHm7D9EjE3cscbCV9N+CLYwyXxXblv
a1hPfDd4H2cbxEXCWOPcbfqg7K5rbd35vwuzg9DBzCJIeQMcJL5DPZrn/Rd5BfLsALUc9BvNxD8s
PjAlJNySsz25bzXxtzT6dZ7SUI9U5mx/Un6HcA1p6mEvcYsweqoOjCew8XL4T2bMIT3x+l0Qo52b
MDWrhhIzytC6RGSYmWQZnQxT5PaE+IvmDqNxUjeRvq95R6g8ZWtFPq/DMfJ+YTROJjwVzjHX2u0b
39DhS7i2FTXS2rQlZ5WRnpUn5TVIrDd37Mnd3yB8AsuotqTxNbUuU9q3yG2gqQX1sbyI9mzOzoaP
wWWU87twBjGjkGGDvMasGQ2tPY1tzL3g64aqFzl3gdXyEs128FLYGvZqTJj5G/X1FDl/Cy6FX4f/
6NYU+bSB3Sn5rMbPNHOUqoo0X2mU9CbuiLSvaLxTswWsMlR/b6rZomY70+Z1TV1peP5ZffZicn6T
NJebetT3vUcYW6kOtBDD9uRfBdtRCw8jjfs525L4AfAyeD+j6CE3ZVP89bRtU6fVxFe67aHpLbyL
qzoau0RmVqvN+Oa9ijB6V287wr+GPzf02sxM2D33osez0aN6XXuYc9j8nGMejmWFx7U/YXfAnu2S
FdNs1gVo+z3szZWjbywjfTl7QPZyUi4nN2x47OtdEn+amfMctA2sHRx2HMrY9fNiiedlx0EtIyUr
WYXuwnEthZiTe1hjeu6BjP8edjm9aHqdyS7NWe8xyErf+yx3RLvuoFVwXE0C2mOH9ZcX6w7P48Sz
znXQJNisoewfsdb4k/sWI2arS/O8HreErF4ddtO8rn4VK2v7Bu7uyvMO0rg7dwuRFXoDm3VlGXY4
nl/zdFg6edHGKzQ8aj7xrM0Vmhx1MXT1Bq7uYharJI+7eiXn2yB6AHsCnMob80rCrJ1VC8Kd4WDO
Nq2aWffFjJZDLXC1x6RBs2G/SHmoLxtNi4c9C+cXxLj7uXzP4kH/70Vr7cVexYudhhdNtQfJeIh3
sFZy3D0aasfDLo8HTZeXXRgvlvAeLItsVtC2u894ObLlSZ1XiR9pas12d6xqWPf9Gro1S0t2epoY
Lzpt7yLO1tOuXHv+x6g7dF/OUOLdVjSMGNaPXvQDXvZtPe7e30Ti0cx73a+BdrjkLDtW3m9zL9ab
NrtFui2Zs7QxD3Jz2HP3vEU82huH2bvHtRx7j2v/gbOsnR0LKu6O5Y93AjHsC3hY+3vd7y/crydo
CR7OOg8iE7RV1nGXrLIfJfwcmpanifkhMT+GfyTG1fWtg3Mgug6nD3mWEYP+xx5OPJpGhSZEof2z
0fl4vg0XkGaFuaN9P2fHQ/q1jabOvsolPcit92nETIEPQTR+FnVt0b/Uz+HvKHNfZlzurpyr+URP
5aA5sQ7AH7hknvkDRoATXNUVyaMPtOub2GDWC4RHQMYoGwlYlMpBy2S5mj1Ka6ElsO+nla6hpmif
1jre0S9yly0QfYj9AGnQ59g/g5upQcpgPUpMijR/Jh90NfYTkJZs94NXcRXrApv9ZRtdsf1Vxnl3
7+kjl+T8EfGMsWWMXXaK9CkkiV2ihT2V9RvynAF/75LRFYsRxehnr2CEQZNjr6W070I0fh52AG16
io3k7acobaPb2snhHxh16XfOa8R34qqjcCYx34ETmp7atN6nuBZbDtsd/a7k7JW0It4Ujjtu02c9
riXqO9T7O5SQ96b5klWY/Q7Bfodgj8OkZLfL61o2fg/57yf/y+BSnoK9Ng91ah2DH3AWK0H7j4S/
D1fDbcRvJPxdcqBfe9zvg14m/rfEYwXnYVfaQxkcNH6eedwF/aTD/rXjWiaXiHH31gPk8yacxlWv
chY9vAcdpoU1pgerD4/7xdmT5LyaPstIXs6eYzk70eXsQXsZY+1vIu1DpHTfnudEmDnGLhg2Mwpj
Za3nEmYnazlnf8/+KZZCHuTgYffWS3vzYqfhde1SBrvvVq4aDhvg3Yb6bWu4kJjpcC2cYajfuWHz
zoW7DfU716y/uErNJ570ei1jrjpE+GJ4CxwCZxlaHsKPkfI2+AycAKdy9kr4MDHDCLeAlNbuDAcT
054847A3MZRW8RT6jWw4mrOKq56Ab8AbiO9D+ZcRMxJ+Bd7JtS9w9jPk8wvCj3O2F2f/CI+QjwOJ
sQuEP4BbiSmDWbieq5CD1Y/wJeRMSeyvwRy8EV5OSmiPgPcT05NSIT3nVWLu4+w4aNM2erpvbfdN
zZ71fPfdSsxOrh3pvt24aiDsDq+gVEhYt14Tg5TKua9uw2HacBhbkTDzgTDt2aR8Gn6T+DOU7XXu
5do/7EJfsYuYj0yrdlzbLdd6ljZgvUYa2oDl2gnfTNittVGQNmAhJasrvAmOIedJlOF22A050+bV
Q8T8E2HkqaZxFW1Sr3MN3VZHe1APwCnwMvgypC1ZddBtY9cTj2QUZbDclt8F3gpppdYAeA10z7p9
qiW8C9JPVYI09DWLOrIov0Ke9nhi6HeWW3ffhhJSKr0eNPwZXELKIuwEqUH1IWF6ltUOuk+9DZKz
cuORg8WzWO6TfkyYdqt+T9iNOQ+PmlZnYV1v0TItVk/W7whfCy+CtDqLEcP5A7ndy1OsIoYyl7nP
Qgu0/0xMG8j44NDXHPqsw9jiID1vgPTPEkML8aaa2uTVZo6Bbm2SCduDKNsp3uPbXZr2WcbuQ1k7
o+0sYz6gOV2Y7xBNDotMDl6sWz3YGklsaSQrAul+U4wdlIMNjIf+6HFte3hL2l2aqPP30B+VO2f4
A6XifWRjseZxv4diHWG57dYLn4c/gRvgt3hqxgRrI089qIkdsGIyfdOPPCsh/cuh/Sh6k3Lrxe0L
Jcg4ptze1BpWwXL4pKGk7qzN8DliKKdk9JDu2MXII2nnkn4k3XLyDrIYtyX3lTVwEaRs8nvQ7UGv
wb/APfAlnitMeCwScMdYatz5Z2J4lzn0BeX231aED0JGLYs0EpmoLYQZYyVvMYf25qG1eFhTe3j7
O+739Xw7YKNRd9gj9rBm8bp1zXcZupxmfCMfqxryBrSQj81zORHuvoJ4ZOUhN8e17HqU8RwbM4dv
FjxYNXiwN/a4X0C7872/ci3zAQ8Wyx7XLitJzpN5Lnqf48qZUUUhE4drLUZ4+xPi6bNlbutCMl7e
j2VIW/Hmctw3b57wWe7ujnuMD3q+ZML7yeFFYtx3mWuFyNxMud9fsyJWWN5aWN5arp8HxhOFBbLi
uWzX0hs7NIXllXK/S3K/gXK/eUGHY6N/sNw9TVc+aCcsdKd6PtCBNCY8FA6Hz8LrYBIm4BSIFsva
beigU7XQGVqXQjSuVhiWw2vgAHgbGrA/EV4EXW0eGkg9W+iAzDvwFujA2NuBWjPxZwmje7QkMY1c
FSTmHGFSWmgmrfGwgfiVhEfCtdDVT1IePS3twFvVEC207puGro70Zu51ivBeOMbVbRJuD9tA9NhW
ADowA/vC77uaW1cHSA7TCP+Ns+gP7Z8SRmeux70OvDENP4DfJM2LXPUa/Bh+yFkvRENuPwDRxOr5
mImPw8XwHsh+gfU4fBfOgpTK5qltV0qktB+ClNNC56z7tSE6Tz3DMfwlfIaUHQm7T9QOToc8u8VT
6PGqA3PRDoxgJnwxT8TcycM+URm6oDIsE8rwa+HF7tfr+iUoYOPt+kNAA+bBtt/qyMpiElbKb7Fu
PciaDmtbx/0Cgm8JPe7XZAtJydfH8iVDD9bRXkYYx/XE8i2+I0D75BnHNxHYyqquJuzw/axzirDr
r2Nd06r/ETPbxBb6RSzVWb/IuVhTV1D+IHe/G94L/wk+DudDbMvla+RDGouns7aTD/nLleaOOo3h
AmLOc/YNUmJjbw1iBzZFfB7b9VFwNGdnwIdcy21ycL/Pcr/Fc2XOHNVh/eX0htiNe7Cpdpg/OHxd
4rhfFD6EnuRv1IIf/or8fw73UJJ97HzNMDptiTWaREMlsUHyMrtQ71OD7nd5rh8P19aUVbCzkfSu
9uxHSP4R7vU8rQILFok1muR94XXfL3wtKJej/WZEdVhFykZ35KRsrGqtcYS7QDSK1hrCbeFa+FOY
g+d4unsgNWtJ4s9CZKt28pUuugVdF7qdyBXU3ZtwD2T09mBH7UHT7qCRsPaSZ4i6u83sJ+qxUc+p
rNsNHb58UTWwW1P91mneQswxrn0PfkSMSzSo6jjh/fAb6AF4dgs7W8e1FbyNlkyvlNgSy5dpLa9y
1VbSu19kCGrEIr37/RHPItFEeZhJqu3UVy3lnMC1yFD+jnC9+d5Z/nPT8xrJcy/7MtoD35jID7nX
X5vO6vQe1/bgMTwGoHGS+5Ce6yloG+Vxv35yv5M6xl2+y10u4u4L3X5K+mry5IseD9oM6e6GPEn/
dZ/R5qqDrtWQOxqQMzKXaJ/kvRAtq6R3WO3Iwf02qhO9AE2RMx/bzra0zE3YwLAfYbdgjHK/nVmH
ZctZ8mT/RfL1lnwf2WKDpL7L1+LvUB70QpIVqPVncm7H2f48O1o76X5tfTPPSwkd7IskOmfJdwry
+6bM5djYe/kmy8YyymM0mQI/WwH9M0yOEkpcoUMrm3z/KrnefMUnN8ofC0tukj8xvVG+oMOb5Yv4
DPypDr8kXzZPgvfUrdKU7FW5XYdfkzt0+HVdEkv+Quo1v3xD7tbhN411r/yl3KvDv9K1rEd8PYZY
8tfSSOo38qAOvy2N17PfysM6/I6Wv8RXmyV/J3+nw+/Kozr8L+obWl7G96ClHlWPmnmVnllZ6jHL
vJ866hmOZXWy1xg9jv2MsOy19lod/qH9vA6/YL+gw8bbm2X/zP6ZDm+139fhP9h/0OFjjhCWI6Nf
EzI6OfqosKLzYgUhY8XYXcKKTUhsFjLxYkKXLfFOVl+b3Zp9Q1jZ3Tk9GuLlz8pdljPe1uwm6Spx
P74WJV5nVZPHReN7VuF38XMPtMb7osQPrcIHo8QbrcITo8QnrcIfo8QzrcIro8Q/rcI3o8RLrcJD
o8RXrcJPo8RjrWqSofF3Z8mj2FcZ6blyk3hulHi1VUhM4r/xc894xovj5xIz/vEs/ONZ+HWUeMmz
8O4o8ZVn4eNR4jHPwtOjxG+ehb9Hib9Hib9HiQddhddHiR9dhe9HiTddhQdIiU9dhR9IiWddhTdI
iX9dhU9IiZddhWdIia9dhX9Iicddhb8+C7+7Cr+7Cr+REu+7Cj9+Fj4kJZ54FZ54Ff4kJf54FV4l
JV55FR7/LDxMSjz0KvxMSvz0KrxNSrz1KnxOSnz2KjxPSjz3KvxPSvz3KrxQSrz4KrwIWniklHj0
VXgUtPBOKfFOKfFOKfFOKfFOKfFOKfFOKfFOKfFOKfFOKfFOKfEMrPBRKfEPrPBUKfESrPBXKfEV
rPBaKfEYrPBdKfEbrGjb0vXLJyeU1Qhr9AOTJ4r4uMl33i2mTbxj6iSxxnz/dHNdn5LoKkRjo4jp
kcUjMqIkosLoKLqKnuJaMVgYO/CBYqQYKyaKyWJ6U9qg8IqsaKFD7cXleiTqJfqLW4xvHHGjuEOM
E/eIKeIBepWbPiTKRE5UCTNb7iK6iavEdWKIGK772yAxCi/pU8UMkRTWdYMG9Rf96m68oSSGD667
viQWkIPRzpaLvLhIJERHcaXoLfqJAWKo+KqwxCXiJjFa3CXuFfeJB0ldLipFS53bpaJaXC2uF63F
TOITIqKfuiAuFinRSXxFdBd9xDWiVtSLEbqsbUSdXk9PEA1imnio6a4Vwi+KopVIi8tED9FX1Igb
xK3iduGItuJmcae4W3xN3C9miYdHd54yWp0ztGwYgHGYhy1H3zFxqtUedoW94QA4GI4YfceUO63x
cBKcCmfA2XDu6NH3NFgL4Cr4PNwFj8BThrYaM+nee+w4zMISbAXbw86w29jJd4y2e8EBcAgcBSfB
GXDuxLvG3WEvhsvharhu4qT77rE3wS1wK9wBd8N98ODEe0dPtI/A9+AJeEqfnGx/Cs8ZOgqWwRCM
w+y9+scpwVawPewMu8FesN+9k8dMcgbAQXBIg4kfDkfB8XASnApnwNlTdI04c+ECuBgugyvhU1Pu
mjTWWQc3ws3wFbgd7ppyz+gGZy88BN+DJ+Gnhh4xZUqnyzw+GIVZWAXbws6anT3VsDesgbWwDtZr
Xu4ZAcfCSXAanAXnTrmvYYpnIVwCl8NVcA1cP1VLwLMJboFb4Q64G+6DB3lrpkXmP/Fr6ZGjSlz0
fxUy/nj/I5bp3uzo0cyrQ+W6x/v/H8R5vxD3bzEXppEi9CVpdjwierSJ/heGlR4DL/4//EqR+tJU
XKcEqwreK+Z/w+CXZvJLs/S/MfGl2epLMPYf0tJvtzx/jefLh3I6VEBO5i/4fPlfKdr8h1T6fdPu
P/ErRfFLMP6l2F2/9eeJZWKt2CJ2iUPiuDgjW8muskYOkWPlNDlXLpVr9Dpjp57HHpOfKo9Kqlaq
q6pRQ9RYNU3PXJeqNWqb+tDKW+2tHlatNdyaaM20FlgrrPXWK9Ye64h10jpnB+y83d7uYdfaw+2J
9kyB1xhR5rY3O9DsuNTsuF+z49ovHOt5iD1AeOXnx3pZ6Sy68Njb/gvp9XHZBo5t3TuTulZbubHB
Xk2//Zt+65p+h194dSTyhWPddyLbLyxND3Fhaa8ec+Fxn2Sz47bNjntdeL8+dc2Ox1x4vz6zm12/
vdnx6QuP+45sdrz3wuN+hWbHky6834COFz7/gD0XHl8fvfD66+svPK6raXbcv9nxgAuPb3blo/S4
G3UlcPPwpt/3/716HDyv6Xdx0++Kpt+1/17qIQubfpc1/a5u+t1w4VMPjV9YC0OHXVjK+g3Njrdd
eHzr4mbHS5odL212vLbZ8bovHOuRelizPjFq5xfavA6MntDseMGF6UcvvPD4zmZSv7NZrd05qtlx
s1Z059Rmx9OaHU+/sJWMe/fC8+P1ClvXjK3XF8f1fP8k7yPzF88Ef51MxmKxOG+pqPCknk28nFqf
+Km9Qa+MlXDkBrlBZ+Wu7TfJTU1re4uVku3mq0enDmgjlNEUyr20KH1v9Zm5vzI6ko76OKnXDpPF
CrFTHBVnZVyXoUxfHU+9IFRqfWqz5rOpFzVNbUf0jKekR3nzd6F6JN7Wq/k39PrwEL8vJ36rf3+p
jw/z+3JCr9z00W7NlxNv6rX9b3XJTIvOiqrEr/SKfIM+u4/flxNv6d/n9PF+fl/+QspfN6U80JTy
N00pDzalbCqvXpmau/2cu73K3T4/8xpnXufML754JvUcz7iRZ/wxz/j5mU2c+QlnnueMEh75mnxN
S93Vihh9iKsJsagVO7Uu9SPdT9w5hem3XUwtCyN/RzwuzP73Tv1PRt+MamnEl8aX6tX104mnqa//
+ZsY/x1/E+Pf6ipLXXWipy6IT/mfGvlvqxHjaV0y4zc1cpmuic7/VTWB9ANIP6il/6yuCSP9mJb+
IRFH+hmkn0X6lUi/hPRbIP2OSP9SpN8J6V+G9Dsj/cuRfhek/xWk3xXpX4H0uyH9K5F+NdLvjvR7
IP2eSL8X0r8K6fdG+lcj/T5IsC8S7IcEr0GCNUjwWiTYHwlep+W1SI8oxgLyEf3vYTFX/5utZ7zz
xNfFfLFQn9kgnhOP8hczH2NEmq/nwbv0+GT+YuYC/mLmN8WfxAnxhLSlI/5Rfk/+QDwp18ofiWXo
kVegQf4uuuOVaI2/h754FZri76MjXo12+AfohZ9CI/w0uuA1Kq96iGdUL3WV2KWuVleL3aqv6ive
VNeoGrFHXaeuE3tVraoVv1K3qFvEPjVUDRVvqSfUdrFf7VA7pEe9rd6WXvUH9QdZpj5WH8ty9Yn6
RPrUZ+oz6efvWgYc6dgy6Hgdr6xwyp1yGXX8jl/GnKATkXEn4SRkmr96mTFaYJk1+l+ZM5pfmTc6
X1lptL2yYPS8smg0vLJkdLuyhdHqyqrovOgL8iL9ho7Jm2KpWEbWxQqxanmL0erKyUaTK6fE+sTq
5FSjw5XfMNpbOddobOWjRlcr5xktrXzM6GflfKOZlY8bnaxcYLSx8ptGAysXxibEq+QT8Zbxlqp/
vFX8EnVdvG28vbo+fmn8UjUw3jneWd0Y7xavVoPM38pUN8dvj49Ug+N3xe9SQ+IT4xPV0PiU+BRV
H58ef0DdGn8wPkvdFt8X36duj/86fkCNjJ+Pn1ejEnqpqUYnVEKpMQn9n7ozkU6k1djEdxLfUeMS
3018T41PrE78QN1t3lbqnsTaxFo1KbEh8Zy6N/FO4j31tcTxxHH1QOJMcrKakZqa+qH6S+rnaWW1
SwfSAevedDadtRrSLdMtra+le6Z7WZPT304vt6amV6RXWtPST6efth5IP5N+xpqR3pB+znow/eP0
Juuh9AvpF6yH0y+lX7Fmp7emt1r/kH4t/Zr1SHpneo/1jfTe9K+sBem30r+xFqY/S39mPZk+lz5n
Lcn0y9RY38rUZeqsZZn6zDDr25nhma9aKzKjM6OtlZm7MndZ38tMykyyVmUaMg3W97Mbs5ut1UZD
bf3Q6KatdUYrbf3I6KOt9UYTbT1rdNDWhuwvs+9Yz+Vqc7XWVjNKiXr9f/+mUapz05ukq/6/5n/F
SPNtsGjZLI152+xqitGzO/tD+yM9Rf/YPs1cL+f2XXrJw7T6VY7lWOKAacviN6Yti4OmLYu3dVsO
ikNO2AmL35oWLQ6bFi3eMW1THKFt+mibft2OijJkalvuMLUtXze1LXea2pa/MLUtd5ma1LM4XYfy
Leqw1tShmmMkpHaap1e/NE+vjuhSDmZsEYwtkrFFMbZYjC1ljC0+xhY/Y0uAsSXI2BJibIkwtkQZ
W+KMLRnGhErGhCJjQokxoQVjwkWMCS0ZEy5mTGhlRgNxiRkNRGszGog2ZjQQbc1oINqZ0UC0N6OB
6OCYv6jR0bEdW3RyQk5IXOZEnIjorPtsQVweL8WrRBfTy8QVppeJbqaXiWrTy0RP08tEL9PLxFWm
l4k+ppeJvqaXiWtMLxM1ppeJa00vE/1NLxMDTC8TA00v0+9D3Y/0m1D3I1Fn+pG4hVnfUNOPRL3p
R+JW04PEbaa/iOGmv4ivmv4iRpj+Im43/UXcYfqLGG36ixhr+osYZ/qLGG/6i5hg+ouYaPqLuMf0
F9Fg+ov4mukvYrLpL+IB01/Eg6a/iNmmv4ivm/4i5pj+Ir5h+ouYa/qLeMz0F/G46S9igekv4pum
v1DDUuS/8H6+3Kwu7Dfxxv3/R+uVl5yy3ypfW76h/Pnyl8q3le8s31O+v/xQ+dHyY+Uny0+Xnyk/
77N9Pl/El/TlfVW+1r6Ovi6+al9vX42v1lfnq/eN8I3xTfA1+Kb5Zvrm+Ob5FvqW+Jb7VvnW+Nb7
Nvm2+Lb6dvh2+/b5DvqO+N7zHfd96PvEd9Yv/B5/wB/1p/0Ff0t/W38nf1d/D38ff3//QP9g/zD/
SP9Y/0T/ZP90/yz/I/75/kX+pf4V/tX+tf4N/uf9L/m3+Xf69/oP+A/7j/qP+U/6T/vP+M8H7IAv
EAkkA/lAVaB1oGOgS6A60DtQE6gN1AXqAyMCYwITAg2BaYGZgTmBeYGFgSWB5YFVgTWB9YFNgS2B
rYEdgd2BfYGDgSOB9wLHAx8GPgmcDYqgJxgIRoPpYCHYMtg22CnYNdgj2CfYPzgwODg4LDgyODY4
MTg5OD04K/hIcH5wUXBpcEVwdXBdcGNwc/CV4PbgruDe4IHg4eDR4LHgyeDp4Jng+ZAd8oUioWQo
H6oKtQ51DHUJVYd6h2pCtaG6UH1oRGhMaEKoITQtNDM0JzQvtDC0JLQ8tCq0JrQ+tCm0JbQ1tCO0
O7QvdDB0JPRe6Hjow9AnobNhEfaEA+FoOB0uhFuG24Y7hbuGe4T7hPuHB4YHh4eFR4bHhieGJ4en
h2eFHwnPDy8KLw2vCK8Orw1vCD8ffim8LbwzvCe8P3wo/G74/fCJ8Knwp+FzERUpi4Qi8Ug2Uoq0
irSPdI50i/SK9IsMiAyKDIkMj4yKjI9MikyNzIjMjsyNLIgsjiyLrIysiayPbIpsiWyN7IzsieyP
HIq8G3k/ciJyKnImcr7CrvBVRCqSFfmKqorWFZ0qulb0qOhT0b9iYMXgimEVIyvGVkysmFwxvWJW
xSMV8ysWVSytWFGxumJtxYaKzRWvVGyv2FWxt+JgxZGK9yqOV3xY8UnF2aiIlkVD0Xg0Gy1FW0Xb
RztHu0V7R2uitdG6aH10RHRMdEK0Qc9uZurZy7zowuiS6PLoquia6PropuiW6Nbozuie6P7ooei7
0WPRk9HT0TPR8zE75otFYmk9LraMtY11inXV85k+sf6xQXr+MlzPSsfHJsWmxmbEZsfmxhbEFseW
xVbGnoqti22MbY69Etse2x3bHzscey92InY6diZ2Pm7HffFIPBnPx6vireMd413i1fHe8Zp4bbwu
Xh8fER8TnxBv0OPm7Pjc+ML4kvjy+Kr4mvj6+Kb4lvjW+I74bj2OHoofjR+Ln4yfjp+Jn0/YCV8i
kkgm8omWibaJTomuiR6JfokBiUGJIYnhiVGJ8YlJiamJGYk5ifmJxYnliVWJNYn1iU2JlxLbEjsT
exIHEkcS7ydOJE4lPk2cS6pkWTKUTCYLyZbJtslOya7JHsk+yf7JgcnByWHJkcmxyYnJyckZyTnJ
+cnFyeXJ1cm1yQ3J55MvJbcldyb3JPcnDyXfTb6fPJE8lfw0eS6lUmWpUCqeyqZKqVapjqmuqR6p
fqkBqUGpIanhqVGp8alJenSakZqTmp9alFqaWpFanVqb2pB6PvVSaltqZ2pP6kDqcOpo6ljqZOqT
1Nm0SHv0OyGaTpu/BJ5um+6crk73SQ9ID0oPSQ9Pj0pPSDekp6Vnph9JL0gvTi9Lr0w/lV6X3pje
rN8AetxP708fSr+bfj99In0q/Wn6XEZlyjKhTDyTzZQyrTLtM50z3TK99DugNjNYj/tjMhMzUzMz
MrMzczMLMoszyzIrM09l1mU2ZjZnXslsz+zK7M0cyBzOHM0cy5zMnM6czapsWTaSTWbz2aps62zH
bJdsdbZ3tiZbm63LDsuOyo7PTspOzc7Izs7OzS7ILs4uy67Mrsmuz27KbtErmp3ZPdn92UPZd7Pv
Z09kT2U/zZ7L2blALp7L56pyrXMdc11yPXJ9cv1zA3NDciNyY3ITcg25abmZuTm5eblFuWW5lbmn
cutyG3Obc6/ktud25fbmDuQO547mjuVO5k7nzuTO5+28Lx/JJ/P5fFW+db5jvku+Ot87X5Ovzdfl
6/Mj8mPzk/LT8rPyc/ML80vzK/NP5dflN+Y351/Jb8/vyu/NH8gfzh/NH8ufzJ/On8mfr7QrfZWR
ymRlvrKqsnVlx8ouldWVvSv7Vw6qrK8cWTm+sqFyeuXsyrmVCyoXVy6rXFn5VOW6yo2Vmytfqdxe
uatyb+WBysOVRyuPVZ6sPF15pvJ8wS74CpFCspAvVBVaFzoWuhSqC70LNYXaQl2hvjCiMKYwodBQ
mFaYWZhTmFdYWFhSWF5YVVhb2FjYUthW2FXYVzhUOFo4VjhZOF04UzhftIu+YqSYLOaLVcXWxY7F
LsXqYu9iTbG2WFesL44ojilOLE4tziw+UlxQXFJcUXyquL74fPGV4vbiruLe4oHi4eLR4rHiyeLp
4pni+ZJd8pUipWQpX6oqtS51LHUpVZd6l2pKtaW6Un1pRGlMaUKpoTStNLM0pzSvtLC0pLS8tKq0
prS+tKm0pbS1tKO0u7SvdLB0pPRe6Xjpw9InpbMtRAtPi0CLaIt/pe5bwKMqsnXrsTuEkA6ke9eu
3U0I6U6nGyPyCvISQWMggATQoEZEBIyIISIiECC8BOSlPAXCSwRG0HEU0eMDFVEQEkBk1KMoiILI
ICKiIigi6qn6d/mYO947c6/nfOce+/Ov1atWrbVq7eqqtTq9N24kMxKL5EaaRVpF2kfyI10iPSK9
I30i/SODIuWR4ZHRkQmRqZFZkXmRxZEVkTWRRyLrI09HNkW2RXZH3o4ciByJnIicjpyPWtHUaCDq
RjOjsWhutFm0VbR9ND/aJdoj2jvaJ9o/Ojg6LDo6Oik6IzovuiS6Krou+lj0qejG6Obotuiu6BvR
vdED0cPRY9GT0dPRc9kkOyk7NTuQ7WZnZseyc7ObZbfKbp+dn90lu1d2SXb/7MHZw7JHZ0/KnpE9
J3th9rLsVdnrsh/Lfip7Y/bm7G3Zu7LfyN6bfSD7cPax7JPZp7PPx1gsOZamUstwLCsWjzWOtYi1
iXWIFcS6xXrFro31jQ2MDY4NjY2IjY1Nik2L3RdbEFsSWxl7KPZobEPs2dim2NbYjtie2Nux/bFD
saOxE7HTsfM5Vk5qjp2TkRPLaZzTIqdNToecgpxuOb1yrs3pmzMwpyxneM7YnMk5s3IW5CzLWZPz
SM76nKdzXsh5Jac6Z3fOWznv5RzKOZbzZc7ZOIknx+vF3XhmPBbPjTeLt4q3j+fHu8R7xK+N94sP
ig+Nj4pPiE+Lz4kvjC+Lr4qviz8Wfyq+Mb45vi2+K/5GfG/8QPxw/Fj8ZPx0/FyCJJISqYlAwk1k
JmKJ3ESzRKtE+0R+okuiR6J3ok+if2JQojwxPDE6MSExNTErMS+xOLEisSbxSGJ94unEC4lXEtWJ
3Ym3Eu8lPkwcSRxX2aSlf7Om8Bng88CtwGrgLuAe4FsqM1UI2UbAJIPPA18C7ldYC3QydCdDJhky
yYZfDdwF3APUo1IgkwJOiuEcVFgH/FRoS4W2VMPZCqwG7gLuAeqxfsikQUNdjKoLOh10OjxJh4Z0
8APQH0BvAGMD6A1AfwD6A9Af0L+9IzdCUhh8Caj1OOA40OCA74AvQUvQLmy5kHQh6cKWC1subLmw
5erf/CnUFsMYFcaoMEaFIZ8Bfgb4GeBngN8AnAaw2wAxmUI3AJ8GbgRuAW4H7gS+DnxTXW2FkH0Y
eI/BjcBNwH0Kp0PrdPROR+909E6H1unQOh1ap0N+JmRmgjPTcA7p6ha+10BbDbTVQLIGPtZAWw20
1eixdVLROxsRnYO5zgE9D2PnwYd5GDsP/PnQPB+98zF2PnrnQ/N8aJ4Pr+bTdxR+CMmFBjcBtZ5F
4CyChkXgLwJ/MbAKVqogUwWZKlipgpUqWKmClSoVY43a1lKMWopRSzFqKeSXg78c/OXgLwd/BTgr
YH2FjiFN0pIKnwZuBG4BbgfuBL4OVNdWI2RzgckGNwI3AbXW2qBToDsFMimQSTH87cCdwNeBehSu
jMLXgR5HxYb6wU+DtjRoSzOcLcDtwJ3A14F6bF3I1IOGdIzCJ5YGQQfhSRAaguDb0G+j18ZYG702
9NvQb0O/rWNPb4KkNLgJqPW44LjQ4ILvgh8CHQIdhq0wJMOQDMNWGLbCsBWGrbC+2gq1xQyMysCo
DIzKgHwm+JngZ4KfCX5DcBrCbkMdExbTn3DWFJjHpim8FJgPLAAWeqg1KHqGwiJwij0Evxj8EnBK
gYOBZcByDyE5HHSFh+BUgq7Sf/1kC/Tnjy3UO5FC7dWzwCpwlqJ3DSRf400UVusZsR16vgq3//z5
Zq+B8zp692pJTiD/vVl7G35edbwhkGgOZ7qX19GSxApMB44CjgaOBY4DTsAp9ryRmgScDJwKnIb+
PehPNqh1JWOHTobGZGhMhsZkaEw2GlMhmwo6YHAUcDRwLHAcUI8LeOMCa3WEFD6pEb+ZXqvtKVrr
cA1q/uOQfBySjxvOVtBaJsPgKJwC2uMp4EwJjARWAMcAK4Hjsc9vNFITgXcDpwDvQf/r6J9ucCT2
8i2gK4BjgJVArXG60VgD2XtBzzc4ElgBHAOsBOpx871xgX/XV1ThBo16hKK3gNY6qgxq/vuQfB+S
7xvOFtBaZrnBkdg5sR9qjsKRwArgGGAlcDz2xo1GaiLwbuAU4D3oRzxoisGRWJVbQFcAxwArgVpj
itGYBtk00LbBkcAK4BhgJVCPs71xQX2nlMYNGvWIoL4zWNNaR9ig5teGZG1I1jacLaC1TKbBkdhb
9BW0kB+kAgNAV9/toXMRfUcH2mdM+zP/SXxGvH6L7ke+0giYAg1pGoOrNCc4E5wUk3Uh2wxGgTH9
6QGdDDoVdCroAOgAaAFagHZBu6DrQLOl7yPRWRq8UTmbydQ8rudbhpfHWi8T/bsOnQn5sC581g6F
TeBbLS9zBb8W+LVwnteytuHzvQuz1i3yWcXVWKNmuAmZWm2Tse6CZ5quA111kIvVsfQel6rkuc5Y
oSPNQ0ilwWJdfR+DylN3gVfX48FSPcjWg9566E0Hne7RkEyHpzoCz5i2Gq3necB4HjSoRwsPYVUh
fBfQ5aDHQY+ioVG3L3ktrErISI/GKAlfXWszsAa4DWtmq1lDuxCNEHamEEaGoQUrmNQHXd9ktZpu
gJywAXobwMYU5Dw1wPnAKv13ap1fqdPWa5827c/8DdjDdqoTw2t1zvkwMrGZ0DBbryS7m+aIZzRH
5Zab0Otlksiarb8AH9d7HOjpoGtA14CeD3o+6IWgF4KuAl0FehZW7RS6D7ud57PKQ0326XH34d1y
Lx/Hqp2KCExFBB6HV9PAmQbONKzUaYi1yrcxX90iI8c1ma6vhn0z8s4ZOrL8DcR3JmzMgq5ZiPss
rNR7cfVqsF5rEFEdJb1yZkN2NuzOwfqYY1bOHI8He3MxYi4iPRcj5oGe59GQnAd/9dyfNu12tBtM
TDz/FxjUoxd6CKsKaQ0irHUtQs8i9KicHHFU7+i7ROflum8xLC+G9GL4WIV1WoWZVsGXKuNLFdYK
I0uwQy7ByKXQshT0MtDLTIau6RXIzVegdwVszPIsQWYpMv3lwCnW5wqP6+gHM3HnVhLyujSgDQzj
lxdhb3Xo7FJHBu9/5m/AKeT1J3nrRWXyO5Fpb0K2rFCka459DpxUky2jStDrUeHj+nwCnQI6DXQa
aBu0DVqClqDDoMOg/dCcpKOts2t4Y3trWbUe1/Mt06s/9FqmtZDVY6el2GlpM/hW26s4wK8Nfm3k
2LX1tdFVBmad4q0L5fE2oLp64iJk2HVMpbETnmnaD11+5NB+C9WFXtG60oCOeh5Cqh4s6v2Ua9Rr
i6Z7PFgKQDYAvcjsVCw1HfRoSAbhqe2tIrTb0W4wkXkavgloEhgtPYRVSXdCF/ZSVWvoHhc9rrei
NQ8SIfSFPBrSIfgY1itaYQ1wG9aK50vYW9G0PrKU+hiZAS3IGGkD0A1MFbIPdYauPxqityFs+D1L
kMlANZMJTMKKrtGSrClqAq8u+W2tkCGeA24GvgLcCtwI3AasBu4AvgDcpFHvLgr3aNT3ImpU+rx2
s2lfMe1W02407TbTVptWaXf82huFm4GvALcCNwK3AauB2psseJ8F77PgfRb8zoLfWfA7Cx5nweMo
5KOQj0I+itlGMSqKUVGMikJ/FGOj3ljMMGpmGDUzjJoZRs0Mo2aGUTPDqJlh1MywOWbYHDNsjhk2
xwybY4bNMcPmmGFzeBCDxzF4HIPHMXgcg8cxeByDxzEj/wJwE2rRXUB9fXKhJxd6cqEnFxpyoSEX
GnIxNhdjG6O3qcFtQFS2sNIUkk0h2RRWmsJKHqzkwUoerOTB2zzoyYOePOjJg5486MmDnjzEN8/E
N8/EN8/EN8/EN8/EN8/EN8/EN8/EtwzxLUN8yxDfMsS3DPEtQ3zLEN8yeHCptV6j/gWtwpeBW8B/
AvSrwO3AGuDzwBchoyv+S/XeofB1cPQclE6vFS+Z9mXTbjH9T5j3r5p2u2lrTPu8aV808vtUy1g+
fM2Hr/nwNR9e5sPLfHiZD//y4V8B5AsgXwD5AsytAKMKMKoAowowtwKMLTBj1dycB7UG50GtQeHL
wC3gPwH6VeB2YA3weeCLkNHRKYQPhfChED4UwodC+FAIHwrhQyF8KNS/nFa4C/ga8HngixgFnYh4
ISJeBP1F0F8E/UXQXATNRdBcBA1F0NAT8j0hUwy6GGOLMbYYvhV7vdBQDA3F8K0YvhXDt2L4VgzN
xdBcDN+K4VsxfCuB/hLoL4H+Eugvgf4S6C+B/hLoL4G2EmgrgbYSXP8Ss55KzHoqMeupxKynErOe
Ssx6KjHrqcSspxKznkrMeiox66kU/pXCv1L4Vwr/SuFfKfwrhX+l8K8U/pXCv1L4V4rZlmK2pdBd
anwtNb6WGl9Lja+lxtdS42up8bUUvjLJtE+SaZ8UvgzcAv4ToF8FbgdqnwZjDoMxh8GYw2B4Pxje
D4b3g+H3YPhdBvkyyJdBvgxzLsOoMowqw6gy6C/D2DIzdh9Q+1tm5llm5llm5llm5llm5llm5llm
5llm5pnAPBOYZwLzTGCeCcwzgXkmMM8E/CiH3+Xwuxx+l8PvcvhdDr/L4Xe5J4+1Wq7WKtffE8Lz
csylHHMp9zi4fuW4fsNhYTgsDIeF4dA9HLqHQ/dwaBgODSMgPwIyFaArMLYCYyvgXYXXCw0V0FAB
7yqgpwJ6KuBJBTypgCeV0FYJbZXQVgltldBWCW2V0FYJbZXQVgltldBWiVhXmmtUaa5RpblGleYa
VZprVGmuUaW5RpXmGg3BNRqCazQE12gIrtEQXKMhuEZDcI2GwA+TA4nnTLvZtK+YdqtpN5p2m2mr
TbsDVsfrE0zhZuArwK3AjcBtwGogchQvLzFWo8Zq1FiNGqtRYzVqrEaN1aixOhdW58LqXFidC6tz
YXUurM6F1bneye2d1sZqnrGaZ6zmGat5xmqesZpnrOYZq6thdTWsrobV1bC6GlZXw+pqWF0Nq4vw
TfVcD5HLLtS0/BvoRcDF5vvtXUBNPwDcAnwMuAa9awy9V+E60I8Cd+Kb7Vc9RJa8Q9PuBaCRr7Nd
5lvxnUBNvwk8AzwE3IvevYZ+R+F+0B8Cf4T+sx6C8wOs3O71An8y36XvBGoafzXiuUABrIPeOoZW
Vnhd0EFUuHNx7xsh+ulrtUlT9UojzYl+YmM70oFIchkpJBmkG+lOYqSHeuknMPQljUg/9WpJ+pNb
yMXkVnIbuYQMIXepESPJRDXiAbKWXE0eIY+RG8gG8pySe568RAaTl8l2cjvZSXaREWS3eo0ie9Sr
grxJ3iajyV7yARlHDqrXVPIROUruIcfU615yQr3uIyfJN2Q2OUt1bZ5FG5HV9ELalDxKm9Pm5Ama
R9uRDbQ9vYxspPm0K3mJdqc9yHbai/YiO2gx7Ud20v60P3mHDqS3kr30NjqEHKC305HkIK2gd5Nj
rA1rQ75ml7D25DS7nt1MvmHj2FRK2RK2hKawJ9gTtA57mj1DU9lz7Dmaxp5nL9C6bDPbTNPZbrab
BtjH7GMaZMfYp9Rmn7HPqMM+ZyepZKfYKRrilFMa5i53aX3egGfSDJ7Fs2gmj/Js2pAneIJGAjMC
D9Go/h0a7RhYH3iLdg68HdhPhwQOBAkdHmTBZFoVTAmm05XBBcEVdF1wZfBB+mRwdXAN/bfg2uBa
+kzwz8Fn6LPB54LP0VeDLwZfpNuCLwVVNRv8a/Aw3RU8Yjv0Q/sSO5+l2wV2Zxayu9hdWYZ9pV3E
Mu2edl8WsfvZ/VhTe6A9kDWzS+3BrLk90Z7IWtl321NYa/seex5rZy+w72ed7UX2U6yL/bT9VzZI
cOFnk0VdUY/NFgERZHOFIxw2X4RFnC0QjUQj9qBoLBqzVaKJaMFWiwJxHVsnrhcj2QuiQsxj74pn
xbPsK3FQHGKnxBfiS3ZanHVS2TdOmtOM13FaOLfxJs4QZyUf5KySlC+TXMb5edlIlllZslyOs26W
E+Qca4ScJ1dZ98g18s/WYrlf7rdWyo/kYetBeUQesVbLo/KYtUYelyestfKk/Np6RJ6RZ6z1bgO3
gfWEm+PGrQ1uI7eR9ZSb6za2/s1t4jaznnVbuK2t5922blvrZXegO9B6xb3NLbO2uOVuufWqO9Qd
Zm1zh7sjrBp3lFtp7XLHu+OtN/BUNR+pR6OsJe9slajPUTuSrz5LV5M+ZCApI8PJWDKZzCILyDKy
hjxKniIvkK3qs/EW2U8Ok+PkFDlHCU2iqaGdhIe2hbaHdqGtDr2Gtia0G+2O0B7VblfUX9FuD72B
tjr0Jtqa0Ftod4TeVm21knsH7fbQXrTVoXfR1oTeQ7sjtF+1NUrufbTbQwfQVoc+QFsT+hDtjtAh
1e5Qch+h3R46jLY69DHamtARtDtC6tRWvf+usDqkzl/Vc1Dhjj8QkaOY+bbQJyYyx0xkPjWROW4i
85mJzAkTkc9NRE6aiHxpIvKVicgpE5GvTUROm4h8YyLyrYnIWROR70xEzpmInDcR+cFE5EcTkZ+8
iISJicjf1Py3hb5ARM4gIt//sYiEmReRMPciEra8iIR9XkTCSV5EwsleRMK1vbUSTvEiE67jRSac
6kUm7PciE07zIhOu60UkXM+LSDjgRSQc9CIStr2IhIUXkbDjRSTsehEJh7yIhMNeRML1TUQyvIiE
qY5IuJZeKeF0HZGw/IMRyTQRaWgikmUiEjERiZqIxExEckxE4iYiCRORRiYiuSYiF5qINPbWSvgi
E5kmJjJNTWSamcg0N5FpYSLS0kTkYhORViYirU1E2piINEBEshGRC/RKCef9wYi0MxG5xESkvYnI
pSYiHUxELjMRudxEJN9E5AoTkQITkc4mIoUmIl1MRLqaiHQzEeluIlJkItLDRKSnWSu9TGSuMpG5
2kSm2ESmt4lMW0SkIyLSCRG5Uq8UlcdQ7TfusyghF9BP6HH6OT1Hv6c/0p8YZz5Wi6UwP0tj6SzA
BHPYLN6GD+a38TI+hJfz2/lQfgcfxu/kw/ldfAQfyUfxCj6aj+FjeaUvK/gw/m53lB4lhH5KPyWU
nqAnCKNnqfr80/P0B+Jj6j9Si1nMIsksiSWR2ky9SAqrw1JJHVaX1SN+FmQ2qctmspkknbfmrUmA
9+a3kqCvoa8hSQTXBdepzIqRMEnh1byG7+A7+S7+Gt/NX+d7+F/1LJV/lZilllnGl/MV/AG+kj/I
V/HVfA3/0z/I/J/16DtW3N/csdISd78TSFTj35z/X+9pufg3fUxloEQ/LkZ58hDu2+9G9HMZWv56
hzpfp7J5orxULX9ItWvxfqVu1fuVSj6JpPGHDfdhw1V7gfJb/4UrRuryJXwpv5ffx2fzOXwun8fn
8wX8fr6QL+KLeZWSsRBjgjkx/ij/C0nlT/InVSbLVEaawTvyy/kVvBPvwrvxIt6T9+M38f58AB/I
b+al/BY+iN/6e9ddz4V34B2U5sv4ZWrW+Txf6S/gavXzQl5ILN6VdyU+3p13J0m8B+9BaqnreSNJ
VivrTjV/z3oHNTpfjSpU0t2VVG9+Db+WX8dL+PW8D7+B9+U3/t5KhPWOvKOyfjnXT42/gl+hrHfi
nZT1LryLst6Nd1PWi3iRst6T91TW+6nVlIw4/Gq9o7J+hbLeRVkv+l3rvxMPNdqn/L5cWS9QFpny
vZuy2ENZSVLeVpJko1/JaAndr3v/1c8U9HfA7PIxr0LMqDvmoj8TSr8vk92ndq1aNJnWpim0Dk2l
fppG69J6NJ0GaJDaVFCHSurSEA3T+jSDNqCZtKGqDiI0SrNpjObQOE3QRvQCmquqhcb0ItqENqXN
VM3QQlUMLenFtBVtTdvQtrQdvURVD5fSDrQjvYxermqIK2gB7UQ700LahXal3eiVqqIooj1oT1VT
XEWvVjVFb3oNvZZeR0vo9bQPvYH2pTfSfvQmVWcMUFXGzbSU3kIH0VvpYFVtlNEhtFzVG0PpHXQY
vZMOp3fREXQkHaWqj9F0DB1LK+k4Op5OoBPpJHo3nUyn0Kn0cfol/YqepmdYKbuFDWK3ssHsNlbG
hrBydjsbyu5gw9idbDi7i41gI9koVsFGszFsLKtUtct4NoFNZJPY3Wwym8KmsnvZWfYdO8e+Z+fZ
D+xH9pNKFChnnHOL+3gSr8WTeW2ewuvwVO7nabwur8fTeYAHuc0Fd7hUtUuIh3l9nqHrF95Q1S8R
Xb3wGM/hcVXBNOIX8Fx+oTgpTolvxFfia3FGfCqWBo4E/hY4GvgkcCzwaeB44LPAicDngZOBLwJf
Br4KnAp8HTgdOBP4JvBt4Gzgu8C5wPeB84EfAj8GfgqSoCqngjxoBX3BpGCtYHKwtqp+6gRTg/5g
WrBusF4wPSiCYft9+4D9gf2hfdA+ZH9kH7Y/to/Yf7OP2p/Yx+xP7eP2Z/YJ+3P7pP2F/aX9lX3K
/to+bZ+xv7G/tc/a39nn7O/t8/YP6vWT/ZNQS0rVMpbwiSRRSySL2iJF1BGpwi/SdHUj0nV1I2z1
coRUr5CqcOqLDNFAZIqGIktERFRki5jIEXGRUHXPBSJXXKgqn4tU3dNUNBPNRQuRJ1qKi0Ur0Vq0
EW1FO3GJaC8uFR1ER1UVdRKdRaHoIrqKbuJK0V0UiR6ip+glrhJXi2LRW1wjrhXXiRJVOfURN4i+
4kbRT9wk+osBYqC4WZSKW8QgcasYLG4TZWKIKBe3i6HiDjFM3CmGi7vECDFSjFL11mgxRowVlWKc
GC8miIlikrhbTBZTxFRxj5gmposZYqaYJe4V88UCcb9YKBaJxaJKLBHLxGXicpEvrhD3idlijpgr
5onj4jNxQnyuazZxWnzrnHA+d046XzhfOl85p5yvndPOGedb56zznXPO+d457/zg/Oj8JImkso5M
lX6ZJuvKejJdBmRQ2iqkjpTSlSEZlvVlhsyUDWWWjMiozJYxmSPjsplsLlvIPNlSXixbydbyEtle
dpAd5WXycpkvr5AFspPsLAtlV9lD9pS95FXyalksr5HXyutkibxe9pE3yL7yRtlP3iT7y4HyZlkq
b5GD5K1ysLxNlrmFbhe3q9vNvdLt7ha5Pdyebi/3Kvdqt9jt7V7jXute55a417t93Bvcvu6Nbj/3
Jre/O0BVhTe7pe4t7iD3Vnewrg7dIao6vF3Vhne4w9w7VXV4lzvCHanqwwp3tDvGHetWuuNUnTjB
nehOcu92J7tT3KnuPe40d7o7w53pzgp/Fj4R/jx8MvxF+MvwV+FT4a/Dp8Nnwt+Gz4a/q99D/6rG
u5+UPkYfIxPpSfoFmURP0a/JZNxhOpXNYrPIWtxnug73me7Hfabv4z7TA7jP9APcZ/oh7jM9iPtM
D+E+049wn+lh3GdaL6guC03HfaYBff8u3WHvtF+nu3FX6Zu6Rqf7HMdpRk867ZzbWG3cW9o2/Hr4
XTY+vC/8PpuBe0vvVWf6NHXWB1Q2ESddVO46Tj9JyfkGz5xRlGzwy1Nw6hGHZMg2hImdUmV8Ypds
p/A1eekvsl3U++dUbZ2q9Lkkk8RkN82RKhsUm2V3ha/IIoVbZe9fxgwApfINFZ8MlbxEWVT/KwIs
prKYxkzl8qwpa6pyiTyWpzRTlWMn/aydNNb3o1P9LzLrXyvUAaq6SNOq1e/Szbt0nY+QT9WL0NV0
tcoUH6JrlcSj9C+K/8+1djV6uv5faGW+wezJfzgp/zvOyf+mU/J/0umorNyiPBzN7vr1lFTejhDH
2eD/2pPS/lEQwYQQrmiDE/OgOiuP6jPM/kydRxfgfDylzkZ9Knpn4k//4mno/JNT8B/PwJbq9Pv1
3Pv5VPn/7fz79ZSbr07tVr+cg0vFMpV1fIh8Q+caOtM4bn8qFniZhlio8oyv7TOirc4yRDv7nDkj
1fkoR8iRcpSskKPlGDlWVspxcpqcLmfImXKWvFfeJ2fLOXKJXCqXyeVyhXxArpQPylW/e6p+8wfO
1Qb/wsnaRraV7XC+Xvq7J2wXdcZ2k1fK7rLo787a3v/b03bAf9J5+/en7YD/jPPW/ljc/0/P3CvI
FKL/zab7SLWqUHaQXYqzm7xNOpO95BjpST6jPjIQJ/J4dinrQCawy1gnMokVsl5kGrua9Sbz2LXs
RnI/u4kNIMvZzexmshLfBzzIXmXfklV4Gsc7PsvnI+/6kn3JZJ8vxZeizu5UX6o6u/XzOQ746vmC
6ux2fI46qZ8NfKxOajtoq5N6dnC2OqnnBufSQHB+cD4NBh8KPkRt/b0CFXaWHaOOHbfjtL7dyL6Q
ZtgX2c1olt3CvpjG7NZ2Pm1kF9jdaUu7h92PXmr3twfTHvZQeyi9zr7TvouW2CPtCnqDygHm0H72
PHsxHW4vUZnAGPsN+x36hP2uvY8+I5aLlXSjWCXW0E3iIbGWviweFuvpFrFBPEN3iiPiGP2rY6mc
4W2nkcoZPnAGOLfRo85dzgz6hXOf8zDzOX9xdrOI84ZzjF3hcrcz6+vOdeeyVaFrQtew1eED4aNs
TfhY+Dh7vH5R/SK2Ad846F9hpuH5ZPeSGsPp+necHWQAf5O/xf+dv83f4Xv5u/w9vo/v5+/zA/wD
/iE/yA/xj/hh/jE/wv/Gj/JP+DH+KT9O76HT6HQ6g86ks+i99D46m86hc+k8Op8uoPfThXQRXUyr
6BK6lC6jy+kK+gBdyWfyWXwcH88n8Il8Er+bT+ZT+FR+zx/iTePT+Qx8W2LhGbRTyAoSxvceLVW9
XEla4XuPfvjeo7+Sa0fC/y++6293oNv75if8m29+9PN7mMqXypVMkLVkF6scqi1TmZk+TVXepE5S
kiS+E9+TZPGDQ0kdRzouqeeEnQYk4BQ6XYjjdHOKiOv0cnqTDLWffUEiajc7o7I3tV+RC9R+FSAX
6j2GNFV7TCFprncWcrHaWXqT1v/gT2v405Tp+1HCyp9W8KetyuPaq/zXUl5NID7l1d0kWZ3vU0lt
+JYC3/zwLQDfbKehE1FeZTsJUh9+ZsHPqFPi9CFxp6/Tn1wAb5vA2+bwthW8baN2Voe0V/tqA9IR
nneC54Vq7+tDrlQ73wDSwzzbqLv6/xA8b4MnuWUhGyS/cDTVSK3b/nTQLzym8rxHyc/P59U8Rlw1
19Ym9hbmmqTmOpHUwhWog7n6xUFxkKSpmuwLUlfl6FxdB5+TqqLuqFnGnAucZqSVytf7kw7OQOc2
cos6X86S251zkpKx6vxoQCar0yFOFqkzoRt5QF2HAWSj2rnLyB51eo0je9WJNYd8qE6pVeSo8smP
moOoPGwqiaDayEe1cQWqjQJUG51QbXRGtVGIaqOLriFIV3FSeXmVfj4NKXZOyD+TPf8FGimek/o/
R++va2YgrnxbrP9ev1kzbX9dM2QC6fALj5FhJPc3a0ZVUIQ7fkcQ4jR32pLaTpmyo78fTPF8hrcR
eBuFt9nwNgZvc+BtHN4m4G0j+NnMzPxn7IFdNwM7VCpqk4fwb9U8qr/fVb6ESZaq+xrTVfpuCPon
3LWwVu/OVH+3fh/9M+5T0HdbzMGuPUNVOb8+E6wfZqL2GlXx6SdqEXJcvag+zQiz59hzCLf32HuI
JVaKlcQn1og1ai9aL9aTWu56dz1Jdp90nyS13Wq3mqS4e9w9RFVb5ELzpK5ZsPmSOtOTcKbXU2f6
GyRIDquXq9b3URKi6mAm4cCuwGukPp6J1QDPxMpSJ2kjErEvtBuTqN3Wbktidnu7Pcmxu9pdSdwu
sotIwr7GvpY0sq+3rye5+q/r5EI8H6sxnox1EZ6M1QRPxmpmT7Ink5b2fHsxaa3O1gfJpfYT9hOk
k6q4d5LOeG5WIZ6b1QVPyeqGp2Rd6T7griTd3RfcF0kPPNeql7vD3Umuct9y3yHFeKLVdaGCUAEp
CakXuR5PseqDJ1f1RUQ568g6s2v0OmEdVNZCWCeVtVDWW+Ur+gv+R8hVav2kOXWdek66E3CCju0I
tZZaOHlOS+dip5XT2mnjtFXraohT7tzuDHXucIY5dzrDJZNcWtInk2QtmSxryxSZkI3kBTJXXigb
y4tkE9lUDpHl8nY5VN4hh8k75XB5lxwvJ8iJcpK8W06WU+RUeY+cK+fJ+XKBvF8ulIvkYlklV8s1
8k/yIblWrpMPy0ekXj+1dWahVrnKLBStMgu1w3+ndrT6KteNq1NmoNq/LlL59zi1e09T+1dHlWev
Il28fCEog2GsvEl0suG4wfq/4fzzOOkxoWDGb8Z0JlkBGXACbiAUCAfqBzICDQKZgYaBNoG2/vf8
+/z7/e/7D/k/8h/2f+w/5v/Uf9z/mf9L/1f+U/6v/Wf93/nP+b8n+u6xP/CMT387/yUkxf+2/12S
6j/gP0jq+Y/4PyG2/4T/C+L6T/u/1X/fqXWUnKc/MoulsHrMUftClDViTdRJ005lsJ1Zd5W7lrB+
ancrUzX1KHXeTGYz2By2kC1jq9g69hh7im1km9k2tou9wfayA+wwO8ZOstPsnKqjk1TNHFD1caaq
hXN5M96Kt+f5vAv+FtKH9+eDeDkfzkernGeqypzm8cV8BV/DH+Hr+dP8Bf4Kr+a7Veb2nsrSjvDj
/Ev+DT9vMSvZSrNsK2xlWXGrsdXCamN1sAqsblYv61qrrzXQGmwNtUZYY61J1jTrPmuBtcRaaT1k
PWpt0P9ekrXV2mHt0U+WtQ5ZR60T1inrrPWjyrtTVHbt+DJ8UV8jXxNfS18732W+zr7uvqt9Jb5+
vlJfmW+Y7z/au/PgqIo8DuA9E153Jv3tQKaTMAwQQghXOCXcICIQ7tts5BQDghEQNYYrQAwQUcIp
IiCiKLIsy3ILKPdNAFnAiIiIqIgroiL3JR7fydYWDEftau0f+8fWt+pTyctRNW/e6/51vzf9hjgj
nTHOi85kZ7oz23nTWeAsdlY67zmbnB3OXuegc9g55pxwTjlnnIvOdSmklJBe6ZMxMl4myOqytmwo
m8iWsr1Mlt3ko7KfHCjT5TCZJXNkrpwqZ8g5cp5cKJfKVXKd3CJ3yX0yXx6Rx+VJeVqelZflDeVW
oSpcRSq/ilXlVGVVQ9VVjVQz1Vp1VCmqh+qt0tQglaEyVbYapyaqaWqWekPNV4vUcrVGbVDb1G61
Xx1SR9UXwq2TcD9tjka0BR6gLdGYtsKDtDWa0DZoStuiGW2HJNoezWkHtKAdwfNId0Ir2hmt6UNo
Q5PRlv4J7WgK2Evoh9GBdkFH2hWdaDd0pt3xEO0Bnku6J3iW6UeQQnvhYfooutBUdKW90Y32QXf6
GNiG6b7oSfvhEfo4etE0sArWTyCV9kdvOgB96EA8Rp9EXzoI/ehTeJw+jTT6DJ6g6ehPn8UAmgHW
u3ownqRDMIgOxVN0GJ4WblQwsfz6QbCP1U3A/kmvxCL6DtiT6RVgq6SH4xmaiXQ6As/SkcigozCY
ZmEIfQ6sYnU2htHRGE7HIJOOxQiag5H0eYyi45BFX8Bz9EVk0/EYTXPB9kZPwFg6ETl0Ep6nkzGO
TsELdCo4gtAvYTydhlz6MibQ6ZhIX8EkOgOT6UxMobMwlb6Kl+hsTKOv4WU6B9Pp63iFvoEZdC5m
0jcxi76FV+k8zKZv4zU6H3Pon/E6XQCOMfRfMJcuBKsB/Ve8RWuiMq2FKrQ2qtI6qEbrojqth/to
fdSgDZBIG6ImvR+16BospYswjy7GfLoUC+hyLKRLwDpDLwPrDP03sPKIOBdxnl6IuEgvRVzm9qZo
QJuhIV2HlXQ93qEbsIpuxGq6CWvoZrxLt4BtsN6KtXQb1tHtWE93IPAZ1J3YSHdhE83DZrobW+ge
bKV7sY2+j+10H3bQv2Mn3Y9d9AA4WtUHsZt+gD00H3vph3ifHsI++hECq6gcButk/TEO0CM4SD/B
B/Qo8umn+JAewyH6GT6ix3GYfo6P6Rc4Qr/EJ/QEjtKv8Ck9iWP0a3xG/4Hj9Bt8Tk8h0Ep8iy/p
aZyg3+Er+j1O0h/wNT0DjgT0j/iGnsUpeg7f0vM4TS/gO3oR39NL+IFexhl6BT/SqzhLr+EcvQ6+
O/onXKA3wPdI/4xL9FcE3qlfcIXnncBV6sI16sZ1GgL2lCiEG9TBz1TiF6rwKw017KzhMeyZEWbY
V0MbVsqAKUSNcWi4kbSwUbSICaURxkO9hv06rGHFiEgDGmUMjTbhtKgpTH2mCC1mIqjfsLZGcWNp
CRNJS5ooGmOiaSlTlMYaHy1titE446dlTHEab1hBo6wpScuZGFrelKIVTWmaYOJoJVOG+6ERatMH
UIc2BseF+l0so6uwmK7GEvoeltO1WMHj/EoE9xh7+ltmD0QeU7NgDqFWwf0pddw+t0/UY++fKOoX
zF91Lpi/Sna3YIXTzZ3i7iLSCu4uGBCyPmSDGOy4HbcYWjBbNcyJcLwis2BWaiR7z3gxSqbKVJEt
+8g+YrQqo1LEGLVZXRVrNDTEWW11pDhnkkxzccG0Ne3EJdPBdBZXTLJJFoGqp7WIE3n83cK6iI7Q
Xm10eOBvdJSO1kW1TxfTfl1cl9AldYwupWN1GR2vS+s4XVaX0+V1BV1RJ+hKunLgzh0xIfBsucD8
h3AXMoXCRSEVobxCqiTVXISq4SpThKklaqlA6JTQqSI89KfQG6KIp4qnqvB6enh6ikjPeE+uiPZs
9GwSPs85z3nhDysbVk6UCOsa1k3EhE0Km8zxDSs14Yg8WzJqTeTMqAXiP3m2AY8tjciMW9bWnyPa
uFa4VrvWujYGVgJw7XXtd+W7DruO2rIh1WwpG2tL2zhbxsbbCraqrWar2/tsDZtoa9patratY+va
era+bW5b2Ja2lW1t29i2tp1tbzvYjraT7ewd4h3mzfSO9GZ5s71jvDnecbahbWyTbYrtarvbnraX
TbV9bF+b5t/s3+rf7t/pz/PvseVsefH/1eZ/72rzPNJsE9vUNrNJ4s71rHm02Io2wVaylW0Vceta
waHC9c87qtz/7l6vf92JxePIXdedfcscXWBLA/fYm7NkrhPiDM/tWNb28e4EbktkPZ/Gin6gO909
1D3CCYkK/Pyu4cgqKPwvwYm7MxyHBSVwrfWuSbgtlQNXYoOSeGc4vgsKX8s9En0tOHzNwel/t3DM
GBTupeBkF+Tm9+m3JYMZeo+MuFs4Pg1Oxm0Zd1tmBed/cm7QJY6L4qKhaMJxdvuCZ4zefL5olsgR
uWKqmME2b55YKJaKVWKd2MK2cp/IF0cCn5gquDr/e437Qyb+Ee8xsxYjEHLQxkSWj5wSeSBqbtTb
Uct8y3wrfXm+A//VOSzxG3akUAYNCmVuZHN0cmVhbQ0KZW5kb2JqDQoyNzUgMCBvYmoNClsgMFsg
NjU4XSAgM1sgMjIwXSAgNVsgNjExXSAgOVsgNTM3XSAgMTZbIDgxNV0gIDIyWyA0OTZdICAyN1sg
NTcxXSAgMTMxWyA0ODhdICAxMzVbIDQ4OCAzMDNdICAxMzlbIDI3OF0gIDE0MlsgMjcxIDgzMiA1
NTggNTMxIDU1Nl0gIDE0OFsgNDE0IDQzMCAzMzggNTUyXSAgNDgzWyAyNjRdIF0gDQplbmRvYmoN
CjI3NiAwIG9iag0KWyAyMjBdIA0KZW5kb2JqDQoyNzcgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURl
Y29kZS9MZW5ndGggNDczPj4NCnN0cmVhbQ0KeJx9lN2O2jAQhe/zFL7cXqziHxwHCUUCQyQu+qOy
fYCQGBqpOJEJF7x9nTnZbaFVIkH02TM+c8axU7vf7n07sPRb6OqDG9ip9U1w1+4WaseO7tz6RErW
tPUwEf3Xl6pP0ph8uF8Hd9n7U5esViz9HievQ7izl3XTHd2nJP0aGhdaf2YvP+wh8uHW97/cxfmB
8aQoWONOcaHPVf+lujiWUtrrvonz7XB/jTl/It7uvWOSWKCYumvcta9qFyp/dsmKx6dgqzI+ReJ8
8zS/RNbxVP+sAkWrGM255MVIQhItFMiCNJEsQUsitQNZIm2INFbJFqAFKAfRKoJDIRNU3VSHeK/q
3YTgJCYER7Scov9vQog1wkhQCJSWQVBCPsuI9LSgAU15OWgLIoMivojWILQi24DQijg4a8JoMmEy
RG8fTMhnE2aSL0kih7zh8xL5hiRylGfEg4R6lljCvaHtFUu4N+jaRoP034LyH0FLSwgrEI2u2gyD
+ApMPl+FnYqlzioNXWlB2C25m61CYeOUHt3LaB+5OwyWGLSz7VZmgTDqhTLohS5n260MJAz2Xz4a
Fc8SO+yoevjWxzM5Xh0fB76+hRDPOt0vdMjH491693EF9V0/Zo2/39NCSDgNCmVuZHN0cmVhbQ0K
ZW5kb2JqDQoyNzggMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggOTM5MzIvTGVu
Z3RoMSAxOTgzODQ+Pg0Kc3RyZWFtDQp4nOx8B3xUVfr2OfdOy5RkJplJmyQzyZBGAgFCCUUypFFC
C8lAElpCqCrFUEVA7BhELFiw4lpXUCcDSLCiYu+9rW111V3FrrsCSf7Pue89MaDrT/f/+77d/b6c
yXOf57yn3HPee86575gg44wxDy4GNrmseuzoI6u/68WUzxYy5t1UXlJW88mHg7cy9tkBxhIry0vG
l675btB0xj5sYMzSMLqsvOKTR749ypRP1jCmfjF68qTqRXOHn8m4wc74NfbR1aGSR9/9sJMpOxIZ
Gz1rUnXBgB8/euN7xvgbuGtD0+LGZZP2TridsVw7BnBB06oV/vDVB19irP4gY8aU+csWLP7hhwko
63MlY1HJCxqXL2MpLID7T0Z754KTT53/Y0LudYzNfh/9dyyc1zj348yOE9D/DJQPXgiD4w7zJuS3
Id9r4eIVazzb02YxphQxlvXSSfOalzz15qO9GXssh7HoL05e2tTY78700xm7Ff2lVSxuXLMsvX+v
z9C+De39SxoXz8taVfUdY69iPtHxy5YuX9HpZediPP1E+bLmectOukvpwK334HZOJnxrvK7tyTnz
OmbHjPieJVmYSPd+tu4ZwY9mXLn2yOH2zVGfm+9GNoopjBLamVgH4wetO44cPrwj6nOtp27JMFpY
YjJYAzOysUxFSycrYPMYc12k3Zcz1ZDHL0KpxbjdWIgu04jVF9i5CrMwJcaoKIpBVQwfMKUzyHZ1
aiNAmlDt97MgppNKYzBfp2T5Gb9elKn7jNFipug9+qfR8OcxohvEc/l9yVDPdhnKWOMvln3OdnXP
q58em/9nSb3jl+sZjv5kVwy/ra9f7H/mL7c1vc52GXv/6/12T4YM6sc4hzUZao/zwx1s9C+O62MW
0z1vzGC3/+b7tbAMcxo74Wf2bNbvt/bRk/7/TOqrbMbvbWMYyLarc1j9b6zbcMz9jrCZv6WdcgrL
/L3j+r+Z1INs0G+pJ3wlNX+NnfN77sH/1vlq1/1uPKaf7b9U3zSXbe9+v5+Npei3PbOu+npf4hkq
Tx3br5rOqn5LH8qdLP333PN/kzDObb+1rnotyzC2/fwZqqtZrno9y/iZPZfV/W/H15N6Uk/qST3p
vycpV3Prb63LO1lvrU0vdq9iZFfotgukXSS1jm0C8n7vONSE479D6uNbzsq18qOdP/xiu6OdPx5T
fzE7B1irrGAPAr8rHvitSR3ENv+f6PffkfA9+SSdp/ybxzEGuBNoBhbotnn/KeP7fyGpR8V/gelJ
Pakn9aSe1JN6Uk/qST2pJ/WkntSTelJP6kk9qSf1pJ70H5hUHSn02xI+CzkodRwz8BIY+jE/MzAn
lINlsFxWyAazIjaMjWQVbCybyGrZdDaTzWZr2Q52h9/pj/Mn+VM7O7W+HWibw/LZIL3FKDaGjWeT
9RaNXS0S/SlowTu/x32nAvfhk2owdw0xU+2lehnrbFIe/XDOh40flnxYov9uJx/o2zWXgbhHkJXp
uYnHz1Qdp16hhtRmtVY9Wf1cPaR+oX6JublYLEvE/LPQWwF6KGPlbBqrY/VsFpvLFrLlbAU7lSs8
hjt5Mk/jOXwyr+cz+SJ+Ml/KV/JVfD0/n2/mF/CL+FV8Lz/AH+KP8cf5M8zEP9fu/PXPfhPFmaL/
7aPCfj3xn8bebSob1NM1Pn42TP1a/QbX74BpVNdQTtRtnkybqUg0W/bz+Wq9bwTOANZiGP/K/P+z
k9pNrgBmqbPVenX6v9hbz275X+6W4Oi5s2fNnDG9vq42VFM9pWrypIkTxleOGztmdEV5WWnJqGDx
yBNGDB82tGjI4EEFffvk52Rl9gpk+BLdLmeMw2aNsphNRoOqcJZfHqho8IezGsKGrMCYMX1EPtAI
Q2M3Q0PYD1PFsXXC/gatmv/YmkHUnH9czSDVDHbV5E7/CDaiT76/POAPP1sW8Lfx+qpa6C1lgTp/
+JCmJ2jakKVlHMikp6OFvzxxYZk/zBv85eGKVQtbyhvK0F+rzVoaKJ1n7ZPPWq02SBtUOCewrJXn
jOSaUHLKh7UqzOIQtw2rmeWNc8OTq2rLy7zp6XWajZVqfYVNpWGz1pd/kRgz2+xvzT/QckGbk81p
yLPPDcxtnFEbVhvRqEUtb2k5L+zKC+cGysK5az9KxJTnhfMDZeXhvAA6q5zSdQMeNmY6A/6W7xkG
Hzj0+bGWRt1iynR+z4QUU+xyE8qlZhgbRoj5paeLsWxuC7I5yIQ3VtVS3s/meCMsWJBXF1YaRMkB
WeIJiZKNsqSreUMgXTyq8gb9Z9XCxPDGOf4++fC+9pOJH5T7w2pWw5ymhYIb57UEysrIbzW14WAZ
RLBRn2t5a78C1G9swCQWCTdU1YYLAsvC7kAJVYDBL57BouparYneLOwuDbOGJr1VuKC8TIzLX97S
UEYDFH0Fqmr3s8LO91sH+r27C7Ez68Q4wvGleChZ5S21c+eHfQ3euVif8/213vRwsA7uqwvUzqsT
TyngDOe+j9ula3fUWmFux9WWlcXMzZkWf63iVevE04LBX4FLoGQECpx4XFpWPNGSEf5a7mWyGu6i
1xDqmH6QUTNLx4giVTQtHeNNr0un9CtD8upjMmaGLd36csLQNSa6zz8dGtUWA8r1l88r6zbAYzo1
6gPUe/vlcSrCF/qN0cIiHucYWaRmYufCpqAbzSSeYqI/zCb7awPzAnUBrKHg5FoxN+Fr7flWVgcq
q+prtaetr5KaY3JUXkS5MEtHscwopViDFXle+Vi1/Ggt35Udc1zxWFnsb7EEKqtbROcBvUPmxw7C
pE1ZYxs3F8UOxNaswOkWqGgM4LVS0dLY1rlxTktrMNiyrLxh4TDRR2Ds3JZAde0IrzbWKbXrvWvF
rWJZJa+sKemTj7OnpDXAN1W1Bvmm6vra/Xjx+TfV1EYUrpQ2lNS19kJZ7X4/Y0HNqgirMIqMX2RE
T1OQsWj1vfuDjG3USg2aQcs3tXGm2SzSxllTm0I2p7QpsBnIFtRsIuEhJS6Ei3Hclvvnisezrm5h
S0Od2FwsHo8SPzzMAyNZWAmMbOWKyR62BuaVhG2BEmEvFvZispuE3YyFweM5nCPOpJaGAM4pLKha
5uW0FFXRpb+ts7OmNv1Z76G6dCy1GUB9bTgqD2e/MXMc6o0WaIB5dHhjU6MYBwvVirbmzLFNdVi2
skNUGRuOQg9Reg+oUaG1EcsRjZrwbPAAtfYbkQlvrAvX5Ymb1i6q05azM8zGBIbhsVOfxixxo4K6
ltjAAG1vYitYM88TFIWxsepasniRxc3qyElmO0beFEBRU4Mf3jawpmosdTpLrV6yzMORaMiap8Hq
1QuZmJaaaXNYw1F90SF+hLb1FVvSmGmuq6PBa7nz9Aq4tzNsw4iyurlSbwDvoGisGAt+zsNQRdWH
RDdVbWxKYA1OFjForSczisOOzLGNOPypvQ2WQJFsbBFnhE3v4yBZzWLmdvhdzaxp67w1cGp6t9Qn
PyBeDmJhMu9+LGxW13K8ITw9r0++5XirQzO3tFgcv9yA/GVxdLEw+svx1mAsEqX625Sz90Ql8nEQ
Z0lxphRnSLFRitOl2CDFeinWSXGaFGulOFWKNVKslmKVFCulWCHFcilOkWKZFEulWCLFYilOluIk
KU6UYpEUC6VYIMV8KeZJMVeKJinmSNEoRYMUs6WYJcVMKWZIMV2KeinqpKiVYpoUU6UISVEjRbUU
U6SokmKyFJOkmCjFBCnGS1EpxTgpxkoxRorRUlRIUS5FmRSlUpRIMUqKoBTFUoyU4gQpRkgxXIph
UgyVokiKIVIMlmKQFAOlKJRigBT9pegnRYEUfaXoI0W+FHlS9JYiV4ocKbKlyJIiU4peUgSkyJAi
XQq/FD4p0qRIlSJFCq8UyVIkSZEoRYIU8VJ4pHBLESdFrBQuKZxSxEgRLYVDCrsUNimsUkRJYZHC
LIVJCqMUBilUKRQpuBRMF7xTig4p2qU4KsURKQ5L8aMU/5Di71L8IMX3UnwnxbdSfCPF11J8JcWX
UnwhxSEpPpfiMyn+JsVfpfhUik+k+FiKv0jxkRQfSvFnKT6Q4n0p3pPiXSnekeJPUrwtxVtSvCnF
G1K8LsVrUrwqxStSvCzFS1K8KMULUjwvxXNSPCvFM1I8LcVTUjwpxRNSPC7FY1I8KsVBKR6R4mEp
HpLigBQPSvGAFPdLcZ8U90pxjxT7pWiTYp8Ud0uxV4o9UuyWIiJFqxRhKe6S4k4p7pBilxQ7pbhd
ij9KcZsUt0pxixQ3S3GTFDdK8QcpbpBihxTXS3GdFNdKcY0UV0txlRTbpbhSiiukuFyKy6TYJsWl
UlwixcVSXCTFVikulGKLFBdIsVmKFinOl2KTFOdJca4U50ghwx4uwx4uwx4uwx4uwx4uwx4uwx4u
wx4uwx4uwx4uwx4uwx4uwx4uwx4uwx4uwx4uwx4uwx7eLIWMf7iMf7iMf7iMf7iMf7iMf7iMf7iM
f7iMf7iMf7iMf7iMf7iMf7iMf7iMf7iMf7iMf7iMf7iMf7iMf7iMf7iMf7iMf7iMf7iMf7iMf7iM
f7iMf7iMf7iMf7iMf7iMf7gMe7gMe7gMe7iMdriMdriMdriMdriMdriMdriMdriMdriMdnjpbiEQ
NUfSRvoQM0fSPKAzKXdGJG0YaCPlTifaEEmzg9ZTbh3RaURriU6NpI4CrYmkloJWE60iWkllKyi3
nKiZjKdEUktAy4iWEi2hKouJTiY6KZJSDjqRaBHRQqIFRPMjKWWgeZSbS9RENIeokaiBaDbRLGo3
k3IziKYT1RPVEdUSTSOaShQiqiGqJppCVEU0mWgS0USiCUTjiSqJxkW8Y0FjicZEvONAo4kqIt5K
UHnEOx5URlRKVEJlo6hdkKiY2o0kOoFoBNUcTjSMmg8lKiIaQjSYaBB1NpCokHoZQNSfqB91VkDU
l9r1IconyiPqTZRLlEOUTV1nEWVSn72IAkQZ1HU6kZ/a+YjSiFKJUoi8RMmR5ImgJKLESPIkUAJR
PBk9RG4yxhHFErmozEkUQ8ZoIgeRncpsRFaiKCqzEJmJTJGkySBjJKkKZCBSyahQjhMxjXgnUYdW
hbdT7ijREaLDVPYj5f5B9HeiH4i+jyTWgL6LJFaDvqXcN0RfE31FZV9S7guiQ0SfU9lnRH8j41+J
PiX6hOhjqvIXyn1EuQ8p92eiD4jep7L3iN4l4ztEfyJ6m+gtqvIm5d4gej2SMA30WiRhKuhVolfI
+DLRS0QvEr1AVZ4neo6MzxI9Q/Q00VNU5UmiJ8j4ONFjRI8SHSR6hGo+TLmHiA4QPUhlDxDdT8b7
iO4luodoP1Eb1dxHubuJ9hLtIdodiS8GRSLx00GtRGGiu4juJLqDaBfRTqLbI/E4r/kfqZfbiG6l
sluIbia6iehGoj8Q3UC0g+h66uw66uVaomuo7Gqiq4i2E11JDa6g3OVElxFto7JLqZdLiC6msouI
thJdSLSF6AKquZlyLUTnE20iOo/o3IinEXROxDMHdDbRWRHPfNCZRGdEPCHQxogHhzE/PeIZDNpA
tJ6ar6N2pxGtjXjmgk6l5muIVhOtIlpJtIJoOXXdTM1PIVoW8TSBllJnS6jmYqKTiU4iOpFoEbVb
SLSARjafms8jmks1m4jmEDUSNRDNJppFk55JI5tBNJ0mXU9d19GNaomm0XCn0o1C1EsNUTXRFKKq
iDsImhxxiztMirjF8p4YcZ8FmhBx9wGNpyqVROMibsQFfCzlxhCNJmNFxL0BVB5xnwcqi7hPB5VG
3BtBJZHYCtAooiBRMdHISCze7/wEyo2IuOpAw4mGRVxiaQwlKoq4RoOGRFy1oMERVz1oEJUNJCqM
uPJBA6hm/4hLTKxfxCX2ZgFRX2reh+6QT5RHnfUmyqXOcoiyibKIMiMu4aVeRAHqM4P6TKfO/NSL
jyiN2qUSpRB5iZKJkiLOmaDEiHMWKCHinA2KJ/IQuYniiGKpgYsaOMkYQxRN5CCyU00b1bSSMYrI
QmQmMlFNI9U0kFElUog4EQt2xszxCXTENPnaY+b6jkIfAQ4DP8L2D9j+DvwAfA98B/u3wDco+xr5
r4AvgS+AQ7B/DnyGsr8h/1fgU+AT4OPoBb6/RC/0fQR8CPwZ+AC298HvAe8C7yD/J/DbwFvAm8Ab
jpN8rzv6+14Dv+o42feKI8v3MvAS9IuOPN8LwPPAcyh/FrZnHIt9T0M/Bf0k9BOOE32POxb5HnMs
9D3qWOA7iLaPoL+HgYeAYOcBXB8EHgDut5/iu8/e7LvXvtx3j32Fbz/QBuyD/W5gL8r2oGw3bBGg
FQgDd9lO9d1pW+u7w7bOt8u23rfTtsF3O/BH4DbgVuAW4GZbH99N4BuBP6DNDeAdtpN810NfB30t
cA301ejrKvS1HX1dCdsVwOXAZcA24FLgErS7GP1dZJ3o22qd5LvQusC3xXqz7wLrrb5z1Ezf2WqR
7yxe5DsztDF0xs6NodND60Mbdq4P2dZz23rv+sr1p63fuf7t9cFYk3VdaG3otJ1rQ6eGVofW7Fwd
ukc5l81XzgmOCK3auTJkWOleuWKl+t1KvnMlL1vJ+63kClvpXOlfqdpXhJpDy3c2h1jz5OaNzeFm
w/Bw8/vNCmvm1rbOA7ubvWkV4OC6Zoez4pTQ0tCynUtDS+YvDp2IAS4qWhBauHNBaH7R3NC8nXND
TUVzQo1FDaHZRTNDs3bODM0oqg9N31kfqiuqDU1D/alFNaHQzppQdVFVaMrOqtCkoomhibBPKKoM
jd9ZGRpXNCY0dueY0OiiilA5Js9SnCn+FNUpBjAxBSNhXl7Szxv0vu/9ymtg3rD3gFeNjUn2JSu5
MUm8dFISX5p0etLWJDUm8flEJZiYm18Rk/B8wnsJXyYY4oIJuX0rWLwz3h+vesTc4ifUVGhcXEbc
f5A21wnxgayKGA+P8fg8SrnPw5nrfddXLtXzoPN5pxITw2NiOmOUYAyqx0T7ohVx6YxWg9H9h1TE
OHwORVw6HWp80AGL6DHbPrmmIsbmsymhYtskmxK0FZdWBG19+lUwlfs5Z9wJUi1iFNzjq8C+3h3P
jRzv89aa6ry8yjYLm1IZtkyeHuabwpnV4hqsqg+bNoVZqH56bSvnF9a1cqW0JuwWv7HV8uds2cJK
UivDqdW14R2pdZXhjRBBITohWGprPCupy5u1fOXyvLwVs3CZtXxFnvaDHF8pcnnCKH6Wr0BefFZq
eZb3q4mqgWYvR1ohjSt+vdV/euL/7gH896dWJv7IYFSncjabq5wFnAmcAWwETgc2AOuBdcBpwFrg
VGANsBpYBawEVgDLgVOAZcBSYAmwGDgZOAk4EVgELAQWAPOBecBcoAmYAzQCDcBsYBYwE5gBTAfq
gTqgFpgGTAVCQA1QDUwBqoDJwCRgIjABGA9UAuOAscAYYDRQAZQDZUApUAKMAoJAMTASOAEYAQwH
hgFDgSJgCDAYGAQMBAqBAUB/oB9QAPQF+gD5QB7QG8gFcoBsIAvIBHoBASADSAf8gA9IA1KBFMAL
JANJQCKQAMQDHsANxAGxgAtwAjFANOAA7IANsAJRgAUwAybACBhGdeKqAgrAAcbmcth4B9AOHAWO
AIeBH4F/AH8HfgC+B74DvgW+Ab4GvgK+BL4ADgGfA58BfwP+CnwKfAJ8DPwF+Aj4EPgz8AHwPvAe
8C7wDvAn4G3gLeBN4A3gdeA14FXgFeBl4CXgReAF4HngOeBZ4BngaeAp4EngCeBx4DHgUeAg8Ajw
MPAQcAB4EHgAuB+4D7gXuAfYD7QB+4C7gb3AHmA3EAFagTBwF3AncAewC9gJ3A78EbgNuBW4BbgZ
uAm4EfgDcAOwA7geuA64FrgGuBq4CtgOXAlcAVwOXAZsAy4FLgEuBi4CtgIXAluAC4DNQAtwPrAJ
OA84FziHzR21kWP/c+x/jv3Psf859j/H/ufY/xz7n2P/c+x/jv3Psf859j/H/ufY/xz7n2P/c+x/
3gzgDOA4AzjOAI4zgOMM4DgDOM4AjjOA4wzgOAM4zgCOM4DjDOA4AzjOAI4zgOMM4DgDOM4AjjOA
4wzgOAM4zgCOM4DjDOA4AzjOAI4zgOMM4DgDOM4AjjOAY/9z7H+O/c+x9zn2Psfe59j7HHufY+9z
7H2Ovc+x9zn2/r/7HP4vT3X/7gH8l6fE2bMYM1/HWMelx/zF9mR2IlvONuJzLtvCLmUPsrfZHHYW
1Ha2g93C/sjC7CH2JHv9X/wL919MHacaFzO7uo+ZWBxjnYc7D3XcArQZo7tZLkUuzuD/ydLp7Pzi
ONsXHZd2OjvaTLHMqrV1KC/B+i1v7zyM9yvynYNFXjkPOkZr8bX5uo67Om49zgdVrJ5NZzPYTNbA
GjF/8Tfpi+CZk9jJbDFbouWWoGwBrvORE39Zj7NE0z/VWsqWAc1sBVvJVuGzDHq5nhNlp2j5lWw1
PmvYqWwtO42tY+v162rNsg4la7X8GmADOx1P5gx2pqYkk+UsdjY7B0/tPLaJnf+rufO7VAvbzC7A
c76Qbf2nessxuYvwuZhdgvWwjV3GLmdXYl1cza45znqFZr+KXceux5oRZZfBcr2mROl97DG2l93J
7mJ3a75sgtfII9Iv8zUfLoMP1mGGZ3UbMflvdZe3NmDuYm4t+kzXwH5mtxardD+KmmehJvVCz0H0
sv44T1yEOZD+aUaUu0yb/0/W7l75Nav0xzXdPHO1lhPqeOs/05eza7EDb8BVeFWoP0CTul7T3e3X
ddXdoeVvZDexm/EsbtWUZLLcAn0ruw17+3a2k+3C5yfdXRHfye7QnlyYtbII28324EnezfaxNs3+
a2W/ZN+t2yNdlv3sHnYvVsgD7ABOmofxkZb7YXtQtx7UbJR/mD2CvKhFucfY4zihnmJPs2fY8+xR
5J7Trk8g9wJ7ib3MXucOqBfZX3FtZy8YP2LRbBRjxnvg52vYLHyMOJWWqy/hFFGZmQ1lE9hENv0+
5sDrPp4N43v3esrKLH3MD+BVrjA/ggEL47w0GGNQHPuSk4sD+waZtqiusW28z55i8xaEucXt77Y/
V9D+7qHYoQWHeME7H7z7gfPr51xDCwo/eOWD/v24K92lwR2tmM1uUyCjrzIoO2twYeGAkcqggVmB
jGhFsw0cPGSkWjggTVHd0jJSEXmuvnS0Xp3UblI2BIqnFhrTkmPcDpNRSUmM7TMi01k9PXNE31Sz
ajapRos5Z0hJRuXJ5RlvmV2pnvjUWIslNjXek+oyt79tjD78jTH6SKnh5CPbVNPwGcW91CutFsVg
MrWlJSb1Hp4+dmpMnNNgi3O64i3mWJc9p2xG+7meFNFHisdDfbVPgFsCnYcNG4xulsGy2LX7Wa/O
T/fYnXx8oE0XWW2dX+2xQdiksEIEk4XKdIqrQ7vatWswh2eK4nwbn9ArkJX5nd1mT8xIDVgdPN5g
Z3anXbkr8GDg+YAasAfssalTYkPGECsuLo4dOrSgYOZMV8JQF6Sr0HlogKsQHs+bSa9ClpeXGR9v
0lyeraar0WogIytr8BBOfk4wB9R0w0oLd2b6fJlxUYal7R+fqFrjAimpmTHcwiMGR1J2mr93crTh
NP4ef/iEeG+0QTXbo/jwjiejHFEGY7Q33hCxRVtU1RJj29J+mvhXY7vEP/bC6kpjeayIPRFM9iU6
+QSfM0ZcHLgk2nHxY67id8TBnGRPEOWeIMo9Hlu+qJwvKueLyvmicr6onH8PvhOyzgN7oVlWITy9
GzXBX+2O0dmh8Q+77Rp/utsmWHEGHTtsB2yKLTn7u/79zb20/ypdNbCN21rNNaz4ULG2bofygpkf
aE4b8EoeCZjz8oaShlPd0YZAekbWINfAwYXp8J5HrOc0lQ/sqwQCLrGY436SBu4rmtR0ytiOOxNy
cxN41optTQPi80b1HjSjPKejPbmoflzkYOmUwUkTM0efVPXc4eG1pVl8+QkLpozs7fFlG87M9uXX
rJ3Qt2Z0Uax10JQlCi8YPyilY2Zg+KT2d4bVjvB1FKUMmcI4a+z8ymA3pmEXz9mdwobn6V7J070C
/lx4BfyF8Eqe7pW8B/AdO5ol8gKWzrJ4fiSu2nAv780GsX68b2vUVGzpVw4J8AKavvO1g/37Zbqj
Td22pcmjb1OxgT3uNEXMWywrg10xWtzB2aeN3fD01gnVl794etGJ9RVei1E1WGyW6AGTTpk0dcvc
IYOaLpo+YXnVwBiz1aTucybGRrtzs701N3197Q1H75rh8ff2Rsclx7pT4qKyC7LLz31o3Wn3nz4q
qyDL5ErDDhSrbCtWWSzzsdXB1OJ0HidWTpxYOXFuzDkuFhOOS8Rs4+4VK4clk2+Sdd8k6ysmWV8x
ybpvku/F9/4o+MYeia7ytvGsViOtEumLV+SKmClOtGOWhLnbAtg69eavbun4Qnv8mbd9em3V3oFL
bz/3rtZ1tzcPVa667cjNU+hBT7vx0+2L9p497qhr5MaHxL9nxczUdZhZPlvVmpytP9FsfdTZ+qiz
9VFn66POblNcwaioOH+cH4NPbuOWoGNjFj+QxV/I4llZpiTxCxpHVTao1dS16mee0oxpFWjHiFNf
/dpzVn620gPpruOkus5gdVjaLxUzVOZbHBajEZcOE49YcDQYoqAnKtzisBpGx3pjLTRbS6zXHet1
WTpOjHKmxMUmO80d/S0urzbvzsNqDeadzWa0muP0ecfp847T5x2nzztOn3cc5r3XkcrSUs2Y2u64
uCRTG8/ZnVGVJA5I/Y1UcNA1tGt2/GeTkW8bOV21BhMzd8B7Zgxe00GL25+cmOG2YKoVmvVgXApm
Mcbs9HrivK6o9r+YHWajERfDnWKWqfqMDJPxlihgbXuK+/OAXZ+UXZ+UXZ+UXZ+UXZ+UXTzMlIRe
NrGibWJF28RZaLOijk2saJs41RJY0IOjMBgnLk4Xvp0HUc4SxH9mR4Hgu1GW0HsKjrz8YMwBO3/B
zu3Hvj+wBA4Vc5xzrwj36E76aSnMzOxyTnc/0T73wCalYbLFnZ6Y7Hdb2ndDJQlfWdwZiUnpbosy
QfMeVLLFLpxktygj2x+W2vCWVO2HFZPUuv94LfznYZP3FSdMSrgrQWW6C5nuQqa7kOkuZLoL2T3Y
xdbOA/vgCatzijZdTLNr62b+bDK8Vo47ypOekNR9tD+NUO7PSowqmY3Zzzw0HI8+HI8+HI8+HI8+
HI/423QWFTPF08bz9A3IC56Vw+m247pcKxZiJXZRVPvBhFzpSv6CeO1Wur1xUdhPd8phHbkhypWi
e8yUhz00gu0KOhtGLhupOPr1SygosPZNTExu+40HoFh9ab362+1Wsf6sYv1ZxfqzivVnFevPKryL
d3EwSbi61+AqW2KCoyCxf1+TL6fKF5LLqzgWgUkhJirfqIhOnF3KNfSEgsJCEa90exoBLmIURCs8
cMy+1MIVXigCF80/pjyL25eUkB5nUToKVZsn1e1Jc9uUjtEcay0p0R9nzvcu9PfrlRjFVxv5ubZk
X1bS4hhvnP2nh7rgyDaz1awa8PpBQLi9y35L71725Bzv0WnqLWm9k2xRcakefS9vMLrYCeyc3dkx
MW7dmRrH6OzQ+CvhTLfuTLfmzDRr374DhDMHJMaICyoOcNqFQpUBooqTpRVNsfaNyTYkibNLrBDN
fcJ5P/NdQaG+ZMhTWVnZgfh4zy/4K01NKMzqtqoMGxyeZMeQ5OxAwNOx0D8qRVEUS5wvMdEXa8lP
npKa7Ut18WGpgwf0T+Q4uuN8SfH+WMtoNyJgW+qAbOX9oeuHj7l83NFvuw6723MyrAm5vvYnBjY1
zCyYtHOS8gDiQ5z+drP4fzeIM/1xrMcUlsvWtPYy6V4z6UvQpC9Bk74ETbrXTMIlCa5U4bJUsf5S
nXYHH58q4sBU8UeHzJXZxq27TSZ7AHHcbk+VvdtxTw5zHnviB44/5g3dXtbq48HVd6y5NCouPUns
st7J3NN7wqLF43P3Dp82M//6qycuqOilXtp4zZIRHX271gmmbk4onnHqtEknDoxu/zFndJOYcVPn
KON5xnS8xYazC4Op1vTYHDGLHDGLHBGX5Ii4JEc8+BzMJGhl/pR+KRtT1JQBunMG6M4ZoAdvA/Tg
bYDunAHiXwbFplsdfdp47p6E6kzDEHGoOBC1HXrlWeGEoV2hysyDMpQd2r+fUfdAtql7GKfHsUYt
ju0WyWEWVrvJXbfi7JH9L2+65NXNZeO2vbtt88tbx8Tljuw9dsmYHLelY1f29CuXLbtydm5W/RXN
p1w1K6c5wecypRfXj0jLn3rL33dc9eNds6fe/M21VdvOXtZnRGlGTFxAeX/JfZsnVm+5Z2HzgxdM
qNl6v75ODDask8GsjF0cTHP2dQ2xYKpDhNeGaM9+iPDiEOG2IZj/vlzxnSG32CV8BeXSfebSF5RL
X1Au3Wcu8SecKX2diIvuXhbkwWDCCVg3e9OrEvSjSouGDnU5rtt3gKH6XtO+QvVVf7aQ4hPSVP2r
QEJcfDwfmJWdlSWDQJvJ3SstOd1tM6z29BlZM3y5XGIICuP6j0quXD4xO1AyY6h/YJ8c94poS0d7
2eSk4sKLbytrKvHhqLJgJ+Gg6D9wWnGg/c2upYcQw6g6iqYuLR214H/Y+xLouKorwf/+Uvvy/699
3zeVSqWlVNpVJVmWVFpsy/smeUE2GIyNsY0xdrABQ0IIDUkgOaY5gQ4ZSNLdgLGxZZM05jQJIT2m
IQOGdANNJkkDTtwZkgy7qua+93+VyracTs/MmdPnjHTt+1+90v/13n13v++pFrabDcnOBQ3FX4Y9
zO0jW2xKRXEk0LEIdNZA6TxzBfBigXr3JNUDoakRgs0emUQ9Mul6ZI3VI5OqZ4quzScb8yYzGmnM
CxCRNoYbdS47vteFzYCL5zGCW1x4OVyn6AZsC466iPU9fdQhX83S9bgRuya6umdQjGqhNCia1wr+
FtSS1+rQiID3D2hwq0VoEayd4MM93ePiEkuswNtHOMzSOMg9L2APNZkc58/zWMBnfBVReqMqSMNr
w5Z5W0ox1CkuE7IomCvm7fmr8Z7tKzpsWhbIbWhatGOodXxeuHHxlm1XLW7q2PLVpckVo50mBUsz
Cq1Sm+4bb88uyjgbl1y97eolTeiaNX8BgZ0/aI/4rB5RGYyHvC2LmloWdDQ0dS/dsXDswPKU0eEz
aQW7SYRIxh3yeOp7I9kFnY1NXUt2wBoZQUO+DpwfpDadsOeBvHYBU+0Y9mn+bHWJzbEAoTHmfIWI
HWCPrBEbwen5gBDnR0n++WTF/Z1x68qagDgcrxO3/b6yJwQt2a1nDhGnnni9n32rwogbVYLbZJIS
I9j/+H7pPLsXfKMkdTjvWZ9Cfiy1fizFfsw6fuxB+DHX4DN6eaHagwVOo6zyhK3yhK3yhK3yhK3y
hK2naB57d9jPxRt58mp4hCa6mF/smuEb4tbKejA5wyLj6FI/VlZ5VYZy7/yDU7uvefLmPsnxN6lq
l+wuDO8eSxLSBExq9PYNJw/2du89vocJlcnx+e9X37EqVbvy1hWMrdpjDIJ2uwqoEqa25T1hrNji
YeTE16gTxW0oqke1DlRrR44pWUhJA6s9e7kHN/Ii7nLYHfZoxLfYzomSXyu25QQRSYKAZ0iNj6Px
8fHkeDJCnCkWuwjZbJUL1Wi1KpT0CdbgiHmsAbugUzLFVSokxoPugKhm0U6EtjAqUF2+sJ5ReXGC
B7EcBO/sUyQFBEHdZ8+yOdyPU0B4jl3geb4Dc+ykrjwa7URgrD7Oz8OCHQEWVOFGPI0iPOmJoKAd
NxJBZPfjRqoBpepRKoxSIdSyuGZxqF7LVIcp4AflYOXgB6e2ZIhUPEWm3Lp4mhdOmLuN5d0Jry/p
NrDFD+hPGYMz4Q/Uuo1M8fsKJET9vrBJSaMQQmZGbY543QGzmkEJGnkYhSnk8YZ4xEUNAvZuBAPz
yufpcpv9a5sTU8Wg/ex5tl1rBK2tMmo/+zHboYE2Z3DaMIXqQdI/JNFgfd6TSKNEHYraUdSGYlYU
p1BicUgreBYLM6k9mDJeR/iZSeIhVMnhVc22MkXE/ErPiYmgP2zRssV3im9xOkvYG4gaOT3aUHxC
p+RBQUWtGgWyIjOnMQU9vpjA6opPdludRo5RadU0Mz0NzhvDGZ1Wegmds7qMLKMEpeBGv1LplWS9
p3+EbfZasC455qdUE5Wnnsz7jb2+3nQvo1XbMjoQ1QyW9wwW9QyP+TczhT7KQ3AfM1JIR2GNQLXL
lqdd9p3bZeluL/N8+xStypsF24+oDJ+hO05nEJVBmUxdT80UcuWNLwdRMMh6ztUNdb2pG2WpdDmr
cV4gge3EeDln83xyYrxNznA0gkGfgIgDExR84+YqZ6ipWfaB5B6W6AKlZCysTY3ZFibHu11On6Hj
q2MDO8dS3bu+u2W/tWFBW9eGQoNOBY6v0tW7fHNmw5eWRr9zd99kr2/Vop7tXXadDjxV3epcf6R/
c8/IdUOR/syiZpcn5FHxDqPD4wx5TLXLbl76vC2VS/Qv6e0D6h4G6r7G7aBqcMTxNCgzTSAra8Gs
rBWzMr3wa0Kv7BT6OO+yJLGHmfTjvB+mfxLr4CRP0oG0Jq+mLJpsc4Dl6qcQdzw65OrnR9qgeYQb
JVoTSGhrq0QdMzSr6M2Y5VIFKgmbUiafUrBaiVv9WtMV944nC/39MZXoskAYoVCa/HYHxBTx4cHB
+Ma7VsQft2SW5/3d+fmxvv3zule2ONC7u5851C9E2xPbQIeyLOhQrpV4QoCmf51oDfELbnty9/xb
J7vEmt7G4uElKzqv2AfytRoo5mdepJqpO4+4iQci5QnekfMD7x3DweosCbV/uzCRVjonJdhobV6f
NiCD411fXqMf9IWnEH3MNMT8pgHbZ7V+sKF2CimOqEdxtjR5nqBKEvn5SirtopSpQnI/FNUJU8ZP
c0pH5/DK9IZvbGru2XF4VXKsr9muVtCi3hjrXNa+50AgP97ZtjyX1OGQ9duCQ9A7Ih4xv+/o7tuf
vamDdwbtBpNdjPkC8cCJx1fctjIZToZUJg+W0/VAlwe5a6ko1UbdlfflOpDW1Yalsw1b4zbszbVh
7mjDzNL2DMLf7pSWqJaWiZWWiZWWJTYtEyuNGUpjCvRr22Iu1lCDN3Xbh0DU2aOGUW4EOyCEnXIX
5U4JP1WC/moRBHe6wlVMNFodkLQwDyoFtxmXYwYOr7niKyvijRu/um7hbXml2Yd5Sv3ovC/05YCD
gKN6Al35/pijzEB7RpeP3nZk465nDg3Mn0dry9Hr9HzgnY378323bgJemteAqTUO1DoMWi1JZajH
8zXpbC67PcuYsDSZ/DgRaQrUYt+3FlNLKlEQ/Qa88MnTfcnvJGmcfH8aS1uGlZmPlXmMvNaSq6Tg
WEy/QKD2hYPsvSx9mkUvs4hl3ek3o0P2c+sN1xlog/qcmzDYeHXGVhLKt5ISs5E6BRFQRShQxVaW
C5mPtsSyhKBK5nDMMf2Ut/+6sfxkIa1TahUMzSi12eU78tsfu769c8fDV1x9//rUo8zePV1ru4M0
TccCwzcur7M4LUqDQ9SbjDqtw27qvmnqpl0nb5nft/MvV5puva9uZFMLtnOR0qf0HdyN4AlMPmXl
sQASwXPJWstV1lYuWZ25ZGZy4eNr9TWRqdLLeRHnMyOa89kBZ/R8/aB/hB8kUVojTsMnn2/6QJKx
pucrLr/k0lukeSuqozRQ82XtTujA0neAL6NQWrwJVyTjN7wIVo8TjS+qQDXZ/SbVAZ7HquZAaPDa
oVBvWAc+jtFkM3BqrdreNNa+USk4TWH/57/B7hAuaDAWf9jkFJTjE19cntAbdSYXroI1F7/O3Mn8
hOqmFlDrqJfzFjE1gKVsQAVTHvDzJjQy0JQDLwmTICfLF1zfOY7fyikXQjOvN4poZKGLNdYzTUol
5h6e0Ot0Xg+NVJPS5VI2pVhM43wGE3kl/oiVfh5uW1kTyWvhGjHWK5nWoX/SLXnPYlnfyrzfOVjj
7/1569Can/sXyoWAHLGY589Kqj/ZdAYT1wYOJXYpBejkzyThX7KMMNWBxlarZAqiMQXoM6tNjoTL
PNcC5jWTJViSbAiWUSZaMae4YBaNxQyM/Iq502S8JeRuHD+4oOUKl2jryf5m3nWL6zLXPLrj2sMb
a/lAg78h3RjxhTNrbxlJDPgQLwjF4qbx+oG0bdOahsG0bcm6sff9Cbv60A3Dm7pdzK6QL7wiveDG
JbUeq1jnDdXRGjrQtaqj+7plDZH8qkygu7XJ4Rip7VofjYz3jt60NKVWBYofrL3S31qIr9rsaxmc
nmjP0SpHKhG39Mzz1Hdj/j4MftzDYJkbqb3HchlUM1OKkBm7qkYh1yzALNu8UvqeJPJJDp+oDS1+
TyNl7r01Dh4syonUULjfMULUJ0lMoLScuJaMcduF6WtiTZSzJOcl59DCPKwSJZtrryvUd+/vg5ck
QVo2xQP3FlbvGwk4yvxMG0cn+sIrl03fVe6ptr/Dha7Nd27AmvL20qdojEtTFipAfeVELrQwtD3E
WGVf7oKIzUSu71wU2UmR3DP0DspNWS6XNpdJagEyHdf4cI0YH+Q65uALhD5nzydlbShbltlz+yZs
djEzAhei7osJYKrtaE/i/xUSMIeU0oSVqL69JtEG/2HGpdeKX0eTMOMwVU/dcXRhI67aE2cBrr/H
446UFTsu5+MJRPCZ9qSOkn+vqkohzatSrgDdl9c4HFRjHZ5jHczxaNxXMIMlPcIRKYWZCk1NZX9W
mi3Mlbsg4WG9MIq9YNpj3vzkgD9lh/COUaqVipAtkPYaykoP06Am2dFRY5zctzSp0ugFUY+rc5w5
NVhg/vpSckhysB/kIEPdn9flsijRgBryIhoF9+hlMrkG2fw14NnryJWYv4Zn6BgVpHQyDS5fBQPR
cFpTKQqTRBIRa1DLxQvufqEsHiTZCc4WePfEJjS+U+aCChvE0CzCIYeHYCqUCFmtzH6VKeh0hexG
RfHQxfyBlqpER9DuCFrUemPxFNqm15LUHIRFavT7ov5SMfn8Z+gGjV7NgFFV6+x88VQxIlhk3YG6
gWYWKk8qWttJRWv2CtYMj6CPj2n4fjJjmQFmr2BdwtmOS4cmj4J7GXycRdS5vEvktXKdPEqi8xgJ
za9bjPovrbVKGcOqmuy5in7zeq3Q9HobpSoRqReRUhFRcxrg7xOLcI5nUfelpWvpsZeUuJ9BH4OS
5ZHiqeEhcL4VeX3PUHd/qrWQGnFUrX91bb5NztsKbeVaH9aW5EDPn1KZl9OhFjnAlpmFe1lSpSaV
ubavrm3nfCw9toBJaa2dV9e2q6JZFaLbZvXwypF7Cq2r+ur51NjwQHjFDQXfjI4NtV2kYy/tYQ6B
Y8Iwaq1qz7KFznRPvKGvxgTKd6Rsg2AFG6n78kZpBTGSzdHFq3SZyjkOFr1ani9bJVJorqoxo49P
yIYJm6W8JjVU4wgXyqTHXkPFMpWrLTK1/wzzZPn3zFOFiN8c/XfM0wWEAgKtx9YJR4NvA4VMVIz6
bt6dS6C4iBICzrVFdSiqQlElqiHZHa8c5HhlgnllteWVvXavTDAvdta9aQ3SmHFEbcbkMuO4wIzj
bTOmmfkUrcG58BNGavQ6WCYHPslqHApB5CiH1zhClElWDhWlxBb5QVXeU3VAXQ6BmLfbd/7t9dv/
y7Zs286/2QnXlsdd3VcvLGzpC7hyVy8cvLrPj3697eQdw703H7serkNw3V+4dWNbZt2to0O3bmjL
TNyKcwvF+5jXgDY4t3AQ5xYCWY3MJRqZSzRl7aORZ68hToxFSiuQBAOpCEgZhlnzCgV+4WXzCrOl
FWbhkcunFb42Ee/ryYermMVscYnKxMjoWGrjl3FaoYmkFfpjfTfN617V4kTv3/CD2wb4YCZU7C7r
QvZ94BkGZ7321nQnLCOHntg9/5bJTlNiXkPxgSUrOyf3k/gZqPWgTK078i4gl0+bxAKT1OjKKRai
5JI4dq6hmiS2qdqZdk7emVbesVbemQaxsyVS0HYlfSxfh2Nn51Arjp35UWzzZ4+dL6BZsyBlPsv8
Ymu+fOysxmLmMysTQ4OFGCZR4xVfXRfvnz9Qgzc3mt2C8pL4uXisTCl0JtEWMpZjaCHSkbi2TLri
/5SCaCkhA0E00U70YyQzeMWx65pR1CgzlVGeurHMXEaZ64yYucSqQgDmMsoJPBfJq5NDUaPFX7CM
ULK6JwY/WfGFqwPA2RQNYSIF/RitUKtUNk/Y4qhvbg9drGYiPe1tHn0g7NGxDGI2Wr2CWq1WmetG
WqafvFTR3JbtixkZlUajNpC9S2Ol8/RLMOMC9VJelx7ODS8cPjD8xDBXVWz7UC6yEabowekp00VF
OFJ8Q2/mfVLFjdTaMIvJBTccImOd4zqFPiSbLzTYLdLliasEL6PwvJzuCR2tq3urRfMbYZGwXrhO
YKTC2j/jqtqQ9T1JGCslNbmgNo5LJFUFtRlf+j9aUKNfapq4dUH9ivn1Vg2LC2bJ3PLWmr5GVyy/
aNlYPpZYvG9xeLA9YVEy4B1pFOpgtpCuyScs8fziZUvyMWSYvxXW2+Ywh30m8D9dfpcYykaimbgv
mOxe3tm8oVCrEy28zmjlBQevtDqsplC9O9Yc9wdrOpfitQiUfkdfy/4t1U6tPZaghFBKpnlKXouU
vBYpWSBTMlemMBPqbPrU+dCgR3/eNtiAvW+lpLbPYLZrkrNXZ56XUnvs7AmGC9MQ1nI6hr5WxfsT
dbb+ybznZqOIq2pfKDtq7+LcsWh8t2XAFnabVZyaY9d4grxBrYgM71xAG6QMw9ny1oqzUg6iqBlf
p9aoOYMdz/s+nOdjfgA+wdfyPvAEtDHMQTHMQTFca4oRJRXjicuFPjkuSZpPpopPpgpcPyayiRtH
ySZdWVh9Mo/6cKyiNqUKMS3nKIBjxs0k+7B8lvVVhaVmTfZdVHzLtsyk/R5Uih6LzSMoRr9BTL/S
LMUotvRgffe++UqzDyRXVFc8gj3LFnReeedGOliWzuk/Llw3L7JyGb273CNX4Zh9QJ9a6pcnqVAJ
rBl2dH2kNhXxIa/U8CKrPE+LfDXPuL/kKlb2FJT+R74Fb0gAr0JAMR7FORSMQ0dXEIWDKICbuQAK
B5Cf9PpR2I9iRnRDAAVwkkstWAYDfpDaAK7tqYEVAzjDiF/hlQjg5+vgxkC8ENA6C1pJAZKyZhLv
7R4nnkNS+kcqRRLdcXUsSXbbVzZTVZkIk63FJG+z34dohi6eYfXOuNcbdxjY4kssh7f92Dwhk5ot
ssxntMYUcNm8gpJ5iFVrdMrPv4eLfqzKoGFW6EQ1AzEhDUg97dTp6H9V61QMrdJiajdDjHEIqD2f
evskNQDqqQum1oqTX4lW1IKvkToUDaCoH0V9KOpFUQ+KuVGcRQkGtXegjnbUkUKd+HsjLGiUl9MH
+JrXALvyfngCb5S78TWvw4YEdxt7CuT3MDFz/EJ+O3+AZ/m8aB3kmwqRQvu9tagWv1eLtSZvsg5e
Wbunlp4PvbYRNSbya5iS48/ncmeAkhK9Z0qrUnFV+pEIrajQmYkpq2qRs5C8qskdYrniR4zeFvf6
ahw65oc0/QSjdya8vhi8Kn7CsRBd2NxBUcX8nKZfoNUisL1PVNGv0+gsrTYFnHYPXhal2TizKPTd
avX0zpklMpqVai2sEESq0061GlZID4oXb7W0l1/RKg1erwRIxzCsV5q64yTVAIQRcH4f6406rDE6
6pAd+PE4rufZkU3WDdZylxWpMbfW4LgV39NJodYQymqR1o/DC7wqWm1DfaKAa5wFoRJCSJXrdKVq
jZlX4t9kxGouH1xgZql5mkwzNc95KlPM5w1ZtOwbr7NaS9DtiQhIjezFj1TIFPN7QmYNe+ZlViP4
XJ6ISKuLn9QaTDoOonMl2lT8S7gwnM5kQCfQYwaTnmUUGmXxCFqowLsDtWZjcQJrD/AC9wN9wtTi
k5QL5tqMJd+FEi5kJ8GzHUUNWQMdUyMnNsntTuRoxYRzIF/BoTEVNMPsQmpYDlpxNTspCS0W3gAj
TbXFFI0C52QqVWwTyepYzUq66UZFQ6PTL9CK/WqeKT6r4sNeb9Cs5hBiPlYIQb87LCiKT/MCpzMb
UBsrapi1FruBY1RG/XQdfdak5cBOiDCTVeDUvs6coJJUx0mKh5lY8a6CKNlllYb3M+o+Na2OCBC0
HHUMGmMkeIGB4+R7I/gKZ0DvyCEe3rJKMr0oINtAsq2abIdCuEm/rlAZVNNnLS7Mj+ju4gHehPe0
0qxW0ClxX3E3elSlVyv6TS5B6Q4EDVarg6evDkREeK0wWAW/wW5z8tPfUPLgadFIU/oQvclNUBYq
QRme5iKuUb4fiPrWSzOVgGYmWkmAXXSQ6IdKfJDHLSoFpLKE3K6QRWVQO+I+XwLkwZ7w+eIONdpd
9nqZUzpRxyl0gu6ztkDSpdW6koFAyqHVOlJAp5ri22gn9Q7lojRPaW1uin/1jLRVTKmUdECLqfK5
OxUGm3Anpzc5TIJNg9jbtfaw0xG2ae/xZepSjpeUGhURS2Q66PLzCgXvx5HHM6WP0N3M/SSGdR2h
zFP0vhMabwgicOMglTuTO4NdksaqicsfJ1w87bvxHP1xPMe4H8/x4teM31+L51frD6bwNTUdD0gd
MGFQ7c4U1hHfhPFsgxlrKdsRvDnp9HG8CUnNgDDDUJLP4elXZRy3pbs76/D/awfSdfPhP37GV5jd
6FXuRqCa+imFdQDuhPFfUDVokQTbrEQjOnvYgakkUU9ncoiiTcuy/QdcfkGhEPwub6auzv6SSqPE
x5KIla+B5++Un6+1yc//Dy4KF/U1pVP2l5Q6oizVyHTA6RcVCpGsypeYPUwd+YQWSn9MEbQ2wqc0
nWmcdR4QvV5mdvSjWlvIbg9atQq9jf8ipxMdIm/VIK5om+UN0G3swM3yKJzeJmCaM+VpF89f5g08
2iSzh36lMlptzNZUGW2FKtFoZoYs3KzEol/Bg/kSqxfteDDMIY0t5LCFrNriA1VvwPBZ8g4ePRfz
wWjsZ1RaGA24CEgAKpJlc17uDVg/VHyX0XB/B/KtOsJzVDrdUG+TByPnbJXfZfVmj8UREFkFPc7q
TV4LuNAs94HeqGKVepNesU9vVMP8zXp43nx0jK6juygjZThGKbXnWQpvEZYrWAGJV4mmqhOF4oQI
P+jboI849EnM64tGvQrBSSHQOedZmr4ZniI8BU85idzU5R7E0ibT5zmTKJqY59RGNUdno6FQNBJS
k1MupU+KX2epkp3SU8anKaXmfRZn9y99jpWleOHzLkEUBebveaF4NuT3hoJBTKHbi4+hP3B3USEq
mLcw2DgzOCxkiAJnLD7t7VQuDZpB2hCpgDhEtFX2D9UxhAslSqLfrRtft4ZDBo9DdJp0THZxq9vX
trgJqXm31ebmaW7ji8VVZ18vrv4HnaDlaIWK2/zKG2/t2PHmz392JatQgKHksczdBCN6F0YUoJpO
UqLkNYty1IWvT+ORiWQzqJbE9dIIk42VPZvKsoXPis0ZOibrb5tVRO+6W8eyjM7kFJ0ePeLWTkxM
sDTvtlncgoq+cjft2PHWG69s5lQKmgOT8lP02Otn0WMvqnkNjE7BnikuhPE9WzxNu7g9lA8shuMn
RucLeO3S58skL0cjgUrQRjjeZTSUKJ1V1GpFqw5RCog2jIZHHsHX4ucBF9gjsyKJrZaCtwl+96ed
CiPZ57W6eBodlz+N/4nD+IJC/jRO2rIvB4szYSPJ3R/XijZdyWBkQCoeeUS6lnQ2Ufup2QVhcECw
GRXc826/YOMVSsFlwrJ9F7OZfoDbXbaFrugAD8KdO1NtEphyKvGiHquFvg0GLop2o8KmMQds9oBZ
jYpfvKCvPsrcUUkB/WO5VWy4sI/nYSzXQPT5Q85PZahB6vBJagg8SJuRHl0/hJK7c2hzDs3LoUwO
hXMoN0XPy5t1brfupmZ0dTMabkbtzSjZjJrhjePXUQgzOXbspeM9752Ax1D1OqSbKn2a18ALXXup
vp6LTiHqKdOqvilkOcKtq5zjBLYafxV8yPFfEA9dxNu+SAufZkpWpTPYi9MXyouyjeWc6w8zWx/d
MbZ/bVeEF+sW7nl0W2QkX2tQsjRSatXaaHa0afyOZQnG2TO6vGHLvauij9uyq3sjQ/NzzkBuIpef
6PagR5Y9tLcQH9r65e9MLPn+t+66slNtFLV6o8kgOnmVQTCMHPzeWqPXbmzbdOf69nW9Yb3NJ97y
+JZU/dgmvJdgMdD2FDlT0EINoFtPUlkckgt4wxc0sHA1T8k9zeWeTLknU+4hCUlhJjFZIJuzYYkK
qL78O/XlYL+6hxTt6qdoR95hjhMtEyepBLntl44y2PNOrzHk9eITLmaCvGavppX8TisOdy0eCADJ
jXInvrH1FD2PokqvHsWLPLPold3j8h6u03KF7DTZStKLYw0NfkZvPTy0tzzo3vKge+VB92JWEzTY
H9c0d3Gpaceq+dMVZmmrHAh7VQqcL9hSDhe+KleNuafyh+GqHa4WSaXOnKRgmExlh5ctm8WHgst7
HLLMqc4dj14z+a1t7fHhbfM71+YDDVcc3rzxnvFavMFrYPtw7A1P65LmrdtdbSs6N22tCc6/si+3
rst3+6GDt6GRpbetrqtZfONo1+blw0Hf/LG12b49K5vSY9tyTRNLC/7Q0LJ19LqavnrHxmWxeZ1t
vszN09+uG+7pCvi6ewu1G66+BuR0EHjpBeAlE/j/5/KOi4oikXJRJIVj4wjmjhSqKnfgGp8ZZ5TM
ePHM+HC2+RkanEPKLyXT/DJz+eWst19OK8H1Pewthv0If0dNXq3xU/VUnmLIuXg13lumWaihKZIX
IQfOJIY4TSSe0lCaVK0L/1lR4xJ88kfe4n1+Zt8zxFEg6NW1KLJkf6KywlYlyFnmhfS1T95y02Ob
k/Vbnzy4D65PGlzJztH6ZVd3Wb09mwZbl3WBv0x/+f4Pj2xY8b2PHr7vI3L9mw0P3LCsxbHoKz/Y
+tV/ONgenjdx/e2gvh4HsX2Is1F11K/z4bAXhT0o7EYhFwo7Udgh7/tNENqLOEKuJ3t6MLnrEYVJ
SyXk7GRCJmhCztMlZIIm5BA8gY9KGbx2fJNdi7FWkOUIrkSuBFmOqvpPy4djgPRwx8MCEkziFMod
DS1O8FNIKZ1QbMxNnyG5YfxzBm+3Kp8kkIRhJg8yLkeD5aMEYBMVUv6jJSLXTolNZR5SaPTK6bVK
nVahUOtVyPAp3lnFKLRqVMPqwIW0gyN7DmIyrg9nf5W80yQ6BTXzxv0aVu+1CXZep3iWYVnEKrWK
z+5Rg3MG1L4eqP0g8HQ3dV9en8iipBclPDinlJ8qm6E8smIuthLNY/WT3AWdOt4UAaDaZFq3naIP
UFqJOFqcQdLiiqjQ2ub3twHz1R1vsirqlvBtUyheppCUSU9LygQUyJnKUWpCI5IruoA4OP1z0TZj
RUV3KMkhjAc58Bunmw0Wo5LRGHWfrdjSJrqbF2XIJmMlOM00p7J3rLqmY+Lu8TrrwB3bz9BNKqOW
G8InTJS812r22mx6pFn7tRs3JpOj7cFgPKgSvRajlTdYwiF789qb5nfvu+eJ68+qRVK9uBJ0wteA
fisRd5JaDSRzY5KtRg0qIEoDFvwGQrcGTLeGKbo5r1mwJLpggd2ERvM4dxmFX4nilFoeeqN5xuBS
8eVqBbnT5Scb/CSWdQHlnyZpIrIrF8u3QWZNg8ztBrxwJlgGQwfe/NGRJ8mJDkRYV2ZhyQJ0CB2C
NTuFtHlNYUntH/x+roAPD2krh4fS59v4yvkhUN1pSd/Lup5scsMbBsS2GT0vKwsFiWMrNQ/puKXs
ssk9sy2iBSzA17p3ff+anh0r240qBWPQq5uXbO/rnewLJpfsHd0Ha6VUaA3qHb1bCjFnZqy5fcNI
owZnocDDNrUv255f/aU1KX/36o552xel0PWr7tncYvH4DAaIesJuf8Qf7F7W2LIyHwTxsJgcRmUw
v6olXsj6QvEQZ3RZjTbBYIJ1rlu6e6Bry1ibllY2L7oG1nkTrPM3OAPIyXN5fawFxbKkEM4QOTku
iUmLLAst5A+X4IN3+HBRHMgdx8cY8WrEDQsbtzceaGQaZz+geYpuApP+nmzSTz9Ndu+YpnBZHO+O
M9mz+Dy6rrb9j368g5+rHbNfsGDj5/GCpZOIPyuv0/Pjr0pLJgkVlqqZNbqgMIUNb+iCP10AHr68
FY75Rv/BI1s7ty7NgitNYwdbUzOwZXDedWN1sbH9y7tWRt12n4fuUhk1nFksekKF+u2Pbm9DD1/1
7e3tgsNu0AlOUXAJKofH6e+7cqh7Xc6nc0ZoY8CvBtELx4v3c3Tzhi+XSmVvmFYwPwVSlMoeHLzG
3/oNK0FNMFNsAGIE3VHRzUOEcObVcqICVXQnQti3yGatNrxFaYpVaBSf/07Lq1mIl7T07dMHIOKl
WTWvZcwaPd0tuMxaprgLx3M2d9Ci41AXalZorSEPhE60oriTi0l/BeyvJEDpy8Kv6Y1V8I8SMMOz
wLEZYJcSeOhPwvkZ4B5QNP8Z8LjicWVB+UcJVD+eAXVKhqnZQFOjeaYM2tAcXAQ/uxzortF9dCno
/0ICQ3oWeOr/LhgfuhT4EIEHZwchROCHGESqCn5hur4azNRl4Jvmb1rqLd+TwLp9FvjN/w7Y9s0G
9kaHpgIPOEplcE7MwRz8fwqPzAqvOl91uV3dANtcDxH40L3gsnBDFRwG+Lsq+BcJPHHPjZ4nPL/6
88Fb8/8E3vC+4Sv+n4H/SOCqoCr4efDz0JHQSYDn/tNDaQ7mYA7mYA7mYA7mYA7mYA7mYA7mYA7m
YA7mYA7mYA7+cwGpIyOKMpyjEH2TjqLU9JsUS4mlDwCvKr0PeLK0HvBVpXcA7yw9BnhX6UmKRQ+U
/ivg06V/AvxC6XWKZZZRRsArKR3g1aVhwGtKTwGeIO11pH09PFmg2NJvAU+WXga8s/Qu4F2l9wDv
Lb1KCSiO34XnY3ya4B/ju+BToM0sK/0K8GqCJwCLMM5/AzxJaSgR3v0I8GoYg8isoVYBniDtddC2
w+f+d8CTMC87fO57gHeVfg94b+kXlB3ufRHwShiVHZ7/O8BrKAbwBGmvg7YbnnAOsAj3uuFz3wE8
AaNyI7r0NmAexuNGTvgUN/KW/hlwvHQa8BdI+y7S/wC+F+b1MuDnyF0v4DZQ5tdUFJ5/N2ARZhQl
84rC838JeC98bhQ+5UXA+FOi8Cm/BeyFZ0bh+bjnLtJzb+ktKgpzyQBeWcoBxrOIkvFHma2lZ6la
MrtaMq9u+KxzgFeV/hvgydLVgK+CVegG+lwLeFfpy1Q3zOJ9wA/AWnfDyJ8C/FxpCvALpSNUN6y7
AHh1qQPwGnwXPBm310F7BcxoC+BJWJcV8MwPAe+FEa6AubwKmC+9BtgJdFgBc3kdcBzWawXMCLfv
Iv33Ap1XoAdI/wsYw+xowCuLnwFeTekBr6HqAU+Q9jrS3lq6D/D1pb+HlZ8svQIYc9oqmNEfAe+F
56xCi6gOwFuohYB/TPmoVTCXLYDXUCrA6wjeSn0J8AHKC/gWyk+tJquzGij2W8ATsGqr4fm4vRNW
YTU8H96FubwJ+Auls4BPl/4V8HOlfwH8AsYgIxpqAijzAeBJ4MAJuBfjXaRnb+kP1ATc9T7g52CN
JuCud6kJoPBvAa/Bv8lMkPY60r4eaDsJT1sPWIRPnISx/RjwBFB7EsBNTQK18bdH8iX8HZDOEv72
SW8Jf//johL+5sndJfz9ljcQ/AXSfydp30V+8yukfW8Jfzfl06R9uoS/nfO5/0Xct8BHVV17733O
mfckDIgaKI1T8BGQhlRRKSAGDIqAMEWxNNQkQ16M5DHMTEKCBA4RaYDcduT6KXJti1S51vrz+vNV
tX52YriJj1yLgBYRbcS3jZBaiqk35Xz/tc6ZRwAt/b7e3zfLtWa/ztpr/fde6+wDeMag3+7sMugX
O7sN+q3OHiMiKrA6+ZDfN1ZDLjEugywW50DSGlVgjahcyuUa439BRmDbcti/Tyzn6F6Oqw6JKFp2
QBLaUXj0AWQJ1i4KcokoPPoxpM+4B3K08UvIXGM7ZMC4F7LBeBWykWUL7IzCIypv4ZHtXI7D8ig8
onI39mQU9j8iorABawn7fw25xLgUcqm4DLKUZY1xF2TE+DcRg4W/gKQIisFCkoR5jFcwBgufgfQh
XmKw8GnIXONJyIDxMmSDsRuykSVZGIOFVN7CI9u5HIcNMVhI5QRiIQY7XxExWJgHucS4BHKpyIYs
ZRkxHsTOHmF0Q/6AJe2TZsy+HzLXeBMygN3SjBkPQm7h9u3Ifs2YhVoSyDDNWNnfQXYjNpt5vzXz
TmuG/v+QCrLBMcjtxmeQsAqyw/gcsotbuo2DUsFefQuyBHIYxh+FjBvHIbcbX0AmuNzBssv4PWQ3
l3uM9+UwXPspZAmkDxgehWyBzIWeI5Dbjb9AkoZc1pALDe9Cdht/huwx+mQuNGAkNByRedBwANJn
7IMcbbwCmWv8FyTuMpABYzdki/E65BbujRsfQCZEFmSHsEN2Czckac4D8q2QS4wmyGIxCnKpqIUs
4XIplyPGS5DIGDKA2Q9C+oBYALN/BpkLXwLIPGdBtgC3AOaldqyCDCD/nAuJnAa5VNwAWcLlUi7X
iOtkMeNfzPgXM/7FjH8x41/M+Bcz/sWM/83Qcw5kKWSIyyEu18C2tyF9xh7I0caLkLnG85Atxm8g
t3BLHDprMNdxyCeND2UNvHtcNrANDWxDA9vQwDY0sA0NbEMD29DANjTy+EYe38jjG3l8I49v5PGN
PL6Rx7dgzBeQHcYAZBdWsAVj/gLZg9VpwSq8JTfxvtrE+2oT76tNvCs28a7YxPtqE++rTbyvNvG+
2sT7agvwd8t2IPAGpM84DDkaY9qBwAeQAS63GH+A3MJl3FUhE1i1duwKDyTtinZYEoBEJEIW417e
DoSXQpZwuZTLEeyxOKz9DHK78QlkAmsdZzvjsPNTyG54FIedR2Qcdn4AiTuL3A4LP4L0sRyNa7fD
wk8hW7Abt8M2atluvCe3Y3YP5FJxLWQJl0u5HDE6ZAJ6DkOSngSdHCBzWeZhZIL9TUDnZ5BbuD0O
PBO457ohE8IL2cGym2UPdkICvgchlxhLIIsFohqzT4cs4XIplyPGa7IDs38C6YPmDsx+BDKXZR7i
qwOzU5lm78DsVI6z3I6TZQfP3oHZnZDdXO7Buncw8h2YHbuEZ+/g2Tt49g6evQOzvy67MPtbkD5j
LyQyIWSu8TJkC+K0i3IgZBz7swsz2iGfhJ1d0HYpZCnLiPGC7IaedyF98L0bej6GzAWe3fDCDRng
9hZu38KSYqebMexmL7rZi27eOd3sRTe8qINcYiDbshfdmBfnKvaiG7NTOYLc1UMnTEgfl0fDlx7M
TjIPu6gHsx+FbOHeLdwexz7pgS/UmwCePdhv1NJNZcwyBrIU587FONHjVI1zyK2QUaMBMmbcAtks
3Opi7K7X1cV0nodcauDeQ+d5yFIux4yXcZrRhBdyhHEQEvdByAqjGnK5cQQyaoQgY0ZYXQJrD0AG
xDmQ2439kAnjccgO4znIbi73YN4lmPFKyKWwZAlmpHIplyPGT4CUZtyoFvNcOH2JpZBRMQUyhmuL
gdWrkD7jPsjRxi9UOo/9EjJgPKLSqexZyC3cHjdeU4uxCrMglxgzgYt2YgByBOzB8wPsWQr9w9Sl
0LkC0mfUQI426iFzWQYMnA/kzcIJGTKOQzYY+yAbWbbw+E1c3sLj27kcN26DfJLLCeMDyA6WXbBn
Kd15IXuMj9SlsG0q5BIgUMJel7DXJex1CXtdwl6XsNcl7HUJe13CXpew1yXsdQl7XcJel7DXJex1
KXtdyl6Xstel7HUpe13KXpey16XsdSl7Xcpel7LXpex1KXtdyl6Xstel7HUpe13KXpey16XsdSl7
Xcpel7LXpex1KXtdyl7XwOtnVLpbvaXS3YpkLsuA8bZKdyuSceNNNUInBMgEyy7sxgg9M6prKdtD
hsRV/Lz7bWWsoP8fjz4VLFV+Cs7mGpUVka1qVlkVBeoIq6xljLHhmXCWVbZntDvEl9iHZtkpJqh7
rLJL+LUbrbJb2ZEa7xE3aTGr7BUTtJetcpayTTtmlbNFjaOdntP5c4ljwCpL4XBOsMqKcLhWW2U8
tbrWW2UtY4xNeF33WGV7RrtDtLgesMpOcbar1yq7hM891iq7ZSA13iMudl9ilb3ibPfNVjlLzndH
rHK2uNzzPCyRmsvC2SybOJtlE2ezbOJslrWMMSbOZtme0W7ibJZNnM2yibNZNnE2yybOZtnE2Syb
OJtlE+df4invEjyfFIgpKF3Pv/4cEfWItXpRhVjzi6v5V7PN384OoiWEUp3IR89MUQPyi0Voq8ZT
TQxXUa0S35UY3QhZgZFX47oajFmGthBGhHhcEFwLXRU8tg61KNrquM+8PgQL/OAgxoWgoRm1VSjF
MJeff6t7Gco1GOtnmxtwdQX/Fng1a6m3tMYwotaak0b44WM9z1nJv/lNvlzHvlahJci/RR1hL/z8
HWQvaV7Tj3L0TGTNtdxSwxqDwMhsT85SCz01jFjYsrIOLbU8q6mT/IxlWEAzhtmX5G+Vm2ibttNM
9UDAz7/SXc0ohPh3uen3zmNcI49jqfUwMTNn8bPtdZZf9YztMh6ZtjjTI0Ktia8zvV6Bej7vh8zV
vIi11bKGZsahwVr5TLxpxUz/K9l+8t9clwjvBvo2Z6S19kNHOOWNaWO1NSaK2mpLewxemCvUmFql
IO+RIFprh/iV3M3lsCTI85db8+fzjq3mtaKeU2Ng6ileT01FzWXiJmsXhaz9dhk0Xo7e0+/6Smv/
mt4ELfurude0p9JCjGys4J1LVq3gNUtec/reqn8ogtO7xVybxaiF2Aaa/wbe7bEh6zjJsqA+w4Ny
K+5i7GUl7+X5aCkXebzG4zGmgvVfy1aZ18ZAYaA4CbSKKZ9jfKjl+ay9FmNi2FtkfzV7EIaGZrTS
ClaxLxQ5Q7Um2yl7mCuwIqXvB2yzuWubebdF2cIYx1WU84B5tZ99oJis5B0V4jlMhJbxtUn0ZgO/
+ciI5rWRjB4znisYk3SMruK5yjmGTzevWaex5dhFDYxhRWrPV3B/mHdsc8Y+D7OnddZON3VVsqTI
Pdlv6jczRB6uGs+7sxZ+VaZi9lSr6k7RfOYYpbUns7TfyrPm7ikfku9O9T29X4faNS0DAfLE9MXM
+sldH0ndQSo4h9ZxLg1+pacmzsEhmFZau//kGCBUaec18JUVnI/Im8qUHhpZwznt61bonxUX6ZiY
xNZQDJh3onxeq7Bo+qX/koKCKf7rQ+WR+mh9Vcx/dX0kXB8JxkL1dfn+mTU1/kWh6uWxqH9RZbQy
0lhZkX91sCa0LBLyh6L+oL+2vqIyUuePBuuifvSHqvxVwdpQTbN/VSi23B9tWBarqfRH6hvqKkJ1
1VF/PYbGKmtxZV2Fv7w+UlcZieb7r4v5qyqDsYZIZdQfqQzW+EMxzFEeneiP1gZhQXkwjDJdUttQ
EwuFobKuobYygpHRyhgriPrDkXrYTWZDe01N/Sr/chjuD9WGg+Uxf6jOHyM/YBku8deE6jBXfZV/
WaiaFZsTxSqbYrg4tKIy32+5eVHUXxusa/aXN8B50+7YcsxfucofCcKXSAhu48Jgrb8hTNNAYzVa
oqHVGB6rh0ON5FLQvyoYqTXnIpjLlwcjMKwykr+osrqhJhhJrcDU5NRTaWkuuwkQwSn/ZfmXX5IB
fSXwxTRB6K8OkR2VMCwSrKisDUZW+OupJ6NadfoFZljgzeK6UAzX3xALxkwfJ0FBPU9QjrWLRUKV
0fz5DeV5weh4f0Wl/9pIPXpjsfDUSZNWrVqVX5tUnl9eXzsp1hyur44Ew8ubJ5XHqurrYlFrKJWr
gnBgBY37QX0DoG32N0QrYQRcom5/ECtZGakNxcigZc1s3uzF82eiN8IVrHNFg7miq5aHypdnXIvv
UF15TUMFYVHvrwhFwzWYgDAPR0IYUI5RlXWxfH9y7vo6bIi80Hh/Ze0yuiitqi45+LQW8XDa0oA/
CnjKzX2Xmp1xtXRNYwPyQpgFW5+gj1CAVNSvqqupD2ZOCpuDpqUAPrUC9Q2xcEMMsDeGyitpzPLK
mvBJDp3JWvBKTKqorAoiiPKD0XBT6nmQ3um0UZzuIzECTxTiLOEwDDEMzy7mU5SQeeDJ5t+jfs1H
02Z7vRJjlB+e6fisLBqvxs90/LBhNF7bfabjfT4abxs40/HDh9N4x8QzHX/WWRiPb0FPlRqPp6fq
a1kOF1lihBgtcnBeHiMmiwtxUpgoFiA/L6W/gxRFyM+zRav4vvgJ7tL3imLxkCgRv0b23o3e15Cz
30H2/qNolkIqMksOkznSJy+Qo2WBzJVXyjw5RwbkYlksl8mbZb0MyTX0p9oobZMN8gHZKB+VLfI3
9CfFaN0n22WvjMs/yu3yuHxSUWRCyZIdSo7sUsbLbmWy7FFmqnOV+epi5Qfq95WgukSpUYuViLpU
Wa2WKK1qqbJZrVG2qhFlpxpTHlRXK4+oa5Un1HVKp6ore9X1yrvq3Uq/2qcMqJ+pNvWIOkI9qp6n
/kmdqH6uflc9pl6jzVZvwHrfPBQzNfgPYrYZmN0NzO4HZo8Bs98Csx70vgnMPgRmfwZmTmB2NjDz
A7N8YPZdYHYtMFsEzMqAWS0wuxWYtQGzu4HZA8DscWD2PDB7CZjtB2bvArMjwOyvcruiAbPhwGwM
MLsImE0BZlcDswAwWwrMQsBsJTBbA8xagdlmYLYVmG0HZjuB2WPA7Glg9jww2w3M9gOz94HZMfVu
VVP7VC8wGwXMLgRmlwKzQmB2PTArBmbVwGjlUMzsezMwOxeYXQDMLgVmM4HZQmB2MzBbAcyagdmP
gNnPgNnDwOxZYLYPmL0LzI4Cs7+JqPSImBwLzL4LzK4FZjcAs2XArA6YtQCzTcBsGzD7d2D2FDDb
DcxeB2bvA7M/y0bFLluUEXKTkiu3KN+W7cp0GVfmALMbgdkyYFYHzFYDs38BZvcAsweB2RPArBOY
9QCzA8DsD8DsY2D2J2D2pVqjqmpEPVuNqd9QV6vfUteqF6nrsId0dZ66Xv0hMKsFZo3AbAMw2wrM
dgCzR4DZc8DsZWB2AJgdHoqZ+4kMzEYBszxgdgUwuwaYLQZm9LQTBWat9OvOwOwhYPYMMHsRmL0H
zD4XFYj35dIHzM4DZlOA2feAWRkwqwFma4BZGzDbBszuB2ZPALNOYLYPmL2LEZ/LesRdA7BqVC4A
Zt8BZlcCs/nAbCkwqwZmUWC2Hpj9CzC7B5g9DMyeBmbdwGwfMHsPmPUBswFgZqhLVadaog5XS9XR
wGwcMLsMmE0DZjOB2bXArBiY1QIzHZj9KzC7F5j9Cpg9C8xeAmYHgNlHwOy4NluzIX0NH4pZ9n9m
YPYNYHYxMJsGzOYBs6XAbAW9iReY3QXMdgGzDmB2CJj1iWLpEiVyFDAbD8y+C8xuBGb1wGwzMHsA
mD0GzDqB2R5g9i4wOwLMDFmsDJM3K34ZUibJGmUmMFsEzMqBWRMwux2YbQVmO4HZY8Dst8CsB5i9
Bcw+BmZ/kV2qW3ar58oe7Jm56mR1sTpb/b66gP6sHWgsg1wBzGLArAWYbQRm96D2c2D2ADD7FTD7
LdDaB8w+Amb/rfZpmvqZNlI9op2vHtUmq3/SitTPtRvVY1oFMIsBM30oZmfNzsDsm8AsH5jNA2bL
6d+5ALPNwOzfgdnTwOwlYPah+L5UxQ/kSGB2GTBbBMzwlChxmpd3ALNHgNkrwOwQMKO/Mx6UoxW3
zEUuylMmyADirVi5HpiVArOVwGwjMMM9QHkImHUAs98Bs7eB2RFgZsi4miW3q9+QT6oXy4T6Xdmh
BoBZNTBrAGZbgdkOYPYYMHsOmL0MzF4DZm8Bsw+A2VFg9lc1og1TY9rZ6mptjLpWG6eu06aouna9
ul5bpt6trQJm64HZVmD2C2D2BDD7T2D2BjD7CJjhfmyz0/nC6cB/Pl9eXtGa1lanTTodvfF4f1tb
Wz9V7OE2HZ+2sNMunc7+tg34oEdDT7+u4z99SEXnYRgzSAOdUjo13frQMJtV7nc6pdPd2fkAPvfc
w9fs3n3//Xfe2d7Ok/L0GOdyoKdpA3+a7Gwcd8Xb2njWsrhe6PfFy5w24bQP+M1P0gS+iL1rbS0q
ysvz+Zwe4fRs8G/wzy2cW/g9kF/3w2Jcu2HOnIKCOXM22G3S7uh3NrW1NfFsMLWNJrRr0m4Lk+lh
bnfSEAzi8eG2AV1vcmrCqRUU9hfSB4Ps9qZ4vEwPmzhC06Mv0iUmJsLEwa0aTtUvLMMT7JOux3ck
duyIDwHP7pR291MvbcKHpzR1WbPjQ1bZHaatgJoqpoFOp12Vdq3X1AIv7GE9UeDrdWjCoZnGFrAa
Gr1tud0m7La2tkDA77e7hN3Vprfpi5GXx4LMPvQE2pzpYYWFNIGtFwW9N8NmoauKkCpa7VLaVZ1O
a7rEB3GtSKdaqNMAJw1QaWcEduxQgaAtENjhsQmXzen0+fykXtcRl5rWK+1Csw9CGvZBNzRo1EWf
wkKuUoE+QJWqiSR0CbNaaH0SqorZduzYwXuGwWP4UCnbwcswYPXAAn9hqhJ2Oq1hA7x/rcqUQt4h
4aQ2Uhi2AR67XpZTpn9NcGGXOqYUkYVFU/7JweWSTk+H3qHvBN0JolU8JcgcqSBDLLqmFLXiUzRd
/acEmfeUIOMRRejOK2rNCDKXTbocemaU2c0o4w5nKsyooyzeTx2acCHMThdnSWVfEWhaOtBcmnQh
0KxIc0npSiH5/xRqlCUeTZwUapwYCk8fa/aviTV7Otbsp4m1TKu/PthcVrC5rGBzWcHmOrNg80BD
KtgQZFxPRhuauZ4KNz1h1gszA85lBhx2VjrgUEkHHPckA86sWAGHSjrgKGRSAWdqOyngXC7hcjn5
RT2E40yxjneAyy5dTrpuAPt1ALcVl3P6LDZ31nSquQY20P5vRR9togHdjLh0bUA3b0cuFw07QWLo
tqGR9mRlwOWWLm8Cn/sK7yvcytQOQqi53B333XfHpk23334bG8UG8RZ1oW+6mCXWp2gWzidSTw9r
Q4Zgi+imzPi4HMLlOOGzPin7KJSnMBSkeSZgIDAIFKdweaQri+JzsxWh39EpQgGay7l+1vnn55x/
/qz1Dpt00CI0YZ+67dLthJqnd8OG3U9Tl3kqaAtzl6ZpsXZ0tcccdumg2/Wgrq9xa8JtS8VpIUY6
HGtorXQMaBqiE04xlFas6l7VcKWDFeHqtkk3BXYbxWu8zS2lOw287nBJh/dx0cNpziQ2xNKdNGqD
Oa3Vvvtpgpyqlu3wwqFJhxW+OpUpFZX5fL2UcmxJTwpYH6uDwwQTxSaC0+EWDk9RYVHhBJ1oOM6d
Zjc6A4E2d8ZQBBrr7/dRyPW7peJOJm9goClC0SiyHFI64CfFsq5IqWjUB9cpFM0CBmnAxj4nHo/j
yQGFOXPiWXbhsWvakJiWmq1XOoTNcQLyhONElirdNn9GUPu5hQrmB11eaulN49xrNqSWxd+raZgb
U8etTWnFNtes2PYPWH1sTmG6Zm5fK7wQ3ska4tsM8JROK8IBH0e42yXc2KzpGF+H7c0B5JBuF8cJ
xfKg24nqjJmm7TNnUNU92LqeP+ilDTiYDOxB3mGpONd5MA00ePhJG46udaRqg26PdGclyhJlyHE7
7vDfgcDa7KcAYy0U7Wa485RknxnvHrd0e2ZYtic/M+lfjyRSniDkN2xoZeMo4sp8BJPbIdzOVMz7
UrbSZ9Z0hufUqHcKMjN7gz95Z05Hvht9ZuSboW/Gi7YG+9tjlx4K08zYd1ixz33a6YPfowkPBX8q
+h3oW0sRqOMctGao2r8b/h6b9DDeVvx7pPRkLMf/UAIgV5s4zfb/TycAj1Q8yQRwBhnAk8wAnmQG
8DjMDECFr8sATmFzGpAnnEa2Kj0ZGYAin5vSKYA6uSkjByALmE3+jA/lAQ/nAd7i1vMaoW1T3E5/
KhNYvWyYv3AwVW0C9NYtYQ0cyqhOL7T2SFNKM2tvctDxE+lAQ0LwuIXH7bXe4vctUKG+TseFhXqh
xyE9ViBxTvA4Uc8Nmk4XBnOp7h7YaGaF1o0DvDEpK1hpIV1noXtc0uNJY2Fk4HLypqRL00kCqrKk
Z1giJ5GzI29HXnxOfA6lytudtztbnaw1oe8AxUFt+gZQK2i9bjnAJxOODTeGjhHlQ9LGTNS/ibSR
GmymjVa2vmkDPC1wEqQeh/BkJA7fSd6k1c0QjCkhiP/0bzGqhK4XxI60wuzZPpPyyKMdvkJfoccl
PC5SYOYdZ+oQZj26cFZB1Hgd0ss56unddFTZ/fSQhyHuVfCZeg31XjOVr51SRJkFvTbhtU1JpxZa
Y2c6t7SuOUl5a6uZvVN4ZamGOzO9+BNeu/RyOrLyywavlN7MtdSdHunMfibR5d+QQU5M7EpOwhXr
IWqKJ93DaYbrSW/gGD9WWXlGtw6ylNyR2+luXlg4YLo2hbWaEwAGPEM5T/uUlUw3rIqfFJBvPJnD
kQfMozQiz1+oD3il4k2dVoekHKdU6ElSnJRzvMmc403mHG8y53g552Q7hNehKMmsYyUd29CkM0yV
Xko6hdbEKPm5jUvJrFOoc1vvkF3Za7Zl5h1OPF4HJR7e+ib8yRXwuAoCcWunn+B60wZgr1HuSdeR
fBSFQgN1M/koqbqZfdL6SH+RKTLzj9cjvJ5skS2+wfQd/Tt6WWIdDgR0JvA6pdc92NXVtXuwq7Oz
s2vQ60LDeSKsl4lEBpWh5TyB8PZ6T4hOPLsnMj4deqd+QvDGPkH1QW49kW44YY7jy9OXGZk6El4F
Sz6kAZc7M+onvNnS6+sd0zumf/qeiQdqDtS8OL+nZ3d7d3unt9PLunsT/Yk9iQOgHlAX6IVEZ6Ij
YXnJDrKubK/0Zp0nVlooJKkssTJxni56RQHDMCi6RCdTl6CyWevQ2bHpVYlEb9OYbLu9p8nrFF6X
kZP+nORp+hPUrxK8IOZ0RLQg5tLQInmHSe/wDnuHvXNjeXt5e1VPVc/lByYvmd6UU5BTwH50dlZV
Tc/JmV5V1dnJT1Rruuz2tV1drzZmOWWWm2Y59GEnfT48ZD5JVvHUVdO5X8VnWjX3V0+jBz540tWF
FVo2Pcsus+zTy8rKBsqsj5f612F7dK1JrMUVa0+eorMzS5FZWiKB/J78+DQjy1ZQIERB+tOb5ZBZ
Lurt6jnQ33+gp6fLujDj4/JK17BDvR8VdA0hfipNzce16VVcrpruzej78BDtGmpI+Qdf+Zx+oDc5
BT2sNu2mlfO2N9HJzZ52dwrrtuYBOPSASn9OVS6ILgeNAbmy8R9tufKc6m0V2yY/Or0/Bwd/fkDl
paGV8Z7+2hxQgWAjBr05OQXYAoNZipKVsfGBo02Vig32JHTcZ1w2AlcQvnTTsXF3ls2PnWuWeKAN
8DrHVvX09NgcIstZVVXV0zbcIbIddrvXi5lyaBFoZEJq0mbvl/QnOoaOrxP48mlYeLPb/KBYwI1c
sj7Uz439Q/d0v9lYMOTTb8NmcvbQh3ettWLJRfO6pzQdSEaLwQ1rurBaMBeopBvs0+1o7VrDDWtp
kdZkNOQygF1ppTRLFU9VRX9ugieNMp9X8frKdPNv6t1ip7JEqOXNkRoxsjpSuUJMrQnG6sR89Mgb
Fs3yY33oHef09zJ2kYUDglmTAliKs7ndbFFwfBgmzgGp1wUCc8T5ixZe7xcFNy6a58f5xBxD/1bC
J87lmooZhqe04/kDx5VRVg1HBnGWGC2+UR6OhsX9LB9i+SjLp1g+x/KFFZWROvEiy1dZ7md5kGUv
yw9Z9tG/9RGfk5R2lqNZ5rOcxfImlrfUrqhdIdey3MjyxyzvYvkzlrtYPpL6Fw9/T8ozlE4gqQID
OxBGBAGX/39tCtYh6x/+zha5/G+F6V+TtoqtYqd4TLwg9orD4nOpCBd76rS87RP07/RVXDcS2UDS
32/JqeZ320bz+6cDGddgvx3ZOaQuvYND69kXDq0PHzG0ftb2ofULTgyt553UP2H00Ppk5Csls34s
o98u5LXTh9bnb8a3G3s6TwTo/23ANa2AqkAJiHXK/crvxQ71p+pPxX4tpt0nXrfts7dJ1X2DOyif
cf8IDykven3e2crV3qXenynNWRVZtyj/O2tdVruyO1vJdip7s7/I/kJ5U0j9OGFjfyPrqdPSHtDB
rPcz6FOL9pyGjmWPTVEeaCqoCHQL07aTKWtP9s7sJ3x3WbQjgx4ioqPuacg9PJCizcPvTNFxk0aM
OQ3lgyaP3J5B95vEPSfRyMdGvpiiV8/uBX1IdI52OhqRf86Ic/LO3ZxBdzK9cFrac+6XScoZmTM6
RUUWzT0tBZhusr6Hkm5JGtfFtD9F5tXv5PSPmjCqYtTPRj1IdLL2UY+cjkzto54eddiiY2miWUZ9
yXPpxN+cP25qiuaPW5SiCotuAenjbqEfsT+/8IL8C4rG3QKZf8ELF7540RtMx/KKQeHxF4Imjj88
fgB8ePyJCS9e/DOi8Ycvfu7iTy/+dKI2MXviyInPgvbnzwAF8osn3WvR89/RL73w0o8nb718MmjG
FTlXFF/RNOUxi56b0jVl/9QJoClTN047dKWdKX7lC0yDMy6f8bBFT105iPrDM/q51n+VcpUy4+Gr
Jhb+uPC5mfmzl4DeuXb5lXFzNL77zVHXzaBx182fO3ZuwdwZcx+cdyFTYN4tTE3zNs67F7Jp3sug
3vmr5+vz37k+DLprQRlGBRa8uuDVeS9DHqIS6PCCvgVfLtSZdi3sYXpnYR/4nYXHA9rC4+jvCxQH
DgUOfy8G2rrIj3G7Fh43exatXnh80fuLjiwO3NS1ZMnNI24ec/OF1Vp1cfWB6i+T38sngh6r89WN
DTeFW8OJ8OFwX/j4Sm3lJSuLVlatDK9cvbJt5V0rH1751MrdK/dGwpGtkQcjn0dFdER0TnRZ9Lno
G7HJsWWxextuamhreL7hWKO9cWLjNY0PN364qmjVl01jmq5pKmuKNN3b9EjTgeaxzT9sfqr5QPOX
q72rz1k9ZfWs1RWrd60+cOuEW4tuLbl1260P3Xro1uNrCtesXvNci72lsCXS8mhLV8vg2tFrl6/d
tbZv3dR1Tese0QNfkaueOjkfDc02emOaKI/wn8NYZGaQr4i9uSdH3NA4MXf6abNOMvNk0NDcoXel
ibKDvj9NZl6gHOp7KKfr3DuRhw/O6EfW5BzM38i3wwPIr9uyd/ruytqTypkYO/z4uAq6Nuup7G3p
3GmihOxcxPnXHDU2e2cSPWqlXMxjD1I/j7cQhN6nst5HJt+JKw6ytj2w7i58H2RK3x0+PemuUJRx
H0jfCXaS3adk/4dOyf5uK+dv5nzPWZ714OrsIpS3JTMh1uNBa72Qm8z8Y+Y3ax2RE5EBadUqUtkx
uaLIcTlz9cN0RXqNxy3SD+uHoY1GHUNfYNThcYtO3RPIg/szMupp8mxmXj01p1qZu4t3k5lF5yfz
J+V1tGBWvW/Ug2hZlBO4fPKCV8/RzPsYf+Oede6XZ/diV41I3n2Sd5URY87R0ncgc1fSvY1HazQC
175wzgjqoRYaRe0jxmTtSe7UnNEjxuAOOIKup7LZmr6PZt5JyRa+a1r3zYw75whoOPk+eeeQu+Me
6844Mmk9+r80Z6f55wXO7s0pgj1D0CfUCGOsVEbEJjE2I5HQNHfKuArgPZdWk5DICYzczuv9IK1N
RlRPHfUIfE3eYfebWvW+HF3vM4lmoO9xi2hVqGTuNPrW+y7IP/8Sk8073PmX8F0pg+gOZ97d+P74
f0l8T82gU0fwnTaDrDtuik69gu60/xjxvfiMKXXH/go6GSmi1H38K4jv7GdMfNo4QzoZHT6jZNCp
+PHZJYNo35sr/Y/RqZr/vnVnRibOdHbJ3nmlfe7YKwezDtKphynOLXY66XAtPncsnYGsPhBOUFPo
1GS2Uu6nEhGfjpbwyYrOUP0z+vl8hNMRSi9cGefTiZ46xRDtWqgvOLRQpxMM13ZZ5xyzvAunoMPU
Qicaum6BRXziifHZCGO5dxfJUY9g9C46TSFbXLjgEJ+7miwKcMuFdOriWmDBIcpLVh8IJ7cCnNXo
hEbXbeQSiM9pYT7PYSyf1FLntXmBqxRGZJCw+F7MROJKO/sDi01L573MummmjayL9Q6NxFNXNHMf
XPSGWRN2elOeer3xHL0lj96RR2/CU58XVwh6h9Iefvsblfr4DViS32On0Bvp+H10HvErY1DsNgZl
mThLBsUiuUyMkuXiW7JCDJcr+K14k+ltb/x+Nwk97wkNY70YOxxjvRjrZn0fYNQR4ZL0fpoyMQ79
i9H/TfSPg64LoOtbuPrfYM879GYY4zF6u5u6Bna0GL+GvVPV94y71fdFgfqBuET9SFysfmK8pn6K
p13SvgfaD9ObAA2F3s5G72DjN7A1iWFirvCBp4rxYhqY3shWCa4C03vZ6K1sDeBG8CpwE5je0bba
2CtuBa8Bt4DXgm/D9RvAt4M3gn8EbgNvAm8GbwG3g58Rs8Sz4AGUT4ANMV4KsAQHxDT5PfAi8A3g
G8EhsZDeAkfvgFNvEtPpLXD0Djh6Axy9zYne/qbeJnK1nxt7tR3g+8B7xXhtH3g/+HXwG+Dfgw+A
3wQfBL8FPgR+W4y3+YzXbL3GXtsfhdfWh/Jn4H5jr90m5trH4/tSMd5+Ob5rjNfsteA6cD24wfjI
3ggGNnZgYwc29tVgYGP/DzHN/ij41+AvxDTHBHGe42JwqRjvKAMvA68ER8DNYB28HgyMHHHwHeCf
g+8Tsxy/wvdn4CPgfvCfwJ+DvwADQ2c5uAJcCW4Q57mEmOYaKc7jvfshv9eOSp/wO+nOxq59HLv2
cey2C7HbZmK3tWK33YDdtgy77TrstkJ6lxy9MU69yfgxvTOO3hhH74Wjt8Kpzxu71Pewzz4Qqvoh
9uAnYinvs/f5DXHDU1FRIiZl6J8D/Y3QPxv6r6C3uUH3nfQ+N3qbG72/jd7eBn3PQd9NIhtajkLL
UWjxQctF0FIHLZOgZRK0XAwtF9E7q+ita9BE77S7hN+0Rp6+RO9EEznQ8Vvo+C105MlS41nomQQ9
pdAzGXpugJ6rZMj4HXRNktuMp3Hlb6BPg75GWFYFnWfBstugbYt62DgG615WP0a0fiK+rX5qRexw
aJ0ArSFovQJaZ0Pr+dCYB2376C1BiLzr4eVi4bEyzN+QSSiz3CNuM/rEBvDt4I3gH4HbwJvAm8H0
7sh28MvGgHgF3AP+L/Cr4N+B94BfA+8F7wPvB78OPgB+2zDEO+A/gHvB74IPg98zXhHvgz8Af268
Jf6MOD8G/gv4OPgL8ACy21/R/yX4v8GD4L+BT8AWw+iTAiw5K76nFmOH/dA4qpbgu8w4qu01+rR9
4P3g18FvgH8PPgB+E3wQ/Bb4EPht8MfGgPYJ+FPwH8F94M/AR8BHwf3gP4E/B/8ZfAwMW7QTYMN4
xTbCeMVRaAw4ZoPngueBFxgfOW7E92JwMfqXgkvApUafowy8DLwCfSvxHQHHUF4FbgI3o74G3zq+
14M3ovwjMNbB8RN8x/F9B/hfUb4T/H94u/f4uOpy3+MrM22SJhOu5VoQwk1BAbkrKFet4KVudauI
e7vjBTQIiCAXdRdag7KRS70BRUVQitxsUWJRREKBQksgkLZJmmZKkzYdkkwnaZJmTaYF/J33mhM5
6Dnndc4/5/zxYWbWrMvv+X6f5/n91hAWt+I23O78d9n+G+8Xef+Q9w97/zh4VMWjKh5V8agqG0LV
evCoikdVPKrqc8xGbAKPqoZCtiqPLWIpYDi0V41gq+9GnXsM45jwmXdVRa+TPvOo+sv4Cs7nVyq6
JZpZnrnS0S1y99PJs6H4O92nxT592KdzZPny9MvRO6MKW4vRB2RmVmZmZWZWZmZlZlZmZmVmVmZm
ZWZWZmbtPSDTSjKtJNNKMq0k00oyrSSLCjKmKGOKMqYoY4qulzybLJv+92h6+ov4kgz6cuiXNVlZ
k5U1WVmTlTVZWZOVNVlZk5U1WVmTlTVZWZPlZJGTRU4WuZjlYpZzRa5luZblVpFTRU5luZLlRpbq
JaqXqF6ieonqJaoWqFqgaJGiRYoWqZilYpGKWSpmqZgtV2xPVEXLM1Rytbn3CXPv0nS7uXaVWchs
U9Y3L8JVItxY1vc/fUqeXbsffb/nDGujc82T9ebJevNkvXmy3jxZb56sN0/WmyfrzZP15sl6VzrR
XHmIufIQNduhZjvUbIea3ahmYzUbq9lYzcZqNjaf7qZmc2o2p2ZzajanZvkdfcS8ebw63ahOe9Xp
RnXam/5SdFj6y8mzZ6PrzKMHmEcPMI/OMnfWmzvrzZ315s56c2e9ubPe3Flv7qw3d9abO+vNnfXm
znq1mFOLObWYU4sdai9Wcx1qrkPN5cxx9ea4evNbvfmt3rxWr1Zy5rZ6c9shaiVnfquX/x3yv0P+
d8j/Dvm/Uf5vlP+x/I/Nf7uZ/3aT/zk53yHnYzmfMwfWm//qzX/15r/6JN/DOK3Hrc9uCd/nwNn6
+Ub9/ApOnM2Je317k2z/YHq1lVRH+Fu6M/pS2b2svXvs1W3GvCVc49OXHLvasWtsPd2xtzh2hWM/
7NgOx30uqpyqo8/as9OeHfb8cHl9leTMfeUzne/703z/ku+7fH+KM93g298705nO1OpM7y7vv668
TtxQ/mcxqqnYOTqg4jxchIvxDVyKb+IyfAs/NNPvmjwbM3kOZvIUzORZl+W10d3RXunHoxPST/F/
U3SwWftTVom7mbn3tUo8OD2oMwwZQd62LdEJ5vPLwlOO2NOa8qBkTnf8RdE5yZOjkyepReekv1Be
fZ0T7WRks4xslpHNMrJZRjbLyGYZ2Swjm2Vks4xsliNnOvISR8505CXlI+sqkmdpXoSL8Q1cim/i
MnwLPxTNeeWnJB/jyOQ5yceUj8w4MuPIjCMzjsw4MuPIjCMzjsw4MjN15PFTRx4vks9HR3h3RFnj
5vIaYTJ5XmXy/Cx8Ap/Ep/CvUY21W421W421W421W82M5N/TTkueM5k833BqpbG87NHGqKPiHWFT
xeE4Au/Eu3AkjsLReDeOwbE4DsfjBJyIk/AevBcn4xS8D+/HqTgNp+MMnImz8AF8ELPxIZyNc/Bh
fAQfxccwBx/Hz/EL/BK/wl24G7/Gb3APFuFe/Bb34X48gAfxEH6HxViCh/F7/AGPoBl/xFKrtWVe
nwo9FU/jGSzHs3jO9hWhs2IlnkcrXkDyzMo2vISXrSDOc7fyhdA+7VkrieewAivxPFrxAl5EW+ic
9hJeDp3Tdw2bps/EHtgTe2Fv7BM2VS7AHaBB5a/Cq5W/DVsr78P9eAAP4o+2P+PVarPyWe/bQ2fl
Gvt3e18Mm6r2x9twAA5EfdhadRAOxiE4FIeFzqq34x2hp+pwyIUquVDF96pjfT7Od6eEV6ve5/WT
YWt1KmyqTmMapqMSVajGDNSgFhnUYSfsjF0g3urdsDvEXS3uanFXi7ta3NXirt4Xs7AfjL/a+KuN
v9r4q+txEA7GITgUhxnTseHV6uPw3tBZfTJOse10zMaH8B/2+5LXC3z3Vft9DY24EFf4bi6uwbWY
hwW232P/++x/f+ipfsDnBzFuWxw2zaiAWGfsHjpniGPGHuHVGQfKoe+Wn4tKnQrqVFCngjoV1Kmg
ToUjKqhTQZ0KypSfnrordsPumIk9sCf2wt7YB8nzVZOnqx6AA1GPg3AwDsGhOAxvT54o7C77cByB
d+JdOBJH4Wi8G8fgWByH43ECTsRJeA/ei5NxCt6H9+NUnIbTcQbOxFn4AD6I2fgQzsY5+DA+go/i
Y5iDjyN5Muwn8El8Cv+KTxv3Z/BZnIvPIXl66zW4FvMwH99DE67D9/EDXI//QvKU2eQZsz/GT/BT
/Ay34jbcjuTJqb/AL/Er3IW78Wv8BvdgEe7Fb2EGrLgfD+BBPITfYTGWQK+t0Gsr/oBH0Iw/Jk+4
TZ4qi6fxDJbj2eR5rViJ59GKF/DPXeTT4YvJE3CTZ7cmz59NntuaPHs2ee7tNB1vmo43TcebpuNN
0/Gm6XjTdLxpOt40HW+ajjdNx5um401b4h7lYfwef8AjaMYfsRR/DsPTHsNf8Dj+iifQgiexDE/h
aTyD5WiLMtNewstRZvquUc30mVHt9D2wJ/bC3tgnqq28KQxX3hwKlQu8v837hWGg8g5zEg/K3exu
34ml8l7fGXOlMVcac6UuXflw2Fz5ezziu2YkXe5R+//Jtsd8/xc87vNfYZyVxlnufit8bvXdC15f
tK0NL+FltEeZyjWu7d6u0r1dZZdta8NkuVP2GJv7ucoBx7pnqSx4b3VdaXVduRXuWSrds1S6Z6nc
hgnEKIptMmyu2ikMV+2MXbAr9g6TVftgX8zCftg/qql6Gw7AgTgsylS9He/A4TjGtmO9HgezbJXZ
9b933ShTnYpqq9OYhumoRPL33dWYgRrUIoM67ISdsQt2xW7YHTOjmuo9sCf2wt7YB/tiFvaDcVYb
Z7VxVhtndT0OwsE4BIfi7WG4+p3u0d6FI3GUz1YK1cd4//dOfLz3J+IkvAfvFcfJ+Kj3H4P73OqP
O+5fwvLqT+CT+FyYrP4P47zAfv/cpd3vVrvfrb4Kc43hGlyLefa/wbXVf7lr3+Z1ofPegZ/jF7jP
+e7H37v4Q7bxsDp27GthckYUNs+oSP5Lo1CYkfxZe43XXW3fPcqUO7sZasZetu2NfaAfz9gv+V0y
qfSpddXc5NnQ5TXa029uvyR5DnP5d5RkvTUSTU+dHf4t/bHwjNVpTfLblu+Go3el3h3yqeNxEk7D
2WFV6pzwQuoj+JhV+afDBquL9VYX62vODS/UnIfrQ77mv3ADfogbcRNuhnu5mgX4EX6Mn+Cn+Blu
xW24HQtxB36OX+CXuBO/wl24G7/Gb3APFoV85p0hH6WNtJg61z3xZe6hTzH+2Pjj1MkhZ/xx6iyv
N4SNqR+6d/l8dKT+daQ9X6j5VMjV/Cs+g3/Dl8PGmgtxES7BpfgWrg+x2GKxxWKLxRaLLRZbLLZY
bLHYYrHFYovFFostFlsstlhssdhiscVii8UWiy0WWyy2WGyx2GKxxWKLxRaLLa79cNhY+xF8FB/D
HHwc/4JPhI1ij3l4UljLoRdTZR/DyvIvhweI/X5x35/6fFiS+gouxg1hGQ2SZ5b3iP1+sd8v9vvF
fr/Yl4l9mdiXiX2Z2JeJfVnN1WFJzbfxXczH98MS41pmXMuMa5lxLTOuZca1zLiWGdey6AwONHKg
0dj6OdBofJMyaEIGTRhnr5F0G0l3+tN/m0if+7c4+f8BcObo5P8FwJ2jp+7xl8uuCdk1YXTdRtdt
dN1G12103UbXzZlGzjRyppEzjZxp5EwjZxo508iZRs40cqaRM42caeRMI2caOdPImUbONHKmkTON
nGnkTCNnGjnTyJlGzjRyppEzjZxp5EwjBbop0E2Bbgp0U6CbAt0U6KZAN2cao7Oo0ECFBl48T4UG
fjyfOjvaX/RzRD9n6vfWG6fup49I/i8iyVPZk/+DSPJc9qlfiT/Hq+d59TyvnufV89SYQ4051JhD
jTnUmEONOdRooEYDNRqo0UCNBmo0UKOBGg3UaKBGAzUaqNFAjQZqNFCjgRoN1GigRgM1GqjRQI0G
ajRQo4EaDdRooEYDNRqo0UCNBmo0UGMONeZQYw415lBjDjXmUGMONeZQoyGqkgsTIs6I+McivlLE
u4nwGhFeFe1Do+X0WU6bLtp0JU8oT57X7dufin+5+JeLf7n4l4u/S/xd4u8Sf5f4u8TfZRxdxtFl
HF3G0WUcXcbRZRxdxtGlVhrDff/U7yaiI1Of0OPORaM+d6Ee93VcBOc24r43e91cPePa8ELtd0O+
9j8xF9fgWszDfHwPTbgO38cPoDfW6o21emOt3lirN9bqjbV6Y63eWKs31uqNtfpirb5Yqy/W6ou1
+mKtvlirL9bqizvNQA1q9byks+fLY4/VeE6N59R4jm7Jffphvl2tdnNqN6d2c2o3p3Zzxh4be2zs
sbHHxh4be2zssbHHxh4be2zssbHHxh4be2zssbHHxh4be2zssbHHxh4be2zssbHHxh4be2zssbHH
xh4be2zssbHHxp70rHPDOmq/SOGn3uxZSUS90bEiavb9Jt9PcuN1brzOjdft22vfavvWqpQakR6l
UmpEe9TUb0DPceh1Dr0uymZRNouyWZTNomwWZbMom0XZLMpmUTaLslmUzaJsFmWzKJtF2SzKZlE2
i7JZlM2ibBZlsyibRdksymZRNouyWZTNomwWZbMom0XZLMrm6ASRNPFmJW9Wphqj/fizUgRfVgHb
VUBRJNeJZK+pX2b2Sn6ZEcntya9ZvFvJu5W8W8m7lbxbKaomUTWJqklUTaJqElWTqJpE1SSqJlE1
iapJVE2iahJVk6iaRNUkqiZRNYmqSVRNomoSVZOomkTVJKomUTWJqklUTaJqElWTqJpE1SSqJnV8
brmO3yOKl6f+ndNso/6pUT8S1Yq3TbxtYm0T1x5i2sM3t4qnTTxt4mkTT5t42qLK1BV8vTJsT10V
Xk1dJy9uDiOpW5Nf2m3dkbouFKMK/9weHW6PYupqGfFtXBc6Uz+IqlPXO/qmMJi6LXnGeXgtdUd4
rdb6ttb6tnZ/vA0H4EDU4yB8xT7n4wJ8FV9DIy7E13ERLsYl+AYuxTdxGS7Ht3AFrsRVuBrfxnfC
a+V4dhhpf2puGBDL5tTPwtaUO73ovNRlsv1yXGHr1aL8Nq4N7al5mI/v4bpoj9QPwsOpBfb7UehL
/Rg/wU+xMDwmvsdqU+HF2jSmYToqUYVqzEANapFBHXbCztgFu2I37I6Z2AN7Yi/sjX2wL2aFERqO
0HCEhiM0HKHhCA1HaDhSe3Jorz0F78P7cSpOw+k4A2fiLHwAH8RsfAhn4xx8RRzn4wJ8FV9DIy7E
13ERLsYl+AYuxTdxGS7Ht3AFrsRVuBrfxnfCY9E0mbOBimuouDF1WxiTS9eFcXkyGf0LF0pcKHFg
BweSDNtoximacYr2KFK5ROWSGaZohimaYYpmmKIZpmiGKVK/RP0S9UvUL1G/RP0S9UvUL1G/RP0S
9UvUL1G/RP0S9UvUL1G/RP0S9UvUL1G/RP0S9UvUL1G/RP0d1N9B/R3U30H9HdTfQf0d1N9hliua
5YpmuaJZrmiWK5rlima5olmuSN0SdUvULVG3RN0SdUvULVG3RN0SdUvULVG3RN0SdUvULVG3RN0S
dUvULVG3RN0SdUvULam5K2V3UotzaXqN7L4u2ona/dTeRO2t0aU0bqFxi0wftOdKWvfTuj/1HZ/n
hiFHjcv8gswvyPyCzC/w4Q0+tPChhQ9jqVvCChWwVgWsVQFrVcBatfSi3vAcjzp51MmjFh618KiF
Ry08auFRC49aeNTCoxYetfCohUctPGrhUQuPWnjUwqMWHrXwqIVHLTxq4VELj1p41MKjFh618KiF
Ry08auFRC49aeNTPo34e9fOon0f9POrnUT+P+lVIQYUUVEhBhRRUSEGFFFRIQYUUVEhBhRRUSEGF
FFRIQYUUVEhBhRR43MLjFh638LiFxy08buFxC49beNzJ404ed/K4k8edPO7kcSePO3ncyeNOHnfy
uJPHnTzu5HEnjzt53MnjTh538riTx5087uRxZ9TIwRwHcxzcxu+nubiVcz2c28K5Ec6NcG6EcyP8
z/D/Ee4VuFdI3WjbzZxeEBZzcJCDgxwc5OAgB4c5OCZPnuBiLxd7uVjgYoGLBS4WuFjgYoGLOS7m
uJjjYo6LOS7muJjjYo6LOS7muJjjYo6LOS7muJjjYo6LOS7muJjjYo6LOS7muJjjYo6LOS6NcGmE
SyNcGuHSCJdGuDTCpREujXBphEsjXBrh0giXRrg0wqURLhW4VOBSgUsFLhW4VOBSgUsFLvVyqZdL
vVzq5VIvl3q51MulXi71cqmXS71c6uVSL5d6udTLpV4u9XKpl0u9XOrlUi+XernUG72bS0UuFcvV
+N9dmODCGBfGOFDkQHLfNEbdMeqOUXeMumPUHaNukbpF6hapW6RukbpF6hapW6RukbpF6hapW6Ru
kbpF6hapW6RukbpF6hapW6RukbpF6hapW6RukTpj1Bmjzhh1xqgzRp0x6oxRZyw6Qmd4XWd4XfUX
zOc1qRtFcZMoyqP3/jYsNN/fYd6eZVW3H/bH23AADkQ9DsJX7HM+LsBX8TVYQdJ6ktaTtJ6k9SSt
J2k9SetJWk/SepLWk7SepPUkrSdpPUnrSVpP0noy+hqtB2k9aMQFIy6ogrwqyKuCvCrIl/X/ewXQ
/X/KfCv4VPLLxv8+2wf5MciPQX4M8mOQH4P8GOTHID8G+THIj0F+DPJjkB+D/BjkxyA/BvkxyI9B
fgzyY5Afg/wY5McgPwYpWKBggYIFChYoWKBggYIFChZUQ1415FVDXjXkVUNeNeRVQ1415FVDXjXk
VUNeNeRVQ1415FVDXjXk/y+qIc+hPIfyHMpzKM+hPIfyHMpzKM+hPIfyHMpzKM+hPIfyHMpzKM+h
PIfyHMpzKM+hPIfy5Tl+tPxvIU/kVYFXBd2moNvkaF+gfaJxgcYFGhdoXKBxgcYFGhdoXKBxgcYF
GhdoXKBxgcYFGhdoXKBxgcYFGhdoXKBxgcYFGhdoXKBxEmNBjAUxFsRYEGNBjAUxFsRYEGNBjAUx
FsRYEGNBjAUxFsRYqE1y4Qpciasg38RYEGMh2kUvjv+xZmTajeVKL+qpxf9TjVi7X2mN6s5UtWVU
W6Vq26jS9lBpNdGcNzvKFWbjubjGffl1rnVDGJXZo/Yuqc1Rs/OEo46icJHCE29ZNY3K7lHZPSq7
R2X3qOwe/f/UbUZl36jsG5V9o7JvVPaNyr5R2Tf6/3RVlNytlCi14s37lokoPbWtxKXXok/TtpW2
rfwb5t8wbZM7mx5OTKfvAH0Hyv1vgc8/c49wq5XSQtvuCAN0HaDrAF0H6DpA1wG6DtC1la6tdG2l
aytdW+naStdWurbStZWurXRtpWsrXVvp2krXVrq20rWVrq10baVrK11b6dpK11a6ttK1VU4Ny6lh
OTUsp4bl1LCcGpZTw3JqmO4DdB+g+wDdB+g+QPcBug/QfYDuA3QfoPsA3QfoPkD3AboP0H2A7gN0
H6D7AN0H6D5A9wG6D9B9oDaJ8wpciatwNb6N74SBssbbpyqhFO2eWhrtmXrKivNpeflMmJdaEe5P
bbPOiMOC1PbQntY500e6ez06PJw+PuTe/Gvlz0S7pD9b/j/8JX9TOJjJhpc4tsh5l+BpFfBM6Egt
l+nPYoVrrvT6QsimXnKn2+FqnV67MBjNSA2p1Ngat2glNIkdYSwdhb50Faqxj7v/o0N/+piwLX0s
jsMJoZg+JWzKNIRC5vzQlvk69IjMN7xeGrKZb0JPyHzX61yv18AaOtMEM2bmZqjKzALf/9Q2vS9z
u88L8UvnWBS2Zx5w/ofx+7At8wc8Yluzz495FVOm3bZVWI21Pncj6/169NlvOPRltmEy9NXNDCN1
e2BPuDusc3dYd4jtF4a2Omv6OuOquz5M1N0cttXdijtwTxiJPjylag+fSlRdS9Vhqg5T9XWqbqZq
N1XXUnUbVddSdS01i9Qcp+Y4JccpOU7JcSpup2JMxZiKMQWHKdhDwbUUXEvBHgqupWA3Bbsp2EPB
7n9SsIeCwxQcpuAwBbsp2EPBHgoOU3CYgmupN0y9YerF1IspN0yxmGIxxWJKxZSKKTVMqXFKjVNq
nFLjlBqn1Dilxik1TqlxSq2dUqqHUsOUiikVUyqm1Hh0UOrB8N3U0vB7SrXIwdco9FuqbEltCF+V
Z1ekhsJdsvszqQkr7e3hVHn2XDodlqcrwy3pTLhEtnemZ4b69AHRBelDw7dk/kHpo8KZVLtH9s+W
c79InxquSZ8RPj/111m96c+Gu9PnhgvTjeGJ5O+XRPUXPekps8QzWBFeccVX+bHBFXOuMOSso864
yRm3qqVT1NL73RE+yLGnwipHJfXyYrlGBqO3OXq1I5935GZjyxlbrTN0lOvh+NDhyKfC84561VGP
OmJ3R2x0vd5y/bqrLtfwAer0SJ+PDhsc1WeUy6P9Zda28pHLZdazWCljXnD0S7Kqwyqy02tX2Cw7
NsuOzTJjs8zYKDM2yoqNsmKbrNgmK7bJiJKMKMmIkozYKBNKMqEkEzZzbjPntnEt6fyD0U7GU2nk
i1zvQdf9s1gfw8qwg67r6ZnLXB2Kzj/u/OPOP565w+dfhaLzjEfTHDVh5Jc5YlOS91bCD+olS8Xy
TGi3NZtapY8kGm4Iebqtct61zrs2OtdVF9h7nprqL2fLn8NcV5/ryDFK7KDEDmfop0SgxMRUXU1Q
YiLVHZY4Y7NMak8VZE8NZobz03tyYy/sjYPD5elDcGjYkn4Hnw/Hkdyje/o0359R/tvlY4zmGLXX
T90J6k6ovX4KT1A4UDiovX4qzKV0oMQCSiygxAL110/tHdTeQe0d1A7qr1/99VN9B9V3UGsu5Sco
NjezWCdagsfD5ZnlXl9EG17COvTgFd/1et3oHJvC5XVReK5uelhSV4kq1Pt8GC7UoeaHBWqwn5s7
6m4Lm+pux0L8HHeGJVGtjByXjZs4fZzu84bu84bu8wbXT1Lpb6j0N1T6G6r6jWg/fiReFmk/SvtR
R1XqUWN61JgeNSb2CbFPiH1C3KPiHhX3qFhHxTqqv4zpL2N6y5jeMqa3jMnvMb1lzFgnjHNUrxjT
K8b0irGKGlecLwNu4/4y7v+E+z9JPcHRFjwVVqSWmxWfxYpwjyx4LbXa9g651R2uSK0Lf031IIv1
eAUbwvWpXq+b0O+cm73mMIDBaL5saU7lvd+Cgswb9jqCreHy1CjGvB/HttCoN7Xr3N06d7cK/owe
9VLqNd+9jjfCE6m/eQ1m4QqkkPSvabJtuveV+lRNmJeu9T4TLi73s5297oJdsRtmhlNk69my9WzZ
era59QfpfcNV6Vm+2w8HRJ9L13s9CAfreYfg0PBv6cN8fjve4fPhOML7d+HIcJYe+UWdZTHX5nNt
Ptfmy/aP6Zc3p0+0z0l4T/he+r1eT8Yp4dr0+7y+H6eGf1cVZ6dP9/6McJnK+MzUX8wuViFXpc+L
9k5/AY3hZf31d5nG0J65EJeG11TJayrkJyrkNVkyX5bMlyXzM/N9/z38F27AD3FTtGfmZtyCBfa/
1bbbcLvPC3GH8/zC5195vStcnPk17sGi8IPMveEqs9m1mQd9fgi/w+IwW1XNNsNdKwPny8D51gc/
MMtdm/lj+F5mKR6132O2PW6/v3r/BFpsX+7zCttXOm+rbS/gRdva8BLanWsVVmON/dfatxvrfNcD
3Vt2z1e1szMbwl9V7myz6LWq92zVOzvTb5sczMjBzKuQh5lBDIVlGXmYkYeZAuRgZitGMaYDjKPo
fSk8kdmOHd6/ATmXkXO6wrw6eVcn7+rS4Ym6aV6nhyt0iSt0iSvqqn2eoXvUQA7WZcKyujrs5P3O
2MX2XbEbdrd9Zug203eb6bvr9nK+ve2zD/bFLOyH/e17gO8PRL3rH2SbDqsbzau7NrSr8Pl110d7
1vG6jtd1vK67ETfhZt/9NFyl8ufrVLN1qtk61WxdYL5uNbvuF85zp3Hf5Zz3OP8in+/Fb3FfuDyq
1yUu0yX+UJ6Zny7P58/qBAMqfoHK/neVvVTVPqxqnzfnxir2SRXbrypXqcZWVfiEKlyj6j6osr6g
kh5WMTermGdVzIAquVWVrFEFLbL/Xtn/cdm/TPYn/6XCiTL+5ehL+tUDRvI7M9bq1MNmqaV6wp9t
ewxPm+ee8d3y0KV7dpm5lulZw2aupebAYaMdMnstNXst1b8WGfmz+tSQkb+kFy036m79ZpN+s8nI
B/TrDiPfqmd36Nkd+slyo1+sFyzWCxYb5WtG+clkzWP2Wp35ok57flhqBltqBlttBluqNofV5rAZ
bLX6fEB9DqvPB9TnA+rzATPY6sx1jvs+bsRNoUtX79LVu9TmsNlstdlstQ7fpcN3qc0HzGZL1eYD
ammxvF8szxfL6SHzSYf5pEPeDplTOuTqkDxdLi8XyctF8nKRXBySa5vk2ia5tkluDcmtIXm1SV5t
klfLzUUdcmq5GW6pnHrADLfazNElPxbJjyH5sckK8gl50IKnrNBWhD9TerPZYZVcOFM3X6+br5cP
L1C1j6rtVG2XE3/SuTdQdqVOvZ6yKym7Um5skRuv6sZrdOM1uvEaOfIuOTKpy/bosj1yZZ08yems
bTprm87aJmc6ddN1umi3zrlGR1ylI66i+maqb6b2Zh1wlQ64SgdcpQOu0gFXUXazrrdK11ul063S
0bp1sR5drEcX69bF2nSxNh2sWwdbp4Ot063W6VY9ulOP7tSjO/XoTm26U5vu1KY7rdOVenSlnqmu
1KYb9ehG3brRGu6s1FnW6yzrubSSQyt1lw26ywYdZINusV63WK8zrNcZ1usM6znVzql2TrXrCht0
gPWcaudUu8pfz6mVKn+Vil+l4lep+FUqfpWKX6Xi21R7m2rvUe09qr1Htbep9h7Vvp6L7ap8vSpf
r8rXq/L17okHrY6TdfXx4fXoBFWW3Gd9XUUtVFELVdTTfJ6narbz9bd8beZrs2rJ87Wfr0t4uoSn
S1RESRWUeDGPF/NUQIkf82R8SZYvlOULZflCXsyT5SVZXpLlC2X5Qtm8nV5L6LRENm+n1RJa9dOq
X1Zvp1e/TN5On2b6NNOnmT79snm7bN5Oo2YaNdNniewtyd6FMne7mJvF+Ey4WcZOiuAJn7YZexwe
lJsbon1Fts2nnMiGRDYkslFRtekDeZG1iazN6LYZXZvRtRndNqNrM6ptRrTNiIaMaMiIhoxmm9Fs
M5ohoxkymjajSO5lh6IDXCl2pXWulHOlnCsN0jC5R213tQlXa3e1dleLXa3d1dpdLXa1dlqM02Lc
VWNajLty7Mo5V865co4W464eu3rs6jlXz7l6u6sn94c59wgb9Mtt4WVRv+zKE664Xi97TMddq+Mm
9wd/KnfcSntNTN1D5af+G6aj0+dGx5aV6/PNet/0lT8l93avlXWcPnXUuE8F5+9y/jGr4W5r2gKF
d4izhhIRpluTVqIK9T4fhjvDqHNsKDuzyt5Zs0gyxonoMOd41jd/pt+4c/3FHq/+/f6+PN9E+ksV
qlET/iKqT4jmy3Qcp+MGOm6gY3J/vYF+48bwF2N41hieNYZnafmP992zsN9b7r/r7X+IWjzM6532
v8u25J67Qswj0V7GN2ZMY8a0xZi2TP2Cs9Xoh4xrq3FtNY6txrHVGLa69phrj7n2mOtucd0trrvF
9ba43hbX2uo6Y66xJTrE2R8X/XMiX/mWLttB58WuVCx31ZryX4p8f8rLdaJvTP6i5+/dR8QrXfVx
V33cVR//X3aepNPU2y/pMod5TTrGnfb9544xozyLbrMO2O7eupKvnw6XTv11x8uu/LnyX4wea9wb
7PknrrW5L+gy/iep9PBbOkgyM3RT6k5eJ/Puq9S6k1p3iudJZ73R2ZZwsc3arYuCd1LwTk62UfFO
FdGtIro52ia+J1VFtxg3iHGDGDdwtc0arMsarMt6q+ufOkc3l9u43PZm56h3jkPCnWJ/UtwbuNxW
7h6zqJ6lerb8a0Ssi2wPzxj1MOWzRjxsxMlvOMPUzlI7a5TDRjhM5SyVs1TOUjlL5SyVsxTOutIw
hbPUzVI3S90sdbOqKtZ1d5j9ZI8Mi8OTUcosuMNKaXuUthpZ4dOYTwNRvU8j7mFK1icj1icjZspJ
M+WkmXJy6jfCvDXLqHV8yYyXN9PlzXSTZrpJ6/WS2S5vjV6yrhixJi+Z3SbNbpNmt0nr7pJ1d8nM
Nmlmm7TuGDGz5a09Rsw0k2aaSbPLZDTDXL7dSH5p7h4xZyfruldddYSD93DwnnJXmWG2n0jP1EmO
DAURDNmrkD4h2lmHcc8THeM63dE059nsPMlvrqUkAhFnyr8g5JP9KTFTPZ0QSrYnv8raw3Gboj18
SqKfEP2E6CfKkZ9nrfCF0PmWyCdEPlGOut3rKqxGFushOpFNiGxCZBPRga72En1j+q6l79q33pm7
dsFVcrSNXSHnCrk378YfKf/il6NtTNu1tI3/4Q59rc/d5V8By3fqtF3r6jnarn3r3XpUIfI4OiRd
593McJfV0ojV0ojV0ogxPWpMj1IrtmIasmJKfl0bptMWK6MRDrzOgYc48JD7yN3cRyZ/HZmseoas
eoaM61GrmyGrmyGrmyGrmyGrmSGrmSHjedRKZsgqZsSYHrWiGLKiGLKiGLKaGIqqjOYPrrzNFUuu
uM3VtrvaC672QnSwbzfSbcAY1xnjOnsWp37D/h8OnWBld4q8PoMOi8IADXfQcMebLj1iW7PPj3l9
3Eprhde3urbW52783b1X7NNn/01h3T+4uCfV+qjWR7U+SvVRqs+4e6d+k+qjSB9F+qjRR40+avRR
o48afdToo0QfJfqo0EeFPir0UaEv2lecr4jxFTG+IsatYuwQ4xoxrhHjGivVJOvWiGeNVWXeqjIv
llesLJMMXCOWNWJZYyWZF8cacawRxytieEUMa8SwRgxryv8V5cHp/4gOjhZGXwl3ROfjAlwe7o6+
E34cfRf/ibm4Bv1hYbQZOYzbZ3v4UbQDr+F1vBF+VPGO0F5xOI7AO/EuHImjcDTejWNwLI7D8TgB
J+IkvAfvxck4Be/D+3EqTsPpOANn4ix8AB/EbHwIZ/834s4EPIoqXcOn6lRXVVdXhz2sArKDo4Iy
OOISx2Hc2ERFERBwQBFMEBQQCAF3FJB9B1kEIYICEhVZXRh3ZW2gaQiyEzqhosie2Oe+1cS5OuLo
zJ3nucnzWtvZ6tSp//++PNINt8Md0BJaQWtoA22hl6iofaDe1z5UK7WPYAP8HT6GT9U67TP4HL6A
L9U6Y44ab8yFefA1xxthE3CvRgKUGhcoraYHyqppAVR2AJUdQGUHKkIlqAz71PhAAWWOw7dqvNkQ
mkG6mm5mQB94DAaoueZAYN7NsWqzuVmtM3E8Vj21zqoPDdRKqyFcBVdzfD10VNOsTtBFjbOmwgLY
x/F+OAA8M+uYmmvFoZBrJzk+rcbZutpsSzAgACagFG2Uoh0EB0LgQhhSoBSUhjJQFsrBtWqd3Ry6
sv8w26fYLmKbrVbap9TmIG0Fy6GPHxBl1UZRDoh+ogKkQkWoDw2gITSCy6AltILW0Abawp3QDu6C
u+FeuB96qFms3Fms3Fms3GGiv3pFDICB8CQMgiEqm9WczWrOZjVns5qzjZFqozEKRsPLMAbGwjgY
DxNgIkyCyTAF5lBvLsxT2Tz1WYGdamNgD+TCN7CP80fYHoUCrh+Hbzn3g9pommBBEByoBJWhLtQD
5sFkHlgd2WZTts3YXsf2VngAukBX6AbpahYrZxYrZxYrZxYrZxgrZ5jJ/ZrcLyso237MnxsxXm0W
E2AiTILJMAUWwiLIhtdhMXwBX8JX8DVshE2wGbbAVtgGEdgOUTioVhATVhATVhATPhffw0k4Bafh
DJxTy4gTy4gTy4gTy4gTy4w8tdk4BnHIhwLAnRgeFMK38B2cAByLcRL8eglQahnv2wqLWGDx7lu8
6xbvusV7brVRn1v3sG0PHSnTCbqoZdajHPeHAfAkDIKh8AKMAN43izmymCOLObKYI96nZdarbBew
XcZ2DTAPFvNgMQ8W88C7toJ3bQXv2gretRW8a5/zrn1u5UMBFFL3JOeZD967ZdoVwhBlRABM/+tx
/O+sgCD4n94dAjf5/dNlRAo0F6niOuihMlnjmazxTNb4ANZ4b9Z4b9Z4b9Z4b9Z4bzGYFoaoDNZ5
Bus8g3WewTrPEM+KUuI5eB5egBHwIrwEI2EUjIZVorpYDQfVEJ7oEJ7oEJ7oJJ5oNk80myeazRPN
5olmC/8TpM+pLJ5qFk81i6eaxVPN0mao7dpMmAWzYQ7MhXnwKsyHBfAaLIRFkA2vw2JYAm/Am7AU
lsFyeAtWQA68rbbrjUUpvYlI1ZuyTYPbVKZ+u3pCbwntOO6lntZ7q3T9UUhX6Wi2lrKT6o9uaym7
su2vvpAD1Ba5WQTkFlFebkP1bseV7xCOPKiy5SG0yGHRQB5he9T/bCC2+aKs0V+UMQbAQHgSBsFg
GAKZMBSyYBgMhzkqg3iRQbzIMLaKUsY2iMB22AE7IQq7IAa7YQ/kAvPJas9itWcRazIDZdR2Vv0Q
YkxGIF84xJdM4ksm8SUjUCTKmBJYW2ZZKAe1oaHKMBuxbQJXi1RiSoZ5DfvpKpP4kUn8yCR+ZBI/
BhA/BhA/ehM/epusJXMIsJbM6Wq7OSP5L+i3W5dAdagBNaEJtFHZvGlDeNOG8KZlWf1EKetxeAqe
hvEwlfNz2M4T1Xmbsqwl7O+j/H44AKw53pxJvDmTeHOyeXOyreMiaHlQSPmTXGf98QZlWWdEKbu8
2m5XgFSoCJWgMlSBqlANGKvNWG3GajNW+1KoBbWhDtSF7rTVAx6CLI6HwXC1Paip7U4H9YTTEbJU
ujMceG8c3huH98bhvXF4bxzeG+dlGANjYRxwv84EmAiTYDJMgakwDabDDJgJs+AVmA3MjzMX5sGr
MB8WiFKhTBgKWTAMhgNzG2JuQ88A73eI9zvE+x3i/Q4xzhDjDDHOEOMMMc4Q4wwxzhDjDDHOEOMM
McYQYwwxxhBjDDHGEGMMMcYQY3QvE6VSguBAiPigy028KQeJRv6e/9kjFfUniWZu8tsFTLDAhiA4
/hclJb8uyf8Ee9f/3hEUQAwFEEMBxFAAMRRADAUQQwHEUAAxFEAMBRBDAcSIfOWIfOVQAnGUQBwl
EEcJxFECcZRAHCUQRwnEUQJxlEAcJRAnSvYkSvYkSvYUjyhP9ILe8CikQwb0gcegL/SDx+EJ1YuI
2peI2peI2peI2peI2pdo2oJo2oJo2oJo2oJo2oJo6hBNHaKpQzR1iKYO0dQhmjpEU4do6hBNHfLu
HvLuHvLuHvLuHvLuHvLuHvLuHuH/vSMbXofFsEpUJvJWJv965F+P/OuRfz3yr0f+9ci/HvnXI/96
5F+P/OuRfz3yr0e07ke07ke07ieO4mXz4BjEIR8K4Dh4UAjfwndwQk0lsi8ksi8ksi8ksi8ksi8k
qg8mqg8mqg8mqg8mqg9G00fR9FE0fRRNH0XTR9H0UTR9FE0fRdNH0fRRNH0UTR9F00fR9FE0fRRN
H0XTR9H0UTR9FE0fRdNH0fRRNH0UTR9F00fR9FE0fRRNH0XTR9H0UTR9FE0fRdNH0fRRNH0UTR9F
00fR9FE0fRRNH9XuFKlaO7gL7oZ7YIaKkIkiZKIImShCJoqQiSJkogiZKEImipCJImSiCJkoQiaK
kIkiZKIImShCJoqQiSJkogiZKEImipCJImSiCJkoQiaKkIkieIkcvMRavMRavMRavMRavMRavEQO
XiIHL5GDl8jBS+RoXwlH+xo2wibhkMVcsphLFnP15v6/UWX7F7a3qeFkszZkszbJbNZJFeg9oBfZ
7SdZTc9QBWS2G8hsvclsN5DZeuPFx8on1JtyjfpIrhcp8kOy3yb8/BZ8+jZRkSwXJ8tJuRN/fyHT
Bch0dZKfMRnnfD6Zp79wyXIuWc4ly7lkOZcs55LlXLKcS5ZzyXIuWc4ly7ko6ThKOo6SjqOk4yjp
OEo6jpKOo6TjKOk4SjqOko6jpOMo6bgxVXnGNJgOM2AmzIJXYDbMUS3InC3InC3wXTn4rhx8Vw5Z
1CGLOmRRhyzqkEUdsqhDFnXIog5Z1CGLOmRRhyzqoDM9dKaHzvTQmR4600NneuhMD53poTM9dKaH
zvTQmR460zNOqQLjNJyBs3AOzkMRFAPvBJl5MJl5MJm5J5k5Qmbuh/+L4v+i+L8o/i+K/4vi/6K4
hBguIYZLiOMSYmTwFoFDysMpxHAKMTJ5TzJ5zwBjCjAmMnoLMrqLa4gFEhwr5ZkCNNBBCpdM7+Io
YjiKGI4ihqOIkfldMr+Ls4jhLGJmNcpeArU5V5fjekCsxWXEUAYtUAau2ZjrrEHUQTlcRwyF0AKF
4OI8YjiPGM4jhvOI4TxiOI8YyqEnyqEnyqEnyqGnSRw1iaMmcdR8AvrDANULNdELNdEXNdEXFdEC
PxtFSURQEhFzdvITmVLN5fB28lOZUs2P2W5WOaiMiMmzxPdGzTMiFcURQXFEUBwRFEcEL5yDF87B
C6/FC69FgUTww2vxwznWdcLBE+fgCzx8gYcv8PAFHr5gDyplIb7Awxd4qJV+qJV+VmdVYD0AXdRg
/IFnpbPPO2X1gcegL/SjzceB+8I77ME7eHgHD+/goXAcFI6Dh/DwEJ41kvKjkp8q6KF6HPyEh5/w
8BMefsJDBQ1GBTmooMr4Cg8lNBgl5OAtPLyFh7fw8BYe3sLDW3gopH4opH4opH4opH7WIdo+DEeA
WG8R61FNU1FNU1FNC1FNC1FLg1FL/VBLC1FLg1FLDl4/iteP4vWjeP0oXj+K14/i9aN4/SheP4rX
j+L1o3j9KF4/iteP4vWjeP0oXj+K14+iuiKorgiqK4LqiqC6IqiuCKorguqKoLoiqK4IqiuC6oqg
uiKorgiqK4LqiqC6IqiuiH0VY7oarlU5dnPoStvdOe4BD8HDnOvJ9hHoBb3hMRVHoUVQaBEUWsR+
ijpjOb+Istlqrf06+4vhlIoGhUhFwUWC3FuwnMoJVhCOc7c66NwD90IH1QZl18bpzP4gVeAMhkz4
Uek9zf7zMEK4KD4Xxeei+FwUn4vic1F8LorPRfG5KD4Xxeei+FwUn4vic1F8LorPRfG5KD4Xxeei
+FwUn4vic1F8LorPRfG5KD4Xxeei+FwUn4vic/8fFZ/7M8VXQYxR12tdRGutm7hbe1AM0v4m/qp1
F9drPcR9+m2ig95L3Cvbq5tlB/VnuVotlOtVa3lAfY42LC+JcPKIGi/z1KfymKgq4/itfHVa1BBj
EhvEErVV/F1tpfUbSz4NthmtX0brl9H6TVovdZrcephecHO4svaqOb3cQC8D5Fq1Rq6D9YkC+YF6
hxy3U36kPpYb1Bh6f46ez8rD6ii9N6f3sfQu6X02vW8QttyoFsjNjAknL7eq7nKbWiUj1NqhdpMV
c9GpS9QnjO0TSt5P7txI6amUzpRbEwlKz6P07eTRd6jxJDVmJD/b8UpGm0U2v4TsfbvemkzeS/XS
+wipL0Ynb1B/0z9V0/S94o/6KTJyeVFKXqlek2uFS5a+kjt4i54+xY9KuRWvuV29TZYO0HqCO4qQ
qTNLMrUs8aSSOzsqj3FXcc7nq+PafcJQq0QATLDAhiA4EAIXwpACpdQaURqaq93iOnhWLRfPwfPw
AoyAF+ElGAmjYDSMYQ5XqS1itdqi6Wq3JsGAAJhggQ1BcCAEYSgNZaAslIPyUAFSoSJUgspQHWpA
TbgUakFtqAN1oR7UhztVrtYO7oK74R7IgmEwHJ6Cp+EZeBaeg+fhBRgBL8I4tUsbDxNgIkyCyTAF
pqpdemO1XG8KadBOvae/pGL6SBVjlbfnqRSwzopZY8t5EgWssbassWJ5OpEnz/BGnFWWPJc4I88n
dssiZcrixFH5g0qTCc4rVdkIJPIMU91sWMoy7MQZI5jYbTjKNEKJo4ar0oww51Mo11+tMgbAQHgS
BsFgGAKZMBSyYBgMh1fVbmM+LIDXYCEsgmx4HRbDEngD3oSlsAyWw1uwAnLgbXgH3lO5xipYDWtg
LayD9fA+fAAfwkewAf4OW9VyYxtEYDvsgJ0QhV0Qg92wB3LV8kCRWmVKYP2aAbXGLMu2HNSGRtAE
rla7zWvYjla55hSYxjH3ab7GPvdjcj8m92NyP+Yyzi2HFZADK2EV51fDGlgLjN1k7OYX7H8JX7H/
NWyETbADdqpdZoxrRyEfvoMT8D2chFNwRuVaKVAKSkMZqKR2WZWhClSFatBU7baugX5qufU4PAVP
w3iYA/PUFmsJ2zNquV1f5dqXqd32FWwbs20Dbdm/X+2yu3O9BzwEL3F+GuenwwyYCUugSO0KCpUb
LMOW9yvIexWsAtXUbqe7ijm9IR36QF/oD7zvDu+7w/vu8L47vO8O77vzMoyBsTAOGK8zASbCJJgM
U2AqTIPpMANmwix4BWYD9+jMhXnwKsyHBWp56A4VC7WEVtAa2kBbuBPaQaZ6LzQUsmAYDIen4Gl4
Bp6F5+B5eAFGwIvwEoyEUTAaXoYxMBbGwQSYCJNgMkyBqTANpqv33MvU8pSgei/FgZB6TxjkiuVE
/rjcLq4gLheLyWKImikyYShkwTA4p2L45xj+OYZ/juGfY/hnD//s4Z89/LOHf/bwzx7+2cM/e/hn
D//s4Z89/LOHf/bwzx7+2cM/e/hnD//s4Z89/LOHf/bwzx7+2cM/e/hnD//s4Z89/LOHf/bwzx7+
2cM/e/hnD//s4Z89/LOHf/bwzx7+2cM/e/6ncGmfMM5PVQGetQDPWoBnLcCzFuBDp+FDp+E7t+E7
t+E7t+kLVF7y/4+88H8d7dfPqP1ksyhZbKbcJGqQL/eRwUbj4Wbi4Wbi4Wbi4QrwcAV4ON8/xfBP
MfxTDM/k4Zk8PJOHZ/LwTB6eycMjzcQHzcSnzMSTzMRDzMRDeHiEAryBhw8owAcUWI1UzLos+Xmc
BWh/X8vH0NkxtHUMLRxDA8fQvx7610P/euhfD/3roX899K+H/vXQvx7610P/euhfD/3roX899K+H
/vXQvx7610OvFqBXC9CrHhq1wB5A20+xv8j/1DTloTc99GZBsDzvUwc1DY05DU25DU25zc1See4w
GK7ywuXV/nAFSIUaUBOe5vx8tV/oZJU3yOvoOLlaXCvXiAfk+6Kp/EBUYn5Xyo9QUhtEfblRtGGu
2+DrAyiGG/H2ZWVEXMW8f4NyqI7OOcDZg6IReqENeqGezBO30O5HJX/LvoyePlRLKD8x2edyrvVG
VawRKZz7nKNN/udS/vKzdLVeIu3in6fLeJrwdlxPr63Ih7czhgtnmpAtz3D2ZrLlGrJlPPkZxfn+
t1FythpHNyb/pliRsnUZg/9dBEfE5ZS4gqNNIo07LM+16tyr/6lvHdTXsr9ozvg/Mm5Ar+mc+Yyj
LylNbkITFnKUy1G6CHN0nqPPRH1hiDQRABMssCEIDoTAhTCk0GN7UUF2RON1gXTuaQ068AN05odq
i9FfpBkDYCA8CYNgMAyBTBgKWTAMhos0vHwanj0Nz56GR0/Do6fhydPw32l47zT8dlry+y/CqNuT
9JTLXRyR7/Mk/W8z+VC9i7rN5977MyerGdc6SnG33HtYlNU2i9raFtGYmenCPPxFdqRUJ9FJdkl+
xlwnma4+9D+VSA5UB+QU0UxOFdfQj8eTrouSWWpcK64ymovGzFYnUZ0a1emnKU+zv6hJT8f9/pM9
hUu+1+RT2ZnaD1C+G9sH2fZnhW1Wu9DIBejjc8n1s0PY1JLC9L8JhdKplEylZJCSHiUKRao4SBRF
Q4nD6KbH6cl/pgPVNnR3AU+9FBF3S7K9CE9wO7Vo01fEgbKqGA9fjIcvxiMX45GL8cjFeORivG8x
fbZXef6/eKLFRrwpVrK17eqkqPizPjsTs7pBBvfWHyW+SX3H6Aq5D48VV4G+T1HrY/oN0e/Z3+w3
RL8H/O9mobWy9BugxVO0WECLJ2kxSGvfldxFMe9Ze876nxfYGSXfDR7nSn9RmZpBRmxS8zQ1i6kZ
ZiwJf9aoWcRbcVDcKg7BYTjHyj4PRVAMPxAd2uNcOqjGsjPR4gHRVXZj+yDbDLzP44xnoJovh7Iu
pog/sR6uZ8Y302Pz5LPZql5J9hZRO3jnyuNyzpeskasM2jYSoET9QFlxq9UROkEXUd+aCgtgH8f7
4QAwTquQcyfZnmZs/uc/FjKyc9zzOUbWiPs+x8gacd9VuG8/Ytjcr8O9HpU7RenkqltLjY+ocYga
VahxiBpVqPEnSpdmzEeSK2+rKmLcZ6l5KFkrkvxego7014mV3IVtV7YDiIoHRC0iXiExxiEyViYy
liHerU1+o47//GKUkpwp5Dm0Z69D8t3wPw0vVT7BqnqSfHeEcefR4zHlJdfbPuodop5D6zYt61yJ
icqih/pOPAQPwxM8/fY8z46MqwsMYGX6pQ+ySo4w00cZ0zH8ZZxW8smTN4iKgdLqu0ABHFffmemQ
AX3gMRgAA2k3peQ7gaK0HKPlmHyCuxpAzD/AczzIKjrEG5S8W+JwHnN0TH2V9OIVGV8R4ytifEUl
d+//TXkvreylFZ1WGjHG0rRyhlYStOJ/0rxNC/v97yNifEWMr4jxFTG+IsZXxPiKGF+RuFz0EK3E
Q/AwDBEtRCYMhSwYJlrQYyl6/AMxK8AMtyNmBZjldsSsRcz0CmZ6Hev0U9bp7azTVnKxGs89fUmG
qHdhNOQtfzR5qIlrRXPWaHPjBhU15ogWxlyYJ1oESotWgX1sC9geh29FC7MhNIN00crMgD7wGPjj
sxnV6ZJ1o5esGz35rPwZPKaOJv8asZRxLywplVpSKpVxe5S8KvkXiGNqGysjPbEBL3gc77cPr3cc
b7fPaJA4zFpLT3icLeRModFA3Uir6Ym98jTzXETtYmLDD2qjEVBn8IVnjZA6ScmNlLwlWfdDrm7h
zBbOOMm6njxPf0XMyg9qOx4zYQSFSd0EpbbjJROUTCMupSeO0EsCl3qSkRXIc2yL6LWYlXmhZjG9
JnCnJxlxgWGzdRhFiPMXWirmDk6x6tLxtWeERiuFtJKgFUULecm+TaFRu5DaCWorauaVjKGhP0+J
cYzhALVrU3s3tU/L87yx/uiLWcc/sOIS6ASlfmAsB2itNq3tprXTRlBFkncV4jm7ojROOU7LPzCm
N/0sqnRaPMs4cmVC6NQ6S9+5Rpj9BupSv0RiEyWO0p8/UzFKHKVNf5ZitPEts/tPz4unX/KcqP0b
zydZNvlcKPsbz4N7/D8+B+Lpvzn/RJn/8rxzj78y38krF51nkWKUF0GjAuOrJByjCq1VpU41NMMl
7FfnWg2u1eJaHY7rcq0e1+qTDwwjlR6qcrUm27o8E9cozxEewqhI/1XooSo9+W1V53wNzl/K+Tqc
r8t52uEp+KX9nquWlPB78tsqy7h0rh42UjlTESqJ6oyvLCUP02Z1xqczPp1ah42aXL8UanG+DmXq
cq4e+/X9byWnlVzG6t+hblRmrFVEoKQVv3Yu4/fvUDdqc60O1y7U1rnf8lCBtZfKmCvRbhXupSpP
vxp9XeLfF9drcL0m12txvQ7n6nK9Htfrc3/cBc+mAu2mcrYiVFI7GEOC2TlgVONZXsI9V6dMDcrU
5PqlUIsytSlThzL1KFOfzOY/Jzc5r5VEecbhz9hZxlGecYQYh5uc21oc10nO4FnGUJ4xhPynImTy
3quUzPOF0fuzJ5P3faFGYcmodVHqP10TvLUe8/dP64K3/UoR/nfXBrUaC+vX1gdX64py/601Qmt/
4K7/w3VC7QaizP91rdDKtf4d/XfWC0/ii+Rz/I/WTDI3hP/ddZOM6g3k6cQxImk3Ik41olpreT5R
SFT7qyxOxIk+PYhqNYlqzY1A4hgRtRvRqBpRrbURTBQS1f5qhBJxIlMPolpNolpzo3ziNDNyOTPS
kBlpaFTiuLL6AzOSwqiaMCv1mJW6RnXO16BcTcpcCrU4rk25OpSrS7l6lKvPqgni3Fw8V5r0v9dn
gyiH2i2P0q2DqvgTWuFj1F6p5HcLrda6iOu0buIW7UExSvsb2+449/ZqlrwXL3KfWo3ymJX8prqG
/6LUx8lS/ncg7Uye/fFo+T+OdJz8eu0DtTy553+73QH2SuGSLxdCNMeTNhJ/5rexaCnuFk3EveI+
zt6PlrtePCJGizvEGLFYPCZWi/UcfcDvePGF2CEmiCi/c0Qu7mSuOEqLr2tVtapiq1Zdu1xs01pp
rcVBra12jzisddQ6i3ytq9ZVeNqDWg9RqKVrfcT32gBtmjitzeC3ijaL36rabH6raa9ri7VLtA+0
TVoNvbF+lXal3lS/RrtKb64315rpN+pp2jX6X/QW2rX6Lfot2nX6bXpL7Xq9td5au0lvp9+t/Vm/
V++gtdA76Z20W/WuelftNr2H/pB2u95T76m11HvpfbRW+uP6QO0ufZA+QrtPf0l/Weupj9WnaOn6
NH261l9foL+lDdRz9I+15/RP9R3aVD2qH9QW6cf0fC1HL9S/1d7VT+hntPf0c3qRtl5XUmgfSl1K
bYO0ZFj7WJaSZbWvZHlZXtssU2UVbYu8VNbSdsg6sq4WlfVlQy0m/yAv13LllfJK7RvZRF6l7ZNN
ZTPtgGwur9MOyxvkjdpReZO8STsmb5Y3a3HZQrbQ8mVr2VYrkPfIDlqh7Ci7aydluszQEvJx+aQu
5FA5VDflMDlMt+QUOVW35VK5VHfk2/JtPSRXypW6K1fJDXpYbpQ79UrygMzXa8nTUul/MAJGit7M
KG800G8ybjBu0Nsb/Y0R+r3GSOMdvbfxnrFen2J8bWzSXzG2Gof1uUaeofS3A07A0b8KuAFX/zpQ
OlBW3xjYFtilbwnsCezTo4GDgYN6buBI4Ii+N5AXOKZ/E8gPfKvvD5wInNCPBk4Fzuh5gXOBc3p+
oChQpBcEfjAD+nHTMlP002Zps7SeMMuaFXRlVjKrS2leal4tHfOP5h/lJeY15q2yutnWbC+vNB8w
n5HNzOfMF2Rn8yVzlOxqjjXHyr+Z480Jsrs52ZwsHzKnmrPkw+Zcc65MN+eb82WG+Zr5muxjLjFz
5GPmu+ZaOch83/xIDjc/MT+Vz5qfm9vl8+ZOMyonmDEzJieZe81v5GTzqBmXU83vzGI50xKWLhdZ
llVTLrbqWU3l361rrRvkNusm6yYZtf5i3Sp3WXdYbeReq53VTh607rHukYese6175WGro9VVHrG6
Wz1kgdXL6iU961FrkCy0hljD5A/WU9bThm69YI0wDGukNcowrbHWNMO2ZlgzjLLWLGuWUc6abc0x
ylsLrAVGqrXEWmNUtDZYnxsNrC3WDuNKa7d1wvijddI6b7S2ii1l3GPXs+sZHewGdiPjfvsK+0qj
s93Ubmp0sa+1mxtd7evtG4wH7Zvsm4zu9m32HUYPu5Xdyuhpt7HbGo/Yd9vtjd72/fb9Robd3e5p
9LEfs/sZT9hD7CHGQDvLzjKetJ+ynzEG2SPsl4xMe5Q92hhmj7XHGk/ZE+wJxtP2FHum8Yy9yM42
XrSX2EuMkfZSe6kxyj5hf2+Mtk/Zp4wx9ln7rDE2SOAzxgWNoGFMCFpBx5gYdIMVjanBysHKxvxg
1WB1Y0GwZrCmke3c7XQ0Xne6Od2Mt5weTg9jhfOI08vIcR51HjXecTKcPsa7Tl+nr/GeM9AZaKxy
hjhDjNXOUGe4scYZ4bxhvO984HxmHHa2O3sMz9nrHDZOO+dCVYxEqHZoXKBmaEJoXmBM6N3Q+sDs
0KbQicAi13IrBb50L3P/Gsh1O7iPBM66j7p9zaD7uNvfLOUOdAeZZd0h7hCzgjvUfd5MdV90x5g1
3XHuOLO+O8GdZDZwp7hzzcvcV91XzWbuAvcN8xp3mfu2eZO70l1j3uKuc9eZLd333ffNVu6H7mdm
a/crd6vZ3o24EbOzu8ONmg+4Mfcbs5u73/3WfNj93j1rDnTPu8XmUDcRFubwsB7WzWfCRtg0nw3b
4bD5Qrh0ONUcHa4UrmRODFcJVzMnhauH65hTw/XC9czZ4eHh4eac8NPh58254RfDL5uvhceHJ5pL
wpPDU8yl4enh6eby8MzwTPOt8CvheeaK8PzwInNlip6SYq5NKZtS0fw8pWrKJeamlDMp582tQnfQ
70K4N5e5UzQQNcV/6UetVgfVEdFY5bG/+6IlEmqmWsZvoRrJ0Z2qE3U+Zi+v5HqeivPf/SVHp39R
378aVyf5/d9r1kX6+R4m/eZ4M2Hdz87spYdUv5df/cF5UW6XKmLfJZN3FmGOD/58jD/ezUX6/Ert
U576mhYOcLdHf2uMv+PHptUpJa0fUgXqY3W45OjEL3rPh1z1jdqmzqo7RJC5ayQu/cn1xG91pk7x
7E7Swv+OnPlHsVy4+pp6Tbjwj2f4T7WPw2EVo429HAbQWfXEjezVSF79u9qodrB+WDv49ov3v1i9
qmazfRHS1BVqgOrP3k/m8ce7Z6/gF7UT6hN1lBX0ifqScfAc/Nn7ea1/lP3qN6ZC4FOFSEnujSk5
49H21z+uzZ+uipIzJ7nzE8z9bvU9er8Up5ryFP7Ru8pPPqH8H0v/on6BOsY75v044/5fRpPbPT8t
81vjLikX+9lRv58dffb72uCnSbJ8yUpTO3l+ttr5Gz2f+cm73UT86TdKv6Gy/TdaffK7x/Tz+kf8
1eGv2V9c2f47anNn6oXk3rv//D6rv/2O+qwR9XYybu31n9u/+6NeT0bT15nXX/7Yv6uFQrU6GTV/
57q4SAsnfv+qukjtkgirtv5HtZcn/7vTjxz/9Z+rf0f/Ry7kMlXEOvr+3+7B/ZdX68NdyV5+zHj7
L/yWXK9xkToN+a3Bb8OfjXJhyXbThd9/Ub/JReuXzC6r5BTR6dSvDZj4eVx9RwTbl3yn/FV9Nnl+
YvJydfWBWq8ifkb/lfrFP9kfJSoT/+8Tbf03pORcLrlhzS9j8T/qFP1kfxyZp5S4XXRjf2nJuYPM
3pZfz6o/9p9c0dOpHyT6PF4Syf3zK9QyIdXKX63/z6swgHrqyfmXS65/pj5l/r8oOfpl/D7/k/2R
1K4sWgtfCaWVnFunVtHCm7/a/6GLn0/wxPz4qNqpNqqHaltSes4v6j9DFHtNvak2q8hPTuviAfGs
GM3eGDHW/zcz4g1W7lKxEnW4RqwXVyX/qtBMbBA7xDVilzgsWoqjmiY6aN20buIJHP1dor/v5cVA
38WLJ/XeeoYYjB+Piix9t35QDNPz9DwxQo/r+eJF35uLkfpp/YwYrRfpRWKM783FWN+bi/F485CY
KGvIGmKa7CwfENNlN/mgmGm8a7wrfFerxOxA2UBZ8ZX5jvmO+NpcZ64XG83d5h6x2VSmElt9Tye2
+Z5ORK07rXYi1/d04hs83X1in+/pxAHf04k839OJuO/pRL7v6cQ539OJBJ5ulCZwc+M105poTdOC
vqfTSvmeTivtezqtjDXfWqCV8z2dVsH3dFo9PN0J7XLcnNLa2tIOaJ1s23a0LrZrp2gP2v9D3ZfA
R1FlX9961bV09+vsQFb2nYhhCwgBAQEVXFBxGQRCUEGRkAyikkg6oIKIqIgjoCLIoqPgIOOCivzV
cXB3EEEBkR1kExERARWo79zbnRgEZR2dr/J7t1/felt3vzrv3FpO4t1E43q3klvFGOCmuunGQLeq
W93Id2u5dYxCt517rnELorYbjFsRnY0xhiE6u88o5vjLuINjImM4x0RGSfCO4HhjJEc6xiQdp5ON
1/Vz+jljkd6kdxvvcKxhLONYw/iCYw1jNccaxjqONYz1HGsYmzjWMLZzrGHs5ljD+I5jDWMvxxrG
zxxHGAc5jjAOcRyhVIw/JqicmEoxVVQg5kDMT4qvKayQGWPIjFGYMRMRUUyixzCnH6dZ8DyFP4ee
ptlYpeZgPtkyn2zMp4U46v4PsyogsyqAWfUB/B/SZxSkz/GnMMuWg1V/QavBrtbQRhxjmzDnatBW
+g5H/B781aTvaT/VogP4q00/0iGqQ4cxI+NlRmbIjDRlRmqZkRozchDFqXzMSy3zMgHzcg1VVmvV
WkpU69QGqqI2qo2UrDZhvqbLfE2T+Zos87WSzNdUma+JylMeJZqg/5SEWatgsVElzF0Hefz4lGL6
MY+TZB6nYR73orpmb8zmepjNfZHPw5yuJ3M6A3N6DRm+tb6vSPm2+LaS7dvm20VB37e+vVTV94Nv
H8X69vsOUjXfIcz+OjL7a8jsz5DZnyGzP0NmfwZm/3mU5HRyOlHQ6ex0Jp/TBceDheOhKzzdnG7w
XORcRI5zsXMxuc4lOE5q4TjpjrqX4Wjxy9ES5DMgFHKuxjETg2PmWqrh9HJ6U6zTx+lDdZxcHEXx
chTFy1Fk4Ci6GbUGOYUo81dnCDy3OLeQcoY6t6KX25zb0PLtONKCONLuQK3hznD4S5wSlA/j2AvJ
sWfw+RSUGePci37HOvdh74POg/CMd8aj1kPOQyjzsDMRnknOJIxksjMZHhyfFODjE+1Mdaai1jRn
GvwznZloZ5YzCyXnOHPgec6Zi7rPO8/je5jnvIRv5mXnNYxzgbMA38nrzusY1b+ddzDad50P0Oan
Dmam87mDOemscFahtS+ddVTdWe9swney2dmGvrY7O6im87WzE9/kN84uqu1863yLHnc7ezDmvc5e
lPzB+QF79zn74N/v7MdIDjg/ov2fnJ/Q8s/Oz2j5oHOQEp1DziH0ftg5jLqe4/H/V3UtymA0gQWa
wAJNYIEmsEATWKAJLNAEFmgCCzQhA2hyD+wYdwwpxhTyMaaQwZhCGpgyHLYkUEpxjCxkAlmWkw6u
CK6kUPCL4B6KY5Qhk1GGUoAymyhRb9abKUl/pb+ikN6it1BlvVVvxd5tehsl6+16O6XrHfob5Hfp
XSj/rf4WZXbr3Sjzvf4e+b36B0rV+/Q+lNmvD6DMT/on7P1ZH6SgPqw9Sg5xaJ3I+AXrC/lgrZBN
CUAxl6qE/KEAVQoFQ0GU1KEQpQPXEuFJClWmVEY3qgx0S4VNC6WjTNVQNUoKVQ9VRzs1QjWRrxWq
hfK1Q7WRB/bBD+yD54nQVPQyLfQkak0PTUfLM0Oz0OZTob9TJUZDMhkNKY7RkOKAWP+MouF4/JmC
hhbQcDLyjwMHTcFBGyj4HPJz6VXY1wizDWj4FvJvAwNNegc4aAIHPwdiLge+mnL+3hUcNAUHKwkO
VhYcDAgOVhEcTBYcTBEcTBUc1EasEUsho6fRE3aQkQ9bYAyBHWoMhR1rjKUQUPIyUoKSfqDk9bCM
kkFBSb+gZIxgYpLaqXZSvOBgguBgojqkDlGsIGCc6TN9lADsc5EPmAGKN3uaPSndvFbuZGPsyxDs
q2b2MfvAnyt3tzEOZggOVjP7mddRWjkObiUTCLiXXGDfQQoI6qUK6lXms7Y4Pjs4HXD0dnQ6kikY
5zrnA+N8wLhuyDO6mYJutqBbsnOpcyk8jG6mc4VzBWwP50qUZIzzCbpVFnQLCLqlAt36knb6Of1g
r3OuQ/kbnBtgBzgDYBnpXEG6QBTphjpD4bkVSGcLxrlOkVOEusVOMcqXIV0p8hGMu9O5C3lGOleQ
zhSkCzjjnHGodb/zADyMeq6gno6i3gRnAvyMfa5gX6qgnimo53OeAOqZUdR70nkS+enOdCDaDGcG
yjMOmoKDqRVw0BQcdIGDC5CPYN9C51/I/9tZAsvY5wL7ViHPqFdJUK+yoF5AUK+KoF6yoF6KoF6q
oJ52vne+Ry3GvsqCfcmCfalR7DsIjDMF47RruAaZEbQKDAsUkT9wR+AO2JJACQUDpcCmYGBkYCQ8
owKjyC84pYITgo+SEsRJ0t8Aa+L0d3oPJQi+xAmyJAFZ9iN/QP9IscCUwzjOGVPiQ2bIpFigiUMx
giMJgiNJQJAE5BlBEkNVQlVQhrEjKZQRyoC/WhQ7aqAFxo4EwY44wY54wY4EYMcTaHNaaBpqzQzN
RPlZQI0EQQ1FquluPvPacst52dSVrvktnv//x+Zt87Zzir5bf6y4i8/zyLm+k217M5/hksj7LXn/
ZVmfYpdEo8+dHH9KLLrK2+htPfKMzvH7LTtD5xWe/AjP7OZ1Q+TJr78Zex9VYxsi7fdO/bxMeTs7
f/3O+05s1I9YcS++2Y3eLqTyM3sVItGkCrVXodRK4vMeVZCLnmEsi67/oC1QPpqK/Wr6i/i+PtbZ
BW/H0efmvD3eBu8L7DnqKsSpbmVnyY98x8dPdFZXOF+AsZvl+Z2/9St7644+q3mmtmNfwTlurVne
dHk9KGfD3+fE54e8Z5H7IFqmbGbxEfyD90mZ/6T62SxzdOMv7/ksmLemQon75XwQnytfJ7nNGE1F
hIp+vyf6+8pZ643HL3fyG2ZahXa9fd5BpJ/4XJd36Ihyv3dd6n9s+4OP+RPYvCmnUbn7MdrbSPUx
B6ueRqu/v9UnwVbGU8HUY27AhhO+hnj6a8Wv2jtiVBWPvROs/4L3hjcven0gyZvmvSHeTby6V1y9
T4k/rAQ2rhf+sFW4iaAZr0neerzOiZbaJdfbPkR6B39bjzxzLUiWQmXnZhdhLfjA+xRpCrxdvWXe
R+L/LMIi5Ir2X05+pEeNfPsR72QN9f5ZwTPQm+nle/fyWX5vSLm3DXyv8nF39FVH4muuR18L3eG9
hc+y6swdqWXzgdcxIFgZL/yAotdnK44BuFx+bYSvsRyn5f+cqTGe6oZvKSSvD/H15qP2DvUWHVE2
8roGq9smniGn0N/nPOuFb8n3xDmsb+uj3xqsd5O3WH7v/WQeYw0LUdZRbe7CcfBN9OqSCeQou+q0
P7L39Ne3X65DH3m9soylMPeSdXsz/nYdxT3XCfc8xtGOo/kMY9extl/h2bKj9h/8tSfq/+ux/XQy
19FPevP6n2SFyD0WY7xR8vqtIMCLnJB7xpsfycm+Mn4m1zvxS712CqN7wXsViPly9N0ibzbx/UGv
cB4JyAkUWwSUKGPB3wJ9P4riROT6WcxRbb7nvey9GW0zid9F/Uegg+ed/GilHo5S74vyd2WxywbO
lcWVESYuiPYBz4/IPSLR42ePIHJvr7u8e5P4al4h0u3IjfcmY627PdpKhXtb8A287hWfwmjzvBJv
hpeP3Ns4qmd4AwQf7sdqNAPf85veFO9GrK3f8jVA+WQLvLnek5Geo6tGqvf2r9rc6i1HVBk5cluU
56K80/sxkk6cMR/R9l453svvCjpylZJ1ujzyFea7Xu57qHjHReMj71j5o7Yjr+LKHUzfHH8k8omO
uv/qj9iOjGT5W8Uc/v54+Cm/zhmLdE9mq8g/cDRwlLUCr79xpbu85I7TH6/3hDfcu9ubJPlPMN+n
850y0XUowhd/8F5CeuP0+pGWsiJ3spxWG5u8LVgJZX3Eb7oF87Ccc0d+dW83OMfuYzHAk+7rFDh3
hdofRX5VjIVx8D/Rd+uix0901H/O8Xyszevv3eAt9OaTkncl3m1A674RRuC94h3Au3HeX71zvFrA
0ebe7d5Np9FXhD9WP63xRjEpEtOW3284/ci9Z3LzZp2BNnj2Lo+gOvjtUb++7N/oLf1lFf5zN4zm
Sxxzcs4Tc5gjxfJIJcJ0sfc9pN+4V/WP3jDeByoeueBXC/7M8fz2hqNtKHOnyJ2u3i1gR5/h6Ivs
e1Psl95r3rXevcg96K2O+E6xr/dOf7wn2ePeivd5/e9u5Rx3z+nfXXmse93P5BZhh+DfX2HVOwNn
LI53j/Lv1j3BGeU9L+f2vz71nipsKWeklRPawIVOm7l6D52JkRynjyjSgd2e9nn5M/QrHa+XTWC2
/+Uj5cxtYD17z9g3k3Aa4zgTx/sfeD3iVGYjeM/GSM3okx1l50UWy3WGxb9beXC07LyT7/eP3k7l
GYij2vjNqyG/U0fO1vOZokgkHDmjU34tOPB78bGc202hfLJPvl+pfwpPeXlbZe345VmysnNyJxrb
Ben8k+/1T90qn2rFk7/yRHxXA1+XLo/svdfFfgN8Pu7ViP+1Dbz/h99+ZqJCuQP//bGc2HZiCHmq
q/oxn5U6bl9yB8Evzw7KFYvymRU4ZqWysnyuKp2uxTH3J2xHcvcIaiB6Og7OypWYP+F8n/fdGWxr
A0XPKB/ziaMG8pQTX0H/5Bh7j9c2P0e1oaxmWU7O8G+Iesr6bCN9/WpcFd7d80ubZWPh57WOGhU/
ldWEr9KcStTuTfGe9haUPwcWzTEjiJ7T/KR8HE2OGu/TJ9/fEfVP4U4hb6lclfiw/L3cAwS+aZ/w
lb4TeHrvN/o+5rPJx6mzRc5a8UouWCDvFuHYiyBD4Pf4pawosdTuxJ7XPEb9U7n/YRk/bylpX+S9
2OhZ899Hh+hnST/yfiPMr++8TyVNoSrgpNujV5PWR45pmWsDT36kx/kckStsFaJ1r693u/d3b6ro
BpTf0+N18144yZYX/TGMmcf42/14h491VTlyRfFXvu+OfxXnVDe5RyaKzN4e8Ik94EcrvVW/IJG3
Ez6+ZtzKu0rev4gZsNzr7b3D7703vb957/IZc9n38BFtrynzn9SILvXyvZFe1+g7yWEGDpD8095M
bwjmwRSwtQVYebnEfO9l76Xoqs1n5ytTllxzHuYNEl/kfsSp4NVP8O/BKgnldwEdcS7I+7Hsaf6T
Gu+j3rOI1R6LvlssfU8RnF8s3wFffZ3n7fX+JQUiT+1H7zCIzuIWJ9/rn7X9V57GPrqXDWWIFbnu
/Gdtp3KdCr/0N1ThrEO5QsKJrD2JxPfvXCH5dGqO2LO61P0KrOMrWU3SqJn3OY5Q/lvjrfXOwfEy
gLQXWdejcSqOzkhMVSX6/oXolQpF5U9Mi/+53/kccm+FV4x1LnoG0uvg5SJ18/pTohdZg8s0NEqQ
OnttvCu96JMN3vvearlbgo/YHViTNkTj10ZUX1bORlLq989uHHtc072ZsM+Wv1/AsdwRd1b0iGau
pcupFTUVnZg6sqfiZw8cXuoFD++XlXKhd7P3Iq9hXti7i3NodewR3UbuAbv5FMY7yCvA5y+QNy5y
gwQ375KV+lP8llsPR56kf0VUQco2+Wa9W6JtnECMd8y+tx+/zFF1dsodAcwTZDbJbF6E9z7ZrX+X
73CtWMrB6BUtO46OXc+ojt2ddKGhjEp0vajTDRN1ujGiTjfW6Gn0pvHGTcZN9DfRpXvEuNUYS5ON
ccYkmsvqdLSA1enodVano4WsTkf/Z/zL+ITeVFmqCS1WzVU2LWF1OlqmzlXn0mesTkefqwtVN1qh
hqhbaJUapopotRqvHqa1apaaRRvV39Vc2qTmq1foa/Waeo2+UQvVG7RLLVLv0HfqA/UBfa/+oxbT
XrVEfUr71DK1jA6o5Wo5/WhqM0Q/mXFmAh1khTnyRGGORGHOMmubtQ1HFOZcUZULmtlmthESVbkY
UZWLE1W5BNGTSzR7mtcaSWYfM9eozM/KGcms+maksuqb0dj3iu8Noyervhn9WOnNuIGV3oz+VpwV
bwywkqwU4ybWezMKrNXWBuM21nszhrPem1HCem9GmPXejBGs92aMtn6wfjbuYY034wHWeDMmscab
MY013ownWePNmMUab8Yc1ngz3mCNN+NN1ngzlti97dHGClZ3Uwaruykfq7spi9XdlMPqbsq1n7Rn
qhjWdVMJrOumElnXTaWzrpuqxbpuqp79gb1SNWBFN3UOK7qp1vZW+2uVw4puqgMruqmLWdFNdWdF
NzWQFd1UET8fp8KucpUqdW3XUSPcoBtUd7qxbpy6y01yk9QoN9lNUaPdDDdDjXFruDXVvay4pu5j
xTU1jhXX1INuE7eJeoh119QE1l1TD7PumnrEbe92UJNYd009yrpragrrrqknWHdNTWPdNTXD7e8O
UDNZd0095Q51h6pnWH1NPcvqa2o2q6+pOe697r1qrjvOHaeedx90x6t5rL6mXmD1NfUiq6+p11h9
Tb3uvui+oRa6b7nL1PvucneFWu1+4X6p1rpr3K1qg7vd/V7tZFU2tZ9V2dQB1/Mb6kdWZVMHWZVN
HWJVNtPwp/irmiHWYzMT/TX99c0kfyN/YzPN39Tf1Kzmb+FvYVb3t/S3MWv42/o7mnX9nfydzEx/
F/8F5ln+rv5uZpb/Yv+lZlP/1f5rzBb+wf4hZstA9UBtM4fV3cwOrO5mXshqbWZXVmszC1mtzSxi
tTZzJKu1mfcGewSvM+fwU3vm66zWZv5bOzrW/Jh12szP9bX6RnM367SZh1mnzedjnTafwzptvgDr
tPmCrNPmq8Q6bb501mnzZbBOm68667T5GulZeo4vk3XafM1Zp83XmnXafOeyTpuvPeu0+TqwTpvv
QtZp83VnnTbfZazT5uuhN+iNvp6ssubrxSprvt6ssubrxyprvhtZZc13M6us+fJjVIzrGxyjY2J8
t8YkxCT5hrGymu+OmP0x+33hWIo1fKWkjI1AvRhEfLEURwbF48+kBKzDPkrG2m1hVa8Df138OVQP
q6BLmUBJP/CwDWngIf+fh3byHzAYMWMEMWOBmFeh1tX4iwdu9kaLfeg6ak/XA0M7AEOHgDncgr+O
NJSGUSUqwl9lKqYwei4FwiYDYTWlGCEjhlLlCeE0Iw6YexYwtx489Y36lGU0MBrC38hohHwmsDhF
sLgJsPhS2O5A5M6iF5pi9AYuNxVcbiq43Ay4PBz+EuMeam6MMcagzXuB1GlA6gcp2xhvPEItjYlA
7SaC2k0EtZsIamcBtZ9FfjawOwvY/Q7Wg3eNd6mN8Z7xEeUYHwPN2wqaK6B5c9gWwHRbMD1OMF0J
pscJpicJpp8nmH62YHorwfR0YPqzVE3NVrMpQ81R/6Aaai5QvqagfE1B+epA+YWw/wesrypYX1uw
PgNY/x/YxUD86kD8JbCfAverCu5XFdyvBdzXVMcMAf3rCvrXF/SvB/RPpoZmiplCjcxUM5U68UqA
PFYCaoCVoB5sfbMBamE9oExeD1Crtdkato3ZBnvbmm1h25ntUAZrAyzWBnj4Wevz5VnrC+T56vPl
+eoL5JnqLlgnSqmdb4TvHjKwWoynWN9Dvol0jm+SbzIl+h71TaXWvmm+6VTFN8P3D0rxzfW9TKlY
UV6hpqwmSs15XaEcXldI87oCG2fFUQcr3oqnJry6UFOsLp+RaX1ufU7VreXWcoq1VlgryGettL4g
C6vOanjWWGvgWWutJcdaZ60j11pvradK1gZrAwV5TaIQr0kouc3aRvHWdms7JWBl+poMa6f1DXrc
ZX1LidZuazdV4bUKPf5g/UDJ1j5rH7W19lv7MbYD1gGM50frR+R/sn5C/mfrZ2pnHbIOoeXDtqJE
27R91M62bIsMrHAOYbGwXQrZfjtAsXbQDpJpa1tTsh2yQ9TWjrFjUAarIP9XdzsRdZPsSqibbKeg
fKqdRgl2up2BlqvaVYkVUGvA1rRrooVadi2Ur23XRvk6dn2Ub2A3oCp2Q7sh/I3sRuSzM+1MirHP
shuj/bPts1E3y85Ca03sJijT1G6Kus3sZqR5xUVfLe2W8LeyW6NkG7sNWsix25Nld7A7o2QXuws5
9vn2+RjzpfZl+FyX21ei/d52X/SeZ/dDL9fZ/dHOAPtmam8Psguog11oD0WPt9q3UUf7dhvoYRfZ
xVTZvsO+A6MdbofxWUrtEWhnpD0SLdxp34kW7rLvoqB9t303ehllj0KZ0fZo9AIGQGnMACgLDOAh
am5PsCdQM+YBlAIeMAl7J9uTKdV+1AYO2I/bj1OOPcWegm/7SftJ2On2DGrKGrAoD66AFubYc2Cf
szFL7bn2XNR93p5Hne1/2v9Eyy/YL2LvfHs+6r5ivwL/q/YClHzdXoiSb9pvYe+/7LcpGwzjXfjf
s9+jxuAZH6D8h/aH8Hxkf4SSH9ufoOQSewnG86m9FGWW2cswws/szzHm5fZyOsteYa+glvZKeyXq
gqOg1lp7LVpeZ69Dra32VrS2zd6B8l/bX6P8d/YPKLPP3odvY7+9H2M7YB+kFOYx1Aw8JoR8jBNP
zZ0EJ5HSnCSnCmU7yU46tXQynOrUBCynHuU49Z0GdKHT0GlEbZxMJxOes5yzqa2T5WShhSZOE5Rs
6jRFmWZOM+xt7iB2BDc6h1o4rZ3W6KuN0wblc5wc7G3rtEVfrClgMGeipsyZYMGZYMGZYMGZYMGZ
YMGZYMGZYMGZKJU5E6UxZ4IFZ6KzmDMhD85EOcyZKIW1aqmx28HtgFpgTvCAOaEMmBMsmBNlM3Oi
lmBOiATcAe4Aagv+VECxbqH7V5QBi0JdsCj4waJQcoQ7Au2MdEcif6d7J/xgVBgPGBXKP+g+SM3d
8e541AKvombgVRPhmeRi1rmT3ceR/7v7d/T1jPsMXchMCx4wLQow04IF04IF04IF04Ld7n5H57p7
3D3o5Xv3e7QD1kVZzLqQ91yP//eWn6iz3/AblMIMjNLAwBxY1+9SCz82yvIH/AHktT8GNtaP9dcf
54+jbH+8PwGeRH8i5fiT/EnUzF/JX4na+iv7q8Cf4k+h5v5Ufyqd5U/zpyGf7k9HLxn+DOyt6q8K
D7gd8uB2GAm4HSy4HSy4HSy4HSy4HSy4HSy4HSy4HSy4HSy4HSy4HQWY29G54HZXUFygR6AH2YEr
A1cif1XgKuSvDlyN/DWBnpTEzA+eewKzSAWeCjyHPPgf8uB/KAP+hzI/Bg1SQRVMpfOYBVKriHYD
s0BSzAJhwQJhr9XXUobupXtRdd1b96Z43Uf3oWo6V+dSLd1X96WaOk/nkan76RuQ76/7o/wAPQBl
btQ3oszN+mbkB+l8qq0H68EoU6ALUWaIHoK9t+ihVBXM8nb4h+lh8INfwg7Xw2FLdJjSdakeQTX0
SH0nSt6l70LJu/Uo9DhG3wfPOP0AWgYHRS8T9ATYh/XfUGainoQxT9aT0c6j+jHkH9ePo/wUPQX5
J/QTaHOqnoq90/Q0qqef1E9SA2auVB/MdRY10k/pp6iTflo/i/xsPRtl5ug52Pu8fh52nv4nZeoX
9AvY+6J+CXtf0a9SQ/2aXgDP6/p1eMB3YcF3Yf+l36Y6+t96Ecq8o9+luvo9/R5Kvq/fRy8f60/g
WaKXok2wYbS/XC+HXaFXoswq/SX2rtar0c4avRb5dXodNQdL3oDWNuqNVI+5MlUFV76T0kN3he6m
mqFRIXxL4M1jKDN0bwjfVWhcaBxVC90fuh+eh0ITqFHo4dDD1In5NDzg05TJfJqSmE+TYj4NCz4N
Cz5NScynqSmYXXvh012ETyth0hHeXMaYmR/HCD+Oob/gL0aY8QXCjLsKM04QZnyRMOPKwoyrCDNO
FmacUkG/xxL9Hlf0eyzR77FEvycg+j2W6PdYot8TEv0eS/R7LNHvsUS/J1b0eyzR74kV/R5L9Hsu
FP2ebqLfkyj6PReLfs8lot9zqej3dBf9nlQw9SB4c8gICUdPoRZGqpEKDs1MvRWY+qXUWrj4FcaV
xl/gZy7exuhv9AfDvtW4FfY2oxi8eTgYeUsw8jHUFlz8XuTvM+5DeWbkLcHIJ1F7cPEp1AEs/CXY
l42XqaMx33gTe5mFXy0s/Dxh4Z2EhXcGC88iU1i4WYF/m+Df5wn/vhD8u5uwcFYY8onCULwoDMWL
wlAlURiKF45+mXD0c9S9aiy1Y2V/6hFl6szLG6nn1fPUQL0KXl5LGHkdYeT11EfqI/Bv5uI11FK1
FP7Pwb9riGpRhvpCrQEjX6fWwbKCUaaoujVUm9VX8GxVW2FZ262qKBvVVt+oXcizvlFd9Z3agzyr
HNVXP6uDyLPWUTV1WHlUVRSPapqGqZBn3aO6pmVayLP6UU1RP6ptBs0gPLFg/42F9zcV3t9ceP/l
ZpqZDj+z/8ZmLbD/s826YP+Nhf1nmQ3NhshnmpmwTcxm1AyRQEvkW5mt6CzzHMQDjSUeaGLmIB5o
bJ5rnov2OR5oLJHAlRIJXCWRwJUSCVwlMUAXsP+JFAPeP5UShPEnC+NPE8bfyjcfjL8NGP8iaut7
x/cxdRTe36mCJpMlmkyxosmUKJpM3SUS6CqRQAfRZ+om8UBrxAPLyJYYwLG+QAxgSwzgSAwQI+zf
EfafbG22NoPlb7G2wsO83xbGX0UYf1dh/AnC+JOF8adYe629sMzpuwind4TTJwin7yKcXtk2OL0j
bN4RNp8irL2L8HVHmHqCMPUUYeddhJc7wsuThZd3ARdH3Gs3BiO3hYsnCBfvEmXhze3mKJ9tZ6M8
c/EuwsIjnNsRnu0It75AuHVX4dYJwq0vEm5dWbh1FeHWycKtU4Q9p9jj7HHglPfb94NNMntuLYw5
x55oT4SfGXMLYcwd7Kn2VPBI5srZ9gxw5RzhymnCldvaT9uzwePngCWnCUu+QvhxW/sl+yXUYpac
LSz5CrDkV1H3NXDlNOHKrYQrt7X/bS9CC+/Y76A8c+VsYclpwpJbCUtuKyy5k70ULDlHWHIHYcnZ
wpLbCktuLyy5s7DkFvYaew32Mj+OMOMW9k57NzzMj1sJP24t/PgK+7B9GAyVmXGOMOO2YMZVkGdO
3F44cQenhlOHOgoz7iTM+GphxucJD+4gPPhq4cGdhAenOS2dlrDMgDsLA+7knOucizZZUSxWtMQs
0RKLFRWxWFERs0RFLCAqYpeIipglKmKWc7lzOXpnLTFLtMRiRUWsm6iIJYqKWHdREUsVFbFUURGz
REXMEhUxS1TEYkVFLLGCilisqIgFREUsVlTEUkVFzBIVsVhREbMqqIhZoiIWKypilqiIJYqKWKqo
iFmiIhYrKmKpFVTELFERixUVse6iImaJfphVQT/MEv2wkOiHxYp+mCX6Yd0r6IdZoh8WK/phluiH
xYp+mCX6YZboh8WKfpgl+mEXin5YN9EPSxT9sItFP+wS0Q+7VPTDuot+WKroh1miH9ZN9MMuEf2w
7hX0wyzRD0sV/TALMUwitUbEUoc6SHzS0a3n1kNsUN+tD67fyG1ErdxM9yzEG43dxvBnuVnRuCXb
beo2o84SvWS72W4rWI5hOrlt3DZoh2OYjm4X93zYC9xuaO0i92KUucS9hFq4lyKSaet2dy9HhHC1
ezX2cjzT3s11czGefm4/1IooMXKE0wkRzkD0xRFOjPtXdwjaucW9BbVudW+l89zb3dvhKXFL8Sk4
zmktsU2aKDdmS4ST4z7gPgDLcU5niXNy3EdcoITEOdkS4bR1p7nT4JnpzkTvHO10kmjnavdZdzZq
cczT1v2H+w+Ued6dB/siIp+gu9bdBPsVYp6gxDznS8zT0d3r7kXLHPO0dn92f8an45gnKDHPFRLz
dJCYJ0einWyJdlpLtJPtDyHCyUGEE0/tJcLpJBHOeRLhdEaEUxlRUBV/MkqmIMJpJbFNmsQzHRHP
1EMvDRHPBBHPNIfN9reGbYsYJigxTBAxzKWwHL0EJXoJSvRyPqKXHtGIhWOVaxCH9JSIpVegFzzX
Ba6jdoGBgYGwgwKDYAcHBsMWBgphhwaGwrIWXbxo0cWLFl0l0aKrJFp08aJFFy+RjymxzWXBtGBN
OifYNXgZtQteHyymHqJU55Nox4cIpxGiCI5hGkkM00DfgBimhr5JDwRT57ilhkQsjRCxFCBfqP+K
yOE2fRs8HKvU0nfoO+Ap0aWIUjg+qSPxSSOJTxogPhkLz32IUhpIlFJPP6gfRHmOTxrpR/RE7J2E
+KQe4pNH0RrHJ3UkPolEJrUkMmmsp+vpsDP1TFiOTJpLZHK5fhaRSRNEJs/B/w89l7IkMmkikUkz
iUyaIzJ5EZ6X9Mt0lp6v56Pka/o1+Dk+OVsvRHzSWL+h38DeRYhMsiQmaS4xyeX6Q/0R9n6sF8PP
kUkzvUwvQ0mOSZrrL/Qq+L9ETNIMMckatLYWkUlViUyy9Hq9Hv1yfNJU4pOz9SYNjifqgJmiR9pQ
79A74WGlwJp6l96NPOsF1hW9wJqiF5gpeoE1RS+wmuiRVtWH9CFY1g7M1J4GAxQFwdog5mCAoiNY
TbRJq4qaYIZok1YVTcG6oimYKdqkDUMxoVj4WV+wbigxlAgPqwzWF5XBaqHkUCr2stZgpmgN1hWt
wfqiNVg7VDNUE3tZcbCuKA7WFMXB2qGBoYFUQyKxOojERkokhvkQuid0DyK0MYi+6kj01UzirssR
dz2C/MTQZMqS6KtZ6LHQY8izcmFdUS7MEOXCTFEurC/KhXVFudBHRtqe9BEgv9ocS+uI+vZE6ovU
H2kQ0hCkYeWvRuFsvIaR7kYaizQeaSLSFKQZSM8gzUV6CWkB0ltI7yJ9jLQUaSXSWlIjPpREfTdL
UiOWIC1HfgfSbqR9SAeJ8hSSixSDlISUilQ9Moa8ur/xmhlpK69pNHGdVkjtZB/ldULqGhmv1JkR
+Yx53ZGuQuoV8Udf1YjVkozCeUjzkd9Y7oukbUi7ovnlSHuj+Z8iaSRFk42kkRKQkpGqRsqOrC3l
Ka8f0o2R7ylvcPl3HinbUMpR3lCkYqQRSKOjn2FcpL+RWdHPOgFpMtLU6P5Z0f3Z0ZQDH37HPP48
C5HeLv8skc88H2kh0ttI7yMtRvoMaRXSeqQt0dedFV7Lyu9BOhB9XRWtd6DC/sNE/XxIAaQ4pMpI
6b+88u/XryZS/RN+VSM7/vJb8Wfr1zj6W59sSj0yyfweG+lH5lVqpJz0WzE1R2r9y2t5G5F21cgL
4G+P1CU6/7Cv30W/vPa7HOkaX3yf9fldS5b0vbuAxNpiNezYggTY8QXJsBMLqsJOKagNO6OgYckS
rlXaq+8zBVml/fpsye9esrzPzvyrSlb3nVuQLTanPP9SQceS1by39MY+e/J7lWzsu6DggpKNkXzU
HsjvV7Kt71sFl4jtAfuu5N+V/McFPWGXFvSFXVnQH3ZtwaCSbVyrdDDsjcgfzh9csqvv5oIhsDsK
hsHuLgiX7GJ/6dBcX/7Qkr199xXcDXuwYGxpcW4gv7jkpzxVMF7sRLFTYN28TrAxBTNgkwqegU0t
mAtbveClkp+4VumIvLoFC8JTcuPyR4TxzRa8Fabcyvmjwzbb0tG56fnjwjqvacG7sK0KPg5r9pSO
i/ijtmb+hHBCbv38yeHkvHYFS8ttp4KV4WT2l06I2sb5U8NV87oWrBW7Gba75K8q2AHbq2A3bL+C
fbA3Fhwst4MLVenkvKGFbunU3Ob5s8K184oLY8K1pbWGUc+IwqQyy57SWbmt82eHs/JGF6aKrV6W
Z3/p7Nz2+fPC2XnjCuuGszlfOi+3fWEm8l3y54dz8iYUNhXbqjw/ubAd7NTCTrCzCrvCzi7sDjuv
8CrJ9wrncN3S+bkX5S8Md8y9PP/t8AV58wv7lduFhf1KF+a9XXhj+ILca/LfD1+S2yd/sYxhsNih
5fn3C4sxkuvzPwv3yFtcOKLcflY4Otwjd2D+qnDPm94qGiF2tNhxsO8WTYD9uGgy7NKiqbAri2bB
ri2aHe7JtUYV37S5aN6oEbmF+evDfXNvy98S7n/TjqL5sLuLForl/L6it8P9ee+o0bnD83eG7ZsO
Fr0ftgeq/J2jxkVs7p35e8KDBrpFi8V+Bhsj+RjJJxWtgk0tWg9bvWgLbN2ineFBXGvUBNgDyI/J
PxweMjCzaA9s06IDsK2K4GH/qMm5Dwz2hYcNbFfMtlNxYNTU3L8NDoTDA7sWx7EdOFrylWG7F6fD
XlVcE7ZXcX3YfsWNYW8sbh4Oc61RswYOLm49anbuY7kbw3cPHFrcPnx37pOD48Jj2Y6snfv04Mrh
8QOLi7vAjii+KDyePaPmRfxR+9zg9PDE3BcG1wxPGTj6/7H3/UFtZHeer4UsNB6GYRiGYRlCGIYw
hBBCiEM4lhBCGEIIQ1hCWC8hoJG6W1J3S0itVksG0RKSkAnhKMbrdVif4/hYn49yHMpxcQ7hHIf4
fKyXpQhFWB/r4ijipQjhKMI5hOUcitz3PUkMtpPM/LH/3dW3vh89v379+v34vO/3+5677Y6GQ+zv
OAlrB/J7bkZw3JqjDHNnOloJ0ofpoQ4O8GKHDfByhwx4tcMDeL3DD3izo7fnFnerY8Crb7ttzVdG
uDsdZ3vukNpGIzn3Os4DzmLEOT332u5aTyhj3ELHJYJXommc3zPbNm0tUSa4Bx3XlAmc7lngVjpu
9Dxom7OWK5PcGow8YMf4YXqz4zbgo467gHsd04AHHXPKJK/uuA94vGNJmcT39qy03bdWKVNtS9Za
ZYZP6Hj4FCZ3rCszbQ+tDcp827r1pLLIp3VsEdw5TGd2PFYW27asrcoyn9OJDjG/U6Mst+1YaWX1
nQe2foJnAFdIes02BLhpuwj4yHYZcM92FfDAdl1ZxXd57+jVtpvee22PrZyyoUNWm7KtP267BZhA
MJlgmu2Oso2vemd1Gqus7Oo0tnsYcVqfaZv1xuvirB5lX59jWyD44Kl0vm0F8IRtDbDEtglYbnuk
7OO7vAu6RKvfq9KlWHu9Wn2VbQ+w1nYA2GBXA560H/dqdenWAW+8vpUgbU/wPtBlWc96k/ScPZlg
GsFMb5Iuy54DaZs9H1C2nwD02EtwPpRf0fvt5ZDTa6/yrulyree9qfoBey3gWXuDN1VXYL2kzGP0
burP2096H+mKrFeg/CV7K9RQZKcxQs5KOD+CpdZr3gxdhfUGtO2KnQO8RvCG3QYjg/P39ON2Gbwn
SeuqrePebP1tu4eg/xDv2nsBp+0DgHP2s4D37ecBl+yXAB/ar3gP9Ov2az411HPbm6dLt98ArLDe
BayzTkM7t+zjgDsYSc6KrtE65y3UP7bffhJxvg+2rfa73myDxj7tS9A1W+97iw1x9jlvMU77knXN
dsjR6axLpF9hfBhNGxLt64Ap9i3AdPsOYJb9MWCuiAALRA30Hd+7p2OtD71lOsG67q00FIlxT2Gp
mOit1InWLW+Nzm3d8dYbKmxnMIoph1gtpnvrdYr1sbfJUCdmATYSbBZzAXVigS8NxyS+TAMrFkF8
ArGBL8cgiKVd6wZRrAB0i9VhD+7Lx37Qd8KgiHVKuiEoNirp2BP5Sgx9YjP2SqIOEHyNr9wwKLJK
keGcKIB/gfXiqzJcEEVlFfPWV2sYFt3KvmFEVABHxWCYY74GPL++k4Yxsc+brasWBwFhHHythgnx
HB4T8QJguKeT4jDglDjirSceZ40/0RkH3gdb/k2+pDNREfjyzhTAqs70iH1+hK1czx5f25mlDLeN
d+YCYjtzwDd0FmCb01kECJYkpOZPdpaC9WjtrFAWCfNXDDPiqI82zItjPs6wKE74bIZlcdInG1bF
qa4lw4Y40/XQsC3O+zxQZhHK7IrLPr9hX1z19dIqccM3QGvFbd9ZOl7c7dpqqxX3lQo6yaHynadT
HVrfpbaTjniljs5wJPmutOU4Un3X2vIdGUo6ne3I9t6j8xx5vht0oaPQNx6ON+hiR7HvNl3mKOua
wxGF7y5d6aj0TdM1jho8C476qGen6x1NBFsAm6Btc3SLQ++7T+sdJt8SbXJYfQ9pq0PyrdOSo8O3
RXc4fL6dcEz7jsoRgiguHEeRKIX2OfohdiVxIx1ynAHsdwxBFIe58fgdvQOQPuO43I3oIcfVbg19
0XG9O46+jEu2qR03u3boq45b3YnhyE13wXGna46+7rgHa5zEqPRNx2zX+jupjoWux/QtxwN4usmx
AuNwx7EGeM+xqWTRs45HEINddexBexYcB4APJLVvQLcrHYf6V6SE7hR6TUr2zeER6E6nN6W0MLe7
s+hHUibUsyflKEX0gZTfncuopRPdBeEIkzkulXQXMQlSeXcpXhfdFUyyVAVROsTq3dVhZNKk2nAE
3l13BBsJNpOn6AiyTKbU0LXO5Egnu7aYfKm1awdH1N0Cc0KiI2mRoBuvr24lMpIQD3cHCfbhVnUP
MiUS1z0YThM8x5RLNiWRqZJkiIchKu6+wNRKnnAM3D18BEcgUpWULKZB8gOexIij1u7RMDKtUm84
Uu0eY2hpQClgOOksIORDjk06H45afeXvYfcEXvXdkwSnwsjI0iWIRSEi7Z5hPNIViDwhLu2eZ/zS
NaWO6ZVuANqkcYg5Z6XbEFvieVkMIzMg3e1e1mdK07C6sWWOZ85Kc+A9M6X7kD4vLXWv6tKlh9gj
SOvdG8wlacv7iLki7XRvM9ekx927zA0n6t5nxp0avypi24n11jU74/xa5rYzEayx25nijw9bQuau
M92fxEw7s/ypzJy9yp/B3Hfm+rPDMYCecxaALyBehlnCdjvso5mHziJ/HrPuLPUXMlvY2zI7zgrw
emC1/MX6OWe1v5h5bFvwl+nPOuu8qSxyNvpTI375irPZG89qnDocSzhZZZWNcwrYpztFZZ9NdLq9
SWyKU4HnLjmD2H85wQay6c5ByM9ynvMmGQqcF6Kegs11Dvsr2QLnCLQNYonuRLbIOeqbw73z17Cl
zrGwpfUusBXOCain2jkJXgB8rr+erbPe8DdhP+VvYRudU3492+yc8ZtYnXPeb8Xj5pdIPR0s61z0
+1jBuQx7HLDh/lA42sHoaw1jNKqxyv5+jOEc/xmCQ7gN/osEL7Oic9WrYt3ODa+WVXA0giMTXysb
dG6H0+DvAOEu8AX+q9jq+q+yfc7dcFzhvx5B6IWvgR107oO/IGnSr6vsOVnlzWAvyFqIKCCu8N9k
h+X4cBQBrTpE/5D+ipzkzWNH5FTAUTkj7PGhHkD/LXZMzg57ef8ddkLO8xayk3IhIORDzpRcHPby
/ntHcBb7Kf8CwSGCD9gZuQx8N3hw/wo7L1eCpwY/7l9jF+Uabw27LNcDrspN4MXq5BZvExnzTYKP
IiOzIeu9xey2bPJWsruy1VvP7suSsmpUyR3+PZ7urA4d57nOumAdb+tsBJQ7m5VB3tOpU1je38kq
Gr63UwglQBkRrg50ukPJ/NlOBa6e7wyG0vhLnX2hTP5K5yDshi51nlP6+GudF0I5bWc7hxWFv9E5
EsrnxztHQyf4251joRLwmBPKMH+3czLQy093ToXK+bnOmVBVeHfQNt05r0zw9zsXQ7X8UseNUAP/
sHM5dJJf71yFfdx658ZhHL7VuR1q5Xc6dyH9uHM/cENAHlWIFjQebYgT4jzxIZuQ6EkKyUKKJzXk
EdI9GSF/eAfK1XiyYc8V3umQPYWQ5ckL9YZ3eUIu5IhCgacQ9lzg60MD3GVPcWiAz/GUhc4KRZ7K
0Hmh1FMT4rg8XLJtwFOvuIUKT1PoUnifZZ70tET3s+E9plBN9pU13Bre8Xn0h0+/6jEBkr2SUOex
wo4pvMc5gD3mpNDYud1dypV5JKi/2dMRuiLoPD7YZ8EIhK4JrCcUiVXOCIKnXxkWRM8ZZVFwe4ZC
NwTFczE0Ht4PCkHP5dBtoc9zNXQXxzmhaWHQcx321LCzDs0RvC+c89wErwE7aPAXgKEljF6ypw49
xE8JrYdRuOC5BT0ahj2XKIx47ihuvP8NbQmjnnuR9A7BxzheOo0iIwm719OaCEKrTscJY57Z03Hh
NMFEYcKzoJwTJj0PYPcKe9jTKcKUZyW8Yz2dfgSzuHueNRixGc8m4DxGvMf0nQyjsOh5FN5Xns4V
lj17ypiw6jkAhHzI2ehSh/eYpwuOYBGO4k6XEqwIo7DddRx2jrB/PF0t7HYlwD4RdpGn64T9rmRl
3qLqSgPUdmUqi5b4rpxQK56X040Em9sGuvJDW5akrhPKhCW1q0SZsWR0lUPJ7K4qpdmolX3+A7J3
IP6I2C7Ysxjj5VBAbUyS+wPHdRr5THeiMVUewr5DvhhIMGZghPTlQLIxW74aSAO8foh58s1AprFQ
vhXIMRbDXdrwns5YJt8J5Bsr5XuBE8YaeTZQYqyXFwLlxlRsPwnuGZvkB93b2FoGqgjW6v3yijfJ
2CKvBRqMenkzcFJXJD/yrhhN8l6g1WiVDwI0QQ7byYAtsrcCDMhGyaUOeML7LGOH63jAb/S5EgK9
xpArOTBg7HelBc4az7gyAYdcOYHz2GYGLhG8Yrzoyg9cAzzhVRkvu0oCN4xXXeWBG2GfYrzuqgqM
G2+6agO3jbdcDYG7xjuuk4Fp4z1Xa3cpsaJa46yLVljjgosLzBkfuGyB+8YVlxxY0gkuj7fSuOby
e8uMm65eZSzsoTAGHuoU8IaQdg34O8KRG5PgOhtYNz5ynQ9s6ZDrUmDHuOe6EnhsPHBd8x8Y81w3
ApkmtWs8kG867rodRKYE192gxpTsmg7GmdJcc8qgKVMeCiYerc2U47ofTDHlu5aC6aYTrofBLFOJ
az2Yayp3bQULTFWunWCRqdb1OFhqanCjYIXppFsTrDa1uuOCdSbanQjIuVOCiRG0udOVVZPszgo2
mjzu3IDf5HcXBJtNve6ioM404C4Nsqaz7oqgYDrvrg6KpkvuuqAbz29QMV3RuYNB0zV3Y7DPlOYG
m2+64dYFB8NzZxp3s8FzpttuwTdguusWgxdM02434JxbCQ6b7sOtI6Yld58/SVfthh2W6aH7HOC6
+0Jw1LTlHg6OmXbcI4CPXSXBCTNyj3YvmzXuMUVjjnNPBCfNie7J4JQ5xT2lCOZ090xwxpzlng/O
m3Pdi8FFc4F1rrvUXOReDpSYS92rwWUouQElK9zbwdXwU8zV7t3ghrnOve+bMzeeUgW3dRpTjrJr
bj6lDe7qSk/FezPMulNJwX0zeyq1R2UWTmX0aM2iydOj1TWeAu9sdp/K64FY7lSht8msnCruSTIH
T5X1pJr7TlX2ZJgHT9X0ZBsLT9V3b2PsyQvv+s3nTjX1FJovnGrpKcbRS08ZjlJ6KvEpSk9NeMWR
E4z+yEnFk6vjduSsgJwM9NSbh0/pAznYv/c04T14TwtmY48+fDpE7MOeeUQegvpJJGYePWXyLhiz
T1m9C5HTG3KuYh6z2npMxkenpB5reNdvnjjV0SPhufY1IBV6ldqm/jdC1G+pXaSiHlO/Q2rq9yoK
aVTHVBr0nOp5VRx6XpWgegm9oHpFlYxeVKWqXkMvqTJVb6CXVTmqj6JXVN9RfQe9GlMd8yWUcqzq
2BdR6jHxmAOlHfvpsZ+i9HgQ9OH4jPi3UUZ8fXwLqotvi+9BX49/N/4nyB9/L34T/SB+K34X3YfW
/AVSk//9IB69iJ5DL6FG9DxqQnr0FUSjb6EW9O/RAAqiQfRzFEL/hH6BptG/UMfR/6DiqBfQ76kX
qVcoisLfOGnxe5PUq1QzZaTSKDMVonKpXuosVU0NUd+hvkb9F+pn1Ndjvh/zfUpWS2on5VL71H7q
lLpX/S3Ko35X/S7lU39b/bdUt/q76r+jgupR9XXqm+qb6h9R/eqfqH9CDar/u/rvqXfJ95hn1fPq
n1PfVi+rV6i/Va+pf0VdUP9a/Wvqkvq36n+l/iN+i466fOzlYy9T//nYz48dUCOaY5osakHzpuZN
akfzUU0+9VvNZzQl1O/wFx7U7zVf0FSq1JoqzdsqjeYrmhZVvOYdDa1K07AaUZWhcWoU1cc139QM
qD6jGdRcUH1W813NFVUN/nJC1aAZ1fyj6quaWc2syq6Z0yyqRM2SZknVqVnRrKg8ml9qNlRd+H0s
VbfmN5odVUizqzlQ9cai2BdU78Ymxr6i+m7sq7FvqP4uNjv206rrsZ+PFVSTsY7YM6rN2L+J/ZuY
uNhvx16IeSH2e7GjMS/j/1c15tXYH8aOx6TFTsT+NCYdvw8Ukx37T7GLMSdiH8SuxRTH/ir2X2Pe
0mZrb8Q0an/z3Osxv4j/Xfzv1Ph7OQH1AsahdPy1ccX1iGpB81C2oK/eE0yV1V+6X1kgWAVJ6Khe
EXxCqFKoHxRuCreEO5UTwj1hVlgQHggrwlrt8dpMob9WFs68VfOWSRgSLgqXhavC9drMtyqBVWrg
+Dbh+G8RRf2e+j1SAaMTUAxc+xB5ExWpvqf6HqJU31d9H65dV/0Axah+rPoxOkbeRNWofqb6GdKS
L8GeU/1ctYCOk3dQ48jbpy+ofqH6BYon752+qPq16tewOvCbpYkxVAx1+L8GH4vRoGTy5VhKTHJM
MvqzmJSYFJRK3hR9LSYnJgd9iHwVlh5TGlOKMsg3YK/HlMd8HmWSr2KyyDsbH4H2x1GJZOQwIv4u
8vB3+Wl+jr/PL/EP+XV+i9/hHwuI3xE0QpyQKKQQTReyhFx+SygQioRSoUKoFuqERqFZ0AmsIAii
4BYUISj0CYPCOeGCMEx0RBgVxoQJYVKYEmaEeWHxqFiahGVhVdgQtg9lV9i3qCzaIxJvSbKkWjIg
N/sJabFkQ9k8S6GlWNiPiqXMUmmpAcRSb9EL2xYTlLVa9BbJ0mHxWUKWfqgz23LGMmS5aLkM/aee
EyJWA3+z/hIZkxSQGJQGokbZ6E10DOWBxKJPgGhRCchzqBTkOCoDeR5VorfI2+VfBquDv7t8Ef0V
akYJqBUkEewOjV5GJpAk5EAS+eKyg3xr6SVvlAdQKtijd9Fr6NsgH0L/ASQd/Sd0BX0YfQ/kdTQK
kol+BPIG+q8gWejHIB9B/w3dhfZNg+SQ/w37o2gR/TPKRf8TJA/9C8jH0S9B8tEj9Bto+x76P+iT
6ADkU5SKikUnqONg+0rI++N/DrYvAZWS98fLqHTqdfQ56g3qDfQF8r1nJVjDevJFZzOqor5B6dAX
KT2lR18m75LXkq8736YESkB1VDvVjr5COSkZ1VNdlB81gO0MoZNgPb+J/or6FtWPvk4NUoPoG+Tr
zlawpOOojZqgJpCBmqR+imhqivp7xFL/QP0DMlH/SM0gM+EvD1YgBwnaXG0uaidv59m0n9QWIjt5
I8+hLdGWIElbpi1DTvIlkUzev3Npddp30CmtQWtAnTC3a2iXcL8I/8sS3BjoBOgk6BToTETnI7oI
uoz+kpvgJrkpboab5xa5ZW6V2+C2uV3AfV7Fa0Hi+SQ+lc/gs/k8vpAv5sv4Sr6Gr+eb+BZez5t4
Ky/xHbyPD/H9/Bl+iL/IXwa5yl/nb/K3+Dv8PX6WX+Af8Cv8Gr/JP+L3+AOhV1ALx4UEIVlIEzKF
HCFfOCGUCOUgVUKt0CCcBGkVaIETbIIseAQ/yIBwVjiP/wfRY/pjZnCC34hvJf++wlv/Zvx+G+RF
wvIEwvKXCMtfJixPIix/hbA8mbA8hbA8lbD8NcLyNMLydMLyDxOWZxCWZxKWv0FYnkVY/hHC8mzC
8jcJyz+KZkByCdc/RrieR7ieT7j+CcL1AsL1TxKuf4pw/dPAdRUqIvz+DOH3v6M+RKUD7zGzSwmz
P0uYXUa+j/gcYXM5YfPnCZsrCJu/AGzugjXgpbywBvBXEl8kbK4mbK6h/pr6a1gPmNO15PuItwmb
6wib66kZ4HEDNUvNoq9qv6b9GmrUNmub0de0Zq0Zf6+d4Evog3mKg7F/HlH2VuBdIWgxaBloZSSv
BrQetAm0BeepX+JO2Iv4+T+tpMyiuMCV2Eu5cnsFv/yk4jyuyl7Nr4JuiA+wcrX2On77TysuwzXY
G7mT9mZ+9z3Ff+Za7Tp+364TVOIKR9tZQfunlZSJF9c4zi4ISXaBs9lForLdLaSCZohWks4WN4U8
8RHnsSuc3x4UCt9T8udicY/rtfcJZe+jleKBUONQcwP2QaJn7ee48/YLQn1YcRr3TWh6T0lfL9mH
hRb7MP4lesU+IujfX3E57pp9lLthHxNMTyo3bp+I1ntUudv2ScH6nnJ37VMfRG2t8nlu2j7Dzdnn
/6Dety9itdHyJazckn35A+lD+yq3bt94Rrfs21htnGOA27HvfhC12eQr3GP7PlYeiSqiGlGL1SbL
1/Bvu9V5ldeJej5OjOcTxaSn1eaRb/ApYur7qc0vj5M60sUMolliNp8r5j2hBWLhM1okFj+hpWLZ
B9YKsZKvFmue0Tqxnm8Um57RZrHlCcX9/gAqSI7jPCuaeEG0/kGFa0KHI0HwOZJJOVGUPpC6xQ5e
EX3PKK4vBNrvSOODYuiDqHDGkcn3if2HOiieOVR8fQj0oiOHpC878oWrjhP8OXGItPcpFa47Skj6
gnjx/VS46SgXbjmqnqhjWLz8hI6IV59RfO8dRy0/Kl4X7jkayO+s4+Qfas8f1THxJj8h3npGJ8U7
/JR47xmdEWePqrDgaI3a9qO2OGorD23cAwd9aINWHNxRO3LIk6PzGp2X6BitOWyHY7vpkI+2idiS
XrApsPZtA2EbYDsbXr9kXZ0XU4nfAL7bLoFekW9H+Wy7Br/wHHxdeOTwCHsOv3Dg6LWoHQPYv1iO
O87ifNw3S4LjvCXZcQnbV0ua4wq2k5ZMxzVLjuMG9gGWfMc4tu2kz8B3ywnH7ah9tpQ47lrKHdO4
35YqxxweC0ut4z62nbhOog2OJctJx0NLq2PdQju2LJxjx2JzPLbIEsLjS3wQHksYQ4sH/GTEn1n8
4H8i42zphXoGJA2ug1w7K8VZzkuJ2O8c+tojc3RYJ9aIT4n6Atwm7Bstl6QU0rYrUnp0nkl5bPth
7olfBp9H+nZNysJ5lhvgw0vCiv01Ht8ntDbsl7G/Iv4YnhP1xfiXKPCH9O0pH0ueBWoZtytYsY+N
+tWoWm7bB7Ee+kjsMyO+8aivfMJHRvxkVC13wQ/CHBPfB/7QMm2fwEp4i/3c7bAe2ixQy5yUS37v
SwWWJamI5IP9sDyUSi3rUoVlS6q27Eh1JB+vYexL8LqFdYTXk+Wx1GhFUjO2RVaNpCPrIroOInaR
cAvqwXbOGge2KbJGyHyB3cL3R23gM2vrqXV1aF+i7Yc6sN20JkosnnNriiQc3o/Lw3qzpkuiNUty
43ZbcyXFWiAFiQ3H/YE+WIukPmupNEjuez/7E2mXtSJix6NrPHSkTKTNpK9P2ePD/mA7HNU/9qw/
Yk+t1ZHfOvE67tOhPm0nj9pKbB+jNvKoTYSypB5cBl+DMbA2OmptN+S7tnF5GiuObfB8k7jmtjxH
8sBmWeed8ba78v1o/GKblpesQWmS2DGIO2xz8kMSU4BNs45KG1ZFmojGBLb78jqxadj/47gB27ol
eQv7aNtDece2Lj+2Tkr7ti0Xsu24NLbHrjg7ciXaNa4Ue5wrncRkEXtJ7sWxWSRuIjFPNEbBdUXq
wNfsia4sbC9xuw5ju2gctvOeDSYajWEisQeuC8dj9hRXLo537Omuguj9pDz0h/wZxousE+ibPctV
RPJw3BjVSJz4hD4dC0Zivyc0Mq5Px3WHimOxqD4d10VjtD8Qm9lzw/q+sRmOvY7GXzjmisZdR2Is
3FZyLy4TGZNn1hasP2uzdO6ZdaWTLkRjLCsrDVsFaQTbomg5qyiNYl5b3dIY4VPUDuAyeM0B/8hv
nzRlHZRmSPqcNG+9IC1iPbrerMPSMrYR1hFplfBzTNp+Jo4BtU5Iu0SBj1jJOsR2a8qpIr8zTm10
DeI1YV10JlmXnamH6w/boFVnBrE1G85s67Yzz7rrLMS+J6q4v3iPRdYf9Nm67yxuVznLSN1gP9q1
zkrSz0j59nhnTXuSs7491dnUnuFswbaoPdupb89zmtoLndb2YqeE/R/xgdg+QUzQXubsaK90+rA9
bq9xhsieBXxhe72zv73Jeaa9xTmEx6td77zYbnJexvuEdsl5HY9Te4fzJi7f7nPeag8577T3O+/h
GBDb/6htbj/jnG0fci4Qhfqwn8Hcbr/ofIDHvf2yc6X9qnMN86z9unOT2DCYx/abzkfk2i3nHqnj
jvMA2/L2e7K6fVY+3r4gJ7Q/kJPbV+S09jU5s31Tzml/JOfj8W3fk08QO4b7fyCX4F+bWi7HfLAd
l6tsCXKtLVlusKXJJw/5AzE4jj9smXKrLUembfkyR/IjNtd2QrbZSmSZzB+sE1u57LFVyX5brdx7
yNXoPiDqoyBta5AHcBnbSfkszkMqRMWH4gcR+v9/g/L/0N+gbKJH7/09AL2LBCaVyWCymTymkClm
yhrVTCVTw9QDNjEt9G5YmAysjJ4x0fthYayMxHQwPibE9DNnmCHmInOZucpcbxxgbjK3Gm8zd5h7
zCwTH5EzRBeYB0xSRFaYNWaTecTsMQesmj3OJrDJbBqbyeaw+ewJtoQtZ6sYVVSgRC3bwJ5kWxlt
WFia5VgblJNJC3GLcEl8DT8PnoDP+V+4Ctz+0r/JOejbsDa+AvISOQdNJOegL5Nz0FfIOWgyMiEO
vYoEkFRyGvoaOQ39EDkN/TA5Dc0gp6Gvk9PQN8hpaBY5Df0IOQ19k5yG5pDT0I+S09Bcchr6MXIa
mgdrbgblo1mQT5LT0EJyGvopchr6aXIaWoR+iX6FPoP+F0gJORP9c3Im+llyJvo5ciZaTs5EP0/O
RL9ApVPpqJKcib5FzkSryJnoF8mZaDU5E/0SOROtIWeiXyZnorVUF+VFdVQ31Y3+gpyJNpAz0a+S
M9GvkdPQJljpP0R/Sf2I+hFqJmeiXydnot8gZ6Jt6j71t5CO/EuDevW4+keIhnU9hVj1uvpXyATr
dxfGkkJupLzHVQP02HDfsGR4aFg3bIHsGB7DwGvoODqRTqHTibC0QIu0m1ZAgnQfPUifoy/Qw/QI
PUoki86lC+giupRIBcFqug6wkW6mdVgwb1QfA958PMKbRPJ8zBgVzNGbwB7MFTWMfyGwB3NFQ7gS
C0x5CziEz8yfA3Y0A4cwP54n/Igj5+QvQL94YBJmQwJw4V3gE+ZBIrDgCvAJMyAJ/QDkFcKAZMKA
V2H+7wJv8Xn4n8Gc/zMwDM/6a2TW08gZ+Idg5jdQOpnjDCoB5vh1MruZZF7fIDOaRbVROvQRMqNv
wozaUA4lw4zmklPuj1H9MIt5ZBY/TmYxn5xpf4L6ITWOChClLdKWHpmPXPVLhtynhe6gfYYCQ1FU
6GxDaUQqnhY6ZKg21IWF7jc0GhrpM5DzlNBD9EVDM4gOhMVCXya/gkGMCn3V4H5W6OukBrdBiUgw
LPRNQ5+hj74FOPis0HcM5wwXDmUYl43ISERGnxbzqHnMMGaYiAq7bZiMyNTTYp4wzESfZZ40zIMM
Q85Twpww7BoWQfDzlrGYcuh4+F0ldxBhtp6t3TBlqiI1TEVH1rARFvOUYduwbR4B3H1WzDPQv/1D
qaNVh6INyx8YqXv0LB1PJx3KAp1K5MF7IxEVeoXOoLOjQmZ8jc57SjZBH9GFRIpB9iL5B4wasOyw
R3UGhTlOVz4rTAJdwyTT9XQTFiaNbgkLk0lbIUdP65kcWn+knkNh8g0btOlQrLQUlfDoG5ZhRoDf
TAnhbjVTzlRhjjG1eCSYBswP5iSkWklv8xia4UiLONLXcE2YKfNklmbMi+ZlwoZVMvobZKQ3GRus
nQIYvyJDKSMbRhgPjHI844f29TIDwGUdcxb47mbO0yrmEnB5UN/LXKGL4bkDwJMglL3G3GDGDfvM
beYuMw0txvwfZOZIL3UwY/cMQeY+lKhjlpiHUBdetaRHpGR4reDZDRoamXVo/xb0eQfy+6BcEay6
PuYxpAqYVhYZSlkNG8cmsilsOptF1nJjWNhctgCvV7aILQWpYKthtQrhFcvWsY3kafAkttkQZHV4
TbJQM5QUWJF1swobNJxj+yLrD6/AEXaQFYBr8YRvqXD1HF1DF7MX6FR2mB1hR+kWdgzmF2aLGWAn
2El2CkYuj66ENp2jZ9kZdh5KL4Is04XsBGEg7iWZK1wOBBiDR4ldBd2gK2END7K7kC+x+0YVu2zU
GuHZxiRjqjHDmG3Mg7HmjIWY78ZiY5mx0lhjrMcch5Elc25sYnKAbcXGFlYw6kFMRitdhgWuScZC
Ywf0oIZugis+usUYwjwF1Bv7jWeMQ8aLbJbxsmHDeJU2Ga8DH624b8abxlvwTD0wVML9M28bxsy7
Jhosw6R5H+ZnGfpTCXwZ5FScFqzACBcPlmKKPWfc5JIMKYYJ/bSxnkvlMvC6Bs7AaHHZXB5XyI5w
xVwZMBRbjl2wZnh0RswT5olwCcOgaY6rhLqwvSMMJiXDVgYYDHXNczWGc1y9YZRrMkzRKig3Ae3Z
5logNWZs4fSGSabEWGgq4UyclZOIFYxYMq7DTCyrsdg8b57nfFwI7Nxq2NZx/dwZ8jR4Ejdk2OAu
YmsGuM1d5C5zV7nrpmQOLLqxJWy5iO3Smje4W1w/3cLdwS0x3oF5wtxpMd4zzmL+hIUZgHZPGRew
TTI+gDleoethdtaAV3lgD/KMmzDWl42P6DLjnvHAUGdSm8DuGP4ve+cCXWVx7fHvfK9EhCNiihAj
jSki8hIDUkAuqEUgOQ+QQqVIJQLGE0SbIkVELiKijVSRWLCIgJRSjDGgIiJgQKW8pMirCIhIU6RI
AYNCikghuXv/5gtEmq7adddd66517zpr/8/Onj17Zvbs2TPzncPhQKJ+ouGQjUM2JtJkBudL3Hwx
dEwiI9E80SbRPtE5cdOwIbn71O9DlwzrmOiRiA79ItE3MSD3QOJOWT2TJcEMH3a/tL9P9seDiZtk
BYclZw2RkvzE6MS4YamJiYmCxJTEtKHjhyUnZibmJhYM3Z4oSSxOLBsWTqwSq+HEmsTGobvF8r7E
VulTWPqyM7E3sT9xKFGeqJA+bhLbyUO/EM3TeVaeP3RyXl3JNg1kLcUlbhpJnVYSKx3zmkj8Hs1r
OnRRovk9R+85eveUe8qG7svdntcir21eU/GDndchr0veLbmb8nrlxfP65Q3My8nLzes1LFveR+Se
zBuZN0a0xyem3LM5b1Le5GGj8qbmPZc3K29eYkpe0d3DOE21/v8b5v+hG2bCyudbDQ31f5PJKbJC
d9lWSs58eRXL6zV5LZVXaU7pQHnlrM5ZPXj34N05G+S1OWczsh3y2iMvlZXJ66C8pN6A8gHlOUfl
dTxH77B2OB7uLW3U50ZjcaOxucs4nHld7jIetxifM28St5hkbjEXcXO5mJtLXc68Yc68l3Dmrc+d
5VJuK5dZofrD6t/PmPjeYU57K5QTlffO8t7XvbTXgpwe34ays+W9RGjxP6FlhrIHGeq16lvSGqGN
tdBWQ9mj5H3nt6PsCfK+N6D9AR0ylLXPvGfPEJojfLlQxT9SdrG8n/7XlL1UqFTsWgH5QnW/SYzt
AspqcAE1+jeoiVDTWqhFLXaV2l5AHb4dxcXvWV2Ebvkn1MtQfKehrPi3pH5CA2uhHENxmbes3G9H
cZnbrBEBjQxojKH4IfMeK5P37ULjhSb9I8UlBrIm/2uKVwQ2pgb0nNCsC2heLVR0AS36N2iJ0Ipa
6F2hdbXQpgto+7ej7IPyvjuH9VErSVn2UaHjgd6Bb0mHhb6ohXYHNivl/eS3o4gr72fOU7Z9ns7p
1A/eGwqlSVny+bZqUiQjaD/8rynSXKjNN+tnp1xAqbWQ1m0v7+ny3jl4v6n2/vwzym4m1KoWyhTq
WAt1/SZFetTI3zXzbXW+DPJYJJpzLr9E+uZ8M39Ux0nNeQ38fc5HA2r49s5v9ulcTqmZA6rXcLC2
dM+ojvnejS6I6ZOmPDJMaLhQvskRur9Exhm5jikyUajA5NccnS/Jk5FpQjPNHhCZG+T30ybeI+KT
6vwckT0tstiMN7Is8IPY1HypNiG1K/MZkbwYEd9FpA8RtXso8G/gT63LPlm9h+2v4WexE7WMDS2L
yn4RrRv068J5umCOzu0p1fNUYPbGaAPTt2ijGvVPm7Hw9+Jg75O/o00CWUkNWlYLXbgvb62FdtbY
X2vsseeovAZdsL+e2y//O/tkk5xv7oUtcs7vgTX2u3M5Syh6S/Au+1Y0HqwxyR9R2ZOisgdFZf+J
5gZyWcO6f7Bue5j1FJV9JjrS5KLomGBdBOugOi9qbKkdzXPkp+o1UmDyltY/lwMvXFsXrKvq/HJu
bRUE/Z8UzPnk8/XRl/UWlb0p+pzpd1T2pKjuQfuCnKRjkD0ouiio969y0IV5vDad6j7Xko/PlSWf
p3+a6/5VPk3/Jv1DnqyZKzNr5Mga+RDd9ECno/GB5ujeEj+9WxjSs43Ot55percNZBIrse7Cax4L
zi+95WwUPRnkMZnT3hpbk0w+i6nv1V/BmaB3ryCX6f7/XJDnNP5kj+4t9nqLvZj0t7fETW+x11vi
rLfalBjrPT7In9X5clFwNqs+N408n0exFdigj5NMvqRfF+bhC3LwuTNMdR7WcaotLZOY6j21Rv3J
wXg6GH9x5pKx9X4ukHWpQb1qoQvPgjm1UODXC89152h8DbrwXFd9RvvvnM2W5Hzz/PVuzvlzV80z
Vk5Qd0UNn1y4tmT9RTfl/MO6im7POXfGiuq63mdy0bl8dcDEdfRwEE/VctU5GcSfvkteiQXrLiZr
LBY2VHO9xVJMjoilmviMNavlHCMUaxVQpiHyoNrvGLx3Pb8GdU3EZK+L9amx/kQv9iOz3mKyR8eG
CCXM3lNN5KNi4ycdc+x+oVGBbRlHbGwwzkA/Jne62BNCTwk9m0Muis0QkjtcbL5Qsdn/lMiTciaI
vSa01OTjWKmJU90LY6uFNghtDvy1Q2iPuSfEDho/xY4a/ZjsHbFTQpXmDKj5vzo3x2UPiNcxpPbY
ZyS24/WN3+NyBo2nmTiLZxg/6jzGmwdlbQIb7U0uj8sZMS7nw7jmHjmPxeUcFpdzVVzOU/Fhxr/x
4UEek/HH84P30SYe4nIWissZKC57RHzK+fjR3K3ngbicheJyForPDeRBzo3LeSBeYuzrOomLj+Jy
BoivqhGr1feA6j1K+PgaoxPfaGT6bYx6q+ut/f9vY/xfelbmtnDX6Ceq9kbrVctKShdqJtRKKFOo
o1DXGu/dhbKF+gj9SGiQ0BChhND9QqOExgpNEHpC6CmhZ4VmCM0Rmi9UHNBrQkuFSoVWC20Q2iy0
Q2iPUJnQwaDNo//k/bjQqYBUv9Kykl0jT64jVD/o29HgXcaQ3FAoTSjDyM+9NxdqY/qa3P78mJM7
C90k1EMoauwk9zXtJQ8QulNoWCAfLpQvNNrYTR4nNFGoQGiK0DShmUJzhRYIlQTvi2u8V+svE1oV
vM8N6q2qUb5GaKPQVqGdQnuF9p9/V/8kHxIq/zfeq31RYfz47xJzUJP6GFL7zFdZoHvoAjpt/tv5
6vfq+tV2L/KF6gbzLfKLGpx/v6iRUBPr1UivSDzSLzIwkhPJhUZERkbGRMZHJkUmR6ZGnovMisyL
FEUWRZZEVkTejayLbIpsl9fuyL7IgcjhyBeRk5EzUTuaHA1HU6KpUHq0GX+3kldmtKNQ12j3aHa0
T/RHkanRQZGi6JBoIno/NCo6Njoh+kT0qeiz0RnROdH50eLoa/L30mhpdHV0Q3RzdEd0T7QsejB6
NHo8eipaGXNjdWL1Yw1jabGMWPNYm1j7WOfYTbEesaiWi7xvbEDsztiw2PBYfmx0bFxsIlQQmxKb
VivNjM2NLYiMiJUEr8Xyqo1fJq9VsTWxjcJvDV47Y3uh/fI6JK/yWEXsdNyK+1DdeAPZExrX+osL
VvCLC8n84kIdfnGhLr+4EOYXF+rziwsN+MWFFH5xoSG/uHA5v7XQOJwevt66Itwu3N1qHR4aTljd
wiPCP7NuDY8KP2RFwuPDj1i3hSeFH7d+GC4Mv231D68Mr7ImhDeEj1gT+fWFBf+LexYKNQjl832V
Ffq/yWdkBiSZJaNrQN0Dyq7BK8mqyfhRwKveoIAfElAiIMm6GZJ1MyTrZkjWzXgi0H0q0FfZszX+
nhG8zwlofo02i4O/X7NaZm+U19bsndl7s/fL6xC4P7tcXhXZpyNWxI/UNa/sjZEGkUaRJpGmIm0h
8iaRtpEO2fsjXSK3yJpkVWZXyLqMR3Jkri7hlzYsfmPD5jc2nHBmONNyw7eGe1heOCscs5L4vY26
4cHhITIPeeF7rSvDI8MPWOnhseH/tDLCE8OPWc3CpeFSq3n4nfA71rXho+GjVov/YeuhyjvcHwgO
lOgIVV4MXwf+evjr4du5vQTbe6OQD0H+a/inBDO91+F7wZu618P3oe51gm2Qt3fvx47WzcT+ILed
oneHfvfJGyt8inuLovdzwcXovKjtnoU/u5I+TER+L3w7+Hbw7U1vAxwL/gwdsXn2z25LwbJgRC0p
vYNeMVK3E+PKo+cJ5Z3d8MmUWtR6Gcl91I0guQS+G3UfxNol9KQb6KHTAZ1cwbbwbeEz3c7Ih8N3
wAJysB2lmZR+371R0buXnnRGU/l2znF0jB+ewlop1nQurnOLkBvsCPZFZxg2l2JTvGHfpi3arb0c
wcc9Wd32aPhu4G5vpOB41QnZ4HT06adtKTq5aE73hgouwOalKgntUj50gtJC9G9F/xn4FKydAMvQ
P+3+QeS2u1awr7tDW1E+dAxJrrtLsIvqWCcVQ9ng1+BKRcdBMws7/VU/9CkWiuAXUtoT/Sr0W8Af
BFeDb6J/xP2paEa93wt/SuPW9r13hK9UeWiIt1FwvyuRYKeqjnXEe1Twb4qhg4FE0MnETiqYRt27
wULwcreK0ruE36Jo74UvBbeC091BOkf+EXApWAwWgOWKSY2krfZmBtF83NffUBkC3w2sF2AxWABq
3cvRXEPpa0h2IxmPZK6Zd+UFl4LFYAFYDqp+FprjqGUZ9J7XqICfTs8XwK8AFwSSYrAALAe7y1je
9QqIooQire8CT1C3MMClYDFYAKqFQrzxjOo4M8Bn6PMJsAw7Zdrn0BFvk2AFeMSbDeaDg0EiwTsq
Fi5nvk6hWQYeDvBRYmC1xgaSSixUYqESC5VExX5K9yPZH0hWCDqM5SpvDTGzCcwHB4PbFImEMhNj
ykukqbVt8EfkTK99EIndOUAZi71eo9ROQ5KGJI3VnaaWBdeCK4jMEhnjWBOfWJ4KFgZ1dV08QMxf
rv8Tt7Q1G8wHB4NrwaOg2txL3b14YyvWtsJPh38xQPXeRvp5W5Jaq2fQRBr8AoPe28xsPvOopSfg
j/j/oR42qL2ykMidVjEV+VZmdiuSxayRZmA6Weh68tvjfnPBR5B/Ri6qgH9Wd5DQX8hp9Uw+VM1Q
He8ewcvIZpPAy/HGInRasRY+hL8NLApyoOwvIezbSYr+Np19/5fqDY9c6uaoT/xlyvutlHcOEdtF
xEkm0buJWsu8xVrXXUSvtHS4yee+Zs6WirI2d7CmdrCOdHVcDV9I6V+CMT5Af3Kp+wr6r+BnMox3
SP2jKLla0cxXa1/2R3s0+vXg16A/PsgexeSBAt0dWIO5yKeDl4JX08ousCqpl85mUgntaumtOsuy
cpVPCVBt3hDk5DnCNyImtyFJB/f4V+j8km9fJJ5vJ28v0SzqbScmt6qm15zYS1aJzJ3GcIrm89Am
s4rlriw7AvOyXT0seWAFMbaCVWlwLetlBbiWHURzdarWFX++Q61HWUGPEofays+1V06WljpZJqu4
clYJXckav4Vay/yvyA+q31F7K5GskoO60iXCP9SdhZ5nBvnnUTS1lflgIbjav0Z5/2lWbm/dZVi5
eyktDdCsUOX7+S0pPYrkKP1XD3fwt2muo7ezdTcMfcCemEpvzyJ/HZ9fCZ/OWPbrScnu46r9zW5Y
8JCeHu3GijJfj5JVdNZmMsY5utac69kHr1V00l2R2O9j+QU0T2D5T/B/gu+J/U3qeUG1nE2f71e0
XoM/DN7u1bH0XKH2b2SmWmBhs9l/9Rwl54S7yH4a4ZM5vRx2hzMKjbfvUTqTnm+jrZVYS9WRun9U
b3j4xP2K+R2t+7vTUK05Hyrv3gjfg/GWM4qvyBVfsRJT6SfZ3i7VHjrtGftFQW+1JxnwrVw5u4bW
M+q3XDkNhm6ibxuoS7Tbnd0Rusap1U/PwHY/53PBae6tYrkr87jEHabxab8g/A6sfRagWnsROzdg
M9N1BT9VlKi70tJTmXjAScIPL1FrJDiVGDjkqvcWYaE5+GvsxOF/zthn4+dbGONwan0G7gXz1GNy
ytJRTNRTq/AXaVSwB92HtSH0sx92fO85zQBBNOro3qY/p/2mit4J8ENwJfIMMFtzgjlzqqbdFuzs
7WIfUb6HOYViZxu4HjvrsbMeOx+jn4t+rkrsfCRdkMTNqVV566T2RPBDcCXyDHjVr2dOtrSy0iDn
qCzsZGlduz98f8OrHcGVyDPAK5GkET+cN7D5KdYqwCJwIVji6g7YE5s9sdkTmz2x2RObPfFST7Xs
tFBNpwUeWI2F1fBvwr+poxCvzqH/im+Y8SovfZuDnTnUOoEFlXSkn18FuJGVpX3o613HatXZedTV
0+a7we1AW1nr7mTNcjtQTcuc5A9wtm/MLaAX+D7WGmP/JLgTLKHuALAHdZch/wzc5EqU+hk6Lr9Y
0R2uOu5mb7msdNryR3q6Tw3CV/l44Gv0w+pVv5h1fT293UacfApODe4pu5iddcTkLmZtF54hPnWV
iQea6Ux5lwvO4k5ko9kEzW3wk2i9i4k35uJllTgOM+Ugz0L/U/ArsAhcx0m+yD9IKyqp0nmR+VX+
YIDMNfwyEzkqkUjIZgazmXG5R1uTnD/KvTLuXazoy7317BZdiWe3eDLLzguclDaqT9xOuu+4dyvv
vA7+CnmRnsfcF8mK6MvZWM9F36VuhHPRvWi+p/dNd71maYf7o9Nf78tufUrfoNbvFJOuQN4QC2fA
EvRziJPxOhfOm+pbZx98T7Cdopuuc+RmEBsF6L9DRH2k6M1Hpx1RkaqazpPM7Ofwwym9ltJGREt3
LJi7agnYi7a6cSp4kR2wh3rM+ZQdpIDcuIZdY52eT5y5nEinsAfN43w4DsnjnGrKsbMK3AF+CH6E
nQPgZvBB9qaP2GeXKXrvwY8Hl5NdT7IH/ULPb25LTnEfBfxSsBgsAMu1VG9e3mH8n4VmXbCT/2NB
cyPjhugsD7AYLADVwutojqHWmyoRVEkflXh3EhWDOOs+CEbAfE6GIzl/9uBOygnWbUb8vE1baDoF
mktdJII6ikNYvjrApWAxWACKNe9avZP67xAz672GUutirM0Fh4LcT90Uxv4Q/NIAl4LFYAGlOq6H
1FfuSuWTrvSfBweofWq5Aap/uCM4JeoHpxunvnEBzgbzwcEgsaQnN78O8/4TNHtobvSu9tYLf8x7
T/B55DsDzAcHg2vB6zTeKF2HZB2SJ/Ws67yqKzT0n5ylm4D/AT7I2TKde1Anzq6tOBVPIaIeJGKn
6DnQ7oHlN+Af4va6hL59gvwTteNG6P8+lbhXBDgbzAcHg7q+rtFeud/VO6z/kol5XRH2AaxdDM7l
hDCBdZTC+eFnxP8sSj8KcDaYDw4G16Ij/nSv0la89/S5oqDqLKfWcvgUPHASL+3xilkLTbTUIDfW
g3pjdQ+pxFupPXGXwh+Dd4kTF/1x3hFmwaDeXrfo7VW8oVGx2Z1A3zRiLfjl9Hw5pSaLdgUv9lIE
LZ0vr7F/m/DzVO5dRSR/Aj4U5FLNPKXk0kJ0JqP/Mivuc9bRxWTUjmTgmfBvawaWuJJa3rvMyzps
cnt1nsXyfVhrCb9U779yw9XSfDRLFZNXaoQnW9y2fo1lnpkkmWz/B243BazQw6ygN1kdN4Dcjp2F
WHgJa5b7uNQqxc5b2jeX51QuN2KZC91D7+Yu/IDyYqEc3MG6Lgd3sFrLwR309g3hn6bFZXjpjJ4B
nBfITutBl769rXdk97fgKEWHJyfORv8J3e9YxYXwb6L/InWfZqUXqMRPaDbw70X+HvplYH9wrn9S
MWmg7nTo/E4jJ+kK+IZgO6ydQX8afa6ju4PbQJ9Tudd5qcSP8rb2zTuqs+82YO2MM/dN4qHE26Bx
onL30+BOrU8si7njdGJd99Q9IqkXc/chM3Wj8n4dr56UnmLPWq43YolezQndtTSpFzvLXF1Nkq9W
gGvJSytA3UOzeY7UEvk+5PuQH0N+APlHyAdh7RNaMTevceyMO8Dl2q5XpiPyeR7rLObGPY89bobq
27/X+7VkucF4+Cv6rHmpk961/Xqs+nJW9ypF8eQm8sx19ERxM6UXcy66WE8+kg/PshZmkzG0dDxY
EGQPrbWLvPGO3rtFZybymfSffOU/IvxS+nyre4XgbxTddPz/GiP9mNkZjc7tgaZKmnAPel/H6F6q
d2SHp8qOubXt5ta2gZz8MH5IY95bcy97nmhp5Eku8pOp9RUnhFf1Pu4Nd+Vm4U4hx95P3fup+xR8
kbZlf58WhzAvL3LrH8aIfsENdwcrwkXytN7K3Zb08w70v6BFeuVNgh+nd3Pnp/BG5z4sdAB/oucl
OTfqqlzuXq77Aj38jDg3t+mbiYSejP06p1TGNVDt+KPAsYruXHchmVNXxA+U98Z4Y+iV+rMfOubz
jpVkM09LnQd0F/NC2KmP/5fTw9/pvdvZA39Mb+vO9fA99bbuvMJYLtGeeKwg93a3sUjm0P8JzjHB
RxyJBPewfsrj/5Yz4V16W5fRaX+u0Du7MxmbDwSoPqwH3q73dG85+GO9Rzh/17H7DfFANnfw/dTK
0Xu68x34VZRW0J+/0sPFyL/ks4x09YzfnNa7goMZ7wiwQ3C21F21MbU26c3d/qPe3J1f4J/GPD8s
o4d3gdnMzpPMY0RnTaJX0F6IJI1+zuQWUwh2Mzw3lELWWiE3nUK9VUmp3ES8azhRv4vmY+Cb3uPk
Q+XDYMQgFiJYiGChJ5rl3PVaqsRtiWQXkpmuzHiIunZT8Anuyz/kvvxDbmGduN89r3cliQTRtxNo
fkSLDTl/tsZaa63rdod/1CCSR9Wa4ErkGeCV7OziGW8boxvuyq3QmYXNTtg3o+sKPqx3T+k/o8Bm
S2y2ZKTljLRcfeXerpb97t528DGNIiy8ZhD/DIHvhR+6+VF8pdib+/sevb/LKKL67MvdRrtRVtDH
WDiBtajuVtoryTyKL7hXC97pThT5GDIq92W5X2vpk2Aakq7uJOHzXe1bayTkW/dK5uJz8EtFZ6Oi
t1nRbQ0+qnW9NrTyHWxmgZ3B+VgrML7CwjGwOR5+CLxPM17SevVAchx/nuLedy9P6e9TPsln17tL
S71r8PBGNLvD36180nq1lhzXk4lXyX2wE+MysdGRWe7OvMyCT8FCF3Re0ecDTo76301lFl4jNq7S
Xcw5qKNzFsLXhx+Pzj6wNbUywBRms6HW9ebpjHvzkbdD8yVm+Unl7c+RdPI7gNM03tBsrLMpcfI4
OVBxKzZL4K+mzyn48GGVi+YpenuKFcon9VUvWyHLqXoffqF+lg1mVr0Efy1YoJ+SB6Uvg/PQHwtv
sBFYiNzUXQS/CGsl4CdIPoHfjY7I7duq9Iloa/BxcDTYDdwNjlcM2YpWBZJM0FJ0cuGngwvASwNe
PzXYRd0TSArBW6n1DHwKpWXgaSS0YvdFcgze2O9C6yfBjyj9GlyJNQedLLA/8k8DXvtQhGQhkp7w
VdRqAX8QXA2+CR5BMwp/Ct6HrwQbgfsrW+jJkP6gb/1NJY7xTBqYqpIQow7dDm5Bvhe+FNyKjvHe
bZU3i4X2Zi6Ut7uBc8C5ZhbgM0ELnA4uqNTT6bvG/yoJvQqeoPQDLM8wo4O/3HgenUp0rjJjQVJG
rw7CbwvGcjPjSpa6Y6k7TiUW/gk9gmZmZZxRzKTnM+ntTPqmWIjkBHgEyVWKluHTwFTwAC02A9PB
68HPaMtE4LPwfwFTK28R7Ad/GTM7ycSkyu1F8K0q9fb9IXxn5ESFnaToE2n+g4ruciycVQ/49ynv
bWSuFxjPVL2gnzai/0sTG1h7lj58hc7X+Oo2XZWyphoR/4pTzSyfPa4rjpGODtAG0wUvB7uB4ykd
j7XxKhF/qrwH8kzQCjBd9wX46QGqZhxv7wo8n84szAGVv1XlzjOUVlDrBnpoIryCEeH/0B4zI4z0
RRPP8MPQWYKXtpvsob5yd+Axs35T4NPwzGr0V1fepE+l4Edj5+fwsxUdVrGTRQSewm+FlDKboSuR
H1Efhs7QZx/vpTKiZLxUqShxZXgdI74K/RI0cXhXgOnUnYMd1d+Cze2UvgziT+sLRn0YnA1+UHWZ
4FnGWAfJ6/BXwqcza33gN9PzQ5Q2Vl4yRpFIbqL0AXAmpXPwANHuXA9vVnqqesy+FrlZEe+DL2D5
bizcjeWdgZeUN5ltE+t6Dav1M2aBrBJy8fyN2DGZcDP416p26kn4jSYHojkZze+ZHEgr25Cz+twJ
rJ318F9V9ZR+mn1kHtnmQ/WVeyN8D+Tl2PkKnkxoXwS2BDPMmkVnPfhWkJ1uEGSnCG1AZ4lZ0SAZ
wJ6Gl7qiswM0eYO4tdkXxKtyp3BY+6GXwJGgyRXNwV+DP0c+Cv4WcDgR+BDyl4O9QON5YsCrB8ze
MQh9cog9xOwpzKaP/xuBheAWsBQkn4deZ76q4N8GT1N3q5kveDwZOgafC8bx0kn4epSuhM8C+1ee
1B4i/xSbU8GFYEmwfk1bGvnrifyTrIj+YE/kq+E7ov8o1th3QmtpvZLYYGcMkcmdxmiuJFrgQyfJ
xjvhS5APgDd5ldn3i4mo+uBjZBjOJ34TrJmM1J/evlk1Sz9jwkJV5S8Zr2BoHXiaPNyXTLIQvBPN
0+ThuozF7FMpQV5NJ7Y1M3RB0gXvdSGrnEReDz+sDFBzr4NmVoBqoYjShQGms++MwIfp9FPzUjql
m8A3qduHZ4wVPMNP40ljmv+GaNYNvl2j307pyHdyzvJs+Vr9lmNoi6JdzOe/a7l78oQq9BdXv5nz
LjcyPm2xu/sX60rnE5zNytvvwR93d3NX5TMvPZ9bA+1mOi/6RMJp4eZp6+5v9YyhvF3ufqnRqOgc
dxdY+nxJNK29iqEEtXopesU80/DBNu44XZtYKHLl3OsMwsIZLfX7Uasv2J7vJ5wCk91UnXHnYfWY
s0Z1lLcn6L9wsUcoOvnOPqyJprVBMZRhaiHZrugeVZRRKM5zntZRYKe7PlWw1xk7lA5Q9CZi4RS4
D5wMLnb0eU4LRbvU0dt9ut7r7VNIGngD6ad+i6yuSqztylt7FUVf+Q2q73XBTjq12jr6/b1mzgyd
fWcefSvRZ9rUWgx2RtJc9b1V1DoQ9ERLByCZ44zVbIO8a4D6PSI3sDZPvUTfliofKqM/jh1S9Cr0
V2/gbdtWSWgVpfoN5Hah/XxjVr/V1seeLNhan7rYpfYzmnXtX2jP7d/pulbefsJ+QnC8rZ9u26of
KgT7Kjr3ojPd5ruO9lTB65wnBV+Hb+W8hB3hQyfQpK59K3Wfgb8Mayc0SkN/ovXT9mW6lm2NigF2
I/pZX+Pf5lN+2xfJzfYlupbta3Qtq34oDt6maP1N0XGw0Atr/e3GmjPtLdhU/qT9qe4a8CVoRrFQ
Sd3vwh8E3wuph5fQh8Oh74lmm5A+4ZS8KJIzIf2U+WyoQvcCu63mVXsCn9rrL8seCZVpfxRDN9sN
VWIv050r9Bfdc8E0sI2iWBO0PoWfCjYI7UNzn650+L2hsbqbYHNLaL7gtNDHuh9pT6zPsPA37Yl9
xrL0W+juF4p+Cvyf4evx7fSL4b+P/FUkYsf9jS823YFgd/CoonMIXKjo1UV+RtF2waeRNEfnJ4r+
LjRbgFFKM+CHwA9A8yAS5O5kxaQm8NdQ+g5YgYRWnD/A3w0/AeyDZCI4RjFEb+2ulL4PX0Z/fHQK
wWJK18K/Dv852Bv8MXJG5JylrrG2CXwMzAM/RLM9PONy/k6LP4NfQ392goeR/BZrw6jVEc2NyK+C
XwQ/G58sg38QfBG8llq/SZLdx7/CzI7y7lGwysyR8l5dJGfgbzJzhORZM1PKOz8Bh4D5WLvTzBe1
ksysweMT/5iZNfQXggcpzVBMaoLkHfp2HZpPgcONf2j9B/TwXeMTlcieqLzxGH5254FdaBFvh76k
FE/apVgg6rxp4Dr054LbwRjIqF0TabPp53j0r8YCPvfC9IH4sZsRexehfwCdV+C7oWli7BYwrJj8
itZN/g79dNDpiYW3wBTkVzDq5nhmI/rTKWWNuDuo1ZS28K0zzaw7fLiLuvjWnQxeg5030GmLffxp
30zdJchZZZ6J1QRtmZXYxMQedj6AR9N+klpH0PkVaCIE7zkjTSTT7lX4apFi6EskL9CWicMbwBvB
26i7Fb4dFjLBz8CvkT9BW0Phf4gdxuXRutcBzSnYmQGP523ygzsfHA32R8e0+EfQRMjblN4LMi9O
Y1r8KYjnk5C4J2hxLHKT01iDrlndrFzvEiQNQDKDQ1Q4WLNNpiKr2F+gT113FPgyWITc5EZ4ZwuS
9fD7aJ24clg79nFqEXWeWU1mRCvRqYP+LCRm3lch7wumgvTZIWf6Bdg0vSIq3I9B1pRLbITouf8I
tR5G/zQ8K9EdB+5Gzpw6+N8bhJwc5ZK1XOLBJqu7ueAK9CuImQnEj8lXxSC5yGMdOY8hMZmznLpm
Tpl3h5nyiSXnDpC15kwFid6kzYrJRIXH/uUR7T7eTmLsPqUu+g45yukE9tbWLUvvIO5vKvXTooFg
d/CoonMIXKjo1UV+RtF2waeRNEfnJ4r+LjRbgFFKM+CHwA9A8yAS5O5kxaQm8NdQ+g5YgYRWnD/A
3w0/AeyDZCI4RjFEb+2ulL4PX0Z/fHQKwWJK18K/Dv852Bv8MXJG5JylrrG2CXwMzAM/RLM9PONy
/k6LP4NfQ392goeR/BZrw6jVEc2NyK+CXwQ/G58sg38QfBG8lrpXULcKnZvgn6U0H/5O5EkgY/GP
gddR+hQ4HPwBtd6l3TR6aHrOeN15YBfqMurQl5QyIruUusy+Nw1ch/5ccDsYA00PzYybcY0Hr8YC
Y/fC2GQe7WbEwEXoH0DnFfhuaJq5vgWkVjKlyd+hnw46PbHwFphC6XR4ItPdgU5TLOMZh/47b1Da
Fjt4xr4Z+RLkRK9nYiCBNRPhJlY/QI6O/SSSI5T+CmR2bPzgjARfwJqZxxvAG8HbKN0K345ameBn
4NfIn8DmUPgfYoeee7TidUBzCnZmwOMrm5XlzgdHg/3RMS3+ETRz+jal94J40mlMiz8F8V4SEvcE
LY5FbrIB0euadUHMe5cgaQCyphzm0cGabdY469H+An3quqPAl8Ei5CarwDtbkKyH30frRIJDhNvH
qUWceCbmzYhWolMH/VlIzMyuQt4XTAXps0O28QuwaXrFvLsfg6wCl9kP0XP/EWo9jP5peNaOOw7c
jZw5dfC/Nwg5q9slEmwyoZsLrkCHqHZNJimHNzPFbDr43ydCnDtAYt6ZChJ7SZuJf+baI597xKqP
D5MYkU+pi75DfnA6KVof2x9Z+lRks5Q2Nc8xnCki6cW9O1efNjjzeJKQRekc/bexTrp+P82ZwbMU
WyX2X5FPUbl+wcLSf22hkkGK3nZFtw3yCurmU3pI0R8Jnwv2wlq50aTdAcHTjKaWPqPQu+EcJI8H
Tzza8G/r9ClKNs9PTvM8JIVnIyXI52tdeyuSXEqfg7exUA6OBosYe11FewIe6KdPSOx1PLVoD9/e
eUvrqo5VxfOKy4LnJ4LWn1XHy8ROX2p15wlJZ5WELnNnibxh8GykhGcgJTwPEax8tkqfU/Wp2qy5
F36A3m3trcqHboUfSGl3+JXwu9EcB58M35nS31PrMJIGxhqS/ZV602+FTgNqtQWHULrTIKWp8Kcp
fR4LTZH/DnkH+BaU+vD3wP/C9EH50EemD5SOUb6yb9VJiYRmSBZbjQX3wM9R3rmEu3yVotMVPI7k
NPwMNP+k6G1XdEPIbbCE0mTFUAV8OdgWfQudKWALcBKlo+nDNPgh8EW0eASdsfAbKB2BnTrYXw3O
D3quPRmOZBmSUnAyyEidXpSGkUyofJv/hV0tr6rUJ4HpWL4/6IPK9+ocOV0Vrb3UXQROxRpPPOwD
SPqpjtusUr+r1o3SmytfEqy0oiKvj871KrG/MH3G8jztg38lkpXKh6Yi71v5usan6rtrKN2ppTJ2
nZ26WO6LvBE2n6H/V1Sdln5OpLd/o297tJaXz1gOIp9L1I3XWqEOtDUWPgM7bSvP8AnCGfUnOFlR
TlOKZUjS0DkI30DR+QG9as+sraOtMVjOpYdlir6Lb5ubCKnqr1GnOnYDlejv70iGZJW59XUsfiP0
Dyrv9UCnLpKBJg7xdhqt1MUzDdRjoScY9YBKfTY7gh4WwdepvF1jrFKfdl4Gxml9Hd64FX6IaoYq
qNUW/iSa67AwFf4p5DvxxibkzZCcoLQQyR6sFSLphuYxRck4zJeJQ/ofZSx/pg9lRIKJ5Gk6arkF
7MNLzDs4gZmqQL8SC21oqzOlbYmfMuQdFSW/67xkBTqKB4iB7VjeavwfeEN73p2xlOGrhsjrgQPQ
HBG0e4Z1cYbYO04kGE31WxPlJbaPE8mqcyc4FcntaKbSViqam6m1Dp2Z4DJK48H6zZSx+PR5CWP8
AHka+A79SRhNxnu/GbVqShTx1JqI8gOvziOq8YZ6JpTA8nPkgVV4b3XQltrJZKYamkxFrXJqrUaz
kmhvi+YSIjNFeT/DuoRIe5sZ1/7PMis6WCNqbRBz1BTMoYdHg4z3X+x9B5QVxbb2rqruU2e6++wZ
hhkYhiA5pyGMJEkCkiRLDsKQHRBhAEWSCBJERZLkJElAQERAkuQkSURykpxzhhne7j2tlxl9v9zr
vW/96//fOmt9u6q6uk7VV7v23tXdp08a9jXut+z01uw4Oro4cS27rZG1HMu9KsRnJdpVt+WBfJX4
OrRmvWrt+vRntSldn7XuMtdhO6AS19FwPreG/JE1fxXPpjvGdYm2kWv24/J6zPxoF8kurWJb4VqV
xBmZy+jnoxl51OV5vCcYP2V8yi1X4Pkqy5iZsapXx7Vyfb15dC3bKNdmkj6s4tU0h7XiKd/Jfcq6
+pT1+SnPhZt+yLz197xYGi5xRz2BR1oq0YuxzbnOs7PaRc1apNnLqItcszUj+zi46eohxcDH2Qbe
ZhvoWph63M8SrKUFWYf3slazLaKaM7imW38Rl8dyzcqcrsblM7nnBzi9gMsrJexn7MKr77Ybk7vf
kjDu2WmerzruauU5fZ3HlTnRryVs5Pv14W5vuecDeCwZuWadBI55+Nx0kIHajPRmltLxX7stA/B7
3sBwf6fjXWl0ESwut9xyALckoYn7lHVCY/dJ+AT+PUiCxekoTkdxurD7nHZCEfdZeirvwuXzON3C
fX7MfTKf0ps5fZ3TV920+yseOnel+5YbLi/iPg1I7cznd7Pc4/fbrHbR/R0BgPs794Qw99ccCWHu
70ESlvhi3bfc6A/ct9y46fg1bjphgO8z9y03+qbbvu+si/oGp4+67euLnH7C6cQ6tRkLc82WjK3d
9964fYs/ldhn3xdcfwanE8+6zH2+y+VZuTzERV2WR5ef8QaPdyAfXcqoufxlrlmev+sql+/gNgtx
SQlmJrHkMR9twvWH8TfuYJYeM/bjby/HNfPwuW7NgpwuyOlCvm1c/pDTebidxPLs3JP6nM7F6Ubc
zkEX/ZrT/CYfv5+PNuGSodza9+47cLiFl7mFKE5Hcbqw+3t5qv8Tp1MxhvNZFbnPhbjPrXiWJ/NI
7/FR7ptvNpe0YNzMeJePpiYsoBdxejG3uZbTw7nOt4yjuHwpp/dx+o7bQ/ctHNRbVw8L8315Ff+M
08ybeyc9ISr+ktufeJ4L9847ldx2j8avcZlMLEnox5iRkc/iFqLiN3FNPjeeRx0/mdNnuc2NnD7A
6et8lDUq/jCXXOB23CdwACwxxH8ZVMx7XWMhrF3XNm9B39iWcZ1hCdDOr26d8hmBdhbPnkE4OOCD
dJAFQiE/FIXiUBaqQgNoRm3UhvfhA4iBDvA2dIfBXv0AaEgPWSElFIBoaqUcVIOG0Jy+tQ70hgFk
OTpCF+gBQ/g/BhPPQfCTzcgGYVAQXoaSUJ6scyNoARLqQh/4ENrAW/AO9IShkApUlVq1KkPVOjVf
zwit6tWplhHGcSup+Z2hL5Ftzk4tRkEpeBVeg9ehMbwJCnJDPegLA6EtxEJXeBeG8TlBkBFygOvp
XoEKUAPywMdcHgEhxEMmiISc1G5hKAaloSJUhprQBFpSv/PCG9APBkE76ATd4D0Y7vUgBdiQGdJC
LmqhCJSBSlAFakFTaAUm5IP60B8+gvbQGeKgl/su05hC3WJUfcbmjG0ZOzP2YOwb0zI2Tn3EOIJx
AuNMxoWMK2JadmujNjBuY9zNuJ/xCOOpmJhOXdR5xrsuGpIxhDEDY17GEq1jO7QzKjFWZ6zTuvPb
nYyGjM0ZWzN2ZOzC2IOxd9uuLWOMAYzDGccyTmOcx7iUcS013NLYxribcT/jkdjO3TsZpxjPM15l
vM34kDHBRdOIfTsm1rQYQxgjGDPQwa5mVsbcjAUZoxlLMZZnrPy2204NxnqMjRnfZGzLGMvY9e2u
rTub7zL2ZRzYxS0fxjiCcSzjJMYZjHMZF3ajOTKXMq5k3MC4jXE344FuHTq3NY8xnma8yHid8S7j
426dYrr4gNFiDGPMwJiTsVC3bgWjfKUYKzBWZ6zH2JSxNWEhXyxjHGNvxoGMwxlHExb2TWKcybiA
cSnjasZNhEV8Oxn3MR5iPMF4lvFyt+6tuvluMt5nfOqilox+RuzWvUs3HcYYyZiRMTtjXsZCccSk
LsZYmrECY1XGWoz1Gd1oXJLtCfsnpKJ1nhbS/UspwS8O/T+jSRbDJCuqwf9vyxmcS0wLsnrJMfCC
qMjO2fzO5b+TEmS9/xxDXxglz4ikVt0cX+1x/YMbJb4wpnhhTP8HDHlhzMg9VSzFc+iO4Pky/EtU
5KlSQcQ/mUrNKUn+KfM/JbNA1n9KZoPs/4QU5En/Gv+aE0Ee/K8x+IUwiqKNOPL6o2EmLIVNsB/O
wl1hiDCRVRQRFUQ90VrEiYFitJgplopNYr84K+5KQ2aQ1WUvOUxOkPPkSrlDHpGX5WNlqUiVW5VQ
VVVj1VH1UsPUBDWP1qD7Xf5EnVU1kuVbJcsPT5b/9Lm8key4j5b5IdDiubxVJGnemZH0fLyftP2w
xknz4ZC0/fCwZPnsyepXTpZvmiyfbDzhR5LmU+VMlq+VLP9u0v6nm5b0ePrVSfPZ8ibL538uT+sv
W8FkxwdwXpJ9CE0cYY5aiTJn4sgN0rlUZKuye6V7PXnEk2c9efPPaude4snVntziyX1Je5EHk44y
z8qk+QIDktYvcCxpPmpn0nyhZcnyK5LmC9dLlq+fLN8lWb5rsvzY57SMEtHjkuVXJq0fnWyW/nB8
d7L83mT5fUlnsfhuQiRmYsQYaCsmsbVtRR+glToahBlipmBfEQo+pwpucSrjJlyHG6jEJ66Ja1Tv
prgJQtwWt0GKe+IeKCyH5cDAV/FV8puuPkhVUVV2v0+GynAqcX9BhG5/VIDOzE/5VLQb6QqTYAuc
gscijPrgp16FObVBOpWdOoRVnLqEVan3IWSTM9JuoSDteUrhRVAyhPp0ieUWpJ2WDKf8FZZb8ABI
yh0i3IJHCLfRWF0NjYTMeIr6uo6O/spyC54muYHyZ1huea7mWa/mOa/mea/mBa/mb/2txv2tzv19
nfv725EafKQmH6n1/BHcwT3cyT3czT387chePrKPj+znIxK0pA8tM1u6T26HyBBiNZxYVU4l5zVi
fR2uAx/1aQMxpaiGezcy0evT0qLzW/J8Ac+UEI/FY5q1Z+IZsWVKinu4XZPb9XG7WkbKSPDLzDIz
BMmcMidYqjLNpm22MluBY7Y2W0PAbGu2BTTbm+0h2OxqdoUQM86MgxRmD7MHhGJGzAgpMTNmpjFl
xawQjtkxO6TCnEh7PsyNuSEC82JeSIP5MT9EYkEsyO/lLgzpsCgWhfT4Mr4MGbA4FoeXsCSWhIz4
Cr4CmbAMlqHZcfUtC+tbVnwNX4Ns2AybQXaMwRjIgW2wDeTEdtgOcmEsxkJu7IydyVB0wS6QF+Mw
DvJhD+wB+fFdfBcKYF/sCwWxP/aHKByIA6EQDsbBUBiH4lAogsNxOBTFT/FTiMbP8XN4GUfhKCiG
Y3AMFMcv8AsogeNxPJTEiTiR9HMyToZXcCpOhdI4HadDGfwSv4SyOAtnQTmcg3OgPH6FX8GrOB/n
QwX8Gr+GirgYF0MlXIJL4DVcikuhMi7DZVAFV+AKqIorcSVUwzW4BqrzfL/O812DdGUT1CRd2QK1
cBtpS23cQdpVB3eSdtXF3aRd9XAvadUbuI+0qj7uJ61qgAdojTTEQ7RGGuERWiON8QSegCb8Tuym
eANvQDO8hbegOd7BO9AC7+E9cN/zPYDWxwDSpGARDP1EpEgP/fmfUQeKxqIpDBKxohMM4X9DHSbe
EXHwsRgmhsFnYpwYDyPELXELRor74j6MEk/EExjtGhkYI33SB2OlIx34QqaQKWCcTCVTwXiZVqaF
CTKLzAITZS6ZCybJgrIWTJZxsjuslT1lT1hHcUQvWC/7yL6wQQ6UA2GTHCwHw2Y5Wo6GLfIL+QVs
lTPlQdimAmR/nqoiqggkqPKqAjxTVVQVIdVkNVkoI86YLgwzxowRhcw2ZhtR2GxnthNFzA5mB1HU
7GZ2E9Fmd7O7eNnsafYUxcyffUNEcauu1VLcsAbbQiQ4IU5F+Z7TxJkiFwVaBzrKO4F+geHyMUr0
Kz9mwkwqGLNgFhWC2TCbSoE5MIcKxVyYS6XEPJhHhWE+zKfCsQAWUKkwCqNUaiyCRVQERmO0SoPF
sJiKxBJYQqXFUlhKpcPSWFqlx7JYVmXA8lhevYQVsILKiJWxssqEzbG5yuz+ObXKgm2xrcqK7bG9
yoadsJPKjm/j2yoHvoPvqJzYHburXNgTe6rc+B6+p/JgP+yn8uIH+IHKh4NwkMqPQ3CIKoDDcJgq
iJ/gJyoKP8PPVCEciSNVYRyNo1URHItjVVEch+NUNE7ACeplnISTVDGcglNUcZyG01QJnIEzVEmc
iTNVKZyNs9UrOBfnqtI4D+epMrgAF6iyuBAXqnL4DX6jyuO3+K16Fb/D71QFXI7LVUX8Hr9XlXAV
rlKv4VpcqyrjelyvquBG3Kiq4mbcrKrhVtyqquN23K5exx/xR1UDd+EuVRP34B5VC3/Cn1Rt/Bl/
VnXwF/xF1cWDeFDVw8N4WL2BR/Goqo8n8aRqgNfwmmqIN/GmaoS38bZqjHfxrmqC9/GBaurtpdzI
pwjb2lykzqZoJppRcRvRBoSx3FgO0hfviwflL+0vTavn32ONSXP/1xr/f26N/6F9kax9ud1oS3Tw
Hf1fHftfHfs36ZgwO1I8HyIyyyKqktEQ0kEJKA9VoQ40pv1CR4rfe1E8MAxGwgSYAfNgCayEDbAD
9sEROA2X4TZF9iB8wgl6F1RQt6C4oPdYdg/qxbJH0Pssewb1IRlHqb4s44L6sewe1J9lj6APWPYM
+pBkd6o3kGVc0CCW3YM+YtkjaDDLnkFDSfagesNYxgV9zLJ70HCWPYI+Ydkz6DOSPaneCJZxQZ+z
7B40kmWPoFEsewb1BklHBxB2DxpC2CPoU8Kef4ORMTzybkFjPWa+8JgZ5zEz3mNmgsfMRI+RSR4j
kz1GpnqMTPMYme4xMsNj5EuPkVkeI7M9RuZ4jMz1GPnKY2S+x8gCj5GvPUYWeows8hgZTePvFjSF
GZnJjMz7m4x84zGyxGPkW4+RpR4j33mMLPcYWeHpyvceMys9ZlZ5zKz2mFnjMbPWY+QHj5H1HiMb
PEY2eoxs8hjZ7DGy1WNkm8fIdo+RHR4jP3qMLGZGlrGmrGNGtvxNRnZ5jOz2GNnjMbLXY+Qnj5Gf
PUb2e4z84jFywGPkoMfIYY+RIx4jRz1dOeYxc9xj5oTHzEmPmVMeM796jJzxGDnrMXLOY+S8x8gF
j5GdzMg+ZuQQa8rpv8nIJY+Ryx4jVzxGrnqMXPMYueExctNj5JbHyG2PkTseI/c8Ru57jDzwGHno
MfLIY+SJx8hTj5F4j5EET1eeJTJjQSIzlkhkxpKJzFjKY+YiM3KdGbnLjDx2NcX9n0a333w1rSHk
EvvkVFVd1VRtVTvVUb2luqnuqqd6T/VRQ9RQNUx9rIarT2jvclqdUWfVOXVeXVAX1SV1WV1RV9U1
dV3dUDfVLXVb3VF31b1AtPs/SmKv2EtfMMX9da6qpqqBVDVUDVCqtWoDhmqvOoBPdVVdwa/iVBwE
qR6qB0UC76p3wVa9VW9wVF/1IQTURDURUqqVaheEBYoGivJVhkiwjAzGS0ZGI5OR2chiZDWyGdmN
HO7IqEf3+Oq6gIjnrk3k4etBsW4NOjOHVyPdczXyPneMmFSxVBuMMMN9F1hOIyfY3veGGeFGKiO1
EWGkMSLdd99RjX98r4SsEGyEGikN0/AZ2vAbQYZl2IZjBAw0go0Qw73eZdDY+lEX3HOk8YpRGhyj
nFEOkI5FQ4SareaqBWqR2qQ2qy1qq9qmtqsd6ke1U+36M8bdq2VqlppFLc5xf9es5qv5xPdCRXaU
mNtI33daXfm99VlUaz4dXalWqdVqjVqrflDr1Hq1QW38sznm1mer2dT6XDXXfSJTLaDWFymyztTD
XdS6Ow639fwQ9qet/sk4mLPTHmfueS+oXXyeqw10ntlZLoUPYSAMgo9gMAyBobSuP4bh/O+in8EI
+JxW+SgYDWNgLHwB42A8rfmJMAkmwxSYCtNgOlmAL2EmzILZMAfmwldkD+bDAvgaFsIiWAzfkHX4
FpbCd7AMlsMK+J5sxSpYDWtgLfwA62A9WY6NsAk2wxbYCttgO9mRH2En7ILdsAf2wk9kVX6G/fAL
HICDcAgOk405CsfgOJyAk3AKfiWLcwbOwjk4DxfgIlwi+3MFrsI1uA434CbcImt0B+7CPbgPD+Ah
PILH8ASeQjwkwDNSaCFryzqyrqwn35D1ZQPZUDaSjWUT2VQ2k81lC/mmbClbyRjZWraRbWU72V52
kB3lWzJWdpKd5duyi3xHTpOH5GF5RB6Vx+RxeUKelKfkr/K0PCPPynPyvLwgL8pL8rK8Iq8qS16T
15Utb8ib8pa8Le/Iu/KevC8fyIfykXwsn8inMl4myGdkgtyn7ZUylKl8Siu/ClK1VR1VV9VTTVUz
9aZqqTqpd9RANUh9pAarUWq8mqQWq2/Ut2qpWqG+V7vVHrVX/aT2qZ/VfvWLOqAOqkPqsDqijqpj
6rg6oU6qU+pXo6RRyv3fVmO/8YtxwDhoHDIOG0eMo8Yx47hxwjhpnDJ+NU4bZ4yzxjnjvHHBuGhc
Mi4bV4yrxjXjunHDuGncMm4bd4y7xj3jvvHAeGg8Mh4bT4ynRryRYDwzA2aoLqfL61d1BV1RV9Kv
6cq6iq6qq+nq+nVdQ9fUtXRtXUfX1fX0G7q+bqAb6ka6sW6im+pmurluod/ULXUrHUOfNvRpR58O
uqN+S8fqTrqzflt30e/orrqbjtPddQ/dU7+r39O96NNb99F9dT/dX3+gB+gP9UA9SH+kB+sheqge
pj/Ww/Un+lP9mR6hP9cj9Sg9Wo/RY/UXepweryfoiXqSnqyn6Kl6mp6uZ+gv9Uw9Xy/QX+uFepFe
rL/RS/S3eqn+Ti9z//tVf69X6lV6tV6j1+of9Dq9Xm/QG/UmvVlv0Vv1Nr1d79A/6p16l96t9+i9
+ie9T/+s9+tf9AF9UB/Sh/URfVQf08f1CX1Sn9K/6tP6jD6rz+nz+oK+qC/py/qKvqqv6ev6hr6p
b+nb+qF+pB/rJ/qpjtcJ+pkf/ELP0rP1HD1Xf6Xn6Tv6rr6n7+sH1rvWe1Yv632rt9XH6mv1s/pb
H1gDrA+tgdYg6yP7fbu33cfua/ez+9sf2APsD+2B9kf2YHuIPdQeZn9sD7c/sT+1P7NH2BPsifYk
e7I9xZ5qT7On2zPsL+2Z9ix7tj3Hnmt/Zc+z59tf2wvtRfZi+xt7if2tvdT+zv7BXmevtzfYG+1N
9mZ7i73D/tHeZe+299h77Z/sffbP9n77F/uAfcj+1T5jn7Mv2JfsK/YN+5Z9x75r37Pv2w/sh/Yj
+7H9xH5qJ9jPHHCEIx3lGI7p+JwzzlnnnHPeueBcdC45l50rzlXnmnPdueHcdG45t507zl3nnnPf
eeA8dB45j50nzlMn3klwngUgIAIyoAJGwAz4AjrgDwQFrIAdcAKBAAaCAyGBFIHQQMpAWCA8kCqQ
OhARSBOIDKQNpAukD2QIvBTIGMgUyBzIEsgayBbIHpgYmBSYHJgSmBqYFpgemBH4MjAzMCswOzAn
MJfvPvMVWb4y2k9OlWRB+XrndFWV/Psv6nXy7wdVY9UEDqvmqgUcZR96XHVRXeAEebwP4KQaqUbC
GTVOjYOz7NnPsd86z37rAvuti+y3LqllajlcZg9x1ShulBDA102laZmWKGiGmCEiiq+MFvL96jsv
LuqCuoi4zldJ71iDrYlSWrOsH2Rqa7v1UBbia6Wt+CrpbPL2tyGIooPM5PNrUAQ0gTzAWrLO9BX2
IJC4nVMLOOXeowmBVJDO3kr5g/Y2wsP2dsKj9s7f6x6k1HrwUywRARkoAsidePfIPuyW20cJf7SP
E+6yTxLusa+5Z2K42yKmclvE1G6L3FY8t/rbPZogym1Gi3Ar2kmOBPORED6SIsmRCD6Sho9E8hEJ
QTRrBWnuikn335JKypIgZSVZCZSsIquAIWvKmmBao6xR4LOWW8tBWzetm9SeNOfKn/5DPjaph/1/
27/+z3hY14e+qN/8T/rMUN1at9Xt9fvkgVzPWZF8ZnX2ZrXJM33KfrIh+UjXOyb6xjYv6BV7/4U/
/KM3HE9+8B8e8Hnv8n+bN/zd25FfHEf++3mvWI6iDzf2SIw83LijFkUej7y44wlFHY0o4pjCMcdU
ijgek9bWJ01t4erlb75TdkrqN50QJ4UT6qR0wpxwJ5WT2olw0jiRTlonnZPeyeC85GR0MjmZnSxO
Viebk93J4eR0cjm5/9TbDvpzf4tBaKH9Ql53wR/9LgZjCKb4g/fdam+zt7MP3vmnXvgg+eHD9lH7
uH3yN3+MqTA1++Rr/61Xjv+jX8YITIOR/5J3TuKbnfj/Ae9cQ0gRTlvZSJETwkQtUQ+y8J3SnKK5
aAN5RDvRDgqLDqIDFBFviU5QVLwtekEx0VuMgQpigpgMzcV3Yg+0kl1lHPSRPWQf6C/7yQ9giPxQ
DoaP5VD5CYyQn8mRMIbveY6XYyVZe97jT1GOCoWpKkyFwWyVSuWGOSqvKgCrVZSqAOvY4+9nj/8L
794OGDOMPXDZTGGmEBHmffO+SGM+NB+KSPOx+Vik9RFdIp1vqO8Tkd73mW+UyOwb4xsncvgm+CaL
PL6pvnmigG+Bb6ko6Vvm2yIq+Lb59oo3fAd8B0Rz32HfUdHCd9x3UrSi2CBetPE9o9hggI7WJcUK
/YouI9b6c/lzi/X+vP4CYqM/yh8ltvqj/dFim7+4v7jY7t4/Ezv8Zf1lxY/+8v7yYqe/kr+S2OWv
4q8idvur+6uLPf56/npir7+Bv4H4yd/Y31js87fwx4if/R38HcShINr2i8NWKytGHLHaWO3FMauj
FSdOWT2sHuIK+dmJ4ir52R/EPfKzD0WCLe0mUtvN7F6ypTPVOS37BT4JTJAbE59vod3oQr7j0ky0
9UqWPVcioAT4vNgjO8U0Rej4LPq4uJCiglks3dwaL7eGcsfp4z5lk0fkIa3JL/KTuysmilGbr4nX
yLlUE9XAEOPEOH7KZhu0NCPNtGY6M72ZwXzJzGhmMjObWcysZjYzu5nDzGnmMnObecy8Zj4zv1nA
LGhGmYXMwuJnsV/8Ig6Ig+KQOCyOiKPimDguToiT4pT4VZwWZ8RZcU6cFxfERXFJXBZXxFVDGYa6
rx6oh+qReqyeqKcqXiWoZ3+nzKChGJKvNBj8a4UUfDcrgj4K0tHHIOZy0EjzgvtcWgH6+InVEhQn
lqKPBaXpY0MFqAgOVKMPQgP6BEMjaEzxYXP6hEJr+qSE9vQJg24QB+HwHvSC1NCPPmlodUqIFMEi
BNLSGo2E9CKDyAAZ+JmGl2i91oKMtF4bQya+q5uZV2oWEStiISs/5ZBNdBc9ILvoI/rQmh4qhkIu
8bEYDrnFCDEC8tIKngD5aAV/B/nFOrEeCogtYitEiZ1iJxTm601FeOVFc0xdla86NeerTm/ytbDI
566F5eOnqUrKpsRYehkloyhyjJbR7m/EZAU6UlVWpcixjqxDkWMD2QBMin/agI8in7cochxiDQO/
NdwaAbY125oDIdZX1gIItQ5YByGVddg6BhHWSesMxdS97b6QibzIQMjqegjIRR5iOuRx7TkUIHt+
AKLIih+HomTJT0I02fIz8DLZ83NQjPZYF6A42fRLUILs+hUoSbb9Gs1V8rHk57FUkR1pLBmSjKW4
LE5H3BEpWYv2NAaPyOQR+SjOawyax+WnKO4dCOJxWTyuAI8rlMcVZi20FtOIlljLIC2PMSOPMbN1
wboE2a0r1g0alzvS/DzSKB5pNI+0GPnBWbRPmEO7jTI86oo86tfIP92HauSd4mmHknj31f2VY2se
UQF3jO6b9qCEN8YCXp2ctHpHiLG/l0kxTyymXNjv9WgF/AkHpSTxxkwYPLcm8+FjPjTz4Wc+giju
bQYWs2LzbDvMTcBqZDUCpJ15Xwim3ddImvPR1kRIR3uwZZDVWmH9ANG0E7sBpa1b1kNoQzHEYOhE
0cII6EXRwQIYQL7/OxhDvv4wTOY5X8Fz/j158F9hJc/8Kp751Tzza3jm1/LM/8Azv448+w1YT979
FmwgDx8PG8mf+2A3xTgRcIDimkxwgmKZ3HCeohIbrlN0kQJukY+PpB0AWULaIb0D4O4gobx7lQFq
u0/bQF37faci7KZz0ovxL1yP33b5H6r9uz5AK57VgqzztZ7Th4L/0AeoB6V/L5NQie/dh/1eT4Ky
Jlkz6TvXWdtIxx/Z7sqhUt7lJ/YkE/ehoNfL3/pagqzZv2Dd6cxwtoXAtlCwLVRsCw22hSbbQh/b
Qs220M+2MIhtocW20GZb6LAtRLaFwWwLQ9gWhrItTMm2MIxtYTjbwtRsC93fNm+gETiysloJZf/y
XpAUlgilXmYWuUUhUUKUF1VFHepdK9FRdBE9KH4aIIaIT8Vo+tZpYrZYIJaIFWKt2CR2iL3EzTHi
4aK4Lu6Kx+SAfNKRoTJCZpBZZW7iOFrkptHnJC7ysWxMHtiVzURxls1FCZYtREmWb4pSLFuKV1i2
EqVZxogyLFuLsizbiHIs24oKLDuISixjyau78m1Rk+UEM7UrjWVmBMvlZhpX4hO/7Uozpd9xpW+m
P8ByjR9ZrvUHs4z3h7BM8Kdg+cwf6kqKoFKyLBMs+Hs6ilxkjYIp1pCUy0vYmCION34hm0SjJE2k
MUYRvikKEbYUhQlbCYplaGxFCVuLaMI24mXCtqK8+/yJeJXwLVGRMJZiFkmjqkzYRVQhfEdUJewq
qhNOEK8TThI1CCeaYSBpvOGEy0336ssTP00MjZS0msZpEK7xU8xDY/S5T1T5NWGC30/4zB8EksZG
EZi/DOSitdWUfH4s+freMBCGw2iYBDNhASyF1bAJdsJ+OAZn4SrZF++eImlSBOl6VtKlgiJalCJt
qixqiHrExps0qlgxj9iaQAzNZ9lMLGDZXHzNsoVYyPJNsYhlK7LurowR37BsKZawbC2+ZdlGLGXZ
1p/elTTGDK6kUb7Eco0/I8u1/kws4/2ZWSb4s7B85s/qShpxNpZlxBSev6k8c9N45qbzzM3gmfuS
52wmz9ksnsXZPHNzeObm8sx95c6HP4wZD2fGUzHjqZnxCGY8DTMeyYynZcbTMeMCjGDgJ8sV2wrg
lS6C3Z+JuG8TrsHP9eeEQhwH8NUwkYp1LTXrSIT73W4rIs3vqfauJrm2l+zJWNYVRvcunQghCwUi
nPZVgi2RZPvi+tUIGCreEA1EI9FQ1BftrYbkARsnXpuW3WVfOUSOURPUV2oJPsV4TMBnZGUnW1Os
qdY0a7o1w/rSmkkWd721wdpobbI2W1usrdY2fIASFRpoog81+q1H1mPrifXUircSrGc2mT37c3uk
PcoebY+xx9pf2OPs8fYye7m9wv7eXmmvslfba+y19hH7mH3CPmWfts/a5+2L9mX7qn3dvmnfdrTj
d4Icy7Edxwk46AQ7eZy8Tj4nv1PAKehEOYWcwk4Rp6gT7bzsFHOKOyWckk4p5xWntFPGKeuUc8o7
rzoVnIroYAARQzElhuFDfISPMS2mQ/c+aHbeeQLvNk2KuqqRT+soYylyiKNdpSP70K4ywM/NIu8h
g3lnGMLXf1Oob9Q3EOpb5FsMKX3Lfcsh3PfA94BiRtovQWp3v0Sx1QnrHORyd00USQ2h+KGE/TVF
Dq/Sjv8wVKdd/1F4neOHGhw/1OT4oRbHD7U5fqjD8UNdjh/qcfzwBscP9Tl+aMDxQ0M7gSKHRk4I
RQutOFrow9FCfwynaOFDGudKaPwiM/qvzeB/ZJ5+myGL2QRmM4h5DGUe0zKPWXnk+Xjk0Tzy2jzy
ehwnNUjcfZr8b4OUrgruteXykOF5/U+uxf+9PibqDrWQgjUFWFMUz7CP5xN5PoN5PkN4PlPwfIby
fKbk+Qzj+Qzn+UzF85ma5zOC5zMNz2ckzVtqSOv13jbxud4jxbzeinXXPOspsJ4K1lPJeqq8cx0z
+LlzIygq+d0K/LbS2XLwKmBNNlmTNWuyP3EnLW6J++KJFw2kkKlkWplF5lJVzBizjdnO7GB2M7ub
PTETZsFsmANzYR7MhwUwCotgNBbDElgKS2NZLI8V/qu9M4Gnquv3+F77nGM+O6GMyZxC9jFkipIh
IYRooMxTpjiRkuEYGiSRVJKxWYaiKAkNopTUo0GFpqdSCKU0cNdZTfTUfe597/u+fe7n8/p/nPNf
a5+zz9p7r/Vb3/8e1iLMiGWEB+FF+BABRBCxklhFhBMRRDQRSyQQG4hNRDKRQqQR6UQGsZPIJLKI
bCKXyCf2EvuJg8Rh4ghRTBwlyojjRAVxkqgizhB1xDniAnGRaCQuE1eIZqKFuEG0EreIO8RdooPo
Jl4R/cRrYvA/T3r8577Pf9qTHvyQ+b1ogsQH2OfP+h/d1w5bIvDjuDfqLmQu9l063+7x+W/u0/l2
hw9cB66PLxt1poOdYwEV6Nv5AvAaewsZXRPXhp8wgnnW+ALcAV+MO+EeUKuCoeqtY19X+5mxr6WN
NriWsab9V2NfeRtt7Ot0PzWjH8yUfRVvjFn/1dhX9EYb3JZfGOwPxhjc5rG2+GcG+48xBvfSWFuG
7Hva4wfzhub3Cwv+mfEOjzXYa4010R9MZqx92b7P5UVr+M/5kV+cHwFYO+w/Z8K+3gxStj0ai+Xr
CCzs0Vg2YVuxDBj95GMHsWIY/5zCarF6GAFdx27D/Uei683/21ftf+jV+h95/elZkM/nSPjgWwY7
7sEM2bEA7OsmouiBfZ0FgKkwjsZhb78d+hlgB/R3AvYM4tkw8sLBcdDLHoUW9MF4pR/Nw/EGDEL/
LRhCfeYH6H8Ew9AfwdmzoOA4FdY5Gs4BfU6cPXIrLw7jb5yO5hThx2GMjQvgQtCfgE+EvjB7jhDY
r4pDXwKXhr4MDiM3XI49+wjsY6dCfxo+DfpKuBL0lXFljD2rigr0p+Ps2YB247uhn4VnQX8Pvgf6
2ZS5aCTZeRiFYk4TZI9VR4PbSxOjmbBHV6TNxSg0M5ore6xwmi/0/dgzE8O+Ohz6q9mjVtESaAnQ
T6TVYuxZluugf5YLKjMXDqNInEuBewUGuP25IelxB9APYYB+mA6jXnohvQ76Z+kXoF8PSRUQkpAz
KJAmR1CEB1V5HD5O+vNz1ujI4Jjbl6eDvzMIQAwCEIOAUU+xAsQgADEIQAwCEIMA9OwJQAwCEIMA
xCAAMQhADAIQgwDEIJ9LiCMSAYhEACIRgEgEIBIBiEQAIhGASAQgEgGIRAAiEYBIBCASAYhEACIR
gEgEIBIBiEQAIhGASAQgEgGIRAAiEYBIBCASAYhEACIRgEgEIBIBiEQAIhGASAQgEgGIRAAiEYBI
BCASAYhEACIRgEgEIBIBiEQAIhGASAQgEgGIRAAiEYBIBCASAYhEACIRgEgEIBIBiEQAIhGASAQg
EgGIRAAiEYBIBCASAYhEACIRgEgEIBIBiEQAIhGASAQgEgGIRAAiEYBIBCASAYhEACIRgEgEIBIB
iES+jlHybcQS8VD4LoRyMfEVJEvcm4N7WqJZ4ls64MRzWeKLYJY9DgCDl+TmoCkRFFyMhpGuHDxK
HIAKWFo4oObakQtI5VE5EvmSMRLoktJMzBpzw0KxICiinhgT/rMvMRmQ0qNWRhWawllgrT2gsvH5
HCCy8sWmtudGVddyWROnkSyqAMnC3+dScIBDcajDkmbO3DC+xWDQ/WXHbJL+raSACssUzFAip3JQ
FlJ5BWWMgoIjQny9fZhSiu5TpRg6OlpS833dQ4JCg7yYUkZBIcHTGZKkxOcPTxi7JCjElekbFMiQ
Jiezl1MERb4vtw0KYkoZrmL6BIX4MiNISWG6jhbJYJCkFgn/lgjT1UiGmjrjS/I3lIgFZEbvFvZM
VSwoKzCfB2cBgB3Cq+uC/9TrtxJXzNmxehnZlX8oWX75u+HtlgUVw3vypQwiF+Tvzk9xUVvRMscj
oudIWKN9W/+LrESJlJx4r7ILK9a4yd6cNLN9HEh7lnG+RsUrM9NHYdc1XeUavuOLFOpMn/IYaGco
H1LUOfhyXtycR/HjqjL9F7oeYUXmuaiEWz7fVe6hl2kjweCSE8o59DRVSeRP/Z3uQi6LaJ45k7Rs
17890JuO14vfqFloUrYxpkb3pX26VfGnA2sCmFYlIk0Z3IrSmONWF1+tKgsBzpkOI0s/7PXi4dp/
PdbBsfeE3rKJseHUtsEzxTHbh0uvRN88IBbiNPPS6VdcBTJkGUdCY5lUuGBCB06BFb8g9iAZu4+M
zYd7cxKgxmaSsTti+JdeC+71DcmWXRAldGz+lpHLeSH//uPH+ps6TmEfw+3PeGuTB3aIaHZXArnb
4eMHnFzUcrJ5LxvQUjekNOr+Kd3/ynGb8vHcuQ1uvR9vNenpLTk0w953WC5gVmPT4XZa5H1Gsn4O
f7Bf1bCAtYhv7cdrRo/GL5Gy7nJbW3JYtEFJS17ljGeewCb5ce4Fb+0lhqQbb04YsD0SaKTG+Ykl
/O6Jtz99wWB1n+3F6qfnyY9SDO4Nk7ZPFZvfOgnf1xfTSSlf+vro/QbHHs95F23tT5RTFAVGtt58
xZUSVbnjQqGW8uM1jw+GPwrLxa75zaq7PmNTp6HAQU0/cb+7mg/+kKA+PmhCbViirh04X4LuVsGT
v/lGq/0s0ysSC/cH3xXQXb9tVc6B67lQFVxIFsXysyrwTC8cf89mxGnP5dqvmjLpd4kBbPfaavAP
KoAaFAOGGkxqfhWDCKSgcCUcgvhCO4YgOZ6d4BLkcXQN9fEN9GbCn+EnCXYmpyCnradHQFCgx9eC
8fyqYLKk9OeCiY1e7uEpZefrHQjXKmVjZPi3qlARse6mc5mJzkGNI4y2IXnNeeG1HyZnXzRZ2dti
+uyPzedWWNq6vd6Fn5t/e56/qpyBZ81V2Qpes4roVfdNqg+nEDYX5JX6c5/SZSe3GMq9d9vVLGqy
b5v55F1XylRlzpmrRAbdmSCpt1mHX+d+9dTXXnoqQG1keIrZ/uP+YH3Wh1PH3KNZQ065sfEJW0r7
K9MLmrX32yQIT1lvdZ8cxPRf1w/px55J7PbXOTBdY7B8egnPOrfU1V5ZO0PpiSX95wekTloLJLtf
Vr6jZiLaU2WeoWdjJ3LVa0HE4aL1DQ4GOSybDYG0o5p1a+Wqbb30d1k1KUWpB8bP5WjJvmaeiAcm
Yntr13fYfVGF92TsW1KQLQryVD6Sh4MLdmg0GieF8v9DKsaxyyjInnaSRlLgGzmJnUFQJ1KFmiZd
DcOCl5b0tZ23ylxgPL3A2P0VyctePI5Khc0ocVTTQRqztrA4ylyh/+ppK2b+oinMaavKEj8VWqav
xuY/v/RC5J7vBSI/cgA3qr+0vumdXdPZnGqHoFfuxoeMsZ6MhsxWiUreHFF6+q02yaKp63q794ce
SWnX2aK/0++0dsD1DSWynzqe3/TlTt1QPfwAq9IYeBs5xC8wnfZiasa2OSsUV1Zop3Ry0hudfa5U
xxiu8DpYVVG1ReNSP4U/cs2b651zOtYOP3hwZHiwo5VeFnwz7ZH1Ce38SJU/9O9q8Lpp4TmxfrIb
B53cU0qXVOncctm8MF5M/Y3ezlwWX/7ypDLlirx9lwvbpE7UkKIJUkL0aadtXxt2LiMfpSn6rq8L
fjhwoPBqzJyQMAJqjB/UGNsvGuM6bvV8REiU0e2IBnXmN7bqr4KjTpJQcdSh4JA6pBo7qc5Oksx/
SdG+LKf8Yvnfak3+XZ7k5rN183ZfOayrUSS7eMVd/zPSMhXpDV3FNfWtCmfVxiedbnNW/jDDQXKC
UnEK/b5QQaCiZfTEWYZHkmcfNd1AvxObXrSD45qjcZhTV99H4mE0s0D9MvNJ7yPXvChKhclIq4FA
a+mlZfRra/srBOkfXfwUE1Ztrig6nfBMuHzrmTcTT7g5d4/v0O2RXppUEhN6zuTR9o3hLrufFoXX
aSWrC6kK3nVrLBY7ZL3Tu+gPKR1yZWeyt+nDeonXdBumoeozmpyf9Ip5pWnnj+lcnLMvwEnEvDDl
1pY4g9U8c2/vPRYve+5h/1qvo+bMagVDiyxXIRcrsoE1cI03OLJn4fzw61wLw2K/aM07MvYN2veT
xrFbLGyEHLWjGuyA9OwtkQve2VvsfCJ8yy9OgzZd4dnPpYmtE5NkqSLkxJifN3Nj9gcmU/VJPVIn
VytXM1Hdh8kM1lVVdQ/xnx7w9RhOdw8KUA1e4cvOVQ0OCfJY5c4MVTWygxVtOswizb7+JOSQmaQu
qf01TeKJyl9WGB4e/rMVeoaMWhPzhwaE1Ga2Y5Cdd7ZUnAYg/hS2mFn04nZsdA89ghluvWOuyAA2
wTfqrtvW/E/eeVmPFae+X3hr17BNzTLuspP7u1kDOyWDFr9/0/eA70YSl8FEYamW2uMmc7kUXBy5
LdJfcTWdmh/46qGZgKJmknRIx/ITJb4Ccuk9zzW470YFBqXx2F6aZjnvsJpy4rO8JmeF06dndi49
Fsd7SlPCOt5k7khVet5izkMZ91dXO0bvO2DV1F+UlWn48LKTnMG9aI25VoPNDWv3vDjRmOUuZFdS
lNl7q6Y5N69w+6U1SuuVay/e+ehPaavRLuprcRIVHlf79lLMfn4usftbZZ+W5lkadJWOV1hN1Cmf
3LviYspMqDZ7oNokfFWbeZHdSG1ov09t7H0DPEOZrgHBo9VmBqnDmEEyNDXVEN4wUFKNZCfJ2P3/
krJNIeU/d5SSgUa+wT6eIVLGdiZSJnZWugzSWFtFU1tDS8Vojqn21w9SBCV/sRF2niFhvu6efytQ
Xado7g13IorjjQ32lZ3vtsyW69AJk+S+qWa+aPV1pTv7OLf2PtX/UK0QWfDhybooteY7+kk6Wv3v
butpTPwjjfVB46VPQohYSmelZWdlwoA6D16XHxaqaencV/HAfN2kyvTVd0ckEybMMV15NXqKo0BL
nLVe8/v2waTuWdij1nbXIeFki72xM9/4zu56sLGG0/oUc+1zvidzuwr9+1q9Y7neTby0TrAq9CG3
5Xu3D925Opm6wy/GN7hKui26zWMf16pnYfFwYbWqi9iWNJpRm/MLFo/sDu5cGsMzaZuVpKF0ftrW
TybGJkGaR020inwPeQ5pGB0VPqun84B/c7/Y+kf2NpP19jCKRgvUd0GKCnk1fZbD1E75tz6V4KPF
g6jmRwZjtCfomdWsHSc1Ci0SU05ndR3RMzSqv/Z/0h5maLC76z9Fe76uifkzBeX6iwr/RKB817C4
+Sa2tDebbpxe06KxJjZ6iqLhtIEb0mnEjqLldsumDnXX2ZsfXPdW8Bqv0ND8/sQJWOCjuEmKJgeU
ddTuB2VqLemRtU2xpyTPOpDloT04o0HI6ISuwc5G+rmVsYoDXgcYD52cU4ZsbR84vdi2dY8vt+XG
lpYwSw2634NI4wNKS+Pso03kROXPbzK9IP9INMZ3qtCgcP0rGeVY02VKr4f214cbyAYN7fdI2JLv
Rj+kInnwyVaD6JHSLR93vOz7RC25Mu/qEuaR9wOCk8V1rhaU3zz9urynoajfQfLDzL6Gm9OMT9dk
zVrnJXLlmJQ7z6XZ+p5qopHHKvXrFMysZER3BW4m6/pSxwoUvx/vLutaTL5w/F2TyYvWeOf/KFO/
J/j6ok6khoYWW510YPI3BF9/Ec6/05t7WoEfShrmmK8UabhqZmBX+75Q6JSyWpWAtW1DXLeB+p15
jDTFE6kenZNt4k+dtWiJpr3rXXUm6eLB1mLfYK/VU7yenajoTTh5pefwJ4G9vItlpqo2z77jQBUP
Ox7gEWBuf/d+X3tNTtzFmI5oS1wr/U1tNpeDpM/cK3dqw5xU152Qp5Y7LPWTcB+JiZzZ00qVn68T
zuR0Put0O1FLeVUj0SWpwx0ZNrzHP3BN50uDlB3ZK4nl06xF3FzUsq/HWSnJOPmYJLWrxvPbHBs6
Lpbs3yO/W/DdZf5bCcRrVljojPrta/KbXDhe0koT1SvepS+NN4xflJAeWDpZ2awpKMuo0+9ZtMKW
FZ/1hgUU4R6R+3kL/X8RfvFzcH85AToBsGMqbJR6/lQcRb99QQin8knyYHbYKswNM8IMx4Zmf4nr
fiJQ6fPHM85G2lSN35LnygmIzcEmyb2h9tWzuGkqI5UL7BIkunVSKwoceNs3n9ATb/lw5EBjxdEF
0uJBXL5RKyj5Mqbd/uUBkTKVpjfiB5LHneHcNKPuRdTzYGeTnLTrTVfvb6l9UDPtSuTLxmK11vUn
L7ufn9EiIl0T1q6XWSYemi294XZ5uYD95tdZZz3NMxUVslw2jdO7KOi52qyquShO17rUbVE7+fy5
zqRHG/vbdGKHBKU3e8S4c1Az+jNxI9W1phtOjeB3PIfM29sozG1ltEC+pj33FF0jzfqEs8ZLa+MS
649wXMhQq3wyu95Ov/rQxvZnXlrJr2UysppKw+0X6N4MMT4mO8hgUUugSBXiAJCx639jVDYmVvx+
jjs3to0U+na8FQGDk0JDdy+za8GXg8lNYfCNPq0OS/M9xcsgyNFLJ5Cy379IZcA69jbFnDPWIrX9
OFemTenGmk+K1qnHSY9RX+FjOJD2udNiFLH5mC/mjoVgQejMvBfGxKQweywCC4Ypb5jvCj0fLCJP
IUbul90rMyI4yDvENdgnQuoHeaOyACZV82flYlFMVyhTbMP8qwPbS7O2zc7vItQdqT3aoaYfPx4t
3tXbST6K2vTmxWvK2jetTkNvmHtieAPL2opVKYHU4C7KzUHhjSq18du19jUbxDs7EhGNt0Vv13xS
T8q+VyaVX2H64mRUTndJrUF9V41xR4vh6XfPhUQ3WfRtAybNy9X5kqKLNxcYJTd8tBpxL0o7d4Ux
ZWFouUtFKvVtIz2s2Gx1MZ4Zc6k4VWOGQv2fHny5W/DGgMnriqMcNM/fEIw8Nkdm+67mNVbBYQXF
Shdknq4JveWcm5LX62jNwJX4w4zfp5tKuKULrk2JfBwv21mw20qLWm/pdfjZvrZ9i2TXbSRbJgvl
sfDJJAsX/36MOBgsnA9mcf3bq+iPPdKYAIPzSxXNdSZFRtdE3u9XgQD8zW9LaIxxsKvVZpBqsKNV
01HXXPKXioiPyBEdJ1yTnacvJzeYiL0p6Xz57gfNYleRjh3nzLlUOiobxfffkaZd5HvplSg3Mgdv
NnpV3ZAnFZbx8PSDbVsEZj9UmJa/PzXJdbPIUNO0ozZi69+tTe2yuzD7WZWKc8pV4zSPQAcX+Tm8
FxPxGMMemV1rL6itsenx3/D4/QzhN/VJaW6T7DP/eCIokHdzT/HbEUddytznrT2LBrwMDL0tllWc
qb6ToPLYsbIhtdBtpd+sA4JcZ5uVmla179oUsTo4rsg082xZ3EarubpKcXbSageHuy7OYobhtcWH
Q+ycK30uRr1g6PtkTokZKOcofXqjcrwy67p/TUnHymPP4twOngBhZBsx2+7YUtrA2/IZHjQ76QlJ
3qaB/H4BiwVtA8vp2H8BDQEXNw0KZW5kc3RyZWFtDQplbmRvYmoNCjI3OSAwIG9iag0KWyAwWyA1
MDddICAzWyAyMjYgNTc5XSAgMTdbIDU0NCA1MzNdICAyNFsgNjE1XSAgMjhbIDQ4OF0gIDM4WyA0
NTldICA0NFsgNjIzXSAgNDdbIDI1Ml0gIDYyWyA0MjBdICA2OFsgODU1IDY0Nl0gIDg3WyA1MTdd
ICA4OVsgNjczIDU0M10gIDk0WyA0NTldICAxMDBbIDQ4N10gIDEwNFsgNjQyXSAgMTE1WyA1Njcg
ODkwXSAgMTIxWyA1MTldICAyNThbIDQ3OV0gIDI3MVsgNTI1IDQyM10gIDI4MlsgNTI1XSAgMjg2
WyA0OThdICAyOTZbIDMwNV0gIDMzNlsgNDcxXSAgMzQ2WyA1MjVdICAzNDlbIDIzMF0gIDM2MVsg
MjM5XSAgMzY0WyA0NTVdICAzNjdbIDIzMF0gIDM3M1sgNzk5IDUyNV0gIDM4MVsgNTI3XSAgMzkz
WyA1MjVdICAzOTVbIDUyNSAzNDldICA0MDBbIDM5MV0gIDQxMFsgMzM1XSAgNDM3WyA1MjVdICA0
NDhbIDQ1MiA3MTVdICA0NTRbIDQzMyA0NTNdICA0NjBbIDM5NV0gIDg1M1sgMjUwXSAgODU1WyAy
NjggMjUyXSAgODU4WyAyNTAgMjUwXSAgODYyWyA0MTggNDE4XSAgODc2WyAzODZdICA4ODJbIDMw
Nl0gIDg4NFsgNDk4XSAgODkwWyA0OThdICA4OTRbIDMwMyAzMDMgMzA3IDMwN10gIDEwMDRbIDUw
NyA1MDcgNTA3IDUwN10gIDEwMDlbIDUwNyA1MDddICAxMDEyWyA1MDddICAxMDkzWyA0OThdIF0g
DQplbmRvYmoNCjI4MCAwIG9iag0KWyAyMjYgMCAwIDAgMCAwIDAgMCAzMDMgMzAzIDAgMCAyNTAg
MzA2IDI1MiAzODYgNTA3IDUwNyA1MDcgNTA3IDAgNTA3IDUwNyAwIDUwNyAwIDI2OCAwIDAgMCA0
OTggMCAwIDU3OSA1NDQgNTMzIDYxNSA0ODggNDU5IDAgNjIzIDI1MiAwIDAgNDIwIDg1NSA2NDYg
MCA1MTcgNjczIDU0MyA0NTkgNDg3IDY0MiA1NjcgODkwIDUxOSAwIDAgMzA3IDAgMzA3IDAgNDk4
IDAgNDc5IDUyNSA0MjMgNTI1IDQ5OCAzMDUgNDcxIDUyNSAyMzAgMjM5IDQ1NSAyMzAgNzk5IDUy
NSA1MjcgNTI1IDUyNSAzNDkgMzkxIDMzNSA1MjUgNDUyIDcxNSA0MzMgNDUzIDM5NV0gDQplbmRv
YmoNCjI4MSAwIG9iag0KWyAyMjYgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDI1MCAwIDAgMCAwIDAg
MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw
IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNDk4IDAgNTE0IDUxNCA0MTYgNTE0IDQ3
OCAwIDUxNCA1MTQgMjMwIDAgNDU1IDIzMCA3OTEgNTE0IDUxMyA1MTQgMCAzNDMgMzg5IDMzNSA1
MTQgNDQ2IDcxNSAwIDQ0N10gDQplbmRvYmoNCjI4MiAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVj
b2RlL0xlbmd0aCA3OTgyMi9MZW5ndGgxIDE2OTA2MD4+DQpzdHJlYW0NCnic7JwJfFTV9fjPe2/2
fV+TWTLJkGSy74GETFaykoRkYMKakABhDQRQsKDUqmhwB+u+1b24DIPW4FKXYv21VlFrtZtba+2a
Wv25gSb5n/fOTEgiVWz76+/Xzz+XnPnee+7y7j333OVNAGAAwIwfImir6WiYN3dc8jqwO34N4Lyw
tqqm8+pjloMA198AILuptqq5evU1L78HcPU2rJA6r6a2Tp+QeCOw294C4E7Ma2vtOLbr/V8C3F4G
zPmGeR2hKt3LfZ8Bm9YG0HRpa0d23vHfH6kDYH6OT+3u3dizuf7u1vMBUsuwfmfvGds8j5z9wrMA
tXcDiE2rN6/ZeOufqu4FCFwOIDeu6dm6GRLAh8/vw/q6NRt2rvY8df/HAI2PASRe3L+qp++di8Z+
ge0vxfyiflSo79HUYPoAppP7N27bseZByREAtgTAz65fNbhpN+xQAexNwDLvbhjo7dHcJbsJoL8e
wPXyxp4dm+3P6S/DvGGs79nUs3HV0zXlxwAuEgFogpsHtm4b18EF2J8aPn/z4KrNK34wjrYouB1A
zwJvW/FNwz9bs+DjFdqyj8AuAz48+uddP+H5TNI1m08UjD6nMMkSgAU5CgWsJ4ExYI4qbjlRcEKJ
+cBcB5MCdy1fRtsPS0EsKFjQQTZ0o5VG9NQKJwowl2OuTHytOB+bdBG5F+ECFmTAasUsy4oUrOht
YMeDcO841pHzFVs6PB6h57dQH6Q3sX5U3Cw0+rhYz48UW9ec7A1zDP6/D5LXYMH/dh9mwkz4dwdR
IrT/A3XKuU5o/kfa516Glq/7vP+LAcdVdZrlKuJx5tWT8a8buNtg7le1I+mEisnP+0JfnDD/6zxT
lDj+aTzOfn9qu1winTZfFdj7YcvXeeY/E3Dsm0+3LHcF7BIPw2WnzDsA5n9Zp2bCTJgJM2Em/EcG
9np49HTLMuPjV/1P9uUfCdzn48v/7c8shE/+3c+cCTNhJsyEmTATZsJMmAkzYSbMhJkwE2bCTJgJ
M2EmzISZMBNmwkTgYpIg/I0xgKcxxQi/tRfBnZh2gA41CoypIQkyoAVWwCpYC5vhTNgJt4yPC7XU
4Inl9cAaWA+DsTxm/CNsPm38E84ZfyAzf7w39ixLTGXCp3sgPd4jrpG7mmEZLaNjHIyLaWMWM8uY
DcwAs505g9nNXMRczFzOXMc8xDzJPAUS5i9CrfdjbZ4MDLCxv4/HwpcH5uRzT2Gg0Fcb8StCzVcX
4c7CbkyMGePCqJGTxo2pySMH5tl/umf/04H7l7b2H+GRwboVy5ctXbK4Kxzq7FjQ3tY6v6W5qbGh
fl5dbU11VWWwYm552ZzZpSXFRYXZWZkZqf6UZF+S22bS67RqpUIuk0rEIo5lIKPWV9ftifi7IyK/
r74+k0/7elDRM0nRHfGgqm5qmYinWyjmmVoyiCVXTysZpJLBiZKMzlMGZZkZnlqfJ/J8jc8zzCxu
D2P8khpflycyIsRbhLjILyTUmPB6sYan1tZf44kw3Z7aSN0Z/UO13TXY3iGlotpXvUqRmQGHFEqM
KjEWSfVtPsSkzmWECJtaO/sQCzI1/9gIl1Lb0xdpaw/X1ji93i5BB9VCWxFJdUQqtOVZy/cZ9nkO
ZTw5dPGwDlZ2B1R9vr6epeEI14OVhrjaoaG9EX0gkuariaSd9Y4Nh7wqkuGrqY0EfNhY04KJBzAR
cYrO5xn6CLDzvpG/TNX0xDSSFN1HwEf5IU6YCfPjccC+YQ9xfF4v35d9w0FYiYnInvYwpT2w0hmF
YHagK8J28zlPxnPMIT5nTzxnonq3z8tPVW137OeMfltkz0pPZgZaX/hJwR/M90Q4f/fK3n6ePauG
fDU1ZLfOcCRYg5FgT2ystYdysrF8TzcOYi1vhvZwJNu3OWLyVVEBVHj4OVjbERaqxKpFTNUR6O6N
1Ypk19bw/fLUDnXXUAf5tnzt4SOQP/7WoQKP83A+FEAX34+IpRonxV87FO5bHXF3O/vQP1d7wk5v
JNiF5uvyhVd18bPk00XS3sLHeYUnCrVwbNNKxwvzI5emyDxh1sl18bOFCk8dfviqyjBDh9MlJPkZ
rSrzhBknxIvhU2Il+NiUdjDBpVTX81kcX7W63unt8lL4ki45Y30Sp0Rkk9rSoWKiT/Scv9s1Ks13
KM1Tu6pmUgenNCqOdTDW2qn7yfK2iD0Ya8j46ayPZ3EpuHJRx2IzgoqfRZsnAm2esG+Vr8uHPhRs
C/Nj420tzG9Th6+pfXFYmO2Yl3ROSVF+CaUi4MXseIKtRh+sCzjj0yqk5wnpiWT9tOyGeLZnSOZr
6hjiG/fFGgQPriActMTf0LOvxFCAS7MOdzdfXY/Po/PUDfUMj+9ZOXQoGBzaXNvdP5tvw9fQN+Tr
CJc5hb4uCO92nsU/ygBNTFNnVWYG7j1Vh3zMhe2HgsyFHYvDR3QAngs7w1GWYau7q7oOJWNe+IgH
IChoWV7LK/mEh0/wLS3AhEwo7zwSBNgj5IoEhZDuHWZA0MniOgZ6h1nS6eI6FnUi0gUFHR9wkmz9
aGLcbms9ffz07OrqH+ru4hcXWHAq8YeJML65EGF9cw8xrEQVUfhWVUWUvipeX8HrK0gv4fVSdAzG
wqBx+D1pqNuH+xQ6VBicDLkixzfpGR4f7wx7n3eOdHnR1ZaiLA5H5AHc+8UpjVhuHi/dqJ4X2dPb
w/cDQmG+rjSlobcL3TbeIBZpiMixBXmsBSxRJ9Th3REr9eLc4AQK9fdgIrKnK9IV4B8aXtsluLMu
AvW+2Tjt1KbYzz8ou2vI4MsT1iYuBUXKXh5y7Bt0hEnjxCQ+rIuMJFVhz3t9mNXb7UFri6C3A12d
9lKFkzSrcEsU+VcJonDGMoEfFpeiVCsi8ixsEH/4uDKLX5LiFGlXF3VeSO2NFcBn6yJK7JF/kilj
FdA6mNXA9wV/9mJX+aJP8c20D8MC3w7cWfhOCy1JMTuiTmnowc2f6itR4yuJV5bxe4Qy1sZR0kr5
kavQ7lxK5/D4Xb6d3kkhM8PHHw68Y4LzCDo2dA1NV0SWBDIzZNO1akE9NCRTn7oC2UumniAq4ZCc
G2bPirrmuofZnYQdUZcScSbhjKhrNmI7YRsV2Rp1zUEMRl1liC2EzYSBqKscsYmwkSpsIKyPJlYi
1hHWRhOrEP3RxGrEGsJqwipCH6GXKqykCj2EbspbQVgeTahFLCMsJSwhLCZ0EcKERYSFhBChk7CA
0E5oI7QS5kcTahAtlGomNBEaCQ2EesI8Qh2hllATdTYgqqPORkQVoZIQjDqbEBWEuVFnM6KcUEaY
Q5hN6CCUUpslhGJqrIhQSCigNvMJeVQvl5BDyCZkETKpsQyqHqB66ZSXRkglzKKSfkIKVUgm+Khe
EpX0EjwEN8FFSIw65iMSCM6ooxXhINgJNsqzEiykNBNMBCPlGQh6UuoopSVoSKkmqAhKgoIgj9rb
ELKovR0hJUgIYoKIinCUYgkMAQQw44QxwqhQgfmcUp8RThCOEz4lfEL4OGrrQHxE+DBq60T8N+ED
wvuEv1GR9wh/JeUI4S+EPxP+REX+SPgD4feU9y7hd4R3CL+lIr8hvE3KtwhvEt4gvB61LkT8mvCr
qHUR4peEX5Dy54TXSPkq4WeEVwg/pSIvU+olSr1IOEbKFwjPE35CeI7wYyr5I8J/kfJZwg8JzxCO
Ri24LzE/iFoqEE8TnopaliCeJDxB+D7hccJjhEcJj1C9I4RhUj5M+B7hIcKDhMOEKOEQ1YtQXx6g
1P2E+6jIvYSDhO8S7iHcTfXuogp3kvIOwu2E2wjfIdxKuIVwM+GmqHkl4kbCDVFzL+L6qLkPcV3U
vApxbdS8GnEN4WrCtwlXEQ4Q9hOujJp7EFdQm5dTm5dRm5cSLqGmL6YK+whDVPIiKnJh1BxC7KXG
LqDGziecRyW/Ra2cS9W/SdhDOIdwNmE3YRfhG4Szombck5md9IQd1PSZhDPoCdupL9sIW+l5g1R9
C2EzYYCwibCRsIGwnoayjp63ltAfNRch1hBWR03nIlZFTbzv9kVN5yB6oya+3kpS9kRNQUQ3KVeQ
cnnUdDZiWdT0LcTSqOl8xJKoEQ9hZnHU6EJ0EcJRowKxiLAwasRjnglFjXi+M52EDsKCqBGPeaY9
asSDnWkjtEYNfK/nRw11iBZCMymbCI2kbCDUE+ZFDXhuMnVUpJaUNYTqqH4eoiqq5xdlZVQfRgSj
+i5ERVS/GDGXUB7V895aRphDmE0ojeoDiJKoPgNRHNWXIooIhVE9/6ACelA+IS+q5y2YS8iJ6nlD
ZhOyqC+ZhAzqUoC6lE5Ioy6lEmZRJ/yEFEIywUcVkqikl7rkoU646XkuQiKVTCA4qbqDYCfYqKSV
YKEOmgkm6qeRHmQg6KmejqAlaAhqKqKilDKqW4ZQRHXLEfKobgVCRpASJAQxlRRRSY6ULIEhQHAc
OY7lxpCjKJ+jfIZyAnXHseKnGP8E5WOUj1A+1K50/zfKB9pe9/vaPvffUN5D+SvKCOr/gvJnzPsT
pv+I8geU36O8i/rfobyD8d8if4PyNpZ7C9NvoryB8jrKr1F+hfJLzRr3LzT97p+jvIbyKsrPUPcK
8qcoL6O8hOkXkcdQXkB5HuUnKM+h/BjlRyj/pV7vfla9wf1Ddbr7GeRRdYb7B6h7GuNPqTe6g+NP
qte5n1CvdX9f3e9+HHMeU+e6H0V5BOWIaot7WDXofli11f091Tb3QygPohzGdBR5CMtEUB5AuR/l
PpR7UQ6ifBflHuXZ7ruVZ7nvUu5034m8Q7nLfbtyt/s21H8H5VaUW1BuRrkJ5UaUG1CuR7lOmem+
FuUaxV3uqxV3uL+NvArlAMp+lCsV/e4rFOe6L1dc775McaP7UsXN7ktQfzHK+VyK+zyuxP0tpsR9
bmhP6JsH94TOCe0OnX1wd0i5m1Hudu5u2v2N3Qd3/2p30CBR7AqdFfrGwbNCO0NnhnYcPDP0CHsR
rGYvDJaFzji4PSTabtq+bTv34Xbm4HamZjuTs51hYbtuu2c7p9oWGgxtPTgYgsG2wT2DkUHRnMjg
W4MsDDKK4fEnDw86XXXI4K5Bta5uS2ggtPngQGjT6o2hddjBtSVrQv0H14RWl/SFVh3sC/WWrAz1
lHSHVpQsCy0/uCy0tGRxaMnBxaGuknBoEZZfWNIZCh3sDHWUtIcWHGwPtZbMD81HfUtJU6j5YFOo
saQ+1HCwPjSvpC5Ui4OHBF2CJ4HT8R2Yn4A9wXffqhxn0PmW829OETgjziednEHrcDvYNK2dqW61
MwP2c+yX2Tmt7ZiNDdrSMuq01mPWN63vWUXGoDUtqw4sOovHwpn5sVlaOusEVtQQcwuFsbZYfP46
rZnRmt1mttZtZkD/lv5ves78hO6YjtVqGa12XMsGtVhcq3FrWP5jXMMFNbnFdVq1W83yH+NqzhJU
o4ZvcZaqrbNOq3Qr2VCFslXJBpUV1XVBZWZOHXCMh2GA0SE4Gd8Lxuyuw3V92MKIGTzPD3V2BAJN
w9LxBU0RWduSCHNhJKWD/wy2L45ILsS37sVLwocY5tKuQwxb3Rkx8d8WCenzL7kEqhKbIokd4cgt
iV1NkT0YCfKRcYxA4iELVHUFlm/dvjUQ2LYcP5Zv3RYQfjDFbOdTAV7J/2zdhmn+z3YhDYEvDVQM
sWIrhm1x5bYvr/UfG5j/7Q78Hw+2FcK/wJLeBDC2f8pvtNpgHWyFPfjnArgE9sMT8CtYCd/C2LVw
C9wJ90AEnoIfwWv/ot+gCWFsp3gjqLiHQQJGgPET4yNjd6IMizWTNPsxZRR5TmrGdeN/nab769j+
cd3YsMQACqGumn0Ztf/NjI6fYCv49HgRn2b3Ylwr1HhfetPYA2N3TelOIzRDJ4RgISyCLmiF+Sht
0A4tsEz47V0v9MEqWA1roB/Wor3WwwbYCJtQVsMAbIYtMIg23Abb4QyMb4tpKL0DdsJZsDvGb8Au
jO/Ez7OE2NlwDlr+mxM8d4InNd+C81HOw88LYC9cCBch+c+puqmpIdgHF+N8XgqXTcQvO6WWj18O
V6FcAVfirB/A+DU499fB9XCDoN0P34arhdTN8B3M//aUsnzeyfI3wk1Y6ha4FUveht5z17SyfMmb
4TF4HH3qh/B99LYnMPY0HMH40/AmvAXvwO/hD/BHJsAUMfPgA/gQjqH1V6PVeZtvFj7X4ueaCYuf
ibaNW/ZstNhUO5wRyyN7nivYKZ53Jpbci7Nx7qQ6Q8I8xdviS8fbmmwvfkz8iE7qaIT7JzQnxz21
FpWbbLOpFrxO0EzNnW7ZyfFb/27ObXAHyu34yc/D9FQ8djeucF6+CwfhXozR58l0PHYf3A8P4F5w
CA7DQ/A9eBiGJ9IPYupkflTQxMucWv8IPCp4wRPwpDD/P4Cjgu4JjB2J5T4Ry3lEiD8Nz+Iu9Bz8
BJ6HZ9B3nhXkOXgB/eMleBl3rV/DGzEPelXwIB8TgBfhJZEffi7WMGLuSXianQ87MP0aey3OBIjf
AQ3/fx+NbeV+ibsHB1KYI+wCrQ9lWjItsrJKBTMCDSBl+oAFD3MxyIBh+oIGEZtSLOHanWr95nam
vUbKdkLF62+8vuyN159HPs9kvz7y6ohu9NURQ2lpdnZuDqP36gUxaVipVCLxJWWxxcVFRfn5eXPZ
woIs1pekQfEXFsxli+dy+XkuVihKJQUtFua13C8/X8K1jkrYb7hrN81PZt1OjUklZjxit1VW3ppl
1HoLU1OD2W6pQsKKZRJZ2uyapJrlsx1jD3FSpVThsVgcGrFIqpLJPXajXSMaqxNrTnwg1nxWLdrw
2QEut2DNgiLxNQoZK5JIHnNaU+bUee0Bj1Fr1Kk0YqPFIJEaDUp/eePoPpnVYZUqFFKVTiG32Swy
uUKi0o2WAAMLxk9IjqI9Z8PhR9jd7NkQDvD3olA4WJXhNamzsoyZoDCbPJkKhc5zWSaTk8loMxkl
l5k5O1uFV8OC9qxMtREUFk+mymzKyPbO1jj97c6QLiQOpQZsFRgM1lJ9fgWTnR84yuTlldqzVyxf
tmyZPlBqy9ajzfVMvj4ff/AjF++qiafdYm5OV4qGE6bH6GN48/tncT4ursKp4WfBasxnYlGp+Kes
wuS12zwGMfs2O9oqS09NS2Jewzip9WJ2RGSwOTV9nkCiTvSomK3SulIyEwa1Nr1YZJeqpGIxfojW
fHaVRq1V4SxcM6G7y+QyytWO1ITPu7i7nLOcGrkx0cz/XaL28RHube7H4Ed/veQR9hx2z4SND8sT
Za5h5oEH/bP8c2TDzP0Pg9bPGDl/7jDrClqNIJ8zK9Ev4bwN6ccdjUWfBjUtXLNgA0fLSMUIbwcm
e+QVtOfrI2g/3Yi+tJS3oeU0KvLWizs3mQxdV5SfZ7HG3Fcq9fvR1UVmk4vlXb+YyxAlp5scOmxW
XbNscE7b2rlWc3bTuou7us7JM4r8qSanTsT8NHtjTdGi6lw3Xt+LAsUD3Y0Gu14jkirl3/U0B9NL
lm4rL7n0wMUD1fUVS3QaTqaS/qW2Nr9z/eCmDF9tqa98w5Vh3mrlaLUXxVsgE6rghqlWCxqU+kSX
2+MrLilNKE0wlOoNwNsrIUuvKC1JEknzj89qTDDolSKNtU7TXPZpUNrCj50fOj/yihHBbq+MZPNO
p9u9V3OUgoERrOc4/VbQiLj2RbznCevfX8zQjiBFN5QKUZE0tmVIpRYL2lHEvWjJbVy/b9HiPXkG
dlZqeoKIUbByM/qfyyBi2sQarVaiq122qaRsYVmKSXafIrE4q2hzd5Pem72hpqCzJs+rZ88ru2L/
vvWVNcGwXqPTiktkKplIhB9jmxwlxbkGX1NFuqewpn5ehrOuLG3uxv2L7qytymlbs2UQV3wzWnYh
9yMohL3TvDEhAfS8IRNTCz5JdYsZseLj7EbPx6lg19lZBWc3nQimxGww+gqg1wVGKjCCQC88WprN
Gy/h61YlE7K8A5K38UZCh7OYTRoJbbMi3ozcQqnGqNK4cptmB3sbclzqxV2VyyrTdTK5SK62lbUu
zb31ZnPe/MFv96Q2VhYmSrn5Br/XkpjsKgxt2LTGv2adJ82j1ai8Ppc9OdF4+3fKr9g/tD6otngd
htgqFZXiPTcDKqbbJajwZlYkYYY8qZg3j8OclMHNqkOlXAYSTc7xhMbZ01cY7yC4t5Fd8vMEH+PN
Yz/tql9Yn6KYJXBHi/kYE1+gFlqfmVxyutmhE7MeYX3OWTQnxSy15DSt2xcONM8tMK9mFCaP3ebG
3W/sVVymhaGaXI+uqmHyIr3b21SR5i6obWh0z778in3rq4zeLDszJlXz25xaOrqytj53wbotm7J6
1pStu3IRWq4F/elG3N+yoGy65b6XnlcsEYF8mNUE5T69ysWZTL7sYVYdNINP8v3i4nSXXq/Keym9
UfVm0DWxvHAb40+G7BF+kSKtpbizWYW1aTyNWnGP8kkkU7yJlU7e59B+BX5hXfIluBuDF75yYJ1U
3DsQXN2UI5fLRTK1TFXe2ZfXdUFXhr1o4Zk3rOzc3pR0T1tjZV9LsX712ktCPvZ3eK6ne+c6+9YZ
LUa1SpGQ6JCrrEZVaseuzsqrrrxg9dz0qvbi/IrM5lUljswytFbV2H7hNCjDN5YHp/mZOr+grKy8
vS0xoTyhfB7van5lGiQUlEGCSFzc4G4vzxclB4/nNKbKPzIYrM2fJrdY3w6KWycsgKOHkUDMhfg9
Lj/76MjR2A6H56yBjoekf7hFNK2YNyKeV/GFSWdDUdHpHiKJunmbru7uuChNq2TEUqVOrkou66os
WlSZptAnKXV1SzeVNvVXJJDbfuFgWVid59bivckv+GxW247WVK9VYdRKLBabUWl2WCwZNdlLdnhT
mipm5S06s3Y27pMbqyYfNXkdG7YMZAbq813lG/Yvwv2wYvwEF8GTphJ2T5sPX5Y9uVIJCp/Spqws
EImNx4OljT67ApKzJK60OlezmJatcByguQSTZx/N0+c/n58nnCSnXW/yXaaoKH7LlMYvM184VViz
SSLlclmFmV/QejEzgJcQZ8BdOLCiSd/GX2dsdlSz8aPFrZ84WmqWDswJLi51yKR2mZI/NpQyNsNR
aUvM8ZnmbjwQGtsSV086V9Y6igpzhHMlpXJxQXKNj98z0XLMe+JsfLtPg3VTbfdgmtvkwlN5ZVCp
cLtcJneaKNmuHWbmfU8cTG6wx7a7N1pG9ILRXn1lhD+L0WYPf0VZfnHHjBK7e0+67wmb4h/F+oR0
V6LfwIolBifGUozs2CcnTXKYES57vNFEP0nwWxUKqz8hIcUul9tTPsuNj507T0pjl/J/33su+shh
9JGCL5wN6SKj2ACciAukG01p+McdNARc6UZ1ToPJZRAH3GlSe3KdvVk9acqFg+HoUQd6Ca1NXJp5
+vyYBYLmr6wt7HASKcNYhH2NH/8s5gu+Eotwh/X2sZ2MWiGTmX2OBI9JIRp7qxc9x2tDI0hYRnnS
RW5jbpWZHD6bzWuUcbeoHNaxQ2NzDHapXC0T4/qRMx+MqQULoXFOesfnLzM75Woph28ttJ6Y99FW
Zpg3zVY6MyiDCnydUIrEurrYIhDm3xFbMMovZuJYi6eN7N1T+7f9i34L1B/x73HHXQJ3TetPaU1m
Zlap1ZLknZ+0BJbgw/HurShJUnY06lOPBxsaS7JwcwFLpjJpyfyaUk3+3Ib85oSJ1RtbvqNH8d0G
lz1eavQ4jYbSo4gf8hPKj8j7dduavhP4p2wEp1LFrBLbGKwn9wfxGmZilnF/yC3PW9/dyO8OglIn
YQak4ryy/HWkjJv0IQbfXExmp1bEJGlrl24sLVtY7OBMdUs3lFQvLrFN2TYSCxzB5vL1+xeObTqp
dM22lzdMVXLno8Nw/A58bxK+BHhLW7N9zRXp/qpwga8mGeK7MM7SbPjGtFny5zocTr9Iw4GWMXFa
TYr5eLCoMcWpETm0uX6ZJ9DgaZZP3VD51YXTgVMwMQ+Wr64VW1Wnb2ouIpNuQf+Lb8FScUH59A14
ijVrlm8p523IvoqjHn3hpMncsy3lTV9qsrTqMO648/Gu9RJayQrZEJ5qJ/4/uXYH5WDT2VgjZ0vm
rw9KVeJHxsa03056dRmJvTCO8EZRfDF74o1m8j0pfjUXznAR91JCafjMq5d1XxROd85eJMS60u83
57aWlK1sKU0xWHLnl5T38DF2a+N1l529vDgrvKe98bpLz1lenB3eszivrdgVaFg5sL0kr63EFWhc
uXkbsOOfjh3gXsSxpeMN/MrpNyNvYZFKXagutKmtNnrZC1hVRYVekTTnuL/RqrZ5RAZng6G19HRe
9nC7FU7n029gklVmTfKPyc5witc84QqT2Ti3wBJi5XjmWPHmzYyywiUd3UFTjZf05jXBhPvwQjNr
4hWvEF+evVr2vNlXHNi3odLgCTjG2uL7mehPeI9BvzjobapML1h0ZmugviChDO8xd9TV5nWuG9xM
K4n9AO2YDxumv8ek6vWJhgRITFANM7agLpjZaEjQpybOkliTGqwTOy6toOyjEyfSEVB9RfFJ9vnS
vcmCPcNxqGUyo9VlSupaOE/fOvVkjq0Vr7WisX2W3ueySiTcDSKry+M0SBXSOf2XdowNfHGJ3J7W
XJoklsolEn4vkY+PsH9GC9TBfVMt8BhuIaMwBwrwfSRgmYN/wKctCDprj6V6xDnioJgTK44FGz3H
UyFdl86quPTsN4LOU7+36ukU578z1I3ohOWU/M+0NfU9GPdvl2jibJ962cbbIf8uyMYs+meJUitX
eXOqszJqsmyFbctaC4vXXLk4u6M6Ry2TshLhe7+k4gXlxa0F9oLWpa2FBSvOb/fPK8tQKrkNCq/H
YrSZ7IFiV2phetqcjoq6nYtyNRanSqZXySw2i0HpdDudmWXe9MJAemlHsGpLR5bKYFEqeEtvGX+P
fUZ0H9TC0DRfSyvKCBQHqmTySnllsTwQyCm2Flshp6q+uLJMlvFbecBbVK/9NOidWGtogpG850tL
8TB9njeqoTS2YI8e1e2ll2fjadSOe6KP+/tvf/z3hfT9bX5+cdxDsRT7DCtRKDXyd1eJJIEcZ2qi
RSaTi9G9ZJ70bGvJghInKxZzq3YrVRKVUX12gFGahNNVzATe1Sq4/XKzxaJXjCnMBfr8bLlCrtSq
3S6bVKpRSmz5LUWqRI9Hw5xQGzUpHsurUpVcJJKrpK9a0I6bcV//DfcYvhVun2bHJKUNcsvycn3J
dhsobcm5dl9Znhzf3VwNGZ8GdS3ik98c0FUKb1JH+VcQvfCqZz2NOpNuHBMvcUUTS1ewY+zlbUKX
wSgMiWaTUytmvbraZQOlNctK7XLpQPxWKWY2SSRK4X2ku8nQyijjajtaU7g93pPUFExNqewq9Nb6
2IL4Oh592VGS6MpNNpVvuCrMXBpXo4V24f3gNrRQLiycfu55mb1RgyX1UdYNAB7ms6AyaMlsSFI7
G2LXZgPvVDjaV0Z0rwsLVT49O3b0495KBpjF+f0TS8xoRieJ+Ql3m0SUsmzL3japwe6xuP1mOXM+
w8gMbofDo5cwG8RzVnY2zeKUeNO2ufRS7g68z2588/Wf9SpVUlYk0yi4kFIvVWtwXFK1fNShknTd
FT16hnB7FstxnJfhbfVpHGcTnDd9nJnMdx90JRkNOY8yn+M9aQ5z/oOG2YakqkdZLQ48gxkNGoJJ
8xoKG7LKjJx9VsPU14a4CXCl8PuVvjRmC93frzHdKoUcE49MNU/sYj7FUuKnxZx/ycaz66VmZ5LZ
4TPLq8deEuscsxISUu2qFWg0o9fhwKspUydiQiKFwWXF81HGNIqzli5s8bAqc5IDL6li7g6lVTbF
hOyB0QHc8kSCORfJ9RKVVk7mtMnl7B9kat64KtmoUyarf+CpH/fEjYvWNeMdg/eiHOif9t2nz2RM
e5TVoSGTmNHDNhv/pZUvqAkasxp8MlNig6lJ0xozTWnMnY6WZo9MfOWuOmW5kxYULOf347qaYrv8
mL0s3G0isXd+/77usVGJwZFid/oMrPLDq1hWinuM062XMtvZuX2d89ys0pzszHRxtyutiiXPvPan
b47djC9mIrHKpGFKuQGVSaoUzKFRjCYtevDI4z38QanCu+Oj4x+zu8TL8b0sG+YETWalxad0+iyp
ooBLaQaFSCcODDMLHnS16OpS48YJVFSMvqC3ltJberZwHZj+ws2d+pdf9/CHudni0IrYezmVLdnh
TDKKuDfxsFJqMnwOn1EqVugUunRvYrIRBxe/4XCPqA1KsVhlUH22UTNrlk+h1ci0Nq3an5qi1Cnl
Ohsw41eNvcEUwVt4C046pAL+Hz9opMbHmXawQWq847oPn8eb7g9zc1LQ/vTdPG/8+JcGRfnZh9Xp
eFWVcdLHrGKdPSXBju+895ZuLXlB+//YOxP4qKq77587M5ktC0FAYmLxQtiFEBEwINIQwyrQlApF
3DKTBRImi8mE7RFNY8SAvDZSV6SCtLW4Uxce69agLIoYASEEEwwKRpgComJAH8p9v+fcSTKBtA/t
53nfvp/PG/79nXvuWf7/89/OuXfqTCLDnNHhWpf5cXq0PSyyCxJvO/cb6zwjBtvFbBThlzQ4fxZi
Ih6WPsIs8tTpGfy8uicOnWfh6Ihyn70u0k3YhnNAvBsZce57e5dul3YJ7xLFtXvX8C7yc5TT1mzr
9LAS0UX0E6PHhouu2l2ih7iCtO5H0N4l3KKLpVOyK7xf2GW9J0RPCPXOgc3akJrjB45H/01mcxvX
XOo479ayX3N1jrnkku6RNm2iFt69V/fEeNu5/porOpbGiJBG69Jmd2gfy1p09Lmrzm8hU9b/v0Ha
TR30b6NTf48sT1kHtUMfmGRL/z9PYQPaoa2S7Nf+Q9olyXFZCB1z3t2GjrdPrgcluS8J0rYLKXze
v0Rn26OIwsgrQui3HdRB/79TlKVduvZ/jHL/ZdraQR3UQR3UQR3UQR3UQR3UQR3UQR3UQR3UQR3U
QR3UQR3UQf/3Sf26gMb/vqCcppUKu7hR66RVGk2Uq4zTlFWqvkmV2yijNYvxHWW0cUL+1req91Bl
miqXGF9rPZj7PWUVLT2Ye4pyG/XZtB+jrDLqKTep+jajTvPB8x3KaGMTZayq9zDeokxT9SXGG5SV
xnHKVazBp71mfKKVKG4liluJ4laiuM1X7fNV+3zVPl+1L6HlNKXUZQktp7Ql1hm0L1P6LlP6LlP6
LlNjlil9V2hVogvlJuGm3CbCtRXMypa/Zm4cpawyApRSx0olZRW6HKaMpncVush6D8asQhdZX2J8
RbkKK1VRP01ZqcpV8K9CVoT65XpZbpMlssq0TfRaKKuElXKTKrfJkt4KbZuau031blO92+i1aNvo
XWadgaydys+DLb1E8+/NZ6rSqrwfpe5k3SIirANF8188GGO1Bes2cbk1NlgPEzHWlGDdTvvsYN0h
frTOD9adYqD1WLDuErqtMFh3W9a2yAoXM22VwXqEGGhrDNYjLY+FRQfrUcLnWN/yVwuGOrsG65pw
OMcH6xZhdz3T/PcJxBWuR4J1m4hyPRWsh4kI12vBup32TcG6QyxxfRysO0U3tztYd4lo95Rg3a2l
tcgKF1e6bwnWIxh/X7AeqU1xrw7Wo8SI8CPyL0TYXEE7m3XTzmbdtLNZN+1s1k07m3XTzmbdtLNZ
N+1s1k07m3XTzmbdtLNZN+1s1k07m3XTzmbdtPMzQhdDRSKURG2qyBEZokgUiGKQLfy0XU+tSBSq
0kNLDrV8kUDPWOGDdDGdNvkrJH5mybssrlmMnk+ZycjrmedjjJe2HEbkqHEekAevTDU2n7ti2vJV
nzk/hxXowBP8dY1F3C2g5keWHFMCRz/tWdzJNZcwO5P+fPU7HLpap65+kSMLDqZMOUJHxwIlM0v9
RorUZZLSNZsWj/oFjyKlha6uHqWllGvqkUHPIMU5T7X4FEcPNjLbm6XkwcenLFYYXGU+LXlKqslT
6ukPWYGUWKh0Me3dbG1z7VJSARbQ1S++zFFWyFG/PyJ/Dcav7qTG/hZ/mDYzpehq7flBvQqUbb1q
ZOuKQzWSVluo5plaz+M+QcVDqDf7KW55isMiZYeSoOdD7S09ZuqfpdYv9Tf9UqSiQV5NidLXOjwK
W7Qx1zgnOKaYu8VB7n60MD00v8VLHhUjHlrz2ujVHM0ZrMSj5GcE5Se0E/WjLtDT9E+z/0e1ZM1w
MTMYRTnBeBsOxxH0tp0/uM389jMiKxjbpqaeoG5zVK+51qygNeX6M1VUS13mKX82z2m/N/ufyu7W
SDL9NoO7HLUGKf8XShN/Gx8PCa6gIESDjGBO+pWWWSrOp9CSIfor/w9gTKbiP0GtypzrV79VNAqO
Q/CkpASV/21XnqC45zHGT9zJ9c9RGhTCYRGt0rvZSheZVW25NrfLncX0wLwWfjepNZsRvUhFYrFa
oV/lXLHaI8zZutJB5muWirYcJcO0kFfNbbbeOOw3hd3SnFsU0mPmeqaySWv+LlCyMlR+tyfXvJdj
M4iiEmXDzJZ8yFT9cscxNWjOgUKlaX4wC0xeWaqUWX2+3rLf3D36M2uAis489MpqyecLV5V/AeeL
t1Er9+YdXA/uwWb0ZLTZCy/UvTVe267r2hALSE1MXcwToTnqi1pOl0y1v+arfdbzdzU17expY9Os
YPSfnwPSqjLyStTMTLVXSW2yWvjIkT613/0jD/1P5UVrTgwJ/n6YJ3hKJShfFYqFz+hDExOT9Kk5
GUUFxQXZfv36gqLCgiKPP6cgP0Ef6/Pp03PmzPUX69OzirOK5mdlJlzv8eV4i3L0nGLdo+cVZGYV
5evFnvxinf6cbD3bk5fjW6QvyPHP1YtLvH5fll5UUJKfmZM/p1gvYKg/K4+Z+Zl6RkFRflZRcYI+
ya9nZ3n8JUVZxXpRlsen5/iRkVE8SC/O87CCDE8hdTklr8TnzymEZX5JXlYRI4uz/IpBsV5YVMC6
5bLh7vMVLNDnsnA9J6/Qk+HXc/J1v9SDlTFF9+XkI6sgW/fmzFGMTUH+rIV+JufMy0rQg2r2K9bz
PPmL9IwSlDfX7Z+L/KwFepEHXYpyUJuJnjy9pFCKgeMcWopzFjPcX4BC86VKHn2BpyjPlCXNnDHX
U8TCsooSWkw/qlkm+kj9R0nXDJ+JiVBKH54wYmiwf7DZH+KILKyNUA/S5uTIVWWxzCJPZlaep2ie
XiB7Qm6z23e3MhK6zcjP8TP/F36P39R4CAwKlIAMPOkvyskqTphSktHfUzxAz8zSJxQV0Ov3F44a
MmTBggUJec3MEzIK8ob4FxUWzCnyFM5dNCTDn12Q7y8ODpX1bA8KzJPjbioowdCL9JLiLBaBSrJb
9+DXrKK8HL9ckHeRWt64GVPG0lukbvB6Zonp3wVzczLmhszlmpOf4SvJlLYo0DNzigt9CJAeKCzK
YUAGo7Ly/Ql6s+yCfMKjf84APSvPKye1sspvHtzuitRwGeCYvxjzZJhR2CJd2TXI61q1gP45SCER
pOmLZLpkFizI9xV4QoWyZo+5Ugzf4oGCEn9hiR+zz8/JyJJj5mb5Cs9T6GJ8oTwxJDMr20NKJXiK
CxfK9zH5d8GMGLG0vV9M5P3GyjuIW3QRDsMQnYJ/UU5+ObE/11IhWt7j2v+Xan00IkJjjLb+YsdH
Rsrxlovm36mTGn/R/KOj5XjrRfPv3FmNv2j+XbowPlX9RT0n735yvHzjjpV/DU+ziG5aJ6Fr0WKw
FiuStB5inJYm0rTZ4lbtVpGr+cQCrUCUayXiQW2+WKctES9oy8Tr2gqxRasUO7VVok57TXylVYlv
tU3ib9o2Lco6WYuzztD6WxdridZHtRFIGdNWvpbSjvwE5I9E/gTkT0f+7cjPQ/5i5Fcg/xHk/xH5
LyP/beRvR/5e5B9E/nHkn9E2afIzia7I74n8Ici/BvnXIWVcW/mW+0Lkd0d+PPKHIn8M8qci/ybk
z0X+AuTfi/yHkP875G9E/rvIr0b+AeQfRf732mvIrZKfXmlxyE9A/nXIn4L8Gci/GSmZbeVb/xoi
/zLk90H+cOSPRf7PkX8r8n3IvxP59yP/CeQ/h/x3kL8d+TXI/xL53yD/b8gPR3535McjfwTyxyF/
BvJvQ34mUvLayg+bFSI/Dvn9kT8S+eOR/0vkZyLfj/x7kf8w8p9G/n8ifwfy9yO/EflNWiV6r9Ki
kX8F8gchfyTypyH/NuQXIH8h8u9GSkVb+faDIfJ/gvwrkX8d8m9Afi7yFyJ/GfKfQP4LyP8L8nch
/wjy5SdmNm2F1g358ci/Cvljkf8z5N+KfD/yH0T+75D/AvJfRco7cp9wujSn21PqKZ0OPSweFssg
e5hmtydNrKisLHSGaU57cnLhRO4OyvawxImlpZXpqt3pNAep8YkTT5aWyvHNU6MPtk6urKx0WjSn
NVkkJyeXlpbKnrDk5Ilp6WvXBnuSzR67S7O7bxaZpamly1oXY7IIyqmoUPJVK6tijk2z2wrN6WFM
SErWo6MPOmyaw5Z8Ujanq5kTJRO12DDWt7ZKyXJVlD6ufshyh6gQTjuzUydOTEvTk0udFovTZq5K
lFotQmONpZrdMOxnrTaLMywtba3TrTnD06s8yT9Pnp68svSh0grIbtfsjtGp5RWPzXXZNZcDDrMy
uT0ZYj7VYbPZzGGh9mud7DwZMr2ioqKNAV1hmgvTKgtWVrgsmsu0YPsmlExNJqqalFpeXmGKMlf2
90zotGnSBEEbyvGpqanNC8YNaenJQRtWEDwzeIxNVTa0SxsmYkOXxeIK2jDUiBxT9nMY0SWN6IrQ
XJF6YmJaWnra2kn6JH2yXp5cnuywaw7naLnSx+a67ZrbqevSEHK5jjDNYZeGxJJuB10Wiy04Us6S
+p0pLV1IVwsHZ0VhKBMsYdpMBBcnOx10pmLQysoKt1VzW7kN9jrcmiPiptLs5FSoQnlZLS/IStWl
UbGq2yEczkFDe/VKSV3IVLnUsFnpJhe7cNiTUpMTWYzLprnCdP2k4p+uGKSatlUawKkCe0i54eXJ
K5JXEFumeSV/R0pKamr/RNZXKhcKH7VSUVpqsxoWm2zXnMY5h2GzWdx2TLzWHam5o/SYxP5p/dPS
0ionVk6KXh69VC/XQ60cbtfCnXqImU1bsvKKwnAHfZa2dna22BmVe/RiUVOG2RgaygbryCWypmZL
y26H3mrqcKsWbtNDbB2uOSJvqcrQUyAZCMFQ+PfbWq602dYXGNspjR2ujB0eqYV3ksZOlMZOk8bG
3Bi7XHc6NKdrTEpKWVn5Cn+EQ4twSX63eFNSUso3v05GOjF4srJ4hJNeTdMszcPlXOfolJSzpaXl
C8OdIYww+nm8ysuDZhXNZpUDlFdSUmelp1dWlEdYtYgWu6s9OVxzthi+2fRqwc081c1oJZQVtPZs
fj24pdul9RUvh3A6Rqdgflv5QneY5rbr+hlTTqHikiL/NSsl+bHnpssVREgz4YTkGzmQMkSKCHcK
p3Ps2JRevfv3l1tKhNUSYW9Zdxs3uKQbSm1hlgiH3OojOmkR0Uk9knqMHuEb7ZP/dvh25K3Y8ti2
mG0xLqfmcv80I+O9997bWj0/0qlFuhMTE9PzizP4t7Wx3uXQXM7LvelV/Nu8MNJFv1YqySp+yst9
hnhP0VZRLeYLOdh1eXb21rNycEQb1vYVC8/nvnVrpE2LtCUmCpGu/iFDjnHJMRnZvoULfTt2NI9J
TG8Z44rUXJ3yC4sfy4gxaWuiJKVKC2t118OUvtVcS4tSkoc8U3yFzRwdrH20N70w6fKIFQtlatoT
E88G5RUqVhkm3+r5yiJbt+7Y8f6swsJ0uZaorTFbY6oTqxPr0m9OL666o8pTGuESLpd8npAm6guN
FklQokgXVSIyTIu0x8TEJJpaiaqqMJthCZM3VZr73DmXURXmsEQ6s7N37KgIPsW7xTrLLGHNWFTk
E13nFGXNE6N8Hn++mEKP9ovpKbqI4c3IUE/vdhEpugbvNOEQUaKbajdbLDxpdRKXQtZJZKXoPf1n
U3WReOP0G3QxJjhGvkdFi+7qTv4V584t3G0iXFwiLgvehYkI3rZiRVxGYXGh+L0qn1XlBlVuVOVb
qnx3XlZRvnhfldWq3KPKT1V5UJWNqjwmPwUQ38pSs6syVpUJqkxR5UxV5ubNy5un3aXKpap8QJWP
qPJJVT6tyhdb3ob+u1K7yNKJJa3YgB2Wuvx/uf59bRb8EPlPX6NED5EgpqtPncvESrFOvCzeFbvF
F7yvWYRLaeoMantMyP+vz8q8ruqv0PPMrI0yr4tTzeuvp4XMId72rGt7/52l7f2pQW3vT8e0vf9h
bZt7LcLd9j7q6bb30X3b3semCJcl5D7OHtJvF9rgG9veD13H1U1M9xdp6BPFnDJMlWhJE3dbfm/Z
J9Zaf2v9rdhj89ueEnvDDthXalb34+4/an92fxQ+QXs/YmbE/ZbrI56KOGxZFPls5AbL25FbIndb
NkdNjJpm2d3puk7XWfYLrWi91M1eFHGiPYp0Qr0iB4XQ0CA526HRkYtbqBRaCa2GdkuKEudTpDPK
HTWoU2OQToZQk6ToW9ql7Oi3mqmzvXNMCy0PUlU7tBuq7TomhCaapHrOo64zu/paqKhbObRc0fr2
qPPubhu7vd99oKJZ7VJ298oWerb7hhb6NEgHocbux0KoSbWdRzE6oxpj9Jj5MfMvOyJJ1mLmx9pj
Y2Knx66I3Rq7U5LZ2kqxje2RktkYe9KkOHcrSc5x0Yq/LvGTyT0HtVBKz1ktlB+kUuiRnqW9JkLT
e73eq5r6671ej5/Se3qfdEWL+xyEmvo+D73cb26/u8DcfuX9Jw/QJfWbO2DMAB9UNmDFgJUDo6G+
V66Anrxy/ZUvBmnn4JVDkob8mNj1qo1Q1dBVQ+uH/nj1nUFaenXl1U8OOwmdG542Yt01myUlzUx6
SNHukREjlweJO+6Xj6xWd9Uja6HlI89dW3HtxtH9kx9JfmTsoJSXk2aao7lWm6NSX5fjUreOWz3u
2XGvj+81fq2i7eMPK/p2gphw6QR9/LfUpkGZE85NjJiYO8kGDZx0inHbJ3sneydMoyyUNWj+5NIb
7Df0VjRwStcpsVDSlDHgIWjVlLNTL52qT9WnrJo6cGrl1Era6ZmWDe6ceumUpGlNPxM/906vvTH3
Jv2mgTcN81R7h3nf8NY3XzOioMfmjpmblvN0zoacE7nRubG5vXOH5iblTs715c7PLc19IHd17su5
b+Vuz62dN3/eY/NenHfGZ/fF+BJ8Sb7Zvrm+5b7nfdW+k3n2PD1vVF5y3rS8W/IW563OeyNvT95n
eUfyfsy35ffNT8yfnv9Q/taC6IKB7bUVpBbcVVBZ8G5BfWHfwvTCdYXH7ujbXtsds+74sf19KLgT
hVDbnaRIbyW5RxTNbCVzdzg/l9rmghnP7e4czbtHCLXN/6IVrSSzvWhVK5l5LvfBTk2XHek+kL20
18hqdj61j6ore2b0W5Gr0cLdqTHS2bzvdY6J7NV5ec98OTfiRJRo3f+C1lis5ojgqMVR7mYryVa5
n8qxUl7n5bK92VKdY7gbxG7sjnJH9pLcmLOyUyPXXopad/ih5+3sq1v38pDd3C3XfcEO3nTBDp5t
7tvs2PbmvVrxkVqv7rw8SsjdSO5u+GMntYNy/zH3GHO3YmeTnspv8R67lrxr9SEWljyOxblV+8me
s0ye7Kche6i5R7bsgu3ugebuquTPCu56Kc37Ha2Des6K3Ukd/ldtnOzttt48T9SVs6N7JSfG+m4b
W06E4E7fuarb+tZTwYwsecao0evlCObO6rZR9qgWRsn2zryGNEdb9w30LYc381VdtbaeZ6EnmlyL
Or2az6/WE2xjcHVtz6zs4En1rDqlzLNpIPemTKSO396tvPunrOJg0LKmdVX+dA+xZZzbzBxpM9Oz
PfOlXXvmS527H+w6pru0/k5p/5AcHBTbiFYHZRQ0R4PkaFqbscfkOE6WiSbMs6XXRHUehJA8W8xz
RZ1M/yKp0yyE2hnxelsKnnUtdOEMdcb9U6ROwYunF/8xnW8pSS0n6N8hdaZeNKlz/iLpfOuop4MQ
utB+6qkhhGQcm57+5+hCzv/96i6OTDvLp4Yo9zWbx61O2h3ZSz5vKJopW67ZLJ8x5F3SzHGr5dOH
2Sdp2Llh5+TzitmqTotak+Sc5EfUM418eqkeWa2eTOTTSzUzZvJkEBt8goAmF6rnhlj5ZCHv1VU+
U8gxD5kkR8gxULAltvGG3vIphTxfO7lQPtHIpxlF21XLWvk0o+62Ty6U+0iwD+KZ6Nnxh+WTj3oS
EuoZCFLPPzb1pMRY+dTT+hw0fvvIWqXxbqnrVN3U9JrNwVV1NVc4YZriLZ+rhORl8j0v1y7wWKif
+6Sbd8KuVRl/tk417rfOEJ2ss0SEtcjYZn1HjKAn0jigRYE4o067HFQZu+g9Kizyv2e2zjAOCY3y
tLBQbrLOMt4XncRzxlmx2TjL3A+Z+yFzDzP3sJYuumgeMUnzip9oGaKXlikitXniEmaOYmaq1Wds
FBp8vxQ2xkYwtgtjIxgbofh/yagTzIk06uFbD99P4PuJdpvoyfjejJ/B+F6M7wvv3vDuBbfVrPcz
EU7tGfTrbL3TqLQuMW5Fv5HWQ8Yj1sMi0fqlGGT9Sgy0HjVqrQHeKqW03Uj7XDiRtg9p+5otQM9l
9NhZ7f1w3ify0Xi8iAbyv7O5Vv43MsZukQWyQbHRIPzGMVEC5oMFYCFYxLvsYuMD8R/gTrAE3AXu
ESNFObgXLAX3gQqwDCwH94MV4M9inHgDnOE9+JzQhSF0Tf7CpwZyxM+1rSIObXOsM8W11puFw3o7
8IkK693iCuuvwD3iJ7Y1xge2teApsFuMtH0C9oC9oAbsA7VgP/gU1IF6cECMDOtq7A4LGB+EfS/s
YU3UT4MfjQ/s2MJ+NdfrxBB7Mtf5xm77ArAQLAJ3Gw32UvAr45i9DNwj7PZycK/xgWO4iHOMALlC
d8wDeeBOMdKxBJRTR3cHujsepf4EWE39WfC8GOfYyBVbOH4A/0XfWfA3oTstYqTTxfUZrox1Pgfe
FHGu2SJOxXAj8e5WUdcoLiNyXyFyX8Hnc/D5HHw+HZ9PJ8ISiLAbibClRNgMIiyTCJtEhE0248oY
bp1pPGD9pbGY2BhBbDxMbKRb3zGeth4SVxFfVmuj8a31qLhZxVYdow6IbiGZ8mvk/Rp5q5G3GnmJ
yPsp8gqRl4q8DORdi7wRzJ6NrIeQ9Z8hslbC/y34zxCXwPVruH4N1w1w3QDXl+D6Elzj4DoArj64
Xg3XoXAdBNf+aPEZnLPg/CFcr4bjerIwztjLzL30fkDLb8Tl8K6CdxW8F8N7MSNKGFGiLHQ7GZLO
yj2iGP7D4T8d/tdpOUYDMhK1x5hXZbyBnDHIWYoGS5E1HA3K4H6/9QvjLFqcsh4xmtAkwRowzqls
P4WkU0g6jqTjSOqClEFIyUXKVUgZi5Q+SBgA9z1w2iNs7GZPE/+ReDeSllPsUkXsHY+LeyjLwb1g
KbgPVIBlYDm4H6wA240z4kOwA3wEqsHHYCfYBXaDT8AesBfUggPGD+Iz0AAOgs/BF+CQsUscBl+C
b40a8Z1xUJwC34MmcBqcMT4SPxhvih/Bf4Gz4G/gnHFYGOydAmjGYbULzjbqrbdQv41runHYtts4
YfsE7AF7QQ3YB2rBfvApqAP14AA4YpyxHQUB8FdwDBwHJ8DX4CT4BnwLvgOnAGuxnQOG8WbYpcYu
xw3GGUcamAFmgpuMg47buaaDLPqzQY7xpiPXOOyYB/LAfPruNE44loC7qZeBe0A5ffdxxfYObO94
kPpK8Cjtq7g+wXU17U9SXwPWgqfAOvg/S/sL1F+ivpH6G9S3gnpwAHwGGkCj8YPjK3AEHAUB8FfW
eAwcByfAKaPG8T3AJw584sAnjh8APnH8F2s4C/4GDGOXUxgHnZrxptNinHC6jMPOZ7iyFudzxI5F
PCC6qlPRKh4wjlLbTpzvFGHcyb1iIXdziPr3rB+LgUKjtUmkEpkNRGYDkdlAZDYQmQ1EZgOR2UBk
NhCZDURmA6MDRNoZIu0MkXaGSDtDpJ0h0s4QRceImCYipomIaSJimprPTeutIszqAV7jC2uG8QVR
00DUNBA1DURNA1HTQNQ0EDUNRE0DUdNA1DQQNQ1ETQOebMKTTXiyCS824MUGPNeE1xrwWgPeasJT
TXiqAa804I0GrH4Gq5/B6mew+hmsfgarHsOqx7BoExZtwqJNWLEBKzZhxQas2IAVG1TG1gsHthyr
nkvuNP6Dc3uGdafoZ93FCfYJJ5+0r3wK2YOGh4SNu2XcTeNuGPZdLWZxnsZznsZznsZznsZznsZz
nsZznsZznsZznsZznsYjZQxnah/O1D7k607ydSf5upN8PUS+HiBfD5CvB8jXA+TrASxtkK/15Gs9
+VpPvtaTr/WsNJszN4kcrSVHPyNHa8nRz6xe0dfKcwlncDlncG/O4J6cwTrnbjznbjznbjznbjzn
bjznbjznbjznbjznbjznbjznbjznbjx5WE8e1pOH9eThTvLuAPm2k3zbSb7Vc17Gc17Gc1bGc1bG
c0bGkyf1nJPxnJN9yJN6zsp4Yn8nsb+T2N9J7O8k9g8R+4eI/QPE/gG8ZOAlg9ivJ953Eu8HiPd6
ztN4ztJ4ztJ4ztJ4EY7NK7H579jR32dH34Xtf4XtX8N77xDf46y72dH3GOese0WG8tfnjD7MqMOc
uw/IXdrIZe4O5r5GaxlzH5BPbMydzNwm5s3mWekB42VGrmRkLSM/YWQeoz5WUfKM4vQb9S02eX79
UsXD4yrDioxqOKWoVezl2UyO363O++9U2cRTQJzxHSfLd8KtdRI9tNnAB/JAASgEd4Ai4AfLRQ/R
jVNpN6fSbuZ+xVz5X89FIH8Nch9DQqN6zlor+lvfFMOsm8AXPOceEr/gabMrTwOxPG32sR6hfpS1
BUS09a9imLhFfR/xCbAaPAnWgLXgKbAO/A78HvwBPA3+CNaDZ8Cz4DnwPHgBvAheAhvAn8DL4BXw
KpDfeJTfd3wXvAc2gy1gK5rI7ya+Dz4A28GHPK3M5tS+zXjD9pFRZ6sGHxt1Yd14emM9dtZj/9So
sx8gp/uDAWAguBJcZdQ5hoKrqQ8Dw42vHCPAaOrXgTH0TTDqnLpxzNkT9ALxoDfoA/qCfgC+Tvg6
4euEr3MQGAwSwBCQCK4Cd8OrFDwP3jS+cqKbE92c6OY8TtsJ45hrArjJqHPNNr4SDvy4Hz/ub35H
wXeb8NmlvB304ilitnDx9DzJehvX28UkEUWExBEhcURIHBESR4TEESFxREgcERJHhMQRIXHM1Jk5
j5k6M+epmVHMjGJmFDOjmBnFzChmRjEziplRzIxiZl9mDmBmX2YO+KdnDg/OHM6T5s2819wuBokw
9KxDzzr0fAc930HPV9Xz72n5NKre83bQv0N+h1V+a5U4nqXebmSOBMQDRGaAyAwQmQEiM0BkBojM
AJEZIDIDRGaAyAwQmQEiM0BkBojMAJEZIDIDRGaAyAwQmQEiM0BkBojMAJEZIDIDRGaAyAxor8nv
uxqfE537ic79ROd+onM/0bmf6DxEdO4jOvcRnfuIzn1E5z5th/GN9hGoBh8b3xCtO4nWnbYtxte2
rWAbeB98ALaDD8EO8JGxj2jeRzTvI5oDRHOAaA7Y1xvf2DcYX9v/BF4Gr4BXwTu0f8S1GiCHqN9H
1AfsXxjfEPkBIj9A5AeI/IBjkPG1YzBIAENAIrjK2Ec27CMb9pMN+8mGQ2TDIbIhQDbsJxv2OcbD
awLXW42vyYoAWREgKwJkRYCsCJAVAbIiQFYEyIoAWREgKwJkRYCsCJAVAbIiQFYEyIoAWRFw+uC1
0PjGuQjcbewjQ/Y5f0XbUrAC/C+wHjxP+wuMeRG8BDaAN41DZFGALAqQRQHnXtqOMvY4Y08Y+51f
c3/S+MaVZHxNZgXIrH1k1iHXzbRl8x5yhsj6nMj6XOvPm/wAMBBcCQaBwSABDAGJ4CowFFwNhoHh
YAS4BiSBkWAUuBaMBteBMeCnIBmMBSngepAKxoHxYAKYCCaByeAGMAVMBdPAz4D8jvVd4G5QCn4F
ysA9oBzcC5aC+0AFkN/GfhCsBL8BD4GHwSPgUSC/a/0EWA2eBGvAWvAUWAd+B34P/gCeBn8E6wGn
mfYseA48D14AL4KXwAbwJ/AyeAW8Kr8Lztrl98DfBe+BzWALkN8Kfx98ALaDD8EOo5FMaSRTGsmU
RvmdcTJ9CTuHg73iWnYO+UnBtbbXjdO2P4M3wJvgLfA2eAf8BbBv2DaBd8F7YDP4SETYqsHHIiKs
m3CHxXC9DMSCOHA5+ImIsGMf++Nc13LFBnZsQMY12l/iHjl25JBpjfYPuG4HrNNew3UfqAX7wafM
P8C8g9Q/B18YjQ4hIhyXGacdsSAOXA7iQW/QB/QF/UB/4XYMAAPBlYCYcxBzDmLOQcw5RtNGXDmI
K7Kx0UHsOCNBFOgEokFncAnoArqCbqA7QGcnOjvR2YnOTnR2orOzB7gC6MLt7Al6gXjQG/QBfUE/
wNqcrM3J2pyszTkIDAYJYAhIBFeBPOO00w8WGo1kdaPzbniXAuLPuQb8gfrz4AX6XgQvgQ3gPeZu
BlvAVvr30vYZ4xsAtnRiS+dx2k+Ar+k7Cb4xTrvIN9dYrhOE20WuuH5J/SauNxuN6mwJkOEB+bsC
8ncGiKh1qvU4rcc5cXZx4shPDT9SrYdoPRQcu4yxvxU2Wg/Terj5MzYRZplozOUd/hWep7sGP5H8
TgyysKNZhoFrjGOWn3KdaOyyTDI+tNwAphp74fg5u/+X7P5fup80PnSvBR8ZAXc1+BjsBLvAbvAJ
2AP2ghqwD9SC/eBTUAfqATu8+zPQAA6Cz8EX4BA4DL4EjeArcAQcBQEjEHEH56bFMosn2CLeyi6z
jDKOWK4Hy4xDluXGIfJtMLk2mN5d7seNI+5VYDVYB54xDrk3gJfBq2AjeMM4FF4JHgQrwW/AQ+Bh
8Ah4lDeVMCzzV6wirfEh1pBP4wfFFcheg+w1lptBJsgDy4xa1lEr37KQvwb5a5C/BvlrkF+L/Frk
1yK/Fvm1yK91v0PfX8AmsA18aKxhTbWsqZY11bKmWtZUy5pqWVMta6oVY/FaGV4rY211eK2M9X2P
107htVOss5qV1LES+cnqYNbbjd0oDOskshuFYaFEnuOXyWcRPHoKj55idXWsro7V1bG6OlZXx+rq
8HQZni7D02V4ugxPl+HpMjxdhqfL8HQZni7D02V4ugxPl+HpMjxdhqfL8HQZni7D02V4ugxPl+Hp
MjxdhqfL8HQZni7D02V4ugxPl+HpMixQhwXqsEAdFqjDAnVYoA4L1GGBOiKhTFyPFbxYwYsvtmMF
L/7YbpmIb5YZaWifhvbjeHu5n7eXB7DCZKxwKVa4GitcihWuxgp/xAr34Kvt+Go7vtqOr7ZjjTSs
kYY10rBGGtZIwxppWMOLNbxYw4s1vFjDizW8WMOLNbxYw4s1vFjDizW8WMOLNbxYw4s1vFjDizW8
WMOLNbxYw4s1vFjDizW8WMOLNbxYw4s1vFjDizW8WCMNa6RhjTSskYY10rBGGtZIwxppWMMr7MG3
vsfRdhXazkS75Wj3uMqTLdhmC3apwS412OAS9L+E3ofQfQu6b0H3Lei+Bd1r0L0G3WvQvQbda9C9
hjXUsIYa1lDDGmpYQw1rqGENNayhhjzJ4S11qvwsUu0vXeH+jRhs+blxlIw9TG+VJdd42zIP+EC+
sS/4ydtm9pbN7veMt91bjLfDNxlHw98F/5u3e42vqyzzPr6yd5uEdG3KSRA8oMhR5QyeUBTHAwge
GSoKI4KnlmF0OlUKailWKtNSDkU5TgUUxwxFLYKQWkJDaaGlmDaku0k23U3SlLTJSrrSpNm7gbbc
892Z6sd5Ps+L59Xz4sfax7Xu6/+/7uu6VpqWlViF5/ECVmMNXsRavIS/oBnrsB4teBmt2IA8NqIN
HSjgFWxCEZvRia7Qf+Dn8QVY7/gdbTK+9pL93Wt/99rfvXQ7nW6nj9eX5ephE1ZgNV4KvdZesvaS
tZesvWTtJWsvWXvJ2kvWXrL2krWXrL1k7SVrL1l7ydpL1l6y9pK1l6y9ZO0lay9Ze8naS9ZesvaS
tZesvWTtJWsvWXvJ2kvWXuLDpaFA7bUUXvO3n+NUIloSnS6iBu9v8v4QN0a4McKNEZ9t89nz9++S
Sq2YuL9WTJRH93NnhDsjImwQYYMIG0TYIMIGETaIsEGEDSJsEGGDCBtE2CDCBhE2iLBBhA0ibBBh
gwgbRNggwgYRNoiwQYQNImwQYYMIG0TYIMIGETaIsEGEDSJsiM4WRT1f1vJlbWZa9FberLX6BbL/
ZdnfL4p6URyxf68fsX+vP06D3/JtLd/W8m0t39byba2o6kVVL6p6UdWLql5U9aKqF1W9qOpFVS+q
elHVi6peVPWiqhdVvajqRVUvqnpR1YuqXlT1oqoXVb2o6kVVL6p6UdWLql5U9aKqF1W9qOqjGr7s
FcUtolgvijZR3GLVL1j1lmiSeJeLd7lYl4urEtMR3qkXz3LxLBfPcvEsF89yOXBteCMzEzd5fKvj
XZWfyng1zdwks6v8d0ydnBnGPMpnfhZNyNzsU+5cMndHkzP3hj2Z+8KeSYvxKH6H3+MPWILH8Ec8
jifwJzyJp9CApfgzluFpNOIZLEcTng17rGtm6M7MCtusb0vmF2FH5p4wGn0l82/hucwMXCdLr8fs
0JK5ET/BHNwUHZ75mePtoTNzR2jPLMSd+DnuVePUs0nnh+cmXYDP4EJchM/ic/g8voAv4ku4GP+I
SzAFX8al+Aq+istwOf4JX8MV+Dqu1ImuwjfwTXwL38Z3MBXWPMmaJ1nzpJ/iJsyFtU+6Gf+OeZiP
W7AAt+I23I7F4ngUv8Pv8QcswWP4Ix7HE/gTnsRTaMBS/BnL8DQa8QyWownPhue5fS31fhY2ULGQ
uds9ZUYejPC/PJ4bg1GtT/RwqMyhkcwNlbyJ3uEbW32je/wb/8qpJk41ZX5gcpxJ+escr8cPTWQV
X2/wzdlmpxvxE8zBTSHoQk26UJOrjWZu49odoYuLXVzs4mKXXGiVr23cLHKzqCM16UhNOlKTjtSk
IzXpSE1cbuJyE5ebuNzE5SYuN3G5ictNXG7ichOXm7jcxOUmLjdxuYnLTVxu4nITl5u43MTlJi43
cbmJy01cbuLyIJcHuTzI5UEuD3J5kMuDXB7k8gCXB7g8wOUBLg9weYDLA1we4PIAlwe4PMDlAS4P
cHmAywNcHtBVm3TVJl21SVdt0lWbdNUmXbVJV22SBUVZUJQFRVlQlAVFWVCUBUVZUJQFRVlQlAVF
WVCUBUVZUJQFRVlQlAVFWVCUBUVZUJQFRVlQlAXFaBoHeznYy8FRfj/NxYpzrZxr51zKuZRzKecq
/h/A/z9yr4t7XZlb1IrKzr09PMzBbg52c7Cbg90c3MzBPnnyHBfbuNjGxS4udnGxi4tdXOziYhcX
e7nYy8VeLvZysZeLvVzs5WIvF3u52MvFXi72crGXi71c7OViLxd7udjLxV4u9nKxl4u9XOzlYi8X
e7mUcinlUsqllEspl1IupVxKuZRyKeVSyqWUSymXUi6lXEq51MWlLi51camLS11c6uJSF5e6uNTG
pTYutXGpjUttXGrjUhuX2rjUxqU2LrVxqY1LbVxq41Ibl9omVearp9GIZ7AcTXjWXHUal8pcKo/v
xpuig7kwyoUxLoxxoMyByvw+Rt0x6o5Rd4y6Y9Qdo26ZumXqlqlbpm6ZumXqlqlbpm6ZumXqlqlb
pm6ZumXqlqlbpm6ZumXqlqlbpm6ZumXqlqlbpm6ZOmPUGaPOGHXGqDNGnTHqjFFnLKq263foMbnM
LXrLgsqKHfWZaKrY+sTW97faMdsd6I34CebgJp+0f8Q6UIlTpvXJtD6Z1ifT+mRXIrsS8Q+If0D8
A+IfEP+A+AfE3yf+PvH3ib9P/H3i7xN/n/j7xN8n/j7x94m/T/x94u8Tf5/4+8TfJ/4+8feJv0/8
feLvE3+f+PvE3/f/UCMS2ZfIvkT2JbIvkX2J7EtkXyL7EtmXyL5E9iWyL5F9iexLZF9C3wH6DtB3
gL4D9B2g7wB9B+g7IPsS2ZfIvkT2JbIvkX2J7EtkXyL7EtmXyL5E9iWyL5F9iexLZF8i+xLZl8i+
RPYlsi+RfcmkZ8fvtm8Kw+M/z34fr1JepXb3oN3dS/uU9imNUxqnNE5pnNI4pXFK45TGKY1TGqc0
Tmmc0jilcUrjlMYpjVMapzROaZzSOKVxSuOUximNUzGmYkzFmIoxFWMqxlSMqRhTMaZiTMWYijEV
YyrGVIypGFMxpmJMxZiKMRVjKsZUjGl0kNpXkoH7ZOC+Svcb32G3eO12uXq3T10Z9nF4H4f3cXgf
h/dxeB+H93F4n9ntWvOM2i/LJ+/P8l5ZfrgsP1jf/OsOnhWdmLkhOkrXG/PuKVQs/f/YoeOTX2XS
Wz3+qBLjaJT16DWPXhPt3ugfrbFojUU6lOlQrsyJoplo96V2XyqqnDUfzP2t1p1yf5j7w3Zeauel
dl5q56V2Xlq3bDwriuIqiqsorqK4iuIqiqsorqK4iuIqiqsorqK4iuIqiqsorqK4iuIqiqsorqK4
iuIqiqsorqK4inwp86XMlzJfynwp86XMlzJfKpUptXNSOye1c1I7J7Vz0kkVT+8Zz6phWTUsq4Zl
1bCsGpZVw7JqWFYNy6phWTUsq4Zl1bCsGpZVw7JqWFYNy6phWTUsq4Zl1bCsGpZVw7JqeFzf16mY
0ncsOizzpPuUFeGFzHNm65VhZmZ1+K/MLr2yFO7MvBZasnFIsrlQzE4OA9nDcDLO8tpnw+/G/6x+
SnRQ9stRvP8nd4Mc+41z/0GmPmdyX2mOWxV2Z57HatV2jSx+yfS8zqTsTjKz0bENfXK1PzrEVdsz
ZezG664SuRuvQS2ODOXs6WFb9gycibPDSPacsC7+bRiNHw0t8R/xJ4+fdHwqbIob0Oj5CseVIY1X
4Xm86LXWsDvegDw2er/gtVew2fNO9DhHEsrxkPOXUA7b4t0Y89prnodQzuVweNiWOwJvxts8fzve
6fExOD6sy50Z2nMfxEfwVVyGy/EtfBtX47HQklsd0px15ZrD7twG392ELvSH9uh8io5QdJCaG6m5
g5o7qLl7v5p5aq7br+Y6aq6j4g4qJlSsKLiTgjspuJN6u6i3i3q7KLeVcoOUW0e5dZQbpNw6yuUp
l6fcIOXylBuh3AjlRig3SLkdlNtBuR2Uy1NukHKDlNtBuR2UW0e1rVTbSrVdVNtFsa2U2kWpXZTa
RaFdFNpFoa0U2kmhnRTaSaGEQgmFEgolFEootJNC6yg0QqFBCu2g0C4K7aLQLgol0bGZxeG7mSdD
o0xeQZn/pMwbFBnKdMrovmhWpj88JKu/nhkNv5XVn5RbL2Sz4flsdbhLhl8kw9tk+EnZg8KS7ME4
zOOjo+9ljwuXyfiTsqeEz2RPDbNk/hny7hfZc8Ps7HnhCh3o5+6Lt7ovrvye32+y08Kz47+lMNlK
Kn71Wc1WVx7iyXZX7nW1IVdLXS11lTR7tLvrkx3PwiXROfbTR3x7sUq3wr5YaR+tDuvFUhbHMc7U
6iwvOstGZ9niLO3O0m6tk5yl3Vny0YG+ucY3t/nmU751qG+td/3NvvmsbxZ8s8s3C75Z8M2DfHOj
b3a48/6N66zUI1apy89jjcx7yTS9DvaKDNsiw7Y460TfzMqeLbJni8zZInO2yJwtsmaLrCnLmrKs
KcuYMRkzJmPGZMwWmTImU8ZkyhbObuFsOVf5vbuMsx7orHUiqGT8YrEvtZ4/Y42MvUR8l9qry53z
77Oyy/NXnUOGOMfKcE1lX7grWEz5J+2ElWGtV5ozL3Mh75ydHLgkrHeu9dFVrnS/T862v7p9+glX
XOCKC3xrBxX2UGGPb2+kQpkK/3OGjY5t6AiPOdtS2dWSGQxrs3WIw3babqft9uzhOAJvxtEUe1d4
Jnssjgt92RO9dhJODj20782eE9VkP+r5eWHH+E9bKr9d8tX/+WmXfdpN6SFKD9mn3dQeonaZ2mX7
tJsiC6heUeV+qtxPlfvt1W7K76H8HsrvoXzZXu22V7s5sIcDeyi3gAtD1FsQD0U18a6wPR5FyePX
oppcVXgmVxe25w7BoRBT7mi8A2LJHed4vM+d4Hii558Ka3MXhsdyF+Gz+I7n1+CxMMSd++3fbk7v
yRV9fjM60Y2t4bFokqzdLGM7Mi+NZ8KZFHv/+J9Wfs1qnooycQNWYGOU0bP+J1O382iQR4O+Ua2+
9atv/epb//+RgYN0GKRDpU4Nin1QbepXm/rVpX51qV9d6leX+tWl/v0ZOajO9Ksz/epMf9Vbqu4I
i6oW4k78HL/AXbgb94RFVjRPJt0li/4ii+bJonmZZ+TecqyQf6tMWM9jdVgim3ZlWr2eD52y6MZM
Qe16BZtQxGZ0hpszXY492IpX0Yvt6Isuk3V/yiQeD2Aw3J7Z4ZhiKMzI7MSwxyPYFaapey06QoeO
0KEKXKr+PZ/Z47292BeeybzhGEJjtgoZZDEhzMhOdKwOD8vs27OTPI7DxarHRhl+sVp5s1p5c/aQ
cKtsv1i2Xy7bL5ftl+vVC7NHhfuyb/HeW3F0dGn2nY7H4F3hGrvgGrvg2uzxnp+AE33/JLzb4/fi
5PAlNfdaNfdWrs7h6hyuzrFTLlB/H8i+z+vvxwfCTdkPOn4I54QF2Q87fgTnhuvspsuzH/P4PJ+5
JNy9/7fWltpZt8uro+TVUer1U+r1b6q3hEU178KxOA7H44SwqPbBsOiA8/DlsCheEtbGj+EpHa0B
y8M8u26XTJsn0+bJtHnxau+vwTqsRwtao6PiDchjo89v8loRmz3vRJfvbfH8VcfecGu8Hf1IwsJ4
INynmy6Id3o+jBHsChfbpRfrsAtk8RxZPMdcslCXXRC/Hm6K92Cvz4Ww0A6+JpcJt+aymBBuspsv
NrcszB0Y7ssd5LWDcYjXDgUP7YY5dsMcu2FO7kiff5vPvh1He+8deKfXjwEPc8eGRhXgYl18gQpw
uQpwTe4kr70b78F7cTJOwak4DafjDJyFs/E+vD/MyH0AH/b4XFXko/iYx/+AT+CT+FS4Pfdpx/Nx
gfc/43hhuFGluVGluTH3Oc8/7xxfwBc9/hIuxj/iEkzx+pdxKb7i+VdDh0mjw6TRkfsn5/ua167A
13ElrsI3fPZb3v82vuP6U702zWvXePy8qrY6zMs1R0fleJ3jdY7XuZdhX6scc3IFGm9yLNJoMzrR
5Xm34xbn2Wrd9rMJpiOXeD6AQewIM6LjVJLrVZKlKsf28Ul6tR60JuzdP9XMVQG+pQI8Y3c32N0d
+nvJzn7Mzu6xe9fatZvs1kft1nV260K7tdlubbZTF9qNV9h9T9pld9hla+2yZ+ys/7Cz8nbOi3bM
k3bMHXbMyv1/92De+G9gXqnGLbOyp3TL9Rn38la4Tq1bodatsMqSivx7FbldRW632qfVuW265sN6
7/bxGWajx23oCKtF0ay27RZFQf3aJIKBv06tonjF5NorirLptdf02qsGbVI7impH0Qr3WWHlt0hX
6I7r4/qQ6JAP65AP65DrdciH7dNt9uk2HXK9vbrCXt1mry6zV5fZq8t0yPXxWt97CS+jNbTrEu26
RLt9uk23XK9brtcx2nWMdvt0hW75sH26wr4q2gNFOV+U37tNsb2m2F45vNsk2ytvd8vZTXJ0tRxd
LUdXy8vd/2vCvdLzq/DXSfc7Pn+1717j+Fh4WH4t0zHX60TtcmW1XNk9Pu3+RFdp0VVa5MZfKL5X
bjxD6Q5K79VVWqi8l8p75cgZukGrbtAqT14anwHL3t+N13ShfSaqiN8TQiuVX6RyZbJ8Sc4U5Exe
zpTlTFnO5FX3vOqeV93z8ucU+ZOo2nlVOy+PmlXpZlW6WZVulkvNKnNRRe5QhfOc2at6tqielbu0
vdzZy50O7nRwpUPVbFE1W1TNFlWzRdVs4UCHStmiUraoji2U36sSdqh+edUvr/p1qH7Nql+zyteh
8hVVvqIqV1Tl8qpaXlXLq2p5Va1ZVWtW1ZpVtaJqllfN8qpZs2rWrIrlVbEOVSzPyRdVpFYVqZWj
L3LzRVWpXVVqV3naVZlWVaZVRWlVUVpVlFautnC1hastqkm7ytHK1RautqgYrVx9kaN7VY0W1aJF
tWhRLVpUixbVokW1aFYpmlWKvEqRVynyKkWzSpFXKVq53qJCtKoQrSpEqwrR6j6+LzqYEzlqj0Zn
25GpXLjO7ltk9y2y+3rkxCw7rMz33/J9Kd+X2lmDfC/wfTHPF/N8sR2U2jUpT2bxZJYdk/Jllh2S
2hWL7IpFdsUinsyyK1K7IrUrFtkVi2R/mWaLabVY9pfptZheBXoV7IIyzQoyv0yjpTRaSqOlNCrI
/rLsL9NpKZ2W0mixbE9l+yKZXhbzUjGuDP8uu3tF0ODZLtWkFB6Uu3qnyEY96xVZn8j69v+8oFnN
SETWLLJmqxu1umara7a6UatrtqpRKxq1oj4r6rOiPqsZtZpRq+mzmj6rabaKUavoc1fUo7KVxieo
TlfqrNRYGqau1uJqo67W4motrlZytRZXa3G1kqu10CKlReqqJVqkrlxy5U5X7nTlTlqkrl5y9ZKr
d7p6p6u3uHrJ1TujOnXyVyLPi7rNlUddcbva16g6t6vOBTWwcbw6V++/z+zyyX73khe5lzwte2l0
xrhyXd4peqf7b89er5wxmuhZJboez3Y4/zrn3xFlTEiVP6M+01zeIbMGaf16GFaDR9W1UXUtVddS
dS1Vt0bVrFE1KnW2TlW8pDu8bu9n1Q76RMc7R5d3KrPsTuda5hPbqDlCzRGf3EzJIhWLVCy6RuXv
jS0R1+8pupOiRYoWKVr5KUGRkjutYZk1dFlDlzV0UbXy04MRqo5QdYSiOym6k6IjFB2xxmVULVrn
Muvsou5O6o6Ma9Ej1oxYM9ER1rnb2oatLbW2dH9ODYtiwPqGrW/YeoatZ9hahq1htzXstoZKbU9d
P3X91HVT101dc9j1KnU7HVdhFRXWUGCNutyjLve4fjvlN7rSmDrcI/rKb0ds+Dt3N1jfBOubUPn7
DGpTj9rUQ4E1rr7K1Ve5+ip1qUdd6lGXetSlHnWpRx3qEfkaNahH5GvUkh6rWaWW9KglPWpJj1rS
415Zf7OSHVbSJ9YRK1i4/8/7K/fJlb91uEEv6XCP3KnT9zhu1W8Gw0pqLaHWE9R6Qgwr7IsOij3A
+zZn2ka1B6j2gLhW7v8ttVaudpsIOyj5ACUf4Gw3NR+wVzrslQ4Od4tvpf3SIcZuMXaLsZvL3Sa7
DpNdhymug+JPUPwJij9hH3VwvZvr3dR/gvpPiH0lBx4Q+0pxd3O9mxNPRG+hfoH6hf0/GXlt/Ccj
URjkQMGKB6140OoGqV2gdsEqB61wkMoFKheoXKBygcoFKhcoXHClQQoXqFugboG6BeoW5FhJPX49
dFayKKry7JfyrfLzgLNDb/RO90pD5ppt5pptuuiYLjqmi45V3tVB27Nf5cHXzCGJO/Uhc0gJ5TCm
842Z+4d0v3az/pCZZJvZfki3G9PtxnS7MfP7kPl9SKcb0+nGzCyVn0u2m1u26Tpjus5YrvI3y2qs
4GkreHr/zvuVsz3t00/75NNRlbXsiD40/v/EWog78XP8Anfhbtxjr8dqYk4GTVZ/DhLVwTjM48Mp
egTejCPDXnNDv7mh39zQr3v1ibLbnDAoy15xJ1Z2J1Z2J1Z2J1Z2J1Z2J1Z2J1Z2J1Z2J1amRGUW
6DYL9JsF+inSTYm9lOimxF79v58Se80A/WaAfjNAPyX2UmKv3t+v9/fr+f2U6NbzB/Xdfn23X9/t
13P7x+Mdpkkctoplm1jGxDImlm37f/69Y/wz26M3mZ3f4FqZa2Wulfc7toFjG/7OrTK3Kj85budO
mTtl7lR+UlzmSnnckQ2Om9BV+V2H8cx4M0+6edLt/MPOP+z8w97pdo2icxedu+jcw8497NxFnnU7
/7DzDzv/sPMPO/8wH7tdozKtdrvOsOsMu85wVC2aoewHoonx69gTTcxNwJHRxEr912W+JsLK32Fe
KSOWRUfSo5sePXTo4emrPH2Vp6/ys4efPc7WRZutvHyVNz286eFFDx96+NDDhx7699C/h/49tH+V
9j2076F9D+17orNdZVQWjbjSqCuNutKoK4260qgrjbrSqCuV/5cqZ3n+gXH1e119VPf7uO53iihe
EcUr1Oq1olErGqVa79+p1mtyLJscyybHcq7S3w7BoXDt/6Xmkd4/2mvvwF+VPc7j483sJzj+Vdmi
x5vRCSqLatRe/7+p/Ha7YZTLnVzuFE+XeLrE0yWWIVk+ap1d1tklu0etc8g6h2T4KKc7rXdIllfW
2GWNXdbYZY1DMn1UplfW2GWNXdzv5Hyn9XVZX5c1dY3/faETsldEJ0T3Rt8M90bfwrcxI8yOfhi+
F/0IP8Ys3ICt3nsVvRgJD0WvhTui17EHe7Ev3FF1YnR41Ul4N96D9+JknIJTcRpOxxk4E2fhbLwP
78cH8EF8COfgw/gIzsVH8TGch4/jH/AJfBKfwqdxPi7AZ3AhLsJn8Tl8HtOiI6qeDc9UrQgNVc9h
JVbheawOy6vW4EWsxUth+YQHw/cmPIRfodnzdVgPsU54AyHcMfGwcO/Ew/Hm6PCJR+IovAVvxduQ
hO9NLHt/N14P36s+Ex/DteHe6pm4DtdjdphdfSPmeu++6PDqV8Lymig6vOZ0xzNwZmioOQsfwbme
fxo8q+FZzbRwR82vsQQDng9iB1KMhodqSuBVTQj31laFO2pz0eG1B2IyDsLBOASH4jC8CUdATLVi
qhVTrZhqxVQrptq342jMDstrb8R/evw7xxccdzimoeEA/h1A8wO+EpZH/xQdYjo9FIfhTTgcR+AE
nIiT8G68BxfiInwWn8Pn8QV8EV/CxTCZRF/BN8MimbtI5i4az9zv66w/wLWYievww/CIbH5ENj8i
mx+RzY9MmB/WT7gFC3ArbsPtuAMLcSd+jl/gLtyNB33vIfwqPML1RRO3hPUTt2E7+pF4fafjMMre
343XwyPVNWF99UE4GDSopkH1MXgXTsVpOB1n4EyfP9fxY46fdBRz9XcwFdNwNa4Ni2TOIpmzSOYs
+lvm/CT8snoO5oZHap+saBMtDC3Rnfg5foG7cDd+i3r8Fx7BYqzFS/gLmuEuNXKXGrlLjdylRu5S
ow3IYyM6sDU8riY8riY8riasjXZhFCWUsRuvhSXqxBJ1Yok6sUSdWDKhL7RMcEc7IcEABrEDKYaw
E8MYwS6MovK9NxDCEvvt8ZoLQ0vNF3AJpuDS8b8fvbbmCsev41s+821MC0tqrvV8Nm7EHPwUN4M+
NfSpuR8P4EE8hF/h1773e8cljsscX0ARm9GJLgw4/yB2IIXY7bW1NWKvEbs9t8See7w2CmvtuyVq
4YToIFX/oKgaNahF5d/1rcMkxMjhQKiCkV0kx6fL8elyfLoc/64cv1KOXynHr5TjV8rxyv+R6wB5
PlWeT5XnU+X5VHk+NfppNDm6CXPxM9yMf8c8zMctWIA/u84ybA33cPQejt7D0Zs5Ooejczg6h6Nz
ODonMitydRZXZ3F1FldncXVW5f8oWvUfWARqVlGzippV1Kz6NR7Gb/CfkIFVMrBKBlbJwCoZWPUo
fgeqV/0BS/AY/ojH8QT+5B78tGhyRhfJnOX4UZwfpmcuCNdnLsQXo0Mz08KdmavD/Mw/o/I3Db4a
PpO9LHzfFPCZ7BWO3w9rsy368cvRYdkN0THZjea3tqguuzXsyb5q5uuNTspuc9wevTebOA5Eh0z4
fnTQhB/gWszEdbgeP8SP8GPMwg2YjQfDVLViqloxdUJrNHnCBuSxEW1oRwcKeAWbUMRm0FKmz5Lp
s9SZ6RPfFFpk/D3qy9SJpegAtWW62jJdbZlaLZeq5Uu1fKl+K96Gk3Gm985yPAc6qHoytfo8j68N
09WO6WrHdLVjutrxXbXju2rHlWrHldU/jQ6ovglzfZ5f1fyqrmT8iTgJ78Z78OHx3TbHLrvHLrvH
LptV8+Nocs0syKkaOVWzCL/2+mLH3+lkSzx+yuMBnx/EDqQYDTfbNTfbNXPsmjk18qvmNcgvu+ce
u2eO3TOrNhNNrn1HaKl9J47Bu3AsjsPxOAHWWWudtdZZa52178XJOAWn4jScjkecy7pqH8VKz1fh
+dBywKdDS90D4fq6h7AyzK97Hs3R5Lp1WI8WvAye1vG0jqd1PK3jaR1P63hax9M6ntbxtI6ndTyt
60QXurEFPdiKV9GLbdiOPvQjiSZPWhEdOuk5rMQqPI8XsBpr8CLW4iX8Bc1YB512UgteRis2II+N
aEMHCngFm1DEZnSiKzo0nh5NPvDz0aEHfgH2k0lxfZTNbh2/J1gfHetRTeZ4lSwe/7fGq1GDWlT+
X7J1mIR4/N+zjlWyWPd3PRyGN+FwHIETcCJOwrvxHnzIFc/BhSExBSSmgMQUkJgCElNAYgpITAGJ
KSAxBSSmgESFnKFCzlAhZ0RTQxpNw9X4Z1yDf8F38T38K6aj8i8EzQjXq6bzVNN5quk81XSeajpP
JZ2ikk5RSaeopFNU0ikqaaySxipprJLGKmmsksYqaaySxipprJLGem5Bzy3ouQU9t6DnFvTcgp5b
0HMLem5Bzy3ouQVVN6fq5vTeRO9N9N5E70303kTvTfTeRO9N9N5E70303kTvTfTeRKWer1LPV6nn
R9s970PlzwYSDGAQO5BiCDsxjBGf3xXmqupzVfW5qvpcVX2uij5dRZ+uok9X0aer6NNV9LyKnlfR
8yp6XkXPq+h5FT2voudV9LyKnlfR8yp6XkXPq+h5FT2voudV9LyKnlfR8yp6XkXPq+h5FT2voudV
9LyKnjeT/8lM3mgmbzSTN5rJG83kjWbyRjN5o5m80UzeaCZvrPpLVFfVjHVYH9XpBjndINYNcpkP
he06Qi7zD47nhxt0hat0hat0hThzWUgy38S0cLPuMFN3mKk7zMz8S0h0iLN1iKt1iLN1iKuz/xZu
zz7tnnd5lMuuCNdk14edusUhusVRukWiW2Sz7e41t7pHfVUn6dVFKv+iXOL1AdX/+1GsW8S6Raxb
xLpFrFvEukWsW8S6RaxbxLpFrFvEptHENJqYRhPTaGIaTUyjiWk0MY0mptHENJqYRhPTaGIaTSbc
E9IJ9+I+3I//wCL8Eg/gwTBFB5qiA01x79Lo3qXRvUujbhTrRrFuFOtGsW4U60axbhTrRrFuFOtG
sW4U60axWS0xqyVmtcSslpjVErNaYlZLzGqJWS0xqyVmtcSslpjVkgkllLEbY3gNr2MP9kJu6XDT
dbjpOtwMHS6vw803URdM1AUTdWKiLuh4UyamITVVF0zVBZ1vhs43Y+KY117D62GKDhibsAvVtSGt
PgB1mIQY6o/OGJu+C6bvgum7YPou6JRxdeVvpx/j8btwvM+egJO9dqrnp+F0nIEzXeMsr3/I++c4
fiQ61IRe0FGn6KixKb1gSi+Y0gum9IIpvWBKL+i0M3TaGTrtDJ12RvUPff9H+DFm4QbMDtfrvtfr
vvN033m67hRdN6/r5qv/K6qrXg457l6wURfOV/dEdTpxXifO68R5nTjv/rDR/WGj+8NG94eNOnPe
PWKje8TGmk/5/Kcd1VKzcmJWTszKiVm5oHvPNSsnZuVEF5+vi8+v+Y7HUzEtTDczJzUzcR2uxw/x
I8hdXT42Tyfm6YJ5OjFPJ+bpROePdf7YXJ2Yq5MauVojV83XiWkgNmMnZuzEjJ2YsRPTwXTTQWw6
yJm1ExPCdBNCbN5OzNuJeTsxbyfm7cS8nZgc5psc5psc5psc5tfIvxr5VyP/auRfjfwzTcw3Tcw3
Tcw1Tcw1RUw3Rcw3Rcw1RUw3RcSmiLwpIm+KyJsi8qaIvCkib4rImyLypoi8KSJvisibIvKmiLwp
Im+KyJsi8qaIvCkiX3tdVFd7PWaHRvfBjaaK2FQRmypi98ONtb/33h+wBI/hyZCYNvKmjbxpI1+7
0Ws7fC7FkMc7ozoTSN49c+MBl0V1dfeF7XX3YxEeCFeZSq6q+7XHy0NS14QVWBlmmlJm1q32WA8x
reRMKznTSs60kjOt5EwrOdNKzrSSM63kTCs500rOtJIzreRMKznTSs60kjOt5EwrOdNKzrSSM63k
TCs500rOtJIzreRMKznTSs60kjOt5EwrOdNKbFqJTSuxaSU2rcSmldi0EptWYtNKbFqJTSuxaSU2
rcSmldi0EptWYtNKbFqJTSuxaSU2rcSmldi0EptWYtNKbFqJTSuxaSU2rcSmldi0kjOtxKaV2LQS
R0dGt4VP/N2/2LSi6q34WjSl6uvRJVVXRj+uuir6eNU3ok9WfTO6JHN+dFlm2vi/3/aJ7KXh49ll
4bfZ5eGibI97hK1efzWk2W3hjmxfWJPtj96STUJrdiCUo3e6ygHRo6E9WhXaXe0aV7vG1a51tWtd
7QJXO9nVPuBqJ7vaqZX/p6CrHexqB7raB13tXFf7QbYxLMs+g+VvDGSfDU/pN+3Z58Kq7Mpwm1XM
tYKxbG/YZhUftIrbrCJrFb+0ipVRbXZd+E22xdrcoWdbwzeyG8Kfs3nfagubdChaWeNT1viUT35F
H1vv03f79I+zrW+84dO/8ukL9LQnfeM637g/Oia6LTq7KhfVVB2IZ8Ns3fVtuunHMp91r6UyZL6r
wy6Ojs2sDOdlVoeLMp3R2f/N3HXAV1Fs7zMze3f2lk3oJLTQQhURRRQQgg0VBEQFka5iAbEj+lTE
+lAszwZoRH0PK6hgoWhAqgEJIaEltFBCSEggEEFKgJD5fzP3JpQEAsHy3/19u7PTd/bMN3Nm957L
D6ghoiP0pzkUwKh5Ie7ie5T2G/QsIVZBh0pR0zFqelBCIe4qBSPnM6GRU4R0LYG7yxI5uLOd8N+l
drOmZKk48gA2IAEH8AI+wA8EABcIA8LVHKoAtFMbqD3wolpMLwEvA/8GxgCvAK8CY4HXgNeBN9GO
P6tNFKc24TluwHPcwCoAFYFKQGWgClAVqAZUByKASKAOEAXUBeoB9YEGQEMgGmgENAZGqTT2LDAa
eA54HngBeBF4CXgZ+DcwBngFeEuls7eBd4B3gfeAccB4YIJK5xepWbw1EAP0VPP4q2obH6u2QXJv
NXY1txvbmt+hRXMhLzdBXgrEwcJscUhdLfKVIw4XHhJHCjeKo8oWBYU7xDEVIwrhr1SE5SnMtmx1
tSWVYzmFhyxv4UbLp2zLX7jDCqgYy4V/GOKNUHHW48BI4AngSeBfwFPA08AzwCjgWWA0MFVtsKYB
3wHfAz8APwLTgRnATyrN+hmIA2YDc4BfgLnAPGA+sABYCCwCfgVWqcXWamANkAKkAmuBdcB6YAOw
EUgDNqnFNmTJhrzYkBcb8mLXwrk20AJoDbQHOqgN9pU4j1dp9n+BSbiehjPqY6M+djyuFwNL4U4A
UuBOxRm9zV4HrAe2Aukq3d6OsAPAUaAAOAYUAkptkJEqTdYAagK1gAYqXTYEooFGQGPgGbVYjgIg
qxKyKicCU4Bv1CY5Uy12OPCASnMeURucETi/h/M4nD9R6c5khCGu8zWwGX5bANTLSQf2qjTvlSrd
exswSG3wDlYbfJPVNt93wA/AdGAmEAcsV7N8SUAysAJYCawCVgNrgBQgFVgLrAPWAxuAjUAasAnY
DGwBtgLpwDYgA9gOZAJZwA4gG8gBdqpZ/rfUNv/bwDvAu8B7wDhgPDABWKDm+RcCi4BfgXhgMbAE
+A1YCiQAy4BEYDmQBCQDK4CVwCpgNbAGSAFSgXXAemADsBFIAzYBm4Etal7gEfOb/3lhNwHoe2SB
d78Di+4UKeC9taqAekF/jIX+GAv9MRb6Yyz0x1joVwnQrxKgXyVAv0qAfpUAdt3DFqv10HNyoefk
Qs/JhZ6TCz0nF7rL+9Bd3oeukghdJRG6SiL/TB0G664B26YXfTshIqGbLFCx0MzrgNu3gGnfwdw/
FnP/WMz9YzH3z8XcPxdz/1zMuxMw707AvDsBc+tYzJ9jMb+NxVw2FnPPWMwztRW/XMwntfW+9bKN
sVOWizlkLuaECZivJWCOptc19XpmAuY9uZj35GKuk+vMVusxl9HW9nK9fdV6zFfex3zlfcxPEjE/
SQwsUocDvwLxwE71eyAfUOp31wVqA3VO+X6j6LuNJeqw+U6Dg9W+wfjwKoWLOGorZtMAMY9ai/kU
gfufKRZidF5EjUUSdUdbdIe+5sHIE4DOVkGsoVZol80YgephzNxGHTC2ezHudMe401hkU2fkuyi0
1ncBSlqAklLUeFPmPoQNw+ik7QSmYFaQo5KIsaEUgyefrPOl9sjtRvDsDcg76NMKLHwIvleBhXeD
hfcZy4+71GHkmIFScuhys5YSgbiNzNpKK9SmCUq/EFfJdBlqHokwD+6hF+rdRy0XI3DPC9QCq4Ox
j94HY+sClYjY4CTMG/JwlYar4ZhdzMc4vEAtpcZkoZYewAYk4ABewAf4gQDgAmEUI3pRVejBM6AD
z0AuHaD/JiOntchpFfTZGOizMdBnY6DPxkCfjYE+GwN9Ngb6bAz02RjoszHQZ2Ogz8ZAJ4uB7hUD
3SsGulYMdK0Y6FYx0KNioEPFQG9CXUxd49R+lJSGu8gS8yC989V6lDgDM6BduPcRdAGedVWE7td3
i3sPo0psBTVkK6klWmaAmbP1Rax+1E8MNPYP+4nhKh4a/FIxUqWL8dRGTADi8BxmUyOMkN9abamV
pa23C6SKRopolHMJnuYIqoeSdmtpMiV50J/WY66Ui3nSYfPsU/U/vcF3D67yzOwrF08rHAywCnEK
wAIFCNmj4+mZDkpIwtNOhgSmgBcgHWovUuchz914wpWR5iBC4kPx83WOKDUZviuQ80rc9Sr4paD0
YIwCE0NLmY0YBxGjICjj2uIq8l2rjpparUCMdqaeqzCf0qFrVCrkqQpmeUdRQjAPJ5R7llir30iY
eq7A1Uq1C+mOhu46AyHbqD56Qh5k1IceUwM9pgL6wRxiOOYZa+f5kPJCob9xEojtICbH1Xrcvb7K
QF2zELIDeeRgzrkTobu0LQf0k0KEHkbuhcHc0W+ykVsOJF7Ps3X6CohxKBRD21J1ELrVWO5HzVQi
ek/jYCh4WIdmo1xucstRWaYP6/y0nfB8tPsxtQVzm92Yy+h34MdUHlz6WR5ErKNAAVr9mEq2PCof
8558y6/2I0ayibsKLt1mR3B1FCUeQ6sqVWh5iSNuIUJTMTcqRI0PIvQQnk4+nuNh5BjMWadIQYoC
5F6IWVYBapJrOSghWJLOIQU5FOCZHkLr5qO9DiPVUaWQMtuUZRNDqjykKkQqhRTZpsxKKDNd6P9m
yMfc/zBa/IhaY2pZgF5cqHJMao9KRw4cOWxEDgctr1pjau5XazGzyzE52cghH+VtFoUmZj7K2Gy5
pr3zIR9HzH2sR0gW0us6r6cwqwp5raqoVwTS1KAKFuY1Vi1yrNpw10FYFMLqI6whrqMR1ghhjSF3
llUNJdREaF2co/EsAlYVXFVVe6zqOi+UUBMl6bzqwD8K/vV0PvCPhj/yIdvEjiCfyUfHqA+3zqsS
6sURmmlVg091IIKiUL9KiJmJPKNQP476caTKtOoivB5QH/4NEScafo3gbqz/exC5pKGuwTuMRF1r
kCeUi06dhvoH77ABwhoiLJia436rAFUhc9VQ5wjkWwP3UlP9gZQ+lI/7QngUwusivD7CG8IvGuGN
EN4Y94e7UDuRQz5y2G9VByIgaZGIXQPPsxaeY23ccx3EiUKcugivB9RHnAaIg1ml1QhxGqN36ucU
MO0aQVVQD91i+ahHFdTDj3oETNvWx3VD04L5qEMV1MGvnwqJ0NMNtnOw9rr1ROjJmjYP1ZpjPDtY
mINeMAhSUwsS2Q06Rx4k8lroHDshQUMglVGQyvbQOXLQGwZBompBKrtB58iDVF4LnWMnpGsIJDMK
ktneqlJ4BK3QAq3QHK3QwooozEcrtEAr6Od5MVqiMVqiqVUH8aLgXxfx6uFcH/Ea4NxQ6Wd6MVqj
MVqjKeYA0CExLsRgFhGG2UNlMKPWV6PBHpeDMxZjHAgnFzphMnT7ZOj2ydDt20O37wzd/jXo9p2h
23eGbt8Zo9FE0Rtcfht0+T5qokkVh1RxSBWHVE3LSBVvUmmb2WuNb9HVd8VXnFXEiN6CiNph/GxG
V2K/iLrSLdSKetNt8L2d7qEr6D56nbpAi59CD1EczcXVfOxvUwKl0ju0DvsnlEGZ9F/awRh9ylxW
leaymqwmLWF1WAv6jd3IutE61oP1oA2sL+tPG9kgNog2sztQ5y1sOHuQMtjjbCxlsdfZ+1TAYrF7
2UTsPvYxdj+bzKawAJvPklkYv4hfzOrw1vwyVo+34+1YNO/IY1gjfjW/hjXhnXln1oxfz7uy5rwb
78Za8p78FnYR7837sEt4P96PteGD+CB2GR/C72aX83v5vawdH8ofZO35o3wku5I/ycewzvxV/gbr
zf/Dx7N+/H3+AbuLf8a/Z3fzH3k8e4wv4ans33wdz2DjeTbfxSbxPP47+4JjDs2+4of5UTaVK0Hs
e8GFYD8KKfxshnCFy+JEuAhns0UlUYnNEdVEDfaLqCfqs4WioYhmv4rGoilbLC4QLdhS0VK0ZMtE
K3ExSxStRRuWJNqJ9myl6CA6sdXiKnENWyu6iR5sg7hV9GGbRF9xF9smhosHWK54VDzB9ohnxDNs
v3hWPMsOiPFiAjsopoqpLF9MF9PZYTFLzGJHxM9iETsqksRajvFP7OIYbYTiNSyPFcYbWlWsJvxC
q4PVgV9tjbDG8Gussdb/eB9rqjWDP2z9ZM3lT1rLrWQ+2lplZfIXrGxL8fGeME8Yn+qp4KnAp3mq
eKrx7zybPBn8R0+WZyeP8+z27ObzPL97fufzPfs8f/AFngOeI3yRp8BTwJd6lM14gi1swZfbHtvD
k2xph/Nku6IdwdfZNewafKtdy47i6XZ9uwnPtJvbHXiuHWPHcGVfafcUZN9uDxIV7Xvt10WE/ab9
luhov2uPE1faH9gfiGvsD+2J4lr7f/YX4jp7ij1FdLOn2dNEd3uGPUP0sH+yfxI32bPtX0RPe749
X9xqx9uLRS97qZ0obrNX26tFPzvF3iD625vsbeJOe7u9XdxnZ9s5Yqi9zz4g7rePShIPSb90xeMy
UjYXT8pWsp14TV4hO4px8lp5vXhfdpVdxUTZXd4sPpK95O1ikuwv+4sv5SA5SHwl75B3iMnybjlM
TJEPyofEd3KEHCF+kCPli+JH+bJ8VSyQr8nXxWL5tnxH/CbHyfEiQcbKT0Wi/Fx+LlLll/JLsVZO
llPEOjlNThMb5Ey5WGyUSXKNyJVpMl38IXfJY+KwVI7HCjjS8VmVneHOcKu686DzsBXhjHAet2o6
TzhPWLWdp5ynrDrOaOc5K8p5x3nHque854yz6jsfOB9aDZ1PnE+sxs5k51uriTPDmWW1cOY7862L
nEXOIquVs8T5zbrYWe4kW62dlc4q6zInxUmx2jrrnHVWOyfNSbfaO7udPdaVzl5nr3W1s9/Zb13j
vdzb1rrW297b3rrO29Hb0bre28XbxbrB283bzeri7eHtYXX19vL2tm703u7tZ3X3DvLeYfX0DvEO
sW71feD7r9XL94XvC2uAb4pvijXQN9U3zRrk+973vXWH70ffdOtO30zfTGuIb45vjnW3b75vvnWP
b6Ev3rrXt9y3z7rfb/vDrLf9Nf31rVh/Q39za5I/xj/YmuIf6k+1Ev3r/Ds87fwFAcvTJVA1cLnn
lkC3wEDPE4FHAq95Xg18HJjq+SzwfWCmZ0bgp0CcZ3ZgTmCuZ25gfmC+Z0FgYWCZZ2EgKbDGkxhI
DaR6VgfWBTZ41gTSAts9awNZgSzP1sDOQJ4nPbAvsM+zI3AwkO/JDhxzybPL9bphnjy3khvhOeDW
dut4Cty6bj1PodvAjbbJbew2toXb1G1jW25bt6Ndye3kXmVHuNe4ne2a7vXu9XYdt4t7ox3ldndv
seu7vd3+dhN3oDvQbukOdu+0L3KHuMPsS9zh7nC7nRvvxtvt3SXuMvsKN8ldbV/prnXX29e5G900
u4u7xd1i3+imu+l2NzfD3WF3d3Pc3fYtYdeH3Wr3CesTNsC+O+yOsLvs+8M7hHeyHyTuna//Edm/
ryJRE4qiP2VTO9QOqgsQ5tClhReqkWqy+gauZ4DbVFc1V30O104Tuk1twHFrKO6BEql3aqhc7HuK
PcNL1gF4ssyadgW+O+F6s9pMmAOfMc1BYL36A84Axu3bodeTyiwOzSt2ZZeSdonaqnapX9Q6nJPU
srLqV+bmIM9FwdKwf19U5vFaFJe8G9iktqDV8lVv8pIH84p6xaGFZRWk8tR+9QfaJ73YS8LXXKmv
1ddoNf0EN5aaVpedidLz1CZcesiHNusAV9NQzVdSW4A0Sk0/WulvNUgNBDqqlupx9dBJLZ1V7CpR
PmQtAfKYrRLVMtRhj0oiOxSSc0rM5WW2wWZTe+2aHmqTXWoWtPlgaFqJ+Aex56ujKhkxr9X/0o75
mxWUTdMimcclJyj7J6XOVBlK/86KoL/q6yTzj+mQveIYe05Nc5p6n9Qq6stT7ujstuCzOmiO29V2
coAzl3oUOBy6aEmXnTHuBPUVjrnqt7Ouz4mps9QPOO4PttNJIaXyz0kxDqmftWzBNV/L6UlhfcpM
vRf4wTDS+lNTl72pd7Q0qSml9hrnLNLnqTjzNHLPteSi9Md59pzTvhE6Ly5H2jnmuLbUFrPLV5/Q
1rDMsvW4oMeXo+hfu84x98AZQ5sAN5sygqyYHtxDoaWNrU2xR2FvelINvzDH5OB+htStSk39hzli
BFYFJTmlOFahygEn5qDHFbWHGQHUZ+a4Hpy5GXxzFpsaT9XBS63pJrh/Mj77MDpnn77sk1K/hVEk
nK6jwXCbvo+0O9Xe0sbOU1LqUXgiUnupGj1W7LtIzSbP6cfVEj3Fg/u+D/7fmlA9Rhwt4nFVUCL1
0RPcr6PvRlJ9Ggv31cZnHmYxv6lppy07s3T/QpSjZqrr1bVqiLouFPeTEqlfCJ1PHiM5DaAXofcT
vUn/wbj6Nn0DKZ1KsyCNs2kuXWxWBNrQIkoFA6+nTOpq1gL6sMFsMD0GDfxmGqF1bxqptW56gg/j
D9C/oD+vo1F8I8+gZ6FFZ9MYvpPvole0Lk1j+UF+iF7nR/lRelPr0vQfrUvT21qXpndFlIii90V/
MYA+EIPFHfShNdOaSR9BC1X0saeapxol2vPsebTcXmL/Rkl2pp1FK6RP+miV1rtotda7aJ3sJ/vT
Jq130RboXXfSVq130Tatd1G21rtop9a7aJfWu+iw1ruoEHrXeEbQuCYyW34sP2VerXexcK13sQpa
72IV5VQ5jVXWeherqvUu1gh61zHWAhqXj/VwwpwKrJ9T2anKBjoRTg12h1PbiWJDnHpOA3av08hp
woY5zZwL2ANOS6cVe9h5yXmZPQYt62v2OLSpJPYktKmV7CmtL7GntQ7DntE6DBvlX+BPZc9rzYRN
CPQODGSztS7BftW6AYvXugFbrXUDtl7rBixN6wZsi9YN2FatG7AMrRuwHK0bsN+1bsD2at2A7de6
ATuq5/2sQM/72TE97+c8rEdYTy7D+oUN4L7wjuGduF7bXWskhhmJ4ZCY8ZiTTKBYyPOH9Bl8Pscu
6QuagjHoa8iTbeTJhjzNQW/7BVLlM1Llg1QthX8CrSE/pZC21ZSK3YWcpVEYbaJtVNesP9WjHbQX
/Xwf9vr0Bx2iBpSPvSEdpmMUTYWQyIpGImsbiRRGIgNGIgOQyOFUgT8AuQwYuawEudxE1fhmvpkq
8y08narzbXwbRfAMyGstI681jbxGGHmtauS1hpHXylxxRZUFJu5UBVLLccRGVSG7Em5HOBQpvJDj
KkaOa0KO+1MjMQDS3BjSPBjuOyDTjY1M14ZMbyJmbbYyiVtZ1g6yrWxrD/mtPGs/1bEOWAcp3Dpk
FVCUdQzSH22kv56R/tpG+msb6a9tpL82pL87VZE9ZA/yy5vkTWTJnugPHvSHXvDpLXvD5zZ5G0nZ
R/YhR96OftIA/aQf0vZHb/Ga3uLXqxTkyjvRZ8LQZ+6hevJeeR+Fy6FyKEXLYehFFU0vqmh6EUMv
GolUT8inEecZOQo+z8pnicvR8jmU8rx8Hjm/gJ7mR0/7N1KNkWPg/4p8BfFfRd9zTd9jes0Dcd6V
76HccXI8QmNlLHw+lB8i1UQ5EXE+lv+DzyQ5CTX5VH4KH/RP8un+iXwmy8lINUVOgf9UORX5TJPT
EHOmnAmfWfJnpI2TcWiH2XIeWma+/BX1jJfxaJPFcjFqlSRXoLYr5RrkmSa3IP5WmY6ct8lM5JYl
d1JduUvuQZvkyT9Q1n55gOrLgxIyKfPlYWooj8gjKPGoPIY6K6monqMnYw0c5jCKdrjDiUFMLPI5
HsdDrmM7NoU50pFU2cFGXgc7VXR8jo/8mk2otmYTHMEmOIJNcASb4Ag2wRFsgiPYBEewCY5gE5Sy
3FmOY5KTRFxzClmaU4hpTqEAOGUhjot88VRBMwsJMEstCgRqB+qQG4gKXE4VNMvAHyxDkWCZplTZ
beY2oypuc7c5ue4F7gVUzW3htkDohe6FFOG2dFtSLfci9xK4W7utEf9S91LEaeO2QZy2blu427nt
qYZ7hXsF4nRwOyJOJ7cTQq90ryI/mOta+Hd2O8Mf/IVjF7cLjl3dG6kSWKw7VXd7uDdRVben2xMx
b3ZvQYm93dvh09ftj5zBbihlsDsYxzvcOxFniHs36nyPew/yude9D+6h7lDEH+YOgxvcB39wH3wy
3O0oJdPNQqod7g7knOPuRJ673N1UVbMhCc2GVEGzIVUAY30bYsO3sItiNnwf7g/Bg8LwoAcs+A3c
U+knHH+mOMOG8+FeCA4UFA8eFODBFPBmKvhVmLV3aXhQGB6sYniwquFBr+HBaoYHqxsejDA8GGl4
0M/CWTgFWF/WF8fhDKzHHmKP4jiCjcBxLBsLHuzJexI3LOmAJYfgqFnSZ1jSMSzpGk6szHN5LthT
82BFw4OV+DF+jMIMA4YLS1hUEdznwO0TPqog+oq+YL1+ApxiuK+W4b46YqAYCP9BYhD8NQ/WMjxY
R9wp7qIaxTy4gwQYcD9JcF8BeQ3rRRrWq6pXVtFLu8luJAy7SfBabxw1ownDaB7DaNVlX9kXPprR
hBwoIcHgtcGIqbmsquEyr+GySHDZ/ejhD8gHcHxQPoiYD8uHcXxUPoqj5jVpeM0b4rXRcjR8ngOv
eQyjSfmSfMnw2suIr3lNgtfGwh1ktDfkm3BrXpOG14ThNa+cICcg1fvyA/hojpOG4/whjvtIfgR/
zXTSMF2k4TghvwK7iRC7fS2/hvsbifFVfiu/RUzNd8LwXeQJfCcM30nwXTzcmuOkXCIT4U6SG3HU
HCfBcZlwa3arYtitqmE3r2G3aobdqht2izDsFmnYzS8LZSFSaY6rajiuuuG4yBDHSXCZMFzmdwJO
AG7DSr65vnnk+Bb4FuC4yLeIfL54cJDPt8S3BD7LfMvIMXzE/ev8W4gbZqnsXgJOCXcvcy+nioZH
wg2DVAaDdIC7oxtDYeCOa+CjuaOCe4N7A3y6ut3AU5ovKhq+qAym6AO3ZopK7gB3AOJojqjs3uXe
Bf+7wRGVwBH3IgfNERUNR4QbjqhgOKIiOCIDeWa6mUiV4+Yg/k6wQ0XDDpx4swp6jebCHy6/mTrR
raebzf9/3tRW6J1ZwXUitaXkqkhIeyp1ra6MnNPVRpVn9MVFZv1hg/HNNCsJK0PrsjrvDKNFpqs1
ao2JESpLrT5j7qF1PDX03Gv2522qq/rRnEusPJcaeyu09F/PTts9Yz7bT3ajTbcXrQqq5WjVdWjN
TWqlWlsc6/jzq1Lst1LtUcmYgUcgRUhTDK42/i2br7geJ64/B+j2oF+J9bWs4GrFSX571Grca17R
quqfuwVXu9S6Ilk7sfwT64xalFhBP11f+pNqds69UX2m/mfOBajtUoMJajLOCaHw0FqHWZ08oFaU
tV5bahkZajskMbSGFXTp9ZHiVev3EL4ruEKttiH20lC7nlSWOnQWJR0qWjf7cze1/3hd1EG01QF1
xKxMn7S6c84rgf/AViSR6Nk5Z45ZFO8vrEuJdx1njP2DmqG+02v0VE19omYYv60q0Zw3Fcc649hw
mpzXgi3yVErwCcK1zvTdDWY8mmJi7DEhSXqlGvuO0CpjqCzTg2rS1aGreSpB/YIYkdQF54XG78vQ
CPYc0O/ca3jG2gdH6O+Kr+9Qk9SD6hXzJu3pYt/28EMctfdUJkd/LPGMMQIvUsv0KP0n1/Wg6T9G
8jTDlOznas/x9fEzS+i5Sc9fsJm3xeqdU98PqydKe5uhNoMzMso5X1qrU5kx2w1eG2+36KieNb6H
SQTfrBWn02WF0UWn5LYH+e0xeXhw3lrka476XWLqudfwpPyLn8uJOYXePmaGelFS6J3kSZJn+D/v
1LeJ+h39+dXoXLdT3/eVXMMP+Y8t1bccT/hsNzXmHCLXMSleVaPMWb9lno62nA4ejdPnUI5F43vw
nWzG6d88nKFW36ppGLOnhq6Wqq9DvXspkGjmGIe07IfqkaUSQ/0+WNYpX12ohajhAsPzLcBCP4R8
fz0pjtJsXY6aptCJb76DzJlu5M7kF5Q1U+/lJu6KolSk30itMOx6n7mar5aoR9Rv6kn1qYoFV4aY
Npgi5D6Iln68HLUcoR5XH6mH4VqmsuF6BK43oAV9pGahZSap+8Hin8BvjWmt6eq/QYkNlVUzOOYU
55atUsHnui+2xsgV6pMhnUDPYY4Y1zm/dzattftEli56xsattbuQ7mNK2aLfxgXfyIXKanH8Sfxd
24lfqOjaoWX+KGOU0VKw/6+uV4lSVbHroJnTrsU544wpFhT14XKW+JHqq0arCca9HPIySc017qxg
X9ZzI/US8H35yzC5XK+eP6/0GWo3YMYIyJ9mtWJtKjhbwZi2ETir2e0ZyllT7pQrQ2/P0823aZuD
X68YjtEj3tZQrL9d9k/d1DB1t4ov+vJIPY15S4JeMzGz3xkqH2FvqFGqhWqqpqgOePb/KjWXD8os
J/iNR/3zru+HJ139cL75naaU984zfSZ4OjU4rqLXbigRngXfnSrl+ArMP7OpZPSSjGAtMBtbX8q4
uB4SkF7+fvDnbKjDa3TC90EY7+b8k/UpuUGvejO4OmKunkLf2RHkzuL5wzbogW+ot9VhzIQ2lv5V
StntfLrvGv/czfA9pAL9/7x0v+Jvjv6CTW07sZzzG53VxedbmzLy3xKcF6E9z2tEOv+14TJLyMLI
WuYXU//0duZZ0DlsJb71PsvyS6w1n0WaPTrV8ZRn27PKU9bfvZ3vmmd53itAl9gRmkl5ivIoXukP
nL51TVmR9LD+5vycyyzPunfO8bcvxeUHv5c9VmZZnK479xL/ka1aeRIVjZDnlGaBTnV8/DffLe+G
ZlTGmm95yvprNuib+0/3BecJsc5Dj/vTNn8Z4dWo3/E3df/EpsdT9LCNZ/79gnnP9Dfr72f7i4rT
pI4LndNDiC8lUlPzxXaV8s2zzDfh6UUpgy6Doi/OgyW2Jzrlq/CTyipaiyxO/UUptdFflrfS350X
3dU51XOiisP+RejKuMw7jLjQXQRr0KpEPctRVnHacsyyofHrrxaKV7vN/PkA2WWtW4fK+otnoKVu
J/4GIdiLeRkpJHXQH3ud61au9x3bzPuO4pme6QW7yu5XobJqn+K7As9nhUqg6tRULQ6tlMaHVpAg
Qeqmc6/hGWuxxBxnFF/3UU9CRxynfx2gHiz2vVr95zQZeErJc/fZjBvl2czcKai57lNr0fdX4Jh2
whibC//fSa/bPWCufwTjDlCJuKsluKdEdXcoXuxJuaapm8tRl9vVzepjdUvoyrjUMOP6Rn2hRpjV
qbjg81WzsE8PPUVdVjVqad54PqWGGz/9PcPH0MQ/Vt/hqWfqdxLG/6R1F3VUTSxHPSeAmRYV3TFc
k3HUvzzTXzNlqmnqKzytBSbQ/P6qSLcPldX63Ev8u7eyf8l53iXsDPZXPIHDZcc+iy0S/BRJNXVr
Q0IBXNVBP0/EngCkqUvR5/pTuIo+qR7dCoOsEfoVq5qjVhie07+w1O/1Q3ri8f5c4k5+McenwKk1
jauN6ouyuqO/VFZtT4o5GuineqHvmG8AwEub1Qb1rfoMsrpT5YU0hebU2PDzBSbOgnNvCjUPM+Ui
CdTfrizAvvn4PEj1Nae+1Jva0uWmrOanlqUqKlK1lQQbLFIvqdnAaPWiOccVvTsMbWEm/shy1PNx
NVK9GXp/HoDrMexvwP9NE/q9gmahZuIJHNfV3fKW9SdtvIS7rDFRYh4lEDe+DFssfUO2WF6gG4yF
lSGsDmtODxjbKk8b2yqj2AA2gJ5lQ9lQGm2sqjzHRrGx9CJ7nU2gt7VVFfpIW1UhbVPlY/pEW1Wh
/7IFLJkm8Yt4K/qet+Zt6EdtVYVm8hgeQ7O0VRX6id/Au1Icf5Q/Rr/wJ/m/aB5/i79LC/hn/DOK
51/yqbSYz+SzKIn/zH+mFXwOn0sr+a88ntbwpXwppfLlPInW8hV8Ja3nq/lq2shTeSqlaZsotElU
EJVos7aGQunaGgpliYaiIWVrayiUoy2gUK5oL9rTHtFBdKQ80Ul0or3iGnEN7RN9RT/6QwwUg+iA
+U78kLZTQoe1nRLmajslLNqaZc1lLbSdEnaptk3CLte2SVhbTxVPVdbOE+Gpza7QFkrYVdpCCbtB
Wyhh3bWFEtZDWyhhN2kLJexmbaGE9fEo28Nu11ZJ2GBtlYQN1VZJ2CPaKgl7VFslYSO1VRI2Slsl
YW9pqyTsbW2VhE3SVknYZG2VhCVrqyRslbZKwlK0VRKWqq2SsHX2FPsbtllbJWHp2ioJ26atkrAM
bZWEbddWSdgObZWEZWurJGyntkrC9mirJCxPWyVhB7RVEnZUWyVhBdoqCSvUVkk411ZJuKOtknC/
tkrC62irJLyJtkrCm+svynlLx3VcfpFT0anEWznVner8EqemU4u3duo6dXkbp6ETzS9zmjpNeVun
hXMhb6ethvArtNUQ3kFbDeGdtNUQfpW2GsKv1lZD+DXOGGcM76xth/DrtO0Qfr22HcK7aNshvJvz
jfMt765th/CbnDgnjt+iLYjwW7UFEd5LWxDhvZ1kJ5n3cVY5q/jtToqTyvtqCyK8v7YgwgdoCyL8
Lm1BhN+tbYfwe7TtEH6fth3Ch2rbIXyYth3C79e2Q/hwbTuEP6Bth/CHtO0Q/qi2HcIf17ZD+Eht
O4Q/q22B8NHaFgj/XNsC4VO1LRA+U9sC4XP9sf7JfKv+9pz/rm2B8PxAt0AvwbQVEOEL/C8wVURr
KyDiEm0FRLTVVkDEFdoKiIjRVkBEJ20FRHTRVkBET20FRNysrYCIXtoKiBgYyA5ki0HaFogYHNgb
2CvuCRwI5It7tS0Qcb+2BSIe0rZAxONuDbeGeMat5dYRo7RFEPGctggiXtAWQcTL2pKH+Le25CHG
aEse4nVtyUO8oy15iHHakoeYEHZ9WHfxftjNYbeKT8L6hPUVk7T1DvF5eIfwDuKr8M7h14nJxMEe
Fri8Ddi2AjGqiF1QJcyaLYrAyOahWhQN/0bYJUao5pjbXABG84K72kOHuALjr586GiuRmt0Cht1c
sFtvpLoNezg4bgDyHkh30WU0BHx3OfjuUZTzGPa2NIKepMr0L+xV6Cl6lqrSaLBhNbBhGFU3v2eJ
YBXAjI3BjI3h04Q1oaasKWsG/+bgyqaGK5sZrmxmuLK54crmhisvAFeOoRbsFfYK0r4K3owAb/6H
LmRvsXHUko0HhzYzHNrMcGgzw6FNwaGT4Z4CJm0KJo2nGLaYLaZL2BK2jFqzRHDrpYZbObi1NY6X
gmFtw7BhhmG5Ydgww7CVDMO2MwzbxDDsRYZhI8Gwk6kWn8KnUA3+Nf+W6vCp4Nwow7lRhnNrg3Pn
4PgLmLemYd56hnlrgHmX45gE/q0N/l2B40qwcE3DwjUNC9c1LFzfsLAXLBxBDUWkiKRoUQOM3N4w
crRh5AZg5MY4NgEv1ze83MjwcgPwcgccO4Kd6xt2rm/YuYH5pU8H80ufjubXPR3Mr3s6Gqa+Akw9
mtpY/0fZ+cc1fZ19/+RLchLwG0SqSC2lDCmlFCmllFKkVNFSxxh11jnrnASEEMKvEEIIISTfhBCC
9fa2zsc6Rx1jljFnHfOxzDrnHLPMWeeco845Silz1jLnLLPO23nb+3OuMOd9P8/zx9O9rk+uXt9z
zvdHknPeV8a5qmC+VmG+3sr06lfVO9gT6tfUO9kc9TfUu1mm+lvqb7N5Yh5n8zGP/4g9JqpOMZrN
WZaYzVmEmM2hczVzWY5mnmYeSxVzOnsMc/o4C9N8oPmAPaiZ0EwwveZDzYdMrZnU/JFpMNdfQuQj
zUeIXNZcZlrNx5qPmU4zpZli94k1gM0SawDaTGum2WzN3zR/Y1FYCT5lKs0Nzd9xrpua/2BzNLc0
t9g8sTbgXJ9pPmMxXBQYeIqruIpFcIlL7DFRzwq+mqvha7iGZWP90DI913GZzeF6jm8Wn81nMxVW
lDlMx6N5NJvF7+Nz0WYen8fCeAyPwcjz+XyMHMtj0QarDpuNVedB9I3nD6FvIl+I9kn8YRbFk/kj
GDmFp6DvY/wxaBpPwwiL+CK0T+fpaP84z0T7J/mTbB7P4lmIP8WfYmqezbOZzJ/mORj/Gf4M+uby
XIy2mC9Gmzyeh77P8mdxR1jhcK6lfCniBXw5Wj7Pn8cIhbyIafgX+ItouZKvZFr+Jf4lXPPL/Ku4
r/W8FONXcTPOXsNrcZY6bsE4jbyZPc3tvJXlcCd344werrBnuJf72H28g/vZXN7JO3G1AR7EvXTz
TRjnFf4KRtjMN2OELXwLxv93/u84upXjEyVWWRYrVln2KFbZb7JFvIf3sDSstd9GvI/3sfn8O3wP
S+Vv8DdYFu/n/XjCe/le6Pf5PrxfWInRCysxFCsx2v+Y/xgjHOE/QQTrMVpiPUb8l/wkIu/yUyxd
rMqIv8ffQ/wc/z3iF/gFjP8+fx/nGucf4OwTfII9wj/kH7LH+SSfRHus3Gh/mV/GCB/zj9F+ml9H
y0/5p2j5D/4Zm68V/wfFo2ItZ2lYy+PYIu2D2ngWq31Im8jStQu1j7DHtSnax1gq1vhMlqV9UpvF
ntM+pc1mT2qf1j6NSI42lz2FtT8PbZ7VPouj+dp8xJ/XPo8xC7WFOPqC9gVEVmhXYGSx10wlyIA9
JsgACjKAggygIAMoyAAKMoCCDKAgA0b1xBjVE4OCDNgjggzggwxYliADtAQZIAIygIIMWLogA/Y4
yGAf2rype5M9BT54i+l1Q7ofoQ0oAb1ACYiDEtDyF7pfQE/oTiACVsB5wQpo+Z7uPbZId053Du1B
DCwNxDCGyPu693F0XPch/L/o/oKzXNVdZc8JhmCLwBA5bH74M+HPsFhBEuxRQRLwQRJQkAQUJIH4
l8O/DH9N+BqWDp54mWWFrwtfx9LCvxr+VfYU2KIUoxnCDeyR8LLwMvjgDLYInPENFhmxK2IX4xHf
jPgm/J6IHvivR7wOf3dEL4sWFILIryKmmBTx54hpxgWLMEmwCIsULMKiwSIvILJiloHlCiJhGaHd
cIJImCSIBAoigX5b/jZbIPfJfexB+Tvyd9hseY+8h8XJb8hvsAS5X+5nD8nflb/LwuQB+fvw98n7
0P5N+U202S/vR5sfyj+Ef0D+3+xz8kH5INq8JQ+hzSH5EI6+LR9mD4ByfoL4Ufko4mAd6LA8DP25
fJzdL78jj7B4+RfyCbT8pfxLtDwpv4sznpaxHsln5VGMDB7CWc7L56G/ly+gzZj8Pq55XB7HOB/I
E/A/lD9E+0l5Ev4f5T9izIvyRRwFObGFgpxYOMhpij0s/1n+M1ssX5H/Ch8Uhfin8qfQG/LfWbJ8
U76J+H/Kd1iS/BlSx4fBVREsST9LL7NEPf5BJFIfyRaDtOYhEqOPZcmCt1g4eCsO+qA+Hm1AXTi6
UJ8EfVj/MFsk2AvjgL3YA2CvE+x+/S/1J9lD+nf1uF9w2GmM82s97lp/Vn+Wxel/q/8tIr/Tn8do
v9f/HmcEnyECPmPJgs9YtOAzJgk+g4LPmCT4jEULPgNtSdIi4rNlxGcSkRmf4bAQgQnekom3xF6p
l6GCtJYTaRUSaUURaa0g0ppLpDWPSCuGSGv+PXuYNbSHWUt7mDW0h1lDe5jDaQ+zhvYwa2gP8yza
w6yhPcwa2sOsoT3MetrDrKE9zKFaDhraw/w87WF+gfYwz6E9zJ+nPcxFtIf5C7SHuZj2MMeqJNUs
dj/4Tw+NUt0P6lqgWgDqEvyXDf57keWoVqpWsxdVX1bhm0nM94zKqDKyp1TNqmaoXeVkuSqXygW/
HeS3GOTXDf8V1StoL/jvKfDfa+xZkF8PywfzHYS+pXoLnDek+imOCuZ7iZhvCTHfUmK+AjBfBgsj
5gu7h/bCQHvLiPY+D9r7AjGf2GWtpl3Ws2mX9WzaZX0f7bKeTUT4RSLCp6VuaRPLE9VI2UriwgVE
gY9KP5B+wB6RDoECP0f8t5D472HpXeldkKIgv4eks9JZxN8D7T1EO7cfkH4vvQ+m/ED6ACp2cadS
ZYsU6aL0J0Q+kj6CivoWcbS7O1H6i3QVvtjjnSR9Ik3DFzu9k6V/SLfhi/3eD0p3pM9YHO36TghT
hUnwxd7vpDBNGPID2gGeQDvAE8Nmhc1CZDaIM42IM4OIM5OIsyTsgbA4xAV3poUtBHcuCksGd6YR
d6aHpYalwsf/oE+EPcmeCMsOexp+TlgOeyzsmbBc+IJKHw/LA5WmhT0X9hzGF1SaRjz6JeLRVcSj
XyIeXUUkugwMuoPJoM/d4r+5Ce6MUfep32T3E31mq4dAn8+APo+zxep31KfYc8SgS+/Zl66hfel6
2pc+h/alFxOVFhKV5tMe9ReITXOIRDkxKCcGlYk+OdFnjOaq5ipY85rmE0QEcc4j4iwk4owi4owh
4pyvuaO5A2IQTLmMmJITU0YRUy4jppR4FJiSE01yosn5RI3LiBc5kWIUkeJ8osNlxIWcuDCGuHAZ
WPBpHBUUGEUUuGyG//J5Plou4UvQUlDgMuI/TrTHifA4Ud1yorpCoroooroVRHVziermEdXFENXN
J3qbz3fwHWwxf42/BgYS9JbDv8W/xXJ5L+9FXHDbk8Rt+XyAD7ACIrYsvg/Elsvf5HjXiNsW80F+
kD0HejuEyNv8MHuRuG0xP8qPopegtyz+M/4zxIf5MPr+nGOtIp7LJp5bzH/FT2OEX3N8r/lv+G/Q
fpSPoo1gu2xiu8XEdkv5GB/DCILw8onwsojwFhPhPUuEV0CE9yT/iH+Eo5/wTzCOYLsn+Q1+CxFB
eNlEeDlaSSuxF7XhWuTQ2mhtLFTQ3mLQXiJ8wXnPEufla9O0GWA4QXtLifZeItpbQoSXT4T3EhHe
Uu1z2ufY/doCbQFUcF4Bcd5SbZG2CGOK6gl6qp6goeoJeqqeoKfqCRqqnhBO1ROKqHqChqonaLRf
034NZxc1FDRUQ0FPNRReoBoKc6iGQjHVUIilGgqxVENBQzUUNFRDQUM1FPRUQ2HOPTUU9FRDIVQV
Rk81FGKphoKGaijoqYaC5p4aChqqoaCnGgoaqqEwh2ooxFINBQ3VUNBTDYXYe2ooaKiGgp5qKBRT
DQUN1VDQ3FNDQUM1FGZRDQU91VDQUA2F4ntqKGiohoKeaihoqIaCnmooaKiGgoZqKOiphoKGaig8
TzUUXqAaCnOohsLnqYZCEdVQ+ALVUCimGgqxVENBQzUUXqAaCkVUQ6H4nhoKGqqhEEs1FDQg9Xks
B4z+EDRB9wTLJxZ/Tlenq2OLQeT1LFfXqGtk2Tqrrgnsa9PZELfr7Ox+YvQsnUPXyug3PPgunRsq
eH2pzqvzYpyALgDdrPs36Bbdqxhtm+7raLNdt509qftf4PjFutd1ryMuOP5Z3Ru6N3AlA7oBtA9V
nRFkvxRkP4izCLKXdT/SHcIIb+veRq8f637Mluh+ovsJIj/XvYPrH9GNYARB9vdTlZos4vtc3ahu
FCoov4AoP1f3B90fWC5Rfhbx/WLdn3R/QuRj3cc4u2D9pcT6L+n+qruGXoL4F+v+pvsb2nyqu8Fy
if6fC88NzwXNC/rPCV8avpQ9G14YXsheDH8h/AWWT5lAbnhJeAnaiEwgJ3xl+Er4LyETyA3/SvhX
0F7kA0spH1hC+UBB+Prw9ez+8K+Fb0DLUmQF2eHl4eWIGMON7DlkBbtmMgGRA+xGDtBLmUBfRB8i
34v4HsuLGIwYhB6IOAA9GHEQOhQxBD0ccRgqqmbMpqoZs6lqxn1UNeM+qpoxm6pmzKaMIoxyhi/O
KptlYk/P2jrrNZY3a++sY2wl1dRQUxahRubQCDoXucGjlBs8In+fcoMfyIPgbJEPPESZwKPIBN6C
PyT/CCx+RD6CiMgBPif/TP4ZIj+X3wGdC+5fSNz/KHH/I+D+M4j8BvT/CNH/w/J78ntoL7j/UfkP
8hiOvg/ufxjc/wFGE9y/kLj/ISL+z8l/kv/E0uSP5I+gH8sfQwX3ZxL3l8h/Bfc/Ll+TpxH/m3yd
pRP9P070/wTRf6b8H/J/IHJL/gd7TL4t30bLz+TPWCagUgWOl/RhLE2v1qvZY/oI5AbplBVkUlZQ
oo/Sz8HRaP1cxEVu8IT+fv39aCmygkz9Q/oExD+nT0R8oX4hRktChhBHGUK6PlmfzB6nPCFDn6JP
wdFH9YtwVNQxSaUKSSn6DH0mIqKmSYI+S58NX1Q2SaLKJglU2SSVKpskUGWTB6lCUpx+mX4ZVFQ5
SdU/r38evqh1kqh/Qb8Cvqh48iBVS4qjuicPULWkOKp+kkTVT1KpWlKKfrX+y1QzaS3iL+tfRkTU
Q0mmeigP6jfoDTgqqqKkUlWUJKqKkkxVURL1Jr0JR0VtlCSqjZJAtVES9YP6QWRBIi9aiLzoF2wB
8iJ8HvS/0v8Kmc9p5EILKRd6grKgEmRBf4A/ph/HExO50BP6Cf0EfFFjJYlqrDxANVZSqcZKMtVY
SaIaK2qmemA6TgGKymGb2AeMGawwB8wN88M2wbbefVVZDXjdAeuB9cEGYPthB2GHYcdgI7BTsLOw
87Bx2EXYFOwa7AaTfAoZM9wmk3wB2GbGyiQYpu6ySNhc2AJYAiwZlha6rrLM0DWU5fw/XvMx1ja8
Lg8Z9SmCrYStga2HlYeut8w081oPs8GcMCU01syr5NsJ2417N8Jq4e+5GwvZXtjgTGwIdmQmPjxj
J2bsNGwUdgE2Abs00/YKtWdlgdB1iOdUJp7FNnrmobbTsJuI7YSJtntge2GDsKGZc9+ZudcjsGHY
iZl7Ox26ng71jEUgNgq7gPuxwhwz/cXYE7BLsCuwaZg4J8YtV8PQrzwKFgOLgyXOvKb8q315Oixr
5jVipl/WPcdzYUtghbBi2CrY2n+9ivevfAOsAmaGWf4v//7fX6UOcU12mCt0b+U+WHDm/f7/MPrM
32PlW2ZsO2wXrBfWD9sHOzATF6+HYEdhx2En7+l/hkzqEM/rHGwsZP/HeSaFqeeUmhuYZ3eZzjIE
jbQcIR2GzrWcgC6wnIYmWEahyZYL0DTLhGe36OVNLcu0XPJmlFoauGdPqb1B9uwty7FcIZ2+6+db
bnr2iqPe7FJXQ7RnsGy55Y5nMOTPqK8h1jNUVtSohq5sjLjrF5G/pjEKur4xBlreGAc1NSZ6hkQv
bx40Hn6wIclzpKy+MQVqa0yHOhuzPEdE3FtQuqUh1TNcpjTmQgONS7wrSrc3ZHhOlG1uLIRuaywm
XQXd2bgWurtxA3RPYwV0b6MZOtho8ZwQvbwlZUONdsVcuqsh23O67Eijy3O6tLchzzMq1LsaWuC5
UDbc6IOeaAx6LoiId13ZaREPHS3tb1jhmSjd11DiuVQ22rgFeoF0onG755KIew2kxtIDDas9V8ou
Ne6CXmnshU6Tf7OxH3qncZ/nSrm68QA0ovHQXY1qPOqtLY9pPO61lh5qWOeZLo9rPOmZptFuzkQS
G89AU4SKiNdRerTB4LlTnt54DprVOEYKX8S97tLjDUZFXZ7bOKmohe/1lx5vvAz/ZEOtElG+pPEq
tLDxOrSY/FWNt6BrrQy6wcqhFVYZarZGkx+rRIi+3k2lZxqsSlTpuQaHElNuscZD7aQua7x3a7nP
mqTElI41uJW40skGP64haE2FbrFmkAp/uzUbV3K5YZOSWL7LmndXe60FSmLp1YatSkqNvS2bNI+0
AOpqWwH1tZVAg22roVva1kG3txmUFNGra7xmV5ux62Lp9YYdSnrprYYeJaumt60W2t9mJRX+vjaH
kiWOdk0ZWEOfZ7TmQJsbeqihr+taSA28YUDJrTna5ifdBD1O/nHyT7ZthZ5p2wE919YDHWvrU3JF
r64b0P3w5YaDypKaybYB6OW2/dCrbYiIeNdtQ3TDYaWw5nqb0Fttx4KSIbbhmFJcy9pGhNbmkX8K
ytvOQuW289DotnFobNtFaHzblFIsegV1tUlt14KRhniDUVlVm9p2Q1llSGoYUdYK7YgypDacUjbU
ZrTdhma7JGWDiHSNhOIzmtFwVqkwZDecV8y1eS7dXS1wRSpmEQ/OJV1gyGsYVyy1K1xzSRfc9Utc
CdDVrmToOlca1ODKhBpdOdBaV34wodbqWu7NMBQ0XFTstQ5XUTCZRnPNRNyulVC/UBHpOmxY0TCl
+Go3udaQrv+nL+LBNENJwzUlWLvVVa4EhR/MrN3hMgVzDKsbbihbanvw5KGu+rt+n8sGHXA5oftd
CvSgKwA97NoMPebapmwRfYP5hnUNt5XtBoNFUnbVjrh2/g895dqt7DIYLTql11BriVT6a8+69pDu
veufdw0q/QarZa6yr3bcNXRXL7qOKPsMDssC5UB5v3UFdJ+1BHqA/EPW1dCj1nXQ41YD9KTVCD1j
rVUOiF7eHeXnrFZvj8FtSVAOGfyWZOVo+ZjVAZ0kvUx61epWjoqj3j7DJkuactywyeoXKvzy69ZN
yphhqyVTOVl+y7qVdAd0kvxJ4W9k1h4ot/ZBZesANNq6XzkpenkHDDssOcoZQ48lXzm3MdZ6EBpv
PQxNsh6DplpHlHOGPstyZWxjBmm29ZR3v2HAUqRMbsyzniU9Dy2wjiuThgHrRfgrrFPQEus16Grr
DRG3FHkPblxnvY2IoUnyHjbst6xULm80NumgtU2RymXDQcsavAtQ77GN1qa53hHDYct6tHc0LYC6
mxKEWtZjHDfFSQ3HLOXKVcOIxYRr8zclK2PlB4Ru3NSUhieDuPfUxq1Nmd6z5J83nLLUK9c37mjK
Ic1XrqM9dGNP03JoX1MRdKBpJXR/0xrowab10MNN5d7xjceaTN6LGMem3DL0NdVDRyxO6FmLgusZ
abJBTwkVEe+U4bwl4GUbzzY5oef/pRS/tnG8SfHe2HixKeC9bRi3bPbyjVNNUOH7JMN40zb4Fy3b
6L52ku6GXiP/RtMe6O2mvcpYhdQ0CNU1DUEjm45A5zYN497RF/c7ZdnplQ3XLLu90RULmk5AE0iT
SdOaTnujDTcse7yxhtuWvd74ikxrCTSnaRSaT7q86YI3vkyyDHqTKoqaJqArSdc0XYKub7ri0wkm
8UVWlDdNg0/ABr65Faamm56hivqmO1CbTR1awX0LxDroS6hw2iI8VyoUW5TniliJfMkVAVuMWJVs
cVCsNb60is22REVdsc2WoqjF98WXWbHTlo7vDj63vpyK3bYs5WTFHlsudK9tiTJZMWgp8uWL99e3
vGLIVqhcN5yyFUPxHHxFFUdsq8Qzsa2Fhu502LYBesJW4Y0XK05wee2Ua1hJETN/sKj2muuEklt7
w3Uaets1OjM/rxSzXHBNneS6oFgMea4JqJhn1tfpXJfEnOO6AsVMEiyvi3RNK/11c103lf6K09bb
3oMVozazb2XFBZvFt6Ziwmb3ra+4ZHP5yiuu2HyevRXTtqBnsOKmbYvPhDbb0eaObZevvlJt6/XZ
KiNs/T5nZZRtn0+pjLEdAF+dsR1SoirjbEd9gcpE23Hf5tIx20klrjLFdsa3rXSf7ZxvZ+kB25jn
SmW6bdLbU5llu+zbXZlru+rbE+KNyiW26769lYW2W8oWQRS+wcriZuYbqlzVzMW70Cz/c2WvXNsc
Dd3QHAutwLUdqTQ3x/uGKy3NSb4TlfbmVN/pSldzhm+00tec7btQGWzO801UbhFMW7m9ucBzonKX
YKfKXkEplf3NK8CuxI2V+5pLoAeaV4PixGfjUuWh5nXQo80G35XK481G33TlyeZa382yaWp5ptnq
Ga481+zw3akcE+RWOdnsxlkuN/uhVwWjVl5v3gS91bzVc8LImndAeXOP54pRbu6DRjcPeKaNsc37
ofHNB5UIY1LzYWhq8zGf05jRPOIZNmY3n+pQG/Oaz/qOiCfQEWEsaD4f+mx3RBlXNI9jnJLmi4ra
uLp5qiPGuK75WkdciDCNhuYbHYlGY/PtjhTxvehIN9baJVA6WL0jizTXaLXrQgTesYS0kLSYdBWd
ZS3pBqPDHukZMrrtcz1HjH77As+wIOqOCuMme8KMbya1iO9Xh924lZ4keLjDReoTV9URNO6wJ3cE
yd9Cut3YY0/zTBj77JngYVBxxy7jgD0nxMAdvaT9pPvKU6wZeFb77fnQg0IFtXYcID1kPGxfHiLV
jqPGY/Yizx3jiH0lFHFETtnXhKi14zjpSdIz4lvfcY50LKTGs/b1YFEQacek8by9HOQJLu24bBy3
m5Q440V7PXTKbgNz7rI7wZbifblKet14za503Cq/bg/g2y1m5jHjDftmrJ7X7Zg/jbftO/3M0Gff
LVYE+x4/r5Lse70jVTr7oF+uirQP+aOr5tqP+GOrFtiH/fEzczvN3lUJ9hP+pKpk+2nMxrfto/7U
qjQxE1Zl2i/4M6py7BP+7Kr8JsmfV7XcfslfEGKAqiL7FWWyaqVYZarWiHm7ar1Yo6vK7dP+FVUm
+01/CVZnrLZV9fY7WPUwa/lXbxxoUftXV9msW/3rNha0RCiXq5wtURhfoXXZ3xKDcQItcRh/c0si
dFtLClbz/S3pGHlnSxbOuLslF7qnZQnOu7cFc2DVYEsxIkMtq6BHWjD7VQ2LlaLqRMsGv6HqdEsF
nglYwnenarTF7Dsi7s5vrLrQYgnNtP7aqokWO8a51OLyxosV2W+tumIx+R1V05bNfnfVzRaf3191
pyXo32RSt2zxbxXPzb+DxumpON2y3d9nimjZ5R8Qc7h/vymKaAfM4z9IevifVGNJ8x8jHSE9RXqW
ruF8SE0xLb3KGVNcS79yzpQoaESQiX/clNKyL+RjvRORi4I3/FMbjdbb/ilTesuBEFf4r5HeoLu4
bcpqOdQpCb9TR5EpU27LUeWqaUnLcRAFuKIz0lTYcjJEEf5x0hHSs3gvzii3TMUt56CrWsZCK77/
ttDOuaa1LZOhVb5zgWlDy2UvM1W0XIUijoi55bqXi6fXmUCaTJom1qnOTKG4a1KTpeUW1m6s4J05
JruDYaXGOt6Zb3I5uDfW5HPI0KAjGqtYkSPWmyTW6M7lpEX0HEZMWxzxXm7a7kjyRpt2OVK98aZe
R4ZywNTvyO5cWbfAdSdoqktoVwd665LbI6Bp7VHKhrrM9hglqy6nPc4zWpffnhisR5sUHF3enh60
1RW1Z+HoyvZcRNa0Lwk669a3FyIbSmovVtbWlbevCiqG2Pa1SnGdqX1DMFBX314R3FxnazcHtxny
2i2Kpc7Zbu+8UKe0u4I76wLtvuDuUHZgKGkPKsG6ze1bgnvqtoH/99btbN8eHKzb3b4LeVxte+8/
ObxuT3t/cKhub/s++IPtBwIRdUPth4JH6o60Hw0O1w23Hw+eqDvRfjJ4uu50+5ngaN1o+7nghVAG
Wsvax5BzhTIdyinqLrRPBidCWV7dBCJL6i61X0bOJdb6S7Xr2q9Cx9uvB6/UXWm/FZyum3az4HDN
pGhpiHZzpbDuplsO3gzlWTV2d/TdfJZyzLo7Iq9EJtgjMj537N2zG9zxUMqV6tXuJGRMoRznIHLM
LfUR7f0dKTXX3alKYX2UOyN4pz7GnY08C0+gW10f584LsUp3RH2iu0Cx1Ke4Vyj99enuku6o+iz3
6u6YUD5Yn+te1x1Xv8Rt6KZ8vDulvtBtRE6NzLo7pFn1xe5az6jIoLtzSZcI9a4mv5DOUhzS+lVu
q5JbvxY515L6DW6HUijy3+5V9RVu94y/lnSD4KXuipkniey12yzUN1dcVefcerPb320Rfred1FVv
cW9SKurt7q3IXpHDdvvqXe4doYy1O0i6hXR7rdvdgyfmc/dBg0JFjtlxXWj3rvot7oFQXtndW7/d
vV/x1e9yH4Qijkiv+3Aox+zuJ91HekBQXPch0qOkx+v73ceQOSJ/7D5Zv889gjwRWWT3mfoD7lNK
b/0h91noUfd5PPPj7vHgEL0v50jH8Km42OGqP+meUoL1Z9zXlF3159w30HLMfVtJMe1z5HWuodyB
1iOauxKUMdMBR0HnetMhx4rOcsMmR4nvjumoY7XI7xzrOk2m40LhGzrrTScdxk4btPaunnFYO52m
cw5Hp2IaQ69zoZzONOlwdwZMlx3+zs2mq45NndtM1x1bO3eajor5U6j3vOmWY4dfFtlZ527SPRvX
OXqUyWrm6OvcW80dA517DYcd+71T1bLjYOdgdbTjcOcQ6RGaJ4dncito54nqWMexztOhPKs63jHS
OVqd5DjVeaE61XG2c6I6w3G+81J1tmMcmuG42HmF5sxp0pvVeY6pzjvQawF1dYHjRiCieoXjdiAi
tKZUl7RKgagZXd2qC8RUr2uNDMRVG1rndqRUG7EeJVXXti5QsqqtrQmBxGpHa3IgpdrdmhZIN1xr
zfRGV/tbc7xy9abWfMUn5kl/j9BAVpmE1RB+63J/T4jcjMbWokBu9dbWlYElBn/rmkBh9Y7W9YHi
6p7W8s41pjOtpk5ndV9rfWegeqDVFlhVvb/VGVhbfbBVCWyoPtwaUDZUH3OsDlT8t9FGWjcHzNWn
WrcFLNVnW3cG7NXnW3cHXNXjrXsCvuqLrXsDweqp1sHAluprrUOB7dU3Wo8EdlXfbh0O9Jql1hNQ
XevpQMWMRraOKgfMc1svBPrNC1onOkfNCa2XAvvMya1XAgfMaa3TgUPmzNabgaPmnNY7gePmfKc6
cFK8v4Ez5uWG24Fz5iJnRGCs+rATc755pTMmMBl678xrnHGBy+b1zkSf01zuTAlcNZuc6dB6Z1bg
utnmzA3cMjudS/wZhlNOMIZZcSLPMgecq7qYebNzbRc3b3NugO503OiSzbudFR23zHucZs+oea/T
0hVtHnTau2LNQ06Xkms+4vR1xZuHncGuJPMJ55auVPNpS6AjxTzq3N65zXzBuasrwzzh7EXLS87+
ruyZs1xx7uvKM087D/iOmG86D3UVGDZVjyjHzXecR7tWGI45j3eV1KidJ7tW10Q4z3Stq4lynusy
1MSYF3QZDOedY13GmjjnZFdtmeS87E2qSXRe7bLWpDivdzlq0p23utw1WW2sy1+T28b9cs2SNt61
KZT11xS2yV1ba4rbort2CHrp6hGU0tUnfkXpGgh94+gXjNWCKLxT/+PbYQv9VhD6ZaBrf82qttiu
g2J97zoscvCuY+LT2DUS+nVIzA/e8zVrHasxPv1WU7OhLd47YDrZluQdmPn1RvyuMlVTYUnuOlW9
tS2162wo668xt2V0na+x4LssMYnNV11TfcKY6lPVDSapbqn+wdSqzyQV45JG4ixcmiXJbJYUJc1h
emmeFMNmSwukB9gcKVFayO6TUqRH2Tzpdel1Nj9sRdjnWaxmpeZLbIHGpWlncZp3Ne+y+MiKyAr2
UKQx8ussIXJHZB8riXwj8l321cjfzdYw3+zI2Znsh7OzZuexc7iaVUxNuycj2WwWzuaw1WwWW8PK
2Yusgr3C1rN/Y1uYn21lv2UB9h77kJ1kf1RFsN+pZJWefaaarZqnUqkWqFJUOvFXjKr5qnWqKlWc
qloVUKWqgqrtqhWqnarXVV9WvaX6teqrYW+Gvamyq23qZlWLWlH7VK3qoPoVlUv9qvpVlaJ+Tf0N
lVf9LfV3VH71fvWgqls9pH5btVn9U/VPVVvV76h/oXqV9sdtV59V/1b1mnpcPaH6hvqS+mNVj/qv
6r+qetWfqv+u+rb4mzbVHs18zXzVdzXvc51qgM/m6apR/gR/QnWdP8lzVJ/ypXy56h9iB4DqM/5F
XiKp+Ur+FYnzl7lRiuQ1vF6K4xbukhK4hwelRfzrfKf0NN/F+6Vn+ff4oFQk/tZeWsUP8fekl/h5
fl5q5Bf4pGTll/glqY1P8SnJxT/h16V28VdTkpf/J78jBcRfTUlBraQNl7q1s7Sx0qvaB7UJ0re0
idp06TvaJ7RLpEFtsbZFOqZ1a1+Xrmh7tb1hsrZP+90wvXZI+3bYfeK/9xQ2Xzus/XlYnPYd7amw
ePG3O2HJ2gntH8OytH/SfhKWo72uk8Ke19XqboatDn8mvCrsw9lLZy9Viz1RtSwIlVm82B1cIMEi
/4u9r4GOqrzafc/8ETAOSDHGGNIYYsSIiBFTiilQDCFiMjNJI1KkmAZy5sxk5sxk/sNHKVLKTSml
SDGlSJHFpfnSNI2YYowpUkoRaZqPIsWIfFwujRQp0pSLFCmL4t37OWfCkMRK1/fdte5arXs9z3nz
nvfs8/7svd99jjMDIY0wTeSoJwqXFZUX7ldPFbaqZ9Xz6qXHe9WrPkPh2fIZvjzfFN+0WVN8hb45
Podvrm+Br6q0qXSPL2nWSZ911oFZp31jfGm+TF+Ob0Lpnll7ybZMZOnnYel/EZL0sfSxMJBdj8J3
Scfi06HC8BPDT4Rk+Knhp3Ruh+FlYTS8bnhdmPHpUIvht4bfiiR8F2i44XeGI2IEPheajE+E3mr4
veH3worPgo40/Nnw5/i/62OUjFL/v2ZmNlpEijHZmCxSjSnGFHGnMdWYKtLw6c27jOON48VYfEco
w1hgLBCZ+HbQ3cYZxi+KLHybIhuf3LiH+p8sjcbMMQt1hliqzlCLVMrB1HnqQnWx6lb9akSlzEld
odara9UNhE3qVrWR/nKrLWqb2qHuVvepXeohtUc9rvaqZ9Q+9aJ6xSfUiz6L2udLVrt8yb7RvlRf
hi/bl+ub5Mv3Ffhm+opvkP0+m6/CN99X2S+yz+ML+GIJssy30rfat45qGxKk23eY2OPb7Nvma6Jj
XFp9O32dxCx7fEfpqmK6xwnfKd9Z33m66hJpvOpr8Bt8Hn+S30rjl4a30RryJxjIiihq8JykkhhF
OolJ5Ih7hVlMIBkmHiThz3dPpfhSQDJCTCO5RRSKWfiG3RMUe7Tv1n1ZzMd36xaSvsUknxEKyRgR
FCFxu6gTS8Qd4uskd4pvkKRRVHpO3CW+TzJWvECSIX4kGsVnxU9I7hatJFniNZJx4uck2eJ1knvE
r8Q+6l8XyXj8K333iaPiXZEr/hfJBPEeyQPifZKJ4oL4kPp+WfxVPCSukTwsGaRhYrI0giLgVHym
+1GKgKNEAT7TPU3KkO4W06Vx0jjxGL7ZV0gx0SFm4V+wKpK+IlWK2VKVVCWewOe7S/DNvlLJI3mE
TfJJPmGXwlJEOKSvSStEOUXQVWIexdBviS9L35bWiKelddI68RV8v28hxdMO8YzUKXWKRdIe6Zdi
sbRfelPI0q+lXwtF+o3ULVyw3xqKAqrwJNHCCR8+Q+dPiibFRC0+NxdMWp60XISSViatFGF8zyWC
T8lFkxqT/l3UJf046cfi32htT4tLsP18/qUVbwYhm5BLmETI11GgYyahWDzlzfbmeid5870F3pne
Yq/NW+Gd760klr0eb0C94I15l3lXeld713kbvJu927xN3lbvTm+nd493v7fbe9h71HvCe8p71nve
e8l7VTWoSaqVZIyapmaqOeoENU+dok5TC9U5qkOdqy5Qq1RFvayqakhdoi5XV6lr1PXqRnWLul1t
Vq+pO9R2dZe6l+SAelA9oh5TT6qn1XPqOZ/JN8LH30cwmD3mIG2F/9O6nSzWQPb532XfpSQjYeWj
YOW3wco/AysfAyu/HVaeAitPhZWnwcrvgpWnw8ozYOWfhZVnwsqzYOXjYOXZsPJ7YOU5sPJ7YeX3
iW6SXNj6/bD1CbD1ibD1B2Hrk2DrD8HWH4atP0K2bhD5sO/Pwb4/L42VMsju2bILYNlfgGVPw3cW
psOaZ8Cavwhrnglrfoys+WvkA1+Xvk4+wN9cmA1rLoY1z5G+J32P/IFtugTfWSiFNdtgzQ6pm+y4
XDooHRRfSnoh6QVRkbQ1aat4MumlpJf4O7mjlo9aTeuUTHN/i5CCR4TwNBFaCTsJnXrdHsJ+Qjfh
MNeZbvM0B1vU4r8PtLGF53h2BNs87cEOteJGcJ1nV3C3Op9QGXYwPHuD+1T574PbeA4EuzwHg4dU
z3Xw354jwR41QIiF53qOBY+ry/4+0GZleIHnZLBXXR3s9ZwOngHOBfvUdYSG0CmUN4er1G1hxXMh
eNFzOXhFbboO/N0aVj3XQkLd+SnoDIfUPeElXlPIAowIJXtHhUar+zVwmcemdl8H/+1NCaWqh0Op
fATSQxnq0U8Ht/NmhbK940O56okb4Z0YmhTXmwjv5FC+euo6vFNDBTeDwJG6Ud4ZoZneolDxkCgJ
2RiBY3UpDG95qOKmMC8037swVDkIi0MyI3AyYvK6Q56bQeB0XbrXHwoAkVAMWBpaxgicq8viY+2p
WKa3J3TUuyK00lsfWj0QgQt1471rQ+s+DYHLdROhY0OoAdgU2uzdGtp2AxpDTYPQEmq9AW2hnTeN
jlCnd3dozyDsC+33doW6B+FQ6PAN4HHfBNSz4eXe46ET3t7QqSFB59Tz4VXqpfAatDsTOntT6Aud
914MXRoE1nc1dMJnCK/3XgldvRn4ksIbVRE29MMSTooD562EMeEtKKeFt/syw81qctiK/g6ALye8
A30YHR7zafBNCLf78sK7Eq9XU8NpNyAjnDkIfO2U8F41O5zjmxY+gGNh+OBQ/fkkqLnhCeqkcN4g
5IenqAXhaYMwM1yYCN+c8JF4bL8hFuuxMh7jfI7wsXgM8s0Nn0yMI/12kriu+pr0z9GC8On+ua0K
n0vsE2LJNYop5PtBkxYDgiN0Hya/Co4KreN9g+09mEJIr5sct+dgFh3pPnzep4Qv+NTwZV8ofM23
JGLi/cW3PDKC63lsvlWRUb41kRSOr771kXSOk76NkSzflsh43gN82yMTObZjzGTvvubI5Hh89u2I
TPW1R2bwuH27IkU8F769kRKOnawTOBAp9x2MzPMdiSz0HYss9p2MuH2nI37fuUgEeyTvQbwn8Bxe
oH1S3898l2n/ic/ztUiK3xRZyjr4nH9EZIV/VKQee098r01Yo36dDH1Pie8F3CfeG/0pkbXcN396
ZEP/OnN7Wjtee+zLtOfx2PxZkU1c5x9Pe/gODbxf8/zegL3avow9i/djuk98L+YjQPaDsQ3YY/nI
8E8MXmTwHhvfV+PwTw5ZGPE9Enumvjcm7pU37JH6PhmHfyrtg7TG2PtoP/TPCE1iwG55n5usoT9m
EfxFka04lkQa/eWRFvgYxQ//vEibf2Gkw784stvvjuxDPfkw7x/wW/Ij9ie/P9Llj0QOcSzyL430
wC90P4jHRbYt1sNxzr+C4lPcR3i9KG7x9fEYOMi3BvhVPL70+xbroLjpr48cx5qvjfTGr0d78jf/
hsgZ/6ZIH/fbvzVy0d8YucIxHDGJx9ASFf62qAXXfVoM0vvl79DjeDwuXU1oo/cZYx0Qj/vHQ3E4
jk+MdZ8QT/279eO+cA6PKY5BcTIxVnJ8jMfIhHiItWc93IZjE82Bvyu8Nzi+bmpwYt0MBuc2vN6c
0wQn1xWhjmJWbXF0ZXBqXUk8fwnOqCv3X4nmI45R3hEsqpuHnIJiWm12tNJ/MTopnhMES+oWIqbx
/s95A8e68rrFvEcH59W5gwvr/LX50UBwcV0k6K5bGvTXrQhG6uqDS+vWBlfUbUBOpsdLvha5WTxv
4pxHz1GgS9eBPtbXbeJ4iX7Fc7t4Hua+HoOBeA6j5x6si/Ox4Nq6rZzvBDfUNfZfz+15PPw354Kc
c9HYgpvqWlDHeWMcep54AwbmgnrudwP0eR2Y1/WDc7E4BuZ18RxtiNwsuFXDp+ZmnHsl5l+cc8Xz
rsQci/vK13Kb+JwM9C3yP/+haPIgv+qJjo7nWP7j0VR/bzSDY1F/vDoTzWa79vdFc2FP8Xpuwz7H
9kfHWhEtqLVEZ6KcHC2uHR21MRL9rTY1WsExojYjOp/tszY3Kg/KYwi1k6IegOyRAT+kuFVbEI3h
ODO6LO6D7BO1tujq2oroun7/I7+qnR9tYH+rrYxurpWj22o90Sbee+JAPKJnLPgfjbk2EG2tjUV3
QjfFj9pl0U6MU29fuzK6p3Z1dH/tumh3bUP0MMei2s3Ro7Xboidqm6KnalujZ3n/YyBOUk5QuzN6
vrYzeonjce2e6FW2U94La/fHDLXdsaTawzEr5utobEztiVgaPyfUno3l8DzVno9N4Pa1l2J5tVdj
UwKG2DTOATn+x2NzIClWGLDG5jBYH/YZfh4aE3PwvAfSYnMDmbEFbGeBnFgVYhitY2BCTMG5vJgK
HVNiIY7lgWmxJYHC2PLAnNiqgCO2JjA3tj6wILYxUBXbElBi23l+A2qsGXGMxh8IxXbguCTWzvYQ
WB7bFVgV2xtYEzsQWB87GLcfzsE5/whsjB0JbIkdC2yPnUS9HnMDzbHTgR2xc6yf/STQHrsQ2BW7
HNgbu9Zvq/HngPgeReXAgToTtwkcrBvBdcIgJGu3tQe/o/iv/4/yz/X/Uc6JC9f/b4BTFh7nauc6
Z4Nzs3Obs8nZ6tzp7HTuce4n7nYedsq6rAOOOk84Pbqccp51nndecl5VDEqSYlXGPDVZSVMylRxl
gpKnTFGmKYXOlc5lmihJDGWO4qA6yNyTylxlwVPjlSpnTFEUVQk91aIsUZYrq5Q1ynplo7JF2a4o
zoAm1KJZ2aG0K7ucMU2oxV7lgHJQOYL+cY+4JZ/jO9Id+G3/refJwh//b3kbWkoeYie5DW9DR+Nt
6GfwNvR2vA1NEYpwizuEhyQN70TvwjvRsXgn+lm8E83EO9G78U50HN6JZuOd6D14J3ov3omOxzvR
+/BONBfvRO/HO9EJ5HndYqI4SPIQ3onm4Z3ow3gn+gjeieaL98UfxefEByRT8Wb0UbwZ/QLejE7H
m9EZeDP6RbwZfUzKkDJEId6MzsKb0SK8GZ2NN6PFeDP6ON6MzsGb0SfwZrRE+pr0dWGTnpWeFWV4
M1qON6NfwpvRJ/FOdC75+6viKek16TUxH29Gn8ab0a/gzegzptWmb4tK/BJdlanD9JpYTN69X8im
M6Y/CoW8+BLNpSRiYtl1W5Unizx5sjxVniEXySUk5fI8eaG8WHbLfjkiL4Xsk7vkQ3KPfJykVz4j
98kX5StO4bQ4k1nkFXK9vFbeIG+CbAU3yi3EbXKHvJuF7cZwP9nNA7rdjMb92WIMtEb3kvWwrZho
/vPIethWLLCVYWQps8iG+M35cLKO+WRDbB+3wD6S8bb8VhpXDVkSW8MosoXnyJ7YDkaTFTSSPbEF
jBEvk9wOC0iBBdxB67+P7Jbfit9Ja/4uWRiv+l1Y9XS8CR9LK39WZGCNM6VRtMZ3Y3WzsK7jsKLZ
0jNSpbgHK3ovrahfjJcitKK5eNd9v7SGVnECVvEBrOJEvNl+UHpV6hCThJSUn1RwfT2q6023VdcP
FPmofKJ6bfWGuMinqjfpsnWgyGerG6tbNJHPV7dVt8mXqGaAyFedhuoOkt0k+1icSU4rHbuqD8XF
Oaa6Z7A406Chp/q4Lr2aODOrz1SfcSYR9w0WZ071xeorcZEFt9VEtuiSPFA8qZ4MebScGhdPtpyh
S/ZA8eTKufF7eSbJLELOHSie/JosOZ+E71fA4imQA3ScKRfHRVk8WDvpnwkN2f0za9PEUyxXyBUe
G/H8weKpoPFVxoWuuv6fRxfLQHFOcOZRn2JxcU7R66ddn4m4OAvlZfLKfqFWdI/VN4pzDsEhr4M0
yA3OuXr9AmcVHTfHR0Ry3KnI2waLU5WbSFrlnSzOkNypiXOJc7lzlbyHVn2NvGfwSKjP62mO9vdL
t3y4Xwo0cW5k+3Zuge02Orc7m2FjO2Az7bCoXaRnL8a72nmAStyjvdCvaSJLcbZjlXI98z2VWK1K
nn2lhyfaOcd5kHxnrfMIec4m5zHnSedp5zk54LxAc1XsvEy2vNt5jey9RzEpI+akkC33KaOUFCWd
jlk0o71ygP4er0yUK5XJylRlBvWY7b9PKcKs7VZKlJLqXm5R3aKUK/NIF3stRoSWmq+wbfZWtykL
5W3K4up6xU31Z6jdBvK6M4qfSmuViLK0epOyQqlX1ioblE3KVvhymyZKo9LC/qq0Odud7UqHspu8
tUvzWGWf0oW70Z2UQ9SbHvZJ5Thp7lXOKH3KReWKS1RfdFk0/2MPlC2uZNdosrUA7M1CZ1NpnRtc
Ga5sudWV65pEazxF3uPKlwuULFeBa6armGZ9Na2AxWUjK2Wba3BVkMyX17kKNAskwVqh3TbYDNW5
KgmyvM1FFu8KUP1hV8y1zLXStdq1To65Glyb5XVKimubHHA1uVqpzU5Xp2uPa7+r29UAG7e4DkPP
UdcJ1wmy4nbXKddZ13nXJddVeTNLdYvb4Gp1J8FWd7rOuq1yp3sM2ynxHneactyd6c5xT3DnyTb3
FHm/expZ73K2RHehe47bQRa8n/6yOFd5ZHm0x+MmG5EzPAGKtgWemLzNs6y6jyxYpihgqemgSJHt
WVld4lldHaHRdroaPOs8DezXZDM0W57Nnm2eJk+rZ6enkyyUIgdFgwy2Adni2ePZQy32e7ZV99XM
cB4gXRzvYMFoiSgDC86SJ3m6qy8q9RQND9MZmdqlkt9UeI5SaTTPgpyhRDwnPKdc2zxnPec5Cspa
/JvEc4U56/RcUno8V70GinMztVjnTfJa+W58J+8Y2eZN42hGXOFN82Z6c7wTlBRvXvUZ7xQtciF2
eZQe7zRlqdxZM5574p5L2tl2Ot0L3FWyxa2wUG+zqN/ZbpXtwx1yL3HZ3Mvp7CrYhE1e7V5Dsp5W
fLN7o3sLrdt2d7O8zb3Dletu52vd7XKTexfZTUV1j3uvK9+tkuxyH1D87oN0x2wa90nF5DwpV7iP
uI+5T7pPk/f0us+5LziXV1+UC6o3uLKVeUoK9awVZy67r9WYXNk1I2pG1aTUpFcfp12gQW51b5cn
1YyvmVgzefEB5xHaaQLOyzVT5XzSXFAzg9oXybaakprymnk1C2sW17jJanPJGjwU6wM1/ppIzdLq
SM0KObumnvyY4m7NWtdOGmGq3KCkk41sqNkkF9dsrWmsaSTvsZHOlpo2+RTZzmqavaYnT9fsllfW
7KvpIj5U01NzvGaf3FTTW3PG5anpq7lIrVNqrrirKPW1uPI9gnwl35PsGe3Kd51HNvXAv54z/+me
MxXhxyccUvjfaliUIaRFlWLMojSSTJKcRTkLbAtsiyYsmvB0z9M9i/IW5fFxwfwF879a/9V61E0h
mbZo2oKVC1YuKiSZQ8LX5ZM0LGhY5FjkoPsYrBusz9M9RuG5RuC5xoAnGiMyXxOeaMx4lrEg8x2G
Z5kkPMsMx/PLLXh+SUbma0XmOxKZ7yg8udyGZ5bPCGnU4lEqxoTPIFatF1JVMx030nGH6bYnRlVt
vxmU7KRjCiH9E5CloWS/hifG3yQmEiYPgakaSk7QccbNoeQsHYt0lOgo11BSrB1LDYQkKs8jLByM
0jF0XPzpKM0k5FDZrcNPiAzAxCGwdABW/AOoJ6wdAhuG0MvYNABbbw5lPPeNhJZPQJuGshkanui4
Sewm7BsCXRrKeN0O3RzKeG17dBzX0auhrFw7OubQuhdQ+QyhbzDK2AYufjrKFuo6rmgoEQTLACQP
gdEDkPoPIIOQPQRyCZOGQP4AFNwcSh10nKn5x5Cgc6VzCQv0drabRAVh/hCYqetU6Fh5cyhV6Sgn
wJOAeJsl+nE5YRWVA9fvlYjSNXo59ukoXU/YOEDHsgFYOQT42i10XE3H7fqxeej+fCLWERqGwGbC
tiHQdCNKd1Rdj9+J8TYeL+NxrP16fCnddWP86LeTxHWNr0t8jvYmzO2BG/vUH1MSY0Dch+P+xXuG
bvNl1IcbbLpSO196kHCEcEyLEby/lJ7W6nlMpecIF6oQX6vWaHGy9FrVdpupCnuAbUSVFt8Xa/Zu
4znR47ON9jRbujZeW5Y2D7bxWrxknQwb6yVbsFFctNHc2agPNtZbrs9vfD65/7xPxvewkoR5Zj1u
TQefs9F+YYvo/Rq4TgPWqH8/ia8Tj5X7slTrm21FwvWL9fXjv3lc5frY6vW6lARkDYGB+/LUITCj
6vr+mrDH9mNeAgbusfH98r+yT9ZX3bgXbqi6vgcm7Hf9MYtga9GPtG/ZOvR6ih822pNstAfZaP+x
HdLryYd5/4Df7tD8yUb7jO24FotsvbpfxP1Aj4uwrS49znkSfOSCFrf4+v4YONC3BvhVf3yJ+9YF
vf99+ppfTLg+pvmbjfYmu9D6bac9yc57ULEek2gMdtqD7Kn6dZ8WfwbG8aHaxPs8RDzuRyABn3Sv
T4unqwdgYJxMjJWbq67HyMSYOFO/tkE/V6DF6DKyn7INGji34fVGXrNJryNbsbdSmeOYnr+UUW5k
r9TjGK1pGedEfVo8s/Pc83zpOUFZmx7LeP8Xepxj+6M9uoz0lZE+O/W3jPMfzmvIzspYJ+cxZ/T4
qcdLXDu16nredPx6HIUuXQf62KfFS/RrYBweEIP7c5h4HOZxsi4+TzZVdiXh+ovaePB3i+4nNLZy
odc1JqBtCAzMBbuGgD6vA/O6fpxJwMC8Lp6j/Vdys4yqG/Ov3KrreVdCjsV9xbXZ1+dkkG+R/9nz
B/uVvaCqP8eyU729WItF8XZ2m2bX9grdnuJxbLfmV3bdv+wUV+y639nJx+wxDYn+Zme/4vqVun2u
qxqcxxDsDTo2a4Dvsf5t+rHpug+yT9hpr7N3JvgftbPv0fzNTnu0vZtwWNt74uDx8jMWzxOP2X6U
cELXTeOwn9LHqbe30zOd/TzhEuFqFWKRw0CgZziHlTBG2/8YiJOUEzjSCJlaPHbk6HZKe6FjAiGP
MEWbL8c0QqH2nOBwaPPkmKu1d9De4agiKFoOyPE/HpsdtAc4QjrytH2GbduxRJt3B+WgjlWanTnW
aPPI6+hYr5/bqOvYosVyB+WIDsoPHRR7HJSPOSgPc1Be5aB8ynFQm1/HET2O8fiP6ceTmj04KBdy
UA7koD3CcTnBfuienA84KBcqo1yobIRer8fcMsoHylL09SM/KaM5KqMcoGx8gq3GnwPiexSVyyZq
bcoma3X4ZEaS9ZZ/fTLjn++NmSnXtI//76qhS7wkxLBMQg5hAiGPMIUwLeFYSJhDcBDmEhYQqggK
QSWECEsIywmrCGsI6wkbCVsI2wnNOnYQ2gm7CHsJBwgHCUcIx/Q+nNTvefoTjucIF3Rw+8uEa0Ik
mQgjCKO0viWl6Md0QhZhPGGipqf/OFk7z31NmkqYoY05qYhQQignzCMsJCzW7pfkJvgJEV3/UsIK
Qj1hLWEDYRNhK6GR0EJoI3QQdhP2EboIh/RjT0L744Re/dihX9ebcP4MoY9wkXBFkLMSLNePPD/D
yZOHjyakEjKG+HvgMZuQS5hEyNfm8h/ChBsxvEDHTEIxwUaoIMwnVOr1fJQJHkKAEEu4fpmOlYTV
GgbdYx3wUunW0sbSltK20o7S3cC+0i6LpfRQaU/p8dLe0jOlfaUXS6/YhM1iS7aNtqXaMmzZJLm2
SbZ8W4Ftpq3YZrNV2ObbKvl/WwMBWwx/LyNZaVtNWGdrsG22bbM1lfbaWm07bZ22Pbb9QLftsO2o
7YTtlO2s7bztku2q3WBPslvtY+xp9kx7jn2CPc8+xT7NXmifY3fY59oX2Kvsil21h+xL7Mvtq+xr
7OvtG+1b7NvtzTi/w95u32Xfaz9gP2g/Yj9mP2k/bT9nv2C/bL/mMBFGOEY5Uhzpjiwu4+/xjomO
yY6pjhkkRSQlJHzkv7lcTsJ/zyNZ6FjscJP4SSKOpY4VjnrHWscGxybHVkejo8XR5uhw7Hbsc3Q5
Djl6HMcdvbQz3DnkLzEI/ZcYkvBLDCPwSwzJ+CUGK36JYRR+iWE0folhDH6JIQW/xHAHfoPhTqts
jYq7rHXW1eIB64+trWK6tc36qphl7bT+Qjxh3Wd9Q5RZu6y/EV+yvjNSEk+ONI40ieUjrSMfEivw
qwyN/x/3TJJGS358dqWT/73tcYd0kJePI68eR948jrx4HHnxuIsJZQZ5NDkj6rLJm7OTtfrs0TpS
dZDXZlPDbPLabPLa7HytbXaB3p7ryMuyi3VdNr2+Qsd8/b58rlL7O1sW95duIkn0KOYO9qkEj9Kk
369Kj9uSyS8Ee1dpG/wr0bvybTZaq5H4BQ6B394w4Lc3jNaYNSZM1m9b1wiz9bvW74lh+B2OZOuP
rE20Di9ZXxZjrR3W10SmdY/1VyLLesD6a5Ez0jDSIMaPNI80i/tG5o3ME7n/j7VL1542PUa8whwk
vgVlB8rDUX5Iry8mnmwOob4K9d9HeQ1xnvlllItR1q59CGUHrn2QeCLX/+2ySYUevnYE9GeaHiZe
YH6aPwdlXoL6mcRF5jDxBrR5ke/7tzYu/+0/0YcG1P8Q5YfBk3Hfh3VmPbPNtbj7TJT57h+b7qdy
IdpMA8/SR3c/2vjQw8fQ/8+j/wFcxeXhxkvoVTqPnTZimjczXzUWo55v9hJ/Qdc2EuVHoJ/rk1FT
bJ6O8mMoay3zcV/ypmtJKBeiPMI0FfU8LoH6WXo9lwtQLgLfgpZFmJ//Y3qUyg+Ya9D/qbiKy7cY
L6DNRJ4ZrFeZ2YNr12CuuJxs/CN6dSfxGIzodp43GnsVytxS4vq//Qmr8CfMqoT62eBhpiYeNfg2
8Gzww2h5i2kKuJz4czx2Q5lZ5v+bba4k/iaPxRBBeTr4KM+8YRm3kQzg59E+j9koo83z5kXEjdB2
G9dI73BZ+hBnn0P7WWj/XZTHQM+H4JNof8X0G6o3mN4gLjcdYf1clv6MGtn0DnEBtxGXmKU54L+C
X2c2GtHyceh5kttL70FDE8o/xdnZaP8x2ueifBq8F/wK2n9gItszlJh/RWX4iMFi/gWVr3G9VGXu
Iu41kS0Z0riN+MD8LPFfmKXTeg2xMQ960sDpuLYa/Bz4DtPHOPtVKv+W2XAc5V3gQ+DnTQt4dSwf
EH9H53ZwM7ge3Mc8LJXueBWz/Spavmrh33HZgPJ0cK1ebgbXg/nax9HyEs72co1xBGp2oGartu5c
libr3A5uBteD+8B81eNo34prBTjP/APiIqz7X1Hzps48lkaUj4LP6eV2cDO4HtyHloX0NJFtroeN
KcRfRfvHwA+Bh4PvAT8H/gv4Vzq3g5vB9WDW/HvM3ne5jfGX4C69zGP8ENc+pTNfOxrldB6v9IG5
m8pjwVP18g/BfvAz4DfA50jnHVj9y2g5mlk6q/OzsKi9bGmouQYNo1kDld9A+Vn4Tjf4DbBW00lt
HkGv7jbvgwWyhuHMVPaDn0HNW1T+EazrJOz2JS6T9XbDj7jeS88kkmRnG6b+aOPiEb3Jlm9IR006
atLRw3SMMR39sXFPyNpbaKRLMNJvQHMr+Dnwa7oG9rggvOkOy+1UMwX1adCcBs1p0JwGzWk8e+SV
rL8ZLY+Dz+tlai9tgf5D4D697Ee8wujAP8OMdWEsrwzju9SCp8OqZS4bR6Cm0fxzth+U74Hl3IPy
WMsXiCcx07pQbyXUiI+h2YazJTi7C2cP4exr8PE2eGgOOBMe8RCi6zct44m/jvr3EQ8vorye903p
D4irt2rRmFuKS2Yn1X8GEXUl+N8wY0vRZgJ88G2UPwtu0uOwi+qh33AneBjzMFiO5UWeHzOiumkZ
j8XSzWXLDIzr+/B9GX4xApb2H8ymEvjRZdTEdC+uh3ewzg5zG7HX1MrxBOM9iLE8j5Zl8L5vWDja
34ryV7hM0YbjSTnqG/WIxOXb0OYplJ/TPBft/4Cx7IPO9dA/DPf6DiJSL/hB9KrMfIZnm5l2H2bN
Ep6xHCXegpbTUb6E9jv0SMhev1iLZlxv3Ih52Iizb4IfAz8FHg4eO6wY3IK7c02UrYiiCpeLwAXQ
fA/Kj+g7zhYqp8Iv3kJNJviY5S62HOwmL8KzbuUdRHoKe1OUdwppBbP5CjziMl9lLoCPf4waGzgH
XnCRNRjvgH+NwV42adgUWB3bwE6sl0DLD+Bxj7IPkrV3IpJo/Aa8mM8W4mw1otBPdG/l+omo34td
rIT107r8ApGQLWoSdsw29OE2jMjIIzI+jjZ/QM0hE2WP0kzUzMU8nLV8RHwJV1UiRs1FzWlErXst
b/POyz0n1iLqs4gtfK/t4OfAey33Ev/K8h3i6fwvzku/ReQ5jrO7dPajh1yusNyPs+cQVTgW2bFG
iuUt7hV6+0POFqT/QM6QhnX5G+pfxqqNZRba/t7LuajBYWL9B01W4jOc3RnuZBZ9uGMQ4w1gjFs4
DhgfQgy5j9mYaaIaw6+h+QW0/AE0/2+UZ0NzN6yim3VKc7i3Ygf6fBb8lHkE1fwVeUg5ND+KlcqF
noNaZsLZLGVQXF4HT1mNvO6syY3+s62Ow9lN6PNbuNdb0JbGYzT9jufBjNkwfcRsjGCVU1ib8W0u
mx5FuQgj7UP/P0IE+wh+nYbefgCdu7iHxskY9XC9t9yTLJQnmOjJRXoTo37VRPm2OI++HcC1O9Fm
qsnDEQNXVXA+bKgw/ol4g2kWaZ6GFdxpWsy2bXiBykeg7X2dWduL0POIPksmKr/HTPY2VnC+SjNg
HIZ5+HdcFQCvgyWcMfHstaLmx1jx8dD2NHpoQzmMGfghZnsmRurGte+Dj4OfgO/3YiwrzItRHs5W
wTupwHqJLdDpBVehtxXQaTE3cDzRLZPHG+b7ihfQ5oolm9n8Ifht8OuozwLPIQ2HtCydW9I+yDzV
/A5iPpeLtLwdet4Cvwk9b0LPm9Dzn2gvo73MNQY/agpQY9PyfC7TTvch+G3w66jPQpnb36o9C+Au
r2uMbPNx6HmcrzU8ifKTWpn1EL+O+izwWNSkw67ewEyyzveg7SK4CfxTcIuJ9+vZ0DkbOmdD52zo
nA2dszFLs1mzMZdbGnMxA3uhYS/Kr6D8Co+CZnUL+s/8M228XKa+bYGeLbjqQ2jgmino50c6s3e8
buI+lJsfhBfz6jxr4j10j/48xXd5w9QDX8bzFLcU2rPPKTwN3YnnpmLwr6HtTui/BO4Bt+DaeeAi
XNuB+vfB3SayW0sWj8vSzGxycxvTQfNrFAFwL0vAzDvgAsyVHzPwV7S38qxamuHvD6G3b8FO3gOv
05/s3sHq7IdNvoNVewczA/tk76MZyOGVMt9BvBlPkQa0zEDLt1BeibsXaPaGtfgx1xiNWCkj6h9H
+/fAH4GbwPvxvNNkOY27cM3HvC60vlw+rTPWGuUOzXK4hixhDlZwDlacntyFbPwdPYNPMt9CHLF8
m57l4Y9/e8+8gdq/gLyui+fE9HneiUzVXDa+DP4e6ps4ezS9iGiJ9pT/c/72WVz7BPK3GrT8JT+h
m97k6G3EE7fxSTPFQNMonP0ZrvoR87C7UJ8CDVfBLWhfCTtZxmthfIXn1ngC5dngh5lNmbxGpizY
Rj3a/wIW9S6zeTvaPAyrSOOWxm9hZf+Eshtn78PZVFhLITRoT/ct4GLcazqylxexJxbxjBnfw85S
j2i5D7vJfs5qjFuRP6/F3rSN2bgUNd9EdtQHPbvBR8Bvg9+FnlPgg+Ao9qx3sfN2MJt/ifIysJbb
X8Le9D+QFd+P/PBdvdwObgbXgzmnfZefOs1nMf+Po2Uy+POWLxNrT6NLwa/p3AyuB7OGl9ESWbfp
Fa4h5hoH15gXwioWIGuNgp8AP49nGT8yzwCy3CLk242chZpyYEU/xx3R3ljPEdWEGmIeyxnov0fn
dnAzuB5M2sz38dO65RewnDfNKXTVLdC2FbwI/A50jsEM1KHcrnM7uBlcj7M8ujqeMdPrXB421vID
8DzWj6tMOvMsvQX9LTwbxunIBpfq/EOwH/wMGBbFGZ1lBFb/K2hZxBHSfI/5TSr/2fxL4h+gvkdn
P/gZ8BvgB9nqcHY/avaj5lucCRv/L3vnHqdTtT/+tffaez8zj7GewRi3oSH3+z23JCmShG6SLq5J
g2GEJCRJkpBKQpJKQiWVy5BKlCQ5KlGOpJJEJEnmme/6vPc+r198v6/X6fzO+fOcXue9P/uzPuuz
1/qsz1p7r/0883hZ5qlzD0/gFeCFcCTPnNns3ZrzTFubZ+Zp5NVI8naaPB+6l+H5NeS75FnXXUnb
vkL/lfjxrqD9e0XjlYs4D+bCW6DMsmrSKu882acHL4SZL/PCPYC3InABTwvjmU0Z7NCHMgvmUvpF
xHkwF94C38PGxtOrKFfx35Y3wJZiw97fUuTwPcZJorTbX8KMqCClIdmPfyc7bu+gaPx10hLvDeSj
yB554mE/xv+RUQgp++6PZd9toyFZsc0bT9skYxXyalq+mtJwLW0Ni/gZlkrGyy8TdLXyQtH7Fcnk
r+Bd0Yoq608+K+oMbKZg/yLz7ifmURHW1Wasw3OQ18o6bPPK1vI3MC6b8LmKlXYmngfhrRbyG7Jn
926lNBfLfGHKOsnwFPZo/hN4Tkq2xMI1/0N2PZOZoYeYQa8zO9jp2/kra8gyPLyAN+Xdb2vl4+dN
aZvHHtyuVDsZC7mT9mPHnSey9XAE7mReH4E7ma1H4E5a+5qVeW/prSJKZ+RJQD/FGrUZerRtrezE
vWfhcKHmvZDeEkySux6zeAby69g/TV3egurJogkGyGoQ3IH+bez3wWvhguCkMNZD7nfYPCeZEyuH
nAkb4e0M9rw19eJyj/CKyxs5r55flvwR2ZW2+Ydl9L3izJ0x0buyodwr35c8Eb33TbRblx3WEnZA
zZnX7eVOEevA2H3KSLUUOYj7RW3pKe5cq2W/bLNX1oR2UhrrwP1lgcwmu16tge+xLq2BciftyL67
Fvq96PeiP4r+APov0PfE21dcJdyXjeH+uBOuluv6+6RHAe+x9Qp24gu5081mP/6u7LvtKncLEf6N
Nsu61Fz24EFRZv0RZvd6ocfbTrvO1KMlwm2UFuHpqEjQkvWwgLkwjxVDSsfCydHqIbU+Z914S/bj
1mYO+jm0n/UqGGflN2jzpV45y2eEXjbxf4We7mF0RmBzfWQpmgrsiT6QPnrFZAet2a3rcE+3iz3d
+6zJdxOHLMa9Trj7JltK+3YtClKo9RvPCS/LPt0f6Nn9hTeNNXYwdQdTdyryYrmWewFX7M24PM3e
8AF2vjuZCx69e1j27F4tWngjluxwNe3xJyKPkT27HoIc2gzCQ1N4kzwv2edGmY+rvVJyR6Bt35Ph
4S77YnKgPb2up/Ntj3qIn2A4HC30FnjLWDNlLlwisj/KH0WrJJLXYKNYtdaxjvlSqvPk/uU7+Ekn
8qtp4XOyH9e7kY/KLl43QG4vu3j9En1JSEt85o53vVfGaubT/vH6qOU4bXPAOySfrwXP8kzYS3bx
tnfSnnKyl9dT8JkXUWJYFF4v+3d/NbxB9hH6D+l7kEkEOrIr30+tW2X/rksir6f0BO35gRauQH+M
T3+yJTJBda7eGt5Cf3Ng0+jZUu6nZai1Vfby7t9kL68fID5leD+5jxb2gh0ZnQcZxytk1GzeWrrL
0GTRzjnsYmbAi0KZHcoMZtkMdjozZFdlS+1OxK/GE/UGLO+Dr/v3sxKKbOAVIfFwBR6uwEN7LI+w
16slGq8Wms/RzPFGyZsKdsqV4ST2y1ezX76aXVhz9ndPyl7JZoK1dwdg+QVXzOTJsw7e6khdrx3y
vSHR3CveLNehrwTLc0+3kfE/oXcDPbsr1HPx2Rz/Ye9aw7tl72nbTy/wWQuftejpEXp6RGLlXS+e
g3b+DnifZBEeXglJfHojdyAOFwWdiJXwKvbvu2X/bnvRSd6JeZ9w3U7MoD14+AVvneQ+Ja2ya47w
Ka+K5c3eBKsfxVrKftnur6X0QZiFprU30cq5nrStDhpWWq88Y/ETPCbUW4T+NqFXB94rdf26XKUk
Pi+HLeAivE0OY4WHo7A6Eb4LDpK1LrZZIpDSmXieYt93B58mDBI5FnC/6yWlfjUivAXLdsj9RI5t
Fm8pneWZxE+yH2xOv8LcaMYot2Nc5iJn4KEVNi/J+wF9q8TfK8sovEJuVJT7l/5OeqeXIacjj8Vm
L6xDrUowg9HMlLr+QhlxfxH6Rli+wCg/KLL7E5rmQVMoO/eBWJaR0bR5cj9roHA7PpciV6HNGcTw
btFby1O09hQzVL6ZMKTwReWo6oUfyDccCpfJ5/hwELwBtip8wbJPYQ30k+UbBeh7R5YvwoV4GE2t
0WhKwxmWz0QelnPF5egPyfcoCpfCr6grHFy4y/Iq0btdC+UNah14PxwBL4K74Fih4wrVCTQNoRLq
/siPwedhsUiWTyI+p+4vaGbAS6n1CHIGpfvgaTRcxe2G5ihy6L8VVz8Jv6D0d7gObxqby+G16L+J
ZGnDYjTL0LRHLqRWTeTv4Dvwdfgjlp2QTyEHyElYOimfUOxP1pRnRdqDvZohGh1GJguWFY1Dr53r
4cfov0TOh9uxCaPXNXmx9dAY+WqR3YtgDlzAVbYjK6Ftg8h94GPw+aQ8tW7A8w/Y3APfpvQp/M8O
+4hcCnk6NklsKnKV1chZtG0lpZ9geRD9fVHvsClMsX5Gh3HAsmNU10ZJnSJW49A3THamj/b+7hYV
qgPIk+HtQudT+Cv8HZt3kZPwDJYruHpVmA0bwO9pYZifM5G/hWWTbS2vQS7BuE8MM1b07nLk2knZ
rX+K3AI9OePGhAF5GIwUeqvxUCCRCQaJ7G8hEybTx32FT8mnpdg/FGYO3mbSht+w2Ux8usrMtTOu
NLNDOB378wrsk4/zBz29AHaGObBd0oXZ0juhjaSwE6Vj8dxJNDZPRF8dfUOitwuehPulVNektA98
DI6kVtXoWmL5HHwb/hLJYnNLUt5g5yGXEL0eSulWeAIPTehR6XBciADj5ewOR5DIPB3ODuS+2Kwk
qjvCtUhi6+0kwuFqkIGcQiTfwf6dZBt564X8GfoReLsTzTyhDleG38nnU0R7BqXkgM128VmMuj8S
/720P6AvW5DLIh+U+Ns8lPjvgwcjfTZ+smnDHFoo2fsyXA1/RB/G/yF4LewFx0Vy6FM+KXgU+5Xo
B0HGSP3MnDpE3ObBjwpLWBbQxziaV5HLMyvzyYou6LfR64OUlqHvPxYutpo2lOahn0/EmFO6AXJD
PJSVOLs10Ifz7gN4Cz774aEfPlehKY8crq5hDmylPd8TZ1Y2x2OkWuInXI23hWtXYSOJIfKWcB3G
cgqW50frsFzlE/TMcW88M3Qz8m+F7W07w3vZQta6TyVKXkvky9Afwc9vyKzGbipkVXQrhSsDNpvh
m7T/5WQTS+5WzvvYrAzXDcg6484iSq2x2QnD1Ylsd7k32aja/Y5mhXFegMNguCJVh0/AO9EPl3HX
PdBcBweSz3dR+i58Ee5nRkyIZIlGeC/rSS1WLbd3eI9jZAPGojScAbPhx5D8cbi/OK8KVSHyWnga
D9ujMRKZ2DpHkRvDzsRtI3LRMMLIl8NrkyelndS6GZ93w6VYtkP+kvz/hPzfxryoA2ugX4TcDPt7
8cMdUCXJEO7RzgFiXgabdeQMsl0P+VwMeSn67sjhGk4OBEvIq3TIvc/nSSmogLdwNTufdr5eOFc+
BcNDYfIh+mjpbKJ0XRgxVv5urELL4M1hLrHy7KYvLozDvtEaLivDa6y3GWha4e0kK89GSvcQjafh
umjFEHviZmM+h/aEcjb3aLEZD++GT0ZyWJpDhEUuif+PqHsKmznwdTRdeEf6K28Xs5A7B6/ZaKdF
nzrJN3nG8m2oAt6Q1/DzJbuE7hI+rX6PfTTv2ZxvPflO1AZ2l3xy5LYLisjKwKdR20R230Y+7u1i
383nd7LXKDzp1lfyrjsudzfvdrnXe8/KExFypndM2i/0Au95qznOdydOC51J1Oov9HfwfqYsTPfG
yFzGQ2OhO9/7gN3ZMT4JlVq5sBvMxFvSK2stV+i7LTfp/bJmIo+Qv6Vyuwt1N71X9phiqdYLHUOt
TUJvl1D31A9bzWLqZslbEXcFdXtSWlXod6HWbrgFToEHtHxCtFtLzHvr0dJ+eS9hvYmmhd8DG9kF
5ItGLRBZrUQzC/m02Hsnsd8udE7oDdI7PVvWcyznC701yONhFpr91Doi9HsgT4HFYfdIY1vl1hdZ
Z0pr1ePUHSjUo4XOIlqiXUfon5DfVEJ2XVc0znpK5ZvtjRwb5+QffKuniztFVgl5X+Tmu49Ij9wH
pP3uczLfRXYnuZMkM12522aLvfMynCbUD2KzzuX7Y+50y0f1g5avIk/XL+BH5GJYruaKfaj7LHID
GHPls+wCrn7aLSGz2yUH3NK0M12y3eX7CW5gNRe7CZndbjXZ74i90xl2FapfhVrjoQPernXLyFrh
fozPUP5G7ikiO0ux7ISHJHXPQ/4Ovu3YHaWzkjYccuRTxbqOvJW166XVnHHk8/EC54TcHWRmOSeQ
O3oZ8uTg7JP2CJ2L3UzLEu4qua8531oPZWFxWFdovVmqb5Cnw+LOXiz3yrxG/tIZLXcWfH7s2p2F
M8vZY/XPE+dA2uNm4ed7+CvzfbZSdtxzPVuaXBpkIH+NXFRkPpdfGFyA/mXR+/Km8ZlgkWUP2A4e
FuqDcJnQT0N/Ruh68GE01bG5SRh8jmVN2InSSsi9kbtj+R0a9N4UYawCcjVK34In0HAV/SFyP+Tx
sAuaCXCU0KG1bmtKP0DeR3sCbGbAJZS+h/wq8k/wKngDenqkC6gbetsK74O3w0+xbIxMv/QfXHEo
8kba8xk8hOZZvPWlVjMst6CviLwceR4xWYU8Ej4Na1DrmZi9+wTlwtER2TsMC8MxEtlPQ3MGuU04
RmhmhiMlsr4J9oa5eLs5HC9qxcJRQyYmwdFw1LBfBr+jtJIwVgHNW7StHpZT4cAwPlz9Elq4IYyJ
aNws5DBixNlbCFtxRaLtHKOUSLr5eCDr/FlwE/YL4A54JaTXXphp82jnWOyr4IGY+4Y2kD9uVXIv
FfsD2LyEfBGWYY61hUaY8pLUTSlJOzU27fHwJsxAX45eVycyW7B/jFLmiLeTWpW5FrHVs8J5Rww/
py6x9abAavh5DZv6+Cee7sXUXYmeWeaHuTqAa4UzsUKYe/j5CBlL90Fq/YjNozDMEKKnh4WZzHUr
EqvlQucYmqe4VpiHTWBL2JW625Eb4aEh/B7+jn4S1+qDfDV+6JfP1f2mWE7Dz2xkIu+yPniL4Ah4
LTbhFf8GwwxZS+kdkHHRZbjiEEjkY2i8X7jiaPThmsYc9MLZzcz1E2iKQ1YGTVZovLnhSsWq4v6M
PXW94fBFuBh9uDYi64/RbEbey9XJK83ccY9Ti6zzw9kU9mgdNnHs56IJx309+m6wLKTNmjUzmIzP
sFVkhbcHMqc8csOh5cE4at2N/WlkZqI3Bu5Cz5hq4u/3RM8a5bFqeeSDy6ru9YdrsD9Bzownf8L1
aglkLfKZR/o+NOHKeYS64Zgy7pqRCsglfSNkrunpkOyNbROmkBU+9y+fbA+Idoy+B5R62GvWKN0c
XiVXV0r2Kd4zSfnMqwdsBw8L9UG4TOinoT8jdD34MJrq2NwkDD7HsibsRGkl5N7I3bH8Dg16b4ow
VgG5GqVvwRNouIr+ELkf8njYBc0EOEro0Fq3NaUfIO+jPQE2M+ASSt9DfhX5J3gVvAE9PdIF1A29
bYX3wdvhp1g2RqZf+g+uOBR5I+35DB5C8yze+lKrGZZb0FdEXo48j5isQh4Jn4Y1qFuOuoXYtEGe
SWku8s3oY5C+BEdhPUqnwoHwEmpt4LpZtDBsOf31FsJW1KXXzjFK6ZGbT11G358FN2G/AO6AV8Kw
heGIh/0aC6vggb77Bp+Mo1uVHEjF/gA2LyFfhGU41m0htVIoTSlJOzU27fHwJsyg9DFkMtPbiU1l
PBMZTfv1a5TWxw+RcS9GvxI92euHOTAAb2GGh7n6EXps3AfR/Ejpo5DRcYmDHgafwls4jk1gS9iV
0u3IjajVEH4Pf0c/CZ99kK/GDy33uYrfFMtp+JmNTKxcZpa3CI6A12ITXvFvMBzTtZTeAYmkLsMV
h0CiF0Pj/cIVR6MPVwOy1wvnBTnvJ9AUh8wpzThqvLnhHGc+uj9jT11vOHwRLkYfrirI+mM0m5H3
cnUyQZPh7nFqkSd+mPNhj9ZhE8d+LppwZNej7wbLQtqsWW2CyfgMW8W4e3sgs8Bj9B1aHoyj1t3Y
n0Zm7nhj4C70jKkm/n5P9Mxuj0xwWQm9/nANNmS1F64kR5DDkWI0NfEPyBB9IyTn9XRI7sW2kf+M
tc967pOrATGM0aOAUg97zfqgmwvVSPcnKx/3tin5q8w4bwOmWU2a7Md1a3nnoCfyPuFySuf7vpLv
RWRI7vEWxRWN+wP6aXzvLuAdiCcaZw76nkJ/h9Cri30WHnIpPSgMhiH3hx2wOYKHE1y9e/Rmo7Ll
KXlz4g5Fc8qrK354i/I1b1Gahm8/0HzHu5T96LdSN593JqOwOQJHhO9PpNduDm8ervHlb38aC3U6
b1G2S6kqFNkpgSY/lMXGzyBi2ehTIsrOuoQ3V66OZjHcBKsKkzML5X1Ul8Jt4g25u+xk3e0iO5ci
96C0HfI65F1YjkFOQW5B6bvUOoSmeOgNzf6ktKQ2NsWpVR/2pvSzkJSWRT5N6ZN4qIz+OfRNkWtS
GiDfhvxA2AaRnS/CNlA6SuRkt8KTNgJV0axQ8nZiN/J8kXVCZFUo1K3hcTSnkdnXu38X+juEnoPe
hUspTRE6J5CPwPrYK2ymwZpwIqUjaMMs5N7Ii7nij9iMRn6f0hz8xNH35yrvwEVR+6U9A9GsQpMP
p0D6qyYkd8ooJNdKHqIZlZQ3ftl4Hhy1QfQLZIzcA0L1JT6Xw+lc/QyWp8K2iY3el5Rv1l2Evp34
d48lX7D6pOpkW5WO5deicX/GzzX4/wFvPcU+KI/+IZG1m3zVMlPsvY3hdfGZQ3zmi95eV7xdTfvL
FZ62mla09tew12Lvd+O6U8m3utgfQDNY4qB+puVponcMTCbPWP1HQncE7C503oH74CFsVgr1JbSn
O5nTGGZy9U3R6FuN6pGUWbmVCC+A1enRsDD/w5ENW4J+nzAFPzFmn336tX0MSlN3icj+ZeH4Spv9
HvRoZTQKC9Gv5dnvVXmHHGZj1JfjjM4Z4nOcmZiLRt6jfo1cHw+ziFgJ5N7UKo79Rmzy0dyMPBj9
dCIzHXk5/rOQ38YmD/sVeLsFjcb+NSxTpNSbTDvpo+5AJjOj1VO0xBMGY+h1Z4mAN1foZoXzi7H7
LLmU0Vkq6zm1ksRhX8SFcjdBf0Jo13oZu29pVVW4GNYnGltpW31pmx3ZMKuP8ymDlB6Am+FnWLbA
s4m8HWcGSZ4soacempXY70FzGHkRPtug6QivR38mGqmFyKIZy1XmY3MzXIVNC9g5mu8NbWsXhr2I
ck9mzUfhWoF+NxyC5wFhHobRID6vMPuWkks9GYXn8dw9tKduCzyPQrMKzSnsM1WCaCwkByTmSSKc
gv/H8XaYcbxZLG3L18o4Spvtc7V46Ib9CixvDe2j9VCu+HhytrQwWjMV6zb9VY9zdfGzLcwQZuIb
vDc+ovrKU7RQHyzsauXr6PUhbHLJsS9lNfCnoq9E+ztGeSXRW+HKN836ohlPftZDnwV3h2spq80o
em3Qj4ApcDE9nUwfc8PYslItIebN0HRgrRsbti3yIOvno7J+2hZKhpcmkg2xGcB1T0ez9QU+0w/n
3RlW5jK0Nry7hfcXiWEXWYu8NfQiu3AspQkyxzLgnhVbHK45xL8Ta04reDqaBfZaMead7h6Ntawz
bcL4RKuB6Lcz07OQx0Qrp5Q+hT6HvM1EvgL9AGy2Iueir87dKoP8XxWtwMfl14QK97NadrOl2xnZ
euGdKym/kbKysCR3tL4y+rIa2GeVbqwVFYiJZbKKeFCK3w9UnvxtUfR2Uaji6OOiV0o0ySfkm+HJ
9fLt/WR75KnIlyIPivTz5H2+fP/fapZQeot8t03+jsDK7yEfQT4ssvzNUXKIfGc+ORN9Y/kGo/Xw
Er/k85GSX0zKt5wtn2OqLvJX/8nL5G9PkhPkr1eS+UGO5Z6YrVVwBLmUyLadj1h+EftZWhUckKvE
jiLvEf+xg8h/IIvNEPnrkuSNgfxG0xOxXrCv/C4QbWsXtjmQX3MaHbOjmbw3wDOl9wWHaPk+vKVj
Kbw31ka+4xeT3yOakCKferT0JxKZlUTg7/QiIRpsnkjpId8hDLZYPh611s7o5F2xFlxL9HcFp/F/
I/6n8FtGop+IvoN8Pz85MfYcdWtJ22I30n6RxyNPCN63fCt2yrIL+sfQXxZUtRwVuw65Bm27gd59
LvYpMaIk31FckpLCOErdBdRtHzzItVZb1sHP7fi5Afkx5PbyOwDW50j8iLyEkWofZKKxGZt8OPhV
4hBRNK8jt0cegtzB30Z/T0j7ybeusL0vpTfC9rFa5JXILYPnsZE8vJAMrCGfV9rxLUVsS9Fy4R2x
l9G/Ynkn8n3IQ4L1tGE9WTQV/VSu+Bp8FM7k6jvgJ2h2QJHziE8es6AR3w1QBYVWPk++LZAsIp/X
JxsUyC9TlYeqQGZHNfmsP9kgZIGd+8mSBessq6IpnxxHaTZ+stHgB58NCuz8TfYL/RRIG2oUzEMv
c6FCwbtc6zPLjIIjaITnwQYFX0BZZxoWfG9ZItmWu4RScefx1E5K97lrWI7KuG1YvzvUhJxewwer
VcruLa/u1jZb2ZWysFBlqjQVqCx1viqu6qomqoW6WF2huqubrY9udl0aqHLVCDVGTVCT1bSoRlEV
U+VVZVVC1VNNVUvV1q77Nyg7bupq1U/doYaqkeoedZ96UD3Cv7EZ1jIqxa5nVVSGqq8usFe/RF2p
eqhblauuUf1VjhrGvwg6UU1R0621vrxLlw6qU7errsxW/a/pdkW2mo+f0vxe7nn2DlFVlVQN1IWq
neqgOqsbVS+lVU11rbpNDVJ56i41Tt2vHlIzqBVX2aqakvtuM9VaXaquUrXUTErKqHRbWlGVVdVV
KdVINVcXqcvU5aqL6ql629bXVtepAWqwGq5Gq/FqkpqqHo3aUUwVUZVUOVXDyo1VG9VedVRd1U2q
j/JVHXW9ul0NUXequ9W96gH1sJqlHuvTMK+PHg8nw+lwNlwAF/fplTNcvwLXwI1wG9wF9/fplddP
H4bH4SmYFHoejPfpMyjXS4cVYG3YAnaA18G+fXNuv83LhSPgmL6DhwzyJsDJcBqcBefABfD5/sN6
9fGWwjfgBrgF7oR74UHruJd3HJ6CSaHv5Qy+c5Afh+kwE2bBSrA6rJszpE+O3xi2gG1hB9jZmgzz
r4E94K2wP8yBw+CoIeJtLJwIp8Dp8HE4Fy4cMqzvYH8xXA5X5op+DdwAN8GtcAfcBffm2ZHyD8BD
8Dg8BZPCIMi7fXD/IA0Wh6VhBVgZ1swb1Cc3qA9bwHawM+wOe+fl1W8Q5MDhcAycCKfCWZYNg7lw
EVwKV8J8uNGyUbAV7oRfwgPwMDxh2Tg4I4y5MAUamAHLWjaJZcOqsDZsCJvB1nl39s6LtYMdYRd4
HewJe+fdmZsXGwAHw+FwNBwPJw230Y5NhTPhbDgfLoJLoDyLu3btKfkvHLWd3Vmq/P+XZJ/J/il9
+19g19IUfkz4P3PmcRbKjsr+XzR/kdqubml2pf/3JMeu1P83S/xlakZEcydxFG+vuMPJ/4VF/jKL
/2VW+F8s9pdZkfZ6HJ0/UVr+Z13in1LbO1Ype4f616TSSK69N53/Lx0r23vzv3KUf1/9rx8dVf0v
sMZf4D+Pm2Pv5v+c6X+Jjezdf5R99pmtFttnp/fVLnVQnXJSnNJOdaeZ08Hp7gxwRjmTndnOYmeV
876zyznonHJT3NJuQ/dWd5o7313urne3uXvdI25SG11B19WtdWd9sx6sx+pper5ertfrbXb+yvVS
wtzWg885n3DO+axzztefc77hT+d23uj9fzoP7JJRV8WcP53Hp5x9nnbq7PqJTmf7z3jl7POS153t
v+TAc87HnGM//5zzFeec7z/7PLP+Oedjzzl//pzzbWe3P+vk2eUVip99XmXyOedT/nRu522VqeeU
7+Xctat48bCH1ZaGx+q5lHh2Dc20K0fVUFujdnRsGh3bRMdO/5d1LRMdS0fHStGx7tmtqDXw7F7W
zjz7XP5hgT/bN+xx9nnjfWefN9lyzvnWs8+bDjjnfOA55xPPOZ90zvmSs88vaPOnrLNCi7bnnPc9
275F/3POzy0fdc756HPOx5w9qheOsjQ2Un2cx1R/Zy53md72P+XMcmbJe0a/pNXJvwmq/bif5hcV
C8d1bF3+DVKHf4NULIqrIO2RRFratEQ8ESRSrCZwfnJ+snY/Oz9bu+POceU6vzq/Km0eMA8ozzxo
HrR3askgV1+qO0iL3OKuXC9d+XadKKFL6lq6vj33dVFt76U6XacrR2foDFujpq6ptK6n69nWO05d
26NMu6sapuaqTWqfOu1k2J6k2L5lpD2h3LRpabMtH0l70nK6jUG6vUdk2xW3vt29tUrUVdpNt+2u
xzEtUd8eS9rzBhzTElnKtWcVLNMS2ZYSMcn7sqpSoqrStr/xRDWOaYnq9phiz2twTPuTZc3IslZk
WTuyrBNZ/qO9M2jvTNr7KO39R8ksSh6j5PE/lyTSaWFxWphBC/9RkklJaUrKUuKqmGv/s5O3iCvf
hU93bW23pI28Tpua9rDybOsCZcfQjmLM+nFc+ZQ3fCpQ/PZ5L8ZUMZqOc9o5bUe20Cm00fJdX3n4
9fEb4DfmlnXLqhS3kltJpbrV3eoqri/Xl6sifo6fo9L8wf5gVdTP9XOV8e0uRSX8Mf4Yle6P9ceq
Yv54f7wqbvqb/qqEGWAGqAwz0AxUJU2OyVGZZrAZrEqZXJOrSpthZpgqY4ab4aqsGWFG8Jv6d6ks
c7e5W5U395h7VAUzzoxT55l7zb0q29xn7lMVzf3mflWJnDyfnKxsHjYPqyrmWfOsqmpeNC+qauYl
85KqbpaZZaqGWWFWqJpmpVlpl6k3zBuqtllj1qg6Jt/kq7pmvVmv6pmNZqOqbzaZTaqB2WK2qIbm
I/ORamQ+Nh+rxmaH2aGamJ1mp2pqPjefqwvMF+YL1czsMXtUc/OV+Uq1MH83f1ctzdfma9XKfGO+
UReab823qrX53nyvLjI/mB9UG/Oj+VFdbH4yP6m25qg5qi4xx8wx1c78Yn5Rl5qT5qS6zJwyp1R7
c9qcVh3MGXNGXW6SJqk6JuQx4YqETmjVifG+kvHubHMlrq6yuZKmuiSMzZauiXSbXd0SxW12XZ3I
sNl1TSLTZtW1idI2q65LlLVZdX0iy86R7okKdo7ckMi2c6RHonKisrqR37PvmWiSaKJuSlyQuEDd
nGieaK5uSbRMtOS9xwQ7PybYTEo4CTXOKeuUV+NZVyY6PZye6n4nxxmkJvPvGU9xhjrD1UPOFGeK
esQ+azyppjvHnGNqpnPSOakedf5w/lCzZCFSj7mBG6jH3TQ3TT3hFnOLqdluppupnnTLueXUHPd8
93z1lFvDraHmuvXdLmqeO9y9U613R7oj1QZ3tDtave3e445V77gT3Ylqo/uA+4B6z53lzlKb3Cfc
J9Rmd5H7uXrfrklGndGNdWOV1G11O1UoOe24ep6e52hvuPeM4/mD/EFOQ3+IP8Rp5A/1hzqN/Tw/
z2ni3+Pf4zT1x/njnAv8e/17nWb+V8FMp3n8yfgLztH4R0XaO8m069Iecu9KeybtgPty0SVFX3F/
Kfpe0R3uadPBdNYp5jZzm06Y283tOt3cYe7QxcwgM0gXN0PMEF3CDDVDdYbJM3m6pLnT3KkzzUgz
Upcyo81oXdqMMWN0GTPWjNVlzXgzXpczE8wEnWUmmom6vJlkJukKZrKZrM8zU8wUnW2mmWm6ollk
FulKZolZos83S81SXdksN8t1FfOaeU1XNa+b13U186Z5U1c3a81aXcOsM+t0TfOWeUvXMu+Z93Rt
s9ls1nXMh+ZDXddsM9t0PbPdbNf1zd/M33QD86n5VDc0u8wu3cjsNrt1Y/Ol+VI3MXvNXt3U7DP7
9AVmv9mvm5kD5oBubr4z3+kW5qA5qFuaQ+aQbmUOm8P6QnPEHNGtzc/mZ32ROW6O6zbmhDmhLza/
md90W/O7+V1fYv4wf+h2psAU6EtNoSnUl9kEdHT7hJfwdIdELBHTlydSE6m6Y6JIooi+IlE0UVR3
Stj/6SsTxRLFdOdEiUQJfVWiZKKk7pIolSiluybKJMrobolyiXL66kT5RHl9TeK8xHn62kTFREV9
XaJKooq+PtEo0Uh3TzRNNNU3JJolmukeiRaJFvrGRKvEhbon+zyH56nGrLW15N7n3OTcZNX9nH7K
8d703lRuLCWWonTKxJSJdvb8dzX+72r8n1mN/1/2lSX75InddW4Pvv1vjv03x/5DOeb4A+0zf7pT
yW2sL/O6qyzVQrVVHVU31cPuOgba5/fR9nlgipqp5qiFaolaodaod9QWtUPtVvvVIXXcPtkrJ3DS
Utcrnbo6dU3qWxzXpm7gmJ/6Nsd1qe/a4xorbeS4JvU9jmtTN3HMT93McV3qB/a41tpt4bgm9UOO
a1O3csxP/YjjutSP7THf2m3nuCb1E45rU3dwzE/9G8d1qZ/a4zpr9xnHNamfc1ybuotjfuoXHNel
vqNcW/q+5drUbZb5qTst1/0bEdlDz1enfhlF5qsoMnujyPw9isy+KDJfRxHZH0Xkmygi30YR+S6K
yPdRRA5GEfkhisiPUUQORxH5KYrIkSgiR6OIHIsicjyKyC9RRE5EEfk1ishu2//VqQeIyCEi8vO/
GZHfooiciiLyexSR01FE/ogiUhBFJBnlSmEYmbgKIxN3wsjE3TAycR1GJu6FEYn7YUTisTAi8ZQw
IvHUMCLxeBiReJEwIvGiYUTiJoxIPBFGJJ4eRiReLIrISSJyRjIlHkhE4mn/XkTiJcKIxDPCiMRL
hhGJZ4YRiZcKIxIvE0YkXjaMSLxcFJGsKCLlo4icF0UkO4pIxTBX4pWiyJwfRaZyFJkqUWSqRpGp
FkWkRhSRmlFEakURqR1FpE4YkXhxiUi8NBGpIJkSr/5vRqReFJH6UUQaRBFpGEWkURSRJlFEmkYR
uSCKSLMoIs2jiLSMItIqisiFUURaRxG5KIrIxVFE2kYRuSSKSLsoVy6NInNZFJn2UWQ6RJG5PIpM
XSLSmIi0ICJtJFPkX1qVdvOOrruq4exwn9ad9FW6v/4f9r4DLouj63fK7jPDs+VRREFFBXv3ARtN
LIgFFexYEUFUBAUVW+zEGk00Ro0ae++aaNTYjcbeY++99979zh7RYGJuct/75X3vvb+P+TFntj57
zpn5n//Mzu624e14Au/Mu/BuvAfvzYfwofwLPowP519C3+UCv8gv8cv8Cr/Kr/Hr/Aa/yW/x2/wO
v8vv8fv8AX/IH/HHRi/rG2h0P90PPzDZegKa1+A1COPhPJxw3orHEYW35fHExjvxTkTyFJ5CXHhX
3hWYQHfenWi8F+9FdN6Hf04M/h3/jmTiq/ke4mb0NHoS8CqwELuSU8mleCneSm4lj5JXyafkVwpY
msEVPcaxfko80o1NFLNGuXiitQccWSBtD890exRPtw1aM0+EvYniplhviiuoFCRa2u+6KZmVLIq7
4qFkVbJZb0aEPX77XesOgENxVTIpqmJThCIVF8WuaIquGIoJXYgMSkbr/gfo1hcuwTqGKeWUYKIr
FZWKxBqBKUM8+Gw+ly/kS/gW/gvfyrfx7XwH38l38d18z6csbo2o8Vl8FpxxjvXsOF/AF4C9F/PF
oMdqvhl+7wK/+eHss2CvBbB1NV/D1/J1fD3fwDfyTfxnvvlTPsazz+az4exz+VxrViFfCGdfwpfA
2beAXxTUwzp7ceL2ybN+Qg+02YU0m1nH/c3ahcdZtQGOUzuw5eRzMoAMJIPIYDKEDIV2PYwMx+8D
jyAjydfQyr+xZheQseRbMo6Mhzb/HZlIJpHJZAqZSqYBAswgM8ksMpvMIXPJPMCDBWQhWUQWkyVk
Kfke0GEZWU5+JCvISrKK/ARYsYasJevIerKBbCSbADk2ky3kF7KVbCPbyQ7AkV1kN9lD9pJ9ZD85
AKjyKzlEDpMj5Cg5Ro4Dxpwkp8hpcoacJefIeUCci+QSuUyukKvkGrkO+HOT3CK3yR1yl9wj9wGN
HpJH5DF5Qp6SZ+Q5eUFeklfkNXlD3kKFpqwOq8vqsfqsAWvIIlkj1pg1YU1ZM9acRbEWLJq1ZDEs
lrVicaw1a8PasnjWjiWwRNaedWBJLJl1ZFPZMXacnWAn2Sl2mp1hZ9k5dp5dYBfZJXaZXWFX2TV2
nd1gN9ktbme32R2usbvsHrvPHrCH7BF7zJ6wp+wZe85esJfsFXvN3rC3EAYpZ5xzhavcxgWX3IXX
4XV5PV6fN+PNeTRvydvzjnwAH8gH8cH8Gz6eT+RL+fd8GV/OV/Gf+F6+j+/nB/hB/is/xA/zI/wo
P8aP8xP8JD/FT/Mz/Cw/x88rgUqQ9eVl5ZByWDmiHFWOKceVE8pJ5ZRyWjmjnFXOKeeVC8pF5ZJy
WbmiXFWuKdeVG8pN5ZZyW7mj3FXuKfeVB8pD5ZHyWHmiPFWeKc+VF8pL5ZXyWnmjvFUzqllETVFL
hIsIUVvUEXVFPVFfNBANRaRoJBqLJqKpaCaaiyjRQkSLliJGxIpWIk60Fm1EWxEv2okEkSjaiw6Q
kiF1gpQiuoiuopvoLnqIz0RP0Uv0Fn1EX9FP9Bep4nMxQAyENFgMEUPFF2KYGC6+FF+JEWKk+FqM
Et+I0WKMGCu+FePEeDFBfCcmiklispgipoppYrqYIWaKWWK2mCPminlivlggFopFYrFYIlaIlWKV
+EmsFmvEWrFOrBcbxEaxyfpus9gifhFbxTaxXewQO8UusVvsEXvFPrFfHBAHxa/ikDgsjoij4pg4
Lk6Ik+KUOC3OiLPinDgvLoiL4pK4LK6Iq+KauC5uiJvilrgt7oi74p64Lx6Ih+KReCyeiKfimXgu
XoiX4pV4LblUpCptUkgpXaRdalIXS8X34gexTCwXP4o34q0kkkpmX2/fYN9o32T/2b7ZvsX+i32r
fZt9u32Hfad9l323tkn7WdusbdF+0bZq27Tt2g5tp7Zb26Pt1fZp+7UD2kHtV+2Qdlg7op3TzmsX
tIvaJe2ydkW7ql3Trms3tJvaLe22dke7q93T7msPtUfaY+2J9lR7pj3XXmgvdVW36UKXuotu1zVd
1zPoGfVMupueWc+iu+seelY9m55d99Rz6gX0QnoRvZheQvfRS+tldX89QA/Ug/RyerBeXq+gV9Qr
6ZX1UL2KXlWvplfXw/Qaek2jkFHYKGIUNYoZxY0ShtPwMXyNkkYpo7RRxihr+Bn+RoARaAQZ5Yxg
o7xRwahoVDJCjMpGqFHFqGpUM6obYUYNo6ZRywg3IozaRh2jrlHPqG80MBoakUYjo7HRxGhqNDOa
G1FGCyPaaGnEGLFGKyPOaG20Mdoa8UY7I8FINM4bF4yLxiXjsnHFuGpcM64bN4ybxi3jtnEHcNf7
3Ygsjoz2ZVMYICiOd07jYRDfD/NaEN+P8ia8KTnOo3gLchJj6GmezJPJGYh4/clZPoqPIhf5OD6O
XMLIfhnj1hWMW1cxbl3DuHWdr+AryQ2MELcUfyWAEhw3ZaqpmtSpuqlu1AdHRn1tN2336DURKMrT
OzhK+tC+x36eMftNTWXumkMLZr44VhqDo6SzIdo/IC7ADnKToiQcGNAEiADrAZ3hJ7RdhDkcWHqA
JeseTQaShXjqBizn0CHKOXLpDsi9ddf3++rAABzWHBNXOGtOYACF39090nNZ63VvyDPqeSDPpOeD
PLNe0jrSbGqd0WxmndFsbp0RzxWCZ027R2NGwJJm1obcMOt8tKUBbmmIWyI/2hKFW1rglmjcwogL
eM0JvvNj1je2AlkgYawKAwbJqrPqRGERLIKo9uP248Rmf21/TYRWRisD52PqXHbgH4qxH0fY/7/j
678nwlox9O/GzX8yZmYRSaKj6CwGQQSyImdtiJmRGM2aQWQaj3EyFmKkFR3fxcbkvxkVB/9FPPxj
NJwJcfC3CJg+uvxfFg1/i3aSQwyf/VFUrAnsw+Ie75iHxTuaiiZSecc7pA1YRytgHPOQc8wXCVKF
WtsQamoLq16+j52s/cdxU2+oR+qN9MZ6E72p3kxvrkfpLfRovaUeo8fqrfQ4vbXeRm+rx+vt9AQ9
UW+vd9CT9ORPRttdn463ZoRZ26zzt6Lugz/GXbOB2dCM/EP0NXRTd2AMdv1kFM4BcTiX7q3n0fO9
j8dmM7M5xuSSfxqVQ/4Yl80os4UZ/S9F549jc8i/ITpHUEYzQ1c2Gy1I3GhtWp/kwTulBWkUjSNF
aBvahpSk8TSelKIJtD0pTZPoZ8SP9qJjSGU6gU4iUfRHuo/EsE4shfRmXVlv0o/1Zf3JEPY5G0yG
saHsSzKSjWCjyBi85zmejWWA9tjHn8x17kqm4AyM2TwLL0zm8KK8BFnLfXhlshEj/iGM+Iex93ZE
ma7sIzfUzGpm6mEjNkKz2piN0Ww26DbT7DZ3mzv1tH1j+5bmsI23TaK5bVNs02kB20zbHFrENs+2
nJawrbCtp4G2jbb9tLLtoO0EbWA7ZztHo2wXbZdpC9tV23UaY7spCI0TTEjaU9iBIaSKiqIKXSWq
iTC6XibJZLpJdpJd6GbZTXaj22Qv2Ytul31lX7rDuotGd8pBchDdJYfIIXS3HC6H0z1yhBxB98pR
chTdJyfICXS/nCQn0QNyqpxKD8pZch79VS6RS+gxlzCXMHrcPtc+j56wL7AvpqfsS+2r6Tn7Wvta
ehOi7Xl6y/5aU+ljiLbB9I1WTZvGhDZD28ha6peNgqyv8atxjm1+NxMG+qSL8b5Lc9o6bc2KdGso
CQAzvmMg+YHZlILtsyBZ+WLgBrNQWkvr0pbWwdJpSNZ8nCK0CNSd4rQ4BD0/6gfnrEqrQoipQWsQ
hY6j43A+znbSUs2r5lPzqwXUgmohtbBaRC2qFlOLqyVUp+qj+qol1VJqabWMWlb1U/3VADVQDVLL
0V/pIXqYHqFH6TF6nJ6gJ+kpepqeoWfpOXqeXqAX6SV6mV6hV+k1et16Wxy9pXBF4U/4U/6MP+cv
+Ev+ir/mb/jb/5N1CqiiMBxvUHDGbEa8p+UBiRNPSArOx1TBekWJICUgSbBqALDFIEh2EgxJI5VJ
KNFJDUgmiYTkII1JE2CJUZBcSStImUhbSG6kM0khmUkP8hlxJ30hZcX5Udmog2Yg2aGlZiM5aE6a
k+TEmQ25cMaUF7TaJsQb7+3mxvaahybSRJIX5zrko11oV5Kf9qa9oWUPpUNJITqMDieF6Ug6khSF
djyBFIN2/CMpTjfSTaQE3Uq3ER+6m+4mJXHUqRS2vzLIrMNw7CkKx56icUQsW7oRsRI47yqQAUMl
OZgP8wH+WIaVsZ7DY5VhSxgLA/5Yl9UF/hjJIokKLCiO2ID/JBBh32vfT6T9oP0I0ey37LdJBvtd
+wPiqnlqOUgWLZeWm3ho+bRCxBOiyRbiDbFkJ8lrxQlSCOLEVVLEQnVSAlDdk/gAluchpQHP85Ey
gOiFSFlA9SLED3paxYg/IHsJEgDo7kMCAeFLgq9+r4sTdanO2oEuOT/SxZ/5wxZLI85qQ89GQY1U
1MgGbK8JEaiXBC7XkbigXnbUy0C9XFEvN/sj+xPiYX9mf0Wyo45eqGNurZhWguTXfLTSoJelaXHU
1Ac1LYOa+kE0vEmCIBY+IOVR61DUuipEqSBSA2JUCPRT3t2DrQntsxVq5GPpaL3TkASk6eiTtk9B
aL0j6dgP6xidT5fCktuH/aAFfMIGQQzshpZQ0Lcq2sOG9hBoD4n2cAH225zY0SoaeltH2xj2KfYp
xIT++RbigD7YMfD5Cft54mm/CVbJa3+jqaCxAywRrJXVgkkcMIk9pD1whiPkM+AID0gqMICXZAxE
/FxkEvp8Ffr8J4jjBchq9Pwa9Pxa9Pw69Px69PwG9PxGiO+lySaI8WXJzxDnQ8hmiOo1yV5gOlHk
CLCbNuQMMJpkcgW4SR1yBzhGJLkPkT4a+gGAhNBP6kiI1Y8klayxBlLHmnND6mmb9GFkLxwTS8f/
7f3wvaL/0N4f6gOJQa/6Yp2vna4++P5WH0h9EvxhHSNVoIf6W33wtca77RfsNwjRbJpJXLTy8Guu
1lrs67+7Em+8BmfaVb6/1gBAs38B3eHIzGlzRS0spIiFHLFQQSxUEQttiIUCsVAiFrogFtoRCzXE
Qh2x0EQsdCAWZkAsdEUszIRY6IZYmBmx0B2xMCuh6jErXrJwvlFdq25V95MKf3lfiFE7dYVrzU0L
U18aQCvRMFoXrjGGtqPJtCtwqVQ6hH5FR8NvT6Wz6UL6A11F19MtdCfdDxY6Bda4Ru/QR/QFhCEb
05kr82A5WV5WGCxdhhYGGxQEixRD2QTisCWbU3+UUTQAZQsaiDKaBqFsScuhjKHBKGNpeZStaAWU
cbQiyta0Msp4WgVlIsR2SybRCJQT1OyWVFaonihXqjks6ago3S2puksPS9oWy6wot8lsKLdLPA66
K3iccJF4nLDLnJYEHpUL5UBHVfyddrQQYJIDGAeDpaKQNwHeYbGYEpBHUSfkLSigFGgIdRP0Kwl5
DAVGA7qVhrwVLQN5HC0LeWtayZqLQkMgT6ChkCcCc2GgVTXIk2l1yDvSMMg70ZqQT6C1IJ9IwyH/
TvUgDPTNCvlK1ZoDW1EahIGmJrhnsXRAvk1mgHy7zGjNrpLQKkC/TJDbpRthoFtmyAeSQtDCmkHk
T4SI34sMIMPJaDKRzCQLyXKylmwhu8khcopcIrcAZdLuL0JN8oAanxfqkpOWoUFQm6rRcFofrBEN
WiXS+WCtCWChBSib04Uoo+gilC3oYpTRdAnKGMB4S8bS71G2pD+gbEWXoYyjy1G2loUsCTpatW0C
aFkE5TZZFOV2adW+CaBrcZQusgRKu3RaEjT2QTmQTkb/TUHPTUXPTUPPTUfPzUCfzUSfzUIvzkbP
zUHPzUXPzbP8Ib3Q4t5o8dxo8Txo8bxo8Xxo8fxo8QJo8YJocf+/YelXVAE7u1FPsHJRWuoTNu5E
u9M+dAD9woqYUCum07l0MV1OVwNibAWkOAiYdgbw6wa9R5/IkoSrGnXIMiibyEoom8sQlFGyMsoW
MhRltKyCsqWsijJGVkMZK6tbkrnKMFyOkzVQtpbhKONlbZSJsgHKJNkY5QQZa0mwVStLgrXiUG6T
rVFul20sCTZri9JFxqO0y3aWBMsloBworVblkNCeYMlqT02k1ZKaS4v3R0l/y4sywPKiDLQ8J4Ms
X8pyli9lsOVFWd7yoqxgeVFarSpeWq0qQUZY7U/WsdqfrGu1P1nPan+yvtX+ZEP0d6TV/mQjq/3J
Juj7puj7Zuj75uj7KPR9C/R9NPq+Jfo+Bn1PiSKzWFeMpYrvS44q+OyCihGEIP5TsJcGx1sPT3BH
FdhDhX3C8amSghD5gt6PmtIsiEPuiB8e1nVaZ6RZP5TaWlpa0RkizljEEcytu7k0A8QwQjND/5ti
rGIYgSzmNZHsAhv7ypKylCwty8iy0k/6ywAZKINkORksy8sKspIMkZVlqKwiq8pqsroMkzVkTVlL
hssIWVvWkXVlPVlfNpANZaRsJBvTBjSSNqaNaEPa1j4ZONfUd/dEWBfWhw1hY/gEPo//oOZUc6le
qreaW83jqOQIcVQW1BEqm8imsplsLqNkCxktW8oYWVHGylYyTraWbWRbGS/byQTgAhftl+yX7Vfs
V+3X7NftN4AXCE1qLppd0zRdMzTTUc6sZlY3w8waZk2zlhkOnKGCVlGrpIVolbVQrYpWVTuqHdOO
aye0k9op7bR2RjurvdJea2+0tzqYUGc61xXdS8+t59Xz6wX1wnpRvbju1H31UnoZ3U+vpYfrEXpt
vY5eV6+n19cb6B31TnpnPUXvonfVu+nd9R76Z3pPvZfeW++j99X76f31VP1zfYA+UB+kD9aH6EP1
L/RhZl2znlnfbGQ2Nps4gh3lHRXMlmaMGQt+KwT1pD74zRoZKQZ9gxrAituxROLDUlgKKcV6s96k
NM7xLoPjHWVxFMMP71X48+/59yRA9YAYGWj7ybaaVLRtsm0iIcJ6jKay9RgFCZUGRL4qVj+fNLb6
+SRGy6sVIQlWb5901vYC7+2lPQTGO1DPBYz3K91b9yYjkPeORN77NfLeUch7v0HeOxp57xjkvWOR
936LvHcc8t7xyHsn6JWB8X6nNwSWOxNZ7gZkuT+bTYHl/gKaryZN/o6P/0Wf/gOe++AzO1qToDVd
0I6uaMfsaMe8qHkx1LwMal4HNa+P/D7y3aiJaqoZESfCyA7IK5Gc6VvR7+v1n9fQd7UJzpAR6w7B
usPRwzb0p4n+dKA/M6A/M6I/XdGfmdCfbujPzOjPLOhPd/SnB/ozK/ozG/itOcmedvUO1TXd1ZvQ
V0tr9xYSYc0lWHMp1lyGNZenHZtBzZTuWA9g0x+w5B1GOEIRz6zRQ4K1WsVaLbA+W09ufUEq/Xfj
WXqkEvTvIRReZUHgrQRbYEFsdcWxvZV4N05F79Mn9GUay87IsrDsLA8rxKur7dUktaPaWe2t9lX7
m23MeDPBbG8mmR3NzmYXs5v5mdnL7GP2M1PNAeYgc4j5hfmVOdOcby40F5vLzB/NleYac525wfzF
3GbuMvea+81fzcPmMfOEeco8Y54zL5iXzCvmNfOGecu8Y94zH5iPzKfmc/Ol+dp866AOxSEcLg7N
YTgcjoyOTI7MDndHVkd2Rw5HLoe3I5+jpKOMw88R4Aj6n7nV/zO3+r/taaoMwIpaq+6OisCnBv6t
Z0cAL2g725V0M/2lNRPuwzy6/8VcuA+z6OAcrByLSjeOaK2pATj5YTSOPiJPoe9bmvnBHiGwLoLV
YQ1ZY9aMtQJETQZs3mzdu/5Usu5Xp09wlo+T3x+TdXc7fbLuhX8yhfwuVbHulH+UIv6YrLvm6RPo
8icJotZHCXT+ODX+VIIo91ECK32cojD9ttzqd6kNpHZ/kpI/lSCifpwa/i61+F1q+3FK0w+v9t0Z
/mf08U9GHyk5A1E+CBiJ9c6m+vj+p9+/+2ks9HWnk7lkMfR2V5ONZCv0dw+SY2A/J87p+N/N/f6l
POJfyT85xvhuBFIHMZ3Oh31CrH4UxLos2PPKhs+RF6JWr7I2HQPlsfRbKI+jk6A8mS6H8o/0rvUG
bXqfcPoAvyH0mD6B8lP6HGPmSyi/om+g/JZZX3NiTIE6pzIblAWz3jqtMR3KBn4bKQPLCGVX5gbl
zCwLlN3xu0fZWHYoezJvKOdmeaCc1/qKEsTYQlAuzApDuQgrAuWirCixvg5VDMrFmfUNs+/Yd1Ce
yCZCeRKbBOXJ3PqCYDWIzJyHqe7QS7VYDAMmFGG9oV6tA/30umoClBPVzlBOUXtCuZfaH8qp6ldQ
HqGOgPJI/Lb6LnUXlHdLnVBgQNZ4VBboHVPpLn2g7OvyPaEuP7j8QLjLMgNsZdwz7hFu3DcFoaY0
NcJNHbg1NVsB5+COcsABKfSUqxLmqOZoQ2jau2UsPI9Je2L/Nz5CkY9Q5CM03VPjFPkIRT5CkY9Q
5CMU+QhFPkKRj1DkIxT5CEU+QpGPUOQj766QISuhyEooshKKrIQiK6HISiiyEoqshCIrochKKLIS
iqyEIiuhyEooshKKrIQiK6HISiiyEoqshCIrochKKLISiqyEIiuhyEooshKKrIQiK6HISiiyEoqs
hCIrochKKLISiqyEIiuhyEooshKKrIQiK6HISiiyEoqshCIrochKKLISiqyEIiuhyEooshKKrIQi
K6HISiiyEoqshCIrochKKLISiqyEIiuhyEooshKKrIQiK6HISiiyEoqshCIrochKKLISiqyEIiuh
yEooshKKrIQiK6HISt6/oejD+4qydwbphmtJ9gRnavY2NpfCg6oNempQwaamZm8Eq+ozSn00p4tN
LWJylk0lzpY2exEbVWhqWUaVqfWcdZxF063xnJ6znyfevA0iESSGdCZJAKhxJAX+rZu5wU7vdCdT
3E4PtS995vbToLJZDw1NvNCUx9Wqcm1qapbCzlTF1ZnKXkzljDIAik1kWFDQkIwHgp/E3jpbwWl8
uFKqwDUl+xRxFrLxBoqWKXdIUnKPTvFt2qZ4FYwt5OXj71/Wq1Z8bKekzkmtU7xCkjolF/fJ6fR8
t3Pmj7ckdWqZEp/UwcfbmcvazjN5/La9blJSilfFLiltkzrFp/Rw5nQ3/Ms6fXyczrJO+Gvibvg6
fXxL+qQt/geuKJXmTm8WqhKeCtUO1ttZKqVkHlu3KflK4IPw7AWnfNs9ynlj+rwv87V49mZMzRkr
30ya7hXcq87076aPiPZNOFCpVY87C7vuqH/iwc2JgzxHTBnQetkvCZ/F5DmSI+iMg466NnbLhmKt
J0xom3/8/oCiG/QfG+XfVOWqPdhvbNF5Bf3n3qr+eaWLAxxrJiQ2aLkwtde06GLdal4fv7xV4ITa
nj4yr9uUeVe/LuJxpdy4WLfoRmrclBxl6w5+OufuaLY1+68bGoQuG9pvQ8Ct+qPDF7+e81n7lPAl
HrvHuhT0JpEjo+PLrqnhKoIavm36cmZru5x9sH/DyLsrAqOy9O+mnHiyfnG/MW+W7ul7ZE62Ts2C
dq69J2fkdi6zDdyxzKtbpoFnGYeKP6P/XGf/Wc7+08GaOajSf4Kz/7f9MjTdn3w3vtPkPHX6uP1Q
66u3u6Z1+vf7L/Uv6ji3fDjmmrbxy4ffepS+vYrmPdYt48Nm0b5TJmu7gtWvh4zYEXDF+8G9yG+K
/ji16vaYu6+O7g4MbDKvTP34N3nbl9+xe/4Ztddpny/LTcmQ3G7NG9cIj/iNr/aHXMzYxCviRkzP
JfOzbi9SNl+x9XHTXL/I54id8bS+53PvHUcyP6y7sEOIr3id6v7scptEo86Tdffrblt3dYvzlZeP
y5AcYwplq3U4B5t1v985vrzpo+9Pb4+8E1d9W936K5bzgq5vRx65J0f0WfXtLwvKFr302aW53S52
nUr2tyu/6WCZL85VdJ1bul32didLnz/kqVyaG6psb1LSr0MtTyNmpX368F8P1y9fZY9ng9nJJ10D
Bn/TZcqcg1MBFaKdqbzmO1SwF1+Q8VTtt80m7dr4HlNy/KfAANq9ny/8AQL4Ahj4+MJi6fdg0AMR
FE5iy8Qa1PPJ5MxoLchM9siWndvGd2iTAj+TwWlaK0UmUTeuVfukDq3eX5j9zy4sj9P73YVlS7+9
VZxXvfg2HeCsXrVDKv4lKqzs0ftI82Wh/nNLLfQ58Txf6erdNr7MNXlbaMe7B6pcOzR8c0LNujGP
xrPNtY5VTyyRNzhuw948K7VqK/t2OR26bv4Is/Yv+Yo8mHrVyJPrQMW8L2LG78saOuubsFzj9ywr
kXtzWLFeSccz5wwc7p/B//S6Qo9aBxajvm/fFKg2+8dEOnjiy9U/xPZNfd5sav8BA79a+mDV6Bn7
/GbXHuheYHD4aecTUu7R1ufl+q8fdDvRf07xUk+WF19i7x3zdffWE8d1NgYtebDloddPEa5fxu4q
etw3NOudNWFjA2vX89jbuk6P+YsGb28YPCW19pAO6velN/XMu65u63Ljw3cX6VOyw4CqtgOT94cN
Yh0GkZkbB5+tl4YKL5z9nzozWaCQT9GddpuEgKaqgvP/N6DCYV1jJuvDuaqTg3DmsFaYShbFbXeO
vV1JctMl909sCZ9Qp3LxGZVj7zk1a7NDUaAZDUrXdBBjei5Y3Ccs/4O9a8NTpjcqkFK4y7JBrxfU
HN2d1Lq+86bHqfhfzOm9HrKQrTsH735Wb/fPU9Y1TLoXW3leZXJn7PYJhz1XaVOyGqOPnsi5qFDv
u7dnd1444oz/V+XGtVvr1/7gkCV5Xp+9fiTe5esh696cJ2tKPXza63kG1+LqzUJjv6mUULDjSr8R
54Sxo3nbPev6VUxoPXfNyjVfldr5gGfo9dnjg+cqne355vz5hW+enD1sLEs+MupixAq/6b2KHSp3
spQWU5ZN6d8uz9AnzWJHLG2yxv9o9PAGA7KVfBw4bmqqPr3FsGVFV06btWvBCa8VG5xZB3q5GYXX
1n1U8VyU8+KogvGDNyVfeDhnwd5+lTp1NQFj2gHG1E3DmJaO7rWQIfH07UgFnPkPtur3gFPS6QTE
KQmA4/R3+lqLJa1FZ8o/cmlp2/mfbP9LrJl+0v7lvp83Vf9uz/yAUovyNE44mbjeO/fK0dtvLN6w
9XD+n30zDlt7onnRl2Ua5sxcZPEI47TbjA4Fa/bNUr7iwi8rfF9liHG8/+hF39r2R1bu2uzG/Vfm
hb4pM0ruSrl892LLaX34ytC3h4NdDy/dGWXs7/lgZSbjVXS7ggO7DF+5aO3Aa+7LR65/nGVFTPPb
Gc8G3PFuOmxJv86bQy+OGdot+ruri7ptKvtlSbcSmU7G7FicbV7EuDaLDnn5Ozue+7JNlQtbPR8Z
tVMqlrim5m3nnVB96agtP/hvqzSrfTOPsAUjjn71eXB3e9VjM38YkGfzhQc9W38flrIuf8UaE1u6
RYc7t6c+3K8l97rToFa3g7JB1/5pWPPM2f8x2j6Hw2qx0AhtG9M12IfeFb7qVedZ/RrjLrsfbfd5
KbV4/mufhiYLJ3LkUTycWfp9uplXtnbIpZRzBjr9p5adWnpQybYpKckBJUrEdkos3v69D4vHJrUv
kZwQb60tkdwpqVWX2JTOJULqQUUrDquc1d7/JPCQIGeA0+/9spMNKpp2wm7dun3qhHGd0p0p5XcN
CNGmQmRSvTaTvT4vRc0r7jWCFt081r/vHaNHSreIb6t6PCSZ4/ucjBk5/XWbaRMvFSz0osHR8W9q
b4hyWfbT7NupD8flTGr84vH98/qvw2RwFnevAxt/DK0q80dHutQYfU/uXl2rw70L1VwLlh7m3els
ixVL4l3zjr5zvZTLyT4dkkbZ6+4sXLP6fN+ig65N2908/9q1Qeea/vC5trq0Z8SA0Kpv14ye1ljM
G3u6+7rIvrPmhO9+sGjihIoXdjXLG3yqb6mq4U/2be856eaKHRNj3eotWTTh7tEN+6ZOWzBm52dF
BhfduO34q0R+YoPfovsHmmV1d2x8urPf7Awy2+mRea4unVYz+MbSjPm7m5uK/jQzYduIIECbSYA2
A9+jTfVetxFt1P8c2tSPbx/XOaVl++T0aFPG6e9TxulTurQv0hsfXPR1WovO/rP/kWsr4Mz3LlDm
7BASn9w2rpNX5XqhXqH1wgN8nJX9ipX2K1W2WEilKn7vd+SZcv6JEvXiOnWNj437S4C6sVqN3X68
x+IBlYNnLdtyu+bkvGf9u+Z0OeIb1qj7wSLHZ4mRd6+We7kuf68ZLy/37uO773i5Yf5lHzw7Flgq
y6FRqS9L3Wo7sFO2EedW1Ty3auDDkna2aXrXzqVrNr+/8nxY7xyrRnc/+TbnwMyVqnTc27dApOuB
zyMC970482TY7fLk4uEz/7XEn+K93ksabb5mOrx62Lmf3X9XSfVLnqfur1bnfLya3sjxQ+xUrfDu
4kecPr+Sfr9dYDnL6t9rwROJckkRN7hCmq9ae3s/Ct2rnyDVN4nV+Vbs6yYu5emcC1gNU7sn+8k5
Ki6aNOGvq4trvulGV/O1mStTf5o4bxQ/ZG35UKDnk1T745AAeeu5hmuRCyhEgVRX9EHPPkzzger3
jB2Mf7wf1p1/bIdS9uS/8LOfvtNktXdb/545r9ZYOzofu0BR2VNSXJCcSJWyB2ZSCbYSlAOjFMZS
QGVWNXHyiF28d96tU2//RZOqxnp1DUetz5cVJ/FNXxsfHKf58+3BEK8Vtd+FL3CL/PT91CbKkPe4
WVbDdbmOpdHd/FnmUe+Ug/pDmHvtl89JsfhmdkLEeZuV3YyTvIcLGzU+py03fBQT2/8zKOhhzOvJ
E+Zmcvp0XrxY5mPCm/WwxmW5dnRzSL2riqTqkS63o6qPJRsyNUW+iR/7oKTT6Ban/eXnsmPldsr5
P5eltPYtSuJdqSu34ukEu/r/G/r+TH/z8S/L+rOe56JK1vz6LCwvbXlu8ZZre75seXdi7acwud82
H09c03LZs3+OfW2axNlNCslcpxxsU40kazbtsD2o5uGnJDkzr8fg4MeJqAWUQBb3TP8DDKqrBW+7
ykdUpS9CL6YGpvMFLZ0MTEzMQaWTJZA7AJ0vjIKTUHlzxzzv9/oTTl6FEifOedgFH/i1WmSXjtFu
If+gE81v7YxvehpO0tg2MeWBfEDLrkPeF+tZf7wv3dd9fMXVdZkFaRXqaS+2bX/fuvPsu1V/hZZw
Rypp6p93uBnGIl22NTcl1yvk9t2P9/bPbz7ecL/eh8l8ytcD8zjC5DLcz948UBajX7tNlWVLWHSW
TPL/hhqbd1dZVH0ty0vYYw/F3Ggz1yk9yfdKzpKzpuzf3Jy8qgdv7Pqnzyvki9fyl0hKMJp3qdlP
Wykmw7X7nn6LQMCmn1ulenPeqc4W/nFa4Hor35emsmKzY1OrFp1JYHvDuqHNePuPKdEtji0RrVPy
NsjreJzJn+P8IOtFvVpfNqS8aWLUAIaICvYcOiS6XwJsnNABUFFGUJ+KAan0xFo4SsI1iDCx8Mhx
MQQzlDIkMTgzOKJ2zTD6dVgKqCm+goaHagJ2C/YtTGRn5OspcO19Xxyy156TVff/jsDgVpm3lhO3
Lw7jvtezzVr64u81y09u3xioKJ3PkVmXzbxIye1tzpbcGqUdbpdbPvfy72PvMjv4uu5lQazr/EmX
zpy723fg4X6tszVvTq4zutq+83TyEbOLEor7y+5Zz9osXTxPsePGli1CIT1f5hxK9ZqloTYnoYvf
+rhwaoXH7vNrm638NyRF3DN4+dJS9nHnp1uWjT+FFXtSGpLZWKZ9msXkrF/t1rHrP9PN1J9e924x
l0zezJrHc2buHY3EGo+P4nMEFS2YZNrXsB2dZrTjqcOxYNu9KzvvvUgz7/2iNG3OmQ3lIYFW14pc
Nil/M2xiWQ8spFYzMTIaNLYPYK8Mpa+IGONe0HjLQAQe3xqMhuzMrOB9AqBUAI1MTmZDHuRhdaBr
EDxuQz4DZFlRA2WERhZDYBp7tL6zdNl9y8nL+g+siHqfJfi5y1PWIAVJC49hmEHIAq0GDQZfhkyG
ZIYihnzwyHwaQwmDAkMIQyVDAZCXDhRPBLIyGCoXqjWo4KxeSyoL8tOLEgsyKhXQijeWJkaGZuvA
1tM6e+cf7H69wGmRzx3tN9eVtjWYBO5fE7F12ZS1Fq7zfapkHjxflfLLXDQx7V92f0bACr+ijbxT
XpR+7fec9+X5+ojYJ5cEtorobrK/8uIXw8TXZQ8ccq0jt6RGhHbOsuQQadPxONlk9vvRbpEDufWM
3I5qm34GOCyxsQ6UrlgQXxvzzrVy1YUPgnV8CW9nt3u0tOn4sUUfCTB7Hf59hZvC5k9bSuvZn2o4
/NDNazvssGxlWENj7K35Sxg1PkpeuTwtfN7msgSDh2H1EdIdLgwXNuuqbC0KXiLTUvMzV+sJM7NA
1wylZXeFj+8/NcOv+/o0kY+Cb//y+ifz7dC6c+mxCPP81+Uhb5YvbGKSN2hikkbEEZthExMPUIiD
7kkUvUZC6WCwQ5PoglgDCeSUyI2YBWIE2gmXYTXkB1a1FoYGRsCK1sjSBFi3oifEvs87HSfJxF6u
/3j31DP9Wc9MVed8RiuzQEnkQlYmf8alF8fVI4pDnhq5+d89Om2nmobRzKYLW0v2lfiH6dxY/Mz8
1+Of7a/jSg9cupq8M8tdyfFMzxL2L4t6g90PlstMU8nVY1TkO/XmVrZ76M/3U2/dO1Jr8WlHEDfX
JyN2o/rP6skJzRV3//yctl37iiNTlabm1jPyZeIqnTOkuld2RD1YpnfFwcHtn/oFgXCB1sWbOEs6
g3rMHsk9ZPr84nymg9hZpbANqyRWneCXepVWKNHm0n3kken2dBYtx/B57gtWhDSxzb8z4+TS6vI3
qYr/vA5+Ebc1Wetns2fzjieRQd9StUQjGVyer1YOKJVSjtzKY/PuRcnPx8ucKloX6by+syeo68m1
DbwMAGyybLkNCmVuZHN0cmVhbQ0KZW5kb2JqDQoyODMgMCBvYmoNClsgMjIwIDAgMCAwIDAgMCAw
IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA2NTIg
MCA1NzMgNzA1IDAgNTUxIDAgNzIyIDAgMCAwIDAgODQ2IDAgMCA2MTQgMCA2NjIgNTEzIDAgMCAw
IDAgMCAwIDAgMCAwIDAgMCAwIDAgNTM1IDAgNDY5IDU5NyA1MzEgMzI2IDUyMCA1OTcgMzE0IDAg
MCAwIDAgNjA0IDU2OSAwIDAgNDYxIDQ1OSAzNjUgNTk3IDAgNzk4XSANCmVuZG9iag0KMjg0IDAg
b2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDk5NDM2L0xlbmd0aDEgMjA5OTI0Pj4N
CnN0cmVhbQ0KeJzsfAl8W8W198y92iVLV7tsybbka8mLbMu2vMexb2R5i7PYjpNaMSFyrAQnhKwk
TUiTGGLHiZM+SCDBgTyW9jXpozy4aYGG/loIvDTQ98j7oCyFLjRQSqHA1wAlpYRI35mR5Nhmbfv9
+vq9TzOe/517ZubMzJkzZ85cx0EYIWQGkKDO4IL2Vr//RCNiHfsRsm5pDgR7HhrU/xahGzsRUq1u
Dsxpuv+/3oayffnQIL812NzCvWlfjVhrBULSRa2d8xds/jdGhdCRHyJGfWXrgoWBwldvCyHmWw6E
NljmL/CVdz96sh0h/CL0Gh64pn+dzmboQojPRYg5NrD5WufihoVPI1RTD+/zVqy76pqXsxZuRsj9
FEKanqv6N65DJsRD/zZoz121euuKh3DwPoTqYExZwcHl/ZFXV8/aAfyvgPKqQSAov6/Swfst8J47
eM21W7btVDwLvGsQcr599fINa4pD5VsQ2gjzY25YvXagf7Z71iyEemEMGTuu6d+yTr9P8zy0Pwnt
nWv6r1muzPx1OUKbngOhudat3Xht7DZ0FKGxD0n5ug3L1/24Xgrty50IyRyIyFb6wb834Is9S3X1
HyC1ApHw8OvjM8nziZbB4T9lXzqquqgIQ10lYlA8QDv5bdFahNQqKL9ZdZFymhTYGkJJa0CdsG4k
MIhDPrQCSn6q6YlXkTzF/BBJkUJ6m9QP70fjT/wntAJHGR0jUbBSiYxlJOcQExOQZGmS99wFTieC
8aO7ZLXRWtwvvw0/4UT4Tsr0nHQhmSlipUH0CB3qv8eTtDpGZIAkh9FV0m+iMM2vjD+lZ+LPyUH2
Y7QkmZe8majXgcISO+qZXjcV/rGDpA3Vkyd7CvVJnoA1bER9zFHUIClAuZIzqI4ZRu2faPMcapf8
E+pLvrMnUDt7L+pi3kZu4CEQmmwA2f9uk0iFVEiFVPgfEpj70Pf+u8eQCqmQCqnw/1Jg+9H2/+4x
pEIqpEIqpEIqpEIqpEIqpEIqpEIqpEIqpEIqpMLfNTCJf4FhQizJMQjJ8NuU8u70f5sB72ziX3Kw
X8A13pLFb7BVf9PoyL8BkSE5oBKSeoLOUTRCMiPL57TfBWkE7UajaA/ai8bQvomSm9AB+rwFHUKH
0a2QO/I3jfTvFb5I8n9ZkKBjgLnICTkiayVKQzloFgqiFtSG5qJOtAD1o5VoLdqEvoruisVoK1LL
CbWaJmp1Q60BtAZtSNTCsY9iFxCK/fvkCJwTMTYwoVtZnz/buAYJi5dHll655Iq+xaHehT3dc+d0
zG5va20JNgVmCY0NM+tn1NXWVFdVVvjLy0p9JcVF3sKC/DyPO5fPcTmzszId9ox0m9ViNhkNek6n
TdOoVUqFXCaVsAxGRdgm2pp6m1eJ6U1hUcMHec4pauadn+sTkcHu4vVOvy9UnKglSr0iMnaIps7e
E0ioCYky7/Qq80TWzb3ngsZz7c5mUeKGH352f0TM7+518dwL9onyELQRM5p6XS67yLjhpx2K4Gd2
vzMicp1Ad9njlHYRdfaSdDL2ag0QUY0rBNjdK2YlX0OhTxvkw7AGp6YNcx4e405o0puCIjKdQJpX
RWQm1c7XIBHVi/leGAgHOcoN+URsek/ERhGb58KQp3ZBmp2r+RQZNEdW8c2RlSDRSPiyTM/HJepy
jjnHunv1fsjSQXeIT3b1nlCrmvim5SogIEpAJ1RqoKgJAVisO4E1DZhmGE1z3QkGKdJAfAYy3GaS
VonCvjBk+CDIDUqMl0tOxk7tn1yEoFkyZ4zn4oMQZU2iPD4I50pR6BfRPueJolNj+09yaFnYq4nw
kf4rekW2HyqcQKy7ebBHdHR0LgYSdAUpPOgkyx2kQBbP2TzoHIN3UjcMyAfJok+hRwaXh4ma4DAf
hDJlU++o65RdNMCzWdR7xTSolnbda3Z2rNm20klex8ZGneJdMNxJpS6CoAQ2GPpYMw+9AbPmVQGy
JL6JZaPa2B6hiyPs63eKQ8tWxXWvf39S/11jnKi54ILVgfWBlrRhQpSR8Coy5FX9ZJrNq5xj+5bT
qe6nUwN9dTavCpJEGoL2o4XQenFv8yDffLlDmDhkWPf0ti6XmO4lDcfGmskQ+yMw+viQoeDy+Mme
sHsxjKdJFHroA/XQNYAehf5gKEFKVFhMmpGScDAUcsXXHaqKcveotIR3jhGOcrdo8nKu01B2qrio
o7u3OWinsxeZpt6Z79js70C+o3OCjG1QZ8z3jj0uo44FfEdXXAsGkxDuiW9gZmLloWqiPuV61mY/
G89f0dvCt4THxlp4Z8tYeKz/ZGxoGe/k+LETGs3Yuuawk25/DPQf7LOLLftDIhcexHV0hQg7J9G9
lu4O0djVR5aqxTnYHzccjbyrxu7ST9Tp/KzixJ4D7Yc9QPbcGPc2jE0D1snubCGm5iRYCLvI1ZAt
CwNa2At7YoDqLwXYKwuAuZ3sGjbkbl65ICEs0MyE8hAb2JWgAhOXi+ynfScFtAxexKGu3vi7Ey2z
fxcJPi+sY5iUnEqWmBeSkqFkyUTzMA/rZutY8AX6PVm3x/S8wVnro/KnpjcinuqBOX5YIypqEktv
bOpl7Uwix9hZklN5wZTVi1YvbUhkAhZzjOOdT/Mi5xWlTb2n7PUhJ6cHU4ehTpuX7CCwqE/zP8HE
jiITJ+J6EVsIHYFdpeadtdZA4YQiOZvHwglNmzytxGEQGfz0uUEdjofp2eP19QaezPApat4SVtvd
QvaV3RWvMTskaoltFrVvU4Dx2pt6nWCJYOd20Yyz2TlIFlt0hoPUJITsk8knY+fCQWICYcikij2h
4oBx0U7VteKiL6voQ6Do1+8PDdYBF6EQZuCshG7pbunpTUipxp7YUaSvdjKVqeUTUkzWgcWHjecS
SzN+YgNFzbC9E/o0kXf0THmb1Bktq5mwDD29Yos3yTz+3uq1T35tm1bcniwG87Hdfh05RhgUOMHj
PV0nBLxnweLehzmEnHt6er/LYKYpHAidyIWy3oed4ARRKkOohEhenOQFdWDg9l1GQevbHxYQGqKl
Ekqg7wMnMaI0RZKG0cBJJk7jkjQGaJI4TaC0uFfRbBsEEfTysOgRUejs/VpocCwcIsJGlrgCgmbz
DUhk+IYTmJFpRBW/PCCq+QChNxJ6Y5wuI3Q5HwD1h83hJFt9LMzD9gcD3IvsOERUmKgL43aejMXA
gp4Fy+sSZe4rIIGBVXpDTtDi2VCvlaQwkFvFoYF+Mg6ipiyx5e0DIVExwRCqtItK4KBMcIAaLbQN
OQWg0QAoaz9Ps0CGzTEUEkNe0mnvSsLA6QR/qI2vE2WeOE+ph3TkC40Z+HJ6nMjcoso9Sh5KGBsx
hJRih1foLBQXklwDIx/goWgg7ARpS9DAAlBGiYf8qOxxynI41SWe5TSp7IlCFN9B6jSVqCwhZ5Wc
5tUlwBB+5KFQfPD0bTRRAfrmRDWMyDNJlIkGIB0oaidjgZ9RGCqp+hhh03USdfNbYA+SQVNOcigW
09zt/WBw4u3VQOFrko2Bl4KSCI/TcaqczFxDHdqek7Hj/FbXpFBcxMPp3EsUE9nBhxRQaGw6QewD
w6mYTk2j5LExRdqnN4jLS5E28SREZ/NK0FXkhDMFxCjztPfvqzFUFD+MnDjrAaUNz3aexJnJjCOZ
sSYzlmTGkMzokxldMpOWzKiSGWUyo0hmZMmMNJmRCG/S3EWKH1H8PcXXKP6G4isUX6b4IsVnKZ6l
+BTFn1B8kuIZiqcpPk7xFMUfUTxB8X6K+ynuozhGcS/F3RRHKA5T3EXxBorXUxyiuJPiDorbKXZR
7KTYTrGNoG+WD3tQI6T5kJZCWgtpJ6QbId0J6X5Ij0L6X5DUKBvnIh+kRkjzIS2FtBbSTkg3QroT
0v2QHoWkhoXkhS341+csVsdzzwNs+5rFvu1r6c/8FPKbvwpwzTqA1WsBrl5jsV+9ZueGjGs3mcyO
q1YBrFgJsHzQZF8+OLI+I32j5bqmdNdWSPInrE8wv3sDe6/9HrY+gvNeCD+y7pGhRyRHbmO8wm14
6c34wEHGCz6AwL1lz6xVDtgGnhhgnQNpulpCLGrNdtdy9yzfUXvHOJ9tu9VTWHvrOPa2jePDhxgv
d6hRqH3pEFaLdnFYZGelYTmWgjp7sSzxlCSeUqF9DHn3QdoLaWxE5r1+J/Zu3yH17hjOyd4zgr2j
kIZHpN5dkOzVZluV2VxpNlSYdX6zptysLDPLSs2sz4xKzCexUxhqanB58rT5eTpdIc7/MOb98M+6
C3/S/vEDbemF0g+Z8x/iQq+2yKvL4bW5vC4rW+vM1uk4vUapUmtkcoWGlUg1CDMaGRvJVus6dIwa
zUBBdoXyWnZU+R10TPkLnVKN1KxaNwPNUIbYPuVm9lrd7eh25RHdw8qfI+3D2IVzBIPOjjPTbPKM
NDNnTTNITGnZs7TYRT4MAHKQfJAaId0J6VHsEjyyovrC+vx6T31ufU69sz6r3l5vqzfXG+p19cp6
WT1bj+o7/T1YNHSgjp6AaMTwXBAQ/d6Ok6yzWyz3dojKzr7eExj/UwioIrMHjsUeUbIHTsIeuHAt
7us9idNJ8QhYFYyR2BEe+XrI680UI8QNG8oMieUkc1NmCBzm8i7Rzge808PGaxOPTVOo4h+bxQ+b
V/aLH8KN7QJchz5sDosX+ODGeGlhs1jU3C/mA9HDB6cwxNP4I+gg3gd5bNwIXW0kOdEmNsJ8p4/n
hJJMvLM7QG4aHWIE7gn2zr6wmMEHwOmHt6rOPvAfAxs3bjyBwEs5wRCQAfT19c7KxFkogjMhOSBZ
IVkgGSDpIekgpUFSQVJCUkCSQZJCkghzIxcjH0V+H3kt8pvIK5GXIy9Gno2cjTwV+UnkyciZyOnI
45FTkR9FTkTuj+yP7IuMRfZGdkdGIsORXZEbItdHhiI7Izsi2yNdkc5Ie6Qt8glBf5kQ+qtaSceQ
FiHpQsQhL0UkKU98cyQfpc7F87HzsX8mGM8jFO2O56cG2XbEsTNj5xloFbsLaui/xHc5pEgk+kdw
29HL6ElKvgUNoUF4jqN9aCYKo/Wfy+SDL9PT1IAbcBUuBqv6TbQXl8JGtaH9CXo5zkf3TVTcgTah
p9Ed6Cg6gDaiQdi176Fz6AYoWYbWTNQi4wtARGgxUkz0ocUl6I8IMd2fMoDn0FNQwwDlT6Mr0RY0
Dx2Gvn6JXoWyMPo99HF5rEUTOAbjuAueX4f0EC1cBu+7KU1EEegdoXvQBjR7ameyR5CCuRbW53pY
l3PoBSBtQgtRw0QPdbgQ9P/bIPfXYGSHGQn6Jf4InYI+zmMtUB6CGZ/DL6PFrAxGeRidR5th3L+M
vhj9Vey8pB1M+XF5ByLL+AjAbmkPykdFqBRVoHzBjIZ16btt9kNm7tYczbjUbJE6cnSosbGRe517
jXsN+97xvVZWiisrGpjqBraywsPnaBk5X1lV5S/PYswmeNGyZrPVzFdivUtPElMtsxTmWj123awG
Z2luujJcv7epZaDBocutL3J6zHLDTfjjSzK2/+Ma/DuLxV1YmZfu89fyHd2m3PKsG7JKMv0tBZ6G
mS3FrqK8fIdszd13R1+T3HZxheRPH90Lo2fI30JKc6RXoCzkQsfBq29a2Cv4nQjuhtlY6pJyOpfL
brHwUqVLqcvGbPZBuGpgO4uxUsfKzTZWZVUqVceCSmTzefXIr7f6bY2GWt/SK5dkvOPVG1BtKbb5
yvW1MCq938+NnjpFUpldyP6rGYawSy6TmU1Ws6sSRAlKncWQfFUVyDTP7WLZvOhCl9YwGF3orinJ
wHdjNZ5tySr1XnqxolzLRcN48C58fGl+R+EyeSAgKZrTKvnKxbs6GvOUgYCspDB7Tt3PGPIHqOgq
WPNZ0uUgmx/GJUO/qwqVWnMbaHsnE2ZYJcs4HFJWelBwSPQcFOh1OqxldSYTHJgHTUYG6wSOcyq2
20AMr8A8Ms4+dxY1vuNFNu40zKnW25gx6aWs1B7vo+hL9yGYjMg2hck0jiGs5z2ga4yeM/jLq6qq
/XqZjM/JZSorDLn+cotk1h7bYM8d37jlxvYrqk171zy07Onon7ffjLOeWP4v0qroy+uvjj4TfSH6
VvQ3ZctC0WcybIex742X8Kz7LOTXS2HQn3qwqQ5UjLYm9MflKGaLDzoEh/1Y0MHqMtnMgzpBxx0L
6mTb8/J8mTvMCWG8gnxelGHjyHgbEzkQgZD+mQyIVnyyRQiXZ7FmkwzUQi7jQSvYSn1FCZNXiS3+
8uoqEkE1QAZyZvD4ufuurmhvn/Wjbavujta5vWaZ1Oz14LsN7Ws6avJmuXJXPHx9g126sGLd7Wev
P/ph7/wVZkNAZS1oLGWv9An56arAxVzWaStsXrPl3x65+FXy+zaQgSQPZAC+XkIC3YjneCcv8hI+
S+fJ9vg8j3okStbj8WZ52ayDArggCmTrtIVt62xAt5nNZI5mwWw6FjSzMqVCeSyo4D1uN7IJVmtx
FtqhJSIrpwoEcLYc0d0xIYPEeutJBfp2huwY7swSIs7g/43RJPbjl+kx5DZlsXR3JtfBpedLGJ7X
J/SPvjBYxlkL+EuvJ9eAfWKvq0SY+9iQz+9Sr1+vySkvGbpYWZ1j1ksDAaWtQChll8RXIPr40qa8
KJsZbIjOaWx2oPgaSJfDGtSguxNrUFqYxqYdEAp5S+GB0lKTXMJaLdZjQZnF4C71szllPJ9zLMiz
aIdXra4r1O5wJCXsfwU1TpgeP+SsfpgfmSURpudLsrV9Jg8Qj8USN16VYOM/ISuzljEDHRSWvrBm
ycW0/MpLF+pytNF6icaan3np/aTMmLTKPA6fTsurYlRF+Xrpxbm1nrRAQJdVvRAfiK7l6z0ZRjBy
U/Q3oMudMTf6XTxvzgy3LhDQ2AsrqkCCS+D8jFAJfichwYoqu6A0tdntFfnIX51lZisq/MeCFaxS
42EL1Pn5BceC+faMqqqcarN0p15fV5mdc30JlSIR4yt+v4HYfHTZjlM56P2gM6BMfiJN/kt0Mfkk
mM4hhImwkvIkIqyq5sEKYB578njL1CIqUIxdskilR6dx116KFeUYlTLWrLG7o38Uo6+nGw0qbWFF
dLfba5GmeWrwu9iMi/DzUqOOn9Hx8Z0zW6nADJkzgvj3Xb8syZ87cKmE9TYHv/VKtGJ2HZG8ypbf
UMr2z6nJ5QIf/ydbmbCRkjtAslmoEN2YkG2ew8k6waI7THJTIVt40AR2/FjQxEoVcsWxoNy2Ize3
KBvtSEsq5SvTNjw5CSd0MuvzmU3fupPakq3KTFW/cgtYUjgg8irJbk3aTayyeosv71Wm+dLHm899
u79hUWRzbe2aRS2ejwLVLotimqo9+MOR08sl62u/tnJwWwWTPC/mgSzKwN/9cUIW1faMIr+/iPWD
L1AEvkBRkRZry9nyg1pBm3YsqGXLcphcjJljQWzPKK7dYcnlG/3FO+RUNtzz5c/BWVKbUDP/9Gle
dhxqiagKv3xfSb37fJYh11ThWYkrBxpoBsWzUuXz5OVR40dUkQUTCNue+H7MNZO2cevmbzVUtOU1
b1o2uz+vsXBBbXRnXfs8vryyuk6bX7V6oHNwpnVox6Kp0nXlOBau71i2f0mBynl1956+PlWg847v
zBFs0Uc66nO1kqOXnvPOHWzYswd2d0/sPPss+DJl6KW41B9Qu93FVvJhox5cCitK70wPp4OvkW4y
EesvmCSlxNco1ZWBr1FWXMyy7MFiY7rNVuAa4rjSgiG53I8E4t3RE4ke5+DmfY5zQ6wBLMHljou+
dMdC8ec6OXHOIaPFklTZvBJwsIljbbHS0yaHOIyW5OLwOZ48/a/SN62fcWVtyYq+eTtCZdf9bjz0
jcG9xhm9TbWLK4pXLd/29aYNP79xxa/6cddXN+WHmhr6ukvyepZv6dh2b8hoi748f0lR/vyauoVd
FcK2A+FtD/ZbLbiCaHg9eI0cex5uBn50PqHhc9UFbMEdgqDuVDPr1FitlujM2eadZlbFmu12juXG
BTuX7zkOxg77WR/ycT7GJJH4WN9hiQVhdb7EOez3VypMgrloREH0/rmMs+TofcXqpwInJzHYR593
ipigwpL1CRsx868fggBjiLP9om5C7jwqXU9lRa47bjpgK/CwQWAliDWmZx1LF4MuFfMtXfftX1m0
cxZ48Z7CQElJU1Xaj6647qtX+rYeaJOlmTLzo/tttx8K1pd0l+6SdrY1rmu/+V8tS5csL3CG5j9U
UJSpEW7aGb0u0Mab01QB/KJk9WDDrLLuEtD4PtD4f4Z1yEIbEquQxamH1EbWOC6oOSSROFjHIYmF
E3RwAXHadskTTqn/hYwJJaaThJ3/FJGg+ZPNL0tmauUQtlI5JHXQTD1wOKpMVEXZzrnLvr/6pde2
//7WrrsDZ3T1Ne4mf1bRss66q+AcDi+Ivf8vf9hmNb175SJ335FNm+7+SjmxnKBXY9Jx5EQ+9L3E
jCqzMo8Hs5ATm3LZ3HHBxMkUrOIemUx6PCiTKVU+1pvmZb2HhDSLQmll0bDPV5a/i0t630R3iCFD
ZEnJmnK/nVjYxkaqNQVfuoN4w8/mFcL0pJHy1XlTRFNJDafbjys8iV1KFUPikBryfdHzW5W6tjvb
H3pwzUtHihbWyYyecmzeHv1198KGUPGiPu/COpw7p6XQrmpS3oTb53908Z43t6i5vqtDvgxVk/YS
um5z6Nsbf/y4N1QHEiQa8WfQiHSQ4aMJCdY5jaxzXFhnxDpjtnG+calRYmGNRhWrAmM0Lqg4lI7V
bDrLWljLIYG1pCPDcEZGjtM4LEseze+eKUeTdkNjxqRzYkli9/n+wm6m7K9P4RhyTxaixUqii+pW
NUt3nZz99Yonb3jzra0v39y3d5nTYzThS7vxzhvmXNf6I0lb59w+5UOrF8cufuOtrYUdlY1dCzY/
+J3aNtxx5PDRm2HvNCDEeqRHkRsdS8ip3CgoNW1G3ZAORjgu6HCW/HhQmtUq2HU8VDsedGdmZhsF
Q7Y9W6bJHpZI8jx6A4Yhv+I/o/dzL9BDIunDZLxTnlQO2C9nqYRcX9jBhBvzyeahauJLEztTTQSS
2G+gTWa/mU/4gD0+N3edz23TstxbP1vUtEdf4PKW6B97jCuoiGoD2pyZc5jBZrk+syT3gYe1T1VX
1K5cOmf7pfGOhlxNgPw7vdyoIMkE7YFNg+ZjV0IuIcE5L0+l8Cmq2epxgVUofBxG5eVQv1Uo1/lm
sjPHBR/HzWN187Ln+eaxVnaeoDW0zRM4WwvbMm5ztJukTZkaXsjkCzFTzhYi6UhdXVfFcGFil757
xmCt5U6fzuDOQkx+PIBD1wvKcHmLJVSEOsa1Se8EXBci2ll/2xgFmyPZzV/QbQjnyS3ElQRPkp69
fn/SsywBB6iq2kO1lz4aGGIJXJjufeocySbOCHqK8DmSzO9IHO5nzw40lqfXV394/NjWV29ff/KG
1rZZhZ68WRXzOps23XmFf54br7y0pHVOc3tr++zW3Fz39tEdu2wtwr3t7GKj2tEfvO8BQ3FFllN/
w96rb+syVV7RWhvOyZpX6+tuyi+6MbxkpCdPJYs+umPbhk3brt/48T2OgLetuWdOTqmT3DHrwI8f
BQs8A40lVj8/T69lCwsKjwe5AvOMLDsLEbYvV1N9PFiD6rBi2GyeOcM5XHrZjQdjmDSV/om7IVml
zM/lRT93fEq7EI5bAPPEPZKhvijVfqBJKE1CaCwxs3r8dN+NHWu2VLMas8cetfv4tLTssnzPgmpW
pjbkOKKWrByjVsKqTJ5CsLTsFV1NXeNbozcXzS3JNMFNUl04eymWRtbOzPJ1lUS/VjPTlWExAF1u
TM9rFljNoq5ql0kR0F76MfGF2gFmSteCptnRAwmZ1bIMyw4IOmY+w8QYrGMeZX4NGYkSMRzDcCyj
v0en0x4P6nTpErvkeNCODYxhWKHIdCQMymnu9OXLEJwzxCpeuWT9hoSpLf1L+U+6Hk3nFsIgPTYh
Uiq+uETxM9H/varMnaZM9+Zg4/aE6GzStR988NGzaYVtS/EzZfW5RnlQcak2KSKiQSAPySGwIbXo
UEIaXitTy2akZxwP4nRz3j1udy5YOl2+XlusZbWHhGLOPyyTzcjKzzMOZxElondfokYTmkBHPUmP
nF/EcbIaTW1M7zJ0spKE/lz+UJEQgNxKNmsWE9c3yaGovSQ3TZZmdeQ6PN01GrcvmlnqTpMa80qx
YYdO03DlVbXdq5syqbYF1N72pVjd2leXl67xLfBFdy6d7VUHAlRgt89u9dpVQcVNbHWj27f4hkXR
g3GdQ/GTW+IHuenAm/tKQnI2RH0xZFHCRhkXlJxml83m5HZJJj4uXrZRRC7c9PqTjRjMXZozYYqI
maLGKHFVk8mYGTc/v2X28Pevfu/Cda9GH1garmz1GpYuCXZ7uKt+c//u00MzYxfue2sDo3vu2aoV
N4Z+9vyiexPrzZL19qBTiVHX6LEaKTgFo2QVEoFRG9Q5alYvkahZNXiTnOee3Fz+eDBXZ0m3pR8P
2hSCXJ7vAZ8jc+K7Cnink/U16ZeTk5C453GTX/KXdTN1C3waS/Bo6cka/5asZT9NN/B/prXftnhm
04P66hJLZbFRpi0sjxovqwPbxS6akxZ9u67BXuavqIg+tnSOVzlt+YnUusBPWwxS86Fnk9/d+dgb
31dybSqeN/InY28IZfEX1moUjOCIjxs55AMHylckFMF9cbzIYrNa87JHdLqSvBGZrAwJJZ9+UU1M
MZklF0mvngD9Ej+9V9fn9yoUWSa5JZ/BNnFLnXZJNccvqRN3VC1DPsD8zDb4lY65fNey6v62wsHH
vta+f+2wtTpQEpjnaLvqys0N9atv7fvWf2BtX19wVkFdpddW1764evFwi8b0ptBir6/yVPm9eQvX
zu7aNMft+wNI1g2SZSQ/Rw50S0Ifi4zK40G5UafDGlZnbBU4nUPQcG0Oh42FSFxRgwGZOJNWYYp7
vGf84M6dBl+uMfnZl9zF43qScOS+iOOEczutbdKpjTtyfrPL7NLHL0zg1TK9N3Ueunn7THDYpX/A
mdHfmMvdjqIy+5aOmXd/k/E1q/KbVnd9tD06c/1qvyrDRvRIIDcm9hwqRvuSX930xQaEio8HkY5V
+Bz3ZKgzs1i5S87KDwkuS6bDNKxW+5hhd9KE+CffkH4Lljf+UTd+Xn8ur8nXoSkNQ0byyZehl5zk
x/GpNyMPNcB5Ah7R5JR53N21Mn1uAd6dvA9plhycvWpnDZw5RpeDPXfp+fDqxsySBT58Q3trvl0T
uBRMXojYRcH5R7biNTX1LjucQCARe+yCbBlIxI12Jddf7chmFcZMLNWm83KlUnE8qNQhg5ll3chs
MmKWMWB4U6Rn52nJhwc/d6ZcbyUuXvwH+az+xFfZ+PGT/pkMwchMqRuSsizPxj95U2/PajT6jcb4
r/Hol285Zt/84S/+431LlseJ3/T5ONX213/w+C6TrrQIb81yZbr56PsqZuTSNubPLY08eCGKAnf6
zJxoP3P/pS68smq2o7BaHmhS2go7Q5fmwjnyPThMpNKF4I/IUYagYVlGLsqQlJXeLwPN5s4g36Uz
jWWlGMZFf/0q7fv2fFwYfV+68OOV7K0XX4r+FJeQ82g7KzIXwBMkfGyCSiZnTrFYIkes71cvgGHJ
OEv+coVwkRJOu+cfKGC2zjuYLx2PpuPfYQLk19GRRHwPvYeHGRnEJ5kn2ZXJKLHQeFRyVNorS/sf
G5+RPSOvlf9csVbxZ+VHqpvV9on4fY2RxvvS+tJ+qu2D+ItUTMV/2BhLxVT8x4y6nFRMxVRMxVRM
xVRMxVRMxVRMxVRMxVRMxVRMxVT8/yXG/xwSIWYH4CAeQjJ0HkmQLPY8oCX2JuBI7HXA3RRHKR6g
eDj2HOCttOaR2L8iCVsVC0B7WexVQEvsfcCR2HuAuymOUjxA8dbYu4BHYm8gOZLEHkByaPsqUkK+
G1AWexFwV+wY4EjsKOBuiqMU98TeBtwb+wHgTbTmAUq/heYPxR4EvJVyOwK9GIFnE6AM+jUCz/8C
HImdBdxNcZTi3tg5wAM0fwhmbYb6PyX/ByH0ZYb6vwDcTXGU4gGKh2jpYWhrhh5fBDwCkjHDXH6C
LNDvK4C7kA5whOJuiqMUD1AkEtgF+DjaBa1OQ70RkNsI9EVwlOIBwN1Q51loeQR6HKU19+A30D1o
D1sFuBfm9Qfy/yDCHMcotzFaZx9tdROl3EQpByD/PDpA87dAq18BjoCsboEeCY5S3At8bgFuFwAP
AOUQtLqADkPN1wB3UxyluBckfBjqvIZupX0dAZ4/BxwBOR+BmgRHKZKaR4Dn24AHKOVQ7Lcwekn0
DaqDPqYu8ce5acz4xB/yatFq+hb/3xEjrCSRx0jLDibyDFKoknVYVKfakMhLkE21J5GXQv7eRF4G
+dOJvBx9pPplIq9AheruRF6JWv4PcecCH1V1Lfx9ksyZZGYSQGkMSnGKXIwWAkVLI6bgE5WijQi2
Wh8zZCbJDJOZYWbyQgzDw4iIjyLFqIhoLVXr7c21PtpcbptirnIpja0CpYg04iNWMQS0IVjKuf+9
z5nJBNLvo/d+9/fN7n/OPmc/1t5r7b3WPqkkzl1W3mF3pGU5xY2u0VbeJYpdKVmpMWenx5z6PYhT
XI9aeU3YXdutfJbIGe5L/TZN8eXh11v5HOEafouVt5EPW3md/CIrbxd3Dm+28rniS8N/beXzxDkj
sq28I/uutCyn+OqI8VbeJUaOSMnK12aP8Fv5AjH1tH+Vvyk0J8/Ss5k39WzmTT2beVPPZt7Us5k3
9WzmTT2beVPPZt7Us5k39WzmTT2beVPPZt7Us5nPt1aDzJt6vkn9Dku3qBFe0ci1VsSFn2tCVIsA
ebeopEaYezc15H2U8hj1AzxLkPfxbL5qK9vItleKeWK2uNRqG8soiXIXoUWtqFA9BujZLeqVrAq+
h5Zr3su6FSJEW58lNUENNzlZHqXEnIGXej5LVsDqocLqy6++S3hy4rxleUjliml1Hlc/ZfPTkoYa
Vfiknk9dRwO9+1RPVTyLcR+nRkxpI6F+v2j478zdlH7yuC7O0ICciTmXhJIXVdbwqv7Nufp4Uq9m
HuH535upqWfvIJ36lV0j1rc5KzNfy11UfbvVaOvUbPzpfmTNEDX+zxaqVpqLimliEqlepRKl0Qq1
huJQqWrKljXUSTAjOcMqNccoPTSqv5Bs9hsnL0dTSVkt8mVLr1o3DeJZ5E8Rk0kXkbv2JBlucbma
aUp/KcuUqN/2GiK5xRyeValRx9WdX+2jGLOX9iqhB6+yuJyxV2nBXClyDfiVLX2qjewlbNm4Mq3f
sJhIWYVaIWZtmfNmrJ2UzU0dS3tGxAJyVSrns3aZ2TbTij7VVs4xrvaCORs5jkVqPHKO16jy1Ijr
1Lwa1Rqus3qUepS/6fbE0Zj73dTbwHqWfV6h9FClnniVzFQbs/+EsoJZUq1+126MfEDpJp5R29Ry
AF2ZT2NqpcXUGjMtVafyjapuQo1HjnFC2u+EVItqNUY5a3O9eC09DNV7pqZS4wikV++AFcw9Z+rN
1OfAGBZYXiCctmFcjdubsZcSqm3YapWSFLH2llmvRo0xpGZpanZuegen7CztErXmaZbUqNUtewmr
3WvuUC+rMVUrLAZ8VcDSh6wVT6+kWDpO+K0VV6+eVqj5+tWerlY68ypvJssGa7EWeTIWZHq0uNrH
oQx/MV/lvRlzDijtzLe8Zcrn+lWrGsuDxJWmKtVopWV97KCAsltVWlPfSe+IE3enqSUzFmbuxArl
WTI9c2rvpPaLlFpn2U/6FLda/ebqmJChr4EVE2NkJ2vq5D0VV2tU+i5fWitxZRXT75hrPKZGXKvs
mTnyAW2ZUcb0gQMrxn+CBzJ1EBbnqjZBpYuEGLzOT5RQq1qbOzRuRZcKng7YZFqGNDmOKjUOr2pf
ryxrzmUo/+jHUw+WXK9WZrUVm8x+qiy9+FUv5gqosXZVpteQevWrvWHWb1T2j9DLYJ1cZfncBRmt
L6e2GUPNPXFq3rzWGrm5jkJqB6b2QdSKFQHVJqJ6MMfutWyRWivhjPhj+qiE2rk16RZST1HLh8bT
fs6M4AFliwEPldKTGZECysYR6/xh9i5HXz/IA3nVbkrt1xprJQXSESqgdojbiscnrquSIeLrtCF2
4GXKFj5VZsbmqeJGy4ekNPR1eruI54PbTky3HXpX+61VY1rCm16J5uz91g5yKz/tVWOvUXNeIFLn
He/fLZX6P/Xzw4l+dh53gXRUvkFpPDEo3k0a4sRVobxC2Do3mr7tWtV/JMMG11i+78QIPVd504jK
mXVNf7lA+Zv/N2cw6dMGzmFD9zpQbvX2rHvK5MkXua8NVMQi8Uhlwn15JBaNxLyJQCRc4r40FHLP
CVRVJ+LuOf64P1bn95Vc7q2ZHwt43dXeuHu+3x92+/zxQFXY73NXRmLuSHhivCImH8f8Xl8gXOX2
hn3uRMQdikQWuKsiEZ+7vprSaCwQTtDGm3DHa7yIiQcW+eMl7msSquM6f6zR7a+jYjzqrUh1E41F
GJscGjWvCHirImFvSJVQPxGo4KbaG4iFAmF/XD1myIFKsjE/wwkxqTp/qNEdT8Qi4aoJDCQQ8rur
I7HAokg4QeOM6uagZB9ynOYU/DVRxsY4VQ8L/G6eM7S4G3VV+2PuRLWX8SZko0htglt/TdwfqpPT
mlsdiKs5VwSiyOSmJhJPuMMRRu33zpePwrKBO8A4AhVxqSRGIZ+EIvX+WIU37ndXVHtj3oqEP2YN
sXa+r9YvB4jQRrpgiPP9UqM0C8TIIwFd+kP+Gn8YE0Yq3fWRmG9ioMZbJQf1HWmIlDkZUm3cMmKF
N6qUrKwj7eKOoGBWijsaQR0T1LiUYmIT04NKWypeHakN+eRQ4iG5dtB4zO+rrbA6V8OK+eO1oYRS
jN9aQIwgfG7CHayl2NR5qkFtXBo07vZFKmrVTKapZjF/VW3IG3PX+6WUgfXob7Aa1wcS1W6vmzpV
jMWfkAqo8cpncmlUBPzhCp431syPhKyRXMXKXaCKL2+MBUJYYohlXkvn6CgUiUsbRNkVgTjakr1j
f6WVsNo/rKiE31sjC/wN1EvE5ZqLuL2BGr9aUHJMbKRAPMEalKs37K83F5A3puxag5ICckMFoli1
MZrSVUl6v05LG/CySMg3Te7mqTeyQuSAvl5y0VSrdKIszTC1P6BWrFcqEfGsNQYU8/r8Nd7YAndE
lmTcVg7tH1Jrdl44ILfyDQlvwtx3k6QjUAIqIrXhRCzAars2wmKXM7iG1Zfa0HMDsYh7Lk9Zlwvi
1YlEdNqkSfX19SU1KXklFZGaSbSLVMW80erGSRWJSvZqZlV1L6vdFKnFvI1yGTMsJilL5AZA9TWB
hBzi/EY14Cvnzb5ULS15g1Nhcco1Jx1CRXVGW67s2FCtzzSXLxCPhhBguiIMzfTkQk2UuFOyI2FW
e3HgPHzFfNlooKtwqvKQI1LVlbtkZ6CwCnP/paUrTVt9XawGUBxASgKXhDFYqo3sjvpwKOLNFMqY
vZanjbnTNsE3RXFPPn8dvkfWqfaHoidM6FRMoRQ/yeev9LJKS7zxaEPqZ4t8jIfFejHUR/4Vnzzh
EE5hNwwxzPqLPjoFxVyTQqR/Jjn0Jyd7qsulUUd75lTr5+fL+lmn3P+wYar+Kfc/fLisn33K/Y8Y
oeqfcv+nn079HPW3jHJFjqovf8J8pvX3ifLlvw5Cp+ei0wvFcHGpOJ0z3JeI74XE/+XiTnGXWCma
xUPibvEkuefFPaJNrBJbxb1il3hQvC++Lw6KteIL8QPNJtZpw8XD2pfFI1qx9pF2UfZUbSZDvG6w
fG1OhvwC5I9G/vnIL0X+t5FfifwE8pch/0HkP4b8Tch/Efm/Qv5vkf828v9M6RHxfS1LrNXykV+E
/HOQPxn5FyN/NvJvRt78wfKzXsyQPwr5xci/FPnlyA8gf5n8fz+Q/xzyf4H8/0D+75HfhfwDyP+r
WKU5xL3IelCbgvwrkX898m9FfgD59chfhfzHkS//aexLg+XnBP6b8t9F/qfI/xvyXcg/F/lTkX8N
8uch34v8GuTfgfz7kf8k8luR/4vB8vWxGfLPQv5X5c+o5c+jkb8Q+auRvx75ryD/deTvQP67yD8u
VmpOcY82GvkTkT8L+TcjP4L8xci/B/nrkP8j5Lch/w3k/wn5Hw2Wn+vIkH828qcj/1bkL0b+Y8hv
Q/4fkd8vlqPnu7SviGZtkribdbRSuwX5YeTfh/znkf9L5O9E/gHkfyHWZeWKh7OKxCNZk7SPsmZm
T836LvaeL/1Ebi7/KyqaMGFm08yDubrItZf52vn4ynLtlPSHKvmE+lXJMZ+nwePx9Mo2eUcqK5so
OpKbx8jfS8qj8PdUulx0J2Vb+zGKF1vVc9VNiOo2kas3bG3vbShq6dV1oevRlqKG3Yt1G1met2+N
5ulanr20iKd8zILo7n5ZYBN5OaX06JGjyJONF+/eHU32L17Rn2cXefYuj6chxKcnL4eaHo/oUjV1
u9Dt/apASrQ3bOfToIQfSKgKORoyftcVbe2S46NlP4+rJ6uGB2TD6Xqe0B2fJmt4V5iqUm6Wlpsj
NdUu2tuzs7U828aNG/NyRZ7S5oSmmTMPqomY6kSfsizvWGWF/FQeU+M9Pt/jW+yTc8mj7EiyQsi0
RJjXI8k8p8hzdnUtbF/YfjNpNumS9ne7ZNtcS7u0NftV6q08kmdDJnrsipYqBWu6/WQF27W83NEu
12LUsDes22SdIRVMgaXg1f1qaugzVCetfoKCc4Wee0AVnJKCbWkFy4Y9tAt/4yQF52VpeaaCLQ07
pIYdDuFwuISLfSDTOWKGuDR5afK9doddc+RNr9wi62+pnO7I0xzO4/JnAcmBVMFelfVyU4r39Kp6
J2pe6t7h1Bz5g3Vval8Jkvo21S87cBy3mlWyWStJFeKzpENH0OLtHVhi9Ort/Xa7Zs9tWC2V3mS3
aXZpJGkMRy7dFeh602t8Ouvtuqy2ffux9o4Gh004bKXVpjmQlCvsuTMqK8s8TTMuf7XJQcTP6xIe
Ulj9/CI98hyapWzj6bXnCXtez6Aacix5i6XA1xbbdWG3KytR1RwXI27plWvBshOGUp10p7uoEhcn
7S5hdx2Oznd/w/2NSy6+ZFRyVNKRhZHa0zbLsWlOfffuBx/8nxtNKsmo8KaM5tAcrs/azfIl6Zqf
tTtcmqOgKxrtinbd5LnJcx3pCs8lnq5e2YHjuNx6TWmrZxotpIx2aCij5aWMJi2zuIORdjQ4czWn
A6OlrSaNi0KPt29Z7NSF01bms1R3ktmcecLpMM12CoZznKLhZH5xR1fDaDYqhtMHGc5xsuHy/6+G
s0vDOZ3C6ZSGK8Bsp2M4TIfhLm1/r0upYEaFV7XxVsxwOjSnC5ViB097KmG95HEhq0rrpfacqpoy
32ADOl2aM8OAN2eYUAlMm9DsxWkogXKRNGHBKjnH5KF2px2BTa9t6YqWFejNrx3LtWu5eQ3bXWUh
7Chvcssq5bDnl7nyhMth5/gs0wyav2olqSjVrKwSq8qaunDpA2b19LpkFJwh/YC07KuvNqm+hrKs
tJwzh1WRti1BUYbNnhMq5eZquY6yylf5VJrxt6fOqq4zaBZfb5lrdb/0CykLY2LVVXdGR2rs+SK3
4LPSiuEVw7++Uaai9qJ2Z1aWU28fZGeXsnO+S+S77Jw5hgln0pk8KzmifUT7jHZ3l4d0qDc/T8t3
np1cmIwmu0RmivLsbJHv1PLzDRFPLmyXhhtIC9vjSUPI1g5DtY6q/2OnSf1A0Uz9CNbyC472DrRa
ktHD0d78Ai1/eG9ZQ2kDn9DPZaoqlWl+qae0d3G+Q8t3mbLNFE8uOaHz/BOL40l139Xfm5/L0GbE
3+3qbSgbM8x+d+exvDwtzzFddHPCs3MKqyJ3UNQn83K1vLzp9e918Vk4XQp12pPZKs2gt/fSqT55
cbusjBm7uw1V2S7y9TFTo9FjUfPTn+8QeY4Z7XIYMs1guSxJziC4tLe/y/Dynfyv15pCfbKxfWFG
+mtXvo3+olEhelP9qWPCkZMqyqk4p3MuyxidPFTK88KRJXGrLWeBvKYP9/cuHnN/5zGnXTjt0ehx
s+NYmer5s0H9xtu/2ZU3TOQNO7ph4eqF2y/eOm13We/oaJGnyJOfreXrXamPAJuuFeTKw4D5X6Q4
OInuE9kVjbGQGFkV8y8QU0PeRJhTtkNoN8y5zC3/8itvsOZ/n1Ng5TVOyMPMP5ug7rM4Fw+nZvY1
5eVXi7Fzvn2tW5TMnfMtt/ztXKpGNv2NsPLsO3GalbfhyU638vIdb6T40gJ/LCyS6rtZfa9W32vU
d4v63qC+n5Y/thHPqe+98lsrUN/T1XdUfT+lvt+sWVCzICtLfbvUd6H6dqvv89X3hep7evpN9VS+
z+CapWZkU39BN9d652fvoqth6GQEMz1dzgrtnPHfalH4vy7hf39M/2j9bFHE++aZ/6PcWbyl38Ip
YjFvievF82Kz2C728lZ8THNpo7UJWpk2W7tFC2mLtdXaeu15bbO2Xduryf+aMZc+XIxmtNKL0H5u
Xp/xqauW/V31d5LlHtDke+KE2wbfX7h/8H1px+D7suTg+6tfyLi3CW1u4eDyuU8Pvr911uD6gZ7B
5QtWDC5PDB9cnugYXJ6MDS5fetrg8pUFg8tX/nxw+ZqWweXrxg8uf1wMLn985eDyH50w/k2LB5e/
wHiyUvc694+KPC3j/pWPRF52xv0vW4S2cav0TvoY10xX0tXsanFtcL3o+tjVn3+bqyW/AZrzN+dv
yz9WcF3B+oItw0ZS7+S0gdScTi2qlxPTx1ai52Fj82+T/Q+RNiCvWclMpW0yId1MW8w0bKRMrpYR
2wtfLmwv3Fa4o3BP4YEzdnG3o8hVdBr3L6uS9qILi9YVdRR18ryr6ItRRUVdo8arshPTHtK2VBo1
QfV4Qho184xdMqn6O05MyEWylK1aD/TcPkTaw6jWqZFZ6awV7g1fGS3HOUTPX1ipy0yjxst07vnn
Pl/Yfu6HxbnFBcVFxWOLi4unFJcWzyJfDU3FHcWdxbuLPy4+dp5+Xvm5H56caDOWtqlUpHo5MU2x
kux5lur95DQWaU1KYip1ynTebUhXiRGYqVym4qLzJygtHEhpckB3hTsmzpl4C2kOaf4Fx0pLSktL
p09bK5HPyj6cvvnSmZdtTF2vHH9VmmvartmbYlbJrKdn7Z/tmvV0+Y3lnvI3y3tnPT330fI35/nm
Nc9be/O+7628pen2cbLUW1D+5s37bt7nneud7w15m7wbK+ZUfNcX8+3wHeZ9uKByZOXYqsnVc6qr
qxcFNge2eOdWzAnsCOyoFDwjBbYE9gT6g/sCe0LVoXCoI7QrsKcmFOoIF4RHhs+MTI5MjU5WZR3k
J0dXRZ9ZOHbh2oW7FnYt7Im9GJ8Tj8abakVtQa2n9qm6UN2qulU8iS5cW/dM45jG3kWX3dG6sOvO
WfE5d66t9TRNa7qiKda0smlD02bSFtLWpj1Nny+ZteSWJbeo+5VLKpd8npyVjFK+J9mcbEn+NLk3
+XGyN9kHx5ZmLR2+tHCpe+n4pdGli5YuSh4j7V2aXLpv2chl1y0LJXuXLVrqXrad9Oayvcs+Xta/
PGt58fJpy8uXz18eWl63fMXyNcs3Lt+0vGN55/Ku5T3L+1foK0auOHOFe0jPkPIOmWnQjl8xf+hk
7vMhd2pqt2YmuU8G7bAViYEkSzPvzV001I5I74rMNGitr2geOpnre8WD+duKWPmFO/CmLSvWpbya
68UVrfnHXP3Sp65om9ecv21Fx4ovpA8bNV6ufbTUYulK+UjZSpaRT2mwRfniZvpNKi+c1mPBFu6a
8ajb7sqllJK7CvKb1dOkSs2Z/jWdlJeXSfriTH+c30BqHtoPy0igYoGMButTfli1p42rX/pkqf27
tit7HGgew65mfvjhzuZEc9Oo8c0PNm8x56x2fnuGn2s3LSs9LJ6AXpq7ilyjxlv+9uVMO0vfKfPN
fYUvK39uWb2oS37fnXP3mXdvpE7XyoGybRmSUqvmwAp3uve0T5d+yPREKg1edxkrzPLgGT68qNNM
GZ5brrQvZNwxI49MhS9TB19e+LJ7Q+HLK1dyfxoaUSPHlxetfMpaawXFxfe04sFLlUfvXHXaKrfp
P1mjRdZKNT0ztZVfnZJev0UqAjTRX65Z30zn6eQL8OKdxbmy5qoXipvUs1yVCgb5dDOZUaU07f8H
IkA1qWloz68iz27l+4+Z8UeNr1NGAqTJXmTbUhkL5LxXddxbeV9xYft90/mWOm+/7/n7C+8vb+4q
3DGvGa/dbProm/fdXyd/Rnl/K362w/Sokcl4+lNMePYTEtFhUBqixpuD0zyfOZKBdHIbYsk/mMyY
EtiRuqbuUveV4oQ0snKkGX/+fiIy/SNpz6knotng1DE4EfsKTNsMlYayS92qhWuJhVaSdzImmvFQ
xcQ5qVzdKmLoKqJnl4yTKn6qRPwkyZZ1q+5voyVtF3bJiKhipUrEyJVNW81oSX6zebUipxlPZdqj
0kpZm7qzHsglUmYRRc0YqhKRc6+KpCqKqkjam841J5vlDlH1j5mJiCuTbLXogQJa0c6KWTukLyxy
PVD8wJvSLz7Qbz4t3PHgMtO/fN+1pnJNy0NjH1r70K6Hdq0Va3+6tn3ta2t331f8g+Nr2/EdHety
Hn6qqGPU+Ie3PkyNzHNmYXvL1S03m77L8lado8Y/cvUjc5Q321F44JGGgfNyUccjP8VXjX/k/Ue3
PVa+ftbj4vFtGzY+MeWJAxtf4Oyxx9Q0ulF6Wuo258a7aYvxQ7HTKBWfGge0HKNPu9U4pAWNTdqH
xm6t22jNLofrjVbHRlHmeBJeEGXO28UU3kNajAO8gbQY+7XZYqTVrpvnO42DvNO00D6HZwNlh3gX
lrU1o5OSVm0YNb5GfrYo1q4nf6vxS62C+yAjScKH1Ok2dvOmSit63U/Jbt57W4xGa7RdtC3TvmPs
1W6Cm+F7cAvcCkGjgz6ep4/ZOTzL4VnObXA7eMALPvBDpbE3c4a8Y7UYz0q90EsTPWxCD7vRA6NB
bif9fyLHp2bUSb02ZiVHtJ+Sbtrst0Yv23XSrnNQ79lKO1Iz3czMpfrYrzTTQR9r0MzODM1IaeuV
Zj40SmSfvLe38P0pTzSl5Sdo8RYtNit9XM/1VuMVWmyWGkOXfbRM0LJN/5bw2e82bnT8EJ6G12Er
1j+dHjssrf6K3rot+WWW/Fcsy/RZlllOb51/t7c8OT562q1mcCvXIDP4ELqNIK2mqBUkZ9GEzN2W
7jYhdxNyH7Pkrrfm3UrrVloPp/XDg2Ra8pzTjDbn7UbQ0msQa3QbfeI5oRtdwgGnwUgoNA6LM9B1
kbFPjMKWZ8Jo4y1xPmVfhQkwEUpgGlwMZfBNmAc3wnfgu3AT3Azfg1vgVrgNbocK5PjAD5VQBdXI
DUAQFiA/BDUQhghEYSHEIA4JqGV8dVAPDdDIWBfBHbAYpM0eYQU9xrWf61H4Av4Kx3j2NzgOBusK
e2k9aOcgHIbPjN1Z2WADO5zB+v46TIWLodzYz7rdn+My9uXkQwEMg+EwAk6D02Gk8VbOl6AQLjM6
ci6HKyBhdNpmGF22K+AquNrYbbuO67dhLmXz4DvGPtt3jbdsfp5Vkq+CaghAEMI8j8BCiEEdLIVl
cBflzXA/+QfgQfg+rKG/tVzX0f8jlD9O/gmePc21FV6D12Er/Cf8zjhs+z28CW/BDthJ213wB9gN
f6SfPfA27IV3YB/z+RN0wbvwvvGWbjM69GkwC9bAQ7DW2K//ALCVvoHrE1yfNToc3fCRsd95A7aZ
JnKM1cKGP7VDrvz3xuAEFxTAMBgOI+B0+a+AQf5b4TOMNlZzH6u5jdW8U5xlrGBFt4gvG5vFGPo8
G9zwFRgL58A4+CcYD+dCMTvnPJhEf5PZlV/jOgUugAvh6zAVvgGlcBFMhxlwCVwKl8HlcAVcCTPh
KrgaroFvwWy4Fq6Dcrge5sANMBc84IX5UAE+8EMlVEE1cwwA+5sd1McO6mMH9bGD+thBfeygPnZQ
Hzuojx3Uxw7qYwftZAftZAftZAftZAe1sINa2EEt7KAWcSd6aoIlgGcTS5n/MryRbrykueErMBbO
gXHwTzAezoViOA/ON2ZrX4V3DY/2PnwAfXDE8KR31J+N1dkfwydwAD6FHjgIvXAIDsNn8Dn8xTiQ
3QdHoB+OwhfwVzgGf4PjxgF2Zx+7s4/d2cfu7GN39rE7+9idfezOPnZnC7uzhd3ZknOl8VLOTLgK
roZrYBZ8C2bDtXAdfBvKIWG05TQiYxHcYRywlcE34RIxkt3cZsOutlmAbW3Y1oY92dlt7Ow2dnYf
O7vFdpOx2XYrz2+D2wEb27CxDRvbKozVNmzMzu9j5/ex8/vY+X3s/D7bAspCUGMEbVHqJKAW6qEB
GJPtDsoXw53km2AJYEPbclgBd9FPM6wkfw/cy1hWU/8+8msY20Pk1zFWzjF4ij7bo9w/Rv4JyjaS
f5L8U/BD+BFsgh/DM/AsPAc/gefhn+Gn8C/wr/AC/AxehJfgZXgFfg6/gDb4N9gM/w6/hF9BO/wa
tsCr0AH/AdvgN7Adfgud8Ab8Dn4Pb8JbsAM4jeC92vBebXivNrxXH96rD+/Vh/fqw3v14b3a8F5t
eK+deK+dtv3GCtt78D5z/wA9fQjd8An9HQBOBrYeY7OOLB05+k7YZbyk74M/QZcxW/+IZ9TXe7g/
CIbxkp19ZM+HM6DCeElkEbN+xXlpvcrtIJcgJ892OcRIeabcps6U74g3hEOVfsp1mtgpwvL3D2if
iOeyNBHOngxT4ALxXHY5XA8RaIQ7ed4ES2A5/Ag2wY8pe4brs/AavA5b4T95vo3rb2A7/BY64Q0R
tj0sltmOi3J9ipjJyeMLfbZYrZeLKfY7xNc4hXQ67hVTHKvFTMd9QMRxPAw/hKfhWfGm4zmxzvET
6vwMXuH+59z/mrpb4HXqbDX+4PhQlDs+ET7HAU4G+ejhY1u/8NmOcs65E5aKBvsy0eB4nBobYCM9
PAkviHXOOaIhfRZ/R+SqE/lOdZZ6U54/qVtO3XLqlqt6RdTo4cRwmBNDDyeGw5wYDnNiOMyJ4TCn
hR4ieA9RrIcI1kME6yGC9RDBDhPBDhPBeohgh4lePfTso2cfPfuIZD1EssNEsh7hRPZOLDIGi4yx
LzU67cuY5eOwQZ6B4Umj0zkHbrfWwCFpfZEjz860K6ZdseMpxqpbs9iPPjvQZwf66kBfK4VdncAp
wQIdJ5VmWxp4Q53PNb4PqNP8Sk7YuzltypP6z3g6W54kxQPqN1msMD5Xv8titRgh7uN6PzzO8w3w
BGyEJ+Ep+CE8DT+CTfBjeAaeM46Kn0ArvAA/gxfhJXgZ/p0+fwnbYDv8FjqB84fYRflu+CPsgbdh
r3FUrgXNZnyuvSvGaO/DB9DDW8NBOAyfQR/PjogxOWcYB3OKYBScCWfBaPgyjIGzwQ1fgbEwzjia
808wHs6FYjgPzocSmAST4WswBS6AqfANKDWO2g4bn9s+g8+hj3tWke0Yq0MzPtedXPONg/ow46he
yJWx6YxNP4vnZ4sR+jnkxwHydeTryNWRq0+m/EKeI0dHjo4c/SK4mOdzeH4Dfc+FeXAjz2+BW+E2
uB04c+ucuXXO3Dpnbr0aQlADYYhAFBZCDBbR5g5YDHfCep5hax376pvI/9g4bA8bnzvyWN0XGJ87
r4JvkZ8NNxoHtZmsnA/EXazhZrgbVrIPiTWspm5xL6wmfx/X++EByh6E71NvDWv+Ia5ruV8H+A31
XvuIca941HiD/dko1htvi2ep8zz8M/wU/gX+FV6BnwMxRBBDWF3drK5u0Q6vwev0uZXrNvgN+e1c
fwud8Dv4Pc92wC76+APshj/CHngb9sI7sA/+BF3wLvXfgz/Dx/AJHIAexn4QeuEQHIbP4HP4C/TB
EehnbkfhC/grHMMD/I15Hudq8KYnjLe1LMg23mHVf6A9wXUjPAlPwQ/hafgRbIIfwzPwLDwHPwHG
whtOJ284nbzhdPJW08kZrJMzWCdvNZ055xiHciYY3TkTuZbAJJgMX4MpcAFcCF+HqfANKIWLYBrt
ZR9l8E2YDjPgErjMaOTNZz1vPutzao13cpYgI2m8wy75gF3yAbvkA9tfjEPslEO2I/CF0W3jLY0d
020zjHd0YRxi53ygM3f8b6OuG2/rDp45jW7dxbNh5Ifzxj0CToPTYSSMIt6eRZ3RlH8ZzubezXUs
bc7jej5MpF4JTKYe89QvoG/mxy47xC47xC47xC47xJvLenZat15G22/CDJ5dApfC5bS5kuvVcA1l
sxjjDYx3LsyD7/D8u3AT3AzfAw94qeujTz9UQhVUQwCClIW41kAYIhCFhRCDOOUJQJ96HdRDAzTC
Ivq+AxbDndDEm9USQOf6UlgO98AquBdWw33o4H54AB6E78Ma5vEQrDXuJcbdq68z3tAfBvai/ghz
fhQeg/WM53H62ECdJ9ATa1JnTeqsRTxFN56iW3+Ges/S7nnjHbzGB/aocci+EGJQC3XQBIwLj9Lt
YPwOxu7gmWMZrAB8iUOeKxinA3/hwF841vAMX+FYCy3Ew03G244fQyv3L8HL8Atog3+DzbT5d/gl
/Ara4Tc8Z6873qPfbqOReH2v48/G284pROILjA+crHkndndeCldxj52d2Nk5i+u3jG48XrfzWu6v
g2/z1lrO9Qaj0TnXeMM5j36wvxP7O7G/08NeP1ud5P4/ndq05UT1cfhl+ZvA5O8B0/HLrfjlcfjk
NnxyG744iC8O4ot1fHEQX6zji4PiB0YJ/ngN/jjIDIL44yD+OIg/DuKPPZwKgpwKxnEqCHIqCHIq
CHIqCHIqCHIqCHIqCHIqGMepYByngnH4b52TQZCTQRA/ruPHdfy4jh/XOSkE8eU6p4Ugp4Ugp4Ug
p4Ugp4Ug/l3Hv+viF8hsg3+jr83wKzEGH98mfs11C7wKHfAf8BrPX6ftVq7/yf1vyP8e3oS3YAfs
oq8/0O9urn+EPfA27IV3eL4P/gRd8C7199PXe1zfRy8fcIb6ELrJfwR/Rqcfwyfo6wB8Cj2c2A9S
v5frITgMn8Hn8Bfoo+wI9MNR+AL+CmYsCGbEAg/ntE3EAw/xIMhJaDbxoJV40Eo8aCUetBIPWokH
rcSDVuJBK/GglXjQSjxoJR60Eg9aeScv1fbTnjnwbl7Ku3mp+kliH9cj0E/+KDKOcf2b4cnKMkqz
ckA3SjlRjeNEFeREFeREFeREFeREFeREFeREFeREFeREFeREFeREFSS26Jyqgpyqgpyqgpyqgpyq
gpyqgpyqgjlf5ZQ2gXfqidQrMTzEHg+xx0Ps8RB7PMQeD7FHJ/boxB4PscdD7PEQe3RiT5DYkyD2
BIk9QWJPgtiTIPYkiD3BjNizhtjTRuxpJd7oxBsP8UYn1gSJM0HijE6MWUOMCRJjPMQYnfgS5LQW
1AvEGOKMhzgTJM4kiDMJ4kyCOJPgFBfkFBfkFBck5ozTz6TeaNp+Gc422og5uv4VnqEHTndBTndB
TndBTndB/Vz6LYbzKD8f0IM+ASbSbwl8jbbMnZPfOOKSTlzyEJc8xCUPccmj4hLzJiatISbpxCSd
mKTrlxklxCUPcUknLunEpSBxSf582cdpcRwnxCBxSScu6cQlnbikE5d0To1BTo1BTo1BTo1B4pRO
nGrVK+grwFyCPFvA+OJcE1ALdVAPDdAIi6h7ByyGO6GJZ0sgCUthGe2Xc13BGO+CZmOlfjesJH8P
81gF98JquI969wM+ibiUIC4liEtB4lKQuBQkLgWJS0HiUpC4FCQueYhLHuKSh5i0hpgUVDFpI3Nm
bxCXWjnBjiM2rSEmeYhJwf9i5t7j267ve4/LSmJJCZSUKqVcwi3hYsCBxKO0JWkbKMSAuTilKWDu
xBjExVxMwOQGuOpoqatNtPXq47PNm6dz5nhpdnGO5m5ja8TpvOEAo7OUtQLiEATEmHuAluZ3nlIE
TVlPdx7ncbadP179Sr/fT/JP38/7+/68v1KKnpTQj2r1o1r9qFY/qtWPavWjWv0ooRfV6kW1elGt
XlSrF9XqRbV6UUIvSuhFCb0ooRfV6kW1elGtXpSY2Rcs0I+u1o+u1o9q9aNa/ahWP6rVj2r1o1r9
KK0fpfWjtH6U1o826Ue1+lGtfpTQjxL6UUI/ulo/SuhFtbNODxboR2n9KK0X1epFm/SiWj0ooQcl
9KCEHpTQgxJ6UEIPuloin68P1epDtfpQ7awrQofrRYnQkZx8lJOPcvJnOfko9xnlPqPcZ5T7jHKf
Ue4zyn1Guc+oFTVqRY1aUaNWyigFjlLWqKqMqsqoqoyqyqiqPKsqz6rKqCqMqsKo2R71iUZ9olF3
N+rung19xF+esi/N8aMCHyrwoYKsOiWr7pZVp2TV3TypwJMK3nXKu0555VQoWnOA/V8T9v6K0lH9
NWfrtIuCzLTmIGOHm7B7DVd+Y7Mn9igRlFxVcuYKO4P3zxQqV/6tnfYVwbby3vj93bb99AGONOGK
ym9sy8vv8/7vfqEZzu6uWRi87ordNc0o/7rx0ZovO3IpLkMLLscVkOrKr5/u+XTPp1+Jq3A1roE9
2nR7tOnl30XK9/p8+Relyl0+43W5yv2Vd/e5979FqBz5yd7PXD1SvvrPyr8nhQ50H5vdx2b3sdl9
bHYfm53d7Gzm/U/oXja7l83uZbN72exeNruXze5ls3vZ7F42h6Z51Y7qL3cToYaa2uD7NUf4PEca
j8LRmIf5OAbH4jgcjzqcoFudiPVec58Zv9+43bs9h53YjbfNy1nB96efjWVoxDk4F+ehCefjAlyI
i4Lv1z5mHzpufBrP4NkgUztlfAV7nAuC70fca2R/HATzHjHvEfMeuc7zhHke9WmGaiLBZE0MMzEL
++MjmI2P4kB8DHNwEA4OxmoOUe9Dg0drDgt+VDM3+KOaw4MRszJhVobMypBZGTIrQ2ZlyKwMmZUh
szJkVobMypBZudus3F3zG97vMzgdS3EmzsV5OB8X4EJchOX4IlbgWqxEgiZucj8341b3dBdW4W73
dQ86cS9Wu26Ne1xrXAd7AtWYUI2JmvL3+l/BduvwOezEbrwd5FRlSFWGVGVIVYZUZUhVhlRlSFWG
VGVIVYZUZUhVhqY3B5PTL8MNwe7pCdyEdtym995uP3gHVgVj09e4Zi3W2Zd9D98PHq39G+Mjwe7a
HwZjtX+Pf/D4H/Wdx+xfnnDun/CjyverQ7XbnPsX/Bg/QRFPO/4Mng3uri257iW8XPnedYgqhmpf
8/gd172L9zze432DYCgSCiYjM4IRahmKxIIxihmKqH/kQMcO8vgTHttPRg7BYZiLw2FPGTkS8zAf
x+J41OFEnIR6nIKFWIQGqHnkVHwSp+FT+DToIEIHkcWghcgZoIfIF3AWzkaT+zsfF+BCXBTsjvCe
yHJ8ERfjS8GjkRX4cvCjyCW4NPijyGVo8XkuDyasggmrYCJylfe72ntc45prnbvOZ21z7AbcCGs+
ckvZg8IPh24I/2HweKgmfEGoriYTmh48Efo4TzpI2j2Y1x4SPBY6NEiFDguaQnPtcg53/ggciaNw
NOZhPo7BsTgOx0vRdbjOe61EK65HG27w3jcigbu8/yrcjXvQ6e/ci9VYA6oOUXVoPXoptxYH41C9
4TAKnys5H+65ilmhOSs0Z4XmrNCcFZqzQnNWaM4KzVmhOSs0Z4WOWKEjlX8tcRNuxt3e6x504l6s
dmwN1mId1lf/hcb9wWT4sODJ8BE4Kng8fKxxQVAfXhikzODy8PJQQ3hl8Gi4DWY6fKtxFTqDvvAa
Y8r1/a4fcP2fe/7XHheM7wSPTpuJ/YO+accaXwyemPYSdmESL2MKr+BVvIbX8QbeDJ6YHg+aps/B
x3GW1X02lqER5+BcnIcmnI8LcCEuwm24HXdUfsNeYBXnZjQGmRkXBwtmfAmXBE0zLg22zrgueGLG
TbgZtwQjM1Yb1+Ah575hTLvuYeN3vKbX+Hue/77xCe/3JP4JT+FH+GfXjCOPAp72957Bs8FjM7Zj
IkjN2IHnvMdO768XzihhKtgqLeSkhRxnKXCUHEfJcZMcNyk7SI5b5LhFjluMcIgch8hxhEmOkOMG
OW6Q4wY5bpDjBDlOkLP6clZfzurLWX05K61gpRWstAkrbcJK67PS+qy0nJU2aaVNWmnlVZazyias
spxVlrOyJiOloBR5IdgUeTHIRF6y+nYFo5HJoDXyctAcmTK+4vyrwXDkteDJyOt4A2869pbrd/sb
b3vNO8FTkXdd+9NgWeRnxvdc83PX7PG+QZCJhoKRaE0wGg0HrdFpQXN0unFG0BOtdS6CaNARjQUt
0ZnBsugsx/cLro7ub/yIcwfAjidqxxM90DUfc008OCQ6x/mPu+4TQXf04KAveggOdf4w180NmqKH
B0uiR7juKNcd7T3mwa4neozzx7ruOO9zvPN1zssGUdkgepLzdj3RBc6f7Pwpzi903u4veqrP8EnX
nIZPBf3RT7vmM6453fHF7mGJ133W8885/nnj0j07omd47ZlBQ/Rs1yzzOjqNnuPacx0/z3VNrjvf
+QucvzDoijYbl/scX8TFrvuS61a47ss+yyWuu8z5Fu9xOa5w/krnr3L+au9zjfM/Dh6N/gRFPI1n
8Cy2YwI78Bx24nmU8AJexEvYhUm8jCm8glfxGl7HG3gTb2E33gYviL4bPBq7Lngy1hpkYtejLSjE
uHfsxqA9lgiaYzcF6djNzt8SlGK3Bpti7a65Ldgauz2YiN3hmjuDq2MdwYOxVUFP7O6gL3YP7OJi
94K3xtYES2Jrg1mx9UF/7D6vvR8POGcHF/tK0BJLBstiX3X+wWAk9jWv/Toe8l7fCDbEup3/pten
8NvOp732YXzL+W97v+843+P12aA+9jf4uyAVe8K9PonnPS7hlaB+5ozg0Zkn4EScjXOCvpmXGC/F
rR634+7gUbuCXM1+OtOgrpSp/iumCV0poSuldaUJXWlQVxrUlQZ1pUFdaVBXGtSVBnWlQV1pUFca
1JU6dKWOyr/5uMF73YgE7vIeq6AL6EITulBaF0rrQmldKK0LTehCE7rQRPnfS+gAgzrAoA6wXQcY
1AEyOkCCuw9y9wx3T3D2DBcf5OKDXHyQiw9y8UEuPsjFB7n4IBcf5OKDXHyQiw9y8TQXT3PxNCfO
VP/dQYETZzhxhhOnOfEEJx7kxIOceJATd3DiQU48yIknOPEgJ05z4kFOnOHEg5w4zYkHuW6G62a4
bobrZvb5Fz0TXHeC6ya4boLrprnuBNed4LoTXHei6mpFrlasutoIV0tztS6u1lJ1tX6uNsjVBrna
YNXVClytwNU2cLURrtbF1Tq4WgtXG6y6WpGrFauuNsLV0lyti6u1cLUcVytytSJX6+Zqaa7WxdW2
crUOrpbjakWuVuRqPVytm6uluVoXV6vjalu5WgdXG+FqBa5W4GrdXK2Lq3VxtQ6uVsfVclytyNWK
XK2Hq3VztTRX6+JqdVwtx9WKXK3I1Xq4WjdXS3O1Lq5Wx9W2crUOrlbgakWuVuRqG7hamqt1cbUC
V+vhat1crYurpblaV3QpRzzDa8/kiLo2VytytSJX66m6WpqrdVVdbStX6+BqOa5W4GoFrtbD1bq5
WhdX6+BqdVwtx9WKXK3I1Xqqrpbmal1lV+Msg7GVQZG7FLhLgbvkuMtT3KWLu3Rwl07uMshdityl
yF2K3CXHXZ7iLmnu0sVd2rnLCHcpcJcCd+nmLl3cpYu7dHCXQ7hLjrsUuUuRu/Rwly7ukuYuXdyl
jrvkuEuBuxSq7tLDXbq4Swd3aeAuW7lLkbsU93GXNHfp4i4Z7pLhLgnuMshdBrlLgrskuEtGtl0R
qgtPhk6Vbcv/++3wAvns4eDUcD7YFC7hveDKafsFm2rPC30nUgqdFnkhtDTyInaFFkcmjS87NkWd
r3j8auj4yJuev+Xxbrzj8bvGnxp/Rr0/N+7xPAgtjdaEFkfDxmmh0yi4FJ0Rqo/Weh5B1LGYcaZx
FvYLHR/d3/mPOHYAPurYgcaPGeNeO8f4cdd8wjUHO34IDnNsrvFw4xEqfJRzR3s+D8c4dqzxOOPx
Xl/n3Amen4h6xxYYTzae4txC4yLvfaprPun4afiUY582fsZ4OhY7v8T4WXzO8c8bl3rtGcYznTvb
a5c53ohzHTvP2GQ83zUXGC90TbNrljv+RXzJsRXGLxsvce+XOdfi+eW40rGrjFcbr9HXVoaOj7WG
lsauxw2h+tiNxkToNOosxm5x7lbP23G7Y3cY7zR2eN0q197t+T2417HVxjXGtV633rn7PL8fXY59
xZg0ftXrHnTua55/Hd9wrNv4TWPK637bubTnD+Pbjn3H2BM6LfStiqK2SPf5YC1VraWqU3+Fok7b
R1EFilpMUfN+haIWU1Q9RRU+pKjT9lFU4d9Q1Lxfo6hCVVHzPqSoeopaTFH1FFX4NYoq/BpFFaqK
mvdvKGrer1BUoaqoeb9GUYWqouZ9SFH1FLWYouopqvBrFFWgqHn7KOp4ilpMUfUUVaCoefsoqn4f
RRU+pKh6ilpMUfUUVfg1iip8SFH1FLWYouopqvC/VdRd4aNCSySKTfvsHTK6bLrSZV/VRd+2z3g3
6NFFH6SUzn32AhldM13tmuVumdYtM7plWrcs6ZadumW5S27SJdO6ZEaXTFNFgy5Z0iU7dcmndMeM
7vig7tijOz5Y7Y7lrrhJV0zrihldMU0NDbpiuRtu0g3TumFGN0xTQoNuWNINO3XDchdM64IZXTCt
C5Z0wU5dMK0LpnXBjC6YpoAGXbCkC3bqguXut0n3S+t+Gd0vXe1+Jd2vU/d7StfLVLtej673YLXr
lbvdJt0urdtldLt0pdu1Wds36h4JefgmOfYWOfoXWTmjm6VVuUs3e0oXy+hiD+piPbrYgypcp4uV
u9cm3Sute2V0r7TqNuheT+lamWrX6tG1Hqx2rXK32qRb9ehWGd0qHfqDSlZcEDTJiSPhVcF2eWpU
nuqSpzpVukelMyrdpNILVHqJPPWUanfLUE/JUF0yVLvK98hQGdVvUv0Fqr9EfhqVn7rkp7ISeigh
QwlNlLCAEpZQQkJ+apWfWimimSJmUcQsikhQxBKKSMhPrfJTK2U0UEYzZcyijFnR+J6XKSNBGUso
o0V+WiE/raCQBgpZRiGzoofveS96hOuOct3R3mMe5jt/jPc51vnjcLzzdc6f4NyJOMn5eucXOHcy
TnFefqaYJRTTJT+1yk+tlNNCOYdEP+NvnK7ai/3NJV73Wc8/53WfNy7d8zDlNEfP9B5n+/zLgnb5
qZWCWikoQUENFDSHgmZRUD8FNVNQj/zULj+1UlIrJSUoqY6S5lDSLErqkZ/a5adWimqlqARFNVDU
HIqaJTs9JTulZadO6togO41QWAuFLaGwVgoblZvSclMXpW2gtBFKa6G0JZS2gtISctMKuWkFxZ1B
ccsoblZszZ73Ymv3PE1xHXJTq9zUSnlnUN4yyjuE8mbFvur8g5T1Nfnr684/5NpvoJtSvxnMocA5
FNgvN7XLTa2U2EGJHZTYQIlzQiso8HGKK1DcJLWVqK2r8n3E23LMO5L+u47/1OO93lKgqElqKlFT
FwWVqKfsJcPUUqCWEqWUeEgXlQxTRpEyipQxyTuKvKOTGgrUUKKEEs/oUv2C6pdUvsQrulR9WKVL
/KHsDcMqXOINJb5Q4gtdPGFYNQuqWVLJkkp2qeKwyhVVrqhykypXVLlO1SqoVkmlSirVpTpF1Smo
zqTqFCvJdu/6L6hKUUVKlbXf6fG9WO3cGuNa1z3gmi7nk/iqax5y/Bvods03jSnXfMs133a+JyiF
+qtr/HEzvN76Lljfj1jfw2Y7Y7Y3WN8dZrzVjJ9hfRer67tgfQ9b32Vnz6jABhXoUIEWFTjD+i5Y
349Y38OqkVGNDdZ3h4q0qsgZ1nfG+h62vodVp9P6TqhQi/WdUaVW6ztjfQ9b3+WKtatYp/WdULUW
VZttfWdUrtX67rG+N1jfG1SxXRXbVbFFFZtUcbb1nbG+h63vYRVtV9FO6zuhqi2qOtv6zljfw9b3
sAq3q3Cn9Z1Q5RZVnm19Z1S6tfqtz7D1Xa56t/WdUPmW6rc+7arfqfot1neCAlqs79et78w+3/oM
W99lRaQpotv67qCKFqqos74foYz26rc+G6zvDVSSppIuKklQSUu1U5S/9Rm2vocpJk0x3dZ3B9W0
UE2d9b3V+h62vocpaJiChqt7o1YKaqGgrdb3I9b3MCUNU9Kw9d1FTe3U1GJ9Z6zvDdb3Bspqp6x2
ymqhrCbKmm19Z6zvYet7mMo6qazd+k5QWgulza5+67LB+t5AdWmq66a6BNW1UF1d9VuXYet7mALT
FNhtfXdQYWvodyu/HN0XTFLjjup303u/i15FmZ1yxQtyxYt4SY7YpbtM6iwvU9uUsewDb7lmN8o5
Y+/3kO3U2EyN7ZQ4QokjlJijxKcosZ0SWyixnRL7KXGEEkcocR0ltlJiMyX2U2KCEvspcYQSRyix
gxLXUWIrJTZT4nxK7KfERFWJmyhxEyW2UuI6SlxBicsocQ4l9lPiCCWOUGIHJa6jxFZKbKbE+ZTY
T4kjlDhCiR2UuI4SWymxmRLnU2I/JSYoMUeJI5Q4Ut2pt1JiMyXmqjv1dZTYTImtlNhMiS9TYj8l
Lqnu1EcocaS6U++nxFZKbKbEJZSYo8RuSnyEEjdR4qbqTr2fElspcRklLqnu1EcocaS6U++nxFZK
bKbEJVS4iQo3Vb7/u5FSEhRQ/u7vVgpoR9nH7nD8TurocHwV57/b9fegkyLuxWpdZo0OslZnWE9R
93nd/XggWEd5HZTXSnnNlDenuiPfRHmb9vm+r5XymimvifJylDdCeSPVHfkGymulvObQVylukuJG
Kv73EiXtoqDJoI+6uqlrRSW9vqm7vKXL7MbbrnmnkmbTFLaOwlZQ1jBl5Sirj7K6KWsFZRUoqoei
+iiqm6IKFLWOogqU1E9JPZTUR0nd1TRboKR1lJSjpAlKmqCkHkrqpqQ0Ja2jpAZKKlBQPwX1UFAf
BXVXU22Bcvopp4dy+iinu5pqC5Szrppqhymmj2K6KaZIMf0U00Mx3RTTRzHdutd8iilQTAfFFCil
v6qUPkrpriqlQCnrKGUrpUxQygSl9Fe/qU5TyrrqN9UFCumvKqSPQrorClmpG7VKstejjS/doDPd
SAkJ1f1Ft9ta/e6mj1K6KaWTUnKUMkEpE5TSQyndlJKmlHWUMp9SChTSTyE9FNJHId3V1LuVQiYo
ZIJC+imkn0LSFLKu+o1wgTI2VL+r6aOM7vK/6QgtqmkKLQpnQ6eHd4UWhidDp087KrQwcn9ocObv
hx4Ixfe5YmHlzEuhRZG3Q4uiIczGoZiPk3AOLsYVoUWxNtyGTjyAh/Ct0KLQ3PBhQV3Y3iV8LFJ2
6X8fbAs/iR8hj+eDbZHXgrrI63gD73HW63AznghOjT0ZnDozFGybWYMjcRROQj0WBdv2ew2v4w28
id3BttABNc8H+fL/i9w6uCx8SvCX4UXB6vDng97wWdbGecFAeLnHK4J8+MvQJ8L3BNnwvcHq8r8+
CZ3rnne6551W0uvue6d3eT18slSxMHgmfLpR1gmvDF4Mt+FWrPIud+NerPH8AWNXkI+M2GEUjU/j
GbwW7PQ5d/qcO33OndEvBNujZ+HHwYvRn6CIp/EMnsV2TGAHnsNOPI8SXsCLeAm7MImXMYVX8Cpe
w+t4A2/iLezG23gH7wYvxj4d5GOfwelYjCX4LD6Hz2MpzsCZ+ALOwnXBTvXZWXNgzfZgZs1z2Ild
obqaV0LLa97Abs/fxjvBxpp3HX/P+PNQXfig0HKzGze7cbM7Fp4XbDTD8fAJxgVm7RR1afB4CbX4
6+GlQTJ8Bvzl8DLHG73mXOP5weXhC4wXBg3hizxuVt/lrvuiYxcHjZXaXmK81Ptc5niL55c7d4Vd
/ZW4ymuu9vwaXIvrXLtyz+5wG2507U1ec6vHdxjL1b0naA+v9po1jt3v2FeCy6edHloe+YtgY2Qz
/iG4PPIYCkEysg0/xmtBXLXjqh1X7Xj0omBj9FJcK/tQeHQlWnE92nADbkQCN8EKiN6CW9GO23A7
7sCd6MBdWIW7cQ86cS9WB8noGqzFOqzHfbqfe48+AOqMfgVJfBW/iQfxNXwdD+Eb6MY3kcJv4beR
xsP4Fr6N76AHv4Pvotdn/C+hJdG+0NnR/2r8Xfwen/j90Mpov8d/YPxDDHj8R67NGP+b5//d+Meu
Gwwuj27AEP4EG/E9bMKf4s/48J/D3EeHYf6j/wNZ/CVG8H38Ff4af4NH8Lf4O/wAW5ALGqOP4n/i
h/h7jOIf8I94DGPYisfxBJ7EP+Ep/Aj/jHHkUcA2/At+vGd39Cco4mk8g2exHRPYgeewE8+jhBfw
Il7CLkziZUzhFbyK1/A63sCbeAu78Tbewbt7dseO4b3H4Xjw6djJQTJ2ChZiERrwGzgVn8TZweWx
ZWjEOTgX56EJ1lnsAlwI6yzWjOX4Ii7Gl7ACX8YluBSXoQWX4wpcCestdjWuwbW4LohzkHjsN4ON
sd8KNobCldW/yv7tsPJ/Q4FnLOcXy8PTOO0MRDCP855Q2duNWcd11nGdV4xYg9utwe00V0dzdTRX
R3N1NFdHc3U0V0dzdTRXR3N19FZHb3X0VkdvdaEIJyqG6/39BcGTPP6vwudwhLILdAb50Es1293L
BA/bgec83hla/v5/36Nmt8dv453g8ZqfBr9Z8zPje9jjcSDph6X+acFd4enGGcZaY8Q4z3gC6n2G
BcFuvrcxvNDjRf4qB670qqU+51lY5nkjznH+XPNwvru9yPNm55bzvb2et7eXXYJLK16XN0cN5qiB
1xU/5HX5cKvufwMSuMn5m423oB234Q7H7jR24K5QvNojN+pwt4fXOrYe9+F+++cFcsJfBI+qwaN8
sMgHi3ywyAeLfLAYedb5HXg+tJD35XlfnvfleV+e9+V5X5735XlfnvfleV+e9+V5X5735Xlfnvfl
eV+e9+V5X5735XlfnvfleV+e9+V5X573lf0nTwsNtNBACw200EALDbTQQAsNtNBACw200MB/8vTQ
QA8N9NBADw38p8h/ivynyH+K/KfIf4r8p8h/iv8PfCfPd/J8J8938nwnz3fyfCfPd/J8J8938nwn
z3fyfCfPd/J8J8938nwnz3fyfCfPd/J8J8938nwnH/2pOf4Z3sPPsQdBaGEshBqEMQ3TMQO1iCCK
GGZiFvbD/vgIDsBsfBQH4mOIYw4+joPwCRyMQ3AoDsNcHI4jcCTkydjRmIf5OAbH4jgcjzqcgBNx
EupBW/yryL+K/KvIv4r8q8i/ivyryL+KsdNc86nQQsl1e7BdGtkujWyXQLZLINuljW3SxjYpY5u1
/abcVpLbSnJbSVYr6dLbdOltuvQ2XXqbLFaSxUqyWEkWK8liJVmsJIuVZLGSLFaSxUqyWEkWK8li
JVmsJIuVZLGSLFaSxUqyWEkWK8liJVmsJIuVZLGSLFaSxUqyWEkWK8liJVmsJIuVuOI2rrhNUn9e
dl0YvMoDBrhR0nrfaL1nrfPeiitN4xg5q39jOenULPfJZ9dM8J0deM7jnXg+qC//V3v2yWSzzchs
XtVU865X/bTiVU01P/d4T8Wr6nnVCK+q51UjvKqeV41UM9tcsziXU07xrh+azbn864fuIuU+y57V
yLOS7jclr60On+lev+DelznW6PG5xibXnR80yW29++S2y6selqzmthQf21jNbo2y22rZbYCfJffJ
bk38LMnPkvwsuTe7yXmtPoMcFb7BmMBNQV/4ZuMtkKHC7cbbYP8VvtPYgVXBeCW53+N+OivpvS68
1vH1uI/f3u/aapqv5L0FweO87oe87oe8ronXNfG6Pl7Xx+v6fintP+ta9Yg8j9eCuVQ2l8rmUtlc
PtjIBxv5YCMfbOSDjXywkQ828sFGPtjIBxv5YCMfbOSDjXywkQ828sFGPtjIBxv5YCMfbOSDjXyw
kQ828sFGPtgoA66WAVfLgKtlwNUy4GoZMCcDrpYBV8uAAzLggAw4IAMOyIADMuCADDggAw7IgAMy
4IAMOCADDsiAAzLggAw4IAMOyIADMuCADDggAw7IgAMy4IAMOMCDk9UMuGhvBrSv/uUMeBkPvqya
AZO/IgM28eAmHtzEg5t4cBMP7uPBTTy4aZ8MmOTFSV6c5MVJXpzkxUlenOTFSV6c5MVJXpzkxUle
nOTFSV6c5MXJf98MKIf/BEU8jWfwLLZjAjvwHHbieZTwAl7ES9iFSbyMKbyCV2G3zEnqOEkdJ6nj
JHWcpI6T1HGSOk5SF7W2o7JIVBaJ/hzWd1QeiYVQgzCmYTpmoBYRRBHDTMzCftgfH8EBmI2P4kB8
DHHMwcdxED6Bg3EIDsVhmIvDcQSOxFE4GvMwH+W8eqzx/cxa5/EJOBHl/FpvtO70gT59oE8f6NMH
+vSBPn2gTx/o0wf6Yqe55lP4v9vRzuW8c0Mn1ExypPd3oksrTlbeda7mYI0VB7vAeBGXaOYYyz2+
2O5VAuZa13OTIU4y0ypOW7kJKzdh5SaszrQVmbASN1mFm6zCrVbGSitipRXxnWh/MGFF3GNF3BPN
eLx3JSyqrITvBZt0zkXVVL/YDC02KxeFlvD8Xl7fy+t7eXsvb+/l0wN8eoBP53n0QDXVbgyf7NxC
nI5z+PFKvtlW3uNW97d7vS8ZGQl6edUArxrgVQO8aiD6haA3ehbsaek5Sc9Jek7Sc5Kek/ScpOck
PSfpOUnPSXpO0nOSnpP0nKTnJD0n6TlJz0l6TtJzkp6T9Jyk5yQ9J+k5Sc9Jek7Sc5Kek/ScVJ8B
9RkI/bE03rBPGm+Qxhve/y+8SeMN0nhDNY2v3yeNr6+m8REdbr0ON6LDrdfhRnS49TpaVjfLSuPx
yu7ilOC3dK5y0s6r8fW605ZKur7csStccyWu8vxqx6/BtWh17AYkIMFK1HGJOi5RxyXquK6Tl6jj
EvUv0vRaj9fjPtyvYywIxXWXrO6S1V3yukted8nrLnndRUdxfgeeD8U57CSHjdNRnMPGpdw4PcXp
Kc5h4/QUp6c4h41z2EkOG6erOF3F6SrOYfMcNs9h8xw2z2HztJbnsHkOm+esWzjrFs66hbNu4axb
OOsWzrqFs27hrFs46xbOuoWzbuGsWzjrFs66hbNukUTjkmhcEo1LonFJNC6JxiXRuCQal0Tjkmhc
Eo1LonFJNC6JxiXRuCQal0TjkmhcEo1LonFJNC6JxiXRuCQal0TjkmhcEo1LonFJNC6JxiXRuCQa
l0TjkmhcEo1LonFJNC6JxiXRuPUUl0TjkmhcEo1bW3FJNG59xa2vuCQal0TjkmjcWotLonFJNM6B
8hwoz4HyHCjPgfIcKM+B8hwoL4nGJdF46N5f+tZziUyztPKdVS/n6OUcA1wjKeOkZJwUJfXKMKlK
hinnl3JWkUMooJcCej/87ajskJIdUrJDSnZIyQ4p2SHFdVKyQ0p2SMkOKQ6U4kApDpSSHVKyQ0p2
SMkOKdkhJTukZIcUd0rJDinZISU7pDhV6oNe/Qehs6nobMo5nmoOp5pequmlml6q6aWaXqrppZpe
qunVT1P6aUo/TemnKf00pZ+m9NOUfprST1P6aUo/TemnKf00pZ+m9NOUfprST1P6aUo/TemnKf00
pZ+m9NPUf2Y/pZDF+7jvove/oQ59NPK2WQphNg7FfJyEc3AxrgitjLXhNnTiATyEVOUb8pWx3wkt
kuaXBrvpYjJ8ceX/D7Scn8j1oemO52XlH8g7P5B3fmBnMCWtv175hmBML8pXrx2bRoPTaDB0M71t
rGbxgfB59uvn09be/UPK1Uu4WZu/s5GjPUiDvTS4cR9XS3G1Nq7WxtXa6LKXDlORct2utXe9DivR
iuvRhhtwIxK4CTfjFtyKdtyG23EH7kQH7sIq3A1OSHcb6W7j/7Gj/Ws3S9Flii5TdJmiyxRdpugy
RZcpbtbGzdq4WRs3a+NmbdysjZu1cbM2btbGzdq4WRs3a+NmbdysjZu1cbM2uu6l61667qXrXrru
peteuu6l61667qXrXrrupeteuu6l61667qXrXrrupeteuu6l61667qXrXrruDdWEz+EZZ7/f1Srf
/yyt7JXyH3zPc/E+3+2UO891ukG1Q/yHfKfyb3WLf8fvNEKfoOKN1V1i/oNfba7GNbi20qvyqptX
3bzq5lU3r7p51c2rbl5186qbV9286uZVN6+6edXNq24+FJGJtpTXWXW+y+sw/8GaO1NFxlQkW61I
eRc+Vq3G2K+oxphqjKnGmGqMqcaYaoypxphqjKnGmGqMqcaYaoypxphqjKnGmGqMqcaYaoypxphq
jKnGmGqMqcaYaoypxth/ajWm8ZZJ1ahUgnY/H6qrHBurHhv7YL62VOdrrDpf2X3mK/v/2XxlzVfW
fGXNV9Z8Zc1X1nxlzVfWfGXNV9Z8Zc1X1nxlzVfWfGXNV9Z8Zc1X1nxlzVfWfGXNV9Z8ZUONFT9e
ymfPq6zp8m9W363kgPJ8lb/P2TszG83MxurMbDQzG/9D/HYQGzCEP8FGfA+b8Kf4s+C71sB3/11n
aEZFUed80M/Gqr1vr54mdbaszpYNXWQms2byB+Ezgl2u7zWb283kLit2l5l8LLwi1GA2x81mNnyZ
Y1c5f10wbka3m9HtZjRrRrNmNGtGs2Y0a0azZjRrRrNmNGtGs2Y0a0azZjRrRrNmNGtGs2Y0a0az
ZjRrRrNmNGtGs2Y0a0azZjQbXR3siq7BWqzDetyH+/EABt3HBgzhT7AR38Mm/ClywbiZHjfT42Z6
3EyPm+lxMz1upsfN9LiZHjfT42Z63EyPm+lxMz1upsfN9LiZHjfT42Z63EyPm+lxMz1e7jTBRjP7
i+yQra7ic0LLQxH7qMdrdlV++9htj3KXPUq++qt4JvRp+XRKPp2ST6ecfTNsldk37qj+6j0VfsDz
rmAsUsTTeMbK+3EwJbNNyWxTMtuUzDYls03JbFMy25TMNiWzTclsUzLblMw2JbNNyWxTMtuUzDYl
s03JbFMy25TMNiWzTclsUzLblMw2JbNNyWxTMtuUzDYls03JbFOxTwdjsc/gdCwGV4p9Fp+DGYgt
xRk4E1/AWbzr2sov2uX/DsMOvP/L9r/+VTtf/VU7/8Gv2u+n972/Hm+ppPg7jHt/Pc6GV0tj5W8X
73fsK8FA5dvEQrDF3m6Lvd2W/9R0e3Kwxb5mi33NFvua/0Xe2cBHUd39/syZnVl2sgRULGotiqJG
0aqhcGndWutLrIK6YnxbNdK6KqKi9a2xFnxMvY0+pS/gba610cZqqWLrgxhbRaUqQWOVREWBVRA2
kQRkDWHhiRhpzv2es5Nks1neBGrvvbOf386ZtzP/83/5nf85s8ksYFyzgHHNAsY1CxjXLAiVMPo+
HXwPnAHOBOPAeHAWOBucA6KA0U1oAjgPlILzwQXgQnARuBjEwCXgUnAZKAOXg4ng++AHjPQtrTmx
Lz6Z7HkaKInnAHDBtXjeTeA2ynepZnTZjC6b0WUz7WmmPc20p5n2NNOeZtrTTHuaaU8zEXCNapX0
FvqJIz78gjisZ05B///8NvNLhuOtdvP/Lo/E9sdbmyhvVvOw+TzkqEaOauSoxvZ6vJ9AloS8VQzD
1kQFPvFjI1fCHi2Ot8eAE8QQOyqORM4EciaQM4GcCeRMIGcCORPImUDOBHImkDMhivDGFF6YwgtT
eF8K79O/PEniaUk8LIlH6V+PJPGcJJ6TxHOSeE4Sz0niOUk8J4nnJPGcJJ6TxHOSeE4Sz0niOUk8
J4nnJPGcJJ6TxHOSeE4Sz0niOUk8J4nnJPGcJJ6TxHOSeE4Sz0niOUmsdLv+jy+aKcRpSHtM79wM
5dWgRS1El1ehw6towTG04Bj0mPTjJ2niR6pG9NmIPhv9WIrRwhh6XUkrY+h2pYmhn1C+S630Y2cl
elyJHleigRgaiKGBGBqIoYEYGoihgRgaiKGBGBqIoYEYGoihgRgaiKGBGBqIoYEYGoihgRgaiKGB
GBqIoYEYGoihgRgaiKGBGBqIoYEYGoihgRg2XIkNV2LDldhwJTZciQ1XYsOV2HCl0c0D4kR0sxSd
LEUnS9HDUvSwlHYuop2LaOMivLHB/x2RZtUFtHXRVhh1EW1dRFsX0dZFA/S+VSAJmkAz+AisBi2g
FawBa8HHYB1IgU9AG1gP2sEGkAYbwSbw36ADfAo2g89gyC/CqF/JiqxqLD0HS8/B0nOw7lwsO9dn
yCex7FysOherzsWqc9HsXDQ7F83ORbNz0excNDsXzc5Fs3NNf5X5ldcj6nn5tForn1XtcrHqML/i
GiYfhB1qwCzuO5f1e0ToCiIyLEbag4iwF2CDBao6VAcagGaO5WAFaGK7jfUWlfAkcAHR6Y0D48EF
YLJKhJtUc7gZfARWg1bY5UD5K7VaPqzS8lH8dhY+/Tjlp8CLYAkRnAab1drQsyodmg9exldeYb1A
NSJNI9I0ht5Sq0NvgybKLRxvBetV2jtUpbwR4DBwkVrrXazWisHyPhVGC9XySVUnF6iJ8rWuZjRR
J5eqM+UqNNSkbpSt6ia5ToyW67vaZDsstkUNtcMqbA9Vk4SUz4rhMiWGk8vfh57WoaOD9f/kR4uN
aLHR6Fi3ZS5YAt5XZZw1ibY02mjHDmnNUh6kmuyvGu029mnPB2A5WAF0m9pUoxdUZd4AsBc4lO0R
4DBwONunGm03oe0mtN3kXcF2HFxpNN/k3Wa034j2G9F+I9pvRPuNA4VKDLQAVhtoAwcePYJWtNGK
Nqyi/aEOiySwSILWtGGVZtszkifsvcEBQD+PeBb7v0AeMZ/1K7RogaqjNXW0po7WtNGaNlrTRmvq
aE0b1mn2TkK6ElpwZn9f8X6EhOQ8SNyGxG1I3IbEbYw+H1FPof+hsg6JXkOipUi5Tpyp/y7W2GMG
nt2GvRrERCvZ1Wp9BFYD3Vd1sP4U9PZNC82vTVzzf05O5eqR8jfUVwUewPIP4oM14A/c61HiZS7l
59k/n23sxf1Hynp4p4H126zfBUupCy7Bg9ZKuETCJXK9GooPT8L2KWyfwuap0NNoqtZoTft0e+h1
ym90teHLp+LLp4aWsE3bQvTVaDCNBtNoMB36kO2VaHgVSIIWrm0FKa5t4/iGrjZPqEWeBQrVSG8o
64PAwWA4OBocA47jWDHr0axPNfExifiYhO+k8J0UvpPCb1JYIY0V0lghjRXSWCEdhv/C8F8Y/gvD
f2G4D19K4UspfCmFL6UG6jdl2FhrIWyzycTHkO6n7Oi5jCOziMBZHF2diUJ0uFjN96Owkigcjg5v
xbZHor/hROEM+0A1z/4a3newONIert7Tsdy1GXsvpIahxPEMaiilhuGyCSu1sl6Hp6xnfzv7t3TN
C3+gJoc/VmPDKVUd/kyNNb+DmEpfM5W+Zip9zVT6mqn4gpbxZnyhEV9olA9QfhjG+IP5TwkziIhq
IqIa2RPG257n+Itsz+f4a5TXI/8WNce2kXmEmoGtG7G1jpJqIqQae88gSqqxeWPoDXUzNp+FzWdh
80Zs3ojNG7FzI3aehZ1nYedZ2HkGdp4RSnH+eq7doG72zlMzvFvA7WqGYXjzZAfNzkCyJLpIoYOU
0X1Q3ocmnoXRUuI7cosYGVotZntHiirvelElHpS/6koYXWa8vhSvL6XFCVqs2Wyo4YAnsUyGB0pp
dcJEwous53POAsoL1Sj5Knita46sR+dvUH4TLAINXfNkI+u3wNsce4f1Yu73LuX3uPdSrl8GEux/
v2uq/ID1crCCYx+yXglWKSmTrJuov5n1R6CF61s5Zw0yrQVwsfyE/W1gPfds70rKjZS3dDXbdleC
CBxFBI6CwyrsAkZrYeXBYxX2UI4fwPqrHBvRpTmtwj5C3YHFNDuXYrWE4TUToV2J0NvgA/YvByvA
Sqy1CiRBJhJLsVJCR2MorUaFOsBnoBNs4dp/su4CSo3yRNcMzwKyK+E5RK/LOtg11RsABnK8sGue
N4j1YLAX+4aqUu9rlIeBgygfzLXDweEcO4J9ReBIVe0dRV0jwdEcOwYcRz3Hc6yY8ijuMZrtk1QF
0T8KHq6Ahyu889h/BdtxcCW4Wt3hTQLXgFs4dhv7fsR5t3fpHqUUZiiFGUphhlKYoTS8oWtGOA02
gk2go2sGzDAKZhgFM4yCGUbBDKMGRtQo8Q1iTMdWCk8bjac10NuU4mkj8bKRflyl8LDReFgDGUmm
L9V9qKeqsV6KXqga683BcnOwWDUWS2Gx0VhrNNYaSS9USi9USoyl6Im0lRqwUgNWaqAnKiWWUlhp
NLGUInNpJHNp7NO3jgInqTlopxrtzKGXqqaXqqaXqkYzKTSTQjMpeiz9f1+qGd08SDzUmBhJdOdQ
moPwIe0vCfwlgb8k8I9Ebr6EPhPoM4E+E+gzgT4T4hIiOmltFp61RXjwUhJdtcJBregqgW5a5QJR
KOvB2+BdsIQMsYX1GrAWrEMq/QzkM9ad4HPwT8ZXAlhAggBwQBAMAIVgMNgL7APgbvsrYD+wPxgG
DgIwi30o0M8En1Wt6L0VbmtF7wn0nkDnCbgtCbcl0bfuq1rhsFZ03uoJUehZYCg4CBwMhoND1VL0
vxT9L/WOZvsYUAzGiCHeWPAt8G1wIvguOBmcAs4CUTABlILzwSXg++AH4FpwHbhVDAlvEIXhNNgI
NoEOUTiQOsVVaDiNDVPYMIUNU/TuHfTsHfTsHRnNsl4D1oId1aqr0j2aDVH2VOt2NfxVzsujZby8
FV9KodU0Wk3jUyl8KoVPpfCpFD1/Bz1/BxzRATd00Ot30Ot39NUq28eAYrA9rZ5KFl2Ctban3Ss4
Lw6uBFmahi/SREYrvp3Ct1P4dgrfTuHbKbKIDrKIDrKIDrKIDrKIDrgiDVek4Yo0XJGGK9LGMntj
mZdNtv2A7nlM7pcg72qkr20kt2onxrWvvYxWXiauYV6iqpD4PQ6MBhepdvKbdrKJ++ilH+Cqh2GZ
R1jPoh96nFzhKZBhnUYiayQ9eCM9eAJ7VersEraZAdtUwjaV9Oq6j6jE60fi9SNhm+GhBV2bQ3Xg
DZ3Fs24CKcrrOb7BMEkluqyESSphkhkwyQx6cJ3zzoBBdE+u895KevOEkJrBdZYiCmjpHPl6L5+E
Ps3hjjA4IMMhwmGsQe8BBoC9wOFm7wKjsUkmW25STWhtNDnB++TAKTGa8+dx/jzOn8f583RewFh8
KVdaXFUtAiaryVyb0tmNcPVcE7W+69eaINNYyZFJYl+rjUwbq1hp1htNltzYI/8y9KvHlaPR5xg1
p09bHNXWpz1HsT0S6HYFzK88FyBB5l76ya+W/EgxWxxKDhcmhwuTw4XJ4cLkcGHObeLOpUTwDPxk
NFE8gyieYf6XThP9CfkUkVxNJFdnRnrmb6foiUEh5aFw+kHgYLaHg6PBMeA4jhWzHq1G48H0dmAj
2AQ6yMN0+xO0P0H7E7S/u90ptL2Qtn/S0/Yt6hO/3SnT7qBaiBUWYoWFWEH/p7EU7U+Z9odgnzS1
tMM6aa5oJ6LTRHSaiE5zZjtntmPnJWoFZ6zg6AqOruDoCqO7RnLnNDnzJjM/7ejxW+6YC0/brNrw
9k32QEZ5h6tNeOsm7wxGahdhhYvBFMo3gB+pTeT2WxjRYCvGxO3CIo+cLSy2F5rvFJ5D/AibfD1t
H2zu3WHe9JMUUs9zIU/mnJHENmfKLhNtc7h/G1HWRpS1EWW6X2/zTjDR04Y8bURPm3cu2+fRH5ex
voX1j9h3O+M/XXM1NW/SNYuRZLxbVCm1huHgSrhXx/Fo5K2GX3UMh+3R4lJ7jLgUnqukxjA8VgmP
VcJjldQchr90PIbhpUp4qRJeqoSXKuGlSjHQMMMg0M0KMEJOlFei4Uo0XImGK3V0i8KsGYCEHv2b
0Xv2iJ3Ret6ReRD7rOaeq7nPau6xGrusxi6rqXc19tiskuxJsidJb9TLXvp/Rs1DzjLkLEPOMp+9
ypC1jHrKkLUMWcuQtcxnpDLkLfMZqcwwkqX/A5WQ9kX4xiVqHZa9CE+5RC22L9Pe4O//mK0Oc1aL
OStkl6qkfb5aZ18ALlRN9sVqjR1Tqzj6B/tS9SnnvyYCnNXM3vXsfZ897+GhF7B1IX6D77G3jr1p
c14He37BuZ+Y++o7faLva0ofUUIT9mSuuY5e9gbVxNZ16jVKDfYPVYvZmmdPoW79NkKLrU9E0J6k
NtjXoNfJ6k37WvWefT3lG9SvuWIp9d7Anh+qBu5+DXqbTBtvUD9jzxJqm4Q816mbqbGaM69DXl2v
lkDv17UwCrYf4p5khfbD4gju+aiqMN8JMdgdJ+a740WJ+4goNu8q+w3o/46y2d5sEff+xvpZ1pl3
kjWYd5EFzPtXW8zbVJdRW1S/mY1+9+dimP+2rWrzn7gz/zHb4owSuLtNxK31ospKs94oqoiCKqKg
ijPXMyLeKIqFLBjrvwF24A6/+TaZ9fZbW/+Hf+7uFnwLCfR9i8Wx4l5RI6Zzn5kiLp6jPA88D14Q
NVKIuLPZKnM+A5+LuBsUVe7+osY9AAwTs92D2B5O+VjKJ7IuERXu6eAKytM4/07wnDXJfck6MzhI
VASnWmXBu6ybghXgHjT3U1Hh3Y9MD1pl3kOgxprkPQweEzXeXGsS7S0vOFHEC84BE6ybCi4RVQVl
YgY6eKfg+0g9RPydNrwMXgELQB1YCF4XxYGRotgtBEeAIqC3jwbjkPBa1hWiGDtqG8a1DQsu47p9
rXXGDhVovEIOFRX2CZy9qx4hORrlCJ5AKcZ5eivGeVERdjaL6c5nYrr7nJgenAruEjXBCjTwoJju
PQRq1DLvYTBXLSuYgGWCXBHhrChnRfu8X3oC9Tn6L6HZU8GeCvbE0VaRsLPfPGfO6dninBjnlIvh
4ndcvwX8E3QBJaKBk8Ep4FQR1fdF0ojriKj7LXAmmAnuA/eD3wNaSit65fuNmoyuJqOrybQoQosi
3D3G3WPcPea1iqiR4Dzzrr0pSHFvjzdW4Y1VeGMV3liFN5YjQRUS1Bhv3B/vOwAMUx14YRVeV9Xt
dUhQgwS1SFAbvIec2niZqOLuVdy9lrvXcvfajGeJ2XhWOZ6l3wpYj2dViP24+3TuPh2fL+cu07nD
dO4wPbtmaqyhxpqeGh8jM9C1jqXWE2nPSWJ6QdS0T9+hos8ddMSX42nlRHw53lZu3nn4LG09xRqF
D44GY8D/ANRnfROcLDqtU8FpoAScDr4HzgDjwSUwxRXgKs69GkymfD24AdwIfghuAjeDW8AdYCqY
Bv5DRKw18M/HYJ1oQbpOpOu02sVsa4OoR8pOpOy0NrH936Ke2OiEo+rhqHpipNNeKFoCeFvgPFAK
zgcXgAvBReBi0Rm4hqi8DiBTYApAngDyuEtFp9uO5biHyz2Cw7HgIeAwvGA/Wl1Fq6todRWtrqLV
VbS6ilZX0WotbQXSVhn2pBakjSNtlWZRpI0jbRxpq5CyCikrkKSKO1ZxtyruVmXeYLASpuww71EY
YblqsnUwGA4OAYeCEeAwcDg4AhSBI8FRaqw1Uo0NnKYmB0rA6eB74AxwJhgHxoOzwNngHBBVk90l
4EOwEqxSY9021uuBUpOD3D84EAwFV6jJ9CdwJy2tcF/C/wYRI0UmRjRr54kRGRaz5WAwRMzujpes
WEn5rF3lHkv5RNYlePjpgPjR/0kBz55NzKRg5/J+MfMYsdTXw8uz4mcK3l2Ld5eLG8Xd2O4/4ZCf
w6rTwS8o/xLMFsPEE+A5MA+8yL754O9c9ZJh83LYvBw2L4fNy2HzcvEq++sNq5eLf3Dum2ARaABv
gfe4VxO96GrOacGXHay+hnW2Z/gegXZq0U4t2qnt7mONV4wU5QF6h8CdotihD3Y2ArzH6YT34ETz
NlMLHy1gXWg4YZj7VcoH4b/DKR/BviJAPfQy5e5x5u2nxe4JrDNvQK1yz+V64sMlPlziA40Pc+Mc
vxJcBa4GkwBxQg9V7l5H+XowBdwAbgQ/BDeBCo7/jPMqQTXbs8Cf4NwpMF0I3p0O0Dn9zfKet6n+
jXLmTapR7xXz9tQpBXBNwemAPKVgPLhMlIf/Az06SF2f26uJr4pGo+8q9B1Fx3H4Iq7fU4YOa5x/
mjbH3XHWfrS31j2bMgxLu6vIfoYgUxyZ4tTaSa31yKR7oBJq76T2euSKI1fcqxNxZIiLA6i5CgvW
Y0HNQPVYsD7bgiauu61IfGfu3qvtPFooyacFUcidon4OVuHnYLr/L6H2OLXHqb2EWmP9NBISvzVv
ka8Tn4FO8Ll5e3md+xvz5nL9tvI6Udjn72X+ICoGPAIeFeUDsJn+O5nQCFESOkyUh44QU0JF4GgR
DX1dRIQ0f4P2J0r7fKGnpJvV2OwnpYxGxjIaGcvo8EhiyuV4dfaokePVHK8WR+0kx1SZnnLrPDMd
npkCz0wxPDO1H9dMyeKa2XDNbL83nQ3XxEwWeJK4Xec/OX11uQghQQkSlFBjjBpjORmQzm6GiUNM
e/q3pSKnLTWGL/u2pSe/6JdX5GYAc8XTyHuFL+/0nNxivpE3ryRWil4qRxqk6M1yujWZh623wdKx
bUpyASwdgaUjsHMEdo7AxhHYOAIbF8HERTBxEUxcBBMXwcRFMHARDByBgSMwcAQGjsDAERg3QgRN
ycO2NbSmhtbU5MYqjDEF1i2CbSOwbQS2jcC2Edg2AtNGYNoITFsEy0Zg1yLYtQh2LYJdi2DXiM+u
EeK9hcgs99k1ArtGYNcIzBqBWSMwawRmjcCsEVi1CFaNwKoRWDUCq0Zg1QisGoFVI7BqEWwagU0j
sGkENo3AphF4pBge0eOFep9HNAPU6/dPw6ARGDQCg0Zg0AgMWiTCPXwCl6CFCrRQgRY0p2guiffj
kUP8eKvJ9Yyt+KSOrxrjFb2jrlz/TG0nQ52CV9T6mWlFz6jqQL/f3GHW1f0n/WOJsUhf9u3WWoZ9
e5m3GOYt1tozfc1g7ljSj33D8MxgMARorfUysdZeja+9GqM9jxFx3Q4x8UhGOTFGOTFGOTFGOTFG
OTEZtgrlYDDEKmTEE2PEE2PEE2P0G2D0G2DEE2PEW8JIV498Yox8Yox8Yox8Yox8Yox8Yox8Yoxw
A4xu9wv+lPI99DXTzbijk5Htfoxs92FkG/X+rHs962uMfGLYoR471BeQ3zICimGL5dhiecHl1iHY
ooXxYjcbaia8nGizzPu3AzkjuBJxhp9xxYnlOLEcJ5bjxHKceI0Tr3HiNU68xk0P/hbr7l48ky31
7cn7ZkBxYjJuevdMBhQnJuPEYNz0tyfk7/H7ZDpxcCVgZEIsxonFOHEYJw7jxGGcOIwTh3HiME4c
xonBODEYJwbjfkYT39kMIiuziROXmYzCMvMxV6OrqOG93uw0l/+ifjYahQOjcGAUDozCgdGsbDSa
jwvRa0WfbNQSQ9BxdCvZaA/b50YV3BjNykij2COKPaLdHGkizsImGZ6MGp48yMx3ROHKKFwZhSuj
OVyZnYlGsU8U+0TzcmUmC41uhy+jWVloNm9Gfd6M+Azwjs8A72QzADaKYqNoFndGRSg78nUWisTR
fhFvE/EruqNAHJivT+1hzuw+NJsttz6Oz/SfvX1nbb/xe8DMHc3unT8SJ3xZ7+11/rfhX517l/gW
nu5GsYier7pDHG/mrPB0rFGCNUryzF3V9owRnjbjhFrfSiVYqcSfy1rqtZhsOe7PadVw5sP4eIhe
J44uK9BjHD3GOVLDkRp0WIPuKjJzlt3zXPnnuLLmZMZm5rm4Krrdq+Zz1Xyumg+TRnuu+ibe0Clm
ilq4Xs8jdeIVnXhFJ17RCffH4f443B+H++PwfRy+j8P3eraz0PkcHnPMbOc7eE4nntMJ98fwnk6f
/+Pwvx69dbrTOPdOMJPt+8D9gCyfviBOX1AYvJN+4C76g0yfMIU+IYYV9KwnXmcVeg+BGuto+oaj
6Rtift9wNH1DnBa9WXAO+phAXwCXZvUNY/DAdjNfZ3ox3WPl9FQxI2luL9XdQ2WkKkSqwiypyk1P
9ZDprQ5BokOMRHNZ655qglWY00MdbXqoE9FvBfqtgDPj8GUcvozDl3H4Mg5fxuFJPTov7uZDPauc
zXs5o/C4b/Eqw29BpC5EnwcQscPBEZSLAOfBbXFaWUFEx4loPe7bbLjtCjO/G4eb4t3cZMYXmb64
ghZW9HhohpfqzbgQb/X5qbaHn8aaWdUqWj0Fbor7cxw6e54ijsHDKrBBBI+KYIcIHhXBoyK0UOdL
LbSwhRa2YJ8IHhbBwyK0bjmtW46XVWCriDuA9bdYnwmmUb4TzKR8H7gf/B48DqNOFcvx/3b8vx3v
0bG2nJYspyWdtKQT6TuxUwS+mo/X6HFPO/aKIHktUuvcoROpa7HBTNgxfw4UIAcKkAMF+uZAohOJ
O5G4yniXjovsPGga++8E+fKhW1VTtqcZL7sfZsl42ud+XnRIVl60n58XvUpOVEFLqrI8731aUu/n
RovFaL8lUb8l0d6WiE5034nuO/356z7ZnN+SaE5GF81qSfacdszMad+qlmGDTmInmhM7OsubktWq
7mxvP1pVktWqqMn2TqU/ybRqgJnzzo2nEbSqxrSouzVCLO/Tov6tqfFtUmJaMo3tO8Hv/ai+3zBm
rmQ9+kaqV3xd1xhdX8I4oAxk9LxcfH1bT1n8bKcoK9sZRv9XvpMjwXL9tMZEfL4nNrpf85/Y9ET0
dDMX847fb0WyMosSMyrTT3OO9z0k7ntIfCv5fnwrvh73mTTme0g8y0Oy+T7m871m1rjP9eU+q+Z6
Ri+z/hnbZHg+2yv287m+BRu0aK4Xjvkd3nzVkP1bOSFpU4BxjxCFYpAIir3FUBES+4tvszVOnCO+
Ic4Xk+kJbxV3snUX2WlMvC1S4jHRZoVFnTXY2ks0W0Os/cVq66vWd8Q66yzrbPZGrXOtva0Lres5
9iPrLmuk9VPrbmuM9XvrCWuslbRardOstXzGWyk+Z1lt1nquS1sbubLDUtYEKWXQulQWyALrB3Kg
HGhdIQfJQVZc7iX3sq6U+8h9rKvkvnJf62o5VA61JskD5XDrGnmoPNS6QR4mD7dulEWyyLpJHiWP
sm6WR8ti6xb5DTnaukOOlSdYU+W35YnWXfIk+V3rp/IUeYr1P+Xp8gzrZ3KcPMe6V54rS61fygvk
xdZMeam8xqqS18prrUfl9XKK9Ud5o7zR+pO8Sd5kPSZvkbdbj8ufyKnWf8m75E+tp+SvZJVVK38r
f2u9IB+UD1ovyt/LP1rz5WPyMWuh/LP8i/Wq/C/5jFUvn5XPWo1ynpxnvSVflPOtt+Ur8hVrsayT
r1nvytfl69YyuUgushLybfm29b5cLBdbH8j3ZMJaLvlYSblKJq0m2SxXWx/JVtlqtcqUTFlrZJts
s9bKtExbH8vNcou1TnZJZbXb0pZW2nZt19poD7ALrU32XvZe1uf2vvZXrC32fvaBVpc93B4ubftQ
+1AZsA+3j5COPdoeI4N2qX2ZDNmT7B/KfexH7Ufl1+xF9iI5zG6035IH2WvtLXK4rQIFcnSgMHCR
PDlwSeBq+YvA5MBt8oHAnYE75Z+cE5wT5GPOic535ePOqc735F+ccc44Odc52zlbPu1EnXNlrXOe
c778q3ORc7F8zrnMKZPPOxOdifJF5wfOFXK+c6VzpXzJuda5Sb7s3OLcJl937nCmyTedu5y75VtO
pVMp33X+07lfvuc84PxOfuQ86MyRLc6zznzZ6bzqLLMt50NnnT3E+cRZbx/ipJ20fZizyfnMPtzZ
4myxj3aUa9nHoJ4B9nGu5x5nj3FHud+wL3PHuN+yL3e/455kx92T3VPsq9zvuePsSe4E93L7Ovf7
7sP2j91H3dn28+5f3CftV9yn3Fq7zv2b+7xd785359uL3Jfdl+0Gd4G7wG50X3Pr7bfcN9w37Xfc
t9y37XfdJe4Se4m7zF1mL3U/dFfby9xWd629ym1zN9jN7ib3U7vV7XQ77XXuP11lp4JWMGSvDxYE
C+zNwYHBQvuz4ODg3vbnwaHBEXZX8PDgEYFw8Ngglgh+O3hOYN/g+cGyQFFwYvDqQHHwmuC1gW8F
pwRvDnw7eGvwtsApwZ8EpwVOC94VrAh8L1gZvDdwZrA2OC9wVvCl4EuB0uAbwTcC5wcXBRcFLgi+
G3w3cGFwWXBZ4KLg+8H3AxcHlwdXBmLB1gHhQNmAgwcUBe4eMHrAaYFfDLh4wI8DDw14YEB74KUB
nSHLGRo6NnSac1DoitC1zpjQE6EnnO+Engw96ZwUeir0lPPd0NOhp52TQ8+E5jmnhF4MzXfOCL0c
qnPGhepDrzvnhN4ILXHODX0QWuNcFmoPtTvXhjaF/tu5LvRp6FNnSuizUJdzgyc96dzqOd4A5zYv
7IWdH3uF3l7OHd5+3gHOnd5B3mFOhXeEN9K51zvWO9b5pTfGG+P8yhvrfdP5tXeCd7Iz0zvNK3Ee
8M7wxjvVXtQ716nxzvMucP7gXeRd7MzyLvUudx7zrvBudP7s3eH9xJnnTfOmOS94d3t3Oy96ld69
znxvuvdr52XvPu+3zqtetfews8h7xHvUWezN8mY573mPeY85S7zZ3mxnqfe097SzzHvGe85JeC94
850PvZe9V5ykt9B7zWn23vQWOS3eEm+ps8b7wPvA+biguOBEZ13BSQXfdTYXnF5wjtNZcG7BBNcu
KC2IuU7BpQWXueGCywsmuoXhD8IfuIPDyfBqd6/whvAm9ysDxUCb3Fee+A24XpzUMb5OTBDfF/+P
LWpZ73d3SW3gc4t6g5LGPRqqwz8+cTfffyZ4KM/+BpDIPk/NQqY5arzZ+sTI+ck2a97UU2rKYM8s
6mPQBpp37io1j8/HO3z+u+Z7w85Kl7eulP6YUkumTvURwMJq5RescUNf6frLqdK7S/qt3T9f7b1+
vdUrU7019NQxxMSA8RjVuo1r0/n25d/bV1o+a1RTt0+qjduTcqsSbNDyZ2LTt2iq51iq39mpfHt3
12Jq/0It6bZSHhtk2tTa7T39W9DNS3335d/b5wzspFapZT7/behpwU7rR03TnKSm9WuBX+I+e8zv
d3Tpy4Dq5Jyjk5WrhqjJpsxYB63o7wYxzGwv02UYo52t9p5rUmotjDzLlKvz3LEark5pjhPGltrK
fKp9fT+j6rREfDaYb832E7Yhfx01NVDjMlOfUCOyji3rjtat69lY+yVT0mz9D/D61u+2a4up/S2w
Zqeu6kALK7J8dEiec7J6afSxLNOaXV/MvTNsp7XzPHarA/Q4at12r03tdN9qfUEx9/iCFt7bk5nC
nl/UevUq9lv/JUvx0m6qJ8MVPVlgVim/3+eJmT2xaL7L8JC/FHHnYtbF/c5c0fstimGpFZr32DOL
UpPerxlUsx+LZ2aUus/OqSdr77C+tfecsZjPTHV7LxsT10/w/fc89dWRSzeYzL5hO21t6v3OLqkJ
qpFvjfEZ+Ptnbru+nV3UBeD6rcmVtT3W/0zcTn26n1hlStPguH8Y/pqphquf95wxbRclfk09rh73
y2kVVj9XJ6salWfkqH0oS7Nf93FyRk7D7/8XcVFu5kTWVqde2Vb+/K9YsseQZnsbGWo/n2pQc7cX
Ib3t03Gm/r6n2tvtDerFbZ6V6s70fO5shWl+txN3edV852GgXVlUrZ8Rabb4aNtt6NW2zzxfV3tn
4iI/F5mR7KCey4eI7F6gaHe1wF/292v3cmTuliiT5471z/XlgJMGd23RPNadKWcx9DR8rK/XDYHf
M/VUww+RrWTXJq82Z3Tftclk25nx0hzz3TsSbDJ6TJm6dV9VJHL6ykw2aRad8w/uLmX6GvqKYv3t
n5vOfOcf6f6rlm1n18rN2Z7Ule5SapIpr+v9zpS23g4zCtLrRXmOLdJ7GUOu6rvXX69Va/tdcUrO
dnufrbrsrKJrG+3zLbAhe1ttVJvIAfwRrKrPYM8sZrT2bp79Wxk795+FybBkN1eiw1b1jilpL16Q
GVOoB43fZtqqSx/kqfmD/Hu75eFjxviqJTOG9ff+mfs9Qq78XL8r53SPMXvnRQ3MaFGtVh/q7/yt
9Gto6SmtMfy7h+ZbjI52el5BXaKzC3WJKa/s/e4udc8LfpmL8a4+WVGfo8+bjPn5narxS+SpPFlF
I6x/r+4Ld7Ke3Wob9Zuc7VXbODenv1ZXqVP1tyn/1Xy/1HPsryZOth4jw7Z6ZLcuxkvm9GyN6OnN
TE5An+yqwf6c3Uzy1OrMR4/g1GT1R/VLM9v0DFvPZFiZ7XnmWIYXxue5Yx2fZWq86a8jZs89Zp8Z
EamJ2G+Z2TONT5PuTemTV/m112VL6197MteMYG3u2WfGK2eEknny0Pv8QZcM9zV1z4vrGYE9Nyuw
1dn3XRi9qKT5nmeeSnSI3fgMx9fMsuxoMiPxvJn7HuPv7T6Z2M71rzDWyDOy3+51DT7qdu3+fm15
RlNkInn37o777b4FBsjk4oPzHNMROosz7sFKRdov2J5BHN7tXzkLv9Tn3MOnerszDjO7Z0j8GfYs
7tjluYZdjAgiYQWfnWSGrJFF3a76sZj9Ba7Id83O1jM7C194IYfUzLpp+2eKvXZzFjIsZ6z7JS5k
uSt295zBTsvwyVbmTRcL87y1z97F2dtm3jS1Y9nVv++cHG34h37y9P/hEvex68suclGPDb4ULjIS
7Gp/8J56N9/IfjtXpXrGyXV6hLyrS75IzMRn7pP9nl9v9O4fYj47vuwsg0Z28vzcZZgZhRRvs57i
/k+SduOyJ+v+d1mqduCcaJ8tM/8kSnbDfbvxhRd6rQ/FMP1UPs+xpt5ZMbOd+e3PbuqT1Nh/o6yi
I7ff3uka2ndRhGFI8FGeej8yTzFys4o8Z36xu5rnC7tsgwyTq/bMM52cY6/qvfhZ9wxsZj7WPzN3
TnsH7tUnL1InG+l3eaZHva/eNzl2nidwqsHMvvfYwJ/b7Z59X72LnnPR7mnBNu+R17vz/XJtB+vb
4ZmKvr9SQ78b9O9e9JwZpVozmzNTXdf7JF9NZH9LnnpatrK3pw344HtkRY+rR9Qj/p616hL1sLpZ
/V39r35X6l81NWc9AZwIxome36up1tynuWbZSqT0/CZskP98cFCekwblPDsU+c9Ua3p+KZjMREuP
9vrPGnn99nTXcmTXFuX6s+/V5omE+dZzkpRe9X/T1dq3VkY2E/3f2eWbdZzJp0ndYmYzMnOb+nfF
MzNzQ+zPzF02kJmZb7YOzGc1v7YG9XWuHq9/A2i2B2cdm2c84Tjh/wbcfzLWay09q/ThNvK/f9XM
b1327BY92jD/iWdGO9/uSnelfRs8ZfTyN/WCesHY4FdGd8sytu6F8aMf+788vDLPHWeZp0Z3c+2G
TFahnqA8x38Oe4f5RaWe+Z3Fp8H84v0k8yy8z7P6ntpmov9Z5vyHzNG9s45VG5ueIfynsWp573d3
SSUzc6d5l3+VDRqyW0X89p19/4EaofZXPzHlv+lff/Kt40A/7Z6j6mGMJnr/7meZqZ7s/37/11N3
5rmjttxH6jfGSpnZ9/rMr0ZN+Zf+8/EGf5Ze+8jZJtI6RJ7f/fbM1Nf5M9BHZh3LmTnVvxHp/u4u
qU07NCe0R5e+zxO2eWb234AMMa03T0bxwsXkAotzYyrr7Jx6/g91VwJeRZGtT1Xfrr5dNxsQQiAJ
JCwhQAKBhC0kLGHfd2QTEFAREXkKroiKuI7jgspdc1UeMso4go4iIm64DCM+dXyI26jsoIMoiIgI
ue+vk4AsYVXfvNf1pXJyurqqbnfVOf9/c7rqJNrD/3et+N7949hy8w1q5VljTxefeFf53EqOj5hD
p41S+/92VN7xNzDazYh8M/bRSUv+Yl9XwvquxD2sEmfG3ovlnXtfYPVNbPYmtlrcH/x+M/bmKa+r
fGKVlmjxGbVV8R+3k8UJrKxaf9paF9Mv/0XbWdEK66qwE7/2MDGTxx3NfsnPfM5VUTOuNf9prQqv
n/baivF0Rgjw3BHmKWvdedzvdyufxRn8nxuoYRl7us+riuaoLHM47nTsEfxxDOeNjav8vbEqlHQm
B/vOfpgDZh48xPON+4PffzvldYdZU8X/k045Z45cU1H2JKz97GMDKq97g478b48Z6pyK/vwe86DK
9mshu4GluN+46nFHtbLsyHifijQBPxUWSJWvK98BdKSq+p/emR6xuPJPKp4hLGoVkXenvf6Etk/e
n6P/p89/jyg/aNBSRazg/53j5P05/n+feAY7ytdhFqny735Fe3GHxw/swrhTl63qOLHtk/enimew
4//3M/jlKP83xl5XFb9YdX+MRf9tDuB/E/myx7y1fMK5tfwu8/Zj+frhkpX8YtOZf4/KeONknlrS
LPKQ8UMDaCD1psF0M/WlW2g+zaYHaQWvbv4uPU3/oB30Fn2N9AXtRPqSdglJG4Qt4ugHkSiq0SFR
Q3QSJPqKASKP1wdpKYaKaaJATBe3iP68MsgksVFsFTPELhETs3gFkNt5BZA/8gog9/AKIPfyCiD3
8Qog9/MKIPPN+hTiAesrz0jxkGeM5wppe2Z6rpIZnhs9N8lMXnWivt3R7igb2J3tHrKh3cvuJZvZ
fexBMtceZg+XBfYoe5RsbZ9vXyHb8LoS/ezr7AVyoB2ww3KaHbW/lTPMahFytb3X3itft/fZ++Ub
Zs0I+TezZoRcoyxlybUKh3xHaZUh/0vVU83lRpWv8uVus4qE3GNWkZB7zSoS8ifVW/WRP5v1I+Qh
dYG6wPKpSWqhFacWqUVWP7VYLbH681oSQ9TT6mlrmPqretYarp5XL1jnqRfVi9ZoXldijHpVvWaN
5XUlxvG6EuPVO+od6wL1vlpvTVQfq63WJbyWxNXqG7Xbuk7tVQesG3kVidt4FYk7HZ+TYM13qjnV
rQW8fkTArB9hLTbrR1iPO+2dcdZSs3KE9aFZOcL63JnuXG5tcK50rrQ2ObOcWdZms36EtcW507nT
2q7H6vOtHWZ9BOtrsz6CtdOsj2B9Y9ZHsHbpe/S91m79gF5gfa8DOmj9qCM6Yv2kn9PPWQf0C/oF
62e9Sq+yDprVEKxD+k39phUzqyF4yKyG4JFmNQSPx9fKV+Cxfa19JR7H18XXxZPk6+nr7anm6+sb
6En2DfYN9tT2DfMN99QhKX7ECPZQB7KRLFJINjlIKeRFcsjlZN5Z8iHFIcUjJXBK4u/VquN3EvTV
kJLxV3VcWwOpDv+HLoVqIqXjdwr4ei2kEkpFyqTaSJ1Qqg51oTSkriiVTvUpA8nE8TVGr3KoCfrQ
lJqjVy0oH3W0pPbQFKEWH3WkXmi3N/VBX/oiJWEu9kP7ZjZWx2wchvaHA1Ok0HgkhybQRLQwiS5G
T6bQVNRxKc1ET2bRNejDtZi19YFrbkTrNyElYzbfjGtvQWpE85Dy6VakbLoNKY9uR8qhO5Ca0J1I
TekupEb0B6Q8zP27wRX+iJRL9yDl0b10H87eD+uQD+vwILWmh5DM/iMLqC35kfIogNSOgkjtKYQ0
mMJI7SiCVERltBg1/IkeR7tP0F/Qk6eQGtNSpDxaBouTA4uzCj15iV5GyVfob9Cvob+jJ2/TWvTk
HaQ8+i+kxrBM70L+B32Ikuthk/JpA1IObaTN6NsW2Kw2bLNasM1qS7voR5TfTz+jbwcpRu1gryQV
wYrZlC+UUCQEJg3GlFd4ySNc4VJNoYUmJXzCR14RB3unYe8SKV4kCYweUQ22rxpsH8aLSBbJKI9E
tUWKwLgRtUQtShOpIpUyRG1Rm+qKOqIO1RNpIo06inSRTp1FhsigUlFX1KUsUU/UowYiUzRBT5qK
Zmg3V+SjJy2F2XWkQHSAplh0Qh/6in7oQ3/RH30YIAagD7C5yIeKEejJeWICyl8gLkD5iWIy+nCh
uAR9mCqmoQ/TxVXow9XiOrR+vZiDdm8UN6PduWIurr1F3IJrHxaP4J48Kh6lJmKh+E9qJBaJxyhP
LBZ/ombicfEE5Yol4s/QbBQbqa/YJDZTN7FFbIW8S+yifuJb8S0NEN+J76i/2C1200CxR+yB/nvx
PfR7xV7ofxA/QL8Pc7iv2C/2U0/xk/iJeosD4gD1Ej+Ln6mPOCgOQn9IHIK+XJRDHxMx6gP/Iam7
tKRFPaRHeiDb0oaspILsSAcyvAu1Mt6FCox3gQzvAhneBTK8CxUY70KDrK+svdTB+sE6SI51yCqn
OCvmsSnFozw+SvXEeeIp05PgqQE52ZNC9T21PPWpkaeBpynleJp5cinPk+cpoHxPoac9tfQUeTpA
U+zpArnU043aebp7BpHwDPaMJAUfdgHV9Ez0XEy1PFM8l1A9z1TP5ZBneK6gLPi2mVTimeWZRW09
V3muorpmdSXUdpPnJmpuvB1ZxttRCrxdF+SldleKs7vZ3SB3t7uTY/ewe5BrvCB1ghfsg7N9bdgW
u5/dD3J/uz8lmzWZUH6gPRCaQfYgqmM8JZUYT0kN4SnPRz7OHkdF9nh7PCWYVZqomX2BfQHkifZE
yJPsSdTBnmxPRg0X2heitovsqZRpX2pPg/4y+zL0ZLp9OfnsGfYMtP4f9hUoM9OeiZpn2bNQ81X2
VTh7nX0d+nO9PRtX3WDPwVU32jehzpvtuSh/iz2P0u1b7dtQ8+327fjsd9h34Oyd9p3oyV32XdD8
wf4D6rzbvhs1/NH+I2q4x74f186351N9+wH7AegftB8k237Ifoiq2wvsBfikATuAa4N2EDWH7BDK
hO0wro3aUbT4sP0wrn3EfgT6R+3/RMlF9iLU8Jj9BGpeYj+FkkvtpbjPy+xl+BRP28+jVyvslfik
L9ovo5VX7NegWW2/iU/3lv13XPW2vRb3+R37PdT/vr2Oiu0P7Y/Rk0/sz9GHL+wv8bw22Bupi73J
3kxd7S32FvRhq70dn26H/RXq/Nr+GjX8y/4Xathp70T939jfoMVd9i6U+db+Fq0Ax1C+wTHI99n7
KM/+0f4R8n57PzUxmIbMOlhEzWDwBOUbZENtDbKhIiAbjdyn4nA2XsVTI5WgEihPJapElExSyZBr
qpqQU1QtnE1VqZSjaqs61FSlqTTKVekqA2frqXqoIVNlorYslYWz9VVDlG+kslG+scpBPU1UU5Rs
pnKptcpTzaEBlkKZAlWAqwpVIeQ2qj3KFKkiamdwFeTeqjfK91F9oBmihqDMUDUc+hFqBGWr89QY
1DNWjUcrQF3UBKhrElo3a0k3UpeoS3F2mpqOfl6uroB8pboW+uvUjajhJnULap6n7qA26k51N+7J
H9X9KDNfPYC2HlQPUXu1QPlpsAoo+DgVVGH0M6IiqKFMlaF8VEVR5mH1MM4+oh6B/lH1KLVQC9VC
am6QHzSLFTyg+pP6E/rwuHocNTyhnkD5JWoJ+vAX9RfkT6mnSBpcSDUNLkT+vHoe+Qq1gjzqBfUC
eQ1GpI4GI1IiMOKrVMOsQIYyQIpU2yBFqmuQIjUwK5Ah/0B9SPFmHTISZh0ylPxEfU711BfqS2g2
qA2k1Ea1ibTarDajzi1qK8psVztw7VfqK+i/Ud+glV3qW5T/Tu1G+b3qB5TZp36kNLVf/YTaDqgD
6PkhdQh5uSrHtTEVI+NUPVTTsR2bshzlwM86OMjjeB0vVXNcx6W6ZrUzkk6cE0f1nHgnHmUSnARS
QK7VKM2p7lTHtbWcWtCnOsB9TpqThhrSnUzUnOU0RMlsJ5u8TmOnMWmg25aU6LRyWqP+9k4x1XBK
nM4o2cUppdpOV6cH6uzp9KUMp58zEK0Pcoah3eHOCOronOeMpM7OKGc0lTpjnDFod6wzjhoAJU9A
yQucC3B2ojMR+knOJPRnsnMhWrnIuQg1X+xcjJovcS5B61OdqbjqUudStAtUTfkGVSMHqqZCoOrZ
lOfc4NxAjZw5zhzogbApzyBsqgmEfT3k2Xo25RucjRw4G5rb9e3UTN+h76BG+k59J2RgbuQP6AdR
5iG9AGWAvKm1Qd7UxiBvKjTIm4oM8obmNf0a8tV6NTTA37gW+BvXAn8jB/6mfODvVpTjK/DBowGF
t6Ymvja+ttTI187XDpr2viJq7evg60BtfMW+YmrrK/GVUJFB6ijT09cTZXr5elGer7evN67t6+tL
ub5+vn7Q9PcNQJmBvoEoAxyPGob5htFg33DfcOBDKccxmu/GOD6JUXtSJV6vzjjdIPIkxuLdGYv3
YCxek7F4L8bifRiL92MsXpuxeDpj8W6MxS3G4kmMv5NQ1iDv4cDWSYyquzOq7sGouiaj6j6Mqmsz
qk5nJJ3BSDoTOPp2ymL0nMfouTmj5wJGz/mMns2K8fdAY3BzIXDz/Sg/H6ktPYCUxRi6kDF0EWPo
YsbQJYyeOzF6nsDouTOj51Kg5zJ8kihSBj1Mj0FeDCSdAST9BGpbQn8GSn4SSDoLSHoZsPLTSFn0
DC2H/DywdRa9AHTdgl4Ewm7OCLsACPsVMJJXkfLpNXoT8ltI+cDdf0Pf1iDlA33/Hfq3kQqAwddC
/w6QdwG9j1QA/P0PaD7gtXbXIRUCi68H8v4IKYs+pn9C/hy4PAu4fCPObkYqBDrfgk+9lbaBI20H
Ui+ir4DU8+hfQOrFQOq7wI2+RSqh7+gHyPuA3UsYu3cCdj8ItnMIqTOVA8d3EWapllIhgeZLhSUs
KmRMn3kUpvcxpk8EpgcLZByfKOJFAuQkYHcfY/dExu4+xu6JjN19jN2rMXavwdg9mbF7T8buvRm7
92XsnsrYPQ3YPRN4PUtkod36IgdykyNoXgLN56LmPNGcHNECyD5RtAKyd4HsC8AuCkUhWmwt2kMu
Atb3AeuXAOt3BOJPFJ1FZ4oTXUQX6EtFKdB/V9EVcjfRG3If0RdyfzEI+RAxFPkwMRzlR4AP+MAH
zkM9I8VI1DNKjIU8DtwgEdxgIs5OBkPwgSHAiomLxMVUXUwBW6gmLgVbqCEuE5dRCjjDdHz2y8VM
yLPAH5KZP/QGf7ie6ojZYjbuwA3gEnXAJW7EfbgZjCKNGYWPGYUr5ol5kG8VUepqvg2qZA6jmTkM
YeYwmpnDGGYO5zNzGMvMYRwzhzHMHM5n5jCWmcM4Zg6jmTkMZ+ZwHjOHEcwcRjJzGM7M4TxmDiOY
OYxk5jCUmcMwZg5DmTkMY+YwlJnDMBkn46idTJAJ1F4mySTI1WV1yMkyGXKKTIFcS9aiejJdppOS
9WQ95NkyG3kL2YJqyQ6yA/KRciSNkpPkJOST5WSy5cXyYuTT5XTks+Vs5PfKe2mADMkQNZKPykcp
Ry6Si2iQfEI+QQ3k0/Jp5C/KF3H2JfkSzq6Ra6ipWTMW+Tq5DvnH8mMaLLfJbZB3yK+oidwv91N/
Cwc1NOvBUrblWi5ybWlqbMVb8TTQqm5Vp/pWHasO8jQrDWcbWg1RPtvKRhnDi8ZbHawOVM+abc2m
rtZN1lzk86y7kL9gvYDcsKZuYEc1wGcML6oNXlSLMjypYEd1wY4agM80BEfKBUdqBi6UC6aUD6aU
B31z8KU24EutIbfxtIPcHtwpC9wJttnTAQyqIxhUCeSOns6QSz2l1NnTFWyqC9hUd7CpHuBUHnCq
weTzDAGz8npGeUZRvGe0ZzQ0YzxjKNEzFlxLg2tNgjzZcxHki8G7EsG7plCy5xKwrxSwr0shT/NM
h3w5mFgymNgMML3/AB+rw3ysB/OxYuZjNTyzPXNQv2Fl+czK8uxOdiegcMPBkph9Jdg97Z6QDQfr
xYwrAYxrIDSGZfWwz7PPo5r2SHsk1WbGlc5sqhvzqCTmUTWZR3VjHmUxj6pgUEnMmpLsa+1rUadh
Td2YKSUxR6rJXCiduVA3ZkFJzIJqMwvqxiwoiflPD2Y+NZn5dLMjdgS1ldllOGuYT21mPt2Y8yQx
w0liDpPEvKU785YezFtqMm/pxbylD/OWfsxbajNvSWdmkg5OshcM5wf7B8piTtKGOUmWfcA+QAX2
z/bP1JaZSYEds2NUaJw/ZTE/yWR+UqxsZVNnZimlzFKywFJ8VKDiwFUKmavUZa7SkrlKG3CVJCpR
1cBYOoKrpOJsbVUbKLwOuEoL5ioFzFWymKu0Yq6SxVylBbhKfdTZAIylLjOWXGYsLZmxtGHG0pIZ
S0dmLAWqpWqJaw1vKWXekqFaK4xqZi9tmL10UR1UB5QsVsWouUSV4BN1Ul1QplSVggN0VV1xbXfV
HZpeqhdyw3MKmed0Zp6TwTwnk3lOLvOcLOY5uWqCmgDZsJ08ZjstmO0UgO1cAi4xVU1FPZeC+bQE
87kCesN5CsF5bkDf5oD5tAXzuRmauWouytwCFlQIFnQrenWbup06qDvAiIqYERWDEd2Lu3ofeFFH
5kWdmRd1Yl40gXlRZ+ZFpcyLCpgXFTMv6sS8qAvzogzwooXorWFEGeox9ZjZEwaMqIAZUSkzos7q
SfUkerJULSWfekY9A07yV/VXcpkLJaqVaiVyw4J6MgvyqVfUK5QMFrQaesN/aqi31dvQrFVrKZW5
UBq40Pso+YH6APk6tQ55BSP6SH0EdmR4kWZelHwUL5LgRRtR56Yj7CgO7GgLNFvBkTQ40nbUU8GR
vlZfQzZMyXeEKX0HtrYbfMmn9qjv0YphTZpZUxyzpmT1s/oZ8kF1EGUMa0qrZE3kEPmYO2nmTqlH
cadEZk01jmJKPifJSYLeMKXUo5iSj5mSZqbkA1OqD47UAHzJ5zRyGkE2rMlXyZpynCaQmzpNKc5p
5uRBbuG0gJwPBuVjBqXBoHpANtypGnOnGsydkpk79WTu1Ju5U1/mTqnMndKc8c54XGUYVA1mUL2Z
QaVWMqiLwZd8zJfSnMucyyBPd6ZTpjPDuQIsa5ZzFXLDkbKYIxU6K52VVMvZ7XwP1nfQOUjK280L
PuB9w/spjfJ+5v2JbHeSO4mUO82dhnyFu4Jy3Jfdl5G/5r5Gg9zV7mpq4K5111Ij9333HzTA3eZu
h36nuxOab91vUXK3uxssC2CJmmpb2zRYu9qlAl1L16Imup6uhzxTZ+FsU90MZ3N1HuRWuhXyzroz
1dfddDfK1j10D2qse+veNFD30X2gH6qHUkOz7jT115P0hSgzXV+OszP1TOiv0ldBc7W+Glddq6+F
xrDBLH0DeGCWnqvnIp+nb0Vu2GAJGOA9yO/VYBl6PnhgFhhggNoyAyzSi/WfqFQv08ugf04vR/6C
fhH5Kv0KFetX9atgjK/r16mrXqvXQr9er0e+WW9Gndv1duqsd+gd1El/pb+iUmaGJcwMM32FvkLK
Yh5YxDywmBlgMTPATGaAWcwA83x9fH0g9wUDLGAGWMgMsK1vkG8Q5KG+odSZeeAE5oGlvhG+EZTh
O883Cled7zufWvom+CZQiVnvmprG7YvbR03NqteUHW/H25RNMi3frH2dsab+emoHtvB/4IjtrIiV
O9d1qCtWrThOx/E2x6w2fX9scWzW4dWmj9LviX0Yu/Xc2o5tjd16grJJ7CP+T/LmIzE/BRz1bt4W
Nyu1mHccKt/1+feszILWk/lzn2vryecab3auUVDH1bLoDMrs5ChU81MZhxnbbtYsO/Mazv345VMe
jtqOBX7P9k59xGbR/9JqOcev0AXNFLOqDD+Nc+4Bz5enTtBWxHMdjjhedHQcSsWcjCXHevHvXufy
tGNjY2NpSKzEXH/cmQLOQ4f7FGtyTCS5Pl3sy9ndCX56p1qv/IR7/lu2fty1J41oPqMjGRZn4/Gf
xVhoXnfuk1O84fCrjljW4XZ+sxrPOBKy/JNy8/mGHR3rbuIcy3dxDOqVJjb1hNozfyl3RHf7kRrP
0oKejY3/ja2Eed47qxq7FW92Hz+afm3rxz7h3/J5n0Hb7x7t2TCWj/6rzxHpPX5D6DfuWez+o8cH
a24/Wdnf+sAn6oNxfGQ+xHbFIsfOjsN34rfx/Ce0/wkdvSLY9jO7u/wUVp3i/AnY4STl3jdv+x35
6x+cn2btnAoUElt1svciTsQOp6nvLHb3iI2uqq1f2jnt2ybDKsuZu97MxFKbKPrDdzy2FD+1+H3P
+2HX3jv2icNLZlRK5n2U92J5jJFNuQrsn3Tmn+M3P648XQHM6N/Lnpzxyg3lZ7UXzRnVeNp3c45d
zZo1/0sr5Zxm5h3X89jLZ1n74XXOz+jNjpPW8m95I7DCn4BdnvV4KN//q9rlWWK8TcXvX/NeVBW1
nxX6O9nKVFWPmqPWNjuH532URX7v9/Fip2ib7/ZhHwN7+6vG6wm1n8E9P/JOfOV6AlWU+Lwq21jx
nQ7/nGOfKz/7OVje2LBza7Hy6l2/5upff1SuaH0GazZVes5f/HfFGh316IinPsuj2TG1V/HGxe91
nL0tO6vafydmyXWfMM4P8/8Tv7P4jVo8sm75ab9pmHDc3x9VfJ9wTq2e8fepv7RtmPfhucjfsi4+
HoFS5brCp/6G5oTvU4cd/X3qGfT9mdOXOem1y87xuorRkIy+r6jqPWrozdM45RvWQMo3ste58Wz4
U+zK2Cfl91d8TxALm79+YYTlhiu2jl1ZFRI4rKv67bzyE7/nPovjKA+89vR2pXJVjlO+oXsWbf/i
v38/FP87H1XtVfC7t3nYrv2qJ/8r+/D6v6HRw3t8VNxzSdM5bolkPZlJwuyrTRZHL3nMjtpky1yZ
WxnJ5Jh9tckr28sOpGU32Y3iZX/ZnxLkQDmQEuVQOZSSOM6pmhwjx1B1OV5OphryYjmFapt9tSmN
o53SzY7alCFnyplUV14tr6Z68jp5HWWa3bUpy+yuTQ04FipbzpfzqbF8UD5IOWanbWpidtqmpvIR
uZCayUXyMWouH5dPUL78s/wLtZJL5VJqLZ+Tz1EbuVKuorbyZfkyFcnX5evUQb4l36JiuUa+TSVm
v23qzLFTXeR/y/VUKj+Wn1AP+U/5OfWSX8qN1Edulpupv9wh/0UD5C65h4ZwNNV58mf5M42Uh2SM
RpmdtmksR1adb3ktH42z4q0EmmhVs6rTZCvZSqGLrFQrlS6xMqy6NNVqYDWiaVZjqzFd7jznPEcz
nOedlfQfZvdlmmV2X6arzL7LdLXZd5muMfsu07XOdudnusFre+Novtl3mULeW7xB+rN3ifc7Wm32
XRau2XdZVDP7Losc9yl3qWhpdlwWBWbHZVFodlwWrc2Oy6KD2XFZlJgdl0UXs+Oy6Gp2XBYDzY7L
4nz3e/cHMc790S0XF2ihpbhE2zpOXGp2WRZX6mSdJq42uyyLG3VjnStu0210e3G32VlZ3Gd2VhYB
s7OyCJmdlUXU7KwsHtEj9RixSI/T4wXvrCyW6Gv0NWJF3Ka4reIF899c8VJceVy5eM38N1esxrj8
iMel5Hg6KTMxOj08Oiti6ySPTsWj0+XRqTE6C6FvjTHqwRhtj7NFR0ZqIY/UZjxS2/BIbcsjtTWP
1EKM1PE4O0FOhN7E6LXmGD3BMXpCTsEItngEV8TrCR7BNo9gL4/gXB7BDsfxCXkDxrGFcXwzyszF
aM7l0dycR3Mij+ZqPJpr8GiuhdH8COaSifirLRdiZLfkuL98+RjGd5rZTx65iQGsiVH+Z+RPYqzX
4rGeyGO9mtlbHrW9iBFfk0d8Sx7xdXnEZ3KcYH2zzzwVyLcx+pvy6G/Ao7+R2W0euYkfrCc/lB9i
1q3HfMjhWMJW8hPMisZmF3rkn2NuZGFufIl8A2ZII54hmRxpWF9+jXnSxOxIj5q/ld9RQ7lb7kYf
9mDm5PDMyeOZk4CZcwiWolyWw0bEMIsyeBZV51mUglnkJR9HKcZxlGKq5cO8SudYxRZWAmZXHbOb
PXITt5iMOZaMvCZmWgrPtASeaUlmZ3vU2RDzLZnnWzrPN4X59jzyFZh1mmddM551zXjW2TzrbMy6
fyL/HHMvl+ee5LnnwdwrJuUt8ZaQ6+2Ieah5HhZiHj5NzbzPeP9KbbzPel+nthyB0tr7GeanMPOT
LMzPNmS7bd125HXbu90p18xVkmZ3dEpzl7pLqaaZsZRoZizVwIxdgfwF9wWcXemuhP4l9yWK5+iV
2hy9ku+udt/A2TXuGuR/d/+O8mvd9yCbSJbm7gfuf1M1d537IdVy17vrcfYz9wvIX7obqaW7yd2E
kpvdzah5i7sF8lZ3K2QT/5Lv7nB3QAOLgBq+d7+nLHevu5cauT+4P1Cm2Y+dCtz97n5q6v7kHqQG
7iH3EDV2y91yyoTVEFTP7NNO2Rwv00or7aXGHDVTV2vto/pm53YqMDYF+mRdE/oUXQv6VF2bGuk6
ug7Opuk0agpbUx+aBroR5cDiNEb9OToHVzXRTSCbiJtWOlfnUhOz0zvV0W11W0rW7XQ78un2uj0l
wDZ1oOq6WBdThi7RnSF30V1QslSX4mx33Z3iODYnlWNzWug+uh/ODtKDkA/Wg1EeVgyyidPJ06P1
GEqCLRsH/Xg9HnVO0hdRir5YX0LpeqqeipKX6ktR8zQ9DfJl+jLIJq6nhZ6hZ0AD20dJsH2bKCdu
c9xWqgULuBvynjjcYWMHyTGvOlB6vIi3KIUkbqiJkW7DMdJ5HCPdhmOk23KMdHuOkW7HMdJFHCPd
lmOk23OMdDuOkS7iGOk2HCPdkmOkCzhGuhXHSBdyjHRLjpEu4BjpVhwjXcgx0s05RroFx0g35xjp
Fhwj3ZxjpFtw/LP3GHt9oqWuQBAmFtqRJbIEtqNUlsJ2GOucL3vKnrApxkY3YBtdzDa6pNJGj5Kj
UH60HI3yxl7ny7FyLMqfL8fB7hjb3YBtd8kxtvtCeSGs8NEWfKqcesSOT5OXQa6w5pfLGZArbPqV
sOkW2/SG8np5PXzJ0Tb9RnnTMZa9oZwn56GMse+N5UPyIUrh+O0EtuzV2LJXY8tegy17U7bsTeRi
uRieydj0OI7rjpPPyGdQ0kR3J3B0dw22403lm7DgaWzBM9iC58q1sN1p8l35LrzFe/J9yMaOZ8gP
5AeQjR3PYDtel+14PbbjzdiOp8lP5afwHJ/BmqexNa8jv4A1T5MbYc3TYM1hBeRWuZVSOYY8gy17
uvwGNj2NrXkqW/N68nv5PTTGpmfLn2DTE9mmJ7JNr2nhFlEix5zHWx7Lhmwse5LlwLInsmVPYste
nS17Mlv2HLbsiRYSuVYS7Hsi23efVQP2PdFKgX1PhH2vjdxEqvs4Uj3JqmvVg8bY+kSOWo+3GsHi
J3LsenW2+8kcwd6BI9i9TnOnOVnOs86z8AHLneXITQyh47ztvE0NnHecd5B/7HwC6/+Z81mlD2jo
bHA24KrNzmbk25xtyE3MoeSYQ8kxh453ovc6auS93juXMtkr5HtD3hBlecPeRVTf+5j3MciLvU9A
Nt6iAXuLYvYWJUe8xU/sLZof4y0s9hYN3R7uRPJwNKPkaEbJfiKFYxpruKvcVbDUxjfUYN/QhCMb
49zX4SE0+4YUjnJMcN9134XGeIjG7BVS4BU+x7XGKzRlr6DZBzThGMgEd5e7C2dNJGQNjoRMcPe4
e+Ab9rn7kBtPkAsfcADyQXiCOvAEMUrjaMkM9gF12Qc0gw9QkB14glps/XN1vI5HyQSdQLV1ok6C
XA3+oBbHVaazD8jVGbou9CbGMp1jLDPYE9TT2TobJRvDE6SxD2jGUZcZOl/no7aWuiX0JgIzQxfo
ArTbWreG3niIRPYNibpIFyE3vqEmvEJHyCZW0wff0BWyidhMYq9Qnb1CDkds+nRf+AZX99f9UcZ4
iET2EDX1ED0EsonnjNfD9HDII+AzXPYZ2XoMfEYi+4ya+gI9EbKJ9kxin5HMPsOFz5gGvfETORz/
Ga9n6VnQmCjQJI4Crc5RoPEGNVO1uO1x25GbSMgMjoTM4EjIJI6ETIovji+mtPiS+BJKJOF5w/M2
CYqj6uYFqYcCcqS/qX+0f47/g0C3wFh/JDDf/3FgSWBDYE9ABqYERwYn+7cEZ/jz/QP8E/xzAgnQ
TkSpm1CiPOjBX2PDd4ej4eXhd8P7I/UjzSM9IpMjcyP3hNdEnom8HFkf2RtZX1a9rGFZfmRT2bCy
0eFtZRPKpuGaAK5Zh2uGRKZGZkdCkUfw88/IjoqSkZfDn0b2ls0JDQuNDi4OTQhdFJrmL0VfIqE5
oXmhu/yjQ/f584N34MwC037ZwrLHw/vLpkV6lD2L9u8J321aL3sVbb+DHiSV5Zd9XPYF2t5S9rW/
aTAUKg594Z8T+tq/MHQw7A0NCGeGs/2RcDd8+tH+YnziycFngk+GZyJd5x8Qvim4I3B3+LbQx+ER
gQ3hOuFWwWdwDzqi5WXcdml4fzQ7vCbaLtotOhEt96hoN7wc7aZG30W7cdF10Q3RbdGd0T2RNyKh
hz0P62hmdAlKNDT3KzozelN0GUqtjqyPrkHdEjUUB/aX5fsbovwbkbcDdfzT8Hz2BRYFxgbu9i8M
7A9OxXN5y78ysNx/n/8Df8S/AH/PCYzFU2kVuM1/UWAD/v7OPy/QDk9pmX8LSm7ztwnsCc4I9vNf
43/HfzB4R3hJeFnZNeE14VXhT8MbwtsiHtx7jedYGCmKXBWZEXkwsoKf4q4yKquLJ2TuZH7ZgLJe
ZRfhbqdE0suuCO+JPBl5H09+fXhnZFyZwpN/I7IYz3h/eH54daR+WZtI5/Ai3KO7w+WRO8riylIx
AuaV3VV2X9mCSL+ypmhtceQAnlK/yD24ak0kJzIS/bvPv8C/JZAcyAyM4HG5JKTQ9/rBzsGi4BD/
s6FIaGHoqdCzGAHzAstDj5uf0EqMj2tCr4auQF+Wh9eU7YuE8NwXlr1VdrBsZVRGvWUfhCaURcqe
KvsuLINDwoNC74TeMqMgnBC6JjAxnB1uF+4T7oiRXhyYYkZBeEp4Os5tCW0JPolRkh3OxqjIxFy4
z/8s2ioOfYAx+VTou9C+cHI4Nzw2PNG/IDQg2jFaHo1Gk6MJ0dxICGNiUHREdGykR/S2aCB6d3h5
dBHuwITwtugqjIpPo/uj86PzI5OjfaJTcA/6RddFngkH8BxScN/To3XC28LbHk56OCXaKtI5Oj16
XaR5dHlER6dgnJb6e6Gvd6E3C/2P+58KtPN/HHw5ODsgg+/jrvXBWDgQouDcwKdIywOrA++GqmPe
rgsmBceFmmIczMCnuCIY8keCbwTfDnQM7gimB1MC3oA3eE/wQf+w4CPBxcEnMRNW+BcEcoP/DG4K
7gruDR4IHvCPDswMTA9cF7gt1AYjLxIMBa8KxYVScS4n2Ny/JdQwlB/4FLri4D2hUsy3XqEBwcLA
oMCUQDSwKrAmsDOoA6v8X/i/Dq4PZAcCobrBHrA7sECB+Wx9pmAG/g973+PX1nHlO3N17xVcE5dS
1qGUEtelLnEcSl1KqUMIpYQQSgihLKGul7IsP2SvI4RQsawfFEv3l34LSfdKcQghhFCXOtR1eTzq
sg7xI5QQ7BCXUNdLXeq6hI9DXccf6nqp631n5O5n9/P+gffefsL5jMRozsycOefM6Dvnc2dEVp0S
WJlUGF0wao5R0akXSl+ch3UL0/+GKPRy/Owtit9fg+M311DxU7caFEB9iEbD6Puwyr0GlIomgP4u
foJ1W/y86v3oPaA0dBnok/E7YtLR+0CfQh8AZaA/AH0a/RkoM3569AHM4gfQdvwg3gX4ORfnosL4
Oc1H8SP4EVQUP4P5WPzEZTF+Gj+NSvAzuAZ9HX8Hfwc9Hr91pQzrsA49gQ/hQ6gcd+Eu9CR2YB5V
4Nfwa+ipOBKuooqpYvR0HA9Xx/HwM4CHy1ENVUF9A9UCKq5FdRQQaojj4e8AvrWixvgO3wz48G10
BPbzS6gHkN4V5KauAopTAL+9j9T4PjwWR2vHqD9Rt9AL1G0NQi8CnL8fDWs+qclAk5oHAEFNaT6j
+Qx6AxDUTnRWk615CL1J59F56C26kC5Ec3QT3YTepg/SB9E8/V26C52jzbQZvUPb6O+hhfh5rsX4
Sa73mE3mL2gpfq/ERdgiaNAllmET0XL8tojfxs9eXWEz2Az0O/YL7BfQ1fhpqd/Hz0mtsoVsEXqf
LWYfR9fYJ9gKdIN9in0KbbAiK6I/sUPsq+gWe5xdQLfJyR38GXJyB+8gp3LwZ8lJHJxFzuDgz5HT
N3gnu86u48+TmwhwNnuHvYsfJOdo8G4tq92GH9Y+pH0IF2mf1D6JH9M2a5/Dxdp2bTuu0HZqTfgb
2sPaw/gp7RGtBVdpbdoeXK11amX899r/pZ3G39bOaM/hf9C+o13ALdoL2gu4TbuoXcQ67S+1v8YH
ACuuYkOCP8GPDyd8mPAhNiduS9yGjyTuS9yHLYCdNrE18Q6XgHmyE8a9gIJScBh2v9vw87D7TcPH
uAwuA78AaGc77iM7Xvwi7HUfwv1cDleNXwak8Syehl3oPjzH7ef247e5Rq4Rz3PNXDM+R3ae+Dzs
OSX8Dufm3Pga5+fC+ANO4RT8IRfl+vBN7iXuJXybG+Rewf/Gvcodx3/hTnAn8L9zo9yPKcT9hBuj
aHJHAMVyr3OvU1ruTe73VAL3PneNepBb525SD5PTH1TelvwtRdSXtxRvKaaKtpRsKaMeI+c7qNIt
T215hnp8yze3PEtVbPnWlv3U01satjRQ39zSuOUfqVpAJo+CL2OqBnZaBJPsQAxCPvr/TPh+1ay6
VVU9Dq/k/VagPkqp7mhqdLe/X+2LNkESo7Fof/Rk9Gx0Nno+uhhUoQ4PvFAjWBgsjCZEU0kNdQp4
Y9Eh4CyAvCV6k7QdqoneBj5oWZ0K1EOdbtJybJvaBz01qfPR/lh2LC96PrY3Vqyao3djdIyLZcRy
YmVxyaB+rEt1x2zqDLRwKzYQ3Q3v9+qqUHchtgwypcbWYhuxzefR8yxQEqQ0qHcmVhmNkfHEBqDm
GeCaU6eiZ0HKkzCeUqAKNQiSrquDah/IOKqOqqej1TAOt3pVvQZ6uAWle0APU9G6qD4aiq4QeYEm
oYXF6CX1gnoxuqqOqWOgr9RoUbQItNJH8uod9U7UpM5AH/uDRFNm6DU9OqLegBbH1W543RrtiXqj
i+qt6PbozqguKpLegHdQvQz8pMWieDtTqhqriVXG6mPZoIcdsYZYcqw5dhD0bYZRFf/t9VZ0PXaK
6OuepmKRmD92jGgsaoqdgBYmoouxJdDyNGjq+vNsbDg2DNa4RTQDr2ugVf75FBjPVMwAsp2PXXk+
8/nMmCMmxznU2BkoGQjUw/cAQ8/SswjRcwTt0vP0PKLo8/R5pKEX6AX4bqDQY/BKntT7PMqGtT8H
KAPlAn0afRUoE8ofQw+gcvQk2o6eAtqBnkbV6LPoH4A+F797bSdqBfo8OgiUjUxAD6Ie5EC78Al8
Aj1MZVBfQTnUV6m9qIIqpApRJRWgorDSP0+Nwip+kvoJOkSNU+PIQE1QE6gDdvz/gozU69RZ9F2a
pVl0hN5Kb0WW+GljK32EtiIb8wjThL7H6Bk9+j7TwXSg44yJ+S76AXOYOYJ+GL8NaZRxMR70o/it
R6eYMPMS+gkzxoyhKWaN+RC9wb7LvoveZn/B/gLNs++x76Fz7Bq7hs6zH7AfoHe0P9FOoAXtz7Rv
oKX4jvbXCdsTtqPLCd9K+Bb6TXyvuZLYndiNfpsYTAyiK4mjibPod4lzie+gu4kXEi9gOnExcREz
iRcTL2I2cTlxGWtJXBEnJP4+8UOceN8j9z2Ct8GML6Oq4jN+G1gCuVJIwvcrRf7TSp0fKT1KvzKi
jHuM4QzlkrKq3FVpNVstg1QfPhWeUHf4Z1SD2qXafANKkVKq1ClNSo835jEqi8qq/5ayDpx59zhV
Wmny16r+eNur6oDSA3XG/Qh4L0FdaNlzGbgX1DIlBPxLkSpo94q6phSpw+qEekadU5fVTaXIuzVe
n1Z6okmKN5rlvRnNVe4q43+rWxee8KZHVbUrOqhcIlgMkNXp6BTg83ngZAHPGsOnyHgA0cBuSwHM
rmZHd6k5ajP0muGpUnco1dBHt7I/Phqdd6siqtmKl2jCm66cJ/L6uuJ62KtWqg2qTOQNT/iN6kHV
AWOKAQ0pesWk3PRcVDk1WTkJ9Ul+VjnrnlC80Ecx8PXAqOv8t6DuKaUCei1SesIZao1PVm3KOLQw
5E1X65VJZQV49ytDHqRYlNvqNsXipaC9urh8+9UlpV/Ndm+o0+6BKPKuqxH1hHpdPaaeUjeUleiU
2uXJ8o9FUxSvOhzNVTOi+cokINVD0VaiKdWm2gA1un3FnirvTXVanfYYYRdaGK2NVoH2ypVS6Cmm
ZnuyPFm+TdDpFOxv0qKZyizIURTlFS+MegH8h4KZvfDRXP6/O5fZ5gQzmcv4FDoAYLzso/T/dqLq
hT2SMSSHToVROEUoCu9yRaT5cGPYGFoQVsLHQ5tCQWhY2BPqinMtuSLhNOBChCNsDi2EU1zHImcj
i+4LkbvKjsh5pVipUQ56RKXL3edjlYhyQol4xr3ZyhLk1pTryoayqSKoMxlZjKxCnTLgbwbuFKUL
uAfucfrYyKpyxn1Dyu9NDU1IfGSnKyLclBqFoshuoc4VieyJFAgj4RnJGCki/au5nvHIXRUpxb4k
pcYjuo6R3tV8JeJLAwm2KUtqoWtZ2XAPqiXCnmBhJF1MDsmRpkC2fzJiknJ7KVEWinpTw7ugRRFG
vBkJhTMjAEki/ZEhlz8yEjkZGZfGhIJwo5QrypGQUCQUQM/nSd9qK/R9SEl2zxP85+4DHcT7jSxC
v4DPlA110JMAqGhKnfGswyeAwXxpaqOyFFmE8YK+VDfUWVIHlSUloo4JRaEFaIENG5UlYY8iEwot
hRxyQfBCeBdoPCd8KGwkdgmdCA2HT4cioVNgkzHIy+EUsNxGOF8yhhshPx2SxWVXpLcOuOfCrcIe
KB0OD8oj8nlpLDwTmY2cV1MiK5FLYIt1z06FVo7BhmCHkqPkKQ1Kvfuq4ohbcViZUPJUlmgS6Ap8
BlZ0ZyoZalLkdmRd8YPlI5GbSqVHryQrcmRRRZG7oJ9FxQb8ez3blWXI3VUMyrQyB3XT1Ew1S90F
o15QbK4N5ZRnXCn2iFBrRcl275JHYEwRkHk5dCWcRPxSmgfdG2Vd4HqIk2BkwcxIacgQqfDPCnWh
Y/A/pEi1UBS8HKkLXwNZFmFUkNRCNde1oZa7+9yjapVnReJdx5RitSSilxojpvCF0CniBRFTxBK8
AXbt6U2VQ/d8IO4F3nCmVB7ZD2QidhflcGYvFeoC6YbBF9Oh/iZw6SI6Uhq+FhFDESlXNfoy1RS1
1j1GvAJ8otuzqvLQK0HKfcQrlE2gDfW4J0GZU+c96551pYb4Duij2JPg7otMqoWg3Qj41j6YMRvg
G5fVcqAglO+G+pzqloyuSMgAs9IfigSyA9mhAWLpYGFoAGblZdAamc8j4TvhqfA+oMJwebgW8o3h
Wt9MeFROBe8AEkagxrHwRVEObYZvhN1h3nfNd03qC8+HbFJfsNA/K9rCF6D16+Gr4WvhW4HNUEMw
E3wnk8zIcJa8E2ZCUbA7QoE+E4QRqTwchPmyNZIargpcj6RLfb2pULpdyg2rYTZ4EfyzJFwlp4e7
wW8nQmfE5dBaOBdWlT5IIDHMQFh9pHLQK6w6MEKZjC4UAY9YCA33pvrS4Bu+Hp/EJxHCY3gMYTyB
JxCFJ/Ek0uA38BuIxm/iNxGD38JvIRafw+eQFr+L30UJ+D38HkrEv8K/QhxewStoCyVSIkqiZEpG
92lyNDloq2ZJs4Q+prmouYiSNZc0l9DHNcuaZZSiuay5jD6hWdGsoFTNFc0V9Heaq5qraJtmVbOK
7qdfoF9AafSL9Ivok/RL9EsonX6Zfhl9in6FfgVl0K/Sr6JP0z+gf4Ay6R/SP0QP0D+mf4y20+/R
76HP0L+kf4l20L+if4U+S/8r/a8oi/41/Wv0Ofo39G/QTvoqfRV9nl6lV1E2vUavoQfpP9B/QLvo
P9J/RA/RH9Ifot30n+k/o4fpv9J/RTkMx3DoC0wSk4Ryma3MVvRFJplJRnuYFCYFfYlJZVJRHrON
2Ya+zKQxaSifSWfS0VeYDCYDFTCZTCb6KrOd2Y72MjuYHegRJovJQoXMTmYnepR5kHkQFTEPMQ+h
x5iHmYdRMfMF5gvoa8wXmS+iEuZLzJfQ15kvM19GpUwBU4Ae17q1blSm9Wq96AmtX+tH5dqgNoie
1Ia0YVShVbQKqtRGtYCbtM9rn0dV2he0L6CntS9qX0TV2pe0Q+gZ7bD2x+jZpLeS3kL/lPR20tuo
Oelc0jnUkvRO0juoNendpHdRW9Ivkn6BdB/F/z6K/30U//vvEf9jD7LG/4wGHKFJ0jzoLfJWiKm2
cq/ea7Gne0O2cme1s9p70jsppnsXvavw/01+2ntb3uW966NlvjvHWypMeWPOVCgZclYD1yw/DZ8s
SrJvm5zmyxZgx+m/7Ktx3PA1uIoC2wMFllhAH/AGYvJgYDawGrgZuBukg9v8o75soBpfsa84kOoq
8h0E7iLg3e8Y9BVbQj7ZVxOICVWBGCFLSMrrTSH/9Wb58qzLvSm9JYGYS2+ddq33lvdWueqkteCS
3OorkypthcCVGYhZl+13rdO+st4UX7Ld5C0iI7MuO6thDCHfAhmp1OBb8k7yO3xXfGuQ2+Sn7eN8
sY/2XfdteIv4bb45fpt1zn7XtynZfLKrNNhsCbl2Bw9aYvZL3n6Q84T9JH/CEgvago7uNRsCDtnP
Bv3+JFc6kR5oBGTZJ+XJt5yTgZivhkgvrVmXbWogxp+wTve2iumuut5DvcZ78hESd8vINuWs9u8C
6UL3ZBNT7SP+Vn5NbILPD8FizNqQ3+isllWoATW7DWKq96at3J/v2/TXdi/5roh6Se5ecww6BgW3
a9I/E5xwDAYbvKHgtCVm4wN6Oc21EuT87sBdfzC47Lrpuhm8ElxzFciZ4lDwOtRSgxuOG8GG4IKv
Rrpuicmsbf5vYyJW6HbTziJ4d/dmSWAP6UwgZr8N4xkVL8F4xoI5wZze071TwJHWOyPkB2LShv22
S++ctM309vUO2kPWZbnWVwz+cxtsPmtddq1bwEcE3lfsrfZW2HK7aTFVmOpe8+4Xx4HLBN4pdtPE
al6SP28POat9HLGZWGq3EM8U4dUy5G3y6uI+fNZ7FupAztsPtAI6DXqLQEtD4M9eKL8Nvr8u896Q
dwToUrzlOm+Prdy3DWgH+PLeQIWrICD6GnzNvhMBHXhAtX1rkAPfvSgjX46rSKrxT4Gv5wST7beF
oMQFQnKanCm4uxuCHH/CdtF3RqyQ830Z0B54ujzo6wLvqvc1gC5zxVL/Ldd2OSkQC0bsW73VvjI5
KbgpXOjNtYSEi71JvWnWZtDeLvD1fFdTINadLadIzbbLrnXi6fadcq3rZC/y6gIx0EOe96wldC/n
7e8t7GXtel+NfdbZAxZhvXrrFeg9X1rrrRVmApS/EOzQY60h7YPVtoom/y1fhi2XzEf/lL3fV+mr
9F+DUiqQIGcGdoN9Uv3dglu8GVj3z4v7xVRim27aPu6sFubFCt+yHzmrXaX2BBjJpeAxf1/QYRt1
3CAJZsNAsMufEjT40/yZ1mWhyr6VpN5WWA8Oybt6G3vNIHMR+PlG8CB4Wh6ZCST3H3MBrLJuHwGv
L4FUJe+Sd/kbrVDqLycW8xd6S/1m0QL+vtPf7ef9Wf5cMlv8+7wmx2AgNaAPDrsmySzwB10n7Sft
6/5r/muwUuzz7Q2e8Kv+UbDgvCUmbvf3+QeDp4JngnNW2rVq74fZWkaS3B3390wBZqx0xp4urUlr
Lq+/Wzoh33BOyq29rb28dVlcdIz2zov9vcFe1X6p97gl1J3tPy6X2+ah/Sn/jH/Ga/JVyinBDJ/f
V+Mq8Bl8tsAe8XywOLjDd0w+1F0W6A8MBUZA5vHAbVfM3u+/4BuwpfiG/ad9045Bux7q5gTSYc3x
A5GSPF9e4GxgElbOBt+E75T/jtzNN/jHnFsF1THo3Aojnglslats+cG84F6hPJgdqLbdCtQFmuw9
lpglBqtBWbDS4rWdDpwPLPocdlOwJlhv3+n1CkZYBbptvGPQZQk2BC6BtNmgi52B0oDFW+HVB04G
Vv1X/Td8EVu+IxgwuUoDK76GQA9YIxiIxSOGE/RP4VvmPcCH5P6GrYDyElE20CfjEcP0eKzwU+hJ
oIx4rPDT8VhhZjxWuD0eK/xMPEq4Ax1FHvRZ5EMKykFRQJxfAbz5ffQoGkU/QkXoDFAx4M1Z9LU4
4vx6/BdKStE7aAE9HkefT8TRZ3kcfT4Zv+u4AtN4K6rEyYA1n8W7AGu2xVGmLo4vD+BvAL48GMeX
/xzHl4fi+FIfx5ftcWRpwE7AlB34BGDKznjU8rvxqGUvVQiYMgyY8huA/56iqtEgVQMIcjiOIF+j
AlQIvUlFqCh6Kx7TPBePaf4uHtN8Px7NXKOmqBn0ATULKPMmoMwr6BbBlziJ4Et8H3WNuoY/Bijz
Q5xMbVB/wZ+g/qpB+FOAL+/DD2g+prkfP0RQJs4jKBMXEHyJv6p5UPMQLtQsaBbwYyROiotJnBR/
jSBOXEIQJ/46QZy4lCBO/DjBmrgMsKYNP0F30924nNy2ip9kHmEexxXME0wl/numiqnF32bqmCbc
RKKruJ3EVbGBxFWxkcRV8XfJr0TgLibMHMOHmX7mJfw9ElfFR5k15hp2MOvMH7DA/JH5M5YAxd7F
QRaxFFZAQBbH2AQ2Cb9AUCweICgWv0xuCsWDBMXiV9g97B48RO72xK+S+zzxMFvKPo5/QH79Cf+Q
rWSfwa+x32S/iX/CPss+i8fYZrYZ/w+Ca/E4+wo7hP8nufcS/5T9ATuBf8aeZl/Hb7NvsD/H77Jv
se/hi3GM+3tyCz9eBXS7jtfiuPYDcsM+XgdEex/+g/bjgGv/FEe0fwFE24rvaHXaA/jftf+sbaew
tkNro1hydyKVou3R9lCf0PJamUol8WLqk9qfaV+nHtC+of05laV9S/sL6iHtknaJytde1P6a+gog
2qvUo+S5R6qExJSpr5OYMlVKYsrU4wTpUmUE6VJPEKRLlROkSz1JYs1UBYk1U98gsWaqMvFHiT+m
niJPLVLVieOJk9Qzia8nTlH15ElFal/idOIM9W3yLDvVkHgu8Rz1ncR3Et+hGklUmvpHEpWmmkhU
mvonEpWmmhPfT7xGtSSuJ96gDgCq/hOlJ88iUkbyPDrVSZ5Epw6Ta+MpM6fhaOoIef6QsnIJHEfZ
uE9wn6C+RzA31UMwN3WUYG7KQTA35eQe4nIonsvl8iiZnG6hfOQpQaqXe5QroULkyUAqxj3BlVPP
k2cCqRe4Sq6K6iNPA1IvEVxODRBcTr1McDk1SHA59QrXzhmpIc7EmanjnIVzUK9xPCdT44DRPdTP
OB/np/6F6+VU6nUuxr1AvQno/FXqLe44IPJzgMh/Sv2S+xkg8stxRL7CvcG9Sf2W+zm3QK1yFwCR
3wBE/ojm41se3VKk+RQg8jLNp8lt+5oscr+i5nP3PXLfo7Czw8iLIv+JuZ8LxtN98d+q2gXrYD6s
YKWoEtWgfagRdtt6RB09KZYgzdERIUMsh9ygpRle+8RK+EwVEsS9kPOL1ZCT+U14p57be7QHaZ7L
O2rh16HMKGZD2SH+sgg9Hm0W7kCugV8Q0//Lqozjt4AjhOkFej0uXSa5w/HQzf+aqHrjrKNM2DAY
nClHt9vmjmSIhe2Tllrx1pEMYUOqluqEjfZV46zIEi5xn61eVG1z4oylVkqQUoH7uNwsG2RZjsgT
8rK85mJdWa5CV7mr1mV28a4+12nXRddV1y035U5wb3fvdO9273EXQJ2DUOeYPOFKAf584G517QPu
4/c4Xbx8zHXBXWEdkU4emZbGj1Y4R60F0qRtrueadFaatZil80eWJL3klRbj/UPP8oS7wMW6TdBe
udxMenf3uPrcXtdpeQnajLn7oe8h94hx1t59+I5QL2w4Dor50m2xUBrpMVtHbHN295EMR1nHDIy7
Tt5rq5TL5Eq55uhZa1FHn9xgrbMld/RZauVkOcPuts3ZuqBnB+nbfQn6XpEX3Lc9tLsCemb/1q/s
pjwRz4B7tyfDM+GZ8yx4ljzLnmH5imdN7nIverpk2XWL6Muz11PjsXlOefyuPs8xY4G02zXo3iqC
LoQN0IvbFRT3iWnWrWJt10HxuHhBvCHekfa3rx6ZtoxKTXzIYADNXG5fBQv1SVtFo3hZTLHUWsxH
usTM9gqx0LAJJVXiVWFTotpXpQrbspWyXJb0sg1GcB0s4QdbDMjD8rSrT54DbW7Im65c1y6wY3fc
iqOuGdcNd1Fck5RrnzsdUoG8AGMulU+5jC5Vvg41T7gyXfPyAsg7BqUToB/Z1Qj8CEabCrkzrhLX
Zdc18IBqd517v7sJNHXH1eg65JoCH0lyVUEtWb7iSrMt86GOOyBz49Fq0U38sn3y6KJ4S9pja7aM
CRvGkHRJunS0QFrhF6WzNoMlk6Qjy+CZufYS5yjI8rc/dwzsI7rH3Rb3pPusOySNu3VuvfukdFeu
t7vNI9KqtC7mt9cJE47knhJ5x9GTDv89HxA2elrlHHFULrYkWZJkWhoxXAEvqewxiywfMoZsc4fv
mEfkPKlOutlxUebkbZY+Obvjjq3YfddzxXPQfR40tioveDjPNrD/DleSp97T7CkjXgEa2OMZ9sie
M55pl9vT4GlwZXmSPdmeMuCa8BTLB2EEC+BFs+5Zzwnwn2HPdfe6+6Ynz1PpMXgc8pwnR0S2Sltl
xx0xS9wl5gt51mpiacugbUks7JLFoNgtjvKL7UOSzpZsTrAlO4b180cXLbXGEf1VqdpqaV91XjWG
jPvt3bY5qcc6Iprbb0o7pe3CKeGUdb9kEpP4FcliOOjwi9egl0OSKPgNXXw6v2ivsuSKp8UxcUqc
BynmoL73yFJXRApZxztUqQDmT3/HccliLj18x7rf7oZZOiSNSEUiLw6Ko4Yuy0XxmpR+eJdlUCw3
5Iit4kUpJpWKJWQFOpJBVh8yA8mqY6sUNqDvfDHXtgwlXrvb7YWVjSY/RYgQQzGwyjHwhyhGy2iR
5qM45kdxzI/imP894pgJk4nb46jlLHoYoebC/9+S5o7xdqfDMKArcUwb9YYBQ17ropNtXzE0dx50
Zpr1xlJnvu6OPre9unWPaZ+T16V0JnfccBxzDDtOGOodC23bHJtOZGg+YDI0m/XOEmdre7Wz25ll
qG/Vmw4Zxbb6Axaj/vC8sNc6+ZzNeaMtp3POuGq83ZIlHHP2tZ3qLBOWjOPPNXeMGYeEMqOXv9lt
EugDlgMWx7J1Etb+Sec1UufwLah3V5CNq8Jc+yy0t2QdEmoEW0smn95W39Fn7LGrRyqN3jbHgQJL
lpTauSZtl/boGnXmzuuSzmTuzO64YUhuye3kTGkdvLUJvhMu8Df1g+KNtmHAiFuBG75VpIrDl6We
jhtSv1SgH5SadBdNKUQ/bZtG0TENLeSZ97cutq/AZ6Ad/ahZ31FlLD2M2qtNvH5el2K2WG9Dma37
vH7Qvu+563xBW4bzcueCUNmSaYzxFUINX925JmaBTvrF3LZ6vq4ly5Qi5rcE+ZumzJagWMJvF8v5
/aYsMiZppyX/SKW16UBBp8OS1bnWVk9GZDTpzMaizuvtBR03dK2GYVOa9bZhgEhJ5OR7HNOGCdDn
oK6k43jnQZA4LqNhoL3avN5u0qXw5w017d72kOFEd79hQ4f4FXuwbbPDbBjQ5xLbdxw3zPHj/CI/
adab9pkOtQSN/YfTxFaj3lTevlU/aNrX2mQPtupbsgCvHWurNx0SyvhV41AnbUg2dZu6bRMmt3FF
nDGpLVmH0/j1lszOMmL51qZWfeeCeNpoacl6rrmtrK2+zUHGKC0eqbRxpiBoEGSW9hwouDc+I9ih
JdfQYEpr329XLactp59b6LR1dAOCudB2XdppA47ObGJrXQnUMcoc6MPcknt43qxv3dOSZRzXmQ3J
zkPCsuRtSeuodeZ21JrM4mmT2Xn68LxVBK9f7qwBj693DOtKdJnOQrDxsmHAsWbeTWzsTCP+7yy3
DTgbO1hiY6fRsNA+S/y/g4XX7tYKx4QzyZnUtaC7ahhw5pO8Y8M87qx6rtmZC5Z3O+YcA45TB0xO
8+E0Y1HrHuNtx5KTddYacjqTHdcNOww7OmnnPkNe+0pLrm7MccUEMhhFXaOpUNco+J2jzlHDhHCi
LefwDWO/YBMifHpnjbAM2BJmipDHi50DzkE9a99ntAh7BYdzUNh0qjpeZIUMPkHoEtaE5g7VmSQk
Cwu8aBwRdjhvCQedfR2FQpnzojHWdoLfye82nj183CgesMBsu9xZY6b4u8IV62QbIDewUrNurO1Y
5wnxQpuDrxZn2jZhxlwWr7YYrZMtmSIy7BDvWEeMZzvXuvUS2E2q7siSLLox4ptSqO2gIZnMtY7C
tnrjkHjNcUba7UyRipy72hyApCDfkdLulfaLjeAVPdKQkCEkixctRilmDRnHW3Vt9YCl02H/ZIJW
VmCP5ZfGJUoSLUZjnVQnnoZ5sSaNiDM61LnDkNzW7Owj64YRyNnn7BPKWm4YzxpnjSPGm7BOZAmn
WjKdp52nhWVdVfui7jSsNzlmWPGID3TWmPi2TUM9X8Tv0fF8qa2sc6Et0jrSuWasM+WKhWJ+22br
CEkwP6sEB9/kWON1Yq3zBq8Xd4G/9ogzJOlapZ3GOuOIpap1SJrsnDDeNuRZb4uZsAoWkDlKcuZS
w4axFGaqxTDBi7oSc2kHsoqGvI7LHcf5Ef6k09i6v3W/yWy/ZqgxgGeaF/mh1kU+1HKL7zcs8Jc6
DzqGj9AdrFnPm4Bm+bOmlCPcc828F2YuzPb2aqPIx8TutnrhmNgo7DWVi2aYx426RtFtFE2tnQs6
M+zORsFj9uqQONZJG8eNongIHI8HPD4o9olTusH/zd7XQLWRXWlWlUpAy4QQhzg0cdzETdM0odVq
TBshFBrzZ2LLMqZpkIQQQqhKGAupjJGQ6h8s04TxMBwv6/V4CSEOS1jGIYQhHsdxWJZlGA9hCCGE
JoQQQtM0IT4elvg4xGE9+97rmfb+nO3dM+fMnuwen3dK4pZeVb13733vfvfzq+fgYbEBeJWaSmix
hEovGep7oWd6o+ihD8cxmNvZlqvMMhijsa60d+7xqneWwIy5WpPDT5zVNrR5raL8zpN3rpwPnQ81
uM9bhKteK33tAv/OLpvQIjbsf2fnnfut0ecHW+YubJ7XA88Zf2emlWyIdanFUjAXdMAxze2Aux96
ZwPFkNJLqnrQIm+UN6q+BXoxc7jm0KVi5LUTjXuhqIuW80cvMcDSHRfWLvSF4i9ku4YvTVy63ZBM
9Z9tuDR7cezi2KXRi5MXpy89qI+p761JDrW0RAIfSKG76wdC9wNF9d31MnOY9lzcC92/sAB9CP5W
o7/YX6Nnjc2bzZtg1h+pj6vZO8syB0FubvJqW/bXO+A4pkA0uHDbG3XJ1hJ7YfbCMogReQwJxg6I
ZdTiBVVNJJUA5nrM+wT8+oDqADHNH4qpGamPuvDYNcxd8c43dNRfYx43YA1htOMCT3vOsv7H9feZ
0Ut9F5JcwzUYPXSh51L2JQNvo8frZy71nGUvNF/sAK0cvNjVfDNEgMjIX7oJ8qJZ4OMPLxlCLaHd
s2AkNC9fSrqkBmNi/dKBi3P1t0It543M4/oskHFE48v4Mobhv8R/ieGKTcUmRpDfIocwBfmX5F9h
4eQdchKLJH9MzmPPk78i38M+T26Rv8Hiyd+Sj7DD5B/IPSwR5ThJSlCwV5TpynQsWalT6rAvhg+H
D2Mp4BnX/oXW6XZhyShLOg5ypG+Dq2GWZEAM/ClsEruHGVGudAYx8MWIgX8L5U1vo7ypFOVNZShv
MmG/BnmTGeVNVpQ3VYC86QXMhjImDmVMAsqYRJQxSShjklHG1IQyposoYwqhjKkFZUzvoIypFWVM
X0EZUxvKmP4EsfTtiKXvQCz9TUIPsqFBlA39EK0wfg+x8fchG48TkI3Hw+AKYzwccvJ4BPEfiB/i
+yAbj8eCLOkDXI14+FTiPnEfP4LY+DTitwoMT4f5EZ6PGPhyxMBXwvwItyMevgrmR7gT8fA1iIc/
i3j4WsTDn0M8vBvx8HWIh/eQDaQf94KMScbr4TpmnENM+zfgOma8F/Ht/w7x7d9EfPsAXMeM/wVc
x4wPwnXM+LcR335XuRkWif8AcelriEt/D2ZS+Dpi1N9HjPpG2OthR/APYD6Fb4Vlhp3BfwP5c4KA
/DmhgPw5QYa5wlyEEmZVRFjYN8J+SoTDHIrQwRyKyIRsOaGHbDmRBbMn4hjMnogcmD0R+TB7Igpg
9kSUweyJMIHsqZUwIz5cDP9++C+IEMyAiG8ixnsQMd7fRoz3EGK8v4MY72HEeP8lYrxHEOP9XcR4
30KM91/B1dXEbbi6mvgJ4rF/hnjsJcRj/xzx2MtwdTXxi+feV+0jVkAO9WmFEuZQikiYQyk+AXMo
RRTMoRSfhDmUIhrkUEWKT8HsSZEBsyfFmzB7UmTD7ElxDGZPihyYPSlyQfa0o8gDOU6WYgpkN1WK
dxEP/HsMx7V419Ocpaz1/7njYznr2j3OgClqH1XfBt9E7YPqIfC5yRWBc2vVvRyY92qXuBIgzXOF
3i4gTaP6k5wO1R/lUoB0u5rl4oA0dO42kAa4Q176/9J8+REfrnwQFv30Dbm31/7Hg3ifP8R2myPY
Ab7QXsxfZZcqx9n77BL75OzjukBlg5AopApaekGooWKEIWFcmBHGnXP8IT4ZXDPEDvGF7GrleOV4
XYCfY59w0VySqZ9/JMTQC+zdcxtCjcBSMeA+42yvpJdKJLckSl1Sl6iT5qR1IHVJ63KMHC+55SLZ
IXtkWW6RE8Fvc3K33CsPgGuMoFYI1FsE9UGRCXBoQX1ZviwngitDQB6vZLlhblhkuNui311rjuBG
uQm6WOS5KXet2MzNgha2mCMqGyrHaac5TmzlFsR2blnshG2SN+QdqQs8a07eBU/okgphi5pI8Nx1
uUgalFuaopsOyN1NB5sO84e4h+KE48q5eb5QXODd/KS4JtaKD/jJygZzhJBojqCHhXHusTDjrpVi
6Ql6QjokxYKSLE5IRx1X2FU+QC9ADZeBa9hVdy2P8VvCEB8GWkKjtmxIXU0FUr8012RrYuQYoIsP
2+EG7ehpGgZ6AfppGgVlomkKlKSm5aY1eaOpXd6VZajTJgb83i4nNl0HepqzF1c2UDHg6kShRm7h
Y4HOEuWUyvFzG2wvLNCK/J692F5cpxFS2F1OxdXWBYR4tpfOFmo4HbD4apDmQ8J9dqgu4FbxJfzV
ygZ2SJhnBzgGeEIh+wTUb6hN5gyUg9fTC+DcIDi7w08Dz8kSxtl5zs+PcJ3cda6H6wPPHAL9X6IX
OKBNwQM8bck5J9wyjfAd/B2RlOwSLd+VAsjqbVKHdEPO+kePmZS2pS1gqTg5XtbKebJVZuVb0D5y
C+wf8JchaUS6AzR2FWgsFVzhBn+tAJ30g19PAAt3STlSvbQnX5GmJYt8TSoEZx7JNXIDuPaePCPP
y0vAC2Q5Qo6SS2UPuBP0i4A0Js2xvaYRdgB5fAlPM9vMNn+D3eDHKse5A5QWeP+WoBV19uv260IN
OMsCb7jrnAM+eV3s4ybEYfE2mPaBB5qHxB7xJvC/UXDlmpjNbQJt3uceiDz0aikg7wKLRsv3m1RN
avlJU5rskNbNEfIqsOlhflJKqAuIU+JB6HvA89b4SHGTn+QnzRHiQ+h7UpgUKczU9UOfY5fEWVDW
oKeBK2OBl+7nkyUNsM+W44o4JcxI+0GPBsRlcRnWER9LGE+XPQBPmm1qbspu0jUVNBmAF9qanE21
aEwmNvmRH/Y13QTjoROeAx7IN/HSOvRWKINaMZKxaUEaATbaaMoG9W43bYJS3GRCntna1A48nOET
zBFnDfxR3shbwDiq5wP8NK0Tk4RdOErBOFVxBzmSXaK0cB4qWwAz0ROuQLByasEqaIUTQqmYDeaY
cfaeUOo1AQ9sEe5xzaIB+BLwJ67YPMA5+RzuphjN02ISD2YgfrGyoXq5epkzcTbYb3ZAuHL24NmD
wmVGA72Qa+daLcWWYlFVruE14oHKBqClg+JhXgStiRbVlatimrOtkrUcFCIEQogS4sRiXs9vizpQ
suk0MD9eE7q5NH6RX6SzRRPHCzu1saIN2EYnOsVaAY63IfYWv8KvCylCnlAkOARZ2OC7+H4uG/R/
UkgUC4QBtpsdsBdb1P80B4O6YP4FfjUkzMCZF43YQp4GWrNXjgOvnKFi+DZzhLSO3l79G/JvMIz8
W/JvMZz8IflDEFv+jvw7EFt+RP4Ivb3qxi5icLd0iHrjEOo9iFDvCwj1xiPU+wWEehMQ6n0Jod5E
hHqTEOp9BaHeZIR6v4hQbwpCva8h1KtBqPd1hHqNCPUWIdR7BqHeYoR630KotwSh3lKEessQ6jUj
1GtBqLccoV4rQr0VCPXa0L8TVBFfAkjXgZCuSPwn4ofYVbSm5GsQxWLfhSgW+x5EsdgdiGKx70MU
i40iln8asfxriOXfQCz/B4jl30Qs/28gisX+HnH924jr/8+I699BXP9vEdf/EHH9j0ielLHfKXfC
IrE9hEE/izBoLMKgzyMMGocw6OcQBj2IMOgLCIPGozUc6WgNhxat4ciAGBTXoZUcmQCDzuJ6xOnX
Ik7/HOL03YjTr0Ocvgdx+l7E6TOI0z+POP16xOn7EKfvR5z+O4jTb4WoFP9K+Hj4L/BBxMhPIUb+
x4iRn0OM/E8QIz//3I5qH/5TiCDxv0cs/CPEwv8OsfC7iIX/PWLhH0MEif8BIkjiRbRe4RW0XiEZ
rVf4IlqvkAIRJPEqRJCEGiJIYgQiSOI/Itb7PYBKrmF3nmKTUwX/0/GxCK3sevAopijrDOqDOUC6
HEwDny3Bw+CcHEwKqoEUsISAVB+MCwJMVFZLjQPJGYwMJgDJGtgFUmngSRCMijJjYBtIhYHtwN7/
0Sj6CF9FxEQkoz7EYcDNDM3/dCj2zq2Z05w1ga3qsWBiMDWY5ZkIeoINQTl4LdgbnHHNBOfdYZYu
qtgSS00E7rBq+6DlRmAsMBdYCWwHo+g7nqlgTVCuCJTHBWeCS6yKKmYPBwfAbzvFVmq2ask0RLWy
zYKzfJV6wC6wm644R599xGpjnazhdJF50xiANeh1ekvIPs0Kh6nrdowtNg0J2eWr7Cz1wH2j/L7F
bS85nUUnC7dpi7AWvMd2mh+c7madQl95EWuwmiTC3GnuKyLN7edN59bs25LVNWPJkWR7f/WidFe6
V7RATfGXqVkLLe1UpUi7xjvio/NJUgRlEJyVt6UiqRTUbpA8Uq80IJj4y6xBukwZyouc2vI4qJ+g
zJVUj1luBLO4eqCfhsA01A41G5zhQq4ZuoQq5tq4q6ya6+JunFvjLJy76CEnch3cSHkWN2auFfXn
TWYTNynmmGvtg/aV6hw2WyxxFXHTVptd5NZdVlHjcoB6Fu6oaOfmXDWoT6A3RaTxDuiRaN92zYBz
oEemu9WLXIl01zLHX7YkVDVUpbhagvfOrVnCYDt5onqMjwjGFaecCfBZoJVZH7bRWUMVO7P4W6ya
vxds4Ff5jfOH+fsW7LyJ3z0TsJTw18DdujwT/BO+iOX57uAJfig4QxUUWwVVxf6yDjFAtVY9oaZc
QIuuLHtkeZbVVnGIdVYtnbEI2UI0vcVkla+6lsRt10ZVqWXujMa1Y9kq7xUOnNGYN6HlXb2uofJV
cYUrsdqsKssNq8nshH2UdUWknC2lVG24LpfHSfK5tQ/7Z+7kL8trxTFVKfLDJqxpf1NslYO2W7aq
dpoSyudPs4Ftcyc1BW0tt8t98pT8WF6uXixaY5tdO+zBM9P0mHRNus9GC5vSEtVqORQcD96TPEyK
6xo7y3YGFi1h1XfKd4HnbwceWcKsa8B7wfgDI0AbdEAbB7uh/wdXgxssyWZDG7PR9BibxKYBP4gP
xpvmA3tBItgSvBwcCt4qvR38UC4NFgXvgzuN00dZXTAqMBlYrwiwByxdrruWWOA3MWB07RbH2QeD
J0zzpnlnVvBJMC/IsrryXdN81Q41S82yBYIO+P8o28w2U5vCLLvJYWy20CdMcIfokPCgaFaMBCPF
5j5EP2Jruf1crDNRcArDbK24nzVZ1sUEIdtNCz3CY3aBrhcWhDRhTdSYVUIBuwyKoahdyGZvU62m
+6d3zmCcnsuhZk3ANuyEGTxJSBIeslPsA/GQiFkZy1VLvYuw2M3OYjjGOimDFGOuZbPBuEqUUs+b
JG3ZUeqha0ZqkS6Dc0MmVpq36KFvSquSJ7gjeYx3pBQpxZUoxQUjJDZ4RboSvFtMSN1IPhG0SuNS
CpMi3ZKeCE5xT4pyJ0sb5gPl844DwN/jJYfYT+ulXVl1pkOOlg9IedSUO9ly1NkgzUhZUo1Mmjur
ds70W3krwzrtI64sZ+KZjnOP2VEhm3pIPbSvc2H0IdZmtXlDVTUeg3tO2KQny3cthVSrdzsIxgX0
gfJdrg3MfjP0Iy5QtsjdcRww17o8Lg8Yq9OuhsAKt24lzcPwAOOTFoa5RcHArYhudoFbF43Vi1Az
sFgSzO3l9ysind1lXbJaPkw1c3auXyyUD3JGOYkzcjQ3GGQtGJgpHnHbfBQfwyfyqWemeW0wj/fw
Ms/yLfwV8NRB/i4/wM/wS/wOF+AbwLhM4U/wDt7Kz/OlgTngl/FgXG9xe/w4q7ZgAsnH8fHBUr4m
MM33BuP4PPGq6z43ZsoS68WQ2CZ2UQYwV/SK/a5b4h3HYXFMnASjNlucE6fFddd8+aq5RxTFG+yU
OCIOilt8nr2Duu5M9G4DvbnddnGR3gIeedDVIna4ul0DFo3r7pkOj002VY+V75ZH8PFygWyQbXKt
zMh+KctVI4/KN+UJ4AO7wHab8kJTmLWn6ZA8LN+2b8tOmZevS1lNkXLn+STgNSnVi3IaKA+qUixb
TcnUdblYbpV76nrlWSlRbqY6y1fLVwU1dZsapaac9yzr0IstR621rMFsYw2lB4u17GMuUrgutAs3
nTWntfQed7S8F8w+y55sh85or6oR1tjrbE+dlu1jbwIPWKday6PEWDHZu11a7Cxi8s494Aor9ltt
tL48i10TWk+3cAnsKPyN9bMMy9N3uGT3DXqEbbfE0otvP6kOCLzAW7ZdEVSPs8EVdfqJ4zAtnukQ
msWj1OEiVfWgs8a6Zp6gjXQhXULbqU4w69lc8eba0iRXYvmJM8n0tPsq1epKPaN3RdGhssWyDst2
xSFXvEvryqLnKg7ZB9lWOpY+KtwsUlnctGhJLh0VGMHPaU6PU4+FKVcKvcgaQBRtFmrZCfah0MmC
mOoNCWueTmDZMDFWOAzO24CdiwWTYGBn62rYYdbpdnOhikNcCUAHCvIfyH/AAIxQkhiufE75HDj3
jMN+xmE/47D/yDhsrAOMnI/Qe/bER8fHZh4lG75STFGy+tYK+CZKFt0g8y6Z85WAc9NvTfkKgTRR
vgWk0bfu+ooxwhPwFWEKT72vCNXv92nAbzfe6vHFAum6uRtInW9d8R3+X84cH2UbihpF6Onq5uyY
//bAeysZw3jZI3egzOgecY+5px3FJ0N1RF1UXWJdap213Fpnrew0JptWT/WZi92FdXdL9EZNJeO2
g2vEMqOl0FF8orMu6kyYsb/OWlfzYc26VLdYJ/ssvnrfoD/CH+NP9Gv9eb6Arx5J8f4Tfoe/wTfp
G/Pf9VnKJmEb6qI8a2VGo8Y97cUcxXWE2wJbYLbVWb37y63mNdOqN9abUHfXm+wFz/dseh7nNXsj
vYe8OT5344HGg42HGw/4OvzzjUk+sVFdyZzqhPc8Nlpm9F519+ffyQ/zTtcluqc/vF/ZI9Nq2TST
V3e3sbmOYDyN7c4hhj3V7txgWvLDGguYRCbOmAx14V3xqJgU93Sjv85qmm/sbLze2GPmzZ3+CM9a
Y59vsFyuGwB9vunLqSv1jbnpU51lhadbfJhbdIdOdRYxdVZ3v3vEd6hs2r0N+1WXAvXqK6xryG2p
m4H9Mq1ajHW36sZB3wfdgwaHL9Ld4Uu4MOPT+I6eKADXt7k73OvuFZ/R3e/LMU8YNWXGhse+sDNh
plVjcvmJU31uiy/2ZMhXkt9fondPGxwGR9l0ZWdprWnGqDndYnC8DW1h8dHQHsAiWr/VP++z+wd8
V/2X/dd8V32if8lf5L/lT/Ht+Vf9u/4njWSjCtoP2CvCb/W1+bN8+33JPr37qnvLZwf3CYFzBDji
/DW+ad9cHdDo6RZ4eGPdI3VWS8gbdpI+Wfh2L7QKsEiae8Tc2agzR3seeI96lj0PvfrG4lPtwJ6h
xuxGg7vfs+kdy7d4J0trvXuNtUwEtFCJvkTfyDcyja1MDSN7w7xhjmJgA1Oj8wJbRzTa3HagnUFg
0ZA3ZLTU3T3Vzlzx9lvuuNe9j9wWJtXd/9b1xpv+iMZhX33jbX+Uz+L3+Ev9LOjvFd+ib8W37tsC
/R333/PPNEb7U/3doEdA8t3wdfn6/b3+eN8dv+xv8e/47xun/Rs+N+jLiH/oI8/O8237Qv4Y3yPv
frTqFlfiYBwqlCB8KMOUYRihjFBGoFW3V//l9ozCQqC8irWAosZaQXkNa8Pawb3hm2FvoJieDmL6
JKYFcf0eeBqM6ToU0zPRe2Bfwklcib2J9p46hmJrDoqtNrT3lJ3IIt7EqohjxDGsmsglcjEnkU8U
YBTxZeLLmIswEAashnibeBs7S5QRZVgtisLnUBRuQO91taH3utrRXlV/ht7u6kB7Vf0rYoKYwP4N
8S7xLnYN7f7+54iJu46YuH+L9n3vIh4SD7GvEr8jfod1I67ta2iHqx60w9XX0Q5XN9AOV9+A72Zh
fWifq2+ifa5+hPa5mkX7XP0Y7XP1E7TP1QLa5+pdtM/VEtrn6udon6tN5abyIfZr5SPlI+yRclf5
e+x3yj3lE+z3YXgYju2Bx5LYfwlThUViT1C0xUGcTcUJ9PYVGfZm2JvA6AVhBXhY2MkwAx4eZgSR
9znE3H0CMXdRiLn7JGLuokHM/Qb+KfT21X64sxYeA3fWwj8Dd9bCD8CdtfDPwp218NhwT7gHfz6c
Ca/H48J94X788+GB8AD+QjgXzuHx4U3hzfgXYOTFXwSRdxx/Jfyvw/8afz18JnwGTw3/cfiP8SPh
Pwn/CZ4W/tPwBfwNGJHxdBiRcS2MyHgGjLy4DkZePBNGXlwPIy/+JRh5cRPam8uG9uaqRHtz2dHe
XFVoby4H2pur+rk/PPcHnIH/ywZ+Hr7hhNfDPdHxC6pW1Vdwn+pPVH+KN6o6VZ04q7qquopzqq+q
unFe1aP6Oi6qelW9uKz696q/wJtU31J9Cw+phlXD+CXVd1Xfx1tUP1CN4n+qGlNN4H+m2lBt4J2q
36h+g//rfUf2vYFf3Xds3zH8z/cd3/dl/Pq+k/sM+Ff3Fe8rxr+2z7TPhPfsq9hXgX99X+W+SvwG
2j3sGyAKdmJDT2NhRsR/d3xs/Pa0MFdBPJaZLuYGjM5MJ/isZ/rAOTfTiiQnMwAkG8OCb8JTyvQD
qYhxg2/CU8g0AymHsTEMkHQMjO1pTBHT8L+ZN56+o9QRVoP2PSsA2BzTPjv+GQfea4k9Hp2nzpwt
Lc6gT+7ljuscx5L0dP5c0YNcz8k9U9HJvcw0rzFnRR+Z3+8t0bflrOSLltjspTx17kZpsa5X58jz
588VXMmfO7lXOvthzVxP7oZ+zmvx1oM4ZAGxZ8RLg6MeFCgNgr8XwdHhDTHx3j09DduQQeuelBbn
i7njJ7d0Dj3tTYAtyNGf3MtbNhUVxOSsZIRyLPo2Q8TpFlBfVWzN0RRt6rfKJj0FTAPwMJlp8Q4y
qcxlJoa5Au8I71lMlBbnFRj38jXHdQWXwR3HP7xfnjpn5XhPLqFvY+4y47lxufF5uuIUfUdBqsnD
3DMs5azkqb1GqIvs7jwT6PMgcwtow8rMMPPMEuwRs8SsMhve0Mk9fWTOSulNWLyh0zHguT36HG8y
0E4a1GrpVEFMBu0tLCo4lgT7dcwE9XqML9jNTMvrhP0Cz7JljEG9akcLuvMjvUe9eueGc+OETV9/
cu/kXsZiacHpXkNeRsi4V3pTN5AvlhYDlKcpuFLn0K/kT+sjvQnenGNJJ7dqwd1yx3O7c7v1c5lp
uePAjqI+J3fg+BSwhQXYgIa4wDvpnWNSvXYmwhsAZx6Bz3pGC3oU573j7WeymFLGyjiYGmQ/eN06
vLa04GRJ6e1SQ26c144siUpdlrffe9V7FWhVrc+BR0YI+pF+f21p5lpBd2YP0wCsEsNc094ET+i2
xOaOQ/vBT2ZA36Gfy6CB/wELHdcxQ8d1p2Nyx/Pd+UdNWmghWPRtxi1mPGMsrx2iOJ0D2hH0cZwZ
L3qQvVQ6pR0FGqIzaH2bvi2v1nDtuJrpLZChnXNWCmIKLoMeWrzTqB92UFbA31tMjPcG0kSXt4s5
AZBtCui3xzsGe4QkERaGYAhvm3fbuwXOFuntTJ7XDXrsYaL+0bOhT1/11gNvuJG3DGYmI/4d/Dtg
Yvou/l0wS30P/x5G4D/Af4Ap8HF8HCPxSXwSU+JT+BQWhs/gM1g4PofPYRH4Ar6APYcv4UuYSvGa
4jVsn+JdxbtYpOJnip9hn1D8XPFzLErxC8UvsE8qfqn4JRat+JXiV9inFO8p3sP2K95XvI99WvGB
4gMshuwiu7DPkN1kN3aA7CF7sM+SN8gbWCzZS/Ziz5N9ZB8WR/aT/djnyAFyADtI3iRvYp8nh8lh
7BC5QC5gL5CL5CIWTy6RS9gXyGVyGTtMrpAr2IvkKrmKJZDvk+9jL5EfkB9gieSvyV9jL5MPyAdY
ErlNbmOvkDvkDpZM7pK72BfJJ+QTLAXN4a+iOVyN5vDX0ByuUe5T7sNeV35C+QksVflJ5SexI8pP
KT+FpSk/rfw09obyM8rPYEeVn1V+FktXPq98HtMqP6f8HJah/Lzy85hO+YLyBSxT+QXlFzC98kXl
i9iXlC8pX8KylC8rX8beVCYrk7FsZYoyBTumVCvVWI5So9RgucpUZSqWp0xTpmH5yqPKo1iBMkOZ
gR2PnIqcwgojpyOnsS9HzkTOYCciZyNnsZORc5FzmCFyPnIe4M5nSPUZUn2GVP8IkCp+V9H5FO+p
bc+Of8bxsYieCtCrmIKqpzfo+0CqpVfAp5PeAuds9BySSukHQCqil8E3QRWCegoqh55B9XX0GJDS
6H56BEgp9HUgJdLD9O1nsfH/29j4lFO1KhxP/1+r5DG899Rovj5z9uRW5uxrt9OtFYWUmiowqzMC
JxbyxzRt6bc0ba9ilF+brb2ZP0Y1U60FUW+snRpNkzNnMw9kzuZ3gPrZGQGdNiNA2SgnrJkelz+W
m5V+q3o/1UNNOSboWFrjWKA1VB/VR0fSCXQyraFLgAz/5b2/uv+1g7AN6dfUvZmzb6xVFOYMUmqz
2jEFW5BJatp04F6vtWqzMzq0TqrVRejGT43qivKNKc2nG+i90k1XvCvRmeJKdWw6rdWL1W10v0sL
7wjvacvKnLVpqehjrdp2V9GJhYrCD++XOavNdskZdqo1fejNeirJ1eK67LqizVaz9COLPpPJ2f9q
JOWHusi77XK42IpCZ7emLSfk6nUNVK3Ssa57VYRryNlAzWraMke12ad6YKFms7Py9dlR6RHO1cwD
Wlt2VG6icb8mpGapA7YaSkel5TXnOaFeqVqKUe8YUmC/QDHlj+lSQZt0GSAjcO44n5QdOnaQMlDF
edGaNud95y51mDp4bJSKPtWjcb+xljnrXHJu6LQUf6rT6UmPc0w5N6iCzOFsbe5uRWF6Higtr2KZ
w2aQMaZHpJ/IzaveX70O9A3sQc3SObSxepFqp7uoYVqk25zzwC5jwCaD9FEAgCbpFbiOhk4A9oP2
iqRpcORQqmPXKRNFUklUO9VXVUrdrCqlw+hDtIVaozaBFmZfDcGn6e6pWU2bK0bbl17qintN5Upx
WoFFsjLmXPdcefQj24wrwtZS2eqKcp3Qraa3qNk3am3arGFt+6sa7eOyUEVhbpGrweWBFiqIKoiq
qC/Qvll/7KbrmqvGVUOpoR0zhysK36yvWEmTjfu1Ok2bmlWzFfVUq9bk6k5P0VldpS5rurVcqwmV
y65bwFJ3qT7XOL0fFDtdSLvB3BcCmnhgb6MeghlzhL5jX6e3ab19jLoJJWqUuk1N0B30VWqZrqcD
9GLViVcn6WnqOvDhBfoG1AzwbOjTa/YxOoF6rMtC/9/S42c49BkOfYZD/xhwKBgd7U8j3YsLH4+p
bFP2e5jCfs82ap8B0i37OkZY1+xz4NyIbcA+BqR5+zKQ+mxd4JuwTtpZIM3b2u3joP5l+yCQ2myy
vQsjKk/YbUDibfX2vo9mhafvqKwpt57uKPViFjyI949HJ6rsc5k96o0MY1pcqjO19ktL4EzXl4jU
vgRwPlH1kkd9N30V1jhScqRLvZG6cDz6tcP2uddZeA5ekVqbJKeSSQ3p3QUNlY8T5rIOqO9qjCnL
R4xH1zN7MmtfepKoqoqvSqnKqzpRVVN1uepa1cApg2G+arXqviO6asehdhgc6qosh//UAwfv6HRc
d/Q4SEcfuCYRXFMErrl1ylA1X3W/6gmqrfuwZtVOVZHD5rituZEW8bIm8eHrOxVt9snM2pc1mn77
uqZfM5KU+Mph+3TCXOJUTr0uLlX3esrLmqoIe8fLd9TskRLUJtiaGvCsgaoT4BmrVfGwRUY3eMqm
w1DVAp7z0PHY0VONVYcdj369+8j00Umki0epC+qiRFVidFK35kbCXFpEZo99LrUA/LJ9pEtTn+p8
e/zIivpJgeM4WdGmsbzWbO+H7VPfhRpOja4Cuk6L0IC2pZ14efq/snf24VEW5/7fPC+7IQWklFIK
eStu9g2yu9mEl7wQaEhjQIyQUqDZ12xSGqOlkSJ6KMWUUowppogUkSIiIqaIKaVIEdNII2KMFJFS
yqGImNIUMQcph1KkmJyZz6Ta9tdfj+eP33Wd63d5Pdd+c+/9zHPPzD33zNz3zGQfUZJCWZYqT2VN
lb+yvqq0anZ8ryjJ9v5yFN9yoez6rSNFOe6oOn+ro+p6tRafUnWick314MpAfHHV/spioROh06rG
qi1VB6vOVh0VGt2ZW+YvdW2K58SXTzhzywVvt9Becnx0oHbsKVHypICRvSx/s/NQblluWey0r01w
6vy782uzR3hD2SsctbP2V2qB4+HGbEtGet4q1+DchfbTOSPtR/NWObpiq/MvCw10ZzcWlI0/KGrU
Ka48Ubu8jBr7QcdicSXlnvd2Txjm7Y6diO2benJCfWy/Iyl/s7CYapGuzlkw4aRjSHFd4Lhv7/iD
GQFnY2Vi5UShh02izWWrz6kMVS4StVgi26jseuXhyo7KM/HhWMCU+Lx4XXyHbJ9bLghOk/hsq6yv
rI/vqozHk+Kuyk3iyXhl+y0NgpccLxF3a4SWiyuvivRbhc4axLcFlSfj1fHauFFWFG+LH4h3Cn0v
rrwqbK9clGNnZbd4qrhyTWWrNyRbPbDNMcR+empPznTHEGH5dYG62Fnn0VlW2VMyFmQUTghN7Jxw
xpHja3DVeLtLBjv9ga5Al785sC27wLe8aKErpC5hfy32o9nNrku+Tmds0smihf5mUdpidcUvV66K
d1UNjZ+qGlGVGr+QXxs/Ej9eNdA701mQk5jd6DjnNkQfHJ3td5xydfiScobl1bsGK9vzdmfUB5Kc
G50bA9XFtcW1juGOIY4h/i2Batem3NO+0fbTJYPtR8cfzG60H8zeKPpmTsHCymH5ex2G47JvsahZ
YlVZdWJlepU9Xlc1XthhRdV8YXELK3dWNVftrlon7VBox6g6Ed9QdbHqSjy5qqWq5ZYZVbGqe8Td
nVXnq1ZXOkRd6kUbtcXbqk4Liz1RPayqoKqoakXVxqp9VYcql1QtCzRJK5jaE1wwZ2/geO71/MvS
XgLJrmECcxxJEzvHn41tKZhfNDt83rnRt3zqmeyjsdWxZnFdiTUH5mVMzCj0tjrqpm+wX5+wRHhz
Z7Jne7szhwpb6iwZnBGKtcR2563JGZYt+ld+rX9LbF3RQm88UO0YIu/lJ83dn7XScaBkjavenVzY
5C8rrvW1+Tqz5mTNcVpd6YVDxrdMmJ7jcA2ONk3tiZ2Pbcyant824ZJvuW9XyeGpvS7N1xa7GGiy
H7Ufde5z+u2Hss9XDvYvDB3xb/F250y86cCE6dkr7GKkcFrFyLQve7djSOy66O3N41cUJvvvcG7M
b3MtijY5lk4oDiTflDNpvWNxZmO2P2u6aDHRQ3LLQucC1WoMzt8sx9+MVaKnbZQjr9DbNm/31J7A
cdelQK3oN9PzN5ccy0mMn+N3+l41Xvv4v08+/u+T/0X/ffJ3v2M5soPPv/SI/NsnT7To/q3B5eKv
5t8YXCJw3eQCwVsdXDDZI741TJ4ivi13j8xuEN+WBIXX41/kHij+av47Jg8V3+YHiydbxLeIb6v4
Ns91Mbv8b/rHh/9XMjBx6Ie+2kiPfj2zxpPuLPSc9I1Iy0nZN60rpSJYF1zs6Q5WB5c7DgZ3BPdO
y/EmBzuTj7iaks85xzpD0wuCycHRQVehJTgj5Xyw1nvE0+1p93SL1NuCB4KdwePBBnFvx6Q6t91d
5C137LZ3+xO9S+0jQwXj1nlq/NP98TFJ/q3+Pf72lNLJ2yNTIvPSXI6hkVrHofAc34lwyFvuLQ8v
8i4N+b213trssZ4a71rxXM2oPf6VpTM9I+3dk7cHvZGS8OFRrf7t3qVze9NGp3akDYmOH9XqigQK
orNzO3LaAmXjhnpaxbdlzpnJ81x5jhZvXvjS3B73QN/A6IhoasEc++Gox7U4WpYyP6fti0dz2jyt
t1RE17nyoluiMfvhQEGwK80l9ZOclJ3uGzG9YFqX95rQz+LMmmkzfM3u5nGpoXsKFrktwU5vV0at
c6xvRKmWWROaH7oj9VjWcN/s0ArXNudKz4LI2lGtnjn5JyIbRrWnGZkducXu5tSTaRfyT4xJyroW
2ZE+NLI3xZPsjbSF1t28ILQxK1nWyR3L7k3tdva4IllJ9u7cDu9SWaPwdE9ryv5AQXbclZdW5yye
2+M4kdYpSynL6VziG5EdmNQ240Bma2brtBnTusalltUXLHIWBjt9q531zrGuvXOuhMeGA9n14YkZ
MzyLwoUOT3KSp9VZ6E2WbR86HboSHhZ2pO0al5o2b1Jd+lD3eE88Nd2xe5zfdzGr66bT+cuykrO7
xySltPi3uotG7YnU+nZ72gNnA9bg6DHJrhk5O9IuuEtnxQMjPPFwsbsgpVS2fOSarFVUlH9M0tz2
lCvepU5N1jFQIdrtUMBvr3E1BHYHylwRT6vrXKAgbbQrL9jgMub2ZFwLnPZtzBJlCZyfdDk2Mpbu
iLljrqa00cnz7N3R2eUzohdjibFhrs2eVm+OXdhh8pExSZEpnlZHS8HYvOX5W5KN4NrgBmd6zobo
fEdLyG/vDtiF1S8Jep2FhRbXlGCOb4R4akqwPGVfcF6aV7ZxcGnZTsfBzKu58aDXmyPbOHjEucAx
X9q/c6u7ZdThYF5wSt6RvCO+5mCTeG6z/C56TSS4a2575uExec6twZLMGtG32oOdnk2uU8lHMmt8
I0TvavPd4QxN68oantXgPjEtJ6Ui83DwVGa9c3pKhegx9tRe0WuqwyeD14LX0nZEjHHrvE3uZvtI
/xr/9jRvJC+rnJ6yKrzS7Qle9tS4lvrO+xPDx4IXInWZ9UIr5eEFjn3hDvHZmbbD3+ouiuRElrpL
HbtDReE9kaS0hkhtyO6sSdWyDjhDWdW+1W676HFLvUtTSr2bJ9VN3u5d7m1ILsnYkVLhXOBPdxzN
rnHs9xxLnZg61n7YWRywO66npju1aIH4FGUeTm7K7QjMzqgVfS3mWRVd7b4obLMpujHlkKNF9rXU
mZ6TqZui9uCU1K15R8Z5gk2jWqML5fdoaTASvSfgj96Ruj45EvV7l6aNdk505QX8afNSrOLbkGhF
dMW4de6B0ea04+6KaEtJV/I850Rnd3JTtNHebe9OjqROdG4SZWwRWqyX44bvfGpHyBPyhNcnN/nH
Cs2VhtvleBMR2g4NFFdZ5krHbley6J/X0zY7C91n5cfbJfpOT35FaGGoMbQ6tMyzwD0wqy3NGLfC
dyiyK7LDNdo+Un5C6yIHIttCW7I2hJojnWI8S40IqxOjz0Q+de6Ye517WaAxuju6z58uxomuUi2y
wbvUFZF9VH5LqciYUbAoOSm0O7Q/dDClIrkhsz0YSakIXc88nFYSHpy5KDxSXOk5DTNO5Z6xrwpr
4cSUCt9q1/LQ+ZSK1D2hs8HRhcucW8XY0xLaF04vPO1bkW4NHUrdHjoRuugbmHMhtTV0dO5J93gx
whZGxNgc6Zp7MndPeGbkgm+f68KNhwLXowOzt/oH+wdHqieVjxnuXuGtzjoeORU551wTtfj25Y12
N/v2+05MOuC7LvR2JHI8Up3l8h3MOZc1z3dxWlLUmj40sC61I3I5JebYJ3pqQ3S/uzl6NFBasjly
LXpajLhXCtoze2JaSoF7oHtgbLDzatpx0UuWZ9VFr9u7565yHI2eF31wdzQWTU0zhH20RvdHD8YG
p+268cSo7ugJz6bcOWltjo2egLCws2miVV2XU674zovrou9i5qZwa8jjLnD7w1vFHGH3xL0bQmWh
2XNOeBvsI7Pj02O+od4DKQPT6iKjI0P8h/3HPCcjLtmbIsmhoaER/jNZoz3tvvPJ5ZHF4XpvZ0pB
Vnk47r3gHp+63l2QNS801Lc6e453r7jEvRm75m6ascvfE4qFYjfZQ1bX3vyYt8t7Kq0rrcvdnHbK
d1qUpGBS9Rhvjtd3Mbw9sjzS4NmZFQnYUwNF7eHu8JlwT/iSXbgPY5JuPORZk7V40mUx3s+IlIcq
3Gdzz6QWR5oC/tSVnri7OaXlxkO+LWJ8NVIGessz1/tn+hf4N2Uuylw/eWyy4ZwYXhPe5G1LiWVt
C19N9mYlBc9l1ocsIY+3IVTqXpG9KdwbskS8oYGRSKTauzhlvGd6Zr17hGdieInvfGh8uCaUmrY4
vERYk2g1uV6ScPrj/x/5+P9HPv7/kf91/z/ydyuqg1f86/ghwxK4atHt10ZVi7+a/dKokMAeZ7Hg
dY+a6QyIb6edpeLbiVFF4q9mPzJbRBP2zlE54q9mb589VnxrHeWYnS6+7XZcFt9aRo1wDv1ghPgg
ekg4qq/nxEGe5WaLZVDPf/O59A/fr36EZ/6a7p+l7e3/9NODjf8zDbxL6i+fJPEZov5yf/jf3Psf
fD5Kuf9peZLFZ7Tl5oHX5DXIMsgqroHi71DxzSo+QweN4EodZBeXR/wdOMg/yC/ujOeuvPziUzCo
CAmlg4oGlQ2aLa7xgyrExyq+jxdXDJR/FWUHSweVimek/PlCynxxzUZukbjEk6Jtb/74HEL/OYRr
xjXLWE4jZHLqwMupAx+nDvycOsji1EGAUwfZnDrI4dTBOE4djOfUwQROHUzk1EEupw7yOHWQz6mD
Ak4dTOLUQSGnDiZz6mAKpw4+z6mDIk4dTOXUQTGnDr7AqYMSTh3cxKmDUk4dTOPUwfSPW/H/i1ZM
0FYZ/Ndgwh7hR1kSm/7+M6BAfIrEp7Sft+tD/j+m/Sgf5Oz6b9LJ+5tF2rJ/4G/o/0h629/I2fVh
eSjv//Dzkcq+7SOU+V/Vuemfl+8j6azob763ic8BS60txDXHtt3mEFe6rUZ822mL2/aIa4GtVXyX
Vw/XJfFxCP4SkSZuW0WaVlu7rcO2qF/KYdsxQbfzfFyknW47Ka4zoPyrqG4w9MFVLy75tx2J8toO
Xv0bvCSkLRB/e9WVaPRfSeqi3CJd4pBEuXL55Y/fb/xP3m/8nvGexctbjn285djPW46zeMtxgLcc
Z/OW4xzecjyOtxyP5y3HE3jL8UTecpzLW47zeMtxPm85LuAtx5N4y3EhbzmezFuOp/CW48/zluMi
3nI8lbccF/OW4y/wluMS3nJ8E285LuUtx9N4y/F03nJ8M285voW3HJfxluNbecvxTN5yPIu3HJfz
luN5vOW4mrccf4W3HM/nLcdf5S3HNbzl+LaPLeNjy/i/WEZCgidhOVFLp8Un7OOw+mhLxd8zH37X
reoj+fLvB7yBH6ZJ6O5/7vC/+EiZPf2fM/88/Qd5NfR/ln9I//XeB/eXf1Aenza7/6oQV0xc88E7
tIXaPeKarS3TVmiNgoqJ+/f082Zrq0k3H/468dkornVc88W1TDwh7y8TfWhw/2+1nv7gt1p1fqvV
MH5qHLQk8iutyfxKazq/0nojv9Kawa+0uvl91jH8PutYfp81k99n9f4/kytiUBn9WSx9vwK7wB7w
BHgYvAK+ISwhlfTL1VMJS8EIOBucAraAqyVqZaAfLIa/FdwLngEPgStJkwx9GWyHsxh6A6UdBqaC
LrCAuwvBGvA8eBzsRUIcTATzQOJv7SRYD64FG8GzEnUPGAKvy7pT0+Wq5JYkdCJ/j87SuwUsBwvB
dFAD94B1IDJ7h4NIfv8C9EDoq6JtY5wxvh9sANfImuo10L3gLzgFVQfeK1E7B/4BfFumFxwxiku7
F/QrPPUlcDbSvgA9g7s90E3QHSDy9Tuhfw++A74LXufuSPBu/j8VK9K/Bm4GE0m5gRL+CfopUiaA
/8GaQxt4Evw5uB18CfwJ+GPwMDKRY/66H0ULmuclbZ3O3e8hWZ3QfgxEgv4M+DOe+iN4Fvwi/BdB
ZOq/BPdR2ovQN0D/DlqHVlpqBdeCPwDfAJsVSrvVjkLnWzYLLFAo7VMrgb4TzKQkQyk5dTTc5HUA
/mfAbjhoUv88+C1wp1B7gr6CNGjSnAYfqzA65F3tApwW8D9JMx9MgvMQKc9Afx2kX2uk1F8Du+Bc
hf5sPx4VT6GNBOou+rPEVdxFmoaetb8gn5bVaVkTe9O/ARaC2JX+VRCtmqD+XSTQvnoJNK0v4lYp
U/EvQY+GPgQ+TEnWQO8Cf0iaMaBf6Q36U9DfIcdqaI1cOsFn4dDu1s9BJ4Ol4GoQm9f6wLcsYkzT
n0OyA5n0BTHSyrsqx08qTJgjUmLzIhKX8snXxPaEPyPRBn84fPRpzib9m+ApOErCq6AB3sKztKC5
EA4WZf00fFXyJeAWcI9lFvgdkT4b+ifgfonGIugIOERhginwkzK96N0yzQBwKDgMPETKbRITUxQm
XBKcG+Fn8mwBdAb4edAE08HPgEngVIXk+6KkhWXKXPLAfLAE/i6J1kclCmuU+CT4LNhKysnQG8Fn
4PhAVR7qIvr7LPqXQHM5qCM5BP8c2Aa+AP8e6Df6UdbuNE/9EPwj/CfA3eRVA/0OtBea0uo/BSmz
GDdAbYDgPA3/aSS/Dt0D/gFcAf6WkqBt/XkkO6E/i5wL0K/An0jd18CZxF0/nLVIUDYwHGyGQ0kM
A3wPvhv8FRzVgneBl+BQC+HNSnqcRJuNu58kr8fAH8Ch1fQwOAYcC37K8lsh4c/IuQpSNmOWQjEb
JBhYhZELbgEXkzILuhKMU/6VICW0onlrOSk3k8YFohnrF8gdq9B3wP81uAE8zFM/g95pCQq8F/o8
iIUYn0DO18E6OD/iqbeRiX3qHdzVoNGtjnzzVdKr0eNw30bBH6HGjYSxckzuPSboRjj4A8b3oXep
kVzeNRkTjIW9+2Ua+ZQxW/okuprj9lo6BN4k0SiV3oimvIt9vacFeuA0y6fMhyVqm5DPvKltgsMM
ou2Fbpd+mkBBW7eTO+Oz/j7l2UwaZm2B6wTnUcs1gRVw6hPGI01wtJ9SwnqJ2hPc/RESVkJvIc0O
cItlgUh5K7kcUSjz1V/vu0ncZczXniRf5QtdBg9bquWcIn1X/ene9XLcQDNqFl5H+l3odrH0zYxX
0HwbOn8JfJnxcwF5PUq+eL96b+8ogWep+5clCguU+t8g5YgyS//qc/hgjeS4WrUaOd4vfUi9SaJ2
l/RdNfwNXc31puQbNVInojW3UMIttI6cX05TqkrSLyPfL0n/U2vpXcH4IPmv98rxth36ld7n5Xgu
rUJoQPicBrO8dogW3EZ5tkkv3ZxJ7uVqlkEnuyg55TcblK6kR2FcoQx4Owb60d+CVjagfIAH4FAj
Yyk6xNs0sRCrmnkfBNeBt4FYnX4PiD51WlP/DYjPZtjBANLWg+OpEZ6eoeZB5XVkQd8F4o0YeHoG
npKBx6K/h4Q5oBcsgq+8nSukHADezt0hqo24+0L/HCrvpoHc1fHAdbwIA+9CjAzyKeUtPw/uAJUX
HSHNBNLgyZhO+L+Cj72Z6MdcAEd5NaQ36CkGPcvAU9Xx1Q00aSjPJ59n60F8KuObpKRd9Ch89Gai
VUN5Pvh1BjoxlP8wClTjTwrplU+1DaTMRjp8cjROg7Pg4JnoqrTLQCVf1f0aWAXeQUq8VuNGnlUS
KKeBl2jSIjretc6oaOJxGfR6XZUHyzHwb0X8JscBtKcrTw+N6feBjDw6ddGV/zwXpMV1eoSIpyRe
xd/GcjRaVnscRLKG5WvUTlPWi6dtHAGV9R6Er37RR0VkRBAGI5iONB39G9iVXDdhZpRI3KQTL2iq
pw8C8RL1HG2YRO7uxfN/EXyXPktPMYhcDKXbn/IUsZ6+gTR74WMnugucDAdfXXgOUs/EdMIrs9A3
hVY15aUrWyIXHRsQkbN8ajM0c4EehMMIr9OL9Vw4+NWaahdsRl8EYqUGtEa0aKh4ZFl/m0rOFPAr
pFFx8ct41yoXokhDec70cUPlQoxmqAiXqNlQ3rKycDUCbKS+pczReCzGPOiHwPvAb+CVKQ/nZdJ8
m9kcH8x8Cn4UvA28H8Tn1PFSdPwEMUdLLATvRSY+j9ChxFNgFzJH40Hhvwnbk6hK8iZ0I/gIHLwv
vZhS/R4aH9hUXuJOkBIaypdTXsoDIB6yMRP6YRD/R3gREqdrX6MvS/oXYAv4PZ5SfmkD+CBYBCpN
4n3pqvzKow5A4+VqyhtU+VaDPwavgKNAvD79S2AFqLy4NBCd6Oekl6hTa0PFKfi6BvkK32kWLS5T
ngCPw6mHXg0SRxjKn8QXNfBg9X0g3rWBN2t8F63SI0zsWSOC0/8NWq0zEN/ZiLls9GuNMUpXXhxz
gaHGnP14RBk8Rd8xiZo1hfiHGrOYFQu3qYg+BjKWCs9Z8ut7l0j/ivRE39qjkmPWMLPT03VGaZ3o
1crKkslKkU6f0tWsqtZ/GJM1RgbjBKhi8OPgMe4y42sb1Tgg17UM5i+NXqypVQVqpLEyo+GvaujE
8Mj0+nN9QwRnIc8elmhTmglKWjtCetZwNOVX1IHMqpqaAfF1raweiGhU0ujNquZNVjzMb0OrVSlG
HhM/xHhW+n5GObnfTXnSezuln9DnFfJvlxyTGd9knLfi+ZiMjZrSPG1q4rcbrNJYmSvNT6qWJWUc
ThltpOY7RlRD+UU3Qd9MfZUPrOrIKoGJX2GwGmOibZNxT6+jtDNJjz+jvYuE38L/HOgDK8G5YClp
HkHOc9DMShpzsbYMPxb7NNppC3wDGz6eDW/HNgJd4fuZWJGh1me+ivxGuU4rvDuBVtrIfEvZLXnd
Cz4E3g8uBb/V3/rlAp+Hs0bZHrRau0CHOqtkWkefVUheo6wIVOt4GywTmOkEWllLEdG3hfFQpqFv
mnieVtColZjw5947QVn3Hmrh56k7ZS3MH8n1Xo31FoNeZuJzakoa3qaBbRuUx0R7uvKg8Jb1Erz6
d7Al7FNvoF54pFoNdc+VmNCGz0/EofnAWqUxpOFNmWjApHYma2gGq2FWvFMDj1dnLjOwPRFrW4hM
JUd53cqvo8/a1MqestV6GRVqzOYavreGJ2niD9vwx3TWcq1/kH1Ea6SnHO09J/hfJiX+icYcrWPV
plphVqtbBaDyPY70vcC4LWnl77FGbaVPWVkhNPFGTOW3qPXVdNkWhvLS60mJ52CyPmZSNnMwiKdq
YxxIgmPDA7cx45vKkrENE/ux4RUYyvNRPgZry1a8F2uMHBnxjBai6UnQ2JUVazFVdKPGRvIyWUU0
WOMVc+IpkRLPX2PlVqN1NEZUjRVsDc/T2El5GOts6NCGBBujtKnaehwpkWaw/mmgeUONnGp0Jbq0
It9KdGAlrjfxHq1qHXUH3iNWrStr7JHl1K5IFDGvxOtyZ0d4jJLWwQnUBTnmERD7N1kZtqIZK166
SWxi3GrZLjhq3MNTNeeiQ9rXirdsZTw0lR/4dn+9RBpN7TKwemyoWisLVCOq8plpfUPFOKqfMn8Z
+J+GioyIB63KD2Qusyq7Qr6V2cHErkwVtX0iYZG4Sy+w0lJW/H8rNmBlJrWq+XoKtPJasVtDlR8N
2PDebXiYZjp8ZVHMWcI/rxD0BIlGO3hEoojXJN0GDujHi0SgFVi4xA74WyUOMBXK/S/DDT8bzAUz
wBHgLInCs6pgDpL4IPhkPy1yMSpJ8xtyoWzmzeBU+Ksl2rZJFPN4BZZcwWqMTJMDvQbcicy34Y/n
2d/DOQV9GeyBU4Ee7gYtyIcj/A2J74CUx/Y16DeQSb7Wx8Bu+CvAB8CNpJkJ/Rb4UP+z1fhmkv45
eAh8ivIcVyh8nwSjEf7zyHkV+t/Bi+A3yfdF6DrwyyDlF1F5BRZbQQwrtYEm9d9BHwNpHdtYEPnC
E6tgvJXPloCvwLkReg64Cw6tJixWYi0SepFPqYQfK/EF8Cx4Afw1Ev5MyX8F0gpilJP82UgrA+Ny
Z1b0hQpWSCqItSXeDk4G3wNpEdGjZRl41jYDmcPg++BkgR741fA74SDTwHKMR+DvALvAH5D+APR9
pIlDI988A4c0RgzOGBD9m58GsXDbHSCaEX5gBeNhBbO25Otw1qKfp1nxe1rufRvsxOkb8MyvSI4V
39hKf9fxoPTl3H1EoUyjL4BWqxl7mPft+Cqs22jN3P13Zvk7uKvS7CfNzYwJgxRKvsn8ov+eNEk8
y1qHqdZDKuC8xN1h0CcV9tXKuAl6L/i6Qkr4JySr9UwV/z7B3S3c3cJdNRteppwPIP9d6O+AD4Or
wR+AfwTfRs5T0PdDPwg9HWRtU4uAS8EWmaNW11sqowClN/KaxV0VGakVNrWionZ1s8HHSX8LqHb9
fDx7F5xPSn3qd6GHZXC+AXaAp+GPUevk0Jd49tOqvdBAFjQ+icEuv6FaXK3eqPWcVvhEecaN0Aao
PPbPI38FOAdkLUWfg549cOpYea5DDxfgVIMLSKPa9zPgNHAueDtYCZaDW8H30Rv11YrBOOU5wt2n
yetp6AaF5HInaZ6E828g7avT7jotrn8WHIhMrFHHPrWz0MOh8UO0Q4qmRodkjlqL0jOorHQMrTNG
tQLxl4o6p8Pfih+uPNX1pN8MfhfEroyJ0IVgEViqImgk4DnrT0n5BhG6MUXytfN9IwX/ZdL8CDlq
RfcncH6ChJ9B/0zpFnqOREOtTjfD2QSq+KIOOfOg72PcwJfQicFNVqL0mUibibbX8uwptLQG/jOU
bR74Ve7i5+jKW76V3FWNdkG/Q5qdPLuTHN+GQyyj3w+tIsSd0AdAFfuvpUWu8aw6O8Feg76SNCsp
4SalVVqnCD4xoEYcoecqDvgtsAR8HuuyQvfv0UMfVfWl5O3Qm8FF4HGwDWQl2YoHnojXmkg/SmQ9
wcrYaFWr5awimhnK15KltWEb2jPavRLlWSbjQREzSX/GwupBt4xqZY1E7ClXQppAom8df097jmfv
l89qT/VNtMg9GsnfQLs8J+ZqudrZDV/i4/KslLaprwG7kniGpx4n/VJ5ykh/QKY03koYjI80VMqx
rBKcmTIv41lyZG1Te41nLyiUfH2NPFWl3a85LHLfql2OA5y+CPTFBH+tPCWllWu7GCe7GSdlqR4V
UalcPehmNv+FoDfKU09aI7tFD8kzV9rTfc8i/7i0wIT35Hgrz0EZd0kUaS5LK0rYJnOB09h3QI5m
ktYr+jk7LXK1eTWxucw9Js+MGUV47PXS2zdu75skPS60sdYSkE/JPUFtbV+RzFeikQNyQsZYDz2T
szEN7Fq+1mcX+DuJQoKou/4G55rGsMv2jKQNg2jlq0hufH8tI+RCOVLJyF37T3I/Ip/VngGfAh8C
HwHXss/YiG4vyB00YSGX4JyipjPkTM2K9/2WEjiy3RskCksWaJzsm4OvKFuWnQVt9fvFErGl1XCe
5alnqcuzyH8YzsPs2U1G2vdZOfmLjKa1F7GWF/taoBeDJy3yLNYFac99AkWUFyBNjaBPSAnWsZTn
t7I82iZq9yBx1nfRlRfrWiY51q9IWi8l34uWe+T8glafQMNvy+NzIiaVOl9FCZ+QGja+0bdMtjL9
axbl/z65PAH+hNb/vtIbGqsnZtnebwO7aX25qrYKybdQ03oiyicp4RxZKiOZtQW1nlMjT80Ja5FP
NSaMsMhzVrJGJZS8nPSLpH2KiKODXKS0l7GfJynJMdK/1reGuldjXZRWytSDWN1XpGRhaVZsQ9pz
UD5r/lCWRIyiB5DcwVwgdxnmvC/745xe2S71CaPJ/Sjlke27m1nmLSyqQPYFkWObLKclU+A21kwW
MQ5vl6cZRR+8wSJ3YwXq9/TlwhmBDjOptdyjSYB+AXzF0meROwtSGimF753JUymC4wYTJepTadMf
ytx1E7xK2Rr7pso+0pfBSPIpaueTuwzQa5D2OPR90I9A7wG3WW60yPMJtwsJSQn54ql3e9+3yCg7
U85QpF/bjz8Ud/MTJlAXUWbjl5Z3pK321ysFvuBoO/o+IZ4NSRS6kvX6o6qRuguusXxJpHGQy0qF
fdngw9LaZdn0RZbPCqyijjNIc8DyJyHNJlcwhO1Nkn2ZXELcDZDL0wl3W+TsJvMld+3ZfpTP3tv3
CqUV8s3fy5rq1ar8snb6YzIvEZvLZwtYPXsIOgFd3S/1o9+QIDX2LJxXGBUfT/iCbKM+t0A/mCxR
tIVT4K6+T4unltCCwylnV9+f8S4mMf4kkPufqPtX5Azer400SdOyVdKK9KreZyxyLyOTUf1rxH0y
5Xel3gRHlucletAvlQ0k3Ez5Za2/Q30z5UxkjpQ9wmT/0faq5Nj2So4N38aGT25O4ETEBOk/mHi5
NmZVK2vvxjp8pHXcZdfVZJ3KygybxMrPAPyrAdw1HiP9Y/g2M+Fwps64TSH+OXujBn67iTduvkUM
dVBiIitdNtZhEvEWtDOkWYmfsI+n2GE038QzYR/Ehvdu/RV4TfKt1DFRncf7ukJ5N9GN10G0lZhA
vt9CJj6YuVohadiRt93HXbUqiI9tXIR+FP7N4FD8VaI2M0UhUac6qahqrXaN1e4P2jMaKL/aUVVn
D54nJd649XPo8Bg5vkxp1aovMYKNvXWbOjOzEc0QH9luhVax2zaQcmp445qKFomJtKtIfhM8qGhG
UaIejThFU/HgvdxV5zyTSHM3/Pky+tPUmQq14+8gZRclmQxNDGuoOJeIw7ZR1Q4JameN1UWrQ1kp
ctSqMntniVhRIrtFVrWTolbzOA1lVadK/rrzKzk8ZaU1rWqVGC0lsgedyP6OVe2PL6ZUr6ETdKV/
H/uphX6J1rmNlv0xKaNYSwF8dbYhSnvVSY6N3R8blmzMxALVPvVTPPUcqGhKZVX7QSrWwK829yJH
rVJ2wnkV/Dn9Qu1I5qq6I5/4OnEEOa4D1cmKFO6yx2FVK66caLXdCV+te6vzM1/mqdPk8iK4AsTD
N5XG0sF8ysb+iEl72dSZ233wVYxPi5i96Ir4yKpO2hDfGSEilN8RaxzDtjmfZig7mcQI8yk0/zvw
OMjqhEGfNeEbRNbGUDjKPr8Hh6jKRsRtSwOtlGEcUSqxrcFaitGkkDIQTVufQRpxscFqhvU8udN3
9B3k0gNegZNKXTqQzAk3IwcJKsbvA3+tkPjo11hRLXVnjNLuRvPEPsar/VgnkKeM05QhEXoGct4D
lR3S+4wOKdMcQpt+uz8ikzPap2i7TyD/P8DfUDYN+jJ4BvmsgeisXxnE9dZvQs8FC1XvgH4dZHy2
jYJmPBGev9Qh59aMAXAG0I7sEw1Qu1rZpFERHzut+hUkVKp1M7XCRnuxG6upVawcxpk1ILGwOZ6n
2IPW2ZmyokO5tcKaswX/WZbwa6TfD+cNSvUGozE7HdZu5LCPY6gzb6rPvgHS10SflS3byLONqmdR
L0YnqzqTxq6ZYaFlLZRTrROqvXX6qU3NdPQ1mzrr8gItdRaZf6b8KkZW7aL68mzKHwe9oANU59mI
sk11Ck7VlPayqR1qdlusw+D74LPLaWOnzGQtwuxUyF0ki1azsnJrYeVWSmDlwSQmMtivMX5Ayhj8
ySA2Y6J/89OKRiYrqDZlS+xy2tTuEjOgjbXBAYzJA9CJDfk21mFs7PvY1FxjwxJysQ1mLnOC5QY5
1hEXrJN0UqI8eyl8j2rpdUiO8C46pD9AjuyMJ7LrauPsfSJ7Oua31Myu5nQ1m6v5F/l7wU7wNfBl
JB+SaP0cnGPgm+BxiWJ2vkHOzmAUvCxRg691wLkV+kGk1UKTXsSnxBHgo+B68AmJ+gOgBc5VctwD
HgRfhL8C3A/nXejbwafAe+G3km8SnLuRuRR8Hc588AXw5/BngQb4PZ51gLeBNyCzi7tbqd1kOC+B
Z5HzF/howHoe/kOk/yJYBKIH4QVJRBsGcvQ2aHX3OaRlwqcWGhoQnsMNeA4yDWUw0K2OJkVUfgOe
gKRVqX5MydXqXD52os5CvCl3DE21M6h6x8/V3KrmTfjFPKv2yhkBzBVqZuyf++TdXnJZAzaAuyjn
nZSEMgv7lymHgtR6AHYyoA/8E2ni4DxQlTkdWrWgDRrbMExQnQK6wpnJK+Q1/b/Y+w5wLYpk7aru
nu6Z+b5DzhkkSs4554xIFImHnHNWAVERELOiIgLmnAjqrgkTImLOYV0DgmmVdRXzX/3OqJyz7l32
uve///88e77nvD3d0zPTXV3V1dXTPeXlwia7bC5DnhhnobuDZM4z4a7NQJRT7wJuw1NewlXgeXUz
UnJwFiVUlwLvREppHB/CccKN4Ct1OfA8pN+K49nALUBIq3oTiCfq14Gf4blv43grMGnrpO4FcBac
aXbgbCI7ybVFgeB8fToQ1NaFgXi6Xoj8SXpFHOMpajrumXAm5EgnvNoXiDbV9ZFnAY7Rdvo+IPpe
Uw/vnceAtk8iZ7LO8/NED+J4A9I74irIuD4JCPm14PygFHCEx/AN4Ic42xvpqLvbjuNqOH4Yx2Vx
vCvlio5+9IIZlU3+OMKaiqi854oQ71zCC/0cVIiVA4J+HgmjRP2Kv8rBYrJYBeGw5oqh0xnvUDjZ
uYBVVQw967BmxmHXlcOaDbPK399iFYpNVrEmO/XAk6a5L5UrhONkHQtqpNGn6adQCwVk4OVp7epi
5O+psRi4BG2HtlaQF3Ux0tE7qVnArkDQWY0BfgFM+qsrgJApoz0yeh4G5Rn9obRdQext9PgsEP2J
huQyehuGFmDoBVUBCBnnRI4aAicDawFrIA/43J6BlCTnLUgfifRBaNnjgAeQDj5UCWei7hpn1R04
ng/8Hs8FlXRJnC2GOzTDPdGzBeDJYH+iqYHJ2n6sANHfoK9ASTT6MX0W7gNtGCTH4El9R1JycH5i
uWOVlEvmHJL1e1hpHGBdtEvscbyfNYlVkqyWxxjArkA6ctpkLRZ6jwA6yCSS+DxqtwLp0IaMMlhI
rkGLhNCAIfqHqA7Ooo+yyd0g9WKd+fyQMos+U2xzj8nqcbwJUhgnqGRtM9YIqWRnJVZVKfSiKtkX
mawNS1a5J3sPk/kTWMcqeZeRjKaSVW0J52ONk05WSid7e5M3UMnb5GT3yjmYlcIcl/TMHm9EisHx
FmC3dMbM4x6crYZjzGgFSfoQ4AjgKOAgYF/gVGAbYFcg5jA15gN1XeBbwA+B7wExexYUS2YdgSit
fiOZe8TxTuCbwCbA24Gtgc2BM1HmU4AdgZ8hHfIuusOnHMHxHTiuDDwfuB3ppwMxByh63+Mh4Drg
buD1wIuBdYBX4Q41cHwb8F7gaUi/GsdLgCiV7glMZiAxz6kbJ/OQQFDVvAKa1EjmFZHnOuALwOnA
y3E2BrZFyle4qgPu8xNSCgFRU90CeD/y41kyUvU4C+nTgAeBh4FPADFbq18EJvOHf8ZV7XCc0PNT
pOBag5Y1vZH+Go5fB74MnAfELK5J7rkBxyWBmI8Vya0L7ePPrgfOAYIm+mHgPuBjyImaSj/vU5LW
fASIVguw2irA+iuX7ATvjHWtyZtf7JVTGNUH6FUsbAqX7HdoA9vtcqzM/B52bmJTJ3NrySprrFbl
dzD/iXd5Id4Lm2R3MFa4GVgoJtnpluzEfwVlSNZOY0WxugjrtPf5+4jNPtvbgHgi9t2LRb/Ujw+x
NhX7GoIXk9GXT7GwEG2yQwRrGFR3pC/A2lFGSgEg5kb4B9znNeAtyLMexw+iLpgD5API3wzpnbBC
tUS6WtvbngexlhU7kuyzQMzfBsk6RtjyFmuhze2Yr8CsqamI+4D+uizeg2zFmx3YUwrztPw1bLRE
m2scY4+MSWZlE7sSs8EqGQNgLsViFshiLV+AdY8Ge+cDzCdozCXaZK9Nsioelp0JMCMKTRFg5Z5L
VgNinKOSNcOJ9Z3Mwg0DrZKZpQ047oe6YKbIOKR0BT6B9BxgU2BfYFL3Jsizx+9PVPN9WzPmThlz
m4z1FS5Z+4q1i/oLXIWn6/ag4Rj/Xkn6gZj8vjnBINl3eSXunLT7UrTRFThei2sH41qsCTdLkD4y
WWOPlLbIE+IYEmGQLv1MI/SlgjpZyzoy4Xm0F1abq1eBoJsZmqxkhuUOHacTWVPp/K2//3zc+XRc
lYvjs7FXsTvyNEL6RKRXAx8m3xy4CtcWxV7X3cBkjjfZjfgp6osdBxocHmBWRO7g77zCo3CRlwu8
obAYnZoGeEoFPCXZ4YV5DD0dkphoZ+xrYMys8j7M0kBHK/CGSvYbLkOZz/BcHVTBPAb6BL0QPYPF
W/tkrRfubCogf7JvK9mru8e/o9d1cf9kd0MyL5es7X/Nlz9I9hck1uII3Kc1ypnMSDRA+qWo72Lk
B98ydqPoG0GxxFbFKCuGHeogEQbrjqyfd6XkGyc8NexBOnfJ3OlUbNLcCdNo4fSx82fSdZ7bThzY
qRI1I/rpJypKWbJUmipREaotPNKM2lJ38isJifrRGJpI02muWAZJ3hxyVIYqy1EdakzNqR31oMF+
XzX1p7E0iWbQPFpC+KgI8hegkMpSFfKjgybUgtpTTxpCJ5OiATQOX0qdT0upBOmeAwb0oC4D+/et
RCcPGti7Eq3HHfyYNaJydBwVp3rUkjpQF+pFQ2kkafK7eXJpCs2iBbQMuSMqT1XlbvWplVgWvakm
LUd6cSokta5A1agkNaCm1Jo6UVfqQ8NolJS1Fg2Uke5Umk0L6ZT0qYUpQxWpOpWihtSGOlM36kvD
aTQFdDydSBNoGs2hRXQqnZbbaF6u+t6jNsAssBiwHLBq7tjp83UdYDNgB2Av4CDgqNyx8yboycCZ
wPnApcAVwDNzc2fM1uuBW4DbgXuAbwI/92jM+JmzZpgSwHLAKsCawHrAJsBWE+eOzTUdgH2Aw4Dj
gbOBy4Frpk+ZNNZcBNwEvAZ4y/SZC2aY7cD7gA8BHwfuAz4PfHX6rNzp5m3g+8BPgIfl5FxzBPij
x8AAY2AhYAlguVkSBFWANYH1gE2ArYAdgN1mzR0/M+gDHAgcNtunjwKOB04FzgYuBC4HrponLRKs
AW4AXgS8HLgFeN28KTMnBrcA7wLeA3wA+Chw77wZubODZ4GvA98HfgY84tGqefMaNLRZYDFgOWBV
YB1gE8FGtg2wE7AHsB9wEPAkwcZ2DHAycDZwMXAFcM28BbPn2fOAlwA3AbcBbwDeNl8oYLcD7wM+
BHwcuA/4PNCvwVciH6X/hVBLz1GFjvtvHflvmP0zDEWaA+nNnBxFIvGZ/0tpTtLypjAVOEb0Vm0h
6W+K/BuPlfSC1f6LkKnkMaPCdYqgwaFZ/L/HnGPGEseMlf4Oix8zVj8GLPpPUYt+K4dv7x/7UVk5
qgA6+e/1H3vIVOufohKNU/tfCJkqHgMWOyZsKdp5NV1E19B2epRepPfpS67CjbgTD+RxPJdX8QW8
je/i3fw8v8uHlVJFVBXVSHVSA9U4NVetUheobeqP6iNdStfULXQPPUxP1ov1Gr1R36Dv0Xv0q/qg
PmJCU8rUNC1MDzOMYH1RmPCa/iRv3FC++PH54o2Oiktm04D8Bp4kbomC5Xnj7r6j8ks8ehtxI5JZ
Qlq0epJa8NskLGTSsEAalsp7dZHb8saL9shbmpL5SltuQ954+Q754oPyxSfnvX/55fniG/I+r/xN
+a7PR80K5fLF1+aLH8kbr9gjX3xj3udVq3lUXPqNao/njVfP5r2++sC88bpV8sWr5otXzxuvZxFX
0ucWSShQr0UaPvRb7Vh/fBrOTMPFabj6t3I32J2G+9Lw5TR8N2+tG1bI2woNx+ctZaN78sX35o03
3pQvvjlffEu++F1H8bCPb88Xfzlf/lfzxpvl48JmXfK2UrOJec+PvSZffFu++M588Xz1HXtf3vuP
r5T3/ATjv5EplJxEB2U0/wl0jfddQvAzIramWQANVIRstMmdF13hNri1br2kWL6Nb5Nb+W/fsvRD
d5HCF3A1vixr8GXZILm7rqPr6nq6PjwnPIWvEipfAvW1L4V6VFLrSbyE2AdzaRM9Tu/Qt1xMShLK
1cWia0hFV0TXCm6KrhO8UupQSEY1laQf9/4f2rjbSPOTUrLbEZ7n7pDwaYnfifA8dxUpiW0RPM9t
FbxAauz5tgxVcdeRlhptcNcjPM/dIOF6id+I8Lyjct6U5rw5zXlLmvPWNGdaXnchnnYxnnYpnvbz
mctw5gqcufLoM9Fm1PEq1HEL6vjzma04sw1nrsYZJTz3CD8itPdfFmZ8WVjhy8Ia37c1+L5tEF0W
XS4ykYwdvIw28S0utqOSdllHfrbJ++tmU8dImp1ip8j1i91iMv/5pvF/vmn8D75p/Cs3lQE31UW/
st52+w/P/Idn/iHPML8Krknsl3rwz/G7eQWckQFnZMEZOeCMAuCMguCMQuCMwuCMIuCMouCMYuCM
4uCMEuCMkuCMUuCM0uCMMuZ6c73wiuePcuCP8uCPCuCPiuCPSuCPyuCPKuCP48AfVcEf1cAf1cEf
NcAfNcEftcAfx4M/aoM/6oA/6oI/6oE/6oM/GoA/GoI/GoE/GoM/moA/moI/moE/moM/WoA/WoI/
WoE/WoM/2oA/2oI/2oE/2oM/OoA/OoI/OoE/OoM/uqBdu6Jdu6Fdu6Nde6Bde6JdvZeVe0VX+Dnj
1fI7jc6U3wpaI7+VtJY2yJnb6HY6Cx7OzoauWUt75LcOHs7Ww8PZOXSIPqJz2XBA5/NVfDVdyDfw
zbQR/ls2wX/LlfDfshn+W66C/5Yt8N+yFf5btsF/y9Xw33IN/LdcC/8t16lyqg1dr9qp9rRHdVQd
aa/qrDrTU6qr6kb7VE/Vk/arPqoPPaMGq8H0rBqqhtJz6ly1m55Xj6pH2apX1Cvs1AfqAw7VF+oL
jtSX6kuO1dfqa87AD1nW+4fhHO8fhgt4/zBc0PuH4ULePwwX9v5huIj3D8NFvX8YLub9w3BxfciU
4BIyuprPXcwSs4y7mhVmBffwfmO4p/cbw7283xju7f3GcB/vN4b7er8x3M/7jeH+3m8MD/B+Y/gE
7zeGB5o9Zg+faPaavTzI7DP7eLDZb/bzEPOseZaHeq8yPMx7leHh3qsMn+S9yvAI71WGT/ZeZXik
9yrDo7xXGR7tvcrwGO9Vhsd6rzI8znuV4VzvVYbHe68yPMF7leGJAQfMkwIdaJ4c2MDylCAMQp7q
vc3wNO9thqd7bzM8w3ub4Zne2wzP8t5meLb3NsNzvLcZnuu9zfA8722G53tvM7zAe5vhhd7bDC/y
3mZ4sfc2w0u8txle6r3N8DLvbYaXe28zfIr3NsOnem8zfJr3NsMrvLcZXhm0Dr7kVcFXwVeqTXAk
+Ea1Db4PflTtLVtWnayxRnW2sc2qLt6jm+puG9pGqodtbVurXra9ba962262m+pje9s+qq/tZ09Q
/e3V9mp1or3OXq8G2efsc2qIfcG+oIbal+xLapg9aA+q4fZj+7E6yc10M9UIN9vNVSe7BW6hGu1H
WWqsW+aWqXFupVulct3dbrea4B5zj6kFbr/brxa659xzapF7wb2gFruX3ctqifswHKuWRrnRRvW3
6LboC107+i76Ts+KozjSs+OicVE9J64T19Vz4zXx2Xp+vC4+Ry+ML4ov0kviS+JL9NL4ynizXhZv
ibfqU+Jr4mv0afGN8c16RXxrfKs+Pb4rvkuvjnfEf9BnxPfHD+j18UPxo3pDfCA+oC+MP44/1hdl
Gmea6oszHTMd9cZM90xPfVmmd6aP3pQZmBmoN2eGZYbpqzIjMyP1lszozGi9NfuH7MN6m/f2o2/0
3n70Td7bj77Ze/vRt3hvP/pW7+1H35Z9Lfuhvj2ndU5r/YDXGH79C/VINUb9dNzRTP4H/pLCtFP+
q+bL48cm16QpikxA/gVaoAKxPQL5IxW4wEleRUWT3gv9xGmQ+y1eLulFyKWCXGrhnS/Y+hbm+30L
8wO+hflB38L8kG9hflha72He7duHn0P79PHto1b52qvHfc3U075m6k156mD0loTektFbKvSWGr1l
iN4yRm+ZQW+ZRW+Zg96yAHrLQugti6C3LIbesjR6ufLo5Sqil6uEXq4yernj0MtVRS9XDb1cdd+/
UQ3fv1FN379RLd+/0fG+f6Pavn+jOvCTXtf3S6KTDgdfik4SCRI9JBIkekgkiJp6CaIWXoKopZcg
auUliNp6CaJ2XoKog5cg6ugliDp5CaLOXoKoq5cg6uklSMYdIiPUx8uIjDtERmSs4S2RgV5G6EQv
IzTI7Xa7aYiXERrqZYSGeRmh4V5G6CQvIzTCSwSd7CWCRnqJoFFeImi0lwga6yWCcr1E0EQvETTJ
SwRN9hJBU71E0HQvETTDSwTN9hJBc7xE0FwvEbTESwQt8xJBK7xE0EovEbTKSwSd4SWCzvQSQWd7
iaB1XiJovZcIOsdLBNo5scR+Hg018PaYecJ/FdY8aZ4Ue+wp8xQp87QRe848Y56BPfa/wau/yJOe
jZI2lHKcizkaoloy8o9EwuoLTzakFlSQWlE7KkkdqDuVk7GB8Bv1k59/T3iy2Omj5NeExtAEakqT
ZEzYmqbRPLligYwbutOVdK3I9Q10C42gO2iX5LuX7qfJ9CA9RjPoSdpL82mf/BbSfvktoufoRVpM
L9NbtJz+JL/V9Gc6QGfQQfmto0/kt54+o69kdHGEFV3ClbimjBZqc326iRtyQ7qdG3MruoPbcAe6
hztxT7qf+3A/eowH8AASLcqj6Ekew2PoJR7Hk+hlnsLT6E2ewQvoT7yIV9JB1UK1oL+q1tIeX6rh
Kpe+UsvVama1UW2UEcLt6nbOqO1qB2fVLrWLC6h71X1cUD2gHuDCap/ax0XUe0pGBeqgOsTF1Mfq
Yy6hPlWfcUl1WB3m0po1cxldSpfisrq8rsDldCVdiSvoKvo4rqhr6BpcWTgg4CrGmRxubwqaxtzN
NDWteZppa8byXJNrpvClZpqZy5uD3GAGXxfMCmbzncHcYB7fHSwMFvKOYGlwJu8M1gRr+JFgfbCe
Hw02BBfwY8GW4G7eG+wIPuS3bY4tpgrbEraUKm3L2LKqnC1vK6oKtrKtpyrbBraBqm+b2CaqgW1m
W6mGdqAdqJrZQXaIam6H2VzVyk6wE1U3O9meIVr1LLtNTbQv23fUKvuufU+dYz+wB9S59pA9pM63
n9pv1AX2O/udusr+ZH9SWxy7QG11Jd3x6jpXx/VQ97leLle94s52Z6sv3L3uPnXYve3+pL50H7rv
1Ffuh7CizoSVw2G6XnhSeI6eGJ4bfq4vDw9HxfX3UclouKkUjYimmdxoRnSKmR+dFp1rzojOjzaa
S6InoyfN5ujZ6DlzVfRC9ILZGr0UvWK2Ra9Fb5hro7eid80N0fvR++a2OBtnze1xsbi4uSMuGZc0
d8Wl47Lm7rh8XNHsjCvH1c29cc24pnkwPiE+wTwUD4uHm4fjEfEI80g8Mh5tHo3HxrnmiXhCPNXs
jafH082zIl3FxSq6E1bRDrGH7pFRrxGr6H6xgURmxfp5TEa9sVhFeykrVtF+KiBW0fOiD16SUW8R
sYpeF33g/d2UgL+bkrCjS8OOLoP5t7L6BX1Q7JgrzMfU2HwatKLVYgneRc/LeP9F+g57IgK5XxXV
RHczw0SSW1EnkWbvW3UcTaW5tFR6obV0AV1O2+gmuovuo90inc/T6/SuaKbD9C37BRXZzD2kM3dn
tmfuRbgjcx/CnZk/INyVuV/C7XL0AMLtmQcR7sg8hHBn5mGEuzKPSLhD8j2KcHvmMYQ7Mo8j3Jl5
AuGuzJMS7pR8exFuzzyFcEdmH8KdmacR7so8I+Euyfcswu2Z5xDuyDyPcGfmBYS7Mn8kJWd3C+7I
7BHcmdkvuOt3UOQl1PzuzMspZV5JKfNqSpnXUsq8nlLmjZQib6YUeSulyJ9SiryTUuTPKUXeTSny
XkqRD1KKHEgp8mFKkYMpRQ6lFPk4pcgnKUU+TSnyWUqRv6QUeVHqf3fmbVDkfVDko99JkS9SihxO
KfLXlCJfphT5W0qRr1OKHEl55ZuUMt+mlPkupcz3KWV+SCnzY0qRnxKKZDmhSFYlFMnqhCJZk1Ak
GyQUybqEItkwoUg2SiiSjROKZDMpRT4HRb7ynJIlT5Gs/X0UyeYkFMkWSCiSLZhQJFsooUi2cEKR
bNGEItliCUWyxROKZEskFMmWTCiSLZ1QJFsmoUi2bMIr2XIJZbLlU8pUSClTMaVMpZQylVOKHJdS
pGpKkWopRaqnFKmRUCSb9RTJFgFFSnlOyVb5nRSplVLk+JQitVOK1EkpUjelSP2UIg1SijRMKdIo
pUjjlCJNU4o0SynSPKVIi5QiLVOKtE4p0ialSNuUIu1SXmmfUqZDSpmOKWU6pZTpnFKmJihSDxRp
Aoq08pzi34T4cuNNyDCqxR/yR/wpf8vf8Y/8k9JirjgVqxxVQBVWRVRxVUKt1S30ZD1FT9XT9HQ9
Q8/Us/RsPUfP1fP0fL1AL9SL9GK9RC/Vy4LF2cVy38J8wPuN40N8iJg/4U9EpxxhkR7+nn8Qk0j+
yCmjDIXKKkuRkh/FKqOylFEFVSHKUUX9zgV1tjqbCuvmujkV0YP0JCoaLAoWUY3souwiGdspKkOx
flw/offoJ/Ve/ZTep5/W+/UzvpZSvmWopc9zub5Cb9JX6s36Kr1Fb9Xb9NV/l+e/vo8fPZc6avTc
CG+QCDkeh+8ln6PcUTkaH3VOkVJYVCEluQZvwHrhDWaTX9/y6OtISwexyYf6GgmvRXyzDyW+2b/5
ogL6+jT1+jSVSUm5n8Qqj4J6o75Mr9Pr9Tl6gz5Xn6fP1xfoC/VF+mJ9ib7UW6WgMaFOSt+kb6as
vlPfKWNpJWPicrq97qg76666h+6l++r+epQercfosXqcztXj9QQ9UU/6rXb3ddHtvIco3UF38GuP
dSe5fxfdRUrZXXcno3vqnhToProPWd1P9yMn7TmSQuGsOVL/5Ont5OpOclV3yd1Hcg3Sg/UQPVQP
08P1SXqEPlmP/C1OxNPb++/fS+n97qfOurM8vavuKk/voXvI03vpXvL0vrqvPL2/7i9PHyXcFIIO
vz69vTy9szy9hzy9728+/Tfo4a0oKXdHeXoXeaKSsveSJ/aTp1gp7TKxrJP7Sx6fw5/3Z49VpnD/
dqhdJ9SrO2rUB3XxMiH3Dyqo9dJrOQ454pgznOUcLsAFuRAX5iJclItxcS7BJbkUl+YyXJbLcXmu
wBXFPqnMVfg4rsrVuDrX4Jpci48Xe6UO1+V6XJ8biNXSSGyWJtyUm3FzbsEtuRW3FvulLbfj9tyB
O4oV05m7cFfuxt25B/fkXtxbbJq+3I/7i1VzAg8Uq2YQD+YhPJSH8XA+iUfwyTySR/FosXTGip2T
y+N5Ak/kSTxZ7J2pPI2ni8Uzk2fxbJ7Dc3kez+cFvFDsn8W8hJfyMl7Op/CpfBqv4JW8ik/n1Xwr
f85f8Jf8NzVeTVAT1SQ1WU1RU9U0NV3NUDPVLDVbzVFz1Tw1Xy1QC9UitVgtUUvVMrGeTlGnqtPU
CrVSrVKnq9VqnTqivlHfqu/U9+oH9aP6SRQ2a6W1NjrQVjsd6kjHOqOzOkcX0AV1IV1YF9FFdTFd
XJfQJcV6Kq3L6LK6nLegdEWxoCp7+0lX1dV0dbGhaupa+nhd23Q13Ux308P0NL1Mb9PH9DX9TH8z
wJxgBpoTzSAz2AwxQ80wM9ycZEaYk81IM8qMNmPMWDNOrKzxZoKZaCaZyWaKmSr21nQzw8w0s8xs
M8fMNQvNcnubvd3eYe+0d9m77Xa7w+60u+w99l57n/2D/aO93z5gH7QP2YftbvuIfdQ+Zh+3T9g9
9km71z5l99mn7X77jH1Wfs/L70X5vWxfsa/a1+zr9g37pn3Lvm3/ZN+xf/b2lH3f21P2Q/kdsh/J
7xOxqT6zf7Gf2y/sYftX+6X9m/3Kfm2P2G/st2JpfW9/sD/anxyJpaWcdsYFzjrnQhe52GVc1uW4
Aq6gK+QKuyJih5VypV0ZV9aVc+VdBVfRVXKVXRV3nKvqqrnqroar6Wq5411tsdXqunquvmvgGrpG
rrFr4pq6Zq65a+FaulautWvj2rp2rr3r4Dq6Tq6z6+K6um6uu+vheoqF19v1cX1dP9ffDXAnuIHu
RDfIDXZD3FA3zA13J7kR7mQ30o1y490EN9FNcpPdFDfVTXPT3QxX1BVzxV0JN9qNcWPdOJfrXnWv
udfdG+5N95a3Fd077s/uXfeee9994A6Eb4Rvhm+Fb4d/Ct8J/xy+G74Xvh8eCD8MD4aHwo/Cj8NP
wk/Dz8K/hJ+H34bfhd+HP4Q/hj9FFLGoSx2ZKIhs5KIwiqI4ykQ5UYGoYFQoKhwViYpGxaLiUcWo
UlQ5qhIdF1WNqkXVo+Oj2lHdqF5UP2oQNYwaRY2jJlHTqFnUImobtYvaRx2ijlGnqEvUNeoWdY96
RD2jXlHvqE/UN+oX9Y9OiAZGJ0aDosHRkGhoNCwaHjeLm8ct4pZxq7h13CZuG7eL28cd4o5xp7hz
3CXuGneLu8c94p5xr7h33CfuG/eL+8cDxC4dGJ8YD4oHx0Piod4+jU8S+/RksU5HxaPjMWKfjotz
4/FioU6MJ8WT4ynx1HiaWKoz4pnxrHh2PCeeG8+L58cL4oXxonhxvCT7dfZI9pvst9nvst9nf8j+
mP0ph3I4R+eYnCCnrbdukzksvoVvodP4M/4LreDD/FdahVkt7z92LV2Lua3rMLf1Oua2QrPELOEI
c1uxnznkh+0mu4Ufw0zWXm/182thEFbkz8Ja4TAVYT6rZfa17HvqlOwH2Q/VGsxnrRMdfabo7iIy
OqhOPWQsutyvIQo/wDoMOYqyv6wMKUQlqFxUQ+JXRTK+cVuiWoJbozq/5G0uR+vEVs7K/UpRBaoa
tfQpkYzu3EVRa8FLojaCG6POv1wzAEcyfpD6lpPBSBVVxe/cUVVlVFJHyYhW1Vf1ZWzQWDWWO7OM
me3Pd6c6MtJRojdkVC16JQMUK8EfS+hjhdNYYT++oEPyI97KW71nP75WctzEN5M5hrv2TO/T81+4
qwomqzv/TvP9b+i9/yWt9/+TtlPf/M/qO/ucfcG+ZA/aj10Geu8u0Xj3QhM94ELRN17LPSYazuu2
RLM9f4w67dA/0WV/r8mc6LBftdfPmuH/NS32q6YaL7o3OlqbydjhTowa/IjBjxfut390E5Lxgpsk
o4XH7R6X9WMFl2OfFi6cLNw3w3PczzpPLc6r76LcaHw0IZoYTYomR1OiqdG0aEG0MFoULY6WREuj
ZdHy6JTorGhNdHa0NloXrY/OiTZE5/6mlvzgd+jJ7DFoyhpRzagW9GWd39SYzUVntoxaRa2jNnl0
Z+d/qD0H/Jv0Z17tOeDfoT/tTjfxn+rQdnQ6+W+MrafHxeLYQ3upM+2jF6kbvUwHqT99zAGNg4Y9
RbVV7ehU1UF1pRWquxpAZ6qBahCdp4aokXShGq3G0hUqV+XSZtj3V6lH1Ne0xZQ0Xegls8AsYB2M
CkaxCcYEYzgIxgXj2AYLggXsvPXPYXA4+Er08pHgCBcIvg1+4ILBT1ZxUWus45I2ssW4rC1hK3AN
W8k24Aa2kW3FHa38uJftYrtxb9vD9uJ+otPH8gk2107hCXaaaPbp9mp7A2+zN9lb+AY3083hm908
t4Bvd4vcYr7LLXUrebs73a3hP7rd7hHe7R5ze/hRt9e9yHv8e0B+wf1VRgUvhiVlVPBWOCAcxgfC
ceEi/ku4LLxEBeHl4R9U5fDB8BXVOTocN1Unx6fGp6otmS6ZLmpr9mD2sNqW/TL7lbo1p01OG3UH
5giUWHIFsNptHT2RpvTMk7KHxpqVZpU53aw2Z5gzzVlmjTnbrDXrzHpzjtlgzjXnmfPNBeZCc5G5
2FxiLjUbzWXmcj6Dz+SzeA2fzWt5Ha/nc3gDn8vn8fl8AV/IF/HFfAlfyhv5Mr6cr+BNfCVv1mfr
tXq5PkWfqk/TK/RKvUqfrlfrM35X2pn6LL0G8xsGeytOp01UBjMVTcTCXUbNMFMxCjMVYyRfKyrz
3ym7n4/BvZO5mjJHzdX496JKRkTT/RtP1UQ1lVFSSyVjKq8vZWQkupKsO+g+otB94j6nTGhDR4XC
KJRxWNgsbE4lwpZhGyoVtg87Uznpsd6mytJfvU9VfY9EtcIfI6bavheh+tKLNKOGvu+gptJ3dKbm
f1eepihPfbXIz01JeZqhPC1lpNZGRqxGSnUqBVKqlRSKBl9NEcoWo2w5KFsRlK1YWCAsJKUqEpag
sihnJZSzStg97EnVw95hfymbL209lLYhStsMpW0hfWdAbaTnzFJ7lLwrSt5deree1Fv6tgHUL31X
20f+30HJm6EuX2G8R7+k+CMZz8rorMgvaUpGXnXo530nPk1RKalr85T2BnW1UtfTyKEFMqhrjrvX
3UsFxJ56mwrKKPwwFXJfuu+E6oHUsmpYKqwoNaglNWsXnhAOowmiQT6kGaIrPqel4bdSm1XS/xen
i6XXb0lXSjsMoHukbx5O+0U/TaOXRSedQm+LHjqXDqSj5jZSpvHy7Mp+7E+dvDVHJ/h32XRi+Ea0
kfYfcz4/96f/h3L/2hbjQNGErwYc1RbNf20LGiR9+s9pSvrx449qi+Z+Pb77PjREYaWwJkXhcHmO
nynTSUlQhsp4eoO0lD9jP/RR5SDPWYzVr5GxuozY/fylPKEMVRI7qA5vkRyr2c/DrvW5aB1f71f0
8o2C5/graAP6uDUy6v91hc0olK+FpGexhoXoI/mx1wak7Fg7lrTdareScXPcHArcArdAJHelW0ku
vjK+ksJ4S7yFonhHvIPi+P74fhLrg2qna2PW4pn3i46z0HGFRMc9S0XpXfmVEm44QKU5EE1XxtQ2
dagsVqeUx+qUSqKJvqXKwQ/Bj1TFZmyGqtoCtgBVs2VtWapuK9qKVMPWsDWppq1ta9Px/v011cZK
lTpYo1IXa1TqYY1KA3uiHUxN7Hg7hZqLbppLbe0qu+r/sPctYFVVW9t77b027Pv9fr9vJMOtmLfU
Y4jK8XjXjIg8hmRIqISkJkaICkaKYAiIqEQe85iZmSmaehQVlJDUjJS8kJmZmamZmZl9c757+aWd
znO+/3v+7z///z+H9TzvHHvMMccc87LmmnOzx1i8AeQEWs0biF+wDMIvWBLwe5XB+L3KnyQLJYt4
QyR/lazjDcNvSEZItkrqeCMleyT7eKPx65HHpLHSWF6idJB0EO9x/GIkCb8SSUaPCvh/4A/kP4px
7kue4jz+APIUZ/hjyPObfoG9lsy425E/R96J/EXEEzEivkggYskMcYs8Iq/IJ/KLAqKgKIrMliTR
E6Jk0ZOicaI/i8aLnhJdFV0TfSe6LvpedEP0g+im6EexQWwUm8RmsUVsFdvEdrFDnCR+QpwsflI8
Tvxn8XjxU+IUcYZ4sniKeKo4U/ycOEs8TZwtzhW/JM4TzxHni+eK54nniwvEJeJS8RLxq+Iy8VJx
ubiC3Al8sh6S5zCZu+Q5TOYueQ6T9fACuf+tZO+nJ2fmkeRuf5DsR5/ldSN70BfJ+lZI7vaE8NOV
nPtnY+blMfkcZxb74j2cf95PtEwOm3tPGRU5WTeyL0W+HJEe+cJ/yROC6IjoGzHont+5V/P+xLzD
vMdsY3Yy9UwD08S0MEeZVqZN0EnwieCE4FPBKcEZwWeCzwVfCL5kq9mVbA1by65m17Br2XXsenYT
28oeZ9vYk+xptp39gv2S/Yq9zF5hr7E32VvsHaFUKBcqhWqhVqgXGoVmoVVoFzqFbqFX6BcGhdHC
jsIYYUjYRdhV2E3YU9Yka5a1yA7LjsqO/ft31f+f/K5awWPJ8iYQRghF/+Q3jGQ+swfYJraZbcEv
SP7ZL8mY4BX2iHiteIN4s3i7eLe4QdwsPio+Lm4XnxdfEl8T3xTfkbASiUQlMUhsEo8kShIj6UpO
Rv3IKWgIOfMkktNNKjnJZJJTy2xJvmSBpFhSJqkiq/kayXqy1tVJdkn2SZokhyWtkpOSs5ILksuS
65JbUh5ZimVSjdQkdUh90mhpSNpN2lsaJ02QDpOOkSZJx0snSjOkWdKZ0lzpPGmRtERaLq2W1krX
SjdIN0u3S3dLG6Qt0mPSNmm79Lz0kvSa9Kb0joyVSWQqmUFmk3lkUbIYWVdZL1k/2UDZENkoWaJs
nCxVli7LlE2XzZblyxbIimVlsipZjWyNbL1sk6xOtku2j9w9h2WtspOys2TXf5ns+W+R81aEXCbX
yE1yh9wnj5aH5N3IKSBOniAfJh8jT5KPl0+UZ8iz5DPlufJ58iJ5ibxcXi2vla+Tb5Rvke+Q18sP
yFvkx+Rt8nb5efkl+TX5TfkdBauQKFQKg8Km8CiiFDGKropein6KgYohilGKRMU4RaoiXZGpmK6Y
rchXLFAUK8oUVYoaxRrFesUmRZ1il2KfoklxWNGqOKk4q7iguKy4rril5CkjlDKlRmlSOpQ+ZbQy
pOym7K2MUyYohynHKJOU45UTlRnKLOVMZa5ynrJIWaIsV1Yra5VrlRuUm5XblbuVDcpm5VHlceVp
5TnlReUV5Q3lbRVfJVIpVDqVReVSBVQdVV1UPVR9VfGqwaoRqrGqZFWKKk01RZWtmqXKUxWoFqqW
qCpVK1VrVOtVm1R1ql2qBlWz6qjquOq06pzqouqK6qbqjppVS9QqtUFtU3vUUeqQupu6tzpOnaAe
ph6jTlKPV09UZ6iz1DPVuep56iJ1ibpcXa2uVa9Vb1BvUe9Q16sPqFvUreqT6rPqC+rL6uvqWxry
INEoNDqNRePSBDQdNV00PTT9NAM1QzSjNImacZpUTbomUzNdM1uTr1mgKdaUaao0NZo1mvWaTZo6
zS5Ng6ZZc1RzXHNac15zSXNNc1NzR8tqJVqV1qR1aH3aaG1I203bWxunTdCO0I7VJmtTtGnaKdps
7SxtnrZAu1C7RFupXaldrV2n3ajdot2hrdc2aY9q27RntRe117Q3tXd0rE6iU+kMOpvOo4vSxei6
6nrp+ukG6oboRukSdeN0qbp0XaZupi5PV6Ar1pXpqnQ1ujW69bpNujrdLt0+XZPusO64rl13XndJ
d013U3dHz+olepXeoLfpffpofUjfTd9bH68frB+hH6tP1qfo0/RT9Nn6Wfp8fZF+ib5KX6Nfo1+v
36Tfrt+tb9A364/pT+rP6S/qr+hv6G8b+AaRQWEwGBwGnyHaEDJ0M/Q2xBkSDMMMYwxJhvGGiYYM
Q5ZhliHfUGRYYqgy1BrWGjYYNhu2G3YbGgzNhqOG44bThnOGi4YrhhuG20a+UWRUGHVGi9FlDBhj
jN2MvY3xxsHGEcaxxmRjijHNOMWYbZxlzDcWGUuM5cZqY61xrXGDcbNxu3G3scHYbDxmbDO2G88b
LxmvG2+ZeKYIk8ykMZlMDpPPFG3qYuplijMNNo0wjTUlm1JM6aZM03TTbNM800LTElOlaaVptWmd
aaNpi2mXqcHUbDpqOm46bTpnumi6Yrphum3mm0VmhVlntphd5oC5o7mLuYe5rznePMQ8xpxsTjVn
mLPNs8x55gLzQvMSc6V5pXm1eZ15o3mLeYe53nzA3GI+Zm4zt5vPmy+Zr5lvWfgWkUVlMVhsFo8l
yhJj6WrpZelnGWgZYhllSbKkWNIsUyzZllmWPEuBZaFliaXSstKyxrLesslSZ9llabA0W45ajltO
W85ZLlquWG5YbltZq8yqs9qsHmuUNcba1drbGmdNsA6zjrWOs6Za062Z1unW2dZ86wJribXSutK6
2rrOutG6xbrDWm89YG2xHrO2Wdut562XrNesN613bKxNYlPZDDabzWOLssXYutp62frZBtqG2EbZ
Em3jbBNtU2zTbbm2Aluxrdy20rbats620bbFtsNWbztga7Eds7XZ2m3nbZds12w3bXfsrF1iV9kN
dpvdY4+yx9i72nvZ+9kT7CPsifbx9jR7pn2mPc9eYF9oX2KvtK+0r7avs2+0b7HvsNfbD9hb7Mfs
bfZ2+3n7Jfs1+037HQfrkDhUDoPD5vA4ohwxjq6OXo5+joGOIY5RjkTHOEeqI92R6ZjumO3Idyxw
FDvKHFWOGsdax0ZHnWO344DjsOO4o91x3nHJcc1x03HHyTolTpXT4LQ5Pc4oZ4yzq7OXs59zoHOI
c5Qz0TnOmerMcGY7ZzvnORc6y5zVztXO9c7Nzh3OeucBZ4vzmLPN2e4877zkvOa86bzjYl0Sl8pl
cNlcHleUK8bV1dXL1c810DXENcqV6BrnSnWluzJd012zXfmuBa5iV5mrylXjWuNa79rkqnPtcu1z
NbkOu1pdJ11nXRdcl13XXbfcPHeEW+bWuE1uh9vnjnaH3N3cvd1x7gT3MPcYd5J7vHuiO8Od5Z7p
znXPcxe5S9zl7mp3rXute4N7s3uHe5+72X3MfdJ9zn3Jfd1928N6ZB6Nx+RxeHyeaE/I083T2xPn
SfAM84zxJHnGe9I8mZ6ZnjzPAk+Jp9JT41njWe/Z5Knz7PLs8zR5DntaPSc9Zz0XPJc91z23vDxv
hFfm1XhNXofX5432hrzdvL29cd4E7whvone8N82b6Z3pzfMu8BZ7y7xV3hrvGu967yZvnXeXd5+3
yXvY2+o96T3rveC97L3uve3j+0Q+hU/ns/hcvoCvo6+Lr4evry/eN9g3wjfWl+xL8aX5pviyfbN8
eb4C30LfEl+lb6VvtW+db6Nvi2+Hr953wNfiO+Zr87X7zvsu+a77bvtZv8yv89v8Pn9Hfxd/D39f
f7x/sH+Ef6w/2Z/iT/dn+Wf58/1F/iX+Kn+tf61/g3+zf7t/t7/B3+w/6j/ub/df8F/x3wzwAqKA
KmAKOAK+QHQgFOgW6B2ICyQEhgXGBsYFJgamBKYHcgMFgeJAWaAqUBNYE1gf2BSoC+wK7As0BQ4H
WgMnA2cDFwKXA9cDt4L0UCkLaoKmoCPoC0YHQ8Fuwd7BuGBCcFhwTDApOD44MZgRzArODOYG5wWL
giXB8mB1sDa4NrghuDm4Pbg72BBsDh4NHg+eDp4LXqS7PuYd4HvAbcB6YAOwCdgCPEr2ggQhGwWM
4HAbcCewDZ7jlBZBtwgyIsiIOH4DsAnYAqSlJJCRgCPhOGcISsGXQZsM2mQcpx7YAGwCtgBpWTlk
FNCgRCklaDVoNSxRQ4MafA30a5CrQVkNcjXQr4F+DfRrmFaCT0JSz+FOINVjAMcADQbwDeAbQRtB
m1CXCZImSJpQlwl1mVCXCXWZSK9TpDVaUMqCUhaUskDeBr4NfBv4NvDt4NhRrx19MpfZCNwMrAPu
Ae4HHgQeAh4ho00Qsm8A53NYB9wBPEGwEFoLkVuI3ELkFkJrIbQWQmsh5F+GzMvgvBzmsPTboCLY
3ghtjdDWCMlG2NgIbY3Q1kjLRvRF7iL0aDHaWgy6BGVLYEMJypaAXwrNpcgtRdlS5JZCcyk0l8Kq
UnJO5fNOQ7KMwx1AqmcpOEuhYSn4S8EvB1aglgrIVECmArVUoJYK1FKBWipIH1OkdS1DqWUotQyl
lkF+OfjLwV8O/nLwq8GpRu3VtA+ZCCpJcDOwDrgHuB94EHgISMaWImSjgSIO64A7gFSrGLQEuiWQ
kUBGwvH3Aw8CDwFP4JvfOuAhYJhD+oaRg6+ANgW0KTjOHuB+4EHgISAtq4SMChrUKIU7ltGC1sIS
LTRowddBvw65OpTVIVcH/Tro10G/jvY982dIGjncATyDXyxsBtYBdwAp3wzaDNqCuiyQtEDSgros
qMuCuiyoy0JHmyCt0YZSNpSyoZQN8g7wHeA7wHeA7wTHiXqdtE/4PnqH8zsBY/kFBPsA44DxwEFh
pBoIvYDgUHBGhxH80eAngpMKTAOmAzPCCMks0DPCCE4O6AoacYW/hN5//DK6EhGkVm0BVoCzDLm1
kPxAEEOwgbaIf4C2l+D+u/c3/wNwDiG3lUoKeJD/iZt7G+/OOoETyKMcAZ/mCqRUkscKLgA/AZ4A
fgo8BTyDp9g2Tuoz4OfAL4BfIr8F+SIOqS4RVmgRNIqgUQSNImgUcRplkJWB1nD4CfAE8FPgKSAt
pwmXY/EkJfgORVqC0PWgqQ4Th5SvgKQCkgqOUw+aytg4/ARPAWrxXHDmClqBx4F4FghOAk9jna/j
pNqBZ4HngOeRfwj5hRy2Yi3fA/o4sA14Ekg1FnIaGyH7CuhSDluBx4FtwJNAWq40XI7tSkeU4EaK
tASh94CmOio4pPzekOwNyd4cZw9oKrOcw1asnFgPKYdgK/A4sA14Engaa2MdJ9UOPAs8BzyPfPQH
I+GwFbNyD+jjwDbgSSDVKOE0KiCLsWJ0HLYCjwPbgCeBtJyO648UtDIFrUxBK1PQyhTosHBI+emQ
TIdkOsfZA5rKODhsxdpCR5DF/kAG1ABNBAV0L0L2IeH0PS69y38H90g4n2XasF+JAkqgQUFR+Bzl
CJPAkXC7Luw22VrgGnr3gBaBloGWgdaA1oDWg9aDNoE2gZZCM6kf91HYGrJn43ZqYW7YNlt4H8u+
T1CInZAQ80LI7iMYA9siwztX8CPBj8TzPJLdjfu7Ca2mKfazhEtxL2nhIuzUxNyOtQmWUVoKXVLs
xaTsHrRtL9EhQ4/SXgJCSoEalYQWkH1qE3jKMA81qSCrgl4VctWg1WEakmpYSnvgPS5tQBq2XMNZ
ruWQltaHEbUShO166DIgx4AcQkMjTXeGU9RqhIwxTKOUEbaa2O3AvcDdmDP13BxqQm+YsTKZUdIC
LZjBPCtoK7erpbQde0I7cu2oYy72PI3AUmAF/c8D3V+Rp2043cyld/kbsYYdJE+McErX4jewE3sZ
GhbRmRRhoxz6ew/sLXcgN7yTxK6ZfQ1I/3tZCLoQdCPoRtCloEtBl4EuA10BugJ0EWbtXGIDXe3C
NpN9KLf7DHNP4NPy8H4cs3YeemAeeuAtWFUATgE4BZipBehrst9Ge2mKHTnGpJCORsRD2HcuoD0r
OIz+fRl1FEFXEfq9CDP1FYxeI+ZrI3qU9hKdOYsguwj1FmN+FHMzpzjMQ32LUWIxenoxSpSALgnT
kCyBvbTtm7l0P9KNXJ+E7V/CIS1dFkbUSpBpRA9TXUuRsxQ5ZE+OfiSfGPocLEdeOWouh3Q5bKzA
PK1ASytgSwVnSwXmCp9XiRWyEiWXQcsy0FWgq7gdOqWrsTevRm416igK1wSZZdjpLwfOZX8geJH2
PpvH4MmDfZ0CqANa8L80S3h20N0l7Rl8vsvfiKdQOD8iPF/ITv4gdto7sFums/gc5UQcAkfG7ZZx
SqDzkSD9f70EtAS0ArQCtA60DrQRtBG0BbQFtByaI2hv0901rNGF5zJJw9ywbY7w+YPOZSYSu3qs
tAxWWiYE28ThEwf4YvDF2GOL6djQUwZaLQnPC2LxbiAZvUgedthS7qRxEJZRWg5dcuyh5SzOGHRG
05MGdKjCCCkVaqTrqYAinVuMOsxDTRrIaqAXOzvSl5TWhmlIamGpLjyLkO5HupHrmc2wTQ9NepQ2
hhG1GpmD0IW1lJw1aI4JOabwjKY8SJiRZw7TkDbDRgud0QT3AndjroRtsYRnNGPFLsWKkjZowY6R
sYO2c6eQEzhn0POHE7lO1CEP1wQZG04zDmAEZnQjleR3wpkgfC6596xgi3wFWAYsB1YCFwGrgNXA
lcDFwFKKdHUh2ALOJvqrlMhNRF84LePSci6t5NJFXFrFpdVcSrRH3qbWECwDlgMrgYuAVcBqILXG
BetdsN4F612w2wW7XbDbBYtdsNgDeQ/kPZD3oLUelPKglAelPNDvQVkPV5a20MO10MO10MO10MO1
0MO10MO10MO10BNuoQgWi2CxCBYTrAQuAlYBq4HUAh8s9sFiHyz2wWIfLPbBYh8s9nHyi4GlOIs2
Aen4RENPNPREQ080NERDQzQ0RKNsNMp2RG4nDquA1cCVwMXAUsypJiCtJRa1xKKWWNQSC2tjoScW
emKhJxZ6YqEnFnpi0b+xXP/Gcv0by/VvLNe/sVz/xnL9G8v1byzXv4+jfx9H/z6O/n0c/fs4+vdx
9O/j6N/HYUGfyCLgq8ClwArgQuAy4HLgCmAxsAS4hCJdOwgeAoe2oQ+iKtD0VS5dyqUVXLqQS5dx
6XIuXcGlxVxawqVLSMrnx8HWONgaB1vjYGUcrIyDlXGwLw72xUM+HvLxkI9H2+JRKh6l4lEqHm2L
R9l4rixpm6iYaiD4KnApsAK4ELgMuBy4AlgMLAHS3hkEGwbBhkGwYRBsGAQbBsGGQbBhEGwYRKO1
EqwBvgYsBpYAoRM9Pgg9PhT6h0L/UOgfCs1DoXkoNA+FhqHQMBzywyEzGvRolB2NsqNh22gudxlw
OXAFcBWwBvgasBhYAqS2jYZto2FbIvQnQn8i9CdCfyL0J0J/IvQnQn8itCVCWyK0JWL8E7n5lMjN
p0RuPiVy8ymRm0+J3HxK5OZTIjefErn5lMjNp0RuPqXCvlTYlwr7UmFfKuxLhX2psC8V9qXCvlTY
lwr7UtHaVLQ2FbpTOVtTOVtTOVtTOVtTOVtTOVtTOVtTYStfdBUz7ipm3FXMuKuYcVcx465ixl3F
jLsKm9LQhjS0IQ1tSIP1abA+Ddanwe402J0O+XTIp0M+HW1OR6l0lEpHqXToT0fZdK7sEiC1N51r
ZzrXznSunelcO9O5dqZz7Uzn2pkebqfYQO0g+CpwKbACuBC4DLgcSO3IgN0ZsDsDdmfA7gzYnQG7
M2B3Bie/ClhD6sxg9sPyDLQlA23JCHMwfhkYvyzUkIUaslBDFnRnQXcWdGdBQxY0ZEM+GzIzQM9A
2RkoOwPWzeBylwGXA1cAi4ElQGrJDFgyA5bkQFsOtOVAWw605UBbDrTlQFsOtOVAWw605UBbDvo6
hxujHG6McrgxyuHGKIcboxxujHK4McrhxigJY5SEMUrCGCVhjJIwRkkYoySMURLsuLsHeoVLy7i0
nEsruXQRl1ZxaTWXrkStGfQJRrAMWA6sBC4CVgGrgeE9Snhf8gqXlnFpOZdWcukiLq3i0mouDdea
i1pzUWsuas1FrbmoNRe15qLWXO7JHX5av8KlZVxazqWVXLqIS6u4tJpLw7WWoNYS1FqCWktQawlq
LUGtJai1BLUuxTfVi8OIvWwZpcXHQC8FlnPfbzcBKb0CuAe4HliL3FqObiW4BvQ64EF8s703jNgl
H6C0xAQa+3V+E/et+EEgpY8Avwe2A1uR28rRHxNsA30aeAf6b4YRnJ9RS3I4F/gL9136QSCl8V8j
QTRQD5QiV8rRpBaBErQWJ9x/R2z7d8S2f0ds+5+K2CbiMeFIMvx/FuPmbgQaCbmre/Dz7vF0opyH
+XN/9TVizvIu8218F99DJKIJL5afyk/jp/Mz+Fnk7J4TWRd5ivqQ/94V+d39F9Fy/+X5+0tkvP+i
Pum/e0X/5upIPdbvu2L//hKNuP8ibfkHl+jC/Rdp8/1X+u9dYvn9F+ml+688XL9+zvrNlU2uGf/g
yvm9SzzyN9eE31zP/+YqvP/i/d/oYcXwTvOsvN68OF4CeQrQdxD++v7BXLJeF/FKeOW8al4tWfU3
8DbztvN28xrICn+Ud5zufBDF4H8VPf8tjP3v4D/wo3LwZILDbJ7wx4iUiNrIrMjpkfmSlZLXJFsk
u3j/O32bwv5cMpI4mACPvm+Xx6ykb+WET9Z65m36Fm363yBmE/MuoWkESAGzhdkKL45thN7OvE9o
Gg1SwOxidhOaxoQUMHsZ+v4UGhlSwDQyB/A+kCZCf8A0E5pGiRQwHzKHCU1jRQqYj5hj9J3oZM8j
YD6hcfkRN1LAfMp8St8rz5wk9CnmFKFPM+2E/ow/n6xuNJKkgF/ILyQ0jScp4L8soO8MplElBYKQ
4Ch9vzL9RpQ84aroO93Zr3kC9hJ7idA0zqRA+HDkyzwmvB+PfFdG7ETMSYHsY3kfHt7lgx7i8zZx
b5Sh8d/5nB/Le1w8zDpC01jwYZ8WBhHh+fBsYRAXns+9EYVGh+fDy4VBjPjw21EYRIrnw+OFQbx4
PvxeGESN58P7hUHseD7XDzSKpgDvpAj3QLjtDDxkGEEnuvOEnwxDo8ATmnrLMDQWPKGpzwxDI8IT
mnrOMDQuPKGp/wxDo8MTmnrRMDRGPKGpLw1DI8UTmnrUMDRePKGpXw1Do8YT+gLtYfjYMDRSPI8P
TxuGxosnNPW3YWjUeEJTrxuGxo4nNPW9YWgEeUJTDxyGxpEn9Fp2LUHqh8PQaPKEpt44DI0pT+i3
2I2kLuqZw9D48oTzLkvmGHuEJaMGXx2GxpQnfOqxw9DI8oSmfjsMjS9PaOq9w9Ao84SmPjwMjTVP
aOrJw9CI84T+jP2caKNePQyNPk841LeHoTHoCU09fBgaiZ7QFzGjqLcPQ6PSEw71+WFobHpCU88f
hkaoJ/R37A0iSb2AGBqtnnCoLxBDY9YT+if2NsmlfkEMjV/P48M7iKHR6glNfYQYGrOe0NRTiKGR
6wlN/YUYGr+e0NRriKFR7AlNfYcYGsue0NSDiKER7QlN/YgYGtee0NSbiKHR7QlNfYoYGuOeRgsT
OgjtFDoJTf2LGBrvntDUy4ihUe8JTX2NGBr7ntDU44ihEfAJHSWMIvcU9T5iaDR8wqE+SAyNiU9o
6onE0Mj4hKb+SAyNj09o6pXE0Cj5hKa+SQyNlU9o6qHE0Ij5hO4u7E40U28lhkbPJ5xe9P7FG0MY
vDGEwRtDGLwxhMEbQxi8MYTBG0MYvDGEwRtDGLwxhMEbQxi8MYSJ3ERXAPhBMTQuPI8PbyiGRocn
NPWJYmiMeEJTzyiGRoonNPWPYmi8eEJTLymGRo3n0VB+PHi8cu9GNKaSVAcuz5gcyjcmRoijCxIK
fpAzkfyafOMfCWsAn2E6S0PiCOEDCgHfIuSFnoqQPBDBsEx+dz65f0aHRoY63sOx1TrybOTBSK/h
vBRyCJpKHotPkwPO0+Q4RK6Q+x5lrO77MZ0iKt/O6vV0fvKIfGv11IUNRyQ1+ZrOoXx2fChfMKRG
wGf4fEnMm+qTI35JXvHB7rul7cSUzM4PhDpECB5lpVpP/6mZL2RNeiYt2xU1oYOrc8+e3V1DJ03I
mjpt6sRsV/+pWZkxnR0hW1hYf3/O1KynsidNndLZHXLSfIHW9Gv+qKlTs12PPJ+dNjVrUvYLIYdR
Huoe6tGF/MV2DnVJMso7dyEfHyJM8pcUegF9RZREaPmPju6sDanpB5FW8thT09ImTXkmm1SjCiko
M1IbOerp1MlTp6TeNUzyjwzzhtxhwyz35qc+7Ro96ZkpRKtrRP9HQvmMJyT/zwFkGCFPkM8oeYQv
4eczDG/rCy+2PvnugJ5ru67v3Paj/6E/ztj9k3Nl44Dnvj0y8MKxhXufHTIq5foy/t6hx/+Y0cnX
9+m/tXi3ShO2vvT8qQE71y1WjNjvf+BazZdyr/PII75bKcs+NA/4y6uDncsOvdvJs3fwg7OnntA7
Hl7YU9Xz1M4O1yc+/CDT5Zc7wYQ172UwhdU/bd804aX8H5Nr5sybX7zxWl3Z6x/2WDNivjFYOOxU
6Aavz/WGH/vM2VXwTUbPN2K63tgc87bkxZTSmROrK6fJC96+tu8717bhmkUTPuh4ossA8+X3B5c/
PGK0qWXiyBfWvVV4YGzfVfkjFkwRvvPQnhzfzlET+ywb1vxAbuyUeYMijqw8PLiAP6WAt3p34ZnR
fAGZ+K/PuRWa80NIS7rT7mdlIUmEiExdoTCSPJbn1FIuw86pCs2pyFM9cTjz20lZK70jc3Wbhhb/
8sFrWf/n51u+kreH90rv3gvUR/remHDpTL+QktqoZZhfWGGInKB/CdkpQ8EaWF2zvWU6L/OJt6+2
7RtWNTI+5vX4CVdCUpqtZFlyGxXcc+sI6IzIeXND7uDAtZYdw7JrE4PZ0c+/W/Dzm0PKZvKGftX0
tenkpP2K2tnf8fs3NBU23xzdXL9q59ipVybE/zWed7n8QNXHtjrpKrO87JM2x1sdXvz2mzXT1i8+
3bO4T2X6jh6Tjy542/vzma9aJ4lLF+y88xnv/a7f/TD7R5UmRvh1h/JX456Nem5rj8XtkfKDT6Yd
2pn3yLMT176/9f3irk3XBKrZs74/2h53JufOZ5+tv3PjzMfydzNbl3w+fEuP2tkPHuvzaVdpSnf+
qjnp3pdvJE9YvDHp/Z6fjF/46DxL7PcPV9bky2r//Mq7Hbe+9pcP3mxzbflbyDzfpZNH7xh1/ZH2
caHPl0RNKtyTefa7N95syYvLmq4ga8wsssakcGvMUxHBOVgLRffeR0KyzvwL72q64PQgK02XLp27
dH3oIbrghEKd6cdY+jE0Z+7/iG1yTBwyddmhw0eMuisu+Afi/3Tt2Zm1+eUvbavmN2bXjU8WdOtT
/fOyWVUdBno2vlE4+pvLA3s1PiGUPrZ2a5Ow+aMhMwZlzn/3iw/OPPPl6z9nB199ZtUnRYL4UMMP
B7cf7GUXjY0fbhTJf9xsTlvns/0kfGz+V/uHRbq7v/F1S8dOW+IOuYVvtJ7/KOqxRuuslg7dIg+t
fLT5/auer9d6V8s71P90eG9S3wl9Gjv+UZrzwvwrC759bmf/pM9ff1f+3aM/+dvPuj76smpc2V9i
H4x66THro+myLvHfTsyYeqVH9bf8t6peO1UZqVL0Nk06+8Kwgbr2bQsPPz+5ej2v+sG470fWJV2f
OWDuVzGzH3j/yUPmp6LeKusv2Z8e98t7XTas7uA5bbjwEbf23AzN+f73155f72LvkWnRQ3b+9IX7
1nOOZfojxh/3rSnC8NmV9K4nN3JkHtYNu5c1hQx5v3/bx1MBJ9sn9HCoZ033mocKYtOyszN7deo0
ISsjZvLdMYyZMHVyp8xnJ1Fup8ysqanPT8ie1qn/aDLxYggrlHDXQoZhe4d6hXrc/RziF3TkFM6Y
MeP3FD6ddY+m7N/cUFh9+nf4cMLOjM+nTd677JPJsgUPNyRMm+Vv6Xi2e86Krqt2elt2nTme/IL6
We1IFzNhW9YPos8bXhwZbYg6duTL5dEfmuRHtc+Vdrg0duePrfvlnd5++sHJQwd0GJs1b/gfjqbb
H0n56wvJxVcaZxR9wI+KWdFY/cAX26LFpy5VnP1i1qJxqgWjXzs1fviMyufGr32iZ+lHb2qcwq/2
DvjrR/Ujt71dd/J2xDze9ezXP/2l2V7jFUaeCz5UX1FiXpc/Pnjhp3kPOI6wHxR/mC//ZO3Q/v2e
P3r61Ixvi5KfVRamLt68fev2N58Z4x6wbnDal2PGvaJLfmbmpZJkgapUtMLnqrhwhqfO/OuPm7Iy
t244W7/KwCerzwqy+swPrz6qdOmy4bt5/jfVnw5wJs56pva3a9C/Zq/TLdSzc7dQ51DXrt3p0tOT
fPwX7HXGTJr89LTspyZn/lf3Oie7T/np7QNxg58zHWhJ6Dt69603dds7dnlfM3zUgbnf9I098cfO
S6K2lKa2O0fM217/pyMvCW9++/yuVxrXfrxhUubEmcGJF7Zs/Xb+tkOX1/2sWS193NOh04f9Toxl
rdPfm5w6efCYT09dPf23VXMb8868NITfvez73StFYx1pgw6d2D09udOLW/zs5rFPpNsm/JI3u/fl
j1n/0J4zsiOfrE8+XtC94/MHFRcdPcWzp99ZkTFlVvulvosrVj6n+HP0cFPK+C4rj84d9oAnOW3A
K6c7zVON2PTje5ZFGZf9y7U3P1B9Ml9xPX/6tG4NS2fVNo+PuCTcWBC79WbZE/MemZc4v2zKRmfH
hOap1f3b0y+8FCh+Nrze5DNRpEd8v7fiiP7f2O2oIsTcyULP0C0M756FcuqFYX+o2Nb1zT8VLN5R
fXH9w4/0bzgcMv9nAR2flTkkvNG858kppD/vkft3Qn+3jfqdBapsqLpz/ewR76uLX3sqklEszByw
6NtpY3b+QSx88Je6kaPn277pWbr19bHS0wu3PGw98tP6Nw5ufWek2zpVNCn3WUGtZ+A3GZsnz/bU
Dfxo3neLlLsii7rt+Tr3q8wnB6z6j026dObc3b4DD/drna15c3Kd0dX2naeTj5hdlFDcX3bPetZm
6eJ5ih03tmwRCun5MudQqtcsDbU5CV381seFUys8dp9f22zlvyEp4p7By5eWso87P92ybPwprNiT
0pDMxjLt0ywmZ/1qt45d/5lupv70uneLuWTyZtY8njNz72gk1nh8FJ8jqGjBJNO+hu3oNKMdTx2O
BdvuXdl570Waee8XpWlzzmwoDwm0ulbkskn5G7CAWgUsoCbBm0dTdMHNI86Bax5hFATg5pGBuZEp
sGgyMgSXUcYQriGIa9C4mR7NI3UDVQhXLs85syAjtUjBJdhVwTXYz8rc0cJI18zCwlHX0s3SyFDV
QBniJxlUP+kGgzylEJxaVJaZnEqweJvayKXgJBFYdXPq29l/77Rf/M3XL/xqlbmGUNk/34DVZdO1
Jrs/WBmWyfR0Sp1v6+36wvelDLd3O+f8zl9T+EH7Ys2kc1PE5y48uuvn97q7iQ91DeTmqOmW2T9z
m9a37kan+Y0z7z+fjz78J+PBp5T+2S8OC/1cvK/lz7Xuc6y2exnLAtSZf7RsF2vrTdgXq6ljc37p
3xlRprL+Ygcsbsgl2tuabQ4TES2fai3wi2HD5Eex5qvVdyfreIg0hj7OebVSe2pvB1/dYoal5Srs
M7QKmHdoqUyYde/oIiXv/T6RbOUhRc4b7FLuTm7hiNj272W7J6fZ5s0/jFfW+SyqrDeK1OSbt/Xr
A5t59m/crJGbU4gCQWNqx34m69e3puyqdeP/dfpL3dz/F1FaSlhLDEpaSiXFBcmJVGkpwUwqwV5Y
o7T/2A5gK60Y3q358+hSR9opzcdRO88yNNWJxxxViRTaveJ79vX2f72nt5bJSyt9+/7w1JadjoxS
5ms9zKcV/DpjvFyjZwf3thJhje2bSx9qcT7q9r8/w376dhOhxlcCd2Xv7Eo57xdg7dP1V/Ku6rqr
09pfeR95+uGno3gs4+vwjtqyqqf5/9oV1kye0zNrf7zUAlEDlQeL6hInympqHvacYOXc3Pnu3tXm
u/46ptbPHR0ZVzHwcH+65il9zqm3esNn3d5YzYf7eusnipZtSfgtor4qXyjZSSPCqsu62+HJ9qNn
JoXLuIVl95+e5BvGynDqh4GDq999yY69XwU+3JW6ryG3JfBT+QO1x7s5G4XuyFldcDVsYpkJLLGm
MjEyGjS2D2CXDaUjiRjqWtB4BFQ7QaONk9mQB3kcDWgvgsdtyGeALCsKLDXgGlkMgUk9+OD6w/K5
eRyXXCcWnGep/3ZQ9NQpgxQkLTyGYQYhC7QaNBh8GTIZkhmKGPLBQ3FpDCUMCgwhDJUMBUBeOlA8
EcjKYKhcqNaggjOdllQW5KcXJRZkVOqjlUssTYwMs7KuFbVl2urUqsof/SEy12Tj5Ibz6tGtjPX7
l/yQiCw1XeUYdulYa+3qGR+Oiiu3nHOPXiR0atuj9l3z6iVzV87jPVDayZXYXLnxoXbJgakPXFVW
/H5y5ObWP3dXTXN6bVtcrnKSezW3h/WDYrvZL9Y1HL9RHdHXpMtRNTU2pdtC5qWVW9KKDdG179XF
xJUkyg9szAj+PHdy7y2l6fd+vWQ/Ei2gE5YVWC6z5qHD38s/8m2vqT9q4m40OzBZSGuv7IfdNpOb
zT81CrL9KZwQzMe8fDf/191pL2aIhJufapv4QUAh4q3152uhW84t7Ei+n1KkpRdlXfqYp0/x9fft
VV5/zm72aJry2XlbpeDyhU1M8gZNTNKIOGIzbGLiAQpx0D0xoleQKNU2OzQxLog1kEBOidyIYV9G
oJ1wGVZDfmD1CqpJDQyBdaoRsD5FT4gVEy7d7g3m5d69eU6bdnB8V7LLvhi00gmURHoy3a5cOCbL
nvNEoM2Oq4n5wv4lz3b9DDIsYOqUfz8h86SDyMGA768+e69ny9wheT54iZNdOWPrRcWgBTy+3/SM
JXesDZ6mG+ckWh1W+IyvQMxOKPjATZ/mrO0mHbJ/1jjo/eq9bV2yNjA+2OVgdLWYpBKjFpv3vZOS
yVwXH+sL/o24uaaG4y5f2XIXZoHAgJVFu2ydNmpqz+dty+LW4r7MN2/h9KMO5t+/1qXtK7iZN+/T
1kXhV11OzM4IDFoosWiiTZqS9Lk9C+VcMzbrrbZ+cf7FN6XObUs0bsiYpT+R+xoWHtP13yd3RpON
yvXbv728TeQa2d9+q7mRWcha61FY5/WB/0KiU4O8ajoAARg2kA0KZW5kc3RyZWFtDQplbmRvYmoN
CjI4NSAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAyMjU+Pg0Kc3RyZWFtDQp4
nF2QwWrDMAyG734KHbtDcbpLewiBrWOQQ7uybA/g2EpmWGSjOIe8/WQvdDCBDfL/f+K39Ll9ackn
0DcOtsMEgyfHOIeFLUKPoyd1qMB5m7au3HYyUWmBu3VOOLU0BFXXoN9FnBOvsHtyoccHpd/YIXsa
Yfd57qTvlhi/cUJKUKmmAYeDDLqYeDUTgi7YvnWi+7TuhflzfKwR4bH0h98wNjico7HIhkZUdSXV
QP0q1Sgk90/fqH6wX4az+3jK7ur5WNzbe+by9+6h7MIsecoOSpAcwRPe1xRDzFQ+PxQhb1ANCmVu
ZHN0cmVhbQ0KZW5kb2JqDQoyODYgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGgg
MTIyMjAvTGVuZ3RoMSAyNDMzMj4+DQpzdHJlYW0NCniczHsJXFRV+/9z7p2NYRv2TeDCsG8zgAso
6iDghqICKqglwzDAKDATM4ComVK54BJvlpYt8qr1prYMLomZW9nmq+35y6xM5VUrLSuXTOH+n3tm
MDAM7NP7+b/ncr/3Oc9ZnuU858w5wx0gAOCOIAIuM2/MqONxcQEAGTsAAgrG5eeNnv4VsxcLLVjr
0IQ8VVLhiz/KAMgLmJ8yJXN8QV3x/W0A4hS8L+gqtaa4R+PaAQJXYJ1puloLF3PoxsMAkTexXFRq
Kqu8Z/B5FiDoPObXl2nNJvADB5S3CftTlFXUl4LDgccA4jErPlReUjlnzOQXngFwDEMly8v12pJP
t2iWYd9xWGGgwHBtZodivgTzYeWVljkho5lvARjMMpYKo0579OKRGQBJh7BOQ6V2jonxlgj6L8UK
XJW2Un9KMXE2QP/RAK5pJqPZwocB9pXxkFBuqtabpmx+bjh2jfVZMwi+EgOszrsyaaZr2hVZIHaF
aePo14cIz4OjUsU83zFMdk7miFlHWl9I+JQ5dgxDnNKx9WaC7Nytks40l3IOQApVXTBAASqYjNQP
4vW2PkRHSRNKl4nXiZMxG257ss1Qyrg7sWIxYYhUwoilt/UM+eMzONBc4i7tEq/oGEmSZY7kjYW3
SkVHoYwSv9nyzBZoE+8A7e29/K8maSCE/7f6Zi9D1l9pJyoBw9+ty19N7Msw6/+3Dj2kA1JC4PG7
8O70ntnt3XJre++npO8ie0sEWCJmWZx3hE5nX3r9KuNBBjK+A9c1B0Q5yBEdwRHRCZz4dnAGZ0QX
cEF0BVf+Js51BaIbuCG6gzuiB3ggeoInohd48zfAm6IP+CCiHP43XDn9EP3BHzEAAvjr0A/6IQZC
EHKCEK9DMAQjcsAhhkAIYiiEIipByf8KYRCGGA4RiBEUIyGSvwZREIUYDdGIMRCDGAux/FWIgzjE
eEhATAAVooqiGtT8FUiERMQkSEJMhmT+MvSH/kgPgIFID4RBiIMopkAKYiqk8r/AYBiMOASGIKZB
Gv8zDIVhiMNgOOJw0PA/gQbxZ0iHdMQRMAIxAzKQnwmZiFkwEnEkjOIvwSgYjTia4hgYgzgWxiJm
QzbiOBiHOB5y+B8hByYgToCJiBNhEv8DTKKYC7mIeZCHmA/5iJNhCn8RpsBUxKlQgFgAhYiFFKfB
NP4Chud0xBkwA/EeuBfxXpjJfw8zoQixCLSIWsTvoBiKkdaBDrEESpCjh1LEUihDLINy/lsoBwOi
AWYhzkI8D7NhNmIFVCBWQhV/DqrAiLQRTIgmuA8590E1YjVFM5gRLWBBrIFa/izUQh1iHcxBnAP1
iPUwF3EuzOP/A/Mozof5iPfDAsQF8ADiA7CQb4OFsAhxETQgNsCD/Bl4kOJD8BDiw7AYcTEsQVwC
SxGXwjL+NCyDRsRGWI64HPEUrIAViCthJeIqeIT/Bh6BJsQm+Ady/gGPIv0orEZcDY8hPoZ4Eh6H
xxHXwFrEtfAE/zU8AU8iPgnrENfBU4hPwdP8V/A04tfwDDyD9LOwHun10Ix0M/wT8Z+wAXEDbOS/
hI2wCXETPIf4HMXn4V+I/4IXEF+AzYibYQt/ArbAVsSt8CL/BbwILyH9EuIX8DK8gvgKWBGt0MIf
hxbYhrgNtiNuhx2IO2An/znshFcRX4VdiLugFbEVdiPuhtf4/4PXYA/iHngd8XXYyx+DvbAPcR/s
R85+OID0ATiIeBDeQHwD3uQ/gzfhEOIheAvxLXib/xTehncQ34F3kfMuvIf0e3AY8TD8G/HfcATx
CBxFPArvI74PH/KfwAcUP4SPED+Cj/mP4WP4BPET+BTxU/iM/wg+g2NIH4PPEf8P8SP4HI4jHocv
EL+AE/yHcAK+RPwSvkL8Cr7mP4Cv4RvEk3AK8RvE9+EUnEb6NJxBPANtyGmD/yD+B84inoXz/FE4
B98inqf4LXzHH4Hv4HvE7+EC4gW4iHgRfkD8AS4h/gg/8f+GS/Az0j9R/Bl+Qc4vcBnxMlzhD8MV
uIr0VfgV6WtwHfFX+A3xOuJ7uO+5gfQNuIl4E9qR0w4d/LvQQQCRJwRRWNtx/+solwqL/h92WHdO
8p7Z4m65PvQn7r1KH5OTzQaHvrf437PB2UmGG+S7scGpZ3Z3lWS99yPpu8hekquLA9ogcux7C5ee
2d217oNP/j4bFK7yu7TBtWe2w5/kekx9GKo+Jjdqg9i57y3+92zwcHNEGyR3YYNbz2z5n+R6THcx
BXtJXp7OwILkDs7tKXn2zHb8k1yPqQ9m9jH5erugDbI7OLen5N0zu/ty1YdxvYsp2EsK8FWgDQ4e
fW/h2zO7u9Z9GNe7CN9eUmCAG4jAwavvLQJ6ZndfchW99/P32cAFeqANcp++twjsma3olutDbN7h
c+YvpJAgT7TB8S5sCOqZreiW64MNd7GM9JLCld64TXC8Q4D0lJQ9s9275e6weHVNd7GM9JJiIvzQ
Bpc7BEhPKaJndnet77B4dU13sYz0khKi++HOxSWk7y2ie2Z319qv9376MFR9TEnxQWiD4g4B0lOK
75ndfcntQ2zexRTsJQ1M4nCz7xbZ9xZJPbO7a32Hid813eFz5i+kwQOUaIP7HQKkpzSgZ3a/brng
3vu5i2Wkl5QxNAp3kF6qvrcY2jOb65YL672fPpjZx5SdGY87SN87OLenlNkzu/t/AKJ67ye07yJ7
SXnZSbiD9B/S9xbZPbO7R+MdJn7XdIc1+i+kGXmDcAcZmN73Fnk9s7trndh7PzF9F9lLKilIw21z
8Ki+tyjoma3ulhvYez8JfRfZe2Ls/xn0xE04JuKPtwS6/iMR/vC/QyEvuotvV9Q9s7u7bnLf+7tz
mvN3dEKTCDQgnIuEL35El0Ivjb9Ucqn60i6eB7gU8nvO9Yz9Oni7lzSa/OHDhqYNGZyaMmhA/+Sk
RLUqIT4uNiY6KjIiPEwZGsIFBwX2C/D38/Xx9vL0cHdTuLo4OznKHWRSiVjEMgTispQjizhrRJFV
FKEcPTpeyCu1yNB2YRRZOWSN7F7HyhXRalz3mhqsWXpbTY2tpuZWTaLg0iAtPo7LUnLWo5lKrpVM
m1SA9MpMZSFnvUjp8ZQWRdCMM2ZCQrAFl+VbnslZSRGXZR1ZW96YVZSJ/bU4yjOUGXp5fBy0yB2R
dETK6qM0tRCfYYQSjE/W4BYGZM6oldVfmZll9VNmCipY2fAsbYl14qSCrMyAkJDC+DgrydApi62g
HGF1jaVVIIOKsUoyrFIqhjMI5sByriXuQOOKVgUUF8U6lShLtDMKrKy2UJDhFotyM60+c9t8f89i
5+4ZBUu6lgawjVm+Bk7INjYu4azNkwq6loYIWFiIfWBbJnxkUeNIFL0CvZidx6E05uHCAit5GEVy
giWCVTb79MosgVM0i7M6KEcoyxtnFeHY+DdaIbc+ZJu/v2Y3/w34Z3GN+QXKEOvwAGWhNrNfiyc0
5tZv99Nwft1L4uNaFG42x7a4uNoJJ+euhP5WGaVodYHKzr3lWSJopByDEWHldBxqUqBEm1IE0KdA
oy4Fq2EqJNjKWoIjYrA6ZBQ1KgYLfKG9VRyuUHKNVwAjQHnxQneO1s6RhCuugEAKcXIr1rC8k7bG
xlpjYoQQkWbgmKKOw2h+QHxcbSuTrjQpOHyg+2Ai+lZbOFiF7g8JEQZ4easGijFjXTipwJbnoDhg
G2hUsYVWpkgoOdBZ4jVZKFnYWXKreZESI3kHncxeVlnErT9XhbdHVvlgK/H+k2K9rTw7T5k9aVoB
l9VYZPdtdn63nK085VaZnbJ6ZBSwAYydYgJYWopBOeNWZSFT4GQVheOfhAZ1SatUhlFJOYQbaVUU
jbZhoTwkpI+NWvlLQiv6+L2ZXU3r4Nju+SHd8t3Uc2pkUWFRBJOdP62xUd6tDCf4iBYlWTqpRUOW
5k0r2K3AveDS/IJtDGEyikYUtoRhWcFuDpdOymVucYUcJ+Qgm2DAbmNktChgNy7RC2mpiDJoXtdK
gPJknTwCulbGxlNQHqZ4aMl3T/dkIvGKYCLASLyx3kyKEygOp6gSkFFtUwUHtzIJ25qFR9y2wGh8
hGkcT/kHJ0a6B6dFCnkfzZCK6OBvtvgFn8J7a2RS8NK0pOAH8VbhXYt5oV7kluhgY6Sx0rjYuEQ0
CLyF06G7m0zTSs68OtnTwdNhUFMr2a9JlTbtlTZtlzaVSZtKpE1TpU0jpU0DpU0J0qZYaVO4tClM
6ilzlylkLjInmVwmk0lkIhkjA5lnK/+NJlb4jPaUKISHRCSgiNIKRkDhhR8MYIbIGBgLVg82m8nO
G0GyrQd0kF3MWa/mKVuJHEdWrBxBrO7ZkJ0/wteaEpvdKuVzrYNis63SidMLWghZVYhcK7MUPZ5f
0Ep4gfVwgLCI7gZC+IdXBtifhYXgXTvcd7j7MLfUkZk9QJEdY39PvrFdU/bE+tchmNTgMSqYWLZL
g1dLBW4ecpsot0ngNlGub6B1TXZegXVLYKE1SSD4wEKyPX2nZp6w7hYps/R4F1mX15b7WhcWc1yL
Zqd9QY4oKtaVC0+t3rpTqc+0apSZXEv6vB6K5wnF6crMFpiXlV/QMk+jz9yWrknPUmozC3dDDilu
iVnVTdyyTnG7IYYU/7HHVlIsdBkjSMxZ1YPEVUJxjiBxlSBxlSAxR5NDJWYZhAGcWNAigxGFONnp
czvjKMexKAoIKRzhrTANowMzJMR3QcBrIuGFOkdc+5zwc9QZb6EoPj0+XSjCgBGKXISPWHuR74Ih
IQGvkRfsRQpkuylHQGxN7G3JLCTwzTJkCjdqsps/wCzc5h6cFFsYC+J7IFE8DoLx7sc+JhxO+VP2
u62jkL8ong3Kjln8l5HC12k77LctafHMdS+eWcbCG3AJ9pEYmAgH+A9BBwVMHZ4DxsIjsAsOwNd4
ZCvBEPcn84Hjn4YVeGx5EJohVeTP74RxcF7mCt546hxMjCABLyiDZ8mXMAYPSfEwBLeky6AacRLy
r5EULCF42LoHpT8GT8E+eB9Ogh/2mADHiJRc4/dABh5NdDAPdsPX4hHi5eAB/4B/wWY4CP8hCWQT
+Y79gd/JH+G/x1bReEIZCNOFNzLgUfgn1vsX/JtRsht5f34e/wL/Lp7vM2ErWn0Q3kJZVwlHphAd
8zxb3/EbX8VvpTtSL0F7vNLRmhywwHNY8xjcIA54NeA6OZzRdbjxPsJMwbN2LOo3GSphASyFlWjF
OlgPr8B5MpyUk6PkB8aZWcjsF0+U5khzHPa3f8aP4q8Kbw1BCGo7FWbjjnqB8IYErMGW/0RZh/C6
BO1kIBlChpExJJc8QhaT58ivTCxzgrnBurCubBxbyBax89nT7HWZuH1Cx9qOD/mJ/Bz0JS5H6M9w
9Fom5MMMMIEZ6mA+LETtVuHVhN7bipcV/bkfrzfhKziD11k4DxcIQ8Roo5zE4KXGawjRkLFkMplJ
yoiZrCWvklayj7xFviOXmf7MQCaVmcDkMmWMibEwTYyVaWH2M23ML6jlYDaLNbMPsFvZN9h32Y/Z
LzDqx4q0IoOoRvSYyCr6THRJdFnUIQaxEq8EsVbc3L6hI7tjOh/BD+GL+ZV8E17n0cdBwttMEIn2
TMRR1Qlv1aBVJrgPr3r03cNo0Rp4Fn0neO9VaIXXMUrfEN6hgA/hC7TvKzgtvCWAzhHs8yIhJJ4k
on+HklF4TcNxqiXzyUKyiqxDP7eQnXgdIF+ilR1o4RSmkLmXqWXmMyuZtcxTzG7mAHMMR4JnJTgS
vuwoNpudyk5n72Ut7Br2CfZJ9ll2PdvKHmDfFjGiwaKJomrRg6Im0QbRK6J3RJ+IvhSrxUPEjXhZ
xTvFe8VnJe6SAEl/SZ6kVSqR1cvOyTpgO7wDLbDz9iMTWUoUpAVeIudYEbuQOcIUMI7MMdIg+oBE
4gikERCvgir4GTUMJB8zg8hUVkemof8aSCmZDs+w/dgN7Fg4Iq4ieexEUgJ5orVwU/wmaMWNzDaW
ETey7eQ6sxXKYRUzu30zX0hcII9sYp7HiLkf0iBa5A/HmFTRbhLORDP7pS+TVhgmlbCp7GCZK+Y2
sWdQzTyZK/kOtOxpnD+ncG7lMs/jmnCWfCmdgNq1s69gnfthGNnU4QabxYVMEenHbCLj2h9s/5x9
il9P/JjTAO1u7elMBkbcZH4Lsw9+hLUd10XfwD7mBEzGVUNHZ87POPfqcKWZAjcZZ5xPebiOmHBt
KsPjZRmen1mMnyGaIIlUh6c9sUjHglwi1rEs4+8gFekI+MmiU3xjcxSX08a3p+UorqaNV7SnwfC0
9jThTlQnu4W4hYe4hZSJ4CbHHripEcMN4EQH6OvIfBucxvXUCXxh0C4gzh5SHKFWsmCHd6LC0b+V
BGqc5P2dE0X9PWb66Vf4xiqutrW3tcHw9qtpw4mbe2pqotpDyUYM6D8wOQkPqFIPT4ky1J59KKJA
MkKlThcz6Qnx6enxCemkjI0d4JUxbtw4v5gbbyakpyckaDS216Lx+IzrvRTn/WbNuBRIYUaLykWt
II6Xp8nHyWfIK+Tz5RKQyYnUQS6ROohBxrBOIkc8BIsC5RJPuVxCGJYNlBMkCUgDZQ4OEjE6TN7K
WHZoRKzcaT9zH+5mXsLVTowoJ9e3OwqO81NcbvO/eNEXPeZ/cXhaWlqqCt0mXpIQu+T+Q0sSfIUH
cU8VLuFPmpaGf4lquIfcQzySiZIke4hDCHtmc0n73vL2PeVbmefbHyLD2f1k5W87xOM6zLr2INup
X/IhWqiC45r4UaqpqlrVYpXIVRnkEBoarAzyCw2NVwZFhoYyyiBZqFKhDPIKVXLKoIhQZSv/j10+
oOJ8E1SqVmLUaHx8PX18fL2xz0gfbyS9vdGBKh+VL+cTzyT4ENbP19uLUUVGOOBOT/UZ5Pkk+vj4
cwnxkcHcEVfCCJ3IFa5+6sQjIek7cQeVQ0MHo0aInyx95lmMoLMg+CItTUCfVGGo3VLdBCe4pXZz
TecOLFFN7gkhbp4+3snJXiEDkpMGDRzg1j9CqRwQQkiIlzJUKvG6rZSwYe2XA8Inqjui1FPCvHOm
+eL6dYG0kYWqqWHe/cInqtoPqKcqvduviMw359wfHBMe3p+rZmstueE3Toho5mbjLfaKG8tsEX2K
nYUrSDQMghpN0NwYEh3bDxfNGJTYnw1wTo6PCWCBEatDw5SurSRE4+ydJCPqJKVjKjrJqZVIdyUv
5a5E+CWJcXurcYxXRfilpF4JiSmnjhp/8fJFRfvFthzBTTB8/MXhFy8q0tLcqIt8UmlcRERG2GaA
8JUNTgfMRkYoQyVent4+3gIPbFNkoI9E4CUnoWZYg7RGJayesmbj3lkjEsO93fzmhak0hTNnvXou
N7fj230vfnvv6588/czTpfOWq0L92ZmRyvvmDcipHR0/LFQtd13s7jM+Ia6ycllt7YqjHScvWQ3v
NUj839y1a/+76/IeVYdRz3SMxJXTijM9Cl7URAVpAr2GySAgMGy6szQwyctR5BLjwy11u+rANhHi
FyVqikqTOfhFtxKXllU48TFGLrahqYo2tB9Np7a7CQtARr0mLihS7hkR7hoeGuEREe4UFQ6OcqUL
F06CPBEiHcPCSYgCIdg9MBwwWkhsrCKNxs2iRTAmv17j7t0vIMIn3N83cLWon7ffatSSYA2h7qJB
uK4oB9J4GmT3qpS6lfX0tnsvgsbX4eCtXhJ5Q8Pbp2unG1efmjQibmBiQ979L89+foY5KXhQzbWH
NVGZZcyiDx56cMOC9dvXvu3rRqYvq8g+tPmB4+WFA161fWf5CXOCfRkcIWQ3sGSHxsVBCv7OEj8n
5x9DhPUiNqdNQUceI77LYsecOLb2iWPHnlh7jEm3PY+B8E8m21UL5/4bF3nqbi4m6k+uPX/Ldfp/
66Ibjv5M7a1vXWdA5/fUwh5Tb6cZ/Nx52E6zuHLMsNOiLnXE+Bm5wk7j5xA8YadluJdvttMOuB/e
bqflhINP7bQjJJHLdtoJkpkIO+1M1jKFdtoFEthLwrfrIlydwEkURGmx8IsbUQKlJZQ/jNJSyh9L
aRmlp1FaePGpVTTLThNwEve30wy4iC12moVccaidFnWpIwZfcYOdloBCvM5OyyBCvMVOO8AI8Yd2
Ws5oJO522hFKZLl22glKZa/aaWemzaGfnXaBGU5AaXkXG4WXxBROMyjt1IXvItBOFZRWCPo7zae0
B9LuTo2U9uxS34v6wUZ7d+H70bZPUzqAyrL1GdilTnAXOozWt9kbT+lWgZZ10VnWpX+nLnwnu/75
9SZ9qVan5zZz+eV6bryxymhBFpdhrDYZq7UWg7GKM1XoErhMrUX7Z5XSKyq4XENZucXM5erN+upa
fUlnvcF59ZXFxgpucK2+2izUTUwYpOaixht01UazsdQSnasvq6nQVk+xFw9IUKttTcbn35KFihrL
qrWm8vquLD2XWa2tM1SVcRNKSw1oRmJqSmp+ucHMlRqrLJwOQWuoMnP5hkq9mcvR13G5xkptFTeq
Wq+fzem0JoNFW2HmtFUlXIWxTl+t05r1cVypoaymWm9jF2vNBh1nqqnSWWpsllqMZXpLub6aqzNY
yjktCqmo0OtokbGUq9RiGYJBp63gzIayKls3ZfoqfTVyTDXoMrOem2jgdOXaaq3OgkYncNxk5JUa
qzmz3mIRzOnWjdCBWWfQV1kMaCRXZ6yeTXlaMxVfaapA89Bci5HDVpyZ+k5wQQ1WMlRxZgvW1laX
UKeYE8otFtNglaquri6h0u7LBOxFVW6prFBVWoQf9akqzTNt3SQI3D62qNNXIFdPm+RMyB8zckxG
ev6YCTnchJHcuDEZWTl5WVz6qNysrPFZOfnOcmd5nyoVGmvQHfVcDbrIcmto0XaTvrrSYLHocZDq
qeFZk8elUy8KGVO1saRGZxHsrys36Mq7tMWnoUpXUVOCTdFnJQazqQIFCC41VRvscYMOxXHpFG6s
qqjnogzRnL6yWGj1e19VnbV7VIlWLxFGFAPKUm2gcdJFPDa/1dcQqkGUAaVY9JXCzKo2oNQSY11V
hVHbVSgqrbWpimGI9hppPBprLKYaC1eirxVmAtYp11eYbrPoT0dSyKkqsHGV2TaIkANGqIZKPOdV
4FmyHnPFUE+c8bNmFua/FX5Dc6s8Dyz4rIISxGooYdexLexedj/eu9nX2BchH9ubhN/qYLkOnxxs
xjsfT78CPR57Enqz2GtxkEH7NlHUIt9Aa3DIqcD2CUhlUr72L/eULvweCJ+5yCnD1hYw05wen3qs
W4tY8of+BqOl9WhzMfKE1oNpvWps09lvImo3CNRIRWFrA2pbjSVmvEuxl2gqoQxqsLXgqSm3tR6A
rdV4dZUyHq37o102jxqxr2p6Ei/H/J1q6am/hHp1KKkK23AwAfUppfrpqdapkIK34EcD9UQp7cuC
lM5OaWlbM+3VgNrpKZ2DzzrqOSONBcGKUShLj9ds2lrQzkDbV9AWtjjhMGfEloL9Qh3B63FUroH6
p9ref2ftYlpH0FeIghrk6rDPmm5jaqH+0OOznPbLUXuFHEcjRUf9WYFlui6thJHhqO62dpX2PnVU
Y45KLbNb3qmNIKWKyrDVMVGNTXSkBX9OxDaCvHI6yloqzzbSQuxyMNler5TGJUdzFirVNjp31qZT
AzNyDFQLobTU7pk62t/sLvW0dr1t1lfSGWQbPdvoCj7j7LKEXn+Pu84oqLH3ZKDeMnef6V0iRbCt
nFphwnmhwquOXgnYY/e4TLDroqL1K1GWCtGCdbRUMyFnhpndtEm4VffvlSFEYIW9rr6LlBycIfkw
BkbinYGrhUBPQK4wc0YijqP8LOTkIQrrySicA1l4jafcfHAGOb0LqQ9tY1qPzxr72Ft6mGu20TLR
WKmksWuh65AQ//VdxikLI2gcyvw9gjpLTHS9KUEpOtqjbdTqqCwdnQk9ybXlDXRWVWDbErtUW3SU
0HITXbPqu8SWIMtw2yphiytblN9uuVCjglJR2C4an3o6vp2yetKr6g99991Lv/decmtm2dYVC9X8
91WgZ+sN9lXldr2GdPGBYInNFguV1/lJI/Rvs7WErnNVdL3T3tFSm6e13bxqW8OMdvx9VRO8aqFr
joX2r8dPoc6V3NZPOY1qUy9j9NdnUmeZiq4mOtqj+bb507k70NI6nflTdDeh77a70HfbP9B1RRQk
ShRli0aJhiKmYm0t2ih4T9AsXfidLl2XhFas7dDMh9zx5+ksffPJHQjP09qEXvSMHSC8FGl/STkg
Td0QkCJxiFk8evE1ZyJlmhsCopEVzhCS6Kh2kIhjXVjGXwxqrUQeKyEi0jCIIaLmPPUkdVwXTr8N
QQv7CT/HxmsCBqCZLmB66vhhwqUO6dKZyPO9USPiiscNPHaB/+xY/4VXtj0b9e9ZzQ1eJ9UN7CG8
45tZhjCMYtR+v8dPrswdmXHtROVo58RNaudbqhIxKrVoOVWSnSySeDDT0hO91B5CRubhNBW3n/rq
Ki5Da9IneqrdBbbUwzGzprpYW1VrwCNMoiv2hly5hyS/XFtn0ScGqgMEhqOHp43BZeir6RGEHoQS
g9WBQjHr4W0vpqcsi7bSJOx3M9LVQT7O6uTEJHV/NU3TfJwThWxyUvKA1AGp09R5XZSdnJfoo/ay
yXfBk6AhD89OcdyYKl1CYqw62iYotLOAiuLyOmXl4XkTt61mQWgDCe3qFSIGtoG4AvLlTAMhsPnw
tk1HjnKvyO9f9uKSmks7cn46edB1f5l278aSfl/suX44eetD6mUFC1acmP3VwGdd9390Yc7Pdc8v
MKbtX/2K82vllyseO7w3N37r6KFXXv3snpkBzPrfVLODNl3buO55/3eZUw+Myz3jUnRB02/Bbuev
h7+z4+SSvTPnzkpMYJ9c5PHCKO79RLPz1Pijc/onP+7+pPvur8tVW86eeaNxRcyby0OWlO59sGCq
sWZ/2paIJfccVnilrX/ou/yD8qpDHW+N/Wq31G1t6PwTwyI/CppzYX3iez+dDfU7cWj7qIx1/jOb
g5ra7r3yw/yf7t9aTB65Mt7x6w9Dp7zw+NGXl9a+/MNrzr+0jT/efKO8+WXPIduXHNzDsBj4Gxed
UC/6XN1fIsOIFYulhIii1BHqsM68miz2tR8VjDqzKQFP7gbhMCucFWjsBHoQwotkagk+GALqdIEX
LBqsTlEPbO7fnLRYbW+uq67o1lpli5WuoZKRnoC1aKQGhouc1PJOLViZ2kVgugqyhFcIJagh5t1E
GJmb/NQ+nfHNejjl56VjoKXEJ8YPSL5tVrCLFsHY2de/K3gjs1/isvonY9fsb3iRHOs37qi1saDq
pCx6473vHl7tcU6U6/zjqEgVpFjb3luds+7T0GKva8MHhUwwJS78aXnKku3nz6+Fjg8mr8kJ+3hz
ZM7cl3dp03+Jef/ce8fv/WpP7MPDdj6z8/ipqfy+HW8tuPKB07OX1nbEfjIkNyAgJfLa8LE4h3l1
A3POPo+dv4299Onn0Ut9k8QO966rXXr7PP6vzIw/Tkd1StfpOLWPQlXqeJvQiN6ECmX66l6n5LaJ
UaO/+qR87kO+maU19yw41LpeF8EPzXh6vluKInyy+XhNpKE9Zzc34xP59eaAmIuTp4RoPw860fZ6
8ux3fvxq4yD9qoDVTq/mBc2YXzpgprgxq6M252Tewg2LuGdeXjpjg+zaf9TXfwgdNG6E/P2Tbwcf
Ojb520XDd+ZujNtC5v68YcvKAR3rz94zS7x+6Owz+9cc6DhSdF1zTtqc+f2iSVXPxfz8aqMi6uIj
X0qaF09cN2+szFkdeFjx7Oxr3xa8LNqseXJb1PlHvF9MO5NnzP5kwDM7jSWB29fE7Rl6rv77yrnX
vc9GvPTKj0/m7dLEPd5av6Xj09yt0ZYFIy6kBm2Y5X22cE9Y+eewMEOxZOFs+5Q8rF70zl+ckk63
piSDR8dk22SMU8eoo5ojmsMWh95pMlrM5nidlk4/bzr9hC7+ZAZKDvRpBva/fQYKo7xkjumLnFzC
Tf+m/r0G9aH23X5r9v4D3tx79Ojbl10+56+PP5BcrHZ764ol4NNHv575NOfRMj9r38SjD55b6PPg
vyJXl3mMvHG49Yl09shTk6aLlz/wgvGXgIkBYQk/G1ZWhF7bc9j78YtOlgPldce/f7J4yUFz06/L
LHOVWzc+MW9ty7VHou8bn1ATMDr9i0s7nbn8Y3XNaxt0hnaHDxov1exxeOr4dbfJEeu0SfvmMtZ5
i/dteHN5aNycjwbUvv6oecb13WfHecmVR9o+/rR/whiNV5pr0dywt58r/XHNB6bvh5277Lzgy4/m
b6y9z3Dw6Qmj1ANCWja84l+cFnt81ZYY6bzPfbfPmHf6meeMHWnLXlI3iNxxCfjNtgS4wkFYnpa2
1O2jYVd1F05qunpMhCuAqXNu/7/qzTOsiWyN4wkJHS8QilRJaCqoTCCS0KVIWaSFqhSBEKQoICLN
AglIU0TUUKUEpCNFhKCiFOlNFMErsOBeOiJKXRWBmwACe9VnP+3dZz/lOXMyM+fMec/v/P/vmWHl
EtX09ArwpuVW4ftw++FIBQU0fCt5up6EPYTcAwht/JnnjzWb6VkkAhDZGCa+7Xqsp6cPXP28j4un
t6tPAA0PCmgAiQQA9CYeZAGkrBxys/g3tOhPl3K6J7VeY0pzhoL70uL97YCpjLxoiZOfVknHMimr
KRlw1YsmGckZMfay7i80nAJmCn1bzPrm3t0JE4pJC3Uua3APdBTrFVYeZAffnIirrz7onJTkIpnY
pXigmq3cSrJWe5xFFRN3IG+fQu60XojGcCj746TT5g6FxItk+4N+xyYTHzgpJRkLIZnEudPyxmOl
+cZUEnDc9lb0+DRhNDb895wPt+kaBburzY+WRQZXK06b3TYsWskJPONjWMzXHse8DwGyvGHvin6s
D2NUtlizXr7rzMKU/ZJgYfmhQsmOl+AH7Vt6WhRMWi3pCOrNEfC2UW6t+siUKQqUMVxpKYP7cV0Z
2uRGLkDIAggZtHkJhhKSAEJ8MId1l9cHV+9UMZPL3PcNrq+1kb3//+NH/JMYX6cCaYK1Jno+nu/w
+0qw+L/9OOdt7GXTUlnbVOljI2JaFMcQcx8tbx0oT9dpdvzw9XW7ktKJPHkz11XxM2ot7fmD9Bd/
RUarpHF4uT1ehRnxudZ87dIc5jwBN5pyvFCcz98sjZY4+BRPhkVJsOMyfzcT+oxo6eWZxxZ6aMoy
rhB3fxo9dXqXydKTWWzTk/F64CscyRwhTNovYNAjTJc1G/wW8sB6ofTXZssZvF4T1qziAWQfbO1G
70emmMuV8Q0F6AMjgSO5fsO+6aAuN7Xal/JRb9VhuYfdBN36D//2Sgg6knsU2nxCDuNhILTLkcKS
ca27x0xNu0PIPNurH6YYfut8Ws7LdCoVnlHFQfGmMHBjTTSqAQkXcPbV05Gd9z76ZhKE/y4kAPJU
vYBColEoJIom4KmIl5X/hgRC9h8lAxfAuWE3WCwdzrlQpYAP9T4c60sI1WwwYvFOZzw9nL61jOVn
LftZN2WpN/2um2IAYqMbAjtrnPDr4oOmRozXTQH8e5LsopGEaZ0kz9rh0VVDa6rGM4F1r8Qllnw7
EWsdUhaGrXcoxPuHAw6C6nOZenAtlKylydra3tJrcRmMX9griNikd8TGJxwNuTUz7qHXTQUfG39x
AkfW8r4iuoCO+GstwjCGyziTt19UHo6iS4dwjGJKZ4+gdBbci7QX957bI9qmwb/HpAKb1J3ZxdXI
r3aW4cwcCaF1UuN9TUuiE7yyFvU1Q2vswn1hmcrswQXyUDKCfdUKqW6OuVxsNT4yfTxAouB3KRlO
NYy/qkZQjsvIZVGX3WO/3Kz318LqkI1CI28l15y6MMW8HAa5tJR4Vlk6xzmhfejgf6TpBNhRuvhF
ZVjxbLiQsCTWs50ae5BMIliK+jwkf6TDIf8MvMAYmDcNOA+VL3QQCAi6blGF/wXlhXJLfJLWt232
Nrs3upQutZt3ufazKQHg3zqFmw7KtocFZAo6T7XrmiB1gHVd+Kz7Dm2AfUtg0QMQ6s+OebmOMdzw
23n6ypIpVlbUCyJSNdLxaA9TzmcHfPMhyBeMrvrz8rm9Id3DDRamueX8ne1js+mfLSp0b+uIj+aJ
DAS+WuINhPXP3xCcZrItu3Lj4TWrx0LtpG7SbbmF2MG1iGQ7fT1jBUlFuKAZ+uslG55bzwaErn90
wCqPMr53/hAwHdNpicOT+PTSA4fwlCHJotVmWEVjRnvjyate8639BUQPxgE8/8PcpbA6Zo2EWclC
18DSWumcEmeRrOJwJvd4rsoS+cQ99JlcmMyaQkD1EeI1kN3qCBMqtowenQ3kfGSnzIaevVV7M8IQ
eoLepul5b96b3y7F+u9dfuCRFcMgZ1VqJ8XJDhDp5agoE9zAGIuDdmob7b1rEP67DMU/BRnb7FNA
yaHkaW4JTdVG1OJhWhHw+Uv6sVkP+Un9n0qiDkIcpsgmY652aLCrgBTdq5wicvWZbdgh24+l3osF
hRFu5X2lohdYm5uz9GPtRLkmPy+KpZQvePgWfZi5q9xUX3PcRq2g7JycZLYjwSGA7LjgEUHq8vi1
Ke3lXRNOX4dHXlF4chxvZI4toUvLebTfIvVI69cBX/FDWgBotPfSBRJnj5Vw5oQRa0vEQEavaeLp
VlxrolvSTbtjBpwTMt3W1nYnsZnnDmY9Dj266xo/j28bU19SthfPhMG064rtffeY9/tN0Jirjdp6
PLeNE0oWXO6+HmQ+e8on1e+a8BX3+Knxk0fb346d3fUCB7p1AZlwnfUB15OyrpnZIcRMnr3DDFpT
5dmGJCKCb1KfyPXvvMs2DGbeuOedN+0wmhE05GfYk3mn4PntlZ+QL492VAxKIAOE1OAfUoTsc/fv
4N/3YkF/w/hpARrAkXTVdOUwxR3G78y366w7Py93V9pRmc1t8nMytAlAi39q7MuuG0KjHU5UE1AH
1LacKF2Y3M595O+vi/f+/oI+P/KEmDcfSJhkmwRuWzMP1yG65vGy5e46g3syBUFmu/pkKz65je1a
Rgj4qWa5BD4gXY6ymdOsD0nGX4owNrlI5F4MOfc646lNK51Xp+Tp3VVY7qzIGsoIuZ18PiX2rIpg
jQXIovxTqGSfndxyr0SgXVJf9vLCnLpAobn2Pd2BWAyXFbPe7DwyXKQKet0ahodMspp0kdmiEp+8
qc3tYuKRQJRXWEYKvbAOO5zVupIfPp2HVqNoug/DZ49WXS6anDW/T9atwj81Rb1pmWDAQRn8PYzX
dB8nT2meCO+/xxK8eLzhwMhokPUvo7IBM6JXbrIdLDO2bqw7YmVV8LJjWKa2Y/pMGjoASYS2UbHZ
RAcGA4Tyfwwc/wD47TR2OmEC4N5aUPeBkYwQ+vVkO22Z3Rx6ZgiSbWfmnNr07RIr8l/AzloeQGz7
RCiSOm8lB/eYdnyxAl/b/0pXBq2Fa117eAzw3nEKG9IJcEzHBMv/YOcdDtLe2mv5ya47WTJY/Kex
7bP1DtL/qkkoEQxq5Zj33l3U9jWgPLFEVF86JaE9IvkeeCHIRSCfXa4c0eO2N6ZOzTB+rJA3oANV
Hs1aA1GYI4nPQWSOE0JdbmDDFT1NhhOynz1CWavgGpcPmWL8jygXGX55y5jf9q62OOP5oo5xagRM
OS0eEdqVbDpthTkiDCaJKXFyrU7rpbC9qqqeTGwVDKF0XvU6OXdxyYiFtZr3dD9C1KlHGm2iXTit
M3ATU8NRWuDVEZsUSRF5+UsE0FoxX239jpnFSS8ENMMy+kywIVpkJkEtSEm6U9rg3Xnzvk75EWZh
eJrqnI0tJJKJ/4KXa6uJSh5h8HhNSRR/pZtRM/fK1YQ4ypke+ioUlEykyiIieHl7xBiQRPA09dAE
LbxP/SVJzR+kUtkYmDYaQEelTPpxgG9n7LFub+2AqaG3VUOPZKet99QFXlaW9m076gSVvztCDwbl
MEwUpZQPSkUJ2QMjn1fjen8QAu6mWrpvuw5ptq3Yehj0JL3XqL+jRLGQ9D9m75Svv/dKufmxHh7N
0JQvXuqBOjr1w1e7Gx6tva972bRmCQ7xL53sRwS5oh6py+SoBj44nEJ/p77SkBsNCp9Uup5/3lka
5os1JybINOGY7ldj6waffmQhr9TRzS+I95VqOvQxQDxX9RNSZ0OKq9D34ZppFWPD1fXjaKBeb+Xi
/jnRc0NA2j2p8Z4wPiQF3hBZZ6ypMoWXU3QzA6nq5EdJJZoKAllTTg6e2eaUbGkEe6H+4Ou1EIYs
Eb90gzuLBgLlkN0vPvvtbr7BcUWt9FRnZA4WJ7a6rHAixTYYeG6mMlNCmQ/pH7jxX39/QU8NCmVu
ZHN0cmVhbQ0KZW5kb2JqDQoyODcgMCBvYmoNClsgMFsgNjAwXSAgMTIwWyA0NjBdIF0gDQplbmRv
YmoNCjI4OCAwIG9iag0KWyAyNzhdIA0KZW5kb2JqDQoyODkgMCBvYmoNCjw8L1R5cGUvWFJlZi9T
aXplIDI4OS9XWyAxIDQgMl0gL1Jvb3QgMSAwIFIvSW5mbyA0NyAwIFIvSURbPDE4QUFGRDUzNjNB
QjE1NDBCQzA4NzkwQzdGOEU2NTdFPjwxOEFBRkQ1MzYzQUIxNTQwQkMwODc5MEM3RjhFNjU3RT5d
IC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDYyND4+DQpzdHJlYW0NCnicNdVZUM5RGMfx/1sp
ZGvf98UWot5CSBGVfU2khCyFqFC0vKVklyzZKUu2JEuUfd+XspWMWzNcmHGRsUx5/8+Xc/F85sw8
Z86c5+L8FEW/Wls1+mqmKCpZUCcYmAtmVYJ5EETBH8EiTLAMge+C1TfBOg2KBRs/4AbbZMHOTrA3
hWrBoVxw9IFI+Co4aQVnb2gQXOoF1zzBLQOaBXdLqIAfgscnwVMneMUL3iWCltdqPwsBLUJ4ghCR
LcSGQroQlySkBOsHph9doPIG3sI7eA0m8K/zvf5cqvP/nQYMwBCMoA0YQ1toB+3BFDpAR+gEnaEL
2IA5mIElWIA1WIEtOIA92IErOIEjNIALOIMbuIMHeIIXeENX6AbdoQf0BB9ohF7QG/qAL/SFfuAH
/qCFABgGg6A/BMJAGABBEApDYDAMhWAIAR2Ew3AYAWHwAUbCWIiECBgNo2AMTIbxMA4mwgSYBDNg
KkyBaIiCaTAdEmAmxMAciIU4mAXxMBvmQhLMh3mwEBZAIqTCYlgEy2AJJMNSSIEMWA5psBJWQDrk
wGpYBVmQCdnwCgphDeRCE+RBAeTDWiiGzbAO1sMG2AiboAi2wFbYBntgJ2yHHVACu2A3HIJ9sBcO
wH44CMegFA7DESiDo1ABJ+E4lMMJOA2n4AxcgEo4C1VwDs7DNbgEF6EWquEyXIEauAp34SZchxtw
G27BHXgM9+EePIQH8AhewlN4As/hGbyAOqjX/+w5BIOuUUXT8lFoTYMiFQONjYphfoxQYAv+QmG0
ilFzmfDTV/ilE35nqhj7SVIa+5eqmNQkCrWSYyZfKqFJUf4CE03ICQ0KZW5kc3RyZWFtDQplbmRv
YmoNCnhyZWYNCjAgMjkwDQowMDAwMDAwMDQ4IDY1NTM1IGYNCjAwMDAwMDAwMTcgMDAwMDAgbg0K
MDAwMDAwMDEyNSAwMDAwMCBuDQowMDAwMDAwMjA5IDAwMDAwIG4NCjAwMDAwMDA1MzAgMDAwMDAg
bg0KMDAwMDAwNDUyOSAwMDAwMCBuDQowMDAwMDA0NjY3IDAwMDAwIG4NCjAwMDAwMDQ2OTUgMDAw
MDAgbg0KMDAwMDAwNDg2MCAwMDAwMCBuDQowMDAwMDA0OTMzIDAwMDAwIG4NCjAwMDAwMDUxODUg
MDAwMDAgbg0KMDAwMDAwNTM2MiAwMDAwMCBuDQowMDAwMDA1NjE1IDAwMDAwIG4NCjAwMDAwMDU3
NDggMDAwMDAgbg0KMDAwMDAwNTc3OCAwMDAwMCBuDQowMDAwMDA1OTM5IDAwMDAwIG4NCjAwMDAw
MDYwMTMgMDAwMDAgbg0KMDAwMDAwNjI1NSAwMDAwMCBuDQowMDAwMDA2NDI1IDAwMDAwIG4NCjAw
MDAwMDY2NjcgMDAwMDAgbg0KMDAwMDAwNjgzOCAwMDAwMCBuDQowMDAwMDA3MDc5IDAwMDAwIG4N
CjAwMDAwMDcyMTIgMDAwMDAgbg0KMDAwMDAwNzI0MiAwMDAwMCBuDQowMDAwMDA3NDAzIDAwMDAw
IG4NCjAwMDAwMDc0NzcgMDAwMDAgbg0KMDAwMDAwNzcxOCAwMDAwMCBuDQowMDAwMDA3ODk2IDAw
MDAwIG4NCjAwMDAwMDgxNDYgMDAwMDAgbg0KMDAwMDAwODMyMiAwMDAwMCBuDQowMDAwMDA4NTY5
IDAwMDAwIG4NCjAwMDAwMDg2OTQgMDAwMDAgbg0KMDAwMDAwODcyNCAwMDAwMCBuDQowMDAwMDA4
ODc3IDAwMDAwIG4NCjAwMDAwMDg5NTEgMDAwMDAgbg0KMDAwMDAwOTE4MiAwMDAwMCBuDQowMDAw
MDA5MzQ0IDAwMDAwIG4NCjAwMDAwMDk1NjkgMDAwMDAgbg0KMDAwMDAwOTg3OSAwMDAwMCBuDQow
MDAwMDEzNzQ1IDAwMDAwIG4NCjAwMDAwMTM3OTkgMDAwMDAgbg0KMDAwMDAxNDA3OCAwMDAwMCBu
DQowMDAwMDE4NTMzIDAwMDAwIG4NCjAwMDAwMTg4MTQgMDAwMDAgbg0KMDAwMDAyNDEzMCAwMDAw
MCBuDQowMDAwMDI0MTg0IDAwMDAwIG4NCjAwMDAwMjQ0MjcgMDAwMDAgbg0KMDAwMDAyOTI0NyAw
MDAwMCBuDQowMDAwMDAwMDQ5IDY1NTM1IGYNCjAwMDAwMDAwNTAgNjU1MzUgZg0KMDAwMDAwMDA1
MSA2NTUzNSBmDQowMDAwMDAwMDUyIDY1NTM1IGYNCjAwMDAwMDAwNTMgNjU1MzUgZg0KMDAwMDAw
MDA1NCA2NTUzNSBmDQowMDAwMDAwMDU1IDY1NTM1IGYNCjAwMDAwMDAwNTYgNjU1MzUgZg0KMDAw
MDAwMDA1NyA2NTUzNSBmDQowMDAwMDAwMDU4IDY1NTM1IGYNCjAwMDAwMDAwNTkgNjU1MzUgZg0K
MDAwMDAwMDA2MCA2NTUzNSBmDQowMDAwMDAwMDYxIDY1NTM1IGYNCjAwMDAwMDAwNjIgNjU1MzUg
Zg0KMDAwMDAwMDA2MyA2NTUzNSBmDQowMDAwMDAwMDY0IDY1NTM1IGYNCjAwMDAwMDAwNjUgNjU1
MzUgZg0KMDAwMDAwMDA2NiA2NTUzNSBmDQowMDAwMDAwMDY3IDY1NTM1IGYNCjAwMDAwMDAwNjgg
NjU1MzUgZg0KMDAwMDAwMDA2OSA2NTUzNSBmDQowMDAwMDAwMDcwIDY1NTM1IGYNCjAwMDAwMDAw
NzEgNjU1MzUgZg0KMDAwMDAwMDA3MiA2NTUzNSBmDQowMDAwMDAwMDczIDY1NTM1IGYNCjAwMDAw
MDAwNzQgNjU1MzUgZg0KMDAwMDAwMDA3NSA2NTUzNSBmDQowMDAwMDAwMDc2IDY1NTM1IGYNCjAw
MDAwMDAwNzcgNjU1MzUgZg0KMDAwMDAwMDA3OCA2NTUzNSBmDQowMDAwMDAwMDc5IDY1NTM1IGYN
CjAwMDAwMDAwODAgNjU1MzUgZg0KMDAwMDAwMDA4MSA2NTUzNSBmDQowMDAwMDAwMDgyIDY1NTM1
IGYNCjAwMDAwMDAwODMgNjU1MzUgZg0KMDAwMDAwMDA4NCA2NTUzNSBmDQowMDAwMDAwMDg1IDY1
NTM1IGYNCjAwMDAwMDAwODYgNjU1MzUgZg0KMDAwMDAwMDA4NyA2NTUzNSBmDQowMDAwMDAwMDg4
IDY1NTM1IGYNCjAwMDAwMDAwODkgNjU1MzUgZg0KMDAwMDAwMDA5MCA2NTUzNSBmDQowMDAwMDAw
MDkxIDY1NTM1IGYNCjAwMDAwMDAwOTIgNjU1MzUgZg0KMDAwMDAwMDA5MyA2NTUzNSBmDQowMDAw
MDAwMDk0IDY1NTM1IGYNCjAwMDAwMDAwOTUgNjU1MzUgZg0KMDAwMDAwMDA5NiA2NTUzNSBmDQow
MDAwMDAwMDk3IDY1NTM1IGYNCjAwMDAwMDAwOTggNjU1MzUgZg0KMDAwMDAwMDA5OSA2NTUzNSBm
DQowMDAwMDAwMTAwIDY1NTM1IGYNCjAwMDAwMDAxMDEgNjU1MzUgZg0KMDAwMDAwMDEwMiA2NTUz
NSBmDQowMDAwMDAwMTAzIDY1NTM1IGYNCjAwMDAwMDAxMDQgNjU1MzUgZg0KMDAwMDAwMDEwNSA2
NTUzNSBmDQowMDAwMDAwMTA2IDY1NTM1IGYNCjAwMDAwMDAxMDcgNjU1MzUgZg0KMDAwMDAwMDEw
OCA2NTUzNSBmDQowMDAwMDAwMTA5IDY1NTM1IGYNCjAwMDAwMDAxMTAgNjU1MzUgZg0KMDAwMDAw
MDExMSA2NTUzNSBmDQowMDAwMDAwMTEyIDY1NTM1IGYNCjAwMDAwMDAxMTMgNjU1MzUgZg0KMDAw
MDAwMDExNCA2NTUzNSBmDQowMDAwMDAwMTE1IDY1NTM1IGYNCjAwMDAwMDAxMTYgNjU1MzUgZg0K
MDAwMDAwMDExNyA2NTUzNSBmDQowMDAwMDAwMTE4IDY1NTM1IGYNCjAwMDAwMDAxMTkgNjU1MzUg
Zg0KMDAwMDAwMDEyMCA2NTUzNSBmDQowMDAwMDAwMTIxIDY1NTM1IGYNCjAwMDAwMDAxMjIgNjU1
MzUgZg0KMDAwMDAwMDEyMyA2NTUzNSBmDQowMDAwMDAwMTI0IDY1NTM1IGYNCjAwMDAwMDAxMjUg
NjU1MzUgZg0KMDAwMDAwMDEyNiA2NTUzNSBmDQowMDAwMDAwMTI3IDY1NTM1IGYNCjAwMDAwMDAx
MjggNjU1MzUgZg0KMDAwMDAwMDEyOSA2NTUzNSBmDQowMDAwMDAwMTMwIDY1NTM1IGYNCjAwMDAw
MDAxMzEgNjU1MzUgZg0KMDAwMDAwMDEzMiA2NTUzNSBmDQowMDAwMDAwMTMzIDY1NTM1IGYNCjAw
MDAwMDAxMzQgNjU1MzUgZg0KMDAwMDAwMDEzNSA2NTUzNSBmDQowMDAwMDAwMTM2IDY1NTM1IGYN
CjAwMDAwMDAxMzcgNjU1MzUgZg0KMDAwMDAwMDEzOCA2NTUzNSBmDQowMDAwMDAwMTM5IDY1NTM1
IGYNCjAwMDAwMDAxNDAgNjU1MzUgZg0KMDAwMDAwMDE0MSA2NTUzNSBmDQowMDAwMDAwMTQyIDY1
NTM1IGYNCjAwMDAwMDAxNDMgNjU1MzUgZg0KMDAwMDAwMDE0NCA2NTUzNSBmDQowMDAwMDAwMTQ1
IDY1NTM1IGYNCjAwMDAwMDAxNDYgNjU1MzUgZg0KMDAwMDAwMDE0NyA2NTUzNSBmDQowMDAwMDAw
MTQ4IDY1NTM1IGYNCjAwMDAwMDAxNDkgNjU1MzUgZg0KMDAwMDAwMDE1MCA2NTUzNSBmDQowMDAw
MDAwMTUxIDY1NTM1IGYNCjAwMDAwMDAxNTIgNjU1MzUgZg0KMDAwMDAwMDE1MyA2NTUzNSBmDQow
MDAwMDAwMTU0IDY1NTM1IGYNCjAwMDAwMDAxNTUgNjU1MzUgZg0KMDAwMDAwMDE1NiA2NTUzNSBm
DQowMDAwMDAwMTU3IDY1NTM1IGYNCjAwMDAwMDAxNTggNjU1MzUgZg0KMDAwMDAwMDE1OSA2NTUz
NSBmDQowMDAwMDAwMTYwIDY1NTM1IGYNCjAwMDAwMDAxNjEgNjU1MzUgZg0KMDAwMDAwMDE2MiA2
NTUzNSBmDQowMDAwMDAwMTYzIDY1NTM1IGYNCjAwMDAwMDAxNjQgNjU1MzUgZg0KMDAwMDAwMDE2
NSA2NTUzNSBmDQowMDAwMDAwMTY2IDY1NTM1IGYNCjAwMDAwMDAxNjcgNjU1MzUgZg0KMDAwMDAw
MDE2OCA2NTUzNSBmDQowMDAwMDAwMTY5IDY1NTM1IGYNCjAwMDAwMDAxNzAgNjU1MzUgZg0KMDAw
MDAwMDE3MSA2NTUzNSBmDQowMDAwMDAwMTcyIDY1NTM1IGYNCjAwMDAwMDAxNzMgNjU1MzUgZg0K
MDAwMDAwMDE3NCA2NTUzNSBmDQowMDAwMDAwMTc1IDY1NTM1IGYNCjAwMDAwMDAxNzYgNjU1MzUg
Zg0KMDAwMDAwMDE3NyA2NTUzNSBmDQowMDAwMDAwMTc4IDY1NTM1IGYNCjAwMDAwMDAxNzkgNjU1
MzUgZg0KMDAwMDAwMDE4MCA2NTUzNSBmDQowMDAwMDAwMTgxIDY1NTM1IGYNCjAwMDAwMDAxODIg
NjU1MzUgZg0KMDAwMDAwMDE4MyA2NTUzNSBmDQowMDAwMDAwMTg0IDY1NTM1IGYNCjAwMDAwMDAx
ODUgNjU1MzUgZg0KMDAwMDAwMDE4NiA2NTUzNSBmDQowMDAwMDAwMTg3IDY1NTM1IGYNCjAwMDAw
MDAxODggNjU1MzUgZg0KMDAwMDAwMDE4OSA2NTUzNSBmDQowMDAwMDAwMTkwIDY1NTM1IGYNCjAw
MDAwMDAxOTEgNjU1MzUgZg0KMDAwMDAwMDE5MiA2NTUzNSBmDQowMDAwMDAwMTkzIDY1NTM1IGYN
CjAwMDAwMDAxOTQgNjU1MzUgZg0KMDAwMDAwMDE5NSA2NTUzNSBmDQowMDAwMDAwMTk2IDY1NTM1
IGYNCjAwMDAwMDAxOTcgNjU1MzUgZg0KMDAwMDAwMDE5OCA2NTUzNSBmDQowMDAwMDAwMTk5IDY1
NTM1IGYNCjAwMDAwMDAyMDAgNjU1MzUgZg0KMDAwMDAwMDIwMSA2NTUzNSBmDQowMDAwMDAwMjAy
IDY1NTM1IGYNCjAwMDAwMDAyMDMgNjU1MzUgZg0KMDAwMDAwMDIwNCA2NTUzNSBmDQowMDAwMDAw
MjA1IDY1NTM1IGYNCjAwMDAwMDAyMDYgNjU1MzUgZg0KMDAwMDAwMDIwNyA2NTUzNSBmDQowMDAw
MDAwMjA4IDY1NTM1IGYNCjAwMDAwMDAyMDkgNjU1MzUgZg0KMDAwMDAwMDIxMCA2NTUzNSBmDQow
MDAwMDAwMjExIDY1NTM1IGYNCjAwMDAwMDAyMTIgNjU1MzUgZg0KMDAwMDAwMDIxMyA2NTUzNSBm
DQowMDAwMDAwMjE0IDY1NTM1IGYNCjAwMDAwMDAyMTUgNjU1MzUgZg0KMDAwMDAwMDIxNiA2NTUz
NSBmDQowMDAwMDAwMjE3IDY1NTM1IGYNCjAwMDAwMDAyMTggNjU1MzUgZg0KMDAwMDAwMDIxOSA2
NTUzNSBmDQowMDAwMDAwMjIwIDY1NTM1IGYNCjAwMDAwMDAyMjEgNjU1MzUgZg0KMDAwMDAwMDIy
MiA2NTUzNSBmDQowMDAwMDAwMjIzIDY1NTM1IGYNCjAwMDAwMDAyMjQgNjU1MzUgZg0KMDAwMDAw
MDIyNSA2NTUzNSBmDQowMDAwMDAwMjI2IDY1NTM1IGYNCjAwMDAwMDAyMjcgNjU1MzUgZg0KMDAw
MDAwMDIyOCA2NTUzNSBmDQowMDAwMDAwMjI5IDY1NTM1IGYNCjAwMDAwMDAyMzAgNjU1MzUgZg0K
MDAwMDAwMDIzMSA2NTUzNSBmDQowMDAwMDAwMjMyIDY1NTM1IGYNCjAwMDAwMDAyMzMgNjU1MzUg
Zg0KMDAwMDAwMDIzNCA2NTUzNSBmDQowMDAwMDAwMjM1IDY1NTM1IGYNCjAwMDAwMDAyMzYgNjU1
MzUgZg0KMDAwMDAwMDIzNyA2NTUzNSBmDQowMDAwMDAwMjM4IDY1NTM1IGYNCjAwMDAwMDAyMzkg
NjU1MzUgZg0KMDAwMDAwMDI0MCA2NTUzNSBmDQowMDAwMDAwMjQxIDY1NTM1IGYNCjAwMDAwMDAy
NDIgNjU1MzUgZg0KMDAwMDAwMDI0MyA2NTUzNSBmDQowMDAwMDAwMjQ0IDY1NTM1IGYNCjAwMDAw
MDAyNDUgNjU1MzUgZg0KMDAwMDAwMDI0NiA2NTUzNSBmDQowMDAwMDAwMjQ3IDY1NTM1IGYNCjAw
MDAwMDAyNDggNjU1MzUgZg0KMDAwMDAwMDI0OSA2NTUzNSBmDQowMDAwMDAwMjUwIDY1NTM1IGYN
CjAwMDAwMDAyNTEgNjU1MzUgZg0KMDAwMDAwMDI1MiA2NTUzNSBmDQowMDAwMDAwMjUzIDY1NTM1
IGYNCjAwMDAwMDAyNTQgNjU1MzUgZg0KMDAwMDAwMDI1NSA2NTUzNSBmDQowMDAwMDAwMjU2IDY1
NTM1IGYNCjAwMDAwMDAyNTcgNjU1MzUgZg0KMDAwMDAwMDI1OCA2NTUzNSBmDQowMDAwMDAwMjU5
IDY1NTM1IGYNCjAwMDAwMDAyNjAgNjU1MzUgZg0KMDAwMDAwMDI2MSA2NTUzNSBmDQowMDAwMDAw
MjYyIDY1NTM1IGYNCjAwMDAwMDAyNjMgNjU1MzUgZg0KMDAwMDAwMDI2NCA2NTUzNSBmDQowMDAw
MDAwMjY1IDY1NTM1IGYNCjAwMDAwMDAyNjYgNjU1MzUgZg0KMDAwMDAwMDI2NyA2NTUzNSBmDQow
MDAwMDAwMjY4IDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAzMjYxOSAwMDAwMCBu
DQowMDAwMDMyOTg1IDAwMDAwIG4NCjAwMDAxMzA3ODAgMDAwMDAgbg0KMDAwMDEzMDkzMiAwMDAw
MCBuDQowMDAwMTMwOTYwIDAwMDAwIG4NCjAwMDAxMzEzNTEgMDAwMDAgbg0KMDAwMDIzMDQ5MiAw
MDAwMCBuDQowMDAwMjMwNjgwIDAwMDAwIG4NCjAwMDAyMzA3MDggMDAwMDAgbg0KMDAwMDIzMTI1
NyAwMDAwMCBuDQowMDAwMzI1MjgyIDAwMDAwIG4NCjAwMDAzMjU5MzYgMDAwMDAgbg0KMDAwMDMy
NjI3MiAwMDAwMCBuDQowMDAwMzI2NTI0IDAwMDAwIG4NCjAwMDA0MDY0MzkgMDAwMDAgbg0KMDAw
MDQwNjY4OSAwMDAwMCBuDQowMDAwNTA2MjE4IDAwMDAwIG4NCjAwMDA1MDY1MTkgMDAwMDAgbg0K
MDAwMDUxODgzMSAwMDAwMCBuDQowMDAwNTE4ODc1IDAwMDAwIG4NCjAwMDA1MTg5MDMgMDAwMDAg
bg0KdHJhaWxlcg0KPDwvU2l6ZSAyOTAvUm9vdCAxIDAgUi9JbmZvIDQ3IDAgUi9JRFs8MThBQUZE
NTM2M0FCMTU0MEJDMDg3OTBDN0Y4RTY1N0U+PDE4QUFGRDUzNjNBQjE1NDBCQzA4NzkwQzdGOEU2
NTdFPl0gPj4NCnN0YXJ0eHJlZg0KNTE5NzMwDQolJUVPRg0KeHJlZg0KMCAwDQp0cmFpbGVyDQo8
PC9TaXplIDI5MC9Sb290IDEgMCBSL0luZm8gNDcgMCBSL0lEWzwxOEFBRkQ1MzYzQUIxNTQwQkMw
ODc5MEM3RjhFNjU3RT48MThBQUZENTM2M0FCMTU0MEJDMDg3OTBDN0Y4RTY1N0U+XSAvUHJldiA1
MTk3MzAvWFJlZlN0bSA1MTg5MDM+Pg0Kc3RhcnR4cmVmDQo1MjU2OTANCiUlRU9G

--_002_048EAD622912254A9DEA24C1734613C18C86D229FFFTLPMAILBOX02_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_002_048EAD622912254A9DEA24C1734613C18C86D229FFFTLPMAILBOX02_--


From xen-devel-bounces@lists.xen.org Tue Oct 16 21:50:06 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 21:50:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOF17-0004wH-Ho; Tue, 16 Oct 2012 21:49:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOBlY-0001iz-FT
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 18:21:21 +0000
Received: from [85.158.139.211:48270] by server-11.bemta-5.messagelabs.com id
	C6/6D-14870-F95AD705; Tue, 16 Oct 2012 18:21:19 +0000
X-Env-Sender: robert.phillips@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1350411671!22550474!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODI3MzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16482 invoked from network); 16 Oct 2012 18:21:12 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 18:21:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,595,1344211200"; 
	d="pdf'?scan'208";a="211462230"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Oct 2012 18:21:09 +0000
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.210]) by
	FTLPMAILMX02.citrite.net ([10.13.107.66]) with mapi; Tue, 16 Oct 2012
	14:21:09 -0400
From: Robert Phillips 
To: Robert Phillips , "xen-devel@lists.xen.org"
	
Date: Tue, 16 Oct 2012 14:21:06 -0400
Thread-Topic: [PATCH] Provide support for multiple frame buffers in Xen.
Thread-Index: Ac2ryjJfok0EFoLpROOgASMeFBLV8gAAL2CQ
Message-ID: <048EAD622912254A9DEA24C1734613C18C86D229FF@FTLPMAILBOX02.citrite.net>
References: <1350411302-5470-1-git-send-email-robert.phillips@citrix.com>
In-Reply-To: <1350411302-5470-1-git-send-email-robert.phillips@citrix.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/mixed;
	boundary="_002_048EAD622912254A9DEA24C1734613C18C86D229FFFTLPMAILBOX02_"
MIME-Version: 1.0
X-Mailman-Approved-At: Tue, 16 Oct 2012 21:49:35 +0000
Subject: Re: [Xen-devel] [PATCH] Provide support for multiple frame buffers
	in Xen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_048EAD622912254A9DEA24C1734613C18C86D229FFFTLPMAILBOX02_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Here is a document describing this patch.

Robert Phillips
Principal Software Engineer,  XenClient-Enterprise - Westford
robert.phillips@citrix.com

-----Original Message-----
From: Robert Phillips [mailto:robert.phillips@citrix.com]
Sent: Tuesday, October 16, 2012 2:15 PM
To: xen-devel@lists.xen.org
Cc: Robert Phillips; Robert Phillips
Subject: [PATCH] Provide support for multiple frame buffers in Xen.

From: Robert Phillips 

Support is provided for both shadow and hardware assisted paging (HAP) mode=
s.
This code bookkeeps the set of video frame buffers (vram),
detects when the guest has modified any of those buffers and, upon request,
returns a bitmap of the modified pages.

This lets other software components re-paint the portions of the monitor (o=
r monitors) that have changed.
Each monitor has a frame buffer of some size at some position in guest phys=
ical memory.
The set of frame buffers being tracked can change over time as monitors are=
 plugged and unplugged.

Signed-Off-By: Robert Phillips 
---
 xen/arch/x86/hvm/Makefile            |    3 +-
 xen/arch/x86/hvm/dirty_vram.c        |  878 ++++++++++++++++++++++++++++++=
++++
 xen/arch/x86/hvm/hvm.c               |    4 +-
 xen/arch/x86/mm/hap/hap.c            |  140 +-----
 xen/arch/x86/mm/paging.c             |  232 ++++-----
 xen/arch/x86/mm/shadow/common.c      |  335 +++++++------
 xen/arch/x86/mm/shadow/multi.c       |  169 +++----
 xen/arch/x86/mm/shadow/multi.h       |    7 +-
 xen/arch/x86/mm/shadow/types.h       |    1 +
 xen/include/asm-x86/hap.h            |    4 -
 xen/include/asm-x86/hvm/dirty_vram.h |  157 ++++++
 xen/include/asm-x86/hvm/domain.h     |    2 +-
 xen/include/asm-x86/paging.h         |   22 +-
 xen/include/asm-x86/shadow.h         |    6 -
 14 files changed, 1403 insertions(+), 557 deletions(-)
 create mode 100644 xen/arch/x86/hvm/dirty_vram.c
 create mode 100644 xen/include/asm-x86/hvm/dirty_vram.h

diff --git a/xen/arch/x86/hvm/Makefile b/xen/arch/x86/hvm/Makefile
index eea5555..f37736b 100644
--- a/xen/arch/x86/hvm/Makefile
+++ b/xen/arch/x86/hvm/Makefile
@@ -2,6 +2,7 @@ subdir-y +=3D svm
 subdir-y +=3D vmx

 obj-y +=3D asid.o
+obj-y +=3D dirty_vram.o
 obj-y +=3D emulate.o
 obj-y +=3D hpet.o
 obj-y +=3D hvm.o
@@ -22,4 +23,4 @@ obj-y +=3D vlapic.o
 obj-y +=3D vmsi.o
 obj-y +=3D vpic.o
 obj-y +=3D vpt.o
-obj-y +=3D vpmu.o
\ No newline at end of file
+obj-y +=3D vpmu.o
diff --git a/xen/arch/x86/hvm/dirty_vram.c b/xen/arch/x86/hvm/dirty_vram.c
new file mode 100644
index 0000000..22375c2
--- /dev/null
+++ b/xen/arch/x86/hvm/dirty_vram.c
@@ -0,0 +1,878 @@
+/*
+ * arch/x86/hvm/dirty_vram.c: Bookkeep/query dirty VRAM pages
+ * with support for multiple frame buffers.
+ *
+ * Copyright (c) 2012, Citrix Systems, Inc. (Robert Phillips)
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License f=
or
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along=
 with
+ * this program; if not, write to the Free Software Foundation, Inc., 59 T=
emple
+ * Place - Suite 330, Boston, MA 02111-1307 USA.
+ */
+
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "../mm/mm-locks.h"
+
+#define DEBUG_stop_tracking_all_vram          1
+#define DEBUG_allocating_dirty_vram_range     1
+#define DEBUG_high_water_mark_for_vram_ranges 1
+#define DEBUG_freeing_dirty_vram_range        1
+#define DEBUG_allocate_paddr_links_page       0
+#define DEBUG_update_vram_mapping             0
+
+/* Allocates domain's dirty_vram structure */
+dv_dirty_vram_t *
+dirty_vram_alloc(struct domain *d)
+{
+    dv_dirty_vram_t *dirty_vram;
+    ASSERT( paging_locked_by_me(d) );
+    dirty_vram =3D d->arch.hvm_domain.dirty_vram =3D xmalloc(dv_dirty_vram=
_t);
+    if ( dirty_vram )
+    {
+        memset(dirty_vram, 0, sizeof(*dirty_vram));
+        INIT_LIST_HEAD(&dirty_vram->range_head);
+        INIT_LIST_HEAD(&dirty_vram->ext_head);
+    }
+    return dirty_vram;
+}
+
+/* Returns domain's dirty_vram structure,
+ * allocating it if necessary */
+dv_dirty_vram_t *
+dirty_vram_find_or_alloc(struct domain *d)
+{
+    dv_dirty_vram_t *dirty_vram =3D d->arch.hvm_domain.dirty_vram;
+    ASSERT( paging_locked_by_me(d) );
+    if ( !dirty_vram )
+        dirty_vram =3D dirty_vram_alloc(d);
+    return dirty_vram;
+}
+
+
+/* Free domain's dirty_vram structure */
+void dirty_vram_free(struct domain *d)
+{
+    dv_dirty_vram_t *dirty_vram =3D d->arch.hvm_domain.dirty_vram;
+    ASSERT( paging_locked_by_me(d) );
+    if ( dirty_vram )
+    {
+        struct list_head *curr, *next;
+        /* Free all the ranges */
+        list_for_each_safe(curr, next, &dirty_vram->range_head)
+        {
+            dv_range_t *range =3D list_entry(curr, dv_range_t, range_link)=
;
+#if DEBUG_stop_tracking_all_vram
+            gdprintk(XENLOG_DEBUG, "[%05lx:%05lx] stop tracking all vram\n=
",
+                     range->begin_pfn, range->end_pfn);
+#endif
+            xfree(range->pl_tab);
+            xfree(range);
+        }
+        /* Free all the extension pages */
+        list_for_each_safe(curr, next, &dirty_vram->ext_head)
+        {
+            xfree(curr);
+        }
+        xfree(dirty_vram);
+        d->arch.hvm_domain.dirty_vram =3D NULL;
+    }
+}
+
+/* Returns dirty vram range containing gfn, NULL if none */
+struct dv_range *
+dirty_vram_range_find_gfn(struct domain *d,
+                          unsigned long gfn)
+{
+    struct dv_dirty_vram *dirty_vram =3D d->arch.hvm_domain.dirty_vram;
+    ASSERT( paging_locked_by_me(d) );
+    if ( dirty_vram )
+    {
+        struct list_head *curr;
+        list_for_each(curr, &dirty_vram->range_head)
+        {
+            dv_range_t *range =3D list_entry(curr, dv_range_t, range_link)=
;
+            if ( gfn >=3D range->begin_pfn &&
+                 gfn <  range->end_pfn )
+            {
+                return range;
+            }
+        }
+    }
+    return NULL;
+}
+
+/* Returns pointer to dirty vram range matching [begin_pfn .. end_pfn ), N=
ULL if none. */
+dv_range_t *
+dirty_vram_range_find(struct domain *d,
+                      unsigned long begin_pfn,
+                      unsigned long nr)
+{
+    unsigned long end_pfn =3D begin_pfn + nr;
+    dv_dirty_vram_t *dirty_vram =3D d->arch.hvm_domain.dirty_vram;
+    ASSERT( paging_locked_by_me(d) );
+    if ( dirty_vram )
+    {
+        struct list_head *curr;
+        list_for_each(curr, &dirty_vram->range_head)
+        {
+            dv_range_t *range =3D list_entry(curr, dv_range_t, range_link)=
;
+            if ( begin_pfn =3D=3D range->begin_pfn &&
+                 end_pfn   =3D=3D range->end_pfn )
+            {
+                return range;
+            }
+        }
+    }
+    return NULL;
+}
+
+/* Allocate specified dirty_vram range */
+static dv_range_t *
+_dirty_vram_range_alloc(struct domain *d,
+                        unsigned long begin_pfn,
+                        unsigned long nr)
+{
+    dv_dirty_vram_t *dirty_vram =3D d->arch.hvm_domain.dirty_vram;
+    dv_range_t *range =3D NULL;
+    unsigned long end_pfn =3D begin_pfn + nr;
+    dv_paddr_link_t *pl_tab =3D NULL;
+    int i;
+
+    ASSERT( paging_locked_by_me(d) );
+    ASSERT( dirty_vram !=3D NULL );
+
+#if DEBUG_allocating_dirty_vram_range
+    gdprintk(XENLOG_DEBUG,
+             "[%05lx:%05lx] Allocating dirty vram range hap:%d\n",
+             begin_pfn, end_pfn,
+             d->arch.hvm_domain.hap_enabled);
+#endif
+
+    range =3D xmalloc(dv_range_t);
+    if (range =3D=3D NULL)
+        goto err_out;
+
+    memset(range, 0, sizeof(dv_range_t));
+    INIT_LIST_HEAD(&range->range_link);
+
+    range->begin_pfn =3D begin_pfn;
+    range->end_pfn =3D end_pfn;
+
+    if (!hap_enabled(d))
+    {
+        if ( (pl_tab =3D xmalloc_array(dv_paddr_link_t, nr)) =3D=3D NULL )
+        {
+            goto err_out;
+        }
+        for (i =3D 0; i !=3D nr; i++)
+        {
+            pl_tab[i].sl1ma =3D INVALID_PADDR;
+            pl_tab[i].pl_next =3D NULL;
+        }
+    }
+
+    range->pl_tab =3D pl_tab;
+    range->mappings_hwm =3D 1;
+
+    list_add(&range->range_link, &dirty_vram->range_head);
+    if ( ++dirty_vram->nr_ranges > dirty_vram->ranges_hwm )
+    {
+        dirty_vram->ranges_hwm =3D dirty_vram->nr_ranges;
+#if DEBUG_high_water_mark_for_vram_ranges
+        gdprintk(XENLOG_DEBUG,
+                 "High water mark for number of vram ranges is now:%d\n",
+                 dirty_vram->ranges_hwm);
+#endif
+    }
+    return range;
+
+ err_out:
+    xfree(pl_tab);
+    xfree(range);
+    return NULL;
+}
+
+
+/* Frees specified dirty_vram range */
+void dirty_vram_range_free(struct domain *d,
+                           dv_range_t *range)
+{
+    dv_dirty_vram_t *dirty_vram =3D d->arch.hvm_domain.dirty_vram;
+    ASSERT( paging_locked_by_me(d) );
+    if ( dirty_vram )
+    {
+        int i, nr =3D range->end_pfn - range->begin_pfn;
+
+#if DEBUG_freeing_dirty_vram_range
+        gdprintk(XENLOG_DEBUG,
+                 "[%05lx:%05lx] Freeing dirty vram range\n",
+                 range->begin_pfn, range->end_pfn);
+#endif
+
+        if (range->pl_tab)
+        {
+            for (i =3D 0; i !=3D nr; i++)
+            {
+                dv_paddr_link_t *plx;
+                plx =3D range->pl_tab[i].pl_next;
+                /* Does current FB page have multiple mappings? */
+                if (plx) /* yes */
+                {
+                    /* Find the last element in singly-linked list */
+                    while (plx->pl_next !=3D NULL)
+                        plx =3D plx->pl_next;
+                    /* Prepend whole list to the free list */
+                    plx->pl_next =3D dirty_vram->pl_free;
+                    dirty_vram->pl_free =3D range->pl_tab[i].pl_next;
+                }
+            }
+            xfree(range->pl_tab);
+            range->pl_tab =3D NULL;
+        }
+
+        /* Remove range from the linked list, free it, and adjust count*/
+        list_del(&range->range_link);
+        xfree(range);
+        dirty_vram->nr_ranges--;
+    }
+}
+
+/* dirty_vram_range_alloc()
+ * This function ensures that the new range does not overlap any existing
+ * ranges -- deleting them if necessary -- and then calls _dirty_vram_rang=
e_alloc
+ * to actually allocate the new range.
+ */
+dv_range_t *
+dirty_vram_range_alloc(struct domain *d,
+                        unsigned long begin_pfn,
+                        unsigned long nr)
+{
+    unsigned long end_pfn =3D begin_pfn + nr;
+    dv_dirty_vram_t *dirty_vram =3D d->arch.hvm_domain.dirty_vram;
+    dv_range_t *range;
+    struct list_head *curr, *next;
+
+    ASSERT( paging_locked_by_me(d) );
+    ASSERT( dirty_vram !=3D NULL );
+
+    /* Ranges cannot overlap so
+     * free any range that overlaps [ begin_pfn .. end_pfn ) */
+    list_for_each_safe(curr, next, &dirty_vram->range_head)
+    {
+        dv_range_t *rng =3D list_entry(curr, dv_range_t, range_link);
+        if ( ((rng->begin_pfn <=3D begin_pfn) && (begin_pfn <  rng->end_pf=
n)) ||
+             ((begin_pfn <=3D rng->begin_pfn) && (rng->begin_pfn < end_pfn=
)) )
+        {
+            /* Different tracking, tear the previous down. */
+            dirty_vram_range_free(d, rng);
+        }
+    }
+
+    range =3D _dirty_vram_range_alloc(d, begin_pfn, nr);
+    if ( !range )
+        goto out;
+
+ out:
+    return range;
+}
+
+/* dirty_vram_range_find_or_alloc()
+ * Find the range for [begin_pfn:begin_pfn+nr).
+ * If it doesn't exists, create it.
+ */
+dv_range_t *
+dirty_vram_range_find_or_alloc(struct domain *d,
+                                unsigned long begin_pfn,
+                                unsigned long nr)
+{
+    dv_range_t *range;
+    ASSERT( paging_locked_by_me(d) );
+    range =3D dirty_vram_range_find(d, begin_pfn, nr);
+    if ( !range )
+        range =3D dirty_vram_range_alloc(d, begin_pfn, nr);
+    return range;
+}
+
+
+
+/* Allocate a dv_paddr_link struct */
+static dv_paddr_link_t *
+alloc_paddr_link(struct domain *d)
+{
+    dv_paddr_link_t * pl =3D NULL;
+    dv_dirty_vram_t *dirty_vram =3D d->arch.hvm_domain.dirty_vram;
+
+    ASSERT( paging_locked_by_me(d) );
+    BUILD_BUG_ON(sizeof(dv_paddr_link_ext_t) > PAGE_SIZE);
+    /* Is the list of free pl's empty? */
+    if (dirty_vram->pl_free =3D=3D NULL) /* yes */
+    {
+        /* Allocate another page of pl's.
+         * Link them all together and point the free list head at them */
+        int i;
+        dv_paddr_link_ext_t *ext =3D xmalloc(dv_paddr_link_ext_t);
+        if (ext =3D=3D NULL)
+            goto out;
+
+#if DEBUG_allocate_paddr_links_page
+        gdprintk(XENLOG_DEBUG, "Allocated another page of paddr_links\n");
+#endif
+        list_add(&ext->ext_link, &dirty_vram->ext_head);
+
+        /* initialize and link together the new pl entries */
+        for (i =3D 0; i !=3D ARRAY_SIZE(ext->entries); i++)
+        {
+            ext->entries[i].sl1ma =3D INVALID_PADDR;
+            ext->entries[i].pl_next =3D &ext->entries[i+1];
+        }
+        ext->entries[ARRAY_SIZE(ext->entries) - 1].pl_next =3D NULL;
+        dirty_vram->pl_free =3D &ext->entries[0];
+    }
+    pl =3D dirty_vram->pl_free;
+    dirty_vram->pl_free =3D pl->pl_next;
+
+    pl->sl1ma =3D INVALID_PADDR;
+    pl->pl_next =3D NULL;
+ out:
+    return pl;
+}
+
+
+/* Free a paddr_link struct, given address of its predecessor in linked li=
st */
+dv_paddr_link_t *
+free_paddr_link(struct domain *d,
+                dv_paddr_link_t **ppl,
+                dv_paddr_link_t *pl)
+{
+    dv_dirty_vram_t *dirty_vram =3D d->arch.hvm_domain.dirty_vram;
+    dv_paddr_link_t *npl; /* next pl */
+
+    ASSERT( paging_locked_by_me(d) );
+    /* extension mapping? */
+    if (ppl) /* yes. free it */
+    {
+        pl =3D (*ppl);
+        (*ppl) =3D npl =3D pl->pl_next;
+    }
+    else  /* main table */
+    {
+        /* move 2nd mapping to main table.
+         * and free 2nd mapping */
+        dv_paddr_link_t * spl;
+        spl =3D pl->pl_next;
+        if (spl =3D=3D NULL)
+        {
+            pl->sl1ma =3D INVALID_PADDR;
+            return pl;
+        }
+        pl->sl1ma =3D spl->sl1ma;
+        pl->pl_next =3D spl->pl_next;
+        npl =3D pl; /* reprocess main table entry again */
+        pl =3D spl;
+    }
+    pl->sl1ma =3D INVALID_PADDR;
+    pl->pl_next =3D dirty_vram->pl_free;
+    dirty_vram->pl_free =3D pl;
+    return npl;
+}
+
+
+/* dirty_vram_range_update()
+ * This is called whenever a level 1 page table entry is modified.
+ * If the L1PTE is being cleared, the function removes any paddr_links
+ * that refer to it.
+ * If the L1PTE is being set to a frame buffer page, a paddr_link is
+ * created for that page's entry in pl_tab.
+ * Returns 1 iff entry found and set or cleared.
+ */
+int dirty_vram_range_update(struct domain *d,
+                            unsigned long gfn,
+                            paddr_t sl1ma,
+                            int set)
+{
+    int effective =3D 0;
+    dv_range_t *range;
+
+    ASSERT(paging_locked_by_me(d));
+    range =3D dirty_vram_range_find_gfn(d, gfn);
+    if ( range )
+    {
+        unsigned long i =3D gfn - range->begin_pfn;
+        dv_paddr_link_t *pl =3D &range->pl_tab[ i ];
+        dv_paddr_link_t **ppl =3D NULL;
+        int len =3D 0;
+
+        /* find matching entry (pl), if any, and its predecessor
+         * in linked list (ppl) */
+        while (pl !=3D NULL)
+        {
+            if (pl->sl1ma =3D=3D sl1ma || pl->sl1ma =3D=3D INVALID_PADDR )
+                break;
+            ppl =3D &pl->pl_next;
+            pl =3D *ppl;
+            len++;
+        }
+
+        if (set)
+        {
+            /* Did we find sl1ma in either the main table or the linked li=
st? */
+            if (pl =3D=3D NULL) /* no, so we'll need to alloc a link */
+            {
+                ASSERT(ppl !=3D NULL);
+                /* alloc link and append it to list */
+                (*ppl) =3D pl =3D alloc_paddr_link(d);
+                if (pl =3D=3D NULL)
+                    goto out;
+            }
+            if ( pl->sl1ma !=3D sl1ma )
+            {
+                pl->sl1ma =3D sl1ma;
+                range->nr_mappings++;
+            }
+            effective =3D 1;
+            if (len > range->mappings_hwm)
+            {
+                range->mappings_hwm =3D len;
+#if DEBUG_update_vram_mapping
+                gdprintk(XENLOG_DEBUG,
+                         "[%lx] set      sl1ma:%lx hwm:%d mappings:%d free=
pages:%d\n",
+                         gfn, sl1ma,
+                         range->mappings_hwm,
+                         range->nr_mappings,
+                         d->arch.paging.shadow.free_pages);
+#endif
+            }
+        }
+        else /* clear */
+        {
+            if (pl && pl->sl1ma =3D=3D sl1ma )
+            {
+#if DEBUG_update_vram_mapping
+                gdprintk(XENLOG_DEBUG,
+                         "[%lx] clear    sl1ma:%lx mappings:%d\n",
+                         gfn, sl1ma,
+                         range->nr_mappings-1);
+#endif
+                free_paddr_link(d, ppl, pl);
+                if ( --range->nr_mappings =3D=3D 0 )
+                {
+                    dirty_vram_range_free(d, range);
+                }
+                effective =3D 1;
+            }
+        }
+    }
+ out:
+    return effective;
+}
+
+
+/* shadow_scan_dirty_flags()
+ * This produces a dirty bitmap for the range by examining every
+ * L1PTE referenced by some dv_paddr_link in the range's pl_tab table.
+ * It tests and clears each such L1PTE's dirty flag.
+ */
+static int shadow_scan_dirty_flags(struct domain *d,
+                                   dv_range_t *range,
+                                   uint8_t *dirty_bitmap)
+{
+    int flush_tlb =3D 0;
+    unsigned long i;
+    unsigned long nr =3D range->end_pfn - range->begin_pfn;
+#ifdef __i386__
+    unsigned long map_mfn =3D INVALID_MFN;
+    void *map_sl1p =3D NULL;
+#endif
+
+    ASSERT( paging_locked_by_me(d) );
+    /* Iterate over VRAM to track dirty bits. */
+    for ( i =3D 0; i < nr; i++ )
+    {
+        int dirty =3D 0, len =3D 1;
+        dv_paddr_link_t *pl;
+        for (pl =3D &range->pl_tab[i]; pl; pl =3D pl->pl_next, len++)
+        {
+#ifdef __i386__
+            void *sl1p;
+            unsigned long sl1mfn;
+#endif
+            l1_pgentry_t *sl1e;
+            paddr_t sl1ma =3D pl->sl1ma;
+            if (sl1ma =3D=3D INVALID_PADDR) /* FB page is unmapped */
+                continue;
+#ifdef __i386__
+            sl1p =3D map_sl1p;
+            sl1mfn =3D paddr_to_pfn(sl1ma);
+
+            if ( sl1mfn !=3D map_mfn )
+            {
+                if ( map_sl1p )
+                    sh_unmap_domain_page(map_sl1p);
+                map_sl1p =3D sl1p =3D sh_map_domain_page(_mfn(sl1mfn));
+                map_mfn =3D sl1mfn;
+            }
+            sl1e =3D sl1p + (sl1ma & ~PAGE_MASK);
+#else
+            sl1e =3D maddr_to_virt(sl1ma);
+#endif
+            if ( l1e_get_flags(*sl1e) & _PAGE_DIRTY )
+            {
+                dirty =3D 1;
+                /* Clear dirty so we can detect if page gets re-dirtied */
+                /* Note: this is atomic, so we may clear a
+                 * _PAGE_ACCESSED set by another processor. */
+                l1e_remove_flags(*sl1e, _PAGE_DIRTY);
+                flush_tlb =3D 1;
+            }
+        } /* for */
+        if ( dirty )
+        {
+            dirty_bitmap[i >> 3] |=3D (1 << (i & 7));
+        }
+    }
+
+#ifdef __i386__
+    if ( map_sl1p )
+        sh_unmap_domain_page(map_sl1p);
+#endif
+    return flush_tlb;
+}
+
+
+/* shadow_track_dirty_vram()
+ * This is the API called by the guest to determine which pages in the ran=
ge
+ * from [begin_pfn:begin_pfn+nr) have been dirtied since the last call.
+ * It creates the domain's dv_dirty_vram on demand.
+ * It creates ranges on demand when some [begin_pfn:nr) is first encounter=
ed.
+ * To collect the dirty bitmask it calls shadow_scan_dirty_flags().
+ * It copies the dirty bitmask into guest storage.
+ */
+int shadow_track_dirty_vram(struct domain *d,
+                            unsigned long begin_pfn,
+                            unsigned long nr,
+                            XEN_GUEST_HANDLE_64(uint8) guest_dirty_bitmap)
+{
+    int rc =3D 0;
+    unsigned long end_pfn =3D begin_pfn + nr;
+    int flush_tlb =3D 0;
+    dv_range_t *range;
+    struct p2m_domain *p2m =3D p2m_get_hostp2m(d);
+
+    if (end_pfn < begin_pfn
+            || begin_pfn > p2m->max_mapped_pfn
+            || end_pfn >=3D p2m->max_mapped_pfn)
+        return -EINVAL;
+
+    paging_lock(d);
+
+    if ( !nr || guest_handle_is_null(guest_dirty_bitmap) )
+    {
+        goto out;
+    }
+
+    if ( !dirty_vram_find_or_alloc(d))
+    {
+        rc =3D -ENOMEM;
+        goto out;
+    }
+
+    range =3D dirty_vram_range_find(d, begin_pfn, nr);
+    if ( !range )
+    {
+        range =3D dirty_vram_range_alloc(d, begin_pfn, nr);
+        if ( range )
+            sh_find_all_vram_mappings(d->vcpu[0], range);
+    }
+    if ( range )
+    {
+        int size =3D (nr + BITS_PER_LONG - 1) / BITS_PER_LONG;
+        unsigned long dirty_bitmap[size];
+
+        memset(dirty_bitmap, 0x00, size * BYTES_PER_LONG);
+
+       flush_tlb |=3D shadow_scan_dirty_flags(d, range, (uint8_t*)dirty_bi=
tmap);
+
+        rc =3D -EFAULT;
+        if ( copy_to_guest(guest_dirty_bitmap,
+                           (uint8_t*)dirty_bitmap,
+                           size * BYTES_PER_LONG) =3D=3D 0 )
+            rc =3D 0;
+    }
+    if ( flush_tlb )
+        flush_tlb_mask(d->domain_dirty_cpumask);
+
+out:
+    paging_unlock(d);
+    return rc;
+}
+
+
+/************************************************/
+/*          HAP VRAM TRACKING SUPPORT           */
+/************************************************/
+
+/* hap_enable_vram_tracking()
+ * For all ranges, mark all vram pages in range as logdirty read-only.
+ */
+static int hap_enable_vram_tracking(struct domain *d)
+{
+    int rc =3D 0;
+    dv_dirty_vram_t *dirty_vram;
+    struct list_head *curr;
+
+    /* turn on PG_log_dirty bit in paging mode */
+    paging_lock(d);
+    d->arch.paging.mode |=3D PG_log_dirty;
+    paging_unlock(d);
+
+    p2m_lock(p2m_get_hostp2m(d));
+    paging_lock(d);
+
+    dirty_vram =3D d->arch.hvm_domain.dirty_vram;
+
+    /* dirty_vram !=3D NULL iff we're tracking dirty vram.
+     * If we start tracking dirty pages for all memory then
+     * the dirty_vram structure is freed. */
+    if ( !dirty_vram )
+    {
+        rc =3D -EINVAL;
+        goto out;
+    }
+
+    /* set l1e entries of P2M table to be read-only. */
+    list_for_each(curr, &dirty_vram->range_head)
+      {
+       dv_range_t *range =3D list_entry(curr, dv_range_t, range_link);
+       gdprintk(XENLOG_DEBUG, "[%05lx:%05lx] enable  vram tracking\n",
+                range->begin_pfn, range->end_pfn);
+       p2m_change_type_range(d, range->begin_pfn, range->end_pfn,
+                             p2m_ram_rw, p2m_ram_logdirty);
+      }
+
+    flush_tlb_mask(d->domain_dirty_cpumask);
+ out:
+    paging_unlock(d);
+    p2m_unlock(p2m_get_hostp2m(d));
+    if (rc)
+    {
+        paging_lock(d);
+        d->arch.paging.mode &=3D ~PG_log_dirty;
+        paging_unlock(d);
+    }
+    return rc;
+}
+
+/* hap_disable_vram_tracking()
+ * For all ranges, mark all vram pages in range as logdirty read-write.
+ */
+static int hap_disable_vram_tracking(struct domain *d)
+{
+    int rc =3D 0;
+    dv_dirty_vram_t *dirty_vram;
+    struct list_head *curr;
+
+    paging_lock(d);
+    d->arch.paging.mode &=3D ~PG_log_dirty;
+    paging_unlock(d);
+
+    p2m_lock(p2m_get_hostp2m(d));
+    paging_lock(d);
+
+    dirty_vram =3D d->arch.hvm_domain.dirty_vram;
+    if ( !dirty_vram )
+    {
+        rc =3D -EINVAL;
+        goto out;
+    }
+
+    /* set l1e entries of P2M table with normal mode */
+    list_for_each(curr, &dirty_vram->range_head)
+      {
+       dv_range_t *range =3D list_entry(curr, dv_range_t, range_link);
+       gdprintk(XENLOG_DEBUG, "[%05lx:%05lx] disable vram tracking\n",
+                range->begin_pfn, range->end_pfn);
+       p2m_change_type_range(d, range->begin_pfn, range->end_pfn,
+                             p2m_ram_logdirty, p2m_ram_rw);
+      }
+    flush_tlb_mask(d->domain_dirty_cpumask);
+ out:
+    paging_unlock(d);
+    p2m_unlock(p2m_get_hostp2m(d));
+    if (rc)
+    {
+        paging_lock(d);
+        d->arch.paging.mode |=3D PG_log_dirty;
+        paging_unlock(d);
+    }
+    return rc;
+}
+
+/* hap_clean_vram_tracking_range()
+ * For all the pages in the range specified by [begin_pfn,nr),
+ * note in the dirty bitmap any page that has been marked as read-write,
+ * which signifies that the page has been dirtied, and reset the page
+ * to ram_logdirty.
+ */
+void hap_clean_vram_tracking_range(struct domain *d,
+                                   unsigned long begin_pfn,
+                                   unsigned long nr,
+                                   uint8_t *dirty_bitmap)
+{
+    int i;
+    unsigned long pfn;
+    dv_dirty_vram_t *dirty_vram =3D d->arch.hvm_domain.dirty_vram;
+    dv_range_t *range;
+
+    ASSERT(p2m_locked_by_me(p2m_get_hostp2m(d)));
+    ASSERT(paging_locked_by_me(d));
+
+    if ( !dirty_vram )
+    {
+        gdprintk(XENLOG_DEBUG, "Should only be called while tracking dirty=
 vram.\n");
+        return;
+    }
+
+    range =3D dirty_vram_range_find(d, begin_pfn, nr);
+    if (!range)
+        return;
+
+    /* set l1e entries of P2M table to be read-only. */
+    /* On first write, it page faults, its entry is changed to read-write,
+     * its bit in the dirty bitmap is set, and on retry the write succeeds=
. */
+    for (i =3D 0, pfn =3D range->begin_pfn; pfn < range->end_pfn; i++, pfn=
++)
+    {
+        p2m_type_t pt;
+        pt =3D p2m_change_type(d, pfn, p2m_ram_rw, p2m_ram_logdirty);
+        if (pt =3D=3D p2m_ram_rw)
+            dirty_bitmap[i >> 3] |=3D (1 << (i & 7));
+    }
+    flush_tlb_mask(d->domain_dirty_cpumask);
+}
+
+static void hap_vram_tracking_init(struct domain *d)
+{
+    paging_log_dirty_init(d, hap_enable_vram_tracking,
+                          hap_disable_vram_tracking,
+                          NULL);
+}
+
+/* hap_track_dirty_vram()
+ * Create the domain's dv_dirty_vram struct on demand.
+ * Create a dirty vram range on demand when some [begin_pfn:begin_pfn+nr] =
is first encountered.
+ * Collect the guest_dirty bitmask, a bit mask of the dirties vram pages, =
by
+ * calling paging_log_dirty_range().
+ */
+int hap_track_dirty_vram(struct domain *d,
+                         unsigned long begin_pfn,
+                         unsigned long nr,
+                         XEN_GUEST_HANDLE_64(uint8) guest_dirty_bitmap)
+{
+    long rc =3D 0;
+    dv_dirty_vram_t *dirty_vram;
+    int restart_log_dirty =3D 0;
+
+    paging_lock(d);
+    dirty_vram =3D d->arch.hvm_domain.dirty_vram;
+    if ( nr )
+    {
+        dv_range_t *range =3D NULL;
+        int size =3D (nr + BITS_PER_LONG - 1) / BITS_PER_LONG;
+        unsigned long dirty_bitmap[size];
+
+        /* Already tracking dirty vram? */
+        if ( paging_mode_log_dirty(d) && dirty_vram ) /* yes */
+        {
+            /* Handle the addition of another range */
+            range =3D dirty_vram_range_find(d, begin_pfn, nr);
+            if ( !range )
+            {
+                rc =3D -ENOMEM;
+                if ( !(range =3D dirty_vram_range_alloc(d, begin_pfn, nr))=
 )
+                    goto param_fail;
+                restart_log_dirty =3D 1;
+            }
+        }
+        /* Just starting to track dirty vram? */
+        else if ( !paging_mode_log_dirty(d) && !dirty_vram ) /* yes */
+        {
+            rc =3D -ENOMEM;
+            if ( !(dirty_vram =3D dirty_vram_alloc(d)) )
+                goto param_fail;
+
+            if ( !(range =3D dirty_vram_range_find_or_alloc(d, begin_pfn, =
nr)) )
+                goto param_fail;
+
+            restart_log_dirty =3D 1;
+            /* Initialize callbacks for vram tracking */
+            hap_vram_tracking_init(d);
+        }
+        else
+        {
+            /* Test for invalid combination */
+            if ( !paging_mode_log_dirty(d) && dirty_vram )
+                rc =3D -EINVAL;
+            else /* logging dirty of all memory, not tracking dirty vram *=
/
+                rc =3D -ENODATA;
+            goto param_fail;
+        }
+
+        if (restart_log_dirty)
+        {
+            /* disable then enable log dirty */
+            paging_unlock(d);
+            if (paging_mode_log_dirty(d))
+                paging_log_dirty_disable(d);
+
+            rc =3D paging_log_dirty_enable(d);
+            paging_lock(d);
+            if (rc !=3D 0)
+                goto param_fail;
+        }
+
+        paging_unlock(d);
+        memset(dirty_bitmap, 0x00, size * BYTES_PER_LONG);
+       paging_log_dirty_range(d, begin_pfn, nr, (uint8_t*)dirty_bitmap);
+        rc =3D -EFAULT;
+        if ( copy_to_guest(guest_dirty_bitmap,
+                           (uint8_t*)dirty_bitmap,
+                           size * BYTES_PER_LONG) =3D=3D 0 )
+        {
+            rc =3D 0;
+        }
+    }
+    else
+    {
+        /* If zero pages specified while already tracking dirty vram
+         * then stop tracking */
+        if ( paging_mode_log_dirty(d) && dirty_vram ) {
+            paging_unlock(d);
+            rc =3D paging_log_dirty_disable(d);
+            paging_lock(d);
+            dirty_vram_free(d);
+        } else /* benign no-op */
+        {
+            rc =3D 0;
+        }
+        paging_unlock(d);
+    }
+
+    return rc;
+
+param_fail:
+    dirty_vram_free(d);
+    paging_unlock(d);
+    return rc;
+}
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index a5a1bcf..55553e4 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -57,6 +57,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1433,8 +1434,7 @@ int hvm_hap_nested_page_fault(paddr_t gpa,
          */
         if ( access_w )
         {
-            paging_mark_dirty(v->domain, mfn_x(mfn));
-            p2m_change_type(v->domain, gfn, p2m_ram_logdirty, p2m_ram_rw);
+            paging_mark_dirty_hap(v->domain, gfn, mfn_x(mfn));
         }
         rc =3D 1;
         goto out_put_gfn;
diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index d2637d3..f31e4e5 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -41,6 +41,7 @@
 #include 
 #include 
 #include 
+#include 

 #include "private.h"

@@ -53,139 +54,6 @@
 #define page_to_mfn(_pg) _mfn(__page_to_mfn(_pg))

 /************************************************/
-/*          HAP VRAM TRACKING SUPPORT           */
-/************************************************/
-
-static int hap_enable_vram_tracking(struct domain *d)
-{
-    struct sh_dirty_vram *dirty_vram =3D d->arch.hvm_domain.dirty_vram;
-
-    if ( !dirty_vram )
-        return -EINVAL;
-
-    /* turn on PG_log_dirty bit in paging mode */
-    paging_lock(d);
-    d->arch.paging.mode |=3D PG_log_dirty;
-    paging_unlock(d);
-
-    /* set l1e entries of P2M table to be read-only. */
-    p2m_change_type_range(d, dirty_vram->begin_pfn, dirty_vram->end_pfn,
-                          p2m_ram_rw, p2m_ram_logdirty);
-
-    flush_tlb_mask(d->domain_dirty_cpumask);
-    return 0;
-}
-
-static int hap_disable_vram_tracking(struct domain *d)
-{
-    struct sh_dirty_vram *dirty_vram =3D d->arch.hvm_domain.dirty_vram;
-
-    if ( !dirty_vram )
-        return -EINVAL;
-
-    paging_lock(d);
-    d->arch.paging.mode &=3D ~PG_log_dirty;
-    paging_unlock(d);
-
-    /* set l1e entries of P2M table with normal mode */
-    p2m_change_type_range(d, dirty_vram->begin_pfn, dirty_vram->end_pfn,
-                          p2m_ram_logdirty, p2m_ram_rw);
-
-    flush_tlb_mask(d->domain_dirty_cpumask);
-    return 0;
-}
-
-static void hap_clean_vram_tracking(struct domain *d)
-{
-    struct sh_dirty_vram *dirty_vram =3D d->arch.hvm_domain.dirty_vram;
-
-    if ( !dirty_vram )
-        return;
-
-    /* set l1e entries of P2M table to be read-only. */
-    p2m_change_type_range(d, dirty_vram->begin_pfn, dirty_vram->end_pfn,
-                          p2m_ram_rw, p2m_ram_logdirty);
-
-    flush_tlb_mask(d->domain_dirty_cpumask);
-}
-
-static void hap_vram_tracking_init(struct domain *d)
-{
-    paging_log_dirty_init(d, hap_enable_vram_tracking,
-                          hap_disable_vram_tracking,
-                          hap_clean_vram_tracking);
-}
-
-int hap_track_dirty_vram(struct domain *d,
-                         unsigned long begin_pfn,
-                         unsigned long nr,
-                         XEN_GUEST_HANDLE_64(uint8) dirty_bitmap)
-{
-    long rc =3D 0;
-    struct sh_dirty_vram *dirty_vram =3D d->arch.hvm_domain.dirty_vram;
-
-    if ( nr )
-    {
-        if ( paging_mode_log_dirty(d) && dirty_vram )
-        {
-            if ( begin_pfn !=3D dirty_vram->begin_pfn ||
-                 begin_pfn + nr !=3D dirty_vram->end_pfn )
-            {
-                paging_log_dirty_disable(d);
-                dirty_vram->begin_pfn =3D begin_pfn;
-                dirty_vram->end_pfn =3D begin_pfn + nr;
-                rc =3D paging_log_dirty_enable(d);
-                if (rc !=3D 0)
-                    goto param_fail;
-            }
-        }
-        else if ( !paging_mode_log_dirty(d) && !dirty_vram )
-        {
-            rc =3D -ENOMEM;
-            if ( (dirty_vram =3D xmalloc(struct sh_dirty_vram)) =3D=3D NUL=
L )
-                goto param_fail;
-
-            dirty_vram->begin_pfn =3D begin_pfn;
-            dirty_vram->end_pfn =3D begin_pfn + nr;
-            d->arch.hvm_domain.dirty_vram =3D dirty_vram;
-            hap_vram_tracking_init(d);
-            rc =3D paging_log_dirty_enable(d);
-            if (rc !=3D 0)
-                goto param_fail;
-        }
-        else
-        {
-            if ( !paging_mode_log_dirty(d) && dirty_vram )
-                rc =3D -EINVAL;
-            else
-                rc =3D -ENODATA;
-            goto param_fail;
-        }
-        /* get the bitmap */
-        rc =3D paging_log_dirty_range(d, begin_pfn, nr, dirty_bitmap);
-    }
-    else
-    {
-        if ( paging_mode_log_dirty(d) && dirty_vram ) {
-            rc =3D paging_log_dirty_disable(d);
-            xfree(dirty_vram);
-            dirty_vram =3D d->arch.hvm_domain.dirty_vram =3D NULL;
-        } else
-            rc =3D 0;
-    }
-
-    return rc;
-
-param_fail:
-    if ( dirty_vram )
-    {
-        xfree(dirty_vram);
-        dirty_vram =3D d->arch.hvm_domain.dirty_vram =3D NULL;
-    }
-    return rc;
-}
-
-/************************************************/
 /*            HAP LOG DIRTY SUPPORT             */
 /************************************************/

@@ -223,14 +91,12 @@ static void hap_clean_dirty_bitmap(struct domain *d)

 void hap_logdirty_init(struct domain *d)
 {
-    struct sh_dirty_vram *dirty_vram =3D d->arch.hvm_domain.dirty_vram;
+    struct dv_dirty_vram *dirty_vram =3D d->arch.hvm_domain.dirty_vram;
     if ( paging_mode_log_dirty(d) && dirty_vram )
     {
         paging_log_dirty_disable(d);
-        xfree(dirty_vram);
-        dirty_vram =3D d->arch.hvm_domain.dirty_vram =3D NULL;
+        dirty_vram_free(d);
     }
-
     /* Reinitialize logdirty mechanism */
     paging_log_dirty_init(d, hap_enable_log_dirty,
                           hap_disable_log_dirty,
diff --git a/xen/arch/x86/mm/paging.c b/xen/arch/x86/mm/paging.c
index ca879f9..7464b07 100644
--- a/xen/arch/x86/mm/paging.c
+++ b/xen/arch/x86/mm/paging.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 

@@ -278,6 +279,46 @@ out:
 }


+/* paging_mark_dirty_hap()
+ * Make a hap page writeable and mark it as dirty.
+ * This done atomically under the p2m and paging locks to avoid leaving
+ * a window where the page might be modified without being marked as dirty=
.
+ */
+void paging_mark_dirty_hap(struct domain *d,
+                           unsigned long pfn,
+                           unsigned long guest_mfn)
+{
+    mfn_t gmfn;
+    p2m_type_t pt;
+    struct p2m_domain *p2m =3D p2m_get_hostp2m(d);
+
+    if ( !paging_mode_log_dirty(d) )
+        return;
+
+    gmfn =3D _mfn(guest_mfn);
+
+    ASSERT( mfn_valid(gmfn) &&
+            page_get_owner(mfn_to_page(gmfn)) =3D=3D d );
+
+    p2m_lock(p2m);
+    pt =3D p2m_change_type(d, pfn, p2m_ram_logdirty, p2m_ram_rw);
+    paging_lock(d);
+    if ( pt =3D=3D p2m_ram_logdirty )
+    {
+        dv_range_t *range;
+        PAGING_DEBUG(LOGDIRTY,
+                     "marked mfn %" PRI_mfn " (pfn=3D%lx), dom %d\n",
+                     mfn_x(gmfn), pfn, d->domain_id);
+        d->arch.paging.log_dirty.dirty_count++;
+        range =3D dirty_vram_range_find_gfn(d, pfn);
+        if (range)
+            range->dirty_count++;
+    }
+    paging_mark_dirty(d, guest_mfn);
+    paging_unlock(d);
+    p2m_unlock(p2m);
+}
+
 /* Is this guest page dirty? */
 int paging_mfn_is_dirty(struct domain *d, mfn_t gmfn)
 {
@@ -333,8 +374,11 @@ int paging_log_dirty_op(struct domain *d, struct xen_d=
omctl_shadow_op *sc)
     mfn_t *l4, *l3, *l2;
     unsigned long *l1;
     int i4, i3, i2;
+    struct p2m_domain *p2m =3D p2m_get_hostp2m(d);

     domain_pause(d);
+    /* Locking hierarchy requires p2m lock to be taken first */
+    p2m_lock(p2m);
     paging_lock(d);

     clean =3D (sc->op =3D=3D XEN_DOMCTL_SHADOW_OP_CLEAN);
@@ -345,6 +389,14 @@ int paging_log_dirty_op(struct domain *d, struct xen_d=
omctl_shadow_op *sc)
                  d->arch.paging.log_dirty.fault_count,
                  d->arch.paging.log_dirty.dirty_count);

+    if (hap_enabled(d) && d->arch.hvm_domain.dirty_vram)
+    {
+        /* If we're cleaning/peeking all guest memory, we should not be tr=
acking
+         * dirty vram. */
+        rv =3D -EINVAL;
+        goto out;
+    }
+
     sc->stats.fault_count =3D d->arch.paging.log_dirty.fault_count;
     sc->stats.dirty_count =3D d->arch.paging.log_dirty.dirty_count;

@@ -424,170 +476,60 @@ int paging_log_dirty_op(struct domain *d, struct xen=
_domctl_shadow_op *sc)

     if ( clean )
     {
-        /* We need to further call clean_dirty_bitmap() functions of speci=
fic
-         * paging modes (shadow or hap).  Safe because the domain is pause=
d. */
-        d->arch.paging.log_dirty.clean_dirty_bitmap(d);
+        /* Is null if tracking dirty vram */
+        if (d->arch.paging.log_dirty.clean_dirty_bitmap)
+        {
+            /* We need to further call clean_dirty_bitmap() functions of s=
pecific
+             * paging modes (shadow or hap).  Safe because the domain is p=
aused. */
+            d->arch.paging.log_dirty.clean_dirty_bitmap(d);
+        }
     }
     domain_unpause(d);
     return rv;

  out:
     paging_unlock(d);
+    p2m_unlock(p2m);
     domain_unpause(d);
     return rv;
 }

-int paging_log_dirty_range(struct domain *d,
-                            unsigned long begin_pfn,
-                            unsigned long nr,
-                            XEN_GUEST_HANDLE_64(uint8) dirty_bitmap)
+void paging_log_dirty_range(struct domain *d,
+                           unsigned long begin_pfn,
+                           unsigned long nr,
+                           uint8_t *dirty_bitmap)
 {
-    int rv =3D 0;
-    unsigned long pages =3D 0;
-    mfn_t *l4, *l3, *l2;
-    unsigned long *l1;
-    int b1, b2, b3, b4;
-    int i2, i3, i4;
-
-    d->arch.paging.log_dirty.clean_dirty_bitmap(d);
+    struct p2m_domain *p2m =3D p2m_get_hostp2m(d);
+    dv_range_t *range;
+    unsigned int range_dirty_count =3D 0;
+
+    p2m_lock(p2m);
     paging_lock(d);

-    PAGING_DEBUG(LOGDIRTY, "log-dirty-range: dom %u faults=3D%u dirty=3D%u=
\n",
-                 d->domain_id,
-                 d->arch.paging.log_dirty.fault_count,
-                 d->arch.paging.log_dirty.dirty_count);
-
-    if ( unlikely(d->arch.paging.log_dirty.failed_allocs) ) {
-        printk("%s: %d failed page allocs while logging dirty pages\n",
-               __FUNCTION__, d->arch.paging.log_dirty.failed_allocs);
-        rv =3D -ENOMEM;
-        goto out;
-    }
-
-    if ( !d->arch.paging.log_dirty.fault_count &&
-         !d->arch.paging.log_dirty.dirty_count ) {
-        unsigned int size =3D BITS_TO_LONGS(nr);
-
-        if ( clear_guest(dirty_bitmap, size * BYTES_PER_LONG) !=3D 0 )
-            rv =3D -EFAULT;
-        goto out;
-    }
-    d->arch.paging.log_dirty.fault_count =3D 0;
-    d->arch.paging.log_dirty.dirty_count =3D 0;
-
-    b1 =3D L1_LOGDIRTY_IDX(begin_pfn);
-    b2 =3D L2_LOGDIRTY_IDX(begin_pfn);
-    b3 =3D L3_LOGDIRTY_IDX(begin_pfn);
-    b4 =3D L4_LOGDIRTY_IDX(begin_pfn);
-    l4 =3D paging_map_log_dirty_bitmap(d);
-
-    for ( i4 =3D b4;
-          (pages < nr) && (i4 < LOGDIRTY_NODE_ENTRIES);
-          i4++ )
+    /* Only called when tracking dirty vram in HAP mode */
+    ASSERT(hap_enabled(d) && d->arch.hvm_domain.dirty_vram);
+
+    range =3D dirty_vram_range_find_gfn(d, begin_pfn);
+    if (range)
     {
-        l3 =3D (l4 && mfn_valid(l4[i4])) ? map_domain_page(mfn_x(l4[i4])) =
: NULL;
-        for ( i3 =3D b3;
-              (pages < nr) && (i3 < LOGDIRTY_NODE_ENTRIES);
-              i3++ )
-        {
-            l2 =3D ((l3 && mfn_valid(l3[i3])) ?
-                  map_domain_page(mfn_x(l3[i3])) : NULL);
-            for ( i2 =3D b2;
-                  (pages < nr) && (i2 < LOGDIRTY_NODE_ENTRIES);
-                  i2++ )
-            {
-                unsigned int bytes =3D PAGE_SIZE;
-                uint8_t *s;
-                l1 =3D ((l2 && mfn_valid(l2[i2])) ?
-                      map_domain_page(mfn_x(l2[i2])) : NULL);
-
-                s =3D ((uint8_t*)l1) + (b1 >> 3);
-                bytes -=3D b1 >> 3;
-
-                if ( likely(((nr - pages + 7) >> 3) < bytes) )
-                    bytes =3D (unsigned int)((nr - pages + 7) >> 3);
-
-                if ( !l1 )
-                {
-                    if ( clear_guest_offset(dirty_bitmap, pages >> 3,
-                                            bytes) !=3D 0 )
-                    {
-                        rv =3D -EFAULT;
-                        goto out;
-                    }
-                }
-                /* begin_pfn is not 32K aligned, hence we have to bit
-                 * shift the bitmap */
-                else if ( b1 & 0x7 )
-                {
-                    int i, j;
-                    uint32_t *l =3D (uint32_t*) s;
-                    int bits =3D b1 & 0x7;
-                    int bitmask =3D (1 << bits) - 1;
-                    int size =3D (bytes + BYTES_PER_LONG - 1) / BYTES_PER_=
LONG;
-                    unsigned long bitmap[size];
-                    static unsigned long printed =3D 0;
-
-                    if ( printed !=3D begin_pfn )
-                    {
-                        dprintk(XENLOG_DEBUG, "%s: begin_pfn %lx is not 32=
K aligned!\n",
-                                __FUNCTION__, begin_pfn);
-                        printed =3D begin_pfn;
-                    }
-
-                    for ( i =3D 0; i < size - 1; i++, l++ ) {
-                        bitmap[i] =3D ((*l) >> bits) |
-                            (((*((uint8_t*)(l + 1))) & bitmask) << (sizeof=
(*l) * 8 - bits));
-                    }
-                    s =3D (uint8_t*) l;
-                    size =3D BYTES_PER_LONG - ((b1 >> 3) & 0x3);
-                    bitmap[i] =3D 0;
-                    for ( j =3D 0; j < size; j++, s++ )
-                        bitmap[i] |=3D (*s) << (j * 8);
-                    bitmap[i] =3D (bitmap[i] >> bits) | (bitmask << (size =
* 8 - bits));
-                    if ( copy_to_guest_offset(dirty_bitmap, (pages >> 3),
-                                (uint8_t*) bitmap, bytes) !=3D 0 )
-                    {
-                        rv =3D -EFAULT;
-                        goto out;
-                    }
-                }
-                else
-                {
-                    if ( copy_to_guest_offset(dirty_bitmap, pages >> 3,
-                                              s, bytes) !=3D 0 )
-                    {
-                        rv =3D -EFAULT;
-                        goto out;
-                    }
-                }
-
-                pages +=3D bytes << 3;
-                if ( l1 )
-                {
-                    clear_page(l1);
-                    unmap_domain_page(l1);
-                }
-                b1 =3D b1 & 0x7;
-            }
-            b2 =3D 0;
-            if ( l2 )
-                unmap_domain_page(l2);
-        }
-        b3 =3D 0;
-        if ( l3 )
-            unmap_domain_page(l3);
+        range_dirty_count =3D range->dirty_count;
+        range->dirty_count =3D 0;
     }
-    if ( l4 )
-        unmap_domain_page(l4);
-
-    paging_unlock(d);
+
+    if ( !range_dirty_count)
+        goto out;

-    return rv;
+    PAGING_DEBUG(LOGDIRTY, "log-dirty-range: dom %u [%05lx:%05lx] range_di=
rty=3D%u\n",
+                 d->domain_id,
+                 begin_pfn,
+                 range->end_pfn,
+                 range_dirty_count);

+    hap_clean_vram_tracking_range(d, begin_pfn, nr, dirty_bitmap);
  out:
     paging_unlock(d);
-    return rv;
+    p2m_unlock(p2m);
+    return;
 }

 /* Note that this function takes three function pointers. Callers must sup=
ply
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/commo=
n.c
index 3f8ad88..c9f3495 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -36,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "private.h"

@@ -3121,12 +3122,7 @@ void shadow_teardown(struct domain *d)
      * calls now that we've torn down the bitmap */
     d->arch.paging.mode &=3D ~PG_log_dirty;

-    if (d->arch.hvm_domain.dirty_vram) {
-        xfree(d->arch.hvm_domain.dirty_vram->sl1ma);
-        xfree(d->arch.hvm_domain.dirty_vram->dirty_bitmap);
-        xfree(d->arch.hvm_domain.dirty_vram);
-        d->arch.hvm_domain.dirty_vram =3D NULL;
-    }
+    dirty_vram_free(d);

     paging_unlock(d);

@@ -3463,179 +3459,212 @@ void shadow_clean_dirty_bitmap(struct domain *d)


 /*************************************************************************=
*/
-/* VRAM dirty tracking support */
-int shadow_track_dirty_vram(struct domain *d,
-                            unsigned long begin_pfn,
-                            unsigned long nr,
-                            XEN_GUEST_HANDLE_64(uint8) dirty_bitmap)
-{
-    int rc;
-    unsigned long end_pfn =3D begin_pfn + nr;
-    unsigned long dirty_size =3D (nr + 7) / 8;
-    int flush_tlb =3D 0;
-    unsigned long i;
-    p2m_type_t t;
-    struct sh_dirty_vram *dirty_vram =3D d->arch.hvm_domain.dirty_vram;
-    struct p2m_domain *p2m =3D p2m_get_hostp2m(d);
-
-    if (end_pfn < begin_pfn
-            || begin_pfn > p2m->max_mapped_pfn
-            || end_pfn >=3D p2m->max_mapped_pfn)
-        return -EINVAL;
-
-    /* We perform p2m lookups, so lock the p2m upfront to avoid deadlock *=
/
-    p2m_lock(p2m_get_hostp2m(d));
-    paging_lock(d);
+/* Support functions for shadow-based dirty VRAM code */

-    if ( dirty_vram && (!nr ||
-             ( begin_pfn !=3D dirty_vram->begin_pfn
-            || end_pfn   !=3D dirty_vram->end_pfn )) )
-    {
-        /* Different tracking, tear the previous down. */
-        gdprintk(XENLOG_INFO, "stopping tracking VRAM %lx - %lx\n", dirty_=
vram->begin_pfn, dirty_vram->end_pfn);
-        xfree(dirty_vram->sl1ma);
-        xfree(dirty_vram->dirty_bitmap);
-        xfree(dirty_vram);
-        dirty_vram =3D d->arch.hvm_domain.dirty_vram =3D NULL;
-    }
+#define DEBUG_unshadow_sl1ma                  0
+#define DEBUG_unshadow_sl1ma_detail           0
+#define DEBUG_count_initial_mappings          1

-    if ( !nr )
+/* smfn is no longer a shadow page.  Remove it from any
+ * dirty vram range mapping. */
+void
+dirty_vram_delete_shadow(struct vcpu *v,
+                         unsigned long gfn,
+                         unsigned int shadow_type,
+                         mfn_t smfn)
+{
+    static unsigned int l1_shadow_mask =3D
+          1 << SH_type_l1_32_shadow
+        | 1 << SH_type_fl1_32_shadow
+        | 1 << SH_type_l1_pae_shadow
+        | 1 << SH_type_fl1_pae_shadow
+        | 1 << SH_type_l1_64_shadow
+        | 1 << SH_type_fl1_64_shadow
+        ;
+    struct domain *d =3D v->domain;
+    dv_dirty_vram_t *dirty_vram;
+    struct list_head *curr, *next;
+
+    ASSERT(paging_locked_by_me(d));
+    /* Ignore all but level 1 shadows */
+
+    if ((l1_shadow_mask & (1 << shadow_type)) =3D=3D 0)
     {
-        rc =3D 0;
         goto out;
     }

-    /* This should happen seldomly (Video mode change),
-     * no need to be careful. */
+    dirty_vram =3D d->arch.hvm_domain.dirty_vram;
     if ( !dirty_vram )
     {
-        /* Throw away all the shadows rather than walking through them
-         * up to nr times getting rid of mappings of each pfn */
-        shadow_blow_tables(d);
-
-        gdprintk(XENLOG_INFO, "tracking VRAM %lx - %lx\n", begin_pfn, end_=
pfn);
-
-        rc =3D -ENOMEM;
-        if ( (dirty_vram =3D xmalloc(struct sh_dirty_vram)) =3D=3D NULL )
-            goto out;
-        dirty_vram->begin_pfn =3D begin_pfn;
-        dirty_vram->end_pfn =3D end_pfn;
-        d->arch.hvm_domain.dirty_vram =3D dirty_vram;
-
-        if ( (dirty_vram->sl1ma =3D xmalloc_array(paddr_t, nr)) =3D=3D NUL=
L )
-            goto out_dirty_vram;
-        memset(dirty_vram->sl1ma, ~0, sizeof(paddr_t) * nr);
-
-        if ( (dirty_vram->dirty_bitmap =3D xzalloc_array(uint8_t, dirty_si=
ze)) =3D=3D NULL )
-            goto out_sl1ma;
-
-        dirty_vram->last_dirty =3D NOW();
-
-        /* Tell the caller that this time we could not track dirty bits. *=
/
-        rc =3D -ENODATA;
-    }
-    else if (dirty_vram->last_dirty =3D=3D -1)
-    {
-        /* still completely clean, just copy our empty bitmap */
-        rc =3D -EFAULT;
-        if ( copy_to_guest(dirty_bitmap, dirty_vram->dirty_bitmap, dirty_s=
ize) =3D=3D 0 )
-            rc =3D 0;
+        goto out;
     }
-    else
+
+    list_for_each_safe(curr, next, &dirty_vram->range_head)
     {
-        /* Iterate over VRAM to track dirty bits. */
-        for ( i =3D 0; i < nr; i++ ) {
-            mfn_t mfn =3D get_gfn_query_unlocked(d, begin_pfn + i, &t);
-            struct page_info *page;
-            int dirty =3D 0;
-            paddr_t sl1ma =3D dirty_vram->sl1ma[i];
-
-            if (mfn_x(mfn) =3D=3D INVALID_MFN)
-            {
-                dirty =3D 1;
-            }
-            else
+        dv_range_t *range =3D list_entry(curr, dv_range_t, range_link);
+        unsigned long i;
+        int max_mappings =3D 1, mappings =3D 0;
+        int unshadowed =3D 0;
+        for (i =3D 0; i !=3D range->end_pfn - range->begin_pfn; i++)
+        {
+            dv_paddr_link_t *pl =3D &range->pl_tab[ i ];
+            dv_paddr_link_t **ppl =3D NULL;
+            mappings =3D 0;
+
+            while (pl !=3D NULL)
             {
-                page =3D mfn_to_page(mfn);
-                switch (page->u.inuse.type_info & PGT_count_mask)
-                {
-                case 0:
-                    /* No guest reference, nothing to track. */
-                    break;
-                case 1:
-                    /* One guest reference. */
-                    if ( sl1ma =3D=3D INVALID_PADDR )
-                    {
-                        /* We don't know which sl1e points to this, too ba=
d. */
-                        dirty =3D 1;
-                        /* TODO: Heuristics for finding the single mapping=
 of
-                         * this gmfn */
-                        flush_tlb |=3D sh_remove_all_mappings(d->vcpu[0], =
mfn);
-                    }
-                    else
-                    {
-                        /* Hopefully the most common case: only one mappin=
g,
-                         * whose dirty bit we can use. */
-                        l1_pgentry_t *sl1e =3D maddr_to_virt(sl1ma);
-
-                        if ( l1e_get_flags(*sl1e) & _PAGE_DIRTY )
-                        {
-                            dirty =3D 1;
-                            /* Note: this is atomic, so we may clear a
-                             * _PAGE_ACCESSED set by another processor. */
-                            l1e_remove_flags(*sl1e, _PAGE_DIRTY);
-                            flush_tlb =3D 1;
-                        }
-                    }
-                    break;
-                default:
-                    /* More than one guest reference,
-                     * we don't afford tracking that. */
-                    dirty =3D 1;
+                paddr_t sl1ma =3D pl->sl1ma;
+                unsigned long sl1mn;
+
+                if (sl1ma =3D=3D INVALID_PADDR )
                     break;
+
+                sl1mn =3D sl1ma >> PAGE_SHIFT;
+                if (sl1mn =3D=3D mfn_x(smfn)) {
+#if DEBUG_unshadow_sl1ma_detail
+                    gdprintk(XENLOG_DEBUG,
+                             "[%lx] gfn[%lx] unshadow sl1ma:%lx\n",
+                             mfn_x(smfn),
+                             range->begin_pfn + i,
+                             sl1ma);
+#endif
+                    unshadowed++;
+                    pl =3D free_paddr_link(d, ppl, pl);
+                    --range->nr_mappings;
+                }
+                else
+                {
+                    ppl =3D &pl->pl_next;
+                    pl =3D *ppl;
+                    mappings++;
                 }
             }
-
-            if ( dirty )
+        }
+        if (mappings > max_mappings)
+            max_mappings =3D mappings;
+
+        if (unshadowed) {
+#if DEBUG_unshadow_sl1ma
+            gdprintk(XENLOG_DEBUG,
+                     "[%lx] gfn[%05lx:%05lx] unshadowed:%d mappings:0x%x m=
ax_mappings:%d\n",
+                     mfn_x(smfn),
+                     range->begin_pfn, range->end_pfn,
+                     unshadowed, range->nr_mappings, max_mappings);
+#endif
+            if ( range->nr_mappings =3D=3D 0 )
             {
-                dirty_vram->dirty_bitmap[i / 8] |=3D 1 << (i % 8);
-                dirty_vram->last_dirty =3D NOW();
+                dirty_vram_range_free(d, range);
             }
         }
+    }
+ out:
+    return;
+}
+
+
+typedef int (*hash_pfn_callback_t)(struct vcpu *v,
+                                   mfn_t smfn,
+                                   unsigned long begin_pfn,
+                                   unsigned long end_pfn,
+                                   int *removed);
+
+static int hash_pfn_foreach(struct vcpu *v,
+                            unsigned int callback_mask,
+                            hash_pfn_callback_t callbacks[],
+                            unsigned long begin_pfn,
+                            unsigned long end_pfn)
+/* Walk the hash table looking at the types of the entries and
+ * calling the appropriate callback function for each entry.
+ * The mask determines which shadow types we call back for, and the array
+ * of callbacks tells us which function to call.
+ * Any callback may return non-zero to let us skip the rest of the scan.
+ *
+ * WARNING: Callbacks MUST NOT add or remove hash entries unless they
+ * then return non-zero to terminate the scan. */
+{
+    int i, done =3D 0, removed =3D 0;
+    struct domain *d =3D v->domain;
+    struct page_info *x;
+
+    /* Say we're here, to stop hash-lookups reordering the chains */
+    ASSERT(paging_locked_by_me(d));
+    ASSERT(d->arch.paging.shadow.hash_walking =3D=3D 0);
+    d->arch.paging.shadow.hash_walking =3D 1;

-        rc =3D -EFAULT;
-        if ( copy_to_guest(dirty_bitmap, dirty_vram->dirty_bitmap, dirty_s=
ize) =3D=3D 0 ) {
-            memset(dirty_vram->dirty_bitmap, 0, dirty_size);
-            if (dirty_vram->last_dirty + SECONDS(2) < NOW())
+    for ( i =3D 0; i < SHADOW_HASH_BUCKETS; i++ )
+    {
+        /* WARNING: This is not safe against changes to the hash table.
+         * The callback *must* return non-zero if it has inserted or
+         * deleted anything from the hash (lookups are OK, though). */
+        for ( x =3D d->arch.paging.shadow.hash_table[i]; x; x =3D next_sha=
dow(x) )
+        {
+            if ( callback_mask & (1 << x->u.sh.type) )
             {
-                /* was clean for more than two seconds, try to disable gue=
st
-                 * write access */
-                for ( i =3D begin_pfn; i < end_pfn; i++ ) {
-                    mfn_t mfn =3D get_gfn_query_unlocked(d, i, &t);
-                    if (mfn_x(mfn) !=3D INVALID_MFN)
-                        flush_tlb |=3D sh_remove_write_access(d->vcpu[0], =
mfn, 1, 0);
-                }
-                dirty_vram->last_dirty =3D -1;
+                ASSERT(x->u.sh.type <=3D 15);
+                ASSERT(callbacks[x->u.sh.type] !=3D NULL);
+                done =3D callbacks[x->u.sh.type](v, page_to_mfn(x),
+                                               begin_pfn, end_pfn,
+                                               &removed);
+                if ( done ) break;
             }
-            rc =3D 0;
         }
+        if ( done ) break;
     }
-    if ( flush_tlb )
-        flush_tlb_mask(d->domain_dirty_cpumask);
-    goto out;
+    d->arch.paging.shadow.hash_walking =3D 0;
+    return removed;
+}

-out_sl1ma:
-    xfree(dirty_vram->sl1ma);
-out_dirty_vram:
-    xfree(dirty_vram);
-    dirty_vram =3D d->arch.hvm_domain.dirty_vram =3D NULL;
+void sh_find_all_vram_mappings(struct vcpu *v,
+                               dv_range_t *range)
+{
+    /* Dispatch table for getting per-type functions */
+    static hash_pfn_callback_t callbacks[SH_type_unused] =3D {
+        NULL, /* none    */
+        SHADOW_INTERNAL_NAME(sh_find_vram_mappings_in_l1, 2), /* l1_32   *=
/
+        SHADOW_INTERNAL_NAME(sh_find_vram_mappings_in_l1, 2), /* fl1_32  *=
/
+        NULL, /* l2_32   */
+        SHADOW_INTERNAL_NAME(sh_find_vram_mappings_in_l1, 3), /* l1_pae  *=
/
+        SHADOW_INTERNAL_NAME(sh_find_vram_mappings_in_l1, 3), /* fl1_pae *=
/
+        NULL, /* l2_pae  */
+        NULL, /* l2h_pae */
+#if CONFIG_PAGING_LEVELS >=3D 4
+        SHADOW_INTERNAL_NAME(sh_find_vram_mappings_in_l1, 4), /* l1_64   *=
/
+        SHADOW_INTERNAL_NAME(sh_find_vram_mappings_in_l1, 4), /* fl1_64  *=
/
+#else
+        NULL, /* l1_64   */
+        NULL, /* fl1_64  */
+#endif
+        NULL, /* l2_64   */
+        NULL, /* l2h_64  */
+        NULL, /* l3_64   */
+        NULL, /* l4_64   */
+        NULL, /* p2m     */
+        NULL  /* unused  */
+    };

-out:
-    paging_unlock(d);
-    p2m_unlock(p2m_get_hostp2m(d));
-    return rc;
+    static unsigned int callback_mask =3D
+          1 << SH_type_l1_32_shadow
+        | 1 << SH_type_fl1_32_shadow
+        | 1 << SH_type_l1_pae_shadow
+        | 1 << SH_type_fl1_pae_shadow
+        | 1 << SH_type_l1_64_shadow
+        | 1 << SH_type_fl1_64_shadow
+        ;
+
+    perfc_incr(shadow_mappings);
+
+    hash_pfn_foreach(v, callback_mask, callbacks,
+                     range->begin_pfn,
+                     range->end_pfn);
+
+#if DEBUG_count_initial_mappings
+    gdprintk(XENLOG_DEBUG, "[%05lx:%05lx] count of initial mappings:%d\n",
+             range->begin_pfn, range->end_pfn,
+             range->nr_mappings);
+#endif
 }

+
 /*************************************************************************=
*/
 /* Shadow-control XEN_DOMCTL dispatcher */

diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.=
c
index b0e6d72..f4d0603 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -149,6 +150,10 @@ delete_fl1_shadow_status(struct vcpu *v, gfn_t gfn, mf=
n_t smfn)
     SHADOW_PRINTK("gfn=3D%"SH_PRI_gfn", type=3D%08x, smfn=3D%05lx\n",
                    gfn_x(gfn), SH_type_fl1_shadow, mfn_x(smfn));
     ASSERT(mfn_to_page(smfn)->u.sh.head);
+
+    /* Removing any dv_paddr_links to the erstwhile shadow page */
+    dirty_vram_delete_shadow(v, gfn_x(gfn), SH_type_fl1_shadow, smfn);
+
     shadow_hash_delete(v, gfn_x(gfn), SH_type_fl1_shadow, smfn);
 }

@@ -160,6 +165,10 @@ delete_shadow_status(struct vcpu *v, mfn_t gmfn, u32 s=
hadow_type, mfn_t smfn)
                    v->domain->domain_id, v->vcpu_id,
                    mfn_x(gmfn), shadow_type, mfn_x(smfn));
     ASSERT(mfn_to_page(smfn)->u.sh.head);
+
+    /* Removing any dv_paddr_links to the erstwhile shadow page */
+    dirty_vram_delete_shadow(v, mfn_x(gmfn), shadow_type, smfn);
+
     shadow_hash_delete(v, mfn_x(gmfn), shadow_type, smfn);
     /* 32-on-64 PV guests don't own their l4 pages; see set_shadow_status =
*/
     if ( !is_pv_32on64_vcpu(v) || shadow_type !=3D SH_type_l4_64_shadow )
@@ -516,7 +525,6 @@ _sh_propagate(struct vcpu *v,
     guest_l1e_t guest_entry =3D { guest_intpte };
     shadow_l1e_t *sp =3D shadow_entry_ptr;
     struct domain *d =3D v->domain;
-    struct sh_dirty_vram *dirty_vram =3D d->arch.hvm_domain.dirty_vram;
     gfn_t target_gfn =3D guest_l1e_get_gfn(guest_entry);
     u32 pass_thru_flags;
     u32 gflags, sflags;
@@ -663,17 +671,6 @@ _sh_propagate(struct vcpu *v,
         }
     }

-    if ( unlikely((level =3D=3D 1) && dirty_vram
-            && dirty_vram->last_dirty =3D=3D -1
-            && gfn_x(target_gfn) >=3D dirty_vram->begin_pfn
-            && gfn_x(target_gfn) < dirty_vram->end_pfn) )
-    {
-        if ( ft & FETCH_TYPE_WRITE )
-            dirty_vram->last_dirty =3D NOW();
-        else
-            sflags &=3D ~_PAGE_RW;
-    }
-
     /* Read-only memory */
     if ( p2m_is_readonly(p2mt) ||
          (p2mt =3D=3D p2m_mmio_direct &&
@@ -1072,101 +1069,57 @@ static int shadow_set_l2e(struct vcpu *v,
     return flags;
 }

-static inline void shadow_vram_get_l1e(shadow_l1e_t new_sl1e,
+/* shadow_vram_fix_l1e()
+ * Testing L1PTEs as they are modified, look for when they start to (or ce=
ase to)
+ * point to frame buffer pages.  If the old and new gfns differ, calls
+ * dirty_vram_range_update() to updates the dirty_vram structures
+ */
+static inline void shadow_vram_fix_l1e(shadow_l1e_t old_sl1e,
+                                       shadow_l1e_t new_sl1e,
                                        shadow_l1e_t *sl1e,
                                        mfn_t sl1mfn,
                                        struct domain *d)
 {
-    mfn_t mfn =3D shadow_l1e_get_mfn(new_sl1e);
-    int flags =3D shadow_l1e_get_flags(new_sl1e);
-    unsigned long gfn;
-    struct sh_dirty_vram *dirty_vram =3D d->arch.hvm_domain.dirty_vram;
+    mfn_t new_mfn, old_mfn;
+    unsigned long new_gfn =3D INVALID_M2P_ENTRY, old_gfn =3D INVALID_M2P_E=
NTRY;
+    paddr_t sl1ma;
+    dv_dirty_vram_t *dirty_vram =3D d->arch.hvm_domain.dirty_vram;

-    if ( !dirty_vram         /* tracking disabled? */
-         || !(flags & _PAGE_RW) /* read-only mapping? */
-         || !mfn_valid(mfn) )   /* mfn can be invalid in mmio_direct */
+    if ( !dirty_vram )
         return;

-    gfn =3D mfn_to_gfn(d, mfn);
-    /* Page sharing not supported on shadow PTs */
-    BUG_ON(SHARED_M2P(gfn));
+    sl1ma =3D pfn_to_paddr(mfn_x(sl1mfn)) | ((unsigned long)sl1e & ~PAGE_M=
ASK);

-    if ( (gfn >=3D dirty_vram->begin_pfn) && (gfn < dirty_vram->end_pfn) )
+    old_mfn =3D shadow_l1e_get_mfn(old_sl1e);
+
+    if ( !sh_l1e_is_magic(old_sl1e) &&
+         (l1e_get_flags(old_sl1e) & _PAGE_PRESENT) &&
+         mfn_valid(old_mfn))
     {
-        unsigned long i =3D gfn - dirty_vram->begin_pfn;
-        struct page_info *page =3D mfn_to_page(mfn);
-
-        if ( (page->u.inuse.type_info & PGT_count_mask) =3D=3D 1 )
-            /* Initial guest reference, record it */
-            dirty_vram->sl1ma[i] =3D pfn_to_paddr(mfn_x(sl1mfn))
-                | ((unsigned long)sl1e & ~PAGE_MASK);
+        old_gfn =3D mfn_to_gfn(d, old_mfn);
     }
-}
-
-static inline void shadow_vram_put_l1e(shadow_l1e_t old_sl1e,
-                                       shadow_l1e_t *sl1e,
-                                       mfn_t sl1mfn,
-                                       struct domain *d)
-{
-    mfn_t mfn =3D shadow_l1e_get_mfn(old_sl1e);
-    int flags =3D shadow_l1e_get_flags(old_sl1e);
-    unsigned long gfn;
-    struct sh_dirty_vram *dirty_vram =3D d->arch.hvm_domain.dirty_vram;
-
-    if ( !dirty_vram         /* tracking disabled? */
-         || !(flags & _PAGE_RW) /* read-only mapping? */
-         || !mfn_valid(mfn) )   /* mfn can be invalid in mmio_direct */
-        return;
-
-    gfn =3D mfn_to_gfn(d, mfn);
-    /* Page sharing not supported on shadow PTs */
-    BUG_ON(SHARED_M2P(gfn));
-
-    if ( (gfn >=3D dirty_vram->begin_pfn) && (gfn < dirty_vram->end_pfn) )
+
+    new_mfn =3D shadow_l1e_get_mfn(new_sl1e);
+    if ( !sh_l1e_is_magic(new_sl1e) &&
+         (l1e_get_flags(new_sl1e) & _PAGE_PRESENT) &&
+         mfn_valid(new_mfn))
     {
-        unsigned long i =3D gfn - dirty_vram->begin_pfn;
-        struct page_info *page =3D mfn_to_page(mfn);
-        int dirty =3D 0;
-        paddr_t sl1ma =3D pfn_to_paddr(mfn_x(sl1mfn))
-            | ((unsigned long)sl1e & ~PAGE_MASK);
+        new_gfn =3D mfn_to_gfn(d, new_mfn);
+    }

-        if ( (page->u.inuse.type_info & PGT_count_mask) =3D=3D 1 )
-        {
-            /* Last reference */
-            if ( dirty_vram->sl1ma[i] =3D=3D INVALID_PADDR ) {
-                /* We didn't know it was that one, let's say it is dirty *=
/
-                dirty =3D 1;
-            }
-            else
-            {
-                ASSERT(dirty_vram->sl1ma[i] =3D=3D sl1ma);
-                dirty_vram->sl1ma[i] =3D INVALID_PADDR;
-                if ( flags & _PAGE_DIRTY )
-                    dirty =3D 1;
-            }
-        }
-        else
+    if (old_gfn =3D=3D new_gfn) return;
+
+    if (VALID_M2P(old_gfn))
+        if (dirty_vram_range_update(d, old_gfn, sl1ma, 0/*clear*/))
         {
-            /* We had more than one reference, just consider the page dirt=
y. */
-            dirty =3D 1;
-            /* Check that it's not the one we recorded. */
-            if ( dirty_vram->sl1ma[i] =3D=3D sl1ma )
-            {
-                /* Too bad, we remembered the wrong one... */
-                dirty_vram->sl1ma[i] =3D INVALID_PADDR;
-            }
-            else
-            {
-                /* Ok, our recorded sl1e is still pointing to this page, l=
et's
-                 * just hope it will remain. */
-            }
+            SHADOW_PRINTK("gfn %lx (mfn %lx) cleared vram pte\n", old_gfn,=
 mfn_x(old_mfn));
         }
-        if ( dirty )
+
+    if (VALID_M2P(new_gfn))
+        if (dirty_vram_range_update(d, new_gfn, sl1ma, 1/*set*/))
         {
-            dirty_vram->dirty_bitmap[i / 8] |=3D 1 << (i % 8);
-            dirty_vram->last_dirty =3D NOW();
+            SHADOW_PRINTK("gfn %lx (mfn %lx) set vram pte\n", new_gfn, mfn=
_x(new_mfn));
         }
-    }
 }

 static int shadow_set_l1e(struct vcpu *v,
@@ -1211,12 +1164,14 @@ static int shadow_set_l1e(struct vcpu *v,
                 shadow_l1e_remove_flags(new_sl1e, _PAGE_RW);
                 /* fall through */
             case 0:
-                shadow_vram_get_l1e(new_sl1e, sl1e, sl1mfn, d);
+                shadow_vram_fix_l1e(old_sl1e, new_sl1e, sl1e, sl1mfn, d);
                 break;
             }
         }
     }

+    shadow_vram_fix_l1e(old_sl1e, new_sl1e, sl1e, sl1mfn, d);
+
     /* Write the new entry */
     shadow_write_entries(sl1e, &new_sl1e, 1, sl1mfn);
     flags |=3D SHADOW_SET_CHANGED;
@@ -1231,7 +1186,6 @@ static int shadow_set_l1e(struct vcpu *v,
          * trigger a flush later. */
         if ( shadow_mode_refcounts(d) )
         {
-            shadow_vram_put_l1e(old_sl1e, sl1e, sl1mfn, d);
             shadow_put_page_from_l1e(old_sl1e, d);
             TRACE_SHADOW_PATH_FLAG(TRCE_SFLAG_SHADOW_L1_PUT_REF);
         }
@@ -2018,7 +1972,6 @@ void sh_destroy_l1_shadow(struct vcpu *v, mfn_t smfn)
         SHADOW_FOREACH_L1E(sl1mfn, sl1e, 0, 0, {
             if ( (shadow_l1e_get_flags(*sl1e) & _PAGE_PRESENT)
                  && !sh_l1e_is_magic(*sl1e) ) {
-                shadow_vram_put_l1e(*sl1e, sl1e, sl1mfn, d);
                 shadow_put_page_from_l1e(*sl1e, d);
             }
         });
@@ -4336,6 +4289,34 @@ int sh_rm_mappings_from_l1(struct vcpu *v, mfn_t sl1=
mfn, mfn_t target_mfn)
     return done;
 }

+
+int sh_find_vram_mappings_in_l1(struct vcpu *v,
+                                mfn_t sl1mfn,
+                                unsigned long begin_pfn,
+                                unsigned long end_pfn,
+                                int *removed)
+/* Find all VRAM mappings in this shadow l1 table */
+{
+    struct domain *d =3D v->domain;
+    shadow_l1e_t *sl1e;
+    int done =3D 0;
+
+    SHADOW_FOREACH_L1E(sl1mfn, sl1e, 0, done, /* only returns _PAGE_PRESEN=
T entries */
+    {
+        unsigned long gfn;
+        mfn_t gmfn =3D shadow_l1e_get_mfn(*sl1e);
+        if (!mfn_valid(gmfn))
+            continue;
+        gfn =3D mfn_to_gfn(d, gmfn);
+        if (VALID_M2P(gfn) && (begin_pfn <=3D gfn) && (gfn < end_pfn))
+        {
+            paddr_t sl1ma =3D pfn_to_paddr(mfn_x(sl1mfn)) | ((unsigned lon=
g)sl1e & ~PAGE_MASK);
+            dirty_vram_range_update(v->domain, gfn, sl1ma, 1/*set*/);
+        }
+    });
+    return 0;
+}
+
 /*************************************************************************=
*/
 /* Functions to excise all pointers to shadows from higher-level shadows. =
*/

diff --git a/xen/arch/x86/mm/shadow/multi.h b/xen/arch/x86/mm/shadow/multi.=
h
index 835121e..436a4ac 100644
--- a/xen/arch/x86/mm/shadow/multi.h
+++ b/xen/arch/x86/mm/shadow/multi.h
@@ -66,7 +66,12 @@ SHADOW_INTERNAL_NAME(sh_rm_write_access_from_l1, GUEST_L=
EVELS)
 extern int
 SHADOW_INTERNAL_NAME(sh_rm_mappings_from_l1, GUEST_LEVELS)
     (struct vcpu *v, mfn_t sl1mfn, mfn_t target_mfn);
-
+extern int
+SHADOW_INTERNAL_NAME(sh_find_vram_mappings_in_l1, GUEST_LEVELS)
+     (struct vcpu *v, mfn_t sl1mfn,
+      unsigned long begin_pfn,
+      unsigned long end_pfn,
+      int *removed);
 extern void
 SHADOW_INTERNAL_NAME(sh_clear_shadow_entry, GUEST_LEVELS)
     (struct vcpu *v, void *ep, mfn_t smfn);
diff --git a/xen/arch/x86/mm/shadow/types.h b/xen/arch/x86/mm/shadow/types.=
h
index 43ce1db..5b0f9f7 100644
--- a/xen/arch/x86/mm/shadow/types.h
+++ b/xen/arch/x86/mm/shadow/types.h
@@ -229,6 +229,7 @@ static inline shadow_l4e_t shadow_l4e_from_mfn(mfn_t mf=
n, u32 flags)
 #define sh_update_cr3              INTERNAL_NAME(sh_update_cr3)
 #define sh_rm_write_access_from_l1 INTERNAL_NAME(sh_rm_write_access_from_l=
1)
 #define sh_rm_mappings_from_l1     INTERNAL_NAME(sh_rm_mappings_from_l1)
+#define sh_find_vram_mappings_in_l1 INTERNAL_NAME(sh_find_vram_mappings_in=
_l1)
 #define sh_remove_l1_shadow        INTERNAL_NAME(sh_remove_l1_shadow)
 #define sh_remove_l2_shadow        INTERNAL_NAME(sh_remove_l2_shadow)
 #define sh_remove_l3_shadow        INTERNAL_NAME(sh_remove_l3_shadow)
diff --git a/xen/include/asm-x86/hap.h b/xen/include/asm-x86/hap.h
index a2532a4..82e20c7 100644
--- a/xen/include/asm-x86/hap.h
+++ b/xen/include/asm-x86/hap.h
@@ -57,10 +57,6 @@ void  hap_final_teardown(struct domain *d);
 void  hap_teardown(struct domain *d);
 void  hap_vcpu_init(struct vcpu *v);
 void  hap_logdirty_init(struct domain *d);
-int   hap_track_dirty_vram(struct domain *d,
-                           unsigned long begin_pfn,
-                           unsigned long nr,
-                           XEN_GUEST_HANDLE_64(uint8) dirty_bitmap);

 extern const struct paging_mode *hap_paging_get_mode(struct vcpu *);

diff --git a/xen/include/asm-x86/hvm/dirty_vram.h b/xen/include/asm-x86/hvm=
/dirty_vram.h
new file mode 100644
index 0000000..b8b92cc
--- /dev/null
+++ b/xen/include/asm-x86/hvm/dirty_vram.h
@@ -0,0 +1,157 @@
+/*************************************************************************=
*****
+ * include/asm-x86/hvm/dirty_vram.h
+ *
+ * Interface for tracking dirty VRAM pages
+ *
+ * Copyright (c) 2012 Citrix Systems, Inc. (Robert Phillips)
+ * Parts of this code are Copyright (c) 2006 by XenSource Inc.
+ * Parts of this code are Copyright (c) 2006 by Michael A Fetterman
+ * Parts based on earlier work by Michael A Fetterman, Ian Pratt et al.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  U=
SA
+ */
+
+#ifndef _DIRTY_VRAM_H
+#define _DIRTY_VRAM_H
+
+/* In shadow mode we need to bookkeep all the L1 page table entries that
+ * map a frame buffer page.  Struct dv_paddr_link does this
+ * by recording the address of a L1 page table entry for some frame buffer=
 page.
+ * Also has a link to additional pl entries if the frame buffer page
+ * has multiple mappings */
+typedef struct dv_paddr_link {
+    paddr_t sl1ma;
+    struct dv_paddr_link *pl_next;
+} dv_paddr_link_t;
+
+/* This defines an extension page of pl entries for FB pages with multiple
+ * mappings. All such pages (of a domain) are linked together. */
+typedef struct dv_paddr_link_ext {
+    struct list_head ext_link;
+    dv_paddr_link_t entries[(PAGE_SIZE-sizeof(struct list_head))/sizeof(dv=
_paddr_link_t)];
+} dv_paddr_link_ext_t;
+
+/* This defines a single frame buffer range.  It bookkeeps all the level 1=
 PTEs
+ * that map guest pages within that range.
+ * All such ranges (of a domain) are linked together. */
+typedef struct dv_range {
+    struct list_head range_link; /* the several ranges form a linked list =
*/
+    unsigned long begin_pfn;
+    unsigned long end_pfn;
+    dv_paddr_link_t *pl_tab; /* table has 1 pl entry per pfn in range */
+    int nr_mappings;  /* total number of mappings in this range */
+    int mappings_hwm; /* high water mark of max mapping count */
+    unsigned int dirty_count;
+} dv_range_t;
+
+/* This contains all the data structures required by a domain to
+ * bookkeep the dirty pages within its frame buffers. */
+typedef struct dv_dirty_vram {
+    struct list_head range_head; /* head of the linked list of ranges */
+    struct list_head ext_head; /* head of list of extension pages */
+    dv_paddr_link_t *pl_free; /* free list of pl's within extension pages =
*/
+    int nr_ranges; /* bookkeeps number of ranges */
+    int ranges_hwm; /* high water mark of max number of ranges */
+} dv_dirty_vram_t;
+
+/* Allocates domain's dirty_vram structure */
+dv_dirty_vram_t *
+dirty_vram_alloc(struct domain *d);
+
+/* Returns domain's dirty_vram structure,
+ * allocating it if necessary */
+dv_dirty_vram_t *
+dirty_vram_find_or_alloc(struct domain *d);
+
+/* Frees domain's dirty_vram structure */
+void dirty_vram_free(struct domain *d);
+
+/* Returns dirty vram range containing gfn, NULL if none */
+struct dv_range *
+dirty_vram_range_find_gfn(struct domain *d,
+                          unsigned long gfn);
+
+/* Returns dirty vram range matching [ begin_pfn .. begin_pfn+nr ), NULL i=
f none */
+dv_range_t *
+dirty_vram_range_find(struct domain *d,
+                      unsigned long begin_pfn,
+                      unsigned long nr);
+
+/* Allocate dirty vram range containing [ begin_pfn .. begin_pfn+nr ),
+ * freeing any existing range that overlaps the new range. */
+dv_range_t *
+dirty_vram_range_alloc(struct domain *d,
+                       unsigned long begin_pfn,
+                       unsigned long nr);
+
+/* Returns dirty vram range matching [ begin_pfn .. begin_pfn+nr ),
+ * creating a range if none already exists and
+ * freeing any existing range that overlaps the new range. */
+dv_range_t *
+dirty_vram_range_find_or_alloc(struct domain *d,
+                               unsigned long begin_pfn,
+                               unsigned long nr);
+
+void dirty_vram_range_free(struct domain *d,
+                           dv_range_t *range);
+
+/* Bookkeep PTE address of a frame buffer page */
+int dirty_vram_range_update(struct domain *d,
+                            unsigned long gfn,
+                            paddr_t sl1ma,
+                            int set);
+
+/* smfn is no longer a shadow page.  Remove it from any
+ * dirty vram range mapping. */
+void
+dirty_vram_delete_shadow(struct vcpu *v,
+                         unsigned long gfn,
+                         unsigned int shadow_type,
+                         mfn_t smfn);
+
+
+/* Scan all the L1 tables looking for VRAM mappings.
+ * Record them in the domain's dv_dirty_vram structure */
+void sh_find_all_vram_mappings(struct vcpu *v,
+                               dv_range_t *range);
+
+/* Free a paddr_link struct, given address of its
+ * predecessor in singly-linked list */
+dv_paddr_link_t *
+free_paddr_link(struct domain *d,
+                dv_paddr_link_t **ppl,
+                dv_paddr_link_t *pl);
+
+
+/* Enable VRAM dirty tracking. */
+int
+shadow_track_dirty_vram(struct domain *d,
+                       unsigned long first_pfn,
+                       unsigned long nr,
+                       XEN_GUEST_HANDLE_64(uint8) dirty_bitmap);
+
+int
+hap_track_dirty_vram(struct domain *d,
+                    unsigned long begin_pfn,
+                    unsigned long nr,
+                    XEN_GUEST_HANDLE_64(uint8) dirty_bitmap);
+
+void
+hap_clean_vram_tracking_range(struct domain *d,
+                             unsigned long begin_pfn,
+                             unsigned long nr,
+                             uint8_t *dirty_bitmap);
+
+#endif /* _DIRTY_VRAM_H */
diff --git a/xen/include/asm-x86/hvm/domain.h b/xen/include/asm-x86/hvm/dom=
ain.h
index 27b3de5..6146542 100644
--- a/xen/include/asm-x86/hvm/domain.h
+++ b/xen/include/asm-x86/hvm/domain.h
@@ -74,7 +74,7 @@ struct hvm_domain {
     struct list_head       pinned_cacheattr_ranges;

     /* VRAM dirty support. */
-    struct sh_dirty_vram *dirty_vram;
+    struct dv_dirty_vram * dirty_vram;

     /* If one of vcpus of this domain is in no_fill_mode or
      * mtrr/pat between vcpus is not the same, set is_in_uc_mode
diff --git a/xen/include/asm-x86/paging.h b/xen/include/asm-x86/paging.h
index d9b6950..fba06b0 100644
--- a/xen/include/asm-x86/paging.h
+++ b/xen/include/asm-x86/paging.h
@@ -137,10 +137,10 @@ struct paging_mode {
 void paging_free_log_dirty_bitmap(struct domain *d);

 /* get the dirty bitmap for a specific range of pfns */
-int paging_log_dirty_range(struct domain *d,
-                           unsigned long begin_pfn,
-                           unsigned long nr,
-                           XEN_GUEST_HANDLE_64(uint8) dirty_bitmap);
+void paging_log_dirty_range(struct domain *d,
+                            unsigned long begin_pfn,
+                            unsigned long nr,
+                            uint8_t *dirty_bitmap);

 /* enable log dirty */
 int paging_log_dirty_enable(struct domain *d);
@@ -161,6 +161,11 @@ void paging_mark_dirty(struct domain *d, unsigned long=
 guest_mfn);
  * This is called from inside paging code, with the paging lock held. */
 int paging_mfn_is_dirty(struct domain *d, mfn_t gmfn);

+/* mark a page as dirty, from hap page fault handler */
+void paging_mark_dirty_hap(struct domain *d,
+                           unsigned long pfn,
+                           unsigned long guest_mfn);
+
 /*
  * Log-dirty radix tree indexing:
  *   All tree nodes are PAGE_SIZE bytes, mapped on-demand.
@@ -183,15 +188,6 @@ int paging_mfn_is_dirty(struct domain *d, mfn_t gmfn);
 #define L4_LOGDIRTY_IDX(pfn) 0
 #endif

-/* VRAM dirty tracking support */
-struct sh_dirty_vram {
-    unsigned long begin_pfn;
-    unsigned long end_pfn;
-    paddr_t *sl1ma;
-    uint8_t *dirty_bitmap;
-    s_time_t last_dirty;
-};
-
 /*************************************************************************=
****
  * Entry points into the paging-assistance code */

diff --git a/xen/include/asm-x86/shadow.h b/xen/include/asm-x86/shadow.h
index 88a8cd2..bdb8dcd 100644
--- a/xen/include/asm-x86/shadow.h
+++ b/xen/include/asm-x86/shadow.h
@@ -62,12 +62,6 @@ void shadow_vcpu_init(struct vcpu *v);
 /* Enable an arbitrary shadow mode.  Call once at domain creation. */
 int shadow_enable(struct domain *d, u32 mode);

-/* Enable VRAM dirty bit tracking. */
-int shadow_track_dirty_vram(struct domain *d,
-                            unsigned long first_pfn,
-                            unsigned long nr,
-                            XEN_GUEST_HANDLE_64(uint8) dirty_bitmap);
-
 /* Handler for shadow control ops: operations from user-space to enable
  * and disable ephemeral shadow modes (test mode and log-dirty mode) and
  * manipulate the log-dirty bitmap. */
--
1.7.9.5


--_002_048EAD622912254A9DEA24C1734613C18C86D229FFFTLPMAILBOX02_
Content-Type: application/pdf; name="multi-dirty-vram.pdf"
Content-Description: multi-dirty-vram.pdf
Content-Disposition: attachment; filename="multi-dirty-vram.pdf"; size=525873;
	creation-date="Tue, 16 Oct 2012 16:27:53 GMT";
	modification-date="Tue, 16 Oct 2012 16:27:54 GMT"
Content-Transfer-Encoding: base64

JVBERi0xLjUNCiW1tbW1DQoxIDAgb2JqDQo8PC9UeXBlL0NhdGFsb2cvUGFnZXMgMiAwIFIvTGFu
Zyhlbi1VUykgL1N0cnVjdFRyZWVSb290IDQ4IDAgUi9NYXJrSW5mbzw8L01hcmtlZCB0cnVlPj4+
Pg0KZW5kb2JqDQoyIDAgb2JqDQo8PC9UeXBlL1BhZ2VzL0NvdW50IDUvS2lkc1sgMyAwIFIgMzcg
MCBSIDQwIDAgUiA0MiAwIFIgNDUgMCBSXSA+Pg0KZW5kb2JqDQozIDAgb2JqDQo8PC9UeXBlL1Bh
Z2UvUGFyZW50IDIgMCBSL1Jlc291cmNlczw8L0ZvbnQ8PC9GMSA1IDAgUi9GMiAxMCAwIFIvRjMg
MTIgMCBSL0Y0IDE3IDAgUi9GNSAxOSAwIFIvRjYgMjEgMCBSL0Y3IDI2IDAgUi9GOCAyOCAwIFIv
RjkgMzAgMCBSL0YxMCAzNSAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0lt
YWdlSV0gPj4vTWVkaWFCb3hbIDAgMCA2MTIgNzkyXSAvQ29udGVudHMgNCAwIFIvR3JvdXA8PC9U
eXBlL0dyb3VwL1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1Y3RQYXJl
bnRzIDA+Pg0KZW5kb2JqDQo0IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDM5
MjQ+Pg0Kc3RyZWFtDQp4nKVabW/bOBL+XqD/gR/tRaySoihKh4WBNC+3PdwCvd2id0C7KBRbSXRx
nKwkN9v79TczpGhSNm1vF0VqWebLcDjzzDNDsjfv2Y8/vvn54t0l4/M5e3t5wd5+eP3qzbVgaZ7w
jH24ff1KMA7/BNNpwtOM5aVK0px9eHz9iie85CnjSSrwf5kr1t7tff3L31+/+vQj54LPZyV8lno+
K+CzuDKfZW7eF2/nv7EP/3j96grEYFc/XzDmySgCGdM9MgrJE+2L+Gkymx4YMT26aiHLJE2DIVFO
kFdwI7BZUDafabuQVOLDwZXI4yspZSL+xEqyoytJuUhgK0YrKYthAbAYOZ/luKhr88mltwYzsNw3
cK4SqUcDiytpNAKD0ARiUBnuvcLPdHjhHoRVYmZlysMhimIu9zTDn9XIuEprXP4wuFfan29oUGg3
ULjesennWaILpzpezkVq5CBbHqS8HobfDms+lVGrk68wcttlDc3d6tVo9YP43PiMU+zbub8I+PmA
majATLI9uyl5kSgdrHXCxpb3O3k5F6liM56IVEjQjkjhiemSPtr69at//8DW0MGbPrfTAyrAfIni
OfyvM0G4oeFFAeMomZQFy+BrqeDnMoeJaLzbH16/+teeRelgUYoJsbsolZSS5SmsLTPYxRCpGOLS
5Jen6UxNbqZyUrf9tJiwXxP2fjrLJvfwqlnBf6sG/nuGv+6MfWzaqZCTflOtptmEXUzLCfV/xB7Y
ZgN/PbytWzadpZN366maLBLmK9E3rqzQCejBk+3TJJ3qCZ/O5ETAQ4oPb6Y5fIEHHhlGpbBhWTjM
m2jbcjQlbiPXWrIPi08TrmL9Mo6g5HXj1GHHPvzdKYLdyffszuBeXCLUDu6VZ1yoc/i75KLkaO9c
iPN5BtiiL8lzhEDrV3Mh8R24C/4mruA5hy7nc/JC0828h2GoT3FhhuXXc9MFPWg7CZ+Dn8Hc6JaC
pzgetVN8Psxg2poZi5Ia4qAgGHi4uODmF5wDRFa2E4hBE+BrMyR9BUlncjuhkQZ/keqK1gXejsvE
H/NrbI9D7EDzXrtP06RQgWaDMOJvrgQsSEXYdokO0PbfYl0ynQhxePj9Wy4VTzI92nKnN1QlT92+
gkqlujZgiQorSrMtqAjcTlAcNg2UCTsxNC+tlaTeXpmPwY5wvpI2h3Q9mNKOzqmjsq9gR2n4tNgK
LJzA9ueTdsnavwIgKIZgf2OB5Pa2bjvWrNl/avT+NbxK2FQIAKmNxST8IwRqewKcppuKFHyypF/a
J+z3FcGpWQIS1Ut2i/1ND3aDWEbP/T3r7qvlVGjz/QWREAap1gBzaAjsvmqXAEMvVVszHK/quga7
dz3JRm2eqzuYhF6jrHcIkZ8n+PNP8PX8/ecpihjFQi2SLA818QhTkkA4ft3FoAnYjQ47JtGm2WgS
iDIcQhlBWUw0xctEhZ2ow7VTYDvuehDtFHx6dAntGM0RTQewQRpvyD1AA5eX3lfssIWKMYgEoMkJ
3hxojmHGawzk1boD/IzwSdaNU+I7897DsXMnUXFhmuOzhbfBI8lTzegaHfnqJJ9IIfwXpa8l3CSF
rUDplx9PUnVaSIS/0SBAMHAQAhX4K06TpxSJ0OFQx2Nf6cW+8f5neVIOgfrDfU2uO9CHNmKEgufA
kcK+zv07dGscB7+ryS3r8ZE4TAeQwScLaJYbNwK/Zvi2mPTwUk8QB1IzDPZ9eEBpsFX9zPp7at7V
4Ih9zD3SIsckwJOMVC1KUtLTbawbJA1ZGXbbUWvYoUi4CDUwgJvISWRaBbttK9QHsTKS/2YDWIRw
GgtmBSBIGY7cIXaNzUPvi2dgHmU5FgvmbwkoQeWPO+PsM7NMZEk5Wt7n6Rltau/WBg+0i7TB9aKH
jWEvA2Gt1wT/bvONRSAQb+zOd9FdHGxTAgxLOz2OUXXsEQZwMNzcNvC1XsbMFPglUPhgmNiUQqaI
q35TijjfgPkyss3bcD1onx0sKg9jZMxegAFxdZooKVBoSH12ZcEln7HN86ACjGysRZeqf99gTO1I
ujPcmLbuNy1SflaR4lHIpnemWOEgbNhJ56Miw33Spo1VM7wb9Axh1QbTusNMAhp9uMc4L6OLUQJL
IcFaVnUfDZ9A/vL8NDUNRiIgd9S2rWUQmPKAfZm14bb1L7i+ijImY4gLVBvuocuXnErrdY8/dpDs
xXYIktNSh1PH+GwK+aiUYVucrmrWBsjQpe5RyDpqEEolabk7hAn3tL7GSR+1QEiI9UiOOLrBhGqP
agcf0J5LjxHFYZGU2Ht3kLUzRctXANwKx11A845qmZbbZXafpw6CCA8M06THrwRCiLAL9w6dhqx1
maCrkMFeVRSD7o+ZFeeJKh33m3kuR6zSxKsWyCg6SGe9jNBe7kV75MoGR6Ja5zrJRDhzZ9RkzTRu
ITIjWhB0bf6HmEByVWTRrHt6BE2bV88DhjX0W/M08Hpk+Q6mO9xr9nxPSAgNumZRYSUC/Qu3qTZ4
DPvzzQGCtWVsjTroEVCs9UToNphbOVJ5lJpD4EXW7LcNtH5kX7Miwwi5J7uJch2JwgX9okEEeBEI
57WlgobMiUvcxOBECI01E7+bYR8NAvhdNGIBFSxOFAx8UYdN+7YiDHzYJk0LMA7yGXoKPcjxOWI5
CLDA2ZrHrYVFcUdrJL8niQksH3EnaDsCg8EfIBuNFhAkFhCCQTBVfF5tYKg7BwmsWmMayTa4RvSG
1Ya0vYWMiAVmGgladEG75wXhoUbBgFztT8ayLE0KbQ817LEFYDaYel7aM43xWzrSmFw8IeYta/ZL
TRBd4VcgZEijZ8jjC7SlWRY3JmCdZSDAsUWJo9XOYVEQ03W5U+0ccg0biIfEmhl5Y45SkslvR/w0
qVcV5v2pMWHEmyd8uMQc4yMxk/vKVCJuampHGGdqARXBK3BKgOUN4jiEBeCYzy4J6brmBoxhVX+e
Ipq3NMBttXAcuAXyKQgzYdr8GFfJQElSWMH/cJWUN8TI2gUgpzJf/oDxC/w5B+x8M1DqrzADugO9
cDWxYvLlK8jYVo8oXPIJNh0bL36LGXAKVJeLUJjDe52easAyhw0qv8OAL6eZMdq+Yr/2LSxyA0qG
IASOewHfIMxmk/UdxfhDHFtrX4Zj65Kn2rBUwGXiNnyJG2KMbVnBCjo0wxZWsGmnhggAQQDjKUbl
MFOwIg/waleUA1O09bInND9b1FpbmGIrMkGD4rHNlpBMAHf0FnBMKVm8WCClTvLTTEYdGAX2SQzs
/qoCn8Oa3MefmdGAyLaEx5Bk9vxEqTUuvCdl9kNQsLyrc0pZ1eTSJ2XLqaSsP5CHCA9ly0gMFvFC
Qy6TfNR3ST4K03+JxsISzz53OjUtmf433MlYXzw7Gk/4Pam9TAvMA4JxKGN8uW8AgZQJ/i7i9rgF
RHBXKzJwzyQj8VFyDIzBBFE2B7xEibDtU7RtmcjRuJjq0X4bZF4RD/RcCb1xnz2MLRJ4m9bOArae
i478t2h1gWMNLuh72CfyAG7KPZtTcpInhc+8dEdQerc2KPi+3irhedh7jyfsq1AKSGh5OprXnDac
b48Y7DOVUk3x1R412JIu0Ddbat2eeeERxfagSeSmpks1YlMBDlrhGYl/YoYjaxrZnHHTadQ51ZHN
WQcNrHYOxaR6iyVV6jAckGEl24g+OqvZjkTD6O2pyWxcw7aHK/tOVPaW42SRpDLcEAsw+RF8kXmO
0TnoSvgSxYciRffY6RBgy9cW/ZpS1scvIIPDDnNIInfTp0h9MFeY6AST2fOgd71fXxmjSG+4jDiQ
qA22qBXS+O1CMLC25NqritIAoPD9AFWulLV2JNJlhbmpafnJXpQaqRzBJZj7sE/rk31alZjbfK9P
e733+PS+PRr06Pes2OLJkF2z5V5uTtQZ+MwCdUfFf1MtW/dsTdz40ZY67X2CbVWGtRUwMw1oaY7j
3EFdhaTlvrlD/hYtEukk1aGQ0ZPhDKxNhm1fKlN8pnzUUIb2gezwlk4Z2p0itC1uVvjDH82jifS0
PHjCpdrHGzJSGndQ0GF7zeQQByjpF+YSAxhhPOkXWdDNJP3DeaVVZ71euFKZ27baZElYaFmyjnxr
QbXo5VAW9OkTbMOirau+CXwyyhi5wITdE+yYDxQn+0Cq/0pc83r/SR/we6KR39fVkjm13jKqCbJV
g0cSbr+RbueGA+zlRFsiTj6FvvFfwqUFoVznm06JCGwLzcTlTzvOwT1QofinElSpBV5cCvoeCSCg
Kxl2oEL11JCpJR0I5pMvK1r4w4mRAkIg1+GoZ2xJpttRpbZt0NMIWZaQo0NSoycvZyMoOeJ7It3i
dcWsgFsaiBtLO+wd5GDBGEJhg7enKkry7eFArIyfIW0OZlranDxK94EJFyLsQxpd2mW1pMscdTmz
fktWhBay6DvK52O7JUyk8sc+7KUHDoFFkSXFcHOGMjKAdGvcJpjayxyGZlMCC36BB0/rHnYNxEW5
Tc5anZh8wStIvoKpTd6MuH0k+YJUIB/1PZ58KYXJ106nBqtj/bcvX/HUzOVSf4UdIe3TIpwpYcCM
sACwcMFzfcBz1Wh1YwJlUWRpmBASIyRF5cmcaDifOJwXiRxSruH81+dP0ZyI4ylq0O2gUab81NAh
lExk8b2hw+99IvZaaAl6UpX4S09wES+1003toN/ZacEqE3hcfVDWbdsMFe03NZX7qm2rbf1oe8B7
2ppBXXIkwdgnzaWuWAVOkk/7/Q/GHHRkpXeVHMYcMNZ40Nl/4abEOlVoMy5N5dfmPl1prxFxum2H
yS5ljtusMd97/dPkvJgwmstI7nrmhaa8U+DN6NS79IddLy7mIosmlubS0jjdxnz0rTI3Te1VQBB9
GAZndzcF6Zahy7+Hi4lqe3PLvyhq03F15N7nSfeRBi8BGj9Edy90JMORKx63IjNa9y0WrNnN01DA
e3jAE8kaYj7da/bwDan6P4ncY3m7XiGdoqvHtg5KDcAXV1N7aQEBjehZOyqe2tNPOrIc7j6MkdQR
vBYi27MpQlropCDhuN6dd9PiCC0RaZpkqW/Wvlbw5gRdfoqMkWvsHIxBxVFHm26QnS4ZiCbUdnXb
vKxmAwGiY1igOoxY1soR35cElYqXzHNDf77Qsgy+NeYSBFEmVMPqG+pp05kpYUZzTTP3rmk+DtmH
EdQu9F3PGiILbE113P5A4Bk0x+kyugW21Wq48bIYghxFQ/bTOfz/HlMcb2ZYYTS9N3cxgtF34tP/
AUblCmoNCmVuZHN0cmVhbQ0KZW5kb2JqDQo1IDAgb2JqDQo8PC9UeXBlL0ZvbnQvU3VidHlwZS9U
eXBlMC9CYXNlRm9udC9BQkNERUUrQ2FtYnJpYSxJdGFsaWMvRW5jb2RpbmcvSWRlbnRpdHktSC9E
ZXNjZW5kYW50Rm9udHMgNiAwIFIvVG9Vbmljb2RlIDI2OSAwIFI+Pg0KZW5kb2JqDQo2IDAgb2Jq
DQpbIDcgMCBSXSANCmVuZG9iag0KNyAwIG9iag0KPDwvQmFzZUZvbnQvQUJDREVFK0NhbWJyaWEs
SXRhbGljL1N1YnR5cGUvQ0lERm9udFR5cGUyL1R5cGUvRm9udC9DSURUb0dJRE1hcC9JZGVudGl0
eS9EVyAxMDAwL0NJRFN5c3RlbUluZm8gOCAwIFIvRm9udERlc2NyaXB0b3IgOSAwIFIvVyAyNzEg
MCBSPj4NCmVuZG9iag0KOCAwIG9iag0KPDwvT3JkZXJpbmcoSWRlbnRpdHkpIC9SZWdpc3RyeShB
ZG9iZSkgL1N1cHBsZW1lbnQgMD4+DQplbmRvYmoNCjkgMCBvYmoNCjw8L1R5cGUvRm9udERlc2Ny
aXB0b3IvRm9udE5hbWUvQUJDREVFK0NhbWJyaWEsSXRhbGljL0ZsYWdzIDMyL0l0YWxpY0FuZ2xl
IC0xMi40L0FzY2VudCA5NTAvRGVzY2VudCAtMjIyL0NhcEhlaWdodCA3NzgvQXZnV2lkdGggNTQy
L01heFdpZHRoIDIzMjcvRm9udFdlaWdodCA0MDAvWEhlaWdodCAyNTAvU3RlbVYgNTQvRm9udEJC
b3hbIC0xMTA1IC0yMjIgMTIyMiA3NzhdIC9Gb250RmlsZTIgMjcwIDAgUj4+DQplbmRvYmoNCjEw
IDAgb2JqDQo8PC9UeXBlL0ZvbnQvU3VidHlwZS9UcnVlVHlwZS9OYW1lL0YyL0Jhc2VGb250L0FC
Q0RFRStDYW1icmlhLEl0YWxpYy9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvRm9udERlc2NyaXB0
b3IgMTEgMCBSL0ZpcnN0Q2hhciA0NS9MYXN0Q2hhciA0NS9XaWR0aHMgMjcyIDAgUj4+DQplbmRv
YmoNCjExIDAgb2JqDQo8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0FCQ0RFRStDYW1i
cmlhLEl0YWxpYy9GbGFncyAzMi9JdGFsaWNBbmdsZSAtMTIuNC9Bc2NlbnQgOTUwL0Rlc2NlbnQg
LTIyMi9DYXBIZWlnaHQgNzc4L0F2Z1dpZHRoIDU0Mi9NYXhXaWR0aCAyMzI3L0ZvbnRXZWlnaHQg
NDAwL1hIZWlnaHQgMjUwL1N0ZW1WIDU0L0ZvbnRCQm94WyAtMTEwNSAtMjIyIDEyMjIgNzc4XSAv
Rm9udEZpbGUyIDI3MCAwIFI+Pg0KZW5kb2JqDQoxMiAwIG9iag0KPDwvVHlwZS9Gb250L1N1YnR5
cGUvVHlwZTAvQmFzZUZvbnQvQUJDREVFK0NhbWJyaWEvRW5jb2RpbmcvSWRlbnRpdHktSC9EZXNj
ZW5kYW50Rm9udHMgMTMgMCBSL1RvVW5pY29kZSAyNzMgMCBSPj4NCmVuZG9iag0KMTMgMCBvYmoN
ClsgMTQgMCBSXSANCmVuZG9iag0KMTQgMCBvYmoNCjw8L0Jhc2VGb250L0FCQ0RFRStDYW1icmlh
L1N1YnR5cGUvQ0lERm9udFR5cGUyL1R5cGUvRm9udC9DSURUb0dJRE1hcC9JZGVudGl0eS9EVyAx
MDAwL0NJRFN5c3RlbUluZm8gMTUgMCBSL0ZvbnREZXNjcmlwdG9yIDE2IDAgUi9XIDI3NSAwIFI+
Pg0KZW5kb2JqDQoxNSAwIG9iag0KPDwvT3JkZXJpbmcoSWRlbnRpdHkpIC9SZWdpc3RyeShBZG9i
ZSkgL1N1cHBsZW1lbnQgMD4+DQplbmRvYmoNCjE2IDAgb2JqDQo8PC9UeXBlL0ZvbnREZXNjcmlw
dG9yL0ZvbnROYW1lL0FCQ0RFRStDYW1icmlhL0ZsYWdzIDMyL0l0YWxpY0FuZ2xlIDAvQXNjZW50
IDk1MC9EZXNjZW50IC0yMjIvQ2FwSGVpZ2h0IDc3OC9BdmdXaWR0aCA2MTUvTWF4V2lkdGggNDM0
Mi9Gb250V2VpZ2h0IDQwMC9YSGVpZ2h0IDI1MC9TdGVtViA2MS9Gb250QkJveFsgLTE0NzUgLTIy
MiAyODY4IDc3OF0gL0ZvbnRGaWxlMiAyNzQgMCBSPj4NCmVuZG9iag0KMTcgMCBvYmoNCjw8L1R5
cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL05hbWUvRjQvQmFzZUZvbnQvQUJDREVFK0NhbWJyaWEv
RW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0ZvbnREZXNjcmlwdG9yIDE4IDAgUi9GaXJzdENoYXIg
MzIvTGFzdENoYXIgMzIvV2lkdGhzIDI3NiAwIFI+Pg0KZW5kb2JqDQoxOCAwIG9iag0KPDwvVHlw
ZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9BQkNERUUrQ2FtYnJpYS9GbGFncyAzMi9JdGFsaWNB
bmdsZSAwL0FzY2VudCA5NTAvRGVzY2VudCAtMjIyL0NhcEhlaWdodCA3NzgvQXZnV2lkdGggNjE1
L01heFdpZHRoIDQzNDIvRm9udFdlaWdodCA0MDAvWEhlaWdodCAyNTAvU3RlbVYgNjEvRm9udEJC
b3hbIC0xNDc1IC0yMjIgMjg2OCA3NzhdIC9Gb250RmlsZTIgMjc0IDAgUj4+DQplbmRvYmoNCjE5
IDAgb2JqDQo8PC9UeXBlL0ZvbnQvU3VidHlwZS9UcnVlVHlwZS9OYW1lL0Y1L0Jhc2VGb250L0FC
Q0RFRStDYWxpYnJpL0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9Gb250RGVzY3JpcHRvciAyMCAw
IFIvRmlyc3RDaGFyIDMyL0xhc3RDaGFyIDEyMi9XaWR0aHMgMjgwIDAgUj4+DQplbmRvYmoNCjIw
IDAgb2JqDQo8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0FCQ0RFRStDYWxpYnJpL0Zs
YWdzIDMyL0l0YWxpY0FuZ2xlIDAvQXNjZW50IDc1MC9EZXNjZW50IC0yNTAvQ2FwSGVpZ2h0IDc1
MC9BdmdXaWR0aCA1MjEvTWF4V2lkdGggMTc0My9Gb250V2VpZ2h0IDQwMC9YSGVpZ2h0IDI1MC9T
dGVtViA1Mi9Gb250QkJveFsgLTUwMyAtMjUwIDEyNDAgNzUwXSAvRm9udEZpbGUyIDI3OCAwIFI+
Pg0KZW5kb2JqDQoyMSAwIG9iag0KPDwvVHlwZS9Gb250L1N1YnR5cGUvVHlwZTAvQmFzZUZvbnQv
QUJDREVFK0NhbGlicmkvRW5jb2RpbmcvSWRlbnRpdHktSC9EZXNjZW5kYW50Rm9udHMgMjIgMCBS
L1RvVW5pY29kZSAyNzcgMCBSPj4NCmVuZG9iag0KMjIgMCBvYmoNClsgMjMgMCBSXSANCmVuZG9i
ag0KMjMgMCBvYmoNCjw8L0Jhc2VGb250L0FCQ0RFRStDYWxpYnJpL1N1YnR5cGUvQ0lERm9udFR5
cGUyL1R5cGUvRm9udC9DSURUb0dJRE1hcC9JZGVudGl0eS9EVyAxMDAwL0NJRFN5c3RlbUluZm8g
MjQgMCBSL0ZvbnREZXNjcmlwdG9yIDI1IDAgUi9XIDI3OSAwIFI+Pg0KZW5kb2JqDQoyNCAwIG9i
ag0KPDwvT3JkZXJpbmcoSWRlbnRpdHkpIC9SZWdpc3RyeShBZG9iZSkgL1N1cHBsZW1lbnQgMD4+
DQplbmRvYmoNCjI1IDAgb2JqDQo8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0FCQ0RF
RStDYWxpYnJpL0ZsYWdzIDMyL0l0YWxpY0FuZ2xlIDAvQXNjZW50IDc1MC9EZXNjZW50IC0yNTAv
Q2FwSGVpZ2h0IDc1MC9BdmdXaWR0aCA1MjEvTWF4V2lkdGggMTc0My9Gb250V2VpZ2h0IDQwMC9Y
SGVpZ2h0IDI1MC9TdGVtViA1Mi9Gb250QkJveFsgLTUwMyAtMjUwIDEyNDAgNzUwXSAvRm9udEZp
bGUyIDI3OCAwIFI+Pg0KZW5kb2JqDQoyNiAwIG9iag0KPDwvVHlwZS9Gb250L1N1YnR5cGUvVHJ1
ZVR5cGUvTmFtZS9GNy9CYXNlRm9udC9BQkNERUUrQ2FsaWJyaSxJdGFsaWMvRW5jb2RpbmcvV2lu
QW5zaUVuY29kaW5nL0ZvbnREZXNjcmlwdG9yIDI3IDAgUi9GaXJzdENoYXIgMzIvTGFzdENoYXIg
MTIxL1dpZHRocyAyODEgMCBSPj4NCmVuZG9iag0KMjcgMCBvYmoNCjw8L1R5cGUvRm9udERlc2Ny
aXB0b3IvRm9udE5hbWUvQUJDREVFK0NhbGlicmksSXRhbGljL0ZsYWdzIDMyL0l0YWxpY0FuZ2xl
IC0xMS9Bc2NlbnQgNzUwL0Rlc2NlbnQgLTI1MC9DYXBIZWlnaHQgNzUwL0F2Z1dpZHRoIDUyMS9N
YXhXaWR0aCAxOTg0L0ZvbnRXZWlnaHQgNDAwL1hIZWlnaHQgMjUwL1N0ZW1WIDUyL0ZvbnRCQm94
WyAtNzI1IC0yNTAgMTI2MCA3NTBdIC9Gb250RmlsZTIgMjgyIDAgUj4+DQplbmRvYmoNCjI4IDAg
b2JqDQo8PC9UeXBlL0ZvbnQvU3VidHlwZS9UcnVlVHlwZS9OYW1lL0Y4L0Jhc2VGb250L0FCQ0RF
RStDYW1icmlhLEJvbGQvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0ZvbnREZXNjcmlwdG9yIDI5
IDAgUi9GaXJzdENoYXIgMzIvTGFzdENoYXIgMTE5L1dpZHRocyAyODMgMCBSPj4NCmVuZG9iag0K
MjkgMCBvYmoNCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvQUJDREVFK0NhbWJyaWEs
Qm9sZC9GbGFncyAzMi9JdGFsaWNBbmdsZSAwL0FzY2VudCA5NTAvRGVzY2VudCAtMjIyL0NhcEhl
aWdodCA3NzgvQXZnV2lkdGggNjAwL01heFdpZHRoIDI0ODIvRm9udFdlaWdodCA3MDAvWEhlaWdo
dCAyNTAvU3RlbVYgNjAvRm9udEJCb3hbIC0xMTEwIC0yMjIgMTM3MyA3NzhdIC9Gb250RmlsZTIg
Mjg0IDAgUj4+DQplbmRvYmoNCjMwIDAgb2JqDQo8PC9UeXBlL0ZvbnQvU3VidHlwZS9UeXBlMC9C
YXNlRm9udC9TeW1ib2wvRW5jb2RpbmcvSWRlbnRpdHktSC9EZXNjZW5kYW50Rm9udHMgMzEgMCBS
L1RvVW5pY29kZSAyODUgMCBSPj4NCmVuZG9iag0KMzEgMCBvYmoNClsgMzIgMCBSXSANCmVuZG9i
ag0KMzIgMCBvYmoNCjw8L0Jhc2VGb250L1N5bWJvbC9TdWJ0eXBlL0NJREZvbnRUeXBlMi9UeXBl
L0ZvbnQvQ0lEVG9HSURNYXAvSWRlbnRpdHkvRFcgMTAwMC9DSURTeXN0ZW1JbmZvIDMzIDAgUi9G
b250RGVzY3JpcHRvciAzNCAwIFIvVyAyODcgMCBSPj4NCmVuZG9iag0KMzMgMCBvYmoNCjw8L09y
ZGVyaW5nKElkZW50aXR5KSAvUmVnaXN0cnkoQWRvYmUpIC9TdXBwbGVtZW50IDA+Pg0KZW5kb2Jq
DQozNCAwIG9iag0KPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9TeW1ib2wvRmxhZ3Mg
MzIvSXRhbGljQW5nbGUgMC9Bc2NlbnQgMTAwNS9EZXNjZW50IC0yMTYvQ2FwSGVpZ2h0IDY5My9B
dmdXaWR0aCA2MDAvTWF4V2lkdGggMTExMy9Gb250V2VpZ2h0IDQwMC9YSGVpZ2h0IDI1MC9TdGVt
ViA2MC9Gb250QkJveFsgMCAtMjE2IDExMTMgNjkzXSAvRm9udEZpbGUyIDI4NiAwIFI+Pg0KZW5k
b2JqDQozNSAwIG9iag0KPDwvVHlwZS9Gb250L1N1YnR5cGUvVHJ1ZVR5cGUvTmFtZS9GMTAvQmFz
ZUZvbnQvQXJpYWwvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0ZvbnREZXNjcmlwdG9yIDM2IDAg
Ui9GaXJzdENoYXIgMzIvTGFzdENoYXIgMzIvV2lkdGhzIDI4OCAwIFI+Pg0KZW5kb2JqDQozNiAw
IG9iag0KPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9BcmlhbC9GbGFncyAzMi9JdGFs
aWNBbmdsZSAwL0FzY2VudCA5MDUvRGVzY2VudCAtMjEwL0NhcEhlaWdodCA3MjgvQXZnV2lkdGgg
NDQxL01heFdpZHRoIDI2NjUvRm9udFdlaWdodCA0MDAvWEhlaWdodCAyNTAvTGVhZGluZyAzMy9T
dGVtViA0NC9Gb250QkJveFsgLTY2NSAtMjEwIDIwMDAgNzI4XSA+Pg0KZW5kb2JqDQozNyAwIG9i
ag0KPDwvVHlwZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8PC9Gb250PDwvRjkgMzAgMCBS
L0YxMCAzNSAwIFIvRjcgMjYgMCBSL0Y1IDE5IDAgUi9GOCAyOCAwIFIvRjYgMjEgMCBSPj4vRXh0
R1N0YXRlPDwvR1MzOSAzOSAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0lt
YWdlSV0gPj4vTWVkaWFCb3hbIDAgMCA2MTIgNzkyXSAvQ29udGVudHMgMzggMCBSL0dyb3VwPDwv
VHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFy
ZW50cyAxPj4NCmVuZG9iag0KMzggMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGgg
Mzc5MD4+DQpzdHJlYW0NCniclVpbb9s4Fn4v0P/ARxtIVFLUdVEESJN0posW6E6zMw/NIlBsufbW
cTKS0jT76/dcSImUQ8XFoONIIg8Pz/U7hxRvPou3b998OvtwLuTJiXh3fibeXb5+9eZ9KZSKZCIu
V69fKSHhPyVKGck4EbksI1mIy1sY99sXXYpv7etXUnzD//32+tXXt1Lmxcl/xOU/X7+6AGJMUMnn
KKaRzDyKX2diPp6aPzNTyQKY8Wfu5nrWzI+T2fXt/FjPKni8N/82u3k6+wZ/tPvk0+fIZ2WkR4xt
2rmKZ6JD2msgVYt5Puvu4K+u2oodfnyAh1vk4Aa/N2JezO7mx+lsJeYlf6ju54nLUQIc3dTwkNDD
MA7fVPiqXoqbp7mSBwpGl2WUaJ9zXG973VU3tMIh+0+0jLIRlUjMlZqJL3UN+wamt3fI6GNEvP2S
1rJSR6klezsWCSjp2sr48XaeHciyKmIwJp/2phXdugaZivXmG1BajyjZuXEMfKX+3OPQWK2iRPlj
HyuyCtY466+ZKz37LvD1Ck2D7KBB64nZepCrXts/NzgGN9ubkNg9gFyMNankYHMKsJ2kRZTkPttj
wfZjMxmVpT920aD264o2ADbZks0uUPl1iI5Vd15EcWzoNJXltCbhLJq6QiLdhraGPhyFyOVpVIzI
uUuLi09nQjghTR0a0rIsjlTCJH89fLmzfy18eTOXqMYGxds9XS/uHsAYUBrdoRFLRaVP0ASsiuWM
QiYRo4UZwrm1JxPUlNUKfh8FM3JzGJ6zPYt7iE7prIaACkPI/NAqwd1EA7+VjWhMr1tXnVhX6BM/
cDy/Zbuu7YJiCdtPwBLI0oAISgQNbVEjg8ngN9uq7ch/pu0uyaLc2m+3ucWt0vTKrA7y7gaPvTfx
d3Ax3AzyBPzD0xNOwtfobxyaefOPVYtUmxp197eRXA0c5k7wfiBloBPDoEEZuMU6ZPC6SCKZ+/sI
7VkXWZSW7liBtp2Ky8XX/fA8ZAsVpcqfRTMu1xA7n7UZEIIxLDIGfLtFvT5hVrjFVxVYQwZJkSJE
vaSxm91LyoKwquwmfweip5/RPkk1L0tKQXTD4O8SmQwNsRMaLJE85mAgNYYZJvJnhSaJsYnV2vb2
UtsYzO7Rjv0jxGmWoJ8Oa4hj0JPOSOrLHxOhL/dmsZquQ+MLhTHS24qJL+By3ROhJNgAOWNDfkl7
ucbwrK3jgiqbmixXoSVfzcg7MI3t7ihOXc1BGmJZ39eo6qWbhwbrEOs+/z3icBM4yJKYp44Mpm5N
LEFuWvZ4Zm3xvbaDo6ApG+2lhZMdLtd1wwtxPrbBiB9q69C9Phfryhg6m/htSLwQ+bPYXyuUeBUA
sjL3x/4jhC1kHBWpPza031imkR7R/bIGOVbLeTKI+0j8fgrPnxFHVbslhuk//zjF/X8KxQSVRIXy
CYfAkFZFpDwmyJzjPCHz/PJXaJ7WGNnceWzQwYV0hrDWY+o8NDbRUTySjGv4wXCLsEeFpb8XRLSH
LwoBghtlZWuUEF8VUZRRrGKIzDrX8P80K0Xz7bm3f/zG+qyQ4SUnaoDD6E6fQJX0tKyDMUZF2ln0
hW0k3jaeAxd2G3GJuJD2MdR7sw+U/Nt1hdbFhieAx1vm00TuYDxMCohsDmVMW6lk+zn/c2KHkLC8
aZzpJsKudsdzPESn7+oeH2GabwesAWA34Htg9rHyyQX9NJZRPlq6ogwBwTdzg6+NjFSvVFgXWiDk
oSPCFBic659c5lKgsiBsCMBuoXpsknRNa9ZbquQUKocWVZkNjdXNds6xUPS4rCPs9xTYXwqeWWSH
ycLaETgKVJdW2yopSXdXs4+BeYUkoO3NoykKxPAZ9355AbEO0lEIY0CsLNz5E5Yic0jQ3lBErySx
WzSKeyrafUAaUmWE6UWMo+Cb99kzThbrPEq1t/JbqdLTEw0/6kKqPJNS6hMl4TlPTzL7Oj1J8M35
yXEKv8XZiYrh9yw/OYaZMAOInEtVSppd8ORjd4riNXBUXODviUoNcXUqdZoylfIU2cH3J6UlDI8y
xkWJCrJ0ppxXF7geT5b0iCPKU5xvGKJH4mbYKfKJvGtabWAOScJod3s6fcdUkPHsPS+dStpAv3UW
nLsBWuKQsspYbAJJXFpz+IiO4VoeQKEgMJUqSmJ//mQwTsPANMl1lKvDg2SRRkqOpk0GySIHVONN
+Ero9s7G9e9gzYzF6ntTXG631GJB8PsRhin8iGDjEoZetEPx53UsxIpCSoUpou6LMcTXqxWUSPdI
2lRYCPhg2l9rCl87XEz0YJzi47MllemuNPXfDwQtKRi2osL3N5uuj5nMzsuw3aoA6oxYe4C6eyIG
naLwaKo0jTNEjg6dw/KdLiFLerOm010SR8rntl1Uuxb1ZcrcboDlbY35emTWpD+Svp594PC3HQyB
Kt7VXSjnlSCu0foNiXdIKqidDVTQj1RRona7da/dca1idSbaGkvLI25pbKmkrppxNDaZ8glhCUwk
3LvfRhyrFkSWp04rmTbK4IAMbZxQ93hcYQJQs2eNGq2zoayQm4/cMhloIuMPbd2ERJpDICl9LoMt
yjzBMsIbi/bZ3AFrVPJtEKqZ0ryXliPnwTeCYBkqUkDw3hqTgS3zUOZzCdAqQuUI9W0zLku8oH2M
wf9dSjmBcwqnPGnivZI8xMltKvHTiklN8PuOSHEitTmJsoRJlpSXZEwZh6mf2kxEOReHYiJKzGf5
3uRak6RsoqV8WJ7YYXFBiw0Z28yGhZQZUpRDFi3NokoSuzjFZjrmg2ewEOh1nhF7kAfHW5fvSXIu
OMClcLJ2WDqTJiefkwTTtzaR8p+yXxWTt3aTdw8NMCEj92ZXDmIZM2O0iRPwH2uUMvuAESQBl/J0
XyrAk3Z5+qW0Dtm5tNaLwdt27rAxcL+GF9T0azeLaouO7vUuRj1SxbC5sdFm03E7Y1vbjgrENwwD
VzNqjPUNVECtx9qergTrbI1FhMPvQWlDQ7aBUt6bNpk3NKB4rX25UOLA+DxsaWOTr9tDboaerxmG
k+gj5o3vGysHzBsIl2132nT5qm6xjubckRGXTqw9BDwbhWIXNMl78Oz6H9oLelA62E3m2zJbK8FF
fJ2ztYIdenAV3QXcT+engz2CISu9H4DQV4x52pFm5cQhaJbkyQzzaTj6pBr56l7kOMjaY4jVSeoJ
J1yu5jm2q7yxfEKzWAsCOai2obM/TmP0klQ7mIPBcBeWTL3r6DSJWsb3d33tiuaV8ZGq6dF/hBFj
pP1SB1DncqhE/3VxjrYWymJlEulkNGUyi+VheK6TNMqs0/xuAcRjbXOuOULhja2cYpFS/w2e9jH6
pS+DhLm2x1ix7jvwN+aoJh8dAw7nDS2vC1CkqbYAzTMHmpMc24iiEXZ14f17aug6GO0nKevWQttt
fcTxqQRrABV+s7AaNFjd3wNzFBQWFZ7eGCBOXYsXdKUl9g+HMlsskA8yHQLriwUDMG6v+2gJZOhi
LZUMFQSDyi0yLgiU+XTw2OeYh7dDwwSgT8ENftbcTtgOOaB8VA8IkpqriPwagnRte0TxHma3NC/F
1s2PmrDUhltKgTNWNLnCF4C/9rTgsEtgLTZwFBxdzRm+X9pTLVEtYIXFHR0sZ6PDFXJshOW2S05R
/gh5IpXfY+WAhwZddeO4MKZKVhrOJ527Ls20egbsHwD0aT5QxYsJlPwgUQZkBULSpb/nvn7obQJ7
NNIeQUEJuR+WKGVZm5kUb1xSHuSl0M7QmwYfDRZ3RVT6c4MFmqa+gDd2KCG5bRRsZUo81PGmcguW
7qKsTa3xiDrhWwdLuhcAez8aeZAn/K55wuOZlVURIhmOJX1h45zcDuU6q9EBRsO5c0CdiUR04W0A
DfAHn0qF7i/k2NTfF1jvkNdbOkbCHgUX9Mjkf2lvC6oPX9J5QRjLdGjtgZaNFQs6GBM3NfoDlqlr
vg+xFAx/BjAzRJRtqGeK/eNS+ysGi7k4juLSH0uxFvkZDsbENjQ/TTD5e/M3bedfJmkfFmu2oGfk
1gZrQJ1HakR6MnsW4ewZ4/0U23Q6owCyI5vADNbS0bo5Zg75noqUTyXcg9HYg/HGVmzk8fPVe+Mf
+wfT8g6TEMe3F9I0LgVI5gM2tCjrFbOqNe5DvZC27yqBj+KFCrq85bdPuPO08BKuOXZvwXkF/AVR
kNyqApMxBv2CF0BBX1ipmKkPvUwYtWDwduLuznSUKgr8JgFRImmGrN2H/2rUJ+xBXTH7987eeBpJ
yr9sgofS9JpuonFUWhKYYeiIPoodQdMewg9T14oSXURa+RuftOJywopVjoeyTIRAq42wkiIsJCwK
l7AFDFPudQkUDZ+DL8EW72x65lZdUzs9p9WK74MBQQriIe+UaZTmPkukBTIwspXQmbWOc4Sy3tRg
ycgIxhu7XxTkiDoAiC+5Tg7dYQFSyicVhvu6yKO8DDO5fx1MhhWnsGNpwfsVmmcyA/gEfF+u2Zxq
uuFJKty71UfqRYyENbByr7ehrW52Gzq4Yx/833Ap5oYdmEyC88vOu0KBzfW9wwaEqJtd33Rf9paC
1qNyyPFOm9apuYe0bu4g2lDVhtSRKh0lmS+akDJSlSKc9cZy338y2kCxG6XJHozt/R3tmzcr+MTA
qylDd1+wqPNJT9uFmrCLVA2XAa5msbULUMopN0X6c29A7XRvtaVD5ev+zJVC3RXNsofiqXHkzdAs
4Up3CIqBZJ4kkdI+VyEnjpMCE7839ihY9qeQE5U7+KAGU5xlCMm9aZMNpjgr8eTcY2rUJ3revdAE
qiWCvU3H17Eo2do7LRBPC1vP9CmPgC0+r9zDbIrBbjFZdX6GfslmNV3+8TB74DwNL5KMJngXJl9o
mwQvuwHs8qlO2/fEZTeloLTqzVtPm/f4oAsNmpIxhaJt3Q1o9OaJb4Zt6RN/uCZaKhsuJ11TA6Hq
Hlr2D1v6E4llzQmcr1aDT12vthgIr72bJtfAQ9vxtWSq5+mW2tWcj4i8oD2p1TKJcmnDBW7KWJTh
9gcn5olqLi98GpjDczeHh6/A5BojlTfbXpNWE3YQS1g19+ftGcL/AYpOwt8NCmVuZHN0cmVhbQ0K
ZW5kb2JqDQozOSAwIG9iag0KPDwvVHlwZS9FeHRHU3RhdGUvQk0vTm9ybWFsL2NhIDE+Pg0KZW5k
b2JqDQo0MCAwIG9iag0KPDwvVHlwZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8PC9Gb250
PDwvRjUgMTkgMCBSL0Y4IDI4IDAgUi9GNiAyMSAwIFI+Pi9FeHRHU3RhdGU8PC9HUzM5IDM5IDAg
Uj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFnZUMvSW1hZ2VJXSA+Pi9NZWRpYUJveFsg
MCAwIDYxMiA3OTJdIC9Db250ZW50cyA0MSAwIFIvR3JvdXA8PC9UeXBlL0dyb3VwL1MvVHJhbnNw
YXJlbmN5L0NTL0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1Y3RQYXJlbnRzIDI+Pg0KZW5kb2JqDQo0
MSAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA0Mzc5Pj4NCnN0cmVhbQ0KeJyt
W2tv3Mix/W7A/6E/zgQSzeabwEKALEvJXsQXTiJkL2AHBjXD0TBLjWZJyorur791qrvJbo56NHcT
LNYPqh/VVadOPbotPnwRP/304fPVz59EeHEhPn66Eh9v37/7cJMKKYMwEbeb9++kCOk/KfIoCKNE
5GEZZIW4faBxf/xbXIr7/v27UNzjlz++f/d1cdmLejd0Td0vpVyIqqvFMltU62WyWC/jRb0W1W5N
X0S3lOGifqDvj8vzdPGDvtEPN/Q5Ul8eMGrffh+quzOBxYZtTbPKRbWjSff0Py19Hi/uaNnHZaom
/frrsljUNb7v6Xsv6K+YN9BiPGCoWhZs90QLPCzPE55fdxjIAzaCtuAfVHsaglWaHS2PDXsWPl2I
5T/E7X+9f3dN6oLKZkrKyiSQSklfefdtc0/7bz2zZFgE+WzWuW+sjALpDn2uBhy37nxT4iKIMneO
7wAyCYNsNlbpovs1EOLnjTIq650tNbPFlrRVkZbaVjRDDwsLtsWOvhMoMKMmm9CCXY2fPhizKPOf
CdIWqV901e5+metFmwG79nW7EY1ac123vJQ6+Dqg1QVgdrttehojtkupYfX8lqnyIigifVLaVRta
C8noLRertq52NSAsnoAJ0sQlK4IxPFMBq4vsnbIyBv62YVW1LVZodsMjkL1u+if6vWf/AAafMPyM
x/cjnncuODvRVlhrYK12Z/gzaxt6g2ZI2n5baWczGjhXMK5YSIwgd6BvbKyBpzXDW3rK4iAyetqb
tdkxBqWrgRbmj+TzUI7SBpnZj7TSXdaL+YTQOBNh1VbNMmb8ADYVdhfP5lTNagtVMzwIdNoojKzB
wFTLp00ujfkIPesa8re1UvLaI1Uc50EYu1IF3rHEmrk71la4uP58JYTFx9Lh44JU4OHjLJLEB1gx
DCIZiTCI85h+TbNSdPevff0r0/SfSD+XX8TnR0DFayNijtTa4g2ho1ODSBam9LuS2godvzTDVhB4
ySrwtedKhQg2S9X38H2DfKBb7CuYFqAeCfpsbl8A5JDHKczAwxgVms0YAnDBuuclxB4QemFvbFYA
RNWKyYsEsRP58XnOLldNMYOHbs1mSghMwyezGoUgFh8kwaAk0B13v7QogzSx3I/kp7V+MNcgIlHo
vIM2eAsvu0c5yM5ZjEXv65VhGBAOa7et6RNvULd2cHx96QgmlYdyWtqq7lpm1kDcQEeaz34Geyqj
tjjAaEF4ZM/fHUJZgUbxszUiS7T4F4k/jDFGpxhAhs3J497g2m+LazrOF5zs9tsSawScXoibRw5M
b5kit2Lj5edPmHPG8yfokUwvWnK27wq7KP4n6XY4p4YZfry20OCKi7nfFj6Vp0Ugc1ee/6Y1viAQ
6oP5phZRkEh7KpFDGKXidvUVkdQ3Kw+S1J3FM25wIG3PFYcBhSOFnh2Iut6tcNQz39pxlgWydA9j
YtqGls4WyuwqpDW7exVC8alfPRE5mJCEfUUFzfVPD8gFdXTacsLwlm1JpanZ/mcObgqZH/DrNaRR
uNFuDRx2/Z68h34yNJzEjDnp0xj+EZwmSlrxcSAnT6v3HEAJH5AQCQf9eRQXhFEBXVME25hA2yEL
iRefMegTbf0BQ0YEeGNRLoNcukc9SuuxRetzfcUxIvPxnJJMmiazsd8WtzjmpJRN0yG/5jSfP3wd
ugp1QjM0Y0UAnVXtP5CA2+zEzsdcvGE3yuwkp7qjdVuO6FwMTJm9uH+Cx5EfKhJvgSHOt6pOVGuw
alf3REE5r6UTVTMLtDOh4JDdpwVoJJEeOeTr6kllAb14VXlgj+SIPcI8yEsbv+J/lA8is55I1EIy
UyLy3H03evEPX/woYsoHnE0o+Egu3O5eFNQNcHO1fkR/YIAqdlTWYP6jJJoFUE7eT8JBmDXBQZKa
V2zDdopsFQLVitRP6FFzxq3Zf8bwpSh3tVUBodmN+aAh6DeoICmjIDZpD2fKHQxKSQlLjloD4alw
Dlar8mSP6BzZ0Rn77R5NmqzAClGtk1lhD9rzVKBO5lKPx15tBX46y19Igy4oae9NVz3UIM95AcyS
U7A5VynVBhr7thz5S6f2Jyguz4IydWrH1Swf2jDUqoeRLneaLrU4TKvMgySPrhJteVx2rVoql3I3
s89p0xWs0/di03ISwmhBDbsT0GrVDc0KKmirjhNHPtqfSUbJ6rs2CL6Fseud59BJHCFuOYeGuroX
Rveq2mm9myraFND5a7o5rthMBrHZYzRj1U/FeF35ihVJ7JK7K3irLdQ1mTt2ZN/2xRdWJMWT0p11
lMVSP4slcYbKyqQlKYoIyjI+/d2zdZEGMpxNU5mMb0IeZO4+XxlPPflvYQGJ0vINB99VQ8GBfPeF
3Q7U/wizPjAtAMu/aiS2ykWtiO0AdsONAI3tKT1WHHxQA3y4yV6poWIZBpl0hP8pjNPri/P0p1Bm
N6HMP12cx/TnNLxI6Dd5ecF/+xTK4iqU5eWFjOjvVzmPitObC5oYhvHFfPfXKrg4zZA9OKrr/LiL
8zyQs+E+4MVFCOw4Y23gCTgNsS4rb8NlfdcPKl1qbIXn3HO7fzIptE7CpvbTcTeLqE4eXXks8cZO
FaJLs3mZUraj9q65dDHZ/ZmOkSqv3b7s1Y9VoGAW68R9PXDeX3GZQDxE+ygiwle7TNhUSEXaIeCB
djSlKhqMAlFbQls3lXfAG/TZ/C9nMQDesG24U6qZpPLlKVQ8ypl6TkOsUWyYjBz5n0Es/bgMZRjx
RKwlrxnIvBY+55m1Hk8oQ6x7IUP6nKcX5/hxUfJ2EIS2KJUzlNYALAVBMggTXkhpFrvUYit57d31
mlo2+ZpwJIrZ6EqqDXDi8lL9OLyBSEr+a4yK04K35f+zQh3eaI5Oao5YXKnj0X6jhFhcnS1OU4/w
+uSQRutllEjp3z4A9PgxpW90OJ4eqg1pmXPLhDSMxD6JWRA6ktxByfEIkvkjSJyXQWY45M+M6oG7
BRwmpz5hvRNcuRFdPPVI0kz9qv28tmLrb6ZaOGdngTOuuWihqECZ0V0zjL0mb5UblRR5Ulu8kwKc
pnxn2qsBzhcxYvRmbKVoeFxlBo7KwgbwsDohKjUoUkgdfSEboWkADNCmlwYioYwKBR8srF0tm7vA
DSPkY8q/YUJUjDjD5Dj9OG1N38P4+iInAF8ryLMbyCt8CtOchQuzZAQxgDg5Bguo8DztocBpfOok
kBp8ZUkQ5aYHtCO7Ozk84CZMfcsx4sdYvd/VDMTX0sKxF6SZ+LlruBMkDeE3htQpnx+s3igaIQRT
/qQE0WEi8PZy4qQIktg9CIKHrzuTIow7o/2dnBwwc8Y6tw/c7YQv+nZLCO7EBM4KvqQhIWznM8m0
Tjkvm7rFpyXKSREFRXbi3kWGdr4zdkpYrJr16J2hjqvWKidxQpqEgXRnHc15DXLJ7pmh151pmqku
Vz/rYgqjOxTjY/Y7ZjvzXhclOwBgx+DLbcjOCm+iWt9dZZRTEChdKX3qj/IkKFJ3rG6NZ05nnDl/
5Gqc4Q5XipFVY/ubZWkQ5u4eR4NSfiQoRXEQx5OvsROgmO8a6Is1VbVipaMPimCVLz5vcZ8lM39f
v+DekbWBOCcMZWV2HEOyzIAha9pxDMmS1BC5B+nqPYqealX3ZyieqBofu/sTwTXgyKHiNow2SGXB
i8xS6BCqLEKUp9u+KmIfgJJbweqNgFocd7I7c2PjVO/6AoZAKeeZ81vOEuZAmL5m51IAQG/ZnVEq
qgtot3UDQjZtG3VLw39qKmyvHA16gdc0g2h2Ynwb0QzNo+mG0Jq+rn/JqLdFmylbMV+DZe5V2yu3
dGffyvDFmn6J4a/hCsk+YO/or+ESDiuO4iiMoQc6ts24Qlkp9JtEy7ma1dFT+UDb/ICmu3rt6vmo
5aIyAo8oAQzGhGl2qQcFVicYGlJKnJtStQVUc+yZS8DUwsD+0dyt8zdKMq0HC+Ku6kno0Ru0Wc36
uGh+HBvSjOF5QjnjKG8wT8gh89I+9EkhBJV2nrrTjvp/EpeINo5y+6FpWzFJanv6+M7gFIvlOZLU
yWL6DdCknDu+7QFF6DRb3KHE54bqGpyvr3p24z3RMJlwai/jqUOhGzgH9puGmSL9qbdaNgdslY2m
UZ3TW+vehpA7qoW7FXx9oeoQ3aIunFLDn5GkrnqeD3tFc22imDLDV4+m07vnhsC/zo50caWkVM+e
z6EkVpHk7un+/sX7SkMGZeHMfCOaJAkOZkvKT2lYN0873ajg1kXd91Xn2ziSZZDGByJHkeTt/Tcv
UZTOJx5KfBDhC3+Ej9C6KmcR3rk1zBararWtDzOtg+sS3XI68gatWjGHkm4Y9pu20oTfm4ZQtvhl
W6tKw/+GJS5tuU+rR1Pu1DnTjpo6Timrzl39zBpqzXjhXe34aKW6xRv79wiV7JSkuS9LqOocd5+5
ewGjbuLfcI4oDHKTvxAdPJjAbl0/qtSYKKTZvEDL3PQli06JBUTd4lIo40sh1UmjyIV3b8Xs/kll
oNVQ8QM2c1vJVxhey0iU/I6o3qAbJ6zdaSysmMmSbfK48ZaACYo6ZxrP8O6T5KjLHJnWE6fpVxS3
Vve8eQ3o9W9QBw7f/KjaejdYr0sq5lxegts2H08xZ5gGkUk2+u3j47BequzweYcQYeIA48x7eyFR
yjlLoWta2u+NKtVLzmdAYMtPD0zwhIQfJtGoTsGGm7EaQT7dRkUgY1cAv9eGqEZmwt7jNSEus3xl
OYWR8sQNVLnvjHVLeOfOM2B4+5OTBP18Z7G/PS1ljkvLfru0Hu8Oa7TAn3f99OLnqOVlUU5l2Z3J
GZ6W01sgJahK7bZslakTU42OXt9XQ+P+ELf+VNCuBkPGUwq3r7vN+CShmzIfb5lK3CddWfnxR831
0j+fesYUhfQ57AnL46vl9bgjqYd/uubcxVe4JhTGSevOrkfDWnnqi0NJLJD+jheHlxvcKpNGkRPT
GW/4vjpf7FZMsziMejeUEQ/76k+J18mTBG+9ojz5Wbskuo0PHiSOl02j8ttW49U8Qdo8wbdXXLmp
Rz3KOs8GSfpBj/UA/kw4L5+t8LcWVsm7rlvOQLl2WnM1nPofp4HMiZunc5wYyHNc5tizVM7kJYYQ
t93T+FcM8Nv7d1lG8Qjv2iNkF5KYJyZAxUGSiK5+/+6XP4gdDbYNZd676slZoiYXvsmvkQERjEHF
DbiQnWw0zCTlX96/+z3bSIAncrYR7qp/mTQQRVylaw3E5IyJPK6BaNKAPbnwTXYoBglA6Yh2hder
08v0g+P///fICvD3Ccd3jmUej7Fbkc7jIuESowBFJAX/EoZq080fTh3CllNDYLn0YAyOF+f2MiFV
T6+NghLUKK2E+aA0SfHPJ5ylkt85ypxOaZ1PN+nclnsaALndMWYre0wyGzPzRHQxo9ETI/pY+HCY
HHgiT058k1/xRGLptEgmNlXvpzi2gvW+b6moSRffd7hMo9pu/X1vKpf6u+rOmQSxHXx+e7pQURhT
RHpFqDe9V2tN4+Ko1tID79UCeia/4r2HAl4h/I8vtNQbobXAA+he/Xso/QiFSgn7FcreXDo5Tb6D
KyJdRU6tr9V4YzXRBm5rYKRe7CPTq+IpL2YnL7WcroA0IuxGb1vo31BujjeWztrqn66o5x38HKsf
K+y2th9sI/lTHfh0nvs98NPQu0cu/TgVyBBxoOMxXezxb1Pyxfhoj/NMfsSur4cCYVqiJ9CpufMe
iUQG5ciSeVkWByzJI0aSdIaMZGMW0Rx5MIgDBQZNFOmMGRlpWih5TSCIrE3HMk+Gsweo58K+Q50w
hPlBDTl6cEsUnNyVxoyZtjqiHT3quHqc7ZLZdmaMvd2hDk8bxbD5P5iHhMENCmVuZHN0cmVhbQ0K
ZW5kb2JqDQo0MiAwIG9iag0KPDwvVHlwZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8PC9G
b250PDwvRjUgMTkgMCBSL0Y2IDIxIDAgUj4+L0V4dEdTdGF0ZTw8L0dTMzkgMzkgMCBSL0dTNDQg
NDQgMCBSPj4vUHJvY1NldFsvUERGL1RleHQvSW1hZ2VCL0ltYWdlQy9JbWFnZUldID4+L01lZGlh
Qm94WyAwIDAgNjEyIDc5Ml0gL0NvbnRlbnRzIDQzIDAgUi9Hcm91cDw8L1R5cGUvR3JvdXAvUy9U
cmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCPj4vVGFicy9TL1N0cnVjdFBhcmVudHMgMz4+DQplbmRv
YmoNCjQzIDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDUyNDA+Pg0Kc3RyZWFt
DQp4nNVdW4/cupF+N+D/oMfuwNYRJVKXhTGAPbYDLxBgNzGwD3FgyD0ad++023PUmjPH/37rK1IS
daG6o1Y/LBJnZqSiqlgs1p3M7y9fhGHmp8qLs9CPhRcJ5UvhhbGfCa8sXr74n794h5cvvN/+y3vz
5re/3X567wU3N96797fe792xoT02kNbgd59fvvjto/KE8On55/uXL4QX0H8INJJ+mnlJkPmh9/kH
gf31H1HmfT++fBF43/lPKc2ff3354p+rx3W0Kos/1q/lavdz/TpaPdGD41qIlbdZpyt6pFZ39Kjw
8HJf3ONVxX/k3tNhrVb7tYg03OaBRnjrbPW8O9ytY/3w2cO3v62FXBUVhj0TUFHgtwN9F+DVtvAq
gn+uETLqfL9fy9XRe8b4LUgo1yIwhOTe+l/e5/98+eIDseK/X75YjnVxpvxEMu+YYxaf8u9EkMb/
gxn2naYPyjQ/9By9daLfNqzb3e/WQq2KO0wlXO3Ar2rbMLtafipRKnylXFP5Bl7uwHzMBwvA9OYl
CHvglQHZXn6kV97driSoin79hTf+4sTKNPAz6SK2xxz6r/fhb7eevX2E2T48LI79KJVeIjJfhV7g
y1T/Dyi5/8tZ79O4eS/i0FddAEw3SuwPBIEYghBHDIjhSAdCSeWHcfcj8t8GMXMxnOdXFt8tYi0I
ENsDMpg6QLIPxFz/XfMnEV4c0xjF/IkYa5o6lFvYKjfDWx4bu8a6BSUJ/SCk4STcaTgQFOzD/JFE
9WujW/Jv9Oe++EqyywquzH/Q5vzKWqjMN2sRrh7MPugL9YWkikz6MnSR6pBpay9p7rZ7ycndaGg6
NMmOsafV3zjJHw5b0nX5gRi6IUVWER+1pt7msAHQF3tSfalWJVBr+2r3uBYxHpf54Tup9+L4yqMf
trJptRBpe08vEpaFFipmzdSq3SPbkR2webzC+WbL9sOljy7kQ5xiyft8KHm6rR3Ij94eFpGZgces
8Mvql9fMpcjvlqYxikI/jFw0vl4enfKVkyU8dawjOwLaSHiLL0uELahcNJxhJaTZKZbSFNJtAMx7
twGwPuAyAAZkwgB0PuLQ7pphtXZPh4S0AEa5p0M8NozswfRVe5RgA5yh2tVQtdNY59DTml2R1own
NPvdDs5prdZJXcS0ISF1rFOg5yvS69AqYkqpzyNSaAfFQeRpna7ZeoZOj4c6nSmercrGKf5/qNIv
Y4OkN0PLNqLRyymVPZMGEh7ppMGtsediS/0kcmF7XhhbFMR+rJz83VWFDwGYsAkz8WK0cOE9wyQk
PZMQSz9JJ0yCfj9hEtoPOE2CBpkyCfZHHCaB+TVhEZr3boNggZywB0rFlj2gYI3CkXHFlQ7sAcY6
h562B2HiiwlzsNkXCKhZhV3g5M8kUqQJPOVxIl8NhX0ZlojIj6dM5DRPFuaAUiDGQVOP+ZocS9su
TEwoUtYG48ScNM9Gys3GnJLybGCeNcWOoaft0qgAvWfTCF9Hkb29mzKLc9Enys+iMzYZZ93yw1fE
OUacxnyu4f66jL4oE37som9pZkQUsAvlQHZkF2VTILu5q9hpuUOuj92lgrNkh594iiyZdyQweEuP
5h9Dle4s34XSMy7vXZ9N2S4b0XicCNDmMlCQglJnbr9hCm+YAr+QLUHgh0On4O/F4z4nrsDh3fFq
cXZ5V22xnovzJMgwwEHLmM4WajUMa+CZm7BGakUKLRo5tOhlJEsaJpzs+7L6smbxR6Ye9O/IYSe+
7eDJh5wE0Dl/rgNcRd5VGsM96lO2QbUgQo6dYkTSUMWGHYA2JeHdc/XgJ+0F5uriax1G0KYO8pqY
Z1ebv697XTIBUQ9f65w7MkfEO3uBv6zA2i9rAL7ynL777PWWfpi4yOZdUZRL44zJS3WhhHqiEOxK
wpNEfjSsMSznUV4oQyrw4XCPU7m4xKrIF05sz1gEmjBvLEgBKcxDk9+k7cVpT721akbt3FW52aIi
kPVz0OgM0mdjS5CNc2BzBukXyqTKaHQf2U1ebrY+8XuoOXyURZt8s86JQW0g77rRa5VDWUBCO2+/
fsMfVVPvg8R/Wd2RalmYjRRbKtfEnPXDuchkgFT4OLJzioeilwQg4uVEYdC8n0gCtB9wJgE0yFQS
wP7IeBJA84vftNyy6Gjfg4wuiMFig8geSC8JIEPhZ01UJkh0I0d4JIYFv+nBJ2NeUJuNGadaa9ea
+eEritXkQ0HeOwpcO1OOgHMueSIRGOAg72TEadAaKZhk6bDKNz1Y0xxPKJ1Rmt+QpISBSG8DIT4E
IqDfs7f4/eZ19IZ+D26EIJggwnP9TL29wQ8CycwbQSOS9zcxPU3UzWv5Rn9Ivae/YzyO1Dt8C9A3
Dl1wzuxcdTGYi/EV4ZjtDy0ZSyOWKRounIgj3fVRK+K+YL7WbRhNJc27K6DBtZqurS7FbJ/rVhg4
3ARAP54OFNNttghqGpfxzmmG586vFhvirxpvKHlq2mDaKECn97ndxas9XDjgJvF/bAqn3jc4VdqZ
2LADxr0/qOPEupZgulDG9zWesZtS9yFxNKLfVtui5NoGq4vDesLzv3RPiQyh02BPidtYb4XYbIX4
I/7dCPWGd8pr/BSB3hdmm2DXqAA/+rtNSN5uvHvMrtS7FLv2ncKXbkT4Rj/D32Y3Az5rdirTlGZM
B3/4PZPAPzEQJN4mRFK6+BbN6FHkYNbpPIGcpQmnRDpQfqIGhNyWRV5xTUr3wnHyJGHJjU/sU26A
2xYH76gDzteIOGNTXfrnN/z6fWe269fHe7h1/1Hvm/JfpiOLdvb9rjy6s0YXTltmpCmHma7isPlZ
Z45AD7EgoWD6zum1zSYjU76IXGScFAO1tBjIJCU/Z0DIZ+JGYnVC6iQDrc+mgiCgcRGaKWr747xv
uwrKTMvE8QEyUCcNTZLCHd3O3lRpBo/bMYmx5EOnZ6WOEkCrNlDQnWJ1Msk0l16Jamg8Ti/5o4GQ
pBo2Ot+0uOipQKLf0MGsk6I3rM5fKnoxjYuGGog3ItaOl6RZO4+93a3pNe3mjfrC5zX9pryZtTB/
f1qbrLW2yseqdj3KvE4QdzN6tSlvk96HpiNYV++5iXd3FdmuuaR4eJ9L90/EElCzqdC+HPPvy2ur
hEQmcdFwUmSSpd13GbG7Oe6+w6VgJ6F2zdn2J8YlUG8bx1676x/41Vn+wI0ILCcfIQKe0xfwvBMq
CO2ojIcKre9iwBovaDJgqIOPpT0SGQZ+4uIp764/aFcsHjLIKMa4CbR1MrhfEPAO2OO1ix1fz6zU
0hYqJApdJH4lEuw86X0JDbK4zYiCBD0tDmKaygTrI/bZtPuW3yFltjgxivwWJ2fOSTul3bQTUjFT
aSfz3p12sj7gSjsZkIm0U+cj42knwzF+BX7JQeLJggAlPSCDqQMk+0C95FOEBrY6P4McresgjcgG
uSceK+zBZx5LMMknSW9GApURn+oHtmlePgy9qW3+6Mo9zSZPkPuSuKg7mXvSHDWSMMXRcFiYNSRb
g0dInjJeozSTao+lNk9sdAJtPOzfySrwT7IKHOHCAN0KtiT8PEx1xEvvTUitLd57bZ8aIxPDDlFo
y6P4X/ixMWGNbQo+dm2TMZ7a/AWtITXYdLTONJGpyiZtHwwuiMXwd4qHw5Bmbxur136RPwPLHIQ3
IuogshNpbDYJG8f2iUaaZgODC6zprf4QTcyyuROG9awFn7AfUZaMhdh7PgHV7ZmP4aRSEFXqMpyz
wDObpIicf4o7HSQ5SzwX4EvQ9+nA91zuWkvl5Yc740ubftoHnXswDn/tcRvVgxNldcOq1jjwCnSG
DO0d6epdE+RVWy/nSjM7ydp919/OS6ehnj1nheJF7Jqz00u5WMxSOZZLeOSTg/c6wGmCo+LO4xCX
xU0f5iM3qnOIAalVLZvwZ5BEJJEcLINtARafmaQRFKM6ZkYbKFltHl7pTASiuiPaqOVqv0Og9qNx
h/KqaR0hIbveAiTBWHhUlCWHsgfDSV4JPmWqOWyfH8VUmsOjddiJ+JSztxXHpPaJ1WYof2//C6Er
b6Y/d5YPeDcVE85fHJXw4ozNGkmMUHEOw91pNR8zeQuZcPH7U5twz5m3R51j16dnkd9LVyW8Yq0B
dhcKxISlj4hDapDZsAJRbZp0jlrbUrZvcce+GWO6vHVKSU0pB5Em7puqFV1gEyI/SaYQ78qqKYgM
qh1xpz2I17na5hUv5mP+va2v8J7Bd3h4YZ1RRnx2MJ1S1W4ivTvfBogYSTbHHM8IkMJeXR4BgxJt
gITQohcjGZA2RrJhrODEfKYOk/pQJixUwo6UbCArhGk+JceIAt2Gg0y3xT+LJAsC43tABlkHSPaB
evGSoLBUtYdzQz4y5/Dvh9V6Hi2do09GTJGMcO/B2S1w3S6WZLq78VIaRZKgQuug8WTcZDhbH1WZ
5OywaG+odo0+bWDHqf68RbVoLBHqbVlnHL1vRaHTuehyvYMmMf4BuQa6w0vVvVwOTTCb9gjH5oSL
9n7l2jcFNO9TpZXYo6ktl4+gkQXmWLSF5SNfHKEN3OKk12yPAl8MKwVlUT2VnP3OjWolxc1quG2v
aqr69660/c401z3mNQ/0vO+bHF/pHfkrpnFVj67PUWDwK23rMQCM5BokY7Pt/uLMUfQocvHGGUhd
gE6isdyBzz6AeD05IJuWDI2Z7lXoR2knljc3ZWUd52LpnLHu/J2nUpxpcJC9/BJFsbGao/jaY+K/
/CtomVRHSuO4T1VowmFbwcXCQk5eOOKcV97TkU/bZs1VN6bfRfDRWxzWGD0QYM7Qjh4IsA7vXmm3
o1pBwbxjVsvLEto6hXDhgxOclw8DnWodLX5lrh0ynUkwKdfSC2HKn+kTCaeczDIfHYIeCOy+kR1C
3M6poadH0+0LTV/qUHdwigcKrmsAMFcf2R6ymCYW4EsnDtwgtll+YVKBTL1jzm126WlP5LXhd33N
00X0TISaYRJj4DDUNFXQf6vCqOubeJ3e3kgTr94mSJfqRPTHtjJKH6z7utKsTthGiamD3oo6pa1z
riZxPEhtIwCumyabfLPp12Jq6gS4eTwRD89f2TDElhvn5BXMkww5f+LAt7xKqSUFyZOhBzGz4b5q
cqzDEs/l9psPaDgI1ieCbEcPbUk/18axf7Q0X50k4GY19Iiw/mT/lFtC2NfE8NppKZAeapIJE4cF
L14MmY3lB95SxIIVqHD7W7wqyoLr3BzXPNbNtPWJFF0x6JsCLBXmXxz5jdfpDO/2yYARr3qZ9qad
C818rMVKzT021/tC+5oTnbYXc4YMbjDS71L+1NfPxT1qOx2yND9wotIlScyPTAQm+Lkewi6nNhia
rXct63B6D6d/TN6pKBGVtz1wjXhpa/Snrl0QdBN8fHsyfgn+MRu5wfEKYqRIZ8nYxaydu33y4uUh
xMlwU25YMhbHqdirdeCEEMLnO1S7sjj20oBxHX42Z3+OV/D7AzSwOci7gq8Phahc+Mq80pdFwimq
9F023v8+oZU2YReE9n5dV0vsuoLZ5uw9XU9ugsyPhgrPUm3FZLViPv44wSUtDvwnA6Rhw+2lHhuu
U0qn2gDqunXY1Oyb5nXR1rzR7m5X98XpLjNdo28/gX4COfC8TKHf4G97BxgUTfdoNYg/3qhe30C/
tgHsYlBud5+JGXE+7ap+zwHVnRD2R7UX2mtvYNC0bkowjX0Ypdo+ARxJiDqIFncx66VPQ8QQ4w0B
CH8e9NlTOwdmqq9joZ6uf2IXs62mWLkw0RNHiUY/nrjX6YLIOPFl4prTdSJj5PjH8T3juiWY65zv
QGNzzC5LE5lt9k91Wft4zahYxOnYWSheqDP8LOPO7ExKmKP5T3WvMWSED/Y813kPXdD0OMw2bo11
+uIa2ZDMOUVOBINUvmoDk5Wtm+but5hPTRb4Qeyi5goSmEW6F3EUn/apsXPL66VicfPQyEE0E4jB
+ufVrgnNOOXy3B5G23qIhWyfWY2EBHrfmCs8q6aTvv0ix06P+oqEPjqKmT7xEZF8j/J7iNSePrPn
PiN/MVNkOHJ5ze8mENxtHnR3yJ/WxSf2HR7t1qn4/Li+CZr2FF/57RkHX4eanTqzdQSgc8sMTfkP
3PUNx4vvnG4v/f4B7a1V87WYQSNGLqJpmqWq6dus56NPAkS0DvTnFL7jbuEbWYAsagrfSZYNmoMN
SFP47sA0VebmM6bwPYDiej9DtYXvDlBTi7Y+JceIAt2Gg/qWupZ/FkkWBN9T1wUyyDpAsg/UK3xn
qS/Ou7o0TAZ1bx4sXYNPlr2FkGP3lx+3uTG3umEf3fKmM51slqgvyT+4Kt1zqYKGxGWF41SdLHQb
Tp5xW2mYDkIDQ/PcizodNHOZ+8CpuLoz7OTJh9mUZJkfChclOk3GGRb3geR76NCycJr7c0gbC5+i
RCD6HSftDVLP9O8ju++xCUco9Ih6Dcn6fL8OndLbzsn9xOStk7jbdm0FMnUqPW4CGdNSbFqrTx7w
v1RCAtSezzyQ4h3ZAyvh9uom2CdnimYuXRFy55GDLlOgb86js2C07aT6UPp9qc1je87PGNQNu7hW
2s34GHA7DpU+pgdr++fjno35rtr/cpq1ufNTEaldx/TOsWlZ16ZBqQex3cwl+zbNgNjNXIPOKesz
bTOX7Ns0A9Vp5hr0V3U+JceIAt2Gfe6bVy0A59WrHZgTd6+mkkZYV5P4UjrUcBQMDBoPlq7BJw1a
mvCczz32RaqY+5FfuSzZXHKECnArk4Ock5bMsLA54jXBQjGwZIZmx+CTespB8+et0yrMRqiEr5Jx
hGhGDqIo5nbk4/KoY8FXNp21PkugY+/Tga5tg+sfd0A6uDhsOLTT1em8av//hLg2nVo3OejcEp/F
iKFovbr8cd+vuyBA7G0I61aXk7oxCru6EacmAjmpGw3IpG60PjOhGw3UtG7sfMqpG816moOB9Wra
ABE5pNIZyJwBwlpEg0zGOhYp+gSiTU0N06KaiIcM1HQ81EEne+hqGBvdMGY6D4pl5/8AywP5PA0K
ZW5kc3RyZWFtDQplbmRvYmoNCjQ0IDAgb2JqDQo8PC9UeXBlL0V4dEdTdGF0ZS9CTS9Ob3JtYWwv
Q0EgMT4+DQplbmRvYmoNCjQ1IDAgb2JqDQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jlc291
cmNlczw8L0ZvbnQ8PC9GNSAxOSAwIFIvRjYgMjEgMCBSPj4vUHJvY1NldFsvUERGL1RleHQvSW1h
Z2VCL0ltYWdlQy9JbWFnZUldID4+L01lZGlhQm94WyAwIDAgNjEyIDc5Ml0gL0NvbnRlbnRzIDQ2
IDAgUi9Hcm91cDw8L1R5cGUvR3JvdXAvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCPj4vVGFi
cy9TL1N0cnVjdFBhcmVudHMgND4+DQplbmRvYmoNCjQ2IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVE
ZWNvZGUvTGVuZ3RoIDQ3NDQ+Pg0Kc3RyZWFtDQp4nMUda2/bOPJ7gPwHfbQXW60oknocCgNt2j3s
YfewhytwH9qFoThyY9R1c7ayaf/9zQwpiXqM5MrKHm6RJtKQMxwO503df6+voshPYuFFaehHwhNR
6MvECyM/Fd4xv776zw/e4frK++l37+XLn367+eWNF6xW3us3N95/zdhImbGhOzZQzuDX766vfvpZ
e0L48Pzd9vpKeAH8T3hx6Aeh8uIg9UPv3efrq8D7iD/+fn31fnG3lIvdsfi2XkaLP5cv1OKYfV7G
i/V2d1gqerv+Aj+O62y/Xwq1+LJ8oReb5R/eu39cX70FnP+6vpqBRpFoX3M0/vgM6BJfJAw6r4nO
e/vbjedujZh9a6JU+7E6f2+O+TJd5PNzRSkkg6GmxZaSM4A3DFM/0aVwS6F9JQaFO6w56I4N3bFn
0hxK5Scps5On4vi4KR6PIMm532HXxajjxI841Ay3XC5IywUaBnsnEzgAIvV16AW+SswPJGT7w1nv
ce/te9x73QTA1crYnSAIRBcEGGJBLEMaEFppP4yak6jvBrFrsYynVw7bHWIdCCS2BWQxNYBUG6iU
0VIBwzaqtDwbSeBHipFR1T3lMFZzQ8fPeCL85Hz9e8wO8OYjSu56+UIuUB9HAM2d+Wm0iRhYGHK0
/ejNjK5kRZTguEtZAabp43Yp5OIwN1dS5acclbwxmoos9qOIwzZmi/TcUqph6edbos7WHHE/ct40
TRfTlCVu9h0Bva4TDtvYjkRz74jC0VM3hLw2Pea1XcanXgJn3xRQUaipepGN7Uk8956EiR9ELTLA
AgVhKLx3m/eL9dyaEyCDiEFcS8MyWaxBGiKQBjyHn1Ew1nAkg0WG3vxfJBZJBMMYSucXi9QXLF/G
5CKZWy6EQldkBsMG/j1tDmxeuMDYC/4KZ9+qUMBWSY7scYffOFPWURxyptKuw08UM0NH3X3GYXl3
n59yZJS3fTwsUbRB9IsdcRJZffLghOSHTfYAPD897gEkKxAm95D/xX2OAHRs6MBktDewF59hX/JD
gW9psq1X4IB7mBNfe60z1j3986y630c4L8qZiNnEOBO9ExHMve+XuSfDau8yCiVYJhVzFH5YoIR8
WJKcociQOJo9A6kEkov7DOQrJSE8IMSTZ1aCglzKIQLgYmkFduChSssUzyV3vUaXUP6JB+O4hwOl
F152+IY05rjGr7vTUgg4fOUOeLCSj7Ap+YnWMZ3QqI/5GsRU9hP6MpCxWs282ZHyhT7PG5kBWeRH
8YAjmO9RNhxWN5QTqTNvt52ZKiVjHwPqv4QFSgV+yOyvOQD5Jsd1ktCdMvx5/Da3lCnwbJh9eA4h
U2l4tss7AzLyAfqRZWUu2JGsw3Mpm35XboO6Gy34em604DSFrL9qLQt6Yd9w6eiYDVsYdLzRW5Pz
WxgwwnjizvJ1L8cWCzpy/diK0kH1MvgNvA/cHg08iuHJvlw/OkVFDk6TIzcegCDP8id8VFmFuR0X
HWpfnhsY9PouZZrfyVYKxWde7Xs+8+pMwGVeLchA5rUxCZNWJYbRm5pdLh3VeySjCVJicUBUC6SV
UNWJwuNTFxviiIkBRNiJtmhwxA0eD7eCAPRxR1mBJJZ1qvVDdmdV13G9p/DqExuCTqVGqASDkX5q
Rl1kOTdXdBLj8DYh22NuVNQDMKPLlfmZIn0VcsSMhpZWrOqiDC9WqhNjWJqZweMWqHcj/2+xJacY
p65SxRLkhFnlHfpSZOBYOzsZb5KSO9OLt18oZ1+73WFGKve7paS9/EQhTLfYcil2OESB4LC/mB+d
Rn0/tNhTQSEkZRDQxykej7wlnkqHDMG11N+pChpHXLdMMeJwiqBox9rW2IDU1tiFcQxh0CyFtqGs
/xE0qqEukGMwg2a1s0UU0m0ZWBY8LfscihwAW+90YCyqBoxqwbSNMyrhyjhjDMUp0W7VgsZGzNhx
IwRKRp6fqLnDEBb1aV462af7zGqDL6BJn1jzNI1KkWqEZ6gct06Gr1Ymhvgad42Tobh/7Ljm6qf4
3f3u5MF/G9ulk995T2irRiK1ibTIMPATwdGSeQ9g2yLj6ZOVzLMT7SuZyALbibxbtIrhIkOl48Fe
3y212WjSR2QNPpp8JkTyHj18d8/nVS9kqk79tOswPS4VWYMNWfmop8x8IXY4K1Iy2GdfaqxodP9S
q8LDycsOuBcwJ3krEe0KHVWTuMsO3zzeizzhnlMmkzLi+ZY8pqNHZxuYGC/KFOcz7aSKsCTZXl9+
PBVIyNP9bl9mUgeFbubzApCR5Ig7xwAmTQOoE+nHCR+L2vd8LOpMwMWiFmQgFm1M0h+LWobRK2CC
DDuE1ABISBOmxOPCqBZMy+Khkymq/h4twfHQnG5OOzavO/r76n9ahtjFOLU88bg05wrhbezA2b3J
lGLBlEb0Ujpq+SxeKxWD/A27xZ/u6O/LDTJUD1s/NDH5n8jko7E53h6NSl5m8vI9miVB2Si0XNpY
riK73ZtaXozh2RGL64ikUosQqtHGbncIduejWSNF8svWo9LHgJa7mBGCxrcZ8SsuQgDBv5PBfEvh
6g4F6QQWd1fWJ70NvqBMZZ4d87sfjX42EWrT7M1Nv4QgIBUc/YjWtTxlgckUuuC0CG3SsN4DKW+K
Vl3jQ4E2Hh3BG9CLeR9oP+7myI9g7IyA1blRYn3he0SYIxa/AovdbbKSBWNvSX7rSs6JqhoFCSQ5
Tpln+qzqBg+yZre4a1uk4AHl3dixHwk2u4wTfYUQywksUEjRLYWAjllJ+CcIAyFerdRL+gefJDeB
jF8FIvo5EPpNIOJoFcHj6CYIArl6gSD4OA3wbxgV0BAh3uJkqxRep6/wTwNqJiXIMKG38ZvVC23w
4IQisCP0K0MN/E7gSWr+1sEKwWF+qV+XeIkkRBlHZjSScBOvEovLEF5ORMuD9dC6UosngL91wtWD
JkugimLM/vbz/RxHImwltbUK/XTIkTDvBxyJegLWkTAgQ46EO0m/I2FZRq80uh2dtLYDgZS0gCym
BpBqA7V9CZX4MnViS8mFeWE3tT08eNSTUDEN7/MkmOzchXgTGKZYvE5nEtjYNeox68jUfWZlqZkS
oOjG7MrOhdPcxIo0wRsKDLFsgn8qOjjQ2CbFoBvL8IfdDP+lwhEpP+1aIHR3stM9MHz9sEXer7cU
tx5zqodv7mffBjg/eKj6yZl9G4TWELsy2EZ3odvPf+kuaJCKrhZ+/iPaj9c5oo0W0Gix/ox/9xzL
Nfkn6Gus92L2QyMgPE45ascDDYO2DrV55au7ccbg4FEP7/uV76V4gUmh+KuU74XEykhgNuM8bTgH
Omq1YtDZqC+/w9AAoz5V5jxJ53mH/AlbEsouA3KIcYxJT2WUFcLB4fyEl8LUr69sNmyPdJhadYZx
g6HQlLCrVFnSDewSiOiKcrWURS1oZCkEyI0tphkiO+Xt0uQXMEYgzthQ14RWO3ONRjYbNeA3p/3Q
94aqkZdyqV9NUM4XtgizdMCKI7EEd9TEV7YSW+wqLppKbHasC6+46GJH1a7i23JgUM1OSr14O1Mb
22BLD0TLJzYrOHXp2E4Wht+pIRuaL2p68yqhBqHSm4/TtOPQW5DKoW/AVJ50NY316TtQFMQQVO3W
N4Aqf9uZSvURRXQbBvJZQgeAzRI2YMayhEHs6/M8++7VkeHB426DpOGdJm6n3gUi+YS5wtMmO6wx
x97oQNvu6eTyTvVE+kSi/Jgjb9xeG6zn2Ouka68HB48rj36aKS2I9vD4xZTzjTLY5KQ9TSKl3d/n
3e7oD6NH8Tc0pp51pL3CpBWF6qpHq2XhlZkoBy31NUNNQnORPa6MsumRNulH0lVmDKthLuRPSCa0
my2cHV3q65hD185LgiqnnBmp6sMmv/Nu0QoZTpzKbhhrwWamVGrK4TGUnuHonYG3t08dlQDHoRkS
Z/BY2yxV+so+frUSyiS0KlBMaCEOA45ZMAOBOTQnEWbyZD25LZxoZs6UogpRQ9yXUnSwA0WWXkyy
EaG0MngWhD+XSb5OtjANVkLYZzbRh0NKRqhmQlEEqxchZfZWQr4sU5CGdXZ0Uj02iUbMVmqbYAQQ
8VrT1jmPA/l2FQOL374hkgId4y4GkQKQG8LX4L54ZXY1uTFbiJTfxGahJulpBMJmMtXLwaTjxKOi
YoFV/v6NOctLSVteiqISwFD3jgUZ7N5xphno3rFQw907janY7h3LwAEvpQbgvRQXZsRLkWHk66q3
JQl8ttQmu1+LocGxO1h9VylTppEfn+emFMds8wmvnt6hk43XUONWDoLxVCbTaIuYDI2jvoplbN1T
zjNWdHwVS7QzuIfoAQ3XTzScaBG6xY5e3dVW7LLS2pW+iN+QYYh1rdxqe+EWORg1cdbyek2qhF3U
3J6c0Vc6HTN4/noAszThLQpm8wZHlT7xyoodhcB3eeW1VRdfsIY3N91KmwjqLCnufj2m+xGdyZSU
oplI3MI2Jb8UHnuVZTpK3LSYQ2lT1oVtG6P0jYgpWxGxOyVMQb6RBTpVQX6dCnl/i79+LJt9bbL8
b/iKrpId/0AP3RZktzu8o3nir1ZezPQoRePTaVk6PAPPdUDj+zESlx4tUwoMX47Y1TA7Ean2heSI
GJV6Ob/U6wibOTvRo0nQbcpAhK6f5XTZCYUQE3N3IBuSyv09sePpUyuLtK8uCewwlTXYo3DxmpTE
TvNnSDJcrqzp2mgvgfgFDaFS+oLGh8WH5fzItfKV5Lgzv6xLHWO4x+AblfXuzZaL5QKmibq25uZL
2QBJu1+nKWw2uMp3OB8aaUs7acsqj2zT2x8fKceMWVsaf6p6Y46mRxhTyrv5pUwp8GIlt9xnMOVK
kQvSj686cIeakz0Zd7A421L/1j3H8hnkUmOi5kzu9Epm60IGRjViJKQzIMMhXT3NUEhnoEZCOncq
NqSzDCzvSpbsc0hyIOxtSRfIImsAqTZQK6oLU/xc4Bn3JWX3TgaNFdzg8ZgOWBaxnxAoyk9TgPIX
eJjb1zDQYmCYdyJIU3R6ZNPQU2mF+ASrIgytbFPBdHQhjOfQjarobnng0j0K6FLA6B657etro1rx
JvZzbEgs8VupDGGjwbaR9zMucspuXcCSPPWaH7Op4zc5qWe4EnjTLlvWZBldPJVU9IdUPHQ0x4JX
vDxFPc79wjE3wSoOsPeKIdinHtd/53zKfjLeVNnvAPSgzW6r7/qYogprM6ei1+EA+nNMZisLijYj
SAdNpgUZNJnONAMm00INm8zGVKzJtPwr7zAmneqxA2DvMCadsnADRrVg2vYyFn6iHLVlQbsKRHWz
oDRYc4NHlXGYJMiw9nbD+Vo/HEubWN0bGrmyMZUWAc6a4EgZV7+GfbW88+zr5jotyczgUf3L0Ex1
2Z7bdeAL14rX6YypLskc6xb5L0t73D9h5jnPyytpJ17vTFyLTAX2FTBrGfg+TH/q+0Jq8ENIYC4Y
atgr5NPRST+RHLrVPjMf+Vov4zo0nJsE5H/CkeB73j+R0UZmTo8bDKRml4FSnmPlp33fTMCeocz7
nFfxMHZbobjOTUeaYO6MoaP+EJy3bx4cLLXPfzBANsKYIyb/WkW5p4LvnZqMHMYJwSE/wx6rsGmP
kbWxHLTHFmTQHjvTDNhjCzVsjxtT8fbYMHDAHtcAvD12YcbssYj9qiiJFyg4f151+95prOAGj5vj
CN50va++rGbHSd7uvqJnvMcuFN5ET6RPgE8sOfLGTTRxtL4NxHO0mxC0FDODxzVaP8lkobH0lT8B
L+uOydpQ20uFTmRUdtGmpPxMQvzDgjIF1dfjqmQ6pQgzupCIk8T1dUrKCG6zTVE+POZ3nvmsONp8
2kz8jCanTy7kh6LhZ+XNcyQRBcpGXbDYmYmS+Igl6sOyvFho7js6ezHgBU0lRYdw+jlS5rzgfCGh
GJ6iu8DwzP0M69P9DtwFPeAuXChM8I/oGqcmEygR4TQfu3l2tOcY96v+ojX2yBXUPkdtjfjtHlOz
NF6Z9yusjaTzd9gW03TntEbHZpb6HjNOvN3ld3Tt9ItX3Oc4y3Bj4qUcCgM0cd0PGmdHUzarr9LS
ATNdmKRnSNrz7FT1zFegdncfKm+IyhnlFVqsStDtWbHob44vv16CyU/ebZkqnVph3yGz7nPcllbm
HS23jF23RXXcFgPiui2dNLczTe22qI7bYqAabksnGd6YSvURRXQbBlb3OaM+AFH7Y31t4yMgpUEX
crjd3SGlvDja+TCTg2qgJd5CDbfEN9CpFjoHRjRcP26mAaiu7JQFhXFHK4jGKkPd2WNn9tZ89v+8
Aed7v3ifV/4AHcetd1dFcJvH+lr7ofjDwefOihcBo6g5a4e2/wFq2PWADQplbmRzdHJlYW0NCmVu
ZG9iag0KNDcgMCBvYmoNCjw8L0F1dGhvcihycGhpbGxpcHMpIC9DcmVhdG9yKP7/AE0AaQBjAHIA
bwBzAG8AZgB0AK4AIABXAG8AcgBkACAAMgAwADEAMCkgL0NyZWF0aW9uRGF0ZShEOjIwMTIxMDE2
MTIyNzU0LTA0JzAwJykgL01vZERhdGUoRDoyMDEyMTAxNjEyMjc1NC0wNCcwMCcpIC9Qcm9kdWNl
cij+/wBNAGkAYwByAG8AcwBvAGYAdACuACAAVwBvAHIAZAAgADIAMAAxADApID4+DQplbmRvYmoN
CjU1IDAgb2JqDQo8PC9UeXBlL09ialN0bS9OIDIyMC9GaXJzdCAxOTU3L0ZpbHRlci9GbGF0ZURl
Y29kZS9MZW5ndGggMzA0ND4+DQpzdHJlYW0NCnictVtLjxy3Eb4b8H/gMTkE03yTgGHAiW3YkG0I
kgAfjBzW0kQWvNoR1ivA/vf5vu7iaLxqFnvayWG32Y9ivb4qkkVO9GYyMZloTczGOtwUYzPuqnFh
MmkyrlqTrPFoRmeCxZ0zcaomeVDik4DXeBhNwouUTLZoZpPxl4op6DNVU7IzeTLVBZO9qRmfOWMn
j6cR11JNDsbaEE2e5cDzhCukgTDWo8sMwXyJpuA++GzKhGv1JldjY5xMAX2akikeV0hS0E8G84J+
Mjor4Fd8MAX9lArBQFdBV6HiNEEmi2uMENE4O2WDrp2FGWowzkHBGnGFzjUZR3lqxhUKoisXHN7T
YlRiQkfRgSuUcJHioXdQQu4JfSUKOKGz7Kk5essUFRxd8fwY/ZXKj9FhDfjY0glgC/MYPwV8Y73x
7NXahEZiIxrvLPrBn3e0oXXGezKFDXyY+KSikfgEr6JjA36NdIBDh4ny2IIGTQONfU58BRaFrxxe
FYrqwKICHNZPJkzTRD+hESGG90CIA7knVGhyUAbYB42ABoxofTLBRzasCWGiWysa9J8vJkT41ga8
ipUNsEiRrkaH2ZJpRoMqAythtlhAzwVuswGvamSjAKGwsQ2A9hT5TQXGHTsEai0xhO+iI+iJfW/5
JKBBuEG4GKCTZWSEGWDZxAjlLAAZI40Qif7Aj9Fznl8hQGZXMj4KJUyMIzoFMQJt2PAIKTqF4TLR
y4wgqmIBpeToFMaNo1MQL8nT8pApeToFMZMCIYGISoH2QTAlsCfkGX98gkYmNjLDkAoiclKhGJkR
SQWhUqoUA3hNFUFFV+WJ2IBpMtFk4Y/MPhA0iFX6FN9lRzEQetlTDEZzsHyC+I3UAirlWBliiNwE
01qGaOY38FDOjHpEVC6e4YgsUcgdmuRK7ozLCTC3iKYywRIITUS8Y4xaNKhpZSwDlQ5KFg/AOoRV
oeOYNgodh0BGo/JjNOBCPEHPCTB3CKuSMp8gh2QYgcFdMsMX8II4jHv0Uy0/Bq9KMRjwU+CrgAZj
HwatxIVDDFb24SBKdRQDlNVTDKaFwHwABWqIfIJX0bLh0IAbHWxYkyN35BomBwcv1swE7JhdKAZe
10IxoHYFM2YgNOYUhJAA1PmICZVx6wjdiRBzc4pxgW+ZmRh/jvE1MQCRvpiSmGcQeGhRHD9nJxqK
4EbsLAMBEhUNQ6dPmSIF9scc78KcwClUYH8FmJkDfqpuTolMYKRgqNrZp4xny0h0BIil+92c1njv
mEeQGyqzKFuZ382DgyffwlZhL+w5Jr5lbkyWz9jL7F2OY3Z2byK3zPQe5wQHed2cMmdDJvKolHlO
djAMWoEtYNolDkJMHm7Jm4wrDijwEZ8xGYa5l8IWookKQW4kIj7hqEfFXOVgyeRFYFMZzw4JfR8s
bcp3HFSX5JlIVPmsAlSffXZ4yrF3Ms8Ozw/P393cHV788e54eP5w//7lw1e3x7eHp6+Nn98/MdPn
n3/6yQaSL14+vL+5fXH8/eFv//i7OTz5ydh/m3NHGzu54Ot28/V/iW+4nq9Z+Ma/xDd9ILFC8vSj
78llJuAka77k5VKWS50vQOh8mftZFUrlkK8nKdeTVJXkG7tGY6fr+dh1GA4YuR2M1nGn04QdNKs4
yw1n3/3z9OqPVbq0Std4ffftKhZ8D0NITiOGq0AaMYxdhmnIcBWGI4Z5GCXfrdLNBhcziHA7nLka
BmUaqepWIyFXVdUyTgirqi7irArqR4I2OfOf6ZwuaLhg+IhyjIJdHHOX48A2SzouaUy/CgCn06yn
J7+DUdhBE3fQpB00eQdN2UFTd9DYdQRvHHSuIhpgYZVIpAvTVcObTqQB9Soav4Mm7KCJO2jSDpq8
g6bscVDdwciuQ4HFnQ1I/Yiq5csXX66TXaToj2jjFphfzTEpHEez7IUA02zrL6iaPV88W+e45HbR
Z66F9SWoqs7rqGZ5TNXZTX2ObtMs8WqOTtGxbLZyusLKy6JF9Jlrhz0JzgHw4ubn2+N6b058VRTL
Rc0GQuMe0eQtWfgxkcpoLoF+ELJH2zW2a8a+IAq6rV0SGy/LRlZcuwJ4p2nsOkRW19h7hWHQGPqd
DKPC0G41cdhuYi8AXLSZy9N9AYqmcewQ5YHGtc8wTBrDtI9hsIqGeauJ8xUmXqodos1cy+9rrIKq
dIj8QGMFVCFpDOseIttJL0MxJcqDkmbOfYzTzBV5Jgj4g+SboGBy26T4I6pJ1z0qmIj6jKiTaQZU
YRdVJ8YHVJ1AHVDlnZYUX0aZBUnl0Urp0UYFXee+x+gq29EVZaYgpVAbFXSlTeWXj6gGNkkKupLq
BdeJ5SHHoHDcbGV3RQwnsXISKycl6SV1duQ6MZzSQGcFWUmdb7tODA+oOjE8oOrE8Ei7LKNXFjtn
DVNps4fTFR6WCE4yA8/K5CyrazrXyS3nInHPBsrkKOuY6gzdQ44Kps60YyvX7VbOkjezWDsr2aro
5ZRO7iiD3FEUZBU1W3m7k6OSrcrmbOXddisXiSKpx/JwQU+CDatIJz7z0qtvM6k24kjspnaVMVF2
A2xR1lVFnfQ3F8driGyHaDBxLxL39XIC/6iPumkVeCXj6vsMy3DFEBs8LojSAB2yYqiyOKtB0Vid
i4c9RHEPUdpDlPcQlQ7RoHpRJShqM+4CJx6xWa59WPFkjSJQ3UNkO6EzUINnMBZxNUwMizENlJer
pBEqF680veZTRn2DqaOhXQ/EEZXvUOkzF559WuStfXmtWmmw62E05Gw1SA3nSGcfxc0+Egs2feaj
XH2d1VqDXQ9oZ/VVvLMKKqxeN1jPBmOOWeE4rBecrVy2W3mxXNNnPvrWlcDpyOrkjnN9vqOzU5Dl
9DFwPe+MOfYHwQ+0Qyu77flGLNf0mY8K9nVWkeU6+WZA1ck3A6pOrhgU153UuJ2TbOWUbOVVTLn1
8XsogdcwtXlEuVzRDT0s8ePF017JVnq53XVyhx/kDq9kK6/7eX0aMuaoZCu/OVtdruhGVpbSvugz
n3btSqBX3H0nd/hB7ggKsoKarfz6WmFE1Yn3AVUn3gdUnXgf2kTmcVJ7dgv9fIq4j4/NedZfMWeQ
fQnRcz6z3PeWWlvynTnDgKoTu0Hf+3WyqnVRQVfUfdeJ4SFnZSwMw13ns4+uiOEgi5UoPorKWBj1
FWEnhuNgdIgKKqK63A+dGB5yVEbAM+3QysFtt7LsFYg+89n5rgRJRVbo5JKk7/+6pCArqSNg6OSh
IUdlBEzDHeezla/IN0kwnCTzpX7G21D7Km1ZL/lzanNyya9yXkNmMG2Mbbm0xWtDVNNZl2bdAevJ
b0C0nvvOSeTpzf3DaolmsaGYUvY8xKCLR40U+aRqvmxOGKmdSzFfavlLkVmO48rRUyM1KCm61YVg
Kb0ZqUstdTGzVKeMOECqBFJtkWKL1FrsJAVKKSFYKWbYSQqRkxQyxYlWlrNWlvB2kn5keSuHdVq5
tUFv/mnKcpWpjhj2wpAv7o/HZ6fTw+HZ6fb4/c07I2MUDH68m98a2Q2ktc+YOL/94fj7w5PjH6bh
/mv0dXd6OB5+4L+v7l59uOGPLn4+/X54fnz5cPjmePPqeL+0SdPa397dvrk7Pv/lhhLywRd36OHm
4c3pTu7vH9785waN+e7H0/2vP59Ovx6+PL18/xYyzU9+++V4fFgw8/3Ny/vTxf2/fsH/i/sv39zc
nl5fPHh+++bV8eLbhQ8+e31/8/bw9ZvX7++PousP79/+9hMs0rZaTZHYmX/Jw5aff8nDVph/yXN2
wvU/CPnLGF/oZFtDdjUE8e2EOeVa9gDkZPX/FP1L//+3EBA6qUXIqb92Fq+dkPtwTo2yyEmudqCq
nXNqx4/aKaB2OKedmWlHV9qJksdHNtrBiXacYetmfNsSbxvVbfu4beK2rdXeJmTbCmwbdG3brG1e
tS2lttHzYbtlNsaf9xVaub9V3bcWjh9XZlt99HH9sVUFW22uVcxaHatVk1qNp1VeWv2jVylo6/e2
im5r27bibOu+thobrUDaOuDxPLvNftsctM0M23ytzZraXKbNMNo4/3Fy/vST/wL+zoMcDQplbmRz
dHJlYW0NCmVuZG9iag0KMjY5IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDI5
MD4+DQpzdHJlYW0NCnichVLNaoQwGLznKXLcHhYTa3cVRGjdLnjoD7V9gJh82kCNIcaDb9+YWEv3
0A0oDPPjMDEqq1OlpMXRqxl4DRa3UgkD4zAZDriBTipEEywktyvyb94zjSJnrufRQl+pdkB5jqM3
R47WzHh3L4YGblD0YgQYqTq8+yhrh+tJ6y/oQVlMUFFgAa0LemL6mfWAI2/bV8Lx0s575/lVvM8a
cOwxDWX4IGDUjINhqgOUE3cKnJ/dKRAoccHfBVfT8k9mvPrWqQmJSbEgSjxKTh6lgTvQgA4BJQE9
BJT5r6x59Cd9K5M+ell6DupyVQeeXpbJEi87xv+HZqFJlgZ1ciU0ND3+aboss1zgNjufjHGL+1v2
Uy8jSwXbj6AHvbiW5xuSXatfDQplbmRzdHJlYW0NCmVuZG9iag0KMjcwIDAgb2JqDQo8PC9GaWx0
ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDk3NzAyL0xlbmd0aDEgMjA2MzQwPj4NCnN0cmVhbQ0KeJzs
fQl8G9W197mzSJYty5JteZOXkRU7TmRbtuXdjq14SWKcQBYHrCzFiiTbSmTLSHJCKIXQEJIaSimF
JCUtUCjklXXM9iWU0kBpgX5NX1soZQtbgVJKWqBlKQT7O/fOSHaC29Ly3u/19z3d8Vz977nbuf+z
zNjEBggAZGAlQFXXmp6lxR/ZvMAbLgPIPndpV/cS87elMoBt5wOIZy5decaaN98z2QDOfxK4otKl
a9Z2LL7L+ypwB04AhK84Y42jZtU3nkwCIIdw1QHviGdszQV/Xg9gywfgrvVujUrBd1d/E6DuZ9i+
fnBsaOTLZocToOQBAP2KIU9kDPIB198WxPnGoeD2wTpN4eMAjdg2XDXs9/he7lx8G67fiv31wyhI
Oqh9CdtRbM8bHome2/K4iPtzOQBWYYs/PJoSMQQAPFdg/0Qw5PW0X97aB7AUm3mXj3jOHTMO6h/C
+ftRII16RvxX3WpdAbAJ9TVXjIUi0ent1xhQn+W0fyzsH3tid5YdoEYPwP8AKHfiez8648bIO2en
tb4HKbg1lsOv719EPx9dMrzngwWf/Fj3aJIHONDhrRScp71mqglA99MPFpzYq3sUopA7vQ/ihW+l
Y1KXQCfahRYOjOCAQQQ36VcoQ4SzyBUgQpJ4jYgMwreUT/IBDJIpLo0TRF4UNMmc8BJw0y4Qzo6t
vWKNJNHVJaOmaaqJeLTXkEdRcB1b9AFxLT0p8GIXPMhU/ZFy/7NFcyaU/fOzEuXfsQh10BfH1TM4
Vjg7nBXHxbBC45tpxwrfoci4H8EFwjLYxd8By+J9d0wL//VaJ0qiJEqi/P9VuK/StwD8bPt0jk2U
REmUREmUz174ApL/P61DoiRKoiRKoiRKoiRKoiRKoiRKoiRKoiRKoiRKovyPFI79Gw+ATOAp4gA0
5C0meUftmSkExyj/woP/B6sqM3nyBt88Z/fr/7rCrBg/47idrL4k3r6U1ZfD1+KSq/DeC/tgP2sd
+Jx6/feXf8T8P1cEuBbrYpAQUcvqIBVbFbACPOCDAIxAGLbCdrgebpeM09NsDh0jzRoTxDHRWWPI
9EfT76OND0//CNeadU17SdPLT8W96u/9VFr1HJfbf/YXNm5Yv87dv7Zv9Yrlvaf1LFu6pKuzY7Gr
vW1Ra0tzU2NDfV2ts6a6ylFZUW5fuKBsfmnJPFuxVSoqLMi35OXmZGeZMzPSTcY0Q6o+JVmXpNWI
As8RKCc5ck5nf/dmObdzQNbbumxGSdaf/vYKhwzpFqvNJDkd7gp1lCzaZcjolTNX9k+Cq9Eta+yn
Djld5kuM71px8gqL1C0LJfhlO83jk8tW91ttxqcs8X43zpHzOvutVovMleBXD3bh12keyScbV6Lc
alEkPTKs7Kf3oelXGlEIjVY31qv75cJY0+2eS8nDANNHTlHzdDJhnNTndnbJkDkJ+ldkMNNhbzeC
DK1ymR0VMSJiq4FDJpnvyiRDJuYVqPLJW9BpLzXOwUG3b7Ot2xdARn0DM5y+rTBqlSakidX9JidC
pnSv/Niq/smU5E5bpz8ZBcAEMJmcgpIUKsAlxiaJvo0wwOm7myc5SEpF+tKput303iy7Lh1AYOtC
3rAnY6bn0PSRy2Z3AU6LoQwFKUrImk5ZqyghBWSXR4ZLpcnyIxOXHTLCpgG73mfzeTb0y7wHB0wC
X9I93Cfn965chyLcCu+BYYmau4tV1HhS97A0gW06dgBrWxc1+kly37B/gLoJGbB1YZ+us3+39YhF
TsfPbtlkl1NxWOp5r1r4ie6cgESbExO7Jfl6VHdWr5XW6AQ5qPpEtw13w8W6N3dQkzjiZmPe2ONj
xnFd6pHkHZs2K77nuSzm/9YJo6x/34rWQfvgTDZRpdI3sJmqvNlDj9m9WZq41M+Oehk7Gvqr1L25
i950Ino/rMXZ6/q7h23dMxviwRHwJafOtVrlXDudODHRTVX0+FB7RWXsmNGfxoTFTlCfTtnVxz6g
j9kAd3R5utyqSB2wjk6jPQNdbrdVsTsOlbUlu8VKmzRBV9SWyJl2o/UR7DtSUd67ur+7y8JOL3Od
/YuO51iOI+5dGReTHBwz4ThuUTjqXWPrXaV4wXCsGuhTApiLWx6HquPZqkdzLEcVvKF/iW3JwMTE
Epu0ZGJgwnNoescmm2S0TUzq9RNj3QMSC3+C8vsvtchLLnPLxoFh0swsRJeTqO8tWd0rZ6xaT021
RBr2KImj3WZttFhN8TEr/1a3GnPo/RgDNOYmjG+hbnrMThZpCU01hzBDWGRjIw1ZVGhtP8aEl/kv
qzBW1uDiFho1vLukO7BGJQs9U3UemgNXqVJcxGql8XTpIRdswoa8Y1W/0pZgk+UucDnsaMcB2nMk
1mNeS3t2xHri0wdsaLec3jX/wL9n+/aEyZYuNTkY/yz1+uQjfXjGDxvlpEbV9Bmd/byFUxFn4SlK
tmMqa5Wz7Wwi5QQz5oTRJv3CJhvtstjZf8TS6paMJkx1BMcss9MIwoz6C9vjhOZRyDTKpFUmWVQO
mFdZeuezG7Ez7khS98SA6mmzj6U+DHzDc58NxxhteDyLMt6UbqMn/BlLb2rWLllC48piVUac5pYN
NDfLhrdYhfpaOvslzEQYuasYkLqlYWpsWRroYinBbZktPjT90kAXTYGoMh1iUV0ca4Xak32tovyz
OvoOdPSLLnMPN+MqroV4AqkOt2XR0tevstRoUSOK7tVDj3Jyf5zF2Bg0PgaeVa7KezwHHTUv57h7
Lsp7+05qzdqM9TXGM0Nfv7zEHltcaS+1W2Y3l53S3RPrxvTxJct59DHCQcekjexZNekie9as6z9s
BJD29PXfxRGuc6DDPTkP+/oPS/gOxKQclVIhbUi0Ab0EV7uLS2LjLYddADtYr8AErO09RIDJkmIy
At5DnCIzxmQcygRF5mIy5a2iO2cYKei3odF9smtl//nu4YkBNyUbshQHRM+2tYHM2domCafRy8k2
f4ecYuug8nYqb1fkGirX2jrQ/TE4JBrqEwM2DH9MwP1gIW7qwtRduBLp0PQ0ZtCjmHmtsqZkA96Y
YHV2t4RefBqOW0rvARQvlXd4PVQP6qY8zeU9XrecFF8Qh/TIOlxBp66AI5awOfQpgJO86KweG4Mo
xuDY4Zbddrppf4AuIEn4PrTM1ixrSpU1xVK6kcM9kW6rYY8TTYmcXLKbfuhQN5oImcSCTdzMrZCk
1aPmXht2eQckZFsA7xp0RqGUfiVbFIkfn+pCqZ/dyRa1E5QISklNlnWV9FmlZTilEhfEL63brSjP
WrvVAbi3UU5BjUpnUalOQHawq4fqgl+7UVU69CG6zKpDsNp2LsYgVZqtpMVuObWkx4MJR5mfghJb
Y2wyrpXERHSNRxSplp5cz15o+w5NH7Rtt84qFeU2fDr3U8cEC75DusA9capAXo+JM+lUaSoTT0wk
pc49QeErKTX+SYUg4dMECdSU9ngubUyvrcBJrlUvvpSVnf/kr7H64vlZli+en/vLXyHeug2rkTGs
giGstoxmWbaMXhjOi45nmvOHNmM1GMDKP5xp8Q/vOicvN5J1XmeudTve+Cy4+0ChtQk/XVnfkmxN
0lN6Q9PTDxJJTkltcv24vBq7jtx9d0YGG1L8tqWg6eOvc/auD/d8fc87+7++/x3x0DtE583xPurl
JW9qGh1299KiEjZ8wf7ikqaGa8neqzl7zr4FC5uy9xHj1e2upmeuJsff5OyuNzOzm1yPZWbSTVy2
SdzlK7tE+44LOftFFxL7BReK9hM7Ofslu3j70xeSC3eVFC3OIyvIcqiBItJNuthnA6lnn52kg30u
Iq3ss520sc9a4nS1EPueXcS+G++LcYOdeCft0jVAp6taZ2yyNJhz6s3mOnN6rTnNadbXmHXVZk2V
mXeYodK82E60JAnSiEg0YCA8ERATwoEB2gnBm8dbBBd+0h4Rv3fUghFvCbGEn1XYU4W4CrEL7xdx
VjJJdQU726yl8w1l89PSFlaVcQvthnJ7WrHNMM+WVlhkkIrSQDSKXJrRpNclp+g12iQ9L4h6IJxe
w/uKCqGsKCWtN41LgRbo4qP8rfBcmiYFUviUtBZo0bn59bqt/AE4oPtm2jOgP0wMJM2VnmYhBak5
2rxUszE7NV3ITIXFOmIAB6GHMcDX8BaQr9LW8taFrWWtpa3zWotbpdbCVktrTqu5Nb01rVXXqmnl
W6F1pbOPyOm90NvXIWcQ/FzTITvtvYd4abVcY++VdSvX908ScrkbpTK3B3N5nyzswfTdh98lrFvf
f4jk0u5dGApIiNw7sOurbru9QPbRd4cdBW65hoIrCtz4llezSrbYOuyfKhGljo6f1LZH5IXdcnm3
Ry7rHpBLbV1szClTyUmtWb0QpS0qiKqTlFXlHLkdz3iqCpM6etiVqzvoK3Gv7MMX2sKV6wfkPFsH
vp1iq37lenzR6cD4Fb8KyWAX14IR6w2gAxCyKVZ/aPCAgqffnv42rRUMMLWaYnEviIg+jv2IQfMl
MPKLpt/mXgLj9PXTfwETE9Pfu4KpL53844ip8RhKUm/26xwdcDN8HejYjTAGZ+An/d2i8r//Ixcs
D//DEXOVH8Bh/Fadlkm4FW5iP7kBuB1Xu2fWKLf6eQb0wbmwDq5HnQZhACXnQE981ACOq8YL8E6O
Sx+EN+B7GH1vkpfn2H832/lhuA6Wgx/axHfFd+Eq1OQ66IWdyMNM+Tmrn+Y8MMTQBaesNAT0N7yW
oUaUr4tRSxmuwDV3wzjsxfZuCCOrx+AIBOEbcAD1/yHcABfBlXBAcx+z2p/FSUjlmtGaSWiFrdAx
9fTUw9TW/2KpAiuU4vPkDORlA/J2P0TED0GnLcVsgF4lmCGTeh36ULLmfDAJq6b/Ku6b/iv1L+pd
fMf0H4SV0x+hWzyIvnGJ2Adl6AdVUAseV0ZmpqFYozFAud1eZcjJqap1OTCIXZYqcBqdnLMgpQxg
oT0jsybTnsI7Kyrqq5yOo+lNjvTspqMOvJpoBY6NR/OO5VH5UVOT49jPTU0mJzaqq0hdbRvX0MbX
1Zbaig2c1lZXX++sKeTMmdgw8GZzttlWR0xWE725Bk3WwnnZpZa0xW1S1bxc3UDrVzqXeNvy0+a1
lkulZm36FeTEJxrec6KR/C4rq2Rh3fxch7PJ1rs6c15N4ZcLKwucSxaUti1aUmEtn1+Wrxn9znem
XhWu+XhQ+OCj2/DY+IKJp9HsRrYWwbP4+te5tt91umQtsrZaiwoXLTLXJGl1Gl1udhaY8zS6PFSv
vYb+xK7UilctX7OosMilS19WVFTBkeaWluabu3KtLbzBaLILFZUVlTd3VaRDTrvdlA7ZTTntTidF
TU3pTTkOu9NZRRzZTuPuI1hM6aQJGwxTCWs7nSbaXW1x2T7fPm5iRWq1vEZjzszK1lqR/oaM+gab
RqMlNp63aU7tqkfrzG+wZojLSUtKqdViMd+amlRRlzI1llJampeVtSuvzFDQ1DjVNDJgySwtHTAl
084blM5bkvVVNSnEHxbXVidllq0dOPFhS3d+RYlQXa2xVHV7ufXb9tR7N35i4v5IUj++Y2r58tOk
mV6es59e5ijhq0/U46t+3/Q7/Av8UbCAE76l2sdRlKqHlHyOz+dTUuoW7HRlcMQIxbnFfPHVrlxj
qr7cWM6X73MZs5J1B7uSzZQYvPOO203gdMYAsoT85x1Pj/OOPBf+qyu5SUP2DIfzNRp0EXR03lmT
xTM20dcF7HXW1Nc34BffscH1TUNy5WLd1CvtqQO3DYxuL3eff+NA21i+TtOxYuHy05c2S02dRZ2r
ax0N6fylHcZP3K2LzQtKxOqPhcu+fPPegYduv/j0gqnJBa2205da2gevPHjG8FB+b0/nTjcovAnL
MP7n4cvCfSpvzS0l88yZGQDJKXxGxqLqnS78PkHPW5JJkvZgVxLMW2hdyC+82mU1mjNrc2r52n2u
nKx008Gu9L95cCpEFs/+wsbZRDKP/byrugnjDd2wwUnmZjabn4vZwSR91oI6/cctU5/MQfCiofpl
aZ8iWDjfurIQX8L4Wt3HO9rbTuU5t2jqZ8tcc/F8FlZVYhfwkANXqTxX5eAro2DgUnngBT6V87rG
eJLGv8hzafzZPKfj+ZxbsrLMB7uy0vQpB7v0MR7wNr5GuTwH2WS5YbeSDJDO4n9xFTfR2hoUx6T8
ZcxwylVVTlYuSdFkLqzSTf10X2qyqaw65S8tYtfDD398n9NhLCxOF6u5G5q7swskI1eno7kSn4Nc
LXqVGU5Tz5qBb6d8CiHmzINdZjgpSlTfyHai+oa/PcJNVPNS/Ugbp+hH/toydYIplzT1GOGSkwRq
U3Hvx76qahNTTTi/vLwsjdkMNUM7iC/yP8On6wOqZu0Sb8XHpLWULy6u0ulz+MzMrqpWR4vDUdvC
V/Gti3iLZoHLtYBfsM/lMjbf0tTUeLCrKa2qOCMj/WBXBtNRcUvGKHNOmlOza6pIjpK31aTNHD9m
p8+1sBtZ0tLHYRZ+8icbjT0sedscDWZOPpvN439Izrptw9nezD4TM+xPLjCYa+rnezZ3Zq6/PYLf
7dSXeYKL09ffvl80mRZU619t7NBvuG/jgI/70KBN+uLWLQHXuqlvLVvIKCYnGs6pXLbIdfFFG6d6
yYmNbmnZosV7dq6bOoO7NXtdYX5RGl+nm/pE+MquEVBswF+ANsiHu1Qb5Cbf5NLpkpIy07kMglc2
nwm35Bv51NRD02+48jOzl4HOqOMyeZ1mhyaVT3VpjPmWg135aZmUJSU5HLVDXo7xKDq03eR0Gl+L
PzRNxOlwYgKvttz3+RdFL9QyBrO1ttIZelVnvLx1if7sewd6qquGkornzR/cXGdABs3pZVUp/I/f
F3ZekPJSbf3Ky7Yuo8x8oZoRQxm5AN+1DMLdUBj3yjbRYrZw71kIQFZGRpI5PcuUZUzS6UxZfFKa
CbOxKd2lw3DWmf+I37yBq7hkGUiFPG/hLftcfJaSLdFtnszLPWrHxiePxE+iJIwYM+iUsPGc6irM
xJ9z3Sp3iZp0GzJs9PXAqbVqrcw7Mec2cDeuvn7d5uH0869Oael2lBVONJBFWVMPD5TVOSv9rYe8
/uBQ++mc1qktWbTpCx/4p86/YeWi9qXLkJ1dyM47+L66EMZVdublpuYYDGkZfE5OORHn8ZIBXzUP
dkFaXm5SUkFWdtbBruxY8sB3IycCY84jzCNiTx+MwczPNsudYVUSo7MGX0gznJ9+fNfH3oS+SVou
NJira+2+MRY7GqPDlTL1iivVc+8Gjy8luS9ZW9XGPzDFN4Yql7Z1fvWCs8hdn6y19OcvtAn4HJnY
tSVQuKqceMtr0yvm0R8YwDI8+0N49hzwq2cvwgSVl5xkNBl1RhOfnG1IMxzsyknJJEJamkmXRE2E
qmc7ae44OQPRBGv6++PdJNsgam18JUff6urT2esdf7OlZH7nms27139po85cZsc0vvy2m8uqkvkH
atxnXnT5DQ+fy/25p70AX8VeO066/I5iHr8FI9PCVA/TfT68req+JmO+EXToZTrdgvmFN7kKCvI1
2vz5AlhzTFnLOGu6lcsWMrTzs/SiKBzsSk0jOkFMSysoKnAU3Fnww4L/LNDo+YJcV66VT7OSUt7q
ys1nYUoDNOaH6lnosaiYWZ0lABPaHiVoWiSi5b9zS3eGQiAor8fZGo7TarQGDr1lfoMzi3oS33A4
Ob2sgnJJViOXhLPU3fSnK8eWt3g31lq6cuynk8ICqdLZs6GJe2V5SxEll/z8McptzaVTT01d+8Nv
9Da15Kbovl9cllrYMbKCessgeYhr5TbgW0a+y8ATjvDkoxc5cj1HOPxGa+NxO/oD/dbK2mDlLFO9
VnIveeiA+nayAr+34UEL1a5c8gjH8RpBBFGrwXcTkdfwPKeVNenQ/slP2qviCYR51fFqQmwZPL4+
cCum3vV+t9H5oFNce6KXv/fjb7zxBi5M8vlH+DFxH1u93GXW3iloOP5OcHH4gdc9R7R8IbQ/QhOL
EqV5x44bnzyGC2NqteLNzf/O5uVc0vWbl4v7pirIE/TG724v+vsXWfm/4nqLXtz1sYvPZpdPKI1f
dwp3im3iA5o8dj2RuBLXv931J82ftIWJK3H9m1+nJa7ElbgSV+JKXIkrcSWuxJW4ElfiSlyJK3El
rsSVuP63XexfW9LfAL4E60wYAAFy4Guwf/oFrA9gfRXsnH4L60tYffk0/Tem+6EQ6wO0Jq9PvwJ7
ccy7WF/C6sun38aajtnLxuzFMU9je+f0+1hfwmq6zgEmOcAkB5iEFgcX+w31VG5//N+DGiDIWspv
W/t4QcUEDPywijnQJ8fG8NCWHFaxAPnJe1QsQk6yrGINyh9TsRY+Sn5VxUmwMGWdinWwJOUFFSdr
k+N7pcCZ+nkq1kOZ/jwVx3Tm4zrHfru6Rn+Diglo9U+qmAONMRj77XwoMrpVLIDB6FOxCHrjuSrW
oPxiFWvhS8YrVZwEZuNRFevAZkpTcTK/K75XCthNNSrWQ6Zpo4pTyXLTOSo2QH36D+hfHhB0Ks8K
VnhWsMKzghWeFazwrGCFZwUrPCtY4VnBCs8KVnhWsMKzghWeFazwrOBU1RsoVnh2QwjGQYIR8MB2
/ByHCPjxMwrDEEAswSCOGMW2hCNoewz7wzg+gLIoYh/KNrG5dA6d2w1rYTksVueGZ/WMYSuEM8bB
y1YM4MoSbGN7ebGee1+lTcd6IYhzfequURwhsd/dj+DKQfUEHhznU/cKqCt41bX8rK5Eyannpv1B
hspw1gL89GPfpvhOc2k1+qmVPztHM6v72EpDKAtjO4IjwoyNKNZ07bnPruz+ab1aZjFAT6KcJcr2
G2PW8LD1lbP6ULKNnTzE/grC3CdVePacxKmf2TWk1sqpFDyOrTFWS0zbrew0/vg6dGQQR/x9Cw0z
5sagGRx4bWNXJWPUy3wogvcgG0lnjuAY+rcb6AmH2BnHcIXt7P/EoqwbQUy1GcS+cdyfzvQwvzkX
vof710AVXk2IVnxqDwk62Ulj/MUsQ/1oMa4VxM/VKBtiWkdYy8/iiP7VCWqvSlzBwyxOT+xhLCie
Qn3Az2zpY3PoKqOqjQfj/I5CBfZ5mYcooynyzPKdmM0Vjqk9Q7AF0RBDPjXKlLmzrehjc+kZIywW
lNNQPc5j+tAz9rD+mMZb2bm2Mx/eqq5IefSgfqdqo8S7wtuMP9M1uxgPQ0ziYXvG5ijrR5kVlB66
cwBlQba+n2kRG62wHECuFGmYeVqY+Zhiqa0Mb2djo0wfqmN5PO8E2YxhpiM9teIvHpWHuVafzVRM
j0Dce2esoMScwpvC54wOW9QsMBq3YYTp7ZkVS1E2d1SdFdsppMaWMm6E6Rhkp1SY7YtHcMzO1C5j
6jmVnhHm3XSVURa9SoR60Btjo0ZhJlcFVD7oqEjck8Lx54Rf9bhtTOpl5/WzmB5mnHlYNqN9J7M4
jvvRZ8HsjBZhcRyclS82MeyZdeYAY2eTmi1jOdfPZo2oGSTCmBpk2lLL+jCCAsxuQ3GmzopHxKnR
qbCkPAtnR6KXZZbZmTkWO7F4obtuVe1Hc4rEvF/xjvJZfM14TBg1+zRTn46pCPNRmrt8cVYizCpK
3lF8PMw0Hmf2nK35DFvKU0bJgTMe4z8lAykcjMJ8Nmcz4yIKJ/v5qTuMs9lKhEbUp4sXpTM2aZ61
G9VjiOnhYfO3McsqZ5krP/oxU5+88zbmmcPqs0lZZ0jlxc9WUTxgRI2q2VmD8upnsaGM387sH8JV
TuZkqZpzt8ya3YmjlWeoEhOfLZuPq5orfhRkERiLgzH1WRFgc0JsBUV3j2qLmK+Mznr+KDkqyiJ3
JD6D8jSm5tBIPM8pT/AAs8VMhorxpDyRAszGIfX9Q1mdar/tpAzkYdEUi9cR1ZMC8SdUgEWIpD6P
T/Wryjmer81zRGDPrJzTDLHncx2cqeaRGEt1uGIT1J8yv+Kk+XNHt1/1HsUinrhHKiz41UiSWL72
sDOMsLNvgdh7j+dv9lI7fPb3iFPz7VpsBeJP5zXsJNGTnnuOOd68vCw7jKrvj0qOW8HWD82yRY+a
A099UvexrBpiSBmr5M0tLO/817yL0dw28z4296oz/epq35NqqqqapBUBbzgUCQ1Gpc5QeCwU9kQD
odFKaXEwKK0ODA1HI9Jqf8Qf3ur3VXZ6RjaFAx5p2BORNvn9o5LPHwkMjfp90mAoLIVGKyLeMBWH
/R5fYHRI8oz6pGhICoZCW6ShUMgnbRvG3rFwYDSKczxRKTLiwW0igfP8kUqpJ8oW3uoPb5f8W3Fg
ZMzjjS0zFg6hblQ1HNkV8AyFRj1B1oPjowEvNoY9gXAwMOqPMDGqHBhEGPajOkE81FZ/cLsUiYZD
o0PlqEgg6JeGQ+HAeaHRKE6eNVxRiq5B9VSO4B8ZQ91QT7bCFr+EclQtIiFdw/6wFB32oL5ROik0
HsWmfyTiD26lx+obDkTYmb2BMdwTGyOhSFQaDaHWfs8mKhqlE6QA6hHwRihJqAWVBEPb/GGvJ+KX
vMOesMcb9YdVFcc3+cb9VEHcdDsugSpu8lNGcVogjBh3QC79Qf+IfxRNGBqUtoXCvorAiGeIKnUW
NUTMnKjSeEQ1otczxkhm1qF2kUJIMHqKNBZCOsqZXoyYcEVcqbilIsOh8aCPqhIJUt9BxsN+37hX
XZypFfZHxoNRRoxfdSDUYHR+VNo8jt0K57EJ4xFq0IjkC3nH2Uma2bSwf2g86AlL2/x0lxl/9J+r
Tt4WiA5LHgnHDKEu/iglYMRDZdQ1vAH/qBfl20c2hYKqJkvRc7ew7s7t4UAQLTGHm4/j4shRMBSh
NhjDqAhEkC26OtqfsTLK4gc9Kur3jNAO/7k4LhqhPheSPIERP3MoqhMGUiASRR+k3jvq36Y4kCfM
7DqCJAVoQAXG0Krbx2JcVcbjtTluwB7mOc00nuvORB+hKtVVNtWr/RVK/yxz+wPMaz2USFQB/Q2V
Cnt8/hFPeIsUoj2zmoNz54iY364dDdBwXhP1RJXYc9BkwDbwhsZHo+EAetyKEDo8PUUPemAsqPsC
4ZDUh1L0zS2R4Wh0rNnh2LZtW+VIbL9Kb2jEgfNCQ2HP2PB2hzc6iPE6eyhr02Hu0DiaeDt1ZVQL
D0l7aBAg/SOBKFVx03amcPfa5YuZe9EGJhZ0UOp3NCl4h2fNxU+M2uC4TzGZLxAZC+IGSjpCY+Px
qLNGK6XY3qFR9PiywALMF5vopJmlRmOD59SIDWcpE6MDCfMqMRjfnTGtrtXCFCgL4C5RTEtoDHTX
7Rgh20aDIc/sTVFnj5ptw1LcJpifxjBF+fxbMf/QMcP+4NgpB/ospmDEO3z+QQ96aqUnMnau+nPG
6T9/85rpnRCd8/fo6V8I1UEyZIB2ehqUnwrqUVxISoHDtwsg1wIh15FbgSO3kTsRy2QSeHIXuRvx
PeRexPeR/4P4EDmM+H7yfcQPkB8gfpAcQfwQeRjxj8gjiH9MfoL4UfIY4sfJTxH/X/IzxEfJzxH/
J/kF4l+SXyF+gjyJ+NfkKcS/IU8jfoY8i/g58hzi58nziI+RY4hfIC8hfpnbBYS7hLsEeG43txvx
Hm4P4q/w1UD4Gt4JPF/LP4X4N/xbiI8LNwARbhT+DLzwF+EviN8TO4AXO7VfB6K9Uns/8Nrv61Ef
/S/1uJf+WGo3ciOoPwvn4C7kQcbdJ5ENDnm4B/G9yAaHPBxCfBjZ4JCHBxD/ANngkIeHED+MbHDI
w48R/wTZ4JCHxxH/FNngkIejiH+ObHDIwy8R/wrZ4JCHXyN+CtngkIdnED+LbHAqDy+QF7F+CXlQ
GFDOTk9dg7UTz87xz/LPIn6Ofw7x8/zziI/xxxC/wL+A+EX+RcQv8bgC/zL/MuJX+FcQ/5b/LeJX
+VcRv8a/hvh1/nXEv+N/h/gN/g3Ev+d/j/hN/k3Ef+D/gPgtyjByeyOy+l3hu8AJNwk3Ib5ZuBnx
QeEg4v8Q/gPx94TvIb5FuAXxrcKtiG8TbkN8u3A74juEOxDLgoz1pDCJkruEuxDfLaDvCfcI9yC+
VziEex0WDqPkfuF+lHxfQF8SnhGQGeGYgB4ivCC8gPIXhRcRv0T/58PCy8LLiF8RXkH8W+G3iF8V
XkX8mvAa4teF1xH/Tvgd4jeENxD/XvgDrvaW8BZKjgvHUfJH4Y+I/yT8CfHbwtuI3xHeQfwu86j3
hPdQ8r7wPko+ED5A/KHwIeK/Cn9F/JHwEeKPhSkcOS1MAxFBRJ8SiUgQcyKHmBcF9EYsKNGIGpSk
i+mIM8QMxJliJmKzaEacJWYhzhazEeeIOYhzxVzEeWIeYotoQZwv5iMuEAsQF4qFiIvEIsSSKCG2
ilbExWIxYptoQzxPnIe4RCxBXCqWIp4vzkdcJpYhXiAuQLxQXIjYLtoRl4vliCvECsSVYiVih+hA
XCVW4SmqRYxBsUasQYlTdCKuFWsR14l1iOvFesQNYgPiRrERcZPYhLhZbEbcIrYgbhVbES8SFyFu
E9sQt4vtuLJLdKFksbgYJR00fjFyr8T4vUp7FdZ7tXux3q/dj/U12gNYf1v7bayv016H9Xe038H6
Ri16qfYmLfqn9qD2Nqzv0KIvae+nGQBjH2NQ/ys9xqD+Cf0TiJ/UP4n413qMR/1TeoxH/W/0v0H8
tP5pxM/oMTb1z+oxNvXP6TFT6Z/H7MGpWSMZ9nKvAu/dHg5C5lDYvwXq8UV4FJZgD1mzukOCLMzW
0+p/bzKomEAS5mX252tYm/5fu404ku9ZuXIZFK8+Y4UElX2reyX8/kIZweN6JhULkALpKhYxs2eo
WAOpkAlm+v8jhx2svoTVl7H6SlbvZ/W1rP4uffWAW1j9PK2JgdUuVodZzcaQp0a2jGzhklidzup8
Vpf+P/bOPi6qau37a4aZvYdBRMt8S9BMjUqwzMyKsswwXzJRtBIzNPEF3wpRUBENzaaOL4UKimRg
NpqYYSc73bsXrEZTs9GjeR/qiCeHVLIdCNpopq77u/cMBun9PPd5nj+ef57P+nxZe++11rX2Xnut
37WuDZn58w7z533mz75CXPmN1//+Zytyq/lEdu5eZVQMvxXGM4UzVhGMSXOe9HrjqRidVv+/xb/V
wvjXG9qItv9XRzeKXmKUmCKyxBJRKLaIT8Q+cUTo4qKliaWdpaslzjLIMsoyxZJlWWIpZDfxiWUf
HkwXxm/6QozfOIp25n0Lw4Ma+Ud1Zm4JV4x/OcpcCYYPtvTKa3z+cNfG5482bXz+2N7G58MblqOw
yc83Lk8+3fh80qbG9WeNalyeUde4fMGyxuUv9mlcvlQ0Ll9a1Lh8pbtx+aohjcvfvK9x+frdjcvf
2dK4fHOPxuXvb25c/tdejcs/OypCrfXnirCUjRehlgbnng9EaEiD86/HCcu2bw2NUkY32RUuwpXw
TuGx4YPCPwz3NC1gyhVFKOSdIjpAbERyRFrEhoi6Zg81G9/soya7rk60jcVGfepkWvtz+jCQmhZc
K4WLQK/NvohQIgIW/pxiIwIp+UpKM1NdIHFvgfSRkcI7tYqLHBmZHJnKz8zIxVHpUTmRI/np4mcO
x8mRyVGbozxR1VHnI0eGi/Yt29/BzwHUvjplklLrU/vE4JVGCcuBZNi+yoJZ4jL6Nlq3TzVqBZJx
H1elTO7LY95bMHXs0bll59VR57umXuv+jLFrmNoPMFLX1TEjIpNjNsV8EbM75mDMkZhTMWdjLsT2
jTkYOxrGxU6LTY+dE+vp1rTbkG6jqXd1OkLafSUdNK38OZ0NJix3mxjb17B/jXSE/saZfdandCPd
MTbWE0jcQyCNNlLMwTvjzJFYXD+ef4xg5MgeW3vsIG0lHbx/Ue9dvY/0ru59vs8IA+Nq303xe/tP
HHCwPn/8qSfq6hmaOTS3nmHRiYMTNw33Jg4euXLk+0ntkvokDh59/tldSe2SWyT3TB6Vsmt85oS9
k7sa5VPbJrVL2ZWya2ry1LSpWVMLpnqmz5qe9fz7L7ROe3DGoBmjZ0yZkT1jZbp75oGZJ2Y1y1if
sWlq8vRZGVqGNmMQ10gZmzJ2ZJzI/CFjxxxtzr65Hef2yNgx15e1aG7HrFezVs4bn30g++j8I0bp
3I4cH1hw4sUmOV1yeuRMy1mUs56j9Tn7cnyLlixyL/rhpZaLVy/WcqYtPrL4CFf35fRYfOqVs4uW
/GUzdRct2ZCz3ihZOn7RDzn7lollzmWrl3dZfsfy8cunLJ+1fAHHC5Yv5ucS8rzlRaQF5lX3ax9w
ffzy8a8fpJ5Znpucm5brya1bYVvRdEWLFR2h64qeK+JWxK8YsmIXV20rDpC6ruhKne9XjlpZvaoH
NZuuiqcmJavGUbPrqs2k0lWfrdq36uiqqjwlr11ebF5c3oC8xLyxeVPy5uQtyluftyVPy9uddzDv
h7zqvLN5F/JFvpLf5Fpqc0VxGiRTQxrpRf7Qa6eASlxznY+8xsoeaapIg5TfIBmlDc8D6++qNdJo
LeRPu3YKzP/89Ii0qPOx6eaq7pQ/x3iS4LOhz/krIzZwVhS40rQgokP+uoi0/E35Rw3Naz8gXESl
GzTZZZQHx8nQ3CLDjlnjw/rRqx8xQ1PRXlOBDXWnLDiCzcZzhhrTA1aNknw9Ita8GlCahjr9x7sY
dJXGFxnJ0HUjBfU+2C6iA+m/U3bD62wwtf2hgO8xkmmFNoZdQ+eNd7J6lvmWFq/ejUagFGj7+TW3
renRfsCa+DWZ7QcElNms88ebTja1JaDcLsPKmryodLNuQJkbvH1DjY3jNVuicqhxRbXDhdlOW3Og
4MEoT7go2HGlLPUac2pxfpN663/4CUPVArpmnuU0TA3nXdAnNPAKUecD6WpP0P6OgDczEnbOG9ei
cjq3jMpZa/wTgy5jphg28Q0H1w4y5+XumFOFI2PnxFww/ENseuEnhbuCWryJ0oA3MHXeqG1eP3vF
Rxw0/ck4rH1h1r8y47sN4Ww3XiGdMq6/8VTsOPPaF2ba3dBDXEmmnzKS4U0aehTua3TQj1zlSUxf
Nsf0JE0DHs1IXPUY/Zl2aBtzwfAtxpO/kfqG/mZBZPKbpUVRxqhHJhf1KFpXVL4mL3Jkck88QM+A
3hcdRd0HFbdGrzsGdDn7AF7jf5jwEX9KeJpG6eoa+KFGKbmFcR8N09Vt8Er/Zgr4pgytPq8/qz83
nrpRmjJjSsCP/fcJD/fvpB3/84THbJQCb+OPhAd9NfBurpWu9V4M34lvDfjVQJqW08PwrotXcxRI
668cTVtwYsEJw7ea3tZotS+QFv1gJKNtzrTijnhlo/UivKnhaQOpyPS1AT9bxNF40w8XBZNxtsCs
vyCYlpipiBZ5xRMN/4pnDXjeQLJxbnjggPc1Uov6I7x1suF9zfpdgyneTEYrW/E0Whntmga92khT
j9KLl6xvaejg+sCuCyVZvzmgNW+13pC2YcvbLd92vb3X3cQ9wq27L2+0bWxZFLUpblMf1KV602Pv
nIiqbj9gc5PNHd/e23AXG5m8OXPzqwEdCyrX+fYDSrJKFpvKNjJyccmWP/bjUdUlPnRrwJboLbve
7bE1auuG9/q8p5embuu07bNlYvmSnH3mfoVk7CiMtLwLsfF+6ReHZazwSV38Ik9abJAqXZYTUrOc
lIUhiTI3ZLjMdW4S8c53QBPxYROE8Vezh2U5kTbtLBbpo53PMkhE0faQ8RfQtPURye4n9j4svdQ7
zPkv0h+s16JRvbZBK15KPZYIWW65k+NBItqSwPGT8jPL0zASkmAUPAPPUScVCwvghPTakuVntjEw
Fp6DcZACE2ESpMrPiLr3E3Vz57QsF3cTx1vEZDD+4ngqTIPp8DwYfwGcBjMg3XxerzVDfmPNgYXy
G1szYbE1h+vgemgBN0BLaCUs9mcBe3bs2bFnx54de/alsAyK4Rj4oBJ+hOPCoh6X36gn4KT8JvRh
6AOPQF94FOKhHzwG/WEADIRB8Lj8JnCnog1jaox4OWNqjGV3xrGEcSxhHEsYxxLGsYRxLGEkPIxf
IW8imTEsYQxLGMMSxrCEMSxhDEsYwxLGsIQxLGk4E4iFD8tO9FSLlVQsvMJ80ZgvGiP9i3Cab5uZ
JJpQzxOcYzpX/2m+Od4abcppo9NGb2TZFpwTuvGmqOXFRuCJfFzVsPESM+Vwg5niNWfEAlqckLG0
cIvrgy28wRbZtDhECw8t4mnhoYVm2g/MoWyjH2WYGKculyOcJbAF9sMB2auRNWOmurB2Emvl5uga
M7XxjMz9X1oLDVr7uznnjSdI5R2cwOpJmUqr7uYqa0GtcmqV0Kcn2KebPtcG+yykz1LzDQb6bEvr
9EZ9BvsL6yO1sAnS+D1LYDzLLeuEImuFE66DFtBS1olW1Gktj4o25G15Z+3kIXEbZbdDV4iBWLgP
7oc4eACGwwh4Ep6Cp2EkJMEoeAZGw7PwHP2MgxQYDxNgIv1NglSYTP9TYCpMg+nwPLwAaTAD0mEm
9zcLMiATZnOvc2AuZMEi+nLBq/AXWAJLYRksh9cgF1ZCHm8jH1bLUrEG1sKnXP8MdsAu+Ap2w174
GvbBN+CFA/B3OAiH4Fs4zBw8Rs76EJXwE5yCn+lHh2qogdNQC3VwBs7Cr+CHc3Cee/kNLsDvcJFr
l8gvk0veewjrzw5tmA9tmYM3MifaQZQ5Nwotk2EKTKVsGkyH5+EFSIMZkA4zYRZk0C4TZsMcmAtZ
MA+y4U36KoJiWA9vwQZ4G9ywETbBO7AZSoC1YKlm1tVAHZyR5dYQsIMKrdCBe+E+6G1qgg9N8Nma
yaO25nAdXA8t4AZoCa2gtTxkawNt4Q5Za3uQNr3hIXgY+sAj0BfiZamtH/ljMAWPwXjYGA8b42Fj
PGyMh43xsDEetnTqzoRZkMn5bNrMkYW2l+mDOWXvB4PgCRgivXbmvp25bx/F8TPwrDxqT5aH7FO5
xhy2M4ftzGE7c9jOHLbP4noGzIY5kA2vAHPVvpTyZZDHcT6shjVQgL1C8nXYL6ac8bZv5NoW8o+A
eWjfD8xFO3PRXi7r7N/B9/BPOAIVtD0K/4If4Bh2fFAJP8JxQJftvC97lfTYfwKdPi5g73e4KGsV
KzDnFBuoEAph0qeEy1Lleo7REqU1522gLdwI7eBmrt8C6IlyN+c9oRfHvCPlEfK+8CjHCeRDsYV2
KGiHgnYok2AKMJ7KNJgOz8MLkAbpMBMYV4VxVTKBsVUYW2UuZME8YJyV+bAAXoTFwDtVeKcK46+g
E8rr3EMurICVsArQBwV9UFbDGijg/tAIpRDegCJgDShvU+bmeCM5819h/ivvcryV/D3YRtkH5F+S
f4V/2C8LlQNwkONDXDtG7oNK+BGOS68qAJ+jMr5qc1motiVPJB8OI+BJeIryp2EkJAHzUH2GeqPh
WUgGfIU6kbqTyFOBsVJfl7XO5rBc+pw8o5P55mS+OVnfTg/nO2EXfAVonxPtctbIUudpWRp2n/SF
4QPCWFth/YG1EMa7CxsGiYBPCGNdhLEuwvAJYUm0mYhevSxscqewsxtQwQGhEAZNoClEQDNoDtfD
DdASWslsvJMf7/Q53skrbpSr8VBpIlJ+LKKw2R46wE3QEW6GTtAZusAtEC0Lxa3QDXt34GHvJO8O
d0EPuBt6wj3QC+6FB6E3PAQPQx94BPrCoxAP/eAx6A8DYRA8DoNhCCTAUBgG7HhEMoyBsfAcjIMU
GA8TYCLPOglSYTLPPAWmwjSYDs/DC5AGMyAdUHA8oheP6MUjevGIaXjENDxiGh4xTcxjnLJhPrBT
Ei/y/Dnkq0W0WANrYSM7jk0Q2Clr4jzXfoML8DtchEtwGST7FkV+iOfR8To6Xke3RLIbieItd5Db
LTdR1pH8ZugEnaEL3ALRcCvlt7Hvuh1SaTsZpkAGZMJsmANzsZcF8yAbjsl0y49wHPCieBUfXsWH
V/FZ/Fw7J9PxJhreRAv5Re4MqYYaOA21UAdn4Cz8Cn44B+fhN3ajF+B3uAiX4DJIqdsEsCe1WaGZ
9OOZ/HgmP57Jj2fy45n8eCY/nsmPZ0rDM6XhmdJs8SLa1g8eg/7yQ9sAud02EAbB4zAYnoAhkABD
YRgkQjqeZybMgkyZjRfSbS8C7822UOp25qCdOWh/TLTAE31uZ57ZmWd25pmdeWZ/GkbJbLxSNl7J
j1dKs4+RH9uZa3bmmp25Zp8Ik4B3YJ8sd9p5B3gtP17Lj9fy47X8eC2/fQZl6TBTFtp5P/YsmAfz
gflk557sCylfBC9xvBheBhf8BZbAUuwsg9c4fh1WcC8rqb+K4wLubS3H67jXIs6Lqbee87c43kjZ
Jo7f4XgzlMC7sBXeg1LYBu/DX+ED2A4fwt/gP0CDj+ET+BQ+gzLYAZ/DF/AleGAn7IKvYDfsgb3w
NeyDb+AgHIJv4TD8J/wDyuE7+B7+CUeggmc6Cv+CH+AYz+aDSvgRjsMJ3t9JqML7/gSn5Gr7z6Dz
7L8wTtVQA2ewdxZ+Bb/8WAkX0UofGAoFwDpWCuENKAI3bIRtwPPhdXS8jo7H8Sncp8I9KhVwVH6o
nICTUCWzldNcoy/Fz/k5+aGqQrj0qU3J0Wb1BnI8vNqenLmGR9LxSDoeScf76HgfHe+j4310dYz0
qGPhOeoz3/BCOl7Ip06WHzprRLTztIgOS0JTjPg1V1j5OYiop5ZI8rAZxRpxnW6eFRrXuUIEIg6L
aRydtVSJzZafxWYrMXxID+gJ94jNIYkwHGbAPHiR6zmwEF6Gd2AzlFC2hfxd2Atfwz74hute8v1w
AP4OB+GQmGZ/U2QqishT7hPxxFwXlESOnxLd1YUijvjL61xBLLtSZDpXiXFO9mzON6EEtsA28YHz
fZHn/Kvo7vwYysRu5w7O91B3L+ynzgH5D2c1ZWc4P4uaG8/u4tlPms9ujNMI4TC/wwS+rJQzQp6r
vtQoDVtR2p3S7pR2F05K/MEY3ae+wo7hVXp9G9ywCd6RXqLGVPNtaNioM7/kEJeLFrSrM/47duOJ
lRIsbg72Vc6zS55T8pyS55A8hwyUcJ+1WDlD28PGvXJ/0aZt4/36hL1BhO+lPJlRzRTvCxee6C+w
BJbDa5ALKyFPRIl8nmS1iMODxYkCrq0lZ/+FF/OJMs53wOfwBXwJHtgJu+Ar2A174Gv4OxyEQ/Ct
6QF1ccyIw6ESfoJT8DP96vALx9X0XwOngYha1MEZOAu/gh/OwXnu6ze4AL/DRbgEl0GKOEsIo/om
FEExrIe3YAO8DW7YCJvgHdgMJaKFrRuwk7E9KJy23vAQPAx94BHoC/EiDg8UhweKs80WUbaXqc+4
KvSpqBAmolCROKUFxy2htXAqbaAt3Ajt4Bau3wb0p9Cfchf0gLsp6wl9aN+X80exlUA+lPNJ5C9A
GsyAuZAF8yAb5sMCYCeiLAbuSzHu6xV4FXjvyuvYy4UVsBJW0Zfx/7nivSurYQ0U0BfvHdWLQ/Xi
lHW0YyxRvzjlbdq4yTcC46Ywbsq7XNvG+Qeihfq6aOFcLpxObDrzOV4NvAOnR0Q5d8Iu+AqYJ86f
qVMj4lCruLD7hDOsr4gK6w88b9hwGAFPwlOQRJ1R5Ckwkff/kfk1ov5LxNVfIGpFvqwSq9lzrYEC
WqwlLwt+gfgcvoAvwQM7//RVYk/wq8Sfv0Jc+wtErdAB3RDV9FkDp6EW6uAMnIVfwQ/n4Dz38htc
gN/hIlyCyyBRB+MrxP/Jl4Fj4hbLj3Ac/HAOfmNmXxIt6r8I2LoRdQei+yqi+yqi+yqi+yqi+yqi
+yqi+yqie43oXiO614jWa+sjdTNSVc0ItZYIVTOj05ZmhFpFhFpFhFpFhFpFhFp1JTqlP4X+lLug
hxmtVhGtVhGpasEotTYYpWpmZFofhc74N6PNV69EnLVEnLVEnLVEnLVEnFVEnFVEnFVEnFVEnFVE
nBoRp0bEqRFxasxwJzPcSeSpEXXWEnVqRJ1ag6jTiDY1I9o0o7zlsooIr+pPEV4tEV4tEV4tEV5t
MMKrIsLTiPA0IrwqortaortAZHd1RKcxw51hKRxPZI50MD1K0Nf8v/DJlg/EQukSi0SEeIl8MbwM
7D/FK+Svcp19KOtPF0s5XgbLpZt16BavU55LvoJ8Jfkq4q48vG4+5/VfBQvYmRhfBgtllniD6+vg
TSiCYlgPb8EGeBvc8A5shhLYAu/CVngPSmEbvA9/hQ9gO3wIf4OP4D9Ag4/hE/iUe/4MykQ8uqDj
2eLxbPF4tng8WzyeLR5d0NEFN7qg49nixV7qf835PvJvwAsH4O9cOwiH4Fv4T+z/A8rhO/ge/glH
oAKOwr/gBzhGfR9rv5L8R8bqOGN1Ak5yzN4RrdHRGh2t8aI1XrTGg9aUojUutKYUrSlFa0rRmlK0
phStKUVrXGiN6xpfPPXgF08drdEtQmYxywotVvIQ6Ta/jNtFBPqjoz86+qOjPzr6o6M/Ovqjoz86
+qOjPzr6o6M/OvqjE0sWWnzY4DmIKQuJKQvN3wVUE9vWiO6WOvIz5H6un4PzxJfooOUiOfpntcpc
qw0UaCWiQ3oT490oXbZ2EAlR0B46wE3QEW6GTtAZusAtEA23wm1wO3SFGIiFbiIe/dNtd3LcHe6C
HnA39IR7oBfcC/fB/RAHD8CD0FuWopkuNNOFZpaimaVoZmnwi6iOZupophfN1G1GrHZBRNh/h4tw
Sbrsl0FKl2IVEeipW7GRq+QOroVyHCa95te/pjJLuY5r13OtBeU3cNyS3XEr8tbQhjpt4UZoB4yN
wtgojI3C2CiMjXIzbRkbhbFBj3WFcVEYF3TZrTAuCuOiMC4K48JOJJ6dSLzCuCiMCzuSeHYk8eh1
KXpdqvTCFmOi3M99MR4K46EwHkpvYDwUxgNN15VHqNcX+4/yHP249hj0hwHEQANp+zjHQyCBOsaX
SfalykjOk2g3Cp6B0Zw/C8kwBsbCczAOUmA8TICJQOyjTCafQrupMA2mw/PwAmVp9DOD50jnfCbM
ggzIhNkwB+ZSJwvmQTbMhwXwIuRgGx1UFgE6iN9x43fc+B03fsfNzioev+NWlvB8S2EZz03EorzG
8evkubACVsIq2ucBOogvKsUXlV719XOdzFXeBOMraDHjtR7egg3cJ/FE8IuormzCBmsP/6QraCE+
yqtspc57UEr9wNdRt8rzqpnSpc6GOTAPsgE9x5e5nc1FhJPnc/JsTq45X4UlsBSWA/eLn3Pj59zO
Ao7XQiEUcb5BZju3yizne4C+Oj+Fz+Bz+AK+BA+xz07YBV8BOuo8xHX0D//oqv8C6qyVWfhIV9j9
IiKM+RX2iMzGX3rxl96wJ7jGnMFv6mFDyYdxngjDpRsf6saHuvGhbvOr6CiZG/YMtpg/YcyfMOYP
u8Z4fKpLhLFDimaHFM0OKdpyAvxwDn5DlS6J7lariLbaQCGa6oavqsBXVeCrjuOrKvBVxm+QKtDT
CvS0Aj2tCP4GqeLKb5CEGXP50FPjtyQV9b8lYU1XsKZ9rB+f+ZV+IAzlWgFgm/dfwfuv4P0f5/0f
5/1X8P59vH8f79/4El5hfgkvhW2ygnH3Me7GF+QKxq+C8fPx/BU8/3Ge34ixCtiRFpp/k+Diroy9
hJ+78nMXfu7Czx346c1Pb3568tOTn5789ODHuh/rfqz6sejHol8olgh5yjIIUtH0E1ILSZSukOGM
q8X44mj+PtT4snDSPDpkWcBRSPC3uH7z33KzBn+nrJstysR1lieJXp+GkZAEo+AZM6J1s7eJZm8T
bUuWh21jYCw8B+MgBSbCJEiVh81707k343fcfYzfhtf/tQU9LZDV5h1VmPdg9Hyan8TMZv86/ev0
r9O/Tv86/Rv36KH/KPqPon+d/nX61+lfp3+d/nX61+lftxnPbliqwVINlmqwVIOlGizVBO7liqUa
LNVgqQZLNViqwVINlmqwVIOlGtEMS5VYqsRSJZYqsVSJpUrjLwuwUImFSixUYqESC5VYqMRCJRYq
sVDJmDcYPfPJza8S4kGLg6Mm0AJaQleIgVjoBndAHDwAD0JveBKegqdhJCTBKGCOWUbDs5AMY5jn
HHOHPptxPBaeg3GQAuNhAkyEScBd2SYzlzUogy9gD+yFH+AnOAU6/ALMb4W1plySPjUUnBAGPI8a
Aa3hZuA51EchHlh7KmtP9LQozMdI+ZOlvayzdOD4JugIN0Mn6Axd4BaIhlsBL2m5HebThqjD8iL5
MZ70Rzhufh33sYvx2frLQ7YBMBAGweMwGJ6AIZAAQ2EYJMpDyreyTjlKfgJOQhXew09+Th5SFVmn
quRN4QZoD2PkT+pYGEdZCoyHyVxPk3XiCE/mtajM2FBwQhiEQ1NoBs3hOrgeboBW0BrYP1ja8lQ3
ynJLO2xEmr/l1hihckbIywh5GSEvI+RlhLyMkJcR8jJCXkbIywh5GaFCRqjQ0gN798H98DA8AgNg
IDwOg+EJGAJDYRiMAFaUhdVkYTVZxsMEYFVZJpnruNQyGabANO5zJsyCDPrNBPZYljkwl3vOgnmQ
DfPNv0Ep522VW3Kws8jcl3p4ax7emsdSTZsa8jryM+R+OCc91las+HtlITFyYUhv6eGtenmrXt6q
l7fq5a16eate3qqXt+rlrXp5q17eqpe36rUNRwlGwxRiZe7XNh2IYW3pxNAzYRbMYY/I/dhegsX4
7b/Bl7JcIcZQiBmV/fjsA3CQ40PEm99SVk7Z93DE/KbsVY5R5oNK+BGOAxqjGH8hUyULlRrq1cGv
5rdmL7PKq/wmdVUQu1rAxrEiy5llXtXBMXE8s82rNpelzDiv2pJrbbnWnuMOHN8EHaETdIYuwF5S
jYbboSvEAntq9U64C5gP6t3QC+4F5obK3FDj4AF4EHrDQ8B8Udk3qswZtS/0B+aOytxR0XOV+aMy
f1Tmj8r8UdkDqMwhlTmkJnLPw2EEPAnE0erTMBKSYBQ8w7OOhmd5nmQYQ72x5m9wNVZUOSuqnBVV
rjL31Ilcn0SdVMomk0/n2vPAPpLVVq7OROlt1hViovUt+br1I2G1eoSVKw9xNBiGwgjjv3YXNnxO
SzxMKxkr2hDVtZUfiRvlGtFO9hGRRHBRlLeHDnATdISboRN0hi5wC0QTFd4Kz2FrHKTAeJgAE7E9
CVJhJvZnQQZkwmz6mQNzIQvm0Wc2zIcCZryCdrWRucHV72P1F7L6Pax+ndXvYfX7WP0eVr+H1e9h
9XtY/R5Wv4fV72H1+1j9Gqvf+KuvXFZqLis1l9XpY3X6WJ0+VqeP1elhdXpYnR5Wp4fVqZt7gBel
bm0nq62MgfUmud/K81pjZYz1Tllg7cFxg9G0jpPHrBMAVbBOI5/F2M+WhdYsjpdTt5h2G+RW6zvk
2+Cv8jvrp+Tlcqf1ojwW0pSdSnNW9W3mbzCrQ6qhBk5DLdTBGTgLv4IfzsF5WW1rLfvY2kBb6I/W
D0AZBsIgeBwGwxMwBBJgKAyDREiHmTALMmUsqz/XPkS67aNkrP0ZSJZ97GOk1z5ZVttnQDqgFPaF
5IuAqMG+kryAemvJ19FmPflGzjeRl0uP/Tv4Hv4JR6CCOkfhX/ADsBOwn4Qq+ZH9Jzgl19h/Bh0b
v2AfNbTXgKEU66SHvaDHVKT9RCAH4BDn35rK40NlfKiMD5XRUBYfyuJDSXSUxIeKeFARHyqSi4r4
UBAPCuJjheayQnNZobms0NwGq9HHavSxGgtZjYWsRg+rUWc16qxGYyXmshJ9rEQPK9HH6tPVGtqd
lgvVWjlbrZNl6hnOz8oE9VfZS/XL6eo5zs+zcn+T1eoF+B0uygr1ksxWL1Mu5R6HkBUOi0xwWGUv
R4hMd7BOHXZZ7lDkQocqZzscsswRyrmTOmHUaSKnO8KhKUTIVEcz6jSXFsd1UnFcz7UWMtlxA3lL
aEV5a9q1oU5b6txInXayrSOSsijqdSC/SaY4Osokx82yn6MTfXa+fM7RBW6h3q2U3wa3Y6crdmKw
E4udbti5g/I7KesOd1Heg/Z3U96T8nso70X5vZTdRz8PSM3xIM/Wm/OHZInjYXmro4+8wfEIz9ZX
5joepV087frR7rHLlY7+l99wDOCeBl7+zjFYFjueoN0Q7jNBZjuIthzDaJtI/eEy1jGC8idp/zT5
SOol0W4Uz/EMdkdT71nqJVNvLOXPUT4OOymUE7E7JlA+kXI0y1Epjzl+hONwAk5CFfwEp+Bn0OEX
qIYaOA21UAdn4Cz8Cn44B+fhN7gAvwNr33EJLoOUx0IFWID1FjpFVoROldmh0+T00OlyT+jznL8g
E0LTZK/QGTI9lLUYOlOWh86SC0Mz5OzQTFkWOpvzOdSZS50s2mXDfJkSukAmhb4o+4XmUHfh5XOh
i+Al2Tb0Zcpd8IpMDX2Vdn/BzhJpCV0qldBllL8mi0NfpzyX9itou1Lmhq6SN4TmUSdfxoauobyA
8rX0UUj5G9IVuo7yNynfIWNCd8EeuTV0L3k59/sdVHNeA+dkjDNc7nR2h7tgsNScCbLQmSyPOcfA
LI4zYL7x1RldbobH0vBW7uBfqxp/D5SKt3LhrcrxVhreSsNbaXgrDW+l4a00vJWGt9LwVhreSsNb
5eKtcs2/BZqIrUmQClf/LY0L7+TCO7nwTi68UzneqRzvVG78HQ2eQcMzaHiGf+AZNDyDG8+QimfQ
UHwNxXej+PNRfDeK70bt3Si7hrJrKLuGsmsou4ayayi7hrJrKLuGsmsou4ayayi7C2V3oewu1Nkd
/JsPL+rsRp3dqLMLdS5HnTXUWUOdNdQ5F3XWUGcNdS5HnTXU2YU6a6izG3XWUGcX6qyhxG6U2I0S
u1Fid4O/BKz/e4RUlDgVJXahxOUocTlKXI4Sl6N0XpTOg9LtQem2o3QelC4FpUtC6ZJQOi9KV4LS
aSidhtJpKJ0XpdNQujKUbjtK50HpUlC6BJQuCaXTUDovSudB6fagdNtROg9Kl4LSJaF0SShdCUq3
B6XzoHQulC4JpUtA6bajdNNRuhKUbg9K50HpFqJ0LpQuCaVLQOk6oXTbUbrpKF0xSleG0mko3WyU
zuXoTJ0uqNYt1LsVO7dh53bsdMVODOWx2OlGnTsov5Py7pTfRXkPyu9GiXpSfg/lAaXbjtKloHSH
UDovSrcHpduO0iWjdCNQukMoXTFK50LpElC6ZMdj8gGUrgql2+4YiCIO5v6eoN0QclYGSleM0iWh
dAkoXS+Urgylc6F021G6MpROQ+nyUbpilC4BpeuH0vVC6cpQuj0oXRlKl4/SFaN0SShdAkrXC7XR
UBsvaqOhNmWozXbUxoPapKA2CahNEmqjoTZe1MaD2uxBbbajNh7UJgW1SUJtklCbYtSmDLXRUJvZ
qI0rdCHtF6E8L8lOqE0JarMHtfGgNgtRGxdqk4TaJKA2nVCb7ahNGWqjoTb5qE0xapOA2vRDbXqh
NmWozR7Upgy1yUdtilGbJNQmAbVxozZu1GY+auNGbTTURkNt5qM281Ebt7AH9mzsvYw92ymRaNVF
Invj/o33xmbZPMrmiXxrLLVWyETrW1w1dtMnZWWIkDNCmglrSEuRqAwTeWqNuEc9LYaotWK4ekY8
rJ4VA9Vf/4u6uw+Pq67zPj45hWYmTaHKQ1XQsSLQUlpo2hjERmyAAE0RqgNCo7VKKyE8hIcUKNAG
iG7RtWqKWh/iQ3V3XNtbd5SCGF3rKhHrSo8QKhkxSjvAwFICYggPlpx9nZMp1L29r93L697b6/7j
ff3OnHMymTm/9+/z/f3OTFNtPE6eS82vfj41q3qPc15yzljqnHQqtSBdlWpJB9oJKvn+qYb0xNTZ
6WrHMvbVODZJW+vY5NT89AH2H+j4FPtehVfbd1CqOX1walb6ENuHOj7V8dc69jocZt/hfvb1znmD
c97o8TTnvMk5b7Z9pHOO8juPds4Mj49xbKZjs+yfjePsO96xOdo6x+Y6Vm//W9Bg3wmOvdVzn+i5
G+17u3NOwjtsL7C/SXuy93BKqi59qu1mP3Oa/ac7/ww/u9CxltQR6Xc6dpafO9vjd9l+N3LOPcc5
5zr/Pc4/3+tc4pxW57zPsaXOeb99y5zzQe0Fji137EP2X4g251ykCl6Sashcmjo7c1nqnMzlqQWZ
K1ItmSu1Vzm20rGrHbvGsVX2XefY9dobHFuTmp/psv9Gx2+23W3/h53/EcfWenyLYx917O/t/zjW
2fcJxz7lnB7H1nuuT9v3Gcc+a98Gxz6v/YJjX3TsS/Z/GV9JzU99mlkzK1b1smrpPkbVMaqZUS0V
o5oZNZ9RA4xqqBhVx6hmRrUwqoFRCxjVwKgyo+oY1cyolopRzYyaz6gBRtUxqoVRzYxqqBjVwKj5
jJrOqDpGtTCqmVENFaMaGLWbUfMZNZ1RdYxqYVQzoxoYNZ9RdYzaxag6RrUwqplRDRWjGhi1m1F1
jGphVDOjGipGNTBqN6PmM2o6oxoY1cKoFkbNZ9QCRs1n1AJGzWJUA6MaGLWAUdMZVWbUAka9llEN
jGphVDOjGhg1n1ENjCozaj6jpjOqjlEtjGpmVAOjGhhVx6hdjKpjVAujmhnVwKj5jGpgVJlRdYxq
ZlQLoxoYtYBRDYwqM6qOUc2MaqkY1cyo+YwaYFQdo1oY1cyoBkbNZ1Qdo3Yxqo5RLYxqZlRDxagG
Ru1mVB2jWhjVzKgGRjUwqo5RuxhVx6gWRjUzqoFR8xnVkLolmMam2Vaet47n1YRUaiargqRej9fp
7ep0tzrdyaZllTpdUJcH1OVBdXlQTV6lJrczqTupx+N1eLs63K0Od7JomToc198O9bdT/W1Xf7er
v63qb1x3N6q7Hepup7rbzpxJ6u52dbdV3e1Td4fU3UF1d4O6u0LdbVd3l7GnSt2N6+1G9bZDve1U
b9uZM0m9jevsRnW2Q53tVGfbWTNJnd2uzraqs3F97VRfV6mvHZX6ukx97VBf29XXVeprK1smqa8D
6utp6us2dTWvrq5RVzvV1XamHKKublNXl6mrferqoLo6UKmra9TVdnW1lS2HqKt3qacb1dM16mmn
etrOlEPU0QF1dFAdHVRDV6mh7SzpTurneN3crm52q5udDFmmbvapm0Pq5qC6uUHdXKFutquby1hS
pW7G9XKjetmhXnaql+0MmaRe9qmXg+rlQKVerlEv29XLVpYcol7epU5uVCfXqJOd6mR76htV7VFf
fH8jmbmO38/oS+5bXK1dFYUVWwpmd+1md62s6WVNnjWNrMmyppE1BdasM6PrY04nc1qZkzejK7Cn
kT0z2HMaewpmc+1mc60s6mVRnkWNLMqyqJFFi83mGs3mTmDTovSrrO9ejYPsPziay6bFZnONZnMn
sGoGqxalX+f4YTjcuvD1jr/BeW/UTtO+ybrtCOe92XlHOucoHO28GY4f43lmep5jHZ/l+GzHjsPx
js/xWuscn+v4PMfrPX6LYw04wfG3enyi/Y1GwNujJrO5Rra1phdYFzc5fjIDTvGcp6LZz5w2Flq3
fsdsrottM6xbf8C2brO5xWZzJ7BuBeuWpd89tiedG3syfY72XMff4/j52iV+X6v3816/432u31LH
3+/3LNN+0PELnLfc86xw/EOe50L72zzPRWN7zOT6GNjJwFYG5s3kCixsZOEMFp7GwoJZXLtZXCsb
e9mYZ2MjG7NsbGTjYjbOZeNsNs5g4yJrxqI1YzHzkbESGxebxTWaxZ3AyhmsXJT5uGPr8AnHP8Xs
Hr9nvee41e/4tN/1Ga/rs45t0H7e8S94ji/6+V7Hv8TyL9v/lbEnU0tYOcrIkIFl5g0xr8y6Xaxb
w7oy625nWplpu5hWZtoQ01YxrcywIYaV2bWLXWsYNSSbBpm0mT2D7BmSR4PyaBVrNjNlF1MG5c+Q
/BmQP53sGGTHkNwZlDur2DDIhiF5MyhvVrFgs57fJWOG9PjtenxIvgzKlm2yZZVc2aB3h/TukDwZ
lCer9OpmPTmkJwflx5D8GJAfHXpvUO8NyY1BubFKb5X11i69VdZbQ3prld4q66UhvVTWQ7v00Bq9
skuvDMqIIRkxICM69cSgnhiSDYOyYZUrP+TKD8qDIXkwIA86XO1BV3tIDgymNrrS/cZ/j6vd42pv
Nd43G+8bXfW8q77ZeF/myp9bGe9bK+N9q/G+0XjvrYz3zXphmV5YpBca9cJW432z8b5Rb+T1xmbj
fZkeObcy3tcb7xuN995K9WjUQ3ON9/V6abHxvt5432i89+qx9koVadRrc/XaRON9vZ5bbLx3G+8b
jPcNenGZXuzQi3P14my9ONF4X2+8bzTee/Voe6WaNOrVuXp1ovHebbxvNN579fCySlVp1Mtz9fJE
4329nl5svN9uvOeN9416vVt1OU3PNxrvfXq/o1Jd5qouTQzIGu/3G+/rWDDJeM8b7xuN99iIbkZ0
qzKNrJjLiqzxvpkZKyr3qTYY7+tZsoYl3SxpZMkMlkwx3jcb7xuN9w2MWcOYbtWmkTVzWZM13rca
7xuN997KeN/MoGUMWsSgRgZtNd43G+8bmZRn0mbjfRmbzq2M927jfYPxvoFZy5jVway5zJrNrInG
+3rjfaPx3suy9koVamTaXKZNrNwj2mC8r2fdGtZ1s66RdTNYN8V432y8bzTeNzBwDQO7VaNGFs5N
5ZN/sTpeje5lYxMb+yvVqFc1KiQ58DTz/mDO8ow5SpwHI6rNs1HTPpmwnZllZnYzcxUzB5hZZmYr
M5uYuSbJh4l6ptrVSzse50SN45Mcj7NisrF/gLF6oHaK816lB19tPnKQfQfbdwgOtT1VO34HdR0z
JzGzqnJfIc6UTmZ2MrODmSuYuZiZ65hZxcwqZs5mZiczVzGzs3IHdR0zJzGzqnJfoZOZq5jZyczF
zOxm5iRmVjHzzcyMM6g9me+83fZJeAcbF7ChiVUn238K8071vON3UKeoRE8y8xvMXKESlSpmdjKz
o2JmLzOzzJzEzLkVM7uZuZmZ7cxcwcxbmNlbuYM6iZlzK2Z2MjPOsluY2cvMLDMnMXMuM8vM7GZm
nG0DzCwzs5WZTcxck2Tb1dE6ZnYzcyDJuOscv97xOOfWyLUutt1oPnSTinGzc7vNhz6Mj7BzreO3
eO6PJvkX371cx8xJzKyq3E/YzMx2Zq5g5i3M7K3cvZzEzLkVMzuZGWfjLczsZWaWmZOSfIznR2sZ
ubZyX38bCwcq9/XjWXQHC1dUZtGDySx6j/Ylx8ecG8nCVDKb7mBhKws7Kvfxt7FwoHIfP55Vd7Bw
RWVWXWDhAAu3s3A9C1ewsLVyd2sVCwssHGDhdhauY+F6Fq5gYSsLZ1fubq1i4WYWbmPhXSzsZuF6
FraycHHFwgILB1i4nYXrWLiehStY2MrC2SwssHCAhdtZuI6Ft7BwBQtbWZit3N3qYOEgCwdZOMDC
rSxsZ+EyFsbVcTML17OwlYXt8vE0Fj5Zubs1N5l9n+Xnzn55Fr6ZhStY2MrCRZVZ+AYWbmXhNhZu
ZeFGFm5mYSsLF7FwEQu3sXCAhdsqs/HNLFzBwlYWLmLhIAu3snAbC7eyMJ6Vd7CwlYUdlXvo21g4
ULmHHs/OO1i4ojI738zCbSy8i4XdLFzPwlYWLq5YWGDhAAu3s3AdC9ezcAULW1k4m4VbWbiNhVtZ
uJGFm1nYysJFLFzEwm0sHGDhtspsfTMLV7CwNf7OUKou/usP1nLdE45MLan+aOrjNf+UWp46cp8j
yx2Rjqk6Lo5WR9awE6LRdFpbq32N9nDtEcn6fDR9rPZ47TztCdozsNj2Odr3Juvg0fQK7UXRaKbD
OvMq7bXaG7Q3paZ7z6OZj3n8Ce2tyXp0NNOr/Wo0mjojODxaGmRxFOZhOS7EZbgBn0R8x+OnUTHo
x89xL+7HA3gUj+FxPBsVq1+Illa/iD9FS9P7oYSH8QgeRRmP4XH8O57AbjyJYTyFp/EHPIM/YgTP
YhTP4Xn4PWm/Jx3/nj14CWOIoqWZFKpwMToxiGK0tCYdFWsyyOJoTMcMzEM9ToyKtS/gRfwJezAW
FVOH7v17O1WPp06qeiIqBLOSVfuy4Hjbc2zXRVcF74jywamuQnx3skX7Lo/Pdfw9KuRK+66WTdfa
v8r2dfG3qaKe1BlVO1NB1cN4BKN4ztFp0TOefWdwnBXenOhxzz4cvM32uX56eTSif0b0z0hwtXOv
8eyr1N/rbN9g380ed0f91T+20vsJHrH9KMpRf3qRunMmStGIPhnRJyP6ZESfjOiTEX0yok9G9MmI
PhnRJyP6ZESfjOiTEX0yok9G9MmIPhnRJyP6ZESfjOiTEX0yok9G9MmIPhnRJyP6ZESfjOiTEX0y
klkQ9WeacDJOwaloxmk4HWdgIVqwCGdG/VVzqnaO9VXF3/UrxVfL9iN4zPYTeCqVq/ojRu17Ds9H
a6tesH+P9iVXZWpqKcsXsnxh8r2AI1yho2wfk8yni8Fxqan6sTeYa3ue/W/zuDGaqT9XBwv0YVOU
C07Rd6fhdP25UOtKBmfa/07nnBVNC86O6oPFRsq78G7Hc/adq30PL86LaoPzPd8S57fa9168z+ta
ivfbt8zjD+CDuMC5yz3XhbjI67nYa7zM9pXaqz2+xs9c6zmvd+4N9t9k/832dePD0doJJ6WWVv9Q
b/8oNiA1tfonuC/KVd+Ph+zbiRLYVv0oynghWmjELjRiFxqxC9OLUlPTZ+K8qJj+ANqjmemLcQku
xWXowOW4AlfiKnRiJa7GNbgWq3AdrscNWI016MKNuAk3ozvKpT+Mj+DvsBa3qGkf1X4Mfx+tTX8c
6/AJfBKfQg/W41Z8Gp/BZ7EBn8Pn8QV8Eb34Er6Mr+Cr2Iiv4eupIP0Pqeb0P2rz+EZqevqfUpel
v2l7U+rs9Gb8L9vfcu63tf+cWp4uaL8jd7/r9d2GLbgdd+B7uBPfR180Lf0D/NDP/gt+hK34Mf4V
P8FPcRf68TPcjZ9jG36Bf8Mvo9r0PdiOEL/CvbgPA7gfO/BrPIBBFPEbPIjfYgi/w+/xEHZiF0pR
vUSolwj1EqFeItRLhHqJUC8R6iVCvUSolwj1EqFeItRLhHqJUC8R6iVCvUSolwj1EqFeItRLhHqJ
UC8R6iVCvUSolwj1EqFeItRLhHqJUJ+ZpRYdp04dj3mp+ZkGo/4EvBUn4m2Yj0a8HQtSQaYJJ+MU
nIpmnIbTIX8zC9GCRTgT74zWZs7C2ViMd8E4zeRwDozVzHtwHs7HEhirGWM18z4sxfthrGaM1Yyx
mrkAy7ECH8KFaMNFaMfF0ULVZ2Hmk1Ex8zlVpFoV2amK7JRCT0ueMKkcV0cDcUVIxX8b6gG5NVNm
zZRRw/JpOJjtjLie7M2Lq6MHjO9h43u44mywj7MBZ4OKswFng8TZcV+Diq9BKpPUl1nJt6N+qL4M
Jb/hIiRVCvHreVJlWv1K5tp+BJW/RKZSrVapVsvavqoXo56qP3lne2yP2Y68w0BOTohWBvtp99dO
1FZr47vdR0R3eG93qKH1XsFokr1zbMdVrtFVeYfHC7SneqxPg9OTazAz0Kcyd4usLcragqztkbUl
WRsmNVZeydkweG9yvaa5XtPk6xb5WpKvJflakq/FYEVqRtCG+B23ay+ONgWXaC9FBy7HlfZdpe3E
eO3Oy918pXb3Bqvt78KNuCnaVP2W1Az9cod+uUPebpG3W+TtJnm7Sd5uqn7M8ScwnJohT0N5GsrT
UJ6G8jSUp6E8DeVpKE9DeRrK01CehvI0lKehPA3laShPQ3kaytNQnobyNJSnoTwN5WkoT8P01/T1
11PT+DGNH9P4MY0f0/gxjR/T+DGNH9P4MS39rcSRaRyZxpFpHJkm07bItC0ybYtM2yLTtsi0LTJt
i0zbIstKsqwky0qyrCTLSrKsJMtKsqwky0qyrCTLSrKsJMtKsqwky0qyrCTLirKsKMuKsqwoy4qy
rCjLirKsKMuKsqwoy4qyrCjLirKsKMuKsqwoy4qyrCjLirKsKMuKsqwoy4qZIDUjMwH7YX9MRDXS
yKAGk1CLyTgAB2IKXoVX4yAcjENwKKbiNXgtXofDcDhejzcgizdiGt6EI/BmHImjcDSmYwaOwUwc
i1mYjeNwPOagDnMxD/XglkzcJBM3ycRNMnGTTNwkEzfJxE0ycVPmJOe8IzUjNbdqp5H4MB7BKJ4z
Gg9nvTmvWU/ReB8xy4nnkSWzjJLZRclMomQWUDQLKJoFFM0CiipCSUUoqQglFaGkIpRUhJKKUFIR
SipCSUUoqQglFaGkIpRUhJKKUFIRSipCSUUoqQglFaGkIpRUhJKKUFIRSipCSUUoqQglFaGkIpRU
hJKKUJKcRclZTB2UzLP3zb+Vidd/Xe6l41m89z8gXczSbZ8tYRZHz0uQeA7dLxln+B175/RnJN89
KCRz+CuSeVchHv9VS1zjw6p2RWFVCQ/bfgSPRrPiv2r4ymzUvufwfHRu1QuS/UXssf2Sdix6QELO
kpB9EnKWhOyTkLMkZF9lttqmv9qSKnCUdm8lOE57fFw3pOY8+9+WJGZOYq71ngpmqquDkx1XFSuz
1R6z1aVmqyXJudJsNW+2utr7vsr7znt3ayVowftfWpmthlI0J0VzZqurg1bPMz5bnerqT5WmK6Vp
QZoWpGlBmuZ41BSs8HMXatu08b1ACSdV84GECyQcx5oCCRdIOMmaD6RbIN3GZ7S4Nvn2bZGHTYFE
C6RZJVnz1jNF65liMrN9SxTurX7WN8PWN8PSdqW0XSlt89I2L23z1jxFa56iNU+x+jE/8wSG8ULU
xvE2jrdxvM16aNh6aFgi5yRyTiLnJHJOIuckck4i5yRyTiLnJHJOIuckck4i5yRyTiLnJHJOIuck
ck4i5yRyTiLnJHJOIuckck4i58xwV5vhrjbDXW2Gu9oMd7UZ7l1muKvNcFen/56lH8c6fAKfxKfQ
g/W4FZ/GZ/BZbMDn8Hl8AV9EL76EL+Mr+Co2YnyGO9WoqTNqpqbz0WBlhrvcqJlq1DQbNc1GzdTK
DHdqZYY7tTLDXakarFQNVqoGK1WDlapBr2qwUjVYaYa72gx3tapQUBUKqkJBVSioCgVVoaAqFFSF
gqpQUBUKqkJBVSioCgVVoaAqFFSFgqqQUxVyqkJOVcipCjlVIacq5FSFnKqQUxVyqkJOVcipCjlV
Iacq5FSFnKqQUxVyqkJOVcipCjlVIacq5ORZkzxrkmdN8qxJnjXJsyZ51iTPmuRZkzxrkmdN8qxJ
njXJsyZ51iTPmuRZkzxrkmdN8qxJnjXJsyZ51iTPmuRZkzxrkmdN8qxJnjXJsyZ51pQJojAzAfth
f0xENdLIoAaTUIvJOAAHYgpehVfjIByMQ3AopuI1eC1eh8NwOF6PNyCLN8KKN/MmHIE340gchaMx
HTNwDGbiWMSzcXNTFalORarLzLFdh7mY53G91jhUkfIqUl5FyqtIeRUpryLlVaS8ipTPnOScd0DW
Wu8XrfeL1vtF6/2i9X7Rer9ovV+03i9a7xet94vW+0Xr/aL8b5P/baljkzX+buk0O8nl/mQ9Hifc
6RJsfB1elGq9lURbm9xzGU+z1dIsn3wqYb1sJK83etuN3najt90IXW9UthuNBSOxYCTuMjqWGBmj
RsZlRsZX09+0b5NRsBnftj0+It6QjIjvRQW1vM7VWuJKLXGllrg6Z8v9ncm/U8+rCXk1IK8G5IPD
vfpsfF8HR2GWVz1bfh6XfJrXH8yz7222z0j+ZUKcpWEyOzUzDFbK+PH7PH2VjAxlYp9M7JOBPTKw
R971ybs+eddX/YIV/Yv4k3G/HxZFPTKuh/8h/0P+h/wP+R/yP+R/yP+Q/yH/Q/6H/A/5H/I/5H/I
/5D/If9D/of8D/kf8j/kf8j/kP8h/0P+h/wP+R/yP+R/7EAfB/o40MeBPg70caCPA30c6ONAHwf6
ONDHgT4O9GUutmrrVLUHrUNy+6xDctYhOdV2bfyXeKueiIrWIjlrkZxK26/KrrQWCVXaflV2pbVI
qNLmVdp2lTav0rartHmVtv3lXjkiejDplWO0s6wzxtckhaRXTksqZ39lrRGvMwoqYmmf+zf9KmKo
IoYqYhgst29FKhtcqG3TtsNc3/oia32RDS6zv0N7OczzrTGy1hjZfdYYheAG26vt68KNMKe3vsiq
fA+qfA+qeP0qXr+KF6p4oYoXWl9krS+y1hfZ/82Ar5ld/XfnTN9y7n+aN0n/funfL/37pX+/9O/n
f7/075f+/VI/lPqh1A+lfij1Q6kfSv1Q6odSP5T6odQPpX4o9UOpH0r9UOqHaf2afhiP4FGUYdyn
H8e/4wnsxpMYxlN4Gn/AM/gjRvAsRvEcnofrkHYd0vF12IOXMIaIWSlUIUhlrRWy1gpZa4WstULW
WiFrrZC1VshaK2StFbLWCllrhay1QtZaIWutkLVWyForZK0VstYKWWuFrLVC1loha62QtVbIWitk
rRWy1gpZa4WstULWWiFrrZC1VshaK2StFbLWCllrhay1QtZaIWutkJUvWWuFrLVC1lohK2uy1gpZ
eZOVN1lrhay1QtZaISt7stYKWWuFrGQOJXMomUPJHErmUDKHkjmUzKG1QtZaIfvyCLv+5flmPNeM
55WNLIxX4GfibCyWQTn7zmPo+dr323eB7eXOvRCX4QbzqvuYeP9fmGe1S9iLcQkuxWXowOW4Alfi
KnRiJa7GNTAazK8K5lcF86uC+VXB/KogvQvmVwXzq4L5VUGSF16ez+ydy/yzx9+R1t9l2G3Ygttx
B76HO/F9/DLKm3PkzTny5hx5c468OUfenCNvzpE358ibc+TNOfLmHHlzjrw5R96cI2/OkTfnyJtz
5M058uYceXOOvDlH3pwjL3PbZG6bzG2TuW0yt03mtsncNpnbJnPbZG6bzG2TuW0yt03mtsncNpnb
JnPbZG6bzG2TuW0yt03mtsncNpnblo6v7x68hDFE6mYKVZiVms+U+UyZn9TtvTX1VdWR+pbGa3AE
jsU8LMZ7sSJ1WaYD1+ImfAy3YoNn6dV+NVWX2i9YIKXOxmLkku9gJ9/Tju9zJcdOrXxH+yxp+S7z
yD7J8oOolKqpGk7u2QdVxq6VUmD1Er7yPe8onPDWVDDhRM94CQ/zyacqcdVvwZk4G+Nrl6sqa5d8
UunPk9Dna19J5vx/Wqv08DNfHfdnO6xP+JjnY56PeT7m+ZjnY56PeT7m+ZjnY56PeT7m+ZjnY56P
eT7m+ZjnY56PeT7m+ZjnY56P+b92lcrXPF/zfM3zNc/XPF/zfM3zNf9/YY7dw/cevvfwvYfvPXzv
4XsP33v43sP3Hr738L2H7z187+F7D997+N7D9x6+9/C9h+89fO/he0+qygymNnVm5c5hTsXOvXLn
MPl8K7lrGDTqnwWVFfaZf+5RcB7Oj/sPF6hi9+F+16UdEit9CS6FSpruwOWwOk9fiasg0dLxXQJz
pvQ1uBZW7enrcD1U1/RqrEEXbsRNuDm+9rgNW3A77sD3cCe+j1/iHmxHiF/hXniN6QHEr3MHfo0H
MIgifoMH8VsM4Xf4PR7CTsT/F8drK58bxvc1e5k9XPnssI/FwyweZvGw3h/W+8Pp+P7vVlgF6/1h
vT+s94f1/rDeH9b7w3p/WO8P6/1hvT+s94dTZ7xy7Y0269/k+p+l/f+lD/q8kx/gf7IvTk7uQ49X
wP7kfvN49etP7i/Hc74LzL8q87D/J/dz/6s52C9xD7YjxK9wL7xGo7o/Hb/OHfg1HsAgivgNHsRv
MYTf4fd4CDuxK+qP/y16vMraJ+EnvPKv06MwOd5vFRZ/4h3G1qb2T36iJT7n5b1h6pQkz+Msj92z
zkvmFuNXtpBk9/vti/8K+n1Rsfr+5JPH//mc/q7fcxu24Hbcge/hTnwfv5SZ92A7QvwK9+I+DOB+
7MCv8QAGUcRv8CB+iyH8Dr/HQ9iJXa7TQlekJ7lWC7QtyecbBaOx4Mr0Jdctl9x/DCvVrccV2lvJ
CtXxb26XvBfjElyKy9CBy3EFrsRV6MRKXI1rcC1W4TpcjxuwGmvQhRtxE27Gd/2e27AFt+MOWP+6
QgVXqGBEFozI/9nKMm7UGX82Uyj+xblEad8zJrw16p9wIoeXu9LDrvLzQVOSff2v1B373l3Jvfhf
mZ3nvPOxpJJ/y/ABfDDOwvh+494slEEX4xJcisvQgctxBa7EVeiENbwrP+zKD7vyw678sCs/7MoP
u/LDrvywKz/syg+78sOu/LArP5zu9ns+jI/g77AWt+Cj+Nh/Iyt/iH/Bj7AVP8a/4if4Ke5CP36G
u/FzbMMv8G9xvfMa7sF2hPgV7sV9GMD92IFf4wEMoojf4EH8FkP4HX6Ph7ATu1SiqrgXkuzQp673
u/TJufbEc4iZqUzyjZvHx7/hUVkdd1kdh5VP4Hom5KK1qbf/xW/PLPdsF+Ky+M5JtDu4Jr5vz4vr
krsnw4HVQtBt/DyCR1HmbsmrehiP4FGU8Rgex7/jCezGkxjGU3gaf8Az+CNG8CxG8Ryexwt4EX/C
HryEMUTRsJn6sJn6cGZBVMg04WScglPRjNNwOs7AQpgbZBZBRqSurtoZ1ZtjzTTHmln1sO1HMP5t
mKVGwtKqUY+fg5Vw8qmyFXDyyXL8+cLeddv4N0zCZP0W341I7jMln3TkAxUpXtPFdx/2+YZJmNyH
3/fOwz7fJPmbrnf+q1XvX/etgTBzFtSpzGJI5My7kcM5kMyZ9+A8mBlklqAV78X7sBTWypll+AA+
iAuwHCvwIVyINlyE9riaxt8SqHyjemfySfwhyfcG9n4zILB3P0zExay+EvGZN0Ul/VLSLyX9UnI9
Sq5HyfUouR4l16PkepRcj5LrUTLyLorKwcrkU5gB42OH5x+/01Zx6uU7bXkpO4NXc6qeTh0saWfw
a07ViO1X7rzlq/ZwJjBz3Q8TMTV1cHIP8+Joh9e4IxnDyec83sN1MvemaIeV3hwrvTmcOnhCLjXD
69/h9e/w+nd4/Tu8/h1e/w6vf4fXv8Pr3+H17/D6d6SmGwG7mb+b+bvZvpvtu5ldZnaZ0WX2lhlZ
ZmSZkWVGlhlZZmSZkWVGlhlZZmSZkWVGlhlZZmSZkWVGlhlZZmSZkWVGlhlZZmSZkWVGlhlZZmSZ
kWVGlhlZZmSZkWVJtjJZF18kc8zzUvOSu4PxncGL43u7iD9VvDK5LuPfCozv/JkHV5uLVku26vjO
2N/y7lgDToAVecaKPPM2zIc1RObt3lv8SWgTY05izEn6oklfxH8pr3+fFGrSL00MiQ3OsWQni3NM
CZkSMiVkSpt+69JvXWwZ1XddjBmt3PWOPx2MP50d1p9drBnd5xPBNsaMMmaUMaP7fuqn37v0e5d+
79LvXfq9S7936fcu/d6l37v0e5d+79LvXfq9S7936fcu/d6l37v0e5d+79LvXfq9S7936fcu/d6l
37v0e5d+79LvXfq9S7936fcu5o4yd5S5o8wdZe4oc0eZO8rc0b/mE5HUhKrdle/mqIGu9V+sexW7
LqrYlXxykHzCGte/MLHrL9a+v6Fhf03ta/o/5FRvUv9eyaT48/YHkm8ixd9Cir+B9PL4i7/3EI89
7Up5NH5d+8fH35/n6N92/P0XGZ7Z+73k4OvRncFt8u/O6Ongbuk6YPuJaHfyHePm4Eve11fxde83
zwrzxsA8MLB+DqybA3PawFo5sB4OmBV4v4H3Engfgdc+oQaTEf8NhYOQxWyvz/wx829mMOaJGXPA
jGuV8bMZ1ypj1pTxfjPeY8b7qvF+aqRhzX7YHxNRDc9dcwAOwVS8BkfiKByH4yF/amRPjbpcY65e
Y65esxRytOYSXAo5WrMmFdTqk1p9UqtPavVJrf6YnEYGftfkSfBeJpsDWMd+vfKuDvXogODWKP4r
bGHwbdcp/s773WraQLQ6eChaGuyK6oNylAueSM2ckIpOmjAl/tf/Uugw89D9k3+9vfcvTtwdDU/Q
gy9/3+/O5OhteiY++oRa98Zod6rm5Z/5duXn7vKb707OiP8V+PjrOszzeHbu3paq/Pvw8X/xm2qv
2jm2pephPILYg1Htc3g+KjK/+GcZ+8no+uTdfcb2Z727L0QnsWIKK6YEX3Nu/Dr+wTzgux7Hr+UH
jv/I/n/1+KfRPUE/7vazP9dud/xe7f34daoheED7KB7D43DFg2fsf9b2nuiKCTU8nIwsZke7Mz8w
0/khg+9KTclsiwYy93o8EJ2UGYyuzxTxO49/77hRyKgpjJrCqCmZRz2W7ZnH8DiG/exTGPGzo46/
EJ1Uk47uqcnAFarJao/GdMzAzFRDzbGYhXke10N1qzlR2xjbFe2uWRZdUfMBXGz7ElyKNdFuVk1h
1RRWTWHVFFZNqX0huqf2RfwJezAW3TM5He2enIH3PHkSvO/UxJe/9/l1/ZiMTA5MiR5IHbD3W0P6
ZnXFvOF9zMszr4d5vfHfm/BTM5gTTjjS7GeynzipcuZaZxactdpZPc6axpF6bhZqS1F77TPRCbUj
Ue/kquiE1DL1uqBOF9TpgtpcUJsLyd+7uzXq28eNfLDR/q9JxH+w75u2v/OKgdyI/zpSgR/9gVVk
0B+/Clg9Btujbwf3aq2QgwcgMQNpGUjL4CnHnq0YHBgjE2xXW8kZ/RMOHB+DE6Z7fIx2ptTY68mP
5f7PsM3jX2jHfcm//Pep9vVl3JF+jvRzpJ8jIUdCjuQz3itH8jXSoEYa1BwafbtGktUcjemYgXmo
xwmOmfHUNGpPjoZrpEXNO3G+7daop+ZDWpWkpg0duBxmczU3ONalvSnqqZXwtdKvVsLXSvjascp3
0JJPrsdHv14dz4Wp+nBI381Jpf9SlmSeTC2pmYOVqbPj1JI7SWrJnp/ov1zwKef2YD1iMz6t3YDP
4fP4QlQbfFHbiy/5rV/WfiWuCrY3ar+WvJqlwT9qv4F/wjexCZvxrTin2PXP2gK+g+/62S3a23EH
vld5zd9HX+JJbfBD7b/gR9gaVx0/89OxUtCPu/2+n2vviWqC7WM7g19p7/X4Pu2AMni/7R22H9AO
eq7fjD0fDNl+KJoa7LR/l30Pax+1r2z7Me3jkNDBsP1Pec6ntSN4diz+K0B8G+ubUDP2/ITJOCCq
nXCgkTLFsUNtH4as/dOdc4ztmY7NHns+471lvK+M95TxXjLeS+bHUEEzP8FP40oY9WZ+pv0FVNWM
qppRVXlamzEWMqprxnjgbI6zucyDtlXazC6U/OzDeARmFxnjJWO8ZNSBjCrG3dqMcZMZddzsgcO1
mRejmsxYVFNThQD7jZVq9tdORDXSHmdQY3tyVFtzgPbAsedrpuAQ24f+B3dfAh9FkcVdVd1VzfQk
4QoQUEFB5RBR40FEvFAjIscgqBjUxXUEDRAPQCMa1IAGNS4GNa6Ca7wQgrrRxV2MGq/oDioBAgj4
oRzRgBhCGA4Rkfr+Vd0zmUkmCQHc/fbr+r3p6urqqtev3vu/V9XdycFNdgfsk0AdUdYFdU9C/mRQ
d+R7gHqCcP/2aSg7HXSGnGsno60zQWfh3NmgFLRzLs71Q/487M/H8WBcMxR1Rh8stscjPwE0EXS7
PNu+A3Qn6H6cm4ayB1DvoYPFcdvk3LifQVWg7aAdoF8PVsTtB/0GOgA6eLAivsXBffEeEMYw3gvC
OMZfory5tMlEaL5Cr+pwvPMSLOFlIJWypnnQ3gU4fhv0ThjJqoFkytMVxYyHvokRDwXdmIjAMi3Y
YSg2SpBF0KYKJ0aSn+vYoItGtHXQpiJoU4WOmT6Gt1Jx0xfYfwn6SuYhfsqDpqgYKi8qhkJ0DiQr
ApIVIZ7KgyY4MdUvuO5X5OvGVocaVwFd4QkZPGHsGGuoLLJHyM/tkaDRcp19I/aRsdbtsgIjWYGR
rLDvwrn7UQexF0azCMi3rlkxWPQa3ha5LDSfofvhNQ/CaxogDrL032bdGzG6G3RE+yrm+vMUXuH4
bZAa3Q+xVyOqvO03mAVsw3VVoKBcg5FaY7RGLNJLrsFobHBHYwP8yxaMyAbPVzj+GvSNtte9sNe9
0ZEtqBp1d4Cc0dhgnyLX2L1Bp4KGgoYjbrgbdA/oAbkmlkTI6TFncbPkau0Bnkf05ejouvC3l/92
v78sk581+A3mDpzbg/0BuQI6tQ53sBp3sBq6sw46sy78DWR7+VmD30Gm4Fw/7M/HfoxcgYhoRczv
Ik92ONVjMci1siyMwyCMwyCHez0Wg3Q8q6xFWUkruQ8WskxFKCHrwDgMwhgMgvwHwSKyYBFZnpVq
DLDfBtqt5TzI82tYO5dBO5e52rkMWrhMa6GrgagFtFJxD+mmY5MlkEi92Q7KYsx2QlblkWgvPGtB
PpZ1JaI80sK64riB2YvW9m71uPgWGNTAvOuQ504tEY20AkVy0hHHIU76IB+LGyduU08846FTi9m3
RP0lPcaqdLS22EZUZrfSkdJiu6NqR8mVJEM/FkM3FhMKvws+1bN96GZFKIf2qPOr/y+Ds4avjpla
G3LOqHbIJYhH4xCPxiEejUM8God4NA7angdtz0OLc6HteVpiZfDhy/W8I09LbhX2SnprsP8OElTS
2wwUVxKsRNlW0E86GnYkugPXu1KFdeTVlywkFCnZFojjPKBIFG0P/xaSbhecC0m3O/KIW2FBeWEp
n4X82aAUXHOunmPkaXQ9X9qwpDxYUh4sKQ+WlAdLytOjcTmtRkS+A7O3IPa7lN270XUgwjetcHVn
las/KspeG0OPIiPvbeQEjOkJkbqlI/FzZZbRD9bVlJ6FImYljfgmdK5LhJ+JjKwjdTAZdGZEtK0l
5OhlrKjZtZzPZBB6EYROBKEHQehAENgehA4EER8GMe5BjHsQ4x4Ma3EQ+T0yiPEMYjyDiIWCGLsg
xiyIMQtizILA7iCwOwjsDiK+CSK+CWL8ghi/IMYtiPEKYryCGK8gxiuI8QrqVfpizMaCmI39pJ9F
JUavkrjev4/rUUcAF0ZqrFoXvWrheM5Y3pF4geHVQMyl8FYVQMmlQL6l8CwVwORqYHI1PEwFPEwF
UG8pMfXfI3TXMhDLrnNWEfSMQdnhJmJErSq46x5OPfTTXi7T9bY4Vop726vP3KpXG46DpVbAUitg
qRWw1ApYqoqo52Emt86dyRWFYyAH2YtCcQ9mUOucGRTQ+TrkR2M/FvvwDCoinrgf5xwUL1IyILZa
2Qtzm0OOR68j0RszbGhvPCgBHKj5YyvFq16RmWt0QXkP1OmF41PUOMgszO+zwIHqnWF+n4X5fRbm
91l15m8M8/0scLAOHGBcZBbm81mYz2dhPp+F+XwWOdH1ZssiYr9JTuyHsraYwbZXHOjYbxk4mBSK
/dzYahK0IQ/akAdOlkEj8hqJrfLA0TI3tpoEjpbF1JTWoTWfKB2M1L/IHhrSNxP3UQN+a8BjDfqr
IZb+W/eIlXQ8U/t3nnVcQ1pDDnGQg9LRHNer5+De83Df1WgnB+3k4F5zcK85uNdq3GsO7ikH91SN
9nNwP9Xah3wO3RwNW7pefmP8Sf6sj3YaN8hdOCoDX6PlLzhXYdwo96AEto2jSuQ2EcsYJX820oiN
OrtxfiNKi40xqH+TXE04zu7UZ50zm1BajfbSiAf1t6CVH1C6AP2Nkntx9KzqAUfqiuvl9nBfPyEX
QPnt4OgOXDdJ/d8h5P6N3FqU34E+79Lle3X5duSqwNsE9D4RLWdAHrdjdO7EPU6ShcYUCdRG7gfk
vsP1GaQljl7A0UocTcAVd8hctPi2bk1d85OqhTu8Q/6o2zaMl6Fbr6LN10h3Qo355Hj9m6h+1X8o
Qr6Nzq8jrcUIEhAjiV+MIp3FQtJZ//fjF0D1/+txtv0OybQ/wv5j7J3/clzs/Hdj2OFMtVaF1nzE
sJ9CHLBMluL8XI0bawnFmWQiaDVJpjuInwax30X8xrmgfsSvn02rEqC/9yLi945DWXzE/xQupqZ8
mLaUq+kZsowOJj3ocOxvBj3o/h/AStlHcUAM9TdX0bPwDkDvXcmjaCmXFJLZaLuY+BnBvRKaICio
JfInk0zRl2SLVFIohpICMQz7T3AuQNZbHUAP0wTrUZpkPQZ6Evf9OCm0X6NJ9jzQfJJrLwAVkTS7
mOSC80RvKunsTaNJ3ptJmncs8eFOSry3kTRI/yNw8AnoU9BnoFLQ56AlJNk8jSSL9iC1Px10Jugs
0AhwNgn7xyDRt0kqpJ8K6fu9t+C6JMROyZBoNmSXDYlmQ37ZrAPJNi7EVUdjXBnOqv9vnUxM5Pyo
58eRX3FA4oSSJAV9QjKsh0GPkkzrMbTwGmgeaL5cay8AFcu13jSSSSxc0R+1UlErNep/XaeRVMJR
ko+SfJTkqxJIrjN0aT5aWgAqRgs88ki1iTrZ5BgyB9I9ADoIkiTRTAVdDhpIElWf4LK/iEd+gP7P
xuo/CyeK10kiuFb8+MCPD7JJh2zSIZt03IEPd+BDb2noTY1tmsuRH7akNGoORhTahF7T0Gsaek1T
moWe09BzGnpOQ8+56DkXPadBy3LRexp6T0Pvaeg9Db3novd89J4PzcpFr/noNR+9FqDXAvRagF7z
oUm+KE06tm7P4R7jiQ86nap7qtNDvdaLtOwLoLP9obOJ3oHoYRTI6TEVPar7LUSPqdpuM6FlmdCy
TGhZpv7/5x+TfETpZ8KazwadA+oLSgHBqukAEqCXgi4DpYIuBw0EXQEaDBpN+tObQWNRF3Kl6chP
BN0OugN0J+gu0CTQZNB9oCzQNNCDoK24ZhvoZ7II3AXAXYDWkHy6ExREfhdoN/J7SD5sYhGQJh9I
kw/bWGQsIYvMazBa14JGga4DpYFGg64H3UACJngxwYcJPkzwYU4B3Q092gC72get34/9byRg9SR+
qxfoVIxJEu46G3edjbvOxl1n466zcdfZuOts3HU2uM0Et/ngNh/c+sGtwsJ8cJsPbv3g1g9uFZf5
4DITnGSjx2z0lo3esoGTm/T/Vy8lJ1Ih0+nxoBNAXUHdQCeCTgKdDOoO6gHqCeolU+gpMsW8Qqab
g0BXggaDhoCGgoaBfKDhoKtAI0AjZbr4HlQJ2gLaKlPEXux/kemWBUoAtQN1AY2X6Yh7W5Jy3GU5
sLM/sLPctZVcsj6EvCwOo9EKlEjyYR/ZsI9scbKsEn3lZiDweiBwAAhcrv4yFrQ213oS8cTjZD20
NxfamxvGCEd786O019Hc/tDc/tDcAq2548kMcPAY6HGgWC7oCeT/AgImgqvO5EPkS0AfAV8+1gid
CYTOBEJnAqEzgdCZ5AuUBzRSZ5IvUfdr0FJQGWg5aDVoM3r7EftKjCIHbdW6mR8ebXeUIYEAJBCA
BAJhnVxC8uEBMk0gv5lDkvl+4ue/gQ5AzxjIBAlIx4N9W1B7+Kxu2HfXHiMTHiMTHiMTHiNTwP5E
P+wvwX4E7Q0fEBDXQdrQbQHdFjeAJoAmgjJAt4PuAN2JtibhusnITwHdDboHlAm6FzQVBHQXkJ2Y
BXoV9Bbo79B91LVbg54GPQN6m1QCIQL2P7S/qARSBOwlyEN2NmTgPQ8ebBhoBGik9maZcTMhO668
Fq7OdD1NhvY0x5BlWsb5kLEvwu613ATX9/tE+F5h1wJ2jXv2Iw7xRfC0P8xTsfakNVF8YUyjeFBe
0ed6RR/p5I6lgzMuvkSOJaxWjWcA4xmA9QbAU36E/JVsrgIfo9HyerS8CHwoHtaj9UUuD1dBNtkk
wfXqfter+12vHo6V0LpfeXZXTorHTM0jJc8BFxL0l9yvE18LRCcRX29ntvg7yuHPPb1JqudUku05
jfg8p4POIt0855D+RH2T0gO1+pLWh/q0G3OAlLpPvDEXSMFcIEWv4/j1PGFu3fkn6sxFndr4rLIB
hMjXHlTHaRolqoASNUCJ9UCJSte/FQApCiKQogBIUQCkKARSFLpIUegiRWcXKQoifNwiIIWPeNBb
KnpLdSOCtJjxyDGa39i8Km+fD159itdo7w7eav1vbav10SvVRS/H74Z7o1XEV69HJRUlkaFA3GGI
VB8lhegN0SloHqjW0/tcT+9Dbz0iJBCKKxwJXBPGyhBGRmJjLFxsAA81/v1MCptjLyEMjIl9dXEv
Nub5XcxLCtlck5h3KHjXOM4FInAuAPvNjYVtUTbtd21ajaUf0vBDGv5Q1O5G2RloLV9jXydoQKbr
QTOgYwWujqVpewiN/MPQf3f0XV1rXAPSoF91R//YwxkxeKWAlnyE1OtJR0km2gM4SNsqJtJFSyUK
9VzEy3QRL5O0In8F4inU2wf6FbQf9Bvod1kqngfNAc0FvQCaB3obs9IdoBpZ6h2t/iPvYbXwtjsP
imzpJMwJShCVlyAqL0FUXsLiqMlagRKpiXlBCaL0EkTpJZh9mhjFGkTrJZgX+DD77I+IvQRzgxLM
DUoQuZdgRGswmvutx4FFT2ovlopR3W/Pp6a9gHowosn2IpJoF1MPRrUAo5rrHQxtuxkjOxY0jiZg
VAsxb4vEm3FAeTUTT9PlyShPRnky9CGZXAHr98H6fbB+H6zfB+v34U58sHAfLNwHC/fBwn3aGy/H
PuSReX2vDCv2wYp9sGIfrNgHK/ZpT+3Bvi2oGygFpDz3JdjH8N6wXh+s1wfr9cF6fbBeH6zXB+v1
wXp9sFwfLNcHy/XBcn2wXB8s1wfL9cFqfbBaH6zWB6v1wWp9zY0GYMk+WLIPluyDJfu0zirppepf
PxkXEVsmwkYTY+CmHzFlIrDTD+z0Azv9wE4/sNOPmBI2BUKPDcSU2W5MmQrvmEopSXRxNRs2UwCb
KYDNFMBmCmAzJbCZEthMCWymMGKuUwhM9SOuTERcmdhAXBmIwFe/G1cmAmP9wFg/MNYPjPXXwdiE
Q8bYO9HWJOwbx1k/4spUxJWpTeBtuYso5ZGjFQNz/cQTiSQYr0I3ZspwY8tMja9c/7dyKrdQU+4M
rUmQdiG/G57DD4VdDsNsz402IqKM6Nl0bYQRmoskh+ciag2lvxux9dcRW3+McgZ63g37KVT4yyjJ
MM4CnQPqi5EcCboaNAmUBXoI5dmg6aAc0AJQIWghzr2B/ZugL0Ffgb4GLUV5GfbLQMtBK0DloJUk
g78I7yaA4f0g9RFkP+STL0ZhFrCQJFvTMYNTK0ZP4b6ehqyU9OuvHC3S6wD/AIq8r9eJFqk1gbAN
OStJa+xqnAPmuytK85FboMbHXX1RuJYKWaaGV9PUSlqa9kydSXxoBBpYywjgigCuCHgvkl/oqGYc
0K01eV6v/Dhj9zfkX9SrPbFaKEcL5WihHC2U6nG7HhGZaqU7tKCSzIafmaPj00qgew3QvQboXgNE
rwSi1wDRa4DoXYHmlfDL5UD0DCB6BhC9BoheCUSvBKLX6HXEHBVd0t7WY7QrkD0DyJ6hdfs12tWe
B5oPWgBS/nqRwmbaFei+2JuG/c24x7GgcfQcaNN6veq13lRz5tBqZjzyJ6uYELh3FfIFevXSdHtN
QK8J6DUNvSqL8qHXBPSaENVrMU1CbwnobRF6W4TektBbCemH+09rNA50sMoHKYUi1QbnueGZv8Ke
lvB+Kq6rG9P1BblWF/YOKl5z5qA+YIUP8X6JI7/w6oBjjc4cK4TuBe48qxYvVNydBi1TFor4LCLm
9pET3BFfj9Eux2iXY7TLcUfr4c+T4M+T4M+TlNwx+uUY/fIo+Q/AsSt7jHp55Opx7aoxaAFIyRrX
u6vFJeCiBPLuCi4C0L3Z8K5ztM5VgotKcFEJDnqDg97goLerf5XgoBIcJIGDWh1UshuAfK3+VVpZ
IEf3eivdi9C7buCoNzjqDQ3wu3rXGzJajogiG9z1BnffgrtycHeR1r1erowC4C4A7gLgLlAn3gmA
uwC4C7jxzn5wF3DjHR+4C4C7ALgLgLsAuIOsEO/kKEwI62oo9onU1QRwmgBO+7ucmuC0EJxmgtM2
rt4WhvW2CzjNBpdrwOUacLkGI1kZNZKXkzXgck3EM4Fy137XgLM1rpxCIxfbPh05JUXYaG89in10
BBDL+y+J8vDOqhElnZtaMdJrg7XePWRRyouXaO9d12v307OckIfVKzf6jkKe1Jm51HrTXZCj8p4n
a7k5VhCpf3UtIKR/kQik8M/v6l/IEipdJPLr5yiPk8wI7Iu2Cle2kGuJK9eESLkSzl6WZaxElnm2
gLaCflJ+hWwhJuYDBBF9BxJPOpJhpC25mqSTQWQKeYCMIQ8hbh1PVtA4Ukxb0dZkL02kHck+egy9
kBykQ+hw2o1eSyfSHvQe+hC9kE6nM+gg+iJdSAfTTXQLvY7+hDSG/kyr6E20mu6gN9Mg3UVvoXup
pOMYYxa9k3mZl97D4lk8zWQtWUt6L2vNWtOprC1rS+9j7Vg7ej/rwDrQLHYsO4FOY91YNzqDncRO
pg+zHqwXzWG9WTJ9jJ3FzqZ5LIWdR59i57ML6LPsInYxfY5dwi6hc9jl7Ao6l13JRtIX2TXsOrqA
Xc9uo2+y8Ww8fZ9NZBn0A3YHu4uWsMnsXvoJu59l0X+zh9h0uoTNYvn0a/Yce46uYi+wF+hq9iJ7
jX7D5rMF9Du2kL1JN7C/s3fpZraYLaY/sWJWQrexT9indAcrZUvoTraULaW/sBVsHd3H1iNRtpFt
wv1XsEpmsq3sJ9aCVSHZrBrJy3ayIItje5AS2AHDYC0NYQjWwbANmyUZ8UYb1tFoZ7RnXYwkoxM7
wTjW6MpONE4yTmKnGN2NU1hvo4/Rh51hnGv0Y8nGKOMmdpYxwZjCLjDmG/PZQKPMKGNXGMuNVWyQ
sd1syYaZbcyB7C7zavN6tsD8kzmevW1mmFNZiZlj5rCv+CX8EvY1T+U+tpRfxa9ja/n1/Aa2kY/h
N7HN/BY+kf3AJ/GpbDu/n09je/h0nsv28Vm8wGD8Zf6Kkchf40uM9ryMbzTO45X8F2Mo38/3G2P4
AUGNm4QpTGOcsITHuFV4RStjvGgjUow7xXmiv/FXcYEYYDwvLhcDjRfFIHGl8ZLA7Md4RaSJccbr
4jaxwHhXvCHeMfaKd8U/jd/Fe+IDQ4qPxWemIb4QX5iWWCKWmC3EV+Ir0yOWieWmLVaKVWacWCvW
mQnie/G92UpsFBvN1qJSbDfbiB1ip9lJ7BW/mseJA0KaJ1jMYuZJFrdamydbba225plWO6u9eZaV
ZHUyz7G6WKeZ51p9rfPNQdZl1rXmcOsGa6zpt261bjczrDutSebd1t3Wfea9VpY1zXzAmmE9Yj5k
PWo9Zs6wZll55iPWB9ZH5qPWJ9an5hNWwAqYs6yV1krzSWu1tdrMs9Zb683Z1kZro/mUtdnabD5t
/WBtMZ+xdrRINJ9r0aPF6eZHLc5vMcQMtLipRba5rsXLLfaZv3mYx8Ov8vT1DOFpnvGeSfxOzz88
/+BTPf/0/Ivf53nP8x7P8rzv+ZRP83zu+YI/4lni+ZrP9Cz3rOC5npWeDfwvngpPDZ/j2efZxxd4
DngO8EKP9Ei+0KY252/YHtvmb9vxdiL/h93e7sjftzvbXflHdnf7VF5qn26fzr+yk+0z+dd2X7sv
L7MvsC/ky+yL7Yv5CvsSexAvt4fYQ/m39nB7JF9vj7Kv4xvt0faNfLM9xr6ZV9pj7XF8mz3ezuRV
9oP2g3y/Pd2ewX+zH7Ef4b/buXYuP2jPsvO4tJ+2/yqYPcd+SVj2q/YCkWAvtN8QifZb9luivV1k
F4kO9jv2OyLJft9+X3S0P7Q/EZ3sUvsL0cVeYn8putpL7WXiRHuVvVp0t7+3N4iedoVdIU7x9vOm
it7egd4rxLneYd5rxXne67xp4lLv9d4/i1Qv5k1iiHec91YxLK4irkIMj/sp7mdxVdyvcQfE1fEt
4r3iuvhL4y/FTI/1nQu0Jf1KLnsZOJtG/uc3uSR67+TkTqRpsgg5RTMc0mdTjrjHZ0FPxygvBi2L
OJ6NNFkWyQH6aLvcoH6baLsqnNvs0NHZVLuyGlTRrKsw70Padsj1t8qv5FYl/eZziC1Rp1Bbm2VQ
fif3os0q+dNhtReWZoRU65X8Z7amR1LudfffRe0TVc4ZAbkyXLfqEO5AXVmFtDmyb1USzZFTEqs1
dWX01VFnd+rr9jr5UFnt2eheQjwfLbk3zHNTsg7f/6aovZLWJi2vKrlSfu/IH/ktuqeaRhpMDPUc
W876aKfcATvajNbWxrINnGlQMsCPaQ6KNWf7o/W7duz10Zg6Z++VnWR/ea/Ol+PO17r7MtJZ5UBl
Wrc21Y6DK4WiBrvsgRprkVY6dqDadErcqxX6zq3LY8RRKXp3vEGZPu4TcW5tWJ+bQC75kf7d5l6z
tvHah77p1pTWbW3WVXu1FMPjUIueddsO5eQS3VPN4fLptgMpyU/R83LQmkPBey3b5nozepjsHfXN
se2j540Pk4tm2TQQ5wv5mdzxR3HTYL+rj1I7y6P3kS3HjEhi6v5R4QSoIudFFPRAX8nYJ9erWRy1
7wFMWSj/qUvmyXehRSoynR063yDiV5FUF+vele+GS9eirZVAsdKImnsVX1G8hc4UIfIs1n01obXh
OGBzvZIB8kP8KhrskC4d3Hh7TW/yFtCtMcrLormVreSJmjo12eL2ULwk0+WXuO8vkZuMKye756+J
cc3O2hRV7kQ9RSq5JUEpZDakMU0Oj9GOGoHwmBw84JA8UZ/bqu+pWZj+n97qaqGsgI692rx5wlHh
Y12d412N1K2j0/JnZWXy5yZ6qI2fP1MktzSXxwbaXeLq7qpGa1WFfIgbuWyBnBc3q5/39O/hza06
60RcT/yBg6uavm+kx7JwzuF5trIkhSoN4UYd7jq6dHQ21ZIdg8tQfKM9gJzpHnV2zw6XXYAEo3Xe
RUp3r2LRuRiFaG1KRLnmGbjfuQFOkl2cmOlEnI7914k3rwm35nDeMurszDBqKy4G1Lmjl1RELV9q
oPd6mzu3qj7U+ofYalmjZ0Wd46nA6hvlVJ13LDGx1iKRa1WvhZAGNRlFR82tHDn21Umdm1Wn7sqo
o7LI+1DI3LxN7pK7Mf8OKi8ACjh0dDbFaeR6Ubi8oRl3PTnFmne7M3I1l9rgRN2y0GnRQaAY7VZp
T6Vmvt+FVh90bLElGiFR8jHKPpQ/RMtYnyuNnsOGZkfyX7HvJSYfNeGcWkM6SujsSKf5qAlvP0D9
6nxobaZ2xrtXy2Nv7GuP3lZ3vTA6RqqHGyt1NFJvdJroI3i43DXQXqOrdfV89zL5lHw9lh38sVvt
vMI93thI3TrcySnyUvWr867Xr/X+Kid/lD/Wa0XqXUM+5Yg3PfZF4aMU3ZOiHs4xotgUV59nwl7n
an8+F3u1spIuy1FahqjXjWc1bdZHo2P2VoaR9GF/B9q4yo0JrtGR8xQ189Bzj3Td8ja3tforNDNx
RbocjP1MjUKRazKz6/RXEb13cu4Kp2vharZ79Ga8DeHGka0DOF4aszl3BfMPWOf/L69ThDYHweFZ
6s5/bJ3+a1vd1Uq3VPmu/sqCoNmDnehMr7w6c0FnlTzGTDuqjdk6bpscjggnR5wrPirMx+o1ev66
W+5u+OyRtHwYW2ET7e/WdSJr9UDq3/SVMXsK0RFsh7CSubNuHRnU6QjilSOTs9zXyLk9+rciAjV3
1I3rGm27tOk6/89vfpeOcMMoNaXPO3WdiFph3ThsfT5iG2z2Jr9H2vCf7jWi/8OIqmW1TkeCdUcU
BaPnBtefHa7q4wZJ1mh36JuzvjG7qWoRW/9m1CXkPx6Dx9zqrar/f7A1tGaQH5Gv1L9HilMBl/Kb
qtj41lgM6VhKjCfW4TXG5rQdPSP472xHewZ8pJuLGDX6N1iPO0fOTT7vCq8XOWMSiTQdjoi7pnXj
KK2MRL4N4EQyh91SI54h9A5L7KjoaK7x1F2vQyy201mH0HPvF/XqzjQ5yp2lV8V61ua+o7LF/Q3z
rPJIxSqFa46Rz8oMOcdpL6oVNdNfpmfk2or1E76La1eU0NIvTd5NxBxWbjuUt27qYoaSuX4nZq07
v1Krahuc1qD3VXVHpLG5shwgO8kT1bNFNU/T75qE9j10rlqvWNR5c0gfNfxEU11ZijTFnQ/O0/dQ
qlc7Nzv6WfdJZqS+oMc+GI9rQm+pRD7J1CsijT9PqYpp/aHtj1tHcld/3HgjRWONQg9nHSldJuGu
Zjo1cYe6tta6/lrOVcivdeXvrlYqmTU471aSSdWyKJLZrpxn44q1+tmMfttHr1VN0NoReoYWNS9R
825cPRv15+uzketI+gm5lrPTtrsuV7s+p1eN/htyDq3lOnIeU2e97jFIeVTo+RKksdmVd5mrlVXy
3/oZ1BaiV1pC6/6gB2L2pnpK1bJQq3OOLJ5HK9+ipNRZ+VdPnOSEcDvhZ5XhNtbKF9TKIfbFagUn
8l3a2jcV3OMvo/ekme+eHr1NW+khvakVelLk7jtrC/4/umSeXCK/UW9/HdJ6nXo+CIlGvq2hZIa0
JOI95Rr4SWUXH8fgZB7srFSvJDX6FO5/YQu/qadW1krlmsbeY6qNBjVuFkM/l0edL5KnNrP3Ku0b
FJpsRntFigPdzufy80avK43k6FBX75wVv7raJnOaybPyyzNdJF7r5oub384h9hYZHTAkvXdH4swm
Lu4ROYfVOK3eF/rgMLhwtOQQ33Fz44kjjM3qvg2uEbnq0JBKboUOKSzYUv9JT0StUCw2CXo3WKN2
NKJ+3mx9rlT+TetzmXwGVExayR/lOqRNjV4XPetac4i9OZFonVVAmdccjl0dnu0i8Rdufg1pcj39
qGyTiNJqIk9x9ke8RcR7tZ4FaJ2OGCTdtf8+B1cd3Cony1PlSc3vQF4o47QdZinemzM/dt46iyrp
2BAHdevKdP3e2gD1zO6/uzXMQb33zDsd3HpwFezqGHkYbxnJsw8675yNJNANeWMzrkyqW3Iw2BAH
MeS89X9NzhFnWv0RnDSnt9gcHE3PKL9t5JzjdzZFfLWwU24PvaXR2DuLbo3ShqJH9Rf1ycPE1E9G
48hgYpGhZBgZSIaTh8ggMgPn7iM55DGgQi55AmWzSD6ZTv5K5pLHyevkLfIkKSIlOA6Qr3C8FGkh
WUG2kjfINqRSUoX0OdlHGfmCchpHVtCWtDVZR9vSC8l6eiUdSj3UR4fTeDqCTsC5DDqd9qQv0lfo
hXQeXUAvpZvoj3QgraaSDtHfTP9JfzN9i/5meqz+Znqc/mb6Vv3N9G36m+l09e0vHW9sNzvRiWZ3
sw+dY55hnk9fMS8yB9Ii9aUvfc/8k3k3/cTMNKfSdeZMcyZdr770pd/xVJ5Kv+cD+VC6gfu4j1by
q/goukV99Uur+U38JlrDb+FT6U79va/Fs/nfmM0L+CusO5/Hf2GnqK97WRY/wA+waVwKwh5Q3/iy
h9Q3vixbeIWXPSwSRAJ7RLQR7ViO6CA6sMfFceIkliu6iz7sGXGGOIu9IFJECntJfQfMXlbfAbNX
1XfAbIEYLq5iC0WauJG9KfxiHHtH3CZuY/8U48Ud7F9isribfSjuE0+zj8XzopB9K94Qb7CfxVvi
HValvhJmO8V74j22S7wvPmC7xcfiE7ZXfCY+Y/vUF8PsVxEQS9h+9cUwO6C+GGa/i1ViFZNirfje
IGKj2G5Y6itho53YI341ksQBixnHqe+DjROttlZ74wyro9XJOFt9GWz0VV8GGwOti62xxjD1TbAx
RX0TbGRZd1v3GA9a91n3GdlWlpVlTLceth4xZthIxiPqO1cjR33hasy08+1njcftOfZc4wm7wH7J
mGW/ar9q5Nkf2h8as+1P7E+Mp+xSu9R4Wn3PajxjL7WXGs+q71mNv6rvWY3n1fesxlxvP+95xgve
872XGS96r/BeYcz3DvMOMxZ4h3uHG4XeEd4RxkLv1d5rjTe813mvM/7uvd57g1FEGF0OCzFJCuFI
EAASh6VYpD1pgWQRj07q/QIvrEileKQEnVqRlkhtsG+F8tZIiThqg2vbInXSXx+2J+2QjsW+PTmX
dEDqR5KQjicdkfqjVidyATkG6SLUOpZ0JcchnYi5Yndw1YP0BA+9SB9wdRo5HW2cgVYstHE++LkA
1hxHroA1J5ArkVrBygejf2XnbWDnI9H/1eRGXPUnJIuMIX9GDzeTcWjjVpKOVsaTyeBkCslEW/eS
+9F7FnkAvT+IlAhMeAjXzkDqA7R4mJwEvMgBXzORepBHkXoCPx4jpwJBcpF/AqkXcORJlOSR2bjq
KaSe5GmkM8kzSGcBY/LJ2UCV58g55HmkoWQO0jlAnbmkL3BmPtpfQN5EX28hnQwMWoyS98gHaOdD
4NGpwKMlyH8JVOqlUelkoNJqlH9DNqDHjUjdySZSgR5/AFqdpdGqt0ars8k+Isk5lACz+gKzOOlD
BRWEUota0IUWtAUxgVoe0o7a1CaCeqmXtKBxQDcbCNaSxNNWFKNOWwPpWgPpMM40kSaiPhLpSNtT
jDftQDuQY2gSTSLH0Y60I+lMO9FOpAs9hh5DzqPH0mPJ+fQ4ehy5kHamnckJtAvtQrrR42lPcNKL
noJ+e9PTwckZNBmtnUnPQ0l/oKoNVB0MHobQIeBhKB0KHoCw+B1BrwEn19IxqH8TvQn1/0z94OEW
eht4SKcTwEMGvRs83EOnovf76DT0+wB9CP1m02xcO51Ox7Uv0gLI5CX6EulBX6avkFOB1K+TnnQ+
XUB6Aa83kYF0M60gF9Mf6I9EYXc1uYLuoDvIlbSG1pBBdCfdSQbTIA2ifBfdhfLddDfK99A9KN9L
f8FV++g+cin9lf5KUul+up9cRn+jv5HL6QF6AOW/099RfpAeRLmkklwO38DIAGYwg1zCTGYizxlH
XjCBvMUs5OE5yOnKc5AzlOdAHp4DeXgO5OE5iP6rEWSIsd3YR1KMX01CLJOajMSZhukh7U3bbEmS
zFZma3K82cbsgHyS2Yl0VT6GdIeP6Uv6mCnm+eQ0eJrL8JtqDiTnKH9DBPzNLaSdOdYcTzqYE8yJ
pIuZYU5CfrJ5NzkBfiiT9DPvNe8lZ5tTzamks/JJ5BTlk4ihfBJpD590BX4H8StJHB/MByM/hA8h
Fh/KhxKP8lWkP3zVVTg7go8grfhIfjXy1/BrUPNafi3yo/go0kl5MtJPeTJyIjzZLfgdy8eSvnwc
H0cS+K38VtKT38ZvQz6dpyM/no8nKXwCn4AWJvKJaC2D30WO55P4ZJRP4VPAw938HuLlmTwT/d7L
p6LO/fx+tJzFs9DyND4NZ7N5Nknk0/kMXPUwfwRX5fCZaPNR/hjqP85zybH8Cf4XtDyLz8JdP8mf
xNk8ngdOZvPZKHmKP4U2n+ZPo4Vn+DNoIZ8/h2uf58+TrnwOn4PyuXwu4fwF/gJpw//G/4Y7LeAF
uPYl/hJafpm/jDqv8Fdw7Tw+Dz2+zl/HtfP5fJQv4AtR8w3+Blp4k7+Nlt/h/0TNf/F/QcKL+WLc
xXv8I3D1Mf8Ud/oZ/wK9/JsvQcmXfCnuroyvwFXlfCXkvIqvQftr+XpyLv+ObwQnm/iP4KGSb8FI
beU/kQv4Nv4zuYhX8SrwsJ3vwN3V8J1oM8iDaGEX34UWdvPdaH8P34Me9/K9qPML/wW9IM4gfVSc
gV/JJemjXBPpoaIN0gvRRgvSU3iEB+WIOcjZKuYgfRFztMFvW5GIs+1EO3Kqij9Q5zhxHH47iy4o
OV4cT7qLE0RX1On2f4m7Fjibqv3/2+ucs/fZ68yMmTEGYx6M1xjzivGaMR7jEZNXQlIhuZqLVMjt
ikKuusggV3vv8xxXKldS/678JcntIZUrJElS6YUkV5Jk/t/1m6FRSHXrv9dnlt9Ze+219t5nrfX9
fo/fWktviNIa6Y1xtqneFCkZegZKaKY3g52pZyF/to72D9bSAnla6vnUUnEXpBfqhcjZXm8Pu4Pe
GWeL9WJqrXgM7Cv1K5Gzv94fKUP0IchzrX490ofqQ6mxYjYoE8wGTzRGH4O6xuq3Ig/4De7nTn06
7Bn6vch/nz4H5czV51O+vkBfhCd19CDKDOlh6qNH9Ajscv3vuJOl+lJc9ZD+EPIs0x9G+iP6I0h5
VH+UsvTl+nJqrtgSUlbqKxE/rj+Oulbpq3DtE/oTyP+k/iRq/Kf+T8Sr9dUkFJeiWopLId6gbyC3
/rz+PHkVo6JCxaioBhjVJqqpVmJBHvAqqqt4FaUqXkUN1UosiHfr71K0Wo+FNLUeC3K+r39EafrH
+idI+VT/lHT9M/0ASf2gfhBlHtI/R54v9CO49kv9S6R/pX+FWo7rXyP/Cf0b5D+lf4c8p/UKqgfC
olGaWsuFQFoND2I0EWpo4CDN8Bpe0g3TiKJaRrQRTQ2MGCMG6TWMGuQ2Yo1YijMQKFWtAINrE4wE
lFbLqIU8iUYirq1r1EUtSUYSrk0z0pBe30hHzoZGQ5TQyMhAyc2MbOTMMXLIa+QauSTBDttRDaPA
KEL5nY2uVNPoZvRAzp5GCdU1rjD6oMy+xlWUYgwwrkbtg43rUO/1xlAqNIYZw6nIuMEYQR2NG40b
Ue9IYxSeqNQoRc4/Gn/E2dHGaKSPMcbgfsYaN6OWccY4lHyLcQtKvs24DbWPN8bjqgnGBNQLVko5
ipUiBiulFmClf6FsY5Yxi3IUN0UMboq4TJZRMzlfgsnIBXIBbPBUxOCpOAueSi0VT6V8xVOpheKp
1EbxVKS8Il9BvFluRgrYKq4CW8VVYKuIwVYpB2y1gJr6Cn2FsIt8RZTh6+DrSNm+Tr5OSOnsK6aW
vi6+LpTv6+rrSq183XzdqI3itcgDXos84LW4CryWMsFrByH9at/VSAe7xVXX+a6jPr7rfdeDU6md
3hXHLWJ2G8dcNo5ZbA1mq3HMU+OYoXZghtqRGWoiM9TOzFC7MEPtxgw1iRlqCjPUImaoLmaoceCn
eShbcdM4cNISlD8QvDOOGWcHZpwdmXEmMuPswowziRlnCnNNCf15D3iuYpxZ4Jv3wlZcsxlzzVzm
mllQp3NR3/00D/YZrrkAZxciZDPjzGXGmc2Ms2UV43wQoTXzzrbMO69h3tmOeWchBRHyKISQS2F6
CPYyhFzmo6ngo4/CXg79mwf1+zjsVQh59ARCLj1Jq2E/DZ6aC566FvYzYKu5zFaz6DmE5rQBIZOe
h15uTi8hZNLLCIrLboL9CkJzMNrNyP8qQja9Rltgb0XIArt9AynbaDve8Q4ExXR3opa3EHJpF+2B
/S5Yby5Y7/s4+yFCNrjvfjz7R/QxGPAn4MEt6TPw4GZ0kHnwYYQ29AVCazpCX8E+Tl/DPkHf4v2c
Qiig7xDa0mkw5gJNTZ0v1AR4c6Hm0lzghYo9Z1Vjz9HMnmPBnn2wFWOOhfKPYcZcE7FiybHMkqOZ
JccyS45mlhzPLDmBWXItZsmdmCUXM0vuyiy5LrPkZLDk+mDGDbQGqDddy4Dd7CxvFuDNWSg5W8vB
gJgLDh2rtQCHNsGhW4LH52v5qLGV1g52AVh1NFg1dJTWAdw6VuukdaIorbPWGenFWjHFaF20LrC7
aj1hl2hXMPPuh7i/dhXiARoYmDYIzDsazPtqlDNYG4xyrtGuhz0ULDwWLHwEzo4EF48GF/8DnnSU
dhPYdil4ebw2Brw8QbtZu5lqg52Pw7Pfok2EfTuYei1m6sVg6neCx0/RpuANTAVrrwfWfjfew3Rw
92Tm7tHM3U1tpjYT9l+0ELVXa9WBtSu+fhXz9SuYr1/FfH0A8/VBzNcHMl+/mvn6AObrg5ivD2S+
fjXz9auYr/dhvt6P+Xpf5utXMl/vw3y9H/P1vszXr2S+3ov5em/m672Yr/dmvt6L+XpvESWiwM5j
RAy1ELEiFna8iIedIBJgJ4pE2LVFbUoTySKZdJEm0hA3EU0Q54pcqiPyRT7sQlEIe7AYTP3FjeJG
xCPFSPKIm8RNiMeJcYiniCmIy0QZtIQjHGqgVrujhiIiIojLRTk1FkvFUuopHhWPwn5CPIH4SfEk
zj4jnkH+Z8WzSHlePK/2FxT/oqbiRfEi4k1iE+I3xBuId4gdiHeKnZQh3hJvwd4ldlGJ+Fh8DPtT
8RniA+IANVEr4iE+Ko4i51fiK6SfEqeou8twGVRfrYVH6a5oVzTiGFcMNXLFueKohyvNlYaUDFcG
8mS6MpGe48pBilI1g10dXR0pzTXNNY3au2a6ZiG+zzUP8bOuZxErzVMEbVMbOkepmiR3PXc9aJhk
dxPKg8JpCjsDOifPnevOpebuPHceZULzXIb0FlA+eVA+7WAXuNvDLmIV1MHdAfqno7sjtYEi6gy7
2N0Vdnd3d2rnvhzqqMDd092TNHeJewC5oZQGUrR7EPSS1329+3qKcQ91D0XKMPcwinUPh4LyQUHd
BLvUPRr2GKipWKipsVBWN0NT1YamugX2re7xsCdAX9WCvppIdd23Q2XVY5XVsZrKSnDPdM9C+fe6
78WzKMXVzHO553KKg9bqQZJVVhzrqxqevp6+sJXK6uwZCGVVA8rqaqQoNdXRM8wzDIx8uGc4WLtS
VimsmopYL8WxXkpkvVTEesnFeimOlVIcq6M4z3TPdJSp1FERK6I41kKJrHlSWPMUsdqJY7WTxGqn
iNVOHOucjqxwElnhFHmWepaitIc8D+GsUjhJrHCKWNvEsZKJY60Sx/qkA+uTjqxPElmfdGZ90oX1
STfWJ0msT1JYgaRAe5yiLM93nu8o13Pac5ryWIHkovsKMGmXjvGfdUgWSKYB2ws1kstqJKtKjUTr
0dSONUkha5JcaJKaOJsAZZLNyiRPT9QTwciVPsnT6+h1wL/r6sng4qnQJ3nQJw1wVTpUSh6rlCxW
KbmsUjJZpeSySsmDSslEmc2hUvL0XD0PZSqtksdapbneSm+NMpViydLb6WjDrFsKoVvQhlm35LFu
KdC76F2Qp6veFaV107vhKS7XeyJPiV4CBXKFfgWu6q33Rko/vR9ipXCyWeG0Y4WTywonixVOnj5M
vxEpSufk6aV6KWyldpqx2sljtZOl36bfhmcZr49HORP0CbjbifpkpJ/RP39Bzln6X2HP1mfj7Bxo
oWxooftxP/P0Miii+dBFLat00d90MBzd0m08r9JIbVkjXcMaqR1rpELWSFlnNdIy5HkYSqmAlVIu
lNJy3KHSSLn6Y/pjyLMSGimLNVIha6S2+lP6U7iHp/WnoWfW6mspFuroGTL15/TnYG/UoZxZHXVi
dRStv6y/DJXyir4Z6UoXJejb9G1I2a5vh1JSGikZGmkXcu7WdyPeo+85q5Te09+jGNZLPtZLtarp
JQG99BnKPADV5GPVFAXVdAgpn0M7+aCdvkA5Sjv59KP6UdhKQUWfVVAnoOK+gY6K1k/q36IWpaZ8
rKaiWE3VwmDsgu023BTNaiq5mpqKZjXlYzVVt5qaimUdlVBNO0UbdYw6SFfaqW417RTN2snH2ika
2ikTqqm5kQU7GzrKyzoqmnWUz8gzLoPdwmiB+2lptILdxmgDuy00VTRrKh80VR/YSk3Fs5pKYDVV
i9VUJ1ZTxaymurKaqstqKtm4ybgJVylNlcCaqpg1Vd0qTXULFFQ0K6hk43bjdtiTjEmUZdxhTKZc
teInYqWdco0FxgLoqA3GBqpjbDQ2Iv7G+JZ0r9vrRtzL25vqeF/zfkD9vR+aGnnMMeYY0s2J5kTE
G8wN1Nh8wXyBGpovmS/BfsV8hXqam83NsLeb26mBuct8my43PzQ/Qp7D5hc4e8w8hvTj5nGkfG1+
jZzfmN9QA+mVJjWV0TKaSmScjKMsmSbTkNJUNkPcXGZThlq7E2fzZSukFEgoMdlL9qJ02Uf2oUby
Snkl9ZDXymupvhwub6Ducoy8GWcnyT8hfYqcgvS75F1IuVvejfzT5XSk3COhXORfoB5z5Ww5G/Fc
eT9ipSRbQz0uRvygtKAnHWjIXGjICGylIVvKlfJxKpRrJBQE9OR6xM/LfyF+Qb5MreQmuQka8lX5
KrWX2+V2pO+VexEflAdR5hfyCLWVX8ovqZBVZWtWlVm+9r72lMsasmWVhlTqsRWrxyxfPx9GMNaQ
zXz9ff1hX+UbgPSBvsFQktf6rqW2rCGvYQ1Z6BvmuwF5/uD7AzX3lfpKqXXUgajPqWHUF1FfIP4m
6hQ1jToddZqaqrVBKT0aB6WTSM5Ra4Om7mo0BRqr6BL/u/S3PJTfBvvLVbT5+RdXTPhxeVUrL30/
02VAxQKE28+s0lmtZlFxtOKNigk/f72jik/O4x8jKv7N3iLf+1wPYJ/r4qo/tTbnWQ/U/+58hMr/
q76odxCetcoL9f1ftHKguFDpvMLfxVZ9/G945Pyyo/b/V93/jbUZL8UrCO+9an3FM95elatZnj2/
6hfVfAmzxL7Pc7bmi/pa/pZHxZLfqR79Ryl3nlmbBm899heV+f75fBEr3+6Zd1yxqvqqNlXvWZxt
2+L3beUYL+89c18/d02PiqkVU6kj/n48p2JZVYln1m8aWt1bC5/O70eo0OPt8575NceAn86C0Vzw
PvfnP0S1+MLHj89fQs2/7KiwLt6vf9y2f6K8S1mf+PxXXtSH9SeOyrWSP6vYXlX32T6gnu2nSq70
6aru2XVpR0XVXDqehS/ov4Bopy9xnsTpExUNuOYJqFuc6ekVo/jMVPVvRcmP7rayZ4lzZtapvsTX
nv6Za1TwmliX9L5+yGgugZNc6BBn12reXtVmz3njPy6T6xbn5sDVl+gBfaaGsx6Gonrqrzou5XpR
bSQ5d1Sv1tbABn5Yljj7dz4EuISaz/GoFD/PP/bXHRjnv69LPf+EinPnq4rfciZR9bJ57tlP1sWj
3UVWva3Gwy663iN0yPdjsKhYx2/9h6Ny2jlXVK5O/u6Fxu5qPOz1i9V8Ntclz6dQc8yqrzdYxUm+
94ot/vE1PziiqnKW8ui8jEs70555RML3rvzfR5/bUyt6qZbJcwEDQP5/V2SzohpU8VZlvop6nO0n
sZLnA5w5KkfOX8kVKqIuIZOo9ta4b17gmzlndrdaJ+eiuyBcSn+u/nS/DTP6+cfvx05/VE/1mdO/
72pUl6LufyrPL/r2qrOTi733830rv4p7VvFzwepE/P5r/Z1BywutkFpx9Pzvk3+xWfYrsE/177e4
5nd/Mu+51525g19QczXEan6RbL/JgTdZVvm2L4wlPzpTOfquOvfzzzz+/35H+lUHY9/b3z99tfUb
/5ur+XasKvNsK/9NZpKeT/38sAVeClKd81svr659+y+5ncqnPWdHphJwrEEV915wrlav6m+Gf/9d
8P1cKOBEZUtVK+NeeAwT5/mtt7l6Jv67pNmev5zfVrafn6VtzhxCcUvc8zvgYq9XpVQv+cWLjmFC
zVjnXLdXvfNLHLkqxBnehGtZ6YD/8/OfPlQ19/pH2HNmVDz/r6CXqp8vck9vnauvLvn4daOQ4Dlg
lXdwQWVcNQPtxYvn+nkHj0BvfW9f+A5/mZb8rY/ffw0p1SZZh/xmv8ldsOZVld/+b7MWwEVrVi1D
nMUoQbexrxeJNFGfNLUfKrnY48stMkUmeUSWyK7y/vKKlqIVmaKdKKIo0VV0pTjRW/SmeNFX9KWa
4ipxFSWIweIaqiWuFddSbTFMjKQ64iZRSqlqb1Sqz75hDcR4MZ7SxUQxkRqKP4k/USMxWUylxmK6
mEnN2GcsWywQiylH7ZNK+ew51kpExBJqLZaKh6id2i2VCtVuqVQkHhePUyf2HOssnhL/pGKxVqyj
rmK9WE+Xs/9YD/Yf6yleEi9RidgkNtMVahdV6qN2UaW+Yo94lwaL98T7NER8KD6k69l/bKj4VByk
YeKwOEo3imPiKypln7HRosLlojFqF1W6lT3HbnNFuWrQeFecK54mqb1U6Q61lypNdiW7kmmqq4Er
ne5yNXU1o2mu5q7mdA97kc1U+3TSX9Q+nfRXtUMnzVE7dNJctTcn3a/25qR5am9OKjO+8LroAW+0
N4Ee8RZ5h9Mq72jvDNrhneMtp8+9T3pPaG61Q6d2hdnGvEG7Su3Qqd1llpkPaveqHTq1+WqHTm2h
2qFTe0Dt0Kn51Q6dWlDt0KmVqx06tb+rHTq1VWqHTm29+a15SnvOrJAe7Xm1N6e2Se3NqW1We3Nq
22SybKjtVHtzanvV3pzaR7KFzNc+lh1kZ+0ztR+n9rnaj1P7Su3HqX2t9uPUvlX7cWrfqf04hab2
4xQetR+nMNR+nKJW1IGogyJR/b+2qBOtR+siWf2/tkhRe16KBmipR7ilCvZKFKI+2qub26uX26vg
9upFe80in8hGq43iVhuNVtsSLVh5LgrRCi3YjRbcDjkLRCHOthftcbYIbTqH23QbbtNZ3KbbcZsu
YE/HtuIatOwcbtlt0LKHIc9wMQJnlQdkW/aA1NgDUhOlaPEubvEGt3iNW7zBLV5yi89Gi5+MvnSn
uLPKV1ITU9EHXOgD05FzhrgHeWaiP1T6UOahPyxA/1koFqKPPSAeoBpikVhEieJv4m/oY4vRW+pz
b6nDvSWZ/Szj2c8yVSxBz2nJ3pYtxEPoPzXQfx5BrDwvk9CL/oF4BfpSMvelBO5L8dyXEtGX1qLM
Z9CjkrhHteQelcw9Kp17VD57ZDYSr4hX0D83o3c1597VuMpHc5vYRhliu9he5a/ZULwp3kSK8trM
rOa12Uq8jd7YTO1pjPhd9Mkm6JPvId6HntmUe2Y+98yG7NnZSBxA/0xXuxyjri/EEeT8UnyJkpWX
ZyZ67DGkfO/rmStAU6imi1xEMS7NpVEtl3AJqu3CQQ24P/OuyFQP/TmKYtkfNI79QVNcNdDD09gr
9DJXPPp5DPp5LcSJ6O110dvrIK6LPl+P+3xN7vO10OeboswM9Py63PPTuOfXQ89fR1HGs8az5DXW
G+thP4exwMtjQTSPBVk8FmTxWGDwWGBgLNiP+COMCNk8IggeEdwYEbqS19vN24183u7e3hTt7YMx
QucxIofHiDYYI/6Xsrxrvc9QO+8676tUwL5Bbb0fek+QpsYOcmHs6ECG2dHsRNLsbPambLOPeQN7
Dk0goUYT0jGarKYa5tPm05SkxhRKwJjyDNUx15nrqL75rLkB9vPm88iz0dyIsy+aL1I8+xilso9R
C3Oz+RrObjW3In7DfAP5t5tvwVb+RnnmbvMdSjT3mO9SsrnX3Iuz75nvoeQPzY+R8on5GbU0D5gH
kP+geRDlHzIPwf7c/By28lJqYR4xjyAFoxjK+db8lpqo3YapqdptmFrzouXNpSbd1Fh6pIeaYXQz
qaHEQRnsw9RKxshYpCtPpgwZL2tSI5kgE3Atxj6kJ8sUSpepMg3p9WUDairTZTrONpQNUXJTmVnl
85SpRkbkV55PrWS+zMdVHWQHipEdZUeqKzvJThSrdjCmmhgxu1Bt2VV2pQaym+wBu6fsiZwlsgRn
e8veFMeeUinsKXWZ7C8H4OxgORjxNfIa5MfYClv5TuXKEfJGqoURdhTSb5I3ocwxchzVk7fI2yhN
jpfjkXOCnICSJ8qJsG+Xt8NWvlaXyTvkHUjBiExqRD5AmVEHow5SMsblb2CfVF5HanQmE6Ozl9Ki
zWgf1VNjNGWQ0PLY/70V+79nsf97K/Z/b83+723Z/70N+7+3Y//31uz/3pb939uw/3s79n9vxf7v
eez/3oL93y9j//eW7P+ex/7vLdj//TL2f2/J/u/Z7P+ew/7v2ez/nsP+79ns/57Dvu3mOSii8MOo
hh/GWabTEiNvJWYob3cvI0QjUSyKKY1xIldcLi7HmKvQIp3RopDRoj2jRT6jRSMxRAxBfoUZueI6
cR3yXy+GggEp/Ehn/GjP+JFfhR9/EH8ABlRHkdFidBWW6GKsuBl2JaLcIm6FrXBFFxOAKy7GlYaM
KO5zEOVuMa0KV3TGlYaMK27GlSZiPhClEktqMJYkigeBIjXYZz9a+EUAtkKUOBESYdgKV+IYV2oy
rjRjXMmowpVlYhnQ9+Gz6FJTLAe61BCPAV1qAF1WIVae/jUZY+KAMU8j5X+BMTXY6z9arAPS1GDf
/5qMN83Ec+I5pCjUiWPUSeF5ACmMOimMOpV4kyS2iC1UV2wVW2Er7Elh7Eli1Elh1Eli1Ell1Elh
1MkUu8VucFWFN/XE+0CaJLFf7Ef8kfgIyKfwJoXxJoVnEiTzTIJkRp0koM4XqPEIsCeJsacOY08q
Y08SY08KY09j8R2wpxJ1Yhh1arncwJsYnn8Q5fK6TNgKe2JdPmBPDGNPLGNPPGNPAmNP0yrsqemq
SdKVwAhUG9gT40oC9sQAe1IQq1kLsUCgRrCbAIFieAZDlKsZcCiG5zHEMxoluLJcWUhRmBTLcxoK
eE6DabQ2WpOLUcpgfDLYz9TLfqZeY5uxjdKNHcYOxPuM90k3PjQ+RKyQqaHxqfEprj1oHER82DiM
WPmlCvZLFeyX6vUO9g4mj/cGL9CFUaqR9x7vbEpjrMr1LvEuofrev3tXUAPvY97HYK/0PgFbYVg6
Y1ghY1h7xrB89m9VGNa6CsN0xjAXY1hDYNhocrP3q2DvV4VkZUA1y7QQV+LZGnMN4rUm2iHjWSKQ
bD1s5SdbE3j2L9jKWzaOkawmI1kGe8vWNF8FnvnM183Xz0G1RHObuQ228qWNNneYb8Leae5EzrfO
ol0T8x2gXQ3GuUTzffMD2MrfNo5xrhnjnA84pxBOYVsGe+BGm1+ZXyFF+eHGsR9uTfbDjTZPmieB
yqfN04gV2imcE5Qk3UC7ekA7A7by1U1htEtitMsE2sXArgHMq80411zWkrWQkijBbGRtWQd2XSBf
bfbqTWG0ay4byyZIVx6+KYx2qTJH5iBPLjAviTEvk719U2Rb2RbltJPtkK48f1NkoSyEXSSLkF6J
iAoLY2SxLEassLAWULA77J7yCsTKUziW8S+e8a+pvAr4J+VAOfAcFKwlh8ghsJUfcZS8Tl4Peyhw
UTIuNpY3AhdjGBdryT/K0bCVl3Es42IC46IELipEVFjYlP2Oo+RUORUpyvs4lr2P49n7OIq9cePY
GzeOvXFT2Bs3hb1xY9kbNza6S3QXqsHomBTdLbobxZDm3ureSRpFUbya4Lc4Swx98JiVaQ2w1tpt
7UH2NHu1vcm6y3E7yc5IZ4azyB7nRKy8B09aqVaeNQAUv4V9HXItRY4Cp7sz0h4XLAj2D44Ozgiu
CO4JfhrSQ5mhHqEBoVGh+aFAaG1of2ht2BuuH84Ktw33Cw8KXxceEVyDa3rhmvuCK0J1Qnmh4tDY
0B2h8aGXQtsqc4YCwXmhU+FZ/qf8a+1D/uH+Df6X/Nv8u+xp/r3+/f4D/iP+4/5Tzs6ACHhV/eHl
4dWofw1qP476BwS7q9qDe1B/ILQ/uBll7gjvRt37wh8/eCyQZa0MlFgDAv0CgwKlVlRgVsCyNtjT
Aqvs1VZmYKMTscfZCwOHAqeD7mBsMDGYHMwI5vhPBboG1jnuwMLA0sA+5N4RzLfWBj4OStzBSLyD
kZGM4IpITvCFSPdI/8gk3IEeWhuJoP7R4azInnI9fF15anlmeevy9uXF5T3K48sHlA8prxNJj3wQ
2Rqur95bZF7kycin5Y0iJ0Nry8meZZeGNgS7O+nhrAcPW2S9FFqC8IgdYxXbc639Vh1rpr3KSXQy
nBX4dlZaS5z11lh8k9MQq29rhNPJbmJvsdo7bnzeZQ23s/CcO5xl1l5HWrqTb+U591l9rKesA87O
4NDgyPC04JTgrcF5wUVBB2/zteB6fKfHgidD7UOtQ8NDi/kb3RU6Ek4KT+S3mhUuCXcNl+Ib3Rrc
GZ4cXBaaHXoqeDi0NhgJNQodD74QWhnaGx6H76ZTcFJoVLhFiIKDwx2C3YNPhvqERTghPCI8N7ww
bIVDofhwk9BdoZmhA+GYUFRoCMqcEvwglIr7G2vdZQ2xvXaCXWJPxNPd5R/i5KB9TrIHOfOsQCDG
uiuQZC9Hy9jvnxlIUH+B+si3IdDE/xruZXRwSvho+ATawKrwpvDp8MaIOyLDW/zDw0vD68KHAuOC
6YGSQIdAW24RE/09Aura5YHVzkgrD+1hhmoRgS2ByYETaIXb8O8sfw/kOIp2k4q7C6A1tPDPRJ7d
gesCI+wtgZBzOIB+FJgb6VUeH9ofSYzERvJDFBkcGRkZHbk14kTWRDZH1gdHR/bgDYwoj4ocK88L
dyjvE3kh8kIoMzI0MiWyLBIpz4wsCvbC97AV731mJLm8Tnl8cEX58EhBpFPkvsiKyM7I4eD6yAwr
yopHa2htjbLGW7Ot+dZi9U37o5zN1hF/qt3P7mBP9hf7Bzhbrb32aXu3/bF91D/KcdsnnP6OYw9C
O3jSClg9nE+tmf54fx1clecMdQZbx61Tzh7nA6uRc9g55pz0k1+3xtv1/Znoia397f09/H2cNbZl
L7RDeP+zMTJMcyb5h1vb/GP9o2zLGe2/w3+Xf6Z/vvOCf7E/4F+Cs4/4Vzq32l3tUnujvc8+5MQ6
vZw11mu4ppGdZK/zj3emWHV4NFrNI9EMexxaL+EJh6AdzLbusPrge3kksCoSwRimeTQStITnkROv
WaTxmkWCZ5C7qIwC5KZl9DBGvMcQEmgNQi2ejZ3Ic69r05sIdWgvQl1eTSiJPkGoRwcRkulzhBT6
GiGVZ0KnabqWRvW1ZlomFUBz5FF7nnNcpBVqhdSB5xN35NnDnbS+Wl8q1q7U+lMXbZg2jLrxWj3d
tVKtlC7XxmpjqYc2SZtEPbUZ2kwq0R7THqPezPb7iE6iE/Vlzt+POf+V4Pw9qL8oEVfQADD/ATRI
INBQ5vzDwOHvpOHMUe8AR32V/gxeupOmgWd+QLOZVf4NfPITWsy/VljiP+I/5IAlHie/OOFyU9Cl
u+rRcleKqz5tcDV0NaQXXI1djelF8LdMeglsLZdecbd1t6XX3Z3cnWiLe5R7FP3bPc49jra6/+ye
TG+4p7in0nb3NPc0etM9030v7eQ5hbt5NuE7EEMu2sMrmezVpe6jfZBycfQBr1XyCc//+1RvpDei
z/Q2ehs6wPP2DupFehEd0rvq3elzvYfem47offX+dFwfqA+kk/o8fR59q6/QH6NT+ip9F51Ws8q0
pmpWmZahZoxpzdQsMS1TzQ/TmquZYVqWfkw/pmWr1TO0HMNt6FqumuOltTBijFStpYGgdTWuNK7U
uhljjdu17safjD9p/Yw7jSnalcbdxt3aVcZ0Y4Y2wJhp3KcNMuYY87VrjVeN17QbjC3Gm9qNxlvG
Lm2MsdvYrd1s7DH2aOOM94yPtFvATg9rk7yLvYu1qd5vvN9od5mpZqp2tznCHKFNM09KoU0HX4rV
Zivlrz0ILpSk2VD7qVoYar++FpGNZCOtXGbIDG0J2E6u9nd5mWypLZWt5WDtYTCQYdpmKPAR2lY5
Uo7U3pClslTbJsfKsdp2pbq1HdDbZdqbcqFcqB2Ri6Vf+1ICwrSvZVgu1U7Ih+XD2mm5XP5Dq5CP
yVVCk0/Jp4RHrpb/K3T5jFwnpFr1QkTJl+XLIlq+Lj8XMfILeVTkymPypGip5iSJAl8HX3dR6Ovh
6yG6+kp8fUQ3NetIlPgG+q4RV/iu9Q0T/Xw3+EaKgb5RvlHiGl+p749iCLhKN+hUTfSHplQsJZ08
RPfP+uGfVttaZW18YKi12zpkx87Pt/PL1i0otkc+MMVeZEfsrfZJe6uTWrbFyXOKnSHOcGeUM9a5
A9eswzWbrEMLetj97aHIPcW+1f7AHoycrZ1ie5m1yYl3FquyF/RwHrEOOXfY+c5LZevskdZqVfKi
sSh3l33SOo2S9y5ch3IPOEesVc5KZ0PZ0gWtnf1+gat3WBv9Wf4S65C/n3XCX4pPc3F1fuW1Dwx1
8vwnFsU7owKJgfRAfqAg0CnQPdArMNjaFBjp7+rf7d9StkU9j9/yL/XvCyT7j9o7F7S299i40l5v
v2BvtrZYO5z5qGm3temB7tY+66j9qbXRjrXT7Qx7sLXDHmk7eA877cOO7mQ6M/l+85wBTh9nvHOX
7balM3tRD+tj+z57sL3CftJOtrfy5+52JyfKOoE6juF9HVI12JOc9nYO3kwPazXedoFTx2nkjMXT
zLBjHXJS7QJ7tHq3diLuZY89z16DuJe984Gh/hi/15/g7EW+bf4k5zV/fX+T+flOwHnKOe4scdY6
p/ylznz/Rn9bu8A/CG9qnH+af7J/Fj4t96/zr0YJO5yx/tMBt/9QICOQE+jvX+VfVbbOP9E/15lt
5wfS7UXWusBQPM9Ofwt/h0BsQAZGB271X+cf4V/oD/k3+T+2Ns5f4+wCGnjAfLcSube5t4EF73Dv
IOHeCS7scu9y7wJCCOqIOAUY0pQygAA5CMm8vkkKtUNIxfmOlEY9qCfVp94I6dSX+lFDuh6hMa+3
14RGITSl0QgZNBGhGU2jGZSprdBWULZIFm0oR7QTBVTCv/z3EmXiQYz3tliJsXyV+B8aK1aL1XSr
WCPW0G3iGfEsjRfPiY10O0SUpD+7493xNJnnvd/pnu6+h6Z4unhG092eSZ5J9LDnz54/0yOeKZ6p
9Kjnbs90+gevvLXSs8DzAD3OK2w96fF7Hqb/8azzrKMNniOeb+h5/W39bXpVf0d/h17T39Xfpdf1
I/oR2qL/R/8P/dt4Bsp7q/Ev4xXayRr6XW+GN4P2snp+jxXtPnOWOYveZ0X7ARTtVvoQ6vMtOm3u
NndrbnOPuUfzmPvMfZpu7jf3a4b67VTzmp+b32im0ihaInp8d9GHe3yi+v/Bvy5Sf1rt+zfNmWQt
AbPdNm/ovGXW8blRZQPmLgZLaAFGMwhccJAVmDO07Aj4x3LwiVX3N5nnvn8T+M8ScNpt1qm5UeCM
SdbeeRnIXVqVs4P1FHjKOlX24oVQO9vmua3j9qC5UXMX37+JSz6E3OvsidZe5D/tSHDsWCcR57aA
Oe2zj4KTZKCWwJxJc/o7Bda2+THWLqeXPcs6ZbdQJYFRTbSWlB2Z39WJxbUvOJudnQjgUWXFzjK7
1Dk8Z7Azz1k2Z6h6HmcS+OUK3NMWXLke6soqO2KtLNuPp15sBcqKrUf4adbC1u0R1i5+Ewfm7FT3
C5ak3sM4e7I9F2wJ94s7XmqHrAN4pv3zp5WttDZYL9n1oQK62iVlffC+1GcvdBxKKtu/uAT5tuFZ
lqhrrSNzJtkL8Wnb/7H39WFtZPe5M6ORhBXWocShhCXEpVzqEkoJIcRLiENZQghhiUu5rtehxCV8
CF2WlfVlrxAjIUuj+ZI0GmlGglDielkvYYnjEi5hKZcSSilxHEJcr0sIIQ5hCaEu4RJKqS/X6e/M
/pE+97n/3nvb++zOc/AOOmfmd34fZ973fQ6acAPMZiCYC7PJgMMG2PBQUKDvcKhJyErc68vvOw8/
T8L1bqr2Dfc9DTWBD7P6tgCZF/cd9c2JUn8mcJAH/dn9teGKPhtfDyyjHDxV39/URwOCO+xn+m/0
x5CngrnBXPDUJHhquX8bfBMSkgF9HvdNQ6+74FUR7N3su8DXh5qCGRDnxf6N/ipF6jf3u4KnAbuu
9Jv6+yF/CKjslXdr+f9tLevMST5Uy/gY1gGQfPHd9u+7EU3MYcAsjzCH8r4sMAN8FnNNnqOXlHLm
WHEoF+U7ioOxwKeDqJc4z+0qJDOgGKBHlVLLHMtCXIkPx2fj9+OHidOJ/ERlojHRlXAmPAkpMRhX
EnOAU6YTW4l9QBaGvpT4cF9aXyaMuQljVmBMDfQ3Qm864Ykj9KX2hJErgKQGOcZ/GE+Op4rz9GJg
jPYwA+xS1OE/ps/H02mPciNgjmf11cI16/suxg/7MhOVcI3GhLOvCd29rwXOKsGCk4CRCvrM0M/R
54otyCPxQmhlzCZzzNridfGG6BgzIAt8FsxxX3HId5hj7mGcgoOTa/h0Zie2KQ3GS+Jt9BL0voxm
zQzAvUXmMG6J+2A2U3DtWN8tsGE0kdQ3CRjqIVgA1vQdJObis4n9/uT+9PgwIKYYIKgcwGWFgDrL
+h4C8rwB1j2BeYPf+tbA3v3+rH5dXOlPZQaYY5jBkVKe2PfvyBI7AX6FQ5yXhziH/IDPkgUlRSlV
ylGM5Gm6mbZJNcwhxCcG5yPwabn8WMkMmOklxkLnS+fEUuaakq2E5CWlOMBAjC2Ki5uU59hF5UZ8
PD7VVxC/F1+AuKzHN+PHiZEEATEtSpxNNCOvJhJqRCcART/qy0ZeBcvJxFNAn5mJU4mMvjPxvYSQ
GErkg0d2EhcAqSbBqGmI9yH8ZhaivJ84F7+dOIoPQORt8YHECGRDMaDI8r4qmPljlAUQr2n4fyeM
upfITZznJqUaqYY1yo/kLfkp8rw8p8SUcm400CINKl6pkp6L57B34nl8VtTBbXOZqNETyHu0kV5E
d4ZZQYMcqIeIeBMSYN9Qnyme2lebqOxzxav5LD6LNYa7UE6wtlg1txYdk/NlIVr+TkagnIh3cg/p
Ca42thM1QxZcio7Fr8Ub5EGwrpIZoM+DhXfYB/EKOOqiY/SivB8vjN3um+kvAf/EAJOjzAD8Dm0Z
7rrRd9C3jTIDPJAGmYH1xeK347N9u327iUY1fyqhVywhxW9CHE6B3THoMQw9qwHbj8EBuYLGJ4i+
h8w1qNAE2HoHPDXHzkVdEOlDZZKroi8od8FrUNuBGWVb6VcKlAJ5jsumndI5eol2MskKozyBCrdI
lYF+OolOUmaUeciLh0oTVP+qvMralFtyrjLqh1phKGVMnhDnJWfUAT3WlA05wc7FRHYwaopx0iD4
fMB/SM8pXmXXv6O0KKaAWTlQssE356D/aEyEesbiOsUsH8WSlTTWqJxhdpR6uP+KvKgsy1vR0lgO
t4ZWo+gY5DdaiVA9WmQJfjeizs7ITTLHUqUs9B3A0/4ifge/g2H4OD6O4fgkPokR+DQ+jWnwb+Hf
wkj8b/C/wbT4t/FvYzr8u/h3MT3+ffz7WBL+Fv4WdgL/Af4DzIA/wh9h7yFogsaSCYZgsGc0RZoi
7KRmVbOKvVezplnDUjTrmnXsNzSPNI+wVM2GZgN7n2ZTs4md0mxptrD3a7Y121iaZkezg/0m+Sr5
KpZOvka+hn2AfJ18Hcsgv0p+FXuWfIN8A8skv0Z+Dfsg+RfkX2BZ5DfIb2AfIt8k38ROkz8if4T9
Fvlj8sdYNvkT8ifYb5M/JX+K5ZBvk29j/4n8GfkzLJd8TD7GfofcJXexM+QeuYf9LvlP5D9heeQ/
k/+MfZj8F/JfsHzyV+SvsN/Twn9YgTZVm4r9vvaU9hRWqE3TpmEf0aZr07EibYY2A/uoNlObiRVr
s7RZ2Me0p7WnsRJttjYb+7g2R5uDndXmanOx57RntGewUm2eNg/7hDZfm4+VaQu0BdgntR/RfgQ7
p/2o9qPYp7Qf034MK9d+XPtx7A+0z2mfwyq0n9B+Ante+0ntJ7FKbbm2HPu0XtJLWJU+po9hn9Er
egWr1if0Ceyz+n79l7Ea/Z/p/wyr1X9F/xXsBf2f6/8cq9O/qn8V+7z+Nf1r2Hn96/pR7A/1t/Vv
Yn+c/P3k72NfSv675L/DWpLfSn4La03+++S/x9qSf5D8A6w9+YfJP8SM7yqC/xtFcAF7hVgkvoN1
q7qgW9UFWVUXjKm6oKzqgnHil8Qh1veuIviuIvjvSRHUdekcv9YHXrGhpvlwWAnfDA+Hb1M1PcfM
QXjT7RCTeK94OrzJ+nqyxGYh3T0pdjFr3IjoYbaZMXcoPBAeD++IBPQ61T3B+sQasSs83pMlLVCE
p0wc8hRGT7pviEt8sb8+eqHntjAclaJ3+OLoorgYXonuR4+iT2Np0ro4Ig65b0h14oOeElESH4lH
rhj0pd1NkWy5Wr5ECX5vT3os5j7gzvse+NPCh7Io+eRhqVBecBW4zcJ9+Z4rRV4RR+R1T6Hc0NPA
5sk+0Rgelzl5WL4t3O9pkO53T3efCyvUaoThTnowsH4zcgvNMTIaGQtvCsnMQc+4kC5gYpenkL3E
bEfusqlhxUVGbrgPIjOR+ciyOBJZ4/ZjTGQjVhALeUqo/VgsQkbqY/2xW8Kw+Dg25urvHqQtscnI
dmwmshubR9a7i93lPemuZe68fFN85E+T65D11COwH2bAzwj33S53kzgi1MnHYUXSUatSsgeTUsP3
pSxJJ+Ug696xLTwsXZLaPA3cRPdj7rTkkzg4F6H/QPdj6Wak1n2XzXJPuh3MhlQmXWY72QrJIi0w
y+FjvthT6DuK1sQ2/A97bscO+F1hODIflTxlVJGsk8ajR3KqnC7nxJblPLlQLpGSI/1yGV8s5MkV
4lJsV8bcN9zlwrC7yTUvLkVPiotyjlwN/r+kJPWkK6eU00q+vKmclUWY5TBHSIWUINxXGpVmcYTf
VYxKF/U0MgmRHFRsfL1ykjotXXKbfQ/cu0yxcl5okIfZBrFStEkD9ICnTRh2bUgrgXPiRPSUPCDf
9Fz2T4o0nwLZOc4fhKdc5e41dwHk6Lq7FEVQzBXPieepoZ688AqKn/uu6OTXIMIrwn1mJjwbXqDv
Qwbni0VUEjpzXwwfio3h++IFyPnh7kdiV0AK32TWwopoZMDbvJf3urJ7KsSTwjW+KrwnCnAkhMs9
A1Fb9Gx0hEnjiyP1USGS2b3lwWKGWFo0qftIvBMxRNI8WeCdO7EUapqdjZRHJzxl0XxPmb8+Rrpd
0aKIyZ0dMfc0wPUg46EO9qV7PZfEVf6htMlekhT+onxZKoyZ5TZ3Wk9DQPJv99yk9t0z3EnZIlM9
ebFtWYGMHg8IPdW8CXJnWL7fsyMNeArdBmY5sCV3hu+Fj8UMKkM8S1W+cxY+lme7H7ln5GruTs9h
d6N8TXzseijX8QXyulTIrosZTJrbHB6PVMlTTFrEAPeO0WWiJG2KQ/6YJ8s3IU6Lc9HTruxojTtF
3Io2C8PSjrjYs8Ms81XSMesLD6PY8CmewkiIu8MtRiYjD8Ukbl8Y7smCGrkbW46N8U3iBGpQGQ9j
o5GD2I3IEwmThylBbkPN7ZI32cu0Rd5TCPkw4orE/P2xUKRc3uHORryRfm4a8rxBSpbSIRf2uSJX
tlQh1UnVUqfUyZ2SKElhp9wOqUQqDA8IdeEVyP1rUF+3e8alPP4MdTKy7C7oKXORUYlO9h35H8a2
pSlpky9nOTlZTu62yVnuG0zIXy+te7KkY2FYgPVLmo2tQXvSs8lSvgk/I18KH8PDJQNqJVUp6llg
0pQa6qS8Lq8rF6Jd7E0lw/dAbnAfuA3ycMwhtEmUkqucUyrdy3K6e6b7vD8m3ecPPFkiDZbvSHvi
dHdjLDN6TlyUGsTH4tOoMVYVq41lR0pZUciLTkfnuEdSW/QB+POibyJKiHSkKlIrzkUc4lH4PqxB
xdFz1GLkTKQAfcIucFvUVnQ1QopHkZZIU7QyUs63hJXYGfdB+Bj8cls6jJ6PlUaLYuX+ye7KSCjq
7MGiHvdGzATzHZbaYvXCgifLtRF9FN2KpMQuxppiLR7MNcotxcwxR8wltTF3Y97oY3EwkBRtjHZF
B3vyuvejS5DzGdHcSDHMazOaoJIYF6zxQ65sv8lvUnXEWfJb8KR5AEgR/W3ZScB7J9T3VH5A1REz
VAXxWeyzcGSqCuIHVQUxS1UQT6sK4m+p2mE21gvY87cBefLqd5jL2O9hcUCgJYA/X8fKsNvY17FP
YjNwfArw5yJWriLQCvU9N89j38OWsUoVjVapaPQzKhqtxkn8JCDEFECdDXgeoM4WFW+2qkizDf8c
IM12FWkaVaTZoSLN/6IizU4VY76EXwd02YWPAro0q1qmRdUyQ0QZoEsR0OXnAAm+QJzHvkLUA5Z8
VcWSI0SYkLA5IkbEsQVV6byrKp2PVKVzU9U43yZmAWluq0jzF4A0N7BfIoyJn0AYEzegXYx4MiDN
/44/QxwQv8JTAECTeCYgzd/AT2vep3kWz0d4E/8Ywpv4cwhp4qWa39P8Pv5JpJvi5Ug3xf8AoU68
AqFO/HmEOvFKhDrxTwPe9OBVgDR9+OdImqTxWu3z2hfwF7Sf1zbgF7UXtI14k7ZJa8Jbkc6KW5DC
iluRworbkcKKX0PvJsFf0X5ZexN3am9pX8e9SGHFfdo97T7u1x5o/wlntP+s/RXOAXrV4VFdks6A
J3TJupP4l3UpulP4IEKv+KsIveJD6Htr8dcQesVv6Up1pfjr6Ftn8WH0TbP4V3W1uhfwUfQGMPy2
rkH3In5H9wXdF/AJ3Rd1X8S/qevUdeKTCM/ib+re0I3iU+jbWfFp3V/oZvEZ3Zzub/El3bd138Mf
6L6v+xH+QxXbbqN3SOA/B1R7gP+Dimd30fsh8F8Akn0/vqf/AODZIxXJPgUk24X/Sm/WXyEIvVV/
lSD1r+h9xAn0DZ/E+/WMniHS9IJeJH4TKcdEpv6v9X9LZOu/rf8e8Tv67+t/SBTo1/XrxHP6R/q3
iVJAso+JcrTnkvg0UpeJKqQuE59B6jJRjRAu8VmEcIkahHCJzyGES9Qi1Zl4AanORB1SnYnPn/jm
iTeJ82gfJPFHJ2ZOzBMNJ/72xCLxBbTfkfiTE/dOLBFNaKcj8acn3jrxFtGMdjQSX0L6NNGC9Gmi
FenTRBvSp4n2E784sU8YTxycOCI6Tzw58T+JK2hvImFHe/AJhwFIB+E0JBmSiG7DewzJhAvtRyQo
Q4ohlXAbnjU8S3gR1iauI6xN+BDWJvwIaxO04aOGEiJgOGsoI3j0l0eEiPYOEjHDpw01hIx2DRJf
NnzecJ4YMNQb6olBQ4PhAvEVtF+QuInwOPEqwuPEEMLjxGsIjxO3DFcNTuJ1g8vgId4weA0ccccg
GETiTcDmUWLGIBsUYtbQZxgk5gw3DK8Si4DKv0bcM9wBJL4MSPxbxKrhrwGJ/0RF4j81fNvwXWLT
8D3DCvFzwyog8V8CEi/TnAIk/rzmN9/z6fdUaT4IeLxO8yH1bWm56H0Smt955vlnPq05A2ugBXP+
GnF3vdMMcJaJ5cBKVoSdhbWqCqvDGjDiyji7gGleWbMkuMdwdos7xjRXbnCb3A5GvLLAHWAa30WL
KzAGn3HsAHzm66nmHsCZiw1hGk9tTym38G9WXY36VioMv4m/hhH4MP4GpsNwco08Uu3JQt8w+pLl
3zaiiS0yr1DzniLugE/lc8w7TsmaRT3hG/hUXws/QM34WlyzbFFgA/XyMdxMYJvP4cugxyW+DUZk
CQ+ELeEoaAgWBOuDTUFXMBbsD94KjgXng8vB3VBqKC/YEqoI1QUfhtpCnSFL6FrIB2MewZgUGOOF
/jeg92TQDL2xd3rCyJRQTmhAIIQk84plw0lQJuGki+NzuBBbJJyijdYpIeNKknBayEX3D9aHZoMF
IV/QFboH17slrKK796L7r4dSg1WhutBmaAfuvRc6hPHnKBc1L9R4FvlUrp/fEWyCE+aUat4xr3AH
vhZqhhv1X+J1wkRPkjB3fdB8z6Ww+0IleOCJ0CV0wagYnyMMCUueImFEmAYL9oWtkBjcCBaETwXL
PY/C+eFzYIEruBvuCqUKR6G68FB4JGQJT4cXww/Cq+FH4a2QEiTDj8P74ZNhOuwMVSC/hWvCjWEh
PBceDO72xtzDPUfBg1AD3xCqe2Wd66eKwTNrwYcQhRt8HvfQKQR2uTU1VsOuWe6uddZlQZHkc6yc
a5aav5LEX+6e5KuR3a5Z5pL1PrfrlJxGTwa3zNexRXyDa5ZXzHmWNfMA+PKxsI9sEp5CXNKCmcHi
4JNgKcTUBJHpR14N3lUjqgulh8p6HapX60KXQ5dCFHi+NlgLHjgTnAluB1uCu8HsYCiUFSwPboSS
Q1ywAHx0FByD2Dp6D4IPIT4Fwf5QYagEsuFmb1NoOHQbYlcNWTAJ8WoBz43CNcngxSBjzqPmubEr
T+lcbpvXoRy1ZvUM8Q3c6JUEL/pazJ3mFfOKkC8U+SFPLcXvHMJZPoc99XKMMgV34c4kapADU6EV
uNv9MOE9vH7BshEaDy2EjoULwiKKvbsO5YSaEc2CU6AFSRDeyQiUE8Kg/5Jwx1/iLxEa+R2mGnqc
E2yBDWre3An3SphXrAvQ67x1RzAKHrhWghtjOsO5IQVqQAwnhTOC5eGi8NlwPsqMcHPYFlxDmQEe
uBa+E05AZiwFzWFj2BiMQb9z4fPQazE4LzyCONSC30W4ykTIcv1c+Ch8OlgargxfCHvCUrC0N8Zd
ZIveqWPuFsxgkpvhdiEPVjiDR/LF+GTuib/BXcH7+CnzlH/FmmW1ePL9l6gnnnzewt9k8yEPbps7
qRRepFr4dSqTMvGbPMVf49a4DX6WX4BZeq3p/H2q1EZQLh9D32FP85vXBX6H8vL3fP18IV/CV1wf
hCrK8WT4L7GnXTvuMraS93ky+D3+8ArBj3sGeyT4mcEfM508x2N8Op/lGWQfeBJ8JzVPFffYro9w
265DrsnfSSeh1ci8g1Yi5HvI7n62COUBzG7UnAcVOM+nhrtgxSO1SdokDNMatAYM1z6jfQYjtO/V
vhfTvKtkvqtkvqtk/v+kZCbdO1Go4pg5YIJYy8h/tEaStNR+2VRir2/n6C0vZzvb5ghkW/esO/Z5
Z5GVsl0INJmyjCPuWfsZx7j1frtob7Jv0wnPKj3Ue5FeDZCBtECmdcd7zbpjpbybAYd7NsAEynsv
2pqNi47N9grHpscYuMUmtU4H1gK71or2cRdmolyd7By7ZB/riHUctIvOZsee3ctlmnRskt3MnnJs
OjbZIhixAWO20RjnUPt4dyl7x77GVnYUB251HHTcYtbZofYSJq91yTZoomwZrUumvY6xbtK1zqd3
mC1mPs89a1xqr+MvWw+vLHka2zuNI90F9m1no72Fu+usZIc6XNxdWPWT+VSL2TQLIyr4at7iaWRz
+cIOV/sl6712DPnHWkZLtiL7tu2slWpzWI9pCXnHlmGl7KTtQnude9Z022ZrFwHPpNOSZ5+pYxrs
a5ZJ5rLpEtN5NZ+rtdY51hlLIGRKtzWblbb+9obAdls9c83V2XGDa2pd4locO231V7YYij3F+Bx7
aE7GGlND65K9pZt0lLjWO8y8gmZk2jEu9Ta11zkaPI2eRvuofdthaVdoqWMS2ckM24pM1+wuZsqU
xcza55HFzIrtgqnEPQteyAUbNz2Npms9BHPowqw6i5k5di62V4CntowjKPbealuue5bZQfF0jNsS
ttN211WC83qMV08aJ4xLHVVXT1/NtfpcnSaKnWuvcGFcJkvYvcYl0/DV83A02jPBxmnbhMV8NQlm
f7btRk9jYBdGFbVucTP2Jldne0V7Xc8DNgmsSm5duppvG2yd5m+3LvHj7dXWe84l7x6f100al5xH
7XUmytNo7OqFuLU+gl6H/KHjNrdhrb5KePccimkYPl26soRibk/rJj2N/B69D1H3BW5BdM7AvUQ4
6wy42CNmr3Xa3uIccg6xjaa6QK2pjt7iS+gtyLJbV3M7JjvSHD56BLJ6omO0vdNKdWzTj70cfeRa
h5jvBUpRPQQu2tMCZmcjinnAZUzYz6B6sJiNI+Zjeo5eCpwJFHjmrONeLlBPT9OLAYOrhD6yuwK1
3stQN6v0IH3Hey3gNQ23X7afoSX6USA70GLKsjfRT8HjO1BvJojZHkTVB/MYQZXgyXdcNi6xE4Fb
gVv2W+yctcK80N7ADrHTTI4jmT1yDqmVc4E931YV6Geyrp+1ZLJJ7EignzsTiLVf4krZIiaZTXAk
66En2AfsabaSK2h9yp4NHLA0u0TVctmBu23FJs41ZZx4ucmsoLtC9T3siLU52JPs09ZpawVX7Gw2
cfZYR7/Dwj28mu9ppCYdClTQRtuZjsy2WEcBt9sxxh1cWUS5alX4QuMSXwc8oLOtCuUqf812wdaM
aq89p72sdZXb9qbzOYFivixQ1THGKJ6z9ANeF0jhL7VX8yWuY97H3eWWuTWoSorabZ1u74QqWeaz
+DbbKWejObWtmBftk9yTK0uocqHK27pJqBEOrNqxZDo2TRxU255j05JpyQwsB5bZ5u5yp2CfbHPY
l9khWH9WHW2BycAke9ThbS+xmB0NbI111lTi8KnttrXMOttWfzW3dYtps6dczW+LOQ5tzR1exzE7
xzWZpjp2UWMozsSOMByjMCJnDuwyCncRKoGiJlGD3KwxLrkhmx3r/IBpFlaRs9Z0rr51qZtENYvO
zBarznYBKvem6RpzG6oWKrfDYTtrmWFWnEX0UMAFGdbULl4/CSuYaG1wY8x9qFMTM8vcs51l9uzz
sBaPWMxQ5wNwrLeLlou9820MM+6ttl5Gdd+xzSxwMdMeO9dRyrmunuRCHVW2DFgzb1t9tqcmyprK
jQE+z+Qy7d6r50zDbUzrlimLYxiM6+dGuVvc/NVcs2I3Q1bVuDo5B9vMpXXcsm/bt6+eguO01dfW
b5+HNeJG9661ur0OqnSYH+ennEu05FwyQyXz951HxiLA79ecjZAB27bG1mmIEMWv8OtQubNQ7/fg
uMnnOStN6e05kDk34diBykrx7rkL3YWottFKYHfxC+DTRbuJzbB7LZnw/IhZ6yCLkxycKZ3tQlnr
GDB6mFQmHeIswRNCdEw5OpkKB2acYx+zqx0HbbWWFLZSjf1WYCYwwxkce44dxz2ugCtna9q8sGpV
s7m95a2rravGJYcSeMIKjuFAKBBCn9ETgRv0hKOQKWRKHHmBsfY2yB/xaj5rY20dVY5rtiMH1Qqr
pPG8w2dnWCdXZa12DDtuO8btpo4YZJDZWmZrtJhdna7O1kXIqgbHLHijxFHGpMPTcsF+0FHqWLen
wBjK1ty66LjvWHFU2DIcm4FR+13rOpPHPrI/Yfc7nph0AQdrZMocN+2T7KL10HQb2YietQzG6FwY
OwjP2FU0Uy6FS+MK7C3GxUAIWNk5eIaWBjbY/MB8u8jWMCsmyom+MTwFX8PXMAz/Mf5jDNc81jzG
CPK/kpOYhvxL8q8wPTlHLmHJ5A/INewD5M/Jf8A+SO6Tv8ROk/+DfIplazVaEstVmc8ZbaG2EPtd
7ae0n8LytBXaCuzD+in9FJYP90j8H9rLO4DlqdzpM8Ccvg6jEXeqVZX4F7AFbBGrUxnUH6pKfL2q
xP+Ryqb+s8qmLqhs6o9VNnUR+zmwqRdVNtWosqk/ATb1IaxJ5VHdKo/qUXkUpfIot8qjPCqP6lV5
1HWVR/lUHkWrPCqg8ihG5VGsyqM4lUfxqmYfUjV7UdXsR4ky4Ei3VY70HXUX8k9Vbf4x0uZxAmnz
uA7tQsb1SKHHk4i/Ir6Dvwdp83g6sKaf4QWqKl+EvlsA/6iqzRcTv9SQ+McRa8I/q+rxX1T1+C8h
1oS3qKp8K2JNuFHzQPMA71S1+ZdUbb5L1eZfVrV5s6rNX1G1eQt5jXTiVuBRDO5Ae53x66oG/wba
64yPqkr811Ql/uuqEj+G9jrj30B7nfEJtNcZ/6aqxM9r93Sn8L9RVfYdVWX/B8Ss8Meq1v6Pqta+
q3tO9wn8F4hf4fu653Uv4r9EyjphQMo68R6krBPJupd1LxPPIJZFnNS9ofsR8V7EqYgKxKmI55GO
TlQiHZ2oQmyK+CxiU0QNYlPEC4hNEXWITRFfRGyKuAxsSiT+VFXKaf1f698mBMSIiK+rWviEqoV/
U9XCJ1Ut/E1VC59StfC/VLXwaVUL/2+qFj6jauF/hXZgE7NoBzbxQ1Xh/omqcG+oCvdPVYV7E+3A
Jt4+8Y+G9xFbwKme1TyDOJXmFOJUmvcjTqVJQ5xKg/46/vc16cCpLmo+gNiU5g8Qm9J8BrEpTTVi
U5rPIjalqUFsSvM5YFNPNLXAeao094HtdGh+jLRhEsdw/Cw+8GsO88db/+HaM7CGZEP9F2Il2Dms
Euq+HruEXcaMWBdGOBfcmZjGOevOdGfD2aT7LPwcc+fD70bdSe5TcDbkLoGzQXcO/Es4FXcxnInu
NPiXcDIvc5iG2qPWqUM4c1LoWjbqiRv7v7Re4uq7YOEm2qe607/+K7oL5f9rI/7Rw1G02UsNeaaa
j3szqMddhZZ9mMWZXueljJdze1c7p3v3X9z0Fpi3vf2eHe+Yd7KF9HCeAbPXyjhFzxR11FXYVUg9
6u1yF7ir3E0Xmd47vUsvblJLX0ryVnnrzdsv1b50ixJ8q759v8Gf6S/1m/wOf8g/6p/3L/s36FQ6
iy6hL9MUzdED9E16nL5H36dX6HV6B8Y8hjHZMKYf+s/4t/1P/Lt0GV0HPYehZ5Y/m74WOHld9CR7
Uq8rnvTrA56sP33oyfHkXb95fdhT+NLk9XFPyZVCb+h6xctO6pHl7Euj16c8ZddnPRXXF5BNgaLA
OX8pveMPBWrgHsu+LWRR4AJdEmimL/sv0jcDXQEbvRJwBjww70vXD5vvmQ2eKd9J3ylfrq/IV+M7
77vwcq7P2Ltq9trKvJOey96xly76Es2XfUO+Ed8d34Rvzrfke9B8z9Pm63pxE3n4C/2956kjn9HT
2TvoEzyWrkLw/VMYseonwaaRwKK/NLDkr/ffCOwzKXSqP0SX+OfBHgN9k2GYfvAPxUwy88xdZpl5
yKwxu8wTFgvMMWamhR5AvmXOMFWMgxljvHQZE4PYJrxmuoKe8hbQNz0+j9h8DL/Lp3PgyOsqbL5H
CejonHaKvRMvn2w+viL2PobsL3fPvxRrHHd7vWe8xe5+77z3Yde93iTvRlvXxbUuynO/F7Kkrct7
lxpx34XMmHIX99Le2uZ092jzsOf2i5stZG+lZ8Gd0muETDryzlBb7uXeGveu+8D9xINRglOk9qnH
L266L3o4b7mbdGe3kN4bPfd6T/We9z7xPfWTgSR/mpoFZ/wF/iq62l+rZpDXP+kf86/R6ZA/ZXQD
3Ukr9DGKFxzX/pW9rwFqI7vz7BYSMDLnJYQQQhiGYUAImZH5EDIIIWOM+QrGQmYYEJL4EnSrW2Kw
EI0DErRarZZCuQjxcg5LOMJ6CcX6KIpwhHI4Qrm8HOvTsV5CCCGEsCxLvCwhhHU4wnEUudc9m5nd
urq5j7qrSl25XnW3/t2vW+/9P97/p3+/9xezyOwyR26D2+jhuWVMEJPktgMOytyjjBVwdYHRMidu
Bb3tDnYfMxNuL33KPKNfubPdPoZmepktT6gnwhPtEQG+DzIQ4880Mt3uPvca0JMwd7N7uPOhY6lz
pL3XpCNXyF3HfovYmd4ldJY7dV3FjnDnQ+eQ87WrpHYT2ICCIrTPqR5q1KgBOrrkWge6uevabzpy
5TQdNRS4VlxbQB+P7iWRBa4JssQ6Y31NlrnGGCXoc5jngech0L90j87T71F7hjwjHrR2zZPoyfUw
dCI9V7dI81znnC6m0CryPp1Ll9O6j9rpOlYXaZJmqKkqL91PD3Ue0IGgpGtngNaW00O0uktMDtIv
jBrnELpC86gp+iEYBTrpCDq68sRZR9vodnK3Ysdz4N3zGjwznknPqmfDc+o59fK9QnefV+at8Baz
+shseXu8w167dx6c2/FqvBr3uOfCG+ZVAPqpV0ofeI/dBkYJtHrOO+4d/Zr/14I8255X3hhvthfz
NruLvZHkI2sEckyOkUvkOnlEnpDnTtQZ7QqnDu+NdV5Y+iyGLk2XostYp723ro2oevrRQ+q4a5QK
6yKoSOdrik8Fu2rAmLPauUEF1weiK5SBGu/adFmBLi0bNRU75qaueXKa9HfWkfuuKFfsvSSnraqv
y1uV3TXV9bRzrnOm8zmFdfV09VFGZLML62ru2uva0d1vLHdBdRLysctfG2oZdQW5Qpy8piRXkkte
eeRSNia6cqoI53PnnPOFc9V13znifOIqcJW5tBXNxmXKTlFddlejy4zMuzq71qg9a5GL/kgEanSD
Fno7+zsnO184SecD5yvnBSWkYqgKatOZ4lR1DbskzjrntktC9XUOdY4ASxX9fkwGdcF43LlNDVBT
wN56rRFgFH5G7gKubTUlOZbMG817zss06l7gVrz+Nf+vIYj/Q/4PIZj/I/6PgK/5Mf/HwNf8hP8T
bsWrGXJBbN5bFgVHcCg4kkPB73AoOJpDwe9yKDiWQ8FxHAoWcShYzKHgBA4FSzgUfIVDwYkcCr7K
oeAkDgUncyi4hEPBag4Fl3IoWMOh4LscCi7jUHA5h4I/5FBwJYeCtRwKruJQsI5DwXoOBRu4twm1
vCyAfOs45NvJ+wvef4IecTNOvs2iWuh7XMas73MZs2ZZVAv9exbVQvPcu4Bl7l3AK+5dwD73LuCX
3LuAA+5dwK9ZVAv9hnsjcMy9EfjP3BuBE+6NwG+5NwKn7FwT6IxP873Q7wRnAJPyOUz6DodJozlM
+i6HSWM4TPoeh0ljOUwaz2FSMTfb4zo32yObm+1xg8WkcA435+MmwKTrcC4X87dyMf8WLuZv42L+
rVzMn+Bi/m1czP8+F/P/Khfzb+di/g4u5t/Jxfy/zsX8e1mUCn8jwBfwC3iGi9ivcBH7n3IR+w0u
Yv8zLmK/+daZ8PPwz1lECf+Wi9JfcFH633FzICBuDgTMIkoej0WUPD8WUfKucDMbkrmZDSnczIZU
bmaDjEWUvDQWUfLkLKLkzbGIkvcfuaj4LwFK6YdmP8Uqt/v+u+0zEZtWRhZBfqS6dJgsh3iml+gS
OBdNaiE/bUTpA7IAnJu1FgAqqLSTrADX+KCeX+VFaTNbv/KEBGiu8shYQcYCao/kQ36m7tIyUvy/
ZEWf4K3A2EAF14cINsln8fLvNz4fHW9Z1UeRYaZFdXHjIqkxbpP2hmXjJDlMjpcemf3JTXwBj0FW
TbQhgtzDLuPF+HzX664LUtjQR8oq0slmkjBOon2kt/SI3HOGIKtOCTnV0If3oH36ArUCtxtE1nXn
tGGoft+5jlL3JVg5ZsMYMpsSaUiDDlvFbPWL2IUh2s3TxbgOkdx7x84C3E6HG4acS+CeFSza8KK+
huIhRfQzbMgaa4x20hp1KU0/pseoImeOexvtq7abnuGKhqlqRXOguo8pxmylEGOoONBH6ZdskffE
1VN6Cd5jDmHm9Y/ujeKU+5X7tfuyaZEJvosx2UxeKYSJ0EgymKGadXpJs4jBTItVL51KLILlD25H
XpsW8XlSQz0wbjcso+MsdwwjpUdOpdkf7UNWsXZqBPBGg6Sg45SNYqpWqX5qCPfiRjL7zqk7BXug
VjQPudMNI4aHlUb9ElXuzq06oF5gjOnIdYgTzQd3I3G7u5xSuXXUS9zL9qlh6s4prsCp5kDkpboP
s1W9ZntkmNRHNYj1S5oDvQRjKjH9o/pedBgdRxUtq4iaOjAtUq+rxa5gVySQzTCpKT1CZsz++ihk
FTe6vNhl1wDywDXleuqady00iA02l69hU7/iajbY8BjjtmvZle0qdhGuYcpWeuSi0L56CB/Wb7mb
DCJ8vEaC2UznQAPW8E2MwWxktlqBlbt5rk1DtKvHOIeh7g0dZo6th9TSqlNTGT7q2lErDDpW8vgy
vmwYcr8wnWCM2d8QCs5NAz1A3dv3FoD8DhkCV3igu5Gkt1rYssoYmgP1UZ5G/VK1XS+ph0iN/pFn
zMjzzHqe6cc8i/pd3aZniYj+qMbTaYupnmJl3kB5Sjy0Z6JhGdz5yLpOrjljq4V67b1I5qkznN5n
RiuzTefqcfU4XUb6yGXSh/cwzXiPcwnU5aOKBjHeDHjbR0aiClRG7lSLyWxgEcV32lmZk6OsPZCH
5LEzyClnZe4M/2irGXUm4fP6/Ybh0nUyhhSTPWQf+ZScJ/PITY42kgbyDDxpGTm1AXvpOiWD0T5n
lG6qBVgU0CMFaXdCwMKKyQrjpHHS7O/0JytIytaHN6uLcUpfoC9AI/U5wB4WrevWdSydXkEpo4oq
p6dpK5lt0NH72Ko7VBdDF9DKqlVnDRVKRRtEzml61lnTnO4sUZ+5RXS484QepE+c61QuvU77W2Pd
EcgcHeXcojspUaXPfdk5Ub9CN2ouSqMMJELqgf0B63tm0FU3u87oI+eic98dTZXfeaBR3blQY+7T
ewusBIDVLZI+hl9xarLqz5mYagUjNuayusoYGUwfxXgNEcywvpHVVWZcP1gd3BiLU0wkEwnkLSSl
TAU5wNjJhXtiUsjRChJjeu5GMkTlIbPABLsP3BfAjqfU0spsvAfofxhTzPThsnujRKImtLSEWWZk
1VOYCBPpl5gBRspoGJ9us36pNEpfcOeBU4vbnWUGERbqnHbO0lqjqMGLFakHMJR+jDH0lt7f2e3s
Bfy7rD7DXtcv0vLSI30UqwN4M9auLi49omaoh9Qc9fxez51TtQJo8kO8B+9zq12HpY8+LsBe6+hZ
G99dRK1alYC/GzStj6q2s7zRARupX0TFmlBmRydkjpk9CqXaqSduFbPGbDKHVBNFUpOusAax2R9Y
7ivqlLpwxeBiV+RHvWQFeugyugy2SBcG7K3Y1eOyu0Zd41WMS+OqAHYqdsm+ukpWgHN5YCze0e+D
1m6T2a4+7HL1pmvNxXcJXYr6KGSogQCjgdTVY5aw1mrtdre7STeDFwM7XnD343vuEfzQ/cQ96eaB
Mueecb80hxiGjP1u271l9wP3kLvfvep+eF+C5BpEtBxj3Oi9Y/dzQzRud+3hU7Yp3IfvGCbxMyz0
3rAnSr8LLPaQOfP4e4I8sR5JtZAxMFJPmcdsW/BYmfF7o/dGPYOeXs80GDcjPVpPjboP1EtyjYJa
054c92uTlYnUR7WgLajnsf6RWUKNeEI84R6lp8Bz39OtP/fITbNoH9oHgJYICwQjUgQWTXc6p3GF
yUybDUNkdv0Jeuw8pwLpR3Q3PWEYwV7hkZRKHamOtN6ntzSr1WCkssZyst91PnIO0vs4v34Q7XFH
2Oy0XGOj1EgTHUTVYa/1ix1Kfaezm6bxPEpEJbLXnGZno9OKbQM6BdtwduLF1GVKVz1PW+n7OJAe
kqvf1bTjMv3gXaN+y7nkTkQpPK/uEC/W7+LS+nPsIdaPjdRDYPxkqu3GOZTSFRuG0FHsFRVRbcc1
eIXaeEeHh9VAumM8DJwxIC+xA7QP6PJ9rA5rp8dqIJO8+sw0AeRRRtdQ6fVBWBG9ZHpmfOnMcWqt
63SJc9d5RPfSj8lsegv09DGQbKA7wnXsOnRq6XBaQifRsc4lOsQ5Rp/TOcgMZvM0snMbBQGCAAgS
BAmCIFjwOcHnuH/EeBPjfhPjfhPj/oOKcUO9wHI+QfM3eJ9sn/lLpPGwYw/ya9zrOOw4BtS2HfxC
aNzoOAXnVjs2Ol4Baun+M0Attp50nABqHtTza3zausfVn7SZAfWkY7LjOaAedzwG1GDrUsfi/3Dk
+OTXh5/Zz/vp/OhszT/f4FGdBNGoB1v69Lk3fdrcluUKg7a/sqRCaouySW41VdNgyzEMV2n0vNJ+
W6P+gcFXrdRJWuzqwcoQfe5XZioMBkOFVBdi87/VZGv8uKZNUhlSHdRxYQ+2Z9v77KP2p/YFu88e
BmiWmrIv2/cckL3CrnGUdVzYZtk2GM6qmvW51cqWZUJYYags0UnYFmhiwFNnq2ldCHjuKREDvn9Z
O6mTtL4m+Hc0RBgRWe1vH3BMO2YdzxyLjiWH2bHiKHCs6yRVTxGN9mUHT59LNGtGiR5i4CsztqiW
5VtNVbJqWj1YpTHstPnrH3SGVgnbkkBRtuVUjJa+biuo1Dr2icPS14ZhlhfEPOEjjiuwzsu3mtqg
zggN0RndKfoQLem393Um2rNtZbbHVRrQz2xbQccrW4E9u4WqeloxajjsGKoMaRmoelo1ZavRjN70
dcx1PM85Zftmi2V523Fgs7YYbdNs36o09br6V7aJamUpWhl1q7zjSctox4uOl2hZx0bLwq2mluGW
0Zadls2O15rRjldVRLVSn9vR3zHC3qtOQgDPdZKOGW1/xymQlg9IUVohraarc1qWK0uqlYbDm75q
qOMCSITPySQbyGPHYQacU9rF9mFHLNhHOqz2NUeJfd5OOe47HjkGHY8dY5wM+0A5sw/bF4D2rXZs
t4y37HHng+0xdq+9xz5uP7Qb7MZbTepBwyG76U9v+m41ETIimFBUDjYEAfksAals3Q0p6Xfstr5q
PSXErQetF4TUcVIxWk0DOT13HGlGHeeGUWKg/nLLss7cySM2OSn5DD4gpUAgJckdPrFMAA0ttwJZ
zrYsVwmBRO22mlL0VpP25U1f1aH+wV1tWxlBVfQRT8sHqyIrjjWjldOdKaAHPntwZzo4DtiP7ZsO
f9CecLbVdsze7KAdWkeNo9ExYTc4JI4klrLL7FK7AlBye7EjyBHi6HV0O6IcnXYh6HeeI+eftJvV
awJ8GrXbq2TcfN23BG8BW7wkuARs8bLgMsQTBAuCufm63/x/l3sKokF5H2JAkUJeUK5C3VAPeDa7
iiyN8+vXgF9fhNKBb38Bvo316wrOr2cC/70PZcF8WABd53JY3eD8aw7nXw1cDqsanop3Harl3eDd
gOp5N3k3ISPvFi8PauAV8gohhFfMK4ZQ3ge8DyAT70PehxDGeWKc88Q2biVYN7cSrIfLefV1bj1Y
L5fz6o95C7wF6Ju8v+T9JdTP5b//Ey7D/QAXo/sWF6Mb5HLY/xveb3m/hYa4+Nu3uUxZw1ymrD/l
MmU95nfyu6A/4/JlfYfv5XuhMS5r1p9zWbN+yGXNWuGyZv2Iy5r1Yy5r1jqXNeunXNasTS5r1s+5
rFn7giPBOfRLwYXgAjr1h/xh6L/48/39of/q/5b/W9CFf5B/EPQ7/xDgiSHO7/oBj6uA+dwKLn//
fP98OMC/xL8EDvS/618Gv+VfDnzwJS6m90dcTC+Yi+l9jovphQDv+2/hz3MruELZPF1wGJunC/4i
m6cLDmfzdMFfYvN0wREBRAABfzngfkA7HBngCOiE3wkgA0j43QBXgAuOCfhaQDf8HuuD4Tjgg33w
lYC/CvgrODVgLWANlgX8NOCncFrAzwJ+BssDfh6wBV9jfTOcwfpmWMH6ZjiT9cGwkvXBcBbrg2EV
64Ph66wPhrVcpq8aLtNXLZfpq47L9FXPZfoycpm+GoR+Qj/Yyv5HCdzCrpKCbWy2dbhV2Cv8Btwm
/GPhv4a/KhwUDsJ24ZBwCHYIvyMchTuFY8I/h0nhuHAcpoTfFf472CX8nvB7MCOcFc7CHuEPhH8B
e4X/QbgIf134QrgEf0N4KDyEHwl/I/wN/M1LmZey4P5LhZcK4W9dunOpFB68dPdSGfztS9pLWvhP
L9VcqoEfX2q41AD/2SXkEgKPcLnIvgP8YR80+alXzFD+i+0zPXlbUFsI5Nfm3xbeFgXxiIs2YPfE
aVsM5Ee8buO3BQNqvy0RULvECTiCcaxNAqg1Yg8cecRL4gJQL4gN4gBQz4glQM0SS8TJ/2T0+MSf
8/v8zVwWNXaNFZROvdn+9zd4tHU4n8nqLuLlM1pFnjZvVnHegOarM2LunuaV5YfmP8kPVUzn27Im
sqwZsqYUxa5yrTyxdbhMmtWdn66YLhAqzksiM2JywR35oeXpH9cEd6bnz7QugHJIRKkn1ZNELCFh
aZZSrBOSlvuEhIDA1c7Whfxotg15vZWv8pnyxLxZ8I3n+erWYa4FTfmhBRX5TxSPsyZUvPwXit2q
iTwz+P48Yim/6IPBvKCqaSKKmCZWiDFindgiHtleAH3bbx3OCmKfWfgM9G6pYFl3OcuqCwVPBE/X
JeY/yerOmsgvym1X7OrS705mLanLdUV3yvK0txZ06pJIxaOsCaUi38by4oPB/PasibbANl5+aIas
7XJGTFvoP/Upqi2i9TA/NMuaNdF62HqY9ZgtrYd3BrOClFjheut4fnr5gyxI8ewOnaXUKlrnC7zq
FLZv2h6Wt+WhBZiKd3uS7VvWROZBlpXl7a2FzItcdeuUNqYs74OVsrD8wDxtfqg2WBupNdzpLvAW
LGc9/mC6PFEx3TpqY3LV4N5z0EdrfmjrUyC5XMW0ci1vNiMGyOOJYhr0V12eWLiuzcu84OTha91j
2wrkkUQ8ImrA502ihNC2bgLZDAIZ7dxsJEKIx8QzG0os/l5mRFTLCdjHfmAuf6Ad0Iq1Ru5Za+Ba
OBF+sxFc9Sf8ASe6C9fZTcXL6wXcGi1qz1Bk7BUYgXy2gFSOCpWAayetw3mzrAzZPXEOevckr1cx
zUoJyAjISekDV0J0ibcZVkrKNeWaYre87u6kYjdvTFOmKVOcs7IEdWbvTt49LZNWXtxayA/N6wVP
2VXs3hr/IDxjM2MT6MY0e3+WUhfaFg1a/0lfCDnQPSVxnyhjW00EgTJB0EQ30WvrL/G1Lrcus1Tr
DluIRsLcekbkEAVgbJo27BNj4PpC6zFh/SftBnpN+LcuqCdtuTp2bkkJ/F34u2Bw+h78PTBSfR/+
PsSDfwD/APKDn8PPIT68CC9CAtgH+4AzfQm/hALgFXgFCoTX4DXoLXgD3oCEfql+qdAlv5/5/QwK
8vu538+hf+X3N35/A132+1u/v4X+yO/v/P4OCvb7hd8voM/5/b3f30Mhfv/g9w/Q5/1+6fdLKJQ/
wh+BvsAf5Y9CYfwx/hj0Rf4T/hMonD/OH4e+xJ/gT0AR/En+JPRl/hR/CorkT/Onobf5s/xZKIq/
xd+C3uFv87ehaP4Ofwd6l7/L34Vi+K/4r6D3+Hv8PSiW/yv+r6A4/q/5v4ZE/H/k/yMUzz/hn0Bi
/in/FErgn/HPIImAfUF1ReAv8IcSuXH8fW4cl3Lj+FVuHE8SfF7weShZ8AXBF6AUwRcFX4RSBV8S
fAmSCb4s+DKUJnhb8DYkF7wjeAe6JnhX8C6ULnhP8B6UIYgTxEEKQbwgHsoUJAgSIKXgiuAKlCV4
X/A+pBJcFVyFrgtSBClQtkAmkEE3BHKBHMoRpAvSoZsChUAB5QqUAiV0S6ASqKA8wQ3BDSg/aCVo
BSoIWg1ahQqD1oLWoKKg9aB16CtBG0EbUHHQZtAmQKBvMOsbzPoGs/7BYFZ4zq/vU+Qn9b7Z/g+2
z8T2+LoFoG18xRJmiQSUz5IC9guWaHBu3sKzADyOz1gAmscnzcfgyMPHQD0//LH5FVd/wHwOqD7z
unkfUA/MPkAxZp/5+I2H/P/WQ34aZ63xa/z0H7Qk+/BoYUrmoVRdkHR7ILMib1KpxI04URSsSJQG
ZuwXbmc9L9y+8RQfvX1clpOZjU8ZVdciMs4LU/AwqTrrye0BvAI3ZlKgtvqqAh9oaGZrFl6AO5uy
nmPl+Jo53NxpHjRPm2nzIr6Db4LjmHnCvGTeNZ+bC5DLlhR8r/Ah24bkGQt5eyDjXKnM2saNRcF4
MNuCaweF2zVJWc8zam4fKyY16UaVpd8yVJgij5XybmAF04qRW1bLE8ukZc7yHGm3vLCoLC8tq5aN
wpS8kczDQtSyfXvA8irLhlcomKth0kCl8uPnSdW3j5tkyQ+MqsKmzMOGmBsDTeIC7e1jaXmTQhGa
VV64ensNH2V50SRsiGkS5/c0Se9iypCmvMZFywzbI4u6qdjyxByVv5lpvH1sjjXHZmK52ZmYOUeT
njeimEnqxSOznlztkUZkvcg0SIsUG7hG8QJvxjGwpzL272JGMkeiyH1fwvbt9nFSTcNAepiq+P2Q
pJNcDJfiCtyeP4978Z6k3sJtXIzLcEPtQUFOlu1OUUFJxjngvRCPSS7Cx5MkGUeFF3gwXowTCvLG
U2WQUqlIVCTiwzeeakY0uaripN7Mnqvj+FN8GV8AMpGYo8y95i2LCiXMWjNkuWwJxc/wPVRoXrEk
mmfNZkuuedGis9RZUHAPKzPafGJ+ZKLxvJpZvA/Pxg34PL6JHyIbZqv5vvmxed9cYi67i0nVmXyp
Oqn3xrFiA/DZanmYGWwZyRJZZoBkVhH1+93maeyhxWZhDM8t7ZYHDc2W0/zNm9GFakWi5SBpVhWW
9zK/x3JRMNgU2RRTesJK6VrEtYir83hY5rE0QpGbMZExgRsBX8NycpTKzMOmYHDF8H7IXaxQnRmj
CDSqsuqasi2vr0418ZvCCtHMM2mRPLZJA7RwEV9rqgD97jYfmdfBOCnCEs0lCIkEmrUWtWnRko70
W5rMz8zWxgKWMgcBKBFiibBEm5WWQMCjcpRILrIU4T782JwEOMZyRs7qtbkGmQFa3ViTxP2jE+8N
Iv1MRMpi0X4Oi/4Jh0UHOCz6LQ6LDnL//vkGkb5BpP83o6heYB+f+Lz3Tj4bXTUEIiWQH1LWwEO0
EM94hjSD/TFiAOeyjYdIMaBeISigdMZtcOQZ15FGQJUYV8CRZ/QhCkCFGRcQMaDmkEBApRhnENEn
Y8OnK1xeC84+zVH1noHdeL9KGUvbT5Ym6eQqZXrccVykkow/kG3GH6TFynNlPrE4bT8hVhyjjAbU
WepreaLsLE2bMnYjPFma0Mnexd6hJGXzCWMJSoVPjkp4Ml8mJI65sR4vSibSauS58auiibR9xIgQ
SA8ygEwha8gOcoaGoOFoLJqE5qAlqBntRc3IHjqNzqJlZUMfHKIr6HoZCe5pBvcMI1MoBOpHgdpy
5BDU7vy4JlqCDKOP0RPJZbE4flI0KHqULBVHyh+mzogWFcPXX6igFGuCJK1M5ksKTRmTh8b1iQaT
dEj2hy/i9goiUl9zbVozRSBT4LvOwHND0FgEY1tkSkTNpnS0F/Ghs6ZcUxG6YlKbylPG8jR5GtF0
nFeuyikXK+S5yc2io8ySFKvMJ88Vi5OlabEfcym1XRKhUmbzZc0l6jyNbCeJjJNW7IhmQftiWA7f
8L/hHxcpz726IvOlqhJClGTcsTxXpQQt8iIEuo/WIFMmG7Jwt8DEgL7nsK0zzYH29ID2vDadgvZc
YEIsDIvEYjAxeoT0YVJMZmoyrZpeAN4A3pqGTE9MGxjfdMD2RJnecJQnRK3oM2U0Opt6mtysBOfi
zgAPtWgZkGB62n7a/vW5nPQknegRey2zQGyXbV4tU0FxkWm9YjGrA8rolME0rVwl20l9YgiLy6sY
BvI/lvkMYSJawpNEsNcS9pFscVj8wXVe8RTb2zRtmjltOiHqalnaftyoCkJiJIFymyg8oex2gcKb
tp+ki4uMixTHxCemjCmj4/Jkm2laFaQq054iCiQboRAv2ztOC0bLopGn6H1kntOgQ6A/QF5oAac/
NPqoLBrdZeUFyhK6iE4AmS4jy+g+Mo4q0UagXWbwKQgdRBbQGrQb3QKaaAT8TEJnkWPEjpYhGNCz
cHQMnUDX0fMPRk08UyDg+zQqB6UX2QOfJeCZfcgm6p+2rypL0iXprj+Qq1Q5cceiRUSmVMWHZsni
E1VK1nKA1YyqzpPPlNGsLohHZWcZz+Mnk6XJUtFiatH1wLjjlDGx8ePy4YvraqBBgantccfSnfgD
0e71F6C1PVy/+4D+hZpSQHtEpjoTalLJH5oum6JNutR20SNW5xIes7rIamJyc0pjihXRVJakznys
i7IzeSJikESIZoG2zcnn4l+KjuJXU6x5mswSoIXhclXGc5kvbiBZqj2VJwJ7VudPxw1k5qR1JzxG
KlQ5Kea7BegRsM59xG5qRxZMD0wPgUYCfTRNmp6jWlYfAbfWEa/pFdDHYOTQNGOaQUNMD1DINIKc
YUJQtxnIbBnIaB+ULXQFU2DZJhKZN/WD8tK0DT6lS6JTxlLGkqVyVcWeWHE9OmHsalnccdpWwpZY
DLRDnPE6a/z6SGq5aiI1XTafOlNQrrN++CIhNiFWtpcQi+TF+QCPY1h+x/myZAq+MrpEnTaW+iRN
K1vIeI6I5eUiSDSWJhePimZTHot3VOdgdAgHY9sWe+3GSbZGzE/ZStuXz+Wk3BgTHeUkItL4l2m9
jZfjxDLxjfCEkPiRtIK4PNGYaFpJIsWyTVV4Kio6SghR9SrLU203nom2gJ37ZD4VJImQbSo34iJF
zwrKE8JVUOqGdFgeLY/OSbxeFBeTk6iCFOIUc15YyhjQoDlxcOqL+NXrRbI9sQG0RRV3FjeVPxi/
nSXLHk17JFpiLUSZrjD+fkwWi9nxOP4VK9k0LZD4GDsKq3LEitR2JakqQ2LkuUpGnmua43IE/oj/
kzdrV96sXfkDWrvyAOr7FIVErHPbZyKk1Ee1I5Bfam/tSO0TQHmvnYM9leMD5+y1vTlTgLKlA0yU
2pQ2W9sHqEY5S9WkjV8bAlTF20OA0tQ21loBVSQvAlRuWu816p/Zx6erUiIDYz7FbhEKPr82953J
a4lR07doceDbw2UnSc9q+6PDJIO1Q1eK5IPiwNrnaeK37QnF2pr3c2pfpfS8K7l2UVtUq64tf3+w
timppvZh4qZkMGf2Srp8sHay9mVCce32OxfvDyZulu1LtuLI+MbovdrT1HXZc5Gm1pYTnjwji466
fy1ahsrar1ykniRtvTMjX7n2IC2yIVjVV79yrb1+K74xvrH+KDG4rkKkKbAmNyXPiDeSZ942aE+M
pPH5XU3tqYgyvjIeGOui9uv65CGJC5EXku70QwMvev5KRNxQY1lqyfVYuTYlO4FKOWu8nyF/J/SK
WnRsCNWXSI6iz/R0Y1RjbKMkOrhRnnDcWCIvudtzpeltXwL1wVxj7xV14+PI/ujg1MHag8axpJqo
lbrllB3xaeJZ3VpKc/xR3U5STd1e3WH6fKpcvRw5B9p5nKCRxJaUpfT9N/bOPcqK4lr43dXVfYan
iEgQ5wXCwLxgnmcGBAQERFHeIg4PmfNiJIiIioQgIqJBRHwRQnA0SBQRERHR+EBEgkgIQYKEEERF
JIhoEAkCEjjn1v7VXE2y8t2b/PGt9a1vuc46Pza7q6urq3ZV7V1dZzrzw6IxRSsje3vsqkgWTMt4
pfiWyuP5a+NXlqwoOxVtGB/cyslaWz561Ky8nuWx+Oho08za+Lj4xIxYfFp6TacW8ZnRFvHZ0cz4
PLmnzPUFpxMrc8blt7zwTPHy0v7hFnJHRZNyZ5ZOKjmdX5M/MPNwdvu8o10Ot0+aUu7O3JHVK+9A
+1PRnul7qg9WtCxaY0q5qzTcqSp9bdGkyPHSorwp/YdGa4fWRpd1nRpuGl1ZMDkjFl0TfS3jSN6Y
3EPZM9sdja6PjolOMZ8l5d275mTMy1+Vuyh/Q0nnrMbZpwcky5qVr8g/GF4T3x/OzKwtmVdW0yrI
mJ8ISqd3OdGpRfn+oUXli/J7JVqUrCjZ1fWecFDS+bJFhW1KTxQvjC8tOhM/nT0u0bRibmZt+p6M
ecULS3dnJoYWhZtmHi7YmHEka0LlkcTW9OXhExWqQoWr8lvmzszbWnI6PZk/sPjJioK8o6XhglfG
Nquo7FRbMrNoSVav0ZUF6aVOesvSNlnNpM1zJydOlBwZ2zh3ce7M9MbVp8K1lTMrsrNeLljarkv1
zgFXJBbkLuraK7NNZpviufmNC/YOmVcZG9ozPD7WK9K88khun/xbyjt0qi2szYl1cgZsC9cWd6u+
JWtf9dTS9UXrs5tXPyn9ofrlwrzyvUVLesw3dr6nuFeekzmnIhle1mVHxvbqkdWR/Mq82qsP5l+R
Pb96+dUbqiPV91TPqF5bsqJgb6cW+WsvWVLdq5PpK8Vp+ZuzVuWr6l69Z1UvrN5c3r5V3tATebV5
tcUzytsX7C3Ym96yvEP58YK9uRvzPsx/PG9O3muxmupkdXLk/tjjPVvkDB56uLxz2bDIvNEqtiey
NJ7ebX4sO9YyfcPobsU789pU9indHWs5ulu8dXb3wilZNV2/KHSyN5btiw2MvFI2o+2M2M54WemJ
wjmRWGxY7Mmc9HjzSOe8zNIzkXVtZ0Q2RrbkbmyXKGhS0KT0RHbroYfTe0UGRyaWLUzvlbUnr03p
mLz1lXszD+cuChdVvpLdZPjcnNWZ49Nz0lWiZ97unNPdZmccN/YxpmRe7szw9PbDEnPSh+XXFE5K
1GbMS99ZOGfUrKyd2YcK5ySKqmsyFpt77pl/RVbjxHj5f6Jv9dzEpPTliUT27Oz6iS7hpqZfr89b
EO6Z3jJ3WrhFwbhEVWJ6jz7Zp81dfhieVd45b6vp2RMSY8KzErNydvU8k30oXJQ9ul2QuzFrT8Z+
GUcq+5h76h7pEytpv6doa+b67NZVK/MjFdmxVZXrIumR1rF9JfWzNmcf6tG8dGuPXUWT8p+Ub+7g
soWlbQomV4+MOtGge3b+2k4tMg5lre2/KT4/Pjk+sf3A4hnyNf11UTwWbVM+LpoXXxxfmjs/PtxY
XzJcJN/Mw+1q8/JMmV5LrEm8ltmmpE+P9p3C8cEl9cNrcveWXDnyUOR06RnTC09n9YqGr30l2je7
dbR/yZHo0IzTAw9F50Rn9Z9VND5rWNaw6IPhNeEF1xzNipTMj05vd7S0dlRRdHz6qrK10US0KD27
aEnXnHD/aJfogvyc6Kbwkow+hZmdguikAZtzt2RsiVaVjsk1vbW4Jr667Yb4xviWzGUDZsR3xQ9l
Hmg/N+9wwinfm2iYaBiv3+10/tryQ9njcofH18W3FxyPHyk5XT4ucrz9ntJlVSdKt5rxakX8lXj9
kvnFE6Jb8w+2q41ujR8PL8ue3HZGfG/53tHNKjaUnum9JHwgsSP/WMXLV3+R2F2+Nz87s2n0tbEq
fV/26ezTkcH5q7rmlFVWLStMJM60fTyzzSUtEkeLa3JPJw4n2mQ1ztqZOzOxPrFpbFrFjMKiIeMq
IqPTEgeqDxZMDm8yVvZhesuhh8O1+Xsq+2Q1K9kVM2N+bGQsJz0nf0OsW9mGyJV9J5W2iEyLzKw8
VLyz7cHy9FFjck9HVuctaeXE1hYfLJubvzx/T2xzpLVp+5cj7SMdyh6P69xDWc2yauIdYs1Gq3aZ
4R3RAyXds1oW1ZadKktGxoXXZ++PLIosGq2KPizbkN29bEPWqsjiyOLwiUiT3HUZGzN3F6wurqw6
2mNc9LXo7qyDebvj3dOX5y6NNY5dEe9TuSt3cXn9jPpl+yLbY7fEJsSmxu4pWVGRXZFdWhQ+UPhg
7qL0nbFjsVOR2aVnWrXJXGNmxJbxzuWdK2PlfcyYPbSiJHt13u52iYguM7UWezjjePracMP0SN6B
SOdYZWRFxdrM9bG5WRtyB1cfy9gfqR8riEyMTC7sUrEhtjC2PLbN3GcyXj/ePnNSXpEZD/KiZ2Jp
0ROR0dHDkbL8CRFjffFD5XtlPcX98Ptfn3z/65Pvf33y/9yvT/5hxbXxrP85nhiWM6Kv4w3LLh1s
/lXDWowYbtj08l1G17C024jO5n+6/xrHuzpZvGpAmqOuPlE83fzvaPGSEWHzv0MjWpv/7S9tNsJE
MFfvKc00/9tZfE+PDt+OEN9GE+4ObyF7Ezo7/Ryn0Rf/y/fY38mnzDf5b5zzRV26f5G2sbbfb+X6
/yJNfXtd+ZdvE/Ntbv/lePrfHfsPvv9Ouf9leVqbb3unXyOHT9Coofk0Nf+2MP9r2CjT/NuGT16j
IvMJm3+bNupiPk6jnubbgk8X8+3bqD85DDX/VjUaYz49GyXMt6H5f0/zGQ/lXysVwaHm45D/JJPL
JPMZQ779zWdKo+mmbft9v2OhbseC8pVTwL6FQvYndGB/Qkf2JxSxP6GY/Qkl7E8oZX9CGfsTytmf
EGZ/QgX7EyrZn9CJ/Qmd2Z9wMfsTurA/oSv7E7qxP+ES9id0Z39CD/Yn9GR/wqXsT+jF/oTe7E/o
w/6Ey9if0Jf9CZezP+GK71vx/4tWdNVczW8O3ZeNH+WkzfvHb72h5ltlvmPqdK98p//ntP/OV/Kp
l/hf0sk1lpp04/9Jv7juK/KK78oi//53eSjvf/j9t8q+4t8o8/9wz/9Qn//htaX+v5UnmX+3OONC
NXwioW2hAvPJCd1i/rczNEH+Rn5oamif+b98DvL5wnwLjP4ek2ZCaCFp9oWOhU6FZtTlkkzTRj7G
+RNM2mFp8oKiJlD+tVJzYd2V5TPXfOTfY+Qon23CtPTvaK5dYMqzJ6113ad93aeD/VBuSV2WZjwG
59rv36r8L96q7PquGVHk3codebdyEe9WLubdyiW8W7mUdyuX8W7lct6tHObdyhW8W7mSdyt34t3K
nXm38sW8W7kL71buyruVu/Fu5Ut4t3J33q3cg3cr9+TdypfybuVevFu5N+9W7sO7lS/j3cp9ebfy
5bxb+QrerdyPdytfxbuV+/Nu5QG8W3kg71YexLuVB/Nu5eG8WznGu5XjvFs5wbuVx/Ju5RrerXz9
95bxvWX8HyzDdfPcmUQtW5yOxj622a+ab/49+N3/vTz7Fb38i67IfMN/l6aL+fb87v//8it5Hqv7
Hqy7zj+l+fZai+u+i76T//vYt8cXfVuejmpO3edB81lgPrVwiVqmVprPHLVGvabWG2mBOb6yTjdH
bSJdLfqt5rvDfLbyqTWfNeYMOb7G9KHGdX8J9sNv/xKsx1+C1fp1vc1J42/ApvM3YLP5G7AX8Tdg
2/I3YHP566/5/PXXAv76ayF//bXD/7V8TQwq0V/qZOo9x01+gXw6td/wTOoLw1Op3YYnUtsMk6kT
ht+kPjBn9ZOUTgxe6U4z7OOONuzlDjXs7nY3HOauNOkrOTrQfdBwsupvOFHJbsBbVC/Doe6ThsPN
SOM6Y8zI4Toj3a2G/d17DMerdLmKe9ywyni7rjNdyduiB7uLDB/gWutJr51mhoGTaZjmyFvuHCmt
sdguhgso5xXuJMO+bo1hxD1sONr4yK4zS8lTvplqjmHCTRpOVRHDGpUmb8tT8rffximJ1x9Wewxn
qBny+1N1wHCJsSvXWeGNNNzqnTHcSz2s5Y7kvXpSwzD1GtyNxpQ29VpyieHy5GDDpcluhouT2YaL
kiYuT61Lvmy4KjnRcEnSXCX1eLK54YqkuVZqwdkjhrXJhoYLz54yFnENe5hzYFtIG3mVUhtePvKj
sIodVufCbKF6Bf4KzoMb5Cy13DHzgHofzUPwJDlcCUOk+RT9EXgL/BjeRZpM5KasMLyO/B5cC5+G
M+ADcDVn/QAuhgNgB46+DRvDKZR/KPLFpHmQX9eugs9xxVvh9ZCyuZfDElgDx8LR5LCEPHvC/rJC
449EJmd/LmkuJH9KqHbV1bCwNWwJ02EP0vwFuTucDW+At5HnE5B+pCvQXwfnQEru/YI0nKUegZMh
Vq2Gw7vhQDgI3gQvgvdI31FYiGoDOzqLDYtgDswXumeR20ofcT9HvhjGOZqknPfDgLJRHv0wJRyH
xoVdYS/4gKsNc0lDafUe9L3htWh+LmnUVMr2AqSlvKcgrWkiPkn5UzQFyNiY+gh+At/kKFbhRdD8
Fh6qs64dRv84LU5JXFrEtbX0AdxPztYesElvEaQ8xiuQNLvRFMHb0aD3noFhSns1+p/BdZAWV9aK
CiHl132QJ8CbYTtKVU767fBV9PcgM0p71LmHrXrz0f8Q/glNK1ifkjRAb3uftahhyNieoi3UX6Gt
2xbIC+EvHDM+e/QRz/a+NMpsS2Jt4JdolDvMyHloOsOd8CdwFiWxd/ca8kzIaKNtyvForA2jUX9A
v5k0m5AZWzwswaNHe++6BYZ2BOgELyWfEfBG+ARpsAFNfXrdYF+u8jz6FHW+lZQ3O4MMpzt3Gd4q
svH3BlHbgxj9hMeF6gzyOTDs+owPdzFOiuZX8E34llBfj9xZaDw04Snj5bhec/StuKJHzu/Ap+Dv
4HNwM/wEvs1ZLWBjeAll+ANHl6L5An4M/wK/5uh4YVAgdGMwDq+BU0n5MvJIOADN69DmvIZ89sG9
8FH4GTxMmoDaO5d7X4/8Afr98DZ4O7yF8uQiL4K2rp6iThZw7p3k8zn6ctgFXgq/ggthKdwKu8Gu
8HLYnhI+DP+q6hnNTXXlkWutQ14J74Xp8AnK8DfkKPwRXAu5R7UEvoimitI2ofbGol+MTNu5E8iN
PBWto/7IWcOpB+5Ov4fmAY4eQ6Z1PGQ9H3kW6UPIXEudgtyvGo2eVvYyoE3ZtO6+3jdMUJJV8HFy
PsK51yI3gJe7zxtqzjoKd6C3VkGd6EOwJWwIz6ds9ciZ1jGRmqTHZkwMKKQ1fazFx85928v+TPoh
aH6NJgwz4SSOYsO6NcSGjT8jcr4zwnAaMi3i/RTa0tbAj+AeuAz+jBy4d/8E5/ZAttbVhzrhTn1y
9i8gzTRGjx+nas3Rs3Y8kTFEPQX/nNwpnhUyo6h+SDR+lJQnRa9Lk+ulTsQbVB8yLt3obKaNNotV
MCJtEm9QMWsoO7renvzQyI+jf4n8HxH6s+EU2A09XpCy81EZvAP9uXCInfuQ/wQ/F99b4XcpfMgg
V8qs8UN0Pcgs4D/NVZ6Dv+Rc/BbFrKqeNX63uQryIDnq/g15COnjzmmTzyVo7nTDnGU0yqUe1kFm
WIW36VuPaxpppsNLnQmmHvBGvH5SQi+euszo7by/mvIwP7r4aeqtuhk5ZlKOkujAuyC5UPwNoYfX
pEtpkTLxf5S9o0LJ2X1G/HCNj6et79FNWtx7lTQjYJyWouZVD+6R1vfSkxcazUTrjVCTTdG/JHma
mM540Sa6Fs7Foy6Ez1ISvAu9ztqPRBbeZKEqlrhG4W+Y0cah1STNJ3AUmuPUW66k1yc5d6nUqrec
un2GlLfBX8CW6N+UiMz7jHux1nKMGlbIN5Hyh/AdGOVevpLoRuEJu39NzjIyHoh6jHyY5b2LksfE
5oWm5oUd0Z+TfF3Gc+kF6ozEOOqktI56W+zQiyLjFavL4Ciuexl8QOJKjden8Ru9MfS4+zn6AryZ
mrS2alvqSfE29Vn0b0Hr6eEFedYLqob0U28b/D1XIcLyiWJ84ikf79R4Cw6jhJA+JSsdhj+HGfDP
8DBnUbf6N/Az9LSjh/+j8Y70GIjlaEqif0caYi6fWEOfQqY/ei+hwd/zqA1NybX134gIPK7oEUF4
v4Y/hutJie/q4TN7NhYjsjBzhMO8KSQe1CuQKaeJe6UMHnobv1iZPuXZ6IZxwIzbQkYknQWpGW3j
03eRrZ9G3KStH4uv7l0F30GPt6/JxyP29DbCP8LPOYof6BEdaHxmjfeoqT1t72IZbEJKa+d70VhL
IKLRzWAIPoje+v/W0yYu9p7kKBGEtnGKjRrwoj2u4tmYgljDY9wz86PDrC0jkvX2qUmFpXk2zt1n
+wjyTmcvM53D7Cka68ljdYp4Stsy3wfxcrWNufCuPerNG4zGjvxfovGRbTmHq2ZGfhnNAbmi2gRP
wLOUgQjFOwCJ2jSxvLbxhY0Lyp3lhtyjvrDuToXN0WQjH0W2v7+28a/V94cRaoY4XVFmhf0obN7b
ACeSg+2tNjZhrcDTcDm00VNDSETvNSIlPcj4ySLbMfMraP9Ol60B+pT3unuLIz6P6G28fwUkyvCw
ZN9GcMwaHtauiUf0VDRjyK0KeapTRb+rwputokWqKJvwGzgAjoc1zlzqX+R74DzOLUQeJPSvhb3R
DIT9YTlMh+fDC2Fr2Bc2glF4rVzLWH4V3o5onoYroOK6b3OUuzBzjehnI18POde7A7aBHTgLmuij
ijFN5CXIryGPRX4eckeezbkH/AzeDrvDqdhGJVc8ieZeE9NIi4j8AJwEY7AfOT+EXAHbce7HyPnw
ajSkVJ/Ce2Efjk6HXeFP4AzYDXaCH8Kj8Beca+WGMBdeA6vhefAPlG0K6ZNoXkDjy9qmV4tmKZo0
eAFsBimt9wjyxcgrYQTNucil0NrGdfAUfJQ0c5A3IFtLGEJJvqqzPWEZ1mXnPkYVZUf+r5HtGggx
vmbsDbH2FaJPhex6F+tOHt6jt0A8DZ8xyrcrWsxB6kcQr0DZlT16q2tXF9dDxrEAPzNkVwxsvM/6
jM+46q2CtWgYo4KOyamORHCS23GR9bv4CXZFYiVkTdKj1wesJyjmbsWahmKGUvRoxbqBZuTXrLpo
5kfFCK/OygqtV0+orSds+z6159oas+mZbZVdJ8SPVXacHCHnuszUyq6FXpVqQrQlOXzM0XfJvxhe
LAzZldKH0QzkXDx2RYTicl+autV49dqO+YxgqjsafBi9FVqf+UG4hposhtRMYOdi+1vdIjS0ZoCH
pllf1XdAYhZNDrpKfGb3N9QPabz7kVcK1djkFilbqoNJsx2NXdey6z/MjHoLV3wMkn/AOrCycQRz
rk/Ovl2VYsxXzJiKecRjrTvADpVdpbwTYqva+nXMHdp6DszFIVZ0lZ2V8AR8672wWugfRR+hzHhf
Pv6VZs1Tl3Ius5smBx8q1jYV3oXHCrli/VnNIZ/JcImtB/g1PAg3Q2pS0WoKX1TZkrcSvd+do6z2
u2cl1gjwkwP8loAVvCALa8H+1T7a4kZ5NmHmJkOfvuwPxt44qhoiH4YfwP3k0EGeYug0NH8kZZw8
6YMKL1TNTAUmN7vyeaNT4charqGPJ+nb+IsWcWPJmwynEB8NF6oXKdsFnDuQsk2RpyqKVjAzo5yL
v+ryhMLHT9DWBuyqNZGgovf5dt2PaFQcVSPjq2vrF7Fmq+1a9C0yUum+3BHjmLYr3jbyImeV4q7f
pISzkTVnEae7eCma/F3uQrNur1kFVdyRtt4jq50+67p6fV09yL2v5+r0OG1Jn9XWGz/NWfgtns3Z
epKrkFnr1oshnoyiF6uDELsNrNdXzXoCHo6iPMp6R1ivT+wc7EPDir3HuOfZpzBo/BXSfxVr/iaK
l758XfKQI+sqDnOrpGEl3LNlwGfTdpTm3pWNBezTq5+n3jQaVo+V9Wbpv5rVAMVqsKa0vvWN8fp8
+qmPT+vbaIKIwLfPR7Bn90uxHE08q+2cxZq8T/6BjZgYE9KIQQLyCSi5xp8M8Mw9vFDdW1ZpfPqv
tr4ls5hmvV1bL5TxysND9nLEfw7sTMoTGZ/oTDGLKdouYLwKGJEC2jRglAhsVGVnH3sV5g5NeTSW
rJmzNGNLQF/zWZUKrNc6Bd/+SymD96I8pTV+lMgN4A/w8IkKfWZkbfsLM0JgY1jbaz4R39639Y+t
6hdZs6IdNZ6wb2Mxni/4Nn607Ujk69le2Yuz7Boa6za+jZHvRUM7ap6beIzMmnhHs6qvsSKPdvFt
bE6ZAxuDk8ZjZPCYlUK0uM9srpeKP69t7yM68G1bW0+eeURbiyWm8+3MSHsF2FuI+ShtBvqbrC2x
ksDRgL4ZDGTNwT6T4vmCGkuaML4WvquPf6gvg0dgER7XTnjMOepIbFvFuFFFj5az8EI1Xn0aXl/a
ffJE20Syom/JuTayOAj/CPfCLXAbKUtgFzhQrmX6lxxdhOZduBvNMGHwVzxDIgWFl2jGLmEVnEvK
pyCevM/VfbzTwHqb1rO9H+LZmvFWjh5DJmffRhmj0ePf+svQ4IWaPiUkHtFTrZ8M4xIRaHxyjceu
baQzAe6W6EBfRG74tNrGX/j8uhXXsh7+Wfgleuszb4d/gQfQ58DfUQ+NIfeuKElg4471pMHnDzVA
JhLxlyMTnelNMBs9KX1iH72KfL4gnwfR2AjxFfTkEJDGp2X9cokUjCVLynVo6iFzNCDqCfDzNbYU
PAyJ2gJiBN/W7S40Nq4h+jPzZhXjm7AjJEYImnP0zzCEnlhVk8azloy96d9AYjd9F+e+BLFDTbwT
YIeBteoEub1PPsTm3jjWGGtlF4o3ijXM5+vmiG30HemheIkBqw3+G5A52rfP6Htx1gxywG/0OqFh
dvP6IW8R/0Tz/FozZmpWUFVnjo5jdbQNM3s3mA4v4Syu6D1PXGNjnHmcdQNpypFvhLfDO+Cw1Dg8
OpEHwrmU8GHk5nCwaHzmRG3XxnPgJeTcHpmSqDI4A17MuU3guWhYr1B4Jt4FQvcr9D7y39A7aJrC
/nJd5ST7Gr2tgR/ALNgQerABJbFz3E85F99SH0XDiqW2o65d/avHWc1IuQn5PPg4tCv/tIVXJvXj
cXdeJezJtRT19iUpvyGNXS0kmtOFpHyZlLacjOHeRcjbkakl7xzSsEdF25W699A3hmFqYCdywGp/
E1qnmOvSvupzjuaRci2aOXAFfAJuhh/DF+FvbJ5wIRpkN4VM/ajXKZu96+FcvT6ybf0vkNtz3ePI
j0EFLyTNSXJohIwlKOZE1RU5AomOTXwh8nZy28STLGszv4bUpPFCaRebEu6AB6Wl1GlaQRPffYnm
ozo7mWjkQ8i2JC/A38Nl8G3S/4o0heTzMJoXUi3FE8ASFsN7SZOJjCWrQ/S+K9EU2esiY9VeD9qL
XuxFGCtY9/PtzpPmpKyEE0lvfTa7z6F1XQ+VPCsgKXWI9Ha/Rwz5KvSzkYdzFbujIAuNXdvvh9wX
Xg7bUM8rucpFaPpRWh/b/oor3mttlfKcJE1b2BG+JTloG/8eRjMOfgpnUSqiP03Mruuh7wyz4fWk
YS3Ff9H6V1KeEB5gyO6HYYQJ4QH6xImaEUxfLQxYhdasqwTbrXeK/jZb/+oJGalkP6HqDS+HO9Qd
JuXr6hHx5aBdE74J+XbYQ6gecA4ai3pL6sQ9xZO4s6zb2LieWEntltyUjdDPJ3+762wb+oJUpYzb
1OchNO+rToYLkWskf9UNpsPrYGvZ/ajyU7PlivAb8iknn4myG1CtJodJcJ3Qu0bO1W+7jY1mkJRE
s4rlYoGuXdu/W/aVqRGyyqoHUA9ryeFK8h8k9LLIbaTsb1Q/VTniMcoOLq+S/UvLU2OM/g3ZFale
Uqsd2fkjZf4APq1+ZDiBktzrvCVjkexgVAug5jmdffo8T/ZbmnH+JUeeWu6S8cT9RlpW9jfqW4Vq
vFzFe9RdauQNaJzURvGXRHZPyj1689DnplYZ3srzuIek7bz+stdRNxAP3/jqm6nt5Ub/caqr4Vlq
so9T4sgK1QLspKdhA3gdPE/oPSc08dpiI/8MOY09af3Ik/jL2H8b6U2wLbU0j72LX7H7MSGymYkk
usmVa2lmQ213OlWIxv312fmM25Mc2W8jUVIxJbxPclMTYQzi25t4U+ThcDzPo4eIrO1TmBx5vunS
O8w8e0wsCpnRQN1ASUZz1+enrhS7Et/VxPh9DEdhe72FHrJOpIYxhxqbcR8528vwWaHKwdrzYC/O
qk8NNOKKo9G0RT5Fbh1Y22kPe0psrohz1UJsch6cDwemVjryJF3kMc5kRyLuPY6sGBwxnJU6Ir6H
tJ37fkr2CjJiqO7UwO1yLf+XlPxiKbnCK1P3U1cR7GEoLfK0WLu/Bcs/SWkH0JpReCkpGzlTZFSn
Hedz1nZXcsumlfvyHPkO2tRLTTfyJmzyILmVcMXR5PYwdX4j9dwAjuLo05Bndqq5REB+M9qdJ1ym
PGJFreAlQvcvrE9+IzRH5dxBcCn1mUscXUM536Yvl8tKiMuamxop+3hNr5FzWUV0P3VbUIcdyEdi
4d9R8p/Lubqx9DV1G+X/ETmvIM0c7uVm5NOphx1ZR5I7upiSJEifTp4P04/OyFXUPmzjG0Z+j3sc
Svoa+ANGj2JYDtdwFfs8cTxrO1Wk7EnND6ds+KWmt4v+Gq47hRa//awZr9STSbGc5bZN3daO7G2Q
lPnYiR2xf02pWqG/G/Zh3t9GGi0jhrGHHZRtHfFUIV7NFhlbmENnyK5vdZV7jrQpfD3VCbkFFm7S
q1XsQT2EnIC1TsqRFTzJbYik1NvRr3YzDJcJdQZyROjtQH4HOxwpJTE9QjiXoxOkzGbUFju5ldav
Tl0q9ZBq68iuifMc2R9yHm3UUVpTZP0+mn5cdwJyN2QXXmpLi/5Krh6GlTDK0VEwAz5Dytuciwzf
cn8oJXQvxjbMUb86eZaY2sgmQpf0vWHUedQczXQrsHDR3EDNnEPNLHM+d+S5npz1W45O5Oq9Re/+
NdXAyI/BCo5eCLty7mzkAeQQh82dq+nLkhtX9xqnSvHofsZ1C2ll4X3cS0fku5EfE3ptnAuM/AG1
/SJ2QhrvPedrR57NibxT1rXUXZLePSRzjZnBG9A3Jbf74ePubY7sL5L0X6KZAhdJPrpp6jdik1z3
cqF/q9Se9wPSXCM1pi5DDsE3KUl3crtW1lHdPSK7czn6Im3dktxGSIt4gSttNJaj8+Fijl4vpVU3
w4Xo21OTD7i9ZVwVGp8z1/AK2FOorufcWW47Wkc4Uuh+lTrfpBldZ7eS26vwLfiQrWdsY4jcnaom
nxthD9iJOr8vddLIf6BUDbivd1Ouka313is1pj5LxUUD3yPntaksw6/pBW8nn5NeSW77qaVhtONU
9waJnpA7WWskzyHU2ATufTL6j8ROVAuO9oeDYWPGyUzSr0LTx+0naWjHPK54hhZcKL6ofpORjSdE
oXdEExolvlboRqFfCC8RBkckZWB3m7B6HNhnWD9iB9ez4qsHdl+63c1io+DLiNbZIeazw6Qez/jS
iCnS2Pmj+5ByJt4+MbjmmZSexuqB/XVGexmfQzzLCLEHJsRqubqC9KwzKCJx/QQ+vH2m0x/fmzgx
6Cb6gPXSENG3z9NJvwX+PD58iDWQ0A08l+H5pj5GGeyOCGJVzZOFEHcUcK5PeTQRrn4X3gzHErsR
S+pB8H5qwz65I+bVPEfw9lESu077Z/JkJdan9jRPjjwi6xDP+wJyC3jKHNjnJnlo2hI1Ewu7B6iT
EPJZ5FbwWUhUoi4jKiEa1XY14BTyuVIDLiXRNhJ/n/TZpFkDN5NmL3IHKae7XtZGFOvVujvn2ifd
XF3fRAntVVjh0ZRHE90HPNv1bUvZtRH7BJDdRx61pHmqEnSH7IkKaAufZ8ohnheH7NMBnidqngQF
9iktz8J81l58rhUaA+3+nDdsmZE/oYTtaAW7utVE2lFTk2aGFet6EH6OTfIcM2Qj1s+wMbv/x8GK
eCrkd0K2MR3rA35DmA7xq0M8bQnx1C8gOgthDz6xs387KdnhH+rF1eNoVnGUXyoFNg134fM8S+eR
8kL05yCn4AzIrq0Qnn+oBWl4Ihawcyxkn++Xckf2CchcaoYVD9/ulGPFyVtNzeTTf6OszNyAfCdH
6aEeqyveKuzZruOVQvZYeiNtdAyvgdXkyUqL9xS8Dt6NHdKynu2b59o+iJXa8tATA1bngkyOvgGv
ZX3ArgixvqftqshJa89oNCXnl2i6C3os3Oda6gzcABkx1Kuk70zOrDd6NXAwZATTvZGHwLHYyY+J
3/+EfD9pWGn0TrCrlrUpfT6aT7k61uhNgbkQi9L1sEzWf4Lt5FbCzLuJo6z/+DXI1j4pv29X23pz
VokwrT9HE9Cu5dq1oPfgRvI5QT5218qHpGnJaGZXPGw/fYX25Vc2ablWw7WOU0uMXd495JMG74Os
jQT2V3J21hiDN24tljUifwkkOgvsszBGaT0cDuFeVkJ2pPisROkw7MJdnIJfY5+/pVQf1a1fyV0w
LwR2T+AbjNtzGd/Y9xgwVgSscfl2XZT+FdjfbdmSNObqC20+XMuWmZnORHaSxnIqZC7TjyDfybms
w/sDkGeQD7smfJ6U+Xav9VHS00MDe192LCoijQPtU2OeS/o7OGp30jJeecvRLIR3Q2wpYG9AQOsE
2cj59iq0CL1V00PTfginQ1bCgwEcxfIDenpAGl2CXF03p58j3kJdtGvketNkD3ZakqdUD3B0F0fZ
IRCw1yUYCCcyIlE/IfvrP57eBqPtHI3G7qvsQD5dYSUsE/rpkOvqGmHod8JgEZwB3xCamE54M5oJ
yOWcdR9yIRwI+8Bx8Dh8CD5I+mI4HvaAnaE9i3KaWEM0A5DbwOuF3lnktshp8GI0F8JO8Dp4CxwJ
b4WHyPNeGIcTyaEX8q/q7FzkjpDy68Gcu4m73kpdDUHmfvX5HP0SfkRu1Ke3kaP1kF+Fv4S/QJ8B
bdlsmsuQr4Wtyf9S0rSEHmk4qkfAG9BQft/KM9FT/yYWNtYSsk+lX5Ln1z7rVyF6TWDnTVrNZ1eA
dwr5D5x7HmxOnn9Dz72bWEZKdTdHp8E5wrQ18B14F2kWQmtRLyCvQObcwFr7HcjPcRW8Ze9XyM+L
zQfn8xuE2WieYfcmreBVQ+rN60bZsARN7XnDKSctqGw5sVLvdjQROBXeiX4YxKpNjCn6KyF6Zc/F
/j1bw1i+N4qjb5L/TWiwJe9yOAj9Y8jvQ/qaWg2fhffAv3C0O/KnyA1hI3gFxOZNrH0OMaDkbH/1
04WjaLxJ8EBdu0vKM2i4X30Ju5Eno7G/i2yP/gI09D7vKmpyOXqsVNcKQ7shVh36LWloTZ+jGgsP
diDzq43APtn8xOlhyLNU3/4a4lXWoxaIPo0nrWknGN9YN0srlbXBNHZ0pE2TFTzjc/agtLJ7nH1u
Ab+5cJFdRmN3MWQu8NmVEbDLJcQz2cD6t3aPfRvJ32PnmGK+0OdI/oHdOT+GGmC08W6E06EDsVuP
VvOwKI+xRduUP6NmSmFnomNGGP8T+Axtgf2odpCaV/QL1Q8ykvh2pMohzzxkO6bRRoqxSGEbiv7u
7qIMtKnG5r1lkBb0VtX1GuFi0mNvLq3m/gT9WmT6gqlVIaOi+2PIGOIyDrv0Apc+5c6FjD8uM4WL
PbjYsLcSPgWxdh+r1naOaAafRm8t1tYAtacYZxQ2phhPvCz4RzQvchUs032UHBgNAnYHBfYX3OzL
CohiArsX0f4WzO50tb+D/i0jCXOKZ8c3Rm8vn6vYersfeQ+lpT79BsjsVQvYlxUQxft25/9xRld2
pgVEUgG7qnwsNrDzNfuNAyJ3n10EmvFWs0crYEdTYHeyMdNpn5L05epT4Ho0tq9RzhAzThptlFZE
mhR14pKGetPPc9YH6O3Y8ntkbFvhMyi7n9nG0fbX37+08Qsy3pSyv4C2uyXtL9Z5kmjGqELaUdZe
2iH/F3vfAZ5FsfV/zszszM6+bwKB0ELovYciXXovIfRQJYROaEnoJTRRioiKyEVERFQsV9RrQa+A
FRWVi6jYu2IX7Iio35mzq5Lo98m9ft9z///nuXmf/GZndnZ39syZOWVn9wxkzGS8npF9X5L9ijKJ
cQHjEsZDPGr68jZ7BWlmc1iDsSoj+wkl+y1lMmNpxh6M4bGD2fNzmrevYLySS9i3pm7k7SzGYbyX
Pb0kRxzOZhSM7KNT4XW/4+3FvM3+Scn+JRmWLIx8ng1YKjXgceeQvaaK20P924DlgkP2VdIc4jCH
sQnjDMYB3LZjvN2R8R1G9nOShHLYkDGkc02u/y5vV2HsxLiJy5sz8n0JvgrpdW4v+2lJ23EldzEq
Lqkb+dkcXspYj5F9vKTJOHyR8QI+KvQJf8slPiP7+tRKxrBO2Gvs1ZTrGe/kcvadqnwuYb+iymNs
ySVPMG7hkpAyDRgzGPcwsn9S3s11eNaVOxibMr7HeBUj+0sl+wblLK6/hjEsv5W3mYtUOpeMZeSW
KOY3j9dGKta3DX9nwPBzf83bKlw1mufW3OrwzaOtrNWHngpeYaLDt37CVdCZbFt15jobeC/bJpr9
eKIC11nofIaa19NqnrXEd3x+tqq8N937CLiH30p4k98OHuK2RfMfb3E6CZ9/H7+/cA+v6+b5ygtt
t2Q+P68dwr6Mkxl53bjXkfeytYK8cga5nTiOMZsxXLV+hDFcdf8Mr2SO8bFspeJxLv+KS3L4qAmM
b/LeLdHqfXdUd8Zq7om5KMXl/B6EPMTbvFZcsAdP83otOYTbyeuukddJItMEw+918Gpbjy0gzf5P
L5xX+Q1NL1z/HL6twP4ZNYifB4XrmsIVTew5lMO5DQv46mP5yVEP93TMsOWO7MFDXm9jwi/hhOu4
DvO1wncqJ3L/hl+hCVfhLucS1sY16+GKV0N5Yf/yCljkNmP4zma4CpS9gobX6hvmE4/fbfHYe4Cz
2LfMa1a98NspvJZeMZ0F+3ZkyFEH+Y5Kh28B8N7wyTJzL4ZvB7D/QYT9u55xHR+VxNtPMt7JeBfj
bPemLZ7g82/ktffsm8KsiE/c1ftwzT3cqub8NL+fe2YtRzj0+I0Yj9e6C24bhjxzlPENPupH3t7G
5+FvGcnbGJkD8UG+1lbeW4zLF/H2ZYzPMob0/Jj3Tne6JY1l94z4AI8plnfIHgDgqwNfEb7gY6/m
o2qENOTzvMutCr+ow/oksudcpEUeAFd/KB/L3ntxiuuHXxO6j/cm8pvL4fqrZRG3O07g9dse+xtx
N59hLd/dIEaWwshXhNN8VLo7D77GyGvLkeW4V5zb2YWvy2/mYrj6aBCPnTFcJ3zb4jAf2yXsfcZP
XYkXvvHaiekTPtfm2cDjNdjyea4Zjuu/sg8nfEcpnAEy2C/UjX0p7H9G5k8Rzn6neTTdzUfxO/ji
NebhfLdGBdnTLsK1QD/xGs7buc3h+0fhm7AbeEXKx6EHjM9/iH0yD4Raimu/e52Uar7McyM/kcHQ
6tnDJWui2fgBJ92YAuE7mxX52BNMH36jwfAacp/nCj98oyH8is4NTA3n5YPwe12Y4w8CmT0/NweS
J+aOnwpzcrLyp8P17s2BgQM6VQbSmH76CUpCHDSUg8pQAuqRRdIC2kEPGAxOPvSDLJgI0yAP5kd1
E8BAClShrfrQFFpCe+gJQ8DxZgaM5e9958MC4GX8XD8RfCgPVcHpR82gFXSAXjAURoGA/pANk2EG
zIaFUBpkz4yMHtBlQL++lWH0oAG9K8N6PoPTzi2kQjUoBQ2hNdlHXaE3ZMJokFALBpDePAVmwhxY
xLUDqADV6WyN4BxoA52gD9SGxbynFBSnvRWhBpThr5S3hc402vvCMDiPWlsHBsJ4mAqzYC4sia6b
BDGoBDWhLDSGc6ELdAe32nkMeFAXBsEEyIFcGrEFsDS7SV62FIwBYwnGFMaqjHWzs3LyZRPGtozd
GDMYhzOOy87KGy+nM+YzLmBcyriKcV129rSZ8lLG6xn3MD7F+CbjVw6VGDd9xjSVzJjCWJmxJmN9
xiaMLSfkZmWrdoy9GIcwjmWczriAcV3O5IlZajPjdsZdjLflTJ89Te1h3Mf4CONBxsOMRxlfzZmR
naPeZvyA8QTjN4ynqUquJxh9xkTGZMYUxsqMNWdQ4tVnbMLYkrEdYxfGXowZM3LHTfeGMI5kHDvT
lU9inM6Yz7iAcSnjKsZ1edQv3qWMmxm3Me5kvInxtrzJ0yd4dzPez/gQ4+OMhxify5uWPdN7mfFd
xs8YTzrUgjGel5fWWJdmrMhYk7EhY3PGdoRNdDfGPowDGDMZRzOOI2yqpzDmMi5gXM64hvHSvNkz
8/QWxu2M1zPewngH4558ooDex/gI40HGw4xHGV9ldG8PCpo/Uv6JVNKMUA2q/0tbCAl/iD6NUk0z
lU9zR0Dj2K20NFHZryW/V+tsy7yo7NdzF97vrN2zQ0UzUxLNvSX/he2fr/n7ewXNdvX/hxSh7Fmj
5OMkz+zum5AOMZI0DhPPGsucNVb5DZY+a6x5Fpj8hyhJdlWAiv/UViptVWJquYg1Z58i1PlDFCR7
6v0TKZJU/2MsdVbYmqTsKthE+sPdcACOwjH4BjU2wy44CMdhPq7EjbgT78RH8Dl8F78SSiSL6qKZ
6CIGiXEiX6wUG8VOcac4JE7LurK17CWHyylygVwjt8ib5H3yoHxZfiRPqUClqLqqteqlhqspwCsM
wQ+5TZ4unFfFi+SrF8mnF8kPOSNPnKxywbllwzwpaN6+wnlz5vUoH1TmvCJOLk29XTMsLd4pSvtE
6ZAoHVP46BJFzlZyU+HWlJlXuLWprxbOV1hfJL+jSP7uwuevcLBI/tXC16twsvDxFVsXyRehfsUX
C+crdSuS31Qkf6zw9WrMOSNPM0jN5CL54YWPr7m9cL7BzCL53CL5/ML5hoM4775fWyKkQMNVYdoo
8ff6sdEdUXp/lB6I0iO/V7tx8ShNidLqUZpW+K4b5xRuVeM7iuQfKZxvUoSKTTYXyW8pkr+lcC83
ufUMHqaNZn6RfN3CxzerXzjffEmR/ObCvdT8vsL7s4pwUdY3hfNjgyL5eJF8YuHzjyvSi+Mz3Xej
iZIT4QOyFz5hKeTieQHH3kI1T80HEdZRi9UStVQVcJ0V4L5MeiGsJtvIxZyVVFoCtN1pNttrzSZz
qdlIJRpvdRYqfzMe8Q68AwR/OV7yF9kVf5HdC88u02Rj2UQ25YhDT7rvd9NWcfDEt+Kk+E6cEt9T
XolHnG9aHBCPOY+UOAJSPC+ep/a75xY+cVAa2Q1baQZ9E05hMrXKp3Mn21tA2GvtXwl32lsJryMq
FCfZW5lkA9sr5m6Q+AS1+x5ON5s9lD5N+Xs53WxuAEG5XYSbzY2EW+iajvNToKq5FSTd7yazm9PN
5jZKN1L+dk43n1Hzjqjm36Kad0Y174pqRu01V/LVruKrXc1X+3nPNbznWt5z3Zl77PV8jzfwPe7i
e/x5z4285ybeczPvEcS1D7sV+fy9fuTv9Qv+Xr/kr8Yr/mq8Z6+xO4jr2ZvFo7yZ4xmyNQX12lpw
72ofoB+qNJUGQs/Ss+j4pWYp3fF/IgX8J1LA70cK+JWbUpibGvLMtE6n/4dn/sMz/y3PIL7IXBPa
RI046tWf5hXmjBhzRpw5I4E5I5E5oxhzRnHmjCTmjBLMGSWZM5KZM0oxZ5RmzijDnFGWOaMcc0aK
2q12E684/khl/qjA/FGR+aMS80dl5o8qzB9VmT+qMX9UZ/6owfxRk/mjFvNHbeaPOswfdZk/6jF/
1Gf+aMD80ZD5oxHzRxrzR2PmjybMH02ZP5oxf5zD/NGc+aMF80dL5o9WzB+tmT/aMH+0Zf44l/mj
HfNHe+aPDswfHZk/OjF/dGb+6ML92pX7tRv3a3fu1x7crz25X13ssvtIVrjvhK2kXwFZQKtgKWkV
F8IyWAPrac+tsBsu4Lihq1nWrIHH6beW44au47ihF8GH8BFcjAo9uASvxmvhMtyFN8Nmjoq2laOi
XcVR0bZxVLSrOSrado6Kdg1HRdvBUdGu5ahoOzkq2nUcFe16kSrawg2inWgPj4uOoiMcFJ1FZ3hS
dBXd4CnRU/SEQ6KP6AP/EIPFYDgshoqh8Iy4WDwER5ymglo8Jh5DI14QL6Av3hPvoRWfi88xIK3m
W4xxdM+4i7qGCS7qGia6qGtYzEVdw+Iu6homuahrWMJFXcOSLuoaJruoa1hKfqpSsDTpZ/OwC+ll
BdhVLVMrsLu6UF2IvVxMNuztYrJhHxeTDfu6mGyY7mKyYT8Xkw0zXEw27O9isuEAF5MNB7qYbDhI
HVaHcbA6oo7gEPWceg6HqqPqKGaqF9WLOMxFbMPhLmIbjnAR23Cki9iGo1zENhztIrbheS5iG45x
Edswy0Vsw7EuYhtmu4htOM5FbMPxzsWDE1zENpzoIrbhJM96Fid7MS+GU7xELxGnesW94pjjIrnh
NBfJDae7SG44w0Vyw5kukhvOcpHcMNdFcsM8F8kN810kN5ztIrnhHBfJDee6SG44z0Vyw/kukhsu
cJHccKGL5IaLXCQ3XOwiueESF8kNC1wkN1zqIrnhMhfJDZe7SG64wuvsncaV3o/ej6KdpmlFtNdK
a9FRW21FFx3XcdFVl9DJopuLlip66la6teilO+vOoo/urruLvjpdp4t0PVAPEv30ED1M9Nc365vF
YH2r3i2G6Jf0SyJTv6JfEcP0a/o1MVyf0CfECP2l/lKMNHPMHDHKzDMLxGiz2CwRWU7XEtlmhVkh
xpnVZo0Yb/5uDoqJ5mnztJhrjpqjYp55ybwk5ptXzCtigXndvC4WmuP+ZLHITrXbxbf2bvudbBDI
QMpZQVKQJHOD8kF5mRc0C86R+cGG4BI5J7gsuFzOC7YGW+XCYFuwTS4Krguul4uDXcGNsiC4JbhF
LgtuD/4mlwd3BXfJ84P7gvvkqmBv8LC8IHg0OCDXB48HT8kNwWfBZ/Ly4MvgS7kp1iZ2rrwi1jPW
U26J9Yv1l1fGBsYGyW2x4bHhcntsTGyMvCY2PjZe7ohNjE2U18Yfjj8hd7pIevJmF0lP3uIi6cm/
ukh68lYXSU/udpH05G3xt+LH5e0JnRM6ywec3HBrf6BHJDfSIu2jOf0P+KUE4W76r16kjtNQdkYl
ZHl4vvuCrhd4AaCX4CWA8Ip5xdjuKRnOYTxbFPDo3+5GJzzHo1PwuJTEO9+hdj2Me10P4z7Xw7jf
9TA+4HoYH6TeewIfcv2Dz3D/9HH9I5a7uxcH3J2Jp92diVfpqkN4zgSeM5HnTMFzpuQ50+c5M+A5
M8ZzZpznzASeMxN5zizOc2YJnjOTec4sx3NdBZ7rKvFcV5nnuio811Xjua46z3U1eK6ryfZYLTfL
QW03y0EdN8tBXTfLQT03y0F9tg8buDkKGrrZiWTSKe80ySQaR9DMjSM4x40jaOHGEbR24wjauHEE
bd04gvZuHEEHN46gkxtH0NmNI+jixhF0deMIurtxBL3dOII+bqSQ3kEjhfQOGimkazirZJAbKTDY
jRQYYg6ag5DpRgoMcyMFhruRAiPcSIGRbqTAKDcuYLQbF3CeGxcwxo0LyHLjArLduIDxblzAJDcu
YLIbFzDFjQvIceMCprtxATPcuIBcNy4gz40LyHfjAha6cQGL3biA5W5cwAo3LmClGxdwgRsXcKEb
F7DWjQu4yI0LWO/GBVzsxgVsYO5tdoZm1NjZZuofbo2KekY9Q7bZs+pZEOp59TxZ3S+oF9g2+3dw
7C+jSs7kljahdlzMHh8A996lJa2uEXFmY3ArZ1tDOygDHaA7pJKeQFwH6fSrBf1hJNnso+nXDMbA
eDgHJpJ+2AamQh4dMZt0iO5wFVxHo3sX3AIj4Da4h+rdC3thEuyHR2EaPAEHIR+eot8cOES/ufAM
PAfz4Ci8BovgDfqthLfgGJwPH9BvLXxCv3XwGXxDmsZJFLAJK2Nt0hzqYSO4CRtjY9iNTbE13IZt
sQPswU7YE/ZiH0yHRzEDM+BxHIij4Qkcg2PgeRyLE+EoTsap8CpOw9nwBs7FZfCBaClawpeiDfXH
V2KYyIZvxCKxEt03KDaTtrBb7MaYuFPchXFxj7gHE8W94j4sJvaJfZjkYoxhCfGOeAdLig8EaQji
Y/Exlhafis+wjPhCfIHlpCc9TJGpMhXLyyqyKqbK6rI6VpQ1ZS2sJOvJeliFOMBiVRVTSdhelVQt
sJtqpdrjVNVRjcdcNVFNwyvUDDUHt3lTvdl4vTfXm4e3ewu8hfg3b4m3BO/ylnvr8W5vg7cBH/Y2
ehvxEW+TtwUf9XZ5f8eD3l7vOL6uS+lUkaQr6sqinK6qq4lUXUPXEhV1Hd1cVNEtdUvRSLfVbUWa
bqc7icZ6uB4umuuRerRoocfoqaK1nqank4SdqS8SPfTF+iYxQb+uPxDL9Uf6Y3GR/lR/Ji7Wn+vP
xSX6a4PiUiONFFcb+hPbjTUJ4hpTyTQR15tmJkPcZwaYqeIFc4m5RHxuHjQPiS/MMfO++Ip4Wopv
aNKvJWN+HX+MbOiP9S+XE/wr/JNyi3/KVpCnbSWbpSrbbJunsu1se77KtxfYK9T59i92u9pkn7HP
qG32RfuSutq+Yl9R19jX7Btqh33LvqOus+/Zj9Qu+4n9RN0aJAfJaneQGlRQtwWVgkrqjqBKUE39
LagR1FJ3B3WChureIC1IU/uDYcEw9UAwJshSDwbZQbZ6OBgfTFSPBJODqeqxYFqQqw4G+UG+Okyj
qxRZSLezhXQX2UZ7SANWZCHtpQn3QdKAfbKQDpC9/ARpwHGykA5BIllIR0gqPE8acAmykF4mqeAi
ypXmiHJl2KYuxzZ1CnvqyssX5Cdk01yrvoSm6muvE6wkq/A+OEK6/6vwPbh4Tx6dr6poJrupTBrJ
raETjWb3nbKxMAVyYQHNQmvgUtgCO+AmuIOsgYdodB6Bl+Ftkk9fwCl0S1vjMZLksb/H7o89yOne
2EOc7os9zOn+2KOU3k9bBzi9P/YYp3tjj3O6L/YEp/tjT1K6l+o9xen9sac53Rs7xOm+2D843R97
htJ9VO8Ip/fHnuV0b+w5TvfFnud0f+wFSvdTvRc5vT/2Eqd7Yy9zui/2Cqf7Y4+AoL0HCffGqGdo
z1HC/X+CIq/xnf899npEmTciyrwZUeatiDJvR5R5J6LIuxFF3oso8n5EkQ8iinwYUeSjiCIfRxT5
NKLIZxFFjkcUORFR5POIIl9GFPkqosjXEUW+iSjybUQR0mCo1jGmyCdMkS/+JEW+iyhyKqLI9xFF
TkcU+SGiyE8hReIQ8kocQ8rERUiZuAwpE1chZeJeSJm4DikSNyFF4jakSDwIKRKPhRSJx0OKxBNC
isSLhRSJFw8pEk8KKRIvEVIkXjKiyEmmyI+OU+K+o0g88c9RJF4qpEi8dEiReJmQIvGyIUXi5UKK
xMtHFEmNKFIhokjFiCKVIopUiShSNaJItZBX4tUjytSIKFMzokytiDK1I8rUiShSL6JI/YgiDSKK
NIwo0iikSDzZUSSewhSp7DglXvdPUqRxRJEmEUWaRhRpFlHknIgiLSKKtIwo0iqiSOuIIm0iipwb
UaRdRJH2EUU6RBTpGFGkc0SRLhFFukYU6RbxSveIMj0iyvSMKNMrokzviDJpTJHmTJG2TJFOjlPc
MxPXbn5mkgl18H38CD/FU/g9/og/CUlGthGBSBCJIkmUEKVEabFGtpU5cpqcLmfImXKWzJV5Ml/O
lnPkXDlPzpcL5EK5SC6WS2SBtzS+lM6bhMc46uqH+KF7ox5p1OJJpFGHp/EH8AT9gRFKKPCFFhqs
oB8EIibiEBPFRHFIECVFMhQTq8VqSJJtZBsoITPlVCjpFXgFUCteEC8g3U5ACgTyoHxSPiWflofk
P+Rh+Yw8Ip91d0ntK+C7dHW2yavldnmN3CGvlTvldfJ6ecNv6vzP53Hac9kztOem7qmYAK5xkL8n
62qknlGj2Rn7BAjBizWoJbv4eVovfh7a7NcnPvImkDSxbHep3EXpjZzf4VLK73DPyCBR3hyV3hyV
Ighq99O0tzoUk1vlVfJiuUFeIi+Vl8mN8nK5SV4hN8u/yC3ySn4q5mgMfE9C3ip3Q1zeJe8iXVqQ
TpwqO8uusrvsKfvIdNlfDpRjZbYcJ8fLCXKinCQnyyly6u/1u7sX2cnFD5RdZBe6626yG52/hyQu
lb1lb1Cyr+wLnsyQGaDlADkADPVnFvjEWbPp/sOrd6Kju9FRval2BtXKlMPkcDlCjpSj5Gh5nhwj
s36PE/nqnV2kPmq9+6pJd9mdrt5T0tigO+lDV0+X6XT1/rI/XX2gHEhXH0vc5DMdfr16Z7p6d7p6
H7p6/9+9+u/Qw1lR1O6udPUedEVBbU+nKw6gq2hqbQHZ1+H5qY6r4fa7vWc7pvj8nfjuuvF99eY7
yuB7cWOCzu9VFOto1jLoo8UAYxjHBEzEYlgck7AElsRkLIWlsQyWxXKYguUxFStgRaxE9kkVrIrV
sDrWwJpYC2tjHaxL9kp9bIANsRGmkdXShGyWZngONscW2BJbYWtsQ/bLudgO22MH7EhWTGfsgl2x
G3bHHtgTe2Fvsmn6Yjr2I6umPw4gq2YQDsYhOBQzcRgOxxE4EkfhaDyPLJ0ssnOycRyOxwk4ESeR
vTMFp2IOWTzTcQbOxFmYi3mYj7NxDtk/83A+LsCFuAgX4xIswKW4DJfjClyJf8UT+Dl+hV+LcWK8
mCAmiklispgipoocMU1MFzPETDFL5Io8kS9mizlirpgn5osFYiFZT4vFElEgloplYrlYIVaKteK0
+EH8KH4iAY9SSCkVWUWajANfWjL0YzIuE2SiLCaLyyRZQpaUybKULC3LyLKynEyR5cl6qiArykqy
srOgZDWyoGo4+0nWlnVkXbKh6ssGsqFspHqqXqq36qP6qnTVT2Wo/mqAGqgGqcFqiBqqMtUwNVyN
UCPVKDVanafGqCw1VmWrcWq8mkBW1iQ1WU1RU1WOmqamk701U81SuSpP5avZao5aoFbqu/U9eo++
V9+n/67v13v1Pr1fP6Af1A/ph/Uj+lF9QD+mH9dP6IP6Sf2Uflof0v/Qh/Uz+oh+Vj+nn9dH9Qv6
Rfq9TL9X6fe6fkO/qd/Sb+t39Lv6PX1Mv68/0B86e0p/4uwpfZx+n+sv6PeV/lp/o7/VJ/V3+pT+
Xp/WP+gf9U8GDBpBlpYyntFkavlkaQUmZuImwSSaYqa4STIlTEmTbEqZ0qaMKWvKmRSywyqbKqaq
qWaqmxqmpqllaps6pq6pZ+qbBqahaWTSTGPTxDQlW+0c09y0MC1NK9PatDFtzbmmnWlvOpiOppPp
bLqYrqab6W56mJ6ml+lt+pi+Jt30MxmmP1l4A80gM9gMMUNNphlmhpsRZqQZZUab88wYk2XGmmwz
zow3E0yOmWammxlmppllck2eyTezTXmTaiqYimaimWQmmylmqnnTvGXeNu+Yd817zlY0H5gPzUfm
Y/OJ+dR85r/jv+u/5x/z3/c/8D/0P/I/9j/xP/OP+yf8z/0v/C/9r/yv/W/8b/2TJB6lVdaz2hrr
W2sDG7Nxm2ATbTFb3CbZErakLWVL2zK2rC1nU2x5m2or2Fq2tq1j69p6tr5tYBvaJrapPcc2ty1s
S9vKtrZtbFt7rm1nO9iutpvtbnvYnraX7WP72nTbz2bY/naAHWgH2cF2iB1qh9nhdoQdaUfZ0fY8
O8ZmBe2C9kGHoGPQKegcdAm6Bt2C7kGPoGfQK+gd9An6BulBvyAj6B8MCAYGg4LBwZBgaJBJdunw
YEQwMhgVjA7Oc/ZpMJbs03FknU4IJgaTyD6dEkwNcshCnR7MCGYGs4LcII8s1dnBnGBuMC+YHywI
FgaLgsXBkqAgWBosi/+UAAmYIBJkgkrwEnSCSfATbEIsIZ6QkNDVWbehDwtvwVugAD/D47AUv8Av
YTl7tVa6mOxwHfu2rmff1svs2/LVMrUMLfu2Auc5xAf1Tr0LH2VP1kFn9eNLfoJfCz/zG/tjhGV/
Vqv4W/GPxeL4p/Hj4kL2Z60lGb2KZHcJ0g5qQg/SRRe5FUn+p7wmg7Zs8i+rRIpDaUi1jSh/gyUN
zuyyjQlvtM1+qdueti4jWzlO5ysLFaG67ehKLGl3ZqvtTLjNdiHcbnv/ckwmb5H+QPebSspIVVGV
dJfqojppJfUF6daikWhEukFT0dQ9aiGdWf98dqjvvG8kN8oSxjDGmEjTYoxTl0uKcklOv4AP6Qd4
DV5Dmt9OvI5q3IQ3u1U3f3jWntF5ev4TZxXeJHH7byTfv0Pu/Zuk3v9P0k788H8r7/RL+hX9mj6h
vzQlWe7dRxLvQZZEB0iqKJZyT5OEc7ItlGwvn6VM+/wPZNlvJVkxkmG/Sq+fJcP/a1LsV0mVQ7I3
6UxpRrrDvaw1OI3B6QuP6kfMtFBfMDNIWzikD5tkpyuYUvp54sJJxH3THMf9LPPEvMLyzk61OXaa
nW5n2Jl2ls21eXaxXWIL7FK7zC63K+xKe7692G6wl9hL7WV2o73cbrJX/K6U/PRPyMnks5CUjWya
bczystnvSsz2JDM72k62s+1SSHb2/m+lZ+b/kvwsLD0z/zfkp95npv+hDG0HK8C9G7cODpDF8Tgc
hM7wFDwH3eAofAD94GP0YCxL2MXiXNEOlogOoissFd1FBqwSA8Qg2CCGiFFwmThPZMGVIltkwza2
768WD4tvYbsqr3rA82q+mo/Sm+BNQOVN8iah503xpqD2FnuL0TjrH33vlPcjWk3iBBO10B4W00YH
WFLHdTEso5N0KpbXFTXN67q2bolpurXuhB11T022ie6j07G3ztADMJ1k+mTsr6fqWThe55Fkz9E3
69twh75D34m7zBwzH282C81i3G0KzFK8wyw3q/FOs9ZswPvNQfMkPmSeNofxEXPEvIqPu+eA+Kz5
nrSC5/xKpBW85mf6Y/CYP8UvwOP+Cn+b8Pwd/sOiiv+Y/4bobE8F54qRwapgldge6xPrI66Jn4if
Ejvip+M/ir8mdEnoIm5jH4EgSy6RV76thceikp6FSh6HLLVarVFr1Tp1kVqvLlYb1CXqUnWZ2qgu
V5vUFWqz+ovaoq5UW9VVapu6Wm1X16gdeD6uwgvwQlyNa3AtrsOLcD1ejBvwErwUL8ONeDluwitw
M/4Ft+CVuBWvwm3yIrleLpXL5HK5Qq6U58tV8gJ5oVz9p8rWyLVyHfs3FLjvb62ArZDCnopmZOEW
QHP2VIxmT8UYqtcaUv6Vtjt/DJ879NWknOGrOcdRkzSiHPfEUzRzkZNEK9GaykhekmZEshK0OWG+
AN98ZU5CzE/0i0FxP8lPhhJ+O789lPY7+l2grN/d7w2pNGMdgyo0X31C+hnNSFCHZiQL9dwsAo1o
FmkHjd3cAefQ3NEbWvymPc25PY3EXOebovY05/a0Ik2tLWmsilq1BDxq1TLwSYKvBMttC7htCdy2
Ety2ZL+0X5ZaleJXhPLczsrczqp+P78/1PQH+kOhDre2Ibe2Mbe2Obe2Jc2dCdCWZs5kaM8t78ot
706zW3/oTXNbJqRHz2rdGxdvcsvDe/mG9T34pcRt1Sa+jWOJX8oEaV714ee3fFyZgLJ0ry0i2iu+
V033WgCGeyDG95pgHjQPQiLZU8egmDluTkFxc9qXRPUEusvqfmW/FjQnjXwotPOH+WNgPEmQ4zCN
ZMVJWEASIhmW0/xfAS6nWb8jXEX9kAl7aG7OgkMkn/LgKMmk8+F1kkNXwLFIa25LbRpH167idH/o
5Kw56O+eZcNA/x27HQ6ddT3n+5P/R7V/7YuxTNGW3BcZZ/RFy1/7AgbRnP5zmaB5vO4ZfdHSrdz3
lR8H8Gv7aWD9LLqO85TJsCXchip89bSolT9jOs9RqTye46yr7yRdnTR257+kK6RAZbKD6uN2qrES
r3VrUVwtWIvOJ7sObyS8yB0B63mOu5C0fkH2jhTtRTcxmNvQzn1xRnQlCYNiEMkW51zdBf2pxZ6v
feP7vvUDP+bHqfV1/Lp+Pb++38Bv6Dfy0+hOxvrZ/jh/vD/Bn+hP8if73/mn/O/90/4P/o/+TxYs
2oq2kq1sq9iqtpqtbmvYmnaszbbj7Hg7wU60k+xkO8Xm29l2jp1r59n5doFdaBfZVfYCe6FdbdfY
tXadvciut5vtX+wWe6Xdaq+y2+zV1t2zdTKC6EoyguhKMoLG6gnizfKkl1Sg+WIYcWID0pXyaBwu
Jk5sTzrRFWQ38sxPNulKpspSXB6VLFfnn1Hyx3Ryx6xQq3455tc1TOO471tReQKvEgL4iH6olqgl
IJy8Bakn68mg9I36RvDMfDOfZsXFZjEYs9qsBj+4LrgObLAr2AVBsDfYC7Hg0eBRapOAetEapDXc
q3tJi9CsRRQnLeIwlIS36VeWxtsxKIce6RIpqpFKg/K8/qcCr/+pTLJeQBXtaQ1VdUldEqrr0ro0
1NDVdDWoqWvpWlBLN9JpUFs31U2hrlshAPV4LVB9XgXUgFcBNeRVQGl6hB4FzXSOngUtSPovgHP1
Gr0GupKNvxO68Rqh7rxGqAevCOrFK4J6BxuDy6FPcHtwB6TzKp2MYH/wAPQPngiegoG8PmdorE2s
DWTG+sX6wTBekzOc1+GMDN9SgcfUBeYSnWuWndW7EdRbupvud8bK963QG2/Hu/Be3IsP4QE8iIfw
CB7Fl2VT+Yp8Tb4h35LvyPfk+/JD+fF/sfclYFFd2bpVxSmGmud5HpEoFoMzGoOoxHbGGNoYW7FE
RFSCRI0Qo4iARHEIMomISNAYY4gSJYoGiQIiEjXGKEEkxhhjiBpijFPrO+evY0fT9tf33Xfv7ffe
157v+/eqtdf+19rD2WftsqogyokKYjuxg9hJ7CIqid1EFbGfaCc6iEvEZeIKcZX4ibhB/EzcJu4Q
99jkI4XtzZay5WwlW83WsvVsI9vMtrLtbCe7G/s5dg92T3YwO5Tdm92X3Z8dxh7EfoF3mneGd5Z3
jtfKa/v3J63/P/mktYBBsP3YXLaALfonn2ck1zNxkjhNnCHOEuf+A58nYzpvEqf8tvvt8qvy2+9X
61fv1+x32u+cX4ffFb9Ovy6/O34POQSHwxFxFBwdx8Lx5wRyQjn9yVPSMPJENJ4870whTzrx5Klm
AXmCSeNkcXLIO7KIU8qp4Ozk7OZUcw5xjnCaOCc5ZzltnEucq+QdeYtzj8vgenN5XAlXxTVwbdwA
rovbmxvGDedGckdzJ3AncadyY7kJ3CTuIu4Sbjo3m7uWm8ct5pZxt3N3cau4+7m13HpuC/cMt5Xb
wb3C7eR2ce9wH/IIHocn4il4Op6F588L5IXy+vMG84bxRvLG86J5U3huXjwvkbeAl8pL42Xxcni5
vCJeKa+Ct5O3m1fNO8Q7wmvinSTvnjbeJd5V3nXeLd498hTmTZ65JHwV38C38QP4Ln5vfhg/nB/J
H82fwJ/En8qP5Sfwk/iL+Ev46fxs/lp+Hr+YX8bfwa/k7+XX8Ov4jfwW/hl+K7+Df4Xfye/i3+E/
FBACjkAkUAh0AovAXxAoCBX0FwwWDBOMFIwXRAumCNyCeEGiYIEgVZAmyBLkCHIFRYJSQYVgp2C3
oFpwSHBE0CQ4KTgraBNcElwVXBfcEtwTMoTeQp5QIlQJDUKbMEDoEvYWhgnDhZHC0cIJwknCqcJY
YYIwSbhIuESYLswWrhXmCYuFZcLtwl3CKuF+Ya2wXtgsPC08J2wXXhZeE94U3hY+ELFEviKBSCbS
iEwih6i7KFjUVzRIFCEaIRormiiaLIoRxYnmipJFi0VLRRmiVaL1ogJRiahCtFO0W1QtOiSqFzWL
TovOidpFl0XXRDdFd0QPxYSYIxaJFWKd2CL2F7vEvcVh4nBxpHi0eIJ4kniqOFacIE4SLxIvEaeL
s8VrxXniYnGZeLt4l3ivuEZcJ24Ut4jPitvEl8RXxdfFt8T3JOQjWyKQyCQaiUnikHSXBEv6SgZL
hklGSsZLoiVTJG5JvCRRskCSKkmTZElyJLmSIkmppEKyU7JbUi05JKmXNEtOS85J2iVXJJ2SLskd
yUMpIeVIRVKV1CC1SQOkLmlvaZg0XBopHSudKJ0sjZHGSedKk6WLpUulGdJV0vXSAmmJtFy6Q1op
3SutkdZJm6Snpa3SS9Jr0i7pHelDGSHjyEQyhUwns8j8ZYGyUFl/2WDZMNlI2XhZtGyKzC2LlyXK
FsmWyjJkObJcWZGsVFYh2ynbLauWHZIdkTXJTsrOyTpkV2Sdsi7ZHdlDOSHnyEVyhVwnt8kD5C55
b3mYPEI+Qj5WPlE+WR4jj5PPlSfLF8vT5Nny9fIieam8Qr5Tvlu+X14rr5c3y8/I2+SX5dfkN+W3
5Q8ULIWvQqBQKAwKmyJA4VL0VoQpwhWRitGKCYpJiqmKWEWCIkmxWJGmyFasVxQpyhTbFbsUVYr9
ilpFvaJZcVpxTtGuuKy4pripuK14oGQpfZUCpUypUZqUDmWgsrcyTBmhHKEcq5yonKyMUcYp5yqT
lYuVacps5VplnrJYWabcrtylrFLuV9Yq65XNyjPKVmWH8oqyU3lLeY88NnmreCqJSqUyqGyqAFWw
qr8qXDVCNVY1UTVZFaOKVyWqFqhSVemqVar1qgJViapctUNVqdqrOqSqVzWrTqvOqdpVl1XXVDdV
t1UP1Cy1r1qglqk1apPaoe6uDlb3VQ9SR6hHqieoJ6vd6gR1snqxeqk6Q71KvV5doC5Rl6t3qCvV
e9U16jp1o7pFfUbdqu5QX1F3qrvU9zQsja9GpFFodBqLxl8TqAnV9NcM1gzTjNSM10zSxGjiNHM1
yZrFmqWaDM0qzXpNgaZEU6HZqdmtqdYc0tRrmjWnNec07ZrLmmuam5rbmgdaQsvTyrQ6rUXrrw3U
hmrDtOHaSO1o7UTtFK1bG69N1C7QpmrTtFnatdoCbYm2XLtDW6ndq63R1mkbtS3aM9pWbYf2irZT
26W9o32oI3QcnUin0Ol0Fp2/LlAXquuvG6wbphupG6+L1k3Rxerm6hbolugydDm6PF2Jrly3Q1ep
26ur0dXpGnUtujO6Vl2H7oquU9elu6N7qCf0HL1Ir9Dr9Ba9vz5QH6rvrx+sj9SP1Ufrp+rj9In6
Rfql+gz9Kv16fYG+RF+u36Gv1O/V1+jr9I36Fv0Zfau+Q39F36nv0t/RPzQQBo5BZFAYdAaLwd8Q
aAg19DcMNgwzjDSMN0QbphjchnhDomGBIdWQZsgy5BhyDUWGUsN2Q6Wh2lBraDScNJwzdBiuGDoN
XYY7hodGwsgxiowKo85oMfobA42hxv7GwcZhxpHG8cZo4xSj25hgTDamGtONq4y5xmJjuXGnscpY
Y6wzNhpbjGeMrcYO4xVjp7HLeMf40ESYOCaRSWHSmSwmf1OgKdTU3zTYNMw00jTeFG2aYnKb4k2J
pgWmVFOaKcuUY8o1FZlKTRWmnabdpmrTIdMRU5PppOmsqc10yXTVdN10y3TPTKbPZp5ZYlaZDWab
OcDsMvc2h5nDzZHm0eYJ5knmqeZYc4I5ybzIvMScbs42rzXnmYvNZebt5l3mKnON+Yi52XzG3Ga+
bO403zI/sBAWnkViUVkMFpslwOKy9LaEWcItkZbRlgmWSZapljhLomWRZakly7LWUmAptVRYdlp2
W6othyxHLE2Wk5azljbLJctVy3XLLcs9K4NM5HlWiVVlNVht1gCry9rbGmYNt0Zax1qjrVOtcdZE
6yLrUmuWNceaay2yllorrDutu63V1kPWI9Ym60nrWWub9ZL1qvW69Zb1gY1l87UJbDKbxmayOWzd
bcG2vrZBtgjbCNtY20TbZFuMLc4215ZsW2xbasuwrbKttxXYSmzlth22StteW42tztZoa7GdsbXa
OmxXbJ22W7YHdsLOs8vsOrvN3t0ebO9rH2SPsI+wj7VPtE+2x9jj7Un2xfY0e7Z9vb3IXmbfbt9l
r7Lvt9fa6+3N9tP2c/YO+1X7TfsdB8Ph6xA5VA6Dw+YIcLgcvR1hjnBHpGO0Y6JjiiPWMdexwLHE
keHIceQ6ihyljgrHTsduR7XjkOOIo8lx0nHW0ea45LjquO645bhHHXycPKfEqXIanDZngNPl7O0M
c4Y7I52jnROck5xTnbHOBGeSc5FziTPdme1c68xzFjvLnNudu5xVzv3OWme9s9l52nnO2e687LxG
ZX3Mj4AfAz8B1gHrgU3AFuBp6vdoyDMIZesP9KbxE+BBYCu+S07JvuD2hY0vbHxpfT2wCdgCpFpx
YMOBhkNrLpLIhZ4HNh7YeLSmDlgPbAK2AKm2fNgIwCBEKyFkMWQxIhGDQQy9BPwS1ErQVoJaCfgl
4JeAX8I8S+KrsJTTeBBI8SigUYBBAb0CeiVkJWQVfKlgqYKlCr5U8KWCLxV8qchRp5DyqEErDVpp
0EoDex30Ouh10Oug10Ojh189xmQ5sxJYBawGHgYeBR4DngCeon7TgTy3UbbbgCtorAbWAM+TmAnW
TNRmojYTtZlgzQRrJlgzYb8SNiuhWenRkGc16v0hKvYGsDWArQGWDYixAWwNYGug2noPQ+1qjGgO
+poDeS3arkUMa9F2LfTrwLwOtevQdh1q14F5HZjXIap15DmVxWiHZS6NNUCKZwM0G8CwAfoN0OcB
8+ElHzb5sMmHl3x4yYeXfHjJJ8eYQspXIVoVolUhWhXCfiP0G6HfCP1G6IuhKYb3YmoMmd6UJYlV
wGrgYeBR4DHgCSA5txTCNgDoS2M1sAZIsfpB5oCbAxsObDi0/ijwGPAE8Dze/60GngB6NOTYMPnQ
C8AmAJuA1hwGHgUeA54AUm2FsBGBQYxWuGOZUshSRCIFgxR6GfhlqJWhrQy1MvDLwC8Dv4wae+Zf
YKmksQZ4EZ9bqAJWA2uAlF4NWQ1ZA18aWGpgqYEvDXxp4EsDXxpqtkmkPOrQSodWOrTSwd4AvQF6
A/QG6I3QGOHXSI0Jy0bd4ayewBBWBokDgeHACOBwD1IMpJxF4ihoojwIfRT00dC4gXHAeGCCB2GZ
BHmhB6FJgZxP/UILaz11/7FyqZ2IRCqqvcB8aApRWwbL417BJNZTPWI1Uv0l8ejj+5t1HJoTqD1L
WXoRsH9Er73Kx6vOywokKI0XVr2XkLJkEF6dwK+BF4AXgd8Av8VT7BPa6jvg98AfgD+ivgX1vjRS
XL7YoX3B6AtGXzD6gtGXZuTBlgdZQuPXwAtAPGnQToJ2Ek87gkONEIkfUUi1IOU6yBSHikZKjycU
gacVIaE1dZApGx2NX+MpQEW8HJrlXtj/vdqA7cAO4CXs89W01WXgFeBV4DXUn0B9Jo2t2MsPQ24D
tgM7gBRjJs3YANu3Ia+jsRXYBmwHdgCpdus87Yi+1IySWEkh1YKUD0OmOPJppPSDYTkYloNpzWHI
lM1GGluxc2I/pDQktgLbgO3ADuAl7I3VtNVl4BXgVeA11GM8mBwaW7EqD0NuA7YDO4AUI4dmFMBW
AFlGYyuwDdgO7ABS7WT0eMSil7HoZSx6GYtexoJDQyOlnwvLubCcS2sOQ6ZsDDS2Ym+hZpBAfsAD
SoAqEr2oXITMQzzlx3T5WP8R7hFPPcFsRb7iD+SAQUAh+w1Kw46BhkNnXcg2iR3AXdTdA9kXMg8y
D7IEsgSyHLIcsgqyCjIXzKR/3EeeaMh7gc7UPFpPbDpPHkt8RiIbmRAb64JNNJMYiNh8PJkr9D7Q
++B57kM04v5uQq+pEvksqaXwONnDDcjU/OiMtQmRUTIXXFzkYlziGPp2nOTgYUSpUQLCSgCPQlL2
IvPUJuiEHh08iWArAq8ItWLIYo8MSzEipUbgY7qsR+mJXEJHLqWRai33ILySiNjl4FKgRoEaUgYj
VR70lPCqhI3SI6OVErGqCOSy1NiQ2Ig1U0evoSaMhho7kxotNWDBCmZoIWvprJaS9cgJ9ajVw8dy
5DwNwHXAfOp/Hqj8inzaesoqunysr8Qedox8YnhKKufchkxsJRhWUyvJ20ZpfJA3krllDWo9mSSy
ZuI94AfUHgc5E3ID5AbI6yCvg5wLORdyPuR8yNlYtcvJGKjdzhMzmYfS2adHex6vNnrycazadIxA
OkbgA0SVAU0GNBlYqRkYazLfRn+pEhk55iSTmg3vgcg7s6iR9TqD8V0JH9ngysa4Z2Olvo3Za8B6
bcCIUqNErZzVsF0NvzlYHzn0ysnx6OBvDVqswUivQYu1kNd6ZFiuRbxU36vo8ijKSnpMPPGvp5Fq
netBeCWR2YARprg2oGYDasicHONIvmJ+xaDycqouD57zYJ2HGPOxTvPR03zEkk/Hko+1wmIUYIcs
QMtCsBRCLoJcRGfolFyM3LwYtcXwke3xBJtCZPobgcuJRyReo0afwEyQT5Ma5Lo1yEhrkCVS/5em
8awOKrukRgavH+sr8RTy1Ht71guZyR9Dpl2DbJlaxZ2UxvtLaHh0toxTArUeSfyAej5B5kAWQBZA
lkGWQVZCVkLWQNZA5oPZmxptKrtGNDLPWiZLj9YTm8Fz/qDWMtMHWT12WiZ2WqYLsfl5ThzQ+0Hv
hxzbj5ob6pSBXnM864KMuBFIzp6PLzJsLn3SOIbIKJkPLj5yaD6BcwW1oqmTBjhEHoSVCB6p/dSL
QmptMcUeHTxJYCsBL3ItciwpWeqRYSlFpDLPKkJ5FGUlPTJViE0OJjlaKz0Ir0rmMXBhLyXPGlSN
CjUqz4qmdLBQo07tkWGtRowaakWTeBzYiLXiiUXjWdFMLbIULVrqwIKMkamHrKdPIedxzqDOH0bU
GuGD7/EEGx1OMwagN1Z0A2XJ6okzgedc8uRZQefzDrAYWAIsBW4AlgHLgRXAfGAhhdTuQmILNPup
z6b47Cf5PGUxXZbQZSldbqDLMrosp0uS3ZegoiGxGFgCLAVuAJYBy4FUNCZEb0L0JkRvQtwmxG1C
3CZEbELEFthbYG+BvQW9taCVBa0saGUBvwVtLXRbqocWuocWuocWuocWuocWuocWuocWuocWuof+
6KE/euiPHvqjh/7ooT966I8e+iMCGyK2IWIbIrYhYhsitiFiGyK20fb5wEKcRZuA1PwEgCcAPAHg
CQBDABgCwBCAtgFo2x21PWksA5YDK4D5wEKsqSYg5SUEXkLgJQReQhBtCHhCwBMCnhDwhIAnBDwh
GN8QenxD6PENocc3hB7fEHp8Q+jxDaHHN4Qe32kY32kY32kY32kY32kY32kY32kY32mIYKDPeuBG
4CbgZmAucAtwK/BdYB6wAFhEIbV3sPAEJzVUHwbitxWociNdbqLLzXSZS5db6HIrXb5Ll3l0WUCX
RWTJYoUj1nDEGo5YwxFlOKIMR5ThiC8c8UXAPgL2EbCPQN8i0CoCrSLQKgJ9i0DbCLot2TffPIqB
xI3ATcDNwFzgFuBW4LvAPGABkBqd4YhhOGIYjhiGI4bhiGE4YhiOGIYjhuHU77eSuB34HjAPWAAE
J0Z8OEZ8FPhHgX8U+EeBeRSYR4F5FBhGgWEM7MfAJgpyFNpGoW0UYouia7cAtwLfBW4Dbge+B8wD
FgCp2KIQWxRiiwZ/NPijwR8N/mjwR4M/GvzR4I8GWzTYosEWjfmPptdTNL2eoun1FE2vp2h6PUXT
6ymaXk/R9HqKptdTNL2eoun15EZ8bsTnRnxuxOdGfG7E50Z8bsTnRnxuxOdGfG701o3eusHtpmN1
07G66VjddKxuOlY3HaubjtWNWFm+d7Hi7mLF3cWKu4sVdxcr7i5W3F2suLuIKQ59iEMf4tCHOEQf
h+jjEH0c4o5D3PGwj4d9POzj0ed4tIpHq3i0igd/PNrG022LgFS88XQ/4+l+xtP9jKf7GU/3M57u
Zzzdz3hPP/0MVBwkbgRuAm4G5gK3ALcCqTgSEHcC4k5A3AmIOwFxJyDuBMSdQNtvA24nfSYwjyLy
BPQlAX1J8GgwfwmYvyR4SIKHJHhIAncSuJPAnQSGJDAkwz4ZNgshL0TbhWi7ENEtpGu3ALcC3wXm
AQuAVCQLEclCRJICthSwpYAtBWwpYEsBWwrYUsCWArYUsKWALQVjnULPUQo9Ryn0HKXQc5RCz1EK
PUcp9Byl0HMUgzmKwRzFYI5iMEcxmKMYzFEM5igGcTzOgd6hy2K6LKHLUrrcQJdldFlOlxXwmkw9
wUgsBpYAS4EbgGXAcqAnR/HkJe/QZTFdltBlKV1uoMsyuiynS4/XDHjNgNcMeM2A1wx4zYDXDHjN
oJ/cnqf1O3RZTJcldFlKlxvosowuy+nS47UAXgvgtQBeC+C1AF4L4LUAXgvgdQPeqV7jQeSyuZTs
1wZ5AzCPfn+7CUjJm4CHgTuBZagto+WzJFZA3gE8hne2P/MgsuRGSuaYICNfZzXR74ofA1LyKeCv
wA7gWdSepeUvSWyF3I53yFngf+BBaJjw4vbUAr3o99KPASnZ8x57IBAZv5cQtUJaJr14SSErccL9
9++2/ft32/79u23/Xb/b5stgen5PhvXPfunm8e/QcMi7vS9r6RPfd6I0A1jLf//GEfMS4zpLxzKx
LKRFAKkLYblZcax4VgIriTy7p/jU+nxHfZP8WZfP/acvkuXpy/L3l6/x6Yv6Zvozr4A/XN2p760/
dYX8/eUb/fRF9uUfXL43n77IPj99xT/r8pM/fZGj9PS1FNfvr5P+cCWT18J/cKU86/L78x+u2X+4
3vzDtebpi/F/4/esmIx2hpYRxghnRJJPgQn4C3+P/7bfEnK/zmasZeQxihll5K6/i1HF2M+oZdST
O/xpxjkq88FvGfzvouU/hSH/GfwH36YyMfheZ4gs4i1vpne89w6fxT5LfLI5FZz3OIc41Hvu/9Xf
w2HgW1r03wtTusmS+sYX+U852ZWmjPb2C8iIzPiNzyT30TTli6RqKIvJDOK6/LzZzwm8WBo2wzXN
m/OcN5NgpvVhMYnSKNc4V/cnNLoyw1IdOY3UNYYRQz6y55GTOIN8HM8gH97k5TI/QUbIvr5a262z
j27yi0c+a9g8/NDeO5bMz0rTJEGuNGKqK81rZCmZiLBYnMD3xW1jH03edLz2cWs9GUpi0HOubt5e
LxFcqWXIvMQ3kmbNjEs2+U/vZgrq16+PadSs6Unz5s+LTTYNmZeUGBhkcOk8xvKna+YlTUueNW9u
kNllpOq9pKrf68fPm5dseuH15Lh5SbOS33AZlHxXH1ffYPJfSJAreJKSHxRMvuxFKsl/k1xvYKxI
Em8p66WoIKlLTL3wlXJenjY/btbcmcmkG5FLQCl9pD7jZ7jnzJvrfhwY5x8FZnWZPYFpnqx3zzBF
zZo5l2Q1jR3ygiuNaXHx/zaBTCab4ZXGFDJIPYeVxmQy9r3x5tlX9wzttz10Z1DrXXuvFxfW3jeW
NAx97capYVfPrPps9sjxMbcKWZ+NOvdiQk/boBmftlj3cSP3vfX6haEHd6wRjD1qf66r9Hu+1Xjq
Bdu9mMLP1UPffWeEsfDEnp6Wz0b0SJ13Xm4YsKqfqN+Fg91uxQ7owQx+9NAZWfFxAjOz+P7+3dPf
Srs7uXRZ+oqcyq7q3K2f960Yu0LpzBx9wXWbMfBW/d2Byw5l/JTQb1tg6O2qwA85b8asWxRbXDCf
n/Fh15FfTJ+Mkayefrz7+eCh6usHRuQNGBulaokd98aODzIbJw7anDY2ay77o16HU2wHx8cOLBzd
/NySkLnpw71PlZwckcGam8Eor828GEWmtwzm1mX3XMt+c0nJ4dTbCZ6L4+1LLl0228fLy7WsjNIy
iWVFrmX5S0WvnEy8MSupxDpuiWz3qJxHx7ck/c+vtzQh4zDj7bCwLPGpQbend14c7BJSMUqZzEcE
2+VFFi49pRAQCkLWrG9ZwEh85cOfW4+MLhoXEbg1YvpNF5eqFhIEeRtlPHHreFErIuX9XUtGOLpa
akYnl0U7kwNe35Px1/dH5i5ijPqh6UdV26yjgrLUX1hD6psym+9ENddtPjhx3s3pEe9FMK7nNRZ9
qavmblbzc79qNXzQ7c0bP1XM37mmvV/OwIL4mr5zTmd9aP3rxR/OzvJbl3Xw4TeMA6G//JZ6VyQJ
ZP/YLe+d8Nn+r+3ru6bDh3/s1bgTB5e+MDt2+4F9B3JCm7q8RKmLfz3dEX4x5eE33+x8ePvil/w9
iWfXfztmb9+y1B5nBn4dyo3pw9q8LN668vbk6WsqJx3o99XUVS+la0J+HVBQmsYr+8vbe7rv2/Lu
8fdbTXs/dalXmGT8gJrxt17omOL6dr3/rMzDiZd+2fZ+y9LwpAUCco9ZTO4xMfQeM83buQx7oe+T
9xGb3Gf+hXc1teH0JXea4OCg4NBevagNx+UKol6GUC9dy5b/t8TGx8Ihly4xaszY8Y/Nvf6B+T/d
ew4mVa38Xrd5RUNy9dTJXr0HFv+1cHFRt2GWym2ZUT9dH9a/4RU29+Xt+5rYzV+MXDg8ccWe745f
nPn91r8mO9+ZufmrbK8IV/1vx/Yf66/3nRgxRunLv1uljtth091nv7zih6Ojfcx9tv3Y0r3n3vAT
Zva2s1e+8H+5Qbu4pVtvnxMlLzUf+Nny43ZrOb9b3f2Tn00aNH1gQ/cXuSlvrLiZdeO1g0Mmfbt1
D/+Xl+7bOy6Zvvi+aEruuyE9/N96WftSPC844kZswrybfYtvsD4o2nKhwEckCFPNuvTG6GGyjk9W
nXx9TvFORnGP8F/HVU+6tWjo8h8CU5878OoJ9TT/D3KHcI7Ghz/6OHhXeTdLu+LqF/Tec8e17Ndn
7z2/38XWU/MDRh68/5353muGQvkp5d0jFdmYPr2QuuvJG9lnKfYNvZVQuRRLn33bR1AGRmKga4Cr
X2mf0l4ZIXHJyYn9e/acnpQQOOfxHAZOnzenZ+LsWZS2Z2LSPPfr05Pn9xwSRS68QFLlinwcIZNJ
hLn6u/o+fu1iZXSnCRcuXPgswhlJTzAl/+GGwu4zpNvn0w8mfDt/zmeFX83hZQ2oj5y/2N7S/VKf
lE2hmw9aWw5dPDf5DfFs6TgTc/onSb/5flv/5rgAhf+ZU99vDPhcxT8tfW1dt86JB++ePcrv+eGM
HnNGDe02MSl9zPOn4/UvxLz3xuScmw0Ls4+z/AM3NRQ/990nAX4XOvMvfbd49RRRVtSWC1PHLCx4
ber2V/qt++J9iZH9w2dD3/uibtwnH1a3PfBOZ9xK3vr1o2Z9qZXtc9nZqy5/rXpH2lTn1fvpzxlO
EcdzPk/jf7V91JDBr59uv7DwRvbk2cJM95qq/fv2vz9zgnnojhFx30+Y8rZs8sxFnWsne4nW+W6y
mfKvXmSIE9+7uzspcd+uS3WbFSxy99lE7j4rPLuPKJ5bOKaWYX9f/PVQY/TimWV/3IP+NblOb1e/
oN6uIFdoaB9q6+lHvvwX5DoTZs2ZMT952pzE/2iu09Zn7v0PG8NHvKZqbIkcFFV7733Z/u7BByRj
xjcu/2lQyPkXg9b7713n7jCOTd9f96dTb7Hv3Hj90NsN27/cNSsxdpEz9urefTdWfHLi+o6/Ssq5
f7Z06/n54PMTCe2Cj+e454yY8PWFn9s/3by8YenFt0ay+uT+WlviO9EQN/zE+doFk3u+uddOVE18
JV43/dHS1LDrXxL2Uf0WJvu8Wjf5XEaf7q8fE1wz9PNLXfBwU8LcxR2dg9bkl7wm+EvAGFXM1OCS
08tHP2eZHDf07fae6aKxu+9+rFmdcN2+UXrnuOirFYJbaQvm967fsLiseap3J7syI2TfndxX0l9I
j16RO7fS2D2yeV7xkI74q285cmZ79ps0pj85IrZn7Ti+/29kOyJvP/pkIWdSKQzjiY1y3tXRz+d/
Evr+nzLW1BRf2znghSH1J13qvzWQsQiegcOIYrxOnkKGMF54OhP6uzTqGRtU7ihxUF3q2APinC3T
fJiCVYlDV9+YP+Hg837sHo+qx0Wt0P3Ub92+rRO57av2DtCeur9z27F9H40za+f5zloy26vMMuyn
hKo5qZbqYV+k/7JaeMgnu/fhH5f8kPjq0M3rTze3XMip/ebTgBOpncd2BX+Z+cnx6Ud6n1KZP13Q
PqBoj3Z+iTnrXFWVZMKqW8V1M0YU+TuKp2YLBzRIZyyKPPD5B8v7j6mMiW53/fBDP/23K7ta+y27
KzWvci+d7k3kdRWxhvRMGZa1/xHr/Iy7I9pbvZLf2cOey2ve1OY/LTXyZ2Wx2NyXpcvc6X00L7j6
u8H1UQMPvrey/Wpsn9W3LHnFzZULJ4zrfzYpYrf1NrlB7SA3qPWP0yN2metfnR793UaA9MjVJ7gX
uTUFBSE9CvG8DKJeupbt+Z9Ij5wuu+elYe6QWYlxM5JMEVFDTUOjRvfv2ysipEeIq9eQHr3ChwwL
srusnj7pnu5TjyiqU6aoGUkLZk2f8U+3t5tEj915tZplM+0fOWL2SP/U4tpfK+n7YNmMUJ8jvXfb
4m77ELU++bf2/ZxiiOk+7PyfyseF7vsi4adJA6qWbxk+UOwb2Gv20Ct1YatYsaz3VLN+HPGTs/v1
sIWvlJ9JLPzTy+mikx/2uLNSf+Vat6rvPy/xjtmWNKFuQP3nz1d/UxktSvju3a8+q3u9z8FbK75Z
dtX/nPbnrl0/p209+5VX2WZ5+v2B997/Zm9wYynL/cuVRxrHa75R2XJW13LnghfTXtt244PgRfVf
JSjGWGbkx4wa1vOR9cMVnRWJB72Ot54LZh99bu3gvSVfds9I2HdcGvzm6volu5Q9gx/EHtBXDn3p
zgf3esxcPrPbO+mnJ22xPplO/b4hXM2//duNVT9fmfXtn+NG/1aQvfjCxsCnMqVn7hj/J5lS8vzE
6dP+SzKlx0zJz96sn8r/vGuftVvxn1/4l3Vhh97tVf41m51unNh1o7CiwXd1zz0nnn/ty4zUhcYL
Pyp3H0z99m5hF2do5AeyA7O6dw2aGTOh6/pbTvH6fp0t5zNHZ/02dbg1xSkf7Lv5U34QkXau115e
MeOLt3csmnb046wXNg3q3RZd7tzYv/Wg96uyit3CkYdzwt7uiim8E/vTl7/o/CuDv24K8qu5b4kb
NvLeF/Mt33fLsTDuT/zUe9eyUvn+0Lv+OcYRMewtK39dNvwH/jrfr6IHrDHM9pv1Xm1k6ktpz/+F
0XdIsXfz8+d6fjpmvt/Av+6fcquhs0+de1rpqDMDE5tfqZQuO3xma5DmoPts3unFzwe8MizKL+yE
193n/8xoXhk1LSiNKCR3rA0sJtO1LPNfeGR76iD5+1tdpcuOUE8netr8vIJ4T76PRvr9/RU3SOB6
slZO7hp/a0gEkUu9oKezqLG08X70pNnZbxIl3a4c+rCfy/1EE17QRNeE0oCl/oxRjFmM6Ywkxjy8
FRf7v8ZQwqDAEMJQyVAA5KUDxROBrAyGyoVqDSo402lJZUF+elFiQUalPlq5xNLEyBD06tea92/+
uk/+6uxTxPXp/IYbtkEnzl3IebPaOFFsV0zMIXau9RryISbMM2oSN3Surg04a/VkCbPhrS8PbR7y
FVxiOvq//8tmX5vNX5euuLLu3mSndleRDMvv/Rt+r3h59g77pavbpxwWOset9EIq/cWnqDN6S400
D5t93ak79Uifa9/eQp5uo06++S98UtzehYs8tl+52KtwUt3rryqXjFfckZb8xCTNUmD8I4qdSanB
dbaZTKVXWO/rnv+LPnoKMvxKC80XN9M+ff/Q50vqa5nb76cVqruZ31+Yfv32x6TlJZ+f9cts7y15
PPFgf3TikwfBYTsdzmX7pttqBy/wKZ4Tnm4x/ct7VbGHbbsXNjHJGzQxSSPiiM2wiYkHKMRB98SI
XkGiVNvs0MS4INZAAjklciOGfRmBdsJlWA35gdWrpaGRoYEhsE41Mo/CSIjnvP//bLxcOy+4lJ//
5tKvO6L2rZNGK51ASaQ++6dRYNXRk1fzRRu0pRZw/8hcGr59W7+Smt4536evy8XulGzVL7n9tIfV
OKDsjZNI0aW69sAIhpjcFZF2Aqab4hdWNl122GyqvCInPUci1/Lp0r/BQZKeF6Ut9kv+TlC9cryB
uV/qWvmf5B1bE9Q7dUQd9dovuxRbmO1v/b1ry3PRf09OJKe2mIWlnU3NEEmfwNr9gsHIjE+PreaF
3ceF39O8l9V6fjknpPww2etAy9/b/b7rk8x6rBraXl1RdDvwqqUsJeZDyIxbMeye6lLhkksCN8w6
dM6/p8Q8p9JAc69CWfaP52U5z1mO+t8XeveQ/8ZeoaVNHG1rk1ecupHF8q5w1kfT95YaZ9oA7RWv
6w0KZW5kc3RyZWFtDQplbmRvYmoNCjI3MSAwIG9iag0KWyAwWyA2NThdICAzWyAyMjBdICAxNlsg
NzkyXSAgMTMxWyA1MjZdICAxMzRbIDUyNF0gIDEzOVsgMjcxXSAgMTQyWyAyNjcgNzk5XSAgMTQ4
WyA0MDddICAxNTBbIDM0NSA1MzUgNDYwXSAgMTU1WyA0NjBdICA0ODZbIDMxOV0gXSANCmVuZG9i
ag0KMjcyIDAgb2JqDQpbIDMxOV0gDQplbmRvYmoNCjI3MyAwIG9iag0KPDwvRmlsdGVyL0ZsYXRl
RGVjb2RlL0xlbmd0aCAzMTU+Pg0Kc3RyZWFtDQp4nH2STW6DMBCF9z6Fl+kiApOEgISQ0iSVWPRH
pT0AsYfUUjGWcRbcvmYmTaNUiiWQPubNvCfG0bbaVUZ7Hr25XtbgeauNcjD0JyeBH+CoDRNLrrT0
Z8K37BrLotBcj4OHrjJtz4qCR++hOHg38tlG9Qd4YNGrU+C0OfLZ57YOXJ+s/YYOjOcxK0uuoA2D
nhv70nTAI2ybVyrUtR/noedP8TFa4AmyoDCyVzDYRoJrzBFYEYdT8uIpnJKBUTf1NXUdWvnVOFQv
gjqOk7hEWiEtE6KcKEUSMdGOKEVaLYgeiTKkjGamAhOcvcSv8yVotkZZlpF6dVZTXdwGzcgiza+H
Jv+H7lGWJ6TeYqB8SR/JcJ3cdRJ7ir/YXDtNv3La+GVP8uRcWBFeC9zNtBVt4HJzbG+nrun5AbWH
tMkNCmVuZHN0cmVhbQ0KZW5kb2JqDQoyNzQgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9M
ZW5ndGggOTkwNDgvTGVuZ3RoMSAyMjIxNTY+Pg0Kc3RyZWFtDQp4nOx9C1hTZ7bo+vfeCQlJSALk
AeGxwya8NhAggEQDBAiI4gMBW9CqIFHRWsWKHbW10lrUorXa1r6nZWZ8zHTmXjfanmJPZ0o7ndZ2
pGMf05npPKqtnXZarbTTTkdPDWf9OwmidR7nO/eeuff7ssh6/Ot/r7X+9e8AASAAEI+EA29tta+l
p6XdCfDaDICo39RWz6h5ul7iAV69A4A9NtVXW/farz58Fpg/7cMOBVMbZzdXn3+7F+DtLGDiNk5t
nlut2JY2D5izbwGs+8vsZmdRk+upJQDkGM7S3nlDR7ctOnEWQGUZjufrvKmHZ1nTgwCLRgFUjy3t
XnbDH1Lm3gRQfQuAtmVZx9puUAGdfz321y5buWFpxe0vfw3QtRvAFNO1pMP/yVbvERwf1wulXaiI
fcHcjWVcL6R33dCzfkGzOgWAyQIoj7l+yY2rkv538i8BnvRim/iVqzs7Ml0izr9pALsP3NCxvtvh
MA5i3fexP7+q44Yl372/eTrAUy04H9u9em3P2FbowfW00vruG5d0H+LPojjrBIAxFagtFV/+dOWN
SwoX6T1fgk0FFI7+8cFyyl+u67r5i+IzDebPrOewqAYGgoD9oh4OuAEs874ovrjP/Jk80gRgy6jG
Nhs60E8UGDCAE5biIPNxXrkJd4bsBgWoFA8rXFh+NMjJV7CUBBg9wylYBadkGe4kMGNe4MbCY89s
5nlAe8CA0h1wk46oh8nLPJDH5UGfVcylOwVW4YOfyEv9aRApcKdhw8RVcg2XlyeCciusu5qe/St0
X6nj7gHT3xonAv96YD+CxrDMdcNy9kPoYlbC7LCOcUPzuJwLlcrvQzP3LcRKWM6thWnyGLOhme2G
hcxT4OCuD+oiEIEIRCACfx+YJHjiG7ppMPwvWEoEIhCBCPx/C6wD9vyr1xCBCEQgAhGIQAQiEIEI
RCACEYhABCIQgQhEIAIRiEAEIhCBCEQgAhGIQAQiEIEIRCACEYhABCIQgQhEIAIRiEAE/q8BG8Kk
0Ke1n8ESSswB4OAxLKcBjxL9jLcadFiaDNVQBzOhGVqhA5bCcuiGdTAwFvwkNm3DX9HGj21Wwo1y
GzJ2YewvAOQHYz8Nf+GYoa+xzvFPjCf9vRWTj9hSUJIzcukbnzIP7Wci/wcWkMf7LwF5/wqFIsTV
l2kNE2TzuGT7xnBbZLoVtsF2Wdoh011wN+yGPXAPyvfBXrgfHvivrfJfCP+c5f9Z+H86Er3zlvgX
LVxw3fx5ba1zW5pmzmiYPq1+ap2vprrKW1lR7pky2V02qbSk2FVUWODMz8sVc7KzMjMc6UKanU9N
SU6yJSZYLWZTfFys0aCP0Wk10WpVlFLBsQyBXGKVrDWttSukhJp2SSv4BAMvaWeNznRKEGuzC0be
5WzLC7WSFKIEcQ1SfGPrIHjL2iSleGWTWRLrMHxux84zbXytxDnwJUzv8EtZTa12wfC2bby+DftI
iTWtdrtNYhz4moZV+JrewfslQyPq7bagZpoEja0Uh8beK0MllNnbkDa1SinhYlvb1RZ5FGBs+Ipl
ziL9hkFtQo1PgvhB0L4ngYk2Gy0DCTxSlogLMaAkjwZOicR/LpE4iZhm4pIvn4J2O1l2FRvU+lcI
tf7laFF/+yWbjgYtauf7+f6mVqMLRXnRDdKxOa2DmugaoWZJNCpAVsBgtAY1GqrAIboHibaCyAKj
rZ08yIBKh+aLpcutpbhC8u5oR0Hwod2wJu5SzdDY8M6JVYDdwlJcUAouQlLWSFHBRfDLJW+HBDv4
wdzh/p1DBljcLmr9gr/julaJ7cAGg8A6artapKSGxnmowqkQ27t46m6fTKjz+Nouvh/LtG07UsFH
nX6Z3t+1pJ2GCWkXfFinrmndZh+2SbHIayWjKOmwmW7jaRvbX2tdztNif/82XhrA5U6otVOKQWDF
pffXCjgbDla7opq6xDnuNjkap/ll53h3dPBS7+IVwdjr2BmOf3u/QdL+xY7eQf9gT7ljyJT+9hV0
ySs66DZrV/D9O5bIW90pbw3jla9d4aNIO2L0w1zsPa+1tkuovTQhbhwF1nFlX7tdShBpx/7+WrrE
Dj+uPrhkrLi0fnombCLB9dRI3haZQYvsA5zR2+FrC6lCDebRbrSm3dfWZg/6HZtKUY5tinyB76cj
RjmkeNFgfxHrhvNyG5paa302efcSU9NaftZqO4tyQ+O4mlixTb/zrC1oo4ZmoWFOMAq6wqS9JXiA
mXHPY9NQe3nUEattJChf11on1LX399cJfF1/e3/H0FjvYoE3CP2DWm1/d207Lx9/gvpndtikup1t
kqG9i0yWPUSH42ns1TU1SHFz5lNX1fFdHcHEUSnYy2x243ibxr9VHTpzGP14BuiZ6zecwbVpMTvZ
+DqaaoYwQ9gkQxk9srigua14Jjrl+JUJnpVmHNxGTw3b5qhd3hwyFkZmKHhoDpwT0uIgdjs9TzuG
vLAYC1LvnNZgmYfFtsPgdYrox3ZaMxyuMc2lNb3hmvHu7QL6zdrQ/A/ie2Js9xuFWN7tlO0vp16/
NNyCe/xrmaQqC7k+rqaVtTEhibGxVIoWMZV5JIsod6Q2wYzZbxD4E4JkECVFTeuwzdPGG4yY6gi2
qRfpCcKMekJ4hdA8CvEGiXgkYqZ6wLwqp3fWUoaV44HE1/a3hyJt4rZCl4G/6+p7wzYGAbdnC7Y3
xgp0h8fl9BbK2o46eq5s9mCL6W1SDM3NUswZmeB6bTWtPGYiPLlzZIGv5buosyW+3SenhDbbRPXQ
2Ml2H02BuGTaxBYKcaRB014ea3m5/2yg92Kg37azrWsyjuLNwR3wJTitfFpaWkNWKrOFThSdaxrd
yuX141YMt0Hn48GzSwWJr1gxUBOtZ9uuZvKGlstKEyaT68rGM0NLq1QnhgcPlqeKtonF+iuqp4Wr
MX1ssm2k1wgD1YMC2T5n0Eu2N89rPWoA4Le3tB5mCFPTXt02mI51rUd5AK+sZaiWKmmBpwVoIDja
YUYlt7cd9QL0yrWcrJDLnUMEZJ0qrCPQOcQEdYawjkEdF9R5ZV3wqaLW2oUmaBXQ6X7J29h6S1tX
f3sbNTaYgwGIkS1UgMQIFYOEUWqlaGFJtaQRqqm+kuorg3ol1UcJ1Rj+eDh4etT72wU8/piAW8FG
2mgI03BhHPzQ2Bhm0BHMvHZJ6bgOEROsWmzjMYqnY7upFNtRPVXq7eyg66BhytJcPq2zTVKND4hN
pklqHEEdGgFb1Ml96C2AnToxWDsEWUQ1Ho7eNqlNpJO2LqcD8Dw+D9ULkyVlRnBMRQadyNnWHysU
ydeJ0iFFO7ZRpsa10UQoa2xYxMnagkaK0uLKOwWs6mzn0docdDZjMHIZ9BVtC2qW4K3OZSyRMdoW
qoTgCdLooiV1Pr2romRZk48D4iuqrS24eLm0LdQA5zZIGlxRxgRThjqgdbBqGl0LvrbhUmnT5+kw
c4agSViPZ5AuWh4pCqslnWNaByacYH8NaoSycGccSyWr6BgvBrVRdOda+YG2ZWjsoLDBPgHycgW8
nVtpYIINnyG90NZ/pUKaj4lTdaVWJ6v7+1W6q3cI2kulG+dUydcux1gFHu8UNKMyY1rHjrLY4ryj
wJPAk2ormc4PkQth4XxY+GtY+Cos/CUsjIaFc2Hh07BwNiycCQufhIU/hoUPwsLpsPB+WHgvLJwK
CyfDwpth4Y2w8HpY+EVYeC0sjISF42FhICzcHRZ2hYX+sLA9LGwLC1vDwvywMC8stIWF1rDQEhYa
w8KMsNAQFqaHhdKwUBAWnGEhLyzkhgV1WIgKCwrvmCx9IdPPZfqZTEdlek6mZ2V6RqYfy/QDmZ6W
6fsyPSXTP8j0HZn+WqZvynREpsdl+qpMX5HpMZm+JNMXZfqCTIdl+pxMfyzTIzIdlOkhme6X6T6Z
Dsh0l0zvkulOme6Qab9M75Rpn0zvkOkWpN6K6XyvXNos01tlukmmi2U6R6aNMq2XabVMYyjVV3Vy
VZCK6ESsRJyNuAhxNeJmxLsRH0c8hPgc4i8QdbCI/Rivjl72C9iNOIAoIQ4jnkA8iTiKqMJRXTiq
C0d14aguHNWFo7pwVBeO6sJRXTiqC6JxDcXYuhhbF2PrYmxdjK2LsXUxROGsAryLeA6RBT3SVMRK
xEWIj3OCV1CMvkeki8MXmeGLJy6evDh6kQsydnjsxNjJsdExrrsqmnPgsoeRnkA8iTjKObxa7uRP
Rn/CyERfZeTsOLCd/sVEphVb65GeRGRw2mha5lRPEn0G0VfZuCi5rES6mbHIbR+FVEQnYiXibMRF
iEp4F+k5xDHmUW8z++5JsyXprV8iufkWs+3mWxJefwPlm76F5IZuJCtXI7l+ldl2/arNNyb2rIs3
JS1bgWTpciRLuuJtS7r61iQmrDVvrEmwb0BMqCpk7oGHEBlIQppLJeYh5mHmEdAydzG7mLuR9zM7
mJ2gBRvzEOxAxC0hfRzx3xF/i8gx+7HNQdAxj2Pf7yB/FPs+Brqxj5hdh+MF91EUHqZCVSJzO7MJ
XSwytzG3gAL5rcxGvLtEZlOIb2SulfXfYpbJfBlz7WGFyA8x3YdtvPvHzI1YT9utQj1H9dceKXS5
1VVVzBpIQHwC64fkNsux9A5KHyGyzB3MBrSoyPQip/03I6fruDnENzDXyPXrmaV4MYjMTcipfl2I
rw3xpaF2PchB1gf5auaaw1FidlUjlglspZRZwCxkFqEJ5zBNTDPyWcxsphFNqWFmIc6BaGYBTEG5
DeWbENdh+REsP4X8N8ijmeXY43o0aCeOtAR5O460GPly8DCdiO2ICxDnIM5C9DEe2Wo1jBEdJeKj
WLBcgWW663LGiFarqzKhnkAd0pcQGWYK1kdhvRs53d2kUHs7to+iVnYdjjO7q8yMM1SRH+J5yOkE
uaGyGOI52FEhTq2qxjIBBdL98pKmMC5oQPRjqYe2ZaoZgzx1FXI6UiVyuvTJIX1ZiJeGeEmI8yFe
HOpXGOIFIX12iGcxBtxCf9UqLBNIRHqUKcItWxgrk4BO0TBaRodcxaiZaNk5KkQNGt+Cq1WhczTo
HA06x4LOUaFzLOgcFdYL2MOBzkjGkVKRJ+JIScgFdEQyYiKiBVGDqAIPaSYz6c7IrBC/hlxHbUXm
hvi1yKn+HfIW5jaR/DrEPyAn6c7IqRA/ST6R+TnktP0Z8gna2ovPC4fV0XjYhgl3uLAwJOChGRob
fvLlVN6NLdjDubnuZwhL0BSHU9OEo1Q8MpySIoSVyclhZVLSuNJmCyvjE0NSryYuJHnV0SgxhBzx
Nu5AiVAdSlXRqASYDalURTkuCA43zpVXBkcEga4Ink5OcXs/stnkZX6Y7nBfM0RU3jjy+18rxClv
N7zNeCWNzv38sELEBt5Jj8fFub2POgvcjz5MxEceVogP7+HEHzzEiQ/dw4ren+UWuu/Zw4rb9zy4
h1F3Wjtf7mT5Tp0eBx99cmqqw/3zIRLtTSIP7iXipMfI/XsZ0fpARo7b8gAx7K30un+zlzxLSkku
3hciKTg8won4cHH4OGV5h0dYZLlU+SyZQabLbaYf3qwQj5L5pAXPlb4qgbTgdluAIVvJdtk525BT
594Z4tvJ3XLHXchp+e4jfQqxskpLBoCQ18hxufIN5HgMyevk+GEl9WzU4aIiN2WHWGqGI39Ikd3q
Nf7Omuh+5VVWfPUYJ3qP2dOo9sgxk0XmL6E1ZW5OlFsLz+UVuhvnoJ3moL0/wG2dfh8L7+fkuEeO
YwQdr/bJ7Y9nZlL+9HFLovuFjwnuWn34HXlir+tjh8P97sfE+6It2X1kUCEOomO8w+Xl7uFDnPjm
IYV4aBOm63dize6f/Zjwu4hhF6FD7igtk4fekSnKSynagWPvvEsh3tXPiXf2K8R+tOMX51jx83MK
8bNeRhwd4MRzaBrvmaJit/cMzka7D8xpCvLaqUFe5pGH0wyg498dIAPYk+rvw/in+rd60T63bSbi
rbiqTTjFWcRfbyab+xyp2/uIuA3xDpxlC2J2n7tvWh+7tI/U9ZHSPpLRR2yTTNZSk6nEFFts0rtM
2iKTutCkLDCxThPkm85f0PPnC84zGZkxWZn6HDEmV9SnCTHpgj4lNYZP1YPCoGA85TEaT4/nIQ+r
Nxi16miNVhml0rKcQosXhFbJ+lO7c4g+h2j0DXrMFFPAx/awP4Tf6pUa0LAa/RSYom5j56tvYh+B
R9QP6X8D2qNEQ7TeHL2NJOusUYk6k8Gii+Xidc7zq88/fn7g/C/OnzivrDzvPX/ovHT+5HkFDBHN
Yed55zNEA5VE483n/sNz3vOV50tPrifHk+XJ8KR70jy8J8Vj81g9Jk+sR+9Re5Qe1gOeRlcLkWIb
oKGlWoojyJurJZfYMMTyTVKR2CCpG+e3DhKyqw21ErMdz3OLxG0fYpDF1syb3zpEEmh1H77TwiQg
NbT33dUmismSn35rqje5TSqiwu7kNmiQiuZINqFavBqs7VkX5mt7Qir8kmEwK6NWyqntkHJr231i
WCsDWYsQbB/qNc4nAI45Ps9VZ59YRRmRJeihg/VQTU/PZQ2vMgdt/zdK8ohrL+8D4Q2HmvT8c32+
seaecDvJKlWi765sMKimTmxsqqbfSW6Q/E0NUkrj/HYpUahukI5hqbRxvqQVqnHstUHooa91a6kj
QrpBYGpaBhlKlEjmz2+t6iQB8JMLiOcR/4r4FeJfEEcRzyF+ingW8QziJ4h/RPwA8TTi+4jvIZ5C
PIn4JuIbiK8j/gLxNcQRxOOIA4h3I+5C7EfcjrgNcSvifMR5iG2IrYgtiI2IMxAbEKcjliIWIDoR
8xBzEdWIUYgK73L/F/7P/Z/5R/3n/Gf9Z/wf+z/wn/a/7z/l/4P/Hf+v/W/6R/zH/a/6X/Ef87/k
f9H/gn/Y/5z/x/4j/kH/If9+/z7/gH+X/y7/Tv8Of7//Tn+f/w7/Fn+vf7P/Vv8m/2L/HH+jv95f
7Y/xXzVi/o9D2//MNKC4Cx9cQDEXDCCGfkRsufTTdvbZoIxvr75NaVgfaLokY+9B0LHloKOjMKax
UeYkGMYGJra4yg98T4ZnUYVQ/kP21bAp1KBznHfL/Jq/Nxq88Hdrrw6vwSvw76HfGHgWjsCPQvof
wVPQhyM+C+vlchs+EN0BA0hbUDMPpsFcWAjLsWYN7IP9oV6LoR0K8QugAi3aH9K+Ch/Bv5Gvsd0j
35j/XpzlRhjCmR6B6TheBezB3d4HP4THoQG2XvZ3KN+W6UmmA1bAWjgIEvb1Q5esnQm3QT1ch2ur
QyutgVU4+zw4BE/CEhiEh1D/LDTBY8qfgIrpoZ4a+zMzeezP8u9G3I/vjm5jdrG90AO3wGPwB8C3
/HB34IW/771/AnbDg7iLO2AX+nQeW842su3jvv1H8DTa63m0zXr0ygH0x2OwmzjgYdgGm4gWvg3P
kqL/9l/pfBp24tiXw0/hKNptP/p3F1psLfrl+7j6xiu7kiwSjXGzAuaRGLgAi/6bK7k6dGMsrMeI
ux3nuRF33gpLMbrWIe9CHP/fCfgIXAHb0evfw6R4GvXVcCusInZMlS/BdmKFjdj+26i9D54hBdh2
LTxJsuA8jj8fd/kNwHxgCOUDoOeSmPGc4NlkL9Ay+3E4H4QpSYdjE/MBEYgO4+1peALn/y48QmyE
hS/hFASIkySh57LhdcSX0G7PwPNovzPYwgq/It/83aNvrAV77FAs4UK131wLRvtdl+Wm2/CkPIrn
axPG0JN41p+He+DfkO/E0gCeoAfgf2EMHMBY6sW1Xpp3HriQLqNUtkEMRgaMzztM9WOvj43I846E
ewV2jcu/xNP8WzzPjZH/YxCB/1lgor5+X/EuM02hV5CxT7gnorjAfPIlVuzHE38v0pvxa9nV+7IX
2Y8Uh8Y+VTwTqFYYFemBNYFb8C77FfwGfgE/g/fhTYzsV+FDtoD9GXuK/Zxr55SKEcV34SkuH74F
9185HreK6+LmcPu4eVy+IhPLSXhXNcG1eFe14315PeY1UOyOKuTuUVyj8LOfsxcUD2K3lZj3tmJu
uhczGT12P0GyVdECWZALBVAMDV6HyVmclZ0LucmawvziXE1+via3mCsphWyxwBUbFxdjteYXslA5
UuTEV+Xv3x4pMsYSi9uJYBgxjBhdhpEiw+9fKiwgJcUVzKQKtqQ4Q0iLYaKEktJSV1EKY4rHQgxr
MllMQgkx2o0UmUlKc066JcOmr6rgC9IT1O2eO2vqOiuS9OmeXD7DFBW7m3x9Ucl2fF1GPjSbHTkl
mQlOl1toaIpPL0q5PSU/2VWXnVFRXpdnz83MSlKu+s53Aqe5h/9jKffVhR/hBoGl/y+HW4EZLxly
oBSu904xm0pzckrZ0j3eHG1yzp6sguQ8Nm9PsjeZHPAlx2oz2Iw9Wq9Wc8CnZY232u2F5pyEWwsL
y3LEzQrnqaJYt/OU0U0pVIqQaDWcFcEallB0Jp4VjbHgdhcWuEoqmBJjcT6TWWIvMptN8UpllCnI
BbaotARrhDRllNFodhWVYjEjQxA2VOTooi0ZWPP48wtrVs7dvnPDO4+kP/idvNkrKzNuSZ02b8ue
qqn33f5IoSGzfjrbUVspmHSFvr7l1/a2pKuzf3jT9h/NZD67d2ft/FILx1y8cHFVVPVtHR23VtD/
gEQtoUZL5MA2bzPEGGL4mIEYKUahZmPUDKNSq82s3phqdBoPGZ8zKtRG8x4vqImJVeekqPeoC5JS
U1IP+FJysg/4clSsak8Oq99njIkRyD6GyVVbNgsh6yC60DhBa4hGcFG+aOGCxIsvLVwg28bqNLyE
CowVo5DPCnYj3f8kFxYYQTDGpzAWk/2S7Tj1YnN2nqcw8NvXcovs+oUL9WnO/Ndi+NKsgC9kLcXc
wBu+ltzYiyeTfVMD83y1yYH1nvock7rwMjuhDfCWV9Kn6lJY6p1SnOBVx9YnJLgcmphMNt2RfsCn
c0Chq/CAr8RiY11sgrXYqiczi4tTlWfNlhI2NrYs0eZiU3tF5ykL3azFRbcrulxQaXHRvVqdlFlc
xljcpejCLWLIX7al2EkC3uiCOdb0jZ3aCbErdbmZFo3alJ0fWOTONaiVxkDP2sBu9Iesuze0Y7KE
LCK3kyZFusZsr679+vGainSrtrAwJr1uDtn8AClxf21nz5UHhn8QuCdUNdESX7vYEbRG99gou1ex
BHNAn1fvNMSY6p15TvrbpRrOPDQ26vWgxhwHVoOVt/ZauRjWak3SpKdzSXkcy+3x5sXFJbFJe+I4
677ZFmKxZPFn9fqCrLNRUUWwr0COhFPB8+JcIEcEnpTQ8TC6qIEwCGLdWMZ65IUFcSmMq0g+CZn5
TEkxTRxmixwWaUqlKd5stgTziJCWaXwr3rdy7rpNxTdtWLe9ZvnPt8zYc0OnpW5hQ9Uyj2vlit67
Zlev+17Ht0fIpNalhRvXNSyd55m8+vaZ3fvnGZICn7cuzizoqJm6uKXYu+quhcv3zM8uIbH0jJjw
jGzC+KiAZd7JWfkqK5k0yVmRYi9k8535B3x8iZieqHASQxxbXlF+wGd0czqzooJVWSexWVmpceVx
5QWpqd4CJ24p1o3Z0eg2WsLBYcHosIyHB74wjWCAmOStWSyTMA6KMzAKTJgo2bgUlsaGnBcyWVZu
QmOFnRRH8tnMEnKqICdD2HM3z+vSc8hax5SaivcCpc5spxCYlp+bnPLUcwXpOYGtjoLc0ilnAn/M
yhaSYhVzC6My7Ektk//8YXFFjjlVVBUWavNbFwW+G1jYNrUwXVdYqBKEJF8RyQ+8PNtlz8F6TWrB
9OtINznhnZyuVxbS/4vWiFEjYfxkQBH88SiQsY+e1BvIDBga+8gbTSUmnyRzWUNjJ70+tb4+S6PJ
ZDPv93ZrejWSZljDgcagadTs1gxoFFpWo0koIPlcPpv/mJczO9IP+hwmPq4gbiBOiuMKkDBx9HuZ
mZm59VxcPJYSdKZkUx5mJdZkSDCwhgcTDHHx8aqUPqLJYIvopGo8skVFxTl9KiwdwYLKKcrHNHha
R2gk4lHF4LMaXlwjLlhTGQ5McIXDck2wKMppShQdmZiz0zIySorTHXKixrwt4MF10byO55j6ig2G
qJzLme/pr33omhk9Ffi2wZ51Tf2sRdYt7b291Z3rPUx0fGZu4FPtz1/Nryvwra64m2ubPuX6unse
11V1rS9rarq9yGmrvH1LYN/08uJUs7aQHGO6lrurE6qXFqHtl4+NcqLiAUjDDLbMm298wmDQH/QZ
TK54p9XJOh/wWs1p2amp2Wz2Xm+qIUp50BcFKhLdFxufxgrUkNQ4glCWu8XmDNsEKisnnMxxS9Bb
zWr4ACO0mAYc5mc5X0UJkzLpCcwYP59YjfbAvbuKKrgSlmN1lkzX51OU8WLpGY9WX7lguWff4Z6f
3Vy90h1jL6tx9m5d1Z07uWyyLYarbJ9RkhKrLo7+j42zarISNMXR+7iamqzzn+z7oNtkDQzOWujN
jR8ZHj6mt08uqJCjrwuj7z6MvgSww3pvNR9nTrEbWeP9XrtdY4ap/LsJ5xIYSDAk8AmjCZyaTTBz
Ztb8AAaXJoVN2evVYI0lFuyxhi2JiULsHVGyHT6Ldb9tdCcmjAQNEaaGt+VYSDgr5/NLV7tjggXQ
KPaQ4yexwSud7fVe3zvztTeuf+m2JbvmOtmL/SUbOpq2VF2vzGnxLbtZ80TNDPGrz/aevsW7+gfb
Y2/6zvzyWjJ35Z3T9j9Ec9Bs3OaHikfx2Wyll4+OUkUd9KlMhlh0s5l8KuqBN/A8P8yf4BU6lqc+
taY56nl8gEln0+9Ppp+Pse/nRabPqqc/DTCQmXq8iT4reovuU87C+KwyQiO78qyrSH56QXejmy9d
vWyJEaObw6c4VxE+rtF4p09uLqbznC4hOy+wLDfDFL0hI8Fi1HHq8nV982ZP6oxz5dvzMmy6c+y1
F79X4xNM0ZhczGneWmaBSxkVk+jKv2F7e6bmqSmFsRneRTOWU18243b/pPDhU1oCXOPNsXAJ3EFf
gikc1Xqms5slevZdltGzi5CxLNnCxPUx0aGDHR3aYLRTFF88ZTgFzgVrFpwNxm14V/i0ydINyTcs
DWIzTaRk89DSTLtFx1kL8/5UbshzBdYrfC+8cOGsNpavriNPemc5LaoS9cWSa2oEfHBAr1Qi+R2e
PDMUeE1clBK9gjEfd9AXDyZiJtCnCy1Gh9kGj1TlJcs6gnOWBJchnyWyks65tijTGCUfl888F+SZ
CnVJmTWlbG34XNCZ0UrKRexxfMI/5b1Go6L7pk8lah4JR4ssJQwtEkqAEpVLabW5ZjcpSktKD/oa
E0tMi55YuHDBQd9CPVFniXWKGmUNW/OATmlQ5/V5MHXTpVPuNWBvj6c1rk9vJzXvYv6ixsZKO63U
YKXdvrgd6vta6X6NZGYr7ayX+Sht14rOEE8V0ccjUVyzcIGcZlABla6zwVsw5CDX+F1IU2wQiIXG
nNlCUyve9RMjsjifo28o/paOvaSTHU1Wx3hm1lfa/bdaGxZ0lNV01KRGx2XkBb6VmWbRqeNsafkZ
WbVz0i/pok32tPzk7PqGDKUu3uEIrM+wW7U0Pj4uZ9M4T7nDcN2iGfWZmXM2LgtsmzGZt+AzFUZL
jY8o566uzkgy8DNmFgfuvbymrduXY9Y46mbkBu50e9JMcdFy1YQQC3mYc6KHPXCTtzyfOiAvC0ku
JSIlCUkeliHMQV8iMWU/kZWVedCXpc+N1RfoWf0DBYbSPpWqIjcnvi9taOwE9UUa/XmywUhmpDnD
vjgVuvYumV+2ftD09ivNOTFgZXNGBV0SepjlnIGbqM1UcTZHQWZmXUuGfITCJ+rjck3M9PkLikvn
VuWYVPEZzrA56m6clp1sTJ0xvSCwIxjvlxvje1yDV0gonrmyObCttgIngOCdx76NGV8HSTDNmwqY
7fd6wRyVyCbujTKYDRoy07wlmtfiuYhOicEofAo1MVtYGreoZPE8ijQGT4mXnkELCxTjNxh9Q0bk
24sJ3e1M/Infrj3W+/bvVr0a2L5lY83CKYlV3fUbbjN8Obr/9Orzfzpweg258Nrvq1btmX3vC/Pf
wDVOCzRxGvRgFpRBrzdHrZSvXhtk5Gfgo81eb4a5NNGV6mJdD+C1bHkCnxoO+sz6tC2FoUxWSPO4
Dk9PYeFksCayZX16+bam2ZvGg5760RI8U/I7T+rB8Yt6/OoO5RvTZUeEDfmPDe0Vby42PvikbZDd
TbrVFrEg0JWeZ1VxWktm3iflOn1F/cypWfsH/c/dMX19kbW82bdh4wdlcxrtKW9WeR1WDONoU3bd
ZHZefXlWYqyauq7SnWH46tP9p9YkkEXtXf/J3tlAR1WdC3ufTDJ/mUBIJmECSEcImCIGBEsjpRgw
YqhokaK1/mAmyYQMJJlxZkISRIgQkqioAfkT8adVUZEi9e96KW1TpRRbGq1WGlvkAirYFiPQFrFF
zvfsfc4kE0i7uOv71vruumvyruec/f/u/e69371PBJnifXOn1jr8uumjzBVuuYQ5vEiUFw7NzvHk
PFPkyZK3vZGbR/Tvr7mEPd2e5LbYUxpd8sMjIz27mMuhKyXdYbd/9SItY/lQc2UPHSPX8wB1jfvN
xeJieZZxlA0YP/6Kj+POMrVaY0dXnwsa//D1OdVXTRxzh2fCmNyrp+Zkjx9/pjpuz2dbrrx2lPXw
hEtHzZw29swPbrnK6+i9XA3vPIfV6WRkl4qHC7PHDLpi0LcHWX42SBOD0gd5WaGDRl4g/wxAYXFG
dvEYjZ+Uka4FrmZX0gjX11xJFuFKdxW6ZrpKXCmOFNcF+VkXWC5YU5iVnZ9iSVmTnz7o6ZycUeO0
pwX2WT5s2Hj78lHdn1QHB8R2dc/lDUvcftttxsfVbcaH1W1hebSre0mvLyi+NMZndy/6uO+tJL0k
e9KMr8+8feRMf0XwigmlLTNnP3ZN6eB5t+VeNcGbN3veLTVXfO/ZO6beeVvSwUlXDblmSv6kyy4e
/a3Som9XFQ3Ncf/21u/0Hz7pkvGFX7tkZHHplbMaCtMypZ1G6MeSXk9+iT18Y+GlA9Mtbm9m4cgx
xZmFrv7FmenrBmYnOftbNZfFait0imeKBju7bP0z3Q7HUFtK6vJBYw5eLid9r7y8jzNuMHLWL7/i
y70XX8y1TX488m00PuvCrAsHGIv76wPVUucqM2Lc5OHu1Ae0K8/8JH10wei8acMuuXpJ0d2LV1vu
teddcfstn/vPXOmLTBly4VcmXDX54SeTLpb9nc5Ne4RlB7ew8sJhF2weMmTwM0VDsriPDbdZbOsK
h2dnjtZGc/pr/bOXe4e6Yh8eLld+0vI8tXc5G/PkUZwn96zxawKmy/g1wTmX7Eyz28YvA9iyF/Zc
t81vjwFynqZrF2TkTp04ctqNI6z9ModfpF1gdY+a8PE3rf2/s27GLQsmpo2YbNlxxlK7cPKoodd8
61Kt7vKJw7MznJd+ecO1ReYF++bZxQ8u1RbOvmKE/MNmmxls2NLCHcwmxhd+JWmbsKRbvJaZljZL
Sn+Lxbat0KolpbxgtTusL+SNvVhLPzh+nPo1l/xM+tS4YGXKX+mFd+/ebWn585+/9H3yCe220+5D
fEnLdkcXDkqSDXGBE0la3kTxrmVqryZPHJSLeMygLzto0DLcohp8aIrv0jd3p9xw+hrLK/98iEZp
daVlZ9ImbmGy1bzCLKvQ0uWfvrLLP1f6giX5BZvNYVf74neYWrrL28YbLV4I2uzCwKCkrCvm5aSs
O3OJ9q5E/Vp1Qbf80xDtrnhJSo6T+2Ni+cr/MvlASvKc5LdSipRsUPJ7627bd23P2S9HNjkmOlY5
rQlJyP9AGdcttyUkIf9DpSUhCUlIQhKSkIQkJCEJSUhCEpKQhCQkIQlJSEISkpCEJCQhCUlIQhKS
kIQkJCEJSUhCEpKQhCQkIQlJSEISkpCE/O8TIf82otDk/8D9YtEuUsRUGKz/STjEMn07z2Z9G88W
9XxQ7+TZpp4rVcoqFV6tnmv0nTzX6YeEQ/uQcDbtHBGDRbZ+mGczZQbTjnyuVM9V+lGea9RzLbUG
U7dTLLNMoG6LerbSh094NtNOK3Xlc6V6rtGPi1btE7FZtFom8HxQlW9Tz5XquUo9V9PCBzybaX81
LcjnA/pJnisJryW9i2eLeq7Uu7QPqdWJTcYkTTT/p2hpSeu7/wdp/USVihn/xme5JdkMa6KfpdIM
J4l+zrCI/euyY52NZjg5rkyK8Di3mWFrXLpN/MO52wzbxajUyWbYIaalvm6GnTZnd/lUcaPLboZd
Is81xwzH+mzp7nPs/9Y4ztVshjVhc71mhpOELf2bZtgiPOlFZjg5rkyKcKXfaoatcek2cVd6pRm2
i6z0J82wQwxP/9gMOy3Lu8uniosH2M2wS7gHjDfDadqMAVeb4X5iQsZD8l/jTXaYdjbChp2NsGFn
I2zY2Qgnx5Ux7GyErXHphp2NsGFnI2zY2QgbdjbChp2NsGFnI5xmrgYZNuz8PREUtcIrqoVPNPCu
FRHh5x0VlSJA2CsqKFFD3EsJGQ+RH6Z8gLQo4XLSSlVdWUfWvUrcIGaIKWbdcFxOiFiQGrWiTLUY
oGWvqFO6ynj2rdeIy7Jlooq65abWKCW86l+KjdBylTkCH+XKTV0Bs4Uysy2/euaTcva4ZX6VCuVR
66u8/eSVdmvqq1c157R8/jbqab1ctTSXtDDxCCXCyhpRnrLtvsduaD+3X9+Is4AciTGWqNIXUrPh
U+0bYy0npU6NPKj+zd2+R2rY2dfLpn41r0HzaYzKCNcSC6mnV/V2gRqNv7sdWbKKEv9+hiqV5UJi
ohiD1CnJVxYtU2soAhWqpKxZTZkoI5IjnKvGGKKFBlJjo4gQlr2pIK8W/bKmT62bevEc+seJscjl
hK49R4dXXKlGGrNfbGbkOppCW1W8Z5E2V/U6omJ+tY/CjF7OVz4t+NSMyxH7lBWMlSLXgF/NZbmq
I1upMee4otu+NeIS8srUCjFKy5Avbu3E5tywsZzPoJhPaK4KlZu7zKgbP4vlqq4cY0TtBWM0sh8L
VX/kGKer/FiPF6hxNag1vMBsUdrRR//O7o2x3w279axn2WaRssNcleJTOmN1jPajahaMHKk5QFqV
at+vehErbVg5gK2M1LBaaWG1xoyZWqDCDapsVPVH9nF0t9+pUjUqVR/lqI314jPt0Ffr8ZaK9SPQ
vXp7ZsHYc4bdDHv29GG+6QVquucwovrti9tLUVW3xqwV0xQ095ZRrlr1sUqN0rDs7O4dHJvnMvXv
bRvjNHKq1eqWrdSo3WvsUB+rMVaqRvT4qoBpD1kq0r2Swt3nhN9ccXUqtUyN16/2dKWymU95M5nX
24q16JNnQbxHi6h9XBXnL0pV2Bc35oCyTqnpLWM+169qVZseJKIsVaF6K2e2nB0UUPM2t9tS3+3e
EWfvTsNKxlkYvxPLlGeJ98yxvRPbL1LrAnP+pE/xqtVvrI7RcfbqWTFhenaupc7dUxG1RqXvKu+2
SkTNiuF3jDUeVj2uVfMZ3/MeaxmnjOEDe1aM/ywPZNigRlyk6sxTtoiK3uv8bA21qraxQyPm6VJG
as+cTIzTJvsxV/XDp+rXqZk1xtKXf/TjqXtrrlMrs9I8m4x25pp28atWjBVQbe6qeK8h7epXe8Mo
36DmP0grvW1ytelz58fVvpLSxhlq7Inz8+a1Zs+NdVSldmBsH4TMsyKg6gRVC0bffeZcxNZKTdz5
Y/ioqNq51d01pJ1Cpg+NdPs54wQPqLno8VAxOxknUkDNcdC8fxity97X9fJAPrWbYvu12lxJge4T
KqB2iNc8j89eV/nqbOyZ93NP24nn7MeJInY+TxA3mn4kZqWv0eLlpPe9g/3mCjGs7utedcZI/eZu
8Sqf7FP9rFa9mi9idxvfv8yVtj7/u8LZPvUGYoHuE/g7yrrRXmfbmD5uV2XKA9SYd0TDj12r2g/G
2Xu66efOPo1nK88ZVCGjrOEb5yvf8v/mviX9V8+dq+9We/LN1p7zjhs79nLvtYGycDASrIh6rwyG
Q8GwLxoI1uR7p1RVeWcF5lZGI95Z/og/vMBfnn+lr7o0HPB5K30Rb6nfX+Mt90cCc2v85d6KYNgb
rLkkUhaWyWG/rzxQM9frqyn3RoPeqmBwvnduMFjuraskNxQO1ESp44t6I9U+1EQCC/2RfO/0qGp4
gT/c4PUvoGAk5CuLNRMKB+mb7BoliwK+ucEaX5XKoXw0UEak0hcIVwVq/BGVTJcDFQTDfrpTxaAW
+KsavJFoOFgzdzQdCVT5vZXBcGBhsCZK5bjiRqdkG7KfxhD81SH6Rj9VC/P9XtLpWsSLuSr9YW+0
0kd/o7JSsDZK1F8d8VctkMOaXRmIqDGXBULoJFIdjES9NUF67feVyqQaWcEboB+Bsog0Er2QKVXB
On+4zBfxe8sqfWFfWdQfNrtYW1pe65cdRGkDTdDFUr+0KNUCYcJowJb+Kn+1v4YpDFZ464Lh8ksC
1b65slPflRMRm066VBsxJ7HMF1JGVrMj58UbxMCsFG8oiDlGq34pw4Qv6e5U90xFKoO1VeWyK5Eq
uXaweNhfXltmNq66FfZHaquiyjB+cwHRg5qLot55tWQbNo9VqI3ICY14y4NltWokE1W1sH9ubZUv
7K3zSy0969Ffb1auC0QrvT4vZebSF39UGqDaJ9Pk0igL+GvKSG+oLg1WmT25mpU7X2Vf2RAOVDET
fSzzWhrHRlXBiJyDELsiEMFasnXmX1mlRu0fVlTU76uWGf56ykUjcs0Fvb5AtV8tKNknNlIgEmUN
ytVb468zFpAvrOa1GiMF5IYKhJjVhlDMVvmzjLF3b9uJsXmcKPfzhBtZI7JLX8u/fELcBPsDap36
pOlQygqjG2Ffub/aF57vDcqcuGhF314htlJvqAnIDfydqC9q7LYxcvsrBWXB2ppoOMAauzbIEpf9
ns6ai23j2YFw0DubVFbj/EhlNBqaOGZMXV1dfnVMX35ZsHoM9YJzw75QZcOYsmgFOzS+qIrLYt8L
1jKpDXLx0i0GKXPkssfg1YGo7GJpg+rwVTfMmKIWlIzgSliScqVJN1BWGVeXN/u0qrbcmKTyQCRU
hQLDATG9DE8uz2i+N6Y7WMMazwt8FQ9RKiv1NFUTK9xnj1Rx5STZDxiszNh13dqVpc22vqE6kBdA
SxRHxGSwQBvYE3U1VUFfvFL67DP9a9jbPSd4pBBOqdy/AI8jy1T6q0JnDeh8pkIZfky5v8LH2sz3
RUL1sd9xCn0ZJ0tfP5pIEnbRX9dFf0LGbwWFlieE+veftD7rxH5SLBNcLvkvyGjrz7d8Wposn2Q/
3/L9+6vy9edbPj1dlf/kfMsPGCDLW2463/KZmZTnLeRvSZNVefnb42yRIuTvStNEuhhEbIwYLCaJ
Zdw5mrlVtHADa+V2cJ+4UzxA6EGxVrSJZ8RK8aJYJX4iVotfizViL6kHxTrRpX0ovtA+0SyWCVo6
XfL01qcNidPXD31DiI1H3xT0fRt9N6OvEi0R9N2NvgeRR9G3FX3/iT752/R30PcB+j5B39+1DzWB
vlT05dD+hb31JX0zTl9/9A0l9nX0TUPf7eibj76F8rf76FuDvqfQ9xL6dqHvHfTtR9+n5Hwh1mop
Yp2Wib6voG8U+i5H35Te+iyLz0PfnfK/I6BvHfo2oe9V9L2JvvfQdxB9x9B3Gn129GWjbxj6LkHf
JPRd1Vtf8htx+tIRL7FvoO8a9FWgL4KmJvlfLND3A/S9iL430NdJysfoOyFWaxaxhrlaq12AvtHo
uxx9V6HvBvTN6a3PemGcvq+g71JiM9FXir670fcg+raibwf6OtB3gJQTok1ziJWaV6zS8tF3Lfpu
QV8AfQ3oa0Pfo+h7AX2vyX1stwq77VRRUX1RUdEpGbGeLiqsLywsPGB3CLvzw8Yy7to3sD6ns24+
bLSnUKK+tbEk3d56zG6j7uGivPT0vKIOa4qwWkva0kNtpxxW4bB57Pb61tbW9VUqI9R6qrE15EgW
juSxtF2oFFiE3VIo2lXEYREOiwrKmNUhrM532AnTlXzaaLUKq+3tyuLi4qNme/yEHDK1s5yu18tK
ycKa8naoMBYMtRV62w7Yk4U9ubDwGMkzvaqZTlopnpSiaSmWxkbR2GjXNDuhRhWxWDRHyhNPPOGw
ag77qSLTMDJmwzDF9cWyrw7NkfpzLNPbNo5kzWENtTUWetPT2w44bBgB4+Sl5ynraD3W0eKtk6wy
jjW2lRjWmWlaRxqEfseZJ7nHPKnCmvp+Y0VhkZKuA1ZbzBBdUpOtT/Ngt5TOSsM8KO3LPLKZPZSf
McGqaVZpHkzi0DRHcuPZBnLaNKfj9NSpGGjq1KmnZdR+Zmph0aIiqcHp1Jyug+2+xllKZigpbDzY
7kzRnLJ7agW1hpwO4XR82DhFDBNuFr6d5zBlTJtVs1EOK62vUm27kpMXNfGzYoEtRWWpFeVMEc6U
gmLVf6nWojm7jSajwtlttcIDtlTN5uoxmzSczS5s9n2ljGDqEanSXi91NNU7bd3pi2TNFGGzKtsR
TtZscppL5CQzZSmG9TCfTVaS5jPtl2zYz6nRqcZ4AzqtpgGdvQ3oiDNgquZMO3CgpP36wusLv4XI
/pJ+wGnFGPSyscSTLDv67wxoNw2YatNSHRgweVIRg5sxQeUVFDWdbiwqSE3RUqUF/4UJUy1aao8J
DRumnWVDm2ZzqGVW1KXCBUVLly4tKnAa6VPlEJUNmbaYDWUYNxLCizhSlA1PyYzisaqBvmyY5Ezp
sWFyspZqbeNHjkwaMWZFNdIzU7vNmJqqpfaLmbG3IVOtWqoyZOFYu7RkqkOkOg1LGrZ0q5DyelbN
Lm2pjOmyaa4eY2JNlausiTldKZorzpyGAVO67Vl4wGWhQI9BcYOpmr1fvEWlTe02zW7atKhLRZRR
sarLyJlqmpX6KZrdtKsZiflnZzIrLdaTmV7VjDIttrVpmk3ZFmumakmp3cY1rOuySeumObU0ly58
jSXtUnyNS+LCukiza2lOvcxXUlK6uLSEn2Np/bS09AOTQgWhgpv4mbF+xvqrPVd7piKFngOT0mxa
mmNSxevt7aECl9XavKc+LVWkpR5nfsY25nAh6if/c65IFZniQvQcP+Cwaw7Hol1W6+SKXR11aQ4t
LdXGTVXKFXjfN7plrvhGo8NG4UkVu3adaW8vnZRm1dKsk8pLSk6VGD/H0pK1tJSSEiEO9EqJxVSK
o5/mSO8KRdaXeXrk8x3K43ep39D1yOeNsnvOSRVvyJ+KSWmxQr7GmJSJxaJEyTEhu2fvCscUyfNl
0Z6dB+qHrNhzSm5Ca3dXK8cqfUd6aZMjtCdp9pT2dnnFbG9PS6Lz7caPnLf29uQULc3W2dnZJswb
qlOsTfpIWMoawlXCPTfsny8mVPmiNdyQnEL7zqyp8gYjuNEbfxahnxnW5D3f+OcUVTxJ3XeyhWX6
zJnFYtisb1/rFfmzZ13jFRPNErhZMcAMJzN9GWY4RbiYSiNs5c7rFlnz+bAWjerZrJ4r1HOVeq5X
z8fU8yn5ASs2q+c++dT6qWeheobVU5XR9lbPr56fZFfPDPUcop4j1XOsek5Uz6Lum/v5PAeqbx45
ohT5JyCwCr6W0bkYST914xzASDPlqLDOwESN/1YNi/AIueX/b0KDRYG4VVSJRWKF2Ci2cBPeI/aJ
o+K05tKGcL+epM3QbtWqtEXaCm2jtkXboe3R9mlHhfxTIBb5p1H4JpL9lndh9d66Tb01Z6VwqHUg
/+QKt/FLT/SOT2ztHZ+8tHd8ak3v+HXpcfEUoX2vsXf+zf16x0u39y4fXNA7/w5X7/yGV3vnL5zV
O7/Z0zu/+bXe+fe/3Dv/gRm989eV9M7fcNZ4njjdO//7Tb3zN3t752/e2jv/1VuFIykWtxL/SDi0
uPj2TXwdxMXbM4S26V7po1LWp05MrUwNp9anNqduS301dR/hE3DaNcp1mWuO61lXV5or7UZKnSv1
SGW3hFUrZ8s2U2g57VZa36fKnS31qaeloDMmlyl51hB6YMiNUlLDA4Zle7KHZudmj8ouGCjDuQNv
4inThg5cMHCfx+lJ94zyFHlKeUZVztkyCsmNiWehiveSgcMMUaVzpYaBN1Gup4WhfciogfukoD8m
bUMOX1BCb4pMGWVKVMrwmuHHsofmjsotzp2Ve1PunNwqQsW5zbltuRtyn8jdmruDtNfJP1dkuZtM
kfWqzLpnS7OStm7ZoGQPbRsyx5TXlRSP2KDGURA/6rz2vL1IO3JgTHj8E+M3jd82/tUJ3oKlBUtj
b5lb0Dpx8zcLJ2+NvacUXLk/xrTKaffGuNpbPK64dfrC4nHXPnvtq9e5r5tQPO76A7O2Xuee9dqs
vbOO3TT5po++t/e2sTL/9kHXuYlPvr3k9nm3N92+1lfk+1bpotJVZdvKtpftLuso21d2ouxUudV/
q7/UV+Sv9FeSc0KKv9Rf42+rmOCvmfu7ufsrL6uc5q+pPBp4oPKywOp5FfPfnr+/qlPmVV5G+O3q
PwRfC80LRUOvh/aEDofLI5MjocgDtfbaobX1ta8v2FfXDymoKyA1FIrWTVtYdeeuRbfeNTS0Z/Gi
yGSZs/id2vol9UuWLtm2ZP+SvzVObZzdWIGEGpc2PtV45m4PMuzuYTJtyf678+7uWDp66eFlLiS7
cbbKWbps7LJfNXma8psKm6Y1zWi6uam8KdzU2NTctLrpsdwdy73IyOUjSQs35S8fu3x78+zmtZSc
1rylqVzmNL/YtLolGcloGdIyrGV0y4SW2S0VLfUtzS1tLRtanmp5saW9ZVfLRy1dLadbna3prUNb
R7eOay1oXdz6Wp/7O7bH46XXvm19vW8xdmuf+y629+Kl1x5qfbtvMfZNn3shth+6xdhd54qx1lv3
uy7zpOduoP8fdfuf5tYzrjl4KbzfPfZZe12X3ZNxT6H0NvgP9gGWCJv2MLwZtWQe4ZiVZDv4MOUr
u+2U5lL+dZ/rstb9Mv2e6yjhMn1uj/eLieGDX1V+eF8vb3kCOf0vvKT003OUp+wyvLXykrK2rPOq
9JjSsve6YM59M/GV0usN9aTft/m+lz3R+3bdd8oYpenV1Bwp73eTjK/IxkNGTU/oic2Y9HMrRmd7
lH81586jclZMXDFzxU/xgqPuj95/sjs3t3u+C1oLultDpI8x/Xef3tXwqb28aropo5SXl36+NOZT
6ZH0tqOyPUMOS+0PFEoN5Ki+5RY/cLNaI7Me/AQPO4cQ/rDtW6b/k+tIribDq8pyMvWm7hUmfenr
cattDuEqWhjVto+cOb3WoeHR53R756qzfPK5Xln6/CeUV95hen4pG5SXHqVaaFapxXIkbV0r2x6a
lT30ocqH9kp7PXR09Y2r21Zkz9qLH91reE184TY832WGj5v/Nn73PAU/e5bgq3vJuSXw5L1k1muy
D/Fybh3DZ/srY+9YLBaXI+glu5ET/17w/P8dqTl/4STpJYZte8Swcl/Sl4XliRKKRiaH5nHaKKnr
F4rKM8c8bxCZFhNOpj3y/FE1QoZwOiGyXl2/1a8u2CdrhvbIc2bJfnUGKbnbQyxknkKexqnGm5A8
oaaqp5SlUjidZOkzjWeWudbY5ZnDGZRvnkdKlnuJN5snEtI0ozs0zTy5wqasliLLL/eu6SdX9XKv
6Qu4XazJXdMhvc6av8m0tYuNPb4uef2c9W0PD3p4xcMdG9I33Lzh2CNJj9gf6feI96G9hJLYyc6N
0x79CC8Qfcz5mOfhjvj7V/bQx+59bKPhQUyfke6JPn7v46uVTyl4fHvspuhxPn4MrxF9YsL3k78f
/kHVk84ndzy18GnX07s2RZfUNy6NyJNb2YUxqNHU9bvbs9zLV9l7eoGWrJ/U5umbtMN6p3ZE32aZ
Cdfr2zw/EpM8L8IbYlJOSIwTSdoM4abkEW7e7+mfCQs1j5tpx4VT0/QOUnZq/WnnUsIzRJ52PeEy
wvP0Q1oj78P6TqERk39r5FP9KOX3Um4cKTvJ247+GfF6+SJ4T7+R3I3kbKJnnfSsk54k095hfZsa
wXY0H1Up81RqB2U7KNtB2Y5erSVJzeQe4ov0EGU1tCYz8v76e3E97lA9PqznS518q35KTKNesv4S
Jd+l5E7V5+t5l4Fss1FpXiw1u+tFedbL+o0eySvQCe/rBXz3GiP+gFaO0Eqn2Yq0UKdpIdnKqn/b
io0WOlVPpVUOK8vMo/Q45miS6m2naQ85rk3oecQc10b0bKPWdmpZqRXtpcNsP+cafXtOSN+oZmm7
OC6scm4hA9yQrZ8QA/UO4dH3ixzmYhAM0d8Vo8i7GEbDJZAPE+EbMAm+CTfAjfBduAm+BzfDLXAr
3AZz4HYoQ085+KEC5kIlegMwD+ajvwqqoQaCEII7IAwRiEIt/VsAdVAPDfR1IdwJi2A9K/JhVsQj
vE/x/gL+Af+E06R9CWdAZ6ZzmJtBzNFgbDkEWw7FvvN4zye9CqrJq4EghOAOCEMEolALC6COOvXQ
AAvhTlhEW3fxXgzMv9bFPH4GJ+CvemeSBVLABgPZB1+DCfANmKkfYq0fynhe35+xBX4IW+EF2AY/
ghfhJf3djJfhFTio78w4BB/qOzNt+qFMOzjACanggjToB6yjzHR9W+YAyNQ7MrP0VZk1+vHMCCwA
bJt5F+/FsIz8JmjW92e26O9mriZtDeG1sA7Ww8PwKOmPwRPwfXgatsGP4GXyX4GfEP4p/Aza4ee0
9wbvX9D+bvL3EO4g7V3e/wV/h5PwOZwCXT/hFqBBElggmb2VAlawgV3f73aAE1LBBWl6p7sf4Mnc
6ZCpv+ser+90V0Id/Aza4ef6Iffr8AvCv+a9h/de+ETf6D5K/G/6Kvff4XPCp/RNWVb9UBa2zsLW
Wdg6C1tnjYCRMI78CfqqrCt4N/BeCHfCIriL/MWwBPARWXfDUn1j1jJo0rdlLYdW6t1P2QcIP6hv
8pzSd3pYyznlrNtvimT9GZGiHxU2sIMDUsEF/aA/pMMAyIQsyAZWGjv9JDu9g51+UgzW17Pbt4gL
9LfEUNr8CnjhQhgGwyEXRsBIuAjy9Kj4KoyhvbHCLS7lPQ7Gw2XwNZgAX4cCuBwmwxVQCFNgKlwJ
RXAVTIOroRimwzUwA66F62AmXA+z4DswG0rAB6VQBuXghwqYC5WMNQDydJrPWKugGmogCCG4A8IQ
gSjUwgKog3powDYL4U5YBHdhp8WwBBrRcTfjX4p3tjIrF/D28r4QhsFwyIURMBIugjz4KoziFLwY
Duol2kfwMZyEz/WSmCfIaNWfybgH7oX7YAXcDw/Ag9AGK2EVPASr9aMZa2AtrIP18DBsgEdgIzwK
z+sn8Son8Son8Son8Son8Son8Son8Son8Spb8Cpb8CpbMj7Co3wMnPMZR+AT+BP8Gf4CR+FT6ILP
8DyZeI6B+tFMD+TAfKiCoHDjVToy6wk3wEK4E7AhHqYTD9OJhzmJh9mS2aq/lbmC9PvhAXgQ2mAl
MNbMh3ivoexaWAfr4WHYQN4jsFGPZj5OmSfhKdgEz8BzsJn852EL4R/CVngBXoSX4GXaeQX+g/Br
sJ2+/JjyOwj/nL69TvgX9PWXxHdT7k3ivyLcQd5bhN8m/Ft4B34H78Fe+D10wvvwB/gj7IMPYD8c
gINwCD6Ej+BjOAxH4BP4E/wZ/gJHgdtHZhd8BsfgOJyAv8Lf4Av4B/wTTsOXcAZ0/She9Che9Che
9Che9ChetBMv2okX7cSLduJFT+JFT+JFT+JFT+JFT+JFO/CiHXjRk3jRk+4B+np3BmTqW9xu/S13
FmTDINobDEMAv+JGZxb6stCVZdF3ZqWCC9L0G7PwS1mslazBxIfAaMAzZ02EImgmrwXa5D2Tu2FU
PUvU85CwiLe4+cnUT3lPFO+JGu5JR+XfJtb+IjYnaaLGMhbGwXix2TITrocgNMBdpC+GJbAMnoZN
8Ax5z/J+DnbBL2E3vEn6r3j/GvbAb6AD3hI17tHiZneJmMYd7LC7QdS77xLjsp6Fl7mzbhTTPI+K
es9jotzzDPFnQaa/AtvFbs+PxVrPDjHOsxN2E3+T+DuUfRc6KfO+/nvP5+SdJv4lnjuNUf7ZPVLM
dF8kZmZtFtdkbeXm9wK5W8U1nhfgR2IFt+QV3JJX5JSJcnXft2EpeY98R97MKTGNEtMoMU3l5nBz
6uLmdJybU5eyLicut6fj3J6Oc3s6zs2pi1tGFydnF6dmF6dmF6dmF6fmcU7N45yaXZyaxzkxu2h9
Jq3PpPWZnFxdnFzHObm6RKq81zMPQ5mHoVlb9Y6sFxgfb498/whe1DtyyvTfG3dW+tEhrGadPOrk
Sbu638YWL9FnmXOQ0RzCmjux5k6stRNrtapb9QcyJ0vmnJ2bbFriLfnNwejzuB2z0/g6OcRZ8an6
AnmJlBnyRq1liSa+jpZjgWZogXsoey/v+2AFp8T9vB+AB6ENVoL8O/EP8ea+JPDIYh3fWesZ08N8
5WxQ99ONAo8sniN/C/wQtsILwJ1J/Ae8Bj+mDN5HcHcS3J0E9yaxC34Ju+FXgNUFdyfxG+iAt+G3
8Dv4PXwA+4E7lTgAB+FDwJMIPInoom+fwTE4Difgr/A3+DuchM/hFH3/Av4B/4TTjOFLOAM6d2h2
ucYu1yx8R6bon3Hn7eDO28Gdt4M7bwf33A5Otw5Otw7uuR0ZrJoM+p5B3zO482XQ34xOeF8/kvEH
+CPsgw9gP/wXHNQ3cs/dyD13Y6Ybb3YBK86rf+a+EIbBcOIjIA++igfiO8bN94ub7xf3GPK5rbCC
N7q5qbgLSLsc+K5xT9aPuK+AQpgCU4EbiXs6ed+Ca+BavN51vGfCLeTfCnzfuPm+cXMTcZfxrqTt
AG++od2cfu4q3tXA/dodIh7mXQvcs9lFG92N9OluWApNpLHO3KwzN+vM3QqsLTfryb0KWE9u1pN7
DayFdcCOdW+AR2AjcA93cw93Pw7cxd3cxd0/gCfhKeBe7t4Ez9MXTkE3687NunNzV3e/SpyTz83J
5/5P2M74fgw74CfwU/gZfW6Hn+vb2PXb3G9wF96p7swb3buow8no3g1v0h4nIx5hG/fojW5ORDdz
7GaO3ew+vMRG9/v68axH9M+y6HMWfc6iz1n0NYu+Zj0Pr+rHPYNgBbC/POwvDzbwMH4P4/es1494
HgfG6WGcHup5GKOHMXo47T2MxcNYPHgoD3vGw57xsF88rDkPa87zG/I64C3g5PbsI+0IsO7xWhvx
Wts8nKA5V+pHcor0z3KuwotxI83hFppzE3G+d3P41s3hWzeHb90c1kIOayGHm2mOT3m8jTl+7uzc
SHMqibMuclgXOXewl4aq0+r/w0mlLRPL9Kn4swL8WQH+rEC0spfv0fPxZ9vxZ5vwY/PwY/PwYwX4
sSh+rAA/Nk+socxafRW+LIovm4cvm4cvm4cvm4cvKxGP8n6Mth/n/QR8H34AT8JT8DRsIv8ZeBae
o93NtPU8bCH8Q9gKL8A20n7E+0XeL8HL8Aq8Cv9B+mvwn+jcDj+mXzvgZ1i1nTH8nPfr8AbshF/A
LtJ/if7dvN8k/mvCv4V34F34HeyF39NuJ+/34Q/wR9gHH5C+H/4LDsBB0g7R1oe8P0L3x5wrh+EI
4U/gT9j0z/AX7HUUPoUu+v4ZHIPjcAL+Cn+Dv8NJ+BxO0eYX8A/4Jxh+dl6cny3hhNqEry3B187j
JJunPa5v056A78MP4El4Cp6GTfAMPAvPwWZ4HuTXxyHqMobur5DDenrsS0Q7xRfKF/pi7TTvL/XF
SUn6jKRksOr/h7Z7j4+rrvM/fjKFcotc2skcbrZGCrbEFmgpRKAWitIA5ZISCzQYKjQCA1Ik4RIk
LRDcVqQgQanieImXqJvf7s6uy8qOF7yku7KrzeKoyagjNqFMA9kRAWkR6Pk9Z3qKWVb35/7x++P1
+J5zvt9zZub7fX/en8/5huqyaf8ULZn2jSg97VH8M3L4Jr6Fb+M7eAzfxffw/ahx2g+izmmD2Ix/
wb/ih3gc/xbMkAtyckHjtB8bvwVD+A9Yp2nWSY5olCMap/3MsbWaNowR5wX3/wK/xK9QxK/xJKzT
pHzRK1/kps/gSUdFjclZUVquaJQnOuWItBzRKD/0yg9p+WGV/NAoN6STp+K0YEZykfadxi7G6TgD
S/Au19+Ns7A0mpdscu857j0X50X9ckZj8gLXLtTfjOW4yH0teI/nrsDFrl2CSx2vRKu+y3C5e9/n
3iuiJfJLY3K1Me14P65CJd+ktdf63tfp/wCuxxrf4wb33ej4JtxszC3VncXVyXWe1ePZd7vOB+Sb
RvmmUb5pTH7E9XvwUdyLja7dZ74+5lkPRTk5J538pO8nvuWWtNySllvScktabknLLenkV/BVfA1/
DfEt13TKNWm5Jp38O/dntX/vO/4Dvh5tSP4jHnH8T37HN/Ao/hk5930T38K38R3QlRyUloPSclBa
DkrLQWk5KC0HrZKDVslBq+SfXvknXc0/P/abt/gdQ3jC8U/0eZOQh9LyUFoOapSDGuWgRjmoUQ5q
lIMa5aC0/NMo/zTKP43yT6P80yj/NMo/nfJPp/yTln/S8k+j/NMo/zTKP52H/k00Tw5aJQetkoMa
5aBGOahRDmqUgxrloEY5qFcO6pWDeuWg3kOfkHN+5XoJfEEeSstDaXlolTzUKQc1HrYsmicP9cpD
vXJQ42ErVbGt2rYoLf+k5Z9O+Sct/6Tln7T8s+qwq6IlclCjHNQoBzUedn0wQx6q/LvcT0bF6o7p
w9Xav/gndk2L3KfIfYrcpyiiiiKqKKKKIqVIgUXKKlqVolUpvr6L9gOZfrD6XlCMd9OKZrvoFxXj
nayib/e74ECfXHnjGORHI3xohA+NqB3LaseX1I5lteNLPGmEJ414atlTy+4sq/IPil6sWYZ01Ftz
h1FPV/9SkJnSzCkrfx0ouVqqVvej1R1w74yO+/e8TXiDOEi9ugxiqPIOsOevJfHdlfsqR0/XVHZ7
aqp/76g8YXDPO0z1bMvrZ5URuz95tHrvgpqp0eaamdHzNW/R1uOtOAqzcDSOwdswG3NwLF9vwDr3
3KGOvlO71dOewja8hB3R6LSnos3TtuFplLAd43gGz2IC/4kyfhttTr4cPe/te7O3783evjd7++73
1r3ZW/fmugZ9b9cuwCl4Fz7i2j34KD7mfFP0fPC4X5Or2SfaXrMf9scBeBMOxME4BNMwHXUIcZhv
fHj0Qs0RVvBIxxy4ZoY3gpnV/bKcWcmZlZxZyZmVnFnJmZWcWcmZlZxZyZmVtWZlbc2JnncKTsUZ
OBPn4Fych/NxAS7EclyEFbgCq1FZl2txXXVn/4Wam3AzbnF+K7pwGz7k+92ObqzFOt+VAqzGRM1d
nnM3tlLsU9iGl7AjGrQqOauSsyo5q5KzKjmrkrMqOauSsyo5q5KzKjmrkpv2XLR92svR9un7RC9M
3w/740AcFG2ZfjAOqe7Oj04/3JgjcGS0PfkrbBcJz2onoheSL4qt32OH453RFis9kXxNXxRtr6vB
lChXNzV6oc5n1O0Ln1PncyghRwk5SlhblzTOWtX5HKrIUUWubobjo407BnMcN0QTVJKrm+t4vjf3
BY5P8oZ9itZ61C127V2O3+34LCzF2bA+ddanbhmsUZ21qWuGtal7D6xP3SW4FCvxXrThcqzC+2D9
6q6ENaxrx/txFa7GNbgea3ADPogb0QHrWWc96z6E29Htt6zFOtyBO3FXNFLXg7v1fxh/5Tesxwa/
x5u+KJgQBRN193reRv334X59HzPm4659Ag9hkzEPR9uDvRMPBi2JL0YdiUejQmIQw0EiSCTODxoS
y4OGmi8Fe0W/CFKcJFQnHqbePjz6UXBEdH9wpJr4zdGWYIb+mXgL6vFWHIVZOBrH4G0QHYHoCK70
rNVox/txFa727GuQxk2efzNuwa3o8jm34UO4HVQeUHmwDg9T8tTq38YGJ0VsRsQOxhH7l+5w50Rs
rvqX4GtxHf57lA2KskFRNijKBidHWYIvJWaiPsokeGRiXjQ3cUL04cSJjs8PFpvJxYnVjq/CNcZf
r70ZXcbfrr3fvPe550vR/YmvO/+24xHtzmjzlP3xJlnCc6dtiH4x7SO4Bx/FvdiI+3A/PoYH0IsH
8XV17z/iEfxvd8cPwsE4pLpTPk9kD06/Jeqf3uP4bqyPlkynuuk+a/rD+DQy6tW/1g4gp++b2u8Z
933tZvc8rt3ifEgbRYPJADVIYAr2UlPtjanYB3w/eSAOin6UPBiHRPcnp2G6mijJPeqQAh3KtYNy
7WDVbV7U/h478fJ/28nNvb6Du9slBjnE7p3ck+Ld3MXxjm4XboO1F5GDfyL6MqIvI/oG/0v0bXS+
O/IGK7vB1WhTSdS9LI/9Aa+4plKpey1qr9sVLa2LojWpICqmaqJcKhFtTsl9qb2wt2tTo/7UPlEm
tW80mNrP+f5Re+qAaGmq1j1vMuZA1w4y5mBYq9Q059ONSRpTZ0wq2pgK9R2Kw6Ke1OHRstQR0aLU
kdGm1JujVakZ+mfqewvqo3TqrcYcZcwsY46ODk8dY9zbjJtj3LG+RwPebtxc4+ZFS1LHRQtSxxs3
X/8CzzgRC/WfpP9kz2n0nHfoP0X/qfpOg3eT1Dv1L9Z/uv4z9C/xOWf6nLP8hqXGNOHsaCB1jjHn
GrPM9fOMOd99Fzi/0PVm7fJdP01d5HpLNCt1cfRI6hL3XYqVPq/V9cuMe69xbb7n5fpXuf8K7ZV+
x2q0G/d+464y7mpjrsG1+q/zjA/gev1r9N+g/4Oec6N+9UpKvZJSr6TUK6nn8Ds8jxfwIn6Pl7AD
4jj1Mv6AV/AqXsMuRNHmMEANrH1o7UNrH+4N9Vi4D/bFfuAFYSduiorhzVF/eEuUCW+NBsMu57dF
7eGHoqXh7dGasNuYta6tM+YO3GnMXc57jLnbmA8bsz7aGG5w/0dwT5QOPxr1hPdGS8KN0YLwvujw
8GP6H3BvLx7U/3H9n4iWhQ9Fi8JN+j8VPRI+7N5PI2PsZ6JN4Wf1f879n8cX9H/RvV/Cl/X36/+K
/q+6//FobjiEn0T3hzuwM7r/0CCae2gq2nzoqTgNF2NllDl0He7AhmizOnqw5gAZKSsb9cf/Bcio
bJSWjTbIRiOyUVY2yspGWdkoKxtlZaOsbJSVjbKyUVY2yspGvbJRb/Vvwld71jVI4ybPuxncX/YZ
lX02yD4bZJ8Nss8G2WdE9hmRfUYqf0/l/FnOn+X8w5w/y/n7OX+a82e5epar93P1NEfv595Z7p3l
3lnuneXeWe6d5d5Z7p3l3lnuneXeWe6d5d4buPcG7r2BA/fHf5cc4cD9HLifA2/gwCMcOMuBsxw4
y4F7OXCWA2c58AgHznLgDRw4y4H7OXCWA2+YXnmz3Iuz7g0Ow237J/2XB6PcdpTbprltmttu4LYj
3HaE245w2xFuludmJW5Wit3sMW7Wy816uFlr7GZ93CzLzbLcLMvN8tysyM2K3CzHzR7jZj3crJOb
tXKzLDfLc7MSNyvFbvYYN+vlZj3crJWbbeFmJW5W4mYbuVkvN+vhZiPcrJObbeFmJW5W4mYD3Gwj
N+vlZj3cbA43G+FmndxskJsVuVmRm/Vxs43crIebdXKzOdxsCzcrcbMSNxvgZhu5WS836+Fmc7jZ
Fm5W4mYlbjbAzTZys15u1sPN5nCzEW7Wyc1GuFmJm5W42SPcrJeb9XCzIjfr42YbuVkPN+vlZj2p
5ZzwIve0cMKLfcYl7rsUK31Gq/GXGfde49o40eXGrXL/FX7LlZ7nHZWb9XGzPm7Ww806Yzfbws1K
3KzEzQa4WR836+VmPdxsEUfJcpQ8RylylCJHyXGUxzhKD0fp5CitHCXLUfIcpcRRSrGjPMZRejlK
D0dp5SiDHKXIUYocpY+jbOQoPRylk6PM4ShbOEqJo5Q4ygBH2chRejlKD0eZw1EGOUqRoxQ5Sh9H
6eMoPRylM3aULRylxFFKHGWAo/RxlF6O0sNR+jlKP0dJc5R0WNmJCMRzTWIiWKyeXa7KXRE0VM8b
gocT85zfH01NPBjVqn4LiUeNGY7WJ0qOd7r+atQ2pTZaP+WYYHHy1uChup3BjLqXg5Pr/oBXg7l1
r2l3aSNrEARHpWqCw1J7BzNSU4OTU/tgv2Buan/tAdpaYw7Ud5DzgzHNtenapFZMpVLuD50fisNc
O1x7hPZIvNlzZ+if6dpb8FbXjtLO0h7t3mO0bzNmjjHHut6Aua7N0x6nPd6Y+foWOD8RJ7l2srZR
+w59p+g71flpeKdri7Wna8/Qt0R7pmefZcxS15twtmvnaM/VLsN5+s/XXoALXW/WLnfvRdoWfRe7
9xLXL0Wra5dp36ttM+Zy7SpjrjDmStdX4/2uXaW9WnuNMdfqu875B7DGtRu0H9TeGI2ENwUzwpuD
k8Nb0BXMDW/Tfkh7u761+tY5vwN3udajvVv7YX3rg6PCDc4/go+6dq92o/Y+fR/T94DzXnzctU9o
H9Ju0vcpfQ87/zQ+49pntZ/Tfl7fF/R90fmX0O/aV7RfDeYGn0zcv+s5KltIYQ2JH8gIw45LlLZb
ZfUUVv8nFDZ/ksLyf4HC8m9Q2PxJCstT2Oz/h8Jm/xmF5f8CheUpbPafUViewmb/GYXlJyls9v9S
YflJCpv9ZxSW/wsUlqew2X9GYfn/QWH5Nyhs/iSF5f8HheUpbPafUVj+f1BYnsJm/0mF1VDSkmBD
op6jzaOvBznZo0Ft4tUgpK2WaqZ+RXZ+VfvHDJ2WoUeq7xtTZYV9sK/zP2bjnmomPkT2nab9YwZO
y8D5+D1icuZtl3nzMm42fn/Yk3Fnxhm3XcZ9XMYtybglGbdfxu2clHEPlnHzMm02fm/Yk2lnyrR5
GTYbvy/sybAz4wzbLsPmZdaeSZl1RGZtj98TJmfWmXFmbZdZ8zJqVkbtmZRRZ8YZdY2M+riMWpJR
SzJqv4zaMymjzpRR8zJpVibtmZRJZ8qgJRm0JIOOTMqePdXMeadseZf2jxkzLWM+LmOWZMySjNkv
Y3ZOypgHy5h5mTIb1957MuVMmfJxmbIkU5Zkyn6ZsmdSppwpU+ZlyKwM2bMnQwZfrtao86Jl6tNc
4uZoq/z3S9r52ZRjoq1UMqCe61HPpaklQy191NJILXOopZFaHqGWHjXcIxTTSTFpismo4fqoppFq
5lBNI9UMqN961G9p6slQTx/1LKWeOdTTSD2t6rdm9VszFS1JHb5rR+oIHOn6m42ZoZ2p7y2oj+ZR
05LUUfpn4ehdBWpqpaY51LSMmpZS01JqmkdNS1LzjDlu1/bU8cbNN26BZ5yIhfpP0n+y/ka8Q/8p
+k/VdxoW6X+n/sX6TscZ+pfoP9PnnBV1qd+a1W/NVNZKZVNT5/qMZa6f557zcYHzC9HsvuW77qOy
JakWxxerzS4xD5e6byVVtVLeZdTzXmpv85zL9a/Sd4X2Su1qn9Fu3PuNu8q4q6MaaptKbRvVb2n1
WyvVraG6dqqbSXUHU91UtdsjlNdJeWnKy6jd+qivkfrmUF8j9Q2o23rUbWkqzFBhHxU2UuEcKmyk
wmVUuJQKl1LhPCpcEt67a0e4cdf28L5dBSpsVbc1q9uaqXEeNS4JP6H/IWzS/yl13MPGfFp/xpvl
Z7xlfpYKPxfVUONUatyobkur21qpcg1VtlPlTKo8OGilypcocogaK3sklbeJPPWNUl6R8roor0R5
2ao/7Vf1qFFqy1f3Pw6sviXkqWyUwooU1kVVRb5UpKYsBeUpqMiLiryoi3Ky1DJCLXneM8p78rxn
DYXkKaTIc4o8p4si8hRR5DVFXtNFCVmrX+Qvlao9a9WLvKXIV4p8pYunZK1w3goXrW7R6nZZ2azV
HLGaeas5ajXzVnONFcxbwaLVK1q9rqpXdFX9YtSK5avv72urFXbeSo1apaJV6rIyI1Ymzx9G+UOe
P6yxGnmrUeQLRb7QZfZHzH7e7I+a/bzZX2PG82a8aLaLwRfMdmV3csiMrzPjm834I+J+QNwPTIr7
tNlvjeP+MbPfFcf9gLjvmxT3rVZiWRz3j4j7AXE/MCnu01alNY77yi7UgLgfsELtskezVVoS70It
i3ehBsT9gFVbY9XaZZFmK7fEyk2Nd6GWxbtQfeK+z0quspLtVnJpvAs1Nd6FGhD3A1Z1jVVtl02a
rewSKzs13oUaEPcDVnmNVW6XVZqt9BIrPTXehVom7gfE/YC4H7DyXeK+2eovEfcDcXZpp4Alsksz
FSwR9wVxv5ES5oj7AXE/IO4HqKKHKrrEfStlLIuzzAB1tIv7PnHfJ+77KKWHUroopZlSllDKweJ+
QNwPiPsBqumhmi5x30o5y6rZZnfcD4j7vklx30pFy+K4f0TcD4j7gUlxn6ao1jjuKztAfeK+j7pW
UVc7dS2Nd4CmxjtAA+J+gNLWUFq7LNRMbUuobaq47xP3feK+j/J6KK+L8popbwnlHSzuB8T9gLgf
oMIeKuwS962UuCz4Wk062lLZP6fIJ+L98t174zdTZ1d192S4uv99TDRU9YWXo2y8d7qFSktUuoZK
myd5xCCVlibtl26h0lK8X9pMpV1VvzhIXO7eK91CpSUqXUOlzVXvSFn9P+6VbnzDXmmaSjdN2ivt
jHcX9uyVzopVmn7DXml7vLuwiErnUeksKt00aa+0M95d2LNXOotKN03aK+2Mdxf27JXOilWafsNe
6SOT9kq3TNpdmLxX+ut4r3TmG/ZKN8W7CyvivdLK7sJj8e7C5L3STfHuQmWvdBGVLnrDXummeHdh
RbxXuohKS5P2KrdQaSneq2ym0q6q161Tq+zep9xCpSUqXUOlzVXf+6/7lO3xrsIiKp1HpbOodNOk
fcrOeFdhzz7lrDfsU26KdxUq+5SLqHTRG/YpN8W7Cisq+5RVv6zUTLnYL/vjXfwJSpyI970ej6vq
tZTYHu97DcR7XaOUOBrv3D8+qbpuj3ftJyhxIt7nejyustdSYnu8zzVBiROUuCmutte+YZ9rghIn
4n2uTXHVvZYSF7xhn2uUEkf/xD7Xgnifa4ISJ+J9rk1x9b2WEhfE+1wTlDgR73NtiqvwtZS4YNI+
V5ESJyhxghIfi6vxtfE+1wAlbqLEtXE1vlbWrIur8TQljlDiBCVOxPtcA3FVvnbSPtcmStxCiaOU
OEqJA2/Y56oocYQSJyhxIt7nGoir87WxEit7XKOUOBrvmj8+qUpvj3fMJyhxIt7fejyu1tdSYnu8
vzVKiaN/Yn9rQby/NUGJE/H+1qa4al9LiQsocQsljlLiKCUOvGF/q6LEEUqcoMSJeH9rIK7e1wb7
1hwUzK/8m03vdqcmng1OSEwEp06pD06o+9vgoUP/PlgdHD1pxAnVnleC1XVRMD+1b7A6Vas9RFun
rdcerX279njtQu07tIu0Z2iXY6XjNm279hrt9dobveXeGqwOb9feqf2w9h7tfdoHtZu0Ge3ntV/W
fi2YH7wrcWTUlpiJY3AiVuMqXI/bcT8eDcLED6NC4gn8tPI3aLngae32qJwYj8qpRNSWmoK98CZM
4D9Rxm/xHH6H5/ECXsTv8RJ2YCdexh/wCl7Fa9iFKGoLA9TA54Q+J/Q54d6Yin2wL/bD/uhEd9R2
6CFR4dBpmB2VDz0eJziej0V4J86MCodvg99xeAnb8UxUCOpqno6GK//WueZZWW5uUM9f1ieO92tP
CBoS8x2f7te/O9qZONusnCsbLo/6Eyu0F5uNm4zhpolb9XU5vm33v5kOTqvZGhVqnoLPrHkJOzzx
yGibud/GxZ43/9t80vOJ4zz5hGjcWmxLnOp4hXGrnV+F69ElB98ejdf9Jtpp3reZ923mfZt535Z6
j2srMBGNm/9x8z9u/sfN/7j5Hzf/4+Z/3PyPm/9x8z9u/sfN/7j5Hzf/4+Z/3PyPm/9x8z9u/sfN
/7j5Hzf/4+Z/3PyPm/9x8z9u/sfN/7j5Hzf/4+Z/m/nfVnOAX7zQL17oFy+seTZYXPPboKXmBbzk
fAd2RutrXnb+qva1oCURBle/rsb6oDZxlPmsqPJY7TxzeRyON88LnFeUeqrzRdbjDNeWRA8kmszU
OdZsmTU7z/XzjbtAe2HUkWjWXmR8i/YSXIqV7nmvz2zD5c5X6X8frsCVzldHtWa9NnGN73atHHO9
4xsr7+bB4sQtrt3qO3zIuNtdv9P1u1zrwd3R+imnBlfX/TIq1xXxm6Chblu0vm48ytU9gwmUg5Y6
81H3XNDy36LnPUFDagXeJ7LS6IjWpzpxE27GLbgVXbgNvkPqdnRjLdbhDtyJu9AD3yn1YfwV1mMD
PoJ78FHcGz2Q2oj7cD8+hgdUYr3aB/F/gqtTfxOclfpb7d8hG8xO/X1wfeofHH89uDD1j3jE8Tfw
KC/6Z22OL33Ts7+Fb+M7eAzfxffwffwAg9js9/4L/hU/xOP4N/w7foQfYwuG8B94Aj9BHj/Fzzzj
5xjGCAr4BX6JX6GIX+NJ/AZbMYoxPAXrk3oaJWzHOJ7Bs5iIakVTrWiqFU21oqlWNNWKplrRVCua
akVTrWiqFU21oqlWNNWKplrRVCuaakVTrWiqFU21oqlWNNWKplrRVCuaakVTrWiqFU21oqlWNNWK
ptrwJF7dGMwO34FFwWnh6VEuPANLcCbehXfjLCzFOUFLeC6W4TycjwtwIZqxHBehBe/BClwcrQ/F
RCgmwpVoxWV4L9ogNsJVeB+ugNgIV6Md78dVuBrXII1rcR0+gOuxBjfgg7gR9LzHpcNPRuWwLyoH
U0R4Ld/byT1LQcgXunlCNw94Uvw/KU5bxGmL3py4elJcPUmTLTTZQpMtNNlCky002UKTLTTZQpMt
NNlCky002UKTLTTZEuxbrRrnVt+0x3zmzxJnc45rOPZNHOPmoDZ4pmYrXxrFGJ7CNsT/GxQ1Lzne
gZ3yxB+iTM0r0VYeNlyzy3EUbU0k+NGU6KbEXtq9tVO1+2jrfcJRcsOx2J1XXuJn/fJKPR8bk1dy
vKySW8YSS32Tip+dre8c7XlRno8N8bHN8k0mcZGxLdWc08/PCvxsLHGZe/bM0+XGrzLmfbgCVxrT
HsxJXI00rnXvddoPYA1uwI2udWg7cZPvWs1jlf8KqprH1ie6XV+HO3Cnt77WYI616LcW/fwtz9+G
+NsQfxuq+52+F7EjmMO/xvjXGP8a419j/GuMf43xrzH+Nca/xvjXGP8a419j/GuMf43xrzH+Nca/
xvjXGP8a419j/GuMf43xrzH+Nca/xlIDfPIv1cM/GfsGTfCpPJ/K86k8n8rzqTyfyvOpPJ/KpzZH
udS/4F/xQzyOf8O/40f4MbZgCP+BJ/AT5PFT/Cwq8KcCfyrwpwJ/KvCnAn8q8KcCfyrwpwJ/KvCn
An8q8KcCfyrwpwJ/KvCnAn8q8KcCfyrwpwJ/KoQHBHPCWrwJB+IgHIxDMA3TkUQdUghxKA7D4TgC
R+LNmIGZeAvq8VYchVk4GsfgbZiNOTgWDXg75mIejsPxOAHzsQAnYiFOwsloxDtwCk7FaViEd2Ix
To+G+NwQnxvic0N8bojPDfG5IT43FDYZc3YwJ1igytiqytiqytiqstiqstiqiiioIgqqB1Vb9KJq
oVJDlWTzkixekrFLsm5B1i3IugVZt8DlS1y+xOVLXL7E5UtcvsTlS1y+xOVLXL7E5UtcvsTlS1y+
xOVLXL7E5UtcvsTlS1y+xOVLXL7E5UtcvsTlS1y+xOVLXL7E5UtcvsTlS9ywwA0LQSI4INifG40F
+1T+Nanv/hxH6HclK/r7RX8l6rPB1MQc8VmpSc8W88v1VqrEDwb1NReZjyNqRqOhmjE85Xgbno7m
Vv73alRgDSqwBvN0hHk6goMtq3m56mJDHGxZzWtVFxviYHM5WI6DzeVgOQ42l4PlVGjdr1doR3Gc
3dXZGO+uj6uzSpUcTqrOOnz/rOoskzjTN32XvqUcZU+ldl60MnG+axfovxDNri13fhFanF+CSz1j
pbbVtcvc+0eHW6liC1VsoYot5HAZa9yUaPf9r9JerU3jWvN2nfYDuN71NdobcKPrHdpO3Oy73gJV
Fberp4+mRLfr63AH7jT2Lv09QYPKrruulcP9MhrjfGNxdbeS+/Vzv37u16+6a1DdNajuGup+Z+yL
2BEN/dlKryPq4JAdHLKDQ3ZwyA4O2cEhOzhkB4fs4JAdHLKDQ3ZwyA4O2cEhOzhkB4fs4JAdHLKD
Q3ZwyA4O2cEhOzhkB4fsUOFlVHgZFV5GhZdR4WVUeIMqvIwKL5P6eBCmPoGHsAmfxKfwMD6NDD6D
z+Jz+Dz68AV8EV/Cl9GPr+Cr+Br+GgPR5tid5+9252gkriBXx+58Fnc+K3bnzbE7r47duVJFruTO
K7nzSu68kjuv5M4Z7rySO69URWZUkRlVZKiKDFWRoSoyVEWGqshQFRmqIkNVZKiKDFWRoSoyVEWG
qshQFRmqIkMuneHSGS6d4dIZLp3h0hkuneHSGS6d4dIZLp3h0hkuneHSGS6d4dIZLp3h0hkuneHS
GS6d4dIZLp3hL038pYm/NPGXJv7SxF+a+EsTf2niL038pYm/NPGXJv7SxF+a+EsTf2niL038pYm/
NPGXJv7SxF+a+EsTf2niL038pYm/NPGXJv7SxF+a+EtTeADHrMWbcCAOwsE4BNMwHUnUIYUQh+Iw
HI4jcCTejBmYibegHm/FUZiFo3EM3obZmINj0YC3Yy7m4Th4kwtPwHwswIlYiErFe7K2UfsOnOL4
VJyGRc7fqV2M06N+GaJfhuiXIfpliH4Zol+G6Jch+sMmY87GOUGDirhBRdygIm5QETeoiBtUxA0q
4gYVcYOKuEFF3KAiblARN+ypToM5NRPRQu5W8doHqk52Judq0p7Dbc6vutY5XOscHryeY53Dh9er
ybKVd0PR2yti0yI2LWLTorJXJKZFYFb0ZUXfFhFxmmgYFQ0XioZ7U//geM/71Dcc746CGdUo+G6U
lU/nx+8Ep5md08zIhdW9hVpeX8vra3l7LW+v5dNDfHpIrVvJg0Pq3X4VZyFxnF9ygmPznTjV8dmO
V/P2q6pvuDnel6v7jTc+VSyvGuJVQ7xqKPUe11bA2ysd5+g4R8c5Os7RcY6Oc3Sco+McHefoOEfH
OTrO0XGOjnN0nKPjHB3n6DhHxzk6ztFxjo5zdJyj4xwd5+g4R8c5Os7RcY6Oc9ZlKKz8r+b8PK7P
G9TnDZPq8+r/3tmk+nxIZlunPq9ktyGZbZ36vJLdcrLbOtktJ7utk91ystu6xJGcfyaOip5IHKM9
Vlut06uZLZs40XEle53n7aGy53OR2bwYu7NSm6zUJisNq7sL6u6CulvVESxUdycTV2mv1qZxrTHX
aT+A611fo70BN7reoe3E6/tIsubtxnS7tg534M5oWO2dlIGekIGekH2GZZ9h2WdY9hlWeyfV3km1
dzKVCOpTU7AX3oTdTtxGd22cuE2d3EZ7bbTXxonbaK+N9to4cVvsxG002EaDbTTYxomHOfEwJx7m
xMOceJguhznxMCceVicX1MkFdXJBnVxQJxfUyQV1ckGdXFAnF9TJBXVyQZ1cUCcX1MkFdXJBnawK
Cxam/hNl/BbP4Xd4Hi/gRfweL2EHduJl/AGv4FW8hl2IgoVhgBokMAV7YW9MxT7YF/thfxwQJNXR
SXV0Uh2dVEcn1dFJdXRSHZ1URyfV0Ul1dFIdnVRHJ9XRSXV0Uh2dVEcn1dFJdXRSHZ1URyfV0Ul1
dFIdnVRHJ9XRSXV0Uh2dVEcn1dFJdXRSHZ1URyfV0Ul1dFIdnVRHJ9XRSXV0Utwn1dFJdXRSHZ3k
AUl1dJIPJPlAUh2dVEcn1dFJnpBURyfV0UkuOcwlh7nkMJcc5pLDXHKYSw5zyWF1dFIdnQw7g/qw
O6gPbuMbHXyjg2d08IgONVymWoOeF3Vzu/Xc7gFO16E261abZSi+W+3VzUMW8pCFPGQhD1lIld08
pIOHdPCQDh7Soc7JqHMy6pyMOiejzsmoczKcMqPOyahzMuqcDNfMcM0M18yoczLqnIw6J6POyahz
MuqcjDonw1Ez6pyMOiejzslw1ww1z6fmW1+vKR5VZ+Q46Dd9n2/h2/gOHsN38T18Hz/DzzGMERTw
C/wSv0IRv8aT+A22YhRjeAqV3/s0StiOcTyDZyGL8Eyqxm/xHH6H5/ECXsTv8RJ2YCdexh/wCl7F
a9iFKKJq1CCBKdgLe2Mq9sG+2A/74yRZ4o/ZYj4P7eChHcEhqX3lmENQj7djIeST1Eq04/rgwvBW
3Il78CAy+HwwI/yy9mvBjMp/ucvlVnhjmUol5eq/S7vAleW85gfiedBbzV6J070jnF99UylXdsqD
a6mq7OpQ9Z5zq55apq4x6nIvP77IeQsq/nqJ9tLq3kY3j+2muDKPLfPYMo8tU1+Z2ir7pGXqKlNX
mbrK1FWmrjJ1lamrTF1l6ipTV5m6ytRVpq4ydZWpq0xdZeoqU1eZusrUVaauMnWVqatMXZU9hm7e
2c07u3lnN7V1U1s37+ymuG6K6+ad3Xyzm/K6+WY39XVTX5n6ytRXpr4y9ZWpr0x9Zeor880y3yzz
zTLfLPPNMt8s880y3yzzzTLfLPPNMt8s880y3yzzzTLfLFNvmXrL1Fum3jL1lqm3TL1l6i1Tb5l6
y9Rbpt4y9Zapt0y9Zeotpyrz9zRK2I7KX3WewbNROahJnB0sDJbJud1ybrec2y3ndsu53TVP4yXs
sC6LgtrEGTg7WJxQaSVUWInmyp47LsGl+i6v7K1X3pgqbz1BbaoTN+Fm3IJb0YXb8CHcjm6sxTrc
gTtxF3pwNz6Mv8J6bMBHcA8+im/6nG/h2/gOHsN38T18v7JvjJ9jGCMo4Bf4JX6FIn6NJ+FNL7UV
6o6UuiP1FCq/42mUsB3jeAbPBg3B3pV5o+7c62/oF4uTpeYpVHXlEsvMx3lqigu0F7rWXHnrdb57
rkJzVR/PVb25Cs1VaK5CcxWaq9BcheYqNFehuQrNVWiuQnMVmqvQXIXmKjRXobkKzVVorkJzFZqr
0FyF5io0V6G5Cs1VvbmqN1f15qreXNWbq3pzVW+uxLP5HMT/zzlLcIWKn2wOpiROp6PK7sDyyv9v
TNVjKtcaEue6tkKu2tvZQg6y05WG6r7BinhkZT/ZfE9ZiJM40Hv4zU4jC4n/y925QEdVnX1/n30y
iCGAZs7hnARFQOVitGpsEHUUL7xjxduoeOkIvF7GiqiRimisjpfYNr4Wa7GaegltvNEKCFGx1aBY
hUiQy3ARMYhFHCEgwyEEjCMFzvfbeyZhgLTvevt97+pa32L92XvOOXPOs5/L/3mePUnmXPhC7aZc
gW6v4t0ZbknLqOIUjl0PblB613yShk/S8EkaPknDJ2n4JA2fpOGTNHyShk/S8EkaPknDJ2n4JA2f
pOGTNHyShk/S8EkaPknDJ2n4JA2fpOGTNHySpiv36Mo9egKPrtyjL/DoCzy6co+uHF5A7x+BBaAR
LAQfg0VgMVgCloIEWAaWgxVgJfgE/C/zgl+n9d2kOWKk6EoNnjCwp7zFb8vWsJOz+8f16m8p0FHx
BHoVj17Fo1fx6FU8ageP2sGjdvDkvWQBxdIpsBV4YBtoAdtBK9gBdoJvAfcgZ3rkTI+c6ZEzPXKm
R870yJkeOdMjZ3rkTI+c6ZEzPXKmR870yJkeOdMjZ3rkTI+c6ZEzPXGz/uyyY/8/+xnmNnhuh+K7
9s8vOac/vwSZzy9VFRRnJXF5C2suZ9y3s9Qk7wP3cyy7kyR/jneq3aSc3SJWHWfVcVYdZ9VxVh1n
1XFWHWfVcVYdZ9VxVh1n1XFWHWfVcVYdZ9VxVh1n1XFWHWfVcVYdZ9VxVh1n1XFWHWfVcVYdZ9Vx
Vh1n1XFWHf+XOmXys3MN+DGIgmvBKDAajAH/CeiHHPohh37IuRHEwE3gJ+BmMBbcAsaBW8Ft4HZQ
Du4A48FPwZ1ggtol1VrFq/Rn9eu1DZT+pb+enm49/dx6eqwk/VRS/xz1w36S/ihJf5SkP0pSEyep
iZPUxElq4iQ1cZKaOElNnKQmTlKv3OI3y4lY627Ge/1Fymtzc54/1fA4tk2cbLQIy2hlvoM5PVd7
LqT3nErPORWZJiPTZGSajH9Y2i9upa+8E0yEf5Rf3IvsP+P4w/5ys0ycbA4B1PJmRAxG7uXIvRy5
lyP3cuRejtzLkXs5ci9H7uXIvRy5l4tBeG0Kb03hrSm8NIWXpg7a9/437nPDEuR68UPdFauO+FYV
JYw/ZbxTRUnGrrrjfZiIgElsMoOdUpHxb+wMyTrOOeBccB4YDv4DhMH5+GEUzZ+wbz+C+Qaw0W/I
+ZmHE7DGCfjF+uzPPKzP+mxCf06oPiPM8EcMa8XwEfVXCGL4SWo/DtHa4bj6qwa5O9Kb/RR+ksJP
UgfwSQxrx7B2DGvHsHYMa8ewdgxrx7B2DGvHsHYMa8ewdgxrx7B2DGvHsHYMa8ewdgxrx7B2DGvH
sHYMa8ewdgxrx7B2DGvHsHYMa8ewdgx/TeGvKfw1hb+m8NcU/prCX1P4a+pf4RthGil6zru1NurE
Wei9Bn3XoO8adFyDjms6son6RFdlFPWp7j1Kd2ovBVQyf8Rvsj2wDbToT3/+bdnGGQGvXQguAheD
SwA9lBMB9EMOHZZzBRgJrgQq354NI43N2QEbCzON1TtgW5S3Mf9OjMW76vCuOryrjpgrIeYU+ywi
5og3xonqE3WtS7XLpBhoEZ60CE9ahCct6qXibivAo4i5kl7Ko7aDVrAD7ATfgjbwHUiD78Eu8Hew
G+wBe4GPBQUwgAQmyAMB0AUcArqCQ0E+ONtfhPcswnsW4T2L8J5FeM8ivGcR3rNI3IMGSnI0UIIG
Sjp+dsvzLzK2+ecarYw7GJEQjZQQf8nsp13J7Cddq7OfdK3OftK1OvNJl3+d/C0aeZps8xyY4q+T
teAFv0q+RL861R8jX0Wrr4M3OP4meeZtv0XO4dr3uGaBGCEbeb0QH1wKljP/BHzqz5AbGTeBzWAb
51r9GWYXv9U8FOT7U83ejAMYy/xzqV7PNc/wr1M/Q+bMF9JZ6Fc5S/x1ToJxJcc+8cc4q8Aazq0F
65g3M6a4ZivwwA6O7eGY769zhV/lSiHdrsJxD/db3EJwJPOjwCDmJYwnMZ4MSsEP/RluGRgCzuT1
WeAcrjmPMcx4pd/qXu1Pde9inAjuBlXgUX9q8af+uuLV4DPQBD4HG/yWYtZf3AzQQfE3YKffWvwt
aAPfge/9VnG8nEIVXgteQkNTGd8AVLPyC1Fg4i8mfmIWgJ6gN/5CJexQ8TqrwDqQAluBB3YAX/Rz
u4sCN+h7rgOGA1jFHQVGA2LDvQtQtbrEhHsfqBIlxZ+KfsWrwWegCXwO8Pti/L4YryrGq4q/153L
E/4GmfY3i6D+mUn1O6Uv4U0z8bK3qUTU75Yu4NhK5qupBqi25Vf6N5prJDErt/kjZAt32e1XmQV+
nelQHQ7Q932bs+q3pLtw31a8sp/+bWi6JbMvVcIA8up/dhoLWZ+XT6DB34KnwXNgCvxXC9TvVb+s
tevImeCN7O9Zz2G+gJ6UXgPf7YfPNsnPOLaGekZLyj1bObabY3uFg+96+K6H1E1YwzEdZRFel4l8
apl8/NbBZ5ucFYyfgFVgDVgL1oFmkOL8VgAnYy3H+Q6kwR7g+034rIPP9nN7Mbr4WxE4ktdHgf7M
Sxh/yHV0fPhqk3sqx87g2hA4h3NhcJH2Vw+LO1jccW8AN4M7wF0cJ0/gvx6Wd/BhD/9twn+b8N8m
/LcJ/23CVz181cNXPXzVw1c9MQSNJtBoAnZQWk3CDh7s4MEOHlpNwAhN+KzEZ6WZDwpAT1AIikFv
MEBHdxOaShDdTUS3R3R7RLdHVHtoKIGGEmgoQUR7aCVBNDe5lxHNV4KrwbVgFBgNbgZ3gYngbnAf
qAKPCsnKEqwswcoSrCzByhL4tMSnJT4t8WmJT0t8QHHgS6xgJqP6rdX5zJVvrGaVW+C4bfToVFbY
3lN2F4eo31rC92vkm8pzWT/1Iz5dz/oKxBhj/d7dxtdgA9gIT7cxfgfSfj2cXA8fN8DFDfCw+qtL
P+VOYzQHVyvfJXqmMK8FLwLFDC/DoW9knzSH83OZzyPqFvgT9E8sL/XH5vzUcpP+qeVmomgT42aw
jfun/Ufw4RQ+nMJvU5pnG5TPMq7wWzLc6pdpXt3E8c3KX5lvBR6Awx0i19kOWsF3vCcN9vAeH41L
v6zjp5GP8sfCs01wbNNBP5F8DufOYwwzXumn8MkUPpnCJ1P4YwomkjCRhIkkTCRhItnZTzDjoyl8
NIWPpvDRFD6aEgGtrTf9nSqCO3ijV/tPhmQZa4L23pnoXulzHjlwAay00p+L7ibAWEkYazL6e5C7
DEZ3IzVjpf0fmUdg4SP9BHcebPbzV4lC7gjrgMydyriT5E413GkEd+nHXYZxlzK5bW9atvD03b6D
TE3FCX9c8d/8ocVf+jXFW/2hIkyNN4wabxg13jBqvGHUeMO4ew13HyufxmeqVY6mr36B+YscfxkZ
X2X+OnizwzfiRGG9nMv5ebxW/rEN9t0NK8NhkurENGHdfPirm45Mh8h0zGM4NoBxIHad79fjFypK
64nQenxjMlFa76wBa+mfmxk3cX6z9gnptPg1znbQCr7j2jSgNydq6/GJuOYj6l4i2CF6HaI3w0kx
v05z0njO0Rm5FfjQveBn4Bece5Rzj1H9FqifFmr/1JNIHaErkzfJQipSV9IhNIMtYljW3lNFfjae
Pf0T/QsAFZ6uQXaTIdtE1D1dhN0HRFSY+EuGp9Rf5FmIvvvJ33DdZPCkyidY9CnG34FnwLMqPvd6
8nnGGp1jquTvGf8Aapm/wHNe1M+eIF/h2B/Bn8CreMA0xungNZWHOD+LsQ68zrk3eO9bzP8M/gKU
3PVgDs96l/E97jkXvM98Hp7VgCd9BBbsbZKNe5NyEfPFYAlY6hfIBOMysJxzKxhXgk+YU0Ppv/zw
Gc9rYr6Ge33OuBZ8Af4GqK2IgTFyPfgKJMHXYCPvb0Y/m/CxzWALlfdWjntgG3K2cN8d2sMlPubs
lwm64V8FfpkJN5Dxx5jFjCobHKOigXEgNR5rcz4A88BHALs5C6l4PmZcBBbr/FrlJDi2km71U143
gc9Vjt3rOV8w/g18Cb4G34AtOudWkVGqyChV8FcJ/FUCf5U4Ozn3rcq9vHevzr9VLpW7K/d6rumP
cQ8B+aAb6A56gJ7gMPVbF3uTbiEIMu/F+1gT+XoE+XqE24f5UX6B25exH+jPsUHEwQ+YnwhOYn4y
7y0Fp3JuKMdOA6f7Ne4Z3CsEzuTcWeAc7nMu585jPpwxzGt6pX2ZkHnMd/bLgHSM7r3gZ+AXnMtm
Q2LJISNWkRGryIhVZMQqMmJV8Ya9yWJsW9wMNoFvQCdZsjdx3Ptif4y4SldZz1ExtWepF2CoF8mY
xBI1gWKlCbDShH0Zi2vf45q5XLMKdiUvU1kliEY8BXR4Cl7RTcdjgdmTTFvop/GUdMZTdIw2aYZa
6I/VWSvBuNKfQP0wmfphMpUWNTFjbtZqoY7YDlp1PQEz6RpZwk5jqbb6YcEk1ktSVSWoqhJUVQk0
nUTL6YyW0fC1zEdRMY0GMVVzMO6n8Rzmuo9zv2ivQXjvY6oO6SSjdVaHHGvQWRp0kx2aVRpVWlwF
vtDVcEGHtgoyFZXWRO6K1eq6gyBwwPBs5ZQrcdX/QKqTyExJMlOSzJSEg9XPnybJTknY0oMBkzBf
Eh9o1ln1ZcapuspOYvNmbL0aW6/GtqvN7lQeA/zV2K+ZSE5iv2ayS3NHtbxOR2uSaE0SrclMhcx5
aiuiM4nNmrHTauy0Gjutxjar3ShVw4PgIfCovxoPT+LhSTw8iYcn8fCkuFp3FI1+GzVSGzVSm5Zq
I+MmsBkgofxeWHIX+DvYQyYRwAAS5IEAUP3rIYxdQaaPbTZ7MD8MHA6CwAK9gAuKgOpz+zAeBVSG
Ohocm6lMqJfaqJfa4Ic2eKGNWqmNWqltv1WeyeuzwHngfGG5F4ALwSXgUnA5uAKMBJk+tdkdw/x6
cCO4CfwE3AbuBBNAbh97P6/j4Jcg09M2U2+1UW+1UW+1UW+1UW+1dda/9kYGYeMfDfhHA/7RgG80
4Buqql1F9kxQsdRlui3GTEWSJEOpijQhVfW4FubfA1NJcJSuDlVl2ETd9VvyomKZF6hlXiLTZ5hl
MswyOdu/KVapgUWoaUC+7s08mCMJc3gwhwdrlKBnD4+rwdtqYIvJB7FFlhXwrhrNCJcRwVeDa1UP
hdeNBjHVOTPeB37B/FHOPaa6VsXaqoYT3VhZA71kNlY531XFIWN7HB4JSjLxyNXqqjWZqN4vWl1Q
BPqDU7NXB+Q8rlygq0pqU+bb/MkiKH5D3bMUtliDdlJoY5voZ53up6wIeAm8DF4BU4kNVxRw3wI6
yRLuXcC9C6iCInSNJXSNJSLP2KhrpX48w+NOBfpIga6eMkdUj56RIyHy+H+q+hu9VAhNWpqu+jMK
1TfPw/ILsJF6V7O/WZ2V23UVTgY2ttENtTLuUP6g71YvF3LlKtV9gy+wXplfZQ4hC3ZFe919lWWb
yLJN8HSTeyTHSsAZzENgOL7SRf8U+Tx00y6tqgip97h/iiqSdQpD/0Xhwfv9tl72E66sX8ZhiDp8
Mw5L1MESddjI0d0UlQXrrJfqKdnfBVX7EqqyxnZqh6mOKK7Dhg42dPDjeM7vY9YR0XVEcR1RXId/
x4nkOuzq4OdxIq2OSKsj0uqItLpi9f0XDpqqQ1NNaKoOTTVpTanM+RlPXqN2h5incjSV0VISLXk6
m7mMRaA/OFVry0NbajcoKX5AhSupcCUVrqS6lVS3kupWUt1KKltJZSupaiVVraSKlVSxkipWUsFK
KlhJBSupXiXVq6RqlVStkqpVUrFKqlVJlSodhQ8AklPNSao5SSUnqeQklZykepNUb5LqTVK5SSo3
SeUmqdwklZukcpNUaJIKTVKdqepDikPh7VZ00AJft7JWtW/XCk+2wpOtrLGFNapObQO2ocoTXbi+
GT15XK8yRzPXNnNtsxigP8H1/MloeaLRwrhd++VktD3R2Mn4La/TmZ+o3P/TC/9cskAz7N8M40yG
3ZvpClvpBnfCNJNzdjPPVZ8Ew8jNsMlkGLcZxm2GcZth2WYYZDKM2gyjNsOozTBqM4zaLIL75fee
mRyv8/d/s+PRae4OwLGeqbwjCh4ED+lP/nb7Ndm9DF1/C4NuqEL/Da9WeiL1N7sK8C610yH1dQP0
zxrQPbW/i1dpfyX3adAdtnrnRP13/dVfi46hkVR2j2+AKBN9ibo6oq6OqKsj6uqIujq1W0JPinJ5
mqn/wrRHn5DD3freHr1Bkh5S0kM6+3HzDRyL+Q30kJIe0qGHdKh9k9S+SWpfeJpzmqf9BuRD9o5O
r0H017KZfhxbJrBlgi5lGLWn2uFJ0BUP0/uSxYy9eX0M1w1gPlCU0cUOw6YJqu9hdLLDkCCObRPY
NoFtE9SCZdSCZdSCZUgQx9YJqu9hSBHH3gnsncDeCeydwN4JMSBbBef0S/5U9OBl7I8OCkExyFTB
jt4zH8i6LmN9mQp1KvpoIFc1kKsayFUOuarhgJ7AQy8eevHIYQ3ksGxfwHsfE06nvnMY1egIqtER
SFaAZAW6Lu9N3rgS3AUmgrtBlSjgDgXcoYA7FHCHAu5QoL1vA+vZgMwbkHMDz9ugfSVFjaW8Sa07
P+uLPbFIIfNikFlnDWus4X01rK+G9VWxvqrs+qpYR5Vex6Oce0x75BN7qUHp/pvVd1GY1/ifmtf6
W4TB/1/q10lm3+jZRn3mEHOkv8W8yt9jXk30Rv0vOVpvjvK/M0f7i0QeZ7dzdBtHN3HE48hV/g6u
3cEdvubofGFyTRuvfsd1W/WdN3Q8Q90NZjNvgyHuUN+iwWwBs7Wm+gZV9areLPe3mup7VQ1ebUWe
sTzxFu44jvvf6q8zb4dZ7vCn8Q6yF7PtzHbw3tu55g5/Bq828Wosr27z7+Rur+s7EcPcYRezDVyV
4tXv/aVmLR79ghjIFS/7T+r/m8ThVoWYbd0rIlZc9LGWiT76uxengoO/c7HanSMq3EbGhYyZ71is
19+t2EP/xkv7z/bv+y2Xil5vc7xelDplIuwMEZXOUBFxTgNniqOdYerbyHnnIK46NfMNIep7ydW3
7QhTf/9j5rsHa4ShvtubLO+JUmObiBmtjDtEzCwDQ7haclQdKRWy6AL9zY0x0e2//Xbz9TnfcG6q
p/KsLkUX8rwTxX9xh0miWjzJPd9hXg/mgHdFTAoR61Ygqq0BhmsNNPpbg0WphSTW+eBH4CJRaV3M
+UuZj2Y+gfEuEbV+wzida2eAjbx3q2ixQ6Lanma49kxjiD0LvCUq3aeQ5FVR6s40XHcWeB2NvwGQ
w50nqlmhVXSpCBVdJ0qLbjSGFN3Giu8QUVa9ouhOWNwS74uw+AB8COaB+aABLBThwo9F2AqBK8FV
4Mcgqr+Ds9p6hnEWeme12DmGnWNF5bwvdOC3hKLvavRd/f/tt4X2YpX4mu9TD/jSERXmGTzx/0Ws
yHbtijw9m7NP16LAGsBTBoKNotyeJu6wZ4pJ9iwxyZ0pyt1Z4HUq+TfAPD9VdCMeegjvCHFVhKsi
ud8gytmICBzwnaYR/a2lJkejHI1yNKqv6cOrPrzqwzUW14REb/E8798N9gJfRArXg69AkvUPEIOQ
cpB1CvOx4B7QABbrb1YdhDwh5Amhm3HoZhy6GccK+rCCPvt9h+qNePF4ZDhBx9uTPOl5kX9gvCFF
PlLkI0W+ij0kyUeSfCTJR5JKJJlEDEaQJn+/GFTxN5Zj94BM7EWIPSVpPpLmI2klktYiaa2Ou1fR
3EzGWaA95lS8Xae1WZsTZ406zvp2SLqbmNsLfGEhmYVkFtJYsEJYS5ORxNJSLBZW7pNznjibJ852
36HLnydmE+URory06DJRXnQ9T+1MgkIYyhJbAPk0aPGEk8Gt4M/gL+Bt8A74GKygv18CloIEWIat
LwaX837FrRVEdQXcWkFkV+iIIUrEjcYpMC78ZsC0xqlgKDgNhETIOBOcKxqN4eA/QBicD34ELgAX
gau55scgCq4Fo8BogPWNn3Cfm8E45reDOwD+Z/wU3AkmgLvAfSAOHgAPgU285xuwRcxG8tlIPtto
gZO2g1bmO8BO5t/CUY6YTaaoJlNUE8WzzQYxu3A7ftQKyCKFO8G3oA18B9KisfDvIlS4G+wBe4Ev
QkEBTJAHAqAr6AYKQHdwGDgcz88TjTbn7Z6gEPQCR4qYfRTH+4J+vO4PfgBOBCeBk8GPwCVch7fY
l4ORvEYv9q3gNoB+hIu2K9F2JdquRNuVaLsSbVei7Uq0XYlGYmikWjN0i4igkQga0WyNRiJoJIJG
YmgihibUaiuRuBLpKpGuUhxjdPHHGX1BP9AfHA2OAceCAWAgGAQGg+P8oUaJP7Twa39c4QawETSD
TWAz+AZsASmwFXhgmz/ONkE3UAC6+0Pt3oxHgOPBKeB0MByob9TMM3rikxfBilvRQgi/HwRfRGG/
CiIwSgRG4YooXBFV/CALxCR5GLDEJPJ0RQennk/++BG4iBrjYl5fynw08wmMmfwcbedb+y3/K52H
O3i3PQdzPJODw9noVNxQTWRGiEz1rdBzicyYGC9+zv+PgV/BuJPA48x/DaaJPmI6eAfUg/c4Nhe8
z2r+ynUfMH4I5oH5oAF8xPFGQC4RH3PtYrAELAXLwCrwFXl6A9dsJG8F8IFNjFuwebsvZH0A7axF
O2vRztqOqGgQ1YFjRSm1QUXhIlEaPJIKpS9c1Q/0B4PAceB4WPVERqKfGqICbfaxqLfQZina7ENN
UUFNUUFNUUFNUWGN4Rzsad3CWEHFcy/58wHmD4GHQSX4De+bzPgk+C1A69bToJp7PsM9nmX+HHge
1IApgCxv/QHM4vybXDcbkD8tsrn1CZHDtW4xmAKj/x7Ui13wWSMVgMq1u+C1RrJ/hOwfIeNXFw2H
V68Bo8BoXfNUiIDK9tlMHstm8hh5MYGOVxEn5MIcFmpEh43oMGaVIMt1er3Hs95G6z7m9wPWTZUS
QaaYrlLqqezmiI1aJnKh28jrhbxul0vZVMkw7SAZinUF5sGs20Ar2CEasesK7LoCu64gvhuxbSO2
bSTOG7UNKoweWp4HOtVLpBO9VIoePCnMk2I8qZInxXhSpa6GspW3roru1XfaX8ZDxbN0R2nwPdgF
/u7Ptz4AH4JF1PXquPV/9RNEaX/oQT9FZLink7NU31lz0B7HcR1VfScVPfqrRX+16K82U93ryqJy
/8reT+2r7JlPoCq9S/twjJxeof4GXqaaoELLsEcF7FEBe0yDPabBHlRuYloOe1zbKXscytP78PQ+
3LGUO5ZyhwruUMG7K3hHKVf2Ef31ejpfSzVrqWYtueuI7LeOSw+Su1rL3VkFtE/eWFbeKPJGsvKW
i37/RJIOre4nQWcazEqRo7VaJKjNaq02R4pwVor9+56r4NwwnBuGa8NwbRhuDcOtYbg1Cq9G4dWo
UDXvfNAAFgL6Ifg0DJ+G4dMwfBqGP8P/IMYaWU0jq2k8MMYUh8KfUXgzDG+G4c0wvBmGN8NwZhjO
VH1XFL5UvVcUnozCk1F4MgpPhonRUnhSdTe7iKhpWZ4Mw5NheDIMR4bhyDAcGYYjw3BkGH6Mwo9h
+DEMP4bhxzD8GIYfw/Cj6uWi8GIYXgzDi2F4MQwvqk4pTPyHs/E/O8uLLcR8BVwYhgvDcGEYLgzD
hVFR0MEDrdqm5WihHC2Uo4VKVl95UPz3z8Za5YFekeOP4QPiKlOx/7OY2ucZ7dl4f8842Ddj4oh/
YMmOLNiZJTWTH6+zV2k2c+UyZ2kHc+5jzVJYU/eP4jDdOx7ImgVo7jBgAWff3oWqww7S3mHiGdix
EwYVe2DP98Ff92dT61MYNZ1h1SL1rYaF/9Id6lUeArl3OpaerJwOp4IOp4IOp0IWGHnyMGAZefRi
5XQ8FXQ8qs5qwbItdD7l9F9ha7TuDivov8rpucrpfCqw6EZ7lpFn12Hdt7QnKpZscV8n+71hBN13
OPYeepxnHIlVZ2PVSUVXikqs2ohV5xaNN47Hqmvpnds5VfGp6lgNvW9kMM/XZ3M74VJxAdwQgRsi
cEMEbojADRG4IUL8R4j/CPEfIf4jOr8vY2zP8YF/kOf7srp+oD8YBI4DKvefyHgaoH8jriO6FrhF
59+D6gHiO0J8R4jvCPEdIb4jxHeE+I4Q3xFiO0JsR4jtCLEdIbYjxHaE2I4Q1xHiOkJcR4jrCHEd
+Z/WF8R6hFiPEOsRYj0ibs5qKUTVSvUMHmf+a/AemAveR8d/5fgHjB+CeWA+oJOgSoUXgfLgj7l2
MVgCloJleg+pcr8q1RCW1m6mSq0lWmqJllqipfYApp2W079Ng2VjVKkWVap1gBVCWCFE3JZnrRCC
cWNYIgS7WLBuDNaNwboxWDeGdUJZ1g1lq6NpnVglhFVCWCWEVUJYJURlasG8MawTwjohrBPCOiGs
E8I6IawTgnljOZVpCEuFsFQoa6nQQRXYATySY5kQlgnBwlQFuRyiKkMkDh/EHaZYRY+S9X9xRGeZ
uYODc7Nxzi5lJ3sT7fVLm463fbXAwXsSalerFInUPlspEpWKMw7cPfx37xpay/4Xdw4l2ipFW6Xi
0OxeWBg9DkKPgzhTyZlKdFiZ3Y3rI7pjjYewxkP/dFdI7wj57+sMp3a3DxfP4YUDxCS9+zWP+Xy9
rzSJO0zjDq9wh0mu2jl8XczlDnO5w9zsHaYV3aR3+aLiFLzDEk9SET9PtL/DvB7MAe+C3RzbC3wx
CZ6fBM9PgucnWQOIlcFUlqcwLxOD8CILL7Lg/HI8yYL3y+H9SfD+JLzJsqZz7QzQwOvFSDjN6GHP
gLVmGi65wM3mgnLNXK/q+m8Xku8iJwwhJwwhJ5STE+ByYwg54dOi69DBjUZ/PG8FntdIThiC523U
e5YVSJqbiSqymSiMNBVIoDJQC08v5ek9eHoPnh7JZqKIzkSzdDbqz5P782T1VJen5R2Ugc7qiCrF
iZ3x4ULdlZe28122Hu7gtdzuW3Faxz7F8UDVyqGc6DyQu0ZzTXvEtnfWanfxGd0Vd3APXUg0u7IY
K4t11NS5HTEV/kH8A2d2dCblOsJVdzJbV1QD8Zhwdn84jIeE8ZAwq6vNraqy+8VhPCbMyhpZWSNe
E9Z7xkO0h4T1vvF0xhkgs38cxj5z8WGqBHLVqzp25iL5XCRvQfIWpG2Be9SurOoC1iJhLdIRFdjo
TjFNHJ/dR44iXRTpokgXRbJdSLYLyXYhWRTJokgWRbKNSLYxu38cRe/T0G0I6aJIF83ZM44iXdR+
0f8sK10LnlOKbkPZfeNGpFyI5+ThOXl4TihTx4hd6LKWGiac3UfehcRvIPELSOwi8VxxIhLHslVW
ORKXI3E5VVYPqqweVFk9slVWORKXd/j2YKycqbQi2r/HMleV1nSOzwCZiqsciVO66pqhuIjKK1N9
KZ+PaM94VVdgKw7w+2g24vrrKiwjveL7vUg/F+lnd8TBMUi/v+RCrNivRtwn+cas5OXoeXa2PlQS
lyOxllZ3JrA7Eq1ForVI1AOJeuhIzNSFLhK9jUQRJCrPRma7RP2RaIX4wT/7/CtbhQzKqUL6/IN9
stwKpDqnAmmP2LDeD+vss7TrdG+mP0vriMQp/3AfKqT2WvTnbCXoskKx2D+ptyty6u1d6HMX+qzI
Ml27J1RotpsOZmRYL1t7K+YLdeIBFTnMp+pwV3/WiAeg67noOoauK9B1j1wWFAH5or9UzvWXOi1g
O2hV+c8Iijz+CdGFStwQPURPZoXCEV1FkTiT1xeKS8k8V4pxYqiYKB4Ul4iHxS/Ej0UVlecY8s3j
4gbxBDkpJp4RM8Vtoo4YeYTKchHaWcK/arFcpMTvRNroIt40DjUOFR8a3YwCMc84zDhcNBiWYYkF
Ri+jiF6vtzFYLDZONkrF50bIGCa+MC42LhHrjYhxmUgaVxvXiQ3GDcbtYptxj/Gw+LvxiPFzo4vx
B+Mlo6sx1XjV6G6sN5qNw43N/HONLUbKKDI8wzd6SykPMU6Q3WQ34xTZXXY3fih7yp5GmTxcHm4M
kUEZNE6VtrSNodKRjnGaPEL2M06XR8ujjbPlsXKAcY4cJI8zzpPHy1IjLH8oy4yL5VB5hnGpPEue
ZVwhz5bnGCPlefI84yp5vrzAuFpeKC80ovJiGTGulZfLkcZ/yqvkNcYNcpS8xbhJ3ipvNSbI22W5
cZccL+807pYT5b3GvfJ+GTcekA/LR4yH5BOy2nhEPiufNX4lp8gpxiT5B/mK8bj8k3zVeEpOl68Z
1XKWfMt4Vr4t3zZqZb2ca7wgP5QfGlPlfLnA+KNcKBca0+USucSYIZfL5cZrcqVcacyUq2STMUuu
lV8Ys+U6ud74s0zKZuMd+Y1MGXOlJ1uMD2SrbDXmy7T0jQZTmtJYYnYxuxhLza5mVyNh5ps9jGXm
4Wahscq0zF7GatM1+xhrzH5mP2O9ebQ50PjKLDOHGM3mSHO0sdkca/7U2GG+bL5s7DGXmEuMvWbC
XGb4gUMD+dIofLTweWkW/r5wmnQKXytcKI8pXFz4mTyn8PPCbfKSwl3BLvLG4KFBW44P3h4cL+PB
CcF75MPBnwV/Jn8ZjAfjsir4YPAh+WiwMvhz+ViwKviofDw4Kfi4fCLIPzk5ODn4pHwy+FTwKflU
8LngC/Lp4EvBV+SU4LTga7I2WBd8U74crA9+JP8UXBj8WL4VXBxMyL8EVwbXyTnB5uBW2Rj81jpE
JqzuVrH8yjrC6iNbrL5WX7nD6m8dLXdax1oDZZt1nHWc/N46wTpR7rJOtobIPdZQ6wzTtM60zjQP
sc6zRppdrautqFlsjbbGmH2s660bzL5WzBpr9rdus243B1p3WOPNwdZEq8IsseJW3DzRetB6xDzJ
+i9rkllm/dp62jzNetZ63jzHqrXeMYdb71tLzTHWMmu1WW6tsdaYd1t/s9ab91gbrU3mfdYWa4v5
gOVZnvmgtdP61nzISlvfm5XWHmuv+XPbtE3zl3bADphVdje7wHzU7mEXmo/Zlt3LfMLubR9hPmn3
s48xn7JL7OPNZ+wf2KeYz9ll9hCz1j7dPt180T7THma+ZA+3h5tT7Qvsi80/2lfYI80Z9ij7BnOm
Pc6+3XzLHm/fb75jV9q/Mj+yH7efNJfZT9lPmZ/a1fYz5mr7ebvWXGO/aL9kfmlPs6ebX9kz7Vnm
1/Zs+y1zo/25/aW5yf7a/tr07I32RnObvdnebLbYW+wt5nZ7q91ittrpXkeabb1O7nVa3hG9wr2u
yju217hed+YN6TXdMfKGOd2cwrxq52zn/LzfOyOcq/KmOnc59+e96bzrvJv3rvO+89e895wPnQ/z
3nfmO4vy/uosdRJ5jc4KZ1Xex06TsyZvqbPW+TJvmZN0NuWtclLO93mfuxBL3mY3z+2S943b1e2a
t9XNd3vmeW7QDebtdHu5RXnfuke6R+Z97x7l9s/b5Q52S/L2uie5QwKGO9Q9M9DVPds9O9DDPd8d
EejpXuReEQi6V7tXB3q7UXd04Aj3eveGQF835t4c6O/e6t4WGODe4Y4PDHLvch8OHOc+7j4eGOo+
4T4ROM19xn0ucLo7xX0hcKb7svtK4Fz3T+60wHD3NfeNwPnubPetwMXuX9y/BC5133HfCUTcOe6c
wGXuPHd+4HL3I/fjwEh3iZsI/Nhd4a4MjHI/dT8LjHG/cP8WuN5tdjcFbnRTbipwU9F5RZcGflJ0
WdHlgQlF1xRdE5hYFC0aFbi7aEzRdYF7i24oujFwf9FNRbf+H+6+A06KIvv/VfUGYGHDdNVMz2yA
JS4sLLDs4gIiuCA5iAgiICIGOFRMqKcSTkHBUzxB9DzFEz1dFfTk/P3EE/VMoAIKSlyCkmFVREAU
MND/b72ZzYFN4P3+VZ+uqX5dabrrvXrf6tdV4dP81/snhd/rv9F/U/iswNrA2vD7AxsDm8P/HNgX
yAufEzgWOB4+N35A/KDwR0met9SMOee/OHAADaEr6f9D5x4oeeYecI/Az3M3Ir4Dx2xzuD+FUmSf
oXYswfF2CdoaHGuLnM+Dn+wuCbbB/c7NNWEly98dPM6scw/iOIFjT6VzfOMug/+mkqnz3O1uHn6P
VLeFZZR5MOg5vt+UjVr2mucN6tdVKSf0W9g2xaUdC1IKexrfpYO10vhQjfC70erd+U/Y/aE6taAU
k+enSqau5X9RQS0/VDlXbui3xLPIp4DHj4bOK/kv3J/Kvi/F6Tg7Cp/r7sSRW9iCajyL2e7woOz5
73bF5YqbVeLqRDfCVe5Ejn/irsFdWQOplsRnR5iyBr12F8535d8llnqQCRXUucRdXpBGMSWX/RL4
4F1fzmXtZn+EQ1PqZL52sOTzQOplIQnMtbppRerKZb7YfTqZE7wHRo5xjtzT37maOW5RXuXlP/dN
cx8Ke6sqI01uYcxdz//kcM3aWaz03cE2cNzw3l487QM4fjrt3T1Y5dFL1KChZ9zhP+8+G9LzzDr3
e/cj90P3+9+7HUFn9LUal/F5ybN8SjkaShk8dKacOw9HThFCCmpPx296qZRrCtNAdq1xc4IU/K4E
/60MlVWBhC0oab27vuAkqRy6OVsOfwe00zvcBSGa4fWc0rWgNZMhWxacnp+Lc0ehxMaYsgGhOYYH
j1CKeaf/P9Vx7tU4ppSglWi7mxXyY09bWkjOuQsgA1bxv5rnphW2vXZGfIyDa8xoGDo7ihqWucNB
K1E6j6OFo3da6AjiizyW/3m10Z6z50rKVIwvy93niqO838+5W0qcl6PZlupf692lJqyw7EJ8YTh8
5Zn+z4yVDc5YVW6Kg/naYUgrOwAJ9EIVavicwzOkS3Hf30tBjP9TUKKUma5AmoY0lxnuEBNyvIzZ
A476C4jFJbSfzowzNaQUL7+AE4IaMreXmuSPWO4Qt6Hb1Mi2YqNKOssjM2IsKTKKGNmfTkn8JBdA
oqeU1wzkWhZKE/rXIc0clFAfyMmnFuQxUma4+XaRawmOaQXjKrg3nxf8BdK+8OpkI6uCev3/HedG
lDifeepXt7E7k+PfFrvybUlKsau5FfGGu9XdavSWkppLkM6xI2Vp3e5NJc4PF8SWFx3PT/1aQd1l
jN3uD+6xEO42xyfB48w6IzFLydxy9I7S97Iod7tfo+2bgxToNgfddSGEuZC54qh7OIgSyyl7m7uN
70HJ0YnpHDNzUDxrAO7bz7j4YKiu91DzK9C1PyyW02hcQVS7O7/1fLzBZ/vcr0xYXns4zf6CWB7L
5jOMRvh+VW/eLrmWm3JWnXs1y6igpC2LL0r1it/HFfYlPksrcXUFa/MrqlTi0dppWfVdKT1qrTvN
vb/onHolyzkjz8h9rcT5znLSlWive43b04Qcf6/YlffMAe4vn/OTyr1S6457zJKCs6ZctzlYf3Cz
TuW5AXcax+dBmi0wnucGJ7uv8tkaHDmhcWcByzxzNrHCUc/IxVx3AOPQc5kyG345KMuDKMsdi6eZ
y7Rp7Hcb/QEI6ZtQLTnB31B5s91saCcB/I5lDik6NzitRN17Sp65e5i/d+fPPJu5kjM/X1I4z12E
Vu13P0Y/5t9lBTOna4pqxTV3fI+WmVnYoqXyU6/FWiqoP6vweZdx1fSRHKSZjX6Xwjq+ocx1Y9ET
Z4by56Dthjqb/YKK5gHQ1wcgNEdwXnxA0bpq+E9q5Q1f/rhUzdzLazJn4Oah5y4q9+qR4DubMlC+
6e+LaFGZOm255ZXhFhU5qu2grRlOP1bJ1L/7OHmmXei9+u8yCxPqM+W8J3G/ZIxQqtcYeujdXTD/
79T62ndAMV/i2Px7t+N3c1fVSinVlQ+LiuYs8izOuozi+mtlbg3a1L6K5yLKzLW88Khh/bUz6hV5
O1mFXAX/osataFJuHeWMxGWO0SnQoFPg61WqTp4vDGk/SYWUcty5lSqzYpfE9aRXoqz00m+2asWd
mVL/G13l5tdKy8PgzFCvGtdtjsdqUgik41eUVJ5FUpBbC7WnAhu9KnNxOeVnnT7N2XXQRX4qe9a2
kvkP17ABSeXV7R5yD5WpRzG9FlwtzVu4G/jN8eFyrvIohl4X0vUKfgtGt9Lz6aepL7fYrFrw/UWN
/0tobr8c3ODuD9kx5r9rPliUzrHva2JBGcStZ3MmqXZc5RFt0btj7pW7I4QFchD/nPHAPPe6Im/t
x5bLF4fL7mvF6ZBYe+Bfcd/B8UoBbba72J3lrnRfLJYz112GtIVvJc1MwvlUYJkM3FLijUepugvf
ve1Gf65lq2C0L6/A+vEQI6dQLcbaq5Jl9D71qxub/3aS34YYu8EUPtvLsy357zuKaZ14Djlll8hX
zZzibncy6zvBOchl7EeC/i6fT+N2ButbzqGZERxTTnlr2K5igLFr5PNAkWvLuLTs/Dmd4u/uGXOu
N7ai5Tb2bM7TGv11ScFZFupWfH+C92jAqaNuRMh2cjnfF/jQs1jOs3a5hh6aFwzqwiY2u0IbTvOG
ORdcZJ7XhUwJPovJwXfI/LTW8DyteRudw73AWC1dzPOqRWoLlTcPz34JzyO/yM+w6DztAr5urIWC
M8B7i7XE2ADs/a95FsXfwmSXmDO/zQ247YL6Or//282clsJn5imsZ1rIDiFofcFhTkUzqfwUmaso
f848yAFmjjzYsxcz9wafdHCG3Tzn8XytmI0HU3Ldp3h2PTf0JLOK1lWi7lUlz8q3JznbrpAnTpuy
UAop/v+f51s74InsZG6vJNItD0fzm+HgG+HgGwVznuMuDT01Qzdjfk4Zd9jMTK8xUujszKafXVdg
772EJdOK8ue1ioyYxhZuGe7i52WmW+u2qXmbMDLk8mizzFir41hR8bvT/KcW4u0KRrEieSbn11bm
1UrYd1ZYesh6k3vuweA45k6vWZll1lPyncfFlErJODge4sFuNaoBZbjv4PioivmCfatSWmOINyv5
7UxVXYEGn/9b4suwcvNtQM8zsnljvp1JGWnyvxmahX46nJ92YY+S7qyCdLuKvqmqjnO3G20ixBeP
hnrXMvfjCvMUe2aVsz/IHx/LuVrlt/8l8i8vounsPXN8UUbNmWS4I9ifM0nC1667pUhdSwr6/0T4
sTiC0ibi1IZTedDSIkpasVXSdQNPZ57aY/YS4PiSwh5WdVfZNrhNS5xnG+s1N/tMfc15ZlzJt8p4
FnmnNoCjIk4drlaBmbj/9d36HE/mZ5FZ/dZVtg1lPIu8//vPotCd+i94T3iqUm/ga8J5JUray6is
vPko/lqk9BvUwq9Igm8yKj9vyyNHeaO5pKkURmasGkSDqS8NobupP82gmTSF7qN5NI3m04v0AP2T
1tBC+oLy6H36Bn4LHYTfSoeEpG0iXETSYVFX1KcfRIyIo+PCFqn0s2gvuiHWXwwSjc16J6K5GCqu
EylikpghssXTYrEYIXaJfeJqXtFkIq9oMoVXNLmHVzSZwSuazOQVTe7lFU3u4xVNZsk2so2Yzatx
3O+Z7TkuHvD8bMeJX2zb1tK2E+0k6bUn2hOlY19vXy/99g32rTJg327fLpPtO+zpsjGvq9HSnm3P
lq3tB+1nZBteP6OH/ZK9QvayP7ZXySvtz1SSHM+rYrypGqvGcplqqprLt3hVjP/wqhjvqvaqvfxA
ZagM+aHKUv3lcjVQjZa5aowaI/PMehjya7MehvzWrIchD6vb1O3yqJqu7pHH1Ez1oDyhHlIPWUI9
rNZaUn2hvrCy1Xq12eqhtqptVh/1lfrK6qd2ql1Wf7Vf7bcGqjyVZw3ilTAGq+/UIetCdVgdti7i
9TCGqpPqpDVM/aYta7gO1x7rMl794lod0EnWJJ2sW1i36Fa6tXUnr34xlVe/mKGzdBfrXn2e7mbd
r3vq3tYDuq8eYv2FV794nFe/eEJfox+wntFz9HzrY17rYq1+Ui+w1umFeqG1QT+rn7U26pf0YmuT
XqqXWlv0Nr3N2qq/1F9a25wHnTnWdrPGg/WV86jzqLXDrPRg7XSedhZae5znnBesfc5LziLra+cV
5xXrW+cj5yProLPKWWV953zmfGYdMis6WN87m5xN1hGzooN11KzoYB0zKzpYP/l7+Htax/29/IOs
k/6L/BeFSf8I/8gwyz/aPzYswj/OPy4syn+1/5qw+iTFYV4dqDOFw1sUAR9GkfCa6sBHUF34OlSP
fRTv/duAfTSvJGR8HMXCR+E3jmzywGv82uQHolWIGx9PXvguZHaqOpcc+Ea47qfzKADfHdfjKZsS
4BtTIryx+GuBVqVQS7ShFaWhVW2pHUpqT51A6Uxd0Z7zqA/q7Uv90J7+8DHg3QFoheHeOHDvxWjF
MBqDXJfDR9BYGod6rqTxaMkEmoiWXEuT0ZJb6Y9owx3g8saQANNR+5/gbXD/3cg7Az4NMmAmWnAf
fCrNgm9Os+Fb0P3wKfRn+DRIhgdw9UH4ljQHvhU9BJ9Kf6GHcXUuJEhbSJD5lEGPwmfSY/Ad6a/w
qfQ4/Dn0N/gsegLerJn2JCgL4DvRU5SDEl6A9GkO6fNPakavwqfSEvo3KG/S22jDO/QfXmvrY9A/
oZVowypajTZ8Cp/KKzU1g9xag/gXtBEpN9EOtGcnfHPaRXvQqr2QaJks0dqwROtIh+g40p+gX9Cq
X8mlcwRBxnWCjAuntiJCRJAQkZB3ktd9UqKeqEfhIkpEUaSoDwlYFxIwhuqLWBFL0SIO0jAWMhC9
hFeFUkILTY7wCi/iPuGjgHCEQwnCL/yUJAIiQA1FvIinriJBJFA3kSgS6XyRJJIoWTQUDamJaCRa
og2tIGHDeV0pJTqILoib1aXqQtoOQO0DxUDUPkgMQu1mpalYSN7haINZb0qJK8QVSD9OmJXcrxZ/
QO0TxXWofZK4DbXfLu5EvXeJaahxurgbNd4j7kHeGWIG8j4tFuI+PCOeoRbiWfEPShPPiecpVeSI
F6ileFG8RK3EIrEYlF1iF/UTu8Ue6iH2in2IHxKHqL/4XnxPA8Vh8OEAcUQcoUHiqDgK+g/iB9CP
iWOg/yh+BP0ncRy5TogT1EucFCepj/hZ/Ey9xS/iF+orfhW/gv6b+A30U+IU6K5wqS9GEUk9pSUt
ukCGyTDEw2U44hEyAvFIGYk4xhhqb8YYSjdjDOIYYxDHGIM4xhjEMcZQohljaDDGmEeos2e+50mK
8CzwPEVRnr97niPted6ziHyexZ6XqZHnFc9riP+P53Vq7FnqeZ/SPB94VlJzzyrPakr1fOpZR209
6z251M6zxbMVlG2enYjv8uyhczx7Pd+T8Bz2HKdwjGRECl0mgrx2pF2HGtp17WjEY+w4SsYIZ9O5
ttlrpaOtbU1JGO0SKdVOspOotRnzyDJjHmmMeTcivMm+maLsW+xbEJ9sT6YI+1b7VqpjxkI6D2Ph
Hbh6p30nxdh32VMQn2pPRcpp9jTEp9vTyY+R8h5KtGfYM1EvxktqivHyQYRz7DnUyX7IfogamDWp
qKX9sP0w4nPtuYjPs+dRZ/sR+xGUM9+ejzIftf9Gjewn7CdBX2AvQEuesv9O9eyn7adR+0L7GaT5
h/0PlPyc/RxKft5+Hldfsl8i215kL0aul+1XkOuf9qsoc4n9L6R/zf4firf/134dJS+1l+K/v2G/
gav/tv+NlrxpvwnKMnsZynzLfgslvG2/jRLesd9D3vft96mx/YH9Aegf2h9SmL3cXk5x9gp7Bf7p
x/bHyPuJ/QlKXmmvRJpV9irk/cz+DDWusdcg71p7Leif2+uQcr29HiVssHNR8hb7S6T8yv4K93mH
vQP/Yqe9H606YH+Nf/qN/R1qOWQfBuWIfQz/7kf7BHKdtH/G3f7FPoXyXWVRFxWmIulcVUfVp0aq
gYqm81SMiqXuKk55KBtdwKbGSikvNVU+5VCc8iuMMCqgAhSv4ClKJagEilGJCuOLSlJJpI02Q22N
NoOwqWpKqaqZaoZ4c9WcWhjNhlpBs0mjlqqtags69BvqaPQb6gT9JgthJ9UZV7uoLpSmzPrGqWY1
MKQ8T2Uj3kP1QLynugBXe6le1Fz1Vn0oRfVVfVFyP9UfVweqgShhkBqE0garwbh6oboI6Yeqi5F+
mBqOci5RI5DyUjWSMtQoNRoUaFRIc4W6ArnGqXGIX6XGI80ENYHOMdoV4rep25D+dnU7KNPVdKT5
k7oH9JlqNkq4Xz2I8qFv4Z8+rB5GvXPVo0hj9h1LNauQoYUL1NOIL1QYfdQL6mXkfUUtQZn/Uq9T
plqq3sTdWKb+gzTvqvdQy/vqA8pSH6rlZo1OtQKUj9QnaOFKtRIlrFKrkH61Wo00n6pPcfUz9Rno
a9QaaqPWqrXU2uh8oKxX6xFuUBvQho1qI0rYpDYh/Wa1GW3YqrYi3Ka2kTQaISmjESKERkiRRiOk
rkYjpGhohN+Rx6yQhqvQC8kxeiElGb2Qmph10hC6WlJ9s1oaCbNaGikdoetRQ7NmGigNdAMK19E6
hurqWI1RTMdpD9IoramJ9mov6AEdII9ZUQ3pE3US0ifrxkjTRDelgG6mm6O0FroFSeiarRCm6lTk
ba1bI32abo+U6TqdknUH3QGUTJ1Jsbqj7khJ0ESzkL6T7oQSOuvOuNpFY3SDbgrNSXfT3ZCrp+4J
+gW6N1L21QNR2iA9BGmG6qEUqS/WF6OFo/UYtPxyPQ4lX6P/gNZO1Ncj5SR9Azn6Rn0LSpus/0gJ
+g49BfVO1Xejxnv0DOqqZ+p7qZu+T8+i8/VsPRs13q8fQPvn6DlI+ZB+CFf/ov8C+sP6YbRkrp6H
Wh7Rj6Dk+Xo+Sn5MP4ba/6r/ilyP68dRL3Rlamt0ZYTQlakDdOWXKFUv0osoTS/Wi0GH3gwK9GZK
NHozJUJvfpBSzQpp1NZozwihPYPyuPM4tXT+5vyN0pwnnCcQhyaN8DnneaTJcV5AGujTlGH0aco0
+jR1MPo0dTL6NCjrnHUI1zvrQYFWjbzQqpEXWjVCaNXUFlp1D2ru7+nviXgvfy9q4e/t70Np/r7+
vqD08/enDP8A/wDK9A/0D6SO/kF+cLTRv5FmhB/867/Ufyml+kf6RyLvaP9oauW/zH8ZKGP8lyPN
WP9YpIF2jhKu9l9NF/qv8V8D3U/KCayj92HtPIY18ZiQFm607RjWs2NYw+7LGnY/1rA1a9gDWMMe
xBr2haxh+1nDTmANuw9r2BZr2DGsVccgt9Gnh0FjjmFduS/ryv1YV9asKw9iXdnPunIC68eJrB83
onuhGWexZpzGmnFb1owzWDNuz5pxB+jFD4HyF/hM6MUPQ8ucC58F7RhjJD0Cn8VaciZryV1ZS+7G
WnJ31pKzWUvuwVryONaSe7KW3Ata8lP4V3+HT6Sn6XnEc6AxJ9JL8Fm0iBZTa3oZenMW9OYl0HH/
BZ9Fr9FSxN+AJp0FTXoZUMZb0Kfbsj6dAX36XUqn9+DbA+2vQPwj+PbQsj9GCz+Bbw9d26yrvgo+
Axr3atA/hZ6dQZ/DZ0Db/gKUdbQe2vwG+Exo3pvwXDfDZ1EubUf8S2jhWdDCd+HqHvhM6OJ78d/3
0X6gnAPQy7vS19DL0+hb6OXdoJcfovPpe/judJh+RPwnaOrdWVPvAU39V7qAfoPPplPQ2i8QZlGb
XkJCd+8lLGFRJmvwjYpo8FGijqgDLbkudPco1t2jRQMRjTg0doRGX49mfT2K9fVo1tejWF+PY33d
Zn1dsb7en/X1gayvD2Z93WF9PR76eiMKE8kiGfU2FimItyzQ4KVoLVqj5DYiDfihrWiHeDp0+rrQ
6TtQHZEhMlBjpuiEeGdo+VHC7HgXK86Drh8tuovuVE+cL84HPVtkQ+/vIXog3lP0Rbyf6I/4QHEh
wovEUIQXi2FIPxxIIApI4BKUM0KMQDmXissQHwNUEA1UMA5XrwI2iAI2uBr/9BoxHtr/BOCEOHEt
cIItrhfXkxdoYRL++w1iMuK3AjkoRg4DgRzuAq6YIqbgDkwFiggARUzHfbgbWCKesUQUY4m6YqaY
ifi94u/Q3Z8GZkhjzDCaMcPFjBlGM2a4jDHD5YwZxjBmGMuY4TLGDJczZhjDmGEsY4bRjBkuYcxw
KWOGEYwZRjJmuIQxw6WMGUYwZhjJmGEYY4bhjBmGMWYYzphhGGOG4bK+rE9dZLSMpnNlrIxF3CM9
iCupEPdKL+I+6aOGMkEmUIRsKBsibC6bI2wr25JPZsgMxLvILoiPkCNolLxSXonwKnkVhcvxcjzC
SXISwilyCsIn5BPU1KyTS83lQrkQ4TPyGUqRz8nn6CL5knyJGst/yX8hfE2+hqtvybeQ/h35DtJ8
Ij+hVmaFXIQbJLQKuUluolSZK3NpqNwv94OSJ7+mlmZVXEq14KiJWQ+Xmll1rboI61n1qIXVwGpA
QyyP5aFkK2AFEMZb8bja1GqK9AYdXWF1sbpQQ2uKNYV6W3+y7kE40/ozwjetN6k3Y6c+wEivAS8Z
dOQHOlpKiZ43gJGSgJGgP3k+BFJqA6S0itI9q4GX2gMvfQr6Z0BNnYCaNiC+0bMZ8VwgqCwgqC3U
3bMVOMqsqLsd8S89OxDf5dlFPT27gakuAKbaC0y1D8gqDMgK2rbnCPBVHc8Jzwmq7znpOQnKz56f
KdrzCxBXLBCXpGjbssMRjwD6igb6igQSqwMM5gUGq4d4lN0A8WjgMQU8FkOOHQtUFmBU1o9RWTdG
ZbYdsBOg3xts1p6xWZo9yZ4E7d8gsRjGYA3s2+zbEDdIbIA9BeirAdDXNFAM1upn32ffB1Qwy54F
VGBwVwJjqj6MpmIYTWlGU30YTVmMpoI4KoaxU4z9ov0iyjTYqQ/jpRhGSpoRUQIjoj6MhWIYC/kZ
C/VhLBTDKKgf4x/N+KePvdpejdI+tT/FVYN//Ix/+jDyiWGcE8NIJobRS19GL/0YvWhGLwMYvQxi
9HIhoxc/o5cExicJQCaNgXOaqCbQlQ0y6cTIJEulqBTo3y1VS+rM+CQD+KQNdPE0oJQsRimNGKV0
Ux1UB+rJWKUXY5UsYJVOSN8ZiKUjI5YkRizpjFg6AbGcBzTVDbjlfCCWXrjaW/WGnt0HiKUdI5YM
RixZjFg6MGLJYsTSDojlQpQ5BLgliXFLG8Yt6YxbOjFuSWfccj7jlgx1uboceQ166cXoJVFdqa4E
xWCYToxhLlB/UH9AyolqIv7dtepa/KPr1CSkuUHdAP3+RnUj8t6sbgblVnUrQoN2Mhnt9GS0k8ho
p5GaoWagPQbzZDHmaaPmqDmIG+STxsinHSOfDCCfx6i9+qv6K8p5HCgoHSjoadAXqmdB+QdQUEeg
oEVo4WJgoc7AQv8E/VX1KlIuAS7KBC56DW37H/W/QKevAyN1ZYzUDRjpbdzbd4CUzmeklM1IqQcj
pXGMlHoyUurFSCmDkVI3Rko9GCldwEgpEUhpLdpsMFKiWqfWIc16YKQMxki9GCNlqy1qC1qyXW0H
4t2hdgAF7VQ7qa7aq/YifkAdQGgwUn/GSFHqoDoIdHRIfQ+6QUe2Oq6Og3JCnQBeMkgpHkjpN6R0
lUtRUAEEwiBeCtNhwE4GNcUyalJFUJMEaoqG3h8D7BTL2KkesFMcKB4gqFggKIVyDIKK1T4NXYJx
VFQBjkqkOjoJaCpKN9SNUIvBVLGMqeoxplI6Racg3lK3RBqDqeJDmKqNbgOKQVaxjKycELLK0Bmo
3SAruwiaitJddVfQDZpyiqCpKN1H90EJBlNFAVMNRnsuBLKK0hfpixA3+CqK8VWsHqahRehL9CVo
zwg9EvHRejTilwFrRTHWigXWugVxg7LiGGXZjLIUo6z+jLIGMsoazCjLYZQVrx/UDyKXwVo2Y62B
jLWcENaaD2QVxcgqXj+hn0D8Sf0kNdJP6acpy6y7jdCgqSxGU5l6p95JPgzOYRThbeBtgHCYdzgo
G73f0ijvQV89CvdN9k2mCN9U31SEK30rKcX3me8zau5b61uL+DrfOrrIt963nhr7tvu2U1PfQd8h
XD3uOwH6b77fQHF9LjU3EIRSHOlIaurEOR5q5XgdLw11Ak4ASCzFAfJw2jntELZ30nE1w+kInNbF
ORdpujrngdLD6YFwiDOEkp1hzjBqZtbRphbOSGckDXFGOaNAv8q5ipo4k53bcHW68yfQ73XuBWWW
MwuU2c5spP+z82dQDHrMch4CbsxyHnGAMoAeH0No0GN3IManES50ngEO/AdwYxYQ40vUmRFjV+cN
59/Uy3nfeR/0j5yPEa5yMCIDPX5O3ZwvnC+APDc4G6i3s93ZDvoB5wDCY84xlHnCOUHZzknnJPVw
fnZ+pl6MJLszkmzkv8B/AWUxbuzKuLEbI8ZujBgbMWLMYsSY5h/lH4X4aCDGDEaMmYwYO/uv8F+B
+FX+qyibceM4xo29/OP94ynRP8E/Ebkm+SdRuv8m/03UPbApsIWaB7YFtiHcF8ijVoFvAt8gPBY4
Ts0CJwMnqRlJf65ZvzthYvJ1QC218fVWzZyPQl9UVOddf2lrzKAlTxF7nqnuXPhb81fILnCZVN89
6u5wZ51+fb5SdRwuZXOU6m7m9897Cmq+mG3ws0PHifLfhJ95h5pV6Lc6LrWaFmyp1cpVc5f8+9Rc
8Up8lSzjtN9FuQcLVkYOWbW6B4r2xupZeJr+eZoUBRxl6ubfStmj1r5zbz0rtZSyInNn5K+CVu1V
MLaUvmvBZ1dgr51TdAW10Lp4yW6/0Pmsqq21hBwTkGOqyZ9fRn5JHC7J/4oF6YpYebljqlpP9V2V
LQYVpPaxkNVQ0AI43+JR5vfMClzVJUNqgU2UDB2+KpdRxFXami4VcneWm8xPaYs545bscVPJ524x
T65MWZFaXIbw+Mj/OWTRV1nnM/c5f2SmgrzBle1L2dNXrezSLj8/39kqfhta3jpwlXlKMpQq2bTA
PVTwjVyqOzXUlmWGE0p9O5ccKt9XRn+qRA8LrodZtKVnh9/Qb6biyP9yzQeOWeIW3j9fid/arftQ
0SfL/eo0lsru6gqvlhoHy3H1wTPLCu62OTt0urvtbiw/Relx8HSueqNFSI8tqKMS359cHPpNZXm+
1s3htceC3H/I2Ibjvy9wR+K3pLU7Pwn0Smm+c+HeOQAxvq9ufLGyy27roeK/teImnD4J6gtKDl8Z
fbZyvbh0H6y8fMZdrnKucttVuXGBn2ixEsrS6UuuKFnRjjWV+mLEPNfCOyVr+UmXV2sFfF1cIldt
3SKW6CuqK3MhSQxHme8sqqRLlPe9cKVrDY4YkmV2BSvTVaPsSsqx8iTZ6b7frtZ9Tg6O66dZKaIs
pFcj7Mf3eQnl3+daHZVPd5/zV4qElC4zpbur7HtR4/4c1GtlgTZUuXw168+V3gusth2ertH1zPpa
FWqtodHPPAke+0KrdDSk04yFlWrDWVtn7UzK6crLjSqWW6I/QxfPv1Lr/6ZwHKlZf660q4WZqYr1
4nJzLal2habN3YAHN7tfuDmhs/xSeZ26CmaCUqF7TzdaRjCkSn+1azCvW9/NR2Fb8jEXI+JZ7i3l
6UtIW+YXTKcqMy9W7OlUUUaVJztrhqbqB6VU8b11ynKhVRUq/G62Ci45H4ufZvztV4pWo6+ya8PV
oKdXr74FoZm9s11vSHaF6pV0PdvjkGwoG5Ew+1+TxVY5YbKVbEXhsrVsHbLQiZQdZCbVkZ1kV4qS
PWVPipUD5UCKk4PlYPLIEfJSsuUoOYq0vFxeTl55pbyKfHK8nEB+s/81xbP9ToK8Wd5MiXKynExJ
8nZ5OzWUd8qp1EjeLWdSUzlXzqMUOV/Op1ZmL2xKZRuf1nKhfJbayOfk89TO7IhN6WZHbMqQr8pX
6Rz5unydsuQy+TZ1kv+R/6Fz5YfyQ+oqP5If0XnyE7mKupl9sSmbrX56mH2xqafcKDfRBTJXbqHe
Znds6mt2x6b+co/cQ4NknvyWBstD8igNlb/IX2iEPCVdutTsjk2j2BpotNkdmy6z6llRNMZqYEXT
WLNHNo0ze2TTVZZjOTTeamI1owlWC6sFXau36+10nf5K76TrzU7HdKPZ6ZhuMjsd081mp2O6xex0
TJP1CW99+qPX602kOd5e3j/Qo95bvA/Qm9753kW0zvuWdzl97d3oE/SD2fVYNPJ1900UKWa/YzHU
97hvoRht9jsWV5v9jsV4s9+xmGD2OxY3mv2Oxc1mv2Nxm9nvWPzR7Hcsppr9jsUMs9+xmGv2Oxbz
nDpOjHjU7HQsnnK8TqL4u9njWOQ4zZzWYpHZ41i8ZvY4Fm+a3Y3Fu2Z3Y/GheSsrVpvdjcWnZndj
8bnZ3VisM/sai01mX2ORG9gU2Cz2m/eNIi9wNHBUHDTvG8V36JEbuUdKthCTshH6ZRj3yzrcLyX3
yzrcL6O4X9ZHv+yAPmrsx6TMRB8NQx/thDSdZRdcPVeei6td0WvbcK/N4F6byr22I1uaZcpL0Xfb
cN/N4L6byrZnmWx7Jtj2TMgJ6McW9+NI7seC+3Ek9+N63I9box/fSXXlXfKukJWakFPRsy307LuR
8h45A2lmopeHo5fPBQ/MQ1+P5b4ex33d5r7uY3u2aLZn88tn0e/bsVVbW/k8en88ev+LCI2FmwYP
LEb4MjjBx5wQy5wQB05YhtLeAj9o5od2zA8NmR8asf1bY7NbPHWQq8AbrZg3mjBvNGPeaAbe2EjN
2S4uhe3i0uUW8EkL8Ml2hF+CW5LBLTsQ7gTPNGOeacRWc43lN+CcluCcQyjze3kYXH1EHkHtxpou
hXkpBrx0itpLFxyVxBzlYY7yMkc1YPs6x4oCXyWwlV2aFQ3uCoC74hAaizsFHlMINTjNy5wWA05r
gnKagt8U81sC81sd8NtXCHeA6+oz16Uy16Uy10Uy10WC675DeAi815p5TzLvhYH3BlId7yDvIIry
DvYOp/reS8CNEcyNbZgbM8CNH1Cq90PwZEe2ncj0HgRnCsOZZJn9yCnS18fXl+qZXcmpte8S30S2
rJhC0vAqRYBX36V433u+90gbjqVYcOxysn0rfCso0feRbyXiq3yrkGa1bzWurvGtoWi2wfCzDUZb
33rfRlzd4tuCcKtvK9KDtxHf49tLcb59vv3k8x3wHQA9z5eHMg/6vgflsO8otfP94PsBKY/5jqHk
H30/Iv6T7yfEjRVHW99J30mKN3KB4iAXwijZCXfCqZkT4URQI7MnOnVw6jp1qZVTz2lATZxoJ5pa
ODFODK5CdlBztvRId3yOH3Rj79HQiXcSqLHZNx15IVNAb+Y0B72FkwJ6S6cVyk91UnG1tdMaJbdz
OoBibEJSIHGyUHInpxNydXY6I26sRNKdrk5XaglJ1JsCTh+nDymnr9OXGjj9nH5kdl4fQO2dgc5A
SnIGOUPI41zkXISUQ52huGosSRy2JElzRjmXgX6FcwXCcc445IL8QvwG5wbEb3RuRAmTndvJ6/zR
uZMSnLucu3B1ijMF5Ux1piI+zZmGuLE/SXPudu6mAOQd+CiwObCZfJB6+xDfH8ijZkb2UV3IvmOU
EPgxcJy8JEUkW/pmsKVvKlv6ZrClbyZb+p7Dlr4d2dI3iy19M9nS9xy29O3Ilr5ZbOmbwZa+bdnS
tz1b+rZjS990tvRty5a+7dnStx1b+qazpW9rtvRtw5a+rdnStw1b+rZmS982bMVbt5iMNtI5soh0
jmS5XIflcnhILhu73joshZvKbJkNWWBkcZrsLXtDahiJ3Jglcmc5VA6lLiyXO7BcbipHypFIb6Rz
mhwtRyP9ZXIM5I6R1I3lWDkO6Y287hCS11fLqyFzi0rtiXJiSHZHyOvk9YgHJfgN8kbEjRyPkLdA
jlssx5uwBA8rJsGnyz+F5HgEy/EmLMfD5KPyUWg6xhY5hmW3h2W3h2W3YtndgmV3c5kjczBiGand
gO2SG7BdsoftkmPYLlmxpG4hV0BGB1hGJ7CMbiVXQzoH5Bq5hhy5Vn6OuJHUCXKdXIe4sWBOYHmd
yPI6ieV1S5bXAblVbsXYsA1SO8BS2y+/gtQOyF2Q2gFI7b0IjcVzAsvuePkdpHaAJXWS/EH+gPhJ
yOtY+Zv8DaGR2ikWbgXFslV0tBVmhSNuZHecFQnZHcsW0nEswW2W4JoleDOW4LFWjBVD9axYyPFY
luP1LRtyPNbyQo7HQo77ERpb6vpsSx1nJVkNQTGSPZbtqqOtZpDvsSzfNdtYd2Ib67p6lB5FFn8h
FMlfCEWyfVsdvU/vo8aQ9d9QhD6oDyI0Ur6JPqKPIP0xfQzhcX2cLLaEk2wJJ9kSro73Cu8VFO6d
6IW8Zonf1Pug9xFqyHI/zbvYu5gaeV/2vk7J3qXe/8fet3DFcV3pnlM8jDHGuB90gTAmCsYylgkh
DCYKkQnGMsYYE0wIoyGYEEIwxljGmG4aAg3d9ejqV3XXo1+EEIbBCktSGJkQgjEmDFZkIitYwYQo
jIKxIjNEZhQtDdElinJ3lWet3HV/wb2zor2qqao+z7332ec7W/ucnoL7nyTOwL0yH+xX54NDie8k
rqAvqbPCF9SIOmVWeOy/Z4VodVaIUGeFz8Ks8CqKVOPtCDXeTpkbAjBP/MDwA/hU5oNENQJPp0bg
aVTrr1Otf4YagXe3YQXmgLtU65+oRuPdY/id4XfwRrH7iWpknka1+A+qFv8u1b5nqFF696hReho1
Sk+nRundA1NqBNiyO8g74FOx8op9vwvu7wYrnwRWPgHulUi+FNXK36da+YfAyhvgngRbb1DteyaZ
SqZCyvvJ+8HCppGfgfv9YPENaszfPtXKZ5JZ5OfgvRL/t0+N/0tRbX0q+Sj5KKTMB1ufrFr5h9RY
wBTyK+RXoLQisgjeK3GBKWQxWQz1HiGPwHtlDkhQrX8C+TT5NHwq1v8A2P1n4V6JIIwD618F90oc
4b2q9deq1v8BNY4wjqyFOSCWrCPrII0yEySoM8EB8lvkt+BeiTKMJ79NNsH9d2BuiCVbyVa4V2aI
A2Q7+SrcKzGI96ozhF6dIWJhhvguvFdmhQfUqMR4kiZpeKPEJt6rxiZq1djEeDUmT6PG5GnUmLwU
NSYvRY3Ju1eNybt3X/m+cpSAcORi5BLCsOLXKJt6vDxRI6QIZUKnsCpWwcWL54RccVtKlnKEXMkn
jUoTwo40K+wXCoVKoVNMFUvEdkg1AymKpQohV0gJpAXyAxWB5oAvMBVYCGwEI4P7g1mB2WBLsDMo
Bufg2gzuhaJDmlBmKDu4GuyBdGmBHMjTBnmuB2ODKcHCYGXwSHA4eOLTlMHOQEdwNVQkL8pL8rK8
Kq/Lm/KWfEPk5T0/8sfJY36NkChtyJt+Uqk/1BRqV+vfCPVC/Vkhm1J7iIe6s4JzgdFQdHAsNAIl
Hg+dElKk6/IJeUno9JcIJ/z1cqU85+f89SLvPwW9L5NXoccT/kv+y/5r/l3/rQAhJAbiA7pA8uB+
P/TbbxMvy3PioJALNZdC3XxoO+ALXQuMh+PDyeHDwRbgwaf1VoSiw1PhheBq+Hx4JXwlXB2+Gr4e
vhmoGIwdTAhdDgfCdHBP4Rd80xweCq6HJ4JieNafp0jCXyCf8Gf7o/3p/lThhJAoFomysBkMBVkp
H/rTAzQgZgqN4ogYLa6JnHhGOijlS1MgrWFhUSIEVilFGIbnTtEklYqXhTqQ2llhT+gR08VLkGpH
RFKacEA6LM1KAeGYsCzGSRuB4kBpkA00BKoDHQFzwBIYCo4FRoG35wMrwcRgQvBQ8Jgq2dPBpeCN
UJ7CXaD0UGowBVJNBKZCBQFnsDHoDpwNigE6cDu4HBgPssFp+NYXyAjUBstCcYGLgcMhMnAwEAge
CK4Hd4I9oZJQeagqdDRwNYSCNcG64GJwK3AlmAu5GgKzgZvQPrfa5nQxW2yCvg2K23KLlCO1SbRk
kYaEStCMTOBWprwD9VYEGkD+lSD31pAcmglxofnQmdCgvBqqD5lCk/6mQIy0MpgymOgvF0Ab/HH+
dj/vH/FP+o8LlfKq5BN2/Bf852S3f9tfBNQKWiL760ErOBgLbqFSHAQtKvSvySF/lf+ov9c/6J/3
nxGG/aawbjAyuBlaC10I7YZuhdPCB8M54fxwbbgtbAl3BCrCPkV64bPh8fDF8Eb4dtgcNgcjwxnh
4sBG4Ep4JcQFcoDnoAuhc6FLMGJWgzeCJ8JEOCZcEW4IO8OjgdFwqZAFo++QUCMMCCLox2lhWkwX
1uUEGL8aeb/YKh4VbXKZXCddlOIlnXhNvCXFCJugATFSrTQuh0DmCzCmW6TrwpicKKeI5fIhqVlq
EEmRlK5IV4Ujwn7ppnRbjpRjhTmxQM6Sc+VC+QiMlxpxVzwlHhcnxXl5GKwBL0zLx+ROuUceEE9J
HbJbFoU5eUxaAQ6dllm5UZ6W5ySzWC/2Qq5dAEEZUrV0XtgSbsgHxDzxgsxKTmFTtUDnVOvjkyZU
q5MLlmkYehcC6ecKS/5TwSywW1j7JVj5j6p7RxGigLB6qgqh7hqNQB40iCLRGHodrNxJIB2aBtKr
uy4T1T2WBvQBEIkuASWpp5gko4+B9qE/AKWgT4DuQ38CSlV3PN6Po/H9KA0/hDPRIZyNs1GBurfw
y/hL+EvosLpv8DF1l2AhfhY/i4rwV3Elehw/j59HT6hnhBzBzbgZPYlbcSsqwZ24Ez2FB7ANleKT
+CR6RsW65UQhUYieVRFvhYp4vwqItwRVEqXE06gKcG8VqiaAUJ2KeJ8HBNuN6tW1uglw4C9QF6zM
V5EFEN0m4ojLgNYkQGsfI1ldVwdUhBYi/ovYRWHiZgRC3wPwbkBjEUkRKWg24n7ATvMRn4n4DPoZ
YKcMtBBxIOJh9E5UVFQ0ejcqJioG/SIqNioWnYuKi4pD70XdG6VF56MSowzo/eid6B30q7vi7opD
K5pfaX6FPtD8VvNbtKrFWox+rb1Teyda0+q0evQbbbL2PvRbdW/S79RdSRu6A7qH0IfqSQkf6bJ1
n0e/131B9yj6WD3/4Kq6j+gTXamuFO3ovqH7BvpPdefPNXXPzx91LboX0XXdS7p2dEPXoTOiPZ1Z
Z0a3dW/o3kB/1b2vu4CR7gPdXzCh7D/BDyv7T/BBZW8JfkTZT4KzlJ0k+HPKHhKcrU/SJ+HPK7vt
cY7+If3D+AvKbhCcp/+C/nH8qL5GX4NL9J36TvyU3qsP4VL9oH4QV+mH9T/AX9OP6kfx1/Vj+tdx
jf6H+pP4qH5C/2P8vP4j/cf424And3ALYMg/4WOJ30/8PjbCwojAJsODhgdxl+FFw4vYDAjqLtwN
eCkJ25QVL/YCFvosFmCV+yAOwir3IRwiHyEfwWHAPJ/Hg8rKFn8P1rQFeIh8jPwm/gHgjWa8SL5I
voiXyJfIl/AvyFfIV/A58jXyNfyesubE52G1GcC/JMNkGG+T3ydH8R/IMXIM/5E8Tp7E18kJcgLf
JN8gJ/H/IqfIn+I/k2+Rb+G/km+TCwQiF8l3iEhl1zsRTS6Ty8Qd5Cq5S8SQN8k/Ew+Rf0mKIB5R
9icQuUlPJj1L/EPSV5O+ShxOei7p68Rjyg4EojipLqmBeCKpMamZKE1qSXqJeDbp5aSXieeSXklq
J6r2PbOvHLQbE5WwblNQyn4UhRC7/X9f2CC0CzZBFo4L54RdkRDTxFKxWWwTzeK4c1q8KN4WL0qJ
0gGXLB1yRUuVUo1UJ7VAnl7Ic0o4Jx4Uq8UGSO0ULeKG2MCZpCzpkDgF3w1KrFK2NCyNCeekFjFN
WoSy2wSTUrJzP5Q9JN4WLkPJ69IWlLsj3ZDc0glpzj3lqpI25WjIzQk2OVsuEc7J5cIluUlu5yA3
tPHTvLJLltfkbalGGPTH+JP9af4M/0F/jv+wnOcvlYvkGfkUpIf+yJwsy/N+Qr4gbsiXob5lOVPY
lVPldHFDuCVekQpdsrvD3SGeF3iBkwaEEWFQOOU6I0wKF8SrwhpwJl7UibViBXBmAviyIV6XYqX9
UqfSfpcMJZRJjdIxYVu4JvUIM8I8tK9ZnBUXxBjxovp8WMx3FAuXxBXxJvDvHPRtUKSlXDEZ6jsi
mICTbVKClCLVQe98YkCKlBLFDLED0o6IOcIZcVQ8C5/Fgixr5DiZlJakVUmUTkt7UkialpHc6s+X
j8sFcp5cBZxqlXtlk2yDEiqkMnkEck1KdfIl+Zp8zh/v1wEnB+VBsVRucmzITWKaP0bmhV5/sbAt
brjioJRb8q6/wl8tH5XruXmxQ4yRzwhrwMshmBmw9iHtI+r/YTwJc8N9cPcgOgBWPwsoBWUD3Ye+
CJSKHgO6H5Wgp1AaegZoP3oWVaDPom8APaCeBZaBmoAeRC1AB1AH0EPIggZQJj6BT6BHiBTiUZRF
fJE4hEpVf3IZ4SH8YOODxCmw3xPEG6iVmCKm0DFimphGr8Ca/i3UTrxNLKDXoiKiIlBX1B1RdyBz
1J1Rd6LuqLui7kI9UXdH3Y2+G3VP1D2oN0ofpUd9UY9HPY4smn/R/Avq15zUnEQD6s5Zq9agTUI2
bYvWixjt97TfQz/SDmuH0YT2n7Wj6F+1Y9rj6A31fJ8p7bR2Bv1EPcdnRrugPY/e1H6k/Qid1Rl0
96N3dbd1t9EF5fg19Cs9oSfQih7+oQ/0pJ5Eq7BuvoR+rf9Qv4l+q66A/z3x84mfR5fUte/v1PXo
hsFj8KAP1fXopuFtw2/QR4bfGjbQbcNHho9wpOH3ht/jKMN/GP4DRxs+MXyC71A8ijjGsEsS+M59
ZfvKcCJYgiNEuWoJEpUYEtuGcmEDFyvU2UcBE7DMulDHzvBlfIuwxKx7RoUtUQP4UMMtejMBMZeI
VYCD6tl0sYmLZTX2Ua4GcPEYXyYsMuuOKg6wkpjKbCophS2uRiwQ25WyPQ3MDYEVm9gZUQNpl1ik
ljwC5SaI2b7zYhET8m4DnpkUZ0QTYG9elAHZwPoBcrcIdcyWuAb1TAtucVtBXp5RpSQlr31ULALs
0yDWc26pQzIDWSSa2XNkAwJaFC9I+Ww6s6n0B1BbsnRYWJYqRI1Uy4REDd3ArHOFXJmoYdYBpZVD
qxFg/zihUWhh9uyjau86hRZHnqgR3ApnhBCfpbRf2FT5ki4i+3lmU2m/WMQdAloEvmQJotjKTAs9
wqqwLuwIN+wrUIPyPC2cFvOgD9FiJiBulou1j0LNRbRZqBNLWCSwfIu9mVtk09kZ+237bTGbWwS0
tiw2gWxOCAPAsz1Ap3NKyxQCxJ4p9gp74rxos2eIZ8RtZk/MBl5VwWrEDZhyBng1CSuWNED1BxVO
QcnpgElLxTypg+sB1JjBl3GbkO4WpOrgVlkNcDULWrvFbEltYj2zx0WKl+23AePq7BapWHBLBAer
XkRoH4bR//ex///V2I9uvGNVGfv4NHoBIcvlv1//b19EjWeP1/S3DpTy846VgWrqPM9bb/BHvTkD
OQP5Xqc3wLd7RyFNNK/h07n2fo5fG6jmdyHFYW/pQA5/iVrxjTGDvjnfum9PiLYvCnlCiVAuHAWk
YWNm2Apmhs4FjDbD5AnRwjwglBG6EvIMM4PwuS5kQvoi4ahvi4ljZgATfZrSRq0II2yp2+fbTzl5
3nfA22xZopwD1b4sTyx/yUb6cu1LHtGW6lLrF86wGb51utK+yJRDeeVsvlK7cA1K3GUrfFtKrcIt
+DQxJZ69fs6X6J7ob/VV8gXe61B6ijvfsjNQPeCE3mts2dDjgLfNxw5keH39vM9tWfKJvpBvfz9y
5fFHqWIq0D9i4waKoeYTvjExhm3wrYtp9kLmAmCvasEErVDrZQahxjgxIMwAphpXMdpZ8bw4RHeK
K/ZFwGOtogX6C/xiegHt0cIu9H2GWfMd8VoGqm2pA6XWI779rl3fIesxyxJ/it/2NgutDOfNEWbs
J+wnmAKunU/tP8rbrCFo+S33bW8ONesd5ev5Kr6AzxwoHaj2DsFzujXXW+x2WpZBakO8yXOIn+R5
L8G3873eDB55872jXto6Zz3Ecx6RveI7IZzzTftOQ/8WfUu+TYbzjYFsNQIpFEBrqwCRg2TtlYBc
j/t2VO7OMDJj8m3SlfB8QzjjW1URNUjUtyxkU1fthVCW8u06tQJcqYccqcwgk0dtMGvQ+wKQ2ohw
QVhj24RLoEGTQpPQKsigN+kMaItvWkB0pHXOs2dthDYP8iP8BceKjQM9bQI9rfVarIXWSr7cE+sr
BG4V2mTg4qBvWrmg3Mv2I3QkrAUI3xZbwfNsBmDncl8jcKrNrRM3fDV8wUC19YitwHfM12ObtM18
qgNA275K70Ve4yvzlfGXfClW1rLjY935fDSMh3KbokU6W5U34Kvrb/e1+Dp50jdgbbSZxHxxnK1Q
cXyGvVAsFksFUqwQ0tkNplzsULViBLD2EKDvCXGKkWFNYwa+7oq1bKmQLo7TO75h+xHfDjMjxgN/
gLtQ2kVY/+TA+qeZzRCdoPHttnLqvGOFJx0+PhukXWSb5CddeTAqVkG2s9YU/gx/uX/Eu+Kd8KYN
jHtjvPHeZG8zf9Rm81Z7fb5IkPk4Xz6QAyNa452y7PAz8KbBW8vLvGwNuUv5OGulLd2VB+Wl8yWO
Yu+CtbI/z3vWe961a92hAvw1t4+P88XCuKn2XvResWV7r3rbgDq8N7237Vu+BBhDibamAad3w93h
S/Ga+XNuny0OxpzOe9BbwefxrdD2Qf6465r3OpTVpFgg6rxifdwrMALB6oBWp4PMC/g86xzYmqMD
TmEXEMGX8QSeQAhP4kmE8TSeRgSexbMoAv8M/wxF4nfwOygKv4vfRdH4PfweugO/j99HMfgD/AG6
E/8G/wbF4g28ge4iaIJGcQRLsOjuiKyILBQf+Xrk6+ieyB9G/gglRE5GTiJD5ErkRURGrkeuo/sj
NyI3UVrklcgt9NnITyI/QRmRN2Cx+6DmNc1rKFdj1BjRP2i6NF0oT9Ot6UaPar6r+S7K1/Rp+tAX
Nf2afnRIY9VY0Zc0lIZCBdrHtI+hL2uf0z6HDmu/pv0aekxbo61Bhdqj2qPoK9pabS0q0tZp69Dj
2nptPSrWNmgb0BPaRm0jOqL9jvY76En9T/U/RSX6N/Vvoqf0b+nfQqX6t/Vvo6f1P9P/DJXp/03/
b+gZ/Tv6d1C5/uf6n6Nn9e/q30MV+l/qL6KvJc8lz6FvJs8nz6OG5IXkBfSt5MXkRdSYfCb5DPp2
8tnks6hp3+f2ZaPv/N1v93e/3d/9dv9T/XbRLdHtf1utv5ajXBEPccuWFVuNZcWBHBoz7ci2jPe7
+2842h29tkaLxXG875bxoDXGccrodMw45tl0c3x3C7wvsExBqvq+a7ZGB2eNgTcjrmXHmf4ex5o5
2dHq1jhu9Q87451p7qPudlOhe8Q97yjpWnMSRp2HcJCeeGOao5dac6w5bhkDzhh3uTOj75pT1+2G
tLxjmxnrSnVWuBqNFZ4MS4On2HzTlMXXuc/xByyz1hV+wJPhqOKH+bHuOrOFvmhK5E/wp6l06jJ/
xLNgS3AtWmb5Tv6YJ4N3my2eBcsEnUHnc8t9tyzn2XTTojnekU1blJ46p5wTjl5TJ21xLtBD3dPW
GOOVgQLHvPWw87zTZ6adE92xfbvmK86LbpPzKnXL42Na6Hxnbd9kV2rfNU/A2UEN0rdNhQ7kGWfb
u7K7bJ4J53XPlPO2Z1ZpveWmecJTPHCJr7MNcOv8AWpQab0pEVq2aGkw6syWvknbfmh7L7/ELdN0
3y1XomnRdcB82JU7kOk6BK3L/rRtthpXp4u1HrZ2mEIu0dpm7ehqd4XMN7vSHXmuMdd+Vw8Vx6Za
xl1HXDWuAUccbWHTXcudk8aAZcqczBZ0rXmueK5Sg3wkH2sq9DjdI/095mSPzjXtIPkDfJYpgenp
KudzHVVsJn+IL2TGbNNdx/uHPbf5RMctc765w5LPLLkaLbXGCnrIU0wv8OvcKn+MaoIe1XkyvMjS
YEoxW7wkc5o/7W73ZnqzO2e8ed4C45C3xEn0u43FtLm7jlvvj7TFeuOMHZAn1dFK15orjFecNz3n
jWbPqOW8Z8W54Yp0XnHFes6aLVRm95hpzEF2TtoSqTP0St+u6YA1zbPQP2eZpdK5dcdI13HQXgsd
z2317doau1nQ4fSuo4psHSbQTZ5ZsqzQo4pkHZPmDGYTZB/tiLNNczvcDcsQ6L2t+7QjVX2qdpQ4
Bs2HHTK3bKtxHIUcmTTtOMWtmqbZdEe2o8nRZJp25DmquE1HkeMM0AUmkd5w94L+zjjjQX873IPO
UrbXWOtJNqa547pr+jedh+lZ1w23pn/Tk8ZUOg92H3CfYQbohi7efc6jo1fc2U6Lbcwy4aShPBgN
XWt9267l/kPOZPct145j0p1H9dKlllp+2phjrvAssMiUwFfS560bTCVfY3IrY4LvAX0S2VZHifmi
+5a5g6kxpVCXqctdp7p4cwxfxu31H3K08qytUPFecXt8o6OcD9HFjmhXo+20aQzG0E3g0kWP0zJF
pbsWrVcdI05Ld51p2tjsqoS6W4w5tkrg1TnXDjXouERtu/Yc1xy77nQY9WXONseIu8nc4anltsz5
3cco5Ea2GkUuXceds86znnHPgjIKPUOuBE+GJ8OYo1x9kzCmO7sHTDX8MnAu4Bx1rDlr6XF+Dsbe
kHPcuWK+aZl1pbiyLEP9B5wb9JCrzjLlaunaBbK5xL5roIvjrjLHue4W17Ajmra43K4TrtPG665C
V6XrGLfVzYI8W90XLCtskee6a9G1yC3RbeZRd7o7nc5h5lxznovA9V5q243MHfx+esq15Nnw3OQT
zMl8imvPtW6Z8EZbxvlVftO16C6n44ETN7q2wc6kGw+6Vr1F/B6M6SPmob4LoMvpth1vufkKv8Xv
0LVejXWDTnOtutZpwnjQPNu1Zlrqm3STdIXnoLvASTBjluvOHHcrPe6p9uQ4m81D5oPuC8YKptLT
5l7zxDjNHrM72nzW2WYac205ncYAswpWo9RdZVlxVjtrlW8clwcKurPcl5z5zgzbOpXqLvLkmxJc
m2Bz4t15likYo9fdJU4LTXsqHK0ggcNum9Hp5twyc8NUaIIR7mnwNHeVs3Huy+5tZzG17enwWOhk
s0+xrh4abESerY4adF9zXKAG+665690m9ykYV0VsL9vqTnVnOhtoemDQfZy+6N516tyT9BDYZ+X/
hojINyNnYZb5NSBGZf9KPOC+O9EBoCTVo5es+vL2oaeAUlRf3n2qLy9V9eWlqb68z6hevP2oHznQ
Z5ELSSgL+QGDPgoI9HX0ZXQK/QgdRnNAhYBAz6KvqBj0cfXXMIrRL9EyekLFo0+qeLRExaNPqSft
luJIHI/KcAKgz6/jTECf31FxZ7OKOF/ATwPibFER54sq4mxVEWebijhfVrHmMWwFlPkKPgEo81XV
q/ia6lX0EgWAMgVAmU8DInyGqEAjRCVgyjEVU54kPIQPvUOIhB+9q/oc31N9jh+pPsePVW/jFjFP
nEF/IM4C7rwOuHMT7SqIE8cpiBPfTWwT2/gewJ1/xAnEDeLPWEv8JQLhfYA478b3R9wTYcAPK7gT
5yq4E+criBN/MeKhiIdxQcRyxDJ+LApHReHCqDuiYvATUXdF3YufjNJGaXF5lD7KgJ9VfJe4UsGd
+DnFg4mrFA8m/pqCPnG1gj7x1xX0iWsU9In/EXBnMj6qTdGm4H9STv/EtdoWbQf+hrZT242btd/V
WnGbltJ68WuKxxMPKL5ObFV8nZhSfJ2YVX67ANu1C9p3Mad9T3se+xRfJxZ1Bl0SlnT7dCk4oEvV
PYBDgGgP4hFdli4bv67L0eXicV2e7hA+qSBafFpBtPgN5eRKPKkgWvxjXb2uHk8pZ03inyjnS+Jp
3Su6dvym8stE+C1dl64Xv62z6Cz4HZ1NZ8NndLBcxT9XMC4+q1vWvY/fVU5gxL/Qrep+j9/Tfay7
iv9dt6O7gT/S7eoJvK3i3T8pp8Xjm4B0k/CeinH/opwEj28Duj2E/6o/rH+cuENBt8TdgG4FIl4v
6WXiXn1AP0ho9UP6HxKkcoofka4/qT9JPKD/V/2PiQzFh0s8rP9Qv0N8DtDtfxFfVmIaiSLFn0s8
rvhziWLFn0s8oaBe4oiCeoknFdRLlCiol3hK8fMSpYqfl3ha8fMSZYZ5wwLxjBJ5SFQYfm54j/iq
YdnwPlGjRBsSRw0fGH5N/JMScU7UGS4ZLhHPGzYMG0S94hEmvql4hIkGxSNMfEvxCBONhpuGPxPf
NvyFxMQLgLCjiTYlqpBoV6LGiVeVeHHCSN5L3kuYSB2pJ7qUSEKim0wi9xE9ZDqZTvQp+JuwKPib
6FfwNzGg4G/CShaQjxE28ivkEwSr7EQhXEq8H+Ely8nnCJ8S40cEyBryH4mgEt1HhMlvkM8Tg0pc
H/F9BaMTwwpGJ36gYHRiRMHoxD+TFtJKjJIUaSeOkw5SIE6SEhkkpgCvDxJvkkPk94m3yBHydeJt
8ofkCeIdQOpTxLvkTwGdvwfofIn4NXkO0PklFZ1vkBfIVeJDco38kLhCfgTo/Bqg87KIe5PKk56N
2Afo/OsR9ylnwEekK6f4RTywr2xfOaz7MHIi8W/4+4XT6nW3+rtImWAT88CaFaMyVImOonrUjNoQ
QbX056MIqpEapqbhqbY1Dj6rqVl4V9GXQ43DUwk1A09FVC/8JV6opQ6hiBeqqVzqGHx3kArAdxlU
A0XDUyrVCk8kVQV//2ahsXoeNUI4cjlyQ21dqnI64Au6//MianoSqE7zPDVN3aBijSTVSBd17r3c
QNd3L1BL9KRpiFoy7kKaFiVVN20kXz5oJOk4SNFO93YvmGXmLHORuc5GsvvZQvYI28j2sG5WZIfZ
OXaJ3bLH2dPt2fY8e5G9hDlvr7c32VvtJsizAnliIU8LpGch9Ql2jN1i9z5NCTlj7al2nsmw7r54
9LWzNou1yDTLQM1MTmdi/2FTdfcGc5g+05XIFCv12yftM+x+uwlq34LyRPsZpXb7BXhassexh6DM
OPtlqHvbfq0ngV7rvUnFmueZBmqMaXtx+9VhhqYvQ9lpII9OZpRaMg0xFUbSwlm43glm1nqri2UW
jKR5pIt9uYGxMD4mjU5lJqDmq8xFLp7Tsfu5ZDaXy+EOc7VQc+On9TLX7UXcLHfW3sRdZEVuA+gK
d9XOcTe5245Iex43xGbZ8xR+cW2cmRtll7gpdotbYKrbto1kf3VrMVPB5LemMaVMqZHsG6ZJmmN3
7OV0vb2IXWZX2eVumhqg06lVuuBlgs4zT9JN9Ixxt7+0NYM6QbmpaSPZdcC4a56nNbSJLqF6Xm4w
7nafNc+3jtJFLy1TS9QyXQX8aDXu0qdaq6nT1Dp9hrnCQBuZ28xNkE8Cc5U9wN5gs0C2lWwNO6Bw
l11UJYvsGpBRr8rdIvtRe5W9HSSQy+babWwKO81usmXAh0S2007C23V7NHy7H3h2nR2G9tcxG4pG
gAa47ZmgIa122T5oH7EfZxvtBexp9jRILBs4GQJtuQ21H4P2iVSIWmodtSA6moqlUzv3GIKu712g
R+hBaqm/tDOxNU2hrgR2i7kOPYALpF9oX7Pfsp/jCC7Gfum1s/ZT9nn7LtMBeRqp0yaz7Sw1Rm2a
eVtzfzMTYIbogk91AEhkxm1Xu6uZWqaWin11+EVe1RIaxoLYX0qnghadZqZMQy+lMM2MmXF29XQd
oUI9sVy+nbPHcfH2GS4NtKKYqwC9qGYbQZ18HK1oBfS2lTvPTYCmktx1zsk52R6ulGvgKqDHIjvH
rADPc0EX4oFWQG85RyyXwR3kmrkOLsCNs1ncYarOepxqfJHrSehLpMZapl8+3DpKzVHDZhu1abPQ
cdSe2da3Tu/S88b5rvWXEs2Z3cUm88sN3edb2+hJqse421XTX0qx9Bo1TF+iL5vM9Ha/jrZRW9QW
fY6+QB2zrXTth3EyY52kTvRl2YiuZUgRT1+jC9psdOZAGZVFZ/deN5JgD24xMUx817G2beARb91l
/jd73x/VVnbn956QKUsIy2KZyF6WsCzrEEIISwnDEMJgDcMwIMseLCRZtmUkPcm2DE9Pb7B+vN8/
JJmlLsuhLMsQQijrOBzqKsTLUEoppYRDOYTjZYnjUOIQSghLKIdQQhnCsrT33d1mmvY05/SP7Tnp
Gd/zJK707nv3x/d77+fz0X1fawKzof5QCnf08MLDTHmEt7zXH+2KIlIdfTVqaLJFrdFGkYqMiZWN
VGQ33E2XRAcjM8oMFMGU2UfxQGXWkQfBzNQTecKPNZro6VDnw8yWeSWahXpX/TMEUf8X9T6MbfGx
svmxsvmxsvn/pbKZMPFbmRC7TCOfR5AGy2/aEXeCG11hfAnvwnqc3Y5cZ/R+tpTmz3EM0lelfOLY
PinpMf39wybJFe/Na9pynZB9zlFxOLAqTjN6cQ0npUQpxTHozvT2EceBDMnfJEltUhGj9+IE5ugi
/O5C++KDzbDg0zVekDOkTn+PL7uxxDEeXpMRzEJMBu+CsxYpxPMs3EEmhPPYsnBJU4+7MGzy6eRU
z0tZC8r0ezz+Nl9Z+IXPGkmx15GZkSynSuqRk5zdstG3gFtdWmwd4I9cMkoU+ZKiRnDNHu8RXkyU
+p9EW70lpArb9eaR5eQQWWmvImyRgyhYpR0bsjZgjVZHDUSPva0pLRqkd6ID2K5kizY4NuxVLium
V/rHMULWgP4ZdUaJ4/vZ/hzfktI7jj3iGHtln8SOmySiqHHUddI0ho+AT9PkoCvcuBZaZGz4odxK
+CMe34YrSW6PEM5TrIXO9C0QLREGfNLlGCc7wmt4QziP7PbkR1rkRskvD+A6pU1Ejys3qiVsRBF+
4ktydEW1Sosc7USpY8r/xN6G7Tp68V6y0ntkPwa1nHKFyZvyLNYTGHAMeEe5BM5EX1VqrNQRX2qS
HNtNY2D8nrPbTVtNu95mIg2U2g5fYLftpd5mb9RepYy9vO197JsNJ3vziGPfEoGRNQ8E13Kkx75I
jhL9pIk4IPtc8fY6x7hjL7xG+LHOcEc40/PMMWifdLT6Dh0N5D7WGdklT+27TWnhi009xKQy8mCM
TtyZkXXsGbYbbMZ2fQvObtxKdoO1Xesro02uQ2bXMeU9Ior+rn1gRHcxxvucrMSe+HT0Y3pIPqEf
EUwQJ/JB3WaIHJ+OVCljzexiHu/zh8nYLlH6UPVgk3gZ6ieK5F5ySB6xH4Sfy+FIp2Mk7JA5eZCs
kWPOoYhkL5IziGN3pt1D+O354SEmHev3GXwLvg1vocRE0qKD9gOpwn7gHIq68ZNw3/1iccI1Rb6w
t+FLjN5vIzuIUqkOLxZ3HLnifqBLsQonpXiMZCFSJMJepViFJPnzHdvkTefoA+FB1FctPhdfSOlS
Fj4rlQa2Jb2SDwxIasnmGJCq/ClSp7gijopzjkGp5cFjLM0V71sSN6U0CXvQTfaJp9g8Nu8Ylzzi
kV3vfOyIefscXSDFk5v4CfCTSWmS2Ao/kjo9HqJFehpekQ0Aq6Q588Im4FlUGCf6pWeyzn9AtIWF
8HPpWaRU6vctRPThq3JxeCKS4xoI70v94eaIhXgVvilnh4dlxOcOd0jHDyrD3f4KrO5+bgBxdLkL
gW8m+YIeLFwYSW/qcbRHqhwxrM7ZR+x6jygwso4RYsyT79jwzbpOHgi+atwaLbDvRotDVYol+4F/
EaVRjsiJ9rqMiiVHY74lbJ5oA9be4xgAdp8azItapZxoYzATmwdcDuQDgzQeDfuCkXVwpfFoRuQ4
mkRg0REf6QKsz74YzY4ao+34ib0qWI5Z/On3R6JlwWaizbdx/zDaRWR5C6NTxJgrKaoDXlgnPSVr
8BPC5pwD4Cw+3OFP9yG+ePBaHJ7GdsNHxLw0Ly1G0hxTvg2p02cI38WXlNG3t/lmnaPhtUibvSjS
Ft6UR4hSlxZcFxzAH4POIYcWML/j6IL/iWPcrmeqIn5XLkCLu7jV+9irkZdxI8E4BuWpwKC8gLeT
wM/wQfHIuyOfMADFSpKvWumvcALZwW6zrYFVwDGz5dXgBXkP7w1r8MEA+PuBQBzL4/K4OI0fYnrH
qv+JvBS84Ariqz4jXixvRJ4STGTm4cWHmeREBNTDOUQcyCcYQa558l0ZCrOKvIy8dPZRXWQ58JsD
cFa/nAQY1iRg2ltkRwBhywhb+C62CxByXuSV5xm5Any20fnCXkSuEAy56ZwLz3kT7JP+JyF/dIlZ
j25gBAb+gRkny3+AtWA90ZNozF4FZtvFKBKxgVYt0c3RQ19SZD3UH92LPH0I+iKKgJr1AFtYiC4/
TCAryRqq2D6GpYT6fUZyxTkH7GYbe+YubCwJl98/JDqJfgLMDOHhcNSTjzcA61wC45h5v1EuE6cd
reHR8BzwhhJSIzf6wpglkhg+BXVec7SHm6WX0quIWlqXtiL5hMdnCB1EKiJ14bsunX8LWHtlIB70
qd+3YK+Tc2UDmSBb5XjlO9+eNEZfdQ2KO3KDb0qaIU3eZJkkyyW9pLdXMUUEIXWC1u5GbEQL8TT8
OII5R+09ZB5ZiFuxOtcJGI9DgiBxMF+OkwkEY88nr/qWQFqWqwmbt9ujB616BmbafsLm2PM68GWy
z7cKWlEDbLEAPwxvEv20ydfuXCN6gJ/qZDew0yTZSprwQ6lHeipNhh/JBdK8Lzs8Hd4JH4GW7oav
RooiFWSzu1B6EjbdXw47iB45NVwjHTi6ws3YK8eeYwpwkBT0FfoKQdAfoT9CUPWw+i8AcxlVjyPx
6kn1PPIJ9aL6u4hW/QP1D5B09Q/VP0J+T/1j9QaSqf6pegfJAhxnF7mY+jD1IfKZs18+W47knDWf
NSO5Z91n3cjnzt47ew/JA/fo/QfaWduL5ELe9DZgTd8EpRXepIea/GVkFplDDJA9vQs1+TqoyV+D
TKoeMikTZFJmyKQsyE8Bk7oOmdRNyKRuASb1acQGORQNORQLORQHORQPOZQAOZQIOZQMOVQYcqgo
5FAPIYdqgRzqjyGHaoUc6p9A3b4N6vbtULd/qioD/CgG+dF34J7gH0N9fkfR51GVos+j8cqeYPQf
KSo9mqD6d6rvoJ9Q9HlUC3jTX6P5UJkvVO2odtB/DPX5ItXP4xD0NYUxoW9BTf4G1ORvK4wJbYDK
vF1hTCgGlfm7Z9Azn0LvQQVegAq8qPAjVII6vAx1+DDU4SNQh49CHf4h1OFbzp49ew7947OfOpuB
PlJ2GKOdUG+fUHYYo/8Wqu6TUHWfgqr7t5UdxuiMssMY/Q/KDmN0Dqru39N8SlOKvoSK+jFU1P9G
YVLoCdTV/xbq6qea2xo7+t8UPqVSae5pOFWcoqKrzisquuqCoqKrflfTqelUpSusSvV7msVzKlWG
wqFU7yocSlWnaOaqa4pmrqpX2JPKorAn1XWFPaluKuxJdUthTyocKudewJ4+UBFQFf9TqIq/rzAj
1TegHh6Devg3oR4+DPXwb0E9/BnUw/8C6uEjUA//AOrho1AP/1fKvmfVmLLvWfVdqHL/R6hyr0CV
+wdQ5X6l7HtW/fBTh9p01SrgVtlxZxRuFZekcKu4TyrcKi5Z4VZxv61wq7gUwK3scb+jsKq41xVW
FfeGwqriKhRWFXdJYVVxOoVVxb2p5c7HxVUC7nMlbh6wHjLu+1Al/gWCoiVo70dc5tqj37jj1yra
eDdVg8ThHfU68K7CW+tLwWuYMoDPOEKiykDOfz8d5AjTAb6FqO7OUeUg5zBtgncVbqVyQc5Yr6a0
IKd3joBclWke7/l/NI/+Ui0/s3vm6KNn4N7d/F8P1U9oKdR+vzk0SI/dO2C0oW1btaeASqAymcZb
iZiBmQLHMqthM2+p2WY2ynaw3VgxLdE995vvFb23TY+F9mzVoEwj00BdpMopE4YwXcwIqwkt3Upk
89iSW+o7e57VUBc/yE/xy/y2kCCUCJWCSWgWHgndwmNhTngh7IvpwpBYIdaJFtEjtohtYqfYIz4B
ZcZBmT1QxgHOj4KzR4Uh4UhMBGfaRI/wgt8Ti8QZWxm1Tx1xHlrNEY2LTVo6kU7Bxjk/nc5JXBud
xXXeI5R6NC5is84qrofO4frpIk65/pS4Lu4KCeITwSQeg3t0S4hSIylJ2Je0oFYXRYuUIWWLnVKu
VADarZef25boTnqMe0XvcgfccT3Jp/JazHDLwkzdbzZNs910HdtxK5FvNI5h2XyQ5/gw38738gP1
DbSFL2Y1Sg/bevnc0F5TA21jwryRxkBNlvgpySoFhQSJEzKlXmlQWgA1Mf1dPfhl0SKXyyaxU74r
N8tR+ZFokzvkbnlIHpUnJFLOlDVindKn0oZ0KF+UcblEOJKv3jugTuk0Op+b5xiu89oRt0iX0hXc
jLHils1TwD3lxmimsZPhGiuEU5FgM0WLsALSmq36ZneoS0lN2ve2md57B8A6dMwSlUyVUEOe1Yb5
UO/tSjaTotg+dvjaGhPPToRGPI1YOz3PgN4IjbCPQzFqGNjKGJV3L4ctpB7ZM+inrAYrYIrpSUrF
WIFlrbLdnmVqlCmjXlAr1Bq1Gep6b7sJWCGroa7SLezF0CF1AStmKU8Gk8pUsy/4BX5JnOQ3FKvg
D/kTQSOqhQvQomoEQaCART0H9nQkpog5ol58powfSJLIiP3iUyFPKBTHBBWwpB0uTdgHf+FivpAp
bIppwAIS+Bi/KgyLmHCVnxX9/IiQLHSIpWIVsMV5cVF8CcqZQC9PCNNillgh3BT6gI1uCOXC3VCv
JyM0aI81WelFet1R6T1gckMnjKGplap0YrcSmTCzzGXdpYBPZLKmxs7GRVZwrN1SWwq4Z9wk10JX
CUegTRtSmaSTMsQtKVWqluIlg2Tkl5u04ivxQCrmDvjWW4nyivyCW6d3eYTapD18Ep/B4lwnX6DY
Hl/NG3irY4UneTK0zb3kXvLx1/YZI6/lG/lUmqB7+C7HGhO2LckrfAPvBl7v57a43VtVfDZfxuvo
9bvJ0oD8WE6W3GKLFJZapZg0Lk1Js8JN0S8nSCfQDivlGvmmXChTsiD3ySpZJTRLI9KStC3clJul
eH5cHgY9fSQ1SI3AXh3ytDwntUtd0qq0J1+Q84QL0jLd1mQAXvSEnqFf0rv0AX3MWJs4dp+da9Le
egn81EDVUIXUzfpY4xNbtbHoVj/7nIqyCRTOJjMbzB5zwhWBOWY5tMqqbr2838xWso+oaU4PbGXI
sUZ13N+kHtPPqB12jd5ij9hTzMi4bzHelMYnVDfVF5oKjYdm2av38ptibM2DTspB3aWeU3N3Yndi
7MrtcrqfMdbrbj5mN9kdBjFWYEYu8d4Bl4I1eFaNWcwgM8DEmHGujmll2rk0LofLx7g7q+xN1kE1
cxVc1U2Ks1AT7LS5n7PdsnDpHFZPsndDA/ZYaIEhmSCzwGwzh+wFtpwdZbKZAkrg1IyRmeVKWTzU
HhoEvpZBaf5uDgbngvk3tAFm3w5l5m0y2GP0GA0sgH4FZpIM59NbaibplkXSKvO++jvqv4TPpz5A
ZESJvq6g3gsQ9aZD1PtpiHozIer9fYh6syHq/UOIei9C1JsDUe9nIerNhaj3cxD15kHU+wWIegsg
6v0jiHoNEPVehaj3XYh66yDqvQZRrxGiXhNEvWaIeq9D1GuFqPcGRL03Ieq9BVGvDf5yYFd9GSBd
B0S6nOrbqu8gXXCXydcUFIt8oKBY5F8rKBYZV1As8m8UFItMQt1/Aer+61D334S6/19D3X8L6v7/
WUGxyM8AilUhe2fUZ+KRffgbwH+FvwEcwt8APjyTfCYZOTqTckaD/AL+EnAKkS4CkS4K0a0Kots4
iG7VEN2eUX4JQOPPXgDoNkGTCRDqJyFCzYEI9bMQoeZChPo5iFDzIEL9vIJQ0QIFoaJ/BPd5vA33
eVTDfR7vKAgVrYG7PWo1i5q/RfVQ8aeg4k9DxZ+Bij8LFX8OKv48VPwFqPiLUPGXoOIfgYp/FCr+
fwYV/24Fs6Lvn/vxuV10Eur481DH/yuo4y9BHf+7UMd/oY3TpqPfU/Al+jOo3R9C7f5DqN0fQe3+
F1C7P1bwJfo3Cr5U/QHc6/BZuNchF+51+Bzc65Cn4EvV5xV8qcpX8KVqRMGXqn8PtfIfA8zSjQx8
hFzeyfvfjl+L38yJdCISZ84yTNIpiOrBMJ0MXodoDRJn2qNV1AnI9dJaJO5BF3UA3lWmFToN5FrA
nJoGvhOoPZCjHMvUKvjuFTUDco3UPLX+Kz72S5SVoEnIhXW9gAAjrBb+xxF34jqm1qkt6vh2Dp1r
Gb7MOFroRpqkc+l2updesCL0kqOfPsESGgawGuYik2efcCyC+7yidh2TtJauphtoN53rkBoQeoFe
ZlRYAnOBHnBMOttvCNcqsE1rkrWAaeYvWmPWQ+aFO9Ux5sIwytTC93n2TR7DUu3qjUJXqTvbkswX
mt3cBrbC7TGV1qSmIWuMmQNlnptarBlG8vIrQy//yMXwo9RLJnp5kX/Ov+Cbb79kyoXFO5nCllt7
R2M9cSxahq/Ni9XOaveyaDUa7AmuTq7dGjM3iFMNMaxS3GY7b0y7e4WXbrewi02L8WarWCbq3MuG
6uvHYlhsFcfFKXFZdGPT2E2mRIT9Q04ZDbdzHIuXGXoB9A9JvVR6pyFGL7CYFakfxhIsQyzB5LF+
R4+h2LDM1hkaWBvrYVvcXZ4dtlNIdHXWzLM9QorrmSXPued4Zi0Qsty9uN7U4h4Q8htiQtGNq+6Y
UMpmCRXsE/eI0iZX4vXSOxp3r2XYnnBt3lltnVVaJF2wJxgNrk5RK065OvF1ttOw6hx0HbtaqHVL
Cbt4O4d9WV+CmZxhppJuV2qs1JHawhKu53BhJo/rMhRwg1yMG+HGTZMNGdwUN8vOcw3uKZfa0cIt
cFqugHPTQS5IL3DcDcEdc1fb7gp11gL3kivNvVprvZbiPnQbQc3b+T5s846GL+SWLcnCM1PL7WNh
3pZ5J8/ZaDm6UwjGLZVbtRwZluDI791RWWPCWAPiaruTaakRFs3BO5meOankjkYqF1MlEzYh4aJV
aa3SPmFLnGJz7ktsp7TirLYPS5vSjrR/vUI6kk7tE+YGacKMmBuUsZaiUp/TILql5/aE24lMs7Ud
o8B49LtnhXR6gY+ybYKezhWqLh/gLdcP2KfuKbattp15QS+4x93jdK6phXnhecxoXC2uY8O2uMok
NK2Is/Q4PWWbs2eKjfZMZo5p1jtcLaZJ4ClbwO4RVwudTS/Ul9AFlmG62DakWAXdpXgMvQpKHrrU
ilUwCUwmk9mw51j0PHK2Xs6n4+kkmqPD9CAdM1vpJZg30gZ6A1xp1q1lCmkttQj8PZdJvhGl1hsG
gKVlAH/cdvTbJ2idOWgOAo/co8voIFNIbVlPrlVcq7AmWWqsSXwH08w0u6r4IXeqkbQW8ALfzQxb
s/mJ2lV+zexujPGZrnTmJqtmU7BT/iIfZW7ym0yNm+OPmoaYHf4uP+cao1e5E36U37lRwid7Vvir
nv3LFXwhM3TjkSWBza8N2gR7t3JH4JsThiUjyW3z08w0s8bvm7drZ11ZLr27WFg3B69XYKfCFjYt
HJuDlhXLphkRMxyLYrZRp1iy2CC67Qliu9grjhhyFUsWF8SNy/31ee5eMVVMdWaLCJ0qGulWMUiP
uJ6KHMwX01ZxAHxPil3inhgvvBIOgJcvGbou50PfThKrxUFr7Ma0pLphYo6kBLHA3HBZfVkNvCUm
5ooG8RA7tZ7cGHLV1c4yJnLDueBSuxKZYWaUL9Rr9JrbBHPk8vO4q63J5CaZR0xH04qt0J3qTnKV
NsaUsVcSa3FrhfzadiUJOewzewJoqdLaU1en9eS23pxrzrifJV10k2wpW8UyQpqULGmkTLaC1bMS
u2uatCLAUyfZV+w6e+DocYY5hC6jZrhqTscZOKt9wj7BtXIk12sosDi4Yq7M0cIec0lcNl3GDXAZ
1Ct6wfMI+PUYO8O1M3mmSW6J3fLOcqlcLmfkGutLuHiBcCfxfa4s3iTYBEzwWxHHM+ey0HInQeh0
PRV6hH6+kC8UngpPhEnrrDXmXhAsPC4wjbNCmzAjSI4xbMWlboy52uREOaVxxJJsTXKH9Y8Ej3vb
fWLZsYy6Etk06eb1Clcn8OFCqVKqkRyWUWzCrhFzpcfScC0ijYoLN6ZvTLPr0py05lyyCMaYNHRt
XrorNUsd4Kw16ZHbbdkUU+0JUh5IL9jO6xWyGiuRrkqC1G1qkabNiERhz51a7AV3eEOwRV1pNTmG
GH+VGXalXD/gy4EdDjv3rlUx+8wp7+Bv8tRtvdvtLmCzzAXmAraHH77eYx0xb/OjTDfT14gwUaa5
acWd7SrFdvgd/rQxdi3dWmzI5lVskbvalQIs0Mg84k1uq2efGVW+Y+4yDgZvCF9j2DTXASPoa27n
1CJsDl/JV7rL3DpsDau0dGCUNdeZ7UrnawT19Qq3tYFzN7ieXj5w9dgnsD5Xv81hagEzZqM76OYs
awZrLeJG2ESn2x02F19PMQ9aBNtdd6u73ZltmwPza/yNwveSGcpF2Kf5x65J/XPXvP6oYRt4bQmb
XrvtsjEJ1kEwX5QzJrC25jErzCYj8Djf12QCLX0MxnaF3+E2iIvM1aYhXsNfoLXMHJ/ADPEvvEks
5m43GgA6iFPvqfcQRP1z9c8R9Oyls5fg7p6PFe6PFe6PFe7fCIUbaQce9UtUXzb0y+PXMo9qVSAb
iavrxFfBu+rtA/wleN01T4HPBHw+ANjF22uWVpAj8QnCiKhsY4FUJI7QB1IDgIe8PeMbA9+Z8H7/
PqKqM5jrQK4a7/Bv/x9nlF+ykLi7ceRHO6O/dPw/H+jj6wRuwW04UdeH9+svVuzXn1Zv41t4vzfe
m+rVXfZ7daY0L2nmjFrzlLfXO1BfaKoCZepwm6kIlJmsPyXL8P76o2vgTK/BQilnelNNReb4QEog
PWALPA2MBeYDLwPrgRyQV3Izga3AcTAp4A8QQWsgxRtT6uAufnumrs9UVbHv1dWfghrolRoYs706
YuWy/52LZk6fSWx6B4gdU8qlpzoDMXfpJfGCWCNOgyPB8eBscCFYEFwKksHVoCG4fZ2wnOKW2lhI
Vdfn01fHzAumY++4N165unI93Aau1+c79g6ELl56QmaAlEsW1BRd6ySLybLgie+ltdhCKX3ha/M9
8b1yWEKZXp3vIPAqlBcqNDTWRQNPr/lDJQFbcCq4rM8Mbnh11gy8/5InuHfZcz2nLurV4f22C95W
M+ct8BfWlQdsbyxbTmuKcJt/2lSE+0H9ery66hgY0TWjsS5TabM3Senz6/neAjzRQiltBqW7vF1G
t6nKpjIjFY/9z3HJv+Pf9x/5T2sWwT0YXMLn8Zl326tjgcTrbaaquj7/hH8O7zdzhhPcYtTiev9K
9fa1Y1NafWHFfs1uze5lvynNv+mwmKpwm4EEo6SMkzJSNjBKx0Ey0B/UBaqCGcHcQFUgPxgM7AaN
gcVADyAnvcGBQEtwEJZ4CtJx4Fnglf+FNz6gxlvwxUAa+LwoUBroDzwJTAaRABOQgG3BRDy/3hY8
JIaJCWKfGCWmiaNQck3RZX9tTP8olFAde/fElGI69vn9m3hp6IJvTBmh+sL6wms2/6N32y89qV32
PfU9rT9tJkxj3nH/5qUnIQ1e59XZVF5dbaw2ZuS8AzVFZLXPZu7ytfj6ffO+9eqY7ShUDuq5HkgP
VYL3/mB84CCYCiwkO9ASaAsQYPxagw1Bd7AxGAswwYLAEyUXqAvoA5ZgcbAs4Alq/SvBrmD7tbZg
OJAVqAhgweq/t2zFpjtBe8cCPcQKjAKnO/sWVADe/4eLBIWEQfo8EgUpH2kB6QtIK9IGrq08T/ZF
uLK/Blb2WaQErO5z4G7Kyl4KV/YvwafHvoyq0TPIGzCi1CW4wurgCmuDEaUaVOWqNxC76pLqEuJU
val6E8FUb6mqEJfqHdU7yB2VXqVH7qrqVfXIPZUZmKQHrsX34VrcDJ8Ga4VPg7XBCFR/Ap8Ja4cR
qP6ZakY1g/yZ6vuq7yPdqp+ofoK8D9W6HqjWfQX+rxy9qgPVAfJV1YeqD5E+qMd9Day5aqQfxq16
DONWfR3GrXpy5pNnUpBvnNGcOYf8Cxix6l/CiFUxGLHqmzBi1TCMWPUt5bkuZATGrfoAxq36IYxb
tQrjVv0Ixq36TzBu1QaMW/UTGLdqC8at+imMW3UI1tws5ENNtiYbjdNc1HwGVWtyNXlovOYLmi+g
v6Up1BSiiZoSsC5/Aq7CyWD9bUB/Gz659TuaRk0jmqp5T/MeelYT1IRQjYbWcGgaVPQuQEXvd6Gi
lw4VPbAWaxbRDPjk1qeVSFno7yuRstAsJVIW+gdKpCw0W4mUhf7hua+c+wp68dxXz30N/cy5gXN/
juae+/q5r6N55wbPDaKfPxc79000X1mR0QIlmhZadG7r3BZarKzI6GvKioyWKCsy+rqy8qKlysqL
fklZedEyZeVFv6ysvKgFxtSywZhat2FMrQYYU8sOY2o5YEwtpzZJm4QSyv+mgfqUp6NQUomMjr6n
fV/bgz7Q9mr70ID269qvo5T2G9pvoLQ2pv0mymi/pX2GctoPtB+ggnZcO4GK2kntJBrWflv7bTSi
ndUuoFHtc+1fov9U+1fa76F/ov1Q+yHaqT3RnqB/er7yfBXadb7ufB36/nnLeSvac/7m+VvoV887
zzvRr52/d/4e2n8eP4+j//w8cZ5AB2DUrz8Hq2An0vfRWli0+yvHr12/iWIyC6zHBUQ1mQNyOUQF
eM0i88Bn6UQReQHkNGQByCUTF4kEkIsH58URCKFVzvcekQlInHefSPQdgty27xXIbXhPfMe/Mm98
9DRT+5lWGJ2sCiB0pKjq4+P//kAfl6yX7OrKdEiJukT/ZkfxXnlbeX/JTOWzq/ordyuxEnUl9nrB
W7GKnbe2r2L3Gq4IxcbXMkvWiVFd2ZXREvWlV+VtV0Yrn72mKXpcidW0VBYpZ165C77bJfZ9al8R
WGd6wKo0CY5EkFdyT/B+n8235avzVZFJvrSSGaUOJfq3TkrUr2UW71Vi5W0lM2a3UoNiK6hDVYn6
9d6KnXeNFZlXhEtZugxd8ZuCCZSpqCnpuTJHBkmODJOtxJEvnSwjuwBOGShZfz23ZLd6r9Faoq5N
Ks5+M/Pd+NqBq3rl6sr1dGUVO1c6LmVdEV5PrZm5VHfJolt9U6i11p+aw+R4xXSxVbdXWaT0xVvV
bya/tqIrI0cqseIGXxo5BdoFWkTOkgvkkq8I3L39XSPZW4l9kQBtKCYNJSlfJHxPwX0sV6JmN+iP
LiX59PUXX88ldoq1xMSV0XfmlNbWT1zqL9ETa8UN5Z1Km8u3lD5/I/dqzhcXi4aVNlfsvNP95lBt
w2uZbxVX71U+I+aI529OvDGrK6h/rKuuxOpL6st1h/W4DinO1u29Q4GxUQP8MP3aCrFZrH1NeGvb
7CZWyvvNxhJPsbF4T7esWy6aeL2g3vFOB+hr7ZsJAGnsE6e+dDBSRb4Zn40sA/2o92X5Zsh48JpC
6nyLZLbvmU8iq/Fd0k02kiQc2RaQ1n2dvnnixRVNbWttl2EZlFT70sC1WgAi7AfJ4rPpyoq1ymE4
LC4gg7pY0eiV4UvHbybr/jt75wMVR1bn++qq6goyDCKw2dA0iE3TNA3dNNXQECCEEEIyhATCEIaB
TP/vprvBmGBEBnmIGWTzIovZyMYsYsyybOTlsRjZDMtEjBgzGGPELEZeRMQYs5GNI8aIGGNk9t7v
ZZzRoz5957zz3LehTn36V7+6dev++d17f/dW09XeNLST1E7xxeKLOyNJDbn8pvJTRZF7XVurn/OV
n6Q1RFJcRawzLMtTenln1c4dO3cU9Gzpe+ZW04j1funl3SMHxvZObLMWe2gcVmt5R3a1dUc5v3V6
27Wc26R0Lm45vXOAprOpqekmqatQktr5g7MHl4iFcAc9B4NkP9BURb3aJut72g+Ok/T30KOD+vdw
B01NYU2RBwsPLh981ORoqn2mtWk3Kaf1B3ObNqxZ9mVi081E03ewLaeE9Ewpis8qPks6ppcVL5Ne
6hXFKxyv+Lzi85yguKS4xImKKcUUp1RcVVzlJMW0Yppbp5hRzHAhilnFLPc2xZxijgsV0oV07qnI
5shmLiySOGHc05Gtka1ceGRbZBv39sj2yHYuIrIjsoN7R+ThyMNcZGRnZCcXFdkV2cVFR70zSs/9
RZQpKpd7Z1RhVCGXRvrMSs4YVRVVxRVEVUdVc5ujno96niuMqouq47ZEvRD1AlcUZY+yc1ujnFFO
rjjKHeXmtkV5o7xcSZQ/ys9tV31B9QVuh+qLqi9yz6i+pPoSV6p6VfUqt1P1ZdWXuTLVV1RfIZ7Z
E1/uiS/3xJf7s/TlFBPENn/tI6Vqnuz/B/sf9Hn9hsApTgicCpwNnOP4wInADOGxwCTRDQSGAiPk
6HDgOjlqC1wPzJKjQ4FWcrQ/cC4wRo58gX5y5Ag0Bo6So5qAjRxVBnoDff+lx5M31+X2Ca4335ak
dykGTXJmgbG/8qypNU+03jFu8C/5H2WfzeULV4tDA/GFg4H4gsWAubwjJzNQFNhRNli8VFRrkn2S
sd9/xtS62epfMp3M5dM8KcsBbcCwsZGEXCwOLWrcxvnFgMM3ROricTA6qAtGkzrxBe4HQ4LhQTmo
ClYELgRGPK7goTwPTYO8mFdmai2qNW7YPOlfyj5bNkZTkOYJxJuKCweNN8s7cjvqxsoGC/1b72Z3
bQ4L3t3oCD4IPmwIDVxoWO9x+SZ9VQ2a+m7342B3Q6ZJzt6fWZC6f2u1qbWhxMBtDjPty31QuGrc
sBZfP/FuThV2lw36z+ROvzDTcDhtePv6XFX2WMORHJNpsLA1tXVjIy2LbY5tu4uGch80tAXic874
ivy59eGBxw3D9WcbeuujA/0N6gb9tpUGUyC+IWLjyDZrQ27aeKqrYTgQn7K4tTqQX94R2IDtfF14
9v66u0aDv89/Jq3NP5zauq0978zGEf/8tnb/sn85a30gjJb5dnErbxgpv0XzXN5hcuVczn2Q/aAg
N2XJdNY/7r8c4GwJgUjbRPH1QLx/1H/Rv+i/vVEycBsl6x1SN63+Xv9poyFgzcvMTstZLBvzz/of
FV8suRTYbdyQo8/R5x0pWNzKZ7uyHxgNFonUUm2gCjXVH0wLFtR3+xaCHYGjQX9wf6Az0BQ8FcwJ
Hg+qAveCg8Gx4ETwUvAKuYbUJKlLVWAlUOW/HpC29PmvuvS+hYDPo3MfDbS4jwb5YHFgMjBl7Cd1
2m80BF/bGdZQGLyxrTa4GpwL3moQGyrzgoaRvN6ytG3m1FL/ma1jabmFqxtXGoINB4qP0BoqXipe
KrzR0GyaLtGVXCqcK5zzL229m5a7VTZuyJ1usPmkbe0FuYH4vN683mxSl6bohp6GsrzRhpoGT/Zc
gUhK935DH6mp0wFfwxliie3BUmJ71cFu983AtcAM2W/6HJ40f1nwZHA6mODVe6LpEel1jvlNnuhg
a2AouC/oCp6rn05NCJ4l5dQeGAh20fz7hnwDxKYXAi3BkMAdUzHe4pP/xHd74rs98d3+PH030l56
3hz73uX7w36Ip89zmhM8ZzzDnlFyNOhUEU54LhHdoEPynCVHI55r5KjTc5R88p7Tnqvk6KqnzXOd
HJ3yDJKjVs9+TxfH75vz1JKjRo/Dc+LX/cSb/xdxW3nvzd84SpimO/9vplbThGdC9pharS2W+MTx
1Ie7mi1S9oRcYqxNnJeXLUOp1Z4bJcXJVdp7eWJGh/aeRWtqzUjzTJjv0avoFakPMx4mzmu6U7vl
088HE+fNkZ4biUsbZ7STnrnkKnm9psI04Q31qr2Z3kJvjfeAt9nbU+4v7/COei96572LpBvSkt3q
y68o8y55I3y7fVW+Wp+PXLOeXFNCrukt93uHSeir3sskZORayEVvic/sazcbdLmeU5oHmluWE0l3
09ssQ0kJxvzECFNrUkLSnGcwcX5TjqXdfCxjOuOcrtA5lreUe9JzLq+Gpsl3wtfvrSH36vFx5B6j
viGaoj2kYyTp0nqDFWU+7Z4NJD0XfJOmVl2hplr3yEhGP89DuS8pPLnIMrm5pbg3cd5SJS97JpLS
tPfSzpBSikycTxxOHNYtWs9bjmWGPL9Ijk3mqswQzw1awsmcfDtx3FKl0+gidLnaCyQlJpKWBd8d
kpZ7Xk89Xx9Sn0BS0rOWjsyKsvrWylJfVfkV72hla2VrfXf9cV/LHq7+ZP0pX379Pm+uL5+Wab1c
X1Dv8i7WH/Jx9R3WFu1NY63nbP4krSHPDc+YZ8wypI3UVGRc2tVsnbJOJc7vak6vSXrok3xFJcUo
1WXvUupDa4tpwkTsQntB9mhuWVusLXlXSclKqd2kVM86fCUdGXPGYyXFm/ZbtNap/BbNhKfbXGXh
Mh4QK5r3dGec275oOUZtJTF0a0XSIXOkOTJP7blh0W46R21N1liGtkdo76WelA9s92S7kg7l39zY
Qu+YOJ44TkqJ3Cebl5d1hRatvJR/wWLwXHKOefVek6/FmwurKCNlZqPfpIJFHfaeofXnvQ172uAz
EMtopPVH8jTq2+FzkDr2eD2+Jm+ld9b7yNtGSrbSe9qrIdplXzw5S+0h03uRhD9CtMQOvTXERoeJ
XdZWXKy47Ov0HSX1ke+97r1O7NXq7fGOk6vo3ftKOvJJORlrLSuJ1zMmSjosK9p7skbWeI5nF3iu
GGt1EanViZc9x/NvlhTrblukrWPae9YpS3vGJbpZHsvrSWoyka9cUtsHSA6u+UZ8M76bvvPpbb5j
vgHfVFL41jHSHg3y0qZumdzRHJ8YodObzV5xZ2R6G7M97b3E6567OnXibOK43Cw3kxRNJk1Q+9zc
kj2RkZZ43TpFLO6RxaA5l9Ehe5xdnlXNJXkx43jGWW1YxoSlsZ73tZDcLfj6ffeJHYbXRxNLVHl7
6ouJZZVSOyQts9bbVr+flLXGe7m+or6i3E/C6eqjSYmMEptdT+rEQ3Kw4Fuo7yItp6V+0Lfie1yf
Vp9TX13v9+bWhyQNyh55WR41tZrvyH2JZYmXZU1Jx9YxXW5JR+J4SYcxP2cpX9ISm7F06nIz9nke
eO7mLSWFkO2uZ9raLvfIS54b+TflXK1544y1paQ4TyT9k9qiNW6wTnlO7i21kHhNc5pqWmbFvZ7j
8pLmhmXIskLPbazN0+cvJFUnXrQ0es7JJUnd6c1JExaH+Z75XlKa52yBLf2w5pyxVnstaVAzkbpq
2ZFaobnheS3pSnqbzmTerY2Um7UDnlOkTc9bmjT7iJ03ZTxMmvDcSgrXPHB2bTqVcUMutDzWPbIO
WKqSBtMfWSZTjydXEZ6UK80bci9l3Epq1Uxk86TE47OvZLfqek2y2awTzRtoC7C2ZJe+0QfLy7T/
tdzR3svooK2JWhnpfyfkvvTm1If5F1JPJlc5T1qqvIv45biviV9/8p8QT/4T4j/9f0L8xu8xbtBg
/4N+lO22bZETVPHGMfLJW64ZRzheFbHrNifYrlge2+aIbtxs4wTLqGUp00DCj8pF5GjQcstG/ChL
vzWeE2JuWWZsYxwfq9GvkHNHMlZsI29pVW/+70NYSOSbHt5fdgqPy5fiHLr76jMpUmK75aHtouqx
bb5UUvlsi7bluAF7mH2DXRtzeK/NcDxm/d6SPa3JIVnnbT22XlufQWcbtl22zWpmVT5tscpHQnN2
w16b3WpqM+jsYXWjqiZDgqzVWeUipz52X/qCvd/SYSp0NlsS1D0Zeue4PGXM0femROoPuMIME64N
cQOO1xw6x4OUC7LWGWrosp/IuJy+oB6Wd8QsyTt2Fqt7rLpNoZYKs6qux1DhXHYeiT1kv5Z+ISZC
1ZTSWDab3qLqlM9naNw5un6VpDNYKgwq41m3K7FWbdJZk0MKFmo7yudj7xpC3OE7EzatN5e6VTqf
WzarVFL6ij7CoHJXu1t1VnO4u9hcmiipquJWjLo4R8y4PrPi/pZrjhD9bGyCaocx7fnHyWOZF1VD
jmij3+LP8qkjtMeTzyX1OnSmRQdfE6qTsqocCY40nSNzvb7SVZUyGXfNkeOq1YTGHtIfzlsptSZf
yT/kKFD3WKJdjTF9rvYYk6HV1ekodh11VBi7aJ62FKX0W+bSJ+Xzao9R1vUnP6A5ei7NoLKQXOl2
66zqZV1L+XzdePIcSWV/nEPdp9ZX3HccirtW21F2ILfn+ceOENVQhWT060ayfOkLlpDkc3GNtmXH
FdP6zIuWidg5w6VdRY7p2LGMymSX4VBsguNGVlP6TcfYbt3Gk6ohQ07daEyoqlEzrH6ks7qG1CY5
P+9O5pnK0+md6t6M2xli4oy+xrVgDk8ZSBmSO12PU2bqxt18RqWhwzEtn9AMO+6S3BclrrhDzDmu
GVOla0U266pSigwJ6RfipmIijCfjw8tm3Wf1fca0uKLkCZ1BPk/yV208q2rSWd1zhpDyefVh8xX3
a5YuucnSra5Rn9511FST0Zcyqb+uNhlld07s/qzdsSfdd5NvGVT6A3KRflR9Rh3hKHUdcznUES7f
puuu/phx1wnVpKPaITv2Wa64mupq7P2qqZjQmJK604ZDTlvcQGamuid2n3oxOXzTaed8bmWKVVOp
jtCF2e9ro+0n5KKNJ+P6Decssu6+QZd1wpyWIsUNqK7ZRkmbGd90VfW4VLItxU6TNiAZSu1h+kfJ
1aQlmAsG1OO0xSRlGl1JzZkHMg+rfCpf7LRtmVz3KPOA7bTtak3QHqnula+pPXFTtjPlS7r7Kl/y
quFS7APZXL6UItlu2+PTzckhtovl8+XzpEVqNZWa2RSDRVY9VjWpmmJu01Zm9tt32HfE7rdPWTpi
liytZtl5xj616arztr7PFa9uMx9yqvVt9iJTYQpnLnXqnT32Ipe2pjJlKHbCKaqOOg/HaOKGnBcN
Cc5Ql1X7mibUPuD02Hpizrg2mEqy7pi77Pc3LdtX7OSestbQZegy5hgH60b1R0yFpH0W6o8Yc+Ic
Zjn5RmZobIehNOaIIcdcajir8slDyeExEe6ElCE36RUyNLp+eUY+YVDJ9wyX3IcyZnW71VfdHapO
9ZmYeUOIWkxu1Te7o22n4xyWELnFtmzIcVe4ozMPu9Ns19379H3uUuM+Q0VeU/oFVVPWHZ01Zbcm
NDkk43Zd0F3g9svW2LvurvQZc/fm47scapN+1nAyfci9P+Vx+oKhIuaIbijREDtnzKmprDssa/WF
5gp7p/2oszB9KH3IWalfdLZZ09Q9zsuZ4/Zau8O5mBJmSFN7Mi6aq3Ujcefp7lDV9bpaVCt1NaoV
Y0HsQ4OK1MERuquXHV2qa+R4xN3tPq6ZNS05wktvumpTOEt0Zq9p2RGdfszRFTuXHm+67PAn845W
R5fjpON4VqRmubYj8c7eQse5pGHSkvsdE3l31Ldty3tCNGWOs6RddhsmHIPp8VUTjlPmc+pR4z7S
97gc+x2XskYcc45bjg5VY1lzmUd3wdKhulZZqBklNTpqvOReNZx0jbjO73Fl3HYeTlzJ0maMZt10
3axrc90h2z25yZBjiDZHy2bXgOuC+rBryjiYdU/XaZp36FLumPfpqtwPPaLrvnF/Spgj2pQZZ3ZN
uq7phyvizRW2R6bm2A7NcGyC+5QlzX3OLDvCY0/tmkxcyV1vmk0Pc9/YFIy9S2rj1qZ53R1zmuVK
5mn3tFHOWNI1ua+kPCY976WdCbFzapH0uyfdg6oN2uLkYveD2ui6ZvfEXr3qmHE/sZsxQ2ndYfVF
XX7MYX2u2qQ2aUKdQSdhTJ+zjIwRxzIua4bt5+0X4sLkC+kLG0+6du86ar+nnjXkOK9nhJpmYwf1
Qeeo3Wf3Oa/aG+1NziWrKmO8ID52wmV2rk8armsrLHQ8NN1WNRrSUoayGu1DzgOZon3GftN4qa4t
62bG9aybcZ32Bfsd4w17lW6HfjRZNkxnhmaGpsy48tM3xHbEHjekGa7UnUnZ4axx7UixZmoc0SkX
UoZcRc4+Z6/ztCZoKFX3qHtilrJOZO2ImU8ZcT7aWGCf1D7YeEs1FBdZIKWEaYZNty0JiSvpU9oC
FxdzW9Ym7pYHNGrnaOIdzbC+19gRN+DMdZZYJlQcGfuGDXKK1p4fc9m+25kp77CPxO4zedJ9To1z
1t7iklyRLkOcltRuhelwyoIzQl9oKnOs2tuTp50azXLiSuIKXWVRLDz5H4cn/+Pw5H8c/tP8j8Nv
rM8+NfWH5xXrFyyZnLD+Znga+eTXXw/XEl5NvkF0l1Maky+Ro4nkGXI0Fh5KPvn1IzVh5Gjo6cfk
k19/+rmH5Kjv6aXnXiNHx5M7yVH307fI5xs9x69nFYoZfgbP/HO5nSRdpv/N3vtbx8E/4po3wv2u
sLa1/Q35wO8Ic2DtvgfW9j6y16x90vOn33LuT9n/mHT/rnDNZG/jdoY6sIWFVpGthXy2k6MqsreH
dmI7GnqMbCfIZ0toP9kcoZE4S7d+sg+E1iKGIfI5EnqebJGhF8heRY4jyTYJ0k8mHQOHyOZA/FMk
limynUe8tWQjV5K6NfwZfRMgPyqfS8P3AYxRJVGVnAnfB8jD9wHy8X2ATfg+QAG+D7AZ3wcoxPcB
tuD7AEX4PsBWfB+gGN8H2IbvA5Tg+wDb8X2AHfg+wDP4PkDpf/n8K/huUUSLHiNjOrdu32/th8je
SvaOteOut+h/O2zHW87/vp2e7yb78d9z/uTaTuVTb4mva+2ef+r+h9Ly1jz+MeHeSNPvytPvC9/x
lnv8qelqfYs8SPazvz4OKi/TTdottSsvKi9KkVIYOeqUqqSjZKslmqOSj2iqpBZojkknpH7JgWva
yfFuaUAakhxES6+okkbIdh6kn0y6AB6TwrBNYpuSJkncRezuiK1RasTnCdyHbtfewikSulaaWdtu
rm0LaxtNMw11R7pHP0lbLPj/5H2teVF5pKXSt7YW4K2tm/HW1kK8tXUL3tpahLe2bsVbW4vx1tZt
eGtrCd7auh1vbd2Bt7Y+g7e2luKtrTvx1tYyvLV1F97auhtvbS3HW1sr8NbWPXhrazXe2urCW1vd
eGurB29t9eKtrT68tbUeb231Pyn3/0flrlAYFEfg5V3l0knp31rbH74pC/Fspzp8vqHTvhmG1/zm
Nb9r5yPIXra2R/z+8G/cjxfZrlh9U4Y+4jfD0PNETleosekVer6RbE1gC9/Od/KdCjV/lD/GnyBy
IznfyXRE249wTeT4KPkcIPsQ2QawNZHzTUR/goYhFvr2tV9nXPj1rzMK4pg4wa3DrzOG49cZY/Hr
jO/ErzMm4NcZE/HrjEn4XcYU/C6jAb/LmIbfZTTidxlN/5djJ/77Kv3FJPpH5UpKhQ0chz4ajAf1
lK+vgK9Bkw/5NniT2Ew84jnMYlNUgdfANoT5BjgNfgf6QnAEPEbJ7wbNYDH0g+AtsAt6NeRl8BI0
zZD7wCbQD94DZ8FVhHSBIWAuiHkMPwd2gL3gUfAOpWAA94GPaU5RSofXSikUObqAMiwAE0AeHAMP
gIhndT2I2H61BDkM8kNOIWzC9z+tYNYaSckLsZDPge/D91E0IMLw/wMcAs+Cn6FX8d0c6TX5r0Lz
CVwrrZGeXYb+Efg6+CXwR+B5hMyB/FFwOzRJkP8J/Dj4d+BFnM0FcVb4a/AvQRfCfAXcBo4g/ccg
lyLMZ/D/bcOYzTWDiF+B/CoQhvRKlO8G63EV7i50I7b3g++lc1Pl30B+DbyHmCsRUg0+C24EM8Fi
UAVuAQvADhBWLRxFbJ8GTyDOv4UeqRU+AvrAzyLMceSuH0R6+JfBOhBx8qxk/jv4YbCekdo2jzvy
H0R+f8WdJlwFH4L/Tu1c8T0q80+B74L+x0gbSltk6fkO5CtI1SehyUfMKB9BDzrB9yuI1y2UIORL
YDj0sDexi57lR3Et8sv/M/gFhGlF+HUIOQHNLsgDkA0IeRnyh0BWJjdApJC/ypFZvPBF5LcC3A8+
g/A9CDMJvoqYPwB9O4jUCjakIQryu8AYELHx34ecAh4CWQ16cRWLJxEMQ3ic5cehQRpEWJqAOhX+
FUQK+VOQ85DaIsiFIGt3qHeBB38KPgfuAL8Mvh1piEBs0PBnQFi1gPiV/wJZCU5DgzhFxCmyMrTj
7KuMimrCNpx9Hpo+XPVXIGxDdEN/CbwKPdq+MpTZAwhrV354rY4oF3FtGvQhCIP+X1gPwvKFAHgA
YZAXJVqr+DTkaJxFr8IjX8oN0FSBzdwe8CXCBiorRWh84HspxXjI6yj5W4wKJeH36FX8TZx9Bfwi
+CVcdRDyPsp1I4yKByT8zxHDY9zxach3wWvgV8A74DS4Cv6CyfS+pN+j8jnE/yMQ4YUl8CHONlFK
WZQKJ+gC3SDL9XXIu8EKaL4BvgqynH4d/Aw4C34L/DbChKPEopDfi5BxlXABfD/4AbAF6WEl+deg
Z02m5XAM13rBTdCbwWfBFxA/yopYCOXzICv5GvA50A7uQQpPMPJvIxoH9A7c69OQz4DHQRN4Cnf/
Ia6aAv8n9IsoH9Qjz0rs38FahJ+B/pvg9xF+L3KKvAinwSDSfx5hvgdND4iciszGbkADG5DaERLl
w7MyRAmTkXQPxtA9GE+pnoN8k/s2R0comh6knLRfqv8aZCPkfoT/JfgTxWcIkQthDsTdRSvIg/8K
/Y9BlubbiO0n4H1okF/lr0DYp5LV6WXEgFpTwqL474I/xVlYo9gFwj5FlI+yCLKXqyNhGiFHgJ24
ipUnS9UnwL8BB3At2pSI2le2Qv8+kFk1NMpPQf4ouBW9wRT4cY74fuKLrJ9/vZ9ofgC9R5FGezlK
IWX1BpH3QV+LkBjFePRpvIOGEV+hYZQYcZTo85UfYOMXzu5anSRyAHIW9YcFEf1PB3eFMJKSb8fZ
p6kvx7MUop/nWT//8dUF2nvgrBNpqwZZSg5RWZkKmsEMnA3ibAPkBsi7QYyYfA0jzj4D/jdo0Ifz
h5kG7KZeMSGV0d/yeyglP821yEbbeeR6H+5eCz6L8O/nThC24KpcRugxAirLuUe09KDPVFhRzkTD
v4BS0lAqmX9YDX0dWMbtR7vAuEzTIHzw9e1Ej/GOzwa9uMsWlhfOQ0cKOrMQvKsn6TgLojaFR6jl
X1A/h38vrqpFjcdTj1pEbYplICsxjODi+6m1CMcRPpPdC/EchIxakExI27nVWFpHuNdHUGI/B1Gz
4mZ6F+L3Um9ZBerAr4IoT9HFrA4xW+m8QNhHyVvp/IhvY7WGsx8Cm6D5Nq66TkOKF8AEWp5iMiX/
Assp+G52FfRuOhsSPo68RKKW61EaJQjzC+Roic5E+OdWO6mNISS8R8G3SsY4wQYeBMuhr1/9HPI+
ifIncxP+H1jecdZG64V/kdqY0AgZnjNfijtuBbfRuZs4g6uYJ9OJVJlw1sWIUkV6lMzG3NSTFM+g
DHuQzmO49kcsBhDWKybAGuGJKeFXC2gvAps1rLVB8LvgbfBtCJ+KGL4OspgHQeRRYB4ys5m9IHwb
4X/h2ndAw/ycn0E/CcKLFth853M4C39M/Cbogf69IJNPg2jvAlqxMIaQzM/EjEacZnUBYn4koE8T
FsCTCAOvTETfKPwEMnxd/oeQ4bELfsgRIPoosRD6WchLIOZ6IuZxAspW+Dw0d0HMrQTmJzO/9zoI
L13AXFJk1oteRURI8Vvg34McQrI5F0sbegOReeOrkOF/igpo4FUKmHuKmJUImG8KDvBT0H8DhE8u
Irz4NZyFJykI0GSAbKYAWbCAHHqYd0KGp8rDb+d/CaKEecyJyHhNiVLiYQM86lRg6UwH/wLcibO9
4OdgyahlHn6ywGaamAHxrI4wh+LR4ngT+AL4K6QZfYKIeYSIWZXI6vEA4qkGmffOfOaDONsFmY2J
qAv+Aghb4jEj4FF6POvDf8pHE65AbsU87n2gF3wWPAJ+CsTdRaRZ1OFeZhA9rcjqhVk1enXBiXKA
hYvMhuHP8/dBzEl5tB0xei02Ui887JNnM3FW2hi7RdYW0H6FZBDjmhAHsnkf+iiR9QZorYIRsf0b
+BgaWI7AxlZ2X1ipgFmqwGbibOUBc0AB7V3AqogA6+VZ+A9gJoVVCwH1JbAeI3TNxihRsyJmQMSf
pDLuooyBb1MK5q/5OS/Bxqi8Hz6SDnIAHlEZmAONBcwFJVAJZoIJIDxDAfMFMktl4alHzfzVH0Dz
YbAX98IsgFjjHozCVH8AMkvbu8EPQcP8UgEMAbMRQyTke5CRZgHeoMhmWJ+EZhv4M3AXWIg4mY8a
zr+bo/NlGv5laN4OIj08SoPHfId4I3tQ75TvAdVgB8jmZfB+hVhQC74TeszCROROxFyDZ94+PGHh
CPztj0BuA5k3/h2ER9mK74CGefVs5vgSeAhnt0OuBt8FaqB/CvJXQRbmRRA1K8CjFlD+4gdBNpv4
MuRiEHUhIhcCbEzJejnWmjBH5tk4gjFxHebR62Dn62CZPFtjYS23kbV6hGcrYB8DPwm/4gHiZ74l
ehsl85/ZVVgH47E+xmO9gsdKC4/+h8cqH48eT0KbXYfeSYm2qcR6mhI9ofTd1VaOzjdp+M1U5j0s
DPwWtoKEMU5CCkW2soRRg8f6J4/+R8SamIh1DJF5vGzlYQddUxWepxSxtibCi+ATQKSER+/Nw8Pn
se7Hs3HwKXCCXsvDc+CxGiO0vB5B0wC9BjG/CH6Uch36PfEpnEV6FGx8xPotrwWZB4IyFNnYx8Zi
eClKtn6C3k9ifT56Hgk9iZLNNbD+KWKFRGTrMBjZBYw+4kuYGSUgVTxK4AFkrDDz31y9Svvk1000
PdCwuU8HyMaR6yDGDiX8FiV8CQm1r2S5QNr4CmgwDipR8iKzojkQ66ICVjJJO6UxsNJGnywyH+MB
swSEwR3Fn4NYMVYy/Q+QfmZjsF4lPFgR63giG3Nl6NmqeBbyxdYGUcICG21HoT8Ffg1EyQjbQNSa
EAO+DWfRjnh4IGIb1ShboM/FLABjkAjrkuALSfAnJaxVSuNI8zGEwWq8oELMdvoMhfTqhEqUsxIl
pvwhYpbBZ8B8MB1MQWzt9ImMGICGtWgT5KOvSyQG5ufUcNkYiwmVzCNlq38RuAtGNwlUvLJ6ECR5
UbyMHJ1HCuGHkJGLprCUPssQMc7y8Dl5tkKI1Usl6lR8CD2eO4iYwYlsTscsmV17B2Q+KlsBhpfL
L6K3gVcgsvXSAuTo7UgJykRRj3kQvDUeXpaCeZK4Oy8hJLxx8RoID5yHp8fjKuUB6LEmr4T3JZ6D
zOY1jLAQEb4Ej9YqYr4pwUNQIjYRfZ2ImYWEpyoiW78N0vm+yPxGtqaN9XOezYXhRUhsLjDEbAlx
okVLFtoe+Sy0ysOri0RmK+3Mm2JzKzafRW2KbJWb1eno618gMvpnHi2Fxzq2ErMYJfOQWVlhLBDZ
ujqeKCnRKkX04fSZOEdXO6kG44XI2hdWeiVWzmytmz3pYOlndf2PlOswHr2NlRj8TIk9cYAXLeLp
wDq26g5vU0SvImGWJDE/Df6/gNjIPIWutLBWA99bgI0J8FpF9mwC5S+wX0dhTxPw9EqEbSvZbJ2t
Qu/j5sld2CjDSgMzKSVbY0GOJNSLhLVoCX2XhFV6iT1Fwtq+yHpyrIqIzB7wtELC3EQJ6xKxpkH8
CqpnT3/Y7OkA9bQFPMniX6bp4b8AfodS+AR97kk8QKr5BqUSfYgIf1UJ31VicxzW56CvE5kFJnJn
yVnW+8XQclOixJQocxEtS8msDr20eIiGEeEnCKx2MF5LbMRksw82QjHfFXoJbVnECCgyy0FvILB5
H2ZPIuxKhB8isXbB7ovykWCxIlvzZ3dn49c4o+IQCYP4JfThSqyiSOjlJMhKjJISm2vgGaIS/a2I
MUvAjF6JEpMwjxZf4Gph+bXIXS1CUn6AUsk0eymFH6/xPuytFmVbC7ulIZ+jDGlkpE+Qyd3p2Xfh
qh+Bd8Hvgd/E2V3gc2syiVlsxdkT0HwfZNciDevUlLwT3IOz/ZDzIDeDQwj/L5D3Q34V/CLSuQB+
Dvn9NMJcBnvBfwAHcfZ1yC8hfDTkv4L+RWi+BI0ZtIC3wDaweO1aMlMTPwE5iDQMMhIPUSFuhP5j
iM0OuRt8H+6CkGIsuB48hGu/DU6DP4P+GcSgRDlEQL8bMmLjn0Js56B/BeEzUJJWyNtw7Wdx9jE0
nWAq9NXg30GDcluHa8mMjPIM+ClwBmFQa9IYOI5rv4GzP8TZHzDS7zaQHo/Kfw8OgN9C+A9CngSR
ZgnlJrGSR3jpIoiUiMO4KgeaI9BshuZZ0AZG4mwCZJZrFfjP0NRCrgHDwK8iPLMWGXIZ9O9GXn4J
DayC+C1UDoe+Ad54A/2ehgj/U2jEeu8VqlGin1ey1Sq2DnyIkZ4V8iF/DMR6oPAd+CoJ6AkboH8R
PoAOo/xB0AG6aUiBPY9+DRr08MI/4aoRcAJEryK+AhnegjAF9oCdrwfpnBeyD/wgI1L4MmT0n8Kz
kK3Q74FchTVt9hyhDemsREpYmjPBErAM9IKbwefAOBAlwH8UcSIGwQ1WQ78FshYyD7JV33DojZC3
0lQRj30H0URB3wLGgmpwF7gbKWTPVRWshCGjJPlb/8HeuUBZVZyJuqr23ud0n3ef96vPObSIvEUk
iM1DBGwRW8QWoUWCCAiIiB1AREQkjEFEggwShhBCCFEkBJEQRaKGICJBJAQJQYLEYYwhBIkiyygh
hJ6qb7d3pO+sO85dc9esu9bI8ju1a9euXfuvx676699/86SjiL+FnD+GvyeGsHWemJ3If6CRnnUF
8f0gdWStJj5AuIwwsy/rGWJ+5dYCMb+lPOuJYQVn7SfG3THfRfxaYha6LYQYZGhZlOSvPPsHxFyO
Jv864rcRk4BFWCLlu5w9DN+Gv+GsK40svBFeCi8ijTtv7E642lCeI9yOsk0iZQ/uPozwrbCXS9qM
28baw95uW+LaMeTzOnwJboK0PfUDSFtVj1F+6kuNYx3X4O5AcfYI/MilqR1N07Z3kfIUKZkrKi9n
PyGmfxMbNHsS5umsE+TDjMtyiBlOPR7n2h83ZnX4QdrAbfA+OIOUrWGMmDYwQ25niB9FTDfycbWy
nYjvxBji2lrQ362hjCGuPpN1pdXNrU3k4K4szpDbLEgPUrQ0dWOT5M1dfJw9Ch+Bdxja/0iY8cQa
yd2/QkwXNx5OgsNhbyS5lfT0Qas78d2p3yDyCRLDrMzyEC7CLBxPDrsJT4YLKckQwg2U9q9cewkx
syFnFZK3fDwjKxr1F8Yf9lDKWOOXMfMsQzvhuNY7rMXse01Kzztc+1X1sKGxxFPDYb2h3Vc9qXkx
ZJ1iZwi3NLT+bqjuE8c0L6Jd9Xf3UiGzdzWenLuR5x2ExzR207yV8t9EzE3qSjMeEu4Ou5DnxbAC
toG3GbtBfe08M3LCe8iN9qYSxhJPXU8ONXC4oXWludZeJUPC6K9Mmn5igY4R5qw9mpTMxtU0clsG
v821NcYKUXVVrXT4I+ypPsG+6JPGkWaNY2wIVRu1SRgtkynhNjhA90i9Eue+V4lXianW/Aq8EXZj
l22gsUtUtY0v8FwvcMeDpvzyr2Y0NvaE1sfwvKHqb+5ojZJrdPgGYm5o3GHGQML9jJytiwhf3bjR
1KPZWdNrbVOSNtRaT2Npqeeuu2iTZm/6crMiUKxB7MrGnmYehTyHis7CaGyWUrY+vFP6cBdN6/fw
hLEW07mtMrN9Yj7GimwQOXfmLksbWwqzP9vSlB/prcSq8G3sEoeasJ75m7VMW3Mvm1051eXvSxgl
JjMmmH2HlZTqSZOD7a7OBpmwGgOHwFGwPfvILUjpaiy/ZfYr1bXQ1a735I69ebrejbWaVewm9BA1
PO9JeoSmNcXQXtQ4RBid6gIjh7/3M3UE+9K2e7gtnKuG8aSjCY/jjmPc3NgzDZJnAHZHt3MFT+dq
wH7Civ4btNLZjRvMeE54hJimOU8cFsYO80PNBxo17Vupo9saze72bTzvUpOz8zvKvNiUWa/EjUxu
Zh1Xi7RP0cL7mhhPW8JnKWFvaq0HtbZFTBfGfsnU0TiuetoYweo6MjVYz7OMpL7ijbPoEWbE8JPP
AO44ktzuRs4DkW13WMfZEbCjWek446nZAbSKGlgNu8Ir0T12hXdy1Y2wFn7QpAMx6+KvmvR2wDyR
tdVoSPTY2NbUNdemZdr0VsjaVhWIr6ac7m71Gcr/N5ODXTI9S/eCXdDkvwDJjOOJnkCedzYuFkYz
bPYHLdr/WZO/9QGcy/i8mKe7ltL2YHxoDXsbWuWs329Fq3MTaQbCy+A1SLs/JRlGzKWUQZiatdJ/
3254fhrSMOX8lPJ/CDvLKvqCuaoN+aRomV2JuQXez1v7Gc5+xDhwA/HVYqt+ui6ig+ZYdE1teE89
aGy51bUybPqIoVXVaEbv7kh1mEmvhmH/+Rbhe+F00SiMTtXk1t+ktI8TP1ZWml5jqOVmwjcT3kP4
OG3vdlMS9Qa8nbOvmDLrNmDa5NTGvuZs48WUKmbqGtaISzUHm7D9EjE3cscbCV9N+CLYwyXxXblv
a1hPfDd4H2cbxEXCWOPcbfqg7K5rbd35vwuzg9DBzCJIeQMcJL5DPZrn/Rd5BfLsALUc9BvNxD8s
PjAlJNySsz25bzXxtzT6dZ7SUI9U5mx/Un6HcA1p6mEvcYsweqoOjCew8XL4T2bMIT3x+l0Qo52b
MDWrhhIzytC6RGSYmWQZnQxT5PaE+IvmDqNxUjeRvq95R6g8ZWtFPq/DMfJ+YTROJjwVzjHX2u0b
39DhS7i2FTXS2rQlZ5WRnpUn5TVIrDd37Mnd3yB8AsuotqTxNbUuU9q3yG2gqQX1sbyI9mzOzoaP
wWWU87twBjGjkGGDvMasGQ2tPY1tzL3g64aqFzl3gdXyEs128FLYGvZqTJj5G/X1FDl/Cy6FX4f/
6NYU+bSB3Sn5rMbPNHOUqoo0X2mU9CbuiLSvaLxTswWsMlR/b6rZomY70+Z1TV1peP5ZffZicn6T
NJebetT3vUcYW6kOtBDD9uRfBdtRCw8jjfs525L4AfAyeD+j6CE3ZVP89bRtU6fVxFe67aHpLbyL
qzoau0RmVqvN+Oa9ijB6V287wr+GPzf02sxM2D33osez0aN6XXuYc9j8nGMejmWFx7U/YXfAnu2S
FdNs1gVo+z3szZWjbywjfTl7QPZyUi4nN2x47OtdEn+amfMctA2sHRx2HMrY9fNiiedlx0EtIyUr
WYXuwnEthZiTe1hjeu6BjP8edjm9aHqdyS7NWe8xyErf+yx3RLvuoFVwXE0C2mOH9ZcX6w7P48Sz
znXQJNisoewfsdb4k/sWI2arS/O8HreErF4ddtO8rn4VK2v7Bu7uyvMO0rg7dwuRFXoDm3VlGXY4
nl/zdFg6edHGKzQ8aj7xrM0Vmhx1MXT1Bq7uYharJI+7eiXn2yB6AHsCnMob80rCrJ1VC8Kd4WDO
Nq2aWffFjJZDLXC1x6RBs2G/SHmoLxtNi4c9C+cXxLj7uXzP4kH/70Vr7cVexYudhhdNtQfJeIh3
sFZy3D0aasfDLo8HTZeXXRgvlvAeLItsVtC2u894ObLlSZ1XiR9pas12d6xqWPf9Gro1S0t2epoY
Lzpt7yLO1tOuXHv+x6g7dF/OUOLdVjSMGNaPXvQDXvZtPe7e30Ti0cx73a+BdrjkLDtW3m9zL9ab
NrtFui2Zs7QxD3Jz2HP3vEU82huH2bvHtRx7j2v/gbOsnR0LKu6O5Y93AjHsC3hY+3vd7y/crydo
CR7OOg8iE7RV1nGXrLIfJfwcmpanifkhMT+GfyTG1fWtg3Mgug6nD3mWEYP+xx5OPJpGhSZEof2z
0fl4vg0XkGaFuaN9P2fHQ/q1jabOvsolPcit92nETIEPQTR+FnVt0b/Uz+HvKHNfZlzurpyr+URP
5aA5sQ7AH7hknvkDRoATXNUVyaMPtOub2GDWC4RHQMYoGwlYlMpBy2S5mj1Ka6ElsO+nla6hpmif
1jre0S9yly0QfYj9AGnQ59g/g5upQcpgPUpMijR/Jh90NfYTkJZs94NXcRXrApv9ZRtdsf1Vxnl3
7+kjl+T8EfGMsWWMXXaK9CkkiV2ihT2V9RvynAF/75LRFYsRxehnr2CEQZNjr6W070I0fh52AG16
io3k7acobaPb2snhHxh16XfOa8R34qqjcCYx34ETmp7atN6nuBZbDtsd/a7k7JW0It4Ujjtu02c9
riXqO9T7O5SQ96b5klWY/Q7Bfodgj8OkZLfL61o2fg/57yf/y+BSnoK9Ng91ah2DH3AWK0H7j4S/
D1fDbcRvJPxdcqBfe9zvg14m/rfEYwXnYVfaQxkcNH6eedwF/aTD/rXjWiaXiHH31gPk8yacxlWv
chY9vAcdpoU1pgerD4/7xdmT5LyaPstIXs6eYzk70eXsQXsZY+1vIu1DpHTfnudEmDnGLhg2Mwpj
Za3nEmYnazlnf8/+KZZCHuTgYffWS3vzYqfhde1SBrvvVq4aDhvg3Yb6bWu4kJjpcC2cYajfuWHz
zoW7DfU716y/uErNJ570ei1jrjpE+GJ4CxwCZxlaHsKPkfI2+AycAKdy9kr4MDHDCLeAlNbuDAcT
054847A3MZRW8RT6jWw4mrOKq56Ab8AbiO9D+ZcRMxJ+Bd7JtS9w9jPk8wvCj3O2F2f/CI+QjwOJ
sQuEP4BbiSmDWbieq5CD1Y/wJeRMSeyvwRy8EV5OSmiPgPcT05NSIT3nVWLu4+w4aNM2erpvbfdN
zZ71fPfdSsxOrh3pvt24aiDsDq+gVEhYt14Tg5TKua9uw2HacBhbkTDzgTDt2aR8Gn6T+DOU7XXu
5do/7EJfsYuYj0yrdlzbLdd6ljZgvUYa2oDl2gnfTNittVGQNmAhJasrvAmOIedJlOF22A050+bV
Q8T8E2HkqaZxFW1Sr3MN3VZHe1APwCnwMvgypC1ZddBtY9cTj2QUZbDclt8F3gpppdYAeA10z7p9
qiW8C9JPVYI09DWLOrIov0Ke9nhi6HeWW3ffhhJSKr0eNPwZXELKIuwEqUH1IWF6ltUOuk+9DZKz
cuORg8WzWO6TfkyYdqt+T9iNOQ+PmlZnYV1v0TItVk/W7whfCy+CtDqLEcP5A7ndy1OsIoYyl7nP
Qgu0/0xMG8j44NDXHPqsw9jiID1vgPTPEkML8aaa2uTVZo6Bbm2SCduDKNsp3uPbXZr2WcbuQ1k7
o+0sYz6gOV2Y7xBNDotMDl6sWz3YGklsaSQrAul+U4wdlIMNjIf+6HFte3hL2l2aqPP30B+VO2f4
A6XifWRjseZxv4diHWG57dYLn4c/gRvgt3hqxgRrI089qIkdsGIyfdOPPCsh/cuh/Sh6k3Lrxe0L
Jcg4ptze1BpWwXL4pKGk7qzN8DliKKdk9JDu2MXII2nnkn4k3XLyDrIYtyX3lTVwEaRs8nvQ7UGv
wb/APfAlnitMeCwScMdYatz5Z2J4lzn0BeX231aED0JGLYs0EpmoLYQZYyVvMYf25qG1eFhTe3j7
O+739Xw7YKNRd9gj9rBm8bp1zXcZupxmfCMfqxryBrSQj81zORHuvoJ4ZOUhN8e17HqU8RwbM4dv
FjxYNXiwN/a4X0C7872/ci3zAQ8Wyx7XLitJzpN5Lnqf48qZUUUhE4drLUZ4+xPi6bNlbutCMl7e
j2VIW/Hmctw3b57wWe7ujnuMD3q+ZML7yeFFYtx3mWuFyNxMud9fsyJWWN5aWN5arp8HxhOFBbLi
uWzX0hs7NIXllXK/S3K/gXK/eUGHY6N/sNw9TVc+aCcsdKd6PtCBNCY8FA6Hz8LrYBIm4BSIFsva
beigU7XQGVqXQjSuVhiWw2vgAHgbGrA/EV4EXW0eGkg9W+iAzDvwFujA2NuBWjPxZwmje7QkMY1c
FSTmHGFSWmgmrfGwgfiVhEfCtdDVT1IePS3twFvVEC207puGro70Zu51ivBeOMbVbRJuD9tA9NhW
ADowA/vC77uaW1cHSA7TCP+Ns+gP7Z8SRmeux70OvDENP4DfJM2LXPUa/Bh+yFkvRENuPwDRxOr5
mImPw8XwHsh+gfU4fBfOgpTK5qltV0qktB+ClNNC56z7tSE6Tz3DMfwlfIaUHQm7T9QOToc8u8VT
6PGqA3PRDoxgJnwxT8TcycM+URm6oDIsE8rwa+HF7tfr+iUoYOPt+kNAA+bBtt/qyMpiElbKb7Fu
PciaDmtbx/0Cgm8JPe7XZAtJydfH8iVDD9bRXkYYx/XE8i2+I0D75BnHNxHYyqquJuzw/axzirDr
r2Nd06r/ETPbxBb6RSzVWb/IuVhTV1D+IHe/G94L/wk+DudDbMvla+RDGouns7aTD/nLleaOOo3h
AmLOc/YNUmJjbw1iBzZFfB7b9VFwNGdnwIdcy21ycL/Pcr/Fc2XOHNVh/eX0htiNe7Cpdpg/OHxd
4rhfFD6EnuRv1IIf/or8fw73UJJ97HzNMDptiTWaREMlsUHyMrtQ71OD7nd5rh8P19aUVbCzkfSu
9uxHSP4R7vU8rQILFok1muR94XXfL3wtKJej/WZEdVhFykZ35KRsrGqtcYS7QDSK1hrCbeFa+FOY
g+d4unsgNWtJ4s9CZKt28pUuugVdF7qdyBXU3ZtwD2T09mBH7UHT7qCRsPaSZ4i6u83sJ+qxUc+p
rNsNHb58UTWwW1P91mneQswxrn0PfkSMSzSo6jjh/fAb6AF4dgs7W8e1FbyNlkyvlNgSy5dpLa9y
1VbSu19kCGrEIr37/RHPItFEeZhJqu3UVy3lnMC1yFD+jnC9+d5Z/nPT8xrJcy/7MtoD35jID7nX
X5vO6vQe1/bgMTwGoHGS+5Ce6yloG+Vxv35yv5M6xl2+y10u4u4L3X5K+mry5IseD9oM6e6GPEn/
dZ/R5qqDrtWQOxqQMzKXaJ/kvRAtq6R3WO3Iwf02qhO9AE2RMx/bzra0zE3YwLAfYbdgjHK/nVmH
ZctZ8mT/RfL1lnwf2WKDpL7L1+LvUB70QpIVqPVncm7H2f48O1o76X5tfTPPSwkd7IskOmfJdwry
+6bM5djYe/kmy8YyymM0mQI/WwH9M0yOEkpcoUMrm3z/KrnefMUnN8ofC0tukj8xvVG+oMOb5Yv4
DPypDr8kXzZPgvfUrdKU7FW5XYdfkzt0+HVdEkv+Quo1v3xD7tbhN411r/yl3KvDv9K1rEd8PYZY
8tfSSOo38qAOvy2N17PfysM6/I6Wv8RXmyV/J3+nw+/Kozr8L+obWl7G96ClHlWPmnmVnllZ6jHL
vJ866hmOZXWy1xg9jv2MsOy19lod/qH9vA6/YL+gw8bbm2X/zP6ZDm+139fhP9h/0OFjjhCWI6Nf
EzI6OfqosKLzYgUhY8XYXcKKTUhsFjLxYkKXLfFOVl+b3Zp9Q1jZ3Tk9GuLlz8pdljPe1uwm6Spx
P74WJV5nVZPHReN7VuF38XMPtMb7osQPrcIHo8QbrcITo8QnrcIfo8QzrcIro8Q/rcI3o8RLrcJD
o8RXrcJPo8RjrWqSofF3Z8mj2FcZ6blyk3hulHi1VUhM4r/xc894xovj5xIz/vEs/ONZ+HWUeMmz
8O4o8ZVn4eNR4jHPwtOjxG+ehb9Hib9Hib9HiQddhddHiR9dhe9HiTddhQdIiU9dhR9IiWddhTdI
iX9dhU9IiZddhWdIia9dhX9Iicddhb8+C7+7Cr+7Cr+REu+7Cj9+Fj4kJZ54FZ54Ff4kJf54FV4l
JV55FR7/LDxMSjz0KvxMSvz0KrxNSrz1KnxOSnz2KjxPSjz3KvxPSvz3KrxQSrz4KrwIWniklHj0
VXgUtPBOKfFOKfFOKfFOKfFOKfFOKfFOKfFOKfFOKfFOKfFOKfEMrPBRKfEPrPBUKfESrPBXKfEV
rPBaKfEYrPBdKfEbrGjb0vXLJyeU1Qhr9AOTJ4r4uMl33i2mTbxj6iSxxnz/dHNdn5LoKkRjo4jp
kcUjMqIkosLoKLqKnuJaMVgYO/CBYqQYKyaKyWJ6U9qg8IqsaKFD7cXleiTqJfqLW4xvHHGjuEOM
E/eIKeIBepWbPiTKRE5UCTNb7iK6iavEdWKIGK772yAxCi/pU8UMkRTWdYMG9Rf96m68oSSGD667
viQWkIPRzpaLvLhIJERHcaXoLfqJAWKo+KqwxCXiJjFa3CXuFfeJB0ldLipFS53bpaJaXC2uF63F
TOITIqKfuiAuFinRSXxFdBd9xDWiVtSLEbqsbUSdXk9PEA1imnio6a4Vwi+KopVIi8tED9FX1Igb
xK3iduGItuJmcae4W3xN3C9miYdHd54yWp0ztGwYgHGYhy1H3zFxqtUedoW94QA4GI4YfceUO63x
cBKcCmfA2XDu6NH3NFgL4Cr4PNwFj8BThrYaM+nee+w4zMISbAXbw86w29jJd4y2e8EBcAgcBSfB
GXDuxLvG3WEvhsvharhu4qT77rE3wS1wK9wBd8N98ODEe0dPtI/A9+AJeEqfnGx/Cs8ZOgqWwRCM
w+y9+scpwVawPewMu8FesN+9k8dMcgbAQXBIg4kfDkfB8XASnApnwNlTdI04c+ECuBgugyvhU1Pu
mjTWWQc3ws3wFbgd7ppyz+gGZy88BN+DJ+Gnhh4xZUqnyzw+GIVZWAXbws6anT3VsDesgbWwDtZr
Xu4ZAcfCSXAanAXnTrmvYYpnIVwCl8NVcA1cP1VLwLMJboFb4Q64G+6DB3lrpkXmP/Fr6ZGjSlz0
fxUy/nj/I5bp3uzo0cyrQ+W6x/v/H8R5vxD3bzEXppEi9CVpdjwierSJ/heGlR4DL/4//EqR+tJU
XKcEqwreK+Z/w+CXZvJLs/S/MfGl2epLMPYf0tJvtzx/jefLh3I6VEBO5i/4fPlfKdr8h1T6fdPu
P/ErRfFLMP6l2F2/9eeJZWKt2CJ2iUPiuDgjW8muskYOkWPlNDlXLpVr9Dpjp57HHpOfKo9Kqlaq
q6pRQ9RYNU3PXJeqNWqb+tDKW+2tHlatNdyaaM20FlgrrPXWK9Ye64h10jpnB+y83d7uYdfaw+2J
9kyB1xhR5rY3O9DsuNTsuF+z49ovHOt5iD1AeOXnx3pZ6Sy68Njb/gvp9XHZBo5t3TuTulZbubHB
Xk2//Zt+65p+h194dSTyhWPddyLbLyxND3Fhaa8ec+Fxn2Sz47bNjntdeL8+dc2Ox1x4vz6zm12/
vdnx6QuP+45sdrz3wuN+hWbHky6834COFz7/gD0XHl8fvfD66+svPK6raXbcv9nxgAuPb3blo/S4
G3UlcPPwpt/3/716HDyv6Xdx0++Kpt+1/17qIQubfpc1/a5u+t1w4VMPjV9YC0OHXVjK+g3Njrdd
eHzr4mbHS5odL212vLbZ8bovHOuRelizPjFq5xfavA6MntDseMGF6UcvvPD4zmZSv7NZrd05qtlx
s1Z059Rmx9OaHU+/sJWMe/fC8+P1ClvXjK3XF8f1fP8k7yPzF88Ef51MxmKxOG+pqPCknk28nFqf
+Km9Qa+MlXDkBrlBZ+Wu7TfJTU1re4uVku3mq0enDmgjlNEUyr20KH1v9Zm5vzI6ko76OKnXDpPF
CrFTHBVnZVyXoUxfHU+9IFRqfWqz5rOpFzVNbUf0jKekR3nzd6F6JN7Wq/k39PrwEL8vJ36rf3+p
jw/z+3JCr9z00W7NlxNv6rX9b3XJTIvOiqrEr/SKfIM+u4/flxNv6d/n9PF+fl/+QspfN6U80JTy
N00pDzalbCqvXpmau/2cu73K3T4/8xpnXufML754JvUcz7iRZ/wxz/j5mU2c+QlnnueMEh75mnxN
S93Vihh9iKsJsagVO7Uu9SPdT9w5hem3XUwtCyN/RzwuzP73Tv1PRt+MamnEl8aX6tX104mnqa//
+ZsY/x1/E+Pf6ipLXXWipy6IT/mfGvlvqxHjaV0y4zc1cpmuic7/VTWB9ANIP6il/6yuCSP9mJb+
IRFH+hmkn0X6lUi/hPRbIP2OSP9SpN8J6V+G9Dsj/cuRfhek/xWk3xXpX4H0uyH9K5F+NdLvjvR7
IP2eSL8X0r8K6fdG+lcj/T5IsC8S7IcEr0GCNUjwWiTYHwlep+W1SI8oxgLyEf3vYTFX/5utZ7zz
xNfFfLFQn9kgnhOP8hczH2NEmq/nwbv0+GT+YuYC/mLmN8WfxAnxhLSlI/5Rfk/+QDwp18ofiWXo
kVegQf4uuuOVaI2/h754FZri76MjXo12+AfohZ9CI/w0uuA1Kq96iGdUL3WV2KWuVleL3aqv6ive
VNeoGrFHXaeuE3tVraoVv1K3qFvEPjVUDRVvqSfUdrFf7VA7pEe9rd6WXvUH9QdZpj5WH8ty9Yn6
RPrUZ+oz6efvWgYc6dgy6Hgdr6xwyp1yGXX8jl/GnKATkXEn4SRkmr96mTFaYJk1+l+ZM5pfmTc6
X1lptL2yYPS8smg0vLJkdLuyhdHqyqrovOgL8iL9ho7Jm2KpWEbWxQqxanmL0erKyUaTK6fE+sTq
5FSjw5XfMNpbOddobOWjRlcr5xktrXzM6GflfKOZlY8bnaxcYLSx8ptGAysXxibEq+QT8Zbxlqp/
vFX8EnVdvG28vbo+fmn8UjUw3jneWd0Y7xavVoPM38pUN8dvj49Ug+N3xe9SQ+IT4xPV0PiU+BRV
H58ef0DdGn8wPkvdFt8X36duj/86fkCNjJ+Pn1ejEnqpqUYnVEKpMQn9n7ozkU6k1djEdxLfUeMS
3018T41PrE78QN1t3lbqnsTaxFo1KbEh8Zy6N/FO4j31tcTxxHH1QOJMcrKakZqa+qH6S+rnaWW1
SwfSAevedDadtRrSLdMtra+le6Z7WZPT304vt6amV6RXWtPST6efth5IP5N+xpqR3pB+znow/eP0
Juuh9AvpF6yH0y+lX7Fmp7emt1r/kH4t/Zr1SHpneo/1jfTe9K+sBem30r+xFqY/S39mPZk+lz5n
Lcn0y9RY38rUZeqsZZn6zDDr25nhma9aKzKjM6OtlZm7MndZ38tMykyyVmUaMg3W97Mbs5ut1UZD
bf3Q6KatdUYrbf3I6KOt9UYTbT1rdNDWhuwvs+9Yz+Vqc7XWVjNKiXr9f/+mUapz05ukq/6/5n/F
SPNtsGjZLI152+xqitGzO/tD+yM9Rf/YPs1cL+f2XXrJw7T6VY7lWOKAacviN6Yti4OmLYu3dVsO
ikNO2AmL35oWLQ6bFi3eMW1THKFt+mibft2OijJkalvuMLUtXze1LXea2pa/MLUtd5ma1LM4XYfy
Leqw1tShmmMkpHaap1e/NE+vjuhSDmZsEYwtkrFFMbZYjC1ljC0+xhY/Y0uAsSXI2BJibIkwtkQZ
W+KMLRnGhErGhCJjQokxoQVjwkWMCS0ZEy5mTGhlRgNxiRkNRGszGog2ZjQQbc1oINqZ0UC0N6OB
6OCYv6jR0bEdW3RyQk5IXOZEnIjorPtsQVweL8WrRBfTy8QVppeJbqaXiWrTy0RP08tEL9PLxFWm
l4k+ppeJvqaXiWtMLxM1ppeJa00vE/1NLxMDTC8TA00v0+9D3Y/0m1D3I1Fn+pG4hVnfUNOPRL3p
R+JW04PEbaa/iOGmv4ivmv4iRpj+Im43/UXcYfqLGG36ixhr+osYZ/qLGG/6i5hg+ouYaPqLuMf0
F9Fg+ov4mukvYrLpL+IB01/Eg6a/iNmmv4ivm/4i5pj+Ir5h+ouYa/qLeMz0F/G46S9igekv4pum
v1DDUuS/8H6+3Kwu7Dfxxv3/R+uVl5yy3ypfW76h/Pnyl8q3le8s31O+v/xQ+dHyY+Uny0+Xnyk/
77N9Pl/El/TlfVW+1r6Ovi6+al9vX42v1lfnq/eN8I3xTfA1+Kb5Zvrm+Ob5FvqW+Jb7VvnW+Nb7
Nvm2+Lb6dvh2+/b5DvqO+N7zHfd96PvEd9Yv/B5/wB/1p/0Ff0t/W38nf1d/D38ff3//QP9g/zD/
SP9Y/0T/ZP90/yz/I/75/kX+pf4V/tX+tf4N/uf9L/m3+Xf69/oP+A/7j/qP+U/6T/vP+M8H7IAv
EAkkA/lAVaB1oGOgS6A60DtQE6gN1AXqAyMCYwITAg2BaYGZgTmBeYGFgSWB5YFVgTWB9YFNgS2B
rYEdgd2BfYGDgSOB9wLHAx8GPgmcDYqgJxgIRoPpYCHYMtg22CnYNdgj2CfYPzgwODg4LDgyODY4
MTg5OD04K/hIcH5wUXBpcEVwdXBdcGNwc/CV4PbgruDe4IHg4eDR4LHgyeDp4Jng+ZAd8oUioWQo
H6oKtQ51DHUJVYd6h2pCtaG6UH1oRGhMaEKoITQtNDM0JzQvtDC0JLQ8tCq0JrQ+tCm0JbQ1tCO0
O7QvdDB0JPRe6Hjow9AnobNhEfaEA+FoOB0uhFuG24Y7hbuGe4T7hPuHB4YHh4eFR4bHhieGJ4en
h2eFHwnPDy8KLw2vCK8Orw1vCD8ffim8LbwzvCe8P3wo/G74/fCJ8Knwp+FzERUpi4Qi8Ug2Uoq0
irSPdI50i/SK9IsMiAyKDIkMj4yKjI9MikyNzIjMjsyNLIgsjiyLrIysiayPbIpsiWyN7IzsieyP
HIq8G3k/ciJyKnImcr7CrvBVRCqSFfmKqorWFZ0qulb0qOhT0b9iYMXgimEVIyvGVkysmFwxvWJW
xSMV8ysWVSytWFGxumJtxYaKzRWvVGyv2FWxt+JgxZGK9yqOV3xY8UnF2aiIlkVD0Xg0Gy1FW0Xb
RztHu0V7R2uitdG6aH10RHRMdEK0Qc9uZurZy7zowuiS6PLoquia6PropuiW6Nbozuie6P7ooei7
0WPRk9HT0TPR8zE75otFYmk9LraMtY11inXV85k+sf6xQXr+MlzPSsfHJsWmxmbEZsfmxhbEFseW
xVbGnoqti22MbY69Etse2x3bHzscey92InY6diZ2Pm7HffFIPBnPx6vireMd413i1fHe8Zp4bbwu
Xh8fER8TnxBv0OPm7Pjc+ML4kvjy+Kr4mvj6+Kb4lvjW+I74bj2OHoofjR+Ln4yfjp+Jn0/YCV8i
kkgm8omWibaJTomuiR6JfokBiUGJIYnhiVGJ8YlJiamJGYk5ifmJxYnliVWJNYn1iU2JlxLbEjsT
exIHEkcS7ydOJE4lPk2cS6pkWTKUTCYLyZbJtslOya7JHsk+yf7JgcnByWHJkcmxyYnJyckZyTnJ
+cnFyeXJ1cm1yQ3J55MvJbcldyb3JPcnDyXfTb6fPJE8lfw0eS6lUmWpUCqeyqZKqVapjqmuqR6p
fqkBqUGpIanhqVGp8alJenSakZqTmp9alFqaWpFanVqb2pB6PvVSaltqZ2pP6kDqcOpo6ljqZOqT
1Nm0SHv0OyGaTpu/BJ5um+6crk73SQ9ID0oPSQ9Pj0pPSDekp6Vnph9JL0gvTi9Lr0w/lV6X3pje
rN8AetxP708fSr+bfj99In0q/Wn6XEZlyjKhTDyTzZQyrTLtM50z3TK99DugNjNYj/tjMhMzUzMz
MrMzczMLMoszyzIrM09l1mU2ZjZnXslsz+zK7M0cyBzOHM0cy5zMnM6czapsWTaSTWbz2aps62zH
bJdsdbZ3tiZbm63LDsuOyo7PTspOzc7Izs7OzS7ILs4uy67Mrsmuz27KbtErmp3ZPdn92UPZd7Pv
Z09kT2U/zZ7L2blALp7L56pyrXMdc11yPXJ9cv1zA3NDciNyY3ITcg25abmZuTm5eblFuWW5lbmn
cutyG3Obc6/ktud25fbmDuQO547mjuVO5k7nzuTO5+28Lx/JJ/P5fFW+db5jvku+Ot87X5Ovzdfl
6/Mj8mPzk/LT8rPyc/ML80vzK/NP5dflN+Y351/Jb8/vyu/NH8gfzh/NH8ufzJ/On8mfr7QrfZWR
ymRlvrKqsnVlx8ouldWVvSv7Vw6qrK8cWTm+sqFyeuXsyrmVCyoXVy6rXFn5VOW6yo2Vmytfqdxe
uatyb+WBysOVRyuPVZ6sPF15pvJ8wS74CpFCspAvVBVaFzoWuhSqC70LNYXaQl2hvjCiMKYwodBQ
mFaYWZhTmFdYWFhSWF5YVVhb2FjYUthW2FXYVzhUOFo4VjhZOF04UzhftIu+YqSYLOaLVcXWxY7F
LsXqYu9iTbG2WFesL44ojilOLE4tziw+UlxQXFJcUXyquL74fPGV4vbiruLe4oHi4eLR4rHiyeLp
4pni+ZJd8pUipWQpX6oqtS51LHUpVZd6l2pKtaW6Un1pRGlMaUKpoTStNLM0pzSvtLC0pLS8tKq0
prS+tKm0pbS1tKO0u7SvdLB0pPRe6Xjpw9InpbMtRAtPi0CLaIt/pe5bwKMqsnXrsTuEkA6ke9eu
3U0I6U6nGyPyCvISQWMggATQoEZEBIyIISIiECC8BOSlPAXCSwRG0HEU0eMDFVEQEkBk1KMoiILI
ICKiIigi6qn6d/mYO947c6/nfOce+/Ov1atWrbVq7eqqtTq9N24kMxKL5EaaRVpF2kfyI10iPSK9
I30i/SODIuWR4ZHRkQmRqZFZkXmRxZEVkTWRRyLrI09HNkW2RXZH3o4ciByJnIicjpyPWtHUaCDq
RjOjsWhutFm0VbR9ND/aJdoj2jvaJ9o/Ojg6LDo6Oik6IzovuiS6Krou+lj0qejG6Obotuiu6BvR
vdED0cPRY9GT0dPRc9kkOyk7NTuQ7WZnZseyc7ObZbfKbp+dn90lu1d2SXb/7MHZw7JHZ0/KnpE9
J3th9rLsVdnrsh/Lfip7Y/bm7G3Zu7LfyN6bfSD7cPax7JPZp7PPx1gsOZamUstwLCsWjzWOtYi1
iXWIFcS6xXrFro31jQ2MDY4NjY2IjY1Nik2L3RdbEFsSWxl7KPZobEPs2dim2NbYjtie2Nux/bFD
saOxE7HTsfM5Vk5qjp2TkRPLaZzTIqdNToecgpxuOb1yrs3pmzMwpyxneM7YnMk5s3IW5CzLWZPz
SM76nKdzXsh5Jac6Z3fOWznv5RzKOZbzZc7ZOIknx+vF3XhmPBbPjTeLt4q3j+fHu8R7xK+N94sP
ig+Nj4pPiE+Lz4kvjC+Lr4qviz8Wfyq+Mb45vi2+K/5GfG/8QPxw/Fj8ZPx0/FyCJJISqYlAwk1k
JmKJ3ESzRKtE+0R+okuiR6J3ok+if2JQojwxPDE6MSExNTErMS+xOLEisSbxSGJ94unEC4lXEtWJ
3Ym3Eu8lPkwcSRxX2aSlf7Om8Bng88CtwGrgLuAe4FsqM1UI2UbAJIPPA18C7ldYC3QydCdDJhky
yYZfDdwF3APUo1IgkwJOiuEcVFgH/FRoS4W2VMPZCqwG7gLuAeqxfsikQUNdjKoLOh10OjxJh4Z0
8APQH0BvAGMD6A1AfwD6A9Af0L+9IzdCUhh8Caj1OOA40OCA74AvQUvQLmy5kHQh6cKWC1subLmw
5erf/CnUFsMYFcaoMEaFIZ8Bfgb4GeBngN8AnAaw2wAxmUI3AJ8GbgRuAW4H7gS+DnxTXW2FkH0Y
eI/BjcBNwH0Kp0PrdPROR+909E6H1unQOh1ap0N+JmRmgjPTcA7p6ha+10BbDbTVQLIGPtZAWw20
1eixdVLROxsRnYO5zgE9D2PnwYd5GDsP/PnQPB+98zF2PnrnQ/N8aJ4Pr+bTdxR+CMmFBjcBtZ5F
4CyChkXgLwJ/MbAKVqogUwWZKlipgpUqWKmClSoVY43a1lKMWopRSzFqKeSXg78c/OXgLwd/BTgr
YH2FjiFN0pIKnwZuBG4BbgfuBL4OVNdWI2RzgckGNwI3AbXW2qBToDsFMimQSTH87cCdwNeBehSu
jMLXgR5HxYb6wU+DtjRoSzOcLcDtwJ3A14F6bF3I1IOGdIzCJ5YGQQfhSRAaguDb0G+j18ZYG702
9NvQb0O/rWNPb4KkNLgJqPW44LjQ4ILvgh8CHQIdhq0wJMOQDMNWGLbCsBWGrbC+2gq1xQyMysCo
DIzKgHwm+JngZ4KfCX5DcBrCbkMdExbTn3DWFJjHpim8FJgPLAAWeqg1KHqGwiJwij0Evxj8EnBK
gYOBZcByDyE5HHSFh+BUgq7Sf/1kC/Tnjy3UO5FC7dWzwCpwlqJ3DSRf400UVusZsR16vgq3//z5
Zq+B8zp692pJTiD/vVl7G35edbwhkGgOZ7qX19GSxApMB44CjgaOBY4DTsAp9ryRmgScDJwKnIb+
PehPNqh1JWOHTobGZGhMhsZkaEw2GlMhmwo6YHAUcDRwLHAcUI8LeOMCa3WEFD6pEb+ZXqvtKVrr
cA1q/uOQfBySjxvOVtBaJsPgKJwC2uMp4EwJjARWAMcAK4Hjsc9vNFITgXcDpwDvQf/r6J9ucCT2
8i2gK4BjgJVArXG60VgD2XtBzzc4ElgBHAOsBOpx871xgX/XV1ThBo16hKK3gNY6qgxq/vuQfB+S
7xvOFtBaZrnBkdg5sR9qjsKRwArgGGAlcDz2xo1GaiLwbuAU4D3oRzxoisGRWJVbQFcAxwArgVpj
itGYBtk00LbBkcAK4BhgJVCPs71xQX2nlMYNGvWIoL4zWNNaR9ig5teGZG1I1jacLaC1TKbBkdhb
9BW0kB+kAgNAV9/toXMRfUcH2mdM+zP/SXxGvH6L7ke+0giYAg1pGoOrNCc4E5wUk3Uh2wxGgTH9
6QGdDDoVdCroAOgAaAFagHZBu6DrQLOl7yPRWRq8UTmbydQ8rudbhpfHWi8T/bsOnQn5sC581g6F
TeBbLS9zBb8W+LVwnteytuHzvQuz1i3yWcXVWKNmuAmZWm2Tse6CZ5quA111kIvVsfQel6rkuc5Y
oSPNQ0ilwWJdfR+DylN3gVfX48FSPcjWg9566E0Hne7RkEyHpzoCz5i2Gq3necB4HjSoRwsPYVUh
fBfQ5aDHQY+ioVG3L3ktrErISI/GKAlfXWszsAa4DWtmq1lDuxCNEHamEEaGoQUrmNQHXd9ktZpu
gJywAXobwMYU5Dw1wPnAKv13ap1fqdPWa5827c/8DdjDdqoTw2t1zvkwMrGZ0DBbryS7m+aIZzRH
5Zab0Otlksiarb8AH9d7HOjpoGtA14CeD3o+6IWgF4KuAl0FehZW7RS6D7ud57PKQ0326XH34d1y
Lx/Hqp2KCExFBB6HV9PAmQbONKzUaYi1yrcxX90iI8c1ma6vhn0z8s4ZOrL8DcR3JmzMgq5ZiPss
rNR7cfVqsF5rEFEdJb1yZkN2NuzOwfqYY1bOHI8He3MxYi4iPRcj5oGe59GQnAd/9dyfNu12tBtM
TDz/FxjUoxd6CKsKaQ0irHUtQs8i9KicHHFU7+i7ROflum8xLC+G9GL4WIV1WoWZVsGXKuNLFdYK
I0uwQy7ByKXQshT0MtDLTIau6RXIzVegdwVszPIsQWYpMv3lwCnW5wqP6+gHM3HnVhLyujSgDQzj
lxdhb3Xo7FJHBu9/5m/AKeT1J3nrRWXyO5Fpb0K2rFCka459DpxUky2jStDrUeHj+nwCnQI6DXQa
aBu0DVqClqDDoMOg/dCcpKOts2t4Y3trWbUe1/Mt06s/9FqmtZDVY6el2GlpM/hW26s4wK8Nfm3k
2LX1tdFVBmad4q0L5fE2oLp64iJk2HVMpbETnmnaD11+5NB+C9WFXtG60oCOeh5Cqh4s6v2Ua9Rr
i6Z7PFgKQDYAvcjsVCw1HfRoSAbhqe2tIrTb0W4wkXkavgloEhgtPYRVSXdCF/ZSVWvoHhc9rrei
NQ8SIfSFPBrSIfgY1itaYQ1wG9aK50vYW9G0PrKU+hiZAS3IGGkD0A1MFbIPdYauPxqityFs+D1L
kMlANZMJTMKKrtGSrClqAq8u+W2tkCGeA24GvgLcCtwI3AasBu4AvgDcpFHvLgr3aNT3ImpU+rx2
s2lfMe1W02407TbTVptWaXf82huFm4GvALcCNwK3AauB2psseJ8F77PgfRb8zoLfWfA7Cx5nweMo
5KOQj0I+itlGMSqKUVGMikJ/FGOj3ljMMGpmGDUzjJoZRs0Mo2aGUTPDqJlh1MywOWbYHDNsjhk2
xwybY4bNMcPmmGFzeBCDxzF4HIPHMXgcg8cxeByDxzEj/wJwE2rRXUB9fXKhJxd6cqEnFxpyoSEX
GnIxNhdjG6O3qcFtQFS2sNIUkk0h2RRWmsJKHqzkwUoerOTB2zzoyYOePOjJg5486MmDnjzEN8/E
N8/EN8/EN8/EN8/EN8/EN8/EN8/EtwzxLUN8yxDfMsS3DPEtQ3zLEN8yeHCptV6j/gWtwpeBW8B/
AvSrwO3AGuDzwBchoyv+S/XeofB1cPQclE6vFS+Z9mXTbjH9T5j3r5p2u2lrTPu8aV808vtUy1g+
fM2Hr/nwNR9e5sPLfHiZD//y4V8B5AsgXwD5AsytAKMKMKoAowowtwKMLTBj1dycB7UG50GtQeHL
wC3gPwH6VeB2YA3weeCLkNHRKYQPhfChED4UwodC+FAIHwrhQyF8KNS/nFa4C/ga8HngixgFnYh4
ISJeBP1F0F8E/UXQXATNRdBcBA1F0NAT8j0hUwy6GGOLMbYYvhV7vdBQDA3F8K0YvhXDt2L4VgzN
xdBcDN+K4VsxfCuB/hLoL4H+Eugvgf4S6C+B/hLoL4G2EmgrgbYSXP8Ss55KzHoqMeupxKynErOe
Ssx6KjHrqcSspxKznkrMeiox66kU/pXCv1L4Vwr/SuFfKfwrhX+l8K8U/pXCv1L4V4rZlmK2pdBd
anwtNb6WGl9Lja+lxtdS42up8bUUvjLJtE+SaZ8UvgzcAv4ToF8FbgdqnwZjDoMxh8GYw2B4Pxje
D4b3g+H3YPhdBvkyyJdBvgxzLsOoMowqw6gy6C/D2DIzdh9Q+1tm5llm5llm5llm5llm5llm5llm
5llm5pnAPBOYZwLzTGCeCcwzgXkmMM8E/CiH3+Xwuxx+l8PvcvhdDr/L4Xe5J4+1Wq7WKtffE8Lz
csylHHMp9zi4fuW4fsNhYTgsDIeF4dA9HLqHQ/dwaBgODSMgPwIyFaArMLYCYyvgXYXXCw0V0FAB
7yqgpwJ6KuBJBTypgCeV0FYJbZXQVgltldBWCW2V0FYJbZXQVgltldBWiVhXmmtUaa5RpblGleYa
VZprVGmuUaW5RpXmGg3BNRqCazQE12gIrtEQXKMhuEZDcI2GwA+TA4nnTLvZtK+YdqtpN5p2m2mr
TbsDVsfrE0zhZuArwK3AjcBtwGogchQvLzFWo8Zq1FiNGqtRYzVqrEaN1aixOhdW58LqXFidC6tz
YXUurM6F1bneye2d1sZqnrGaZ6zmGat5xmqesZpnrOYZq6thdTWsrobV1bC6GlZXw+pqWF0Nq4vw
TfVcD5HLLtS0/BvoRcDF5vvtXUBNPwDcAnwMuAa9awy9V+E60I8Cd+Kb7Vc9RJa8Q9PuBaCRr7Nd
5lvxnUBNvwk8AzwE3IvevYZ+R+F+0B8Cf4T+sx6C8wOs3O71An8y36XvBGoafzXiuUABrIPeOoZW
Vnhd0EFUuHNx7xsh+ulrtUlT9UojzYl+YmM70oFIchkpJBmkG+lOYqSHeuknMPQljUg/9WpJ+pNb
yMXkVnIbuYQMIXepESPJRDXiAbKWXE0eIY+RG8gG8pySe568RAaTl8l2cjvZSXaREWS3eo0ie9Sr
grxJ3iajyV7yARlHDqrXVPIROUruIcfU615yQr3uIyfJN2Q2OUt1bZ5FG5HV9ELalDxKm9Pm5Ama
R9uRDbQ9vYxspPm0K3mJdqc9yHbai/YiO2gx7Ud20v60P3mHDqS3kr30NjqEHKC305HkIK2gd5Nj
rA1rQ75ml7D25DS7nt1MvmHj2FRK2RK2hKawJ9gTtA57mj1DU9lz7Dmaxp5nL9C6bDPbTNPZbrab
BtjH7GMaZMfYp9Rmn7HPqMM+ZyepZKfYKRrilFMa5i53aX3egGfSDJ7Fs2gmj/Js2pAneIJGAjMC
D9Go/h0a7RhYH3iLdg68HdhPhwQOBAkdHmTBZFoVTAmm05XBBcEVdF1wZfBB+mRwdXAN/bfg2uBa
+kzwz8Fn6LPB54LP0VeDLwZfpNuCLwVVNRv8a/Aw3RU8Yjv0Q/sSO5+l2wV2Zxayu9hdWYZ9pV3E
Mu2edl8WsfvZ/VhTe6A9kDWzS+3BrLk90Z7IWtl321NYa/seex5rZy+w72ed7UX2U6yL/bT9VzZI
cOFnk0VdUY/NFgERZHOFIxw2X4RFnC0QjUQj9qBoLBqzVaKJaMFWiwJxHVsnrhcj2QuiQsxj74pn
xbPsK3FQHGKnxBfiS3ZanHVS2TdOmtOM13FaOLfxJs4QZyUf5KySlC+TXMb5edlIlllZslyOs26W
E+Qca4ScJ1dZ98g18s/WYrlf7rdWyo/kYetBeUQesVbLo/KYtUYelyestfKk/Np6RJ6RZ6z1bgO3
gfWEm+PGrQ1uI7eR9ZSb6za2/s1t4jaznnVbuK2t5922blvrZXegO9B6xb3NLbO2uOVuufWqO9Qd
Zm1zh7sjrBp3lFtp7XLHu+OtN/BUNR+pR6OsJe9slajPUTuSrz5LV5M+ZCApI8PJWDKZzCILyDKy
hjxKniIvkK3qs/EW2U8Ok+PkFDlHCU2iqaGdhIe2hbaHdqGtDr2Gtia0G+2O0B7VblfUX9FuD72B
tjr0Jtqa0Ftod4TeVm21knsH7fbQXrTVoXfR1oTeQ7sjtF+1NUrufbTbQwfQVoc+QFsT+hDtjtAh
1e5Qch+h3R46jLY69DHamtARtDtC6tRWvf+usDqkzl/Vc1Dhjj8QkaOY+bbQJyYyx0xkPjWROW4i
85mJzAkTkc9NRE6aiHxpIvKVicgpE5GvTUROm4h8YyLyrYnIWROR70xEzpmInDcR+cFE5EcTkZ+8
iISJicjf1Py3hb5ARM4gIt//sYiEmReRMPciEra8iIR9XkTCSV5EwsleRMK1vbUSTvEiE67jRSac
6kUm7PciE07zIhOu60UkXM+LSDjgRSQc9CIStr2IhIUXkbDjRSTsehEJh7yIhMNeRML1TUQyvIiE
qY5IuJZeKeF0HZGw/IMRyTQRaWgikmUiEjERiZqIxExEckxE4iYiCRORRiYiuSYiF5qINPbWSvgi
E5kmJjJNTWSamcg0N5FpYSLS0kTkYhORViYirU1E2piINEBEshGRC/RKCef9wYi0MxG5xESkvYnI
pSYiHUxELjMRudxEJN9E5AoTkQITkc4mIoUmIl1MRLqaiHQzEeluIlJkItLDRKSnWSu9TGSuMpG5
2kSm2ESmt4lMW0SkIyLSCRG5Uq8UlcdQ7TfusyghF9BP6HH6OT1Hv6c/0p8YZz5Wi6UwP0tj6SzA
BHPYLN6GD+a38TI+hJfz2/lQfgcfxu/kw/ldfAQfyUfxCj6aj+FjeaUvK/gw/m53lB4lhH5KPyWU
nqAnCKNnqfr80/P0B+Jj6j9Si1nMIsksiSWR2ky9SAqrw1JJHVaX1SN+FmQ2qctmspkknbfmrUmA
9+a3kqCvoa8hSQTXBdepzIqRMEnh1byG7+A7+S7+Gt/NX+d7+F/1LJV/lZilllnGl/MV/AG+kj/I
V/HVfA3/0z/I/J/16DtW3N/csdISd78TSFTj35z/X+9pufg3fUxloEQ/LkZ58hDu2+9G9HMZWv56
hzpfp7J5orxULX9ItWvxfqVu1fuVSj6JpPGHDfdhw1V7gfJb/4UrRuryJXwpv5ffx2fzOXwun8fn
8wX8fr6QL+KLeZWSsRBjgjkx/ij/C0nlT/InVSbLVEaawTvyy/kVvBPvwrvxIt6T9+M38f58AB/I
b+al/BY+iN/6e9ddz4V34B2U5sv4ZWrW+Txf6S/gavXzQl5ILN6VdyU+3p13J0m8B+9BaqnreSNJ
VivrTjV/z3oHNTpfjSpU0t2VVG9+Db+WX8dL+PW8D7+B9+U3/t5KhPWOvKOyfjnXT42/gl+hrHfi
nZT1LryLst6Nd1PWi3iRst6T91TW+6nVlIw4/Gq9o7J+hbLeRVkv+l3rvxMPNdqn/L5cWS9QFpny
vZuy2ENZSVLeVpJko1/JaAndr3v/1c8U9HfA7PIxr0LMqDvmoj8TSr8vk92ndq1aNJnWpim0Dk2l
fppG69J6NJ0GaJDaVFCHSurSEA3T+jSDNqCZtKGqDiI0SrNpjObQOE3QRvQCmquqhcb0ItqENqXN
VM3QQlUMLenFtBVtTdvQtrQdvURVD5fSDrQjvYxermqIK2gB7UQ700LahXal3eiVqqIooj1oT1VT
XEWvVjVFb3oNvZZeR0vo9bQPvYH2pTfSfvQmVWcMUFXGzbSU3kIH0VvpYFVtlNEhtFzVG0PpHXQY
vZMOp3fREXQkHaWqj9F0DB1LK+k4Op5OoBPpJHo3nUyn0Kn0cfol/YqepmdYKbuFDWK3ssHsNlbG
hrBydjsbyu5gw9idbDi7i41gI9koVsFGszFsLKtUtct4NoFNZJPY3Wwym8KmsnvZWfYdO8e+Z+fZ
D+xH9pNKFChnnHOL+3gSr8WTeW2ewuvwVO7nabwur8fTeYAHuc0Fd7hUtUuIh3l9nqHrF95Q1S8R
Xb3wGM/hcVXBNOIX8Fx+oTgpTolvxFfia3FGfCqWBo4E/hY4GvgkcCzwaeB44LPAicDngZOBLwJf
Br4KnAp8HTgdOBP4JvBt4Gzgu8C5wPeB84EfAj8GfgqSoCqngjxoBX3BpGCtYHKwtqp+6gRTg/5g
WrBusF4wPSiCYft9+4D9gf2hfdA+ZH9kH7Y/to/Yf7OP2p/Yx+xP7eP2Z/YJ+3P7pP2F/aX9lX3K
/to+bZ+xv7G/tc/a39nn7O/t8/YP6vWT/ZNQS0rVMpbwiSRRSySL2iJF1BGpwi/SdHUj0nV1I2z1
coRUr5CqcOqLDNFAZIqGIktERFRki5jIEXGRUHXPBSJXXKgqn4tU3dNUNBPNRQuRJ1qKi0Ur0Vq0
EW1FO3GJaC8uFR1ER1UVdRKdRaHoIrqKbuJK0V0UiR6ip+glrhJXi2LRW1wjrhXXiRJVOfURN4i+
4kbRT9wk+osBYqC4WZSKW8QgcasYLG4TZWKIKBe3i6HiDjFM3CmGi7vECDFSjFL11mgxRowVlWKc
GC8miIlikrhbTBZTxFRxj5gmposZYqaYJe4V88UCcb9YKBaJxaJKLBHLxGXicpEvrhD3idlijpgr
5onj4jNxQnyuazZxWnzrnHA+d046XzhfOl85p5yvndPOGedb56zznXPO+d457/zg/Oj8JImkso5M
lX6ZJuvKejJdBmRQ2iqkjpTSlSEZlvVlhsyUDWWWjMiozJYxmSPjsplsLlvIPNlSXixbydbyEtle
dpAd5WXycpkvr5AFspPsLAtlV9lD9pS95FXyalksr5HXyutkibxe9pE3yL7yRtlP3iT7y4HyZlkq
b5GD5K1ysLxNlrmFbhe3q9vNvdLt7ha5Pdyebi/3Kvdqt9jt7V7jXute55a417t93Bvcvu6Nbj/3
Jre/O0BVhTe7pe4t7iD3Vnewrg7dIao6vF3Vhne4w9w7VXV4lzvCHanqwwp3tDvGHetWuuNUnTjB
nehOcu92J7tT3KnuPe40d7o7w53pzgp/Fj4R/jx8MvxF+MvwV+FT4a/Dp8Nnwt+Gz4a/q99D/6rG
u5+UPkYfIxPpSfoFmURP0a/JZNxhOpXNYrPIWtxnug73me7Hfabv4z7TA7jP9APcZ/oh7jM9iPtM
D+E+049wn+lh3GdaL6guC03HfaYBff8u3WHvtF+nu3FX6Zu6Rqf7HMdpRk867ZzbWG3cW9o2/Hr4
XTY+vC/8PpuBe0vvVWf6NHXWB1Q2ESddVO46Tj9JyfkGz5xRlGzwy1Nw6hGHZMg2hImdUmV8Ypds
p/A1eekvsl3U++dUbZ2q9Lkkk8RkN82RKhsUm2V3ha/IIoVbZe9fxgwApfINFZ8MlbxEWVT/KwIs
prKYxkzl8qwpa6pyiTyWpzRTlWMn/aydNNb3o1P9LzLrXyvUAaq6SNOq1e/Szbt0nY+QT9WL0NV0
tcoUH6JrlcSj9C+K/8+1djV6uv5faGW+wezJfzgp/zvOyf+mU/J/0umorNyiPBzN7vr1lFTejhDH
2eD/2pPS/lEQwYQQrmiDE/OgOiuP6jPM/kydRxfgfDylzkZ9Knpn4k//4mno/JNT8B/PwJbq9Pv1
3Pv5VPn/7fz79ZSbr07tVr+cg0vFMpV1fIh8Q+caOtM4bn8qFniZhlio8oyv7TOirc4yRDv7nDkj
1fkoR8iRcpSskKPlGDlWVspxcpqcLmfImXKWvFfeJ2fLOXKJXCqXyeVyhXxArpQPylW/e6p+8wfO
1Qb/wsnaRraV7XC+Xvq7J2wXdcZ2k1fK7rLo787a3v/b03bAf9J5+/en7YD/jPPW/ljc/0/P3CvI
FKL/zab7SLWqUHaQXYqzm7xNOpO95BjpST6jPjIQJ/J4dinrQCawy1gnMokVsl5kGrua9Sbz2LXs
RnI/u4kNIMvZzexmshLfBzzIXmXfklV4Gsc7PsvnI+/6kn3JZJ8vxZeizu5UX6o6u/XzOQ746vmC
6ux2fI46qZ8NfKxOajtoq5N6dnC2OqnnBufSQHB+cD4NBh8KPkRt/b0CFXaWHaOOHbfjtL7dyL6Q
ZtgX2c1olt3CvpjG7NZ2Pm1kF9jdaUu7h92PXmr3twfTHvZQeyi9zr7TvouW2CPtCnqDygHm0H72
PHsxHW4vUZnAGPsN+x36hP2uvY8+I5aLlXSjWCXW0E3iIbGWviweFuvpFrFBPEN3iiPiGP2rY6mc
4W2nkcoZPnAGOLfRo85dzgz6hXOf8zDzOX9xdrOI84ZzjF3hcrcz6+vOdeeyVaFrQtew1eED4aNs
TfhY+Dh7vH5R/SK2Ad846F9hpuH5ZPeSGsPp+necHWQAf5O/xf+dv83f4Xv5u/w9vo/v5+/zA/wD
/iE/yA/xj/hh/jE/wv/Gj/JP+DH+KT9O76HT6HQ6g86ks+i99D46m86hc+k8Op8uoPfThXQRXUyr
6BK6lC6jy+kK+gBdyWfyWXwcH88n8Il8Er+bT+ZT+FR+zx/iTePT+Qx8W2LhGbRTyAoSxvceLVW9
XEla4XuPfvjeo7+Sa0fC/y++6293oNv75if8m29+9PN7mMqXypVMkLVkF6scqi1TmZk+TVXepE5S
kiS+E9+TZPGDQ0kdRzouqeeEnQYk4BQ6XYjjdHOKiOv0cnqTDLWffUEiajc7o7I3tV+RC9R+FSAX
6j2GNFV7TCFprncWcrHaWXqT1v/gT2v405Tp+1HCyp9W8KetyuPaq/zXUl5NID7l1d0kWZ3vU0lt
+JYC3/zwLQDfbKehE1FeZTsJUh9+ZsHPqFPi9CFxp6/Tn1wAb5vA2+bwthW8baN2Voe0V/tqA9IR
nneC54Vq7+tDrlQ73wDSwzzbqLv6/xA8b4MnuWUhGyS/cDTVSK3b/nTQLzym8rxHyc/P59U8Rlw1
19Ym9hbmmqTmOpHUwhWog7n6xUFxkKSpmuwLUlfl6FxdB5+TqqLuqFnGnAucZqSVytf7kw7OQOc2
cos6X86S251zkpKx6vxoQCar0yFOFqkzoRt5QF2HAWSj2rnLyB51eo0je9WJNYd8qE6pVeSo8smP
moOoPGwqiaDayEe1cQWqjQJUG51QbXRGtVGIaqOLriFIV3FSeXmVfj4NKXZOyD+TPf8FGimek/o/
R++va2YgrnxbrP9ev1kzbX9dM2QC6fALj5FhJPc3a0ZVUIQ7fkcQ4jR32pLaTpmyo78fTPF8hrcR
eBuFt9nwNgZvc+BtHN4m4G0j+NnMzPxn7IFdNwM7VCpqk4fwb9U8qr/fVb6ESZaq+xrTVfpuCPon
3LWwVu/OVH+3fh/9M+5T0HdbzMGuPUNVOb8+E6wfZqL2GlXx6SdqEXJcvag+zQiz59hzCLf32HuI
JVaKlcQn1og1ai9aL9aTWu56dz1Jdp90nyS13Wq3mqS4e9w9RFVb5ELzpK5ZsPmSOtOTcKbXU2f6
GyRIDquXq9b3URKi6mAm4cCuwGukPp6J1QDPxMpSJ2kjErEvtBuTqN3Wbktidnu7Pcmxu9pdSdwu
sotIwr7GvpY0sq+3rye5+q/r5EI8H6sxnox1EZ6M1QRPxmpmT7Ink5b2fHsxaa3O1gfJpfYT9hOk
k6q4d5LOeG5WIZ6b1QVPyeqGp2Rd6T7griTd3RfcF0kPPNeql7vD3Umuct9y3yHFeKLVdaGCUAEp
CakXuR5PseqDJ1f1RUQ568g6s2v0OmEdVNZCWCeVtVDWW+Ur+gv+R8hVav2kOXWdek66E3CCju0I
tZZaOHlOS+dip5XT2mnjtFXraohT7tzuDHXucIY5dzrDJZNcWtInk2QtmSxryxSZkI3kBTJXXigb
y4tkE9lUDpHl8nY5VN4hh8k75XB5lxwvJ8iJcpK8W06WU+RUeY+cK+fJ+XKBvF8ulIvkYlklV8s1
8k/yIblWrpMPy0ekXj+1dWahVrnKLBStMgu1w3+ndrT6KteNq1NmoNq/LlL59zi1e09T+1dHlWev
Il28fCEog2GsvEl0suG4wfq/4fzzOOkxoWDGb8Z0JlkBGXACbiAUCAfqBzICDQKZgYaBNoG2/vf8
+/z7/e/7D/k/8h/2f+w/5v/Uf9z/mf9L/1f+U/6v/Wf93/nP+b8n+u6xP/CMT387/yUkxf+2/12S
6j/gP0jq+Y/4PyG2/4T/C+L6T/u/1X/fqXWUnKc/MoulsHrMUftClDViTdRJ005lsJ1Zd5W7lrB+
ancrUzX1KHXeTGYz2By2kC1jq9g69hh7im1km9k2tou9wfayA+wwO8ZOstPsnKqjk1TNHFD1caaq
hXN5M96Kt+f5vAv+FtKH9+eDeDkfzkernGeqypzm8cV8BV/DH+Hr+dP8Bf4Kr+a7Veb2nsrSjvDj
/Ev+DT9vMSvZSrNsK2xlWXGrsdXCamN1sAqsblYv61qrrzXQGmwNtUZYY61J1jTrPmuBtcRaaT1k
PWpt0P9ekrXV2mHt0U+WtQ5ZR60T1inrrPWjyrtTVHbt+DJ8UV8jXxNfS18732W+zr7uvqt9Jb5+
vlJfmW+Y7z/au/PgqIo8DuA9E153Jv3tQKaTMAwQQghXOCXcICIQ7tts5BQDghEQNYYrQAwQUcIp
IiCiKLIsy3ILKPdNAFnAiIiIqIgroiL3JR7fydYWDEftau0f+8fWt+pTyctRNW/e6/51vzf9hjgj
nTHOi85kZ7oz23nTWeAsdlY67zmbnB3OXuegc9g55pxwTjlnnIvOdSmklJBe6ZMxMl4myOqytmwo
m8iWsr1Mlt3ko7KfHCjT5TCZJXNkrpwqZ8g5cp5cKJfKVXKd3CJ3yX0yXx6Rx+VJeVqelZflDeVW
oSpcRSq/ilXlVGVVQ9VVjVQz1Vp1VCmqh+qt0tQglaEyVbYapyaqaWqWekPNV4vUcrVGbVDb1G61
Xx1SR9UXwq2TcD9tjka0BR6gLdGYtsKDtDWa0DZoStuiGW2HJNoezWkHtKAdwfNId0Ir2hmt6UNo
Q5PRlv4J7WgK2Evoh9GBdkFH2hWdaDd0pt3xEO0Bnku6J3iW6UeQQnvhYfooutBUdKW90Y32QXf6
GNiG6b7oSfvhEfo4etE0sArWTyCV9kdvOgB96EA8Rp9EXzoI/ehTeJw+jTT6DJ6g6ehPn8UAmgHW
u3ownqRDMIgOxVN0GJ4WblQwsfz6QbCP1U3A/kmvxCL6DtiT6RVgq6SH4xmaiXQ6As/SkcigozCY
ZmEIfQ6sYnU2htHRGE7HIJOOxQiag5H0eYyi45BFX8Bz9EVk0/EYTXPB9kZPwFg6ETl0Ep6nkzGO
TsELdCo4gtAvYTydhlz6MibQ6ZhIX8EkOgOT6UxMobMwlb6Kl+hsTKOv4WU6B9Pp63iFvoEZdC5m
0jcxi76FV+k8zKZv4zU6H3Pon/E6XQCOMfRfMJcuBKsB/Ve8RWuiMq2FKrQ2qtI6qEbrojqth/to
fdSgDZBIG6ImvR+16BospYswjy7GfLoUC+hyLKRLwDpDLwPrDP03sPKIOBdxnl6IuEgvRVzm9qZo
QJuhIV2HlXQ93qEbsIpuxGq6CWvoZrxLt4BtsN6KtXQb1tHtWE93IPAZ1J3YSHdhE83DZrobW+ge
bKV7sY2+j+10H3bQv2Mn3Y9d9AA4WtUHsZt+gD00H3vph3ifHsI++hECq6gcButk/TEO0CM4SD/B
B/Qo8umn+JAewyH6GT6ix3GYfo6P6Rc4Qr/EJ/QEjtKv8Ck9iWP0a3xG/4Hj9Bt8Tk8h0Ep8iy/p
aZyg3+Er+j1O0h/wNT0DjgT0j/iGnsUpeg7f0vM4TS/gO3oR39NL+IFexhl6BT/SqzhLr+EcvQ6+
O/onXKA3wPdI/4xL9FcE3qlfcIXnncBV6sI16sZ1GgL2lCiEG9TBz1TiF6rwKw017KzhMeyZEWbY
V0MbVsqAKUSNcWi4kbSwUbSICaURxkO9hv06rGHFiEgDGmUMjTbhtKgpTH2mCC1mIqjfsLZGcWNp
CRNJS5ooGmOiaSlTlMYaHy1titE446dlTHEab1hBo6wpScuZGFrelKIVTWmaYOJoJVOG+6ERatMH
UIc2BseF+l0so6uwmK7GEvoeltO1WMHj/EoE9xh7+ltmD0QeU7NgDqFWwf0pddw+t0/UY++fKOoX
zF91Lpi/Sna3YIXTzZ3i7iLSCu4uGBCyPmSDGOy4HbcYWjBbNcyJcLwis2BWaiR7z3gxSqbKVJEt
+8g+YrQqo1LEGLVZXRVrNDTEWW11pDhnkkxzccG0Ne3EJdPBdBZXTLJJFoGqp7WIE3n83cK6iI7Q
Xm10eOBvdJSO1kW1TxfTfl1cl9AldYwupWN1GR2vS+s4XVaX0+V1BV1RJ+hKunLgzh0xIfBsucD8
h3AXMoXCRSEVobxCqiTVXISq4SpThKklaqlA6JTQqSI89KfQG6KIp4qnqvB6enh6ikjPeE+uiPZs
9GwSPs85z3nhDysbVk6UCOsa1k3EhE0Km8zxDSs14Yg8WzJqTeTMqAXiP3m2AY8tjciMW9bWnyPa
uFa4VrvWujYGVgJw7XXtd+W7DruO2rIh1WwpG2tL2zhbxsbbCraqrWar2/tsDZtoa9patratY+va
era+bW5b2Ja2lW1t29i2tp1tbzvYjraT7ewd4h3mzfSO9GZ5s71jvDnecbahbWyTbYrtarvbnraX
TbV9bF+b5t/s3+rf7t/pz/PvseVsefH/1eZ/72rzPNJsE9vUNrNJ4s71rHm02Io2wVaylW0Vceta
waHC9c87qtz/7l6vf92JxePIXdedfcscXWBLA/fYm7NkrhPiDM/tWNb28e4EbktkPZ/Gin6gO909
1D3CCYkK/Pyu4cgqKPwvwYm7MxyHBSVwrfWuSbgtlQNXYoOSeGc4vgsKX8s9En0tOHzNwel/t3DM
GBTupeBkF+Tm9+m3JYMZeo+MuFs4Pg1Oxm0Zd1tmBed/cm7QJY6L4qKhaMJxdvuCZ4zefL5olsgR
uWKqmME2b55YKJaKVWKd2MK2cp/IF0cCn5gquDr/e437Qyb+Ee8xsxYjEHLQxkSWj5wSeSBqbtTb
Uct8y3wrfXm+A//VOSzxG3akUAYNCmVuZHN0cmVhbQ0KZW5kb2JqDQoyNzUgMCBvYmoNClsgMFsg
NjU4XSAgM1sgMjIwXSAgNVsgNjExXSAgOVsgNTM3XSAgMTZbIDgxNV0gIDIyWyA0OTZdICAyN1sg
NTcxXSAgMTMxWyA0ODhdICAxMzVbIDQ4OCAzMDNdICAxMzlbIDI3OF0gIDE0MlsgMjcxIDgzMiA1
NTggNTMxIDU1Nl0gIDE0OFsgNDE0IDQzMCAzMzggNTUyXSAgNDgzWyAyNjRdIF0gDQplbmRvYmoN
CjI3NiAwIG9iag0KWyAyMjBdIA0KZW5kb2JqDQoyNzcgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURl
Y29kZS9MZW5ndGggNDczPj4NCnN0cmVhbQ0KeJx9lN2O2jAQhe/zFL7cXqziHxwHCUUCQyQu+qOy
fYCQGBqpOJEJF7x9nTnZbaFVIkH02TM+c8axU7vf7n07sPRb6OqDG9ip9U1w1+4WaseO7tz6RErW
tPUwEf3Xl6pP0ph8uF8Hd9n7U5esViz9HievQ7izl3XTHd2nJP0aGhdaf2YvP+wh8uHW97/cxfmB
8aQoWONOcaHPVf+lujiWUtrrvonz7XB/jTl/It7uvWOSWKCYumvcta9qFyp/dsmKx6dgqzI+ReJ8
8zS/RNbxVP+sAkWrGM255MVIQhItFMiCNJEsQUsitQNZIm2INFbJFqAFKAfRKoJDIRNU3VSHeK/q
3YTgJCYER7Scov9vQog1wkhQCJSWQVBCPsuI9LSgAU15OWgLIoMivojWILQi24DQijg4a8JoMmEy
RG8fTMhnE2aSL0kih7zh8xL5hiRylGfEg4R6lljCvaHtFUu4N+jaRoP034LyH0FLSwgrEI2u2gyD
+ApMPl+FnYqlzioNXWlB2C25m61CYeOUHt3LaB+5OwyWGLSz7VZmgTDqhTLohS5n260MJAz2Xz4a
Fc8SO+yoevjWxzM5Xh0fB76+hRDPOt0vdMjH491693EF9V0/Zo2/39NCSDgNCmVuZHN0cmVhbQ0K
ZW5kb2JqDQoyNzggMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggOTM5MzIvTGVu
Z3RoMSAxOTgzODQ+Pg0Kc3RyZWFtDQp4nOx8B3xUVfr2OfdOy5RkJplJmyQzyZBGAgFCCUUypFFC
C8lAElpCqCrFUEVA7BhELFiw4lpXUCcDSLCiYu+9rW111V3FrrsCSf7Pue89MaDrT/f/+77d/b6c
yXOf57yn3HPee86575gg44wxDy4GNrmseuzoI6u/68WUzxYy5t1UXlJW88mHg7cy9tkBxhIry0vG
l675btB0xj5sYMzSMLqsvOKTR749ypRP1jCmfjF68qTqRXOHn8m4wc74NfbR1aGSR9/9sJMpOxIZ
Gz1rUnXBgB8/euN7xvgbuGtD0+LGZZP2TridsVw7BnBB06oV/vDVB19irP4gY8aU+csWLP7hhwko
63MlY1HJCxqXL2MpLID7T0Z754KTT53/Y0LudYzNfh/9dyyc1zj348yOE9D/DJQPXgiD4w7zJuS3
Id9r4eIVazzb02YxphQxlvXSSfOalzz15qO9GXssh7HoL05e2tTY78700xm7Ff2lVSxuXLMsvX+v
z9C+De39SxoXz8taVfUdY69iPtHxy5YuX9HpZediPP1E+bLmectOukvpwK334HZOJnxrvK7tyTnz
OmbHjPieJVmYSPd+tu4ZwY9mXLn2yOH2zVGfm+9GNoopjBLamVgH4wetO44cPrwj6nOtp27JMFpY
YjJYAzOysUxFSycrYPMYc12k3Zcz1ZDHL0KpxbjdWIgu04jVF9i5CrMwJcaoKIpBVQwfMKUzyHZ1
aiNAmlDt97MgppNKYzBfp2T5Gb9elKn7jNFipug9+qfR8OcxohvEc/l9yVDPdhnKWOMvln3OdnXP
q58em/9nSb3jl+sZjv5kVwy/ra9f7H/mL7c1vc52GXv/6/12T4YM6sc4hzUZao/zwx1s9C+O62MW
0z1vzGC3/+b7tbAMcxo74Wf2bNbvt/bRk/7/TOqrbMbvbWMYyLarc1j9b6zbcMz9jrCZv6WdcgrL
/L3j+r+Z1INs0G+pJ3wlNX+NnfN77sH/1vlq1/1uPKaf7b9U3zSXbe9+v5+Npei3PbOu+npf4hkq
Tx3br5rOqn5LH8qdLP333PN/kzDObb+1rnotyzC2/fwZqqtZrno9y/iZPZfV/W/H15N6Uk/qST3p
vycpV3Prb63LO1lvrU0vdq9iZFfotgukXSS1jm0C8n7vONSE479D6uNbzsq18qOdP/xiu6OdPx5T
fzE7B1irrGAPAr8rHvitSR3ENv+f6PffkfA9+SSdp/ybxzEGuBNoBhbotnn/KeP7fyGpR8V/gelJ
Pakn9aSe1JN6Uk/qST2pJ/WkntSTelJP6kk9qSf1pJ70H5hUHSn02xI+CzkodRwz8BIY+jE/MzAn
lINlsFxWyAazIjaMjWQVbCybyGrZdDaTzWZr2Q52h9/pj/Mn+VM7O7W+HWibw/LZIL3FKDaGjWeT
9RaNXS0S/SlowTu/x32nAvfhk2owdw0xU+2lehnrbFIe/XDOh40flnxYov9uJx/o2zWXgbhHkJXp
uYnHz1Qdp16hhtRmtVY9Wf1cPaR+oX6JublYLEvE/LPQWwF6KGPlbBqrY/VsFpvLFrLlbAU7lSs8
hjt5Mk/jOXwyr+cz+SJ+Ml/KV/JVfD0/n2/mF/CL+FV8Lz/AH+KP8cf5M8zEP9fu/PXPfhPFmaL/
7aPCfj3xn8bebSob1NM1Pn42TP1a/QbX74BpVNdQTtRtnkybqUg0W/bz+Wq9bwTOANZiGP/K/P+z
k9pNrgBmqbPVenX6v9hbz275X+6W4Oi5s2fNnDG9vq42VFM9pWrypIkTxleOGztmdEV5WWnJqGDx
yBNGDB82tGjI4EEFffvk52Rl9gpk+BLdLmeMw2aNsphNRoOqcJZfHqho8IezGsKGrMCYMX1EPtAI
Q2M3Q0PYD1PFsXXC/gatmv/YmkHUnH9czSDVDHbV5E7/CDaiT76/POAPP1sW8Lfx+qpa6C1lgTp/
+JCmJ2jakKVlHMikp6OFvzxxYZk/zBv85eGKVQtbyhvK0F+rzVoaKJ1n7ZPPWq02SBtUOCewrJXn
jOSaUHLKh7UqzOIQtw2rmeWNc8OTq2rLy7zp6XWajZVqfYVNpWGz1pd/kRgz2+xvzT/QckGbk81p
yLPPDcxtnFEbVhvRqEUtb2k5L+zKC+cGysK5az9KxJTnhfMDZeXhvAA6q5zSdQMeNmY6A/6W7xkG
Hzj0+bGWRt1iynR+z4QUU+xyE8qlZhgbRoj5paeLsWxuC7I5yIQ3VtVS3s/meCMsWJBXF1YaRMkB
WeIJiZKNsqSreUMgXTyq8gb9Z9XCxPDGOf4++fC+9pOJH5T7w2pWw5ymhYIb57UEysrIbzW14WAZ
RLBRn2t5a78C1G9swCQWCTdU1YYLAsvC7kAJVYDBL57BouparYneLOwuDbOGJr1VuKC8TIzLX97S
UEYDFH0Fqmr3s8LO91sH+r27C7Ez68Q4wvGleChZ5S21c+eHfQ3euVif8/213vRwsA7uqwvUzqsT
TyngDOe+j9ula3fUWmFux9WWlcXMzZkWf63iVevE04LBX4FLoGQECpx4XFpWPNGSEf5a7mWyGu6i
1xDqmH6QUTNLx4giVTQtHeNNr0un9CtD8upjMmaGLd36csLQNSa6zz8dGtUWA8r1l88r6zbAYzo1
6gPUe/vlcSrCF/qN0cIiHucYWaRmYufCpqAbzSSeYqI/zCb7awPzAnUBrKHg5FoxN+Fr7flWVgcq
q+prtaetr5KaY3JUXkS5MEtHscwopViDFXle+Vi1/Ggt35Udc1zxWFnsb7EEKqtbROcBvUPmxw7C
pE1ZYxs3F8UOxNaswOkWqGgM4LVS0dLY1rlxTktrMNiyrLxh4TDRR2Ds3JZAde0IrzbWKbXrvWvF
rWJZJa+sKemTj7OnpDXAN1W1Bvmm6vra/Xjx+TfV1EYUrpQ2lNS19kJZ7X4/Y0HNqgirMIqMX2RE
T1OQsWj1vfuDjG3USg2aQcs3tXGm2SzSxllTm0I2p7QpsBnIFtRsIuEhJS6Ei3Hclvvnisezrm5h
S0Od2FwsHo8SPzzMAyNZWAmMbOWKyR62BuaVhG2BEmEvFvZispuE3YyFweM5nCPOpJaGAM4pLKha
5uW0FFXRpb+ts7OmNv1Z76G6dCy1GUB9bTgqD2e/MXMc6o0WaIB5dHhjU6MYBwvVirbmzLFNdVi2
skNUGRuOQg9Reg+oUaG1EcsRjZrwbPAAtfYbkQlvrAvX5Ymb1i6q05azM8zGBIbhsVOfxixxo4K6
ltjAAG1vYitYM88TFIWxsepasniRxc3qyElmO0beFEBRU4Mf3jawpmosdTpLrV6yzMORaMiap8Hq
1QuZmJaaaXNYw1F90SF+hLb1FVvSmGmuq6PBa7nz9Aq4tzNsw4iyurlSbwDvoGisGAt+zsNQRdWH
RDdVbWxKYA1OFjForSczisOOzLGNOPypvQ2WQJFsbBFnhE3v4yBZzWLmdvhdzaxp67w1cGp6t9Qn
PyBeDmJhMu9+LGxW13K8ITw9r0++5XirQzO3tFgcv9yA/GVxdLEw+svx1mAsEqX625Sz90Ql8nEQ
Z0lxphRnSLFRitOl2CDFeinWSXGaFGulOFWKNVKslmKVFCulWCHFcilOkWKZFEulWCLFYilOluIk
KU6UYpEUC6VYIMV8KeZJMVeKJinmSNEoRYMUs6WYJcVMKWZIMV2KeinqpKiVYpoUU6UISVEjRbUU
U6SokmKyFJOkmCjFBCnGS1EpxTgpxkoxRorRUlRIUS5FmRSlUpRIMUqKoBTFUoyU4gQpRkgxXIph
UgyVokiKIVIMlmKQFAOlKJRigBT9pegnRYEUfaXoI0W+FHlS9JYiV4ocKbKlyJIiU4peUgSkyJAi
XQq/FD4p0qRIlSJFCq8UyVIkSZEoRYIU8VJ4pHBLESdFrBQuKZxSxEgRLYVDCrsUNimsUkRJYZHC
LIVJCqMUBilUKRQpuBRMF7xTig4p2qU4KsURKQ5L8aMU/5Di71L8IMX3UnwnxbdSfCPF11J8JcWX
UnwhxSEpPpfiMyn+JsVfpfhUik+k+FiKv0jxkRQfSvFnKT6Q4n0p3pPiXSnekeJPUrwtxVtSvCnF
G1K8LsVrUrwqxStSvCzFS1K8KMULUjwvxXNSPCvFM1I8LcVTUjwpxRNSPC7FY1I8KsVBKR6R4mEp
HpLigBQPSvGAFPdLcZ8U90pxjxT7pWiTYp8Ud0uxV4o9UuyWIiJFqxRhKe6S4k4p7pBilxQ7pbhd
ij9KcZsUt0pxixQ3S3GTFDdK8QcpbpBihxTXS3GdFNdKcY0UV0txlRTbpbhSiiukuFyKy6TYJsWl
UlwixcVSXCTFVikulGKLFBdIsVmKFinOl2KTFOdJca4U50ghwx4uwx4uwx4uwx4uwx4uwx4uwx4u
wx4uwx4uwx4uwx4uwx4uwx4uwx4uwx4uwx4uwx4uwx7eLIWMf7iMf7iMf7iMf7iMf7iMf7iMf7iM
f7iMf7iMf7iMf7iMf7iMf7iMf7iMf7iMf7iMf7iMf7iMf7iMf7iMf7iMf7iMf7iMf7iMf7iMf7iM
f7iMf7iMf7iMf7iMf7iMf7gMe7gMe7gMe7iMdriMdriMdriMdriMdriMdriMdriMdriMdnjpbiEQ
NUfSRvoQM0fSPKAzKXdGJG0YaCPlTifaEEmzg9ZTbh3RaURriU6NpI4CrYmkloJWE60iWkllKyi3
nKiZjKdEUktAy4iWEi2hKouJTiY6KZJSDjqRaBHRQqIFRPMjKWWgeZSbS9RENIeokaiBaDbRLGo3
k3IziKYT1RPVEdUSTSOaShQiqiGqJppCVEU0mWgS0USiCUTjiSqJxkW8Y0FjicZEvONAo4kqIt5K
UHnEOx5URlRKVEJlo6hdkKiY2o0kOoFoBNUcTjSMmg8lKiIaQjSYaBB1NpCokHoZQNSfqB91VkDU
l9r1IconyiPqTZRLlEOUTV1nEWVSn72IAkQZ1HU6kZ/a+YjSiFKJUoi8RMmR5ImgJKLESPIkUAJR
PBk9RG4yxhHFErmozEkUQ8ZoIgeRncpsRFaiKCqzEJmJTJGkySBjJKkKZCBSyahQjhMxjXgnUYdW
hbdT7ijREaLDVPYj5f5B9HeiH4i+jyTWgL6LJFaDvqXcN0RfE31FZV9S7guiQ0SfU9lnRH8j41+J
PiX6hOhjqvIXyn1EuQ8p92eiD4jep7L3iN4l4ztEfyJ6m+gtqvIm5d4gej2SMA30WiRhKuhVolfI
+DLRS0QvEr1AVZ4neo6MzxI9Q/Q00VNU5UmiJ8j4ONFjRI8SHSR6hGo+TLmHiA4QPUhlDxDdT8b7
iO4luodoP1Eb1dxHubuJ9hLtIdodiS8GRSLx00GtRGGiu4juJLqDaBfRTqLbI/E4r/kfqZfbiG6l
sluIbia6iehGoj8Q3UC0g+h66uw66uVaomuo7Gqiq4i2E11JDa6g3OVElxFto7JLqZdLiC6msouI
thJdSLSF6AKquZlyLUTnE20iOo/o3IinEXROxDMHdDbRWRHPfNCZRGdEPCHQxogHhzE/PeIZDNpA
tJ6ar6N2pxGtjXjmgk6l5muIVhOtIlpJtIJoOXXdTM1PIVoW8TSBllJnS6jmYqKTiU4iOpFoEbVb
SLSARjafms8jmks1m4jmEDUSNRDNJppFk55JI5tBNJ0mXU9d19GNaomm0XCn0o1C1EsNUTXRFKKq
iDsImhxxiztMirjF8p4YcZ8FmhBx9wGNpyqVROMibsQFfCzlxhCNJmNFxL0BVB5xnwcqi7hPB5VG
3BtBJZHYCtAooiBRMdHISCze7/wEyo2IuOpAw4mGRVxiaQwlKoq4RoOGRFy1oMERVz1oEJUNJCqM
uPJBA6hm/4hLTKxfxCX2ZgFRX2reh+6QT5RHnfUmyqXOcoiyibKIMiMu4aVeRAHqM4P6TKfO/NSL
jyiN2qUSpRB5iZKJkiLOmaDEiHMWKCHinA2KJ/IQuYniiGKpgYsaOMkYQxRN5CCyU00b1bSSMYrI
QmQmMlFNI9U0kFElUog4EQt2xszxCXTENPnaY+b6jkIfAQ4DP8L2D9j+DvwAfA98B/u3wDco+xr5
r4AvgS+AQ7B/DnyGsr8h/1fgU+AT4OPoBb6/RC/0fQR8CPwZ+AC298HvAe8C7yD/J/DbwFvAm8Ab
jpN8rzv6+14Dv+o42feKI8v3MvAS9IuOPN8LwPPAcyh/FrZnHIt9T0M/Bf0k9BOOE32POxb5HnMs
9D3qWOA7iLaPoL+HgYeAYOcBXB8EHgDut5/iu8/e7LvXvtx3j32Fbz/QBuyD/W5gL8r2oGw3bBGg
FQgDd9lO9d1pW+u7w7bOt8u23rfTtsF3O/BH4DbgVuAW4GZbH99N4BuBP6DNDeAdtpN810NfB30t
cA301ejrKvS1HX1dCdsVwOXAZcA24FLgErS7GP1dZJ3o22qd5LvQusC3xXqz7wLrrb5z1Ezf2WqR
7yxe5DsztDF0xs6NodND60Mbdq4P2dZz23rv+sr1p63fuf7t9cFYk3VdaG3otJ1rQ6eGVofW7Fwd
ukc5l81XzgmOCK3auTJkWOleuWKl+t1KvnMlL1vJ+63kClvpXOlfqdpXhJpDy3c2h1jz5OaNzeFm
w/Bw8/vNCmvm1rbOA7ubvWkV4OC6Zoez4pTQ0tCynUtDS+YvDp2IAS4qWhBauHNBaH7R3NC8nXND
TUVzQo1FDaHZRTNDs3bODM0oqg9N31kfqiuqDU1D/alFNaHQzppQdVFVaMrOqtCkoomhibBPKKoM
jd9ZGRpXNCY0dueY0OiiilA5Js9SnCn+FNUpBjAxBSNhXl7Szxv0vu/9ymtg3rD3gFeNjUn2JSu5
MUm8dFISX5p0etLWJDUm8flEJZiYm18Rk/B8wnsJXyYY4oIJuX0rWLwz3h+vesTc4ifUVGhcXEbc
f5A21wnxgayKGA+P8fg8SrnPw5nrfddXLtXzoPN5pxITw2NiOmOUYAyqx0T7ohVx6YxWg9H9h1TE
OHwORVw6HWp80AGL6DHbPrmmIsbmsymhYtskmxK0FZdWBG19+lUwlfs5Z9wJUi1iFNzjq8C+3h3P
jRzv89aa6ry8yjYLm1IZtkyeHuabwpnV4hqsqg+bNoVZqH56bSvnF9a1cqW0JuwWv7HV8uds2cJK
UivDqdW14R2pdZXhjRBBITohWGprPCupy5u1fOXyvLwVs3CZtXxFnvaDHF8pcnnCKH6Wr0BefFZq
eZb3q4mqgWYvR1ohjSt+vdV/euL/7gH896dWJv7IYFSncjabq5wFnAmcAWwETgc2AOuBdcBpwFrg
VGANsBpYBawEVgDLgVOAZcBSYAmwGDgZOAk4EVgELAQWAPOBecBcoAmYAzQCDcBsYBYwE5gBTAfq
gTqgFpgGTAVCQA1QDUwBqoDJwCRgIjABGA9UAuOAscAYYDRQAZQDZUApUAKMAoJAMTASOAEYAQwH
hgFDgSJgCDAYGAQMBAqBAUB/oB9QAPQF+gD5QB7QG8gFcoBsIAvIBHoBASADSAf8gA9IA1KBFMAL
JANJQCKQAMQDHsANxAGxgAtwAjFANOAA7IANsAJRgAUwAybACBhGdeKqAgrAAcbmcth4B9AOHAWO
AIeBH4F/AH8HfgC+B74DvgW+Ab4GvgK+BL4ADgGfA58BfwP+CnwKfAJ8DPwF+Aj4EPgz8AHwPvAe
8C7wDvAn4G3gLeBN4A3gdeA14FXgFeBl4CXgReAF4HngOeBZ4BngaeAp4EngCeBx4DHgUeAg8Ajw
MPAQcAB4EHgAuB+4D7gXuAfYD7QB+4C7gb3AHmA3EAFagTBwF3AncAewC9gJ3A78EbgNuBW4BbgZ
uAm4EfgDcAOwA7geuA64FrgGuBq4CtgOXAlcAVwOXAZsAy4FLgEuBi4CtgIXAluAC4DNQAtwPrAJ
OA84FziHzR21kWP/c+x/jv3Psf859j/H/ufY/xz7n2P/c+x/jv3Psf859j/H/ufY/xz7n2P/c+x/
3gzgDOA4AzjOAI4zgOMM4DgDOM4AjjOA4wzgOAM4zgCOM4DjDOA4AzjOAI4zgOMM4DgDOM4AjjOA
4wzgOAM4zgCOM4DjDOA4AzjOAI4zgOMM4DgDOM4AjjOAY/9z7H+O/c+x9zn2Psfe59j7HHufY+9z
7H2Ovc+x9zn2/r/7HP4vT3X/7gH8l6fE2bMYM1/HWMelx/zF9mR2IlvONuJzLtvCLmUPsrfZHHYW
1Ha2g93C/sjC7CH2JHv9X/wL919MHacaFzO7uo+ZWBxjnYc7D3XcArQZo7tZLkUuzuD/ydLp7Pzi
ONsXHZd2OjvaTLHMqrV1KC/B+i1v7zyM9yvynYNFXjkPOkZr8bX5uo67Om49zgdVrJ5NZzPYTNbA
GjF/8Tfpi+CZk9jJbDFbouWWoGwBrvORE39Zj7NE0z/VWsqWAc1sBVvJVuGzDHq5nhNlp2j5lWw1
PmvYqWwtO42tY+v162rNsg4la7X8GmADOx1P5gx2pqYkk+UsdjY7B0/tPLaJnf+rufO7VAvbzC7A
c76Qbf2nessxuYvwuZhdgvWwjV3GLmdXYl1cza45znqFZr+KXceux5oRZZfBcr2mROl97DG2l93J
7mJ3a75sgtfII9Iv8zUfLoMP1mGGZ3UbMflvdZe3NmDuYm4t+kzXwH5mtxardD+KmmehJvVCz0H0
sv44T1yEOZD+aUaUu0yb/0/W7l75Nav0xzXdPHO1lhPqeOs/05eza7EDb8BVeFWoP0CTul7T3e3X
ddXdoeVvZDexm/EsbtWUZLLcAn0ruw17+3a2k+3C5yfdXRHfye7QnlyYtbII28324EnezfaxNs3+
a2W/ZN+t2yNdlv3sHnYvVsgD7ABOmofxkZb7YXtQtx7UbJR/mD2CvKhFucfY4zihnmJPs2fY8+xR
5J7Trk8g9wJ7ib3MXucOqBfZX3FtZy8YP2LRbBRjxnvg52vYLHyMOJWWqy/hFFGZmQ1lE9hENv0+
5sDrPp4N43v3esrKLH3MD+BVrjA/ggEL47w0GGNQHPuSk4sD+waZtqiusW28z55i8xaEucXt77Y/
V9D+7qHYoQWHeME7H7z7gfPr51xDCwo/eOWD/v24K92lwR2tmM1uUyCjrzIoO2twYeGAkcqggVmB
jGhFsw0cPGSkWjggTVHd0jJSEXmuvnS0Xp3UblI2BIqnFhrTkmPcDpNRSUmM7TMi01k9PXNE31Sz
ajapRos5Z0hJRuXJ5RlvmV2pnvjUWIslNjXek+oyt79tjD78jTH6SKnh5CPbVNPwGcW91CutFsVg
MrWlJSb1Hp4+dmpMnNNgi3O64i3mWJc9p2xG+7meFNFHisdDfbVPgFsCnYcNG4xulsGy2LX7Wa/O
T/fYnXx8oE0XWW2dX+2xQdiksEIEk4XKdIqrQ7vatWswh2eK4nwbn9ArkJX5nd1mT8xIDVgdPN5g
Z3anXbkr8GDg+YAasAfssalTYkPGECsuLo4dOrSgYOZMV8JQF6Sr0HlogKsQHs+bSa9ClpeXGR9v
0lyeraar0WogIytr8BBOfk4wB9R0w0oLd2b6fJlxUYal7R+fqFrjAimpmTHcwiMGR1J2mr93crTh
NP4ef/iEeG+0QTXbo/jwjiejHFEGY7Q33hCxRVtU1RJj29J+mvhXY7vEP/bC6kpjeayIPRFM9iU6
+QSfM0ZcHLgk2nHxY67id8TBnGRPEOWeIMo9Hlu+qJwvKueLyvmicr6onH8PvhOyzgN7oVlWITy9
GzXBX+2O0dmh8Q+77Rp/utsmWHEGHTtsB2yKLTn7u/79zb20/ypdNbCN21rNNaz4ULG2bofygpkf
aE4b8EoeCZjz8oaShlPd0YZAekbWINfAwYXp8J5HrOc0lQ/sqwQCLrGY436SBu4rmtR0ytiOOxNy
cxN41optTQPi80b1HjSjPKejPbmoflzkYOmUwUkTM0efVPXc4eG1pVl8+QkLpozs7fFlG87M9uXX
rJ3Qt2Z0Uax10JQlCi8YPyilY2Zg+KT2d4bVjvB1FKUMmcI4a+z8ymA3pmEXz9mdwobn6V7J070C
/lx4BfyF8Eqe7pW8B/AdO5ol8gKWzrJ4fiSu2nAv780GsX68b2vUVGzpVw4J8AKavvO1g/37Zbqj
Td22pcmjb1OxgT3uNEXMWywrg10xWtzB2aeN3fD01gnVl794etGJ9RVei1E1WGyW6AGTTpk0dcvc
IYOaLpo+YXnVwBiz1aTucybGRrtzs701N3197Q1H75rh8ff2Rsclx7pT4qKyC7LLz31o3Wn3nz4q
qyDL5ErDDhSrbCtWWSzzsdXB1OJ0HidWTpxYOXFuzDkuFhOOS8Rs4+4VK4clk2+Sdd8k6ysmWV8x
ybpvku/F9/4o+MYeia7ytvGsViOtEumLV+SKmClOtGOWhLnbAtg69eavbun4Qnv8mbd9em3V3oFL
bz/3rtZ1tzcPVa667cjNU+hBT7vx0+2L9p497qhr5MaHxL9nxczUdZhZPlvVmpytP9FsfdTZ+qiz
9VFn66POblNcwaioOH+cH4NPbuOWoGNjFj+QxV/I4llZpiTxCxpHVTao1dS16mee0oxpFWjHiFNf
/dpzVn620gPpruOkus5gdVjaLxUzVOZbHBajEZcOE49YcDQYoqAnKtzisBpGx3pjLTRbS6zXHet1
WTpOjHKmxMUmO80d/S0urzbvzsNqDeadzWa0muP0ecfp847T5x2nzztOn3cc5r3XkcrSUs2Y2u64
uCRTG8/ZnVGVJA5I/Y1UcNA1tGt2/GeTkW8bOV21BhMzd8B7Zgxe00GL25+cmOG2YKoVmvVgXApm
Mcbs9HrivK6o9r+YHWajERfDnWKWqfqMDJPxlihgbXuK+/OAXZ+UXZ+UXZ+UXZ+UXZ+UXTzMlIRe
NrGibWJF28RZaLOijk2saJs41RJY0IOjMBgnLk4Xvp0HUc4SxH9mR4Hgu1GW0HsKjrz8YMwBO3/B
zu3Hvj+wBA4Vc5xzrwj36E76aSnMzOxyTnc/0T73wCalYbLFnZ6Y7Hdb2ndDJQlfWdwZiUnpbosy
QfMeVLLFLpxktygj2x+W2vCWVO2HFZPUuv94LfznYZP3FSdMSrgrQWW6C5nuQqa7kOkuZLoL2T3Y
xdbOA/vgCatzijZdTLNr62b+bDK8Vo47ypOekNR9tD+NUO7PSowqmY3Zzzw0HI8+HI8+HI8+HI8+
HI/423QWFTPF08bz9A3IC56Vw+m247pcKxZiJXZRVPvBhFzpSv6CeO1Wur1xUdhPd8phHbkhypWi
e8yUhz00gu0KOhtGLhupOPr1SygosPZNTExu+40HoFh9ab362+1Wsf6sYv1ZxfqzivVnFevPKryL
d3EwSbi61+AqW2KCoyCxf1+TL6fKF5LLqzgWgUkhJirfqIhOnF3KNfSEgsJCEa90exoBLmIURCs8
cMy+1MIVXigCF80/pjyL25eUkB5nUToKVZsn1e1Jc9uUjtEcay0p0R9nzvcu9PfrlRjFVxv5ubZk
X1bS4hhvnP2nh7rgyDaz1awa8PpBQLi9y35L71725Bzv0WnqLWm9k2xRcakefS9vMLrYCeyc3dkx
MW7dmRrH6OzQ+CvhTLfuTLfmzDRr374DhDMHJMaICyoOcNqFQpUBooqTpRVNsfaNyTYkibNLrBDN
fcJ5P/NdQaG+ZMhTWVnZgfh4zy/4K01NKMzqtqoMGxyeZMeQ5OxAwNOx0D8qRVEUS5wvMdEXa8lP
npKa7Ut18WGpgwf0T+Q4uuN8SfH+WMtoNyJgW+qAbOX9oeuHj7l83NFvuw6723MyrAm5vvYnBjY1
zCyYtHOS8gDiQ5z+drP4fzeIM/1xrMcUlsvWtPYy6V4z6UvQpC9Bk74ETbrXTMIlCa5U4bJUsf5S
nXYHH58q4sBU8UeHzJXZxq27TSZ7AHHcbk+VvdtxTw5zHnviB44/5g3dXtbq48HVd6y5NCouPUns
st7J3NN7wqLF43P3Dp82M//6qycuqOilXtp4zZIRHX271gmmbk4onnHqtEknDoxu/zFndJOYcVPn
KON5xnS8xYazC4Op1vTYHDGLHDGLHBGX5Ii4JEc8+BzMJGhl/pR+KRtT1JQBunMG6M4ZoAdvA/Tg
bYDunAHiXwbFplsdfdp47p6E6kzDEHGoOBC1HXrlWeGEoV2hysyDMpQd2r+fUfdAtql7GKfHsUYt
ju0WyWEWVrvJXbfi7JH9L2+65NXNZeO2vbtt88tbx8Tljuw9dsmYHLelY1f29CuXLbtydm5W/RXN
p1w1K6c5wecypRfXj0jLn3rL33dc9eNds6fe/M21VdvOXtZnRGlGTFxAeX/JfZsnVm+5Z2HzgxdM
qNl6v75ODDask8GsjF0cTHP2dQ2xYKpDhNeGaM9+iPDiEOG2IZj/vlzxnSG32CV8BeXSfebSF5RL
X1Au3Wcu8SecKX2diIvuXhbkwWDCCVg3e9OrEvSjSouGDnU5rtt3gKH6XtO+QvVVf7aQ4hPSVP2r
QEJcfDwfmJWdlSWDQJvJ3SstOd1tM6z29BlZM3y5XGIICuP6j0quXD4xO1AyY6h/YJ8c94poS0d7
2eSk4sKLbytrKvHhqLJgJ+Gg6D9wWnGg/c2upYcQw6g6iqYuLR214H/Y+xLouKorwf/+Uvvy/699
3zeVSqWlVNpVJVmWVFpsy/smeUE2GIyNsY0xdrABQ0IIDUkgOaY5gQ4ZSNLdgLGxZZM05jQJIT2m
IQOGdANNJkkDTtwZkgy7qua+93+VyracTs/MmdPnjHTt+1+90v/13n13v++pFrabDcnOBQ3FX4Y9
zO0jW2xKRXEk0LEIdNZA6TxzBfBigXr3JNUDoakRgs0emUQ9Mul6ZI3VI5OqZ4quzScb8yYzGmnM
CxCRNoYbdS47vteFzYCL5zGCW1x4OVyn6AZsC466iPU9fdQhX83S9bgRuya6umdQjGqhNCia1wr+
FtSS1+rQiID3D2hwq0VoEayd4MM93ePiEkuswNtHOMzSOMg9L2APNZkc58/zWMBnfBVReqMqSMNr
w5Z5W0ox1CkuE7IomCvm7fmr8Z7tKzpsWhbIbWhatGOodXxeuHHxlm1XLW7q2PLVpckVo50mBUsz
Cq1Sm+4bb88uyjgbl1y97eolTeiaNX8BgZ0/aI/4rB5RGYyHvC2LmloWdDQ0dS/dsXDswPKU0eEz
aQW7SYRIxh3yeOp7I9kFnY1NXUt2wBoZQUO+DpwfpDadsOeBvHYBU+0Y9mn+bHWJzbEAoTHmfIWI
HWCPrBEbwen5gBDnR0n++WTF/Z1x68qagDgcrxO3/b6yJwQt2a1nDhGnnni9n32rwogbVYLbZJIS
I9j/+H7pPLsXfKMkdTjvWZ9Cfiy1fizFfsw6fuxB+DHX4DN6eaHagwVOo6zyhK3yhK3yhK3yhK3y
hK2naB57d9jPxRt58mp4hCa6mF/smuEb4tbKejA5wyLj6FI/VlZ5VYZy7/yDU7uvefLmPsnxN6lq
l+wuDO8eSxLSBExq9PYNJw/2du89vocJlcnx+e9X37EqVbvy1hWMrdpjDIJ2uwqoEqa25T1hrNji
YeTE16gTxW0oqke1DlRrR44pWUhJA6s9e7kHN/Ii7nLYHfZoxLfYzomSXyu25QQRSYKAZ0iNj6Px
8fHkeDJCnCkWuwjZbJUL1Wi1KpT0CdbgiHmsAbugUzLFVSokxoPugKhm0U6EtjAqUF2+sJ5ReXGC
B7EcBO/sUyQFBEHdZ8+yOdyPU0B4jl3geb4Dc+ykrjwa7URgrD7Oz8OCHQEWVOFGPI0iPOmJoKAd
NxJBZPfjRqoBpepRKoxSIdSyuGZxqF7LVIcp4AflYOXgB6e2ZIhUPEWm3Lp4mhdOmLuN5d0Jry/p
NrDFD+hPGYMz4Q/Uuo1M8fsKJET9vrBJSaMQQmZGbY543QGzmkEJGnkYhSnk8YZ4xEUNAvZuBAPz
yufpcpv9a5sTU8Wg/ex5tl1rBK2tMmo/+zHboYE2Z3DaMIXqQdI/JNFgfd6TSKNEHYraUdSGYlYU
p1BicUgreBYLM6k9mDJeR/iZSeIhVMnhVc22MkXE/ErPiYmgP2zRssV3im9xOkvYG4gaOT3aUHxC
p+RBQUWtGgWyIjOnMQU9vpjA6opPdludRo5RadU0Mz0NzhvDGZ1Wegmds7qMLKMEpeBGv1LplWS9
p3+EbfZasC455qdUE5Wnnsz7jb2+3nQvo1XbMjoQ1QyW9wwW9QyP+TczhT7KQ3AfM1JIR2GNQLXL
lqdd9p3bZeluL/N8+xStypsF24+oDJ+hO05nEJVBmUxdT80UcuWNLwdRMMh6ztUNdb2pG2WpdDmr
cV4gge3EeDln83xyYrxNznA0gkGfgIgDExR84+YqZ6ipWfaB5B6W6AKlZCysTY3ZFibHu11On6Hj
q2MDO8dS3bu+u2W/tWFBW9eGQoNOBY6v0tW7fHNmw5eWRr9zd99kr2/Vop7tXXadDjxV3epcf6R/
c8/IdUOR/syiZpcn5FHxDqPD4wx5TLXLbl76vC2VS/Qv6e0D6h4G6r7G7aBqcMTxNCgzTSAra8Gs
rBWzMr3wa0Kv7BT6OO+yJLGHmfTjvB+mfxLr4CRP0oG0Jq+mLJpsc4Dl6qcQdzw65OrnR9qgeYQb
JVoTSGhrq0QdMzSr6M2Y5VIFKgmbUiafUrBaiVv9WtMV944nC/39MZXoskAYoVCa/HYHxBTx4cHB
+Ma7VsQft2SW5/3d+fmxvv3zule2ONC7u5851C9E2xPbQIeyLOhQrpV4QoCmf51oDfELbnty9/xb
J7vEmt7G4uElKzqv2AfytRoo5mdepJqpO4+4iQci5QnekfMD7x3DweosCbV/uzCRVjonJdhobV6f
NiCD411fXqMf9IWnEH3MNMT8pgHbZ7V+sKF2CimOqEdxtjR5nqBKEvn5SirtopSpQnI/FNUJU8ZP
c0pH5/DK9IZvbGru2XF4VXKsr9muVtCi3hjrXNa+50AgP97ZtjyX1OGQ9duCQ9A7Ih4xv+/o7tuf
vamDdwbtBpNdjPkC8cCJx1fctjIZToZUJg+W0/VAlwe5a6ko1UbdlfflOpDW1Yalsw1b4zbszbVh
7mjDzNL2DMLf7pSWqJaWiZWWiZWWJTYtEyuNGUpjCvRr22Iu1lCDN3Xbh0DU2aOGUW4EOyCEnXIX
5U4JP1WC/moRBHe6wlVMNFodkLQwDyoFtxmXYwYOr7niKyvijRu/um7hbXml2Yd5Sv3ovC/05YCD
gKN6Al35/pijzEB7RpeP3nZk465nDg3Mn0dry9Hr9HzgnY378323bgJemteAqTUO1DoMWi1JZajH
8zXpbC67PcuYsDSZ/DgRaQrUYt+3FlNLKlEQ/Qa88MnTfcnvJGmcfH8aS1uGlZmPlXmMvNaSq6Tg
WEy/QKD2hYPsvSx9mkUvs4hl3ek3o0P2c+sN1xlog/qcmzDYeHXGVhLKt5ISs5E6BRFQRShQxVaW
C5mPtsSyhKBK5nDMMf2Ut/+6sfxkIa1TahUMzSi12eU78tsfu769c8fDV1x9//rUo8zePV1ru4M0
TccCwzcur7M4LUqDQ9SbjDqtw27qvmnqpl0nb5nft/MvV5puva9uZFMLtnOR0qf0HdyN4AlMPmXl
sQASwXPJWstV1lYuWZ25ZGZy4eNr9TWRqdLLeRHnMyOa89kBZ/R8/aB/hB8kUVojTsMnn2/6QJKx
pucrLr/k0lukeSuqozRQ82XtTujA0neAL6NQWrwJVyTjN7wIVo8TjS+qQDXZ/SbVAZ7HquZAaPDa
oVBvWAc+jtFkM3BqrdreNNa+USk4TWH/57/B7hAuaDAWf9jkFJTjE19cntAbdSYXroI1F7/O3Mn8
hOqmFlDrqJfzFjE1gKVsQAVTHvDzJjQy0JQDLwmTICfLF1zfOY7fyikXQjOvN4poZKGLNdYzTUol
5h6e0Ot0Xg+NVJPS5VI2pVhM43wGE3kl/oiVfh5uW1kTyWvhGjHWK5nWoX/SLXnPYlnfyrzfOVjj
7/1569Can/sXyoWAHLGY589Kqj/ZdAYT1wYOJXYpBejkzyThX7KMMNWBxlarZAqiMQXoM6tNjoTL
PNcC5jWTJViSbAiWUSZaMae4YBaNxQyM/Iq502S8JeRuHD+4oOUKl2jryf5m3nWL6zLXPLrj2sMb
a/lAg78h3RjxhTNrbxlJDPgQLwjF4qbx+oG0bdOahsG0bcm6sff9Cbv60A3Dm7pdzK6QL7wiveDG
JbUeq1jnDdXRGjrQtaqj+7plDZH8qkygu7XJ4Rip7VofjYz3jt60NKVWBYofrL3S31qIr9rsaxmc
nmjP0SpHKhG39Mzz1Hdj/j4MftzDYJkbqb3HchlUM1OKkBm7qkYh1yzALNu8UvqeJPJJDp+oDS1+
TyNl7r01Dh4syonUULjfMULUJ0lMoLScuJaMcduF6WtiTZSzJOcl59DCPKwSJZtrryvUd+/vg5ck
QVo2xQP3FlbvGwk4yvxMG0cn+sIrl03fVe6ptr/Dha7Nd27AmvL20qdojEtTFipAfeVELrQwtD3E
WGVf7oKIzUSu71wU2UmR3DP0DspNWS6XNpdJagEyHdf4cI0YH+Q65uALhD5nzydlbShbltlz+yZs
djEzAhei7osJYKrtaE/i/xUSMIeU0oSVqL69JtEG/2HGpdeKX0eTMOMwVU/dcXRhI67aE2cBrr/H
446UFTsu5+MJRPCZ9qSOkn+vqkohzatSrgDdl9c4HFRjHZ5jHczxaNxXMIMlPcIRKYWZCk1NZX9W
mi3Mlbsg4WG9MIq9YNpj3vzkgD9lh/COUaqVipAtkPYaykoP06Am2dFRY5zctzSp0ugFUY+rc5w5
NVhg/vpSckhysB/kIEPdn9flsijRgBryIhoF9+hlMrkG2fw14NnryJWYv4Zn6BgVpHQyDS5fBQPR
cFpTKQqTRBIRa1DLxQvufqEsHiTZCc4WePfEJjS+U+aCChvE0CzCIYeHYCqUCFmtzH6VKeh0hexG
RfHQxfyBlqpER9DuCFrUemPxFNqm15LUHIRFavT7ov5SMfn8Z+gGjV7NgFFV6+x88VQxIlhk3YG6
gWYWKk8qWttJRWv2CtYMj6CPj2n4fjJjmQFmr2BdwtmOS4cmj4J7GXycRdS5vEvktXKdPEqi8xgJ
za9bjPovrbVKGcOqmuy5in7zeq3Q9HobpSoRqReRUhFRcxrg7xOLcI5nUfelpWvpsZeUuJ9BH4OS
5ZHiqeEhcL4VeX3PUHd/qrWQGnFUrX91bb5NztsKbeVaH9aW5EDPn1KZl9OhFjnAlpmFe1lSpSaV
ubavrm3nfCw9toBJaa2dV9e2q6JZFaLbZvXwypF7Cq2r+ur51NjwQHjFDQXfjI4NtV2kYy/tYQ6B
Y8Iwaq1qz7KFznRPvKGvxgTKd6Rsg2AFG6n78kZpBTGSzdHFq3SZyjkOFr1ani9bJVJorqoxo49P
yIYJm6W8JjVU4wgXyqTHXkPFMpWrLTK1/wzzZPn3zFOFiN8c/XfM0wWEAgKtx9YJR4NvA4VMVIz6
bt6dS6C4iBICzrVFdSiqQlElqiHZHa8c5HhlgnllteWVvXavTDAvdta9aQ3SmHFEbcbkMuO4wIzj
bTOmmfkUrcG58BNGavQ6WCYHPslqHApB5CiH1zhClElWDhWlxBb5QVXeU3VAXQ6BmLfbd/7t9dv/
y7Zs286/2QnXlsdd3VcvLGzpC7hyVy8cvLrPj3697eQdw703H7serkNw3V+4dWNbZt2to0O3bmjL
TNyKcwvF+5jXgDY4t3AQ5xYCWY3MJRqZSzRl7aORZ68hToxFSiuQBAOpCEgZhlnzCgV+4WXzCrOl
FWbhkcunFb42Ee/ryYermMVscYnKxMjoWGrjl3FaoYmkFfpjfTfN617V4kTv3/CD2wb4YCZU7C7r
QvZ94BkGZ7321nQnLCOHntg9/5bJTlNiXkPxgSUrOyf3k/gZqPWgTK078i4gl0+bxAKT1OjKKRai
5JI4dq6hmiS2qdqZdk7emVbesVbemQaxsyVS0HYlfSxfh2Nn51Arjp35UWzzZ4+dL6BZsyBlPsv8
Ymu+fOysxmLmMysTQ4OFGCZR4xVfXRfvnz9Qgzc3mt2C8pL4uXisTCl0JtEWMpZjaCHSkbi2TLri
/5SCaCkhA0E00U70YyQzeMWx65pR1CgzlVGeurHMXEaZ64yYucSqQgDmMsoJPBfJq5NDUaPFX7CM
ULK6JwY/WfGFqwPA2RQNYSIF/RitUKtUNk/Y4qhvbg9drGYiPe1tHn0g7NGxDGI2Wr2CWq1WmetG
WqafvFTR3JbtixkZlUajNpC9S2Ol8/RLMOMC9VJelx7ODS8cPjD8xDBXVWz7UC6yEabowekp00VF
OFJ8Q2/mfVLFjdTaMIvJBTccImOd4zqFPiSbLzTYLdLliasEL6PwvJzuCR2tq3urRfMbYZGwXrhO
YKTC2j/jqtqQ9T1JGCslNbmgNo5LJFUFtRlf+j9aUKNfapq4dUH9ivn1Vg2LC2bJ3PLWmr5GVyy/
aNlYPpZYvG9xeLA9YVEy4B1pFOpgtpCuyScs8fziZUvyMWSYvxXW2+Ywh30m8D9dfpcYykaimbgv
mOxe3tm8oVCrEy28zmjlBQevtDqsplC9O9Yc9wdrOpfitQiUfkdfy/4t1U6tPZaghFBKpnlKXouU
vBYpWSBTMlemMBPqbPrU+dCgR3/eNtiAvW+lpLbPYLZrkrNXZ56XUnvs7AmGC9MQ1nI6hr5WxfsT
dbb+ybznZqOIq2pfKDtq7+LcsWh8t2XAFnabVZyaY9d4grxBrYgM71xAG6QMw9ny1oqzUg6iqBlf
p9aoOYMdz/s+nOdjfgA+wdfyPvAEtDHMQTHMQTFca4oRJRXjicuFPjkuSZpPpopPpgpcPyayiRtH
ySZdWVh9Mo/6cKyiNqUKMS3nKIBjxs0k+7B8lvVVhaVmTfZdVHzLtsyk/R5Uih6LzSMoRr9BTL/S
LMUotvRgffe++UqzDyRXVFc8gj3LFnReeedGOliWzuk/Llw3L7JyGb273CNX4Zh9QJ9a6pcnqVAJ
rBl2dH2kNhXxIa/U8CKrPE+LfDXPuL/kKlb2FJT+R74Fb0gAr0JAMR7FORSMQ0dXEIWDKICbuQAK
B5Cf9PpR2I9iRnRDAAVwkkstWAYDfpDaAK7tqYEVAzjDiF/hlQjg5+vgxkC8ENA6C1pJAZKyZhLv
7R4nnkNS+kcqRRLdcXUsSXbbVzZTVZkIk63FJG+z34dohi6eYfXOuNcbdxjY4kssh7f92Dwhk5ot
ssxntMYUcNm8gpJ5iFVrdMrPv4eLfqzKoGFW6EQ1AzEhDUg97dTp6H9V61QMrdJiajdDjHEIqD2f
evskNQDqqQum1oqTX4lW1IKvkToUDaCoH0V9KOpFUQ+KuVGcRQkGtXegjnbUkUKd+HsjLGiUl9MH
+JrXALvyfngCb5S78TWvw4YEdxt7CuT3MDFz/EJ+O3+AZ/m8aB3kmwqRQvu9tagWv1eLtSZvsg5e
Wbunlp4PvbYRNSbya5iS48/ncmeAkhK9Z0qrUnFV+pEIrajQmYkpq2qRs5C8qskdYrniR4zeFvf6
ahw65oc0/QSjdya8vhi8Kn7CsRBd2NxBUcX8nKZfoNUisL1PVNGv0+gsrTYFnHYPXhal2TizKPTd
avX0zpklMpqVai2sEESq0061GlZID4oXb7W0l1/RKg1erwRIxzCsV5q64yTVAIQRcH4f6406rDE6
6pAd+PE4rufZkU3WDdZylxWpMbfW4LgV39NJodYQymqR1o/DC7wqWm1DfaKAa5wFoRJCSJXrdKVq
jZlX4t9kxGouH1xgZql5mkwzNc95KlPM5w1ZtOwbr7NaS9DtiQhIjezFj1TIFPN7QmYNe+ZlViP4
XJ6ISKuLn9QaTDoOonMl2lT8S7gwnM5kQCfQYwaTnmUUGmXxCFqowLsDtWZjcQJrD/AC9wN9wtTi
k5QL5tqMJd+FEi5kJ8GzHUUNWQMdUyMnNsntTuRoxYRzIF/BoTEVNMPsQmpYDlpxNTspCS0W3gAj
TbXFFI0C52QqVWwTyepYzUq66UZFQ6PTL9CK/WqeKT6r4sNeb9Cs5hBiPlYIQb87LCiKT/MCpzMb
UBsrapi1FruBY1RG/XQdfdak5cBOiDCTVeDUvs6coJJUx0mKh5lY8a6CKNlllYb3M+o+Na2OCBC0
HHUMGmMkeIGB4+R7I/gKZ0DvyCEe3rJKMr0oINtAsq2abIdCuEm/rlAZVNNnLS7Mj+ju4gHehPe0
0qxW0ClxX3E3elSlVyv6TS5B6Q4EDVarg6evDkREeK0wWAW/wW5z8tPfUPLgadFIU/oQvclNUBYq
QRme5iKuUb4fiPrWSzOVgGYmWkmAXXSQ6IdKfJDHLSoFpLKE3K6QRWVQO+I+XwLkwZ7w+eIONdpd
9nqZUzpRxyl0gu6ztkDSpdW6koFAyqHVOlJAp5ri22gn9Q7lojRPaW1uin/1jLRVTKmUdECLqfK5
OxUGm3Anpzc5TIJNg9jbtfaw0xG2ae/xZepSjpeUGhURS2Q66PLzCgXvx5HHM6WP0N3M/SSGdR2h
zFP0vhMabwgicOMglTuTO4NdksaqicsfJ1w87bvxHP1xPMe4H8/x4teM31+L51frD6bwNTUdD0gd
MGFQ7c4U1hHfhPFsgxlrKdsRvDnp9HG8CUnNgDDDUJLP4elXZRy3pbs76/D/awfSdfPhP37GV5jd
6FXuRqCa+imFdQDuhPFfUDVokQTbrEQjOnvYgakkUU9ncoiiTcuy/QdcfkGhEPwub6auzv6SSqPE
x5KIla+B5++Un6+1yc//Dy4KF/U1pVP2l5Q6oizVyHTA6RcVCpGsypeYPUwd+YQWSn9MEbQ2wqc0
nWmcdR4QvV5mdvSjWlvIbg9atQq9jf8ipxMdIm/VIK5om+UN0G3swM3yKJzeJmCaM+VpF89f5g08
2iSzh36lMlptzNZUGW2FKtFoZoYs3KzEol/Bg/kSqxfteDDMIY0t5LCFrNriA1VvwPBZ8g4ePRfz
wWjsZ1RaGA24CEgAKpJlc17uDVg/VHyX0XB/B/KtOsJzVDrdUG+TByPnbJXfZfVmj8UREFkFPc7q
TV4LuNAs94HeqGKVepNesU9vVMP8zXp43nx0jK6juygjZThGKbXnWQpvEZYrWAGJV4mmqhOF4oQI
P+jboI849EnM64tGvQrBSSHQOedZmr4ZniI8BU85idzU5R7E0ibT5zmTKJqY59RGNUdno6FQNBJS
k1MupU+KX2epkp3SU8anKaXmfRZn9y99jpWleOHzLkEUBebveaF4NuT3hoJBTKHbi4+hP3B3USEq
mLcw2DgzOCxkiAJnLD7t7VQuDZpB2hCpgDhEtFX2D9UxhAslSqLfrRtft4ZDBo9DdJp0THZxq9vX
trgJqXm31ebmaW7ji8VVZ18vrv4HnaDlaIWK2/zKG2/t2PHmz392JatQgKHksczdBCN6F0YUoJpO
UqLkNYty1IWvT+ORiWQzqJbE9dIIk42VPZvKsoXPis0ZOibrb5tVRO+6W8eyjM7kFJ0ePeLWTkxM
sDTvtlncgoq+cjft2PHWG69s5lQKmgOT8lP02Otn0WMvqnkNjE7BnikuhPE9WzxNu7g9lA8shuMn
RucLeO3S58skL0cjgUrQRjjeZTSUKJ1V1GpFqw5RCog2jIZHHsHX4ucBF9gjsyKJrZaCtwl+96ed
CiPZ57W6eBodlz+N/4nD+IJC/jRO2rIvB4szYSPJ3R/XijZdyWBkQCoeeUS6lnQ2Ufup2QVhcECw
GRXc826/YOMVSsFlwrJ9F7OZfoDbXbaFrugAD8KdO1NtEphyKvGiHquFvg0GLop2o8KmMQds9oBZ
jYpfvKCvPsrcUUkB/WO5VWy4sI/nYSzXQPT5Q85PZahB6vBJagg8SJuRHl0/hJK7c2hzDs3LoUwO
hXMoN0XPy5t1brfupmZ0dTMabkbtzSjZjJrhjePXUQgzOXbspeM9752Ax1D1OqSbKn2a18ALXXup
vp6LTiHqKdOqvilkOcKtq5zjBLYafxV8yPFfEA9dxNu+SAufZkpWpTPYi9MXyouyjeWc6w8zWx/d
MbZ/bVeEF+sW7nl0W2QkX2tQsjRSatXaaHa0afyOZQnG2TO6vGHLvauij9uyq3sjQ/NzzkBuIpef
6PagR5Y9tLcQH9r65e9MLPn+t+66slNtFLV6o8kgOnmVQTCMHPzeWqPXbmzbdOf69nW9Yb3NJ97y
+JZU/dgmvJdgMdD2FDlT0EINoFtPUlkckgt4wxc0sHA1T8k9zeWeTLknU+4hCUlhJjFZIJuzYYkK
qL78O/XlYL+6hxTt6qdoR95hjhMtEyepBLntl44y2PNOrzHk9eITLmaCvGavppX8TisOdy0eCADJ
jXInvrH1FD2PokqvHsWLPLPold3j8h6u03KF7DTZStKLYw0NfkZvPTy0tzzo3vKge+VB92JWEzTY
H9c0d3Gpaceq+dMVZmmrHAh7VQqcL9hSDhe+KleNuafyh+GqHa4WSaXOnKRgmExlh5ctm8WHgst7
HLLMqc4dj14z+a1t7fHhbfM71+YDDVcc3rzxnvFavMFrYPtw7A1P65LmrdtdbSs6N22tCc6/si+3
rst3+6GDt6GRpbetrqtZfONo1+blw0Hf/LG12b49K5vSY9tyTRNLC/7Q0LJ19LqavnrHxmWxeZ1t
vszN09+uG+7pCvi6ewu1G66+BuR0EHjpBeAlE/j/5/KOi4oikXJRJIVj4wjmjhSqKnfgGp8ZZ5TM
ePHM+HC2+RkanEPKLyXT/DJz+eWst19OK8H1Pewthv0If0dNXq3xU/VUnmLIuXg13lumWaihKZIX
IQfOJIY4TSSe0lCaVK0L/1lR4xJ88kfe4n1+Zt8zxFEg6NW1KLJkf6KywlYlyFnmhfS1T95y02Ob
k/Vbnzy4D65PGlzJztH6ZVd3Wb09mwZbl3WBv0x/+f4Pj2xY8b2PHr7vI3L9mw0P3LCsxbHoKz/Y
+tV/ONgenjdx/e2gvh4HsX2Is1F11K/z4bAXhT0o7EYhFwo7Udgh7/tNENqLOEKuJ3t6MLnrEYVJ
SyXk7GRCJmhCztMlZIIm5BA8gY9KGbx2fJNdi7FWkOUIrkSuBFmOqvpPy4djgPRwx8MCEkziFMod
DS1O8FNIKZ1QbMxNnyG5YfxzBm+3Kp8kkIRhJg8yLkeD5aMEYBMVUv6jJSLXTolNZR5SaPTK6bVK
nVahUOtVyPAp3lnFKLRqVMPqwIW0gyN7DmIyrg9nf5W80yQ6BTXzxv0aVu+1CXZep3iWYVnEKrWK
z+5Rg3MG1L4eqP0g8HQ3dV9en8iipBclPDinlJ8qm6E8smIuthLNY/WT3AWdOt4UAaDaZFq3naIP
UFqJOFqcQdLiiqjQ2ub3twHz1R1vsirqlvBtUyheppCUSU9LygQUyJnKUWpCI5IruoA4OP1z0TZj
RUV3KMkhjAc58Bunmw0Wo5LRGHWfrdjSJrqbF2XIJmMlOM00p7J3rLqmY+Lu8TrrwB3bz9BNKqOW
G8InTJS812r22mx6pFn7tRs3JpOj7cFgPKgSvRajlTdYwiF789qb5nfvu+eJ68+qRVK9uBJ0wteA
fisRd5JaDSRzY5KtRg0qIEoDFvwGQrcGTLeGKbo5r1mwJLpggd2ERvM4dxmFX4nilFoeeqN5xuBS
8eVqBbnT5Scb/CSWdQHlnyZpIrIrF8u3QWZNg8ztBrxwJlgGQwfe/NGRJ8mJDkRYV2ZhyQJ0CB2C
NTuFtHlNYUntH/x+roAPD2krh4fS59v4yvkhUN1pSd/Lup5scsMbBsS2GT0vKwsFiWMrNQ/puKXs
ssk9sy2iBSzA17p3ff+anh0r240qBWPQq5uXbO/rnewLJpfsHd0Ha6VUaA3qHb1bCjFnZqy5fcNI
owZnocDDNrUv255f/aU1KX/36o552xel0PWr7tncYvH4DAaIesJuf8Qf7F7W2LIyHwTxsJgcRmUw
v6olXsj6QvEQZ3RZjTbBYIJ1rlu6e6Bry1ibllY2L7oG1nkTrPM3OAPIyXN5fawFxbKkEM4QOTku
iUmLLAst5A+X4IN3+HBRHMgdx8cY8WrEDQsbtzceaGQaZz+geYpuApP+nmzSTz9Ndu+YpnBZHO+O
M9mz+Dy6rrb9j368g5+rHbNfsGDj5/GCpZOIPyuv0/Pjr0pLJgkVlqqZNbqgMIUNb+iCP10AHr68
FY75Rv/BI1s7ty7NgitNYwdbUzOwZXDedWN1sbH9y7tWRt12n4fuUhk1nFksekKF+u2Pbm9DD1/1
7e3tgsNu0AlOUXAJKofH6e+7cqh7Xc6nc0ZoY8CvBtELx4v3c3Tzhi+XSmVvmFYwPwVSlMoeHLzG
3/oNK0FNMFNsAGIE3VHRzUOEcObVcqICVXQnQti3yGatNrxFaYpVaBSf/07Lq1mIl7T07dMHIOKl
WTWvZcwaPd0tuMxaprgLx3M2d9Ci41AXalZorSEPhE60oriTi0l/BeyvJEDpy8Kv6Y1V8I8SMMOz
wLEZYJcSeOhPwvkZ4B5QNP8Z8LjicWVB+UcJVD+eAXVKhqnZQFOjeaYM2tAcXAQ/uxzortF9dCno
/0ICQ3oWeOr/LhgfuhT4EIEHZwchROCHGESqCn5hur4azNRl4Jvmb1rqLd+TwLp9FvjN/w7Y9s0G
9kaHpgIPOEplcE7MwRz8fwqPzAqvOl91uV3dANtcDxH40L3gsnBDFRwG+Lsq+BcJPHHPjZ4nPL/6
88Fb8/8E3vC+4Sv+n4H/SOCqoCr4efDz0JHQSYDn/tNDaQ7mYA7mYA7mYA7mYA7mYA7mYA7mYA7m
YA7mYA7mYA7+cwGpIyOKMpyjEH2TjqLU9JsUS4mlDwCvKr0PeLK0HvBVpXcA7yw9BnhX6UmKRQ+U
/ivg06V/AvxC6XWKZZZRRsArKR3g1aVhwGtKTwGeIO11pH09PFmg2NJvAU+WXga8s/Qu4F2l9wDv
Lb1KCSiO34XnY3ya4B/ju+BToM0sK/0K8GqCJwCLMM5/AzxJaSgR3v0I8GoYg8isoVYBniDtddC2
w+f+d8CTMC87fO57gHeVfg94b+kXlB3ufRHwShiVHZ7/O8BrKAbwBGmvg7YbnnAOsAj3uuFz3wE8
AaNyI7r0NmAexuNGTvgUN/KW/hlwvHQa8BdI+y7S/wC+F+b1MuDnyF0v4DZQ5tdUFJ5/N2ARZhQl
84rC838JeC98bhQ+5UXA+FOi8Cm/BeyFZ0bh+bjnLtJzb+ktKgpzyQBeWcoBxrOIkvFHma2lZ6la
MrtaMq9u+KxzgFeV/hvgydLVgK+CVegG+lwLeFfpy1Q3zOJ9wA/AWnfDyJ8C/FxpCvALpSNUN6y7
AHh1qQPwGnwXPBm310F7BcxoC+BJWJcV8MwPAe+FEa6AubwKmC+9BtgJdFgBc3kdcBzWawXMCLfv
Iv33Ap1XoAdI/wsYw+xowCuLnwFeTekBr6HqAU+Q9jrS3lq6D/D1pb+HlZ8svQIYc9oqmNEfAe+F
56xCi6gOwFuohYB/TPmoVTCXLYDXUCrA6wjeSn0J8AHKC/gWyk+tJquzGij2W8ATsGqr4fm4vRNW
YTU8H96FubwJ+Auls4BPl/4V8HOlfwH8AsYgIxpqAijzAeBJ4MAJuBfjXaRnb+kP1ATc9T7g52CN
JuCud6kJoPBvAa/Bv8lMkPY60r4eaDsJT1sPWIRPnISx/RjwBFB7EsBNTQK18bdH8iX8HZDOEv72
SW8Jf//johL+5sndJfz9ljcQ/AXSfydp30V+8yukfW8Jfzfl06R9uoS/nfO5/0Xct8BHVV17733O
mfckDIgaKI1T8BGQhlRRKSAGDIqAMEWxNNQkQ16M5DHMTEKCBA4RaYDcduT6KXJti1S51vrz+vNV
tX52YriJj1yLgBYRbcS3jZBaiqk35Xz/tc6ZRwAt/b7e3zfLtWa/ztpr/fde6+wDeMag3+7sMugX
O7sN+q3OHiMiKrA6+ZDfN1ZDLjEugywW50DSGlVgjahcyuUa439BRmDbcti/Tyzn6F6Oqw6JKFp2
QBLaUXj0AWQJ1i4KcokoPPoxpM+4B3K08UvIXGM7ZMC4F7LBeBWykWUL7IzCIypv4ZHtXI7D8ig8
onI39mQU9j8iorABawn7fw25xLgUcqm4DLKUZY1xF2TE+DcRg4W/gKQIisFCkoR5jFcwBgufgfQh
XmKw8GnIXONJyIDxMmSDsRuykSVZGIOFVN7CI9u5HIcNMVhI5QRiIQY7XxExWJgHucS4BHKpyIYs
ZRkxHsTOHmF0Q/6AJe2TZsy+HzLXeBMygN3SjBkPQm7h9u3Ifs2YhVoSyDDNWNnfQXYjNpt5vzXz
TmuG/v+QCrLBMcjtxmeQsAqyw/gcsotbuo2DUsFefQuyBHIYxh+FjBvHIbcbX0AmuNzBssv4PWQ3
l3uM9+UwXPspZAmkDxgehWyBzIWeI5Dbjb9AkoZc1pALDe9Cdht/huwx+mQuNGAkNByRedBwANJn
7IMcbbwCmWv8FyTuMpABYzdki/E65BbujRsfQCZEFmSHsEN2Czckac4D8q2QS4wmyGIxCnKpqIUs
4XIplyPGS5DIGDKA2Q9C+oBYALN/BpkLXwLIPGdBtgC3AOaldqyCDCD/nAuJnAa5VNwAWcLlUi7X
iOtkMeNfzPgXM/7FjH8x41/M+Bcz/sWM/83Qcw5kKWSIyyEu18C2tyF9xh7I0caLkLnG85Atxm8g
t3BLHDprMNdxyCeND2UNvHtcNrANDWxDA9vQwDY0sA0NbEMD29DANjTy+EYe38jjG3l8I49v5PGN
PL6Rx7dgzBeQHcYAZBdWsAVj/gLZg9VpwSq8JTfxvtrE+2oT76tNvCs28a7YxPtqE++rTbyvNvG+
2sT7agvwd8t2IPAGpM84DDkaY9qBwAeQAS63GH+A3MJl3FUhE1i1duwKDyTtinZYEoBEJEIW417e
DoSXQpZwuZTLEeyxOKz9DHK78QlkAmsdZzvjsPNTyG54FIedR2Qcdn4AiTuL3A4LP4L0sRyNa7fD
wk8hW7Abt8M2atluvCe3Y3YP5FJxLWQJl0u5HDE6ZAJ6DkOSngSdHCBzWeZhZIL9TUDnZ5BbuD0O
PBO457ohE8IL2cGym2UPdkICvgchlxhLIIsFohqzT4cs4XIplyPGa7IDs38C6YPmDsx+BDKXZR7i
qwOzU5lm78DsVI6z3I6TZQfP3oHZnZDdXO7Buncw8h2YHbuEZ+/g2Tt49g6evQOzvy67MPtbkD5j
LyQyIWSu8TJkC+K0i3IgZBz7swsz2iGfhJ1d0HYpZCnLiPGC7IaedyF98L0bej6GzAWe3fDCDRng
9hZu38KSYqebMexmL7rZi27eOd3sRTe8qINcYiDbshfdmBfnKvaiG7NTOYLc1UMnTEgfl0fDlx7M
TjIPu6gHsx+FbOHeLdwexz7pgS/UmwCePdhv1NJNZcwyBrIU587FONHjVI1zyK2QUaMBMmbcAtks
3Opi7K7X1cV0nodcauDeQ+d5yFIux4yXcZrRhBdyhHEQEvdByAqjGnK5cQQyaoQgY0ZYXQJrD0AG
xDmQ2439kAnjccgO4znIbi73YN4lmPFKyKWwZAlmpHIplyPGT4CUZtyoFvNcOH2JpZBRMQUyhmuL
gdWrkD7jPsjRxi9UOo/9EjJgPKLSqexZyC3cHjdeU4uxCrMglxgzgYt2YgByBOzB8wPsWQr9w9Sl
0LkC0mfUQI426iFzWQYMnA/kzcIJGTKOQzYY+yAbWbbw+E1c3sLj27kcN26DfJLLCeMDyA6WXbBn
Kd15IXuMj9SlsG0q5BIgUMJel7DXJex1CXtdwl6XsNcl7HUJe13CXpew1yXsdQl7XcJel7DXJex1
KXtdyl6Xstel7HUpe13KXpey16XsdSl7Xcpel7LXpex1KXtdyl6Xstel7HUpe13KXpey16XsdSl7
Xcpel7LXpex1KXtdyl7XwOtnVLpbvaXS3YpkLsuA8bZKdyuSceNNNUInBMgEyy7sxgg9M6prKdtD
hsRV/Lz7bWWsoP8fjz4VLFV+Cs7mGpUVka1qVlkVBeoIq6xljLHhmXCWVbZntDvEl9iHZtkpJqh7
rLJL+LUbrbJb2ZEa7xE3aTGr7BUTtJetcpayTTtmlbNFjaOdntP5c4ljwCpL4XBOsMqKcLhWW2U8
tbrWW2UtY4xNeF33WGV7RrtDtLgesMpOcbar1yq7hM891iq7ZSA13iMudl9ilb3ibPfNVjlLzndH
rHK2uNzzPCyRmsvC2SybOJtlE2ezbOJslrWMMSbOZtme0W7ibJZNnM2yibNZNnE2yybOZtnE2Syb
OJtlE+df4invEjyfFIgpKF3Pv/4cEfWItXpRhVjzi6v5V7PN384OoiWEUp3IR89MUQPyi0Voq8ZT
TQxXUa0S35UY3QhZgZFX47oajFmGthBGhHhcEFwLXRU8tg61KNrquM+8PgQL/OAgxoWgoRm1VSjF
MJeff6t7Gco1GOtnmxtwdQX/Fng1a6m3tMYwotaak0b44WM9z1nJv/lNvlzHvlahJci/RR1hL/z8
HWQvaV7Tj3L0TGTNtdxSwxqDwMhsT85SCz01jFjYsrIOLbU8q6mT/IxlWEAzhtmX5G+Vm2ibttNM
9UDAz7/SXc0ohPh3uen3zmNcI49jqfUwMTNn8bPtdZZf9YztMh6ZtjjTI0Ktia8zvV6Bej7vh8zV
vIi11bKGZsahwVr5TLxpxUz/K9l+8t9clwjvBvo2Z6S19kNHOOWNaWO1NSaK2mpLewxemCvUmFql
IO+RIFprh/iV3M3lsCTI85db8+fzjq3mtaKeU2Ng6ileT01FzWXiJmsXhaz9dhk0Xo7e0+/6Smv/
mt4ELfurude0p9JCjGys4J1LVq3gNUtec/reqn8ogtO7xVybxaiF2Aaa/wbe7bEh6zjJsqA+w4Ny
K+5i7GUl7+X5aCkXebzG4zGmgvVfy1aZ18ZAYaA4CbSKKZ9jfKjl+ay9FmNi2FtkfzV7EIaGZrTS
ClaxLxQ5Q7Um2yl7mCuwIqXvB2yzuWubebdF2cIYx1WU84B5tZ99oJis5B0V4jlMhJbxtUn0ZgO/
+ciI5rWRjB4znisYk3SMruK5yjmGTzevWaex5dhFDYxhRWrPV3B/mHdsc8Y+D7OnddZON3VVsqTI
Pdlv6jczRB6uGs+7sxZ+VaZi9lSr6k7RfOYYpbUns7TfyrPm7ikfku9O9T29X4faNS0DAfLE9MXM
+sldH0ndQSo4h9ZxLg1+pacmzsEhmFZau//kGCBUaec18JUVnI/Im8qUHhpZwznt61bonxUX6ZiY
xNZQDJh3onxeq7Bo+qX/koKCKf7rQ+WR+mh9Vcx/dX0kXB8JxkL1dfn+mTU1/kWh6uWxqH9RZbQy
0lhZkX91sCa0LBLyh6L+oL+2vqIyUuePBuuifvSHqvxVwdpQTbN/VSi23B9tWBarqfRH6hvqKkJ1
1VF/PYbGKmtxZV2Fv7w+UlcZieb7r4v5qyqDsYZIZdQfqQzW+EMxzFEeneiP1gZhQXkwjDJdUttQ
EwuFobKuobYygpHRyhgriPrDkXrYTWZDe01N/Sr/chjuD9WGg+Uxf6jOHyM/YBku8deE6jBXfZV/
WaiaFZsTxSqbYrg4tKIy32+5eVHUXxusa/aXN8B50+7YcsxfucofCcKXSAhu48Jgrb8hTNNAYzVa
oqHVGB6rh0ON5FLQvyoYqTXnIpjLlwcjMKwykr+osrqhJhhJrcDU5NRTaWkuuwkQwSn/ZfmXX5IB
fSXwxTRB6K8OkR2VMCwSrKisDUZW+OupJ6NadfoFZljgzeK6UAzX3xALxkwfJ0FBPU9QjrWLRUKV
0fz5DeV5weh4f0Wl/9pIPXpjsfDUSZNWrVqVX5tUnl9eXzsp1hyur44Ew8ubJ5XHqurrYlFrKJWr
gnBgBY37QX0DoG32N0QrYQRcom5/ECtZGakNxcigZc1s3uzF82eiN8IVrHNFg7miq5aHypdnXIvv
UF15TUMFYVHvrwhFwzWYgDAPR0IYUI5RlXWxfH9y7vo6bIi80Hh/Ze0yuiitqi45+LQW8XDa0oA/
CnjKzX2Xmp1xtXRNYwPyQpgFW5+gj1CAVNSvqqupD2ZOCpuDpqUAPrUC9Q2xcEMMsDeGyitpzPLK
mvBJDp3JWvBKTKqorAoiiPKD0XBT6nmQ3um0UZzuIzECTxTiLOEwDDEMzy7mU5SQeeDJ5t+jfs1H
02Z7vRJjlB+e6fisLBqvxs90/LBhNF7bfabjfT4abxs40/HDh9N4x8QzHX/WWRiPb0FPlRqPp6fq
a1kOF1lihBgtcnBeHiMmiwtxUpgoFiA/L6W/gxRFyM+zRav4vvgJ7tL3imLxkCgRv0b23o3e15Cz
30H2/qNolkIqMksOkznSJy+Qo2WBzJVXyjw5RwbkYlksl8mbZb0MyTX0p9oobZMN8gHZKB+VLfI3
9CfFaN0n22WvjMs/yu3yuHxSUWRCyZIdSo7sUsbLbmWy7FFmqnOV+epi5Qfq95WgukSpUYuViLpU
Wa2WKK1qqbJZrVG2qhFlpxpTHlRXK4+oa5Un1HVKp6ore9X1yrvq3Uq/2qcMqJ+pNvWIOkI9qp6n
/kmdqH6uflc9pl6jzVZvwHrfPBQzNfgPYrYZmN0NzO4HZo8Bs98Csx70vgnMPgRmfwZmTmB2NjDz
A7N8YPZdYHYtMFsEzMqAWS0wuxWYtQGzu4HZA8DscWD2PDB7CZjtB2bvArMjwOyvcruiAbPhwGwM
MLsImE0BZlcDswAwWwrMQsBsJTBbA8xagdlmYLYVmG0HZjuB2WPA7Glg9jww2w3M9gOz94HZMfVu
VVP7VC8wGwXMLgRmlwKzQmB2PTArBmbVwGjlUMzsezMwOxeYXQDMLgVmM4HZQmB2MzBbAcyagdmP
gNnPgNnDwOxZYLYPmL0LzI4Cs7+JqPSImBwLzL4LzK4FZjcAs2XArA6YtQCzTcBsGzD7d2D2FDDb
DcxeB2bvA7M/y0bFLluUEXKTkiu3KN+W7cp0GVfmALMbgdkyYFYHzFYDs38BZvcAsweB2RPArBOY
9QCzA8DsD8DsY2D2J2D2pVqjqmpEPVuNqd9QV6vfUteqF6nrsId0dZ66Xv0hMKsFZo3AbAMw2wrM
dgCzR4DZc8DsZWB2AJgdHoqZ+4kMzEYBszxgdgUwuwaYLQZm9LQTBWat9OvOwOwhYPYMMHsRmL0H
zD4XFYj35dIHzM4DZlOA2feAWRkwqwFma4BZGzDbBszuB2ZPALNOYLYPmL2LEZ/LesRdA7BqVC4A
Zt8BZlcCs/nAbCkwqwZmUWC2Hpj9CzC7B5g9DMyeBmbdwGwfMHsPmPUBswFgZqhLVadaog5XS9XR
wGwcMLsMmE0DZjOB2bXArBiY1QIzHZj9KzC7F5j9Cpg9C8xeAmYHgNlHwOy4NluzIX0NH4pZ9n9m
YPYNYHYxMJsGzOYBs6XAbAW9iReY3QXMdgGzDmB2CJj1iWLpEiVyFDAbD8y+C8xuBGb1wGwzMHsA
mD0GzDqB2R5g9i4wOwLMDFmsDJM3K34ZUibJGmUmMFsEzMqBWRMwux2YbQVmO4HZY8Dst8CsB5i9
Bcw+BmZ/kV2qW3ar58oe7Jm56mR1sTpb/b66gP6sHWgsg1wBzGLArAWYbQRm96D2c2D2ADD7FTD7
LdDaB8w+Amb/rfZpmvqZNlI9op2vHtUmq3/SitTPtRvVY1oFMIsBM30oZmfNzsDsm8AsH5jNA2bL
6d+5ALPNwOzfgdnTwOwlYPah+L5UxQ/kSGB2GTBbBMzwlChxmpd3ALNHgNkrwOwQMKO/Mx6UoxW3
zEUuylMmyADirVi5HpiVArOVwGwjMMM9QHkImHUAs98Bs7eB2RFgZsi4miW3q9+QT6oXy4T6Xdmh
BoBZNTBrAGZbgdkOYPYYMHsOmL0MzF4DZm8Bsw+A2VFg9lc1og1TY9rZ6mptjLpWG6eu06aouna9
ul5bpt6trQJm64HZVmD2C2D2BDD7T2D2BjD7CJjhfmyz0/nC6cB/Pl9eXtGa1lanTTodvfF4f1tb
Wz9V7OE2HZ+2sNMunc7+tg34oEdDT7+u4z99SEXnYRgzSAOdUjo13frQMJtV7nc6pdPd2fkAPvfc
w9fs3n3//Xfe2d7Ok/L0GOdyoKdpA3+a7Gwcd8Xb2njWsrhe6PfFy5w24bQP+M1P0gS+iL1rbS0q
ysvz+Zwe4fRs8G/wzy2cW/g9kF/3w2Jcu2HOnIKCOXM22G3S7uh3NrW1NfFsMLWNJrRr0m4Lk+lh
bnfSEAzi8eG2AV1vcmrCqRUU9hfSB4Ps9qZ4vEwPmzhC06Mv0iUmJsLEwa0aTtUvLMMT7JOux3ck
duyIDwHP7pR291MvbcKHpzR1WbPjQ1bZHaatgJoqpoFOp12Vdq3X1AIv7GE9UeDrdWjCoZnGFrAa
Gr1tud0m7La2tkDA77e7hN3Vprfpi5GXx4LMPvQE2pzpYYWFNIGtFwW9N8NmoauKkCpa7VLaVZ1O
a7rEB3GtSKdaqNMAJw1QaWcEduxQgaAtENjhsQmXzen0+fykXtcRl5rWK+1Csw9CGvZBNzRo1EWf
wkKuUoE+QJWqiSR0CbNaaH0SqorZduzYwXuGwWP4UCnbwcswYPXAAn9hqhJ2Oq1hA7x/rcqUQt4h
4aQ2Uhi2AR67XpZTpn9NcGGXOqYUkYVFU/7JweWSTk+H3qHvBN0JolU8JcgcqSBDLLqmFLXiUzRd
/acEmfeUIOMRRejOK2rNCDKXTbocemaU2c0o4w5nKsyooyzeTx2acCHMThdnSWVfEWhaOtBcmnQh
0KxIc0npSiH5/xRqlCUeTZwUapwYCk8fa/aviTV7Otbsp4m1TKu/PthcVrC5rGBzWcHmOrNg80BD
KtgQZFxPRhuauZ4KNz1h1gszA85lBhx2VjrgUEkHHPckA86sWAGHSjrgKGRSAWdqOyngXC7hcjn5
RT2E40yxjneAyy5dTrpuAPt1ALcVl3P6LDZ31nSquQY20P5vRR9togHdjLh0bUA3b0cuFw07QWLo
tqGR9mRlwOWWLm8Cn/sK7yvcytQOQqi53B333XfHpk23334bG8UG8RZ1oW+6mCXWp2gWzidSTw9r
Q4Zgi+imzPi4HMLlOOGzPin7KJSnMBSkeSZgIDAIFKdweaQri+JzsxWh39EpQgGay7l+1vnn55x/
/qz1Dpt00CI0YZ+67dLthJqnd8OG3U9Tl3kqaAtzl6ZpsXZ0tcccdumg2/Wgrq9xa8JtS8VpIUY6
HGtorXQMaBqiE04xlFas6l7VcKWDFeHqtkk3BXYbxWu8zS2lOw287nBJh/dx0cNpziQ2xNKdNGqD
Oa3Vvvtpgpyqlu3wwqFJhxW+OpUpFZX5fL2UcmxJTwpYH6uDwwQTxSaC0+EWDk9RYVHhBJ1oOM6d
Zjc6A4E2d8ZQBBrr7/dRyPW7peJOJm9goClC0SiyHFI64CfFsq5IqWjUB9cpFM0CBmnAxj4nHo/j
yQGFOXPiWXbhsWvakJiWmq1XOoTNcQLyhONElirdNn9GUPu5hQrmB11eaulN49xrNqSWxd+raZgb
U8etTWnFNtes2PYPWH1sTmG6Zm5fK7wQ3ska4tsM8JROK8IBH0e42yXc2KzpGF+H7c0B5JBuF8cJ
xfKg24nqjJmm7TNnUNU92LqeP+ilDTiYDOxB3mGpONd5MA00ePhJG46udaRqg26PdGclyhJlyHE7
7vDfgcDa7KcAYy0U7Wa485RknxnvHrd0e2ZYtic/M+lfjyRSniDkN2xoZeMo4sp8BJPbIdzOVMz7
UrbSZ9Z0hufUqHcKMjN7gz95Z05Hvht9ZuSboW/Gi7YG+9tjlx4K08zYd1ixz33a6YPfowkPBX8q
+h3oW0sRqOMctGao2r8b/h6b9DDeVvx7pPRkLMf/UAIgV5s4zfb/TycAj1Q8yQRwBhnAk8wAnmQG
8DjMDECFr8sATmFzGpAnnEa2Kj0ZGYAin5vSKYA6uSkjByALmE3+jA/lAQ/nAd7i1vMaoW1T3E5/
KhNYvWyYv3AwVW0C9NYtYQ0cyqhOL7T2SFNKM2tvctDxE+lAQ0LwuIXH7bXe4vctUKG+TseFhXqh
xyE9ViBxTvA4Uc8Nmk4XBnOp7h7YaGaF1o0DvDEpK1hpIV1noXtc0uNJY2Fk4HLypqRL00kCqrKk
Z1giJ5GzI29HXnxOfA6lytudtztbnaw1oe8AxUFt+gZQK2i9bjnAJxOODTeGjhHlQ9LGTNS/ibSR
GmymjVa2vmkDPC1wEqQeh/BkJA7fSd6k1c0QjCkhiP/0bzGqhK4XxI60wuzZPpPyyKMdvkJfoccl
PC5SYOYdZ+oQZj26cFZB1Hgd0ss56unddFTZ/fSQhyHuVfCZeg31XjOVr51SRJkFvTbhtU1JpxZa
Y2c6t7SuOUl5a6uZvVN4ZamGOzO9+BNeu/RyOrLyywavlN7MtdSdHunMfibR5d+QQU5M7EpOwhXr
IWqKJ93DaYbrSW/gGD9WWXlGtw6ylNyR2+luXlg4YLo2hbWaEwAGPEM5T/uUlUw3rIqfFJBvPJnD
kQfMozQiz1+oD3il4k2dVoekHKdU6ElSnJRzvMmc403mHG8y53g552Q7hNehKMmsYyUd29CkM0yV
Xko6hdbEKPm5jUvJrFOoc1vvkF3Za7Zl5h1OPF4HJR7e+ib8yRXwuAoCcWunn+B60wZgr1HuSdeR
fBSFQgN1M/koqbqZfdL6SH+RKTLzj9cjvJ5skS2+wfQd/Tt6WWIdDgR0JvA6pdc92NXVtXuwq7Oz
s2vQ60LDeSKsl4lEBpWh5TyB8PZ6T4hOPLsnMj4deqd+QvDGPkH1QW49kW44YY7jy9OXGZk6El4F
Sz6kAZc7M+onvNnS6+sd0zumf/qeiQdqDtS8OL+nZ3d7d3unt9PLunsT/Yk9iQOgHlAX6IVEZ6Ij
YXnJDrKubK/0Zp0nVlooJKkssTJxni56RQHDMCi6RCdTl6CyWevQ2bHpVYlEb9OYbLu9p8nrFF6X
kZP+nORp+hPUrxK8IOZ0RLQg5tLQInmHSe/wDnuHvXNjeXt5e1VPVc/lByYvmd6UU5BTwH50dlZV
Tc/JmV5V1dnJT1Rruuz2tV1drzZmOWWWm2Y59GEnfT48ZD5JVvHUVdO5X8VnWjX3V0+jBz540tWF
FVo2Pcsus+zTy8rKBsqsj5f612F7dK1JrMUVa0+eorMzS5FZWiKB/J78+DQjy1ZQIERB+tOb5ZBZ
Lurt6jnQ33+gp6fLujDj4/JK17BDvR8VdA0hfipNzce16VVcrpruzej78BDtGmpI+Qdf+Zx+oDc5
BT2sNu2mlfO2N9HJzZ52dwrrtuYBOPSASn9OVS6ILgeNAbmy8R9tufKc6m0V2yY/Or0/Bwd/fkDl
paGV8Z7+2hxQgWAjBr05OQXYAoNZipKVsfGBo02Vig32JHTcZ1w2AlcQvnTTsXF3ls2PnWuWeKAN
8DrHVvX09NgcIstZVVXV0zbcIbIddrvXi5lyaBFoZEJq0mbvl/QnOoaOrxP48mlYeLPb/KBYwI1c
sj7Uz439Q/d0v9lYMOTTb8NmcvbQh3ettWLJRfO6pzQdSEaLwQ1rurBaMBeopBvs0+1o7VrDDWtp
kdZkNOQygF1ppTRLFU9VRX9ugieNMp9X8frKdPNv6t1ip7JEqOXNkRoxsjpSuUJMrQnG6sR89Mgb
Fs3yY33oHef09zJ2kYUDglmTAliKs7ndbFFwfBgmzgGp1wUCc8T5ixZe7xcFNy6a58f5xBxD/1bC
J87lmooZhqe04/kDx5VRVg1HBnGWGC2+UR6OhsX9LB9i+SjLp1g+x/KFFZWROvEiy1dZ7md5kGUv
yw9Z9tG/9RGfk5R2lqNZ5rOcxfImlrfUrqhdIdey3MjyxyzvYvkzlrtYPpL6Fw9/T8ozlE4gqQID
OxBGBAGX/39tCtYh6x/+zha5/G+F6V+TtoqtYqd4TLwg9orD4nOpCBd76rS87RP07/RVXDcS2UDS
32/JqeZ320bz+6cDGddgvx3ZOaQuvYND69kXDq0PHzG0ftb2ofULTgyt553UP2H00Ppk5Csls34s
o98u5LXTh9bnb8a3G3s6TwTo/23ANa2AqkAJiHXK/crvxQ71p+pPxX4tpt0nXrfts7dJ1X2DOyif
cf8IDykven3e2crV3qXenynNWRVZtyj/O2tdVruyO1vJdip7s7/I/kJ5U0j9OGFjfyPrqdPSHtDB
rPcz6FOL9pyGjmWPTVEeaCqoCHQL07aTKWtP9s7sJ3x3WbQjgx4ioqPuacg9PJCizcPvTNFxk0aM
OQ3lgyaP3J5B95vEPSfRyMdGvpiiV8/uBX1IdI52OhqRf86Ic/LO3ZxBdzK9cFrac+6XScoZmTM6
RUUWzT0tBZhusr6Hkm5JGtfFtD9F5tXv5PSPmjCqYtTPRj1IdLL2UY+cjkzto54eddiiY2miWUZ9
yXPpxN+cP25qiuaPW5SiCotuAenjbqEfsT+/8IL8C4rG3QKZf8ELF7540RtMx/KKQeHxF4Imjj88
fgB8ePyJCS9e/DOi8Ycvfu7iTy/+dKI2MXviyInPgvbnzwAF8osn3WvR89/RL73w0o8nb718MmjG
FTlXFF/RNOUxi56b0jVl/9QJoClTN047dKWdKX7lC0yDMy6f8bBFT105iPrDM/q51n+VcpUy4+Gr
Jhb+uPC5mfmzl4DeuXb5lXFzNL77zVHXzaBx182fO3ZuwdwZcx+cdyFTYN4tTE3zNs67F7Jp3sug
3vmr5+vz37k+DLprQRlGBRa8uuDVeS9DHqIS6PCCvgVfLtSZdi3sYXpnYR/4nYXHA9rC4+jvCxQH
DgUOfy8G2rrIj3G7Fh43exatXnh80fuLjiwO3NS1ZMnNI24ec/OF1Vp1cfWB6i+T38sngh6r89WN
DTeFW8OJ8OFwX/j4Sm3lJSuLVlatDK9cvbJt5V0rH1751MrdK/dGwpGtkQcjn0dFdER0TnRZ9Lno
G7HJsWWxextuamhreL7hWKO9cWLjNY0PN364qmjVl01jmq5pKmuKNN3b9EjTgeaxzT9sfqr5QPOX
q72rz1k9ZfWs1RWrd60+cOuEW4tuLbl1260P3Xro1uNrCtesXvNci72lsCXS8mhLV8vg2tFrl6/d
tbZv3dR1Tese0QNfkaueOjkfDc02emOaKI/wn8NYZGaQr4i9uSdH3NA4MXf6abNOMvNk0NDcoXel
ibKDvj9NZl6gHOp7KKfr3DuRhw/O6EfW5BzM38i3wwPIr9uyd/ruytqTypkYO/z4uAq6Nuup7G3p
3GmihOxcxPnXHDU2e2cSPWqlXMxjD1I/j7cQhN6nst5HJt+JKw6ytj2w7i58H2RK3x0+PemuUJRx
H0jfCXaS3adk/4dOyf5uK+dv5nzPWZ714OrsIpS3JTMh1uNBa72Qm8z8Y+Y3ax2RE5EBadUqUtkx
uaLIcTlz9cN0RXqNxy3SD+uHoY1GHUNfYNThcYtO3RPIg/szMupp8mxmXj01p1qZu4t3k5lF5yfz
J+V1tGBWvW/Ug2hZlBO4fPKCV8/RzPsYf+Oede6XZ/diV41I3n2Sd5URY87R0ncgc1fSvY1HazQC
175wzgjqoRYaRe0jxmTtSe7UnNEjxuAOOIKup7LZmr6PZt5JyRa+a1r3zYw75whoOPk+eeeQu+Me
6844Mmk9+r80Z6f55wXO7s0pgj1D0CfUCGOsVEbEJjE2I5HQNHfKuArgPZdWk5DICYzczuv9IK1N
RlRPHfUIfE3eYfebWvW+HF3vM4lmoO9xi2hVqGTuNPrW+y7IP/8Sk8073PmX8F0pg+gOZ97d+P74
f0l8T82gU0fwnTaDrDtuik69gu60/xjxvfiMKXXH/go6GSmi1H38K4jv7GdMfNo4QzoZHT6jZNCp
+PHZJYNo35sr/Y/RqZr/vnVnRibOdHbJ3nmlfe7YKwezDtKphynOLXY66XAtPncsnYGsPhBOUFPo
1GS2Uu6nEhGfjpbwyYrOUP0z+vl8hNMRSi9cGefTiZ46xRDtWqgvOLRQpxMM13ZZ5xyzvAunoMPU
Qicaum6BRXziifHZCGO5dxfJUY9g9C46TSFbXLjgEJ+7miwKcMuFdOriWmDBIcpLVh8IJ7cCnNXo
hEbXbeQSiM9pYT7PYSyf1FLntXmBqxRGZJCw+F7MROJKO/sDi01L573MummmjayL9Q6NxFNXNHMf
XPSGWRN2elOeer3xHL0lj96RR2/CU58XVwh6h9Iefvsblfr4DViS32On0Bvp+H10HvErY1DsNgZl
mThLBsUiuUyMkuXiW7JCDJcr+K14k+ltb/x+Nwk97wkNY70YOxxjvRjrZn0fYNQR4ZL0fpoyMQ79
i9H/TfSPg64LoOtbuPrfYM879GYY4zF6u5u6Bna0GL+GvVPV94y71fdFgfqBuET9SFysfmK8pn6K
p13SvgfaD9ObAA2F3s5G72DjN7A1iWFirvCBp4rxYhqY3shWCa4C03vZ6K1sDeBG8CpwE5je0bba
2CtuBa8Bt4DXgm/D9RvAt4M3gn8EbgNvAm8GbwG3g58Rs8Sz4AGUT4ANMV4KsAQHxDT5PfAi8A3g
G8EhsZDeAkfvgFNvEtPpLXD0Djh6Axy9zYne/qbeJnK1nxt7tR3g+8B7xXhtH3g/+HXwG+Dfgw+A
3wQfBL8FPgR+W4y3+YzXbL3GXtsfhdfWh/Jn4H5jr90m5trH4/tSMd5+Ob5rjNfsteA6cD24wfjI
3ggGNnZgYwc29tVgYGP/DzHN/ij41+AvxDTHBHGe42JwqRjvKAMvA68ER8DNYB28HgyMHHHwHeCf
g+8Tsxy/wvdn4CPgfvCfwJ+DvwADQ2c5uAJcCW4Q57mEmOYaKc7jvfshv9eOSp/wO+nOxq59HLv2
cey2C7HbZmK3tWK33YDdtgy77TrstkJ6lxy9MU69yfgxvTOO3hhH74Wjt8Kpzxu71Pewzz4Qqvoh
9uAnYinvs/f5DXHDU1FRIiZl6J8D/Y3QPxv6r6C3uUH3nfQ+N3qbG72/jd7eBn3PQd9NIhtajkLL
UWjxQctF0FIHLZOgZRK0XAwtF9E7q+ita9BE77S7hN+0Rp6+RO9EEznQ8Vvo+C105MlS41nomQQ9
pdAzGXpugJ6rZMj4HXRNktuMp3Hlb6BPg75GWFYFnWfBstugbYt62DgG615WP0a0fiK+rX5qRexw
aJ0ArSFovQJaZ0Pr+dCYB2376C1BiLzr4eVi4bEyzN+QSSiz3CNuM/rEBvDt4I3gH4HbwJvAm8H0
7sh28MvGgHgF3AP+L/Cr4N+B94BfA+8F7wPvB78OPgB+2zDEO+A/gHvB74IPg98zXhHvgz8Af268
Jf6MOD8G/gv4OPgL8ACy21/R/yX4v8GD4L+BT8AWw+iTAiw5K76nFmOH/dA4qpbgu8w4qu01+rR9
4P3g18FvgH8PPgB+E3wQ/Bb4EPht8MfGgPYJ+FPwH8F94M/AR8BHwf3gP4E/B/8ZfAwMW7QTYMN4
xTbCeMVRaAw4ZoPngueBFxgfOW7E92JwMfqXgkvApUafowy8DLwCfSvxHQHHUF4FbgI3o74G3zq+
14M3ovwjMNbB8RN8x/F9B/hfUb4T/H94u/f4uOpy3+MrM22SJhOu5VoQwk1BAbkrKFet4KVudauI
e7vjBTQIiCAXdRdag7KRS70BRUVQitxsUWJRREKBQksgkLZJmmZKkzYdkkwnaZJmTaYF/J33mhM5
6Dnndc4/5/zxYWbWrMvv+X6f5/n91hAWt+I23O78d9n+G+8Xef+Q9w97/zh4VMWjKh5V8agqG0LV
evCoikdVPKrqc8xGbAKPqoZCtiqPLWIpYDi0V41gq+9GnXsM45jwmXdVRa+TPvOo+sv4Cs7nVyq6
JZpZnrnS0S1y99PJs6H4O92nxT592KdzZPny9MvRO6MKW4vRB2RmVmZmZWZWZmZlZlZmZmVmVmZm
ZWZWZmbtPSDTSjKtJNNKMq0k00oyrSSLCjKmKGOKMqYoY4qulzybLJv+92h6+ov4kgz6cuiXNVlZ
k5U1WVmTlTVZWZOVNVlZk5U1WVmTlTVZWZPlZJGTRU4WuZjlYpZzRa5luZblVpFTRU5luZLlRpbq
JaqXqF6ieonqJaoWqFqgaJGiRYoWqZilYpGKWSpmqZgtV2xPVEXLM1Rytbn3CXPv0nS7uXaVWchs
U9Y3L8JVItxY1vc/fUqeXbsffb/nDGujc82T9ebJevNkvXmy3jxZb56sN0/WmyfrzZP15sl6VzrR
XHmIufIQNduhZjvUbIea3ahmYzUbq9lYzcZqNjaf7qZmc2o2p2ZzajanZvkdfcS8ebw63ahOe9Xp
RnXam/5SdFj6y8mzZ6PrzKMHmEcPMI/OMnfWmzvrzZ315s56c2e9ubPe3Flv7qw3d9abO+vNnfXm
znq1mFOLObWYU4sdai9Wcx1qrkPN5cxx9ea4evNbvfmt3rxWr1Zy5rZ6c9shaiVnfquX/x3yv0P+
d8j/Dvm/Uf5vlP+x/I/Nf7uZ/3aT/zk53yHnYzmfMwfWm//qzX/15r/6JN/DOK3Hrc9uCd/nwNn6
+Ub9/ApOnM2Je317k2z/YHq1lVRH+Fu6M/pS2b2svXvs1W3GvCVc49OXHLvasWtsPd2xtzh2hWM/
7NgOx30uqpyqo8/as9OeHfb8cHl9leTMfeUzne/703z/ku+7fH+KM93g298705nO1OpM7y7vv668
TtxQ/mcxqqnYOTqg4jxchIvxDVyKb+IyfAs/NNPvmjwbM3kOZvIUzORZl+W10d3RXunHoxPST/F/
U3SwWftTVom7mbn3tUo8OD2oMwwZQd62LdEJ5vPLwlOO2NOa8qBkTnf8RdE5yZOjkyepReekv1Be
fZ0T7WRks4xslpHNMrJZRjbLyGYZ2Swjm2Vks4xsliNnOvISR8505CXlI+sqkmdpXoSL8Q1cim/i
MnwLPxTNeeWnJB/jyOQ5yceUj8w4MuPIjCMzjsw4MuPIjCMzjsw4MjN15PFTRx4vks9HR3h3RFnj
5vIaYTJ5XmXy/Cx8Ap/Ep/CvUY21W421W421W421W82M5N/TTkueM5k833BqpbG87NHGqKPiHWFT
xeE4Au/Eu3AkjsLReDeOwbE4DsfjBJyIk/AevBcn4xS8D+/HqTgNp+MMnImz8AF8ELPxIZyNc/Bh
fAQfxccwBx/Hz/EL/BK/wl24G7/Gb3APFuFe/Bb34X48gAfxEH6HxViCh/F7/AGPoBl/xFKrtWVe
nwo9FU/jGSzHs3jO9hWhs2IlnkcrXkDyzMo2vISXrSDOc7fyhdA+7VkrieewAivxPFrxAl5EW+ic
9hJeDp3Tdw2bps/EHtgTe2Fv7BM2VS7AHaBB5a/Cq5W/DVsr78P9eAAP4o+2P+PVarPyWe/bQ2fl
Gvt3e18Mm6r2x9twAA5EfdhadRAOxiE4FIeFzqq34x2hp+pwyIUquVDF96pjfT7Od6eEV6ve5/WT
YWt1KmyqTmMapqMSVajGDNSgFhnUYSfsjF0g3urdsDvEXS3uanFXi7ta3NXirt4Xs7AfjL/a+KuN
v9r4q+txEA7GITgUhxnTseHV6uPw3tBZfTJOse10zMaH8B/2+5LXC3z3Vft9DY24EFf4bi6uwbWY
hwW232P/++x/f+ipfsDnBzFuWxw2zaiAWGfsHjpniGPGHuHVGQfKoe+Wn4tKnQrqVFCngjoV1Kmg
ToUjKqhTQZ0KypSfnrordsPumIk9sCf2wt7YB8nzVZOnqx6AA1GPg3AwDsGhOAxvT54o7C77cByB
d+JdOBJH4Wi8G8fgWByH43ECTsRJeA/ei5NxCt6H9+NUnIbTcQbOxFn4AD6I2fgQzsY5+DA+go/i
Y5iDjyN5Muwn8El8Cv+KTxv3Z/BZnIvPIXl66zW4FvMwH99DE67D9/EDXI//QvKU2eQZsz/GT/BT
/Ay34jbcjuTJqb/AL/Er3IW78Wv8BvdgEe7Fb2EGrLgfD+BBPITfYTGWQK+t0Gsr/oBH0Iw/Jk+4
TZ4qi6fxDJbj2eR5rViJ59GKF/DPXeTT4YvJE3CTZ7cmz59NntuaPHs2ee7tNB1vmo43TcebpuNN
0/Gm6XjTdLxpOt40HW+ajjdNx5um401b4h7lYfwef8AjaMYfsRR/DsPTHsNf8Dj+iifQgiexDE/h
aTyD5WiLMtNewstRZvquUc30mVHt9D2wJ/bC3tgnqq28KQxX3hwKlQu8v837hWGg8g5zEg/K3exu
34ml8l7fGXOlMVcac6UuXflw2Fz5ezziu2YkXe5R+//Jtsd8/xc87vNfYZyVxlnufit8bvXdC15f
tK0NL+FltEeZyjWu7d6u0r1dZZdta8NkuVP2GJv7ucoBx7pnqSx4b3VdaXVduRXuWSrds1S6Z6nc
hgnEKIptMmyu2ikMV+2MXbAr9g6TVftgX8zCftg/qql6Gw7AgTgsylS9He/A4TjGtmO9HgezbJXZ
9b933ShTnYpqq9OYhumoRPL33dWYgRrUIoM67ISdsQt2xW7YHTOjmuo9sCf2wt7YB/tiFvaDcVYb
Z7VxVhtndT0OwsE4BIfi7WG4+p3u0d6FI3GUz1YK1cd4//dOfLz3J+IkvAfvFcfJ+Kj3H4P73OqP
O+5fwvLqT+CT+FyYrP4P47zAfv/cpd3vVrvfrb4Kc43hGlyLefa/wbXVf7lr3+Z1ofPegZ/jF7jP
+e7H37v4Q7bxsDp27GthckYUNs+oSP5Lo1CYkfxZe43XXW3fPcqUO7sZasZetu2NfaAfz9gv+V0y
qfSpddXc5NnQ5TXa029uvyR5DnP5d5RkvTUSTU+dHf4t/bHwjNVpTfLblu+Go3el3h3yqeNxEk7D
2WFV6pzwQuoj+JhV+afDBquL9VYX62vODS/UnIfrQ77mv3ADfogbcRNuhnu5mgX4EX6Mn+Cn+Blu
xW24HQtxB36OX+CXuBO/wl24G7/Gb3APFoV85p0hH6WNtJg61z3xZe6hTzH+2Pjj1MkhZ/xx6iyv
N4SNqR+6d/l8dKT+daQ9X6j5VMjV/Cs+g3/Dl8PGmgtxES7BpfgWrg+x2GKxxWKLxRaLLRZbLLZY
bLHYYrHFYovFFostFlsstlhssdhiscVii8UWiy0WWyy2WGyx2GKxxWKLxRaLLa79cNhY+xF8FB/D
HHwc/4JPhI1ij3l4UljLoRdTZR/DyvIvhweI/X5x35/6fFiS+gouxg1hGQ2SZ5b3iP1+sd8v9vvF
fr/Yl4l9mdiXiX2Z2JeJfVnN1WFJzbfxXczH98MS41pmXMuMa5lxLTOuZca1zLiWGdey6AwONHKg
0dj6OdBofJMyaEIGTRhnr5F0G0l3+tN/m0if+7c4+f8BcObo5P8FwJ2jp+7xl8uuCdk1YXTdRtdt
dN1G12103UbXzZlGzjRyppEzjZxp5EwjZxo508iZRs40cqaRM42caeRMI2caOdPImUbONHKmkTON
nGnkTCNnGjnTyJlGzjRyppEzjZxp5EwjBbop0E2Bbgp0U6CbAt0U6KZAN2cao7Oo0ECFBl48T4UG
fjyfOjvaX/RzRD9n6vfWG6fup49I/i8iyVPZk/+DSPJc9qlfiT/Hq+d59TyvnufV89SYQ4051JhD
jTnUmEONOdRooEYDNRqo0UCNBmo0UKOBGg3UaKBGAzUaqNFAjQZqNFCjgRoN1GigRgM1GqjRQI0G
ajRQo4EaDdRooEYDNRqo0UCNBmo0UGMONeZQYw415lBjDjXmUGMONeZQoyGqkgsTIs6I+McivlLE
u4nwGhFeFe1Do+X0WU6bLtp0JU8oT57X7dufin+5+JeLf7n4l4u/S/xd4u8Sf5f4u8TfZRxdxtFl
HF3G0WUcXcbRZRxdxtGlVhrDff/U7yaiI1Of0OPORaM+d6Ee93VcBOc24r43e91cPePa8ELtd0O+
9j8xF9fgWszDfHwPTbgO38cPoDfW6o21emOt3lirN9bqjbV6Y63eWKs31uqNtfpirb5Yqy/W6ou1
+mKtvlirL9bqizvNQA1q9byks+fLY4/VeE6N59R4jm7Jffphvl2tdnNqN6d2c2o3p3Zzxh4be2zs
sbHHxh4be2zssbHHxh4be2zssbHHxh4be2zssbHHxh4be2zssbHHxh4be2zssbHHxh4be2zssbHH
xh4be2zssbHHxp70rHPDOmq/SOGn3uxZSUS90bEiavb9Jt9PcuN1brzOjdft22vfavvWqpQakR6l
UmpEe9TUb0DPceh1Dr0uymZRNouyWZTNomwWZbMom0XZLMpmUTaLslmUzaJsFmWzKJtF2SzKZlE2
i7JZlM2ibBZlsyibRdksymZRNouyWZTNomwWZbMom0XZLMrm6ASRNPFmJW9Wphqj/fizUgRfVgHb
VUBRJNeJZK+pX2b2Sn6ZEcntya9ZvFvJu5W8W8m7lbxbKaomUTWJqklUTaJqElWTqJpE1SSqJlE1
iapJVE2iahJVk6iaRNUkqiZRNYmqSVRNomoSVZOomkTVJKomUTWJqklUTaJqElWTqJpE1SSqJnV8
brmO3yOKl6f+ndNso/6pUT8S1Yq3TbxtYm0T1x5i2sM3t4qnTTxt4mkTT5t42qLK1BV8vTJsT10V
Xk1dJy9uDiOpW5Nf2m3dkbouFKMK/9weHW6PYupqGfFtXBc6Uz+IqlPXO/qmMJi6LXnGeXgtdUd4
rdb6ttb6tnZ/vA0H4EDU4yB8xT7n4wJ8FV9DIy7E13ERLsYl+AYuxTdxGS7Ht3AFrsRVuBrfxnfC
a+V4dhhpf2puGBDL5tTPwtaUO73ovNRlsv1yXGHr1aL8Nq4N7al5mI/v4bpoj9QPwsOpBfb7UehL
/Rg/wU+xMDwmvsdqU+HF2jSmYToqUYVqzEANapFBHXbCztgFu2I37I6Z2AN7Yi/sjX2wL2aFERqO
0HCEhiM0HKHhCA1HaDhSe3Jorz0F78P7cSpOw+k4A2fiLHwAH8RsfAhn4xx8RRzn4wJ8FV9DIy7E
13ERLsYl+AYuxTdxGS7Ht3AFrsRVuBrfxnfCY9E0mbOBimuouDF1WxiTS9eFcXkyGf0LF0pcKHFg
BweSDNtoximacYr2KFK5ROWSGaZohimaYYpmmKIZpmiGKVK/RP0S9UvUL1G/RP0S9UvUL1G/RP0S
9UvUL1G/RP0S9UvUL1G/RP0S9UvUL1G/RP0S9UvUL1G/RP0d1N9B/R3U30H9HdTfQf0d1N9hliua
5YpmuaJZrmiWK5rlima5olmuSN0SdUvULVG3RN0SdUvULVG3RN0SdUvULVG3RN0SdUvULVG3RN0S
dUvULVG3RN0SdUvULam5K2V3UotzaXqN7L4u2ona/dTeRO2t0aU0bqFxi0wftOdKWvfTuj/1HZ/n
hiFHjcv8gswvyPyCzC/w4Q0+tPChhQ9jqVvCChWwVgWsVQFrVcBatfSi3vAcjzp51MmjFh618KiF
Ry08auFRC49aeNTCoxYetfCohUctPGrhUQuPWnjUwqMWHrXwqIVHLTxq4VELj1p41MKjFh618KiF
Ry08auFRC49aeNTPo34e9fOon0f9POrnUT+P+lVIQYUUVEhBhRRUSEGFFFRIQYUUVEhBhRRUSEGF
FFRIQYUUVEhBhRR43MLjFh638LiFxy08buFxC49beNzJ404ed/K4k8edPO7kcSePO3ncyeNOHnfy
uJPHnTzu5HEnjzt53MnjTh538riTx5087uRxZ9TIwRwHcxzcxu+nubiVcz2c28K5Ec6NcG6EcyP8
z/D/Ee4VuFdI3WjbzZxeEBZzcJCDgxwc5OAgB4c5OCZPnuBiLxd7uVjgYoGLBS4WuFjgYoGLOS7m
uJjjYo6LOS7muJjjYo6LOS7muJjjYo6LOS7muJjjYo6LOS7muJjjYo6LOS7muJjjYo6LOS6NcGmE
SyNcGuHSCJdGuDTCpREujXBphEsjXBrh0giXRrg0wqURLhW4VOBSgUsFLhW4VOBSgUsFLvVyqZdL
vVzq5VIvl3q51MulXi71cqmXS71c6uVSL5d6udTLpV4u9XKpl0u9XOrlUi+XernUG72bS0UuFcvV
+N9dmODCGBfGOFDkQHLfNEbdMeqOUXeMumPUHaNukbpF6hapW6RukbpF6hapW6RukbpF6hapW6Ru
kbpF6hapW6RukbpF6hapW6RukbpF6hapW6RukTpj1Bmjzhh1xqgzRp0x6oxRZyw6Qmd4XWd4XfUX
zOc1qRtFcZMoyqP3/jYsNN/fYd6eZVW3H/bH23AADkQ9DsJX7HM+LsBX8TVYQdJ6ktaTtJ6k9SSt
J2k9SetJWk/SepLWk7SepPUkrSdpPUnrSVpP0noy+hqtB2k9aMQFIy6ogrwqyKuCvCrIl/X/ewXQ
/X/KfCv4VPLLxv8+2wf5MciPQX4M8mOQH4P8GOTHID8G+THIj0F+DPJjkB+D/BjkxyA/BvkxyI9B
fgzyY5Afg/wY5McgPwYpWKBggYIFChYoWKBggYIFChZUQ1415FVDXjXkVUNeNeRVQ1415FVDXjXk
VUNeNeRVQ1415FVDXjXk/y+qIc+hPIfyHMpzKM+hPIfyHMpzKM+hPIfyHMpzKM+hPIfyHMpzKM+h
PIfyHMpzKM+hPIfy5Tl+tPxvIU/kVYFXBd2moNvkaF+gfaJxgcYFGhdoXKBxgcYFGhdoXKBxgcYF
GhdoXKBxgcYFGhdoXKBxgcYFGhdoXKBxgcYFGhdoXKBxEmNBjAUxFsRYEGNBjAUxFsRYEGNBjAUx
FsRYEGNBjAUxFsRYqE1y4Qpciasg38RYEGMh2kUvjv+xZmTajeVKL+qpxf9TjVi7X2mN6s5UtWVU
W6Vq26jS9lBpNdGcNzvKFWbjubjGffl1rnVDGJXZo/Yuqc1Rs/OEo46icJHCE29ZNY3K7lHZPSq7
R2X3qOwe/f/UbUZl36jsG5V9o7JvVPaNyr5R2Tf6/3RVlNytlCi14s37lokoPbWtxKXXok/TtpW2
rfwb5t8wbZM7mx5OTKfvAH0Hyv1vgc8/c49wq5XSQtvuCAN0HaDrAF0H6DpA1wG6DtC1la6tdG2l
aytdW+naStdWurbStZWurXRtpWsrXVvp2krXVrq20rWVrq10baVrK11b6dpK11a6ttK1VU4Ny6lh
OTUsp4bl1LCcGpZTw3JqmO4DdB+g+wDdB+g+QPcBug/QfYDuA3QfoPsA3QfoPkD3AboP0H2A7gN0
H6D7AN0H6D5A9wG6D9B9oDaJ8wpciatwNb6N74SBssbbpyqhFO2eWhrtmXrKivNpeflMmJdaEe5P
bbPOiMOC1PbQntY500e6ez06PJw+PuTe/Gvlz0S7pD9b/j/8JX9TOJjJhpc4tsh5l+BpFfBM6Egt
l+nPYoVrrvT6QsimXnKn2+FqnV67MBjNSA2p1Ngat2glNIkdYSwdhb50Faqxj7v/o0N/+piwLX0s
jsMJoZg+JWzKNIRC5vzQlvk69IjMN7xeGrKZb0JPyHzX61yv18AaOtMEM2bmZqjKzALf/9Q2vS9z
u88L8UvnWBS2Zx5w/ofx+7At8wc8Yluzz495FVOm3bZVWI21Pncj6/169NlvOPRltmEy9NXNDCN1
e2BPuDusc3dYd4jtF4a2Omv6OuOquz5M1N0cttXdijtwTxiJPjylag+fSlRdS9Vhqg5T9XWqbqZq
N1XXUnUbVddSdS01i9Qcp+Y4JccpOU7JcSpup2JMxZiKMQWHKdhDwbUUXEvBHgqupWA3Bbsp2EPB
7n9SsIeCwxQcpuAwBbsp2EPBHgoOU3CYgmupN0y9YerF1IspN0yxmGIxxWJKxZSKKTVMqXFKjVNq
nFLjlBqn1Dilxik1TqlxSq2dUqqHUsOUiikVUyqm1Hh0UOrB8N3U0vB7SrXIwdco9FuqbEltCF+V
Z1ekhsJdsvszqQkr7e3hVHn2XDodlqcrwy3pTLhEtnemZ4b69AHRBelDw7dk/kHpo8KZVLtH9s+W
c79InxquSZ8RPj/111m96c+Gu9PnhgvTjeGJ5O+XRPUXPekps8QzWBFeccVX+bHBFXOuMOSso864
yRm3qqVT1NL73RE+yLGnwipHJfXyYrlGBqO3OXq1I5935GZjyxlbrTN0lOvh+NDhyKfC84561VGP
OmJ3R2x0vd5y/bqrLtfwAer0SJ+PDhsc1WeUy6P9Zda28pHLZdazWCljXnD0S7Kqwyqy02tX2Cw7
NsuOzTJjs8zYKDM2yoqNsmKbrNgmK7bJiJKMKMmIkozYKBNKMqEkEzZzbjPntnEt6fyD0U7GU2nk
i1zvQdf9s1gfw8qwg67r6ZnLXB2Kzj/u/OPOP565w+dfhaLzjEfTHDVh5Jc5YlOS91bCD+olS8Xy
TGi3NZtapY8kGm4Iebqtct61zrs2OtdVF9h7nprqL2fLn8NcV5/ryDFK7KDEDmfop0SgxMRUXU1Q
YiLVHZY4Y7NMak8VZE8NZobz03tyYy/sjYPD5elDcGjYkn4Hnw/Hkdyje/o0359R/tvlY4zmGLXX
T90J6k6ovX4KT1A4UDiovX4qzKV0oMQCSiygxAL110/tHdTeQe0d1A7qr1/99VN9B9V3UGsu5Sco
NjezWCdagsfD5ZnlXl9EG17COvTgFd/1et3oHJvC5XVReK5uelhSV4kq1Pt8GC7UoeaHBWqwn5s7
6m4Lm+pux0L8HHeGJVGtjByXjZs4fZzu84bu84bu8wbXT1Lpb6j0N1T6G6r6jWg/fiReFmk/SvtR
R1XqUWN61JgeNSb2CbFPiH1C3KPiHhX3qFhHxTqqv4zpL2N6y5jeMqa3jMnvMb1lzFgnjHNUrxjT
K8b0irGKGlecLwNu4/4y7v+E+z9JPcHRFjwVVqSWmxWfxYpwjyx4LbXa9g651R2uSK0Lf031IIv1
eAUbwvWpXq+b0O+cm73mMIDBaL5saU7lvd+Cgswb9jqCreHy1CjGvB/HttCoN7Xr3N06d7cK/owe
9VLqNd+9jjfCE6m/eQ1m4QqkkPSvabJtuveV+lRNmJeu9T4TLi73s5297oJdsRtmhlNk69my9WzZ
era59QfpfcNV6Vm+2w8HRJ9L13s9CAfreYfg0PBv6cN8fjve4fPhOML7d+HIcJYe+UWdZTHX5nNt
Ptfmy/aP6Zc3p0+0z0l4T/he+r1eT8Yp4dr0+7y+H6eGf1cVZ6dP9/6McJnK+MzUX8wuViFXpc+L
9k5/AY3hZf31d5nG0J65EJeG11TJayrkJyrkNVkyX5bMlyXzM/N9/z38F27AD3FTtGfmZtyCBfa/
1bbbcLvPC3GH8/zC5195vStcnPk17sGi8IPMveEqs9m1mQd9fgi/w+IwW1XNNsNdKwPny8D51gc/
MMtdm/lj+F5mKR6132O2PW6/v3r/BFpsX+7zCttXOm+rbS/gRdva8BLanWsVVmON/dfatxvrfNcD
3Vt2z1e1szMbwl9V7myz6LWq92zVOzvTb5sczMjBzKuQh5lBDIVlGXmYkYeZAuRgZitGMaYDjKPo
fSk8kdmOHd6/ATmXkXO6wrw6eVcn7+rS4Ym6aV6nhyt0iSt0iSvqqn2eoXvUQA7WZcKyujrs5P3O
2MX2XbEbdrd9Zug203eb6bvr9nK+ve2zD/bFLOyH/e17gO8PRL3rH2SbDqsbzau7NrSr8Pl110d7
1vG6jtd1vK67ETfhZt/9NFyl8ufrVLN1qtk61WxdYL5uNbvuF85zp3Hf5Zz3OP8in+/Fb3FfuDyq
1yUu0yX+UJ6Zny7P58/qBAMqfoHK/neVvVTVPqxqnzfnxir2SRXbrypXqcZWVfiEKlyj6j6osr6g
kh5WMTermGdVzIAquVWVrFEFLbL/Xtn/cdm/TPYn/6XCiTL+5ehL+tUDRvI7M9bq1MNmqaV6wp9t
ewxPm+ee8d3y0KV7dpm5lulZw2aupebAYaMdMnstNXst1b8WGfmz+tSQkb+kFy036m79ZpN+s8nI
B/TrDiPfqmd36Nkd+slyo1+sFyzWCxYb5WtG+clkzWP2Wp35ok57flhqBltqBlttBluqNofV5rAZ
bLX6fEB9DqvPB9TnA+rzATPY6sx1jvs+bsRNoUtX79LVu9TmsNlstdlstQ7fpcN3qc0HzGZL1eYD
ammxvF8szxfL6SHzSYf5pEPeDplTOuTqkDxdLi8XyctF8nKRXBySa5vk2ia5tkluDcmtIXm1SV5t
klfLzUUdcmq5GW6pnHrADLfazNElPxbJjyH5sckK8gl50IKnrNBWhD9TerPZYZVcOFM3X6+br5cP
L1C1j6rtVG2XE3/SuTdQdqVOvZ6yKym7Um5skRuv6sZrdOM1uvEaOfIuOTKpy/bosj1yZZ08yems
bTprm87aJmc6ddN1umi3zrlGR1ylI66i+maqb6b2Zh1wlQ64SgdcpQOu0gFXUXazrrdK11ul063S
0bp1sR5drEcX69bF2nSxNh2sWwdbp4Ot063W6VY9ulOP7tSjO/XoTm26U5vu1KY7rdOVenSlnqmu
1KYb9ehG3brRGu6s1FnW6yzrubSSQyt1lw26ywYdZINusV63WK8zrNcZ1usM6znVzql2TrXrCht0
gPWcaudUu8pfz6mVKn+Vil+l4lep+FUqfpWKX6Xi21R7m2rvUe09qr1Htbep9h7Vvp6L7ap8vSpf
r8rXq/L17okHrY6TdfXx4fXoBFWW3Gd9XUUtVFELVdTTfJ6narbz9bd8beZrs2rJ87Wfr0t4uoSn
S1RESRWUeDGPF/NUQIkf82R8SZYvlOULZflCXsyT5SVZXpLlC2X5Qtm8nV5L6LRENm+n1RJa9dOq
X1Zvp1e/TN5On2b6NNOnmT79snm7bN5Oo2YaNdNniewtyd6FMne7mJvF+Ey4WcZOiuAJn7YZexwe
lJsbon1Fts2nnMiGRDYkslFRtekDeZG1iazN6LYZXZvRtRndNqNrM6ptRrTNiIaMaMiIhoxmm9Fs
M5ohoxkymjajSO5lh6IDXCl2pXWulHOlnCsN0jC5R213tQlXa3e1dleLXa3d1dpdLXa1dlqM02Lc
VWNajLty7Mo5V865co4W464eu3rs6jlXz7l6u6sn94c59wgb9Mtt4WVRv+zKE664Xi97TMddq+Mm
9wd/KnfcSntNTN1D5af+G6aj0+dGx5aV6/PNet/0lT8l93avlXWcPnXUuE8F5+9y/jGr4W5r2gKF
d4izhhIRpluTVqIK9T4fhjvDqHNsKDuzyt5Zs0gyxonoMOd41jd/pt+4c/3FHq/+/f6+PN9E+ksV
qlET/iKqT4jmy3Qcp+MGOm6gY3J/vYF+48bwF2N41hieNYZnafmP992zsN9b7r/r7X+IWjzM6532
v8u25J67Qswj0V7GN2ZMY8a0xZi2TP2Cs9Xoh4xrq3FtNY6txrHVGLa69phrj7n2mOtucd0trrvF
9ba43hbX2uo6Y66xJTrE2R8X/XMiX/mWLttB58WuVCx31ZryX4p8f8rLdaJvTP6i5+/dR8QrXfVx
V33cVR//X3aepNPU2y/pMod5TTrGnfb9544xozyLbrMO2O7eupKvnw6XTv11x8uu/LnyX4wea9wb
7PknrrW5L+gy/iep9PBbOkgyM3RT6k5eJ/Puq9S6k1p3iudJZ73R2ZZwsc3arYuCd1LwTk62UfFO
FdGtIro52ia+J1VFtxg3iHGDGDdwtc0arMsarMt6q+ufOkc3l9u43PZm56h3jkPCnWJ/UtwbuNxW
7h6zqJ6lerb8a0Ssi2wPzxj1MOWzRjxsxMlvOMPUzlI7a5TDRjhM5SyVs1TOUjlL5SyVsxTOutIw
hbPUzVI3S90sdbOqKtZ1d5j9ZI8Mi8OTUcosuMNKaXuUthpZ4dOYTwNRvU8j7mFK1icj1icjZspJ
M+WkmXJy6jfCvDXLqHV8yYyXN9PlzXSTZrpJ6/WS2S5vjV6yrhixJi+Z3SbNbpNmt0nr7pJ1d8nM
Nmlmm7TuGDGz5a09Rsw0k2aaSbPLZDTDXL7dSH5p7h4xZyfruldddYSD93DwnnJXmWG2n0jP1EmO
DAURDNmrkD4h2lmHcc8THeM63dE059nsPMlvrqUkAhFnyr8g5JP9KTFTPZ0QSrYnv8raw3Gboj18
SqKfEP2E6CfKkZ9nrfCF0PmWyCdEPlGOut3rKqxGFushOpFNiGxCZBPRga72En1j+q6l79q33pm7
dsFVcrSNXSHnCrk378YfKf/il6NtTNu1tI3/4Q59rc/d5V8By3fqtF3r6jnarn3r3XpUIfI4OiRd
593McJfV0ojV0ojV0ogxPWpMj1IrtmIasmJKfl0bptMWK6MRDrzOgYc48JD7yN3cRyZ/HZmseoas
eoaM61GrmyGrmyGrmyGrmyGrmSGrmSHjedRKZsgqZsSYHrWiGLKiGLKiGLKaGIqqjOYPrrzNFUuu
uM3VtrvaC672QnSwbzfSbcAY1xnjOnsWp37D/h8OnWBld4q8PoMOi8IADXfQcMebLj1iW7PPj3l9
3Eprhde3urbW52783b1X7NNn/01h3T+4uCfV+qjWR7U+SvVRqs+4e6d+k+qjSB9F+qjRR40+avRR
o48afdToo0QfJfqo0EeFPir0UaEv2lecr4jxFTG+IsatYuwQ4xoxrhHjGivVJOvWiGeNVWXeqjIv
llesLJMMXCOWNWJZYyWZF8cacawRxytieEUMa8SwRgxryv8V5cHp/4gOjhZGXwl3ROfjAlwe7o6+
E34cfRf/ibm4Bv1hYbQZOYzbZ3v4UbQDr+F1vBF+VPGO0F5xOI7AO/EuHImjcDTejWNwLI7D8TgB
J+IkvAfvxck4Be/D+3EqTsPpOANn4ix8AB/EbHwIZ/834s4EPIoqXcOn6lRXVVdXhz2sArKDo4Iy
OOISx2Hc2ERFERBwQBFMEBQQCAF3FJB9B1kEIYICEhVZXRh3ZW2gaQiyEzqhosie2Oe+1cS5OuLo
zJ3nucnzWtvZ6tSp//++PNINt8Md0BJaQWtoA22hl6iofaDe1z5UK7WPYAP8HT6GT9U67TP4HL6A
L9U6Y44ab8yFefA1xxthE3CvRgKUGhcoraYHyqppAVR2AJUdQGUHKkIlqAz71PhAAWWOw7dqvNkQ
mkG6mm5mQB94DAaoueZAYN7NsWqzuVmtM3E8Vj21zqoPDdRKqyFcBVdzfD10VNOsTtBFjbOmwgLY
x/F+OAA8M+uYmmvFoZBrJzk+rcbZutpsSzAgACagFG2Uoh0EB0LgQhhSoBSUhjJQFsrBtWqd3Ry6
sv8w26fYLmKbrVbap9TmIG0Fy6GPHxBl1UZRDoh+ogKkQkWoDw2gITSCy6AltILW0Abawp3QDu6C
u+FeuB96qFms3Fms3Fms3GGiv3pFDICB8CQMgiEqm9WczWrOZjVns5qzjZFqozEKRsPLMAbGwjgY
DxNgIkyCyTAF5lBvLsxT2Tz1WYGdamNgD+TCN7CP80fYHoUCrh+Hbzn3g9pommBBEByoBJWhLtQD
5sFkHlgd2WZTts3YXsf2VngAukBX6AbpahYrZxYrZxYrZxYrZxgrZ5jJ/ZrcLyso237MnxsxXm0W
E2AiTILJMAUWwiLIhtdhMXwBX8JX8DVshE2wGbbAVtgGEdgOUTioVhATVhATVhATPhffw0k4Bafh
DJxTy4gTy4gTy4gTy4gTy4w8tdk4BnHIhwLAnRgeFMK38B2cAByLcRL8eglQahnv2wqLWGDx7lu8
6xbvusV7brVRn1v3sG0PHSnTCbqoZdajHPeHAfAkDIKh8AKMAN43izmymCOLObKYI96nZdarbBew
XcZ2DTAPFvNgMQ8W88C7toJ3bQXv2gretRW8a5/zrn1u5UMBFFL3JOeZD967ZdoVwhBlRABM/+tx
/O+sgCD4n94dAjf5/dNlRAo0F6niOuihMlnjmazxTNb4ANZ4b9Z4b9Z4b9Z4b9Z4bzGYFoaoDNZ5
Bus8g3WewTrPEM+KUuI5eB5egBHwIrwEI2EUjIZVorpYDQfVEJ7oEJ7oEJ7oJJ5oNk80myeazRPN
5olmC/8TpM+pLJ5qFk81i6eaxVPN0mao7dpMmAWzYQ7MhXnwKsyHBfAaLIRFkA2vw2JYAm/Am7AU
lsFyeAtWQA68rbbrjUUpvYlI1ZuyTYPbVKZ+u3pCbwntOO6lntZ7q3T9UUhX6Wi2lrKT6o9uaym7
su2vvpAD1Ba5WQTkFlFebkP1bseV7xCOPKiy5SG0yGHRQB5he9T/bCC2+aKs0V+UMQbAQHgSBsFg
GAKZMBSyYBgMhzkqg3iRQbzIMLaKUsY2iMB22AE7IQq7IAa7YQ/kAvPJas9itWcRazIDZdR2Vv0Q
YkxGIF84xJdM4ksm8SUjUCTKmBJYW2ZZKAe1oaHKMBuxbQJXi1RiSoZ5DfvpKpP4kUn8yCR+ZBI/
BhA/BhA/ehM/epusJXMIsJbM6Wq7OSP5L+i3W5dAdagBNaEJtFHZvGlDeNOG8KZlWf1EKetxeAqe
hvEwlfNz2M4T1Xmbsqwl7O+j/H44AKw53pxJvDmTeHOyeXOyreMiaHlQSPmTXGf98QZlWWdEKbu8
2m5XgFSoCJWgMlSBqlANGKvNWG3GajNW+1KoBbWhDtSF7rTVAx6CLI6HwXC1Paip7U4H9YTTEbJU
ujMceG8c3huH98bhvXF4bxzeG+dlGANjYRxwv84EmAiTYDJMgakwDabDDJgJs+AVmA3MjzMX5sGr
MB8WiFKhTBgKWTAMhgNzG2JuQ88A73eI9zvE+x3i/Q4xzhDjDDHOEOMMMc4Q4wwxzhDjDDHOEOMM
McYQYwwxxhBjDDHGEGMMMcYQY3QvE6VSguBAiPigy028KQeJRv6e/9kjFfUniWZu8tsFTLDAhiA4
/hclJb8uyf8Ee9f/3hEUQAwFEEMBxFAAMRRADAUQQwHEUAAxFEAMBRBDAcSIfOWIfOVQAnGUQBwl
EEcJxFECcZRAHCUQRwnEUQJxlEAcJRAnSvYkSvYkSvYUjyhP9ILe8CikQwb0gcegL/SDx+EJ1YuI
2peI2peI2peI2peI2pdo2oJo2oJo2oJo2oJo2oJo6hBNHaKpQzR1iKYO0dQhmjpEU4do6hBNHfLu
HvLuHvLuHvLuHvLuHvLuHvLuHuH/vSMbXofFsEpUJvJWJv965F+P/OuRfz3yr0f+9ci/HvnXI/96
5F+P/OuRfz3yr0e07ke07ke07ieO4mXz4BjEIR8K4Dh4UAjfwndwQk0lsi8ksi8ksi8ksi8ksi8k
qg8mqg8mqg8mqg8mqg9G00fR9FE0fRRNH0XTR9H0UTR9FE0fRdNH0fRRNH0UTR9F00fR9FE0fRRN
H0XTR9H0UTR9FE0fRdNH0fRRNH0UTR9F00fR9FE0fRRNH0XTR9H0UTR9FE0fRdNH0fRRNH0UTR9F
00fR9FE0fRRNH9XuFKlaO7gL7oZ7YIaKkIkiZKIImShCJoqQiSJkogiZKEImipCJImSiCJkoQiaK
kIkiZKIImShCJoqQiSJkogiZKEImipCJImSiCJkoQiaKkIkieIkcvMRavMRavMRavMRavMRavEQO
XiIHL5GDl8jBS+RoXwlH+xo2wibhkMVcsphLFnP15v6/UWX7F7a3qeFkszZkszbJbNZJFeg9oBfZ
7SdZTc9QBWS2G8hsvclsN5DZeuPFx8on1JtyjfpIrhcp8kOy3yb8/BZ8+jZRkSwXJ8tJuRN/fyHT
Bch0dZKfMRnnfD6Zp79wyXIuWc4ly7lkOZcs55LlXLKcS5ZzyXIuWc4ly7ko6ThKOo6SjqOk4yjp
OEo6jpKOo6TjKOk4SjqOko6jpOMo6bgxVXnGNJgOM2AmzIJXYDbMUS3InC3InC3wXTn4rhx8Vw5Z
1CGLOmRRhyzqkEUdsqhDFnXIog5Z1CGLOmRRhyzqoDM9dKaHzvTQmR4600NneuhMD53poTM9dKaH
zvTQmR460zNOqQLjNJyBs3AOzkMRFAPvBJl5MJl5MJm5J5k5Qmbuh/+L4v+i+L8o/i+K/4vi/6K4
hBguIYZLiOMSYmTwFoFDysMpxHAKMTJ5TzJ5zwBjCjAmMnoLMrqLa4gFEhwr5ZkCNNBBCpdM7+Io
YjiKGI4ihqOIkfldMr+Ls4jhLGJmNcpeArU5V5fjekCsxWXEUAYtUAau2ZjrrEHUQTlcRwyF0AKF
4OI8YjiPGM4jhvOI4TxiOI8YyqEnyqEnyqEnyqGnSRw1iaMmcdR8AvrDANULNdELNdEXNdEXFdEC
PxtFSURQEhFzdvITmVLN5fB28lOZUs2P2W5WOaiMiMmzxPdGzTMiFcURQXFEUBwRFEcEL5yDF87B
C6/FC69FgUTww2vxwznWdcLBE+fgCzx8gYcv8PAFHr5gDyplIb7Awxd4qJV+qJV+VmdVYD0AXdRg
/IFnpbPPO2X1gcegL/SjzceB+8I77ME7eHgHD+/goXAcFI6Dh/DwEJ41kvKjkp8q6KF6HPyEh5/w
8BMefsJDBQ1GBTmooMr4Cg8lNBgl5OAtPLyFh7fw8BYe3sLDW3gopH4opH4opH4opH7WIdo+DEeA
WG8R61FNU1FNU1FNC1FNC1FLg1FL/VBLC1FLg1FLDl4/iteP4vWjeP0oXj+K14/i9aN4/SheP4rX
j+L1o3j9KF4/iteP4vWjeP0oXj+K14+iuiKorgiqK4LqiqC6IqiuCKorguqKoLoiqK4IqiuC6oqg
uiKorgiqK4LqiqC6IqiuiH0VY7oarlU5dnPoStvdOe4BD8HDnOvJ9hHoBb3hMRVHoUVQaBEUWsR+
ijpjOb+Istlqrf06+4vhlIoGhUhFwUWC3FuwnMoJVhCOc7c66NwD90IH1QZl18bpzP4gVeAMhkz4
Uek9zf7zMEK4KD4Xxeei+FwUn4vic1F8LorPRfG5KD4Xxeei+FwUn4vic1F8LorPRfG5KD4Xxeei
+FwUn4vic1F8LorPRfG5KD4Xxeei+FwUn4vic/8fFZ/7M8VXQYxR12tdRGutm7hbe1AM0v4m/qp1
F9drPcR9+m2ig95L3Cvbq5tlB/VnuVotlOtVa3lAfY42LC+JcPKIGi/z1KfymKgq4/itfHVa1BBj
EhvEErVV/F1tpfUbSz4NthmtX0brl9H6TVovdZrcephecHO4svaqOb3cQC8D5Fq1Rq6D9YkC+YF6
hxy3U36kPpYb1Bh6f46ez8rD6ii9N6f3sfQu6X02vW8QttyoFsjNjAknL7eq7nKbWiUj1NqhdpMV
c9GpS9QnjO0TSt5P7txI6amUzpRbEwlKz6P07eTRd6jxJDVmJD/b8UpGm0U2v4TsfbvemkzeS/XS
+wipL0Ynb1B/0z9V0/S94o/6KTJyeVFKXqlek2uFS5a+kjt4i54+xY9KuRWvuV29TZYO0HqCO4qQ
qTNLMrUs8aSSOzsqj3FXcc7nq+PafcJQq0QATLDAhiA4EAIXwpACpdQaURqaq93iOnhWLRfPwfPw
AoyAF+ElGAmjYDSMYQ5XqS1itdqi6Wq3JsGAAJhggQ1BcCAEYSgNZaAslIPyUAFSoSJUgspQHWpA
TbgUakFtqAN1oR7UhztVrtYO7oK74R7IgmEwHJ6Cp+EZeBaeg+fhBRgBL8I4tUsbDxNgIkyCyTAF
pqpdemO1XG8KadBOvae/pGL6SBVjlbfnqRSwzopZY8t5EgWssbassWJ5OpEnz/BGnFWWPJc4I88n
dssiZcrixFH5g0qTCc4rVdkIJPIMU91sWMoy7MQZI5jYbTjKNEKJo4ar0oww51Mo11+tMgbAQHgS
BsFgGAKZMBSyYBgMh1fVbmM+LIDXYCEsgmx4HRbDEngD3oSlsAyWw1uwAnLgbXgH3lO5xipYDWtg
LayD9fA+fAAfwkewAf4OW9VyYxtEYDvsgJ0QhV0Qg92wB3LV8kCRWmVKYP2aAbXGLMu2HNSGRtAE
rla7zWvYjla55hSYxjH3ab7GPvdjcj8m92NyP+Yyzi2HFZADK2EV51fDGlgLjN1k7OYX7H8JX7H/
NWyETbADdqpdZoxrRyEfvoMT8D2chFNwRuVaKVAKSkMZqKR2WZWhClSFatBU7baugX5qufU4PAVP
w3iYA/PUFmsJ2zNquV1f5dqXqd32FWwbs20Dbdm/X+2yu3O9BzwEL3F+GuenwwyYCUugSO0KCpUb
LMOW9yvIexWsAtXUbqe7ijm9IR36QF/oD7zvDu+7w/vu8L47vO8O77vzMoyBsTAOGK8zASbCJJgM
U2AqTIPpMANmwix4BWYD9+jMhXnwKsyHBWp56A4VC7WEVtAa2kBbuBPaQaZ6LzQUsmAYDIen4Gl4
Bp6F5+B5eAFGwIvwEoyEUTAaXoYxMBbGwQSYCJNgMkyBqTANpqv33MvU8pSgei/FgZB6TxjkiuVE
/rjcLq4gLheLyWKImikyYShkwTA4p2L45xj+OYZ/juGfY/hnD//s4Z89/LOHf/bwzx7+2cM/e/hn
D//s4Z89/LOHf/bwzx7+2cM/e/hnD//s4Z89/LOHf/bwzx7+2cM/e/hnD//s4Z89/LOHf/bwzx7+
2cM/e/hnD//s4Z89/LOHf/bwzx7+2cM/e/6ncGmfMM5PVQGetQDPWoBnLcCzFuBDp+FDp+E7t+E7
t+E7t+kLVF7y/4+88H8d7dfPqP1ksyhZbKbcJGqQL/eRwUbj4Wbi4Wbi4Wbi4QrwcAV4ON8/xfBP
MfxTDM/k4Zk8PJOHZ/LwTB6eycMjzcQHzcSnzMSTzMRDzMRDeHiEAryBhw8owAcUWI1UzLos+Xmc
BWh/X8vH0NkxtHUMLRxDA8fQvx7610P/euhfD/3roX899K+H/vXQvx7610P/euhfD/3roX899K+H
/vXQvx7610OvFqBXC9CrHhq1wB5A20+xv8j/1DTloTc99GZBsDzvUwc1DY05DU25DU25zc1See4w
GK7ywuXV/nAFSIUaUBOe5vx8tV/oZJU3yOvoOLlaXCvXiAfk+6Kp/EBUYn5Xyo9QUhtEfblRtGGu
2+DrAyiGG/H2ZWVEXMW8f4NyqI7OOcDZg6IReqENeqGezBO30O5HJX/LvoyePlRLKD8x2edyrvVG
VawRKZz7nKNN/udS/vKzdLVeIu3in6fLeJrwdlxPr63Ih7czhgtnmpAtz3D2ZrLlGrJlPPkZxfn+
t1FythpHNyb/pliRsnUZg/9dBEfE5ZS4gqNNIo07LM+16tyr/6lvHdTXsr9ozvg/Mm5Ar+mc+Yyj
LylNbkITFnKUy1G6CHN0nqPPRH1hiDQRABMssCEIDoTAhTCk0GN7UUF2RON1gXTuaQ068AN05odq
i9FfpBkDYCA8CYNgMAyBTBgKWTAMhos0vHwanj0Nz56GR0/Do6fhydPw32l47zT8dlry+y/CqNuT
9JTLXRyR7/Mk/W8z+VC9i7rN5977MyerGdc6SnG33HtYlNU2i9raFtGYmenCPPxFdqRUJ9FJdkl+
xlwnma4+9D+VSA5UB+QU0UxOFdfQj8eTrouSWWpcK64ymovGzFYnUZ0a1emnKU+zv6hJT8f9/pM9
hUu+1+RT2ZnaD1C+G9sH2fZnhW1Wu9DIBejjc8n1s0PY1JLC9L8JhdKplEylZJCSHiUKRao4SBRF
Q4nD6KbH6cl/pgPVNnR3AU+9FBF3S7K9CE9wO7Vo01fEgbKqGA9fjIcvxiMX45GL8cjFeORivG8x
fbZXef6/eKLFRrwpVrK17eqkqPizPjsTs7pBBvfWHyW+SX3H6Aq5D48VV4G+T1HrY/oN0e/Z3+w3
RL8H/O9mobWy9BugxVO0WECLJ2kxSGvfldxFMe9Ze876nxfYGSXfDR7nSn9RmZpBRmxS8zQ1i6kZ
ZiwJf9aoWcRbcVDcKg7BYTjHyj4PRVAMPxAd2uNcOqjGsjPR4gHRVXZj+yDbDLzP44xnoJovh7Iu
pog/sR6uZ8Y302Pz5LPZql5J9hZRO3jnyuNyzpeskasM2jYSoET9QFlxq9UROkEXUd+aCgtgH8f7
4QAwTquQcyfZnmZs/uc/FjKyc9zzOUbWiPs+x8gacd9VuG8/Ytjcr8O9HpU7RenkqltLjY+ocYga
VahxiBpVqPEnSpdmzEeSK2+rKmLcZ6l5KFkrkvxego7014mV3IVtV7YDiIoHRC0iXiExxiEyViYy
liHerU1+o47//GKUkpwp5Dm0Z69D8t3wPw0vVT7BqnqSfHeEcefR4zHlJdfbPuodop5D6zYt61yJ
icqih/pOPAQPwxM8/fY8z46MqwsMYGX6pQ+ySo4w00cZ0zH8ZZxW8smTN4iKgdLqu0ABHFffmemQ
AX3gMRgAA2k3peQ7gaK0HKPlmHyCuxpAzD/AczzIKjrEG5S8W+JwHnN0TH2V9OIVGV8R4ytifEUl
d+//TXkvreylFZ1WGjHG0rRyhlYStOJ/0rxNC/v97yNifEWMr4jxFTG+IsZXxPiKGF+RuFz0EK3E
Q/AwDBEtRCYMhSwYJlrQYyl6/AMxK8AMtyNmBZjldsSsRcz0CmZ6Hev0U9bp7azTVnKxGs89fUmG
qHdhNOQtfzR5qIlrRXPWaHPjBhU15ogWxlyYJ1oESotWgX1sC9geh29FC7MhNIN00crMgD7wGPjj
sxnV6ZJ1o5esGz35rPwZPKaOJv8asZRxLywplVpSKpVxe5S8KvkXiGNqGysjPbEBL3gc77cPr3cc
b7fPaJA4zFpLT3icLeRModFA3Uir6Ym98jTzXETtYmLDD2qjEVBn8IVnjZA6ScmNlLwlWfdDrm7h
zBbOOMm6njxPf0XMyg9qOx4zYQSFSd0EpbbjJROUTCMupSeO0EsCl3qSkRXIc2yL6LWYlXmhZjG9
JnCnJxlxgWGzdRhFiPMXWirmDk6x6tLxtWeERiuFtJKgFUULecm+TaFRu5DaCWorauaVjKGhP0+J
cYzhALVrU3s3tU/L87yx/uiLWcc/sOIS6ASlfmAsB2itNq3tprXTRlBFkncV4jm7ojROOU7LPzCm
N/0sqnRaPMs4cmVC6NQ6S9+5Rpj9BupSv0RiEyWO0p8/UzFKHKVNf5ZitPEts/tPz4unX/KcqP0b
zydZNvlcKPsbz4N7/D8+B+Lpvzn/RJn/8rxzj78y38krF51nkWKUF0GjAuOrJByjCq1VpU41NMMl
7FfnWg2u1eJaHY7rcq0e1+qTDwwjlR6qcrUm27o8E9cozxEewqhI/1XooSo9+W1V53wNzl/K+Tqc
r8t52uEp+KX9nquWlPB78tsqy7h0rh42UjlTESqJ6oyvLCUP02Z1xqczPp1ah42aXL8UanG+DmXq
cq4e+/X9byWnlVzG6t+hblRmrFVEoKQVv3Yu4/fvUDdqc60O1y7U1rnf8lCBtZfKmCvRbhXupSpP
vxp9XeLfF9drcL0m12txvQ7n6nK9Htfrc3/cBc+mAu2mcrYiVFI7GEOC2TlgVONZXsI9V6dMDcrU
5PqlUIsytSlThzL1KFOfzOY/Jzc5r5VEecbhz9hZxlGecYQYh5uc21oc10nO4FnGUJ4xhPynImTy
3quUzPOF0fuzJ5P3faFGYcmodVHqP10TvLUe8/dP64K3/UoR/nfXBrUaC+vX1gdX64py/601Qmt/
4K7/w3VC7QaizP91rdDKtf4d/XfWC0/ii+Rz/I/WTDI3hP/ddZOM6g3k6cQxImk3Ik41olpreT5R
SFT7qyxOxIk+PYhqNYlqzY1A4hgRtRvRqBpRrbURTBQS1f5qhBJxIlMPolpNolpzo3ziNDNyOTPS
kBlpaFTiuLL6AzOSwqiaMCv1mJW6RnXO16BcTcpcCrU4rk25OpSrS7l6lKvPqgni3Fw8V5r0v9dn
gyiH2i2P0q2DqvgTWuFj1F6p5HcLrda6iOu0buIW7UExSvsb2+449/ZqlrwXL3KfWo3ymJX8prqG
/6LUx8lS/ncg7Uye/fFo+T+OdJz8eu0DtTy553+73QH2SuGSLxdCNMeTNhJ/5rexaCnuFk3EveI+
zt6PlrtePCJGizvEGLFYPCZWi/UcfcDvePGF2CEmiCi/c0Qu7mSuOEqLr2tVtapiq1Zdu1xs01pp
rcVBra12jzisddQ6i3ytq9ZVeNqDWg9RqKVrfcT32gBtmjitzeC3ijaL36rabH6raa9ri7VLtA+0
TVoNvbF+lXal3lS/RrtKb64315rpN+pp2jX6X/QW2rX6Lfot2nX6bXpL7Xq9td5au0lvp9+t/Vm/
V++gtdA76Z20W/WuelftNr2H/pB2u95T76m11HvpfbRW+uP6QO0ufZA+QrtPf0l/Weupj9WnaOn6
NH261l9foL+lDdRz9I+15/RP9R3aVD2qH9QW6cf0fC1HL9S/1d7VT+hntPf0c3qRtl5XUmgfSl1K
bYO0ZFj7WJaSZbWvZHlZXtssU2UVbYu8VNbSdsg6sq4WlfVlQy0m/yAv13LllfJK7RvZRF6l7ZNN
ZTPtgGwur9MOyxvkjdpReZO8STsmb5Y3a3HZQrbQ8mVr2VYrkPfIDlqh7Ci7aydluszQEvJx+aQu
5FA5VDflMDlMt+QUOVW35VK5VHfk2/JtPSRXypW6K1fJDXpYbpQ79UrygMzXa8nTUul/MAJGit7M
KG800G8ybjBu0Nsb/Y0R+r3GSOMdvbfxnrFen2J8bWzSXzG2Gof1uUaeofS3A07A0b8KuAFX/zpQ
OlBW3xjYFtilbwnsCezTo4GDgYN6buBI4Ii+N5AXOKZ/E8gPfKvvD5wInNCPBk4Fzuh5gXOBc3p+
oChQpBcEfjAD+nHTMlP002Zps7SeMMuaFXRlVjKrS2leal4tHfOP5h/lJeY15q2yutnWbC+vNB8w
n5HNzOfMF2Rn8yVzlOxqjjXHyr+Z480Jsrs52ZwsHzKnmrPkw+Zcc65MN+eb82WG+Zr5muxjLjFz
5GPmu+ZaOch83/xIDjc/MT+Vz5qfm9vl8+ZOMyonmDEzJieZe81v5GTzqBmXU83vzGI50xKWLhdZ
llVTLrbqWU3l361rrRvkNusm6yYZtf5i3Sp3WXdYbeReq53VTh607rHukYese6175WGro9VVHrG6
Wz1kgdXL6iU961FrkCy0hljD5A/WU9bThm69YI0wDGukNcowrbHWNMO2ZlgzjLLWLGuWUc6abc0x
ylsLrAVGqrXEWmNUtDZYnxsNrC3WDuNKa7d1wvijddI6b7S2ii1l3GPXs+sZHewGdiPjfvsK+0qj
s93Ubmp0sa+1mxtd7evtG4wH7Zvsm4zu9m32HUYPu5Xdyuhpt7HbGo/Yd9vtjd72/fb9Robd3e5p
9LEfs/sZT9hD7CHGQDvLzjKetJ+ynzEG2SPsl4xMe5Q92hhmj7XHGk/ZE+wJxtP2FHum8Yy9yM42
XrSX2EuMkfZSe6kxyj5hf2+Mtk/Zp4wx9ln7rDE2SOAzxgWNoGFMCFpBx5gYdIMVjanBysHKxvxg
1WB1Y0GwZrCmke3c7XQ0Xne6Od2Mt5weTg9jhfOI08vIcR51HjXecTKcPsa7Tl+nr/GeM9AZaKxy
hjhDjNXOUGe4scYZ4bxhvO984HxmHHa2O3sMz9nrHDZOO+dCVYxEqHZoXKBmaEJoXmBM6N3Q+sDs
0KbQicAi13IrBb50L3P/Gsh1O7iPBM66j7p9zaD7uNvfLOUOdAeZZd0h7hCzgjvUfd5MdV90x5g1
3XHuOLO+O8GdZDZwp7hzzcvcV91XzWbuAvcN8xp3mfu2eZO70l1j3uKuc9eZLd333ffNVu6H7mdm
a/crd6vZ3o24EbOzu8ONmg+4Mfcbs5u73/3WfNj93j1rDnTPu8XmUDcRFubwsB7WzWfCRtg0nw3b
4bD5Qrh0ONUcHa4UrmRODFcJVzMnhauH65hTw/XC9czZ4eHh4eac8NPh58254RfDL5uvhceHJ5pL
wpPDU8yl4enh6eby8MzwTPOt8CvheeaK8PzwInNlip6SYq5NKZtS0fw8pWrKJeamlDMp582tQnfQ
70K4N5e5UzQQNcV/6UetVgfVEdFY5bG/+6IlEmqmWsZvoRrJ0Z2qE3U+Zi+v5HqeivPf/SVHp39R
378aVyf5/d9r1kX6+R4m/eZ4M2Hdz87spYdUv5df/cF5UW6XKmLfJZN3FmGOD/58jD/ezUX6/Ert
U576mhYOcLdHf2uMv+PHptUpJa0fUgXqY3W45OjEL3rPh1z1jdqmzqo7RJC5ayQu/cn1xG91pk7x
7E7Swv+OnPlHsVy4+pp6Tbjwj2f4T7WPw2EVo429HAbQWfXEjezVSF79u9qodrB+WDv49ov3v1i9
qmazfRHS1BVqgOrP3k/m8ce7Z6/gF7UT6hN1lBX0ifqScfAc/Nn7ea1/lP3qN6ZC4FOFSEnujSk5
49H21z+uzZ+uipIzJ7nzE8z9bvU9er8Up5ryFP7Ru8pPPqH8H0v/on6BOsY75v044/5fRpPbPT8t
81vjLikX+9lRv58dffb72uCnSbJ8yUpTO3l+ttr5Gz2f+cm73UT86TdKv6Gy/TdaffK7x/Tz+kf8
1eGv2V9c2f47anNn6oXk3rv//D6rv/2O+qwR9XYybu31n9u/+6NeT0bT15nXX/7Yv6uFQrU6GTV/
57q4SAsnfv+qukjtkgirtv5HtZcn/7vTjxz/9Z+rf0f/Ry7kMlXEOvr+3+7B/ZdX68NdyV5+zHj7
L/yWXK9xkToN+a3Bb8OfjXJhyXbThd9/Ub/JReuXzC6r5BTR6dSvDZj4eVx9RwTbl3yn/FV9Nnl+
YvJydfWBWq8ifkb/lfrFP9kfJSoT/+8Tbf03pORcLrlhzS9j8T/qFP1kfxyZp5S4XXRjf2nJuYPM
3pZfz6o/9p9c0dOpHyT6PF4Syf3zK9QyIdXKX63/z6swgHrqyfmXS65/pj5l/r8oOfpl/D7/k/2R
1K4sWgtfCaWVnFunVtHCm7/a/6GLn0/wxPz4qNqpNqqHaltSes4v6j9DFHtNvak2q8hPTuviAfGs
GM3eGDHW/zcz4g1W7lKxEnW4RqwXVyX/qtBMbBA7xDVilzgsWoqjmiY6aN20buIJHP1dor/v5cVA
38WLJ/XeeoYYjB+Piix9t35QDNPz9DwxQo/r+eJF35uLkfpp/YwYrRfpRWKM783FWN+bi/F485CY
KGvIGmKa7CwfENNlN/mgmGm8a7wrfFerxOxA2UBZ8ZX5jvmO+NpcZ64XG83d5h6x2VSmElt9Tye2
+Z5ORK07rXYi1/d04hs83X1in+/pxAHf04k839OJuO/pRL7v6cQ539OJBJ5ulCZwc+M105poTdOC
vqfTSvmeTivtezqtjDXfWqCV8z2dVsH3dFo9PN0J7XLcnNLa2tIOaJ1s23a0LrZrp2gP2v9D3ZfA
R1FlX9961bV09+vsQFb2nYhhCwgBAQEVXFBxGQRCUEGRkAyikkg6oIKIqIgjoCLIoqPgIOOCivzV
cXB3EEEBkR1kExERARWo79zbnRgEZR2dr/J7t1/felt3vzrv3FpO4t1E43q3klvFGOCmuunGQLeq
W93Id2u5dYxCt517rnELorYbjFsRnY0xhiE6u88o5vjLuINjImM4x0RGSfCO4HhjJEc6xiQdp5ON
1/Vz+jljkd6kdxvvcKxhLONYw/iCYw1jNccaxjqONYz1HGsYmzjWMLZzrGHs5ljD+I5jDWMvxxrG
zxxHGAc5jjAOcRyhVIw/JqicmEoxVVQg5kDMT4qvKayQGWPIjFGYMRMRUUyixzCnH6dZ8DyFP4ee
ptlYpeZgPtkyn2zMp4U46v4PsyogsyqAWfUB/B/SZxSkz/GnMMuWg1V/QavBrtbQRhxjmzDnatBW
+g5H/B781aTvaT/VogP4q00/0iGqQ4cxI+NlRmbIjDRlRmqZkRozchDFqXzMSy3zMgHzcg1VVmvV
WkpU69QGqqI2qo2UrDZhvqbLfE2T+Zos87WSzNdUma+JylMeJZqg/5SEWatgsVElzF0Hefz4lGL6
MY+TZB6nYR73orpmb8zmepjNfZHPw5yuJ3M6A3N6DRm+tb6vSPm2+LaS7dvm20VB37e+vVTV94Nv
H8X69vsOUjXfIcz+OjL7a8jsz5DZnyGzP0NmfwZm/3mU5HRyOlHQ6ex0Jp/TBceDheOhKzzdnG7w
XORcRI5zsXMxuc4lOE5q4TjpjrqX4Wjxy9ES5DMgFHKuxjETg2PmWqrh9HJ6U6zTx+lDdZxcHEXx
chTFy1Fk4Ci6GbUGOYUo81dnCDy3OLeQcoY6t6KX25zb0PLtONKCONLuQK3hznD4S5wSlA/j2AvJ
sWfw+RSUGePci37HOvdh74POg/CMd8aj1kPOQyjzsDMRnknOJIxksjMZHhyfFODjE+1Mdaai1jRn
GvwznZloZ5YzCyXnOHPgec6Zi7rPO8/je5jnvIRv5mXnNYxzgbMA38nrzusY1b+ddzDad50P0Oan
Dmam87mDOemscFahtS+ddVTdWe9swney2dmGvrY7O6im87WzE9/kN84uqu1863yLHnc7ezDmvc5e
lPzB+QF79zn74N/v7MdIDjg/ov2fnJ/Q8s/Oz2j5oHOQEp1DziH0ftg5jLqe4/H/V3UtymA0gQWa
wAJNYIEmsEATWKAJLNAEFmgCCzQhA2hyD+wYdwwpxhTyMaaQwZhCGpgyHLYkUEpxjCxkAlmWkw6u
CK6kUPCL4B6KY5Qhk1GGUoAymyhRb9abKUl/pb+ikN6it1BlvVVvxd5tehsl6+16O6XrHfob5Hfp
XSj/rf4WZXbr3Sjzvf4e+b36B0rV+/Q+lNmvD6DMT/on7P1ZH6SgPqw9Sg5xaJ3I+AXrC/lgrZBN
CUAxl6qE/KEAVQoFQ0GU1KEQpQPXEuFJClWmVEY3qgx0S4VNC6WjTNVQNUoKVQ9VRzs1QjWRrxWq
hfK1Q7WRB/bBD+yD54nQVPQyLfQkak0PTUfLM0Oz0OZTob9TJUZDMhkNKY7RkOKAWP+MouF4/JmC
hhbQcDLyjwMHTcFBGyj4HPJz6VXY1wizDWj4FvJvAwNNegc4aAIHPwdiLge+mnL+3hUcNAUHKwkO
VhYcDAgOVhEcTBYcTBEcTBUc1EasEUsho6fRE3aQkQ9bYAyBHWoMhR1rjKUQUPIyUoKSfqDk9bCM
kkFBSb+gZIxgYpLaqXZSvOBgguBgojqkDlGsIGCc6TN9lADsc5EPmAGKN3uaPSndvFbuZGPsyxDs
q2b2MfvAnyt3tzEOZggOVjP7mddRWjkObiUTCLiXXGDfQQoI6qUK6lXms7Y4Pjs4HXD0dnQ6kikY
5zrnA+N8wLhuyDO6mYJutqBbsnOpcyk8jG6mc4VzBWwP50qUZIzzCbpVFnQLCLqlAt36knb6Of1g
r3OuQ/kbnBtgBzgDYBnpXEG6QBTphjpD4bkVSGcLxrlOkVOEusVOMcqXIV0p8hGMu9O5C3lGOleQ
zhSkCzjjnHGodb/zADyMeq6gno6i3gRnAvyMfa5gX6qgnimo53OeAOqZUdR70nkS+enOdCDaDGcG
yjMOmoKDqRVw0BQcdIGDC5CPYN9C51/I/9tZAsvY5wL7ViHPqFdJUK+yoF5AUK+KoF6yoF6KoF6q
oJ52vne+Ry3GvsqCfcmCfalR7DsIjDMF47RruAaZEbQKDAsUkT9wR+AO2JJACQUDpcCmYGBkYCQ8
owKjyC84pYITgo+SEsRJ0t8Aa+L0d3oPJQi+xAmyJAFZ9iN/QP9IscCUwzjOGVPiQ2bIpFigiUMx
giMJgiNJQJAE5BlBEkNVQlVQhrEjKZQRyoC/WhQ7aqAFxo4EwY44wY54wY4EYMcTaHNaaBpqzQzN
RPlZQI0EQQ1FquluPvPacst52dSVrvktnv//x+Zt87Zzir5bf6y4i8/zyLm+k217M5/hksj7LXn/
ZVmfYpdEo8+dHH9KLLrK2+htPfKMzvH7LTtD5xWe/AjP7OZ1Q+TJr78Zex9VYxsi7fdO/bxMeTs7
f/3O+05s1I9YcS++2Y3eLqTyM3sVItGkCrVXodRK4vMeVZCLnmEsi67/oC1QPpqK/Wr6i/i+PtbZ
BW/H0efmvD3eBu8L7DnqKsSpbmVnyY98x8dPdFZXOF+AsZvl+Z2/9St7644+q3mmtmNfwTlurVne
dHk9KGfD3+fE54e8Z5H7IFqmbGbxEfyD90mZ/6T62SxzdOMv7/ksmLemQon75XwQnytfJ7nNGE1F
hIp+vyf6+8pZ643HL3fyG2ZahXa9fd5BpJ/4XJd36Ihyv3dd6n9s+4OP+RPYvCmnUbn7MdrbSPUx
B6ueRqu/v9UnwVbGU8HUY27AhhO+hnj6a8Wv2jtiVBWPvROs/4L3hjcven0gyZvmvSHeTby6V1y9
T4k/rAQ2rhf+sFW4iaAZr0neerzOiZbaJdfbPkR6B39bjzxzLUiWQmXnZhdhLfjA+xRpCrxdvWXe
R+L/LMIi5Ir2X05+pEeNfPsR72QN9f5ZwTPQm+nle/fyWX5vSLm3DXyv8nF39FVH4muuR18L3eG9
hc+y6swdqWXzgdcxIFgZL/yAotdnK44BuFx+bYSvsRyn5f+cqTGe6oZvKSSvD/H15qP2DvUWHVE2
8roGq9smniGn0N/nPOuFb8n3xDmsb+uj3xqsd5O3WH7v/WQeYw0LUdZRbe7CcfBN9OqSCeQou+q0
P7L39Ne3X65DH3m9soylMPeSdXsz/nYdxT3XCfc8xtGOo/kMY9extl/h2bKj9h/8tSfq/+ux/XQy
19FPevP6n2SFyD0WY7xR8vqtIMCLnJB7xpsfycm+Mn4m1zvxS712CqN7wXsViPly9N0ibzbx/UGv
cB4JyAkUWwSUKGPB3wJ9P4riROT6WcxRbb7nvey9GW0zid9F/Uegg+ed/GilHo5S74vyd2WxywbO
lcWVESYuiPYBz4/IPSLR42ePIHJvr7u8e5P4al4h0u3IjfcmY627PdpKhXtb8A287hWfwmjzvBJv
hpeP3Ns4qmd4AwQf7sdqNAPf85veFO9GrK3f8jVA+WQLvLnek5Geo6tGqvf2r9rc6i1HVBk5cluU
56K80/sxkk6cMR/R9l453svvCjpylZJ1ujzyFea7Xu57qHjHReMj71j5o7Yjr+LKHUzfHH8k8omO
uv/qj9iOjGT5W8Uc/v54+Cm/zhmLdE9mq8g/cDRwlLUCr79xpbu85I7TH6/3hDfcu9ubJPlPMN+n
850y0XUowhd/8F5CeuP0+pGWsiJ3spxWG5u8LVgJZX3Eb7oF87Ccc0d+dW83OMfuYzHAk+7rFDh3
hdofRX5VjIVx8D/Rd+uix0901H/O8Xyszevv3eAt9OaTkncl3m1A674RRuC94h3Au3HeX71zvFrA
0ebe7d5Np9FXhD9WP63xRjEpEtOW3284/ci9Z3LzZp2BNnj2Lo+gOvjtUb++7N/oLf1lFf5zN4zm
Sxxzcs4Tc5gjxfJIJcJ0sfc9pN+4V/WP3jDeByoeueBXC/7M8fz2hqNtKHOnyJ2u3i1gR5/h6Ivs
e1Psl95r3rXevcg96K2O+E6xr/dOf7wn2ePeivd5/e9u5Rx3z+nfXXmse93P5BZhh+DfX2HVOwNn
LI53j/Lv1j3BGeU9L+f2vz71nipsKWeklRPawIVOm7l6D52JkRynjyjSgd2e9nn5M/QrHa+XTWC2
/+Uj5cxtYD17z9g3k3Aa4zgTx/sfeD3iVGYjeM/GSM3okx1l50UWy3WGxb9beXC07LyT7/eP3k7l
GYij2vjNqyG/U0fO1vOZokgkHDmjU34tOPB78bGc202hfLJPvl+pfwpPeXlbZe345VmysnNyJxrb
Ben8k+/1T90qn2rFk7/yRHxXA1+XLo/svdfFfgN8Pu7ViP+1Dbz/h99+ZqJCuQP//bGc2HZiCHmq
q/oxn5U6bl9yB8Evzw7KFYvymRU4ZqWysnyuKp2uxTH3J2xHcvcIaiB6Og7OypWYP+F8n/fdGWxr
A0XPKB/ziaMG8pQTX0H/5Bh7j9c2P0e1oaxmWU7O8G+Iesr6bCN9/WpcFd7d80ubZWPh57WOGhU/
ldWEr9KcStTuTfGe9haUPwcWzTEjiJ7T/KR8HE2OGu/TJ9/fEfVP4U4hb6lclfiw/L3cAwS+aZ/w
lb4TeHrvN/o+5rPJx6mzRc5a8UouWCDvFuHYiyBD4Pf4pawosdTuxJ7XPEb9U7n/YRk/bylpX+S9
2OhZ899Hh+hnST/yfiPMr++8TyVNoSrgpNujV5PWR45pmWsDT36kx/kckStsFaJ1r693u/d3b6ro
BpTf0+N18144yZYX/TGMmcf42/14h491VTlyRfFXvu+OfxXnVDe5RyaKzN4e8Ik94EcrvVW/IJG3
Ez6+ZtzKu0rev4gZsNzr7b3D7703vb957/IZc9n38BFtrynzn9SILvXyvZFe1+g7yWEGDpD8095M
bwjmwRSwtQVYebnEfO9l76Xoqs1n5ytTllxzHuYNEl/kfsSp4NVP8O/BKgnldwEdcS7I+7Hsaf6T
Gu+j3rOI1R6LvlssfU8RnF8s3wFffZ3n7fX+JQUiT+1H7zCIzuIWJ9/rn7X9V57GPrqXDWWIFbnu
/Gdtp3KdCr/0N1ThrEO5QsKJrD2JxPfvXCH5dGqO2LO61P0KrOMrWU3SqJn3OY5Q/lvjrfXOwfEy
gLQXWdejcSqOzkhMVSX6/oXolQpF5U9Mi/+53/kccm+FV4x1LnoG0uvg5SJ18/pTohdZg8s0NEqQ
OnttvCu96JMN3vvearlbgo/YHViTNkTj10ZUX1bORlLq989uHHtc072ZsM+Wv1/AsdwRd1b0iGau
pcupFTUVnZg6sqfiZw8cXuoFD++XlXKhd7P3Iq9hXti7i3NodewR3UbuAbv5FMY7yCvA5y+QNy5y
gwQ375KV+lP8llsPR56kf0VUQco2+Wa9W6JtnECMd8y+tx+/zFF1dsodAcwTZDbJbF6E9z7ZrX+X
73CtWMrB6BUtO46OXc+ojt2ddKGhjEp0vajTDRN1ujGiTjfW6Gn0pvHGTcZN9DfRpXvEuNUYS5ON
ccYkmsvqdLSA1enodVano4WsTkf/Z/zL+ITeVFmqCS1WzVU2LWF1OlqmzlXn0mesTkefqwtVN1qh
hqhbaJUapopotRqvHqa1apaaRRvV39Vc2qTmq1foa/Waeo2+UQvVG7RLLVLv0HfqA/UBfa/+oxbT
XrVEfUr71DK1jA6o5Wo5/WhqM0Q/mXFmAh1khTnyRGGORGHOMmubtQ1HFOZcUZULmtlmthESVbkY
UZWLE1W5BNGTSzR7mtcaSWYfM9eozM/KGcms+maksuqb0dj3iu8Noyervhn9WOnNuIGV3oz+VpwV
bwywkqwU4ybWezMKrNXWBuM21nszhrPem1HCem9GmPXejBGs92aMtn6wfjbuYY034wHWeDMmscab
MY013ownWePNmMUab8Yc1ngz3mCNN+NN1ngzlti97dHGClZ3Uwaruykfq7spi9XdlMPqbsq1n7Rn
qhjWdVMJrOumElnXTaWzrpuqxbpuqp79gb1SNWBFN3UOK7qp1vZW+2uVw4puqgMruqmLWdFNdWdF
NzWQFd1UET8fp8KucpUqdW3XUSPcoBtUd7qxbpy6y01yk9QoN9lNUaPdDDdDjXFruDXVvay4pu5j
xTU1jhXX1INuE7eJeoh119QE1l1TD7PumnrEbe92UJNYd009yrpragrrrqknWHdNTWPdNTXD7e8O
UDNZd0095Q51h6pnWH1NPcvqa2o2q6+pOe697r1qrjvOHaeedx90x6t5rL6mXmD1NfUiq6+p11h9
Tb3uvui+oRa6b7nL1PvucneFWu1+4X6p1rpr3K1qg7vd/V7tZFU2tZ9V2dQB1/Mb6kdWZVMHWZVN
HWJVNtPwp/irmiHWYzMT/TX99c0kfyN/YzPN39Tf1Kzmb+FvYVb3t/S3MWv42/o7mnX9nfydzEx/
F/8F5ln+rv5uZpb/Yv+lZlP/1f5rzBb+wf4hZstA9UBtM4fV3cwOrO5mXshqbWZXVmszC1mtzSxi
tTZzJKu1mfcGewSvM+fwU3vm66zWZv5bOzrW/Jh12szP9bX6RnM367SZh1mnzedjnTafwzptvgDr
tPmCrNPmq8Q6bb501mnzZbBOm68667T5GulZeo4vk3XafM1Zp83XmnXafOeyTpuvPeu0+TqwTpvv
QtZp83VnnTbfZazT5uuhN+iNvp6ssubrxSprvt6ssubrxyprvhtZZc13M6us+fJjVIzrGxyjY2J8
t8YkxCT5hrGymu+OmP0x+33hWIo1fKWkjI1AvRhEfLEURwbF48+kBKzDPkrG2m1hVa8Df138OVQP
q6BLmUBJP/CwDWngIf+fh3byHzAYMWMEMWOBmFeh1tX4iwdu9kaLfeg6ak/XA0M7AEOHgDncgr+O
NJSGUSUqwl9lKqYwei4FwiYDYTWlGCEjhlLlCeE0Iw6YexYwtx489Y36lGU0MBrC38hohHwmsDhF
sLgJsPhS2O5A5M6iF5pi9AYuNxVcbiq43Ay4PBz+EuMeam6MMcagzXuB1GlA6gcp2xhvPEItjYlA
7SaC2k0EtZsIamcBtZ9FfjawOwvY/Q7Wg3eNd6mN8Z7xEeUYHwPN2wqaK6B5c9gWwHRbMD1OMF0J
pscJpicJpp8nmH62YHorwfR0YPqzVE3NVrMpQ81R/6Aaai5QvqagfE1B+epA+YWw/wesrypYX1uw
PgNY/x/YxUD86kD8JbCfAverCu5XFdyvBdzXVMcMAf3rCvrXF/SvB/RPpoZmiplCjcxUM5U68UqA
PFYCaoCVoB5sfbMBamE9oExeD1Crtdkato3ZBnvbmm1h25ntUAZrAyzWBnj4Wevz5VnrC+T56vPl
+eoL5JnqLlgnSqmdb4TvHjKwWoynWN9Dvol0jm+SbzIl+h71TaXWvmm+6VTFN8P3D0rxzfW9TKlY
UV6hpqwmSs15XaEcXldI87oCG2fFUQcr3oqnJry6UFOsLp+RaX1ufU7VreXWcoq1VlgryGettL4g
C6vOanjWWGvgWWutJcdaZ60j11pvradK1gZrAwV5TaIQr0kouc3aRvHWdms7JWBl+poMa6f1DXrc
ZX1LidZuazdV4bUKPf5g/UDJ1j5rH7W19lv7MbYD1gGM50frR+R/sn5C/mfrZ2pnHbIOoeXDtqJE
27R91M62bIsMrHAOYbGwXQrZfjtAsXbQDpJpa1tTsh2yQ9TWjrFjUAarIP9XdzsRdZPsSqibbKeg
fKqdRgl2up2BlqvaVYkVUGvA1rRrooVadi2Ur23XRvk6dn2Ub2A3oCp2Q7sh/I3sRuSzM+1MirHP
shuj/bPts1E3y85Ca03sJijT1G6Kus3sZqR5xUVfLe2W8LeyW6NkG7sNWsix25Nld7A7o2QXuws5
9vn2+RjzpfZl+FyX21ei/d52X/SeZ/dDL9fZ/dHOAPtmam8Psguog11oD0WPt9q3UUf7dhvoYRfZ
xVTZvsO+A6MdbofxWUrtEWhnpD0SLdxp34kW7rLvoqB9t303ehllj0KZ0fZo9AIGQGnMACgLDOAh
am5PsCdQM+YBlAIeMAl7J9uTKdV+1AYO2I/bj1OOPcWegm/7SftJ2On2DGrKGrAoD66AFubYc2Cf
szFL7bn2XNR93p5Hne1/2v9Eyy/YL2LvfHs+6r5ivwL/q/YClHzdXoiSb9pvYe+/7LcpGwzjXfjf
s9+jxuAZH6D8h/aH8Hxkf4SSH9ufoOQSewnG86m9FGWW2cswws/szzHm5fZyOsteYa+glvZKeyXq
gqOg1lp7LVpeZ69Dra32VrS2zd6B8l/bX6P8d/YPKLPP3odvY7+9H2M7YB+kFOYx1Aw8JoR8jBNP
zZ0EJ5HSnCSnCmU7yU46tXQynOrUBCynHuU49Z0GdKHT0GlEbZxMJxOes5yzqa2T5WShhSZOE5Rs
6jRFmWZOM+xt7iB2BDc6h1o4rZ3W6KuN0wblc5wc7G3rtEVfrClgMGeipsyZYMGZYMGZYMGZYMGZ
YMGZYMGZYMGZKJU5E6UxZ4IFZ6KzmDMhD85EOcyZKIW1aqmx28HtgFpgTvCAOaEMmBMsmBNlM3Oi
lmBOiATcAe4Aagv+VECxbqH7V5QBi0JdsCj4waJQcoQ7Au2MdEcif6d7J/xgVBgPGBXKP+g+SM3d
8e541AKvombgVRPhmeRi1rmT3ceR/7v7d/T1jPsMXchMCx4wLQow04IF04IF04IF04Ld7n5H57p7
3D3o5Xv3e7QD1kVZzLqQ91yP//eWn6iz3/AblMIMjNLAwBxY1+9SCz82yvIH/AHktT8GNtaP9dcf
54+jbH+8PwGeRH8i5fiT/EnUzF/JX4na+iv7q8Cf4k+h5v5Ufyqd5U/zpyGf7k9HLxn+DOyt6q8K
D7gd8uB2GAm4HSy4HSy4HSy4HSy4HSy4HSy4HSy4HSy4HSy4HSy4HQWY29G54HZXUFygR6AH2YEr
A1cif1XgKuSvDlyN/DWBnpTEzA+eewKzSAWeCjyHPPgf8uB/KAP+hzI/Bg1SQRVMpfOYBVKriHYD
s0BSzAJhwQJhr9XXUobupXtRdd1b96Z43Uf3oWo6V+dSLd1X96WaOk/nkan76RuQ76/7o/wAPQBl
btQ3oszN+mbkB+l8qq0H68EoU6ALUWaIHoK9t+ihVBXM8nb4h+lh8INfwg7Xw2FLdJjSdakeQTX0
SH0nSt6l70LJu/Uo9DhG3wfPOP0AWgYHRS8T9ATYh/XfUGainoQxT9aT0c6j+jHkH9ePo/wUPQX5
J/QTaHOqnoq90/Q0qqef1E9SA2auVB/MdRY10k/pp6iTflo/i/xsPRtl5ug52Pu8fh52nv4nZeoX
9AvY+6J+CXtf0a9SQ/2aXgDP6/p1eMB3YcF3Yf+l36Y6+t96Ecq8o9+luvo9/R5Kvq/fRy8f60/g
WaKXok2wYbS/XC+HXaFXoswq/SX2rtar0c4avRb5dXodNQdL3oDWNuqNVI+5MlUFV76T0kN3he6m
mqFRIXxL4M1jKDN0bwjfVWhcaBxVC90fuh+eh0ITqFHo4dDD1In5NDzg05TJfJqSmE+TYj4NCz4N
Cz5NScynqSmYXXvh012ETyth0hHeXMaYmR/HCD+Oob/gL0aY8QXCjLsKM04QZnyRMOPKwoyrCDNO
FmacUkG/xxL9Hlf0eyzR77FEvycg+j2W6PdYot8TEv0eS/R7LNHvsUS/J1b0eyzR74kV/R5L9Hsu
FP2ebqLfkyj6PReLfs8lot9zqej3dBf9nlQw9SB4c8gICUdPoRZGqpEKDs1MvRWY+qXUWrj4FcaV
xl/gZy7exuhv9AfDvtW4FfY2oxi8eTgYeUsw8jHUFlz8XuTvM+5DeWbkLcHIJ1F7cPEp1AEs/CXY
l42XqaMx33gTe5mFXy0s/Dxh4Z2EhXcGC88iU1i4WYF/m+Df5wn/vhD8u5uwcFYY8onCULwoDMWL
wlAlURiKF45+mXD0c9S9aiy1Y2V/6hFl6szLG6nn1fPUQL0KXl5LGHkdYeT11EfqI/Bv5uI11FK1
FP7Pwb9riGpRhvpCrQEjX6fWwbKCUaaoujVUm9VX8GxVW2FZ262qKBvVVt+oXcizvlFd9Z3agzyr
HNVXP6uDyLPWUTV1WHlUVRSPapqGqZBn3aO6pmVayLP6UU1RP6ptBs0gPLFg/42F9zcV3t9ceP/l
ZpqZDj+z/8ZmLbD/s826YP+Nhf1nmQ3NhshnmpmwTcxm1AyRQEvkW5mt6CzzHMQDjSUeaGLmIB5o
bJ5rnov2OR5oLJHAlRIJXCWRwJUSCVwlMUAXsP+JFAPeP5UShPEnC+NPE8bfyjcfjL8NGP8iaut7
x/cxdRTe36mCJpMlmkyxosmUKJpM3SUS6CqRQAfRZ+om8UBrxAPLyJYYwLG+QAxgSwzgSAwQI+zf
EfafbG22NoPlb7G2wsO83xbGX0UYf1dh/AnC+JOF8adYe629sMzpuwind4TTJwin7yKcXtk2OL0j
bN4RNp8irL2L8HVHmHqCMPUUYeddhJc7wsuThZd3ARdH3Gs3BiO3hYsnCBfvEmXhze3mKJ9tZ6M8
c/EuwsIjnNsRnu0It75AuHVX4dYJwq0vEm5dWbh1FeHWycKtU4Q9p9jj7HHglPfb94NNMntuLYw5
x55oT4SfGXMLYcwd7Kn2VPBI5srZ9gxw5RzhymnCldvaT9uzwePngCWnCUu+QvhxW/sl+yXUYpac
LSz5CrDkV1H3NXDlNOHKrYQrt7X/bS9CC+/Y76A8c+VsYclpwpJbCUtuKyy5k70ULDlHWHIHYcnZ
wpLbCktuLyy5s7DkFvYaew32Mj+OMOMW9k57NzzMj1sJP24t/PgK+7B9GAyVmXGOMOO2YMZVkGdO
3F44cQenhlOHOgoz7iTM+GphxucJD+4gPPhq4cGdhAenOS2dlrDMgDsLA+7knOucizZZUSxWtMQs
0RKLFRWxWFERs0RFLCAqYpeIipglKmKWc7lzOXpnLTFLtMRiRUWsm6iIJYqKWHdREUsVFbFUURGz
REXMEhUxS1TEYkVFLLGCilisqIgFREUsVlTEUkVFzBIVsVhREbMqqIhZoiIWKypilqiIJYqKWKqo
iFmiIhYrKmKpFVTELFERixUVse6iImaJfphVQT/MEv2wkOiHxYp+mCX6Yd0r6IdZoh8WK/phluiH
xYp+mCX6YZboh8WKfpgl+mEXin5YN9EPSxT9sItFP+wS0Q+7VPTDuot+WKroh1miH9ZN9MMuEf2w
7hX0wyzRD0sV/TALMUwitUbEUoc6SHzS0a3n1kNsUN+tD67fyG1ErdxM9yzEG43dxvBnuVnRuCXb
beo2o84SvWS72W4rWI5hOrlt3DZoh2OYjm4X93zYC9xuaO0i92KUucS9hFq4lyKSaet2dy9HhHC1
ezX2cjzT3s11czGefm4/1IooMXKE0wkRzkD0xRFOjPtXdwjaucW9BbVudW+l89zb3dvhKXFL8Sk4
zmktsU2aKDdmS4ST4z7gPgDLcU5niXNy3EdcoITEOdkS4bR1p7nT4JnpzkTvHO10kmjnavdZdzZq
cczT1v2H+w+Ued6dB/siIp+gu9bdBPsVYp6gxDznS8zT0d3r7kXLHPO0dn92f8an45gnKDHPFRLz
dJCYJ0einWyJdlpLtJPtDyHCyUGEE0/tJcLpJBHOeRLhdEaEUxlRUBV/MkqmIMJpJbFNmsQzHRHP
1EMvDRHPBBHPNIfN9reGbYsYJigxTBAxzKWwHL0EJXoJSvRyPqKXHtGIhWOVaxCH9JSIpVegFzzX
Ba6jdoGBgYGwgwKDYAcHBsMWBgphhwaGwrIWXbxo0cWLFl0l0aKrJFp08aJFFy+RjymxzWXBtGBN
OifYNXgZtQteHyymHqJU55Nox4cIpxGiCI5hGkkM00DfgBimhr5JDwRT57ilhkQsjRCxFCBfqP+K
yOE2fRs8HKvU0nfoO+Ap0aWIUjg+qSPxSSOJTxogPhkLz32IUhpIlFJPP6gfRHmOTxrpR/RE7J2E
+KQe4pNH0RrHJ3UkPolEJrUkMmmsp+vpsDP1TFiOTJpLZHK5fhaRSRNEJs/B/w89l7IkMmkikUkz
iUyaIzJ5EZ6X9Mt0lp6v56Pka/o1+Dk+OVsvRHzSWL+h38DeRYhMsiQmaS4xyeX6Q/0R9n6sF8PP
kUkzvUwvQ0mOSZrrL/Qq+L9ETNIMMckatLYWkUlViUyy9Hq9Hv1yfNJU4pOz9SYNjifqgJmiR9pQ
79A74WGlwJp6l96NPOsF1hW9wJqiF5gpeoE1RS+wmuiRVtWH9CFY1g7M1J4GAxQFwdog5mCAoiNY
TbRJq4qaYIZok1YVTcG6oimYKdqkDUMxoVj4WV+wbigxlAgPqwzWF5XBaqHkUCr2stZgpmgN1hWt
wfqiNVg7VDNUE3tZcbCuKA7WFMXB2qGBoYFUQyKxOojERkokhvkQuid0DyK0MYi+6kj01UzirssR
dz2C/MTQZMqS6KtZ6LHQY8izcmFdUS7MEOXCTFEurC/KhXVFudBHRtqe9BEgv9ocS+uI+vZE6ovU
H2kQ0hCkYeWvRuFsvIaR7kYaizQeaSLSFKQZSM8gzUV6CWkB0ltI7yJ9jLQUaSXSWlIjPpREfTdL
UiOWIC1HfgfSbqR9SAeJ8hSSixSDlISUilQ9Moa8ur/xmhlpK69pNHGdVkjtZB/ldULqGhmv1JkR
+Yx53ZGuQuoV8Udf1YjVkozCeUjzkd9Y7oukbUi7ovnlSHuj+Z8iaSRFk42kkRKQkpGqRsqOrC3l
Ka8f0o2R7ylvcPl3HinbUMpR3lCkYqQRSKOjn2FcpL+RWdHPOgFpMtLU6P5Z0f3Z0ZQDH37HPP48
C5HeLv8skc88H2kh0ttI7yMtRvoMaRXSeqQt0dedFV7Lyu9BOhB9XRWtd6DC/sNE/XxIAaQ4pMpI
6b+88u/XryZS/RN+VSM7/vJb8Wfr1zj6W59sSj0yyfweG+lH5lVqpJz0WzE1R2r9y2t5G5F21cgL
4G+P1CU6/7Cv30W/vPa7HOkaX3yf9fldS5b0vbuAxNpiNezYggTY8QXJsBMLqsJOKagNO6OgYckS
rlXaq+8zBVml/fpsye9esrzPzvyrSlb3nVuQLTanPP9SQceS1by39MY+e/J7lWzsu6DggpKNkXzU
HsjvV7Kt71sFl4jtAfuu5N+V/McFPWGXFvSFXVnQH3ZtwaCSbVyrdDDsjcgfzh9csqvv5oIhsDsK
hsHuLgiX7GJ/6dBcX/7Qkr199xXcDXuwYGxpcW4gv7jkpzxVMF7sRLFTYN28TrAxBTNgkwqegU0t
mAtbveClkp+4VumIvLoFC8JTcuPyR4TxzRa8Fabcyvmjwzbb0tG56fnjwjqvacG7sK0KPg5r9pSO
i/ijtmb+hHBCbv38yeHkvHYFS8ttp4KV4WT2l06I2sb5U8NV87oWrBW7Gba75K8q2AHbq2A3bL+C
fbA3Fhwst4MLVenkvKGFbunU3Ob5s8K184oLY8K1pbWGUc+IwqQyy57SWbmt82eHs/JGF6aKrV6W
Z3/p7Nz2+fPC2XnjCuuGszlfOi+3fWEm8l3y54dz8iYUNhXbqjw/ubAd7NTCTrCzCrvCzi7sDjuv
8CrJ9wrncN3S+bkX5S8Md8y9PP/t8AV58wv7lduFhf1KF+a9XXhj+ILca/LfD1+S2yd/sYxhsNih
5fn3C4sxkuvzPwv3yFtcOKLcflY4Otwjd2D+qnDPm94qGiF2tNhxsO8WTYD9uGgy7NKiqbAri2bB
ri2aHe7JtUYV37S5aN6oEbmF+evDfXNvy98S7n/TjqL5sLuLForl/L6it8P9ee+o0bnD83eG7ZsO
Fr0ftgeq/J2jxkVs7p35e8KDBrpFi8V+Bhsj+RjJJxWtgk0tWg9bvWgLbN2ineFBXGvUBNgDyI/J
PxweMjCzaA9s06IDsK2K4GH/qMm5Dwz2hYcNbFfMtlNxYNTU3L8NDoTDA7sWx7EdOFrylWG7F6fD
XlVcE7ZXcX3YfsWNYW8sbh4Oc61RswYOLm49anbuY7kbw3cPHFrcPnx37pOD48Jj2Y6snfv04Mrh
8QOLi7vAjii+KDyePaPmRfxR+9zg9PDE3BcG1wxPGTj6/7H3/UFtZHeer4UsNB6GYRiGYRlCGIYw
hBBCiEM4lhBCGEIIQ1hCWC8hoJG6W1J3S0itVksG0RKSkAnhKMbrdVif4/hYn49yHMpxcQ7hHIf4
fKyXpQhFWB/r4ijipQjhKMI5hOUcitz3PUkMtpPM/LH/3dW3vh89v379+v34vO/3+5677Y6GQ+zv
OAlrB/J7bkZw3JqjDHNnOloJ0ofpoQ4O8GKHDfByhwx4tcMDeL3DD3izo7fnFnerY8Crb7ttzVdG
uDsdZ3vukNpGIzn3Os4DzmLEOT332u5aTyhj3ELHJYJXommc3zPbNm0tUSa4Bx3XlAmc7lngVjpu
9Dxom7OWK5PcGow8YMf4YXqz4zbgo467gHsd04AHHXPKJK/uuA94vGNJmcT39qy03bdWKVNtS9Za
ZYZP6Hj4FCZ3rCszbQ+tDcp827r1pLLIp3VsEdw5TGd2PFYW27asrcoyn9OJDjG/U6Mst+1YaWX1
nQe2foJnAFdIes02BLhpuwj4yHYZcM92FfDAdl1ZxXd57+jVtpvee22PrZyyoUNWm7KtP267BZhA
MJlgmu2Oso2vemd1Gqus7Oo0tnsYcVqfaZv1xuvirB5lX59jWyD44Kl0vm0F8IRtDbDEtglYbnuk
7OO7vAu6RKvfq9KlWHu9Wn2VbQ+w1nYA2GBXA560H/dqdenWAW+8vpUgbU/wPtBlWc96k/ScPZlg
GsFMb5Iuy54DaZs9H1C2nwD02EtwPpRf0fvt5ZDTa6/yrulyree9qfoBey3gWXuDN1VXYL2kzGP0
burP2096H+mKrFeg/CV7K9RQZKcxQs5KOD+CpdZr3gxdhfUGtO2KnQO8RvCG3QYjg/P39ON2Gbwn
SeuqrePebP1tu4eg/xDv2nsBp+0DgHP2s4D37ecBl+yXAB/ar3gP9Ov2az411HPbm6dLt98ArLDe
BayzTkM7t+zjgDsYSc6KrtE65y3UP7bffhJxvg+2rfa73myDxj7tS9A1W+97iw1x9jlvMU77knXN
dsjR6axLpF9hfBhNGxLt64Ap9i3AdPsOYJb9MWCuiAALRA30Hd+7p2OtD71lOsG67q00FIlxT2Gp
mOit1InWLW+Nzm3d8dYbKmxnMIoph1gtpnvrdYr1sbfJUCdmATYSbBZzAXVigS8NxyS+TAMrFkF8
ArGBL8cgiKVd6wZRrAB0i9VhD+7Lx37Qd8KgiHVKuiEoNirp2BP5Sgx9YjP2SqIOEHyNr9wwKLJK
keGcKIB/gfXiqzJcEEVlFfPWV2sYFt3KvmFEVABHxWCYY74GPL++k4Yxsc+brasWBwFhHHythgnx
HB4T8QJguKeT4jDglDjirSceZ40/0RkH3gdb/k2+pDNREfjyzhTAqs70iH1+hK1czx5f25mlDLeN
d+YCYjtzwDd0FmCb01kECJYkpOZPdpaC9WjtrFAWCfNXDDPiqI82zItjPs6wKE74bIZlcdInG1bF
qa4lw4Y40/XQsC3O+zxQZhHK7IrLPr9hX1z19dIqccM3QGvFbd9ZOl7c7dpqqxX3lQo6yaHynadT
HVrfpbaTjniljs5wJPmutOU4Un3X2vIdGUo6ne3I9t6j8xx5vht0oaPQNx6ON+hiR7HvNl3mKOua
wxGF7y5d6aj0TdM1jho8C476qGen6x1NBFsAm6Btc3SLQ++7T+sdJt8SbXJYfQ9pq0PyrdOSo8O3
RXc4fL6dcEz7jsoRgiguHEeRKIX2OfohdiVxIx1ynAHsdwxBFIe58fgdvQOQPuO43I3oIcfVbg19
0XG9O46+jEu2qR03u3boq45b3YnhyE13wXGna46+7rgHa5zEqPRNx2zX+jupjoWux/QtxwN4usmx
AuNwx7EGeM+xqWTRs45HEINddexBexYcB4APJLVvQLcrHYf6V6SE7hR6TUr2zeER6E6nN6W0MLe7
s+hHUibUsyflKEX0gZTfncuopRPdBeEIkzkulXQXMQlSeXcpXhfdFUyyVAVROsTq3dVhZNKk2nAE
3l13BBsJNpOn6AiyTKbU0LXO5Egnu7aYfKm1awdH1N0Cc0KiI2mRoBuvr24lMpIQD3cHCfbhVnUP
MiUS1z0YThM8x5RLNiWRqZJkiIchKu6+wNRKnnAM3D18BEcgUpWULKZB8gOexIij1u7RMDKtUm84
Uu0eY2hpQClgOOksIORDjk06H45afeXvYfcEXvXdkwSnwsjI0iWIRSEi7Z5hPNIViDwhLu2eZ/zS
NaWO6ZVuANqkcYg5Z6XbEFvieVkMIzMg3e1e1mdK07C6sWWOZ85Kc+A9M6X7kD4vLXWv6tKlh9gj
SOvdG8wlacv7iLki7XRvM9ekx927zA0n6t5nxp0avypi24n11jU74/xa5rYzEayx25nijw9bQuau
M92fxEw7s/ypzJy9yp/B3Hfm+rPDMYCecxaALyBehlnCdjvso5mHziJ/HrPuLPUXMlvY2zI7zgrw
emC1/MX6OWe1v5h5bFvwl+nPOuu8qSxyNvpTI375irPZG89qnDocSzhZZZWNcwrYpztFZZ9NdLq9
SWyKU4HnLjmD2H85wQay6c5ByM9ynvMmGQqcF6Kegs11Dvsr2QLnCLQNYonuRLbIOeqbw73z17Cl
zrGwpfUusBXOCain2jkJXgB8rr+erbPe8DdhP+VvYRudU3492+yc8ZtYnXPeb8Xj5pdIPR0s61z0
+1jBuQx7HLDh/lA42sHoaw1jNKqxyv5+jOEc/xmCQ7gN/osEL7Oic9WrYt3ODa+WVXA0giMTXysb
dG6H0+DvAOEu8AX+q9jq+q+yfc7dcFzhvx5B6IWvgR107oO/IGnSr6vsOVnlzWAvyFqIKCCu8N9k
h+X4cBQBrTpE/5D+ipzkzWNH5FTAUTkj7PGhHkD/LXZMzg57ef8ddkLO8xayk3IhIORDzpRcHPby
/ntHcBb7Kf8CwSGCD9gZuQx8N3hw/wo7L1eCpwY/7l9jF+Uabw27LNcDrspN4MXq5BZvExnzTYKP
IiOzIeu9xey2bPJWsruy1VvP7suSsmpUyR3+PZ7urA4d57nOumAdb+tsBJQ7m5VB3tOpU1je38kq
Gr63UwglQBkRrg50ukPJ/NlOBa6e7wyG0vhLnX2hTP5K5yDshi51nlP6+GudF0I5bWc7hxWFv9E5
EsrnxztHQyf4251joRLwmBPKMH+3czLQy093ToXK+bnOmVBVeHfQNt05r0zw9zsXQ7X8UseNUAP/
sHM5dJJf71yFfdx658ZhHL7VuR1q5Xc6dyH9uHM/cENAHlWIFjQebYgT4jzxIZuQ6EkKyUKKJzXk
EdI9GSF/eAfK1XiyYc8V3umQPYWQ5ckL9YZ3eUIu5IhCgacQ9lzg60MD3GVPcWiAz/GUhc4KRZ7K
0Hmh1FMT4rg8XLJtwFOvuIUKT1PoUnifZZ70tET3s+E9plBN9pU13Bre8Xn0h0+/6jEBkr2SUOex
wo4pvMc5gD3mpNDYud1dypV5JKi/2dMRuiLoPD7YZ8EIhK4JrCcUiVXOCIKnXxkWRM8ZZVFwe4ZC
NwTFczE0Ht4PCkHP5dBtoc9zNXQXxzmhaWHQcx321LCzDs0RvC+c89wErwE7aPAXgKEljF6ypw49
xE8JrYdRuOC5BT0ahj2XKIx47ihuvP8NbQmjnnuR9A7BxzheOo0iIwm719OaCEKrTscJY57Z03Hh
NMFEYcKzoJwTJj0PYPcKe9jTKcKUZyW8Yz2dfgSzuHueNRixGc8m4DxGvMf0nQyjsOh5FN5Xns4V
lj17ypiw6jkAhHzI2ehSh/eYpwuOYBGO4k6XEqwIo7DddRx2jrB/PF0t7HYlwD4RdpGn64T9rmRl
3qLqSgPUdmUqi5b4rpxQK56X040Em9sGuvJDW5akrhPKhCW1q0SZsWR0lUPJ7K4qpdmolX3+A7J3
IP6I2C7Ysxjj5VBAbUyS+wPHdRr5THeiMVUewr5DvhhIMGZghPTlQLIxW74aSAO8foh58s1AprFQ
vhXIMRbDXdrwns5YJt8J5Bsr5XuBE8YaeTZQYqyXFwLlxlRsPwnuGZvkB93b2FoGqgjW6v3yijfJ
2CKvBRqMenkzcFJXJD/yrhhN8l6g1WiVDwI0QQ7byYAtsrcCDMhGyaUOeML7LGOH63jAb/S5EgK9
xpArOTBg7HelBc4az7gyAYdcOYHz2GYGLhG8Yrzoyg9cAzzhVRkvu0oCN4xXXeWBG2GfYrzuqgqM
G2+6agO3jbdcDYG7xjuuk4Fp4z1Xa3cpsaJa46yLVljjgosLzBkfuGyB+8YVlxxY0gkuj7fSuOby
e8uMm65eZSzsoTAGHuoU8IaQdg34O8KRG5PgOhtYNz5ynQ9s6ZDrUmDHuOe6EnhsPHBd8x8Y81w3
ApkmtWs8kG867rodRKYE192gxpTsmg7GmdJcc8qgKVMeCiYerc2U47ofTDHlu5aC6aYTrofBLFOJ
az2Yayp3bQULTFWunWCRqdb1OFhqanCjYIXppFsTrDa1uuOCdSbanQjIuVOCiRG0udOVVZPszgo2
mjzu3IDf5HcXBJtNve6ioM404C4Nsqaz7oqgYDrvrg6KpkvuuqAbz29QMV3RuYNB0zV3Y7DPlOYG
m2+64dYFB8NzZxp3s8FzpttuwTdguusWgxdM02434JxbCQ6b7sOtI6Yld58/SVfthh2W6aH7HOC6
+0Jw1LTlHg6OmXbcI4CPXSXBCTNyj3YvmzXuMUVjjnNPBCfNie7J4JQ5xT2lCOZ090xwxpzlng/O
m3Pdi8FFc4F1rrvUXOReDpSYS92rwWUouQElK9zbwdXwU8zV7t3ghrnOve+bMzeeUgW3dRpTjrJr
bj6lDe7qSk/FezPMulNJwX0zeyq1R2UWTmX0aM2iydOj1TWeAu9sdp/K64FY7lSht8msnCruSTIH
T5X1pJr7TlX2ZJgHT9X0ZBsLT9V3b2PsyQvv+s3nTjX1FJovnGrpKcbRS08ZjlJ6KvEpSk9NeMWR
E4z+yEnFk6vjduSsgJwM9NSbh0/pAznYv/c04T14TwtmY48+fDpE7MOeeUQegvpJJGYePWXyLhiz
T1m9C5HTG3KuYh6z2npMxkenpB5reNdvnjjV0SPhufY1IBV6ldqm/jdC1G+pXaSiHlO/Q2rq9yoK
aVTHVBr0nOp5VRx6XpWgegm9oHpFlYxeVKWqXkMvqTJVb6CXVTmqj6JXVN9RfQe9GlMd8yWUcqzq
2BdR6jHxmAOlHfvpsZ+i9HgQ9OH4jPi3UUZ8fXwLqotvi+9BX49/N/4nyB9/L34T/SB+K34X3YfW
/AVSk//9IB69iJ5DL6FG9DxqQnr0FUSjb6EW9O/RAAqiQfRzFEL/hH6BptG/UMfR/6DiqBfQ76kX
qVcoisLfOGnxe5PUq1QzZaTSKDMVonKpXuosVU0NUd+hvkb9F+pn1Ndjvh/zfUpWS2on5VL71H7q
lLpX/S3Ko35X/S7lU39b/bdUt/q76r+jgupR9XXqm+qb6h9R/eqfqH9CDar/u/rvqXfJ95hn1fPq
n1PfVi+rV6i/Va+pf0VdUP9a/Wvqkvq36n+l/iN+i466fOzlYy9T//nYz48dUCOaY5osakHzpuZN
akfzUU0+9VvNZzQl1O/wFx7U7zVf0FSq1JoqzdsqjeYrmhZVvOYdDa1K07AaUZWhcWoU1cc139QM
qD6jGdRcUH1W813NFVUN/nJC1aAZ1fyj6quaWc2syq6Z0yyqRM2SZknVqVnRrKg8ml9qNlRd+H0s
VbfmN5odVUizqzlQ9cai2BdU78Ymxr6i+m7sq7FvqP4uNjv206rrsZ+PFVSTsY7YM6rN2L+J/ZuY
uNhvx16IeSH2e7GjMS/j/1c15tXYH8aOx6TFTsT+NCYdvw8Ukx37T7GLMSdiH8SuxRTH/ir2X2Pe
0mZrb8Q0an/z3Osxv4j/Xfzv1Ph7OQH1AsahdPy1ccX1iGpB81C2oK/eE0yV1V+6X1kgWAVJ6Khe
EXxCqFKoHxRuCreEO5UTwj1hVlgQHggrwlrt8dpMob9WFs68VfOWSRgSLgqXhavC9drMtyqBVWrg
+Dbh+G8RRf2e+j1SAaMTUAxc+xB5ExWpvqf6HqJU31d9H65dV/0Axah+rPoxOkbeRNWofqb6GdKS
L8GeU/1ctYCOk3dQ48jbpy+ofqH6BYon752+qPq16tewOvCbpYkxVAx1+L8GH4vRoGTy5VhKTHJM
MvqzmJSYFJRK3hR9LSYnJgd9iHwVlh5TGlOKMsg3YK/HlMd8HmWSr2KyyDsbH4H2x1GJZOQwIv4u
8vB3+Wl+jr/PL/EP+XV+i9/hHwuI3xE0QpyQKKQQTReyhFx+SygQioRSoUKoFuqERqFZ0AmsIAii
4BYUISj0CYPCOeGCMEx0RBgVxoQJYVKYEmaEeWHxqFiahGVhVdgQtg9lV9i3qCzaIxJvSbKkWjIg
N/sJabFkQ9k8S6GlWNiPiqXMUmmpAcRSb9EL2xYTlLVa9BbJ0mHxWUKWfqgz23LGMmS5aLkM/aee
EyJWA3+z/hIZkxSQGJQGokbZ6E10DOWBxKJPgGhRCchzqBTkOCoDeR5VorfI2+VfBquDv7t8Ef0V
akYJqBUkEewOjV5GJpAk5EAS+eKyg3xr6SVvlAdQKtijd9Fr6NsgH0L/ASQd/Sd0BX0YfQ/kdTQK
kol+BPIG+q8gWejHIB9B/w3dhfZNg+SQ/w37o2gR/TPKRf8TJA/9C8jH0S9B8tEj9Bto+x76P+iT
6ADkU5SKikUnqONg+0rI++N/DrYvAZWS98fLqHTqdfQ56g3qDfQF8r1nJVjDevJFZzOqor5B6dAX
KT2lR18m75LXkq8736YESkB1VDvVjr5COSkZ1VNdlB81gO0MoZNgPb+J/or6FtWPvk4NUoPoG+Tr
zlawpOOojZqgJpCBmqR+imhqivp7xFL/QP0DMlH/SM0gM+EvD1YgBwnaXG0uaidv59m0n9QWIjt5
I8+hLdGWIElbpi1DTvIlkUzev3Npddp30CmtQWtAnTC3a2iXcL8I/8sS3BjoBOgk6BToTETnI7oI
uoz+kpvgJrkpboab5xa5ZW6V2+C2uV3AfV7Fa0Hi+SQ+lc/gs/k8vpAv5sv4Sr6Gr+eb+BZez5t4
Ky/xHbyPD/H9/Bl+iL/IXwa5yl/nb/K3+Dv8PX6WX+Af8Cv8Gr/JP+L3+AOhV1ALx4UEIVlIEzKF
HCFfOCGUCOUgVUKt0CCcBGkVaIETbIIseAQ/yIBwVjiP/wfRY/pjZnCC34hvJf++wlv/Zvx+G+RF
wvIEwvKXCMtfJixPIix/hbA8mbA8hbA8lbD8NcLyNMLydMLyDxOWZxCWZxKWv0FYnkVY/hHC8mzC
8jcJyz+KZkByCdc/RrieR7ieT7j+CcL1AsL1TxKuf4pw/dPAdRUqIvz+DOH3v6M+RKUD7zGzSwmz
P0uYXUa+j/gcYXM5YfPnCZsrCJu/AGzugjXgpbywBvBXEl8kbK4mbK6h/pr6a1gPmNO15PuItwmb
6wib66kZ4HEDNUvNoq9qv6b9GmrUNmub0de0Zq0Zf6+d4Evog3mKg7F/HlH2VuBdIWgxaBloZSSv
BrQetAm0BeepX+JO2Iv4+T+tpMyiuMCV2Eu5cnsFv/yk4jyuyl7Nr4JuiA+wcrX2On77TysuwzXY
G7mT9mZ+9z3Ff+Za7Tp+364TVOIKR9tZQfunlZSJF9c4zi4ISXaBs9lForLdLaSCZohWks4WN4U8
8RHnsSuc3x4UCt9T8udicY/rtfcJZe+jleKBUONQcwP2QaJn7ee48/YLQn1YcRr3TWh6T0lfL9mH
hRb7MP4lesU+IujfX3E57pp9lLthHxNMTyo3bp+I1ntUudv2ScH6nnJ37VMfRG2t8nlu2j7Dzdnn
/6Dety9itdHyJazckn35A+lD+yq3bt94Rrfs21htnGOA27HvfhC12eQr3GP7PlYeiSqiGlGL1SbL
1/Bvu9V5ldeJej5OjOcTxaSn1eaRb/ApYur7qc0vj5M60sUMolliNp8r5j2hBWLhM1okFj+hpWLZ
B9YKsZKvFmue0Tqxnm8Um57RZrHlCcX9/gAqSI7jPCuaeEG0/kGFa0KHI0HwOZJJOVGUPpC6xQ5e
EX3PKK4vBNrvSOODYuiDqHDGkcn3if2HOiieOVR8fQj0oiOHpC878oWrjhP8OXGItPcpFa47Skj6
gnjx/VS46SgXbjmqnqhjWLz8hI6IV59RfO8dRy0/Kl4X7jkayO+s4+Qfas8f1THxJj8h3npGJ8U7
/JR47xmdEWePqrDgaI3a9qO2OGorD23cAwd9aINWHNxRO3LIk6PzGp2X6BitOWyHY7vpkI+2idiS
XrApsPZtA2EbYDsbXr9kXZ0XU4nfAL7bLoFekW9H+Wy7Br/wHHxdeOTwCHsOv3Dg6LWoHQPYv1iO
O87ifNw3S4LjvCXZcQnbV0ua4wq2k5ZMxzVLjuMG9gGWfMc4tu2kz8B3ywnH7ah9tpQ47lrKHdO4
35YqxxweC0ut4z62nbhOog2OJctJx0NLq2PdQju2LJxjx2JzPLbIEsLjS3wQHksYQ4sH/GTEn1n8
4H8i42zphXoGJA2ug1w7K8VZzkuJ2O8c+tojc3RYJ9aIT4n6Atwm7Bstl6QU0rYrUnp0nkl5bPth
7olfBp9H+nZNysJ5lhvgw0vCiv01Ht8ntDbsl7G/Iv4YnhP1xfiXKPCH9O0pH0ueBWoZtytYsY+N
+tWoWm7bB7Ee+kjsMyO+8aivfMJHRvxkVC13wQ/CHBPfB/7QMm2fwEp4i/3c7bAe2ixQy5yUS37v
SwWWJamI5IP9sDyUSi3rUoVlS6q27Eh1JB+vYexL8LqFdYTXk+Wx1GhFUjO2RVaNpCPrIroOInaR
cAvqwXbOGge2KbJGyHyB3cL3R23gM2vrqXV1aF+i7Yc6sN20JkosnnNriiQc3o/Lw3qzpkuiNUty
43ZbcyXFWiAFiQ3H/YE+WIukPmupNEjuez/7E2mXtSJix6NrPHSkTKTNpK9P2ePD/mA7HNU/9qw/
Yk+t1ZHfOvE67tOhPm0nj9pKbB+jNvKoTYSypB5cBl+DMbA2OmptN+S7tnF5GiuObfB8k7jmtjxH
8sBmWeed8ba78v1o/GKblpesQWmS2DGIO2xz8kMSU4BNs45KG1ZFmojGBLb78jqxadj/47gB27ol
eQv7aNtDece2Lj+2Tkr7ti0Xsu24NLbHrjg7ciXaNa4Ue5wrncRkEXtJ7sWxWSRuIjFPNEbBdUXq
wNfsia4sbC9xuw5ju2gctvOeDSYajWEisQeuC8dj9hRXLo537Omuguj9pDz0h/wZxousE+ibPctV
RPJw3BjVSJz4hD4dC0Zivyc0Mq5Px3WHimOxqD4d10VjtD8Qm9lzw/q+sRmOvY7GXzjmisZdR2Is
3FZyLy4TGZNn1hasP2uzdO6ZdaWTLkRjLCsrDVsFaQTbomg5qyiNYl5b3dIY4VPUDuAyeM0B/8hv
nzRlHZRmSPqcNG+9IC1iPbrerMPSMrYR1hFplfBzTNp+Jo4BtU5Iu0SBj1jJOsR2a8qpIr8zTm10
DeI1YV10JlmXnamH6w/boFVnBrE1G85s67Yzz7rrLMS+J6q4v3iPRdYf9Nm67yxuVznLSN1gP9q1
zkrSz0j59nhnTXuSs7491dnUnuFswbaoPdupb89zmtoLndb2YqeE/R/xgdg+QUzQXubsaK90+rA9
bq9xhsieBXxhe72zv73Jeaa9xTmEx6td77zYbnJexvuEdsl5HY9Te4fzJi7f7nPeag8577T3O+/h
GBDb/6htbj/jnG0fci4Qhfqwn8Hcbr/ofIDHvf2yc6X9qnMN86z9unOT2DCYx/abzkfk2i3nHqnj
jvMA2/L2e7K6fVY+3r4gJ7Q/kJPbV+S09jU5s31Tzml/JOfj8W3fk08QO4b7fyCX4F+bWi7HfLAd
l6tsCXKtLVlusKXJJw/5AzE4jj9smXKrLUembfkyR/IjNtd2QrbZSmSZzB+sE1u57LFVyX5brdx7
yNXoPiDqoyBta5AHcBnbSfkszkMqRMWH4gcR+v9/g/L/0N+gbKJH7/09AL2LBCaVyWCymTymkClm
yhrVTCVTw9QDNjEt9G5YmAysjJ4x0fthYayMxHQwPibE9DNnmCHmInOZucpcbxxgbjK3Gm8zd5h7
zCwTH5EzRBeYB0xSRFaYNWaTecTsMQesmj3OJrDJbBqbyeaw+ewJtoQtZ6sYVVSgRC3bwJ5kWxlt
WFia5VgblJNJC3GLcEl8DT8PnoDP+V+4Ctz+0r/JOejbsDa+AvISOQdNJOegL5Nz0FfIOWgyMiEO
vYoEkFRyGvoaOQ39EDkN/TA5Dc0gp6Gvk9PQN8hpaBY5Df0IOQ19k5yG5pDT0I+S09Bcchr6MXIa
mgdrbgblo1mQT5LT0EJyGvopchr6aXIaWoR+iX6FPoP+F0gJORP9c3Im+llyJvo5ciZaTs5EP0/O
RL9ApVPpqJKcib5FzkSryJnoF8mZaDU5E/0SOROtIWeiXyZnorVUF+VFdVQ31Y3+gpyJNpAz0a+S
M9GvkdPQJljpP0R/Sf2I+hFqJmeiXydnot8gZ6Jt6j71t5CO/EuDevW4+keIhnU9hVj1uvpXyATr
dxfGkkJupLzHVQP02HDfsGR4aFg3bIHsGB7DwGvoODqRTqHTibC0QIu0m1ZAgnQfPUifoy/Qw/QI
PUoki86lC+giupRIBcFqug6wkW6mdVgwb1QfA958PMKbRPJ8zBgVzNGbwB7MFTWMfyGwB3NFQ7gS
C0x5CziEz8yfA3Y0A4cwP54n/Igj5+QvQL94YBJmQwJw4V3gE+ZBIrDgCvAJMyAJ/QDkFcKAZMKA
V2H+7wJv8Xn4n8Gc/zMwDM/6a2TW08gZ+Idg5jdQOpnjDCoB5vh1MruZZF7fIDOaRbVROvQRMqNv
wozaUA4lw4zmklPuj1H9MIt5ZBY/TmYxn5xpf4L6ITWOChClLdKWHpmPXPVLhtynhe6gfYYCQ1FU
6GxDaUQqnhY6ZKg21IWF7jc0GhrpM5DzlNBD9EVDM4gOhMVCXya/gkGMCn3V4H5W6OukBrdBiUgw
LPRNQ5+hj74FOPis0HcM5wwXDmUYl43ISERGnxbzqHnMMGaYiAq7bZiMyNTTYp4wzESfZZ40zIMM
Q85Twpww7BoWQfDzlrGYcuh4+F0ldxBhtp6t3TBlqiI1TEVH1rARFvOUYduwbR4B3H1WzDPQv/1D
qaNVh6INyx8YqXv0LB1PJx3KAp1K5MF7IxEVeoXOoLOjQmZ8jc57SjZBH9GFRIpB9iL5B4wasOyw
R3UGhTlOVz4rTAJdwyTT9XQTFiaNbgkLk0lbIUdP65kcWn+knkNh8g0btOlQrLQUlfDoG5ZhRoDf
TAnhbjVTzlRhjjG1eCSYBswP5iSkWklv8xia4UiLONLXcE2YKfNklmbMi+ZlwoZVMvobZKQ3GRus
nQIYvyJDKSMbRhgPjHI844f29TIDwGUdcxb47mbO0yrmEnB5UN/LXKGL4bkDwJMglL3G3GDGDfvM
beYuMw0txvwfZOZIL3UwY/cMQeY+lKhjlpiHUBdetaRHpGR4reDZDRoamXVo/xb0eQfy+6BcEay6
PuYxpAqYVhYZSlkNG8cmsilsOptF1nJjWNhctgCvV7aILQWpYKthtQrhFcvWsY3kafAkttkQZHV4
TbJQM5QUWJF1swobNJxj+yLrD6/AEXaQFYBr8YRvqXD1HF1DF7MX6FR2mB1hR+kWdgzmF2aLGWAn
2El2CkYuj66ENp2jZ9kZdh5KL4Is04XsBGEg7iWZK1wOBBiDR4ldBd2gK2END7K7kC+x+0YVu2zU
GuHZxiRjqjHDmG3Mg7HmjIWY78ZiY5mx0lhjrMcch5Elc25sYnKAbcXGFlYw6kFMRitdhgWuScZC
Ywf0oIZugis+usUYwjwF1Bv7jWeMQ8aLbJbxsmHDeJU2Ga8DH624b8abxlvwTD0wVML9M28bxsy7
Jhosw6R5H+ZnGfpTCXwZ5FScFqzACBcPlmKKPWfc5JIMKYYJ/bSxnkvlMvC6Bs7AaHHZXB5XyI5w
xVwZMBRbjl2wZnh0RswT5olwCcOgaY6rhLqwvSMMJiXDVgYYDHXNczWGc1y9YZRrMkzRKig3Ae3Z
5logNWZs4fSGSabEWGgq4UyclZOIFYxYMq7DTCyrsdg8b57nfFwI7Nxq2NZx/dwZ8jR4Ejdk2OAu
YmsGuM1d5C5zV7nrpmQOLLqxJWy5iO3Smje4W1w/3cLdwS0x3oF5wtxpMd4zzmL+hIUZgHZPGRew
TTI+gDleoethdtaAV3lgD/KMmzDWl42P6DLjnvHAUGdSm8DuGP4ve+cCXWVx7fHvfK9EhCNiihAj
jSki8hIDUkAuqEUgOQ+QQqVIJQLGE0SbIkVELiKijVSRWLCIgJRSjDGgIiJgQKW8pMirCIhIU6RI
AYNCikghuXv/5gtEmq7adddd66517zpr/8/Onj17Zvbs2TPzncPhQKJ+ouGQjUM2JtJkBudL3Hwx
dEwiI9E80SbRPtE5cdOwIbn71O9DlwzrmOiRiA79ItE3MSD3QOJOWT2TJcEMH3a/tL9P9seDiZtk
BYclZw2RkvzE6MS4YamJiYmCxJTEtKHjhyUnZibmJhYM3Z4oSSxOLBsWTqwSq+HEmsTGobvF8r7E
VulTWPqyM7E3sT9xKFGeqJA+bhLbyUO/EM3TeVaeP3RyXl3JNg1kLcUlbhpJnVYSKx3zmkj8Hs1r
OnRRovk9R+85eveUe8qG7svdntcir21eU/GDndchr0veLbmb8nrlxfP65Q3My8nLzes1LFveR+Se
zBuZN0a0xyem3LM5b1Le5GGj8qbmPZc3K29eYkpe0d3DOE21/v8b5v+hG2bCyudbDQ31f5PJKbJC
d9lWSs58eRXL6zV5LZVXaU7pQHnlrM5ZPXj34N05G+S1OWczsh3y2iMvlZXJ66C8pN6A8gHlOUfl
dTxH77B2OB7uLW3U50ZjcaOxucs4nHld7jIetxifM28St5hkbjEXcXO5mJtLXc68Yc68l3Dmrc+d
5VJuK5dZofrD6t/PmPjeYU57K5QTlffO8t7XvbTXgpwe34ays+W9RGjxP6FlhrIHGeq16lvSGqGN
tdBWQ9mj5H3nt6PsCfK+N6D9AR0ylLXPvGfPEJojfLlQxT9SdrG8n/7XlL1UqFTsWgH5QnW/SYzt
AspqcAE1+jeoiVDTWqhFLXaV2l5AHb4dxcXvWV2Ebvkn1MtQfKehrPi3pH5CA2uhHENxmbes3G9H
cZnbrBEBjQxojKH4IfMeK5P37ULjhSb9I8UlBrIm/2uKVwQ2pgb0nNCsC2heLVR0AS36N2iJ0Ipa
6F2hdbXQpgto+7ej7IPyvjuH9VErSVn2UaHjgd6Bb0mHhb6ohXYHNivl/eS3o4gr72fOU7Z9ns7p
1A/eGwqlSVny+bZqUiQjaD/8rynSXKjNN+tnp1xAqbWQ1m0v7+ny3jl4v6n2/vwzym4m1KoWyhTq
WAt1/SZFetTI3zXzbXW+DPJYJJpzLr9E+uZ8M39Ux0nNeQ38fc5HA2r49s5v9ulcTqmZA6rXcLC2
dM+ojvnejS6I6ZOmPDJMaLhQvskRur9Exhm5jikyUajA5NccnS/Jk5FpQjPNHhCZG+T30ybeI+KT
6vwckT0tstiMN7Is8IPY1HypNiG1K/MZkbwYEd9FpA8RtXso8G/gT63LPlm9h+2v4WexE7WMDS2L
yn4RrRv068J5umCOzu0p1fNUYPbGaAPTt2ijGvVPm7Hw9+Jg75O/o00CWUkNWlYLXbgvb62FdtbY
X2vsseeovAZdsL+e2y//O/tkk5xv7oUtcs7vgTX2u3M5Syh6S/Au+1Y0HqwxyR9R2ZOisgdFZf+J
5gZyWcO6f7Bue5j1FJV9JjrS5KLomGBdBOugOi9qbKkdzXPkp+o1UmDyltY/lwMvXFsXrKvq/HJu
bRUE/Z8UzPnk8/XRl/UWlb0p+pzpd1T2pKjuQfuCnKRjkD0ouiio969y0IV5vDad6j7Xko/PlSWf
p3+a6/5VPk3/Jv1DnqyZKzNr5Mga+RDd9ECno/GB5ujeEj+9WxjSs43Ot55percNZBIrse7Cax4L
zi+95WwUPRnkMZnT3hpbk0w+i6nv1V/BmaB3ryCX6f7/XJDnNP5kj+4t9nqLvZj0t7fETW+x11vi
rLfalBjrPT7In9X5clFwNqs+N408n0exFdigj5NMvqRfF+bhC3LwuTNMdR7WcaotLZOY6j21Rv3J
wXg6GH9x5pKx9X4ukHWpQb1qoQvPgjm1UODXC89152h8DbrwXFd9RvvvnM2W5Hzz/PVuzvlzV80z
Vk5Qd0UNn1y4tmT9RTfl/MO6im7POXfGiuq63mdy0bl8dcDEdfRwEE/VctU5GcSfvkteiQXrLiZr
LBY2VHO9xVJMjoilmviMNavlHCMUaxVQpiHyoNrvGLx3Pb8GdU3EZK+L9amx/kQv9iOz3mKyR8eG
CCXM3lNN5KNi4ycdc+x+oVGBbRlHbGwwzkA/Jne62BNCTwk9m0Muis0QkjtcbL5Qsdn/lMiTciaI
vSa01OTjWKmJU90LY6uFNghtDvy1Q2iPuSfEDho/xY4a/ZjsHbFTQpXmDKj5vzo3x2UPiNcxpPbY
ZyS24/WN3+NyBo2nmTiLZxg/6jzGmwdlbQIb7U0uj8sZMS7nw7jmHjmPxeUcFpdzVVzOU/Fhxr/x
4UEek/HH84P30SYe4nIWissZKC57RHzK+fjR3K3ngbicheJyForPDeRBzo3LeSBeYuzrOomLj+Jy
BoivqhGr1feA6j1K+PgaoxPfaGT6bYx6q+ut/f9vY/xfelbmtnDX6Ceq9kbrVctKShdqJtRKKFOo
o1DXGu/dhbKF+gj9SGiQ0BChhND9QqOExgpNEHpC6CmhZ4VmCM0Rmi9UHNBrQkuFSoVWC20Q2iy0
Q2iPUJnQwaDNo//k/bjQqYBUv9Kykl0jT64jVD/o29HgXcaQ3FAoTSjDyM+9NxdqY/qa3P78mJM7
C90k1EMoauwk9zXtJQ8QulNoWCAfLpQvNNrYTR4nNFGoQGiK0DShmUJzhRYIlQTvi2u8V+svE1oV
vM8N6q2qUb5GaKPQVqGdQnuF9p9/V/8kHxIq/zfeq31RYfz47xJzUJP6GFL7zFdZoHvoAjpt/tv5
6vfq+tV2L/KF6gbzLfKLGpx/v6iRUBPr1UivSDzSLzIwkhPJhUZERkbGRMZHJkUmR6ZGnovMisyL
FEUWRZZEVkTejayLbIpsl9fuyL7IgcjhyBeRk5EzUTuaHA1HU6KpUHq0GX+3kldmtKNQ12j3aHa0
T/RHkanRQZGi6JBoIno/NCo6Njoh+kT0qeiz0RnROdH50eLoa/L30mhpdHV0Q3RzdEd0T7QsejB6
NHo8eipaGXNjdWL1Yw1jabGMWPNYm1j7WOfYTbEesaiWi7xvbEDsztiw2PBYfmx0bFxsIlQQmxKb
VivNjM2NLYiMiJUEr8Xyqo1fJq9VsTWxjcJvDV47Y3uh/fI6JK/yWEXsdNyK+1DdeAPZExrX+osL
VvCLC8n84kIdfnGhLr+4EOYXF+rziwsN+MWFFH5xoSG/uHA5v7XQOJwevt66Itwu3N1qHR4aTljd
wiPCP7NuDY8KP2RFwuPDj1i3hSeFH7d+GC4Mv231D68Mr7ImhDeEj1gT+fWFBf+LexYKNQjl832V
Ffq/yWdkBiSZJaNrQN0Dyq7BK8mqyfhRwKveoIAfElAiIMm6GZJ1MyTrZkjWzXgi0H0q0FfZszX+
nhG8zwlofo02i4O/X7NaZm+U19bsndl7s/fL6xC4P7tcXhXZpyNWxI/UNa/sjZEGkUaRJpGmIm0h
8iaRtpEO2fsjXSK3yJpkVWZXyLqMR3Jkri7hlzYsfmPD5jc2nHBmONNyw7eGe1heOCscs5L4vY26
4cHhITIPeeF7rSvDI8MPWOnhseH/tDLCE8OPWc3CpeFSq3n4nfA71rXho+GjVov/YeuhyjvcHwgO
lOgIVV4MXwf+evjr4du5vQTbe6OQD0H+a/inBDO91+F7wZu618P3oe51gm2Qt3fvx47WzcT+ILed
oneHfvfJGyt8inuLovdzwcXovKjtnoU/u5I+TER+L3w7+Hbw7U1vAxwL/gwdsXn2z25LwbJgRC0p
vYNeMVK3E+PKo+cJ5Z3d8MmUWtR6Gcl91I0guQS+G3UfxNol9KQb6KHTAZ1cwbbwbeEz3c7Ih8N3
wAJysB2lmZR+371R0buXnnRGU/l2znF0jB+ewlop1nQurnOLkBvsCPZFZxg2l2JTvGHfpi3arb0c
wcc9Wd32aPhu4G5vpOB41QnZ4HT06adtKTq5aE73hgouwOalKgntUj50gtJC9G9F/xn4FKydAMvQ
P+3+QeS2u1awr7tDW1E+dAxJrrtLsIvqWCcVQ9ng1+BKRcdBMws7/VU/9CkWiuAXUtoT/Sr0W8Af
BFeDb6J/xP2paEa93wt/SuPW9r13hK9UeWiIt1FwvyuRYKeqjnXEe1Twb4qhg4FE0MnETiqYRt27
wULwcreK0ruE36Jo74UvBbeC091BOkf+EXApWAwWgOWKSY2krfZmBtF83NffUBkC3w2sF2AxWABq
3cvRXEPpa0h2IxmPZK6Zd+UFl4LFYAFYDqp+FprjqGUZ9J7XqICfTs8XwK8AFwSSYrAALAe7y1je
9QqIooQire8CT1C3MMClYDFYAKqFQrzxjOo4M8Bn6PMJsAw7Zdrn0BFvk2AFeMSbDeaDg0EiwTsq
Fi5nvk6hWQYeDvBRYmC1xgaSSixUYqESC5VExX5K9yPZH0hWCDqM5SpvDTGzCcwHB4PbFImEMhNj
ykukqbVt8EfkTK99EIndOUAZi71eo9ROQ5KGJI3VnaaWBdeCK4jMEhnjWBOfWJ4KFgZ1dV08QMxf
rv8Tt7Q1G8wHB4NrwaOg2txL3b14YyvWtsJPh38xQPXeRvp5W5Jaq2fQRBr8AoPe28xsPvOopSfg
j/j/oR42qL2ykMidVjEV+VZmdiuSxayRZmA6Weh68tvjfnPBR5B/Ri6qgH9Wd5DQX8hp9Uw+VM1Q
He8ewcvIZpPAy/HGInRasRY+hL8NLApyoOwvIezbSYr+Np19/5fqDY9c6uaoT/xlyvutlHcOEdtF
xEkm0buJWsu8xVrXXUSvtHS4yee+Zs6WirI2d7CmdrCOdHVcDV9I6V+CMT5Af3Kp+wr6r+BnMox3
SP2jKLla0cxXa1/2R3s0+vXg16A/PsgexeSBAt0dWIO5yKeDl4JX08ousCqpl85mUgntaumtOsuy
cpVPCVBt3hDk5DnCNyImtyFJB/f4V+j8km9fJJ5vJ28v0SzqbScmt6qm15zYS1aJzJ3GcIrm89Am
s4rlriw7AvOyXT0seWAFMbaCVWlwLetlBbiWHURzdarWFX++Q61HWUGPEofays+1V06WljpZJqu4
clYJXckav4Vay/yvyA+q31F7K5GskoO60iXCP9SdhZ5nBvnnUTS1lflgIbjav0Z5/2lWbm/dZVi5
eyktDdCsUOX7+S0pPYrkKP1XD3fwt2muo7ezdTcMfcCemEpvzyJ/HZ9fCZ/OWPbrScnu46r9zW5Y
8JCeHu3GijJfj5JVdNZmMsY5utac69kHr1V00l2R2O9j+QU0T2D5T/B/gu+J/U3qeUG1nE2f71e0
XoM/DN7u1bH0XKH2b2SmWmBhs9l/9Rwl54S7yH4a4ZM5vRx2hzMKjbfvUTqTnm+jrZVYS9WRun9U
b3j4xP2K+R2t+7vTUK05Hyrv3gjfg/GWM4qvyBVfsRJT6SfZ3i7VHjrtGftFQW+1JxnwrVw5u4bW
M+q3XDkNhm6ibxuoS7Tbnd0Rusap1U/PwHY/53PBae6tYrkr87jEHabxab8g/A6sfRagWnsROzdg
M9N1BT9VlKi70tJTmXjAScIPL1FrJDiVGDjkqvcWYaE5+GvsxOF/zthn4+dbGONwan0G7gXz1GNy
ytJRTNRTq/AXaVSwB92HtSH0sx92fO85zQBBNOro3qY/p/2mit4J8ENwJfIMMFtzgjlzqqbdFuzs
7WIfUb6HOYViZxu4HjvrsbMeOx+jn4t+rkrsfCRdkMTNqVV566T2RPBDcCXyDHjVr2dOtrSy0iDn
qCzsZGlduz98f8OrHcGVyDPAK5GkET+cN7D5KdYqwCJwIVji6g7YE5s9sdkTmz2x2RObPfFST7Xs
tFBNpwUeWI2F1fBvwr+poxCvzqH/im+Y8SovfZuDnTnUOoEFlXSkn18FuJGVpX3o613HatXZedTV
0+a7we1AW1nr7mTNcjtQTcuc5A9wtm/MLaAX+D7WGmP/JLgTLKHuALAHdZch/wzc5EqU+hk6Lr9Y
0R2uOu5mb7msdNryR3q6Tw3CV/l44Gv0w+pVv5h1fT293UacfApODe4pu5iddcTkLmZtF54hPnWV
iQea6Ux5lwvO4k5ko9kEzW3wk2i9i4k35uJllTgOM+Ugz0L/U/ArsAhcx0m+yD9IKyqp0nmR+VX+
YIDMNfwyEzkqkUjIZgazmXG5R1uTnD/KvTLuXazoy7317BZdiWe3eDLLzguclDaqT9xOuu+4dyvv
vA7+CnmRnsfcF8mK6MvZWM9F36VuhHPRvWi+p/dNd71maYf7o9Nf78tufUrfoNbvFJOuQN4QC2fA
EvRziJPxOhfOm+pbZx98T7Cdopuuc+RmEBsF6L9DRH2k6M1Hpx1RkaqazpPM7Ofwwym9ltJGREt3
LJi7agnYi7a6cSp4kR2wh3rM+ZQdpIDcuIZdY52eT5y5nEinsAfN43w4DsnjnGrKsbMK3AF+CH6E
nQPgZvBB9qaP2GeXKXrvwY8Hl5NdT7IH/ULPb25LTnEfBfxSsBgsAMu1VG9e3mH8n4VmXbCT/2NB
cyPjhugsD7AYLADVwutojqHWmyoRVEkflXh3EhWDOOs+CEbAfE6GIzl/9uBOygnWbUb8vE1baDoF
mktdJII6ikNYvjrApWAxWACKNe9avZP67xAz672GUutirM0Fh4LcT90Uxv4Q/NIAl4LFYAGlOq6H
1FfuSuWTrvSfBweofWq5Aap/uCM4JeoHpxunvnEBzgbzwcEgsaQnN78O8/4TNHtobvSu9tYLf8x7
T/B55DsDzAcHg2vB6zTeKF2HZB2SJ/Ws67yqKzT0n5ylm4D/AT7I2TKde1Anzq6tOBVPIaIeJGKn
6DnQ7oHlN+Af4va6hL59gvwTteNG6P8+lbhXBDgbzAcHg7q+rtFeud/VO6z/kol5XRH2AaxdDM7l
hDCBdZTC+eFnxP8sSj8KcDaYDw4G16Ij/nSv0la89/S5oqDqLKfWcvgUPHASL+3xilkLTbTUIDfW
g3pjdQ+pxFupPXGXwh+Dd4kTF/1x3hFmwaDeXrfo7VW8oVGx2Z1A3zRiLfjl9Hw5pSaLdgUv9lIE
LZ0vr7F/m/DzVO5dRSR/Aj4U5FLNPKXk0kJ0JqP/Mivuc9bRxWTUjmTgmfBvawaWuJJa3rvMyzps
cnt1nsXyfVhrCb9U779yw9XSfDRLFZNXaoQnW9y2fo1lnpkkmWz/B243BazQw6ygN1kdN4Dcjp2F
WHgJa5b7uNQqxc5b2jeX51QuN2KZC91D7+Yu/IDyYqEc3MG6Lgd3sFrLwR309g3hn6bFZXjpjJ4B
nBfITutBl769rXdk97fgKEWHJyfORv8J3e9YxYXwb6L/InWfZqUXqMRPaDbw70X+HvplYH9wrn9S
MWmg7nTo/E4jJ+kK+IZgO6ydQX8afa6ju4PbQJ9Tudd5qcSP8rb2zTuqs+82YO2MM/dN4qHE26Bx
onL30+BOrU8si7njdGJd99Q9IqkXc/chM3Wj8n4dr56UnmLPWq43YolezQndtTSpFzvLXF1Nkq9W
gGvJSytA3UOzeY7UEvk+5PuQH0N+APlHyAdh7RNaMTevceyMO8Dl2q5XpiPyeR7rLObGPY89bobq
27/X+7VkucF4+Cv6rHmpk961/Xqs+nJW9ypF8eQm8sx19ERxM6UXcy66WE8+kg/PshZmkzG0dDxY
EGQPrbWLvPGO3rtFZybymfSffOU/IvxS+nyre4XgbxTddPz/GiP9mNkZjc7tgaZKmnAPel/H6F6q
d2SHp8qOubXt5ta2gZz8MH5IY95bcy97nmhp5Eku8pOp9RUnhFf1Pu4Nd+Vm4U4hx95P3fup+xR8
kbZlf58WhzAvL3LrH8aIfsENdwcrwkXytN7K3Zb08w70v6BFeuVNgh+nd3Pnp/BG5z4sdAB/oucl
OTfqqlzuXq77Aj38jDg3t+mbiYSejP06p1TGNVDt+KPAsYruXHchmVNXxA+U98Z4Y+iV+rMfOubz
jpVkM09LnQd0F/NC2KmP/5fTw9/pvdvZA39Mb+vO9fA99bbuvMJYLtGeeKwg93a3sUjm0P8JzjHB
RxyJBPewfsrj/5Yz4V16W5fRaX+u0Du7MxmbDwSoPqwH3q73dG85+GO9Rzh/17H7DfFANnfw/dTK
0Xu68x34VZRW0J+/0sPFyL/ks4x09YzfnNa7goMZ7wiwQ3C21F21MbU26c3d/qPe3J1f4J/GPD8s
o4d3gdnMzpPMY0RnTaJX0F6IJI1+zuQWUwh2Mzw3lELWWiE3nUK9VUmp3ES8azhRv4vmY+Cb3uPk
Q+XDYMQgFiJYiGChJ5rl3PVaqsRtiWQXkpmuzHiIunZT8Anuyz/kvvxDbmGduN89r3cliQTRtxNo
fkSLDTl/tsZaa63rdod/1CCSR9Wa4ErkGeCV7OziGW8boxvuyq3QmYXNTtg3o+sKPqx3T+k/o8Bm
S2y2ZKTljLRcfeXerpb97t528DGNIiy8ZhD/DIHvhR+6+VF8pdib+/sevb/LKKL67MvdRrtRVtDH
WDiBtajuVtoryTyKL7hXC97pThT5GDIq92W5X2vpk2Aakq7uJOHzXe1bayTkW/dK5uJz8EtFZ6Oi
t1nRbQ0+qnW9NrTyHWxmgZ3B+VgrML7CwjGwOR5+CLxPM17SevVAchx/nuLedy9P6e9TPsln17tL
S71r8PBGNLvD36180nq1lhzXk4lXyX2wE+MysdGRWe7OvMyCT8FCF3Re0ecDTo76301lFl4jNq7S
Xcw5qKNzFsLXhx+Pzj6wNbUywBRms6HW9ebpjHvzkbdD8yVm+Unl7c+RdPI7gNM03tBsrLMpcfI4
OVBxKzZL4K+mzyn48GGVi+YpenuKFcon9VUvWyHLqXoffqF+lg1mVr0Efy1YoJ+SB6Uvg/PQHwtv
sBFYiNzUXQS/CGsl4CdIPoHfjY7I7duq9Iloa/BxcDTYDdwNjlcM2YpWBZJM0FJ0cuGngwvASwNe
PzXYRd0TSArBW6n1DHwKpWXgaSS0YvdFcgze2O9C6yfBjyj9GlyJNQedLLA/8k8DXvtQhGQhkp7w
VdRqAX8QXA2+CR5BMwp/Ct6HrwQbgfsrW+jJkP6gb/1NJY7xTBqYqpIQow7dDm5Bvhe+FNyKjvHe
bZU3i4X2Zi6Ut7uBc8C5ZhbgM0ELnA4uqNTT6bvG/yoJvQqeoPQDLM8wo4O/3HgenUp0rjJjQVJG
rw7CbwvGcjPjSpa6Y6k7TiUW/gk9gmZmZZxRzKTnM+ntTPqmWIjkBHgEyVWKluHTwFTwAC02A9PB
68HPaMtE4LPwfwFTK28R7Ad/GTM7ycSkyu1F8K0q9fb9IXxn5ESFnaToE2n+g4ruciycVQ/49ynv
bWSuFxjPVL2gnzai/0sTG1h7lj58hc7X+Oo2XZWyphoR/4pTzSyfPa4rjpGODtAG0wUvB7uB4ykd
j7XxKhF/qrwH8kzQCjBd9wX46QGqZhxv7wo8n84szAGVv1XlzjOUVlDrBnpoIryCEeH/0B4zI4z0
RRPP8MPQWYKXtpvsob5yd+Axs35T4NPwzGr0V1fepE+l4Edj5+fwsxUdVrGTRQSewm+FlDKboSuR
H1Efhs7QZx/vpTKiZLxUqShxZXgdI74K/RI0cXhXgOnUnYMd1d+Cze2UvgziT+sLRn0YnA1+UHWZ
4FnGWAfJ6/BXwqcza33gN9PzQ5Q2Vl4yRpFIbqL0AXAmpXPwANHuXA9vVnqqesy+FrlZEe+DL2D5
bizcjeWdgZeUN5ltE+t6Dav1M2aBrBJy8fyN2DGZcDP416p26kn4jSYHojkZze+ZHEgr25Cz+twJ
rJ318F9V9ZR+mn1kHtnmQ/WVeyN8D+Tl2PkKnkxoXwS2BDPMmkVnPfhWkJ1uEGSnCG1AZ4lZ0SAZ
wJ6Gl7qiswM0eYO4tdkXxKtyp3BY+6GXwJGgyRXNwV+DP0c+Cv4WcDgR+BDyl4O9QON5YsCrB8ze
MQh9cog9xOwpzKaP/xuBheAWsBQkn4deZ76q4N8GT1N3q5kveDwZOgafC8bx0kn4epSuhM8C+1ee
1B4i/xSbU8GFYEmwfk1bGvnrifyTrIj+YE/kq+E7ov8o1th3QmtpvZLYYGcMkcmdxmiuJFrgQyfJ
xjvhS5APgDd5ldn3i4mo+uBjZBjOJ34TrJmM1J/evlk1Sz9jwkJV5S8Zr2BoHXiaPNyXTLIQvBPN
0+ThuozF7FMpQV5NJ7Y1M3RB0gXvdSGrnEReDz+sDFBzr4NmVoBqoYjShQGms++MwIfp9FPzUjql
m8A3qduHZ4wVPMNP40ljmv+GaNYNvl2j307pyHdyzvJs+Vr9lmNoi6JdzOe/a7l78oQq9BdXv5nz
LjcyPm2xu/sX60rnE5zNytvvwR93d3NX5TMvPZ9bA+1mOi/6RMJp4eZp6+5v9YyhvF3ufqnRqOgc
dxdY+nxJNK29iqEEtXopesU80/DBNu44XZtYKHLl3OsMwsIZLfX7Uasv2J7vJ5wCk91UnXHnYfWY
s0Z1lLcn6L9wsUcoOvnOPqyJprVBMZRhaiHZrugeVZRRKM5zntZRYKe7PlWw1xk7lA5Q9CZi4RS4
D5wMLnb0eU4LRbvU0dt9ut7r7VNIGngD6ad+i6yuSqztylt7FUVf+Q2q73XBTjq12jr6/b1mzgyd
fWcefSvRZ9rUWgx2RtJc9b1V1DoQ9ERLByCZ44zVbIO8a4D6PSI3sDZPvUTfliofKqM/jh1S9Cr0
V2/gbdtWSWgVpfoN5Hah/XxjVr/V1seeLNhan7rYpfYzmnXtX2jP7d/pulbefsJ+QnC8rZ9u26of
KgT7Kjr3ojPd5ruO9lTB65wnBV+Hb+W8hB3hQyfQpK59K3Wfgb8Mayc0SkN/ovXT9mW6lm2NigF2
I/pZX+Pf5lN+2xfJzfYlupbta3Qtq34oDt6maP1N0XGw0Atr/e3GmjPtLdhU/qT9qe4a8CVoRrFQ
Sd3vwh8E3wuph5fQh8Oh74lmm5A+4ZS8KJIzIf2U+WyoQvcCu63mVXsCn9rrL8seCZVpfxRDN9sN
VWIv050r9Bfdc8E0sI2iWBO0PoWfCjYI7UNzn650+L2hsbqbYHNLaL7gtNDHuh9pT6zPsPA37Yl9
xrL0W+juF4p+Cvyf4evx7fSL4b+P/FUkYsf9jS823YFgd/CoonMIXKjo1UV+RtF2waeRNEfnJ4r+
LjRbgFFKM+CHwA9A8yAS5O5kxaQm8NdQ+g5YgYRWnD/A3w0/AeyDZCI4RjFEb+2ulL4PX0Z/fHQK
wWJK18K/Dv852Bv8MXJG5JylrrG2CXwMzAM/RLM9PONy/k6LP4NfQ392goeR/BZrw6jVEc2NyK+C
XwQ/G58sg38QfBG8llq/SZLdx7/CzI7y7lGwysyR8l5dJGfgbzJzhORZM1PKOz8Bh4D5WLvTzBe1
ksysweMT/5iZNfQXggcpzVBMaoLkHfp2HZpPgcONf2j9B/TwXeMTlcieqLzxGH5254FdaBFvh76k
FE/apVgg6rxp4Dr054LbwRjIqF0TabPp53j0r8YCPvfC9IH4sZsRexehfwCdV+C7oWli7BYwrJj8
itZN/g79dNDpiYW3wBTkVzDq5nhmI/rTKWWNuDuo1ZS28K0zzaw7fLiLuvjWnQxeg5030GmLffxp
30zdJchZZZ6J1QRtmZXYxMQedj6AR9N+klpH0PkVaCIE7zkjTSTT7lX4apFi6EskL9CWicMbwBvB
26i7Fb4dFjLBz8CvkT9BW0Phf4gdxuXRutcBzSnYmQGP523ygzsfHA32R8e0+EfQRMjblN4LMi9O
Y1r8KYjnk5C4J2hxLHKT01iDrlndrFzvEiQNQDKDQ1Q4WLNNpiKr2F+gT113FPgyWITc5EZ4ZwuS
9fD7aJ24clg79nFqEXWeWU1mRCvRqYP+LCRm3lch7wumgvTZIWf6Bdg0vSIq3I9B1pRLbITouf8I
tR5G/zQ8K9EdB+5Gzpw6+N8bhJwc5ZK1XOLBJqu7ueAK9CuImQnEj8lXxSC5yGMdOY8hMZmznLpm
Tpl3h5nyiSXnDpC15kwFid6kzYrJRIXH/uUR7T7eTmLsPqUu+g45yukE9tbWLUvvIO5vKvXTooFg
d/CoonMIXKjo1UV+RtF2waeRNEfnJ4r+LjRbgFFKM+CHwA9A8yAS5O5kxaQm8NdQ+g5YgYRWnD/A
3w0/AeyDZCI4RjFEb+2ulL4PX0Z/fHQKwWJK18K/Dv852Bv8MXJG5JylrrG2CXwMzAM/RLM9PONy
/k6LP4NfQ392goeR/BZrw6jVEc2NyK+CXwQ/G58sg38QfBG8lrpXULcKnZvgn6U0H/5O5EkgY/GP
gddR+hQ4HPwBtd6l3TR6aHrOeN15YBfqMurQl5QyIruUusy+Nw1ch/5ccDsYA00PzYybcY0Hr8YC
Y/fC2GQe7WbEwEXoH0DnFfhuaJq5vgWkVjKlyd+hnw46PbHwFphC6XR4ItPdgU5TLOMZh/47b1Da
Fjt4xr4Z+RLkRK9nYiCBNRPhJlY/QI6O/SSSI5T+CmR2bPzgjARfwJqZxxvAG8HbKN0K345ameBn
4NfIn8DmUPgfYoeee7TidUBzCnZmwOMrm5XlzgdHg/3RMS3+ETRz+jal94J40mlMiz8F8V4SEvcE
LY5FbrIB0euadUHMe5cgaQCyphzm0cGabdY469H+An3quqPAl8Ei5CarwDtbkKyH30frRIJDhNvH
qUWceCbmzYhWolMH/VlIzMyuQt4XTAXps0O28QuwaXrFvLsfg6wCl9kP0XP/EWo9jP5peNaOOw7c
jZw5dfC/Nwg5q9slEmwyoZsLrkCHqHZNJimHNzPFbDr43ydCnDtAYt6ZChJ7SZuJf+baI597xKqP
D5MYkU+pi75DfnA6KVof2x9Z+lRks5Q2Nc8xnCki6cW9O1efNjjzeJKQRekc/bexTrp+P82ZwbMU
WyX2X5FPUbl+wcLSf22hkkGK3nZFtw3yCurmU3pI0R8Jnwv2wlq50aTdAcHTjKaWPqPQu+EcJI8H
Tzza8G/r9ClKNs9PTvM8JIVnIyXI52tdeyuSXEqfg7exUA6OBosYe11FewIe6KdPSOx1PLVoD9/e
eUvrqo5VxfOKy4LnJ4LWn1XHy8ROX2p15wlJZ5WELnNnibxh8GykhGcgJTwPEax8tkqfU/Wp2qy5
F36A3m3trcqHboUfSGl3+JXwu9EcB58M35nS31PrMJIGxhqS/ZV602+FTgNqtQWHULrTIKWp8Kcp
fR4LTZH/DnkH+BaU+vD3wP/C9EH50EemD5SOUb6yb9VJiYRmSBZbjQX3wM9R3rmEu3yVotMVPI7k
NPwMNP+k6G1XdEPIbbCE0mTFUAV8OdgWfQudKWALcBKlo+nDNPgh8EW0eASdsfAbKB2BnTrYXw3O
D3quPRmOZBmSUnAyyEidXpSGkUyofJv/hV0tr6rUJ4HpWL4/6IPK9+ocOV0Vrb3UXQROxRpPPOwD
SPqpjtusUr+r1o3SmytfEqy0oiKvj871KrG/MH3G8jztg38lkpXKh6Yi71v5usan6rtrKN2ppTJ2
nZ26WO6LvBE2n6H/V1Sdln5OpLd/o297tJaXz1gOIp9L1I3XWqEOtDUWPgM7bSvP8AnCGfUnOFlR
TlOKZUjS0DkI30DR+QG9as+sraOtMVjOpYdlir6Lb5ubCKnqr1GnOnYDlejv70iGZJW59XUsfiP0
Dyrv9UCnLpKBJg7xdhqt1MUzDdRjoScY9YBKfTY7gh4WwdepvF1jrFKfdl4Gxml9Hd64FX6IaoYq
qNUW/iSa67AwFf4p5DvxxibkzZCcoLQQyR6sFSLphuYxRck4zJeJQ/ofZSx/pg9lRIKJ5Gk6arkF
7MNLzDs4gZmqQL8SC21oqzOlbYmfMuQdFSW/67xkBTqKB4iB7VjeavwfeEN73p2xlOGrhsjrgQPQ
HBG0e4Z1cYbYO04kGE31WxPlJbaPE8mqcyc4FcntaKbSViqam6m1Dp2Z4DJK48H6zZSx+PR5CWP8
AHka+A79SRhNxnu/GbVqShTx1JqI8gOvziOq8YZ6JpTA8nPkgVV4b3XQltrJZKYamkxFrXJqrUaz
kmhvi+YSIjNFeT/DuoRIe5sZ1/7PMis6WCNqbRBz1BTMoYdHg4z3X+x9B5QVxbb2rqruU2e6++wZ
hhkYhiA5pyGMJEkCkiRLDsKQHRBhAEWSCBJERZLkJElAQERAkuQkSURykpxzhhne7j2tlxl9v9zr
vW/96//fOmt9u6q6uk7VV7v23tXdp08a9jXut+z01uw4Oro4cS27rZG1HMu9KsRnJdpVt+WBfJX4
OrRmvWrt+vRntSldn7XuMtdhO6AS19FwPreG/JE1fxXPpjvGdYm2kWv24/J6zPxoF8kurWJb4VqV
xBmZy+jnoxl51OV5vCcYP2V8yi1X4Pkqy5iZsapXx7Vyfb15dC3bKNdmkj6s4tU0h7XiKd/Jfcq6
+pT1+SnPhZt+yLz197xYGi5xRz2BR1oq0YuxzbnOs7PaRc1apNnLqItcszUj+zi46eohxcDH2Qbe
ZhvoWph63M8SrKUFWYf3slazLaKaM7imW38Rl8dyzcqcrsblM7nnBzi9gMsrJexn7MKr77Ybk7vf
kjDu2WmerzruauU5fZ3HlTnRryVs5Pv14W5vuecDeCwZuWadBI55+Nx0kIHajPRmltLxX7stA/B7
3sBwf6fjXWl0ESwut9xyALckoYn7lHVCY/dJ+AT+PUiCxekoTkdxurD7nHZCEfdZeirvwuXzON3C
fX7MfTKf0ps5fZ3TV920+yseOnel+5YbLi/iPg1I7cznd7Pc4/fbrHbR/R0BgPs794Qw99ccCWHu
70ESlvhi3bfc6A/ct9y46fg1bjphgO8z9y03+qbbvu+si/oGp4+67euLnH7C6cQ6tRkLc82WjK3d
9964fYs/ldhn3xdcfwanE8+6zH2+y+VZuTzERV2WR5ef8QaPdyAfXcqoufxlrlmev+sql+/gNgtx
SQlmJrHkMR9twvWH8TfuYJYeM/bjby/HNfPwuW7NgpwuyOlCvm1c/pDTebidxPLs3JP6nM7F6Ubc
zkEX/ZrT/CYfv5+PNuGSodza9+47cLiFl7mFKE5Hcbqw+3t5qv8Tp1MxhvNZFbnPhbjPrXiWJ/NI
7/FR7ptvNpe0YNzMeJePpiYsoBdxejG3uZbTw7nOt4yjuHwpp/dx+o7bQ/ctHNRbVw8L8315Ff+M
08ybeyc9ISr+ktufeJ4L9847ldx2j8avcZlMLEnox5iRkc/iFqLiN3FNPjeeRx0/mdNnuc2NnD7A
6et8lDUq/jCXXOB23CdwACwxxH8ZVMx7XWMhrF3XNm9B39iWcZ1hCdDOr26d8hmBdhbPnkE4OOCD
dJAFQiE/FIXiUBaqQgNoRm3UhvfhA4iBDvA2dIfBXv0AaEgPWSElFIBoaqUcVIOG0Jy+tQ70hgFk
OTpCF+gBQ/g/BhPPQfCTzcgGYVAQXoaSUJ6scyNoARLqQh/4ENrAW/AO9IShkApUlVq1KkPVOjVf
zwit6tWplhHGcSup+Z2hL5Ftzk4tRkEpeBVeg9ehMbwJCnJDPegLA6EtxEJXeBeG8TlBkBFygOvp
XoEKUAPywMdcHgEhxEMmiISc1G5hKAaloSJUhprQBFpSv/PCG9APBkE76ATd4D0Y7vUgBdiQGdJC
LmqhCJSBSlAFakFTaAUm5IP60B8+gvbQGeKgl/su05hC3WJUfcbmjG0ZOzP2YOwb0zI2Tn3EOIJx
AuNMxoWMK2JadmujNjBuY9zNuJ/xCOOpmJhOXdR5xrsuGpIxhDEDY17GEq1jO7QzKjFWZ6zTuvPb
nYyGjM0ZWzN2ZOzC2IOxd9uuLWOMAYzDGccyTmOcx7iUcS013NLYxribcT/jkdjO3TsZpxjPM15l
vM34kDHBRdOIfTsm1rQYQxgjGDPQwa5mVsbcjAUZoxlLMZZnrPy2204NxnqMjRnfZGzLGMvY9e2u
rTub7zL2ZRzYxS0fxjiCcSzjJMYZjHMZF3ajOTKXMq5k3MC4jXE344FuHTq3NY8xnma8yHid8S7j
426dYrr4gNFiDGPMwJiTsVC3bgWjfKUYKzBWZ6zH2JSxNWEhXyxjHGNvxoGMwxlHExb2TWKcybiA
cSnjasZNhEV8Oxn3MR5iPMF4lvFyt+6tuvluMt5nfOqilox+RuzWvUs3HcYYyZiRMTtjXsZCccSk
LsZYmrECY1XGWoz1Gd1oXJLtCfsnpKJ1nhbS/UspwS8O/T+jSRbDJCuqwf9vyxmcS0wLsnrJMfCC
qMjO2fzO5b+TEmS9/xxDXxglz4ikVt0cX+1x/YMbJb4wpnhhTP8HDHlhzMg9VSzFc+iO4Pky/EtU
5KlSQcQ/mUrNKUn+KfM/JbNA1n9KZoPs/4QU5En/Gv+aE0Ee/K8x+IUwiqKNOPL6o2EmLIVNsB/O
wl1hiDCRVRQRFUQ90VrEiYFitJgplopNYr84K+5KQ2aQ1WUvOUxOkPPkSrlDHpGX5WNlqUiVW5VQ
VVVj1VH1UsPUBDWP1qD7Xf5EnVU1kuVbJcsPT5b/9Lm8key4j5b5IdDiubxVJGnemZH0fLyftP2w
xknz4ZC0/fCwZPnsyepXTpZvmiyfbDzhR5LmU+VMlq+VLP9u0v6nm5b0ePrVSfPZ8ibL538uT+sv
W8FkxwdwXpJ9CE0cYY5aiTJn4sgN0rlUZKuye6V7PXnEk2c9efPPaude4snVntziyX1Je5EHk44y
z8qk+QIDktYvcCxpPmpn0nyhZcnyK5LmC9dLlq+fLN8lWb5rsvzY57SMEtHjkuVXJq0fnWyW/nB8
d7L83mT5fUlnsfhuQiRmYsQYaCsmsbVtRR+glToahBlipmBfEQo+pwpucSrjJlyHG6jEJ66Ja1Tv
prgJQtwWt0GKe+IeKCyH5cDAV/FV8puuPkhVUVV2v0+GynAqcX9BhG5/VIDOzE/5VLQb6QqTYAuc
gscijPrgp16FObVBOpWdOoRVnLqEVan3IWSTM9JuoSDteUrhRVAyhPp0ieUWpJ2WDKf8FZZb8ABI
yh0i3IJHCLfRWF0NjYTMeIr6uo6O/spyC54muYHyZ1huea7mWa/mOa/mea/mBa/mb/2txv2tzv19
nfv725EafKQmH6n1/BHcwT3cyT3czT387chePrKPj+znIxK0pA8tM1u6T26HyBBiNZxYVU4l5zVi
fR2uAx/1aQMxpaiGezcy0evT0qLzW/J8Ac+UEI/FY5q1Z+IZsWVKinu4XZPb9XG7WkbKSPDLzDIz
BMmcMidYqjLNpm22MluBY7Y2W0PAbGu2BTTbm+0h2OxqdoUQM86MgxRmD7MHhGJGzAgpMTNmpjFl
xawQjtkxO6TCnEh7PsyNuSEC82JeSIP5MT9EYkEsyO/lLgzpsCgWhfT4Mr4MGbA4FoeXsCSWhIz4
Cr4CmbAMlqHZcfUtC+tbVnwNX4Ns2AybQXaMwRjIgW2wDeTEdtgOcmEsxkJu7IydyVB0wS6QF+Mw
DvJhD+wB+fFdfBcKYF/sCwWxP/aHKByIA6EQDsbBUBiH4lAogsNxOBTFT/FTiMbP8XN4GUfhKCiG
Y3AMFMcv8AsogeNxPJTEiTiR9HMyToZXcCpOhdI4HadDGfwSv4SyOAtnQTmcg3OgPH6FX8GrOB/n
QwX8Gr+GirgYF0MlXIJL4DVcikuhMi7DZVAFV+AKqIorcSVUwzW4BqrzfL/O812DdGUT1CRd2QK1
cBtpS23cQdpVB3eSdtXF3aRd9XAvadUbuI+0qj7uJ61qgAdojTTEQ7RGGuERWiON8QSegCb8Tuym
eANvQDO8hbegOd7BO9AC7+E9cN/zPYDWxwDSpGARDP1EpEgP/fmfUQeKxqIpDBKxohMM4X9DHSbe
EXHwsRgmhsFnYpwYDyPELXELRor74j6MEk/EExjtGhkYI33SB2OlIx34QqaQKWCcTCVTwXiZVqaF
CTKLzAITZS6ZCybJgrIWTJZxsjuslT1lT1hHcUQvWC/7yL6wQQ6UA2GTHCwHw2Y5Wo6GLfIL+QVs
lTPlQdimAmR/nqoiqggkqPKqAjxTVVQVIdVkNVkoI86YLgwzxowRhcw2ZhtR2GxnthNFzA5mB1HU
7GZ2E9Fmd7O7eNnsafYUxcyffUNEcauu1VLcsAbbQiQ4IU5F+Z7TxJkiFwVaBzrKO4F+geHyMUr0
Kz9mwkwqGLNgFhWC2TCbSoE5MIcKxVyYS6XEPJhHhWE+zKfCsQAWUKkwCqNUaiyCRVQERmO0SoPF
sJiKxBJYQqXFUlhKpcPSWFqlx7JYVmXA8lhevYQVsILKiJWxssqEzbG5yuz+ObXKgm2xrcqK7bG9
yoadsJPKjm/j2yoHvoPvqJzYHburXNgTe6rc+B6+p/JgP+yn8uIH+IHKh4NwkMqPQ3CIKoDDcJgq
iJ/gJyoKP8PPVCEciSNVYRyNo1URHItjVVEch+NUNE7ACeplnISTVDGcglNUcZyG01QJnIEzVEmc
iTNVKZyNs9UrOBfnqtI4D+epMrgAF6iyuBAXqnL4DX6jyuO3+K16Fb/D71QFXI7LVUX8Hr9XlXAV
rlKv4VpcqyrjelyvquBG3Kiq4mbcrKrhVtyqquN23K5exx/xR1UDd+EuVRP34B5VC3/Cn1Rt/Bl/
VnXwF/xF1cWDeFDVw8N4WL2BR/Goqo8n8aRqgNfwmmqIN/GmaoS38bZqjHfxrmqC9/GBaurtpdzI
pwjb2lykzqZoJppRcRvRBoSx3FgO0hfviwflL+0vTavn32ONSXP/1xr/f26N/6F9kax9ud1oS3Tw
Hf1fHftfHfs36ZgwO1I8HyIyyyKqktEQ0kEJKA9VoQ40pv1CR4rfe1E8MAxGwgSYAfNgCayEDbAD
9sEROA2X4TZF9iB8wgl6F1RQt6C4oPdYdg/qxbJH0Pssewb1IRlHqb4s44L6sewe1J9lj6APWPYM
+pBkd6o3kGVc0CCW3YM+YtkjaDDLnkFDSfagesNYxgV9zLJ70HCWPYI+Ydkz6DOSPaneCJZxQZ+z
7B40kmWPoFEsewb1BklHBxB2DxpC2CPoU8Kef4ORMTzybkFjPWa+8JgZ5zEz3mNmgsfMRI+RSR4j
kz1GpnqMTPMYme4xMsNj5EuPkVkeI7M9RuZ4jMz1GPnKY2S+x8gCj5GvPUYWeows8hgZTePvFjSF
GZnJjMz7m4x84zGyxGPkW4+RpR4j33mMLPcYWeHpyvceMys9ZlZ5zKz2mFnjMbPWY+QHj5H1HiMb
PEY2eoxs8hjZ7DGy1WNkm8fIdo+RHR4jP3qMLGZGlrGmrGNGtvxNRnZ5jOz2GNnjMbLXY+Qnj5Gf
PUb2e4z84jFywGPkoMfIYY+RIx4jRz1dOeYxc9xj5oTHzEmPmVMeM796jJzxGDnrMXLOY+S8x8gF
j5GdzMg+ZuQQa8rpv8nIJY+Ryx4jVzxGrnqMXPMYueExctNj5JbHyG2PkTseI/c8Ru57jDzwGHno
MfLIY+SJx8hTj5F4j5EET1eeJTJjQSIzlkhkxpKJzFjKY+YiM3KdGbnLjDx2NcX9n0a333w1rSHk
EvvkVFVd1VRtVTvVUb2luqnuqqd6T/VRQ9RQNUx9rIarT2jvclqdUWfVOXVeXVAX1SV1WV1RV9U1
dV3dUDfVLXVb3VF31b1AtPs/SmKv2EtfMMX9da6qpqqBVDVUDVCqtWoDhmqvOoBPdVVdwa/iVBwE
qR6qB0UC76p3wVa9VW9wVF/1IQTURDURUqqVaheEBYoGivJVhkiwjAzGS0ZGI5OR2chiZDWyGdmN
HO7IqEf3+Oq6gIjnrk3k4etBsW4NOjOHVyPdczXyPneMmFSxVBuMMMN9F1hOIyfY3veGGeFGKiO1
EWGkMSLdd99RjX98r4SsEGyEGikN0/AZ2vAbQYZl2IZjBAw0go0Qw73eZdDY+lEX3HOk8YpRGhyj
nFEOkI5FQ4SareaqBWqR2qQ2qy1qq9qmtqsd6ke1U+36M8bdq2VqlppFLc5xf9es5qv5xPdCRXaU
mNtI33daXfm99VlUaz4dXalWqdVqjVqrflDr1Hq1QW38sznm1mer2dT6XDXXfSJTLaDWFymyztTD
XdS6Ow639fwQ9qet/sk4mLPTHmfueS+oXXyeqw10ntlZLoUPYSAMgo9gMAyBobSuP4bh/O+in8EI
+JxW+SgYDWNgLHwB42A8rfmJMAkmwxSYCtNgOlmAL2EmzILZMAfmwldkD+bDAvgaFsIiWAzfkHX4
FpbCd7AMlsMK+J5sxSpYDWtgLfwA62A9WY6NsAk2wxbYCttgO9mRH2En7ILdsAf2wk9kVX6G/fAL
HICDcAgOk405CsfgOJyAk3AKfiWLcwbOwjk4DxfgIlwi+3MFrsI1uA434CbcImt0B+7CPbgPD+Ah
PILH8ASeQjwkwDNSaCFryzqyrqwn35D1ZQPZUDaSjWUT2VQ2k81lC/mmbClbyRjZWraRbWU72V52
kB3lWzJWdpKd5duyi3xHTpOH5GF5RB6Vx+RxeUKelKfkr/K0PCPPynPyvLwgL8pL8rK8Iq8qS16T
15Utb8ib8pa8Le/Iu/KevC8fyIfykXwsn8inMl4myGdkgtyn7ZUylKl8Siu/ClK1VR1VV9VTTVUz
9aZqqTqpd9RANUh9pAarUWq8mqQWq2/Ut2qpWqG+V7vVHrVX/aT2qZ/VfvWLOqAOqkPqsDqijqpj
6rg6oU6qU+pXo6RRyv3fVmO/8YtxwDhoHDIOG0eMo8Yx47hxwjhpnDJ+NU4bZ4yzxjnjvHHBuGhc
Mi4bV4yrxjXjunHDuGncMm4bd4y7xj3jvvHAeGg8Mh4bT4ynRryRYDwzA2aoLqfL61d1BV1RV9Kv
6cq6iq6qq+nq+nVdQ9fUtXRtXUfX1fX0G7q+bqAb6ka6sW6im+pmurluod/ULXUrHUOfNvRpR58O
uqN+S8fqTrqzflt30e/orrqbjtPddQ/dU7+r39O96NNb99F9dT/dX3+gB+gP9UA9SH+kB+sheqge
pj/Ww/Un+lP9mR6hP9cj9Sg9Wo/RY/UXepweryfoiXqSnqyn6Kl6mp6uZ+gv9Uw9Xy/QX+uFepFe
rL/RS/S3eqn+Ti9z//tVf69X6lV6tV6j1+of9Dq9Xm/QG/UmvVlv0Vv1Nr1d79A/6p16l96t9+i9
+ie9T/+s9+tf9AF9UB/Sh/URfVQf08f1CX1Sn9K/6tP6jD6rz+nz+oK+qC/py/qKvqqv6ev6hr6p
b+nb+qF+pB/rJ/qpjtcJ+pkf/ELP0rP1HD1Xf6Xn6Tv6rr6n7+sH1rvWe1Yv632rt9XH6mv1s/pb
H1gDrA+tgdYg6yP7fbu33cfua/ez+9sf2APsD+2B9kf2YHuIPdQeZn9sD7c/sT+1P7NH2BPsifYk
e7I9xZ5qT7On2zPsL+2Z9ix7tj3Hnmt/Zc+z59tf2wvtRfZi+xt7if2tvdT+zv7BXmevtzfYG+1N
9mZ7i73D/tHeZe+299h77Z/sffbP9n77F/uAfcj+1T5jn7Mv2JfsK/YN+5Z9x75r37Pv2w/sh/Yj
+7H9xH5qJ9jPHHCEIx3lGI7p+JwzzlnnnHPeueBcdC45l50rzlXnmnPdueHcdG45t507zl3nnnPf
eeA8dB45j50nzlMn3klwngUgIAIyoAJGwAz4AjrgDwQFrIAdcAKBAAaCAyGBFIHQQMpAWCA8kCqQ
OhARSBOIDKQNpAukD2QIvBTIGMgUyBzIEsgayBbIHpgYmBSYHJgSmBqYFpgemBH4MjAzMCswOzAn
MJfvPvMVWb4y2k9OlWRB+XrndFWV/Psv6nXy7wdVY9UEDqvmqgUcZR96XHVRXeAEebwP4KQaqUbC
GTVOjYOz7NnPsd86z37rAvuti+y3LqllajlcZg9x1ShulBDA102laZmWKGiGmCEiiq+MFvL96jsv
LuqCuoi4zldJ71iDrYlSWrOsH2Rqa7v1UBbia6Wt+CrpbPL2tyGIooPM5PNrUAQ0gTzAWrLO9BX2
IJC4nVMLOOXeowmBVJDO3kr5g/Y2wsP2dsKj9s7f6x6k1HrwUywRARkoAsidePfIPuyW20cJf7SP
E+6yTxLusa+5Z2K42yKmclvE1G6L3FY8t/rbPZogym1Gi3Ar2kmOBPORED6SIsmRCD6Sho9E8hEJ
QTRrBWnuikn335JKypIgZSVZCZSsIquAIWvKmmBao6xR4LOWW8tBWzetm9SeNOfKn/5DPjaph/1/
27/+z3hY14e+qN/8T/rMUN1at9Xt9fvkgVzPWZF8ZnX2ZrXJM33KfrIh+UjXOyb6xjYv6BV7/4U/
/KM3HE9+8B8e8Hnv8n+bN/zd25FfHEf++3mvWI6iDzf2SIw83LijFkUej7y44wlFHY0o4pjCMcdU
ijgek9bWJ01t4erlb75TdkrqN50QJ4UT6qR0wpxwJ5WT2olw0jiRTlonnZPeyeC85GR0MjmZnSxO
Viebk93J4eR0cjm5/9TbDvpzf4tBaKH9Ql53wR/9LgZjCKb4g/fdam+zt7MP3vmnXvgg+eHD9lH7
uH3yN3+MqTA1++Rr/61Xjv+jX8YITIOR/5J3TuKbnfj/Ae9cQ0gRTlvZSJETwkQtUQ+y8J3SnKK5
aAN5RDvRDgqLDqIDFBFviU5QVLwtekEx0VuMgQpigpgMzcV3Yg+0kl1lHPSRPWQf6C/7yQ9giPxQ
DoaP5VD5CYyQn8mRMIbveY6XYyVZe97jT1GOCoWpKkyFwWyVSuWGOSqvKgCrVZSqAOvY4+9nj/8L
794OGDOMPXDZTGGmEBHmffO+SGM+NB+KSPOx+Vik9RFdIp1vqO8Tkd73mW+UyOwb4xsncvgm+CaL
PL6pvnmigG+Bb6ko6Vvm2yIq+Lb59oo3fAd8B0Rz32HfUdHCd9x3UrSi2CBetPE9o9hggI7WJcUK
/YouI9b6c/lzi/X+vP4CYqM/yh8ltvqj/dFim7+4v7jY7t4/Ezv8Zf1lxY/+8v7yYqe/kr+S2OWv
4q8idvur+6uLPf56/npir7+Bv4H4yd/Y31js87fwx4if/R38HcShINr2i8NWKytGHLHaWO3FMauj
FSdOWT2sHuIK+dmJ4ir52R/EPfKzD0WCLe0mUtvN7F6ypTPVOS37BT4JTJAbE59vod3oQr7j0ky0
9UqWPVcioAT4vNgjO8U0Rej4LPq4uJCiglks3dwaL7eGcsfp4z5lk0fkIa3JL/KTuysmilGbr4nX
yLlUE9XAEOPEOH7KZhu0NCPNtGY6M72ZwXzJzGhmMjObWcysZjYzu5nDzGnmMnObecy8Zj4zv1nA
LGhGmYXMwuJnsV/8Ig6Ig+KQOCyOiKPimDguToiT4pT4VZwWZ8RZcU6cFxfERXFJXBZXxFVDGYa6
rx6oh+qReqyeqKcqXiWoZ3+nzKChGJKvNBj8a4UUfDcrgj4K0tHHIOZy0EjzgvtcWgH6+InVEhQn
lqKPBaXpY0MFqAgOVKMPQgP6BEMjaEzxYXP6hEJr+qSE9vQJg24QB+HwHvSC1NCPPmlodUqIFMEi
BNLSGo2E9CKDyAAZ+JmGl2i91oKMtF4bQya+q5uZV2oWEStiISs/5ZBNdBc9ILvoI/rQmh4qhkIu
8bEYDrnFCDEC8tIKngD5aAV/B/nFOrEeCogtYitEiZ1iJxTm601FeOVFc0xdla86NeerTm/ytbDI
566F5eOnqUrKpsRYehkloyhyjJbR7m/EZAU6UlVWpcixjqxDkWMD2QBMin/agI8in7cochxiDQO/
NdwaAbY125oDIdZX1gIItQ5YByGVddg6BhHWSesMxdS97b6QibzIQMjqegjIRR5iOuRx7TkUIHt+
AKLIih+HomTJT0I02fIz8DLZ83NQjPZYF6A42fRLUILs+hUoSbb9Gs1V8rHk57FUkR1pLBmSjKW4
LE5H3BEpWYv2NAaPyOQR+SjOawyax+WnKO4dCOJxWTyuAI8rlMcVZi20FtOIlljLIC2PMSOPMbN1
wboE2a0r1g0alzvS/DzSKB5pNI+0GPnBWbRPmEO7jTI86oo86tfIP92HauSd4mmHknj31f2VY2se
UQF3jO6b9qCEN8YCXp2ctHpHiLG/l0kxTyymXNjv9WgF/AkHpSTxxkwYPLcm8+FjPjTz4Wc+giju
bQYWs2LzbDvMTcBqZDUCpJ15Xwim3ddImvPR1kRIR3uwZZDVWmH9ANG0E7sBpa1b1kNoQzHEYOhE
0cII6EXRwQIYQL7/OxhDvv4wTOY5X8Fz/j158F9hJc/8Kp751Tzza3jm1/LM/8Azv448+w1YT979
FmwgDx8PG8mf+2A3xTgRcIDimkxwgmKZ3HCeohIbrlN0kQJukY+PpB0AWULaIb0D4O4gobx7lQFq
u0/bQF37faci7KZz0ovxL1yP33b5H6r9uz5AK57VgqzztZ7Th4L/0AeoB6V/L5NQie/dh/1eT4Ky
Jlkz6TvXWdtIxx/Z7sqhUt7lJ/YkE/ehoNfL3/pagqzZv2Dd6cxwtoXAtlCwLVRsCw22hSbbQh/b
Qs220M+2MIhtocW20GZb6LAtRLaFwWwLQ9gWhrItTMm2MIxtYTjbwtRsC93fNm+gETiysloJZf/y
XpAUlgilXmYWuUUhUUKUF1VFHepdK9FRdBE9KH4aIIaIT8Vo+tZpYrZYIJaIFWKt2CR2iL3EzTHi
4aK4Lu6Kx+SAfNKRoTJCZpBZZW7iOFrkptHnJC7ysWxMHtiVzURxls1FCZYtREmWb4pSLFuKV1i2
EqVZxogyLFuLsizbiHIs24oKLDuISixjyau78m1Rk+UEM7UrjWVmBMvlZhpX4hO/7Uozpd9xpW+m
P8ByjR9ZrvUHs4z3h7BM8Kdg+cwf6kqKoFKyLBMs+Hs6ilxkjYIp1pCUy0vYmCION34hm0SjJE2k
MUYRvikKEbYUhQlbCYplaGxFCVuLaMI24mXCtqK8+/yJeJXwLVGRMJZiFkmjqkzYRVQhfEdUJewq
qhNOEK8TThI1CCeaYSBpvOGEy0336ssTP00MjZS0msZpEK7xU8xDY/S5T1T5NWGC30/4zB8EksZG
EZi/DOSitdWUfH4s+freMBCGw2iYBDNhASyF1bAJdsJ+OAZn4SrZF++eImlSBOl6VtKlgiJalCJt
qixqiHrExps0qlgxj9iaQAzNZ9lMLGDZXHzNsoVYyPJNsYhlK7LurowR37BsKZawbC2+ZdlGLGXZ
1p/elTTGDK6kUb7Eco0/I8u1/kws4/2ZWSb4s7B85s/qShpxNpZlxBSev6k8c9N45qbzzM3gmfuS
52wmz9ksnsXZPHNzeObm8sx95c6HP4wZD2fGUzHjqZnxCGY8DTMeyYynZcbTMeMCjGDgJ8sV2wrg
lS6C3Z+JuG8TrsHP9eeEQhwH8NUwkYp1LTXrSIT73W4rIs3vqfauJrm2l+zJWNYVRvcunQghCwUi
nPZVgi2RZPvi+tUIGCreEA1EI9FQ1BftrYbkARsnXpuW3WVfOUSOURPUV2oJPsV4TMBnZGUnW1Os
qdY0a7o1w/rSmkkWd721wdpobbI2W1usrdY2fIASFRpoog81+q1H1mPrifXUircSrGc2mT37c3uk
PcoebY+xx9pf2OPs8fYye7m9wv7eXmmvslfba+y19hH7mH3CPmWfts/a5+2L9mX7qn3dvmnfdrTj
d4Icy7Edxwk46AQ7eZy8Tj4nv1PAKehEOYWcwk4Rp6gT7bzsFHOKOyWckk4p5xWntFPGKeuUc8o7
rzoVnIroYAARQzElhuFDfISPMS2mQ/c+aHbeeQLvNk2KuqqRT+soYylyiKNdpSP70K4ywM/NIu8h
g3lnGMLXf1Oob9Q3EOpb5FsMKX3Lfcsh3PfA94BiRtovQWp3v0Sx1QnrHORyd00USQ2h+KGE/TVF
Dq/Sjv8wVKdd/1F4neOHGhw/1OT4oRbHD7U5fqjD8UNdjh/qcfzwBscP9Tl+aMDxQ0M7gSKHRk4I
RQutOFrow9FCfwynaOFDGudKaPwiM/qvzeB/ZJ5+myGL2QRmM4h5DGUe0zKPWXnk+Xjk0Tzy2jzy
ehwnNUjcfZr8b4OUrgruteXykOF5/U+uxf+9PibqDrWQgjUFWFMUz7CP5xN5PoN5PkN4PlPwfIby
fKbk+Qzj+Qzn+UzF85ma5zOC5zMNz2ckzVtqSOv13jbxud4jxbzeinXXPOspsJ4K1lPJeqq8cx0z
+LlzIygq+d0K/LbS2XLwKmBNNlmTNWuyP3EnLW6J++KJFw2kkKlkWplF5lJVzBizjdnO7GB2M7ub
PTETZsFsmANzYR7MhwUwCotgNBbDElgKS2NZLI8V/qu9M4Gnquv3+F77nGM+O6GMyZxC9jFkipIh
IYRooMxTpjiRkuEYGiSRVJKxWYaiKAkNopTUo0GFpqdSCKU0cNdZTfTUfe597/u+fe7n8/p/nPNf
a5+zz9p7r/Vb3/8e1iLMiGWEB+FF+BABRBCxklhFhBMRRDQRSyQQG4hNRDKRQqQR6UQGsZPIJLKI
bCKXyCf2EvuJg8Rh4ghRTBwlyojjRAVxkqgizhB1xDniAnGRaCQuE1eIZqKFuEG0EreIO8RdooPo
Jl4R/cRrYvA/T3r8577Pf9qTHvyQ+b1ogsQH2OfP+h/d1w5bIvDjuDfqLmQu9l063+7x+W/u0/l2
hw9cB66PLxt1poOdYwEV6Nv5AvAaewsZXRPXhp8wgnnW+ALcAV+MO+EeUKuCoeqtY19X+5mxr6WN
NriWsab9V2NfeRtt7Ot0PzWjH8yUfRVvjFn/1dhX9EYb3JZfGOwPxhjc5rG2+GcG+48xBvfSWFuG
7Hva4wfzhub3Cwv+mfEOjzXYa4010R9MZqx92b7P5UVr+M/5kV+cHwFYO+w/Z8K+3gxStj0ai+Xr
CCzs0Vg2YVuxDBj95GMHsWIY/5zCarF6GAFdx27D/Uei683/21ftf+jV+h95/elZkM/nSPjgWwY7
7sEM2bEA7OsmouiBfZ0FgKkwjsZhb78d+hlgB/R3AvYM4tkw8sLBcdDLHoUW9MF4pR/Nw/EGDEL/
LRhCfeYH6H8Ew9AfwdmzoOA4FdY5Gs4BfU6cPXIrLw7jb5yO5hThx2GMjQvgQtCfgE+EvjB7jhDY
r4pDXwKXhr4MDiM3XI49+wjsY6dCfxo+DfpKuBL0lXFljD2rigr0p+Ps2YB247uhn4VnQX8Pvgf6
2ZS5aCTZeRiFYk4TZI9VR4PbSxOjmbBHV6TNxSg0M5ore6xwmi/0/dgzE8O+Ohz6q9mjVtESaAnQ
T6TVYuxZluugf5YLKjMXDqNInEuBewUGuP25IelxB9APYYB+mA6jXnohvQ76Z+kXoF8PSRUQkpAz
KJAmR1CEB1V5HD5O+vNz1ujI4Jjbl6eDvzMIQAwCEIOAUU+xAsQgADEIQAwCEIMA9OwJQAwCEIMA
xCAAMQhADAIQgwDEIJ9LiCMSAYhEACIRgEgEIBIBiEQAIhGASAQgEgGIRAAiEYBIBCASAYhEACIR
gEgEIBIBiEQAIhGASAQgEgGIRAAiEYBIBCASAYhEACIRgEgEIBIBiEQAIhGASAQgEgGIRAAiEYBI
BCASAYhEACIRgEgEIBIBiEQAIhGASAQgEgGIRAAiEYBIBCASAYhEACIRgEgEIBIBiEQAIhGASAQg
EgGIRAAiEYBIBCASAYhEACIRgEgEIBIBiEQAIhGASAQgEgGIRAAiEYBIBCASAYhEACIRgEgEIBIB
iES+jlHybcQS8VD4LoRyMfEVJEvcm4N7WqJZ4ls64MRzWeKLYJY9DgCDl+TmoCkRFFyMhpGuHDxK
HIAKWFo4oObakQtI5VE5EvmSMRLoktJMzBpzw0KxICiinhgT/rMvMRmQ0qNWRhWawllgrT2gsvH5
HCCy8sWmtudGVddyWROnkSyqAMnC3+dScIBDcajDkmbO3DC+xWDQ/WXHbJL+raSACssUzFAip3JQ
FlJ5BWWMgoIjQny9fZhSiu5TpRg6OlpS833dQ4JCg7yYUkZBIcHTGZKkxOcPTxi7JCjElekbFMiQ
Jiezl1MERb4vtw0KYkoZrmL6BIX4MiNISWG6jhbJYJCkFgn/lgjT1UiGmjrjS/I3lIgFZEbvFvZM
VSwoKzCfB2cBgB3Cq+uC/9TrtxJXzNmxehnZlX8oWX75u+HtlgUVw3vypQwiF+Tvzk9xUVvRMscj
oudIWKN9W/+LrESJlJx4r7ILK9a4yd6cNLN9HEh7lnG+RsUrM9NHYdc1XeUavuOLFOpMn/IYaGco
H1LUOfhyXtycR/HjqjL9F7oeYUXmuaiEWz7fVe6hl2kjweCSE8o59DRVSeRP/Z3uQi6LaJ45k7Rs
17890JuO14vfqFloUrYxpkb3pX26VfGnA2sCmFYlIk0Z3IrSmONWF1+tKgsBzpkOI0s/7PXi4dp/
PdbBsfeE3rKJseHUtsEzxTHbh0uvRN88IBbiNPPS6VdcBTJkGUdCY5lUuGBCB06BFb8g9iAZu4+M
zYd7cxKgxmaSsTti+JdeC+71DcmWXRAldGz+lpHLeSH//uPH+ps6TmEfw+3PeGuTB3aIaHZXArnb
4eMHnFzUcrJ5LxvQUjekNOr+Kd3/ynGb8vHcuQ1uvR9vNenpLTk0w953WC5gVmPT4XZa5H1Gsn4O
f7Bf1bCAtYhv7cdrRo/GL5Gy7nJbW3JYtEFJS17ljGeewCb5ce4Fb+0lhqQbb04YsD0SaKTG+Ykl
/O6Jtz99wWB1n+3F6qfnyY9SDO4Nk7ZPFZvfOgnf1xfTSSlf+vro/QbHHs95F23tT5RTFAVGtt58
xZUSVbnjQqGW8uM1jw+GPwrLxa75zaq7PmNTp6HAQU0/cb+7mg/+kKA+PmhCbViirh04X4LuVsGT
v/lGq/0s0ysSC/cH3xXQXb9tVc6B67lQFVxIFsXysyrwTC8cf89mxGnP5dqvmjLpd4kBbPfaavAP
KoAaFAOGGkxqfhWDCKSgcCUcgvhCO4YgOZ6d4BLkcXQN9fEN9GbCn+EnCXYmpyCnradHQFCgx9eC
8fyqYLKk9OeCiY1e7uEpZefrHQjXKmVjZPi3qlARse6mc5mJzkGNI4y2IXnNeeG1HyZnXzRZ2dti
+uyPzedWWNq6vd6Fn5t/e56/qpyBZ81V2Qpes4roVfdNqg+nEDYX5JX6c5/SZSe3GMq9d9vVLGqy
b5v55F1XylRlzpmrRAbdmSCpt1mHX+d+9dTXXnoqQG1keIrZ/uP+YH3Wh1PH3KNZQ065sfEJW0r7
K9MLmrX32yQIT1lvdZ8cxPRf1w/px55J7PbXOTBdY7B8egnPOrfU1V5ZO0PpiSX95wekTloLJLtf
Vr6jZiLaU2WeoWdjJ3LVa0HE4aL1DQ4GOSybDYG0o5p1a+Wqbb30d1k1KUWpB8bP5WjJvmaeiAcm
Yntr13fYfVGF92TsW1KQLQryVD6Sh4MLdmg0GieF8v9DKsaxyyjInnaSRlLgGzmJnUFQJ1KFmiZd
DcOCl5b0tZ23ylxgPL3A2P0VyctePI5Khc0ocVTTQRqztrA4ylyh/+ppK2b+oinMaavKEj8VWqav
xuY/v/RC5J7vBSI/cgA3qr+0vumdXdPZnGqHoFfuxoeMsZ6MhsxWiUreHFF6+q02yaKp63q794ce
SWnX2aK/0++0dsD1DSWynzqe3/TlTt1QPfwAq9IYeBs5xC8wnfZiasa2OSsUV1Zop3Ry0hudfa5U
xxiu8DpYVVG1ReNSP4U/cs2b651zOtYOP3hwZHiwo5VeFnwz7ZH1Ce38SJU/9O9q8Lpp4TmxfrIb
B53cU0qXVOncctm8MF5M/Y3ezlwWX/7ypDLlirx9lwvbpE7UkKIJUkL0aadtXxt2LiMfpSn6rq8L
fjhwoPBqzJyQMAJqjB/UGNsvGuM6bvV8REiU0e2IBnXmN7bqr4KjTpJQcdSh4JA6pBo7qc5Oksx/
SdG+LKf8Yvnfak3+XZ7k5rN183ZfOayrUSS7eMVd/zPSMhXpDV3FNfWtCmfVxiedbnNW/jDDQXKC
UnEK/b5QQaCiZfTEWYZHkmcfNd1AvxObXrSD45qjcZhTV99H4mE0s0D9MvNJ7yPXvChKhclIq4FA
a+mlZfRra/srBOkfXfwUE1Ztrig6nfBMuHzrmTcTT7g5d4/v0O2RXppUEhN6zuTR9o3hLrufFoXX
aSWrC6kK3nVrLBY7ZL3Tu+gPKR1yZWeyt+nDeonXdBumoeozmpyf9Ip5pWnnj+lcnLMvwEnEvDDl
1pY4g9U8c2/vPRYve+5h/1qvo+bMagVDiyxXIRcrsoE1cI03OLJn4fzw61wLw2K/aM07MvYN2veT
xrFbLGyEHLWjGuyA9OwtkQve2VvsfCJ8yy9OgzZd4dnPpYmtE5NkqSLkxJifN3Nj9gcmU/VJPVIn
VytXM1Hdh8kM1lVVdQ/xnx7w9RhOdw8KUA1e4cvOVQ0OCfJY5c4MVTWygxVtOswizb7+JOSQmaQu
qf01TeKJyl9WGB4e/rMVeoaMWhPzhwaE1Ga2Y5Cdd7ZUnAYg/hS2mFn04nZsdA89ghluvWOuyAA2
wTfqrtvW/E/eeVmPFae+X3hr17BNzTLuspP7u1kDOyWDFr9/0/eA70YSl8FEYamW2uMmc7kUXBy5
LdJfcTWdmh/46qGZgKJmknRIx/ITJb4Ccuk9zzW470YFBqXx2F6aZjnvsJpy4rO8JmeF06dndi49
Fsd7SlPCOt5k7khVet5izkMZ91dXO0bvO2DV1F+UlWn48LKTnMG9aI25VoPNDWv3vDjRmOUuZFdS
lNl7q6Y5N69w+6U1SuuVay/e+ehPaavRLuprcRIVHlf79lLMfn4usftbZZ+W5lkadJWOV1hN1Cmf
3LviYspMqDZ7oNokfFWbeZHdSG1ov09t7H0DPEOZrgHBo9VmBqnDmEEyNDXVEN4wUFKNZCfJ2P3/
krJNIeU/d5SSgUa+wT6eIVLGdiZSJnZWugzSWFtFU1tDS8Vojqn21w9SBCV/sRF2niFhvu6efytQ
Xado7g13IorjjQ32lZ3vtsyW69AJk+S+qWa+aPV1pTv7OLf2PtX/UK0QWfDhybooteY7+kk6Wv3v
butpTPwjjfVB46VPQohYSmelZWdlwoA6D16XHxaqaencV/HAfN2kyvTVd0ckEybMMV15NXqKo0BL
nLVe8/v2waTuWdij1nbXIeFki72xM9/4zu56sLGG0/oUc+1zvidzuwr9+1q9Y7neTby0TrAq9CG3
5Xu3D925Opm6wy/GN7hKui26zWMf16pnYfFwYbWqi9iWNJpRm/MLFo/sDu5cGsMzaZuVpKF0ftrW
TybGJkGaR020inwPeQ5pGB0VPqun84B/c7/Y+kf2NpP19jCKRgvUd0GKCnk1fZbD1E75tz6V4KPF
g6jmRwZjtCfomdWsHSc1Ci0SU05ndR3RMzSqv/Z/0h5maLC76z9Fe76uifkzBeX6iwr/RKB817C4
+Sa2tDebbpxe06KxJjZ6iqLhtIEb0mnEjqLldsumDnXX2ZsfXPdW8Bqv0ND8/sQJWOCjuEmKJgeU
ddTuB2VqLemRtU2xpyTPOpDloT04o0HI6ISuwc5G+rmVsYoDXgcYD52cU4ZsbR84vdi2dY8vt+XG
lpYwSw2634NI4wNKS+Pso03kROXPbzK9IP9INMZ3qtCgcP0rGeVY02VKr4f214cbyAYN7fdI2JLv
Rj+kInnwyVaD6JHSLR93vOz7RC25Mu/qEuaR9wOCk8V1rhaU3zz9urynoajfQfLDzL6Gm9OMT9dk
zVrnJXLlmJQ7z6XZ+p5qopHHKvXrFMysZER3BW4m6/pSxwoUvx/vLutaTL5w/F2TyYvWeOf/KFO/
J/j6ok6khoYWW510YPI3BF9/Ec6/05t7WoEfShrmmK8UabhqZmBX+75Q6JSyWpWAtW1DXLeB+p15
jDTFE6kenZNt4k+dtWiJpr3rXXUm6eLB1mLfYK/VU7yenajoTTh5pefwJ4G9vItlpqo2z77jQBUP
Ox7gEWBuf/d+X3tNTtzFmI5oS1wr/U1tNpeDpM/cK3dqw5xU152Qp5Y7LPWTcB+JiZzZ00qVn68T
zuR0Put0O1FLeVUj0SWpwx0ZNrzHP3BN50uDlB3ZK4nl06xF3FzUsq/HWSnJOPmYJLWrxvPbHBs6
Lpbs3yO/W/DdZf5bCcRrVljojPrta/KbXDhe0koT1SvepS+NN4xflJAeWDpZ2awpKMuo0+9ZtMKW
FZ/1hgUU4R6R+3kL/X8RfvFzcH85AToBsGMqbJR6/lQcRb99QQin8knyYHbYKswNM8IMx4Zmf4nr
fiJQ6fPHM85G2lSN35LnygmIzcEmyb2h9tWzuGkqI5UL7BIkunVSKwoceNs3n9ATb/lw5EBjxdEF
0uJBXL5RKyj5Mqbd/uUBkTKVpjfiB5LHneHcNKPuRdTzYGeTnLTrTVfvb6l9UDPtSuTLxmK11vUn
L7ufn9EiIl0T1q6XWSYemi294XZ5uYD95tdZZz3NMxUVslw2jdO7KOi52qyquShO17rUbVE7+fy5
zqRHG/vbdGKHBKU3e8S4c1Az+jNxI9W1phtOjeB3PIfM29sozG1ltEC+pj33FF0jzfqEs8ZLa+MS
649wXMhQq3wyu95Ov/rQxvZnXlrJr2UysppKw+0X6N4MMT4mO8hgUUugSBXiAJCx639jVDYmVvx+
jjs3to0U+na8FQGDk0JDdy+za8GXg8lNYfCNPq0OS/M9xcsgyNFLJ5Cy379IZcA69jbFnDPWIrX9
OFemTenGmk+K1qnHSY9RX+FjOJD2udNiFLH5mC/mjoVgQejMvBfGxKQweywCC4Ypb5jvCj0fLCJP
IUbul90rMyI4yDvENdgnQuoHeaOyACZV82flYlFMVyhTbMP8qwPbS7O2zc7vItQdqT3aoaYfPx4t
3tXbST6K2vTmxWvK2jetTkNvmHtieAPL2opVKYHU4C7KzUHhjSq18du19jUbxDs7EhGNt0Vv13xS
T8q+VyaVX2H64mRUTndJrUF9V41xR4vh6XfPhUQ3WfRtAybNy9X5kqKLNxcYJTd8tBpxL0o7d4Ux
ZWFouUtFKvVtIz2s2Gx1MZ4Zc6k4VWOGQv2fHny5W/DGgMnriqMcNM/fEIw8Nkdm+67mNVbBYQXF
Shdknq4JveWcm5LX62jNwJX4w4zfp5tKuKULrk2JfBwv21mw20qLWm/pdfjZvrZ9i2TXbSRbJgvl
sfDJJAsX/36MOBgsnA9mcf3bq+iPPdKYAIPzSxXNdSZFRtdE3u9XgQD8zW9LaIxxsKvVZpBqsKNV
01HXXPKXioiPyBEdJ1yTnacvJzeYiL0p6Xz57gfNYleRjh3nzLlUOiobxfffkaZd5HvplSg3Mgdv
NnpV3ZAnFZbx8PSDbVsEZj9UmJa/PzXJdbPIUNO0ozZi69+tTe2yuzD7WZWKc8pV4zSPQAcX+Tm8
FxPxGMMemV1rL6itsenx3/D4/QzhN/VJaW6T7DP/eCIokHdzT/HbEUddytznrT2LBrwMDL0tllWc
qb6ToPLYsbIhtdBtpd+sA4JcZ5uVmla179oUsTo4rsg082xZ3EarubpKcXbSageHuy7OYobhtcWH
Q+ycK30uRr1g6PtkTokZKOcofXqjcrwy67p/TUnHymPP4twOngBhZBsx2+7YUtrA2/IZHjQ76QlJ
3qaB/H4BiwVtA8vp2H8BDQEXNw0KZW5kc3RyZWFtDQplbmRvYmoNCjI3OSAwIG9iag0KWyAwWyA1
MDddICAzWyAyMjYgNTc5XSAgMTdbIDU0NCA1MzNdICAyNFsgNjE1XSAgMjhbIDQ4OF0gIDM4WyA0
NTldICA0NFsgNjIzXSAgNDdbIDI1Ml0gIDYyWyA0MjBdICA2OFsgODU1IDY0Nl0gIDg3WyA1MTdd
ICA4OVsgNjczIDU0M10gIDk0WyA0NTldICAxMDBbIDQ4N10gIDEwNFsgNjQyXSAgMTE1WyA1Njcg
ODkwXSAgMTIxWyA1MTldICAyNThbIDQ3OV0gIDI3MVsgNTI1IDQyM10gIDI4MlsgNTI1XSAgMjg2
WyA0OThdICAyOTZbIDMwNV0gIDMzNlsgNDcxXSAgMzQ2WyA1MjVdICAzNDlbIDIzMF0gIDM2MVsg
MjM5XSAgMzY0WyA0NTVdICAzNjdbIDIzMF0gIDM3M1sgNzk5IDUyNV0gIDM4MVsgNTI3XSAgMzkz
WyA1MjVdICAzOTVbIDUyNSAzNDldICA0MDBbIDM5MV0gIDQxMFsgMzM1XSAgNDM3WyA1MjVdICA0
NDhbIDQ1MiA3MTVdICA0NTRbIDQzMyA0NTNdICA0NjBbIDM5NV0gIDg1M1sgMjUwXSAgODU1WyAy
NjggMjUyXSAgODU4WyAyNTAgMjUwXSAgODYyWyA0MTggNDE4XSAgODc2WyAzODZdICA4ODJbIDMw
Nl0gIDg4NFsgNDk4XSAgODkwWyA0OThdICA4OTRbIDMwMyAzMDMgMzA3IDMwN10gIDEwMDRbIDUw
NyA1MDcgNTA3IDUwN10gIDEwMDlbIDUwNyA1MDddICAxMDEyWyA1MDddICAxMDkzWyA0OThdIF0g
DQplbmRvYmoNCjI4MCAwIG9iag0KWyAyMjYgMCAwIDAgMCAwIDAgMCAzMDMgMzAzIDAgMCAyNTAg
MzA2IDI1MiAzODYgNTA3IDUwNyA1MDcgNTA3IDAgNTA3IDUwNyAwIDUwNyAwIDI2OCAwIDAgMCA0
OTggMCAwIDU3OSA1NDQgNTMzIDYxNSA0ODggNDU5IDAgNjIzIDI1MiAwIDAgNDIwIDg1NSA2NDYg
MCA1MTcgNjczIDU0MyA0NTkgNDg3IDY0MiA1NjcgODkwIDUxOSAwIDAgMzA3IDAgMzA3IDAgNDk4
IDAgNDc5IDUyNSA0MjMgNTI1IDQ5OCAzMDUgNDcxIDUyNSAyMzAgMjM5IDQ1NSAyMzAgNzk5IDUy
NSA1MjcgNTI1IDUyNSAzNDkgMzkxIDMzNSA1MjUgNDUyIDcxNSA0MzMgNDUzIDM5NV0gDQplbmRv
YmoNCjI4MSAwIG9iag0KWyAyMjYgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDI1MCAwIDAgMCAwIDAg
MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw
IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNDk4IDAgNTE0IDUxNCA0MTYgNTE0IDQ3
OCAwIDUxNCA1MTQgMjMwIDAgNDU1IDIzMCA3OTEgNTE0IDUxMyA1MTQgMCAzNDMgMzg5IDMzNSA1
MTQgNDQ2IDcxNSAwIDQ0N10gDQplbmRvYmoNCjI4MiAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVj
b2RlL0xlbmd0aCA3OTgyMi9MZW5ndGgxIDE2OTA2MD4+DQpzdHJlYW0NCnic7JwJfFTV9fjPe2/2
fV+TWTLJkGSy74GETFaykoRkYMKakABhDQRQsKDUqmhwB+u+1b24DIPW4FKXYv21VlFrtZtba+2a
Wv25gSb5n/fOTEgiVWz76+/Xzz+XnPnee+7y7j333OVNAGAAwIwfImir6WiYN3dc8jqwO34N4Lyw
tqqm8+pjloMA198AILuptqq5evU1L78HcPU2rJA6r6a2Tp+QeCOw294C4E7Ma2vtOLbr/V8C3F4G
zPmGeR2hKt3LfZ8Bm9YG0HRpa0d23vHfH6kDYH6OT+3u3dizuf7u1vMBUsuwfmfvGds8j5z9wrMA
tXcDiE2rN6/ZeOufqu4FCFwOIDeu6dm6GRLAh8/vw/q6NRt2rvY8df/HAI2PASRe3L+qp++di8Z+
ge0vxfyiflSo79HUYPoAppP7N27bseZByREAtgTAz65fNbhpN+xQAexNwDLvbhjo7dHcJbsJoL8e
wPXyxp4dm+3P6S/DvGGs79nUs3HV0zXlxwAuEgFogpsHtm4b18EF2J8aPn/z4KrNK34wjrYouB1A
zwJvW/FNwz9bs+DjFdqyj8AuAz48+uddP+H5TNI1m08UjD6nMMkSgAU5CgWsJ4ExYI4qbjlRcEKJ
+cBcB5MCdy1fRtsPS0EsKFjQQTZ0o5VG9NQKJwowl2OuTHytOB+bdBG5F+ECFmTAasUsy4oUrOht
YMeDcO841pHzFVs6PB6h57dQH6Q3sX5U3Cw0+rhYz48UW9ec7A1zDP6/D5LXYMH/dh9mwkz4dwdR
IrT/A3XKuU5o/kfa516Glq/7vP+LAcdVdZrlKuJx5tWT8a8buNtg7le1I+mEisnP+0JfnDD/6zxT
lDj+aTzOfn9qu1winTZfFdj7YcvXeeY/E3Dsm0+3LHcF7BIPw2WnzDsA5n9Zp2bCTJgJM2Em/EcG
9np49HTLMuPjV/1P9uUfCdzn48v/7c8shE/+3c+cCTNhJsyEmTATZsJMmAkzYSbMhJkwE2bCTJgJ
M2EmzISZMBNmwkTgYpIg/I0xgKcxxQi/tRfBnZh2gA41CoypIQkyoAVWwCpYC5vhTNgJt4yPC7XU
4Inl9cAaWA+DsTxm/CNsPm38E84ZfyAzf7w39ixLTGXCp3sgPd4jrpG7mmEZLaNjHIyLaWMWM8uY
DcwAs505g9nNXMRczFzOXMc8xDzJPAUS5i9CrfdjbZ4MDLCxv4/HwpcH5uRzT2Gg0Fcb8StCzVcX
4c7CbkyMGePCqJGTxo2pySMH5tl/umf/04H7l7b2H+GRwboVy5ctXbK4Kxzq7FjQ3tY6v6W5qbGh
fl5dbU11VWWwYm552ZzZpSXFRYXZWZkZqf6UZF+S22bS67RqpUIuk0rEIo5lIKPWV9ftifi7IyK/
r74+k0/7elDRM0nRHfGgqm5qmYinWyjmmVoyiCVXTysZpJLBiZKMzlMGZZkZnlqfJ/J8jc8zzCxu
D2P8khpflycyIsRbhLjILyTUmPB6sYan1tZf44kw3Z7aSN0Z/UO13TXY3iGlotpXvUqRmQGHFEqM
KjEWSfVtPsSkzmWECJtaO/sQCzI1/9gIl1Lb0xdpaw/X1ji93i5BB9VCWxFJdUQqtOVZy/cZ9nkO
ZTw5dPGwDlZ2B1R9vr6epeEI14OVhrjaoaG9EX0gkuariaSd9Y4Nh7wqkuGrqY0EfNhY04KJBzAR
cYrO5xn6CLDzvpG/TNX0xDSSFN1HwEf5IU6YCfPjccC+YQ9xfF4v35d9w0FYiYnInvYwpT2w0hmF
YHagK8J28zlPxnPMIT5nTzxnonq3z8tPVW137OeMfltkz0pPZgZaX/hJwR/M90Q4f/fK3n6ePauG
fDU1ZLfOcCRYg5FgT2ystYdysrF8TzcOYi1vhvZwJNu3OWLyVVEBVHj4OVjbERaqxKpFTNUR6O6N
1Ypk19bw/fLUDnXXUAf5tnzt4SOQP/7WoQKP83A+FEAX34+IpRonxV87FO5bHXF3O/vQP1d7wk5v
JNiF5uvyhVd18bPk00XS3sLHeYUnCrVwbNNKxwvzI5emyDxh1sl18bOFCk8dfviqyjBDh9MlJPkZ
rSrzhBknxIvhU2Il+NiUdjDBpVTX81kcX7W63unt8lL4ki45Y30Sp0Rkk9rSoWKiT/Scv9s1Ks13
KM1Tu6pmUgenNCqOdTDW2qn7yfK2iD0Ya8j46ayPZ3EpuHJRx2IzgoqfRZsnAm2esG+Vr8uHPhRs
C/Nj420tzG9Th6+pfXFYmO2Yl3ROSVF+CaUi4MXseIKtRh+sCzjj0yqk5wnpiWT9tOyGeLZnSOZr
6hjiG/fFGgQPriActMTf0LOvxFCAS7MOdzdfXY/Po/PUDfUMj+9ZOXQoGBzaXNvdP5tvw9fQN+Tr
CJc5hb4uCO92nsU/ygBNTFNnVWYG7j1Vh3zMhe2HgsyFHYvDR3QAngs7w1GWYau7q7oOJWNe+IgH
IChoWV7LK/mEh0/wLS3AhEwo7zwSBNgj5IoEhZDuHWZA0MniOgZ6h1nS6eI6FnUi0gUFHR9wkmz9
aGLcbms9ffz07OrqH+ru4hcXWHAq8YeJML65EGF9cw8xrEQVUfhWVUWUvipeX8HrK0gv4fVSdAzG
wqBx+D1pqNuH+xQ6VBicDLkixzfpGR4f7wx7n3eOdHnR1ZaiLA5H5AHc+8UpjVhuHi/dqJ4X2dPb
w/cDQmG+rjSlobcL3TbeIBZpiMixBXmsBSxRJ9Th3REr9eLc4AQK9fdgIrKnK9IV4B8aXtsluLMu
AvW+2Tjt1KbYzz8ou2vI4MsT1iYuBUXKXh5y7Bt0hEnjxCQ+rIuMJFVhz3t9mNXb7UFri6C3A12d
9lKFkzSrcEsU+VcJonDGMoEfFpeiVCsi8ixsEH/4uDKLX5LiFGlXF3VeSO2NFcBn6yJK7JF/kilj
FdA6mNXA9wV/9mJX+aJP8c20D8MC3w7cWfhOCy1JMTuiTmnowc2f6itR4yuJV5bxe4Qy1sZR0kr5
kavQ7lxK5/D4Xb6d3kkhM8PHHw68Y4LzCDo2dA1NV0SWBDIzZNO1akE9NCRTn7oC2UumniAq4ZCc
G2bPirrmuofZnYQdUZcScSbhjKhrNmI7YRsV2Rp1zUEMRl1liC2EzYSBqKscsYmwkSpsIKyPJlYi
1hHWRhOrEP3RxGrEGsJqwipCH6GXKqykCj2EbspbQVgeTahFLCMsJSwhLCZ0EcKERYSFhBChk7CA
0E5oI7QS5kcTahAtlGomNBEaCQ2EesI8Qh2hllATdTYgqqPORkQVoZIQjDqbEBWEuVFnM6KcUEaY
Q5hN6CCUUpslhGJqrIhQSCigNvMJeVQvl5BDyCZkETKpsQyqHqB66ZSXRkglzKKSfkIKVUgm+Khe
EpX0EjwEN8FFSIw65iMSCM6ooxXhINgJNsqzEiykNBNMBCPlGQh6UuoopSVoSKkmqAhKgoIgj9rb
ELKovR0hJUgIYoKIinCUYgkMAQQw44QxwqhQgfmcUp8RThCOEz4lfEL4OGrrQHxE+DBq60T8N+ED
wvuEv1GR9wh/JeUI4S+EPxP+REX+SPgD4feU9y7hd4R3CL+lIr8hvE3KtwhvEt4gvB61LkT8mvCr
qHUR4peEX5Dy54TXSPkq4WeEVwg/pSIvU+olSr1IOEbKFwjPE35CeI7wYyr5I8J/kfJZwg8JzxCO
Ri24LzE/iFoqEE8TnopaliCeJDxB+D7hccJjhEcJj1C9I4RhUj5M+B7hIcKDhMOEKOEQ1YtQXx6g
1P2E+6jIvYSDhO8S7iHcTfXuogp3kvIOwu2E2wjfIdxKuIVwM+GmqHkl4kbCDVFzL+L6qLkPcV3U
vApxbdS8GnEN4WrCtwlXEQ4Q9hOujJp7EFdQm5dTm5dRm5cSLqGmL6YK+whDVPIiKnJh1BxC7KXG
LqDGziecRyW/Ra2cS9W/SdhDOIdwNmE3YRfhG4Szombck5md9IQd1PSZhDPoCdupL9sIW+l5g1R9
C2EzYYCwibCRsIGwnoayjp63ltAfNRch1hBWR03nIlZFTbzv9kVN5yB6oya+3kpS9kRNQUQ3KVeQ
cnnUdDZiWdT0LcTSqOl8xJKoEQ9hZnHU6EJ0EcJRowKxiLAwasRjnglFjXi+M52EDsKCqBGPeaY9
asSDnWkjtEYNfK/nRw11iBZCMymbCI2kbCDUE+ZFDXhuMnVUpJaUNYTqqH4eoiqq5xdlZVQfRgSj
+i5ERVS/GDGXUB7V895aRphDmE0ojeoDiJKoPgNRHNWXIooIhVE9/6ACelA+IS+q5y2YS8iJ6nlD
ZhOyqC+ZhAzqUoC6lE5Ioy6lEmZRJ/yEFEIywUcVkqikl7rkoU646XkuQiKVTCA4qbqDYCfYqKSV
YKEOmgkm6qeRHmQg6KmejqAlaAhqKqKilDKqW4ZQRHXLEfKobgVCRpASJAQxlRRRSY6ULIEhQHAc
OY7lxpCjKJ+jfIZyAnXHseKnGP8E5WOUj1A+1K50/zfKB9pe9/vaPvffUN5D+SvKCOr/gvJnzPsT
pv+I8geU36O8i/rfobyD8d8if4PyNpZ7C9NvoryB8jrKr1F+hfJLzRr3LzT97p+jvIbyKsrPUPcK
8qcoL6O8hOkXkcdQXkB5HuUnKM+h/BjlRyj/pV7vfla9wf1Ddbr7GeRRdYb7B6h7GuNPqTe6g+NP
qte5n1CvdX9f3e9+HHMeU+e6H0V5BOWIaot7WDXofli11f091Tb3QygPohzGdBR5CMtEUB5AuR/l
PpR7UQ6ifBflHuXZ7ruVZ7nvUu5034m8Q7nLfbtyt/s21H8H5VaUW1BuRrkJ5UaUG1CuR7lOmem+
FuUaxV3uqxV3uL+NvArlAMp+lCsV/e4rFOe6L1dc775McaP7UsXN7ktQfzHK+VyK+zyuxP0tpsR9
bmhP6JsH94TOCe0OnX1wd0i5m1Hudu5u2v2N3Qd3/2p30CBR7AqdFfrGwbNCO0NnhnYcPDP0CHsR
rGYvDJaFzji4PSTabtq+bTv34Xbm4HamZjuTs51hYbtuu2c7p9oWGgxtPTgYgsG2wT2DkUHRnMjg
W4MsDDKK4fEnDw86XXXI4K5Bta5uS2ggtPngQGjT6o2hddjBtSVrQv0H14RWl/SFVh3sC/WWrAz1
lHSHVpQsCy0/uCy0tGRxaMnBxaGuknBoEZZfWNIZCh3sDHWUtIcWHGwPtZbMD81HfUtJU6j5YFOo
saQ+1HCwPjSvpC5Ui4OHBF2CJ4HT8R2Yn4A9wXffqhxn0PmW829OETgjziednEHrcDvYNK2dqW61
MwP2c+yX2Tmt7ZiNDdrSMuq01mPWN63vWUXGoDUtqw4sOovHwpn5sVlaOusEVtQQcwuFsbZYfP46
rZnRmt1mttZtZkD/lv5ves78hO6YjtVqGa12XMsGtVhcq3FrWP5jXMMFNbnFdVq1W83yH+NqzhJU
o4ZvcZaqrbNOq3Qr2VCFslXJBpUV1XVBZWZOHXCMh2GA0SE4Gd8Lxuyuw3V92MKIGTzPD3V2BAJN
w9LxBU0RWduSCHNhJKWD/wy2L45ILsS37sVLwocY5tKuQwxb3Rkx8d8WCenzL7kEqhKbIokd4cgt
iV1NkT0YCfKRcYxA4iELVHUFlm/dvjUQ2LYcP5Zv3RYQfjDFbOdTAV7J/2zdhmn+z3YhDYEvDVQM
sWIrhm1x5bYvr/UfG5j/7Q78Hw+2FcK/wJLeBDC2f8pvtNpgHWyFPfjnArgE9sMT8CtYCd/C2LVw
C9wJ90AEnoIfwWv/ot+gCWFsp3gjqLiHQQJGgPET4yNjd6IMizWTNPsxZRR5TmrGdeN/nab769j+
cd3YsMQACqGumn0Ztf/NjI6fYCv49HgRn2b3Ylwr1HhfetPYA2N3TelOIzRDJ4RgISyCLmiF+Sht
0A4tsEz47V0v9MEqWA1roB/Wor3WwwbYCJtQVsMAbIYtMIg23Abb4QyMb4tpKL0DdsJZsDvGb8Au
jO/Ez7OE2NlwDlr+mxM8d4InNd+C81HOw88LYC9cCBch+c+puqmpIdgHF+N8XgqXTcQvO6WWj18O
V6FcAVfirB/A+DU499fB9XCDoN0P34arhdTN8B3M//aUsnzeyfI3wk1Y6ha4FUveht5z17SyfMmb
4TF4HH3qh/B99LYnMPY0HMH40/AmvAXvwO/hD/BHJsAUMfPgA/gQjqH1V6PVeZtvFj7X4ueaCYuf
ibaNW/ZstNhUO5wRyyN7nivYKZ53Jpbci7Nx7qQ6Q8I8xdviS8fbmmwvfkz8iE7qaIT7JzQnxz21
FpWbbLOpFrxO0EzNnW7ZyfFb/27ObXAHyu34yc/D9FQ8djeucF6+CwfhXozR58l0PHYf3A8P4F5w
CA7DQ/A9eBiGJ9IPYupkflTQxMucWv8IPCp4wRPwpDD/P4Cjgu4JjB2J5T4Ry3lEiD8Nz+Iu9Bz8
BJ6HZ9B3nhXkOXgB/eMleBl3rV/DGzEPelXwIB8TgBfhJZEffi7WMGLuSXianQ87MP0aey3OBIjf
AQ3/fx+NbeV+ibsHB1KYI+wCrQ9lWjItsrJKBTMCDSBl+oAFD3MxyIBh+oIGEZtSLOHanWr95nam
vUbKdkLF62+8vuyN159HPs9kvz7y6ohu9NURQ2lpdnZuDqP36gUxaVipVCLxJWWxxcVFRfn5eXPZ
woIs1pekQfEXFsxli+dy+XkuVihKJQUtFua13C8/X8K1jkrYb7hrN81PZt1OjUklZjxit1VW3ppl
1HoLU1OD2W6pQsKKZRJZ2uyapJrlsx1jD3FSpVThsVgcGrFIqpLJPXajXSMaqxNrTnwg1nxWLdrw
2QEut2DNgiLxNQoZK5JIHnNaU+bUee0Bj1Fr1Kk0YqPFIJEaDUp/eePoPpnVYZUqFFKVTiG32Swy
uUKi0o2WAAMLxk9IjqI9Z8PhR9jd7NkQDvD3olA4WJXhNamzsoyZoDCbPJkKhc5zWSaTk8loMxkl
l5k5O1uFV8OC9qxMtREUFk+mymzKyPbO1jj97c6QLiQOpQZsFRgM1lJ9fgWTnR84yuTlldqzVyxf
tmyZPlBqy9ajzfVMvj4ff/AjF++qiafdYm5OV4qGE6bH6GN48/tncT4ursKp4WfBasxnYlGp+Kes
wuS12zwGMfs2O9oqS09NS2Jewzip9WJ2RGSwOTV9nkCiTvSomK3SulIyEwa1Nr1YZJeqpGIxfojW
fHaVRq1V4SxcM6G7y+QyytWO1ITPu7i7nLOcGrkx0cz/XaL28RHube7H4Ed/veQR9hx2z4SND8sT
Za5h5oEH/bP8c2TDzP0Pg9bPGDl/7jDrClqNIJ8zK9Ev4bwN6ccdjUWfBjUtXLNgA0fLSMUIbwcm
e+QVtOfrI2g/3Yi+tJS3oeU0KvLWizs3mQxdV5SfZ7HG3Fcq9fvR1UVmk4vlXb+YyxAlp5scOmxW
XbNscE7b2rlWc3bTuou7us7JM4r8qSanTsT8NHtjTdGi6lw3Xt+LAsUD3Y0Gu14jkirl3/U0B9NL
lm4rL7n0wMUD1fUVS3QaTqaS/qW2Nr9z/eCmDF9tqa98w5Vh3mrlaLUXxVsgE6rghqlWCxqU+kSX
2+MrLilNKE0wlOoNwNsrIUuvKC1JEknzj89qTDDolSKNtU7TXPZpUNrCj50fOj/yihHBbq+MZPNO
p9u9V3OUgoERrOc4/VbQiLj2RbznCevfX8zQjiBFN5QKUZE0tmVIpRYL2lHEvWjJbVy/b9HiPXkG
dlZqeoKIUbByM/qfyyBi2sQarVaiq122qaRsYVmKSXafIrE4q2hzd5Pem72hpqCzJs+rZ88ru2L/
vvWVNcGwXqPTiktkKplIhB9jmxwlxbkGX1NFuqewpn5ehrOuLG3uxv2L7qytymlbs2UQV3wzWnYh
9yMohL3TvDEhAfS8IRNTCz5JdYsZseLj7EbPx6lg19lZBWc3nQimxGww+gqg1wVGKjCCQC88WprN
Gy/h61YlE7K8A5K38UZCh7OYTRoJbbMi3ozcQqnGqNK4cptmB3sbclzqxV2VyyrTdTK5SK62lbUu
zb31ZnPe/MFv96Q2VhYmSrn5Br/XkpjsKgxt2LTGv2adJ82j1ai8Ppc9OdF4+3fKr9g/tD6otngd
htgqFZXiPTcDKqbbJajwZlYkYYY8qZg3j8OclMHNqkOlXAYSTc7xhMbZ01cY7yC4t5Fd8vMEH+PN
Yz/tql9Yn6KYJXBHi/kYE1+gFlqfmVxyutmhE7MeYX3OWTQnxSy15DSt2xcONM8tMK9mFCaP3ebG
3W/sVVymhaGaXI+uqmHyIr3b21SR5i6obWh0z778in3rq4zeLDszJlXz25xaOrqytj53wbotm7J6
1pStu3IRWq4F/elG3N+yoGy65b6XnlcsEYF8mNUE5T69ysWZTL7sYVYdNINP8v3i4nSXXq/Keym9
UfVm0DWxvHAb40+G7BF+kSKtpbizWYW1aTyNWnGP8kkkU7yJlU7e59B+BX5hXfIluBuDF75yYJ1U
3DsQXN2UI5fLRTK1TFXe2ZfXdUFXhr1o4Zk3rOzc3pR0T1tjZV9LsX712ktCPvZ3eK6ne+c6+9YZ
LUa1SpGQ6JCrrEZVaseuzsqrrrxg9dz0qvbi/IrM5lUljswytFbV2H7hNCjDN5YHp/mZOr+grKy8
vS0xoTyhfB7van5lGiQUlEGCSFzc4G4vzxclB4/nNKbKPzIYrM2fJrdY3w6KWycsgKOHkUDMhfg9
Lj/76MjR2A6H56yBjoekf7hFNK2YNyKeV/GFSWdDUdHpHiKJunmbru7uuChNq2TEUqVOrkou66os
WlSZptAnKXV1SzeVNvVXJJDbfuFgWVid59bivckv+GxW247WVK9VYdRKLBabUWl2WCwZNdlLdnhT
mipm5S06s3Y27pMbqyYfNXkdG7YMZAbq813lG/Yvwv2wYvwEF8GTphJ2T5sPX5Y9uVIJCp/Spqws
EImNx4OljT67ApKzJK60OlezmJatcByguQSTZx/N0+c/n58nnCSnXW/yXaaoKH7LlMYvM184VViz
SSLlclmFmV/QejEzgJcQZ8BdOLCiSd/GX2dsdlSz8aPFrZ84WmqWDswJLi51yKR2mZI/NpQyNsNR
aUvM8ZnmbjwQGtsSV086V9Y6igpzhHMlpXJxQXKNj98z0XLMe+JsfLtPg3VTbfdgmtvkwlN5ZVCp
cLtcJneaKNmuHWbmfU8cTG6wx7a7N1pG9ILRXn1lhD+L0WYPf0VZfnHHjBK7e0+67wmb4h/F+oR0
V6LfwIolBifGUozs2CcnTXKYES57vNFEP0nwWxUKqz8hIcUul9tTPsuNj507T0pjl/J/33su+shh
9JGCL5wN6SKj2ACciAukG01p+McdNARc6UZ1ToPJZRAH3GlSe3KdvVk9acqFg+HoUQd6Ca1NXJp5
+vyYBYLmr6wt7HASKcNYhH2NH/8s5gu+Eotwh/X2sZ2MWiGTmX2OBI9JIRp7qxc9x2tDI0hYRnnS
RW5jbpWZHD6bzWuUcbeoHNaxQ2NzDHapXC0T4/qRMx+MqQULoXFOesfnLzM75Woph28ttJ6Y99FW
Zpg3zVY6MyiDCnydUIrEurrYIhDm3xFbMMovZuJYi6eN7N1T+7f9i34L1B/x73HHXQJ3TetPaU1m
Zlap1ZLknZ+0BJbgw/HurShJUnY06lOPBxsaS7JwcwFLpjJpyfyaUk3+3Ib85oSJ1RtbvqNH8d0G
lz1eavQ4jYbSo4gf8hPKj8j7dduavhP4p2wEp1LFrBLbGKwn9wfxGmZilnF/yC3PW9/dyO8OglIn
YQak4ryy/HWkjJv0IQbfXExmp1bEJGlrl24sLVtY7OBMdUs3lFQvLrFN2TYSCxzB5vL1+xeObTqp
dM22lzdMVXLno8Nw/A58bxK+BHhLW7N9zRXp/qpwga8mGeK7MM7SbPjGtFny5zocTr9Iw4GWMXFa
TYr5eLCoMcWpETm0uX6ZJ9DgaZZP3VD51YXTgVMwMQ+Wr64VW1Wnb2ouIpNuQf+Lb8FScUH59A14
ijVrlm8p523IvoqjHn3hpMncsy3lTV9qsrTqMO648/Gu9RJayQrZEJ5qJ/4/uXYH5WDT2VgjZ0vm
rw9KVeJHxsa03056dRmJvTCO8EZRfDF74o1m8j0pfjUXznAR91JCafjMq5d1XxROd85eJMS60u83
57aWlK1sKU0xWHLnl5T38DF2a+N1l529vDgrvKe98bpLz1lenB3eszivrdgVaFg5sL0kr63EFWhc
uXkbsOOfjh3gXsSxpeMN/MrpNyNvYZFKXagutKmtNnrZC1hVRYVekTTnuL/RqrZ5RAZng6G19HRe
9nC7FU7n029gklVmTfKPyc5witc84QqT2Ti3wBJi5XjmWPHmzYyywiUd3UFTjZf05jXBhPvwQjNr
4hWvEF+evVr2vNlXHNi3odLgCTjG2uL7mehPeI9BvzjobapML1h0ZmugviChDO8xd9TV5nWuG9xM
K4n9AO2YDxumv8ek6vWJhgRITFANM7agLpjZaEjQpybOkliTGqwTOy6toOyjEyfSEVB9RfFJ9vnS
vcmCPcNxqGUyo9VlSupaOE/fOvVkjq0Vr7WisX2W3ueySiTcDSKry+M0SBXSOf2XdowNfHGJ3J7W
XJoklsolEn4vkY+PsH9GC9TBfVMt8BhuIaMwBwrwfSRgmYN/wKctCDprj6V6xDnioJgTK44FGz3H
UyFdl86quPTsN4LOU7+36ukU578z1I3ohOWU/M+0NfU9GPdvl2jibJ962cbbIf8uyMYs+meJUitX
eXOqszJqsmyFbctaC4vXXLk4u6M6Ry2TshLhe7+k4gXlxa0F9oLWpa2FBSvOb/fPK8tQKrkNCq/H
YrSZ7IFiV2phetqcjoq6nYtyNRanSqZXySw2i0HpdDudmWXe9MJAemlHsGpLR5bKYFEqeEtvGX+P
fUZ0H9TC0DRfSyvKCBQHqmTySnllsTwQyCm2Flshp6q+uLJMlvFbecBbVK/9NOidWGtogpG850tL
8TB9njeqoTS2YI8e1e2ll2fjadSOe6KP+/tvf/z3hfT9bX5+cdxDsRT7DCtRKDXyd1eJJIEcZ2qi
RSaTi9G9ZJ70bGvJghInKxZzq3YrVRKVUX12gFGahNNVzATe1Sq4/XKzxaJXjCnMBfr8bLlCrtSq
3S6bVKpRSmz5LUWqRI9Hw5xQGzUpHsurUpVcJJKrpK9a0I6bcV//DfcYvhVun2bHJKUNcsvycn3J
dhsobcm5dl9Znhzf3VwNGZ8GdS3ik98c0FUKb1JH+VcQvfCqZz2NOpNuHBMvcUUTS1ewY+zlbUKX
wSgMiWaTUytmvbraZQOlNctK7XLpQPxWKWY2SSRK4X2ku8nQyijjajtaU7g93pPUFExNqewq9Nb6
2IL4Oh592VGS6MpNNpVvuCrMXBpXo4V24f3gNrRQLiycfu55mb1RgyX1UdYNAB7ms6AyaMlsSFI7
G2LXZgPvVDjaV0Z0rwsLVT49O3b0495KBpjF+f0TS8xoRieJ+Ql3m0SUsmzL3japwe6xuP1mOXM+
w8gMbofDo5cwG8RzVnY2zeKUeNO2ufRS7g68z2588/Wf9SpVUlYk0yi4kFIvVWtwXFK1fNShknTd
FT16hnB7FstxnJfhbfVpHGcTnDd9nJnMdx90JRkNOY8yn+M9aQ5z/oOG2YakqkdZLQ48gxkNGoJJ
8xoKG7LKjJx9VsPU14a4CXCl8PuVvjRmC93frzHdKoUcE49MNU/sYj7FUuKnxZx/ycaz66VmZ5LZ
4TPLq8deEuscsxISUu2qFWg0o9fhwKspUydiQiKFwWXF81HGNIqzli5s8bAqc5IDL6li7g6lVTbF
hOyB0QHc8kSCORfJ9RKVVk7mtMnl7B9kat64KtmoUyarf+CpH/fEjYvWNeMdg/eiHOif9t2nz2RM
e5TVoSGTmNHDNhv/pZUvqAkasxp8MlNig6lJ0xozTWnMnY6WZo9MfOWuOmW5kxYULOf347qaYrv8
mL0s3G0isXd+/77usVGJwZFid/oMrPLDq1hWinuM062XMtvZuX2d89ys0pzszHRxtyutiiXPvPan
b47djC9mIrHKpGFKuQGVSaoUzKFRjCYtevDI4z38QanCu+Oj4x+zu8TL8b0sG+YETWalxad0+iyp
ooBLaQaFSCcODDMLHnS16OpS48YJVFSMvqC3ltJberZwHZj+ws2d+pdf9/CHudni0IrYezmVLdnh
TDKKuDfxsFJqMnwOn1EqVugUunRvYrIRBxe/4XCPqA1KsVhlUH22UTNrlk+h1ci0Nq3an5qi1Cnl
Ohsw41eNvcEUwVt4C046pAL+Hz9opMbHmXawQWq847oPn8eb7g9zc1LQ/vTdPG/8+JcGRfnZh9Xp
eFWVcdLHrGKdPSXBju+895ZuLXlB+//YOxP4qKq77587M5ktC0FAYmLxQtiFEBEwINIQwyrQlApF
3DKTBRImi8mE7RFNY8SAvDZSV6SCtLW4Uxce69agLIoYASEEEwwKRpgComJAH8p9v+fcSTKBtA/t
53nfvp/PG/79nXvuWf7/89/OuXfqTCLDnNHhWpf5cXq0PSyyCxJvO/cb6zwjBtvFbBThlzQ4fxZi
Ih6WPsIs8tTpGfy8uicOnWfh6Ihyn70u0k3YhnNAvBsZce57e5dul3YJ7xLFtXvX8C7yc5TT1mzr
9LAS0UX0E6PHhouu2l2ih7iCtO5H0N4l3KKLpVOyK7xf2GW9J0RPCPXOgc3akJrjB45H/01mcxvX
XOo479ayX3N1jrnkku6RNm2iFt69V/fEeNu5/porOpbGiJBG69Jmd2gfy1p09Lmrzm8hU9b/v0Ha
TR30b6NTf48sT1kHtUMfmGRL/z9PYQPaoa2S7Nf+Q9olyXFZCB1z3t2GjrdPrgcluS8J0rYLKXze
v0Rn26OIwsgrQui3HdRB/79TlKVduvZ/jHL/ZdraQR3UQR3UQR3UQR3UQR3UQR3UQR3UQR3UQR3U
QR3UQR3UQf/3Sf26gMb/vqCcppUKu7hR66RVGk2Uq4zTlFWqvkmV2yijNYvxHWW0cUL+1req91Bl
miqXGF9rPZj7PWUVLT2Ye4pyG/XZtB+jrDLqKTep+jajTvPB8x3KaGMTZayq9zDeokxT9SXGG5SV
xnHKVazBp71mfKKVKG4liluJ4laiuM1X7fNV+3zVPl+1L6HlNKXUZQktp7Ql1hm0L1P6LlP6LlP6
LlNjlil9V2hVogvlJuGm3CbCtRXMypa/Zm4cpawyApRSx0olZRW6HKaMpncVush6D8asQhdZX2J8
RbkKK1VRP01ZqcpV8K9CVoT65XpZbpMlssq0TfRaKKuElXKTKrfJkt4KbZuau031blO92+i1aNvo
XWadgaydys+DLb1E8+/NZ6rSqrwfpe5k3SIirANF8188GGO1Bes2cbk1NlgPEzHWlGDdTvvsYN0h
frTOD9adYqD1WLDuErqtMFh3W9a2yAoXM22VwXqEGGhrDNYjLY+FRQfrUcLnWN/yVwuGOrsG65pw
OMcH6xZhdz3T/PcJxBWuR4J1m4hyPRWsh4kI12vBup32TcG6QyxxfRysO0U3tztYd4lo95Rg3a2l
tcgKF1e6bwnWIxh/X7AeqU1xrw7Wo8SI8CPyL0TYXEE7m3XTzmbdtLNZN+1s1k07m3XTzmbdtLNZ
N+1s1k07m3XTzmbdtLNZN+1s1k07m3XTzmbdtPMzQhdDRSKURG2qyBEZokgUiGKQLfy0XU+tSBSq
0kNLDrV8kUDPWOGDdDGdNvkrJH5mybssrlmMnk+ZycjrmedjjJe2HEbkqHEekAevTDU2n7ti2vJV
nzk/hxXowBP8dY1F3C2g5keWHFMCRz/tWdzJNZcwO5P+fPU7HLpap65+kSMLDqZMOUJHxwIlM0v9
RorUZZLSNZsWj/oFjyKlha6uHqWllGvqkUHPIMU5T7X4FEcPNjLbm6XkwcenLFYYXGU+LXlKqslT
6ukPWYGUWKh0Me3dbG1z7VJSARbQ1S++zFFWyFG/PyJ/Dcav7qTG/hZ/mDYzpehq7flBvQqUbb1q
ZOuKQzWSVluo5plaz+M+QcVDqDf7KW55isMiZYeSoOdD7S09ZuqfpdYv9Tf9UqSiQV5NidLXOjwK
W7Qx1zgnOKaYu8VB7n60MD00v8VLHhUjHlrz2ujVHM0ZrMSj5GcE5Se0E/WjLtDT9E+z/0e1ZM1w
MTMYRTnBeBsOxxH0tp0/uM389jMiKxjbpqaeoG5zVK+51qygNeX6M1VUS13mKX82z2m/N/ufyu7W
SDL9NoO7HLUGKf8XShN/Gx8PCa6gIESDjGBO+pWWWSrOp9CSIfor/w9gTKbiP0GtypzrV79VNAqO
Q/CkpASV/21XnqC45zHGT9zJ9c9RGhTCYRGt0rvZSheZVW25NrfLncX0wLwWfjepNZsRvUhFYrFa
oV/lXLHaI8zZutJB5muWirYcJcO0kFfNbbbeOOw3hd3SnFsU0mPmeqaySWv+LlCyMlR+tyfXvJdj
M4iiEmXDzJZ8yFT9cscxNWjOgUKlaX4wC0xeWaqUWX2+3rLf3D36M2uAis489MpqyecLV5V/AeeL
t1Er9+YdXA/uwWb0ZLTZCy/UvTVe267r2hALSE1MXcwToTnqi1pOl0y1v+arfdbzdzU17expY9Os
YPSfnwPSqjLyStTMTLVXSW2yWvjIkT613/0jD/1P5UVrTgwJ/n6YJ3hKJShfFYqFz+hDExOT9Kk5
GUUFxQXZfv36gqLCgiKPP6cgP0Ef6/Pp03PmzPUX69OzirOK5mdlJlzv8eV4i3L0nGLdo+cVZGYV
5evFnvxinf6cbD3bk5fjW6QvyPHP1YtLvH5fll5UUJKfmZM/p1gvYKg/K4+Z+Zl6RkFRflZRcYI+
ya9nZ3n8JUVZxXpRlsen5/iRkVE8SC/O87CCDE8hdTklr8TnzymEZX5JXlYRI4uz/IpBsV5YVMC6
5bLh7vMVLNDnsnA9J6/Qk+HXc/J1v9SDlTFF9+XkI6sgW/fmzFGMTUH+rIV+JufMy0rQg2r2K9bz
PPmL9IwSlDfX7Z+L/KwFepEHXYpyUJuJnjy9pFCKgeMcWopzFjPcX4BC86VKHn2BpyjPlCXNnDHX
U8TCsooSWkw/qlkm+kj9R0nXDJ+JiVBKH54wYmiwf7DZH+KILKyNUA/S5uTIVWWxzCJPZlaep2ie
XiB7Qm6z23e3MhK6zcjP8TP/F36P39R4CAwKlIAMPOkvyskqTphSktHfUzxAz8zSJxQV0Ov3F44a
MmTBggUJec3MEzIK8ob4FxUWzCnyFM5dNCTDn12Q7y8ODpX1bA8KzJPjbioowdCL9JLiLBaBSrJb
9+DXrKK8HL9ckHeRWt64GVPG0lukbvB6Zonp3wVzczLmhszlmpOf4SvJlLYo0DNzigt9CJAeKCzK
YUAGo7Ly/Ql6s+yCfMKjf84APSvPKye1sspvHtzuitRwGeCYvxjzZJhR2CJd2TXI61q1gP45SCER
pOmLZLpkFizI9xV4QoWyZo+5Ugzf4oGCEn9hiR+zz8/JyJJj5mb5Cs9T6GJ8oTwxJDMr20NKJXiK
CxfK9zH5d8GMGLG0vV9M5P3GyjuIW3QRDsMQnYJ/UU5+ObE/11IhWt7j2v+Xan00IkJjjLb+YsdH
Rsrxlovm36mTGn/R/KOj5XjrRfPv3FmNv2j+XbowPlX9RT0n735yvHzjjpV/DU+ziG5aJ6Fr0WKw
FiuStB5inJYm0rTZ4lbtVpGr+cQCrUCUayXiQW2+WKctES9oy8Tr2gqxRasUO7VVok57TXylVYlv
tU3ib9o2Lco6WYuzztD6WxdridZHtRFIGdNWvpbSjvwE5I9E/gTkT0f+7cjPQ/5i5Fcg/xHk/xH5
LyP/beRvR/5e5B9E/nHkn9E2afIzia7I74n8Ici/BvnXIWVcW/mW+0Lkd0d+PPKHIn8M8qci/ybk
z0X+AuTfi/yHkP875G9E/rvIr0b+AeQfRf732mvIrZKfXmlxyE9A/nXIn4L8Gci/GSmZbeVb/xoi
/zLk90H+cOSPRf7PkX8r8n3IvxP59yP/CeQ/h/x3kL8d+TXI/xL53yD/b8gPR3535McjfwTyxyF/
BvJvQ34mUvLayg+bFSI/Dvn9kT8S+eOR/0vkZyLfj/x7kf8w8p9G/n8ifwfy9yO/EflNWiV6r9Ki
kX8F8gchfyTypyH/NuQXIH8h8u9GSkVb+faDIfJ/gvwrkX8d8m9Afi7yFyJ/GfKfQP4LyP8L8nch
/wjy5SdmNm2F1g358ci/Cvljkf8z5N+KfD/yH0T+75D/AvJfRco7cp9wujSn21PqKZ0OPSweFssg
e5hmtydNrKisLHSGaU57cnLhRO4OyvawxImlpZXpqt3pNAep8YkTT5aWyvHNU6MPtk6urKx0WjSn
NVkkJyeXlpbKnrDk5Ilp6WvXBnuSzR67S7O7bxaZpamly1oXY7IIyqmoUPJVK6tijk2z2wrN6WFM
SErWo6MPOmyaw5Z8Ujanq5kTJRO12DDWt7ZKyXJVlD6ufshyh6gQTjuzUydOTEvTk0udFovTZq5K
lFotQmONpZrdMOxnrTaLMywtba3TrTnD06s8yT9Pnp68svSh0grIbtfsjtGp5RWPzXXZNZcDDrMy
uT0ZYj7VYbPZzGGh9mud7DwZMr2ioqKNAV1hmgvTKgtWVrgsmsu0YPsmlExNJqqalFpeXmGKMlf2
90zotGnSBEEbyvGpqanNC8YNaenJQRtWEDwzeIxNVTa0SxsmYkOXxeIK2jDUiBxT9nMY0SWN6IrQ
XJF6YmJaWnra2kn6JH2yXp5cnuywaw7naLnSx+a67ZrbqevSEHK5jjDNYZeGxJJuB10Wiy04Us6S
+p0pLV1IVwsHZ0VhKBMsYdpMBBcnOx10pmLQysoKt1VzW7kN9jrcmiPiptLs5FSoQnlZLS/IStWl
UbGq2yEczkFDe/VKSV3IVLnUsFnpJhe7cNiTUpMTWYzLprnCdP2k4p+uGKSatlUawKkCe0i54eXJ
K5JXEFumeSV/R0pKamr/RNZXKhcKH7VSUVpqsxoWm2zXnMY5h2GzWdx2TLzWHam5o/SYxP5p/dPS
0ionVk6KXh69VC/XQ60cbtfCnXqImU1bsvKKwnAHfZa2dna22BmVe/RiUVOG2RgaygbryCWypmZL
y26H3mrqcKsWbtNDbB2uOSJvqcrQUyAZCMFQ+PfbWq602dYXGNspjR2ujB0eqYV3ksZOlMZOk8bG
3Bi7XHc6NKdrTEpKWVn5Cn+EQ4twSX63eFNSUso3v05GOjF4srJ4hJNeTdMszcPlXOfolJSzpaXl
C8OdIYww+nm8ysuDZhXNZpUDlFdSUmelp1dWlEdYtYgWu6s9OVxzthi+2fRqwc081c1oJZQVtPZs
fj24pdul9RUvh3A6Rqdgflv5QneY5rbr+hlTTqHikiL/NSsl+bHnpssVREgz4YTkGzmQMkSKCHcK
p3Ps2JRevfv3l1tKhNUSYW9Zdxs3uKQbSm1hlgiH3OojOmkR0Uk9knqMHuEb7ZP/dvh25K3Y8ti2
mG0xLqfmcv80I+O9997bWj0/0qlFuhMTE9PzizP4t7Wx3uXQXM7LvelV/Nu8MNJFv1YqySp+yst9
hnhP0VZRLeYLOdh1eXb21rNycEQb1vYVC8/nvnVrpE2LtCUmCpGu/iFDjnHJMRnZvoULfTt2NI9J
TG8Z44rUXJ3yC4sfy4gxaWuiJKVKC2t118OUvtVcS4tSkoc8U3yFzRwdrH20N70w6fKIFQtlatoT
E88G5RUqVhkm3+r5yiJbt+7Y8f6swsJ0uZaorTFbY6oTqxPr0m9OL666o8pTGuESLpd8npAm6guN
FklQokgXVSIyTIu0x8TEJJpaiaqqMJthCZM3VZr73DmXURXmsEQ6s7N37KgIPsW7xTrLLGHNWFTk
E13nFGXNE6N8Hn++mEKP9ovpKbqI4c3IUE/vdhEpugbvNOEQUaKbajdbLDxpdRKXQtZJZKXoPf1n
U3WReOP0G3QxJjhGvkdFi+7qTv4V584t3G0iXFwiLgvehYkI3rZiRVxGYXGh+L0qn1XlBlVuVOVb
qnx3XlZRvnhfldWq3KPKT1V5UJWNqjwmPwUQ38pSs6syVpUJqkxR5UxV5ubNy5un3aXKpap8QJWP
qPJJVT6tyhdb3ob+u1K7yNKJJa3YgB2Wuvx/uf59bRb8EPlPX6NED5EgpqtPncvESrFOvCzeFbvF
F7yvWYRLaeoMantMyP+vz8q8ruqv0PPMrI0yr4tTzeuvp4XMId72rGt7/52l7f2pQW3vT8e0vf9h
bZt7LcLd9j7q6bb30X3b3semCJcl5D7OHtJvF9rgG9veD13H1U1M9xdp6BPFnDJMlWhJE3dbfm/Z
J9Zaf2v9rdhj89ueEnvDDthXalb34+4/an92fxQ+QXs/YmbE/ZbrI56KOGxZFPls5AbL25FbIndb
NkdNjJpm2d3puk7XWfYLrWi91M1eFHGiPYp0Qr0iB4XQ0CA526HRkYtbqBRaCa2GdkuKEudTpDPK
HTWoU2OQToZQk6ToW9ql7Oi3mqmzvXNMCy0PUlU7tBuq7TomhCaapHrOo64zu/paqKhbObRc0fr2
qPPubhu7vd99oKJZ7VJ298oWerb7hhb6NEgHocbux0KoSbWdRzE6oxpj9Jj5MfMvOyJJ1mLmx9pj
Y2Knx66I3Rq7U5LZ2kqxje2RktkYe9KkOHcrSc5x0Yq/LvGTyT0HtVBKz1ktlB+kUuiRnqW9JkLT
e73eq5r6671ej5/Se3qfdEWL+xyEmvo+D73cb26/u8DcfuX9Jw/QJfWbO2DMAB9UNmDFgJUDo6G+
V66Anrxy/ZUvBmnn4JVDkob8mNj1qo1Q1dBVQ+uH/nj1nUFaenXl1U8OOwmdG542Yt01myUlzUx6
SNHukREjlweJO+6Xj6xWd9Uja6HlI89dW3HtxtH9kx9JfmTsoJSXk2aao7lWm6NSX5fjUreOWz3u
2XGvj+81fq2i7eMPK/p2gphw6QR9/LfUpkGZE85NjJiYO8kGDZx0inHbJ3sneydMoyyUNWj+5NIb
7Df0VjRwStcpsVDSlDHgIWjVlLNTL52qT9WnrJo6cGrl1Era6ZmWDe6ceumUpGlNPxM/906vvTH3
Jv2mgTcN81R7h3nf8NY3XzOioMfmjpmblvN0zoacE7nRubG5vXOH5iblTs715c7PLc19IHd17su5
b+Vuz62dN3/eY/NenHfGZ/fF+BJ8Sb7Zvrm+5b7nfdW+k3n2PD1vVF5y3rS8W/IW563OeyNvT95n
eUfyfsy35ffNT8yfnv9Q/taC6IKB7bUVpBbcVVBZ8G5BfWHfwvTCdYXH7ujbXtsds+74sf19KLgT
hVDbnaRIbyW5RxTNbCVzdzg/l9rmghnP7e4czbtHCLXN/6IVrSSzvWhVK5l5LvfBTk2XHek+kL20
18hqdj61j6ore2b0W5Gr0cLdqTHS2bzvdY6J7NV5ec98OTfiRJRo3f+C1lis5ojgqMVR7mYryVa5
n8qxUl7n5bK92VKdY7gbxG7sjnJH9pLcmLOyUyPXXopad/ih5+3sq1v38pDd3C3XfcEO3nTBDp5t
7tvs2PbmvVrxkVqv7rw8SsjdSO5u+GMntYNy/zH3GHO3YmeTnspv8R67lrxr9SEWljyOxblV+8me
s0ye7Kche6i5R7bsgu3ugebuquTPCu56Kc37Ha2Des6K3Ukd/ldtnOzttt48T9SVs6N7JSfG+m4b
W06E4E7fuarb+tZTwYwsecao0evlCObO6rZR9qgWRsn2zryGNEdb9w30LYc381VdtbaeZ6EnmlyL
Or2az6/WE2xjcHVtz6zs4En1rDqlzLNpIPemTKSO396tvPunrOJg0LKmdVX+dA+xZZzbzBxpM9Oz
PfOlXXvmS527H+w6pru0/k5p/5AcHBTbiFYHZRQ0R4PkaFqbscfkOE6WiSbMs6XXRHUehJA8W8xz
RZ1M/yKp0yyE2hnxelsKnnUtdOEMdcb9U6ROwYunF/8xnW8pSS0n6N8hdaZeNKlz/iLpfOuop4MQ
utB+6qkhhGQcm57+5+hCzv/96i6OTDvLp4Yo9zWbx61O2h3ZSz5vKJopW67ZLJ8x5F3SzHGr5dOH
2Sdp2Llh5+TzitmqTotak+Sc5EfUM418eqkeWa2eTOTTSzUzZvJkEBt8goAmF6rnhlj5ZCHv1VU+
U8gxD5kkR8gxULAltvGG3vIphTxfO7lQPtHIpxlF21XLWvk0o+62Ty6U+0iwD+KZ6Nnxh+WTj3oS
EuoZCFLPPzb1pMRY+dTT+hw0fvvIWqXxbqnrVN3U9JrNwVV1NVc4YZriLZ+rhORl8j0v1y7wWKif
+6Sbd8KuVRl/tk417rfOEJ2ss0SEtcjYZn1HjKAn0jigRYE4o067HFQZu+g9Kizyv2e2zjAOCY3y
tLBQbrLOMt4XncRzxlmx2TjL3A+Z+yFzDzP3sJYuumgeMUnzip9oGaKXlikitXniEmaOYmaq1Wds
FBp8vxQ2xkYwtgtjIxgbofh/yagTzIk06uFbD99P4PuJdpvoyfjejJ/B+F6M7wvv3vDuBbfVrPcz
EU7tGfTrbL3TqLQuMW5Fv5HWQ8Yj1sMi0fqlGGT9Sgy0HjVqrQHeKqW03Uj7XDiRtg9p+5otQM9l
9NhZ7f1w3ify0Xi8iAbyv7O5Vv43MsZukQWyQbHRIPzGMVEC5oMFYCFYxLvsYuMD8R/gTrAE3AXu
ESNFObgXLAX3gQqwDCwH94MV4M9inHgDnOE9+JzQhSF0Tf7CpwZyxM+1rSIObXOsM8W11puFw3o7
8IkK693iCuuvwD3iJ7Y1xge2teApsFuMtH0C9oC9oAbsA7VgP/gU1IF6cECMDOtq7A4LGB+EfS/s
YU3UT4MfjQ/s2MJ+NdfrxBB7Mtf5xm77ArAQLAJ3Gw32UvAr45i9DNwj7PZycK/xgWO4iHOMALlC
d8wDeeBOMdKxBJRTR3cHujsepf4EWE39WfC8GOfYyBVbOH4A/0XfWfA3oTstYqTTxfUZrox1Pgfe
FHGu2SJOxXAj8e5WUdcoLiNyXyFyX8Hnc/D5HHw+HZ9PJ8ISiLAbibClRNgMIiyTCJtEhE0248oY
bp1pPGD9pbGY2BhBbDxMbKRb3zGeth4SVxFfVmuj8a31qLhZxVYdow6IbiGZ8mvk/Rp5q5G3GnmJ
yPsp8gqRl4q8DORdi7wRzJ6NrIeQ9Z8hslbC/y34zxCXwPVruH4N1w1w3QDXl+D6Elzj4DoArj64
Xg3XoXAdBNf+aPEZnLPg/CFcr4bjerIwztjLzL30fkDLb8Tl8K6CdxW8F8N7MSNKGFGiLHQ7GZLO
yj2iGP7D4T8d/tdpOUYDMhK1x5hXZbyBnDHIWYoGS5E1HA3K4H6/9QvjLFqcsh4xmtAkwRowzqls
P4WkU0g6jqTjSOqClEFIyUXKVUgZi5Q+SBgA9z1w2iNs7GZPE/+ReDeSllPsUkXsHY+LeyjLwb1g
KbgPVIBlYDm4H6wA240z4kOwA3wEqsHHYCfYBXaDT8AesBfUggPGD+Iz0AAOgs/BF+CQsUscBl+C
b40a8Z1xUJwC34MmcBqcMT4SPxhvih/Bf4Gz4G/gnHFYGOydAmjGYbULzjbqrbdQv41runHYtts4
YfsE7AF7QQ3YB2rBfvApqAP14AA4YpyxHQUB8FdwDBwHJ8DX4CT4BnwLvgOnAGuxnQOG8WbYpcYu
xw3GGUcamAFmgpuMg47buaaDLPqzQY7xpiPXOOyYB/LAfPruNE44loC7qZeBe0A5ffdxxfYObO94
kPpK8Cjtq7g+wXU17U9SXwPWgqfAOvg/S/sL1F+ivpH6G9S3gnpwAHwGGkCj8YPjK3AEHAUB8FfW
eAwcByfAKaPG8T3AJw584sAnjh8APnH8F2s4C/4GDGOXUxgHnZrxptNinHC6jMPOZ7iyFudzxI5F
PCC6qlPRKh4wjlLbTpzvFGHcyb1iIXdziPr3rB+LgUKjtUmkEpkNRGYDkdlAZDYQmQ1EZgOR2UBk
NhCZDURmA6MDRNoZIu0MkXaGSDtDpJ0h0s4QRceImCYipomIaSJimprPTeutIszqAV7jC2uG8QVR
00DUNBA1DURNA1HTQNQ0EDUNRE0DUdNA1DQQNQ1ETQOebMKTTXiyCS824MUGPNeE1xrwWgPeasJT
TXiqAa804I0GrH4Gq5/B6mew+hmsfgarHsOqx7BoExZtwqJNWLEBKzZhxQas2IAVG1TG1gsHthyr
nkvuNP6Dc3uGdafoZ93FCfYJJ5+0r3wK2YOGh4SNu2XcTeNuGPZdLWZxnsZznsZznsZznsZznsZz
nsZznsZznsZznsZznsYjZQxnah/O1D7k607ydSf5upN8PUS+HiBfD5CvB8jXA+TrASxtkK/15Gs9
+VpPvtaTr/WsNJszN4kcrSVHPyNHa8nRz6xe0dfKcwlncDlncG/O4J6cwTrnbjznbjznbjznbjzn
bjznbjznbjznbjznbjznbjznbjznbjx5WE8e1pOH9eThTvLuAPm2k3zbSb7Vc17Gc17Gc1bGc1bG
c0bGkyf1nJPxnJN9yJN6zsp4Yn8nsb+T2N9J7O8k9g8R+4eI/QPE/gG8ZOAlg9ivJ953Eu8HiPd6
ztN4ztJ4ztJ4ztJ4EY7NK7H579jR32dH34Xtf4XtX8N77xDf46y72dH3GOese0WG8tfnjD7MqMOc
uw/IXdrIZe4O5r5GaxlzH5BPbMydzNwm5s3mWekB42VGrmRkLSM/YWQeoz5WUfKM4vQb9S02eX79
UsXD4yrDioxqOKWoVezl2UyO363O++9U2cRTQJzxHSfLd8KtdRI9tNnAB/JAASgEd4Ai4AfLRQ/R
jVNpN6fSbuZ+xVz5X89FIH8Nch9DQqN6zlor+lvfFMOsm8AXPOceEr/gabMrTwOxPG32sR6hfpS1
BUS09a9imLhFfR/xCbAaPAnWgLXgKbAO/A78HvwBPA3+CNaDZ8Cz4DnwPHgBvAheAhvAn8DL4BXw
KpDfeJTfd3wXvAc2gy1gK5rI7ya+Dz4A28GHPK3M5tS+zXjD9pFRZ6sGHxt1Yd14emM9dtZj/9So
sx8gp/uDAWAguBJcZdQ5hoKrqQ8Dw42vHCPAaOrXgTH0TTDqnLpxzNkT9ALxoDfoA/qCfgC+Tvg6
4euEr3MQGAwSwBCQCK4Cd8OrFDwP3jS+cqKbE92c6OY8TtsJ45hrArjJqHPNNr4SDvy4Hz/ub35H
wXeb8NmlvB304ilitnDx9DzJehvX28UkEUWExBEhcURIHBESR4TEESFxREgcERJHhMQRIXHM1Jk5
j5k6M+epmVHMjGJmFDOjmBnFzChmRjEziplRzIxiZl9mDmBmX2YO+KdnDg/OHM6T5s2819wuBokw
9KxDzzr0fAc930HPV9Xz72n5NKre83bQv0N+h1V+a5U4nqXebmSOBMQDRGaAyAwQmQEiM0BkBojM
AJEZIDIDRGaAyAwQmQEiM0BkBojMAJEZIDIDRGaAyAwQmQEiM0BkBojMAJEZIDIDRGaAyAxor8nv
uxqfE537ic79ROd+onM/0bmf6DxEdO4jOvcRnfuIzn1E5z5th/GN9hGoBh8b3xCtO4nWnbYtxte2
rWAbeB98ALaDD8EO8JGxj2jeRzTvI5oDRHOAaA7Y1xvf2DcYX9v/BF4Gr4BXwTu0f8S1GiCHqN9H
1AfsXxjfEPkBIj9A5AeI/IBjkPG1YzBIAENAIrjK2Ec27CMb9pMN+8mGQ2TDIbIhQDbsJxv2OcbD
awLXW42vyYoAWREgKwJkRYCsCJAVAbIiQFYEyIoAWREgKwJkRYCsCJAVAbIiQFYEyIoAWRFw+uC1
0PjGuQjcbewjQ/Y5f0XbUrAC/C+wHjxP+wuMeRG8BDaAN41DZFGALAqQRQHnXtqOMvY4Y08Y+51f
c3/S+MaVZHxNZgXIrH1k1iHXzbRl8x5yhsj6nMj6XOvPm/wAMBBcCQaBwSABDAGJ4CowFFwNhoHh
YAS4BiSBkWAUuBaMBteBMeCnIBmMBSngepAKxoHxYAKYCCaByeAGMAVMBdPAz4D8jvVd4G5QCn4F
ysA9oBzcC5aC+0AFkN/GfhCsBL8BD4GHwSPgUSC/a/0EWA2eBGvAWvAUWAd+B34P/gCeBn8E6wGn
mfYseA48D14AL4KXwAbwJ/AyeAW8Kr8Lztrl98DfBe+BzWALkN8Kfx98ALaDD8EOo5FMaSRTGsmU
RvmdcTJ9CTuHg73iWnYO+UnBtbbXjdO2P4M3wJvgLfA2eAf8BbBv2DaBd8F7YDP4SETYqsHHIiKs
m3CHxXC9DMSCOHA5+ImIsGMf++Nc13LFBnZsQMY12l/iHjl25JBpjfYPuG4HrNNew3UfqAX7wafM
P8C8g9Q/B18YjQ4hIhyXGacdsSAOXA7iQW/QB/QF/UB/4XYMAAPBlYCYcxBzDmLOQcw5RtNGXDmI
K7Kx0UHsOCNBFOgEokFncAnoArqCbqA7QGcnOjvR2YnOTnR2orOzB7gC6MLt7Al6gXjQG/QBfUE/
wNqcrM3J2pyszTkIDAYJYAhIBFeBPOO00w8WGo1kdaPzbniXAuLPuQb8gfrz4AX6XgQvgQ3gPeZu
BlvAVvr30vYZ4xsAtnRiS+dx2k+Ar+k7Cb4xTrvIN9dYrhOE20WuuH5J/SauNxuN6mwJkOEB+bsC
8ncGiKh1qvU4rcc5cXZx4shPDT9SrYdoPRQcu4yxvxU2Wg/Terj5MzYRZplozOUd/hWep7sGP5H8
TgyysKNZhoFrjGOWn3KdaOyyTDI+tNwAphp74fg5u/+X7P5fup80PnSvBR8ZAXc1+BjsBLvAbvAJ
2AP2ghqwD9SC/eBTUAfqATu8+zPQAA6Cz8EX4BA4DL4EjeArcAQcBQEjEHEH56bFMosn2CLeyi6z
jDKOWK4Hy4xDluXGIfJtMLk2mN5d7seNI+5VYDVYB54xDrk3gJfBq2AjeMM4FF4JHgQrwW/AQ+Bh
8Ah4lDeVMCzzV6wirfEh1pBP4wfFFcheg+w1lptBJsgDy4xa1lEr37KQvwb5a5C/BvlrkF+L/Frk
1yK/Fvm1yK91v0PfX8AmsA18aKxhTbWsqZY11bKmWtZUy5pqWVMta6oVY/FaGV4rY211eK2M9X2P
107htVOss5qV1LES+cnqYNbbjd0oDOskshuFYaFEnuOXyWcRPHoKj55idXWsro7V1bG6OlZXx+rq
8HQZni7D02V4ugxPl+HpMjxdhqfL8HQZni7D02V4ugxPl+HpMjxdhqfL8HQZni7D02V4ugxPl+Hp
MjxdhqfL8HQZni7D02V4ugxPl+HpMixQhwXqsEAdFqjDAnVYoA4L1GGBOiKhTFyPFbxYwYsvtmMF
L/7YbpmIb5YZaWifhvbjeHu5n7eXB7DCZKxwKVa4GitcihWuxgp/xAr34Kvt+Go7vtqOr7ZjjTSs
kYY10rBGGtZIwxppWMOLNbxYw4s1vFjDizW8WMOLNbxYw4s1vFjDizW8WMOLNbxYw4s1vFjDizW8
WMOLNbxYw4s1vFjDizW8WMOLNbxYw4s1vFjDizW8WCMNa6RhjTSskYY10rBGGtZIwxppWMMr7MG3
vsfRdhXazkS75Wj3uMqTLdhmC3apwS412OAS9L+E3ofQfQu6b0H3Lei+Bd1r0L0G3WvQvQbda9C9
hjXUsIYa1lDDGmpYQw1rqGENNayhhjzJ4S11qvwsUu0vXeH+jRhs+blxlIw9TG+VJdd42zIP+EC+
sS/4ydtm9pbN7veMt91bjLfDNxlHw98F/5u3e42vqyzzPr6yd5uEdG3KSRA8oMhR5QyeUBTHAwge
GSoKI4KnlmF0OlUKailWKtNSDkU5TgUUxwxFLYKQWkJDaaGlmDaku0k23U3SlLTJSrrSpNm7gbbc
892Z6sd5Ps+L59Xz4sfax7Xu6/+/7uu6VpqWlViF5/ECVmMNXsRavIS/oBnrsB4teBmt2IA8NqIN
HSjgFWxCEZvRia7Qf+Dn8QVY7/gdbTK+9pL93Wt/99rfvXQ7nW6nj9eX5ephE1ZgNV4KvdZesvaS
tZesvWTtJWsvWXvJ2kvWXrL2krWXrL1k7SVrL1l7ydpL1l6y9pK1l6y9ZO0lay9Ze8naS9ZesvaS
tZesvWTtJWsvWXvJ2kvWXuLDpaFA7bUUXvO3n+NUIloSnS6iBu9v8v4QN0a4McKNEZ9t89nz9++S
Sq2YuL9WTJRH93NnhDsjImwQYYMIG0TYIMIGETaIsEGEDSJsEGGDCBtE2CDCBhE2iLBBhA0ibBBh
gwgbRNggwgYRNoiwQYQNImwQYYMIG0TYIMIGETaIsEGEDSJsiM4WRT1f1vJlbWZa9FberLX6BbL/
ZdnfL4p6URyxf68fsX+vP06D3/JtLd/W8m0t39byba2o6kVVL6p6UdWLql5U9aKqF1W9qOpFVS+q
elHVi6peVPWiqhdVvajqRVUvqnpR1YuqXlT1oqoXVb2o6kVVL6p6UdWLql5U9aKqF1W9qOqjGr7s
FcUtolgvijZR3GLVL1j1lmiSeJeLd7lYl4urEtMR3qkXz3LxLBfPcvEsF89yOXBteCMzEzd5fKvj
XZWfyng1zdwks6v8d0ydnBnGPMpnfhZNyNzsU+5cMndHkzP3hj2Z+8KeSYvxKH6H3+MPWILH8Ec8
jifwJzyJp9CApfgzluFpNOIZLEcTng17rGtm6M7MCtusb0vmF2FH5p4wGn0l82/hucwMXCdLr8fs
0JK5ET/BHNwUHZ75mePtoTNzR2jPLMSd+DnuVePUs0nnh+cmXYDP4EJchM/ic/g8voAv4ku4GP+I
SzAFX8al+Aq+istwOf4JX8MV+Dqu1ImuwjfwTXwL38Z3MBXWPMmaJ1nzpJ/iJsyFtU+6Gf+OeZiP
W7AAt+I23I7F4ngUv8Pv8QcswWP4Ix7HE/gTnsRTaMBS/BnL8DQa8QyWownPhue5fS31fhY2ULGQ
uds9ZUYejPC/PJ4bg1GtT/RwqMyhkcwNlbyJ3uEbW32je/wb/8qpJk41ZX5gcpxJ+escr8cPTWQV
X2/wzdlmpxvxE8zBTSHoQk26UJOrjWZu49odoYuLXVzs4mKXXGiVr23cLHKzqCM16UhNOlKTjtSk
IzXpSE1cbuJyE5ebuNzE5SYuN3G5ictNXG7ichOXm7jcxOUmLjdxuYnLTVxu4nITl5u43MTlJi43
cbmJy01cbuLyIJcHuTzI5UEuD3J5kMuDXB7k8gCXB7g8wOUBLg9weYDLA1we4PIAlwe4PMDlAS4P
cHmAywNcHtBVm3TVJl21SVdt0lWbdNUmXbVJV22SBUVZUJQFRVlQlAVFWVCUBUVZUJQFRVlQlAVF
WVCUBUVZUJQFRVlQlAVFWVCUBUVZUJQFRVlQlAXFaBoHeznYy8FRfj/NxYpzrZxr51zKuZRzKecq
/h/A/z9yr4t7XZlb1IrKzr09PMzBbg52c7Cbg90c3MzBPnnyHBfbuNjGxS4udnGxi4tdXOziYhcX
e7nYy8VeLvZysZeLvVzs5WIvF3u52MvFXi72crGXi71c7OViLxd7udjLxV4u9nKxl4u9XOzlYi8X
e7mUcinlUsqllEspl1IupVxKuZRyKeVSyqWUSymXUi6lXEq51MWlLi51camLS11c6uJSF5e6uNTG
pTYutXGpjUttXGrjUhuX2rjUxqU2LrVxqY1LbVxq41Ibl9omVearp9GIZ7AcTXjWXHUal8pcKo/v
xpuig7kwyoUxLoxxoMyByvw+Rt0x6o5Rd4y6Y9Qdo26ZumXqlqlbpm6ZumXqlqlbpm6ZumXqlqlb
pm6ZumXqlqlbpm6ZumXqlqlbpm6ZumXqlqlbpm6ZOmPUGaPOGHXGqDNGnTHqjFFnLKq263foMbnM
LXrLgsqKHfWZaKrY+sTW97faMdsd6I34CebgJp+0f8Q6UIlTpvXJtD6Z1ifT+mRXIrsS8Q+If0D8
A+IfEP+A+AfE3yf+PvH3ib9P/H3i7xN/n/j7xN8n/j7x94m/T/x94u8Tf5/4+8TfJ/4+8feJv0/8
feLvE3+f+PvE3/f/UCMS2ZfIvkT2JbIvkX2J7EtkXyL7EtmXyL5E9iWyL5F9iexLZF9C3wH6DtB3
gL4D9B2g7wB9B+g7IPsS2ZfIvkT2JbIvkX2J7EtkXyL7EtmXyL5E9iWyL5F9iexLZF8i+xLZl8i+
RPYlsi+RfcmkZ8fvtm8Kw+M/z34fr1JepXb3oN3dS/uU9imNUxqnNE5pnNI4pXFK45TGKY1TGqc0
Tmmc0jilcUrjlMYpjVMapzROaZzSOKVxSuOUximNUzGmYkzFmIoxFWMqxlSMqRhTMaZiTMWYijEV
YyrGVIypGFMxpmJMxZiKMRVjKsZUjGl0kNpXkoH7ZOC+Svcb32G3eO12uXq3T10Z9nF4H4f3cXgf
h/dxeB+H93F4n9ntWvOM2i/LJ+/P8l5ZfrgsP1jf/OsOnhWdmLkhOkrXG/PuKVQs/f/YoeOTX2XS
Wz3+qBLjaJT16DWPXhPt3ugfrbFojUU6lOlQrsyJoplo96V2XyqqnDUfzP2t1p1yf5j7w3Zeauel
dl5q56V2Xlq3bDwriuIqiqsorqK4iuIqiqsorqK4iuIqiqsorqK4iuIqiqsorqK4iuIqiqsorqK4
iuIqiqsorqK4inwp86XMlzJfynwp86XMlzJfKpUptXNSOye1c1I7J7Vz0kkVT+8Zz6phWTUsq4Zl
1bCsGpZVw7JqWFYNy6phWTUsq4Zl1bCsGpZVw7JqWFYNy6phWTUsq4Zl1bCsGpZVw7JqeFzf16mY
0ncsOizzpPuUFeGFzHNm65VhZmZ1+K/MLr2yFO7MvBZasnFIsrlQzE4OA9nDcDLO8tpnw+/G/6x+
SnRQ9stRvP8nd4Mc+41z/0GmPmdyX2mOWxV2Z57HatV2jSx+yfS8zqTsTjKz0bENfXK1PzrEVdsz
ZezG664SuRuvQS2ODOXs6WFb9gycibPDSPacsC7+bRiNHw0t8R/xJ4+fdHwqbIob0Oj5CseVIY1X
4Xm86LXWsDvegDw2er/gtVew2fNO9DhHEsrxkPOXUA7b4t0Y89prnodQzuVweNiWOwJvxts8fzve
6fExOD6sy50Z2nMfxEfwVVyGy/EtfBtX47HQklsd0px15ZrD7twG392ELvSH9uh8io5QdJCaG6m5
g5o7qLl7v5p5aq7br+Y6aq6j4g4qJlSsKLiTgjspuJN6u6i3i3q7KLeVcoOUW0e5dZQbpNw6yuUp
l6fcIOXylBuh3AjlRig3SLkdlNtBuR2Uy1NukHKDlNtBuR2UW0e1rVTbSrVdVNtFsa2U2kWpXZTa
RaFdFNpFoa0U2kmhnRTaSaGEQgmFEgolFEootJNC6yg0QqFBCu2g0C4K7aLQLgol0bGZxeG7mSdD
o0xeQZn/pMwbFBnKdMrovmhWpj88JKu/nhkNv5XVn5RbL2Sz4flsdbhLhl8kw9tk+EnZg8KS7ME4
zOOjo+9ljwuXyfiTsqeEz2RPDbNk/hny7hfZc8Ps7HnhCh3o5+6Lt7ovrvye32+y08Kz47+lMNlK
Kn71Wc1WVx7iyXZX7nW1IVdLXS11lTR7tLvrkx3PwiXROfbTR3x7sUq3wr5YaR+tDuvFUhbHMc7U
6iwvOstGZ9niLO3O0m6tk5yl3Vny0YG+ucY3t/nmU751qG+td/3NvvmsbxZ8s8s3C75Z8M2DfHOj
b3a48/6N66zUI1apy89jjcx7yTS9DvaKDNsiw7Y460TfzMqeLbJni8zZInO2yJwtsmaLrCnLmrKs
KcuYMRkzJmPGZMwWmTImU8ZkyhbObuFsOVf5vbuMsx7orHUiqGT8YrEvtZ4/Y42MvUR8l9qry53z
77Oyy/NXnUOGOMfKcE1lX7grWEz5J+2ElWGtV5ozL3Mh75ydHLgkrHeu9dFVrnS/T862v7p9+glX
XOCKC3xrBxX2UGGPb2+kQpkK/3OGjY5t6AiPOdtS2dWSGQxrs3WIw3babqft9uzhOAJvxtEUe1d4
Jnssjgt92RO9dhJODj20782eE9VkP+r5eWHH+E9bKr9d8tX/+WmXfdpN6SFKD9mn3dQeonaZ2mX7
tJsiC6heUeV+qtxPlfvt1W7K76H8HsrvoXzZXu22V7s5sIcDeyi3gAtD1FsQD0U18a6wPR5FyePX
oppcVXgmVxe25w7BoRBT7mi8A2LJHed4vM+d4Hii558Ka3MXhsdyF+Gz+I7n1+CxMMSd++3fbk7v
yRV9fjM60Y2t4bFokqzdLGM7Mi+NZ8KZFHv/+J9Wfs1qnooycQNWYGOU0bP+J1O382iQR4O+Ua2+
9atv/epb//+RgYN0GKRDpU4Nin1QbepXm/rVpX51qV9d6leX+tWl/v0ZOajO9Ksz/epMf9Vbqu4I
i6oW4k78HL/AXbgb94RFVjRPJt0li/4ii+bJonmZZ+TecqyQf6tMWM9jdVgim3ZlWr2eD52y6MZM
Qe16BZtQxGZ0hpszXY492IpX0Yvt6Isuk3V/yiQeD2Aw3J7Z4ZhiKMzI7MSwxyPYFaapey06QoeO
0KEKXKr+PZ/Z47292BeeybzhGEJjtgoZZDEhzMhOdKwOD8vs27OTPI7DxarHRhl+sVp5s1p5c/aQ
cKtsv1i2Xy7bL5ftl+vVC7NHhfuyb/HeW3F0dGn2nY7H4F3hGrvgGrvg2uzxnp+AE33/JLzb4/fi
5PAlNfdaNfdWrs7h6hyuzrFTLlB/H8i+z+vvxwfCTdkPOn4I54QF2Q87fgTnhuvspsuzH/P4PJ+5
JNy9/7fWltpZt8uro+TVUer1U+r1b6q3hEU178KxOA7H44SwqPbBsOiA8/DlsCheEtbGj+EpHa0B
y8M8u26XTJsn0+bJtHnxau+vwTqsRwtao6PiDchjo89v8loRmz3vRJfvbfH8VcfecGu8Hf1IwsJ4
INynmy6Id3o+jBHsChfbpRfrsAtk8RxZPMdcslCXXRC/Hm6K92Cvz4Ww0A6+JpcJt+aymBBuspsv
NrcszB0Y7ssd5LWDcYjXDgUP7YY5dsMcu2FO7kiff5vPvh1He+8deKfXjwEPc8eGRhXgYl18gQpw
uQpwTe4kr70b78F7cTJOwak4DafjDJyFs/E+vD/MyH0AH/b4XFXko/iYx/+AT+CT+FS4Pfdpx/Nx
gfc/43hhuFGluVGluTH3Oc8/7xxfwBc9/hIuxj/iEkzx+pdxKb7i+VdDh0mjw6TRkfsn5/ua167A
13ElrsI3fPZb3v82vuP6U702zWvXePy8qrY6zMs1R0fleJ3jdY7XuZdhX6scc3IFGm9yLNJoMzrR
5Xm34xbn2Wrd9rMJpiOXeD6AQewIM6LjVJLrVZKlKsf28Ul6tR60JuzdP9XMVQG+pQI8Y3c32N0d
+nvJzn7Mzu6xe9fatZvs1kft1nV260K7tdlubbZTF9qNV9h9T9pld9hla+2yZ+ys/7Cz8nbOi3bM
k3bMHXbMyv1/92De+G9gXqnGLbOyp3TL9Rn38la4Tq1bodatsMqSivx7FbldRW632qfVuW265sN6
7/bxGWajx23oCKtF0ay27RZFQf3aJIKBv06tonjF5NorirLptdf02qsGbVI7impH0Qr3WWHlt0hX
6I7r4/qQ6JAP65AP65DrdciH7dNt9uk2HXK9vbrCXt1mry6zV5fZq8t0yPXxWt97CS+jNbTrEu26
RLt9uk23XK9brtcx2nWMdvt0hW75sH26wr4q2gNFOV+U37tNsb2m2F45vNsk2ytvd8vZTXJ0tRxd
LUdXy8vd/2vCvdLzq/DXSfc7Pn+1717j+Fh4WH4t0zHX60TtcmW1XNk9Pu3+RFdp0VVa5MZfKL5X
bjxD6Q5K79VVWqi8l8p75cgZukGrbtAqT14anwHL3t+N13ShfSaqiN8TQiuVX6RyZbJ8Sc4U5Exe
zpTlTFnO5FX3vOqeV93z8ucU+ZOo2nlVOy+PmlXpZlW6WZVulkvNKnNRRe5QhfOc2at6tqielbu0
vdzZy50O7nRwpUPVbFE1W1TNFlWzRdVs4UCHStmiUraoji2U36sSdqh+edUvr/p1qH7Nql+zyteh
8hVVvqIqV1Tl8qpaXlXLq2p5Va1ZVWtW1ZpVtaJqllfN8qpZs2rWrIrlVbEOVSzPyRdVpFYVqZWj
L3LzRVWpXVVqV3naVZlWVaZVRWlVUVpVlFautnC1hastqkm7ytHK1RautqgYrVx9kaN7VY0W1aJF
tWhRLVpUixbVokW1aFYpmlWKvEqRVynyKkWzSpFXKVq53qJCtKoQrSpEqwrR6j6+LzqYEzlqj0Zn
25GpXLjO7ltk9y2y+3rkxCw7rMz33/J9Kd+X2lmDfC/wfTHPF/N8sR2U2jUpT2bxZJYdk/Jllh2S
2hWL7IpFdsUinsyyK1K7IrUrFtkVi2R/mWaLabVY9pfptZheBXoV7IIyzQoyv0yjpTRaSqOlNCrI
/rLsL9NpKZ2W0mixbE9l+yKZXhbzUjGuDP8uu3tF0ODZLtWkFB6Uu3qnyEY96xVZn8j69v+8oFnN
SETWLLJmqxu1umara7a6UatrtqpRKxq1oj4r6rOiPqsZtZpRq+mzmj6rabaKUavoc1fUo7KVxieo
TlfqrNRYGqau1uJqo67W4motrlZytRZXa3G1kqu10CKlReqqJVqkrlxy5U5X7nTlTlqkrl5y9ZKr
d7p6p6u3uHrJ1TujOnXyVyLPi7rNlUddcbva16g6t6vOBTWwcbw6V++/z+zyyX73khe5lzwte2l0
xrhyXd4peqf7b89er5wxmuhZJboez3Y4/zrn3xFlTEiVP6M+01zeIbMGaf16GFaDR9W1UXUtVddS
dS1Vt0bVrFE1KnW2TlW8pDu8bu9n1Q76RMc7R5d3KrPsTuda5hPbqDlCzRGf3EzJIhWLVCy6RuXv
jS0R1+8pupOiRYoWKVr5KUGRkjutYZk1dFlDlzV0UbXy04MRqo5QdYSiOym6k6IjFB2xxmVULVrn
Muvsou5O6o6Ma9Ej1oxYM9ER1rnb2oatLbW2dH9ODYtiwPqGrW/YeoatZ9hahq1htzXstoZKbU9d
P3X91HVT101dc9j1KnU7HVdhFRXWUGCNutyjLve4fjvlN7rSmDrcI/rKb0ds+Dt3N1jfBOubUPn7
DGpTj9rUQ4E1rr7K1Ve5+ip1qUdd6lGXetSlHnWpRx3qEfkaNahH5GvUkh6rWaWW9KglPWpJj1rS
415Zf7OSHVbSJ9YRK1i4/8/7K/fJlb91uEEv6XCP3KnT9zhu1W8Gw0pqLaHWE9R6Qgwr7IsOij3A
+zZn2ka1B6j2gLhW7v8ttVaudpsIOyj5ACUf4Gw3NR+wVzrslQ4Od4tvpf3SIcZuMXaLsZvL3Sa7
DpNdhymug+JPUPwJij9hH3VwvZvr3dR/gvpPiH0lBx4Q+0pxd3O9mxNPRG+hfoH6hf0/GXlt/Ccj
URjkQMGKB6140OoGqV2gdsEqB61wkMoFKheoXKBygcoFKhcoXHClQQoXqFugboG6BeoW5FhJPX49
dFayKKry7JfyrfLzgLNDb/RO90pD5ppt5pptuuiYLjqmi45V3tVB27Nf5cHXzCGJO/Uhc0gJ5TCm
842Z+4d0v3az/pCZZJvZfki3G9PtxnS7MfP7kPl9SKcb0+nGzCyVn0u2m1u26Tpjus5YrvI3y2qs
4GkreHr/zvuVsz3t00/75NNRlbXsiD40/v/EWog78XP8Anfhbtxjr8dqYk4GTVZ/DhLVwTjM48Mp
egTejCPDXnNDv7mh39zQr3v1ibLbnDAoy15xJ1Z2J1Z2J1Z2J1Z2J1Z2J1Z2J1Z2J1Z2J1amRGUW
6DYL9JsF+inSTYm9lOimxF79v58Se80A/WaAfjNAPyX2UmKv3t+v9/fr+f2U6NbzB/Xdfn23X9/t
13P7x+Mdpkkctoplm1jGxDImlm37f/69Y/wz26M3mZ3f4FqZa2Wulfc7toFjG/7OrTK3Kj85budO
mTtl7lR+UlzmSnnckQ2Om9BV+V2H8cx4M0+6edLt/MPOP+z8w97pdo2icxedu+jcw8497NxFnnU7
/7DzDzv/sPMPO/8wH7tdozKtdrvOsOsMu85wVC2aoewHoonx69gTTcxNwJHRxEr912W+JsLK32Fe
KSOWRUfSo5sePXTo4emrPH2Vp6/ys4efPc7WRZutvHyVNz286eFFDx96+NDDhx7699C/h/49tH+V
9j2076F9D+17orNdZVQWjbjSqCuNutKoK4260qgrjbrSqCuV/5cqZ3n+gXH1e119VPf7uO53iihe
EcUr1Oq1olErGqVa79+p1mtyLJscyybHcq7S3w7BoXDt/6Xmkd4/2mvvwF+VPc7j483sJzj+Vdmi
x5vRCSqLatRe/7+p/Ha7YZTLnVzuFE+XeLrE0yWWIVk+ap1d1tklu0etc8g6h2T4KKc7rXdIllfW
2GWNXdbYZY1DMn1UplfW2GWNXdzv5Hyn9XVZX5c1dY3/faETsldEJ0T3Rt8M90bfwrcxI8yOfhi+
F/0IP8Ys3ICt3nsVvRgJD0WvhTui17EHe7Ev3FF1YnR41Ul4N96D9+JknIJTcRpOxxk4E2fhbLwP
78cH8EF8COfgw/gIzsVH8TGch4/jH/AJfBKfwqdxPi7AZ3AhLsJn8Tl8HtOiI6qeDc9UrQgNVc9h
JVbheawOy6vW4EWsxUth+YQHw/cmPIRfodnzdVgPsU54AyHcMfGwcO/Ew/Hm6PCJR+IovAVvxduQ
hO9NLHt/N14P36s+Ex/DteHe6pm4DtdjdphdfSPmeu++6PDqV8Lymig6vOZ0xzNwZmioOQsfwbme
fxo8q+FZzbRwR82vsQQDng9iB1KMhodqSuBVTQj31laFO2pz0eG1B2IyDsLBOASH4jC8CUdATLVi
qhVTrZhqxVQrptq342jMDstrb8R/evw7xxccdzimoeEA/h1A8wO+EpZH/xQdYjo9FIfhTTgcR+AE
nIiT8G68BxfiInwWn8Pn8QV8EV/CxTCZRF/BN8MimbtI5i4az9zv66w/wLWYievww/CIbH5ENj8i
mx+RzY9MmB/WT7gFC3ArbsPtuAMLcSd+jl/gLtyNB33vIfwqPML1RRO3hPUTt2E7+pF4fafjMMre
343XwyPVNWF99UE4GDSopkH1MXgXTsVpOB1n4EyfP9fxY46fdBRz9XcwFdNwNa4Ni2TOIpmzSOYs
+lvm/CT8snoO5oZHap+saBMtDC3Rnfg5foG7cDd+i3r8Fx7BYqzFS/gLmuEuNXKXGrlLjdylRu5S
ow3IYyM6sDU8riY8riY8riasjXZhFCWUsRuvhSXqxBJ1Yok6sUSdWDKhL7RMcEc7IcEABrEDKYaw
E8MYwS6MovK9NxDCEvvt8ZoLQ0vNF3AJpuDS8b8fvbbmCsev41s+821MC0tqrvV8Nm7EHPwUN4M+
NfSpuR8P4EE8hF/h1773e8cljsscX0ARm9GJLgw4/yB2IIXY7bW1NWKvEbs9t8See7w2CmvtuyVq
4YToIFX/oKgaNahF5d/1rcMkxMjhQKiCkV0kx6fL8elyfLoc/64cv1KOXynHr5TjV8rxyv+R6wB5
PlWeT5XnU+X5VHk+NfppNDm6CXPxM9yMf8c8zMctWIA/u84ybA33cPQejt7D0Zs5Ooejczg6h6Nz
ODonMitydRZXZ3F1FldncXVW5f8oWvUfWARqVlGzippV1Kz6NR7Gb/CfkIFVMrBKBlbJwCoZWPUo
fgeqV/0BS/AY/ojH8QT+5B78tGhyRhfJnOX4UZwfpmcuCNdnLsQXo0Mz08KdmavD/Mw/o/I3Db4a
PpO9LHzfFPCZ7BWO3w9rsy368cvRYdkN0THZjea3tqguuzXsyb5q5uuNTspuc9wevTebOA5Eh0z4
fnTQhB/gWszEdbgeP8SP8GPMwg2YjQfDVLViqloxdUJrNHnCBuSxEW1oRwcKeAWbUMRm0FKmz5Lp
s9SZ6RPfFFpk/D3qy9SJpegAtWW62jJdbZlaLZeq5Uu1fKl+K96Gk3Gm985yPAc6qHoytfo8j68N
09WO6WrHdLVjutrxXbXju2rHlWrHldU/jQ6ovglzfZ5f1fyqrmT8iTgJ78Z78OHx3TbHLrvHLrvH
LptV8+Nocs0syKkaOVWzCL/2+mLH3+lkSzx+yuMBnx/EDqQYDTfbNTfbNXPsmjk18qvmNcgvu+ce
u2eO3TOrNhNNrn1HaKl9J47Bu3AsjsPxOAHWWWudtdZZa52178XJOAWn4jScjkecy7pqH8VKz1fh
+dBywKdDS90D4fq6h7AyzK97Hs3R5Lp1WI8WvAye1vG0jqd1PK3jaR1P63hax9M6ntbxtI6ndTyt
60QXurEFPdiKV9GLbdiOPvQjiSZPWhEdOuk5rMQqPI8XsBpr8CLW4iX8Bc1YB512UgteRis2II+N
aEMHCngFm1DEZnSiKzo0nh5NPvDz0aEHfgH2k0lxfZTNbh2/J1gfHetRTeZ4lSwe/7fGq1GDWlT+
X7J1mIR4/N+zjlWyWPd3PRyGN+FwHIETcCJOwrvxHnzIFc/BhSExBSSmgMQUkJgCElNAYgpITAGJ
KSAxBSSmgESFnKFCzlAhZ0RTQxpNw9X4Z1yDf8F38T38K6aj8i8EzQjXq6bzVNN5quk81XSeajpP
JZ2ikk5RSaeopFNU0ikqaaySxipprJLGKmmsksYqaaySxipprJLGem5Bzy3ouQU9t6DnFvTcgp5b
0HMLem5Bzy3ouQVVN6fq5vTeRO9N9N5E70303kTvTfTeRO9N9N5E70303kTvTfTeRKWer1LPV6nn
R9s970PlzwYSDGAQO5BiCDsxjBGf3xXmqupzVfW5qvpcVX2uij5dRZ+uok9X0aer6NNV9LyKnlfR
8yp6XkXPq+h5FT2voudV9LyKnlfR8yp6XkXPq+h5FT2voudV9LyKnlfR8yp6XkXPq+h5FT2voudV
9LyKnjeT/8lM3mgmbzSTN5rJG83kjWbyRjN5o5m80UzeaCZvrPpLVFfVjHVYH9XpBjndINYNcpkP
he06Qi7zD47nhxt0hat0hat0hThzWUgy38S0cLPuMFN3mKk7zMz8S0h0iLN1iKt1iLN1iKuz/xZu
zz7tnnd5lMuuCNdk14edusUhusVRukWiW2Sz7e41t7pHfVUn6dVFKv+iXOL1AdX/+1GsW8S6Raxb
xLpFrFvEukWsW8S6RaxbxLpFrFvEptHENJqYRhPTaGIaTUyjiWk0MY0mptHENJqYRhPTaGIaTSbc
E9IJ9+I+3I//wCL8Eg/gwTBFB5qiA01x79Lo3qXRvUujbhTrRrFuFOtGsW4U60axbhTrRrFuFOtG
sW4U60axWS0xqyVmtcSslpjVErNaYlZLzGqJWS0xqyVmtcSslpjVkgkllLEbY3gNr2MP9kJu6XDT
dbjpOtwMHS6vw803URdM1AUTdWKiLuh4UyamITVVF0zVBZ1vhs43Y+KY117D62GKDhibsAvVtSGt
PgB1mIQY6o/OGJu+C6bvgum7YPou6JRxdeVvpx/j8btwvM+egJO9dqrnp+F0nIEzXeMsr3/I++c4
fiQ61IRe0FGn6KixKb1gSi+Y0gum9IIpvWBKL+i0M3TaGTrtDJ12RvUPff9H+DFm4QbMDtfrvtfr
vvN033m67hRdN6/r5qv/K6qrXg457l6wURfOV/dEdTpxXifO68R5nTjv/rDR/WGj+8NG94eNOnPe
PWKje8TGmk/5/Kcd1VKzcmJWTszKiVm5oHvPNSsnZuVEF5+vi8+v+Y7HUzEtTDczJzUzcR2uxw/x
I8hdXT42Tyfm6YJ5OjFPJ+bpROePdf7YXJ2Yq5MauVojV83XiWkgNmMnZuzEjJ2YsRPTwXTTQWw6
yJm1ExPCdBNCbN5OzNuJeTsxbyfm7cS8nZgc5psc5psc5psc5tfIvxr5VyP/auRfjfwzTcw3Tcw3
Tcw1Tcw1RUw3Rcw3Rcw1RUw3RcSmiLwpIm+KyJsi8qaIvCkib4rImyLypoi8KSJvisibIvKmiLwp
Im+KyJsi8qaIvCkiX3tdVFd7PWaHRvfBjaaK2FQRmypi98ONtb/33h+wBI/hyZCYNvKmjbxpI1+7
0Ws7fC7FkMc7ozoTSN49c+MBl0V1dfeF7XX3YxEeCFeZSq6q+7XHy0NS14QVWBlmmlJm1q32WA8x
reRMKznTSs60kjOt5EwrOdNKzrSSM63kTCs500rOtJIzreRMKznTSs60kjOt5EwrOdNKzrSSM63k
TCs500rOtJIzreRMKznTSs60kjOt5EwrOdNKbFqJTSuxaSU2rcSmldi0EptWYtNKbFqJTSuxaSU2
rcSmldi0EptWYtNKbFqJTSuxaSU2rcSmldi0EptWYtNKbFqJTSuxaSU2rcSmldi0kjOtxKaV2LQS
R0dGt4VP/N2/2LSi6q34WjSl6uvRJVVXRj+uuir6eNU3ok9WfTO6JHN+dFlm2vi/3/aJ7KXh49ll
4bfZ5eGibI97hK1efzWk2W3hjmxfWJPtj96STUJrdiCUo3e6ygHRo6E9WhXaXe0aV7vG1a51tWtd
7QJXO9nVPuBqJ7vaqZX/p6CrHexqB7raB13tXFf7QbYxLMs+g+VvDGSfDU/pN+3Z58Kq7Mpwm1XM
tYKxbG/YZhUftIrbrCJrFb+0ipVRbXZd+E22xdrcoWdbwzeyG8Kfs3nfagubdChaWeNT1viUT35F
H1vv03f79I+zrW+84dO/8ukL9LQnfeM637g/Oia6LTq7KhfVVB2IZ8Ns3fVtuunHMp91r6UyZL6r
wy6Ojs2sDOdlVoeLMp3R2f/N3HXAV1Fs7zMze3f2lk3oJLTQQhURRRQQgg0VBEQFka5iAbEj+lTE
+lAszwZoRH0PK6hgoWhAqgEJIaEltFBCSEggEEFKgJD5fzP3JpQEAsHy3/19u7PTd/bMN3Nm957L
D6ghoiP0pzkUwKh5Ie7ie5T2G/QsIVZBh0pR0zFqelBCIe4qBSPnM6GRU4R0LYG7yxI5uLOd8N+l
drOmZKk48gA2IAEH8AI+wA8EABcIA8LVHKoAtFMbqD3wolpMLwEvA/8GxgCvAK8CY4HXgNeBN9GO
P6tNFKc24TluwHPcwCoAFYFKQGWgClAVqAZUByKASKAOEAXUBeoB9YEGQEMgGmgENAZGqTT2LDAa
eA54HngBeBF4CXgZ+DcwBngFeEuls7eBd4B3gfeAccB4YIJK5xepWbw1EAP0VPP4q2obH6u2QXJv
NXY1txvbmt+hRXMhLzdBXgrEwcJscUhdLfKVIw4XHhJHCjeKo8oWBYU7xDEVIwrhr1SE5SnMtmx1
tSWVYzmFhyxv4UbLp2zLX7jDCqgYy4V/GOKNUHHW48BI4AngSeBfwFPA08AzwCjgWWA0MFVtsKYB
3wHfAz8APwLTgRnATyrN+hmIA2YDc4BfgLnAPGA+sABYCCwCfgVWqcXWamANkAKkAmuBdcB6YAOw
EUgDNqnFNmTJhrzYkBcb8mLXwrk20AJoDbQHOqgN9pU4j1dp9n+BSbiehjPqY6M+djyuFwNL4U4A
UuBOxRm9zV4HrAe2Aukq3d6OsAPAUaAAOAYUAkptkJEqTdYAagK1gAYqXTYEooFGQGPgGbVYjgIg
qxKyKicCU4Bv1CY5Uy12OPCASnMeURucETi/h/M4nD9R6c5khCGu8zWwGX5bANTLSQf2qjTvlSrd
exswSG3wDlYbfJPVNt93wA/AdGAmEAcsV7N8SUAysAJYCawCVgNrgBQgFVgLrAPWAxuAjUAasAnY
DGwBtgLpwDYgA9gOZAJZwA4gG8gBdqpZ/rfUNv/bwDvAu8B7wDhgPDABWKDm+RcCi4BfgXhgMbAE
+A1YCiQAy4BEYDmQBCQDK4CVwCpgNbAGSAFSgXXAemADsBFIAzYBm4Etal7gEfOb/3lhNwHoe2SB
d78Di+4UKeC9taqAekF/jIX+GAv9MRb6Yyz0x1joVwnQrxKgXyVAv0qAfpUAdt3DFqv10HNyoefk
Qs/JhZ6TCz0nF7rL+9Bd3oeukghdJRG6SiL/TB0G664B26YXfTshIqGbLFCx0MzrgNu3gGnfwdw/
FnP/WMz9YzH3z8XcPxdz/1zMuxMw707AvDsBc+tYzJ9jMb+NxVw2FnPPWMwztRW/XMwntfW+9bKN
sVOWizlkLuaECZivJWCOptc19XpmAuY9uZj35GKuk+vMVusxl9HW9nK9fdV6zFfex3zlfcxPEjE/
SQwsUocDvwLxwE71eyAfUOp31wVqA3VO+X6j6LuNJeqw+U6Dg9W+wfjwKoWLOGorZtMAMY9ai/kU
gfufKRZidF5EjUUSdUdbdIe+5sHIE4DOVkGsoVZol80YgephzNxGHTC2ezHudMe401hkU2fkuyi0
1ncBSlqAklLUeFPmPoQNw+ik7QSmYFaQo5KIsaEUgyefrPOl9sjtRvDsDcg76NMKLHwIvleBhXeD
hfcZy4+71GHkmIFScuhys5YSgbiNzNpKK9SmCUq/EFfJdBlqHokwD+6hF+rdRy0XI3DPC9QCq4Ox
j94HY+sClYjY4CTMG/JwlYar4ZhdzMc4vEAtpcZkoZYewAYk4ABewAf4gQDgAmEUI3pRVejBM6AD
z0AuHaD/JiOntchpFfTZGOizMdBnY6DPxkCfjYE+GwN9Ngb6bAz02RjoszHQZ2Ogz8ZAJ4uB7hUD
3SsGulYMdK0Y6FYx0KNioEPFQG9CXUxd49R+lJSGu8gS8yC989V6lDgDM6BduPcRdAGedVWE7td3
i3sPo0psBTVkK6klWmaAmbP1Rax+1E8MNPYP+4nhKh4a/FIxUqWL8dRGTADi8BxmUyOMkN9abamV
pa23C6SKRopolHMJnuYIqoeSdmtpMiV50J/WY66Ui3nSYfPsU/U/vcF3D67yzOwrF08rHAywCnEK
wAIFCNmj4+mZDkpIwtNOhgSmgBcgHWovUuchz914wpWR5iBC4kPx83WOKDUZviuQ80rc9Sr4paD0
YIwCE0NLmY0YBxGjICjj2uIq8l2rjpparUCMdqaeqzCf0qFrVCrkqQpmeUdRQjAPJ5R7llir30iY
eq7A1Uq1C+mOhu46AyHbqD56Qh5k1IceUwM9pgL6wRxiOOYZa+f5kPJCob9xEojtICbH1Xrcvb7K
QF2zELIDeeRgzrkTobu0LQf0k0KEHkbuhcHc0W+ykVsOJF7Ps3X6CohxKBRD21J1ELrVWO5HzVQi
ek/jYCh4WIdmo1xucstRWaYP6/y0nfB8tPsxtQVzm92Yy+h34MdUHlz6WR5ErKNAAVr9mEq2PCof
8558y6/2I0ayibsKLt1mR3B1FCUeQ6sqVWh5iSNuIUJTMTcqRI0PIvQQnk4+nuNh5BjMWadIQYoC
5F6IWVYBapJrOSghWJLOIQU5FOCZHkLr5qO9DiPVUaWQMtuUZRNDqjykKkQqhRTZpsxKKDNd6P9m
yMfc/zBa/IhaY2pZgF5cqHJMao9KRw4cOWxEDgctr1pjau5XazGzyzE52cghH+VtFoUmZj7K2Gy5
pr3zIR9HzH2sR0gW0us6r6cwqwp5raqoVwTS1KAKFuY1Vi1yrNpw10FYFMLqI6whrqMR1ghhjSF3
llUNJdREaF2co/EsAlYVXFVVe6zqOi+UUBMl6bzqwD8K/vV0PvCPhj/yIdvEjiCfyUfHqA+3zqsS
6sURmmlVg091IIKiUL9KiJmJPKNQP476caTKtOoivB5QH/4NEScafo3gbqz/exC5pKGuwTuMRF1r
kCeUi06dhvoH77ABwhoiLJia436rAFUhc9VQ5wjkWwP3UlP9gZQ+lI/7QngUwusivD7CG8IvGuGN
EN4Y94e7UDuRQz5y2G9VByIgaZGIXQPPsxaeY23ccx3EiUKcugivB9RHnAaIg1ml1QhxGqN36ucU
MO0aQVVQD91i+ahHFdTDj3oETNvWx3VD04L5qEMV1MGvnwqJ0NMNtnOw9rr1ROjJmjYP1ZpjPDtY
mINeMAhSUwsS2Q06Rx4k8lroHDshQUMglVGQyvbQOXLQGwZBompBKrtB58iDVF4LnWMnpGsIJDMK
ktneqlJ4BK3QAq3QHK3QwooozEcrtEAr6Od5MVqiMVqiqVUH8aLgXxfx6uFcH/Ea4NxQ6Wd6MVqj
MVqjKeYA0CExLsRgFhGG2UNlMKPWV6PBHpeDMxZjHAgnFzphMnT7ZOj2ydDt20O37wzd/jXo9p2h
23eGbt8Zo9FE0Rtcfht0+T5qokkVh1RxSBWHVE3LSBVvUmmb2WuNb9HVd8VXnFXEiN6CiNph/GxG
V2K/iLrSLdSKetNt8L2d7qEr6D56nbpAi59CD1EczcXVfOxvUwKl0ju0DvsnlEGZ9F/awRh9ylxW
leaymqwmLWF1WAv6jd3IutE61oP1oA2sL+tPG9kgNog2sztQ5y1sOHuQMtjjbCxlsdfZ+1TAYrF7
2UTsPvYxdj+bzKawAJvPklkYv4hfzOrw1vwyVo+34+1YNO/IY1gjfjW/hjXhnXln1oxfz7uy5rwb
78Za8p78FnYR7837sEt4P96PteGD+CB2GR/C72aX83v5vawdH8ofZO35o3wku5I/ycewzvxV/gbr
zf/Dx7N+/H3+AbuLf8a/Z3fzH3k8e4wv4ans33wdz2DjeTbfxSbxPP47+4JjDs2+4of5UTaVK0Hs
e8GFYD8KKfxshnCFy+JEuAhns0UlUYnNEdVEDfaLqCfqs4WioYhmv4rGoilbLC4QLdhS0VK0ZMtE
K3ExSxStRRuWJNqJ9myl6CA6sdXiKnENWyu6iR5sg7hV9GGbRF9xF9smhosHWK54VDzB9ohnxDNs
v3hWPMsOiPFiAjsopoqpLF9MF9PZYTFLzGJHxM9iETsqksRajvFP7OIYbYTiNSyPFcYbWlWsJvxC
q4PVgV9tjbDG8Gussdb/eB9rqjWDP2z9ZM3lT1rLrWQ+2lplZfIXrGxL8fGeME8Yn+qp4KnAp3mq
eKrx7zybPBn8R0+WZyeP8+z27ObzPL97fufzPfs8f/AFngOeI3yRp8BTwJd6lM14gi1swZfbHtvD
k2xph/Nku6IdwdfZNewafKtdy47i6XZ9uwnPtJvbHXiuHWPHcGVfafcUZN9uDxIV7Xvt10WE/ab9
luhov2uPE1faH9gfiGvsD+2J4lr7f/YX4jp7ij1FdLOn2dNEd3uGPUP0sH+yfxI32bPtX0RPe749
X9xqx9uLRS97qZ0obrNX26tFPzvF3iD625vsbeJOe7u9XdxnZ9s5Yqi9zz4g7rePShIPSb90xeMy
UjYXT8pWsp14TV4hO4px8lp5vXhfdpVdxUTZXd4sPpK95O1ikuwv+4sv5SA5SHwl75B3iMnybjlM
TJEPyofEd3KEHCF+kCPli+JH+bJ8VSyQr8nXxWL5tnxH/CbHyfEiQcbKT0Wi/Fx+LlLll/JLsVZO
llPEOjlNThMb5Ey5WGyUSXKNyJVpMl38IXfJY+KwVI7HCjjS8VmVneHOcKu686DzsBXhjHAet2o6
TzhPWLWdp5ynrDrOaOc5K8p5x3nHque854yz6jsfOB9aDZ1PnE+sxs5k51uriTPDmWW1cOY7862L
nEXOIquVs8T5zbrYWe4kW62dlc4q6zInxUmx2jrrnHVWOyfNSbfaO7udPdaVzl5nr3W1s9/Zb13j
vdzb1rrW297b3rrO29Hb0bre28XbxbrB283bzeri7eHtYXX19vL2tm703u7tZ3X3DvLeYfX0DvEO
sW71feD7r9XL94XvC2uAb4pvijXQN9U3zRrk+973vXWH70ffdOtO30zfTGuIb45vjnW3b75vvnWP
b6Ev3rrXt9y3z7rfb/vDrLf9Nf31rVh/Q39za5I/xj/YmuIf6k+1Ev3r/Ds87fwFAcvTJVA1cLnn
lkC3wEDPE4FHAq95Xg18HJjq+SzwfWCmZ0bgp0CcZ3ZgTmCuZ25gfmC+Z0FgYWCZZ2EgKbDGkxhI
DaR6VgfWBTZ41gTSAts9awNZgSzP1sDOQJ4nPbAvsM+zI3AwkO/JDhxzybPL9bphnjy3khvhOeDW
dut4Cty6bj1PodvAjbbJbew2toXb1G1jW25bt6Ndye3kXmVHuNe4ne2a7vXu9XYdt4t7ox3ldndv
seu7vd3+dhN3oDvQbukOdu+0L3KHuMPsS9zh7nC7nRvvxtvt3SXuMvsKN8ldbV/prnXX29e5G900
u4u7xd1i3+imu+l2NzfD3WF3d3Pc3fYtYdeH3Wr3CesTNsC+O+yOsLvs+8M7hHeyHyTuna//Edm/
ryJRE4qiP2VTO9QOqgsQ5tClhReqkWqy+gauZ4DbVFc1V30O104Tuk1twHFrKO6BEql3aqhc7HuK
PcNL1gF4ssyadgW+O+F6s9pMmAOfMc1BYL36A84Axu3bodeTyiwOzSt2ZZeSdonaqnapX9Q6nJPU
srLqV+bmIM9FwdKwf19U5vFaFJe8G9iktqDV8lVv8pIH84p6xaGFZRWk8tR+9QfaJ73YS8LXXKmv
1ddoNf0EN5aaVpedidLz1CZcesiHNusAV9NQzVdSW4A0Sk0/WulvNUgNBDqqlupx9dBJLZ1V7CpR
PmQtAfKYrRLVMtRhj0oiOxSSc0rM5WW2wWZTe+2aHmqTXWoWtPlgaFqJ+Aex56ujKhkxr9X/0o75
mxWUTdMimcclJyj7J6XOVBlK/86KoL/q6yTzj+mQveIYe05Nc5p6n9Qq6stT7ujstuCzOmiO29V2
coAzl3oUOBy6aEmXnTHuBPUVjrnqt7Ouz4mps9QPOO4PttNJIaXyz0kxDqmftWzBNV/L6UlhfcpM
vRf4wTDS+lNTl72pd7Q0qSml9hrnLNLnqTjzNHLPteSi9Md59pzTvhE6Ly5H2jnmuLbUFrPLV5/Q
1rDMsvW4oMeXo+hfu84x98AZQ5sAN5sygqyYHtxDoaWNrU2xR2FvelINvzDH5OB+htStSk39hzli
BFYFJTmlOFahygEn5qDHFbWHGQHUZ+a4Hpy5GXxzFpsaT9XBS63pJrh/Mj77MDpnn77sk1K/hVEk
nK6jwXCbvo+0O9Xe0sbOU1LqUXgiUnupGj1W7LtIzSbP6cfVEj3Fg/u+D/7fmlA9Rhwt4nFVUCL1
0RPcr6PvRlJ9Ggv31cZnHmYxv6lppy07s3T/QpSjZqrr1bVqiLouFPeTEqlfCJ1PHiM5DaAXofcT
vUn/wbj6Nn0DKZ1KsyCNs2kuXWxWBNrQIkoFA6+nTOpq1gL6sMFsMD0GDfxmGqF1bxqptW56gg/j
D9C/oD+vo1F8I8+gZ6FFZ9MYvpPvole0Lk1j+UF+iF7nR/lRelPr0vQfrUvT21qXpndFlIii90V/
MYA+EIPFHfShNdOaSR9BC1X0saeapxol2vPsebTcXmL/Rkl2pp1FK6RP+miV1rtotda7aJ3sJ/vT
Jq130RboXXfSVq130Tatd1G21rtop9a7aJfWu+iw1ruoEHrXeEbQuCYyW34sP2VerXexcK13sQpa
72IV5VQ5jVXWeherqvUu1gh61zHWAhqXj/VwwpwKrJ9T2anKBjoRTg12h1PbiWJDnHpOA3av08hp
woY5zZwL2ANOS6cVe9h5yXmZPQYt62v2OLSpJPYktKmV7CmtL7GntQ7DntE6DBvlX+BPZc9rzYRN
CPQODGSztS7BftW6AYvXugFbrXUDtl7rBixN6wZsi9YN2FatG7AMrRuwHK0bsN+1bsD2at2A7de6
ATuq5/2sQM/72TE97+c8rEdYTy7D+oUN4L7wjuGduF7bXWskhhmJ4ZCY8ZiTTKBYyPOH9Bl8Pscu
6QuagjHoa8iTbeTJhjzNQW/7BVLlM1Llg1QthX8CrSE/pZC21ZSK3YWcpVEYbaJtVNesP9WjHbQX
/Xwf9vr0Bx2iBpSPvSEdpmMUTYWQyIpGImsbiRRGIgNGIgOQyOFUgT8AuQwYuawEudxE1fhmvpkq
8y08narzbXwbRfAMyGstI681jbxGGHmtauS1hpHXylxxRZUFJu5UBVLLccRGVSG7Em5HOBQpvJDj
KkaOa0KO+1MjMQDS3BjSPBjuOyDTjY1M14ZMbyJmbbYyiVtZ1g6yrWxrD/mtPGs/1bEOWAcp3Dpk
FVCUdQzSH22kv56R/tpG+msb6a9tpL82pL87VZE9ZA/yy5vkTWTJnugPHvSHXvDpLXvD5zZ5G0nZ
R/YhR96OftIA/aQf0vZHb/Ga3uLXqxTkyjvRZ8LQZ+6hevJeeR+Fy6FyKEXLYehFFU0vqmh6EUMv
GolUT8inEecZOQo+z8pnicvR8jmU8rx8Hjm/gJ7mR0/7N1KNkWPg/4p8BfFfRd9zTd9jes0Dcd6V
76HccXI8QmNlLHw+lB8i1UQ5EXE+lv+DzyQ5CTX5VH4KH/RP8un+iXwmy8lINUVOgf9UORX5TJPT
EHOmnAmfWfJnpI2TcWiH2XIeWma+/BX1jJfxaJPFcjFqlSRXoLYr5RrkmSa3IP5WmY6ct8lM5JYl
d1JduUvuQZvkyT9Q1n55gOrLgxIyKfPlYWooj8gjKPGoPIY6K6monqMnYw0c5jCKdrjDiUFMLPI5
HsdDrmM7NoU50pFU2cFGXgc7VXR8jo/8mk2otmYTHMEmOIJNcASb4Ag2wRFsgiPYBEewCY5gE5Sy
3FmOY5KTRFxzClmaU4hpTqEAOGUhjot88VRBMwsJMEstCgRqB+qQG4gKXE4VNMvAHyxDkWCZplTZ
beY2oypuc7c5ue4F7gVUzW3htkDohe6FFOG2dFtSLfci9xK4W7utEf9S91LEaeO2QZy2blu427nt
qYZ7hXsF4nRwOyJOJ7cTQq90ryI/mOta+Hd2O8Mf/IVjF7cLjl3dG6kSWKw7VXd7uDdRVben2xMx
b3ZvQYm93dvh09ftj5zBbihlsDsYxzvcOxFniHs36nyPew/yude9D+6h7lDEH+YOgxvcB39wH3wy
3O0oJdPNQqod7g7knOPuRJ673N1UVbMhCc2GVEGzIVUAY30bYsO3sItiNnwf7g/Bg8LwoAcs+A3c
U+knHH+mOMOG8+FeCA4UFA8eFODBFPBmKvhVmLV3aXhQGB6sYniwquFBr+HBaoYHqxsejDA8GGl4
0M/CWTgFWF/WF8fhDKzHHmKP4jiCjcBxLBsLHuzJexI3LOmAJYfgqFnSZ1jSMSzpGk6szHN5LthT
82BFw4OV+DF+jMIMA4YLS1hUEdznwO0TPqog+oq+YL1+ApxiuK+W4b46YqAYCP9BYhD8NQ/WMjxY
R9wp7qIaxTy4gwQYcD9JcF8BeQ3rRRrWq6pXVtFLu8luJAy7SfBabxw1ownDaB7DaNVlX9kXPprR
hBwoIcHgtcGIqbmsquEyr+GySHDZ/ejhD8gHcHxQPoiYD8uHcXxUPoqj5jVpeM0b4rXRcjR8ngOv
eQyjSfmSfMnw2suIr3lNgtfGwh1ktDfkm3BrXpOG14ThNa+cICcg1fvyA/hojpOG4/whjvtIfgR/
zXTSMF2k4TghvwK7iRC7fS2/hvsbifFVfiu/RUzNd8LwXeQJfCcM30nwXTzcmuOkXCIT4U6SG3HU
HCfBcZlwa3arYtitqmE3r2G3aobdqht2izDsFmnYzS8LZSFSaY6rajiuuuG4yBDHSXCZMFzmdwJO
AG7DSr65vnnk+Bb4FuC4yLeIfL54cJDPt8S3BD7LfMvIMXzE/ev8W4gbZqnsXgJOCXcvcy+nioZH
wg2DVAaDdIC7oxtDYeCOa+CjuaOCe4N7A3y6ut3AU5ovKhq+qAym6AO3ZopK7gB3AOJojqjs3uXe
Bf+7wRGVwBH3IgfNERUNR4QbjqhgOKIiOCIDeWa6mUiV4+Yg/k6wQ0XDDpx4swp6jebCHy6/mTrR
raebzf9/3tRW6J1ZwXUitaXkqkhIeyp1ra6MnNPVRpVn9MVFZv1hg/HNNCsJK0PrsjrvDKNFpqs1
ao2JESpLrT5j7qF1PDX03Gv2522qq/rRnEusPJcaeyu09F/PTts9Yz7bT3ajTbcXrQqq5WjVdWjN
TWqlWlsc6/jzq1Lst1LtUcmYgUcgRUhTDK42/i2br7geJ64/B+j2oF+J9bWs4GrFSX571Grca17R
quqfuwVXu9S6Ilk7sfwT64xalFhBP11f+pNqds69UX2m/mfOBajtUoMJajLOCaHw0FqHWZ08oFaU
tV5bahkZajskMbSGFXTp9ZHiVev3EL4ruEKttiH20lC7nlSWOnQWJR0qWjf7cze1/3hd1EG01QF1
xKxMn7S6c84rgf/AViSR6Nk5Z45ZFO8vrEuJdx1njP2DmqG+02v0VE19omYYv60q0Zw3Fcc649hw
mpzXgi3yVErwCcK1zvTdDWY8mmJi7DEhSXqlGvuO0CpjqCzTg2rS1aGreSpB/YIYkdQF54XG78vQ
CPYc0O/ca3jG2gdH6O+Kr+9Qk9SD6hXzJu3pYt/28EMctfdUJkd/LPGMMQIvUsv0KP0n1/Wg6T9G
8jTDlOznas/x9fEzS+i5Sc9fsJm3xeqdU98PqydKe5uhNoMzMso5X1qrU5kx2w1eG2+36KieNb6H
SQTfrBWn02WF0UWn5LYH+e0xeXhw3lrka476XWLqudfwpPyLn8uJOYXePmaGelFS6J3kSZJn+D/v
1LeJ+h39+dXoXLdT3/eVXMMP+Y8t1bccT/hsNzXmHCLXMSleVaPMWb9lno62nA4ejdPnUI5F43vw
nWzG6d88nKFW36ppGLOnhq6Wqq9DvXspkGjmGIe07IfqkaUSQ/0+WNYpX12ohajhAsPzLcBCP4R8
fz0pjtJsXY6aptCJb76DzJlu5M7kF5Q1U+/lJu6KolSk30itMOx6n7mar5aoR9Rv6kn1qYoFV4aY
Npgi5D6Iln68HLUcoR5XH6mH4VqmsuF6BK43oAV9pGahZSap+8Hin8BvjWmt6eq/QYkNlVUzOOYU
55atUsHnui+2xsgV6pMhnUDPYY4Y1zm/dzattftEli56xsattbuQ7mNK2aLfxgXfyIXKanH8Sfxd
24lfqOjaoWX+KGOU0VKw/6+uV4lSVbHroJnTrsU544wpFhT14XKW+JHqq0arCca9HPIySc017qxg
X9ZzI/US8H35yzC5XK+eP6/0GWo3YMYIyJ9mtWJtKjhbwZi2ETir2e0ZyllT7pQrQ2/P0823aZuD
X68YjtEj3tZQrL9d9k/d1DB1t4ov+vJIPY15S4JeMzGz3xkqH2FvqFGqhWqqpqgOePb/KjWXD8os
J/iNR/3zru+HJ139cL75naaU984zfSZ4OjU4rqLXbigRngXfnSrl+ArMP7OpZPSSjGAtMBtbX8q4
uB4SkF7+fvDnbKjDa3TC90EY7+b8k/UpuUGvejO4OmKunkLf2RHkzuL5wzbogW+ot9VhzIQ2lv5V
StntfLrvGv/czfA9pAL9/7x0v+Jvjv6CTW07sZzzG53VxedbmzLy3xKcF6E9z2tEOv+14TJLyMLI
WuYXU//0duZZ0DlsJb71PsvyS6w1n0WaPTrV8ZRn27PKU9bfvZ3vmmd53itAl9gRmkl5ivIoXukP
nL51TVmR9LD+5vycyyzPunfO8bcvxeUHv5c9VmZZnK479xL/ka1aeRIVjZDnlGaBTnV8/DffLe+G
ZlTGmm95yvprNuib+0/3BecJsc5Dj/vTNn8Z4dWo3/E3df/EpsdT9LCNZ/79gnnP9Dfr72f7i4rT
pI4LndNDiC8lUlPzxXaV8s2zzDfh6UUpgy6Doi/OgyW2Jzrlq/CTyipaiyxO/UUptdFflrfS350X
3dU51XOiisP+RejKuMw7jLjQXQRr0KpEPctRVnHacsyyofHrrxaKV7vN/PkA2WWtW4fK+otnoKVu
J/4GIdiLeRkpJHXQH3ud61au9x3bzPuO4pme6QW7yu5XobJqn+K7As9nhUqg6tRULQ6tlMaHVpAg
Qeqmc6/hGWuxxBxnFF/3UU9CRxynfx2gHiz2vVr95zQZeErJc/fZjBvl2czcKai57lNr0fdX4Jh2
whibC//fSa/bPWCufwTjDlCJuKsluKdEdXcoXuxJuaapm8tRl9vVzepjdUvoyrjUMOP6Rn2hRpjV
qbjg81WzsE8PPUVdVjVqad54PqWGGz/9PcPH0MQ/Vt/hqWfqdxLG/6R1F3VUTSxHPSeAmRYV3TFc
k3HUvzzTXzNlqmnqKzytBSbQ/P6qSLcPldX63Ev8u7eyf8l53iXsDPZXPIHDZcc+iy0S/BRJNXVr
Q0IBXNVBP0/EngCkqUvR5/pTuIo+qR7dCoOsEfoVq5qjVhie07+w1O/1Q3ri8f5c4k5+McenwKk1
jauN6ouyuqO/VFZtT4o5GuineqHvmG8AwEub1Qb1rfoMsrpT5YU0hebU2PDzBSbOgnNvCjUPM+Ui
CdTfrizAvvn4PEj1Nae+1Jva0uWmrOanlqUqKlK1lQQbLFIvqdnAaPWiOccVvTsMbWEm/shy1PNx
NVK9GXp/HoDrMexvwP9NE/q9gmahZuIJHNfV3fKW9SdtvIS7rDFRYh4lEDe+DFssfUO2WF6gG4yF
lSGsDmtODxjbKk8b2yqj2AA2gJ5lQ9lQGm2sqjzHRrGx9CJ7nU2gt7VVFfpIW1UhbVPlY/pEW1Wh
/7IFLJkm8Yt4K/qet+Zt6EdtVYVm8hgeQ7O0VRX6id/Au1Icf5Q/Rr/wJ/m/aB5/i79LC/hn/DOK
51/yqbSYz+SzKIn/zH+mFXwOn0sr+a88ntbwpXwppfLlPInW8hV8Ja3nq/lq2shTeSqlaZsotElU
EJVos7aGQunaGgpliYaiIWVrayiUoy2gUK5oL9rTHtFBdKQ80Ul0or3iGnEN7RN9RT/6QwwUg+iA
+U78kLZTQoe1nRLmajslLNqaZc1lLbSdEnaptk3CLte2SVhbTxVPVdbOE+Gpza7QFkrYVdpCCbtB
Wyhh3bWFEtZDWyhhN2kLJexmbaGE9fEo28Nu11ZJ2GBtlYQN1VZJ2CPaKgl7VFslYSO1VRI2Slsl
YW9pqyTsbW2VhE3SVknYZG2VhCVrqyRslbZKwlK0VRKWqq2SsHX2FPsbtllbJWHp2ioJ26atkrAM
bZWEbddWSdgObZWEZWurJGyntkrC9mirJCxPWyVhB7RVEnZUWyVhBdoqCSvUVkk411ZJuKOtknC/
tkrC62irJLyJtkrCm+svynlLx3VcfpFT0anEWznVner8EqemU4u3duo6dXkbp6ETzS9zmjpNeVun
hXMhb6ethvArtNUQ3kFbDeGdtNUQfpW2GsKv1lZD+DXOGGcM76xth/DrtO0Qfr22HcK7aNshvJvz
jfMt765th/CbnDgnjt+iLYjwW7UFEd5LWxDhvZ1kJ5n3cVY5q/jtToqTyvtqCyK8v7YgwgdoCyL8
Lm1BhN+tbYfwe7TtEH6fth3Ch2rbIXyYth3C79e2Q/hwbTuEP6Bth/CHtO0Q/qi2HcIf17ZD+Eht
O4Q/q22B8NHaFgj/XNsC4VO1LRA+U9sC4XP9sf7JfKv+9pz/rm2B8PxAt0AvwbQVEOEL/C8wVURr
KyDiEm0FRLTVVkDEFdoKiIjRVkBEJ20FRHTRVkBET20FRNysrYCIXtoKiBgYyA5ki0HaFogYHNgb
2CvuCRwI5It7tS0Qcb+2BSIe0rZAxONuDbeGeMat5dYRo7RFEPGctggiXtAWQcTL2pKH+Le25CHG
aEse4nVtyUO8oy15iHHakoeYEHZ9WHfxftjNYbeKT8L6hPUVk7T1DvF5eIfwDuKr8M7h14nJxMEe
Fri8Ddi2AjGqiF1QJcyaLYrAyOahWhQN/0bYJUao5pjbXABG84K72kOHuALjr586GiuRmt0Cht1c
sFtvpLoNezg4bgDyHkh30WU0BHx3OfjuUZTzGPa2NIKepMr0L+xV6Cl6lqrSaLBhNbBhGFU3v2eJ
YBXAjI3BjI3h04Q1oaasKWsG/+bgyqaGK5sZrmxmuLK54crmhisvAFeOoRbsFfYK0r4K3owAb/6H
LmRvsXHUko0HhzYzHNrMcGgzw6FNwaGT4Z4CJm0KJo2nGLaYLaZL2BK2jFqzRHDrpYZbObi1NY6X
gmFtw7BhhmG5Ydgww7CVDMO2MwzbxDDsRYZhI8Gwk6kWn8KnUA3+Nf+W6vCp4Nwow7lRhnNrg3Pn
4PgLmLemYd56hnlrgHmX45gE/q0N/l2B40qwcE3DwjUNC9c1LFzfsLAXLBxBDUWkiKRoUQOM3N4w
crRh5AZg5MY4NgEv1ze83MjwcgPwcgccO4Kd6xt2rm/YuYH5pU8H80ufjubXPR3Mr3s6Gqa+Akw9
mtpY/0fZ+cc1fZ19/+RLchLwG0SqSC2lDCmlFCmllFKkVNFSxxh11jnrnASEEMKvEEIIISTfhBCC
9fa2zsc6Rx1jljFnHfOxzDrnHLPMWeeco845Silz1jLnLLPO23nb+3OuMOd9P8/zx9O9rk+uXt9z
zvdHknPeV8a5qmC+VmG+3sr06lfVO9gT6tfUO9kc9TfUu1mm+lvqb7N5Yh5n8zGP/4g9JqpOMZrN
WZaYzVmEmM2hczVzWY5mnmYeSxVzOnsMc/o4C9N8oPmAPaiZ0EwwveZDzYdMrZnU/JFpMNdfQuQj
zUeIXNZcZlrNx5qPmU4zpZli94k1gM0SawDaTGum2WzN3zR/Y1FYCT5lKs0Nzd9xrpua/2BzNLc0
t9g8sTbgXJ9pPmMxXBQYeIqruIpFcIlL7DFRzwq+mqvha7iGZWP90DI913GZzeF6jm8Wn81nMxVW
lDlMx6N5NJvF7+Nz0WYen8fCeAyPwcjz+XyMHMtj0QarDpuNVedB9I3nD6FvIl+I9kn8YRbFk/kj
GDmFp6DvY/wxaBpPwwiL+CK0T+fpaP84z0T7J/mTbB7P4lmIP8WfYmqezbOZzJ/mORj/Gf4M+uby
XIy2mC9Gmzyeh77P8mdxR1jhcK6lfCniBXw5Wj7Pn8cIhbyIafgX+ItouZKvZFr+Jf4lXPPL/Ku4
r/W8FONXcTPOXsNrcZY6bsE4jbyZPc3tvJXlcCd344werrBnuJf72H28g/vZXN7JO3G1AR7EvXTz
TRjnFf4KRtjMN2OELXwLxv93/u84upXjEyVWWRYrVln2KFbZb7JFvIf3sDSstd9GvI/3sfn8O3wP
S+Vv8DdYFu/n/XjCe/le6Pf5PrxfWInRCysxFCsx2v+Y/xgjHOE/QQTrMVpiPUb8l/wkIu/yUyxd
rMqIv8ffQ/wc/z3iF/gFjP8+fx/nGucf4OwTfII9wj/kH7LH+SSfRHus3Gh/mV/GCB/zj9F+ml9H
y0/5p2j5D/4Zm68V/wfFo2ItZ2lYy+PYIu2D2ngWq31Im8jStQu1j7DHtSnax1gq1vhMlqV9UpvF
ntM+pc1mT2qf1j6NSI42lz2FtT8PbZ7VPouj+dp8xJ/XPo8xC7WFOPqC9gVEVmhXYGSx10wlyIA9
JsgACjKAggygIAMoyAAKMoCCDKAgA0b1xBjVE4OCDNgjggzggwxYliADtAQZIAIygIIMWLogA/Y4
yGAf2rype5M9BT54i+l1Q7ofoQ0oAb1ACYiDEtDyF7pfQE/oTiACVsB5wQpo+Z7uPbZId053Du1B
DCwNxDCGyPu693F0XPch/L/o/oKzXNVdZc8JhmCLwBA5bH74M+HPsFhBEuxRQRLwQRJQkAQUJIH4
l8O/DH9N+BqWDp54mWWFrwtfx9LCvxr+VfYU2KIUoxnCDeyR8LLwMvjgDLYInPENFhmxK2IX4xHf
jPgm/J6IHvivR7wOf3dEL4sWFILIryKmmBTx54hpxgWLMEmwCIsULMKiwSIvILJiloHlCiJhGaHd
cIJImCSIBAoigX5b/jZbIPfJfexB+Tvyd9hseY+8h8XJb8hvsAS5X+5nD8nflb/LwuQB+fvw98n7
0P5N+U202S/vR5sfyj+Ef0D+3+xz8kH5INq8JQ+hzSH5EI6+LR9mD4ByfoL4Ufko4mAd6LA8DP25
fJzdL78jj7B4+RfyCbT8pfxLtDwpv4sznpaxHsln5VGMDB7CWc7L56G/ly+gzZj8Pq55XB7HOB/I
E/A/lD9E+0l5Ev4f5T9izIvyRRwFObGFgpxYOMhpij0s/1n+M1ssX5H/Ch8Uhfin8qfQG/LfWbJ8
U76J+H/Kd1iS/BlSx4fBVREsST9LL7NEPf5BJFIfyRaDtOYhEqOPZcmCt1g4eCsO+qA+Hm1AXTi6
UJ8EfVj/MFsk2AvjgL3YA2CvE+x+/S/1J9lD+nf1uF9w2GmM82s97lp/Vn+Wxel/q/8tIr/Tn8do
v9f/HmcEnyECPmPJgs9YtOAzJgk+g4LPmCT4jEULPgNtSdIi4rNlxGcSkRmf4bAQgQnekom3xF6p
l6GCtJYTaRUSaUURaa0g0ppLpDWPSCuGSGv+PXuYNbSHWUt7mDW0h1lDe5jDaQ+zhvYwa2gP8yza
w6yhPcwa2sOsoT3MetrDrKE9zKFaDhraw/w87WF+gfYwz6E9zJ+nPcxFtIf5C7SHuZj2MMeqJNUs
dj/4Tw+NUt0P6lqgWgDqEvyXDf57keWoVqpWsxdVX1bhm0nM94zKqDKyp1TNqmaoXeVkuSqXygW/
HeS3GOTXDf8V1StoL/jvKfDfa+xZkF8PywfzHYS+pXoLnDek+imOCuZ7iZhvCTHfUmK+AjBfBgsj
5gu7h/bCQHvLiPY+D9r7AjGf2GWtpl3Ws2mX9WzaZX0f7bKeTUT4RSLCp6VuaRPLE9VI2UriwgVE
gY9KP5B+wB6RDoECP0f8t5D472HpXeldkKIgv4eks9JZxN8D7T1EO7cfkH4vvQ+m/ED6ACp2cadS
ZYsU6aL0J0Q+kj6CivoWcbS7O1H6i3QVvtjjnSR9Ik3DFzu9k6V/SLfhi/3eD0p3pM9YHO36TghT
hUnwxd7vpDBNGPID2gGeQDvAE8Nmhc1CZDaIM42IM4OIM5OIsyTsgbA4xAV3poUtBHcuCksGd6YR
d6aHpYalwsf/oE+EPcmeCMsOexp+TlgOeyzsmbBc+IJKHw/LA5WmhT0X9hzGF1SaRjz6JeLRVcSj
XyIeXUUkugwMuoPJoM/d4r+5Ce6MUfep32T3E31mq4dAn8+APo+zxep31KfYc8SgS+/Zl66hfel6
2pc+h/alFxOVFhKV5tMe9ReITXOIRDkxKCcGlYk+OdFnjOaq5ipY85rmE0QEcc4j4iwk4owi4owh
4pyvuaO5A2IQTLmMmJITU0YRUy4jppR4FJiSE01yosn5RI3LiBc5kWIUkeJ8osNlxIWcuDCGuHAZ
WPBpHBUUGEUUuGyG//J5Plou4UvQUlDgMuI/TrTHifA4Ud1yorpCoroooroVRHVziermEdXFENXN
J3qbz3fwHWwxf42/BgYS9JbDv8W/xXJ5L+9FXHDbk8Rt+XyAD7ACIrYsvg/Elsvf5HjXiNsW80F+
kD0HejuEyNv8MHuRuG0xP8qPopegtyz+M/4zxIf5MPr+nGOtIp7LJp5bzH/FT2OEX3N8r/lv+G/Q
fpSPoo1gu2xiu8XEdkv5GB/DCILw8onwsojwFhPhPUuEV0CE9yT/iH+Eo5/wTzCOYLsn+Q1+CxFB
eNlEeDlaSSuxF7XhWuTQ2mhtLFTQ3mLQXiJ8wXnPEufla9O0GWA4QXtLifZeItpbQoSXT4T3EhHe
Uu1z2ufY/doCbQFUcF4Bcd5SbZG2CGOK6gl6qp6goeoJeqqeoKfqCRqqnhBO1ROKqHqChqonaLRf
034NZxc1FDRUQ0FPNRReoBoKc6iGQjHVUIilGgqxVENBQzUUNFRDQUM1FPRUQ2HOPTUU9FRDIVQV
Rk81FGKphoKGaijoqYaC5p4aChqqoaCnGgoaqqEwh2ooxFINBQ3VUNBTDYXYe2ooaKiGgp5qKBRT
DQUN1VDQ3FNDQUM1FGZRDQU91VDQUA2F4ntqKGiohoKeaihoqIaCnmooaKiGgoZqKOiphoKGaig8
TzUUXqAaCnOohsLnqYZCEdVQ+ALVUCimGgqxVENBQzUUXqAaCkVUQ6H4nhoKGqqhEEs1FDQg9Xks
B4z+EDRB9wTLJxZ/Tlenq2OLQeT1LFfXqGtk2Tqrrgnsa9PZELfr7Ox+YvQsnUPXyug3PPgunRsq
eH2pzqvzYpyALgDdrPs36Bbdqxhtm+7raLNdt509qftf4PjFutd1ryMuOP5Z3Ru6N3AlA7oBtA9V
nRFkvxRkP4izCLKXdT/SHcIIb+veRq8f637Mluh+ovsJIj/XvYPrH9GNYARB9vdTlZos4vtc3ahu
FCoov4AoP1f3B90fWC5Rfhbx/WLdn3R/QuRj3cc4u2D9pcT6L+n+qruGXoL4F+v+pvsb2nyqu8Fy
if6fC88NzwXNC/rPCV8avpQ9G14YXsheDH8h/AWWT5lAbnhJeAnaiEwgJ3xl+Er4LyETyA3/SvhX
0F7kA0spH1hC+UBB+Prw9ez+8K+Fb0DLUmQF2eHl4eWIGMON7DlkBbtmMgGRA+xGDtBLmUBfRB8i
34v4HsuLGIwYhB6IOAA9GHEQOhQxBD0ccRgqqmbMpqoZs6lqxn1UNeM+qpoxm6pmzKaMIoxyhi/O
KptlYk/P2jrrNZY3a++sY2wl1dRQUxahRubQCDoXucGjlBs8In+fcoMfyIPgbJEPPESZwKPIBN6C
PyT/CCx+RD6CiMgBPif/TP4ZIj+X3wGdC+5fSNz/KHH/I+D+M4j8BvT/CNH/w/J78ntoL7j/UfkP
8hiOvg/ufxjc/wFGE9y/kLj/ISL+z8l/kv/E0uSP5I+gH8sfQwX3ZxL3l8h/Bfc/Ll+TpxH/m3yd
pRP9P070/wTRf6b8H/J/IHJL/gd7TL4t30bLz+TPWCagUgWOl/RhLE2v1qvZY/oI5AbplBVkUlZQ
oo/Sz8HRaP1cxEVu8IT+fv39aCmygkz9Q/oExD+nT0R8oX4hRktChhBHGUK6PlmfzB6nPCFDn6JP
wdFH9YtwVNQxSaUKSSn6DH0mIqKmSYI+S58NX1Q2SaLKJglU2SSVKpskUGWTB6lCUpx+mX4ZVFQ5
SdU/r38evqh1kqh/Qb8Cvqh48iBVS4qjuicPULWkOKp+kkTVT1KpWlKKfrX+y1QzaS3iL+tfRkTU
Q0mmeigP6jfoDTgqqqKkUlWUJKqKkkxVURL1Jr0JR0VtlCSqjZJAtVES9YP6QWRBIi9aiLzoF2wB
8iJ8HvS/0v8Kmc9p5EILKRd6grKgEmRBf4A/ph/HExO50BP6Cf0EfFFjJYlqrDxANVZSqcZKMtVY
SaIaK2qmemA6TgGKymGb2AeMGawwB8wN88M2wbbefVVZDXjdAeuB9cEGYPthB2GHYcdgI7BTsLOw
87Bx2EXYFOwa7AaTfAoZM9wmk3wB2GbGyiQYpu6ySNhc2AJYAiwZlha6rrLM0DWU5fw/XvMx1ja8
Lg8Z9SmCrYStga2HlYeut8w081oPs8GcMCU01syr5NsJ2417N8Jq4e+5GwvZXtjgTGwIdmQmPjxj
J2bsNGwUdgE2Abs00/YKtWdlgdB1iOdUJp7FNnrmobbTsJuI7YSJtntge2GDsKGZc9+ZudcjsGHY
iZl7Ox26ng71jEUgNgq7gPuxwhwz/cXYE7BLsCuwaZg4J8YtV8PQrzwKFgOLgyXOvKb8q315Oixr
5jVipl/WPcdzYUtghbBi2CrY2n+9ivevfAOsAmaGWf4v//7fX6UOcU12mCt0b+U+WHDm/f7/MPrM
32PlW2ZsO2wXrBfWD9sHOzATF6+HYEdhx2En7+l/hkzqEM/rHGwsZP/HeSaFqeeUmhuYZ3eZzjIE
jbQcIR2GzrWcgC6wnIYmWEahyZYL0DTLhGe36OVNLcu0XPJmlFoauGdPqb1B9uwty7FcIZ2+6+db
bnr2iqPe7FJXQ7RnsGy55Y5nMOTPqK8h1jNUVtSohq5sjLjrF5G/pjEKur4xBlreGAc1NSZ6hkQv
bx40Hn6wIclzpKy+MQVqa0yHOhuzPEdE3FtQuqUh1TNcpjTmQgONS7wrSrc3ZHhOlG1uLIRuaywm
XQXd2bgWurtxA3RPYwV0b6MZOtho8ZwQvbwlZUONdsVcuqsh23O67Eijy3O6tLchzzMq1LsaWuC5
UDbc6IOeaAx6LoiId13ZaREPHS3tb1jhmSjd11DiuVQ22rgFeoF0onG755KIew2kxtIDDas9V8ou
Ne6CXmnshU6Tf7OxH3qncZ/nSrm68QA0ovHQXY1qPOqtLY9pPO61lh5qWOeZLo9rPOmZptFuzkQS
G89AU4SKiNdRerTB4LlTnt54DprVOEYKX8S97tLjDUZFXZ7bOKmohe/1lx5vvAz/ZEOtElG+pPEq
tLDxOrSY/FWNt6BrrQy6wcqhFVYZarZGkx+rRIi+3k2lZxqsSlTpuQaHElNuscZD7aQua7x3a7nP
mqTElI41uJW40skGP64haE2FbrFmkAp/uzUbV3K5YZOSWL7LmndXe60FSmLp1YatSkqNvS2bNI+0
AOpqWwH1tZVAg22roVva1kG3txmUFNGra7xmV5ux62Lp9YYdSnrprYYeJaumt60W2t9mJRX+vjaH
kiWOdk0ZWEOfZ7TmQJsbeqihr+taSA28YUDJrTna5ifdBD1O/nHyT7ZthZ5p2wE919YDHWvrU3JF
r64b0P3w5YaDypKaybYB6OW2/dCrbYiIeNdtQ3TDYaWw5nqb0Fttx4KSIbbhmFJcy9pGhNbmkX8K
ytvOQuW289DotnFobNtFaHzblFIsegV1tUlt14KRhniDUVlVm9p2Q1llSGoYUdYK7YgypDacUjbU
ZrTdhma7JGWDiHSNhOIzmtFwVqkwZDecV8y1eS7dXS1wRSpmEQ/OJV1gyGsYVyy1K1xzSRfc9Utc
CdDVrmToOlca1ODKhBpdOdBaV34wodbqWu7NMBQ0XFTstQ5XUTCZRnPNRNyulVC/UBHpOmxY0TCl
+Go3udaQrv+nL+LBNENJwzUlWLvVVa4EhR/MrN3hMgVzDKsbbihbanvw5KGu+rt+n8sGHXA5oftd
CvSgKwA97NoMPebapmwRfYP5hnUNt5XtBoNFUnbVjrh2/g895dqt7DIYLTql11BriVT6a8+69pDu
veufdw0q/QarZa6yr3bcNXRXL7qOKPsMDssC5UB5v3UFdJ+1BHqA/EPW1dCj1nXQ41YD9KTVCD1j
rVUOiF7eHeXnrFZvj8FtSVAOGfyWZOVo+ZjVAZ0kvUx61epWjoqj3j7DJkuactywyeoXKvzy69ZN
yphhqyVTOVl+y7qVdAd0kvxJ4W9k1h4ot/ZBZesANNq6XzkpenkHDDssOcoZQ48lXzm3MdZ6EBpv
PQxNsh6DplpHlHOGPstyZWxjBmm29ZR3v2HAUqRMbsyzniU9Dy2wjiuThgHrRfgrrFPQEus16Grr
DRG3FHkPblxnvY2IoUnyHjbst6xULm80NumgtU2RymXDQcsavAtQ77GN1qa53hHDYct6tHc0LYC6
mxKEWtZjHDfFSQ3HLOXKVcOIxYRr8zclK2PlB4Ru3NSUhieDuPfUxq1Nmd6z5J83nLLUK9c37mjK
Ic1XrqM9dGNP03JoX1MRdKBpJXR/0xrowab10MNN5d7xjceaTN6LGMem3DL0NdVDRyxO6FmLgusZ
abJBTwkVEe+U4bwl4GUbzzY5oef/pRS/tnG8SfHe2HixKeC9bRi3bPbyjVNNUOH7JMN40zb4Fy3b
6L52ku6GXiP/RtMe6O2mvcpYhdQ0CNU1DUEjm45A5zYN497RF/c7ZdnplQ3XLLu90RULmk5AE0iT
SdOaTnujDTcse7yxhtuWvd74ikxrCTSnaRSaT7q86YI3vkyyDHqTKoqaJqArSdc0XYKub7ri0wkm
8UVWlDdNg0/ABr65Faamm56hivqmO1CbTR1awX0LxDroS6hw2iI8VyoUW5TniliJfMkVAVuMWJVs
cVCsNb60is22REVdsc2WoqjF98WXWbHTlo7vDj63vpyK3bYs5WTFHlsudK9tiTJZMWgp8uWL99e3
vGLIVqhcN5yyFUPxHHxFFUdsq8Qzsa2Fhu502LYBesJW4Y0XK05wee2Ua1hJETN/sKj2muuEklt7
w3Uaets1OjM/rxSzXHBNneS6oFgMea4JqJhn1tfpXJfEnOO6AsVMEiyvi3RNK/11c103lf6K09bb
3oMVozazb2XFBZvFt6Ziwmb3ra+4ZHP5yiuu2HyevRXTtqBnsOKmbYvPhDbb0eaObZevvlJt6/XZ
KiNs/T5nZZRtn0+pjLEdAF+dsR1SoirjbEd9gcpE23Hf5tIx20klrjLFdsa3rXSf7ZxvZ+kB25jn
SmW6bdLbU5llu+zbXZlru+rbE+KNyiW26769lYW2W8oWQRS+wcriZuYbqlzVzMW70Cz/c2WvXNsc
Dd3QHAutwLUdqTQ3x/uGKy3NSb4TlfbmVN/pSldzhm+00tec7btQGWzO801UbhFMW7m9ucBzonKX
YKfKXkEplf3NK8CuxI2V+5pLoAeaV4PixGfjUuWh5nXQo80G35XK481G33TlyeZa382yaWp5ptnq
Ga481+zw3akcE+RWOdnsxlkuN/uhVwWjVl5v3gS91bzVc8LImndAeXOP54pRbu6DRjcPeKaNsc37
ofHNB5UIY1LzYWhq8zGf05jRPOIZNmY3n+pQG/Oaz/qOiCfQEWEsaD4f+mx3RBlXNI9jnJLmi4ra
uLp5qiPGuK75WkdciDCNhuYbHYlGY/PtjhTxvehIN9baJVA6WL0jizTXaLXrQgTesYS0kLSYdBWd
ZS3pBqPDHukZMrrtcz1HjH77As+wIOqOCuMme8KMbya1iO9Xh924lZ4keLjDReoTV9URNO6wJ3cE
yd9Cut3YY0/zTBj77JngYVBxxy7jgD0nxMAdvaT9pPvKU6wZeFb77fnQg0IFtXYcID1kPGxfHiLV
jqPGY/Yizx3jiH0lFHFETtnXhKi14zjpSdIz4lvfcY50LKTGs/b1YFEQacek8by9HOQJLu24bBy3
m5Q440V7PXTKbgNz7rI7wZbifblKet14za503Cq/bg/g2y1m5jHjDftmrJ7X7Zg/jbftO/3M0Gff
LVYE+x4/r5Lse70jVTr7oF+uirQP+aOr5tqP+GOrFtiH/fEzczvN3lUJ9hP+pKpk+2nMxrfto/7U
qjQxE1Zl2i/4M6py7BP+7Kr8JsmfV7XcfslfEGKAqiL7FWWyaqVYZarWiHm7ar1Yo6vK7dP+FVUm
+01/CVZnrLZV9fY7WPUwa/lXbxxoUftXV9msW/3rNha0RCiXq5wtURhfoXXZ3xKDcQItcRh/c0si
dFtLClbz/S3pGHlnSxbOuLslF7qnZQnOu7cFc2DVYEsxIkMtq6BHWjD7VQ2LlaLqRMsGv6HqdEsF
nglYwnenarTF7Dsi7s5vrLrQYgnNtP7aqokWO8a51OLyxosV2W+tumIx+R1V05bNfnfVzRaf3191
pyXo32RSt2zxbxXPzb+DxumpON2y3d9nimjZ5R8Qc7h/vymKaAfM4z9IevifVGNJ8x8jHSE9RXqW
ruF8SE0xLb3KGVNcS79yzpQoaESQiX/clNKyL+RjvRORi4I3/FMbjdbb/ilTesuBEFf4r5HeoLu4
bcpqOdQpCb9TR5EpU27LUeWqaUnLcRAFuKIz0lTYcjJEEf5x0hHSs3gvzii3TMUt56CrWsZCK77/
ttDOuaa1LZOhVb5zgWlDy2UvM1W0XIUijoi55bqXi6fXmUCaTJom1qnOTKG4a1KTpeUW1m6s4J05
JruDYaXGOt6Zb3I5uDfW5HPI0KAjGqtYkSPWmyTW6M7lpEX0HEZMWxzxXm7a7kjyRpt2OVK98aZe
R4ZywNTvyO5cWbfAdSdoqktoVwd665LbI6Bp7VHKhrrM9hglqy6nPc4zWpffnhisR5sUHF3enh60
1RW1Z+HoyvZcRNa0Lwk669a3FyIbSmovVtbWlbevCiqG2Pa1SnGdqX1DMFBX314R3FxnazcHtxny
2i2Kpc7Zbu+8UKe0u4I76wLtvuDuUHZgKGkPKsG6ze1bgnvqtoH/99btbN8eHKzb3b4LeVxte+8/
ObxuT3t/cKhub/s++IPtBwIRdUPth4JH6o60Hw0O1w23Hw+eqDvRfjJ4uu50+5ngaN1o+7nghVAG
Wsvax5BzhTIdyinqLrRPBidCWV7dBCJL6i61X0bOJdb6S7Xr2q9Cx9uvB6/UXWm/FZyum3az4HDN
pGhpiHZzpbDuplsO3gzlWTV2d/TdfJZyzLo7Iq9EJtgjMj537N2zG9zxUMqV6tXuJGRMoRznIHLM
LfUR7f0dKTXX3alKYX2UOyN4pz7GnY08C0+gW10f584LsUp3RH2iu0Cx1Ke4Vyj99enuku6o+iz3
6u6YUD5Yn+te1x1Xv8Rt6KZ8vDulvtBtRE6NzLo7pFn1xe5az6jIoLtzSZcI9a4mv5DOUhzS+lVu
q5JbvxY515L6DW6HUijy3+5V9RVu94y/lnSD4KXuipkniey12yzUN1dcVefcerPb320Rfred1FVv
cW9SKurt7q3IXpHDdvvqXe4doYy1O0i6hXR7rdvdgyfmc/dBg0JFjtlxXWj3rvot7oFQXtndW7/d
vV/x1e9yH4Qijkiv+3Aox+zuJ91HekBQXPch0qOkx+v73ceQOSJ/7D5Zv889gjwRWWT3mfoD7lNK
b/0h91noUfd5PPPj7vHgEL0v50jH8Km42OGqP+meUoL1Z9zXlF3159w30HLMfVtJMe1z5HWuodyB
1iOauxKUMdMBR0HnetMhx4rOcsMmR4nvjumoY7XI7xzrOk2m40LhGzrrTScdxk4btPaunnFYO52m
cw5Hp2IaQ69zoZzONOlwdwZMlx3+zs2mq45NndtM1x1bO3eajor5U6j3vOmWY4dfFtlZ527SPRvX
OXqUyWrm6OvcW80dA517DYcd+71T1bLjYOdgdbTjcOcQ6RGaJ4dncito54nqWMexztOhPKs63jHS
OVqd5DjVeaE61XG2c6I6w3G+81J1tmMcmuG42HmF5sxp0pvVeY6pzjvQawF1dYHjRiCieoXjdiAi
tKZUl7RKgagZXd2qC8RUr2uNDMRVG1rndqRUG7EeJVXXti5QsqqtrQmBxGpHa3IgpdrdmhZIN1xr
zfRGV/tbc7xy9abWfMUn5kl/j9BAVpmE1RB+63J/T4jcjMbWokBu9dbWlYElBn/rmkBh9Y7W9YHi
6p7W8s41pjOtpk5ndV9rfWegeqDVFlhVvb/VGVhbfbBVCWyoPtwaUDZUH3OsDlT8t9FGWjcHzNWn
WrcFLNVnW3cG7NXnW3cHXNXjrXsCvuqLrXsDweqp1sHAluprrUOB7dU3Wo8EdlXfbh0O9Jql1hNQ
XevpQMWMRraOKgfMc1svBPrNC1onOkfNCa2XAvvMya1XAgfMaa3TgUPmzNabgaPmnNY7gePmfKc6
cFK8v4Ez5uWG24Fz5iJnRGCs+rATc755pTMmMBl678xrnHGBy+b1zkSf01zuTAlcNZuc6dB6Z1bg
utnmzA3cMjudS/wZhlNOMIZZcSLPMgecq7qYebNzbRc3b3NugO503OiSzbudFR23zHucZs+oea/T
0hVtHnTau2LNQ06Xkms+4vR1xZuHncGuJPMJ55auVPNpS6AjxTzq3N65zXzBuasrwzzh7EXLS87+
ruyZs1xx7uvKM087D/iOmG86D3UVGDZVjyjHzXecR7tWGI45j3eV1KidJ7tW10Q4z3Stq4lynusy
1MSYF3QZDOedY13GmjjnZFdtmeS87E2qSXRe7bLWpDivdzlq0p23utw1WW2sy1+T28b9cs2SNt61
KZT11xS2yV1ba4rbort2CHrp6hGU0tUnfkXpGgh94+gXjNWCKLxT/+PbYQv9VhD6ZaBrf82qttiu
g2J97zoscvCuY+LT2DUS+nVIzA/e8zVrHasxPv1WU7OhLd47YDrZluQdmPn1RvyuMlVTYUnuOlW9
tS2162wo668xt2V0na+x4LssMYnNV11TfcKY6lPVDSapbqn+wdSqzyQV45JG4ixcmiXJbJYUJc1h
emmeFMNmSwukB9gcKVFayO6TUqRH2Tzpdel1Nj9sRdjnWaxmpeZLbIHGpWlncZp3Ne+y+MiKyAr2
UKQx8ussIXJHZB8riXwj8l321cjfzdYw3+zI2Znsh7OzZuexc7iaVUxNuycj2WwWzuaw1WwWW8PK
2Yusgr3C1rN/Y1uYn21lv2UB9h77kJ1kf1RFsN+pZJWefaaarZqnUqkWqFJUOvFXjKr5qnWqKlWc
qloVUKWqgqrtqhWqnarXVV9WvaX6teqrYW+Gvamyq23qZlWLWlH7VK3qoPoVlUv9qvpVlaJ+Tf0N
lVf9LfV3VH71fvWgqls9pH5btVn9U/VPVVvV76h/oXqV9sdtV59V/1b1mnpcPaH6hvqS+mNVj/qv
6r+qetWfqv+u+rb4mzbVHs18zXzVdzXvc51qgM/m6apR/gR/QnWdP8lzVJ/ypXy56h9iB4DqM/5F
XiKp+Ur+FYnzl7lRiuQ1vF6K4xbukhK4hwelRfzrfKf0NN/F+6Vn+ff4oFQk/tZeWsUP8fekl/h5
fl5q5Bf4pGTll/glqY1P8SnJxT/h16V28VdTkpf/J78jBcRfTUlBraQNl7q1s7Sx0qvaB7UJ0re0
idp06TvaJ7RLpEFtsbZFOqZ1a1+Xrmh7tb1hsrZP+90wvXZI+3bYfeK/9xQ2Xzus/XlYnPYd7amw
ePG3O2HJ2gntH8OytH/SfhKWo72uk8Ke19XqboatDn8mvCrsw9lLZy9Viz1RtSwIlVm82B1cIMEi
/4u9r4GOqrzafc/8ETAOSDHGGNIYYsSIiBFTiilQDCFiMjNJI1KkmAZy5sxk5sxk/sNHKVLKTSml
SDGlSJHFpfnSNI2YYowpUkoRaZqPIsWIfFwujRQp0pSLFCmL4t37OWfCkMRK1/fdte5arXs9z3nz
nvfs8/7svd99jjMDIY0wTeSoJwqXFZUX7ldPFbaqZ9Xz6qXHe9WrPkPh2fIZvjzfFN+0WVN8hb45
Podvrm+Br6q0qXSPL2nWSZ911oFZp31jfGm+TF+Ob0Lpnll7ybZMZOnnYel/EZL0sfSxMJBdj8J3
Scfi06HC8BPDT4Rk+Knhp3Ruh+FlYTS8bnhdmPHpUIvht4bfiiR8F2i44XeGI2IEPheajE+E3mr4
veH3worPgo40/Nnw5/i/62OUjFL/v2ZmNlpEijHZmCxSjSnGFHGnMdWYKtLw6c27jOON48VYfEco
w1hgLBCZ+HbQ3cYZxi+KLHybIhuf3LiH+p8sjcbMMQt1hliqzlCLVMrB1HnqQnWx6lb9akSlzEld
odara9UNhE3qVrWR/nKrLWqb2qHuVvepXeohtUc9rvaqZ9Q+9aJ6xSfUiz6L2udLVrt8yb7RvlRf
hi/bl+ub5Mv3Ffhm+opvkP0+m6/CN99X2S+yz+ML+GIJssy30rfat45qGxKk23eY2OPb7Nvma6Jj
XFp9O32dxCx7fEfpqmK6xwnfKd9Z33m66hJpvOpr8Bt8Hn+S30rjl4a30RryJxjIiihq8JykkhhF
OolJ5Ih7hVlMIBkmHiThz3dPpfhSQDJCTCO5RRSKWfiG3RMUe7Tv1n1ZzMd36xaSvsUknxEKyRgR
FCFxu6gTS8Qd4uskd4pvkKRRVHpO3CW+TzJWvECSIX4kGsVnxU9I7hatJFniNZJx4uck2eJ1knvE
r8Q+6l8XyXj8K333iaPiXZEr/hfJBPEeyQPifZKJ4oL4kPp+WfxVPCSukTwsGaRhYrI0giLgVHym
+1GKgKNEAT7TPU3KkO4W06Vx0jjxGL7ZV0gx0SFm4V+wKpK+IlWK2VKVVCWewOe7S/DNvlLJI3mE
TfJJPmGXwlJEOKSvSStEOUXQVWIexdBviS9L35bWiKelddI68RV8v28hxdMO8YzUKXWKRdIe6Zdi
sbRfelPI0q+lXwtF+o3ULVyw3xqKAqrwJNHCCR8+Q+dPiibFRC0+NxdMWp60XISSViatFGF8zyWC
T8lFkxqT/l3UJf046cfi32htT4tLsP18/qUVbwYhm5BLmETI11GgYyahWDzlzfbmeid5870F3pne
Yq/NW+Gd760klr0eb0C94I15l3lXeld713kbvJu927xN3lbvTm+nd493v7fbe9h71HvCe8p71nve
e8l7VTWoSaqVZIyapmaqOeoENU+dok5TC9U5qkOdqy5Qq1RFvayqakhdoi5XV6lr1PXqRnWLul1t
Vq+pO9R2dZe6l+SAelA9oh5TT6qn1XPqOZ/JN8LH30cwmD3mIG2F/9O6nSzWQPb532XfpSQjYeWj
YOW3wco/AysfAyu/HVaeAitPhZWnwcrvgpWnw8ozYOWfhZVnwsqzYOXjYOXZsPJ7YOU5sPJ7YeX3
iW6SXNj6/bD1CbD1ibD1B2Hrk2DrD8HWH4atP0K2bhD5sO/Pwb4/L42VMsju2bILYNlfgGVPw3cW
psOaZ8Cavwhrnglrfoys+WvkA1+Xvk4+wN9cmA1rLoY1z5G+J32P/IFtugTfWSiFNdtgzQ6pm+y4
XDooHRRfSnoh6QVRkbQ1aat4MumlpJf4O7mjlo9aTeuUTHN/i5CCR4TwNBFaCTsJnXrdHsJ+Qjfh
MNeZbvM0B1vU4r8PtLGF53h2BNs87cEOteJGcJ1nV3C3Op9QGXYwPHuD+1T574PbeA4EuzwHg4dU
z3Xw354jwR41QIiF53qOBY+ry/4+0GZleIHnZLBXXR3s9ZwOngHOBfvUdYSG0CmUN4er1G1hxXMh
eNFzOXhFbboO/N0aVj3XQkLd+SnoDIfUPeElXlPIAowIJXtHhUar+zVwmcemdl8H/+1NCaWqh0Op
fATSQxnq0U8Ht/NmhbK940O56okb4Z0YmhTXmwjv5FC+euo6vFNDBTeDwJG6Ud4ZoZneolDxkCgJ
2RiBY3UpDG95qOKmMC8037swVDkIi0MyI3AyYvK6Q56bQeB0XbrXHwoAkVAMWBpaxgicq8viY+2p
WKa3J3TUuyK00lsfWj0QgQt1471rQ+s+DYHLdROhY0OoAdgU2uzdGtp2AxpDTYPQEmq9AW2hnTeN
jlCnd3dozyDsC+33doW6B+FQ6PAN4HHfBNSz4eXe46ET3t7QqSFB59Tz4VXqpfAatDsTOntT6Aud
914MXRoE1nc1dMJnCK/3XgldvRn4ksIbVRE29MMSTooD562EMeEtKKeFt/syw81qctiK/g6ALye8
A30YHR7zafBNCLf78sK7Eq9XU8NpNyAjnDkIfO2U8F41O5zjmxY+gGNh+OBQ/fkkqLnhCeqkcN4g
5IenqAXhaYMwM1yYCN+c8JF4bL8hFuuxMh7jfI7wsXgM8s0Nn0yMI/12kriu+pr0z9GC8On+ua0K
n0vsE2LJNYop5PtBkxYDgiN0Hya/Co4KreN9g+09mEJIr5sct+dgFh3pPnzep4Qv+NTwZV8ofM23
JGLi/cW3PDKC63lsvlWRUb41kRSOr771kXSOk76NkSzflsh43gN82yMTObZjzGTvvubI5Hh89u2I
TPW1R2bwuH27IkU8F769kRKOnawTOBAp9x2MzPMdiSz0HYss9p2MuH2nI37fuUgEeyTvQbwn8Bxe
oH1S3898l2n/ic/ztUiK3xRZyjr4nH9EZIV/VKQee098r01Yo36dDH1Pie8F3CfeG/0pkbXcN396
ZEP/OnN7Wjtee+zLtOfx2PxZkU1c5x9Pe/gODbxf8/zegL3avow9i/djuk98L+YjQPaDsQ3YY/nI
8E8MXmTwHhvfV+PwTw5ZGPE9Enumvjcm7pU37JH6PhmHfyrtg7TG2PtoP/TPCE1iwG55n5usoT9m
EfxFka04lkQa/eWRFvgYxQ//vEibf2Gkw784stvvjuxDPfkw7x/wW/Ij9ie/P9Llj0QOcSzyL430
wC90P4jHRbYt1sNxzr+C4lPcR3i9KG7x9fEYOMi3BvhVPL70+xbroLjpr48cx5qvjfTGr0d78jf/
hsgZ/6ZIH/fbvzVy0d8YucIxHDGJx9ASFf62qAXXfVoM0vvl79DjeDwuXU1oo/cZYx0Qj/vHQ3E4
jk+MdZ8QT/279eO+cA6PKY5BcTIxVnJ8jMfIhHiItWc93IZjE82Bvyu8Nzi+bmpwYt0MBuc2vN6c
0wQn1xWhjmJWbXF0ZXBqXUk8fwnOqCv3X4nmI45R3hEsqpuHnIJiWm12tNJ/MTopnhMES+oWIqbx
/s95A8e68rrFvEcH59W5gwvr/LX50UBwcV0k6K5bGvTXrQhG6uqDS+vWBlfUbUBOpsdLvha5WTxv
4pxHz1GgS9eBPtbXbeJ4iX7Fc7t4Hua+HoOBeA6j5x6si/Ox4Nq6rZzvBDfUNfZfz+15PPw354Kc
c9HYgpvqWlDHeWMcep54AwbmgnrudwP0eR2Y1/WDc7E4BuZ18RxtiNwsuFXDp+ZmnHsl5l+cc8Xz
rsQci/vK13Kb+JwM9C3yP/+haPIgv+qJjo7nWP7j0VR/bzSDY1F/vDoTzWa79vdFc2FP8Xpuwz7H
9kfHWhEtqLVEZ6KcHC2uHR21MRL9rTY1WsExojYjOp/tszY3Kg/KYwi1k6IegOyRAT+kuFVbEI3h
ODO6LO6D7BO1tujq2oroun7/I7+qnR9tYH+rrYxurpWj22o90Sbee+JAPKJnLPgfjbk2EG2tjUV3
QjfFj9pl0U6MU29fuzK6p3Z1dH/tumh3bUP0MMei2s3Ro7Xboidqm6KnalujZ3n/YyBOUk5QuzN6
vrYzeonjce2e6FW2U94La/fHDLXdsaTawzEr5utobEztiVgaPyfUno3l8DzVno9N4Pa1l2J5tVdj
UwKG2DTOATn+x2NzIClWGLDG5jBYH/YZfh4aE3PwvAfSYnMDmbEFbGeBnFgVYhitY2BCTMG5vJgK
HVNiIY7lgWmxJYHC2PLAnNiqgCO2JjA3tj6wILYxUBXbElBi23l+A2qsGXGMxh8IxXbguCTWzvYQ
WB7bFVgV2xtYEzsQWB87GLcfzsE5/whsjB0JbIkdC2yPnUS9HnMDzbHTgR2xc6yf/STQHrsQ2BW7
HNgbu9Zvq/HngPgeReXAgToTtwkcrBvBdcIgJGu3tQe/o/iv/4/yz/X/Uc6JC9f/b4BTFh7nauc6
Z4Nzs3Obs8nZ6tzp7HTuce4n7nYedsq6rAOOOk84Pbqccp51nndecl5VDEqSYlXGPDVZSVMylRxl
gpKnTFGmKYXOlc5lmihJDGWO4qA6yNyTylxlwVPjlSpnTFEUVQk91aIsUZYrq5Q1ynplo7JF2a4o
zoAm1KJZ2aG0K7ucMU2oxV7lgHJQOYL+cY+4JZ/jO9Id+G3/refJwh//b3kbWkoeYie5DW9DR+Nt
6GfwNvR2vA1NEYpwizuEhyQN70TvwjvRsXgn+lm8E83EO9G78U50HN6JZuOd6D14J3ov3omOxzvR
+/BONBfvRO/HO9EJ5HndYqI4SPIQ3onm4Z3ow3gn+gjeieaL98UfxefEByRT8Wb0UbwZ/QLejE7H
m9EZeDP6RbwZfUzKkDJEId6MzsKb0SK8GZ2NN6PFeDP6ON6MzsGb0SfwZrRE+pr0dWGTnpWeFWV4
M1qON6NfwpvRJ/FOdC75+6viKek16TUxH29Gn8ab0a/gzegzptWmb4tK/BJdlanD9JpYTN69X8im
M6Y/CoW8+BLNpSRiYtl1W5Unizx5sjxVniEXySUk5fI8eaG8WHbLfjkiL4Xsk7vkQ3KPfJykVz4j
98kX5StO4bQ4k1nkFXK9vFbeIG+CbAU3yi3EbXKHvJuF7cZwP9nNA7rdjMb92WIMtEb3kvWwrZho
/vPIethWLLCVYWQps8iG+M35cLKO+WRDbB+3wD6S8bb8VhpXDVkSW8MosoXnyJ7YDkaTFTSSPbEF
jBEvk9wOC0iBBdxB67+P7Jbfit9Ja/4uWRiv+l1Y9XS8CR9LK39WZGCNM6VRtMZ3Y3WzsK7jsKLZ
0jNSpbgHK3ovrahfjJcitKK5eNd9v7SGVnECVvEBrOJEvNl+UHpV6hCThJSUn1RwfT2q6023VdcP
FPmofKJ6bfWGuMinqjfpsnWgyGerG6tbNJHPV7dVt8mXqGaAyFedhuoOkt0k+1icSU4rHbuqD8XF
Oaa6Z7A406Chp/q4Lr2aODOrz1SfcSYR9w0WZ071xeorcZEFt9VEtuiSPFA8qZ4MebScGhdPtpyh
S/ZA8eTKufF7eSbJLELOHSie/JosOZ+E71fA4imQA3ScKRfHRVk8WDvpnwkN2f0za9PEUyxXyBUe
G/H8weKpoPFVxoWuuv6fRxfLQHFOcOZRn2JxcU7R66ddn4m4OAvlZfLKfqFWdI/VN4pzDsEhr4M0
yA3OuXr9AmcVHTfHR0Ry3KnI2waLU5WbSFrlnSzOkNypiXOJc7lzlbyHVn2NvGfwSKjP62mO9vdL
t3y4Xwo0cW5k+3Zuge02Orc7m2FjO2Az7bCoXaRnL8a72nmAStyjvdCvaSJLcbZjlXI98z2VWK1K
nn2lhyfaOcd5kHxnrfMIec4m5zHnSedp5zk54LxAc1XsvEy2vNt5jey9RzEpI+akkC33KaOUFCWd
jlk0o71ygP4er0yUK5XJylRlBvWY7b9PKcKs7VZKlJLqXm5R3aKUK/NIF3stRoSWmq+wbfZWtykL
5W3K4up6xU31Z6jdBvK6M4qfSmuViLK0epOyQqlX1ioblE3KVvhymyZKo9LC/qq0Odud7UqHspu8
tUvzWGWf0oW70Z2UQ9SbHvZJ5Thp7lXOKH3KReWKS1RfdFk0/2MPlC2uZNdosrUA7M1CZ1NpnRtc
Ga5sudWV65pEazxF3uPKlwuULFeBa6armGZ9Na2AxWUjK2Wba3BVkMyX17kKNAskwVqh3TbYDNW5
KgmyvM1FFu8KUP1hV8y1zLXStdq1To65Glyb5XVKimubHHA1uVqpzU5Xp2uPa7+r29UAG7e4DkPP
UdcJ1wmy4nbXKddZ13nXJddVeTNLdYvb4Gp1J8FWd7rOuq1yp3sM2ynxHneactyd6c5xT3DnyTb3
FHm/expZ73K2RHehe47bQRa8n/6yOFd5ZHm0x+MmG5EzPAGKtgWemLzNs6y6jyxYpihgqemgSJHt
WVld4lldHaHRdroaPOs8DezXZDM0W57Nnm2eJk+rZ6enkyyUIgdFgwy2Adni2ePZQy32e7ZV99XM
cB4gXRzvYMFoiSgDC86SJ3m6qy8q9RQND9MZmdqlkt9UeI5SaTTPgpyhRDwnPKdc2zxnPec5Cspa
/JvEc4U56/RcUno8V70GinMztVjnTfJa+W58J+8Y2eZN42hGXOFN82Z6c7wTlBRvXvUZ7xQtciF2
eZQe7zRlqdxZM5574p5L2tl2Ot0L3FWyxa2wUG+zqN/ZbpXtwx1yL3HZ3Mvp7CrYhE1e7V5Dsp5W
fLN7o3sLrdt2d7O8zb3Dletu52vd7XKTexfZTUV1j3uvK9+tkuxyH1D87oN0x2wa90nF5DwpV7iP
uI+5T7pPk/f0us+5LziXV1+UC6o3uLKVeUoK9awVZy67r9WYXNk1I2pG1aTUpFcfp12gQW51b5cn
1YyvmVgzefEB5xHaaQLOyzVT5XzSXFAzg9oXybaakprymnk1C2sW17jJanPJGjwU6wM1/ppIzdLq
SM0KObumnvyY4m7NWtdOGmGq3KCkk41sqNkkF9dsrWmsaSTvsZHOlpo2+RTZzmqavaYnT9fsllfW
7KvpIj5U01NzvGaf3FTTW3PG5anpq7lIrVNqrrirKPW1uPI9gnwl35PsGe3Kd51HNvXAv54z/+me
MxXhxyccUvjfaliUIaRFlWLMojSSTJKcRTkLbAtsiyYsmvB0z9M9i/IW5fFxwfwF879a/9V61E0h
mbZo2oKVC1YuKiSZQ8LX5ZM0LGhY5FjkoPsYrBusz9M9RuG5RuC5xoAnGiMyXxOeaMx4lrEg8x2G
Z5kkPMsMx/PLLXh+SUbma0XmOxKZ7yg8udyGZ5bPCGnU4lEqxoTPIFatF1JVMx030nGH6bYnRlVt
vxmU7KRjCiH9E5CloWS/hifG3yQmEiYPgakaSk7QccbNoeQsHYt0lOgo11BSrB1LDYQkKs8jLByM
0jF0XPzpKM0k5FDZrcNPiAzAxCGwdABW/AOoJ6wdAhuG0MvYNABbbw5lPPeNhJZPQJuGshkanui4
Sewm7BsCXRrKeN0O3RzKeG17dBzX0auhrFw7OubQuhdQ+QyhbzDK2AYufjrKFuo6rmgoEQTLACQP
gdEDkPoPIIOQPQRyCZOGQP4AFNwcSh10nKn5x5Cgc6VzCQv0drabRAVh/hCYqetU6Fh5cyhV6Sgn
wJOAeJsl+nE5YRWVA9fvlYjSNXo59ukoXU/YOEDHsgFYOQT42i10XE3H7fqxeej+fCLWERqGwGbC
tiHQdCNKd1Rdj9+J8TYeL+NxrP16fCnddWP86LeTxHWNr0t8jvYmzO2BG/vUH1MSY0Dch+P+xXuG
bvNl1IcbbLpSO196kHCEcEyLEby/lJ7W6nlMpecIF6oQX6vWaHGy9FrVdpupCnuAbUSVFt8Xa/Zu
4znR47ON9jRbujZeW5Y2D7bxWrxknQwb6yVbsFFctNHc2agPNtZbrs9vfD65/7xPxvewkoR5Zj1u
TQefs9F+YYvo/Rq4TgPWqH8/ia8Tj5X7slTrm21FwvWL9fXjv3lc5frY6vW6lARkDYGB+/LUITCj
6vr+mrDH9mNeAgbusfH98r+yT9ZX3bgXbqi6vgcm7Hf9MYtga9GPtG/ZOvR6ih822pNstAfZaP+x
HdLryYd5/4Df7tD8yUb7jO24FotsvbpfxP1Aj4uwrS49znkSfOSCFrf4+v4YONC3BvhVf3yJ+9YF
vf99+ppfTLg+pvmbjfYmu9D6bac9yc57ULEek2gMdtqD7Kn6dZ8WfwbG8aHaxPs8RDzuRyABn3Sv
T4unqwdgYJxMjJWbq67HyMSYOFO/tkE/V6DF6DKyn7INGji34fVGXrNJryNbsbdSmeOYnr+UUW5k
r9TjGK1pGedEfVo8s/Pc83zpOUFZmx7LeP8Xepxj+6M9uoz0lZE+O/W3jPMfzmvIzspYJ+cxZ/T4
qcdLXDu16nredPx6HIUuXQf62KfFS/RrYBweEIP7c5h4HOZxsi4+TzZVdiXh+ovaePB3i+4nNLZy
odc1JqBtCAzMBbuGgD6vA/O6fpxJwMC8Lp6j/Vdys4yqG/Ov3KrreVdCjsV9xbXZ1+dkkG+R/9nz
B/uVvaCqP8eyU729WItF8XZ2m2bX9grdnuJxbLfmV3bdv+wUV+y639nJx+wxDYn+Zme/4vqVun2u
qxqcxxDsDTo2a4Dvsf5t+rHpug+yT9hpr7N3JvgftbPv0fzNTnu0vZtwWNt74uDx8jMWzxOP2X6U
cELXTeOwn9LHqbe30zOd/TzhEuFqFWKRw0CgZziHlTBG2/8YiJOUEzjSCJlaPHbk6HZKe6FjAiGP
MEWbL8c0QqH2nOBwaPPkmKu1d9De4agiKFoOyPE/HpsdtAc4QjrytH2GbduxRJt3B+WgjlWanTnW
aPPI6+hYr5/bqOvYosVyB+WIDsoPHRR7HJSPOSgPc1Be5aB8ynFQm1/HET2O8fiP6ceTmj04KBdy
UA7koD3CcTnBfuienA84KBcqo1yobIRer8fcMsoHylL09SM/KaM5KqMcoGx8gq3GnwPiexSVyyZq
bcoma3X4ZEaS9ZZ/fTLjn++NmSnXtI//76qhS7wkxLBMQg5hAiGPMIUwLeFYSJhDcBDmEhYQqggK
QSWECEsIywmrCGsI6wkbCVsI2wnNOnYQ2gm7CHsJBwgHCUcIx/Q+nNTvefoTjucIF3Rw+8uEa0Ik
mQgjCKO0viWl6Md0QhZhPGGipqf/OFk7z31NmkqYoY05qYhQQignzCMsJCzW7pfkJvgJEV3/UsIK
Qj1hLWEDYRNhK6GR0EJoI3QQdhP2EboIh/RjT0L744Re/dihX9ebcP4MoY9wkXBFkLMSLNePPD/D
yZOHjyakEjKG+HvgMZuQS5hEyNfm8h/ChBsxvEDHTEIxwUaoIMwnVOr1fJQJHkKAEEu4fpmOlYTV
GgbdYx3wUunW0sbSltK20o7S3cC+0i6LpfRQaU/p8dLe0jOlfaUXS6/YhM1iS7aNtqXaMmzZJLm2
SbZ8W4Ftpq3YZrNV2ObbKvl/WwMBWwx/LyNZaVtNWGdrsG22bbM1lfbaWm07bZ22Pbb9QLftsO2o
7YTtlO2s7bztku2q3WBPslvtY+xp9kx7jn2CPc8+xT7NXmifY3fY59oX2Kvsil21h+xL7Mvtq+xr
7OvtG+1b7NvtzTi/w95u32Xfaz9gP2g/Yj9mP2k/bT9nv2C/bL/mMBFGOEY5Uhzpjiwu4+/xjomO
yY6pjhkkRSQlJHzkv7lcTsJ/zyNZ6FjscJP4SSKOpY4VjnrHWscGxybHVkejo8XR5uhw7Hbsc3Q5
Djl6HMcdvbQz3DnkLzEI/ZcYkvBLDCPwSwzJ+CUGK36JYRR+iWE0folhDH6JIQW/xHAHfoPhTqts
jYq7rHXW1eIB64+trWK6tc36qphl7bT+Qjxh3Wd9Q5RZu6y/EV+yvjNSEk+ONI40ieUjrSMfEivw
qwyN/x/3TJJGS358dqWT/73tcYd0kJePI68eR948jrx4HHnxuIsJZQZ5NDkj6rLJm7OTtfrs0TpS
dZDXZlPDbPLabPLa7HytbXaB3p7ryMuyi3VdNr2+Qsd8/b58rlL7O1sW95duIkn0KOYO9qkEj9Kk
369Kj9uSyS8Ee1dpG/wr0bvybTZaq5H4BQ6B394w4Lc3jNaYNSZM1m9b1wiz9bvW74lh+B2OZOuP
rE20Di9ZXxZjrR3W10SmdY/1VyLLesD6a5Ez0jDSIMaPNI80i/tG5o3ME7n/j7VL1542PUa8whwk
vgVlB8rDUX5Iry8mnmwOob4K9d9HeQ1xnvlllItR1q59CGUHrn2QeCLX/+2ySYUevnYE9GeaHiZe
YH6aPwdlXoL6mcRF5jDxBrR5ke/7tzYu/+0/0YcG1P8Q5YfBk3Hfh3VmPbPNtbj7TJT57h+b7qdy
IdpMA8/SR3c/2vjQw8fQ/8+j/wFcxeXhxkvoVTqPnTZimjczXzUWo55v9hJ/Qdc2EuVHoJ/rk1FT
bJ6O8mMoay3zcV/ypmtJKBeiPMI0FfU8LoH6WXo9lwtQLgLfgpZFmJ//Y3qUyg+Ya9D/qbiKy7cY
L6DNRJ4ZrFeZ2YNr12CuuJxs/CN6dSfxGIzodp43GnsVytxS4vq//Qmr8CfMqoT62eBhpiYeNfg2
8Gzww2h5i2kKuJz4czx2Q5lZ5v+bba4k/iaPxRBBeTr4KM+8YRm3kQzg59E+j9koo83z5kXEjdB2
G9dI73BZ+hBnn0P7WWj/XZTHQM+H4JNof8X0G6o3mN4gLjcdYf1clv6MGtn0DnEBtxGXmKU54L+C
X2c2GtHyceh5kttL70FDE8o/xdnZaP8x2ueifBq8F/wK2n9gItszlJh/RWX4iMFi/gWVr3G9VGXu
Iu41kS0Z0riN+MD8LPFfmKXTeg2xMQ960sDpuLYa/Bz4DtPHOPtVKv+W2XAc5V3gQ+DnTQt4dSwf
EH9H53ZwM7ge3Mc8LJXueBWz/Spavmrh33HZgPJ0cK1ebgbXg/nax9HyEs72co1xBGp2oGartu5c
libr3A5uBteD+8B81eNo34prBTjP/APiIqz7X1Hzps48lkaUj4LP6eV2cDO4HtyHloX0NJFtroeN
KcRfRfvHwA+Bh4PvAT8H/gv4Vzq3g5vB9WDW/HvM3ne5jfGX4C69zGP8ENc+pTNfOxrldB6v9IG5
m8pjwVP18g/BfvAz4DfA50jnHVj9y2g5mlk6q/OzsKi9bGmouQYNo1kDld9A+Vn4Tjf4DbBW00lt
HkGv7jbvgwWyhuHMVPaDn0HNW1T+EazrJOz2JS6T9XbDj7jeS88kkmRnG6b+aOPiEb3Jlm9IR006
atLRw3SMMR39sXFPyNpbaKRLMNJvQHMr+Dnwa7oG9rggvOkOy+1UMwX1adCcBs1p0JwGzWk8e+SV
rL8ZLY+Dz+tlai9tgf5D4D697Ee8wujAP8OMdWEsrwzju9SCp8OqZS4bR6Cm0fxzth+U74Hl3IPy
WMsXiCcx07pQbyXUiI+h2YazJTi7C2cP4exr8PE2eGgOOBMe8RCi6zct44m/jvr3EQ8vorye903p
D4irt2rRmFuKS2Yn1X8GEXUl+N8wY0vRZgJ88G2UPwtu0uOwi+qh33AneBjzMFiO5UWeHzOiumkZ
j8XSzWXLDIzr+/B9GX4xApb2H8ymEvjRZdTEdC+uh3ewzg5zG7HX1MrxBOM9iLE8j5Zl8L5vWDja
34ryV7hM0YbjSTnqG/WIxOXb0OYplJ/TPBft/4Cx7IPO9dA/DPf6DiJSL/hB9KrMfIZnm5l2H2bN
Ep6xHCXegpbTUb6E9jv0SMhev1iLZlxv3Ih52Iizb4IfAz8FHg4eO6wY3IK7c02UrYiiCpeLwAXQ
fA/Kj+g7zhYqp8Iv3kJNJviY5S62HOwmL8KzbuUdRHoKe1OUdwppBbP5CjziMl9lLoCPf4waGzgH
XnCRNRjvgH+NwV42adgUWB3bwE6sl0DLD+Bxj7IPkrV3IpJo/Aa8mM8W4mw1otBPdG/l+omo34td
rIT107r8ApGQLWoSdsw29OE2jMjIIzI+jjZ/QM0hE2WP0kzUzMU8nLV8RHwJV1UiRs1FzWlErXst
b/POyz0n1iLqs4gtfK/t4OfAey33Ev/K8h3i6fwvzku/ReQ5jrO7dPajh1yusNyPs+cQVTgW2bFG
iuUt7hV6+0POFqT/QM6QhnX5G+pfxqqNZRba/t7LuajBYWL9B01W4jOc3RnuZBZ9uGMQ4w1gjFs4
DhgfQgy5j9mYaaIaw6+h+QW0/AE0/2+UZ0NzN6yim3VKc7i3Ygf6fBb8lHkE1fwVeUg5ND+KlcqF
noNaZsLZLGVQXF4HT1mNvO6syY3+s62Ow9lN6PNbuNdb0JbGYzT9jufBjNkwfcRsjGCVU1ib8W0u
mx5FuQgj7UP/P0IE+wh+nYbefgCdu7iHxskY9XC9t9yTLJQnmOjJRXoTo37VRPm2OI++HcC1O9Fm
qsnDEQNXVXA+bKgw/ol4g2kWaZ6GFdxpWsy2bXiBykeg7X2dWduL0POIPksmKr/HTPY2VnC+SjNg
HIZ5+HdcFQCvgyWcMfHstaLmx1jx8dD2NHpoQzmMGfghZnsmRurGte+Dj4OfgO/3YiwrzItRHs5W
wTupwHqJLdDpBVehtxXQaTE3cDzRLZPHG+b7ihfQ5oolm9n8Ifht8OuozwLPIQ2HtCydW9I+yDzV
/A5iPpeLtLwdet4Cvwk9b0LPm9Dzn2gvo73MNQY/agpQY9PyfC7TTvch+G3w66jPQpnb36o9C+Au
r2uMbPNx6HmcrzU8ifKTWpn1EL+O+izwWNSkw67ewEyyzveg7SK4CfxTcIuJ9+vZ0DkbOmdD52zo
nA2dszFLs1mzMZdbGnMxA3uhYS/Kr6D8Co+CZnUL+s/8M228XKa+bYGeLbjqQ2jgmino50c6s3e8
buI+lJsfhBfz6jxr4j10j/48xXd5w9QDX8bzFLcU2rPPKTwN3YnnpmLwr6HtTui/BO4Bt+DaeeAi
XNuB+vfB3SayW0sWj8vSzGxycxvTQfNrFAFwL0vAzDvgAsyVHzPwV7S38qxamuHvD6G3b8FO3gOv
05/s3sHq7IdNvoNVewczA/tk76MZyOGVMt9BvBlPkQa0zEDLt1BeibsXaPaGtfgx1xiNWCkj6h9H
+/fAH4GbwPvxvNNkOY27cM3HvC60vlw+rTPWGuUOzXK4hixhDlZwDlacntyFbPwdPYNPMt9CHLF8
m57l4Y9/e8+8gdq/gLyui+fE9HneiUzVXDa+DP4e6ps4ezS9iGiJ9pT/c/72WVz7BPK3GrT8JT+h
m97k6G3EE7fxSTPFQNMonP0ZrvoR87C7UJ8CDVfBLWhfCTtZxmthfIXn1ngC5dngh5lNmbxGpizY
Rj3a/wIW9S6zeTvaPAyrSOOWxm9hZf+Eshtn78PZVFhLITRoT/ct4GLcazqylxexJxbxjBnfw85S
j2i5D7vJfs5qjFuRP6/F3rSN2bgUNd9EdtQHPbvBR8Bvg9+FnlPgg+Ao9qx3sfN2MJt/ifIysJbb
X8Le9D+QFd+P/PBdvdwObgbXgzmnfZefOs1nMf+Po2Uy+POWLxNrT6NLwa/p3AyuB7OGl9ESWbfp
Fa4h5hoH15gXwioWIGuNgp8AP49nGT8yzwCy3CLk242chZpyYEU/xx3R3ljPEdWEGmIeyxnov0fn
dnAzuB5M2sz38dO65RewnDfNKXTVLdC2FbwI/A50jsEM1KHcrnM7uBlcj7M8ujqeMdPrXB421vID
8DzWj6tMOvMsvQX9LTwbxunIBpfq/EOwH/wMGBbFGZ1lBFb/K2hZxBHSfI/5TSr/2fxL4h+gvkdn
P/gZ8BvgB9nqcHY/avaj5lucCRv/L3vnHqdTtT/+tffaez8zj7GewRi3oSH3+z23JCmShG6SLq5J
g2GEJCRJkpBKQpJKQiWVy5BKlCQ5KlGOpJJEJEnmme/6vPc+r198v6/X6fzO+fOcXue9P/uzPuuz
1/qsz1p7r/0883hZ5qlzD0/gFeCFcCTPnNns3ZrzTFubZ+Zp5NVI8naaPB+6l+H5NeS75FnXXUnb
vkL/lfjxrqD9e0XjlYs4D+bCW6DMsmrSKu882acHL4SZL/PCPYC3InABTwvjmU0Z7NCHMgvmUvpF
xHkwF94C38PGxtOrKFfx35Y3wJZiw97fUuTwPcZJorTbX8KMqCClIdmPfyc7bu+gaPx10hLvDeSj
yB554mE/xv+RUQgp++6PZd9toyFZsc0bT9skYxXyalq+mtJwLW0Ni/gZlkrGyy8TdLXyQtH7Fcnk
r+Bd0Yoq608+K+oMbKZg/yLz7ifmURHW1Wasw3OQ18o6bPPK1vI3MC6b8LmKlXYmngfhrRbyG7Jn
926lNBfLfGHKOsnwFPZo/hN4Tkq2xMI1/0N2PZOZoYeYQa8zO9jp2/kra8gyPLyAN+Xdb2vl4+dN
aZvHHtyuVDsZC7mT9mPHnSey9XAE7mReH4E7ma1H4E5a+5qVeW/prSJKZ+RJQD/FGrUZerRtrezE
vWfhcKHmvZDeEkySux6zeAby69g/TV3egurJogkGyGoQ3IH+bez3wWvhguCkMNZD7nfYPCeZEyuH
nAkb4e0M9rw19eJyj/CKyxs5r55flvwR2ZW2+Ydl9L3izJ0x0buyodwr35c8Eb33TbRblx3WEnZA
zZnX7eVOEevA2H3KSLUUOYj7RW3pKe5cq2W/bLNX1oR2UhrrwP1lgcwmu16tge+xLq2BciftyL67
Fvq96PeiP4r+APov0PfE21dcJdyXjeH+uBOuluv6+6RHAe+x9Qp24gu5081mP/6u7LvtKncLEf6N
Nsu61Fz24EFRZv0RZvd6ocfbTrvO1KMlwm2UFuHpqEjQkvWwgLkwjxVDSsfCydHqIbU+Z914S/bj
1mYO+jm0n/UqGGflN2jzpV45y2eEXjbxf4We7mF0RmBzfWQpmgrsiT6QPnrFZAet2a3rcE+3iz3d
+6zJdxOHLMa9Trj7JltK+3YtClKo9RvPCS/LPt0f6Nn9hTeNNXYwdQdTdyryYrmWewFX7M24PM3e
8AF2vjuZCx69e1j27F4tWngjluxwNe3xJyKPkT27HoIc2gzCQ1N4kzwv2edGmY+rvVJyR6Bt35Ph
4S77YnKgPb2up/Ntj3qIn2A4HC30FnjLWDNlLlwisj/KH0WrJJLXYKNYtdaxjvlSqvPk/uU7+Ekn
8qtp4XOyH9e7kY/KLl43QG4vu3j9En1JSEt85o53vVfGaubT/vH6qOU4bXPAOySfrwXP8kzYS3bx
tnfSnnKyl9dT8JkXUWJYFF4v+3d/NbxB9hH6D+l7kEkEOrIr30+tW2X/rksir6f0BO35gRauQH+M
T3+yJTJBda7eGt5Cf3Ng0+jZUu6nZai1Vfby7t9kL68fID5leD+5jxb2gh0ZnQcZxytk1GzeWrrL
0GTRzjnsYmbAi0KZHcoMZtkMdjozZFdlS+1OxK/GE/UGLO+Dr/v3sxKKbOAVIfFwBR6uwEN7LI+w
16slGq8Wms/RzPFGyZsKdsqV4ST2y1ezX76aXVhz9ndPyl7JZoK1dwdg+QVXzOTJsw7e6khdrx3y
vSHR3CveLNehrwTLc0+3kfE/oXcDPbsr1HPx2Rz/Ye9aw7tl72nbTy/wWQuftejpEXp6RGLlXS+e
g3b+DnifZBEeXglJfHojdyAOFwWdiJXwKvbvu2X/bnvRSd6JeZ9w3U7MoD14+AVvneQ+Ja2ya47w
Ka+K5c3eBKsfxVrKftnur6X0QZiFprU30cq5nrStDhpWWq88Y/ETPCbUW4T+NqFXB94rdf26XKUk
Pi+HLeAivE0OY4WHo7A6Eb4LDpK1LrZZIpDSmXieYt93B58mDBI5FnC/6yWlfjUivAXLdsj9RI5t
Fm8pneWZxE+yH2xOv8LcaMYot2Nc5iJn4KEVNi/J+wF9q8TfK8sovEJuVJT7l/5OeqeXIacjj8Vm
L6xDrUowg9HMlLr+QhlxfxH6Rli+wCg/KLL7E5rmQVMoO/eBWJaR0bR5cj9roHA7PpciV6HNGcTw
btFby1O09hQzVL6ZMKTwReWo6oUfyDccCpfJ5/hwELwBtip8wbJPYQ30k+UbBeh7R5YvwoV4GE2t
0WhKwxmWz0QelnPF5egPyfcoCpfCr6grHFy4y/Iq0btdC+UNah14PxwBL4K74Fih4wrVCTQNoRLq
/siPwedhsUiWTyI+p+4vaGbAS6n1CHIGpfvgaTRcxe2G5ihy6L8VVz8Jv6D0d7gObxqby+G16L+J
ZGnDYjTL0LRHLqRWTeTv4Dvwdfgjlp2QTyEHyElYOimfUOxP1pRnRdqDvZohGh1GJguWFY1Dr53r
4cfov0TOh9uxCaPXNXmx9dAY+WqR3YtgDlzAVbYjK6Ftg8h94GPw+aQ8tW7A8w/Y3APfpvQp/M8O
+4hcCnk6NklsKnKV1chZtG0lpZ9geRD9fVHvsClMsX5Gh3HAsmNU10ZJnSJW49A3THamj/b+7hYV
qgPIk+HtQudT+Cv8HZt3kZPwDJYruHpVmA0bwO9pYZifM5G/hWWTbS2vQS7BuE8MM1b07nLk2knZ
rX+K3AI9OePGhAF5GIwUeqvxUCCRCQaJ7G8hEybTx32FT8mnpdg/FGYO3mbSht+w2Ux8usrMtTOu
NLNDOB378wrsk4/zBz29AHaGObBd0oXZ0juhjaSwE6Vj8dxJNDZPRF8dfUOitwuehPulVNektA98
DI6kVtXoWmL5HHwb/hLJYnNLUt5g5yGXEL0eSulWeAIPTehR6XBciADj5ewOR5DIPB3ODuS+2Kwk
qjvCtUhi6+0kwuFqkIGcQiTfwf6dZBt564X8GfoReLsTzTyhDleG38nnU0R7BqXkgM128VmMuj8S
/720P6AvW5DLIh+U+Ns8lPjvgwcjfTZ+smnDHFoo2fsyXA1/RB/G/yF4LewFx0Vy6FM+KXgU+5Xo
B0HGSP3MnDpE3ObBjwpLWBbQxziaV5HLMyvzyYou6LfR64OUlqHvPxYutpo2lOahn0/EmFO6AXJD
PJSVOLs10Ifz7gN4Cz774aEfPlehKY8crq5hDmylPd8TZ1Y2x2OkWuInXI23hWtXYSOJIfKWcB3G
cgqW50frsFzlE/TMcW88M3Qz8m+F7W07w3vZQta6TyVKXkvky9Afwc9vyKzGbipkVXQrhSsDNpvh
m7T/5WQTS+5WzvvYrAzXDcg6484iSq2x2QnD1Ylsd7k32aja/Y5mhXFegMNguCJVh0/AO9EPl3HX
PdBcBweSz3dR+i58Ee5nRkyIZIlGeC/rSS1WLbd3eI9jZAPGojScAbPhx5D8cbi/OK8KVSHyWnga
D9ujMRKZ2DpHkRvDzsRtI3LRMMLIl8NrkyelndS6GZ93w6VYtkP+kvz/hPzfxryoA2ugX4TcDPt7
8cMdUCXJEO7RzgFiXgabdeQMsl0P+VwMeSn67sjhGk4OBEvIq3TIvc/nSSmogLdwNTufdr5eOFc+
BcNDYfIh+mjpbKJ0XRgxVv5urELL4M1hLrHy7KYvLozDvtEaLivDa6y3GWha4e0kK89GSvcQjafh
umjFEHviZmM+h/aEcjb3aLEZD++GT0ZyWJpDhEUuif+PqHsKmznwdTRdeEf6K28Xs5A7B6/ZaKdF
nzrJN3nG8m2oAt6Q1/DzJbuE7hI+rX6PfTTv2ZxvPflO1AZ2l3xy5LYLisjKwKdR20R230Y+7u1i
383nd7LXKDzp1lfyrjsudzfvdrnXe8/KExFypndM2i/0Au95qznOdydOC51J1Oov9HfwfqYsTPfG
yFzGQ2OhO9/7gN3ZMT4JlVq5sBvMxFvSK2stV+i7LTfp/bJmIo+Qv6Vyuwt1N71X9phiqdYLHUOt
TUJvl1D31A9bzWLqZslbEXcFdXtSWlXod6HWbrgFToEHtHxCtFtLzHvr0dJ+eS9hvYmmhd8DG9kF
5ItGLRBZrUQzC/m02Hsnsd8udE7oDdI7PVvWcyznC701yONhFpr91Doi9HsgT4HFYfdIY1vl1hdZ
Z0pr1ePUHSjUo4XOIlqiXUfon5DfVEJ2XVc0znpK5ZvtjRwb5+QffKuniztFVgl5X+Tmu49Ij9wH
pP3uczLfRXYnuZMkM12522aLvfMynCbUD2KzzuX7Y+50y0f1g5avIk/XL+BH5GJYruaKfaj7LHID
GHPls+wCrn7aLSGz2yUH3NK0M12y3eX7CW5gNRe7CZndbjXZ74i90xl2FapfhVrjoQPernXLyFrh
fozPUP5G7ikiO0ux7ISHJHXPQ/4Ovu3YHaWzkjYccuRTxbqOvJW166XVnHHk8/EC54TcHWRmOSeQ
O3oZ8uTg7JP2CJ2L3UzLEu4qua8531oPZWFxWFdovVmqb5Cnw+LOXiz3yrxG/tIZLXcWfH7s2p2F
M8vZY/XPE+dA2uNm4ed7+CvzfbZSdtxzPVuaXBpkIH+NXFRkPpdfGFyA/mXR+/Km8ZlgkWUP2A4e
FuqDcJnQT0N/Ruh68GE01bG5SRh8jmVN2InSSsi9kbtj+R0a9N4UYawCcjVK34In0HAV/SFyP+Tx
sAuaCXCU0KG1bmtKP0DeR3sCbGbAJZS+h/wq8k/wKngDenqkC6gbetsK74O3w0+xbIxMv/QfXHEo
8kba8xk8hOZZvPWlVjMst6CviLwceR4xWYU8Ej4Na1DrmZi9+wTlwtER2TsMC8MxEtlPQ3MGuU04
RmhmhiMlsr4J9oa5eLs5HC9qxcJRQyYmwdFw1LBfBr+jtJIwVgHNW7StHpZT4cAwPlz9Elq4IYyJ
aNws5DBixNlbCFtxRaLtHKOUSLr5eCDr/FlwE/YL4A54JaTXXphp82jnWOyr4IGY+4Y2kD9uVXIv
FfsD2LyEfBGWYY61hUaY8pLUTSlJOzU27fHwJsxAX45eVycyW7B/jFLmiLeTWpW5FrHVs8J5Rww/
py6x9abAavh5DZv6+Cee7sXUXYmeWeaHuTqAa4UzsUKYe/j5CBlL90Fq/YjNozDMEKKnh4WZzHUr
EqvlQucYmqe4VpiHTWBL2JW625Eb4aEh/B7+jn4S1+qDfDV+6JfP1f2mWE7Dz2xkIu+yPniL4Ah4
LTbhFf8GwwxZS+kdkHHRZbjiEEjkY2i8X7jiaPThmsYc9MLZzcz1E2iKQ1YGTVZovLnhSsWq4v6M
PXW94fBFuBh9uDYi64/RbEbey9XJK83ccY9Ti6zzw9kU9mgdNnHs56IJx309+m6wLKTNmjUzmIzP
sFVkhbcHMqc8csOh5cE4at2N/WlkZqI3Bu5Cz5hq4u/3RM8a5bFqeeSDy6ru9YdrsD9Bzownf8L1
aglkLfKZR/o+NOHKeYS64Zgy7pqRCsglfSNkrunpkOyNbROmkBU+9y+fbA+Idoy+B5R62GvWKN0c
XiVXV0r2Kd4zSfnMqwdsBw8L9UG4TOinoT8jdD34MJrq2NwkDD7HsibsRGkl5N7I3bH8Dg16b4ow
VgG5GqVvwRNouIr+ELkf8njYBc0EOEro0Fq3NaUfIO+jPQE2M+ASSt9DfhX5J3gVvAE9PdIF1A29
bYX3wdvhp1g2RqZf+g+uOBR5I+35DB5C8yze+lKrGZZb0FdEXo48j5isQh4Jn4Y1qFuOuoXYtEGe
SWku8s3oY5C+BEdhPUqnwoHwEmpt4LpZtDBsOf31FsJW1KXXzjFK6ZGbT11G358FN2G/AO6AV8Kw
heGIh/0aC6vggb77Bp+Mo1uVHEjF/gA2LyFfhGU41m0htVIoTSlJOzU27fHwJsyg9DFkMtPbiU1l
PBMZTfv1a5TWxw+RcS9GvxI92euHOTAAb2GGh7n6EXps3AfR/Ejpo5DRcYmDHgafwls4jk1gS9iV
0u3IjajVEH4Pf0c/CZ99kK/GDy33uYrfFMtp+JmNTKxcZpa3CI6A12ITXvFvMBzTtZTeAYmkLsMV
h0CiF0Pj/cIVR6MPVwOy1wvnBTnvJ9AUh8wpzThqvLnhHGc+uj9jT11vOHwRLkYfrirI+mM0m5H3
cnUyQZPh7nFqkSd+mPNhj9ZhE8d+LppwZNej7wbLQtqsWW2CyfgMW8W4e3sgs8Bj9B1aHoyj1t3Y
n0Zm7nhj4C70jKkm/n5P9Mxuj0xwWQm9/nANNmS1F64kR5DDkWI0NfEPyBB9IyTn9XRI7sW2kf+M
tc967pOrATGM0aOAUg97zfqgmwvVSPcnKx/3tin5q8w4bwOmWU2a7Md1a3nnoCfyPuFySuf7vpLv
RWRI7vEWxRWN+wP6aXzvLuAdiCcaZw76nkJ/h9Cri30WHnIpPSgMhiH3hx2wOYKHE1y9e/Rmo7Ll
KXlz4g5Fc8qrK354i/I1b1Gahm8/0HzHu5T96LdSN593JqOwOQJHhO9PpNduDm8ervHlb38aC3U6
b1G2S6kqFNkpgSY/lMXGzyBi2ehTIsrOuoQ3V66OZjHcBKsKkzML5X1Ul8Jt4g25u+xk3e0iO5ci
96C0HfI65F1YjkFOQW5B6bvUOoSmeOgNzf6ktKQ2NsWpVR/2pvSzkJSWRT5N6ZN4qIz+OfRNkWtS
GiDfhvxA2AaRnS/CNlA6SuRkt8KTNgJV0axQ8nZiN/J8kXVCZFUo1K3hcTSnkdnXu38X+juEnoPe
hUspTRE6J5CPwPrYK2ymwZpwIqUjaMMs5N7Ii7nij9iMRn6f0hz8xNH35yrvwEVR+6U9A9GsQpMP
p0D6qyYkd8ooJNdKHqIZlZQ3ftl4Hhy1QfQLZIzcA0L1JT6Xw+lc/QyWp8K2iY3el5Rv1l2Evp34
d48lX7D6pOpkW5WO5deicX/GzzX4/wFvPcU+KI/+IZG1m3zVMlPsvY3hdfGZQ3zmi95eV7xdTfvL
FZ62mla09tew12Lvd+O6U8m3utgfQDNY4qB+puVponcMTCbPWP1HQncE7C503oH74CFsVgr1JbSn
O5nTGGZy9U3R6FuN6pGUWbmVCC+A1enRsDD/w5ENW4J+nzAFPzFmn336tX0MSlN3icj+ZeH4Spv9
HvRoZTQKC9Gv5dnvVXmHHGZj1JfjjM4Z4nOcmZiLRt6jfo1cHw+ziFgJ5N7UKo79Rmzy0dyMPBj9
dCIzHXk5/rOQ38YmD/sVeLsFjcb+NSxTpNSbTDvpo+5AJjOj1VO0xBMGY+h1Z4mAN1foZoXzi7H7
LLmU0Vkq6zm1ksRhX8SFcjdBf0Jo13oZu29pVVW4GNYnGltpW31pmx3ZMKuP8ymDlB6Am+FnWLbA
s4m8HWcGSZ4soacempXY70FzGHkRPtug6QivR38mGqmFyKIZy1XmY3MzXIVNC9g5mu8NbWsXhr2I
ck9mzUfhWoF+NxyC5wFhHobRID6vMPuWkks9GYXn8dw9tKduCzyPQrMKzSnsM1WCaCwkByTmSSKc
gv/H8XaYcbxZLG3L18o4Spvtc7V46Ib9CixvDe2j9VCu+HhytrQwWjMV6zb9VY9zdfGzLcwQZuIb
vDc+ovrKU7RQHyzsauXr6PUhbHLJsS9lNfCnoq9E+ztGeSXRW+HKN836ohlPftZDnwV3h2spq80o
em3Qj4ApcDE9nUwfc8PYslItIebN0HRgrRsbti3yIOvno7J+2hZKhpcmkg2xGcB1T0ez9QU+0w/n
3RlW5jK0Nry7hfcXiWEXWYu8NfQiu3AspQkyxzLgnhVbHK45xL8Ta04reDqaBfZaMead7h6Ntawz
bcL4RKuB6Lcz07OQx0Qrp5Q+hT6HvM1EvgL9AGy2Iueir87dKoP8XxWtwMfl14QK97NadrOl2xnZ
euGdKym/kbKysCR3tL4y+rIa2GeVbqwVFYiJZbKKeFCK3w9UnvxtUfR2Uaji6OOiV0o0ySfkm+HJ
9fLt/WR75KnIlyIPivTz5H2+fP/fapZQeot8t03+jsDK7yEfQT4ssvzNUXKIfGc+ORN9Y/kGo/Xw
Er/k85GSX0zKt5wtn2OqLvJX/8nL5G9PkhPkr1eS+UGO5Z6YrVVwBLmUyLadj1h+EftZWhUckKvE
jiLvEf+xg8h/IIvNEPnrkuSNgfxG0xOxXrCv/C4QbWsXtjmQX3MaHbOjmbw3wDOl9wWHaPk+vKVj
Kbw31ka+4xeT3yOakCKferT0JxKZlUTg7/QiIRpsnkjpId8hDLZYPh611s7o5F2xFlxL9HcFp/F/
I/6n8FtGop+IvoN8Pz85MfYcdWtJ22I30n6RxyNPCN63fCt2yrIL+sfQXxZUtRwVuw65Bm27gd59
LvYpMaIk31FckpLCOErdBdRtHzzItVZb1sHP7fi5Afkx5PbyOwDW50j8iLyEkWofZKKxGZt8OPhV
4hBRNK8jt0cegtzB30Z/T0j7ybeusL0vpTfC9rFa5JXILYPnsZE8vJAMrCGfV9rxLUVsS9Fy4R2x
l9G/Ynkn8n3IQ4L1tGE9WTQV/VSu+Bp8FM7k6jvgJ2h2QJHziE8es6AR3w1QBYVWPk++LZAsIp/X
JxsUyC9TlYeqQGZHNfmsP9kgZIGd+8mSBessq6IpnxxHaTZ+stHgB58NCuz8TfYL/RRIG2oUzEMv
c6FCwbtc6zPLjIIjaITnwQYFX0BZZxoWfG9ZItmWu4RScefx1E5K97lrWI7KuG1YvzvUhJxewwer
VcruLa/u1jZb2ZWysFBlqjQVqCx1viqu6qomqoW6WF2huqubrY9udl0aqHLVCDVGTVCT1bSoRlEV
U+VVZVVC1VNNVUvV1q77Nyg7bupq1U/doYaqkeoedZ96UD3Cv7EZ1jIqxa5nVVSGqq8usFe/RF2p
eqhblauuUf1VjhrGvwg6UU1R0621vrxLlw6qU7errsxW/a/pdkW2mo+f0vxe7nn2DlFVlVQN1IWq
neqgOqsbVS+lVU11rbpNDVJ56i41Tt2vHlIzqBVX2aqakvtuM9VaXaquUrXUTErKqHRbWlGVVdVV
KdVINVcXqcvU5aqL6ql629bXVtepAWqwGq5Gq/FqkpqqHo3aUUwVUZVUOVXDyo1VG9VedVRd1U2q
j/JVHXW9ul0NUXequ9W96gH1sJqlHuvTMK+PHg8nw+lwNlwAF/fplTNcvwLXwI1wG9wF9/fplddP
H4bH4SmYFHoejPfpMyjXS4cVYG3YAnaA18G+fXNuv83LhSPgmL6DhwzyJsDJcBqcBefABfD5/sN6
9fGWwjfgBrgF7oR74UHruJd3HJ6CSaHv5Qy+c5Afh+kwE2bBSrA6rJszpE+O3xi2gG1hB9jZmgzz
r4E94K2wP8yBw+CoIeJtLJwIp8Dp8HE4Fy4cMqzvYH8xXA5X5op+DdwAN8GtcAfcBffm2ZHyD8BD
8Dg8BZPCIMi7fXD/IA0Wh6VhBVgZ1swb1Cc3qA9bwHawM+wOe+fl1W8Q5MDhcAycCKfCWZYNg7lw
EVwKV8J8uNGyUbAV7oRfwgPwMDxh2Tg4I4y5MAUamAHLWjaJZcOqsDZsCJvB1nl39s6LtYMdYRd4
HewJe+fdmZsXGwAHw+FwNBwPJw230Y5NhTPhbDgfLoJLoDyLu3btKfkvHLWd3Vmq/P+XZJ/J/il9
+19g19IUfkz4P3PmcRbKjsr+XzR/kdqubml2pf/3JMeu1P83S/xlakZEcydxFG+vuMPJ/4VF/jKL
/2VW+F8s9pdZkfZ6HJ0/UVr+Z13in1LbO1Ype4f616TSSK69N53/Lx0r23vzv3KUf1/9rx8dVf0v
sMZf4D+Pm2Pv5v+c6X+Jjezdf5R99pmtFttnp/fVLnVQnXJSnNJOdaeZ08Hp7gxwRjmTndnOYmeV
876zyznonHJT3NJuQ/dWd5o7313urne3uXvdI25SG11B19WtdWd9sx6sx+pper5ertfrbXb+yvVS
wtzWg885n3DO+axzztefc77hT+d23uj9fzoP7JJRV8WcP53Hp5x9nnbq7PqJTmf7z3jl7POS153t
v+TAc87HnGM//5zzFeec7z/7PLP+Oedjzzl//pzzbWe3P+vk2eUVip99XmXyOedT/nRu522VqeeU
7+Xctat48bCH1ZaGx+q5lHh2Dc20K0fVUFujdnRsGh3bRMdO/5d1LRMdS0fHStGx7tmtqDXw7F7W
zjz7XP5hgT/bN+xx9nnjfWefN9lyzvnWs8+bDjjnfOA55xPPOZ90zvmSs88vaPOnrLNCi7bnnPc9
275F/3POzy0fdc756HPOx5w9qheOsjQ2Un2cx1R/Zy53md72P+XMcmbJe0a/pNXJvwmq/bif5hcV
C8d1bF3+DVKHf4NULIqrIO2RRFratEQ8ESRSrCZwfnJ+snY/Oz9bu+POceU6vzq/Km0eMA8ozzxo
HrR3askgV1+qO0iL3OKuXC9d+XadKKFL6lq6vj33dVFt76U6XacrR2foDFujpq6ptK6n69nWO05d
26NMu6sapuaqTWqfOu1k2J6k2L5lpD2h3LRpabMtH0l70nK6jUG6vUdk2xW3vt29tUrUVdpNt+2u
xzEtUd8eS9rzBhzTElnKtWcVLNMS2ZYSMcn7sqpSoqrStr/xRDWOaYnq9phiz2twTPuTZc3IslZk
WTuyrBNZ/qO9M2jvTNr7KO39R8ksSh6j5PE/lyTSaWFxWphBC/9RkklJaUrKUuKqmGv/s5O3iCvf
hU93bW23pI28Tpua9rDybOsCZcfQjmLM+nFc+ZQ3fCpQ/PZ5L8ZUMZqOc9o5bUe20Cm00fJdX3n4
9fEb4DfmlnXLqhS3kltJpbrV3eoqri/Xl6sifo6fo9L8wf5gVdTP9XOV8e0uRSX8Mf4Yle6P9ceq
Yv54f7wqbvqb/qqEGWAGqAwz0AxUJU2OyVGZZrAZrEqZXJOrSpthZpgqY4ab4aqsGWFG8Jv6d6ks
c7e5W5U395h7VAUzzoxT55l7zb0q29xn7lMVzf3mflWJnDyfnKxsHjYPqyrmWfOsqmpeNC+qauYl
85KqbpaZZaqGWWFWqJpmpVlpl6k3zBuqtllj1qg6Jt/kq7pmvVmv6pmNZqOqbzaZTaqB2WK2qIbm
I/ORamQ+Nh+rxmaH2aGamJ1mp2pqPjefqwvMF+YL1czsMXtUc/OV+Uq1MH83f1ctzdfma9XKfGO+
UReab823qrX53nyvLjI/mB9UG/Oj+VFdbH4yP6m25qg5qi4xx8wx1c78Yn5Rl5qT5qS6zJwyp1R7
c9qcVh3MGXNGXW6SJqk6JuQx4YqETmjVifG+kvHubHMlrq6yuZKmuiSMzZauiXSbXd0SxW12XZ3I
sNl1TSLTZtW1idI2q65LlLVZdX0iy86R7okKdo7ckMi2c6RHonKisrqR37PvmWiSaKJuSlyQuEDd
nGieaK5uSbRMtOS9xwQ7PybYTEo4CTXOKeuUV+NZVyY6PZye6n4nxxmkJvPvGU9xhjrD1UPOFGeK
esQ+azyppjvHnGNqpnPSOakedf5w/lCzZCFSj7mBG6jH3TQ3TT3hFnOLqdluppupnnTLueXUHPd8
93z1lFvDraHmuvXdLmqeO9y9U613R7oj1QZ3tDtave3e445V77gT3Ylqo/uA+4B6z53lzlKb3Cfc
J9Rmd5H7uXrfrklGndGNdWOV1G11O1UoOe24ep6e52hvuPeM4/mD/EFOQ3+IP8Rp5A/1hzqN/Tw/
z2ni3+Pf4zT1x/njnAv8e/17nWb+V8FMp3n8yfgLztH4R0XaO8m069Iecu9KeybtgPty0SVFX3F/
Kfpe0R3uadPBdNYp5jZzm06Y283tOt3cYe7QxcwgM0gXN0PMEF3CDDVDdYbJM3m6pLnT3KkzzUgz
Upcyo81oXdqMMWN0GTPWjNVlzXgzXpczE8wEnWUmmom6vJlkJukKZrKZrM8zU8wUnW2mmWm6ollk
FulKZolZos83S81SXdksN8t1FfOaeU1XNa+b13U186Z5U1c3a81aXcOsM+t0TfOWeUvXMu+Z93Rt
s9ls1nXMh+ZDXddsM9t0PbPdbNf1zd/M33QD86n5VDc0u8wu3cjsNrt1Y/Ol+VI3MXvNXt3U7DP7
9AVmv9mvm5kD5oBubr4z3+kW5qA5qFuaQ+aQbmUOm8P6QnPEHNGtzc/mZ32ROW6O6zbmhDmhLza/
md90W/O7+V1fYv4wf+h2psAU6EtNoSnUl9kEdHT7hJfwdIdELBHTlydSE6m6Y6JIooi+IlE0UVR3
Stj/6SsTxRLFdOdEiUQJfVWiZKKk7pIolSiluybKJMrobolyiXL66kT5RHl9TeK8xHn62kTFREV9
XaJKooq+PtEo0Uh3TzRNNNU3JJolmukeiRaJFvrGRKvEhbon+zyH56nGrLW15N7n3OTcZNX9nH7K
8d703lRuLCWWonTKxJSJdvb8dzX+72r8n1mN/1/2lSX75InddW4Pvv1vjv03x/5DOeb4A+0zf7pT
yW2sL/O6qyzVQrVVHVU31cPuOgba5/fR9nlgipqp5qiFaolaodaod9QWtUPtVvvVIXXcPtkrJ3DS
Utcrnbo6dU3qWxzXpm7gmJ/6Nsd1qe/a4xorbeS4JvU9jmtTN3HMT93McV3qB/a41tpt4bgm9UOO
a1O3csxP/YjjutSP7THf2m3nuCb1E45rU3dwzE/9G8d1qZ/a4zpr9xnHNamfc1ybuotjfuoXHNel
vqNcW/q+5drUbZb5qTst1/0bEdlDz1enfhlF5qsoMnujyPw9isy+KDJfRxHZH0Xkmygi30YR+S6K
yPdRRA5GEfkhisiPUUQORxH5KYrIkSgiR6OIHIsicjyKyC9RRE5EEfk1ishu2//VqQeIyCEi8vO/
GZHfooiciiLyexSR01FE/ogiUhBFJBnlSmEYmbgKIxN3wsjE3TAycR1GJu6FEYn7YUTisTAi8ZQw
IvHUMCLxeBiReJEwIvGiYUTiJoxIPBFGJJ4eRiReLIrISSJyRjIlHkhE4mn/XkTiJcKIxDPCiMRL
hhGJZ4YRiZcKIxIvE0YkXjaMSLxcFJGsKCLlo4icF0UkO4pIxTBX4pWiyJwfRaZyFJkqUWSqRpGp
FkWkRhSRmlFEakURqR1FpE4YkXhxiUi8NBGpIJkSr/5vRqReFJH6UUQaRBFpGEWkURSRJlFEmkYR
uSCKSLMoIs2jiLSMItIqisiFUURaRxG5KIrIxVFE2kYRuSSKSLsoVy6NInNZFJn2UWQ6RJG5PIpM
XSLSmIi0ICJtJFPkX1qVdvOOrruq4exwn9ad9FW6v/4f9r4DLouj63fK7jPDs+VRREFFBXv3ARtN
LIgFFexYEUFUBAUVW+zEGk00Ro0ae++aaNTYjcbeY++99979zh7RYGJuct/75X3vvb+P+TFntj57
zpn5n//Mzu624e14Au/Mu/BuvAfvzYfwofwLPowP519C3+UCv8gv8cv8Cr/Kr/Hr/Aa/yW/x2/wO
v8vv8fv8AX/IH/HHRi/rG2h0P90PPzDZegKa1+A1COPhPJxw3orHEYW35fHExjvxTkTyFJ5CXHhX
3hWYQHfenWi8F+9FdN6Hf04M/h3/jmTiq/ke4mb0NHoS8CqwELuSU8mleCneSm4lj5JXyafkVwpY
msEVPcaxfko80o1NFLNGuXiitQccWSBtD890exRPtw1aM0+EvYniplhviiuoFCRa2u+6KZmVLIq7
4qFkVbJZb0aEPX77XesOgENxVTIpqmJThCIVF8WuaIquGIoJXYgMSkbr/gfo1hcuwTqGKeWUYKIr
FZWKxBqBKUM8+Gw+ly/kS/gW/gvfyrfx7XwH38l38d18z6csbo2o8Vl8FpxxjvXsOF/AF4C9F/PF
oMdqvhl+7wK/+eHss2CvBbB1NV/D1/J1fD3fwDfyTfxnvvlTPsazz+az4exz+VxrViFfCGdfwpfA
2beAXxTUwzp7ceL2ybN+Qg+02YU0m1nH/c3ahcdZtQGOUzuw5eRzMoAMJIPIYDKEDIV2PYwMx+8D
jyAjydfQyr+xZheQseRbMo6Mhzb/HZlIJpHJZAqZSqYBAswgM8ksMpvMIXPJPMCDBWQhWUQWkyVk
Kfke0GEZWU5+JCvISrKK/ARYsYasJevIerKBbCSbADk2ky3kF7KVbCPbyQ7AkV1kN9lD9pJ9ZD85
AKjyKzlEDpMj5Cg5Ro4Dxpwkp8hpcoacJefIeUCci+QSuUyukKvkGrkO+HOT3CK3yR1yl9wj9wGN
HpJH5DF5Qp6SZ+Q5eUFeklfkNXlD3kKFpqwOq8vqsfqsAWvIIlkj1pg1YU1ZM9acRbEWLJq1ZDEs
lrVicaw1a8PasnjWjiWwRNaedWBJLJl1ZFPZMXacnWAn2Sl2mp1hZ9k5dp5dYBfZJXaZXWFX2TV2
nd1gN9ktbme32R2usbvsHrvPHrCH7BF7zJ6wp+wZe85esJfsFXvN3rC3EAYpZ5xzhavcxgWX3IXX
4XV5PV6fN+PNeTRvydvzjnwAH8gH8cH8Gz6eT+RL+fd8GV/OV/Gf+F6+j+/nB/hB/is/xA/zI/wo
P8aP8xP8JD/FT/Mz/Cw/x88rgUqQ9eVl5ZByWDmiHFWOKceVE8pJ5ZRyWjmjnFXOKeeVC8pF5ZJy
WbmiXFWuKdeVG8pN5ZZyW7mj3FXuKfeVB8pD5ZHyWHmiPFWeKc+VF8pL5ZXyWnmjvFUzqllETVFL
hIsIUVvUEXVFPVFfNBANRaRoJBqLJqKpaCaaiyjRQkSLliJGxIpWIk60Fm1EWxEv2okEkSjaiw6Q
kiF1gpQiuoiuopvoLnqIz0RP0Uv0Fn1EX9FP9Bep4nMxQAyENFgMEUPFF2KYGC6+FF+JEWKk+FqM
Et+I0WKMGCu+FePEeDFBfCcmiklispgipoppYrqYIWaKWWK2mCPminlivlggFopFYrFYIlaIlWKV
+EmsFmvEWrFOrBcbxEaxyfpus9gifhFbxTaxXewQO8UusVvsEXvFPrFfHBAHxa/ikDgsjoij4pg4
Lk6Ik+KUOC3OiLPinDgvLoiL4pK4LK6Iq+KauC5uiJvilrgt7oi74p64Lx6Ih+KReCyeiKfimXgu
XoiX4pV4LblUpCptUkgpXaRdalIXS8X34gexTCwXP4o34q0kkkpmX2/fYN9o32T/2b7ZvsX+i32r
fZt9u32Hfad9l323tkn7WdusbdF+0bZq27Tt2g5tp7Zb26Pt1fZp+7UD2kHtV+2Qdlg7op3TzmsX
tIvaJe2ydkW7ql3Trms3tJvaLe22dke7q93T7msPtUfaY+2J9lR7pj3XXmgvdVW36UKXuotu1zVd
1zPoGfVMupueWc+iu+seelY9m55d99Rz6gX0QnoRvZheQvfRS+tldX89QA/Ug/RyerBeXq+gV9Qr
6ZX1UL2KXlWvplfXw/Qaek2jkFHYKGIUNYoZxY0ShtPwMXyNkkYpo7RRxihr+Bn+RoARaAQZ5Yxg
o7xRwahoVDJCjMpGqFHFqGpUM6obYUYNo6ZRywg3IozaRh2jrlHPqG80MBoakUYjo7HRxGhqNDOa
G1FGCyPaaGnEGLFGKyPOaG20Mdoa8UY7I8FINM4bF4yLxiXjsnHFuGpcM64bN4ybxi3jtnEHcNf7
3Ygsjoz2ZVMYICiOd07jYRDfD/NaEN+P8ia8KTnOo3gLchJj6GmezJPJGYh4/clZPoqPIhf5OD6O
XMLIfhnj1hWMW1cxbl3DuHWdr+AryQ2MELcUfyWAEhw3ZaqpmtSpuqlu1AdHRn1tN2336DURKMrT
OzhK+tC+x36eMftNTWXumkMLZr44VhqDo6SzIdo/IC7ADnKToiQcGNAEiADrAZ3hJ7RdhDkcWHqA
JeseTQaShXjqBizn0CHKOXLpDsi9ddf3++rAABzWHBNXOGtOYACF39090nNZ63VvyDPqeSDPpOeD
PLNe0jrSbGqd0WxmndFsbp0RzxWCZ027R2NGwJJm1obcMOt8tKUBbmmIWyI/2hKFW1rglmjcwogL
eM0JvvNj1je2AlkgYawKAwbJqrPqRGERLIKo9uP248Rmf21/TYRWRisD52PqXHbgH4qxH0fY/7/j
678nwlox9O/GzX8yZmYRSaKj6CwGQQSyImdtiJmRGM2aQWQaj3EyFmKkFR3fxcbkvxkVB/9FPPxj
NJwJcfC3CJg+uvxfFg1/i3aSQwyf/VFUrAnsw+Ie75iHxTuaiiZSecc7pA1YRytgHPOQc8wXCVKF
WtsQamoLq16+j52s/cdxU2+oR+qN9MZ6E72p3kxvrkfpLfRovaUeo8fqrfQ4vbXeRm+rx+vt9AQ9
UW+vd9CT9ORPRttdn463ZoRZ26zzt6Lugz/GXbOB2dCM/EP0NXRTd2AMdv1kFM4BcTiX7q3n0fO9
j8dmM7M5xuSSfxqVQ/4Yl80os4UZ/S9F549jc8i/ITpHUEYzQ1c2Gy1I3GhtWp/kwTulBWkUjSNF
aBvahpSk8TSelKIJtD0pTZPoZ8SP9qJjSGU6gU4iUfRHuo/EsE4shfRmXVlv0o/1Zf3JEPY5G0yG
saHsSzKSjWCjyBi85zmejWWA9tjHn8x17kqm4AyM2TwLL0zm8KK8BFnLfXhlshEj/iGM+Iex93ZE
ma7sIzfUzGpm6mEjNkKz2piN0Ww26DbT7DZ3mzv1tH1j+5bmsI23TaK5bVNs02kB20zbHFrENs+2
nJawrbCtp4G2jbb9tLLtoO0EbWA7ZztHo2wXbZdpC9tV23UaY7spCI0TTEjaU9iBIaSKiqIKXSWq
iTC6XibJZLpJdpJd6GbZTXaj22Qv2Ytul31lX7rDuotGd8pBchDdJYfIIXS3HC6H0z1yhBxB98pR
chTdJyfICXS/nCQn0QNyqpxKD8pZch79VS6RS+gxlzCXMHrcPtc+j56wL7AvpqfsS+2r6Tn7Wvta
ehOi7Xl6y/5aU+ljiLbB9I1WTZvGhDZD28ha6peNgqyv8atxjm1+NxMG+qSL8b5Lc9o6bc2KdGso
CQAzvmMg+YHZlILtsyBZ+WLgBrNQWkvr0pbWwdJpSNZ8nCK0CNSd4rQ4BD0/6gfnrEqrQoipQWsQ
hY6j43A+znbSUs2r5lPzqwXUgmohtbBaRC2qFlOLqyVUp+qj+qol1VJqabWMWlb1U/3VADVQDVLL
0V/pIXqYHqFH6TF6nJ6gJ+kpepqeoWfpOXqeXqAX6SV6mV6hV+k1et16Wxy9pXBF4U/4U/6MP+cv
+Ev+ir/mb/jb/5N1CqiiMBxvUHDGbEa8p+UBiRNPSArOx1TBekWJICUgSbBqALDFIEh2EgxJI5VJ
KNFJDUgmiYTkII1JE2CJUZBcSStImUhbSG6kM0khmUkP8hlxJ30hZcX5Udmog2Yg2aGlZiM5aE6a
k+TEmQ25cMaUF7TaJsQb7+3mxvaahybSRJIX5zrko11oV5Kf9qa9oWUPpUNJITqMDieF6Ug6khSF
djyBFIN2/CMpTjfSTaQE3Uq3ER+6m+4mJXHUqRS2vzLIrMNw7CkKx56icUQsW7oRsRI47yqQAUMl
OZgP8wH+WIaVsZ7DY5VhSxgLA/5Yl9UF/hjJIokKLCiO2ID/JBBh32vfT6T9oP0I0ey37LdJBvtd
+wPiqnlqOUgWLZeWm3ho+bRCxBOiyRbiDbFkJ8lrxQlSCOLEVVLEQnVSAlDdk/gAluchpQHP85Ey
gOiFSFlA9SLED3paxYg/IHsJEgDo7kMCAeFLgq9+r4sTdanO2oEuOT/SxZ/5wxZLI85qQ89GQY1U
1MgGbK8JEaiXBC7XkbigXnbUy0C9XFEvN/sj+xPiYX9mf0Wyo45eqGNurZhWguTXfLTSoJelaXHU
1Ac1LYOa+kE0vEmCIBY+IOVR61DUuipEqSBSA2JUCPRT3t2DrQntsxVq5GPpaL3TkASk6eiTtk9B
aL0j6dgP6xidT5fCktuH/aAFfMIGQQzshpZQ0Lcq2sOG9hBoD4n2cAH225zY0SoaeltH2xj2KfYp
xIT++RbigD7YMfD5Cft54mm/CVbJa3+jqaCxAywRrJXVgkkcMIk9pD1whiPkM+AID0gqMICXZAxE
/FxkEvp8Ffr8J4jjBchq9Pwa9Pxa9Pw69Px69PwG9PxGiO+lySaI8WXJzxDnQ8hmiOo1yV5gOlHk
CLCbNuQMMJpkcgW4SR1yBzhGJLkPkT4a+gGAhNBP6kiI1Y8klayxBlLHmnND6mmb9GFkLxwTS8f/
7f3wvaL/0N4f6gOJQa/6Yp2vna4++P5WH0h9EvxhHSNVoIf6W33wtca77RfsNwjRbJpJXLTy8Guu
1lrs67+7Em+8BmfaVb6/1gBAs38B3eHIzGlzRS0spIiFHLFQQSxUEQttiIUCsVAiFrogFtoRCzXE
Qh2x0EQsdCAWZkAsdEUszIRY6IZYmBmx0B2xMCuh6jErXrJwvlFdq25V95MKf3lfiFE7dYVrzU0L
U18aQCvRMFoXrjGGtqPJtCtwqVQ6hH5FR8NvT6Wz6UL6A11F19MtdCfdDxY6Bda4Ru/QR/QFhCEb
05kr82A5WV5WGCxdhhYGGxQEixRD2QTisCWbU3+UUTQAZQsaiDKaBqFsScuhjKHBKGNpeZStaAWU
cbQiyta0Msp4WgVlIsR2SybRCJQT1OyWVFaonihXqjks6ago3S2puksPS9oWy6wot8lsKLdLPA66
K3iccJF4nLDLnJYEHpUL5UBHVfyddrQQYJIDGAeDpaKQNwHeYbGYEpBHUSfkLSigFGgIdRP0Kwl5
DAVGA7qVhrwVLQN5HC0LeWtayZqLQkMgT6ChkCcCc2GgVTXIk2l1yDvSMMg70ZqQT6C1IJ9IwyH/
TvUgDPTNCvlK1ZoDW1EahIGmJrhnsXRAvk1mgHy7zGjNrpLQKkC/TJDbpRthoFtmyAeSQtDCmkHk
T4SI34sMIMPJaDKRzCQLyXKylmwhu8khcopcIrcAZdLuL0JN8oAanxfqkpOWoUFQm6rRcFofrBEN
WiXS+WCtCWChBSib04Uoo+gilC3oYpTRdAnKGMB4S8bS71G2pD+gbEWXoYyjy1G2loUsCTpatW0C
aFkE5TZZFOV2adW+CaBrcZQusgRKu3RaEjT2QTmQTkb/TUHPTUXPTUPPTUfPzUCfzUSfzUIvzkbP
zUHPzUXPzbP8Ib3Q4t5o8dxo8Txo8bxo8Xxo8fxo8QJo8YJocf+/YelXVAE7u1FPsHJRWuoTNu5E
u9M+dAD9woqYUCum07l0MV1OVwNibAWkOAiYdgbw6wa9R5/IkoSrGnXIMiibyEoom8sQlFGyMsoW
MhRltKyCsqWsijJGVkMZK6tbkrnKMFyOkzVQtpbhKONlbZSJsgHKJNkY5QQZa0mwVStLgrXiUG6T
rVFul20sCTZri9JFxqO0y3aWBMsloBworVblkNCeYMlqT02k1ZKaS4v3R0l/y4sywPKiDLQ8J4Ms
X8pyli9lsOVFWd7yoqxgeVFarSpeWq0qQUZY7U/WsdqfrGu1P1nPan+yvtX+ZEP0d6TV/mQjq/3J
Juj7puj7Zuj75uj7KPR9C/R9NPq+Jfo+Bn1PiSKzWFeMpYrvS44q+OyCihGEIP5TsJcGx1sPT3BH
FdhDhX3C8amSghD5gt6PmtIsiEPuiB8e1nVaZ6RZP5TaWlpa0RkizljEEcytu7k0A8QwQjND/5ti
rGIYgSzmNZHsAhv7ypKylCwty8iy0k/6ywAZKINkORksy8sKspIMkZVlqKwiq8pqsroMkzVkTVlL
hssIWVvWkXVlPVlfNpANZaRsJBvTBjSSNqaNaEPa1j4ZONfUd/dEWBfWhw1hY/gEPo//oOZUc6le
qreaW83jqOQIcVQW1BEqm8imsplsLqNkCxktW8oYWVHGylYyTraWbWRbGS/byQTgAhftl+yX7Vfs
V+3X7NftN4AXCE1qLppd0zRdMzTTUc6sZlY3w8waZk2zlhkOnKGCVlGrpIVolbVQrYpWVTuqHdOO
aye0k9op7bR2RjurvdJea2+0tzqYUGc61xXdS8+t59Xz6wX1wnpRvbju1H31UnoZ3U+vpYfrEXpt
vY5eV6+n19cb6B31TnpnPUXvonfVu+nd9R76Z3pPvZfeW++j99X76f31VP1zfYA+UB+kD9aH6EP1
L/RhZl2znlnfbGQ2Nps4gh3lHRXMlmaMGQt+KwT1pD74zRoZKQZ9gxrAituxROLDUlgKKcV6s96k
NM7xLoPjHWVxFMMP71X48+/59yRA9YAYGWj7ybaaVLRtsm0iIcJ6jKay9RgFCZUGRL4qVj+fNLb6
+SRGy6sVIQlWb5901vYC7+2lPQTGO1DPBYz3K91b9yYjkPeORN77NfLeUch7v0HeOxp57xjkvWOR
936LvHcc8t7xyHsn6JWB8X6nNwSWOxNZ7gZkuT+bTYHl/gKaryZN/o6P/0Wf/gOe++AzO1qToDVd
0I6uaMfsaMe8qHkx1LwMal4HNa+P/D7y3aiJaqoZESfCyA7IK5Gc6VvR7+v1n9fQd7UJzpAR6w7B
usPRwzb0p4n+dKA/M6A/M6I/XdGfmdCfbujPzOjPLOhPd/SnB/ozK/ozG/itOcmedvUO1TXd1ZvQ
V0tr9xYSYc0lWHMp1lyGNZenHZtBzZTuWA9g0x+w5B1GOEIRz6zRQ4K1WsVaLbA+W09ufUEq/Xfj
WXqkEvTvIRReZUHgrQRbYEFsdcWxvZV4N05F79Mn9GUay87IsrDsLA8rxKur7dUktaPaWe2t9lX7
m23MeDPBbG8mmR3NzmYXs5v5mdnL7GP2M1PNAeYgc4j5hfmVOdOcby40F5vLzB/NleYac525wfzF
3GbuMvea+81fzcPmMfOEeco8Y54zL5iXzCvmNfOGecu8Y94zH5iPzKfmc/Ol+dp866AOxSEcLg7N
YTgcjoyOTI7MDndHVkd2Rw5HLoe3I5+jpKOMw88R4Aj6n7nV/zO3+r/taaoMwIpaq+6OisCnBv6t
Z0cAL2g725V0M/2lNRPuwzy6/8VcuA+z6OAcrByLSjeOaK2pATj5YTSOPiJPoe9bmvnBHiGwLoLV
YQ1ZY9aMtQJETQZs3mzdu/5Usu5Xp09wlo+T3x+TdXc7fbLuhX8yhfwuVbHulH+UIv6YrLvm6RPo
8icJotZHCXT+ODX+VIIo91ECK32cojD9ttzqd6kNpHZ/kpI/lSCifpwa/i61+F1q+3FK0w+v9t0Z
/mf08U9GHyk5A1E+CBiJ9c6m+vj+p9+/+2ks9HWnk7lkMfR2V5ONZCv0dw+SY2A/J87p+N/N/f6l
POJfyT85xvhuBFIHMZ3Oh31CrH4UxLos2PPKhs+RF6JWr7I2HQPlsfRbKI+jk6A8mS6H8o/0rvUG
bXqfcPoAvyH0mD6B8lP6HGPmSyi/om+g/JZZX3NiTIE6pzIblAWz3jqtMR3KBn4bKQPLCGVX5gbl
zCwLlN3xu0fZWHYoezJvKOdmeaCc1/qKEsTYQlAuzApDuQgrAuWirCixvg5VDMrFmfUNs+/Yd1Ce
yCZCeRKbBOXJ3PqCYDWIzJyHqe7QS7VYDAMmFGG9oV6tA/30umoClBPVzlBOUXtCuZfaH8qp6ldQ
HqGOgPJI/Lb6LnUXlHdLnVBgQNZ4VBboHVPpLn2g7OvyPaEuP7j8QLjLMgNsZdwz7hFu3DcFoaY0
NcJNHbg1NVsB5+COcsABKfSUqxLmqOZoQ2jau2UsPI9Je2L/Nz5CkY9Q5CM03VPjFPkIRT5CkY9Q
5CMU+QhFPkKRj1DkIxT5CEU+QpGPUOQj766QISuhyEooshKKrIQiK6HISiiyEoqshCIrochKKLIS
iqyEIiuhyEooshKKrIQiK6HISiiyEoqshCIrochKKLISiqyEIiuhyEooshKKrIQiK6HISiiyEoqs
hCIrochKKLISiqyEIiuhyEooshKKrIQiK6HISiiyEoqshCIrochKKLISiqyEIiuhyEooshKKrIQi
K6HISiiyEoqshCIrochKKLISiqyEIiuhyEooshKKrIQiK6HISiiyEoqshCIrochKKLISiqyEIiuh
yEooshKKrIQiK6HISt6/oejD+4qydwbphmtJ9gRnavY2NpfCg6oNempQwaamZm8Eq+ozSn00p4tN
LWJylk0lzpY2exEbVWhqWUaVqfWcdZxF063xnJ6znyfevA0iESSGdCZJAKhxJAX+rZu5wU7vdCdT
3E4PtS995vbToLJZDw1NvNCUx9Wqcm1qapbCzlTF1ZnKXkzljDIAik1kWFDQkIwHgp/E3jpbwWl8
uFKqwDUl+xRxFrLxBoqWKXdIUnKPTvFt2qZ4FYwt5OXj71/Wq1Z8bKekzkmtU7xCkjolF/fJ6fR8
t3Pmj7ckdWqZEp/UwcfbmcvazjN5/La9blJSilfFLiltkzrFp/Rw5nQ3/Ms6fXyczrJO+Gvibvg6
fXxL+qQt/geuKJXmTm8WqhKeCtUO1ttZKqVkHlu3KflK4IPw7AWnfNs9ynlj+rwv87V49mZMzRkr
30ya7hXcq87076aPiPZNOFCpVY87C7vuqH/iwc2JgzxHTBnQetkvCZ/F5DmSI+iMg466NnbLhmKt
J0xom3/8/oCiG/QfG+XfVOWqPdhvbNF5Bf3n3qr+eaWLAxxrJiQ2aLkwtde06GLdal4fv7xV4ITa
nj4yr9uUeVe/LuJxpdy4WLfoRmrclBxl6w5+OufuaLY1+68bGoQuG9pvQ8Ct+qPDF7+e81n7lPAl
HrvHuhT0JpEjo+PLrqnhKoIavm36cmZru5x9sH/DyLsrAqOy9O+mnHiyfnG/MW+W7ul7ZE62Ts2C
dq69J2fkdi6zDdyxzKtbpoFnGYeKP6P/XGf/Wc7+08GaOajSf4Kz/7f9MjTdn3w3vtPkPHX6uP1Q
66u3u6Z1+vf7L/Uv6ji3fDjmmrbxy4ffepS+vYrmPdYt48Nm0b5TJmu7gtWvh4zYEXDF+8G9yG+K
/ji16vaYu6+O7g4MbDKvTP34N3nbl9+xe/4Ztddpny/LTcmQ3G7NG9cIj/iNr/aHXMzYxCviRkzP
JfOzbi9SNl+x9XHTXL/I54id8bS+53PvHUcyP6y7sEOIr3id6v7scptEo86Tdffrblt3dYvzlZeP
y5AcYwplq3U4B5t1v985vrzpo+9Pb4+8E1d9W936K5bzgq5vRx65J0f0WfXtLwvKFr302aW53S52
nUr2tyu/6WCZL85VdJ1bul32didLnz/kqVyaG6psb1LSr0MtTyNmpX368F8P1y9fZY9ng9nJJ10D
Bn/TZcqcg1MBFaKdqbzmO1SwF1+Q8VTtt80m7dr4HlNy/KfAANq9ny/8AQL4Ahj4+MJi6fdg0AMR
FE5iy8Qa1PPJ5MxoLchM9siWndvGd2iTAj+TwWlaK0UmUTeuVfukDq3eX5j9zy4sj9P73YVlS7+9
VZxXvfg2HeCsXrVDKv4lKqzs0ftI82Wh/nNLLfQ58Txf6erdNr7MNXlbaMe7B6pcOzR8c0LNujGP
xrPNtY5VTyyRNzhuw948K7VqK/t2OR26bv4Is/Yv+Yo8mHrVyJPrQMW8L2LG78saOuubsFzj9ywr
kXtzWLFeSccz5wwc7p/B//S6Qo9aBxajvm/fFKg2+8dEOnjiy9U/xPZNfd5sav8BA79a+mDV6Bn7
/GbXHuheYHD4aecTUu7R1ufl+q8fdDvRf07xUk+WF19i7x3zdffWE8d1NgYtebDloddPEa5fxu4q
etw3NOudNWFjA2vX89jbuk6P+YsGb28YPCW19pAO6velN/XMu65u63Ljw3cX6VOyw4CqtgOT94cN
Yh0GkZkbB5+tl4YKL5z9nzozWaCQT9GddpuEgKaqgvP/N6DCYV1jJuvDuaqTg3DmsFaYShbFbXeO
vV1JctMl909sCZ9Qp3LxGZVj7zk1a7NDUaAZDUrXdBBjei5Y3Ccs/4O9a8NTpjcqkFK4y7JBrxfU
HN2d1Lq+86bHqfhfzOm9HrKQrTsH735Wb/fPU9Y1TLoXW3leZXJn7PYJhz1XaVOyGqOPnsi5qFDv
u7dnd1444oz/V+XGtVvr1/7gkCV5Xp+9fiTe5esh696cJ2tKPXza63kG1+LqzUJjv6mUULDjSr8R
54Sxo3nbPev6VUxoPXfNyjVfldr5gGfo9dnjg+cqne355vz5hW+enD1sLEs+MupixAq/6b2KHSp3
spQWU5ZN6d8uz9AnzWJHLG2yxv9o9PAGA7KVfBw4bmqqPr3FsGVFV06btWvBCa8VG5xZB3q5GYXX
1n1U8VyU8+KogvGDNyVfeDhnwd5+lTp1NQFj2gHG1E3DmJaO7rWQIfH07UgFnPkPtur3gFPS6QTE
KQmA4/R3+lqLJa1FZ8o/cmlp2/mfbP9LrJl+0v7lvp83Vf9uz/yAUovyNE44mbjeO/fK0dtvLN6w
9XD+n30zDlt7onnRl2Ua5sxcZPEI47TbjA4Fa/bNUr7iwi8rfF9liHG8/+hF39r2R1bu2uzG/Vfm
hb4pM0ruSrl892LLaX34ytC3h4NdDy/dGWXs7/lgZSbjVXS7ggO7DF+5aO3Aa+7LR65/nGVFTPPb
Gc8G3PFuOmxJv86bQy+OGdot+ruri7ptKvtlSbcSmU7G7FicbV7EuDaLDnn5Ozue+7JNlQtbPR8Z
tVMqlrim5m3nnVB96agtP/hvqzSrfTOPsAUjjn71eXB3e9VjM38YkGfzhQc9W38flrIuf8UaE1u6
RYc7t6c+3K8l97rToFa3g7JB1/5pWPPM2f8x2j6Hw2qx0AhtG9M12IfeFb7qVedZ/RrjLrsfbfd5
KbV4/mufhiYLJ3LkUTycWfp9uplXtnbIpZRzBjr9p5adWnpQybYpKckBJUrEdkos3v69D4vHJrUv
kZwQb60tkdwpqVWX2JTOJULqQUUrDquc1d7/JPCQIGeA0+/9spMNKpp2wm7dun3qhHGd0p0p5XcN
CNGmQmRSvTaTvT4vRc0r7jWCFt081r/vHaNHSreIb6t6PCSZ4/ucjBk5/XWbaRMvFSz0osHR8W9q
b4hyWfbT7NupD8flTGr84vH98/qvw2RwFnevAxt/DK0q80dHutQYfU/uXl2rw70L1VwLlh7m3els
ixVL4l3zjr5zvZTLyT4dkkbZ6+4sXLP6fN+ig65N2908/9q1Qeea/vC5trq0Z8SA0Kpv14ye1ljM
G3u6+7rIvrPmhO9+sGjihIoXdjXLG3yqb6mq4U/2be856eaKHRNj3eotWTTh7tEN+6ZOWzBm52dF
BhfduO34q0R+YoPfovsHmmV1d2x8urPf7Awy2+mRea4unVYz+MbSjPm7m5uK/jQzYduIIECbSYA2
A9+jTfVetxFt1P8c2tSPbx/XOaVl++T0aFPG6e9TxulTurQv0hsfXPR1WovO/rP/kWsr4Mz3LlDm
7BASn9w2rpNX5XqhXqH1wgN8nJX9ipX2K1W2WEilKn7vd+SZcv6JEvXiOnWNj437S4C6sVqN3X68
x+IBlYNnLdtyu+bkvGf9u+Z0OeIb1qj7wSLHZ4mRd6+We7kuf68ZLy/37uO773i5Yf5lHzw7Flgq
y6FRqS9L3Wo7sFO2EedW1Ty3auDDkna2aXrXzqVrNr+/8nxY7xyrRnc/+TbnwMyVqnTc27dApOuB
zyMC970482TY7fLk4uEz/7XEn+K93ksabb5mOrx62Lmf3X9XSfVLnqfur1bnfLya3sjxQ+xUrfDu
4kecPr+Sfr9dYDnL6t9rwROJckkRN7hCmq9ae3s/Ct2rnyDVN4nV+Vbs6yYu5emcC1gNU7sn+8k5
Ki6aNOGvq4trvulGV/O1mStTf5o4bxQ/ZG35UKDnk1T745AAeeu5hmuRCyhEgVRX9EHPPkzzger3
jB2Mf7wf1p1/bIdS9uS/8LOfvtNktXdb/545r9ZYOzofu0BR2VNSXJCcSJWyB2ZSCbYSlAOjFMZS
QGVWNXHyiF28d96tU2//RZOqxnp1DUetz5cVJ/FNXxsfHKf58+3BEK8Vtd+FL3CL/PT91CbKkPe4
WVbDdbmOpdHd/FnmUe+Ug/pDmHvtl89JsfhmdkLEeZuV3YyTvIcLGzU+py03fBQT2/8zKOhhzOvJ
E+Zmcvp0XrxY5mPCm/WwxmW5dnRzSL2riqTqkS63o6qPJRsyNUW+iR/7oKTT6Ban/eXnsmPldsr5
P5eltPYtSuJdqSu34ukEu/r/G/r+TH/z8S/L+rOe56JK1vz6LCwvbXlu8ZZre75seXdi7acwud82
H09c03LZs3+OfW2axNlNCslcpxxsU40kazbtsD2o5uGnJDkzr8fg4MeJqAWUQBb3TP8DDKqrBW+7
ykdUpS9CL6YGpvMFLZ0MTEzMQaWTJZA7AJ0vjIKTUHlzxzzv9/oTTl6FEifOedgFH/i1WmSXjtFu
If+gE81v7YxvehpO0tg2MeWBfEDLrkPeF+tZf7wv3dd9fMXVdZkFaRXqaS+2bX/fuvPsu1V/hZZw
Rypp6p93uBnGIl22NTcl1yvk9t2P9/bPbz7ecL/eh8l8ytcD8zjC5DLcz948UBajX7tNlWVLWHSW
TPL/hhqbd1dZVH0ty0vYYw/F3Ggz1yk9yfdKzpKzpuzf3Jy8qgdv7Pqnzyvki9fyl0hKMJp3qdlP
Wykmw7X7nn6LQMCmn1ulenPeqc4W/nFa4Hor35emsmKzY1OrFp1JYHvDuqHNePuPKdEtji0RrVPy
NsjreJzJn+P8IOtFvVpfNqS8aWLUAIaICvYcOiS6XwJsnNABUFFGUJ+KAan0xFo4SsI1iDCx8Mhx
MQQzlDIkMTgzOKJ2zTD6dVgKqCm+goaHagJ2C/YtTGRn5OspcO19Xxyy156TVff/jsDgVpm3lhO3
Lw7jvtezzVr64u81y09u3xioKJ3PkVmXzbxIye1tzpbcGqUdbpdbPvfy72PvMjv4uu5lQazr/EmX
zpy723fg4X6tszVvTq4zutq+83TyEbOLEor7y+5Zz9osXTxPsePGli1CIT1f5hxK9ZqloTYnoYvf
+rhwaoXH7vNrm638NyRF3DN4+dJS9nHnp1uWjT+FFXtSGpLZWKZ9msXkrF/t1rHrP9PN1J9e924x
l0zezJrHc2buHY3EGo+P4nMEFS2YZNrXsB2dZrTjqcOxYNu9KzvvvUgz7/2iNG3OmQ3lIYFW14pc
Nil/M2xiWQ8spFYzMTIaNLYPYK8Mpa+IGONe0HjLQAQe3xqMhuzMrOB9AqBUAI1MTmZDHuRhdaBr
EDxuQz4DZFlRA2WERhZDYBp7tL6zdNl9y8nL+g+siHqfJfi5y1PWIAVJC49hmEHIAq0GDQZfhkyG
ZIYihnzwyHwaQwmDAkMIQyVDAZCXDhRPBLIyGCoXqjWo4KxeSyoL8tOLEgsyKhXQijeWJkaGZuvA
1tM6e+cf7H69wGmRzx3tN9eVtjWYBO5fE7F12ZS1Fq7zfapkHjxflfLLXDQx7V92f0bACr+ijbxT
XpR+7fec9+X5+ojYJ5cEtorobrK/8uIXw8TXZQ8ccq0jt6RGhHbOsuQQadPxONlk9vvRbpEDufWM
3I5qm34GOCyxsQ6UrlgQXxvzzrVy1YUPgnV8CW9nt3u0tOn4sUUfCTB7Hf59hZvC5k9bSuvZn2o4
/NDNazvssGxlWENj7K35Sxg1PkpeuTwtfN7msgSDh2H1EdIdLgwXNuuqbC0KXiLTUvMzV+sJM7NA
1wylZXeFj+8/NcOv+/o0kY+Cb//y+ifz7dC6c+mxCPP81+Uhb5YvbGKSN2hikkbEEZthExMPUIiD
7kkUvUZC6WCwQ5PoglgDCeSUyI2YBWIE2gmXYTXkB1a1FoYGRsCK1sjSBFi3oifEvs87HSfJxF6u
/3j31DP9Wc9MVed8RiuzQEnkQlYmf8alF8fVI4pDnhq5+d89Om2nmobRzKYLW0v2lfiH6dxY/Mz8
1+Of7a/jSg9cupq8M8tdyfFMzxL2L4t6g90PlstMU8nVY1TkO/XmVrZ76M/3U2/dO1Jr8WlHEDfX
JyN2o/rP6skJzRV3//yctl37iiNTlabm1jPyZeIqnTOkuld2RD1YpnfFwcHtn/oFgXCB1sWbOEs6
g3rMHsk9ZPr84nymg9hZpbANqyRWneCXepVWKNHm0n3kken2dBYtx/B57gtWhDSxzb8z4+TS6vI3
qYr/vA5+Ebc1Wetns2fzjieRQd9StUQjGVyer1YOKJVSjtzKY/PuRcnPx8ucKloX6by+syeo68m1
DbwMAGyybLkNCmVuZHN0cmVhbQ0KZW5kb2JqDQoyODMgMCBvYmoNClsgMjIwIDAgMCAwIDAgMCAw
IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA2NTIg
MCA1NzMgNzA1IDAgNTUxIDAgNzIyIDAgMCAwIDAgODQ2IDAgMCA2MTQgMCA2NjIgNTEzIDAgMCAw
IDAgMCAwIDAgMCAwIDAgMCAwIDAgNTM1IDAgNDY5IDU5NyA1MzEgMzI2IDUyMCA1OTcgMzE0IDAg
MCAwIDAgNjA0IDU2OSAwIDAgNDYxIDQ1OSAzNjUgNTk3IDAgNzk4XSANCmVuZG9iag0KMjg0IDAg
b2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDk5NDM2L0xlbmd0aDEgMjA5OTI0Pj4N
CnN0cmVhbQ0KeJzsfAl8W8W198y92iVLV7tsybbka8mLbMu2vMexb2R5i7PYjpNaMSFyrAQnhKwk
TUiTGGLHiZM+SCDBgTyW9jXpozy4aYGG/loIvDTQ98j7oCyFLjRQSqHA1wAlpYRI35mR5Nhmbfv9
+vq9TzOe/517ZubMzJkzZ85cx0EYIWQGkKDO4IL2Vr//RCNiHfsRsm5pDgR7HhrU/xahGzsRUq1u
Dsxpuv+/3oayffnQIL812NzCvWlfjVhrBULSRa2d8xds/jdGhdCRHyJGfWXrgoWBwldvCyHmWw6E
NljmL/CVdz96sh0h/CL0Gh64pn+dzmboQojPRYg5NrD5WufihoVPI1RTD+/zVqy76pqXsxZuRsj9
FEKanqv6N65DJsRD/zZoz121euuKh3DwPoTqYExZwcHl/ZFXV8/aAfyvgPKqQSAov6/Swfst8J47
eM21W7btVDwLvGsQcr599fINa4pD5VsQ2gjzY25YvXagf7Z71iyEemEMGTuu6d+yTr9P8zy0Pwnt
nWv6r1muzPx1OUKbngOhudat3Xht7DZ0FKGxD0n5ug3L1/24Xgrty50IyRyIyFb6wb834Is9S3X1
HyC1ApHw8OvjM8nziZbB4T9lXzqquqgIQ10lYlA8QDv5bdFahNQqKL9ZdZFymhTYGkJJa0CdsG4k
MIhDPrQCSn6q6YlXkTzF/BBJkUJ6m9QP70fjT/wntAJHGR0jUbBSiYxlJOcQExOQZGmS99wFTieC
8aO7ZLXRWtwvvw0/4UT4Tsr0nHQhmSlipUH0CB3qv8eTtDpGZIAkh9FV0m+iMM2vjD+lZ+LPyUH2
Y7QkmZe8majXgcISO+qZXjcV/rGDpA3Vkyd7CvVJnoA1bER9zFHUIClAuZIzqI4ZRu2faPMcapf8
E+pLvrMnUDt7L+pi3kZu4CEQmmwA2f9uk0iFVEiFVPgfEpj70Pf+u8eQCqmQCqnw/1Jg+9H2/+4x
pEIqpEIqpEIqpEIqpEIqpEIqpEIqpEIqpEIqpMLfNTCJf4FhQizJMQjJ8NuU8u70f5sB72ziX3Kw
X8A13pLFb7BVf9PoyL8BkSE5oBKSeoLOUTRCMiPL57TfBWkE7UajaA/ai8bQvomSm9AB+rwFHUKH
0a2QO/I3jfTvFb5I8n9ZkKBjgLnICTkiayVKQzloFgqiFtSG5qJOtAD1o5VoLdqEvoruisVoK1LL
CbWaJmp1Q60BtAZtSNTCsY9iFxCK/fvkCJwTMTYwoVtZnz/buAYJi5dHll655Iq+xaHehT3dc+d0
zG5va20JNgVmCY0NM+tn1NXWVFdVVvjLy0p9JcVF3sKC/DyPO5fPcTmzszId9ox0m9ViNhkNek6n
TdOoVUqFXCaVsAxGRdgm2pp6m1eJ6U1hUcMHec4pauadn+sTkcHu4vVOvy9UnKglSr0iMnaIps7e
E0ioCYky7/Qq80TWzb3ngsZz7c5mUeKGH352f0TM7+518dwL9onyELQRM5p6XS67yLjhpx2K4Gd2
vzMicp1Ad9njlHYRdfaSdDL2ag0QUY0rBNjdK2YlX0OhTxvkw7AGp6YNcx4e405o0puCIjKdQJpX
RWQm1c7XIBHVi/leGAgHOcoN+URsek/ERhGb58KQp3ZBmp2r+RQZNEdW8c2RlSDRSPiyTM/HJepy
jjnHunv1fsjSQXeIT3b1nlCrmvim5SogIEpAJ1RqoKgJAVisO4E1DZhmGE1z3QkGKdJAfAYy3GaS
VonCvjBk+CDIDUqMl0tOxk7tn1yEoFkyZ4zn4oMQZU2iPD4I50pR6BfRPueJolNj+09yaFnYq4nw
kf4rekW2HyqcQKy7ebBHdHR0LgYSdAUpPOgkyx2kQBbP2TzoHIN3UjcMyAfJok+hRwaXh4ma4DAf
hDJlU++o65RdNMCzWdR7xTSolnbda3Z2rNm20klex8ZGneJdMNxJpS6CoAQ2GPpYMw+9AbPmVQGy
JL6JZaPa2B6hiyPs63eKQ8tWxXWvf39S/11jnKi54ILVgfWBlrRhQpSR8Coy5FX9ZJrNq5xj+5bT
qe6nUwN9dTavCpJEGoL2o4XQenFv8yDffLlDmDhkWPf0ti6XmO4lDcfGmskQ+yMw+viQoeDy+Mme
sHsxjKdJFHroA/XQNYAehf5gKEFKVFhMmpGScDAUcsXXHaqKcveotIR3jhGOcrdo8nKu01B2qrio
o7u3OWinsxeZpt6Z79js70C+o3OCjG1QZ8z3jj0uo44FfEdXXAsGkxDuiW9gZmLloWqiPuV61mY/
G89f0dvCt4THxlp4Z8tYeKz/ZGxoGe/k+LETGs3Yuuawk25/DPQf7LOLLftDIhcexHV0hQg7J9G9
lu4O0djVR5aqxTnYHzccjbyrxu7ST9Tp/KzixJ4D7Yc9QPbcGPc2jE0D1snubCGm5iRYCLvI1ZAt
CwNa2At7YoDqLwXYKwuAuZ3sGjbkbl65ICEs0MyE8hAb2JWgAhOXi+ynfScFtAxexKGu3vi7Ey2z
fxcJPi+sY5iUnEqWmBeSkqFkyUTzMA/rZutY8AX6PVm3x/S8wVnro/KnpjcinuqBOX5YIypqEktv
bOpl7Uwix9hZklN5wZTVi1YvbUhkAhZzjOOdT/Mi5xWlTb2n7PUhJ6cHU4ehTpuX7CCwqE/zP8HE
jiITJ+J6EVsIHYFdpeadtdZA4YQiOZvHwglNmzytxGEQGfz0uUEdjofp2eP19QaezPApat4SVtvd
QvaV3RWvMTskaoltFrVvU4Dx2pt6nWCJYOd20Yyz2TlIFlt0hoPUJITsk8knY+fCQWICYcikij2h
4oBx0U7VteKiL6voQ6Do1+8PDdYBF6EQZuCshG7pbunpTUipxp7YUaSvdjKVqeUTUkzWgcWHjecS
SzN+YgNFzbC9E/o0kXf0THmb1Bktq5mwDD29Yos3yTz+3uq1T35tm1bcniwG87Hdfh05RhgUOMHj
PV0nBLxnweLehzmEnHt6er/LYKYpHAidyIWy3oed4ARRKkOohEhenOQFdWDg9l1GQevbHxYQGqKl
Ekqg7wMnMaI0RZKG0cBJJk7jkjQGaJI4TaC0uFfRbBsEEfTysOgRUejs/VpocCwcIsJGlrgCgmbz
DUhk+IYTmJFpRBW/PCCq+QChNxJ6Y5wuI3Q5HwD1h83hJFt9LMzD9gcD3IvsOERUmKgL43aejMXA
gp4Fy+sSZe4rIIGBVXpDTtDi2VCvlaQwkFvFoYF+Mg6ipiyx5e0DIVExwRCqtItK4KBMcIAaLbQN
OQWg0QAoaz9Ps0CGzTEUEkNe0mnvSsLA6QR/qI2vE2WeOE+ph3TkC40Z+HJ6nMjcoso9Sh5KGBsx
hJRih1foLBQXklwDIx/goWgg7ARpS9DAAlBGiYf8qOxxynI41SWe5TSp7IlCFN9B6jSVqCwhZ5Wc
5tUlwBB+5KFQfPD0bTRRAfrmRDWMyDNJlIkGIB0oaidjgZ9RGCqp+hhh03USdfNbYA+SQVNOcigW
09zt/WBw4u3VQOFrko2Bl4KSCI/TcaqczFxDHdqek7Hj/FbXpFBcxMPp3EsUE9nBhxRQaGw6QewD
w6mYTk2j5LExRdqnN4jLS5E28SREZ/NK0FXkhDMFxCjztPfvqzFUFD+MnDjrAaUNz3aexJnJjCOZ
sSYzlmTGkMzokxldMpOWzKiSGWUyo0hmZMmMNJmRCG/S3EWKH1H8PcXXKP6G4isUX6b4IsVnKZ6l
+BTFn1B8kuIZiqcpPk7xFMUfUTxB8X6K+ynuozhGcS/F3RRHKA5T3EXxBorXUxyiuJPiDorbKXZR
7KTYTrGNoG+WD3tQI6T5kJZCWgtpJ6QbId0J6X5Ij0L6X5DUKBvnIh+kRkjzIS2FtBbSTkg3QroT
0v2QHoWkhoXkhS341+csVsdzzwNs+5rFvu1r6c/8FPKbvwpwzTqA1WsBrl5jsV+9ZueGjGs3mcyO
q1YBrFgJsHzQZF8+OLI+I32j5bqmdNdWSPInrE8wv3sDe6/9HrY+gvNeCD+y7pGhRyRHbmO8wm14
6c34wEHGCz6AwL1lz6xVDtgGnhhgnQNpulpCLGrNdtdy9yzfUXvHOJ9tu9VTWHvrOPa2jePDhxgv
d6hRqH3pEFaLdnFYZGelYTmWgjp7sSzxlCSeUqF9DHn3QdoLaWxE5r1+J/Zu3yH17hjOyd4zgr2j
kIZHpN5dkOzVZluV2VxpNlSYdX6zptysLDPLSs2sz4xKzCexUxhqanB58rT5eTpdIc7/MOb98M+6
C3/S/vEDbemF0g+Z8x/iQq+2yKvL4bW5vC4rW+vM1uk4vUapUmtkcoWGlUg1CDMaGRvJVus6dIwa
zUBBdoXyWnZU+R10TPkLnVKN1KxaNwPNUIbYPuVm9lrd7eh25RHdw8qfI+3D2IVzBIPOjjPTbPKM
NDNnTTNITGnZs7TYRT4MAHKQfJAaId0J6VHsEjyyovrC+vx6T31ufU69sz6r3l5vqzfXG+p19cp6
WT1bj+o7/T1YNHSgjp6AaMTwXBAQ/d6Ok6yzWyz3dojKzr7eExj/UwioIrMHjsUeUbIHTsIeuHAt
7us9idNJ8QhYFYyR2BEe+XrI680UI8QNG8oMieUkc1NmCBzm8i7Rzge808PGaxOPTVOo4h+bxQ+b
V/aLH8KN7QJchz5sDosX+ODGeGlhs1jU3C/mA9HDB6cwxNP4I+gg3gd5bNwIXW0kOdEmNsJ8p4/n
hJJMvLM7QG4aHWIE7gn2zr6wmMEHwOmHt6rOPvAfAxs3bjyBwEs5wRCQAfT19c7KxFkogjMhOSBZ
IVkgGSDpIekgpUFSQVJCUkCSQZJCkghzIxcjH0V+H3kt8pvIK5GXIy9Gno2cjTwV+UnkyciZyOnI
45FTkR9FTkTuj+yP7IuMRfZGdkdGIsORXZEbItdHhiI7Izsi2yNdkc5Ie6Qt8glBf5kQ+qtaSceQ
FiHpQsQhL0UkKU98cyQfpc7F87HzsX8mGM8jFO2O56cG2XbEsTNj5xloFbsLaui/xHc5pEgk+kdw
29HL6ElKvgUNoUF4jqN9aCYKo/Wfy+SDL9PT1IAbcBUuBqv6TbQXl8JGtaH9CXo5zkf3TVTcgTah
p9Ed6Cg6gDaiQdi176Fz6AYoWYbWTNQi4wtARGgxUkz0ocUl6I8IMd2fMoDn0FNQwwDlT6Mr0RY0
Dx2Gvn6JXoWyMPo99HF5rEUTOAbjuAueX4f0EC1cBu+7KU1EEegdoXvQBjR7ameyR5CCuRbW53pY
l3PoBSBtQgtRw0QPdbgQ9P/bIPfXYGSHGQn6Jf4InYI+zmMtUB6CGZ/DL6PFrAxGeRidR5th3L+M
vhj9Vey8pB1M+XF5ByLL+AjAbmkPykdFqBRVoHzBjIZ16btt9kNm7tYczbjUbJE6cnSosbGRe517
jXsN+97xvVZWiisrGpjqBraywsPnaBk5X1lV5S/PYswmeNGyZrPVzFdivUtPElMtsxTmWj123awG
Z2luujJcv7epZaDBocutL3J6zHLDTfjjSzK2/+Ma/DuLxV1YmZfu89fyHd2m3PKsG7JKMv0tBZ6G
mS3FrqK8fIdszd13R1+T3HZxheRPH90Lo2fI30JKc6RXoCzkQsfBq29a2Cv4nQjuhtlY6pJyOpfL
brHwUqVLqcvGbPZBuGpgO4uxUsfKzTZWZVUqVceCSmTzefXIr7f6bY2GWt/SK5dkvOPVG1BtKbb5
yvW1MCq938+NnjpFUpldyP6rGYawSy6TmU1Ws6sSRAlKncWQfFUVyDTP7WLZvOhCl9YwGF3orinJ
wHdjNZ5tySr1XnqxolzLRcN48C58fGl+R+EyeSAgKZrTKvnKxbs6GvOUgYCspDB7Tt3PGPIHqOgq
WPNZ0uUgmx/GJUO/qwqVWnMbaHsnE2ZYJcs4HFJWelBwSPQcFOh1OqxldSYTHJgHTUYG6wSOcyq2
20AMr8A8Ms4+dxY1vuNFNu40zKnW25gx6aWs1B7vo+hL9yGYjMg2hck0jiGs5z2ga4yeM/jLq6qq
/XqZjM/JZSorDLn+cotk1h7bYM8d37jlxvYrqk171zy07Onon7ffjLOeWP4v0qroy+uvjj4TfSH6
VvQ3ZctC0WcybIex742X8Kz7LOTXS2HQn3qwqQ5UjLYm9MflKGaLDzoEh/1Y0MHqMtnMgzpBxx0L
6mTb8/J8mTvMCWG8gnxelGHjyHgbEzkQgZD+mQyIVnyyRQiXZ7FmkwzUQi7jQSvYSn1FCZNXiS3+
8uoqEkE1QAZyZvD4ufuurmhvn/Wjbavujta5vWaZ1Oz14LsN7Ws6avJmuXJXPHx9g126sGLd7Wev
P/ph7/wVZkNAZS1oLGWv9An56arAxVzWaStsXrPl3x65+FXy+zaQgSQPZAC+XkIC3YjneCcv8hI+
S+fJ9vg8j3okStbj8WZ52ayDArggCmTrtIVt62xAt5nNZI5mwWw6FjSzMqVCeSyo4D1uN7IJVmtx
FtqhJSIrpwoEcLYc0d0xIYPEeutJBfp2huwY7swSIs7g/43RJPbjl+kx5DZlsXR3JtfBpedLGJ7X
J/SPvjBYxlkL+EuvJ9eAfWKvq0SY+9iQz+9Sr1+vySkvGbpYWZ1j1ksDAaWtQChll8RXIPr40qa8
KJsZbIjOaWx2oPgaSJfDGtSguxNrUFqYxqYdEAp5S+GB0lKTXMJaLdZjQZnF4C71szllPJ9zLMiz
aIdXra4r1O5wJCXsfwU1TpgeP+SsfpgfmSURpudLsrV9Jg8Qj8USN16VYOM/ISuzljEDHRSWvrBm
ycW0/MpLF+pytNF6icaan3np/aTMmLTKPA6fTsurYlRF+Xrpxbm1nrRAQJdVvRAfiK7l6z0ZRjBy
U/Q3oMudMTf6XTxvzgy3LhDQ2AsrqkCCS+D8jFAJfichwYoqu6A0tdntFfnIX51lZisq/MeCFaxS
42EL1Pn5BceC+faMqqqcarN0p15fV5mdc30JlSIR4yt+v4HYfHTZjlM56P2gM6BMfiJN/kt0Mfkk
mM4hhImwkvIkIqyq5sEKYB578njL1CIqUIxdskilR6dx116KFeUYlTLWrLG7o38Uo6+nGw0qbWFF
dLfba5GmeWrwu9iMi/DzUqOOn9Hx8Z0zW6nADJkzgvj3Xb8syZ87cKmE9TYHv/VKtGJ2HZG8ypbf
UMr2z6nJ5QIf/ydbmbCRkjtAslmoEN2YkG2ew8k6waI7THJTIVt40AR2/FjQxEoVcsWxoNy2Ize3
KBvtSEsq5SvTNjw5CSd0MuvzmU3fupPakq3KTFW/cgtYUjgg8irJbk3aTayyeosv71Wm+dLHm899
u79hUWRzbe2aRS2ejwLVLotimqo9+MOR08sl62u/tnJwWwWTPC/mgSzKwN/9cUIW1faMIr+/iPWD
L1AEvkBRkRZry9nyg1pBm3YsqGXLcphcjJljQWzPKK7dYcnlG/3FO+RUNtzz5c/BWVKbUDP/9Gle
dhxqiagKv3xfSb37fJYh11ThWYkrBxpoBsWzUuXz5OVR40dUkQUTCNue+H7MNZO2cevmbzVUtOU1
b1o2uz+vsXBBbXRnXfs8vryyuk6bX7V6oHNwpnVox6Kp0nXlOBau71i2f0mBynl1956+PlWg847v
zBFs0Uc66nO1kqOXnvPOHWzYswd2d0/sPPss+DJl6KW41B9Qu93FVvJhox5cCitK70wPp4OvkW4y
EesvmCSlxNco1ZWBr1FWXMyy7MFiY7rNVuAa4rjSgiG53I8E4t3RE4ke5+DmfY5zQ6wBLMHljou+
dMdC8ec6OXHOIaPFklTZvBJwsIljbbHS0yaHOIyW5OLwOZ48/a/SN62fcWVtyYq+eTtCZdf9bjz0
jcG9xhm9TbWLK4pXLd/29aYNP79xxa/6cddXN+WHmhr6ukvyepZv6dh2b8hoi748f0lR/vyauoVd
FcK2A+FtD/ZbLbiCaHg9eI0cex5uBn50PqHhc9UFbMEdgqDuVDPr1FitlujM2eadZlbFmu12juXG
BTuX7zkOxg77WR/ycT7GJJH4WN9hiQVhdb7EOez3VypMgrloREH0/rmMs+TofcXqpwInJzHYR593
ipigwpL1CRsx868fggBjiLP9om5C7jwqXU9lRa47bjpgK/CwQWAliDWmZx1LF4MuFfMtXfftX1m0
cxZ48Z7CQElJU1Xaj6647qtX+rYeaJOlmTLzo/tttx8K1pd0l+6SdrY1rmu/+V8tS5csL3CG5j9U
UJSpEW7aGb0u0Mab01QB/KJk9WDDrLLuEtD4PtD4f4Z1yEIbEquQxamH1EbWOC6oOSSROFjHIYmF
E3RwAXHadskTTqn/hYwJJaaThJ3/FJGg+ZPNL0tmauUQtlI5JHXQTD1wOKpMVEXZzrnLvr/6pde2
//7WrrsDZ3T1Ne4mf1bRss66q+AcDi+Ivf8vf9hmNb175SJ335FNm+7+SjmxnKBXY9Jx5EQ+9L3E
jCqzMo8Hs5ATm3LZ3HHBxMkUrOIemUx6PCiTKVU+1pvmZb2HhDSLQmll0bDPV5a/i0t630R3iCFD
ZEnJmnK/nVjYxkaqNQVfuoN4w8/mFcL0pJHy1XlTRFNJDafbjys8iV1KFUPikBryfdHzW5W6tjvb
H3pwzUtHihbWyYyecmzeHv1198KGUPGiPu/COpw7p6XQrmpS3oTb53908Z43t6i5vqtDvgxVk/YS
um5z6Nsbf/y4N1QHEiQa8WfQiHSQ4aMJCdY5jaxzXFhnxDpjtnG+calRYmGNRhWrAmM0Lqg4lI7V
bDrLWljLIYG1pCPDcEZGjtM4LEseze+eKUeTdkNjxqRzYkli9/n+wm6m7K9P4RhyTxaixUqii+pW
NUt3nZz99Yonb3jzra0v39y3d5nTYzThS7vxzhvmXNf6I0lb59w+5UOrF8cufuOtrYUdlY1dCzY/
+J3aNtxx5PDRm2HvNCDEeqRHkRsdS8ip3CgoNW1G3ZAORjgu6HCW/HhQmtUq2HU8VDsedGdmZhsF
Q7Y9W6bJHpZI8jx6A4Yhv+I/o/dzL9BDIunDZLxTnlQO2C9nqYRcX9jBhBvzyeahauJLEztTTQSS
2G+gTWa/mU/4gD0+N3edz23TstxbP1vUtEdf4PKW6B97jCuoiGoD2pyZc5jBZrk+syT3gYe1T1VX
1K5cOmf7pfGOhlxNgPw7vdyoIMkE7YFNg+ZjV0IuIcE5L0+l8Cmq2epxgVUofBxG5eVQv1Uo1/lm
sjPHBR/HzWN187Ln+eaxVnaeoDW0zRM4WwvbMm5ztJukTZkaXsjkCzFTzhYi6UhdXVfFcGFil757
xmCt5U6fzuDOQkx+PIBD1wvKcHmLJVSEOsa1Se8EXBci2ll/2xgFmyPZzV/QbQjnyS3ElQRPkp69
fn/SsywBB6iq2kO1lz4aGGIJXJjufeocySbOCHqK8DmSzO9IHO5nzw40lqfXV394/NjWV29ff/KG
1rZZhZ68WRXzOps23XmFf54br7y0pHVOc3tr++zW3Fz39tEdu2wtwr3t7GKj2tEfvO8BQ3FFllN/
w96rb+syVV7RWhvOyZpX6+tuyi+6MbxkpCdPJYs+umPbhk3brt/48T2OgLetuWdOTqmT3DHrwI8f
BQs8A40lVj8/T69lCwsKjwe5AvOMLDsLEbYvV1N9PFiD6rBi2GyeOcM5XHrZjQdjmDSV/om7IVml
zM/lRT93fEq7EI5bAPPEPZKhvijVfqBJKE1CaCwxs3r8dN+NHWu2VLMas8cetfv4tLTssnzPgmpW
pjbkOKKWrByjVsKqTJ5CsLTsFV1NXeNbozcXzS3JNMFNUl04eymWRtbOzPJ1lUS/VjPTlWExAF1u
TM9rFljNoq5ql0kR0F76MfGF2gFmSteCptnRAwmZ1bIMyw4IOmY+w8QYrGMeZX4NGYkSMRzDcCyj
v0en0x4P6nTpErvkeNCODYxhWKHIdCQMymnu9OXLEJwzxCpeuWT9hoSpLf1L+U+6Hk3nFsIgPTYh
Uiq+uETxM9H/varMnaZM9+Zg4/aE6GzStR988NGzaYVtS/EzZfW5RnlQcak2KSKiQSAPySGwIbXo
UEIaXitTy2akZxwP4nRz3j1udy5YOl2+XlusZbWHhGLOPyyTzcjKzzMOZxElondfokYTmkBHPUmP
nF/EcbIaTW1M7zJ0spKE/lz+UJEQgNxKNmsWE9c3yaGovSQ3TZZmdeQ6PN01GrcvmlnqTpMa80qx
YYdO03DlVbXdq5syqbYF1N72pVjd2leXl67xLfBFdy6d7VUHAlRgt89u9dpVQcVNbHWj27f4hkXR
g3GdQ/GTW+IHuenAm/tKQnI2RH0xZFHCRhkXlJxml83m5HZJJj4uXrZRRC7c9PqTjRjMXZozYYqI
maLGKHFVk8mYGTc/v2X28Pevfu/Cda9GH1garmz1GpYuCXZ7uKt+c//u00MzYxfue2sDo3vu2aoV
N4Z+9vyiexPrzZL19qBTiVHX6LEaKTgFo2QVEoFRG9Q5alYvkahZNXiTnOee3Fz+eDBXZ0m3pR8P
2hSCXJ7vAZ8jc+K7Cnink/U16ZeTk5C453GTX/KXdTN1C3waS/Bo6cka/5asZT9NN/B/prXftnhm
04P66hJLZbFRpi0sjxovqwPbxS6akxZ9u67BXuavqIg+tnSOVzlt+YnUusBPWwxS86Fnk9/d+dgb
31dybSqeN/InY28IZfEX1moUjOCIjxs55AMHylckFMF9cbzIYrNa87JHdLqSvBGZrAwJJZ9+UU1M
MZklF0mvngD9Ej+9V9fn9yoUWSa5JZ/BNnFLnXZJNccvqRN3VC1DPsD8zDb4lY65fNey6v62wsHH
vta+f+2wtTpQEpjnaLvqys0N9atv7fvWf2BtX19wVkFdpddW1764evFwi8b0ptBir6/yVPm9eQvX
zu7aNMft+wNI1g2SZSQ/Rw50S0Ifi4zK40G5UafDGlZnbBU4nUPQcG0Oh42FSFxRgwGZOJNWYYp7
vGf84M6dBl+uMfnZl9zF43qScOS+iOOEczutbdKpjTtyfrPL7NLHL0zg1TK9N3Ueunn7THDYpX/A
mdHfmMvdjqIy+5aOmXd/k/E1q/KbVnd9tD06c/1qvyrDRvRIIDcm9hwqRvuSX930xQaEio8HkY5V
+Bz3ZKgzs1i5S87KDwkuS6bDNKxW+5hhd9KE+CffkH4Lljf+UTd+Xn8ur8nXoSkNQ0byyZehl5zk
x/GpNyMPNcB5Ah7R5JR53N21Mn1uAd6dvA9plhycvWpnDZw5RpeDPXfp+fDqxsySBT58Q3trvl0T
uBRMXojYRcH5R7biNTX1LjucQCARe+yCbBlIxI12Jddf7chmFcZMLNWm83KlUnE8qNQhg5ll3chs
MmKWMWB4U6Rn52nJhwc/d6ZcbyUuXvwH+az+xFfZ+PGT/pkMwchMqRuSsizPxj95U2/PajT6jcb4
r/Hol285Zt/84S/+431LlseJ3/T5ONX213/w+C6TrrQIb81yZbr56PsqZuTSNubPLY08eCGKAnf6
zJxoP3P/pS68smq2o7BaHmhS2go7Q5fmwjnyPThMpNKF4I/IUYagYVlGLsqQlJXeLwPN5s4g36Uz
jWWlGMZFf/0q7fv2fFwYfV+68OOV7K0XX4r+FJeQ82g7KzIXwBMkfGyCSiZnTrFYIkes71cvgGHJ
OEv+coVwkRJOu+cfKGC2zjuYLx2PpuPfYQLk19GRRHwPvYeHGRnEJ5kn2ZXJKLHQeFRyVNorS/sf
G5+RPSOvlf9csVbxZ+VHqpvV9on4fY2RxvvS+tJ+qu2D+ItUTMV/2BhLxVT8x4y6nFRMxVRMxVRM
xVRMxVRMxVRMxVRMxVRMxVRMxVT8/yXG/xwSIWYH4CAeQjJ0HkmQLPY8oCX2JuBI7HXA3RRHKR6g
eDj2HOCttOaR2L8iCVsVC0B7WexVQEvsfcCR2HuAuymOUjxA8dbYu4BHYm8gOZLEHkByaPsqUkK+
G1AWexFwV+wY4EjsKOBuiqMU98TeBtwb+wHgTbTmAUq/heYPxR4EvJVyOwK9GIFnE6AM+jUCz/8C
HImdBdxNcZTi3tg5wAM0fwhmbYb6PyX/ByH0ZYb6vwDcTXGU4gGKh2jpYWhrhh5fBDwCkjHDXH6C
LNDvK4C7kA5whOJuiqMUD1AkEtgF+DjaBa1OQ70RkNsI9EVwlOIBwN1Q51loeQR6HKU19+A30D1o
D1sFuBfm9Qfy/yDCHMcotzFaZx9tdROl3EQpByD/PDpA87dAq18BjoCsboEeCY5S3At8bgFuFwAP
AOUQtLqADkPN1wB3UxyluBckfBjqvIZupX0dAZ4/BxwBOR+BmgRHKZKaR4Dn24AHKOVQ7Lcwekn0
DaqDPqYu8ce5acz4xB/yatFq+hb/3xEjrCSRx0jLDibyDFKoknVYVKfakMhLkE21J5GXQv7eRF4G
+dOJvBx9pPplIq9AheruRF6JWv4PcecCH1V1Lfx9ksyZZGYSQGkMSnGKXIwWAkVLI6bgE5WijQi2
Wh8zZCbJDJOZYWbyQgzDw4iIjyLFqIhoLVXr7c21PtpcbptirnIpja0CpYg04iNWMQS0IVjKuf+9
z5nJBNLvo/d+9/fN7n/OPmc/1t5r7b3WPqkkzl1W3mF3pGU5xY2u0VbeJYpdKVmpMWenx5z6PYhT
XI9aeU3YXdutfJbIGe5L/TZN8eXh11v5HOEafouVt5EPW3md/CIrbxd3Dm+28rniS8N/beXzxDkj
sq28I/uutCyn+OqI8VbeJUaOSMnK12aP8Fv5AjH1tH+Vvyk0J8/Ss5k39WzmTT2beVPPZt7Us5k3
9WzmTT2beVPPZt7Us5k39WzmTT2beVPPZt7Us5nPt1aDzJt6vkn9Dku3qBFe0ci1VsSFn2tCVIsA
ebeopEaYezc15H2U8hj1AzxLkPfxbL5qK9vItleKeWK2uNRqG8soiXIXoUWtqFA9BujZLeqVrAq+
h5Zr3su6FSJEW58lNUENNzlZHqXEnIGXej5LVsDqocLqy6++S3hy4rxleUjliml1Hlc/ZfPTkoYa
Vfiknk9dRwO9+1RPVTyLcR+nRkxpI6F+v2j478zdlH7yuC7O0ICciTmXhJIXVdbwqv7Nufp4Uq9m
HuH535upqWfvIJ36lV0j1rc5KzNfy11UfbvVaOvUbPzpfmTNEDX+zxaqVpqLimliEqlepRKl0Qq1
huJQqWrKljXUSTAjOcMqNccoPTSqv5Bs9hsnL0dTSVkt8mVLr1o3DeJZ5E8Rk0kXkbv2JBlucbma
aUp/KcuUqN/2GiK5xRyeValRx9WdX+2jGLOX9iqhB6+yuJyxV2nBXClyDfiVLX2qjewlbNm4Mq3f
sJhIWYVaIWZtmfNmrJ2UzU0dS3tGxAJyVSrns3aZ2TbTij7VVs4xrvaCORs5jkVqPHKO16jy1Ijr
1Lwa1Rqus3qUepS/6fbE0Zj73dTbwHqWfV6h9FClnniVzFQbs/+EsoJZUq1+126MfEDpJp5R29Ry
AF2ZT2NqpcXUGjMtVafyjapuQo1HjnFC2u+EVItqNUY5a3O9eC09DNV7pqZS4wikV++AFcw9Z+rN
1OfAGBZYXiCctmFcjdubsZcSqm3YapWSFLH2llmvRo0xpGZpanZuegen7CztErXmaZbUqNUtewmr
3WvuUC+rMVUrLAZ8VcDSh6wVT6+kWDpO+K0VV6+eVqj5+tWerlY68ypvJssGa7EWeTIWZHq0uNrH
oQx/MV/lvRlzDijtzLe8Zcrn+lWrGsuDxJWmKtVopWV97KCAsltVWlPfSe+IE3enqSUzFmbuxArl
WTI9c2rvpPaLlFpn2U/6FLda/ebqmJChr4EVE2NkJ2vq5D0VV2tU+i5fWitxZRXT75hrPKZGXKvs
mTnyAW2ZUcb0gQMrxn+CBzJ1EBbnqjZBpYuEGLzOT5RQq1qbOzRuRZcKng7YZFqGNDmOKjUOr2pf
ryxrzmUo/+jHUw+WXK9WZrUVm8x+qiy9+FUv5gqosXZVpteQevWrvWHWb1T2j9DLYJ1cZfncBRmt
L6e2GUPNPXFq3rzWGrm5jkJqB6b2QdSKFQHVJqJ6MMfutWyRWivhjPhj+qiE2rk16RZST1HLh8bT
fs6M4AFliwEPldKTGZECysYR6/xh9i5HXz/IA3nVbkrt1xprJQXSESqgdojbiscnrquSIeLrtCF2
4GXKFj5VZsbmqeJGy4ekNPR1eruI54PbTky3HXpX+61VY1rCm16J5uz91g5yKz/tVWOvUXNeIFLn
He/fLZX6P/Xzw4l+dh53gXRUvkFpPDEo3k0a4sRVobxC2Do3mr7tWtV/JMMG11i+78QIPVd504jK
mXVNf7lA+Zv/N2cw6dMGzmFD9zpQbvX2rHvK5MkXua8NVMQi8Uhlwn15JBaNxLyJQCRc4r40FHLP
CVRVJ+LuOf64P1bn95Vc7q2ZHwt43dXeuHu+3x92+/zxQFXY73NXRmLuSHhivCImH8f8Xl8gXOX2
hn3uRMQdikQWuKsiEZ+7vprSaCwQTtDGm3DHa7yIiQcW+eMl7msSquM6f6zR7a+jYjzqrUh1E41F
GJscGjWvCHirImFvSJVQPxGo4KbaG4iFAmF/XD1myIFKsjE/wwkxqTp/qNEdT8Qi4aoJDCQQ8rur
I7HAokg4QeOM6uagZB9ynOYU/DVRxsY4VQ8L/G6eM7S4G3VV+2PuRLWX8SZko0htglt/TdwfqpPT
mlsdiKs5VwSiyOSmJhJPuMMRRu33zpePwrKBO8A4AhVxqSRGIZ+EIvX+WIU37ndXVHtj3oqEP2YN
sXa+r9YvB4jQRrpgiPP9UqM0C8TIIwFd+kP+Gn8YE0Yq3fWRmG9ioMZbJQf1HWmIlDkZUm3cMmKF
N6qUrKwj7eKOoGBWijsaQR0T1LiUYmIT04NKWypeHakN+eRQ4iG5dtB4zO+rrbA6V8OK+eO1oYRS
jN9aQIwgfG7CHayl2NR5qkFtXBo07vZFKmrVTKapZjF/VW3IG3PX+6WUgfXob7Aa1wcS1W6vmzpV
jMWfkAqo8cpncmlUBPzhCp431syPhKyRXMXKXaCKL2+MBUJYYohlXkvn6CgUiUsbRNkVgTjakr1j
f6WVsNo/rKiE31sjC/wN1EvE5ZqLuL2BGr9aUHJMbKRAPMEalKs37K83F5A3puxag5ICckMFoli1
MZrSVUl6v05LG/CySMg3Te7mqTeyQuSAvl5y0VSrdKIszTC1P6BWrFcqEfGsNQYU8/r8Nd7YAndE
lmTcVg7tH1Jrdl44ILfyDQlvwtx3k6QjUAIqIrXhRCzAars2wmKXM7iG1Zfa0HMDsYh7Lk9Zlwvi
1YlEdNqkSfX19SU1KXklFZGaSbSLVMW80erGSRWJSvZqZlV1L6vdFKnFvI1yGTMsJilL5AZA9TWB
hBzi/EY14Cvnzb5ULS15g1Nhcco1Jx1CRXVGW67s2FCtzzSXLxCPhhBguiIMzfTkQk2UuFOyI2FW
e3HgPHzFfNlooKtwqvKQI1LVlbtkZ6CwCnP/paUrTVt9XawGUBxASgKXhDFYqo3sjvpwKOLNFMqY
vZanjbnTNsE3RXFPPn8dvkfWqfaHoidM6FRMoRQ/yeev9LJKS7zxaEPqZ4t8jIfFejHUR/4Vnzzh
EE5hNwwxzPqLPjoFxVyTQqR/Jjn0Jyd7qsulUUd75lTr5+fL+lmn3P+wYar+Kfc/fLisn33K/Y8Y
oeqfcv+nn079HPW3jHJFjqovf8J8pvX3ifLlvw5Cp+ei0wvFcHGpOJ0z3JeI74XE/+XiTnGXWCma
xUPibvEkuefFPaJNrBJbxb1il3hQvC++Lw6KteIL8QPNJtZpw8XD2pfFI1qx9pF2UfZUbSZDvG6w
fG1OhvwC5I9G/vnIL0X+t5FfifwE8pch/0HkP4b8Tch/Efm/Qv5vkf828v9M6RHxfS1LrNXykV+E
/HOQPxn5FyN/NvJvRt78wfKzXsyQPwr5xci/FPnlyA8gf5n8fz+Q/xzyf4H8/0D+75HfhfwDyP+r
WKU5xL3IelCbgvwrkX898m9FfgD59chfhfzHkS//aexLg+XnBP6b8t9F/qfI/xvyXcg/F/lTkX8N
8uch34v8GuTfgfz7kf8k8luR/4vB8vWxGfLPQv5X5c+o5c+jkb8Q+auRvx75ryD/deTvQP67yD8u
VmpOcY82GvkTkT8L+TcjP4L8xci/B/nrkP8j5Lch/w3k/wn5Hw2Wn+vIkH828qcj/1bkL0b+Y8hv
Q/4fkd8vlqPnu7SviGZtkribdbRSuwX5YeTfh/znkf9L5O9E/gHkfyHWZeWKh7OKxCNZk7SPsmZm
T836LvaeL/1Ebi7/KyqaMGFm08yDubrItZf52vn4ynLtlPSHKvmE+lXJMZ+nwePx9Mo2eUcqK5so
OpKbx8jfS8qj8PdUulx0J2Vb+zGKF1vVc9VNiOo2kas3bG3vbShq6dV1oevRlqKG3Yt1G1met2+N
5ulanr20iKd8zILo7n5ZYBN5OaX06JGjyJONF+/eHU32L17Rn2cXefYuj6chxKcnL4eaHo/oUjV1
u9Dt/apASrQ3bOfToIQfSKgKORoyftcVbe2S46NlP4+rJ6uGB2TD6Xqe0B2fJmt4V5iqUm6Wlpsj
NdUu2tuzs7U828aNG/NyRZ7S5oSmmTMPqomY6kSfsizvWGWF/FQeU+M9Pt/jW+yTc8mj7EiyQsi0
RJjXI8k8p8hzdnUtbF/YfjNpNumS9ne7ZNtcS7u0NftV6q08kmdDJnrsipYqBWu6/WQF27W83NEu
12LUsDes22SdIRVMgaXg1f1qaugzVCetfoKCc4Wee0AVnJKCbWkFy4Y9tAt/4yQF52VpeaaCLQ07
pIYdDuFwuISLfSDTOWKGuDR5afK9doddc+RNr9wi62+pnO7I0xzO4/JnAcmBVMFelfVyU4r39Kp6
J2pe6t7h1Bz5g3Vval8Jkvo21S87cBy3mlWyWStJFeKzpENH0OLtHVhi9Ort/Xa7Zs9tWC2V3mS3
aXZpJGkMRy7dFeh602t8Ouvtuqy2ffux9o4Gh004bKXVpjmQlCvsuTMqK8s8TTMuf7XJQcTP6xIe
Ulj9/CI98hyapWzj6bXnCXtez6Aacix5i6XA1xbbdWG3KytR1RwXI27plWvBshOGUp10p7uoEhcn
7S5hdx2Oznd/w/2NSy6+ZFRyVNKRhZHa0zbLsWlOfffuBx/8nxtNKsmo8KaM5tAcrs/azfIl6Zqf
tTtcmqOgKxrtinbd5LnJcx3pCs8lnq5e2YHjuNx6TWmrZxotpIx2aCij5aWMJi2zuIORdjQ4czWn
A6OlrSaNi0KPt29Z7NSF01bms1R3ktmcecLpMM12CoZznKLhZH5xR1fDaDYqhtMHGc5xsuHy/6+G
s0vDOZ3C6ZSGK8Bsp2M4TIfhLm1/r0upYEaFV7XxVsxwOjSnC5ViB097KmG95HEhq0rrpfacqpoy
32ADOl2aM8OAN2eYUAlMm9DsxWkogXKRNGHBKjnH5KF2px2BTa9t6YqWFejNrx3LtWu5eQ3bXWUh
7Chvcssq5bDnl7nyhMth5/gs0wyav2olqSjVrKwSq8qaunDpA2b19LpkFJwh/YC07KuvNqm+hrKs
tJwzh1WRti1BUYbNnhMq5eZquY6yylf5VJrxt6fOqq4zaBZfb5lrdb/0CykLY2LVVXdGR2rs+SK3
4LPSiuEVw7++Uaai9qJ2Z1aWU28fZGeXsnO+S+S77Jw5hgln0pk8KzmifUT7jHZ3l4d0qDc/T8t3
np1cmIwmu0RmivLsbJHv1PLzDRFPLmyXhhtIC9vjSUPI1g5DtY6q/2OnSf1A0Uz9CNbyC472DrRa
ktHD0d78Ai1/eG9ZQ2kDn9DPZaoqlWl+qae0d3G+Q8t3mbLNFE8uOaHz/BOL40l139Xfm5/L0GbE
3+3qbSgbM8x+d+exvDwtzzFddHPCs3MKqyJ3UNQn83K1vLzp9e918Vk4XQp12pPZKs2gt/fSqT55
cbusjBm7uw1V2S7y9TFTo9FjUfPTn+8QeY4Z7XIYMs1guSxJziC4tLe/y/Dynfyv15pCfbKxfWFG
+mtXvo3+olEhelP9qWPCkZMqyqk4p3MuyxidPFTK88KRJXGrLWeBvKYP9/cuHnN/5zGnXTjt0ehx
s+NYmer5s0H9xtu/2ZU3TOQNO7ph4eqF2y/eOm13We/oaJGnyJOfreXrXamPAJuuFeTKw4D5X6Q4
OInuE9kVjbGQGFkV8y8QU0PeRJhTtkNoN8y5zC3/8itvsOZ/n1Ng5TVOyMPMP5ug7rM4Fw+nZvY1
5eVXi7Fzvn2tW5TMnfMtt/ztXKpGNv2NsPLsO3GalbfhyU638vIdb6T40gJ/LCyS6rtZfa9W32vU
d4v63qC+n5Y/thHPqe+98lsrUN/T1XdUfT+lvt+sWVCzICtLfbvUd6H6dqvv89X3hep7evpN9VS+
z+CapWZkU39BN9d652fvoqth6GQEMz1dzgrtnPHfalH4vy7hf39M/2j9bFHE++aZ/6PcWbyl38Ip
YjFvievF82Kz2C728lZ8THNpo7UJWpk2W7tFC2mLtdXaeu15bbO2Xduryf+aMZc+XIxmtNKL0H5u
Xp/xqauW/V31d5LlHtDke+KE2wbfX7h/8H1px+D7suTg+6tfyLi3CW1u4eDyuU8Pvr911uD6gZ7B
5QtWDC5PDB9cnugYXJ6MDS5fetrg8pUFg8tX/nxw+ZqWweXrxg8uf1wMLn985eDyH50w/k2LB5e/
wHiyUvc694+KPC3j/pWPRF52xv0vW4S2cav0TvoY10xX0tXsanFtcL3o+tjVn3+bqyW/AZrzN+dv
yz9WcF3B+oItw0ZS7+S0gdScTi2qlxPTx1ai52Fj82+T/Q+RNiCvWclMpW0yId1MW8w0bKRMrpYR
2wtfLmwv3Fa4o3BP4YEzdnG3o8hVdBr3L6uS9qILi9YVdRR18ryr6ItRRUVdo8arshPTHtK2VBo1
QfV4Qho184xdMqn6O05MyEWylK1aD/TcPkTaw6jWqZFZ6awV7g1fGS3HOUTPX1ipy0yjxst07vnn
Pl/Yfu6HxbnFBcVFxWOLi4unFJcWzyJfDU3FHcWdxbuLPy4+dp5+Xvm5H56caDOWtqlUpHo5MU2x
kux5lur95DQWaU1KYip1ynTebUhXiRGYqVym4qLzJygtHEhpckB3hTsmzpl4C2kOaf4Fx0pLSktL
p09bK5HPyj6cvvnSmZdtTF2vHH9VmmvartmbYlbJrKdn7Z/tmvV0+Y3lnvI3y3tnPT330fI35/nm
Nc9be/O+7628pen2cbLUW1D+5s37bt7nneud7w15m7wbK+ZUfNcX8+3wHeZ9uKByZOXYqsnVc6qr
qxcFNge2eOdWzAnsCOyoFDwjBbYE9gT6g/sCe0LVoXCoI7QrsKcmFOoIF4RHhs+MTI5MjU5WZR3k
J0dXRZ9ZOHbh2oW7FnYt7Im9GJ8Tj8abakVtQa2n9qm6UN2qulU8iS5cW/dM45jG3kWX3dG6sOvO
WfE5d66t9TRNa7qiKda0smlD02bSFtLWpj1Nny+ZteSWJbeo+5VLKpd8npyVjFK+J9mcbEn+NLk3
+XGyN9kHx5ZmLR2+tHCpe+n4pdGli5YuSh4j7V2aXLpv2chl1y0LJXuXLVrqXrad9Oayvcs+Xta/
PGt58fJpy8uXz18eWl63fMXyNcs3Lt+0vGN55/Ku5T3L+1foK0auOHOFe0jPkPIOmWnQjl8xf+hk
7vMhd2pqt2YmuU8G7bAViYEkSzPvzV001I5I74rMNGitr2geOpnre8WD+duKWPmFO/CmLSvWpbya
68UVrfnHXP3Sp65om9ecv21Fx4ovpA8bNV6ufbTUYulK+UjZSpaRT2mwRfniZvpNKi+c1mPBFu6a
8ajb7sqllJK7CvKb1dOkSs2Z/jWdlJeXSfriTH+c30BqHtoPy0igYoGMButTfli1p42rX/pkqf27
tit7HGgew65mfvjhzuZEc9Oo8c0PNm8x56x2fnuGn2s3LSs9LJ6AXpq7ilyjxlv+9uVMO0vfKfPN
fYUvK39uWb2oS37fnXP3mXdvpE7XyoGybRmSUqvmwAp3uve0T5d+yPREKg1edxkrzPLgGT68qNNM
GZ5brrQvZNwxI49MhS9TB19e+LJ7Q+HLK1dyfxoaUSPHlxetfMpaawXFxfe04sFLlUfvXHXaKrfp
P1mjRdZKNT0ztZVfnZJev0UqAjTRX65Z30zn6eQL8OKdxbmy5qoXipvUs1yVCgb5dDOZUaU07f8H
IkA1qWloz68iz27l+4+Z8UeNr1NGAqTJXmTbUhkL5LxXddxbeV9xYft90/mWOm+/7/n7C+8vb+4q
3DGvGa/dbProm/fdXyd/Rnl/K362w/Sokcl4+lNMePYTEtFhUBqixpuD0zyfOZKBdHIbYsk/mMyY
EtiRuqbuUveV4oQ0snKkGX/+fiIy/SNpz6knotng1DE4EfsKTNsMlYayS92qhWuJhVaSdzImmvFQ
xcQ5qVzdKmLoKqJnl4yTKn6qRPwkyZZ1q+5voyVtF3bJiKhipUrEyJVNW81oSX6zebUipxlPZdqj
0kpZm7qzHsglUmYRRc0YqhKRc6+KpCqKqkjam841J5vlDlH1j5mJiCuTbLXogQJa0c6KWTukLyxy
PVD8wJvSLz7Qbz4t3PHgMtO/fN+1pnJNy0NjH1r70K6Hdq0Va3+6tn3ta2t331f8g+Nr2/EdHety
Hn6qqGPU+Ie3PkyNzHNmYXvL1S03m77L8lado8Y/cvUjc5Q321F44JGGgfNyUccjP8VXjX/k/Ue3
PVa+ftbj4vFtGzY+MeWJAxtf4Oyxx9Q0ulF6Wuo258a7aYvxQ7HTKBWfGge0HKNPu9U4pAWNTdqH
xm6t22jNLofrjVbHRlHmeBJeEGXO28UU3kNajAO8gbQY+7XZYqTVrpvnO42DvNO00D6HZwNlh3gX
lrU1o5OSVm0YNb5GfrYo1q4nf6vxS62C+yAjScKH1Ok2dvOmSit63U/Jbt57W4xGa7RdtC3TvmPs
1W6Cm+F7cAvcCkGjgz6ep4/ZOTzL4VnObXA7eMALPvBDpbE3c4a8Y7UYz0q90EsTPWxCD7vRA6NB
bif9fyLHp2bUSb02ZiVHtJ+Sbtrst0Yv23XSrnNQ79lKO1Iz3czMpfrYrzTTQR9r0MzODM1IaeuV
Zj40SmSfvLe38P0pTzSl5Sdo8RYtNit9XM/1VuMVWmyWGkOXfbRM0LJN/5bw2e82bnT8EJ6G12Er
1j+dHjssrf6K3rot+WWW/Fcsy/RZlllOb51/t7c8OT562q1mcCvXIDP4ELqNIK2mqBUkZ9GEzN2W
7jYhdxNyH7Pkrrfm3UrrVloPp/XDg2Ra8pzTjDbn7UbQ0msQa3QbfeI5oRtdwgGnwUgoNA6LM9B1
kbFPjMKWZ8Jo4y1xPmVfhQkwEUpgGlwMZfBNmAc3wnfgu3AT3Azfg1vgVrgNbocK5PjAD5VQBdXI
DUAQFiA/BDUQhghEYSHEIA4JqGV8dVAPDdDIWBfBHbAYpM0eYQU9xrWf61H4Av4Kx3j2NzgOBusK
e2k9aOcgHIbPjN1Z2WADO5zB+v46TIWLodzYz7rdn+My9uXkQwEMg+EwAk6D02Gk8VbOl6AQLjM6
ci6HKyBhdNpmGF22K+AquNrYbbuO67dhLmXz4DvGPtt3jbdsfp5Vkq+CaghAEMI8j8BCiEEdLIVl
cBflzXA/+QfgQfg+rKG/tVzX0f8jlD9O/gmePc21FV6D12Er/Cf8zjhs+z28CW/BDthJ213wB9gN
f6SfPfA27IV3YB/z+RN0wbvwvvGWbjM69GkwC9bAQ7DW2K//ALCVvoHrE1yfNToc3fCRsd95A7aZ
JnKM1cKGP7VDrvz3xuAEFxTAMBgOI+B0+a+AQf5b4TOMNlZzH6u5jdW8U5xlrGBFt4gvG5vFGPo8
G9zwFRgL58A4+CcYD+dCMTvnPJhEf5PZlV/jOgUugAvh6zAVvgGlcBFMhxlwCVwKl8HlcAVcCTPh
KrgaroFvwWy4Fq6Dcrge5sANMBc84IX5UAE+8EMlVEE1cwwA+5sd1McO6mMH9bGD+thBfeygPnZQ
Hzuojx3Uxw7qYwftZAftZAftZAftZAe1sINa2EEt7KAWcSd6aoIlgGcTS5n/MryRbrykueErMBbO
gXHwTzAezoViOA/ON2ZrX4V3DY/2PnwAfXDE8KR31J+N1dkfwydwAD6FHjgIvXAIDsNn8Dn8xTiQ
3QdHoB+OwhfwVzgGf4PjxgF2Zx+7s4/d2cfu7GN39rE7+9idfezOPnZnC7uzhd3ZknOl8VLOTLgK
roZrYBZ8C2bDtXAdfBvKIWG05TQiYxHcYRywlcE34RIxkt3cZsOutlmAbW3Y1oY92dlt7Ow2dnYf
O7vFdpOx2XYrz2+D2wEb27CxDRvbKozVNmzMzu9j5/ex8/vY+X3s/D7bAspCUGMEbVHqJKAW6qEB
GJPtDsoXw53km2AJYEPbclgBd9FPM6wkfw/cy1hWU/8+8msY20Pk1zFWzjF4ij7bo9w/Rv4JyjaS
f5L8U/BD+BFsgh/DM/AsPAc/gefhn+Gn8C/wr/AC/AxehJfgZXgFfg6/gDb4N9gM/w6/hF9BO/wa
tsCr0AH/AdvgN7Adfgud8Ab8Dn4Pb8JbsAM4jeC92vBebXivNrxXH96rD+/Vh/fqw3v14b3a8F5t
eK+deK+dtv3GCtt78D5z/wA9fQjd8An9HQBOBrYeY7OOLB05+k7YZbyk74M/QZcxW/+IZ9TXe7g/
CIbxkp19ZM+HM6DCeElkEbN+xXlpvcrtIJcgJ892OcRIeabcps6U74g3hEOVfsp1mtgpwvL3D2if
iOeyNBHOngxT4ALxXHY5XA8RaIQ7ed4ES2A5/Ag2wY8pe4brs/AavA5b4T95vo3rb2A7/BY64Q0R
tj0sltmOi3J9ipjJyeMLfbZYrZeLKfY7xNc4hXQ67hVTHKvFTMd9QMRxPAw/hKfhWfGm4zmxzvET
6vwMXuH+59z/mrpb4HXqbDX+4PhQlDs+ET7HAU4G+ejhY1u/8NmOcs65E5aKBvsy0eB4nBobYCM9
PAkviHXOOaIhfRZ/R+SqE/lOdZZ6U54/qVtO3XLqlqt6RdTo4cRwmBNDDyeGw5wYDnNiOMyJ4TCn
hR4ieA9RrIcI1kME6yGC9RDBDhPBDhPBeohgh4lePfTso2cfPfuIZD1EssNEsh7hRPZOLDIGi4yx
LzU67cuY5eOwQZ6B4Umj0zkHbrfWwCFpfZEjz860K6ZdseMpxqpbs9iPPjvQZwf66kBfK4VdncAp
wQIdJ5VmWxp4Q53PNb4PqNP8Sk7YuzltypP6z3g6W54kxQPqN1msMD5Xv8titRgh7uN6PzzO8w3w
BGyEJ+Ep+CE8DT+CTfBjeAaeM46Kn0ArvAA/gxfhJXgZ/p0+fwnbYDv8FjqB84fYRflu+CPsgbdh
r3FUrgXNZnyuvSvGaO/DB9DDW8NBOAyfQR/PjogxOWcYB3OKYBScCWfBaPgyjIGzwQ1fgbEwzjia
808wHs6FYjgPzocSmAST4WswBS6AqfANKDWO2g4bn9s+g8+hj3tWke0Yq0MzPtedXPONg/ow46he
yJWx6YxNP4vnZ4sR+jnkxwHydeTryNWRq0+m/EKeI0dHjo4c/SK4mOdzeH4Dfc+FeXAjz2+BW+E2
uB04c+ucuXXO3Dpnbr0aQlADYYhAFBZCDBbR5g5YDHfCep5hax376pvI/9g4bA8bnzvyWN0XGJ87
r4JvkZ8NNxoHtZmsnA/EXazhZrgbVrIPiTWspm5xL6wmfx/X++EByh6E71NvDWv+Ia5ruV8H+A31
XvuIca941HiD/dko1htvi2ep8zz8M/wU/gX+FV6BnwMxRBBDWF3drK5u0Q6vwev0uZXrNvgN+e1c
fwud8Dv4Pc92wC76+APshj/CHngb9sI7sA/+BF3wLvXfgz/Dx/AJHIAexn4QeuEQHIbP4HP4C/TB
EehnbkfhC/grHMMD/I15Hudq8KYnjLe1LMg23mHVf6A9wXUjPAlPwQ/hafgRbIIfwzPwLDwHPwHG
whtOJ284nbzhdPJW08kZrJMzWCdvNZ055xiHciYY3TkTuZbAJJgMX4MpcAFcCF+HqfANKIWLYBrt
ZR9l8E2YDjPgErjMaOTNZz1vPutzao13cpYgI2m8wy75gF3yAbvkA9tfjEPslEO2I/CF0W3jLY0d
020zjHd0YRxi53ygM3f8b6OuG2/rDp45jW7dxbNh5Ifzxj0CToPTYSSMIt6eRZ3RlH8ZzubezXUs
bc7jej5MpF4JTKYe89QvoG/mxy47xC47xC47xC47xJvLenZat15G22/CDJ5dApfC5bS5kuvVcA1l
sxjjDYx3LsyD7/D8u3AT3AzfAw94qeujTz9UQhVUQwCClIW41kAYIhCFhRCDOOUJQJ96HdRDAzTC
Ivq+AxbDndDEm9USQOf6UlgO98AquBdWw33o4H54AB6E78Ma5vEQrDXuJcbdq68z3tAfBvai/ghz
fhQeg/WM53H62ECdJ9ATa1JnTeqsRTxFN56iW3+Ges/S7nnjHbzGB/aocci+EGJQC3XQBIwLj9Lt
YPwOxu7gmWMZrAB8iUOeKxinA3/hwF841vAMX+FYCy3Ew03G244fQyv3L8HL8Atog3+DzbT5d/gl
/Ara4Tc8Z6873qPfbqOReH2v48/G284pROILjA+crHkndndeCldxj52d2Nk5i+u3jG48XrfzWu6v
g2/z1lrO9Qaj0TnXeMM5j36wvxP7O7G/08NeP1ud5P4/ndq05UT1cfhl+ZvA5O8B0/HLrfjlcfjk
NnxyG744iC8O4ot1fHEQX6zji4PiB0YJ/ngN/jjIDIL44yD+OIg/DuKPPZwKgpwKxnEqCHIqCHIq
CHIqCHIqCHIqCHIqCHIqGMepYByngnH4b52TQZCTQRA/ruPHdfy4jh/XOSkE8eU6p4Ugp4Ugp4Ug
p4Ugp4Ug/l3Hv+viF8hsg3+jr83wKzEGH98mfs11C7wKHfAf8BrPX6ftVq7/yf1vyP8e3oS3YAfs
oq8/0O9urn+EPfA27IV3eL4P/gRd8C7199PXe1zfRy8fcIb6ELrJfwR/Rqcfwyfo6wB8Cj2c2A9S
v5frITgMn8Hn8Bfoo+wI9MNR+AL+CmYsCGbEAg/ntE3EAw/xIMhJaDbxoJV40Eo8aCUetBIPWokH
rcSDVuJBK/GglXjQSjxoJR60Eg9aeScv1fbTnjnwbl7Ku3mp+kliH9cj0E/+KDKOcf2b4cnKMkqz
ckA3SjlRjeNEFeREFeREFeREFeREFeREFeREFeREFeREFeREFeREFSS26Jyqgpyqgpyqgpyqgpyq
gpyqgpyqgjlf5ZQ2gXfqidQrMTzEHg+xx0Ps8RB7PMQeD7FHJ/boxB4PscdD7PEQe3RiT5DYkyD2
BIk9QWJPgtiTIPYkiD3BjNizhtjTRuxpJd7oxBsP8UYn1gSJM0HijE6MWUOMCRJjPMQYnfgS5LQW
1AvEGOKMhzgTJM4kiDMJ4kyCOJPgFBfkFBfkFBck5ozTz6TeaNp+Gc422og5uv4VnqEHTndBTndB
TndBTndB/Vz6LYbzKD8f0IM+ASbSbwl8jbbMnZPfOOKSTlzyEJc8xCUPccmj4hLzJiatISbpxCSd
mKTrlxklxCUPcUknLunEpSBxSf582cdpcRwnxCBxSScu6cQlnbikE5d0To1BTo1BTo1BTo1B4pRO
nGrVK+grwFyCPFvA+OJcE1ALdVAPDdAIi6h7ByyGO6GJZ0sgCUthGe2Xc13BGO+CZmOlfjesJH8P
81gF98JquI969wM+ibiUIC4liEtB4lKQuBQkLgWJS0HiUpC4FCQueYhLHuKSh5i0hpgUVDFpI3Nm
bxCXWjnBjiM2rSEmeYhJwf9i5t7j267ve4/LSmJJCZSUKqVcwi3hYsCBxKO0JWkbKMSAuTilKWDu
xBjExVxMwOQGuOpoqatNtPXq47PNm6dz5nhpdnGO5m5ja8TpvOEAo7OUtQLiEATEmHuAluZ3nlIE
TVlPdx7ncbadP179Sr/fT/JP38/7+/68v1KKnpTQj2r1o1r9qFY/qtWPavWjWv0ooRfV6kW1elGt
XlSrF9XqRbV6UUIvSuhFCb0ooRfV6kW1elGtXpSY2Rcs0I+u1o+u1o9q9aNa/ahWP6rVj2r1o1r9
KK0fpfWjtH6U1o826Ue1+lGtfpTQjxL6UUI/ulo/SuhFtbNODxboR2n9KK0X1epFm/SiWj0ooQcl
9KCEHpTQgxJ6UEIPuloin68P1epDtfpQ7awrQofrRYnQkZx8lJOPcvJnOfko9xnlPqPcZ5T7jHKf
Ue4zyn1Guc+oFTVqRY1aUaNWyigFjlLWqKqMqsqoqoyqyqiqPKsqz6rKqCqMqsKo2R71iUZ9olF3
N+rung19xF+esi/N8aMCHyrwoYKsOiWr7pZVp2TV3TypwJMK3nXKu0555VQoWnOA/V8T9v6K0lH9
NWfrtIuCzLTmIGOHm7B7DVd+Y7Mn9igRlFxVcuYKO4P3zxQqV/6tnfYVwbby3vj93bb99AGONOGK
ym9sy8vv8/7vfqEZzu6uWRi87ordNc0o/7rx0ZovO3IpLkMLLscVkOrKr5/u+XTPp1+Jq3A1roE9
2nR7tOnl30XK9/p8+Relyl0+43W5yv2Vd/e5979FqBz5yd7PXD1SvvrPyr8nhQ50H5vdx2b3sdl9
bHYfm53d7Gzm/U/oXja7l83uZbN72exeNruXze5ls3vZ7F42h6Z51Y7qL3cToYaa2uD7NUf4PEca
j8LRmIf5OAbH4jgcjzqcoFudiPVec58Zv9+43bs9h53YjbfNy1nB96efjWVoxDk4F+ehCefjAlyI
i4Lv1z5mHzpufBrP4NkgUztlfAV7nAuC70fca2R/HATzHjHvEfMeuc7zhHke9WmGaiLBZE0MMzEL
++MjmI2P4kB8DHNwEA4OxmoOUe9Dg0drDgt+VDM3+KOaw4MRszJhVobMypBZGTIrQ2ZlyKwMmZUh
szJkVobMypBZudus3F3zG97vMzgdS3EmzsV5OB8X4EJchOX4IlbgWqxEgiZucj8341b3dBdW4W73
dQ86cS9Wu26Ne1xrXAd7AtWYUI2JmvL3+l/BduvwOezEbrwd5FRlSFWGVGVIVYZUZUhVhlRlSFWG
VGVIVYZUZUhVhqY3B5PTL8MNwe7pCdyEdtym995uP3gHVgVj09e4Zi3W2Zd9D98PHq39G+Mjwe7a
HwZjtX+Pf/D4H/Wdx+xfnnDun/CjyverQ7XbnPsX/Bg/QRFPO/4Mng3uri257iW8XPnedYgqhmpf
8/gd172L9zze432DYCgSCiYjM4IRahmKxIIxihmKqH/kQMcO8vgTHttPRg7BYZiLw2FPGTkS8zAf
x+J41OFEnIR6nIKFWIQGqHnkVHwSp+FT+DToIEIHkcWghcgZoIfIF3AWzkaT+zsfF+BCXBTsjvCe
yHJ8ERfjS8GjkRX4cvCjyCW4NPijyGVo8XkuDyasggmrYCJylfe72ntc45prnbvOZ21z7AbcCGs+
ckvZg8IPh24I/2HweKgmfEGoriYTmh48Efo4TzpI2j2Y1x4SPBY6NEiFDguaQnPtcg53/ggciaNw
NOZhPo7BsTgOx0vRdbjOe61EK65HG27w3jcigbu8/yrcjXvQ6e/ci9VYA6oOUXVoPXoptxYH41C9
4TAKnys5H+65ilmhOSs0Z4XmrNCcFZqzQnNWaM4KzVmhOSs0Z4WOWKEjlX8tcRNuxt3e6x504l6s
dmwN1mId1lf/hcb9wWT4sODJ8BE4Kng8fKxxQVAfXhikzODy8PJQQ3hl8Gi4DWY6fKtxFTqDvvAa
Y8r1/a4fcP2fe/7XHheM7wSPTpuJ/YO+accaXwyemPYSdmESL2MKr+BVvIbX8QbeDJ6YHg+aps/B
x3GW1X02lqER5+BcnIcmnI8LcCEuwm24HXdUfsNeYBXnZjQGmRkXBwtmfAmXBE0zLg22zrgueGLG
TbgZtwQjM1Yb1+Ah575hTLvuYeN3vKbX+Hue/77xCe/3JP4JT+FH+GfXjCOPAp72957Bs8FjM7Zj
IkjN2IHnvMdO768XzihhKtgqLeSkhRxnKXCUHEfJcZMcNyk7SI5b5LhFjluMcIgch8hxhEmOkOMG
OW6Q4wY5bpDjBDlOkLP6clZfzurLWX05K61gpRWstAkrbcJK67PS+qy0nJU2aaVNWmnlVZazyias
spxVlrOyJiOloBR5IdgUeTHIRF6y+nYFo5HJoDXyctAcmTK+4vyrwXDkteDJyOt4A2869pbrd/sb
b3vNO8FTkXdd+9NgWeRnxvdc83PX7PG+QZCJhoKRaE0wGg0HrdFpQXN0unFG0BOtdS6CaNARjQUt
0ZnBsugsx/cLro7ub/yIcwfAjidqxxM90DUfc008OCQ6x/mPu+4TQXf04KAveggOdf4w180NmqKH
B0uiR7juKNcd7T3mwa4neozzx7ruOO9zvPN1zssGUdkgepLzdj3RBc6f7Pwpzi903u4veqrP8EnX
nIZPBf3RT7vmM6453fHF7mGJ133W8885/nnj0j07omd47ZlBQ/Rs1yzzOjqNnuPacx0/z3VNrjvf
+QucvzDoijYbl/scX8TFrvuS61a47ss+yyWuu8z5Fu9xOa5w/krnr3L+au9zjfM/Dh6N/gRFPI1n
8Cy2YwI78Bx24nmU8AJexEvYhUm8jCm8glfxGl7HG3gTb2E33gYviL4bPBq7Lngy1hpkYtejLSjE
uHfsxqA9lgiaYzcF6djNzt8SlGK3Bpti7a65Ldgauz2YiN3hmjuDq2MdwYOxVUFP7O6gL3YP7OJi
94K3xtYES2Jrg1mx9UF/7D6vvR8POGcHF/tK0BJLBstiX3X+wWAk9jWv/Toe8l7fCDbEup3/pten
8NvOp732YXzL+W97v+843+P12aA+9jf4uyAVe8K9PonnPS7hlaB+5ozg0Zkn4EScjXOCvpmXGC/F
rR634+7gUbuCXM1+OtOgrpSp/iumCV0poSuldaUJXWlQVxrUlQZ1pUFdaVBXGtSVBnWlQV1pUFca
1JU6dKWOyr/5uMF73YgE7vIeq6AL6EITulBaF0rrQmldKK0LTehCE7rQRPnfS+gAgzrAoA6wXQcY
1AEyOkCCuw9y9wx3T3D2DBcf5OKDXHyQiw9y8UEuPsjFB7n4IBcf5OKDXHyQiw9y8TQXT3PxNCfO
VP/dQYETZzhxhhOnOfEEJx7kxIOceJATd3DiQU48yIknOPEgJ05z4kFOnOHEg5w4zYkHuW6G62a4
bobrZvb5Fz0TXHeC6ya4boLrprnuBNed4LoTXHei6mpFrlasutoIV0tztS6u1lJ1tX6uNsjVBrna
YNXVClytwNU2cLURrtbF1Tq4WgtXG6y6WpGrFauuNsLV0lyti6u1cLUcVytytSJX6+Zqaa7WxdW2
crUOrpbjakWuVuRqPVytm6uluVoXV6vjalu5WgdXG+FqBa5W4GrdXK2Lq3VxtQ6uVsfVclytyNWK
XK2Hq3VztTRX6+JqdVwtx9WKXK3I1Xq4WjdXS3O1Lq5Wx9W2crUOrlbgakWuVuRqG7hamqt1cbUC
V+vhat1crYurpblaV3QpRzzDa8/kiLo2VytytSJX66m6WpqrdVVdbStX6+BqOa5W4GoFrtbD1bq5
WhdX6+BqdVwtx9WKXK3I1Xqqrpbmal1lV+Msg7GVQZG7FLhLgbvkuMtT3KWLu3Rwl07uMshdityl
yF2K3CXHXZ7iLmnu0sVd2rnLCHcpcJcCd+nmLl3cpYu7dHCXQ7hLjrsUuUuRu/Rwly7ukuYuXdyl
jrvkuEuBuxSq7tLDXbq4Swd3aeAuW7lLkbsU93GXNHfp4i4Z7pLhLgnuMshdBrlLgrskuEtGtl0R
qgtPhk6Vbcv/++3wAvns4eDUcD7YFC7hveDKafsFm2rPC30nUgqdFnkhtDTyInaFFkcmjS87NkWd
r3j8auj4yJuev+Xxbrzj8bvGnxp/Rr0/N+7xPAgtjdaEFkfDxmmh0yi4FJ0Rqo/Weh5B1LGYcaZx
FvYLHR/d3/mPOHYAPurYgcaPGeNeO8f4cdd8wjUHO34IDnNsrvFw4xEqfJRzR3s+D8c4dqzxOOPx
Xl/n3Amen4h6xxYYTzae4txC4yLvfaprPun4afiUY582fsZ4OhY7v8T4WXzO8c8bl3rtGcYznTvb
a5c53ohzHTvP2GQ83zUXGC90TbNrljv+RXzJsRXGLxsvce+XOdfi+eW40rGrjFcbr9HXVoaOj7WG
lsauxw2h+tiNxkToNOosxm5x7lbP23G7Y3cY7zR2eN0q197t+T2417HVxjXGtV633rn7PL8fXY59
xZg0ftXrHnTua55/Hd9wrNv4TWPK637bubTnD+Pbjn3H2BM6LfStiqK2SPf5YC1VraWqU3+Fok7b
R1EFilpMUfN+haIWU1Q9RRU+pKjT9lFU4d9Q1Lxfo6hCVVHzPqSoeopaTFH1FFX4NYoq/BpFFaqK
mvdvKGrer1BUoaqoeb9GUYWqouZ9SFH1FLWYouopqvBrFFWgqHn7KOp4ilpMUfUUVaCoefsoqn4f
RRU+pKh6ilpMUfUUVfg1iip8SFH1FLWYouopqvC/VdRd4aNCSySKTfvsHTK6bLrSZV/VRd+2z3g3
6NFFH6SUzn32AhldM13tmuVumdYtM7plWrcs6ZadumW5S27SJdO6ZEaXTFNFgy5Z0iU7dcmndMeM
7vig7tijOz5Y7Y7lrrhJV0zrihldMU0NDbpiuRtu0g3TumFGN0xTQoNuWNINO3XDchdM64IZXTCt
C5Z0wU5dMK0LpnXBjC6YpoAGXbCkC3bqguXut0n3S+t+Gd0vXe1+Jd2vU/d7StfLVLtej673YLXr
lbvdJt0urdtldLt0pdu1Wds36h4JefgmOfYWOfoXWTmjm6VVuUs3e0oXy+hiD+piPbrYgypcp4uV
u9cm3Sute2V0r7TqNuheT+lamWrX6tG1Hqx2rXK32qRb9ehWGd0qHfqDSlZcEDTJiSPhVcF2eWpU
nuqSpzpVukelMyrdpNILVHqJPPWUanfLUE/JUF0yVLvK98hQGdVvUv0Fqr9EfhqVn7rkp7ISeigh
QwlNlLCAEpZQQkJ+apWfWimimSJmUcQsikhQxBKKSMhPrfJTK2U0UEYzZcyijFnR+J6XKSNBGUso
o0V+WiE/raCQBgpZRiGzoofveS96hOuOct3R3mMe5jt/jPc51vnjcLzzdc6f4NyJOMn5eucXOHcy
TnFefqaYJRTTJT+1yk+tlNNCOYdEP+NvnK7ai/3NJV73Wc8/53WfNy7d8zDlNEfP9B5n+/zLgnb5
qZWCWikoQUENFDSHgmZRUD8FNVNQj/zULj+1UlIrJSUoqY6S5lDSLErqkZ/a5adWimqlqARFNVDU
HIqaJTs9JTulZadO6togO41QWAuFLaGwVgoblZvSclMXpW2gtBFKa6G0JZS2gtISctMKuWkFxZ1B
ccsoblZszZ73Ymv3PE1xHXJTq9zUSnlnUN4yyjuE8mbFvur8g5T1Nfnr684/5NpvoJtSvxnMocA5
FNgvN7XLTa2U2EGJHZTYQIlzQiso8HGKK1DcJLWVqK2r8n3E23LMO5L+u47/1OO93lKgqElqKlFT
FwWVqKfsJcPUUqCWEqWUeEgXlQxTRpEyipQxyTuKvKOTGgrUUKKEEs/oUv2C6pdUvsQrulR9WKVL
/KHsDcMqXOINJb5Q4gtdPGFYNQuqWVLJkkp2qeKwyhVVrqhykypXVLlO1SqoVkmlSirVpTpF1Smo
zqTqFCvJdu/6L6hKUUVKlbXf6fG9WO3cGuNa1z3gmi7nk/iqax5y/Bvods03jSnXfMs133a+JyiF
+qtr/HEzvN76Lljfj1jfw2Y7Y7Y3WN8dZrzVjJ9hfRer67tgfQ9b32Vnz6jABhXoUIEWFTjD+i5Y
349Y38OqkVGNDdZ3h4q0qsgZ1nfG+h62vodVp9P6TqhQi/WdUaVW6ztjfQ9b3+WKtatYp/WdULUW
VZttfWdUrtX67rG+N1jfG1SxXRXbVbFFFZtUcbb1nbG+h63vYRVtV9FO6zuhqi2qOtv6zljfw9b3
sAq3q3Cn9Z1Q5RZVnm19Z1S6tfqtz7D1Xa56t/WdUPmW6rc+7arfqfot1neCAlqs79et78w+3/oM
W99lRaQpotv67qCKFqqos74foYz26rc+G6zvDVSSppIuKklQSUu1U5S/9Rm2vocpJk0x3dZ3B9W0
UE2d9b3V+h62vocpaJiChqt7o1YKaqGgrdb3I9b3MCUNU9Kw9d1FTe3U1GJ9Z6zvDdb3Bspqp6x2
ymqhrCbKmm19Z6zvYet7mMo6qazd+k5QWgulza5+67LB+t5AdWmq66a6BNW1UF1d9VuXYet7mALT
FNhtfXdQYWvodyu/HN0XTFLjjup303u/i15FmZ1yxQtyxYt4SY7YpbtM6iwvU9uUsewDb7lmN8o5
Y+/3kO3U2EyN7ZQ4QokjlJijxKcosZ0SWyixnRL7KXGEEkcocR0ltlJiMyX2U2KCEvspcYQSRyix
gxLXUWIrJTZT4nxK7KfERFWJmyhxEyW2UuI6SlxBicsocQ4l9lPiCCWOUGIHJa6jxFZKbKbE+ZTY
T4kjlDhCiR2UuI4SWymxmRLnU2I/JSYoMUeJI5Q4Ut2pt1JiMyXmqjv1dZTYTImtlNhMiS9TYj8l
Lqnu1EcocaS6U++nxFZKbKbEJZSYo8RuSnyEEjdR4qbqTr2fElspcRklLqnu1EcocaS6U++nxFZK
bKbEJVS4iQo3Vb7/u5FSEhRQ/u7vVgpoR9nH7nD8TurocHwV57/b9fegkyLuxWpdZo0OslZnWE9R
93nd/XggWEd5HZTXSnnNlDenuiPfRHmb9vm+r5XymimvifJylDdCeSPVHfkGymulvObQVylukuJG
Kv73EiXtoqDJoI+6uqlrRSW9vqm7vKXL7MbbrnmnkmbTFLaOwlZQ1jBl5Sirj7K6KWsFZRUoqoei
+iiqm6IKFLWOogqU1E9JPZTUR0nd1TRboKR1lJSjpAlKmqCkHkrqpqQ0Ja2jpAZKKlBQPwX1UFAf
BXVXU22Bcvopp4dy+iinu5pqC5Szrppqhymmj2K6KaZIMf0U00Mx3RTTRzHdutd8iilQTAfFFCil
v6qUPkrpriqlQCnrKGUrpUxQygSl9Fe/qU5TyrrqN9UFCumvKqSPQrorClmpG7VKstejjS/doDPd
SAkJ1f1Ft9ta/e6mj1K6KaWTUnKUMkEpE5TSQyndlJKmlHWUMp9SChTSTyE9FNJHId3V1LuVQiYo
ZIJC+imkn0LSFLKu+o1wgTI2VL+r6aOM7vK/6QgtqmkKLQpnQ6eHd4UWhidDp087KrQwcn9ocObv
hx4Ixfe5YmHlzEuhRZG3Q4uiIczGoZiPk3AOLsYVoUWxNtyGTjyAh/Ct0KLQ3PBhQV3Y3iV8LFJ2
6X8fbAs/iR8hj+eDbZHXgrrI63gD73HW63AznghOjT0ZnDozFGybWYMjcRROQj0WBdv2ew2v4w28
id3BttABNc8H+fL/i9w6uCx8SvCX4UXB6vDng97wWdbGecFAeLnHK4J8+MvQJ8L3BNnwvcHq8r8+
CZ3rnne6551W0uvue6d3eT18slSxMHgmfLpR1gmvDF4Mt+FWrPIud+NerPH8AWNXkI+M2GEUjU/j
GbwW7PQ5d/qcO33OndEvBNujZ+HHwYvRn6CIp/EMnsV2TGAHnsNOPI8SXsCLeAm7MImXMYVX8Cpe
w+t4A2/iLezG23gH7wYvxj4d5GOfwelYjCX4LD6Hz2MpzsCZ+ALOwnXBTvXZWXNgzfZgZs1z2Ild
obqaV0LLa97Abs/fxjvBxpp3HX/P+PNQXfig0HKzGze7cbM7Fp4XbDTD8fAJxgVm7RR1afB4CbX4
6+GlQTJ8Bvzl8DLHG73mXOP5weXhC4wXBg3hizxuVt/lrvuiYxcHjZXaXmK81Ptc5niL55c7d4Vd
/ZW4ymuu9vwaXIvrXLtyz+5wG2507U1ec6vHdxjL1b0naA+v9po1jt3v2FeCy6edHloe+YtgY2Qz
/iG4PPIYCkEysg0/xmtBXLXjqh1X7Xj0omBj9FJcK/tQeHQlWnE92nADbkQCN8EKiN6CW9GO23A7
7sCd6MBdWIW7cQ86cS9WB8noGqzFOqzHfbqfe48+AOqMfgVJfBW/iQfxNXwdD+Eb6MY3kcJv4beR
xsP4Fr6N76AHv4Pvotdn/C+hJdG+0NnR/2r8Xfwen/j90Mpov8d/YPxDDHj8R67NGP+b5//d+Meu
Gwwuj27AEP4EG/E9bMKf4s/48J/D3EeHYf6j/wNZ/CVG8H38Ff4af4NH8Lf4O/wAW5ALGqOP4n/i
h/h7jOIf8I94DGPYisfxBJ7EP+Ep/Aj/jHHkUcA2/At+vGd39Cco4mk8g2exHRPYgeewE8+jhBfw
Il7CLkziZUzhFbyK1/A63sCbeAu78Tbewbt7dseO4b3H4Xjw6djJQTJ2ChZiERrwGzgVn8TZweWx
ZWjEOTgX56EJ1lnsAlwI6yzWjOX4Ii7Gl7ACX8YluBSXoQWX4wpcCestdjWuwbW4LohzkHjsN4ON
sd8KNobCldW/yv7tsPJ/Q4FnLOcXy8PTOO0MRDCP855Q2duNWcd11nGdV4xYg9utwe00V0dzdTRX
R3N1NFdHc3U0V0dzdTRXR3N19FZHb3X0VkdvdaEIJyqG6/39BcGTPP6vwudwhLILdAb50Es1293L
BA/bgec83hla/v5/36Nmt8dv453g8ZqfBr9Z8zPje9jjcSDph6X+acFd4enGGcZaY8Q4z3gC6n2G
BcFuvrcxvNDjRf4qB670qqU+51lY5nkjznH+XPNwvru9yPNm55bzvb2et7eXXYJLK16XN0cN5qiB
1xU/5HX5cKvufwMSuMn5m423oB234Q7H7jR24K5QvNojN+pwt4fXOrYe9+F+++cFcsJfBI+qwaN8
sMgHi3ywyAeLfLAYedb5HXg+tJD35XlfnvfleV+e9+V5X5735XlfnvfleV+e9+V5X5735Xlfnvfl
eV+e9+V5X5735XlfnvfleV+e9+V5X573lf0nTwsNtNBACw200EALDbTQQAsNtNBACw200MB/8vTQ
QA8N9NBADw38p8h/ivynyH+K/KfIf4r8p8h/iv8PfCfPd/J8J8938nwnz3fyfCfPd/J8J8938nwn
z3fyfCfPd/J8J8938nwnz3fyfCfPd/J8J8938nwnH/2pOf4Z3sPPsQdBaGEshBqEMQ3TMQO1iCCK
GGZiFvbD/vgIDsBsfBQH4mOIYw4+joPwCRyMQ3AoDsNcHI4jcCTkydjRmIf5OAbH4jgcjzqcgBNx
EupBW/yryL+K/KvIv4r8q8i/ivyryL+KsdNc86nQQsl1e7BdGtkujWyXQLZLINuljW3SxjYpY5u1
/abcVpLbSnJbSVYr6dLbdOltuvQ2XXqbLFaSxUqyWEkWK8liJVmsJIuVZLGSLFaSxUqyWEkWK8li
JVmsJIuVZLGSLFaSxUqyWEkWK8liJVmsJIuVZLGSLFaSxUqyWEkWK8liJVmsJIuVuOI2rrhNUn9e
dl0YvMoDBrhR0nrfaL1nrfPeiitN4xg5q39jOenULPfJZ9dM8J0deM7jnXg+qC//V3v2yWSzzchs
XtVU865X/bTiVU01P/d4T8Wr6nnVCK+q51UjvKqeV41UM9tcsziXU07xrh+azbn864fuIuU+y57V
yLOS7jclr60On+lev+DelznW6PG5xibXnR80yW29++S2y6selqzmthQf21jNbo2y22rZbYCfJffJ
bk38LMnPkvwsuTe7yXmtPoMcFb7BmMBNQV/4ZuMtkKHC7cbbYP8VvtPYgVXBeCW53+N+OivpvS68
1vH1uI/f3u/aapqv5L0FweO87oe87oe8ronXNfG6Pl7Xx+v6fintP+ta9Yg8j9eCuVQ2l8rmUtlc
PtjIBxv5YCMfbOSDjXywkQ828sFGPtjIBxv5YCMfbOSDjXywkQ828sFGPtjIBxv5YCMfbOSDjXyw
kQ828sFGPtgoA66WAVfLgKtlwNUy4GoZMCcDrpYBV8uAAzLggAw4IAMOyIADMuCADDggAw7IgAMy
4IAMOCADDsiAAzLggAw4IAMOyIADMuCADDggAw7IgAMy4IAMOMCDk9UMuGhvBrSv/uUMeBkPvqya
AZO/IgM28eAmHtzEg5t4cBMP7uPBTTy4aZ8MmOTFSV6c5MVJXpzkxUlenOTFSV6c5MVJXpzkxUle
nOTFSV6c5MXJf98MKIf/BEU8jWfwLLZjAjvwHHbieZTwAl7ES9iFSbyMKbyCV2G3zEnqOEkdJ6nj
JHWcpI6T1HGSOk5SF7W2o7JIVBaJ/hzWd1QeiYVQgzCmYTpmoBYRRBHDTMzCftgfH8EBmI2P4kB8
DHHMwcdxED6Bg3EIDsVhmIvDcQSOxFE4GvMwH+W8eqzx/cxa5/EJOBHl/FpvtO70gT59oE8f6NMH
+vSBPn2gTx/o0wf6Yqe55lP4v9vRzuW8c0Mn1ExypPd3oksrTlbeda7mYI0VB7vAeBGXaOYYyz2+
2O5VAuZa13OTIU4y0ypOW7kJKzdh5SaszrQVmbASN1mFm6zCrVbGSitipRXxnWh/MGFF3GNF3BPN
eLx3JSyqrITvBZt0zkXVVL/YDC02KxeFlvD8Xl7fy+t7eXsvb+/l0wN8eoBP53n0QDXVbgyf7NxC
nI5z+PFKvtlW3uNW97d7vS8ZGQl6edUArxrgVQO8aiD6haA3ehbsaek5Sc9Jek7Sc5Kek/ScpOck
PSfpOUnPSXpO0nOSnpP0nKTnJD0n6TlJz0l6TtJzkp6T9Jyk5yQ9J+k5Sc9Jek7Sc5Kek/ScVJ8B
9RkI/bE03rBPGm+Qxhve/y+8SeMN0nhDNY2v3yeNr6+m8REdbr0ON6LDrdfhRnS49TpaVjfLSuPx
yu7ilOC3dK5y0s6r8fW605ZKur7csStccyWu8vxqx6/BtWh17AYkIMFK1HGJOi5RxyXquK6Tl6jj
EvUv0vRaj9fjPtyvYywIxXWXrO6S1V3yukted8nrLnndRUdxfgeeD8U57CSHjdNRnMPGpdw4PcXp
Kc5h4/QUp6c4h41z2EkOG6erOF3F6SrOYfMcNs9h8xw2z2HztJbnsHkOm+esWzjrFs66hbNu4axb
OOsWzrqFs27hrFs46xbOuoWzbuGsWzjrFs66hbNukUTjkmhcEo1LonFJNC6JxiXRuCQal0Tjkmhc
Eo1LonFJNC6JxiXRuCQal0TjkmhcEo1LonFJNC6JxiXRuCQal0TjkmhcEo1LonFJNC6JxiXRuCQa
l0TjkmhcEo1LonFJNC6JxiXRuPUUl0TjkmhcEo1bW3FJNG59xa2vuCQal0TjkmjcWotLonFJNM6B
8hwoz4HyHCjPgfIcKM+B8hwoL4nGJdF46N5f+tZziUyztPKdVS/n6OUcA1wjKeOkZJwUJfXKMKlK
hinnl3JWkUMooJcCej/87ajskJIdUrJDSnZIyQ4p2SHFdVKyQ0p2SMkOKQ6U4kApDpSSHVKyQ0p2
SMkOKdkhJTukZIcUd0rJDinZISU7pDhV6oNe/Qehs6nobMo5nmoOp5pequmlml6q6aWaXqrppZpe
qunVT1P6aUo/TemnKf00pZ+m9NOUfprST1P6aUo/TemnKf00pZ+m9NOUfprST1P6aUo/TemnKf00
pZ+m9NPUf2Y/pZDF+7jvove/oQ59NPK2WQphNg7FfJyEc3AxrgitjLXhNnTiATyEVOUb8pWx3wkt
kuaXBrvpYjJ8ceX/D7Scn8j1oemO52XlH8g7P5B3fmBnMCWtv175hmBML8pXrx2bRoPTaDB0M71t
rGbxgfB59uvn09be/UPK1Uu4WZu/s5GjPUiDvTS4cR9XS3G1Nq7WxtXa6LKXDlORct2utXe9DivR
iuvRhhtwIxK4CTfjFtyKdtyG23EH7kQH7sIq3A1OSHcb6W7j/7Gj/Ws3S9Flii5TdJmiyxRdpugy
RZcpbtbGzdq4WRs3a+NmbdysjZu1cbM2btbGzdq4WRs3a+NmbdysjZu1cbM2uu6l61667qXrXrru
peteuu6l61667qXrXrrupeteuu6l61667qXrXrrupeteuu6l61667qXrXrruDdWEz+EZZ7/f1Srf
/yyt7JXyH3zPc/E+3+2UO891ukG1Q/yHfKfyb3WLf8fvNEKfoOKN1V1i/oNfba7GNbi20qvyqptX
3bzq5lU3r7p51c2rbl5186qbV9286uZVN6+6edXNq24+FJGJtpTXWXW+y+sw/8GaO1NFxlQkW61I
eRc+Vq3G2K+oxphqjKnGmGqMqcaYaoypxphqjKnGmGqMqcaYaoypxphqjKnGmGqMqcaYaoypxphq
jKnGmGqMqcaYaoypxth/ajWm8ZZJ1ahUgnY/H6qrHBurHhv7YL62VOdrrDpf2X3mK/v/2XxlzVfW
fGXNV9Z8Zc1X1nxlzVfWfGXNV9Z8Zc1X1nxlzVfWfGXNV9Z8Zc1X1nxlzVfWfGXNV9Z8ZUONFT9e
ymfPq6zp8m9W363kgPJ8lb/P2TszG83MxurMbDQzG/9D/HYQGzCEP8FGfA+b8Kf4s+C71sB3/11n
aEZFUed80M/Gqr1vr54mdbaszpYNXWQms2byB+Ezgl2u7zWb283kLit2l5l8LLwi1GA2x81mNnyZ
Y1c5f10wbka3m9HtZjRrRrNmNGtGs2Y0a0azZjRrRrNmNGtGs2Y0a0azZjRrRrNmNGtGs2Y0a0az
ZjRrRrNmNGtGs2Y0a0azZjQbXR3siq7BWqzDetyH+/EABt3HBgzhT7AR38Mm/ClywbiZHjfT42Z6
3EyPm+lxMz1upsfN9LiZHjfT42Z63EyPm+lxMz1upsfN9LiZHjfT42Z63EyPm+lxMz1e7jTBRjP7
i+yQra7ic0LLQxH7qMdrdlV++9htj3KXPUq++qt4JvRp+XRKPp2ST6ecfTNsldk37qj+6j0VfsDz
rmAsUsTTeMbK+3EwJbNNyWxTMtuUzDYls03JbFMy25TMNiWzTclsUzLblMw2JbNNyWxTMtuUzDYl
s03JbFMy25TMNiWzTclsUzLblMw2JbNNyWxTMtuUzDYls03JbFOxTwdjsc/gdCwGV4p9Fp+DGYgt
xRk4E1/AWbzr2sov2uX/DsMOvP/L9r/+VTtf/VU7/8Gv2u+n972/Hm+ppPg7jHt/Pc6GV0tj5W8X
73fsK8FA5dvEQrDF3m6Lvd2W/9R0e3Kwxb5mi33NFvua/0Xe2cBHUd39/syZnVl2sgRULGotiqJG
0aqhcGndWutLrIK6YnxbNdK6KqKi9a2xFnxMvY0+pS/gba610cZqqWLrgxhbRaUqQWOVREWBVRA2
kQRkDWHhiRhpzv2es5Nks1neBGrvvbOf386ZtzP/83/5nf85s8ksYFyzgHHNAsY1CxjXLAiVMPo+
HXwPnAHOBOPAeHAWOBucA6KA0U1oAjgPlILzwQXgQnARuBjEwCXgUnAZKAOXg4ng++AHjPQtrTmx
Lz6Z7HkaKInnAHDBtXjeTeA2ynepZnTZjC6b0WUz7WmmPc20p5n2NNOeZtrTTHuaaU8zEXCNapX0
FvqJIz78gjisZ05B///8NvNLhuOtdvP/Lo/E9sdbmyhvVvOw+TzkqEaOauSoxvZ6vJ9AloS8VQzD
1kQFPvFjI1fCHi2Ot8eAE8QQOyqORM4EciaQM4GcCeRMIGcCORPImUDOBHImkDMhivDGFF6YwgtT
eF8K79O/PEniaUk8LIlH6V+PJPGcJJ6TxHOSeE4Sz0niOUk8J4nnJPGcJJ6TxHOSeE4Sz0niOUk8
J4nnJPGcJJ6TxHOSeE4Sz0niOUk8J4nnJPGcJJ6TxHOSeE4Sz0niOUmsdLv+jy+aKcRpSHtM79wM
5dWgRS1El1ehw6towTG04Bj0mPTjJ2niR6pG9NmIPhv9WIrRwhh6XUkrY+h2pYmhn1C+S630Y2cl
elyJHleigRgaiKGBGBqIoYEYGoihgRgaiKGBGBqIoYEYGoihgRgaiKGBGBqIoYEYGoihgRgaiKGB
GBqIoYEYGoihgRgaiKGBGBqIoYEYGoihgRg2XIkNV2LDldhwJTZciQ1XYsOV2HCl0c0D4kR0sxSd
LEUnS9HDUvSwlHYuop2LaOMivLHB/x2RZtUFtHXRVhh1EW1dRFsX0dZFA/S+VSAJmkAz+AisBi2g
FawBa8HHYB1IgU9AG1gP2sEGkAYbwSbw36ADfAo2g89gyC/CqF/JiqxqLD0HS8/B0nOw7lwsO9dn
yCex7FysOherzsWqc9HsXDQ7F83ORbNz0excNDsXzc5Fs3NNf5X5ldcj6nn5tForn1XtcrHqML/i
GiYfhB1qwCzuO5f1e0ToCiIyLEbag4iwF2CDBao6VAcagGaO5WAFaGK7jfUWlfAkcAHR6Y0D48EF
YLJKhJtUc7gZfARWg1bY5UD5K7VaPqzS8lH8dhY+/Tjlp8CLYAkRnAab1drQsyodmg9exldeYb1A
NSJNI9I0ht5Sq0NvgybKLRxvBetV2jtUpbwR4DBwkVrrXazWisHyPhVGC9XySVUnF6iJ8rWuZjRR
J5eqM+UqNNSkbpSt6ia5ToyW67vaZDsstkUNtcMqbA9Vk4SUz4rhMiWGk8vfh57WoaOD9f/kR4uN
aLHR6Fi3ZS5YAt5XZZw1ibY02mjHDmnNUh6kmuyvGu029mnPB2A5WAF0m9pUoxdUZd4AsBc4lO0R
4DBwONunGm03oe0mtN3kXcF2HFxpNN/k3Wa034j2G9F+I9pvRPuNA4VKDLQAVhtoAwcePYJWtNGK
Nqyi/aEOiySwSILWtGGVZtszkifsvcEBQD+PeBb7v0AeMZ/1K7RogaqjNXW0po7WtNGaNlrTRmvq
aE0b1mn2TkK6ElpwZn9f8X6EhOQ8SNyGxG1I3IbEbYw+H1FPof+hsg6JXkOipUi5Tpyp/y7W2GMG
nt2GvRrERCvZ1Wp9BFYD3Vd1sP4U9PZNC82vTVzzf05O5eqR8jfUVwUewPIP4oM14A/c61HiZS7l
59k/n23sxf1Hynp4p4H126zfBUupCy7Bg9ZKuETCJXK9GooPT8L2KWyfwuap0NNoqtZoTft0e+h1
ym90teHLp+LLp4aWsE3bQvTVaDCNBtNoMB36kO2VaHgVSIIWrm0FKa5t4/iGrjZPqEWeBQrVSG8o
64PAwWA4OBocA47jWDHr0axPNfExifiYhO+k8J0UvpPCb1JYIY0V0lghjRXSWCEdhv/C8F8Y/gvD
f2G4D19K4UspfCmFL6UG6jdl2FhrIWyzycTHkO6n7Oi5jCOziMBZHF2diUJ0uFjN96Owkigcjg5v
xbZHor/hROEM+0A1z/4a3newONIert7Tsdy1GXsvpIahxPEMaiilhuGyCSu1sl6Hp6xnfzv7t3TN
C3+gJoc/VmPDKVUd/kyNNb+DmEpfM5W+Zip9zVT6mqn4gpbxZnyhEV9olA9QfhjG+IP5TwkziIhq
IqIa2RPG257n+Itsz+f4a5TXI/8WNce2kXmEmoGtG7G1jpJqIqQae88gSqqxeWPoDXUzNp+FzWdh
80Zs3ojNG7FzI3aehZ1nYedZ2HkGdp4RSnH+eq7doG72zlMzvFvA7WqGYXjzZAfNzkCyJLpIoYOU
0X1Q3ocmnoXRUuI7cosYGVotZntHiirvelElHpS/6koYXWa8vhSvL6XFCVqs2Wyo4YAnsUyGB0pp
dcJEwous53POAsoL1Sj5Knita46sR+dvUH4TLAINXfNkI+u3wNsce4f1Yu73LuX3uPdSrl8GEux/
v2uq/ID1crCCYx+yXglWKSmTrJuov5n1R6CF61s5Zw0yrQVwsfyE/W1gPfds70rKjZS3dDXbdleC
CBxFBI6CwyrsAkZrYeXBYxX2UI4fwPqrHBvRpTmtwj5C3YHFNDuXYrWE4TUToV2J0NvgA/YvByvA
Sqy1CiRBJhJLsVJCR2MorUaFOsBnoBNs4dp/su4CSo3yRNcMzwKyK+E5RK/LOtg11RsABnK8sGue
N4j1YLAX+4aqUu9rlIeBgygfzLXDweEcO4J9ReBIVe0dRV0jwdEcOwYcRz3Hc6yY8ijuMZrtk1QF
0T8KHq6Ahyu889h/BdtxcCW4Wt3hTQLXgFs4dhv7fsR5t3fpHqUUZiiFGUphhlKYoTS8oWtGOA02
gk2go2sGzDAKZhgFM4yCGUbBDKMGRtQo8Q1iTMdWCk8bjac10NuU4mkj8bKRflyl8LDReFgDGUmm
L9V9qKeqsV6KXqga683BcnOwWDUWS2Gx0VhrNNYaSS9USi9USoyl6Im0lRqwUgNWaqAnKiWWUlhp
NLGUInNpJHNp7NO3jgInqTlopxrtzKGXqqaXqqaXqkYzKTSTQjMpeiz9f1+qGd08SDzUmBhJdOdQ
moPwIe0vCfwlgb8k8I9Ebr6EPhPoM4E+E+gzgT4T4hIiOmltFp61RXjwUhJdtcJBregqgW5a5QJR
KOvB2+BdsIQMsYX1GrAWrEMq/QzkM9ad4HPwT8ZXAlhAggBwQBAMAIVgMNgL7APgbvsrYD+wPxgG
DgIwi30o0M8En1Wt6L0VbmtF7wn0nkDnCbgtCbcl0bfuq1rhsFZ03uoJUehZYCg4CBwMhoND1VL0
vxT9L/WOZvsYUAzGiCHeWPAt8G1wIvguOBmcAs4CUTABlILzwSXg++AH4FpwHbhVDAlvEIXhNNgI
NoEOUTiQOsVVaDiNDVPYMIUNU/TuHfTsHfTsHRnNsl4D1oId1aqr0j2aDVH2VOt2NfxVzsujZby8
FV9KodU0Wk3jUyl8KoVPpfCpFD1/Bz1/BxzRATd00Ot30Ot39NUq28eAYrA9rZ5KFl2Ctban3Ss4
Lw6uBFmahi/SREYrvp3Ct1P4dgrfTuHbKbKIDrKIDrKIDrKIDrKIDrgiDVek4Yo0XJGGK9LGMntj
mZdNtv2A7nlM7pcg72qkr20kt2onxrWvvYxWXiauYV6iqpD4PQ6MBhepdvKbdrKJ++ilH+Cqh2GZ
R1jPoh96nFzhKZBhnUYiayQ9eCM9eAJ7VersEraZAdtUwjaV9Oq6j6jE60fi9SNhm+GhBV2bQ3Xg
DZ3Fs24CKcrrOb7BMEkluqyESSphkhkwyQx6cJ3zzoBBdE+u895KevOEkJrBdZYiCmjpHPl6L5+E
Ps3hjjA4IMMhwmGsQe8BBoC9wOFm7wKjsUkmW25STWhtNDnB++TAKTGa8+dx/jzOn8f583RewFh8
KVdaXFUtAiaryVyb0tmNcPVcE7W+69eaINNYyZFJYl+rjUwbq1hp1htNltzYI/8y9KvHlaPR5xg1
p09bHNXWpz1HsT0S6HYFzK88FyBB5l76ya+W/EgxWxxKDhcmhwuTw4XJ4cLkcGHObeLOpUTwDPxk
NFE8gyieYf6XThP9CfkUkVxNJFdnRnrmb6foiUEh5aFw+kHgYLaHg6PBMeA4jhWzHq1G48H0dmAj
2AQ6yMN0+xO0P0H7E7S/u90ptL2Qtn/S0/Yt6hO/3SnT7qBaiBUWYoWFWEH/p7EU7U+Z9odgnzS1
tMM6aa5oJ6LTRHSaiE5zZjtntmPnJWoFZ6zg6AqOruDoCqO7RnLnNDnzJjM/7ejxW+6YC0/brNrw
9k32QEZ5h6tNeOsm7wxGahdhhYvBFMo3gB+pTeT2WxjRYCvGxO3CIo+cLSy2F5rvFJ5D/AibfD1t
H2zu3WHe9JMUUs9zIU/mnJHENmfKLhNtc7h/G1HWRpS1EWW6X2/zTjDR04Y8bURPm3cu2+fRH5ex
voX1j9h3O+M/XXM1NW/SNYuRZLxbVCm1huHgSrhXx/Fo5K2GX3UMh+3R4lJ7jLgUnqukxjA8VgmP
VcJjldQchr90PIbhpUp4qRJeqoSXKuGlSjHQMMMg0M0KMEJOlFei4Uo0XImGK3V0i8KsGYCEHv2b
0Xv2iJ3Ret6ReRD7rOaeq7nPau6xGrusxi6rqXc19tiskuxJsidJb9TLXvp/Rs1DzjLkLEPOMp+9
ypC1jHrKkLUMWcuQtcxnpDLkLfMZqcwwkqX/A5WQ9kX4xiVqHZa9CE+5RC22L9Pe4O//mK0Oc1aL
OStkl6qkfb5aZ18ALlRN9sVqjR1Tqzj6B/tS9SnnvyYCnNXM3vXsfZ897+GhF7B1IX6D77G3jr1p
c14He37BuZ+Y++o7faLva0ofUUIT9mSuuY5e9gbVxNZ16jVKDfYPVYvZmmdPoW79NkKLrU9E0J6k
NtjXoNfJ6k37WvWefT3lG9SvuWIp9d7Anh+qBu5+DXqbTBtvUD9jzxJqm4Q816mbqbGaM69DXl2v
lkDv17UwCrYf4p5khfbD4gju+aiqMN8JMdgdJ+a740WJ+4goNu8q+w3o/46y2d5sEff+xvpZ1pl3
kjWYd5EFzPtXW8zbVJdRW1S/mY1+9+dimP+2rWrzn7gz/zHb4owSuLtNxK31ospKs94oqoiCKqKg
ijPXMyLeKIqFLBjrvwF24A6/+TaZ9fZbW/+Hf+7uFnwLCfR9i8Wx4l5RI6Zzn5kiLp6jPA88D14Q
NVKIuLPZKnM+A5+LuBsUVe7+osY9AAwTs92D2B5O+VjKJ7IuERXu6eAKytM4/07wnDXJfck6MzhI
VASnWmXBu6ybghXgHjT3U1Hh3Y9MD1pl3kOgxprkPQweEzXeXGsS7S0vOFHEC84BE6ybCi4RVQVl
YgY6eKfg+0g9RPydNrwMXgELQB1YCF4XxYGRotgtBEeAIqC3jwbjkPBa1hWiGDtqG8a1DQsu47p9
rXXGDhVovEIOFRX2CZy9qx4hORrlCJ5AKcZ5eivGeVERdjaL6c5nYrr7nJgenAruEjXBCjTwoJju
PQRq1DLvYTBXLSuYgGWCXBHhrChnRfu8X3oC9Tn6L6HZU8GeCvbE0VaRsLPfPGfO6dninBjnlIvh
4ndcvwX8E3QBJaKBk8Ep4FQR1fdF0ojriKj7LXAmmAnuA/eD3wNaSit65fuNmoyuJqOrybQoQosi
3D3G3WPcPea1iqiR4Dzzrr0pSHFvjzdW4Y1VeGMV3liFN5YjQRUS1Bhv3B/vOwAMUx14YRVeV9Xt
dUhQgwS1SFAbvIec2niZqOLuVdy9lrvXcvfajGeJ2XhWOZ6l3wpYj2dViP24+3TuPh2fL+cu07nD
dO4wPbtmaqyhxpqeGh8jM9C1jqXWE2nPSWJ6QdS0T9+hos8ddMSX42nlRHw53lZu3nn4LG09xRqF
D44GY8D/ANRnfROcLDqtU8FpoAScDr4HzgDjwSUwxRXgKs69GkymfD24AdwIfghuAjeDW8AdYCqY
Bv5DRKw18M/HYJ1oQbpOpOu02sVsa4OoR8pOpOy0NrH936Ke2OiEo+rhqHpipNNeKFoCeFvgPFAK
zgcXgAvBReBi0Rm4hqi8DiBTYApAngDyuEtFp9uO5biHyz2Cw7HgIeAwvGA/Wl1Fq6todRWtrqLV
VbS6ilZX0WotbQXSVhn2pBakjSNtlWZRpI0jbRxpq5CyCikrkKSKO1ZxtyruVmXeYLASpuww71EY
YblqsnUwGA4OAYeCEeAwcDg4AhSBI8FRaqw1Uo0NnKYmB0rA6eB74AxwJhgHxoOzwNngHBBVk90l
4EOwEqxSY9021uuBUpOD3D84EAwFV6jJ9CdwJy2tcF/C/wYRI0UmRjRr54kRGRaz5WAwRMzujpes
WEn5rF3lHkv5RNYlePjpgPjR/0kBz55NzKRg5/J+MfMYsdTXw8uz4mcK3l2Ld5eLG8Xd2O4/4ZCf
w6rTwS8o/xLMFsPEE+A5MA+8yL754O9c9ZJh83LYvBw2L4fNy2HzcvEq++sNq5eLf3Dum2ARaABv
gfe4VxO96GrOacGXHay+hnW2Z/gegXZq0U4t2qnt7mONV4wU5QF6h8CdotihD3Y2ArzH6YT34ETz
NlMLHy1gXWg4YZj7VcoH4b/DKR/BviJAPfQy5e5x5u2nxe4JrDNvQK1yz+V64sMlPlziA40Pc+Mc
vxJcBa4GkwBxQg9V7l5H+XowBdwAbgQ/BDeBCo7/jPMqQTXbs8Cf4NwpMF0I3p0O0Dn9zfKet6n+
jXLmTapR7xXz9tQpBXBNwemAPKVgPLhMlIf/Az06SF2f26uJr4pGo+8q9B1Fx3H4Iq7fU4YOa5x/
mjbH3XHWfrS31j2bMgxLu6vIfoYgUxyZ4tTaSa31yKR7oBJq76T2euSKI1fcqxNxZIiLA6i5CgvW
Y0HNQPVYsD7bgiauu61IfGfu3qvtPFooyacFUcidon4OVuHnYLr/L6H2OLXHqb2EWmP9NBISvzVv
ka8Tn4FO8Ll5e3md+xvz5nL9tvI6Udjn72X+ICoGPAIeFeUDsJn+O5nQCFESOkyUh44QU0JF4GgR
DX1dRIQ0f4P2J0r7fKGnpJvV2OwnpYxGxjIaGcvo8EhiyuV4dfaokePVHK8WR+0kx1SZnnLrPDMd
npkCz0wxPDO1H9dMyeKa2XDNbL83nQ3XxEwWeJK4Xec/OX11uQghQQkSlFBjjBpjORmQzm6GiUNM
e/q3pSKnLTWGL/u2pSe/6JdX5GYAc8XTyHuFL+/0nNxivpE3ryRWil4qRxqk6M1yujWZh623wdKx
bUpyASwdgaUjsHMEdo7AxhHYOAIbF8HERTBxEUxcBBMXwcRFMHARDByBgSMwcAQGjsDAERg3QgRN
ycO2NbSmhtbU5MYqjDEF1i2CbSOwbQS2jcC2Edg2AtNGYNoITFsEy0Zg1yLYtQh2LYJdi2DXiM+u
EeK9hcgs99k1ArtGYNcIzBqBWSMwawRmjcCsEVi1CFaNwKoRWDUCq0Zg1QisGoFVI7BqEWwagU0j
sGkENo3AphF4pBge0eOFep9HNAPU6/dPw6ARGDQCg0Zg0AgMWiTCPXwCl6CFCrRQgRY0p2guiffj
kUP8eKvJ9Yyt+KSOrxrjFb2jrlz/TG0nQ52CV9T6mWlFz6jqQL/f3GHW1f0n/WOJsUhf9u3WWoZ9
e5m3GOYt1tozfc1g7ljSj33D8MxgMARorfUysdZeja+9GqM9jxFx3Q4x8UhGOTFGOTFGOTFGOTFG
OTEZtgrlYDDEKmTEE2PEE2PEE2P0G2D0G2DEE2PEW8JIV498Yox8Yox8Yox8Yox8Yox8Yox8Yoxw
A4xu9wv+lPI99DXTzbijk5Htfoxs92FkG/X+rHs962uMfGLYoR471BeQ3zICimGL5dhiecHl1iHY
ooXxYjcbaia8nGizzPu3AzkjuBJxhp9xxYnlOLEcJ5bjxHKceI0Tr3HiNU68xk0P/hbr7l48ky31
7cn7ZkBxYjJuevdMBhQnJuPEYNz0tyfk7/H7ZDpxcCVgZEIsxonFOHEYJw7jxGGcOIwTh3HiME4c
xonBODEYJwbjfkYT39kMIiuziROXmYzCMvMxV6OrqOG93uw0l/+ifjYahQOjcGAUDozCgdGsbDSa
jwvRa0WfbNQSQ9BxdCvZaA/b50YV3BjNykij2COKPaLdHGkizsImGZ6MGp48yMx3ROHKKFwZhSuj
OVyZnYlGsU8U+0TzcmUmC41uhy+jWVloNm9Gfd6M+Azwjs8A72QzADaKYqNoFndGRSg78nUWisTR
fhFvE/EruqNAHJivT+1hzuw+NJsttz6Oz/SfvX1nbb/xe8DMHc3unT8SJ3xZ7+11/rfhX517l/gW
nu5GsYier7pDHG/mrPB0rFGCNUryzF3V9owRnjbjhFrfSiVYqcSfy1rqtZhsOe7PadVw5sP4eIhe
J44uK9BjHD3GOVLDkRp0WIPuKjJzlt3zXPnnuLLmZMZm5rm4Krrdq+Zz1Xyumg+TRnuu+ibe0Clm
ilq4Xs8jdeIVnXhFJ17RCffH4f443B+H++PwfRy+j8P3eraz0PkcHnPMbOc7eE4nntMJ98fwnk6f
/+Pwvx69dbrTOPdOMJPt+8D9gCyfviBOX1AYvJN+4C76g0yfMIU+IYYV9KwnXmcVeg+BGuto+oaj
6Rtift9wNH1DnBa9WXAO+phAXwCXZvUNY/DAdjNfZ3ox3WPl9FQxI2luL9XdQ2WkKkSqwiypyk1P
9ZDprQ5BokOMRHNZ655qglWY00MdbXqoE9FvBfqtgDPj8GUcvozDl3H4Mg5fxuFJPTov7uZDPauc
zXs5o/C4b/Eqw29BpC5EnwcQscPBEZSLAOfBbXFaWUFEx4loPe7bbLjtCjO/G4eb4t3cZMYXmb64
ghZW9HhohpfqzbgQb/X5qbaHn8aaWdUqWj0Fbor7cxw6e54ijsHDKrBBBI+KYIcIHhXBoyK0UOdL
LbSwhRa2YJ8IHhbBwyK0bjmtW46XVWCriDuA9bdYnwmmUb4TzKR8H7gf/B48DqNOFcvx/3b8vx3v
0bG2nJYspyWdtKQT6TuxUwS+mo/X6HFPO/aKIHktUuvcoROpa7HBTNgxfw4UIAcKkAMF+uZAohOJ
O5G4yniXjovsPGga++8E+fKhW1VTtqcZL7sfZsl42ud+XnRIVl60n58XvUpOVEFLqrI8731aUu/n
RovFaL8lUb8l0d6WiE5034nuO/356z7ZnN+SaE5GF81qSfacdszMad+qlmGDTmInmhM7OsubktWq
7mxvP1pVktWqqMn2TqU/ybRqgJnzzo2nEbSqxrSouzVCLO/Tov6tqfFtUmJaMo3tO8Hv/ai+3zBm
rmQ9+kaqV3xd1xhdX8I4oAxk9LxcfH1bT1n8bKcoK9sZRv9XvpMjwXL9tMZEfL4nNrpf85/Y9ET0
dDMX847fb0WyMosSMyrTT3OO9z0k7ntIfCv5fnwrvh73mTTme0g8y0Oy+T7m871m1rjP9eU+q+Z6
Ri+z/hnbZHg+2yv287m+BRu0aK4Xjvkd3nzVkP1bOSFpU4BxjxCFYpAIir3FUBES+4tvszVOnCO+
Ic4Xk+kJbxV3snUX2WlMvC1S4jHRZoVFnTXY2ks0W0Os/cVq66vWd8Q66yzrbPZGrXOtva0Lres5
9iPrLmuk9VPrbmuM9XvrCWuslbRardOstXzGWyk+Z1lt1nquS1sbubLDUtYEKWXQulQWyALrB3Kg
HGhdIQfJQVZc7iX3sq6U+8h9rKvkvnJf62o5VA61JskD5XDrGnmoPNS6QR4mD7dulEWyyLpJHiWP
sm6WR8ti6xb5DTnaukOOlSdYU+W35YnWXfIk+V3rp/IUeYr1P+Xp8gzrZ3KcPMe6V54rS61fygvk
xdZMeam8xqqS18prrUfl9XKK9Ud5o7zR+pO8Sd5kPSZvkbdbj8ufyKnWf8m75E+tp+SvZJVVK38r
f2u9IB+UD1ovyt/LP1rz5WPyMWuh/LP8i/Wq/C/5jFUvn5XPWo1ynpxnvSVflPOtt+Ur8hVrsayT
r1nvytfl69YyuUgushLybfm29b5cLBdbH8j3ZMJaLvlYSblKJq0m2SxXWx/JVtlqtcqUTFlrZJts
s9bKtExbH8vNcou1TnZJZbXb0pZW2nZt19poD7ALrU32XvZe1uf2vvZXrC32fvaBVpc93B4ubftQ
+1AZsA+3j5COPdoeI4N2qX2ZDNmT7B/KfexH7Ufl1+xF9iI5zG6035IH2WvtLXK4rQIFcnSgMHCR
PDlwSeBq+YvA5MBt8oHAnYE75Z+cE5wT5GPOic535ePOqc735F+ccc44Odc52zlbPu1EnXNlrXOe
c778q3ORc7F8zrnMKZPPOxOdifJF5wfOFXK+c6VzpXzJuda5Sb7s3OLcJl937nCmyTedu5y75VtO
pVMp33X+07lfvuc84PxOfuQ86MyRLc6zznzZ6bzqLLMt50NnnT3E+cRZbx/ipJ20fZizyfnMPtzZ
4myxj3aUa9nHoJ4B9nGu5x5nj3FHud+wL3PHuN+yL3e/455kx92T3VPsq9zvuePsSe4E93L7Ovf7
7sP2j91H3dn28+5f3CftV9yn3Fq7zv2b+7xd785359uL3Jfdl+0Gd4G7wG50X3Pr7bfcN9w37Xfc
t9y37XfdJe4Se4m7zF1mL3U/dFfby9xWd629ym1zN9jN7ib3U7vV7XQ77XXuP11lp4JWMGSvDxYE
C+zNwYHBQvuz4ODg3vbnwaHBEXZX8PDgEYFw8Ngglgh+O3hOYN/g+cGyQFFwYvDqQHHwmuC1gW8F
pwRvDnw7eGvwtsApwZ8EpwVOC94VrAh8L1gZvDdwZrA2OC9wVvCl4EuB0uAbwTcC5wcXBRcFLgi+
G3w3cGFwWXBZ4KLg+8H3AxcHlwdXBmLB1gHhQNmAgwcUBe4eMHrAaYFfDLh4wI8DDw14YEB74KUB
nSHLGRo6NnSac1DoitC1zpjQE6EnnO+Engw96ZwUeir0lPPd0NOhp52TQ8+E5jmnhF4MzXfOCL0c
qnPGhepDrzvnhN4ILXHODX0QWuNcFmoPtTvXhjaF/tu5LvRp6FNnSuizUJdzgyc96dzqOd4A5zYv
7IWdH3uF3l7OHd5+3gHOnd5B3mFOhXeEN9K51zvWO9b5pTfGG+P8yhvrfdP5tXeCd7Iz0zvNK3Ee
8M7wxjvVXtQ716nxzvMucP7gXeRd7MzyLvUudx7zrvBudP7s3eH9xJnnTfOmOS94d3t3Oy96ld69
znxvuvdr52XvPu+3zqtetfews8h7xHvUWezN8mY573mPeY85S7zZ3mxnqfe097SzzHvGe85JeC94
850PvZe9V5ykt9B7zWn23vQWOS3eEm+ps8b7wPvA+biguOBEZ13BSQXfdTYXnF5wjtNZcG7BBNcu
KC2IuU7BpQWXueGCywsmuoXhD8IfuIPDyfBqd6/whvAm9ysDxUCb3Fee+A24XpzUMb5OTBDfF/+P
LWpZ73d3SW3gc4t6g5LGPRqqwz8+cTfffyZ4KM/+BpDIPk/NQqY5arzZ+sTI+ck2a97UU2rKYM8s
6mPQBpp37io1j8/HO3z+u+Z7w85Kl7eulP6YUkumTvURwMJq5RescUNf6frLqdK7S/qt3T9f7b1+
vdUrU7019NQxxMSA8RjVuo1r0/n25d/bV1o+a1RTt0+qjduTcqsSbNDyZ2LTt2iq51iq39mpfHt3
12Jq/0It6bZSHhtk2tTa7T39W9DNS3335d/b5wzspFapZT7/behpwU7rR03TnKSm9WuBX+I+e8zv
d3Tpy4Dq5Jyjk5WrhqjJpsxYB63o7wYxzGwv02UYo52t9p5rUmotjDzLlKvz3LEark5pjhPGltrK
fKp9fT+j6rREfDaYb832E7Yhfx01NVDjMlOfUCOyji3rjtat69lY+yVT0mz9D/D61u+2a4up/S2w
Zqeu6kALK7J8dEiec7J6afSxLNOaXV/MvTNsp7XzPHarA/Q4at12r03tdN9qfUEx9/iCFt7bk5nC
nl/UevUq9lv/JUvx0m6qJ8MVPVlgVim/3+eJmT2xaL7L8JC/FHHnYtbF/c5c0fstimGpFZr32DOL
UpPerxlUsx+LZ2aUus/OqSdr77C+tfecsZjPTHV7LxsT10/w/fc89dWRSzeYzL5hO21t6v3OLqkJ
qpFvjfEZ+Ptnbru+nV3UBeD6rcmVtT3W/0zcTn26n1hlStPguH8Y/pqphquf95wxbRclfk09rh73
y2kVVj9XJ6salWfkqH0oS7Nf93FyRk7D7/8XcVFu5kTWVqde2Vb+/K9YsseQZnsbGWo/n2pQc7cX
Ib3t03Gm/r6n2tvtDerFbZ6V6s70fO5shWl+txN3edV852GgXVlUrZ8Rabb4aNtt6NW2zzxfV3tn
4iI/F5mR7KCey4eI7F6gaHe1wF/292v3cmTuliiT5471z/XlgJMGd23RPNadKWcx9DR8rK/XDYHf
M/VUww+RrWTXJq82Z3Tftclk25nx0hzz3TsSbDJ6TJm6dV9VJHL6ykw2aRad8w/uLmX6GvqKYv3t
n5vOfOcf6f6rlm1n18rN2Z7Ule5SapIpr+v9zpS23g4zCtLrRXmOLdJ7GUOu6rvXX69Va/tdcUrO
dnufrbrsrKJrG+3zLbAhe1ttVJvIAfwRrKrPYM8sZrT2bp79Wxk795+FybBkN1eiw1b1jilpL16Q
GVOoB43fZtqqSx/kqfmD/Hu75eFjxviqJTOG9ff+mfs9Qq78XL8r53SPMXvnRQ3MaFGtVh/q7/yt
9Gto6SmtMfy7h+ZbjI52el5BXaKzC3WJKa/s/e4udc8LfpmL8a4+WVGfo8+bjPn5narxS+SpPFlF
I6x/r+4Ld7Ke3Wob9Zuc7VXbODenv1ZXqVP1tyn/1Xy/1HPsryZOth4jw7Z6ZLcuxkvm9GyN6OnN
TE5An+yqwf6c3Uzy1OrMR4/g1GT1R/VLM9v0DFvPZFiZ7XnmWIYXxue5Yx2fZWq86a8jZs89Zp8Z
EamJ2G+Z2TONT5PuTemTV/m112VL6197MteMYG3u2WfGK2eEknny0Pv8QZcM9zV1z4vrGYE9Nyuw
1dn3XRi9qKT5nmeeSnSI3fgMx9fMsuxoMiPxvJn7HuPv7T6Z2M71rzDWyDOy3+51DT7qdu3+fm15
RlNkInn37o777b4FBsjk4oPzHNMROosz7sFKRdov2J5BHN7tXzkLv9Tn3MOnerszDjO7Z0j8GfYs
7tjluYZdjAgiYQWfnWSGrJFF3a76sZj9Ba7Id83O1jM7C194IYfUzLpp+2eKvXZzFjIsZ6z7JS5k
uSt295zBTsvwyVbmTRcL87y1z97F2dtm3jS1Y9nVv++cHG34h37y9P/hEvex68suclGPDb4ULjIS
7Gp/8J56N9/IfjtXpXrGyXV6hLyrS75IzMRn7pP9nl9v9O4fYj47vuwsg0Z28vzcZZgZhRRvs57i
/k+SduOyJ+v+d1mqduCcaJ8tM/8kSnbDfbvxhRd6rQ/FMP1UPs+xpt5ZMbOd+e3PbuqT1Nh/o6yi
I7ff3uka2ndRhGFI8FGeej8yTzFys4o8Z36xu5rnC7tsgwyTq/bMM52cY6/qvfhZ9wxsZj7WPzN3
TnsH7tUnL1InG+l3eaZHva/eNzl2nidwqsHMvvfYwJ/b7Z59X72LnnPR7mnBNu+R17vz/XJtB+vb
4ZmKvr9SQ78b9O9e9JwZpVozmzNTXdf7JF9NZH9LnnpatrK3pw344HtkRY+rR9Qj/p616hL1sLpZ
/V39r35X6l81NWc9AZwIxome36up1tynuWbZSqT0/CZskP98cFCekwblPDsU+c9Ua3p+KZjMREuP
9vrPGnn99nTXcmTXFuX6s+/V5omE+dZzkpRe9X/T1dq3VkY2E/3f2eWbdZzJp0ndYmYzMnOb+nfF
MzNzQ+zPzF02kJmZb7YOzGc1v7YG9XWuHq9/A2i2B2cdm2c84Tjh/wbcfzLWay09q/ThNvK/f9XM
b1327BY92jD/iWdGO9/uSnelfRs8ZfTyN/WCesHY4FdGd8sytu6F8aMf+788vDLPHWeZp0Z3c+2G
TFahnqA8x38Oe4f5RaWe+Z3Fp8H84v0k8yy8z7P6ntpmov9Z5vyHzNG9s45VG5ueIfynsWp573d3
SSUzc6d5l3+VDRqyW0X89p19/4EaofZXPzHlv+lff/Kt40A/7Z6j6mGMJnr/7meZqZ7s/37/11N3
5rmjttxH6jfGSpnZ9/rMr0ZN+Zf+8/EGf5Ze+8jZJtI6RJ7f/fbM1Nf5M9BHZh3LmTnVvxHp/u4u
qU07NCe0R5e+zxO2eWb234AMMa03T0bxwsXkAotzYyrr7Jx6/g91VwJeRZGtT1Xfrr5dNxsQQiAJ
JCwhQAKBhC0kLGHfd2QTEFAREXkKroiKuI7jgspdc1UeMso4go4iIm64DCM+dXyI26jsoIMoiIgI
ue+vk4AsYVXfvNf1pXJyurqqbnfVOf9/c7rqJNrD/3et+N7949hy8w1q5VljTxefeFf53EqOj5hD
p41S+/92VN7xNzDazYh8M/bRSUv+Yl9XwvquxD2sEmfG3ovlnXtfYPVNbPYmtlrcH/x+M/bmKa+r
fGKVlmjxGbVV8R+3k8UJrKxaf9paF9Mv/0XbWdEK66qwE7/2MDGTxx3NfsnPfM5VUTOuNf9prQqv
n/baivF0Rgjw3BHmKWvdedzvdyufxRn8nxuoYRl7us+riuaoLHM47nTsEfxxDOeNjav8vbEqlHQm
B/vOfpgDZh48xPON+4PffzvldYdZU8X/k045Z45cU1H2JKz97GMDKq97g478b48Z6pyK/vwe86DK
9mshu4GluN+46nFHtbLsyHifijQBPxUWSJWvK98BdKSq+p/emR6xuPJPKp4hLGoVkXenvf6Etk/e
n6P/p89/jyg/aNBSRazg/53j5P05/n+feAY7ytdhFqny735Fe3GHxw/swrhTl63qOLHtk/enimew
4//3M/jlKP83xl5XFb9YdX+MRf9tDuB/E/myx7y1fMK5tfwu8/Zj+frhkpX8YtOZf4/KeONknlrS
LPKQ8UMDaCD1psF0M/WlW2g+zaYHaQWvbv4uPU3/oB30Fn2N9AXtRPqSdglJG4Qt4ugHkSiq0SFR
Q3QSJPqKASKP1wdpKYaKaaJATBe3iP68MsgksVFsFTPELhETs3gFkNt5BZA/8gog9/AKIPfyCiD3
8Qog9/MKIPPN+hTiAesrz0jxkGeM5wppe2Z6rpIZnhs9N8lMXnWivt3R7igb2J3tHrKh3cvuJZvZ
fexBMtceZg+XBfYoe5RsbZ9vXyHb8LoS/ezr7AVyoB2ww3KaHbW/lTPMahFytb3X3itft/fZ++Ub
Zs0I+TezZoRcoyxlybUKh3xHaZUh/0vVU83lRpWv8uVus4qE3GNWkZB7zSoS8ifVW/WRP5v1I+Qh
dYG6wPKpSWqhFacWqUVWP7VYLbH681oSQ9TT6mlrmPqretYarp5XL1jnqRfVi9ZoXldijHpVvWaN
5XUlxvG6EuPVO+od6wL1vlpvTVQfq63WJbyWxNXqG7Xbuk7tVQesG3kVidt4FYk7HZ+TYM13qjnV
rQW8fkTArB9hLTbrR1iPO+2dcdZSs3KE9aFZOcL63JnuXG5tcK50rrQ2ObOcWdZms36EtcW507nT
2q7H6vOtHWZ9BOtrsz6CtdOsj2B9Y9ZHsHbpe/S91m79gF5gfa8DOmj9qCM6Yv2kn9PPWQf0C/oF
62e9Sq+yDprVEKxD+k39phUzqyF4yKyG4JFmNQSPx9fKV+Cxfa19JR7H18XXxZPk6+nr7anm6+sb
6En2DfYN9tT2DfMN99QhKX7ECPZQB7KRLFJINjlIKeRFcsjlZN5Z8iHFIcUjJXBK4u/VquN3EvTV
kJLxV3VcWwOpDv+HLoVqIqXjdwr4ei2kEkpFyqTaSJ1Qqg51oTSkriiVTvUpA8nE8TVGr3KoCfrQ
lJqjVy0oH3W0pPbQFKEWH3WkXmi3N/VBX/oiJWEu9kP7ZjZWx2wchvaHA1Ok0HgkhybQRLQwiS5G
T6bQVNRxKc1ET2bRNejDtZi19YFrbkTrNyElYzbfjGtvQWpE85Dy6VakbLoNKY9uR8qhO5Ca0J1I
TekupEb0B6Q8zP27wRX+iJRL9yDl0b10H87eD+uQD+vwILWmh5DM/iMLqC35kfIogNSOgkjtKYQ0
mMJI7SiCVERltBg1/IkeR7tP0F/Qk6eQGtNSpDxaBouTA4uzCj15iV5GyVfob9Cvob+jJ2/TWvTk
HaQ8+i+kxrBM70L+B32Ikuthk/JpA1IObaTN6NsW2Kw2bLNasM1qS7voR5TfTz+jbwcpRu1gryQV
wYrZlC+UUCQEJg3GlFd4ySNc4VJNoYUmJXzCR14RB3unYe8SKV4kCYweUQ22rxpsH8aLSBbJKI9E
tUWKwLgRtUQtShOpIpUyRG1Rm+qKOqIO1RNpIo06inSRTp1FhsigUlFX1KUsUU/UowYiUzRBT5qK
Zmg3V+SjJy2F2XWkQHSAplh0Qh/6in7oQ3/RH30YIAagD7C5yIeKEejJeWICyl8gLkD5iWIy+nCh
uAR9mCqmoQ/TxVXow9XiOrR+vZiDdm8UN6PduWIurr1F3IJrHxaP4J48Kh6lJmKh+E9qJBaJxyhP
LBZ/ombicfEE5Yol4s/QbBQbqa/YJDZTN7FFbIW8S+yifuJb8S0NEN+J76i/2C1200CxR+yB/nvx
PfR7xV7ofxA/QL8Pc7iv2C/2U0/xk/iJeosD4gD1Ej+Ln6mPOCgOQn9IHIK+XJRDHxMx6gP/Iam7
tKRFPaRHeiDb0oaspILsSAcyvAu1Mt6FCox3gQzvAhneBTK8CxUY70KDrK+svdTB+sE6SI51yCqn
OCvmsSnFozw+SvXEeeIp05PgqQE52ZNC9T21PPWpkaeBpynleJp5cinPk+cpoHxPoac9tfQUeTpA
U+zpArnU043aebp7BpHwDPaMJAUfdgHV9Ez0XEy1PFM8l1A9z1TP5ZBneK6gLPi2mVTimeWZRW09
V3muorpmdSXUdpPnJmpuvB1ZxttRCrxdF+SldleKs7vZ3SB3t7uTY/ewe5BrvCB1ghfsg7N9bdgW
u5/dD3J/uz8lmzWZUH6gPRCaQfYgqmM8JZUYT0kN4SnPRz7OHkdF9nh7PCWYVZqomX2BfQHkifZE
yJPsSdTBnmxPRg0X2heitovsqZRpX2pPg/4y+zL0ZLp9OfnsGfYMtP4f9hUoM9OeiZpn2bNQ81X2
VTh7nX0d+nO9PRtX3WDPwVU32jehzpvtuSh/iz2P0u1b7dtQ8+327fjsd9h34Oyd9p3oyV32XdD8
wf4D6rzbvhs1/NH+I2q4x74f186351N9+wH7AegftB8k237Ifoiq2wvsBfikATuAa4N2EDWH7BDK
hO0wro3aUbT4sP0wrn3EfgT6R+3/RMlF9iLU8Jj9BGpeYj+FkkvtpbjPy+xl+BRP28+jVyvslfik
L9ovo5VX7NegWW2/iU/3lv13XPW2vRb3+R37PdT/vr2Oiu0P7Y/Rk0/sz9GHL+wv8bw22Bupi73J
3kxd7S32FvRhq70dn26H/RXq/Nr+GjX8y/4Xathp70T939jfoMVd9i6U+db+Fq0Ax1C+wTHI99n7
KM/+0f4R8n57PzUxmIbMOlhEzWDwBOUbZENtDbKhIiAbjdyn4nA2XsVTI5WgEihPJapElExSyZBr
qpqQU1QtnE1VqZSjaqs61FSlqTTKVekqA2frqXqoIVNlorYslYWz9VVDlG+kslG+scpBPU1UU5Rs
pnKptcpTzaEBlkKZAlWAqwpVIeQ2qj3KFKkiamdwFeTeqjfK91F9oBmihqDMUDUc+hFqBGWr89QY
1DNWjUcrQF3UBKhrElo3a0k3UpeoS3F2mpqOfl6uroB8pboW+uvUjajhJnULap6n7qA26k51N+7J
H9X9KDNfPYC2HlQPUXu1QPlpsAoo+DgVVGH0M6IiqKFMlaF8VEVR5mH1MM4+oh6B/lH1KLVQC9VC
am6QHzSLFTyg+pP6E/rwuHocNTyhnkD5JWoJ+vAX9RfkT6mnSBpcSDUNLkT+vHoe+Qq1gjzqBfUC
eQ1GpI4GI1IiMOKrVMOsQIYyQIpU2yBFqmuQIjUwK5Ah/0B9SPFmHTISZh0ylPxEfU711BfqS2g2
qA2k1Ea1ibTarDajzi1qK8psVztw7VfqK+i/Ud+glV3qW5T/Tu1G+b3qB5TZp36kNLVf/YTaDqgD
6PkhdQh5uSrHtTEVI+NUPVTTsR2bshzlwM86OMjjeB0vVXNcx6W6ZrUzkk6cE0f1nHgnHmUSnARS
QK7VKM2p7lTHtbWcWtCnOsB9TpqThhrSnUzUnOU0RMlsJ5u8TmOnMWmg25aU6LRyWqP+9k4x1XBK
nM4o2cUppdpOV6cH6uzp9KUMp58zEK0Pcoah3eHOCOronOeMpM7OKGc0lTpjnDFod6wzjhoAJU9A
yQucC3B2ojMR+knOJPRnsnMhWrnIuQg1X+xcjJovcS5B61OdqbjqUudStAtUTfkGVSMHqqZCoOrZ
lOfc4NxAjZw5zhzogbApzyBsqgmEfT3k2Xo25RucjRw4G5rb9e3UTN+h76BG+k59J2RgbuQP6AdR
5iG9AGWAvKm1Qd7UxiBvKjTIm4oM8obmNf0a8tV6NTTA37gW+BvXAn8jB/6mfODvVpTjK/DBowGF
t6Ymvja+ttTI187XDpr2viJq7evg60BtfMW+YmrrK/GVUJFB6ijT09cTZXr5elGer7evN67t6+tL
ub5+vn7Q9PcNQJmBvoEoAxyPGob5htFg33DfcOBDKccxmu/GOD6JUXtSJV6vzjjdIPIkxuLdGYv3
YCxek7F4L8bifRiL92MsXpuxeDpj8W6MxS3G4kmMv5NQ1iDv4cDWSYyquzOq7sGouiaj6j6Mqmsz
qk5nJJ3BSDoTOPp2ymL0nMfouTmj5wJGz/mMns2K8fdAY3BzIXDz/Sg/H6ktPYCUxRi6kDF0EWPo
YsbQJYyeOzF6nsDouTOj51Kg5zJ8kihSBj1Mj0FeDCSdAST9BGpbQn8GSn4SSDoLSHoZsPLTSFn0
DC2H/DywdRa9AHTdgl4Ewm7OCLsACPsVMJJXkfLpNXoT8ltI+cDdf0Pf1iDlA33/Hfq3kQqAwddC
/w6QdwG9j1QA/P0PaD7gtXbXIRUCi68H8v4IKYs+pn9C/hy4PAu4fCPObkYqBDrfgk+9lbaBI20H
Ui+ir4DU8+hfQOrFQOq7wI2+RSqh7+gHyPuA3UsYu3cCdj8ItnMIqTOVA8d3EWapllIhgeZLhSUs
KmRMn3kUpvcxpk8EpgcLZByfKOJFAuQkYHcfY/dExu4+xu6JjN19jN2rMXavwdg9mbF7T8buvRm7
92XsnsrYPQ3YPRN4PUtkod36IgdykyNoXgLN56LmPNGcHNECyD5RtAKyd4HsC8AuCkUhWmwt2kMu
Atb3AeuXAOt3BOJPFJ1FZ4oTXUQX6EtFKdB/V9EVcjfRG3If0RdyfzEI+RAxFPkwMRzlR4AP+MAH
zkM9I8VI1DNKjIU8DtwgEdxgIs5OBkPwgSHAiomLxMVUXUwBW6gmLgVbqCEuE5dRCjjDdHz2y8VM
yLPAH5KZP/QGf7ie6ojZYjbuwA3gEnXAJW7EfbgZjCKNGYWPGYUr5ol5kG8VUepqvg2qZA6jmTkM
YeYwmpnDGGYO5zNzGMvMYRwzhzHMHM5n5jCWmcM4Zg6jmTkMZ+ZwHjOHEcwcRjJzGM7M4TxmDiOY
OYxk5jCUmcMwZg5DmTkMY+YwlJnDMBkn46idTJAJ1F4mySTI1WV1yMkyGXKKTIFcS9aiejJdppOS
9WQ95NkyG3kL2YJqyQ6yA/KRciSNkpPkJOST5WSy5cXyYuTT5XTks+Vs5PfKe2mADMkQNZKPykcp
Ry6Si2iQfEI+QQ3k0/Jp5C/KF3H2JfkSzq6Ra6ipWTMW+Tq5DvnH8mMaLLfJbZB3yK+oidwv91N/
Cwc1NOvBUrblWi5ybWlqbMVb8TTQqm5Vp/pWHasO8jQrDWcbWg1RPtvKRhnDi8ZbHawOVM+abc2m
rtZN1lzk86y7kL9gvYDcsKZuYEc1wGcML6oNXlSLMjypYEd1wY4agM80BEfKBUdqBi6UC6aUD6aU
B31z8KU24EutIbfxtIPcHtwpC9wJttnTAQyqIxhUCeSOns6QSz2l1NnTFWyqC9hUd7CpHuBUHnCq
weTzDAGz8npGeUZRvGe0ZzQ0YzxjKNEzFlxLg2tNgjzZcxHki8G7EsG7plCy5xKwrxSwr0shT/NM
h3w5mFgymNgMML3/AB+rw3ysB/OxYuZjNTyzPXNQv2Fl+czK8uxOdiegcMPBkph9Jdg97Z6QDQfr
xYwrAYxrIDSGZfWwz7PPo5r2SHsk1WbGlc5sqhvzqCTmUTWZR3VjHmUxj6pgUEnMmpLsa+1rUadh
Td2YKSUxR6rJXCiduVA3ZkFJzIJqMwvqxiwoiflPD2Y+NZn5dLMjdgS1ldllOGuYT21mPt2Y8yQx
w0liDpPEvKU785YezFtqMm/pxbylD/OWfsxbajNvSWdmkg5OshcM5wf7B8piTtKGOUmWfcA+QAX2
z/bP1JaZSYEds2NUaJw/ZTE/yWR+UqxsZVNnZimlzFKywFJ8VKDiwFUKmavUZa7SkrlKG3CVJCpR
1cBYOoKrpOJsbVUbKLwOuEoL5ioFzFWymKu0Yq6SxVylBbhKfdTZAIylLjOWXGYsLZmxtGHG0pIZ
S0dmLAWqpWqJaw1vKWXekqFaK4xqZi9tmL10UR1UB5QsVsWouUSV4BN1Ul1QplSVggN0VV1xbXfV
HZpeqhdyw3MKmed0Zp6TwTwnk3lOLvOcLOY5uWqCmgDZsJ08ZjstmO0UgO1cAi4xVU1FPZeC+bQE
87kCesN5CsF5bkDf5oD5tAXzuRmauWouytwCFlQIFnQrenWbup06qDvAiIqYERWDEd2Lu3ofeFFH
5kWdmRd1Yl40gXlRZ+ZFpcyLCpgXFTMv6sS8qAvzogzwooXorWFEGeox9ZjZEwaMqIAZUSkzos7q
SfUkerJULSWfekY9A07yV/VXcpkLJaqVaiVyw4J6MgvyqVfUK5QMFrQaesN/aqi31dvQrFVrKZW5
UBq40Pso+YH6APk6tQ55BSP6SH0EdmR4kWZelHwUL5LgRRtR56Yj7CgO7GgLNFvBkTQ40nbUU8GR
vlZfQzZMyXeEKX0HtrYbfMmn9qjv0YphTZpZUxyzpmT1s/oZ8kF1EGUMa0qrZE3kEPmYO2nmTqlH
cadEZk01jmJKPifJSYLeMKXUo5iSj5mSZqbkA1OqD47UAHzJ5zRyGkE2rMlXyZpynCaQmzpNKc5p
5uRBbuG0gJwPBuVjBqXBoHpANtypGnOnGsydkpk79WTu1Ju5U1/mTqnMndKc8c54XGUYVA1mUL2Z
QaVWMqiLwZd8zJfSnMucyyBPd6ZTpjPDuQIsa5ZzFXLDkbKYIxU6K52VVMvZ7XwP1nfQOUjK280L
PuB9w/spjfJ+5v2JbHeSO4mUO82dhnyFu4Jy3Jfdl5G/5r5Gg9zV7mpq4K5111Ij9333HzTA3eZu
h36nuxOab91vUXK3uxssC2CJmmpb2zRYu9qlAl1L16Imup6uhzxTZ+FsU90MZ3N1HuRWuhXyzroz
1dfddDfK1j10D2qse+veNFD30X2gH6qHUkOz7jT115P0hSgzXV+OszP1TOiv0ldBc7W+Glddq6+F
xrDBLH0DeGCWnqvnIp+nb0Vu2GAJGOA9yO/VYBl6PnhgFhhggNoyAyzSi/WfqFQv08ugf04vR/6C
fhH5Kv0KFetX9atgjK/r16mrXqvXQr9er0e+WW9Gndv1duqsd+gd1El/pb+iUmaGJcwMM32FvkLK
Yh5YxDywmBlgMTPATGaAWcwA83x9fH0g9wUDLGAGWMgMsK1vkG8Q5KG+odSZeeAE5oGlvhG+EZTh
O883Cled7zufWvom+CZQiVnvmprG7YvbR03NqteUHW/H25RNMi3frH2dsab+emoHtvB/4IjtrIiV
O9d1qCtWrThOx/E2x6w2fX9scWzW4dWmj9LviX0Yu/Xc2o5tjd16grJJ7CP+T/LmIzE/BRz1bt4W
Nyu1mHccKt/1+feszILWk/lzn2vryecab3auUVDH1bLoDMrs5ChU81MZhxnbbtYsO/Mazv345VMe
jtqOBX7P9k59xGbR/9JqOcev0AXNFLOqDD+Nc+4Bz5enTtBWxHMdjjhedHQcSsWcjCXHevHvXufy
tGNjY2NpSKzEXH/cmQLOQ4f7FGtyTCS5Pl3sy9ndCX56p1qv/IR7/lu2fty1J41oPqMjGRZn4/Gf
xVhoXnfuk1O84fCrjljW4XZ+sxrPOBKy/JNy8/mGHR3rbuIcy3dxDOqVJjb1hNozfyl3RHf7kRrP
0oKejY3/ja2Eed47qxq7FW92Hz+afm3rxz7h3/J5n0Hb7x7t2TCWj/6rzxHpPX5D6DfuWez+o8cH
a24/Wdnf+sAn6oNxfGQ+xHbFIsfOjsN34rfx/Ce0/wkdvSLY9jO7u/wUVp3i/AnY4STl3jdv+x35
6x+cn2btnAoUElt1svciTsQOp6nvLHb3iI2uqq1f2jnt2ybDKsuZu97MxFKbKPrDdzy2FD+1+H3P
+2HX3jv2icNLZlRK5n2U92J5jJFNuQrsn3Tmn+M3P648XQHM6N/Lnpzxyg3lZ7UXzRnVeNp3c45d
zZo1/0sr5Zxm5h3X89jLZ1n74XXOz+jNjpPW8m95I7DCn4BdnvV4KN//q9rlWWK8TcXvX/NeVBW1
nxX6O9nKVFWPmqPWNjuH532URX7v9/Fip2ib7/ZhHwN7+6vG6wm1n8E9P/JOfOV6AlWU+Lwq21jx
nQ7/nGOfKz/7OVje2LBza7Hy6l2/5upff1SuaH0GazZVes5f/HfFGh316IinPsuj2TG1V/HGxe91
nL0tO6vafydmyXWfMM4P8/8Tv7P4jVo8sm75ab9pmHDc3x9VfJ9wTq2e8fepv7RtmPfhucjfsi4+
HoFS5brCp/6G5oTvU4cd/X3qGfT9mdOXOem1y87xuorRkIy+r6jqPWrozdM45RvWQMo3ste58Wz4
U+zK2Cfl91d8TxALm79+YYTlhiu2jl1ZFRI4rKv67bzyE7/nPovjKA+89vR2pXJVjlO+oXsWbf/i
v38/FP87H1XtVfC7t3nYrv2qJ/8r+/D6v6HRw3t8VNxzSdM5bolkPZlJwuyrTRZHL3nMjtpky1yZ
WxnJ5Jh9tckr28sOpGU32Y3iZX/ZnxLkQDmQEuVQOZSSOM6pmhwjx1B1OV5OphryYjmFapt9tSmN
o53SzY7alCFnyplUV14tr6Z68jp5HWWa3bUpy+yuTQ04FipbzpfzqbF8UD5IOWanbWpidtqmpvIR
uZCayUXyMWouH5dPUL78s/wLtZJL5VJqLZ+Tz1EbuVKuorbyZfkyFcnX5evUQb4l36JiuUa+TSVm
v23qzLFTXeR/y/VUKj+Wn1AP+U/5OfWSX8qN1Edulpupv9wh/0UD5C65h4ZwNNV58mf5M42Uh2SM
RpmdtmksR1adb3ktH42z4q0EmmhVs6rTZCvZSqGLrFQrlS6xMqy6NNVqYDWiaVZjqzFd7jznPEcz
nOedlfQfZvdlmmV2X6arzL7LdLXZd5muMfsu07XOdudnusFre+Novtl3mULeW7xB+rN3ifc7Wm32
XRau2XdZVDP7Losc9yl3qWhpdlwWBWbHZVFodlwWrc2Oy6KD2XFZlJgdl0UXs+Oy6Gp2XBYDzY7L
4nz3e/cHMc790S0XF2ihpbhE2zpOXGp2WRZX6mSdJq42uyyLG3VjnStu0210e3G32VlZ3Gd2VhYB
s7OyCJmdlUXU7KwsHtEj9RixSI/T4wXvrCyW6Gv0NWJF3Ka4reIF899c8VJceVy5eM38N1esxrj8
iMel5Hg6KTMxOj08Oiti6ySPTsWj0+XRqTE6C6FvjTHqwRhtj7NFR0ZqIY/UZjxS2/BIbcsjtTWP
1EKM1PE4O0FOhN7E6LXmGD3BMXpCTsEItngEV8TrCR7BNo9gL4/gXB7BDsfxCXkDxrGFcXwzyszF
aM7l0dycR3Mij+ZqPJpr8GiuhdH8COaSifirLRdiZLfkuL98+RjGd5rZTx65iQGsiVH+Z+RPYqzX
4rGeyGO9mtlbHrW9iBFfk0d8Sx7xdXnEZ3KcYH2zzzwVyLcx+pvy6G/Ao7+R2W0euYkfrCc/lB9i
1q3HfMjhWMJW8hPMisZmF3rkn2NuZGFufIl8A2ZII54hmRxpWF9+jXnSxOxIj5q/ld9RQ7lb7kYf
9mDm5PDMyeOZk4CZcwiWolyWw0bEMIsyeBZV51mUglnkJR9HKcZxlGKq5cO8SudYxRZWAmZXHbOb
PXITt5iMOZaMvCZmWgrPtASeaUlmZ3vU2RDzLZnnWzrPN4X59jzyFZh1mmddM551zXjW2TzrbMy6
fyL/HHMvl+ee5LnnwdwrJuUt8ZaQ6+2Ieah5HhZiHj5NzbzPeP9KbbzPel+nthyB0tr7GeanMPOT
LMzPNmS7bd125HXbu90p18xVkmZ3dEpzl7pLqaaZsZRoZizVwIxdgfwF9wWcXemuhP4l9yWK5+iV
2hy9ku+udt/A2TXuGuR/d/+O8mvd9yCbSJbm7gfuf1M1d537IdVy17vrcfYz9wvIX7obqaW7yd2E
kpvdzah5i7sF8lZ3K2QT/5Lv7nB3QAOLgBq+d7+nLHevu5cauT+4P1Cm2Y+dCtz97n5q6v7kHqQG
7iH3EDV2y91yyoTVEFTP7NNO2Rwv00or7aXGHDVTV2vto/pm53YqMDYF+mRdE/oUXQv6VF2bGuk6
ug7Opuk0agpbUx+aBroR5cDiNEb9OToHVzXRTSCbiJtWOlfnUhOz0zvV0W11W0rW7XQ78un2uj0l
wDZ1oOq6WBdThi7RnSF30V1QslSX4mx33Z3iODYnlWNzWug+uh/ODtKDkA/Wg1EeVgyyidPJ06P1
GEqCLRsH/Xg9HnVO0hdRir5YX0LpeqqeipKX6ktR8zQ9DfJl+jLIJq6nhZ6hZ0AD20dJsH2bKCdu
c9xWqgULuBvynjjcYWMHyTGvOlB6vIi3KIUkbqiJkW7DMdJ5HCPdhmOk23KMdHuOkW7HMdJFHCPd
lmOk23OMdDuOkS7iGOk2HCPdkmOkCzhGuhXHSBdyjHRLjpEu4BjpVhwjXcgx0s05RroFx0g35xjp
Fhwj3ZxjpFtw/LP3GHt9oqWuQBAmFtqRJbIEtqNUlsJ2GOucL3vKnrApxkY3YBtdzDa6pNJGj5Kj
UH60HI3yxl7ny7FyLMqfL8fB7hjb3YBtd8kxtvtCeSGs8NEWfKqcesSOT5OXQa6w5pfLGZArbPqV
sOkW2/SG8np5PXzJ0Tb9RnnTMZa9oZwn56GMse+N5UPyIUrh+O0EtuzV2LJXY8tegy17U7bsTeRi
uRieydj0OI7rjpPPyGdQ0kR3J3B0dw22403lm7DgaWzBM9iC58q1sN1p8l35LrzFe/J9yMaOZ8gP
5AeQjR3PYDtel+14PbbjzdiOp8lP5afwHJ/BmqexNa8jv4A1T5MbYc3TYM1hBeRWuZVSOYY8gy17
uvwGNj2NrXkqW/N68nv5PTTGpmfLn2DTE9mmJ7JNr2nhFlEix5zHWx7Lhmwse5LlwLInsmVPYste
nS17Mlv2HLbsiRYSuVYS7Hsi23efVQP2PdFKgX1PhH2vjdxEqvs4Uj3JqmvVg8bY+kSOWo+3GsHi
J3LsenW2+8kcwd6BI9i9TnOnOVnOs86z8AHLneXITQyh47ztvE0NnHecd5B/7HwC6/+Z81mlD2jo
bHA24KrNzmbk25xtyE3MoeSYQ8kxh453ovc6auS93juXMtkr5HtD3hBlecPeRVTf+5j3MciLvU9A
Nt6iAXuLYvYWJUe8xU/sLZof4y0s9hYN3R7uRPJwNKPkaEbJfiKFYxpruKvcVbDUxjfUYN/QhCMb
49zX4SE0+4YUjnJMcN9134XGeIjG7BVS4BU+x7XGKzRlr6DZBzThGMgEd5e7C2dNJGQNjoRMcPe4
e+Ab9rn7kBtPkAsfcADyQXiCOvAEMUrjaMkM9gF12Qc0gw9QkB14glps/XN1vI5HyQSdQLV1ok6C
XA3+oBbHVaazD8jVGbou9CbGMp1jLDPYE9TT2TobJRvDE6SxD2jGUZcZOl/no7aWuiX0JgIzQxfo
ArTbWreG3niIRPYNibpIFyE3vqEmvEJHyCZW0wff0BWyidhMYq9Qnb1CDkds+nRf+AZX99f9UcZ4
iET2EDX1ED0EsonnjNfD9HDII+AzXPYZ2XoMfEYi+4ya+gI9EbKJ9kxin5HMPsOFz5gGvfETORz/
Ga9n6VnQmCjQJI4Crc5RoPEGNVO1uO1x25GbSMgMjoTM4EjIJI6ETIovji+mtPiS+BJKJOF5w/M2
CYqj6uYFqYcCcqS/qX+0f47/g0C3wFh/JDDf/3FgSWBDYE9ABqYERwYn+7cEZ/jz/QP8E/xzAgnQ
TkSpm1CiPOjBX2PDd4ej4eXhd8P7I/UjzSM9IpMjcyP3hNdEnom8HFkf2RtZX1a9rGFZfmRT2bCy
0eFtZRPKpuGaAK5Zh2uGRKZGZkdCkUfw88/IjoqSkZfDn0b2ls0JDQuNDi4OTQhdFJrmL0VfIqE5
oXmhu/yjQ/f584N34MwC037ZwrLHw/vLpkV6lD2L9u8J321aL3sVbb+DHiSV5Zd9XPYF2t5S9rW/
aTAUKg594Z8T+tq/MHQw7A0NCGeGs/2RcDd8+tH+YnziycFngk+GZyJd5x8Qvim4I3B3+LbQx+ER
gQ3hOuFWwWdwDzqi5WXcdml4fzQ7vCbaLtotOhEt96hoN7wc7aZG30W7cdF10Q3RbdGd0T2RNyKh
hz0P62hmdAlKNDT3KzozelN0GUqtjqyPrkHdEjUUB/aX5fsbovwbkbcDdfzT8Hz2BRYFxgbu9i8M
7A9OxXN5y78ysNx/n/8Df8S/AH/PCYzFU2kVuM1/UWAD/v7OPy/QDk9pmX8LSm7ztwnsCc4I9vNf
43/HfzB4R3hJeFnZNeE14VXhT8MbwtsiHtx7jedYGCmKXBWZEXkwsoKf4q4yKquLJ2TuZH7ZgLJe
ZRfhbqdE0suuCO+JPBl5H09+fXhnZFyZwpN/I7IYz3h/eH54daR+WZtI5/Ai3KO7w+WRO8riylIx
AuaV3VV2X9mCSL+ypmhtceQAnlK/yD24ak0kJzIS/bvPv8C/JZAcyAyM4HG5JKTQ9/rBzsGi4BD/
s6FIaGHoqdCzGAHzAstDj5uf0EqMj2tCr4auQF+Wh9eU7YuE8NwXlr1VdrBsZVRGvWUfhCaURcqe
KvsuLINDwoNC74TeMqMgnBC6JjAxnB1uF+4T7oiRXhyYYkZBeEp4Os5tCW0JPolRkh3OxqjIxFy4
z/8s2ioOfYAx+VTou9C+cHI4Nzw2PNG/IDQg2jFaHo1Gk6MJ0dxICGNiUHREdGykR/S2aCB6d3h5
dBHuwITwtugqjIpPo/uj86PzI5OjfaJTcA/6RddFngkH8BxScN/To3XC28LbHk56OCXaKtI5Oj16
XaR5dHlER6dgnJb6e6Gvd6E3C/2P+58KtPN/HHw5ODsgg+/jrvXBWDgQouDcwKdIywOrA++GqmPe
rgsmBceFmmIczMCnuCIY8keCbwTfDnQM7gimB1MC3oA3eE/wQf+w4CPBxcEnMRNW+BcEcoP/DG4K
7gruDR4IHvCPDswMTA9cF7gt1AYjLxIMBa8KxYVScS4n2Ny/JdQwlB/4FLri4D2hUsy3XqEBwcLA
oMCUQDSwKrAmsDOoA6v8X/i/Dq4PZAcCobrBHrA7sECB+Wx9pmAG/g973+PX1nHlO3N17xVcE5dS
1qGUEtelLnEcSl1KqUMIpYQQSgihLKGul7IsP2SvI4RQsawfFEv3l34LSfdKcQghhFCXOtR1eTzq
sg7xI5QQ7BCXUNdLXeq6hI9DXccf6nqp631n5O5n9/P+gffefsL5jMRozsycOefM6Dvnc2dEVp0S
WJlUGF0wao5R0akXSl+ch3UL0/+GKPRy/Owtit9fg+M311DxU7caFEB9iEbD6Puwyr0GlIomgP4u
foJ1W/y86v3oPaA0dBnok/E7YtLR+0CfQh8AZaA/AH0a/RkoM3569AHM4gfQdvwg3gX4ORfnosL4
Oc1H8SP4EVQUP4P5WPzEZTF+Gj+NSvAzuAZ9HX8Hfwc9Hr91pQzrsA49gQ/hQ6gcd+Eu9CR2YB5V
4Nfwa+ipOBKuooqpYvR0HA9Xx/HwM4CHy1ENVUF9A9UCKq5FdRQQaojj4e8AvrWixvgO3wz48G10
BPbzS6gHkN4V5KauAopTAL+9j9T4PjwWR2vHqD9Rt9AL1G0NQi8CnL8fDWs+qclAk5oHAEFNaT6j
+Qx6AxDUTnRWk615CL1J59F56C26kC5Ec3QT3YTepg/SB9E8/V26C52jzbQZvUPb6O+hhfh5rsX4
Sa73mE3mL2gpfq/ERdgiaNAllmET0XL8tojfxs9eXWEz2Az0O/YL7BfQ1fhpqd/Hz0mtsoVsEXqf
LWYfR9fYJ9gKdIN9in0KbbAiK6I/sUPsq+gWe5xdQLfJyR38GXJyB+8gp3LwZ8lJHJxFzuDgz5HT
N3gnu86u48+TmwhwNnuHvYsfJOdo8G4tq92GH9Y+pH0IF2mf1D6JH9M2a5/Dxdp2bTuu0HZqTfgb
2sPaw/gp7RGtBVdpbdoeXK11amX899r/pZ3G39bOaM/hf9C+o13ALdoL2gu4TbuoXcQ67S+1v8YH
ACuuYkOCP8GPDyd8mPAhNiduS9yGjyTuS9yHLYCdNrE18Q6XgHmyE8a9gIJScBh2v9vw87D7TcPH
uAwuA78AaGc77iM7Xvwi7HUfwv1cDleNXwak8Syehl3oPjzH7ef247e5Rq4Rz3PNXDM+R3ae+Dzs
OSX8Dufm3Pga5+fC+ANO4RT8IRfl+vBN7iXuJXybG+Rewf/Gvcodx3/hTnAn8L9zo9yPKcT9hBuj
aHJHAMVyr3OvU1ruTe73VAL3PneNepBb525SD5PTH1TelvwtRdSXtxRvKaaKtpRsKaMeI+c7qNIt
T215hnp8yze3PEtVbPnWlv3U01satjRQ39zSuOUfqVpAJo+CL2OqBnZaBJPsQAxCPvr/TPh+1ay6
VVU9Dq/k/VagPkqp7mhqdLe/X+2LNkESo7Fof/Rk9Gx0Nno+uhhUoQ4PvFAjWBgsjCZEU0kNdQp4
Y9Eh4CyAvCV6k7QdqoneBj5oWZ0K1EOdbtJybJvaBz01qfPR/lh2LC96PrY3Vqyao3djdIyLZcRy
YmVxyaB+rEt1x2zqDLRwKzYQ3Q3v9+qqUHchtgwypcbWYhuxzefR8yxQEqQ0qHcmVhmNkfHEBqDm
GeCaU6eiZ0HKkzCeUqAKNQiSrquDah/IOKqOqqej1TAOt3pVvQZ6uAWle0APU9G6qD4aiq4QeYEm
oYXF6CX1gnoxuqqOqWOgr9RoUbQItNJH8uod9U7UpM5AH/uDRFNm6DU9OqLegBbH1W543RrtiXqj
i+qt6PbozqguKpLegHdQvQz8pMWieDtTqhqriVXG6mPZoIcdsYZYcqw5dhD0bYZRFf/t9VZ0PXaK
6OuepmKRmD92jGgsaoqdgBYmoouxJdDyNGjq+vNsbDg2DNa4RTQDr2ugVf75FBjPVMwAsp2PXXk+
8/nMmCMmxznU2BkoGQjUw/cAQ8/SswjRcwTt0vP0PKLo8/R5pKEX6AX4bqDQY/BKntT7PMqGtT8H
KAPlAn0afRUoE8ofQw+gcvQk2o6eAtqBnkbV6LPoH4A+F797bSdqBfo8OgiUjUxAD6Ie5EC78Al8
Aj1MZVBfQTnUV6m9qIIqpApRJRWgorDSP0+Nwip+kvoJOkSNU+PIQE1QE6gDdvz/gozU69RZ9F2a
pVl0hN5Kb0WW+GljK32EtiIb8wjThL7H6Bk9+j7TwXSg44yJ+S76AXOYOYJ+GL8NaZRxMR70o/it
R6eYMPMS+gkzxoyhKWaN+RC9wb7LvoveZn/B/gLNs++x76Fz7Bq7hs6zH7AfoHe0P9FOoAXtz7Rv
oKX4jvbXCdsTtqPLCd9K+Bb6TXyvuZLYndiNfpsYTAyiK4mjibPod4lzie+gu4kXEi9gOnExcREz
iRcTL2I2cTlxGWtJXBEnJP4+8UOceN8j9z2Ct8GML6Oq4jN+G1gCuVJIwvcrRf7TSp0fKT1KvzKi
jHuM4QzlkrKq3FVpNVstg1QfPhWeUHf4Z1SD2qXafANKkVKq1ClNSo835jEqi8qq/5ayDpx59zhV
Wmny16r+eNur6oDSA3XG/Qh4L0FdaNlzGbgX1DIlBPxLkSpo94q6phSpw+qEekadU5fVTaXIuzVe
n1Z6okmKN5rlvRnNVe4q43+rWxee8KZHVbUrOqhcIlgMkNXp6BTg83ngZAHPGsOnyHgA0cBuSwHM
rmZHd6k5ajP0muGpUnco1dBHt7I/Phqdd6siqtmKl2jCm66cJ/L6uuJ62KtWqg2qTOQNT/iN6kHV
AWOKAQ0pesWk3PRcVDk1WTkJ9Ul+VjnrnlC80Ecx8PXAqOv8t6DuKaUCei1SesIZao1PVm3KOLQw
5E1X65VJZQV49ytDHqRYlNvqNsXipaC9urh8+9UlpV/Ndm+o0+6BKPKuqxH1hHpdPaaeUjeUleiU
2uXJ8o9FUxSvOhzNVTOi+cokINVD0VaiKdWm2gA1un3FnirvTXVanfYYYRdaGK2NVoH2ypVS6Cmm
ZnuyPFm+TdDpFOxv0qKZyizIURTlFS+MegH8h4KZvfDRXP6/O5fZ5gQzmcv4FDoAYLzso/T/dqLq
hT2SMSSHToVROEUoCu9yRaT5cGPYGFoQVsLHQ5tCQWhY2BPqinMtuSLhNOBChCNsDi2EU1zHImcj
i+4LkbvKjsh5pVipUQ56RKXL3edjlYhyQol4xr3ZyhLk1pTryoayqSKoMxlZjKxCnTLgbwbuFKUL
uAfucfrYyKpyxn1Dyu9NDU1IfGSnKyLclBqFoshuoc4VieyJFAgj4RnJGCki/au5nvHIXRUpxb4k
pcYjuo6R3tV8JeJLAwm2KUtqoWtZ2XAPqiXCnmBhJF1MDsmRpkC2fzJiknJ7KVEWinpTw7ugRRFG
vBkJhTMjAEki/ZEhlz8yEjkZGZfGhIJwo5QrypGQUCQUQM/nSd9qK/R9SEl2zxP85+4DHcT7jSxC
v4DPlA110JMAqGhKnfGswyeAwXxpaqOyFFmE8YK+VDfUWVIHlSUloo4JRaEFaIENG5UlYY8iEwot
hRxyQfBCeBdoPCd8KGwkdgmdCA2HT4cioVNgkzHIy+EUsNxGOF8yhhshPx2SxWVXpLcOuOfCrcIe
KB0OD8oj8nlpLDwTmY2cV1MiK5FLYIt1z06FVo7BhmCHkqPkKQ1Kvfuq4ohbcViZUPJUlmgS6Ap8
BlZ0ZyoZalLkdmRd8YPlI5GbSqVHryQrcmRRRZG7oJ9FxQb8ez3blWXI3VUMyrQyB3XT1Ew1S90F
o15QbK4N5ZRnXCn2iFBrRcl275JHYEwRkHk5dCWcRPxSmgfdG2Vd4HqIk2BkwcxIacgQqfDPCnWh
Y/A/pEi1UBS8HKkLXwNZFmFUkNRCNde1oZa7+9yjapVnReJdx5RitSSilxojpvCF0CniBRFTxBK8
AXbt6U2VQ/d8IO4F3nCmVB7ZD2QidhflcGYvFeoC6YbBF9Oh/iZw6SI6Uhq+FhFDESlXNfoy1RS1
1j1GvAJ8otuzqvLQK0HKfcQrlE2gDfW4J0GZU+c96551pYb4Duij2JPg7otMqoWg3Qj41j6YMRvg
G5fVcqAglO+G+pzqloyuSMgAs9IfigSyA9mhAWLpYGFoAGblZdAamc8j4TvhqfA+oMJwebgW8o3h
Wt9MeFROBe8AEkagxrHwRVEObYZvhN1h3nfNd03qC8+HbFJfsNA/K9rCF6D16+Gr4WvhW4HNUEMw
E3wnk8zIcJa8E2ZCUbA7QoE+E4QRqTwchPmyNZIargpcj6RLfb2pULpdyg2rYTZ4EfyzJFwlp4e7
wW8nQmfE5dBaOBdWlT5IIDHMQFh9pHLQK6w6MEKZjC4UAY9YCA33pvrS4Bu+Hp/EJxHCY3gMYTyB
JxCFJ/Ek0uA38BuIxm/iNxGD38JvIRafw+eQFr+L30UJ+D38HkrEv8K/QhxewStoCyVSIkqiZEpG
92lyNDloq2ZJs4Q+prmouYiSNZc0l9DHNcuaZZSiuay5jD6hWdGsoFTNFc0V9Heaq5qraJtmVbOK
7qdfoF9AafSL9Ivok/RL9EsonX6Zfhl9in6FfgVl0K/Sr6JP0z+gf4Ay6R/SP0QP0D+mf4y20+/R
76HP0L+kf4l20L+if4U+S/8r/a8oi/41/Wv0Ofo39G/QTvoqfRV9nl6lV1E2vUavoQfpP9B/QLvo
P9J/RA/RH9Ifot30n+k/o4fpv9J/RTkMx3DoC0wSk4Ryma3MVvRFJplJRnuYFCYFfYlJZVJRHrON
2Ya+zKQxaSifSWfS0VeYDCYDFTCZTCb6KrOd2Y72MjuYHegRJovJQoXMTmYnepR5kHkQFTEPMQ+h
x5iHmYdRMfMF5gvoa8wXmS+iEuZLzJfQ15kvM19GpUwBU4Ae17q1blSm9Wq96AmtX+tH5dqgNoie
1Ia0YVShVbQKqtRGtYCbtM9rn0dV2he0L6CntS9qX0TV2pe0Q+gZ7bD2x+jZpLeS3kL/lPR20tuo
Oelc0jnUkvRO0juoNendpHdRW9Ivkn6BdB/F/z6K/30U//vvEf9jD7LG/4wGHKFJ0jzoLfJWiKm2
cq/ea7Gne0O2cme1s9p70jsppnsXvavw/01+2ntb3uW966NlvjvHWypMeWPOVCgZclYD1yw/DZ8s
SrJvm5zmyxZgx+m/7Ktx3PA1uIoC2wMFllhAH/AGYvJgYDawGrgZuBukg9v8o75soBpfsa84kOoq
8h0E7iLg3e8Y9BVbQj7ZVxOICVWBGCFLSMrrTSH/9Wb58qzLvSm9JYGYS2+ddq33lvdWueqkteCS
3OorkypthcCVGYhZl+13rdO+st4UX7Ld5C0iI7MuO6thDCHfAhmp1OBb8k7yO3xXfGuQ2+Sn7eN8
sY/2XfdteIv4bb45fpt1zn7XtynZfLKrNNhsCbl2Bw9aYvZL3n6Q84T9JH/CEgvago7uNRsCDtnP
Bv3+JFc6kR5oBGTZJ+XJt5yTgZivhkgvrVmXbWogxp+wTve2iumuut5DvcZ78hESd8vINuWs9u8C
6UL3ZBNT7SP+Vn5NbILPD8FizNqQ3+isllWoATW7DWKq96at3J/v2/TXdi/5roh6Se5ecww6BgW3
a9I/E5xwDAYbvKHgtCVm4wN6Oc21EuT87sBdfzC47Lrpuhm8ElxzFciZ4lDwOtRSgxuOG8GG4IKv
Rrpuicmsbf5vYyJW6HbTziJ4d/dmSWAP6UwgZr8N4xkVL8F4xoI5wZze071TwJHWOyPkB2LShv22
S++ctM309vUO2kPWZbnWVwz+cxtsPmtddq1bwEcE3lfsrfZW2HK7aTFVmOpe8+4Xx4HLBN4pdtPE
al6SP28POat9HLGZWGq3EM8U4dUy5G3y6uI+fNZ7FupAztsPtAI6DXqLQEtD4M9eKL8Nvr8u896Q
dwToUrzlOm+Prdy3DWgH+PLeQIWrICD6GnzNvhMBHXhAtX1rkAPfvSgjX46rSKrxT4Gv5wST7beF
oMQFQnKanCm4uxuCHH/CdtF3RqyQ830Z0B54ujzo6wLvqvc1gC5zxVL/Ldd2OSkQC0bsW73VvjI5
KbgpXOjNtYSEi71JvWnWZtDeLvD1fFdTINadLadIzbbLrnXi6fadcq3rZC/y6gIx0EOe96wldC/n
7e8t7GXtel+NfdbZAxZhvXrrFeg9X1rrrRVmApS/EOzQY60h7YPVtoom/y1fhi2XzEf/lL3fV+mr
9F+DUiqQIGcGdoN9Uv3dglu8GVj3z4v7xVRim27aPu6sFubFCt+yHzmrXaX2BBjJpeAxf1/QYRt1
3CAJZsNAsMufEjT40/yZ1mWhyr6VpN5WWA8Oybt6G3vNIHMR+PlG8CB4Wh6ZCST3H3MBrLJuHwGv
L4FUJe+Sd/kbrVDqLycW8xd6S/1m0QL+vtPf7ef9Wf5cMlv8+7wmx2AgNaAPDrsmySzwB10n7Sft
6/5r/muwUuzz7Q2e8Kv+UbDgvCUmbvf3+QeDp4JngnNW2rVq74fZWkaS3B3390wBZqx0xp4urUlr
Lq+/Wzoh33BOyq29rb28dVlcdIz2zov9vcFe1X6p97gl1J3tPy6X2+ah/Sn/jH/Ga/JVyinBDJ/f
V+Mq8Bl8tsAe8XywOLjDd0w+1F0W6A8MBUZA5vHAbVfM3u+/4BuwpfiG/ad9045Bux7q5gTSYc3x
A5GSPF9e4GxgElbOBt+E75T/jtzNN/jHnFsF1THo3Aojnglslats+cG84F6hPJgdqLbdCtQFmuw9
lpglBqtBWbDS4rWdDpwPLPocdlOwJlhv3+n1CkZYBbptvGPQZQk2BC6BtNmgi52B0oDFW+HVB04G
Vv1X/Td8EVu+IxgwuUoDK76GQA9YIxiIxSOGE/RP4VvmPcCH5P6GrYDyElE20CfjEcP0eKzwU+hJ
oIx4rPDT8VhhZjxWuD0eK/xMPEq4Ax1FHvRZ5EMKykFRQJxfAbz5ffQoGkU/QkXoDFAx4M1Z9LU4
4vx6/BdKStE7aAE9HkefT8TRZ3kcfT4Zv+u4AtN4K6rEyYA1n8W7AGu2xVGmLo4vD+BvAL48GMeX
/xzHl4fi+FIfx5ftcWRpwE7AlB34BGDKznjU8rvxqGUvVQiYMgyY8huA/56iqtEgVQMIcjiOIF+j
AlQIvUlFqCh6Kx7TPBePaf4uHtN8Px7NXKOmqBn0ATULKPMmoMwr6BbBlziJ4Et8H3WNuoY/Bijz
Q5xMbVB/wZ+g/qpB+FOAL+/DD2g+prkfP0RQJs4jKBMXEHyJv6p5UPMQLtQsaBbwYyROiotJnBR/
jSBOXEIQJ/46QZy4lCBO/DjBmrgMsKYNP0F30924nNy2ip9kHmEexxXME0wl/numiqnF32bqmCbc
RKKruJ3EVbGBxFWxkcRV8XfJr0TgLibMHMOHmX7mJfw9ElfFR5k15hp2MOvMH7DA/JH5M5YAxd7F
QRaxFFZAQBbH2AQ2Cb9AUCweICgWv0xuCsWDBMXiV9g97B48RO72xK+S+zzxMFvKPo5/QH79Cf+Q
rWSfwa+x32S/iX/CPss+i8fYZrYZ/w+Ca/E4+wo7hP8nufcS/5T9ATuBf8aeZl/Hb7NvsD/H77Jv
se/hi3GM+3tyCz9eBXS7jtfiuPYDcsM+XgdEex/+g/bjgGv/FEe0fwFE24rvaHXaA/jftf+sbaew
tkNro1hydyKVou3R9lCf0PJamUol8WLqk9qfaV+nHtC+of05laV9S/sL6iHtknaJytde1P6a+gog
2qvUo+S5R6qExJSpr5OYMlVKYsrU4wTpUmUE6VJPEKRLlROkSz1JYs1UBYk1U98gsWaqMvFHiT+m
niJPLVLVieOJk9Qzia8nTlH15ElFal/idOIM9W3yLDvVkHgu8Rz1ncR3Et+hGklUmvpHEpWmmkhU
mvonEpWmmhPfT7xGtSSuJ96gDgCq/hOlJ88iUkbyPDrVSZ5Epw6Ta+MpM6fhaOoIef6QsnIJHEfZ
uE9wn6C+RzA31UMwN3WUYG7KQTA35eQe4nIonsvl8iiZnG6hfOQpQaqXe5QroULkyUAqxj3BlVPP
k2cCqRe4Sq6K6iNPA1IvEVxODRBcTr1McDk1SHA59QrXzhmpIc7EmanjnIVzUK9xPCdT44DRPdTP
OB/np/6F6+VU6nUuxr1AvQno/FXqLe44IPJzgMh/Sv2S+xkg8stxRL7CvcG9Sf2W+zm3QK1yFwCR
3wBE/ojm41se3VKk+RQg8jLNp8lt+5oscr+i5nP3PXLfo7Czw8iLIv+JuZ8LxtN98d+q2gXrYD6s
YKWoEtWgfagRdtt6RB09KZYgzdERIUMsh9ygpRle+8RK+EwVEsS9kPOL1ZCT+U14p57be7QHaZ7L
O2rh16HMKGZD2SH+sgg9Hm0W7kCugV8Q0//Lqozjt4AjhOkFej0uXSa5w/HQzf+aqHrjrKNM2DAY
nClHt9vmjmSIhe2Tllrx1pEMYUOqluqEjfZV46zIEi5xn61eVG1z4oylVkqQUoH7uNwsG2RZjsgT
8rK85mJdWa5CV7mr1mV28a4+12nXRddV1y035U5wb3fvdO9273EXQJ2DUOeYPOFKAf584G517QPu
4/c4Xbx8zHXBXWEdkU4emZbGj1Y4R60F0qRtrueadFaatZil80eWJL3klRbj/UPP8oS7wMW6TdBe
udxMenf3uPrcXtdpeQnajLn7oe8h94hx1t59+I5QL2w4Dor50m2xUBrpMVtHbHN295EMR1nHDIy7
Tt5rq5TL5Eq55uhZa1FHn9xgrbMld/RZauVkOcPuts3ZuqBnB+nbfQn6XpEX3Lc9tLsCemb/1q/s
pjwRz4B7tyfDM+GZ8yx4ljzLnmH5imdN7nIverpk2XWL6Muz11PjsXlOefyuPs8xY4G02zXo3iqC
LoQN0IvbFRT3iWnWrWJt10HxuHhBvCHekfa3rx6ZtoxKTXzIYADNXG5fBQv1SVtFo3hZTLHUWsxH
usTM9gqx0LAJJVXiVWFTotpXpQrbspWyXJb0sg1GcB0s4QdbDMjD8rSrT54DbW7Im65c1y6wY3fc
iqOuGdcNd1Fck5RrnzsdUoG8AGMulU+5jC5Vvg41T7gyXfPyAsg7BqUToB/Z1Qj8CEabCrkzrhLX
Zdc18IBqd517v7sJNHXH1eg65JoCH0lyVUEtWb7iSrMt86GOOyBz49Fq0U38sn3y6KJ4S9pja7aM
CRvGkHRJunS0QFrhF6WzNoMlk6Qjy+CZufYS5yjI8rc/dwzsI7rH3Rb3pPusOySNu3VuvfukdFeu
t7vNI9KqtC7mt9cJE47knhJ5x9GTDv89HxA2elrlHHFULrYkWZJkWhoxXAEvqewxiywfMoZsc4fv
mEfkPKlOutlxUebkbZY+Obvjjq3YfddzxXPQfR40tioveDjPNrD/DleSp97T7CkjXgEa2OMZ9sie
M55pl9vT4GlwZXmSPdmeMuCa8BTLB2EEC+BFs+5Zzwnwn2HPdfe6+6Ynz1PpMXgc8pwnR0S2Sltl
xx0xS9wl5gt51mpiacugbUks7JLFoNgtjvKL7UOSzpZsTrAlO4b180cXLbXGEf1VqdpqaV91XjWG
jPvt3bY5qcc6Iprbb0o7pe3CKeGUdb9kEpP4FcliOOjwi9egl0OSKPgNXXw6v2ivsuSKp8UxcUqc
BynmoL73yFJXRApZxztUqQDmT3/HccliLj18x7rf7oZZOiSNSEUiLw6Ko4Yuy0XxmpR+eJdlUCw3
5Iit4kUpJpWKJWQFOpJBVh8yA8mqY6sUNqDvfDHXtgwlXrvb7YWVjSY/RYgQQzGwyjHwhyhGy2iR
5qM45kdxzI/imP894pgJk4nb46jlLHoYoebC/9+S5o7xdqfDMKArcUwb9YYBQ17ropNtXzE0dx50
Zpr1xlJnvu6OPre9unWPaZ+T16V0JnfccBxzDDtOGOodC23bHJtOZGg+YDI0m/XOEmdre7Wz25ll
qG/Vmw4Zxbb6Axaj/vC8sNc6+ZzNeaMtp3POuGq83ZIlHHP2tZ3qLBOWjOPPNXeMGYeEMqOXv9lt
EugDlgMWx7J1Etb+Sec1UufwLah3V5CNq8Jc+yy0t2QdEmoEW0smn95W39Fn7LGrRyqN3jbHgQJL
lpTauSZtl/boGnXmzuuSzmTuzO64YUhuye3kTGkdvLUJvhMu8Df1g+KNtmHAiFuBG75VpIrDl6We
jhtSv1SgH5SadBdNKUQ/bZtG0TENLeSZ97cutq/AZ6Ad/ahZ31FlLD2M2qtNvH5el2K2WG9Dma37
vH7Qvu+563xBW4bzcueCUNmSaYzxFUINX925JmaBTvrF3LZ6vq4ly5Qi5rcE+ZumzJagWMJvF8v5
/aYsMiZppyX/SKW16UBBp8OS1bnWVk9GZDTpzMaizuvtBR03dK2GYVOa9bZhgEhJ5OR7HNOGCdDn
oK6k43jnQZA4LqNhoL3avN5u0qXw5w017d72kOFEd79hQ4f4FXuwbbPDbBjQ5xLbdxw3zPHj/CI/
adab9pkOtQSN/YfTxFaj3lTevlU/aNrX2mQPtupbsgCvHWurNx0SyvhV41AnbUg2dZu6bRMmt3FF
nDGpLVmH0/j1lszOMmL51qZWfeeCeNpoacl6rrmtrK2+zUHGKC0eqbRxpiBoEGSW9hwouDc+I9ih
JdfQYEpr329XLactp59b6LR1dAOCudB2XdppA47ObGJrXQnUMcoc6MPcknt43qxv3dOSZRzXmQ3J
zkPCsuRtSeuodeZ21JrM4mmT2Xn68LxVBK9f7qwBj693DOtKdJnOQrDxsmHAsWbeTWzsTCP+7yy3
DTgbO1hiY6fRsNA+S/y/g4XX7tYKx4QzyZnUtaC7ahhw5pO8Y8M87qx6rtmZC5Z3O+YcA45TB0xO
8+E0Y1HrHuNtx5KTddYacjqTHdcNOww7OmnnPkNe+0pLrm7MccUEMhhFXaOpUNco+J2jzlHDhHCi
LefwDWO/YBMifHpnjbAM2BJmipDHi50DzkE9a99ntAh7BYdzUNh0qjpeZIUMPkHoEtaE5g7VmSQk
Cwu8aBwRdjhvCQedfR2FQpnzojHWdoLfye82nj183CgesMBsu9xZY6b4u8IV62QbIDewUrNurO1Y
5wnxQpuDrxZn2jZhxlwWr7YYrZMtmSIy7BDvWEeMZzvXuvUS2E2q7siSLLox4ptSqO2gIZnMtY7C
tnrjkHjNcUba7UyRipy72hyApCDfkdLulfaLjeAVPdKQkCEkixctRilmDRnHW3Vt9YCl02H/ZIJW
VmCP5ZfGJUoSLUZjnVQnnoZ5sSaNiDM61LnDkNzW7Owj64YRyNnn7BPKWm4YzxpnjSPGm7BOZAmn
WjKdp52nhWVdVfui7jSsNzlmWPGID3TWmPi2TUM9X8Tv0fF8qa2sc6Et0jrSuWasM+WKhWJ+22br
CEkwP6sEB9/kWON1Yq3zBq8Xd4G/9ogzJOlapZ3GOuOIpap1SJrsnDDeNuRZb4uZsAoWkDlKcuZS
w4axFGaqxTDBi7oSc2kHsoqGvI7LHcf5Ef6k09i6v3W/yWy/ZqgxgGeaF/mh1kU+1HKL7zcs8Jc6
DzqGj9AdrFnPm4Bm+bOmlCPcc828F2YuzPb2aqPIx8TutnrhmNgo7DWVi2aYx426RtFtFE2tnQs6
M+zORsFj9uqQONZJG8eNongIHI8HPD4o9olTusH/zd7XQLWRXWlWlUpAy4QQhzg0cdzETdM0odVq
TBshFBrzZ2LLMqZpkIQQQqhKGAupjJGQ6h8s04TxMBwv6/V4CSEOS1jGIYQhHsdxWJZlGA9hCCGE
JoQQQtM0IT4elvg4xGE9+97rmfb+nO3dM+fMnuwen3dK4pZeVb13733vfvfzq+fgYbEBeJWaSmix
hEovGep7oWd6o+ihD8cxmNvZlqvMMhijsa60d+7xqneWwIy5WpPDT5zVNrR5raL8zpN3rpwPnQ81
uM9bhKteK33tAv/OLpvQIjbsf2fnnfut0ecHW+YubJ7XA88Zf2emlWyIdanFUjAXdMAxze2Aux96
ZwPFkNJLqnrQIm+UN6q+BXoxc7jm0KVi5LUTjXuhqIuW80cvMcDSHRfWLvSF4i9ku4YvTVy63ZBM
9Z9tuDR7cezi2KXRi5MXpy89qI+p761JDrW0RAIfSKG76wdC9wNF9d31MnOY9lzcC92/sAB9CP5W
o7/YX6Nnjc2bzZtg1h+pj6vZO8syB0FubvJqW/bXO+A4pkA0uHDbG3XJ1hJ7YfbCMogReQwJxg6I
ZdTiBVVNJJUA5nrM+wT8+oDqADHNH4qpGamPuvDYNcxd8c43dNRfYx43YA1htOMCT3vOsv7H9feZ
0Ut9F5JcwzUYPXSh51L2JQNvo8frZy71nGUvNF/sAK0cvNjVfDNEgMjIX7oJ8qJZ4OMPLxlCLaHd
s2AkNC9fSrqkBmNi/dKBi3P1t0It543M4/oskHFE48v4Mobhv8R/ieGKTcUmRpDfIocwBfmX5F9h
4eQdchKLJH9MzmPPk78i38M+T26Rv8Hiyd+Sj7DD5B/IPSwR5ThJSlCwV5TpynQsWalT6rAvhg+H
D2Mp4BnX/oXW6XZhyShLOg5ypG+Dq2GWZEAM/ClsEruHGVGudAYx8MWIgX8L5U1vo7ypFOVNZShv
MmG/BnmTGeVNVpQ3VYC86QXMhjImDmVMAsqYRJQxSShjklHG1IQyposoYwqhjKkFZUzvoIypFWVM
X0EZUxvKmP4EsfTtiKXvQCz9TUIPsqFBlA39EK0wfg+x8fchG48TkI3Hw+AKYzwccvJ4BPEfiB/i
+yAbj8eCLOkDXI14+FTiPnEfP4LY+DTitwoMT4f5EZ6PGPhyxMBXwvwItyMevgrmR7gT8fA1iIc/
i3j4WsTDn0M8vBvx8HWIh/eQDaQf94KMScbr4TpmnENM+zfgOma8F/Ht/w7x7d9EfPsAXMeM/wVc
x4wPwnXM+LcR335XuRkWif8AcelriEt/D2ZS+Dpi1N9HjPpG2OthR/APYD6Fb4Vlhp3BfwP5c4KA
/DmhgPw5QYa5wlyEEmZVRFjYN8J+SoTDHIrQwRyKyIRsOaGHbDmRBbMn4hjMnogcmD0R+TB7Igpg
9kSUweyJMIHsqZUwIz5cDP9++C+IEMyAiG8ixnsQMd7fRoz3EGK8v4MY72HEeP8lYrxHEOP9XcR4
30KM91/B1dXEbbi6mvgJ4rF/hnjsJcRj/xzx2MtwdTXxi+feV+0jVkAO9WmFEuZQikiYQyk+AXMo
RRTMoRSfhDmUIhrkUEWKT8HsSZEBsyfFmzB7UmTD7ElxDGZPihyYPSlyQfa0o8gDOU6WYgpkN1WK
dxEP/HsMx7V419Ocpaz1/7njYznr2j3OgClqH1XfBt9E7YPqIfC5yRWBc2vVvRyY92qXuBIgzXOF
3i4gTaP6k5wO1R/lUoB0u5rl4oA0dO42kAa4Q176/9J8+REfrnwQFv30Dbm31/7Hg3ifP8R2myPY
Ab7QXsxfZZcqx9n77BL75OzjukBlg5AopApaekGooWKEIWFcmBHGnXP8IT4ZXDPEDvGF7GrleOV4
XYCfY59w0VySqZ9/JMTQC+zdcxtCjcBSMeA+42yvpJdKJLckSl1Sl6iT5qR1IHVJ63KMHC+55SLZ
IXtkWW6RE8Fvc3K33CsPgGuMoFYI1FsE9UGRCXBoQX1ZviwngitDQB6vZLlhblhkuNui311rjuBG
uQm6WOS5KXet2MzNgha2mCMqGyrHaac5TmzlFsR2blnshG2SN+QdqQs8a07eBU/okgphi5pI8Nx1
uUgalFuaopsOyN1NB5sO84e4h+KE48q5eb5QXODd/KS4JtaKD/jJygZzhJBojqCHhXHusTDjrpVi
6Ql6QjokxYKSLE5IRx1X2FU+QC9ADZeBa9hVdy2P8VvCEB8GWkKjtmxIXU0FUr8012RrYuQYoIsP
2+EG7ehpGgZ6AfppGgVlomkKlKSm5aY1eaOpXd6VZajTJgb83i4nNl0HepqzF1c2UDHg6kShRm7h
Y4HOEuWUyvFzG2wvLNCK/J692F5cpxFS2F1OxdXWBYR4tpfOFmo4HbD4apDmQ8J9dqgu4FbxJfzV
ygZ2SJhnBzgGeEIh+wTUb6hN5gyUg9fTC+DcIDi7w08Dz8kSxtl5zs+PcJ3cda6H6wPPHAL9X6IX
OKBNwQM8bck5J9wyjfAd/B2RlOwSLd+VAsjqbVKHdEPO+kePmZS2pS1gqTg5XtbKebJVZuVb0D5y
C+wf8JchaUS6AzR2FWgsFVzhBn+tAJ30g19PAAt3STlSvbQnX5GmJYt8TSoEZx7JNXIDuPaePCPP
y0vAC2Q5Qo6SS2UPuBP0i4A0Js2xvaYRdgB5fAlPM9vMNn+D3eDHKse5A5QWeP+WoBV19uv260IN
OMsCb7jrnAM+eV3s4ybEYfE2mPaBB5qHxB7xJvC/UXDlmpjNbQJt3uceiDz0aikg7wKLRsv3m1RN
avlJU5rskNbNEfIqsOlhflJKqAuIU+JB6HvA89b4SHGTn+QnzRHiQ+h7UpgUKczU9UOfY5fEWVDW
oKeBK2OBl+7nkyUNsM+W44o4JcxI+0GPBsRlcRnWER9LGE+XPQBPmm1qbspu0jUVNBmAF9qanE21
aEwmNvmRH/Y13QTjoROeAx7IN/HSOvRWKINaMZKxaUEaATbaaMoG9W43bYJS3GRCntna1A48nOET
zBFnDfxR3shbwDiq5wP8NK0Tk4RdOErBOFVxBzmSXaK0cB4qWwAz0ROuQLByasEqaIUTQqmYDeaY
cfaeUOo1AQ9sEe5xzaIB+BLwJ67YPMA5+RzuphjN02ISD2YgfrGyoXq5epkzcTbYb3ZAuHL24NmD
wmVGA72Qa+daLcWWYlFVruE14oHKBqClg+JhXgStiRbVlatimrOtkrUcFCIEQogS4sRiXs9vizpQ
suk0MD9eE7q5NH6RX6SzRRPHCzu1saIN2EYnOsVaAY63IfYWv8KvCylCnlAkOARZ2OC7+H4uG/R/
UkgUC4QBtpsdsBdb1P80B4O6YP4FfjUkzMCZF43YQp4GWrNXjgOvnKFi+DZzhLSO3l79G/JvMIz8
W/JvMZz8IflDEFv+jvw7EFt+RP4Ivb3qxi5icLd0iHrjEOo9iFDvCwj1xiPU+wWEehMQ6n0Jod5E
hHqTEOp9BaHeZIR6v4hQbwpCva8h1KtBqPd1hHqNCPUWIdR7BqHeYoR630KotwSh3lKEessQ6jUj
1GtBqLccoV4rQr0VCPXa0L8TVBFfAkjXgZCuSPwn4ofYVbSm5GsQxWLfhSgW+x5EsdgdiGKx70MU
i40iln8asfxriOXfQCz/B4jl30Qs/28gisX+HnH924jr/8+I699BXP9vEdf/EHH9j0ielLHfKXfC
IrE9hEE/izBoLMKgzyMMGocw6OcQBj2IMOgLCIPGozUc6WgNhxat4ciAGBTXoZUcmQCDzuJ6xOnX
Ik7/HOL03YjTr0Ocvgdx+l7E6TOI0z+POP16xOn7EKfvR5z+O4jTb4WoFP9K+Hj4L/BBxMhPIUb+
x4iRn0OM/E8QIz//3I5qH/5TiCDxv0cs/CPEwv8OsfC7iIX/PWLhH0MEif8BIkjiRbRe4RW0XiEZ
rVf4IlqvkAIRJPEqRJCEGiJIYgQiSOI/Itb7PYBKrmF3nmKTUwX/0/GxCK3sevAopijrDOqDOUC6
HEwDny3Bw+CcHEwKqoEUsISAVB+MCwJMVFZLjQPJGYwMJgDJGtgFUmngSRCMijJjYBtIhYHtwN7/
0Sj6CF9FxEQkoz7EYcDNDM3/dCj2zq2Z05w1ga3qsWBiMDWY5ZkIeoINQTl4LdgbnHHNBOfdYZYu
qtgSS00E7rBq+6DlRmAsMBdYCWwHo+g7nqlgTVCuCJTHBWeCS6yKKmYPBwfAbzvFVmq2ask0RLWy
zYKzfJV6wC6wm644R599xGpjnazhdJF50xiANeh1ekvIPs0Kh6nrdowtNg0J2eWr7Cz1wH2j/L7F
bS85nUUnC7dpi7AWvMd2mh+c7madQl95EWuwmiTC3GnuKyLN7edN59bs25LVNWPJkWR7f/WidFe6
V7RATfGXqVkLLe1UpUi7xjvio/NJUgRlEJyVt6UiqRTUbpA8Uq80IJj4y6xBukwZyouc2vI4qJ+g
zJVUj1luBLO4eqCfhsA01A41G5zhQq4ZuoQq5tq4q6ya6+JunFvjLJy76CEnch3cSHkWN2auFfXn
TWYTNynmmGvtg/aV6hw2WyxxFXHTVptd5NZdVlHjcoB6Fu6oaOfmXDWoT6A3RaTxDuiRaN92zYBz
oEemu9WLXIl01zLHX7YkVDVUpbhagvfOrVnCYDt5onqMjwjGFaecCfBZoJVZH7bRWUMVO7P4W6ya
vxds4Ff5jfOH+fsW7LyJ3z0TsJTw18DdujwT/BO+iOX57uAJfig4QxUUWwVVxf6yDjFAtVY9oaZc
QIuuLHtkeZbVVnGIdVYtnbEI2UI0vcVkla+6lsRt10ZVqWXujMa1Y9kq7xUOnNGYN6HlXb2uofJV
cYUrsdqsKssNq8nshH2UdUWknC2lVG24LpfHSfK5tQ/7Z+7kL8trxTFVKfLDJqxpf1NslYO2W7aq
dpoSyudPs4Ftcyc1BW0tt8t98pT8WF6uXixaY5tdO+zBM9P0mHRNus9GC5vSEtVqORQcD96TPEyK
6xo7y3YGFi1h1XfKd4HnbwceWcKsa8B7wfgDI0AbdEAbB7uh/wdXgxssyWZDG7PR9BibxKYBP4gP
xpvmA3tBItgSvBwcCt4qvR38UC4NFgXvgzuN00dZXTAqMBlYrwiwByxdrruWWOA3MWB07RbH2QeD
J0zzpnlnVvBJMC/IsrryXdN81Q41S82yBYIO+P8o28w2U5vCLLvJYWy20CdMcIfokPCgaFaMBCPF
5j5EP2Jruf1crDNRcArDbK24nzVZ1sUEIdtNCz3CY3aBrhcWhDRhTdSYVUIBuwyKoahdyGZvU62m
+6d3zmCcnsuhZk3ANuyEGTxJSBIeslPsA/GQiFkZy1VLvYuw2M3OYjjGOimDFGOuZbPBuEqUUs+b
JG3ZUeqha0ZqkS6Dc0MmVpq36KFvSquSJ7gjeYx3pBQpxZUoxQUjJDZ4RboSvFtMSN1IPhG0SuNS
CpMi3ZKeCE5xT4pyJ0sb5gPl844DwN/jJYfYT+ulXVl1pkOOlg9IedSUO9ly1NkgzUhZUo1Mmjur
ds70W3krwzrtI64sZ+KZjnOP2VEhm3pIPbSvc2H0IdZmtXlDVTUeg3tO2KQny3cthVSrdzsIxgX0
gfJdrg3MfjP0Iy5QtsjdcRww17o8Lg8Yq9OuhsAKt24lzcPwAOOTFoa5RcHArYhudoFbF43Vi1Az
sFgSzO3l9ysind1lXbJaPkw1c3auXyyUD3JGOYkzcjQ3GGQtGJgpHnHbfBQfwyfyqWemeW0wj/fw
Ms/yLfwV8NRB/i4/wM/wS/wOF+AbwLhM4U/wDt7Kz/OlgTngl/FgXG9xe/w4q7ZgAsnH8fHBUr4m
MM33BuP4PPGq6z43ZsoS68WQ2CZ2UQYwV/SK/a5b4h3HYXFMnASjNlucE6fFddd8+aq5RxTFG+yU
OCIOilt8nr2Duu5M9G4DvbnddnGR3gIeedDVIna4ul0DFo3r7pkOj002VY+V75ZH8PFygWyQbXKt
zMh+KctVI4/KN+UJ4AO7wHab8kJTmLWn6ZA8LN+2b8tOmZevS1lNkXLn+STgNSnVi3IaKA+qUixb
TcnUdblYbpV76nrlWSlRbqY6y1fLVwU1dZsapaac9yzr0IstR621rMFsYw2lB4u17GMuUrgutAs3
nTWntfQed7S8F8w+y55sh85or6oR1tjrbE+dlu1jbwIPWKday6PEWDHZu11a7Cxi8s494Aor9ltt
tL48i10TWk+3cAnsKPyN9bMMy9N3uGT3DXqEbbfE0otvP6kOCLzAW7ZdEVSPs8EVdfqJ4zAtnukQ
msWj1OEiVfWgs8a6Zp6gjXQhXULbqU4w69lc8eba0iRXYvmJM8n0tPsq1epKPaN3RdGhssWyDst2
xSFXvEvryqLnKg7ZB9lWOpY+KtwsUlnctGhJLh0VGMHPaU6PU4+FKVcKvcgaQBRtFmrZCfah0MmC
mOoNCWueTmDZMDFWOAzO24CdiwWTYGBn62rYYdbpdnOhikNcCUAHCvIfyH/AAIxQkhiufE75HDj3
jMN+xmE/47D/yDhsrAOMnI/Qe/bER8fHZh4lG75STFGy+tYK+CZKFt0g8y6Z85WAc9NvTfkKgTRR
vgWk0bfu+ooxwhPwFWEKT72vCNXv92nAbzfe6vHFAum6uRtInW9d8R3+X84cH2UbihpF6Onq5uyY
//bAeysZw3jZI3egzOgecY+5px3FJ0N1RF1UXWJdap213Fpnrew0JptWT/WZi92FdXdL9EZNJeO2
g2vEMqOl0FF8orMu6kyYsb/OWlfzYc26VLdYJ/ssvnrfoD/CH+NP9Gv9eb6Arx5J8f4Tfoe/wTfp
G/Pf9VnKJmEb6qI8a2VGo8Y97cUcxXWE2wJbYLbVWb37y63mNdOqN9abUHfXm+wFz/dseh7nNXsj
vYe8OT5344HGg42HGw/4OvzzjUk+sVFdyZzqhPc8Nlpm9F519+ffyQ/zTtcluqc/vF/ZI9Nq2TST
V3e3sbmOYDyN7c4hhj3V7txgWvLDGguYRCbOmAx14V3xqJgU93Sjv85qmm/sbLze2GPmzZ3+CM9a
Y59vsFyuGwB9vunLqSv1jbnpU51lhadbfJhbdIdOdRYxdVZ3v3vEd6hs2r0N+1WXAvXqK6xryG2p
m4H9Mq1ajHW36sZB3wfdgwaHL9Ld4Uu4MOPT+I6eKADXt7k73OvuFZ/R3e/LMU8YNWXGhse+sDNh
plVjcvmJU31uiy/2ZMhXkt9fondPGxwGR9l0ZWdprWnGqDndYnC8DW1h8dHQHsAiWr/VP++z+wd8
V/2X/dd8V32if8lf5L/lT/Ht+Vf9u/4njWSjCtoP2CvCb/W1+bN8+33JPr37qnvLZwf3CYFzBDji
/DW+ad9cHdDo6RZ4eGPdI3VWS8gbdpI+Wfh2L7QKsEiae8Tc2agzR3seeI96lj0PvfrG4lPtwJ6h
xuxGg7vfs+kdy7d4J0trvXuNtUwEtFCJvkTfyDcyja1MDSN7w7xhjmJgA1Oj8wJbRzTa3HagnUFg
0ZA3ZLTU3T3Vzlzx9lvuuNe9j9wWJtXd/9b1xpv+iMZhX33jbX+Uz+L3+Ev9LOjvFd+ib8W37tsC
/R333/PPNEb7U/3doEdA8t3wdfn6/b3+eN8dv+xv8e/47xun/Rs+N+jLiH/oI8/O8237Qv4Y3yPv
frTqFlfiYBwqlCB8KMOUYRihjFBGoFW3V//l9ozCQqC8irWAosZaQXkNa8Pawb3hm2FvoJieDmL6
JKYFcf0eeBqM6ToU0zPRe2Bfwklcib2J9p46hmJrDoqtNrT3lJ3IIt7EqohjxDGsmsglcjEnkU8U
YBTxZeLLmIswEAashnibeBs7S5QRZVgtisLnUBRuQO91taH3utrRXlV/ht7u6kB7Vf0rYoKYwP4N
8S7xLnYN7f7+54iJu46YuH+L9n3vIh4SD7GvEr8jfod1I67ta2iHqx60w9XX0Q5XN9AOV9+A72Zh
fWifq2+ifa5+hPa5mkX7XP0Y7XP1E7TP1QLa5+pdtM/VEtrn6udon6tN5abyIfZr5SPlI+yRclf5
e+x3yj3lE+z3YXgYju2Bx5LYfwlThUViT1C0xUGcTcUJ9PYVGfZm2JvA6AVhBXhY2MkwAx4eZgSR
9znE3H0CMXdRiLn7JGLuokHM/Qb+KfT21X64sxYeA3fWwj8Dd9bCD8CdtfDPwp218NhwT7gHfz6c
Ca/H48J94X788+GB8AD+QjgXzuHx4U3hzfgXYOTFXwSRdxx/Jfyvw/8afz18JnwGTw3/cfiP8SPh
Pwn/CZ4W/tPwBfwNGJHxdBiRcS2MyHgGjLy4DkZePBNGXlwPIy/+JRh5cRPam8uG9uaqRHtz2dHe
XFVoby4H2pur+rk/PPcHnIH/ywZ+Hr7hhNfDPdHxC6pW1Vdwn+pPVH+KN6o6VZ04q7qquopzqq+q
unFe1aP6Oi6qelW9uKz696q/wJtU31J9Cw+phlXD+CXVd1Xfx1tUP1CN4n+qGlNN4H+m2lBt4J2q
36h+g//rfUf2vYFf3Xds3zH8z/cd3/dl/Pq+k/sM+Ff3Fe8rxr+2z7TPhPfsq9hXgX99X+W+SvwG
2j3sGyAKdmJDT2NhRsR/d3xs/Pa0MFdBPJaZLuYGjM5MJ/isZ/rAOTfTiiQnMwAkG8OCb8JTyvQD
qYhxg2/CU8g0AymHsTEMkHQMjO1pTBHT8L+ZN56+o9QRVoP2PSsA2BzTPjv+GQfea4k9Hp2nzpwt
Lc6gT+7ljuscx5L0dP5c0YNcz8k9U9HJvcw0rzFnRR+Z3+8t0bflrOSLltjspTx17kZpsa5X58jz
588VXMmfO7lXOvthzVxP7oZ+zmvx1oM4ZAGxZ8RLg6MeFCgNgr8XwdHhDTHx3j09DduQQeuelBbn
i7njJ7d0Dj3tTYAtyNGf3MtbNhUVxOSsZIRyLPo2Q8TpFlBfVWzN0RRt6rfKJj0FTAPwMJlp8Q4y
qcxlJoa5Au8I71lMlBbnFRj38jXHdQWXwR3HP7xfnjpn5XhPLqFvY+4y47lxufF5uuIUfUdBqsnD
3DMs5azkqb1GqIvs7jwT6PMgcwtow8rMMPPMEuwRs8SsMhve0Mk9fWTOSulNWLyh0zHguT36HG8y
0E4a1GrpVEFMBu0tLCo4lgT7dcwE9XqML9jNTMvrhP0Cz7JljEG9akcLuvMjvUe9eueGc+OETV9/
cu/kXsZiacHpXkNeRsi4V3pTN5AvlhYDlKcpuFLn0K/kT+sjvQnenGNJJ7dqwd1yx3O7c7v1c5lp
uePAjqI+J3fg+BSwhQXYgIa4wDvpnWNSvXYmwhsAZx6Bz3pGC3oU573j7WeymFLGyjiYGmQ/eN06
vLa04GRJ6e1SQ26c144siUpdlrffe9V7FWhVrc+BR0YI+pF+f21p5lpBd2YP0wCsEsNc094ET+i2
xOaOQ/vBT2ZA36Gfy6CB/wELHdcxQ8d1p2Nyx/Pd+UdNWmghWPRtxi1mPGMsrx2iOJ0D2hH0cZwZ
L3qQvVQ6pR0FGqIzaH2bvi2v1nDtuJrpLZChnXNWCmIKLoMeWrzTqB92UFbA31tMjPcG0kSXt4s5
AZBtCui3xzsGe4QkERaGYAhvm3fbuwXOFuntTJ7XDXrsYaL+0bOhT1/11gNvuJG3DGYmI/4d/Dtg
Yvou/l0wS30P/x5G4D/Af4Ap8HF8HCPxSXwSU+JT+BQWhs/gM1g4PofPYRH4Ar6APYcv4UuYSvGa
4jVsn+JdxbtYpOJnip9hn1D8XPFzLErxC8UvsE8qfqn4JRat+JXiV9inFO8p3sP2K95XvI99WvGB
4gMshuwiu7DPkN1kN3aA7CF7sM+SN8gbWCzZS/Ziz5N9ZB8WR/aT/djnyAFyADtI3iRvYp8nh8lh
7BC5QC5gL5CL5CIWTy6RS9gXyGVyGTtMrpAr2IvkKrmKJZDvk+9jL5EfkB9gieSvyV9jL5MPyAdY
ErlNbmOvkDvkDpZM7pK72BfJJ+QTLAXN4a+iOVyN5vDX0ByuUe5T7sNeV35C+QksVflJ5SexI8pP
KT+FpSk/rfw09obyM8rPYEeVn1V+FktXPq98HtMqP6f8HJah/Lzy85hO+YLyBSxT+QXlFzC98kXl
i9iXlC8pX8KylC8rX8beVCYrk7FsZYoyBTumVCvVWI5So9RgucpUZSqWp0xTpmH5yqPKo1iBMkOZ
gR2PnIqcwgojpyOnsS9HzkTOYCciZyNnsZORc5FzmCFyPnIe4M5nSPUZUn2GVP8IkCp+V9H5FO+p
bc+Of8bxsYieCtCrmIKqpzfo+0CqpVfAp5PeAuds9BySSukHQCqil8E3QRWCegoqh55B9XX0GJDS
6H56BEgp9HUgJdLD9O1nsfH/29j4lFO1KhxP/1+r5DG899Rovj5z9uRW5uxrt9OtFYWUmiowqzMC
JxbyxzRt6bc0ba9ilF+brb2ZP0Y1U60FUW+snRpNkzNnMw9kzuZ3gPrZGQGdNiNA2SgnrJkelz+W
m5V+q3o/1UNNOSboWFrjWKA1VB/VR0fSCXQyraFLgAz/5b2/uv+1g7AN6dfUvZmzb6xVFOYMUmqz
2jEFW5BJatp04F6vtWqzMzq0TqrVRejGT43qivKNKc2nG+i90k1XvCvRmeJKdWw6rdWL1W10v0sL
7wjvacvKnLVpqehjrdp2V9GJhYrCD++XOavNdskZdqo1fejNeirJ1eK67LqizVaz9COLPpPJ2f9q
JOWHusi77XK42IpCZ7emLSfk6nUNVK3Ssa57VYRryNlAzWraMke12ad6YKFms7Py9dlR6RHO1cwD
Wlt2VG6icb8mpGapA7YaSkel5TXnOaFeqVqKUe8YUmC/QDHlj+lSQZt0GSAjcO44n5QdOnaQMlDF
edGaNud95y51mDp4bJSKPtWjcb+xljnrXHJu6LQUf6rT6UmPc0w5N6iCzOFsbe5uRWF6Higtr2KZ
w2aQMaZHpJ/IzaveX70O9A3sQc3SObSxepFqp7uoYVqk25zzwC5jwCaD9FEAgCbpFbiOhk4A9oP2
iqRpcORQqmPXKRNFUklUO9VXVUrdrCqlw+hDtIVaozaBFmZfDcGn6e6pWU2bK0bbl17qintN5Upx
WoFFsjLmXPdcefQj24wrwtZS2eqKcp3Qraa3qNk3am3arGFt+6sa7eOyUEVhbpGrweWBFiqIKoiq
qC/Qvll/7KbrmqvGVUOpoR0zhysK36yvWEmTjfu1Ok2bmlWzFfVUq9bk6k5P0VldpS5rurVcqwmV
y65bwFJ3qT7XOL0fFDtdSLvB3BcCmnhgb6MeghlzhL5jX6e3ab19jLoJJWqUuk1N0B30VWqZrqcD
9GLViVcn6WnqOvDhBfoG1AzwbOjTa/YxOoF6rMtC/9/S42c49BkOfYZD/xhwKBgd7U8j3YsLH4+p
bFP2e5jCfs82ap8B0i37OkZY1+xz4NyIbcA+BqR5+zKQ+mxd4JuwTtpZIM3b2u3joP5l+yCQ2myy
vQsjKk/YbUDibfX2vo9mhafvqKwpt57uKPViFjyI949HJ6rsc5k96o0MY1pcqjO19ktL4EzXl4jU
vgRwPlH1kkd9N30V1jhScqRLvZG6cDz6tcP2uddZeA5ekVqbJKeSSQ3p3QUNlY8T5rIOqO9qjCnL
R4xH1zN7MmtfepKoqoqvSqnKqzpRVVN1uepa1cApg2G+arXqviO6asehdhgc6qosh//UAwfv6HRc
d/Q4SEcfuCYRXFMErrl1ylA1X3W/6gmqrfuwZtVOVZHD5rituZEW8bIm8eHrOxVt9snM2pc1mn77
uqZfM5KU+Mph+3TCXOJUTr0uLlX3esrLmqoIe8fLd9TskRLUJtiaGvCsgaoT4BmrVfGwRUY3eMqm
w1DVAp7z0PHY0VONVYcdj369+8j00Umki0epC+qiRFVidFK35kbCXFpEZo99LrUA/LJ9pEtTn+p8
e/zIivpJgeM4WdGmsbzWbO+H7VPfhRpOja4Cuk6L0IC2pZ14efq/snf24VEW5/7fPC+7IQWklFIK
eStu9g2yu9mEl7wQaEhjQIyQUqDZ12xSGqOlkSJ6KMWUUowppogUkSIiIqaIKaVIEdNII2KMFJFS
yqGImNIUMQcph1KkmJyZz6Ta9tdfj+eP33Wd63d5Pdd+c+/9zHPPzD33zNz3zGQfUZJCWZYqT2VN
lb+yvqq0anZ8ryjJ9v5yFN9yoez6rSNFOe6oOn+ro+p6tRafUnWick314MpAfHHV/spioROh06rG
qi1VB6vOVh0VGt2ZW+YvdW2K58SXTzhzywVvt9Becnx0oHbsKVHypICRvSx/s/NQblluWey0r01w
6vy782uzR3hD2SsctbP2V2qB4+HGbEtGet4q1+DchfbTOSPtR/NWObpiq/MvCw10ZzcWlI0/KGrU
Ka48Ubu8jBr7QcdicSXlnvd2Txjm7Y6diO2benJCfWy/Iyl/s7CYapGuzlkw4aRjSHFd4Lhv7/iD
GQFnY2Vi5UShh02izWWrz6kMVS4StVgi26jseuXhyo7KM/HhWMCU+Lx4XXyHbJ9bLghOk/hsq6yv
rI/vqozHk+Kuyk3iyXhl+y0NgpccLxF3a4SWiyuvivRbhc4axLcFlSfj1fHauFFWFG+LH4h3Cn0v
rrwqbK9clGNnZbd4qrhyTWWrNyRbPbDNMcR+empPznTHEGH5dYG62Fnn0VlW2VMyFmQUTghN7Jxw
xpHja3DVeLtLBjv9ga5Al785sC27wLe8aKErpC5hfy32o9nNrku+Tmds0smihf5mUdpidcUvV66K
d1UNjZ+qGlGVGr+QXxs/Ej9eNdA701mQk5jd6DjnNkQfHJ3td5xydfiScobl1bsGK9vzdmfUB5Kc
G50bA9XFtcW1juGOIY4h/i2Batem3NO+0fbTJYPtR8cfzG60H8zeKPpmTsHCymH5ex2G47JvsahZ
YlVZdWJlepU9Xlc1XthhRdV8YXELK3dWNVftrlon7VBox6g6Ed9QdbHqSjy5qqWq5ZYZVbGqe8Td
nVXnq1ZXOkRd6kUbtcXbqk4Liz1RPayqoKqoakXVxqp9VYcql1QtCzRJK5jaE1wwZ2/geO71/MvS
XgLJrmECcxxJEzvHn41tKZhfNDt83rnRt3zqmeyjsdWxZnFdiTUH5mVMzCj0tjrqpm+wX5+wRHhz
Z7Jne7szhwpb6iwZnBGKtcR2563JGZYt+ld+rX9LbF3RQm88UO0YIu/lJ83dn7XScaBkjavenVzY
5C8rrvW1+Tqz5mTNcVpd6YVDxrdMmJ7jcA2ONk3tiZ2Pbcyant824ZJvuW9XyeGpvS7N1xa7GGiy
H7Ufde5z+u2Hss9XDvYvDB3xb/F250y86cCE6dkr7GKkcFrFyLQve7djSOy66O3N41cUJvvvcG7M
b3MtijY5lk4oDiTflDNpvWNxZmO2P2u6aDHRQ3LLQucC1WoMzt8sx9+MVaKnbZQjr9DbNm/31J7A
cdelQK3oN9PzN5ccy0mMn+N3+l41Xvv4v08+/u+T/0X/ffJ3v2M5soPPv/SI/NsnT7To/q3B5eKv
5t8YXCJw3eQCwVsdXDDZI741TJ4ivi13j8xuEN+WBIXX41/kHij+av47Jg8V3+YHiydbxLeIb6v4
Ns91Mbv8b/rHh/9XMjBx6Ie+2kiPfj2zxpPuLPSc9I1Iy0nZN60rpSJYF1zs6Q5WB5c7DgZ3BPdO
y/EmBzuTj7iaks85xzpD0wuCycHRQVehJTgj5Xyw1nvE0+1p93SL1NuCB4KdwePBBnFvx6Q6t91d
5C137LZ3+xO9S+0jQwXj1nlq/NP98TFJ/q3+Pf72lNLJ2yNTIvPSXI6hkVrHofAc34lwyFvuLQ8v
8i4N+b213trssZ4a71rxXM2oPf6VpTM9I+3dk7cHvZGS8OFRrf7t3qVze9NGp3akDYmOH9XqigQK
orNzO3LaAmXjhnpaxbdlzpnJ81x5jhZvXvjS3B73QN/A6IhoasEc++Gox7U4WpYyP6fti0dz2jyt
t1RE17nyoluiMfvhQEGwK80l9ZOclJ3uGzG9YFqX95rQz+LMmmkzfM3u5nGpoXsKFrktwU5vV0at
c6xvRKmWWROaH7oj9VjWcN/s0ArXNudKz4LI2lGtnjn5JyIbRrWnGZkducXu5tSTaRfyT4xJyroW
2ZE+NLI3xZPsjbSF1t28ILQxK1nWyR3L7k3tdva4IllJ9u7cDu9SWaPwdE9ryv5AQXbclZdW5yye
2+M4kdYpSynL6VziG5EdmNQ240Bma2brtBnTusalltUXLHIWBjt9q531zrGuvXOuhMeGA9n14YkZ
MzyLwoUOT3KSp9VZ6E2WbR86HboSHhZ2pO0al5o2b1Jd+lD3eE88Nd2xe5zfdzGr66bT+cuykrO7
xySltPi3uotG7YnU+nZ72gNnA9bg6DHJrhk5O9IuuEtnxQMjPPFwsbsgpVS2fOSarFVUlH9M0tz2
lCvepU5N1jFQIdrtUMBvr3E1BHYHylwRT6vrXKAgbbQrL9jgMub2ZFwLnPZtzBJlCZyfdDk2Mpbu
iLljrqa00cnz7N3R2eUzohdjibFhrs2eVm+OXdhh8pExSZEpnlZHS8HYvOX5W5KN4NrgBmd6zobo
fEdLyG/vDtiF1S8Jep2FhRbXlGCOb4R4akqwPGVfcF6aV7ZxcGnZTsfBzKu58aDXmyPbOHjEucAx
X9q/c6u7ZdThYF5wSt6RvCO+5mCTeG6z/C56TSS4a2575uExec6twZLMGtG32oOdnk2uU8lHMmt8
I0TvavPd4QxN68oantXgPjEtJ6Ui83DwVGa9c3pKhegx9tRe0WuqwyeD14LX0nZEjHHrvE3uZvtI
/xr/9jRvJC+rnJ6yKrzS7Qle9tS4lvrO+xPDx4IXInWZ9UIr5eEFjn3hDvHZmbbD3+ouiuRElrpL
HbtDReE9kaS0hkhtyO6sSdWyDjhDWdW+1W676HFLvUtTSr2bJ9VN3u5d7m1ILsnYkVLhXOBPdxzN
rnHs9xxLnZg61n7YWRywO66npju1aIH4FGUeTm7K7QjMzqgVfS3mWRVd7b4obLMpujHlkKNF9rXU
mZ6TqZui9uCU1K15R8Z5gk2jWqML5fdoaTASvSfgj96Ruj45EvV7l6aNdk505QX8afNSrOLbkGhF
dMW4de6B0ea04+6KaEtJV/I850Rnd3JTtNHebe9OjqROdG4SZWwRWqyX44bvfGpHyBPyhNcnN/nH
Cs2VhtvleBMR2g4NFFdZ5krHbley6J/X0zY7C91n5cfbJfpOT35FaGGoMbQ6tMyzwD0wqy3NGLfC
dyiyK7LDNdo+Un5C6yIHIttCW7I2hJojnWI8S40IqxOjz0Q+de6Ye517WaAxuju6z58uxomuUi2y
wbvUFZF9VH5LqciYUbAoOSm0O7Q/dDClIrkhsz0YSakIXc88nFYSHpy5KDxSXOk5DTNO5Z6xrwpr
4cSUCt9q1/LQ+ZSK1D2hs8HRhcucW8XY0xLaF04vPO1bkW4NHUrdHjoRuugbmHMhtTV0dO5J93gx
whZGxNgc6Zp7MndPeGbkgm+f68KNhwLXowOzt/oH+wdHqieVjxnuXuGtzjoeORU551wTtfj25Y12
N/v2+05MOuC7LvR2JHI8Up3l8h3MOZc1z3dxWlLUmj40sC61I3I5JebYJ3pqQ3S/uzl6NFBasjly
LXpajLhXCtoze2JaSoF7oHtgbLDzatpx0UuWZ9VFr9u7565yHI2eF31wdzQWTU0zhH20RvdHD8YG
p+268cSo7ugJz6bcOWltjo2egLCws2miVV2XU674zovrou9i5qZwa8jjLnD7w1vFHGH3xL0bQmWh
2XNOeBvsI7Pj02O+od4DKQPT6iKjI0P8h/3HPCcjLtmbIsmhoaER/jNZoz3tvvPJ5ZHF4XpvZ0pB
Vnk47r3gHp+63l2QNS801Lc6e453r7jEvRm75m6ascvfE4qFYjfZQ1bX3vyYt8t7Kq0rrcvdnHbK
d1qUpGBS9Rhvjtd3Mbw9sjzS4NmZFQnYUwNF7eHu8JlwT/iSXbgPY5JuPORZk7V40mUx3s+IlIcq
3Gdzz6QWR5oC/tSVnri7OaXlxkO+LWJ8NVIGessz1/tn+hf4N2Uuylw/eWyy4ZwYXhPe5G1LiWVt
C19N9mYlBc9l1ocsIY+3IVTqXpG9KdwbskS8oYGRSKTauzhlvGd6Zr17hGdieInvfGh8uCaUmrY4
vERYk2g1uV6ScPrj/x/5+P9HPv7/kf91/z/ydyuqg1f86/ghwxK4atHt10ZVi7+a/dKokMAeZ7Hg
dY+a6QyIb6edpeLbiVFF4q9mPzJbRBP2zlE54q9mb589VnxrHeWYnS6+7XZcFt9aRo1wDv1ghPgg
ekg4qq/nxEGe5WaLZVDPf/O59A/fr36EZ/6a7p+l7e3/9NODjf8zDbxL6i+fJPEZov5yf/jf3Psf
fD5Kuf9peZLFZ7Tl5oHX5DXIMsgqroHi71DxzSo+QweN4EodZBeXR/wdOMg/yC/ujOeuvPziUzCo
CAmlg4oGlQ2aLa7xgyrExyq+jxdXDJR/FWUHSweVimek/PlCynxxzUZukbjEk6Jtb/74HEL/OYRr
xjXLWE4jZHLqwMupAx+nDvycOsji1EGAUwfZnDrI4dTBOE4djOfUwQROHUzk1EEupw7yOHWQz6mD
Ak4dTOLUQSGnDiZz6mAKpw4+z6mDIk4dTOXUQTGnDr7AqYMSTh3cxKmDUk4dTOPUwfSPW/H/i1ZM
0FYZ/Ndgwh7hR1kSm/7+M6BAfIrEp7Sft+tD/j+m/Sgf5Oz6b9LJ+5tF2rJ/4G/o/0h629/I2fVh
eSjv//Dzkcq+7SOU+V/Vuemfl+8j6azob763ic8BS60txDXHtt3mEFe6rUZ822mL2/aIa4GtVXyX
Vw/XJfFxCP4SkSZuW0WaVlu7rcO2qF/KYdsxQbfzfFyknW47Ka4zoPyrqG4w9MFVLy75tx2J8toO
Xv0bvCSkLRB/e9WVaPRfSeqi3CJd4pBEuXL55Y/fb/xP3m/8nvGexctbjn285djPW46zeMtxgLcc
Z/OW4xzecjyOtxyP5y3HE3jL8UTecpzLW47zeMtxPm85LuAtx5N4y3EhbzmezFuOp/CW48/zluMi
3nI8lbccF/OW4y/wluMS3nJ8E285LuUtx9N4y/F03nJ8M285voW3HJfxluNbecvxTN5yPIu3HJfz
luN5vOW4mrccf4W3HM/nLcdf5S3HNbzl+LaPLeNjy/i/WEZCgidhOVFLp8Un7OOw+mhLxd8zH37X
reoj+fLvB7yBH6ZJ6O5/7vC/+EiZPf2fM/88/Qd5NfR/ln9I//XeB/eXf1Aenza7/6oQV0xc88E7
tIXaPeKarS3TVmiNgoqJ+/f082Zrq0k3H/468dkornVc88W1TDwh7y8TfWhw/2+1nv7gt1p1fqvV
MH5qHLQk8iutyfxKazq/0nojv9Kawa+0uvl91jH8PutYfp81k99n9f4/kytiUBn9WSx9vwK7wB7w
BHgYvAK+ISwhlfTL1VMJS8EIOBucAraAqyVqZaAfLIa/FdwLngEPgStJkwx9GWyHsxh6A6UdBqaC
LrCAuwvBGvA8eBzsRUIcTATzQOJv7SRYD64FG8GzEnUPGAKvy7pT0+Wq5JYkdCJ/j87SuwUsBwvB
dFAD94B1IDJ7h4NIfv8C9EDoq6JtY5wxvh9sANfImuo10L3gLzgFVQfeK1E7B/4BfFumFxwxiku7
F/QrPPUlcDbSvgA9g7s90E3QHSDy9Tuhfw++A74LXufuSPBu/j8VK9K/Bm4GE0m5gRL+CfopUiaA
/8GaQxt4Evw5uB18CfwJ+GPwMDKRY/66H0ULmuclbZ3O3e8hWZ3QfgxEgv4M+DOe+iN4Fvwi/BdB
ZOq/BPdR2ovQN0D/DlqHVlpqBdeCPwDfAJsVSrvVjkLnWzYLLFAo7VMrgb4TzKQkQyk5dTTc5HUA
/mfAbjhoUv88+C1wp1B7gr6CNGjSnAYfqzA65F3tApwW8D9JMx9MgvMQKc9Afx2kX2uk1F8Du+Bc
hf5sPx4VT6GNBOou+rPEVdxFmoaetb8gn5bVaVkTe9O/ARaC2JX+VRCtmqD+XSTQvnoJNK0v4lYp
U/EvQY+GPgQ+TEnWQO8Cf0iaMaBf6Q36U9DfIcdqaI1cOsFn4dDu1s9BJ4Ol4GoQm9f6wLcsYkzT
n0OyA5n0BTHSyrsqx08qTJgjUmLzIhKX8snXxPaEPyPRBn84fPRpzib9m+ApOErCq6AB3sKztKC5
EA4WZf00fFXyJeAWcI9lFvgdkT4b+ifgfonGIugIOERhginwkzK96N0yzQBwKDgMPETKbRITUxQm
XBKcG+Fn8mwBdAb4edAE08HPgEngVIXk+6KkhWXKXPLAfLAE/i6J1kclCmuU+CT4LNhKysnQG8Fn
4PhAVR7qIvr7LPqXQHM5qCM5BP8c2Aa+AP8e6Df6UdbuNE/9EPwj/CfA3eRVA/0OtBea0uo/BSmz
GDdAbYDgPA3/aSS/Dt0D/gFcAf6WkqBt/XkkO6E/i5wL0K/An0jd18CZxF0/nLVIUDYwHGyGQ0kM
A3wPvhv8FRzVgneBl+BQC+HNSnqcRJuNu58kr8fAH8Ch1fQwOAYcC37K8lsh4c/IuQpSNmOWQjEb
JBhYhZELbgEXkzILuhKMU/6VICW0onlrOSk3k8YFohnrF8gdq9B3wP81uAE8zFM/g95pCQq8F/o8
iIUYn0DO18E6OD/iqbeRiX3qHdzVoNGtjnzzVdKr0eNw30bBH6HGjYSxckzuPSboRjj4A8b3oXep
kVzeNRkTjIW9+2Ua+ZQxW/okuprj9lo6BN4k0SiV3oimvIt9vacFeuA0y6fMhyVqm5DPvKltgsMM
ou2Fbpd+mkBBW7eTO+Oz/j7l2UwaZm2B6wTnUcs1gRVw6hPGI01wtJ9SwnqJ2hPc/RESVkJvIc0O
cItlgUh5K7kcUSjz1V/vu0ncZczXniRf5QtdBg9bquWcIn1X/ene9XLcQDNqFl5H+l3odrH0zYxX
0HwbOn8JfJnxcwF5PUq+eL96b+8ogWep+5clCguU+t8g5YgyS//qc/hgjeS4WrUaOd4vfUi9SaJ2
l/RdNfwNXc31puQbNVInojW3UMIttI6cX05TqkrSLyPfL0n/U2vpXcH4IPmv98rxth36ld7n5Xgu
rUJoQPicBrO8dogW3EZ5tkkv3ZxJ7uVqlkEnuyg55TcblK6kR2FcoQx4Owb60d+CVjagfIAH4FAj
Yyk6xNs0sRCrmnkfBNeBt4FYnX4PiD51WlP/DYjPZtjBANLWg+OpEZ6eoeZB5XVkQd8F4o0YeHoG
npKBx6K/h4Q5oBcsgq+8nSukHADezt0hqo24+0L/HCrvpoHc1fHAdbwIA+9CjAzyKeUtPw/uAJUX
HSHNBNLgyZhO+L+Cj72Z6MdcAEd5NaQ36CkGPcvAU9Xx1Q00aSjPJ59n60F8KuObpKRd9Ch89Gai
VUN5Pvh1BjoxlP8wClTjTwrplU+1DaTMRjp8cjROg7Pg4JnoqrTLQCVf1f0aWAXeQUq8VuNGnlUS
KKeBl2jSIjretc6oaOJxGfR6XZUHyzHwb0X8JscBtKcrTw+N6feBjDw6ddGV/zwXpMV1eoSIpyRe
xd/GcjRaVnscRLKG5WvUTlPWi6dtHAGV9R6Er37RR0VkRBAGI5iONB39G9iVXDdhZpRI3KQTL2iq
pw8C8RL1HG2YRO7uxfN/EXyXPktPMYhcDKXbn/IUsZ6+gTR74WMnugucDAdfXXgOUs/EdMIrs9A3
hVY15aUrWyIXHRsQkbN8ajM0c4EehMMIr9OL9Vw4+NWaahdsRl8EYqUGtEa0aKh4ZFl/m0rOFPAr
pFFx8ct41yoXokhDec70cUPlQoxmqAiXqNlQ3rKycDUCbKS+pczReCzGPOiHwPvAb+CVKQ/nZdJ8
m9kcH8x8Cn4UvA28H8Tn1PFSdPwEMUdLLATvRSY+j9ChxFNgFzJH40Hhvwnbk6hK8iZ0I/gIHLwv
vZhS/R4aH9hUXuJOkBIaypdTXsoDIB6yMRP6YRD/R3gREqdrX6MvS/oXYAv4PZ5SfmkD+CBYBCpN
4n3pqvzKow5A4+VqyhtU+VaDPwavgKNAvD79S2AFqLy4NBCd6Oekl6hTa0PFKfi6BvkK32kWLS5T
ngCPw6mHXg0SRxjKn8QXNfBg9X0g3rWBN2t8F63SI0zsWSOC0/8NWq0zEN/ZiLls9GuNMUpXXhxz
gaHGnP14RBk8Rd8xiZo1hfiHGrOYFQu3qYg+BjKWCs9Z8ut7l0j/ivRE39qjkmPWMLPT03VGaZ3o
1crKkslKkU6f0tWsqtZ/GJM1RgbjBKhi8OPgMe4y42sb1Tgg17UM5i+NXqypVQVqpLEyo+GvaujE
8Mj0+nN9QwRnIc8elmhTmglKWjtCetZwNOVX1IHMqpqaAfF1raweiGhU0ujNquZNVjzMb0OrVSlG
HhM/xHhW+n5GObnfTXnSezuln9DnFfJvlxyTGd9knLfi+ZiMjZrSPG1q4rcbrNJYmSvNT6qWJWUc
ThltpOY7RlRD+UU3Qd9MfZUPrOrIKoGJX2GwGmOibZNxT6+jtDNJjz+jvYuE38L/HOgDK8G5YClp
HkHOc9DMShpzsbYMPxb7NNppC3wDGz6eDW/HNgJd4fuZWJGh1me+ivxGuU4rvDuBVtrIfEvZLXnd
Cz4E3g8uBb/V3/rlAp+Hs0bZHrRau0CHOqtkWkefVUheo6wIVOt4GywTmOkEWllLEdG3hfFQpqFv
mnieVtColZjw5947QVn3Hmrh56k7ZS3MH8n1Xo31FoNeZuJzakoa3qaBbRuUx0R7uvKg8Jb1Erz6
d7Al7FNvoF54pFoNdc+VmNCGz0/EofnAWqUxpOFNmWjApHYma2gGq2FWvFMDj1dnLjOwPRFrW4hM
JUd53cqvo8/a1MqestV6GRVqzOYavreGJ2niD9vwx3TWcq1/kH1Ea6SnHO09J/hfJiX+icYcrWPV
plphVqtbBaDyPY70vcC4LWnl77FGbaVPWVkhNPFGTOW3qPXVdNkWhvLS60mJ52CyPmZSNnMwiKdq
YxxIgmPDA7cx45vKkrENE/ux4RUYyvNRPgZry1a8F2uMHBnxjBai6UnQ2JUVazFVdKPGRvIyWUU0
WOMVc+IpkRLPX2PlVqN1NEZUjRVsDc/T2El5GOts6NCGBBujtKnaehwpkWaw/mmgeUONnGp0Jbq0
It9KdGAlrjfxHq1qHXUH3iNWrStr7JHl1K5IFDGvxOtyZ0d4jJLWwQnUBTnmERD7N1kZtqIZK166
SWxi3GrZLjhq3MNTNeeiQ9rXirdsZTw0lR/4dn+9RBpN7TKwemyoWisLVCOq8plpfUPFOKqfMn8Z
+J+GioyIB63KD2Qusyq7Qr6V2cHErkwVtX0iYZG4Sy+w0lJW/H8rNmBlJrWq+XoKtPJasVtDlR8N
2PDebXiYZjp8ZVHMWcI/rxD0BIlGO3hEoojXJN0GDujHi0SgFVi4xA74WyUOMBXK/S/DDT8bzAUz
wBHgLInCs6pgDpL4IPhkPy1yMSpJ8xtyoWzmzeBU+Ksl2rZJFPN4BZZcwWqMTJMDvQbcicy34Y/n
2d/DOQV9GeyBU4Ee7gYtyIcj/A2J74CUx/Y16DeQSb7Wx8Bu+CvAB8CNpJkJ/Rb4UP+z1fhmkv45
eAh8ivIcVyh8nwSjEf7zyHkV+t/Bi+A3yfdF6DrwyyDlF1F5BRZbQQwrtYEm9d9BHwNpHdtYEPnC
E6tgvJXPloCvwLkReg64Cw6tJixWYi0SepFPqYQfK/EF8Cx4Afw1Ev5MyX8F0gpilJP82UgrA+Ny
Z1b0hQpWSCqItSXeDk4G3wNpEdGjZRl41jYDmcPg++BkgR741fA74SDTwHKMR+DvALvAH5D+APR9
pIlDI988A4c0RgzOGBD9m58GsXDbHSCaEX5gBeNhBbO25Otw1qKfp1nxe1rufRvsxOkb8MyvSI4V
39hKf9fxoPTl3H1EoUyjL4BWqxl7mPft+Cqs22jN3P13Zvk7uKvS7CfNzYwJgxRKvsn8ov+eNEk8
y1qHqdZDKuC8xN1h0CcV9tXKuAl6L/i6Qkr4JySr9UwV/z7B3S3c3cJdNRteppwPIP9d6O+AD4Or
wR+AfwTfRs5T0PdDPwg9HWRtU4uAS8EWmaNW11sqowClN/KaxV0VGakVNrWionZ1s8HHSX8LqHb9
fDx7F5xPSn3qd6GHZXC+AXaAp+GPUevk0Jd49tOqvdBAFjQ+icEuv6FaXK3eqPWcVvhEecaN0Aao
PPbPI38FOAdkLUWfg549cOpYea5DDxfgVIMLSKPa9zPgNHAueDtYCZaDW8H30Rv11YrBOOU5wt2n
yetp6AaF5HInaZ6E828g7avT7jotrn8WHIhMrFHHPrWz0MOh8UO0Q4qmRodkjlqL0jOorHQMrTNG
tQLxl4o6p8Pfih+uPNX1pN8MfhfEroyJ0IVgEViqImgk4DnrT0n5BhG6MUXytfN9IwX/ZdL8CDlq
RfcncH6ChJ9B/0zpFnqOREOtTjfD2QSq+KIOOfOg72PcwJfQicFNVqL0mUibibbX8uwptLQG/jOU
bR74Ve7i5+jKW76V3FWNdkG/Q5qdPLuTHN+GQyyj3w+tIsSd0AdAFfuvpUWu8aw6O8Feg76SNCsp
4SalVVqnCD4xoEYcoecqDvgtsAR8HuuyQvfv0UMfVfWl5O3Qm8FF4HGwDWQl2YoHnojXmkg/SmQ9
wcrYaFWr5awimhnK15KltWEb2jPavRLlWSbjQREzSX/GwupBt4xqZY1E7ClXQppAom8df097jmfv
l89qT/VNtMg9GsnfQLs8J+ZqudrZDV/i4/KslLaprwG7kniGpx4n/VJ5ykh/QKY03koYjI80VMqx
rBKcmTIv41lyZG1Te41nLyiUfH2NPFWl3a85LHLfql2OA5y+CPTFBH+tPCWllWu7GCe7GSdlqR4V
UalcPehmNv+FoDfKU09aI7tFD8kzV9rTfc8i/7i0wIT35Hgrz0EZd0kUaS5LK0rYJnOB09h3QI5m
ktYr+jk7LXK1eTWxucw9Js+MGUV47PXS2zdu75skPS60sdYSkE/JPUFtbV+RzFeikQNyQsZYDz2T
szEN7Fq+1mcX+DuJQoKou/4G55rGsMv2jKQNg2jlq0hufH8tI+RCOVLJyF37T3I/Ip/VngGfAh8C
HwHXss/YiG4vyB00YSGX4JyipjPkTM2K9/2WEjiy3RskCksWaJzsm4OvKFuWnQVt9fvFErGl1XCe
5alnqcuzyH8YzsPs2U1G2vdZOfmLjKa1F7GWF/taoBeDJy3yLNYFac99AkWUFyBNjaBPSAnWsZTn
t7I82iZq9yBx1nfRlRfrWiY51q9IWi8l34uWe+T8glafQMNvy+NzIiaVOl9FCZ+QGja+0bdMtjL9
axbl/z65PAH+hNb/vtIbGqsnZtnebwO7aX25qrYKybdQ03oiyicp4RxZKiOZtQW1nlMjT80Ja5FP
NSaMsMhzVrJGJZS8nPSLpH2KiKODXKS0l7GfJynJMdK/1reGuldjXZRWytSDWN1XpGRhaVZsQ9pz
UD5r/lCWRIyiB5DcwVwgdxnmvC/745xe2S71CaPJ/Sjlke27m1nmLSyqQPYFkWObLKclU+A21kwW
MQ5vl6cZRR+8wSJ3YwXq9/TlwhmBDjOptdyjSYB+AXzF0meROwtSGimF753JUymC4wYTJepTadMf
ytx1E7xK2Rr7pso+0pfBSPIpaueTuwzQa5D2OPR90I9A7wG3WW60yPMJtwsJSQn54ql3e9+3yCg7
U85QpF/bjz8Ud/MTJlAXUWbjl5Z3pK321ysFvuBoO/o+IZ4NSRS6kvX6o6qRuguusXxJpHGQy0qF
fdngw9LaZdn0RZbPCqyijjNIc8DyJyHNJlcwhO1Nkn2ZXELcDZDL0wl3W+TsJvMld+3ZfpTP3tv3
CqUV8s3fy5rq1ar8snb6YzIvEZvLZwtYPXsIOgFd3S/1o9+QIDX2LJxXGBUfT/iCbKM+t0A/mCxR
tIVT4K6+T4unltCCwylnV9+f8S4mMf4kkPufqPtX5Azer400SdOyVdKK9KreZyxyLyOTUf1rxH0y
5Xel3gRHlucletAvlQ0k3Ez5Za2/Q30z5UxkjpQ9wmT/0faq5Nj2So4N38aGT25O4ETEBOk/mHi5
NmZVK2vvxjp8pHXcZdfVZJ3KygybxMrPAPyrAdw1HiP9Y/g2M+Fwps64TSH+OXujBn67iTduvkUM
dVBiIitdNtZhEvEWtDOkWYmfsI+n2GE038QzYR/Ehvdu/RV4TfKt1DFRncf7ukJ5N9GN10G0lZhA
vt9CJj6YuVohadiRt93HXbUqiI9tXIR+FP7N4FD8VaI2M0UhUac6qahqrXaN1e4P2jMaKL/aUVVn
D54nJd649XPo8Bg5vkxp1aovMYKNvXWbOjOzEc0QH9luhVax2zaQcmp445qKFomJtKtIfhM8qGhG
UaIejThFU/HgvdxV5zyTSHM3/Pky+tPUmQq14+8gZRclmQxNDGuoOJeIw7ZR1Q4JameN1UWrQ1kp
ctSqMntniVhRIrtFVrWTolbzOA1lVadK/rrzKzk8ZaU1rWqVGC0lsgedyP6OVe2PL6ZUr6ETdKV/
H/uphX6J1rmNlv0xKaNYSwF8dbYhSnvVSY6N3R8blmzMxALVPvVTPPUcqGhKZVX7QSrWwK829yJH
rVJ2wnkV/Dn9Qu1I5qq6I5/4OnEEOa4D1cmKFO6yx2FVK66caLXdCV+te6vzM1/mqdPk8iK4AsTD
N5XG0sF8ysb+iEl72dSZ233wVYxPi5i96Ir4yKpO2hDfGSEilN8RaxzDtjmfZig7mcQI8yk0/zvw
OMjqhEGfNeEbRNbGUDjKPr8Hh6jKRsRtSwOtlGEcUSqxrcFaitGkkDIQTVufQRpxscFqhvU8udN3
9B3k0gNegZNKXTqQzAk3IwcJKsbvA3+tkPjo11hRLXVnjNLuRvPEPsar/VgnkKeM05QhEXoGct4D
lR3S+4wOKdMcQpt+uz8ikzPap2i7TyD/P8DfUDYN+jJ4BvmsgeisXxnE9dZvQs8FC1XvgH4dZHy2
jYJmPBGev9Qh59aMAXAG0I7sEw1Qu1rZpFERHzut+hUkVKp1M7XCRnuxG6upVawcxpk1ILGwOZ6n
2IPW2ZmyokO5tcKaswX/WZbwa6TfD+cNSvUGozE7HdZu5LCPY6gzb6rPvgHS10SflS3byLONqmdR
L0YnqzqTxq6ZYaFlLZRTrROqvXX6qU3NdPQ1mzrr8gItdRaZf6b8KkZW7aL68mzKHwe9oANU59mI
sk11Ck7VlPayqR1qdlusw+D74LPLaWOnzGQtwuxUyF0ki1azsnJrYeVWSmDlwSQmMtivMX5Ayhj8
ySA2Y6J/89OKRiYrqDZlS+xy2tTuEjOgjbXBAYzJA9CJDfk21mFs7PvY1FxjwxJysQ1mLnOC5QY5
1hEXrJN0UqI8eyl8j2rpdUiO8C46pD9AjuyMJ7LrauPsfSJ7Oua31Myu5nQ1m6v5F/l7wU7wNfBl
JB+SaP0cnGPgm+BxiWJ2vkHOzmAUvCxRg691wLkV+kGk1UKTXsSnxBHgo+B68AmJ+gOgBc5VctwD
HgRfhL8C3A/nXejbwafAe+G3km8SnLuRuRR8Hc588AXw5/BngQb4PZ51gLeBNyCzi7tbqd1kOC+B
Z5HzF/howHoe/kOk/yJYBKIH4QVJRBsGcvQ2aHX3OaRlwqcWGhoQnsMNeA4yDWUw0K2OJkVUfgOe
gKRVqX5MydXqXD52os5CvCl3DE21M6h6x8/V3KrmTfjFPKv2yhkBzBVqZuyf++TdXnJZAzaAuyjn
nZSEMgv7lymHgtR6AHYyoA/8E2ni4DxQlTkdWrWgDRrbMExQnQK6wpnJK+Q1/b/Y+w5wLYpk7aru
nu6Z+b5DzhkkSs4554xIFImHnHNWAVERELOiIgLmnAjqrgkTImLOYV0DgmmVdRXzX/3OqJyz7l32
uve///88e77nvD3d0zPTXV3V1dXTPeXlwia7bC5DnhhnobuDZM4z4a7NQJRT7wJuw1NewlXgeXUz
UnJwFiVUlwLvREppHB/CccKN4Ct1OfA8pN+K49nALUBIq3oTiCfq14Gf4blv43grMGnrpO4FcBac
aXbgbCI7ybVFgeB8fToQ1NaFgXi6Xoj8SXpFHOMpajrumXAm5EgnvNoXiDbV9ZFnAY7Rdvo+IPpe
Uw/vnceAtk8iZ7LO8/NED+J4A9I74irIuD4JCPm14PygFHCEx/AN4Ic42xvpqLvbjuNqOH4Yx2Vx
vCvlio5+9IIZlU3+OMKaiqi854oQ71zCC/0cVIiVA4J+HgmjRP2Kv8rBYrJYBeGw5oqh0xnvUDjZ
uYBVVQw967BmxmHXlcOaDbPK399iFYpNVrEmO/XAk6a5L5UrhONkHQtqpNGn6adQCwVk4OVp7epi
5O+psRi4BG2HtlaQF3Ux0tE7qVnArkDQWY0BfgFM+qsrgJApoz0yeh4G5Rn9obRdQext9PgsEP2J
huQyehuGFmDoBVUBCBnnRI4aAicDawFrIA/43J6BlCTnLUgfifRBaNnjgAeQDj5UCWei7hpn1R04
ng/8Hs8FlXRJnC2GOzTDPdGzBeDJYH+iqYHJ2n6sANHfoK9ASTT6MX0W7gNtGCTH4El9R1JycH5i
uWOVlEvmHJL1e1hpHGBdtEvscbyfNYlVkqyWxxjArkA6ctpkLRZ6jwA6yCSS+DxqtwLp0IaMMlhI
rkGLhNCAIfqHqA7Ooo+yyd0g9WKd+fyQMos+U2xzj8nqcbwJUhgnqGRtM9YIqWRnJVZVKfSiKtkX
mawNS1a5J3sPk/kTWMcqeZeRjKaSVW0J52ONk05WSid7e5M3UMnb5GT3yjmYlcIcl/TMHm9EisHx
FmC3dMbM4x6crYZjzGgFSfoQ4AjgKOAgYF/gVGAbYFcg5jA15gN1XeBbwA+B7wExexYUS2YdgSit
fiOZe8TxTuCbwCbA24Gtgc2BM1HmU4AdgZ8hHfIuusOnHMHxHTiuDDwfuB3ppwMxByh63+Mh4Drg
buD1wIuBdYBX4Q41cHwb8F7gaUi/GsdLgCiV7glMZiAxz6kbJ/OQQFDVvAKa1EjmFZHnOuALwOnA
y3E2BrZFyle4qgPu8xNSCgFRU90CeD/y41kyUvU4C+nTgAeBh4FPADFbq18EJvOHf8ZV7XCc0PNT
pOBag5Y1vZH+Go5fB74MnAfELK5J7rkBxyWBmI8Vya0L7ePPrgfOAYIm+mHgPuBjyImaSj/vU5LW
fASIVguw2irA+iuX7ATvjHWtyZtf7JVTGNUH6FUsbAqX7HdoA9vtcqzM/B52bmJTJ3NrySprrFbl
dzD/iXd5Id4Lm2R3MFa4GVgoJtnpluzEfwVlSNZOY0WxugjrtPf5+4jNPtvbgHgi9t2LRb/Ujw+x
NhX7GoIXk9GXT7GwEG2yQwRrGFR3pC/A2lFGSgEg5kb4B9znNeAtyLMexw+iLpgD5API3wzpnbBC
tUS6WtvbngexlhU7kuyzQMzfBsk6RtjyFmuhze2Yr8CsqamI+4D+uizeg2zFmx3YUwrztPw1bLRE
m2scY4+MSWZlE7sSs8EqGQNgLsViFshiLV+AdY8Ge+cDzCdozCXaZK9Nsioelp0JMCMKTRFg5Z5L
VgNinKOSNcOJ9Z3Mwg0DrZKZpQ047oe6YKbIOKR0BT6B9BxgU2BfYFL3Jsizx+9PVPN9WzPmThlz
m4z1FS5Z+4q1i/oLXIWn6/ag4Rj/Xkn6gZj8vjnBINl3eSXunLT7UrTRFThei2sH41qsCTdLkD4y
WWOPlLbIE+IYEmGQLv1MI/SlgjpZyzoy4Xm0F1abq1eBoJsZmqxkhuUOHacTWVPp/K2//3zc+XRc
lYvjs7FXsTvyNEL6RKRXAx8m3xy4CtcWxV7X3cBkjjfZjfgp6osdBxocHmBWRO7g77zCo3CRlwu8
obAYnZoGeEoFPCXZ4YV5DD0dkphoZ+xrYMys8j7M0kBHK/CGSvYbLkOZz/BcHVTBPAb6BL0QPYPF
W/tkrRfubCogf7JvK9mru8e/o9d1cf9kd0MyL5es7X/Nlz9I9hck1uII3Kc1ypnMSDRA+qWo72Lk
B98ydqPoG0GxxFbFKCuGHeogEQbrjqyfd6XkGyc8NexBOnfJ3OlUbNLcCdNo4fSx82fSdZ7bThzY
qRI1I/rpJypKWbJUmipREaotPNKM2lJ38isJifrRGJpI02muWAZJ3hxyVIYqy1EdakzNqR31oMF+
XzX1p7E0iWbQPFpC+KgI8hegkMpSFfKjgybUgtpTTxpCJ5OiATQOX0qdT0upBOmeAwb0oC4D+/et
RCcPGti7Eq3HHfyYNaJydBwVp3rUkjpQF+pFQ2kkafK7eXJpCs2iBbQMuSMqT1XlbvWplVgWvakm
LUd6cSokta5A1agkNaCm1Jo6UVfqQ8NolJS1Fg2Uke5Umk0L6ZT0qYUpQxWpOpWihtSGOlM36kvD
aTQFdDydSBNoGs2hRXQqnZbbaF6u+t6jNsAssBiwHLBq7tjp83UdYDNgB2Av4CDgqNyx8yboycCZ
wPnApcAVwDNzc2fM1uuBW4DbgXuAbwI/92jM+JmzZpgSwHLAKsCawHrAJsBWE+eOzTUdgH2Aw4Dj
gbOBy4Frpk+ZNNZcBNwEvAZ4y/SZC2aY7cD7gA8BHwfuAz4PfHX6rNzp5m3g+8BPgIfl5FxzBPij
x8AAY2AhYAlguVkSBFWANYH1gE2ArYAdgN1mzR0/M+gDHAgcNtunjwKOB04FzgYuBC4HrponLRKs
AW4AXgS8HLgFeN28KTMnBrcA7wLeA3wA+Chw77wZubODZ4GvA98HfgY84tGqefMaNLRZYDFgOWBV
YB1gE8FGtg2wE7AHsB9wEPAkwcZ2DHAycDZwMXAFcM28BbPn2fOAlwA3AbcBbwDeNl8oYLcD7wM+
BHwcuA/4PNCvwVciH6X/hVBLz1GFjvtvHflvmP0zDEWaA+nNnBxFIvGZ/0tpTtLypjAVOEb0Vm0h
6W+K/BuPlfSC1f6LkKnkMaPCdYqgwaFZ/L/HnGPGEseMlf4Oix8zVj8GLPpPUYt+K4dv7x/7UVk5
qgA6+e/1H3vIVOufohKNU/tfCJkqHgMWOyZsKdp5NV1E19B2epRepPfpS67CjbgTD+RxPJdX8QW8
je/i3fw8v8uHlVJFVBXVSHVSA9U4NVetUheobeqP6iNdStfULXQPPUxP1ov1Gr1R36Dv0Xv0q/qg
PmJCU8rUNC1MDzOMYH1RmPCa/iRv3FC++PH54o2Oiktm04D8Bp4kbomC5Xnj7r6j8ks8ehtxI5JZ
Qlq0epJa8NskLGTSsEAalsp7dZHb8saL9shbmpL5SltuQ954+Q754oPyxSfnvX/55fniG/I+r/xN
+a7PR80K5fLF1+aLH8kbr9gjX3xj3udVq3lUXPqNao/njVfP5r2++sC88bpV8sWr5otXzxuvZxFX
0ucWSShQr0UaPvRb7Vh/fBrOTMPFabj6t3I32J2G+9Lw5TR8N2+tG1bI2woNx+ctZaN78sX35o03
3pQvvjlffEu++F1H8bCPb88Xfzlf/lfzxpvl48JmXfK2UrOJec+PvSZffFu++M588Xz1HXtf3vuP
r5T3/ATjv5EplJxEB2U0/wl0jfddQvAzIramWQANVIRstMmdF13hNri1br2kWL6Nb5Nb+W/fsvRD
d5HCF3A1vixr8GXZILm7rqPr6nq6PjwnPIWvEipfAvW1L4V6VFLrSbyE2AdzaRM9Tu/Qt1xMShLK
1cWia0hFV0TXCm6KrhO8UupQSEY1laQf9/4f2rjbSPOTUrLbEZ7n7pDwaYnfifA8dxUpiW0RPM9t
FbxAauz5tgxVcdeRlhptcNcjPM/dIOF6id+I8Lyjct6U5rw5zXlLmvPWNGdaXnchnnYxnnYpnvbz
mctw5gqcufLoM9Fm1PEq1HEL6vjzma04sw1nrsYZJTz3CD8itPdfFmZ8WVjhy8Ia37c1+L5tEF0W
XS4ykYwdvIw28S0utqOSdllHfrbJ++tmU8dImp1ip8j1i91iMv/5pvF/vmn8D75p/Cs3lQE31UW/
st52+w/P/Idn/iHPML8Krknsl3rwz/G7eQWckQFnZMEZOeCMAuCMguCMQuCMwuCMIuCMouCMYuCM
4uCMEuCMkuCMUuCM0uCMMuZ6c73wiuePcuCP8uCPCuCPiuCPSuCPyuCPKuCP48AfVcEf1cAf1cEf
NcAfNcEftcAfx4M/aoM/6oA/6oI/6oE/6oM/GoA/GoI/GoE/GoM/moA/moI/moE/moM/WoA/WoI/
WoE/WoM/2oA/2oI/2oE/2oM/OoA/OoI/OoE/OoM/uqBdu6Jdu6Fdu6Nde6Bde6JdvZeVe0VX+Dnj
1fI7jc6U3wpaI7+VtJY2yJnb6HY6Cx7OzoauWUt75LcOHs7Ww8PZOXSIPqJz2XBA5/NVfDVdyDfw
zbQR/ls2wX/LlfDfshn+W66C/5Yt8N+yFf5btsF/y9Xw33IN/LdcC/8t16lyqg1dr9qp9rRHdVQd
aa/qrDrTU6qr6kb7VE/Vk/arPqoPPaMGq8H0rBqqhtJz6ly1m55Xj6pH2apX1Cvs1AfqAw7VF+oL
jtSX6kuO1dfqa87AD1nW+4fhHO8fhgt4/zBc0PuH4ULePwwX9v5huIj3D8NFvX8YLub9w3BxfciU
4BIyuprPXcwSs4y7mhVmBffwfmO4p/cbw7283xju7f3GcB/vN4b7er8x3M/7jeH+3m8MD/B+Y/gE
7zeGB5o9Zg+faPaavTzI7DP7eLDZb/bzEPOseZaHeq8yPMx7leHh3qsMn+S9yvAI71WGT/ZeZXik
9yrDo7xXGR7tvcrwGO9Vhsd6rzI8znuV4VzvVYbHe68yPMF7leGJAQfMkwIdaJ4c2MDylCAMQp7q
vc3wNO9thqd7bzM8w3ub4Zne2wzP8t5meLb3NsNzvLcZnuu9zfA8722G53tvM7zAe5vhhd7bDC/y
3mZ4sfc2w0u8txle6r3N8DLvbYaXe28zfIr3NsOnem8zfJr3NsMrvLcZXhm0Dr7kVcFXwVeqTXAk
+Ea1Db4PflTtLVtWnayxRnW2sc2qLt6jm+puG9pGqodtbVurXra9ba962262m+pje9s+qq/tZ09Q
/e3V9mp1or3OXq8G2efsc2qIfcG+oIbal+xLapg9aA+q4fZj+7E6yc10M9UIN9vNVSe7BW6hGu1H
WWqsW+aWqXFupVulct3dbrea4B5zj6kFbr/brxa659xzapF7wb2gFruX3ctqifswHKuWRrnRRvW3
6LboC107+i76Ts+KozjSs+OicVE9J64T19Vz4zXx2Xp+vC4+Ry+ML4ov0kviS+JL9NL4ynizXhZv
ibfqU+Jr4mv0afGN8c16RXxrfKs+Pb4rvkuvjnfEf9BnxPfHD+j18UPxo3pDfCA+oC+MP44/1hdl
Gmea6oszHTMd9cZM90xPfVmmd6aP3pQZmBmoN2eGZYbpqzIjMyP1lszozGi9NfuH7MN6m/f2o2/0
3n70Td7bj77Ze/vRt3hvP/pW7+1H35Z9Lfuhvj2ndU5r/YDXGH79C/VINUb9dNzRTP4H/pLCtFP+
q+bL48cm16QpikxA/gVaoAKxPQL5IxW4wEleRUWT3gv9xGmQ+y1eLulFyKWCXGrhnS/Y+hbm+30L
8wO+hflB38L8kG9hflha72He7duHn0P79PHto1b52qvHfc3U075m6k156mD0loTektFbKvSWGr1l
iN4yRm+ZQW+ZRW+Zg96yAHrLQugti6C3LIbesjR6ufLo5Sqil6uEXq4yernj0MtVRS9XDb1cdd+/
UQ3fv1FN379RLd+/0fG+f6Pavn+jOvCTXtf3S6KTDgdfik4SCRI9JBIkekgkiJp6CaIWXoKopZcg
auUliNp6CaJ2XoKog5cg6ugliDp5CaLOXoKoq5cg6uklSMYdIiPUx8uIjDtERmSs4S2RgV5G6EQv
IzTI7Xa7aYiXERrqZYSGeRmh4V5G6CQvIzTCSwSd7CWCRnqJoFFeImi0lwga6yWCcr1E0EQvETTJ
SwRN9hJBU71E0HQvETTDSwTN9hJBc7xE0FwvEbTESwQt8xJBK7xE0EovEbTKSwSd4SWCzvQSQWd7
iaB1XiJovZcIOsdLBNo5scR+Hg018PaYecJ/FdY8aZ4Ue+wp8xQp87QRe848Y56BPfa/wau/yJOe
jZI2lHKcizkaoloy8o9EwuoLTzakFlSQWlE7KkkdqDuVk7GB8Bv1k59/T3iy2Omj5NeExtAEakqT
ZEzYmqbRPLligYwbutOVdK3I9Q10C42gO2iX5LuX7qfJ9CA9RjPoSdpL82mf/BbSfvktoufoRVpM
L9NbtJz+JL/V9Gc6QGfQQfmto0/kt54+o69kdHGEFV3ClbimjBZqc326iRtyQ7qdG3MruoPbcAe6
hztxT7qf+3A/eowH8AASLcqj6Ekew2PoJR7Hk+hlnsLT6E2ewQvoT7yIV9JB1UK1oL+q1tIeX6rh
Kpe+UsvVama1UW2UEcLt6nbOqO1qB2fVLrWLC6h71X1cUD2gHuDCap/ax0XUe0pGBeqgOsTF1Mfq
Yy6hPlWfcUl1WB3m0po1cxldSpfisrq8rsDldCVdiSvoKvo4rqhr6BpcWTgg4CrGmRxubwqaxtzN
NDWteZppa8byXJNrpvClZpqZy5uD3GAGXxfMCmbzncHcYB7fHSwMFvKOYGlwJu8M1gRr+JFgfbCe
Hw02BBfwY8GW4G7eG+wIPuS3bY4tpgrbEraUKm3L2LKqnC1vK6oKtrKtpyrbBraBqm+b2CaqgW1m
W6mGdqAdqJrZQXaIam6H2VzVyk6wE1U3O9meIVr1LLtNTbQv23fUKvuufU+dYz+wB9S59pA9pM63
n9pv1AX2O/udusr+ZH9SWxy7QG11Jd3x6jpXx/VQ97leLle94s52Z6sv3L3uPnXYve3+pL50H7rv
1Ffuh7CizoSVw2G6XnhSeI6eGJ4bfq4vDw9HxfX3UclouKkUjYimmdxoRnSKmR+dFp1rzojOjzaa
S6InoyfN5ujZ6DlzVfRC9ILZGr0UvWK2Ra9Fb5hro7eid80N0fvR++a2OBtnze1xsbi4uSMuGZc0
d8Wl47Lm7rh8XNHsjCvH1c29cc24pnkwPiE+wTwUD4uHm4fjEfEI80g8Mh5tHo3HxrnmiXhCPNXs
jafH082zIl3FxSq6E1bRDrGH7pFRrxGr6H6xgURmxfp5TEa9sVhFeykrVtF+KiBW0fOiD16SUW8R
sYpeF33g/d2UgL+bkrCjS8OOLoP5t7L6BX1Q7JgrzMfU2HwatKLVYgneRc/LeP9F+g57IgK5XxXV
RHczw0SSW1EnkWbvW3UcTaW5tFR6obV0AV1O2+gmuovuo90inc/T6/SuaKbD9C37BRXZzD2kM3dn
tmfuRbgjcx/CnZk/INyVuV/C7XL0AMLtmQcR7sg8hHBn5mGEuzKPSLhD8j2KcHvmMYQ7Mo8j3Jl5
AuGuzJMS7pR8exFuzzyFcEdmH8KdmacR7so8I+Euyfcswu2Z5xDuyDyPcGfmBYS7Mn8kJWd3C+7I
7BHcmdkvuOt3UOQl1PzuzMspZV5JKfNqSpnXUsq8nlLmjZQib6YUeSulyJ9SiryTUuTPKUXeTSny
XkqRD1KKHEgp8mFKkYMpRQ6lFPk4pcgnKUU+TSnyWUqRv6QUeVHqf3fmbVDkfVDko99JkS9SihxO
KfLXlCJfphT5W0qRr1OKHEl55ZuUMt+mlPkupcz3KWV+SCnzY0qRnxKKZDmhSFYlFMnqhCJZk1Ak
GyQUybqEItkwoUg2SiiSjROKZDMpRT4HRb7ynJIlT5Gs/X0UyeYkFMkWSCiSLZhQJFsooUi2cEKR
bNGEItliCUWyxROKZEskFMmWTCiSLZ1QJFsmoUi2bMIr2XIJZbLlU8pUSClTMaVMpZQylVOKHJdS
pGpKkWopRaqnFKmRUCSb9RTJFgFFSnlOyVb5nRSplVLk+JQitVOK1EkpUjelSP2UIg1SijRMKdIo
pUjjlCJNU4o0SynSPKVIi5QiLVOKtE4p0ialSNuUIu1SXmmfUqZDSpmOKWU6pZTpnFKmJihSDxRp
Aoq08pzi34T4cuNNyDCqxR/yR/wpf8vf8Y/8k9JirjgVqxxVQBVWRVRxVUKt1S30ZD1FT9XT9HQ9
Q8/Us/RsPUfP1fP0fL1AL9SL9GK9RC/Vy4LF2cVy38J8wPuN40N8iJg/4U9EpxxhkR7+nn8Qk0j+
yCmjDIXKKkuRkh/FKqOylFEFVSHKUUX9zgV1tjqbCuvmujkV0YP0JCoaLAoWUY3souwiGdspKkOx
flw/offoJ/Ve/ZTep5/W+/UzvpZSvmWopc9zub5Cb9JX6s36Kr1Fb9Xb9NV/l+e/vo8fPZc6avTc
CG+QCDkeh+8ln6PcUTkaH3VOkVJYVCEluQZvwHrhDWaTX9/y6OtISwexyYf6GgmvRXyzDyW+2b/5
ogL6+jT1+jSVSUm5n8Qqj4J6o75Mr9Pr9Tl6gz5Xn6fP1xfoC/VF+mJ9ib7UW6WgMaFOSt+kb6as
vlPfKWNpJWPicrq97qg76666h+6l++r+epQercfosXqcztXj9QQ9UU/6rXb3ddHtvIco3UF38GuP
dSe5fxfdRUrZXXcno3vqnhToProPWd1P9yMn7TmSQuGsOVL/5Ont5OpOclV3yd1Hcg3Sg/UQPVQP
08P1SXqEPlmP/C1OxNPb++/fS+n97qfOurM8vavuKk/voXvI03vpXvL0vrqvPL2/7i9PHyXcFIIO
vz69vTy9szy9hzy9728+/Tfo4a0oKXdHeXoXeaKSsveSJ/aTp1gp7TKxrJP7Sx6fw5/3Z49VpnD/
dqhdJ9SrO2rUB3XxMiH3Dyqo9dJrOQ454pgznOUcLsAFuRAX5iJclItxcS7BJbkUl+YyXJbLcXmu
wBXFPqnMVfg4rsrVuDrX4Jpci48Xe6UO1+V6XJ8biNXSSGyWJtyUm3FzbsEtuRW3FvulLbfj9tyB
O4oV05m7cFfuxt25B/fkXtxbbJq+3I/7i1VzAg8Uq2YQD+YhPJSH8XA+iUfwyTySR/FosXTGip2T
y+N5Ak/kSTxZ7J2pPI2ni8Uzk2fxbJ7Dc3kez+cFvFDsn8W8hJfyMl7Op/CpfBqv4JW8ik/n1Xwr
f85f8Jf8NzVeTVAT1SQ1WU1RU9U0NV3NUDPVLDVbzVFz1Tw1Xy1QC9UitVgtUUvVMrGeTlGnqtPU
CrVSrVKnq9VqnTqivlHfqu/U9+oH9aP6SRQ2a6W1NjrQVjsd6kjHOqOzOkcX0AV1IV1YF9FFdTFd
XJfQJcV6Kq3L6LK6nLegdEWxoCp7+0lX1dV0dbGhaupa+nhd23Q13Ux308P0NL1Mb9PH9DX9TH8z
wJxgBpoTzSAz2AwxQ80wM9ycZEaYk81IM8qMNmPMWDNOrKzxZoKZaCaZyWaKmSr21nQzw8w0s8xs
M8fMNQvNcnubvd3eYe+0d9m77Xa7w+60u+w99l57n/2D/aO93z5gH7QP2YftbvuIfdQ+Zh+3T9g9
9km71z5l99mn7X77jH1Wfs/L70X5vWxfsa/a1+zr9g37pn3Lvm3/ZN+xf/b2lH3f21P2Q/kdsh/J
7xOxqT6zf7Gf2y/sYftX+6X9m/3Kfm2P2G/st2JpfW9/sD/anxyJpaWcdsYFzjrnQhe52GVc1uW4
Aq6gK+QKuyJih5VypV0ZV9aVc+VdBVfRVXKVXRV3nKvqqrnqroar6Wq5411tsdXqunquvmvgGrpG
rrFr4pq6Zq65a+FaulautWvj2rp2rr3r4Dq6Tq6z6+K6um6uu+vheoqF19v1cX1dP9ffDXAnuIHu
RDfIDXZD3FA3zA13J7kR7mQ30o1y490EN9FNcpPdFDfVTXPT3QxX1BVzxV0JN9qNcWPdOJfrXnWv
udfdG+5N95a3Fd077s/uXfeee9994A6Eb4Rvhm+Fb4d/Ct8J/xy+G74Xvh8eCD8MD4aHwo/Cj8NP
wk/Dz8K/hJ+H34bfhd+HP4Q/hj9FFLGoSx2ZKIhs5KIwiqI4ykQ5UYGoYFQoKhwViYpGxaLiUcWo
UlQ5qhIdF1WNqkXVo+Oj2lHdqF5UP2oQNYwaRY2jJlHTqFnUImobtYvaRx2ijlGnqEvUNeoWdY96
RD2jXlHvqE/UN+oX9Y9OiAZGJ0aDosHRkGhoNCwaHjeLm8ct4pZxq7h13CZuG7eL28cd4o5xp7hz
3CXuGneLu8c94p5xr7h33CfuG/eL+8cDxC4dGJ8YD4oHx0Piod4+jU8S+/RksU5HxaPjMWKfjotz
4/FioU6MJ8WT4ynx1HiaWKoz4pnxrHh2PCeeG8+L58cL4oXxonhxvCT7dfZI9pvst9nvst9nf8j+
mP0ph3I4R+eYnCCnrbdukzksvoVvodP4M/4LreDD/FdahVkt7z92LV2Lua3rMLf1Oua2QrPELOEI
c1uxnznkh+0mu4Ufw0zWXm/182thEFbkz8Ja4TAVYT6rZfa17HvqlOwH2Q/VGsxnrRMdfabo7iIy
OqhOPWQsutyvIQo/wDoMOYqyv6wMKUQlqFxUQ+JXRTK+cVuiWoJbozq/5G0uR+vEVs7K/UpRBaoa
tfQpkYzu3EVRa8FLojaCG6POv1wzAEcyfpD6lpPBSBVVxe/cUVVlVFJHyYhW1Vf1ZWzQWDWWO7OM
me3Pd6c6MtJRojdkVC16JQMUK8EfS+hjhdNYYT++oEPyI97KW71nP75WctzEN5M5hrv2TO/T81+4
qwomqzv/TvP9b+i9/yWt9/+TtlPf/M/qO/ucfcG+ZA/aj10Geu8u0Xj3QhM94ELRN17LPSYazuu2
RLM9f4w67dA/0WV/r8mc6LBftdfPmuH/NS32q6YaL7o3OlqbydjhTowa/IjBjxfut390E5Lxgpsk
o4XH7R6X9WMFl2OfFi6cLNw3w3PczzpPLc6r76LcaHw0IZoYTYomR1OiqdG0aEG0MFoULY6WREuj
ZdHy6JTorGhNdHa0NloXrY/OiTZE5/6mlvzgd+jJ7DFoyhpRzagW9GWd39SYzUVntoxaRa2jNnl0
Z+d/qD0H/Jv0Z17tOeDfoT/tTjfxn+rQdnQ6+W+MrafHxeLYQ3upM+2jF6kbvUwHqT99zAGNg4Y9
RbVV7ehU1UF1pRWquxpAZ6qBahCdp4aokXShGq3G0hUqV+XSZtj3V6lH1Ne0xZQ0Xegls8AsYB2M
CkaxCcYEYzgIxgXj2AYLggXsvPXPYXA4+Er08pHgCBcIvg1+4ILBT1ZxUWus45I2ssW4rC1hK3AN
W8k24Aa2kW3FHa38uJftYrtxb9vD9uJ+otPH8gk2107hCXaaaPbp9mp7A2+zN9lb+AY3083hm908
t4Bvd4vcYr7LLXUrebs73a3hP7rd7hHe7R5ze/hRt9e9yHv8e0B+wf1VRgUvhiVlVPBWOCAcxgfC
ceEi/ku4LLxEBeHl4R9U5fDB8BXVOTocN1Unx6fGp6otmS6ZLmpr9mD2sNqW/TL7lbo1p01OG3UH
5giUWHIFsNptHT2RpvTMk7KHxpqVZpU53aw2Z5gzzVlmjTnbrDXrzHpzjtlgzjXnmfPNBeZCc5G5
2FxiLjUbzWXmcj6Dz+SzeA2fzWt5Ha/nc3gDn8vn8fl8AV/IF/HFfAlfyhv5Mr6cr+BNfCVv1mfr
tXq5PkWfqk/TK/RKvUqfrlfrM35X2pn6LL0G8xsGeytOp01UBjMVTcTCXUbNMFMxCjMVYyRfKyrz
3ym7n4/BvZO5mjJHzdX496JKRkTT/RtP1UQ1lVFSSyVjKq8vZWQkupKsO+g+otB94j6nTGhDR4XC
KJRxWNgsbE4lwpZhGyoVtg87Uznpsd6mytJfvU9VfY9EtcIfI6bavheh+tKLNKOGvu+gptJ3dKbm
f1eepihPfbXIz01JeZqhPC1lpNZGRqxGSnUqBVKqlRSKBl9NEcoWo2w5KFsRlK1YWCAsJKUqEpag
sihnJZSzStg97EnVw95hfymbL209lLYhStsMpW0hfWdAbaTnzFJ7lLwrSt5deree1Fv6tgHUL31X
20f+30HJm6EuX2G8R7+k+CMZz8rorMgvaUpGXnXo530nPk1RKalr85T2BnW1UtfTyKEFMqhrjrvX
3UsFxJ56mwrKKPwwFXJfuu+E6oHUsmpYKqwoNaglNWsXnhAOowmiQT6kGaIrPqel4bdSm1XS/xen
i6XXb0lXSjsMoHukbx5O+0U/TaOXRSedQm+LHjqXDqSj5jZSpvHy7Mp+7E+dvDVHJ/h32XRi+Ea0
kfYfcz4/96f/h3L/2hbjQNGErwYc1RbNf20LGiR9+s9pSvrx449qi+Z+Pb77PjREYaWwJkXhcHmO
nynTSUlQhsp4eoO0lD9jP/RR5SDPWYzVr5GxuozY/fylPKEMVRI7qA5vkRyr2c/DrvW5aB1f71f0
8o2C5/graAP6uDUy6v91hc0olK+FpGexhoXoI/mx1wak7Fg7lrTdareScXPcHArcArdAJHelW0ku
vjK+ksJ4S7yFonhHvIPi+P74fhLrg2qna2PW4pn3i46z0HGFRMc9S0XpXfmVEm44QKU5EE1XxtQ2
dagsVqeUx+qUSqKJvqXKwQ/Bj1TFZmyGqtoCtgBVs2VtWapuK9qKVMPWsDWppq1ta9Px/v011cZK
lTpYo1IXa1TqYY1KA3uiHUxN7Hg7hZqLbppLbe0qu+r/sPctYFVVW9t77b027Pv9fr9vJMOtmLfU
Y4jK8XjXjIg8hmRIqISkJkaICkaKYAiIqEQe85iZmSmaehQVlJDUjJS8kJmZmamZmZl9c757+aWd
znO+/3v+7z///z+H9TzvHHvMMccc87LmmnOzx1i8AeQEWs0biF+wDMIvWBLwe5XB+L3KnyQLJYt4
QyR/lazjDcNvSEZItkrqeCMleyT7eKPx65HHpLHSWF6idJB0EO9x/GIkCb8SSUaPCvh/4A/kP4px
7kue4jz+APIUZ/hjyPObfoG9lsy425E/R96J/EXEEzEivkggYskMcYs8Iq/IJ/KLAqKgKIrMliTR
E6Jk0ZOicaI/i8aLnhJdFV0TfSe6LvpedEP0g+im6EexQWwUm8RmsUVsFdvEdrFDnCR+QpwsflI8
Tvxn8XjxU+IUcYZ4sniKeKo4U/ycOEs8TZwtzhW/JM4TzxHni+eK54nniwvEJeJS8RLxq+Iy8VJx
ubiC3Al8sh6S5zCZu+Q5TOYueQ6T9fACuf+tZO+nJ2fmkeRuf5DsR5/ldSN70BfJ+lZI7vaE8NOV
nPtnY+blMfkcZxb74j2cf95PtEwOm3tPGRU5WTeyL0W+HJEe+cJ/yROC6IjoGzHont+5V/P+xLzD
vMdsY3Yy9UwD08S0MEeZVqZN0EnwieCE4FPBKcEZwWeCzwVfCL5kq9mVbA1by65m17Br2XXsenYT
28oeZ9vYk+xptp39gv2S/Yq9zF5hr7E32VvsHaFUKBcqhWqhVqgXGoVmoVVoFzqFbqFX6BcGhdHC
jsIYYUjYRdhV2E3YU9Yka5a1yA7LjsqO/ft31f+f/K5awWPJ8iYQRghF/+Q3jGQ+swfYJraZbcEv
SP7ZL8mY4BX2iHiteIN4s3i7eLe4QdwsPio+Lm4XnxdfEl8T3xTfkbASiUQlMUhsEo8kShIj6UpO
Rv3IKWgIOfMkktNNKjnJZJJTy2xJvmSBpFhSJqkiq/kayXqy1tVJdkn2SZokhyWtkpOSs5ILksuS
65JbUh5ZimVSjdQkdUh90mhpSNpN2lsaJ02QDpOOkSZJx0snSjOkWdKZ0lzpPGmRtERaLq2W1krX
SjdIN0u3S3dLG6Qt0mPSNmm79Lz0kvSa9Kb0joyVSWQqmUFmk3lkUbIYWVdZL1k/2UDZENkoWaJs
nCxVli7LlE2XzZblyxbIimVlsipZjWyNbL1sk6xOtku2j9w9h2WtspOys2TXf5ns+W+R81aEXCbX
yE1yh9wnj5aH5N3IKSBOniAfJh8jT5KPl0+UZ8iz5DPlufJ58iJ5ibxcXi2vla+Tb5Rvke+Q18sP
yFvkx+Rt8nb5efkl+TX5TfkdBauQKFQKg8Km8CiiFDGKropein6KgYohilGKRMU4RaoiXZGpmK6Y
rchXLFAUK8oUVYoaxRrFesUmRZ1il2KfoklxWNGqOKk4q7iguKy4rril5CkjlDKlRmlSOpQ+ZbQy
pOym7K2MUyYohynHKJOU45UTlRnKLOVMZa5ynrJIWaIsV1Yra5VrlRuUm5XblbuVDcpm5VHlceVp
5TnlReUV5Q3lbRVfJVIpVDqVReVSBVQdVV1UPVR9VfGqwaoRqrGqZFWKKk01RZWtmqXKUxWoFqqW
qCpVK1VrVOtVm1R1ql2qBlWz6qjquOq06pzqouqK6qbqjppVS9QqtUFtU3vUUeqQupu6tzpOnaAe
ph6jTlKPV09UZ6iz1DPVuep56iJ1ibpcXa2uVa9Vb1BvUe9Q16sPqFvUreqT6rPqC+rL6uvqWxry
INEoNDqNRePSBDQdNV00PTT9NAM1QzSjNImacZpUTbomUzNdM1uTr1mgKdaUaao0NZo1mvWaTZo6
zS5Ng6ZZc1RzXHNac15zSXNNc1NzR8tqJVqV1qR1aH3aaG1I203bWxunTdCO0I7VJmtTtGnaKdps
7SxtnrZAu1C7RFupXaldrV2n3ajdot2hrdc2aY9q27RntRe117Q3tXd0rE6iU+kMOpvOo4vSxei6
6nrp+ukG6oboRukSdeN0qbp0XaZupi5PV6Ar1pXpqnQ1ujW69bpNujrdLt0+XZPusO64rl13XndJ
d013U3dHz+olepXeoLfpffpofUjfTd9bH68frB+hH6tP1qfo0/RT9Nn6Wfp8fZF+ib5KX6Nfo1+v
36Tfrt+tb9A364/pT+rP6S/qr+hv6G8b+AaRQWEwGBwGnyHaEDJ0M/Q2xBkSDMMMYwxJhvGGiYYM
Q5ZhliHfUGRYYqgy1BrWGjYYNhu2G3YbGgzNhqOG44bThnOGi4YrhhuG20a+UWRUGHVGi9FlDBhj
jN2MvY3xxsHGEcaxxmRjijHNOMWYbZxlzDcWGUuM5cZqY61xrXGDcbNxu3G3scHYbDxmbDO2G88b
LxmvG2+ZeKYIk8ykMZlMDpPPFG3qYuplijMNNo0wjTUlm1JM6aZM03TTbNM800LTElOlaaVptWmd
aaNpi2mXqcHUbDpqOm46bTpnumi6Yrphum3mm0VmhVlntphd5oC5o7mLuYe5rznePMQ8xpxsTjVn
mLPNs8x55gLzQvMSc6V5pXm1eZ15o3mLeYe53nzA3GI+Zm4zt5vPmy+Zr5lvWfgWkUVlMVhsFo8l
yhJj6WrpZelnGWgZYhllSbKkWNIsUyzZllmWPEuBZaFliaXSstKyxrLesslSZ9llabA0W45ajltO
W85ZLlquWG5YbltZq8yqs9qsHmuUNcba1drbGmdNsA6zjrWOs6Za062Z1unW2dZ86wJribXSutK6
2rrOutG6xbrDWm89YG2xHrO2Wdut562XrNesN613bKxNYlPZDDabzWOLssXYutp62frZBtqG2EbZ
Em3jbBNtU2zTbbm2Aluxrdy20rbats620bbFtsNWbztga7Eds7XZ2m3nbZds12w3bXfsrF1iV9kN
dpvdY4+yx9i72nvZ+9kT7CPsifbx9jR7pn2mPc9eYF9oX2KvtK+0r7avs2+0b7HvsNfbD9hb7Mfs
bfZ2+3n7Jfs1+037HQfrkDhUDoPD5vA4ohwxjq6OXo5+joGOIY5RjkTHOEeqI92R6ZjumO3Idyxw
FDvKHFWOGsdax0ZHnWO344DjsOO4o91x3nHJcc1x03HHyTolTpXT4LQ5Pc4oZ4yzq7OXs59zoHOI
c5Qz0TnOmerMcGY7ZzvnORc6y5zVztXO9c7Nzh3OeucBZ4vzmLPN2e4877zkvOa86bzjYl0Sl8pl
cNlcHleUK8bV1dXL1c810DXENcqV6BrnSnWluzJd012zXfmuBa5iV5mrylXjWuNa79rkqnPtcu1z
NbkOu1pdJ11nXRdcl13XXbfcPHeEW+bWuE1uh9vnjnaH3N3cvd1x7gT3MPcYd5J7vHuiO8Od5Z7p
znXPcxe5S9zl7mp3rXute4N7s3uHe5+72X3MfdJ9zn3Jfd1928N6ZB6Nx+RxeHyeaE/I083T2xPn
SfAM84zxJHnGe9I8mZ6ZnjzPAk+Jp9JT41njWe/Z5Knz7PLs8zR5DntaPSc9Zz0XPJc91z23vDxv
hFfm1XhNXofX5432hrzdvL29cd4E7whvone8N82b6Z3pzfMu8BZ7y7xV3hrvGu967yZvnXeXd5+3
yXvY2+o96T3rveC97L3uve3j+0Q+hU/ns/hcvoCvo6+Lr4evry/eN9g3wjfWl+xL8aX5pviyfbN8
eb4C30LfEl+lb6VvtW+db6Nvi2+Hr953wNfiO+Zr87X7zvsu+a77bvtZv8yv89v8Pn9Hfxd/D39f
f7x/sH+Ef6w/2Z/iT/dn+Wf58/1F/iX+Kn+tf61/g3+zf7t/t7/B3+w/6j/ub/df8F/x3wzwAqKA
KmAKOAK+QHQgFOgW6B2ICyQEhgXGBsYFJgamBKYHcgMFgeJAWaAqUBNYE1gf2BSoC+wK7As0BQ4H
WgMnA2cDFwKXA9cDt4L0UCkLaoKmoCPoC0YHQ8Fuwd7BuGBCcFhwTDApOD44MZgRzArODOYG5wWL
giXB8mB1sDa4NrghuDm4Pbg72BBsDh4NHg+eDp4LXqS7PuYd4HvAbcB6YAOwCdgCPEr2ggQhGwWM
4HAbcCewDZ7jlBZBtwgyIsiIOH4DsAnYAqSlJJCRgCPhOGcISsGXQZsM2mQcpx7YAGwCtgBpWTlk
FNCgRCklaDVoNSxRQ4MafA30a5CrQVkNcjXQr4F+DfRrmFaCT0JSz+FOINVjAMcADQbwDeAbQRtB
m1CXCZImSJpQlwl1mVCXCXWZSK9TpDVaUMqCUhaUskDeBr4NfBv4NvDt4NhRrx19MpfZCNwMrAPu
Ae4HHgQeAh4ho00Qsm8A53NYB9wBPEGwEFoLkVuI3ELkFkJrIbQWQmsh5F+GzMvgvBzmsPTboCLY
3ghtjdDWCMlG2NgIbY3Q1kjLRvRF7iL0aDHaWgy6BGVLYEMJypaAXwrNpcgtRdlS5JZCcyk0l8Kq
UnJO5fNOQ7KMwx1AqmcpOEuhYSn4S8EvB1aglgrIVECmArVUoJYK1FKBWipIH1OkdS1DqWUotQyl
lkF+OfjLwV8O/nLwq8GpRu3VtA+ZCCpJcDOwDrgHuB94EHgISMaWImSjgSIO64A7gFSrGLQEuiWQ
kUBGwvH3Aw8CDwFP4JvfOuAhYJhD+oaRg6+ANgW0KTjOHuB+4EHgISAtq4SMChrUKIU7ltGC1sIS
LTRowddBvw65OpTVIVcH/Tro10G/jvY982dIGjncATyDXyxsBtYBdwAp3wzaDNqCuiyQtEDSgros
qMuCuiyoy0JHmyCt0YZSNpSyoZQN8g7wHeA7wHeA7wTHiXqdtE/4PnqH8zsBY/kFBPsA44DxwEFh
pBoIvYDgUHBGhxH80eAngpMKTAOmAzPCCMks0DPCCE4O6AoacYW/hN5//DK6EhGkVm0BVoCzDLm1
kPxAEEOwgbaIf4C2l+D+u/c3/wNwDiG3lUoKeJD/iZt7G+/OOoETyKMcAZ/mCqRUkscKLgA/AZ4A
fgo8BTyDp9g2Tuoz4OfAL4BfIr8F+SIOqS4RVmgRNIqgUQSNImgUcRplkJWB1nD4CfAE8FPgKSAt
pwmXY/EkJfgORVqC0PWgqQ4Th5SvgKQCkgqOUw+aytg4/ARPAWrxXHDmClqBx4F4FghOAk9jna/j
pNqBZ4HngOeRfwj5hRy2Yi3fA/o4sA14Ekg1FnIaGyH7CuhSDluBx4FtwJNAWq40XI7tSkeU4EaK
tASh94CmOio4pPzekOwNyd4cZw9oKrOcw1asnFgPKYdgK/A4sA14Engaa2MdJ9UOPAs8BzyPfPQH
I+GwFbNyD+jjwDbgSSDVKOE0KiCLsWJ0HLYCjwPbgCeBtJyO648UtDIFrUxBK1PQyhTosHBI+emQ
TIdkOsfZA5rKODhsxdpCR5DF/kAG1ABNBAV0L0L2IeH0PS69y38H90g4n2XasF+JAkqgQUFR+Bzl
CJPAkXC7Luw22VrgGnr3gBaBloGWgdaA1oDWg9aDNoE2gZZCM6kf91HYGrJn43ZqYW7YNlt4H8u+
T1CInZAQ80LI7iMYA9siwztX8CPBj8TzPJLdjfu7Ca2mKfazhEtxL2nhIuzUxNyOtQmWUVoKXVLs
xaTsHrRtL9EhQ4/SXgJCSoEalYQWkH1qE3jKMA81qSCrgl4VctWg1WEakmpYSnvgPS5tQBq2XMNZ
ruWQltaHEbUShO166DIgx4AcQkMjTXeGU9RqhIwxTKOUEbaa2O3AvcDdmDP13BxqQm+YsTKZUdIC
LZjBPCtoK7erpbQde0I7cu2oYy72PI3AUmAF/c8D3V+Rp2043cyld/kbsYYdJE+McErX4jewE3sZ
GhbRmRRhoxz6ew/sLXcgN7yTxK6ZfQ1I/3tZCLoQdCPoRtCloEtBl4EuA10BugJ0EWbtXGIDXe3C
NpN9KLf7DHNP4NPy8H4cs3YeemAeeuAtWFUATgE4BZipBehrst9Ge2mKHTnGpJCORsRD2HcuoD0r
OIz+fRl1FEFXEfq9CDP1FYxeI+ZrI3qU9hKdOYsguwj1FmN+FHMzpzjMQ32LUWIxenoxSpSALgnT
kCyBvbTtm7l0P9KNXJ+E7V/CIS1dFkbUSpBpRA9TXUuRsxQ5ZE+OfiSfGPocLEdeOWouh3Q5bKzA
PK1ASytgSwVnSwXmCp9XiRWyEiWXQcsy0FWgq7gdOqWrsTevRm416igK1wSZZdjpLwfOZX8geJH2
PpvH4MmDfZ0CqANa8L80S3h20N0l7Rl8vsvfiKdQOD8iPF/ITv4gdto7sFums/gc5UQcAkfG7ZZx
SqDzkSD9f70EtAS0ArQCtA60DrQRtBG0BbQFtByaI2hv0901rNGF5zJJw9ywbY7w+YPOZSYSu3qs
tAxWWiYE28ThEwf4YvDF2GOL6djQUwZaLQnPC2LxbiAZvUgedthS7qRxEJZRWg5dcuyh5SzOGHRG
05MGdKjCCCkVaqTrqYAinVuMOsxDTRrIaqAXOzvSl5TWhmlIamGpLjyLkO5HupHrmc2wTQ9NepQ2
hhG1GpmD0IW1lJw1aI4JOabwjKY8SJiRZw7TkDbDRgud0QT3AndjroRtsYRnNGPFLsWKkjZowY6R
sYO2c6eQEzhn0POHE7lO1CEP1wQZG04zDmAEZnQjleR3wpkgfC6596xgi3wFWAYsB1YCFwGrgNXA
lcDFwFKKdHUh2ALOJvqrlMhNRF84LePSci6t5NJFXFrFpdVcSrRH3qbWECwDlgMrgYuAVcBqILXG
BetdsN4F612w2wW7XbDbBYtdsNgDeQ/kPZD3oLUelPKglAelPNDvQVkPV5a20MO10MO10MO10MO1
0MO10MO10MO10BNuoQgWi2CxCBYTrAQuAlYBq4HUAh8s9sFiHyz2wWIfLPbBYh8s9nHyi4GlOIs2
Aen4RENPNPREQ080NERDQzQ0RKNsNMp2RG4nDquA1cCVwMXAUsypJiCtJRa1xKKWWNQSC2tjoScW
emKhJxZ6YqEnFnpi0b+xXP/Gcv0by/VvLNe/sVz/xnL9G8v1byzXv4+jfx9H/z6O/n0c/fs4+vdx
9O/j6N/HYUGfyCLgq8ClwArgQuAy4HLgCmAxsAS4hCJdOwgeAoe2oQ+iKtD0VS5dyqUVXLqQS5dx
6XIuXcGlxVxawqVLSMrnx8HWONgaB1vjYGUcrIyDlXGwLw72xUM+HvLxkI9H2+JRKh6l4lEqHm2L
R9l4rixpm6iYaiD4KnApsAK4ELgMuBy4AlgMLAHS3hkEGwbBhkGwYRBsGAQbBsGGQbBhEGwYRKO1
EqwBvgYsBpYAoRM9Pgg9PhT6h0L/UOgfCs1DoXkoNA+FhqHQMBzywyEzGvRolB2NsqNh22gudxlw
OXAFcBWwBvgasBhYAqS2jYZto2FbIvQnQn8i9CdCfyL0J0J/IvQnQn8itCVCWyK0JWL8E7n5lMjN
p0RuPiVy8ymRm0+J3HxK5OZTIjefErn5lMjNp0RuPqXCvlTYlwr7UmFfKuxLhX2psC8V9qXCvlTY
lwr7UtHaVLQ2FbpTOVtTOVtTOVtTOVtTOVtTOVtTOVtTYStfdBUz7ipm3FXMuKuYcVcx465ixl3F
jLsKm9LQhjS0IQ1tSIP1abA+Ddanwe402J0O+XTIp0M+HW1OR6l0lEpHqXToT0fZdK7sEiC1N51r
ZzrXznSunelcO9O5dqZz7Uzn2pkebqfYQO0g+CpwKbACuBC4DLgcSO3IgN0ZsDsDdmfA7gzYnQG7
M2B3Bie/ClhD6sxg9sPyDLQlA23JCHMwfhkYvyzUkIUaslBDFnRnQXcWdGdBQxY0ZEM+GzIzQM9A
2RkoOwPWzeBylwGXA1cAi4ElQGrJDFgyA5bkQFsOtOVAWw605UBbDrTlQFsOtOVAWw605UBbDvo6
hxujHG6McrgxyuHGKIcboxxujHK4McrhxigJY5SEMUrCGCVhjJIwRkkYoySMURLsuLsHeoVLy7i0
nEsruXQRl1ZxaTWXrkStGfQJRrAMWA6sBC4CVgGrgeE9Snhf8gqXlnFpOZdWcukiLq3i0mouDdea
i1pzUWsuas1FrbmoNRe15qLWXO7JHX5av8KlZVxazqWVXLqIS6u4tJpLw7WWoNYS1FqCWktQawlq
LUGtJai1BLUuxTfVi8OIvWwZpcXHQC8FlnPfbzcBKb0CuAe4HliL3FqObiW4BvQ64EF8s703jNgl
H6C0xAQa+3V+E/et+EEgpY8Avwe2A1uR28rRHxNsA30aeAf6b4YRnJ9RS3I4F/gL9136QSCl8V8j
QTRQD5QiV8rRpBaBErQWJ9x/R2z7d8S2f0ds+5+K2CbiMeFIMvx/FuPmbgQaCbmre/Dz7vF0opyH
+XN/9TVizvIu8218F99DJKIJL5afyk/jp/Mz+Fnk7J4TWRd5ivqQ/94V+d39F9Fy/+X5+0tkvP+i
Pum/e0X/5upIPdbvu2L//hKNuP8ibfkHl+jC/Rdp8/1X+u9dYvn9F+ml+688XL9+zvrNlU2uGf/g
yvm9SzzyN9eE31zP/+YqvP/i/d/oYcXwTvOsvN68OF4CeQrQdxD++v7BXLJeF/FKeOW8al4tWfU3
8DbztvN28xrICn+Ud5zufBDF4H8VPf8tjP3v4D/wo3LwZILDbJ7wx4iUiNrIrMjpkfmSlZLXJFsk
u3j/O32bwv5cMpI4mACPvm+Xx6ykb+WET9Z65m36Fm363yBmE/MuoWkESAGzhdkKL45thN7OvE9o
Gg1SwOxidhOaxoQUMHsZ+v4UGhlSwDQyB/A+kCZCf8A0E5pGiRQwHzKHCU1jRQqYj5hj9J3oZM8j
YD6hcfkRN1LAfMp8St8rz5wk9CnmFKFPM+2E/ow/n6xuNJKkgF/ILyQ0jScp4L8soO8MplElBYKQ
4Ch9vzL9RpQ84aroO93Zr3kC9hJ7idA0zqRA+HDkyzwmvB+PfFdG7ETMSYHsY3kfHt7lgx7i8zZx
b5Sh8d/5nB/Le1w8zDpC01jwYZ8WBhHh+fBsYRAXns+9EYVGh+fDy4VBjPjw21EYRIrnw+OFQbx4
PvxeGESN58P7hUHseD7XDzSKpgDvpAj3QLjtDDxkGEEnuvOEnwxDo8ATmnrLMDQWPKGpzwxDI8IT
mnrOMDQuPKGp/wxDo8MTmnrRMDRGPKGpLw1DI8UTmnrUMDRePKGpXw1Do8YT+gLtYfjYMDRSPI8P
TxuGxosnNPW3YWjUeEJTrxuGxo4nNPW9YWgEeUJTDxyGxpEn9Fp2LUHqh8PQaPKEpt44DI0pT+i3
2I2kLuqZw9D48oTzLkvmGHuEJaMGXx2GxpQnfOqxw9DI8oSmfjsMjS9PaOq9w9Ao84SmPjwMjTVP
aOrJw9CI84T+jP2caKNePQyNPk841LeHoTHoCU09fBgaiZ7QFzGjqLcPQ6PSEw71+WFobHpCU88f
hkaoJ/R37A0iSb2AGBqtnnCoLxBDY9YT+if2NsmlfkEMjV/P48M7iKHR6glNfYQYGrOe0NRTiKGR
6wlN/YUYGr+e0NRriKFR7AlNfYcYGsue0NSDiKER7QlN/YgYGtee0NSbiKHR7QlNfYoYGuOeRgsT
OgjtFDoJTf2LGBrvntDUy4ihUe8JTX2NGBr7ntDU44ihEfAJHSWMIvcU9T5iaDR8wqE+SAyNiU9o
6onE0Mj4hKb+SAyNj09o6pXE0Cj5hKa+SQyNlU9o6qHE0Ij5hO4u7E40U28lhkbPJ5xe9P7FG0MY
vDGEwRtDGLwxhMEbQxi8MYTBG0MYvDGEwRtDGLwxhMEbQxi8MYSJ3ERXAPhBMTQuPI8PbyiGRocn
NPWJYmiMeEJTzyiGRoonNPWPYmi8eEJTLymGRo3n0VB+PHi8cu9GNKaSVAcuz5gcyjcmRoijCxIK
fpAzkfyafOMfCWsAn2E6S0PiCOEDCgHfIuSFnoqQPBDBsEx+dz65f0aHRoY63sOx1TrybOTBSK/h
vBRyCJpKHotPkwPO0+Q4RK6Q+x5lrO77MZ0iKt/O6vV0fvKIfGv11IUNRyQ1+ZrOoXx2fChfMKRG
wGf4fEnMm+qTI35JXvHB7rul7cSUzM4PhDpECB5lpVpP/6mZL2RNeiYt2xU1oYOrc8+e3V1DJ03I
mjpt6sRsV/+pWZkxnR0hW1hYf3/O1KynsidNndLZHXLSfIHW9Gv+qKlTs12PPJ+dNjVrUvYLIYdR
Huoe6tGF/MV2DnVJMso7dyEfHyJM8pcUegF9RZREaPmPju6sDanpB5FW8thT09ImTXkmm1SjCiko
M1IbOerp1MlTp6TeNUzyjwzzhtxhwyz35qc+7Ro96ZkpRKtrRP9HQvmMJyT/zwFkGCFPkM8oeYQv
4eczDG/rCy+2PvnugJ5ru67v3Paj/6E/ztj9k3Nl44Dnvj0y8MKxhXufHTIq5foy/t6hx/+Y0cnX
9+m/tXi3ShO2vvT8qQE71y1WjNjvf+BazZdyr/PII75bKcs+NA/4y6uDncsOvdvJs3fwg7OnntA7
Hl7YU9Xz1M4O1yc+/CDT5Zc7wYQ172UwhdU/bd804aX8H5Nr5sybX7zxWl3Z6x/2WDNivjFYOOxU
6Aavz/WGH/vM2VXwTUbPN2K63tgc87bkxZTSmROrK6fJC96+tu8717bhmkUTPuh4ossA8+X3B5c/
PGK0qWXiyBfWvVV4YGzfVfkjFkwRvvPQnhzfzlET+ywb1vxAbuyUeYMijqw8PLiAP6WAt3p34ZnR
fAGZ+K/PuRWa80NIS7rT7mdlIUmEiExdoTCSPJbn1FIuw86pCs2pyFM9cTjz20lZK70jc3Wbhhb/
8sFrWf/n51u+kreH90rv3gvUR/remHDpTL+QktqoZZhfWGGInKB/CdkpQ8EaWF2zvWU6L/OJt6+2
7RtWNTI+5vX4CVdCUpqtZFlyGxXcc+sI6IzIeXND7uDAtZYdw7JrE4PZ0c+/W/Dzm0PKZvKGftX0
tenkpP2K2tnf8fs3NBU23xzdXL9q59ipVybE/zWed7n8QNXHtjrpKrO87JM2x1sdXvz2mzXT1i8+
3bO4T2X6jh6Tjy542/vzma9aJ4lLF+y88xnv/a7f/TD7R5UmRvh1h/JX456Nem5rj8XtkfKDT6Yd
2pn3yLMT176/9f3irk3XBKrZs74/2h53JufOZ5+tv3PjzMfydzNbl3w+fEuP2tkPHuvzaVdpSnf+
qjnp3pdvJE9YvDHp/Z6fjF/46DxL7PcPV9bky2r//Mq7Hbe+9pcP3mxzbflbyDzfpZNH7xh1/ZH2
caHPl0RNKtyTefa7N95syYvLmq4ga8wsssakcGvMUxHBOVgLRffeR0KyzvwL72q64PQgK02XLp27
dH3oIbrghEKd6cdY+jE0Z+7/iG1yTBwyddmhw0eMuisu+Afi/3Tt2Zm1+eUvbavmN2bXjU8WdOtT
/fOyWVUdBno2vlE4+pvLA3s1PiGUPrZ2a5Ow+aMhMwZlzn/3iw/OPPPl6z9nB199ZtUnRYL4UMMP
B7cf7GUXjY0fbhTJf9xsTlvns/0kfGz+V/uHRbq7v/F1S8dOW+IOuYVvtJ7/KOqxRuuslg7dIg+t
fLT5/auer9d6V8s71P90eG9S3wl9Gjv+UZrzwvwrC759bmf/pM9ff1f+3aM/+dvPuj76smpc2V9i
H4x66THro+myLvHfTsyYeqVH9bf8t6peO1UZqVL0Nk06+8Kwgbr2bQsPPz+5ej2v+sG470fWJV2f
OWDuVzGzH3j/yUPmp6LeKusv2Z8e98t7XTas7uA5bbjwEbf23AzN+f73155f72LvkWnRQ3b+9IX7
1nOOZfojxh/3rSnC8NmV9K4nN3JkHtYNu5c1hQx5v3/bx1MBJ9sn9HCoZ033mocKYtOyszN7deo0
ISsjZvLdMYyZMHVyp8xnJ1Fup8ysqanPT8ie1qn/aDLxYggrlHDXQoZhe4d6hXrc/RziF3TkFM6Y
MeP3FD6ddY+m7N/cUFh9+nf4cMLOjM+nTd677JPJsgUPNyRMm+Vv6Xi2e86Krqt2elt2nTme/IL6
We1IFzNhW9YPos8bXhwZbYg6duTL5dEfmuRHtc+Vdrg0duePrfvlnd5++sHJQwd0GJs1b/gfjqbb
H0n56wvJxVcaZxR9wI+KWdFY/cAX26LFpy5VnP1i1qJxqgWjXzs1fviMyufGr32iZ+lHb2qcwq/2
DvjrR/Ujt71dd/J2xDze9ezXP/2l2V7jFUaeCz5UX1FiXpc/Pnjhp3kPOI6wHxR/mC//ZO3Q/v2e
P3r61Ixvi5KfVRamLt68fev2N58Z4x6wbnDal2PGvaJLfmbmpZJkgapUtMLnqrhwhqfO/OuPm7Iy
t244W7/KwCerzwqy+swPrz6qdOmy4bt5/jfVnw5wJs56pva3a9C/Zq/TLdSzc7dQ51DXrt3p0tOT
fPwX7HXGTJr89LTspyZn/lf3Oie7T/np7QNxg58zHWhJ6Dt69603dds7dnlfM3zUgbnf9I098cfO
S6K2lKa2O0fM217/pyMvCW9++/yuVxrXfrxhUubEmcGJF7Zs/Xb+tkOX1/2sWS193NOh04f9Toxl
rdPfm5w6efCYT09dPf23VXMb8868NITfvez73StFYx1pgw6d2D09udOLW/zs5rFPpNsm/JI3u/fl
j1n/0J4zsiOfrE8+XtC94/MHFRcdPcWzp99ZkTFlVvulvosrVj6n+HP0cFPK+C4rj84d9oAnOW3A
K6c7zVON2PTje5ZFGZf9y7U3P1B9Ml9xPX/6tG4NS2fVNo+PuCTcWBC79WbZE/MemZc4v2zKRmfH
hOap1f3b0y+8FCh+Nrze5DNRpEd8v7fiiP7f2O2oIsTcyULP0C0M756FcuqFYX+o2Nb1zT8VLN5R
fXH9w4/0bzgcMv9nAR2flTkkvNG858kppD/vkft3Qn+3jfqdBapsqLpz/ewR76uLX3sqklEszByw
6NtpY3b+QSx88Je6kaPn277pWbr19bHS0wu3PGw98tP6Nw5ufWek2zpVNCn3WUGtZ+A3GZsnz/bU
Dfxo3neLlLsii7rt+Tr3q8wnB6z6j026dObc3b4DD/drna15c3Kd0dX2naeTj5hdlFDcX3bPetZm
6eJ5ih03tmwRCun5MudQqtcsDbU5CV381seFUys8dp9f22zlvyEp4p7By5eWso87P92ybPwprNiT
0pDMxjLt0ywmZ/1qt45d/5lupv70uneLuWTyZtY8njNz72gk1nh8FJ8jqGjBJNO+hu3oNKMdTx2O
BdvuXdl570Waee8XpWlzzmwoDwm0ulbkskn5G7CAWgUsoCbBm0dTdMHNI86Bax5hFATg5pGBuZEp
sGgyMgSXUcYQriGIa9C4mR7NI3UDVQhXLs85syAjtUjBJdhVwTXYz8rc0cJI18zCwlHX0s3SyFDV
QBniJxlUP+kGgzylEJxaVJaZnEqweJvayKXgJBFYdXPq29l/77Rf/M3XL/xqlbmGUNk/34DVZdO1
Jrs/WBmWyfR0Sp1v6+36wvelDLd3O+f8zl9T+EH7Ys2kc1PE5y48uuvn97q7iQ91DeTmqOmW2T9z
m9a37kan+Y0z7z+fjz78J+PBp5T+2S8OC/1cvK/lz7Xuc6y2exnLAtSZf7RsF2vrTdgXq6ljc37p
3xlRprL+Ygcsbsgl2tuabQ4TES2fai3wi2HD5Eex5qvVdyfreIg0hj7OebVSe2pvB1/dYoal5Srs
M7QKmHdoqUyYde/oIiXv/T6RbOUhRc4b7FLuTm7hiNj272W7J6fZ5s0/jFfW+SyqrDeK1OSbt/Xr
A5t59m/crJGbU4gCQWNqx34m69e3puyqdeP/dfpL3dz/F1FaSlhLDEpaSiXFBcmJVGkpwUwqwV5Y
o7T/2A5gK60Y3q358+hSR9opzcdRO88yNNWJxxxViRTaveJ79vX2f72nt5bJSyt9+/7w1JadjoxS
5ms9zKcV/DpjvFyjZwf3thJhje2bSx9qcT7q9r8/w376dhOhxlcCd2Xv7Eo57xdg7dP1V/Ku6rqr
09pfeR95+uGno3gs4+vwjtqyqqf5/9oV1kye0zNrf7zUAlEDlQeL6hInympqHvacYOXc3Pnu3tXm
u/46ptbPHR0ZVzHwcH+65il9zqm3esNn3d5YzYf7eusnipZtSfgtor4qXyjZSSPCqsu62+HJ9qNn
JoXLuIVl95+e5BvGynDqh4GDq999yY69XwU+3JW6ryG3JfBT+QO1x7s5G4XuyFldcDVsYpkJLLGm
MjEyGjS2D2CXDaUjiRjqWtB4BFQ7QaONk9mQB3kcDWgvgsdtyGeALCsKLDXgGlkMgUk9+OD6w/K5
eRyXXCcWnGep/3ZQ9NQpgxQkLTyGYQYhC7QaNBh8GTIZkhmKGPLBQ3FpDCUMCgwhDJUMBUBeOlA8
EcjKYKhcqNaggjOdllQW5KcXJRZkVOqjlUssTYwMs7KuFbVl2urUqsof/SEy12Tj5Ibz6tGtjPX7
l/yQiCw1XeUYdulYa+3qGR+Oiiu3nHOPXiR0atuj9l3z6iVzV87jPVDayZXYXLnxoXbJgakPXFVW
/H5y5ObWP3dXTXN6bVtcrnKSezW3h/WDYrvZL9Y1HL9RHdHXpMtRNTU2pdtC5qWVW9KKDdG179XF
xJUkyg9szAj+PHdy7y2l6fd+vWQ/Ei2gE5YVWC6z5qHD38s/8m2vqT9q4m40OzBZSGuv7IfdNpOb
zT81CrL9KZwQzMe8fDf/191pL2aIhJufapv4QUAh4q3152uhW84t7Ei+n1KkpRdlXfqYp0/x9fft
VV5/zm72aJry2XlbpeDyhU1M8gZNTNKIOGIzbGLiAQpx0D0xoleQKNU2OzQxLog1kEBOidyIYV9G
oJ1wGVZDfmD1CqpJDQyBdaoRsD5FT4gVEy7d7g3m5d69eU6bdnB8V7LLvhi00gmURHoy3a5cOCbL
nvNEoM2Oq4n5wv4lz3b9DDIsYOqUfz8h86SDyMGA768+e69ny9wheT54iZNdOWPrRcWgBTy+3/SM
JXesDZ6mG+ckWh1W+IyvQMxOKPjATZ/mrO0mHbJ/1jjo/eq9bV2yNjA+2OVgdLWYpBKjFpv3vZOS
yVwXH+sL/o24uaaG4y5f2XIXZoHAgJVFu2ydNmpqz+dty+LW4r7MN2/h9KMO5t+/1qXtK7iZN+/T
1kXhV11OzM4IDFoosWiiTZqS9Lk9C+VcMzbrrbZ+cf7FN6XObUs0bsiYpT+R+xoWHtP13yd3RpON
yvXbv728TeQa2d9+q7mRWcha61FY5/WB/0KiU4O8ajoAARg2kA0KZW5kc3RyZWFtDQplbmRvYmoN
CjI4NSAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAyMjU+Pg0Kc3RyZWFtDQp4
nF2QwWrDMAyG734KHbtDcbpLewiBrWOQQ7uybA/g2EpmWGSjOIe8/WQvdDCBDfL/f+K39Ll9ackn
0DcOtsMEgyfHOIeFLUKPoyd1qMB5m7au3HYyUWmBu3VOOLU0BFXXoN9FnBOvsHtyoccHpd/YIXsa
Yfd57qTvlhi/cUJKUKmmAYeDDLqYeDUTgi7YvnWi+7TuhflzfKwR4bH0h98wNjico7HIhkZUdSXV
QP0q1Sgk90/fqH6wX4az+3jK7ur5WNzbe+by9+6h7MIsecoOSpAcwRPe1xRDzFQ+PxQhb1ANCmVu
ZHN0cmVhbQ0KZW5kb2JqDQoyODYgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGgg
MTIyMjAvTGVuZ3RoMSAyNDMzMj4+DQpzdHJlYW0NCniczHsJXFRV+/9z7p2NYRv2TeDCsG8zgAso
6iDghqICKqglwzDAKDATM4ComVK54BJvlpYt8qr1prYMLomZW9nmq+35y6xM5VUrLSuXTOH+n3tm
MDAM7NP7+b/ncr/3Oc9ZnuU858w5wx0gAOCOIAIuM2/MqONxcQEAGTsAAgrG5eeNnv4VsxcLLVjr
0IQ8VVLhiz/KAMgLmJ8yJXN8QV3x/W0A4hS8L+gqtaa4R+PaAQJXYJ1puloLF3PoxsMAkTexXFRq
Kqu8Z/B5FiDoPObXl2nNJvADB5S3CftTlFXUl4LDgccA4jErPlReUjlnzOQXngFwDEMly8v12pJP
t2iWYd9xWGGgwHBtZodivgTzYeWVljkho5lvARjMMpYKo0579OKRGQBJh7BOQ6V2jonxlgj6L8UK
XJW2Un9KMXE2QP/RAK5pJqPZwocB9pXxkFBuqtabpmx+bjh2jfVZMwi+EgOszrsyaaZr2hVZIHaF
aePo14cIz4OjUsU83zFMdk7miFlHWl9I+JQ5dgxDnNKx9WaC7Nytks40l3IOQApVXTBAASqYjNQP
4vW2PkRHSRNKl4nXiZMxG257ss1Qyrg7sWIxYYhUwoilt/UM+eMzONBc4i7tEq/oGEmSZY7kjYW3
SkVHoYwSv9nyzBZoE+8A7e29/K8maSCE/7f6Zi9D1l9pJyoBw9+ty19N7Msw6/+3Dj2kA1JC4PG7
8O70ntnt3XJre++npO8ie0sEWCJmWZx3hE5nX3r9KuNBBjK+A9c1B0Q5yBEdwRHRCZz4dnAGZ0QX
cEF0BVf+Js51BaIbuCG6gzuiB3ggeoInohd48zfAm6IP+CCiHP43XDn9EP3BHzEAAvjr0A/6IQZC
EHKCEK9DMAQjcsAhhkAIYiiEIipByf8KYRCGGA4RiBEUIyGSvwZREIUYDdGIMRCDGAux/FWIgzjE
eEhATAAVooqiGtT8FUiERMQkSEJMhmT+MvSH/kgPgIFID4RBiIMopkAKYiqk8r/AYBiMOASGIKZB
Gv8zDIVhiMNgOOJw0PA/gQbxZ0iHdMQRMAIxAzKQnwmZiFkwEnEkjOIvwSgYjTia4hgYgzgWxiJm
QzbiOBiHOB5y+B8hByYgToCJiBNhEv8DTKKYC7mIeZCHmA/5iJNhCn8RpsBUxKlQgFgAhYiFFKfB
NP4Chud0xBkwA/EeuBfxXpjJfw8zoQixCLSIWsTvoBiKkdaBDrEESpCjh1LEUihDLINy/lsoBwOi
AWYhzkI8D7NhNmIFVCBWQhV/DqrAiLQRTIgmuA8590E1YjVFM5gRLWBBrIFa/izUQh1iHcxBnAP1
iPUwF3EuzOP/A/Mozof5iPfDAsQF8ADiA7CQb4OFsAhxETQgNsCD/Bl4kOJD8BDiw7AYcTEsQVwC
SxGXwjL+NCyDRsRGWI64HPEUrIAViCthJeIqeIT/Bh6BJsQm+Ady/gGPIv0orEZcDY8hPoZ4Eh6H
xxHXwFrEtfAE/zU8AU8iPgnrENfBU4hPwdP8V/A04tfwDDyD9LOwHun10Ix0M/wT8Z+wAXEDbOS/
hI2wCXETPIf4HMXn4V+I/4IXEF+AzYibYQt/ArbAVsSt8CL/BbwILyH9EuIX8DK8gvgKWBGt0MIf
hxbYhrgNtiNuhx2IO2An/znshFcRX4VdiLugFbEVdiPuhtf4/4PXYA/iHngd8XXYyx+DvbAPcR/s
R85+OID0ATiIeBDeQHwD3uQ/gzfhEOIheAvxLXib/xTehncQ34F3kfMuvIf0e3AY8TD8G/HfcATx
CBxFPArvI74PH/KfwAcUP4SPED+Cj/mP4WP4BPET+BTxU/iM/wg+g2NIH4PPEf8P8SP4HI4jHocv
EL+AE/yHcAK+RPwSvkL8Cr7mP4Cv4RvEk3AK8RvE9+EUnEb6NJxBPANtyGmD/yD+B84inoXz/FE4
B98inqf4LXzHH4Hv4HvE7+EC4gW4iHgRfkD8AS4h/gg/8f+GS/Az0j9R/Bl+Qc4vcBnxMlzhD8MV
uIr0VfgV6WtwHfFX+A3xOuJ7uO+5gfQNuIl4E9qR0w4d/LvQQQCRJwRRWNtx/+solwqL/h92WHdO
8p7Z4m65PvQn7r1KH5OTzQaHvrf437PB2UmGG+S7scGpZ3Z3lWS99yPpu8hekquLA9ogcux7C5ee
2d217oNP/j4bFK7yu7TBtWe2w5/kekx9GKo+Jjdqg9i57y3+92zwcHNEGyR3YYNbz2z5n+R6THcx
BXtJXp7OwILkDs7tKXn2zHb8k1yPqQ9m9jH5erugDbI7OLen5N0zu/ty1YdxvYsp2EsK8FWgDQ4e
fW/h2zO7u9Z9GNe7CN9eUmCAG4jAwavvLQJ6ZndfchW99/P32cAFeqANcp++twjsma3olutDbN7h
c+YvpJAgT7TB8S5sCOqZreiW64MNd7GM9JLCld64TXC8Q4D0lJQ9s9275e6weHVNd7GM9JJiIvzQ
Bpc7BEhPKaJndnet77B4dU13sYz0khKi++HOxSWk7y2ie2Z319qv9376MFR9TEnxQWiD4g4B0lOK
75ndfcntQ2zexRTsJQ1M4nCz7xbZ9xZJPbO7a32Hid813eFz5i+kwQOUaIP7HQKkpzSgZ3a/brng
3vu5i2Wkl5QxNAp3kF6qvrcY2jOb65YL672fPpjZx5SdGY87SN87OLenlNkzu/t/AKJ67ye07yJ7
SXnZSbiD9B/S9xbZPbO7R+MdJn7XdIc1+i+kGXmDcAcZmN73Fnk9s7trndh7PzF9F9lLKilIw21z
8Ki+tyjoma3ulhvYez8JfRfZe2Ls/xn0xE04JuKPtwS6/iMR/vC/QyEvuotvV9Q9s7u7bnLf+7tz
mvN3dEKTCDQgnIuEL35El0Ivjb9Ucqn60i6eB7gU8nvO9Yz9Oni7lzSa/OHDhqYNGZyaMmhA/+Sk
RLUqIT4uNiY6KjIiPEwZGsIFBwX2C/D38/Xx9vL0cHdTuLo4OznKHWRSiVjEMgTispQjizhrRJFV
FKEcPTpeyCu1yNB2YRRZOWSN7F7HyhXRalz3mhqsWXpbTY2tpuZWTaLg0iAtPo7LUnLWo5lKrpVM
m1SA9MpMZSFnvUjp8ZQWRdCMM2ZCQrAFl+VbnslZSRGXZR1ZW96YVZSJ/bU4yjOUGXp5fBy0yB2R
dETK6qM0tRCfYYQSjE/W4BYGZM6oldVfmZll9VNmCipY2fAsbYl14qSCrMyAkJDC+DgrydApi62g
HGF1jaVVIIOKsUoyrFIqhjMI5sByriXuQOOKVgUUF8U6lShLtDMKrKy2UJDhFotyM60+c9t8f89i
5+4ZBUu6lgawjVm+Bk7INjYu4azNkwq6loYIWFiIfWBbJnxkUeNIFL0CvZidx6E05uHCAit5GEVy
giWCVTb79MosgVM0i7M6KEcoyxtnFeHY+DdaIbc+ZJu/v2Y3/w34Z3GN+QXKEOvwAGWhNrNfiyc0
5tZv99Nwft1L4uNaFG42x7a4uNoJJ+euhP5WGaVodYHKzr3lWSJopByDEWHldBxqUqBEm1IE0KdA
oy4Fq2EqJNjKWoIjYrA6ZBQ1KgYLfKG9VRyuUHKNVwAjQHnxQneO1s6RhCuugEAKcXIr1rC8k7bG
xlpjYoQQkWbgmKKOw2h+QHxcbSuTrjQpOHyg+2Ai+lZbOFiF7g8JEQZ4easGijFjXTipwJbnoDhg
G2hUsYVWpkgoOdBZ4jVZKFnYWXKreZESI3kHncxeVlnErT9XhbdHVvlgK/H+k2K9rTw7T5k9aVoB
l9VYZPdtdn63nK085VaZnbJ6ZBSwAYydYgJYWopBOeNWZSFT4GQVheOfhAZ1SatUhlFJOYQbaVUU
jbZhoTwkpI+NWvlLQiv6+L2ZXU3r4Nju+SHd8t3Uc2pkUWFRBJOdP62xUd6tDCf4iBYlWTqpRUOW
5k0r2K3AveDS/IJtDGEyikYUtoRhWcFuDpdOymVucYUcJ+Qgm2DAbmNktChgNy7RC2mpiDJoXtdK
gPJknTwCulbGxlNQHqZ4aMl3T/dkIvGKYCLASLyx3kyKEygOp6gSkFFtUwUHtzIJ25qFR9y2wGh8
hGkcT/kHJ0a6B6dFCnkfzZCK6OBvtvgFn8J7a2RS8NK0pOAH8VbhXYt5oV7kluhgY6Sx0rjYuEQ0
CLyF06G7m0zTSs68OtnTwdNhUFMr2a9JlTbtlTZtlzaVSZtKpE1TpU0jpU0DpU0J0qZYaVO4tClM
6ilzlylkLjInmVwmk0lkIhkjA5lnK/+NJlb4jPaUKISHRCSgiNIKRkDhhR8MYIbIGBgLVg82m8nO
G0GyrQd0kF3MWa/mKVuJHEdWrBxBrO7ZkJ0/wteaEpvdKuVzrYNis63SidMLWghZVYhcK7MUPZ5f
0Ep4gfVwgLCI7gZC+IdXBtifhYXgXTvcd7j7MLfUkZk9QJEdY39PvrFdU/bE+tchmNTgMSqYWLZL
g1dLBW4ecpsot0ngNlGub6B1TXZegXVLYKE1SSD4wEKyPX2nZp6w7hYps/R4F1mX15b7WhcWc1yL
Zqd9QY4oKtaVC0+t3rpTqc+0apSZXEv6vB6K5wnF6crMFpiXlV/QMk+jz9yWrknPUmozC3dDDilu
iVnVTdyyTnG7IYYU/7HHVlIsdBkjSMxZ1YPEVUJxjiBxlSBxlSAxR5NDJWYZhAGcWNAigxGFONnp
czvjKMexKAoIKRzhrTANowMzJMR3QcBrIuGFOkdc+5zwc9QZb6EoPj0+XSjCgBGKXISPWHuR74Ih
IQGvkRfsRQpkuylHQGxN7G3JLCTwzTJkCjdqsps/wCzc5h6cFFsYC+J7IFE8DoLx7sc+JhxO+VP2
u62jkL8ong3Kjln8l5HC12k77LctafHMdS+eWcbCG3AJ9pEYmAgH+A9BBwVMHZ4DxsIjsAsOwNd4
ZCvBEPcn84Hjn4YVeGx5EJohVeTP74RxcF7mCt546hxMjCABLyiDZ8mXMAYPSfEwBLeky6AacRLy
r5EULCF42LoHpT8GT8E+eB9Ogh/2mADHiJRc4/dABh5NdDAPdsPX4hHi5eAB/4B/wWY4CP8hCWQT
+Y79gd/JH+G/x1bReEIZCNOFNzLgUfgn1vsX/JtRsht5f34e/wL/Lp7vM2ErWn0Q3kJZVwlHphAd
8zxb3/EbX8VvpTtSL0F7vNLRmhywwHNY8xjcIA54NeA6OZzRdbjxPsJMwbN2LOo3GSphASyFlWjF
OlgPr8B5MpyUk6PkB8aZWcjsF0+U5khzHPa3f8aP4q8Kbw1BCGo7FWbjjnqB8IYErMGW/0RZh/C6
BO1kIBlChpExJJc8QhaT58ivTCxzgrnBurCubBxbyBax89nT7HWZuH1Cx9qOD/mJ/Bz0JS5H6M9w
9Fom5MMMMIEZ6mA+LETtVuHVhN7bipcV/bkfrzfhKziD11k4DxcIQ8Roo5zE4KXGawjRkLFkMplJ
yoiZrCWvklayj7xFviOXmf7MQCaVmcDkMmWMibEwTYyVaWH2M23ML6jlYDaLNbMPsFvZN9h32Y/Z
LzDqx4q0IoOoRvSYyCr6THRJdFnUIQaxEq8EsVbc3L6hI7tjOh/BD+GL+ZV8E17n0cdBwttMEIn2
TMRR1Qlv1aBVJrgPr3r03cNo0Rp4Fn0neO9VaIXXMUrfEN6hgA/hC7TvKzgtvCWAzhHs8yIhJJ4k
on+HklF4TcNxqiXzyUKyiqxDP7eQnXgdIF+ilR1o4RSmkLmXqWXmMyuZtcxTzG7mAHMMR4JnJTgS
vuwoNpudyk5n72Ut7Br2CfZJ9ll2PdvKHmDfFjGiwaKJomrRg6Im0QbRK6J3RJ+IvhSrxUPEjXhZ
xTvFe8VnJe6SAEl/SZ6kVSqR1cvOyTpgO7wDLbDz9iMTWUoUpAVeIudYEbuQOcIUMI7MMdIg+oBE
4gikERCvgir4GTUMJB8zg8hUVkemof8aSCmZDs+w/dgN7Fg4Iq4ieexEUgJ5orVwU/wmaMWNzDaW
ETey7eQ6sxXKYRUzu30zX0hcII9sYp7HiLkf0iBa5A/HmFTRbhLORDP7pS+TVhgmlbCp7GCZK+Y2
sWdQzTyZK/kOtOxpnD+ncG7lMs/jmnCWfCmdgNq1s69gnfthGNnU4QabxYVMEenHbCLj2h9s/5x9
il9P/JjTAO1u7elMBkbcZH4Lsw9+hLUd10XfwD7mBEzGVUNHZ87POPfqcKWZAjcZZ5xPebiOmHBt
KsPjZRmen1mMnyGaIIlUh6c9sUjHglwi1rEs4+8gFekI+MmiU3xjcxSX08a3p+UorqaNV7SnwfC0
9jThTlQnu4W4hYe4hZSJ4CbHHripEcMN4EQH6OvIfBucxvXUCXxh0C4gzh5SHKFWsmCHd6LC0b+V
BGqc5P2dE0X9PWb66Vf4xiqutrW3tcHw9qtpw4mbe2pqotpDyUYM6D8wOQkPqFIPT4ky1J59KKJA
MkKlThcz6Qnx6enxCemkjI0d4JUxbtw4v5gbbyakpyckaDS216Lx+IzrvRTn/WbNuBRIYUaLykWt
II6Xp8nHyWfIK+Tz5RKQyYnUQS6ROohBxrBOIkc8BIsC5RJPuVxCGJYNlBMkCUgDZQ4OEjE6TN7K
WHZoRKzcaT9zH+5mXsLVTowoJ9e3OwqO81NcbvO/eNEXPeZ/cXhaWlqqCt0mXpIQu+T+Q0sSfIUH
cU8VLuFPmpaGf4lquIfcQzySiZIke4hDCHtmc0n73vL2PeVbmefbHyLD2f1k5W87xOM6zLr2INup
X/IhWqiC45r4UaqpqlrVYpXIVRnkEBoarAzyCw2NVwZFhoYyyiBZqFKhDPIKVXLKoIhQZSv/j10+
oOJ8E1SqVmLUaHx8PX18fL2xz0gfbyS9vdGBKh+VL+cTzyT4ENbP19uLUUVGOOBOT/UZ5Pkk+vj4
cwnxkcHcEVfCCJ3IFa5+6sQjIek7cQeVQ0MHo0aInyx95lmMoLMg+CItTUCfVGGo3VLdBCe4pXZz
TecOLFFN7gkhbp4+3snJXiEDkpMGDRzg1j9CqRwQQkiIlzJUKvG6rZSwYe2XA8Inqjui1FPCvHOm
+eL6dYG0kYWqqWHe/cInqtoPqKcqvduviMw359wfHBMe3p+rZmstueE3Toho5mbjLfaKG8tsEX2K
nYUrSDQMghpN0NwYEh3bDxfNGJTYnw1wTo6PCWCBEatDw5SurSRE4+ydJCPqJKVjKjrJqZVIdyUv
5a5E+CWJcXurcYxXRfilpF4JiSmnjhp/8fJFRfvFthzBTTB8/MXhFy8q0tLcqIt8UmlcRERG2GaA
8JUNTgfMRkYoQyVent4+3gIPbFNkoI9E4CUnoWZYg7RGJayesmbj3lkjEsO93fzmhak0hTNnvXou
N7fj230vfnvv6588/czTpfOWq0L92ZmRyvvmDcipHR0/LFQtd13s7jM+Ia6ycllt7YqjHScvWQ3v
NUj839y1a/+76/IeVYdRz3SMxJXTijM9Cl7URAVpAr2GySAgMGy6szQwyctR5BLjwy11u+rANhHi
FyVqikqTOfhFtxKXllU48TFGLrahqYo2tB9Np7a7CQtARr0mLihS7hkR7hoeGuEREe4UFQ6OcqUL
F06CPBEiHcPCSYgCIdg9MBwwWkhsrCKNxs2iRTAmv17j7t0vIMIn3N83cLWon7ffatSSYA2h7qJB
uK4oB9J4GmT3qpS6lfX0tnsvgsbX4eCtXhJ5Q8Pbp2unG1efmjQibmBiQ979L89+foY5KXhQzbWH
NVGZZcyiDx56cMOC9dvXvu3rRqYvq8g+tPmB4+WFA161fWf5CXOCfRkcIWQ3sGSHxsVBCv7OEj8n
5x9DhPUiNqdNQUceI77LYsecOLb2iWPHnlh7jEm3PY+B8E8m21UL5/4bF3nqbi4m6k+uPX/Ldfp/
66Ibjv5M7a1vXWdA5/fUwh5Tb6cZ/Nx52E6zuHLMsNOiLnXE+Bm5wk7j5xA8YadluJdvttMOuB/e
bqflhINP7bQjJJHLdtoJkpkIO+1M1jKFdtoFEthLwrfrIlydwEkURGmx8IsbUQKlJZQ/jNJSyh9L
aRmlp1FaePGpVTTLThNwEve30wy4iC12moVccaidFnWpIwZfcYOdloBCvM5OyyBCvMVOO8AI8Yd2
Ws5oJO522hFKZLl22glKZa/aaWemzaGfnXaBGU5AaXkXG4WXxBROMyjt1IXvItBOFZRWCPo7zae0
B9LuTo2U9uxS34v6wUZ7d+H70bZPUzqAyrL1GdilTnAXOozWt9kbT+lWgZZ10VnWpX+nLnwnu/75
9SZ9qVan5zZz+eV6bryxymhBFpdhrDYZq7UWg7GKM1XoErhMrUX7Z5XSKyq4XENZucXM5erN+upa
fUlnvcF59ZXFxgpucK2+2izUTUwYpOaixht01UazsdQSnasvq6nQVk+xFw9IUKttTcbn35KFihrL
qrWm8vquLD2XWa2tM1SVcRNKSw1oRmJqSmp+ucHMlRqrLJwOQWuoMnP5hkq9mcvR13G5xkptFTeq
Wq+fzem0JoNFW2HmtFUlXIWxTl+t05r1cVypoaymWm9jF2vNBh1nqqnSWWpsllqMZXpLub6aqzNY
yjktCqmo0OtokbGUq9RiGYJBp63gzIayKls3ZfoqfTVyTDXoMrOem2jgdOXaaq3OgkYncNxk5JUa
qzmz3mIRzOnWjdCBWWfQV1kMaCRXZ6yeTXlaMxVfaapA89Bci5HDVpyZ+k5wQQ1WMlRxZgvW1laX
UKeYE8otFtNglaquri6h0u7LBOxFVW6prFBVWoQf9akqzTNt3SQI3D62qNNXIFdPm+RMyB8zckxG
ev6YCTnchJHcuDEZWTl5WVz6qNysrPFZOfnOcmd5nyoVGmvQHfVcDbrIcmto0XaTvrrSYLHocZDq
qeFZk8elUy8KGVO1saRGZxHsrys36Mq7tMWnoUpXUVOCTdFnJQazqQIFCC41VRvscYMOxXHpFG6s
qqjnogzRnL6yWGj1e19VnbV7VIlWLxFGFAPKUm2gcdJFPDa/1dcQqkGUAaVY9JXCzKo2oNQSY11V
hVHbVSgqrbWpimGI9hppPBprLKYaC1eirxVmAtYp11eYbrPoT0dSyKkqsHGV2TaIkANGqIZKPOdV
4FmyHnPFUE+c8bNmFua/FX5Dc6s8Dyz4rIISxGooYdexLexedj/eu9nX2BchH9ubhN/qYLkOnxxs
xjsfT78CPR57Enqz2GtxkEH7NlHUIt9Aa3DIqcD2CUhlUr72L/eULvweCJ+5yCnD1hYw05wen3qs
W4tY8of+BqOl9WhzMfKE1oNpvWps09lvImo3CNRIRWFrA2pbjSVmvEuxl2gqoQxqsLXgqSm3tR6A
rdV4dZUyHq37o102jxqxr2p6Ei/H/J1q6am/hHp1KKkK23AwAfUppfrpqdapkIK34EcD9UQp7cuC
lM5OaWlbM+3VgNrpKZ2DzzrqOSONBcGKUShLj9ds2lrQzkDbV9AWtjjhMGfEloL9Qh3B63FUroH6
p9ref2ftYlpH0FeIghrk6rDPmm5jaqH+0OOznPbLUXuFHEcjRUf9WYFlui6thJHhqO62dpX2PnVU
Y45KLbNb3qmNIKWKyrDVMVGNTXSkBX9OxDaCvHI6yloqzzbSQuxyMNler5TGJUdzFirVNjp31qZT
AzNyDFQLobTU7pk62t/sLvW0dr1t1lfSGWQbPdvoCj7j7LKEXn+Pu84oqLH3ZKDeMnef6V0iRbCt
nFphwnmhwquOXgnYY/e4TLDroqL1K1GWCtGCdbRUMyFnhpndtEm4VffvlSFEYIW9rr6LlBycIfkw
BkbinYGrhUBPQK4wc0YijqP8LOTkIQrrySicA1l4jafcfHAGOb0LqQ9tY1qPzxr72Ft6mGu20TLR
WKmksWuh65AQ//VdxikLI2gcyvw9gjpLTHS9KUEpOtqjbdTqqCwdnQk9ybXlDXRWVWDbErtUW3SU
0HITXbPqu8SWIMtw2yphiytblN9uuVCjglJR2C4an3o6vp2yetKr6g99991Lv/decmtm2dYVC9X8
91WgZ+sN9lXldr2GdPGBYInNFguV1/lJI/Rvs7WErnNVdL3T3tFSm6e13bxqW8OMdvx9VRO8aqFr
joX2r8dPoc6V3NZPOY1qUy9j9NdnUmeZiq4mOtqj+bb507k70NI6nflTdDeh77a70HfbP9B1RRQk
ShRli0aJhiKmYm0t2ih4T9AsXfidLl2XhFas7dDMh9zx5+ksffPJHQjP09qEXvSMHSC8FGl/STkg
Td0QkCJxiFk8evE1ZyJlmhsCopEVzhCS6Kh2kIhjXVjGXwxqrUQeKyEi0jCIIaLmPPUkdVwXTr8N
QQv7CT/HxmsCBqCZLmB66vhhwqUO6dKZyPO9USPiiscNPHaB/+xY/4VXtj0b9e9ZzQ1eJ9UN7CG8
45tZhjCMYtR+v8dPrswdmXHtROVo58RNaudbqhIxKrVoOVWSnSySeDDT0hO91B5CRubhNBW3n/rq
Ki5Da9IneqrdBbbUwzGzprpYW1VrwCNMoiv2hly5hyS/XFtn0ScGqgMEhqOHp43BZeir6RGEHoQS
g9WBQjHr4W0vpqcsi7bSJOx3M9LVQT7O6uTEJHV/NU3TfJwThWxyUvKA1AGp09R5XZSdnJfoo/ay
yXfBk6AhD89OcdyYKl1CYqw62iYotLOAiuLyOmXl4XkTt61mQWgDCe3qFSIGtoG4AvLlTAMhsPnw
tk1HjnKvyO9f9uKSmks7cn46edB1f5l278aSfl/suX44eetD6mUFC1acmP3VwGdd9390Yc7Pdc8v
MKbtX/2K82vllyseO7w3N37r6KFXXv3snpkBzPrfVLODNl3buO55/3eZUw+Myz3jUnRB02/Bbuev
h7+z4+SSvTPnzkpMYJ9c5PHCKO79RLPz1Pijc/onP+7+pPvur8tVW86eeaNxRcyby0OWlO59sGCq
sWZ/2paIJfccVnilrX/ou/yD8qpDHW+N/Wq31G1t6PwTwyI/CppzYX3iez+dDfU7cWj7qIx1/jOb
g5ra7r3yw/yf7t9aTB65Mt7x6w9Dp7zw+NGXl9a+/MNrzr+0jT/efKO8+WXPIduXHNzDsBj4Gxed
UC/6XN1fIsOIFYulhIii1BHqsM68miz2tR8VjDqzKQFP7gbhMCucFWjsBHoQwotkagk+GALqdIEX
LBqsTlEPbO7fnLRYbW+uq67o1lpli5WuoZKRnoC1aKQGhouc1PJOLViZ2kVgugqyhFcIJagh5t1E
GJmb/NQ+nfHNejjl56VjoKXEJ8YPSL5tVrCLFsHY2de/K3gjs1/isvonY9fsb3iRHOs37qi1saDq
pCx6473vHl7tcU6U6/zjqEgVpFjb3luds+7T0GKva8MHhUwwJS78aXnKku3nz6+Fjg8mr8kJ+3hz
ZM7cl3dp03+Jef/ce8fv/WpP7MPDdj6z8/ipqfy+HW8tuPKB07OX1nbEfjIkNyAgJfLa8LE4h3l1
A3POPo+dv4299Onn0Ut9k8QO966rXXr7PP6vzIw/Tkd1StfpOLWPQlXqeJvQiN6ECmX66l6n5LaJ
UaO/+qR87kO+maU19yw41LpeF8EPzXh6vluKInyy+XhNpKE9Zzc34xP59eaAmIuTp4RoPw860fZ6
8ux3fvxq4yD9qoDVTq/mBc2YXzpgprgxq6M252Tewg2LuGdeXjpjg+zaf9TXfwgdNG6E/P2Tbwcf
Ojb520XDd+ZujNtC5v68YcvKAR3rz94zS7x+6Owz+9cc6DhSdF1zTtqc+f2iSVXPxfz8aqMi6uIj
X0qaF09cN2+szFkdeFjx7Oxr3xa8LNqseXJb1PlHvF9MO5NnzP5kwDM7jSWB29fE7Rl6rv77yrnX
vc9GvPTKj0/m7dLEPd5av6Xj09yt0ZYFIy6kBm2Y5X22cE9Y+eewMEOxZOFs+5Q8rF70zl+ckk63
piSDR8dk22SMU8eoo5ojmsMWh95pMlrM5nidlk4/bzr9hC7+ZAZKDvRpBva/fQYKo7xkjumLnFzC
Tf+m/r0G9aH23X5r9v4D3tx79Ojbl10+56+PP5BcrHZ764ol4NNHv575NOfRMj9r38SjD55b6PPg
vyJXl3mMvHG49Yl09shTk6aLlz/wgvGXgIkBYQk/G1ZWhF7bc9j78YtOlgPldce/f7J4yUFz06/L
LHOVWzc+MW9ty7VHou8bn1ATMDr9i0s7nbn8Y3XNaxt0hnaHDxov1exxeOr4dbfJEeu0SfvmMtZ5
i/dteHN5aNycjwbUvv6oecb13WfHecmVR9o+/rR/whiNV5pr0dywt58r/XHNB6bvh5277Lzgy4/m
b6y9z3Dw6Qmj1ANCWja84l+cFnt81ZYY6bzPfbfPmHf6meeMHWnLXlI3iNxxCfjNtgS4wkFYnpa2
1O2jYVd1F05qunpMhCuAqXNu/7/qzTOsiWyN4wkJHS8QilRJaCqoTCCS0KVIWaSFqhSBEKQoICLN
AglIU0TUUKUEpCNFhKCiFOlNFMErsOBeOiJKXRWBmwACe9VnP+3dZz/lOXMyM+fMec/v/P/vmWHl
EtX09ArwpuVW4ftw++FIBQU0fCt5up6EPYTcAwht/JnnjzWb6VkkAhDZGCa+7Xqsp6cPXP28j4un
t6tPAA0PCmgAiQQA9CYeZAGkrBxys/g3tOhPl3K6J7VeY0pzhoL70uL97YCpjLxoiZOfVknHMimr
KRlw1YsmGckZMfay7i80nAJmCn1bzPrm3t0JE4pJC3Uua3APdBTrFVYeZAffnIirrz7onJTkIpnY
pXigmq3cSrJWe5xFFRN3IG+fQu60XojGcCj746TT5g6FxItk+4N+xyYTHzgpJRkLIZnEudPyxmOl
+cZUEnDc9lb0+DRhNDb895wPt+kaBburzY+WRQZXK06b3TYsWskJPONjWMzXHse8DwGyvGHvin6s
D2NUtlizXr7rzMKU/ZJgYfmhQsmOl+AH7Vt6WhRMWi3pCOrNEfC2UW6t+siUKQqUMVxpKYP7cV0Z
2uRGLkDIAggZtHkJhhKSAEJ8MId1l9cHV+9UMZPL3PcNrq+1kb3//+NH/JMYX6cCaYK1Jno+nu/w
+0qw+L/9OOdt7GXTUlnbVOljI2JaFMcQcx8tbx0oT9dpdvzw9XW7ktKJPHkz11XxM2ot7fmD9Bd/
RUarpHF4uT1ehRnxudZ87dIc5jwBN5pyvFCcz98sjZY4+BRPhkVJsOMyfzcT+oxo6eWZxxZ6aMoy
rhB3fxo9dXqXydKTWWzTk/F64CscyRwhTNovYNAjTJc1G/wW8sB6ofTXZssZvF4T1qziAWQfbO1G
70emmMuV8Q0F6AMjgSO5fsO+6aAuN7Xal/JRb9VhuYfdBN36D//2Sgg6knsU2nxCDuNhILTLkcKS
ca27x0xNu0PIPNurH6YYfut8Ws7LdCoVnlHFQfGmMHBjTTSqAQkXcPbV05Gd9z76ZhKE/y4kAPJU
vYBColEoJIom4KmIl5X/hgRC9h8lAxfAuWE3WCwdzrlQpYAP9T4c60sI1WwwYvFOZzw9nL61jOVn
LftZN2WpN/2um2IAYqMbAjtrnPDr4oOmRozXTQH8e5LsopGEaZ0kz9rh0VVDa6rGM4F1r8Qllnw7
EWsdUhaGrXcoxPuHAw6C6nOZenAtlKylydra3tJrcRmMX9griNikd8TGJxwNuTUz7qHXTQUfG39x
AkfW8r4iuoCO+GstwjCGyziTt19UHo6iS4dwjGJKZ4+gdBbci7QX957bI9qmwb/HpAKb1J3ZxdXI
r3aW4cwcCaF1UuN9TUuiE7yyFvU1Q2vswn1hmcrswQXyUDKCfdUKqW6OuVxsNT4yfTxAouB3KRlO
NYy/qkZQjsvIZVGX3WO/3Kz318LqkI1CI28l15y6MMW8HAa5tJR4Vlk6xzmhfejgf6TpBNhRuvhF
ZVjxbLiQsCTWs50ae5BMIliK+jwkf6TDIf8MvMAYmDcNOA+VL3QQCAi6blGF/wXlhXJLfJLWt232
Nrs3upQutZt3ufazKQHg3zqFmw7KtocFZAo6T7XrmiB1gHVd+Kz7Dm2AfUtg0QMQ6s+OebmOMdzw
23n6ypIpVlbUCyJSNdLxaA9TzmcHfPMhyBeMrvrz8rm9Id3DDRamueX8ne1js+mfLSp0b+uIj+aJ
DAS+WuINhPXP3xCcZrItu3Lj4TWrx0LtpG7SbbmF2MG1iGQ7fT1jBUlFuKAZ+uslG55bzwaErn90
wCqPMr53/hAwHdNpicOT+PTSA4fwlCHJotVmWEVjRnvjyate8639BUQPxgE8/8PcpbA6Zo2EWclC
18DSWumcEmeRrOJwJvd4rsoS+cQ99JlcmMyaQkD1EeI1kN3qCBMqtowenQ3kfGSnzIaevVV7M8IQ
eoLepul5b96b3y7F+u9dfuCRFcMgZ1VqJ8XJDhDp5agoE9zAGIuDdmob7b1rEP67DMU/BRnb7FNA
yaHkaW4JTdVG1OJhWhHw+Uv6sVkP+Un9n0qiDkIcpsgmY652aLCrgBTdq5wicvWZbdgh24+l3osF
hRFu5X2lohdYm5uz9GPtRLkmPy+KpZQvePgWfZi5q9xUX3PcRq2g7JycZLYjwSGA7LjgEUHq8vi1
Ke3lXRNOX4dHXlF4chxvZI4toUvLebTfIvVI69cBX/FDWgBotPfSBRJnj5Vw5oQRa0vEQEavaeLp
VlxrolvSTbtjBpwTMt3W1nYnsZnnDmY9Dj266xo/j28bU19SthfPhMG064rtffeY9/tN0Jirjdp6
PLeNE0oWXO6+HmQ+e8on1e+a8BX3+Knxk0fb346d3fUCB7p1AZlwnfUB15OyrpnZIcRMnr3DDFpT
5dmGJCKCb1KfyPXvvMs2DGbeuOedN+0wmhE05GfYk3mn4PntlZ+QL492VAxKIAOE1OAfUoTsc/fv
4N/3YkF/w/hpARrAkXTVdOUwxR3G78y366w7Py93V9pRmc1t8nMytAlAi39q7MuuG0KjHU5UE1AH
1LacKF2Y3M595O+vi/f+/oI+P/KEmDcfSJhkmwRuWzMP1yG65vGy5e46g3syBUFmu/pkKz65je1a
Rgj4qWa5BD4gXY6ymdOsD0nGX4owNrlI5F4MOfc646lNK51Xp+Tp3VVY7qzIGsoIuZ18PiX2rIpg
jQXIovxTqGSfndxyr0SgXVJf9vLCnLpAobn2Pd2BWAyXFbPe7DwyXKQKet0ahodMspp0kdmiEp+8
qc3tYuKRQJRXWEYKvbAOO5zVupIfPp2HVqNoug/DZ49WXS6anDW/T9atwj81Rb1pmWDAQRn8PYzX
dB8nT2meCO+/xxK8eLzhwMhokPUvo7IBM6JXbrIdLDO2bqw7YmVV8LJjWKa2Y/pMGjoASYS2UbHZ
RAcGA4Tyfwwc/wD47TR2OmEC4N5aUPeBkYwQ+vVkO22Z3Rx6ZgiSbWfmnNr07RIr8l/AzloeQGz7
RCiSOm8lB/eYdnyxAl/b/0pXBq2Fa117eAzw3nEKG9IJcEzHBMv/YOcdDtLe2mv5ya47WTJY/Kex
7bP1DtL/qkkoEQxq5Zj33l3U9jWgPLFEVF86JaE9IvkeeCHIRSCfXa4c0eO2N6ZOzTB+rJA3oANV
Hs1aA1GYI4nPQWSOE0JdbmDDFT1NhhOynz1CWavgGpcPmWL8jygXGX55y5jf9q62OOP5oo5xagRM
OS0eEdqVbDpthTkiDCaJKXFyrU7rpbC9qqqeTGwVDKF0XvU6OXdxyYiFtZr3dD9C1KlHGm2iXTit
M3ATU8NRWuDVEZsUSRF5+UsE0FoxX239jpnFSS8ENMMy+kywIVpkJkEtSEm6U9rg3Xnzvk75EWZh
eJrqnI0tJJKJ/4KXa6uJSh5h8HhNSRR/pZtRM/fK1YQ4ypke+ioUlEykyiIieHl7xBiQRPA09dAE
LbxP/SVJzR+kUtkYmDYaQEelTPpxgG9n7LFub+2AqaG3VUOPZKet99QFXlaW9m076gSVvztCDwbl
MEwUpZQPSkUJ2QMjn1fjen8QAu6mWrpvuw5ptq3Yehj0JL3XqL+jRLGQ9D9m75Svv/dKufmxHh7N
0JQvXuqBOjr1w1e7Gx6tva972bRmCQ7xL53sRwS5oh6py+SoBj44nEJ/p77SkBsNCp9Uup5/3lka
5os1JybINOGY7ldj6waffmQhr9TRzS+I95VqOvQxQDxX9RNSZ0OKq9D34ZppFWPD1fXjaKBeb+Xi
/jnRc0NA2j2p8Z4wPiQF3hBZZ6ypMoWXU3QzA6nq5EdJJZoKAllTTg6e2eaUbGkEe6H+4Ou1EIYs
Eb90gzuLBgLlkN0vPvvtbr7BcUWt9FRnZA4WJ7a6rHAixTYYeG6mMlNCmQ/pH7jxX39/QU8NCmVu
ZHN0cmVhbQ0KZW5kb2JqDQoyODcgMCBvYmoNClsgMFsgNjAwXSAgMTIwWyA0NjBdIF0gDQplbmRv
YmoNCjI4OCAwIG9iag0KWyAyNzhdIA0KZW5kb2JqDQoyODkgMCBvYmoNCjw8L1R5cGUvWFJlZi9T
aXplIDI4OS9XWyAxIDQgMl0gL1Jvb3QgMSAwIFIvSW5mbyA0NyAwIFIvSURbPDE4QUFGRDUzNjNB
QjE1NDBCQzA4NzkwQzdGOEU2NTdFPjwxOEFBRkQ1MzYzQUIxNTQwQkMwODc5MEM3RjhFNjU3RT5d
IC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDYyND4+DQpzdHJlYW0NCnicNdVZUM5RGMfx/1sp
ZGvf98UWot5CSBGVfU2khCyFqFC0vKVklyzZKUu2JEuUfd+XspWMWzNcmHGRsUx5/8+Xc/F85sw8
Z86c5+L8FEW/Wls1+mqmKCpZUCcYmAtmVYJ5EETBH8EiTLAMge+C1TfBOg2KBRs/4AbbZMHOTrA3
hWrBoVxw9IFI+Co4aQVnb2gQXOoF1zzBLQOaBXdLqIAfgscnwVMneMUL3iWCltdqPwsBLUJ4ghCR
LcSGQroQlySkBOsHph9doPIG3sI7eA0m8K/zvf5cqvP/nQYMwBCMoA0YQ1toB+3BFDpAR+gEnaEL
2IA5mIElWIA1WIEtOIA92IErOIEjNIALOIMbuIMHeIIXeENX6AbdoQf0BB9ohF7QG/qAL/SFfuAH
/qCFABgGg6A/BMJAGABBEApDYDAMhWAIAR2Ew3AYAWHwAUbCWIiECBgNo2AMTIbxMA4mwgSYBDNg
KkyBaIiCaTAdEmAmxMAciIU4mAXxMBvmQhLMh3mwEBZAIqTCYlgEy2AJJMNSSIEMWA5psBJWQDrk
wGpYBVmQCdnwCgphDeRCE+RBAeTDWiiGzbAO1sMG2AiboAi2wFbYBntgJ2yHHVACu2A3HIJ9sBcO
wH44CMegFA7DESiDo1ABJ+E4lMMJOA2n4AxcgEo4C1VwDs7DNbgEF6EWquEyXIEauAp34SZchxtw
G27BHXgM9+EePIQH8AhewlN4As/hGbyAOqjX/+w5BIOuUUXT8lFoTYMiFQONjYphfoxQYAv+QmG0
ilFzmfDTV/ilE35nqhj7SVIa+5eqmNQkCrWSYyZfKqFJUf4CE03ICQ0KZW5kc3RyZWFtDQplbmRv
YmoNCnhyZWYNCjAgMjkwDQowMDAwMDAwMDQ4IDY1NTM1IGYNCjAwMDAwMDAwMTcgMDAwMDAgbg0K
MDAwMDAwMDEyNSAwMDAwMCBuDQowMDAwMDAwMjA5IDAwMDAwIG4NCjAwMDAwMDA1MzAgMDAwMDAg
bg0KMDAwMDAwNDUyOSAwMDAwMCBuDQowMDAwMDA0NjY3IDAwMDAwIG4NCjAwMDAwMDQ2OTUgMDAw
MDAgbg0KMDAwMDAwNDg2MCAwMDAwMCBuDQowMDAwMDA0OTMzIDAwMDAwIG4NCjAwMDAwMDUxODUg
MDAwMDAgbg0KMDAwMDAwNTM2MiAwMDAwMCBuDQowMDAwMDA1NjE1IDAwMDAwIG4NCjAwMDAwMDU3
NDggMDAwMDAgbg0KMDAwMDAwNTc3OCAwMDAwMCBuDQowMDAwMDA1OTM5IDAwMDAwIG4NCjAwMDAw
MDYwMTMgMDAwMDAgbg0KMDAwMDAwNjI1NSAwMDAwMCBuDQowMDAwMDA2NDI1IDAwMDAwIG4NCjAw
MDAwMDY2NjcgMDAwMDAgbg0KMDAwMDAwNjgzOCAwMDAwMCBuDQowMDAwMDA3MDc5IDAwMDAwIG4N
CjAwMDAwMDcyMTIgMDAwMDAgbg0KMDAwMDAwNzI0MiAwMDAwMCBuDQowMDAwMDA3NDAzIDAwMDAw
IG4NCjAwMDAwMDc0NzcgMDAwMDAgbg0KMDAwMDAwNzcxOCAwMDAwMCBuDQowMDAwMDA3ODk2IDAw
MDAwIG4NCjAwMDAwMDgxNDYgMDAwMDAgbg0KMDAwMDAwODMyMiAwMDAwMCBuDQowMDAwMDA4NTY5
IDAwMDAwIG4NCjAwMDAwMDg2OTQgMDAwMDAgbg0KMDAwMDAwODcyNCAwMDAwMCBuDQowMDAwMDA4
ODc3IDAwMDAwIG4NCjAwMDAwMDg5NTEgMDAwMDAgbg0KMDAwMDAwOTE4MiAwMDAwMCBuDQowMDAw
MDA5MzQ0IDAwMDAwIG4NCjAwMDAwMDk1NjkgMDAwMDAgbg0KMDAwMDAwOTg3OSAwMDAwMCBuDQow
MDAwMDEzNzQ1IDAwMDAwIG4NCjAwMDAwMTM3OTkgMDAwMDAgbg0KMDAwMDAxNDA3OCAwMDAwMCBu
DQowMDAwMDE4NTMzIDAwMDAwIG4NCjAwMDAwMTg4MTQgMDAwMDAgbg0KMDAwMDAyNDEzMCAwMDAw
MCBuDQowMDAwMDI0MTg0IDAwMDAwIG4NCjAwMDAwMjQ0MjcgMDAwMDAgbg0KMDAwMDAyOTI0NyAw
MDAwMCBuDQowMDAwMDAwMDQ5IDY1NTM1IGYNCjAwMDAwMDAwNTAgNjU1MzUgZg0KMDAwMDAwMDA1
MSA2NTUzNSBmDQowMDAwMDAwMDUyIDY1NTM1IGYNCjAwMDAwMDAwNTMgNjU1MzUgZg0KMDAwMDAw
MDA1NCA2NTUzNSBmDQowMDAwMDAwMDU1IDY1NTM1IGYNCjAwMDAwMDAwNTYgNjU1MzUgZg0KMDAw
MDAwMDA1NyA2NTUzNSBmDQowMDAwMDAwMDU4IDY1NTM1IGYNCjAwMDAwMDAwNTkgNjU1MzUgZg0K
MDAwMDAwMDA2MCA2NTUzNSBmDQowMDAwMDAwMDYxIDY1NTM1IGYNCjAwMDAwMDAwNjIgNjU1MzUg
Zg0KMDAwMDAwMDA2MyA2NTUzNSBmDQowMDAwMDAwMDY0IDY1NTM1IGYNCjAwMDAwMDAwNjUgNjU1
MzUgZg0KMDAwMDAwMDA2NiA2NTUzNSBmDQowMDAwMDAwMDY3IDY1NTM1IGYNCjAwMDAwMDAwNjgg
NjU1MzUgZg0KMDAwMDAwMDA2OSA2NTUzNSBmDQowMDAwMDAwMDcwIDY1NTM1IGYNCjAwMDAwMDAw
NzEgNjU1MzUgZg0KMDAwMDAwMDA3MiA2NTUzNSBmDQowMDAwMDAwMDczIDY1NTM1IGYNCjAwMDAw
MDAwNzQgNjU1MzUgZg0KMDAwMDAwMDA3NSA2NTUzNSBmDQowMDAwMDAwMDc2IDY1NTM1IGYNCjAw
MDAwMDAwNzcgNjU1MzUgZg0KMDAwMDAwMDA3OCA2NTUzNSBmDQowMDAwMDAwMDc5IDY1NTM1IGYN
CjAwMDAwMDAwODAgNjU1MzUgZg0KMDAwMDAwMDA4MSA2NTUzNSBmDQowMDAwMDAwMDgyIDY1NTM1
IGYNCjAwMDAwMDAwODMgNjU1MzUgZg0KMDAwMDAwMDA4NCA2NTUzNSBmDQowMDAwMDAwMDg1IDY1
NTM1IGYNCjAwMDAwMDAwODYgNjU1MzUgZg0KMDAwMDAwMDA4NyA2NTUzNSBmDQowMDAwMDAwMDg4
IDY1NTM1IGYNCjAwMDAwMDAwODkgNjU1MzUgZg0KMDAwMDAwMDA5MCA2NTUzNSBmDQowMDAwMDAw
MDkxIDY1NTM1IGYNCjAwMDAwMDAwOTIgNjU1MzUgZg0KMDAwMDAwMDA5MyA2NTUzNSBmDQowMDAw
MDAwMDk0IDY1NTM1IGYNCjAwMDAwMDAwOTUgNjU1MzUgZg0KMDAwMDAwMDA5NiA2NTUzNSBmDQow
MDAwMDAwMDk3IDY1NTM1IGYNCjAwMDAwMDAwOTggNjU1MzUgZg0KMDAwMDAwMDA5OSA2NTUzNSBm
DQowMDAwMDAwMTAwIDY1NTM1IGYNCjAwMDAwMDAxMDEgNjU1MzUgZg0KMDAwMDAwMDEwMiA2NTUz
NSBmDQowMDAwMDAwMTAzIDY1NTM1IGYNCjAwMDAwMDAxMDQgNjU1MzUgZg0KMDAwMDAwMDEwNSA2
NTUzNSBmDQowMDAwMDAwMTA2IDY1NTM1IGYNCjAwMDAwMDAxMDcgNjU1MzUgZg0KMDAwMDAwMDEw
OCA2NTUzNSBmDQowMDAwMDAwMTA5IDY1NTM1IGYNCjAwMDAwMDAxMTAgNjU1MzUgZg0KMDAwMDAw
MDExMSA2NTUzNSBmDQowMDAwMDAwMTEyIDY1NTM1IGYNCjAwMDAwMDAxMTMgNjU1MzUgZg0KMDAw
MDAwMDExNCA2NTUzNSBmDQowMDAwMDAwMTE1IDY1NTM1IGYNCjAwMDAwMDAxMTYgNjU1MzUgZg0K
MDAwMDAwMDExNyA2NTUzNSBmDQowMDAwMDAwMTE4IDY1NTM1IGYNCjAwMDAwMDAxMTkgNjU1MzUg
Zg0KMDAwMDAwMDEyMCA2NTUzNSBmDQowMDAwMDAwMTIxIDY1NTM1IGYNCjAwMDAwMDAxMjIgNjU1
MzUgZg0KMDAwMDAwMDEyMyA2NTUzNSBmDQowMDAwMDAwMTI0IDY1NTM1IGYNCjAwMDAwMDAxMjUg
NjU1MzUgZg0KMDAwMDAwMDEyNiA2NTUzNSBmDQowMDAwMDAwMTI3IDY1NTM1IGYNCjAwMDAwMDAx
MjggNjU1MzUgZg0KMDAwMDAwMDEyOSA2NTUzNSBmDQowMDAwMDAwMTMwIDY1NTM1IGYNCjAwMDAw
MDAxMzEgNjU1MzUgZg0KMDAwMDAwMDEzMiA2NTUzNSBmDQowMDAwMDAwMTMzIDY1NTM1IGYNCjAw
MDAwMDAxMzQgNjU1MzUgZg0KMDAwMDAwMDEzNSA2NTUzNSBmDQowMDAwMDAwMTM2IDY1NTM1IGYN
CjAwMDAwMDAxMzcgNjU1MzUgZg0KMDAwMDAwMDEzOCA2NTUzNSBmDQowMDAwMDAwMTM5IDY1NTM1
IGYNCjAwMDAwMDAxNDAgNjU1MzUgZg0KMDAwMDAwMDE0MSA2NTUzNSBmDQowMDAwMDAwMTQyIDY1
NTM1IGYNCjAwMDAwMDAxNDMgNjU1MzUgZg0KMDAwMDAwMDE0NCA2NTUzNSBmDQowMDAwMDAwMTQ1
IDY1NTM1IGYNCjAwMDAwMDAxNDYgNjU1MzUgZg0KMDAwMDAwMDE0NyA2NTUzNSBmDQowMDAwMDAw
MTQ4IDY1NTM1IGYNCjAwMDAwMDAxNDkgNjU1MzUgZg0KMDAwMDAwMDE1MCA2NTUzNSBmDQowMDAw
MDAwMTUxIDY1NTM1IGYNCjAwMDAwMDAxNTIgNjU1MzUgZg0KMDAwMDAwMDE1MyA2NTUzNSBmDQow
MDAwMDAwMTU0IDY1NTM1IGYNCjAwMDAwMDAxNTUgNjU1MzUgZg0KMDAwMDAwMDE1NiA2NTUzNSBm
DQowMDAwMDAwMTU3IDY1NTM1IGYNCjAwMDAwMDAxNTggNjU1MzUgZg0KMDAwMDAwMDE1OSA2NTUz
NSBmDQowMDAwMDAwMTYwIDY1NTM1IGYNCjAwMDAwMDAxNjEgNjU1MzUgZg0KMDAwMDAwMDE2MiA2
NTUzNSBmDQowMDAwMDAwMTYzIDY1NTM1IGYNCjAwMDAwMDAxNjQgNjU1MzUgZg0KMDAwMDAwMDE2
NSA2NTUzNSBmDQowMDAwMDAwMTY2IDY1NTM1IGYNCjAwMDAwMDAxNjcgNjU1MzUgZg0KMDAwMDAw
MDE2OCA2NTUzNSBmDQowMDAwMDAwMTY5IDY1NTM1IGYNCjAwMDAwMDAxNzAgNjU1MzUgZg0KMDAw
MDAwMDE3MSA2NTUzNSBmDQowMDAwMDAwMTcyIDY1NTM1IGYNCjAwMDAwMDAxNzMgNjU1MzUgZg0K
MDAwMDAwMDE3NCA2NTUzNSBmDQowMDAwMDAwMTc1IDY1NTM1IGYNCjAwMDAwMDAxNzYgNjU1MzUg
Zg0KMDAwMDAwMDE3NyA2NTUzNSBmDQowMDAwMDAwMTc4IDY1NTM1IGYNCjAwMDAwMDAxNzkgNjU1
MzUgZg0KMDAwMDAwMDE4MCA2NTUzNSBmDQowMDAwMDAwMTgxIDY1NTM1IGYNCjAwMDAwMDAxODIg
NjU1MzUgZg0KMDAwMDAwMDE4MyA2NTUzNSBmDQowMDAwMDAwMTg0IDY1NTM1IGYNCjAwMDAwMDAx
ODUgNjU1MzUgZg0KMDAwMDAwMDE4NiA2NTUzNSBmDQowMDAwMDAwMTg3IDY1NTM1IGYNCjAwMDAw
MDAxODggNjU1MzUgZg0KMDAwMDAwMDE4OSA2NTUzNSBmDQowMDAwMDAwMTkwIDY1NTM1IGYNCjAw
MDAwMDAxOTEgNjU1MzUgZg0KMDAwMDAwMDE5MiA2NTUzNSBmDQowMDAwMDAwMTkzIDY1NTM1IGYN
CjAwMDAwMDAxOTQgNjU1MzUgZg0KMDAwMDAwMDE5NSA2NTUzNSBmDQowMDAwMDAwMTk2IDY1NTM1
IGYNCjAwMDAwMDAxOTcgNjU1MzUgZg0KMDAwMDAwMDE5OCA2NTUzNSBmDQowMDAwMDAwMTk5IDY1
NTM1IGYNCjAwMDAwMDAyMDAgNjU1MzUgZg0KMDAwMDAwMDIwMSA2NTUzNSBmDQowMDAwMDAwMjAy
IDY1NTM1IGYNCjAwMDAwMDAyMDMgNjU1MzUgZg0KMDAwMDAwMDIwNCA2NTUzNSBmDQowMDAwMDAw
MjA1IDY1NTM1IGYNCjAwMDAwMDAyMDYgNjU1MzUgZg0KMDAwMDAwMDIwNyA2NTUzNSBmDQowMDAw
MDAwMjA4IDY1NTM1IGYNCjAwMDAwMDAyMDkgNjU1MzUgZg0KMDAwMDAwMDIxMCA2NTUzNSBmDQow
MDAwMDAwMjExIDY1NTM1IGYNCjAwMDAwMDAyMTIgNjU1MzUgZg0KMDAwMDAwMDIxMyA2NTUzNSBm
DQowMDAwMDAwMjE0IDY1NTM1IGYNCjAwMDAwMDAyMTUgNjU1MzUgZg0KMDAwMDAwMDIxNiA2NTUz
NSBmDQowMDAwMDAwMjE3IDY1NTM1IGYNCjAwMDAwMDAyMTggNjU1MzUgZg0KMDAwMDAwMDIxOSA2
NTUzNSBmDQowMDAwMDAwMjIwIDY1NTM1IGYNCjAwMDAwMDAyMjEgNjU1MzUgZg0KMDAwMDAwMDIy
MiA2NTUzNSBmDQowMDAwMDAwMjIzIDY1NTM1IGYNCjAwMDAwMDAyMjQgNjU1MzUgZg0KMDAwMDAw
MDIyNSA2NTUzNSBmDQowMDAwMDAwMjI2IDY1NTM1IGYNCjAwMDAwMDAyMjcgNjU1MzUgZg0KMDAw
MDAwMDIyOCA2NTUzNSBmDQowMDAwMDAwMjI5IDY1NTM1IGYNCjAwMDAwMDAyMzAgNjU1MzUgZg0K
MDAwMDAwMDIzMSA2NTUzNSBmDQowMDAwMDAwMjMyIDY1NTM1IGYNCjAwMDAwMDAyMzMgNjU1MzUg
Zg0KMDAwMDAwMDIzNCA2NTUzNSBmDQowMDAwMDAwMjM1IDY1NTM1IGYNCjAwMDAwMDAyMzYgNjU1
MzUgZg0KMDAwMDAwMDIzNyA2NTUzNSBmDQowMDAwMDAwMjM4IDY1NTM1IGYNCjAwMDAwMDAyMzkg
NjU1MzUgZg0KMDAwMDAwMDI0MCA2NTUzNSBmDQowMDAwMDAwMjQxIDY1NTM1IGYNCjAwMDAwMDAy
NDIgNjU1MzUgZg0KMDAwMDAwMDI0MyA2NTUzNSBmDQowMDAwMDAwMjQ0IDY1NTM1IGYNCjAwMDAw
MDAyNDUgNjU1MzUgZg0KMDAwMDAwMDI0NiA2NTUzNSBmDQowMDAwMDAwMjQ3IDY1NTM1IGYNCjAw
MDAwMDAyNDggNjU1MzUgZg0KMDAwMDAwMDI0OSA2NTUzNSBmDQowMDAwMDAwMjUwIDY1NTM1IGYN
CjAwMDAwMDAyNTEgNjU1MzUgZg0KMDAwMDAwMDI1MiA2NTUzNSBmDQowMDAwMDAwMjUzIDY1NTM1
IGYNCjAwMDAwMDAyNTQgNjU1MzUgZg0KMDAwMDAwMDI1NSA2NTUzNSBmDQowMDAwMDAwMjU2IDY1
NTM1IGYNCjAwMDAwMDAyNTcgNjU1MzUgZg0KMDAwMDAwMDI1OCA2NTUzNSBmDQowMDAwMDAwMjU5
IDY1NTM1IGYNCjAwMDAwMDAyNjAgNjU1MzUgZg0KMDAwMDAwMDI2MSA2NTUzNSBmDQowMDAwMDAw
MjYyIDY1NTM1IGYNCjAwMDAwMDAyNjMgNjU1MzUgZg0KMDAwMDAwMDI2NCA2NTUzNSBmDQowMDAw
MDAwMjY1IDY1NTM1IGYNCjAwMDAwMDAyNjYgNjU1MzUgZg0KMDAwMDAwMDI2NyA2NTUzNSBmDQow
MDAwMDAwMjY4IDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAzMjYxOSAwMDAwMCBu
DQowMDAwMDMyOTg1IDAwMDAwIG4NCjAwMDAxMzA3ODAgMDAwMDAgbg0KMDAwMDEzMDkzMiAwMDAw
MCBuDQowMDAwMTMwOTYwIDAwMDAwIG4NCjAwMDAxMzEzNTEgMDAwMDAgbg0KMDAwMDIzMDQ5MiAw
MDAwMCBuDQowMDAwMjMwNjgwIDAwMDAwIG4NCjAwMDAyMzA3MDggMDAwMDAgbg0KMDAwMDIzMTI1
NyAwMDAwMCBuDQowMDAwMzI1MjgyIDAwMDAwIG4NCjAwMDAzMjU5MzYgMDAwMDAgbg0KMDAwMDMy
NjI3MiAwMDAwMCBuDQowMDAwMzI2NTI0IDAwMDAwIG4NCjAwMDA0MDY0MzkgMDAwMDAgbg0KMDAw
MDQwNjY4OSAwMDAwMCBuDQowMDAwNTA2MjE4IDAwMDAwIG4NCjAwMDA1MDY1MTkgMDAwMDAgbg0K
MDAwMDUxODgzMSAwMDAwMCBuDQowMDAwNTE4ODc1IDAwMDAwIG4NCjAwMDA1MTg5MDMgMDAwMDAg
bg0KdHJhaWxlcg0KPDwvU2l6ZSAyOTAvUm9vdCAxIDAgUi9JbmZvIDQ3IDAgUi9JRFs8MThBQUZE
NTM2M0FCMTU0MEJDMDg3OTBDN0Y4RTY1N0U+PDE4QUFGRDUzNjNBQjE1NDBCQzA4NzkwQzdGOEU2
NTdFPl0gPj4NCnN0YXJ0eHJlZg0KNTE5NzMwDQolJUVPRg0KeHJlZg0KMCAwDQp0cmFpbGVyDQo8
PC9TaXplIDI5MC9Sb290IDEgMCBSL0luZm8gNDcgMCBSL0lEWzwxOEFBRkQ1MzYzQUIxNTQwQkMw
ODc5MEM3RjhFNjU3RT48MThBQUZENTM2M0FCMTU0MEJDMDg3OTBDN0Y4RTY1N0U+XSAvUHJldiA1
MTk3MzAvWFJlZlN0bSA1MTg5MDM+Pg0Kc3RhcnR4cmVmDQo1MjU2OTANCiUlRU9G

--_002_048EAD622912254A9DEA24C1734613C18C86D229FFFTLPMAILBOX02_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_002_048EAD622912254A9DEA24C1734613C18C86D229FFFTLPMAILBOX02_--


From xen-devel-bounces@lists.xen.org Tue Oct 16 21:50:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 21:50:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOF1P-0004xW-VY; Tue, 16 Oct 2012 21:49:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOF1O-0004xM-KQ
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 21:49:54 +0000
Received: from [85.158.143.99:28989] by server-1.bemta-4.messagelabs.com id
	32/5F-19134-186DD705; Tue, 16 Oct 2012 21:49:53 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1350424193!28259503!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29514 invoked from network); 16 Oct 2012 21:49:53 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 21:49:53 -0000
Received: by mail-we0-f173.google.com with SMTP id t11so4872706wey.32
	for ; Tue, 16 Oct 2012 14:49:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=rD2ju4FmPU3xGPfuo2B4bKi/QZu5cJx4dAqIQ1TKb8M=;
	b=WA9C7M0m+2E8yGlNh42II6TeJdPTh1Z1MLpozTKq3UI5V+Zjz2sRFo+0pAApOGZDkH
	6ZvV73+E2WhsNF/ILr6UYCHeoPaINzCBwwfSpzi5qB3kqX1vKiRpEsXMIVFA+Y5LG+jj
	HVSEnZAP13z71EXK6klcDtSWFndPkwoJWWYZlI+1ASeysqQIYMqMh/GHzuVq50y+RzEc
	Rm5abC/JOJHOb4+fvI9GK19znXHjMeWR2tjtmPESN3+O/v7AYuKjNg7j9iPJ+5wAa46D
	sGoGY2prVszsnDjn6VRTDD1IreRTV8tdml/5vqY6E2UoYRUV4FT8uBCy8csCnE7Myn1m
	sChQ==
Received: by 10.180.83.234 with SMTP id t10mr34575704wiy.7.1350424192954;
	Tue, 16 Oct 2012 14:49:52 -0700 (PDT)
Received: from [192.168.1.69]
	(host86-183-156-141.range86-183.btcentralplus.com. [86.183.156.141])
	by mx.google.com with ESMTPS id w8sm21064677wif.4.2012.10.16.14.49.50
	(version=SSLv3 cipher=OTHER); Tue, 16 Oct 2012 14:49:51 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Tue, 16 Oct 2012 22:49:49 +0100
From: Keir Fraser 
To: Jan Beulich 
Message-ID: 
Thread-Topic: [Xen-devel] [PATCH 1/3] x86/HPET: obtain proper lock for
	changing IRQ affinity
Thread-Index: Ac2r6CoOPQuR+XIti0m/BD5rzkg+HQ==
In-Reply-To: <507DA35102000078000A1C26@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel 
Subject: Re: [Xen-devel] [PATCH 1/3] x86/HPET: obtain proper lock for
 changing IRQ affinity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 16/10/2012 17:11, "Jan Beulich"  wrote:

>>>> On 16.10.12 at 17:41, Keir Fraser  wrote:
>> On 16/10/2012 16:09, "Jan Beulich"  wrote:
>> 
>>> The IRQ descriptor lock should be held while adjusting the affinity of
>>> any IRQ; the HPET channel lock isn't sufficient to protect namely
>>> against races with moving the IRQ to a different CPU.
>>> 
>>> Signed-off-by: Jan Beulich 
>> 
>> Would be more usual for the underscore-prefixed name to be the one that
>> doesn't take locks?
> 
> Will make the patch bigger, but I can certainly do that. I specifically
> picked only a single underscore to distinguish this a little from the
> "usual" case.

It doesn't make the patch much bigger, and it would be preferable.

> Jan
> 
>>> --- a/xen/arch/x86/hpet.c
>>> +++ b/xen/arch/x86/hpet.c
>>> @@ -436,6 +436,16 @@ static struct hpet_event_channel *hpet_g
>>>      return ch;
>>>  }
>>>  
>>> +static void _hpet_msi_set_affinity(const struct hpet_event_channel *ch)
>>> +{
>>> +    struct irq_desc *desc = irq_to_desc(ch->irq);
>>> +
>>> +    ASSERT(!local_irq_is_enabled());
>>> +    spin_lock(&desc->lock);
>>> +    hpet_msi_set_affinity(desc, cpumask_of(ch->cpu));
>>> +    spin_unlock(&desc->lock);
>>> +}
>>> +
>>>  static void hpet_attach_channel(unsigned int cpu,
>>>                                  struct hpet_event_channel *ch)
>>>  {
>>> @@ -450,7 +460,7 @@ static void hpet_attach_channel(unsigned
>>>      if ( ch->cpu != cpu )
>>>          return;
>>>  
>>> -    hpet_msi_set_affinity(irq_to_desc(ch->irq), cpumask_of(ch->cpu));
>>> +    _hpet_msi_set_affinity(ch);
>>>  }
>>>  
>>>  static void hpet_detach_channel(unsigned int cpu,
>>> @@ -472,7 +482,7 @@ static void hpet_detach_channel(unsigned
>>>      }
>>>  
>>>      ch->cpu = cpumask_first(ch->cpumask);
>>> -    hpet_msi_set_affinity(irq_to_desc(ch->irq), cpumask_of(ch->cpu));
>>> +    _hpet_msi_set_affinity(ch);
>>>  }
>>>  
>>>  #include 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xen.org/xen-devel
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 21:50:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 21:50:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOF1P-0004xW-VY; Tue, 16 Oct 2012 21:49:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOF1O-0004xM-KQ
	for xen-devel@lists.xen.org; Tue, 16 Oct 2012 21:49:54 +0000
Received: from [85.158.143.99:28989] by server-1.bemta-4.messagelabs.com id
	32/5F-19134-186DD705; Tue, 16 Oct 2012 21:49:53 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1350424193!28259503!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29514 invoked from network); 16 Oct 2012 21:49:53 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Oct 2012 21:49:53 -0000
Received: by mail-we0-f173.google.com with SMTP id t11so4872706wey.32
	for ; Tue, 16 Oct 2012 14:49:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=rD2ju4FmPU3xGPfuo2B4bKi/QZu5cJx4dAqIQ1TKb8M=;
	b=WA9C7M0m+2E8yGlNh42II6TeJdPTh1Z1MLpozTKq3UI5V+Zjz2sRFo+0pAApOGZDkH
	6ZvV73+E2WhsNF/ILr6UYCHeoPaINzCBwwfSpzi5qB3kqX1vKiRpEsXMIVFA+Y5LG+jj
	HVSEnZAP13z71EXK6klcDtSWFndPkwoJWWYZlI+1ASeysqQIYMqMh/GHzuVq50y+RzEc
	Rm5abC/JOJHOb4+fvI9GK19znXHjMeWR2tjtmPESN3+O/v7AYuKjNg7j9iPJ+5wAa46D
	sGoGY2prVszsnDjn6VRTDD1IreRTV8tdml/5vqY6E2UoYRUV4FT8uBCy8csCnE7Myn1m
	sChQ==
Received: by 10.180.83.234 with SMTP id t10mr34575704wiy.7.1350424192954;
	Tue, 16 Oct 2012 14:49:52 -0700 (PDT)
Received: from [192.168.1.69]
	(host86-183-156-141.range86-183.btcentralplus.com. [86.183.156.141])
	by mx.google.com with ESMTPS id w8sm21064677wif.4.2012.10.16.14.49.50
	(version=SSLv3 cipher=OTHER); Tue, 16 Oct 2012 14:49:51 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Tue, 16 Oct 2012 22:49:49 +0100
From: Keir Fraser 
To: Jan Beulich 
Message-ID: 
Thread-Topic: [Xen-devel] [PATCH 1/3] x86/HPET: obtain proper lock for
	changing IRQ affinity
Thread-Index: Ac2r6CoOPQuR+XIti0m/BD5rzkg+HQ==
In-Reply-To: <507DA35102000078000A1C26@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel 
Subject: Re: [Xen-devel] [PATCH 1/3] x86/HPET: obtain proper lock for
 changing IRQ affinity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 16/10/2012 17:11, "Jan Beulich"  wrote:

>>>> On 16.10.12 at 17:41, Keir Fraser  wrote:
>> On 16/10/2012 16:09, "Jan Beulich"  wrote:
>> 
>>> The IRQ descriptor lock should be held while adjusting the affinity of
>>> any IRQ; the HPET channel lock isn't sufficient to protect namely
>>> against races with moving the IRQ to a different CPU.
>>> 
>>> Signed-off-by: Jan Beulich 
>> 
>> Would be more usual for the underscore-prefixed name to be the one that
>> doesn't take locks?
> 
> Will make the patch bigger, but I can certainly do that. I specifically
> picked only a single underscore to distinguish this a little from the
> "usual" case.

It doesn't make the patch much bigger, and it would be preferable.

> Jan
> 
>>> --- a/xen/arch/x86/hpet.c
>>> +++ b/xen/arch/x86/hpet.c
>>> @@ -436,6 +436,16 @@ static struct hpet_event_channel *hpet_g
>>>      return ch;
>>>  }
>>>  
>>> +static void _hpet_msi_set_affinity(const struct hpet_event_channel *ch)
>>> +{
>>> +    struct irq_desc *desc = irq_to_desc(ch->irq);
>>> +
>>> +    ASSERT(!local_irq_is_enabled());
>>> +    spin_lock(&desc->lock);
>>> +    hpet_msi_set_affinity(desc, cpumask_of(ch->cpu));
>>> +    spin_unlock(&desc->lock);
>>> +}
>>> +
>>>  static void hpet_attach_channel(unsigned int cpu,
>>>                                  struct hpet_event_channel *ch)
>>>  {
>>> @@ -450,7 +460,7 @@ static void hpet_attach_channel(unsigned
>>>      if ( ch->cpu != cpu )
>>>          return;
>>>  
>>> -    hpet_msi_set_affinity(irq_to_desc(ch->irq), cpumask_of(ch->cpu));
>>> +    _hpet_msi_set_affinity(ch);
>>>  }
>>>  
>>>  static void hpet_detach_channel(unsigned int cpu,
>>> @@ -472,7 +482,7 @@ static void hpet_detach_channel(unsigned
>>>      }
>>>  
>>>      ch->cpu = cpumask_first(ch->cpumask);
>>> -    hpet_msi_set_affinity(irq_to_desc(ch->irq), cpumask_of(ch->cpu));
>>> +    _hpet_msi_set_affinity(ch);
>>>  }
>>>  
>>>  #include 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xen.org/xen-devel
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 22:11:44 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 22:11:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOFM9-0005NG-7z; Tue, 16 Oct 2012 22:11:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOFM8-0005NB-7G
	for Xen-devel@lists.xensource.com; Tue, 16 Oct 2012 22:11:20 +0000
Received: from [85.158.138.51:14827] by server-12.bemta-3.messagelabs.com id
	DB/58-27853-58BDD705; Tue, 16 Oct 2012 22:11:17 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1350425475!34537866!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgxMzczNg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4621 invoked from network); 16 Oct 2012 22:11:17 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Oct 2012 22:11:17 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9GMBCHD024473
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 16 Oct 2012 22:11:13 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9GMBBjB004085
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 16 Oct 2012 22:11:12 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9GMBBge020506; Tue, 16 Oct 2012 17:11:11 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 16 Oct 2012 15:11:11 -0700
Date: Tue, 16 Oct 2012 15:11:08 -0700
From: Mukesh Rathor 
To: Ian Campbell 
Message-ID: <20121016151108.0d30e7cf@mantra.us.oracle.com>
In-Reply-To: <1350291497.18058.5.camel@zakaz.uk.xensource.com>
References: <20121011145711.0d9c27df@mantra.us.oracle.com>
	<1350031937.14806.49.camel@zakaz.uk.xensource.com>
	<20121012120619.6d8f3317@mantra.us.oracle.com>
	<1350291497.18058.5.camel@zakaz.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V2 2/7]: PVH: use native irq, enable callback,
 use HVM ring ops, ...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 15 Oct 2012 09:58:17 +0100
Ian Campbell  wrote:

> On Fri, 2012-10-12 at 20:06 +0100, Mukesh Rathor wrote:
> > On Fri, 12 Oct 2012 09:52:17 +0100
> > Ian Campbell  wrote:
> > 
> > > >  drivers/xen/cpu_hotplug.c            |    4 +++-
> > > >  drivers/xen/events.c                 |    9 ++++++++-
> > > >  drivers/xen/xenbus/xenbus_client.c   |    3 ++-
> > > >  7 files changed, 27 insertions(+), 8 deletions(-)
> > > > 
> > > union {
> > > 	struct {
> > > 		unsigned long gdt_frames[16], gdt_ents;
> > > 	} pv;
> > > 	struct {
> > > 		unsigned long gdtaddr, gdtsz;
> > > 	} pvh;
> > > } gdt;
> > > 
> > > (I've gone with naming the union gdt instead of u. You might want
> > > therefore to also drop the gdt prefix from the members?)
> > 
> > Is it worth it, I mean, making it a union. Would you be OK if I just
> > used gdt_frames[0] and gdt_ends for gdtaddr and size?
> 
> What's the problem with making it a union? Seems like you are 80% of
> the way there.

No problem. It resutls in a patch on xen side too. I'll send that too.

> units AFAICT and so can be combined.
> 
> How come you don't need the same stuff for ldt*?

Happens natively. Isn't PVH great!

thanks
mukesh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 16 22:11:44 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 16 Oct 2012 22:11:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOFM9-0005NG-7z; Tue, 16 Oct 2012 22:11:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOFM8-0005NB-7G
	for Xen-devel@lists.xensource.com; Tue, 16 Oct 2012 22:11:20 +0000
Received: from [85.158.138.51:14827] by server-12.bemta-3.messagelabs.com id
	DB/58-27853-58BDD705; Tue, 16 Oct 2012 22:11:17 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1350425475!34537866!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgxMzczNg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4621 invoked from network); 16 Oct 2012 22:11:17 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Oct 2012 22:11:17 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9GMBCHD024473
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 16 Oct 2012 22:11:13 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9GMBBjB004085
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 16 Oct 2012 22:11:12 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9GMBBge020506; Tue, 16 Oct 2012 17:11:11 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 16 Oct 2012 15:11:11 -0700
Date: Tue, 16 Oct 2012 15:11:08 -0700
From: Mukesh Rathor 
To: Ian Campbell 
Message-ID: <20121016151108.0d30e7cf@mantra.us.oracle.com>
In-Reply-To: <1350291497.18058.5.camel@zakaz.uk.xensource.com>
References: <20121011145711.0d9c27df@mantra.us.oracle.com>
	<1350031937.14806.49.camel@zakaz.uk.xensource.com>
	<20121012120619.6d8f3317@mantra.us.oracle.com>
	<1350291497.18058.5.camel@zakaz.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V2 2/7]: PVH: use native irq, enable callback,
 use HVM ring ops, ...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 15 Oct 2012 09:58:17 +0100
Ian Campbell  wrote:

> On Fri, 2012-10-12 at 20:06 +0100, Mukesh Rathor wrote:
> > On Fri, 12 Oct 2012 09:52:17 +0100
> > Ian Campbell  wrote:
> > 
> > > >  drivers/xen/cpu_hotplug.c            |    4 +++-
> > > >  drivers/xen/events.c                 |    9 ++++++++-
> > > >  drivers/xen/xenbus/xenbus_client.c   |    3 ++-
> > > >  7 files changed, 27 insertions(+), 8 deletions(-)
> > > > 
> > > union {
> > > 	struct {
> > > 		unsigned long gdt_frames[16], gdt_ents;
> > > 	} pv;
> > > 	struct {
> > > 		unsigned long gdtaddr, gdtsz;
> > > 	} pvh;
> > > } gdt;
> > > 
> > > (I've gone with naming the union gdt instead of u. You might want
> > > therefore to also drop the gdt prefix from the members?)
> > 
> > Is it worth it, I mean, making it a union. Would you be OK if I just
> > used gdt_frames[0] and gdt_ends for gdtaddr and size?
> 
> What's the problem with making it a union? Seems like you are 80% of
> the way there.

No problem. It resutls in a patch on xen side too. I'll send that too.

> units AFAICT and so can be combined.
> 
> How come you don't need the same stuff for ldt*?

Happens natively. Isn't PVH great!

thanks
mukesh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 00:09:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 00:09:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOHCA-0006X9-KJ; Wed, 17 Oct 2012 00:09:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOHC8-0006X1-Od
	for Xen-devel@lists.xensource.com; Wed, 17 Oct 2012 00:09:08 +0000
Received: from [85.158.143.99:27265] by server-3.bemta-4.messagelabs.com id
	D1/7D-03544-427FD705; Wed, 17 Oct 2012 00:09:08 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1350432546!29097374!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODA4MTY1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20967 invoked from network); 17 Oct 2012 00:09:07 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Oct 2012 00:09:07 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9H0934B001278
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Oct 2012 00:09:04 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9H09327028124
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Oct 2012 00:09:03 GMT
Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9H092Tt021269; Tue, 16 Oct 2012 19:09:02 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 16 Oct 2012 17:09:02 -0700
Date: Tue, 16 Oct 2012 17:09:00 -0700
From: Mukesh Rathor 
To: Ian Campbell 
Message-ID: <20121016170900.665acf55@mantra.us.oracle.com>
In-Reply-To: <1350032817.14806.58.camel@zakaz.uk.xensource.com>
References: <20121011150113.4d525407@mantra.us.oracle.com>
	<1350032817.14806.58.camel@zakaz.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V2 6/7]: PVH: balloon and grant changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 12 Oct 2012 10:06:57 +0100
Ian Campbell  wrote:

> On Thu, 2012-10-11 at 23:01 +0100, Mukesh Rathor wrote:
> > PVH: balloon and grant changes. For balloon changes we skip setting
> > of local p2m as it's updated in xen. For grant, the shared grant
> > frame is the pfn and not mfn, hence its mapped via the same code
> > path as HVM
> > 
> > Signed-off-by: Mukesh R 
> > ---
> >  drivers/xen/balloon.c     |   18 +++++++++++-------
> >  drivers/xen/gntdev.c      |    3 ++-
> >  drivers/xen/grant-table.c |   25 +++++++++++++++++++++----
> >  3 files changed, 34 insertions(+), 12 deletions(-)
> > 
> > diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> > index 31ab82f..9b895ad 100644
> > --- a/drivers/xen/balloon.c
> > +++ b/drivers/xen/balloon.c
> > @@ -358,10 +358,13 @@ static enum bp_state
> > increase_reservation(unsigned long nr_pages)
> > BUG_ON(!xen_feature(XENFEAT_auto_translated_physmap) &&
> > phys_to_machine_mapping_valid(pfn)); 
> > -		set_phys_to_machine(pfn, frame_list[i]);
> > +		if (!xen_feature(XENFEAT_auto_translated_physmap))
> > +			set_phys_to_machine(pfn, frame_list[i]);
> 
> set_phys_to_machine is a NOP if XENFEAT_auto_translated_physmap but it
> includes some useful sanity checks (BUG_ON(pfn != mfn && mfn !=
> INVALID_P2M_ENTRY)) so it would be useful to keep calling it I think.

ok, fine, done.

> > +		     !xen_feature(XENFEAT_auto_translated_physmap);
> >  
> >  	err = misc_register(&gntdev_miscdev);
> >  	if (err != 0) {
> > @@ -1055,7 +1060,7 @@ static void gnttab_request_version(void)
> >  	int rc;
> >  	struct gnttab_set_version gsv;
> >  
> > -	if (xen_hvm_domain())
> > +	if (xen_hvm_domain() ||
> > xen_feature(XENFEAT_auto_translated_physmap))
> 
> This is just a case of not yet implemented rather than a fundamental
> problem with v2 grant tables, correct? (i.e. future work)

Right. 

> >  		gsv.version = 1;
> >  	else
> >  		gsv.version = 2;
> > @@ -1083,12 +1088,24 @@ static void gnttab_request_version(void)
> >  int gnttab_resume(void)
> >  {
> >  	unsigned int max_nr_gframes;
> > +	char *kmsg = "Failed to kmalloc pages for pv in hvm grant
> > frames\n"; 
> >  	gnttab_request_version();
> >  	max_nr_gframes = gnttab_max_grant_frames();
> >  	if (max_nr_gframes < nr_grant_frames)
> >  		return -ENOSYS;
> >  
> > +	/* PVH note: xen will free existing kmalloc'd mfn in
> > +	 * XENMEM_add_to_physmap */
> 
> It doesn't leak it?
> We should consider using xenballoon_alloc_pages here.

Well, it's a one time allocation of a dozen (iirc) pages, that are 
returned back to dom heap. We could use xenballoon, but for that we
need to create vma first so we get the contigous VA, then map each pte
since xenballoon_ doesn't return contigous pages, and then populate
physmap. I'm gonna punt it to phase II.  Lets get some working baseline
in asap.

thanks
mukesh


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 00:09:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 00:09:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOHCA-0006X9-KJ; Wed, 17 Oct 2012 00:09:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOHC8-0006X1-Od
	for Xen-devel@lists.xensource.com; Wed, 17 Oct 2012 00:09:08 +0000
Received: from [85.158.143.99:27265] by server-3.bemta-4.messagelabs.com id
	D1/7D-03544-427FD705; Wed, 17 Oct 2012 00:09:08 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1350432546!29097374!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODA4MTY1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20967 invoked from network); 17 Oct 2012 00:09:07 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Oct 2012 00:09:07 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9H0934B001278
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Oct 2012 00:09:04 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9H09327028124
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Oct 2012 00:09:03 GMT
Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9H092Tt021269; Tue, 16 Oct 2012 19:09:02 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 16 Oct 2012 17:09:02 -0700
Date: Tue, 16 Oct 2012 17:09:00 -0700
From: Mukesh Rathor 
To: Ian Campbell 
Message-ID: <20121016170900.665acf55@mantra.us.oracle.com>
In-Reply-To: <1350032817.14806.58.camel@zakaz.uk.xensource.com>
References: <20121011150113.4d525407@mantra.us.oracle.com>
	<1350032817.14806.58.camel@zakaz.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V2 6/7]: PVH: balloon and grant changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 12 Oct 2012 10:06:57 +0100
Ian Campbell  wrote:

> On Thu, 2012-10-11 at 23:01 +0100, Mukesh Rathor wrote:
> > PVH: balloon and grant changes. For balloon changes we skip setting
> > of local p2m as it's updated in xen. For grant, the shared grant
> > frame is the pfn and not mfn, hence its mapped via the same code
> > path as HVM
> > 
> > Signed-off-by: Mukesh R 
> > ---
> >  drivers/xen/balloon.c     |   18 +++++++++++-------
> >  drivers/xen/gntdev.c      |    3 ++-
> >  drivers/xen/grant-table.c |   25 +++++++++++++++++++++----
> >  3 files changed, 34 insertions(+), 12 deletions(-)
> > 
> > diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> > index 31ab82f..9b895ad 100644
> > --- a/drivers/xen/balloon.c
> > +++ b/drivers/xen/balloon.c
> > @@ -358,10 +358,13 @@ static enum bp_state
> > increase_reservation(unsigned long nr_pages)
> > BUG_ON(!xen_feature(XENFEAT_auto_translated_physmap) &&
> > phys_to_machine_mapping_valid(pfn)); 
> > -		set_phys_to_machine(pfn, frame_list[i]);
> > +		if (!xen_feature(XENFEAT_auto_translated_physmap))
> > +			set_phys_to_machine(pfn, frame_list[i]);
> 
> set_phys_to_machine is a NOP if XENFEAT_auto_translated_physmap but it
> includes some useful sanity checks (BUG_ON(pfn != mfn && mfn !=
> INVALID_P2M_ENTRY)) so it would be useful to keep calling it I think.

ok, fine, done.

> > +		     !xen_feature(XENFEAT_auto_translated_physmap);
> >  
> >  	err = misc_register(&gntdev_miscdev);
> >  	if (err != 0) {
> > @@ -1055,7 +1060,7 @@ static void gnttab_request_version(void)
> >  	int rc;
> >  	struct gnttab_set_version gsv;
> >  
> > -	if (xen_hvm_domain())
> > +	if (xen_hvm_domain() ||
> > xen_feature(XENFEAT_auto_translated_physmap))
> 
> This is just a case of not yet implemented rather than a fundamental
> problem with v2 grant tables, correct? (i.e. future work)

Right. 

> >  		gsv.version = 1;
> >  	else
> >  		gsv.version = 2;
> > @@ -1083,12 +1088,24 @@ static void gnttab_request_version(void)
> >  int gnttab_resume(void)
> >  {
> >  	unsigned int max_nr_gframes;
> > +	char *kmsg = "Failed to kmalloc pages for pv in hvm grant
> > frames\n"; 
> >  	gnttab_request_version();
> >  	max_nr_gframes = gnttab_max_grant_frames();
> >  	if (max_nr_gframes < nr_grant_frames)
> >  		return -ENOSYS;
> >  
> > +	/* PVH note: xen will free existing kmalloc'd mfn in
> > +	 * XENMEM_add_to_physmap */
> 
> It doesn't leak it?
> We should consider using xenballoon_alloc_pages here.

Well, it's a one time allocation of a dozen (iirc) pages, that are 
returned back to dom heap. We could use xenballoon, but for that we
need to create vma first so we get the contigous VA, then map each pte
since xenballoon_ doesn't return contigous pages, and then populate
physmap. I'm gonna punt it to phase II.  Lets get some working baseline
in asap.

thanks
mukesh


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 00:16:06 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 00:16:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOHIR-0006fx-Jr; Wed, 17 Oct 2012 00:15:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOHIQ-0006fr-CI
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 00:15:38 +0000
Received: from [85.158.143.99:50742] by server-3.bemta-4.messagelabs.com id
	CA/30-03544-9A8FD705; Wed, 17 Oct 2012 00:15:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1350432936!27950332!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQzMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28106 invoked from network); 17 Oct 2012 00:15:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 00:15:37 -0000
X-IronPort-AV: E=Sophos;i="4.80,595,1344211200"; d="scan'208";a="15214056"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 00:15:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 17 Oct 2012 01:15:37 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TOHIO-0001Mp-Dy;
	Wed, 17 Oct 2012 00:15:36 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TOHIO-0002ES-Da;
	Wed, 17 Oct 2012 01:15:36 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Wed, 17 Oct 2012 01:15:36 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13973: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13973 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13973/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 13967
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-pv            5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl           5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                fail REGR. vs. 13967
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 13967
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 13967
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 13967
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot          fail REGR. vs. 13967

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-pair         8 xen-boot/dst_host           fail pass in 13972
 test-amd64-amd64-pair         7 xen-boot/src_host           fail pass in 13972

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13967
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13967

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  4fc87c2f31a0
baseline version:
 xen                  c1c549c4fe9e

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf 
  Huang Ying 
  Jan Beulich 
  Keir Fraser 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26060:4fc87c2f31a0
tag:         tip
user:        Huang Ying 
date:        Tue Oct 16 17:26:36 2012 +0200
    
    ACPI: fix APEI related table size checking
    
    On Huang Ying's machine:
    
    erst_tab->header_length == sizeof(struct acpi_table_einj)
    
    but Yinghai reported that on his machine,
    
    erst_tab->header_length == sizeof(struct acpi_table_einj) -
    sizeof(struct acpi_table_header)
    
    To make erst table size checking code works on all systems, both
    testing are treated as PASS.
    
    Same situation applies to einj_tab->header_length, so corresponding
    table size checking is changed in similar way too.
    
    Originally-by: Yinghai Lu 
    Signed-off-by: Huang Ying 
    
    - use switch() for better readability
    - add comment explaining why a formally invalid size it also being
      accepted
    - check erst_tab->header.length before even looking at
      erst_tab->header_length
    - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    Committed-by: Jan Beulich 
    
    
changeset:   26059:c1c549c4fe9e
user:        Daniel De Graaf 
date:        Mon Oct 15 16:51:44 2012 +0100
    
    xen: Add versions of rcu_lock_*_domain without IS_PRIV
    
    These functions will be used to avoid duplication of IS_PRIV calls
    that will be introduced in XSM hooks. This also fixes a build error
    with XSM enabled introduced by 25925:d1c3375c3f11 which depends on
    this patch.
    
    Signed-off-by: Daniel De Graaf 
    Committed-by: Keir Fraser 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 00:16:06 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 00:16:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOHIR-0006fx-Jr; Wed, 17 Oct 2012 00:15:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOHIQ-0006fr-CI
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 00:15:38 +0000
Received: from [85.158.143.99:50742] by server-3.bemta-4.messagelabs.com id
	CA/30-03544-9A8FD705; Wed, 17 Oct 2012 00:15:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1350432936!27950332!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQzMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28106 invoked from network); 17 Oct 2012 00:15:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 00:15:37 -0000
X-IronPort-AV: E=Sophos;i="4.80,595,1344211200"; d="scan'208";a="15214056"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 00:15:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 17 Oct 2012 01:15:37 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TOHIO-0001Mp-Dy;
	Wed, 17 Oct 2012 00:15:36 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TOHIO-0002ES-Da;
	Wed, 17 Oct 2012 01:15:36 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Wed, 17 Oct 2012 01:15:36 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13973: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13973 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13973/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 13967
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-pv            5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl           5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                fail REGR. vs. 13967
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 13967
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 13967
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 13967
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot          fail REGR. vs. 13967

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-pair         8 xen-boot/dst_host           fail pass in 13972
 test-amd64-amd64-pair         7 xen-boot/src_host           fail pass in 13972

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13967
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13967

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  4fc87c2f31a0
baseline version:
 xen                  c1c549c4fe9e

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf 
  Huang Ying 
  Jan Beulich 
  Keir Fraser 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26060:4fc87c2f31a0
tag:         tip
user:        Huang Ying 
date:        Tue Oct 16 17:26:36 2012 +0200
    
    ACPI: fix APEI related table size checking
    
    On Huang Ying's machine:
    
    erst_tab->header_length == sizeof(struct acpi_table_einj)
    
    but Yinghai reported that on his machine,
    
    erst_tab->header_length == sizeof(struct acpi_table_einj) -
    sizeof(struct acpi_table_header)
    
    To make erst table size checking code works on all systems, both
    testing are treated as PASS.
    
    Same situation applies to einj_tab->header_length, so corresponding
    table size checking is changed in similar way too.
    
    Originally-by: Yinghai Lu 
    Signed-off-by: Huang Ying 
    
    - use switch() for better readability
    - add comment explaining why a formally invalid size it also being
      accepted
    - check erst_tab->header.length before even looking at
      erst_tab->header_length
    - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    Committed-by: Jan Beulich 
    
    
changeset:   26059:c1c549c4fe9e
user:        Daniel De Graaf 
date:        Mon Oct 15 16:51:44 2012 +0100
    
    xen: Add versions of rcu_lock_*_domain without IS_PRIV
    
    These functions will be used to avoid duplication of IS_PRIV calls
    that will be introduced in XSM hooks. This also fixes a build error
    with XSM enabled introduced by 25925:d1c3375c3f11 which depends on
    this patch.
    
    Signed-off-by: Daniel De Graaf 
    Committed-by: Keir Fraser 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 04:36:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 04:36:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOLMQ-0003zq-VG; Wed, 17 Oct 2012 04:36:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOLMP-0003zl-Pv
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 04:36:02 +0000
Received: from [85.158.138.51:60156] by server-9.bemta-3.messagelabs.com id
	D0/E3-16841-0B53E705; Wed, 17 Oct 2012 04:36:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1350448559!34724044!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ1MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17927 invoked from network); 17 Oct 2012 04:35:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 04:35:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,597,1344211200"; d="scan'208";a="15215141"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 04:35:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 17 Oct 2012 05:35:58 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TOLMM-0002sX-80;
	Wed, 17 Oct 2012 04:35:58 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TOLMM-0008Il-48;
	Wed, 17 Oct 2012 05:35:58 +0100
To: 
Message-ID: 
From: xen.org 
Date: Wed, 17 Oct 2012 05:35:58 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13979: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13979 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13979/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 13967
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-pv            5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl           5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                fail REGR. vs. 13967
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 13967
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 13967
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 13967
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot          fail REGR. vs. 13967

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-pair         8 xen-boot/dst_host           fail pass in 13972
 test-amd64-amd64-pair         7 xen-boot/src_host           fail pass in 13972

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13967
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13967

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  4fc87c2f31a0
baseline version:
 xen                  c1c549c4fe9e

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf 
  Huang Ying 
  Jan Beulich 
  Keir Fraser 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26060:4fc87c2f31a0
tag:         tip
user:        Huang Ying 
date:        Tue Oct 16 17:26:36 2012 +0200
    
    ACPI: fix APEI related table size checking
    
    On Huang Ying's machine:
    
    erst_tab->header_length == sizeof(struct acpi_table_einj)
    
    but Yinghai reported that on his machine,
    
    erst_tab->header_length == sizeof(struct acpi_table_einj) -
    sizeof(struct acpi_table_header)
    
    To make erst table size checking code works on all systems, both
    testing are treated as PASS.
    
    Same situation applies to einj_tab->header_length, so corresponding
    table size checking is changed in similar way too.
    
    Originally-by: Yinghai Lu 
    Signed-off-by: Huang Ying 
    
    - use switch() for better readability
    - add comment explaining why a formally invalid size it also being
      accepted
    - check erst_tab->header.length before even looking at
      erst_tab->header_length
    - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    Committed-by: Jan Beulich 
    
    
changeset:   26059:c1c549c4fe9e
user:        Daniel De Graaf 
date:        Mon Oct 15 16:51:44 2012 +0100
    
    xen: Add versions of rcu_lock_*_domain without IS_PRIV
    
    These functions will be used to avoid duplication of IS_PRIV calls
    that will be introduced in XSM hooks. This also fixes a build error
    with XSM enabled introduced by 25925:d1c3375c3f11 which depends on
    this patch.
    
    Signed-off-by: Daniel De Graaf 
    Committed-by: Keir Fraser 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 04:36:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 04:36:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOLMQ-0003zq-VG; Wed, 17 Oct 2012 04:36:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOLMP-0003zl-Pv
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 04:36:02 +0000
Received: from [85.158.138.51:60156] by server-9.bemta-3.messagelabs.com id
	D0/E3-16841-0B53E705; Wed, 17 Oct 2012 04:36:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1350448559!34724044!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ1MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17927 invoked from network); 17 Oct 2012 04:35:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 04:35:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,597,1344211200"; d="scan'208";a="15215141"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 04:35:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 17 Oct 2012 05:35:58 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TOLMM-0002sX-80;
	Wed, 17 Oct 2012 04:35:58 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TOLMM-0008Il-48;
	Wed, 17 Oct 2012 05:35:58 +0100
To: 
Message-ID: 
From: xen.org 
Date: Wed, 17 Oct 2012 05:35:58 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13979: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13979 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13979/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 13967
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-pv            5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl           5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                fail REGR. vs. 13967
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 13967
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 13967
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 13967
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot          fail REGR. vs. 13967

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-pair         8 xen-boot/dst_host           fail pass in 13972
 test-amd64-amd64-pair         7 xen-boot/src_host           fail pass in 13972

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13967
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13967

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  4fc87c2f31a0
baseline version:
 xen                  c1c549c4fe9e

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf 
  Huang Ying 
  Jan Beulich 
  Keir Fraser 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26060:4fc87c2f31a0
tag:         tip
user:        Huang Ying 
date:        Tue Oct 16 17:26:36 2012 +0200
    
    ACPI: fix APEI related table size checking
    
    On Huang Ying's machine:
    
    erst_tab->header_length == sizeof(struct acpi_table_einj)
    
    but Yinghai reported that on his machine,
    
    erst_tab->header_length == sizeof(struct acpi_table_einj) -
    sizeof(struct acpi_table_header)
    
    To make erst table size checking code works on all systems, both
    testing are treated as PASS.
    
    Same situation applies to einj_tab->header_length, so corresponding
    table size checking is changed in similar way too.
    
    Originally-by: Yinghai Lu 
    Signed-off-by: Huang Ying 
    
    - use switch() for better readability
    - add comment explaining why a formally invalid size it also being
      accepted
    - check erst_tab->header.length before even looking at
      erst_tab->header_length
    - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    Committed-by: Jan Beulich 
    
    
changeset:   26059:c1c549c4fe9e
user:        Daniel De Graaf 
date:        Mon Oct 15 16:51:44 2012 +0100
    
    xen: Add versions of rcu_lock_*_domain without IS_PRIV
    
    These functions will be used to avoid duplication of IS_PRIV calls
    that will be introduced in XSM hooks. This also fixes a build error
    with XSM enabled introduced by 25925:d1c3375c3f11 which depends on
    this patch.
    
    Signed-off-by: Daniel De Graaf 
    Committed-by: Keir Fraser 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 05:25:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 05:25:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOM7d-0004pO-R9; Wed, 17 Oct 2012 05:24:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOM7c-0004pJ-5x
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 05:24:48 +0000
Received: from [85.158.138.51:18546] by server-5.bemta-3.messagelabs.com id
	B5/46-12440-F114E705; Wed, 17 Oct 2012 05:24:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1350451484!25769084!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ1MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18739 invoked from network); 17 Oct 2012 05:24:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 05:24:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,597,1344211200"; d="scan'208";a="15215529"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 05:24:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 17 Oct 2012 06:24:44 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TOM7X-00038C-TT;
	Wed, 17 Oct 2012 05:24:43 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TOM7X-00085G-SM;
	Wed, 17 Oct 2012 06:24:43 +0100
To: 
Message-ID: 
From: xen.org 
Date: Wed, 17 Oct 2012 06:24:43 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete
	test-amd64-i386-qemuu-rhel6hvm-amd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-qemuu-rhel6hvm-amd
test xen-boot

Tree: linux git://xenbits.xen.org/linux-pvops.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 http://xenbits.xen.org/hg/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
  Bug introduced:  4fc87c2f31a0
  Bug not present: c1c549c4fe9e


  changeset:   26060:4fc87c2f31a0
  tag:         tip
  user:        Huang Ying 
  date:        Tue Oct 16 17:26:36 2012 +0200
      
      ACPI: fix APEI related table size checking
      
      On Huang Ying's machine:
      
      erst_tab->header_length == sizeof(struct acpi_table_einj)
      
      but Yinghai reported that on his machine,
      
      erst_tab->header_length == sizeof(struct acpi_table_einj) -
      sizeof(struct acpi_table_header)
      
      To make erst table size checking code works on all systems, both
      testing are treated as PASS.
      
      Same situation applies to einj_tab->header_length, so corresponding
      table size checking is changed in similar way too.
      
      Originally-by: Yinghai Lu 
      Signed-off-by: Huang Ying 
      
      - use switch() for better readability
      - add comment explaining why a formally invalid size it also being
        accepted
      - check erst_tab->header.length before even looking at
        erst_tab->header_length
      - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
      
      Signed-off-by: Jan Beulich 
      Acked-by: Keir Fraser 
      Committed-by: Jan Beulich 
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-i386-qemuu-rhel6hvm-amd.xen-boot.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 13979 fail [host=leaf-beetle] / 13967 [host=potato-beetle] 13963 [host=lace-bug] 13962 [host=moss-bug] 13960 ok.
Failure / basis pass flights: 13979 / 13960
Tree: linux git://xenbits.xen.org/linux-pvops.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 http://xenbits.xen.org/hg/staging/xen-unstable.hg
Latest a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
Basis pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 e0e1350dfe9b
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#a938a246d34912423c560f475ccf1ce0c71d9d00-a938a246d34912423c560f475ccf1ce0c71d9d00 git://xenbits.xen.org/staging/qemu-xen-unstable.git#bacc0d302445c75f18f4c826750fb5853b60e7ca-bacc0d302445c75f18f4c826750fb5853b60e7ca git://xenbits.xen.org/staging/qemu-upstream-unstable.git#cdf4d2bb4006805f209712fbb8ed1f83127e9984-cdf4d2bb4006805f209712fbb8ed1f83127e9984 http://xenbits.xen.org/hg/staging/xen-unstable.hg#e0e1350dfe9b-4fc87c2f31a0
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
Loaded 239 nodes in revision graph
Searching for test results:
 13958 [host=potato-beetle]
 13960 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 e0e1350dfe9b
 13967 [host=potato-beetle]
 13978 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
 13962 [host=moss-bug]
 13972 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 13963 [host=lace-bug]
 13956 [host=lace-bug]
 13980 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 13964 []
 13974 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 e0e1350dfe9b
 13981 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
 13975 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 13976 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 177fdda0be56
 13982 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 13973 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 13977 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 37bb894121c7
 13979 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 13983 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
 13984 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
Searching for interesting versions
 Result found: flight 13960 (pass), for basis pass
 Result found: flight 13972 (fail), for basis failure
 Repro found: flight 13974 (pass), for basis pass
 Repro found: flight 13975 (fail), for basis failure
 0 revisions at a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
No revisions left to test, checking graph state.
 Result found: flight 13978 (pass), for last pass
 Result found: flight 13979 (fail), for first failure
 Repro found: flight 13981 (pass), for last pass
 Repro found: flight 13982 (fail), for first failure
 Repro found: flight 13983 (pass), for last pass
 Repro found: flight 13984 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
  Bug introduced:  4fc87c2f31a0
  Bug not present: c1c549c4fe9e

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   26060:4fc87c2f31a0
  tag:         tip
  user:        Huang Ying 
  date:        Tue Oct 16 17:26:36 2012 +0200
      
      ACPI: fix APEI related table size checking
      
      On Huang Ying's machine:
      
      erst_tab->header_length == sizeof(struct acpi_table_einj)
      
      but Yinghai reported that on his machine,
      
      erst_tab->header_length == sizeof(struct acpi_table_einj) -
      sizeof(struct acpi_table_header)
      
      To make erst table size checking code works on all systems, both
      testing are treated as PASS.
      
      Same situation applies to einj_tab->header_length, so corresponding
      table size checking is changed in similar way too.
      
      Originally-by: Yinghai Lu 
      Signed-off-by: Huang Ying 
      
      - use switch() for better readability
      - add comment explaining why a formally invalid size it also being
        accepted
      - check erst_tab->header.length before even looking at
        erst_tab->header_length
      - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
      
      Signed-off-by: Jan Beulich 
      Acked-by: Keir Fraser 
      Committed-by: Jan Beulich 
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-amd64-i386-qemuu-rhel6hvm-amd.xen-boot.{dot,ps,png,html}.
----------------------------------------
13984: tolerable ALL FAIL

flight 13984 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13984/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot          fail baseline untested


jobs:
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 05:25:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 05:25:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOM7d-0004pO-R9; Wed, 17 Oct 2012 05:24:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOM7c-0004pJ-5x
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 05:24:48 +0000
Received: from [85.158.138.51:18546] by server-5.bemta-3.messagelabs.com id
	B5/46-12440-F114E705; Wed, 17 Oct 2012 05:24:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1350451484!25769084!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ1MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18739 invoked from network); 17 Oct 2012 05:24:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 05:24:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,597,1344211200"; d="scan'208";a="15215529"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 05:24:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 17 Oct 2012 06:24:44 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TOM7X-00038C-TT;
	Wed, 17 Oct 2012 05:24:43 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TOM7X-00085G-SM;
	Wed, 17 Oct 2012 06:24:43 +0100
To: 
Message-ID: 
From: xen.org 
Date: Wed, 17 Oct 2012 06:24:43 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete
	test-amd64-i386-qemuu-rhel6hvm-amd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-qemuu-rhel6hvm-amd
test xen-boot

Tree: linux git://xenbits.xen.org/linux-pvops.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 http://xenbits.xen.org/hg/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
  Bug introduced:  4fc87c2f31a0
  Bug not present: c1c549c4fe9e


  changeset:   26060:4fc87c2f31a0
  tag:         tip
  user:        Huang Ying 
  date:        Tue Oct 16 17:26:36 2012 +0200
      
      ACPI: fix APEI related table size checking
      
      On Huang Ying's machine:
      
      erst_tab->header_length == sizeof(struct acpi_table_einj)
      
      but Yinghai reported that on his machine,
      
      erst_tab->header_length == sizeof(struct acpi_table_einj) -
      sizeof(struct acpi_table_header)
      
      To make erst table size checking code works on all systems, both
      testing are treated as PASS.
      
      Same situation applies to einj_tab->header_length, so corresponding
      table size checking is changed in similar way too.
      
      Originally-by: Yinghai Lu 
      Signed-off-by: Huang Ying 
      
      - use switch() for better readability
      - add comment explaining why a formally invalid size it also being
        accepted
      - check erst_tab->header.length before even looking at
        erst_tab->header_length
      - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
      
      Signed-off-by: Jan Beulich 
      Acked-by: Keir Fraser 
      Committed-by: Jan Beulich 
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-i386-qemuu-rhel6hvm-amd.xen-boot.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 13979 fail [host=leaf-beetle] / 13967 [host=potato-beetle] 13963 [host=lace-bug] 13962 [host=moss-bug] 13960 ok.
Failure / basis pass flights: 13979 / 13960
Tree: linux git://xenbits.xen.org/linux-pvops.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 http://xenbits.xen.org/hg/staging/xen-unstable.hg
Latest a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
Basis pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 e0e1350dfe9b
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#a938a246d34912423c560f475ccf1ce0c71d9d00-a938a246d34912423c560f475ccf1ce0c71d9d00 git://xenbits.xen.org/staging/qemu-xen-unstable.git#bacc0d302445c75f18f4c826750fb5853b60e7ca-bacc0d302445c75f18f4c826750fb5853b60e7ca git://xenbits.xen.org/staging/qemu-upstream-unstable.git#cdf4d2bb4006805f209712fbb8ed1f83127e9984-cdf4d2bb4006805f209712fbb8ed1f83127e9984 http://xenbits.xen.org/hg/staging/xen-unstable.hg#e0e1350dfe9b-4fc87c2f31a0
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
Loaded 239 nodes in revision graph
Searching for test results:
 13958 [host=potato-beetle]
 13960 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 e0e1350dfe9b
 13967 [host=potato-beetle]
 13978 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
 13962 [host=moss-bug]
 13972 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 13963 [host=lace-bug]
 13956 [host=lace-bug]
 13980 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 13964 []
 13974 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 e0e1350dfe9b
 13981 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
 13975 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 13976 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 177fdda0be56
 13982 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 13973 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 13977 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 37bb894121c7
 13979 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 13983 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
 13984 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
Searching for interesting versions
 Result found: flight 13960 (pass), for basis pass
 Result found: flight 13972 (fail), for basis failure
 Repro found: flight 13974 (pass), for basis pass
 Repro found: flight 13975 (fail), for basis failure
 0 revisions at a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
No revisions left to test, checking graph state.
 Result found: flight 13978 (pass), for last pass
 Result found: flight 13979 (fail), for first failure
 Repro found: flight 13981 (pass), for last pass
 Repro found: flight 13982 (fail), for first failure
 Repro found: flight 13983 (pass), for last pass
 Repro found: flight 13984 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
  Bug introduced:  4fc87c2f31a0
  Bug not present: c1c549c4fe9e

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   26060:4fc87c2f31a0
  tag:         tip
  user:        Huang Ying 
  date:        Tue Oct 16 17:26:36 2012 +0200
      
      ACPI: fix APEI related table size checking
      
      On Huang Ying's machine:
      
      erst_tab->header_length == sizeof(struct acpi_table_einj)
      
      but Yinghai reported that on his machine,
      
      erst_tab->header_length == sizeof(struct acpi_table_einj) -
      sizeof(struct acpi_table_header)
      
      To make erst table size checking code works on all systems, both
      testing are treated as PASS.
      
      Same situation applies to einj_tab->header_length, so corresponding
      table size checking is changed in similar way too.
      
      Originally-by: Yinghai Lu 
      Signed-off-by: Huang Ying 
      
      - use switch() for better readability
      - add comment explaining why a formally invalid size it also being
        accepted
      - check erst_tab->header.length before even looking at
        erst_tab->header_length
      - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
      
      Signed-off-by: Jan Beulich 
      Acked-by: Keir Fraser 
      Committed-by: Jan Beulich 
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-amd64-i386-qemuu-rhel6hvm-amd.xen-boot.{dot,ps,png,html}.
----------------------------------------
13984: tolerable ALL FAIL

flight 13984 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13984/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot          fail baseline untested


jobs:
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 06:57:20 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 06:57:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TONYj-0006By-5u; Wed, 17 Oct 2012 06:56:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TONYh-0006Bq-Fv
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 06:56:51 +0000
Received: from [85.158.137.99:50221] by server-6.bemta-3.messagelabs.com id
	A2/D0-32375-2B65E705; Wed, 17 Oct 2012 06:56:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1350457009!20657933!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22688 invoked from network); 17 Oct 2012 06:56:50 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-217.messagelabs.com with SMTP;
	17 Oct 2012 06:56:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 17 Oct 2012 07:56:49 +0100
Message-Id: <507E72CE02000078000A1DB5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 17 Oct 2012 07:56:46 +0100
From: "Jan Beulich" 
To: "Huang Ying" 
References: <507D8F6802000078000A1B88@nat28.tlf.novell.com>
	<1350456592.7098.42.camel@yhuang-dev>
In-Reply-To: <1350456592.7098.42.camel@yhuang-dev>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel 
Subject: Re: [Xen-devel] [PATCH] ACPI: fix APEI related table size checking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 17.10.12 at 08:49, Huang Ying  wrote:
> On Tue, 2012-10-16 at 15:46 +0100, Jan Beulich wrote:
>> On Huang Ying's machine:
>> 
>> erst_tab->header_length == sizeof(struct acpi_table_einj)
>   ~~~~                                                ~~~~
> 
> Typo?

Your typo: I copied the Linux commit message verbatim, to make
it possible to match the two commits. The adjustments done in
the actual patch eliminate the copy-n-paste mistake corrected by
Linux commit 7ed28f2ed43ece424ff2fa4dedac7928bb37a23a.

Jan

>> but Yinghai reported that on his machine,
>> 
>> erst_tab->header_length == sizeof(struct acpi_table_einj) -
>> sizeof(struct acpi_table_header)
>> 
>> To make erst table size checking code works on all systems, both
>> testing are treated as PASS.
>> 
>> Same situation applies to einj_tab->header_length, so corresponding
>> table size checking is changed in similar way too.
>> 
>> Originally-by: Yinghai Lu 
>> Signed-off-by: Huang Ying 
>> 
>> - use switch() for better readability
>> - add comment explaining why a formally invalid size it also being
>>   accepted
>> - check erst_tab->header.length before even looking at
>>   erst_tab->header_length
>> - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
>> 
>> Signed-off-by: Jan Beulich 
>> 
>> --- a/xen/drivers/acpi/apei/erst.c
>> +++ b/xen/drivers/acpi/apei/erst.c
>> @@ -715,12 +715,23 @@ int erst_clear(u64 record_id)
>>  
>>  static int __init erst_check_table(struct acpi_table_erst *erst_tab)
>>  {
>> -	if (erst_tab->header_length != sizeof(struct acpi_table_erst))
>> +	if (erst_tab->header.length < sizeof(*erst_tab))
>>  		return -EINVAL;
>> -	if (erst_tab->header.length < sizeof(struct acpi_table_erst))
>> +
>> +	switch (erst_tab->header_length) {
>> +	case sizeof(*erst_tab) - sizeof(erst_tab->header):
>> +	/*
>> +	 * While invalid per specification, there are (early?) systems
>> +	 * indicating the full header size here, so accept that value too.
>> +	 */
>> +	case sizeof(*erst_tab):
>> +		break;
>> +	default:
>>  		return -EINVAL;
>> +	}
>> +
>>  	if (erst_tab->entries !=
>> -	    (erst_tab->header.length - sizeof(struct acpi_table_erst)) /
>> +	    (erst_tab->header.length - sizeof(*erst_tab)) /
>>  	    sizeof(struct acpi_erst_entry))
>>  		return -EINVAL;
>>  
>> 
>> 
>> 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 06:57:20 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 06:57:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TONYj-0006By-5u; Wed, 17 Oct 2012 06:56:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TONYh-0006Bq-Fv
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 06:56:51 +0000
Received: from [85.158.137.99:50221] by server-6.bemta-3.messagelabs.com id
	A2/D0-32375-2B65E705; Wed, 17 Oct 2012 06:56:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1350457009!20657933!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22688 invoked from network); 17 Oct 2012 06:56:50 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-217.messagelabs.com with SMTP;
	17 Oct 2012 06:56:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 17 Oct 2012 07:56:49 +0100
Message-Id: <507E72CE02000078000A1DB5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 17 Oct 2012 07:56:46 +0100
From: "Jan Beulich" 
To: "Huang Ying" 
References: <507D8F6802000078000A1B88@nat28.tlf.novell.com>
	<1350456592.7098.42.camel@yhuang-dev>
In-Reply-To: <1350456592.7098.42.camel@yhuang-dev>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel 
Subject: Re: [Xen-devel] [PATCH] ACPI: fix APEI related table size checking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 17.10.12 at 08:49, Huang Ying  wrote:
> On Tue, 2012-10-16 at 15:46 +0100, Jan Beulich wrote:
>> On Huang Ying's machine:
>> 
>> erst_tab->header_length == sizeof(struct acpi_table_einj)
>   ~~~~                                                ~~~~
> 
> Typo?

Your typo: I copied the Linux commit message verbatim, to make
it possible to match the two commits. The adjustments done in
the actual patch eliminate the copy-n-paste mistake corrected by
Linux commit 7ed28f2ed43ece424ff2fa4dedac7928bb37a23a.

Jan

>> but Yinghai reported that on his machine,
>> 
>> erst_tab->header_length == sizeof(struct acpi_table_einj) -
>> sizeof(struct acpi_table_header)
>> 
>> To make erst table size checking code works on all systems, both
>> testing are treated as PASS.
>> 
>> Same situation applies to einj_tab->header_length, so corresponding
>> table size checking is changed in similar way too.
>> 
>> Originally-by: Yinghai Lu 
>> Signed-off-by: Huang Ying 
>> 
>> - use switch() for better readability
>> - add comment explaining why a formally invalid size it also being
>>   accepted
>> - check erst_tab->header.length before even looking at
>>   erst_tab->header_length
>> - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
>> 
>> Signed-off-by: Jan Beulich 
>> 
>> --- a/xen/drivers/acpi/apei/erst.c
>> +++ b/xen/drivers/acpi/apei/erst.c
>> @@ -715,12 +715,23 @@ int erst_clear(u64 record_id)
>>  
>>  static int __init erst_check_table(struct acpi_table_erst *erst_tab)
>>  {
>> -	if (erst_tab->header_length != sizeof(struct acpi_table_erst))
>> +	if (erst_tab->header.length < sizeof(*erst_tab))
>>  		return -EINVAL;
>> -	if (erst_tab->header.length < sizeof(struct acpi_table_erst))
>> +
>> +	switch (erst_tab->header_length) {
>> +	case sizeof(*erst_tab) - sizeof(erst_tab->header):
>> +	/*
>> +	 * While invalid per specification, there are (early?) systems
>> +	 * indicating the full header size here, so accept that value too.
>> +	 */
>> +	case sizeof(*erst_tab):
>> +		break;
>> +	default:
>>  		return -EINVAL;
>> +	}
>> +
>>  	if (erst_tab->entries !=
>> -	    (erst_tab->header.length - sizeof(struct acpi_table_erst)) /
>> +	    (erst_tab->header.length - sizeof(*erst_tab)) /
>>  	    sizeof(struct acpi_erst_entry))
>>  		return -EINVAL;
>>  
>> 
>> 
>> 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 07:05:01 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 07:05:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TONgC-0006ZE-Up; Wed, 17 Oct 2012 07:04:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TONgA-0006Z9-RG
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 07:04:34 +0000
Received: from [85.158.137.99:59620] by server-15.bemta-3.messagelabs.com id
	94/A1-10261-1885E705; Wed, 17 Oct 2012 07:04:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1350457473!18757992!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20644 invoked from network); 17 Oct 2012 07:04:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-217.messagelabs.com with SMTP;
	17 Oct 2012 07:04:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 17 Oct 2012 08:04:33 +0100
Message-Id: <507E749B02000078000A1DBF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 17 Oct 2012 08:04:27 +0100
From: "Jan Beulich" 
To: "Ian Campbell" ,
 "Ben Guthro" 
References: <20121016T192158.GA.6e659.stse@fsing.rootsland.net>
	
	<1350412943.14440.13.camel@dagon.hellion.org.uk>
In-Reply-To: <1350412943.14440.13.camel@dagon.hellion.org.uk>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Stephan Seitz ,
	Konrad Rzeszutek Wilk ,
	xen-devel 
Subject: Re: [Xen-devel] CPU microcode update under xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 16.10.12 at 20:42, Ian Campbell  wrote:
>> On Tue, Oct 16, 2012 at 1:27 PM, Stephan Seitz
>>  wrote:
> [...]
>> > Do I need another driver for microcode updates under XEN, or is it 
> impossible for now?
> 
> There is also the option for Xen itself to load the microcode.
> 
> See the ucode option in
> http://xenbits.xen.org/docs/4.2-testing/misc/xen-command-line.html 
> 
> I think this is probably 4.2+ only though (not sure when it was added).

Yes, this is 4.2+ only.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 07:05:01 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 07:05:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TONgC-0006ZE-Up; Wed, 17 Oct 2012 07:04:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TONgA-0006Z9-RG
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 07:04:34 +0000
Received: from [85.158.137.99:59620] by server-15.bemta-3.messagelabs.com id
	94/A1-10261-1885E705; Wed, 17 Oct 2012 07:04:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1350457473!18757992!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20644 invoked from network); 17 Oct 2012 07:04:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-217.messagelabs.com with SMTP;
	17 Oct 2012 07:04:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 17 Oct 2012 08:04:33 +0100
Message-Id: <507E749B02000078000A1DBF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 17 Oct 2012 08:04:27 +0100
From: "Jan Beulich" 
To: "Ian Campbell" ,
 "Ben Guthro" 
References: <20121016T192158.GA.6e659.stse@fsing.rootsland.net>
	
	<1350412943.14440.13.camel@dagon.hellion.org.uk>
In-Reply-To: <1350412943.14440.13.camel@dagon.hellion.org.uk>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Stephan Seitz ,
	Konrad Rzeszutek Wilk ,
	xen-devel 
Subject: Re: [Xen-devel] CPU microcode update under xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 16.10.12 at 20:42, Ian Campbell  wrote:
>> On Tue, Oct 16, 2012 at 1:27 PM, Stephan Seitz
>>  wrote:
> [...]
>> > Do I need another driver for microcode updates under XEN, or is it 
> impossible for now?
> 
> There is also the option for Xen itself to load the microcode.
> 
> See the ucode option in
> http://xenbits.xen.org/docs/4.2-testing/misc/xen-command-line.html 
> 
> I think this is probably 4.2+ only though (not sure when it was added).

Yes, this is 4.2+ only.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 07:14:15 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 07:14:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TONpA-0006ju-0S; Wed, 17 Oct 2012 07:13:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TONp8-0006jp-Oz
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 07:13:50 +0000
Received: from [85.158.139.211:12915] by server-16.bemta-5.messagelabs.com id
	40/41-09196-EAA5E705; Wed, 17 Oct 2012 07:13:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1350458029!22158673!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11833 invoked from network); 17 Oct 2012 07:13:49 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-206.messagelabs.com with SMTP;
	17 Oct 2012 07:13:49 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 17 Oct 2012 08:13:35 +0100
Message-Id: <507E76BC02000078000A1DCD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 17 Oct 2012 08:13:32 +0100
From: "Jan Beulich" 
To: "Laszlo Ersek" 
References: <507D7240.2010305@citrix.com>
	<1350408986-10891-1-git-send-email-lersek@redhat.com>
In-Reply-To: <1350408986-10891-1-git-send-email-lersek@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andrew.cooper3@citrix.com, jeremy@goop.org, konrad.wilk@oracle.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen PV passthru: assign SR-IOV virtual
 functions to separate virtual slots
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 16.10.12 at 19:36, Laszlo Ersek  wrote:
> VFs are reported as single-function devices in PCI_HEADER_TYPE, which
> causes pci_scan_slot() in the PV domU to skip all VFs beyond #0 in the
> pciback-provided slot. Avoid this by assigning each VF to a separate
> virtual slot.
> 
> Signed-off-by: Laszlo Ersek 
> ---
>  drivers/xen/xen-pciback/vpci.c |   35 ++++++++++++++++++++---------------
>  1 files changed, 20 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/xen/xen-pciback/vpci.c b/drivers/xen/xen-pciback/vpci.c
> index 46d140b..489404a 100644
> --- a/drivers/xen/xen-pciback/vpci.c
> +++ b/drivers/xen/xen-pciback/vpci.c
> @@ -89,21 +89,26 @@ static int __xen_pcibk_add_pci_dev(struct 
> xen_pcibk_device *pdev,
>  
>  	mutex_lock(&vpci_dev->lock);
>  
> -	/* Keep multi-function devices together on the virtual PCI bus */
> -	for (slot = 0; slot < PCI_SLOT_MAX; slot++) {
> -		if (!list_empty(&vpci_dev->dev_list[slot])) {
> -			t = list_entry(list_first(&vpci_dev->dev_list[slot]),
> -				       struct pci_dev_entry, list);
> -
> -			if (match_slot(dev, t->dev)) {
> -				pr_info(DRV_NAME ": vpci: %s: "
> -					"assign to virtual slot %d func %d\n",
> -					pci_name(dev), slot,
> -					PCI_FUNC(dev->devfn));
> -				list_add_tail(&dev_entry->list,
> -					      &vpci_dev->dev_list[slot]);
> -				func = PCI_FUNC(dev->devfn);
> -				goto unlock;
> +	/*
> +	 * Keep multi-function devices together on the virtual PCI bus, except
> +	 * virtual functions.
> +	 */
> +	if (!dev->is_virtfn) {
> +		for (slot = 0; slot < PCI_SLOT_MAX; slot++) {
> +			if (!list_empty(&vpci_dev->dev_list[slot])) {

To keep indentation reasonable (and shrink the patch size at once),
could you use

			if (list_empty(&vpci_dev->dev_list[slot]))
				continue;

here instead? Or alternatively tweak the for() above to embed the
if()'s condition there?

Jan

> +				t = list_entry(list_first(&vpci_dev->dev_list[slot]),
> +					       struct pci_dev_entry, list);
> +
> +				if (match_slot(dev, t->dev)) {
> +					pr_info(DRV_NAME ": vpci: %s: "
> +						"assign to virtual slot %d func %d\n",
> +						pci_name(dev), slot,
> +						PCI_FUNC(dev->devfn));
> +					list_add_tail(&dev_entry->list,
> +						      &vpci_dev->dev_list[slot]);
> +					func = PCI_FUNC(dev->devfn);
> +					goto unlock;
> +				}
>  			}
>  		}
>  	}
> -- 
> 1.7.1
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 07:14:15 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 07:14:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TONpA-0006ju-0S; Wed, 17 Oct 2012 07:13:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TONp8-0006jp-Oz
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 07:13:50 +0000
Received: from [85.158.139.211:12915] by server-16.bemta-5.messagelabs.com id
	40/41-09196-EAA5E705; Wed, 17 Oct 2012 07:13:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1350458029!22158673!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11833 invoked from network); 17 Oct 2012 07:13:49 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-206.messagelabs.com with SMTP;
	17 Oct 2012 07:13:49 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 17 Oct 2012 08:13:35 +0100
Message-Id: <507E76BC02000078000A1DCD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 17 Oct 2012 08:13:32 +0100
From: "Jan Beulich" 
To: "Laszlo Ersek" 
References: <507D7240.2010305@citrix.com>
	<1350408986-10891-1-git-send-email-lersek@redhat.com>
In-Reply-To: <1350408986-10891-1-git-send-email-lersek@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andrew.cooper3@citrix.com, jeremy@goop.org, konrad.wilk@oracle.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen PV passthru: assign SR-IOV virtual
 functions to separate virtual slots
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 16.10.12 at 19:36, Laszlo Ersek  wrote:
> VFs are reported as single-function devices in PCI_HEADER_TYPE, which
> causes pci_scan_slot() in the PV domU to skip all VFs beyond #0 in the
> pciback-provided slot. Avoid this by assigning each VF to a separate
> virtual slot.
> 
> Signed-off-by: Laszlo Ersek 
> ---
>  drivers/xen/xen-pciback/vpci.c |   35 ++++++++++++++++++++---------------
>  1 files changed, 20 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/xen/xen-pciback/vpci.c b/drivers/xen/xen-pciback/vpci.c
> index 46d140b..489404a 100644
> --- a/drivers/xen/xen-pciback/vpci.c
> +++ b/drivers/xen/xen-pciback/vpci.c
> @@ -89,21 +89,26 @@ static int __xen_pcibk_add_pci_dev(struct 
> xen_pcibk_device *pdev,
>  
>  	mutex_lock(&vpci_dev->lock);
>  
> -	/* Keep multi-function devices together on the virtual PCI bus */
> -	for (slot = 0; slot < PCI_SLOT_MAX; slot++) {
> -		if (!list_empty(&vpci_dev->dev_list[slot])) {
> -			t = list_entry(list_first(&vpci_dev->dev_list[slot]),
> -				       struct pci_dev_entry, list);
> -
> -			if (match_slot(dev, t->dev)) {
> -				pr_info(DRV_NAME ": vpci: %s: "
> -					"assign to virtual slot %d func %d\n",
> -					pci_name(dev), slot,
> -					PCI_FUNC(dev->devfn));
> -				list_add_tail(&dev_entry->list,
> -					      &vpci_dev->dev_list[slot]);
> -				func = PCI_FUNC(dev->devfn);
> -				goto unlock;
> +	/*
> +	 * Keep multi-function devices together on the virtual PCI bus, except
> +	 * virtual functions.
> +	 */
> +	if (!dev->is_virtfn) {
> +		for (slot = 0; slot < PCI_SLOT_MAX; slot++) {
> +			if (!list_empty(&vpci_dev->dev_list[slot])) {

To keep indentation reasonable (and shrink the patch size at once),
could you use

			if (list_empty(&vpci_dev->dev_list[slot]))
				continue;

here instead? Or alternatively tweak the for() above to embed the
if()'s condition there?

Jan

> +				t = list_entry(list_first(&vpci_dev->dev_list[slot]),
> +					       struct pci_dev_entry, list);
> +
> +				if (match_slot(dev, t->dev)) {
> +					pr_info(DRV_NAME ": vpci: %s: "
> +						"assign to virtual slot %d func %d\n",
> +						pci_name(dev), slot,
> +						PCI_FUNC(dev->devfn));
> +					list_add_tail(&dev_entry->list,
> +						      &vpci_dev->dev_list[slot]);
> +					func = PCI_FUNC(dev->devfn);
> +					goto unlock;
> +				}
>  			}
>  		}
>  	}
> -- 
> 1.7.1
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 07:42:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 07:42:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOOGI-0007Bq-UY; Wed, 17 Oct 2012 07:41:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOOGH-0007Bj-3I
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 07:41:53 +0000
Received: from [85.158.139.211:9795] by server-5.bemta-5.messagelabs.com id
	0E/B8-09732-0416E705; Wed, 17 Oct 2012 07:41:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1350459711!22551664!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14995 invoked from network); 17 Oct 2012 07:41:51 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-206.messagelabs.com with SMTP;
	17 Oct 2012 07:41:51 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 17 Oct 2012 08:41:52 +0100
Message-Id: <507E7D5C02000078000A1DE6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 17 Oct 2012 08:41:48 +0100
From: "Jan Beulich" 
To: "Jinsong Liu" ,
References: 
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel , ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-i386-qemuu-rhel6hvm-amd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 17.10.12 at 07:24, xen.org  wrote:
> *** Found and reproduced problem changeset ***
> 
>   Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg 
>   Bug introduced:  4fc87c2f31a0
>   Bug not present: c1c549c4fe9e
> 
> 
>   changeset:   26060:4fc87c2f31a0
>   tag:         tip
>   user:        Huang Ying 
>   date:        Tue Oct 16 17:26:36 2012 +0200
>       
>       ACPI: fix APEI related table size checking
>       
>       On Huang Ying's machine:
>       
>       erst_tab->header_length == sizeof(struct acpi_table_einj)
>       
>       but Yinghai reported that on his machine,
>       
>       erst_tab->header_length == sizeof(struct acpi_table_einj) -
>       sizeof(struct acpi_table_header)
>       
>       To make erst table size checking code works on all systems, both
>       testing are treated as PASS.
>       
>       Same situation applies to einj_tab->header_length, so corresponding
>       table size checking is changed in similar way too.
>       
>       Originally-by: Yinghai Lu 
>       Signed-off-by: Huang Ying 
>       
>       - use switch() for better readability
>       - add comment explaining why a formally invalid size it also being
>         accepted
>       - check erst_tab->header.length before even looking at
>         erst_tab->header_length
>       - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
>       
>       Signed-off-by: Jan Beulich 
>       Acked-by: Keir Fraser 
>       Committed-by: Jan Beulich 

So I just now realized that a similar change was already done
by 23736:31683aa4bfb3 and then reverted by
23760:ae10d7804168. Nothing was done subsequently to
address the actual problem(s). It is quite obvious that the more
relaxed check uncovers other bugs in the ERST code, yet looking
at the Linux history of the corresponding file doesn't reveal any
fix the lack of which would explain an outright hang (rather than
a crash, as I would expect to be the result of e.g. the missing
ioremap()-s added by 0bbba38a61283a55f2061ab3e0910c572d19f462.

Most of the other changes are cosmetic or pstore related, so I
wonder whether instead of reverting again we should try pulling
in this one extra fix.

If reverting is preferred (or turns out necessary if that second
fix doesn't help), we should settle on the disposition of the whole
APEI/ERST code, as my conclusion is that it is pretty much
unmaintained since its original contribution over two years ago.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 07:42:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 07:42:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOOGI-0007Bq-UY; Wed, 17 Oct 2012 07:41:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOOGH-0007Bj-3I
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 07:41:53 +0000
Received: from [85.158.139.211:9795] by server-5.bemta-5.messagelabs.com id
	0E/B8-09732-0416E705; Wed, 17 Oct 2012 07:41:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1350459711!22551664!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14995 invoked from network); 17 Oct 2012 07:41:51 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-206.messagelabs.com with SMTP;
	17 Oct 2012 07:41:51 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 17 Oct 2012 08:41:52 +0100
Message-Id: <507E7D5C02000078000A1DE6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 17 Oct 2012 08:41:48 +0100
From: "Jan Beulich" 
To: "Jinsong Liu" ,
References: 
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel , ian.jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-i386-qemuu-rhel6hvm-amd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 17.10.12 at 07:24, xen.org  wrote:
> *** Found and reproduced problem changeset ***
> 
>   Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg 
>   Bug introduced:  4fc87c2f31a0
>   Bug not present: c1c549c4fe9e
> 
> 
>   changeset:   26060:4fc87c2f31a0
>   tag:         tip
>   user:        Huang Ying 
>   date:        Tue Oct 16 17:26:36 2012 +0200
>       
>       ACPI: fix APEI related table size checking
>       
>       On Huang Ying's machine:
>       
>       erst_tab->header_length == sizeof(struct acpi_table_einj)
>       
>       but Yinghai reported that on his machine,
>       
>       erst_tab->header_length == sizeof(struct acpi_table_einj) -
>       sizeof(struct acpi_table_header)
>       
>       To make erst table size checking code works on all systems, both
>       testing are treated as PASS.
>       
>       Same situation applies to einj_tab->header_length, so corresponding
>       table size checking is changed in similar way too.
>       
>       Originally-by: Yinghai Lu 
>       Signed-off-by: Huang Ying 
>       
>       - use switch() for better readability
>       - add comment explaining why a formally invalid size it also being
>         accepted
>       - check erst_tab->header.length before even looking at
>         erst_tab->header_length
>       - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
>       
>       Signed-off-by: Jan Beulich 
>       Acked-by: Keir Fraser 
>       Committed-by: Jan Beulich 

So I just now realized that a similar change was already done
by 23736:31683aa4bfb3 and then reverted by
23760:ae10d7804168. Nothing was done subsequently to
address the actual problem(s). It is quite obvious that the more
relaxed check uncovers other bugs in the ERST code, yet looking
at the Linux history of the corresponding file doesn't reveal any
fix the lack of which would explain an outright hang (rather than
a crash, as I would expect to be the result of e.g. the missing
ioremap()-s added by 0bbba38a61283a55f2061ab3e0910c572d19f462.

Most of the other changes are cosmetic or pstore related, so I
wonder whether instead of reverting again we should try pulling
in this one extra fix.

If reverting is preferred (or turns out necessary if that second
fix doesn't help), we should settle on the disposition of the whole
APEI/ERST code, as my conclusion is that it is pretty much
unmaintained since its original contribution over two years ago.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 07:55:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 07:55:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOOSv-0007Rg-GK; Wed, 17 Oct 2012 07:54:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TONS2-00065l-64
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 06:49:58 +0000
Received: from [85.158.139.83:54291] by server-11.bemta-5.messagelabs.com id
	3F/F7-14870-5155E705; Wed, 17 Oct 2012 06:49:57 +0000
X-Env-Sender: ying.huang@intel.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1350456596!30914167!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjE5NTM2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23443 invoked from network); 17 Oct 2012 06:49:56 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-14.tower-182.messagelabs.com with SMTP;
	17 Oct 2012 06:49:56 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 16 Oct 2012 23:49:55 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,597,1344236400"; d="scan'208";a="205449930"
Received: from yhuang-dev.sh.intel.com (HELO [10.239.13.178]) ([10.239.13.178])
	by azsmga001.ch.intel.com with ESMTP; 16 Oct 2012 23:49:54 -0700
Message-ID: <1350456592.7098.42.camel@yhuang-dev>
From: Huang Ying 
To: Jan Beulich 
Date: Wed, 17 Oct 2012 14:49:52 +0800
In-Reply-To: <507D8F6802000078000A1B88@nat28.tlf.novell.com>
References: <507D8F6802000078000A1B88@nat28.tlf.novell.com>
X-Mailer: Evolution 3.4.3-1 
Mime-Version: 1.0
X-Mailman-Approved-At: Wed, 17 Oct 2012 07:54:57 +0000
Cc: xen-devel 
Subject: Re: [Xen-devel] [PATCH] ACPI: fix APEI related table size checking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-16 at 15:46 +0100, Jan Beulich wrote:
> On Huang Ying's machine:
> 
> erst_tab->header_length == sizeof(struct acpi_table_einj)
  ~~~~                                                ~~~~

Typo?

Best Regards,
Huang Ying

> but Yinghai reported that on his machine,
> 
> erst_tab->header_length == sizeof(struct acpi_table_einj) -
> sizeof(struct acpi_table_header)
> 
> To make erst table size checking code works on all systems, both
> testing are treated as PASS.
> 
> Same situation applies to einj_tab->header_length, so corresponding
> table size checking is changed in similar way too.
> 
> Originally-by: Yinghai Lu 
> Signed-off-by: Huang Ying 
> 
> - use switch() for better readability
> - add comment explaining why a formally invalid size it also being
>   accepted
> - check erst_tab->header.length before even looking at
>   erst_tab->header_length
> - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
> 
> Signed-off-by: Jan Beulich 
> 
> --- a/xen/drivers/acpi/apei/erst.c
> +++ b/xen/drivers/acpi/apei/erst.c
> @@ -715,12 +715,23 @@ int erst_clear(u64 record_id)
>  
>  static int __init erst_check_table(struct acpi_table_erst *erst_tab)
>  {
> -	if (erst_tab->header_length != sizeof(struct acpi_table_erst))
> +	if (erst_tab->header.length < sizeof(*erst_tab))
>  		return -EINVAL;
> -	if (erst_tab->header.length < sizeof(struct acpi_table_erst))
> +
> +	switch (erst_tab->header_length) {
> +	case sizeof(*erst_tab) - sizeof(erst_tab->header):
> +	/*
> +	 * While invalid per specification, there are (early?) systems
> +	 * indicating the full header size here, so accept that value too.
> +	 */
> +	case sizeof(*erst_tab):
> +		break;
> +	default:
>  		return -EINVAL;
> +	}
> +
>  	if (erst_tab->entries !=
> -	    (erst_tab->header.length - sizeof(struct acpi_table_erst)) /
> +	    (erst_tab->header.length - sizeof(*erst_tab)) /
>  	    sizeof(struct acpi_erst_entry))
>  		return -EINVAL;
>  
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 07:55:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 07:55:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOOSv-0007Rg-GK; Wed, 17 Oct 2012 07:54:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TONS2-00065l-64
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 06:49:58 +0000
Received: from [85.158.139.83:54291] by server-11.bemta-5.messagelabs.com id
	3F/F7-14870-5155E705; Wed, 17 Oct 2012 06:49:57 +0000
X-Env-Sender: ying.huang@intel.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1350456596!30914167!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjE5NTM2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23443 invoked from network); 17 Oct 2012 06:49:56 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-14.tower-182.messagelabs.com with SMTP;
	17 Oct 2012 06:49:56 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 16 Oct 2012 23:49:55 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,597,1344236400"; d="scan'208";a="205449930"
Received: from yhuang-dev.sh.intel.com (HELO [10.239.13.178]) ([10.239.13.178])
	by azsmga001.ch.intel.com with ESMTP; 16 Oct 2012 23:49:54 -0700
Message-ID: <1350456592.7098.42.camel@yhuang-dev>
From: Huang Ying 
To: Jan Beulich 
Date: Wed, 17 Oct 2012 14:49:52 +0800
In-Reply-To: <507D8F6802000078000A1B88@nat28.tlf.novell.com>
References: <507D8F6802000078000A1B88@nat28.tlf.novell.com>
X-Mailer: Evolution 3.4.3-1 
Mime-Version: 1.0
X-Mailman-Approved-At: Wed, 17 Oct 2012 07:54:57 +0000
Cc: xen-devel 
Subject: Re: [Xen-devel] [PATCH] ACPI: fix APEI related table size checking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-16 at 15:46 +0100, Jan Beulich wrote:
> On Huang Ying's machine:
> 
> erst_tab->header_length == sizeof(struct acpi_table_einj)
  ~~~~                                                ~~~~

Typo?

Best Regards,
Huang Ying

> but Yinghai reported that on his machine,
> 
> erst_tab->header_length == sizeof(struct acpi_table_einj) -
> sizeof(struct acpi_table_header)
> 
> To make erst table size checking code works on all systems, both
> testing are treated as PASS.
> 
> Same situation applies to einj_tab->header_length, so corresponding
> table size checking is changed in similar way too.
> 
> Originally-by: Yinghai Lu 
> Signed-off-by: Huang Ying 
> 
> - use switch() for better readability
> - add comment explaining why a formally invalid size it also being
>   accepted
> - check erst_tab->header.length before even looking at
>   erst_tab->header_length
> - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
> 
> Signed-off-by: Jan Beulich 
> 
> --- a/xen/drivers/acpi/apei/erst.c
> +++ b/xen/drivers/acpi/apei/erst.c
> @@ -715,12 +715,23 @@ int erst_clear(u64 record_id)
>  
>  static int __init erst_check_table(struct acpi_table_erst *erst_tab)
>  {
> -	if (erst_tab->header_length != sizeof(struct acpi_table_erst))
> +	if (erst_tab->header.length < sizeof(*erst_tab))
>  		return -EINVAL;
> -	if (erst_tab->header.length < sizeof(struct acpi_table_erst))
> +
> +	switch (erst_tab->header_length) {
> +	case sizeof(*erst_tab) - sizeof(erst_tab->header):
> +	/*
> +	 * While invalid per specification, there are (early?) systems
> +	 * indicating the full header size here, so accept that value too.
> +	 */
> +	case sizeof(*erst_tab):
> +		break;
> +	default:
>  		return -EINVAL;
> +	}
> +
>  	if (erst_tab->entries !=
> -	    (erst_tab->header.length - sizeof(struct acpi_table_erst)) /
> +	    (erst_tab->header.length - sizeof(*erst_tab)) /
>  	    sizeof(struct acpi_erst_entry))
>  		return -EINVAL;
>  
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 08:34:56 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 08:34:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOP5B-0008BN-8L; Wed, 17 Oct 2012 08:34:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOP5A-0008BI-8k
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 08:34:28 +0000
Received: from [85.158.139.83:30820] by server-11.bemta-5.messagelabs.com id
	DF/69-14870-39D6E705; Wed, 17 Oct 2012 08:34:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1350462866!30931915!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7573 invoked from network); 17 Oct 2012 08:34:26 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-182.messagelabs.com with SMTP;
	17 Oct 2012 08:34:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 17 Oct 2012 09:34:35 +0100
Message-Id: <507E89AF02000078000A1E10@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 17 Oct 2012 09:34:22 +0100
From: "Jan Beulich" 
To: "xen-devel" 
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartB584969E.0__="
Subject: [Xen-devel] [PATCH] x86/oprof: adjust off-by-one counter range
	checks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartB584969E.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/oprofile/xenoprof.c
+++ b/xen/arch/x86/oprofile/xenoprof.c
@@ -24,7 +24,7 @@ int xenoprof_arch_counter(XEN_GUEST_HAND
     if ( copy_from_guest(&counter, arg, 1) )
         return -EFAULT;
=20
-    if ( counter.ind > OP_MAX_COUNTER )
+    if ( counter.ind >=3D OP_MAX_COUNTER )
         return -E2BIG;
=20
     counter_config[counter.ind].count     =3D counter.count;
@@ -61,7 +61,7 @@ int compat_oprof_arch_counter(XEN_GUEST_
     if ( copy_from_guest(&counter, arg, 1) )
         return -EFAULT;
=20
-    if ( counter.ind > OP_MAX_COUNTER )
+    if ( counter.ind >=3D OP_MAX_COUNTER )
         return -E2BIG;
=20
     counter_config[counter.ind].count     =3D counter.count;




--=__PartB584969E.0__=
Content-Type: text/plain; name="x86-oprof-counter-range.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-oprof-counter-range.patch"

x86/oprof: adjust off-by-one counter range checks=0A=0ASigned-off-by: Jan =
Beulich =0A=0A--- a/xen/arch/x86/oprofile/xenoprof.c=0A+=
++ b/xen/arch/x86/oprofile/xenoprof.c=0A@@ -24,7 +24,7 @@ int xenoprof_arch=
_counter(XEN_GUEST_HAND=0A     if ( copy_from_guest(&counter, arg, 1) )=0A =
        return -EFAULT;=0A =0A-    if ( counter.ind > OP_MAX_COUNTER )=0A+ =
   if ( counter.ind >=3D OP_MAX_COUNTER )=0A         return -E2BIG;=0A =0A =
    counter_config[counter.ind].count     =3D counter.count;=0A@@ -61,7 =
+61,7 @@ int compat_oprof_arch_counter(XEN_GUEST_=0A     if ( copy_from_gue=
st(&counter, arg, 1) )=0A         return -EFAULT;=0A =0A-    if ( =
counter.ind > OP_MAX_COUNTER )=0A+    if ( counter.ind >=3D OP_MAX_COUNTER =
)=0A         return -E2BIG;=0A =0A     counter_config[counter.ind].count   =
  =3D counter.count;=0A
--=__PartB584969E.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__PartB584969E.0__=--


From xen-devel-bounces@lists.xen.org Wed Oct 17 08:34:56 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 08:34:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOP5B-0008BN-8L; Wed, 17 Oct 2012 08:34:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOP5A-0008BI-8k
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 08:34:28 +0000
Received: from [85.158.139.83:30820] by server-11.bemta-5.messagelabs.com id
	DF/69-14870-39D6E705; Wed, 17 Oct 2012 08:34:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1350462866!30931915!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7573 invoked from network); 17 Oct 2012 08:34:26 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-182.messagelabs.com with SMTP;
	17 Oct 2012 08:34:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 17 Oct 2012 09:34:35 +0100
Message-Id: <507E89AF02000078000A1E10@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 17 Oct 2012 09:34:22 +0100
From: "Jan Beulich" 
To: "xen-devel" 
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartB584969E.0__="
Subject: [Xen-devel] [PATCH] x86/oprof: adjust off-by-one counter range
	checks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartB584969E.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/oprofile/xenoprof.c
+++ b/xen/arch/x86/oprofile/xenoprof.c
@@ -24,7 +24,7 @@ int xenoprof_arch_counter(XEN_GUEST_HAND
     if ( copy_from_guest(&counter, arg, 1) )
         return -EFAULT;
=20
-    if ( counter.ind > OP_MAX_COUNTER )
+    if ( counter.ind >=3D OP_MAX_COUNTER )
         return -E2BIG;
=20
     counter_config[counter.ind].count     =3D counter.count;
@@ -61,7 +61,7 @@ int compat_oprof_arch_counter(XEN_GUEST_
     if ( copy_from_guest(&counter, arg, 1) )
         return -EFAULT;
=20
-    if ( counter.ind > OP_MAX_COUNTER )
+    if ( counter.ind >=3D OP_MAX_COUNTER )
         return -E2BIG;
=20
     counter_config[counter.ind].count     =3D counter.count;




--=__PartB584969E.0__=
Content-Type: text/plain; name="x86-oprof-counter-range.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-oprof-counter-range.patch"

x86/oprof: adjust off-by-one counter range checks=0A=0ASigned-off-by: Jan =
Beulich =0A=0A--- a/xen/arch/x86/oprofile/xenoprof.c=0A+=
++ b/xen/arch/x86/oprofile/xenoprof.c=0A@@ -24,7 +24,7 @@ int xenoprof_arch=
_counter(XEN_GUEST_HAND=0A     if ( copy_from_guest(&counter, arg, 1) )=0A =
        return -EFAULT;=0A =0A-    if ( counter.ind > OP_MAX_COUNTER )=0A+ =
   if ( counter.ind >=3D OP_MAX_COUNTER )=0A         return -E2BIG;=0A =0A =
    counter_config[counter.ind].count     =3D counter.count;=0A@@ -61,7 =
+61,7 @@ int compat_oprof_arch_counter(XEN_GUEST_=0A     if ( copy_from_gue=
st(&counter, arg, 1) )=0A         return -EFAULT;=0A =0A-    if ( =
counter.ind > OP_MAX_COUNTER )=0A+    if ( counter.ind >=3D OP_MAX_COUNTER =
)=0A         return -E2BIG;=0A =0A     counter_config[counter.ind].count   =
  =3D counter.count;=0A
--=__PartB584969E.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__PartB584969E.0__=--


From xen-devel-bounces@lists.xen.org Wed Oct 17 08:36:40 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 08:36:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOP6u-0008G8-Qj; Wed, 17 Oct 2012 08:36:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOP6s-0008Fy-Tw
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 08:36:15 +0000
Received: from [85.158.138.51:28837] by server-6.bemta-3.messagelabs.com id
	4D/6D-32375-EFD6E705; Wed, 17 Oct 2012 08:36:14 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1350462971!26587327!1
X-Originating-IP: [216.32.181.182]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5663 invoked from network); 17 Oct 2012 08:36:13 -0000
Received: from ch1ehsobe002.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.182)
	by server-3.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	17 Oct 2012 08:36:13 -0000
Received: from mail150-ch1-R.bigfish.com (10.43.68.232) by
	CH1EHSOBE010.bigfish.com (10.43.70.60) with Microsoft SMTP Server id
	14.1.225.23; Wed, 17 Oct 2012 08:36:11 +0000
Received: from mail150-ch1 (localhost [127.0.0.1])	by
	mail150-ch1-R.bigfish.com (Postfix) with ESMTP id 163483E02A1	for
	; Wed, 17 Oct 2012 08:36:11 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzc85fhc85dhzz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12bdh137ah1441h34h1155h)
Received: from mail150-ch1 (localhost.localdomain [127.0.0.1]) by mail150-ch1
	(MessageSwitch) id 1350462969474808_13288;
	Wed, 17 Oct 2012 08:36:09 +0000 (UTC)
Received: from CH1EHSMHS017.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.252])	by mail150-ch1.bigfish.com (Postfix) with ESMTP id
	722F2400042	for ;
	Wed, 17 Oct 2012 08:36:09 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS017.bigfish.com (10.43.70.17) with Microsoft SMTP Server id
	14.1.225.23; Wed, 17 Oct 2012 08:36:06 +0000
X-WSS-ID: 0MC13W1-02-41I-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2EE03C80AE	for ; Wed, 17 Oct 2012
	03:36:01 -0500 (CDT)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 17 Oct 2012 03:51:54 -0500
Received: from STOREXDAG01.amd.com (10.1.13.10) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Wed, 17 Oct 2012 03:36:04 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag01.amd.com
	(10.1.13.10) with Microsoft SMTP Server id 14.1.323.3; Wed, 17 Oct 2012
	04:36:03 -0400
Message-ID: <507E6DF1.7080506@amd.com>
Date: Wed, 17 Oct 2012 10:36:01 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" 
Content-Type: multipart/mixed; boundary="------------000306010809040908010205"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] nestedsvm: fix memory leak on shutdown/crash
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------000306010809040908010205
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit


Fix memory leak of l1 vmcb page when destroying a vcpu while
l2 guest is running.

Signed-off-by: Christoph Egger 

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------000306010809040908010205
Content-Type: text/plain; charset="us-ascii"; name="xen_nh_shutdown.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_nh_shutdown.diff"
Content-Description: xen_nh_shutdown.diff

diff -r 6b73078a4403 xen/arch/x86/hvm/svm/nestedsvm.c
--- a/xen/arch/x86/hvm/svm/nestedsvm.c	Fri Oct 12 14:38:20 2012 +0200
+++ b/xen/arch/x86/hvm/svm/nestedsvm.c	Wed Oct 17 09:08:20 2012 +0200
@@ -122,6 +122,15 @@ void nsvm_vcpu_destroy(struct vcpu *v)
     struct nestedvcpu *nv = &vcpu_nestedhvm(v);
     struct nestedsvm *svm = &vcpu_nestedsvm(v);
 
+    /*
+     * When destroying the vcpu, it may be running on behalf of l2 guest.
+     * Therefore we need to switch the VMCB pointer back to the l1 vmcb,
+     * in order to avoid double free of l2 vmcb and the possible memory leak
+     * of l1 vmcb page.
+     */
+    if (nv->nv_n1vmcx)
+        v->arch.hvm_svm.vmcb = nv->nv_n1vmcx;
+
     if (svm->ns_cached_msrpm) {
         free_xenheap_pages(svm->ns_cached_msrpm,
                            get_order_from_bytes(MSRPM_SIZE));

--------------000306010809040908010205
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------000306010809040908010205--


From xen-devel-bounces@lists.xen.org Wed Oct 17 08:36:40 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 08:36:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOP6u-0008G8-Qj; Wed, 17 Oct 2012 08:36:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOP6s-0008Fy-Tw
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 08:36:15 +0000
Received: from [85.158.138.51:28837] by server-6.bemta-3.messagelabs.com id
	4D/6D-32375-EFD6E705; Wed, 17 Oct 2012 08:36:14 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1350462971!26587327!1
X-Originating-IP: [216.32.181.182]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5663 invoked from network); 17 Oct 2012 08:36:13 -0000
Received: from ch1ehsobe002.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.182)
	by server-3.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	17 Oct 2012 08:36:13 -0000
Received: from mail150-ch1-R.bigfish.com (10.43.68.232) by
	CH1EHSOBE010.bigfish.com (10.43.70.60) with Microsoft SMTP Server id
	14.1.225.23; Wed, 17 Oct 2012 08:36:11 +0000
Received: from mail150-ch1 (localhost [127.0.0.1])	by
	mail150-ch1-R.bigfish.com (Postfix) with ESMTP id 163483E02A1	for
	; Wed, 17 Oct 2012 08:36:11 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzc85fhc85dhzz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12bdh137ah1441h34h1155h)
Received: from mail150-ch1 (localhost.localdomain [127.0.0.1]) by mail150-ch1
	(MessageSwitch) id 1350462969474808_13288;
	Wed, 17 Oct 2012 08:36:09 +0000 (UTC)
Received: from CH1EHSMHS017.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.252])	by mail150-ch1.bigfish.com (Postfix) with ESMTP id
	722F2400042	for ;
	Wed, 17 Oct 2012 08:36:09 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS017.bigfish.com (10.43.70.17) with Microsoft SMTP Server id
	14.1.225.23; Wed, 17 Oct 2012 08:36:06 +0000
X-WSS-ID: 0MC13W1-02-41I-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2EE03C80AE	for ; Wed, 17 Oct 2012
	03:36:01 -0500 (CDT)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 17 Oct 2012 03:51:54 -0500
Received: from STOREXDAG01.amd.com (10.1.13.10) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Wed, 17 Oct 2012 03:36:04 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag01.amd.com
	(10.1.13.10) with Microsoft SMTP Server id 14.1.323.3; Wed, 17 Oct 2012
	04:36:03 -0400
Message-ID: <507E6DF1.7080506@amd.com>
Date: Wed, 17 Oct 2012 10:36:01 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" 
Content-Type: multipart/mixed; boundary="------------000306010809040908010205"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] nestedsvm: fix memory leak on shutdown/crash
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------000306010809040908010205
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit


Fix memory leak of l1 vmcb page when destroying a vcpu while
l2 guest is running.

Signed-off-by: Christoph Egger 

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------000306010809040908010205
Content-Type: text/plain; charset="us-ascii"; name="xen_nh_shutdown.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_nh_shutdown.diff"
Content-Description: xen_nh_shutdown.diff

diff -r 6b73078a4403 xen/arch/x86/hvm/svm/nestedsvm.c
--- a/xen/arch/x86/hvm/svm/nestedsvm.c	Fri Oct 12 14:38:20 2012 +0200
+++ b/xen/arch/x86/hvm/svm/nestedsvm.c	Wed Oct 17 09:08:20 2012 +0200
@@ -122,6 +122,15 @@ void nsvm_vcpu_destroy(struct vcpu *v)
     struct nestedvcpu *nv = &vcpu_nestedhvm(v);
     struct nestedsvm *svm = &vcpu_nestedsvm(v);
 
+    /*
+     * When destroying the vcpu, it may be running on behalf of l2 guest.
+     * Therefore we need to switch the VMCB pointer back to the l1 vmcb,
+     * in order to avoid double free of l2 vmcb and the possible memory leak
+     * of l1 vmcb page.
+     */
+    if (nv->nv_n1vmcx)
+        v->arch.hvm_svm.vmcb = nv->nv_n1vmcx;
+
     if (svm->ns_cached_msrpm) {
         free_xenheap_pages(svm->ns_cached_msrpm,
                            get_order_from_bytes(MSRPM_SIZE));

--------------000306010809040908010205
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------000306010809040908010205--


From xen-devel-bounces@lists.xen.org Wed Oct 17 08:39:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 08:39:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOP9a-0008Pu-OK; Wed, 17 Oct 2012 08:39:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOP9Z-0008Pm-Gn
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 08:39:01 +0000
Received: from [85.158.143.99:56538] by server-2.bemta-4.messagelabs.com id
	DC/C1-22268-4AE6E705; Wed, 17 Oct 2012 08:39:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1350463140!23191067!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ1MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24526 invoked from network); 17 Oct 2012 08:39:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 08:39:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,599,1344211200"; d="scan'208";a="15218942"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 08:38:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 09:38:59 +0100
Message-ID: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 17 Oct 2012 09:38:58 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	linux-kernel ,
	xen-devel 
Subject: [Xen-devel] [PATCH 00/10] xen: build fixes and interface tweaks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The following is based on v3.7-rc1 and fixes various build fallout which
I discovered when build for Xen on ARM.

It also cleans up a final few s/unsigned long/xen_{pfn,ulong}_t/
changes. These have no impact on x86 (since those types are typedefs of
unsigned long) but change the ARM port to use the interface we have
settled on and which I shall be committing to the h/v shortly.

I've sent a few of these out individually as I've gone along too, but
they are mostly independent so I figure there's no harm in resending.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 08:39:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 08:39:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOP9a-0008Pu-OK; Wed, 17 Oct 2012 08:39:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOP9Z-0008Pm-Gn
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 08:39:01 +0000
Received: from [85.158.143.99:56538] by server-2.bemta-4.messagelabs.com id
	DC/C1-22268-4AE6E705; Wed, 17 Oct 2012 08:39:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1350463140!23191067!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ1MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24526 invoked from network); 17 Oct 2012 08:39:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 08:39:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,599,1344211200"; d="scan'208";a="15218942"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 08:38:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 09:38:59 +0100
Message-ID: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 17 Oct 2012 09:38:58 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	linux-kernel ,
	xen-devel 
Subject: [Xen-devel] [PATCH 00/10] xen: build fixes and interface tweaks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The following is based on v3.7-rc1 and fixes various build fallout which
I discovered when build for Xen on ARM.

It also cleans up a final few s/unsigned long/xen_{pfn,ulong}_t/
changes. These have no impact on x86 (since those types are typedefs of
unsigned long) but change the ARM port to use the interface we have
settled on and which I shall be committing to the h/v shortly.

I've sent a few of these out individually as I've gone along too, but
they are mostly independent so I figure there's no harm in resending.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 08:39:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 08:39:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOP9v-0008S5-6K; Wed, 17 Oct 2012 08:39:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOP9t-0008Rf-RM
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 08:39:21 +0000
Received: from [85.158.143.99:23517] by server-1.bemta-4.messagelabs.com id
	BB/CD-19134-9BE6E705; Wed, 17 Oct 2012 08:39:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1350463159!34470657!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODI4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2039 invoked from network); 17 Oct 2012 08:39:20 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 08:39:20 -0000
X-IronPort-AV: E=Sophos;i="4.80,599,1344211200"; d="scan'208";a="211526017"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 08:39:18 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 04:39:18 -0400
Received: from drall.uk.xensource.com ([10.80.227.107])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TOP9q-0003fa-4A;
	Wed, 17 Oct 2012 09:39:18 +0100
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 17 Oct 2012 09:39:09 +0100
Message-ID: <1350463157-5068-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	Ian Campbell , xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 02/10] xen: sysfs: include err.h for PTR_ERR etc
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Fixes build error on ARM:
drivers/xen/sys-hypervisor.c: In function 'uuid_show_fallback':
drivers/xen/sys-hypervisor.c:127:2: error: implicit declaration of function 'IS_ERR' [-Werror=implicit-function-declaration]
drivers/xen/sys-hypervisor.c:128:3: error: implicit declaration of function 'PTR_ERR' [-Werror=implicit-function-declaration]

Signed-off-by: Ian Campbell 
---
 drivers/xen/sys-hypervisor.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c
index 5e5ad7e..66a0a14 100644
--- a/drivers/xen/sys-hypervisor.c
+++ b/drivers/xen/sys-hypervisor.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 08:39:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 08:39:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOP9v-0008S5-6K; Wed, 17 Oct 2012 08:39:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOP9t-0008Rf-RM
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 08:39:21 +0000
Received: from [85.158.143.99:23517] by server-1.bemta-4.messagelabs.com id
	BB/CD-19134-9BE6E705; Wed, 17 Oct 2012 08:39:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1350463159!34470657!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODI4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2039 invoked from network); 17 Oct 2012 08:39:20 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 08:39:20 -0000
X-IronPort-AV: E=Sophos;i="4.80,599,1344211200"; d="scan'208";a="211526017"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 08:39:18 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 04:39:18 -0400
Received: from drall.uk.xensource.com ([10.80.227.107])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TOP9q-0003fa-4A;
	Wed, 17 Oct 2012 09:39:18 +0100
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 17 Oct 2012 09:39:09 +0100
Message-ID: <1350463157-5068-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	Ian Campbell , xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 02/10] xen: sysfs: include err.h for PTR_ERR etc
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Fixes build error on ARM:
drivers/xen/sys-hypervisor.c: In function 'uuid_show_fallback':
drivers/xen/sys-hypervisor.c:127:2: error: implicit declaration of function 'IS_ERR' [-Werror=implicit-function-declaration]
drivers/xen/sys-hypervisor.c:128:3: error: implicit declaration of function 'PTR_ERR' [-Werror=implicit-function-declaration]

Signed-off-by: Ian Campbell 
---
 drivers/xen/sys-hypervisor.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c
index 5e5ad7e..66a0a14 100644
--- a/drivers/xen/sys-hypervisor.c
+++ b/drivers/xen/sys-hypervisor.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 08:39:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 08:39:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOP9y-0008UO-QQ; Wed, 17 Oct 2012 08:39:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOP9x-0008Sn-4q
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 08:39:25 +0000
Received: from [85.158.139.211:38902] by server-10.bemta-5.messagelabs.com id
	AA/DD-01025-CBE6E705; Wed, 17 Oct 2012 08:39:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1350463162!22168947!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODI4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4417 invoked from network); 17 Oct 2012 08:39:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 08:39:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,599,1344211200"; d="scan'208";a="211526025"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 08:39:19 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 04:39:18 -0400
Received: from drall.uk.xensource.com ([10.80.227.107])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TOP9q-0003fa-Cg;
	Wed, 17 Oct 2012 09:39:18 +0100
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 17 Oct 2012 09:39:16 +0100
Message-ID: <1350463157-5068-9-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	Ian Campbell , xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 09/10] xen: balloon: use correct type for
	frame_list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is now a xen_pfn_t.

Signed-off-by: Ian Campbell 
---
 drivers/xen/balloon.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index d7bd1b3..d6886d9 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -87,7 +87,7 @@ struct balloon_stats balloon_stats;
 EXPORT_SYMBOL_GPL(balloon_stats);
 
 /* We increase/decrease in batches which fit in a page */
-static unsigned long frame_list[PAGE_SIZE / sizeof(unsigned long)];
+static xen_pfn_t frame_list[PAGE_SIZE / sizeof(unsigned long)];
 
 #ifdef CONFIG_HIGHMEM
 #define inc_totalhigh_pages() (totalhigh_pages++)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 08:39:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 08:39:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOP9y-0008UO-QQ; Wed, 17 Oct 2012 08:39:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOP9x-0008Sn-4q
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 08:39:25 +0000
Received: from [85.158.139.211:38902] by server-10.bemta-5.messagelabs.com id
	AA/DD-01025-CBE6E705; Wed, 17 Oct 2012 08:39:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1350463162!22168947!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODI4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4417 invoked from network); 17 Oct 2012 08:39:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 08:39:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,599,1344211200"; d="scan'208";a="211526025"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 08:39:19 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 04:39:18 -0400
Received: from drall.uk.xensource.com ([10.80.227.107])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TOP9q-0003fa-Cg;
	Wed, 17 Oct 2012 09:39:18 +0100
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 17 Oct 2012 09:39:16 +0100
Message-ID: <1350463157-5068-9-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	Ian Campbell , xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 09/10] xen: balloon: use correct type for
	frame_list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is now a xen_pfn_t.

Signed-off-by: Ian Campbell 
---
 drivers/xen/balloon.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index d7bd1b3..d6886d9 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -87,7 +87,7 @@ struct balloon_stats balloon_stats;
 EXPORT_SYMBOL_GPL(balloon_stats);
 
 /* We increase/decrease in batches which fit in a page */
-static unsigned long frame_list[PAGE_SIZE / sizeof(unsigned long)];
+static xen_pfn_t frame_list[PAGE_SIZE / sizeof(unsigned long)];
 
 #ifdef CONFIG_HIGHMEM
 #define inc_totalhigh_pages() (totalhigh_pages++)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 08:39:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 08:39:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOP9y-0008U0-EF; Wed, 17 Oct 2012 08:39:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOP9w-0008Sg-VM
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 08:39:25 +0000
Received: from [85.158.138.51:20684] by server-2.bemta-3.messagelabs.com id
	4F/ED-00604-CBE6E705; Wed, 17 Oct 2012 08:39:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1350463161!15978258!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODI4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3343 invoked from network); 17 Oct 2012 08:39:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 08:39:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,599,1344211200"; d="scan'208";a="211526023"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 08:39:19 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 04:39:18 -0400
Received: from drall.uk.xensource.com ([10.80.227.107])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TOP9q-0003fa-6N;
	Wed, 17 Oct 2012 09:39:18 +0100
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 17 Oct 2012 09:39:11 +0100
Message-ID: <1350463157-5068-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	Ian Campbell ,
	Jan Beulich , xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 04/10] xen: dbgp: Fix warning when CONFIG_PCI is
	not enabled.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I saw this on ARM:
linux/drivers/xen/dbgp.c:11:23: warning: unused variable 'ctrlr' [-Wunused-variable]

Signed-off-by: Ian Campbell 
Cc: Jan Beulich 
---
 drivers/xen/dbgp.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/dbgp.c b/drivers/xen/dbgp.c
index 42569c7..f3ccc80 100644
--- a/drivers/xen/dbgp.c
+++ b/drivers/xen/dbgp.c
@@ -8,7 +8,9 @@
 
 static int xen_dbgp_op(struct usb_hcd *hcd, int op)
 {
+#ifdef CONFIG_PCI
 	const struct device *ctrlr = hcd_to_bus(hcd)->controller;
+#endif
 	struct physdev_dbgp_op dbgp;
 
 	if (!xen_initial_domain())
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 08:39:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 08:39:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOP9y-0008U0-EF; Wed, 17 Oct 2012 08:39:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOP9w-0008Sg-VM
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 08:39:25 +0000
Received: from [85.158.138.51:20684] by server-2.bemta-3.messagelabs.com id
	4F/ED-00604-CBE6E705; Wed, 17 Oct 2012 08:39:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1350463161!15978258!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODI4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3343 invoked from network); 17 Oct 2012 08:39:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 08:39:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,599,1344211200"; d="scan'208";a="211526023"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 08:39:19 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 04:39:18 -0400
Received: from drall.uk.xensource.com ([10.80.227.107])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TOP9q-0003fa-6N;
	Wed, 17 Oct 2012 09:39:18 +0100
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 17 Oct 2012 09:39:11 +0100
Message-ID: <1350463157-5068-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	Ian Campbell ,
	Jan Beulich , xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 04/10] xen: dbgp: Fix warning when CONFIG_PCI is
	not enabled.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I saw this on ARM:
linux/drivers/xen/dbgp.c:11:23: warning: unused variable 'ctrlr' [-Wunused-variable]

Signed-off-by: Ian Campbell 
Cc: Jan Beulich 
---
 drivers/xen/dbgp.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/dbgp.c b/drivers/xen/dbgp.c
index 42569c7..f3ccc80 100644
--- a/drivers/xen/dbgp.c
+++ b/drivers/xen/dbgp.c
@@ -8,7 +8,9 @@
 
 static int xen_dbgp_op(struct usb_hcd *hcd, int op)
 {
+#ifdef CONFIG_PCI
 	const struct device *ctrlr = hcd_to_bus(hcd)->controller;
+#endif
 	struct physdev_dbgp_op dbgp;
 
 	if (!xen_initial_domain())
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 08:39:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 08:39:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOP9w-0008Sh-JX; Wed, 17 Oct 2012 08:39:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOP9u-0008Rj-Ds
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 08:39:22 +0000
Received: from [85.158.143.99:61858] by server-3.bemta-4.messagelabs.com id
	E2/F5-03544-9BE6E705; Wed, 17 Oct 2012 08:39:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1350463159!34470657!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODI4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2050 invoked from network); 17 Oct 2012 08:39:21 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 08:39:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,599,1344211200"; d="scan'208";a="211526018"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 08:39:18 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 04:39:18 -0400
Received: from drall.uk.xensource.com ([10.80.227.107])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TOP9q-0003fa-3Z;
	Wed, 17 Oct 2012 09:39:18 +0100
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 17 Oct 2012 09:39:08 +0100
Message-ID: <1350463157-5068-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	Ian Campbell , xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 01/10] xen: xenbus: quirk uses x86 specific cpuid
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This breaks on ARM. This quirk is not necessary on ARM because no
hypervisors of that vintage exist for that architecture (port is too
new).

Signed-off-by: Ian Campbell 
---
 drivers/xen/xenbus/xenbus_xs.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
index 48220e1..b46ad11 100644
--- a/drivers/xen/xenbus/xenbus_xs.c
+++ b/drivers/xen/xenbus/xenbus_xs.c
@@ -619,6 +619,8 @@ static struct xenbus_watch *find_watch(const char *token)
 
 	return NULL;
 }
+
+#ifdef CONFIG_X86
 /*
  * Certain older XenBus toolstack cannot handle reading values that are
  * not populated. Some Xen 3.4 installation are incapable of doing this
@@ -637,6 +639,10 @@ static bool xen_strict_xenbus_quirk()
 	return false;
 
 }
+#else
+static bool xen_strict_xenbus_quirk(void) { return false; }
+#endif
+
 static void xs_reset_watches(void)
 {
 	int err, supported = 0;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 08:39:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 08:39:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOP9z-0008Uf-68; Wed, 17 Oct 2012 08:39:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOP9x-0008T2-K6
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 08:39:25 +0000
Received: from [85.158.138.51:53568] by server-4.bemta-3.messagelabs.com id
	3C/44-01405-CBE6E705; Wed, 17 Oct 2012 08:39:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1350463161!15978258!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODI4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3366 invoked from network); 17 Oct 2012 08:39:24 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 08:39:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,599,1344211200"; d="scan'208";a="211526026"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 08:39:19 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 04:39:18 -0400
Received: from drall.uk.xensource.com ([10.80.227.107])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TOP9q-0003fa-EJ;
	Wed, 17 Oct 2012 09:39:18 +0100
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 17 Oct 2012 09:39:17 +0100
Message-ID: <1350463157-5068-10-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	Ian Campbell , xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 10/10] xen: arm: make p2m operations NOPs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This makes common code less ifdef-y and is consistent with PVHVM on
x86.

Also note that phys_to_machine_mapping_valid should take a pfn
argument and make it do so.

Add __set_phys_to_machine, make set_phys_to_machine a simple wrapper
(on systems with non-nop implementations the outer one can allocate
new p2m pages).

Make __set_phys_to_machine check for identity mapping or invalid only.

Signed-off-by: Ian Campbell 
---
 arch/arm/include/asm/xen/page.h |   13 ++++++++++---
 1 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
index 1742023..c6b9096 100644
--- a/arch/arm/include/asm/xen/page.h
+++ b/arch/arm/include/asm/xen/page.h
@@ -10,7 +10,7 @@
 #include 
 
 #define pfn_to_mfn(pfn)			(pfn)
-#define phys_to_machine_mapping_valid	(1)
+#define phys_to_machine_mapping_valid(pfn) (1)
 #define mfn_to_pfn(mfn)			(mfn)
 #define mfn_to_virt(m)			(__va(mfn_to_pfn(m) << PAGE_SHIFT))
 
@@ -30,6 +30,8 @@ typedef struct xpaddr {
 #define XMADDR(x)	((xmaddr_t) { .maddr = (x) })
 #define XPADDR(x)	((xpaddr_t) { .paddr = (x) })
 
+#define INVALID_P2M_ENTRY      (~0UL)
+
 static inline xmaddr_t phys_to_machine(xpaddr_t phys)
 {
 	unsigned offset = phys.paddr & ~PAGE_MASK;
@@ -74,9 +76,14 @@ static inline int m2p_remove_override(struct page *page, bool clear_pte)
 	return 0;
 }
 
+static inline bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
+{
+	BUG_ON(pfn != mfn && mfn != INVALID_P2M_ENTRY);
+	return true;
+}
+
 static inline bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 {
-	BUG();
-	return false;
+	return __set_phys_to_machine(pfn, mfn);
 }
 #endif /* _ASM_ARM_XEN_PAGE_H */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 08:39:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 08:39:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOP9x-0008TX-RT; Wed, 17 Oct 2012 08:39:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOP9w-0008SM-EP
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 08:39:24 +0000
Received: from [85.158.138.51:20641] by server-10.bemta-3.messagelabs.com id
	FA/A5-27386-BBE6E705; Wed, 17 Oct 2012 08:39:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1350463161!15978258!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODI4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3308 invoked from network); 17 Oct 2012 08:39:22 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 08:39:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,599,1344211200"; d="scan'208";a="211526021"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 08:39:18 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 04:39:18 -0400
Received: from drall.uk.xensource.com ([10.80.227.107])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TOP9q-0003fa-8i;
	Wed, 17 Oct 2012 09:39:18 +0100
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 17 Oct 2012 09:39:13 +0100
Message-ID: <1350463157-5068-6-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	Ian Campbell , xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 06/10] xen: XENMEM_translate_gpfn_list was
	remove ages ago and is unused.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Campbell 
---
 include/xen/interface/memory.h |   24 ++----------------------
 1 files changed, 2 insertions(+), 22 deletions(-)

diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index b66d04c..90712e2 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -179,28 +179,8 @@ struct xen_add_to_physmap {
 };
 DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_physmap);
 
-/*
- * Translates a list of domain-specific GPFNs into MFNs. Returns a -ve error
- * code on failure. This call only works for auto-translated guests.
- */
-#define XENMEM_translate_gpfn_list  8
-struct xen_translate_gpfn_list {
-    /* Which domain to translate for? */
-    domid_t domid;
-
-    /* Length of list. */
-    xen_ulong_t nr_gpfns;
-
-    /* List of GPFNs to translate. */
-    GUEST_HANDLE(ulong) gpfn_list;
-
-    /*
-     * Output list to contain MFN translations. May be the same as the input
-     * list (in which case each input GPFN is overwritten with the output MFN).
-     */
-    GUEST_HANDLE(ulong) mfn_list;
-};
-DEFINE_GUEST_HANDLE_STRUCT(xen_translate_gpfn_list);
+/*** REMOVED ***/
+/*#define XENMEM_translate_gpfn_list  8*/
 
 /*
  * Returns the pseudo-physical memory map as it was when the domain
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 08:39:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 08:39:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOP9w-0008Sw-Vs; Wed, 17 Oct 2012 08:39:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOP9u-0008Rj-T7
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 08:39:23 +0000
Received: from [85.158.143.99:61895] by server-3.bemta-4.messagelabs.com id
	08/F5-03544-ABE6E705; Wed, 17 Oct 2012 08:39:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1350463159!34470657!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODI4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2068 invoked from network); 17 Oct 2012 08:39:21 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 08:39:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,599,1344211200"; d="scan'208";a="211526019"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 08:39:18 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 04:39:18 -0400
Received: from drall.uk.xensource.com ([10.80.227.107])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TOP9q-0003fa-4d;
	Wed, 17 Oct 2012 09:39:18 +0100
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 17 Oct 2012 09:39:10 +0100
Message-ID: <1350463157-5068-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	Ian Campbell , xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 03/10] xen: sysfs: fix build warning.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Define PRI macros for xen_ulong_t and xen_pfn_t and use to fix:
drivers/xen/sys-hypervisor.c:288:4: warning: format '%lx' expects argument of type 'long unsigned int', but argument 3 has type 'xen_ulong_t' [-Wformat]

Ideally this would use PRIx64 on ARM but these (or equivalent) don't
seem to be available in the kernel.

Signed-off-by: Ian Campbell 
---
 arch/arm/include/asm/xen/interface.h |    2 ++
 arch/x86/include/asm/xen/interface.h |    2 ++
 drivers/xen/sys-hypervisor.c         |    3 ++-
 3 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
index ae05e56..62160f2 100644
--- a/arch/arm/include/asm/xen/interface.h
+++ b/arch/arm/include/asm/xen/interface.h
@@ -31,7 +31,9 @@
 /* Explicitly size integers that represent pfns in the interface with
  * Xen so that we can have one ABI that works for 32 and 64 bit guests. */
 typedef uint64_t xen_pfn_t;
+#define PRI_xen_pfn "llx"
 typedef uint64_t xen_ulong_t;
+#define PRI_xen_ulong "llx"
 /* Guest handles for primitive C types. */
 __DEFINE_GUEST_HANDLE(uchar, unsigned char);
 __DEFINE_GUEST_HANDLE(uint,  unsigned int);
diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
index 6d2f75a..ab3c67c 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -51,7 +51,9 @@
  * with Xen so that on ARM we can have one ABI that works for 32 and 64
  * bit guests. */
 typedef unsigned long xen_pfn_t;
+#define PRI_xen_pfn "lx"
 typedef unsigned long xen_ulong_t;
+#define PRI_xen_ulong "lx"
 /* Guest handles for primitive C types. */
 __DEFINE_GUEST_HANDLE(uchar, unsigned char);
 __DEFINE_GUEST_HANDLE(uint,  unsigned int);
diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c
index 66a0a14..96453f8 100644
--- a/drivers/xen/sys-hypervisor.c
+++ b/drivers/xen/sys-hypervisor.c
@@ -285,7 +285,8 @@ static ssize_t virtual_start_show(struct hyp_sysfs_attr *attr, char *buffer)
 		ret = HYPERVISOR_xen_version(XENVER_platform_parameters,
 					     parms);
 		if (!ret)
-			ret = sprintf(buffer, "%lx\n", parms->virt_start);
+			ret = sprintf(buffer, "%"PRI_xen_ulong"\n",
+				      parms->virt_start);
 		kfree(parms);
 	}
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 08:39:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 08:39:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOP9x-0008TG-ED; Wed, 17 Oct 2012 08:39:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOP9v-0008Rj-Bb
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 08:39:23 +0000
Received: from [85.158.143.99:23604] by server-3.bemta-4.messagelabs.com id
	7D/F5-03544-BBE6E705; Wed, 17 Oct 2012 08:39:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1350463159!34470657!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODI4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2089 invoked from network); 17 Oct 2012 08:39:22 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 08:39:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,599,1344211200"; d="scan'208";a="211526020"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 08:39:18 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 04:39:18 -0400
Received: from drall.uk.xensource.com ([10.80.227.107])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TOP9q-0003fa-8C;
	Wed, 17 Oct 2012 09:39:18 +0100
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 17 Oct 2012 09:39:12 +0100
Message-ID: <1350463157-5068-5-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	Stefano Stabellini ,
	Ian Campbell , xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 05/10] xen: events: pirq_check_eoi_map is X86
	specific
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On ARM I see:
drivers/xen/events.c:280:13: warning: 'pirq_check_eoi_map' defined but not used
[-Wunused-function]

Signed-off-by: Ian Campbell 
Cc: Stefano Stabellini 
---
 drivers/xen/events.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 59e10a1..912ac81 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -115,7 +115,9 @@ struct irq_info {
 #define PIRQ_SHAREABLE	(1 << 1)
 
 static int *evtchn_to_irq;
+#ifdef CONFIG_X86
 static unsigned long *pirq_eoi_map;
+#endif
 static bool (*pirq_needs_eoi)(unsigned irq);
 
 static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
@@ -277,10 +279,12 @@ static unsigned int cpu_from_evtchn(unsigned int evtchn)
 	return ret;
 }
 
+#ifdef CONFIG_X86
 static bool pirq_check_eoi_map(unsigned irq)
 {
 	return test_bit(pirq_from_irq(irq), pirq_eoi_map);
 }
+#endif
 
 static bool pirq_needs_eoi_flag(unsigned irq)
 {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 08:39:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 08:39:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOP9z-0008Uf-68; Wed, 17 Oct 2012 08:39:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOP9x-0008T2-K6
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 08:39:25 +0000
Received: from [85.158.138.51:53568] by server-4.bemta-3.messagelabs.com id
	3C/44-01405-CBE6E705; Wed, 17 Oct 2012 08:39:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1350463161!15978258!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODI4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3366 invoked from network); 17 Oct 2012 08:39:24 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 08:39:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,599,1344211200"; d="scan'208";a="211526026"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 08:39:19 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 04:39:18 -0400
Received: from drall.uk.xensource.com ([10.80.227.107])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TOP9q-0003fa-EJ;
	Wed, 17 Oct 2012 09:39:18 +0100
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 17 Oct 2012 09:39:17 +0100
Message-ID: <1350463157-5068-10-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	Ian Campbell , xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 10/10] xen: arm: make p2m operations NOPs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This makes common code less ifdef-y and is consistent with PVHVM on
x86.

Also note that phys_to_machine_mapping_valid should take a pfn
argument and make it do so.

Add __set_phys_to_machine, make set_phys_to_machine a simple wrapper
(on systems with non-nop implementations the outer one can allocate
new p2m pages).

Make __set_phys_to_machine check for identity mapping or invalid only.

Signed-off-by: Ian Campbell 
---
 arch/arm/include/asm/xen/page.h |   13 ++++++++++---
 1 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
index 1742023..c6b9096 100644
--- a/arch/arm/include/asm/xen/page.h
+++ b/arch/arm/include/asm/xen/page.h
@@ -10,7 +10,7 @@
 #include 
 
 #define pfn_to_mfn(pfn)			(pfn)
-#define phys_to_machine_mapping_valid	(1)
+#define phys_to_machine_mapping_valid(pfn) (1)
 #define mfn_to_pfn(mfn)			(mfn)
 #define mfn_to_virt(m)			(__va(mfn_to_pfn(m) << PAGE_SHIFT))
 
@@ -30,6 +30,8 @@ typedef struct xpaddr {
 #define XMADDR(x)	((xmaddr_t) { .maddr = (x) })
 #define XPADDR(x)	((xpaddr_t) { .paddr = (x) })
 
+#define INVALID_P2M_ENTRY      (~0UL)
+
 static inline xmaddr_t phys_to_machine(xpaddr_t phys)
 {
 	unsigned offset = phys.paddr & ~PAGE_MASK;
@@ -74,9 +76,14 @@ static inline int m2p_remove_override(struct page *page, bool clear_pte)
 	return 0;
 }
 
+static inline bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
+{
+	BUG_ON(pfn != mfn && mfn != INVALID_P2M_ENTRY);
+	return true;
+}
+
 static inline bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 {
-	BUG();
-	return false;
+	return __set_phys_to_machine(pfn, mfn);
 }
 #endif /* _ASM_ARM_XEN_PAGE_H */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 08:39:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 08:39:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOP9w-0008Sh-JX; Wed, 17 Oct 2012 08:39:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOP9u-0008Rj-Ds
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 08:39:22 +0000
Received: from [85.158.143.99:61858] by server-3.bemta-4.messagelabs.com id
	E2/F5-03544-9BE6E705; Wed, 17 Oct 2012 08:39:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1350463159!34470657!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODI4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2050 invoked from network); 17 Oct 2012 08:39:21 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 08:39:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,599,1344211200"; d="scan'208";a="211526018"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 08:39:18 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 04:39:18 -0400
Received: from drall.uk.xensource.com ([10.80.227.107])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TOP9q-0003fa-3Z;
	Wed, 17 Oct 2012 09:39:18 +0100
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 17 Oct 2012 09:39:08 +0100
Message-ID: <1350463157-5068-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	Ian Campbell , xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 01/10] xen: xenbus: quirk uses x86 specific cpuid
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This breaks on ARM. This quirk is not necessary on ARM because no
hypervisors of that vintage exist for that architecture (port is too
new).

Signed-off-by: Ian Campbell 
---
 drivers/xen/xenbus/xenbus_xs.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
index 48220e1..b46ad11 100644
--- a/drivers/xen/xenbus/xenbus_xs.c
+++ b/drivers/xen/xenbus/xenbus_xs.c
@@ -619,6 +619,8 @@ static struct xenbus_watch *find_watch(const char *token)
 
 	return NULL;
 }
+
+#ifdef CONFIG_X86
 /*
  * Certain older XenBus toolstack cannot handle reading values that are
  * not populated. Some Xen 3.4 installation are incapable of doing this
@@ -637,6 +639,10 @@ static bool xen_strict_xenbus_quirk()
 	return false;
 
 }
+#else
+static bool xen_strict_xenbus_quirk(void) { return false; }
+#endif
+
 static void xs_reset_watches(void)
 {
 	int err, supported = 0;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 08:39:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 08:39:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOP9w-0008Sw-Vs; Wed, 17 Oct 2012 08:39:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOP9u-0008Rj-T7
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 08:39:23 +0000
Received: from [85.158.143.99:61895] by server-3.bemta-4.messagelabs.com id
	08/F5-03544-ABE6E705; Wed, 17 Oct 2012 08:39:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1350463159!34470657!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODI4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2068 invoked from network); 17 Oct 2012 08:39:21 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 08:39:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,599,1344211200"; d="scan'208";a="211526019"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 08:39:18 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 04:39:18 -0400
Received: from drall.uk.xensource.com ([10.80.227.107])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TOP9q-0003fa-4d;
	Wed, 17 Oct 2012 09:39:18 +0100
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 17 Oct 2012 09:39:10 +0100
Message-ID: <1350463157-5068-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	Ian Campbell , xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 03/10] xen: sysfs: fix build warning.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Define PRI macros for xen_ulong_t and xen_pfn_t and use to fix:
drivers/xen/sys-hypervisor.c:288:4: warning: format '%lx' expects argument of type 'long unsigned int', but argument 3 has type 'xen_ulong_t' [-Wformat]

Ideally this would use PRIx64 on ARM but these (or equivalent) don't
seem to be available in the kernel.

Signed-off-by: Ian Campbell 
---
 arch/arm/include/asm/xen/interface.h |    2 ++
 arch/x86/include/asm/xen/interface.h |    2 ++
 drivers/xen/sys-hypervisor.c         |    3 ++-
 3 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
index ae05e56..62160f2 100644
--- a/arch/arm/include/asm/xen/interface.h
+++ b/arch/arm/include/asm/xen/interface.h
@@ -31,7 +31,9 @@
 /* Explicitly size integers that represent pfns in the interface with
  * Xen so that we can have one ABI that works for 32 and 64 bit guests. */
 typedef uint64_t xen_pfn_t;
+#define PRI_xen_pfn "llx"
 typedef uint64_t xen_ulong_t;
+#define PRI_xen_ulong "llx"
 /* Guest handles for primitive C types. */
 __DEFINE_GUEST_HANDLE(uchar, unsigned char);
 __DEFINE_GUEST_HANDLE(uint,  unsigned int);
diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
index 6d2f75a..ab3c67c 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -51,7 +51,9 @@
  * with Xen so that on ARM we can have one ABI that works for 32 and 64
  * bit guests. */
 typedef unsigned long xen_pfn_t;
+#define PRI_xen_pfn "lx"
 typedef unsigned long xen_ulong_t;
+#define PRI_xen_ulong "lx"
 /* Guest handles for primitive C types. */
 __DEFINE_GUEST_HANDLE(uchar, unsigned char);
 __DEFINE_GUEST_HANDLE(uint,  unsigned int);
diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c
index 66a0a14..96453f8 100644
--- a/drivers/xen/sys-hypervisor.c
+++ b/drivers/xen/sys-hypervisor.c
@@ -285,7 +285,8 @@ static ssize_t virtual_start_show(struct hyp_sysfs_attr *attr, char *buffer)
 		ret = HYPERVISOR_xen_version(XENVER_platform_parameters,
 					     parms);
 		if (!ret)
-			ret = sprintf(buffer, "%lx\n", parms->virt_start);
+			ret = sprintf(buffer, "%"PRI_xen_ulong"\n",
+				      parms->virt_start);
 		kfree(parms);
 	}
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 08:39:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 08:39:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOP9x-0008TX-RT; Wed, 17 Oct 2012 08:39:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOP9w-0008SM-EP
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 08:39:24 +0000
Received: from [85.158.138.51:20641] by server-10.bemta-3.messagelabs.com id
	FA/A5-27386-BBE6E705; Wed, 17 Oct 2012 08:39:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1350463161!15978258!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODI4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3308 invoked from network); 17 Oct 2012 08:39:22 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 08:39:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,599,1344211200"; d="scan'208";a="211526021"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 08:39:18 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 04:39:18 -0400
Received: from drall.uk.xensource.com ([10.80.227.107])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TOP9q-0003fa-8i;
	Wed, 17 Oct 2012 09:39:18 +0100
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 17 Oct 2012 09:39:13 +0100
Message-ID: <1350463157-5068-6-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	Ian Campbell , xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 06/10] xen: XENMEM_translate_gpfn_list was
	remove ages ago and is unused.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Campbell 
---
 include/xen/interface/memory.h |   24 ++----------------------
 1 files changed, 2 insertions(+), 22 deletions(-)

diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index b66d04c..90712e2 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -179,28 +179,8 @@ struct xen_add_to_physmap {
 };
 DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_physmap);
 
-/*
- * Translates a list of domain-specific GPFNs into MFNs. Returns a -ve error
- * code on failure. This call only works for auto-translated guests.
- */
-#define XENMEM_translate_gpfn_list  8
-struct xen_translate_gpfn_list {
-    /* Which domain to translate for? */
-    domid_t domid;
-
-    /* Length of list. */
-    xen_ulong_t nr_gpfns;
-
-    /* List of GPFNs to translate. */
-    GUEST_HANDLE(ulong) gpfn_list;
-
-    /*
-     * Output list to contain MFN translations. May be the same as the input
-     * list (in which case each input GPFN is overwritten with the output MFN).
-     */
-    GUEST_HANDLE(ulong) mfn_list;
-};
-DEFINE_GUEST_HANDLE_STRUCT(xen_translate_gpfn_list);
+/*** REMOVED ***/
+/*#define XENMEM_translate_gpfn_list  8*/
 
 /*
  * Returns the pseudo-physical memory map as it was when the domain
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 08:39:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 08:39:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOP9x-0008TG-ED; Wed, 17 Oct 2012 08:39:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOP9v-0008Rj-Bb
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 08:39:23 +0000
Received: from [85.158.143.99:23604] by server-3.bemta-4.messagelabs.com id
	7D/F5-03544-BBE6E705; Wed, 17 Oct 2012 08:39:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1350463159!34470657!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODI4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2089 invoked from network); 17 Oct 2012 08:39:22 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 08:39:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,599,1344211200"; d="scan'208";a="211526020"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 08:39:18 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 04:39:18 -0400
Received: from drall.uk.xensource.com ([10.80.227.107])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TOP9q-0003fa-8C;
	Wed, 17 Oct 2012 09:39:18 +0100
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 17 Oct 2012 09:39:12 +0100
Message-ID: <1350463157-5068-5-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	Stefano Stabellini ,
	Ian Campbell , xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 05/10] xen: events: pirq_check_eoi_map is X86
	specific
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On ARM I see:
drivers/xen/events.c:280:13: warning: 'pirq_check_eoi_map' defined but not used
[-Wunused-function]

Signed-off-by: Ian Campbell 
Cc: Stefano Stabellini 
---
 drivers/xen/events.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 59e10a1..912ac81 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -115,7 +115,9 @@ struct irq_info {
 #define PIRQ_SHAREABLE	(1 << 1)
 
 static int *evtchn_to_irq;
+#ifdef CONFIG_X86
 static unsigned long *pirq_eoi_map;
+#endif
 static bool (*pirq_needs_eoi)(unsigned irq);
 
 static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
@@ -277,10 +279,12 @@ static unsigned int cpu_from_evtchn(unsigned int evtchn)
 	return ret;
 }
 
+#ifdef CONFIG_X86
 static bool pirq_check_eoi_map(unsigned irq)
 {
 	return test_bit(pirq_from_irq(irq), pirq_eoi_map);
 }
+#endif
 
 static bool pirq_needs_eoi_flag(unsigned irq)
 {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 08:39:38 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 08:39:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOP9z-0008VQ-W4; Wed, 17 Oct 2012 08:39:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOP9z-0008UQ-9N
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 08:39:27 +0000
Received: from [85.158.143.99:23822] by server-2.bemta-4.messagelabs.com id
	7E/62-22268-EBE6E705; Wed, 17 Oct 2012 08:39:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1350463159!34470657!6
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODI4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2112 invoked from network); 17 Oct 2012 08:39:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 08:39:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,599,1344211200"; d="scan'208";a="211526024"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 08:39:19 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 04:39:18 -0400
Received: from drall.uk.xensource.com ([10.80.227.107])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TOP9q-0003fa-Ax;
	Wed, 17 Oct 2012 09:39:18 +0100
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 17 Oct 2012 09:39:15 +0100
Message-ID: <1350463157-5068-8-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	Ian Campbell , xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 08/10] xen: balloon: don't include e820.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This breaks on !X86 and AFAICT is not required on X86 either.

Signed-off-by: Ian Campbell 
---
 drivers/xen/balloon.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 31ab82f..d7bd1b3 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -55,7 +55,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 #include 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 08:39:38 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 08:39:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOP9z-0008VQ-W4; Wed, 17 Oct 2012 08:39:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOP9z-0008UQ-9N
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 08:39:27 +0000
Received: from [85.158.143.99:23822] by server-2.bemta-4.messagelabs.com id
	7E/62-22268-EBE6E705; Wed, 17 Oct 2012 08:39:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1350463159!34470657!6
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODI4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2112 invoked from network); 17 Oct 2012 08:39:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 08:39:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,599,1344211200"; d="scan'208";a="211526024"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 08:39:19 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 04:39:18 -0400
Received: from drall.uk.xensource.com ([10.80.227.107])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TOP9q-0003fa-Ax;
	Wed, 17 Oct 2012 09:39:18 +0100
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 17 Oct 2012 09:39:15 +0100
Message-ID: <1350463157-5068-8-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	Ian Campbell , xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 08/10] xen: balloon: don't include e820.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This breaks on !X86 and AFAICT is not required on X86 either.

Signed-off-by: Ian Campbell 
---
 drivers/xen/balloon.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 31ab82f..d7bd1b3 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -55,7 +55,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 #include 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 08:39:38 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 08:39:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOP9z-0008V6-Io; Wed, 17 Oct 2012 08:39:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOP9y-0008Rj-B5
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 08:39:26 +0000
Received: from [85.158.143.99:23793] by server-3.bemta-4.messagelabs.com id
	7B/16-03544-EBE6E705; Wed, 17 Oct 2012 08:39:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1350463159!34470657!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODI4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2106 invoked from network); 17 Oct 2012 08:39:22 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 08:39:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,599,1344211200"; d="scan'208";a="211526022"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 08:39:18 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 04:39:18 -0400
Received: from drall.uk.xensource.com ([10.80.227.107])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TOP9q-0003fa-9C;
	Wed, 17 Oct 2012 09:39:18 +0100
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 17 Oct 2012 09:39:14 +0100
Message-ID: <1350463157-5068-7-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	Ian Campbell , xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 07/10] xen: grant: use xen_pfn_t type for
	frame_list.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This correctly sizes it as 64 bit on ARM but leaves it as unsigned
long on x86 (therefore no intended change on x86).

The long and ulong guest handles are now unused (and a bit dangerous)
so remove them.

Signed-off-by: Ian Campbell 
---
 arch/arm/include/asm/xen/interface.h |    2 --
 arch/arm/xen/grant-table.c           |    2 +-
 arch/x86/include/asm/xen/interface.h |    2 --
 drivers/xen/grant-table.c            |    8 ++++----
 include/xen/grant_table.h            |    2 +-
 include/xen/interface/grant_table.h  |    2 +-
 6 files changed, 7 insertions(+), 11 deletions(-)

diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
index 62160f2..1d6ef9c 100644
--- a/arch/arm/include/asm/xen/interface.h
+++ b/arch/arm/include/asm/xen/interface.h
@@ -37,10 +37,8 @@ typedef uint64_t xen_ulong_t;
 /* Guest handles for primitive C types. */
 __DEFINE_GUEST_HANDLE(uchar, unsigned char);
 __DEFINE_GUEST_HANDLE(uint,  unsigned int);
-__DEFINE_GUEST_HANDLE(ulong, unsigned long);
 DEFINE_GUEST_HANDLE(char);
 DEFINE_GUEST_HANDLE(int);
-DEFINE_GUEST_HANDLE(long);
 DEFINE_GUEST_HANDLE(void);
 DEFINE_GUEST_HANDLE(uint64_t);
 DEFINE_GUEST_HANDLE(uint32_t);
diff --git a/arch/arm/xen/grant-table.c b/arch/arm/xen/grant-table.c
index dbd1330..859a9bb 100644
--- a/arch/arm/xen/grant-table.c
+++ b/arch/arm/xen/grant-table.c
@@ -33,7 +33,7 @@
 #include 
 #include 
 
-int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes,
+int arch_gnttab_map_shared(xen_pfn_t *frames, unsigned long nr_gframes,
 			   unsigned long max_nr_gframes,
 			   void **__shared)
 {
diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
index ab3c67c..54d52ff 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -57,10 +57,8 @@ typedef unsigned long xen_ulong_t;
 /* Guest handles for primitive C types. */
 __DEFINE_GUEST_HANDLE(uchar, unsigned char);
 __DEFINE_GUEST_HANDLE(uint,  unsigned int);
-__DEFINE_GUEST_HANDLE(ulong, unsigned long);
 DEFINE_GUEST_HANDLE(char);
 DEFINE_GUEST_HANDLE(int);
-DEFINE_GUEST_HANDLE(long);
 DEFINE_GUEST_HANDLE(void);
 DEFINE_GUEST_HANDLE(uint64_t);
 DEFINE_GUEST_HANDLE(uint32_t);
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index b2b0a37..b91f14e 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -84,7 +84,7 @@ struct gnttab_ops {
 	 * nr_gframes is the number of frames to map grant table. Returning
 	 * GNTST_okay means success and negative value means failure.
 	 */
-	int (*map_frames)(unsigned long *frames, unsigned int nr_gframes);
+	int (*map_frames)(xen_pfn_t *frames, unsigned int nr_gframes);
 	/*
 	 * Release a list of frames which are mapped in map_frames for grant
 	 * entry status.
@@ -960,7 +960,7 @@ static unsigned nr_status_frames(unsigned nr_grant_frames)
 	return (nr_grant_frames * GREFS_PER_GRANT_FRAME + SPP - 1) / SPP;
 }
 
-static int gnttab_map_frames_v1(unsigned long *frames, unsigned int nr_gframes)
+static int gnttab_map_frames_v1(xen_pfn_t *frames, unsigned int nr_gframes)
 {
 	int rc;
 
@@ -977,7 +977,7 @@ static void gnttab_unmap_frames_v1(void)
 	arch_gnttab_unmap(gnttab_shared.addr, nr_grant_frames);
 }
 
-static int gnttab_map_frames_v2(unsigned long *frames, unsigned int nr_gframes)
+static int gnttab_map_frames_v2(xen_pfn_t *frames, unsigned int nr_gframes)
 {
 	uint64_t *sframes;
 	unsigned int nr_sframes;
@@ -1029,7 +1029,7 @@ static void gnttab_unmap_frames_v2(void)
 static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 {
 	struct gnttab_setup_table setup;
-	unsigned long *frames;
+	xen_pfn_t *frames;
 	unsigned int nr_gframes = end_idx + 1;
 	int rc;
 
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index aecee9d..694dcaf 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -170,7 +170,7 @@ gnttab_set_unmap_op(struct gnttab_unmap_grant_ref *unmap, phys_addr_t addr,
 	unmap->dev_bus_addr = 0;
 }
 
-int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes,
+int arch_gnttab_map_shared(xen_pfn_t *frames, unsigned long nr_gframes,
 			   unsigned long max_nr_gframes,
 			   void **__shared);
 int arch_gnttab_map_status(uint64_t *frames, unsigned long nr_gframes,
diff --git a/include/xen/interface/grant_table.h b/include/xen/interface/grant_table.h
index f9f8b97..e40fae9 100644
--- a/include/xen/interface/grant_table.h
+++ b/include/xen/interface/grant_table.h
@@ -310,7 +310,7 @@ struct gnttab_setup_table {
     uint32_t nr_frames;
     /* OUT parameters. */
     int16_t  status;              /* GNTST_* */
-    GUEST_HANDLE(ulong) frame_list;
+    GUEST_HANDLE(xen_pfn_t) frame_list;
 };
 DEFINE_GUEST_HANDLE_STRUCT(gnttab_setup_table);
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 08:39:38 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 08:39:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOP9z-0008V6-Io; Wed, 17 Oct 2012 08:39:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOP9y-0008Rj-B5
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 08:39:26 +0000
Received: from [85.158.143.99:23793] by server-3.bemta-4.messagelabs.com id
	7B/16-03544-EBE6E705; Wed, 17 Oct 2012 08:39:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1350463159!34470657!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODI4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2106 invoked from network); 17 Oct 2012 08:39:22 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 08:39:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,599,1344211200"; d="scan'208";a="211526022"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 08:39:18 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 04:39:18 -0400
Received: from drall.uk.xensource.com ([10.80.227.107])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TOP9q-0003fa-9C;
	Wed, 17 Oct 2012 09:39:18 +0100
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 17 Oct 2012 09:39:14 +0100
Message-ID: <1350463157-5068-7-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	Ian Campbell , xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 07/10] xen: grant: use xen_pfn_t type for
	frame_list.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This correctly sizes it as 64 bit on ARM but leaves it as unsigned
long on x86 (therefore no intended change on x86).

The long and ulong guest handles are now unused (and a bit dangerous)
so remove them.

Signed-off-by: Ian Campbell 
---
 arch/arm/include/asm/xen/interface.h |    2 --
 arch/arm/xen/grant-table.c           |    2 +-
 arch/x86/include/asm/xen/interface.h |    2 --
 drivers/xen/grant-table.c            |    8 ++++----
 include/xen/grant_table.h            |    2 +-
 include/xen/interface/grant_table.h  |    2 +-
 6 files changed, 7 insertions(+), 11 deletions(-)

diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
index 62160f2..1d6ef9c 100644
--- a/arch/arm/include/asm/xen/interface.h
+++ b/arch/arm/include/asm/xen/interface.h
@@ -37,10 +37,8 @@ typedef uint64_t xen_ulong_t;
 /* Guest handles for primitive C types. */
 __DEFINE_GUEST_HANDLE(uchar, unsigned char);
 __DEFINE_GUEST_HANDLE(uint,  unsigned int);
-__DEFINE_GUEST_HANDLE(ulong, unsigned long);
 DEFINE_GUEST_HANDLE(char);
 DEFINE_GUEST_HANDLE(int);
-DEFINE_GUEST_HANDLE(long);
 DEFINE_GUEST_HANDLE(void);
 DEFINE_GUEST_HANDLE(uint64_t);
 DEFINE_GUEST_HANDLE(uint32_t);
diff --git a/arch/arm/xen/grant-table.c b/arch/arm/xen/grant-table.c
index dbd1330..859a9bb 100644
--- a/arch/arm/xen/grant-table.c
+++ b/arch/arm/xen/grant-table.c
@@ -33,7 +33,7 @@
 #include 
 #include 
 
-int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes,
+int arch_gnttab_map_shared(xen_pfn_t *frames, unsigned long nr_gframes,
 			   unsigned long max_nr_gframes,
 			   void **__shared)
 {
diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
index ab3c67c..54d52ff 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -57,10 +57,8 @@ typedef unsigned long xen_ulong_t;
 /* Guest handles for primitive C types. */
 __DEFINE_GUEST_HANDLE(uchar, unsigned char);
 __DEFINE_GUEST_HANDLE(uint,  unsigned int);
-__DEFINE_GUEST_HANDLE(ulong, unsigned long);
 DEFINE_GUEST_HANDLE(char);
 DEFINE_GUEST_HANDLE(int);
-DEFINE_GUEST_HANDLE(long);
 DEFINE_GUEST_HANDLE(void);
 DEFINE_GUEST_HANDLE(uint64_t);
 DEFINE_GUEST_HANDLE(uint32_t);
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index b2b0a37..b91f14e 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -84,7 +84,7 @@ struct gnttab_ops {
 	 * nr_gframes is the number of frames to map grant table. Returning
 	 * GNTST_okay means success and negative value means failure.
 	 */
-	int (*map_frames)(unsigned long *frames, unsigned int nr_gframes);
+	int (*map_frames)(xen_pfn_t *frames, unsigned int nr_gframes);
 	/*
 	 * Release a list of frames which are mapped in map_frames for grant
 	 * entry status.
@@ -960,7 +960,7 @@ static unsigned nr_status_frames(unsigned nr_grant_frames)
 	return (nr_grant_frames * GREFS_PER_GRANT_FRAME + SPP - 1) / SPP;
 }
 
-static int gnttab_map_frames_v1(unsigned long *frames, unsigned int nr_gframes)
+static int gnttab_map_frames_v1(xen_pfn_t *frames, unsigned int nr_gframes)
 {
 	int rc;
 
@@ -977,7 +977,7 @@ static void gnttab_unmap_frames_v1(void)
 	arch_gnttab_unmap(gnttab_shared.addr, nr_grant_frames);
 }
 
-static int gnttab_map_frames_v2(unsigned long *frames, unsigned int nr_gframes)
+static int gnttab_map_frames_v2(xen_pfn_t *frames, unsigned int nr_gframes)
 {
 	uint64_t *sframes;
 	unsigned int nr_sframes;
@@ -1029,7 +1029,7 @@ static void gnttab_unmap_frames_v2(void)
 static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 {
 	struct gnttab_setup_table setup;
-	unsigned long *frames;
+	xen_pfn_t *frames;
 	unsigned int nr_gframes = end_idx + 1;
 	int rc;
 
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index aecee9d..694dcaf 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -170,7 +170,7 @@ gnttab_set_unmap_op(struct gnttab_unmap_grant_ref *unmap, phys_addr_t addr,
 	unmap->dev_bus_addr = 0;
 }
 
-int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes,
+int arch_gnttab_map_shared(xen_pfn_t *frames, unsigned long nr_gframes,
 			   unsigned long max_nr_gframes,
 			   void **__shared);
 int arch_gnttab_map_status(uint64_t *frames, unsigned long nr_gframes,
diff --git a/include/xen/interface/grant_table.h b/include/xen/interface/grant_table.h
index f9f8b97..e40fae9 100644
--- a/include/xen/interface/grant_table.h
+++ b/include/xen/interface/grant_table.h
@@ -310,7 +310,7 @@ struct gnttab_setup_table {
     uint32_t nr_frames;
     /* OUT parameters. */
     int16_t  status;              /* GNTST_* */
-    GUEST_HANDLE(ulong) frame_list;
+    GUEST_HANDLE(xen_pfn_t) frame_list;
 };
 DEFINE_GUEST_HANDLE_STRUCT(gnttab_setup_table);
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 08:41:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 08:41:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOPBx-000100-Hc; Wed, 17 Oct 2012 08:41:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOPBw-0000zh-4G
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 08:41:28 +0000
Received: from [85.158.138.51:7953] by server-5.bemta-3.messagelabs.com id
	83/D5-12440-73F6E705; Wed, 17 Oct 2012 08:41:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1350463286!27066251!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ1MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11899 invoked from network); 17 Oct 2012 08:41:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 08:41:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,599,1344211200"; d="scan'208";a="15219028"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 08:41:26 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 09:41:26 +0100
Message-ID: <1350463284.2460.20.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 17 Oct 2012 09:41:24 +0100
In-Reply-To: <1350463157-5068-1-git-send-email-ian.campbell@citrix.com>
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
	<1350463157-5068-1-git-send-email-ian.campbell@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 01/10] xen: xenbus: quirk uses x86 specific
	cpuid
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I botched the LKML address in my git send-email cmdline so these didn't
go there. This is Xen specific enough that I don't think it is worth
resending/spamming you guys with a repeat to fix that.

On Wed, 2012-10-17 at 09:39 +0100, Ian Campbell wrote:
> This breaks on ARM. This quirk is not necessary on ARM because no
> hypervisors of that vintage exist for that architecture (port is too
> new).
> 
> Signed-off-by: Ian Campbell 
> ---
>  drivers/xen/xenbus/xenbus_xs.c |    6 ++++++
>  1 files changed, 6 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
> index 48220e1..b46ad11 100644
> --- a/drivers/xen/xenbus/xenbus_xs.c
> +++ b/drivers/xen/xenbus/xenbus_xs.c
> @@ -619,6 +619,8 @@ static struct xenbus_watch *find_watch(const char *token)
>  
>  	return NULL;
>  }
> +
> +#ifdef CONFIG_X86
>  /*
>   * Certain older XenBus toolstack cannot handle reading values that are
>   * not populated. Some Xen 3.4 installation are incapable of doing this
> @@ -637,6 +639,10 @@ static bool xen_strict_xenbus_quirk()
>  	return false;
>  
>  }
> +#else
> +static bool xen_strict_xenbus_quirk(void) { return false; }
> +#endif
> +
>  static void xs_reset_watches(void)
>  {
>  	int err, supported = 0;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 08:41:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 08:41:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOPBx-000100-Hc; Wed, 17 Oct 2012 08:41:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOPBw-0000zh-4G
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 08:41:28 +0000
Received: from [85.158.138.51:7953] by server-5.bemta-3.messagelabs.com id
	83/D5-12440-73F6E705; Wed, 17 Oct 2012 08:41:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1350463286!27066251!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ1MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11899 invoked from network); 17 Oct 2012 08:41:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 08:41:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,599,1344211200"; d="scan'208";a="15219028"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 08:41:26 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 09:41:26 +0100
Message-ID: <1350463284.2460.20.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 17 Oct 2012 09:41:24 +0100
In-Reply-To: <1350463157-5068-1-git-send-email-ian.campbell@citrix.com>
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
	<1350463157-5068-1-git-send-email-ian.campbell@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 01/10] xen: xenbus: quirk uses x86 specific
	cpuid
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I botched the LKML address in my git send-email cmdline so these didn't
go there. This is Xen specific enough that I don't think it is worth
resending/spamming you guys with a repeat to fix that.

On Wed, 2012-10-17 at 09:39 +0100, Ian Campbell wrote:
> This breaks on ARM. This quirk is not necessary on ARM because no
> hypervisors of that vintage exist for that architecture (port is too
> new).
> 
> Signed-off-by: Ian Campbell 
> ---
>  drivers/xen/xenbus/xenbus_xs.c |    6 ++++++
>  1 files changed, 6 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
> index 48220e1..b46ad11 100644
> --- a/drivers/xen/xenbus/xenbus_xs.c
> +++ b/drivers/xen/xenbus/xenbus_xs.c
> @@ -619,6 +619,8 @@ static struct xenbus_watch *find_watch(const char *token)
>  
>  	return NULL;
>  }
> +
> +#ifdef CONFIG_X86
>  /*
>   * Certain older XenBus toolstack cannot handle reading values that are
>   * not populated. Some Xen 3.4 installation are incapable of doing this
> @@ -637,6 +639,10 @@ static bool xen_strict_xenbus_quirk()
>  	return false;
>  
>  }
> +#else
> +static bool xen_strict_xenbus_quirk(void) { return false; }
> +#endif
> +
>  static void xs_reset_watches(void)
>  {
>  	int err, supported = 0;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 08:53:21 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 08:53:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOPNC-0001jn-2O; Wed, 17 Oct 2012 08:53:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOPNA-0001jb-Bk
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 08:53:04 +0000
Received: from [85.158.137.99:14655] by server-8.bemta-3.messagelabs.com id
	C5/5F-10525-FE17E705; Wed, 17 Oct 2012 08:53:03 +0000
X-Env-Sender: ying.huang@intel.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1350463982!21925468!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjE5NTM2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27289 invoked from network); 17 Oct 2012 08:53:02 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-13.tower-217.messagelabs.com with SMTP;
	17 Oct 2012 08:53:02 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 17 Oct 2012 01:53:01 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,599,1344236400"; d="scan'208";a="157150003"
Received: from yhuang-dev.sh.intel.com (HELO [10.239.13.178]) ([10.239.13.178])
	by AZSMGA002.ch.intel.com with ESMTP; 17 Oct 2012 01:53:00 -0700
Message-ID: <1350463979.7098.49.camel@yhuang-dev>
From: Huang Ying 
To: Jan Beulich 
Date: Wed, 17 Oct 2012 16:52:59 +0800
In-Reply-To: <507E72CE02000078000A1DB5@nat28.tlf.novell.com>
References: <507D8F6802000078000A1B88@nat28.tlf.novell.com>
	<1350456592.7098.42.camel@yhuang-dev>
	<507E72CE02000078000A1DB5@nat28.tlf.novell.com>
X-Mailer: Evolution 3.4.3-1 
Mime-Version: 1.0
Cc: xen-devel 
Subject: Re: [Xen-devel] [PATCH] ACPI: fix APEI related table size checking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-17 at 07:56 +0100, Jan Beulich wrote:
> >>> On 17.10.12 at 08:49, Huang Ying  wrote:
> > On Tue, 2012-10-16 at 15:46 +0100, Jan Beulich wrote:
> >> On Huang Ying's machine:
> >> 
> >> erst_tab->header_length == sizeof(struct acpi_table_einj)
> >   ~~~~                                                ~~~~
> > 
> > Typo?
> 
> Your typo: I copied the Linux commit message verbatim, to make
> it possible to match the two commits. The adjustments done in
> the actual patch eliminate the copy-n-paste mistake corrected by
> Linux commit 7ed28f2ed43ece424ff2fa4dedac7928bb37a23a.

Sorry, my bad.

Best Regards,
Huang Ying

> 
> >> but Yinghai reported that on his machine,
> >> 
> >> erst_tab->header_length == sizeof(struct acpi_table_einj) -
> >> sizeof(struct acpi_table_header)
> >> 
> >> To make erst table size checking code works on all systems, both
> >> testing are treated as PASS.
> >> 
> >> Same situation applies to einj_tab->header_length, so corresponding
> >> table size checking is changed in similar way too.
> >> 
> >> Originally-by: Yinghai Lu 
> >> Signed-off-by: Huang Ying 
> >> 
> >> - use switch() for better readability
> >> - add comment explaining why a formally invalid size it also being
> >>   accepted
> >> - check erst_tab->header.length before even looking at
> >>   erst_tab->header_length
> >> - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
> >> 
> >> Signed-off-by: Jan Beulich 
> >> 
> >> --- a/xen/drivers/acpi/apei/erst.c
> >> +++ b/xen/drivers/acpi/apei/erst.c
> >> @@ -715,12 +715,23 @@ int erst_clear(u64 record_id)
> >>  
> >>  static int __init erst_check_table(struct acpi_table_erst *erst_tab)
> >>  {
> >> -	if (erst_tab->header_length != sizeof(struct acpi_table_erst))
> >> +	if (erst_tab->header.length < sizeof(*erst_tab))
> >>  		return -EINVAL;
> >> -	if (erst_tab->header.length < sizeof(struct acpi_table_erst))
> >> +
> >> +	switch (erst_tab->header_length) {
> >> +	case sizeof(*erst_tab) - sizeof(erst_tab->header):
> >> +	/*
> >> +	 * While invalid per specification, there are (early?) systems
> >> +	 * indicating the full header size here, so accept that value too.
> >> +	 */
> >> +	case sizeof(*erst_tab):
> >> +		break;
> >> +	default:
> >>  		return -EINVAL;
> >> +	}
> >> +
> >>  	if (erst_tab->entries !=
> >> -	    (erst_tab->header.length - sizeof(struct acpi_table_erst)) /
> >> +	    (erst_tab->header.length - sizeof(*erst_tab)) /
> >>  	    sizeof(struct acpi_erst_entry))
> >>  		return -EINVAL;
> >>  
> >> 
> >> 
> >> 
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 08:53:21 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 08:53:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOPNC-0001jn-2O; Wed, 17 Oct 2012 08:53:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOPNA-0001jb-Bk
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 08:53:04 +0000
Received: from [85.158.137.99:14655] by server-8.bemta-3.messagelabs.com id
	C5/5F-10525-FE17E705; Wed, 17 Oct 2012 08:53:03 +0000
X-Env-Sender: ying.huang@intel.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1350463982!21925468!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjE5NTM2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27289 invoked from network); 17 Oct 2012 08:53:02 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-13.tower-217.messagelabs.com with SMTP;
	17 Oct 2012 08:53:02 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 17 Oct 2012 01:53:01 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,599,1344236400"; d="scan'208";a="157150003"
Received: from yhuang-dev.sh.intel.com (HELO [10.239.13.178]) ([10.239.13.178])
	by AZSMGA002.ch.intel.com with ESMTP; 17 Oct 2012 01:53:00 -0700
Message-ID: <1350463979.7098.49.camel@yhuang-dev>
From: Huang Ying 
To: Jan Beulich 
Date: Wed, 17 Oct 2012 16:52:59 +0800
In-Reply-To: <507E72CE02000078000A1DB5@nat28.tlf.novell.com>
References: <507D8F6802000078000A1B88@nat28.tlf.novell.com>
	<1350456592.7098.42.camel@yhuang-dev>
	<507E72CE02000078000A1DB5@nat28.tlf.novell.com>
X-Mailer: Evolution 3.4.3-1 
Mime-Version: 1.0
Cc: xen-devel 
Subject: Re: [Xen-devel] [PATCH] ACPI: fix APEI related table size checking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-17 at 07:56 +0100, Jan Beulich wrote:
> >>> On 17.10.12 at 08:49, Huang Ying  wrote:
> > On Tue, 2012-10-16 at 15:46 +0100, Jan Beulich wrote:
> >> On Huang Ying's machine:
> >> 
> >> erst_tab->header_length == sizeof(struct acpi_table_einj)
> >   ~~~~                                                ~~~~
> > 
> > Typo?
> 
> Your typo: I copied the Linux commit message verbatim, to make
> it possible to match the two commits. The adjustments done in
> the actual patch eliminate the copy-n-paste mistake corrected by
> Linux commit 7ed28f2ed43ece424ff2fa4dedac7928bb37a23a.

Sorry, my bad.

Best Regards,
Huang Ying

> 
> >> but Yinghai reported that on his machine,
> >> 
> >> erst_tab->header_length == sizeof(struct acpi_table_einj) -
> >> sizeof(struct acpi_table_header)
> >> 
> >> To make erst table size checking code works on all systems, both
> >> testing are treated as PASS.
> >> 
> >> Same situation applies to einj_tab->header_length, so corresponding
> >> table size checking is changed in similar way too.
> >> 
> >> Originally-by: Yinghai Lu 
> >> Signed-off-by: Huang Ying 
> >> 
> >> - use switch() for better readability
> >> - add comment explaining why a formally invalid size it also being
> >>   accepted
> >> - check erst_tab->header.length before even looking at
> >>   erst_tab->header_length
> >> - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
> >> 
> >> Signed-off-by: Jan Beulich 
> >> 
> >> --- a/xen/drivers/acpi/apei/erst.c
> >> +++ b/xen/drivers/acpi/apei/erst.c
> >> @@ -715,12 +715,23 @@ int erst_clear(u64 record_id)
> >>  
> >>  static int __init erst_check_table(struct acpi_table_erst *erst_tab)
> >>  {
> >> -	if (erst_tab->header_length != sizeof(struct acpi_table_erst))
> >> +	if (erst_tab->header.length < sizeof(*erst_tab))
> >>  		return -EINVAL;
> >> -	if (erst_tab->header.length < sizeof(struct acpi_table_erst))
> >> +
> >> +	switch (erst_tab->header_length) {
> >> +	case sizeof(*erst_tab) - sizeof(erst_tab->header):
> >> +	/*
> >> +	 * While invalid per specification, there are (early?) systems
> >> +	 * indicating the full header size here, so accept that value too.
> >> +	 */
> >> +	case sizeof(*erst_tab):
> >> +		break;
> >> +	default:
> >>  		return -EINVAL;
> >> +	}
> >> +
> >>  	if (erst_tab->entries !=
> >> -	    (erst_tab->header.length - sizeof(struct acpi_table_erst)) /
> >> +	    (erst_tab->header.length - sizeof(*erst_tab)) /
> >>  	    sizeof(struct acpi_erst_entry))
> >>  		return -EINVAL;
> >>  
> >> 
> >> 
> >> 
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 09:03:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 09:03:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOPWd-0001yG-Fs; Wed, 17 Oct 2012 09:02:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOPWc-0001yB-6Q
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 09:02:50 +0000
Received: from [85.158.138.51:65219] by server-9.bemta-3.messagelabs.com id
	C3/91-16841-9347E705; Wed, 17 Oct 2012 09:02:49 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1350464568!28340532!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16530 invoked from network); 17 Oct 2012 09:02:48 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 09:02:48 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so4229868eek.32
	for ; Wed, 17 Oct 2012 02:02:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=WptEizr3uXb1L26sGQRjINrlAZpVAW0z4TLKCftrAXQ=;
	b=FnXp/xqbk3YNaRnei5V2OUpkai3xsUpEPajylnkHKNriDdbB/Ap+ztDCiIc58ArACZ
	7NEz/GxWaWS4N8drasEI6iUP6791SQvitVzgG+SmG0UU2m7RI8Tvvgsi/bIVeu3zavV1
	53wcSYiLRUv08aPR5XJAb6gQW+9iFjf7/Kxpcfr0ko/6S5FvR+BGj6PxOy3jEwDUn1l2
	xjj/+zkv2BEVHHk5fwFM7uSaQHKKNcOyRd0Lv6lORhgDexkKMV500BUN9RL09GWuJPxi
	1Hrh2fMc/uQ9ooNqR0G9rkefrVaJ1RRY6P86zdh0Dyf8yGKqFaIhMxcfL942A84e1P1n
	6rig==
Received: by 10.14.212.72 with SMTP id x48mr25476825eeo.40.1350464568519;
	Wed, 17 Oct 2012 02:02:48 -0700 (PDT)
Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com.
	[86.183.156.141])
	by mx.google.com with ESMTPS id e7sm33881585eep.2.2012.10.17.02.02.46
	(version=SSLv3 cipher=OTHER); Wed, 17 Oct 2012 02:02:47 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Wed, 17 Oct 2012 10:02:43 +0100
From: Keir Fraser 
To: Jan Beulich ,
	xen-devel 
Message-ID: 
Thread-Topic: [Xen-devel] [PATCH] x86/oprof: adjust off-by-one counter range
	checks
Thread-Index: Ac2sRirWNfr/L0ehLUaAQSqAlvBy4w==
In-Reply-To: <507E89AF02000078000A1E10@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86/oprof: adjust off-by-one counter range
 checks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/10/2012 09:34, "Jan Beulich"  wrote:

> Signed-off-by: Jan Beulich 

Acked-by: Keir Fraser 

> --- a/xen/arch/x86/oprofile/xenoprof.c
> +++ b/xen/arch/x86/oprofile/xenoprof.c
> @@ -24,7 +24,7 @@ int xenoprof_arch_counter(XEN_GUEST_HAND
>      if ( copy_from_guest(&counter, arg, 1) )
>          return -EFAULT;
>  
> -    if ( counter.ind > OP_MAX_COUNTER )
> +    if ( counter.ind >= OP_MAX_COUNTER )
>          return -E2BIG;
>  
>      counter_config[counter.ind].count     = counter.count;
> @@ -61,7 +61,7 @@ int compat_oprof_arch_counter(XEN_GUEST_
>      if ( copy_from_guest(&counter, arg, 1) )
>          return -EFAULT;
>  
> -    if ( counter.ind > OP_MAX_COUNTER )
> +    if ( counter.ind >= OP_MAX_COUNTER )
>          return -E2BIG;
>  
>      counter_config[counter.ind].count     = counter.count;
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 09:03:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 09:03:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOPWd-0001yG-Fs; Wed, 17 Oct 2012 09:02:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOPWc-0001yB-6Q
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 09:02:50 +0000
Received: from [85.158.138.51:65219] by server-9.bemta-3.messagelabs.com id
	C3/91-16841-9347E705; Wed, 17 Oct 2012 09:02:49 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1350464568!28340532!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16530 invoked from network); 17 Oct 2012 09:02:48 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 09:02:48 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so4229868eek.32
	for ; Wed, 17 Oct 2012 02:02:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=WptEizr3uXb1L26sGQRjINrlAZpVAW0z4TLKCftrAXQ=;
	b=FnXp/xqbk3YNaRnei5V2OUpkai3xsUpEPajylnkHKNriDdbB/Ap+ztDCiIc58ArACZ
	7NEz/GxWaWS4N8drasEI6iUP6791SQvitVzgG+SmG0UU2m7RI8Tvvgsi/bIVeu3zavV1
	53wcSYiLRUv08aPR5XJAb6gQW+9iFjf7/Kxpcfr0ko/6S5FvR+BGj6PxOy3jEwDUn1l2
	xjj/+zkv2BEVHHk5fwFM7uSaQHKKNcOyRd0Lv6lORhgDexkKMV500BUN9RL09GWuJPxi
	1Hrh2fMc/uQ9ooNqR0G9rkefrVaJ1RRY6P86zdh0Dyf8yGKqFaIhMxcfL942A84e1P1n
	6rig==
Received: by 10.14.212.72 with SMTP id x48mr25476825eeo.40.1350464568519;
	Wed, 17 Oct 2012 02:02:48 -0700 (PDT)
Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com.
	[86.183.156.141])
	by mx.google.com with ESMTPS id e7sm33881585eep.2.2012.10.17.02.02.46
	(version=SSLv3 cipher=OTHER); Wed, 17 Oct 2012 02:02:47 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Wed, 17 Oct 2012 10:02:43 +0100
From: Keir Fraser 
To: Jan Beulich ,
	xen-devel 
Message-ID: 
Thread-Topic: [Xen-devel] [PATCH] x86/oprof: adjust off-by-one counter range
	checks
Thread-Index: Ac2sRirWNfr/L0ehLUaAQSqAlvBy4w==
In-Reply-To: <507E89AF02000078000A1E10@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86/oprof: adjust off-by-one counter range
 checks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/10/2012 09:34, "Jan Beulich"  wrote:

> Signed-off-by: Jan Beulich 

Acked-by: Keir Fraser 

> --- a/xen/arch/x86/oprofile/xenoprof.c
> +++ b/xen/arch/x86/oprofile/xenoprof.c
> @@ -24,7 +24,7 @@ int xenoprof_arch_counter(XEN_GUEST_HAND
>      if ( copy_from_guest(&counter, arg, 1) )
>          return -EFAULT;
>  
> -    if ( counter.ind > OP_MAX_COUNTER )
> +    if ( counter.ind >= OP_MAX_COUNTER )
>          return -E2BIG;
>  
>      counter_config[counter.ind].count     = counter.count;
> @@ -61,7 +61,7 @@ int compat_oprof_arch_counter(XEN_GUEST_
>      if ( copy_from_guest(&counter, arg, 1) )
>          return -EFAULT;
>  
> -    if ( counter.ind > OP_MAX_COUNTER )
> +    if ( counter.ind >= OP_MAX_COUNTER )
>          return -E2BIG;
>  
>      counter_config[counter.ind].count     = counter.count;
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 09:03:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 09:03:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOPWm-0001z6-S6; Wed, 17 Oct 2012 09:03:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOPWl-0001yx-Ed
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 09:02:59 +0000
Received: from [85.158.139.211:2733] by server-5.bemta-5.messagelabs.com id
	4F/2B-09732-2447E705; Wed, 17 Oct 2012 09:02:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1350464577!22172918!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ1MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 696 invoked from network); 17 Oct 2012 09:02:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 09:02:58 -0000
X-IronPort-AV: E=Sophos;i="4.80,599,1344211200"; d="scan'208";a="15219789"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 09:02:33 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 10:02:33 +0100
Message-ID: <1350464551.2460.24.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Jan Beulich 
Date: Wed, 17 Oct 2012 10:02:31 +0100
In-Reply-To: <507E7D5C02000078000A1DE6@nat28.tlf.novell.com>
References: 
	<507E7D5C02000078000A1DE6@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Jinsong Liu ,
	Ian Jackson ,
	Stefano Stabellini ,
	"Keir \(Xen.org\)" , xen-devel 
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-i386-qemuu-rhel6hvm-amd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-17 at 08:41 +0100, Jan Beulich wrote:
> So I just now realized that a similar change was already done
> by 23736:31683aa4bfb3 and then reverted by
> 23760:ae10d7804168. Nothing was done subsequently to
> address the actual problem(s). It is quite obvious that the more
> relaxed check uncovers other bugs in the ERST code, yet looking
> at the Linux history of the corresponding file doesn't reveal any
> fix the lack of which would explain an outright hang (rather than
> a crash, as I would expect to be the result of e.g. the missing
> ioremap()-s added by 0bbba38a61283a55f2061ab3e0910c572d19f462.
> 
> Most of the other changes are cosmetic or pstore related, so I
> wonder whether instead of reverting again we should try pulling
> in this one extra fix.

Worth a go. I assume this issue isn't related to the typo you found this
morning?

> If reverting is preferred (or turns out necessary if that second
> fix doesn't help), we should settle on the disposition of the whole
> APEI/ERST code, as my conclusion is that it is pretty much
> unmaintained since its original contribution over two years ago.

If we revert we should leave a big fat comment pointing to this and/or
the previous discussion to stop the next guy doing the same thing.

The comment in 26060:4fc87c2f31a0 seems to suggest that the issue is
(possibly) only a problem non-production or early machines, if that's
the case it doesn't seem worth worrying about ERST not functioning on
those Assuming the system works generally I think the world can live
without the ERST facility being available on them.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 09:03:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 09:03:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOPWm-0001z6-S6; Wed, 17 Oct 2012 09:03:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOPWl-0001yx-Ed
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 09:02:59 +0000
Received: from [85.158.139.211:2733] by server-5.bemta-5.messagelabs.com id
	4F/2B-09732-2447E705; Wed, 17 Oct 2012 09:02:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1350464577!22172918!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ1MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 696 invoked from network); 17 Oct 2012 09:02:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 09:02:58 -0000
X-IronPort-AV: E=Sophos;i="4.80,599,1344211200"; d="scan'208";a="15219789"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 09:02:33 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 10:02:33 +0100
Message-ID: <1350464551.2460.24.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Jan Beulich 
Date: Wed, 17 Oct 2012 10:02:31 +0100
In-Reply-To: <507E7D5C02000078000A1DE6@nat28.tlf.novell.com>
References: 
	<507E7D5C02000078000A1DE6@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Jinsong Liu ,
	Ian Jackson ,
	Stefano Stabellini ,
	"Keir \(Xen.org\)" , xen-devel 
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-i386-qemuu-rhel6hvm-amd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-17 at 08:41 +0100, Jan Beulich wrote:
> So I just now realized that a similar change was already done
> by 23736:31683aa4bfb3 and then reverted by
> 23760:ae10d7804168. Nothing was done subsequently to
> address the actual problem(s). It is quite obvious that the more
> relaxed check uncovers other bugs in the ERST code, yet looking
> at the Linux history of the corresponding file doesn't reveal any
> fix the lack of which would explain an outright hang (rather than
> a crash, as I would expect to be the result of e.g. the missing
> ioremap()-s added by 0bbba38a61283a55f2061ab3e0910c572d19f462.
> 
> Most of the other changes are cosmetic or pstore related, so I
> wonder whether instead of reverting again we should try pulling
> in this one extra fix.

Worth a go. I assume this issue isn't related to the typo you found this
morning?

> If reverting is preferred (or turns out necessary if that second
> fix doesn't help), we should settle on the disposition of the whole
> APEI/ERST code, as my conclusion is that it is pretty much
> unmaintained since its original contribution over two years ago.

If we revert we should leave a big fat comment pointing to this and/or
the previous discussion to stop the next guy doing the same thing.

The comment in 26060:4fc87c2f31a0 seems to suggest that the issue is
(possibly) only a problem non-production or early machines, if that's
the case it doesn't seem worth worrying about ERST not functioning on
those Assuming the system works generally I think the world can live
without the ERST facility being available on them.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 09:06:22 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 09:06:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOPZY-0002DI-D7; Wed, 17 Oct 2012 09:05:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOPZX-0002D7-DP
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 09:05:51 +0000
Received: from [85.158.143.35:38416] by server-2.bemta-4.messagelabs.com id
	AA/00-22268-EE47E705; Wed, 17 Oct 2012 09:05:50 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1350464657!14707314!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17555 invoked from network); 17 Oct 2012 09:04:18 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 09:04:18 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so4230757eek.32
	for ; Wed, 17 Oct 2012 02:04:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=kwpG81aZzX+mAX5LOgF3WnxygvgFTrjkrxqiC0Xnq0E=;
	b=HnYQKhVNtdkscGPB35r/HeHB4VXQyNup1BpuVmHiJqDt81DYd8xb2F87H/j8Qg6c06
	JlctlfKA5ADGZzR8L5lJSWuzUqx1S27qxH9XKslYE7pHWGPHi7tFkxx7ToDqQkVrzXI5
	KRRe8sWZ39/sjpV+DXCvUq5ObBTnrw3RdGg102k7Mzv/B2L76paNJzyEZ1LOSMAkWcvw
	Om6v8BgQGD55mDt/UsA5IoUiwTLL+IB6D7wGla2Y1cVKiLfvRj4EsKtMs3QDWZUHhwFS
	Hbpuis9Eo9f+ERIPyoPXHiB0KngO1yEZshvgau0uCikkt5EIs/0BLqpipB5cACwLuIHc
	IRXw==
Received: by 10.14.209.129 with SMTP id s1mr25719536eeo.24.1350464657575;
	Wed, 17 Oct 2012 02:04:17 -0700 (PDT)
Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com.
	[86.183.156.141])
	by mx.google.com with ESMTPS id r45sm33891121eem.6.2012.10.17.02.04.11
	(version=SSLv3 cipher=OTHER); Wed, 17 Oct 2012 02:04:14 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Wed, 17 Oct 2012 10:04:05 +0100
From: Keir Fraser 
To: Jan Beulich ,
	"Liu, Jinsong" 
Message-ID: 
Thread-Topic: [Xen-devel] [xen-unstable bisection] complete
	test-amd64-i386-qemuu-rhel6hvm-amd
Thread-Index: Ac2sRlu2ZrtZdv29RkC/0WskhXk4CA==
In-Reply-To: <507E7D5C02000078000A1DE6@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel ,
	Ian Jackson ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-i386-qemuu-rhel6hvm-amd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/10/2012 08:41, "Jan Beulich"  wrote:

> So I just now realized that a similar change was already done
> by 23736:31683aa4bfb3 and then reverted by
> 23760:ae10d7804168. Nothing was done subsequently to
> address the actual problem(s). It is quite obvious that the more
> relaxed check uncovers other bugs in the ERST code, yet looking
> at the Linux history of the corresponding file doesn't reveal any
> fix the lack of which would explain an outright hang (rather than
> a crash, as I would expect to be the result of e.g. the missing
> ioremap()-s added by 0bbba38a61283a55f2061ab3e0910c572d19f462.
> 
> Most of the other changes are cosmetic or pstore related, so I
> wonder whether instead of reverting again we should try pulling
> in this one extra fix.
> 
> If reverting is preferred (or turns out necessary if that second
> fix doesn't help), we should settle on the disposition of the whole
> APEI/ERST code, as my conclusion is that it is pretty much
> unmaintained since its original contribution over two years ago.

Perhaps we reverted before because we decided that this advertised table
size was a bug, and handling it just opened us to other bugs lurking in the
table?

 -- Keir

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 09:06:22 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 09:06:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOPZY-0002DI-D7; Wed, 17 Oct 2012 09:05:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOPZX-0002D7-DP
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 09:05:51 +0000
Received: from [85.158.143.35:38416] by server-2.bemta-4.messagelabs.com id
	AA/00-22268-EE47E705; Wed, 17 Oct 2012 09:05:50 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1350464657!14707314!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17555 invoked from network); 17 Oct 2012 09:04:18 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 09:04:18 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so4230757eek.32
	for ; Wed, 17 Oct 2012 02:04:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=kwpG81aZzX+mAX5LOgF3WnxygvgFTrjkrxqiC0Xnq0E=;
	b=HnYQKhVNtdkscGPB35r/HeHB4VXQyNup1BpuVmHiJqDt81DYd8xb2F87H/j8Qg6c06
	JlctlfKA5ADGZzR8L5lJSWuzUqx1S27qxH9XKslYE7pHWGPHi7tFkxx7ToDqQkVrzXI5
	KRRe8sWZ39/sjpV+DXCvUq5ObBTnrw3RdGg102k7Mzv/B2L76paNJzyEZ1LOSMAkWcvw
	Om6v8BgQGD55mDt/UsA5IoUiwTLL+IB6D7wGla2Y1cVKiLfvRj4EsKtMs3QDWZUHhwFS
	Hbpuis9Eo9f+ERIPyoPXHiB0KngO1yEZshvgau0uCikkt5EIs/0BLqpipB5cACwLuIHc
	IRXw==
Received: by 10.14.209.129 with SMTP id s1mr25719536eeo.24.1350464657575;
	Wed, 17 Oct 2012 02:04:17 -0700 (PDT)
Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com.
	[86.183.156.141])
	by mx.google.com with ESMTPS id r45sm33891121eem.6.2012.10.17.02.04.11
	(version=SSLv3 cipher=OTHER); Wed, 17 Oct 2012 02:04:14 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Wed, 17 Oct 2012 10:04:05 +0100
From: Keir Fraser 
To: Jan Beulich ,
	"Liu, Jinsong" 
Message-ID: 
Thread-Topic: [Xen-devel] [xen-unstable bisection] complete
	test-amd64-i386-qemuu-rhel6hvm-amd
Thread-Index: Ac2sRlu2ZrtZdv29RkC/0WskhXk4CA==
In-Reply-To: <507E7D5C02000078000A1DE6@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel ,
	Ian Jackson ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-i386-qemuu-rhel6hvm-amd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/10/2012 08:41, "Jan Beulich"  wrote:

> So I just now realized that a similar change was already done
> by 23736:31683aa4bfb3 and then reverted by
> 23760:ae10d7804168. Nothing was done subsequently to
> address the actual problem(s). It is quite obvious that the more
> relaxed check uncovers other bugs in the ERST code, yet looking
> at the Linux history of the corresponding file doesn't reveal any
> fix the lack of which would explain an outright hang (rather than
> a crash, as I would expect to be the result of e.g. the missing
> ioremap()-s added by 0bbba38a61283a55f2061ab3e0910c572d19f462.
> 
> Most of the other changes are cosmetic or pstore related, so I
> wonder whether instead of reverting again we should try pulling
> in this one extra fix.
> 
> If reverting is preferred (or turns out necessary if that second
> fix doesn't help), we should settle on the disposition of the whole
> APEI/ERST code, as my conclusion is that it is pretty much
> unmaintained since its original contribution over two years ago.

Perhaps we reverted before because we decided that this advertised table
size was a bug, and handling it just opened us to other bugs lurking in the
table?

 -- Keir

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 09:09:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 09:09:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOPcY-0002Pt-W7; Wed, 17 Oct 2012 09:08:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOPcX-0002Pa-7w
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 09:08:57 +0000
Received: from [85.158.137.99:30444] by server-13.bemta-3.messagelabs.com id
	7D/D9-26794-8A57E705; Wed, 17 Oct 2012 09:08:56 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1350464935!19524749!1
X-Originating-IP: [213.199.154.144]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31075 invoked from network); 17 Oct 2012 09:08:55 -0000
Received: from db3ehsobe006.messaging.microsoft.com (HELO
	db3outboundpool.messaging.microsoft.com) (213.199.154.144)
	by server-15.tower-217.messagelabs.com with AES128-SHA encrypted SMTP;
	17 Oct 2012 09:08:55 -0000
Received: from mail56-db3-R.bigfish.com (10.3.81.231) by
	DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id
	14.1.225.23; Wed, 17 Oct 2012 09:08:54 +0000
Received: from mail56-db3 (localhost [127.0.0.1])	by mail56-db3-R.bigfish.com
	(Postfix) with ESMTP id AED441800B4	for ;
	Wed, 17 Oct 2012 09:08:54 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzc85fhc85dhzz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12bdh137ah1441h34h1155h)
Received: from mail56-db3 (localhost.localdomain [127.0.0.1]) by mail56-db3
	(MessageSwitch) id 1350464930648030_25066;
	Wed, 17 Oct 2012 09:08:50 +0000 (UTC)
Received: from DB3EHSMHS006.bigfish.com (unknown [10.3.81.250])	by
	mail56-db3.bigfish.com (Postfix) with ESMTP id 9A93BA0047	for
	; Wed, 17 Oct 2012 09:08:50 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS006.bigfish.com (10.3.87.106) with Microsoft SMTP Server id
	14.1.225.23; Wed, 17 Oct 2012 09:08:49 +0000
X-WSS-ID: 0MC15EN-01-55R-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1) with ESMTP id 2CB05102808D	for ;
	Wed, 17 Oct 2012 04:08:46 -0500 (CDT)
Received: from SAUSEXDAG05.amd.com (163.181.55.6) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 17 Oct 2012 04:24:36 -0500
Received: from STOREXDAG03.amd.com (10.1.13.12) by sausexdag05.amd.com
	(163.181.55.6) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Wed, 17 Oct 2012 04:08:38 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag03.amd.com
	(10.1.13.12) with Microsoft SMTP Server id 14.1.323.3; Wed, 17 Oct 2012
	05:08:37 -0400
Message-ID: <507E7593.9080904@amd.com>
Date: Wed, 17 Oct 2012 11:08:35 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" 
Content-Type: multipart/mixed; boundary="------------040904050005060908070009"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] nestedsvm: fix VMEXIT emulation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------040904050005060908070009
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit


Values in regs can be newer than those in the shadow
vmcb (e.g. due to an instruction emulation right before).
So use the values from regs.

Signed-off-by: Christoph Egger 


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------040904050005060908070009
Content-Type: text/plain; charset="us-ascii"; name="xen_nh_vmexit.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_nh_vmexit.diff"
Content-Description: xen_nh_vmexit.diff

diff -r 6b73078a4403 xen/arch/x86/hvm/svm/nestedsvm.c
--- a/xen/arch/x86/hvm/svm/nestedsvm.c	Fri Oct 12 14:38:20 2012 +0200
+++ b/xen/arch/x86/hvm/svm/nestedsvm.c	Wed Oct 17 09:19:05 2012 +0200
@@ -990,7 +999,7 @@ nsvm_vmcb_guest_intercepts_trap(struct v
 }
 
 static int
-nsvm_vmcb_prepare4vmexit(struct vcpu *v)
+nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs)
 {
     struct nestedvcpu *nv = &vcpu_nestedhvm(v);
     struct nestedsvm *svm = &vcpu_nestedsvm(v);
@@ -1114,17 +1123,22 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v)
     ns_vmcb->_dr7 = n2vmcb->_dr7;
     ns_vmcb->_dr6 = n2vmcb->_dr6;
 
+    /* Restore registers from regs as those values
+     * can be newer than in n2vmcb (e.g. due to an
+     * instruction emulation right before).
+     */
+
     /* RFLAGS */
-    ns_vmcb->rflags = n2vmcb->rflags;
+    ns_vmcb->rflags = n2vmcb->rflags = regs->rflags;
 
     /* RIP */
-    ns_vmcb->rip = n2vmcb->rip;
+    ns_vmcb->rip = n2vmcb->rip = regs->rip;
 
     /* RSP */
-    ns_vmcb->rsp = n2vmcb->rsp;
+    ns_vmcb->rsp = n2vmcb->rsp = regs->rsp;
 
     /* RAX */
-    ns_vmcb->rax = n2vmcb->rax;
+    ns_vmcb->rax = n2vmcb->rax = regs->rax;
 
     /* Keep the l2 guest values of the fs, gs, ldtr, tr, kerngsbase,
      * star, lstar, cstar, sfmask, sysenter_cs, sysenter_esp,
@@ -1358,7 +1372,7 @@ nestedsvm_vmexit_n2n1(struct vcpu *v, st
     ASSERT(vcpu_nestedhvm(v).nv_vmswitch_in_progress);
     ASSERT(nestedhvm_vcpu_in_guestmode(v));
 
-    rc = nsvm_vmcb_prepare4vmexit(v);
+    rc = nsvm_vmcb_prepare4vmexit(v, regs);
     if (rc)
         ret = NESTEDHVM_VMEXIT_ERROR;
 

--------------040904050005060908070009
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------040904050005060908070009--


From xen-devel-bounces@lists.xen.org Wed Oct 17 09:09:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 09:09:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOPcY-0002Pt-W7; Wed, 17 Oct 2012 09:08:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOPcX-0002Pa-7w
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 09:08:57 +0000
Received: from [85.158.137.99:30444] by server-13.bemta-3.messagelabs.com id
	7D/D9-26794-8A57E705; Wed, 17 Oct 2012 09:08:56 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1350464935!19524749!1
X-Originating-IP: [213.199.154.144]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31075 invoked from network); 17 Oct 2012 09:08:55 -0000
Received: from db3ehsobe006.messaging.microsoft.com (HELO
	db3outboundpool.messaging.microsoft.com) (213.199.154.144)
	by server-15.tower-217.messagelabs.com with AES128-SHA encrypted SMTP;
	17 Oct 2012 09:08:55 -0000
Received: from mail56-db3-R.bigfish.com (10.3.81.231) by
	DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id
	14.1.225.23; Wed, 17 Oct 2012 09:08:54 +0000
Received: from mail56-db3 (localhost [127.0.0.1])	by mail56-db3-R.bigfish.com
	(Postfix) with ESMTP id AED441800B4	for ;
	Wed, 17 Oct 2012 09:08:54 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzc85fhc85dhzz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12bdh137ah1441h34h1155h)
Received: from mail56-db3 (localhost.localdomain [127.0.0.1]) by mail56-db3
	(MessageSwitch) id 1350464930648030_25066;
	Wed, 17 Oct 2012 09:08:50 +0000 (UTC)
Received: from DB3EHSMHS006.bigfish.com (unknown [10.3.81.250])	by
	mail56-db3.bigfish.com (Postfix) with ESMTP id 9A93BA0047	for
	; Wed, 17 Oct 2012 09:08:50 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS006.bigfish.com (10.3.87.106) with Microsoft SMTP Server id
	14.1.225.23; Wed, 17 Oct 2012 09:08:49 +0000
X-WSS-ID: 0MC15EN-01-55R-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1) with ESMTP id 2CB05102808D	for ;
	Wed, 17 Oct 2012 04:08:46 -0500 (CDT)
Received: from SAUSEXDAG05.amd.com (163.181.55.6) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 17 Oct 2012 04:24:36 -0500
Received: from STOREXDAG03.amd.com (10.1.13.12) by sausexdag05.amd.com
	(163.181.55.6) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Wed, 17 Oct 2012 04:08:38 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag03.amd.com
	(10.1.13.12) with Microsoft SMTP Server id 14.1.323.3; Wed, 17 Oct 2012
	05:08:37 -0400
Message-ID: <507E7593.9080904@amd.com>
Date: Wed, 17 Oct 2012 11:08:35 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" 
Content-Type: multipart/mixed; boundary="------------040904050005060908070009"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] nestedsvm: fix VMEXIT emulation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------040904050005060908070009
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit


Values in regs can be newer than those in the shadow
vmcb (e.g. due to an instruction emulation right before).
So use the values from regs.

Signed-off-by: Christoph Egger 


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------040904050005060908070009
Content-Type: text/plain; charset="us-ascii"; name="xen_nh_vmexit.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_nh_vmexit.diff"
Content-Description: xen_nh_vmexit.diff

diff -r 6b73078a4403 xen/arch/x86/hvm/svm/nestedsvm.c
--- a/xen/arch/x86/hvm/svm/nestedsvm.c	Fri Oct 12 14:38:20 2012 +0200
+++ b/xen/arch/x86/hvm/svm/nestedsvm.c	Wed Oct 17 09:19:05 2012 +0200
@@ -990,7 +999,7 @@ nsvm_vmcb_guest_intercepts_trap(struct v
 }
 
 static int
-nsvm_vmcb_prepare4vmexit(struct vcpu *v)
+nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs)
 {
     struct nestedvcpu *nv = &vcpu_nestedhvm(v);
     struct nestedsvm *svm = &vcpu_nestedsvm(v);
@@ -1114,17 +1123,22 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v)
     ns_vmcb->_dr7 = n2vmcb->_dr7;
     ns_vmcb->_dr6 = n2vmcb->_dr6;
 
+    /* Restore registers from regs as those values
+     * can be newer than in n2vmcb (e.g. due to an
+     * instruction emulation right before).
+     */
+
     /* RFLAGS */
-    ns_vmcb->rflags = n2vmcb->rflags;
+    ns_vmcb->rflags = n2vmcb->rflags = regs->rflags;
 
     /* RIP */
-    ns_vmcb->rip = n2vmcb->rip;
+    ns_vmcb->rip = n2vmcb->rip = regs->rip;
 
     /* RSP */
-    ns_vmcb->rsp = n2vmcb->rsp;
+    ns_vmcb->rsp = n2vmcb->rsp = regs->rsp;
 
     /* RAX */
-    ns_vmcb->rax = n2vmcb->rax;
+    ns_vmcb->rax = n2vmcb->rax = regs->rax;
 
     /* Keep the l2 guest values of the fs, gs, ldtr, tr, kerngsbase,
      * star, lstar, cstar, sfmask, sysenter_cs, sysenter_esp,
@@ -1358,7 +1372,7 @@ nestedsvm_vmexit_n2n1(struct vcpu *v, st
     ASSERT(vcpu_nestedhvm(v).nv_vmswitch_in_progress);
     ASSERT(nestedhvm_vcpu_in_guestmode(v));
 
-    rc = nsvm_vmcb_prepare4vmexit(v);
+    rc = nsvm_vmcb_prepare4vmexit(v, regs);
     if (rc)
         ret = NESTEDHVM_VMEXIT_ERROR;
 

--------------040904050005060908070009
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------040904050005060908070009--


From xen-devel-bounces@lists.xen.org Wed Oct 17 09:09:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 09:09:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOPd7-0002TC-Dn; Wed, 17 Oct 2012 09:09:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOPd5-0002T1-GE
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 09:09:31 +0000
Received: from [85.158.137.99:46511] by server-2.bemta-3.messagelabs.com id
	BD/33-00604-AC57E705; Wed, 17 Oct 2012 09:09:30 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1350464969!20679735!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31319 invoked from network); 17 Oct 2012 09:09:30 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-217.messagelabs.com with SMTP;
	17 Oct 2012 09:09:30 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 17 Oct 2012 10:09:57 +0100
Message-Id: <507E91E602000078000A1E76@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 17 Oct 2012 10:09:26 +0100
From: "Jan Beulich" 
To: "Ian Campbell" ,
	"Konrad Rzeszutek Wilk" 
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
	<1350463157-5068-1-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1350463157-5068-1-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Stefano Stabellini , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 01/10] xen: xenbus: quirk uses x86 specific
 cpuid
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 17.10.12 at 10:39, Ian Campbell  wrote:
> --- a/drivers/xen/xenbus/xenbus_xs.c
> +++ b/drivers/xen/xenbus/xenbus_xs.c
> @@ -619,6 +619,8 @@ static struct xenbus_watch *find_watch(const char *token)
>  
>  	return NULL;
>  }
> +
> +#ifdef CONFIG_X86
>  /*
>   * Certain older XenBus toolstack cannot handle reading values that are
>   * not populated. Some Xen 3.4 installation are incapable of doing this
> @@ -637,6 +639,10 @@ static bool xen_strict_xenbus_quirk()
>  	return false;
>  
>  }
> +#else
> +static bool xen_strict_xenbus_quirk(void) { return false; }
> +#endif

Wouldn't it reduce redundancy if the #ifdef block was inserted
inside the existing function?

Jan

> +
>  static void xs_reset_watches(void)
>  {
>  	int err, supported = 0;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 09:09:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 09:09:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOPd7-0002TC-Dn; Wed, 17 Oct 2012 09:09:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOPd5-0002T1-GE
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 09:09:31 +0000
Received: from [85.158.137.99:46511] by server-2.bemta-3.messagelabs.com id
	BD/33-00604-AC57E705; Wed, 17 Oct 2012 09:09:30 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1350464969!20679735!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31319 invoked from network); 17 Oct 2012 09:09:30 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-217.messagelabs.com with SMTP;
	17 Oct 2012 09:09:30 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 17 Oct 2012 10:09:57 +0100
Message-Id: <507E91E602000078000A1E76@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 17 Oct 2012 10:09:26 +0100
From: "Jan Beulich" 
To: "Ian Campbell" ,
	"Konrad Rzeszutek Wilk" 
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
	<1350463157-5068-1-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1350463157-5068-1-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Stefano Stabellini , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 01/10] xen: xenbus: quirk uses x86 specific
 cpuid
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 17.10.12 at 10:39, Ian Campbell  wrote:
> --- a/drivers/xen/xenbus/xenbus_xs.c
> +++ b/drivers/xen/xenbus/xenbus_xs.c
> @@ -619,6 +619,8 @@ static struct xenbus_watch *find_watch(const char *token)
>  
>  	return NULL;
>  }
> +
> +#ifdef CONFIG_X86
>  /*
>   * Certain older XenBus toolstack cannot handle reading values that are
>   * not populated. Some Xen 3.4 installation are incapable of doing this
> @@ -637,6 +639,10 @@ static bool xen_strict_xenbus_quirk()
>  	return false;
>  
>  }
> +#else
> +static bool xen_strict_xenbus_quirk(void) { return false; }
> +#endif

Wouldn't it reduce redundancy if the #ifdef block was inserted
inside the existing function?

Jan

> +
>  static void xs_reset_watches(void)
>  {
>  	int err, supported = 0;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 09:10:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 09:10:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOPeI-0002bc-Sm; Wed, 17 Oct 2012 09:10:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOPeI-0002bV-4g
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 09:10:46 +0000
Received: from [85.158.137.99:60360] by server-12.bemta-3.messagelabs.com id
	53/7D-27853-5167E705; Wed, 17 Oct 2012 09:10:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1350465044!17097541!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2619 invoked from network); 17 Oct 2012 09:10:44 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-217.messagelabs.com with SMTP;
	17 Oct 2012 09:10:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 17 Oct 2012 10:11:14 +0100
Message-Id: <507E923202000078000A1E8C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 17 Oct 2012 10:10:42 +0100
From: "Jan Beulich" 
To: "Ian Campbell" ,
	"Konrad Rzeszutek Wilk" 
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
	<1350463157-5068-4-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1350463157-5068-4-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Stefano Stabellini , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 04/10] xen: dbgp: Fix warning when
 CONFIG_PCI is not enabled.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 17.10.12 at 10:39, Ian Campbell  wrote:
> I saw this on ARM:
> linux/drivers/xen/dbgp.c:11:23: warning: unused variable 'ctrlr' 
> [-Wunused-variable]
> 
> Signed-off-by: Ian Campbell 
> Cc: Jan Beulich 

Acked-by: Jan Beulich 

> ---
>  drivers/xen/dbgp.c |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/xen/dbgp.c b/drivers/xen/dbgp.c
> index 42569c7..f3ccc80 100644
> --- a/drivers/xen/dbgp.c
> +++ b/drivers/xen/dbgp.c
> @@ -8,7 +8,9 @@
>  
>  static int xen_dbgp_op(struct usb_hcd *hcd, int op)
>  {
> +#ifdef CONFIG_PCI
>  	const struct device *ctrlr = hcd_to_bus(hcd)->controller;
> +#endif
>  	struct physdev_dbgp_op dbgp;
>  
>  	if (!xen_initial_domain())
> -- 
> 1.7.2.5




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 09:10:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 09:10:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOPeI-0002bc-Sm; Wed, 17 Oct 2012 09:10:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOPeI-0002bV-4g
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 09:10:46 +0000
Received: from [85.158.137.99:60360] by server-12.bemta-3.messagelabs.com id
	53/7D-27853-5167E705; Wed, 17 Oct 2012 09:10:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1350465044!17097541!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2619 invoked from network); 17 Oct 2012 09:10:44 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-217.messagelabs.com with SMTP;
	17 Oct 2012 09:10:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 17 Oct 2012 10:11:14 +0100
Message-Id: <507E923202000078000A1E8C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 17 Oct 2012 10:10:42 +0100
From: "Jan Beulich" 
To: "Ian Campbell" ,
	"Konrad Rzeszutek Wilk" 
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
	<1350463157-5068-4-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1350463157-5068-4-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Stefano Stabellini , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 04/10] xen: dbgp: Fix warning when
 CONFIG_PCI is not enabled.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 17.10.12 at 10:39, Ian Campbell  wrote:
> I saw this on ARM:
> linux/drivers/xen/dbgp.c:11:23: warning: unused variable 'ctrlr' 
> [-Wunused-variable]
> 
> Signed-off-by: Ian Campbell 
> Cc: Jan Beulich 

Acked-by: Jan Beulich 

> ---
>  drivers/xen/dbgp.c |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/xen/dbgp.c b/drivers/xen/dbgp.c
> index 42569c7..f3ccc80 100644
> --- a/drivers/xen/dbgp.c
> +++ b/drivers/xen/dbgp.c
> @@ -8,7 +8,9 @@
>  
>  static int xen_dbgp_op(struct usb_hcd *hcd, int op)
>  {
> +#ifdef CONFIG_PCI
>  	const struct device *ctrlr = hcd_to_bus(hcd)->controller;
> +#endif
>  	struct physdev_dbgp_op dbgp;
>  
>  	if (!xen_initial_domain())
> -- 
> 1.7.2.5




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 09:18:28 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 09:18:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOPla-0002xF-8F; Wed, 17 Oct 2012 09:18:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOPlY-0002xA-5l
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 09:18:16 +0000
Received: from [85.158.143.99:6856] by server-2.bemta-4.messagelabs.com id
	FE/78-22268-6D77E705; Wed, 17 Oct 2012 09:18:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1350465493!28319470!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32672 invoked from network); 17 Oct 2012 09:18:13 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-216.messagelabs.com with SMTP;
	17 Oct 2012 09:18:13 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 17 Oct 2012 10:19:00 +0100
Message-Id: <507E93F302000078000A1E98@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 17 Oct 2012 10:18:11 +0100
From: "Jan Beulich" 
To: "Ian Campbell" 
References: 
	<507E7D5C02000078000A1DE6@nat28.tlf.novell.com>
	<1350464551.2460.24.camel@zakaz.uk.xensource.com>
In-Reply-To: <1350464551.2460.24.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jinsong Liu , "Keir \(Xen.org\)" ,
	xen-devel ,
	Ian Jackson ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-i386-qemuu-rhel6hvm-amd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 17.10.12 at 11:02, Ian Campbell  wrote:
> On Wed, 2012-10-17 at 08:41 +0100, Jan Beulich wrote:
>> So I just now realized that a similar change was already done
>> by 23736:31683aa4bfb3 and then reverted by
>> 23760:ae10d7804168. Nothing was done subsequently to
>> address the actual problem(s). It is quite obvious that the more
>> relaxed check uncovers other bugs in the ERST code, yet looking
>> at the Linux history of the corresponding file doesn't reveal any
>> fix the lack of which would explain an outright hang (rather than
>> a crash, as I would expect to be the result of e.g. the missing
>> ioremap()-s added by 0bbba38a61283a55f2061ab3e0910c572d19f462.
>> 
>> Most of the other changes are cosmetic or pstore related, so I
>> wonder whether instead of reverting again we should try pulling
>> in this one extra fix.
> 
> Worth a go. I assume this issue isn't related to the typo you found this
> morning?

I didn't find any typo; the original author of the Linux side patch
pointed out a typo in the commit message (which was copied
verbatim from the Linux side).

>> If reverting is preferred (or turns out necessary if that second
>> fix doesn't help), we should settle on the disposition of the whole
>> APEI/ERST code, as my conclusion is that it is pretty much
>> unmaintained since its original contribution over two years ago.
> 
> If we revert we should leave a big fat comment pointing to this and/or
> the previous discussion to stop the next guy doing the same thing.

We should rather decide whether this should get fixed, or the
code ripped out (decision mainly depending on the original
contributer - Intel - being willing to fix the code).

> The comment in 26060:4fc87c2f31a0 seems to suggest that the issue is
> (possibly) only a problem non-production or early machines, if that's
> the case it doesn't seem worth worrying about ERST not functioning on
> those Assuming the system works generally I think the world can live
> without the ERST facility being available on them.

It's actually the other way around - prior to the patch, to code
accepted only the value seen on some early systems, whereas
the patch gets it in line with the spec, but still permits the wrong
value to be used. Which implies that the AMD systems the tester
uses use the correct value (and hangs because we now don't
reject that anymore).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 09:18:28 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 09:18:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOPla-0002xF-8F; Wed, 17 Oct 2012 09:18:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOPlY-0002xA-5l
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 09:18:16 +0000
Received: from [85.158.143.99:6856] by server-2.bemta-4.messagelabs.com id
	FE/78-22268-6D77E705; Wed, 17 Oct 2012 09:18:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1350465493!28319470!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32672 invoked from network); 17 Oct 2012 09:18:13 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-216.messagelabs.com with SMTP;
	17 Oct 2012 09:18:13 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 17 Oct 2012 10:19:00 +0100
Message-Id: <507E93F302000078000A1E98@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 17 Oct 2012 10:18:11 +0100
From: "Jan Beulich" 
To: "Ian Campbell" 
References: 
	<507E7D5C02000078000A1DE6@nat28.tlf.novell.com>
	<1350464551.2460.24.camel@zakaz.uk.xensource.com>
In-Reply-To: <1350464551.2460.24.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jinsong Liu , "Keir \(Xen.org\)" ,
	xen-devel ,
	Ian Jackson ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-i386-qemuu-rhel6hvm-amd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 17.10.12 at 11:02, Ian Campbell  wrote:
> On Wed, 2012-10-17 at 08:41 +0100, Jan Beulich wrote:
>> So I just now realized that a similar change was already done
>> by 23736:31683aa4bfb3 and then reverted by
>> 23760:ae10d7804168. Nothing was done subsequently to
>> address the actual problem(s). It is quite obvious that the more
>> relaxed check uncovers other bugs in the ERST code, yet looking
>> at the Linux history of the corresponding file doesn't reveal any
>> fix the lack of which would explain an outright hang (rather than
>> a crash, as I would expect to be the result of e.g. the missing
>> ioremap()-s added by 0bbba38a61283a55f2061ab3e0910c572d19f462.
>> 
>> Most of the other changes are cosmetic or pstore related, so I
>> wonder whether instead of reverting again we should try pulling
>> in this one extra fix.
> 
> Worth a go. I assume this issue isn't related to the typo you found this
> morning?

I didn't find any typo; the original author of the Linux side patch
pointed out a typo in the commit message (which was copied
verbatim from the Linux side).

>> If reverting is preferred (or turns out necessary if that second
>> fix doesn't help), we should settle on the disposition of the whole
>> APEI/ERST code, as my conclusion is that it is pretty much
>> unmaintained since its original contribution over two years ago.
> 
> If we revert we should leave a big fat comment pointing to this and/or
> the previous discussion to stop the next guy doing the same thing.

We should rather decide whether this should get fixed, or the
code ripped out (decision mainly depending on the original
contributer - Intel - being willing to fix the code).

> The comment in 26060:4fc87c2f31a0 seems to suggest that the issue is
> (possibly) only a problem non-production or early machines, if that's
> the case it doesn't seem worth worrying about ERST not functioning on
> those Assuming the system works generally I think the world can live
> without the ERST facility being available on them.

It's actually the other way around - prior to the patch, to code
accepted only the value seen on some early systems, whereas
the patch gets it in line with the spec, but still permits the wrong
value to be used. Which implies that the AMD systems the tester
uses use the correct value (and hangs because we now don't
reject that anymore).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 09:21:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 09:21:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOPoM-00035K-Vg; Wed, 17 Oct 2012 09:21:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOPoL-000356-Ms
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 09:21:09 +0000
Received: from [85.158.138.51:46861] by server-5.bemta-3.messagelabs.com id
	57/3C-12440-4887E705; Wed, 17 Oct 2012 09:21:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1350465666!34667072!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18864 invoked from network); 17 Oct 2012 09:21:06 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-174.messagelabs.com with SMTP;
	17 Oct 2012 09:21:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 17 Oct 2012 10:22:03 +0100
Message-Id: <507E949F02000078000A1EA5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 17 Oct 2012 10:21:03 +0100
From: "Jan Beulich" 
To: "Jinsong Liu" ,"Keir Fraser" 
References: <507E7D5C02000078000A1DE6@nat28.tlf.novell.com>
	
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel ,
	Ian Jackson ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-i386-qemuu-rhel6hvm-amd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 17.10.12 at 11:04, Keir Fraser  wrote:
> On 17/10/2012 08:41, "Jan Beulich"  wrote:
> 
>> So I just now realized that a similar change was already done
>> by 23736:31683aa4bfb3 and then reverted by
>> 23760:ae10d7804168. Nothing was done subsequently to
>> address the actual problem(s). It is quite obvious that the more
>> relaxed check uncovers other bugs in the ERST code, yet looking
>> at the Linux history of the corresponding file doesn't reveal any
>> fix the lack of which would explain an outright hang (rather than
>> a crash, as I would expect to be the result of e.g. the missing
>> ioremap()-s added by 0bbba38a61283a55f2061ab3e0910c572d19f462.
>> 
>> Most of the other changes are cosmetic or pstore related, so I
>> wonder whether instead of reverting again we should try pulling
>> in this one extra fix.
>> 
>> If reverting is preferred (or turns out necessary if that second
>> fix doesn't help), we should settle on the disposition of the whole
>> APEI/ERST code, as my conclusion is that it is pretty much
>> unmaintained since its original contribution over two years ago.
> 
> Perhaps we reverted before because we decided that this advertised table
> size was a bug, and handling it just opened us to other bugs lurking in the
> table?

As just said in the response to Ian - originally, only a spec violating
vale was accepted here, whereas with the change we also accept
the proper value. The patch itself was prompted by a bug report
we got that on a spec conformant system the "ERST table is invalid"
message was seen.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 09:21:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 09:21:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOPoM-00035K-Vg; Wed, 17 Oct 2012 09:21:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOPoL-000356-Ms
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 09:21:09 +0000
Received: from [85.158.138.51:46861] by server-5.bemta-3.messagelabs.com id
	57/3C-12440-4887E705; Wed, 17 Oct 2012 09:21:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1350465666!34667072!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18864 invoked from network); 17 Oct 2012 09:21:06 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-174.messagelabs.com with SMTP;
	17 Oct 2012 09:21:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 17 Oct 2012 10:22:03 +0100
Message-Id: <507E949F02000078000A1EA5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 17 Oct 2012 10:21:03 +0100
From: "Jan Beulich" 
To: "Jinsong Liu" ,"Keir Fraser" 
References: <507E7D5C02000078000A1DE6@nat28.tlf.novell.com>
	
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel ,
	Ian Jackson ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-i386-qemuu-rhel6hvm-amd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 17.10.12 at 11:04, Keir Fraser  wrote:
> On 17/10/2012 08:41, "Jan Beulich"  wrote:
> 
>> So I just now realized that a similar change was already done
>> by 23736:31683aa4bfb3 and then reverted by
>> 23760:ae10d7804168. Nothing was done subsequently to
>> address the actual problem(s). It is quite obvious that the more
>> relaxed check uncovers other bugs in the ERST code, yet looking
>> at the Linux history of the corresponding file doesn't reveal any
>> fix the lack of which would explain an outright hang (rather than
>> a crash, as I would expect to be the result of e.g. the missing
>> ioremap()-s added by 0bbba38a61283a55f2061ab3e0910c572d19f462.
>> 
>> Most of the other changes are cosmetic or pstore related, so I
>> wonder whether instead of reverting again we should try pulling
>> in this one extra fix.
>> 
>> If reverting is preferred (or turns out necessary if that second
>> fix doesn't help), we should settle on the disposition of the whole
>> APEI/ERST code, as my conclusion is that it is pretty much
>> unmaintained since its original contribution over two years ago.
> 
> Perhaps we reverted before because we decided that this advertised table
> size was a bug, and handling it just opened us to other bugs lurking in the
> table?

As just said in the response to Ian - originally, only a spec violating
vale was accepted here, whereas with the change we also accept
the proper value. The patch itself was prompted by a bug report
we got that on a spec conformant system the "ERST table is invalid"
message was seen.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 09:32:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 09:32:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOPz1-0003JY-P1; Wed, 17 Oct 2012 09:32:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOPz0-0003JT-Q2
	for Xen-devel@lists.xensource.com; Wed, 17 Oct 2012 09:32:11 +0000
Received: from [85.158.137.99:54570] by server-3.bemta-3.messagelabs.com id
	05/67-09368-91B7E705; Wed, 17 Oct 2012 09:32:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1350466329!17167707!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23719 invoked from network); 17 Oct 2012 09:32:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 09:32:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,599,1344211200"; d="scan'208";a="15220995"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 09:32:08 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 10:32:08 +0100
Message-ID: <1350466326.2460.40.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Mukesh Rathor 
Date: Wed, 17 Oct 2012 10:32:06 +0100
In-Reply-To: <20121016170900.665acf55@mantra.us.oracle.com>
References: <20121011150113.4d525407@mantra.us.oracle.com>
	<1350032817.14806.58.camel@zakaz.uk.xensource.com>
	<20121016170900.665acf55@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V2 6/7]: PVH: balloon and grant changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-17 at 01:09 +0100, Mukesh Rathor wrote:
> > >  		gsv.version = 1;
> > >  	else
> > >  		gsv.version = 2;
> > > @@ -1083,12 +1088,24 @@ static void gnttab_request_version(void)
> > >  int gnttab_resume(void)
> > >  {
> > >  	unsigned int max_nr_gframes;
> > > +	char *kmsg = "Failed to kmalloc pages for pv in hvm grant
> > > frames\n"; 
> > >  	gnttab_request_version();
> > >  	max_nr_gframes = gnttab_max_grant_frames();
> > >  	if (max_nr_gframes < nr_grant_frames)
> > >  		return -ENOSYS;
> > >  
> > > +	/* PVH note: xen will free existing kmalloc'd mfn in
> > > +	 * XENMEM_add_to_physmap */
> > 
> > It doesn't leak it?
> > We should consider using xenballoon_alloc_pages here.
> 
> Well, it's a one time allocation of a dozen (iirc) pages, that are 
> returned back to dom heap.

>  We could use xenballoon, but for that we
> need to create vma first so we get the contigous VA,
>  then map each pte
> since xenballoon_ doesn't return contigous pages, and then populate
> physmap. I'm gonna punt it to phase II.  Lets get some working baseline
> in asap.

That's fair enough.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 09:32:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 09:32:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOPz1-0003JY-P1; Wed, 17 Oct 2012 09:32:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOPz0-0003JT-Q2
	for Xen-devel@lists.xensource.com; Wed, 17 Oct 2012 09:32:11 +0000
Received: from [85.158.137.99:54570] by server-3.bemta-3.messagelabs.com id
	05/67-09368-91B7E705; Wed, 17 Oct 2012 09:32:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1350466329!17167707!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23719 invoked from network); 17 Oct 2012 09:32:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 09:32:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,599,1344211200"; d="scan'208";a="15220995"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 09:32:08 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 10:32:08 +0100
Message-ID: <1350466326.2460.40.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Mukesh Rathor 
Date: Wed, 17 Oct 2012 10:32:06 +0100
In-Reply-To: <20121016170900.665acf55@mantra.us.oracle.com>
References: <20121011150113.4d525407@mantra.us.oracle.com>
	<1350032817.14806.58.camel@zakaz.uk.xensource.com>
	<20121016170900.665acf55@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V2 6/7]: PVH: balloon and grant changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-17 at 01:09 +0100, Mukesh Rathor wrote:
> > >  		gsv.version = 1;
> > >  	else
> > >  		gsv.version = 2;
> > > @@ -1083,12 +1088,24 @@ static void gnttab_request_version(void)
> > >  int gnttab_resume(void)
> > >  {
> > >  	unsigned int max_nr_gframes;
> > > +	char *kmsg = "Failed to kmalloc pages for pv in hvm grant
> > > frames\n"; 
> > >  	gnttab_request_version();
> > >  	max_nr_gframes = gnttab_max_grant_frames();
> > >  	if (max_nr_gframes < nr_grant_frames)
> > >  		return -ENOSYS;
> > >  
> > > +	/* PVH note: xen will free existing kmalloc'd mfn in
> > > +	 * XENMEM_add_to_physmap */
> > 
> > It doesn't leak it?
> > We should consider using xenballoon_alloc_pages here.
> 
> Well, it's a one time allocation of a dozen (iirc) pages, that are 
> returned back to dom heap.

>  We could use xenballoon, but for that we
> need to create vma first so we get the contigous VA,
>  then map each pte
> since xenballoon_ doesn't return contigous pages, and then populate
> physmap. I'm gonna punt it to phase II.  Lets get some working baseline
> in asap.

That's fair enough.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 09:33:49 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 09:33:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOQ0P-0003Q5-8u; Wed, 17 Oct 2012 09:33:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOQ0O-0003Ps-09
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 09:33:36 +0000
Received: from [85.158.138.51:36311] by server-10.bemta-3.messagelabs.com id
	37/8B-27386-F6B7E705; Wed, 17 Oct 2012 09:33:35 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1350466414!15987324!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5809 invoked from network); 17 Oct 2012 09:33:34 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 09:33:34 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so4246492eek.32
	for ; Wed, 17 Oct 2012 02:33:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=Yuh3FpVsd14UFSC6UX4ultY5ZuqZa/lIblubLOaDSVY=;
	b=O00aR0yI9Ken2U/b17jCEmZxJ87GOSmMd+D2rGoqVhbcmPOOZShC5fbOhVADLiD7mm
	TCNOrQDcQXuSyPqJjo6M8Xvv5yKd89kHoF0AhvE9rm/7GTATnbHCrJqajbPqaztFlP+V
	yQfdLHjmxvkeVm00M2xB8dnKoYAOV/txpdn5jLtouKFB7Uddze4/D6OfkLdlJR0ev4Qv
	FQZDCkKlL198VBw/i2Dob9FUBm30uzqiXB9g1izs45qXVfP6dT+kPQ/Xoa5r9YkLsCpK
	ulXTiHjpmgwLZzKDK5KWiSK3ytR0ifNLT7kmRiKGHthApP3PQoQnjJ+hEEgjhEXzemMu
	lksw==
Received: by 10.14.213.201 with SMTP id a49mr25877321eep.4.1350466414107;
	Wed, 17 Oct 2012 02:33:34 -0700 (PDT)
Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com.
	[86.183.156.141])
	by mx.google.com with ESMTPS id s1sm34017990eem.9.2012.10.17.02.33.32
	(version=SSLv3 cipher=OTHER); Wed, 17 Oct 2012 02:33:33 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Wed, 17 Oct 2012 10:33:26 +0100
From: Keir Fraser 
To: Jan Beulich ,
	"Liu, Jinsong" 
Message-ID: 
Thread-Topic: [Xen-devel] [xen-unstable bisection] complete
	test-amd64-i386-qemuu-rhel6hvm-amd
Thread-Index: Ac2sSnVZ4uEXd2OGlkmYcToiLeHqUQ==
In-Reply-To: <507E949F02000078000A1EA5@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel ,
	Ian Jackson ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-i386-qemuu-rhel6hvm-amd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/10/2012 10:21, "Jan Beulich"  wrote:

>> Perhaps we reverted before because we decided that this advertised table
>> size was a bug, and handling it just opened us to other bugs lurking in the
>> table?
> 
> As just said in the response to Ian - originally, only a spec violating
> vale was accepted here, whereas with the change we also accept
> the proper value. The patch itself was prompted by a bug report
> we got that on a spec conformant system the "ERST table is invalid"
> message was seen.

Oh dear!

 K.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 09:33:49 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 09:33:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOQ0P-0003Q5-8u; Wed, 17 Oct 2012 09:33:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOQ0O-0003Ps-09
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 09:33:36 +0000
Received: from [85.158.138.51:36311] by server-10.bemta-3.messagelabs.com id
	37/8B-27386-F6B7E705; Wed, 17 Oct 2012 09:33:35 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1350466414!15987324!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5809 invoked from network); 17 Oct 2012 09:33:34 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 09:33:34 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so4246492eek.32
	for ; Wed, 17 Oct 2012 02:33:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=Yuh3FpVsd14UFSC6UX4ultY5ZuqZa/lIblubLOaDSVY=;
	b=O00aR0yI9Ken2U/b17jCEmZxJ87GOSmMd+D2rGoqVhbcmPOOZShC5fbOhVADLiD7mm
	TCNOrQDcQXuSyPqJjo6M8Xvv5yKd89kHoF0AhvE9rm/7GTATnbHCrJqajbPqaztFlP+V
	yQfdLHjmxvkeVm00M2xB8dnKoYAOV/txpdn5jLtouKFB7Uddze4/D6OfkLdlJR0ev4Qv
	FQZDCkKlL198VBw/i2Dob9FUBm30uzqiXB9g1izs45qXVfP6dT+kPQ/Xoa5r9YkLsCpK
	ulXTiHjpmgwLZzKDK5KWiSK3ytR0ifNLT7kmRiKGHthApP3PQoQnjJ+hEEgjhEXzemMu
	lksw==
Received: by 10.14.213.201 with SMTP id a49mr25877321eep.4.1350466414107;
	Wed, 17 Oct 2012 02:33:34 -0700 (PDT)
Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com.
	[86.183.156.141])
	by mx.google.com with ESMTPS id s1sm34017990eem.9.2012.10.17.02.33.32
	(version=SSLv3 cipher=OTHER); Wed, 17 Oct 2012 02:33:33 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Wed, 17 Oct 2012 10:33:26 +0100
From: Keir Fraser 
To: Jan Beulich ,
	"Liu, Jinsong" 
Message-ID: 
Thread-Topic: [Xen-devel] [xen-unstable bisection] complete
	test-amd64-i386-qemuu-rhel6hvm-amd
Thread-Index: Ac2sSnVZ4uEXd2OGlkmYcToiLeHqUQ==
In-Reply-To: <507E949F02000078000A1EA5@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel ,
	Ian Jackson ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-i386-qemuu-rhel6hvm-amd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/10/2012 10:21, "Jan Beulich"  wrote:

>> Perhaps we reverted before because we decided that this advertised table
>> size was a bug, and handling it just opened us to other bugs lurking in the
>> table?
> 
> As just said in the response to Ian - originally, only a spec violating
> vale was accepted here, whereas with the change we also accept
> the proper value. The patch itself was prompted by a bug report
> we got that on a spec conformant system the "ERST table is invalid"
> message was seen.

Oh dear!

 K.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 09:37:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 09:37:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOQ4B-0003dL-A1; Wed, 17 Oct 2012 09:37:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOQ2W-0003ZC-DF
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 09:35:48 +0000
Received: from [85.158.139.83:5323] by server-9.bemta-5.messagelabs.com id
	74/D0-23053-3FB7E705; Wed, 17 Oct 2012 09:35:47 +0000
X-Env-Sender: cloudvirtual@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1350466545!35510503!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=2.4 required=7.0 tests=FROM_EXCESS_BASE64,
	HTML_20_30,HTML_MESSAGE,MIME_BASE64_TEXT,MIME_BOUND_NEXTPART,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6843 invoked from network); 17 Oct 2012 09:35:46 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 09:35:46 -0000
Received: by mail-pb0-f45.google.com with SMTP id rp2so7033370pbb.32
	for ; Wed, 17 Oct 2012 02:35:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-qq-ssf:x-has-attach:x-qq-business-origin:x-originating-ip
	:x-qq-style:x-qq-mid:from:to:subject:mime-version:content-type
	:content-transfer-encoding:date:x-priority:message-id:x-qq-mime
	:x-mailer:x-qq-mailer;
	bh=GIo1ssvAmiaSgRU5m3GhDGjJl5Bn1IbwS6D9w/0IKt8=;
	b=ZiS4NPHrh/cZfn1iuyMlfstVNb5HnFMheSDJoJFQbqm1693xPU28W1NXuHTDERwvhh
	SW9SkrDpHA8toSHzNf66nQBvF9DiT/l6cyOReinE9/cqrzpK8HKkIdnW/HjRqdvoCdDL
	bBIM8cqVN0iBGDHBsSQKt2oRBG41wP17BW14WinHXnpumLDeUduX6RgzVVWSxId6mByU
	IcnG5Q0KPAreiLfyvszG9eBL3Y7UMjYjocwWXwffyMO1YiCl58xCeUM3EAu1HR/e45xt
	N2A+/5urGRz4ApK5ggqvWj1yE4uBVAS8f7ySEIQ0F6gk7MwQ/jamIJNlgQ+vMduqBGa8
	J2Qg==
Received: by 10.68.237.232 with SMTP id vf8mr54111795pbc.65.1350466544422;
	Wed, 17 Oct 2012 02:35:44 -0700 (PDT)
Received: from smtpbg297.qq.com (smtpbg297.qq.com. [184.105.67.100])
	by mx.google.com with ESMTPS id bp7sm12327458pab.33.2012.10.17.02.35.43
	(version=SSLv3 cipher=OTHER); Wed, 17 Oct 2012 02:35:43 -0700 (PDT)
X-QQ-SSF: 00000000000000F0000000000000000
X-HAS-ATTACH: no
X-QQ-BUSINESS-ORIGIN: 2
X-Originating-IP: 61.148.163.108
X-QQ-STYLE: 
X-QQ-mid: webmail554t1350466539t8012501
From: "=?ISO-8859-1?B?Y2xvdWR2aXJ0dWFs?=" 
To: "=?ISO-8859-1?B?eGVuLWRldmVs?=" 
Mime-Version: 1.0
Date: Wed, 17 Oct 2012 17:35:39 +0800
X-Priority: 3
Message-ID: 
X-QQ-MIME: TCMime 1.0 by Tencent
X-Mailer: QQMail 2.x
X-QQ-Mailer: QQMail 2.x
X-Mailman-Approved-At: Wed, 17 Oct 2012 09:37:29 +0000
Subject: [Xen-devel] Grant table in HVM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============7410650800952023278=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.

--===============7410650800952023278==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_507E7BEB_D67F76A0_34E687FC"
Content-Transfer-Encoding: 8Bit

This is a multi-part message in MIME format.

------=_NextPart_507E7BEB_D67F76A0_34E687FC
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: base64

RG9lcyBncmFudCB0YWJsZSB3b3JrIGluIEhWTSBlbnZpcm9ubWVudD8gT3IgaXMgdGhlcmUg
YW55IG90aGVyIHdheSB0byBzaGFyZSBtZW1vcnkgYmV0d2VlbiBIVk0gdmlydHVhbCBtYWNo
aW5lcz8gVGhhbmtzIQ0KDQoNClRoYW5rcywNCkxlaQ==

------=_NextPart_507E7BEB_D67F76A0_34E687FC
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: base64

PGZvbnQ+PGRpdj5Eb2VzIGdyYW50IHRhYmxlIHdvcmsgaW4gSFZNIGVudmlyb25tZW50PyBP
ciBpcyB0aGVyZSBhbnkgb3RoZXIgd2F5IHRvIHNoYXJlIG1lbW9yeSBiZXR3ZWVuIEhWTSB2
aXJ0dWFsIG1hY2hpbmVzPyBUaGFua3MhPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5UaGFu
a3MsPC9kaXY+PGRpdj5MZWk8L2Rpdj48L2ZvbnQ+

------=_NextPart_507E7BEB_D67F76A0_34E687FC--



--===============7410650800952023278==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7410650800952023278==--



From xen-devel-bounces@lists.xen.org Wed Oct 17 09:37:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 09:37:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOQ4B-0003dL-A1; Wed, 17 Oct 2012 09:37:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOQ2W-0003ZC-DF
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 09:35:48 +0000
Received: from [85.158.139.83:5323] by server-9.bemta-5.messagelabs.com id
	74/D0-23053-3FB7E705; Wed, 17 Oct 2012 09:35:47 +0000
X-Env-Sender: cloudvirtual@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1350466545!35510503!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=2.4 required=7.0 tests=FROM_EXCESS_BASE64,
	HTML_20_30,HTML_MESSAGE,MIME_BASE64_TEXT,MIME_BOUND_NEXTPART,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6843 invoked from network); 17 Oct 2012 09:35:46 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 09:35:46 -0000
Received: by mail-pb0-f45.google.com with SMTP id rp2so7033370pbb.32
	for ; Wed, 17 Oct 2012 02:35:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=x-qq-ssf:x-has-attach:x-qq-business-origin:x-originating-ip
	:x-qq-style:x-qq-mid:from:to:subject:mime-version:content-type
	:content-transfer-encoding:date:x-priority:message-id:x-qq-mime
	:x-mailer:x-qq-mailer;
	bh=GIo1ssvAmiaSgRU5m3GhDGjJl5Bn1IbwS6D9w/0IKt8=;
	b=ZiS4NPHrh/cZfn1iuyMlfstVNb5HnFMheSDJoJFQbqm1693xPU28W1NXuHTDERwvhh
	SW9SkrDpHA8toSHzNf66nQBvF9DiT/l6cyOReinE9/cqrzpK8HKkIdnW/HjRqdvoCdDL
	bBIM8cqVN0iBGDHBsSQKt2oRBG41wP17BW14WinHXnpumLDeUduX6RgzVVWSxId6mByU
	IcnG5Q0KPAreiLfyvszG9eBL3Y7UMjYjocwWXwffyMO1YiCl58xCeUM3EAu1HR/e45xt
	N2A+/5urGRz4ApK5ggqvWj1yE4uBVAS8f7ySEIQ0F6gk7MwQ/jamIJNlgQ+vMduqBGa8
	J2Qg==
Received: by 10.68.237.232 with SMTP id vf8mr54111795pbc.65.1350466544422;
	Wed, 17 Oct 2012 02:35:44 -0700 (PDT)
Received: from smtpbg297.qq.com (smtpbg297.qq.com. [184.105.67.100])
	by mx.google.com with ESMTPS id bp7sm12327458pab.33.2012.10.17.02.35.43
	(version=SSLv3 cipher=OTHER); Wed, 17 Oct 2012 02:35:43 -0700 (PDT)
X-QQ-SSF: 00000000000000F0000000000000000
X-HAS-ATTACH: no
X-QQ-BUSINESS-ORIGIN: 2
X-Originating-IP: 61.148.163.108
X-QQ-STYLE: 
X-QQ-mid: webmail554t1350466539t8012501
From: "=?ISO-8859-1?B?Y2xvdWR2aXJ0dWFs?=" 
To: "=?ISO-8859-1?B?eGVuLWRldmVs?=" 
Mime-Version: 1.0
Date: Wed, 17 Oct 2012 17:35:39 +0800
X-Priority: 3
Message-ID: 
X-QQ-MIME: TCMime 1.0 by Tencent
X-Mailer: QQMail 2.x
X-QQ-Mailer: QQMail 2.x
X-Mailman-Approved-At: Wed, 17 Oct 2012 09:37:29 +0000
Subject: [Xen-devel] Grant table in HVM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============7410650800952023278=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.

--===============7410650800952023278==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_507E7BEB_D67F76A0_34E687FC"
Content-Transfer-Encoding: 8Bit

This is a multi-part message in MIME format.

------=_NextPart_507E7BEB_D67F76A0_34E687FC
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: base64

RG9lcyBncmFudCB0YWJsZSB3b3JrIGluIEhWTSBlbnZpcm9ubWVudD8gT3IgaXMgdGhlcmUg
YW55IG90aGVyIHdheSB0byBzaGFyZSBtZW1vcnkgYmV0d2VlbiBIVk0gdmlydHVhbCBtYWNo
aW5lcz8gVGhhbmtzIQ0KDQoNClRoYW5rcywNCkxlaQ==

------=_NextPart_507E7BEB_D67F76A0_34E687FC
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: base64

PGZvbnQ+PGRpdj5Eb2VzIGdyYW50IHRhYmxlIHdvcmsgaW4gSFZNIGVudmlyb25tZW50PyBP
ciBpcyB0aGVyZSBhbnkgb3RoZXIgd2F5IHRvIHNoYXJlIG1lbW9yeSBiZXR3ZWVuIEhWTSB2
aXJ0dWFsIG1hY2hpbmVzPyBUaGFua3MhPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5UaGFu
a3MsPC9kaXY+PGRpdj5MZWk8L2Rpdj48L2ZvbnQ+

------=_NextPart_507E7BEB_D67F76A0_34E687FC--



--===============7410650800952023278==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7410650800952023278==--



From xen-devel-bounces@lists.xen.org Wed Oct 17 09:43:38 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 09:43:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOQ9n-0003nj-3P; Wed, 17 Oct 2012 09:43:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOQ9m-0003nb-6g; Wed, 17 Oct 2012 09:43:18 +0000
Received: from [85.158.139.83:19529] by server-6.bemta-5.messagelabs.com id
	16/02-32589-5BD7E705; Wed, 17 Oct 2012 09:43:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1350466994!30700538!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9518 invoked from network); 17 Oct 2012 09:43:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 09:43:14 -0000
X-IronPort-AV: E=Sophos;i="4.80,599,1344211200"; d="scan'208";a="15221230"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 09:43:14 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 10:43:14 +0100
Message-ID: <1350466992.2460.47.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: kk s 
Date: Wed, 17 Oct 2012 10:43:12 +0100
In-Reply-To: 
References: 
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-users@lists.xen.org" ,
	Konrad Rzeszutek Wilk ,
	Stefano Stabellini ,
	xen-devel 
Subject: Re: [Xen-devel] [Xen-users] Fedora 17 Dom-U booting issue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Adding xen-devel and the relevant maintainers.

On Tue, 2012-10-16 at 20:24 +0100, kk s wrote:
> Hi Folks,
> 
> 
> I have upgraded Fedora 16 to 17 on one of Xen HVM Dom-U and it refuses
> to boot fine and getting the below error on console,
> 
> 
> --------
> Booting 'Fedora (3.6.1-1.fc17.x86_64)'
> 
> 
> Loading Fedora (3.6.1-1.fc17.x86_64)
> Loading initial ramdisk ...
> [   0.000000] Cannot get hvm parameter 18: -22!

HVM parameter 18 is HVM_PARAM_CONSOLE_EVTCHN.

I'm not sure it's related but commit 5842f5768599 "xen/hvc: Check
HVM_PARAM_CONSOLE_[EVTCHN|PFN] for correctness." looks a bit dogy to me,
in particular:
+       /*
+        * If the toolstack (or the hypervisor) hasn't set these values, the
+        * default value is 0. Even though mfn = 0 and evtchn = 0 are
+        * theoretically correct values, in practice they never are and they
+        * mean that a legacy toolstack hasn't initialized the pv console correc
+        */

The only reason 0 isn't used is pure coincidence because libxl (and
presumably xend) do:
    state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, state->store_domid);
    state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, state->console_domid);

so the store happens to become port 0 and the console port 1, but I
think relying on this never changing is pretty fragile.

If this is being relied on then I suggest that a patch to the hypervisor
to reject port 0 as a console port would be wise in case someone decides
to refactor this code and inadvertently changes the order of the
allocation. At the same time perhaps making the default be some invalid
port number on the hypervisor side would be a good idea for future
proofing.


> ---------
> 
> 
> The dom0 is running with Xen 3.4.3.
> 
> 
> Any help much appreciated!
> 
> 





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 09:43:38 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 09:43:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOQ9n-0003nj-3P; Wed, 17 Oct 2012 09:43:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOQ9m-0003nb-6g; Wed, 17 Oct 2012 09:43:18 +0000
Received: from [85.158.139.83:19529] by server-6.bemta-5.messagelabs.com id
	16/02-32589-5BD7E705; Wed, 17 Oct 2012 09:43:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1350466994!30700538!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9518 invoked from network); 17 Oct 2012 09:43:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 09:43:14 -0000
X-IronPort-AV: E=Sophos;i="4.80,599,1344211200"; d="scan'208";a="15221230"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 09:43:14 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 10:43:14 +0100
Message-ID: <1350466992.2460.47.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: kk s 
Date: Wed, 17 Oct 2012 10:43:12 +0100
In-Reply-To: 
References: 
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-users@lists.xen.org" ,
	Konrad Rzeszutek Wilk ,
	Stefano Stabellini ,
	xen-devel 
Subject: Re: [Xen-devel] [Xen-users] Fedora 17 Dom-U booting issue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Adding xen-devel and the relevant maintainers.

On Tue, 2012-10-16 at 20:24 +0100, kk s wrote:
> Hi Folks,
> 
> 
> I have upgraded Fedora 16 to 17 on one of Xen HVM Dom-U and it refuses
> to boot fine and getting the below error on console,
> 
> 
> --------
> Booting 'Fedora (3.6.1-1.fc17.x86_64)'
> 
> 
> Loading Fedora (3.6.1-1.fc17.x86_64)
> Loading initial ramdisk ...
> [   0.000000] Cannot get hvm parameter 18: -22!

HVM parameter 18 is HVM_PARAM_CONSOLE_EVTCHN.

I'm not sure it's related but commit 5842f5768599 "xen/hvc: Check
HVM_PARAM_CONSOLE_[EVTCHN|PFN] for correctness." looks a bit dogy to me,
in particular:
+       /*
+        * If the toolstack (or the hypervisor) hasn't set these values, the
+        * default value is 0. Even though mfn = 0 and evtchn = 0 are
+        * theoretically correct values, in practice they never are and they
+        * mean that a legacy toolstack hasn't initialized the pv console correc
+        */

The only reason 0 isn't used is pure coincidence because libxl (and
presumably xend) do:
    state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, state->store_domid);
    state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, state->console_domid);

so the store happens to become port 0 and the console port 1, but I
think relying on this never changing is pretty fragile.

If this is being relied on then I suggest that a patch to the hypervisor
to reject port 0 as a console port would be wise in case someone decides
to refactor this code and inadvertently changes the order of the
allocation. At the same time perhaps making the default be some invalid
port number on the hypervisor side would be a good idea for future
proofing.


> ---------
> 
> 
> The dom0 is running with Xen 3.4.3.
> 
> 
> Any help much appreciated!
> 
> 





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 09:44:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 09:44:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOQBA-0003x0-7I; Wed, 17 Oct 2012 09:44:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOQB8-0003wm-E0
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 09:44:42 +0000
Received: from [85.158.138.51:65470] by server-5.bemta-3.messagelabs.com id
	0C/D5-12440-90E7E705; Wed, 17 Oct 2012 09:44:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1350467080!34628516!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19748 invoked from network); 17 Oct 2012 09:44:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 09:44:40 -0000
X-IronPort-AV: E=Sophos;i="4.80,599,1344211200"; d="scan'208";a="15221274"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 09:44:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 10:44:39 +0100
Message-ID: <1350467077.2460.49.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: cloudvirtual 
Date: Wed, 17 Oct 2012 10:44:37 +0100
In-Reply-To: 
References: 
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel 
Subject: Re: [Xen-devel] Grant table in HVM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-17 at 10:35 +0100, cloudvirtual wrote:
> Does grant table work in HVM environment? Or is there any other way to
> share memory between HVM virtual machines? Thanks!

http://wiki.xen.org/wiki/Asking_Xen_Devel_Questions

Please do some research before asking questions which can be trivially
answered with a search engine and/or grep.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 09:44:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 09:44:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOQBA-0003x0-7I; Wed, 17 Oct 2012 09:44:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOQB8-0003wm-E0
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 09:44:42 +0000
Received: from [85.158.138.51:65470] by server-5.bemta-3.messagelabs.com id
	0C/D5-12440-90E7E705; Wed, 17 Oct 2012 09:44:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1350467080!34628516!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19748 invoked from network); 17 Oct 2012 09:44:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 09:44:40 -0000
X-IronPort-AV: E=Sophos;i="4.80,599,1344211200"; d="scan'208";a="15221274"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 09:44:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 10:44:39 +0100
Message-ID: <1350467077.2460.49.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: cloudvirtual 
Date: Wed, 17 Oct 2012 10:44:37 +0100
In-Reply-To: 
References: 
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel 
Subject: Re: [Xen-devel] Grant table in HVM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-17 at 10:35 +0100, cloudvirtual wrote:
> Does grant table work in HVM environment? Or is there any other way to
> share memory between HVM virtual machines? Thanks!

http://wiki.xen.org/wiki/Asking_Xen_Devel_Questions

Please do some research before asking questions which can be trivially
answered with a search engine and/or grep.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 09:54:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 09:54:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOQKl-0004Kz-Ce; Wed, 17 Oct 2012 09:54:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOQKj-0004Kt-Pi
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 09:54:38 +0000
Received: from [85.158.137.99:39002] by server-2.bemta-3.messagelabs.com id
	76/64-00604-C508E705; Wed, 17 Oct 2012 09:54:36 +0000
X-Env-Sender: lersek@redhat.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1350467673!16847610!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTgyMzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20514 invoked from network); 17 Oct 2012 09:54:34 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-3.tower-217.messagelabs.com with SMTP;
	17 Oct 2012 09:54:34 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q9H9sTr2018896
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Oct 2012 05:54:29 -0400
Received: from lacos-laptop.usersys.redhat.com (vpn1-4-31.ams2.redhat.com
	[10.36.4.31])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q9H9sPPj003326; Wed, 17 Oct 2012 05:54:25 -0400
From: Laszlo Ersek 
To: JBeulich@suse.com, andrew.cooper3@citrix.com, jeremy@goop.org,
	konrad.wilk@oracle.com, xen-devel@lists.xen.org
Date: Wed, 17 Oct 2012 11:55:55 +0200
Message-Id: <1350467755-4825-1-git-send-email-lersek@redhat.com>
In-Reply-To: <507E76BC02000078000A1DCD@nat28.tlf.novell.com>
References: <507E76BC02000078000A1DCD@nat28.tlf.novell.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Subject: [Xen-devel] [PATCH v2] xen PV passthru: assign SR-IOV virtual
	functions to separate virtual slots
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

VFs are reported as single-function devices in PCI_HEADER_TYPE, which
causes pci_scan_slot() in the PV domU to skip all VFs beyond #0 in the
pciback-provided slot. Avoid this by assigning each VF to a separate
virtual slot.

Signed-off-by: Laszlo Ersek 
---
v1->v2:
* avoid extra indentation
* make sure virtual functions are assigned with func=0

 drivers/xen/xen-pciback/vpci.c |   14 ++++++++++----
 1 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/xen/xen-pciback/vpci.c b/drivers/xen/xen-pciback/vpci.c
index 46d140b..0f478ac 100644
--- a/drivers/xen/xen-pciback/vpci.c
+++ b/drivers/xen/xen-pciback/vpci.c
@@ -89,9 +89,15 @@ static int __xen_pcibk_add_pci_dev(struct xen_pcibk_device *pdev,
 
 	mutex_lock(&vpci_dev->lock);
 
-	/* Keep multi-function devices together on the virtual PCI bus */
-	for (slot = 0; slot < PCI_SLOT_MAX; slot++) {
-		if (!list_empty(&vpci_dev->dev_list[slot])) {
+	/*
+	 * Keep multi-function devices together on the virtual PCI bus, except
+	 * virtual functions.
+	 */
+	if (!dev->is_virtfn) {
+		for (slot = 0; slot < PCI_SLOT_MAX; slot++) {
+			if (list_empty(&vpci_dev->dev_list[slot]))
+				continue;
+
 			t = list_entry(list_first(&vpci_dev->dev_list[slot]),
 				       struct pci_dev_entry, list);
 
@@ -116,7 +122,7 @@ static int __xen_pcibk_add_pci_dev(struct xen_pcibk_device *pdev,
 			       pci_name(dev), slot);
 			list_add_tail(&dev_entry->list,
 				      &vpci_dev->dev_list[slot]);
-			func = PCI_FUNC(dev->devfn);
+			func = dev->is_virtfn ? 0 : PCI_FUNC(dev->devfn);
 			goto unlock;
 		}
 	}
-- 
1.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 09:54:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 09:54:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOQKl-0004Kz-Ce; Wed, 17 Oct 2012 09:54:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOQKj-0004Kt-Pi
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 09:54:38 +0000
Received: from [85.158.137.99:39002] by server-2.bemta-3.messagelabs.com id
	76/64-00604-C508E705; Wed, 17 Oct 2012 09:54:36 +0000
X-Env-Sender: lersek@redhat.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1350467673!16847610!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTgyMzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20514 invoked from network); 17 Oct 2012 09:54:34 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-3.tower-217.messagelabs.com with SMTP;
	17 Oct 2012 09:54:34 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q9H9sTr2018896
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Oct 2012 05:54:29 -0400
Received: from lacos-laptop.usersys.redhat.com (vpn1-4-31.ams2.redhat.com
	[10.36.4.31])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q9H9sPPj003326; Wed, 17 Oct 2012 05:54:25 -0400
From: Laszlo Ersek 
To: JBeulich@suse.com, andrew.cooper3@citrix.com, jeremy@goop.org,
	konrad.wilk@oracle.com, xen-devel@lists.xen.org
Date: Wed, 17 Oct 2012 11:55:55 +0200
Message-Id: <1350467755-4825-1-git-send-email-lersek@redhat.com>
In-Reply-To: <507E76BC02000078000A1DCD@nat28.tlf.novell.com>
References: <507E76BC02000078000A1DCD@nat28.tlf.novell.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Subject: [Xen-devel] [PATCH v2] xen PV passthru: assign SR-IOV virtual
	functions to separate virtual slots
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

VFs are reported as single-function devices in PCI_HEADER_TYPE, which
causes pci_scan_slot() in the PV domU to skip all VFs beyond #0 in the
pciback-provided slot. Avoid this by assigning each VF to a separate
virtual slot.

Signed-off-by: Laszlo Ersek 
---
v1->v2:
* avoid extra indentation
* make sure virtual functions are assigned with func=0

 drivers/xen/xen-pciback/vpci.c |   14 ++++++++++----
 1 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/xen/xen-pciback/vpci.c b/drivers/xen/xen-pciback/vpci.c
index 46d140b..0f478ac 100644
--- a/drivers/xen/xen-pciback/vpci.c
+++ b/drivers/xen/xen-pciback/vpci.c
@@ -89,9 +89,15 @@ static int __xen_pcibk_add_pci_dev(struct xen_pcibk_device *pdev,
 
 	mutex_lock(&vpci_dev->lock);
 
-	/* Keep multi-function devices together on the virtual PCI bus */
-	for (slot = 0; slot < PCI_SLOT_MAX; slot++) {
-		if (!list_empty(&vpci_dev->dev_list[slot])) {
+	/*
+	 * Keep multi-function devices together on the virtual PCI bus, except
+	 * virtual functions.
+	 */
+	if (!dev->is_virtfn) {
+		for (slot = 0; slot < PCI_SLOT_MAX; slot++) {
+			if (list_empty(&vpci_dev->dev_list[slot]))
+				continue;
+
 			t = list_entry(list_first(&vpci_dev->dev_list[slot]),
 				       struct pci_dev_entry, list);
 
@@ -116,7 +122,7 @@ static int __xen_pcibk_add_pci_dev(struct xen_pcibk_device *pdev,
 			       pci_name(dev), slot);
 			list_add_tail(&dev_entry->list,
 				      &vpci_dev->dev_list[slot]);
-			func = PCI_FUNC(dev->devfn);
+			func = dev->is_virtfn ? 0 : PCI_FUNC(dev->devfn);
 			goto unlock;
 		}
 	}
-- 
1.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 10:01:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 10:01:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOQRI-0004bU-84; Wed, 17 Oct 2012 10:01:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOQRG-0004bP-D8
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 10:01:22 +0000
Received: from [193.109.254.147:48931] by server-8.bemta-14.messagelabs.com id
	FE/71-16549-1F18E705; Wed, 17 Oct 2012 10:01:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1350468079!3135940!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19957 invoked from network); 17 Oct 2012 10:01:19 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-27.messagelabs.com with SMTP;
	17 Oct 2012 10:01:19 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 17 Oct 2012 11:03:36 +0100
Message-Id: <507E9E0D02000078000A1EDB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 17 Oct 2012 11:01:17 +0100
From: "Jan Beulich" 
To: ,"Laszlo Ersek" 
References: <507E76BC02000078000A1DCD@nat28.tlf.novell.com>
	<1350467755-4825-1-git-send-email-lersek@redhat.com>
In-Reply-To: <1350467755-4825-1-git-send-email-lersek@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andrew.cooper3@citrix.com, jeremy@goop.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] xen PV passthru: assign SR-IOV virtual
 functions to separate virtual slots
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 17.10.12 at 11:55, Laszlo Ersek  wrote:
> VFs are reported as single-function devices in PCI_HEADER_TYPE, which
> causes pci_scan_slot() in the PV domU to skip all VFs beyond #0 in the
> pciback-provided slot. Avoid this by assigning each VF to a separate
> virtual slot.
> 
> Signed-off-by: Laszlo Ersek 

Acked-by: Jan Beulich 

> ---
> v1->v2:
> * avoid extra indentation
> * make sure virtual functions are assigned with func=0
> 
>  drivers/xen/xen-pciback/vpci.c |   14 ++++++++++----
>  1 files changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/xen/xen-pciback/vpci.c b/drivers/xen/xen-pciback/vpci.c
> index 46d140b..0f478ac 100644
> --- a/drivers/xen/xen-pciback/vpci.c
> +++ b/drivers/xen/xen-pciback/vpci.c
> @@ -89,9 +89,15 @@ static int __xen_pcibk_add_pci_dev(struct xen_pcibk_device *pdev,
>  
>  	mutex_lock(&vpci_dev->lock);
>  
> -	/* Keep multi-function devices together on the virtual PCI bus */
> -	for (slot = 0; slot < PCI_SLOT_MAX; slot++) {
> -		if (!list_empty(&vpci_dev->dev_list[slot])) {
> +	/*
> +	 * Keep multi-function devices together on the virtual PCI bus, except
> +	 * virtual functions.
> +	 */
> +	if (!dev->is_virtfn) {
> +		for (slot = 0; slot < PCI_SLOT_MAX; slot++) {
> +			if (list_empty(&vpci_dev->dev_list[slot]))
> +				continue;
> +
>  			t = list_entry(list_first(&vpci_dev->dev_list[slot]),
>  				       struct pci_dev_entry, list);
>  
> @@ -116,7 +122,7 @@ static int __xen_pcibk_add_pci_dev(struct xen_pcibk_device *pdev,
>  			       pci_name(dev), slot);
>  			list_add_tail(&dev_entry->list,
>  				      &vpci_dev->dev_list[slot]);
> -			func = PCI_FUNC(dev->devfn);
> +			func = dev->is_virtfn ? 0 : PCI_FUNC(dev->devfn);
>  			goto unlock;
>  		}
>  	}
> -- 
> 1.7.1




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 10:01:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 10:01:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOQRI-0004bU-84; Wed, 17 Oct 2012 10:01:24 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOQRG-0004bP-D8
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 10:01:22 +0000
Received: from [193.109.254.147:48931] by server-8.bemta-14.messagelabs.com id
	FE/71-16549-1F18E705; Wed, 17 Oct 2012 10:01:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1350468079!3135940!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19957 invoked from network); 17 Oct 2012 10:01:19 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-27.messagelabs.com with SMTP;
	17 Oct 2012 10:01:19 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 17 Oct 2012 11:03:36 +0100
Message-Id: <507E9E0D02000078000A1EDB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 17 Oct 2012 11:01:17 +0100
From: "Jan Beulich" 
To: ,"Laszlo Ersek" 
References: <507E76BC02000078000A1DCD@nat28.tlf.novell.com>
	<1350467755-4825-1-git-send-email-lersek@redhat.com>
In-Reply-To: <1350467755-4825-1-git-send-email-lersek@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andrew.cooper3@citrix.com, jeremy@goop.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] xen PV passthru: assign SR-IOV virtual
 functions to separate virtual slots
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 17.10.12 at 11:55, Laszlo Ersek  wrote:
> VFs are reported as single-function devices in PCI_HEADER_TYPE, which
> causes pci_scan_slot() in the PV domU to skip all VFs beyond #0 in the
> pciback-provided slot. Avoid this by assigning each VF to a separate
> virtual slot.
> 
> Signed-off-by: Laszlo Ersek 

Acked-by: Jan Beulich 

> ---
> v1->v2:
> * avoid extra indentation
> * make sure virtual functions are assigned with func=0
> 
>  drivers/xen/xen-pciback/vpci.c |   14 ++++++++++----
>  1 files changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/xen/xen-pciback/vpci.c b/drivers/xen/xen-pciback/vpci.c
> index 46d140b..0f478ac 100644
> --- a/drivers/xen/xen-pciback/vpci.c
> +++ b/drivers/xen/xen-pciback/vpci.c
> @@ -89,9 +89,15 @@ static int __xen_pcibk_add_pci_dev(struct xen_pcibk_device *pdev,
>  
>  	mutex_lock(&vpci_dev->lock);
>  
> -	/* Keep multi-function devices together on the virtual PCI bus */
> -	for (slot = 0; slot < PCI_SLOT_MAX; slot++) {
> -		if (!list_empty(&vpci_dev->dev_list[slot])) {
> +	/*
> +	 * Keep multi-function devices together on the virtual PCI bus, except
> +	 * virtual functions.
> +	 */
> +	if (!dev->is_virtfn) {
> +		for (slot = 0; slot < PCI_SLOT_MAX; slot++) {
> +			if (list_empty(&vpci_dev->dev_list[slot]))
> +				continue;
> +
>  			t = list_entry(list_first(&vpci_dev->dev_list[slot]),
>  				       struct pci_dev_entry, list);
>  
> @@ -116,7 +122,7 @@ static int __xen_pcibk_add_pci_dev(struct xen_pcibk_device *pdev,
>  			       pci_name(dev), slot);
>  			list_add_tail(&dev_entry->list,
>  				      &vpci_dev->dev_list[slot]);
> -			func = PCI_FUNC(dev->devfn);
> +			func = dev->is_virtfn ? 0 : PCI_FUNC(dev->devfn);
>  			goto unlock;
>  		}
>  	}
> -- 
> 1.7.1




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 10:41:45 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 10:41:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOR3x-0004tt-3j; Wed, 17 Oct 2012 10:41:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOR3v-0004to-DH
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 10:41:19 +0000
Received: from [85.158.139.83:55470] by server-15.bemta-5.messagelabs.com id
	6D/32-28599-E4B8E705; Wed, 17 Oct 2012 10:41:18 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1350470473!29631393!1
X-Originating-IP: [216.32.181.186]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4078 invoked from network); 17 Oct 2012 10:41:14 -0000
Received: from ch1ehsobe006.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.186)
	by server-5.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	17 Oct 2012 10:41:14 -0000
Received: from mail214-ch1-R.bigfish.com (10.43.68.235) by
	CH1EHSOBE006.bigfish.com (10.43.70.56) with Microsoft SMTP Server id
	14.1.225.23; Wed, 17 Oct 2012 10:41:12 +0000
Received: from mail214-ch1 (localhost [127.0.0.1])	by
	mail214-ch1-R.bigfish.com (Postfix) with ESMTP id 5D6D32E01DC	for
	; Wed, 17 Oct 2012 10:41:12 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzc85fhc85dhzz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12bdh137ah1441h34h1155h)
Received: from mail214-ch1 (localhost.localdomain [127.0.0.1]) by mail214-ch1
	(MessageSwitch) id 1350470470171505_14043;
	Wed, 17 Oct 2012 10:41:10 +0000 (UTC)
Received: from CH1EHSMHS039.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.250])	by mail214-ch1.bigfish.com (Postfix) with ESMTP id
	1E6231C006A	for ;
	Wed, 17 Oct 2012 10:41:10 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS039.bigfish.com (10.43.69.248) with Microsoft SMTP Server id
	14.1.225.23; Wed, 17 Oct 2012 10:41:07 +0000
X-WSS-ID: 0MC19OF-02-9XI-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2037EC80AE	for ; Wed, 17 Oct 2012
	05:41:02 -0500 (CDT)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 17 Oct 2012 05:56:56 -0500
Received: from STOREXDAG02.amd.com (10.1.13.11) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Wed, 17 Oct 2012 05:41:05 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag02.amd.com
	(10.1.13.11) with Microsoft SMTP Server id 14.1.323.3; Wed, 17 Oct 2012
	06:41:04 -0400
Message-ID: <507E8B3F.8030801@amd.com>
Date: Wed, 17 Oct 2012 12:41:03 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" 
Content-Type: multipart/mixed; boundary="------------030605020302030609080700"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] vMCE: Implement AMD MSRs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------030605020302030609080700
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit


Implement AMD MSRs for vMCE

Signed-off-by: Christoph Egger 


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------030605020302030609080700
Content-Type: text/plain; charset="us-ascii"; name="xen_vmce.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_vmce.diff"
Content-Description: xen_vmce.diff

# User Christoph Egger
# Date 1350465050 -7200
implement AMD MSRs for vMCE

Signed-off-by: Christoph Egger 

diff -r 9181f580bc3f -r 7d79c4a86be5 xen/arch/x86/cpu/mcheck/amd_f10.c
--- a/xen/arch/x86/cpu/mcheck/amd_f10.c
+++ b/xen/arch/x86/cpu/mcheck/amd_f10.c
@@ -106,24 +106,43 @@ enum mcheck_type amd_f10_mcheck_init(str
 /* amd specific MCA MSR */
 int vmce_amd_wrmsr(struct vcpu *v, uint32_t msr, uint64_t val)
 {
-        switch (msr) {
-        case MSR_F10_MC4_MISC1:
-        case MSR_F10_MC4_MISC2:
-        case MSR_F10_MC4_MISC3:
-                break;
-        }
+	switch (msr) {
+	case MSR_F10_MC4_MISC1: /* DRAM error type */
+		v->arch.vmce.bank[1].mci_misc = val; 
+		mce_printk(MCE_VERBOSE, "MCE: wr msr %#"PRIx64"\n", val);
+		break;
+	case MSR_F10_MC4_MISC2: /* Link error type */
+	case MSR_F10_MC4_MISC3: /* L3 cache error type */
+		/* ignore write: we do not emulate link and l3 cache errors
+		 * to the guest.
+		 */
+		mce_printk(MCE_VERBOSE, "MCE: wr msr %#"PRIx64"\n", val);
+		break;
+	default:
+		return 0;
+	}
 
-        return 1;
+	return 1;
 }
 
 int vmce_amd_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t *val)
 {
-        switch (msr) {
-        case MSR_F10_MC4_MISC1:
-        case MSR_F10_MC4_MISC2:
-        case MSR_F10_MC4_MISC3:
-                break;
-        }
+	switch (msr) {
+	case MSR_F10_MC4_MISC1: /* DRAM error type */
+		*val = v->arch.vmce.bank[1].mci_misc;
+		mce_printk(MCE_VERBOSE, "MCE: rd msr %#"PRIx64"\n", *val);
+		break;
+	case MSR_F10_MC4_MISC2: /* Link error type */
+	case MSR_F10_MC4_MISC3: /* L3 cache error type */
+		/* we do not emulate link and l3 cache
+		 * errors to the guest.
+		 */
+		*val = 0;
+		mce_printk(MCE_VERBOSE, "MCE: rd msr %#"PRIx64"\n", *val);
+		break;
+	default:
+		return 0;
+	}
 
-        return 1;
+	return 1;
 }

--------------030605020302030609080700
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------030605020302030609080700--


From xen-devel-bounces@lists.xen.org Wed Oct 17 10:41:45 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 10:41:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOR3x-0004tt-3j; Wed, 17 Oct 2012 10:41:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOR3v-0004to-DH
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 10:41:19 +0000
Received: from [85.158.139.83:55470] by server-15.bemta-5.messagelabs.com id
	6D/32-28599-E4B8E705; Wed, 17 Oct 2012 10:41:18 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1350470473!29631393!1
X-Originating-IP: [216.32.181.186]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4078 invoked from network); 17 Oct 2012 10:41:14 -0000
Received: from ch1ehsobe006.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.186)
	by server-5.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	17 Oct 2012 10:41:14 -0000
Received: from mail214-ch1-R.bigfish.com (10.43.68.235) by
	CH1EHSOBE006.bigfish.com (10.43.70.56) with Microsoft SMTP Server id
	14.1.225.23; Wed, 17 Oct 2012 10:41:12 +0000
Received: from mail214-ch1 (localhost [127.0.0.1])	by
	mail214-ch1-R.bigfish.com (Postfix) with ESMTP id 5D6D32E01DC	for
	; Wed, 17 Oct 2012 10:41:12 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzc85fhc85dhzz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12bdh137ah1441h34h1155h)
Received: from mail214-ch1 (localhost.localdomain [127.0.0.1]) by mail214-ch1
	(MessageSwitch) id 1350470470171505_14043;
	Wed, 17 Oct 2012 10:41:10 +0000 (UTC)
Received: from CH1EHSMHS039.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.250])	by mail214-ch1.bigfish.com (Postfix) with ESMTP id
	1E6231C006A	for ;
	Wed, 17 Oct 2012 10:41:10 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS039.bigfish.com (10.43.69.248) with Microsoft SMTP Server id
	14.1.225.23; Wed, 17 Oct 2012 10:41:07 +0000
X-WSS-ID: 0MC19OF-02-9XI-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2037EC80AE	for ; Wed, 17 Oct 2012
	05:41:02 -0500 (CDT)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 17 Oct 2012 05:56:56 -0500
Received: from STOREXDAG02.amd.com (10.1.13.11) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Wed, 17 Oct 2012 05:41:05 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag02.amd.com
	(10.1.13.11) with Microsoft SMTP Server id 14.1.323.3; Wed, 17 Oct 2012
	06:41:04 -0400
Message-ID: <507E8B3F.8030801@amd.com>
Date: Wed, 17 Oct 2012 12:41:03 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" 
Content-Type: multipart/mixed; boundary="------------030605020302030609080700"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] vMCE: Implement AMD MSRs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------030605020302030609080700
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit


Implement AMD MSRs for vMCE

Signed-off-by: Christoph Egger 


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------030605020302030609080700
Content-Type: text/plain; charset="us-ascii"; name="xen_vmce.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_vmce.diff"
Content-Description: xen_vmce.diff

# User Christoph Egger
# Date 1350465050 -7200
implement AMD MSRs for vMCE

Signed-off-by: Christoph Egger 

diff -r 9181f580bc3f -r 7d79c4a86be5 xen/arch/x86/cpu/mcheck/amd_f10.c
--- a/xen/arch/x86/cpu/mcheck/amd_f10.c
+++ b/xen/arch/x86/cpu/mcheck/amd_f10.c
@@ -106,24 +106,43 @@ enum mcheck_type amd_f10_mcheck_init(str
 /* amd specific MCA MSR */
 int vmce_amd_wrmsr(struct vcpu *v, uint32_t msr, uint64_t val)
 {
-        switch (msr) {
-        case MSR_F10_MC4_MISC1:
-        case MSR_F10_MC4_MISC2:
-        case MSR_F10_MC4_MISC3:
-                break;
-        }
+	switch (msr) {
+	case MSR_F10_MC4_MISC1: /* DRAM error type */
+		v->arch.vmce.bank[1].mci_misc = val; 
+		mce_printk(MCE_VERBOSE, "MCE: wr msr %#"PRIx64"\n", val);
+		break;
+	case MSR_F10_MC4_MISC2: /* Link error type */
+	case MSR_F10_MC4_MISC3: /* L3 cache error type */
+		/* ignore write: we do not emulate link and l3 cache errors
+		 * to the guest.
+		 */
+		mce_printk(MCE_VERBOSE, "MCE: wr msr %#"PRIx64"\n", val);
+		break;
+	default:
+		return 0;
+	}
 
-        return 1;
+	return 1;
 }
 
 int vmce_amd_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t *val)
 {
-        switch (msr) {
-        case MSR_F10_MC4_MISC1:
-        case MSR_F10_MC4_MISC2:
-        case MSR_F10_MC4_MISC3:
-                break;
-        }
+	switch (msr) {
+	case MSR_F10_MC4_MISC1: /* DRAM error type */
+		*val = v->arch.vmce.bank[1].mci_misc;
+		mce_printk(MCE_VERBOSE, "MCE: rd msr %#"PRIx64"\n", *val);
+		break;
+	case MSR_F10_MC4_MISC2: /* Link error type */
+	case MSR_F10_MC4_MISC3: /* L3 cache error type */
+		/* we do not emulate link and l3 cache
+		 * errors to the guest.
+		 */
+		*val = 0;
+		mce_printk(MCE_VERBOSE, "MCE: rd msr %#"PRIx64"\n", *val);
+		break;
+	default:
+		return 0;
+	}
 
-        return 1;
+	return 1;
 }

--------------030605020302030609080700
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------030605020302030609080700--


From xen-devel-bounces@lists.xen.org Wed Oct 17 10:45:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 10:45:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOR7d-00051E-3S; Wed, 17 Oct 2012 10:45:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOR7b-000515-9U
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 10:45:07 +0000
Received: from [85.158.143.35:35858] by server-3.bemta-4.messagelabs.com id
	E3/85-03544-23C8E705; Wed, 17 Oct 2012 10:45:06 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1350470703!13334399!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODMwNDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18703 invoked from network); 17 Oct 2012 10:45:05 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 10:45:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,599,1344211200"; d="scan'208";a="211535049"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 10:44:32 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 06:44:31 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TOR71-0005cD-6R;
	Wed, 17 Oct 2012 11:44:31 +0100
Message-ID: <507E8AE7.8070106@eu.citrix.com>
Date: Wed, 17 Oct 2012 11:39:35 +0100
From: George Dunlap 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk 
References: 
	<20121016144537.GA10883@phenom.dumpdata.com>
In-Reply-To: <20121016144537.GA10883@phenom.dumpdata.com>
Cc: "annie.li@oracle.com" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Xen 4.3 development update, 15 Oct
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 16/10/12 15:45, Konrad Rzeszutek Wilk wrote:
>> * Multi-page net protocol (external)
>>    owner: ijc@citrix or annie.li@oracle
>>    status: Initial patches posted (by Wei Liu)
>>    expand the network ring protocol to allow multiple pages for
>>    increased throughput
> We are cleaning them up to get Ian's input. There are .. many things
> here for this TODO - there is the feature persistent grant which gives a big
> performance boost. Then there is the Wei Liu patches which need
> some rework (they were RFC). The persistent grant (which is what
> Annie is working on right now) nicely fit on top of Wei Liu's, but since
> they (the RFC patches - which split the netback into per-vif threads)
> are not yet ready - annie is looking to see if she can do some lookup
> using the old netback mechanism.
OK, so it sounds like you're actually giving an update on the persistent 
grants...?

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 10:45:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 10:45:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOR7d-00051E-3S; Wed, 17 Oct 2012 10:45:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOR7b-000515-9U
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 10:45:07 +0000
Received: from [85.158.143.35:35858] by server-3.bemta-4.messagelabs.com id
	E3/85-03544-23C8E705; Wed, 17 Oct 2012 10:45:06 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1350470703!13334399!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODMwNDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18703 invoked from network); 17 Oct 2012 10:45:05 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 10:45:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,599,1344211200"; d="scan'208";a="211535049"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 10:44:32 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 06:44:31 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TOR71-0005cD-6R;
	Wed, 17 Oct 2012 11:44:31 +0100
Message-ID: <507E8AE7.8070106@eu.citrix.com>
Date: Wed, 17 Oct 2012 11:39:35 +0100
From: George Dunlap 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk 
References: 
	<20121016144537.GA10883@phenom.dumpdata.com>
In-Reply-To: <20121016144537.GA10883@phenom.dumpdata.com>
Cc: "annie.li@oracle.com" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Xen 4.3 development update, 15 Oct
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 16/10/12 15:45, Konrad Rzeszutek Wilk wrote:
>> * Multi-page net protocol (external)
>>    owner: ijc@citrix or annie.li@oracle
>>    status: Initial patches posted (by Wei Liu)
>>    expand the network ring protocol to allow multiple pages for
>>    increased throughput
> We are cleaning them up to get Ian's input. There are .. many things
> here for this TODO - there is the feature persistent grant which gives a big
> performance boost. Then there is the Wei Liu patches which need
> some rework (they were RFC). The persistent grant (which is what
> Annie is working on right now) nicely fit on top of Wei Liu's, but since
> they (the RFC patches - which split the netback into per-vif threads)
> are not yet ready - annie is looking to see if she can do some lookup
> using the old netback mechanism.
OK, so it sounds like you're actually giving an update on the persistent 
grants...?

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 10:58:46 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 10:58:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TORKT-0005E0-TV; Wed, 17 Oct 2012 10:58:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TORKS-0005Dv-Ij
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 10:58:24 +0000
Received: from [85.158.143.99:57241] by server-3.bemta-4.messagelabs.com id
	E5/0A-03544-F4F8E705; Wed, 17 Oct 2012 10:58:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1350471502!34495499!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1636 invoked from network); 17 Oct 2012 10:58:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 10:58:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,600,1344211200"; d="scan'208";a="15223247"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 10:58:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 17 Oct 2012 11:58:22 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TORKQ-0005vQ-6C;
	Wed, 17 Oct 2012 10:58:22 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TORKQ-0008WQ-52;
	Wed, 17 Oct 2012 11:58:22 +0100
To: 
Message-ID: 
From: xen.org 
Date: Wed, 17 Oct 2012 11:58:22 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete test-amd64-amd64-pv
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

branch xen-unstable
xen branch xen-unstable
job test-amd64-amd64-pv
test xen-boot

Tree: linux git://xenbits.xen.org/linux-pvops.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 http://xenbits.xen.org/hg/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
  Bug introduced:  4fc87c2f31a0
  Bug not present: c1c549c4fe9e


  changeset:   26060:4fc87c2f31a0
  user:        Huang Ying 
  date:        Tue Oct 16 17:26:36 2012 +0200
      
      ACPI: fix APEI related table size checking
      
      On Huang Ying's machine:
      
      erst_tab->header_length == sizeof(struct acpi_table_einj)
      
      but Yinghai reported that on his machine,
      
      erst_tab->header_length == sizeof(struct acpi_table_einj) -
      sizeof(struct acpi_table_header)
      
      To make erst table size checking code works on all systems, both
      testing are treated as PASS.
      
      Same situation applies to einj_tab->header_length, so corresponding
      table size checking is changed in similar way too.
      
      Originally-by: Yinghai Lu 
      Signed-off-by: Huang Ying 
      
      - use switch() for better readability
      - add comment explaining why a formally invalid size it also being
        accepted
      - check erst_tab->header.length before even looking at
        erst_tab->header_length
      - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
      
      Signed-off-by: Jan Beulich 
      Acked-by: Keir Fraser 
      Committed-by: Jan Beulich 
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-amd64-pv.xen-boot.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 13979 fail [host=lake-frog] / 13967 [host=potato-beetle] 13964 [host=field-cricket] 13963 [host=fire-frog] 13962 [host=leaf-beetle] 13960 ok.
Failure / basis pass flights: 13979 / 13960
Tree: linux git://xenbits.xen.org/linux-pvops.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 http://xenbits.xen.org/hg/staging/xen-unstable.hg
Latest a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
Basis pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 e0e1350dfe9b
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#a938a246d34912423c560f475ccf1ce0c71d9d00-a938a246d34912423c560f475ccf1ce0c71d9d00 git://xenbits.xen.org/staging/qemu-xen-unstable.git#bacc0d302445c75f18f4c826750fb5853b60e7ca-bacc0d302445c75f18f4c826750fb5853b60e7ca git://xenbits.xen.org/staging/qemu-upstream-unstable.git#cdf4d2bb4006805f209712fbb8ed1f83127e9984-cdf4d2bb4006805f209712fbb8ed1f83127e9984 http://xenbits.xen.org/hg/staging/xen-unstable.hg#e0e1350dfe9b-4fc87c2f31a0
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
Loaded 239 nodes in revision graph
Searching for test results:
 13958 [host=lace-bug]
 13989 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
 13960 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 e0e1350dfe9b
 13967 [host=potato-beetle]
 13962 [host=leaf-beetle]
 13972 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 13963 [host=fire-frog]
 13985 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 e0e1350dfe9b
 13956 [host=bush-cricket]
 13964 [host=field-cricket]
 13994 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 13986 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 13973 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 13990 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 13979 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 13987 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 177fdda0be56
 13993 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
 13988 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 37bb894121c7
 13991 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
 13992 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
Searching for interesting versions
 Result found: flight 13960 (pass), for basis pass
 Result found: flight 13972 (fail), for basis failure
 Repro found: flight 13985 (pass), for basis pass
 Repro found: flight 13986 (fail), for basis failure
 0 revisions at a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
No revisions left to test, checking graph state.
 Result found: flight 13989 (pass), for last pass
 Result found: flight 13990 (fail), for first failure
 Repro found: flight 13991 (pass), for last pass
 Repro found: flight 13992 (fail), for first failure
 Repro found: flight 13993 (pass), for last pass
 Repro found: flight 13994 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
  Bug introduced:  4fc87c2f31a0
  Bug not present: c1c549c4fe9e

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   26060:4fc87c2f31a0
  user:        Huang Ying 
  date:        Tue Oct 16 17:26:36 2012 +0200
      
      ACPI: fix APEI related table size checking
      
      On Huang Ying's machine:
      
      erst_tab->header_length == sizeof(struct acpi_table_einj)
      
      but Yinghai reported that on his machine,
      
      erst_tab->header_length == sizeof(struct acpi_table_einj) -
      sizeof(struct acpi_table_header)
      
      To make erst table size checking code works on all systems, both
      testing are treated as PASS.
      
      Same situation applies to einj_tab->header_length, so corresponding
      table size checking is changed in similar way too.
      
      Originally-by: Yinghai Lu 
      Signed-off-by: Huang Ying 
      
      - use switch() for better readability
      - add comment explaining why a formally invalid size it also being
        accepted
      - check erst_tab->header.length before even looking at
        erst_tab->header_length
      - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
      
      Signed-off-by: Jan Beulich 
      Acked-by: Keir Fraser 
      Committed-by: Jan Beulich 
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-amd64-amd64-pv.xen-boot.{dot,ps,png,html}.
----------------------------------------
13994: tolerable ALL FAIL

flight 13994 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13994/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-amd64-pv           5 xen-boot                fail baseline untested


jobs:
 test-amd64-amd64-pv                                          fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 10:58:46 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 10:58:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TORKT-0005E0-TV; Wed, 17 Oct 2012 10:58:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TORKS-0005Dv-Ij
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 10:58:24 +0000
Received: from [85.158.143.99:57241] by server-3.bemta-4.messagelabs.com id
	E5/0A-03544-F4F8E705; Wed, 17 Oct 2012 10:58:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1350471502!34495499!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1636 invoked from network); 17 Oct 2012 10:58:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 10:58:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,600,1344211200"; d="scan'208";a="15223247"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 10:58:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 17 Oct 2012 11:58:22 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TORKQ-0005vQ-6C;
	Wed, 17 Oct 2012 10:58:22 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TORKQ-0008WQ-52;
	Wed, 17 Oct 2012 11:58:22 +0100
To: 
Message-ID: 
From: xen.org 
Date: Wed, 17 Oct 2012 11:58:22 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete test-amd64-amd64-pv
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

branch xen-unstable
xen branch xen-unstable
job test-amd64-amd64-pv
test xen-boot

Tree: linux git://xenbits.xen.org/linux-pvops.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 http://xenbits.xen.org/hg/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
  Bug introduced:  4fc87c2f31a0
  Bug not present: c1c549c4fe9e


  changeset:   26060:4fc87c2f31a0
  user:        Huang Ying 
  date:        Tue Oct 16 17:26:36 2012 +0200
      
      ACPI: fix APEI related table size checking
      
      On Huang Ying's machine:
      
      erst_tab->header_length == sizeof(struct acpi_table_einj)
      
      but Yinghai reported that on his machine,
      
      erst_tab->header_length == sizeof(struct acpi_table_einj) -
      sizeof(struct acpi_table_header)
      
      To make erst table size checking code works on all systems, both
      testing are treated as PASS.
      
      Same situation applies to einj_tab->header_length, so corresponding
      table size checking is changed in similar way too.
      
      Originally-by: Yinghai Lu 
      Signed-off-by: Huang Ying 
      
      - use switch() for better readability
      - add comment explaining why a formally invalid size it also being
        accepted
      - check erst_tab->header.length before even looking at
        erst_tab->header_length
      - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
      
      Signed-off-by: Jan Beulich 
      Acked-by: Keir Fraser 
      Committed-by: Jan Beulich 
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-amd64-pv.xen-boot.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 13979 fail [host=lake-frog] / 13967 [host=potato-beetle] 13964 [host=field-cricket] 13963 [host=fire-frog] 13962 [host=leaf-beetle] 13960 ok.
Failure / basis pass flights: 13979 / 13960
Tree: linux git://xenbits.xen.org/linux-pvops.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 http://xenbits.xen.org/hg/staging/xen-unstable.hg
Latest a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
Basis pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 e0e1350dfe9b
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#a938a246d34912423c560f475ccf1ce0c71d9d00-a938a246d34912423c560f475ccf1ce0c71d9d00 git://xenbits.xen.org/staging/qemu-xen-unstable.git#bacc0d302445c75f18f4c826750fb5853b60e7ca-bacc0d302445c75f18f4c826750fb5853b60e7ca git://xenbits.xen.org/staging/qemu-upstream-unstable.git#cdf4d2bb4006805f209712fbb8ed1f83127e9984-cdf4d2bb4006805f209712fbb8ed1f83127e9984 http://xenbits.xen.org/hg/staging/xen-unstable.hg#e0e1350dfe9b-4fc87c2f31a0
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
Loaded 239 nodes in revision graph
Searching for test results:
 13958 [host=lace-bug]
 13989 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
 13960 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 e0e1350dfe9b
 13967 [host=potato-beetle]
 13962 [host=leaf-beetle]
 13972 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 13963 [host=fire-frog]
 13985 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 e0e1350dfe9b
 13956 [host=bush-cricket]
 13964 [host=field-cricket]
 13994 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 13986 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 13973 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 13990 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 13979 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 13987 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 177fdda0be56
 13993 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
 13988 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 37bb894121c7
 13991 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
 13992 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
Searching for interesting versions
 Result found: flight 13960 (pass), for basis pass
 Result found: flight 13972 (fail), for basis failure
 Repro found: flight 13985 (pass), for basis pass
 Repro found: flight 13986 (fail), for basis failure
 0 revisions at a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
No revisions left to test, checking graph state.
 Result found: flight 13989 (pass), for last pass
 Result found: flight 13990 (fail), for first failure
 Repro found: flight 13991 (pass), for last pass
 Repro found: flight 13992 (fail), for first failure
 Repro found: flight 13993 (pass), for last pass
 Repro found: flight 13994 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
  Bug introduced:  4fc87c2f31a0
  Bug not present: c1c549c4fe9e

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   26060:4fc87c2f31a0
  user:        Huang Ying 
  date:        Tue Oct 16 17:26:36 2012 +0200
      
      ACPI: fix APEI related table size checking
      
      On Huang Ying's machine:
      
      erst_tab->header_length == sizeof(struct acpi_table_einj)
      
      but Yinghai reported that on his machine,
      
      erst_tab->header_length == sizeof(struct acpi_table_einj) -
      sizeof(struct acpi_table_header)
      
      To make erst table size checking code works on all systems, both
      testing are treated as PASS.
      
      Same situation applies to einj_tab->header_length, so corresponding
      table size checking is changed in similar way too.
      
      Originally-by: Yinghai Lu 
      Signed-off-by: Huang Ying 
      
      - use switch() for better readability
      - add comment explaining why a formally invalid size it also being
        accepted
      - check erst_tab->header.length before even looking at
        erst_tab->header_length
      - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
      
      Signed-off-by: Jan Beulich 
      Acked-by: Keir Fraser 
      Committed-by: Jan Beulich 
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-amd64-amd64-pv.xen-boot.{dot,ps,png,html}.
----------------------------------------
13994: tolerable ALL FAIL

flight 13994 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13994/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-amd64-pv           5 xen-boot                fail baseline untested


jobs:
 test-amd64-amd64-pv                                          fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 11:22:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 11:22:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TORhF-0005Rx-Ge; Wed, 17 Oct 2012 11:21:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TORhE-0005Rs-Cm
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 11:21:56 +0000
Received: from [85.158.138.51:10024] by server-8.bemta-3.messagelabs.com id
	68/7D-10525-3D49E705; Wed, 17 Oct 2012 11:21:55 +0000
X-Env-Sender: abb@gremwell.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1350472913!28365873!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3364 invoked from network); 17 Oct 2012 11:21:54 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 11:21:54 -0000
Received: by mail-vb0-f45.google.com with SMTP id p1so8851696vbi.32
	for ; Wed, 17 Oct 2012 04:21:53 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:cc:content-type
	:x-gm-message-state;
	bh=k3GbeLDeiKfiDv0Mq4wLePjXIuSKjQaRfCKWcaf3U0Q=;
	b=fhgandUHARRSquUT77+YUMasR/N8fKH/phk7hf5BVTSrvlEulOjlasowsnivD5EbFD
	kE8f8SC94TgZKMD5P0Uk1BPjB4pT4/WukolENl8NzyG8ZjbQVEOXhqtc3nzxxPy9lnOs
	WBohtb6Fexmlwm8Ch1lTOSotjYJOdfws5cMmelFWBGZbpv+rLdNcZmXGx2fjixYSP+dD
	eZXMMNncVxb0uQzJ3bh/LDa63NZE1eLbE6JfHRJusIsc0NhWTSfMEJ3ukZnZjt9b47BK
	Ob5ToTPAfmyr7wGnmBbrwpxNCeSoioqxLvrcyS42XRJtxIIa3u+B8th0b/6+I0imEgnw
	VUbg==
MIME-Version: 1.0
Received: by 10.58.161.41 with SMTP id xp9mr4850981veb.56.1350472913210; Wed,
	17 Oct 2012 04:21:53 -0700 (PDT)
Received: by 10.58.155.226 with HTTP; Wed, 17 Oct 2012 04:21:53 -0700 (PDT)
Date: Wed, 17 Oct 2012 13:21:53 +0200
Message-ID: 
From: Alexandre Bezroutchko 
To: nathanael@polymorpheus.com
X-Gm-Message-State: ALoCoQm3RnIo2GYE0k4mPmeKIp5UrMqCKgFYMo93T1s7ZEDk7exi5Wd8pnpcjvD1KpwkGCCb6SXS
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] pvusb with kernel 3.4 / 3.6
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============2873797212543964579=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2873797212543964579==
Content-Type: multipart/alternative; boundary=047d7b6dc9aa454ec404cc3f7a35

--047d7b6dc9aa454ec404cc3f7a35
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Nathanael,

Is it possible to use your patch [1] on newer kernels? I've tried to use it
but most devices are not usable and some cause kernel crash. Detailed
description of an attempt on kernel 3.4 is at [2] and (somewhat less
detailed) with 3.6 is at [3]. I'm motivated to make it work, any ideas what
can be done to fix this issue? Please tell me if you need any additional
info.

I've added xen-devel and Pasi K=E4rkk=E4inen into Cc, hope this is ok.

Regards,
Alex

[1] http://lists.xen.org/archives/html/xen-devel/2012-02/msg00571.html
[2] https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/3IAf7f8lz2UJ
[3] https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/rNmVAOXX4dYJ

--047d7b6dc9aa454ec404cc3f7a35
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Nathanael,

Is it possible to use your patch [1] on newer kernels?=
 I've tried to use it but most devices are not usable and some cause ke=
rnel crash. Detailed description of an attempt on kernel 3.4 is at [2] and =
(somewhat less detailed) with 3.6 is at [3]. I'm motivated to make it w=
ork, any ideas what can be done to fix this issue? Please tell me if you ne=
ed any additional info.



I've added xen-devel and Pasi K=E4rkk=E4inen into Cc, hope this is =
ok.

Regards,
Alex

[1] http://lists.x=
en.org/archives/html/xen-devel/2012-02/msg00571.html

[2] https://groups.google.com/d/msg/qubes-devel/4AK=
ulABh2Jc/3IAf7f8lz2UJ

[3] https://groups.google.com/d/msg/qubes-devel/4AK=
ulABh2Jc/rNmVAOXX4dYJ



--047d7b6dc9aa454ec404cc3f7a35--


--===============2873797212543964579==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2873797212543964579==--


From xen-devel-bounces@lists.xen.org Wed Oct 17 11:22:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 11:22:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TORhF-0005Rx-Ge; Wed, 17 Oct 2012 11:21:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TORhE-0005Rs-Cm
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 11:21:56 +0000
Received: from [85.158.138.51:10024] by server-8.bemta-3.messagelabs.com id
	68/7D-10525-3D49E705; Wed, 17 Oct 2012 11:21:55 +0000
X-Env-Sender: abb@gremwell.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1350472913!28365873!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3364 invoked from network); 17 Oct 2012 11:21:54 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 11:21:54 -0000
Received: by mail-vb0-f45.google.com with SMTP id p1so8851696vbi.32
	for ; Wed, 17 Oct 2012 04:21:53 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:cc:content-type
	:x-gm-message-state;
	bh=k3GbeLDeiKfiDv0Mq4wLePjXIuSKjQaRfCKWcaf3U0Q=;
	b=fhgandUHARRSquUT77+YUMasR/N8fKH/phk7hf5BVTSrvlEulOjlasowsnivD5EbFD
	kE8f8SC94TgZKMD5P0Uk1BPjB4pT4/WukolENl8NzyG8ZjbQVEOXhqtc3nzxxPy9lnOs
	WBohtb6Fexmlwm8Ch1lTOSotjYJOdfws5cMmelFWBGZbpv+rLdNcZmXGx2fjixYSP+dD
	eZXMMNncVxb0uQzJ3bh/LDa63NZE1eLbE6JfHRJusIsc0NhWTSfMEJ3ukZnZjt9b47BK
	Ob5ToTPAfmyr7wGnmBbrwpxNCeSoioqxLvrcyS42XRJtxIIa3u+B8th0b/6+I0imEgnw
	VUbg==
MIME-Version: 1.0
Received: by 10.58.161.41 with SMTP id xp9mr4850981veb.56.1350472913210; Wed,
	17 Oct 2012 04:21:53 -0700 (PDT)
Received: by 10.58.155.226 with HTTP; Wed, 17 Oct 2012 04:21:53 -0700 (PDT)
Date: Wed, 17 Oct 2012 13:21:53 +0200
Message-ID: 
From: Alexandre Bezroutchko 
To: nathanael@polymorpheus.com
X-Gm-Message-State: ALoCoQm3RnIo2GYE0k4mPmeKIp5UrMqCKgFYMo93T1s7ZEDk7exi5Wd8pnpcjvD1KpwkGCCb6SXS
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] pvusb with kernel 3.4 / 3.6
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============2873797212543964579=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2873797212543964579==
Content-Type: multipart/alternative; boundary=047d7b6dc9aa454ec404cc3f7a35

--047d7b6dc9aa454ec404cc3f7a35
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Nathanael,

Is it possible to use your patch [1] on newer kernels? I've tried to use it
but most devices are not usable and some cause kernel crash. Detailed
description of an attempt on kernel 3.4 is at [2] and (somewhat less
detailed) with 3.6 is at [3]. I'm motivated to make it work, any ideas what
can be done to fix this issue? Please tell me if you need any additional
info.

I've added xen-devel and Pasi K=E4rkk=E4inen into Cc, hope this is ok.

Regards,
Alex

[1] http://lists.xen.org/archives/html/xen-devel/2012-02/msg00571.html
[2] https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/3IAf7f8lz2UJ
[3] https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/rNmVAOXX4dYJ

--047d7b6dc9aa454ec404cc3f7a35
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Nathanael,

Is it possible to use your patch [1] on newer kernels?=
 I've tried to use it but most devices are not usable and some cause ke=
rnel crash. Detailed description of an attempt on kernel 3.4 is at [2] and =
(somewhat less detailed) with 3.6 is at [3]. I'm motivated to make it w=
ork, any ideas what can be done to fix this issue? Please tell me if you ne=
ed any additional info.



I've added xen-devel and Pasi K=E4rkk=E4inen into Cc, hope this is =
ok.

Regards,
Alex

[1] http://lists.x=
en.org/archives/html/xen-devel/2012-02/msg00571.html

[2] https://groups.google.com/d/msg/qubes-devel/4AK=
ulABh2Jc/3IAf7f8lz2UJ

[3] https://groups.google.com/d/msg/qubes-devel/4AK=
ulABh2Jc/rNmVAOXX4dYJ



--047d7b6dc9aa454ec404cc3f7a35--


--===============2873797212543964579==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2873797212543964579==--


From xen-devel-bounces@lists.xen.org Wed Oct 17 11:32:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 11:32:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TORr0-0005bY-LS; Wed, 17 Oct 2012 11:32:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TORqz-0005bT-EU
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 11:32:01 +0000
Received: from [85.158.139.211:57881] by server-14.bemta-5.messagelabs.com id
	33/0E-24068-0379E705; Wed, 17 Oct 2012 11:32:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1350473519!22692475!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5664 invoked from network); 17 Oct 2012 11:31:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 11:31:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,600,1344211200"; d="scan'208";a="15223926"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 11:31:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 12:31:59 +0100
Message-ID: <1350473518.2460.58.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 17 Oct 2012 12:31:58 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	linux-kernel ,
	xen-devel 
Subject: [Xen-devel] [PATCH V2 0/6] arm: implement ballooning and privcmd
 foreign mappings based on x86 PVH
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This series is much reduced after rebasing onto V2 of the X86 PVH
patches, thanks Mukesh.

The baseline is v3.7-rc1 + "xen: build fixes and interface
tweaks" (posted this morning) and the PVH V2 patches from Mukesh.

With this series I can build a guest on Xen ARM.

The final patch requires that XENMEM_add_to_physmap_range be implemented
for x86 on the hypervisor side. For inspiration the ARM version can be
found at <1350314444-17148-1-git-send-email-ian.campbell@citrix.com>
(and will likely be in xen-unstable soon).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 11:32:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 11:32:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TORr0-0005bY-LS; Wed, 17 Oct 2012 11:32:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TORqz-0005bT-EU
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 11:32:01 +0000
Received: from [85.158.139.211:57881] by server-14.bemta-5.messagelabs.com id
	33/0E-24068-0379E705; Wed, 17 Oct 2012 11:32:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1350473519!22692475!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5664 invoked from network); 17 Oct 2012 11:31:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 11:31:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,600,1344211200"; d="scan'208";a="15223926"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 11:31:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 12:31:59 +0100
Message-ID: <1350473518.2460.58.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 17 Oct 2012 12:31:58 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	linux-kernel ,
	xen-devel 
Subject: [Xen-devel] [PATCH V2 0/6] arm: implement ballooning and privcmd
 foreign mappings based on x86 PVH
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This series is much reduced after rebasing onto V2 of the X86 PVH
patches, thanks Mukesh.

The baseline is v3.7-rc1 + "xen: build fixes and interface
tweaks" (posted this morning) and the PVH V2 patches from Mukesh.

With this series I can build a guest on Xen ARM.

The final patch requires that XENMEM_add_to_physmap_range be implemented
for x86 on the hypervisor side. For inspiration the ARM version can be
found at <1350314444-17148-1-git-send-email-ian.campbell@citrix.com>
(and will likely be in xen-unstable soon).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 11:32:35 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 11:32:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TORrL-0005e7-9h; Wed, 17 Oct 2012 11:32:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TORrJ-0005d5-Um
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 11:32:22 +0000
Received: from [85.158.138.51:38165] by server-13.bemta-3.messagelabs.com id
	0E/50-26794-5479E705; Wed, 17 Oct 2012 11:32:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1350473534!26772435!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzcwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9440 invoked from network); 17 Oct 2012 11:32:18 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 11:32:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,600,1344211200"; d="scan'208";a="41487902"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 11:32:13 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 07:32:13 -0400
Received: from drall.uk.xensource.com ([10.80.227.107])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TORrA-0006LF-Us;
	Wed, 17 Oct 2012 12:32:12 +0100
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 17 Oct 2012 12:32:10 +0100
Message-ID: <1350473532-15863-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1350473518.2460.58.camel@zakaz.uk.xensource.com>
References: <1350473518.2460.58.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	linux-kernel@vger.kernel.org,
	Ian Campbell , xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 4/6] xen: correctly use xen_pfn_t in
	remap_domain_mfn_range.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

For Xen on ARM a PFN is 64 bits so we need to use the appropriate
type here.

Signed-off-by: Ian Campbell 
---
 arch/x86/xen/mmu.c    |    2 +-
 include/xen/xen-ops.h |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 1c5812b..d779e96 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -2603,7 +2603,7 @@ static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token,
 
 int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 			       unsigned long addr,
-			       unsigned long mfn, int nr,
+			       xen_pfn_t mfn, int nr,
 			       pgprot_t prot, unsigned domid,
 			       struct page **pages)
 
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 6a40253..dc63e80 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -26,7 +26,7 @@ void xen_destroy_contiguous_region(unsigned long vstart, unsigned int order);
 struct vm_area_struct;
 int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 			       unsigned long addr,
-			       unsigned long mfn, int nr,
+			       xen_pfn_t mfn, int nr,
 			       pgprot_t prot, unsigned domid,
 			       struct page **pages);
 int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 11:32:35 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 11:32:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TORrL-0005e7-9h; Wed, 17 Oct 2012 11:32:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TORrJ-0005d5-Um
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 11:32:22 +0000
Received: from [85.158.138.51:38165] by server-13.bemta-3.messagelabs.com id
	0E/50-26794-5479E705; Wed, 17 Oct 2012 11:32:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1350473534!26772435!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzcwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9440 invoked from network); 17 Oct 2012 11:32:18 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 11:32:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,600,1344211200"; d="scan'208";a="41487902"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 11:32:13 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 07:32:13 -0400
Received: from drall.uk.xensource.com ([10.80.227.107])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TORrA-0006LF-Us;
	Wed, 17 Oct 2012 12:32:12 +0100
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 17 Oct 2012 12:32:10 +0100
Message-ID: <1350473532-15863-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1350473518.2460.58.camel@zakaz.uk.xensource.com>
References: <1350473518.2460.58.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	linux-kernel@vger.kernel.org,
	Ian Campbell , xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 4/6] xen: correctly use xen_pfn_t in
	remap_domain_mfn_range.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

For Xen on ARM a PFN is 64 bits so we need to use the appropriate
type here.

Signed-off-by: Ian Campbell 
---
 arch/x86/xen/mmu.c    |    2 +-
 include/xen/xen-ops.h |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 1c5812b..d779e96 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -2603,7 +2603,7 @@ static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token,
 
 int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 			       unsigned long addr,
-			       unsigned long mfn, int nr,
+			       xen_pfn_t mfn, int nr,
 			       pgprot_t prot, unsigned domid,
 			       struct page **pages)
 
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 6a40253..dc63e80 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -26,7 +26,7 @@ void xen_destroy_contiguous_region(unsigned long vstart, unsigned int order);
 struct vm_area_struct;
 int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 			       unsigned long addr,
-			       unsigned long mfn, int nr,
+			       xen_pfn_t mfn, int nr,
 			       pgprot_t prot, unsigned domid,
 			       struct page **pages);
 int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 11:32:35 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 11:32:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TORrJ-0005d8-Kh; Wed, 17 Oct 2012 11:32:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TORrH-0005cJ-PL
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 11:32:19 +0000
Received: from [85.158.138.51:25691] by server-7.bemta-3.messagelabs.com id
	0E/9E-06991-3479E705; Wed, 17 Oct 2012 11:32:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1350473534!26772435!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzcwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9419 invoked from network); 17 Oct 2012 11:32:16 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 11:32:16 -0000
X-IronPort-AV: E=Sophos;i="4.80,600,1344211200"; d="scan'208";a="41487901"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 11:32:13 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 07:32:13 -0400
Received: from drall.uk.xensource.com ([10.80.227.107])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TORrA-0006LF-Qo;
	Wed, 17 Oct 2012 12:32:12 +0100
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 17 Oct 2012 12:32:07 +0100
Message-ID: <1350473532-15863-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1350473518.2460.58.camel@zakaz.uk.xensource.com>
References: <1350473518.2460.58.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	linux-kernel@vger.kernel.org,
	Ian Campbell , xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 1/6] xen: balloon: allow PVMMU interfaces to be
	compiled out
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The ARM platform has no concept of PVMMU and therefor no
HYPERVISOR_update_va_mapping et al. Allow this code to be compiled out
when not required.

In some similar situations (e.g. P2M) we have defined dummy functions
to avoid this, however I think we can/should draw the line at dummying
out actual hypercalls.

Signed-off-by: Ian Campbell 
---
 arch/x86/xen/Kconfig  |    1 +
 drivers/xen/Kconfig   |    3 +++
 drivers/xen/balloon.c |    4 ++++
 3 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index 9323b8c..6d101a1 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -6,6 +6,7 @@ config XEN
 	bool "Xen guest support"
 	select PARAVIRT
 	select PARAVIRT_CLOCK
+	select XEN_HAVE_PVMMU
 	depends on X86_64 || (X86_32 && X86_PAE && !X86_VISWS)
 	depends on X86_CMPXCHG && X86_TSC
 	help
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index d4dffcd..9c00652 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -204,4 +204,7 @@ config XEN_MCE_LOG
 	  Allow kernel fetching MCE error from Xen platform and
 	  converting it into Linux mcelog format for mcelog tools
 
+config XEN_HAVE_PVMMU
+       bool
+
 endmenu
diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index db3aa34..92449a0 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -360,6 +360,7 @@ static enum bp_state increase_reservation(unsigned long nr_pages)
 		if (!xen_feature(XENFEAT_auto_translated_physmap))
 			set_phys_to_machine(pfn, frame_list[i]);
 
+#ifdef CONFIG_XEN_HAVE_PVMMU
 		/* Link back into the page tables if not highmem. */
 		if (xen_pv_domain() && !PageHighMem(page) &&
 		    !xen_feature(XENFEAT_auto_translated_physmap)) {
@@ -371,6 +372,7 @@ static enum bp_state increase_reservation(unsigned long nr_pages)
 				0);
 			BUG_ON(ret);
 		}
+#endif
 
 		/* Relinquish the page back to the allocator. */
 		ClearPageReserved(page);
@@ -419,6 +421,7 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
 
 		scrub_page(page);
 
+#ifdef CONFIG_XEN_HAVE_PVMMU
 		if (xen_pv_domain() && !PageHighMem(page)) {
 			if (!xen_feature(XENFEAT_auto_translated_physmap)) {
 				ret = HYPERVISOR_update_va_mapping(
@@ -427,6 +430,7 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
 				BUG_ON(ret);
 			}
 		}
+#endif
 	}
 
 	/* Ensure that ballooned highmem pages don't have kmaps. */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 11:32:35 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 11:32:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TORrJ-0005d8-Kh; Wed, 17 Oct 2012 11:32:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TORrH-0005cJ-PL
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 11:32:19 +0000
Received: from [85.158.138.51:25691] by server-7.bemta-3.messagelabs.com id
	0E/9E-06991-3479E705; Wed, 17 Oct 2012 11:32:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1350473534!26772435!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzcwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9419 invoked from network); 17 Oct 2012 11:32:16 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 11:32:16 -0000
X-IronPort-AV: E=Sophos;i="4.80,600,1344211200"; d="scan'208";a="41487901"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 11:32:13 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 07:32:13 -0400
Received: from drall.uk.xensource.com ([10.80.227.107])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TORrA-0006LF-Qo;
	Wed, 17 Oct 2012 12:32:12 +0100
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 17 Oct 2012 12:32:07 +0100
Message-ID: <1350473532-15863-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1350473518.2460.58.camel@zakaz.uk.xensource.com>
References: <1350473518.2460.58.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	linux-kernel@vger.kernel.org,
	Ian Campbell , xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 1/6] xen: balloon: allow PVMMU interfaces to be
	compiled out
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The ARM platform has no concept of PVMMU and therefor no
HYPERVISOR_update_va_mapping et al. Allow this code to be compiled out
when not required.

In some similar situations (e.g. P2M) we have defined dummy functions
to avoid this, however I think we can/should draw the line at dummying
out actual hypercalls.

Signed-off-by: Ian Campbell 
---
 arch/x86/xen/Kconfig  |    1 +
 drivers/xen/Kconfig   |    3 +++
 drivers/xen/balloon.c |    4 ++++
 3 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index 9323b8c..6d101a1 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -6,6 +6,7 @@ config XEN
 	bool "Xen guest support"
 	select PARAVIRT
 	select PARAVIRT_CLOCK
+	select XEN_HAVE_PVMMU
 	depends on X86_64 || (X86_32 && X86_PAE && !X86_VISWS)
 	depends on X86_CMPXCHG && X86_TSC
 	help
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index d4dffcd..9c00652 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -204,4 +204,7 @@ config XEN_MCE_LOG
 	  Allow kernel fetching MCE error from Xen platform and
 	  converting it into Linux mcelog format for mcelog tools
 
+config XEN_HAVE_PVMMU
+       bool
+
 endmenu
diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index db3aa34..92449a0 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -360,6 +360,7 @@ static enum bp_state increase_reservation(unsigned long nr_pages)
 		if (!xen_feature(XENFEAT_auto_translated_physmap))
 			set_phys_to_machine(pfn, frame_list[i]);
 
+#ifdef CONFIG_XEN_HAVE_PVMMU
 		/* Link back into the page tables if not highmem. */
 		if (xen_pv_domain() && !PageHighMem(page) &&
 		    !xen_feature(XENFEAT_auto_translated_physmap)) {
@@ -371,6 +372,7 @@ static enum bp_state increase_reservation(unsigned long nr_pages)
 				0);
 			BUG_ON(ret);
 		}
+#endif
 
 		/* Relinquish the page back to the allocator. */
 		ClearPageReserved(page);
@@ -419,6 +421,7 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
 
 		scrub_page(page);
 
+#ifdef CONFIG_XEN_HAVE_PVMMU
 		if (xen_pv_domain() && !PageHighMem(page)) {
 			if (!xen_feature(XENFEAT_auto_translated_physmap)) {
 				ret = HYPERVISOR_update_va_mapping(
@@ -427,6 +430,7 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
 				BUG_ON(ret);
 			}
 		}
+#endif
 	}
 
 	/* Ensure that ballooned highmem pages don't have kmaps. */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 11:32:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 11:32:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TORrI-0005cR-2C; Wed, 17 Oct 2012 11:32:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TORrG-0005c9-8D
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 11:32:18 +0000
Received: from [85.158.138.51:38027] by server-1.bemta-3.messagelabs.com id
	09/78-31728-1479E705; Wed, 17 Oct 2012 11:32:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1350473534!26772435!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzcwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9386 invoked from network); 17 Oct 2012 11:32:15 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 11:32:15 -0000
X-IronPort-AV: E=Sophos;i="4.80,600,1344211200"; d="scan'208";a="41487900"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 11:32:13 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 07:32:13 -0400
Received: from drall.uk.xensource.com ([10.80.227.107])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TORrA-0006LF-Sb;
	Wed, 17 Oct 2012 12:32:12 +0100
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 17 Oct 2012 12:32:08 +0100
Message-ID: <1350473532-15863-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1350473518.2460.58.camel@zakaz.uk.xensource.com>
References: <1350473518.2460.58.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	linux-kernel@vger.kernel.org,
	Ian Campbell , xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 2/6] xen: arm: enable balloon driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The code is no in a state where can just enable it.

Drop the *_xenballloned_pages duplicates since these are now supplied
by the balloon code.

Signed-off-by: Ian Campbell 
---
 arch/arm/xen/enlighten.c |   23 +++++------------------
 drivers/xen/Makefile     |    4 ++--
 2 files changed, 7 insertions(+), 20 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 59bcb96..ba5cc13 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -29,6 +30,10 @@ struct shared_info *HYPERVISOR_shared_info = (void *)&xen_dummy_shared_info;
 
 DEFINE_PER_CPU(struct vcpu_info *, xen_vcpu);
 
+/* These are unused until we support booting "pre-ballooned" */
+unsigned long xen_released_pages;
+struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata;
+
 /* TODO: to be removed */
 __read_mostly int xen_have_vector_callback;
 EXPORT_SYMBOL_GPL(xen_have_vector_callback);
@@ -148,21 +153,3 @@ static int __init xen_init_events(void)
 	return 0;
 }
 postcore_initcall(xen_init_events);
-
-/* XXX: only until balloon is properly working */
-int alloc_xenballooned_pages(int nr_pages, struct page **pages, bool highmem)
-{
-	*pages = alloc_pages(highmem ? GFP_HIGHUSER : GFP_KERNEL,
-			get_order(nr_pages));
-	if (*pages == NULL)
-		return -ENOMEM;
-	return 0;
-}
-EXPORT_SYMBOL_GPL(alloc_xenballooned_pages);
-
-void free_xenballooned_pages(int nr_pages, struct page **pages)
-{
-	kfree(*pages);
-	*pages = NULL;
-}
-EXPORT_SYMBOL_GPL(free_xenballooned_pages);
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 0e863703..909bb56 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -1,8 +1,8 @@
 ifneq ($(CONFIG_ARM),y)
-obj-y	+= manage.o balloon.o
+obj-y	+= manage.o
 obj-$(CONFIG_HOTPLUG_CPU)		+= cpu_hotplug.o
 endif
-obj-y	+= grant-table.o features.o events.o
+obj-y	+= grant-table.o features.o events.o balloon.o
 obj-y	+= xenbus/
 
 nostackp := $(call cc-option, -fno-stack-protector)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 11:32:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 11:32:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TORrI-0005cR-2C; Wed, 17 Oct 2012 11:32:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TORrG-0005c9-8D
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 11:32:18 +0000
Received: from [85.158.138.51:38027] by server-1.bemta-3.messagelabs.com id
	09/78-31728-1479E705; Wed, 17 Oct 2012 11:32:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1350473534!26772435!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzcwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9386 invoked from network); 17 Oct 2012 11:32:15 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 11:32:15 -0000
X-IronPort-AV: E=Sophos;i="4.80,600,1344211200"; d="scan'208";a="41487900"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 11:32:13 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 07:32:13 -0400
Received: from drall.uk.xensource.com ([10.80.227.107])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TORrA-0006LF-Sb;
	Wed, 17 Oct 2012 12:32:12 +0100
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 17 Oct 2012 12:32:08 +0100
Message-ID: <1350473532-15863-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1350473518.2460.58.camel@zakaz.uk.xensource.com>
References: <1350473518.2460.58.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	linux-kernel@vger.kernel.org,
	Ian Campbell , xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 2/6] xen: arm: enable balloon driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The code is no in a state where can just enable it.

Drop the *_xenballloned_pages duplicates since these are now supplied
by the balloon code.

Signed-off-by: Ian Campbell 
---
 arch/arm/xen/enlighten.c |   23 +++++------------------
 drivers/xen/Makefile     |    4 ++--
 2 files changed, 7 insertions(+), 20 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 59bcb96..ba5cc13 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -29,6 +30,10 @@ struct shared_info *HYPERVISOR_shared_info = (void *)&xen_dummy_shared_info;
 
 DEFINE_PER_CPU(struct vcpu_info *, xen_vcpu);
 
+/* These are unused until we support booting "pre-ballooned" */
+unsigned long xen_released_pages;
+struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata;
+
 /* TODO: to be removed */
 __read_mostly int xen_have_vector_callback;
 EXPORT_SYMBOL_GPL(xen_have_vector_callback);
@@ -148,21 +153,3 @@ static int __init xen_init_events(void)
 	return 0;
 }
 postcore_initcall(xen_init_events);
-
-/* XXX: only until balloon is properly working */
-int alloc_xenballooned_pages(int nr_pages, struct page **pages, bool highmem)
-{
-	*pages = alloc_pages(highmem ? GFP_HIGHUSER : GFP_KERNEL,
-			get_order(nr_pages));
-	if (*pages == NULL)
-		return -ENOMEM;
-	return 0;
-}
-EXPORT_SYMBOL_GPL(alloc_xenballooned_pages);
-
-void free_xenballooned_pages(int nr_pages, struct page **pages)
-{
-	kfree(*pages);
-	*pages = NULL;
-}
-EXPORT_SYMBOL_GPL(free_xenballooned_pages);
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 0e863703..909bb56 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -1,8 +1,8 @@
 ifneq ($(CONFIG_ARM),y)
-obj-y	+= manage.o balloon.o
+obj-y	+= manage.o
 obj-$(CONFIG_HOTPLUG_CPU)		+= cpu_hotplug.o
 endif
-obj-y	+= grant-table.o features.o events.o
+obj-y	+= grant-table.o features.o events.o balloon.o
 obj-y	+= xenbus/
 
 nostackp := $(call cc-option, -fno-stack-protector)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 11:32:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 11:32:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TORrK-0005dO-0c; Wed, 17 Oct 2012 11:32:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TORrI-0005cL-3V
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 11:32:20 +0000
Received: from [85.158.139.83:11305] by server-14.bemta-5.messagelabs.com id
	F0/DE-24068-3479E705; Wed, 17 Oct 2012 11:32:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1350473536!30722763!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzcwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28294 invoked from network); 17 Oct 2012 11:32:18 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 11:32:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,600,1344211200"; d="scan'208";a="41487903"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 11:32:13 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 07:32:13 -0400
Received: from drall.uk.xensource.com ([10.80.227.107])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TORrA-0006LF-UN;
	Wed, 17 Oct 2012 12:32:12 +0100
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 17 Oct 2012 12:32:09 +0100
Message-ID: <1350473532-15863-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1350473518.2460.58.camel@zakaz.uk.xensource.com>
References: <1350473518.2460.58.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	linux-kernel@vger.kernel.org,
	Ian Campbell , xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 3/6] xen: avoid use of vma->vm_private in
	xen_unmap_domain_mfn_range interface
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Campbell 
---
I beleive Mukesh has something similar in his tree. Should be trivial
to resolve I think. I'm happy to do so ontop of PVH v3 when it arrives.
---
 arch/x86/xen/mmu.c    |    6 ++----
 drivers/xen/privcmd.c |    2 +-
 include/xen/xen-ops.h |    3 ++-
 3 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 018cbf0..1c5812b 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -2655,11 +2655,9 @@ out:
 EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
 
 /* Returns: 0 success */
-int xen_unmap_domain_mfn_range(struct vm_area_struct *vma)
+int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
+			       struct page **pages, int numpgs)
 {
-	int numpgs = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
-	struct page **pages = vma ? vma->vm_private_data : NULL;
-
 	if (!pages || !xen_feature(XENFEAT_auto_translated_physmap))
 		return 0;
 
diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 641a420..a1ca5ab 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -498,7 +498,7 @@ static void privcmd_close(struct vm_area_struct *vma)
 	if (!pages || !numpgs || !xen_feature(XENFEAT_auto_translated_physmap))
 		return;
 
-	xen_unmap_domain_mfn_range(vma);
+	xen_unmap_domain_mfn_range(vma, pages, numpgs);
 	while (numpgs--)
 		free_xenballooned_pages(1, &pages[numpgs]);
 	kfree(pages);
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 8b24315..6a40253 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -29,6 +29,7 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 			       unsigned long mfn, int nr,
 			       pgprot_t prot, unsigned domid,
 			       struct page **pages);
-int xen_unmap_domain_mfn_range(struct vm_area_struct *vma);
+int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
+			       struct page **pages, int nr);
 
 #endif /* INCLUDE_XEN_OPS_H */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 11:32:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 11:32:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TORrK-0005dO-0c; Wed, 17 Oct 2012 11:32:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TORrI-0005cL-3V
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 11:32:20 +0000
Received: from [85.158.139.83:11305] by server-14.bemta-5.messagelabs.com id
	F0/DE-24068-3479E705; Wed, 17 Oct 2012 11:32:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1350473536!30722763!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzcwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28294 invoked from network); 17 Oct 2012 11:32:18 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 11:32:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,600,1344211200"; d="scan'208";a="41487903"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 11:32:13 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 07:32:13 -0400
Received: from drall.uk.xensource.com ([10.80.227.107])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TORrA-0006LF-UN;
	Wed, 17 Oct 2012 12:32:12 +0100
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 17 Oct 2012 12:32:09 +0100
Message-ID: <1350473532-15863-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1350473518.2460.58.camel@zakaz.uk.xensource.com>
References: <1350473518.2460.58.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	linux-kernel@vger.kernel.org,
	Ian Campbell , xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 3/6] xen: avoid use of vma->vm_private in
	xen_unmap_domain_mfn_range interface
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Campbell 
---
I beleive Mukesh has something similar in his tree. Should be trivial
to resolve I think. I'm happy to do so ontop of PVH v3 when it arrives.
---
 arch/x86/xen/mmu.c    |    6 ++----
 drivers/xen/privcmd.c |    2 +-
 include/xen/xen-ops.h |    3 ++-
 3 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 018cbf0..1c5812b 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -2655,11 +2655,9 @@ out:
 EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
 
 /* Returns: 0 success */
-int xen_unmap_domain_mfn_range(struct vm_area_struct *vma)
+int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
+			       struct page **pages, int numpgs)
 {
-	int numpgs = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
-	struct page **pages = vma ? vma->vm_private_data : NULL;
-
 	if (!pages || !xen_feature(XENFEAT_auto_translated_physmap))
 		return 0;
 
diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 641a420..a1ca5ab 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -498,7 +498,7 @@ static void privcmd_close(struct vm_area_struct *vma)
 	if (!pages || !numpgs || !xen_feature(XENFEAT_auto_translated_physmap))
 		return;
 
-	xen_unmap_domain_mfn_range(vma);
+	xen_unmap_domain_mfn_range(vma, pages, numpgs);
 	while (numpgs--)
 		free_xenballooned_pages(1, &pages[numpgs]);
 	kfree(pages);
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 8b24315..6a40253 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -29,6 +29,7 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 			       unsigned long mfn, int nr,
 			       pgprot_t prot, unsigned domid,
 			       struct page **pages);
-int xen_unmap_domain_mfn_range(struct vm_area_struct *vma);
+int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
+			       struct page **pages, int nr);
 
 #endif /* INCLUDE_XEN_OPS_H */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 11:32:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 11:32:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TORrK-0005dv-Rm; Wed, 17 Oct 2012 11:32:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TORrJ-0005cs-7I
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 11:32:21 +0000
Received: from [85.158.138.51:38261] by server-9.bemta-3.messagelabs.com id
	54/EB-16841-4479E705; Wed, 17 Oct 2012 11:32:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1350473534!26772435!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzcwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9499 invoked from network); 17 Oct 2012 11:32:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 11:32:19 -0000
X-IronPort-AV: E=Sophos;i="4.80,600,1344211200"; d="scan'208";a="41487905"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 11:32:13 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 07:32:13 -0400
Received: from drall.uk.xensource.com ([10.80.227.107])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TORrA-0006LF-VO;
	Wed, 17 Oct 2012 12:32:13 +0100
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 17 Oct 2012 12:32:11 +0100
Message-ID: <1350473532-15863-5-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1350473518.2460.58.camel@zakaz.uk.xensource.com>
References: <1350473518.2460.58.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	linux-kernel@vger.kernel.org,
	Ian Campbell , xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 5/6] xen: arm: implement remap interfaces needed
	for privcmd mappings.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We use XENMEM_add_to_physmap_range which is the preferred interface
for foreign mappings.

Signed-off-by: Ian Campbell 
---
 arch/arm/include/asm/xen/interface.h |    1 +
 arch/arm/xen/enlighten.c             |  100 +++++++++++++++++++++++++++++++++-
 arch/x86/include/asm/xen/interface.h |    1 +
 include/xen/interface/memory.h       |   18 ++++++
 4 files changed, 117 insertions(+), 3 deletions(-)

diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
index 1d6ef9c..007e6da 100644
--- a/arch/arm/include/asm/xen/interface.h
+++ b/arch/arm/include/asm/xen/interface.h
@@ -43,6 +43,7 @@ DEFINE_GUEST_HANDLE(void);
 DEFINE_GUEST_HANDLE(uint64_t);
 DEFINE_GUEST_HANDLE(uint32_t);
 DEFINE_GUEST_HANDLE(xen_pfn_t);
+DEFINE_GUEST_HANDLE(xen_ulong_t);
 
 /* Maximum number of virtual CPUs in multi-processor guests. */
 #define MAX_VIRT_CPUS 1
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index ba5cc13..6bb4630 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -18,6 +19,8 @@
 #include 
 #include 
 
+#include 
+
 struct start_info _xen_start_info;
 struct start_info *xen_start_info = &_xen_start_info;
 EXPORT_SYMBOL_GPL(xen_start_info);
@@ -43,15 +46,106 @@ EXPORT_SYMBOL_GPL(xen_platform_pci_unplug);
 
 static __read_mostly int xen_events_irq = -1;
 
+/* map fgmfn of domid to lpfn in the current domain */
+static int map_foreign_page(unsigned long lpfn, unsigned long fgmfn,
+			    unsigned int domid)
+{
+	int rc;
+	struct xen_add_to_physmap_range xatp = {
+		.domid = DOMID_SELF,
+		.foreign_domid = domid,
+		.size = 1,
+		.space = XENMAPSPACE_gmfn_foreign,
+	};
+	xen_ulong_t idx = fgmfn;
+	xen_pfn_t gpfn = lpfn;
+
+	set_xen_guest_handle(xatp.idxs, &idx);
+	set_xen_guest_handle(xatp.gpfns, &gpfn);
+
+	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap_range, &xatp);
+	if (rc) {
+		pr_warn("Failed to map pfn to mfn rc:%d pfn:%lx mfn:%lx\n",
+			rc, lpfn, fgmfn);
+		return 1;
+	}
+	return 0;
+}
+
+struct remap_data {
+	xen_pfn_t fgmfn; /* foreign domain's gmfn */
+	pgprot_t prot;
+	domid_t  domid;
+	struct vm_area_struct *vma;
+	int index;
+	struct page **pages;
+	struct xen_remap_mfn_info *info;
+};
+
+static int remap_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr,
+			void *data)
+{
+	struct remap_data *info = data;
+	struct page *page = info->pages[info->index++];
+	unsigned long pfn = page_to_pfn(page);
+	pte_t pte = pfn_pte(pfn, info->prot);
+
+	if (map_foreign_page(pfn, info->fgmfn, info->domid))
+		return -EFAULT;
+	set_pte_at(info->vma->vm_mm, addr, ptep, pte);
+
+	return 0;
+}
+
 int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 			       unsigned long addr,
-			       unsigned long mfn, int nr,
-			       pgprot_t prot, unsigned domid)
+			       xen_pfn_t mfn, int nr,
+			       pgprot_t prot, unsigned domid,
+			       struct page **pages)
 {
-	return -ENOSYS;
+	int err;
+	struct remap_data data;
+
+	/* TBD: Batching, current sole caller only does page at a time */
+	if (nr > 1)
+		return -EINVAL;
+
+	data.fgmfn = mfn;
+	data.prot = prot;
+	data.domid = domid;
+	data.vma = vma;
+	data.index = 0;
+	data.pages = pages;
+	err = apply_to_page_range(vma->vm_mm, addr, nr << PAGE_SHIFT,
+				  remap_pte_fn, &data);
+	return err;
 }
 EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
 
+int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
+			       struct page **pages, int nr)
+{
+	int i;
+
+	for (i=0; i enum phys_map_space */
+
+    /* Number of pages to go through */
+    uint16_t size;
+    domid_t foreign_domid; /* IFF gmfn_foreign */
+
+    /* Indexes into space being mapped. */
+    GUEST_HANDLE(xen_ulong_t) idxs;
+
+    /* GPFN in domid where the source mapping page should appear. */
+    GUEST_HANDLE(xen_pfn_t) gpfns;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_physmap_range);
+
 /*
  * Returns the pseudo-physical memory map as it was when the domain
  * was started (specified by XENMEM_set_memory_map).
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 11:32:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 11:32:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TORrK-0005dv-Rm; Wed, 17 Oct 2012 11:32:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TORrJ-0005cs-7I
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 11:32:21 +0000
Received: from [85.158.138.51:38261] by server-9.bemta-3.messagelabs.com id
	54/EB-16841-4479E705; Wed, 17 Oct 2012 11:32:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1350473534!26772435!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzcwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9499 invoked from network); 17 Oct 2012 11:32:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 11:32:19 -0000
X-IronPort-AV: E=Sophos;i="4.80,600,1344211200"; d="scan'208";a="41487905"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 11:32:13 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 07:32:13 -0400
Received: from drall.uk.xensource.com ([10.80.227.107])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TORrA-0006LF-VO;
	Wed, 17 Oct 2012 12:32:13 +0100
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 17 Oct 2012 12:32:11 +0100
Message-ID: <1350473532-15863-5-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1350473518.2460.58.camel@zakaz.uk.xensource.com>
References: <1350473518.2460.58.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	linux-kernel@vger.kernel.org,
	Ian Campbell , xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 5/6] xen: arm: implement remap interfaces needed
	for privcmd mappings.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We use XENMEM_add_to_physmap_range which is the preferred interface
for foreign mappings.

Signed-off-by: Ian Campbell 
---
 arch/arm/include/asm/xen/interface.h |    1 +
 arch/arm/xen/enlighten.c             |  100 +++++++++++++++++++++++++++++++++-
 arch/x86/include/asm/xen/interface.h |    1 +
 include/xen/interface/memory.h       |   18 ++++++
 4 files changed, 117 insertions(+), 3 deletions(-)

diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
index 1d6ef9c..007e6da 100644
--- a/arch/arm/include/asm/xen/interface.h
+++ b/arch/arm/include/asm/xen/interface.h
@@ -43,6 +43,7 @@ DEFINE_GUEST_HANDLE(void);
 DEFINE_GUEST_HANDLE(uint64_t);
 DEFINE_GUEST_HANDLE(uint32_t);
 DEFINE_GUEST_HANDLE(xen_pfn_t);
+DEFINE_GUEST_HANDLE(xen_ulong_t);
 
 /* Maximum number of virtual CPUs in multi-processor guests. */
 #define MAX_VIRT_CPUS 1
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index ba5cc13..6bb4630 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -18,6 +19,8 @@
 #include 
 #include 
 
+#include 
+
 struct start_info _xen_start_info;
 struct start_info *xen_start_info = &_xen_start_info;
 EXPORT_SYMBOL_GPL(xen_start_info);
@@ -43,15 +46,106 @@ EXPORT_SYMBOL_GPL(xen_platform_pci_unplug);
 
 static __read_mostly int xen_events_irq = -1;
 
+/* map fgmfn of domid to lpfn in the current domain */
+static int map_foreign_page(unsigned long lpfn, unsigned long fgmfn,
+			    unsigned int domid)
+{
+	int rc;
+	struct xen_add_to_physmap_range xatp = {
+		.domid = DOMID_SELF,
+		.foreign_domid = domid,
+		.size = 1,
+		.space = XENMAPSPACE_gmfn_foreign,
+	};
+	xen_ulong_t idx = fgmfn;
+	xen_pfn_t gpfn = lpfn;
+
+	set_xen_guest_handle(xatp.idxs, &idx);
+	set_xen_guest_handle(xatp.gpfns, &gpfn);
+
+	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap_range, &xatp);
+	if (rc) {
+		pr_warn("Failed to map pfn to mfn rc:%d pfn:%lx mfn:%lx\n",
+			rc, lpfn, fgmfn);
+		return 1;
+	}
+	return 0;
+}
+
+struct remap_data {
+	xen_pfn_t fgmfn; /* foreign domain's gmfn */
+	pgprot_t prot;
+	domid_t  domid;
+	struct vm_area_struct *vma;
+	int index;
+	struct page **pages;
+	struct xen_remap_mfn_info *info;
+};
+
+static int remap_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr,
+			void *data)
+{
+	struct remap_data *info = data;
+	struct page *page = info->pages[info->index++];
+	unsigned long pfn = page_to_pfn(page);
+	pte_t pte = pfn_pte(pfn, info->prot);
+
+	if (map_foreign_page(pfn, info->fgmfn, info->domid))
+		return -EFAULT;
+	set_pte_at(info->vma->vm_mm, addr, ptep, pte);
+
+	return 0;
+}
+
 int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 			       unsigned long addr,
-			       unsigned long mfn, int nr,
-			       pgprot_t prot, unsigned domid)
+			       xen_pfn_t mfn, int nr,
+			       pgprot_t prot, unsigned domid,
+			       struct page **pages)
 {
-	return -ENOSYS;
+	int err;
+	struct remap_data data;
+
+	/* TBD: Batching, current sole caller only does page at a time */
+	if (nr > 1)
+		return -EINVAL;
+
+	data.fgmfn = mfn;
+	data.prot = prot;
+	data.domid = domid;
+	data.vma = vma;
+	data.index = 0;
+	data.pages = pages;
+	err = apply_to_page_range(vma->vm_mm, addr, nr << PAGE_SHIFT,
+				  remap_pte_fn, &data);
+	return err;
 }
 EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
 
+int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
+			       struct page **pages, int nr)
+{
+	int i;
+
+	for (i=0; i enum phys_map_space */
+
+    /* Number of pages to go through */
+    uint16_t size;
+    domid_t foreign_domid; /* IFF gmfn_foreign */
+
+    /* Indexes into space being mapped. */
+    GUEST_HANDLE(xen_ulong_t) idxs;
+
+    /* GPFN in domid where the source mapping page should appear. */
+    GUEST_HANDLE(xen_pfn_t) gpfns;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_physmap_range);
+
 /*
  * Returns the pseudo-physical memory map as it was when the domain
  * was started (specified by XENMEM_set_memory_map).
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 11:32:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 11:32:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TORrK-0005df-EP; Wed, 17 Oct 2012 11:32:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TORrI-0005cf-VG
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 11:32:21 +0000
Received: from [85.158.139.83:38178] by server-2.bemta-5.messagelabs.com id
	03/68-10520-3479E705; Wed, 17 Oct 2012 11:32:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1350473536!30722763!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzcwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28333 invoked from network); 17 Oct 2012 11:32:18 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 11:32:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,600,1344211200"; d="scan'208";a="41487904"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 11:32:13 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 07:32:13 -0400
Received: from drall.uk.xensource.com ([10.80.227.107])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TORrB-0006LF-0x;
	Wed, 17 Oct 2012 12:32:13 +0100
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 17 Oct 2012 12:32:12 +0100
Message-ID: <1350473532-15863-6-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1350473518.2460.58.camel@zakaz.uk.xensource.com>
References: <1350473518.2460.58.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	linux-kernel@vger.kernel.org,
	Ian Campbell , xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 6/6] xen: x86 pvh: use
	XENMEM_add_to_physmap_range for foreign gmfn mappings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Squeezing the necessary fields into the existing XENMEM_add_to_physmap
interface was proving to be a bit tricky so we have decided to go with
a new interface upstream (the XENMAPSPACE_gmfn_foreign interface using
XENMEM_add_to_physmap was never committed anywhere). This interface
also allows for batching which was impossible to support at the same
time as foreign mfns in the old interface.

This reverts the relevant parts of "PVH: basic and header changes,
elfnote changes, ..." and followups and trivially converts
pvh_add_to_xen_p2m over.

Signed-off-by: Ian Campbell 
---
 arch/x86/xen/mmu.c             |   18 ++++++++++++------
 include/xen/interface/memory.h |   24 +++++++++++-------------
 2 files changed, 23 insertions(+), 19 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index d779e96..e7edcdd 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -2506,13 +2506,19 @@ static int pvh_add_to_xen_p2m(unsigned long lpfn, unsigned long fgmfn,
 			      unsigned int domid)
 {
 	int rc;
-	struct xen_add_to_physmap xatp = { .u.foreign_domid = domid };
+	struct xen_add_to_physmap_range xatp = {
+		.domid = DOMID_SELF,
+		.foreign_domid = domid,
+		.size = 1,
+		.space = XENMAPSPACE_gmfn_foreign,
+	};
+	xen_ulong_t idx = fgmfn;
+	xen_pfn_t gpfn = lpfn;
+
+	set_xen_guest_handle(xatp.idxs, &idx);
+	set_xen_guest_handle(xatp.gpfns, &gpfn);
 
-	xatp.gpfn = lpfn;
-	xatp.idx = fgmfn;
-	xatp.domid = DOMID_SELF;
-	xatp.space = XENMAPSPACE_gmfn_foreign;
-	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
+	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap_range, &xatp);
 	if (rc)
 		pr_warn("d0: Failed to map pfn (0x%lx) to mfn (0x%lx) rc:%d\n",
 			lpfn, fgmfn, rc);
diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index eb2d3e5..b40a431 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -153,6 +153,14 @@ struct xen_machphys_mapping {
 };
 DEFINE_GUEST_HANDLE_STRUCT(xen_machphys_mapping_t);
 
+#define XENMAPSPACE_shared_info  0 /* shared info page */
+#define XENMAPSPACE_grant_table  1 /* grant table page */
+#define XENMAPSPACE_gmfn         2 /* GMFN */
+#define XENMAPSPACE_gmfn_range   3 /* GMFN range, XENMEM_add_to_physmap only. */
+#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another dom,
+				    * XENMEM_add_to_physmap_range only.
+				    */
+
 /*
  * Sets the GPFN at which a particular page appears in the specified guest's
  * pseudophysical address space.
@@ -163,22 +171,12 @@ struct xen_add_to_physmap {
     /* Which domain to change the mapping for. */
     domid_t domid;
 
-    union {
-	/* Number of pages to go through for gmfn_range */
-	uint16_t    size;
-	/* IFF XENMAPSPACE_gmfn_foreign */
-	domid_t foreign_domid;
-    } u;
+    /* Number of pages to go through for gmfn_range */
+    uint16_t    size;
+
     /* Source mapping space. */
-#define XENMAPSPACE_shared_info 0 /* shared info page */
-#define XENMAPSPACE_grant_table 1 /* grant table page */
-#define XENMAPSPACE_gmfn        2 /* GMFN */
-#define XENMAPSPACE_gmfn_range  3 /* GMFN range */
-#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */
     unsigned int space;
 
-#define XENMAPIDX_grant_table_status 0x80000000
-
     /* Index into source mapping space. */
     xen_ulong_t idx;
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 11:32:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 11:32:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TORrK-0005df-EP; Wed, 17 Oct 2012 11:32:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TORrI-0005cf-VG
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 11:32:21 +0000
Received: from [85.158.139.83:38178] by server-2.bemta-5.messagelabs.com id
	03/68-10520-3479E705; Wed, 17 Oct 2012 11:32:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1350473536!30722763!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzcwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28333 invoked from network); 17 Oct 2012 11:32:18 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 11:32:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,600,1344211200"; d="scan'208";a="41487904"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 11:32:13 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 07:32:13 -0400
Received: from drall.uk.xensource.com ([10.80.227.107])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TORrB-0006LF-0x;
	Wed, 17 Oct 2012 12:32:13 +0100
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 17 Oct 2012 12:32:12 +0100
Message-ID: <1350473532-15863-6-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1350473518.2460.58.camel@zakaz.uk.xensource.com>
References: <1350473518.2460.58.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	linux-kernel@vger.kernel.org,
	Ian Campbell , xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 6/6] xen: x86 pvh: use
	XENMEM_add_to_physmap_range for foreign gmfn mappings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Squeezing the necessary fields into the existing XENMEM_add_to_physmap
interface was proving to be a bit tricky so we have decided to go with
a new interface upstream (the XENMAPSPACE_gmfn_foreign interface using
XENMEM_add_to_physmap was never committed anywhere). This interface
also allows for batching which was impossible to support at the same
time as foreign mfns in the old interface.

This reverts the relevant parts of "PVH: basic and header changes,
elfnote changes, ..." and followups and trivially converts
pvh_add_to_xen_p2m over.

Signed-off-by: Ian Campbell 
---
 arch/x86/xen/mmu.c             |   18 ++++++++++++------
 include/xen/interface/memory.h |   24 +++++++++++-------------
 2 files changed, 23 insertions(+), 19 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index d779e96..e7edcdd 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -2506,13 +2506,19 @@ static int pvh_add_to_xen_p2m(unsigned long lpfn, unsigned long fgmfn,
 			      unsigned int domid)
 {
 	int rc;
-	struct xen_add_to_physmap xatp = { .u.foreign_domid = domid };
+	struct xen_add_to_physmap_range xatp = {
+		.domid = DOMID_SELF,
+		.foreign_domid = domid,
+		.size = 1,
+		.space = XENMAPSPACE_gmfn_foreign,
+	};
+	xen_ulong_t idx = fgmfn;
+	xen_pfn_t gpfn = lpfn;
+
+	set_xen_guest_handle(xatp.idxs, &idx);
+	set_xen_guest_handle(xatp.gpfns, &gpfn);
 
-	xatp.gpfn = lpfn;
-	xatp.idx = fgmfn;
-	xatp.domid = DOMID_SELF;
-	xatp.space = XENMAPSPACE_gmfn_foreign;
-	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
+	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap_range, &xatp);
 	if (rc)
 		pr_warn("d0: Failed to map pfn (0x%lx) to mfn (0x%lx) rc:%d\n",
 			lpfn, fgmfn, rc);
diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index eb2d3e5..b40a431 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -153,6 +153,14 @@ struct xen_machphys_mapping {
 };
 DEFINE_GUEST_HANDLE_STRUCT(xen_machphys_mapping_t);
 
+#define XENMAPSPACE_shared_info  0 /* shared info page */
+#define XENMAPSPACE_grant_table  1 /* grant table page */
+#define XENMAPSPACE_gmfn         2 /* GMFN */
+#define XENMAPSPACE_gmfn_range   3 /* GMFN range, XENMEM_add_to_physmap only. */
+#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another dom,
+				    * XENMEM_add_to_physmap_range only.
+				    */
+
 /*
  * Sets the GPFN at which a particular page appears in the specified guest's
  * pseudophysical address space.
@@ -163,22 +171,12 @@ struct xen_add_to_physmap {
     /* Which domain to change the mapping for. */
     domid_t domid;
 
-    union {
-	/* Number of pages to go through for gmfn_range */
-	uint16_t    size;
-	/* IFF XENMAPSPACE_gmfn_foreign */
-	domid_t foreign_domid;
-    } u;
+    /* Number of pages to go through for gmfn_range */
+    uint16_t    size;
+
     /* Source mapping space. */
-#define XENMAPSPACE_shared_info 0 /* shared info page */
-#define XENMAPSPACE_grant_table 1 /* grant table page */
-#define XENMAPSPACE_gmfn        2 /* GMFN */
-#define XENMAPSPACE_gmfn_range  3 /* GMFN range */
-#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */
     unsigned int space;
 
-#define XENMAPIDX_grant_table_status 0x80000000
-
     /* Index into source mapping space. */
     xen_ulong_t idx;
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 11:36:53 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 11:36:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TORvY-0006TT-1u; Wed, 17 Oct 2012 11:36:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TORvX-0006TJ-3C
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 11:36:43 +0000
Received: from [85.158.139.83:32730] by server-13.bemta-5.messagelabs.com id
	1F/37-30674-A489E705; Wed, 17 Oct 2012 11:36:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1350473800!31371356!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5646 invoked from network); 17 Oct 2012 11:36:40 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-182.messagelabs.com with SMTP;
	17 Oct 2012 11:36:40 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 17 Oct 2012 12:36:39 +0100
Message-Id: <507EB46502000078000A1F1E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 17 Oct 2012 12:36:37 +0100
From: "Jan Beulich" 
To: "xen-devel" 
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part8BBAA855.0__="
Subject: [Xen-devel] [PATCH] ACPI/APEI: fix ERST MOVE_DATA instruction
 implementation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part8BBAA855.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

The src_base and dst_base fields in apei_exec_context are physical
address, so they should be ioremaped before being used in ERST
MOVE_DATA instruction.

Reported-by: Javier Martinez Canillas 
Reported-by: Andrew Morton 
Signed-off-by: Huang Ying 

Replace use of ioremap() by __acpi_map_table()/set_fixmap(). Fix error
handling.

Signed-off-by: Jan Beulich 
---
Note that I have no way to test this code other than by having it go
through the tester, since I have no hardware available to reproduce
the regression found there (in other words, this is just a blind
attempt at addressing the problem uncovered by 26060:4fc87c2f31a0).

--- a/xen/drivers/acpi/apei/erst.c
+++ b/xen/drivers/acpi/apei/erst.c
@@ -247,15 +247,64 @@ static int erst_exec_move_data(struct ap
 {
 	int rc;
 	u64 offset;
+#ifdef CONFIG_X86
+	enum fixed_addresses idx;
+#endif
+	void *src, *dst;
+
+	/* ioremap does not work in interrupt context */
+	if (in_irq()) {
+		printk(KERN_WARNING
+		       "MOVE_DATA cannot be used in interrupt context\n");
+		return -EBUSY;
+	}
=20
 	rc =3D __apei_exec_read_register(entry, &offset);
 	if (rc)
 		return rc;
-	memmove((void *)(unsigned long)(ctx->dst_base + offset),
-		(void *)(unsigned long)(ctx->src_base + offset),
-		ctx->var2);
=20
-	return 0;
+#ifdef CONFIG_X86
+	switch (ctx->var2) {
+	case 0:
+		return 0;
+	case 1 ... PAGE_SIZE:
+		break;
+	default:
+		printk(KERN_WARNING
+		       "MOVE_DATA cannot be used for %#"PRIx64" bytes of =
data\n",
+		       ctx->var2);
+		return -EOPNOTSUPP;
+	}
+
+	src =3D __acpi_map_table(ctx->src_base + offset, ctx->var2);
+#else
+	src =3D ioremap(ctx->src_base + offset, ctx->var2);
+#endif
+	if (!src)
+		return -ENOMEM;
+
+#ifdef CONFIG_X86
+	BUILD_BUG_ON(FIX_ACPI_PAGES < 4);
+	idx =3D virt_to_fix((unsigned long)src + 2 * PAGE_SIZE);
+	offset +=3D ctx->dst_base;
+	dst =3D (void *)fix_to_virt(idx) + (offset & ~PAGE_MASK);
+	set_fixmap(idx, offset);
+	if (PFN_DOWN(offset) !=3D PFN_DOWN(offset + ctx->var2 - 1)) {
+		idx =3D virt_to_fix((unsigned long)dst + PAGE_SIZE);
+		set_fixmap(idx, offset + PAGE_SIZE);
+	}
+#else
+	dst =3D ioremap(ctx->dst_base + offset, ctx->var2);
+#endif
+	if (dst) {
+		memmove(dst, src, ctx->var2);
+		iounmap(dst);
+	} else
+		rc =3D -ENOMEM;
+
+	iounmap(src);
+
+	return rc;
 }
=20
 static struct apei_exec_ins_type erst_ins_type[] =3D {




--=__Part8BBAA855.0__=
Content-Type: text/plain; name="ACPI-ERST-move-data-map.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="ACPI-ERST-move-data-map.patch"

ACPI/APEI: fix ERST MOVE_DATA instruction implementation=0A=0AThe src_base =
and dst_base fields in apei_exec_context are physical=0Aaddress, so they =
should be ioremaped before being used in ERST=0AMOVE_DATA instruction.=0A=
=0AReported-by: Javier Martinez Canillas =0ARepo=
rted-by: Andrew Morton =0ASigned-off-by: Huang =
Ying =0A=0AReplace use of ioremap() by __acpi_map_tab=
le()/set_fixmap(). Fix error=0Ahandling.=0A=0ASigned-off-by: Jan Beulich =
=0A---=0ANote that I have no way to test this code =
other than by having it go=0Athrough the tester, since I have no hardware =
available to reproduce=0Athe regression found there (in other words, this =
is just a blind=0Aattempt at addressing the problem uncovered by 26060:4fc8=
7c2f31a0).=0A=0A--- a/xen/drivers/acpi/apei/erst.c=0A+++ b/xen/drivers/acpi=
/apei/erst.c=0A@@ -247,15 +247,64 @@ static int erst_exec_move_data(struct =
ap=0A {=0A 	int rc;=0A 	u64 offset;=0A+#ifdef CONFIG_X86=0A+	=
enum fixed_addresses idx;=0A+#endif=0A+	void *src, *dst;=0A+=0A+	/* =
ioremap does not work in interrupt context */=0A+	if (in_irq()) =
{=0A+		printk(KERN_WARNING=0A+		       "MOVE_DATA cannot =
be used in interrupt context\n");=0A+		return -EBUSY;=0A+	=
}=0A =0A 	rc =3D __apei_exec_read_register(entry, &offset);=0A 	if =
(rc)=0A 		return rc;=0A-	memmove((void *)(unsigned =
long)(ctx->dst_base + offset),=0A-		(void *)(unsigned =
long)(ctx->src_base + offset),=0A-		ctx->var2);=0A =0A-	=
return 0;=0A+#ifdef CONFIG_X86=0A+	switch (ctx->var2) {=0A+	=
case 0:=0A+		return 0;=0A+	case 1 ... PAGE_SIZE:=0A+		=
break;=0A+	default:=0A+		printk(KERN_WARNING=0A+		   =
    "MOVE_DATA cannot be used for %#"PRIx64" bytes of data\n",=0A+		=
       ctx->var2);=0A+		return -EOPNOTSUPP;=0A+	}=0A+=0A+	=
src =3D __acpi_map_table(ctx->src_base + offset, ctx->var2);=0A+#else=0A+	=
src =3D ioremap(ctx->src_base + offset, ctx->var2);=0A+#endif=0A+	if =
(!src)=0A+		return -ENOMEM;=0A+=0A+#ifdef CONFIG_X86=0A+	=
BUILD_BUG_ON(FIX_ACPI_PAGES < 4);=0A+	idx =3D virt_to_fix((unsigned =
long)src + 2 * PAGE_SIZE);=0A+	offset +=3D ctx->dst_base;=0A+	dst =3D =
(void *)fix_to_virt(idx) + (offset & ~PAGE_MASK);=0A+	set_fixmap(idx, =
offset);=0A+	if (PFN_DOWN(offset) !=3D PFN_DOWN(offset + ctx->var2 - =
1)) {=0A+		idx =3D virt_to_fix((unsigned long)dst + PAGE_SIZE)=
;=0A+		set_fixmap(idx, offset + PAGE_SIZE);=0A+	}=0A+#else=
=0A+	dst =3D ioremap(ctx->dst_base + offset, ctx->var2);=0A+#endif=0A+	=
if (dst) {=0A+		memmove(dst, src, ctx->var2);=0A+		=
iounmap(dst);=0A+	} else=0A+		rc =3D -ENOMEM;=0A+=0A+	=
iounmap(src);=0A+=0A+	return rc;=0A }=0A =0A static struct apei_exec_ins_=
type erst_ins_type[] =3D {=0A
--=__Part8BBAA855.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__Part8BBAA855.0__=--


From xen-devel-bounces@lists.xen.org Wed Oct 17 11:36:53 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 11:36:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TORvY-0006TT-1u; Wed, 17 Oct 2012 11:36:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TORvX-0006TJ-3C
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 11:36:43 +0000
Received: from [85.158.139.83:32730] by server-13.bemta-5.messagelabs.com id
	1F/37-30674-A489E705; Wed, 17 Oct 2012 11:36:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1350473800!31371356!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5646 invoked from network); 17 Oct 2012 11:36:40 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-182.messagelabs.com with SMTP;
	17 Oct 2012 11:36:40 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 17 Oct 2012 12:36:39 +0100
Message-Id: <507EB46502000078000A1F1E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 17 Oct 2012 12:36:37 +0100
From: "Jan Beulich" 
To: "xen-devel" 
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part8BBAA855.0__="
Subject: [Xen-devel] [PATCH] ACPI/APEI: fix ERST MOVE_DATA instruction
 implementation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part8BBAA855.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

The src_base and dst_base fields in apei_exec_context are physical
address, so they should be ioremaped before being used in ERST
MOVE_DATA instruction.

Reported-by: Javier Martinez Canillas 
Reported-by: Andrew Morton 
Signed-off-by: Huang Ying 

Replace use of ioremap() by __acpi_map_table()/set_fixmap(). Fix error
handling.

Signed-off-by: Jan Beulich 
---
Note that I have no way to test this code other than by having it go
through the tester, since I have no hardware available to reproduce
the regression found there (in other words, this is just a blind
attempt at addressing the problem uncovered by 26060:4fc87c2f31a0).

--- a/xen/drivers/acpi/apei/erst.c
+++ b/xen/drivers/acpi/apei/erst.c
@@ -247,15 +247,64 @@ static int erst_exec_move_data(struct ap
 {
 	int rc;
 	u64 offset;
+#ifdef CONFIG_X86
+	enum fixed_addresses idx;
+#endif
+	void *src, *dst;
+
+	/* ioremap does not work in interrupt context */
+	if (in_irq()) {
+		printk(KERN_WARNING
+		       "MOVE_DATA cannot be used in interrupt context\n");
+		return -EBUSY;
+	}
=20
 	rc =3D __apei_exec_read_register(entry, &offset);
 	if (rc)
 		return rc;
-	memmove((void *)(unsigned long)(ctx->dst_base + offset),
-		(void *)(unsigned long)(ctx->src_base + offset),
-		ctx->var2);
=20
-	return 0;
+#ifdef CONFIG_X86
+	switch (ctx->var2) {
+	case 0:
+		return 0;
+	case 1 ... PAGE_SIZE:
+		break;
+	default:
+		printk(KERN_WARNING
+		       "MOVE_DATA cannot be used for %#"PRIx64" bytes of =
data\n",
+		       ctx->var2);
+		return -EOPNOTSUPP;
+	}
+
+	src =3D __acpi_map_table(ctx->src_base + offset, ctx->var2);
+#else
+	src =3D ioremap(ctx->src_base + offset, ctx->var2);
+#endif
+	if (!src)
+		return -ENOMEM;
+
+#ifdef CONFIG_X86
+	BUILD_BUG_ON(FIX_ACPI_PAGES < 4);
+	idx =3D virt_to_fix((unsigned long)src + 2 * PAGE_SIZE);
+	offset +=3D ctx->dst_base;
+	dst =3D (void *)fix_to_virt(idx) + (offset & ~PAGE_MASK);
+	set_fixmap(idx, offset);
+	if (PFN_DOWN(offset) !=3D PFN_DOWN(offset + ctx->var2 - 1)) {
+		idx =3D virt_to_fix((unsigned long)dst + PAGE_SIZE);
+		set_fixmap(idx, offset + PAGE_SIZE);
+	}
+#else
+	dst =3D ioremap(ctx->dst_base + offset, ctx->var2);
+#endif
+	if (dst) {
+		memmove(dst, src, ctx->var2);
+		iounmap(dst);
+	} else
+		rc =3D -ENOMEM;
+
+	iounmap(src);
+
+	return rc;
 }
=20
 static struct apei_exec_ins_type erst_ins_type[] =3D {




--=__Part8BBAA855.0__=
Content-Type: text/plain; name="ACPI-ERST-move-data-map.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="ACPI-ERST-move-data-map.patch"

ACPI/APEI: fix ERST MOVE_DATA instruction implementation=0A=0AThe src_base =
and dst_base fields in apei_exec_context are physical=0Aaddress, so they =
should be ioremaped before being used in ERST=0AMOVE_DATA instruction.=0A=
=0AReported-by: Javier Martinez Canillas =0ARepo=
rted-by: Andrew Morton =0ASigned-off-by: Huang =
Ying =0A=0AReplace use of ioremap() by __acpi_map_tab=
le()/set_fixmap(). Fix error=0Ahandling.=0A=0ASigned-off-by: Jan Beulich =
=0A---=0ANote that I have no way to test this code =
other than by having it go=0Athrough the tester, since I have no hardware =
available to reproduce=0Athe regression found there (in other words, this =
is just a blind=0Aattempt at addressing the problem uncovered by 26060:4fc8=
7c2f31a0).=0A=0A--- a/xen/drivers/acpi/apei/erst.c=0A+++ b/xen/drivers/acpi=
/apei/erst.c=0A@@ -247,15 +247,64 @@ static int erst_exec_move_data(struct =
ap=0A {=0A 	int rc;=0A 	u64 offset;=0A+#ifdef CONFIG_X86=0A+	=
enum fixed_addresses idx;=0A+#endif=0A+	void *src, *dst;=0A+=0A+	/* =
ioremap does not work in interrupt context */=0A+	if (in_irq()) =
{=0A+		printk(KERN_WARNING=0A+		       "MOVE_DATA cannot =
be used in interrupt context\n");=0A+		return -EBUSY;=0A+	=
}=0A =0A 	rc =3D __apei_exec_read_register(entry, &offset);=0A 	if =
(rc)=0A 		return rc;=0A-	memmove((void *)(unsigned =
long)(ctx->dst_base + offset),=0A-		(void *)(unsigned =
long)(ctx->src_base + offset),=0A-		ctx->var2);=0A =0A-	=
return 0;=0A+#ifdef CONFIG_X86=0A+	switch (ctx->var2) {=0A+	=
case 0:=0A+		return 0;=0A+	case 1 ... PAGE_SIZE:=0A+		=
break;=0A+	default:=0A+		printk(KERN_WARNING=0A+		   =
    "MOVE_DATA cannot be used for %#"PRIx64" bytes of data\n",=0A+		=
       ctx->var2);=0A+		return -EOPNOTSUPP;=0A+	}=0A+=0A+	=
src =3D __acpi_map_table(ctx->src_base + offset, ctx->var2);=0A+#else=0A+	=
src =3D ioremap(ctx->src_base + offset, ctx->var2);=0A+#endif=0A+	if =
(!src)=0A+		return -ENOMEM;=0A+=0A+#ifdef CONFIG_X86=0A+	=
BUILD_BUG_ON(FIX_ACPI_PAGES < 4);=0A+	idx =3D virt_to_fix((unsigned =
long)src + 2 * PAGE_SIZE);=0A+	offset +=3D ctx->dst_base;=0A+	dst =3D =
(void *)fix_to_virt(idx) + (offset & ~PAGE_MASK);=0A+	set_fixmap(idx, =
offset);=0A+	if (PFN_DOWN(offset) !=3D PFN_DOWN(offset + ctx->var2 - =
1)) {=0A+		idx =3D virt_to_fix((unsigned long)dst + PAGE_SIZE)=
;=0A+		set_fixmap(idx, offset + PAGE_SIZE);=0A+	}=0A+#else=
=0A+	dst =3D ioremap(ctx->dst_base + offset, ctx->var2);=0A+#endif=0A+	=
if (dst) {=0A+		memmove(dst, src, ctx->var2);=0A+		=
iounmap(dst);=0A+	} else=0A+		rc =3D -ENOMEM;=0A+=0A+	=
iounmap(src);=0A+=0A+	return rc;=0A }=0A =0A static struct apei_exec_ins_=
type erst_ins_type[] =3D {=0A
--=__Part8BBAA855.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__Part8BBAA855.0__=--


From xen-devel-bounces@lists.xen.org Wed Oct 17 11:43:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 11:43:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOS1S-0006l5-2B; Wed, 17 Oct 2012 11:42:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOS1Q-0006ky-MR
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 11:42:48 +0000
Received: from [85.158.139.83:40136] by server-14.bemta-5.messagelabs.com id
	2D/46-24068-5B99E705; Wed, 17 Oct 2012 11:42:45 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1350474163!29644434!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzcwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23625 invoked from network); 17 Oct 2012 11:42:45 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 11:42:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,600,1344211200"; d="scan'208";a="41488801"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 11:42:43 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 07:42:43 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TOS1K-0006UL-PE;
	Wed, 17 Oct 2012 12:42:42 +0100
From: David Vrabel 
To: xen-devel@lists.xen.org
Date: Wed, 17 Oct 2012 12:42:30 +0100
Message-ID: <1350474150-3990-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: stable@kernel.org, Frediano Ziglio ,
	David Vrabel ,
	Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH] xen/x86: don't corrupt %eip when returning from
	a signal handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel 

In 32 bit guests, if a userspace process has %eax == -ERESTARTSYS
(-512) or -ERESTARTNOINTR (-513) when it is interrupted by an event
/and/ the process has a pending signal then %eip (and %eax) are
corrupted when returning to the main process after handling the
signal.  The application may then crash with SIGSEGV or a SIGILL or it
may have subtly incorrect behaviour (depending on what instruction it
returned to).

The occurs because handle_signal() is incorrectly thinking that there
is a system call that needs to restarted so it adjusts %eip and %eax
to re-execute the system call instruction (even though user space had
not done a system call).

If %eax == -514 (-ERESTARTNOHAND (-514) or -ERESTART_RESTARTBLOCK
(-516) then handle_signal() only corrupted %eax (by setting it to
-EINTR).  This may cause the application to crash or have incorrect
behaviour.

handle_signal() assumes that regs->orig_ax >= 0 means a system call so
any kernel entry point that is not for a system call must push a
negative value for orig_ax.  For example, for physical interrupts on
bare metal the inverse of the vector is pushed and page_fault() sets
regs->orig_ax to -1, overwriting the hardware provided error code.

xen_hypervisor_callback() was incorrectly pushing 0 for orig_ax
instead of -1.  For consistency, we also change
xen_failsafe_callback().

Classic Xen kernels pushed %eax which works as %eax cannot be both
non-negative and -RESTARTSYS (etc.), but using -1 avoids the
additional tests in handle_signal().

Signed-off-by: David Vrabel 
Cc: stable@kernel.org
---
 arch/x86/kernel/entry_32.S |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
index 2c63407..6a19e66 100644
--- a/arch/x86/kernel/entry_32.S
+++ b/arch/x86/kernel/entry_32.S
@@ -1042,7 +1042,7 @@ ENTRY(xen_sysenter_target)
 
 ENTRY(xen_hypervisor_callback)
 	CFI_STARTPROC
-	pushl_cfi $0
+	pushl_cfi $-1 /* orig_ax = -1 => not a system call */
 	SAVE_ALL
 	TRACE_IRQS_OFF
 
@@ -1078,7 +1078,7 @@ ENDPROC(xen_hypervisor_callback)
 # We distinguish between categories by maintaining a status value in EAX.
 ENTRY(xen_failsafe_callback)
 	CFI_STARTPROC
-	pushl_cfi %eax
+	pushl_cfi $-1  /* orig_ax = -1 => not a system call */
 	movl $1,%eax
 1:	mov 4(%esp),%ds
 2:	mov 8(%esp),%es
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 11:43:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 11:43:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOS1S-0006l5-2B; Wed, 17 Oct 2012 11:42:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOS1Q-0006ky-MR
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 11:42:48 +0000
Received: from [85.158.139.83:40136] by server-14.bemta-5.messagelabs.com id
	2D/46-24068-5B99E705; Wed, 17 Oct 2012 11:42:45 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1350474163!29644434!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzcwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23625 invoked from network); 17 Oct 2012 11:42:45 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 11:42:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,600,1344211200"; d="scan'208";a="41488801"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 11:42:43 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 07:42:43 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TOS1K-0006UL-PE;
	Wed, 17 Oct 2012 12:42:42 +0100
From: David Vrabel 
To: xen-devel@lists.xen.org
Date: Wed, 17 Oct 2012 12:42:30 +0100
Message-ID: <1350474150-3990-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: stable@kernel.org, Frediano Ziglio ,
	David Vrabel ,
	Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH] xen/x86: don't corrupt %eip when returning from
	a signal handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel 

In 32 bit guests, if a userspace process has %eax == -ERESTARTSYS
(-512) or -ERESTARTNOINTR (-513) when it is interrupted by an event
/and/ the process has a pending signal then %eip (and %eax) are
corrupted when returning to the main process after handling the
signal.  The application may then crash with SIGSEGV or a SIGILL or it
may have subtly incorrect behaviour (depending on what instruction it
returned to).

The occurs because handle_signal() is incorrectly thinking that there
is a system call that needs to restarted so it adjusts %eip and %eax
to re-execute the system call instruction (even though user space had
not done a system call).

If %eax == -514 (-ERESTARTNOHAND (-514) or -ERESTART_RESTARTBLOCK
(-516) then handle_signal() only corrupted %eax (by setting it to
-EINTR).  This may cause the application to crash or have incorrect
behaviour.

handle_signal() assumes that regs->orig_ax >= 0 means a system call so
any kernel entry point that is not for a system call must push a
negative value for orig_ax.  For example, for physical interrupts on
bare metal the inverse of the vector is pushed and page_fault() sets
regs->orig_ax to -1, overwriting the hardware provided error code.

xen_hypervisor_callback() was incorrectly pushing 0 for orig_ax
instead of -1.  For consistency, we also change
xen_failsafe_callback().

Classic Xen kernels pushed %eax which works as %eax cannot be both
non-negative and -RESTARTSYS (etc.), but using -1 avoids the
additional tests in handle_signal().

Signed-off-by: David Vrabel 
Cc: stable@kernel.org
---
 arch/x86/kernel/entry_32.S |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
index 2c63407..6a19e66 100644
--- a/arch/x86/kernel/entry_32.S
+++ b/arch/x86/kernel/entry_32.S
@@ -1042,7 +1042,7 @@ ENTRY(xen_sysenter_target)
 
 ENTRY(xen_hypervisor_callback)
 	CFI_STARTPROC
-	pushl_cfi $0
+	pushl_cfi $-1 /* orig_ax = -1 => not a system call */
 	SAVE_ALL
 	TRACE_IRQS_OFF
 
@@ -1078,7 +1078,7 @@ ENDPROC(xen_hypervisor_callback)
 # We distinguish between categories by maintaining a status value in EAX.
 ENTRY(xen_failsafe_callback)
 	CFI_STARTPROC
-	pushl_cfi %eax
+	pushl_cfi $-1  /* orig_ax = -1 => not a system call */
 	movl $1,%eax
 1:	mov 4(%esp),%ds
 2:	mov 8(%esp),%es
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 11:46:15 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 11:46:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOS4X-0006sB-M4; Wed, 17 Oct 2012 11:46:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOS4V-0006s0-DA
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 11:45:59 +0000
Received: from [85.158.143.99:20651] by server-1.bemta-4.messagelabs.com id
	37/44-19134-67A9E705; Wed, 17 Oct 2012 11:45:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1350474357!34440102!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17576 invoked from network); 17 Oct 2012 11:45:57 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-216.messagelabs.com with SMTP;
	17 Oct 2012 11:45:57 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 17 Oct 2012 12:45:56 +0100
Message-Id: <507EB69302000078000A1F46@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 17 Oct 2012 12:45:55 +0100
From: "Jan Beulich" 
To: "Keir Fraser" 
References: <507DA35102000078000A1C26@nat28.tlf.novell.com>
	
In-Reply-To: 
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartBF8E9C63.1__="
Cc: xen-devel 
Subject: [Xen-devel] [PATCH v2 1/3] x86/HPET: obtain proper lock for
 changing IRQ affinity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartBF8E9C63.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

The IRQ descriptor lock should be held while adjusting the affinity of
any IRQ; the HPET channel lock isn't sufficient to protect namely
against races with moving the IRQ to a different CPU.

Signed-off-by: Jan Beulich 
---
v2: rename new helper function

--- a/xen/arch/x86/hpet.c
+++ b/xen/arch/x86/hpet.c
@@ -436,6 +436,16 @@ static struct hpet_event_channel *hpet_g
     return ch;
 }
=20
+static void set_channel_irq_affinity(const struct hpet_event_channel *ch)
+{
+    struct irq_desc *desc =3D irq_to_desc(ch->irq);
+
+    ASSERT(!local_irq_is_enabled());
+    spin_lock(&desc->lock);
+    hpet_msi_set_affinity(desc, cpumask_of(ch->cpu));
+    spin_unlock(&desc->lock);
+}
+
 static void hpet_attach_channel(unsigned int cpu,
                                 struct hpet_event_channel *ch)
 {
@@ -450,7 +460,7 @@ static void hpet_attach_channel(unsigned
     if ( ch->cpu !=3D cpu )
         return;
=20
-    hpet_msi_set_affinity(irq_to_desc(ch->irq), cpumask_of(ch->cpu));
+    set_channel_irq_affinity(ch);
 }
=20
 static void hpet_detach_channel(unsigned int cpu,
@@ -472,7 +482,7 @@ static void hpet_detach_channel(unsigned
     }
=20
     ch->cpu =3D cpumask_first(ch->cpumask);
-    hpet_msi_set_affinity(irq_to_desc(ch->irq), cpumask_of(ch->cpu));
+    set_channel_irq_affinity(ch);
 }
=20
 #include 




--=__PartBF8E9C63.1__=
Content-Type: text/plain; name="x86-HPET-affinity-lock.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-HPET-affinity-lock.patch"

x86/HPET: obtain proper lock for changing IRQ affinity=0A=0AThe IRQ =
descriptor lock should be held while adjusting the affinity of=0Aany IRQ; =
the HPET channel lock isn't sufficient to protect namely=0Aagainst races =
with moving the IRQ to a different CPU.=0A=0ASigned-off-by: Jan Beulich =
=0A---=0Av2: rename new helper function=0A=0A--- =
a/xen/arch/x86/hpet.c=0A+++ b/xen/arch/x86/hpet.c=0A@@ -436,6 +436,16 @@ =
static struct hpet_event_channel *hpet_g=0A     return ch;=0A }=0A =
=0A+static void set_channel_irq_affinity(const struct hpet_event_channel =
*ch)=0A+{=0A+    struct irq_desc *desc =3D irq_to_desc(ch->irq);=0A+=0A+   =
 ASSERT(!local_irq_is_enabled());=0A+    spin_lock(&desc->lock);=0A+    =
hpet_msi_set_affinity(desc, cpumask_of(ch->cpu));=0A+    spin_unlock(&desc-=
>lock);=0A+}=0A+=0A static void hpet_attach_channel(unsigned int cpu,=0A   =
                              struct hpet_event_channel *ch)=0A {=0A@@ =
-450,7 +460,7 @@ static void hpet_attach_channel(unsigned=0A     if ( =
ch->cpu !=3D cpu )=0A         return;=0A =0A-    hpet_msi_set_affinity(irq_=
to_desc(ch->irq), cpumask_of(ch->cpu));=0A+    set_channel_irq_affinity(ch)=
;=0A }=0A =0A static void hpet_detach_channel(unsigned int cpu,=0A@@ =
-472,7 +482,7 @@ static void hpet_detach_channel(unsigned=0A     }=0A =0A  =
   ch->cpu =3D cpumask_first(ch->cpumask);=0A-    hpet_msi_set_affinity(irq=
_to_desc(ch->irq), cpumask_of(ch->cpu));=0A+    set_channel_irq_affinity(ch=
);=0A }=0A =0A #include =0A
--=__PartBF8E9C63.1__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__PartBF8E9C63.1__=--


From xen-devel-bounces@lists.xen.org Wed Oct 17 11:46:15 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 11:46:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOS4X-0006sB-M4; Wed, 17 Oct 2012 11:46:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOS4V-0006s0-DA
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 11:45:59 +0000
Received: from [85.158.143.99:20651] by server-1.bemta-4.messagelabs.com id
	37/44-19134-67A9E705; Wed, 17 Oct 2012 11:45:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1350474357!34440102!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17576 invoked from network); 17 Oct 2012 11:45:57 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-216.messagelabs.com with SMTP;
	17 Oct 2012 11:45:57 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 17 Oct 2012 12:45:56 +0100
Message-Id: <507EB69302000078000A1F46@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 17 Oct 2012 12:45:55 +0100
From: "Jan Beulich" 
To: "Keir Fraser" 
References: <507DA35102000078000A1C26@nat28.tlf.novell.com>
	
In-Reply-To: 
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartBF8E9C63.1__="
Cc: xen-devel 
Subject: [Xen-devel] [PATCH v2 1/3] x86/HPET: obtain proper lock for
 changing IRQ affinity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartBF8E9C63.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

The IRQ descriptor lock should be held while adjusting the affinity of
any IRQ; the HPET channel lock isn't sufficient to protect namely
against races with moving the IRQ to a different CPU.

Signed-off-by: Jan Beulich 
---
v2: rename new helper function

--- a/xen/arch/x86/hpet.c
+++ b/xen/arch/x86/hpet.c
@@ -436,6 +436,16 @@ static struct hpet_event_channel *hpet_g
     return ch;
 }
=20
+static void set_channel_irq_affinity(const struct hpet_event_channel *ch)
+{
+    struct irq_desc *desc =3D irq_to_desc(ch->irq);
+
+    ASSERT(!local_irq_is_enabled());
+    spin_lock(&desc->lock);
+    hpet_msi_set_affinity(desc, cpumask_of(ch->cpu));
+    spin_unlock(&desc->lock);
+}
+
 static void hpet_attach_channel(unsigned int cpu,
                                 struct hpet_event_channel *ch)
 {
@@ -450,7 +460,7 @@ static void hpet_attach_channel(unsigned
     if ( ch->cpu !=3D cpu )
         return;
=20
-    hpet_msi_set_affinity(irq_to_desc(ch->irq), cpumask_of(ch->cpu));
+    set_channel_irq_affinity(ch);
 }
=20
 static void hpet_detach_channel(unsigned int cpu,
@@ -472,7 +482,7 @@ static void hpet_detach_channel(unsigned
     }
=20
     ch->cpu =3D cpumask_first(ch->cpumask);
-    hpet_msi_set_affinity(irq_to_desc(ch->irq), cpumask_of(ch->cpu));
+    set_channel_irq_affinity(ch);
 }
=20
 #include 




--=__PartBF8E9C63.1__=
Content-Type: text/plain; name="x86-HPET-affinity-lock.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-HPET-affinity-lock.patch"

x86/HPET: obtain proper lock for changing IRQ affinity=0A=0AThe IRQ =
descriptor lock should be held while adjusting the affinity of=0Aany IRQ; =
the HPET channel lock isn't sufficient to protect namely=0Aagainst races =
with moving the IRQ to a different CPU.=0A=0ASigned-off-by: Jan Beulich =
=0A---=0Av2: rename new helper function=0A=0A--- =
a/xen/arch/x86/hpet.c=0A+++ b/xen/arch/x86/hpet.c=0A@@ -436,6 +436,16 @@ =
static struct hpet_event_channel *hpet_g=0A     return ch;=0A }=0A =
=0A+static void set_channel_irq_affinity(const struct hpet_event_channel =
*ch)=0A+{=0A+    struct irq_desc *desc =3D irq_to_desc(ch->irq);=0A+=0A+   =
 ASSERT(!local_irq_is_enabled());=0A+    spin_lock(&desc->lock);=0A+    =
hpet_msi_set_affinity(desc, cpumask_of(ch->cpu));=0A+    spin_unlock(&desc-=
>lock);=0A+}=0A+=0A static void hpet_attach_channel(unsigned int cpu,=0A   =
                              struct hpet_event_channel *ch)=0A {=0A@@ =
-450,7 +460,7 @@ static void hpet_attach_channel(unsigned=0A     if ( =
ch->cpu !=3D cpu )=0A         return;=0A =0A-    hpet_msi_set_affinity(irq_=
to_desc(ch->irq), cpumask_of(ch->cpu));=0A+    set_channel_irq_affinity(ch)=
;=0A }=0A =0A static void hpet_detach_channel(unsigned int cpu,=0A@@ =
-472,7 +482,7 @@ static void hpet_detach_channel(unsigned=0A     }=0A =0A  =
   ch->cpu =3D cpumask_first(ch->cpumask);=0A-    hpet_msi_set_affinity(irq=
_to_desc(ch->irq), cpumask_of(ch->cpu));=0A+    set_channel_irq_affinity(ch=
);=0A }=0A =0A #include =0A
--=__PartBF8E9C63.1__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__PartBF8E9C63.1__=--


From xen-devel-bounces@lists.xen.org Wed Oct 17 11:47:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 11:47:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOS5h-0006xn-TM; Wed, 17 Oct 2012 11:47:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOS5g-0006xZ-21
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 11:47:12 +0000
Received: from [85.158.143.99:32920] by server-1.bemta-4.messagelabs.com id
	90/26-19134-FBA9E705; Wed, 17 Oct 2012 11:47:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1350474429!33851465!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17110 invoked from network); 17 Oct 2012 11:47:09 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-216.messagelabs.com with SMTP;
	17 Oct 2012 11:47:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 17 Oct 2012 12:47:09 +0100
Message-Id: <507EB6DB02000078000A1F4A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 17 Oct 2012 12:47:07 +0100
From: "Jan Beulich" 
To: "xen-devel" 
References: <507D93C102000078000A1BAB@nat28.tlf.novell.com>
	<507D94FE02000078000A1BC1@nat28.tlf.novell.com>
In-Reply-To: <507D94FE02000078000A1BC1@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part774654AB.1__="
Cc: xiantao.zhang@intel.com
Subject: [Xen-devel] [PATCH v2 2/3] x86/HPET: allow use for broadcast when
 interrupt remapping is in effect
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part774654AB.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This requires some additions to the VT-d side; AMD IOMMUs use the
"normal" MSI message format even when interrupt remapping is enabled,
thus making adjustments here unnecessary.

Signed-off-by: Jan Beulich 
---
v2: refresh after updating patch 1 of this series (patch 3 is unchanged)

--- a/xen/arch/x86/acpi/boot.c
+++ b/xen/arch/x86/acpi/boot.c
@@ -276,6 +276,7 @@ static int __init acpi_parse_hpet(struct
 	}
=20
 	hpet_address =3D hpet_tbl->address.address;
+	hpet_blockid =3D hpet_tbl->sequence;
 	printk(KERN_INFO PREFIX "HPET id: %#x base: %#lx\n",
 	       hpet_tbl->id, hpet_address);
=20
--- a/xen/arch/x86/hpet.c
+++ b/xen/arch/x86/hpet.c
@@ -40,7 +40,7 @@ struct hpet_event_channel
=20
     unsigned int idx;   /* physical channel idx */
     unsigned int cpu;   /* msi target */
-    int irq;            /* msi irq */
+    struct msi_desc msi;/* msi state */
     unsigned int flags; /* HPET_EVT_x */
 } __cacheline_aligned;
 static struct hpet_event_channel *__read_mostly hpet_events;
@@ -51,6 +51,7 @@ static unsigned int __read_mostly num_hp
 DEFINE_PER_CPU(struct hpet_event_channel *, cpu_bc_channel);
=20
 unsigned long __read_mostly hpet_address;
+u8 __initdata hpet_blockid;
=20
 /*
  * force_hpet_broadcast: by default legacy hpet broadcast will be stopped
@@ -252,6 +253,8 @@ static void hpet_msi_mask(struct irq_des
=20
 static void hpet_msi_write(struct hpet_event_channel *ch, struct msi_msg =
*msg)
 {
+    if ( iommu_intremap )
+        iommu_update_ire_from_msi(&ch->msi, msg);
     hpet_write32(msg->data, HPET_Tn_ROUTE(ch->idx));
     hpet_write32(msg->address_lo, HPET_Tn_ROUTE(ch->idx) + 4);
 }
@@ -261,6 +264,8 @@ static void hpet_msi_read(struct hpet_ev
     msg->data =3D hpet_read32(HPET_Tn_ROUTE(ch->idx));
     msg->address_lo =3D hpet_read32(HPET_Tn_ROUTE(ch->idx) + 4);
     msg->address_hi =3D 0;
+    if ( iommu_intremap )
+        iommu_read_msi_from_ire(&ch->msi, msg);
 }
=20
 static unsigned int hpet_msi_startup(struct irq_desc *desc)
@@ -292,6 +297,7 @@ static void hpet_msi_set_affinity(struct
     msg.data |=3D MSI_DATA_VECTOR(desc->arch.vector);
     msg.address_lo &=3D ~MSI_ADDR_DEST_ID_MASK;
     msg.address_lo |=3D MSI_ADDR_DEST_ID(dest);
+    msg.dest32 =3D dest;
     hpet_msi_write(desc->action->dev_id, &msg);
 }
=20
@@ -316,35 +322,48 @@ static void __hpet_setup_msi_irq(struct=20
     hpet_msi_write(desc->action->dev_id, &msg);
 }
=20
-static int __init hpet_setup_msi_irq(unsigned int irq, struct hpet_event_c=
hannel *ch)
+static int __init hpet_setup_msi_irq(struct hpet_event_channel *ch)
 {
     int ret;
-    irq_desc_t *desc =3D irq_to_desc(irq);
+    irq_desc_t *desc =3D irq_to_desc(ch->msi.irq);
+
+    if ( iommu_intremap )
+    {
+        ch->msi.hpet_id =3D hpet_blockid;
+        ret =3D iommu_setup_hpet_msi(&ch->msi);
+        if ( ret )
+            return ret;
+    }
=20
     desc->handler =3D &hpet_msi_type;
-    ret =3D request_irq(irq, hpet_interrupt_handler, 0, "HPET", ch);
+    ret =3D request_irq(ch->msi.irq, hpet_interrupt_handler, 0, "HPET", =
ch);
     if ( ret < 0 )
+    {
+        if ( iommu_intremap )
+            iommu_update_ire_from_msi(&ch->msi, NULL);
         return ret;
+    }
=20
     __hpet_setup_msi_irq(desc);
=20
     return 0;
 }
=20
-static int __init hpet_assign_irq(unsigned int idx)
+static int __init hpet_assign_irq(struct hpet_event_channel *ch)
 {
     int irq;
=20
     if ( (irq =3D create_irq(NUMA_NO_NODE)) < 0 )
         return irq;
=20
-    if ( hpet_setup_msi_irq(irq, hpet_events + idx) )
+    ch->msi.irq =3D irq;
+    if ( hpet_setup_msi_irq(ch) )
     {
         destroy_irq(irq);
         return -EINVAL;
     }
=20
-    return irq;
+    return 0;
 }
=20
 static void __init hpet_fsb_cap_lookup(void)
@@ -352,14 +371,6 @@ static void __init hpet_fsb_cap_lookup(v
     u32 id;
     unsigned int i, num_chs;
=20
-    /* TODO. */
-    if ( iommu_intremap )
-    {
-        printk(XENLOG_INFO "HPET's MSI mode hasn't been supported when "
-            "Interrupt Remapping is enabled.\n");
-        return;
-    }
-
     id =3D hpet_read32(HPET_ID);
=20
     num_chs =3D ((id & HPET_ID_NUMBER) >> HPET_ID_NUMBER_SHIFT);
@@ -391,8 +402,8 @@ static void __init hpet_fsb_cap_lookup(v
         ch->flags =3D 0;
         ch->idx =3D i;
=20
-        if ( (ch->irq =3D hpet_assign_irq(num_hpets_used++)) < 0 )
-            num_hpets_used--;
+        if ( hpet_assign_irq(ch) =3D=3D 0 )
+            num_hpets_used++;
     }
=20
     printk(XENLOG_INFO "HPET: %u timers (%u will be used for broadcast)\n"=
,
@@ -438,7 +449,7 @@ static struct hpet_event_channel *hpet_g
=20
 static void set_channel_irq_affinity(const struct hpet_event_channel *ch)
 {
-    struct irq_desc *desc =3D irq_to_desc(ch->irq);
+    struct irq_desc *desc =3D irq_to_desc(ch->msi.irq);
=20
     ASSERT(!local_irq_is_enabled());
     spin_lock(&desc->lock);
@@ -530,7 +541,7 @@ void __init hpet_broadcast_init(void)
             hpet_events =3D xzalloc(struct hpet_event_channel);
         if ( !hpet_events || !zalloc_cpumask_var(&hpet_events->cpumask) )
             return;
-        hpet_events->irq =3D -1;
+        hpet_events->msi.irq =3D -1;
=20
         /* Start HPET legacy interrupts */
         cfg |=3D HPET_CFG_LEGACY;
@@ -598,8 +609,8 @@ void hpet_broadcast_resume(void)
=20
     for ( i =3D 0; i < n; i++ )
     {
-        if ( hpet_events[i].irq >=3D 0 )
-            __hpet_setup_msi_irq(irq_to_desc(hpet_events[i].irq));
+        if ( hpet_events[i].msi.irq >=3D 0 )
+            __hpet_setup_msi_irq(irq_to_desc(hpet_events[i].msi.irq));
=20
         /* set HPET Tn as oneshot */
         cfg =3D hpet_read32(HPET_Tn_CFG(hpet_events[i].idx));
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -495,6 +495,12 @@ unsigned int iommu_read_apic_from_ire(un
     return ops->read_apic_from_ire(apic, reg);
 }
=20
+int __init iommu_setup_hpet_msi(struct msi_desc *msi)
+{
+    const struct iommu_ops *ops =3D iommu_get_ops();
+    return ops->setup_hpet_msi ? ops->setup_hpet_msi(msi) : 0;
+}
+
 void iommu_resume()
 {
     const struct iommu_ops *ops =3D iommu_get_ops();
--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -147,6 +147,34 @@ struct iommu * ioapic_to_iommu(unsigned=20
     return NULL;
 }
=20
+static bool_t acpi_hpet_device_match(
+    struct list_head *list, unsigned int hpet_id)
+{
+    struct acpi_hpet_unit *hpet;
+
+    list_for_each_entry( hpet, list, list )
+        if (hpet->id =3D=3D hpet_id)
+            return 1;
+    return 0;
+}
+
+struct acpi_drhd_unit *hpet_to_drhd(unsigned int hpet_id)
+{
+    struct acpi_drhd_unit *drhd;
+
+    list_for_each_entry( drhd, &acpi_drhd_units, list )
+        if ( acpi_hpet_device_match(&drhd->hpet_list, hpet_id) )
+            return drhd;
+    return NULL;
+}
+
+struct iommu *hpet_to_iommu(unsigned int hpet_id)
+{
+    struct acpi_drhd_unit *drhd =3D hpet_to_drhd(hpet_id);
+
+    return drhd ? drhd->iommu : NULL;
+}
+
 static int __init acpi_register_atsr_unit(struct acpi_atsr_unit *atsr)
 {
     /*
@@ -330,6 +358,22 @@ static int __init acpi_parse_dev_scope(
             if ( iommu_verbose )
                 dprintk(VTDPREFIX, " MSI HPET: %04x:%02x:%02x.%u\n",
                         seg, bus, path->dev, path->fn);
+
+            if ( type =3D=3D DMAR_TYPE )
+            {
+                struct acpi_drhd_unit *drhd =3D acpi_entry;
+                struct acpi_hpet_unit *acpi_hpet_unit;
+
+                acpi_hpet_unit =3D xmalloc(struct acpi_hpet_unit);
+                if ( !acpi_hpet_unit )
+                    return -ENOMEM;
+                acpi_hpet_unit->id =3D acpi_scope->enumeration_id;
+                acpi_hpet_unit->bus =3D bus;
+                acpi_hpet_unit->dev =3D path->dev;
+                acpi_hpet_unit->func =3D path->fn;
+                list_add(&acpi_hpet_unit->list, &drhd->hpet_list);
+            }
+
             break;
=20
         case ACPI_DMAR_SCOPE_TYPE_ENDPOINT:
@@ -407,6 +451,7 @@ acpi_parse_one_drhd(struct acpi_dmar_hea
     dmaru->segment =3D drhd->segment;
     dmaru->include_all =3D drhd->flags & ACPI_DMAR_INCLUDE_ALL;
     INIT_LIST_HEAD(&dmaru->ioapic_list);
+    INIT_LIST_HEAD(&dmaru->hpet_list);
     if ( iommu_verbose )
         dprintk(VTDPREFIX, "  dmaru->address =3D %"PRIx64"\n",
                 dmaru->address);
--- a/xen/drivers/passthrough/vtd/dmar.h
+++ b/xen/drivers/passthrough/vtd/dmar.h
@@ -39,6 +39,19 @@ struct acpi_ioapic_unit {
     }ioapic;
 };
=20
+struct acpi_hpet_unit {
+    struct list_head list;
+    unsigned int id;
+    union {
+        u16 bdf;
+        struct {
+            u16 func: 3,
+                dev:  5,
+                bus:  8;
+        };
+    };
+};
+
 struct dmar_scope {
     DECLARE_BITMAP(buses, 256);         /* buses owned by this unit */
     u16    *devices;                    /* devices owned by this unit */
@@ -53,6 +66,7 @@ struct acpi_drhd_unit {
     u8     include_all:1;
     struct iommu *iommu;
     struct list_head ioapic_list;
+    struct list_head hpet_list;
 };
=20
 struct acpi_rmrr_unit {
--- a/xen/drivers/passthrough/vtd/extern.h
+++ b/xen/drivers/passthrough/vtd/extern.h
@@ -54,7 +54,9 @@ int iommu_flush_iec_index(struct iommu *
 void clear_fault_bits(struct iommu *iommu);
=20
 struct iommu * ioapic_to_iommu(unsigned int apic_id);
+struct iommu * hpet_to_iommu(unsigned int hpet_id);
 struct acpi_drhd_unit * ioapic_to_drhd(unsigned int apic_id);
+struct acpi_drhd_unit * hpet_to_drhd(unsigned int hpet_id);
 struct acpi_drhd_unit * iommu_to_drhd(struct iommu *iommu);
 struct acpi_rhsa_unit * drhd_to_rhsa(struct acpi_drhd_unit *drhd);
=20
@@ -90,6 +92,8 @@ struct msi_msg;
 void msi_msg_read_remap_rte(struct msi_desc *, struct msi_msg *);
 void msi_msg_write_remap_rte(struct msi_desc *, struct msi_msg *);
=20
+int intel_setup_hpet_msi(struct msi_desc *);
+
 int is_igd_vt_enabled_quirk(void);
 void platform_quirks_init(void);
 void vtd_ops_preamble_quirk(struct iommu* iommu);
--- a/xen/drivers/passthrough/vtd/intremap.c
+++ b/xen/drivers/passthrough/vtd/intremap.c
@@ -107,6 +107,19 @@ static u16 apicid_to_bdf(int apic_id)
     return 0;
 }
=20
+static u16 hpetid_to_bdf(unsigned int hpet_id)
+{
+    struct acpi_drhd_unit *drhd =3D hpet_to_drhd(hpet_id);
+    struct acpi_hpet_unit *acpi_hpet_unit;
+
+    list_for_each_entry ( acpi_hpet_unit, &drhd->hpet_list, list )
+        if ( acpi_hpet_unit->id =3D=3D hpet_id )
+            return acpi_hpet_unit->bdf;
+
+    dprintk(XENLOG_ERR VTDPREFIX, "Didn't find the bdf for HPET %u!\n", =
hpet_id);
+    return 0;
+}
+
 static void set_ire_sid(struct iremap_entry *ire,
                         unsigned int svt, unsigned int sq, unsigned int =
sid)
 {
@@ -121,6 +134,16 @@ static void set_ioapic_source_id(int api
                 apicid_to_bdf(apic_id));
 }
=20
+static void set_hpet_source_id(unsigned int id, struct iremap_entry *ire)
+{
+    /*
+     * Should really use SQ_ALL_16. Some platforms are broken.
+     * While we figure out the right quirks for these broken platforms, =
use
+     * SQ_13_IGNORE_3 for now.
+     */
+    set_ire_sid(ire, SVT_VERIFY_SID_SQ, SQ_13_IGNORE_3, hpetid_to_bdf(id))=
;
+}
+
 int iommu_supports_eim(void)
 {
     struct acpi_drhd_unit *drhd;
@@ -592,7 +615,10 @@ static int msi_msg_to_remap_entry(
         new_ire.lo.dst =3D ((msg->address_lo >> MSI_ADDR_DEST_ID_SHIFT)
                           & 0xff) << 8;
=20
-    set_msi_source_id(pdev, &new_ire);
+    if ( pdev )
+        set_msi_source_id(pdev, &new_ire);
+    else
+        set_hpet_source_id(msi_desc->hpet_id, &new_ire);
     new_ire.hi.res_1 =3D 0;
     new_ire.lo.p =3D 1;    /* finally, set present bit */
=20
@@ -624,7 +650,9 @@ void msi_msg_read_remap_rte(
     struct iommu *iommu =3D NULL;
     struct ir_ctrl *ir_ctrl;
=20
-    if ( (drhd =3D acpi_find_matched_drhd_unit(pdev)) =3D=3D NULL )
+    drhd =3D pdev ? acpi_find_matched_drhd_unit(pdev)
+                : hpet_to_drhd(msi_desc->hpet_id);
+    if ( !drhd )
         return;
     iommu =3D drhd->iommu;
=20
@@ -643,7 +671,9 @@ void msi_msg_write_remap_rte(
     struct iommu *iommu =3D NULL;
     struct ir_ctrl *ir_ctrl;
=20
-    if ( (drhd =3D acpi_find_matched_drhd_unit(pdev)) =3D=3D NULL )
+    drhd =3D pdev ? acpi_find_matched_drhd_unit(pdev)
+                : hpet_to_drhd(msi_desc->hpet_id);
+    if ( !drhd )
         return;
     iommu =3D drhd->iommu;
=20
@@ -654,6 +684,32 @@ void msi_msg_write_remap_rte(
     msi_msg_to_remap_entry(iommu, pdev, msi_desc, msg);
 }
=20
+int __init intel_setup_hpet_msi(struct msi_desc *msi_desc)
+{
+    struct iommu *iommu =3D hpet_to_iommu(msi_desc->hpet_id);
+    struct ir_ctrl *ir_ctrl =3D iommu_ir_ctrl(iommu);
+    unsigned long flags;
+    int rc =3D 0;
+
+    if ( !ir_ctrl || !ir_ctrl->iremap_maddr )
+        return 0;
+
+    spin_lock_irqsave(&ir_ctrl->iremap_lock, flags);
+    msi_desc->remap_index =3D alloc_remap_entry(iommu);
+    if ( msi_desc->remap_index >=3D IREMAP_ENTRY_NR )
+    {
+        dprintk(XENLOG_ERR VTDPREFIX,
+                "%s: intremap index (%d) is larger than"
+                " the maximum index (%d)!\n",
+                __func__, msi_desc->remap_index, IREMAP_ENTRY_NR - 1);
+        msi_desc->remap_index =3D -1;
+        rc =3D -ENXIO;
+    }
+    spin_unlock_irqrestore(&ir_ctrl->iremap_lock, flags);
+
+    return rc;
+}
+
 int enable_intremap(struct iommu *iommu, int eim)
 {
     struct acpi_drhd_unit *drhd;
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -2396,6 +2396,7 @@ const struct iommu_ops intel_iommu_ops =3D
     .update_ire_from_msi =3D msi_msg_write_remap_rte,
     .read_apic_from_ire =3D io_apic_read_remap_rte,
     .read_msi_from_ire =3D msi_msg_read_remap_rte,
+    .setup_hpet_msi =3D intel_setup_hpet_msi,
     .suspend =3D vtd_suspend,
     .resume =3D vtd_resume,
     .share_p2m =3D iommu_set_pgd,
--- a/xen/include/asm-x86/hpet.h
+++ b/xen/include/asm-x86/hpet.h
@@ -53,6 +53,7 @@
     (*(volatile u32 *)(fix_to_virt(FIX_HPET_BASE) + (x)) =3D (y))
=20
 extern unsigned long hpet_address;
+extern u8 hpet_blockid;
=20
 /*
  * Detect and initialise HPET hardware: return counter update frequency.
--- a/xen/include/asm-x86/msi.h
+++ b/xen/include/asm-x86/msi.h
@@ -97,7 +97,10 @@ struct msi_desc {
=20
 	struct list_head list;
=20
-	void __iomem *mask_base;        /* va for the entry in mask table =
*/
+	union {
+		void __iomem *mask_base;/* va for the entry in mask table =
*/
+		unsigned int hpet_id;   /* HPET (dev is NULL)             =
*/
+	};
 	struct pci_dev *dev;
 	int irq;
=20
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -109,6 +109,7 @@ struct iommu_ops {
     void (*update_ire_from_msi)(struct msi_desc *msi_desc, struct msi_msg =
*msg);
     void (*read_msi_from_ire)(struct msi_desc *msi_desc, struct msi_msg =
*msg);
     unsigned int (*read_apic_from_ire)(unsigned int apic, unsigned int =
reg);
+    int (*setup_hpet_msi)(struct msi_desc *);
     void (*suspend)(void);
     void (*resume)(void);
     void (*share_p2m)(struct domain *d);
@@ -122,6 +123,7 @@ void iommu_update_ire_from_apic(unsigned
 void iommu_update_ire_from_msi(struct msi_desc *msi_desc, struct msi_msg =
*msg);
 void iommu_read_msi_from_ire(struct msi_desc *msi_desc, struct msi_msg =
*msg);
 unsigned int iommu_read_apic_from_ire(unsigned int apic, unsigned int =
reg);
+int iommu_setup_hpet_msi(struct msi_desc *);
=20
 void iommu_suspend(void);
 void iommu_resume(void);



--=__Part774654AB.1__=
Content-Type: text/plain; name="x86-HPET-intremap.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-HPET-intremap.patch"

x86/HPET: allow use for broadcast when interrupt remapping is in =
effect=0A=0AThis requires some additions to the VT-d side; AMD IOMMUs use =
the=0A"normal" MSI message format even when interrupt remapping is =
enabled,=0Athus making adjustments here unnecessary.=0A=0ASigned-off-by: =
Jan Beulich =0A---=0Av2: refresh after updating patch 1 =
of this series (patch 3 is unchanged)=0A=0A--- a/xen/arch/x86/acpi/boot.c=
=0A+++ b/xen/arch/x86/acpi/boot.c=0A@@ -276,6 +276,7 @@ static int __init =
acpi_parse_hpet(struct=0A 	}=0A =0A 	hpet_address =3D hpet_tbl->=
address.address;=0A+	hpet_blockid =3D hpet_tbl->sequence;=0A 	=
printk(KERN_INFO PREFIX "HPET id: %#x base: %#lx\n",=0A 	       =
hpet_tbl->id, hpet_address);=0A =0A--- a/xen/arch/x86/hpet.c=0A+++ =
b/xen/arch/x86/hpet.c=0A@@ -40,7 +40,7 @@ struct hpet_event_channel=0A =0A =
    unsigned int idx;   /* physical channel idx */=0A     unsigned int =
cpu;   /* msi target */=0A-    int irq;            /* msi irq */=0A+    =
struct msi_desc msi;/* msi state */=0A     unsigned int flags; /* =
HPET_EVT_x */=0A } __cacheline_aligned;=0A static struct hpet_event_channel=
 *__read_mostly hpet_events;=0A@@ -51,6 +51,7 @@ static unsigned int =
__read_mostly num_hp=0A DEFINE_PER_CPU(struct hpet_event_channel *, =
cpu_bc_channel);=0A =0A unsigned long __read_mostly hpet_address;=0A+u8 =
__initdata hpet_blockid;=0A =0A /*=0A  * force_hpet_broadcast: by default =
legacy hpet broadcast will be stopped=0A@@ -252,6 +253,8 @@ static void =
hpet_msi_mask(struct irq_des=0A =0A static void hpet_msi_write(struct =
hpet_event_channel *ch, struct msi_msg *msg)=0A {=0A+    if ( iommu_intrema=
p )=0A+        iommu_update_ire_from_msi(&ch->msi, msg);=0A     hpet_write3=
2(msg->data, HPET_Tn_ROUTE(ch->idx));=0A     hpet_write32(msg->address_lo, =
HPET_Tn_ROUTE(ch->idx) + 4);=0A }=0A@@ -261,6 +264,8 @@ static void =
hpet_msi_read(struct hpet_ev=0A     msg->data =3D hpet_read32(HPET_Tn_ROUTE=
(ch->idx));=0A     msg->address_lo =3D hpet_read32(HPET_Tn_ROUTE(ch->idx) =
+ 4);=0A     msg->address_hi =3D 0;=0A+    if ( iommu_intremap )=0A+       =
 iommu_read_msi_from_ire(&ch->msi, msg);=0A }=0A =0A static unsigned int =
hpet_msi_startup(struct irq_desc *desc)=0A@@ -292,6 +297,7 @@ static void =
hpet_msi_set_affinity(struct=0A     msg.data |=3D MSI_DATA_VECTOR(desc->arc=
h.vector);=0A     msg.address_lo &=3D ~MSI_ADDR_DEST_ID_MASK;=0A     =
msg.address_lo |=3D MSI_ADDR_DEST_ID(dest);=0A+    msg.dest32 =3D dest;=0A =
    hpet_msi_write(desc->action->dev_id, &msg);=0A }=0A =0A@@ -316,35 =
+322,48 @@ static void __hpet_setup_msi_irq(struct =0A     hpet_msi_write(d=
esc->action->dev_id, &msg);=0A }=0A =0A-static int __init hpet_setup_msi_ir=
q(unsigned int irq, struct hpet_event_channel *ch)=0A+static int __init =
hpet_setup_msi_irq(struct hpet_event_channel *ch)=0A {=0A     int ret;=0A- =
   irq_desc_t *desc =3D irq_to_desc(irq);=0A+    irq_desc_t *desc =3D =
irq_to_desc(ch->msi.irq);=0A+=0A+    if ( iommu_intremap )=0A+    {=0A+    =
    ch->msi.hpet_id =3D hpet_blockid;=0A+        ret =3D iommu_setup_hpet_m=
si(&ch->msi);=0A+        if ( ret )=0A+            return ret;=0A+    }=0A =
=0A     desc->handler =3D &hpet_msi_type;=0A-    ret =3D request_irq(irq, =
hpet_interrupt_handler, 0, "HPET", ch);=0A+    ret =3D request_irq(ch->msi.=
irq, hpet_interrupt_handler, 0, "HPET", ch);=0A     if ( ret < 0 )=0A+    =
{=0A+        if ( iommu_intremap )=0A+            iommu_update_ire_from_msi=
(&ch->msi, NULL);=0A         return ret;=0A+    }=0A =0A     __hpet_setup_m=
si_irq(desc);=0A =0A     return 0;=0A }=0A =0A-static int __init hpet_assig=
n_irq(unsigned int idx)=0A+static int __init hpet_assign_irq(struct =
hpet_event_channel *ch)=0A {=0A     int irq;=0A =0A     if ( (irq =3D =
create_irq(NUMA_NO_NODE)) < 0 )=0A         return irq;=0A =0A-    if ( =
hpet_setup_msi_irq(irq, hpet_events + idx) )=0A+    ch->msi.irq =3D =
irq;=0A+    if ( hpet_setup_msi_irq(ch) )=0A     {=0A         destroy_irq(i=
rq);=0A         return -EINVAL;=0A     }=0A =0A-    return irq;=0A+    =
return 0;=0A }=0A =0A static void __init hpet_fsb_cap_lookup(void)=0A@@ =
-352,14 +371,6 @@ static void __init hpet_fsb_cap_lookup(v=0A     u32 =
id;=0A     unsigned int i, num_chs;=0A =0A-    /* TODO. */=0A-    if ( =
iommu_intremap )=0A-    {=0A-        printk(XENLOG_INFO "HPET's MSI mode =
hasn't been supported when "=0A-            "Interrupt Remapping is =
enabled.\n");=0A-        return;=0A-    }=0A-=0A     id =3D hpet_read32(HPE=
T_ID);=0A =0A     num_chs =3D ((id & HPET_ID_NUMBER) >> HPET_ID_NUMBER_SHIF=
T);=0A@@ -391,8 +402,8 @@ static void __init hpet_fsb_cap_lookup(v=0A      =
   ch->flags =3D 0;=0A         ch->idx =3D i;=0A =0A-        if ( (ch->irq =
=3D hpet_assign_irq(num_hpets_used++)) < 0 )=0A-            num_hpets_used-=
-;=0A+        if ( hpet_assign_irq(ch) =3D=3D 0 )=0A+            num_hpets_=
used++;=0A     }=0A =0A     printk(XENLOG_INFO "HPET: %u timers (%u will =
be used for broadcast)\n",=0A@@ -438,7 +449,7 @@ static struct hpet_event_c=
hannel *hpet_g=0A =0A static void set_channel_irq_affinity(const struct =
hpet_event_channel *ch)=0A {=0A-    struct irq_desc *desc =3D irq_to_desc(c=
h->irq);=0A+    struct irq_desc *desc =3D irq_to_desc(ch->msi.irq);=0A =0A =
    ASSERT(!local_irq_is_enabled());=0A     spin_lock(&desc->lock);=0A@@ =
-530,7 +541,7 @@ void __init hpet_broadcast_init(void)=0A             =
hpet_events =3D xzalloc(struct hpet_event_channel);=0A         if ( =
!hpet_events || !zalloc_cpumask_var(&hpet_events->cpumask) )=0A            =
 return;=0A-        hpet_events->irq =3D -1;=0A+        hpet_events->msi.ir=
q =3D -1;=0A =0A         /* Start HPET legacy interrupts */=0A         cfg =
|=3D HPET_CFG_LEGACY;=0A@@ -598,8 +609,8 @@ void hpet_broadcast_resume(void=
)=0A =0A     for ( i =3D 0; i < n; i++ )=0A     {=0A-        if ( =
hpet_events[i].irq >=3D 0 )=0A-            __hpet_setup_msi_irq(irq_to_desc=
(hpet_events[i].irq));=0A+        if ( hpet_events[i].msi.irq >=3D 0 )=0A+ =
           __hpet_setup_msi_irq(irq_to_desc(hpet_events[i].msi.irq));=0A =
=0A         /* set HPET Tn as oneshot */=0A         cfg =3D hpet_read32(HPE=
T_Tn_CFG(hpet_events[i].idx));=0A--- a/xen/drivers/passthrough/iommu.c=0A++=
+ b/xen/drivers/passthrough/iommu.c=0A@@ -495,6 +495,12 @@ unsigned int =
iommu_read_apic_from_ire(un=0A     return ops->read_apic_from_ire(apic, =
reg);=0A }=0A =0A+int __init iommu_setup_hpet_msi(struct msi_desc =
*msi)=0A+{=0A+    const struct iommu_ops *ops =3D iommu_get_ops();=0A+    =
return ops->setup_hpet_msi ? ops->setup_hpet_msi(msi) : 0;=0A+}=0A+=0A =
void iommu_resume()=0A {=0A     const struct iommu_ops *ops =3D iommu_get_o=
ps();=0A--- a/xen/drivers/passthrough/vtd/dmar.c=0A+++ b/xen/drivers/passth=
rough/vtd/dmar.c=0A@@ -147,6 +147,34 @@ struct iommu * ioapic_to_iommu(unsi=
gned =0A     return NULL;=0A }=0A =0A+static bool_t acpi_hpet_device_match(=
=0A+    struct list_head *list, unsigned int hpet_id)=0A+{=0A+    struct =
acpi_hpet_unit *hpet;=0A+=0A+    list_for_each_entry( hpet, list, list =
)=0A+        if (hpet->id =3D=3D hpet_id)=0A+            return 1;=0A+    =
return 0;=0A+}=0A+=0A+struct acpi_drhd_unit *hpet_to_drhd(unsigned int =
hpet_id)=0A+{=0A+    struct acpi_drhd_unit *drhd;=0A+=0A+    list_for_each_=
entry( drhd, &acpi_drhd_units, list )=0A+        if ( acpi_hpet_device_matc=
h(&drhd->hpet_list, hpet_id) )=0A+            return drhd;=0A+    return =
NULL;=0A+}=0A+=0A+struct iommu *hpet_to_iommu(unsigned int hpet_id)=0A+{=0A=
+    struct acpi_drhd_unit *drhd =3D hpet_to_drhd(hpet_id);=0A+=0A+    =
return drhd ? drhd->iommu : NULL;=0A+}=0A+=0A static int __init acpi_regist=
er_atsr_unit(struct acpi_atsr_unit *atsr)=0A {=0A     /*=0A@@ -330,6 =
+358,22 @@ static int __init acpi_parse_dev_scope(=0A             if ( =
iommu_verbose )=0A                 dprintk(VTDPREFIX, " MSI HPET: =
%04x:%02x:%02x.%u\n",=0A                         seg, bus, path->dev, =
path->fn);=0A+=0A+            if ( type =3D=3D DMAR_TYPE )=0A+            =
{=0A+                struct acpi_drhd_unit *drhd =3D acpi_entry;=0A+       =
         struct acpi_hpet_unit *acpi_hpet_unit;=0A+=0A+                =
acpi_hpet_unit =3D xmalloc(struct acpi_hpet_unit);=0A+                if ( =
!acpi_hpet_unit )=0A+                    return -ENOMEM;=0A+               =
 acpi_hpet_unit->id =3D acpi_scope->enumeration_id;=0A+                =
acpi_hpet_unit->bus =3D bus;=0A+                acpi_hpet_unit->dev =3D =
path->dev;=0A+                acpi_hpet_unit->func =3D path->fn;=0A+       =
         list_add(&acpi_hpet_unit->list, &drhd->hpet_list);=0A+            =
}=0A+=0A             break;=0A =0A         case ACPI_DMAR_SCOPE_TYPE_ENDPOI=
NT:=0A@@ -407,6 +451,7 @@ acpi_parse_one_drhd(struct acpi_dmar_hea=0A     =
dmaru->segment =3D drhd->segment;=0A     dmaru->include_all =3D drhd->flags=
 & ACPI_DMAR_INCLUDE_ALL;=0A     INIT_LIST_HEAD(&dmaru->ioapic_list);=0A+  =
  INIT_LIST_HEAD(&dmaru->hpet_list);=0A     if ( iommu_verbose )=0A        =
 dprintk(VTDPREFIX, "  dmaru->address =3D %"PRIx64"\n",=0A                 =
dmaru->address);=0A--- a/xen/drivers/passthrough/vtd/dmar.h=0A+++ =
b/xen/drivers/passthrough/vtd/dmar.h=0A@@ -39,6 +39,19 @@ struct acpi_ioapi=
c_unit {=0A     }ioapic;=0A };=0A =0A+struct acpi_hpet_unit {=0A+    =
struct list_head list;=0A+    unsigned int id;=0A+    union {=0A+        =
u16 bdf;=0A+        struct {=0A+            u16 func: 3,=0A+               =
 dev:  5,=0A+                bus:  8;=0A+        };=0A+    };=0A+};=0A+=0A =
struct dmar_scope {=0A     DECLARE_BITMAP(buses, 256);         /* buses =
owned by this unit */=0A     u16    *devices;                    /* =
devices owned by this unit */=0A@@ -53,6 +66,7 @@ struct acpi_drhd_unit =
{=0A     u8     include_all:1;=0A     struct iommu *iommu;=0A     struct =
list_head ioapic_list;=0A+    struct list_head hpet_list;=0A };=0A =0A =
struct acpi_rmrr_unit {=0A--- a/xen/drivers/passthrough/vtd/extern.h=0A+++ =
b/xen/drivers/passthrough/vtd/extern.h=0A@@ -54,7 +54,9 @@ int iommu_flush_=
iec_index(struct iommu *=0A void clear_fault_bits(struct iommu *iommu);=0A =
=0A struct iommu * ioapic_to_iommu(unsigned int apic_id);=0A+struct iommu =
* hpet_to_iommu(unsigned int hpet_id);=0A struct acpi_drhd_unit * =
ioapic_to_drhd(unsigned int apic_id);=0A+struct acpi_drhd_unit * hpet_to_dr=
hd(unsigned int hpet_id);=0A struct acpi_drhd_unit * iommu_to_drhd(struct =
iommu *iommu);=0A struct acpi_rhsa_unit * drhd_to_rhsa(struct acpi_drhd_uni=
t *drhd);=0A =0A@@ -90,6 +92,8 @@ struct msi_msg;=0A void msi_msg_read_rema=
p_rte(struct msi_desc *, struct msi_msg *);=0A void msi_msg_write_remap_rte=
(struct msi_desc *, struct msi_msg *);=0A =0A+int intel_setup_hpet_msi(stru=
ct msi_desc *);=0A+=0A int is_igd_vt_enabled_quirk(void);=0A void =
platform_quirks_init(void);=0A void vtd_ops_preamble_quirk(struct iommu* =
iommu);=0A--- a/xen/drivers/passthrough/vtd/intremap.c=0A+++ b/xen/drivers/=
passthrough/vtd/intremap.c=0A@@ -107,6 +107,19 @@ static u16 apicid_to_bdf(=
int apic_id)=0A     return 0;=0A }=0A =0A+static u16 hpetid_to_bdf(unsigned=
 int hpet_id)=0A+{=0A+    struct acpi_drhd_unit *drhd =3D hpet_to_drhd(hpet=
_id);=0A+    struct acpi_hpet_unit *acpi_hpet_unit;=0A+=0A+    list_for_eac=
h_entry ( acpi_hpet_unit, &drhd->hpet_list, list )=0A+        if ( =
acpi_hpet_unit->id =3D=3D hpet_id )=0A+            return acpi_hpet_unit->b=
df;=0A+=0A+    dprintk(XENLOG_ERR VTDPREFIX, "Didn't find the bdf for HPET =
%u!\n", hpet_id);=0A+    return 0;=0A+}=0A+=0A static void set_ire_sid(stru=
ct iremap_entry *ire,=0A                         unsigned int svt, =
unsigned int sq, unsigned int sid)=0A {=0A@@ -121,6 +134,16 @@ static void =
set_ioapic_source_id(int api=0A                 apicid_to_bdf(apic_id));=0A=
 }=0A =0A+static void set_hpet_source_id(unsigned int id, struct iremap_ent=
ry *ire)=0A+{=0A+    /*=0A+     * Should really use SQ_ALL_16. Some =
platforms are broken.=0A+     * While we figure out the right quirks for =
these broken platforms, use=0A+     * SQ_13_IGNORE_3 for now.=0A+     =
*/=0A+    set_ire_sid(ire, SVT_VERIFY_SID_SQ, SQ_13_IGNORE_3, hpetid_to_bdf=
(id));=0A+}=0A+=0A int iommu_supports_eim(void)=0A {=0A     struct =
acpi_drhd_unit *drhd;=0A@@ -592,7 +615,10 @@ static int msi_msg_to_remap_en=
try(=0A         new_ire.lo.dst =3D ((msg->address_lo >> MSI_ADDR_DEST_ID_SH=
IFT)=0A                           & 0xff) << 8;=0A =0A-    set_msi_source_i=
d(pdev, &new_ire);=0A+    if ( pdev )=0A+        set_msi_source_id(pdev, =
&new_ire);=0A+    else=0A+        set_hpet_source_id(msi_desc->hpet_id, =
&new_ire);=0A     new_ire.hi.res_1 =3D 0;=0A     new_ire.lo.p =3D 1;    /* =
finally, set present bit */=0A =0A@@ -624,7 +650,9 @@ void msi_msg_read_rem=
ap_rte(=0A     struct iommu *iommu =3D NULL;=0A     struct ir_ctrl =
*ir_ctrl;=0A =0A-    if ( (drhd =3D acpi_find_matched_drhd_unit(pdev)) =
=3D=3D NULL )=0A+    drhd =3D pdev ? acpi_find_matched_drhd_unit(pdev)=0A+ =
               : hpet_to_drhd(msi_desc->hpet_id);=0A+    if ( !drhd )=0A   =
      return;=0A     iommu =3D drhd->iommu;=0A =0A@@ -643,7 +671,9 @@ void =
msi_msg_write_remap_rte(=0A     struct iommu *iommu =3D NULL;=0A     =
struct ir_ctrl *ir_ctrl;=0A =0A-    if ( (drhd =3D acpi_find_matched_drhd_u=
nit(pdev)) =3D=3D NULL )=0A+    drhd =3D pdev ? acpi_find_matched_drhd_unit=
(pdev)=0A+                : hpet_to_drhd(msi_desc->hpet_id);=0A+    if ( =
!drhd )=0A         return;=0A     iommu =3D drhd->iommu;=0A =0A@@ -654,6 =
+684,32 @@ void msi_msg_write_remap_rte(=0A     msi_msg_to_remap_entry(iomm=
u, pdev, msi_desc, msg);=0A }=0A =0A+int __init intel_setup_hpet_msi(struct=
 msi_desc *msi_desc)=0A+{=0A+    struct iommu *iommu =3D hpet_to_iommu(msi_=
desc->hpet_id);=0A+    struct ir_ctrl *ir_ctrl =3D iommu_ir_ctrl(iommu);=0A=
+    unsigned long flags;=0A+    int rc =3D 0;=0A+=0A+    if ( !ir_ctrl || =
!ir_ctrl->iremap_maddr )=0A+        return 0;=0A+=0A+    spin_lock_irqsave(=
&ir_ctrl->iremap_lock, flags);=0A+    msi_desc->remap_index =3D alloc_remap=
_entry(iommu);=0A+    if ( msi_desc->remap_index >=3D IREMAP_ENTRY_NR =
)=0A+    {=0A+        dprintk(XENLOG_ERR VTDPREFIX,=0A+                =
"%s: intremap index (%d) is larger than"=0A+                " the maximum =
index (%d)!\n",=0A+                __func__, msi_desc->remap_index, =
IREMAP_ENTRY_NR - 1);=0A+        msi_desc->remap_index =3D -1;=0A+        =
rc =3D -ENXIO;=0A+    }=0A+    spin_unlock_irqrestore(&ir_ctrl->iremap_lock=
, flags);=0A+=0A+    return rc;=0A+}=0A+=0A int enable_intremap(struct =
iommu *iommu, int eim)=0A {=0A     struct acpi_drhd_unit *drhd;=0A--- =
a/xen/drivers/passthrough/vtd/iommu.c=0A+++ b/xen/drivers/passthrough/vtd/i=
ommu.c=0A@@ -2396,6 +2396,7 @@ const struct iommu_ops intel_iommu_ops =
=3D=0A     .update_ire_from_msi =3D msi_msg_write_remap_rte,=0A     =
.read_apic_from_ire =3D io_apic_read_remap_rte,=0A     .read_msi_from_ire =
=3D msi_msg_read_remap_rte,=0A+    .setup_hpet_msi =3D intel_setup_hpet_msi=
,=0A     .suspend =3D vtd_suspend,=0A     .resume =3D vtd_resume,=0A     =
.share_p2m =3D iommu_set_pgd,=0A--- a/xen/include/asm-x86/hpet.h=0A+++ =
b/xen/include/asm-x86/hpet.h=0A@@ -53,6 +53,7 @@=0A     (*(volatile u32 =
*)(fix_to_virt(FIX_HPET_BASE) + (x)) =3D (y))=0A =0A extern unsigned long =
hpet_address;=0A+extern u8 hpet_blockid;=0A =0A /*=0A  * Detect and =
initialise HPET hardware: return counter update frequency.=0A--- a/xen/incl=
ude/asm-x86/msi.h=0A+++ b/xen/include/asm-x86/msi.h=0A@@ -97,7 +97,10 @@ =
struct msi_desc {=0A =0A 	struct list_head list;=0A =0A-	void =
__iomem *mask_base;        /* va for the entry in mask table */=0A+	=
union {=0A+		void __iomem *mask_base;/* va for the entry in =
mask table */=0A+		unsigned int hpet_id;   /* HPET (dev is =
NULL)             */=0A+	};=0A 	struct pci_dev *dev;=0A 	=
int irq;=0A =0A--- a/xen/include/xen/iommu.h=0A+++ b/xen/include/xen/iommu.=
h=0A@@ -109,6 +109,7 @@ struct iommu_ops {=0A     void (*update_ire_from_ms=
i)(struct msi_desc *msi_desc, struct msi_msg *msg);=0A     void (*read_msi_=
from_ire)(struct msi_desc *msi_desc, struct msi_msg *msg);=0A     unsigned =
int (*read_apic_from_ire)(unsigned int apic, unsigned int reg);=0A+    int =
(*setup_hpet_msi)(struct msi_desc *);=0A     void (*suspend)(void);=0A     =
void (*resume)(void);=0A     void (*share_p2m)(struct domain *d);=0A@@ =
-122,6 +123,7 @@ void iommu_update_ire_from_apic(unsigned=0A void =
iommu_update_ire_from_msi(struct msi_desc *msi_desc, struct msi_msg =
*msg);=0A void iommu_read_msi_from_ire(struct msi_desc *msi_desc, struct =
msi_msg *msg);=0A unsigned int iommu_read_apic_from_ire(unsigned int apic, =
unsigned int reg);=0A+int iommu_setup_hpet_msi(struct msi_desc *);=0A =0A =
void iommu_suspend(void);=0A void iommu_resume(void);=0A
--=__Part774654AB.1__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__Part774654AB.1__=--


From xen-devel-bounces@lists.xen.org Wed Oct 17 11:47:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 11:47:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOS5h-0006xn-TM; Wed, 17 Oct 2012 11:47:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOS5g-0006xZ-21
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 11:47:12 +0000
Received: from [85.158.143.99:32920] by server-1.bemta-4.messagelabs.com id
	90/26-19134-FBA9E705; Wed, 17 Oct 2012 11:47:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1350474429!33851465!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17110 invoked from network); 17 Oct 2012 11:47:09 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-216.messagelabs.com with SMTP;
	17 Oct 2012 11:47:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 17 Oct 2012 12:47:09 +0100
Message-Id: <507EB6DB02000078000A1F4A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 17 Oct 2012 12:47:07 +0100
From: "Jan Beulich" 
To: "xen-devel" 
References: <507D93C102000078000A1BAB@nat28.tlf.novell.com>
	<507D94FE02000078000A1BC1@nat28.tlf.novell.com>
In-Reply-To: <507D94FE02000078000A1BC1@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part774654AB.1__="
Cc: xiantao.zhang@intel.com
Subject: [Xen-devel] [PATCH v2 2/3] x86/HPET: allow use for broadcast when
 interrupt remapping is in effect
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part774654AB.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This requires some additions to the VT-d side; AMD IOMMUs use the
"normal" MSI message format even when interrupt remapping is enabled,
thus making adjustments here unnecessary.

Signed-off-by: Jan Beulich 
---
v2: refresh after updating patch 1 of this series (patch 3 is unchanged)

--- a/xen/arch/x86/acpi/boot.c
+++ b/xen/arch/x86/acpi/boot.c
@@ -276,6 +276,7 @@ static int __init acpi_parse_hpet(struct
 	}
=20
 	hpet_address =3D hpet_tbl->address.address;
+	hpet_blockid =3D hpet_tbl->sequence;
 	printk(KERN_INFO PREFIX "HPET id: %#x base: %#lx\n",
 	       hpet_tbl->id, hpet_address);
=20
--- a/xen/arch/x86/hpet.c
+++ b/xen/arch/x86/hpet.c
@@ -40,7 +40,7 @@ struct hpet_event_channel
=20
     unsigned int idx;   /* physical channel idx */
     unsigned int cpu;   /* msi target */
-    int irq;            /* msi irq */
+    struct msi_desc msi;/* msi state */
     unsigned int flags; /* HPET_EVT_x */
 } __cacheline_aligned;
 static struct hpet_event_channel *__read_mostly hpet_events;
@@ -51,6 +51,7 @@ static unsigned int __read_mostly num_hp
 DEFINE_PER_CPU(struct hpet_event_channel *, cpu_bc_channel);
=20
 unsigned long __read_mostly hpet_address;
+u8 __initdata hpet_blockid;
=20
 /*
  * force_hpet_broadcast: by default legacy hpet broadcast will be stopped
@@ -252,6 +253,8 @@ static void hpet_msi_mask(struct irq_des
=20
 static void hpet_msi_write(struct hpet_event_channel *ch, struct msi_msg =
*msg)
 {
+    if ( iommu_intremap )
+        iommu_update_ire_from_msi(&ch->msi, msg);
     hpet_write32(msg->data, HPET_Tn_ROUTE(ch->idx));
     hpet_write32(msg->address_lo, HPET_Tn_ROUTE(ch->idx) + 4);
 }
@@ -261,6 +264,8 @@ static void hpet_msi_read(struct hpet_ev
     msg->data =3D hpet_read32(HPET_Tn_ROUTE(ch->idx));
     msg->address_lo =3D hpet_read32(HPET_Tn_ROUTE(ch->idx) + 4);
     msg->address_hi =3D 0;
+    if ( iommu_intremap )
+        iommu_read_msi_from_ire(&ch->msi, msg);
 }
=20
 static unsigned int hpet_msi_startup(struct irq_desc *desc)
@@ -292,6 +297,7 @@ static void hpet_msi_set_affinity(struct
     msg.data |=3D MSI_DATA_VECTOR(desc->arch.vector);
     msg.address_lo &=3D ~MSI_ADDR_DEST_ID_MASK;
     msg.address_lo |=3D MSI_ADDR_DEST_ID(dest);
+    msg.dest32 =3D dest;
     hpet_msi_write(desc->action->dev_id, &msg);
 }
=20
@@ -316,35 +322,48 @@ static void __hpet_setup_msi_irq(struct=20
     hpet_msi_write(desc->action->dev_id, &msg);
 }
=20
-static int __init hpet_setup_msi_irq(unsigned int irq, struct hpet_event_c=
hannel *ch)
+static int __init hpet_setup_msi_irq(struct hpet_event_channel *ch)
 {
     int ret;
-    irq_desc_t *desc =3D irq_to_desc(irq);
+    irq_desc_t *desc =3D irq_to_desc(ch->msi.irq);
+
+    if ( iommu_intremap )
+    {
+        ch->msi.hpet_id =3D hpet_blockid;
+        ret =3D iommu_setup_hpet_msi(&ch->msi);
+        if ( ret )
+            return ret;
+    }
=20
     desc->handler =3D &hpet_msi_type;
-    ret =3D request_irq(irq, hpet_interrupt_handler, 0, "HPET", ch);
+    ret =3D request_irq(ch->msi.irq, hpet_interrupt_handler, 0, "HPET", =
ch);
     if ( ret < 0 )
+    {
+        if ( iommu_intremap )
+            iommu_update_ire_from_msi(&ch->msi, NULL);
         return ret;
+    }
=20
     __hpet_setup_msi_irq(desc);
=20
     return 0;
 }
=20
-static int __init hpet_assign_irq(unsigned int idx)
+static int __init hpet_assign_irq(struct hpet_event_channel *ch)
 {
     int irq;
=20
     if ( (irq =3D create_irq(NUMA_NO_NODE)) < 0 )
         return irq;
=20
-    if ( hpet_setup_msi_irq(irq, hpet_events + idx) )
+    ch->msi.irq =3D irq;
+    if ( hpet_setup_msi_irq(ch) )
     {
         destroy_irq(irq);
         return -EINVAL;
     }
=20
-    return irq;
+    return 0;
 }
=20
 static void __init hpet_fsb_cap_lookup(void)
@@ -352,14 +371,6 @@ static void __init hpet_fsb_cap_lookup(v
     u32 id;
     unsigned int i, num_chs;
=20
-    /* TODO. */
-    if ( iommu_intremap )
-    {
-        printk(XENLOG_INFO "HPET's MSI mode hasn't been supported when "
-            "Interrupt Remapping is enabled.\n");
-        return;
-    }
-
     id =3D hpet_read32(HPET_ID);
=20
     num_chs =3D ((id & HPET_ID_NUMBER) >> HPET_ID_NUMBER_SHIFT);
@@ -391,8 +402,8 @@ static void __init hpet_fsb_cap_lookup(v
         ch->flags =3D 0;
         ch->idx =3D i;
=20
-        if ( (ch->irq =3D hpet_assign_irq(num_hpets_used++)) < 0 )
-            num_hpets_used--;
+        if ( hpet_assign_irq(ch) =3D=3D 0 )
+            num_hpets_used++;
     }
=20
     printk(XENLOG_INFO "HPET: %u timers (%u will be used for broadcast)\n"=
,
@@ -438,7 +449,7 @@ static struct hpet_event_channel *hpet_g
=20
 static void set_channel_irq_affinity(const struct hpet_event_channel *ch)
 {
-    struct irq_desc *desc =3D irq_to_desc(ch->irq);
+    struct irq_desc *desc =3D irq_to_desc(ch->msi.irq);
=20
     ASSERT(!local_irq_is_enabled());
     spin_lock(&desc->lock);
@@ -530,7 +541,7 @@ void __init hpet_broadcast_init(void)
             hpet_events =3D xzalloc(struct hpet_event_channel);
         if ( !hpet_events || !zalloc_cpumask_var(&hpet_events->cpumask) )
             return;
-        hpet_events->irq =3D -1;
+        hpet_events->msi.irq =3D -1;
=20
         /* Start HPET legacy interrupts */
         cfg |=3D HPET_CFG_LEGACY;
@@ -598,8 +609,8 @@ void hpet_broadcast_resume(void)
=20
     for ( i =3D 0; i < n; i++ )
     {
-        if ( hpet_events[i].irq >=3D 0 )
-            __hpet_setup_msi_irq(irq_to_desc(hpet_events[i].irq));
+        if ( hpet_events[i].msi.irq >=3D 0 )
+            __hpet_setup_msi_irq(irq_to_desc(hpet_events[i].msi.irq));
=20
         /* set HPET Tn as oneshot */
         cfg =3D hpet_read32(HPET_Tn_CFG(hpet_events[i].idx));
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -495,6 +495,12 @@ unsigned int iommu_read_apic_from_ire(un
     return ops->read_apic_from_ire(apic, reg);
 }
=20
+int __init iommu_setup_hpet_msi(struct msi_desc *msi)
+{
+    const struct iommu_ops *ops =3D iommu_get_ops();
+    return ops->setup_hpet_msi ? ops->setup_hpet_msi(msi) : 0;
+}
+
 void iommu_resume()
 {
     const struct iommu_ops *ops =3D iommu_get_ops();
--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -147,6 +147,34 @@ struct iommu * ioapic_to_iommu(unsigned=20
     return NULL;
 }
=20
+static bool_t acpi_hpet_device_match(
+    struct list_head *list, unsigned int hpet_id)
+{
+    struct acpi_hpet_unit *hpet;
+
+    list_for_each_entry( hpet, list, list )
+        if (hpet->id =3D=3D hpet_id)
+            return 1;
+    return 0;
+}
+
+struct acpi_drhd_unit *hpet_to_drhd(unsigned int hpet_id)
+{
+    struct acpi_drhd_unit *drhd;
+
+    list_for_each_entry( drhd, &acpi_drhd_units, list )
+        if ( acpi_hpet_device_match(&drhd->hpet_list, hpet_id) )
+            return drhd;
+    return NULL;
+}
+
+struct iommu *hpet_to_iommu(unsigned int hpet_id)
+{
+    struct acpi_drhd_unit *drhd =3D hpet_to_drhd(hpet_id);
+
+    return drhd ? drhd->iommu : NULL;
+}
+
 static int __init acpi_register_atsr_unit(struct acpi_atsr_unit *atsr)
 {
     /*
@@ -330,6 +358,22 @@ static int __init acpi_parse_dev_scope(
             if ( iommu_verbose )
                 dprintk(VTDPREFIX, " MSI HPET: %04x:%02x:%02x.%u\n",
                         seg, bus, path->dev, path->fn);
+
+            if ( type =3D=3D DMAR_TYPE )
+            {
+                struct acpi_drhd_unit *drhd =3D acpi_entry;
+                struct acpi_hpet_unit *acpi_hpet_unit;
+
+                acpi_hpet_unit =3D xmalloc(struct acpi_hpet_unit);
+                if ( !acpi_hpet_unit )
+                    return -ENOMEM;
+                acpi_hpet_unit->id =3D acpi_scope->enumeration_id;
+                acpi_hpet_unit->bus =3D bus;
+                acpi_hpet_unit->dev =3D path->dev;
+                acpi_hpet_unit->func =3D path->fn;
+                list_add(&acpi_hpet_unit->list, &drhd->hpet_list);
+            }
+
             break;
=20
         case ACPI_DMAR_SCOPE_TYPE_ENDPOINT:
@@ -407,6 +451,7 @@ acpi_parse_one_drhd(struct acpi_dmar_hea
     dmaru->segment =3D drhd->segment;
     dmaru->include_all =3D drhd->flags & ACPI_DMAR_INCLUDE_ALL;
     INIT_LIST_HEAD(&dmaru->ioapic_list);
+    INIT_LIST_HEAD(&dmaru->hpet_list);
     if ( iommu_verbose )
         dprintk(VTDPREFIX, "  dmaru->address =3D %"PRIx64"\n",
                 dmaru->address);
--- a/xen/drivers/passthrough/vtd/dmar.h
+++ b/xen/drivers/passthrough/vtd/dmar.h
@@ -39,6 +39,19 @@ struct acpi_ioapic_unit {
     }ioapic;
 };
=20
+struct acpi_hpet_unit {
+    struct list_head list;
+    unsigned int id;
+    union {
+        u16 bdf;
+        struct {
+            u16 func: 3,
+                dev:  5,
+                bus:  8;
+        };
+    };
+};
+
 struct dmar_scope {
     DECLARE_BITMAP(buses, 256);         /* buses owned by this unit */
     u16    *devices;                    /* devices owned by this unit */
@@ -53,6 +66,7 @@ struct acpi_drhd_unit {
     u8     include_all:1;
     struct iommu *iommu;
     struct list_head ioapic_list;
+    struct list_head hpet_list;
 };
=20
 struct acpi_rmrr_unit {
--- a/xen/drivers/passthrough/vtd/extern.h
+++ b/xen/drivers/passthrough/vtd/extern.h
@@ -54,7 +54,9 @@ int iommu_flush_iec_index(struct iommu *
 void clear_fault_bits(struct iommu *iommu);
=20
 struct iommu * ioapic_to_iommu(unsigned int apic_id);
+struct iommu * hpet_to_iommu(unsigned int hpet_id);
 struct acpi_drhd_unit * ioapic_to_drhd(unsigned int apic_id);
+struct acpi_drhd_unit * hpet_to_drhd(unsigned int hpet_id);
 struct acpi_drhd_unit * iommu_to_drhd(struct iommu *iommu);
 struct acpi_rhsa_unit * drhd_to_rhsa(struct acpi_drhd_unit *drhd);
=20
@@ -90,6 +92,8 @@ struct msi_msg;
 void msi_msg_read_remap_rte(struct msi_desc *, struct msi_msg *);
 void msi_msg_write_remap_rte(struct msi_desc *, struct msi_msg *);
=20
+int intel_setup_hpet_msi(struct msi_desc *);
+
 int is_igd_vt_enabled_quirk(void);
 void platform_quirks_init(void);
 void vtd_ops_preamble_quirk(struct iommu* iommu);
--- a/xen/drivers/passthrough/vtd/intremap.c
+++ b/xen/drivers/passthrough/vtd/intremap.c
@@ -107,6 +107,19 @@ static u16 apicid_to_bdf(int apic_id)
     return 0;
 }
=20
+static u16 hpetid_to_bdf(unsigned int hpet_id)
+{
+    struct acpi_drhd_unit *drhd =3D hpet_to_drhd(hpet_id);
+    struct acpi_hpet_unit *acpi_hpet_unit;
+
+    list_for_each_entry ( acpi_hpet_unit, &drhd->hpet_list, list )
+        if ( acpi_hpet_unit->id =3D=3D hpet_id )
+            return acpi_hpet_unit->bdf;
+
+    dprintk(XENLOG_ERR VTDPREFIX, "Didn't find the bdf for HPET %u!\n", =
hpet_id);
+    return 0;
+}
+
 static void set_ire_sid(struct iremap_entry *ire,
                         unsigned int svt, unsigned int sq, unsigned int =
sid)
 {
@@ -121,6 +134,16 @@ static void set_ioapic_source_id(int api
                 apicid_to_bdf(apic_id));
 }
=20
+static void set_hpet_source_id(unsigned int id, struct iremap_entry *ire)
+{
+    /*
+     * Should really use SQ_ALL_16. Some platforms are broken.
+     * While we figure out the right quirks for these broken platforms, =
use
+     * SQ_13_IGNORE_3 for now.
+     */
+    set_ire_sid(ire, SVT_VERIFY_SID_SQ, SQ_13_IGNORE_3, hpetid_to_bdf(id))=
;
+}
+
 int iommu_supports_eim(void)
 {
     struct acpi_drhd_unit *drhd;
@@ -592,7 +615,10 @@ static int msi_msg_to_remap_entry(
         new_ire.lo.dst =3D ((msg->address_lo >> MSI_ADDR_DEST_ID_SHIFT)
                           & 0xff) << 8;
=20
-    set_msi_source_id(pdev, &new_ire);
+    if ( pdev )
+        set_msi_source_id(pdev, &new_ire);
+    else
+        set_hpet_source_id(msi_desc->hpet_id, &new_ire);
     new_ire.hi.res_1 =3D 0;
     new_ire.lo.p =3D 1;    /* finally, set present bit */
=20
@@ -624,7 +650,9 @@ void msi_msg_read_remap_rte(
     struct iommu *iommu =3D NULL;
     struct ir_ctrl *ir_ctrl;
=20
-    if ( (drhd =3D acpi_find_matched_drhd_unit(pdev)) =3D=3D NULL )
+    drhd =3D pdev ? acpi_find_matched_drhd_unit(pdev)
+                : hpet_to_drhd(msi_desc->hpet_id);
+    if ( !drhd )
         return;
     iommu =3D drhd->iommu;
=20
@@ -643,7 +671,9 @@ void msi_msg_write_remap_rte(
     struct iommu *iommu =3D NULL;
     struct ir_ctrl *ir_ctrl;
=20
-    if ( (drhd =3D acpi_find_matched_drhd_unit(pdev)) =3D=3D NULL )
+    drhd =3D pdev ? acpi_find_matched_drhd_unit(pdev)
+                : hpet_to_drhd(msi_desc->hpet_id);
+    if ( !drhd )
         return;
     iommu =3D drhd->iommu;
=20
@@ -654,6 +684,32 @@ void msi_msg_write_remap_rte(
     msi_msg_to_remap_entry(iommu, pdev, msi_desc, msg);
 }
=20
+int __init intel_setup_hpet_msi(struct msi_desc *msi_desc)
+{
+    struct iommu *iommu =3D hpet_to_iommu(msi_desc->hpet_id);
+    struct ir_ctrl *ir_ctrl =3D iommu_ir_ctrl(iommu);
+    unsigned long flags;
+    int rc =3D 0;
+
+    if ( !ir_ctrl || !ir_ctrl->iremap_maddr )
+        return 0;
+
+    spin_lock_irqsave(&ir_ctrl->iremap_lock, flags);
+    msi_desc->remap_index =3D alloc_remap_entry(iommu);
+    if ( msi_desc->remap_index >=3D IREMAP_ENTRY_NR )
+    {
+        dprintk(XENLOG_ERR VTDPREFIX,
+                "%s: intremap index (%d) is larger than"
+                " the maximum index (%d)!\n",
+                __func__, msi_desc->remap_index, IREMAP_ENTRY_NR - 1);
+        msi_desc->remap_index =3D -1;
+        rc =3D -ENXIO;
+    }
+    spin_unlock_irqrestore(&ir_ctrl->iremap_lock, flags);
+
+    return rc;
+}
+
 int enable_intremap(struct iommu *iommu, int eim)
 {
     struct acpi_drhd_unit *drhd;
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -2396,6 +2396,7 @@ const struct iommu_ops intel_iommu_ops =3D
     .update_ire_from_msi =3D msi_msg_write_remap_rte,
     .read_apic_from_ire =3D io_apic_read_remap_rte,
     .read_msi_from_ire =3D msi_msg_read_remap_rte,
+    .setup_hpet_msi =3D intel_setup_hpet_msi,
     .suspend =3D vtd_suspend,
     .resume =3D vtd_resume,
     .share_p2m =3D iommu_set_pgd,
--- a/xen/include/asm-x86/hpet.h
+++ b/xen/include/asm-x86/hpet.h
@@ -53,6 +53,7 @@
     (*(volatile u32 *)(fix_to_virt(FIX_HPET_BASE) + (x)) =3D (y))
=20
 extern unsigned long hpet_address;
+extern u8 hpet_blockid;
=20
 /*
  * Detect and initialise HPET hardware: return counter update frequency.
--- a/xen/include/asm-x86/msi.h
+++ b/xen/include/asm-x86/msi.h
@@ -97,7 +97,10 @@ struct msi_desc {
=20
 	struct list_head list;
=20
-	void __iomem *mask_base;        /* va for the entry in mask table =
*/
+	union {
+		void __iomem *mask_base;/* va for the entry in mask table =
*/
+		unsigned int hpet_id;   /* HPET (dev is NULL)             =
*/
+	};
 	struct pci_dev *dev;
 	int irq;
=20
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -109,6 +109,7 @@ struct iommu_ops {
     void (*update_ire_from_msi)(struct msi_desc *msi_desc, struct msi_msg =
*msg);
     void (*read_msi_from_ire)(struct msi_desc *msi_desc, struct msi_msg =
*msg);
     unsigned int (*read_apic_from_ire)(unsigned int apic, unsigned int =
reg);
+    int (*setup_hpet_msi)(struct msi_desc *);
     void (*suspend)(void);
     void (*resume)(void);
     void (*share_p2m)(struct domain *d);
@@ -122,6 +123,7 @@ void iommu_update_ire_from_apic(unsigned
 void iommu_update_ire_from_msi(struct msi_desc *msi_desc, struct msi_msg =
*msg);
 void iommu_read_msi_from_ire(struct msi_desc *msi_desc, struct msi_msg =
*msg);
 unsigned int iommu_read_apic_from_ire(unsigned int apic, unsigned int =
reg);
+int iommu_setup_hpet_msi(struct msi_desc *);
=20
 void iommu_suspend(void);
 void iommu_resume(void);



--=__Part774654AB.1__=
Content-Type: text/plain; name="x86-HPET-intremap.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-HPET-intremap.patch"

x86/HPET: allow use for broadcast when interrupt remapping is in =
effect=0A=0AThis requires some additions to the VT-d side; AMD IOMMUs use =
the=0A"normal" MSI message format even when interrupt remapping is =
enabled,=0Athus making adjustments here unnecessary.=0A=0ASigned-off-by: =
Jan Beulich =0A---=0Av2: refresh after updating patch 1 =
of this series (patch 3 is unchanged)=0A=0A--- a/xen/arch/x86/acpi/boot.c=
=0A+++ b/xen/arch/x86/acpi/boot.c=0A@@ -276,6 +276,7 @@ static int __init =
acpi_parse_hpet(struct=0A 	}=0A =0A 	hpet_address =3D hpet_tbl->=
address.address;=0A+	hpet_blockid =3D hpet_tbl->sequence;=0A 	=
printk(KERN_INFO PREFIX "HPET id: %#x base: %#lx\n",=0A 	       =
hpet_tbl->id, hpet_address);=0A =0A--- a/xen/arch/x86/hpet.c=0A+++ =
b/xen/arch/x86/hpet.c=0A@@ -40,7 +40,7 @@ struct hpet_event_channel=0A =0A =
    unsigned int idx;   /* physical channel idx */=0A     unsigned int =
cpu;   /* msi target */=0A-    int irq;            /* msi irq */=0A+    =
struct msi_desc msi;/* msi state */=0A     unsigned int flags; /* =
HPET_EVT_x */=0A } __cacheline_aligned;=0A static struct hpet_event_channel=
 *__read_mostly hpet_events;=0A@@ -51,6 +51,7 @@ static unsigned int =
__read_mostly num_hp=0A DEFINE_PER_CPU(struct hpet_event_channel *, =
cpu_bc_channel);=0A =0A unsigned long __read_mostly hpet_address;=0A+u8 =
__initdata hpet_blockid;=0A =0A /*=0A  * force_hpet_broadcast: by default =
legacy hpet broadcast will be stopped=0A@@ -252,6 +253,8 @@ static void =
hpet_msi_mask(struct irq_des=0A =0A static void hpet_msi_write(struct =
hpet_event_channel *ch, struct msi_msg *msg)=0A {=0A+    if ( iommu_intrema=
p )=0A+        iommu_update_ire_from_msi(&ch->msi, msg);=0A     hpet_write3=
2(msg->data, HPET_Tn_ROUTE(ch->idx));=0A     hpet_write32(msg->address_lo, =
HPET_Tn_ROUTE(ch->idx) + 4);=0A }=0A@@ -261,6 +264,8 @@ static void =
hpet_msi_read(struct hpet_ev=0A     msg->data =3D hpet_read32(HPET_Tn_ROUTE=
(ch->idx));=0A     msg->address_lo =3D hpet_read32(HPET_Tn_ROUTE(ch->idx) =
+ 4);=0A     msg->address_hi =3D 0;=0A+    if ( iommu_intremap )=0A+       =
 iommu_read_msi_from_ire(&ch->msi, msg);=0A }=0A =0A static unsigned int =
hpet_msi_startup(struct irq_desc *desc)=0A@@ -292,6 +297,7 @@ static void =
hpet_msi_set_affinity(struct=0A     msg.data |=3D MSI_DATA_VECTOR(desc->arc=
h.vector);=0A     msg.address_lo &=3D ~MSI_ADDR_DEST_ID_MASK;=0A     =
msg.address_lo |=3D MSI_ADDR_DEST_ID(dest);=0A+    msg.dest32 =3D dest;=0A =
    hpet_msi_write(desc->action->dev_id, &msg);=0A }=0A =0A@@ -316,35 =
+322,48 @@ static void __hpet_setup_msi_irq(struct =0A     hpet_msi_write(d=
esc->action->dev_id, &msg);=0A }=0A =0A-static int __init hpet_setup_msi_ir=
q(unsigned int irq, struct hpet_event_channel *ch)=0A+static int __init =
hpet_setup_msi_irq(struct hpet_event_channel *ch)=0A {=0A     int ret;=0A- =
   irq_desc_t *desc =3D irq_to_desc(irq);=0A+    irq_desc_t *desc =3D =
irq_to_desc(ch->msi.irq);=0A+=0A+    if ( iommu_intremap )=0A+    {=0A+    =
    ch->msi.hpet_id =3D hpet_blockid;=0A+        ret =3D iommu_setup_hpet_m=
si(&ch->msi);=0A+        if ( ret )=0A+            return ret;=0A+    }=0A =
=0A     desc->handler =3D &hpet_msi_type;=0A-    ret =3D request_irq(irq, =
hpet_interrupt_handler, 0, "HPET", ch);=0A+    ret =3D request_irq(ch->msi.=
irq, hpet_interrupt_handler, 0, "HPET", ch);=0A     if ( ret < 0 )=0A+    =
{=0A+        if ( iommu_intremap )=0A+            iommu_update_ire_from_msi=
(&ch->msi, NULL);=0A         return ret;=0A+    }=0A =0A     __hpet_setup_m=
si_irq(desc);=0A =0A     return 0;=0A }=0A =0A-static int __init hpet_assig=
n_irq(unsigned int idx)=0A+static int __init hpet_assign_irq(struct =
hpet_event_channel *ch)=0A {=0A     int irq;=0A =0A     if ( (irq =3D =
create_irq(NUMA_NO_NODE)) < 0 )=0A         return irq;=0A =0A-    if ( =
hpet_setup_msi_irq(irq, hpet_events + idx) )=0A+    ch->msi.irq =3D =
irq;=0A+    if ( hpet_setup_msi_irq(ch) )=0A     {=0A         destroy_irq(i=
rq);=0A         return -EINVAL;=0A     }=0A =0A-    return irq;=0A+    =
return 0;=0A }=0A =0A static void __init hpet_fsb_cap_lookup(void)=0A@@ =
-352,14 +371,6 @@ static void __init hpet_fsb_cap_lookup(v=0A     u32 =
id;=0A     unsigned int i, num_chs;=0A =0A-    /* TODO. */=0A-    if ( =
iommu_intremap )=0A-    {=0A-        printk(XENLOG_INFO "HPET's MSI mode =
hasn't been supported when "=0A-            "Interrupt Remapping is =
enabled.\n");=0A-        return;=0A-    }=0A-=0A     id =3D hpet_read32(HPE=
T_ID);=0A =0A     num_chs =3D ((id & HPET_ID_NUMBER) >> HPET_ID_NUMBER_SHIF=
T);=0A@@ -391,8 +402,8 @@ static void __init hpet_fsb_cap_lookup(v=0A      =
   ch->flags =3D 0;=0A         ch->idx =3D i;=0A =0A-        if ( (ch->irq =
=3D hpet_assign_irq(num_hpets_used++)) < 0 )=0A-            num_hpets_used-=
-;=0A+        if ( hpet_assign_irq(ch) =3D=3D 0 )=0A+            num_hpets_=
used++;=0A     }=0A =0A     printk(XENLOG_INFO "HPET: %u timers (%u will =
be used for broadcast)\n",=0A@@ -438,7 +449,7 @@ static struct hpet_event_c=
hannel *hpet_g=0A =0A static void set_channel_irq_affinity(const struct =
hpet_event_channel *ch)=0A {=0A-    struct irq_desc *desc =3D irq_to_desc(c=
h->irq);=0A+    struct irq_desc *desc =3D irq_to_desc(ch->msi.irq);=0A =0A =
    ASSERT(!local_irq_is_enabled());=0A     spin_lock(&desc->lock);=0A@@ =
-530,7 +541,7 @@ void __init hpet_broadcast_init(void)=0A             =
hpet_events =3D xzalloc(struct hpet_event_channel);=0A         if ( =
!hpet_events || !zalloc_cpumask_var(&hpet_events->cpumask) )=0A            =
 return;=0A-        hpet_events->irq =3D -1;=0A+        hpet_events->msi.ir=
q =3D -1;=0A =0A         /* Start HPET legacy interrupts */=0A         cfg =
|=3D HPET_CFG_LEGACY;=0A@@ -598,8 +609,8 @@ void hpet_broadcast_resume(void=
)=0A =0A     for ( i =3D 0; i < n; i++ )=0A     {=0A-        if ( =
hpet_events[i].irq >=3D 0 )=0A-            __hpet_setup_msi_irq(irq_to_desc=
(hpet_events[i].irq));=0A+        if ( hpet_events[i].msi.irq >=3D 0 )=0A+ =
           __hpet_setup_msi_irq(irq_to_desc(hpet_events[i].msi.irq));=0A =
=0A         /* set HPET Tn as oneshot */=0A         cfg =3D hpet_read32(HPE=
T_Tn_CFG(hpet_events[i].idx));=0A--- a/xen/drivers/passthrough/iommu.c=0A++=
+ b/xen/drivers/passthrough/iommu.c=0A@@ -495,6 +495,12 @@ unsigned int =
iommu_read_apic_from_ire(un=0A     return ops->read_apic_from_ire(apic, =
reg);=0A }=0A =0A+int __init iommu_setup_hpet_msi(struct msi_desc =
*msi)=0A+{=0A+    const struct iommu_ops *ops =3D iommu_get_ops();=0A+    =
return ops->setup_hpet_msi ? ops->setup_hpet_msi(msi) : 0;=0A+}=0A+=0A =
void iommu_resume()=0A {=0A     const struct iommu_ops *ops =3D iommu_get_o=
ps();=0A--- a/xen/drivers/passthrough/vtd/dmar.c=0A+++ b/xen/drivers/passth=
rough/vtd/dmar.c=0A@@ -147,6 +147,34 @@ struct iommu * ioapic_to_iommu(unsi=
gned =0A     return NULL;=0A }=0A =0A+static bool_t acpi_hpet_device_match(=
=0A+    struct list_head *list, unsigned int hpet_id)=0A+{=0A+    struct =
acpi_hpet_unit *hpet;=0A+=0A+    list_for_each_entry( hpet, list, list =
)=0A+        if (hpet->id =3D=3D hpet_id)=0A+            return 1;=0A+    =
return 0;=0A+}=0A+=0A+struct acpi_drhd_unit *hpet_to_drhd(unsigned int =
hpet_id)=0A+{=0A+    struct acpi_drhd_unit *drhd;=0A+=0A+    list_for_each_=
entry( drhd, &acpi_drhd_units, list )=0A+        if ( acpi_hpet_device_matc=
h(&drhd->hpet_list, hpet_id) )=0A+            return drhd;=0A+    return =
NULL;=0A+}=0A+=0A+struct iommu *hpet_to_iommu(unsigned int hpet_id)=0A+{=0A=
+    struct acpi_drhd_unit *drhd =3D hpet_to_drhd(hpet_id);=0A+=0A+    =
return drhd ? drhd->iommu : NULL;=0A+}=0A+=0A static int __init acpi_regist=
er_atsr_unit(struct acpi_atsr_unit *atsr)=0A {=0A     /*=0A@@ -330,6 =
+358,22 @@ static int __init acpi_parse_dev_scope(=0A             if ( =
iommu_verbose )=0A                 dprintk(VTDPREFIX, " MSI HPET: =
%04x:%02x:%02x.%u\n",=0A                         seg, bus, path->dev, =
path->fn);=0A+=0A+            if ( type =3D=3D DMAR_TYPE )=0A+            =
{=0A+                struct acpi_drhd_unit *drhd =3D acpi_entry;=0A+       =
         struct acpi_hpet_unit *acpi_hpet_unit;=0A+=0A+                =
acpi_hpet_unit =3D xmalloc(struct acpi_hpet_unit);=0A+                if ( =
!acpi_hpet_unit )=0A+                    return -ENOMEM;=0A+               =
 acpi_hpet_unit->id =3D acpi_scope->enumeration_id;=0A+                =
acpi_hpet_unit->bus =3D bus;=0A+                acpi_hpet_unit->dev =3D =
path->dev;=0A+                acpi_hpet_unit->func =3D path->fn;=0A+       =
         list_add(&acpi_hpet_unit->list, &drhd->hpet_list);=0A+            =
}=0A+=0A             break;=0A =0A         case ACPI_DMAR_SCOPE_TYPE_ENDPOI=
NT:=0A@@ -407,6 +451,7 @@ acpi_parse_one_drhd(struct acpi_dmar_hea=0A     =
dmaru->segment =3D drhd->segment;=0A     dmaru->include_all =3D drhd->flags=
 & ACPI_DMAR_INCLUDE_ALL;=0A     INIT_LIST_HEAD(&dmaru->ioapic_list);=0A+  =
  INIT_LIST_HEAD(&dmaru->hpet_list);=0A     if ( iommu_verbose )=0A        =
 dprintk(VTDPREFIX, "  dmaru->address =3D %"PRIx64"\n",=0A                 =
dmaru->address);=0A--- a/xen/drivers/passthrough/vtd/dmar.h=0A+++ =
b/xen/drivers/passthrough/vtd/dmar.h=0A@@ -39,6 +39,19 @@ struct acpi_ioapi=
c_unit {=0A     }ioapic;=0A };=0A =0A+struct acpi_hpet_unit {=0A+    =
struct list_head list;=0A+    unsigned int id;=0A+    union {=0A+        =
u16 bdf;=0A+        struct {=0A+            u16 func: 3,=0A+               =
 dev:  5,=0A+                bus:  8;=0A+        };=0A+    };=0A+};=0A+=0A =
struct dmar_scope {=0A     DECLARE_BITMAP(buses, 256);         /* buses =
owned by this unit */=0A     u16    *devices;                    /* =
devices owned by this unit */=0A@@ -53,6 +66,7 @@ struct acpi_drhd_unit =
{=0A     u8     include_all:1;=0A     struct iommu *iommu;=0A     struct =
list_head ioapic_list;=0A+    struct list_head hpet_list;=0A };=0A =0A =
struct acpi_rmrr_unit {=0A--- a/xen/drivers/passthrough/vtd/extern.h=0A+++ =
b/xen/drivers/passthrough/vtd/extern.h=0A@@ -54,7 +54,9 @@ int iommu_flush_=
iec_index(struct iommu *=0A void clear_fault_bits(struct iommu *iommu);=0A =
=0A struct iommu * ioapic_to_iommu(unsigned int apic_id);=0A+struct iommu =
* hpet_to_iommu(unsigned int hpet_id);=0A struct acpi_drhd_unit * =
ioapic_to_drhd(unsigned int apic_id);=0A+struct acpi_drhd_unit * hpet_to_dr=
hd(unsigned int hpet_id);=0A struct acpi_drhd_unit * iommu_to_drhd(struct =
iommu *iommu);=0A struct acpi_rhsa_unit * drhd_to_rhsa(struct acpi_drhd_uni=
t *drhd);=0A =0A@@ -90,6 +92,8 @@ struct msi_msg;=0A void msi_msg_read_rema=
p_rte(struct msi_desc *, struct msi_msg *);=0A void msi_msg_write_remap_rte=
(struct msi_desc *, struct msi_msg *);=0A =0A+int intel_setup_hpet_msi(stru=
ct msi_desc *);=0A+=0A int is_igd_vt_enabled_quirk(void);=0A void =
platform_quirks_init(void);=0A void vtd_ops_preamble_quirk(struct iommu* =
iommu);=0A--- a/xen/drivers/passthrough/vtd/intremap.c=0A+++ b/xen/drivers/=
passthrough/vtd/intremap.c=0A@@ -107,6 +107,19 @@ static u16 apicid_to_bdf(=
int apic_id)=0A     return 0;=0A }=0A =0A+static u16 hpetid_to_bdf(unsigned=
 int hpet_id)=0A+{=0A+    struct acpi_drhd_unit *drhd =3D hpet_to_drhd(hpet=
_id);=0A+    struct acpi_hpet_unit *acpi_hpet_unit;=0A+=0A+    list_for_eac=
h_entry ( acpi_hpet_unit, &drhd->hpet_list, list )=0A+        if ( =
acpi_hpet_unit->id =3D=3D hpet_id )=0A+            return acpi_hpet_unit->b=
df;=0A+=0A+    dprintk(XENLOG_ERR VTDPREFIX, "Didn't find the bdf for HPET =
%u!\n", hpet_id);=0A+    return 0;=0A+}=0A+=0A static void set_ire_sid(stru=
ct iremap_entry *ire,=0A                         unsigned int svt, =
unsigned int sq, unsigned int sid)=0A {=0A@@ -121,6 +134,16 @@ static void =
set_ioapic_source_id(int api=0A                 apicid_to_bdf(apic_id));=0A=
 }=0A =0A+static void set_hpet_source_id(unsigned int id, struct iremap_ent=
ry *ire)=0A+{=0A+    /*=0A+     * Should really use SQ_ALL_16. Some =
platforms are broken.=0A+     * While we figure out the right quirks for =
these broken platforms, use=0A+     * SQ_13_IGNORE_3 for now.=0A+     =
*/=0A+    set_ire_sid(ire, SVT_VERIFY_SID_SQ, SQ_13_IGNORE_3, hpetid_to_bdf=
(id));=0A+}=0A+=0A int iommu_supports_eim(void)=0A {=0A     struct =
acpi_drhd_unit *drhd;=0A@@ -592,7 +615,10 @@ static int msi_msg_to_remap_en=
try(=0A         new_ire.lo.dst =3D ((msg->address_lo >> MSI_ADDR_DEST_ID_SH=
IFT)=0A                           & 0xff) << 8;=0A =0A-    set_msi_source_i=
d(pdev, &new_ire);=0A+    if ( pdev )=0A+        set_msi_source_id(pdev, =
&new_ire);=0A+    else=0A+        set_hpet_source_id(msi_desc->hpet_id, =
&new_ire);=0A     new_ire.hi.res_1 =3D 0;=0A     new_ire.lo.p =3D 1;    /* =
finally, set present bit */=0A =0A@@ -624,7 +650,9 @@ void msi_msg_read_rem=
ap_rte(=0A     struct iommu *iommu =3D NULL;=0A     struct ir_ctrl =
*ir_ctrl;=0A =0A-    if ( (drhd =3D acpi_find_matched_drhd_unit(pdev)) =
=3D=3D NULL )=0A+    drhd =3D pdev ? acpi_find_matched_drhd_unit(pdev)=0A+ =
               : hpet_to_drhd(msi_desc->hpet_id);=0A+    if ( !drhd )=0A   =
      return;=0A     iommu =3D drhd->iommu;=0A =0A@@ -643,7 +671,9 @@ void =
msi_msg_write_remap_rte(=0A     struct iommu *iommu =3D NULL;=0A     =
struct ir_ctrl *ir_ctrl;=0A =0A-    if ( (drhd =3D acpi_find_matched_drhd_u=
nit(pdev)) =3D=3D NULL )=0A+    drhd =3D pdev ? acpi_find_matched_drhd_unit=
(pdev)=0A+                : hpet_to_drhd(msi_desc->hpet_id);=0A+    if ( =
!drhd )=0A         return;=0A     iommu =3D drhd->iommu;=0A =0A@@ -654,6 =
+684,32 @@ void msi_msg_write_remap_rte(=0A     msi_msg_to_remap_entry(iomm=
u, pdev, msi_desc, msg);=0A }=0A =0A+int __init intel_setup_hpet_msi(struct=
 msi_desc *msi_desc)=0A+{=0A+    struct iommu *iommu =3D hpet_to_iommu(msi_=
desc->hpet_id);=0A+    struct ir_ctrl *ir_ctrl =3D iommu_ir_ctrl(iommu);=0A=
+    unsigned long flags;=0A+    int rc =3D 0;=0A+=0A+    if ( !ir_ctrl || =
!ir_ctrl->iremap_maddr )=0A+        return 0;=0A+=0A+    spin_lock_irqsave(=
&ir_ctrl->iremap_lock, flags);=0A+    msi_desc->remap_index =3D alloc_remap=
_entry(iommu);=0A+    if ( msi_desc->remap_index >=3D IREMAP_ENTRY_NR =
)=0A+    {=0A+        dprintk(XENLOG_ERR VTDPREFIX,=0A+                =
"%s: intremap index (%d) is larger than"=0A+                " the maximum =
index (%d)!\n",=0A+                __func__, msi_desc->remap_index, =
IREMAP_ENTRY_NR - 1);=0A+        msi_desc->remap_index =3D -1;=0A+        =
rc =3D -ENXIO;=0A+    }=0A+    spin_unlock_irqrestore(&ir_ctrl->iremap_lock=
, flags);=0A+=0A+    return rc;=0A+}=0A+=0A int enable_intremap(struct =
iommu *iommu, int eim)=0A {=0A     struct acpi_drhd_unit *drhd;=0A--- =
a/xen/drivers/passthrough/vtd/iommu.c=0A+++ b/xen/drivers/passthrough/vtd/i=
ommu.c=0A@@ -2396,6 +2396,7 @@ const struct iommu_ops intel_iommu_ops =
=3D=0A     .update_ire_from_msi =3D msi_msg_write_remap_rte,=0A     =
.read_apic_from_ire =3D io_apic_read_remap_rte,=0A     .read_msi_from_ire =
=3D msi_msg_read_remap_rte,=0A+    .setup_hpet_msi =3D intel_setup_hpet_msi=
,=0A     .suspend =3D vtd_suspend,=0A     .resume =3D vtd_resume,=0A     =
.share_p2m =3D iommu_set_pgd,=0A--- a/xen/include/asm-x86/hpet.h=0A+++ =
b/xen/include/asm-x86/hpet.h=0A@@ -53,6 +53,7 @@=0A     (*(volatile u32 =
*)(fix_to_virt(FIX_HPET_BASE) + (x)) =3D (y))=0A =0A extern unsigned long =
hpet_address;=0A+extern u8 hpet_blockid;=0A =0A /*=0A  * Detect and =
initialise HPET hardware: return counter update frequency.=0A--- a/xen/incl=
ude/asm-x86/msi.h=0A+++ b/xen/include/asm-x86/msi.h=0A@@ -97,7 +97,10 @@ =
struct msi_desc {=0A =0A 	struct list_head list;=0A =0A-	void =
__iomem *mask_base;        /* va for the entry in mask table */=0A+	=
union {=0A+		void __iomem *mask_base;/* va for the entry in =
mask table */=0A+		unsigned int hpet_id;   /* HPET (dev is =
NULL)             */=0A+	};=0A 	struct pci_dev *dev;=0A 	=
int irq;=0A =0A--- a/xen/include/xen/iommu.h=0A+++ b/xen/include/xen/iommu.=
h=0A@@ -109,6 +109,7 @@ struct iommu_ops {=0A     void (*update_ire_from_ms=
i)(struct msi_desc *msi_desc, struct msi_msg *msg);=0A     void (*read_msi_=
from_ire)(struct msi_desc *msi_desc, struct msi_msg *msg);=0A     unsigned =
int (*read_apic_from_ire)(unsigned int apic, unsigned int reg);=0A+    int =
(*setup_hpet_msi)(struct msi_desc *);=0A     void (*suspend)(void);=0A     =
void (*resume)(void);=0A     void (*share_p2m)(struct domain *d);=0A@@ =
-122,6 +123,7 @@ void iommu_update_ire_from_apic(unsigned=0A void =
iommu_update_ire_from_msi(struct msi_desc *msi_desc, struct msi_msg =
*msg);=0A void iommu_read_msi_from_ire(struct msi_desc *msi_desc, struct =
msi_msg *msg);=0A unsigned int iommu_read_apic_from_ire(unsigned int apic, =
unsigned int reg);=0A+int iommu_setup_hpet_msi(struct msi_desc *);=0A =0A =
void iommu_suspend(void);=0A void iommu_resume(void);=0A
--=__Part774654AB.1__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__Part774654AB.1__=--


From xen-devel-bounces@lists.xen.org Wed Oct 17 11:48:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 11:48:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOS6L-00072a-HJ; Wed, 17 Oct 2012 11:47:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOS6K-00072M-Ja
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 11:47:52 +0000
Received: from [85.158.137.99:17635] by server-2.bemta-3.messagelabs.com id
	8F/F3-00604-7EA9E705; Wed, 17 Oct 2012 11:47:51 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1350474470!21892083!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22148 invoked from network); 17 Oct 2012 11:47:51 -0000
Received: from mail-ea0-f173.google.com (HELO mail-ea0-f173.google.com)
	(209.85.215.173)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 11:47:51 -0000
Received: by mail-ea0-f173.google.com with SMTP id a1so1911131eaa.32
	for ; Wed, 17 Oct 2012 04:47:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=A3jEHiKlM6bSPzXnUVIanuDv9UQWjLc091X9T1OMqG8=;
	b=vg9dkHhxqf6hNjgz19pljKDpeWFKhR2ND7ARMlSCMzTlwmJlTnfdqRj54QHq2vOl5j
	SnT2urfjqthJNwfvOB05QNqM7YMLmu5im7kiRoydyB1NjM1abJ+sKnv99tCWSCauBcMt
	KPRgN761PPSdi8dkzPHELPM0RRd/kBTuPScft2C27yAjdlI9GDiIgS0DxsbFGPiwrS5e
	nwLCA9HheJFhv+bXm8OEEpXKV0k3/WrJ+6lHNY77pcaPjb7ash3QazBcXYh+Gn0dliZZ
	J2Kx7Y55yC6QbFiq3FJfUDVdDgcy9oUrcMMoOhgemtWdcBq4MKwCCgHlCJFnNEoiXPjR
	5pXQ==
Received: by 10.14.218.5 with SMTP id j5mr26511586eep.41.1350474470668;
	Wed, 17 Oct 2012 04:47:50 -0700 (PDT)
Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com.
	[86.183.156.141])
	by mx.google.com with ESMTPS id i41sm34573892eem.7.2012.10.17.04.47.49
	(version=SSLv3 cipher=OTHER); Wed, 17 Oct 2012 04:47:50 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Wed, 17 Oct 2012 12:47:44 +0100
From: Keir Fraser 
To: Jan Beulich ,
	xen-devel 
Message-ID: 
Thread-Topic: [Xen-devel] [PATCH] ACPI/APEI: fix ERST MOVE_DATA instruction
	implementation
Thread-Index: Ac2sXThL4EQ3HNbc3ke+5y/RxcARKg==
In-Reply-To: <507EB46502000078000A1F1E@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] ACPI/APEI: fix ERST MOVE_DATA instruction
 implementation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/10/2012 12:36, "Jan Beulich"  wrote:

> The src_base and dst_base fields in apei_exec_context are physical
> address, so they should be ioremaped before being used in ERST
> MOVE_DATA instruction.
> 
> Reported-by: Javier Martinez Canillas 
> Reported-by: Andrew Morton 
> Signed-off-by: Huang Ying 
> 
> Replace use of ioremap() by __acpi_map_table()/set_fixmap(). Fix error
> handling.
> 
> Signed-off-by: Jan Beulich 

Acked-by: Keir Fraser 

> ---
> Note that I have no way to test this code other than by having it go
> through the tester, since I have no hardware available to reproduce
> the regression found there (in other words, this is just a blind
> attempt at addressing the problem uncovered by 26060:4fc87c2f31a0).
> 
> --- a/xen/drivers/acpi/apei/erst.c
> +++ b/xen/drivers/acpi/apei/erst.c
> @@ -247,15 +247,64 @@ static int erst_exec_move_data(struct ap
>  {
> int rc;
> u64 offset;
> +#ifdef CONFIG_X86
> + enum fixed_addresses idx;
> +#endif
> + void *src, *dst;
> +
> + /* ioremap does not work in interrupt context */
> + if (in_irq()) {
> +  printk(KERN_WARNING
> +         "MOVE_DATA cannot be used in interrupt context\n");
> +  return -EBUSY;
> + }
>  
> rc = __apei_exec_read_register(entry, &offset);
> if (rc)
> return rc;
> - memmove((void *)(unsigned long)(ctx->dst_base + offset),
> -  (void *)(unsigned long)(ctx->src_base + offset),
> -  ctx->var2);
>  
> - return 0;
> +#ifdef CONFIG_X86
> + switch (ctx->var2) {
> + case 0:
> +  return 0;
> + case 1 ... PAGE_SIZE:
> +  break;
> + default:
> +  printk(KERN_WARNING
> +         "MOVE_DATA cannot be used for %#"PRIx64" bytes of data\n",
> +         ctx->var2);
> +  return -EOPNOTSUPP;
> + }
> +
> + src = __acpi_map_table(ctx->src_base + offset, ctx->var2);
> +#else
> + src = ioremap(ctx->src_base + offset, ctx->var2);
> +#endif
> + if (!src)
> +  return -ENOMEM;
> +
> +#ifdef CONFIG_X86
> + BUILD_BUG_ON(FIX_ACPI_PAGES < 4);
> + idx = virt_to_fix((unsigned long)src + 2 * PAGE_SIZE);
> + offset += ctx->dst_base;
> + dst = (void *)fix_to_virt(idx) + (offset & ~PAGE_MASK);
> + set_fixmap(idx, offset);
> + if (PFN_DOWN(offset) != PFN_DOWN(offset + ctx->var2 - 1)) {
> +  idx = virt_to_fix((unsigned long)dst + PAGE_SIZE);
> +  set_fixmap(idx, offset + PAGE_SIZE);
> + }
> +#else
> + dst = ioremap(ctx->dst_base + offset, ctx->var2);
> +#endif
> + if (dst) {
> +  memmove(dst, src, ctx->var2);
> +  iounmap(dst);
> + } else
> +  rc = -ENOMEM;
> +
> + iounmap(src);
> +
> + return rc;
>  }
>  
>  static struct apei_exec_ins_type erst_ins_type[] = {
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 11:48:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 11:48:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOS6L-00072a-HJ; Wed, 17 Oct 2012 11:47:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOS6K-00072M-Ja
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 11:47:52 +0000
Received: from [85.158.137.99:17635] by server-2.bemta-3.messagelabs.com id
	8F/F3-00604-7EA9E705; Wed, 17 Oct 2012 11:47:51 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1350474470!21892083!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22148 invoked from network); 17 Oct 2012 11:47:51 -0000
Received: from mail-ea0-f173.google.com (HELO mail-ea0-f173.google.com)
	(209.85.215.173)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 11:47:51 -0000
Received: by mail-ea0-f173.google.com with SMTP id a1so1911131eaa.32
	for ; Wed, 17 Oct 2012 04:47:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=A3jEHiKlM6bSPzXnUVIanuDv9UQWjLc091X9T1OMqG8=;
	b=vg9dkHhxqf6hNjgz19pljKDpeWFKhR2ND7ARMlSCMzTlwmJlTnfdqRj54QHq2vOl5j
	SnT2urfjqthJNwfvOB05QNqM7YMLmu5im7kiRoydyB1NjM1abJ+sKnv99tCWSCauBcMt
	KPRgN761PPSdi8dkzPHELPM0RRd/kBTuPScft2C27yAjdlI9GDiIgS0DxsbFGPiwrS5e
	nwLCA9HheJFhv+bXm8OEEpXKV0k3/WrJ+6lHNY77pcaPjb7ash3QazBcXYh+Gn0dliZZ
	J2Kx7Y55yC6QbFiq3FJfUDVdDgcy9oUrcMMoOhgemtWdcBq4MKwCCgHlCJFnNEoiXPjR
	5pXQ==
Received: by 10.14.218.5 with SMTP id j5mr26511586eep.41.1350474470668;
	Wed, 17 Oct 2012 04:47:50 -0700 (PDT)
Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com.
	[86.183.156.141])
	by mx.google.com with ESMTPS id i41sm34573892eem.7.2012.10.17.04.47.49
	(version=SSLv3 cipher=OTHER); Wed, 17 Oct 2012 04:47:50 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Wed, 17 Oct 2012 12:47:44 +0100
From: Keir Fraser 
To: Jan Beulich ,
	xen-devel 
Message-ID: 
Thread-Topic: [Xen-devel] [PATCH] ACPI/APEI: fix ERST MOVE_DATA instruction
	implementation
Thread-Index: Ac2sXThL4EQ3HNbc3ke+5y/RxcARKg==
In-Reply-To: <507EB46502000078000A1F1E@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] ACPI/APEI: fix ERST MOVE_DATA instruction
 implementation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/10/2012 12:36, "Jan Beulich"  wrote:

> The src_base and dst_base fields in apei_exec_context are physical
> address, so they should be ioremaped before being used in ERST
> MOVE_DATA instruction.
> 
> Reported-by: Javier Martinez Canillas 
> Reported-by: Andrew Morton 
> Signed-off-by: Huang Ying 
> 
> Replace use of ioremap() by __acpi_map_table()/set_fixmap(). Fix error
> handling.
> 
> Signed-off-by: Jan Beulich 

Acked-by: Keir Fraser 

> ---
> Note that I have no way to test this code other than by having it go
> through the tester, since I have no hardware available to reproduce
> the regression found there (in other words, this is just a blind
> attempt at addressing the problem uncovered by 26060:4fc87c2f31a0).
> 
> --- a/xen/drivers/acpi/apei/erst.c
> +++ b/xen/drivers/acpi/apei/erst.c
> @@ -247,15 +247,64 @@ static int erst_exec_move_data(struct ap
>  {
> int rc;
> u64 offset;
> +#ifdef CONFIG_X86
> + enum fixed_addresses idx;
> +#endif
> + void *src, *dst;
> +
> + /* ioremap does not work in interrupt context */
> + if (in_irq()) {
> +  printk(KERN_WARNING
> +         "MOVE_DATA cannot be used in interrupt context\n");
> +  return -EBUSY;
> + }
>  
> rc = __apei_exec_read_register(entry, &offset);
> if (rc)
> return rc;
> - memmove((void *)(unsigned long)(ctx->dst_base + offset),
> -  (void *)(unsigned long)(ctx->src_base + offset),
> -  ctx->var2);
>  
> - return 0;
> +#ifdef CONFIG_X86
> + switch (ctx->var2) {
> + case 0:
> +  return 0;
> + case 1 ... PAGE_SIZE:
> +  break;
> + default:
> +  printk(KERN_WARNING
> +         "MOVE_DATA cannot be used for %#"PRIx64" bytes of data\n",
> +         ctx->var2);
> +  return -EOPNOTSUPP;
> + }
> +
> + src = __acpi_map_table(ctx->src_base + offset, ctx->var2);
> +#else
> + src = ioremap(ctx->src_base + offset, ctx->var2);
> +#endif
> + if (!src)
> +  return -ENOMEM;
> +
> +#ifdef CONFIG_X86
> + BUILD_BUG_ON(FIX_ACPI_PAGES < 4);
> + idx = virt_to_fix((unsigned long)src + 2 * PAGE_SIZE);
> + offset += ctx->dst_base;
> + dst = (void *)fix_to_virt(idx) + (offset & ~PAGE_MASK);
> + set_fixmap(idx, offset);
> + if (PFN_DOWN(offset) != PFN_DOWN(offset + ctx->var2 - 1)) {
> +  idx = virt_to_fix((unsigned long)dst + PAGE_SIZE);
> +  set_fixmap(idx, offset + PAGE_SIZE);
> + }
> +#else
> + dst = ioremap(ctx->dst_base + offset, ctx->var2);
> +#endif
> + if (dst) {
> +  memmove(dst, src, ctx->var2);
> +  iounmap(dst);
> + } else
> +  rc = -ENOMEM;
> +
> + iounmap(src);
> +
> + return rc;
>  }
>  
>  static struct apei_exec_ins_type erst_ins_type[] = {
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 11:48:57 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 11:48:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOS7A-0007Ac-V7; Wed, 17 Oct 2012 11:48:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOS79-0007AP-7O
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 11:48:43 +0000
Received: from [193.109.254.147:21844] by server-11.bemta-14.messagelabs.com
	id BD/2A-09558-A1B9E705; Wed, 17 Oct 2012 11:48:42 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1350474518!5698007!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzcwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2716 invoked from network); 17 Oct 2012 11:48:39 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 11:48:39 -0000
X-IronPort-AV: E=Sophos;i="4.80,600,1344211200"; d="scan'208";a="41489301"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 11:48:38 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Wed, 17 Oct 2012
	07:48:37 -0400
Message-ID: <507E9B14.1040601@citrix.com>
Date: Wed, 17 Oct 2012 12:48:36 +0100
From: David Vrabel 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: David Vrabel 
References: <1350474150-3990-1-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1350474150-3990-1-git-send-email-david.vrabel@citrix.com>
Cc: Frediano Ziglio ,
	Konrad Rzeszutek Wilk ,
	"stable@kernel.org" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] xen/x86: don't corrupt %eip when returning
 from a signal handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/10/12 12:42, David Vrabel wrote:
> From: David Vrabel 
> 
> In 32 bit guests, if a userspace process has %eax == -ERESTARTSYS
> (-512) or -ERESTARTNOINTR (-513) when it is interrupted by an event
> /and/ the process has a pending signal then %eip (and %eax) are
> corrupted when returning to the main process after handling the
> signal.  The application may then crash with SIGSEGV or a SIGILL or it
> may have subtly incorrect behaviour (depending on what instruction it
> returned to).

The following test program shows the bug.  It will receive the signal
when in the infinite loop and return to the preceeding int 3 instruction.

Big thanks to Frediano for producing the test program and the majority
of the effort in tracking down this bug.

David

8<--------------------------
#include 
#include 
#include 
#include 
#include 

static void handler(int sig)
{
	static unsigned count = 0;
	if (++count == 60 * 1000)
		exit(0);
}

int main(void)
{
	struct sigaction act;

	// set signal
	sigfillset(&act.sa_mask);
	act.sa_flags = 0;
	act.sa_handler = handler;

	int err = sigaction(SIGALRM, &act, NULL);
	assert(!err);

	// set timer
	struct itimerval ival = { { 0, 1000 }, { 0, 1000 } };
	err = setitimer(ITIMER_REAL, &ival, NULL);
	assert(!err);

#if !defined(__x86_64__) && !defined(__i386__)
# error This code work only on Intel architecture!
#endif

	// wait for a core !!
	asm(
#ifdef __x86_64__
"	mov	$-513, %rax\n"
#else
"	mov	$-513, %eax\n"
#endif
"	jmp	infinite\n"
"	int	$3\n"
"	int	$3\n"
"	int	$3\n"
"	int	$3\n"
"infinite:\n"
"	jmp	infinite\n"
);

	return 0;
}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 11:48:57 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 11:48:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOS7A-0007Ac-V7; Wed, 17 Oct 2012 11:48:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOS79-0007AP-7O
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 11:48:43 +0000
Received: from [193.109.254.147:21844] by server-11.bemta-14.messagelabs.com
	id BD/2A-09558-A1B9E705; Wed, 17 Oct 2012 11:48:42 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1350474518!5698007!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzcwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2716 invoked from network); 17 Oct 2012 11:48:39 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 11:48:39 -0000
X-IronPort-AV: E=Sophos;i="4.80,600,1344211200"; d="scan'208";a="41489301"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 11:48:38 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Wed, 17 Oct 2012
	07:48:37 -0400
Message-ID: <507E9B14.1040601@citrix.com>
Date: Wed, 17 Oct 2012 12:48:36 +0100
From: David Vrabel 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: David Vrabel 
References: <1350474150-3990-1-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1350474150-3990-1-git-send-email-david.vrabel@citrix.com>
Cc: Frediano Ziglio ,
	Konrad Rzeszutek Wilk ,
	"stable@kernel.org" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] xen/x86: don't corrupt %eip when returning
 from a signal handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/10/12 12:42, David Vrabel wrote:
> From: David Vrabel 
> 
> In 32 bit guests, if a userspace process has %eax == -ERESTARTSYS
> (-512) or -ERESTARTNOINTR (-513) when it is interrupted by an event
> /and/ the process has a pending signal then %eip (and %eax) are
> corrupted when returning to the main process after handling the
> signal.  The application may then crash with SIGSEGV or a SIGILL or it
> may have subtly incorrect behaviour (depending on what instruction it
> returned to).

The following test program shows the bug.  It will receive the signal
when in the infinite loop and return to the preceeding int 3 instruction.

Big thanks to Frediano for producing the test program and the majority
of the effort in tracking down this bug.

David

8<--------------------------
#include 
#include 
#include 
#include 
#include 

static void handler(int sig)
{
	static unsigned count = 0;
	if (++count == 60 * 1000)
		exit(0);
}

int main(void)
{
	struct sigaction act;

	// set signal
	sigfillset(&act.sa_mask);
	act.sa_flags = 0;
	act.sa_handler = handler;

	int err = sigaction(SIGALRM, &act, NULL);
	assert(!err);

	// set timer
	struct itimerval ival = { { 0, 1000 }, { 0, 1000 } };
	err = setitimer(ITIMER_REAL, &ival, NULL);
	assert(!err);

#if !defined(__x86_64__) && !defined(__i386__)
# error This code work only on Intel architecture!
#endif

	// wait for a core !!
	asm(
#ifdef __x86_64__
"	mov	$-513, %rax\n"
#else
"	mov	$-513, %eax\n"
#endif
"	jmp	infinite\n"
"	int	$3\n"
"	int	$3\n"
"	int	$3\n"
"	int	$3\n"
"infinite:\n"
"	jmp	infinite\n"
);

	return 0;
}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 11:53:01 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 11:53:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOSB5-0007SN-KO; Wed, 17 Oct 2012 11:52:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOSB4-0007SD-Hc
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 11:52:46 +0000
Received: from [85.158.143.35:30063] by server-2.bemta-4.messagelabs.com id
	56/71-22268-D0C9E705; Wed, 17 Oct 2012 11:52:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1350474765!14375198!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23113 invoked from network); 17 Oct 2012 11:52:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 11:52:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,600,1344211200"; d="scan'208";a="15224448"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 11:52:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 12:52:45 +0100
Message-ID: <1350474763.2460.59.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: David Vrabel 
Date: Wed, 17 Oct 2012 12:52:43 +0100
In-Reply-To: <1350474150-3990-1-git-send-email-david.vrabel@citrix.com>
References: <1350474150-3990-1-git-send-email-david.vrabel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Frediano Ziglio , Konrad
	Rzeszutek Wilk ,
	"stable@kernel.org" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] xen/x86: don't corrupt %eip when returning
 from a signal handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-17 at 12:42 +0100, David Vrabel wrote:
> From: David Vrabel 
> 
> In 32 bit guests, if a userspace process has %eax == -ERESTARTSYS
> (-512) or -ERESTARTNOINTR (-513) when it is interrupted by an event
> /and/ the process has a pending signal then %eip (and %eax) are
> corrupted when returning to the main process after handling the
> signal.  The application may then crash with SIGSEGV or a SIGILL or it
> may have subtly incorrect behaviour (depending on what instruction it
> returned to).
> 
> The occurs because handle_signal() is incorrectly thinking that there
> is a system call that needs to restarted so it adjusts %eip and %eax
> to re-execute the system call instruction (even though user space had
> not done a system call).
> 
> If %eax == -514 (-ERESTARTNOHAND (-514) or -ERESTART_RESTARTBLOCK
> (-516) then handle_signal() only corrupted %eax (by setting it to
> -EINTR).  This may cause the application to crash or have incorrect
> behaviour.
> 
> handle_signal() assumes that regs->orig_ax >= 0 means a system call so
> any kernel entry point that is not for a system call must push a
> negative value for orig_ax.  For example, for physical interrupts on
> bare metal the inverse of the vector is pushed and page_fault() sets
> regs->orig_ax to -1, overwriting the hardware provided error code.
> 
> xen_hypervisor_callback() was incorrectly pushing 0 for orig_ax
> instead of -1.  For consistency, we also change
> xen_failsafe_callback().
> 
> Classic Xen kernels pushed %eax which works as %eax cannot be both
> non-negative and -RESTARTSYS (etc.), but using -1 avoids the
> additional tests in handle_signal().
> 
> Signed-off-by: David Vrabel 

Acked-by: Ian Campbell 

> Cc: stable@kernel.org
> ---
>  arch/x86/kernel/entry_32.S |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
> index 2c63407..6a19e66 100644
> --- a/arch/x86/kernel/entry_32.S
> +++ b/arch/x86/kernel/entry_32.S
> @@ -1042,7 +1042,7 @@ ENTRY(xen_sysenter_target)
>  
>  ENTRY(xen_hypervisor_callback)
>  	CFI_STARTPROC
> -	pushl_cfi $0
> +	pushl_cfi $-1 /* orig_ax = -1 => not a system call */
>  	SAVE_ALL
>  	TRACE_IRQS_OFF
>  
> @@ -1078,7 +1078,7 @@ ENDPROC(xen_hypervisor_callback)
>  # We distinguish between categories by maintaining a status value in EAX.
>  ENTRY(xen_failsafe_callback)
>  	CFI_STARTPROC
> -	pushl_cfi %eax
> +	pushl_cfi $-1  /* orig_ax = -1 => not a system call */
>  	movl $1,%eax
>  1:	mov 4(%esp),%ds
>  2:	mov 8(%esp),%es



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 11:53:01 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 11:53:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOSB5-0007SN-KO; Wed, 17 Oct 2012 11:52:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOSB4-0007SD-Hc
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 11:52:46 +0000
Received: from [85.158.143.35:30063] by server-2.bemta-4.messagelabs.com id
	56/71-22268-D0C9E705; Wed, 17 Oct 2012 11:52:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1350474765!14375198!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23113 invoked from network); 17 Oct 2012 11:52:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 11:52:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,600,1344211200"; d="scan'208";a="15224448"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 11:52:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 12:52:45 +0100
Message-ID: <1350474763.2460.59.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: David Vrabel 
Date: Wed, 17 Oct 2012 12:52:43 +0100
In-Reply-To: <1350474150-3990-1-git-send-email-david.vrabel@citrix.com>
References: <1350474150-3990-1-git-send-email-david.vrabel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Frediano Ziglio , Konrad
	Rzeszutek Wilk ,
	"stable@kernel.org" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] xen/x86: don't corrupt %eip when returning
 from a signal handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-17 at 12:42 +0100, David Vrabel wrote:
> From: David Vrabel 
> 
> In 32 bit guests, if a userspace process has %eax == -ERESTARTSYS
> (-512) or -ERESTARTNOINTR (-513) when it is interrupted by an event
> /and/ the process has a pending signal then %eip (and %eax) are
> corrupted when returning to the main process after handling the
> signal.  The application may then crash with SIGSEGV or a SIGILL or it
> may have subtly incorrect behaviour (depending on what instruction it
> returned to).
> 
> The occurs because handle_signal() is incorrectly thinking that there
> is a system call that needs to restarted so it adjusts %eip and %eax
> to re-execute the system call instruction (even though user space had
> not done a system call).
> 
> If %eax == -514 (-ERESTARTNOHAND (-514) or -ERESTART_RESTARTBLOCK
> (-516) then handle_signal() only corrupted %eax (by setting it to
> -EINTR).  This may cause the application to crash or have incorrect
> behaviour.
> 
> handle_signal() assumes that regs->orig_ax >= 0 means a system call so
> any kernel entry point that is not for a system call must push a
> negative value for orig_ax.  For example, for physical interrupts on
> bare metal the inverse of the vector is pushed and page_fault() sets
> regs->orig_ax to -1, overwriting the hardware provided error code.
> 
> xen_hypervisor_callback() was incorrectly pushing 0 for orig_ax
> instead of -1.  For consistency, we also change
> xen_failsafe_callback().
> 
> Classic Xen kernels pushed %eax which works as %eax cannot be both
> non-negative and -RESTARTSYS (etc.), but using -1 avoids the
> additional tests in handle_signal().
> 
> Signed-off-by: David Vrabel 

Acked-by: Ian Campbell 

> Cc: stable@kernel.org
> ---
>  arch/x86/kernel/entry_32.S |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
> index 2c63407..6a19e66 100644
> --- a/arch/x86/kernel/entry_32.S
> +++ b/arch/x86/kernel/entry_32.S
> @@ -1042,7 +1042,7 @@ ENTRY(xen_sysenter_target)
>  
>  ENTRY(xen_hypervisor_callback)
>  	CFI_STARTPROC
> -	pushl_cfi $0
> +	pushl_cfi $-1 /* orig_ax = -1 => not a system call */
>  	SAVE_ALL
>  	TRACE_IRQS_OFF
>  
> @@ -1078,7 +1078,7 @@ ENDPROC(xen_hypervisor_callback)
>  # We distinguish between categories by maintaining a status value in EAX.
>  ENTRY(xen_failsafe_callback)
>  	CFI_STARTPROC
> -	pushl_cfi %eax
> +	pushl_cfi $-1  /* orig_ax = -1 => not a system call */
>  	movl $1,%eax
>  1:	mov 4(%esp),%ds
>  2:	mov 8(%esp),%es



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 11:53:44 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 11:53:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOSBp-0007WQ-27; Wed, 17 Oct 2012 11:53:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOSBo-0007WF-20
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 11:53:32 +0000
Received: from [85.158.143.99:30413] by server-1.bemta-4.messagelabs.com id
	74/8F-19134-B3C9E705; Wed, 17 Oct 2012 11:53:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1350474810!24859748!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27881 invoked from network); 17 Oct 2012 11:53:30 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-216.messagelabs.com with SMTP;
	17 Oct 2012 11:53:30 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 17 Oct 2012 12:53:30 +0100
Message-Id: <507EB85802000078000A1F79@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 17 Oct 2012 12:53:28 +0100
From: "Jan Beulich" 
To: "xen-devel" 
References: <507EB46502000078000A1F1E@nat28.tlf.novell.com>
In-Reply-To: <507EB46502000078000A1F1E@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Subject: Re: [Xen-devel] [PATCH] ACPI/APEI: fix ERST MOVE_DATA instruction
 implementation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 17.10.12 at 13:36, "Jan Beulich"  wrote:
> --- a/xen/drivers/acpi/apei/erst.c
> +++ b/xen/drivers/acpi/apei/erst.c
> @@ -247,15 +247,64 @@ static int erst_exec_move_data(struct ap
>  {
>  	int rc;
>  	u64 offset;
> +#ifdef CONFIG_X86
> +	enum fixed_addresses idx;
> +#endif
> +	void *src, *dst;
> +
> +	/* ioremap does not work in interrupt context */
> +	if (in_irq()) {
> +		printk(KERN_WARNING
> +		       "MOVE_DATA cannot be used in interrupt context\n");
> +		return -EBUSY;
> +	}
>  
>  	rc = __apei_exec_read_register(entry, &offset);
>  	if (rc)
>  		return rc;
> -	memmove((void *)(unsigned long)(ctx->dst_base + offset),
> -		(void *)(unsigned long)(ctx->src_base + offset),
> -		ctx->var2);
>  
> -	return 0;
> +#ifdef CONFIG_X86
> +	switch (ctx->var2) {
> +	case 0:
> +		return 0;
> +	case 1 ... PAGE_SIZE:
> +		break;
> +	default:
> +		printk(KERN_WARNING
> +		       "MOVE_DATA cannot be used for %#"PRIx64" bytes of data\n",
> +		       ctx->var2);
> +		return -EOPNOTSUPP;
> +	}
> +
> +	src = __acpi_map_table(ctx->src_base + offset, ctx->var2);
> +#else
> +	src = ioremap(ctx->src_base + offset, ctx->var2);
> +#endif

Before anyone asks - yes, I have added to my todo list to put in
place a proper ioremap() for x86. But since I'm under some time
pressure right now, this was the faster route to something that
can be committed to see whether the regression goes away.

Jan

> +	if (!src)
> +		return -ENOMEM;
> +
> +#ifdef CONFIG_X86
> +	BUILD_BUG_ON(FIX_ACPI_PAGES < 4);
> +	idx = virt_to_fix((unsigned long)src + 2 * PAGE_SIZE);
> +	offset += ctx->dst_base;
> +	dst = (void *)fix_to_virt(idx) + (offset & ~PAGE_MASK);
> +	set_fixmap(idx, offset);
> +	if (PFN_DOWN(offset) != PFN_DOWN(offset + ctx->var2 - 1)) {
> +		idx = virt_to_fix((unsigned long)dst + PAGE_SIZE);
> +		set_fixmap(idx, offset + PAGE_SIZE);
> +	}
> +#else
> +	dst = ioremap(ctx->dst_base + offset, ctx->var2);
> +#endif
> +	if (dst) {
> +		memmove(dst, src, ctx->var2);
> +		iounmap(dst);
> +	} else
> +		rc = -ENOMEM;
> +
> +	iounmap(src);
> +
> +	return rc;
>  }
>  
>  static struct apei_exec_ins_type erst_ins_type[] = {




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 11:53:44 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 11:53:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOSBp-0007WQ-27; Wed, 17 Oct 2012 11:53:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOSBo-0007WF-20
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 11:53:32 +0000
Received: from [85.158.143.99:30413] by server-1.bemta-4.messagelabs.com id
	74/8F-19134-B3C9E705; Wed, 17 Oct 2012 11:53:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1350474810!24859748!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27881 invoked from network); 17 Oct 2012 11:53:30 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-216.messagelabs.com with SMTP;
	17 Oct 2012 11:53:30 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 17 Oct 2012 12:53:30 +0100
Message-Id: <507EB85802000078000A1F79@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 17 Oct 2012 12:53:28 +0100
From: "Jan Beulich" 
To: "xen-devel" 
References: <507EB46502000078000A1F1E@nat28.tlf.novell.com>
In-Reply-To: <507EB46502000078000A1F1E@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Subject: Re: [Xen-devel] [PATCH] ACPI/APEI: fix ERST MOVE_DATA instruction
 implementation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 17.10.12 at 13:36, "Jan Beulich"  wrote:
> --- a/xen/drivers/acpi/apei/erst.c
> +++ b/xen/drivers/acpi/apei/erst.c
> @@ -247,15 +247,64 @@ static int erst_exec_move_data(struct ap
>  {
>  	int rc;
>  	u64 offset;
> +#ifdef CONFIG_X86
> +	enum fixed_addresses idx;
> +#endif
> +	void *src, *dst;
> +
> +	/* ioremap does not work in interrupt context */
> +	if (in_irq()) {
> +		printk(KERN_WARNING
> +		       "MOVE_DATA cannot be used in interrupt context\n");
> +		return -EBUSY;
> +	}
>  
>  	rc = __apei_exec_read_register(entry, &offset);
>  	if (rc)
>  		return rc;
> -	memmove((void *)(unsigned long)(ctx->dst_base + offset),
> -		(void *)(unsigned long)(ctx->src_base + offset),
> -		ctx->var2);
>  
> -	return 0;
> +#ifdef CONFIG_X86
> +	switch (ctx->var2) {
> +	case 0:
> +		return 0;
> +	case 1 ... PAGE_SIZE:
> +		break;
> +	default:
> +		printk(KERN_WARNING
> +		       "MOVE_DATA cannot be used for %#"PRIx64" bytes of data\n",
> +		       ctx->var2);
> +		return -EOPNOTSUPP;
> +	}
> +
> +	src = __acpi_map_table(ctx->src_base + offset, ctx->var2);
> +#else
> +	src = ioremap(ctx->src_base + offset, ctx->var2);
> +#endif

Before anyone asks - yes, I have added to my todo list to put in
place a proper ioremap() for x86. But since I'm under some time
pressure right now, this was the faster route to something that
can be committed to see whether the regression goes away.

Jan

> +	if (!src)
> +		return -ENOMEM;
> +
> +#ifdef CONFIG_X86
> +	BUILD_BUG_ON(FIX_ACPI_PAGES < 4);
> +	idx = virt_to_fix((unsigned long)src + 2 * PAGE_SIZE);
> +	offset += ctx->dst_base;
> +	dst = (void *)fix_to_virt(idx) + (offset & ~PAGE_MASK);
> +	set_fixmap(idx, offset);
> +	if (PFN_DOWN(offset) != PFN_DOWN(offset + ctx->var2 - 1)) {
> +		idx = virt_to_fix((unsigned long)dst + PAGE_SIZE);
> +		set_fixmap(idx, offset + PAGE_SIZE);
> +	}
> +#else
> +	dst = ioremap(ctx->dst_base + offset, ctx->var2);
> +#endif
> +	if (dst) {
> +		memmove(dst, src, ctx->var2);
> +		iounmap(dst);
> +	} else
> +		rc = -ENOMEM;
> +
> +	iounmap(src);
> +
> +	return rc;
>  }
>  
>  static struct apei_exec_ins_type erst_ins_type[] = {




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 11:59:01 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 11:59:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOSGu-0007lB-Qg; Wed, 17 Oct 2012 11:58:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOSGt-0007l4-7j
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 11:58:47 +0000
Received: from [193.109.254.147:35225] by server-11.bemta-14.messagelabs.com
	id 57/38-09558-67D9E705; Wed, 17 Oct 2012 11:58:46 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1350475125!2537806!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22451 invoked from network); 17 Oct 2012 11:58:45 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 11:58:45 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so4322436eek.32
	for ; Wed, 17 Oct 2012 04:58:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=QCoeUG/6iX8jAFdD41XKVa5QWTfAte/2Ld2FMGp8U6s=;
	b=Perqfo3jchRZwoZaDko5ZQaU8kTCvQC1TLwRhmu7jfPOUIT5oA8vNPFFIiyooDX2d6
	rRwZXTFG4A8E+Bq7ZIorNH5Uu/7jieA7QwsP9yw2siE/qPaJqXLDn6cE/TnBGjSh/xNX
	a6ivgEpsIuf0UctPeYDj7wRqIzpaJrxZ5x2+pLSoFax4qQLeTX7Cu99Jp7lsWgzN+d36
	La7+pR5HskKzExrUqcgld1/1vBpBuiORHZ5qOEDyhcKxsD3uXDLJSg5JEbKywv+/RLcg
	jD9brRogwylzrVEKnb12PvMmcwy8dBN5jusA7rDbQWPf/XoRc9fgjhqOrVo1V9fSMIo0
	70sg==
Received: by 10.14.220.134 with SMTP id o6mr26405263eep.35.1350475125650;
	Wed, 17 Oct 2012 04:58:45 -0700 (PDT)
Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com.
	[86.183.156.141])
	by mx.google.com with ESMTPS id t7sm34644472eel.14.2012.10.17.04.58.42
	(version=SSLv3 cipher=OTHER); Wed, 17 Oct 2012 04:58:44 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Wed, 17 Oct 2012 12:58:36 +0100
From: Keir Fraser 
To: Jan Beulich 
Message-ID: 
Thread-Topic: [PATCH v2 1/3] x86/HPET: obtain proper lock for changing IRQ
	affinity
Thread-Index: Ac2sXrzq5Mr3DhlJQE6q8tACcsuo9g==
In-Reply-To: <507EB69302000078000A1F46@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel 
Subject: Re: [Xen-devel] [PATCH v2 1/3] x86/HPET: obtain proper lock for
 changing IRQ affinity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/10/2012 12:45, "Jan Beulich"  wrote:

> The IRQ descriptor lock should be held while adjusting the affinity of
> any IRQ; the HPET channel lock isn't sufficient to protect namely
> against races with moving the IRQ to a different CPU.
> 
> Signed-off-by: Jan Beulich 

Acked-by: Keir Fraser 

> ---
> v2: rename new helper function
> 
> --- a/xen/arch/x86/hpet.c
> +++ b/xen/arch/x86/hpet.c
> @@ -436,6 +436,16 @@ static struct hpet_event_channel *hpet_g
>      return ch;
>  }
>  
> +static void set_channel_irq_affinity(const struct hpet_event_channel *ch)
> +{
> +    struct irq_desc *desc = irq_to_desc(ch->irq);
> +
> +    ASSERT(!local_irq_is_enabled());
> +    spin_lock(&desc->lock);
> +    hpet_msi_set_affinity(desc, cpumask_of(ch->cpu));
> +    spin_unlock(&desc->lock);
> +}
> +
>  static void hpet_attach_channel(unsigned int cpu,
>                                  struct hpet_event_channel *ch)
>  {
> @@ -450,7 +460,7 @@ static void hpet_attach_channel(unsigned
>      if ( ch->cpu != cpu )
>          return;
>  
> -    hpet_msi_set_affinity(irq_to_desc(ch->irq), cpumask_of(ch->cpu));
> +    set_channel_irq_affinity(ch);
>  }
>  
>  static void hpet_detach_channel(unsigned int cpu,
> @@ -472,7 +482,7 @@ static void hpet_detach_channel(unsigned
>      }
>  
>      ch->cpu = cpumask_first(ch->cpumask);
> -    hpet_msi_set_affinity(irq_to_desc(ch->irq), cpumask_of(ch->cpu));
> +    set_channel_irq_affinity(ch);
>  }
>  
>  #include 
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 11:59:01 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 11:59:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOSGu-0007lB-Qg; Wed, 17 Oct 2012 11:58:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOSGt-0007l4-7j
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 11:58:47 +0000
Received: from [193.109.254.147:35225] by server-11.bemta-14.messagelabs.com
	id 57/38-09558-67D9E705; Wed, 17 Oct 2012 11:58:46 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1350475125!2537806!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22451 invoked from network); 17 Oct 2012 11:58:45 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 11:58:45 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so4322436eek.32
	for ; Wed, 17 Oct 2012 04:58:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=QCoeUG/6iX8jAFdD41XKVa5QWTfAte/2Ld2FMGp8U6s=;
	b=Perqfo3jchRZwoZaDko5ZQaU8kTCvQC1TLwRhmu7jfPOUIT5oA8vNPFFIiyooDX2d6
	rRwZXTFG4A8E+Bq7ZIorNH5Uu/7jieA7QwsP9yw2siE/qPaJqXLDn6cE/TnBGjSh/xNX
	a6ivgEpsIuf0UctPeYDj7wRqIzpaJrxZ5x2+pLSoFax4qQLeTX7Cu99Jp7lsWgzN+d36
	La7+pR5HskKzExrUqcgld1/1vBpBuiORHZ5qOEDyhcKxsD3uXDLJSg5JEbKywv+/RLcg
	jD9brRogwylzrVEKnb12PvMmcwy8dBN5jusA7rDbQWPf/XoRc9fgjhqOrVo1V9fSMIo0
	70sg==
Received: by 10.14.220.134 with SMTP id o6mr26405263eep.35.1350475125650;
	Wed, 17 Oct 2012 04:58:45 -0700 (PDT)
Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com.
	[86.183.156.141])
	by mx.google.com with ESMTPS id t7sm34644472eel.14.2012.10.17.04.58.42
	(version=SSLv3 cipher=OTHER); Wed, 17 Oct 2012 04:58:44 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Wed, 17 Oct 2012 12:58:36 +0100
From: Keir Fraser 
To: Jan Beulich 
Message-ID: 
Thread-Topic: [PATCH v2 1/3] x86/HPET: obtain proper lock for changing IRQ
	affinity
Thread-Index: Ac2sXrzq5Mr3DhlJQE6q8tACcsuo9g==
In-Reply-To: <507EB69302000078000A1F46@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel 
Subject: Re: [Xen-devel] [PATCH v2 1/3] x86/HPET: obtain proper lock for
 changing IRQ affinity
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/10/2012 12:45, "Jan Beulich"  wrote:

> The IRQ descriptor lock should be held while adjusting the affinity of
> any IRQ; the HPET channel lock isn't sufficient to protect namely
> against races with moving the IRQ to a different CPU.
> 
> Signed-off-by: Jan Beulich 

Acked-by: Keir Fraser 

> ---
> v2: rename new helper function
> 
> --- a/xen/arch/x86/hpet.c
> +++ b/xen/arch/x86/hpet.c
> @@ -436,6 +436,16 @@ static struct hpet_event_channel *hpet_g
>      return ch;
>  }
>  
> +static void set_channel_irq_affinity(const struct hpet_event_channel *ch)
> +{
> +    struct irq_desc *desc = irq_to_desc(ch->irq);
> +
> +    ASSERT(!local_irq_is_enabled());
> +    spin_lock(&desc->lock);
> +    hpet_msi_set_affinity(desc, cpumask_of(ch->cpu));
> +    spin_unlock(&desc->lock);
> +}
> +
>  static void hpet_attach_channel(unsigned int cpu,
>                                  struct hpet_event_channel *ch)
>  {
> @@ -450,7 +460,7 @@ static void hpet_attach_channel(unsigned
>      if ( ch->cpu != cpu )
>          return;
>  
> -    hpet_msi_set_affinity(irq_to_desc(ch->irq), cpumask_of(ch->cpu));
> +    set_channel_irq_affinity(ch);
>  }
>  
>  static void hpet_detach_channel(unsigned int cpu,
> @@ -472,7 +482,7 @@ static void hpet_detach_channel(unsigned
>      }
>  
>      ch->cpu = cpumask_first(ch->cpumask);
> -    hpet_msi_set_affinity(irq_to_desc(ch->irq), cpumask_of(ch->cpu));
> +    set_channel_irq_affinity(ch);
>  }
>  
>  #include 
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 11:59:57 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 11:59:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOSHs-0007q4-9R; Wed, 17 Oct 2012 11:59:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOSHp-0007pn-Q3
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 11:59:46 +0000
Received: from [85.158.139.83:32570] by server-13.bemta-5.messagelabs.com id
	CD/EB-30674-1BD9E705; Wed, 17 Oct 2012 11:59:45 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1350475183!32415959!1
X-Originating-IP: [209.85.212.179]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22001 invoked from network); 17 Oct 2012 11:59:43 -0000
Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com)
	(209.85.212.179)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 11:59:43 -0000
Received: by mail-wi0-f179.google.com with SMTP id hq7so448473wib.14
	for ; Wed, 17 Oct 2012 04:59:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=+sS1eD95CPZGhbL3ZycvD8Xe9jxrCVNue0/HnHS6B/A=;
	b=FjIz0sHcowe+POd+e0GCXNq79MALspJ3sk528OHsPU8KbPOhsEGZT8vGVE4R5yWDww
	wD7Bpr6FaXqAalrxfsdPhU6BtBzzwDdrVngrXbSCnzKLhwg+jQb2/qwRGlnNkRCLP8N8
	BQImuq2mc/QfqFUhb5W+jd4F1G+w0jJzoKkN4PKqTzv6iC60ddB2BqoIOXLL66siKToW
	6HWoDwqRaMQqeqcfHW8nLfjFnn7B+MrbmI46+aj4QZfenWMTam855o7Vecis5+phy8fm
	rzVGDzCjLaEYJicNwOrtSsk1pxn8kCwsq/7b1IcTVFs1A+IWC+KxyUEamlvvMPxQ/Uql
	+vOQ==
Received: by 10.180.19.71 with SMTP id c7mr3733275wie.2.1350475183480;
	Wed, 17 Oct 2012 04:59:43 -0700 (PDT)
Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com.
	[86.183.156.141])
	by mx.google.com with ESMTPS id cl8sm24016328wib.10.2012.10.17.04.59.41
	(version=SSLv3 cipher=OTHER); Wed, 17 Oct 2012 04:59:42 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Wed, 17 Oct 2012 12:59:33 +0100
From: Keir Fraser 
To: Jan Beulich ,
	xen-devel 
Message-ID: 
Thread-Topic: [Xen-devel] [PATCH v2 2/3] x86/HPET: allow use for broadcast
	when interrupt remapping is in effect
Thread-Index: Ac2sXt7kI3Y4TowWd0eFPhw0/ngldw==
In-Reply-To: <507EB6DB02000078000A1F4A@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xiantao.zhang@intel.com
Subject: Re: [Xen-devel] [PATCH v2 2/3] x86/HPET: allow use for broadcast
 when interrupt remapping is in effect
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/10/2012 12:47, "Jan Beulich"  wrote:

> This requires some additions to the VT-d side; AMD IOMMUs use the
> "normal" MSI message format even when interrupt remapping is enabled,
> thus making adjustments here unnecessary.
> 
> Signed-off-by: Jan Beulich 

Acked-by: Keir Fraser 

...for the principle, but needs an Intel ack for the details.

 -- Keir

> ---
> v2: refresh after updating patch 1 of this series (patch 3 is unchanged)
> 
> --- a/xen/arch/x86/acpi/boot.c
> +++ b/xen/arch/x86/acpi/boot.c
> @@ -276,6 +276,7 @@ static int __init acpi_parse_hpet(struct
> }
>  
> hpet_address = hpet_tbl->address.address;
> + hpet_blockid = hpet_tbl->sequence;
> printk(KERN_INFO PREFIX "HPET id: %#x base: %#lx\n",
>       hpet_tbl->id, hpet_address);
>  
> --- a/xen/arch/x86/hpet.c
> +++ b/xen/arch/x86/hpet.c
> @@ -40,7 +40,7 @@ struct hpet_event_channel
>  
>      unsigned int idx;   /* physical channel idx */
>      unsigned int cpu;   /* msi target */
> -    int irq;            /* msi irq */
> +    struct msi_desc msi;/* msi state */
>      unsigned int flags; /* HPET_EVT_x */
>  } __cacheline_aligned;
>  static struct hpet_event_channel *__read_mostly hpet_events;
> @@ -51,6 +51,7 @@ static unsigned int __read_mostly num_hp
>  DEFINE_PER_CPU(struct hpet_event_channel *, cpu_bc_channel);
>  
>  unsigned long __read_mostly hpet_address;
> +u8 __initdata hpet_blockid;
>  
>  /*
>   * force_hpet_broadcast: by default legacy hpet broadcast will be stopped
> @@ -252,6 +253,8 @@ static void hpet_msi_mask(struct irq_des
>  
>  static void hpet_msi_write(struct hpet_event_channel *ch, struct msi_msg
> *msg)
>  {
> +    if ( iommu_intremap )
> +        iommu_update_ire_from_msi(&ch->msi, msg);
>      hpet_write32(msg->data, HPET_Tn_ROUTE(ch->idx));
>      hpet_write32(msg->address_lo, HPET_Tn_ROUTE(ch->idx) + 4);
>  }
> @@ -261,6 +264,8 @@ static void hpet_msi_read(struct hpet_ev
>      msg->data = hpet_read32(HPET_Tn_ROUTE(ch->idx));
>      msg->address_lo = hpet_read32(HPET_Tn_ROUTE(ch->idx) + 4);
>      msg->address_hi = 0;
> +    if ( iommu_intremap )
> +        iommu_read_msi_from_ire(&ch->msi, msg);
>  }
>  
>  static unsigned int hpet_msi_startup(struct irq_desc *desc)
> @@ -292,6 +297,7 @@ static void hpet_msi_set_affinity(struct
>      msg.data |= MSI_DATA_VECTOR(desc->arch.vector);
>      msg.address_lo &= ~MSI_ADDR_DEST_ID_MASK;
>      msg.address_lo |= MSI_ADDR_DEST_ID(dest);
> +    msg.dest32 = dest;
>      hpet_msi_write(desc->action->dev_id, &msg);
>  }
>  
> @@ -316,35 +322,48 @@ static void __hpet_setup_msi_irq(struct
>      hpet_msi_write(desc->action->dev_id, &msg);
>  }
>  
> -static int __init hpet_setup_msi_irq(unsigned int irq, struct
> hpet_event_channel *ch)
> +static int __init hpet_setup_msi_irq(struct hpet_event_channel *ch)
>  {
>      int ret;
> -    irq_desc_t *desc = irq_to_desc(irq);
> +    irq_desc_t *desc = irq_to_desc(ch->msi.irq);
> +
> +    if ( iommu_intremap )
> +    {
> +        ch->msi.hpet_id = hpet_blockid;
> +        ret = iommu_setup_hpet_msi(&ch->msi);
> +        if ( ret )
> +            return ret;
> +    }
>  
>      desc->handler = &hpet_msi_type;
> -    ret = request_irq(irq, hpet_interrupt_handler, 0, "HPET", ch);
> +    ret = request_irq(ch->msi.irq, hpet_interrupt_handler, 0, "HPET", ch);
>      if ( ret < 0 )
> +    {
> +        if ( iommu_intremap )
> +            iommu_update_ire_from_msi(&ch->msi, NULL);
>          return ret;
> +    }
>  
>      __hpet_setup_msi_irq(desc);
>  
>      return 0;
>  }
>  
> -static int __init hpet_assign_irq(unsigned int idx)
> +static int __init hpet_assign_irq(struct hpet_event_channel *ch)
>  {
>      int irq;
>  
>      if ( (irq = create_irq(NUMA_NO_NODE)) < 0 )
>          return irq;
>  
> -    if ( hpet_setup_msi_irq(irq, hpet_events + idx) )
> +    ch->msi.irq = irq;
> +    if ( hpet_setup_msi_irq(ch) )
>      {
>          destroy_irq(irq);
>          return -EINVAL;
>      }
>  
> -    return irq;
> +    return 0;
>  }
>  
>  static void __init hpet_fsb_cap_lookup(void)
> @@ -352,14 +371,6 @@ static void __init hpet_fsb_cap_lookup(v
>      u32 id;
>      unsigned int i, num_chs;
>  
> -    /* TODO. */
> -    if ( iommu_intremap )
> -    {
> -        printk(XENLOG_INFO "HPET's MSI mode hasn't been supported when "
> -            "Interrupt Remapping is enabled.\n");
> -        return;
> -    }
> -
>      id = hpet_read32(HPET_ID);
>  
>      num_chs = ((id & HPET_ID_NUMBER) >> HPET_ID_NUMBER_SHIFT);
> @@ -391,8 +402,8 @@ static void __init hpet_fsb_cap_lookup(v
>          ch->flags = 0;
>          ch->idx = i;
>  
> -        if ( (ch->irq = hpet_assign_irq(num_hpets_used++)) < 0 )
> -            num_hpets_used--;
> +        if ( hpet_assign_irq(ch) == 0 )
> +            num_hpets_used++;
>      }
>  
>      printk(XENLOG_INFO "HPET: %u timers (%u will be used for broadcast)\n",
> @@ -438,7 +449,7 @@ static struct hpet_event_channel *hpet_g
>  
>  static void set_channel_irq_affinity(const struct hpet_event_channel *ch)
>  {
> -    struct irq_desc *desc = irq_to_desc(ch->irq);
> +    struct irq_desc *desc = irq_to_desc(ch->msi.irq);
>  
>      ASSERT(!local_irq_is_enabled());
>      spin_lock(&desc->lock);
> @@ -530,7 +541,7 @@ void __init hpet_broadcast_init(void)
>              hpet_events = xzalloc(struct hpet_event_channel);
>          if ( !hpet_events || !zalloc_cpumask_var(&hpet_events->cpumask) )
>              return;
> -        hpet_events->irq = -1;
> +        hpet_events->msi.irq = -1;
>  
>          /* Start HPET legacy interrupts */
>          cfg |= HPET_CFG_LEGACY;
> @@ -598,8 +609,8 @@ void hpet_broadcast_resume(void)
>  
>      for ( i = 0; i < n; i++ )
>      {
> -        if ( hpet_events[i].irq >= 0 )
> -            __hpet_setup_msi_irq(irq_to_desc(hpet_events[i].irq));
> +        if ( hpet_events[i].msi.irq >= 0 )
> +            __hpet_setup_msi_irq(irq_to_desc(hpet_events[i].msi.irq));
>  
>          /* set HPET Tn as oneshot */
>          cfg = hpet_read32(HPET_Tn_CFG(hpet_events[i].idx));
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -495,6 +495,12 @@ unsigned int iommu_read_apic_from_ire(un
>      return ops->read_apic_from_ire(apic, reg);
>  }
>  
> +int __init iommu_setup_hpet_msi(struct msi_desc *msi)
> +{
> +    const struct iommu_ops *ops = iommu_get_ops();
> +    return ops->setup_hpet_msi ? ops->setup_hpet_msi(msi) : 0;
> +}
> +
>  void iommu_resume()
>  {
>      const struct iommu_ops *ops = iommu_get_ops();
> --- a/xen/drivers/passthrough/vtd/dmar.c
> +++ b/xen/drivers/passthrough/vtd/dmar.c
> @@ -147,6 +147,34 @@ struct iommu * ioapic_to_iommu(unsigned
>      return NULL;
>  }
>  
> +static bool_t acpi_hpet_device_match(
> +    struct list_head *list, unsigned int hpet_id)
> +{
> +    struct acpi_hpet_unit *hpet;
> +
> +    list_for_each_entry( hpet, list, list )
> +        if (hpet->id == hpet_id)
> +            return 1;
> +    return 0;
> +}
> +
> +struct acpi_drhd_unit *hpet_to_drhd(unsigned int hpet_id)
> +{
> +    struct acpi_drhd_unit *drhd;
> +
> +    list_for_each_entry( drhd, &acpi_drhd_units, list )
> +        if ( acpi_hpet_device_match(&drhd->hpet_list, hpet_id) )
> +            return drhd;
> +    return NULL;
> +}
> +
> +struct iommu *hpet_to_iommu(unsigned int hpet_id)
> +{
> +    struct acpi_drhd_unit *drhd = hpet_to_drhd(hpet_id);
> +
> +    return drhd ? drhd->iommu : NULL;
> +}
> +
>  static int __init acpi_register_atsr_unit(struct acpi_atsr_unit *atsr)
>  {
>      /*
> @@ -330,6 +358,22 @@ static int __init acpi_parse_dev_scope(
>              if ( iommu_verbose )
>                  dprintk(VTDPREFIX, " MSI HPET: %04x:%02x:%02x.%u\n",
>                          seg, bus, path->dev, path->fn);
> +
> +            if ( type == DMAR_TYPE )
> +            {
> +                struct acpi_drhd_unit *drhd = acpi_entry;
> +                struct acpi_hpet_unit *acpi_hpet_unit;
> +
> +                acpi_hpet_unit = xmalloc(struct acpi_hpet_unit);
> +                if ( !acpi_hpet_unit )
> +                    return -ENOMEM;
> +                acpi_hpet_unit->id = acpi_scope->enumeration_id;
> +                acpi_hpet_unit->bus = bus;
> +                acpi_hpet_unit->dev = path->dev;
> +                acpi_hpet_unit->func = path->fn;
> +                list_add(&acpi_hpet_unit->list, &drhd->hpet_list);
> +            }
> +
>              break;
>  
>          case ACPI_DMAR_SCOPE_TYPE_ENDPOINT:
> @@ -407,6 +451,7 @@ acpi_parse_one_drhd(struct acpi_dmar_hea
>      dmaru->segment = drhd->segment;
>      dmaru->include_all = drhd->flags & ACPI_DMAR_INCLUDE_ALL;
>      INIT_LIST_HEAD(&dmaru->ioapic_list);
> +    INIT_LIST_HEAD(&dmaru->hpet_list);
>      if ( iommu_verbose )
>          dprintk(VTDPREFIX, "  dmaru->address = %"PRIx64"\n",
>                  dmaru->address);
> --- a/xen/drivers/passthrough/vtd/dmar.h
> +++ b/xen/drivers/passthrough/vtd/dmar.h
> @@ -39,6 +39,19 @@ struct acpi_ioapic_unit {
>      }ioapic;
>  };
>  
> +struct acpi_hpet_unit {
> +    struct list_head list;
> +    unsigned int id;
> +    union {
> +        u16 bdf;
> +        struct {
> +            u16 func: 3,
> +                dev:  5,
> +                bus:  8;
> +        };
> +    };
> +};
> +
>  struct dmar_scope {
>      DECLARE_BITMAP(buses, 256);         /* buses owned by this unit */
>      u16    *devices;                    /* devices owned by this unit */
> @@ -53,6 +66,7 @@ struct acpi_drhd_unit {
>      u8     include_all:1;
>      struct iommu *iommu;
>      struct list_head ioapic_list;
> +    struct list_head hpet_list;
>  };
>  
>  struct acpi_rmrr_unit {
> --- a/xen/drivers/passthrough/vtd/extern.h
> +++ b/xen/drivers/passthrough/vtd/extern.h
> @@ -54,7 +54,9 @@ int iommu_flush_iec_index(struct iommu *
>  void clear_fault_bits(struct iommu *iommu);
>  
>  struct iommu * ioapic_to_iommu(unsigned int apic_id);
> +struct iommu * hpet_to_iommu(unsigned int hpet_id);
>  struct acpi_drhd_unit * ioapic_to_drhd(unsigned int apic_id);
> +struct acpi_drhd_unit * hpet_to_drhd(unsigned int hpet_id);
>  struct acpi_drhd_unit * iommu_to_drhd(struct iommu *iommu);
>  struct acpi_rhsa_unit * drhd_to_rhsa(struct acpi_drhd_unit *drhd);
>  
> @@ -90,6 +92,8 @@ struct msi_msg;
>  void msi_msg_read_remap_rte(struct msi_desc *, struct msi_msg *);
>  void msi_msg_write_remap_rte(struct msi_desc *, struct msi_msg *);
>  
> +int intel_setup_hpet_msi(struct msi_desc *);
> +
>  int is_igd_vt_enabled_quirk(void);
>  void platform_quirks_init(void);
>  void vtd_ops_preamble_quirk(struct iommu* iommu);
> --- a/xen/drivers/passthrough/vtd/intremap.c
> +++ b/xen/drivers/passthrough/vtd/intremap.c
> @@ -107,6 +107,19 @@ static u16 apicid_to_bdf(int apic_id)
>      return 0;
>  }
>  
> +static u16 hpetid_to_bdf(unsigned int hpet_id)
> +{
> +    struct acpi_drhd_unit *drhd = hpet_to_drhd(hpet_id);
> +    struct acpi_hpet_unit *acpi_hpet_unit;
> +
> +    list_for_each_entry ( acpi_hpet_unit, &drhd->hpet_list, list )
> +        if ( acpi_hpet_unit->id == hpet_id )
> +            return acpi_hpet_unit->bdf;
> +
> +    dprintk(XENLOG_ERR VTDPREFIX, "Didn't find the bdf for HPET %u!\n",
> hpet_id);
> +    return 0;
> +}
> +
>  static void set_ire_sid(struct iremap_entry *ire,
>                          unsigned int svt, unsigned int sq, unsigned int sid)
>  {
> @@ -121,6 +134,16 @@ static void set_ioapic_source_id(int api
>                  apicid_to_bdf(apic_id));
>  }
>  
> +static void set_hpet_source_id(unsigned int id, struct iremap_entry *ire)
> +{
> +    /*
> +     * Should really use SQ_ALL_16. Some platforms are broken.
> +     * While we figure out the right quirks for these broken platforms, use
> +     * SQ_13_IGNORE_3 for now.
> +     */
> +    set_ire_sid(ire, SVT_VERIFY_SID_SQ, SQ_13_IGNORE_3, hpetid_to_bdf(id));
> +}
> +
>  int iommu_supports_eim(void)
>  {
>      struct acpi_drhd_unit *drhd;
> @@ -592,7 +615,10 @@ static int msi_msg_to_remap_entry(
>          new_ire.lo.dst = ((msg->address_lo >> MSI_ADDR_DEST_ID_SHIFT)
>                            & 0xff) << 8;
>  
> -    set_msi_source_id(pdev, &new_ire);
> +    if ( pdev )
> +        set_msi_source_id(pdev, &new_ire);
> +    else
> +        set_hpet_source_id(msi_desc->hpet_id, &new_ire);
>      new_ire.hi.res_1 = 0;
>      new_ire.lo.p = 1;    /* finally, set present bit */
>  
> @@ -624,7 +650,9 @@ void msi_msg_read_remap_rte(
>      struct iommu *iommu = NULL;
>      struct ir_ctrl *ir_ctrl;
>  
> -    if ( (drhd = acpi_find_matched_drhd_unit(pdev)) == NULL )
> +    drhd = pdev ? acpi_find_matched_drhd_unit(pdev)
> +                : hpet_to_drhd(msi_desc->hpet_id);
> +    if ( !drhd )
>          return;
>      iommu = drhd->iommu;
>  
> @@ -643,7 +671,9 @@ void msi_msg_write_remap_rte(
>      struct iommu *iommu = NULL;
>      struct ir_ctrl *ir_ctrl;
>  
> -    if ( (drhd = acpi_find_matched_drhd_unit(pdev)) == NULL )
> +    drhd = pdev ? acpi_find_matched_drhd_unit(pdev)
> +                : hpet_to_drhd(msi_desc->hpet_id);
> +    if ( !drhd )
>          return;
>      iommu = drhd->iommu;
>  
> @@ -654,6 +684,32 @@ void msi_msg_write_remap_rte(
>      msi_msg_to_remap_entry(iommu, pdev, msi_desc, msg);
>  }
>  
> +int __init intel_setup_hpet_msi(struct msi_desc *msi_desc)
> +{
> +    struct iommu *iommu = hpet_to_iommu(msi_desc->hpet_id);
> +    struct ir_ctrl *ir_ctrl = iommu_ir_ctrl(iommu);
> +    unsigned long flags;
> +    int rc = 0;
> +
> +    if ( !ir_ctrl || !ir_ctrl->iremap_maddr )
> +        return 0;
> +
> +    spin_lock_irqsave(&ir_ctrl->iremap_lock, flags);
> +    msi_desc->remap_index = alloc_remap_entry(iommu);
> +    if ( msi_desc->remap_index >= IREMAP_ENTRY_NR )
> +    {
> +        dprintk(XENLOG_ERR VTDPREFIX,
> +                "%s: intremap index (%d) is larger than"
> +                " the maximum index (%d)!\n",
> +                __func__, msi_desc->remap_index, IREMAP_ENTRY_NR - 1);
> +        msi_desc->remap_index = -1;
> +        rc = -ENXIO;
> +    }
> +    spin_unlock_irqrestore(&ir_ctrl->iremap_lock, flags);
> +
> +    return rc;
> +}
> +
>  int enable_intremap(struct iommu *iommu, int eim)
>  {
>      struct acpi_drhd_unit *drhd;
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -2396,6 +2396,7 @@ const struct iommu_ops intel_iommu_ops =
>      .update_ire_from_msi = msi_msg_write_remap_rte,
>      .read_apic_from_ire = io_apic_read_remap_rte,
>      .read_msi_from_ire = msi_msg_read_remap_rte,
> +    .setup_hpet_msi = intel_setup_hpet_msi,
>      .suspend = vtd_suspend,
>      .resume = vtd_resume,
>      .share_p2m = iommu_set_pgd,
> --- a/xen/include/asm-x86/hpet.h
> +++ b/xen/include/asm-x86/hpet.h
> @@ -53,6 +53,7 @@
>      (*(volatile u32 *)(fix_to_virt(FIX_HPET_BASE) + (x)) = (y))
>  
>  extern unsigned long hpet_address;
> +extern u8 hpet_blockid;
>  
>  /*
>   * Detect and initialise HPET hardware: return counter update frequency.
> --- a/xen/include/asm-x86/msi.h
> +++ b/xen/include/asm-x86/msi.h
> @@ -97,7 +97,10 @@ struct msi_desc {
>  
> struct list_head list;
>  
> - void __iomem *mask_base;        /* va for the entry in mask table */
> + union {
> +  void __iomem *mask_base;/* va for the entry in mask table */
> +  unsigned int hpet_id;   /* HPET (dev is NULL)             */
> + };
> struct pci_dev *dev;
> int irq;
>  
> --- a/xen/include/xen/iommu.h
> +++ b/xen/include/xen/iommu.h
> @@ -109,6 +109,7 @@ struct iommu_ops {
>      void (*update_ire_from_msi)(struct msi_desc *msi_desc, struct msi_msg
> *msg);
>      void (*read_msi_from_ire)(struct msi_desc *msi_desc, struct msi_msg
> *msg);
>      unsigned int (*read_apic_from_ire)(unsigned int apic, unsigned int reg);
> +    int (*setup_hpet_msi)(struct msi_desc *);
>      void (*suspend)(void);
>      void (*resume)(void);
>      void (*share_p2m)(struct domain *d);
> @@ -122,6 +123,7 @@ void iommu_update_ire_from_apic(unsigned
>  void iommu_update_ire_from_msi(struct msi_desc *msi_desc, struct msi_msg
> *msg);
>  void iommu_read_msi_from_ire(struct msi_desc *msi_desc, struct msi_msg *msg);
>  unsigned int iommu_read_apic_from_ire(unsigned int apic, unsigned int reg);
> +int iommu_setup_hpet_msi(struct msi_desc *);
>  
>  void iommu_suspend(void);
>  void iommu_resume(void);
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 11:59:57 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 11:59:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOSHs-0007q4-9R; Wed, 17 Oct 2012 11:59:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOSHp-0007pn-Q3
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 11:59:46 +0000
Received: from [85.158.139.83:32570] by server-13.bemta-5.messagelabs.com id
	CD/EB-30674-1BD9E705; Wed, 17 Oct 2012 11:59:45 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1350475183!32415959!1
X-Originating-IP: [209.85.212.179]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22001 invoked from network); 17 Oct 2012 11:59:43 -0000
Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com)
	(209.85.212.179)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 11:59:43 -0000
Received: by mail-wi0-f179.google.com with SMTP id hq7so448473wib.14
	for ; Wed, 17 Oct 2012 04:59:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=+sS1eD95CPZGhbL3ZycvD8Xe9jxrCVNue0/HnHS6B/A=;
	b=FjIz0sHcowe+POd+e0GCXNq79MALspJ3sk528OHsPU8KbPOhsEGZT8vGVE4R5yWDww
	wD7Bpr6FaXqAalrxfsdPhU6BtBzzwDdrVngrXbSCnzKLhwg+jQb2/qwRGlnNkRCLP8N8
	BQImuq2mc/QfqFUhb5W+jd4F1G+w0jJzoKkN4PKqTzv6iC60ddB2BqoIOXLL66siKToW
	6HWoDwqRaMQqeqcfHW8nLfjFnn7B+MrbmI46+aj4QZfenWMTam855o7Vecis5+phy8fm
	rzVGDzCjLaEYJicNwOrtSsk1pxn8kCwsq/7b1IcTVFs1A+IWC+KxyUEamlvvMPxQ/Uql
	+vOQ==
Received: by 10.180.19.71 with SMTP id c7mr3733275wie.2.1350475183480;
	Wed, 17 Oct 2012 04:59:43 -0700 (PDT)
Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com.
	[86.183.156.141])
	by mx.google.com with ESMTPS id cl8sm24016328wib.10.2012.10.17.04.59.41
	(version=SSLv3 cipher=OTHER); Wed, 17 Oct 2012 04:59:42 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Wed, 17 Oct 2012 12:59:33 +0100
From: Keir Fraser 
To: Jan Beulich ,
	xen-devel 
Message-ID: 
Thread-Topic: [Xen-devel] [PATCH v2 2/3] x86/HPET: allow use for broadcast
	when interrupt remapping is in effect
Thread-Index: Ac2sXt7kI3Y4TowWd0eFPhw0/ngldw==
In-Reply-To: <507EB6DB02000078000A1F4A@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xiantao.zhang@intel.com
Subject: Re: [Xen-devel] [PATCH v2 2/3] x86/HPET: allow use for broadcast
 when interrupt remapping is in effect
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/10/2012 12:47, "Jan Beulich"  wrote:

> This requires some additions to the VT-d side; AMD IOMMUs use the
> "normal" MSI message format even when interrupt remapping is enabled,
> thus making adjustments here unnecessary.
> 
> Signed-off-by: Jan Beulich 

Acked-by: Keir Fraser 

...for the principle, but needs an Intel ack for the details.

 -- Keir

> ---
> v2: refresh after updating patch 1 of this series (patch 3 is unchanged)
> 
> --- a/xen/arch/x86/acpi/boot.c
> +++ b/xen/arch/x86/acpi/boot.c
> @@ -276,6 +276,7 @@ static int __init acpi_parse_hpet(struct
> }
>  
> hpet_address = hpet_tbl->address.address;
> + hpet_blockid = hpet_tbl->sequence;
> printk(KERN_INFO PREFIX "HPET id: %#x base: %#lx\n",
>       hpet_tbl->id, hpet_address);
>  
> --- a/xen/arch/x86/hpet.c
> +++ b/xen/arch/x86/hpet.c
> @@ -40,7 +40,7 @@ struct hpet_event_channel
>  
>      unsigned int idx;   /* physical channel idx */
>      unsigned int cpu;   /* msi target */
> -    int irq;            /* msi irq */
> +    struct msi_desc msi;/* msi state */
>      unsigned int flags; /* HPET_EVT_x */
>  } __cacheline_aligned;
>  static struct hpet_event_channel *__read_mostly hpet_events;
> @@ -51,6 +51,7 @@ static unsigned int __read_mostly num_hp
>  DEFINE_PER_CPU(struct hpet_event_channel *, cpu_bc_channel);
>  
>  unsigned long __read_mostly hpet_address;
> +u8 __initdata hpet_blockid;
>  
>  /*
>   * force_hpet_broadcast: by default legacy hpet broadcast will be stopped
> @@ -252,6 +253,8 @@ static void hpet_msi_mask(struct irq_des
>  
>  static void hpet_msi_write(struct hpet_event_channel *ch, struct msi_msg
> *msg)
>  {
> +    if ( iommu_intremap )
> +        iommu_update_ire_from_msi(&ch->msi, msg);
>      hpet_write32(msg->data, HPET_Tn_ROUTE(ch->idx));
>      hpet_write32(msg->address_lo, HPET_Tn_ROUTE(ch->idx) + 4);
>  }
> @@ -261,6 +264,8 @@ static void hpet_msi_read(struct hpet_ev
>      msg->data = hpet_read32(HPET_Tn_ROUTE(ch->idx));
>      msg->address_lo = hpet_read32(HPET_Tn_ROUTE(ch->idx) + 4);
>      msg->address_hi = 0;
> +    if ( iommu_intremap )
> +        iommu_read_msi_from_ire(&ch->msi, msg);
>  }
>  
>  static unsigned int hpet_msi_startup(struct irq_desc *desc)
> @@ -292,6 +297,7 @@ static void hpet_msi_set_affinity(struct
>      msg.data |= MSI_DATA_VECTOR(desc->arch.vector);
>      msg.address_lo &= ~MSI_ADDR_DEST_ID_MASK;
>      msg.address_lo |= MSI_ADDR_DEST_ID(dest);
> +    msg.dest32 = dest;
>      hpet_msi_write(desc->action->dev_id, &msg);
>  }
>  
> @@ -316,35 +322,48 @@ static void __hpet_setup_msi_irq(struct
>      hpet_msi_write(desc->action->dev_id, &msg);
>  }
>  
> -static int __init hpet_setup_msi_irq(unsigned int irq, struct
> hpet_event_channel *ch)
> +static int __init hpet_setup_msi_irq(struct hpet_event_channel *ch)
>  {
>      int ret;
> -    irq_desc_t *desc = irq_to_desc(irq);
> +    irq_desc_t *desc = irq_to_desc(ch->msi.irq);
> +
> +    if ( iommu_intremap )
> +    {
> +        ch->msi.hpet_id = hpet_blockid;
> +        ret = iommu_setup_hpet_msi(&ch->msi);
> +        if ( ret )
> +            return ret;
> +    }
>  
>      desc->handler = &hpet_msi_type;
> -    ret = request_irq(irq, hpet_interrupt_handler, 0, "HPET", ch);
> +    ret = request_irq(ch->msi.irq, hpet_interrupt_handler, 0, "HPET", ch);
>      if ( ret < 0 )
> +    {
> +        if ( iommu_intremap )
> +            iommu_update_ire_from_msi(&ch->msi, NULL);
>          return ret;
> +    }
>  
>      __hpet_setup_msi_irq(desc);
>  
>      return 0;
>  }
>  
> -static int __init hpet_assign_irq(unsigned int idx)
> +static int __init hpet_assign_irq(struct hpet_event_channel *ch)
>  {
>      int irq;
>  
>      if ( (irq = create_irq(NUMA_NO_NODE)) < 0 )
>          return irq;
>  
> -    if ( hpet_setup_msi_irq(irq, hpet_events + idx) )
> +    ch->msi.irq = irq;
> +    if ( hpet_setup_msi_irq(ch) )
>      {
>          destroy_irq(irq);
>          return -EINVAL;
>      }
>  
> -    return irq;
> +    return 0;
>  }
>  
>  static void __init hpet_fsb_cap_lookup(void)
> @@ -352,14 +371,6 @@ static void __init hpet_fsb_cap_lookup(v
>      u32 id;
>      unsigned int i, num_chs;
>  
> -    /* TODO. */
> -    if ( iommu_intremap )
> -    {
> -        printk(XENLOG_INFO "HPET's MSI mode hasn't been supported when "
> -            "Interrupt Remapping is enabled.\n");
> -        return;
> -    }
> -
>      id = hpet_read32(HPET_ID);
>  
>      num_chs = ((id & HPET_ID_NUMBER) >> HPET_ID_NUMBER_SHIFT);
> @@ -391,8 +402,8 @@ static void __init hpet_fsb_cap_lookup(v
>          ch->flags = 0;
>          ch->idx = i;
>  
> -        if ( (ch->irq = hpet_assign_irq(num_hpets_used++)) < 0 )
> -            num_hpets_used--;
> +        if ( hpet_assign_irq(ch) == 0 )
> +            num_hpets_used++;
>      }
>  
>      printk(XENLOG_INFO "HPET: %u timers (%u will be used for broadcast)\n",
> @@ -438,7 +449,7 @@ static struct hpet_event_channel *hpet_g
>  
>  static void set_channel_irq_affinity(const struct hpet_event_channel *ch)
>  {
> -    struct irq_desc *desc = irq_to_desc(ch->irq);
> +    struct irq_desc *desc = irq_to_desc(ch->msi.irq);
>  
>      ASSERT(!local_irq_is_enabled());
>      spin_lock(&desc->lock);
> @@ -530,7 +541,7 @@ void __init hpet_broadcast_init(void)
>              hpet_events = xzalloc(struct hpet_event_channel);
>          if ( !hpet_events || !zalloc_cpumask_var(&hpet_events->cpumask) )
>              return;
> -        hpet_events->irq = -1;
> +        hpet_events->msi.irq = -1;
>  
>          /* Start HPET legacy interrupts */
>          cfg |= HPET_CFG_LEGACY;
> @@ -598,8 +609,8 @@ void hpet_broadcast_resume(void)
>  
>      for ( i = 0; i < n; i++ )
>      {
> -        if ( hpet_events[i].irq >= 0 )
> -            __hpet_setup_msi_irq(irq_to_desc(hpet_events[i].irq));
> +        if ( hpet_events[i].msi.irq >= 0 )
> +            __hpet_setup_msi_irq(irq_to_desc(hpet_events[i].msi.irq));
>  
>          /* set HPET Tn as oneshot */
>          cfg = hpet_read32(HPET_Tn_CFG(hpet_events[i].idx));
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -495,6 +495,12 @@ unsigned int iommu_read_apic_from_ire(un
>      return ops->read_apic_from_ire(apic, reg);
>  }
>  
> +int __init iommu_setup_hpet_msi(struct msi_desc *msi)
> +{
> +    const struct iommu_ops *ops = iommu_get_ops();
> +    return ops->setup_hpet_msi ? ops->setup_hpet_msi(msi) : 0;
> +}
> +
>  void iommu_resume()
>  {
>      const struct iommu_ops *ops = iommu_get_ops();
> --- a/xen/drivers/passthrough/vtd/dmar.c
> +++ b/xen/drivers/passthrough/vtd/dmar.c
> @@ -147,6 +147,34 @@ struct iommu * ioapic_to_iommu(unsigned
>      return NULL;
>  }
>  
> +static bool_t acpi_hpet_device_match(
> +    struct list_head *list, unsigned int hpet_id)
> +{
> +    struct acpi_hpet_unit *hpet;
> +
> +    list_for_each_entry( hpet, list, list )
> +        if (hpet->id == hpet_id)
> +            return 1;
> +    return 0;
> +}
> +
> +struct acpi_drhd_unit *hpet_to_drhd(unsigned int hpet_id)
> +{
> +    struct acpi_drhd_unit *drhd;
> +
> +    list_for_each_entry( drhd, &acpi_drhd_units, list )
> +        if ( acpi_hpet_device_match(&drhd->hpet_list, hpet_id) )
> +            return drhd;
> +    return NULL;
> +}
> +
> +struct iommu *hpet_to_iommu(unsigned int hpet_id)
> +{
> +    struct acpi_drhd_unit *drhd = hpet_to_drhd(hpet_id);
> +
> +    return drhd ? drhd->iommu : NULL;
> +}
> +
>  static int __init acpi_register_atsr_unit(struct acpi_atsr_unit *atsr)
>  {
>      /*
> @@ -330,6 +358,22 @@ static int __init acpi_parse_dev_scope(
>              if ( iommu_verbose )
>                  dprintk(VTDPREFIX, " MSI HPET: %04x:%02x:%02x.%u\n",
>                          seg, bus, path->dev, path->fn);
> +
> +            if ( type == DMAR_TYPE )
> +            {
> +                struct acpi_drhd_unit *drhd = acpi_entry;
> +                struct acpi_hpet_unit *acpi_hpet_unit;
> +
> +                acpi_hpet_unit = xmalloc(struct acpi_hpet_unit);
> +                if ( !acpi_hpet_unit )
> +                    return -ENOMEM;
> +                acpi_hpet_unit->id = acpi_scope->enumeration_id;
> +                acpi_hpet_unit->bus = bus;
> +                acpi_hpet_unit->dev = path->dev;
> +                acpi_hpet_unit->func = path->fn;
> +                list_add(&acpi_hpet_unit->list, &drhd->hpet_list);
> +            }
> +
>              break;
>  
>          case ACPI_DMAR_SCOPE_TYPE_ENDPOINT:
> @@ -407,6 +451,7 @@ acpi_parse_one_drhd(struct acpi_dmar_hea
>      dmaru->segment = drhd->segment;
>      dmaru->include_all = drhd->flags & ACPI_DMAR_INCLUDE_ALL;
>      INIT_LIST_HEAD(&dmaru->ioapic_list);
> +    INIT_LIST_HEAD(&dmaru->hpet_list);
>      if ( iommu_verbose )
>          dprintk(VTDPREFIX, "  dmaru->address = %"PRIx64"\n",
>                  dmaru->address);
> --- a/xen/drivers/passthrough/vtd/dmar.h
> +++ b/xen/drivers/passthrough/vtd/dmar.h
> @@ -39,6 +39,19 @@ struct acpi_ioapic_unit {
>      }ioapic;
>  };
>  
> +struct acpi_hpet_unit {
> +    struct list_head list;
> +    unsigned int id;
> +    union {
> +        u16 bdf;
> +        struct {
> +            u16 func: 3,
> +                dev:  5,
> +                bus:  8;
> +        };
> +    };
> +};
> +
>  struct dmar_scope {
>      DECLARE_BITMAP(buses, 256);         /* buses owned by this unit */
>      u16    *devices;                    /* devices owned by this unit */
> @@ -53,6 +66,7 @@ struct acpi_drhd_unit {
>      u8     include_all:1;
>      struct iommu *iommu;
>      struct list_head ioapic_list;
> +    struct list_head hpet_list;
>  };
>  
>  struct acpi_rmrr_unit {
> --- a/xen/drivers/passthrough/vtd/extern.h
> +++ b/xen/drivers/passthrough/vtd/extern.h
> @@ -54,7 +54,9 @@ int iommu_flush_iec_index(struct iommu *
>  void clear_fault_bits(struct iommu *iommu);
>  
>  struct iommu * ioapic_to_iommu(unsigned int apic_id);
> +struct iommu * hpet_to_iommu(unsigned int hpet_id);
>  struct acpi_drhd_unit * ioapic_to_drhd(unsigned int apic_id);
> +struct acpi_drhd_unit * hpet_to_drhd(unsigned int hpet_id);
>  struct acpi_drhd_unit * iommu_to_drhd(struct iommu *iommu);
>  struct acpi_rhsa_unit * drhd_to_rhsa(struct acpi_drhd_unit *drhd);
>  
> @@ -90,6 +92,8 @@ struct msi_msg;
>  void msi_msg_read_remap_rte(struct msi_desc *, struct msi_msg *);
>  void msi_msg_write_remap_rte(struct msi_desc *, struct msi_msg *);
>  
> +int intel_setup_hpet_msi(struct msi_desc *);
> +
>  int is_igd_vt_enabled_quirk(void);
>  void platform_quirks_init(void);
>  void vtd_ops_preamble_quirk(struct iommu* iommu);
> --- a/xen/drivers/passthrough/vtd/intremap.c
> +++ b/xen/drivers/passthrough/vtd/intremap.c
> @@ -107,6 +107,19 @@ static u16 apicid_to_bdf(int apic_id)
>      return 0;
>  }
>  
> +static u16 hpetid_to_bdf(unsigned int hpet_id)
> +{
> +    struct acpi_drhd_unit *drhd = hpet_to_drhd(hpet_id);
> +    struct acpi_hpet_unit *acpi_hpet_unit;
> +
> +    list_for_each_entry ( acpi_hpet_unit, &drhd->hpet_list, list )
> +        if ( acpi_hpet_unit->id == hpet_id )
> +            return acpi_hpet_unit->bdf;
> +
> +    dprintk(XENLOG_ERR VTDPREFIX, "Didn't find the bdf for HPET %u!\n",
> hpet_id);
> +    return 0;
> +}
> +
>  static void set_ire_sid(struct iremap_entry *ire,
>                          unsigned int svt, unsigned int sq, unsigned int sid)
>  {
> @@ -121,6 +134,16 @@ static void set_ioapic_source_id(int api
>                  apicid_to_bdf(apic_id));
>  }
>  
> +static void set_hpet_source_id(unsigned int id, struct iremap_entry *ire)
> +{
> +    /*
> +     * Should really use SQ_ALL_16. Some platforms are broken.
> +     * While we figure out the right quirks for these broken platforms, use
> +     * SQ_13_IGNORE_3 for now.
> +     */
> +    set_ire_sid(ire, SVT_VERIFY_SID_SQ, SQ_13_IGNORE_3, hpetid_to_bdf(id));
> +}
> +
>  int iommu_supports_eim(void)
>  {
>      struct acpi_drhd_unit *drhd;
> @@ -592,7 +615,10 @@ static int msi_msg_to_remap_entry(
>          new_ire.lo.dst = ((msg->address_lo >> MSI_ADDR_DEST_ID_SHIFT)
>                            & 0xff) << 8;
>  
> -    set_msi_source_id(pdev, &new_ire);
> +    if ( pdev )
> +        set_msi_source_id(pdev, &new_ire);
> +    else
> +        set_hpet_source_id(msi_desc->hpet_id, &new_ire);
>      new_ire.hi.res_1 = 0;
>      new_ire.lo.p = 1;    /* finally, set present bit */
>  
> @@ -624,7 +650,9 @@ void msi_msg_read_remap_rte(
>      struct iommu *iommu = NULL;
>      struct ir_ctrl *ir_ctrl;
>  
> -    if ( (drhd = acpi_find_matched_drhd_unit(pdev)) == NULL )
> +    drhd = pdev ? acpi_find_matched_drhd_unit(pdev)
> +                : hpet_to_drhd(msi_desc->hpet_id);
> +    if ( !drhd )
>          return;
>      iommu = drhd->iommu;
>  
> @@ -643,7 +671,9 @@ void msi_msg_write_remap_rte(
>      struct iommu *iommu = NULL;
>      struct ir_ctrl *ir_ctrl;
>  
> -    if ( (drhd = acpi_find_matched_drhd_unit(pdev)) == NULL )
> +    drhd = pdev ? acpi_find_matched_drhd_unit(pdev)
> +                : hpet_to_drhd(msi_desc->hpet_id);
> +    if ( !drhd )
>          return;
>      iommu = drhd->iommu;
>  
> @@ -654,6 +684,32 @@ void msi_msg_write_remap_rte(
>      msi_msg_to_remap_entry(iommu, pdev, msi_desc, msg);
>  }
>  
> +int __init intel_setup_hpet_msi(struct msi_desc *msi_desc)
> +{
> +    struct iommu *iommu = hpet_to_iommu(msi_desc->hpet_id);
> +    struct ir_ctrl *ir_ctrl = iommu_ir_ctrl(iommu);
> +    unsigned long flags;
> +    int rc = 0;
> +
> +    if ( !ir_ctrl || !ir_ctrl->iremap_maddr )
> +        return 0;
> +
> +    spin_lock_irqsave(&ir_ctrl->iremap_lock, flags);
> +    msi_desc->remap_index = alloc_remap_entry(iommu);
> +    if ( msi_desc->remap_index >= IREMAP_ENTRY_NR )
> +    {
> +        dprintk(XENLOG_ERR VTDPREFIX,
> +                "%s: intremap index (%d) is larger than"
> +                " the maximum index (%d)!\n",
> +                __func__, msi_desc->remap_index, IREMAP_ENTRY_NR - 1);
> +        msi_desc->remap_index = -1;
> +        rc = -ENXIO;
> +    }
> +    spin_unlock_irqrestore(&ir_ctrl->iremap_lock, flags);
> +
> +    return rc;
> +}
> +
>  int enable_intremap(struct iommu *iommu, int eim)
>  {
>      struct acpi_drhd_unit *drhd;
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -2396,6 +2396,7 @@ const struct iommu_ops intel_iommu_ops =
>      .update_ire_from_msi = msi_msg_write_remap_rte,
>      .read_apic_from_ire = io_apic_read_remap_rte,
>      .read_msi_from_ire = msi_msg_read_remap_rte,
> +    .setup_hpet_msi = intel_setup_hpet_msi,
>      .suspend = vtd_suspend,
>      .resume = vtd_resume,
>      .share_p2m = iommu_set_pgd,
> --- a/xen/include/asm-x86/hpet.h
> +++ b/xen/include/asm-x86/hpet.h
> @@ -53,6 +53,7 @@
>      (*(volatile u32 *)(fix_to_virt(FIX_HPET_BASE) + (x)) = (y))
>  
>  extern unsigned long hpet_address;
> +extern u8 hpet_blockid;
>  
>  /*
>   * Detect and initialise HPET hardware: return counter update frequency.
> --- a/xen/include/asm-x86/msi.h
> +++ b/xen/include/asm-x86/msi.h
> @@ -97,7 +97,10 @@ struct msi_desc {
>  
> struct list_head list;
>  
> - void __iomem *mask_base;        /* va for the entry in mask table */
> + union {
> +  void __iomem *mask_base;/* va for the entry in mask table */
> +  unsigned int hpet_id;   /* HPET (dev is NULL)             */
> + };
> struct pci_dev *dev;
> int irq;
>  
> --- a/xen/include/xen/iommu.h
> +++ b/xen/include/xen/iommu.h
> @@ -109,6 +109,7 @@ struct iommu_ops {
>      void (*update_ire_from_msi)(struct msi_desc *msi_desc, struct msi_msg
> *msg);
>      void (*read_msi_from_ire)(struct msi_desc *msi_desc, struct msi_msg
> *msg);
>      unsigned int (*read_apic_from_ire)(unsigned int apic, unsigned int reg);
> +    int (*setup_hpet_msi)(struct msi_desc *);
>      void (*suspend)(void);
>      void (*resume)(void);
>      void (*share_p2m)(struct domain *d);
> @@ -122,6 +123,7 @@ void iommu_update_ire_from_apic(unsigned
>  void iommu_update_ire_from_msi(struct msi_desc *msi_desc, struct msi_msg
> *msg);
>  void iommu_read_msi_from_ire(struct msi_desc *msi_desc, struct msi_msg *msg);
>  unsigned int iommu_read_apic_from_ire(unsigned int apic, unsigned int reg);
> +int iommu_setup_hpet_msi(struct msi_desc *);
>  
>  void iommu_suspend(void);
>  void iommu_resume(void);
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 12:08:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 12:08:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOSPg-0008TG-1S; Wed, 17 Oct 2012 12:07:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOSPe-0008Sz-7S
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 12:07:50 +0000
Received: from [85.158.143.35:49539] by server-1.bemta-4.messagelabs.com id
	38/36-19134-59F9E705; Wed, 17 Oct 2012 12:07:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1350475668!11843470!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1866 invoked from network); 17 Oct 2012 12:07:48 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-21.messagelabs.com with SMTP;
	17 Oct 2012 12:07:48 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 17 Oct 2012 13:07:48 +0100
Message-Id: <507EBBB302000078000A1FAC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 17 Oct 2012 13:07:47 +0100
From: "Jan Beulich" 
To: "David Vrabel" 
References: <1350474150-3990-1-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1350474150-3990-1-git-send-email-david.vrabel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Frediano Ziglio ,
	Konrad Rzeszutek Wilk ,
	stable@kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen/x86: don't corrupt %eip when returning
 from a signal handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 17.10.12 at 13:42, David Vrabel  wrote:
> From: David Vrabel 
> 
> In 32 bit guests, if a userspace process has %eax == -ERESTARTSYS
> (-512) or -ERESTARTNOINTR (-513) when it is interrupted by an event
> /and/ the process has a pending signal then %eip (and %eax) are
> corrupted when returning to the main process after handling the
> signal.  The application may then crash with SIGSEGV or a SIGILL or it
> may have subtly incorrect behaviour (depending on what instruction it
> returned to).
> 
> The occurs because handle_signal() is incorrectly thinking that there
> is a system call that needs to restarted so it adjusts %eip and %eax
> to re-execute the system call instruction (even though user space had
> not done a system call).
> 
> If %eax == -514 (-ERESTARTNOHAND (-514) or -ERESTART_RESTARTBLOCK
> (-516) then handle_signal() only corrupted %eax (by setting it to
> -EINTR).  This may cause the application to crash or have incorrect
> behaviour.
> 
> handle_signal() assumes that regs->orig_ax >= 0 means a system call so
> any kernel entry point that is not for a system call must push a
> negative value for orig_ax.  For example, for physical interrupts on
> bare metal the inverse of the vector is pushed and page_fault() sets
> regs->orig_ax to -1, overwriting the hardware provided error code.
> 
> xen_hypervisor_callback() was incorrectly pushing 0 for orig_ax
> instead of -1.  For consistency, we also change
> xen_failsafe_callback().

Is this really just for consistency? There is a way for the failsafe
callback to continue to ret_from_exception, and I would think that
the same situation could arise there (and for the x86-64 case too).

Jan

> Classic Xen kernels pushed %eax which works as %eax cannot be both
> non-negative and -RESTARTSYS (etc.), but using -1 avoids the
> additional tests in handle_signal().
> 
> Signed-off-by: David Vrabel 
> Cc: stable@kernel.org 
> ---
>  arch/x86/kernel/entry_32.S |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
> index 2c63407..6a19e66 100644
> --- a/arch/x86/kernel/entry_32.S
> +++ b/arch/x86/kernel/entry_32.S
> @@ -1042,7 +1042,7 @@ ENTRY(xen_sysenter_target)
>  
>  ENTRY(xen_hypervisor_callback)
>  	CFI_STARTPROC
> -	pushl_cfi $0
> +	pushl_cfi $-1 /* orig_ax = -1 => not a system call */
>  	SAVE_ALL
>  	TRACE_IRQS_OFF
>  
> @@ -1078,7 +1078,7 @@ ENDPROC(xen_hypervisor_callback)
>  # We distinguish between categories by maintaining a status value in EAX.
>  ENTRY(xen_failsafe_callback)
>  	CFI_STARTPROC
> -	pushl_cfi %eax
> +	pushl_cfi $-1  /* orig_ax = -1 => not a system call */
>  	movl $1,%eax
>  1:	mov 4(%esp),%ds
>  2:	mov 8(%esp),%es
> -- 
> 1.7.2.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 12:08:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 12:08:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOSPg-0008TG-1S; Wed, 17 Oct 2012 12:07:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOSPe-0008Sz-7S
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 12:07:50 +0000
Received: from [85.158.143.35:49539] by server-1.bemta-4.messagelabs.com id
	38/36-19134-59F9E705; Wed, 17 Oct 2012 12:07:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1350475668!11843470!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1866 invoked from network); 17 Oct 2012 12:07:48 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-21.messagelabs.com with SMTP;
	17 Oct 2012 12:07:48 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 17 Oct 2012 13:07:48 +0100
Message-Id: <507EBBB302000078000A1FAC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 17 Oct 2012 13:07:47 +0100
From: "Jan Beulich" 
To: "David Vrabel" 
References: <1350474150-3990-1-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1350474150-3990-1-git-send-email-david.vrabel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Frediano Ziglio ,
	Konrad Rzeszutek Wilk ,
	stable@kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen/x86: don't corrupt %eip when returning
 from a signal handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 17.10.12 at 13:42, David Vrabel  wrote:
> From: David Vrabel 
> 
> In 32 bit guests, if a userspace process has %eax == -ERESTARTSYS
> (-512) or -ERESTARTNOINTR (-513) when it is interrupted by an event
> /and/ the process has a pending signal then %eip (and %eax) are
> corrupted when returning to the main process after handling the
> signal.  The application may then crash with SIGSEGV or a SIGILL or it
> may have subtly incorrect behaviour (depending on what instruction it
> returned to).
> 
> The occurs because handle_signal() is incorrectly thinking that there
> is a system call that needs to restarted so it adjusts %eip and %eax
> to re-execute the system call instruction (even though user space had
> not done a system call).
> 
> If %eax == -514 (-ERESTARTNOHAND (-514) or -ERESTART_RESTARTBLOCK
> (-516) then handle_signal() only corrupted %eax (by setting it to
> -EINTR).  This may cause the application to crash or have incorrect
> behaviour.
> 
> handle_signal() assumes that regs->orig_ax >= 0 means a system call so
> any kernel entry point that is not for a system call must push a
> negative value for orig_ax.  For example, for physical interrupts on
> bare metal the inverse of the vector is pushed and page_fault() sets
> regs->orig_ax to -1, overwriting the hardware provided error code.
> 
> xen_hypervisor_callback() was incorrectly pushing 0 for orig_ax
> instead of -1.  For consistency, we also change
> xen_failsafe_callback().

Is this really just for consistency? There is a way for the failsafe
callback to continue to ret_from_exception, and I would think that
the same situation could arise there (and for the x86-64 case too).

Jan

> Classic Xen kernels pushed %eax which works as %eax cannot be both
> non-negative and -RESTARTSYS (etc.), but using -1 avoids the
> additional tests in handle_signal().
> 
> Signed-off-by: David Vrabel 
> Cc: stable@kernel.org 
> ---
>  arch/x86/kernel/entry_32.S |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
> index 2c63407..6a19e66 100644
> --- a/arch/x86/kernel/entry_32.S
> +++ b/arch/x86/kernel/entry_32.S
> @@ -1042,7 +1042,7 @@ ENTRY(xen_sysenter_target)
>  
>  ENTRY(xen_hypervisor_callback)
>  	CFI_STARTPROC
> -	pushl_cfi $0
> +	pushl_cfi $-1 /* orig_ax = -1 => not a system call */
>  	SAVE_ALL
>  	TRACE_IRQS_OFF
>  
> @@ -1078,7 +1078,7 @@ ENDPROC(xen_hypervisor_callback)
>  # We distinguish between categories by maintaining a status value in EAX.
>  ENTRY(xen_failsafe_callback)
>  	CFI_STARTPROC
> -	pushl_cfi %eax
> +	pushl_cfi $-1  /* orig_ax = -1 => not a system call */
>  	movl $1,%eax
>  1:	mov 4(%esp),%ds
>  2:	mov 8(%esp),%es
> -- 
> 1.7.2.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 12:08:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 12:08:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOSPf-0008T9-Lq; Wed, 17 Oct 2012 12:07:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOSPd-0008Sy-QL
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 12:07:50 +0000
Received: from [85.158.139.211:62194] by server-7.bemta-5.messagelabs.com id
	08/AB-23102-59F9E705; Wed, 17 Oct 2012 12:07:49 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1350475668!22621824!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3875 invoked from network); 17 Oct 2012 12:07:48 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 12:07:48 -0000
Received: by mail-bk0-f45.google.com with SMTP id jf3so3284448bkc.32
	for ; Wed, 17 Oct 2012 05:07:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=g9OWh7EhycxFi4DeerRN3BumnwU7RG7myEQMbvKjs1Q=;
	b=p6qVWMRHXsuWoAEQ95ANfwE6hjf/UReJUTxOMpfQSGtFKYf1OuCIhVysMBTbX5/6Ej
	w3jxl4JAI5Y2MePkjChiM0wHpsNu+4CbjZGUOzQ3wAIwm0rnHgH5UnBn8VIcxpM150We
	PoTAfAeFnPTfIunW8/Pd8jxe+NBfctW83FV3oauDF1uzRq6hvr/y1ep+vH+JE32Es42a
	/aQspqt78AcLnK9VR4KslQPbgkaTH3WYv792FyZTQ5QNAPzkuFUW2dQlXMhJpWRf2OpE
	Q4V5V5wyBC9AcKsz/8GE89ZbXpxu3BbqWW2d8/WGO979MtYXk8CMbcUzgAKKe7YjCDOF
	uWug==
Received: by 10.204.9.4 with SMTP id j4mr5170155bkj.22.1350475668136;
	Wed, 17 Oct 2012 05:07:48 -0700 (PDT)
Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com.
	[86.183.156.141])
	by mx.google.com with ESMTPS id s20sm12725485bkw.15.2012.10.17.05.07.46
	(version=SSLv3 cipher=OTHER); Wed, 17 Oct 2012 05:07:47 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Wed, 17 Oct 2012 13:07:43 +0100
From: Keir Fraser 
To: Jan Beulich ,
	xen-devel 
Message-ID: 
Thread-Topic: [Xen-devel] [PATCH] ACPI/APEI: fix ERST MOVE_DATA instruction
	implementation
Thread-Index: Ac2sYAL0fT4CV6A9skKpCY2Uy4s2yw==
In-Reply-To: <507EB85802000078000A1F79@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] ACPI/APEI: fix ERST MOVE_DATA instruction
 implementation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/10/2012 12:53, "Jan Beulich"  wrote:

> Before anyone asks - yes, I have added to my todo list to put in
> place a proper ioremap() for x86. But since I'm under some time
> pressure right now, this was the faster route to something that
> can be committed to see whether the regression goes away.

That's good as we'll need it for >4kB per-VCPU stacks (even if we only need
4kB VCPU stacks, we'll want a guard page too).

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 12:08:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 12:08:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOSPf-0008T9-Lq; Wed, 17 Oct 2012 12:07:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOSPd-0008Sy-QL
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 12:07:50 +0000
Received: from [85.158.139.211:62194] by server-7.bemta-5.messagelabs.com id
	08/AB-23102-59F9E705; Wed, 17 Oct 2012 12:07:49 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1350475668!22621824!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3875 invoked from network); 17 Oct 2012 12:07:48 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 12:07:48 -0000
Received: by mail-bk0-f45.google.com with SMTP id jf3so3284448bkc.32
	for ; Wed, 17 Oct 2012 05:07:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=g9OWh7EhycxFi4DeerRN3BumnwU7RG7myEQMbvKjs1Q=;
	b=p6qVWMRHXsuWoAEQ95ANfwE6hjf/UReJUTxOMpfQSGtFKYf1OuCIhVysMBTbX5/6Ej
	w3jxl4JAI5Y2MePkjChiM0wHpsNu+4CbjZGUOzQ3wAIwm0rnHgH5UnBn8VIcxpM150We
	PoTAfAeFnPTfIunW8/Pd8jxe+NBfctW83FV3oauDF1uzRq6hvr/y1ep+vH+JE32Es42a
	/aQspqt78AcLnK9VR4KslQPbgkaTH3WYv792FyZTQ5QNAPzkuFUW2dQlXMhJpWRf2OpE
	Q4V5V5wyBC9AcKsz/8GE89ZbXpxu3BbqWW2d8/WGO979MtYXk8CMbcUzgAKKe7YjCDOF
	uWug==
Received: by 10.204.9.4 with SMTP id j4mr5170155bkj.22.1350475668136;
	Wed, 17 Oct 2012 05:07:48 -0700 (PDT)
Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com.
	[86.183.156.141])
	by mx.google.com with ESMTPS id s20sm12725485bkw.15.2012.10.17.05.07.46
	(version=SSLv3 cipher=OTHER); Wed, 17 Oct 2012 05:07:47 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Wed, 17 Oct 2012 13:07:43 +0100
From: Keir Fraser 
To: Jan Beulich ,
	xen-devel 
Message-ID: 
Thread-Topic: [Xen-devel] [PATCH] ACPI/APEI: fix ERST MOVE_DATA instruction
	implementation
Thread-Index: Ac2sYAL0fT4CV6A9skKpCY2Uy4s2yw==
In-Reply-To: <507EB85802000078000A1F79@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] ACPI/APEI: fix ERST MOVE_DATA instruction
 implementation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/10/2012 12:53, "Jan Beulich"  wrote:

> Before anyone asks - yes, I have added to my todo list to put in
> place a proper ioremap() for x86. But since I'm under some time
> pressure right now, this was the faster route to something that
> can be committed to see whether the regression goes away.

That's good as we'll need it for >4kB per-VCPU stacks (even if we only need
4kB VCPU stacks, we'll want a guard page too).

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 12:11:33 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 12:11:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOST3-0000IH-M0; Wed, 17 Oct 2012 12:11:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOST2-0000I4-KE
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 12:11:20 +0000
Received: from [85.158.143.35:7965] by server-3.bemta-4.messagelabs.com id
	A4/1F-03544-860AE705; Wed, 17 Oct 2012 12:11:20 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-4.tower-21.messagelabs.com!1350475878!5307140!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MjQxMzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6491 invoked from network); 17 Oct 2012 12:11:19 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Oct 2012 12:11:19 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id BF9CC1838;
	Wed, 17 Oct 2012 15:11:16 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 52B6B20058; Wed, 17 Oct 2012 15:11:16 +0300 (EEST)
Date: Wed, 17 Oct 2012 15:11:16 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= 
To: Alexandre Bezroutchko 
Message-ID: <20121017121115.GI8912@reaktio.net>
References: 
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: nathanael@polymorpheus.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] pvusb with kernel 3.4 / 3.6
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 17, 2012 at 01:21:53PM +0200, Alexandre Bezroutchko wrote:
>    Hi Nathanael,
> =

>    Is it possible to use your patch [1] on newer kernels? I've tried to u=
se
>    it but most devices are not usable and some cause kernel crash. Detail=
ed
>    description of an attempt on kernel 3.4 is at [2] and (somewhat less
>    detailed) with 3.6 is at [3]. I'm motivated to make it work, any ideas
>    what can be done to fix this issue? Please tell me if you need any
>    additional info.
> =

>    I've added xen-devel and Pasi K=E4rkk=E4inen into Cc, hope this is ok.
>

I think Konrad has the pvusb drivers in his git tree..


-- Pasi
 =


>    Regards,
>    Alex
> =

>    [1] [1]http://lists.xen.org/archives/html/xen-devel/2012-02/msg00571.h=
tml
>    [2]
>    [2]https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/3IAf7f8lz2UJ
>    [3]
>    [3]https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/rNmVAOXX4dYJ
> =

> References
> =

>    Visible links
>    1. http://lists.xen.org/archives/html/xen-devel/2012-02/msg00571.html
>    2. https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/3IAf7f8lz2UJ
>    3. https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/rNmVAOXX4dYJ

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 12:11:33 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 12:11:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOST3-0000IH-M0; Wed, 17 Oct 2012 12:11:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOST2-0000I4-KE
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 12:11:20 +0000
Received: from [85.158.143.35:7965] by server-3.bemta-4.messagelabs.com id
	A4/1F-03544-860AE705; Wed, 17 Oct 2012 12:11:20 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-4.tower-21.messagelabs.com!1350475878!5307140!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MjQxMzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6491 invoked from network); 17 Oct 2012 12:11:19 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Oct 2012 12:11:19 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id BF9CC1838;
	Wed, 17 Oct 2012 15:11:16 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 52B6B20058; Wed, 17 Oct 2012 15:11:16 +0300 (EEST)
Date: Wed, 17 Oct 2012 15:11:16 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= 
To: Alexandre Bezroutchko 
Message-ID: <20121017121115.GI8912@reaktio.net>
References: 
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: nathanael@polymorpheus.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] pvusb with kernel 3.4 / 3.6
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 17, 2012 at 01:21:53PM +0200, Alexandre Bezroutchko wrote:
>    Hi Nathanael,
> =

>    Is it possible to use your patch [1] on newer kernels? I've tried to u=
se
>    it but most devices are not usable and some cause kernel crash. Detail=
ed
>    description of an attempt on kernel 3.4 is at [2] and (somewhat less
>    detailed) with 3.6 is at [3]. I'm motivated to make it work, any ideas
>    what can be done to fix this issue? Please tell me if you need any
>    additional info.
> =

>    I've added xen-devel and Pasi K=E4rkk=E4inen into Cc, hope this is ok.
>

I think Konrad has the pvusb drivers in his git tree..


-- Pasi
 =


>    Regards,
>    Alex
> =

>    [1] [1]http://lists.xen.org/archives/html/xen-devel/2012-02/msg00571.h=
tml
>    [2]
>    [2]https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/3IAf7f8lz2UJ
>    [3]
>    [3]https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/rNmVAOXX4dYJ
> =

> References
> =

>    Visible links
>    1. http://lists.xen.org/archives/html/xen-devel/2012-02/msg00571.html
>    2. https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/3IAf7f8lz2UJ
>    3. https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/rNmVAOXX4dYJ

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 12:15:26 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 12:15:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOSWr-0000VX-E5; Wed, 17 Oct 2012 12:15:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOSWq-0000VS-IG
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 12:15:16 +0000
Received: from [85.158.143.35:28736] by server-1.bemta-4.messagelabs.com id
	59/A0-19134-351AE705; Wed, 17 Oct 2012 12:15:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1350476114!5659909!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6498 invoked from network); 17 Oct 2012 12:15:14 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-21.messagelabs.com with SMTP;
	17 Oct 2012 12:15:14 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 17 Oct 2012 13:15:13 +0100
Message-Id: <507EBD7002000078000A1FC9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 17 Oct 2012 13:15:12 +0100
From: "Jan Beulich" 
To: "Keir Fraser" 
References: <507EB85802000078000A1F79@nat28.tlf.novell.com>
	
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel 
Subject: Re: [Xen-devel] [PATCH] ACPI/APEI: fix ERST MOVE_DATA instruction
 implementation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 17.10.12 at 14:07, Keir Fraser  wrote:
> On 17/10/2012 12:53, "Jan Beulich"  wrote:
> 
>> Before anyone asks - yes, I have added to my todo list to put in
>> place a proper ioremap() for x86. But since I'm under some time
>> pressure right now, this was the faster route to something that
>> can be committed to see whether the regression goes away.
> 
> That's good as we'll need it for >4kB per-VCPU stacks (even if we only need
> 4kB VCPU stacks, we'll want a guard page too).

But why would you want to do that via ioremap()?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 12:15:26 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 12:15:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOSWr-0000VX-E5; Wed, 17 Oct 2012 12:15:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOSWq-0000VS-IG
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 12:15:16 +0000
Received: from [85.158.143.35:28736] by server-1.bemta-4.messagelabs.com id
	59/A0-19134-351AE705; Wed, 17 Oct 2012 12:15:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1350476114!5659909!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6498 invoked from network); 17 Oct 2012 12:15:14 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-21.messagelabs.com with SMTP;
	17 Oct 2012 12:15:14 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 17 Oct 2012 13:15:13 +0100
Message-Id: <507EBD7002000078000A1FC9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 17 Oct 2012 13:15:12 +0100
From: "Jan Beulich" 
To: "Keir Fraser" 
References: <507EB85802000078000A1F79@nat28.tlf.novell.com>
	
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel 
Subject: Re: [Xen-devel] [PATCH] ACPI/APEI: fix ERST MOVE_DATA instruction
 implementation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 17.10.12 at 14:07, Keir Fraser  wrote:
> On 17/10/2012 12:53, "Jan Beulich"  wrote:
> 
>> Before anyone asks - yes, I have added to my todo list to put in
>> place a proper ioremap() for x86. But since I'm under some time
>> pressure right now, this was the faster route to something that
>> can be committed to see whether the regression goes away.
> 
> That's good as we'll need it for >4kB per-VCPU stacks (even if we only need
> 4kB VCPU stacks, we'll want a guard page too).

But why would you want to do that via ioremap()?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 12:20:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 12:20:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOSbQ-0000fg-6M; Wed, 17 Oct 2012 12:20:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOSbO-0000fY-BA
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 12:19:58 +0000
Received: from [85.158.139.211:51133] by server-9.bemta-5.messagelabs.com id
	B2/06-23053-D62AE705; Wed, 17 Oct 2012 12:19:57 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1350476395!21157025!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODMwNDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9223 invoked from network); 17 Oct 2012 12:19:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 12:19:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,600,1344211200"; d="scan'208";a="211543026"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 12:19:55 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Wed, 17 Oct 2012
	08:19:54 -0400
Message-ID: <507EA269.4070807@citrix.com>
Date: Wed, 17 Oct 2012 13:19:53 +0100
From: David Vrabel 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Jan Beulich 
References: <1350474150-3990-1-git-send-email-david.vrabel@citrix.com>
	<507EBBB302000078000A1FAC@nat28.tlf.novell.com>
In-Reply-To: <507EBBB302000078000A1FAC@nat28.tlf.novell.com>
Cc: Frediano Ziglio ,
	Konrad Rzeszutek Wilk ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] xen/x86: don't corrupt %eip when returning
 from a signal handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/10/12 13:07, Jan Beulich wrote:
>>>> On 17.10.12 at 13:42, David Vrabel  wrote:
>> From: David Vrabel 
>>
>> In 32 bit guests, if a userspace process has %eax == -ERESTARTSYS
>> (-512) or -ERESTARTNOINTR (-513) when it is interrupted by an event
>> /and/ the process has a pending signal then %eip (and %eax) are
>> corrupted when returning to the main process after handling the
>> signal.  The application may then crash with SIGSEGV or a SIGILL or it
>> may have subtly incorrect behaviour (depending on what instruction it
>> returned to).
>>
>> The occurs because handle_signal() is incorrectly thinking that there
>> is a system call that needs to restarted so it adjusts %eip and %eax
>> to re-execute the system call instruction (even though user space had
>> not done a system call).
>>
>> If %eax == -514 (-ERESTARTNOHAND (-514) or -ERESTART_RESTARTBLOCK
>> (-516) then handle_signal() only corrupted %eax (by setting it to
>> -EINTR).  This may cause the application to crash or have incorrect
>> behaviour.
>>
>> handle_signal() assumes that regs->orig_ax >= 0 means a system call so
>> any kernel entry point that is not for a system call must push a
>> negative value for orig_ax.  For example, for physical interrupts on
>> bare metal the inverse of the vector is pushed and page_fault() sets
>> regs->orig_ax to -1, overwriting the hardware provided error code.
>>
>> xen_hypervisor_callback() was incorrectly pushing 0 for orig_ax
>> instead of -1.  For consistency, we also change
>> xen_failsafe_callback().
> 
> Is this really just for consistency? There is a way for the failsafe
> callback to continue to ret_from_exception, and I would think that
> the same situation could arise there (and for the x86-64 case too).

The 32-bit xen_failsafe_callback was using %eax for orig_ax which is
safe (see comment on classic kernel behaviour below).

We couldn't repro the issue in 64-bit guests and looking at entry_64.S
xen_hypervisor_callback is correct (see the zeroentry macro).

I must admit to not really being able to follow what
xen_failsafe_callback is doing, but it does look like that last pushq
before the SAVE_ALL should be pushq_cfi $-1 as well.  Do you agree?

David

>> Classic Xen kernels pushed %eax which works as %eax cannot be both
>> non-negative and -RESTARTSYS (etc.), but using -1 avoids the
>> additional tests in handle_signal().
>>
>> Signed-off-by: David Vrabel 
>> Cc: stable@kernel.org 
>> ---
>>  arch/x86/kernel/entry_32.S |    4 ++--
>>  1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
>> index 2c63407..6a19e66 100644
>> --- a/arch/x86/kernel/entry_32.S
>> +++ b/arch/x86/kernel/entry_32.S
>> @@ -1042,7 +1042,7 @@ ENTRY(xen_sysenter_target)
>>  
>>  ENTRY(xen_hypervisor_callback)
>>  	CFI_STARTPROC
>> -	pushl_cfi $0
>> +	pushl_cfi $-1 /* orig_ax = -1 => not a system call */
>>  	SAVE_ALL
>>  	TRACE_IRQS_OFF
>>  
>> @@ -1078,7 +1078,7 @@ ENDPROC(xen_hypervisor_callback)
>>  # We distinguish between categories by maintaining a status value in EAX.
>>  ENTRY(xen_failsafe_callback)
>>  	CFI_STARTPROC
>> -	pushl_cfi %eax
>> +	pushl_cfi $-1  /* orig_ax = -1 => not a system call */
>>  	movl $1,%eax
>>  1:	mov 4(%esp),%ds
>>  2:	mov 8(%esp),%es
>> -- 
>> 1.7.2.5
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org 
>> http://lists.xen.org/xen-devel 
> 
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 12:20:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 12:20:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOSbQ-0000fg-6M; Wed, 17 Oct 2012 12:20:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOSbO-0000fY-BA
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 12:19:58 +0000
Received: from [85.158.139.211:51133] by server-9.bemta-5.messagelabs.com id
	B2/06-23053-D62AE705; Wed, 17 Oct 2012 12:19:57 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1350476395!21157025!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODMwNDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9223 invoked from network); 17 Oct 2012 12:19:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 12:19:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,600,1344211200"; d="scan'208";a="211543026"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 12:19:55 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Wed, 17 Oct 2012
	08:19:54 -0400
Message-ID: <507EA269.4070807@citrix.com>
Date: Wed, 17 Oct 2012 13:19:53 +0100
From: David Vrabel 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Jan Beulich 
References: <1350474150-3990-1-git-send-email-david.vrabel@citrix.com>
	<507EBBB302000078000A1FAC@nat28.tlf.novell.com>
In-Reply-To: <507EBBB302000078000A1FAC@nat28.tlf.novell.com>
Cc: Frediano Ziglio ,
	Konrad Rzeszutek Wilk ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] xen/x86: don't corrupt %eip when returning
 from a signal handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/10/12 13:07, Jan Beulich wrote:
>>>> On 17.10.12 at 13:42, David Vrabel  wrote:
>> From: David Vrabel 
>>
>> In 32 bit guests, if a userspace process has %eax == -ERESTARTSYS
>> (-512) or -ERESTARTNOINTR (-513) when it is interrupted by an event
>> /and/ the process has a pending signal then %eip (and %eax) are
>> corrupted when returning to the main process after handling the
>> signal.  The application may then crash with SIGSEGV or a SIGILL or it
>> may have subtly incorrect behaviour (depending on what instruction it
>> returned to).
>>
>> The occurs because handle_signal() is incorrectly thinking that there
>> is a system call that needs to restarted so it adjusts %eip and %eax
>> to re-execute the system call instruction (even though user space had
>> not done a system call).
>>
>> If %eax == -514 (-ERESTARTNOHAND (-514) or -ERESTART_RESTARTBLOCK
>> (-516) then handle_signal() only corrupted %eax (by setting it to
>> -EINTR).  This may cause the application to crash or have incorrect
>> behaviour.
>>
>> handle_signal() assumes that regs->orig_ax >= 0 means a system call so
>> any kernel entry point that is not for a system call must push a
>> negative value for orig_ax.  For example, for physical interrupts on
>> bare metal the inverse of the vector is pushed and page_fault() sets
>> regs->orig_ax to -1, overwriting the hardware provided error code.
>>
>> xen_hypervisor_callback() was incorrectly pushing 0 for orig_ax
>> instead of -1.  For consistency, we also change
>> xen_failsafe_callback().
> 
> Is this really just for consistency? There is a way for the failsafe
> callback to continue to ret_from_exception, and I would think that
> the same situation could arise there (and for the x86-64 case too).

The 32-bit xen_failsafe_callback was using %eax for orig_ax which is
safe (see comment on classic kernel behaviour below).

We couldn't repro the issue in 64-bit guests and looking at entry_64.S
xen_hypervisor_callback is correct (see the zeroentry macro).

I must admit to not really being able to follow what
xen_failsafe_callback is doing, but it does look like that last pushq
before the SAVE_ALL should be pushq_cfi $-1 as well.  Do you agree?

David

>> Classic Xen kernels pushed %eax which works as %eax cannot be both
>> non-negative and -RESTARTSYS (etc.), but using -1 avoids the
>> additional tests in handle_signal().
>>
>> Signed-off-by: David Vrabel 
>> Cc: stable@kernel.org 
>> ---
>>  arch/x86/kernel/entry_32.S |    4 ++--
>>  1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
>> index 2c63407..6a19e66 100644
>> --- a/arch/x86/kernel/entry_32.S
>> +++ b/arch/x86/kernel/entry_32.S
>> @@ -1042,7 +1042,7 @@ ENTRY(xen_sysenter_target)
>>  
>>  ENTRY(xen_hypervisor_callback)
>>  	CFI_STARTPROC
>> -	pushl_cfi $0
>> +	pushl_cfi $-1 /* orig_ax = -1 => not a system call */
>>  	SAVE_ALL
>>  	TRACE_IRQS_OFF
>>  
>> @@ -1078,7 +1078,7 @@ ENDPROC(xen_hypervisor_callback)
>>  # We distinguish between categories by maintaining a status value in EAX.
>>  ENTRY(xen_failsafe_callback)
>>  	CFI_STARTPROC
>> -	pushl_cfi %eax
>> +	pushl_cfi $-1  /* orig_ax = -1 => not a system call */
>>  	movl $1,%eax
>>  1:	mov 4(%esp),%ds
>>  2:	mov 8(%esp),%es
>> -- 
>> 1.7.2.5
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org 
>> http://lists.xen.org/xen-devel 
> 
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 12:28:40 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 12:28:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOSjb-0000py-9u; Wed, 17 Oct 2012 12:28:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOSja-0000pt-4t
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 12:28:26 +0000
Received: from [85.158.138.51:9292] by server-11.bemta-3.messagelabs.com id
	D3/FB-24008-964AE705; Wed, 17 Oct 2012 12:28:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1350476904!25834600!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5591 invoked from network); 17 Oct 2012 12:28:24 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-174.messagelabs.com with SMTP;
	17 Oct 2012 12:28:24 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 17 Oct 2012 13:28:09 +0100
Message-Id: <507EC07802000078000A1FE3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 17 Oct 2012 13:28:08 +0100
From: "Jan Beulich" 
To: "David Vrabel" 
References: <1350474150-3990-1-git-send-email-david.vrabel@citrix.com>
	<507EBBB302000078000A1FAC@nat28.tlf.novell.com>
	<507EA269.4070807@citrix.com>
In-Reply-To: <507EA269.4070807@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Frediano Ziglio ,
	Konrad Rzeszutek Wilk ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] xen/x86: don't corrupt %eip when returning
 from a signal handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 17.10.12 at 14:19, David Vrabel  wrote:
> On 17/10/12 13:07, Jan Beulich wrote:
>>>>> On 17.10.12 at 13:42, David Vrabel  wrote:
>>> From: David Vrabel 
>>>
>>> In 32 bit guests, if a userspace process has %eax == -ERESTARTSYS
>>> (-512) or -ERESTARTNOINTR (-513) when it is interrupted by an event
>>> /and/ the process has a pending signal then %eip (and %eax) are
>>> corrupted when returning to the main process after handling the
>>> signal.  The application may then crash with SIGSEGV or a SIGILL or it
>>> may have subtly incorrect behaviour (depending on what instruction it
>>> returned to).
>>>
>>> The occurs because handle_signal() is incorrectly thinking that there
>>> is a system call that needs to restarted so it adjusts %eip and %eax
>>> to re-execute the system call instruction (even though user space had
>>> not done a system call).
>>>
>>> If %eax == -514 (-ERESTARTNOHAND (-514) or -ERESTART_RESTARTBLOCK
>>> (-516) then handle_signal() only corrupted %eax (by setting it to
>>> -EINTR).  This may cause the application to crash or have incorrect
>>> behaviour.
>>>
>>> handle_signal() assumes that regs->orig_ax >= 0 means a system call so
>>> any kernel entry point that is not for a system call must push a
>>> negative value for orig_ax.  For example, for physical interrupts on
>>> bare metal the inverse of the vector is pushed and page_fault() sets
>>> regs->orig_ax to -1, overwriting the hardware provided error code.
>>>
>>> xen_hypervisor_callback() was incorrectly pushing 0 for orig_ax
>>> instead of -1.  For consistency, we also change
>>> xen_failsafe_callback().
>> 
>> Is this really just for consistency? There is a way for the failsafe
>> callback to continue to ret_from_exception, and I would think that
>> the same situation could arise there (and for the x86-64 case too).
> 
> The 32-bit xen_failsafe_callback was using %eax for orig_ax which is
> safe (see comment on classic kernel behaviour below).

Ah, yes, I didn't spot that %eax was used there instead of 0
(and other than inn the classic Xen kernel, which I will want to
fix too).

> We couldn't repro the issue in 64-bit guests and looking at entry_64.S
> xen_hypervisor_callback is correct (see the zeroentry macro).

Yes, the normal callback path isn't affected there.

> I must admit to not really being able to follow what
> xen_failsafe_callback is doing, but it does look like that last pushq
> before the SAVE_ALL should be pushq_cfi $-1 as well.  Do you agree?

That's what I was trying to hint at. Feel free to put my ack on
the patch if you re-submit with that adjustment (and ideally the
commit message adjusted too).

Jan

>>> Classic Xen kernels pushed %eax which works as %eax cannot be both
>>> non-negative and -RESTARTSYS (etc.), but using -1 avoids the
>>> additional tests in handle_signal().
>>>
>>> Signed-off-by: David Vrabel 
>>> Cc: stable@kernel.org 
>>> ---
>>>  arch/x86/kernel/entry_32.S |    4 ++--
>>>  1 files changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
>>> index 2c63407..6a19e66 100644
>>> --- a/arch/x86/kernel/entry_32.S
>>> +++ b/arch/x86/kernel/entry_32.S
>>> @@ -1042,7 +1042,7 @@ ENTRY(xen_sysenter_target)
>>>  
>>>  ENTRY(xen_hypervisor_callback)
>>>  	CFI_STARTPROC
>>> -	pushl_cfi $0
>>> +	pushl_cfi $-1 /* orig_ax = -1 => not a system call */
>>>  	SAVE_ALL
>>>  	TRACE_IRQS_OFF
>>>  
>>> @@ -1078,7 +1078,7 @@ ENDPROC(xen_hypervisor_callback)
>>>  # We distinguish between categories by maintaining a status value in EAX.
>>>  ENTRY(xen_failsafe_callback)
>>>  	CFI_STARTPROC
>>> -	pushl_cfi %eax
>>> +	pushl_cfi $-1  /* orig_ax = -1 => not a system call */
>>>  	movl $1,%eax
>>>  1:	mov 4(%esp),%ds
>>>  2:	mov 8(%esp),%es
>>> -- 
>>> 1.7.2.5
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org 
>>> http://lists.xen.org/xen-devel 
>> 
>> 
>> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 12:28:40 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 12:28:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOSjb-0000py-9u; Wed, 17 Oct 2012 12:28:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOSja-0000pt-4t
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 12:28:26 +0000
Received: from [85.158.138.51:9292] by server-11.bemta-3.messagelabs.com id
	D3/FB-24008-964AE705; Wed, 17 Oct 2012 12:28:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1350476904!25834600!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5591 invoked from network); 17 Oct 2012 12:28:24 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-174.messagelabs.com with SMTP;
	17 Oct 2012 12:28:24 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 17 Oct 2012 13:28:09 +0100
Message-Id: <507EC07802000078000A1FE3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 17 Oct 2012 13:28:08 +0100
From: "Jan Beulich" 
To: "David Vrabel" 
References: <1350474150-3990-1-git-send-email-david.vrabel@citrix.com>
	<507EBBB302000078000A1FAC@nat28.tlf.novell.com>
	<507EA269.4070807@citrix.com>
In-Reply-To: <507EA269.4070807@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Frediano Ziglio ,
	Konrad Rzeszutek Wilk ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] xen/x86: don't corrupt %eip when returning
 from a signal handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 17.10.12 at 14:19, David Vrabel  wrote:
> On 17/10/12 13:07, Jan Beulich wrote:
>>>>> On 17.10.12 at 13:42, David Vrabel  wrote:
>>> From: David Vrabel 
>>>
>>> In 32 bit guests, if a userspace process has %eax == -ERESTARTSYS
>>> (-512) or -ERESTARTNOINTR (-513) when it is interrupted by an event
>>> /and/ the process has a pending signal then %eip (and %eax) are
>>> corrupted when returning to the main process after handling the
>>> signal.  The application may then crash with SIGSEGV or a SIGILL or it
>>> may have subtly incorrect behaviour (depending on what instruction it
>>> returned to).
>>>
>>> The occurs because handle_signal() is incorrectly thinking that there
>>> is a system call that needs to restarted so it adjusts %eip and %eax
>>> to re-execute the system call instruction (even though user space had
>>> not done a system call).
>>>
>>> If %eax == -514 (-ERESTARTNOHAND (-514) or -ERESTART_RESTARTBLOCK
>>> (-516) then handle_signal() only corrupted %eax (by setting it to
>>> -EINTR).  This may cause the application to crash or have incorrect
>>> behaviour.
>>>
>>> handle_signal() assumes that regs->orig_ax >= 0 means a system call so
>>> any kernel entry point that is not for a system call must push a
>>> negative value for orig_ax.  For example, for physical interrupts on
>>> bare metal the inverse of the vector is pushed and page_fault() sets
>>> regs->orig_ax to -1, overwriting the hardware provided error code.
>>>
>>> xen_hypervisor_callback() was incorrectly pushing 0 for orig_ax
>>> instead of -1.  For consistency, we also change
>>> xen_failsafe_callback().
>> 
>> Is this really just for consistency? There is a way for the failsafe
>> callback to continue to ret_from_exception, and I would think that
>> the same situation could arise there (and for the x86-64 case too).
> 
> The 32-bit xen_failsafe_callback was using %eax for orig_ax which is
> safe (see comment on classic kernel behaviour below).

Ah, yes, I didn't spot that %eax was used there instead of 0
(and other than inn the classic Xen kernel, which I will want to
fix too).

> We couldn't repro the issue in 64-bit guests and looking at entry_64.S
> xen_hypervisor_callback is correct (see the zeroentry macro).

Yes, the normal callback path isn't affected there.

> I must admit to not really being able to follow what
> xen_failsafe_callback is doing, but it does look like that last pushq
> before the SAVE_ALL should be pushq_cfi $-1 as well.  Do you agree?

That's what I was trying to hint at. Feel free to put my ack on
the patch if you re-submit with that adjustment (and ideally the
commit message adjusted too).

Jan

>>> Classic Xen kernels pushed %eax which works as %eax cannot be both
>>> non-negative and -RESTARTSYS (etc.), but using -1 avoids the
>>> additional tests in handle_signal().
>>>
>>> Signed-off-by: David Vrabel 
>>> Cc: stable@kernel.org 
>>> ---
>>>  arch/x86/kernel/entry_32.S |    4 ++--
>>>  1 files changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
>>> index 2c63407..6a19e66 100644
>>> --- a/arch/x86/kernel/entry_32.S
>>> +++ b/arch/x86/kernel/entry_32.S
>>> @@ -1042,7 +1042,7 @@ ENTRY(xen_sysenter_target)
>>>  
>>>  ENTRY(xen_hypervisor_callback)
>>>  	CFI_STARTPROC
>>> -	pushl_cfi $0
>>> +	pushl_cfi $-1 /* orig_ax = -1 => not a system call */
>>>  	SAVE_ALL
>>>  	TRACE_IRQS_OFF
>>>  
>>> @@ -1078,7 +1078,7 @@ ENDPROC(xen_hypervisor_callback)
>>>  # We distinguish between categories by maintaining a status value in EAX.
>>>  ENTRY(xen_failsafe_callback)
>>>  	CFI_STARTPROC
>>> -	pushl_cfi %eax
>>> +	pushl_cfi $-1  /* orig_ax = -1 => not a system call */
>>>  	movl $1,%eax
>>>  1:	mov 4(%esp),%ds
>>>  2:	mov 8(%esp),%es
>>> -- 
>>> 1.7.2.5
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org 
>>> http://lists.xen.org/xen-devel 
>> 
>> 
>> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 13:02:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 13:02:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOTG8-0001AI-B4; Wed, 17 Oct 2012 13:02:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOTG7-0001A8-5r
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 13:02:03 +0000
Received: from [85.158.138.51:18692] by server-9.bemta-3.messagelabs.com id
	3C/78-16841-A4CAE705; Wed, 17 Oct 2012 13:02:02 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1350478921!16023631!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12100 invoked from network); 17 Oct 2012 13:02:01 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 13:02:01 -0000
Received: by mail-bk0-f45.google.com with SMTP id jf3so3318327bkc.32
	for ; Wed, 17 Oct 2012 06:02:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=S5pqSJomiscQDSHTQ3EeeEjKi8VqKsmTF+ipLFp9TZ4=;
	b=Jrmtm1h5kRMC31fwH32Ag+2baBGwcoYjqRbLHLRMBd97mQj8tWgbSL9uexpfTRlGbv
	cZrogouMDU8qls54qPjuIahfUvQ8HfvKn1YWo2HIpqT+6uXOpJ3rblSI8n0Erjfzfq74
	m556MqLmmmOnOoVmvo5ca01w2fdUfNZtmJO+9dbcwGau743xfsclJK5ZDGdtVs+3AsBI
	PpED7996xXP0eyZwQGqgSpSgjU0NIkyLchYWe5rPKtuRklkXJ3Ua/ZsPby6MgSXG/QQ8
	N8YanaY0piH8d4lx+n4Z3oRblKOWVfg13pMs7vV2PT7UCh9HimnDr04KcjjRpEKDRS9m
	gOHw==
Received: by 10.204.5.215 with SMTP id 23mr5209085bkw.101.1350478921220;
	Wed, 17 Oct 2012 06:02:01 -0700 (PDT)
Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com.
	[86.183.156.141])
	by mx.google.com with ESMTPS id e3sm12795110bks.7.2012.10.17.06.01.58
	(version=SSLv3 cipher=OTHER); Wed, 17 Oct 2012 06:01:59 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Wed, 17 Oct 2012 14:01:54 +0100
From: Keir Fraser 
To: Jan Beulich 
Message-ID: 
Thread-Topic: [Xen-devel] [PATCH] ACPI/APEI: fix ERST MOVE_DATA instruction
	implementation
Thread-Index: Ac2sZ5SzaLg0ByL5zUqjMLrWQiMpcA==
In-Reply-To: <507EBD7002000078000A1FC9@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel 
Subject: Re: [Xen-devel] [PATCH] ACPI/APEI: fix ERST MOVE_DATA instruction
 implementation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/10/2012 13:15, "Jan Beulich"  wrote:

>>>> On 17.10.12 at 14:07, Keir Fraser  wrote:
>> On 17/10/2012 12:53, "Jan Beulich"  wrote:
>> 
>>> Before anyone asks - yes, I have added to my todo list to put in
>>> place a proper ioremap() for x86. But since I'm under some time
>>> pressure right now, this was the faster route to something that
>>> can be committed to see whether the regression goes away.
>> 
>> That's good as we'll need it for >4kB per-VCPU stacks (even if we only need
>> 4kB VCPU stacks, we'll want a guard page too).
> 
> But why would you want to do that via ioremap()?

Well the required missing mechanism is the same, right? The ability to
allocate some unused virtual address space. We already have
map_pages_to_xen(), so it's just the allocation part that is missing for
either ioremap() or vcpu stacks.

 -- Keir

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 13:02:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 13:02:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOTG8-0001AI-B4; Wed, 17 Oct 2012 13:02:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOTG7-0001A8-5r
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 13:02:03 +0000
Received: from [85.158.138.51:18692] by server-9.bemta-3.messagelabs.com id
	3C/78-16841-A4CAE705; Wed, 17 Oct 2012 13:02:02 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1350478921!16023631!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12100 invoked from network); 17 Oct 2012 13:02:01 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 13:02:01 -0000
Received: by mail-bk0-f45.google.com with SMTP id jf3so3318327bkc.32
	for ; Wed, 17 Oct 2012 06:02:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=S5pqSJomiscQDSHTQ3EeeEjKi8VqKsmTF+ipLFp9TZ4=;
	b=Jrmtm1h5kRMC31fwH32Ag+2baBGwcoYjqRbLHLRMBd97mQj8tWgbSL9uexpfTRlGbv
	cZrogouMDU8qls54qPjuIahfUvQ8HfvKn1YWo2HIpqT+6uXOpJ3rblSI8n0Erjfzfq74
	m556MqLmmmOnOoVmvo5ca01w2fdUfNZtmJO+9dbcwGau743xfsclJK5ZDGdtVs+3AsBI
	PpED7996xXP0eyZwQGqgSpSgjU0NIkyLchYWe5rPKtuRklkXJ3Ua/ZsPby6MgSXG/QQ8
	N8YanaY0piH8d4lx+n4Z3oRblKOWVfg13pMs7vV2PT7UCh9HimnDr04KcjjRpEKDRS9m
	gOHw==
Received: by 10.204.5.215 with SMTP id 23mr5209085bkw.101.1350478921220;
	Wed, 17 Oct 2012 06:02:01 -0700 (PDT)
Received: from [192.168.1.3] (host86-183-156-141.range86-183.btcentralplus.com.
	[86.183.156.141])
	by mx.google.com with ESMTPS id e3sm12795110bks.7.2012.10.17.06.01.58
	(version=SSLv3 cipher=OTHER); Wed, 17 Oct 2012 06:01:59 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Wed, 17 Oct 2012 14:01:54 +0100
From: Keir Fraser 
To: Jan Beulich 
Message-ID: 
Thread-Topic: [Xen-devel] [PATCH] ACPI/APEI: fix ERST MOVE_DATA instruction
	implementation
Thread-Index: Ac2sZ5SzaLg0ByL5zUqjMLrWQiMpcA==
In-Reply-To: <507EBD7002000078000A1FC9@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel 
Subject: Re: [Xen-devel] [PATCH] ACPI/APEI: fix ERST MOVE_DATA instruction
 implementation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/10/2012 13:15, "Jan Beulich"  wrote:

>>>> On 17.10.12 at 14:07, Keir Fraser  wrote:
>> On 17/10/2012 12:53, "Jan Beulich"  wrote:
>> 
>>> Before anyone asks - yes, I have added to my todo list to put in
>>> place a proper ioremap() for x86. But since I'm under some time
>>> pressure right now, this was the faster route to something that
>>> can be committed to see whether the regression goes away.
>> 
>> That's good as we'll need it for >4kB per-VCPU stacks (even if we only need
>> 4kB VCPU stacks, we'll want a guard page too).
> 
> But why would you want to do that via ioremap()?

Well the required missing mechanism is the same, right? The ability to
allocate some unused virtual address space. We already have
map_pages_to_xen(), so it's just the allocation part that is missing for
either ioremap() or vcpu stacks.

 -- Keir

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 13:05:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 13:05:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOTIt-0001bl-Kf; Wed, 17 Oct 2012 13:04:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOTIr-0001bD-49
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 13:04:53 +0000
Received: from [85.158.139.211:5535] by server-8.bemta-5.messagelabs.com id
	1E/2C-23193-4FCAE705; Wed, 17 Oct 2012 13:04:52 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1350479090!21164506!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjIwMDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29678 invoked from network); 17 Oct 2012 13:04:51 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-9.tower-206.messagelabs.com with SMTP;
	17 Oct 2012 13:04:51 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 17 Oct 2012 06:04:50 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,600,1344236400"; d="scan'208";a="205575600"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by azsmga001.ch.intel.com with ESMTP; 17 Oct 2012 06:04:49 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 17 Oct 2012 06:04:49 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.123]) with mapi id
	14.01.0355.002; Wed, 17 Oct 2012 21:04:47 +0800
From: "Liu, Jinsong" 
To: Jan Beulich , Ian Campbell ,
	"Keir (Xen.org)" 
Thread-Topic: [Xen-devel] [xen-unstable bisection] complete
	test-amd64-i386-qemuu-rhel6hvm-amd
Thread-Index: AQHNrEhg0fOg/ClX8U+LJ4LAnirczpe9dJlg
Date: Wed, 17 Oct 2012 13:04:47 +0000
Message-ID: 
References: 
	<507E7D5C02000078000A1DE6@nat28.tlf.novell.com>
	<1350464551.2460.24.camel@zakaz.uk.xensource.com>
	<507E93F302000078000A1E98@nat28.tlf.novell.com>
In-Reply-To: <507E93F302000078000A1E98@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC829233535CED3SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: xen-devel ,
	Ian Jackson ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-i386-qemuu-rhel6hvm-amd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC829233535CED3SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Jan Beulich wrote:
>>>> On 17.10.12 at 11:02, Ian Campbell  wrote:
>> On Wed, 2012-10-17 at 08:41 +0100, Jan Beulich wrote:
>>> So I just now realized that a similar change was already done
>>> by 23736:31683aa4bfb3 and then reverted by
>>> 23760:ae10d7804168. Nothing was done subsequently to
>>> address the actual problem(s). It is quite obvious that the more
>>> relaxed check uncovers other bugs in the ERST code, yet looking
>>> at the Linux history of the corresponding file doesn't reveal any
>>> fix the lack of which would explain an outright hang (rather than
>>> a crash, as I would expect to be the result of e.g. the missing
>>> ioremap()-s added by 0bbba38a61283a55f2061ab3e0910c572d19f462.
>>>=20
>>> Most of the other changes are cosmetic or pstore related, so I
>>> wonder whether instead of reverting again we should try pulling
>>> in this one extra fix.
>>=20
>> Worth a go. I assume this issue isn't related to the typo you found
>> this morning?
>=20
> I didn't find any typo; the original author of the Linux side patch
> pointed out a typo in the commit message (which was copied
> verbatim from the Linux side).
>=20
>>> If reverting is preferred (or turns out necessary if that second
>>> fix doesn't help), we should settle on the disposition of the whole
>>> APEI/ERST code, as my conclusion is that it is pretty much
>>> unmaintained since its original contribution over two years ago.
>>=20
>> If we revert we should leave a big fat comment pointing to this
>> and/or the previous discussion to stop the next guy doing the same
>> thing.=20
>=20
> We should rather decide whether this should get fixed, or the
> code ripped out (decision mainly depending on the original
> contributer - Intel - being willing to fix the code).

I just checked the history.

1. It firstly checked in as c/s 22052 --> at that time it tested at an old =
intel platform (I forget type);
2. then it updated with c/s 23736 --> since when our QA tested at a newer i=
ntel platform, it cannot pass erst_check_table, after debug we found the ne=
wer intel platform bios has different header length definiation at its ERST=
 table, so we allow both size table work;
3. then it reverted with c/s 23760 --> since when test at an AMD platform b=
y Critix (see attached, complete test-amd64-i386-xl), it will hang, so Keir=
 revert it.

c/s 22052 and 23736 were tested at 2 intel platforms, but we have no way to=
 test at AMD platform. So the problem is, how to debug&fix it?

Thanks,
Jinsong=

--_002_DE8DF0795D48FD4CA783C40EC829233535CED3SHSMSX101ccrcorpi_
Content-Type: message/rfc822
Content-Disposition: attachment;
	creation-date="Wed, 17 Oct 2012 13:04:46 GMT";
	modification-date="Wed, 17 Oct 2012 13:04:46 GMT"

Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
 SHSMSX602.ccr.corp.intel.com (10.239.4.104) with Microsoft SMTP Server (TLS)
 id 8.2.255.0; Tue, 9 Aug 2011 22:58:46 +0800
Received: from rrsmsx602.amr.corp.intel.com (10.31.0.33) by
 SHSMSX101.ccr.corp.intel.com (10.239.4.153) with Microsoft SMTP Server (TLS)
 id 14.1.323.3; Tue, 9 Aug 2011 22:58:46 +0800
Received: from azsmga001.ch.intel.com (10.2.17.19) by rrsmsx602-1.rr.intel.com
 (10.31.0.33) with Microsoft SMTP Server id 8.2.255.0; Tue, 9 Aug 2011
 08:58:44 -0600
Received: from azsmga101.ch.intel.com ([10.2.16.36])  by
 azsmga001-1.ch.intel.com with ESMTP; 09 Aug 2011 07:58:40 -0700
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM)
 ([62.200.22.115])  by mga03.intel.com with ESMTP; 09 Aug 2011 07:58:39 -0700
Received: from unknown (HELO LONPMAILMX01.citrite.net) ([10.30.203.162])  by
 LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 Aug 2011 14:58:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
 smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0;
 Tue, 9 Aug 2011 15:58:37 +0100
Received: from [10.80.2.22] (helo=mariner.uk.xensource.com ident=Debian-exim)
	by norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
 )	id 1QqnlN-0000or-QI; Tue, 09 Aug 2011 14:58:37
 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69)
	(envelope-from )	id 1QqnlN-0005IP-OA; Tue, 09 Aug
 2011 15:58:37 +0100
From: Ian Jackson 
To: Keir Fraser 
CC: Jan Beulich , Stefano Stabellini
	, "xen-devel@lists.xensource.com"
	, "Liu, Jinsong" ,
	Jeremy Fitzhardinge 
Subject: Re: [Xen-devel] [xen-unstable bisection] complete test-amd64-i386-xl
Thread-Topic: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-i386-xl
Thread-Index: AcxWpNbpQT/v8LNISfqL/zQ9xkV3CA==
Date: Tue, 9 Aug 2011 14:58:37 +0000
Message-ID: <20033.19229.741344.489650@mariner.uk.xensource.com>
References: <20033.7748.282915.819692@mariner.uk.xensource.com>
	
In-Reply-To: 
Content-Language: en-US
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-AuthSource: rrsmsx602.amr.corp.intel.com
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ironport-av: E=Sophos;i="4.67,343,1309737600";    d="scan'208";a="7180551"
x-ironport-anti-spam-filtered: true
x-ironport-anti-spam-result: AhMBADBJQU4+yBZzmWdsb2JhbABCp08BAQEBAQgLCwcUJYFAAQEFJxMZJhALNhA8GwYOh3S+eYZGBJgOCRWLRQ
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Keir Fraser writes ("Re: [Xen-devel] [xen-unstable bisection] complete test=
-amd64-i386-xl"):
> Does reverting just the change to erst_check_table() fix the regression o=
n
> the affected test boxes? What about the similar-looking boot failure that
> you see, Jeremy?

Indeed, reverting xen/drivers/acpi/apei/erst.c, ie the change to
erst_check_table, seems to fix it.  That is,

  23736:31683aa4bfb3 "acpi: Add support for old and new bios erst, ..."
   +
  23742:50ddc200a60c "fix regression from c/s 23735:537918f518ee"

fails.  That plus the diff below boots happily.

Ian.

diff --git a/xen/drivers/acpi/apei/erst.c b/xen/drivers/acpi/apei/erst.c
index e012cd3..eb666a6 100644
--- a/xen/drivers/acpi/apei/erst.c
+++ b/xen/drivers/acpi/apei/erst.c
@@ -715,13 +715,7 @@ int erst_clear(u64 record_id)
=20
 static int __init erst_check_table(struct acpi_table_erst *erst_tab)
 {
-	/*
-	 * Some old BIOSes include the ACPI standard header in the ERST header
-	 * length; new BIOSes do not. Our check allows for both methods.
-	 */
-	if ((erst_tab->header_length !=3D
-	    (sizeof(struct acpi_table_erst) - sizeof(erst_tab->header)))
-	    && (erst_tab->header_length !=3D sizeof(struct acpi_table_erst)))
+	if (erst_tab->header_length !=3D sizeof(struct acpi_table_erst))
 		return -EINVAL;
 	if (erst_tab->header.length < sizeof(struct acpi_table_erst))
 		return -EINVAL;

--_002_DE8DF0795D48FD4CA783C40EC829233535CED3SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC829233535CED3SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Wed Oct 17 13:05:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 13:05:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOTIt-0001bl-Kf; Wed, 17 Oct 2012 13:04:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOTIr-0001bD-49
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 13:04:53 +0000
Received: from [85.158.139.211:5535] by server-8.bemta-5.messagelabs.com id
	1E/2C-23193-4FCAE705; Wed, 17 Oct 2012 13:04:52 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1350479090!21164506!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjIwMDA5\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29678 invoked from network); 17 Oct 2012 13:04:51 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-9.tower-206.messagelabs.com with SMTP;
	17 Oct 2012 13:04:51 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 17 Oct 2012 06:04:50 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,600,1344236400"; d="scan'208";a="205575600"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by azsmga001.ch.intel.com with ESMTP; 17 Oct 2012 06:04:49 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 17 Oct 2012 06:04:49 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.123]) with mapi id
	14.01.0355.002; Wed, 17 Oct 2012 21:04:47 +0800
From: "Liu, Jinsong" 
To: Jan Beulich , Ian Campbell ,
	"Keir (Xen.org)" 
Thread-Topic: [Xen-devel] [xen-unstable bisection] complete
	test-amd64-i386-qemuu-rhel6hvm-amd
Thread-Index: AQHNrEhg0fOg/ClX8U+LJ4LAnirczpe9dJlg
Date: Wed, 17 Oct 2012 13:04:47 +0000
Message-ID: 
References: 
	<507E7D5C02000078000A1DE6@nat28.tlf.novell.com>
	<1350464551.2460.24.camel@zakaz.uk.xensource.com>
	<507E93F302000078000A1E98@nat28.tlf.novell.com>
In-Reply-To: <507E93F302000078000A1E98@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC829233535CED3SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: xen-devel ,
	Ian Jackson ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-i386-qemuu-rhel6hvm-amd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC829233535CED3SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Jan Beulich wrote:
>>>> On 17.10.12 at 11:02, Ian Campbell  wrote:
>> On Wed, 2012-10-17 at 08:41 +0100, Jan Beulich wrote:
>>> So I just now realized that a similar change was already done
>>> by 23736:31683aa4bfb3 and then reverted by
>>> 23760:ae10d7804168. Nothing was done subsequently to
>>> address the actual problem(s). It is quite obvious that the more
>>> relaxed check uncovers other bugs in the ERST code, yet looking
>>> at the Linux history of the corresponding file doesn't reveal any
>>> fix the lack of which would explain an outright hang (rather than
>>> a crash, as I would expect to be the result of e.g. the missing
>>> ioremap()-s added by 0bbba38a61283a55f2061ab3e0910c572d19f462.
>>>=20
>>> Most of the other changes are cosmetic or pstore related, so I
>>> wonder whether instead of reverting again we should try pulling
>>> in this one extra fix.
>>=20
>> Worth a go. I assume this issue isn't related to the typo you found
>> this morning?
>=20
> I didn't find any typo; the original author of the Linux side patch
> pointed out a typo in the commit message (which was copied
> verbatim from the Linux side).
>=20
>>> If reverting is preferred (or turns out necessary if that second
>>> fix doesn't help), we should settle on the disposition of the whole
>>> APEI/ERST code, as my conclusion is that it is pretty much
>>> unmaintained since its original contribution over two years ago.
>>=20
>> If we revert we should leave a big fat comment pointing to this
>> and/or the previous discussion to stop the next guy doing the same
>> thing.=20
>=20
> We should rather decide whether this should get fixed, or the
> code ripped out (decision mainly depending on the original
> contributer - Intel - being willing to fix the code).

I just checked the history.

1. It firstly checked in as c/s 22052 --> at that time it tested at an old =
intel platform (I forget type);
2. then it updated with c/s 23736 --> since when our QA tested at a newer i=
ntel platform, it cannot pass erst_check_table, after debug we found the ne=
wer intel platform bios has different header length definiation at its ERST=
 table, so we allow both size table work;
3. then it reverted with c/s 23760 --> since when test at an AMD platform b=
y Critix (see attached, complete test-amd64-i386-xl), it will hang, so Keir=
 revert it.

c/s 22052 and 23736 were tested at 2 intel platforms, but we have no way to=
 test at AMD platform. So the problem is, how to debug&fix it?

Thanks,
Jinsong=

--_002_DE8DF0795D48FD4CA783C40EC829233535CED3SHSMSX101ccrcorpi_
Content-Type: message/rfc822
Content-Disposition: attachment;
	creation-date="Wed, 17 Oct 2012 13:04:46 GMT";
	modification-date="Wed, 17 Oct 2012 13:04:46 GMT"

Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
 SHSMSX602.ccr.corp.intel.com (10.239.4.104) with Microsoft SMTP Server (TLS)
 id 8.2.255.0; Tue, 9 Aug 2011 22:58:46 +0800
Received: from rrsmsx602.amr.corp.intel.com (10.31.0.33) by
 SHSMSX101.ccr.corp.intel.com (10.239.4.153) with Microsoft SMTP Server (TLS)
 id 14.1.323.3; Tue, 9 Aug 2011 22:58:46 +0800
Received: from azsmga001.ch.intel.com (10.2.17.19) by rrsmsx602-1.rr.intel.com
 (10.31.0.33) with Microsoft SMTP Server id 8.2.255.0; Tue, 9 Aug 2011
 08:58:44 -0600
Received: from azsmga101.ch.intel.com ([10.2.16.36])  by
 azsmga001-1.ch.intel.com with ESMTP; 09 Aug 2011 07:58:40 -0700
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM)
 ([62.200.22.115])  by mga03.intel.com with ESMTP; 09 Aug 2011 07:58:39 -0700
Received: from unknown (HELO LONPMAILMX01.citrite.net) ([10.30.203.162])  by
 LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 09 Aug 2011 14:58:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
 smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id 8.3.137.0;
 Tue, 9 Aug 2011 15:58:37 +0100
Received: from [10.80.2.22] (helo=mariner.uk.xensource.com ident=Debian-exim)
	by norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
 )	id 1QqnlN-0000or-QI; Tue, 09 Aug 2011 14:58:37
 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.69)
	(envelope-from )	id 1QqnlN-0005IP-OA; Tue, 09 Aug
 2011 15:58:37 +0100
From: Ian Jackson 
To: Keir Fraser 
CC: Jan Beulich , Stefano Stabellini
	, "xen-devel@lists.xensource.com"
	, "Liu, Jinsong" ,
	Jeremy Fitzhardinge 
Subject: Re: [Xen-devel] [xen-unstable bisection] complete test-amd64-i386-xl
Thread-Topic: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-i386-xl
Thread-Index: AcxWpNbpQT/v8LNISfqL/zQ9xkV3CA==
Date: Tue, 9 Aug 2011 14:58:37 +0000
Message-ID: <20033.19229.741344.489650@mariner.uk.xensource.com>
References: <20033.7748.282915.819692@mariner.uk.xensource.com>
	
In-Reply-To: 
Content-Language: en-US
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-AuthSource: rrsmsx602.amr.corp.intel.com
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ironport-av: E=Sophos;i="4.67,343,1309737600";    d="scan'208";a="7180551"
x-ironport-anti-spam-filtered: true
x-ironport-anti-spam-result: AhMBADBJQU4+yBZzmWdsb2JhbABCp08BAQEBAQgLCwcUJYFAAQEFJxMZJhALNhA8GwYOh3S+eYZGBJgOCRWLRQ
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Keir Fraser writes ("Re: [Xen-devel] [xen-unstable bisection] complete test=
-amd64-i386-xl"):
> Does reverting just the change to erst_check_table() fix the regression o=
n
> the affected test boxes? What about the similar-looking boot failure that
> you see, Jeremy?

Indeed, reverting xen/drivers/acpi/apei/erst.c, ie the change to
erst_check_table, seems to fix it.  That is,

  23736:31683aa4bfb3 "acpi: Add support for old and new bios erst, ..."
   +
  23742:50ddc200a60c "fix regression from c/s 23735:537918f518ee"

fails.  That plus the diff below boots happily.

Ian.

diff --git a/xen/drivers/acpi/apei/erst.c b/xen/drivers/acpi/apei/erst.c
index e012cd3..eb666a6 100644
--- a/xen/drivers/acpi/apei/erst.c
+++ b/xen/drivers/acpi/apei/erst.c
@@ -715,13 +715,7 @@ int erst_clear(u64 record_id)
=20
 static int __init erst_check_table(struct acpi_table_erst *erst_tab)
 {
-	/*
-	 * Some old BIOSes include the ACPI standard header in the ERST header
-	 * length; new BIOSes do not. Our check allows for both methods.
-	 */
-	if ((erst_tab->header_length !=3D
-	    (sizeof(struct acpi_table_erst) - sizeof(erst_tab->header)))
-	    && (erst_tab->header_length !=3D sizeof(struct acpi_table_erst)))
+	if (erst_tab->header_length !=3D sizeof(struct acpi_table_erst))
 		return -EINVAL;
 	if (erst_tab->header.length < sizeof(struct acpi_table_erst))
 		return -EINVAL;

--_002_DE8DF0795D48FD4CA783C40EC829233535CED3SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC829233535CED3SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Wed Oct 17 13:11:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 13:11:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOTOr-0002Jd-Hd; Wed, 17 Oct 2012 13:11:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOTOq-0002JX-3q
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 13:11:04 +0000
Received: from [85.158.139.83:21817] by server-1.bemta-5.messagelabs.com id
	24/0A-21640-76EAE705; Wed, 17 Oct 2012 13:11:03 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1350479459!30743341!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18321 invoked from network); 17 Oct 2012 13:10:59 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-4.tower-182.messagelabs.com with SMTP;
	17 Oct 2012 13:10:59 -0000
Received: from p5b2e42c0.dip.t-dialin.net ([91.46.66.192] helo=canonical.com)
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71)
	(envelope-from )
	id 1TOTOk-0007hW-3S; Wed, 17 Oct 2012 13:10:58 +0000
From: Stefan Bader 
To: xen-devel@lists.xen.org
Date: Wed, 17 Oct 2012 15:10:56 +0200
Message-Id: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
X-Mailer: git-send-email 1.7.9.5
Cc: Konrad Rzeszutek Wilk 
Subject: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I am currently looking at a bug report[1] which is happening when
a Xen PVM guest with multiple VCPUs is running a high IO database
load (a test script is available in the bug report).

In experimenting it seems that this happens (or is getting more
likely) when the number of VCPUs is 8 or higher (though I have
not tried 6, only 2 and 4), having autogroup enabled seems to
make it more likely, too (at some point thought it would actually
prevent it but we were wrong) and pv spinlocks enabled.
It has happened with older (3.4.3) and newer (4.1.2) versions of
Xen as a host and with 3.2 and 3.5 kernels as guests.

The pv spinlock assumption I will try to get re-verified by asking
to reproduce under a real load with a kernel that just disables
that. However, the dumps I am looking at really do look odd there.

The first dump I looked at had the spinlock of runqueue[0] being
placed into the per-cpu lock_spinners variable for cpu#0 and
cpu#7 (doing my tests with 8 VCPUs). So apparently both cpus were
waiting on the slow path for it to become free. Though actually
it was free! Now, here is one issue I have in understanding the
dump: the back traces produced in crash are in the normal form
not showing any cpu in the poll_irq HV call. Only when using
the form that uses the last known stack location and displays
all text symols found will get close for cpu#7. cpu#0 still does
not seem to be anywhere close. This could be a problem with crash,
or with the way PVM works, I am not sure.

Anyway, from what I could take from that situation, it seemed that
cpu#1 (that one had soft lockup warnings in the log) seemed to try
to do a wake_up on the task that just seemed to have done an io
schedule on cpu#7 (but the waitqueue_head spinlock is currently
locked). cpu#7 tries to get the runqueue[0] spinlock to do an idle
migration (though the lock currently is free). So I guessed that
maybe cpu#0 was just woken for the free lock but has not grabbed
it yet.

>From there I wondered whether something that acquires a spinlock
usually more than the quick path timeout (and this causes new
lockers to go into the slow path), could cause a stall on a high
numbered cpu when the lock is contented (as the search and
signalling is only done for the first waiter starting from 0).
That lead to below patch. The good thing about it, it does not
break things immediately, the bad thing, it does not help with
the problem. :/

The interesting thing when looking at a second dump, taken with
a testkernel using the patch below, was that again 2 cpus seemed
to spin slow on a lock that was free in the dump. And again at
least one did not seem to be doing anything spinlock related
(anymore?).
One other detail (but that could be just incidence as well) was
that in unmodified kernel I usually would end up with soft
lockup messages, with the patched kernel, that was a stall
detected by rcu_bh (0 and 1 stalled, detected by 3).

Now I am a bit confused and wonder about some basic things:
1. When a cpu goes into the slow lock path and into the poll_irq,
   shouldn't I expect this one to be in hypercall_page in the
   dump?
2. When does the whole handling for interrupted spinlock wait
   apply? I assume only for a spinlock taken without irqs
   disabled and then trying to acquire another one in an
   interrupt handler. Is that correct?
3. Not really related but I just stumbled over it:
   In xen_spin_trylock: "asm("xchgb %b0,%1"...)
   What does the "b" part of %b0 do? I thought xchgb already
   would say it is a byte value...

But putting aside those questions, the fact that two times
there was two cpus waiting on the same lock which from the
lock count (=0) was free seems a bit too much of a coincidence.
Oh and the spinners count in the lock was 2 as one would
expect.

struct rq {
  lock = {
    raw_lock = {
      {
        head_tail = 512, 
        tickets = {
          head = 0 '\000', 
          tail = 2 '\002'
        }
      }
    }
  }, 
  nr_running = 1,
  ...
}

I really don't know how this happens. Especially cpu#0 seems at
least past the wakeup and should have removed itself from the
spinners list...
 
-Stefan

[1] http://bugs.launchpad.net/bugs/1011792

>From 635a4e101ccbc9a324c8000f7e264ed4e646592c Mon Sep 17 00:00:00 2001
From: Stefan Bader 
Date: Tue, 16 Oct 2012 17:46:09 +0200
Subject: [PATCH] xen/spinlocks: Make wakeup fairer

Instead of sending the IPI signalling the free lock to the first
online CPU found waiting for it, start the search from the CPU
that had the lock last.

Signed-off-by: Stefan Bader 
---
 arch/x86/xen/spinlock.c |   22 ++++++++++++++--------
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
index d69cc6c..8b86efb 100644
--- a/arch/x86/xen/spinlock.c
+++ b/arch/x86/xen/spinlock.c
@@ -320,17 +320,23 @@ static void xen_spin_lock_flags(struct arch_spinlock *lock, unsigned long flags)
 static noinline void xen_spin_unlock_slow(struct xen_spinlock *xl)
 {
 	int cpu;
+	int this_cpu = smp_processor_id();
 
 	ADD_STATS(released_slow, 1);
 
-	for_each_online_cpu(cpu) {
-		/* XXX should mix up next cpu selection */
-		if (per_cpu(lock_spinners, cpu) == xl) {
-			ADD_STATS(released_slow_kicked, 1);
-			xen_send_IPI_one(cpu, XEN_SPIN_UNLOCK_VECTOR);
-			break;
-		}
-	}
+	cpu = cpumask_next(this_cpu, cpu_online_mask);
+	do {
+		if (cpu < nr_cpu_ids) {
+			if (per_cpu(lock_spinners, cpu) == xl) {
+				ADD_STATS(released_slow_kicked, 1);
+				xen_send_IPI_one(cpu, XEN_SPIN_UNLOCK_VECTOR);
+				break;
+			}
+		} else
+			cpu = -1;
+
+		cpu = cpumask_next(cpu, cpu_online_mask);
+	} while (cpu != this_cpu);
 }
 
 static void xen_spin_unlock(struct arch_spinlock *lock)
-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 13:11:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 13:11:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOTOr-0002Jd-Hd; Wed, 17 Oct 2012 13:11:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOTOq-0002JX-3q
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 13:11:04 +0000
Received: from [85.158.139.83:21817] by server-1.bemta-5.messagelabs.com id
	24/0A-21640-76EAE705; Wed, 17 Oct 2012 13:11:03 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1350479459!30743341!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18321 invoked from network); 17 Oct 2012 13:10:59 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-4.tower-182.messagelabs.com with SMTP;
	17 Oct 2012 13:10:59 -0000
Received: from p5b2e42c0.dip.t-dialin.net ([91.46.66.192] helo=canonical.com)
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71)
	(envelope-from )
	id 1TOTOk-0007hW-3S; Wed, 17 Oct 2012 13:10:58 +0000
From: Stefan Bader 
To: xen-devel@lists.xen.org
Date: Wed, 17 Oct 2012 15:10:56 +0200
Message-Id: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
X-Mailer: git-send-email 1.7.9.5
Cc: Konrad Rzeszutek Wilk 
Subject: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I am currently looking at a bug report[1] which is happening when
a Xen PVM guest with multiple VCPUs is running a high IO database
load (a test script is available in the bug report).

In experimenting it seems that this happens (or is getting more
likely) when the number of VCPUs is 8 or higher (though I have
not tried 6, only 2 and 4), having autogroup enabled seems to
make it more likely, too (at some point thought it would actually
prevent it but we were wrong) and pv spinlocks enabled.
It has happened with older (3.4.3) and newer (4.1.2) versions of
Xen as a host and with 3.2 and 3.5 kernels as guests.

The pv spinlock assumption I will try to get re-verified by asking
to reproduce under a real load with a kernel that just disables
that. However, the dumps I am looking at really do look odd there.

The first dump I looked at had the spinlock of runqueue[0] being
placed into the per-cpu lock_spinners variable for cpu#0 and
cpu#7 (doing my tests with 8 VCPUs). So apparently both cpus were
waiting on the slow path for it to become free. Though actually
it was free! Now, here is one issue I have in understanding the
dump: the back traces produced in crash are in the normal form
not showing any cpu in the poll_irq HV call. Only when using
the form that uses the last known stack location and displays
all text symols found will get close for cpu#7. cpu#0 still does
not seem to be anywhere close. This could be a problem with crash,
or with the way PVM works, I am not sure.

Anyway, from what I could take from that situation, it seemed that
cpu#1 (that one had soft lockup warnings in the log) seemed to try
to do a wake_up on the task that just seemed to have done an io
schedule on cpu#7 (but the waitqueue_head spinlock is currently
locked). cpu#7 tries to get the runqueue[0] spinlock to do an idle
migration (though the lock currently is free). So I guessed that
maybe cpu#0 was just woken for the free lock but has not grabbed
it yet.

>From there I wondered whether something that acquires a spinlock
usually more than the quick path timeout (and this causes new
lockers to go into the slow path), could cause a stall on a high
numbered cpu when the lock is contented (as the search and
signalling is only done for the first waiter starting from 0).
That lead to below patch. The good thing about it, it does not
break things immediately, the bad thing, it does not help with
the problem. :/

The interesting thing when looking at a second dump, taken with
a testkernel using the patch below, was that again 2 cpus seemed
to spin slow on a lock that was free in the dump. And again at
least one did not seem to be doing anything spinlock related
(anymore?).
One other detail (but that could be just incidence as well) was
that in unmodified kernel I usually would end up with soft
lockup messages, with the patched kernel, that was a stall
detected by rcu_bh (0 and 1 stalled, detected by 3).

Now I am a bit confused and wonder about some basic things:
1. When a cpu goes into the slow lock path and into the poll_irq,
   shouldn't I expect this one to be in hypercall_page in the
   dump?
2. When does the whole handling for interrupted spinlock wait
   apply? I assume only for a spinlock taken without irqs
   disabled and then trying to acquire another one in an
   interrupt handler. Is that correct?
3. Not really related but I just stumbled over it:
   In xen_spin_trylock: "asm("xchgb %b0,%1"...)
   What does the "b" part of %b0 do? I thought xchgb already
   would say it is a byte value...

But putting aside those questions, the fact that two times
there was two cpus waiting on the same lock which from the
lock count (=0) was free seems a bit too much of a coincidence.
Oh and the spinners count in the lock was 2 as one would
expect.

struct rq {
  lock = {
    raw_lock = {
      {
        head_tail = 512, 
        tickets = {
          head = 0 '\000', 
          tail = 2 '\002'
        }
      }
    }
  }, 
  nr_running = 1,
  ...
}

I really don't know how this happens. Especially cpu#0 seems at
least past the wakeup and should have removed itself from the
spinners list...
 
-Stefan

[1] http://bugs.launchpad.net/bugs/1011792

>From 635a4e101ccbc9a324c8000f7e264ed4e646592c Mon Sep 17 00:00:00 2001
From: Stefan Bader 
Date: Tue, 16 Oct 2012 17:46:09 +0200
Subject: [PATCH] xen/spinlocks: Make wakeup fairer

Instead of sending the IPI signalling the free lock to the first
online CPU found waiting for it, start the search from the CPU
that had the lock last.

Signed-off-by: Stefan Bader 
---
 arch/x86/xen/spinlock.c |   22 ++++++++++++++--------
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
index d69cc6c..8b86efb 100644
--- a/arch/x86/xen/spinlock.c
+++ b/arch/x86/xen/spinlock.c
@@ -320,17 +320,23 @@ static void xen_spin_lock_flags(struct arch_spinlock *lock, unsigned long flags)
 static noinline void xen_spin_unlock_slow(struct xen_spinlock *xl)
 {
 	int cpu;
+	int this_cpu = smp_processor_id();
 
 	ADD_STATS(released_slow, 1);
 
-	for_each_online_cpu(cpu) {
-		/* XXX should mix up next cpu selection */
-		if (per_cpu(lock_spinners, cpu) == xl) {
-			ADD_STATS(released_slow_kicked, 1);
-			xen_send_IPI_one(cpu, XEN_SPIN_UNLOCK_VECTOR);
-			break;
-		}
-	}
+	cpu = cpumask_next(this_cpu, cpu_online_mask);
+	do {
+		if (cpu < nr_cpu_ids) {
+			if (per_cpu(lock_spinners, cpu) == xl) {
+				ADD_STATS(released_slow_kicked, 1);
+				xen_send_IPI_one(cpu, XEN_SPIN_UNLOCK_VECTOR);
+				break;
+			}
+		} else
+			cpu = -1;
+
+		cpu = cpumask_next(cpu, cpu_online_mask);
+	} while (cpu != this_cpu);
 }
 
 static void xen_spin_unlock(struct arch_spinlock *lock)
-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 13:36:28 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 13:36:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOTnA-0002nN-Gb; Wed, 17 Oct 2012 13:36:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOTn9-0002nE-1N
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 13:36:11 +0000
Received: from [85.158.137.99:61339] by server-8.bemta-3.messagelabs.com id
	B4/AC-10525-A44BE705; Wed, 17 Oct 2012 13:36:10 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1350480967!21831547!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzcwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23476 invoked from network); 17 Oct 2012 13:36:09 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 13:36:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,600,1344211200"; d="scan'208";a="41505030"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 13:36:07 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 09:36:06 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TOTgx-00084L-95;
	Wed, 17 Oct 2012 14:29:47 +0100
From: David Vrabel 
To: xen-devel@lists.xen.org
Date: Wed, 17 Oct 2012 14:29:40 +0100
Message-ID: <1350480580-4844-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Frediano Ziglio ,
	David Vrabel , stable@vger.kernel.org,
	Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCHv2] xen/x86: don't corrupt %eip when returning
	from a signal handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel 

In 32 bit guests, if a userspace process has %eax == -ERESTARTSYS
(-512) or -ERESTARTNOINTR (-513) when it is interrupted by an event
/and/ the process has a pending signal then %eip (and %eax) are
corrupted when returning to the main process after handling the
signal.  The application may then crash with SIGSEGV or a SIGILL or it
may have subtly incorrect behaviour (depending on what instruction it
returned to).

The occurs because handle_signal() is incorrectly thinking that there
is a system call that needs to restarted so it adjusts %eip and %eax
to re-execute the system call instruction (even though user space had
not done a system call).

If %eax == -514 (-ERESTARTNOHAND (-514) or -ERESTART_RESTARTBLOCK
(-516) then handle_signal() only corrupted %eax (by setting it to
-EINTR).  This may cause the application to crash or have incorrect
behaviour.

handle_signal() assumes that regs->orig_ax >= 0 means a system call so
any kernel entry point that is not for a system call must push a
negative value for orig_ax.  For example, for physical interrupts on
bare metal the inverse of the vector is pushed and page_fault() sets
regs->orig_ax to -1, overwriting the hardware provided error code.

xen_hypervisor_callback() was incorrectly pushing 0 for orig_ax
instead of -1.

Classic Xen kernels pushed %eax which works as %eax cannot be both
non-negative and -RESTARTSYS (etc.), but using -1 is consistent with
other non-system call entry points.

There were similar bugs in xen_failsafe_callback(), if the fault was
corrected and normal return path was used.  64 bit guests would push 0
which is broken.  32 bit guests would push %eax which is safe (see
previous paragraph), but for consistency this is also changed to -1.

Signed-off-by: David Vrabel 
Acked-by: Jan Beulich 
Acked-by: Ian Campbell 
Cc: stable@vger.kernel.org
---
 arch/x86/kernel/entry_32.S |    4 ++--
 arch/x86/kernel/entry_64.S |    2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
index 2c63407..6a19e66 100644
--- a/arch/x86/kernel/entry_32.S
+++ b/arch/x86/kernel/entry_32.S
@@ -1042,7 +1042,7 @@ ENTRY(xen_sysenter_target)
 
 ENTRY(xen_hypervisor_callback)
 	CFI_STARTPROC
-	pushl_cfi $0
+	pushl_cfi $-1 /* orig_ax = -1 => not a system call */
 	SAVE_ALL
 	TRACE_IRQS_OFF
 
@@ -1078,7 +1078,7 @@ ENDPROC(xen_hypervisor_callback)
 # We distinguish between categories by maintaining a status value in EAX.
 ENTRY(xen_failsafe_callback)
 	CFI_STARTPROC
-	pushl_cfi %eax
+	pushl_cfi $-1  /* orig_ax = -1 => not a system call */
 	movl $1,%eax
 1:	mov 4(%esp),%ds
 2:	mov 8(%esp),%es
diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index cdc790c..430b1fc 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -1451,7 +1451,7 @@ ENTRY(xen_failsafe_callback)
 	CFI_RESTORE r11
 	addq $0x30,%rsp
 	CFI_ADJUST_CFA_OFFSET -0x30
-	pushq_cfi $0
+	pushq_cfi $-1 /* orig_ax = -1 => not a system call */
 	SAVE_ALL
 	jmp error_exit
 	CFI_ENDPROC
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 13:36:28 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 13:36:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOTnA-0002nN-Gb; Wed, 17 Oct 2012 13:36:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOTn9-0002nE-1N
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 13:36:11 +0000
Received: from [85.158.137.99:61339] by server-8.bemta-3.messagelabs.com id
	B4/AC-10525-A44BE705; Wed, 17 Oct 2012 13:36:10 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1350480967!21831547!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzcwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23476 invoked from network); 17 Oct 2012 13:36:09 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 13:36:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,600,1344211200"; d="scan'208";a="41505030"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 13:36:07 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 09:36:06 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TOTgx-00084L-95;
	Wed, 17 Oct 2012 14:29:47 +0100
From: David Vrabel 
To: xen-devel@lists.xen.org
Date: Wed, 17 Oct 2012 14:29:40 +0100
Message-ID: <1350480580-4844-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Frediano Ziglio ,
	David Vrabel , stable@vger.kernel.org,
	Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCHv2] xen/x86: don't corrupt %eip when returning
	from a signal handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel 

In 32 bit guests, if a userspace process has %eax == -ERESTARTSYS
(-512) or -ERESTARTNOINTR (-513) when it is interrupted by an event
/and/ the process has a pending signal then %eip (and %eax) are
corrupted when returning to the main process after handling the
signal.  The application may then crash with SIGSEGV or a SIGILL or it
may have subtly incorrect behaviour (depending on what instruction it
returned to).

The occurs because handle_signal() is incorrectly thinking that there
is a system call that needs to restarted so it adjusts %eip and %eax
to re-execute the system call instruction (even though user space had
not done a system call).

If %eax == -514 (-ERESTARTNOHAND (-514) or -ERESTART_RESTARTBLOCK
(-516) then handle_signal() only corrupted %eax (by setting it to
-EINTR).  This may cause the application to crash or have incorrect
behaviour.

handle_signal() assumes that regs->orig_ax >= 0 means a system call so
any kernel entry point that is not for a system call must push a
negative value for orig_ax.  For example, for physical interrupts on
bare metal the inverse of the vector is pushed and page_fault() sets
regs->orig_ax to -1, overwriting the hardware provided error code.

xen_hypervisor_callback() was incorrectly pushing 0 for orig_ax
instead of -1.

Classic Xen kernels pushed %eax which works as %eax cannot be both
non-negative and -RESTARTSYS (etc.), but using -1 is consistent with
other non-system call entry points.

There were similar bugs in xen_failsafe_callback(), if the fault was
corrected and normal return path was used.  64 bit guests would push 0
which is broken.  32 bit guests would push %eax which is safe (see
previous paragraph), but for consistency this is also changed to -1.

Signed-off-by: David Vrabel 
Acked-by: Jan Beulich 
Acked-by: Ian Campbell 
Cc: stable@vger.kernel.org
---
 arch/x86/kernel/entry_32.S |    4 ++--
 arch/x86/kernel/entry_64.S |    2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
index 2c63407..6a19e66 100644
--- a/arch/x86/kernel/entry_32.S
+++ b/arch/x86/kernel/entry_32.S
@@ -1042,7 +1042,7 @@ ENTRY(xen_sysenter_target)
 
 ENTRY(xen_hypervisor_callback)
 	CFI_STARTPROC
-	pushl_cfi $0
+	pushl_cfi $-1 /* orig_ax = -1 => not a system call */
 	SAVE_ALL
 	TRACE_IRQS_OFF
 
@@ -1078,7 +1078,7 @@ ENDPROC(xen_hypervisor_callback)
 # We distinguish between categories by maintaining a status value in EAX.
 ENTRY(xen_failsafe_callback)
 	CFI_STARTPROC
-	pushl_cfi %eax
+	pushl_cfi $-1  /* orig_ax = -1 => not a system call */
 	movl $1,%eax
 1:	mov 4(%esp),%ds
 2:	mov 8(%esp),%es
diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index cdc790c..430b1fc 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -1451,7 +1451,7 @@ ENTRY(xen_failsafe_callback)
 	CFI_RESTORE r11
 	addq $0x30,%rsp
 	CFI_ADJUST_CFA_OFFSET -0x30
-	pushq_cfi $0
+	pushq_cfi $-1 /* orig_ax = -1 => not a system call */
 	SAVE_ALL
 	jmp error_exit
 	CFI_ENDPROC
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 13:36:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 13:36:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOTnA-0002nU-SV; Wed, 17 Oct 2012 13:36:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOTn9-0002nE-K1
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 13:36:11 +0000
Received: from [85.158.137.99:35093] by server-8.bemta-3.messagelabs.com id
	5C/AC-10525-B44BE705; Wed, 17 Oct 2012 13:36:11 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1350480967!21831547!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzcwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23512 invoked from network); 17 Oct 2012 13:36:09 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 13:36:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,600,1344211200"; d="scan'208";a="41505057"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 13:36:09 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 09:36:08 -0400
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TOTfh-00083G-6Y;
	Wed, 17 Oct 2012 14:28:29 +0100
Message-ID: <507EB27D.8050308@citrix.com>
Date: Wed, 17 Oct 2012 14:28:29 +0100
From: Andrew Cooper 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org, stefan.bader@canonical.com, 
	Konrad Rzeszutek Wilk 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
In-Reply-To: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
X-Enigmail-Version: 1.4.5
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/10/12 14:10, Stefan Bader wrote:
> I am currently looking at a bug report[1] which is happening when
> a Xen PVM guest with multiple VCPUs is running a high IO database
> load (a test script is available in the bug report).
>
> In experimenting it seems that this happens (or is getting more
> likely) when the number of VCPUs is 8 or higher (though I have
> not tried 6, only 2 and 4), having autogroup enabled seems to
> make it more likely, too (at some point thought it would actually
> prevent it but we were wrong) and pv spinlocks enabled.
> It has happened with older (3.4.3) and newer (4.1.2) versions of
> Xen as a host and with 3.2 and 3.5 kernels as guests.
>
> The pv spinlock assumption I will try to get re-verified by asking
> to reproduce under a real load with a kernel that just disables
> that. However, the dumps I am looking at really do look odd there.
>
> The first dump I looked at had the spinlock of runqueue[0] being
> placed into the per-cpu lock_spinners variable for cpu#0 and
> cpu#7 (doing my tests with 8 VCPUs). So apparently both cpus were
> waiting on the slow path for it to become free. Though actually
> it was free! Now, here is one issue I have in understanding the
> dump: the back traces produced in crash are in the normal form
> not showing any cpu in the poll_irq HV call. Only when using
> the form that uses the last known stack location and displays
> all text symols found will get close for cpu#7. cpu#0 still does
> not seem to be anywhere close. This could be a problem with crash,
> or with the way PVM works, I am not sure.
>
> Anyway, from what I could take from that situation, it seemed that
> cpu#1 (that one had soft lockup warnings in the log) seemed to try
> to do a wake_up on the task that just seemed to have done an io
> schedule on cpu#7 (but the waitqueue_head spinlock is currently
> locked). cpu#7 tries to get the runqueue[0] spinlock to do an idle
> migration (though the lock currently is free). So I guessed that
> maybe cpu#0 was just woken for the free lock but has not grabbed
> it yet.
>
> From there I wondered whether something that acquires a spinlock
> usually more than the quick path timeout (and this causes new
> lockers to go into the slow path), could cause a stall on a high
> numbered cpu when the lock is contented (as the search and
> signalling is only done for the first waiter starting from 0).
> That lead to below patch. The good thing about it, it does not
> break things immediately, the bad thing, it does not help with
> the problem. :/
>
> The interesting thing when looking at a second dump, taken with
> a testkernel using the patch below, was that again 2 cpus seemed
> to spin slow on a lock that was free in the dump. And again at
> least one did not seem to be doing anything spinlock related
> (anymore?).
> One other detail (but that could be just incidence as well) was
> that in unmodified kernel I usually would end up with soft
> lockup messages, with the patched kernel, that was a stall
> detected by rcu_bh (0 and 1 stalled, detected by 3).
>
> Now I am a bit confused and wonder about some basic things:
> 1. When a cpu goes into the slow lock path and into the poll_irq,
>    shouldn't I expect this one to be in hypercall_page in the
>    dump?
> 2. When does the whole handling for interrupted spinlock wait
>    apply? I assume only for a spinlock taken without irqs
>    disabled and then trying to acquire another one in an
>    interrupt handler. Is that correct?
> 3. Not really related but I just stumbled over it:
>    In xen_spin_trylock: "asm("xchgb %b0,%1"...)
>    What does the "b" part of %b0 do? I thought xchgb already
>    would say it is a byte value...
>
> But putting aside those questions, the fact that two times
> there was two cpus waiting on the same lock which from the
> lock count (=0) was free seems a bit too much of a coincidence.
> Oh and the spinners count in the lock was 2 as one would
> expect.
>
> struct rq {
>   lock = {
>     raw_lock = {
>       {
>         head_tail = 512, 
>         tickets = {
>           head = 0 '\000', 
>           tail = 2 '\002'
>         }
>       }
>     }
>   }, 
>   nr_running = 1,
>   ...
> }
>
> I really don't know how this happens. Especially cpu#0 seems at
> least past the wakeup and should have removed itself from the
> spinners list...
>  
> -Stefan

We (Citrix) have an outstanding bug, on 2.6.32 classic, which we have
never managed to get to the bottom of (because of inability to reliably
reproduce), which might be related.

In our case, certain processes were locking up, and it turned out that
the kernel was issuing SCHOP_poll hypercalls (same the stack trace on
your launchpad ticket) on its own spinlock IPI event channel
(understandable, as its a spinlock), but with the event channel masked,
so it would never wake up from the poll.

Can you reliably reproduce the issue? and if so, would it be possible to
capture hypervisor debug keys q and e when the badness happens?  This
would clearly show if our bugs are related or not

Our repro case took about a month to reproduce, and unfortunately
turning lockdep on has appeared to fix the problem.

~Andrew

>
> [1] http://bugs.launchpad.net/bugs/1011792
>
> From 635a4e101ccbc9a324c8000f7e264ed4e646592c Mon Sep 17 00:00:00 2001
> From: Stefan Bader 
> Date: Tue, 16 Oct 2012 17:46:09 +0200
> Subject: [PATCH] xen/spinlocks: Make wakeup fairer
>
> Instead of sending the IPI signalling the free lock to the first
> online CPU found waiting for it, start the search from the CPU
> that had the lock last.
>
> Signed-off-by: Stefan Bader 
> ---
>  arch/x86/xen/spinlock.c |   22 ++++++++++++++--------
>  1 file changed, 14 insertions(+), 8 deletions(-)
>
> diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
> index d69cc6c..8b86efb 100644
> --- a/arch/x86/xen/spinlock.c
> +++ b/arch/x86/xen/spinlock.c
> @@ -320,17 +320,23 @@ static void xen_spin_lock_flags(struct arch_spinlock *lock, unsigned long flags)
>  static noinline void xen_spin_unlock_slow(struct xen_spinlock *xl)
>  {
>  	int cpu;
> +	int this_cpu = smp_processor_id();
>  
>  	ADD_STATS(released_slow, 1);
>  
> -	for_each_online_cpu(cpu) {
> -		/* XXX should mix up next cpu selection */
> -		if (per_cpu(lock_spinners, cpu) == xl) {
> -			ADD_STATS(released_slow_kicked, 1);
> -			xen_send_IPI_one(cpu, XEN_SPIN_UNLOCK_VECTOR);
> -			break;
> -		}
> -	}
> +	cpu = cpumask_next(this_cpu, cpu_online_mask);
> +	do {
> +		if (cpu < nr_cpu_ids) {
> +			if (per_cpu(lock_spinners, cpu) == xl) {
> +				ADD_STATS(released_slow_kicked, 1);
> +				xen_send_IPI_one(cpu, XEN_SPIN_UNLOCK_VECTOR);
> +				break;
> +			}
> +		} else
> +			cpu = -1;
> +
> +		cpu = cpumask_next(cpu, cpu_online_mask);
> +	} while (cpu != this_cpu);
>  }
>  
>  static void xen_spin_unlock(struct arch_spinlock *lock)

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 13:36:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 13:36:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOTnA-0002nU-SV; Wed, 17 Oct 2012 13:36:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOTn9-0002nE-K1
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 13:36:11 +0000
Received: from [85.158.137.99:35093] by server-8.bemta-3.messagelabs.com id
	5C/AC-10525-B44BE705; Wed, 17 Oct 2012 13:36:11 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1350480967!21831547!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzcwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23512 invoked from network); 17 Oct 2012 13:36:09 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 13:36:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,600,1344211200"; d="scan'208";a="41505057"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 13:36:09 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 09:36:08 -0400
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TOTfh-00083G-6Y;
	Wed, 17 Oct 2012 14:28:29 +0100
Message-ID: <507EB27D.8050308@citrix.com>
Date: Wed, 17 Oct 2012 14:28:29 +0100
From: Andrew Cooper 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org, stefan.bader@canonical.com, 
	Konrad Rzeszutek Wilk 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
In-Reply-To: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
X-Enigmail-Version: 1.4.5
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/10/12 14:10, Stefan Bader wrote:
> I am currently looking at a bug report[1] which is happening when
> a Xen PVM guest with multiple VCPUs is running a high IO database
> load (a test script is available in the bug report).
>
> In experimenting it seems that this happens (or is getting more
> likely) when the number of VCPUs is 8 or higher (though I have
> not tried 6, only 2 and 4), having autogroup enabled seems to
> make it more likely, too (at some point thought it would actually
> prevent it but we were wrong) and pv spinlocks enabled.
> It has happened with older (3.4.3) and newer (4.1.2) versions of
> Xen as a host and with 3.2 and 3.5 kernels as guests.
>
> The pv spinlock assumption I will try to get re-verified by asking
> to reproduce under a real load with a kernel that just disables
> that. However, the dumps I am looking at really do look odd there.
>
> The first dump I looked at had the spinlock of runqueue[0] being
> placed into the per-cpu lock_spinners variable for cpu#0 and
> cpu#7 (doing my tests with 8 VCPUs). So apparently both cpus were
> waiting on the slow path for it to become free. Though actually
> it was free! Now, here is one issue I have in understanding the
> dump: the back traces produced in crash are in the normal form
> not showing any cpu in the poll_irq HV call. Only when using
> the form that uses the last known stack location and displays
> all text symols found will get close for cpu#7. cpu#0 still does
> not seem to be anywhere close. This could be a problem with crash,
> or with the way PVM works, I am not sure.
>
> Anyway, from what I could take from that situation, it seemed that
> cpu#1 (that one had soft lockup warnings in the log) seemed to try
> to do a wake_up on the task that just seemed to have done an io
> schedule on cpu#7 (but the waitqueue_head spinlock is currently
> locked). cpu#7 tries to get the runqueue[0] spinlock to do an idle
> migration (though the lock currently is free). So I guessed that
> maybe cpu#0 was just woken for the free lock but has not grabbed
> it yet.
>
> From there I wondered whether something that acquires a spinlock
> usually more than the quick path timeout (and this causes new
> lockers to go into the slow path), could cause a stall on a high
> numbered cpu when the lock is contented (as the search and
> signalling is only done for the first waiter starting from 0).
> That lead to below patch. The good thing about it, it does not
> break things immediately, the bad thing, it does not help with
> the problem. :/
>
> The interesting thing when looking at a second dump, taken with
> a testkernel using the patch below, was that again 2 cpus seemed
> to spin slow on a lock that was free in the dump. And again at
> least one did not seem to be doing anything spinlock related
> (anymore?).
> One other detail (but that could be just incidence as well) was
> that in unmodified kernel I usually would end up with soft
> lockup messages, with the patched kernel, that was a stall
> detected by rcu_bh (0 and 1 stalled, detected by 3).
>
> Now I am a bit confused and wonder about some basic things:
> 1. When a cpu goes into the slow lock path and into the poll_irq,
>    shouldn't I expect this one to be in hypercall_page in the
>    dump?
> 2. When does the whole handling for interrupted spinlock wait
>    apply? I assume only for a spinlock taken without irqs
>    disabled and then trying to acquire another one in an
>    interrupt handler. Is that correct?
> 3. Not really related but I just stumbled over it:
>    In xen_spin_trylock: "asm("xchgb %b0,%1"...)
>    What does the "b" part of %b0 do? I thought xchgb already
>    would say it is a byte value...
>
> But putting aside those questions, the fact that two times
> there was two cpus waiting on the same lock which from the
> lock count (=0) was free seems a bit too much of a coincidence.
> Oh and the spinners count in the lock was 2 as one would
> expect.
>
> struct rq {
>   lock = {
>     raw_lock = {
>       {
>         head_tail = 512, 
>         tickets = {
>           head = 0 '\000', 
>           tail = 2 '\002'
>         }
>       }
>     }
>   }, 
>   nr_running = 1,
>   ...
> }
>
> I really don't know how this happens. Especially cpu#0 seems at
> least past the wakeup and should have removed itself from the
> spinners list...
>  
> -Stefan

We (Citrix) have an outstanding bug, on 2.6.32 classic, which we have
never managed to get to the bottom of (because of inability to reliably
reproduce), which might be related.

In our case, certain processes were locking up, and it turned out that
the kernel was issuing SCHOP_poll hypercalls (same the stack trace on
your launchpad ticket) on its own spinlock IPI event channel
(understandable, as its a spinlock), but with the event channel masked,
so it would never wake up from the poll.

Can you reliably reproduce the issue? and if so, would it be possible to
capture hypervisor debug keys q and e when the badness happens?  This
would clearly show if our bugs are related or not

Our repro case took about a month to reproduce, and unfortunately
turning lockdep on has appeared to fix the problem.

~Andrew

>
> [1] http://bugs.launchpad.net/bugs/1011792
>
> From 635a4e101ccbc9a324c8000f7e264ed4e646592c Mon Sep 17 00:00:00 2001
> From: Stefan Bader 
> Date: Tue, 16 Oct 2012 17:46:09 +0200
> Subject: [PATCH] xen/spinlocks: Make wakeup fairer
>
> Instead of sending the IPI signalling the free lock to the first
> online CPU found waiting for it, start the search from the CPU
> that had the lock last.
>
> Signed-off-by: Stefan Bader 
> ---
>  arch/x86/xen/spinlock.c |   22 ++++++++++++++--------
>  1 file changed, 14 insertions(+), 8 deletions(-)
>
> diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
> index d69cc6c..8b86efb 100644
> --- a/arch/x86/xen/spinlock.c
> +++ b/arch/x86/xen/spinlock.c
> @@ -320,17 +320,23 @@ static void xen_spin_lock_flags(struct arch_spinlock *lock, unsigned long flags)
>  static noinline void xen_spin_unlock_slow(struct xen_spinlock *xl)
>  {
>  	int cpu;
> +	int this_cpu = smp_processor_id();
>  
>  	ADD_STATS(released_slow, 1);
>  
> -	for_each_online_cpu(cpu) {
> -		/* XXX should mix up next cpu selection */
> -		if (per_cpu(lock_spinners, cpu) == xl) {
> -			ADD_STATS(released_slow_kicked, 1);
> -			xen_send_IPI_one(cpu, XEN_SPIN_UNLOCK_VECTOR);
> -			break;
> -		}
> -	}
> +	cpu = cpumask_next(this_cpu, cpu_online_mask);
> +	do {
> +		if (cpu < nr_cpu_ids) {
> +			if (per_cpu(lock_spinners, cpu) == xl) {
> +				ADD_STATS(released_slow_kicked, 1);
> +				xen_send_IPI_one(cpu, XEN_SPIN_UNLOCK_VECTOR);
> +				break;
> +			}
> +		} else
> +			cpu = -1;
> +
> +		cpu = cpumask_next(cpu, cpu_online_mask);
> +	} while (cpu != this_cpu);
>  }
>  
>  static void xen_spin_unlock(struct arch_spinlock *lock)

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 13:40:21 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 13:40:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOTqt-00033O-OE; Wed, 17 Oct 2012 13:40:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOTqs-00033G-Ju
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 13:40:02 +0000
Received: from [85.158.139.211:16546] by server-12.bemta-5.messagelabs.com id
	77/AC-26919-135BE705; Wed, 17 Oct 2012 13:40:01 +0000
X-Env-Sender: abb@gremwell.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1350481201!22654300!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17384 invoked from network); 17 Oct 2012 13:40:01 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 13:40:01 -0000
Received: by mail-bk0-f45.google.com with SMTP id jf3so3342584bkc.32
	for ; Wed, 17 Oct 2012 06:40:00 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:x-enigmail-version:content-type
	:content-transfer-encoding:x-gm-message-state;
	bh=fK7h7ZJaRaSmjk6gophYHGl06qUjJy+d1Lhg3ZIHK/U=;
	b=cjaMMnrwn7o3Gqma6lIEhC9FUsPQwd8+aCHNXWuAFH/NCm3FpfdVdOGzYVHrgb0QVR
	8BdIp2OhGjVgRH67yEpF6C94QStDwRlOdM9l9UIY4Fr/fEIsSSqRNbLXGVV1XREBQC0Z
	orU/29UG3Yd5RYYgb5/W5hVBTjgbFUYJYXgRHCPPDTKN0XuYlV7gPdBwqNvJZ6Cx2r8Q
	m76ohpuCJ97sevgXcpK050FiT6gBXOLfKMZJRN0tv8DI14hC21/Uhmln9bhqPozRPLHR
	qnmfFhYOyy+d6sG93RJRyt/RDHwc6/LxfX75cLHUWFzwM3aSV2aalqJ+257ievkrcYjI
	/RfQ==
Received: by 10.204.145.88 with SMTP id c24mr4596427bkv.106.1350481200692;
	Wed, 17 Oct 2012 06:40:00 -0700 (PDT)
Received: from [192.168.1.120] (253.2-66-87.adsl-static.isp.belgacom.be.
	[87.66.2.253])
	by mx.google.com with ESMTPS id e3sm12907492bks.7.2012.10.17.06.39.59
	(version=SSLv3 cipher=OTHER); Wed, 17 Oct 2012 06:39:59 -0700 (PDT)
Message-ID: <507EB52D.1040209@gremwell.com>
Date: Wed, 17 Oct 2012 15:39:57 +0200
From: Alexandre Bezroutchko 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= 
References: 
	<20121017121115.GI8912@reaktio.net>
In-Reply-To: <20121017121115.GI8912@reaktio.net>
X-Enigmail-Version: 1.4.4
X-Gm-Message-State: ALoCoQmhPOL9smomZNWUPBKVpLgb6G/CAcYJYOvc6LHtQIJ3rayBNIN3BQoZWOotKQGa2TjLdKhE
Cc: nathanael@polymorpheus.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] pvusb with kernel 3.4 / 3.6
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thanks for the hint, found it, here it is:

http://wiki.xen.org/wiki/Xen_Development_Projects#Upstreaming_Xen_PVUSB_dri=
vers_to_mainline_Linux_kernel

On 10/17/2012 02:11 PM, Pasi K=E4rkk=E4inen wrote:
> On Wed, Oct 17, 2012 at 01:21:53PM +0200, Alexandre Bezroutchko wrote:
>>    Hi Nathanael,
>>
>>    Is it possible to use your patch [1] on newer kernels? I've tried to =
use
>>    it but most devices are not usable and some cause kernel crash. Detai=
led
>>    description of an attempt on kernel 3.4 is at [2] and (somewhat less
>>    detailed) with 3.6 is at [3]. I'm motivated to make it work, any ideas
>>    what can be done to fix this issue? Please tell me if you need any
>>    additional info.
>>
>>    I've added xen-devel and Pasi K=E4rkk=E4inen into Cc, hope this is ok.
>>
> I think Konrad has the pvusb drivers in his git tree..
>
>
> -- Pasi
>  =

>
>>    Regards,
>>    Alex
>>
>>    [1] [1]http://lists.xen.org/archives/html/xen-devel/2012-02/msg00571.=
html
>>    [2]
>>    [2]https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/3IAf7f8lz2=
UJ
>>    [3]
>>    [3]https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/rNmVAOXX4d=
YJ
>>
>> References
>>
>>    Visible links
>>    1. http://lists.xen.org/archives/html/xen-devel/2012-02/msg00571.html
>>    2. https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/3IAf7f8lz2=
UJ
>>    3. https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/rNmVAOXX4d=
YJ


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 13:40:21 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 13:40:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOTqt-00033O-OE; Wed, 17 Oct 2012 13:40:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOTqs-00033G-Ju
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 13:40:02 +0000
Received: from [85.158.139.211:16546] by server-12.bemta-5.messagelabs.com id
	77/AC-26919-135BE705; Wed, 17 Oct 2012 13:40:01 +0000
X-Env-Sender: abb@gremwell.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1350481201!22654300!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17384 invoked from network); 17 Oct 2012 13:40:01 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 13:40:01 -0000
Received: by mail-bk0-f45.google.com with SMTP id jf3so3342584bkc.32
	for ; Wed, 17 Oct 2012 06:40:00 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:x-enigmail-version:content-type
	:content-transfer-encoding:x-gm-message-state;
	bh=fK7h7ZJaRaSmjk6gophYHGl06qUjJy+d1Lhg3ZIHK/U=;
	b=cjaMMnrwn7o3Gqma6lIEhC9FUsPQwd8+aCHNXWuAFH/NCm3FpfdVdOGzYVHrgb0QVR
	8BdIp2OhGjVgRH67yEpF6C94QStDwRlOdM9l9UIY4Fr/fEIsSSqRNbLXGVV1XREBQC0Z
	orU/29UG3Yd5RYYgb5/W5hVBTjgbFUYJYXgRHCPPDTKN0XuYlV7gPdBwqNvJZ6Cx2r8Q
	m76ohpuCJ97sevgXcpK050FiT6gBXOLfKMZJRN0tv8DI14hC21/Uhmln9bhqPozRPLHR
	qnmfFhYOyy+d6sG93RJRyt/RDHwc6/LxfX75cLHUWFzwM3aSV2aalqJ+257ievkrcYjI
	/RfQ==
Received: by 10.204.145.88 with SMTP id c24mr4596427bkv.106.1350481200692;
	Wed, 17 Oct 2012 06:40:00 -0700 (PDT)
Received: from [192.168.1.120] (253.2-66-87.adsl-static.isp.belgacom.be.
	[87.66.2.253])
	by mx.google.com with ESMTPS id e3sm12907492bks.7.2012.10.17.06.39.59
	(version=SSLv3 cipher=OTHER); Wed, 17 Oct 2012 06:39:59 -0700 (PDT)
Message-ID: <507EB52D.1040209@gremwell.com>
Date: Wed, 17 Oct 2012 15:39:57 +0200
From: Alexandre Bezroutchko 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= 
References: 
	<20121017121115.GI8912@reaktio.net>
In-Reply-To: <20121017121115.GI8912@reaktio.net>
X-Enigmail-Version: 1.4.4
X-Gm-Message-State: ALoCoQmhPOL9smomZNWUPBKVpLgb6G/CAcYJYOvc6LHtQIJ3rayBNIN3BQoZWOotKQGa2TjLdKhE
Cc: nathanael@polymorpheus.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] pvusb with kernel 3.4 / 3.6
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thanks for the hint, found it, here it is:

http://wiki.xen.org/wiki/Xen_Development_Projects#Upstreaming_Xen_PVUSB_dri=
vers_to_mainline_Linux_kernel

On 10/17/2012 02:11 PM, Pasi K=E4rkk=E4inen wrote:
> On Wed, Oct 17, 2012 at 01:21:53PM +0200, Alexandre Bezroutchko wrote:
>>    Hi Nathanael,
>>
>>    Is it possible to use your patch [1] on newer kernels? I've tried to =
use
>>    it but most devices are not usable and some cause kernel crash. Detai=
led
>>    description of an attempt on kernel 3.4 is at [2] and (somewhat less
>>    detailed) with 3.6 is at [3]. I'm motivated to make it work, any ideas
>>    what can be done to fix this issue? Please tell me if you need any
>>    additional info.
>>
>>    I've added xen-devel and Pasi K=E4rkk=E4inen into Cc, hope this is ok.
>>
> I think Konrad has the pvusb drivers in his git tree..
>
>
> -- Pasi
>  =

>
>>    Regards,
>>    Alex
>>
>>    [1] [1]http://lists.xen.org/archives/html/xen-devel/2012-02/msg00571.=
html
>>    [2]
>>    [2]https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/3IAf7f8lz2=
UJ
>>    [3]
>>    [3]https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/rNmVAOXX4d=
YJ
>>
>> References
>>
>>    Visible links
>>    1. http://lists.xen.org/archives/html/xen-devel/2012-02/msg00571.html
>>    2. https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/3IAf7f8lz2=
UJ
>>    3. https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/rNmVAOXX4d=
YJ


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 13:46:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 13:46:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOTwj-0003Gp-Pf; Wed, 17 Oct 2012 13:46:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOTwh-0003Gk-Rd
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 13:46:04 +0000
Received: from [85.158.139.211:32370] by server-3.bemta-5.messagelabs.com id
	AA/16-28618-A96BE705; Wed, 17 Oct 2012 13:46:02 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1350481559!22670372!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5452 invoked from network); 17 Oct 2012 13:45:59 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-3.tower-206.messagelabs.com with SMTP;
	17 Oct 2012 13:45:59 -0000
Received: from p5b2e42c0.dip.t-dialin.net ([91.46.66.192] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from )
	id 1TOTwc-00008R-RN; Wed, 17 Oct 2012 13:45:58 +0000
Message-ID: <507EB694.8070105@canonical.com>
Date: Wed, 17 Oct 2012 15:45:56 +0200
From: Stefan Bader 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Andrew Cooper 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
In-Reply-To: <507EB27D.8050308@citrix.com>
X-Enigmail-Version: 1.4.5
Cc: Konrad Rzeszutek Wilk , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============3687563582694962846=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============3687563582694962846==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig81D271FA730DEC5D8D196885"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig81D271FA730DEC5D8D196885
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 17.10.2012 15:28, Andrew Cooper wrote:
> On 17/10/12 14:10, Stefan Bader wrote:
>> I am currently looking at a bug report[1] which is happening when
>> a Xen PVM guest with multiple VCPUs is running a high IO database
>> load (a test script is available in the bug report).
>>
>> In experimenting it seems that this happens (or is getting more
>> likely) when the number of VCPUs is 8 or higher (though I have
>> not tried 6, only 2 and 4), having autogroup enabled seems to
>> make it more likely, too (at some point thought it would actually
>> prevent it but we were wrong) and pv spinlocks enabled.
>> It has happened with older (3.4.3) and newer (4.1.2) versions of
>> Xen as a host and with 3.2 and 3.5 kernels as guests.
>>
>> The pv spinlock assumption I will try to get re-verified by asking
>> to reproduce under a real load with a kernel that just disables
>> that. However, the dumps I am looking at really do look odd there.
>>
>> The first dump I looked at had the spinlock of runqueue[0] being
>> placed into the per-cpu lock_spinners variable for cpu#0 and
>> cpu#7 (doing my tests with 8 VCPUs). So apparently both cpus were
>> waiting on the slow path for it to become free. Though actually
>> it was free! Now, here is one issue I have in understanding the
>> dump: the back traces produced in crash are in the normal form
>> not showing any cpu in the poll_irq HV call. Only when using
>> the form that uses the last known stack location and displays
>> all text symols found will get close for cpu#7. cpu#0 still does
>> not seem to be anywhere close. This could be a problem with crash,
>> or with the way PVM works, I am not sure.
>>
>> Anyway, from what I could take from that situation, it seemed that
>> cpu#1 (that one had soft lockup warnings in the log) seemed to try
>> to do a wake_up on the task that just seemed to have done an io
>> schedule on cpu#7 (but the waitqueue_head spinlock is currently
>> locked). cpu#7 tries to get the runqueue[0] spinlock to do an idle
>> migration (though the lock currently is free). So I guessed that
>> maybe cpu#0 was just woken for the free lock but has not grabbed
>> it yet.
>>
>> From there I wondered whether something that acquires a spinlock
>> usually more than the quick path timeout (and this causes new
>> lockers to go into the slow path), could cause a stall on a high
>> numbered cpu when the lock is contented (as the search and
>> signalling is only done for the first waiter starting from 0).
>> That lead to below patch. The good thing about it, it does not
>> break things immediately, the bad thing, it does not help with
>> the problem. :/
>>
>> The interesting thing when looking at a second dump, taken with
>> a testkernel using the patch below, was that again 2 cpus seemed
>> to spin slow on a lock that was free in the dump. And again at
>> least one did not seem to be doing anything spinlock related
>> (anymore?).
>> One other detail (but that could be just incidence as well) was
>> that in unmodified kernel I usually would end up with soft
>> lockup messages, with the patched kernel, that was a stall
>> detected by rcu_bh (0 and 1 stalled, detected by 3).
>>
>> Now I am a bit confused and wonder about some basic things:
>> 1. When a cpu goes into the slow lock path and into the poll_irq,
>>    shouldn't I expect this one to be in hypercall_page in the
>>    dump?
>> 2. When does the whole handling for interrupted spinlock wait
>>    apply? I assume only for a spinlock taken without irqs
>>    disabled and then trying to acquire another one in an
>>    interrupt handler. Is that correct?
>> 3. Not really related but I just stumbled over it:
>>    In xen_spin_trylock: "asm("xchgb %b0,%1"...)
>>    What does the "b" part of %b0 do? I thought xchgb already
>>    would say it is a byte value...
>>
>> But putting aside those questions, the fact that two times
>> there was two cpus waiting on the same lock which from the
>> lock count (=3D0) was free seems a bit too much of a coincidence.
>> Oh and the spinners count in the lock was 2 as one would
>> expect.
>>
>> struct rq {
>>   lock =3D {
>>     raw_lock =3D {
>>       {
>>         head_tail =3D 512,=20
>>         tickets =3D {
>>           head =3D 0 '\000',=20
>>           tail =3D 2 '\002'
>>         }
>>       }
>>     }
>>   },=20
>>   nr_running =3D 1,
>>   ...
>> }
>>
>> I really don't know how this happens. Especially cpu#0 seems at
>> least past the wakeup and should have removed itself from the
>> spinners list...
>> =20
>> -Stefan
>=20
> We (Citrix) have an outstanding bug, on 2.6.32 classic, which we have
> never managed to get to the bottom of (because of inability to reliably=

> reproduce), which might be related.
>=20
> In our case, certain processes were locking up, and it turned out that
> the kernel was issuing SCHOP_poll hypercalls (same the stack trace on
> your launchpad ticket) on its own spinlock IPI event channel
> (understandable, as its a spinlock), but with the event channel masked,=

> so it would never wake up from the poll.

Unfortunately either crash looking at it or something else is wrong for t=
he PV
guest as looking at HYPERVISOR_shared_info appears completely blank.

>=20
> Can you reliably reproduce the issue? and if so, would it be possible t=
o
> capture hypervisor debug keys q and e when the badness happens?  This
> would clearly show if our bugs are related or not

Yes, as mentioned the python script in the bug report does that when meet=
ing the
other conditions. I certainly can do the debug keys on that.

>=20
> Our repro case took about a month to reproduce, and unfortunately
> turning lockdep on has appeared to fix the problem.

Yeah, having lockdep enabled was another thing that made it less likely. =
Though
some reporters had lockups with it, too. Just much less likely.

-Stefan

>=20
> ~Andrew
>=20
>>
>> [1] http://bugs.launchpad.net/bugs/1011792
>>



--------------enig81D271FA730DEC5D8D196885
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBCgAGBQJQfraVAAoJEOhnXe7L7s6jtCQP/1Li9oKebZMBeK1os42nAu0v
uOeizVRkV4Brl0hSTjXRJnzPWXnOAho5mKU429m0VJrxLeo8uHHqMApTJBF8YEFF
Nf+NkEg18khpLn08jlFt6Gz2aKMYi4zoRr8nBtIzwrw21bOSlOzMaT2EO39UtHvm
PX3HkMZWfkvEp/FTNBjynksOTMCp8W/dGXCMjA4h58fUPujl4IYjWhIUwvsI++Rc
m61PUi/LeWl0eE8xBYtp/piJwYkzl8/dLkyHo+qu0HlQ4jrQVYKsv5w+f0hfP1sY
uWAtGDFWALCJY8QYVqM81QiS3mPEWbG9B3pnJxarfSZx9IED62Ea4rXh3Vdm3xKc
Hk22e2abi/NSq81EUdbJMaH4Y0luoIiVeb5Pb76gqyDT1usMmE113US3e6JiDdfL
Nyu+xbaDUZMPK6VfVP3e+ZgdMwrYEwnR++NM+VYqsuKf5fLtBzNeGJ0JDN6c4wKB
O6pX/GDfdjX7soABFaQarfJWp9HX9LHE6BZF+SWYDuKdvIoKW8H2I9Hnh6qq6ALW
1I+LEdq6bn1N5cuGr6FxC+crAoEGhKCB5kjQ51x1ZNBo8f132DlctAsL2BLar4Jk
JK2F1B/pkVh6IW8wzJfjvQw+s9S/9pqFTSRPdRQf1sTanH1w5leLyuBASYqYUhpy
xUA3qXiwmqchNpek8NxS
=kZrl
-----END PGP SIGNATURE-----

--------------enig81D271FA730DEC5D8D196885--


--===============3687563582694962846==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3687563582694962846==--


From xen-devel-bounces@lists.xen.org Wed Oct 17 13:46:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 13:46:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOTwj-0003Gp-Pf; Wed, 17 Oct 2012 13:46:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOTwh-0003Gk-Rd
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 13:46:04 +0000
Received: from [85.158.139.211:32370] by server-3.bemta-5.messagelabs.com id
	AA/16-28618-A96BE705; Wed, 17 Oct 2012 13:46:02 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1350481559!22670372!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5452 invoked from network); 17 Oct 2012 13:45:59 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-3.tower-206.messagelabs.com with SMTP;
	17 Oct 2012 13:45:59 -0000
Received: from p5b2e42c0.dip.t-dialin.net ([91.46.66.192] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from )
	id 1TOTwc-00008R-RN; Wed, 17 Oct 2012 13:45:58 +0000
Message-ID: <507EB694.8070105@canonical.com>
Date: Wed, 17 Oct 2012 15:45:56 +0200
From: Stefan Bader 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Andrew Cooper 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
In-Reply-To: <507EB27D.8050308@citrix.com>
X-Enigmail-Version: 1.4.5
Cc: Konrad Rzeszutek Wilk , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============3687563582694962846=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============3687563582694962846==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig81D271FA730DEC5D8D196885"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig81D271FA730DEC5D8D196885
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 17.10.2012 15:28, Andrew Cooper wrote:
> On 17/10/12 14:10, Stefan Bader wrote:
>> I am currently looking at a bug report[1] which is happening when
>> a Xen PVM guest with multiple VCPUs is running a high IO database
>> load (a test script is available in the bug report).
>>
>> In experimenting it seems that this happens (or is getting more
>> likely) when the number of VCPUs is 8 or higher (though I have
>> not tried 6, only 2 and 4), having autogroup enabled seems to
>> make it more likely, too (at some point thought it would actually
>> prevent it but we were wrong) and pv spinlocks enabled.
>> It has happened with older (3.4.3) and newer (4.1.2) versions of
>> Xen as a host and with 3.2 and 3.5 kernels as guests.
>>
>> The pv spinlock assumption I will try to get re-verified by asking
>> to reproduce under a real load with a kernel that just disables
>> that. However, the dumps I am looking at really do look odd there.
>>
>> The first dump I looked at had the spinlock of runqueue[0] being
>> placed into the per-cpu lock_spinners variable for cpu#0 and
>> cpu#7 (doing my tests with 8 VCPUs). So apparently both cpus were
>> waiting on the slow path for it to become free. Though actually
>> it was free! Now, here is one issue I have in understanding the
>> dump: the back traces produced in crash are in the normal form
>> not showing any cpu in the poll_irq HV call. Only when using
>> the form that uses the last known stack location and displays
>> all text symols found will get close for cpu#7. cpu#0 still does
>> not seem to be anywhere close. This could be a problem with crash,
>> or with the way PVM works, I am not sure.
>>
>> Anyway, from what I could take from that situation, it seemed that
>> cpu#1 (that one had soft lockup warnings in the log) seemed to try
>> to do a wake_up on the task that just seemed to have done an io
>> schedule on cpu#7 (but the waitqueue_head spinlock is currently
>> locked). cpu#7 tries to get the runqueue[0] spinlock to do an idle
>> migration (though the lock currently is free). So I guessed that
>> maybe cpu#0 was just woken for the free lock but has not grabbed
>> it yet.
>>
>> From there I wondered whether something that acquires a spinlock
>> usually more than the quick path timeout (and this causes new
>> lockers to go into the slow path), could cause a stall on a high
>> numbered cpu when the lock is contented (as the search and
>> signalling is only done for the first waiter starting from 0).
>> That lead to below patch. The good thing about it, it does not
>> break things immediately, the bad thing, it does not help with
>> the problem. :/
>>
>> The interesting thing when looking at a second dump, taken with
>> a testkernel using the patch below, was that again 2 cpus seemed
>> to spin slow on a lock that was free in the dump. And again at
>> least one did not seem to be doing anything spinlock related
>> (anymore?).
>> One other detail (but that could be just incidence as well) was
>> that in unmodified kernel I usually would end up with soft
>> lockup messages, with the patched kernel, that was a stall
>> detected by rcu_bh (0 and 1 stalled, detected by 3).
>>
>> Now I am a bit confused and wonder about some basic things:
>> 1. When a cpu goes into the slow lock path and into the poll_irq,
>>    shouldn't I expect this one to be in hypercall_page in the
>>    dump?
>> 2. When does the whole handling for interrupted spinlock wait
>>    apply? I assume only for a spinlock taken without irqs
>>    disabled and then trying to acquire another one in an
>>    interrupt handler. Is that correct?
>> 3. Not really related but I just stumbled over it:
>>    In xen_spin_trylock: "asm("xchgb %b0,%1"...)
>>    What does the "b" part of %b0 do? I thought xchgb already
>>    would say it is a byte value...
>>
>> But putting aside those questions, the fact that two times
>> there was two cpus waiting on the same lock which from the
>> lock count (=3D0) was free seems a bit too much of a coincidence.
>> Oh and the spinners count in the lock was 2 as one would
>> expect.
>>
>> struct rq {
>>   lock =3D {
>>     raw_lock =3D {
>>       {
>>         head_tail =3D 512,=20
>>         tickets =3D {
>>           head =3D 0 '\000',=20
>>           tail =3D 2 '\002'
>>         }
>>       }
>>     }
>>   },=20
>>   nr_running =3D 1,
>>   ...
>> }
>>
>> I really don't know how this happens. Especially cpu#0 seems at
>> least past the wakeup and should have removed itself from the
>> spinners list...
>> =20
>> -Stefan
>=20
> We (Citrix) have an outstanding bug, on 2.6.32 classic, which we have
> never managed to get to the bottom of (because of inability to reliably=

> reproduce), which might be related.
>=20
> In our case, certain processes were locking up, and it turned out that
> the kernel was issuing SCHOP_poll hypercalls (same the stack trace on
> your launchpad ticket) on its own spinlock IPI event channel
> (understandable, as its a spinlock), but with the event channel masked,=

> so it would never wake up from the poll.

Unfortunately either crash looking at it or something else is wrong for t=
he PV
guest as looking at HYPERVISOR_shared_info appears completely blank.

>=20
> Can you reliably reproduce the issue? and if so, would it be possible t=
o
> capture hypervisor debug keys q and e when the badness happens?  This
> would clearly show if our bugs are related or not

Yes, as mentioned the python script in the bug report does that when meet=
ing the
other conditions. I certainly can do the debug keys on that.

>=20
> Our repro case took about a month to reproduce, and unfortunately
> turning lockdep on has appeared to fix the problem.

Yeah, having lockdep enabled was another thing that made it less likely. =
Though
some reporters had lockups with it, too. Just much less likely.

-Stefan

>=20
> ~Andrew
>=20
>>
>> [1] http://bugs.launchpad.net/bugs/1011792
>>



--------------enig81D271FA730DEC5D8D196885
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBCgAGBQJQfraVAAoJEOhnXe7L7s6jtCQP/1Li9oKebZMBeK1os42nAu0v
uOeizVRkV4Brl0hSTjXRJnzPWXnOAho5mKU429m0VJrxLeo8uHHqMApTJBF8YEFF
Nf+NkEg18khpLn08jlFt6Gz2aKMYi4zoRr8nBtIzwrw21bOSlOzMaT2EO39UtHvm
PX3HkMZWfkvEp/FTNBjynksOTMCp8W/dGXCMjA4h58fUPujl4IYjWhIUwvsI++Rc
m61PUi/LeWl0eE8xBYtp/piJwYkzl8/dLkyHo+qu0HlQ4jrQVYKsv5w+f0hfP1sY
uWAtGDFWALCJY8QYVqM81QiS3mPEWbG9B3pnJxarfSZx9IED62Ea4rXh3Vdm3xKc
Hk22e2abi/NSq81EUdbJMaH4Y0luoIiVeb5Pb76gqyDT1usMmE113US3e6JiDdfL
Nyu+xbaDUZMPK6VfVP3e+ZgdMwrYEwnR++NM+VYqsuKf5fLtBzNeGJ0JDN6c4wKB
O6pX/GDfdjX7soABFaQarfJWp9HX9LHE6BZF+SWYDuKdvIoKW8H2I9Hnh6qq6ALW
1I+LEdq6bn1N5cuGr6FxC+crAoEGhKCB5kjQ51x1ZNBo8f132DlctAsL2BLar4Jk
JK2F1B/pkVh6IW8wzJfjvQw+s9S/9pqFTSRPdRQf1sTanH1w5leLyuBASYqYUhpy
xUA3qXiwmqchNpek8NxS
=kZrl
-----END PGP SIGNATURE-----

--------------enig81D271FA730DEC5D8D196885--


--===============3687563582694962846==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3687563582694962846==--


From xen-devel-bounces@lists.xen.org Wed Oct 17 13:50:48 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 13:50:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOU14-0003Pt-Ho; Wed, 17 Oct 2012 13:50:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOU12-0003Pn-Tm
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 13:50:33 +0000
Received: from [85.158.143.99:40571] by server-2.bemta-4.messagelabs.com id
	44/4B-22268-8A7BE705; Wed, 17 Oct 2012 13:50:32 +0000
X-Env-Sender: abb@gremwell.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1350481829!34460270!1
X-Originating-IP: [209.85.215.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32352 invoked from network); 17 Oct 2012 13:50:30 -0000
Received: from mail-la0-f45.google.com (HELO mail-la0-f45.google.com)
	(209.85.215.45)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 13:50:30 -0000
Received: by mail-la0-f45.google.com with SMTP id m13so6194113lah.32
	for ; Wed, 17 Oct 2012 06:50:29 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:x-enigmail-version:content-type
	:content-transfer-encoding:x-gm-message-state;
	bh=JHB9Vc7mDXvPXKa9sCHJigY9wBtvrLUh769ObZQjYjE=;
	b=fTV168D8aeOjxUERt+hhXuK4onhc/xG9iip51eoVZu42ABn9+feMvAG2IC5dmhFWUw
	tZsLgDj156+7AV19BviumQ7+VIsmIsK6x9+S2ZXfwMmePfdBYj+ZpPzoAzNG9uBqIWGd
	LT/FKw2UjTAAc3d+UzSHWRBlfqBwc67kE7pIFSVlZOd9OrDG5ssOMWJk8groE6qUwble
	ZruQ/rttVsYChfReV3o+NL52fs1ipuYZA4oyxk+ZlJ1uGfETJtHPqlwDXJl74WQcm+Ln
	3PVk9QfI0zBZaSa9V9AIOdv7/MrkM2fYfohU64ZqunhKh0zm8UuFGVLlGAVl4PMaJxXm
	T3/Q==
Received: by 10.112.86.196 with SMTP id r4mr6877044lbz.33.1350481829365;
	Wed, 17 Oct 2012 06:50:29 -0700 (PDT)
Received: from [192.168.1.120] (253.2-66-87.adsl-static.isp.belgacom.be.
	[87.66.2.253])
	by mx.google.com with ESMTPS id nr2sm6570421lab.5.2012.10.17.06.50.27
	(version=SSLv3 cipher=OTHER); Wed, 17 Oct 2012 06:50:28 -0700 (PDT)
Message-ID: <507EB7A1.1080907@gremwell.com>
Date: Wed, 17 Oct 2012 15:50:25 +0200
From: Alexandre Bezroutchko 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: konrad.wilk@oracle.com
References: 
	<20121017121115.GI8912@reaktio.net> <507EB52D.1040209@gremwell.com>
In-Reply-To: <507EB52D.1040209@gremwell.com>
X-Enigmail-Version: 1.4.4
X-Gm-Message-State: ALoCoQlcgPsQye0oDikqwsl3tRtLkqz/HgnDpk+0xhSKTXrzPuuUepsCSZFWHHkLAwoYcQ9hFQ7a
Cc: nathanael@polymorpheus.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] pvusb with kernel 3.4 / 3.6
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/17/2012 03:39 PM, Alexandre Bezroutchko wrote:
> Thanks for the hint, found it, here it is:
>
> http://wiki.xen.org/wiki/Xen_Development_Projects#Upstreaming_Xen_PVUSB_d=
rivers_to_mainline_Linux_kernel
>
> On 10/17/2012 02:11 PM, Pasi K=E4rkk=E4inen wrote:
>> On Wed, Oct 17, 2012 at 01:21:53PM +0200, Alexandre Bezroutchko wrote:
>>>    Hi Nathanael,
>>>
>>>    Is it possible to use your patch [1] on newer kernels? I've tried to=
 use
>>>    it but most devices are not usable and some cause kernel crash. Deta=
iled
>>>    description of an attempt on kernel 3.4 is at [2] and (somewhat less
>>>    detailed) with 3.6 is at [3]. I'm motivated to make it work, any ide=
as
>>>    what can be done to fix this issue? Please tell me if you need any
>>>    additional info.
>>>
>>>    I've added xen-devel and Pasi K=E4rkk=E4inen into Cc, hope this is o=
k.
>>>
>> I think Konrad has the pvusb drivers in his git tree..
Konrad's repo seems to contain the same patch [1] as published by
Nathanael. It does not work for me. I've put Konrad in Cc, hope he can
comment...

[1]
http://git.kernel.org/?p=3Dlinux/kernel/git/konrad/xen.git;a=3Dpatch;h=3D10=
b675fc21702ff5a9b94fc13e2b504ca09073fd

Regards,
Alex

>>
>>
>> -- Pasi
>>  =

>>
>>>    Regards,
>>>    Alex
>>>
>>>    [1] [1]http://lists.xen.org/archives/html/xen-devel/2012-02/msg00571=
.html
>>>    [2]
>>>    [2]https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/3IAf7f8lz=
2UJ
>>>    [3]
>>>    [3]https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/rNmVAOXX4=
dYJ
>>>
>>> References
>>>
>>>    Visible links
>>>    1. http://lists.xen.org/archives/html/xen-devel/2012-02/msg00571.html
>>>    2. https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/3IAf7f8lz=
2UJ
>>>    3. https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/rNmVAOXX4=
dYJ


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 13:50:48 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 13:50:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOU14-0003Pt-Ho; Wed, 17 Oct 2012 13:50:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOU12-0003Pn-Tm
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 13:50:33 +0000
Received: from [85.158.143.99:40571] by server-2.bemta-4.messagelabs.com id
	44/4B-22268-8A7BE705; Wed, 17 Oct 2012 13:50:32 +0000
X-Env-Sender: abb@gremwell.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1350481829!34460270!1
X-Originating-IP: [209.85.215.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32352 invoked from network); 17 Oct 2012 13:50:30 -0000
Received: from mail-la0-f45.google.com (HELO mail-la0-f45.google.com)
	(209.85.215.45)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 13:50:30 -0000
Received: by mail-la0-f45.google.com with SMTP id m13so6194113lah.32
	for ; Wed, 17 Oct 2012 06:50:29 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:x-enigmail-version:content-type
	:content-transfer-encoding:x-gm-message-state;
	bh=JHB9Vc7mDXvPXKa9sCHJigY9wBtvrLUh769ObZQjYjE=;
	b=fTV168D8aeOjxUERt+hhXuK4onhc/xG9iip51eoVZu42ABn9+feMvAG2IC5dmhFWUw
	tZsLgDj156+7AV19BviumQ7+VIsmIsK6x9+S2ZXfwMmePfdBYj+ZpPzoAzNG9uBqIWGd
	LT/FKw2UjTAAc3d+UzSHWRBlfqBwc67kE7pIFSVlZOd9OrDG5ssOMWJk8groE6qUwble
	ZruQ/rttVsYChfReV3o+NL52fs1ipuYZA4oyxk+ZlJ1uGfETJtHPqlwDXJl74WQcm+Ln
	3PVk9QfI0zBZaSa9V9AIOdv7/MrkM2fYfohU64ZqunhKh0zm8UuFGVLlGAVl4PMaJxXm
	T3/Q==
Received: by 10.112.86.196 with SMTP id r4mr6877044lbz.33.1350481829365;
	Wed, 17 Oct 2012 06:50:29 -0700 (PDT)
Received: from [192.168.1.120] (253.2-66-87.adsl-static.isp.belgacom.be.
	[87.66.2.253])
	by mx.google.com with ESMTPS id nr2sm6570421lab.5.2012.10.17.06.50.27
	(version=SSLv3 cipher=OTHER); Wed, 17 Oct 2012 06:50:28 -0700 (PDT)
Message-ID: <507EB7A1.1080907@gremwell.com>
Date: Wed, 17 Oct 2012 15:50:25 +0200
From: Alexandre Bezroutchko 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: konrad.wilk@oracle.com
References: 
	<20121017121115.GI8912@reaktio.net> <507EB52D.1040209@gremwell.com>
In-Reply-To: <507EB52D.1040209@gremwell.com>
X-Enigmail-Version: 1.4.4
X-Gm-Message-State: ALoCoQlcgPsQye0oDikqwsl3tRtLkqz/HgnDpk+0xhSKTXrzPuuUepsCSZFWHHkLAwoYcQ9hFQ7a
Cc: nathanael@polymorpheus.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] pvusb with kernel 3.4 / 3.6
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/17/2012 03:39 PM, Alexandre Bezroutchko wrote:
> Thanks for the hint, found it, here it is:
>
> http://wiki.xen.org/wiki/Xen_Development_Projects#Upstreaming_Xen_PVUSB_d=
rivers_to_mainline_Linux_kernel
>
> On 10/17/2012 02:11 PM, Pasi K=E4rkk=E4inen wrote:
>> On Wed, Oct 17, 2012 at 01:21:53PM +0200, Alexandre Bezroutchko wrote:
>>>    Hi Nathanael,
>>>
>>>    Is it possible to use your patch [1] on newer kernels? I've tried to=
 use
>>>    it but most devices are not usable and some cause kernel crash. Deta=
iled
>>>    description of an attempt on kernel 3.4 is at [2] and (somewhat less
>>>    detailed) with 3.6 is at [3]. I'm motivated to make it work, any ide=
as
>>>    what can be done to fix this issue? Please tell me if you need any
>>>    additional info.
>>>
>>>    I've added xen-devel and Pasi K=E4rkk=E4inen into Cc, hope this is o=
k.
>>>
>> I think Konrad has the pvusb drivers in his git tree..
Konrad's repo seems to contain the same patch [1] as published by
Nathanael. It does not work for me. I've put Konrad in Cc, hope he can
comment...

[1]
http://git.kernel.org/?p=3Dlinux/kernel/git/konrad/xen.git;a=3Dpatch;h=3D10=
b675fc21702ff5a9b94fc13e2b504ca09073fd

Regards,
Alex

>>
>>
>> -- Pasi
>>  =

>>
>>>    Regards,
>>>    Alex
>>>
>>>    [1] [1]http://lists.xen.org/archives/html/xen-devel/2012-02/msg00571=
.html
>>>    [2]
>>>    [2]https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/3IAf7f8lz=
2UJ
>>>    [3]
>>>    [3]https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/rNmVAOXX4=
dYJ
>>>
>>> References
>>>
>>>    Visible links
>>>    1. http://lists.xen.org/archives/html/xen-devel/2012-02/msg00571.html
>>>    2. https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/3IAf7f8lz=
2UJ
>>>    3. https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/rNmVAOXX4=
dYJ


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 13:51:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 13:51:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOU1X-0003SG-V9; Wed, 17 Oct 2012 13:51:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOU1W-0003S7-3N
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 13:51:02 +0000
Received: from [85.158.143.35:16355] by server-2.bemta-4.messagelabs.com id
	15/1C-22268-5C7BE705; Wed, 17 Oct 2012 13:51:01 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1350481858!6797584!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2762 invoked from network); 17 Oct 2012 13:50:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 13:50:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,600,1344211200"; d="scan'208";a="15227614"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 13:50:58 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 17 Oct 2012 14:50:58 +0100
Date: Wed, 17 Oct 2012 14:50:35 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1350314444-17148-10-git-send-email-ian.campbell@citrix.com>
Message-ID: 
References: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
	<1350314444-17148-10-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" ,
	Stefano Stabellini ,
	"Tim \(Xen.org\)" ,
	"xen-devel@lists.xen.org" ,
	Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 10/10] arm: parameter guest handles are 32
 bit on 32 bit hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 15 Oct 2012, Ian Campbell wrote:
> Handles within structs remain 64 bit such that they are consistently
> sized on both 32 and 64 bit.
> 
> Signed-off-by: Ian Campbell 
> ---
>  xen/include/public/arch-arm.h |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> index ac493a5..ff02d15 100644
> --- a/xen/include/public/arch-arm.h
> +++ b/xen/include/public/arch-arm.h
> @@ -74,7 +74,7 @@
>  #define __XEN_GUEST_HANDLE(name)        __guest_handle_64_ ## name
>  #define XEN_GUEST_HANDLE(name)          __XEN_GUEST_HANDLE(name)
>  /* this is going to be changed on 64 bit */
> -#define XEN_GUEST_HANDLE_PARAM(name)   XEN_GUEST_HANDLE(name)
> +#define XEN_GUEST_HANDLE_PARAM(name)    __guest_handle_ ## name
>  #define set_xen_guest_handle_raw(hnd, val)                  \
>      do {                                                    \
>          typeof(&(hnd)) _sxghr_tmp = &(hnd);                 \

I am confused.

I am not sure what version of my patch "xen: introduce
XEN_GUEST_HANDLE_PARAM" you have based this series upon, because the
latest one I have sent, certainly contains this change:


diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index 2ae6548..4c6d607 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -51,18 +51,36 @@
 
 #define XEN_HYPERCALL_TAG   0XEA1
 
+#define uint64_aligned_t uint64_t __attribute__((aligned(8)))
 
 #ifndef __ASSEMBLY__
-#define ___DEFINE_XEN_GUEST_HANDLE(name, type) \
-    typedef struct { type *p; } __guest_handle_ ## name
+#define ___DEFINE_XEN_GUEST_HANDLE(name, type)                  \
+    typedef union { type *p; unsigned long q; }                 \
+        __guest_handle_ ## name;                                \
+    typedef union { type *p; uint64_aligned_t q; }              \
+        __guest_handle_64_ ## name;
 
+/*
+ * XEN_GUEST_HANDLE represents a guest pointer, when passed as a field
+ * in a struct in memory. On ARM is always 8 bytes sizes and 8 bytes
+ * aligned.
+ * XEN_GUEST_HANDLE_PARAM represent a guest pointer, when passed as an
+ * hypercall argument. It is 4 bytes on aarch and 8 bytes on aarch64.
+ */
 #define __DEFINE_XEN_GUEST_HANDLE(name, type) \
     ___DEFINE_XEN_GUEST_HANDLE(name, type);   \
     ___DEFINE_XEN_GUEST_HANDLE(const_##name, const type)
 #define DEFINE_XEN_GUEST_HANDLE(name)   __DEFINE_XEN_GUEST_HANDLE(name, name)
-#define __XEN_GUEST_HANDLE(name)        __guest_handle_ ## name
+#define __XEN_GUEST_HANDLE(name)        __guest_handle_64_ ## name
 #define XEN_GUEST_HANDLE(name)          __XEN_GUEST_HANDLE(name)
-#define set_xen_guest_handle_raw(hnd, val)  do { (hnd).p = val; } while (0)
+/* this is going to be changes on 64 bit */
+#define XEN_GUEST_HANDLE_PARAM(name)    __guest_handle_ ## name


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 13:51:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 13:51:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOU1X-0003SG-V9; Wed, 17 Oct 2012 13:51:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOU1W-0003S7-3N
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 13:51:02 +0000
Received: from [85.158.143.35:16355] by server-2.bemta-4.messagelabs.com id
	15/1C-22268-5C7BE705; Wed, 17 Oct 2012 13:51:01 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1350481858!6797584!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2762 invoked from network); 17 Oct 2012 13:50:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 13:50:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,600,1344211200"; d="scan'208";a="15227614"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 13:50:58 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 17 Oct 2012 14:50:58 +0100
Date: Wed, 17 Oct 2012 14:50:35 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1350314444-17148-10-git-send-email-ian.campbell@citrix.com>
Message-ID: 
References: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
	<1350314444-17148-10-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" ,
	Stefano Stabellini ,
	"Tim \(Xen.org\)" ,
	"xen-devel@lists.xen.org" ,
	Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 10/10] arm: parameter guest handles are 32
 bit on 32 bit hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 15 Oct 2012, Ian Campbell wrote:
> Handles within structs remain 64 bit such that they are consistently
> sized on both 32 and 64 bit.
> 
> Signed-off-by: Ian Campbell 
> ---
>  xen/include/public/arch-arm.h |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> index ac493a5..ff02d15 100644
> --- a/xen/include/public/arch-arm.h
> +++ b/xen/include/public/arch-arm.h
> @@ -74,7 +74,7 @@
>  #define __XEN_GUEST_HANDLE(name)        __guest_handle_64_ ## name
>  #define XEN_GUEST_HANDLE(name)          __XEN_GUEST_HANDLE(name)
>  /* this is going to be changed on 64 bit */
> -#define XEN_GUEST_HANDLE_PARAM(name)   XEN_GUEST_HANDLE(name)
> +#define XEN_GUEST_HANDLE_PARAM(name)    __guest_handle_ ## name
>  #define set_xen_guest_handle_raw(hnd, val)                  \
>      do {                                                    \
>          typeof(&(hnd)) _sxghr_tmp = &(hnd);                 \

I am confused.

I am not sure what version of my patch "xen: introduce
XEN_GUEST_HANDLE_PARAM" you have based this series upon, because the
latest one I have sent, certainly contains this change:


diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index 2ae6548..4c6d607 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -51,18 +51,36 @@
 
 #define XEN_HYPERCALL_TAG   0XEA1
 
+#define uint64_aligned_t uint64_t __attribute__((aligned(8)))
 
 #ifndef __ASSEMBLY__
-#define ___DEFINE_XEN_GUEST_HANDLE(name, type) \
-    typedef struct { type *p; } __guest_handle_ ## name
+#define ___DEFINE_XEN_GUEST_HANDLE(name, type)                  \
+    typedef union { type *p; unsigned long q; }                 \
+        __guest_handle_ ## name;                                \
+    typedef union { type *p; uint64_aligned_t q; }              \
+        __guest_handle_64_ ## name;
 
+/*
+ * XEN_GUEST_HANDLE represents a guest pointer, when passed as a field
+ * in a struct in memory. On ARM is always 8 bytes sizes and 8 bytes
+ * aligned.
+ * XEN_GUEST_HANDLE_PARAM represent a guest pointer, when passed as an
+ * hypercall argument. It is 4 bytes on aarch and 8 bytes on aarch64.
+ */
 #define __DEFINE_XEN_GUEST_HANDLE(name, type) \
     ___DEFINE_XEN_GUEST_HANDLE(name, type);   \
     ___DEFINE_XEN_GUEST_HANDLE(const_##name, const type)
 #define DEFINE_XEN_GUEST_HANDLE(name)   __DEFINE_XEN_GUEST_HANDLE(name, name)
-#define __XEN_GUEST_HANDLE(name)        __guest_handle_ ## name
+#define __XEN_GUEST_HANDLE(name)        __guest_handle_64_ ## name
 #define XEN_GUEST_HANDLE(name)          __XEN_GUEST_HANDLE(name)
-#define set_xen_guest_handle_raw(hnd, val)  do { (hnd).p = val; } while (0)
+/* this is going to be changes on 64 bit */
+#define XEN_GUEST_HANDLE_PARAM(name)    __guest_handle_ ## name


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 13:54:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 13:54:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOU4Q-0003f8-K5; Wed, 17 Oct 2012 13:54:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOU4O-0003ey-0V
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 13:54:00 +0000
Received: from [85.158.139.83:12200] by server-4.bemta-5.messagelabs.com id
	10/EA-01455-778BE705; Wed, 17 Oct 2012 13:53:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1350482038!31398844!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28157 invoked from network); 17 Oct 2012 13:53:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 13:53:58 -0000
X-IronPort-AV: E=Sophos;i="4.80,600,1344211200"; d="scan'208";a="15227694"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 13:53:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 14:53:57 +0100
Message-ID: <1350482036.2460.73.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Wed, 17 Oct 2012 14:53:56 +0100
In-Reply-To: 
References: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
	<1350314444-17148-10-git-send-email-ian.campbell@citrix.com>
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" , "Tim \(Xen.org\)" ,
	Jan Beulich ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 10/10] arm: parameter guest handles are 32
 bit on 32 bit hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-17 at 14:50 +0100, Stefano Stabellini wrote:
> On Mon, 15 Oct 2012, Ian Campbell wrote:
> > Handles within structs remain 64 bit such that they are consistently
> > sized on both 32 and 64 bit.
> > 
> > Signed-off-by: Ian Campbell 
> > ---
> >  xen/include/public/arch-arm.h |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> > index ac493a5..ff02d15 100644
> > --- a/xen/include/public/arch-arm.h
> > +++ b/xen/include/public/arch-arm.h
> > @@ -74,7 +74,7 @@
> >  #define __XEN_GUEST_HANDLE(name)        __guest_handle_64_ ## name
> >  #define XEN_GUEST_HANDLE(name)          __XEN_GUEST_HANDLE(name)
> >  /* this is going to be changed on 64 bit */
> > -#define XEN_GUEST_HANDLE_PARAM(name)   XEN_GUEST_HANDLE(name)
> > +#define XEN_GUEST_HANDLE_PARAM(name)    __guest_handle_ ## name
> >  #define set_xen_guest_handle_raw(hnd, val)                  \
> >      do {                                                    \
> >          typeof(&(hnd)) _sxghr_tmp = &(hnd);                 \
> 
> I am confused.
> 
> I am not sure what version of my patch "xen: introduce
> XEN_GUEST_HANDLE_PARAM" you have based this series upon, because the
> latest one I have sent, certainly contains this change:

That stuff is in "xen: introduce XEN_GUEST_HANDLE_PARAM". I had to defer
the final switch until after the transition to HANDLE_PARAM was complete
in order to avoid breaking the build in the interim.

> 
> 
> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> index 2ae6548..4c6d607 100644
> --- a/xen/include/public/arch-arm.h
> +++ b/xen/include/public/arch-arm.h
> @@ -51,18 +51,36 @@
>  
>  #define XEN_HYPERCALL_TAG   0XEA1
>  
> +#define uint64_aligned_t uint64_t __attribute__((aligned(8)))
>  
>  #ifndef __ASSEMBLY__
> -#define ___DEFINE_XEN_GUEST_HANDLE(name, type) \
> -    typedef struct { type *p; } __guest_handle_ ## name
> +#define ___DEFINE_XEN_GUEST_HANDLE(name, type)                  \
> +    typedef union { type *p; unsigned long q; }                 \
> +        __guest_handle_ ## name;                                \
> +    typedef union { type *p; uint64_aligned_t q; }              \
> +        __guest_handle_64_ ## name;
>  
> +/*
> + * XEN_GUEST_HANDLE represents a guest pointer, when passed as a field
> + * in a struct in memory. On ARM is always 8 bytes sizes and 8 bytes
> + * aligned.
> + * XEN_GUEST_HANDLE_PARAM represent a guest pointer, when passed as an
> + * hypercall argument. It is 4 bytes on aarch and 8 bytes on aarch64.
> + */
>  #define __DEFINE_XEN_GUEST_HANDLE(name, type) \
>      ___DEFINE_XEN_GUEST_HANDLE(name, type);   \
>      ___DEFINE_XEN_GUEST_HANDLE(const_##name, const type)
>  #define DEFINE_XEN_GUEST_HANDLE(name)   __DEFINE_XEN_GUEST_HANDLE(name, name)
> -#define __XEN_GUEST_HANDLE(name)        __guest_handle_ ## name
> +#define __XEN_GUEST_HANDLE(name)        __guest_handle_64_ ## name
>  #define XEN_GUEST_HANDLE(name)          __XEN_GUEST_HANDLE(name)
> -#define set_xen_guest_handle_raw(hnd, val)  do { (hnd).p = val; } while (0)
> +/* this is going to be changes on 64 bit */
> +#define XEN_GUEST_HANDLE_PARAM(name)    __guest_handle_ ## name
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 13:54:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 13:54:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOU4Q-0003f8-K5; Wed, 17 Oct 2012 13:54:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOU4O-0003ey-0V
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 13:54:00 +0000
Received: from [85.158.139.83:12200] by server-4.bemta-5.messagelabs.com id
	10/EA-01455-778BE705; Wed, 17 Oct 2012 13:53:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1350482038!31398844!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28157 invoked from network); 17 Oct 2012 13:53:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 13:53:58 -0000
X-IronPort-AV: E=Sophos;i="4.80,600,1344211200"; d="scan'208";a="15227694"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 13:53:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 14:53:57 +0100
Message-ID: <1350482036.2460.73.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Wed, 17 Oct 2012 14:53:56 +0100
In-Reply-To: 
References: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
	<1350314444-17148-10-git-send-email-ian.campbell@citrix.com>
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" , "Tim \(Xen.org\)" ,
	Jan Beulich ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 10/10] arm: parameter guest handles are 32
 bit on 32 bit hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-17 at 14:50 +0100, Stefano Stabellini wrote:
> On Mon, 15 Oct 2012, Ian Campbell wrote:
> > Handles within structs remain 64 bit such that they are consistently
> > sized on both 32 and 64 bit.
> > 
> > Signed-off-by: Ian Campbell 
> > ---
> >  xen/include/public/arch-arm.h |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> > index ac493a5..ff02d15 100644
> > --- a/xen/include/public/arch-arm.h
> > +++ b/xen/include/public/arch-arm.h
> > @@ -74,7 +74,7 @@
> >  #define __XEN_GUEST_HANDLE(name)        __guest_handle_64_ ## name
> >  #define XEN_GUEST_HANDLE(name)          __XEN_GUEST_HANDLE(name)
> >  /* this is going to be changed on 64 bit */
> > -#define XEN_GUEST_HANDLE_PARAM(name)   XEN_GUEST_HANDLE(name)
> > +#define XEN_GUEST_HANDLE_PARAM(name)    __guest_handle_ ## name
> >  #define set_xen_guest_handle_raw(hnd, val)                  \
> >      do {                                                    \
> >          typeof(&(hnd)) _sxghr_tmp = &(hnd);                 \
> 
> I am confused.
> 
> I am not sure what version of my patch "xen: introduce
> XEN_GUEST_HANDLE_PARAM" you have based this series upon, because the
> latest one I have sent, certainly contains this change:

That stuff is in "xen: introduce XEN_GUEST_HANDLE_PARAM". I had to defer
the final switch until after the transition to HANDLE_PARAM was complete
in order to avoid breaking the build in the interim.

> 
> 
> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> index 2ae6548..4c6d607 100644
> --- a/xen/include/public/arch-arm.h
> +++ b/xen/include/public/arch-arm.h
> @@ -51,18 +51,36 @@
>  
>  #define XEN_HYPERCALL_TAG   0XEA1
>  
> +#define uint64_aligned_t uint64_t __attribute__((aligned(8)))
>  
>  #ifndef __ASSEMBLY__
> -#define ___DEFINE_XEN_GUEST_HANDLE(name, type) \
> -    typedef struct { type *p; } __guest_handle_ ## name
> +#define ___DEFINE_XEN_GUEST_HANDLE(name, type)                  \
> +    typedef union { type *p; unsigned long q; }                 \
> +        __guest_handle_ ## name;                                \
> +    typedef union { type *p; uint64_aligned_t q; }              \
> +        __guest_handle_64_ ## name;
>  
> +/*
> + * XEN_GUEST_HANDLE represents a guest pointer, when passed as a field
> + * in a struct in memory. On ARM is always 8 bytes sizes and 8 bytes
> + * aligned.
> + * XEN_GUEST_HANDLE_PARAM represent a guest pointer, when passed as an
> + * hypercall argument. It is 4 bytes on aarch and 8 bytes on aarch64.
> + */
>  #define __DEFINE_XEN_GUEST_HANDLE(name, type) \
>      ___DEFINE_XEN_GUEST_HANDLE(name, type);   \
>      ___DEFINE_XEN_GUEST_HANDLE(const_##name, const type)
>  #define DEFINE_XEN_GUEST_HANDLE(name)   __DEFINE_XEN_GUEST_HANDLE(name, name)
> -#define __XEN_GUEST_HANDLE(name)        __guest_handle_ ## name
> +#define __XEN_GUEST_HANDLE(name)        __guest_handle_64_ ## name
>  #define XEN_GUEST_HANDLE(name)          __XEN_GUEST_HANDLE(name)
> -#define set_xen_guest_handle_raw(hnd, val)  do { (hnd).p = val; } while (0)
> +/* this is going to be changes on 64 bit */
> +#define XEN_GUEST_HANDLE_PARAM(name)    __guest_handle_ ## name
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 13:55:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 13:55:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOU5O-0003kx-Ne; Wed, 17 Oct 2012 13:55:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOU5M-0003kl-9e
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 13:55:00 +0000
Received: from [85.158.139.83:19557] by server-8.bemta-5.messagelabs.com id
	62/3B-23193-3B8BE705; Wed, 17 Oct 2012 13:54:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1350482098!23543544!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22858 invoked from network); 17 Oct 2012 13:54:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 13:54:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,600,1344211200"; d="scan'208";a="15227735"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 13:54:58 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 17 Oct 2012 14:54:58 +0100
Date: Wed, 17 Oct 2012 14:54:35 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1350314444-17148-9-git-send-email-ian.campbell@citrix.com>
Message-ID: 
References: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
	<1350314444-17148-9-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" ,
	Stefano Stabellini ,
	"Tim \(Xen.org\)" ,
	"xen-devel@lists.xen.org" ,
	Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 09/10] xen: remove XEN_GUEST_HANDLE(ulong)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 15 Oct 2012, Ian Campbell wrote:
> Having both this handle (always unsigned long) and
> XEN_GUEST_HANDLE(xen_ulong_t) (unsigned long on x86 and explicit size
> of ARM) is confusing and error prone.
> 
> Replace the two remaining uses of the ulong handle, in grant set and
> x86 set_gdt hypercalls, with xen_ulong_t.
> 
> This correctly sizes the grant frame entry as 64 bit on ARM but
> leaves it as unsigned long on x86 (therefore no intended change on
> x86). Likewise in set_gdt there is no actual change.
> 
> Signed-off-by: Ian Campbell 
> Cc: keir@xen.org
> Cc: JBeulich@suse.com


Acked-by: Stefano Stabellini 

>  xen/arch/x86/mm.c                |    3 ++-
>  xen/common/grant_table.c         |    2 +-
>  xen/include/asm-x86/hypercall.h  |    2 +-
>  xen/include/public/grant_table.h |    2 +-
>  xen/include/public/xen.h         |    2 --
>  5 files changed, 5 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> index 191f5ea..fad3d33 100644
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -4100,7 +4100,8 @@ long set_gdt(struct vcpu *v,
>  }
>  
>  
> -long do_set_gdt(XEN_GUEST_HANDLE_PARAM(ulong) frame_list, unsigned int entries)
> +long do_set_gdt(XEN_GUEST_HANDLE_PARAM(xen_ulong_t) frame_list,
> +                unsigned int entries)
>  {
>      int nr_pages = (entries + 511) / 512;
>      unsigned long frames[16];
> diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
> index f4ae9ee..7912769 100644
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -1322,7 +1322,7 @@ gnttab_setup_table(
>      struct domain *d;
>      struct grant_table *gt;
>      int            i;
> -    unsigned long  gmfn;
> +    xen_pfn_t  gmfn;
>  
>      if ( count != 1 )
>          return -EINVAL;
> diff --git a/xen/include/asm-x86/hypercall.h b/xen/include/asm-x86/hypercall.h
> index bd14220..afa8ba9 100644
> --- a/xen/include/asm-x86/hypercall.h
> +++ b/xen/include/asm-x86/hypercall.h
> @@ -33,7 +33,7 @@ do_mmu_update(
>  
>  extern long
>  do_set_gdt(
> -    XEN_GUEST_HANDLE_PARAM(ulong) frame_list,
> +    XEN_GUEST_HANDLE_PARAM(xen_ulong_t) frame_list,
>      unsigned int entries);
>  
>  extern long
> diff --git a/xen/include/public/grant_table.h b/xen/include/public/grant_table.h
> index 28d9476..13cc559 100644
> --- a/xen/include/public/grant_table.h
> +++ b/xen/include/public/grant_table.h
> @@ -385,7 +385,7 @@ struct gnttab_setup_table {
>      uint32_t nr_frames;
>      /* OUT parameters. */
>      int16_t  status;              /* => enum grant_status */
> -    XEN_GUEST_HANDLE(ulong) frame_list;
> +    XEN_GUEST_HANDLE(xen_pfn_t) frame_list;
>  };
>  typedef struct gnttab_setup_table gnttab_setup_table_t;
>  DEFINE_XEN_GUEST_HANDLE(gnttab_setup_table_t);
> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> index e42d01f..9a5b394 100644
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -43,8 +43,6 @@ DEFINE_XEN_GUEST_HANDLE(char);
>  __DEFINE_XEN_GUEST_HANDLE(uchar, unsigned char);
>  DEFINE_XEN_GUEST_HANDLE(int);
>  __DEFINE_XEN_GUEST_HANDLE(uint,  unsigned int);
> -DEFINE_XEN_GUEST_HANDLE(long);
> -__DEFINE_XEN_GUEST_HANDLE(ulong, unsigned long);
>  DEFINE_XEN_GUEST_HANDLE(void);
>  
>  DEFINE_XEN_GUEST_HANDLE(uint64_t);
> -- 
> 1.7.9.1
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 13:55:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 13:55:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOU5O-0003kx-Ne; Wed, 17 Oct 2012 13:55:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOU5M-0003kl-9e
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 13:55:00 +0000
Received: from [85.158.139.83:19557] by server-8.bemta-5.messagelabs.com id
	62/3B-23193-3B8BE705; Wed, 17 Oct 2012 13:54:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1350482098!23543544!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22858 invoked from network); 17 Oct 2012 13:54:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 13:54:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,600,1344211200"; d="scan'208";a="15227735"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 13:54:58 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 17 Oct 2012 14:54:58 +0100
Date: Wed, 17 Oct 2012 14:54:35 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1350314444-17148-9-git-send-email-ian.campbell@citrix.com>
Message-ID: 
References: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
	<1350314444-17148-9-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" ,
	Stefano Stabellini ,
	"Tim \(Xen.org\)" ,
	"xen-devel@lists.xen.org" ,
	Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 09/10] xen: remove XEN_GUEST_HANDLE(ulong)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 15 Oct 2012, Ian Campbell wrote:
> Having both this handle (always unsigned long) and
> XEN_GUEST_HANDLE(xen_ulong_t) (unsigned long on x86 and explicit size
> of ARM) is confusing and error prone.
> 
> Replace the two remaining uses of the ulong handle, in grant set and
> x86 set_gdt hypercalls, with xen_ulong_t.
> 
> This correctly sizes the grant frame entry as 64 bit on ARM but
> leaves it as unsigned long on x86 (therefore no intended change on
> x86). Likewise in set_gdt there is no actual change.
> 
> Signed-off-by: Ian Campbell 
> Cc: keir@xen.org
> Cc: JBeulich@suse.com


Acked-by: Stefano Stabellini 

>  xen/arch/x86/mm.c                |    3 ++-
>  xen/common/grant_table.c         |    2 +-
>  xen/include/asm-x86/hypercall.h  |    2 +-
>  xen/include/public/grant_table.h |    2 +-
>  xen/include/public/xen.h         |    2 --
>  5 files changed, 5 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> index 191f5ea..fad3d33 100644
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -4100,7 +4100,8 @@ long set_gdt(struct vcpu *v,
>  }
>  
>  
> -long do_set_gdt(XEN_GUEST_HANDLE_PARAM(ulong) frame_list, unsigned int entries)
> +long do_set_gdt(XEN_GUEST_HANDLE_PARAM(xen_ulong_t) frame_list,
> +                unsigned int entries)
>  {
>      int nr_pages = (entries + 511) / 512;
>      unsigned long frames[16];
> diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
> index f4ae9ee..7912769 100644
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -1322,7 +1322,7 @@ gnttab_setup_table(
>      struct domain *d;
>      struct grant_table *gt;
>      int            i;
> -    unsigned long  gmfn;
> +    xen_pfn_t  gmfn;
>  
>      if ( count != 1 )
>          return -EINVAL;
> diff --git a/xen/include/asm-x86/hypercall.h b/xen/include/asm-x86/hypercall.h
> index bd14220..afa8ba9 100644
> --- a/xen/include/asm-x86/hypercall.h
> +++ b/xen/include/asm-x86/hypercall.h
> @@ -33,7 +33,7 @@ do_mmu_update(
>  
>  extern long
>  do_set_gdt(
> -    XEN_GUEST_HANDLE_PARAM(ulong) frame_list,
> +    XEN_GUEST_HANDLE_PARAM(xen_ulong_t) frame_list,
>      unsigned int entries);
>  
>  extern long
> diff --git a/xen/include/public/grant_table.h b/xen/include/public/grant_table.h
> index 28d9476..13cc559 100644
> --- a/xen/include/public/grant_table.h
> +++ b/xen/include/public/grant_table.h
> @@ -385,7 +385,7 @@ struct gnttab_setup_table {
>      uint32_t nr_frames;
>      /* OUT parameters. */
>      int16_t  status;              /* => enum grant_status */
> -    XEN_GUEST_HANDLE(ulong) frame_list;
> +    XEN_GUEST_HANDLE(xen_pfn_t) frame_list;
>  };
>  typedef struct gnttab_setup_table gnttab_setup_table_t;
>  DEFINE_XEN_GUEST_HANDLE(gnttab_setup_table_t);
> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> index e42d01f..9a5b394 100644
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -43,8 +43,6 @@ DEFINE_XEN_GUEST_HANDLE(char);
>  __DEFINE_XEN_GUEST_HANDLE(uchar, unsigned char);
>  DEFINE_XEN_GUEST_HANDLE(int);
>  __DEFINE_XEN_GUEST_HANDLE(uint,  unsigned int);
> -DEFINE_XEN_GUEST_HANDLE(long);
> -__DEFINE_XEN_GUEST_HANDLE(ulong, unsigned long);
>  DEFINE_XEN_GUEST_HANDLE(void);
>  
>  DEFINE_XEN_GUEST_HANDLE(uint64_t);
> -- 
> 1.7.9.1
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 13:55:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 13:55:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOU5k-0003oK-4i; Wed, 17 Oct 2012 13:55:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOU5i-0003nv-HC
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 13:55:22 +0000
Received: from [85.158.137.99:40070] by server-15.bemta-3.messagelabs.com id
	19/76-10261-9C8BE705; Wed, 17 Oct 2012 13:55:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1350482120!20733118!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18718 invoked from network); 17 Oct 2012 13:55:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 13:55:20 -0000
X-IronPort-AV: E=Sophos;i="4.80,600,1344211200"; d="scan'208";a="15227744"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 13:55:20 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 14:55:20 +0100
Message-ID: <1350482118.2460.74.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Andrew Cooper 
Date: Wed, 17 Oct 2012 14:55:18 +0100
In-Reply-To: <507EB27D.8050308@citrix.com>
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk ,
	"stefan.bader@canonical.com" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-17 at 14:28 +0100, Andrew Cooper wrote:
> In our case, certain processes were locking up, and it turned out that
> the kernel was issuing SCHOP_poll hypercalls (same the stack trace on
> your launchpad ticket) on its own spinlock IPI event channel
> (understandable, as its a spinlock), but with the event channel
> masked, so it would never wake up from the poll. 

I think (but you might want to check) that SCHEDOP_poll works (or is
supposed to work!) regardless of whether the specific evtchn you ask for
is masked or not.

The Linux PV spinlock implementation takes advantage of this because it
never wants to take a real interrupt from the spinlock poller evtchn.

The IRQ handler for the spinlock evtchn in Linux is:
        static irqreturn_t dummy_handler(int irq, void *dev_id)
        {
                BUG();
                return IRQ_HANDLED;
        }
        
and right after we register it:
                disable_irq(irq); /* make sure it's never delivered */

The is no enable -- ignoring bugs of which there have been couple of
instances, but those trigger the BUG() so are pretty obvious.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 13:55:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 13:55:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOU5k-0003oK-4i; Wed, 17 Oct 2012 13:55:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOU5i-0003nv-HC
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 13:55:22 +0000
Received: from [85.158.137.99:40070] by server-15.bemta-3.messagelabs.com id
	19/76-10261-9C8BE705; Wed, 17 Oct 2012 13:55:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1350482120!20733118!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18718 invoked from network); 17 Oct 2012 13:55:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 13:55:20 -0000
X-IronPort-AV: E=Sophos;i="4.80,600,1344211200"; d="scan'208";a="15227744"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 13:55:20 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 14:55:20 +0100
Message-ID: <1350482118.2460.74.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Andrew Cooper 
Date: Wed, 17 Oct 2012 14:55:18 +0100
In-Reply-To: <507EB27D.8050308@citrix.com>
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk ,
	"stefan.bader@canonical.com" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-17 at 14:28 +0100, Andrew Cooper wrote:
> In our case, certain processes were locking up, and it turned out that
> the kernel was issuing SCHOP_poll hypercalls (same the stack trace on
> your launchpad ticket) on its own spinlock IPI event channel
> (understandable, as its a spinlock), but with the event channel
> masked, so it would never wake up from the poll. 

I think (but you might want to check) that SCHEDOP_poll works (or is
supposed to work!) regardless of whether the specific evtchn you ask for
is masked or not.

The Linux PV spinlock implementation takes advantage of this because it
never wants to take a real interrupt from the spinlock poller evtchn.

The IRQ handler for the spinlock evtchn in Linux is:
        static irqreturn_t dummy_handler(int irq, void *dev_id)
        {
                BUG();
                return IRQ_HANDLED;
        }
        
and right after we register it:
                disable_irq(irq); /* make sure it's never delivered */

The is no enable -- ignoring bugs of which there have been couple of
instances, but those trigger the BUG() so are pretty obvious.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 14:04:00 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 14:04:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOUDr-0004Fc-VU; Wed, 17 Oct 2012 14:03:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOUDq-0004F7-7Q
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 14:03:46 +0000
Received: from [85.158.143.35:23703] by server-1.bemta-4.messagelabs.com id
	55/7C-19134-1CABE705; Wed, 17 Oct 2012 14:03:45 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1350482623!14077485!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgxNjgxMg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8943 invoked from network); 17 Oct 2012 14:03:45 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Oct 2012 14:03:45 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9HE3Zoj025254
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Oct 2012 14:03:36 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9HE3ZNP021289
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Oct 2012 14:03:35 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9HE3ZRO024956; Wed, 17 Oct 2012 09:03:35 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 07:03:34 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1DE404035B; Wed, 17 Oct 2012 09:49:53 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	lenb@kernel.org, linux-acpi@vger.kernel.org, hpa@zytor.com, x86@kernel.org
Date: Wed, 17 Oct 2012 09:49:46 -0400
Message-Id: <1350481786-4969-5-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 4/4] xen/acpi: Prep saved_context cr3 values.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

When save_processor_state is executed it executes a bunch of
pvops calls to save the CPU state values. When it comes back
from Xen's S3 (so acpi_enter_sleep_state, which ends up calling
xen_acpi_notify_hypervisor_state), it ends up back in the
assembler code in wakeup_[32|64].S. It skips the wakeup
calls (so wakeup_pmode_return and wakeup_long64) as that has
been done in the hypervisor. Instead it continues on in
the resume_point (64-bit) or ret_point (32-bit). Most of the
calls in there are safe to be executed except when it comes to
reloading of cr3 (which it only does on 64-bit kernels). Since
they are native assembler calls and Xen expects a PV kernel to
prep those to use machine address for cr3 that is what
we are going to do. Note: that it is not Machine Frame Numbers
(those are used in the MMUEXT_NEW_BASEPTR hypercall for cr3
installation) but the machine physical address.

When the assembler code executes this mov %ebx, cr3 it ends
end up trapped in the hypervisor (traps.c) which properly now
sets the cr3 value.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 drivers/xen/acpi.c |   25 +++++++++++++++++++++++++
 1 files changed, 25 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/acpi.c b/drivers/xen/acpi.c
index 119d42a..25e612c 100644
--- a/drivers/xen/acpi.c
+++ b/drivers/xen/acpi.c
@@ -35,6 +35,13 @@
 #include 
 #include 
 
+#include 
+
+#ifdef CONFIG_X86_64
+#include 
+extern struct saved_context saved_context;
+#endif
+
 int xen_acpi_notify_hypervisor_state(u8 sleep_state,
 				     u32 pm1a_cnt, u32 pm1b_cnt)
 {
@@ -56,7 +63,25 @@ int xen_acpi_notify_hypervisor_state(u8 sleep_state,
 		     pm1a_cnt, pm1b_cnt);
 		return -1;
 	}
+#ifdef CONFIG_X86_64
+	/* We do not need to anything for 32-bit kernels as the
+	 * low-level calls (write to cr3) is done in the wakup code
+	 * which we never execute when running under Xen.
+	 */
+	{
+		unsigned long mfn;
 
+		/* resume_point in wakeup_64.s barrels through and does:
+		 * movq    saved_context_cr3(%rax), %rbx
+		 * movq    %rbx, %cr3
+		 * so lets prep the values so they are OK with the
+		 * hypervisor. */
+		mfn = pfn_to_mfn(PFN_DOWN(saved_context.cr3));
+		/* and back to a physical address */
+		mfn = PFN_PHYS(mfn);
+		saved_context.cr3 = mfn;
+	}
+#endif
 	HYPERVISOR_dom0_op(&op);
 	return 1;
 }
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 14:04:00 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 14:04:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOUDr-0004Fc-VU; Wed, 17 Oct 2012 14:03:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOUDq-0004F7-7Q
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 14:03:46 +0000
Received: from [85.158.143.35:23703] by server-1.bemta-4.messagelabs.com id
	55/7C-19134-1CABE705; Wed, 17 Oct 2012 14:03:45 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1350482623!14077485!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgxNjgxMg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8943 invoked from network); 17 Oct 2012 14:03:45 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Oct 2012 14:03:45 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9HE3Zoj025254
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Oct 2012 14:03:36 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9HE3ZNP021289
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Oct 2012 14:03:35 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9HE3ZRO024956; Wed, 17 Oct 2012 09:03:35 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 07:03:34 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1DE404035B; Wed, 17 Oct 2012 09:49:53 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	lenb@kernel.org, linux-acpi@vger.kernel.org, hpa@zytor.com, x86@kernel.org
Date: Wed, 17 Oct 2012 09:49:46 -0400
Message-Id: <1350481786-4969-5-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 4/4] xen/acpi: Prep saved_context cr3 values.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

When save_processor_state is executed it executes a bunch of
pvops calls to save the CPU state values. When it comes back
from Xen's S3 (so acpi_enter_sleep_state, which ends up calling
xen_acpi_notify_hypervisor_state), it ends up back in the
assembler code in wakeup_[32|64].S. It skips the wakeup
calls (so wakeup_pmode_return and wakeup_long64) as that has
been done in the hypervisor. Instead it continues on in
the resume_point (64-bit) or ret_point (32-bit). Most of the
calls in there are safe to be executed except when it comes to
reloading of cr3 (which it only does on 64-bit kernels). Since
they are native assembler calls and Xen expects a PV kernel to
prep those to use machine address for cr3 that is what
we are going to do. Note: that it is not Machine Frame Numbers
(those are used in the MMUEXT_NEW_BASEPTR hypercall for cr3
installation) but the machine physical address.

When the assembler code executes this mov %ebx, cr3 it ends
end up trapped in the hypervisor (traps.c) which properly now
sets the cr3 value.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 drivers/xen/acpi.c |   25 +++++++++++++++++++++++++
 1 files changed, 25 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/acpi.c b/drivers/xen/acpi.c
index 119d42a..25e612c 100644
--- a/drivers/xen/acpi.c
+++ b/drivers/xen/acpi.c
@@ -35,6 +35,13 @@
 #include 
 #include 
 
+#include 
+
+#ifdef CONFIG_X86_64
+#include 
+extern struct saved_context saved_context;
+#endif
+
 int xen_acpi_notify_hypervisor_state(u8 sleep_state,
 				     u32 pm1a_cnt, u32 pm1b_cnt)
 {
@@ -56,7 +63,25 @@ int xen_acpi_notify_hypervisor_state(u8 sleep_state,
 		     pm1a_cnt, pm1b_cnt);
 		return -1;
 	}
+#ifdef CONFIG_X86_64
+	/* We do not need to anything for 32-bit kernels as the
+	 * low-level calls (write to cr3) is done in the wakup code
+	 * which we never execute when running under Xen.
+	 */
+	{
+		unsigned long mfn;
 
+		/* resume_point in wakeup_64.s barrels through and does:
+		 * movq    saved_context_cr3(%rax), %rbx
+		 * movq    %rbx, %cr3
+		 * so lets prep the values so they are OK with the
+		 * hypervisor. */
+		mfn = pfn_to_mfn(PFN_DOWN(saved_context.cr3));
+		/* and back to a physical address */
+		mfn = PFN_PHYS(mfn);
+		saved_context.cr3 = mfn;
+	}
+#endif
 	HYPERVISOR_dom0_op(&op);
 	return 1;
 }
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 14:04:00 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 14:04:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOUDu-0004G6-Bo; Wed, 17 Oct 2012 14:03:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOUDt-0004Fj-3m
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 14:03:49 +0000
Received: from [85.158.139.211:51549] by server-10.bemta-5.messagelabs.com id
	D0/7B-01025-4CABE705; Wed, 17 Oct 2012 14:03:48 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1350482626!22719556!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgxNjgxMg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 613 invoked from network); 17 Oct 2012 14:03:47 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Oct 2012 14:03:47 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9HE3abC025256
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Oct 2012 14:03:37 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9HE3ZmV027407
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Oct 2012 14:03:35 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9HE3Yk4011387; Wed, 17 Oct 2012 09:03:34 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 07:03:34 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 11F0E40376; Wed, 17 Oct 2012 09:49:53 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	lenb@kernel.org, linux-acpi@vger.kernel.org, hpa@zytor.com, x86@kernel.org
Date: Wed, 17 Oct 2012 09:49:45 -0400
Message-Id: <1350481786-4969-4-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 3/4] xen/lowlevel: Implement pvop call for
	store_gdt (gidt)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In the past it used to point to 'sgdt' (native_store_gdt)
operation which is a non-privileged operation. This resulted
in the value of 'struct desc_ptr' pointing to an bogus address
0xffff820000000000, instead of the GDT table that Linux thinks
it is using. The end result is that doing:

      store_gdt(&desc);
      load_gdt(&desc);

would blow up b/c xen_load_gdt would try to parse the GDT contents
(desc) and de-reference an bogus virtual address.

With this patch we are providing the last written address and size
of the GDT.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/xen/enlighten.c |   16 +++++++++++++++-
 1 files changed, 15 insertions(+), 1 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index f29d6d6..4a65138 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -471,6 +471,8 @@ static void xen_set_ldt(const void *addr, unsigned entries)
 	xen_mc_issue(PARAVIRT_LAZY_CPU);
 }
 
+static DEFINE_PER_CPU(struct desc_ptr, gdt_desc);
+
 static void xen_load_gdt(const struct desc_ptr *dtr)
 {
 	unsigned long va = dtr->address;
@@ -478,6 +480,7 @@ static void xen_load_gdt(const struct desc_ptr *dtr)
 	unsigned pages = (size + PAGE_SIZE - 1) / PAGE_SIZE;
 	unsigned long frames[pages];
 	int f;
+	struct desc_ptr *shadow;
 
 	/*
 	 * A GDT can be up to 64k in size, which corresponds to 8192
@@ -515,8 +518,19 @@ static void xen_load_gdt(const struct desc_ptr *dtr)
 
 	if (HYPERVISOR_set_gdt(frames, size / sizeof(struct desc_struct)))
 		BUG();
+
+	shadow = &__get_cpu_var(gdt_desc);
+	shadow->address = dtr->address;
+	shadow->size = size;
 }
 
+static void xen_store_gdt(struct desc_ptr *dtr)
+{
+	const struct desc_ptr *desc = &__get_cpu_var(gdt_desc);
+
+	dtr->address = desc->address;
+	dtr->size = desc->size;
+}
 /*
  * load_gdt for early boot, when the gdt is only mapped once
  */
@@ -1205,7 +1219,7 @@ static const struct pv_cpu_ops xen_cpu_ops __initconst = {
 	.alloc_ldt = xen_alloc_ldt,
 	.free_ldt = xen_free_ldt,
 
-	.store_gdt = native_store_gdt,
+	.store_gdt = xen_store_gdt,
 	.store_idt = xen_store_idt,
 	.store_tr = xen_store_tr,
 
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 14:04:00 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 14:04:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOUDu-0004G6-Bo; Wed, 17 Oct 2012 14:03:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOUDt-0004Fj-3m
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 14:03:49 +0000
Received: from [85.158.139.211:51549] by server-10.bemta-5.messagelabs.com id
	D0/7B-01025-4CABE705; Wed, 17 Oct 2012 14:03:48 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1350482626!22719556!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgxNjgxMg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 613 invoked from network); 17 Oct 2012 14:03:47 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Oct 2012 14:03:47 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9HE3abC025256
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Oct 2012 14:03:37 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9HE3ZmV027407
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Oct 2012 14:03:35 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9HE3Yk4011387; Wed, 17 Oct 2012 09:03:34 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 07:03:34 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 11F0E40376; Wed, 17 Oct 2012 09:49:53 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	lenb@kernel.org, linux-acpi@vger.kernel.org, hpa@zytor.com, x86@kernel.org
Date: Wed, 17 Oct 2012 09:49:45 -0400
Message-Id: <1350481786-4969-4-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 3/4] xen/lowlevel: Implement pvop call for
	store_gdt (gidt)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In the past it used to point to 'sgdt' (native_store_gdt)
operation which is a non-privileged operation. This resulted
in the value of 'struct desc_ptr' pointing to an bogus address
0xffff820000000000, instead of the GDT table that Linux thinks
it is using. The end result is that doing:

      store_gdt(&desc);
      load_gdt(&desc);

would blow up b/c xen_load_gdt would try to parse the GDT contents
(desc) and de-reference an bogus virtual address.

With this patch we are providing the last written address and size
of the GDT.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/xen/enlighten.c |   16 +++++++++++++++-
 1 files changed, 15 insertions(+), 1 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index f29d6d6..4a65138 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -471,6 +471,8 @@ static void xen_set_ldt(const void *addr, unsigned entries)
 	xen_mc_issue(PARAVIRT_LAZY_CPU);
 }
 
+static DEFINE_PER_CPU(struct desc_ptr, gdt_desc);
+
 static void xen_load_gdt(const struct desc_ptr *dtr)
 {
 	unsigned long va = dtr->address;
@@ -478,6 +480,7 @@ static void xen_load_gdt(const struct desc_ptr *dtr)
 	unsigned pages = (size + PAGE_SIZE - 1) / PAGE_SIZE;
 	unsigned long frames[pages];
 	int f;
+	struct desc_ptr *shadow;
 
 	/*
 	 * A GDT can be up to 64k in size, which corresponds to 8192
@@ -515,8 +518,19 @@ static void xen_load_gdt(const struct desc_ptr *dtr)
 
 	if (HYPERVISOR_set_gdt(frames, size / sizeof(struct desc_struct)))
 		BUG();
+
+	shadow = &__get_cpu_var(gdt_desc);
+	shadow->address = dtr->address;
+	shadow->size = size;
 }
 
+static void xen_store_gdt(struct desc_ptr *dtr)
+{
+	const struct desc_ptr *desc = &__get_cpu_var(gdt_desc);
+
+	dtr->address = desc->address;
+	dtr->size = desc->size;
+}
 /*
  * load_gdt for early boot, when the gdt is only mapped once
  */
@@ -1205,7 +1219,7 @@ static const struct pv_cpu_ops xen_cpu_ops __initconst = {
 	.alloc_ldt = xen_alloc_ldt,
 	.free_ldt = xen_free_ldt,
 
-	.store_gdt = native_store_gdt,
+	.store_gdt = xen_store_gdt,
 	.store_idt = xen_store_idt,
 	.store_tr = xen_store_tr,
 
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 14:04:00 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 14:04:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOUDr-0004FO-7w; Wed, 17 Oct 2012 14:03:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOUDp-0004F7-Nk
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 14:03:45 +0000
Received: from [85.158.143.99:21813] by server-1.bemta-4.messagelabs.com id
	60/7C-19134-1CABE705; Wed, 17 Oct 2012 14:03:45 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1350482623!34462196!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgxNjgxMg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13894 invoked from network); 17 Oct 2012 14:03:44 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Oct 2012 14:03:44 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9HE3d19025349
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Oct 2012 14:03:40 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9HE3ZTq018462
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Oct 2012 14:03:37 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9HE3ZFT005222; Wed, 17 Oct 2012 09:03:35 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 07:03:34 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1C5B24031C; Wed, 17 Oct 2012 09:49:53 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	lenb@kernel.org, linux-acpi@vger.kernel.org, hpa@zytor.com, x86@kernel.org
Date: Wed, 17 Oct 2012 09:49:44 -0400
Message-Id: <1350481786-4969-3-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 2/4] xen/lowlevel: Implement pvop call for
	load_idt (sidt).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In the past it used to point to 'sidt' (native_store_idt) operation
which is a non-privileged operation. This resulted in the
'struct desc_ptr' value containing the address of Xen's IDT table,
instead of the IDT table that Linux thinks its using. The end result
is that doing:

  store_idt(&desc);
  load_idt(&desc);

would blow up b/c xen_load_idt would try to parse the IDT contents
(desc) and de-reference a virtual address that is outside Linux's
__va (it is in Xen's virtual address).

With this patch we are providing the last written IDT address.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/xen/enlighten.c |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index e3497f2..f29d6d6 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -777,7 +777,13 @@ static void xen_load_idt(const struct desc_ptr *desc)
 
 	spin_unlock(&lock);
 }
+static void xen_store_idt(struct desc_ptr *dtr)
+{
+	const struct desc_ptr *desc = &__get_cpu_var(idt_desc);
 
+	dtr->address = desc->address;
+	dtr->size = desc->size;
+}
 /* Write a GDT descriptor entry.  Ignore LDT descriptors, since
    they're handled differently. */
 static void xen_write_gdt_entry(struct desc_struct *dt, int entry,
@@ -1200,7 +1206,7 @@ static const struct pv_cpu_ops xen_cpu_ops __initconst = {
 	.free_ldt = xen_free_ldt,
 
 	.store_gdt = native_store_gdt,
-	.store_idt = native_store_idt,
+	.store_idt = xen_store_idt,
 	.store_tr = xen_store_tr,
 
 	.write_ldt_entry = xen_write_ldt_entry,
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 14:04:00 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 14:04:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOUDr-0004FO-7w; Wed, 17 Oct 2012 14:03:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOUDp-0004F7-Nk
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 14:03:45 +0000
Received: from [85.158.143.99:21813] by server-1.bemta-4.messagelabs.com id
	60/7C-19134-1CABE705; Wed, 17 Oct 2012 14:03:45 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1350482623!34462196!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgxNjgxMg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13894 invoked from network); 17 Oct 2012 14:03:44 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Oct 2012 14:03:44 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9HE3d19025349
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Oct 2012 14:03:40 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9HE3ZTq018462
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Oct 2012 14:03:37 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9HE3ZFT005222; Wed, 17 Oct 2012 09:03:35 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 07:03:34 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1C5B24031C; Wed, 17 Oct 2012 09:49:53 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	lenb@kernel.org, linux-acpi@vger.kernel.org, hpa@zytor.com, x86@kernel.org
Date: Wed, 17 Oct 2012 09:49:44 -0400
Message-Id: <1350481786-4969-3-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 2/4] xen/lowlevel: Implement pvop call for
	load_idt (sidt).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In the past it used to point to 'sidt' (native_store_idt) operation
which is a non-privileged operation. This resulted in the
'struct desc_ptr' value containing the address of Xen's IDT table,
instead of the IDT table that Linux thinks its using. The end result
is that doing:

  store_idt(&desc);
  load_idt(&desc);

would blow up b/c xen_load_idt would try to parse the IDT contents
(desc) and de-reference a virtual address that is outside Linux's
__va (it is in Xen's virtual address).

With this patch we are providing the last written IDT address.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/xen/enlighten.c |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index e3497f2..f29d6d6 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -777,7 +777,13 @@ static void xen_load_idt(const struct desc_ptr *desc)
 
 	spin_unlock(&lock);
 }
+static void xen_store_idt(struct desc_ptr *dtr)
+{
+	const struct desc_ptr *desc = &__get_cpu_var(idt_desc);
 
+	dtr->address = desc->address;
+	dtr->size = desc->size;
+}
 /* Write a GDT descriptor entry.  Ignore LDT descriptors, since
    they're handled differently. */
 static void xen_write_gdt_entry(struct desc_struct *dt, int entry,
@@ -1200,7 +1206,7 @@ static const struct pv_cpu_ops xen_cpu_ops __initconst = {
 	.free_ldt = xen_free_ldt,
 
 	.store_gdt = native_store_gdt,
-	.store_idt = native_store_idt,
+	.store_idt = xen_store_idt,
 	.store_tr = xen_store_tr,
 
 	.write_ldt_entry = xen_write_ldt_entry,
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 14:04:00 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 14:04:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOUDu-0004GE-Pg; Wed, 17 Oct 2012 14:03:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOUDt-0004Fv-Vy
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 14:03:50 +0000
Received: from [85.158.137.99:61247] by server-6.bemta-3.messagelabs.com id
	EB/63-32375-5CABE705; Wed, 17 Oct 2012 14:03:49 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1350482627!16893481!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODA5NzQy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18304 invoked from network); 17 Oct 2012 14:03:48 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Oct 2012 14:03:48 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9HE3dQA030664
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Oct 2012 14:03:40 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9HE3Z9s018461
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Oct 2012 14:03:37 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9HE3Yel011386; Wed, 17 Oct 2012 09:03:34 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 07:03:34 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1A91040356; Wed, 17 Oct 2012 09:49:53 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	lenb@kernel.org, linux-acpi@vger.kernel.org, hpa@zytor.com, x86@kernel.org
Date: Wed, 17 Oct 2012 09:49:42 -0400
Message-Id: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: [Xen-devel] [RFC] ACPI S3 and Xen (suprisingly small\!).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>From Konrad Rzeszutek Wilk  # This line is ignored.
From: Konrad Rzeszutek Wilk 
Subject: [RFC] ACPI S3 and Xen (surprisingly small\!).
In-Reply-To: 

Hey,

Way back at the LinuxPlumbers 2012 I chatted with Len about the issue
with Xen and Linux not working very well when suspending. We did a bit
of brainstorming and armed with these ideas I started looking at this.

The end result is this is a nice set of patches where there is only
_one_ change in the x86 code (and it is just more of dealing with
error case) - and the rest are all done in Xen side.

The change is to check whether there is a TSS GDT descriptor before
trying to set it. On 64-bit Xen there is no TSS and we ignore any
calls to set such field.

The bulk of the Xen code is filling out some of the pvops calls
(some of them are already in v3.7-rc1), and one to "prep" the cr3
value so that the hypervisor is fine with it.

Note: These are the other patches that went in 3.7-rc1:
xen/bootup: allow {read|write}_cr8 pvops call [https://lkml.org/lkml/2012/10/10/339]
xen/bootup: allow read_tscp call for Xen PV guests. [https://lkml.org/lkml/2012/10/10/340]

Anyhow, with these patches ACPI S3 suspend/resume of Linux works great!

 arch/x86/power/cpu.c     |    7 +++++--
 arch/x86/xen/enlighten.c |   24 ++++++++++++++++++++++--
 drivers/xen/acpi.c       |   25 +++++++++++++++++++++++++
 3 files changed, 52 insertions(+), 4 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 14:04:00 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 14:04:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOUDr-0004FV-Jq; Wed, 17 Oct 2012 14:03:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOUDp-0004F8-Q1
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 14:03:46 +0000
Received: from [85.158.138.51:10724] by server-9.bemta-3.messagelabs.com id
	AF/95-16841-1CABE705; Wed, 17 Oct 2012 14:03:45 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1350482623!32941632!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODA5NzQy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5414 invoked from network); 17 Oct 2012 14:03:44 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Oct 2012 14:03:44 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9HE3dHG030665
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Oct 2012 14:03:40 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9HE3aYv018500
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Oct 2012 14:03:37 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9HE3aGt011402; Wed, 17 Oct 2012 09:03:36 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 07:03:36 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 17D6E4035E; Wed, 17 Oct 2012 09:49:53 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	lenb@kernel.org, linux-acpi@vger.kernel.org, hpa@zytor.com, x86@kernel.org
Date: Wed, 17 Oct 2012 09:49:43 -0400
Message-Id: <1350481786-4969-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 1/4] x86/wakeup/sleep: Check whether the TSS GDT
	descriptor is empty before using it.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We check the TSS descriptor before we try to dereference it.
Also fix up the value to use the #defines.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/power/cpu.c |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/x86/power/cpu.c b/arch/x86/power/cpu.c
index 218cdb1..c17370e 100644
--- a/arch/x86/power/cpu.c
+++ b/arch/x86/power/cpu.c
@@ -133,7 +133,9 @@ static void fix_processor_context(void)
 {
 	int cpu = smp_processor_id();
 	struct tss_struct *t = &per_cpu(init_tss, cpu);
-
+#ifdef CONFIG_X86_64
+	struct desc_struct *desc = get_cpu_gdt_table(cpu);
+#endif
 	set_tss_desc(cpu, t);	/*
 				 * This just modifies memory; should not be
 				 * necessary. But... This is necessary, because
@@ -142,7 +144,8 @@ static void fix_processor_context(void)
 				 */
 
 #ifdef CONFIG_X86_64
-	get_cpu_gdt_table(cpu)[GDT_ENTRY_TSS].type = 9;
+	if (!desc_empty(&desc[GDT_ENTRY_TSS]))
+		desc[GDT_ENTRY_TSS].type = DESC_TSS;
 
 	syscall_init();				/* This sets MSR_*STAR and related */
 #endif
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 14:04:00 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 14:04:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOUDu-0004GE-Pg; Wed, 17 Oct 2012 14:03:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOUDt-0004Fv-Vy
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 14:03:50 +0000
Received: from [85.158.137.99:61247] by server-6.bemta-3.messagelabs.com id
	EB/63-32375-5CABE705; Wed, 17 Oct 2012 14:03:49 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1350482627!16893481!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODA5NzQy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18304 invoked from network); 17 Oct 2012 14:03:48 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Oct 2012 14:03:48 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9HE3dQA030664
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Oct 2012 14:03:40 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9HE3Z9s018461
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Oct 2012 14:03:37 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9HE3Yel011386; Wed, 17 Oct 2012 09:03:34 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 07:03:34 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1A91040356; Wed, 17 Oct 2012 09:49:53 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	lenb@kernel.org, linux-acpi@vger.kernel.org, hpa@zytor.com, x86@kernel.org
Date: Wed, 17 Oct 2012 09:49:42 -0400
Message-Id: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: [Xen-devel] [RFC] ACPI S3 and Xen (suprisingly small\!).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>From Konrad Rzeszutek Wilk  # This line is ignored.
From: Konrad Rzeszutek Wilk 
Subject: [RFC] ACPI S3 and Xen (surprisingly small\!).
In-Reply-To: 

Hey,

Way back at the LinuxPlumbers 2012 I chatted with Len about the issue
with Xen and Linux not working very well when suspending. We did a bit
of brainstorming and armed with these ideas I started looking at this.

The end result is this is a nice set of patches where there is only
_one_ change in the x86 code (and it is just more of dealing with
error case) - and the rest are all done in Xen side.

The change is to check whether there is a TSS GDT descriptor before
trying to set it. On 64-bit Xen there is no TSS and we ignore any
calls to set such field.

The bulk of the Xen code is filling out some of the pvops calls
(some of them are already in v3.7-rc1), and one to "prep" the cr3
value so that the hypervisor is fine with it.

Note: These are the other patches that went in 3.7-rc1:
xen/bootup: allow {read|write}_cr8 pvops call [https://lkml.org/lkml/2012/10/10/339]
xen/bootup: allow read_tscp call for Xen PV guests. [https://lkml.org/lkml/2012/10/10/340]

Anyhow, with these patches ACPI S3 suspend/resume of Linux works great!

 arch/x86/power/cpu.c     |    7 +++++--
 arch/x86/xen/enlighten.c |   24 ++++++++++++++++++++++--
 drivers/xen/acpi.c       |   25 +++++++++++++++++++++++++
 3 files changed, 52 insertions(+), 4 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 14:04:00 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 14:04:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOUDr-0004FV-Jq; Wed, 17 Oct 2012 14:03:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOUDp-0004F8-Q1
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 14:03:46 +0000
Received: from [85.158.138.51:10724] by server-9.bemta-3.messagelabs.com id
	AF/95-16841-1CABE705; Wed, 17 Oct 2012 14:03:45 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1350482623!32941632!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODA5NzQy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5414 invoked from network); 17 Oct 2012 14:03:44 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Oct 2012 14:03:44 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9HE3dHG030665
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Oct 2012 14:03:40 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9HE3aYv018500
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Oct 2012 14:03:37 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9HE3aGt011402; Wed, 17 Oct 2012 09:03:36 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 07:03:36 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 17D6E4035E; Wed, 17 Oct 2012 09:49:53 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	lenb@kernel.org, linux-acpi@vger.kernel.org, hpa@zytor.com, x86@kernel.org
Date: Wed, 17 Oct 2012 09:49:43 -0400
Message-Id: <1350481786-4969-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 1/4] x86/wakeup/sleep: Check whether the TSS GDT
	descriptor is empty before using it.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We check the TSS descriptor before we try to dereference it.
Also fix up the value to use the #defines.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/power/cpu.c |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/x86/power/cpu.c b/arch/x86/power/cpu.c
index 218cdb1..c17370e 100644
--- a/arch/x86/power/cpu.c
+++ b/arch/x86/power/cpu.c
@@ -133,7 +133,9 @@ static void fix_processor_context(void)
 {
 	int cpu = smp_processor_id();
 	struct tss_struct *t = &per_cpu(init_tss, cpu);
-
+#ifdef CONFIG_X86_64
+	struct desc_struct *desc = get_cpu_gdt_table(cpu);
+#endif
 	set_tss_desc(cpu, t);	/*
 				 * This just modifies memory; should not be
 				 * necessary. But... This is necessary, because
@@ -142,7 +144,8 @@ static void fix_processor_context(void)
 				 */
 
 #ifdef CONFIG_X86_64
-	get_cpu_gdt_table(cpu)[GDT_ENTRY_TSS].type = 9;
+	if (!desc_empty(&desc[GDT_ENTRY_TSS]))
+		desc[GDT_ENTRY_TSS].type = DESC_TSS;
 
 	syscall_init();				/* This sets MSR_*STAR and related */
 #endif
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 14:18:13 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 14:18:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOURa-000526-PL; Wed, 17 Oct 2012 14:17:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOURY-000521-P5
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 14:17:57 +0000
Received: from [85.158.139.83:8011] by server-5.bemta-5.messagelabs.com id
	6E/20-09732-31EBE705; Wed, 17 Oct 2012 14:17:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1350483474!32443772!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27041 invoked from network); 17 Oct 2012 14:17:55 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 14:17:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,600,1344211200"; d="scan'208";a="15228430"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 14:17:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 17 Oct 2012 15:17:54 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TOURW-0007HB-Gz;
	Wed, 17 Oct 2012 14:17:54 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TOURW-0005nN-GS;
	Wed, 17 Oct 2012 15:17:54 +0100
To: 
Message-ID: 
From: xen.org 
Date: Wed, 17 Oct 2012 15:17:54 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13995: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13995 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13995/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 13967
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-pv            5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 13967
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 13967
 test-amd64-amd64-xl           5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                fail REGR. vs. 13967
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 13967
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 13967
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 13967
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 13967
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot          fail REGR. vs. 13967

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13967
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13967

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  4b4c0c7a6031
baseline version:
 xen                  c1c549c4fe9e

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf 
  Huang Ying 
  Jan Beulich 
  Keir Fraser 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26061:4b4c0c7a6031
tag:         tip
user:        Jan Beulich 
date:        Wed Oct 17 11:23:10 2012 +0200
    
    x86/oprof: adjust off-by-one counter range checks
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    
    
changeset:   26060:4fc87c2f31a0
user:        Huang Ying 
date:        Tue Oct 16 17:26:36 2012 +0200
    
    ACPI: fix APEI related table size checking
    
    On Huang Ying's machine:
    
    erst_tab->header_length == sizeof(struct acpi_table_einj)
    
    but Yinghai reported that on his machine,
    
    erst_tab->header_length == sizeof(struct acpi_table_einj) -
    sizeof(struct acpi_table_header)
    
    To make erst table size checking code works on all systems, both
    testing are treated as PASS.
    
    Same situation applies to einj_tab->header_length, so corresponding
    table size checking is changed in similar way too.
    
    Originally-by: Yinghai Lu 
    Signed-off-by: Huang Ying 
    
    - use switch() for better readability
    - add comment explaining why a formally invalid size it also being
      accepted
    - check erst_tab->header.length before even looking at
      erst_tab->header_length
    - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    Committed-by: Jan Beulich 
    
    
changeset:   26059:c1c549c4fe9e
user:        Daniel De Graaf 
date:        Mon Oct 15 16:51:44 2012 +0100
    
    xen: Add versions of rcu_lock_*_domain without IS_PRIV
    
    These functions will be used to avoid duplication of IS_PRIV calls
    that will be introduced in XSM hooks. This also fixes a build error
    with XSM enabled introduced by 25925:d1c3375c3f11 which depends on
    this patch.
    
    Signed-off-by: Daniel De Graaf 
    Committed-by: Keir Fraser 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 14:18:13 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 14:18:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOURa-000526-PL; Wed, 17 Oct 2012 14:17:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOURY-000521-P5
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 14:17:57 +0000
Received: from [85.158.139.83:8011] by server-5.bemta-5.messagelabs.com id
	6E/20-09732-31EBE705; Wed, 17 Oct 2012 14:17:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1350483474!32443772!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27041 invoked from network); 17 Oct 2012 14:17:55 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 14:17:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,600,1344211200"; d="scan'208";a="15228430"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 14:17:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 17 Oct 2012 15:17:54 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TOURW-0007HB-Gz;
	Wed, 17 Oct 2012 14:17:54 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TOURW-0005nN-GS;
	Wed, 17 Oct 2012 15:17:54 +0100
To: 
Message-ID: 
From: xen.org 
Date: Wed, 17 Oct 2012 15:17:54 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13995: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13995 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13995/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 13967
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-pv            5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 13967
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 13967
 test-amd64-amd64-xl           5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                fail REGR. vs. 13967
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 13967
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 13967
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 13967
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 13967
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot          fail REGR. vs. 13967

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13967
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13967

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  4b4c0c7a6031
baseline version:
 xen                  c1c549c4fe9e

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf 
  Huang Ying 
  Jan Beulich 
  Keir Fraser 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26061:4b4c0c7a6031
tag:         tip
user:        Jan Beulich 
date:        Wed Oct 17 11:23:10 2012 +0200
    
    x86/oprof: adjust off-by-one counter range checks
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    
    
changeset:   26060:4fc87c2f31a0
user:        Huang Ying 
date:        Tue Oct 16 17:26:36 2012 +0200
    
    ACPI: fix APEI related table size checking
    
    On Huang Ying's machine:
    
    erst_tab->header_length == sizeof(struct acpi_table_einj)
    
    but Yinghai reported that on his machine,
    
    erst_tab->header_length == sizeof(struct acpi_table_einj) -
    sizeof(struct acpi_table_header)
    
    To make erst table size checking code works on all systems, both
    testing are treated as PASS.
    
    Same situation applies to einj_tab->header_length, so corresponding
    table size checking is changed in similar way too.
    
    Originally-by: Yinghai Lu 
    Signed-off-by: Huang Ying 
    
    - use switch() for better readability
    - add comment explaining why a formally invalid size it also being
      accepted
    - check erst_tab->header.length before even looking at
      erst_tab->header_length
    - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    Committed-by: Jan Beulich 
    
    
changeset:   26059:c1c549c4fe9e
user:        Daniel De Graaf 
date:        Mon Oct 15 16:51:44 2012 +0100
    
    xen: Add versions of rcu_lock_*_domain without IS_PRIV
    
    These functions will be used to avoid duplication of IS_PRIV calls
    that will be introduced in XSM hooks. This also fixes a build error
    with XSM enabled introduced by 25925:d1c3375c3f11 which depends on
    this patch.
    
    Signed-off-by: Daniel De Graaf 
    Committed-by: Keir Fraser 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 14:52:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 14:52:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOUyR-0005LK-19; Wed, 17 Oct 2012 14:51:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOUyP-0005LF-Hj
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 14:51:53 +0000
Received: from [193.109.254.147:37424] by server-15.bemta-14.messagelabs.com
	id 84/C9-16351-806CE705; Wed, 17 Oct 2012 14:51:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1350485512!2565559!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2323 invoked from network); 17 Oct 2012 14:51:52 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-27.messagelabs.com with SMTP;
	17 Oct 2012 14:51:52 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 17 Oct 2012 15:51:51 +0100
Message-Id: <507EE22602000078000A20DB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 17 Oct 2012 15:51:50 +0100
From: "Jan Beulich" 
To: "Andrew Cooper" 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
In-Reply-To: <507EB27D.8050308@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk , stefan.bader@canonical.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 17.10.12 at 15:28, Andrew Cooper  wrote:
> In our case, certain processes were locking up, and it turned out that
> the kernel was issuing SCHOP_poll hypercalls (same the stack trace on
> your launchpad ticket) on its own spinlock IPI event channel
> (understandable, as its a spinlock), but with the event channel masked,
> so it would never wake up from the poll.

Probably some misunderstanding: The event channel used
here will always be masked, and whether an event channel is
masked doesn't matter for the purposes of polling it.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 14:52:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 14:52:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOUyR-0005LK-19; Wed, 17 Oct 2012 14:51:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOUyP-0005LF-Hj
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 14:51:53 +0000
Received: from [193.109.254.147:37424] by server-15.bemta-14.messagelabs.com
	id 84/C9-16351-806CE705; Wed, 17 Oct 2012 14:51:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1350485512!2565559!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2323 invoked from network); 17 Oct 2012 14:51:52 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-27.messagelabs.com with SMTP;
	17 Oct 2012 14:51:52 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 17 Oct 2012 15:51:51 +0100
Message-Id: <507EE22602000078000A20DB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 17 Oct 2012 15:51:50 +0100
From: "Jan Beulich" 
To: "Andrew Cooper" 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
In-Reply-To: <507EB27D.8050308@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk , stefan.bader@canonical.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 17.10.12 at 15:28, Andrew Cooper  wrote:
> In our case, certain processes were locking up, and it turned out that
> the kernel was issuing SCHOP_poll hypercalls (same the stack trace on
> your launchpad ticket) on its own spinlock IPI event channel
> (understandable, as its a spinlock), but with the event channel masked,
> so it would never wake up from the poll.

Probably some misunderstanding: The event channel used
here will always be masked, and whether an event channel is
masked doesn't matter for the purposes of polling it.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 15:04:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 15:04:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOV9z-0005YR-HI; Wed, 17 Oct 2012 15:03:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOV9y-0005YM-Bk
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 15:03:50 +0000
Received: from [85.158.137.99:3293] by server-16.bemta-3.messagelabs.com id
	9C/98-16565-5D8CE705; Wed, 17 Oct 2012 15:03:49 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1350486227!17161459!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgxNjgxMg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18023 invoked from network); 17 Oct 2012 15:03:48 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-7.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Oct 2012 15:03:48 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9HF3fq8012693
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Oct 2012 15:03:42 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9HF3cee000877
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Oct 2012 15:03:41 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9HF3ZII022359; Wed, 17 Oct 2012 10:03:36 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 08:03:35 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 3807D4035B; Wed, 17 Oct 2012 10:51:34 -0400 (EDT)
Date: Wed, 17 Oct 2012 10:51:34 -0400
From: Konrad Rzeszutek Wilk 
To: Jan Beulich 
Message-ID: <20121017145134.GA7594@phenom.dumpdata.com>
References: <507E76BC02000078000A1DCD@nat28.tlf.novell.com>
	<1350467755-4825-1-git-send-email-lersek@redhat.com>
	<507E9E0D02000078000A1EDB@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <507E9E0D02000078000A1EDB@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: andrew.cooper3@citrix.com, jeremy@goop.org,
	Laszlo Ersek , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] xen PV passthru: assign SR-IOV virtual
 functions to separate virtual slots
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 17, 2012 at 11:01:17AM +0100, Jan Beulich wrote:
> >>> On 17.10.12 at 11:55, Laszlo Ersek  wrote:
> > VFs are reported as single-function devices in PCI_HEADER_TYPE, which
> > causes pci_scan_slot() in the PV domU to skip all VFs beyond #0 in the
> > pciback-provided slot. Avoid this by assigning each VF to a separate
> > virtual slot.
> > 
> > Signed-off-by: Laszlo Ersek 
> 
> Acked-by: Jan Beulich 

Applied.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 15:04:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 15:04:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOV9z-0005YR-HI; Wed, 17 Oct 2012 15:03:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOV9y-0005YM-Bk
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 15:03:50 +0000
Received: from [85.158.137.99:3293] by server-16.bemta-3.messagelabs.com id
	9C/98-16565-5D8CE705; Wed, 17 Oct 2012 15:03:49 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1350486227!17161459!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgxNjgxMg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18023 invoked from network); 17 Oct 2012 15:03:48 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-7.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Oct 2012 15:03:48 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9HF3fq8012693
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Oct 2012 15:03:42 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9HF3cee000877
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Oct 2012 15:03:41 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9HF3ZII022359; Wed, 17 Oct 2012 10:03:36 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 08:03:35 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 3807D4035B; Wed, 17 Oct 2012 10:51:34 -0400 (EDT)
Date: Wed, 17 Oct 2012 10:51:34 -0400
From: Konrad Rzeszutek Wilk 
To: Jan Beulich 
Message-ID: <20121017145134.GA7594@phenom.dumpdata.com>
References: <507E76BC02000078000A1DCD@nat28.tlf.novell.com>
	<1350467755-4825-1-git-send-email-lersek@redhat.com>
	<507E9E0D02000078000A1EDB@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <507E9E0D02000078000A1EDB@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: andrew.cooper3@citrix.com, jeremy@goop.org,
	Laszlo Ersek , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] xen PV passthru: assign SR-IOV virtual
 functions to separate virtual slots
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 17, 2012 at 11:01:17AM +0100, Jan Beulich wrote:
> >>> On 17.10.12 at 11:55, Laszlo Ersek  wrote:
> > VFs are reported as single-function devices in PCI_HEADER_TYPE, which
> > causes pci_scan_slot() in the PV domU to skip all VFs beyond #0 in the
> > pciback-provided slot. Avoid this by assigning each VF to a separate
> > virtual slot.
> > 
> > Signed-off-by: Laszlo Ersek 
> 
> Acked-by: Jan Beulich 

Applied.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 15:08:34 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 15:08:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOVEC-0005gj-F5; Wed, 17 Oct 2012 15:08:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOVEA-0005gc-U8
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 15:08:11 +0000
Received: from [85.158.143.99:52786] by server-2.bemta-4.messagelabs.com id
	5D/DB-22268-AD9CE705; Wed, 17 Oct 2012 15:08:10 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1350486488!34472602!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgxNjgxMg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9036 invoked from network); 17 Oct 2012 15:08:09 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Oct 2012 15:08:09 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9HF85Gg018779
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Oct 2012 15:08:06 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9HF84Vr010768
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Oct 2012 15:08:04 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9HF84lb026129; Wed, 17 Oct 2012 10:08:04 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 08:08:03 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 8B7194035B; Wed, 17 Oct 2012 10:56:02 -0400 (EDT)
Date: Wed, 17 Oct 2012 10:56:02 -0400
From: Konrad Rzeszutek Wilk 
To: Jan Beulich 
Message-ID: <20121017145602.GB7594@phenom.dumpdata.com>
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
	<1350463157-5068-1-git-send-email-ian.campbell@citrix.com>
	<507E91E602000078000A1E76@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <507E91E602000078000A1E76@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Stefano Stabellini ,
	Ian Campbell , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 01/10] xen: xenbus: quirk uses x86 specific
 cpuid
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 17, 2012 at 10:09:26AM +0100, Jan Beulich wrote:
> >>> On 17.10.12 at 10:39, Ian Campbell  wrote:
> > --- a/drivers/xen/xenbus/xenbus_xs.c
> > +++ b/drivers/xen/xenbus/xenbus_xs.c
> > @@ -619,6 +619,8 @@ static struct xenbus_watch *find_watch(const char *token)
> >  
> >  	return NULL;
> >  }
> > +
> > +#ifdef CONFIG_X86
> >  /*
> >   * Certain older XenBus toolstack cannot handle reading values that are
> >   * not populated. Some Xen 3.4 installation are incapable of doing this
> > @@ -637,6 +639,10 @@ static bool xen_strict_xenbus_quirk()
> >  	return false;
> >  
> >  }
> > +#else
> > +static bool xen_strict_xenbus_quirk(void) { return false; }
> > +#endif
> 
> Wouldn't it reduce redundancy if the #ifdef block was inserted
> inside the existing function?

Applied with Jan's suggestions.
> 
> Jan
> 
> > +
> >  static void xs_reset_watches(void)
> >  {
> >  	int err, supported = 0;
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 15:08:34 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 15:08:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOVEC-0005gj-F5; Wed, 17 Oct 2012 15:08:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOVEA-0005gc-U8
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 15:08:11 +0000
Received: from [85.158.143.99:52786] by server-2.bemta-4.messagelabs.com id
	5D/DB-22268-AD9CE705; Wed, 17 Oct 2012 15:08:10 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1350486488!34472602!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgxNjgxMg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9036 invoked from network); 17 Oct 2012 15:08:09 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Oct 2012 15:08:09 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9HF85Gg018779
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Oct 2012 15:08:06 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9HF84Vr010768
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Oct 2012 15:08:04 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9HF84lb026129; Wed, 17 Oct 2012 10:08:04 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 08:08:03 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 8B7194035B; Wed, 17 Oct 2012 10:56:02 -0400 (EDT)
Date: Wed, 17 Oct 2012 10:56:02 -0400
From: Konrad Rzeszutek Wilk 
To: Jan Beulich 
Message-ID: <20121017145602.GB7594@phenom.dumpdata.com>
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
	<1350463157-5068-1-git-send-email-ian.campbell@citrix.com>
	<507E91E602000078000A1E76@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <507E91E602000078000A1E76@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Stefano Stabellini ,
	Ian Campbell , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 01/10] xen: xenbus: quirk uses x86 specific
 cpuid
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 17, 2012 at 10:09:26AM +0100, Jan Beulich wrote:
> >>> On 17.10.12 at 10:39, Ian Campbell  wrote:
> > --- a/drivers/xen/xenbus/xenbus_xs.c
> > +++ b/drivers/xen/xenbus/xenbus_xs.c
> > @@ -619,6 +619,8 @@ static struct xenbus_watch *find_watch(const char *token)
> >  
> >  	return NULL;
> >  }
> > +
> > +#ifdef CONFIG_X86
> >  /*
> >   * Certain older XenBus toolstack cannot handle reading values that are
> >   * not populated. Some Xen 3.4 installation are incapable of doing this
> > @@ -637,6 +639,10 @@ static bool xen_strict_xenbus_quirk()
> >  	return false;
> >  
> >  }
> > +#else
> > +static bool xen_strict_xenbus_quirk(void) { return false; }
> > +#endif
> 
> Wouldn't it reduce redundancy if the #ifdef block was inserted
> inside the existing function?

Applied with Jan's suggestions.
> 
> Jan
> 
> > +
> >  static void xs_reset_watches(void)
> >  {
> >  	int err, supported = 0;
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 15:13:51 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 15:13:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOVJH-0005qx-Ab; Wed, 17 Oct 2012 15:13:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOVJG-0005qs-33
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 15:13:26 +0000
Received: from [85.158.138.51:54819] by server-15.bemta-3.messagelabs.com id
	84/DC-10261-51BCE705; Wed, 17 Oct 2012 15:13:25 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1350486803!26656698!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzcwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32334 invoked from network); 17 Oct 2012 15:13:24 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 15:13:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,601,1344211200"; d="scan'208";a="41524595"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 15:12:56 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 11:12:56 -0400
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TOVIm-0001C7-5H;
	Wed, 17 Oct 2012 16:12:56 +0100
Message-ID: <507ECAF8.7050709@citrix.com>
Date: Wed, 17 Oct 2012 16:12:56 +0100
From: Andrew Cooper 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Jan Beulich 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
	<507EE22602000078000A20DB@nat28.tlf.novell.com>
In-Reply-To: <507EE22602000078000A20DB@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.5
Cc: Konrad Rzeszutek Wilk ,
	"stefan.bader@canonical.com" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/10/12 15:51, Jan Beulich wrote:
>>>> On 17.10.12 at 15:28, Andrew Cooper  wrote:
>> In our case, certain processes were locking up, and it turned out that
>> the kernel was issuing SCHOP_poll hypercalls (same the stack trace on
>> your launchpad ticket) on its own spinlock IPI event channel
>> (understandable, as its a spinlock), but with the event channel masked,
>> so it would never wake up from the poll.
> Probably some misunderstanding: The event channel used
> here will always be masked, and whether an event channel is
> masked doesn't matter for the purposes of polling it.
>
> Jan
>

Sorry - I was not very clear.

In our case, we saw every single VCPU stuck in a SCHEDOP_poll on its own
spinlock event channel, which renderes the guest completely deadlocked.

My understanding was that while some VCPUs were blocked in the
hypervisor, the VCPU with the lock should raise an event when the lock
was released, waking the other VCPUs so one could grab the lock.  This
implication of this being that there is a bug in the spinlock code.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 15:13:51 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 15:13:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOVJH-0005qx-Ab; Wed, 17 Oct 2012 15:13:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOVJG-0005qs-33
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 15:13:26 +0000
Received: from [85.158.138.51:54819] by server-15.bemta-3.messagelabs.com id
	84/DC-10261-51BCE705; Wed, 17 Oct 2012 15:13:25 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1350486803!26656698!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzcwNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32334 invoked from network); 17 Oct 2012 15:13:24 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 15:13:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,601,1344211200"; d="scan'208";a="41524595"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 15:12:56 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 11:12:56 -0400
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TOVIm-0001C7-5H;
	Wed, 17 Oct 2012 16:12:56 +0100
Message-ID: <507ECAF8.7050709@citrix.com>
Date: Wed, 17 Oct 2012 16:12:56 +0100
From: Andrew Cooper 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Jan Beulich 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
	<507EE22602000078000A20DB@nat28.tlf.novell.com>
In-Reply-To: <507EE22602000078000A20DB@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.5
Cc: Konrad Rzeszutek Wilk ,
	"stefan.bader@canonical.com" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/10/12 15:51, Jan Beulich wrote:
>>>> On 17.10.12 at 15:28, Andrew Cooper  wrote:
>> In our case, certain processes were locking up, and it turned out that
>> the kernel was issuing SCHOP_poll hypercalls (same the stack trace on
>> your launchpad ticket) on its own spinlock IPI event channel
>> (understandable, as its a spinlock), but with the event channel masked,
>> so it would never wake up from the poll.
> Probably some misunderstanding: The event channel used
> here will always be masked, and whether an event channel is
> masked doesn't matter for the purposes of polling it.
>
> Jan
>

Sorry - I was not very clear.

In our case, we saw every single VCPU stuck in a SCHEDOP_poll on its own
spinlock event channel, which renderes the guest completely deadlocked.

My understanding was that while some VCPUs were blocked in the
hypervisor, the VCPU with the lock should raise an event when the lock
was released, waking the other VCPUs so one could grab the lock.  This
implication of this being that there is a bug in the spinlock code.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 15:15:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 15:15:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOVKQ-0005v8-Q2; Wed, 17 Oct 2012 15:14:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOVKP-0005uz-Nj
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 15:14:37 +0000
Received: from [85.158.143.35:49499] by server-2.bemta-4.messagelabs.com id
	D6/73-22268-D5BCE705; Wed, 17 Oct 2012 15:14:37 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1350486874!15640909!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODA5NzQy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25929 invoked from network); 17 Oct 2012 15:14:36 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Oct 2012 15:14:36 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9HFEPTK032132
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Oct 2012 15:14:26 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9HFEOHe006633
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Oct 2012 15:14:25 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9HFEOkg005211; Wed, 17 Oct 2012 10:14:24 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 08:14:24 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id CD6914035B; Wed, 17 Oct 2012 11:02:22 -0400 (EDT)
Date: Wed, 17 Oct 2012 11:02:22 -0400
From: Konrad Rzeszutek Wilk 
To: David Vrabel 
Message-ID: <20121017150222.GA8743@phenom.dumpdata.com>
References: <1350480580-4844-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1350480580-4844-1-git-send-email-david.vrabel@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Frediano Ziglio , stable@vger.kernel.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCHv2] xen/x86: don't corrupt %eip when
 returning from a signal handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 17, 2012 at 02:29:40PM +0100, David Vrabel wrote:
> From: David Vrabel 
> 
> In 32 bit guests, if a userspace process has %eax == -ERESTARTSYS
> (-512) or -ERESTARTNOINTR (-513) when it is interrupted by an event
> /and/ the process has a pending signal then %eip (and %eax) are
> corrupted when returning to the main process after handling the
> signal.  The application may then crash with SIGSEGV or a SIGILL or it
> may have subtly incorrect behaviour (depending on what instruction it
> returned to).
> 
> The occurs because handle_signal() is incorrectly thinking that there
> is a system call that needs to restarted so it adjusts %eip and %eax
> to re-execute the system call instruction (even though user space had
> not done a system call).
> 
> If %eax == -514 (-ERESTARTNOHAND (-514) or -ERESTART_RESTARTBLOCK
> (-516) then handle_signal() only corrupted %eax (by setting it to
> -EINTR).  This may cause the application to crash or have incorrect
> behaviour.
> 
> handle_signal() assumes that regs->orig_ax >= 0 means a system call so
> any kernel entry point that is not for a system call must push a
> negative value for orig_ax.  For example, for physical interrupts on
> bare metal the inverse of the vector is pushed and page_fault() sets
> regs->orig_ax to -1, overwriting the hardware provided error code.
> 
> xen_hypervisor_callback() was incorrectly pushing 0 for orig_ax
> instead of -1.
> 
> Classic Xen kernels pushed %eax which works as %eax cannot be both
> non-negative and -RESTARTSYS (etc.), but using -1 is consistent with
> other non-system call entry points.
> 
> There were similar bugs in xen_failsafe_callback(), if the fault was
> corrected and normal return path was used.  64 bit guests would push 0
> which is broken.  32 bit guests would push %eax which is safe (see
> previous paragraph), but for consistency this is also changed to -1.
> 
> Signed-off-by: David Vrabel 
> Acked-by: Jan Beulich 
> Acked-by: Ian Campbell 
> Cc: stable@vger.kernel.org

Applied.

> ---
>  arch/x86/kernel/entry_32.S |    4 ++--
>  arch/x86/kernel/entry_64.S |    2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
> index 2c63407..6a19e66 100644
> --- a/arch/x86/kernel/entry_32.S
> +++ b/arch/x86/kernel/entry_32.S
> @@ -1042,7 +1042,7 @@ ENTRY(xen_sysenter_target)
>  
>  ENTRY(xen_hypervisor_callback)
>  	CFI_STARTPROC
> -	pushl_cfi $0
> +	pushl_cfi $-1 /* orig_ax = -1 => not a system call */
>  	SAVE_ALL
>  	TRACE_IRQS_OFF
>  
> @@ -1078,7 +1078,7 @@ ENDPROC(xen_hypervisor_callback)
>  # We distinguish between categories by maintaining a status value in EAX.
>  ENTRY(xen_failsafe_callback)
>  	CFI_STARTPROC
> -	pushl_cfi %eax
> +	pushl_cfi $-1  /* orig_ax = -1 => not a system call */
>  	movl $1,%eax
>  1:	mov 4(%esp),%ds
>  2:	mov 8(%esp),%es
> diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
> index cdc790c..430b1fc 100644
> --- a/arch/x86/kernel/entry_64.S
> +++ b/arch/x86/kernel/entry_64.S
> @@ -1451,7 +1451,7 @@ ENTRY(xen_failsafe_callback)
>  	CFI_RESTORE r11
>  	addq $0x30,%rsp
>  	CFI_ADJUST_CFA_OFFSET -0x30
> -	pushq_cfi $0
> +	pushq_cfi $-1 /* orig_ax = -1 => not a system call */
>  	SAVE_ALL
>  	jmp error_exit
>  	CFI_ENDPROC
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 15:15:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 15:15:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOVKQ-0005v8-Q2; Wed, 17 Oct 2012 15:14:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOVKP-0005uz-Nj
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 15:14:37 +0000
Received: from [85.158.143.35:49499] by server-2.bemta-4.messagelabs.com id
	D6/73-22268-D5BCE705; Wed, 17 Oct 2012 15:14:37 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1350486874!15640909!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODA5NzQy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25929 invoked from network); 17 Oct 2012 15:14:36 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Oct 2012 15:14:36 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9HFEPTK032132
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Oct 2012 15:14:26 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9HFEOHe006633
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Oct 2012 15:14:25 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9HFEOkg005211; Wed, 17 Oct 2012 10:14:24 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 08:14:24 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id CD6914035B; Wed, 17 Oct 2012 11:02:22 -0400 (EDT)
Date: Wed, 17 Oct 2012 11:02:22 -0400
From: Konrad Rzeszutek Wilk 
To: David Vrabel 
Message-ID: <20121017150222.GA8743@phenom.dumpdata.com>
References: <1350480580-4844-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1350480580-4844-1-git-send-email-david.vrabel@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Frediano Ziglio , stable@vger.kernel.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCHv2] xen/x86: don't corrupt %eip when
 returning from a signal handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 17, 2012 at 02:29:40PM +0100, David Vrabel wrote:
> From: David Vrabel 
> 
> In 32 bit guests, if a userspace process has %eax == -ERESTARTSYS
> (-512) or -ERESTARTNOINTR (-513) when it is interrupted by an event
> /and/ the process has a pending signal then %eip (and %eax) are
> corrupted when returning to the main process after handling the
> signal.  The application may then crash with SIGSEGV or a SIGILL or it
> may have subtly incorrect behaviour (depending on what instruction it
> returned to).
> 
> The occurs because handle_signal() is incorrectly thinking that there
> is a system call that needs to restarted so it adjusts %eip and %eax
> to re-execute the system call instruction (even though user space had
> not done a system call).
> 
> If %eax == -514 (-ERESTARTNOHAND (-514) or -ERESTART_RESTARTBLOCK
> (-516) then handle_signal() only corrupted %eax (by setting it to
> -EINTR).  This may cause the application to crash or have incorrect
> behaviour.
> 
> handle_signal() assumes that regs->orig_ax >= 0 means a system call so
> any kernel entry point that is not for a system call must push a
> negative value for orig_ax.  For example, for physical interrupts on
> bare metal the inverse of the vector is pushed and page_fault() sets
> regs->orig_ax to -1, overwriting the hardware provided error code.
> 
> xen_hypervisor_callback() was incorrectly pushing 0 for orig_ax
> instead of -1.
> 
> Classic Xen kernels pushed %eax which works as %eax cannot be both
> non-negative and -RESTARTSYS (etc.), but using -1 is consistent with
> other non-system call entry points.
> 
> There were similar bugs in xen_failsafe_callback(), if the fault was
> corrected and normal return path was used.  64 bit guests would push 0
> which is broken.  32 bit guests would push %eax which is safe (see
> previous paragraph), but for consistency this is also changed to -1.
> 
> Signed-off-by: David Vrabel 
> Acked-by: Jan Beulich 
> Acked-by: Ian Campbell 
> Cc: stable@vger.kernel.org

Applied.

> ---
>  arch/x86/kernel/entry_32.S |    4 ++--
>  arch/x86/kernel/entry_64.S |    2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
> index 2c63407..6a19e66 100644
> --- a/arch/x86/kernel/entry_32.S
> +++ b/arch/x86/kernel/entry_32.S
> @@ -1042,7 +1042,7 @@ ENTRY(xen_sysenter_target)
>  
>  ENTRY(xen_hypervisor_callback)
>  	CFI_STARTPROC
> -	pushl_cfi $0
> +	pushl_cfi $-1 /* orig_ax = -1 => not a system call */
>  	SAVE_ALL
>  	TRACE_IRQS_OFF
>  
> @@ -1078,7 +1078,7 @@ ENDPROC(xen_hypervisor_callback)
>  # We distinguish between categories by maintaining a status value in EAX.
>  ENTRY(xen_failsafe_callback)
>  	CFI_STARTPROC
> -	pushl_cfi %eax
> +	pushl_cfi $-1  /* orig_ax = -1 => not a system call */
>  	movl $1,%eax
>  1:	mov 4(%esp),%ds
>  2:	mov 8(%esp),%es
> diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
> index cdc790c..430b1fc 100644
> --- a/arch/x86/kernel/entry_64.S
> +++ b/arch/x86/kernel/entry_64.S
> @@ -1451,7 +1451,7 @@ ENTRY(xen_failsafe_callback)
>  	CFI_RESTORE r11
>  	addq $0x30,%rsp
>  	CFI_ADJUST_CFA_OFFSET -0x30
> -	pushq_cfi $0
> +	pushq_cfi $-1 /* orig_ax = -1 => not a system call */
>  	SAVE_ALL
>  	jmp error_exit
>  	CFI_ENDPROC
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 15:22:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 15:22:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOVRN-0006Ay-Vp; Wed, 17 Oct 2012 15:21:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOVRM-0006Aq-0V
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 15:21:48 +0000
Received: from [193.109.254.147:4760] by server-4.bemta-14.messagelabs.com id
	A2/2D-04248-B0DCE705; Wed, 17 Oct 2012 15:21:47 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1350487306!10411440!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26025 invoked from network); 17 Oct 2012 15:21:46 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-12.tower-27.messagelabs.com with SMTP;
	17 Oct 2012 15:21:46 -0000
Received: from p5b2e42c0.dip.t-dialin.net ([91.46.66.192] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from )
	id 1TOVRI-0002lS-1l; Wed, 17 Oct 2012 15:21:44 +0000
Message-ID: <507ECD06.2050407@canonical.com>
Date: Wed, 17 Oct 2012 17:21:42 +0200
From: Stefan Bader 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Ian Campbell 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
	<1350482118.2460.74.camel@zakaz.uk.xensource.com>
In-Reply-To: <1350482118.2460.74.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.5
Cc: Andrew Cooper ,
	Konrad Rzeszutek Wilk ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============6214944843867296276=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============6214944843867296276==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enigDCF9146FEFDB17A1136CD1F0"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigDCF9146FEFDB17A1136CD1F0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 17.10.2012 15:55, Ian Campbell wrote:
> On Wed, 2012-10-17 at 14:28 +0100, Andrew Cooper wrote:
>> In our case, certain processes were locking up, and it turned out that=

>> the kernel was issuing SCHOP_poll hypercalls (same the stack trace on
>> your launchpad ticket) on its own spinlock IPI event channel
>> (understandable, as its a spinlock), but with the event channel
>> masked, so it would never wake up from the poll.=20
>=20
> I think (but you might want to check) that SCHEDOP_poll works (or is
> supposed to work!) regardless of whether the specific evtchn you ask fo=
r
> is masked or not.

I was assuming it to be supposed to work at least in Xen 4.1.2. Or at lea=
st if
it did not I would hope to catch VCPUs rather sitting on the hypercall th=
an
doing nothing. Of course I cannot say how reliable information in crash i=
s as
this is something new to do after Daniel fixed crash.

>=20
> The Linux PV spinlock implementation takes advantage of this because it=

> never wants to take a real interrupt from the spinlock poller evtchn.

Right, I probably should have realized that. Though I guess it is still
interesting to see whether the channel is pending.

So when just recreating, I got the q and e info which is (assuming the gu=
est
domain is enough):

(XEN) Event channel information for domain 1:
(XEN) Polling vCPUs: {1,4,6}
(XEN)     port [p/m]
(XEN)        1 [0/0]: s=3D3 n=3D0 d=3D0 p=3D68 x=3D0
(XEN)        2 [1/0]: s=3D3 n=3D0 d=3D0 p=3D69 x=3D0
(XEN)        3 [1/0]: s=3D5 n=3D0 v=3D0 x=3D0
(XEN)        4 [1/1]: s=3D6 n=3D0 x=3D0
(XEN)        5 [1/0]: s=3D6 n=3D0 x=3D0
(XEN)        6 [0/0]: s=3D6 n=3D0 x=3D0
(XEN)        7 [0/0]: s=3D5 n=3D0 v=3D1 x=3D0
(XEN)        8 [0/0]: s=3D6 n=3D0 x=3D0
(XEN)        9 [1/0]: s=3D5 n=3D1 v=3D0 x=3D0
(XEN)       10 [0/1]: s=3D6 n=3D1 x=3D0
(XEN)       11 [1/0]: s=3D6 n=3D1 x=3D0
(XEN)       12 [0/0]: s=3D6 n=3D1 x=3D0
(XEN)       13 [0/0]: s=3D5 n=3D1 v=3D1 x=3D0
(XEN)       14 [0/0]: s=3D6 n=3D1 x=3D0
(XEN)       15 [0/0]: s=3D5 n=3D2 v=3D0 x=3D0
(XEN)       16 [1/1]: s=3D6 n=3D2 x=3D0
(XEN)       17 [0/0]: s=3D6 n=3D2 x=3D0
(XEN)       18 [0/0]: s=3D6 n=3D2 x=3D0
(XEN)       19 [0/0]: s=3D5 n=3D2 v=3D1 x=3D0
(XEN)       20 [0/0]: s=3D6 n=3D2 x=3D0
(XEN)       21 [0/0]: s=3D5 n=3D3 v=3D0 x=3D0
(XEN)       22 [1/1]: s=3D6 n=3D3 x=3D0
(XEN)       23 [0/0]: s=3D6 n=3D3 x=3D0
(XEN)       24 [0/0]: s=3D6 n=3D3 x=3D0
(XEN)       25 [0/0]: s=3D5 n=3D3 v=3D1 x=3D0
(XEN)       26 [0/0]: s=3D6 n=3D3 x=3D0
(XEN)       27 [1/0]: s=3D5 n=3D4 v=3D0 x=3D0
(XEN)       28 [0/1]: s=3D6 n=3D4 x=3D0
(XEN)       29 [1/0]: s=3D6 n=3D4 x=3D0
(XEN)       30 [0/0]: s=3D6 n=3D4 x=3D0
(XEN)       31 [0/0]: s=3D5 n=3D4 v=3D1 x=3D0
(XEN)       32 [0/0]: s=3D6 n=3D4 x=3D0
(XEN)       33 [0/0]: s=3D5 n=3D5 v=3D0 x=3D0
(XEN)       34 [0/1]: s=3D6 n=3D5 x=3D0
(XEN)       35 [0/0]: s=3D6 n=3D5 x=3D0
(XEN)       36 [0/0]: s=3D6 n=3D5 x=3D0
(XEN)       37 [0/0]: s=3D5 n=3D5 v=3D1 x=3D0
(XEN)       38 [0/0]: s=3D6 n=3D5 x=3D0
(XEN)       39 [1/0]: s=3D5 n=3D6 v=3D0 x=3D0
(XEN)       40 [0/1]: s=3D6 n=3D6 x=3D0
(XEN)       41 [1/0]: s=3D6 n=3D6 x=3D0
(XEN)       42 [0/0]: s=3D6 n=3D6 x=3D0
(XEN)       43 [0/0]: s=3D5 n=3D6 v=3D1 x=3D0
(XEN)       44 [0/0]: s=3D6 n=3D6 x=3D0
(XEN)       45 [0/0]: s=3D5 n=3D7 v=3D0 x=3D0
(XEN)       46 [1/1]: s=3D6 n=3D7 x=3D0
(XEN)       47 [0/0]: s=3D6 n=3D7 x=3D0
(XEN)       48 [0/0]: s=3D6 n=3D7 x=3D0
(XEN)       49 [0/0]: s=3D5 n=3D7 v=3D1 x=3D0
(XEN)       50 [0/0]: s=3D6 n=3D7 x=3D0
(XEN)       51 [0/0]: s=3D3 n=3D7 d=3D0 p=3D70 x=3D0
(XEN)       52 [0/0]: s=3D3 n=3D0 d=3D0 p=3D71 x=3D0
(XEN)       53 [0/0]: s=3D3 n=3D0 d=3D0 p=3D72 x=3D0
(XEN)       54 [0/0]: s=3D3 n=3D0 d=3D0 p=3D73 x=3D0
(XEN)       55 [1/0]: s=3D3 n=3D0 d=3D0 p=3D74 x=3D0

[maybe someone can tell me what the s,n,d,p and x mean]

(XEN) Rangesets belonging to domain 1:
(XEN)     I/O Ports  { }
(XEN)     Interrupts { }
(XEN)     I/O Memory { }
(XEN) Memory pages belonging to domain 1:
(XEN)     DomPage list too long to display
(XEN)     XenPage 00000000008000ab: caf=3Dc000000000000002, taf=3D7400000=
000000002
(XEN)     XenPage 00000000008000aa: caf=3Dc000000000000002, taf=3D7400000=
000000002
(XEN)     XenPage 00000000008000a9: caf=3Dc000000000000002, taf=3D7400000=
000000002
(XEN)     XenPage 00000000008000a8: caf=3Dc000000000000001, taf=3D7400000=
000000001
(XEN)     XenPage 00000000000dfae4: caf=3Dc000000000000002, taf=3D7400000=
000000002
(XEN) VCPU information and callbacks for domain 1:
(XEN)     VCPU0: CPU3 [has=3DT] flags=3D0 poll=3D0 upcall_pend =3D 01, up=
call_mask =3D 01
dirty_cpus=3D{3} cpu_affinity=3D{0-127}
(XEN)     No periodic timer
(XEN)     VCPU1: CPU7 [has=3DF] flags=3D1 poll=3D10 upcall_pend =3D 01, u=
pcall_mask =3D 01
dirty_cpus=3D{} cpu_affinity=3D{0-127}
(XEN)     No periodic timer
(XEN)     VCPU2: CPU4 [has=3DF] flags=3D1 poll=3D0 upcall_pend =3D 00, up=
call_mask =3D 00
dirty_cpus=3D{} cpu_affinity=3D{0-127}
(XEN)     No periodic timer
(XEN)     VCPU3: CPU5 [has=3DF] flags=3D1 poll=3D0 upcall_pend =3D 00, up=
call_mask =3D 00
dirty_cpus=3D{} cpu_affinity=3D{0-127}
(XEN)     No periodic timer
(XEN)     VCPU4: CPU6 [has=3DF] flags=3D1 poll=3D28 upcall_pend =3D 01, u=
pcall_mask =3D 01
dirty_cpus=3D{} cpu_affinity=3D{0-127}
(XEN)     No periodic timer
(XEN)     VCPU5: CPU7 [has=3DF] flags=3D1 poll=3D0 upcall_pend =3D 00, up=
call_mask =3D 00
dirty_cpus=3D{7} cpu_affinity=3D{0-127}
(XEN)     No periodic timer
(XEN)     VCPU6: CPU0 [has=3DF] flags=3D1 poll=3D40 upcall_pend =3D 01, u=
pcall_mask =3D 01
dirty_cpus=3D{} cpu_affinity=3D{0-127}
(XEN)     No periodic timer
(XEN)     VCPU7: CPU6 [has=3DT] flags=3D0 poll=3D0 upcall_pend =3D 00, up=
call_mask =3D 01
dirty_cpus=3D{6} cpu_affinity=3D{0-127}
(XEN)     No periodic timer
(XEN) Notifying guest 0:0 (virq 1, port 5, stat 0/0/0)
(XEN) Notifying guest 0:1 (virq 1, port 11, stat 0/0/0)
(XEN) Notifying guest 0:2 (virq 1, port 17, stat 0/0/0)
(XEN) Notifying guest 0:3 (virq 1, port 23, stat 0/0/0)
(XEN) Notifying guest 0:4 (virq 1, port 29, stat 0/0/0)
(XEN) Notifying guest 0:5 (virq 1, port 35, stat 0/0/0)
(XEN) Notifying guest 0:6 (virq 1, port 41, stat 0/0/0)
(XEN) Notifying guest 0:7 (virq 1, port 47, stat 0/0/0)
(XEN) Notifying guest 1:0 (virq 1, port 7, stat 0/0/-1)
(XEN) Notifying guest 1:1 (virq 1, port 13, stat 0/0/-1)
(XEN) Notifying guest 1:2 (virq 1, port 19, stat 0/0/0)
(XEN) Notifying guest 1:3 (virq 1, port 25, stat 0/0/0)
(XEN) Notifying guest 1:4 (virq 1, port 31, stat 0/0/-1)
(XEN) Notifying guest 1:5 (virq 1, port 37, stat 0/0/0)
(XEN) Notifying guest 1:6 (virq 1, port 43, stat 0/0/-1)
(XEN) Notifying guest 1:7 (virq 1, port 49, stat 0/0/0)

When the guest was unresponsive the console would still show:
[10174.372092] INFO: rcu_sched detected stalls on CPUs/tasks: { 0 1} (det=
ected
by 4, t=3D15002 jiffies)
[10284.448089] INFO: rcu_bh detected stalls on CPUs/tasks: { 0 1 4 6} (de=
tected
by 5, t=3D15004 jiffies)

in a repeating pattern. So I take the above as cpus 1,4 and 6 are polling=
=2E From
the dump and the content of lock_spinners I get:

cpu 0 and 1 -> ffff8803bfc13700 (which is runqueue[0] and is unlocked aga=
in)
cpu 4 and 6 -> ffffffff81f15ef0 (which is blkif_io_lock and is locked)

Backtraces would be somewhat inconsistent (as always). Note, I should men=
tion
that I still had a kernel with my patch applied on that guest. That chang=
es
things a bit (actually it takes a bit longer to hang but again that might=
 be
just a matter of timing). The strange lock state of 2 spinners on an unlo=
cked
lock remains the same with or without it.

One question about the patch actually, would anybody think that there cou=
ld be a
case where the unlocking cpu has itself on the spinners list? I did not t=
hink so
but that might be wrong.
> =20
> The IRQ handler for the spinlock evtchn in Linux is:
>         static irqreturn_t dummy_handler(int irq, void *dev_id)
>         {
>                 BUG();
>                 return IRQ_HANDLED;
>         }
>        =20
> and right after we register it:
>                 disable_irq(irq); /* make sure it's never delivered */
>=20
> The is no enable -- ignoring bugs of which there have been couple of
> instances, but those trigger the BUG() so are pretty obvious.
>=20
> Ian.
>=20
>=20





--------------enigDCF9146FEFDB17A1136CD1F0
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBCgAGBQJQfs0GAAoJEOhnXe7L7s6jwXUQAL5NF6D2cs6XlFgWJ7CjAZtL
jJCCkonPut/ZJG081Jb0F8ZOx8dbHame2/ypTNPghZVNnfWMwPR9Niy99Jk4l2sm
H2jMJ2lAfYt2cHHI6T31pbcrO5JJ5aYrRn3A6CS8LIiTSY3gc0CGgIVWU5FWFwGJ
czSTqV9Wk7cMIEkdQOSnCotBQ942wa9tI0otMv8RUMBfdfUa89DmuMh571AXLu9p
x1KGfwNRo7m6S/1SvO5GnA0lUGueC86deHH+zCRPq003LNIHZR55H/FRwMo4wZxE
i5UjUkiVaZdi4DHawVgfWjyVx5BPfLVBAmKCTu5PRcVIF2wv9PXEKXGFtu2uAte0
0qvaav7PIEvAkBlFH4iaXkvLlUEoBTB3OUhxz46WcdzuM09D4m2WqpckJezsw+pP
zC2wiw5H+D4KCqGaRLXIc+zidBbzE7C2Y+SJmp3QWO1174VKOwnI0hsVD8uaky/7
6OcyktOX3kf9Hs+Cpc1XneGYWLZmE8v5jfz4JTiVq1YQs35deHK6tvDLaMBrnSk5
1ZW4EAGMSVTk11BxOYlfOqwz6YRmm829xKM/j96zbOeqVjU70fs1ZfmQfSQeyYkK
rDxo4UagRdLcxFlNlvFVABP922oZJe0sVuyJXyK13xc76bjDSeGBpp/O3DWuTXj5
e+NdMunsg2owKoGESWjB
=JD2M
-----END PGP SIGNATURE-----

--------------enigDCF9146FEFDB17A1136CD1F0--


--===============6214944843867296276==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6214944843867296276==--


From xen-devel-bounces@lists.xen.org Wed Oct 17 15:22:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 15:22:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOVRN-0006Ay-Vp; Wed, 17 Oct 2012 15:21:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOVRM-0006Aq-0V
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 15:21:48 +0000
Received: from [193.109.254.147:4760] by server-4.bemta-14.messagelabs.com id
	A2/2D-04248-B0DCE705; Wed, 17 Oct 2012 15:21:47 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1350487306!10411440!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26025 invoked from network); 17 Oct 2012 15:21:46 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-12.tower-27.messagelabs.com with SMTP;
	17 Oct 2012 15:21:46 -0000
Received: from p5b2e42c0.dip.t-dialin.net ([91.46.66.192] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from )
	id 1TOVRI-0002lS-1l; Wed, 17 Oct 2012 15:21:44 +0000
Message-ID: <507ECD06.2050407@canonical.com>
Date: Wed, 17 Oct 2012 17:21:42 +0200
From: Stefan Bader 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Ian Campbell 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
	<1350482118.2460.74.camel@zakaz.uk.xensource.com>
In-Reply-To: <1350482118.2460.74.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.5
Cc: Andrew Cooper ,
	Konrad Rzeszutek Wilk ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============6214944843867296276=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============6214944843867296276==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enigDCF9146FEFDB17A1136CD1F0"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigDCF9146FEFDB17A1136CD1F0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 17.10.2012 15:55, Ian Campbell wrote:
> On Wed, 2012-10-17 at 14:28 +0100, Andrew Cooper wrote:
>> In our case, certain processes were locking up, and it turned out that=

>> the kernel was issuing SCHOP_poll hypercalls (same the stack trace on
>> your launchpad ticket) on its own spinlock IPI event channel
>> (understandable, as its a spinlock), but with the event channel
>> masked, so it would never wake up from the poll.=20
>=20
> I think (but you might want to check) that SCHEDOP_poll works (or is
> supposed to work!) regardless of whether the specific evtchn you ask fo=
r
> is masked or not.

I was assuming it to be supposed to work at least in Xen 4.1.2. Or at lea=
st if
it did not I would hope to catch VCPUs rather sitting on the hypercall th=
an
doing nothing. Of course I cannot say how reliable information in crash i=
s as
this is something new to do after Daniel fixed crash.

>=20
> The Linux PV spinlock implementation takes advantage of this because it=

> never wants to take a real interrupt from the spinlock poller evtchn.

Right, I probably should have realized that. Though I guess it is still
interesting to see whether the channel is pending.

So when just recreating, I got the q and e info which is (assuming the gu=
est
domain is enough):

(XEN) Event channel information for domain 1:
(XEN) Polling vCPUs: {1,4,6}
(XEN)     port [p/m]
(XEN)        1 [0/0]: s=3D3 n=3D0 d=3D0 p=3D68 x=3D0
(XEN)        2 [1/0]: s=3D3 n=3D0 d=3D0 p=3D69 x=3D0
(XEN)        3 [1/0]: s=3D5 n=3D0 v=3D0 x=3D0
(XEN)        4 [1/1]: s=3D6 n=3D0 x=3D0
(XEN)        5 [1/0]: s=3D6 n=3D0 x=3D0
(XEN)        6 [0/0]: s=3D6 n=3D0 x=3D0
(XEN)        7 [0/0]: s=3D5 n=3D0 v=3D1 x=3D0
(XEN)        8 [0/0]: s=3D6 n=3D0 x=3D0
(XEN)        9 [1/0]: s=3D5 n=3D1 v=3D0 x=3D0
(XEN)       10 [0/1]: s=3D6 n=3D1 x=3D0
(XEN)       11 [1/0]: s=3D6 n=3D1 x=3D0
(XEN)       12 [0/0]: s=3D6 n=3D1 x=3D0
(XEN)       13 [0/0]: s=3D5 n=3D1 v=3D1 x=3D0
(XEN)       14 [0/0]: s=3D6 n=3D1 x=3D0
(XEN)       15 [0/0]: s=3D5 n=3D2 v=3D0 x=3D0
(XEN)       16 [1/1]: s=3D6 n=3D2 x=3D0
(XEN)       17 [0/0]: s=3D6 n=3D2 x=3D0
(XEN)       18 [0/0]: s=3D6 n=3D2 x=3D0
(XEN)       19 [0/0]: s=3D5 n=3D2 v=3D1 x=3D0
(XEN)       20 [0/0]: s=3D6 n=3D2 x=3D0
(XEN)       21 [0/0]: s=3D5 n=3D3 v=3D0 x=3D0
(XEN)       22 [1/1]: s=3D6 n=3D3 x=3D0
(XEN)       23 [0/0]: s=3D6 n=3D3 x=3D0
(XEN)       24 [0/0]: s=3D6 n=3D3 x=3D0
(XEN)       25 [0/0]: s=3D5 n=3D3 v=3D1 x=3D0
(XEN)       26 [0/0]: s=3D6 n=3D3 x=3D0
(XEN)       27 [1/0]: s=3D5 n=3D4 v=3D0 x=3D0
(XEN)       28 [0/1]: s=3D6 n=3D4 x=3D0
(XEN)       29 [1/0]: s=3D6 n=3D4 x=3D0
(XEN)       30 [0/0]: s=3D6 n=3D4 x=3D0
(XEN)       31 [0/0]: s=3D5 n=3D4 v=3D1 x=3D0
(XEN)       32 [0/0]: s=3D6 n=3D4 x=3D0
(XEN)       33 [0/0]: s=3D5 n=3D5 v=3D0 x=3D0
(XEN)       34 [0/1]: s=3D6 n=3D5 x=3D0
(XEN)       35 [0/0]: s=3D6 n=3D5 x=3D0
(XEN)       36 [0/0]: s=3D6 n=3D5 x=3D0
(XEN)       37 [0/0]: s=3D5 n=3D5 v=3D1 x=3D0
(XEN)       38 [0/0]: s=3D6 n=3D5 x=3D0
(XEN)       39 [1/0]: s=3D5 n=3D6 v=3D0 x=3D0
(XEN)       40 [0/1]: s=3D6 n=3D6 x=3D0
(XEN)       41 [1/0]: s=3D6 n=3D6 x=3D0
(XEN)       42 [0/0]: s=3D6 n=3D6 x=3D0
(XEN)       43 [0/0]: s=3D5 n=3D6 v=3D1 x=3D0
(XEN)       44 [0/0]: s=3D6 n=3D6 x=3D0
(XEN)       45 [0/0]: s=3D5 n=3D7 v=3D0 x=3D0
(XEN)       46 [1/1]: s=3D6 n=3D7 x=3D0
(XEN)       47 [0/0]: s=3D6 n=3D7 x=3D0
(XEN)       48 [0/0]: s=3D6 n=3D7 x=3D0
(XEN)       49 [0/0]: s=3D5 n=3D7 v=3D1 x=3D0
(XEN)       50 [0/0]: s=3D6 n=3D7 x=3D0
(XEN)       51 [0/0]: s=3D3 n=3D7 d=3D0 p=3D70 x=3D0
(XEN)       52 [0/0]: s=3D3 n=3D0 d=3D0 p=3D71 x=3D0
(XEN)       53 [0/0]: s=3D3 n=3D0 d=3D0 p=3D72 x=3D0
(XEN)       54 [0/0]: s=3D3 n=3D0 d=3D0 p=3D73 x=3D0
(XEN)       55 [1/0]: s=3D3 n=3D0 d=3D0 p=3D74 x=3D0

[maybe someone can tell me what the s,n,d,p and x mean]

(XEN) Rangesets belonging to domain 1:
(XEN)     I/O Ports  { }
(XEN)     Interrupts { }
(XEN)     I/O Memory { }
(XEN) Memory pages belonging to domain 1:
(XEN)     DomPage list too long to display
(XEN)     XenPage 00000000008000ab: caf=3Dc000000000000002, taf=3D7400000=
000000002
(XEN)     XenPage 00000000008000aa: caf=3Dc000000000000002, taf=3D7400000=
000000002
(XEN)     XenPage 00000000008000a9: caf=3Dc000000000000002, taf=3D7400000=
000000002
(XEN)     XenPage 00000000008000a8: caf=3Dc000000000000001, taf=3D7400000=
000000001
(XEN)     XenPage 00000000000dfae4: caf=3Dc000000000000002, taf=3D7400000=
000000002
(XEN) VCPU information and callbacks for domain 1:
(XEN)     VCPU0: CPU3 [has=3DT] flags=3D0 poll=3D0 upcall_pend =3D 01, up=
call_mask =3D 01
dirty_cpus=3D{3} cpu_affinity=3D{0-127}
(XEN)     No periodic timer
(XEN)     VCPU1: CPU7 [has=3DF] flags=3D1 poll=3D10 upcall_pend =3D 01, u=
pcall_mask =3D 01
dirty_cpus=3D{} cpu_affinity=3D{0-127}
(XEN)     No periodic timer
(XEN)     VCPU2: CPU4 [has=3DF] flags=3D1 poll=3D0 upcall_pend =3D 00, up=
call_mask =3D 00
dirty_cpus=3D{} cpu_affinity=3D{0-127}
(XEN)     No periodic timer
(XEN)     VCPU3: CPU5 [has=3DF] flags=3D1 poll=3D0 upcall_pend =3D 00, up=
call_mask =3D 00
dirty_cpus=3D{} cpu_affinity=3D{0-127}
(XEN)     No periodic timer
(XEN)     VCPU4: CPU6 [has=3DF] flags=3D1 poll=3D28 upcall_pend =3D 01, u=
pcall_mask =3D 01
dirty_cpus=3D{} cpu_affinity=3D{0-127}
(XEN)     No periodic timer
(XEN)     VCPU5: CPU7 [has=3DF] flags=3D1 poll=3D0 upcall_pend =3D 00, up=
call_mask =3D 00
dirty_cpus=3D{7} cpu_affinity=3D{0-127}
(XEN)     No periodic timer
(XEN)     VCPU6: CPU0 [has=3DF] flags=3D1 poll=3D40 upcall_pend =3D 01, u=
pcall_mask =3D 01
dirty_cpus=3D{} cpu_affinity=3D{0-127}
(XEN)     No periodic timer
(XEN)     VCPU7: CPU6 [has=3DT] flags=3D0 poll=3D0 upcall_pend =3D 00, up=
call_mask =3D 01
dirty_cpus=3D{6} cpu_affinity=3D{0-127}
(XEN)     No periodic timer
(XEN) Notifying guest 0:0 (virq 1, port 5, stat 0/0/0)
(XEN) Notifying guest 0:1 (virq 1, port 11, stat 0/0/0)
(XEN) Notifying guest 0:2 (virq 1, port 17, stat 0/0/0)
(XEN) Notifying guest 0:3 (virq 1, port 23, stat 0/0/0)
(XEN) Notifying guest 0:4 (virq 1, port 29, stat 0/0/0)
(XEN) Notifying guest 0:5 (virq 1, port 35, stat 0/0/0)
(XEN) Notifying guest 0:6 (virq 1, port 41, stat 0/0/0)
(XEN) Notifying guest 0:7 (virq 1, port 47, stat 0/0/0)
(XEN) Notifying guest 1:0 (virq 1, port 7, stat 0/0/-1)
(XEN) Notifying guest 1:1 (virq 1, port 13, stat 0/0/-1)
(XEN) Notifying guest 1:2 (virq 1, port 19, stat 0/0/0)
(XEN) Notifying guest 1:3 (virq 1, port 25, stat 0/0/0)
(XEN) Notifying guest 1:4 (virq 1, port 31, stat 0/0/-1)
(XEN) Notifying guest 1:5 (virq 1, port 37, stat 0/0/0)
(XEN) Notifying guest 1:6 (virq 1, port 43, stat 0/0/-1)
(XEN) Notifying guest 1:7 (virq 1, port 49, stat 0/0/0)

When the guest was unresponsive the console would still show:
[10174.372092] INFO: rcu_sched detected stalls on CPUs/tasks: { 0 1} (det=
ected
by 4, t=3D15002 jiffies)
[10284.448089] INFO: rcu_bh detected stalls on CPUs/tasks: { 0 1 4 6} (de=
tected
by 5, t=3D15004 jiffies)

in a repeating pattern. So I take the above as cpus 1,4 and 6 are polling=
=2E From
the dump and the content of lock_spinners I get:

cpu 0 and 1 -> ffff8803bfc13700 (which is runqueue[0] and is unlocked aga=
in)
cpu 4 and 6 -> ffffffff81f15ef0 (which is blkif_io_lock and is locked)

Backtraces would be somewhat inconsistent (as always). Note, I should men=
tion
that I still had a kernel with my patch applied on that guest. That chang=
es
things a bit (actually it takes a bit longer to hang but again that might=
 be
just a matter of timing). The strange lock state of 2 spinners on an unlo=
cked
lock remains the same with or without it.

One question about the patch actually, would anybody think that there cou=
ld be a
case where the unlocking cpu has itself on the spinners list? I did not t=
hink so
but that might be wrong.
> =20
> The IRQ handler for the spinlock evtchn in Linux is:
>         static irqreturn_t dummy_handler(int irq, void *dev_id)
>         {
>                 BUG();
>                 return IRQ_HANDLED;
>         }
>        =20
> and right after we register it:
>                 disable_irq(irq); /* make sure it's never delivered */
>=20
> The is no enable -- ignoring bugs of which there have been couple of
> instances, but those trigger the BUG() so are pretty obvious.
>=20
> Ian.
>=20
>=20





--------------enigDCF9146FEFDB17A1136CD1F0
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBCgAGBQJQfs0GAAoJEOhnXe7L7s6jwXUQAL5NF6D2cs6XlFgWJ7CjAZtL
jJCCkonPut/ZJG081Jb0F8ZOx8dbHame2/ypTNPghZVNnfWMwPR9Niy99Jk4l2sm
H2jMJ2lAfYt2cHHI6T31pbcrO5JJ5aYrRn3A6CS8LIiTSY3gc0CGgIVWU5FWFwGJ
czSTqV9Wk7cMIEkdQOSnCotBQ942wa9tI0otMv8RUMBfdfUa89DmuMh571AXLu9p
x1KGfwNRo7m6S/1SvO5GnA0lUGueC86deHH+zCRPq003LNIHZR55H/FRwMo4wZxE
i5UjUkiVaZdi4DHawVgfWjyVx5BPfLVBAmKCTu5PRcVIF2wv9PXEKXGFtu2uAte0
0qvaav7PIEvAkBlFH4iaXkvLlUEoBTB3OUhxz46WcdzuM09D4m2WqpckJezsw+pP
zC2wiw5H+D4KCqGaRLXIc+zidBbzE7C2Y+SJmp3QWO1174VKOwnI0hsVD8uaky/7
6OcyktOX3kf9Hs+Cpc1XneGYWLZmE8v5jfz4JTiVq1YQs35deHK6tvDLaMBrnSk5
1ZW4EAGMSVTk11BxOYlfOqwz6YRmm829xKM/j96zbOeqVjU70fs1ZfmQfSQeyYkK
rDxo4UagRdLcxFlNlvFVABP922oZJe0sVuyJXyK13xc76bjDSeGBpp/O3DWuTXj5
e+NdMunsg2owKoGESWjB
=JD2M
-----END PGP SIGNATURE-----

--------------enigDCF9146FEFDB17A1136CD1F0--


--===============6214944843867296276==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6214944843867296276==--


From xen-devel-bounces@lists.xen.org Wed Oct 17 15:26:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 15:26:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOVVY-0006Id-NT; Wed, 17 Oct 2012 15:26:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOVVX-0006IW-7Y
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 15:26:07 +0000
Received: from [85.158.139.211:53332] by server-7.bemta-5.messagelabs.com id
	96/CC-23102-E0ECE705; Wed, 17 Oct 2012 15:26:06 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1350487565!18718283!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23641 invoked from network); 17 Oct 2012 15:26:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 15:26:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,601,1344211200"; d="scan'208";a="15230454"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 15:26:05 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 17 Oct 2012 16:26:04 +0100
Date: Wed, 17 Oct 2012 16:25:42 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1350482036.2460.73.camel@zakaz.uk.xensource.com>
Message-ID: 
References: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
	<1350314444-17148-10-git-send-email-ian.campbell@citrix.com>
	
	<1350482036.2460.73.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" ,
	Stefano Stabellini ,
	"Tim \(Xen.org\)" ,
	"xen-devel@lists.xen.org" ,
	Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 10/10] arm: parameter guest handles are 32
 bit on 32 bit hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 17 Oct 2012, Ian Campbell wrote:
> On Wed, 2012-10-17 at 14:50 +0100, Stefano Stabellini wrote:
> > On Mon, 15 Oct 2012, Ian Campbell wrote:
> > > Handles within structs remain 64 bit such that they are consistently
> > > sized on both 32 and 64 bit.
> > > 
> > > Signed-off-by: Ian Campbell 
> > > ---
> > >  xen/include/public/arch-arm.h |    2 +-
> > >  1 files changed, 1 insertions(+), 1 deletions(-)
> > > 
> > > diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> > > index ac493a5..ff02d15 100644
> > > --- a/xen/include/public/arch-arm.h
> > > +++ b/xen/include/public/arch-arm.h
> > > @@ -74,7 +74,7 @@
> > >  #define __XEN_GUEST_HANDLE(name)        __guest_handle_64_ ## name
> > >  #define XEN_GUEST_HANDLE(name)          __XEN_GUEST_HANDLE(name)
> > >  /* this is going to be changed on 64 bit */
> > > -#define XEN_GUEST_HANDLE_PARAM(name)   XEN_GUEST_HANDLE(name)
> > > +#define XEN_GUEST_HANDLE_PARAM(name)    __guest_handle_ ## name
> > >  #define set_xen_guest_handle_raw(hnd, val)                  \
> > >      do {                                                    \
> > >          typeof(&(hnd)) _sxghr_tmp = &(hnd);                 \
> > 
> > I am confused.
> > 
> > I am not sure what version of my patch "xen: introduce
> > XEN_GUEST_HANDLE_PARAM" you have based this series upon, because the
> > latest one I have sent, certainly contains this change:
> 
> That stuff is in "xen: introduce XEN_GUEST_HANDLE_PARAM". I had to defer
> the final switch until after the transition to HANDLE_PARAM was complete
> in order to avoid breaking the build in the interim.

I see.
Also I noticed that you wrote that in the commit message of "xen:
introduce XEN_GUEST_HANDLE_PARAM", so it is OK by me.


Acked-by: Stefano Stabellini 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 15:26:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 15:26:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOVVY-0006Id-NT; Wed, 17 Oct 2012 15:26:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOVVX-0006IW-7Y
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 15:26:07 +0000
Received: from [85.158.139.211:53332] by server-7.bemta-5.messagelabs.com id
	96/CC-23102-E0ECE705; Wed, 17 Oct 2012 15:26:06 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1350487565!18718283!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23641 invoked from network); 17 Oct 2012 15:26:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 15:26:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,601,1344211200"; d="scan'208";a="15230454"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 15:26:05 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 17 Oct 2012 16:26:04 +0100
Date: Wed, 17 Oct 2012 16:25:42 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1350482036.2460.73.camel@zakaz.uk.xensource.com>
Message-ID: 
References: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
	<1350314444-17148-10-git-send-email-ian.campbell@citrix.com>
	
	<1350482036.2460.73.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" ,
	Stefano Stabellini ,
	"Tim \(Xen.org\)" ,
	"xen-devel@lists.xen.org" ,
	Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 10/10] arm: parameter guest handles are 32
 bit on 32 bit hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 17 Oct 2012, Ian Campbell wrote:
> On Wed, 2012-10-17 at 14:50 +0100, Stefano Stabellini wrote:
> > On Mon, 15 Oct 2012, Ian Campbell wrote:
> > > Handles within structs remain 64 bit such that they are consistently
> > > sized on both 32 and 64 bit.
> > > 
> > > Signed-off-by: Ian Campbell 
> > > ---
> > >  xen/include/public/arch-arm.h |    2 +-
> > >  1 files changed, 1 insertions(+), 1 deletions(-)
> > > 
> > > diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> > > index ac493a5..ff02d15 100644
> > > --- a/xen/include/public/arch-arm.h
> > > +++ b/xen/include/public/arch-arm.h
> > > @@ -74,7 +74,7 @@
> > >  #define __XEN_GUEST_HANDLE(name)        __guest_handle_64_ ## name
> > >  #define XEN_GUEST_HANDLE(name)          __XEN_GUEST_HANDLE(name)
> > >  /* this is going to be changed on 64 bit */
> > > -#define XEN_GUEST_HANDLE_PARAM(name)   XEN_GUEST_HANDLE(name)
> > > +#define XEN_GUEST_HANDLE_PARAM(name)    __guest_handle_ ## name
> > >  #define set_xen_guest_handle_raw(hnd, val)                  \
> > >      do {                                                    \
> > >          typeof(&(hnd)) _sxghr_tmp = &(hnd);                 \
> > 
> > I am confused.
> > 
> > I am not sure what version of my patch "xen: introduce
> > XEN_GUEST_HANDLE_PARAM" you have based this series upon, because the
> > latest one I have sent, certainly contains this change:
> 
> That stuff is in "xen: introduce XEN_GUEST_HANDLE_PARAM". I had to defer
> the final switch until after the transition to HANDLE_PARAM was complete
> in order to avoid breaking the build in the interim.

I see.
Also I noticed that you wrote that in the commit message of "xen:
introduce XEN_GUEST_HANDLE_PARAM", so it is OK by me.


Acked-by: Stefano Stabellini 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 15:31:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 15:31:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOVax-0006St-If; Wed, 17 Oct 2012 15:31:43 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOVav-0006Sn-Li
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 15:31:41 +0000
Received: from [193.109.254.147:8711] by server-5.bemta-14.messagelabs.com id
	85/49-18309-C5FCE705; Wed, 17 Oct 2012 15:31:40 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1350487900!14998595!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 855 invoked from network); 17 Oct 2012 15:31:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 15:31:40 -0000
X-IronPort-AV: E=Sophos;i="4.80,601,1344211200"; d="scan'208";a="15230563"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 15:31:39 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 17 Oct 2012 16:31:39 +0100
Date: Wed, 17 Oct 2012 16:31:16 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1350314444-17148-1-git-send-email-ian.campbell@citrix.com>
Message-ID: 
References: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
	<1350314444-17148-1-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" ,
	Stefano Stabellini ,
	"Tim \(Xen.org\)" ,
	"xen-devel@lists.xen.org" ,
	Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 01/10] xen: arm: implement
	XENMEM_add_to_physmap_range
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 15 Oct 2012, Ian Campbell wrote:
> diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
> index 86d02c8..f1ddbc0 100644
> --- a/xen/include/public/memory.h
> +++ b/xen/include/public/memory.h
> @@ -198,6 +198,15 @@ struct xen_machphys_mapping {
>  typedef struct xen_machphys_mapping xen_machphys_mapping_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_machphys_mapping_t);
>  
> +/* Source mapping space. */
> +/* ` enum phys_map_space { */

I don't think that these comments about the enum add any value.

In any case the patch is simple and seems correct so:

Acked-by: Stefano Stabellini 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 15:31:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 15:31:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOVax-0006St-If; Wed, 17 Oct 2012 15:31:43 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOVav-0006Sn-Li
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 15:31:41 +0000
Received: from [193.109.254.147:8711] by server-5.bemta-14.messagelabs.com id
	85/49-18309-C5FCE705; Wed, 17 Oct 2012 15:31:40 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1350487900!14998595!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 855 invoked from network); 17 Oct 2012 15:31:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 15:31:40 -0000
X-IronPort-AV: E=Sophos;i="4.80,601,1344211200"; d="scan'208";a="15230563"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 15:31:39 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 17 Oct 2012 16:31:39 +0100
Date: Wed, 17 Oct 2012 16:31:16 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1350314444-17148-1-git-send-email-ian.campbell@citrix.com>
Message-ID: 
References: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
	<1350314444-17148-1-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" ,
	Stefano Stabellini ,
	"Tim \(Xen.org\)" ,
	"xen-devel@lists.xen.org" ,
	Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 01/10] xen: arm: implement
	XENMEM_add_to_physmap_range
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 15 Oct 2012, Ian Campbell wrote:
> diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
> index 86d02c8..f1ddbc0 100644
> --- a/xen/include/public/memory.h
> +++ b/xen/include/public/memory.h
> @@ -198,6 +198,15 @@ struct xen_machphys_mapping {
>  typedef struct xen_machphys_mapping xen_machphys_mapping_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_machphys_mapping_t);
>  
> +/* Source mapping space. */
> +/* ` enum phys_map_space { */

I don't think that these comments about the enum add any value.

In any case the patch is simple and seems correct so:

Acked-by: Stefano Stabellini 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 15:35:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 15:35:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOVea-0006bk-CJ; Wed, 17 Oct 2012 15:35:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOVeY-0006bc-4H
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 15:35:26 +0000
Received: from [85.158.143.99:26968] by server-2.bemta-4.messagelabs.com id
	00/8E-22268-D30DE705; Wed, 17 Oct 2012 15:35:25 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1350488121!27502628!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODMwNDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18019 invoked from network); 17 Oct 2012 15:35:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 15:35:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,601,1344211200"; 
	d="scan'208,217";a="211577252"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 15:35:21 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 11:35:20 -0400
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TOVeS-0001Vl-9u;
	Wed, 17 Oct 2012 16:35:20 +0100
Message-ID: <507ED038.8000806@citrix.com>
Date: Wed, 17 Oct 2012 16:35:20 +0100
From: Andrew Cooper 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Stefan Bader 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
	<1350482118.2460.74.camel@zakaz.uk.xensource.com>
	<507ECD06.2050407@canonical.com>
In-Reply-To: <507ECD06.2050407@canonical.com>
X-Enigmail-Version: 1.4.5
Cc: Konrad Rzeszutek Wilk ,
	Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============6179704354617584911=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6179704354617584911==
Content-Type: multipart/alternative;
	boundary="------------030607010300050505080009"

--------------030607010300050505080009
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit


On 17/10/12 16:21, Stefan Bader wrote:
> On 17.10.2012 15:55, Ian Campbell wrote:
>> On Wed, 2012-10-17 at 14:28 +0100, Andrew Cooper wrote:
>>> In our case, certain processes were locking up, and it turned out that
>>> the kernel was issuing SCHOP_poll hypercalls (same the stack trace on
>>> your launchpad ticket) on its own spinlock IPI event channel
>>> (understandable, as its a spinlock), but with the event channel
>>> masked, so it would never wake up from the poll.
>>
>> I think (but you might want to check) that SCHEDOP_poll works (or is
>> supposed to work!) regardless of whether the specific evtchn you ask for
>> is masked or not.
>
> I was assuming it to be supposed to work at least in Xen 4.1.2. Or at
least if
> it did not I would hope to catch VCPUs rather sitting on the hypercall
than
> doing nothing. Of course I cannot say how reliable information in
crash is as
> this is something new to do after Daniel fixed crash.
>
>>
>> The Linux PV spinlock implementation takes advantage of this because it
>> never wants to take a real interrupt from the spinlock poller evtchn.
>
> Right, I probably should have realized that. Though I guess it is still
> interesting to see whether the channel is pending.
>
> So when just recreating, I got the q and e info which is (assuming the
guest
> domain is enough):
>
> (XEN) Event channel information for domain 1:
> (XEN) Polling vCPUs: {1,4,6}
> (XEN) port [p/m]
> (XEN) 1 [0/0]: s=3 n=0 d=0 p=68 x=0
> (XEN) 2 [1/0]: s=3 n=0 d=0 p=69 x=0
> (XEN) 3 [1/0]: s=5 n=0 v=0 x=0
> (XEN) 4 [1/1]: s=6 n=0 x=0
> (XEN) 5 [1/0]: s=6 n=0 x=0
> (XEN) 6 [0/0]: s=6 n=0 x=0
> (XEN) 7 [0/0]: s=5 n=0 v=1 x=0
> (XEN) 8 [0/0]: s=6 n=0 x=0
> (XEN) 9 [1/0]: s=5 n=1 v=0 x=0
> (XEN) 10 [0/1]: s=6 n=1 x=0
> (XEN) 11 [1/0]: s=6 n=1 x=0
> (XEN) 12 [0/0]: s=6 n=1 x=0
> (XEN) 13 [0/0]: s=5 n=1 v=1 x=0
> (XEN) 14 [0/0]: s=6 n=1 x=0
> (XEN) 15 [0/0]: s=5 n=2 v=0 x=0
> (XEN) 16 [1/1]: s=6 n=2 x=0
> (XEN) 17 [0/0]: s=6 n=2 x=0
> (XEN) 18 [0/0]: s=6 n=2 x=0
> (XEN) 19 [0/0]: s=5 n=2 v=1 x=0
> (XEN) 20 [0/0]: s=6 n=2 x=0
> (XEN) 21 [0/0]: s=5 n=3 v=0 x=0
> (XEN) 22 [1/1]: s=6 n=3 x=0
> (XEN) 23 [0/0]: s=6 n=3 x=0
> (XEN) 24 [0/0]: s=6 n=3 x=0
> (XEN) 25 [0/0]: s=5 n=3 v=1 x=0
> (XEN) 26 [0/0]: s=6 n=3 x=0
> (XEN) 27 [1/0]: s=5 n=4 v=0 x=0
> (XEN) 28 [0/1]: s=6 n=4 x=0
> (XEN) 29 [1/0]: s=6 n=4 x=0
> (XEN) 30 [0/0]: s=6 n=4 x=0
> (XEN) 31 [0/0]: s=5 n=4 v=1 x=0
> (XEN) 32 [0/0]: s=6 n=4 x=0
> (XEN) 33 [0/0]: s=5 n=5 v=0 x=0
> (XEN) 34 [0/1]: s=6 n=5 x=0
> (XEN) 35 [0/0]: s=6 n=5 x=0
> (XEN) 36 [0/0]: s=6 n=5 x=0
> (XEN) 37 [0/0]: s=5 n=5 v=1 x=0
> (XEN) 38 [0/0]: s=6 n=5 x=0
> (XEN) 39 [1/0]: s=5 n=6 v=0 x=0
> (XEN) 40 [0/1]: s=6 n=6 x=0
> (XEN) 41 [1/0]: s=6 n=6 x=0
> (XEN) 42 [0/0]: s=6 n=6 x=0
> (XEN) 43 [0/0]: s=5 n=6 v=1 x=0
> (XEN) 44 [0/0]: s=6 n=6 x=0event channel
> (XEN) 45 [0/0]: s=5 n=7 v=0 x=0
> (XEN) 46 [1/1]: s=6 n=7 x=0
> (XEN) 47 [0/0]: s=6 n=7 x=0
> (XEN) 48 [0/0]: s=6 n=7 x=0
> (XEN) 49 [0/0]: s=5 n=7 v=1 x=0
> (XEN) 50 [0/0]: s=6 n=7 x=0
> (XEN) 51 [0/0]: s=3 n=7 d=0 p=70 x=0
> (XEN) 52 [0/0]: s=3 n=0 d=0 p=71 x=0
> (XEN) 53 [0/0]: s=3 n=0 d=0 p=72 x=0
> (XEN) 54 [0/0]: s=3 n=0 d=0 p=73 x=0
> (XEN) 55 [1/0]: s=3 n=0 d=0 p=74 x=0
>
> [maybe someone can tell me what the s,n,d,p and x mean]

s = state.  0 = free, 1 = reserved, 2 = unbound, 3 = inter-domain, 4 =
pirq, 5 = virq, 6 = ipi
n = target vcpu id to notify
x = boolean indicating whether xen is a consumer of the event channel or
not.

d = target domain (when appropriate)  In this case, p is the target port.

>
>
> (XEN) Rangesets belonging to domain 1:
> (XEN) I/O Ports { }
> (XEN) Interrupts { }
> (XEN) I/O Memory { }
> (XEN) Memory pages belonging to domain 1:
> (XEN) DomPage list too long to display
> (XEN) XenPage 00000000008000ab: caf=c000000000000002, taf=7400000000000002
> (XEN) XenPage 00000000008000aa: caf=c000000000000002, taf=7400000000000002
> (XEN) XenPage 00000000008000a9: caf=c000000000000002, taf=7400000000000002
> (XEN) XenPage 00000000008000a8: caf=c000000000000001, taf=7400000000000001
> (XEN) XenPage 00000000000dfae4: caf=c000000000000002, taf=7400000000000002
> (XEN) VCPU information and callbacks for domain 1:
> (XEN) VCPU0: CPU3 [has=T] flags=0 poll=0 upcall_pend = 01, upcall_mask
= 01
> dirty_cpus={3} cpu_affinity={0-127}
> (XEN) No periodic timer
> (XEN) VCPU1: CPU7 [has=F] flags=1 poll=10 upcall_pend = 01,
upcall_mask = 01
> dirty_cpus={} cpu_affinity={0-127}
> (XEN) No periodic timer
> (XEN) VCPU2: CPU4 [has=F] flags=1 poll=0 upcall_pend = 00, upcall_mask
= 00
> dirty_cpus={} cpu_affinity={0-127}
> (XEN) No periodic timer
> (XEN) VCPU3: CPU5 [has=F] flags=1 poll=0 upcall_pend = 00, upcall_mask
= 00
> dirty_cpus={} cpu_affinity={0-127}
> (XEN) No periodic timer
> (XEN) VCPU4: CPU6 [has=F] flags=1 poll=28 upcall_pend = 01,
upcall_mask = 01
> dirty_cpus={} cpu_affinity={0-127}
> (XEN) No periodic timer
> (XEN) VCPU5: CPU7 [has=F] flags=1 poll=0 upcall_pend = 00, upcall_mask
= 00
> dirty_cpus={7} cpu_affinity={0-127}
> (XEN) No periodic timer
> (XEN) VCPU6: CPU0 [has=F] flags=1 poll=40 upcall_pend = 01,
upcall_mask = 01
> dirty_cpus={} cpu_affinity={0-127}
> (XEN) No periodic timer
> (XEN) VCPU7: CPU6 [has=T] flags=0 poll=0 upcall_pend = 00, upcall_mask
= 01
> dirty_cpus={6} cpu_affinity={0-127}
> (XEN) No periodic timer
> (XEN) Notifying guest 0:0 (virq 1, port 5, stat 0/0/0)
> (XEN) Notifying guest 0:1 (virq 1, port 11, stat 0/0/0)
> (XEN) Notifying guest 0:2 (virq 1, port 17, stat 0/0/0)
> (XEN) Notifying guest 0:3 (virq 1, port 23, stat 0/0/0)
> (XEN) Notifying guest 0:4 (virq 1, port 29, stat 0/0/0)
> (XEN) Notifying guest 0:5 (virq 1, port 35, stat 0/0/0)
> (XEN) Notifying guest 0:6 (virq 1, port 41, stat 0/0/0)
> (XEN) Notifying guest 0:7 (virq 1, port 47, stat 0/0/0)
> (XEN) Notifying guest 1:0 (virq 1, port 7, stat 0/0/-1)
> (XEN) Notifying guest 1:1 (virq 1, port 13, stat 0/0/-1)
> (XEN) Notifying guest 1:2 (virq 1, port 19, stat 0/0/0)
> (XEN) Notifying guest 1:3 (virq 1, port 25, stat 0/0/0)
> (XEN) Notifying guest 1:4 (virq 1, port 31, stat 0/0/-1)
> (XEN) Notifying guest 1:5 (virq 1, port 37, stat 0/0/0)
> (XEN) Notifying guest 1:6 (virq 1, port 43, stat 0/0/-1)
> (XEN) Notifying guest 1:7 (virq 1, port 49, stat 0/0/0)

So in this case, vcpu 1 is in a poll, on port 10, which is an IPI event
channel for itself.

Same for vcpu 4, except it is on port 28, and for vcpu 6 on port 60.

In each case, the event channels are masked (no surprise given the
conversation so far on this thread), and have no pending events. 
Therefore, I believe we are looking at the same bug.


>
>
> When the guest was unresponsive the console would still show:
> [10174.372092] INFO: rcu_sched detected stalls on CPUs/tasks: { 0 1}
(detected
> by 4, t=15002 jiffies)
> [10284.448089] INFO: rcu_bh detected stalls on CPUs/tasks: { 0 1 4 6}
(detected
> by 5, t=15004 jiffies)
>
> in a repeating pattern. So I take the above as cpus 1,4 and 6 are
polling. From
> the dump and the content of lock_spinners I get:
>
> cpu 0 and 1 -> ffff8803bfc13700 (which is runqueue[0] and is unlocked
again)
> cpu 4 and 6 -> ffffffff81f15ef0 (which is blkif_io_lock and is locked)

I wonder if there is possibly a race condition between notifying that a
lock has been unlocked, and another vcpu trying to poll after deciding
that the lock is locked.

The other option is that there is a bug in working out which event
channel to notify when a lock is unlocked.

~Andrew

>
>
> Backtraces would be somewhat inconsistent (as always). Note, I should
mention
> that I still had a kernel with my patch applied on that guest. That
changes
> things a bit (actually it takes a bit longer to hang but again that
might be
> just a matter of timing). The strange lock state of 2 spinners on an
unlocked
> lock remains the same with or without it.
>
> One question about the patch actually, would anybody think that there
could be a
> case where the unlocking cpu has itself on the spinners list? I did
not think so
> but that might be wrong.
>>
>> The IRQ handler for the spinlock evtchn in Linux is:
>> static irqreturn_t dummy_handler(int irq, void *dev_id)
>> {
>> BUG();
>> return IRQ_HANDLED;
>> }
>>
>> and right after we register it:
>> disable_irq(irq); /* make sure it's never delivered */
>>
>> The is no enable -- ignoring bugs of which there have been couple of
>> instances, but those trigger the BUG() so are pretty obvious.
>>
>> Ian.
>>
>>
>
>
>
>

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------030607010300050505080009
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: 8bit


  
    
  
  
    

    On 17/10/12 16:21, Stefan Bader wrote:

    > On 17.10.2012 15:55, Ian
      Campbell wrote:

      >> On Wed, 2012-10-17 at 14:28 +0100, Andrew Cooper wrote:

      >>> In our case, certain processes were locking up, and
      it turned out that

      >>> the kernel was issuing SCHOP_poll hypercalls (same
      the stack trace on

      >>> your launchpad ticket) on its own spinlock IPI event
      channel

      >>> (understandable, as its a spinlock), but with the
      event channel

      >>> masked, so it would never wake up from the poll. 

      >>

      >> I think (but you might want to check) that SCHEDOP_poll
      works (or is

      >> supposed to work!) regardless of whether the specific
      evtchn you ask for

      >> is masked or not.

      >

      > I was assuming it to be supposed to work at least in Xen
      4.1.2. Or at least if

      > it did not I would hope to catch VCPUs rather sitting on the
      hypercall than

      > doing nothing. Of course I cannot say how reliable
      information in crash is as

      > this is something new to do after Daniel fixed crash.

      >

      >>

      >> The Linux PV spinlock implementation takes advantage of
      this because it

      >> never wants to take a real interrupt from the spinlock
      poller evtchn.

      >

      > Right, I probably should have realized that. Though I guess
      it is still

      > interesting to see whether the channel is pending.

      >

      > So when just recreating, I got the q and e info which is
      (assuming the guest

      > domain is enough):

      >

      > (XEN) Event channel information for domain 1:

      > (XEN) Polling vCPUs: {1,4,6}

      > (XEN) port [p/m]

      > (XEN) 1 [0/0]: s=3 n=0 d=0 p=68 x=0

      > (XEN) 2 [1/0]: s=3 n=0 d=0 p=69 x=0

      > (XEN) 3 [1/0]: s=5 n=0 v=0 x=0

      > (XEN) 4 [1/1]: s=6 n=0 x=0

      > (XEN) 5 [1/0]: s=6 n=0 x=0

      > (XEN) 6 [0/0]: s=6 n=0 x=0

      > (XEN) 7 [0/0]: s=5 n=0 v=1 x=0

      > (XEN) 8 [0/0]: s=6 n=0 x=0

      > (XEN) 9 [1/0]: s=5 n=1 v=0 x=0

      > (XEN) 10 [0/1]: s=6 n=1 x=0

      > (XEN) 11 [1/0]: s=6 n=1 x=0

      > (XEN) 12 [0/0]: s=6 n=1 x=0

      > (XEN) 13 [0/0]: s=5 n=1 v=1 x=0

      > (XEN) 14 [0/0]: s=6 n=1 x=0

      > (XEN) 15 [0/0]: s=5 n=2 v=0 x=0

      > (XEN) 16 [1/1]: s=6 n=2 x=0

      > (XEN) 17 [0/0]: s=6 n=2 x=0

      > (XEN) 18 [0/0]: s=6 n=2 x=0

      > (XEN) 19 [0/0]: s=5 n=2 v=1 x=0

      > (XEN) 20 [0/0]: s=6 n=2 x=0

      > (XEN) 21 [0/0]: s=5 n=3 v=0 x=0

      > (XEN) 22 [1/1]: s=6 n=3 x=0

      > (XEN) 23 [0/0]: s=6 n=3 x=0

      > (XEN) 24 [0/0]: s=6 n=3 x=0

      > (XEN) 25 [0/0]: s=5 n=3 v=1 x=0

      > (XEN) 26 [0/0]: s=6 n=3 x=0

      > (XEN) 27 [1/0]: s=5 n=4 v=0 x=0

      > (XEN) 28 [0/1]: s=6 n=4 x=0

      > (XEN) 29 [1/0]: s=6 n=4 x=0

      > (XEN) 30 [0/0]: s=6 n=4 x=0

      > (XEN) 31 [0/0]: s=5 n=4 v=1 x=0

      > (XEN) 32 [0/0]: s=6 n=4 x=0

      > (XEN) 33 [0/0]: s=5 n=5 v=0 x=0

      > (XEN) 34 [0/1]: s=6 n=5 x=0

      > (XEN) 35 [0/0]: s=6 n=5 x=0

      > (XEN) 36 [0/0]: s=6 n=5 x=0

      > (XEN) 37 [0/0]: s=5 n=5 v=1 x=0

      > (XEN) 38 [0/0]: s=6 n=5 x=0

      > (XEN) 39 [1/0]: s=5 n=6 v=0 x=0

      > (XEN) 40 [0/1]: s=6 n=6 x=0

      > (XEN) 41 [1/0]: s=6 n=6 x=0

      > (XEN) 42 [0/0]: s=6 n=6 x=0

      > (XEN) 43 [0/0]: s=5 n=6 v=1 x=0

      > (XEN) 44 [0/0]: s=6 n=6 x=0event channel

      > (XEN) 45 [0/0]: s=5 n=7 v=0 x=0

      > (XEN) 46 [1/1]: s=6 n=7 x=0

      > (XEN) 47 [0/0]: s=6 n=7 x=0

      > (XEN) 48 [0/0]: s=6 n=7 x=0

      > (XEN) 49 [0/0]: s=5 n=7 v=1 x=0

      > (XEN) 50 [0/0]: s=6 n=7 x=0

      > (XEN) 51 [0/0]: s=3 n=7 d=0 p=70 x=0

      > (XEN) 52 [0/0]: s=3 n=0 d=0 p=71 x=0

      > (XEN) 53 [0/0]: s=3 n=0 d=0 p=72 x=0

      > (XEN) 54 [0/0]: s=3 n=0 d=0 p=73 x=0

      > (XEN) 55 [1/0]: s=3 n=0 d=0 p=74 x=0

      >

      > [maybe someone can tell me what the s,n,d,p and x mean]

    

    s = state.  0 = free, 1 = reserved, 2 = unbound, 3 = inter-domain, 4
    = pirq, 5 = virq, 6 = ipi

    n = target vcpu id to notify

    x = boolean indicating whether xen is a consumer of the event
    channel or not.

    

    d = target domain (when appropriate)  In this case, p is the target
    port.

    

    >

      >

      > (XEN) Rangesets belonging to domain 1:

      > (XEN) I/O Ports { }

      > (XEN) Interrupts { }

      > (XEN) I/O Memory { }

      > (XEN) Memory pages belonging to domain 1:

      > (XEN) DomPage list too long to display

      > (XEN) XenPage 00000000008000ab: caf=c000000000000002,
      taf=7400000000000002

      > (XEN) XenPage 00000000008000aa: caf=c000000000000002,
      taf=7400000000000002

      > (XEN) XenPage 00000000008000a9: caf=c000000000000002,
      taf=7400000000000002

      > (XEN) XenPage 00000000008000a8: caf=c000000000000001,
      taf=7400000000000001

      > (XEN) XenPage 00000000000dfae4: caf=c000000000000002,
      taf=7400000000000002

      > (XEN) VCPU information and callbacks for domain 1:

      > (XEN) VCPU0: CPU3 [has=T] flags=0 poll=0 upcall_pend = 01,
      upcall_mask = 01

      > dirty_cpus={3} cpu_affinity={0-127}

      > (XEN) No periodic timer

      > (XEN) VCPU1: CPU7 [has=F] flags=1 poll=10 upcall_pend = 01,
      upcall_mask = 01

      > dirty_cpus={} cpu_affinity={0-127}

      > (XEN) No periodic timer

      > (XEN) VCPU2: CPU4 [has=F] flags=1 poll=0 upcall_pend = 00,
      upcall_mask = 00

      > dirty_cpus={} cpu_affinity={0-127}

      > (XEN) No periodic timer

      > (XEN) VCPU3: CPU5 [has=F] flags=1 poll=0 upcall_pend = 00,
      upcall_mask = 00

      > dirty_cpus={} cpu_affinity={0-127}

      > (XEN) No periodic timer

      > (XEN) VCPU4: CPU6 [has=F] flags=1 poll=28 upcall_pend = 01,
      upcall_mask = 01

      > dirty_cpus={} cpu_affinity={0-127}

      > (XEN) No periodic timer

      > (XEN) VCPU5: CPU7 [has=F] flags=1 poll=0 upcall_pend = 00,
      upcall_mask = 00

      > dirty_cpus={7} cpu_affinity={0-127}

      > (XEN) No periodic timer

      > (XEN) VCPU6: CPU0 [has=F] flags=1 poll=40 upcall_pend = 01,
      upcall_mask = 01

      > dirty_cpus={} cpu_affinity={0-127}

      > (XEN) No periodic timer

      > (XEN) VCPU7: CPU6 [has=T] flags=0 poll=0 upcall_pend = 00,
      upcall_mask = 01

      > dirty_cpus={6} cpu_affinity={0-127}

      > (XEN) No periodic timer

      > (XEN) Notifying guest 0:0 (virq 1, port 5, stat 0/0/0)

      > (XEN) Notifying guest 0:1 (virq 1, port 11, stat 0/0/0)

      > (XEN) Notifying guest 0:2 (virq 1, port 17, stat 0/0/0)

      > (XEN) Notifying guest 0:3 (virq 1, port 23, stat 0/0/0)

      > (XEN) Notifying guest 0:4 (virq 1, port 29, stat 0/0/0)

      > (XEN) Notifying guest 0:5 (virq 1, port 35, stat 0/0/0)

      > (XEN) Notifying guest 0:6 (virq 1, port 41, stat 0/0/0)

      > (XEN) Notifying guest 0:7 (virq 1, port 47, stat 0/0/0)

      > (XEN) Notifying guest 1:0 (virq 1, port 7, stat 0/0/-1)

      > (XEN) Notifying guest 1:1 (virq 1, port 13, stat 0/0/-1)

      > (XEN) Notifying guest 1:2 (virq 1, port 19, stat 0/0/0)

      > (XEN) Notifying guest 1:3 (virq 1, port 25, stat 0/0/0)

      > (XEN) Notifying guest 1:4 (virq 1, port 31, stat 0/0/-1)

      > (XEN) Notifying guest 1:5 (virq 1, port 37, stat 0/0/0)

      > (XEN) Notifying guest 1:6 (virq 1, port 43, stat 0/0/-1)

      > (XEN) Notifying guest 1:7 (virq 1, port 49, stat 0/0/0)

    

    So in this case, vcpu 1 is in a poll, on port 10, which is an IPI
    event channel for itself.

    

    Same for vcpu 4, except it is on port 28, and for vcpu 6 on port 60.

    

    In each case, the event channels are masked (no surprise given the
    conversation so far on this thread), and have no pending events. 
    Therefore, I believe we are looking at the same bug.

    

    

    >

      >

      > When the guest was unresponsive the console would still show:

      > [10174.372092] INFO: rcu_sched detected stalls on CPUs/tasks:
      { 0 1} (detected

      > by 4, t=15002 jiffies)

      > [10284.448089] INFO: rcu_bh detected stalls on CPUs/tasks: {
      0 1 4 6} (detected

      > by 5, t=15004 jiffies)

      >

      > in a repeating pattern. So I take the above as cpus 1,4 and 6
      are polling. From

      > the dump and the content of lock_spinners I get:

      >

      > cpu 0 and 1 -> ffff8803bfc13700 (which is runqueue[0] and
      is unlocked again)

      > cpu 4 and 6 -> ffffffff81f15ef0 (which is blkif_io_lock
      and is locked)

    

    I wonder if there is possibly a race condition between notifying
    that a lock has been unlocked, and another vcpu trying to poll after
    deciding that the lock is locked.

    

    The other option is that there is a bug in working out which event
    channel to notify when a lock is unlocked.

    

    ~Andrew

    

    >

      >

      > Backtraces would be somewhat inconsistent (as always). Note,
      I should mention

      > that I still had a kernel with my patch applied on that
      guest. That changes

      > things a bit (actually it takes a bit longer to hang but
      again that might be

      > just a matter of timing). The strange lock state of 2
      spinners on an unlocked

      > lock remains the same with or without it.

      >

      > One question about the patch actually, would anybody think
      that there could be a

      > case where the unlocking cpu has itself on the spinners list?
      I did not think so

      > but that might be wrong.

      >> 

      >> The IRQ handler for the spinlock evtchn in Linux is:

      >> static irqreturn_t dummy_handler(int irq, void *dev_id)

      >> {

      >> BUG();

      >> return IRQ_HANDLED;

      >> }

      >> 

      >> and right after we register it:

      >> disable_irq(irq); /* make sure it's never delivered */

      >>

      >> The is no enable -- ignoring bugs of which there have
      been couple of

      >> instances, but those trigger the BUG() so are pretty
      obvious.

      >>

      >> Ian.

      >>

      >>

      >

      >

      >

      >

    

    -- 

    Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer

    T: +44 (0)1223 225 900, http://www.citrix.com

    

  


--------------030607010300050505080009--


--===============6179704354617584911==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6179704354617584911==--


From xen-devel-bounces@lists.xen.org Wed Oct 17 15:35:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 15:35:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOVea-0006bk-CJ; Wed, 17 Oct 2012 15:35:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOVeY-0006bc-4H
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 15:35:26 +0000
Received: from [85.158.143.99:26968] by server-2.bemta-4.messagelabs.com id
	00/8E-22268-D30DE705; Wed, 17 Oct 2012 15:35:25 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1350488121!27502628!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODMwNDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18019 invoked from network); 17 Oct 2012 15:35:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 15:35:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,601,1344211200"; 
	d="scan'208,217";a="211577252"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 15:35:21 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 11:35:20 -0400
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TOVeS-0001Vl-9u;
	Wed, 17 Oct 2012 16:35:20 +0100
Message-ID: <507ED038.8000806@citrix.com>
Date: Wed, 17 Oct 2012 16:35:20 +0100
From: Andrew Cooper 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Stefan Bader 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
	<1350482118.2460.74.camel@zakaz.uk.xensource.com>
	<507ECD06.2050407@canonical.com>
In-Reply-To: <507ECD06.2050407@canonical.com>
X-Enigmail-Version: 1.4.5
Cc: Konrad Rzeszutek Wilk ,
	Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============6179704354617584911=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6179704354617584911==
Content-Type: multipart/alternative;
	boundary="------------030607010300050505080009"

--------------030607010300050505080009
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit


On 17/10/12 16:21, Stefan Bader wrote:
> On 17.10.2012 15:55, Ian Campbell wrote:
>> On Wed, 2012-10-17 at 14:28 +0100, Andrew Cooper wrote:
>>> In our case, certain processes were locking up, and it turned out that
>>> the kernel was issuing SCHOP_poll hypercalls (same the stack trace on
>>> your launchpad ticket) on its own spinlock IPI event channel
>>> (understandable, as its a spinlock), but with the event channel
>>> masked, so it would never wake up from the poll.
>>
>> I think (but you might want to check) that SCHEDOP_poll works (or is
>> supposed to work!) regardless of whether the specific evtchn you ask for
>> is masked or not.
>
> I was assuming it to be supposed to work at least in Xen 4.1.2. Or at
least if
> it did not I would hope to catch VCPUs rather sitting on the hypercall
than
> doing nothing. Of course I cannot say how reliable information in
crash is as
> this is something new to do after Daniel fixed crash.
>
>>
>> The Linux PV spinlock implementation takes advantage of this because it
>> never wants to take a real interrupt from the spinlock poller evtchn.
>
> Right, I probably should have realized that. Though I guess it is still
> interesting to see whether the channel is pending.
>
> So when just recreating, I got the q and e info which is (assuming the
guest
> domain is enough):
>
> (XEN) Event channel information for domain 1:
> (XEN) Polling vCPUs: {1,4,6}
> (XEN) port [p/m]
> (XEN) 1 [0/0]: s=3 n=0 d=0 p=68 x=0
> (XEN) 2 [1/0]: s=3 n=0 d=0 p=69 x=0
> (XEN) 3 [1/0]: s=5 n=0 v=0 x=0
> (XEN) 4 [1/1]: s=6 n=0 x=0
> (XEN) 5 [1/0]: s=6 n=0 x=0
> (XEN) 6 [0/0]: s=6 n=0 x=0
> (XEN) 7 [0/0]: s=5 n=0 v=1 x=0
> (XEN) 8 [0/0]: s=6 n=0 x=0
> (XEN) 9 [1/0]: s=5 n=1 v=0 x=0
> (XEN) 10 [0/1]: s=6 n=1 x=0
> (XEN) 11 [1/0]: s=6 n=1 x=0
> (XEN) 12 [0/0]: s=6 n=1 x=0
> (XEN) 13 [0/0]: s=5 n=1 v=1 x=0
> (XEN) 14 [0/0]: s=6 n=1 x=0
> (XEN) 15 [0/0]: s=5 n=2 v=0 x=0
> (XEN) 16 [1/1]: s=6 n=2 x=0
> (XEN) 17 [0/0]: s=6 n=2 x=0
> (XEN) 18 [0/0]: s=6 n=2 x=0
> (XEN) 19 [0/0]: s=5 n=2 v=1 x=0
> (XEN) 20 [0/0]: s=6 n=2 x=0
> (XEN) 21 [0/0]: s=5 n=3 v=0 x=0
> (XEN) 22 [1/1]: s=6 n=3 x=0
> (XEN) 23 [0/0]: s=6 n=3 x=0
> (XEN) 24 [0/0]: s=6 n=3 x=0
> (XEN) 25 [0/0]: s=5 n=3 v=1 x=0
> (XEN) 26 [0/0]: s=6 n=3 x=0
> (XEN) 27 [1/0]: s=5 n=4 v=0 x=0
> (XEN) 28 [0/1]: s=6 n=4 x=0
> (XEN) 29 [1/0]: s=6 n=4 x=0
> (XEN) 30 [0/0]: s=6 n=4 x=0
> (XEN) 31 [0/0]: s=5 n=4 v=1 x=0
> (XEN) 32 [0/0]: s=6 n=4 x=0
> (XEN) 33 [0/0]: s=5 n=5 v=0 x=0
> (XEN) 34 [0/1]: s=6 n=5 x=0
> (XEN) 35 [0/0]: s=6 n=5 x=0
> (XEN) 36 [0/0]: s=6 n=5 x=0
> (XEN) 37 [0/0]: s=5 n=5 v=1 x=0
> (XEN) 38 [0/0]: s=6 n=5 x=0
> (XEN) 39 [1/0]: s=5 n=6 v=0 x=0
> (XEN) 40 [0/1]: s=6 n=6 x=0
> (XEN) 41 [1/0]: s=6 n=6 x=0
> (XEN) 42 [0/0]: s=6 n=6 x=0
> (XEN) 43 [0/0]: s=5 n=6 v=1 x=0
> (XEN) 44 [0/0]: s=6 n=6 x=0event channel
> (XEN) 45 [0/0]: s=5 n=7 v=0 x=0
> (XEN) 46 [1/1]: s=6 n=7 x=0
> (XEN) 47 [0/0]: s=6 n=7 x=0
> (XEN) 48 [0/0]: s=6 n=7 x=0
> (XEN) 49 [0/0]: s=5 n=7 v=1 x=0
> (XEN) 50 [0/0]: s=6 n=7 x=0
> (XEN) 51 [0/0]: s=3 n=7 d=0 p=70 x=0
> (XEN) 52 [0/0]: s=3 n=0 d=0 p=71 x=0
> (XEN) 53 [0/0]: s=3 n=0 d=0 p=72 x=0
> (XEN) 54 [0/0]: s=3 n=0 d=0 p=73 x=0
> (XEN) 55 [1/0]: s=3 n=0 d=0 p=74 x=0
>
> [maybe someone can tell me what the s,n,d,p and x mean]

s = state.  0 = free, 1 = reserved, 2 = unbound, 3 = inter-domain, 4 =
pirq, 5 = virq, 6 = ipi
n = target vcpu id to notify
x = boolean indicating whether xen is a consumer of the event channel or
not.

d = target domain (when appropriate)  In this case, p is the target port.

>
>
> (XEN) Rangesets belonging to domain 1:
> (XEN) I/O Ports { }
> (XEN) Interrupts { }
> (XEN) I/O Memory { }
> (XEN) Memory pages belonging to domain 1:
> (XEN) DomPage list too long to display
> (XEN) XenPage 00000000008000ab: caf=c000000000000002, taf=7400000000000002
> (XEN) XenPage 00000000008000aa: caf=c000000000000002, taf=7400000000000002
> (XEN) XenPage 00000000008000a9: caf=c000000000000002, taf=7400000000000002
> (XEN) XenPage 00000000008000a8: caf=c000000000000001, taf=7400000000000001
> (XEN) XenPage 00000000000dfae4: caf=c000000000000002, taf=7400000000000002
> (XEN) VCPU information and callbacks for domain 1:
> (XEN) VCPU0: CPU3 [has=T] flags=0 poll=0 upcall_pend = 01, upcall_mask
= 01
> dirty_cpus={3} cpu_affinity={0-127}
> (XEN) No periodic timer
> (XEN) VCPU1: CPU7 [has=F] flags=1 poll=10 upcall_pend = 01,
upcall_mask = 01
> dirty_cpus={} cpu_affinity={0-127}
> (XEN) No periodic timer
> (XEN) VCPU2: CPU4 [has=F] flags=1 poll=0 upcall_pend = 00, upcall_mask
= 00
> dirty_cpus={} cpu_affinity={0-127}
> (XEN) No periodic timer
> (XEN) VCPU3: CPU5 [has=F] flags=1 poll=0 upcall_pend = 00, upcall_mask
= 00
> dirty_cpus={} cpu_affinity={0-127}
> (XEN) No periodic timer
> (XEN) VCPU4: CPU6 [has=F] flags=1 poll=28 upcall_pend = 01,
upcall_mask = 01
> dirty_cpus={} cpu_affinity={0-127}
> (XEN) No periodic timer
> (XEN) VCPU5: CPU7 [has=F] flags=1 poll=0 upcall_pend = 00, upcall_mask
= 00
> dirty_cpus={7} cpu_affinity={0-127}
> (XEN) No periodic timer
> (XEN) VCPU6: CPU0 [has=F] flags=1 poll=40 upcall_pend = 01,
upcall_mask = 01
> dirty_cpus={} cpu_affinity={0-127}
> (XEN) No periodic timer
> (XEN) VCPU7: CPU6 [has=T] flags=0 poll=0 upcall_pend = 00, upcall_mask
= 01
> dirty_cpus={6} cpu_affinity={0-127}
> (XEN) No periodic timer
> (XEN) Notifying guest 0:0 (virq 1, port 5, stat 0/0/0)
> (XEN) Notifying guest 0:1 (virq 1, port 11, stat 0/0/0)
> (XEN) Notifying guest 0:2 (virq 1, port 17, stat 0/0/0)
> (XEN) Notifying guest 0:3 (virq 1, port 23, stat 0/0/0)
> (XEN) Notifying guest 0:4 (virq 1, port 29, stat 0/0/0)
> (XEN) Notifying guest 0:5 (virq 1, port 35, stat 0/0/0)
> (XEN) Notifying guest 0:6 (virq 1, port 41, stat 0/0/0)
> (XEN) Notifying guest 0:7 (virq 1, port 47, stat 0/0/0)
> (XEN) Notifying guest 1:0 (virq 1, port 7, stat 0/0/-1)
> (XEN) Notifying guest 1:1 (virq 1, port 13, stat 0/0/-1)
> (XEN) Notifying guest 1:2 (virq 1, port 19, stat 0/0/0)
> (XEN) Notifying guest 1:3 (virq 1, port 25, stat 0/0/0)
> (XEN) Notifying guest 1:4 (virq 1, port 31, stat 0/0/-1)
> (XEN) Notifying guest 1:5 (virq 1, port 37, stat 0/0/0)
> (XEN) Notifying guest 1:6 (virq 1, port 43, stat 0/0/-1)
> (XEN) Notifying guest 1:7 (virq 1, port 49, stat 0/0/0)

So in this case, vcpu 1 is in a poll, on port 10, which is an IPI event
channel for itself.

Same for vcpu 4, except it is on port 28, and for vcpu 6 on port 60.

In each case, the event channels are masked (no surprise given the
conversation so far on this thread), and have no pending events. 
Therefore, I believe we are looking at the same bug.


>
>
> When the guest was unresponsive the console would still show:
> [10174.372092] INFO: rcu_sched detected stalls on CPUs/tasks: { 0 1}
(detected
> by 4, t=15002 jiffies)
> [10284.448089] INFO: rcu_bh detected stalls on CPUs/tasks: { 0 1 4 6}
(detected
> by 5, t=15004 jiffies)
>
> in a repeating pattern. So I take the above as cpus 1,4 and 6 are
polling. From
> the dump and the content of lock_spinners I get:
>
> cpu 0 and 1 -> ffff8803bfc13700 (which is runqueue[0] and is unlocked
again)
> cpu 4 and 6 -> ffffffff81f15ef0 (which is blkif_io_lock and is locked)

I wonder if there is possibly a race condition between notifying that a
lock has been unlocked, and another vcpu trying to poll after deciding
that the lock is locked.

The other option is that there is a bug in working out which event
channel to notify when a lock is unlocked.

~Andrew

>
>
> Backtraces would be somewhat inconsistent (as always). Note, I should
mention
> that I still had a kernel with my patch applied on that guest. That
changes
> things a bit (actually it takes a bit longer to hang but again that
might be
> just a matter of timing). The strange lock state of 2 spinners on an
unlocked
> lock remains the same with or without it.
>
> One question about the patch actually, would anybody think that there
could be a
> case where the unlocking cpu has itself on the spinners list? I did
not think so
> but that might be wrong.
>>
>> The IRQ handler for the spinlock evtchn in Linux is:
>> static irqreturn_t dummy_handler(int irq, void *dev_id)
>> {
>> BUG();
>> return IRQ_HANDLED;
>> }
>>
>> and right after we register it:
>> disable_irq(irq); /* make sure it's never delivered */
>>
>> The is no enable -- ignoring bugs of which there have been couple of
>> instances, but those trigger the BUG() so are pretty obvious.
>>
>> Ian.
>>
>>
>
>
>
>

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------030607010300050505080009
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: 8bit


  
    
  
  
    

    On 17/10/12 16:21, Stefan Bader wrote:

    > On 17.10.2012 15:55, Ian
      Campbell wrote:

      >> On Wed, 2012-10-17 at 14:28 +0100, Andrew Cooper wrote:

      >>> In our case, certain processes were locking up, and
      it turned out that

      >>> the kernel was issuing SCHOP_poll hypercalls (same
      the stack trace on

      >>> your launchpad ticket) on its own spinlock IPI event
      channel

      >>> (understandable, as its a spinlock), but with the
      event channel

      >>> masked, so it would never wake up from the poll. 

      >>

      >> I think (but you might want to check) that SCHEDOP_poll
      works (or is

      >> supposed to work!) regardless of whether the specific
      evtchn you ask for

      >> is masked or not.

      >

      > I was assuming it to be supposed to work at least in Xen
      4.1.2. Or at least if

      > it did not I would hope to catch VCPUs rather sitting on the
      hypercall than

      > doing nothing. Of course I cannot say how reliable
      information in crash is as

      > this is something new to do after Daniel fixed crash.

      >

      >>

      >> The Linux PV spinlock implementation takes advantage of
      this because it

      >> never wants to take a real interrupt from the spinlock
      poller evtchn.

      >

      > Right, I probably should have realized that. Though I guess
      it is still

      > interesting to see whether the channel is pending.

      >

      > So when just recreating, I got the q and e info which is
      (assuming the guest

      > domain is enough):

      >

      > (XEN) Event channel information for domain 1:

      > (XEN) Polling vCPUs: {1,4,6}

      > (XEN) port [p/m]

      > (XEN) 1 [0/0]: s=3 n=0 d=0 p=68 x=0

      > (XEN) 2 [1/0]: s=3 n=0 d=0 p=69 x=0

      > (XEN) 3 [1/0]: s=5 n=0 v=0 x=0

      > (XEN) 4 [1/1]: s=6 n=0 x=0

      > (XEN) 5 [1/0]: s=6 n=0 x=0

      > (XEN) 6 [0/0]: s=6 n=0 x=0

      > (XEN) 7 [0/0]: s=5 n=0 v=1 x=0

      > (XEN) 8 [0/0]: s=6 n=0 x=0

      > (XEN) 9 [1/0]: s=5 n=1 v=0 x=0

      > (XEN) 10 [0/1]: s=6 n=1 x=0

      > (XEN) 11 [1/0]: s=6 n=1 x=0

      > (XEN) 12 [0/0]: s=6 n=1 x=0

      > (XEN) 13 [0/0]: s=5 n=1 v=1 x=0

      > (XEN) 14 [0/0]: s=6 n=1 x=0

      > (XEN) 15 [0/0]: s=5 n=2 v=0 x=0

      > (XEN) 16 [1/1]: s=6 n=2 x=0

      > (XEN) 17 [0/0]: s=6 n=2 x=0

      > (XEN) 18 [0/0]: s=6 n=2 x=0

      > (XEN) 19 [0/0]: s=5 n=2 v=1 x=0

      > (XEN) 20 [0/0]: s=6 n=2 x=0

      > (XEN) 21 [0/0]: s=5 n=3 v=0 x=0

      > (XEN) 22 [1/1]: s=6 n=3 x=0

      > (XEN) 23 [0/0]: s=6 n=3 x=0

      > (XEN) 24 [0/0]: s=6 n=3 x=0

      > (XEN) 25 [0/0]: s=5 n=3 v=1 x=0

      > (XEN) 26 [0/0]: s=6 n=3 x=0

      > (XEN) 27 [1/0]: s=5 n=4 v=0 x=0

      > (XEN) 28 [0/1]: s=6 n=4 x=0

      > (XEN) 29 [1/0]: s=6 n=4 x=0

      > (XEN) 30 [0/0]: s=6 n=4 x=0

      > (XEN) 31 [0/0]: s=5 n=4 v=1 x=0

      > (XEN) 32 [0/0]: s=6 n=4 x=0

      > (XEN) 33 [0/0]: s=5 n=5 v=0 x=0

      > (XEN) 34 [0/1]: s=6 n=5 x=0

      > (XEN) 35 [0/0]: s=6 n=5 x=0

      > (XEN) 36 [0/0]: s=6 n=5 x=0

      > (XEN) 37 [0/0]: s=5 n=5 v=1 x=0

      > (XEN) 38 [0/0]: s=6 n=5 x=0

      > (XEN) 39 [1/0]: s=5 n=6 v=0 x=0

      > (XEN) 40 [0/1]: s=6 n=6 x=0

      > (XEN) 41 [1/0]: s=6 n=6 x=0

      > (XEN) 42 [0/0]: s=6 n=6 x=0

      > (XEN) 43 [0/0]: s=5 n=6 v=1 x=0

      > (XEN) 44 [0/0]: s=6 n=6 x=0event channel

      > (XEN) 45 [0/0]: s=5 n=7 v=0 x=0

      > (XEN) 46 [1/1]: s=6 n=7 x=0

      > (XEN) 47 [0/0]: s=6 n=7 x=0

      > (XEN) 48 [0/0]: s=6 n=7 x=0

      > (XEN) 49 [0/0]: s=5 n=7 v=1 x=0

      > (XEN) 50 [0/0]: s=6 n=7 x=0

      > (XEN) 51 [0/0]: s=3 n=7 d=0 p=70 x=0

      > (XEN) 52 [0/0]: s=3 n=0 d=0 p=71 x=0

      > (XEN) 53 [0/0]: s=3 n=0 d=0 p=72 x=0

      > (XEN) 54 [0/0]: s=3 n=0 d=0 p=73 x=0

      > (XEN) 55 [1/0]: s=3 n=0 d=0 p=74 x=0

      >

      > [maybe someone can tell me what the s,n,d,p and x mean]

    

    s = state.  0 = free, 1 = reserved, 2 = unbound, 3 = inter-domain, 4
    = pirq, 5 = virq, 6 = ipi

    n = target vcpu id to notify

    x = boolean indicating whether xen is a consumer of the event
    channel or not.

    

    d = target domain (when appropriate)  In this case, p is the target
    port.

    

    >

      >

      > (XEN) Rangesets belonging to domain 1:

      > (XEN) I/O Ports { }

      > (XEN) Interrupts { }

      > (XEN) I/O Memory { }

      > (XEN) Memory pages belonging to domain 1:

      > (XEN) DomPage list too long to display

      > (XEN) XenPage 00000000008000ab: caf=c000000000000002,
      taf=7400000000000002

      > (XEN) XenPage 00000000008000aa: caf=c000000000000002,
      taf=7400000000000002

      > (XEN) XenPage 00000000008000a9: caf=c000000000000002,
      taf=7400000000000002

      > (XEN) XenPage 00000000008000a8: caf=c000000000000001,
      taf=7400000000000001

      > (XEN) XenPage 00000000000dfae4: caf=c000000000000002,
      taf=7400000000000002

      > (XEN) VCPU information and callbacks for domain 1:

      > (XEN) VCPU0: CPU3 [has=T] flags=0 poll=0 upcall_pend = 01,
      upcall_mask = 01

      > dirty_cpus={3} cpu_affinity={0-127}

      > (XEN) No periodic timer

      > (XEN) VCPU1: CPU7 [has=F] flags=1 poll=10 upcall_pend = 01,
      upcall_mask = 01

      > dirty_cpus={} cpu_affinity={0-127}

      > (XEN) No periodic timer

      > (XEN) VCPU2: CPU4 [has=F] flags=1 poll=0 upcall_pend = 00,
      upcall_mask = 00

      > dirty_cpus={} cpu_affinity={0-127}

      > (XEN) No periodic timer

      > (XEN) VCPU3: CPU5 [has=F] flags=1 poll=0 upcall_pend = 00,
      upcall_mask = 00

      > dirty_cpus={} cpu_affinity={0-127}

      > (XEN) No periodic timer

      > (XEN) VCPU4: CPU6 [has=F] flags=1 poll=28 upcall_pend = 01,
      upcall_mask = 01

      > dirty_cpus={} cpu_affinity={0-127}

      > (XEN) No periodic timer

      > (XEN) VCPU5: CPU7 [has=F] flags=1 poll=0 upcall_pend = 00,
      upcall_mask = 00

      > dirty_cpus={7} cpu_affinity={0-127}

      > (XEN) No periodic timer

      > (XEN) VCPU6: CPU0 [has=F] flags=1 poll=40 upcall_pend = 01,
      upcall_mask = 01

      > dirty_cpus={} cpu_affinity={0-127}

      > (XEN) No periodic timer

      > (XEN) VCPU7: CPU6 [has=T] flags=0 poll=0 upcall_pend = 00,
      upcall_mask = 01

      > dirty_cpus={6} cpu_affinity={0-127}

      > (XEN) No periodic timer

      > (XEN) Notifying guest 0:0 (virq 1, port 5, stat 0/0/0)

      > (XEN) Notifying guest 0:1 (virq 1, port 11, stat 0/0/0)

      > (XEN) Notifying guest 0:2 (virq 1, port 17, stat 0/0/0)

      > (XEN) Notifying guest 0:3 (virq 1, port 23, stat 0/0/0)

      > (XEN) Notifying guest 0:4 (virq 1, port 29, stat 0/0/0)

      > (XEN) Notifying guest 0:5 (virq 1, port 35, stat 0/0/0)

      > (XEN) Notifying guest 0:6 (virq 1, port 41, stat 0/0/0)

      > (XEN) Notifying guest 0:7 (virq 1, port 47, stat 0/0/0)

      > (XEN) Notifying guest 1:0 (virq 1, port 7, stat 0/0/-1)

      > (XEN) Notifying guest 1:1 (virq 1, port 13, stat 0/0/-1)

      > (XEN) Notifying guest 1:2 (virq 1, port 19, stat 0/0/0)

      > (XEN) Notifying guest 1:3 (virq 1, port 25, stat 0/0/0)

      > (XEN) Notifying guest 1:4 (virq 1, port 31, stat 0/0/-1)

      > (XEN) Notifying guest 1:5 (virq 1, port 37, stat 0/0/0)

      > (XEN) Notifying guest 1:6 (virq 1, port 43, stat 0/0/-1)

      > (XEN) Notifying guest 1:7 (virq 1, port 49, stat 0/0/0)

    

    So in this case, vcpu 1 is in a poll, on port 10, which is an IPI
    event channel for itself.

    

    Same for vcpu 4, except it is on port 28, and for vcpu 6 on port 60.

    

    In each case, the event channels are masked (no surprise given the
    conversation so far on this thread), and have no pending events. 
    Therefore, I believe we are looking at the same bug.

    

    

    >

      >

      > When the guest was unresponsive the console would still show:

      > [10174.372092] INFO: rcu_sched detected stalls on CPUs/tasks:
      { 0 1} (detected

      > by 4, t=15002 jiffies)

      > [10284.448089] INFO: rcu_bh detected stalls on CPUs/tasks: {
      0 1 4 6} (detected

      > by 5, t=15004 jiffies)

      >

      > in a repeating pattern. So I take the above as cpus 1,4 and 6
      are polling. From

      > the dump and the content of lock_spinners I get:

      >

      > cpu 0 and 1 -> ffff8803bfc13700 (which is runqueue[0] and
      is unlocked again)

      > cpu 4 and 6 -> ffffffff81f15ef0 (which is blkif_io_lock
      and is locked)

    

    I wonder if there is possibly a race condition between notifying
    that a lock has been unlocked, and another vcpu trying to poll after
    deciding that the lock is locked.

    

    The other option is that there is a bug in working out which event
    channel to notify when a lock is unlocked.

    

    ~Andrew

    

    >

      >

      > Backtraces would be somewhat inconsistent (as always). Note,
      I should mention

      > that I still had a kernel with my patch applied on that
      guest. That changes

      > things a bit (actually it takes a bit longer to hang but
      again that might be

      > just a matter of timing). The strange lock state of 2
      spinners on an unlocked

      > lock remains the same with or without it.

      >

      > One question about the patch actually, would anybody think
      that there could be a

      > case where the unlocking cpu has itself on the spinners list?
      I did not think so

      > but that might be wrong.

      >> 

      >> The IRQ handler for the spinlock evtchn in Linux is:

      >> static irqreturn_t dummy_handler(int irq, void *dev_id)

      >> {

      >> BUG();

      >> return IRQ_HANDLED;

      >> }

      >> 

      >> and right after we register it:

      >> disable_irq(irq); /* make sure it's never delivered */

      >>

      >> The is no enable -- ignoring bugs of which there have
      been couple of

      >> instances, but those trigger the BUG() so are pretty
      obvious.

      >>

      >> Ian.

      >>

      >>

      >

      >

      >

      >

    

    -- 

    Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer

    T: +44 (0)1223 225 900, http://www.citrix.com

    

  


--------------030607010300050505080009--


--===============6179704354617584911==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6179704354617584911==--


From xen-devel-bounces@lists.xen.org Wed Oct 17 15:38:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 15:38:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOVhI-0006l1-5g; Wed, 17 Oct 2012 15:38:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOVhG-0006kt-Om
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 15:38:15 +0000
Received: from [85.158.143.35:15647] by server-1.bemta-4.messagelabs.com id
	F4/C3-19134-6E0DE705; Wed, 17 Oct 2012 15:38:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1350488293!12650723!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15292 invoked from network); 17 Oct 2012 15:38:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 15:38:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,601,1344211200"; d="scan'208";a="15230691"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 15:38:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 16:38:13 +0100
Message-ID: <1350488291.2460.75.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Wed, 17 Oct 2012 16:38:11 +0100
In-Reply-To: 
References: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
	<1350314444-17148-1-git-send-email-ian.campbell@citrix.com>
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" , "Tim \(Xen.org\)" ,
	Jan Beulich ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 01/10] xen: arm: implement
	XENMEM_add_to_physmap_range
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-17 at 16:31 +0100, Stefano Stabellini wrote:
> On Mon, 15 Oct 2012, Ian Campbell wrote:
> > diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
> > index 86d02c8..f1ddbc0 100644
> > --- a/xen/include/public/memory.h
> > +++ b/xen/include/public/memory.h
> > @@ -198,6 +198,15 @@ struct xen_machphys_mapping {
> >  typedef struct xen_machphys_mapping xen_machphys_mapping_t;
> >  DEFINE_XEN_GUEST_HANDLE(xen_machphys_mapping_t);
> >  
> > +/* Source mapping space. */
> > +/* ` enum phys_map_space { */
> 
> I don't think that these comments about the enum add any value.

They are part of the infrastructure which generates useful symlinks and
cross references in http://xenbits.xen.org/docs.

> 
> In any case the patch is simple and seems correct so:
> 
> Acked-by: Stefano Stabellini 

Thanks.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 15:38:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 15:38:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOVhI-0006l1-5g; Wed, 17 Oct 2012 15:38:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOVhG-0006kt-Om
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 15:38:15 +0000
Received: from [85.158.143.35:15647] by server-1.bemta-4.messagelabs.com id
	F4/C3-19134-6E0DE705; Wed, 17 Oct 2012 15:38:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1350488293!12650723!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15292 invoked from network); 17 Oct 2012 15:38:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 15:38:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,601,1344211200"; d="scan'208";a="15230691"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 15:38:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 16:38:13 +0100
Message-ID: <1350488291.2460.75.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Wed, 17 Oct 2012 16:38:11 +0100
In-Reply-To: 
References: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
	<1350314444-17148-1-git-send-email-ian.campbell@citrix.com>
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" , "Tim \(Xen.org\)" ,
	Jan Beulich ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 01/10] xen: arm: implement
	XENMEM_add_to_physmap_range
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-17 at 16:31 +0100, Stefano Stabellini wrote:
> On Mon, 15 Oct 2012, Ian Campbell wrote:
> > diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
> > index 86d02c8..f1ddbc0 100644
> > --- a/xen/include/public/memory.h
> > +++ b/xen/include/public/memory.h
> > @@ -198,6 +198,15 @@ struct xen_machphys_mapping {
> >  typedef struct xen_machphys_mapping xen_machphys_mapping_t;
> >  DEFINE_XEN_GUEST_HANDLE(xen_machphys_mapping_t);
> >  
> > +/* Source mapping space. */
> > +/* ` enum phys_map_space { */
> 
> I don't think that these comments about the enum add any value.

They are part of the infrastructure which generates useful symlinks and
cross references in http://xenbits.xen.org/docs.

> 
> In any case the patch is simple and seems correct so:
> 
> Acked-by: Stefano Stabellini 

Thanks.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 15:45:06 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 15:45:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOVne-0006xI-8Z; Wed, 17 Oct 2012 15:44:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOVnc-0006xD-Um
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 15:44:49 +0000
Received: from [193.109.254.147:11589] by server-7.bemta-14.messagelabs.com id
	AD/62-24122-072DE705; Wed, 17 Oct 2012 15:44:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1350488687!11708459!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3704 invoked from network); 17 Oct 2012 15:44:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 15:44:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,601,1344211200"; d="scan'208";a="15230827"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 15:44:47 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 16:44:47 +0100
Message-ID: <1350488686.2460.76.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: "Keir (Xen.org)" 
Date: Wed, 17 Oct 2012 16:44:46 +0100
In-Reply-To: <1350398712.18058.120.camel@zakaz.uk.xensource.com>
References: 
	<1350398712.18058.120.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel , "Tim \(Xen.org\)" ,
	Jan Beulich ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH v2 00/10] 64 bit ARM ABI,
 map foreign gmfn API, ARM grant tables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-16 at 15:45 +0100, Ian Campbell wrote:
> On Mon, 2012-10-15 at 16:48 +0100, Keir Fraser wrote:
> > On 15/10/2012 16:20, "Ian Campbell"  wrote:
> > 
> > > This is v2 of "Sweep through arm-for-4.3 branch + a bit extra" retitled
> > > since most of the sweep through stuff has been swept through already and
> > > just the bit extra remains.
> > > 
> > > I've addressed the review comments and fixed the bisection issue. A
> > > bunch of this stuff is cross arch and/or touches common code.
> > 
> > Those bits are fine by me, now.
> > 
> > Acked-by: Keir Fraser 
> 
> Thanks, I'll give it a while for others to comment and plan to shovel it
> in tomorrow or Thursday unless there are objections.

Added Stefano's + your acks and pushed, thanks

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 15:45:06 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 15:45:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOVne-0006xI-8Z; Wed, 17 Oct 2012 15:44:50 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOVnc-0006xD-Um
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 15:44:49 +0000
Received: from [193.109.254.147:11589] by server-7.bemta-14.messagelabs.com id
	AD/62-24122-072DE705; Wed, 17 Oct 2012 15:44:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1350488687!11708459!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3704 invoked from network); 17 Oct 2012 15:44:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 15:44:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,601,1344211200"; d="scan'208";a="15230827"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 15:44:47 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 16:44:47 +0100
Message-ID: <1350488686.2460.76.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: "Keir (Xen.org)" 
Date: Wed, 17 Oct 2012 16:44:46 +0100
In-Reply-To: <1350398712.18058.120.camel@zakaz.uk.xensource.com>
References: 
	<1350398712.18058.120.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel , "Tim \(Xen.org\)" ,
	Jan Beulich ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH v2 00/10] 64 bit ARM ABI,
 map foreign gmfn API, ARM grant tables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-16 at 15:45 +0100, Ian Campbell wrote:
> On Mon, 2012-10-15 at 16:48 +0100, Keir Fraser wrote:
> > On 15/10/2012 16:20, "Ian Campbell"  wrote:
> > 
> > > This is v2 of "Sweep through arm-for-4.3 branch + a bit extra" retitled
> > > since most of the sweep through stuff has been swept through already and
> > > just the bit extra remains.
> > > 
> > > I've addressed the review comments and fixed the bisection issue. A
> > > bunch of this stuff is cross arch and/or touches common code.
> > 
> > Those bits are fine by me, now.
> > 
> > Acked-by: Keir Fraser 
> 
> Thanks, I'll give it a while for others to comment and plan to shovel it
> in tomorrow or Thursday unless there are objections.

Added Stefano's + your acks and pushed, thanks

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 15:53:57 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 15:53:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOVw6-00076f-BY; Wed, 17 Oct 2012 15:53:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOVw4-00076a-Pu
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 15:53:33 +0000
Received: from [85.158.137.99:14035] by server-8.bemta-3.messagelabs.com id
	03/46-10525-A74DE705; Wed, 17 Oct 2012 15:53:30 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1350489208!17232676!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgxNjgxMg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24004 invoked from network); 17 Oct 2012 15:53:29 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Oct 2012 15:53:29 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9HFrFCP017960
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Oct 2012 15:53:16 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9HFrDBV008082
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Oct 2012 15:53:14 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9HFrBxr005195; Wed, 17 Oct 2012 10:53:12 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 08:53:11 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id BFA064035B; Wed, 17 Oct 2012 11:41:09 -0400 (EDT)
Date: Wed, 17 Oct 2012 11:41:09 -0400
From: Konrad Rzeszutek Wilk 
To: Alexandre Bezroutchko 
Message-ID: <20121017154109.GB7590@phenom.dumpdata.com>
References: 
	<20121017121115.GI8912@reaktio.net> <507EB52D.1040209@gremwell.com>
	<507EB7A1.1080907@gremwell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <507EB7A1.1080907@gremwell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: nathanael@polymorpheus.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] pvusb with kernel 3.4 / 3.6
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 17, 2012 at 03:50:25PM +0200, Alexandre Bezroutchko wrote:
> On 10/17/2012 03:39 PM, Alexandre Bezroutchko wrote:
> > Thanks for the hint, found it, here it is:
> >
> > http://wiki.xen.org/wiki/Xen_Development_Projects#Upstreaming_Xen_PVUSB=
_drivers_to_mainline_Linux_kernel
> >
> > On 10/17/2012 02:11 PM, Pasi K=E4rkk=E4inen wrote:
> >> On Wed, Oct 17, 2012 at 01:21:53PM +0200, Alexandre Bezroutchko wrote:
> >>>    Hi Nathanael,
> >>>
> >>>    Is it possible to use your patch [1] on newer kernels? I've tried =
to use
> >>>    it but most devices are not usable and some cause kernel crash. De=
tailed
> >>>    description of an attempt on kernel 3.4 is at [2] and (somewhat le=
ss
> >>>    detailed) with 3.6 is at [3]. I'm motivated to make it work, any i=
deas
> >>>    what can be done to fix this issue? Please tell me if you need any
> >>>    additional info.
> >>>
> >>>    I've added xen-devel and Pasi K=E4rkk=E4inen into Cc, hope this is=
 ok.
> >>>
> >> I think Konrad has the pvusb drivers in his git tree..
> Konrad's repo seems to contain the same patch [1] as published by
> Nathanael. It does not work for me. I've put Konrad in Cc, hope he can
> comment...

So how does it not work?
> =

> [1]
> http://git.kernel.org/?p=3Dlinux/kernel/git/konrad/xen.git;a=3Dpatch;h=3D=
10b675fc21702ff5a9b94fc13e2b504ca09073fd
> =

> Regards,
> Alex
> =

> >>
> >>
> >> -- Pasi
> >>  =

> >>
> >>>    Regards,
> >>>    Alex
> >>>
> >>>    [1] [1]http://lists.xen.org/archives/html/xen-devel/2012-02/msg005=
71.html
> >>>    [2]
> >>>    [2]https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/3IAf7f8=
lz2UJ
> >>>    [3]
> >>>    [3]https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/rNmVAOX=
X4dYJ
> >>>
> >>> References
> >>>
> >>>    Visible links
> >>>    1. http://lists.xen.org/archives/html/xen-devel/2012-02/msg00571.h=
tml
> >>>    2. https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/3IAf7f8=
lz2UJ
> >>>    3. https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/rNmVAOX=
X4dYJ

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 15:53:57 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 15:53:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOVw6-00076f-BY; Wed, 17 Oct 2012 15:53:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOVw4-00076a-Pu
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 15:53:33 +0000
Received: from [85.158.137.99:14035] by server-8.bemta-3.messagelabs.com id
	03/46-10525-A74DE705; Wed, 17 Oct 2012 15:53:30 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1350489208!17232676!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgxNjgxMg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24004 invoked from network); 17 Oct 2012 15:53:29 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Oct 2012 15:53:29 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9HFrFCP017960
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Oct 2012 15:53:16 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9HFrDBV008082
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Oct 2012 15:53:14 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9HFrBxr005195; Wed, 17 Oct 2012 10:53:12 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 08:53:11 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id BFA064035B; Wed, 17 Oct 2012 11:41:09 -0400 (EDT)
Date: Wed, 17 Oct 2012 11:41:09 -0400
From: Konrad Rzeszutek Wilk 
To: Alexandre Bezroutchko 
Message-ID: <20121017154109.GB7590@phenom.dumpdata.com>
References: 
	<20121017121115.GI8912@reaktio.net> <507EB52D.1040209@gremwell.com>
	<507EB7A1.1080907@gremwell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <507EB7A1.1080907@gremwell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: nathanael@polymorpheus.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] pvusb with kernel 3.4 / 3.6
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 17, 2012 at 03:50:25PM +0200, Alexandre Bezroutchko wrote:
> On 10/17/2012 03:39 PM, Alexandre Bezroutchko wrote:
> > Thanks for the hint, found it, here it is:
> >
> > http://wiki.xen.org/wiki/Xen_Development_Projects#Upstreaming_Xen_PVUSB=
_drivers_to_mainline_Linux_kernel
> >
> > On 10/17/2012 02:11 PM, Pasi K=E4rkk=E4inen wrote:
> >> On Wed, Oct 17, 2012 at 01:21:53PM +0200, Alexandre Bezroutchko wrote:
> >>>    Hi Nathanael,
> >>>
> >>>    Is it possible to use your patch [1] on newer kernels? I've tried =
to use
> >>>    it but most devices are not usable and some cause kernel crash. De=
tailed
> >>>    description of an attempt on kernel 3.4 is at [2] and (somewhat le=
ss
> >>>    detailed) with 3.6 is at [3]. I'm motivated to make it work, any i=
deas
> >>>    what can be done to fix this issue? Please tell me if you need any
> >>>    additional info.
> >>>
> >>>    I've added xen-devel and Pasi K=E4rkk=E4inen into Cc, hope this is=
 ok.
> >>>
> >> I think Konrad has the pvusb drivers in his git tree..
> Konrad's repo seems to contain the same patch [1] as published by
> Nathanael. It does not work for me. I've put Konrad in Cc, hope he can
> comment...

So how does it not work?
> =

> [1]
> http://git.kernel.org/?p=3Dlinux/kernel/git/konrad/xen.git;a=3Dpatch;h=3D=
10b675fc21702ff5a9b94fc13e2b504ca09073fd
> =

> Regards,
> Alex
> =

> >>
> >>
> >> -- Pasi
> >>  =

> >>
> >>>    Regards,
> >>>    Alex
> >>>
> >>>    [1] [1]http://lists.xen.org/archives/html/xen-devel/2012-02/msg005=
71.html
> >>>    [2]
> >>>    [2]https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/3IAf7f8=
lz2UJ
> >>>    [3]
> >>>    [3]https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/rNmVAOX=
X4dYJ
> >>>
> >>> References
> >>>
> >>>    Visible links
> >>>    1. http://lists.xen.org/archives/html/xen-devel/2012-02/msg00571.h=
tml
> >>>    2. https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/3IAf7f8=
lz2UJ
> >>>    3. https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/rNmVAOX=
X4dYJ

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 15:59:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 15:59:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOW1E-0007HA-Dk; Wed, 17 Oct 2012 15:58:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOW1C-0007H5-UE
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 15:58:51 +0000
Received: from [85.158.139.83:33567] by server-7.bemta-5.messagelabs.com id
	35/22-23102-AB5DE705; Wed, 17 Oct 2012 15:58:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1350489529!34742146!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17188 invoked from network); 17 Oct 2012 15:58:49 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 15:58:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,601,1344211200"; d="scan'208";a="15231230"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 15:58:49 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 17 Oct 2012 16:58:49 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TOW1A-0007xD-SE; Wed, 17 Oct 2012 15:58:48 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TOW1A-0007ST-OS;
	Wed, 17 Oct 2012 16:58:48 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20606.54712.655309.739689@mariner.uk.xensource.com>
Date: Wed, 17 Oct 2012 16:58:48 +0100
To: Ian Campbell 
In-Reply-To: <65e301c71ca41af8cf0a.1350295790@cosworth.uk.xensource.com>
References: 
	<65e301c71ca41af8cf0a.1350295790@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "linux@eikelenboom.it" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 1 of 5] libxl: propagate user supplied
 values into event for_user field
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[PATCH 1 of 5] libxl: propagate user supplied values into event for_user field"):
> libxl: propagate user supplied values into event for_user field.
> 
> This was ommited in the majority of cases. Add as a parameter to
> libxl__event_new and the NEW_EVENT wrapper to help prevent it being
> forgotten in the future.

Oops.

Acked-by: Ian Jackson 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 15:59:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 15:59:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOW1E-0007HA-Dk; Wed, 17 Oct 2012 15:58:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOW1C-0007H5-UE
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 15:58:51 +0000
Received: from [85.158.139.83:33567] by server-7.bemta-5.messagelabs.com id
	35/22-23102-AB5DE705; Wed, 17 Oct 2012 15:58:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1350489529!34742146!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17188 invoked from network); 17 Oct 2012 15:58:49 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 15:58:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,601,1344211200"; d="scan'208";a="15231230"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 15:58:49 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 17 Oct 2012 16:58:49 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TOW1A-0007xD-SE; Wed, 17 Oct 2012 15:58:48 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TOW1A-0007ST-OS;
	Wed, 17 Oct 2012 16:58:48 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20606.54712.655309.739689@mariner.uk.xensource.com>
Date: Wed, 17 Oct 2012 16:58:48 +0100
To: Ian Campbell 
In-Reply-To: <65e301c71ca41af8cf0a.1350295790@cosworth.uk.xensource.com>
References: 
	<65e301c71ca41af8cf0a.1350295790@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "linux@eikelenboom.it" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 1 of 5] libxl: propagate user supplied
 values into event for_user field
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[PATCH 1 of 5] libxl: propagate user supplied values into event for_user field"):
> libxl: propagate user supplied values into event for_user field.
> 
> This was ommited in the majority of cases. Add as a parameter to
> libxl__event_new and the NEW_EVENT wrapper to help prevent it being
> forgotten in the future.

Oops.

Acked-by: Ian Jackson 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 16:03:34 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 16:03:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOW5Z-0007pL-4v; Wed, 17 Oct 2012 16:03:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOW5X-0007pE-RY
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 16:03:19 +0000
Received: from [193.109.254.147:6707] by server-2.bemta-14.messagelabs.com id
	C0/A1-19917-6C6DE705; Wed, 17 Oct 2012 16:03:18 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1350489796!13624002!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14735 invoked from network); 17 Oct 2012 16:03:18 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Oct 2012 16:03:18 -0000
Received: from tazenda.hos.anvin.org (c-67-188-81-177.hsd1.ca.comcast.net
	[67.188.81.177]) (authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id q9HG3CKS019598
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256
	verify=FAIL); Wed, 17 Oct 2012 09:03:12 -0700
Message-ID: <507ED6C0.4020503@zytor.com>
Date: Wed, 17 Oct 2012 09:03:12 -0700
From: "H. Peter Anvin" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120911 Thunderbird/15.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk 
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
In-Reply-To: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
Cc: linux-acpi@vger.kernel.org, x86@kernel.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] [RFC] ACPI S3 and Xen (suprisingly small\!).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/17/2012 06:49 AM, Konrad Rzeszutek Wilk wrote:
>
> Note: These are the other patches that went in 3.7-rc1:
> xen/bootup: allow {read|write}_cr8 pvops call [https://lkml.org/lkml/2012/10/10/339]
> xen/bootup: allow read_tscp call for Xen PV guests. [https://lkml.org/lkml/2012/10/10/340]
>

So WTF do we have a read_tscp PV call?  Again, if there isn't a user we 
should just axe it...

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 16:03:34 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 16:03:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOW5Z-0007pL-4v; Wed, 17 Oct 2012 16:03:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOW5X-0007pE-RY
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 16:03:19 +0000
Received: from [193.109.254.147:6707] by server-2.bemta-14.messagelabs.com id
	C0/A1-19917-6C6DE705; Wed, 17 Oct 2012 16:03:18 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1350489796!13624002!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14735 invoked from network); 17 Oct 2012 16:03:18 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Oct 2012 16:03:18 -0000
Received: from tazenda.hos.anvin.org (c-67-188-81-177.hsd1.ca.comcast.net
	[67.188.81.177]) (authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id q9HG3CKS019598
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256
	verify=FAIL); Wed, 17 Oct 2012 09:03:12 -0700
Message-ID: <507ED6C0.4020503@zytor.com>
Date: Wed, 17 Oct 2012 09:03:12 -0700
From: "H. Peter Anvin" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120911 Thunderbird/15.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk 
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
In-Reply-To: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
Cc: linux-acpi@vger.kernel.org, x86@kernel.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] [RFC] ACPI S3 and Xen (suprisingly small\!).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/17/2012 06:49 AM, Konrad Rzeszutek Wilk wrote:
>
> Note: These are the other patches that went in 3.7-rc1:
> xen/bootup: allow {read|write}_cr8 pvops call [https://lkml.org/lkml/2012/10/10/339]
> xen/bootup: allow read_tscp call for Xen PV guests. [https://lkml.org/lkml/2012/10/10/340]
>

So WTF do we have a read_tscp PV call?  Again, if there isn't a user we 
should just axe it...

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 16:03:35 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 16:03:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOW5b-0007pc-Gz; Wed, 17 Oct 2012 16:03:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOW5Z-0007pQ-TX
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 16:03:22 +0000
Received: from [85.158.139.211:44504] by server-12.bemta-5.messagelabs.com id
	3E/EC-26919-9C6DE705; Wed, 17 Oct 2012 16:03:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1350489800!22716988!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13990 invoked from network); 17 Oct 2012 16:03:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 16:03:20 -0000
X-IronPort-AV: E=Sophos;i="4.80,601,1344211200"; d="scan'208";a="15231360"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 16:03:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 17 Oct 2012 17:03:20 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TOW5X-00084U-UY; Wed, 17 Oct 2012 16:03:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TOW5X-0007T6-RB;
	Wed, 17 Oct 2012 17:03:19 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20606.54983.746418.437132@mariner.uk.xensource.com>
Date: Wed, 17 Oct 2012 17:03:19 +0100
To: Ian Campbell 
In-Reply-To: <2329dca4ef449979b140.1350295791@cosworth.uk.xensource.com>
References: 
	<2329dca4ef449979b140.1350295791@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "linux@eikelenboom.it" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 2 of 5] xl: Introduce xl shutdown --all
 support for xm compatibility
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[PATCH 2 of 5] xl: Introduce xl shutdown --all support for xm compatibility"):
> xl: Introduce xl shutdown --all support for xm compatibility
...> 
> Based on a patch by Sander Eikelenboom
...
>  int main_shutdown(int argc, char **argv)
...
> +        if (wait_for_it)
> +            deathws = calloc(nb_domain, sizeof(deathws));

This should read sizeof(*deathws).  It's a shame we don't have a macro
to avoid this broken pattern in xl.  In libxl we have GCNEW_ARRAY of
course.  (In fact in this particular case the two things are both
pointers so the sizeof() is the same and the bug is theoretical.)

Apart from that,

Acked-by: Ian Jackson 

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 16:03:35 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 16:03:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOW5b-0007pc-Gz; Wed, 17 Oct 2012 16:03:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOW5Z-0007pQ-TX
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 16:03:22 +0000
Received: from [85.158.139.211:44504] by server-12.bemta-5.messagelabs.com id
	3E/EC-26919-9C6DE705; Wed, 17 Oct 2012 16:03:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1350489800!22716988!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13990 invoked from network); 17 Oct 2012 16:03:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 16:03:20 -0000
X-IronPort-AV: E=Sophos;i="4.80,601,1344211200"; d="scan'208";a="15231360"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 16:03:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 17 Oct 2012 17:03:20 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TOW5X-00084U-UY; Wed, 17 Oct 2012 16:03:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TOW5X-0007T6-RB;
	Wed, 17 Oct 2012 17:03:19 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20606.54983.746418.437132@mariner.uk.xensource.com>
Date: Wed, 17 Oct 2012 17:03:19 +0100
To: Ian Campbell 
In-Reply-To: <2329dca4ef449979b140.1350295791@cosworth.uk.xensource.com>
References: 
	<2329dca4ef449979b140.1350295791@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "linux@eikelenboom.it" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 2 of 5] xl: Introduce xl shutdown --all
 support for xm compatibility
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[PATCH 2 of 5] xl: Introduce xl shutdown --all support for xm compatibility"):
> xl: Introduce xl shutdown --all support for xm compatibility
...> 
> Based on a patch by Sander Eikelenboom
...
>  int main_shutdown(int argc, char **argv)
...
> +        if (wait_for_it)
> +            deathws = calloc(nb_domain, sizeof(deathws));

This should read sizeof(*deathws).  It's a shame we don't have a macro
to avoid this broken pattern in xl.  In libxl we have GCNEW_ARRAY of
course.  (In fact in this particular case the two things are both
pointers so the sizeof() is the same and the bug is theoretical.)

Apart from that,

Acked-by: Ian Jackson 

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 16:04:56 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 16:04:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOW6w-0007yj-1C; Wed, 17 Oct 2012 16:04:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOW6v-0007yc-0r
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 16:04:45 +0000
Received: from [193.109.254.147:14848] by server-9.bemta-14.messagelabs.com id
	52/A7-09620-C17DE705; Wed, 17 Oct 2012 16:04:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1350489883!1656050!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25913 invoked from network); 17 Oct 2012 16:04:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 16:04:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,601,1344211200"; d="scan'208";a="15231466"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 16:04:43 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 17 Oct 2012 17:04:43 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TOW6t-00085C-7X; Wed, 17 Oct 2012 16:04:43 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TOW6t-0007TA-41;
	Wed, 17 Oct 2012 17:04:43 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20606.55067.23580.509457@mariner.uk.xensource.com>
Date: Wed, 17 Oct 2012 17:04:43 +0100
To: Ian Campbell 
In-Reply-To: <5a24315f39c035e5e5b7.1350295792@cosworth.uk.xensource.com>
References: 
	<5a24315f39c035e5e5b7.1350295792@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "linux@eikelenboom.it" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 3 of 5] xl: Add --wait and --all to xl reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[PATCH 3 of 5] xl: Add --wait and --all to xl reboot"):
> xl: Add --wait and --all to xl reboot.

Acked-by: Ian Jackson 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 16:04:56 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 16:04:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOW6w-0007yj-1C; Wed, 17 Oct 2012 16:04:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOW6v-0007yc-0r
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 16:04:45 +0000
Received: from [193.109.254.147:14848] by server-9.bemta-14.messagelabs.com id
	52/A7-09620-C17DE705; Wed, 17 Oct 2012 16:04:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1350489883!1656050!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25913 invoked from network); 17 Oct 2012 16:04:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 16:04:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,601,1344211200"; d="scan'208";a="15231466"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 16:04:43 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 17 Oct 2012 17:04:43 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TOW6t-00085C-7X; Wed, 17 Oct 2012 16:04:43 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TOW6t-0007TA-41;
	Wed, 17 Oct 2012 17:04:43 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20606.55067.23580.509457@mariner.uk.xensource.com>
Date: Wed, 17 Oct 2012 17:04:43 +0100
To: Ian Campbell 
In-Reply-To: <5a24315f39c035e5e5b7.1350295792@cosworth.uk.xensource.com>
References: 
	<5a24315f39c035e5e5b7.1350295792@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "linux@eikelenboom.it" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 3 of 5] xl: Add --wait and --all to xl reboot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[PATCH 3 of 5] xl: Add --wait and --all to xl reboot"):
> xl: Add --wait and --all to xl reboot.

Acked-by: Ian Jackson 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 16:05:59 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 16:05:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOW7x-00085B-Fg; Wed, 17 Oct 2012 16:05:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOW7v-00084n-BU
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 16:05:47 +0000
Received: from [85.158.138.51:43864] by server-1.bemta-3.messagelabs.com id
	DB/BD-31728-A57DE705; Wed, 17 Oct 2012 16:05:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1350489945!32961230!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19768 invoked from network); 17 Oct 2012 16:05:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 16:05:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,601,1344211200"; d="scan'208";a="15231533"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 16:05:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 17 Oct 2012 17:05:45 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TOW7s-00085Y-Tm; Wed, 17 Oct 2012 16:05:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TOW7s-0007TH-Pp;
	Wed, 17 Oct 2012 17:05:44 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20606.55128.686378.924416@mariner.uk.xensource.com>
Date: Wed, 17 Oct 2012 17:05:44 +0100
To: Ian Campbell 
In-Reply-To: 
References: 
	
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "linux@eikelenboom.it" ,
	Ian Jackson ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 4 of 5] xl: allow def_getopt to handle long
	options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[PATCH 4 of 5] xl: allow def_getopt to handle long options"):
> xl: allow def_getopt to handle long options

Acked-by: Ian Jackson 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 16:05:59 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 16:05:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOW7x-00085B-Fg; Wed, 17 Oct 2012 16:05:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOW7v-00084n-BU
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 16:05:47 +0000
Received: from [85.158.138.51:43864] by server-1.bemta-3.messagelabs.com id
	DB/BD-31728-A57DE705; Wed, 17 Oct 2012 16:05:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1350489945!32961230!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19768 invoked from network); 17 Oct 2012 16:05:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 16:05:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,601,1344211200"; d="scan'208";a="15231533"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 16:05:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 17 Oct 2012 17:05:45 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TOW7s-00085Y-Tm; Wed, 17 Oct 2012 16:05:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TOW7s-0007TH-Pp;
	Wed, 17 Oct 2012 17:05:44 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20606.55128.686378.924416@mariner.uk.xensource.com>
Date: Wed, 17 Oct 2012 17:05:44 +0100
To: Ian Campbell 
In-Reply-To: 
References: 
	
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "linux@eikelenboom.it" ,
	Ian Jackson ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 4 of 5] xl: allow def_getopt to handle long
	options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[PATCH 4 of 5] xl: allow def_getopt to handle long options"):
> xl: allow def_getopt to handle long options

Acked-by: Ian Jackson 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 16:10:44 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 16:10:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOWCT-0008Or-7w; Wed, 17 Oct 2012 16:10:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOWCR-0008Ok-Ny
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 16:10:28 +0000
Received: from [85.158.143.35:34278] by server-2.bemta-4.messagelabs.com id
	E6/5C-22268-278DE705; Wed, 17 Oct 2012 16:10:26 +0000
X-Env-Sender: abb@gremwell.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1350490220!15648654!1
X-Originating-IP: [209.85.212.179]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_MESSAGE,
	MIME_QP_LONG_LINE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12363 invoked from network); 17 Oct 2012 16:10:23 -0000
Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com)
	(209.85.212.179)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 16:10:23 -0000
Received: by mail-wi0-f179.google.com with SMTP id hq7so720268wib.14
	for ; Wed, 17 Oct 2012 09:09:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=references:in-reply-to:mime-version:content-transfer-encoding
	:content-type:message-id:cc:x-mailer:from:subject:date:to
	:x-gm-message-state;
	bh=AkS9goCul+rkKQtgbCVNfdvojEDp9cFYD0BkaYNu45g=;
	b=cZDx+1AOm2OtbTaz9m65tXTLnZSAnudHeBfzPta9pb2/ABSiUMC8kgm/G/IBVxI31y
	AxdbQGxEp2RAJ9HZxUBJ1Fd1CP9OA2Whpy0asJ2yvSPIWsczQ+1iJHoD3BwlffVyRqTb
	8f6AyoK2VsXzEyeVaWlcb8D4AgpAzkifL5lzMadt1+5Asa5IlG1QDmVXWkdu+jKcj0/w
	PD+nrO48B/zY0lcnw99TLh90MGcsBYX/gDgMc0/mvUN4aFz5J2vdrubdH67riXaBH2EN
	AuauKXJ4EJfDiJbAH7B2yQiBVAQr5wcQWoJ+dK3E6XF6Y7grQsVDiBEoen8vbkxvXAKf
	MxfA==
Received: by 10.216.210.214 with SMTP id u64mr10388902weo.177.1350490161110;
	Wed, 17 Oct 2012 09:09:21 -0700 (PDT)
Received: from [46.178.96.218] ([46.178.96.218])
	by mx.google.com with ESMTPS id a10sm28322817wiz.4.2012.10.17.09.09.03
	(version=SSLv3 cipher=OTHER); Wed, 17 Oct 2012 09:09:20 -0700 (PDT)
References: 
	<20121017121115.GI8912@reaktio.net>
	<507EB52D.1040209@gremwell.com> <507EB7A1.1080907@gremwell.com>
	<20121017154109.GB7590@phenom.dumpdata.com>
In-Reply-To: <20121017154109.GB7590@phenom.dumpdata.com>
Mime-Version: 1.0 (1.0)
Message-Id: 
X-Mailer: iPhone Mail (10A403)
From: Alexandre Bezroutchko 
Date: Wed, 17 Oct 2012 18:08:58 +0200
To: Konrad Rzeszutek Wilk 
X-Gm-Message-State: ALoCoQmJM07bpU7XuJfOKoD+9lV6TNQUikE+glM9bLjAqobD+gtWSbWJFG0pFwt1z5P1wKbCULGQ
Cc: "nathanael@polymorpheus.com" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] pvusb with kernel 3.4 / 3.6
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0760532822858062933=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============0760532822858062933==
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative;
	boundary=Apple-Mail-CCF7580F-1F9F-40DD-9168-1B9D06A8FE69


--Apple-Mail-CCF7580F-1F9F-40DD-9168-1B9D06A8FE69
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 17 Oct 2012, at 17:41, Konrad Rzeszutek Wilk  wro=
te:

> On Wed, Oct 17, 2012 at 03:50:25PM +0200, Alexandre Bezroutchko wrote:
>> On 10/17/2012 03:39 PM, Alexandre Bezroutchko wrote:
>>> Thanks for the hint, found it, here it is:
>>>=20
>>> http://wiki.xen.org/wiki/Xen_Development_Projects#Upstreaming_Xen_PVUSB_=
drivers_to_mainline_Linux_kernel
>>>=20
>>> On 10/17/2012 02:11 PM, Pasi K=C3=A4rkk=C3=A4inen wrote:
>>>> On Wed, Oct 17, 2012 at 01:21:53PM +0200, Alexandre Bezroutchko wrote:
>>>>>   Hi Nathanael,
>>>>>=20
>>>>>   Is it possible to use your patch [1] on newer kernels? I've tried to=
 use
>>>>>   it but most devices are not usable and some cause kernel crash. Deta=
iled
>>>>>   description of an attempt on kernel 3.4 is at [2] and (somewhat less=

>>>>>   detailed) with 3.6 is at [3]. I'm motivated to make it work, any ide=
as
>>>>>   what can be done to fix this issue? Please tell me if you need any
>>>>>   additional info.
>>>>>=20
>>>>>   I've added xen-devel and Pasi K=C3=A4rkk=C3=A4inen into Cc, hope thi=
s is ok.
>>>> I think Konrad has the pvusb drivers in his git tree..
>> Konrad's repo seems to contain the same patch [1] as published by
>> Nathanael. It does not work for me. I've put Konrad in Cc, hope he can
>> comment...
>=20
> So how does it not work?

Here is my original question, please tell me what additional info you need.

-----------
pvusb with kernel 3.4 / 3.6
Hi Nathanael,=20

Is it possible to use your patch [1] on newer kernels? I've tried to use it=20=

but most devices are not usable and some cause kernel crash. Detailed=20
description of an attempt on kernel 3.4 is at [2] and (somewhat less=20
detailed) with 3.6 is at [3]. I'm motivated to make it work, any ideas what=20=

can be done to fix this issue? Please tell me if you need any additional=20
info.=20

I've added xen-devel and Pasi K=C3=A4rkk=C3=A4inen into Cc, hope this is ok.=
=20

Regards,=20
Alex=20

[1] http://lists.xen.org/archives/html/xen-devel/2012-02/msg00571.html=20
[2] https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/3IAf7f8lz2UJ=20
[3] https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/rNmVAOXX4dYJ
------------

>>=20
>> [1]
>> http://git.kernel.org/?p=3Dlinux/kernel/git/konrad/xen.git;a=3Dpatch;h=3D=
10b675fc21702ff5a9b94fc13e2b504ca09073fd
>>=20
>> Regards,
>> Alex
>>=20
>>>>=20
>>>>=20
>>>> -- Pasi
>>>>=20
>>>>=20
>>>>>   Regards,
>>>>>   Alex
>>>>>=20
>>>>>   [1] [1]http://lists.xen.org/archives/html/xen-devel/2012-02/msg00571=
.html
>>>>>   [2]
>>>>>   [2]https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/3IAf7f8lz=
2UJ
>>>>>   [3]
>>>>>   [3]https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/rNmVAOXX4=
dYJ
>>>>>=20
>>>>> References
>>>>>=20
>>>>>   Visible links
>>>>>   1. http://lists.xen.org/archives/html/xen-devel/2012-02/msg00571.htm=
l
>>>>>   2. https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/3IAf7f8lz=
2UJ
>>>>>   3. https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/rNmVAOXX4=
dYJ

--Apple-Mail-CCF7580F-1F9F-40DD-9168-1B9D06A8FE69
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


On 17 Oct 2012, at 17:41, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:

On Wed, Oct 17, 2012 at 03:50:=
25PM +0200, Alexandre Bezroutchko wrote:
On 10/17/2012 03:39 PM, Alexandre Bezroutchko wrote:
Thanks for t=
he hint, found it, here it is:

http://wiki.xen.org/wiki/Xen_Development_Proj=
ects#Upstreaming_Xen_PVUSB_drivers_to_mainline_Linux_kernel
=

On 10/17/2012 02:11 PM, Pasi K=C3=A4rkk=C3=A4inen w=
rote:
On Wed, Oct 17, 2012 at 01=
:21:53PM +0200, Alexandre Bezroutchko wrote:
   Hi Nathanae=
l,

   Is it possible to u=
se your patch [1] on newer kernels? I've tried to use
 &=
nbsp; it but most devices are not usable and some cause kernel crash. D=
etailed
   description of an attempt on kernel=
 3.4 is at [2] and (somewhat less
   detailed)=
 with 3.6 is at [3]. I'm motivated to make it work, any ideas
=
   what can be done to fix this issue? Please tell me if you=
 need any
   additional info.

   I've added xen-devel and Pasi K=C3=A4r=
kk=C3=A4inen into Cc, hope this is ok.
<=
/blockquote>

I think Konrad has the=
 pvusb drivers in his git tree..
Konrad's repo seems to contain the sam=
e patch [1] as published by
Nathanael. It does not work for me. I've put Konrad in Cc, hope he ca=
n
comment...

So how does it not work?

Here is my original question, p=
lease tell me what additional info you need.

-----------
pvusb with kernel 3.4 /=
 3.6
Hi Nathanael, 

Is it possible to=
 use your patch [1] on newer kernels? I've tried to use it 
but most=
 devices are not usable and some cause kernel crash. Detailed 
descr=
iption of an attempt on kernel 3.4 is at [2] and (somewhat less 
det=
ailed) with 3.6 is at [3]. I'm motivated to make it work, any ideas what&nbs=
p;
can be done to fix this issue? Please tell me if you need any addition=
al 
info. 

I've added xen-devel and Pasi K=C3=A4rkk=C3=A4=
inen into Cc, hope this is ok. 

Regards, 
Alex 
=

[1] http://lists.xen.org/arch=
ives/html/xen-devel/2012-02/msg00571.html 
[2] https://groups.google.com/d/msg/qubes-devel/4AKu=
lABh2Jc/3IAf7f8lz2UJ 
[3] https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/rNmVAOXX4dYJ<=
/a>

=

--Apple-Mail-CCF7580F-1F9F-40DD-9168-1B9D06A8FE69--


--===============0760532822858062933==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0760532822858062933==--


From xen-devel-bounces@lists.xen.org Wed Oct 17 16:10:44 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 16:10:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOWCT-0008Or-7w; Wed, 17 Oct 2012 16:10:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOWCR-0008Ok-Ny
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 16:10:28 +0000
Received: from [85.158.143.35:34278] by server-2.bemta-4.messagelabs.com id
	E6/5C-22268-278DE705; Wed, 17 Oct 2012 16:10:26 +0000
X-Env-Sender: abb@gremwell.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1350490220!15648654!1
X-Originating-IP: [209.85.212.179]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_MESSAGE,
	MIME_QP_LONG_LINE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12363 invoked from network); 17 Oct 2012 16:10:23 -0000
Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com)
	(209.85.212.179)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 16:10:23 -0000
Received: by mail-wi0-f179.google.com with SMTP id hq7so720268wib.14
	for ; Wed, 17 Oct 2012 09:09:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=references:in-reply-to:mime-version:content-transfer-encoding
	:content-type:message-id:cc:x-mailer:from:subject:date:to
	:x-gm-message-state;
	bh=AkS9goCul+rkKQtgbCVNfdvojEDp9cFYD0BkaYNu45g=;
	b=cZDx+1AOm2OtbTaz9m65tXTLnZSAnudHeBfzPta9pb2/ABSiUMC8kgm/G/IBVxI31y
	AxdbQGxEp2RAJ9HZxUBJ1Fd1CP9OA2Whpy0asJ2yvSPIWsczQ+1iJHoD3BwlffVyRqTb
	8f6AyoK2VsXzEyeVaWlcb8D4AgpAzkifL5lzMadt1+5Asa5IlG1QDmVXWkdu+jKcj0/w
	PD+nrO48B/zY0lcnw99TLh90MGcsBYX/gDgMc0/mvUN4aFz5J2vdrubdH67riXaBH2EN
	AuauKXJ4EJfDiJbAH7B2yQiBVAQr5wcQWoJ+dK3E6XF6Y7grQsVDiBEoen8vbkxvXAKf
	MxfA==
Received: by 10.216.210.214 with SMTP id u64mr10388902weo.177.1350490161110;
	Wed, 17 Oct 2012 09:09:21 -0700 (PDT)
Received: from [46.178.96.218] ([46.178.96.218])
	by mx.google.com with ESMTPS id a10sm28322817wiz.4.2012.10.17.09.09.03
	(version=SSLv3 cipher=OTHER); Wed, 17 Oct 2012 09:09:20 -0700 (PDT)
References: 
	<20121017121115.GI8912@reaktio.net>
	<507EB52D.1040209@gremwell.com> <507EB7A1.1080907@gremwell.com>
	<20121017154109.GB7590@phenom.dumpdata.com>
In-Reply-To: <20121017154109.GB7590@phenom.dumpdata.com>
Mime-Version: 1.0 (1.0)
Message-Id: 
X-Mailer: iPhone Mail (10A403)
From: Alexandre Bezroutchko 
Date: Wed, 17 Oct 2012 18:08:58 +0200
To: Konrad Rzeszutek Wilk 
X-Gm-Message-State: ALoCoQmJM07bpU7XuJfOKoD+9lV6TNQUikE+glM9bLjAqobD+gtWSbWJFG0pFwt1z5P1wKbCULGQ
Cc: "nathanael@polymorpheus.com" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] pvusb with kernel 3.4 / 3.6
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0760532822858062933=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============0760532822858062933==
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative;
	boundary=Apple-Mail-CCF7580F-1F9F-40DD-9168-1B9D06A8FE69


--Apple-Mail-CCF7580F-1F9F-40DD-9168-1B9D06A8FE69
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 17 Oct 2012, at 17:41, Konrad Rzeszutek Wilk  wro=
te:

> On Wed, Oct 17, 2012 at 03:50:25PM +0200, Alexandre Bezroutchko wrote:
>> On 10/17/2012 03:39 PM, Alexandre Bezroutchko wrote:
>>> Thanks for the hint, found it, here it is:
>>>=20
>>> http://wiki.xen.org/wiki/Xen_Development_Projects#Upstreaming_Xen_PVUSB_=
drivers_to_mainline_Linux_kernel
>>>=20
>>> On 10/17/2012 02:11 PM, Pasi K=C3=A4rkk=C3=A4inen wrote:
>>>> On Wed, Oct 17, 2012 at 01:21:53PM +0200, Alexandre Bezroutchko wrote:
>>>>>   Hi Nathanael,
>>>>>=20
>>>>>   Is it possible to use your patch [1] on newer kernels? I've tried to=
 use
>>>>>   it but most devices are not usable and some cause kernel crash. Deta=
iled
>>>>>   description of an attempt on kernel 3.4 is at [2] and (somewhat less=

>>>>>   detailed) with 3.6 is at [3]. I'm motivated to make it work, any ide=
as
>>>>>   what can be done to fix this issue? Please tell me if you need any
>>>>>   additional info.
>>>>>=20
>>>>>   I've added xen-devel and Pasi K=C3=A4rkk=C3=A4inen into Cc, hope thi=
s is ok.
>>>> I think Konrad has the pvusb drivers in his git tree..
>> Konrad's repo seems to contain the same patch [1] as published by
>> Nathanael. It does not work for me. I've put Konrad in Cc, hope he can
>> comment...
>=20
> So how does it not work?

Here is my original question, please tell me what additional info you need.

-----------
pvusb with kernel 3.4 / 3.6
Hi Nathanael,=20

Is it possible to use your patch [1] on newer kernels? I've tried to use it=20=

but most devices are not usable and some cause kernel crash. Detailed=20
description of an attempt on kernel 3.4 is at [2] and (somewhat less=20
detailed) with 3.6 is at [3]. I'm motivated to make it work, any ideas what=20=

can be done to fix this issue? Please tell me if you need any additional=20
info.=20

I've added xen-devel and Pasi K=C3=A4rkk=C3=A4inen into Cc, hope this is ok.=
=20

Regards,=20
Alex=20

[1] http://lists.xen.org/archives/html/xen-devel/2012-02/msg00571.html=20
[2] https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/3IAf7f8lz2UJ=20
[3] https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/rNmVAOXX4dYJ
------------

>>=20
>> [1]
>> http://git.kernel.org/?p=3Dlinux/kernel/git/konrad/xen.git;a=3Dpatch;h=3D=
10b675fc21702ff5a9b94fc13e2b504ca09073fd
>>=20
>> Regards,
>> Alex
>>=20
>>>>=20
>>>>=20
>>>> -- Pasi
>>>>=20
>>>>=20
>>>>>   Regards,
>>>>>   Alex
>>>>>=20
>>>>>   [1] [1]http://lists.xen.org/archives/html/xen-devel/2012-02/msg00571=
.html
>>>>>   [2]
>>>>>   [2]https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/3IAf7f8lz=
2UJ
>>>>>   [3]
>>>>>   [3]https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/rNmVAOXX4=
dYJ
>>>>>=20
>>>>> References
>>>>>=20
>>>>>   Visible links
>>>>>   1. http://lists.xen.org/archives/html/xen-devel/2012-02/msg00571.htm=
l
>>>>>   2. https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/3IAf7f8lz=
2UJ
>>>>>   3. https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/rNmVAOXX4=
dYJ

--Apple-Mail-CCF7580F-1F9F-40DD-9168-1B9D06A8FE69
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


On 17 Oct 2012, at 17:41, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:

On Wed, Oct 17, 2012 at 03:50:=
25PM +0200, Alexandre Bezroutchko wrote:
On 10/17/2012 03:39 PM, Alexandre Bezroutchko wrote:
Thanks for t=
he hint, found it, here it is:

http://wiki.xen.org/wiki/Xen_Development_Proj=
ects#Upstreaming_Xen_PVUSB_drivers_to_mainline_Linux_kernel
=

On 10/17/2012 02:11 PM, Pasi K=C3=A4rkk=C3=A4inen w=
rote:
On Wed, Oct 17, 2012 at 01=
:21:53PM +0200, Alexandre Bezroutchko wrote:
   Hi Nathanae=
l,

   Is it possible to u=
se your patch [1] on newer kernels? I've tried to use
 &=
nbsp; it but most devices are not usable and some cause kernel crash. D=
etailed
   description of an attempt on kernel=
 3.4 is at [2] and (somewhat less
   detailed)=
 with 3.6 is at [3]. I'm motivated to make it work, any ideas
=
   what can be done to fix this issue? Please tell me if you=
 need any
   additional info.

   I've added xen-devel and Pasi K=C3=A4r=
kk=C3=A4inen into Cc, hope this is ok.
<=
/blockquote>

I think Konrad has the=
 pvusb drivers in his git tree..
Konrad's repo seems to contain the sam=
e patch [1] as published by
Nathanael. It does not work for me. I've put Konrad in Cc, hope he ca=
n
comment...

So how does it not work?

Here is my original question, p=
lease tell me what additional info you need.

-----------
pvusb with kernel 3.4 /=
 3.6
Hi Nathanael, 

Is it possible to=
 use your patch [1] on newer kernels? I've tried to use it 
but most=
 devices are not usable and some cause kernel crash. Detailed 
descr=
iption of an attempt on kernel 3.4 is at [2] and (somewhat less 
det=
ailed) with 3.6 is at [3]. I'm motivated to make it work, any ideas what&nbs=
p;
can be done to fix this issue? Please tell me if you need any addition=
al 
info. 

I've added xen-devel and Pasi K=C3=A4rkk=C3=A4=
inen into Cc, hope this is ok. 

Regards, 
Alex 
=

[1] http://lists.xen.org/arch=
ives/html/xen-devel/2012-02/msg00571.html 
[2] https://groups.google.com/d/msg/qubes-devel/4AKu=
lABh2Jc/3IAf7f8lz2UJ 
[3] https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/rNmVAOXX4dYJ<=
/a>

=

--Apple-Mail-CCF7580F-1F9F-40DD-9168-1B9D06A8FE69--


--===============0760532822858062933==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0760532822858062933==--


From xen-devel-bounces@lists.xen.org Wed Oct 17 16:13:50 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 16:13:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOWFV-00005i-0V; Wed, 17 Oct 2012 16:13:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOWFT-00005c-It
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 16:13:35 +0000
Received: from [85.158.143.35:46221] by server-1.bemta-4.messagelabs.com id
	3F/AD-19134-E29DE705; Wed, 17 Oct 2012 16:13:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1350490413!4761964!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25600 invoked from network); 17 Oct 2012 16:13:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 16:13:34 -0000
X-IronPort-AV: E=Sophos;i="4.80,601,1344211200"; d="scan'208";a="15231739"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 16:13:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 17 Oct 2012 17:13:33 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TOWFR-000884-I4; Wed, 17 Oct 2012 16:13:33 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TOWFR-0007Up-Ea;
	Wed, 17 Oct 2012 17:13:33 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20606.55597.190403.314007@mariner.uk.xensource.com>
Date: Wed, 17 Oct 2012 17:13:33 +0100
To: Ian Campbell 
In-Reply-To: <22688187afa84747de9b.1350295794@cosworth.uk.xensource.com>
References: 
	<22688187afa84747de9b.1350295794@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "linux@eikelenboom.it" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 5 of 5] xl: Introduce helper macro for
	option parsing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[PATCH 5 of 5] xl: Introduce helper macro for option parsing"):
> xl: Introduce helper macro for option parsing.

The idea is a reasonable one, but I have some quibbles.

> +#define FOREACH_OPT(_opt, _opts, _lopts, _help, _req)           \
> +    while (((_opt) = def_getopt(argc, argv, (_opts), (_lopts),  \
> +                                (_help), (_req))) != -1)        \
> +        switch (opt)

This macro name should have the word SWITCH in it too so you know it
has to take cases and that "break" doesn't do what you think.
FOREACH_SWITCH_OPT maybe.

> @@ -2304,8 +2309,10 @@ int main_memmax(int argc, char **argv)
>      char *mem;
>      int rc;
> 
> -    if ((opt = def_getopt(argc, argv, "", NULL, "mem-max", 2)) != -1)
> +    FOREACH_OPT(opt, "", NULL, "mem-max", 2) {
> +    case 0: case 2:
>          return opt;
> +    }

This error handling behaviour (?) is rather opaque.  I RTFM
getopt_long and AFAICT it returns 0 only for certain long options and
it doesn't seem to mention returning 2.

Perhaps this would all be clearer if FOREACH_OPT had a big comment
explaining how to use it.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 16:13:50 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 16:13:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOWFV-00005i-0V; Wed, 17 Oct 2012 16:13:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOWFT-00005c-It
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 16:13:35 +0000
Received: from [85.158.143.35:46221] by server-1.bemta-4.messagelabs.com id
	3F/AD-19134-E29DE705; Wed, 17 Oct 2012 16:13:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1350490413!4761964!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25600 invoked from network); 17 Oct 2012 16:13:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 16:13:34 -0000
X-IronPort-AV: E=Sophos;i="4.80,601,1344211200"; d="scan'208";a="15231739"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 16:13:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 17 Oct 2012 17:13:33 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TOWFR-000884-I4; Wed, 17 Oct 2012 16:13:33 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TOWFR-0007Up-Ea;
	Wed, 17 Oct 2012 17:13:33 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20606.55597.190403.314007@mariner.uk.xensource.com>
Date: Wed, 17 Oct 2012 17:13:33 +0100
To: Ian Campbell 
In-Reply-To: <22688187afa84747de9b.1350295794@cosworth.uk.xensource.com>
References: 
	<22688187afa84747de9b.1350295794@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "linux@eikelenboom.it" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 5 of 5] xl: Introduce helper macro for
	option parsing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[PATCH 5 of 5] xl: Introduce helper macro for option parsing"):
> xl: Introduce helper macro for option parsing.

The idea is a reasonable one, but I have some quibbles.

> +#define FOREACH_OPT(_opt, _opts, _lopts, _help, _req)           \
> +    while (((_opt) = def_getopt(argc, argv, (_opts), (_lopts),  \
> +                                (_help), (_req))) != -1)        \
> +        switch (opt)

This macro name should have the word SWITCH in it too so you know it
has to take cases and that "break" doesn't do what you think.
FOREACH_SWITCH_OPT maybe.

> @@ -2304,8 +2309,10 @@ int main_memmax(int argc, char **argv)
>      char *mem;
>      int rc;
> 
> -    if ((opt = def_getopt(argc, argv, "", NULL, "mem-max", 2)) != -1)
> +    FOREACH_OPT(opt, "", NULL, "mem-max", 2) {
> +    case 0: case 2:
>          return opt;
> +    }

This error handling behaviour (?) is rather opaque.  I RTFM
getopt_long and AFAICT it returns 0 only for certain long options and
it doesn't seem to mention returning 2.

Perhaps this would all be clearer if FOREACH_OPT had a big comment
explaining how to use it.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 16:16:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 16:16:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOWHh-0000Dj-HX; Wed, 17 Oct 2012 16:15:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOWHf-0000DZ-Ni; Wed, 17 Oct 2012 16:15:51 +0000
Received: from [85.158.143.99:18570] by server-2.bemta-4.messagelabs.com id
	6E/A1-22268-6B9DE705; Wed, 17 Oct 2012 16:15:50 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1350490549!34171726!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19702 invoked from network); 17 Oct 2012 16:15:50 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 16:15:50 -0000
Received: by mail-ee0-f43.google.com with SMTP id c13so4407536eek.30
	for ; Wed, 17 Oct 2012 09:15:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type;
	bh=eUfywBZKUMdL52BTJQgirwifvfTvXFtBrBicuXUYDVY=;
	b=HqiBtTm1HMtNWw2BGKn8Dxq0Z8Aq7RZfUE/sVuG2tqhkSrCyrf9lv6J/xay43T98xz
	XjWwEn8MbIGyxRsqrrGqedsA0s36L8sP0jbvHMTf8Or2QRBv37yXiFV1Uq+PfE2ii6mJ
	ig2ZPK9LFKMrIp7GwpF9CYtlmXZKIDRY4jH+/4M38Vk2uOILF0V7z+RIX/BtKPuA7a+X
	FlkUQIRyQSIc06+ySu1qskK7fq2Pl4v+BhtIj40bBNt9nSY/F6iQ1jGbRRs3+RBgBb2F
	MNsFUMe80Y86QyiyTL4Fxy2Lqb9qADw+S5ITq4jydeUntYn5c4JTbuLBpTgCG9w2Bnxl
	7HeQ==
Received: by 10.14.213.201 with SMTP id a49mr27977656eep.4.1350490549491;
	Wed, 17 Oct 2012 09:15:49 -0700 (PDT)
Received: from [192.168.1.3] (host86-160-224-184.range86-160.btcentralplus.com.
	[86.160.224.184])
	by mx.google.com with ESMTPS id t1sm35654377eeo.3.2012.10.17.09.15.46
	(version=SSLv3 cipher=OTHER); Wed, 17 Oct 2012 09:15:47 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Wed, 17 Oct 2012 17:15:40 +0100
From: Keir Fraser 
To: Mauro ,
	Jan Beulich 
Message-ID: 
Thread-Topic: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
Thread-Index: Ac2sgqZWPdIKOuVrnkCp0s/sGWuYMA==
In-Reply-To: 
Mime-version: 1.0
Content-type: multipart/mixed;
	boundary="B_3433338947_42397714"
Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com,
	Dan Magenheimer ,
	Olivier Hanesse ,
	Xen Users ,
	Mark Adams 
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3433338947_42397714
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

On 15/10/2012 15:25, "Mauro"  wrote:

> On 15 October 2012 14:49, Jan Beulich  wrote:
>>>>> On 15.10.12 at 13:24, Mauro  wrote:
>>> I have the problem on this hardware type:
>>> 
>>> Hp Proliant DL580 G5 with four Intel(R) Xeon(R) CPU E7330  @ 2.40GHz.
>>> It seem that
>>> GRUB_CMDLINE_XEN="clocksource=pit cpuidle=0"
>>> put in in /etc/default/grup (I use linux debian)
>>> solves the problem for me.
>> 
>> Did you check whether either or both options on their own also
>> make the problem go away?
> 
> Only clocksource=pit does not solve the problem, I've not tried with
> only cpuidle=0, I will try soon.

The problem here is that the platform timer has *not* wrapped. In fact it is
almost certainly correct, and it is the calculation of current-system-time
extrapolated from local CPU's TSC that has gone haywire. The
overflow-handling logic in plt_overflow() then propagates that incorrectness
into plt_stamp64 (up to a maximum of 10 times wrapping the platform timer's
counter). This means that platform time is incorrect (skips forward) and
soon after will infect the local time estimation for all CPUs.

I've attached a patch which will (a) stop plt_overflow() from misguidedly
trying to fix up apparent platform timer overflow; and (b) will print
possibly-useful diagnostics when apparent 'timer overflow' occurs. Such
lines will be prefixed "XXX plt_overflow:" in the hypervisor log. Patch is
against xen-unstable but I'm sure it must backport to older trees quite
trivially.

 -- Keir


--B_3433338947_42397714
Content-type: application/octet-stream; name="00-tsc-debug"
Content-disposition: attachment;
	filename="00-tsc-debug"
Content-transfer-encoding: base64


ZGlmZiAtciBjMWM1NDljNGZlOWUgeGVuL2FyY2gveDg2L3RpbWUuYwotLS0gYS94ZW4vYXJj
aC94ODYvdGltZS5jCU1vbiBPY3QgMTUgMTY6NTE6NDQgMjAxMiArMDEwMAorKysgYi94ZW4v
YXJjaC94ODYvdGltZS5jCVdlZCBPY3QgMTcgMTc6MTM6MjIgMjAxMiArMDEwMApAQCAtNTIz
LDExICs1MjMsMTIgQEAgc3RhdGljIHNfdGltZV90IF9fcmVhZF9wbGF0Zm9ybV9zdGltZSh1
Ngogc3RhdGljIHZvaWQgcGx0X292ZXJmbG93KHZvaWQgKnVudXNlZCkKIHsKICAgICBpbnQg
aTsKLSAgICB1NjQgY291bnQ7CisgICAgdTY0IGNvdW50LCBvbGRfc3RhbXAsIHRzYzsKICAg
ICBzX3RpbWVfdCBub3csIHBsdF9ub3csIHBsdF93cmFwOwogCiAgICAgc3Bpbl9sb2NrX2ly
cSgmcGxhdGZvcm1fdGltZXJfbG9jayk7CiAKKyAgICBvbGRfc3RhbXAgPSBwbHRfc3RhbXA7
CiAgICAgY291bnQgPSBwbHRfc3JjLnJlYWRfY291bnRlcigpOwogICAgIHBsdF9zdGFtcDY0
ICs9IChjb3VudCAtIHBsdF9zdGFtcCkgJiBwbHRfbWFzazsKICAgICBwbHRfc3RhbXAgPSBj
b3VudDsKQEAgLTU0MCw2ICs1NDEsMTQgQEAgc3RhdGljIHZvaWQgcGx0X292ZXJmbG93KHZv
aWQgKnVudXNlZCkKICAgICAgICAgcGx0X3dyYXAgPSBfX3JlYWRfcGxhdGZvcm1fc3RpbWUo
cGx0X3N0YW1wNjQgKyBwbHRfbWFzayArIDEpOwogICAgICAgICBpZiAoIEFCUyhwbHRfd3Jh
cCAtIG5vdykgPiBBQlMocGx0X25vdyAtIG5vdykgKQogICAgICAgICAgICAgYnJlYWs7Cisg
ICAgICAgIHJkdHNjbGwodHNjKTsKKyAgICAgICAgcHJpbnRrKCJYWFggcGx0X292ZXJmbG93
OiBwbHRfbm93PSUiUFJJeDY0IiBwbHRfd3JhcD0lIlBSSXg2NAorICAgICAgICAgICAgICAg
IiBub3c9JSJQUkl4NjQiIG9sZF9zdGFtcD0lIlBSSXg2NCIgbmV3X3N0YW1wPSUiUFJJeDY0
CisgICAgICAgICAgICAgICAiIHBsdF9zdGFtcDY0PSUiUFJJeDY0IiBwbHRfbWFzaz0lIlBS
SXg2NAorICAgICAgICAgICAgICAgIiB0c2M9JSJQUkl4NjQiIHRzY19zdGFtcD0lIlBSSXg2
NCJcbiIsCisgICAgICAgICAgICAgICBwbHRfbm93LCBwbHRfd3JhcCwgbm93LCBvbGRfc3Rh
bXAsIHBsdF9zdGFtcCwgcGx0X3N0YW1wNjQsCisgICAgICAgICAgICAgICBwbHRfbWFzaywg
dHNjLCB0aGlzX2NwdShjcHVfdGltZSkubG9jYWxfdHNjX3N0YW1wKTsKKyAgICAgICAgYnJl
YWs7CiAgICAgICAgIHBsdF9zdGFtcDY0ICs9IHBsdF9tYXNrICsgMTsKICAgICB9CiAgICAg
aWYgKCBpICE9IDAgKQo=
--B_3433338947_42397714
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--B_3433338947_42397714--




From xen-devel-bounces@lists.xen.org Wed Oct 17 16:16:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 16:16:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOWHh-0000Dj-HX; Wed, 17 Oct 2012 16:15:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOWHf-0000DZ-Ni; Wed, 17 Oct 2012 16:15:51 +0000
Received: from [85.158.143.99:18570] by server-2.bemta-4.messagelabs.com id
	6E/A1-22268-6B9DE705; Wed, 17 Oct 2012 16:15:50 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1350490549!34171726!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19702 invoked from network); 17 Oct 2012 16:15:50 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 16:15:50 -0000
Received: by mail-ee0-f43.google.com with SMTP id c13so4407536eek.30
	for ; Wed, 17 Oct 2012 09:15:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type;
	bh=eUfywBZKUMdL52BTJQgirwifvfTvXFtBrBicuXUYDVY=;
	b=HqiBtTm1HMtNWw2BGKn8Dxq0Z8Aq7RZfUE/sVuG2tqhkSrCyrf9lv6J/xay43T98xz
	XjWwEn8MbIGyxRsqrrGqedsA0s36L8sP0jbvHMTf8Or2QRBv37yXiFV1Uq+PfE2ii6mJ
	ig2ZPK9LFKMrIp7GwpF9CYtlmXZKIDRY4jH+/4M38Vk2uOILF0V7z+RIX/BtKPuA7a+X
	FlkUQIRyQSIc06+ySu1qskK7fq2Pl4v+BhtIj40bBNt9nSY/F6iQ1jGbRRs3+RBgBb2F
	MNsFUMe80Y86QyiyTL4Fxy2Lqb9qADw+S5ITq4jydeUntYn5c4JTbuLBpTgCG9w2Bnxl
	7HeQ==
Received: by 10.14.213.201 with SMTP id a49mr27977656eep.4.1350490549491;
	Wed, 17 Oct 2012 09:15:49 -0700 (PDT)
Received: from [192.168.1.3] (host86-160-224-184.range86-160.btcentralplus.com.
	[86.160.224.184])
	by mx.google.com with ESMTPS id t1sm35654377eeo.3.2012.10.17.09.15.46
	(version=SSLv3 cipher=OTHER); Wed, 17 Oct 2012 09:15:47 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Wed, 17 Oct 2012 17:15:40 +0100
From: Keir Fraser 
To: Mauro ,
	Jan Beulich 
Message-ID: 
Thread-Topic: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
Thread-Index: Ac2sgqZWPdIKOuVrnkCp0s/sGWuYMA==
In-Reply-To: 
Mime-version: 1.0
Content-type: multipart/mixed;
	boundary="B_3433338947_42397714"
Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com,
	Dan Magenheimer ,
	Olivier Hanesse ,
	Xen Users ,
	Mark Adams 
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3433338947_42397714
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

On 15/10/2012 15:25, "Mauro"  wrote:

> On 15 October 2012 14:49, Jan Beulich  wrote:
>>>>> On 15.10.12 at 13:24, Mauro  wrote:
>>> I have the problem on this hardware type:
>>> 
>>> Hp Proliant DL580 G5 with four Intel(R) Xeon(R) CPU E7330  @ 2.40GHz.
>>> It seem that
>>> GRUB_CMDLINE_XEN="clocksource=pit cpuidle=0"
>>> put in in /etc/default/grup (I use linux debian)
>>> solves the problem for me.
>> 
>> Did you check whether either or both options on their own also
>> make the problem go away?
> 
> Only clocksource=pit does not solve the problem, I've not tried with
> only cpuidle=0, I will try soon.

The problem here is that the platform timer has *not* wrapped. In fact it is
almost certainly correct, and it is the calculation of current-system-time
extrapolated from local CPU's TSC that has gone haywire. The
overflow-handling logic in plt_overflow() then propagates that incorrectness
into plt_stamp64 (up to a maximum of 10 times wrapping the platform timer's
counter). This means that platform time is incorrect (skips forward) and
soon after will infect the local time estimation for all CPUs.

I've attached a patch which will (a) stop plt_overflow() from misguidedly
trying to fix up apparent platform timer overflow; and (b) will print
possibly-useful diagnostics when apparent 'timer overflow' occurs. Such
lines will be prefixed "XXX plt_overflow:" in the hypervisor log. Patch is
against xen-unstable but I'm sure it must backport to older trees quite
trivially.

 -- Keir


--B_3433338947_42397714
Content-type: application/octet-stream; name="00-tsc-debug"
Content-disposition: attachment;
	filename="00-tsc-debug"
Content-transfer-encoding: base64


ZGlmZiAtciBjMWM1NDljNGZlOWUgeGVuL2FyY2gveDg2L3RpbWUuYwotLS0gYS94ZW4vYXJj
aC94ODYvdGltZS5jCU1vbiBPY3QgMTUgMTY6NTE6NDQgMjAxMiArMDEwMAorKysgYi94ZW4v
YXJjaC94ODYvdGltZS5jCVdlZCBPY3QgMTcgMTc6MTM6MjIgMjAxMiArMDEwMApAQCAtNTIz
LDExICs1MjMsMTIgQEAgc3RhdGljIHNfdGltZV90IF9fcmVhZF9wbGF0Zm9ybV9zdGltZSh1
Ngogc3RhdGljIHZvaWQgcGx0X292ZXJmbG93KHZvaWQgKnVudXNlZCkKIHsKICAgICBpbnQg
aTsKLSAgICB1NjQgY291bnQ7CisgICAgdTY0IGNvdW50LCBvbGRfc3RhbXAsIHRzYzsKICAg
ICBzX3RpbWVfdCBub3csIHBsdF9ub3csIHBsdF93cmFwOwogCiAgICAgc3Bpbl9sb2NrX2ly
cSgmcGxhdGZvcm1fdGltZXJfbG9jayk7CiAKKyAgICBvbGRfc3RhbXAgPSBwbHRfc3RhbXA7
CiAgICAgY291bnQgPSBwbHRfc3JjLnJlYWRfY291bnRlcigpOwogICAgIHBsdF9zdGFtcDY0
ICs9IChjb3VudCAtIHBsdF9zdGFtcCkgJiBwbHRfbWFzazsKICAgICBwbHRfc3RhbXAgPSBj
b3VudDsKQEAgLTU0MCw2ICs1NDEsMTQgQEAgc3RhdGljIHZvaWQgcGx0X292ZXJmbG93KHZv
aWQgKnVudXNlZCkKICAgICAgICAgcGx0X3dyYXAgPSBfX3JlYWRfcGxhdGZvcm1fc3RpbWUo
cGx0X3N0YW1wNjQgKyBwbHRfbWFzayArIDEpOwogICAgICAgICBpZiAoIEFCUyhwbHRfd3Jh
cCAtIG5vdykgPiBBQlMocGx0X25vdyAtIG5vdykgKQogICAgICAgICAgICAgYnJlYWs7Cisg
ICAgICAgIHJkdHNjbGwodHNjKTsKKyAgICAgICAgcHJpbnRrKCJYWFggcGx0X292ZXJmbG93
OiBwbHRfbm93PSUiUFJJeDY0IiBwbHRfd3JhcD0lIlBSSXg2NAorICAgICAgICAgICAgICAg
IiBub3c9JSJQUkl4NjQiIG9sZF9zdGFtcD0lIlBSSXg2NCIgbmV3X3N0YW1wPSUiUFJJeDY0
CisgICAgICAgICAgICAgICAiIHBsdF9zdGFtcDY0PSUiUFJJeDY0IiBwbHRfbWFzaz0lIlBS
SXg2NAorICAgICAgICAgICAgICAgIiB0c2M9JSJQUkl4NjQiIHRzY19zdGFtcD0lIlBSSXg2
NCJcbiIsCisgICAgICAgICAgICAgICBwbHRfbm93LCBwbHRfd3JhcCwgbm93LCBvbGRfc3Rh
bXAsIHBsdF9zdGFtcCwgcGx0X3N0YW1wNjQsCisgICAgICAgICAgICAgICBwbHRfbWFzaywg
dHNjLCB0aGlzX2NwdShjcHVfdGltZSkubG9jYWxfdHNjX3N0YW1wKTsKKyAgICAgICAgYnJl
YWs7CiAgICAgICAgIHBsdF9zdGFtcDY0ICs9IHBsdF9tYXNrICsgMTsKICAgICB9CiAgICAg
aWYgKCBpICE9IDAgKQo=
--B_3433338947_42397714
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--B_3433338947_42397714--




From xen-devel-bounces@lists.xen.org Wed Oct 17 16:23:00 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 16:23:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOWON-0000dp-5x; Wed, 17 Oct 2012 16:22:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOWOK-0000df-W0
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 16:22:45 +0000
Received: from [85.158.143.99:5013] by server-1.bemta-4.messagelabs.com id
	6C/26-19134-45BDE705; Wed, 17 Oct 2012 16:22:44 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1350490962!33896588!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgxNjgxMg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32237 invoked from network); 17 Oct 2012 16:22:43 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Oct 2012 16:22:43 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9HGMc23028595
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Oct 2012 16:22:39 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9HGMcwH017043
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Oct 2012 16:22:38 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9HGMbdD028746; Wed, 17 Oct 2012 11:22:37 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 09:22:37 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 324084035B; Wed, 17 Oct 2012 12:10:36 -0400 (EDT)
Date: Wed, 17 Oct 2012 12:10:36 -0400
From: Konrad Rzeszutek Wilk 
To: "H. Peter Anvin" 
Message-ID: <20121017161036.GA10691@phenom.dumpdata.com>
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	<507ED6C0.4020503@zytor.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <507ED6C0.4020503@zytor.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: linux-acpi@vger.kernel.org, x86@kernel.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, lenb@kernel.org
Subject: [Xen-devel] Is: axe read_tscp pvops call. Was: Re: [RFC] ACPI S3
 and Xen (suprisingly small\!).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 17, 2012 at 09:03:12AM -0700, H. Peter Anvin wrote:
> On 10/17/2012 06:49 AM, Konrad Rzeszutek Wilk wrote:
> >
> >Note: These are the other patches that went in 3.7-rc1:
> >xen/bootup: allow {read|write}_cr8 pvops call [https://lkml.org/lkml/2012/10/10/339]
> >xen/bootup: allow read_tscp call for Xen PV guests. [https://lkml.org/lkml/2012/10/10/340]
> >
> 
> So WTF do we have a read_tscp PV call?  Again, if there isn't a user
> we should just axe it...

Let me spin off a patch to see if that can be done.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 16:23:00 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 16:23:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOWON-0000dp-5x; Wed, 17 Oct 2012 16:22:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOWOK-0000df-W0
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 16:22:45 +0000
Received: from [85.158.143.99:5013] by server-1.bemta-4.messagelabs.com id
	6C/26-19134-45BDE705; Wed, 17 Oct 2012 16:22:44 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1350490962!33896588!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgxNjgxMg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32237 invoked from network); 17 Oct 2012 16:22:43 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Oct 2012 16:22:43 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9HGMc23028595
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Oct 2012 16:22:39 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9HGMcwH017043
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Oct 2012 16:22:38 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9HGMbdD028746; Wed, 17 Oct 2012 11:22:37 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 09:22:37 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 324084035B; Wed, 17 Oct 2012 12:10:36 -0400 (EDT)
Date: Wed, 17 Oct 2012 12:10:36 -0400
From: Konrad Rzeszutek Wilk 
To: "H. Peter Anvin" 
Message-ID: <20121017161036.GA10691@phenom.dumpdata.com>
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	<507ED6C0.4020503@zytor.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <507ED6C0.4020503@zytor.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: linux-acpi@vger.kernel.org, x86@kernel.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, lenb@kernel.org
Subject: [Xen-devel] Is: axe read_tscp pvops call. Was: Re: [RFC] ACPI S3
 and Xen (suprisingly small\!).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 17, 2012 at 09:03:12AM -0700, H. Peter Anvin wrote:
> On 10/17/2012 06:49 AM, Konrad Rzeszutek Wilk wrote:
> >
> >Note: These are the other patches that went in 3.7-rc1:
> >xen/bootup: allow {read|write}_cr8 pvops call [https://lkml.org/lkml/2012/10/10/339]
> >xen/bootup: allow read_tscp call for Xen PV guests. [https://lkml.org/lkml/2012/10/10/340]
> >
> 
> So WTF do we have a read_tscp PV call?  Again, if there isn't a user
> we should just axe it...

Let me spin off a patch to see if that can be done.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 16:27:50 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 16:27:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOWT3-0000pa-UU; Wed, 17 Oct 2012 16:27:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOWT2-0000pP-Fy
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 16:27:36 +0000
Received: from [85.158.143.35:31299] by server-1.bemta-4.messagelabs.com id
	7D/7A-19134-77CDE705; Wed, 17 Oct 2012 16:27:35 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1350491254!4763853!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11191 invoked from network); 17 Oct 2012 16:27:35 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-2.tower-21.messagelabs.com with SMTP;
	17 Oct 2012 16:27:35 -0000
Received: from p5b2e42c0.dip.t-dialin.net ([91.46.66.192] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from )
	id 1TOWSy-0004fs-7w; Wed, 17 Oct 2012 16:27:32 +0000
Message-ID: <507EDC71.4040400@canonical.com>
Date: Wed, 17 Oct 2012 18:27:29 +0200
From: Stefan Bader 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Andrew Cooper 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
	<1350482118.2460.74.camel@zakaz.uk.xensource.com>
	<507ECD06.2050407@canonical.com> <507ED038.8000806@citrix.com>
In-Reply-To: <507ED038.8000806@citrix.com>
X-Enigmail-Version: 1.4.5
Cc: "xen-devel@lists.xen.org" ,
	Ian Campbell ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============2837620664345663613=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============2837620664345663613==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig2567AA1A474DF249DA5F091A"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig2567AA1A474DF249DA5F091A
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 17.10.2012 17:35, Andrew Cooper wrote:

>> (XEN) Event channel information for domain 1:
>> (XEN) Polling vCPUs: {1,4,6}
>> (XEN) port [p/m]
>> (XEN) 4 [1/1]: s=3D6 n=3D0 x=3D0
>> (XEN) 10 [0/1]: s=3D6 n=3D1 x=3D0
>> (XEN) 28 [0/1]: s=3D6 n=3D4 x=3D0
>> (XEN) 40 [0/1]: s=3D6 n=3D6 x=3D0
>>
> s =3D state.  0 =3D free, 1 =3D reserved, 2 =3D unbound, 3 =3D inter-do=
main, 4 =3D
> pirq, 5 =3D virq, 6 =3D ipi
> n =3D target vcpu id to notify
> x =3D boolean indicating whether xen is a consumer of the event channel=
 or
> not.
>=20
> d =3D target domain (when appropriate)  In this case, p is the target p=
ort.
>=20

Thanks (at least something learned today :)) One thing I noticed here, in=
 the
event channel info above, pending is 0 for channel 10, 28 and 40 (and set=
 for 4
which is the spinlock ipi for cpu 0). But in the VCPU info below (another=

unknown: has=3DT and F) it says upcall_pend for all of them. Unfortunatel=
y that
might just mean that things change...

>> (XEN) VCPU0: CPU3 [has=3DT] flags=3D0 poll=3D0 upcall_pend =3D 01, upc=
all_mask
> =3D 01
>> dirty_cpus=3D{3} cpu_affinity=3D{0-127}
>> (XEN) No periodic timer
>> (XEN) VCPU1: CPU7 [has=3DF] flags=3D1 poll=3D10 upcall_pend =3D 01,
> upcall_mask =3D 01
>> dirty_cpus=3D{} cpu_affinity=3D{0-127}
>> (XEN) No periodic timer

>> (XEN) VCPU4: CPU6 [has=3DF] flags=3D1 poll=3D28 upcall_pend =3D 01,
> upcall_mask =3D 01
>> dirty_cpus=3D{} cpu_affinity=3D{0-127}
>> (XEN) No periodic timer
>> (XEN) VCPU6: CPU0 [has=3DF] flags=3D1 poll=3D40 upcall_pend =3D 01,
> upcall_mask =3D 01
>> dirty_cpus=3D{} cpu_affinity=3D{0-127}
>> (XEN) No periodic timer
>=20
> So in this case, vcpu 1 is in a poll, on port 10, which is an IPI event=

> channel for itself.
>=20
> Same for vcpu 4, except it is on port 28, and for vcpu 6 on port 60.
>=20

>=20
> I wonder if there is possibly a race condition between notifying that a=

> lock has been unlocked, and another vcpu trying to poll after deciding
> that the lock is locked.

There has to be something somehwere, I just cannot spot it. The unlocking=
 cpu
will do a wmb() before setting the lock to 0, then a mb() and then check =
for
spinners. When failing the quick pack a locker will first set the lockspi=
nner
entry, then do a wmb() and increment the spinners count. After that it cl=
ears
the event pending and then checks lock again before actually going into p=
oll.

>=20
> The other option is that there is a bug in working out which event
> channel to notify when a lock is unlocked.

I had thought I saw one thing that I tried to fix with my patch. Another =
train
of thought would have been any other cpu grabbing the lock always as soon=
 as it
gets released and so preventing any cpu in poll from success. But that wo=
uld
then show the lock as locked...

>=20
> ~Andrew
>=20
>>
>>
>> Backtraces would be somewhat inconsistent (as always). Note, I should
> mention
>> that I still had a kernel with my patch applied on that guest. That
> changes
>> things a bit (actually it takes a bit longer to hang but again that
> might be
>> just a matter of timing). The strange lock state of 2 spinners on an
> unlocked
>> lock remains the same with or without it.
>>
>> One question about the patch actually, would anybody think that there
> could be a
>> case where the unlocking cpu has itself on the spinners list? I did
> not think so
>> but that might be wrong.
>>>
>>> The IRQ handler for the spinlock evtchn in Linux is:
>>> static irqreturn_t dummy_handler(int irq, void *dev_id)
>>> {
>>> BUG();
>>> return IRQ_HANDLED;
>>> }
>>>
>>> and right after we register it:
>>> disable_irq(irq); /* make sure it's never delivered */
>>>
>>> The is no enable -- ignoring bugs of which there have been couple of
>>> instances, but those trigger the BUG() so are pretty obvious.
>>>
>>> Ian.
>>>
>>>
>>
>>
>>
>>
>=20
>=20
>=20
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>=20



--------------enig2567AA1A474DF249DA5F091A
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBCgAGBQJQftxyAAoJEOhnXe7L7s6j3vsQAMcmgY1Ebao/FjiQQZhub8+y
5LLEOO/DPPlmUICssoz9IKrN4ZOoPGGKSlsuWVIALvbl+DgT8wBLISEAvtcAcXnn
k7JknLkO49vkgJgy0TstSn4jM3xo5HbyubaALQDrPXawVqFOz133t02b0LLDD3B5
tZNqYxxWSByX/XYi1UJCQ1LeUdUqyK8luxtZsVL9KP2lTsYxfQOD7+QZ90fReALe
fvht5N/Dm1RFPkcGdirbP9JlutjbfSsbPHmR5FvHyJ6eYw46tiIEcGXnp8cYOh6y
pGi1SAAg/c2zOAytPibut2CDdpqwJVX7VzrJsjhj2lnVwvge6ADJS6tr7wgMMj5V
7J/c1QeHj+u0Dkgz+UutgrHcXHyRwv2iLDq6PppjY5VjbPZlYU6Mhs8E3bzmZzBT
t1LjGDj4LcoPtH2I3XEr4I5ivClFcLlvEDAVQ45iYy1fp4NxBykc0A0/TgwQ6NIS
E+JSd4DZM5MDlftue4AelKb9/4lE6G/V+9o4SSSPDcDhJCKZO9pSDTUty9PHFwti
96XCF0o2F2qH7aOI1UwFfimHGViZshHB0hvxtanoQPw0kulpxhKDUu1Q8CPnBTlm
7zuKEHtNjf+hoJs62dPPNx+EfgDXS4JeUj54IoMrPoPMBljDRW+q1aQ1WdHa9AMT
GmjYaVKtKTd7P05P/kaa
=Wd+1
-----END PGP SIGNATURE-----

--------------enig2567AA1A474DF249DA5F091A--


--===============2837620664345663613==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2837620664345663613==--


From xen-devel-bounces@lists.xen.org Wed Oct 17 16:27:50 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 16:27:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOWT3-0000pa-UU; Wed, 17 Oct 2012 16:27:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOWT2-0000pP-Fy
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 16:27:36 +0000
Received: from [85.158.143.35:31299] by server-1.bemta-4.messagelabs.com id
	7D/7A-19134-77CDE705; Wed, 17 Oct 2012 16:27:35 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1350491254!4763853!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11191 invoked from network); 17 Oct 2012 16:27:35 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-2.tower-21.messagelabs.com with SMTP;
	17 Oct 2012 16:27:35 -0000
Received: from p5b2e42c0.dip.t-dialin.net ([91.46.66.192] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from )
	id 1TOWSy-0004fs-7w; Wed, 17 Oct 2012 16:27:32 +0000
Message-ID: <507EDC71.4040400@canonical.com>
Date: Wed, 17 Oct 2012 18:27:29 +0200
From: Stefan Bader 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Andrew Cooper 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
	<1350482118.2460.74.camel@zakaz.uk.xensource.com>
	<507ECD06.2050407@canonical.com> <507ED038.8000806@citrix.com>
In-Reply-To: <507ED038.8000806@citrix.com>
X-Enigmail-Version: 1.4.5
Cc: "xen-devel@lists.xen.org" ,
	Ian Campbell ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============2837620664345663613=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============2837620664345663613==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig2567AA1A474DF249DA5F091A"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig2567AA1A474DF249DA5F091A
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 17.10.2012 17:35, Andrew Cooper wrote:

>> (XEN) Event channel information for domain 1:
>> (XEN) Polling vCPUs: {1,4,6}
>> (XEN) port [p/m]
>> (XEN) 4 [1/1]: s=3D6 n=3D0 x=3D0
>> (XEN) 10 [0/1]: s=3D6 n=3D1 x=3D0
>> (XEN) 28 [0/1]: s=3D6 n=3D4 x=3D0
>> (XEN) 40 [0/1]: s=3D6 n=3D6 x=3D0
>>
> s =3D state.  0 =3D free, 1 =3D reserved, 2 =3D unbound, 3 =3D inter-do=
main, 4 =3D
> pirq, 5 =3D virq, 6 =3D ipi
> n =3D target vcpu id to notify
> x =3D boolean indicating whether xen is a consumer of the event channel=
 or
> not.
>=20
> d =3D target domain (when appropriate)  In this case, p is the target p=
ort.
>=20

Thanks (at least something learned today :)) One thing I noticed here, in=
 the
event channel info above, pending is 0 for channel 10, 28 and 40 (and set=
 for 4
which is the spinlock ipi for cpu 0). But in the VCPU info below (another=

unknown: has=3DT and F) it says upcall_pend for all of them. Unfortunatel=
y that
might just mean that things change...

>> (XEN) VCPU0: CPU3 [has=3DT] flags=3D0 poll=3D0 upcall_pend =3D 01, upc=
all_mask
> =3D 01
>> dirty_cpus=3D{3} cpu_affinity=3D{0-127}
>> (XEN) No periodic timer
>> (XEN) VCPU1: CPU7 [has=3DF] flags=3D1 poll=3D10 upcall_pend =3D 01,
> upcall_mask =3D 01
>> dirty_cpus=3D{} cpu_affinity=3D{0-127}
>> (XEN) No periodic timer

>> (XEN) VCPU4: CPU6 [has=3DF] flags=3D1 poll=3D28 upcall_pend =3D 01,
> upcall_mask =3D 01
>> dirty_cpus=3D{} cpu_affinity=3D{0-127}
>> (XEN) No periodic timer
>> (XEN) VCPU6: CPU0 [has=3DF] flags=3D1 poll=3D40 upcall_pend =3D 01,
> upcall_mask =3D 01
>> dirty_cpus=3D{} cpu_affinity=3D{0-127}
>> (XEN) No periodic timer
>=20
> So in this case, vcpu 1 is in a poll, on port 10, which is an IPI event=

> channel for itself.
>=20
> Same for vcpu 4, except it is on port 28, and for vcpu 6 on port 60.
>=20

>=20
> I wonder if there is possibly a race condition between notifying that a=

> lock has been unlocked, and another vcpu trying to poll after deciding
> that the lock is locked.

There has to be something somehwere, I just cannot spot it. The unlocking=
 cpu
will do a wmb() before setting the lock to 0, then a mb() and then check =
for
spinners. When failing the quick pack a locker will first set the lockspi=
nner
entry, then do a wmb() and increment the spinners count. After that it cl=
ears
the event pending and then checks lock again before actually going into p=
oll.

>=20
> The other option is that there is a bug in working out which event
> channel to notify when a lock is unlocked.

I had thought I saw one thing that I tried to fix with my patch. Another =
train
of thought would have been any other cpu grabbing the lock always as soon=
 as it
gets released and so preventing any cpu in poll from success. But that wo=
uld
then show the lock as locked...

>=20
> ~Andrew
>=20
>>
>>
>> Backtraces would be somewhat inconsistent (as always). Note, I should
> mention
>> that I still had a kernel with my patch applied on that guest. That
> changes
>> things a bit (actually it takes a bit longer to hang but again that
> might be
>> just a matter of timing). The strange lock state of 2 spinners on an
> unlocked
>> lock remains the same with or without it.
>>
>> One question about the patch actually, would anybody think that there
> could be a
>> case where the unlocking cpu has itself on the spinners list? I did
> not think so
>> but that might be wrong.
>>>
>>> The IRQ handler for the spinlock evtchn in Linux is:
>>> static irqreturn_t dummy_handler(int irq, void *dev_id)
>>> {
>>> BUG();
>>> return IRQ_HANDLED;
>>> }
>>>
>>> and right after we register it:
>>> disable_irq(irq); /* make sure it's never delivered */
>>>
>>> The is no enable -- ignoring bugs of which there have been couple of
>>> instances, but those trigger the BUG() so are pretty obvious.
>>>
>>> Ian.
>>>
>>>
>>
>>
>>
>>
>=20
>=20
>=20
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>=20



--------------enig2567AA1A474DF249DA5F091A
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBCgAGBQJQftxyAAoJEOhnXe7L7s6j3vsQAMcmgY1Ebao/FjiQQZhub8+y
5LLEOO/DPPlmUICssoz9IKrN4ZOoPGGKSlsuWVIALvbl+DgT8wBLISEAvtcAcXnn
k7JknLkO49vkgJgy0TstSn4jM3xo5HbyubaALQDrPXawVqFOz133t02b0LLDD3B5
tZNqYxxWSByX/XYi1UJCQ1LeUdUqyK8luxtZsVL9KP2lTsYxfQOD7+QZ90fReALe
fvht5N/Dm1RFPkcGdirbP9JlutjbfSsbPHmR5FvHyJ6eYw46tiIEcGXnp8cYOh6y
pGi1SAAg/c2zOAytPibut2CDdpqwJVX7VzrJsjhj2lnVwvge6ADJS6tr7wgMMj5V
7J/c1QeHj+u0Dkgz+UutgrHcXHyRwv2iLDq6PppjY5VjbPZlYU6Mhs8E3bzmZzBT
t1LjGDj4LcoPtH2I3XEr4I5ivClFcLlvEDAVQ45iYy1fp4NxBykc0A0/TgwQ6NIS
E+JSd4DZM5MDlftue4AelKb9/4lE6G/V+9o4SSSPDcDhJCKZO9pSDTUty9PHFwti
96XCF0o2F2qH7aOI1UwFfimHGViZshHB0hvxtanoQPw0kulpxhKDUu1Q8CPnBTlm
7zuKEHtNjf+hoJs62dPPNx+EfgDXS4JeUj54IoMrPoPMBljDRW+q1aQ1WdHa9AMT
GmjYaVKtKTd7P05P/kaa
=Wd+1
-----END PGP SIGNATURE-----

--------------enig2567AA1A474DF249DA5F091A--


--===============2837620664345663613==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2837620664345663613==--


From xen-devel-bounces@lists.xen.org Wed Oct 17 16:38:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 16:38:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOWdX-00015E-Hb; Wed, 17 Oct 2012 16:38:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOWdV-000159-EY
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 16:38:25 +0000
Received: from [85.158.139.83:55069] by server-8.bemta-5.messagelabs.com id
	66/E7-23193-00FDE705; Wed, 17 Oct 2012 16:38:24 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1350491902!29700093!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODA5NzQy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9989 invoked from network); 17 Oct 2012 16:38:24 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Oct 2012 16:38:24 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9HGcKLu023734
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Oct 2012 16:38:21 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9HGcJm4007784
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Oct 2012 16:38:20 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9HGcJt2021356; Wed, 17 Oct 2012 11:38:19 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 09:38:19 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 3A7B74035B; Wed, 17 Oct 2012 12:26:18 -0400 (EDT)
Date: Wed, 17 Oct 2012 12:26:18 -0400
From: Konrad Rzeszutek Wilk 
To: Ian Campbell 
Message-ID: <20121017162617.GA32178@phenom.dumpdata.com>
References: <507D6CCC02000078000A1B07@nat28.tlf.novell.com>
	<1350392403.18058.116.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1350392403.18058.116.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Jan Beulich , xen-devel 
Subject: Re: [Xen-devel] [PATCH] linux-2.6.18/xenbus: fix overflow check in
 xenbus_dev_write()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 16, 2012 at 02:00:03PM +0100, Ian Campbell wrote:
> On Tue, 2012-10-16 at 13:18 +0100, Jan Beulich wrote:
> > Reported-by: Dan Carpenter 
> > Signed-off-by: Jan Beulich 
> 
> Acked-by: Ian Campbell 
> 
> CC-ing Konrad since I think that modulo tweaking the path this ought to
> apply as is to upstream kernels.
> 
> > 
> > --- a/drivers/xen/xenbus/xenbus_dev.c
> > +++ b/drivers/xen/xenbus/xenbus_dev.c
> > @@ -239,7 +239,7 @@ static ssize_t xenbus_dev_write(struct f
> >  	if (!is_xenstored_ready())
> >  		return -ENODEV;
> >  
> > -	if ((len + u->len) > sizeof(u->u.buffer)) {
> > +	if (len > sizeof(u->u.buffer) - u->len) {
> >  		rc = -EINVAL;
> >  		goto out;
> >  	}
> > 
> > 
> > 

Like this:

diff --git a/drivers/xen/xenbus/xenbus_dev_frontend.c b/drivers/xen/xenbus/xenbus_dev_frontend.c
index 89f7625..ac72702 100644
--- a/drivers/xen/xenbus/xenbus_dev_frontend.c
+++ b/drivers/xen/xenbus/xenbus_dev_frontend.c
@@ -458,7 +458,7 @@ static ssize_t xenbus_file_write(struct file *filp,
 		goto out;
 
 	/* Can't write a xenbus message larger we can buffer */
-	if ((len + u->len) > sizeof(u->u.buffer)) {
+	if (len > sizeof(u->u.buffer) - u->len) {
 		/* On error, dump existing buffer */
 		u->len = 0;
 		rc = -EINVAL;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 16:38:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 16:38:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOWdX-00015E-Hb; Wed, 17 Oct 2012 16:38:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOWdV-000159-EY
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 16:38:25 +0000
Received: from [85.158.139.83:55069] by server-8.bemta-5.messagelabs.com id
	66/E7-23193-00FDE705; Wed, 17 Oct 2012 16:38:24 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1350491902!29700093!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODA5NzQy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9989 invoked from network); 17 Oct 2012 16:38:24 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Oct 2012 16:38:24 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9HGcKLu023734
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Oct 2012 16:38:21 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9HGcJm4007784
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Oct 2012 16:38:20 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9HGcJt2021356; Wed, 17 Oct 2012 11:38:19 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 09:38:19 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 3A7B74035B; Wed, 17 Oct 2012 12:26:18 -0400 (EDT)
Date: Wed, 17 Oct 2012 12:26:18 -0400
From: Konrad Rzeszutek Wilk 
To: Ian Campbell 
Message-ID: <20121017162617.GA32178@phenom.dumpdata.com>
References: <507D6CCC02000078000A1B07@nat28.tlf.novell.com>
	<1350392403.18058.116.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1350392403.18058.116.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Jan Beulich , xen-devel 
Subject: Re: [Xen-devel] [PATCH] linux-2.6.18/xenbus: fix overflow check in
 xenbus_dev_write()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 16, 2012 at 02:00:03PM +0100, Ian Campbell wrote:
> On Tue, 2012-10-16 at 13:18 +0100, Jan Beulich wrote:
> > Reported-by: Dan Carpenter 
> > Signed-off-by: Jan Beulich 
> 
> Acked-by: Ian Campbell 
> 
> CC-ing Konrad since I think that modulo tweaking the path this ought to
> apply as is to upstream kernels.
> 
> > 
> > --- a/drivers/xen/xenbus/xenbus_dev.c
> > +++ b/drivers/xen/xenbus/xenbus_dev.c
> > @@ -239,7 +239,7 @@ static ssize_t xenbus_dev_write(struct f
> >  	if (!is_xenstored_ready())
> >  		return -ENODEV;
> >  
> > -	if ((len + u->len) > sizeof(u->u.buffer)) {
> > +	if (len > sizeof(u->u.buffer) - u->len) {
> >  		rc = -EINVAL;
> >  		goto out;
> >  	}
> > 
> > 
> > 

Like this:

diff --git a/drivers/xen/xenbus/xenbus_dev_frontend.c b/drivers/xen/xenbus/xenbus_dev_frontend.c
index 89f7625..ac72702 100644
--- a/drivers/xen/xenbus/xenbus_dev_frontend.c
+++ b/drivers/xen/xenbus/xenbus_dev_frontend.c
@@ -458,7 +458,7 @@ static ssize_t xenbus_file_write(struct file *filp,
 		goto out;
 
 	/* Can't write a xenbus message larger we can buffer */
-	if ((len + u->len) > sizeof(u->u.buffer)) {
+	if (len > sizeof(u->u.buffer) - u->len) {
 		/* On error, dump existing buffer */
 		u->len = 0;
 		rc = -EINVAL;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 16:50:40 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 16:50:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOWp4-0001Ff-Pg; Wed, 17 Oct 2012 16:50:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOWp3-0001Fa-O2
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 16:50:21 +0000
Received: from [85.158.137.99:6388] by server-9.bemta-3.messagelabs.com id
	D7/E9-16841-DC1EE705; Wed, 17 Oct 2012 16:50:21 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1350492618!18821323!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26709 invoked from network); 17 Oct 2012 16:50:19 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-9.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Oct 2012 16:50:19 -0000
Received: from tazenda.hos.anvin.org (c-67-188-81-177.hsd1.ca.comcast.net
	[67.188.81.177]) (authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id q9HGoBbG001456
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256
	verify=FAIL); Wed, 17 Oct 2012 09:50:15 -0700
Message-ID: <507EE1C3.7070300@zytor.com>
Date: Wed, 17 Oct 2012 09:50:11 -0700
From: "H. Peter Anvin" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121009 Thunderbird/16.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk 
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	<507ED6C0.4020503@zytor.com>
	<20121017161036.GA10691@phenom.dumpdata.com>
In-Reply-To: <20121017161036.GA10691@phenom.dumpdata.com>
Cc: linux-acpi@vger.kernel.org, x86@kernel.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] Is: axe read_tscp pvops call. Was: Re: [RFC] ACPI
 S3 and Xen (suprisingly small\!).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/17/2012 09:10 AM, Konrad Rzeszutek Wilk wrote:
> On Wed, Oct 17, 2012 at 09:03:12AM -0700, H. Peter Anvin wrote:
>> On 10/17/2012 06:49 AM, Konrad Rzeszutek Wilk wrote:
>>>
>>> Note: These are the other patches that went in 3.7-rc1:
>>> xen/bootup: allow {read|write}_cr8 pvops call [https://lkml.org/lkml/2012/10/10/339]
>>> xen/bootup: allow read_tscp call for Xen PV guests. [https://lkml.org/lkml/2012/10/10/340]
>>>
>>
>> So WTF do we have a read_tscp PV call?  Again, if there isn't a user
>> we should just axe it...
>
> Let me spin off a patch to see if that can be done.
>

Could you do an audit for other pvops calls that have no users?  If the 
*only* user is lguest, we should talk about it, too...

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 16:50:40 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 16:50:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOWp4-0001Ff-Pg; Wed, 17 Oct 2012 16:50:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOWp3-0001Fa-O2
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 16:50:21 +0000
Received: from [85.158.137.99:6388] by server-9.bemta-3.messagelabs.com id
	D7/E9-16841-DC1EE705; Wed, 17 Oct 2012 16:50:21 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1350492618!18821323!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26709 invoked from network); 17 Oct 2012 16:50:19 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-9.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Oct 2012 16:50:19 -0000
Received: from tazenda.hos.anvin.org (c-67-188-81-177.hsd1.ca.comcast.net
	[67.188.81.177]) (authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id q9HGoBbG001456
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256
	verify=FAIL); Wed, 17 Oct 2012 09:50:15 -0700
Message-ID: <507EE1C3.7070300@zytor.com>
Date: Wed, 17 Oct 2012 09:50:11 -0700
From: "H. Peter Anvin" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121009 Thunderbird/16.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk 
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	<507ED6C0.4020503@zytor.com>
	<20121017161036.GA10691@phenom.dumpdata.com>
In-Reply-To: <20121017161036.GA10691@phenom.dumpdata.com>
Cc: linux-acpi@vger.kernel.org, x86@kernel.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] Is: axe read_tscp pvops call. Was: Re: [RFC] ACPI
 S3 and Xen (suprisingly small\!).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/17/2012 09:10 AM, Konrad Rzeszutek Wilk wrote:
> On Wed, Oct 17, 2012 at 09:03:12AM -0700, H. Peter Anvin wrote:
>> On 10/17/2012 06:49 AM, Konrad Rzeszutek Wilk wrote:
>>>
>>> Note: These are the other patches that went in 3.7-rc1:
>>> xen/bootup: allow {read|write}_cr8 pvops call [https://lkml.org/lkml/2012/10/10/339]
>>> xen/bootup: allow read_tscp call for Xen PV guests. [https://lkml.org/lkml/2012/10/10/340]
>>>
>>
>> So WTF do we have a read_tscp PV call?  Again, if there isn't a user
>> we should just axe it...
>
> Let me spin off a patch to see if that can be done.
>

Could you do an audit for other pvops calls that have no users?  If the 
*only* user is lguest, we should talk about it, too...

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 16:52:01 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 16:52:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOWqR-0001Lj-EO; Wed, 17 Oct 2012 16:51:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOWqP-0001LY-J0
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 16:51:45 +0000
Received: from [85.158.139.211:26421] by server-13.bemta-5.messagelabs.com id
	E3/C5-30674-022EE705; Wed, 17 Oct 2012 16:51:44 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1350492704!22758673!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28133 invoked from network); 17 Oct 2012 16:51:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 16:51:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,602,1344211200"; d="scan'208";a="15232669"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 16:51:44 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 17 Oct 2012 17:51:44 +0100
Date: Wed, 17 Oct 2012 17:51:21 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1350383800.18058.114.camel@zakaz.uk.xensource.com>
Message-ID: 
References: 
	<1350383800.18058.114.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" , "Keir
	\(Xen.org\)" , "Tim Deegan \(3P\)" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH v3 0/6] ARM hypercall ABI: 64 bit ready
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 16 Oct 2012, Ian Campbell wrote:
> On Thu, 2012-08-16 at 15:48 +0100, Stefano Stabellini wrote:
> > In this version of the patch series I have introduced conversion macros
> > to convert a XEN_GUEST_HANDLE_PARAM into a XEN_GUEST_HANDLE a vice
> > versa. Most of the problematic cases come from xen/arch/x86 code, in
> > order to spot them I wrote a simple debug patch that change the
> > definition of XEN_GUEST_HANDLE_PARAM to be different from
> > XEN_GUEST_HANDLE on x86 too. I am attaching the debug patch to this
> > email. 
> 
> This (quoted below) seems like a useful patch from the PoV of catching
> these sorts of things early on x86 before they break ARM.
> 
> It doesn't seem like it should have any impact on the generated code,
> should we perhaps apply it?

Nope, it shouldn't have any impact.
Having it in the tree would be a clear improvement!


> I needed the addition of the following to actually make it work though.
> 
> diff --git a/xen/include/asm-x86/guest_access.h b/xen/include/asm-x86/guest_acce
> index ca700c9..33b4afd 100644
> --- a/xen/include/asm-x86/guest_access.h
> +++ b/xen/include/asm-x86/guest_access.h
> @@ -54,22 +54,24 @@
>  
>  /* Cast a XEN_GUEST_HANDLE to XEN_GUEST_HANDLE_PARAM */
>  #define guest_handle_to_param(hnd, type) ({                  \
> +    typeof((hnd).p) _x = (hnd).p;                            \
> +    XEN_GUEST_HANDLE_PARAM(type) _y = { _x };                \
>      /* type checking: make sure that the pointers inside     \
>       * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of    \
>       * the same type, then return hnd */                     \
> -    (void)((typeof(&(hnd).p)) 0 ==                           \
> -        (typeof(&((XEN_GUEST_HANDLE_PARAM(type)) {}).p)) 0); \
> -    (hnd);                                                   \
> +    (void)(&_x == &_y.p);                                    \
> +    _y;                                                      \
>  })
>  
>  /* Cast a XEN_GUEST_HANDLE_PARAM to XEN_GUEST_HANDLE */
> -#define guest_handle_from_param(hnd, type) ({                \
> -    /* type checking: make sure that the pointers inside     \
> -     * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of    \
> -     * the same type, then return hnd */                     \
> -    (void)((typeof(&(hnd).p)) 0 ==                           \
> -        (typeof(&((XEN_GUEST_HANDLE_PARAM(type)) {}).p)) 0); \
> -    (hnd);                                                   \
> +#define guest_handle_from_param(hnd, type) ({               \
> +    typeof((hnd).p) _x = (hnd).p;                           \
> +    XEN_GUEST_HANDLE(type) _y = { _x };                     \
> +    /* type checking: make sure that the pointers inside    \
> +     * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of   \
> +     * the same type, then return hnd */                    \
> +    (void)(&_x == &_y.p);                                   \
> +    _y;                                                     \
>  })
>  
>  #define guest_handle_for_field(hnd, type, fld)          \

I would argue that these changes are the right thing to do anyway.
The original code is unreadable.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 16:52:01 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 16:52:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOWqR-0001Lj-EO; Wed, 17 Oct 2012 16:51:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOWqP-0001LY-J0
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 16:51:45 +0000
Received: from [85.158.139.211:26421] by server-13.bemta-5.messagelabs.com id
	E3/C5-30674-022EE705; Wed, 17 Oct 2012 16:51:44 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1350492704!22758673!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28133 invoked from network); 17 Oct 2012 16:51:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 16:51:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,602,1344211200"; d="scan'208";a="15232669"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 16:51:44 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 17 Oct 2012 17:51:44 +0100
Date: Wed, 17 Oct 2012 17:51:21 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1350383800.18058.114.camel@zakaz.uk.xensource.com>
Message-ID: 
References: 
	<1350383800.18058.114.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" , "Keir
	\(Xen.org\)" , "Tim Deegan \(3P\)" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH v3 0/6] ARM hypercall ABI: 64 bit ready
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 16 Oct 2012, Ian Campbell wrote:
> On Thu, 2012-08-16 at 15:48 +0100, Stefano Stabellini wrote:
> > In this version of the patch series I have introduced conversion macros
> > to convert a XEN_GUEST_HANDLE_PARAM into a XEN_GUEST_HANDLE a vice
> > versa. Most of the problematic cases come from xen/arch/x86 code, in
> > order to spot them I wrote a simple debug patch that change the
> > definition of XEN_GUEST_HANDLE_PARAM to be different from
> > XEN_GUEST_HANDLE on x86 too. I am attaching the debug patch to this
> > email. 
> 
> This (quoted below) seems like a useful patch from the PoV of catching
> these sorts of things early on x86 before they break ARM.
> 
> It doesn't seem like it should have any impact on the generated code,
> should we perhaps apply it?

Nope, it shouldn't have any impact.
Having it in the tree would be a clear improvement!


> I needed the addition of the following to actually make it work though.
> 
> diff --git a/xen/include/asm-x86/guest_access.h b/xen/include/asm-x86/guest_acce
> index ca700c9..33b4afd 100644
> --- a/xen/include/asm-x86/guest_access.h
> +++ b/xen/include/asm-x86/guest_access.h
> @@ -54,22 +54,24 @@
>  
>  /* Cast a XEN_GUEST_HANDLE to XEN_GUEST_HANDLE_PARAM */
>  #define guest_handle_to_param(hnd, type) ({                  \
> +    typeof((hnd).p) _x = (hnd).p;                            \
> +    XEN_GUEST_HANDLE_PARAM(type) _y = { _x };                \
>      /* type checking: make sure that the pointers inside     \
>       * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of    \
>       * the same type, then return hnd */                     \
> -    (void)((typeof(&(hnd).p)) 0 ==                           \
> -        (typeof(&((XEN_GUEST_HANDLE_PARAM(type)) {}).p)) 0); \
> -    (hnd);                                                   \
> +    (void)(&_x == &_y.p);                                    \
> +    _y;                                                      \
>  })
>  
>  /* Cast a XEN_GUEST_HANDLE_PARAM to XEN_GUEST_HANDLE */
> -#define guest_handle_from_param(hnd, type) ({                \
> -    /* type checking: make sure that the pointers inside     \
> -     * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of    \
> -     * the same type, then return hnd */                     \
> -    (void)((typeof(&(hnd).p)) 0 ==                           \
> -        (typeof(&((XEN_GUEST_HANDLE_PARAM(type)) {}).p)) 0); \
> -    (hnd);                                                   \
> +#define guest_handle_from_param(hnd, type) ({               \
> +    typeof((hnd).p) _x = (hnd).p;                           \
> +    XEN_GUEST_HANDLE(type) _y = { _x };                     \
> +    /* type checking: make sure that the pointers inside    \
> +     * XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are of   \
> +     * the same type, then return hnd */                    \
> +    (void)(&_x == &_y.p);                                   \
> +    _y;                                                     \
>  })
>  
>  #define guest_handle_for_field(hnd, type, fld)          \

I would argue that these changes are the right thing to do anyway.
The original code is unreadable.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 16:52:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 16:52:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOWqb-0001Mp-RY; Wed, 17 Oct 2012 16:51:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOWqa-0001Mb-6M
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 16:51:56 +0000
Received: from [85.158.139.211:5856] by server-3.bemta-5.messagelabs.com id
	40/A5-28618-B22EE705; Wed, 17 Oct 2012 16:51:55 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1350492713!22724250!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgxNjgxMg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16968 invoked from network); 17 Oct 2012 16:51:54 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-4.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Oct 2012 16:51:54 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9HGpliQ032202
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Oct 2012 16:51:48 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9HGpl0w000670
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Oct 2012 16:51:47 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9HGplx8017659; Wed, 17 Oct 2012 11:51:47 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 09:51:47 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id BE64C4035B; Wed, 17 Oct 2012 12:39:45 -0400 (EDT)
Date: Wed, 17 Oct 2012 12:39:45 -0400
From: Konrad Rzeszutek Wilk 
To: "H. Peter Anvin" 
Message-ID: <20121017163945.GA28856@phenom.dumpdata.com>
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	<507ED6C0.4020503@zytor.com>
	<20121017161036.GA10691@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20121017161036.GA10691@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: linux-acpi@vger.kernel.org, x86@kernel.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] Is: axe read_tscp pvops call. Was: Re: [RFC] ACPI
 S3 and Xen (suprisingly small\!).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 17, 2012 at 12:10:36PM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Oct 17, 2012 at 09:03:12AM -0700, H. Peter Anvin wrote:
> > On 10/17/2012 06:49 AM, Konrad Rzeszutek Wilk wrote:
> > >
> > >Note: These are the other patches that went in 3.7-rc1:
> > >xen/bootup: allow {read|write}_cr8 pvops call [https://lkml.org/lkml/2012/10/10/339]
> > >xen/bootup: allow read_tscp call for Xen PV guests. [https://lkml.org/lkml/2012/10/10/340]
> > >
> > 
> > So WTF do we have a read_tscp PV call?  Again, if there isn't a user
> > we should just axe it...
> 
> Let me spin off a patch to see if that can be done.

It can be done faily easy. That said  the only user that could
_potentially_ use this (if the read_tscp had some extra logic to
do 'readtsc' operations) would be the __vdso_getcpu.

Meaning in __vdso_getcpu we would modify it from native_read_tscp
to paravirt_read_tscp:

notrace long
__vdso_getcpu(unsigned *cpu, unsigned *node, struct getcpu_cache *unused)
{
	unsigned int p;

	if (VVAR(vgetcpu_mode) == VGETCPU_RDTSCP) {
		/* Load per CPU data from RDTSCP */
===>		native_read_tscp(&p);
	} else {
		/* Load per CPU data from GDT */
		asm("lsl %1,%0" : "=r" (p) : "r" (__PER_CPU_SEG));
	}
	if (cpu)
		*cpu = p & 0xfff;
	if (node)
		*node = p >> 12;
	return 0;
}

but that line was added for a purpose, which was
in git commit 8f12dea6135d0a55b151dcb4c6bbe211f5f8d35d
Author: Glauber de Oliveira Costa 
Date:   Wed Jan 30 13:31:06 2008 +0100

    x86: introduce native_read_tscp
    
    Targetting paravirt, this patch introduces native_read_tscp, in
    place of rdtscp() macro. When in a paravirt guest, this will
    involve a function call, and thus, cannot be done in the vdso area.
    These users then have to call the native version directly
    
    Signed-off-by: Glauber de Oliveira Costa 
    Signed-off-by: Ingo Molnar 
    Signed-off-by: Thomas Gleixner 

which implies that it since it is a vDSO area it cannot do paravirt
calls anyhow.

In other words, I think I'm OK with axing it. Going to spin a patch
and ask for some other folks to review/double check.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 16:52:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 16:52:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOWqb-0001Mp-RY; Wed, 17 Oct 2012 16:51:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOWqa-0001Mb-6M
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 16:51:56 +0000
Received: from [85.158.139.211:5856] by server-3.bemta-5.messagelabs.com id
	40/A5-28618-B22EE705; Wed, 17 Oct 2012 16:51:55 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1350492713!22724250!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgxNjgxMg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16968 invoked from network); 17 Oct 2012 16:51:54 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-4.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Oct 2012 16:51:54 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9HGpliQ032202
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Oct 2012 16:51:48 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9HGpl0w000670
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Oct 2012 16:51:47 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9HGplx8017659; Wed, 17 Oct 2012 11:51:47 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 09:51:47 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id BE64C4035B; Wed, 17 Oct 2012 12:39:45 -0400 (EDT)
Date: Wed, 17 Oct 2012 12:39:45 -0400
From: Konrad Rzeszutek Wilk 
To: "H. Peter Anvin" 
Message-ID: <20121017163945.GA28856@phenom.dumpdata.com>
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	<507ED6C0.4020503@zytor.com>
	<20121017161036.GA10691@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20121017161036.GA10691@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: linux-acpi@vger.kernel.org, x86@kernel.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] Is: axe read_tscp pvops call. Was: Re: [RFC] ACPI
 S3 and Xen (suprisingly small\!).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 17, 2012 at 12:10:36PM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Oct 17, 2012 at 09:03:12AM -0700, H. Peter Anvin wrote:
> > On 10/17/2012 06:49 AM, Konrad Rzeszutek Wilk wrote:
> > >
> > >Note: These are the other patches that went in 3.7-rc1:
> > >xen/bootup: allow {read|write}_cr8 pvops call [https://lkml.org/lkml/2012/10/10/339]
> > >xen/bootup: allow read_tscp call for Xen PV guests. [https://lkml.org/lkml/2012/10/10/340]
> > >
> > 
> > So WTF do we have a read_tscp PV call?  Again, if there isn't a user
> > we should just axe it...
> 
> Let me spin off a patch to see if that can be done.

It can be done faily easy. That said  the only user that could
_potentially_ use this (if the read_tscp had some extra logic to
do 'readtsc' operations) would be the __vdso_getcpu.

Meaning in __vdso_getcpu we would modify it from native_read_tscp
to paravirt_read_tscp:

notrace long
__vdso_getcpu(unsigned *cpu, unsigned *node, struct getcpu_cache *unused)
{
	unsigned int p;

	if (VVAR(vgetcpu_mode) == VGETCPU_RDTSCP) {
		/* Load per CPU data from RDTSCP */
===>		native_read_tscp(&p);
	} else {
		/* Load per CPU data from GDT */
		asm("lsl %1,%0" : "=r" (p) : "r" (__PER_CPU_SEG));
	}
	if (cpu)
		*cpu = p & 0xfff;
	if (node)
		*node = p >> 12;
	return 0;
}

but that line was added for a purpose, which was
in git commit 8f12dea6135d0a55b151dcb4c6bbe211f5f8d35d
Author: Glauber de Oliveira Costa 
Date:   Wed Jan 30 13:31:06 2008 +0100

    x86: introduce native_read_tscp
    
    Targetting paravirt, this patch introduces native_read_tscp, in
    place of rdtscp() macro. When in a paravirt guest, this will
    involve a function call, and thus, cannot be done in the vdso area.
    These users then have to call the native version directly
    
    Signed-off-by: Glauber de Oliveira Costa 
    Signed-off-by: Ingo Molnar 
    Signed-off-by: Thomas Gleixner 

which implies that it since it is a vDSO area it cannot do paravirt
calls anyhow.

In other words, I think I'm OK with axing it. Going to spin a patch
and ask for some other folks to review/double check.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 16:54:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 16:54:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOWst-0001aI-DU; Wed, 17 Oct 2012 16:54:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOWss-0001aB-Nr
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 16:54:18 +0000
Received: from [85.158.139.83:2055] by server-11.bemta-5.messagelabs.com id
	ED/1A-14870-9B2EE705; Wed, 17 Oct 2012 16:54:17 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1350492855!27981073!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24550 invoked from network); 17 Oct 2012 16:54:17 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Oct 2012 16:54:17 -0000
Received: from tazenda.hos.anvin.org (c-67-188-81-177.hsd1.ca.comcast.net
	[67.188.81.177]) (authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id q9HGsCl5002715
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256
	verify=FAIL); Wed, 17 Oct 2012 09:54:12 -0700
Message-ID: <507EE2B4.7070705@zytor.com>
Date: Wed, 17 Oct 2012 09:54:12 -0700
From: "H. Peter Anvin" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121009 Thunderbird/16.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk 
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	<507ED6C0.4020503@zytor.com>
	<20121017161036.GA10691@phenom.dumpdata.com>
	<20121017163945.GA28856@phenom.dumpdata.com>
In-Reply-To: <20121017163945.GA28856@phenom.dumpdata.com>
Cc: linux-acpi@vger.kernel.org, x86@kernel.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] Is: axe read_tscp pvops call. Was: Re: [RFC] ACPI
 S3 and Xen (suprisingly small\!).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/17/2012 09:39 AM, Konrad Rzeszutek Wilk wrote:
>
> which implies that it since it is a vDSO area it cannot do paravirt
> calls anyhow.
>

Obviously.  The vdso is *user space*.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 16:54:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 16:54:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOWst-0001aI-DU; Wed, 17 Oct 2012 16:54:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOWss-0001aB-Nr
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 16:54:18 +0000
Received: from [85.158.139.83:2055] by server-11.bemta-5.messagelabs.com id
	ED/1A-14870-9B2EE705; Wed, 17 Oct 2012 16:54:17 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1350492855!27981073!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24550 invoked from network); 17 Oct 2012 16:54:17 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Oct 2012 16:54:17 -0000
Received: from tazenda.hos.anvin.org (c-67-188-81-177.hsd1.ca.comcast.net
	[67.188.81.177]) (authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id q9HGsCl5002715
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256
	verify=FAIL); Wed, 17 Oct 2012 09:54:12 -0700
Message-ID: <507EE2B4.7070705@zytor.com>
Date: Wed, 17 Oct 2012 09:54:12 -0700
From: "H. Peter Anvin" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121009 Thunderbird/16.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk 
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	<507ED6C0.4020503@zytor.com>
	<20121017161036.GA10691@phenom.dumpdata.com>
	<20121017163945.GA28856@phenom.dumpdata.com>
In-Reply-To: <20121017163945.GA28856@phenom.dumpdata.com>
Cc: linux-acpi@vger.kernel.org, x86@kernel.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] Is: axe read_tscp pvops call. Was: Re: [RFC] ACPI
 S3 and Xen (suprisingly small\!).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/17/2012 09:39 AM, Konrad Rzeszutek Wilk wrote:
>
> which implies that it since it is a vDSO area it cannot do paravirt
> calls anyhow.
>

Obviously.  The vdso is *user space*.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 16:57:53 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 16:57:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOWw8-0001pD-Di; Wed, 17 Oct 2012 16:57:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOWw6-0001p7-IH
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 16:57:38 +0000
Received: from [85.158.139.211:3725] by server-1.bemta-5.messagelabs.com id
	02/E2-21640-183EE705; Wed, 17 Oct 2012 16:57:37 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1350493055!22723149!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODA5NzQy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14591 invoked from network); 17 Oct 2012 16:57:37 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Oct 2012 16:57:37 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9HGvXUq016193
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Oct 2012 16:57:34 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9HGvWrG013380
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Oct 2012 16:57:33 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9HGvWSa015195; Wed, 17 Oct 2012 11:57:32 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 09:57:32 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 3E1734035B; Wed, 17 Oct 2012 12:45:31 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: hpa@zytor.com, david.vrabel@citrix.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com
Date: Wed, 17 Oct 2012 12:45:26 -0400
Message-Id: <1350492326-22658-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [RFC PATCH] paravirt: Remove paravirt_rdtscp as all
	platforms use the native version anyhow.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The generic case uses native_read_tscp, the Xen case uses
native_read_tscp, llguest does not even have it defined.

There is not even any user of this call. The only one that
could potentially be is the __vdso_getcpu, but that runs
within vDSO so it cannot run in kernel space.

Suggested-by: H. Peter Anvin 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/include/asm/msr.h            |    4 ++--
 arch/x86/include/asm/paravirt.h       |   21 ---------------------
 arch/x86/include/asm/paravirt_types.h |    1 -
 arch/x86/kernel/paravirt.c            |    1 -
 arch/x86/xen/enlighten.c              |    2 --
 5 files changed, 2 insertions(+), 27 deletions(-)

diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
index 813ed10..ba064dd 100644
--- a/arch/x86/include/asm/msr.h
+++ b/arch/x86/include/asm/msr.h
@@ -202,6 +202,8 @@ do {							\
 
 #define rdpmcl(counter, val) ((val) = native_read_pmc(counter))
 
+#endif	/* !CONFIG_PARAVIRT */
+
 #define rdtscp(low, high, aux)					\
 do {                                                            \
 	unsigned long long _val = native_read_tscp(&(aux));     \
@@ -211,8 +213,6 @@ do {                                                            \
 
 #define rdtscpll(val, aux) (val) = native_read_tscp(&(aux))
 
-#endif	/* !CONFIG_PARAVIRT */
-
 #define wrmsrl_safe(msr, val) wrmsr_safe((msr), (u32)(val),		\
 					     (u32)((val) >> 32))
 
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index a0facf3..c2520b8 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -215,27 +215,6 @@ do {						\
 
 #define rdpmcl(counter, val) ((val) = paravirt_read_pmc(counter))
 
-static inline unsigned long long paravirt_rdtscp(unsigned int *aux)
-{
-	return PVOP_CALL1(u64, pv_cpu_ops.read_tscp, aux);
-}
-
-#define rdtscp(low, high, aux)				\
-do {							\
-	int __aux;					\
-	unsigned long __val = paravirt_rdtscp(&__aux);	\
-	(low) = (u32)__val;				\
-	(high) = (u32)(__val >> 32);			\
-	(aux) = __aux;					\
-} while (0)
-
-#define rdtscpll(val, aux)				\
-do {							\
-	unsigned long __aux; 				\
-	val = paravirt_rdtscp(&__aux);			\
-	(aux) = __aux;					\
-} while (0)
-
 static inline void paravirt_alloc_ldt(struct desc_struct *ldt, unsigned entries)
 {
 	PVOP_VCALL2(pv_cpu_ops.alloc_ldt, ldt, entries);
diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
index 142236e..d6cf0d2 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -157,7 +157,6 @@ struct pv_cpu_ops {
 
 	u64 (*read_tsc)(void);
 	u64 (*read_pmc)(int counter);
-	unsigned long long (*read_tscp)(unsigned int *aux);
 
 	/*
 	 * Atomically enable interrupts and return to userspace.  This
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index 17fff18..012d6c1 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -355,7 +355,6 @@ struct pv_cpu_ops pv_cpu_ops = {
 	.write_msr = native_write_msr_safe,
 	.read_tsc = native_read_tsc,
 	.read_pmc = native_read_pmc,
-	.read_tscp = native_read_tscp,
 	.load_tr_desc = native_load_tr_desc,
 	.set_ldt = native_set_ldt,
 	.load_gdt = native_load_gdt,
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 586d838..355341f 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1176,8 +1176,6 @@ static const struct pv_cpu_ops xen_cpu_ops __initconst = {
 	.read_tsc = native_read_tsc,
 	.read_pmc = native_read_pmc,
 
-	.read_tscp = native_read_tscp,
-
 	.iret = xen_iret,
 	.irq_enable_sysexit = xen_sysexit,
 #ifdef CONFIG_X86_64
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 16:57:53 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 16:57:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOWw8-0001pD-Di; Wed, 17 Oct 2012 16:57:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOWw6-0001p7-IH
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 16:57:38 +0000
Received: from [85.158.139.211:3725] by server-1.bemta-5.messagelabs.com id
	02/E2-21640-183EE705; Wed, 17 Oct 2012 16:57:37 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1350493055!22723149!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODA5NzQy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14591 invoked from network); 17 Oct 2012 16:57:37 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Oct 2012 16:57:37 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9HGvXUq016193
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Oct 2012 16:57:34 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9HGvWrG013380
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Oct 2012 16:57:33 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9HGvWSa015195; Wed, 17 Oct 2012 11:57:32 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 09:57:32 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 3E1734035B; Wed, 17 Oct 2012 12:45:31 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: hpa@zytor.com, david.vrabel@citrix.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com
Date: Wed, 17 Oct 2012 12:45:26 -0400
Message-Id: <1350492326-22658-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [RFC PATCH] paravirt: Remove paravirt_rdtscp as all
	platforms use the native version anyhow.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The generic case uses native_read_tscp, the Xen case uses
native_read_tscp, llguest does not even have it defined.

There is not even any user of this call. The only one that
could potentially be is the __vdso_getcpu, but that runs
within vDSO so it cannot run in kernel space.

Suggested-by: H. Peter Anvin 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/include/asm/msr.h            |    4 ++--
 arch/x86/include/asm/paravirt.h       |   21 ---------------------
 arch/x86/include/asm/paravirt_types.h |    1 -
 arch/x86/kernel/paravirt.c            |    1 -
 arch/x86/xen/enlighten.c              |    2 --
 5 files changed, 2 insertions(+), 27 deletions(-)

diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
index 813ed10..ba064dd 100644
--- a/arch/x86/include/asm/msr.h
+++ b/arch/x86/include/asm/msr.h
@@ -202,6 +202,8 @@ do {							\
 
 #define rdpmcl(counter, val) ((val) = native_read_pmc(counter))
 
+#endif	/* !CONFIG_PARAVIRT */
+
 #define rdtscp(low, high, aux)					\
 do {                                                            \
 	unsigned long long _val = native_read_tscp(&(aux));     \
@@ -211,8 +213,6 @@ do {                                                            \
 
 #define rdtscpll(val, aux) (val) = native_read_tscp(&(aux))
 
-#endif	/* !CONFIG_PARAVIRT */
-
 #define wrmsrl_safe(msr, val) wrmsr_safe((msr), (u32)(val),		\
 					     (u32)((val) >> 32))
 
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index a0facf3..c2520b8 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -215,27 +215,6 @@ do {						\
 
 #define rdpmcl(counter, val) ((val) = paravirt_read_pmc(counter))
 
-static inline unsigned long long paravirt_rdtscp(unsigned int *aux)
-{
-	return PVOP_CALL1(u64, pv_cpu_ops.read_tscp, aux);
-}
-
-#define rdtscp(low, high, aux)				\
-do {							\
-	int __aux;					\
-	unsigned long __val = paravirt_rdtscp(&__aux);	\
-	(low) = (u32)__val;				\
-	(high) = (u32)(__val >> 32);			\
-	(aux) = __aux;					\
-} while (0)
-
-#define rdtscpll(val, aux)				\
-do {							\
-	unsigned long __aux; 				\
-	val = paravirt_rdtscp(&__aux);			\
-	(aux) = __aux;					\
-} while (0)
-
 static inline void paravirt_alloc_ldt(struct desc_struct *ldt, unsigned entries)
 {
 	PVOP_VCALL2(pv_cpu_ops.alloc_ldt, ldt, entries);
diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
index 142236e..d6cf0d2 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -157,7 +157,6 @@ struct pv_cpu_ops {
 
 	u64 (*read_tsc)(void);
 	u64 (*read_pmc)(int counter);
-	unsigned long long (*read_tscp)(unsigned int *aux);
 
 	/*
 	 * Atomically enable interrupts and return to userspace.  This
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index 17fff18..012d6c1 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -355,7 +355,6 @@ struct pv_cpu_ops pv_cpu_ops = {
 	.write_msr = native_write_msr_safe,
 	.read_tsc = native_read_tsc,
 	.read_pmc = native_read_pmc,
-	.read_tscp = native_read_tscp,
 	.load_tr_desc = native_load_tr_desc,
 	.set_ldt = native_set_ldt,
 	.load_gdt = native_load_gdt,
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 586d838..355341f 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1176,8 +1176,6 @@ static const struct pv_cpu_ops xen_cpu_ops __initconst = {
 	.read_tsc = native_read_tsc,
 	.read_pmc = native_read_pmc,
 
-	.read_tscp = native_read_tscp,
-
 	.iret = xen_iret,
 	.irq_enable_sysexit = xen_sysexit,
 #ifdef CONFIG_X86_64
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 16:59:53 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 16:59:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOWy6-0001vo-0D; Wed, 17 Oct 2012 16:59:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOWy5-0001vh-0K
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 16:59:41 +0000
Received: from [85.158.139.211:43824] by server-3.bemta-5.messagelabs.com id
	63/1E-28618-CF3EE705; Wed, 17 Oct 2012 16:59:40 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1350493179!21700756!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13759 invoked from network); 17 Oct 2012 16:59:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 16:59:39 -0000
X-IronPort-AV: E=Sophos;i="4.80,602,1344211200"; d="scan'208";a="15232821"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 16:59:39 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 17 Oct 2012 17:59:39 +0100
Date: Wed, 17 Oct 2012 17:59:16 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1350463157-5068-2-git-send-email-ian.campbell@citrix.com>
Message-ID: 
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
	<1350463157-5068-2-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	"xen-devel@lists.xen.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 02/10] xen: sysfs: include err.h for PTR_ERR
	etc
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 17 Oct 2012, Ian Campbell wrote:
> Fixes build error on ARM:
> drivers/xen/sys-hypervisor.c: In function 'uuid_show_fallback':
> drivers/xen/sys-hypervisor.c:127:2: error: implicit declaration of function 'IS_ERR' [-Werror=implicit-function-declaration]
> drivers/xen/sys-hypervisor.c:128:3: error: implicit declaration of function 'PTR_ERR' [-Werror=implicit-function-declaration]
> 
> Signed-off-by: Ian Campbell 

Acked-by: Stefano Stabellini 


>  drivers/xen/sys-hypervisor.c |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c
> index 5e5ad7e..66a0a14 100644
> --- a/drivers/xen/sys-hypervisor.c
> +++ b/drivers/xen/sys-hypervisor.c
> @@ -11,6 +11,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> -- 
> 1.7.2.5
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 16:59:53 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 16:59:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOWy6-0001vo-0D; Wed, 17 Oct 2012 16:59:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOWy5-0001vh-0K
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 16:59:41 +0000
Received: from [85.158.139.211:43824] by server-3.bemta-5.messagelabs.com id
	63/1E-28618-CF3EE705; Wed, 17 Oct 2012 16:59:40 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1350493179!21700756!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13759 invoked from network); 17 Oct 2012 16:59:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 16:59:39 -0000
X-IronPort-AV: E=Sophos;i="4.80,602,1344211200"; d="scan'208";a="15232821"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 16:59:39 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 17 Oct 2012 17:59:39 +0100
Date: Wed, 17 Oct 2012 17:59:16 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1350463157-5068-2-git-send-email-ian.campbell@citrix.com>
Message-ID: 
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
	<1350463157-5068-2-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	"xen-devel@lists.xen.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 02/10] xen: sysfs: include err.h for PTR_ERR
	etc
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 17 Oct 2012, Ian Campbell wrote:
> Fixes build error on ARM:
> drivers/xen/sys-hypervisor.c: In function 'uuid_show_fallback':
> drivers/xen/sys-hypervisor.c:127:2: error: implicit declaration of function 'IS_ERR' [-Werror=implicit-function-declaration]
> drivers/xen/sys-hypervisor.c:128:3: error: implicit declaration of function 'PTR_ERR' [-Werror=implicit-function-declaration]
> 
> Signed-off-by: Ian Campbell 

Acked-by: Stefano Stabellini 


>  drivers/xen/sys-hypervisor.c |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c
> index 5e5ad7e..66a0a14 100644
> --- a/drivers/xen/sys-hypervisor.c
> +++ b/drivers/xen/sys-hypervisor.c
> @@ -11,6 +11,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> -- 
> 1.7.2.5
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 17:03:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 17:03:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOX1l-0002AD-LV; Wed, 17 Oct 2012 17:03:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOX1k-0002A1-80
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 17:03:28 +0000
Received: from [85.158.139.83:47821] by server-15.bemta-5.messagelabs.com id
	7C/FD-28599-FD4EE705; Wed, 17 Oct 2012 17:03:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1350493398!34750325!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10960 invoked from network); 17 Oct 2012 17:03:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 17:03:19 -0000
X-IronPort-AV: E=Sophos;i="4.80,602,1344211200"; d="scan'208";a="15232963"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 17:03:18 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 17 Oct 2012 18:03:18 +0100
Date: Wed, 17 Oct 2012 18:02:55 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1350463157-5068-3-git-send-email-ian.campbell@citrix.com>
Message-ID: 
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
	<1350463157-5068-3-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	"xen-devel@lists.xen.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 03/10] xen: sysfs: fix build warning.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 17 Oct 2012, Ian Campbell wrote:
> Define PRI macros for xen_ulong_t and xen_pfn_t and use to fix:
> drivers/xen/sys-hypervisor.c:288:4: warning: format '%lx' expects argument of type 'long unsigned int', but argument 3 has type 'xen_ulong_t' [-Wformat]
> 
> Ideally this would use PRIx64 on ARM but these (or equivalent) don't
> seem to be available in the kernel.

I don't think that the PRI macros are used at all in the kernel, so you
can actually name and define these ones the way you like.

These definitions seem good to me.


> Signed-off-by: Ian Campbell 
> ---
>  arch/arm/include/asm/xen/interface.h |    2 ++
>  arch/x86/include/asm/xen/interface.h |    2 ++
>  drivers/xen/sys-hypervisor.c         |    3 ++-
>  3 files changed, 6 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
> index ae05e56..62160f2 100644
> --- a/arch/arm/include/asm/xen/interface.h
> +++ b/arch/arm/include/asm/xen/interface.h
> @@ -31,7 +31,9 @@
>  /* Explicitly size integers that represent pfns in the interface with
>   * Xen so that we can have one ABI that works for 32 and 64 bit guests. */
>  typedef uint64_t xen_pfn_t;
> +#define PRI_xen_pfn "llx"
>  typedef uint64_t xen_ulong_t;
> +#define PRI_xen_ulong "llx"
>  /* Guest handles for primitive C types. */
>  __DEFINE_GUEST_HANDLE(uchar, unsigned char);
>  __DEFINE_GUEST_HANDLE(uint,  unsigned int);
> diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
> index 6d2f75a..ab3c67c 100644
> --- a/arch/x86/include/asm/xen/interface.h
> +++ b/arch/x86/include/asm/xen/interface.h
> @@ -51,7 +51,9 @@
>   * with Xen so that on ARM we can have one ABI that works for 32 and 64
>   * bit guests. */
>  typedef unsigned long xen_pfn_t;
> +#define PRI_xen_pfn "lx"
>  typedef unsigned long xen_ulong_t;
> +#define PRI_xen_ulong "lx"
>  /* Guest handles for primitive C types. */
>  __DEFINE_GUEST_HANDLE(uchar, unsigned char);
>  __DEFINE_GUEST_HANDLE(uint,  unsigned int);
> diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c
> index 66a0a14..96453f8 100644
> --- a/drivers/xen/sys-hypervisor.c
> +++ b/drivers/xen/sys-hypervisor.c
> @@ -285,7 +285,8 @@ static ssize_t virtual_start_show(struct hyp_sysfs_attr *attr, char *buffer)
>  		ret = HYPERVISOR_xen_version(XENVER_platform_parameters,
>  					     parms);
>  		if (!ret)
> -			ret = sprintf(buffer, "%lx\n", parms->virt_start);
> +			ret = sprintf(buffer, "%"PRI_xen_ulong"\n",
> +				      parms->virt_start);
>  		kfree(parms);
>  	}
>  
> -- 
> 1.7.2.5
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 17:03:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 17:03:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOX1l-0002AD-LV; Wed, 17 Oct 2012 17:03:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOX1k-0002A1-80
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 17:03:28 +0000
Received: from [85.158.139.83:47821] by server-15.bemta-5.messagelabs.com id
	7C/FD-28599-FD4EE705; Wed, 17 Oct 2012 17:03:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1350493398!34750325!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10960 invoked from network); 17 Oct 2012 17:03:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 17:03:19 -0000
X-IronPort-AV: E=Sophos;i="4.80,602,1344211200"; d="scan'208";a="15232963"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 17:03:18 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 17 Oct 2012 18:03:18 +0100
Date: Wed, 17 Oct 2012 18:02:55 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1350463157-5068-3-git-send-email-ian.campbell@citrix.com>
Message-ID: 
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
	<1350463157-5068-3-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	"xen-devel@lists.xen.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 03/10] xen: sysfs: fix build warning.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 17 Oct 2012, Ian Campbell wrote:
> Define PRI macros for xen_ulong_t and xen_pfn_t and use to fix:
> drivers/xen/sys-hypervisor.c:288:4: warning: format '%lx' expects argument of type 'long unsigned int', but argument 3 has type 'xen_ulong_t' [-Wformat]
> 
> Ideally this would use PRIx64 on ARM but these (or equivalent) don't
> seem to be available in the kernel.

I don't think that the PRI macros are used at all in the kernel, so you
can actually name and define these ones the way you like.

These definitions seem good to me.


> Signed-off-by: Ian Campbell 
> ---
>  arch/arm/include/asm/xen/interface.h |    2 ++
>  arch/x86/include/asm/xen/interface.h |    2 ++
>  drivers/xen/sys-hypervisor.c         |    3 ++-
>  3 files changed, 6 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
> index ae05e56..62160f2 100644
> --- a/arch/arm/include/asm/xen/interface.h
> +++ b/arch/arm/include/asm/xen/interface.h
> @@ -31,7 +31,9 @@
>  /* Explicitly size integers that represent pfns in the interface with
>   * Xen so that we can have one ABI that works for 32 and 64 bit guests. */
>  typedef uint64_t xen_pfn_t;
> +#define PRI_xen_pfn "llx"
>  typedef uint64_t xen_ulong_t;
> +#define PRI_xen_ulong "llx"
>  /* Guest handles for primitive C types. */
>  __DEFINE_GUEST_HANDLE(uchar, unsigned char);
>  __DEFINE_GUEST_HANDLE(uint,  unsigned int);
> diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
> index 6d2f75a..ab3c67c 100644
> --- a/arch/x86/include/asm/xen/interface.h
> +++ b/arch/x86/include/asm/xen/interface.h
> @@ -51,7 +51,9 @@
>   * with Xen so that on ARM we can have one ABI that works for 32 and 64
>   * bit guests. */
>  typedef unsigned long xen_pfn_t;
> +#define PRI_xen_pfn "lx"
>  typedef unsigned long xen_ulong_t;
> +#define PRI_xen_ulong "lx"
>  /* Guest handles for primitive C types. */
>  __DEFINE_GUEST_HANDLE(uchar, unsigned char);
>  __DEFINE_GUEST_HANDLE(uint,  unsigned int);
> diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c
> index 66a0a14..96453f8 100644
> --- a/drivers/xen/sys-hypervisor.c
> +++ b/drivers/xen/sys-hypervisor.c
> @@ -285,7 +285,8 @@ static ssize_t virtual_start_show(struct hyp_sysfs_attr *attr, char *buffer)
>  		ret = HYPERVISOR_xen_version(XENVER_platform_parameters,
>  					     parms);
>  		if (!ret)
> -			ret = sprintf(buffer, "%lx\n", parms->virt_start);
> +			ret = sprintf(buffer, "%"PRI_xen_ulong"\n",
> +				      parms->virt_start);
>  		kfree(parms);
>  	}
>  
> -- 
> 1.7.2.5
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 17:07:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 17:07:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOX56-0002KQ-IV; Wed, 17 Oct 2012 17:06:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOX54-0002KJ-TA
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 17:06:55 +0000
Received: from [85.158.143.35:8716] by server-2.bemta-4.messagelabs.com id
	20/3B-22268-EA5EE705; Wed, 17 Oct 2012 17:06:54 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1350493602!6828158!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24217 invoked from network); 17 Oct 2012 17:06:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 17:06:46 -0000
X-IronPort-AV: E=Sophos;i="4.80,602,1344211200"; d="scan'208";a="15233049"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 17:06:41 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 17 Oct 2012 18:06:41 +0100
Date: Wed, 17 Oct 2012 18:06:18 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1350463157-5068-5-git-send-email-ian.campbell@citrix.com>
Message-ID: 
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
	<1350463157-5068-5-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	"xen-devel@lists.xen.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 05/10] xen: events: pirq_check_eoi_map is
	X86 specific
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 17 Oct 2012, Ian Campbell wrote:
> On ARM I see:
> drivers/xen/events.c:280:13: warning: 'pirq_check_eoi_map' defined but not used
> [-Wunused-function]
> 
> Signed-off-by: Ian Campbell 
> Cc: Stefano Stabellini 

I hate the proliferation of #ifdefs but in this case it might be the
only thing to do


>  drivers/xen/events.c |    4 ++++
>  1 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index 59e10a1..912ac81 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
> @@ -115,7 +115,9 @@ struct irq_info {
>  #define PIRQ_SHAREABLE	(1 << 1)
>  
>  static int *evtchn_to_irq;
> +#ifdef CONFIG_X86
>  static unsigned long *pirq_eoi_map;
> +#endif
>  static bool (*pirq_needs_eoi)(unsigned irq);
>  
>  static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
> @@ -277,10 +279,12 @@ static unsigned int cpu_from_evtchn(unsigned int evtchn)
>  	return ret;
>  }
>  
> +#ifdef CONFIG_X86
>  static bool pirq_check_eoi_map(unsigned irq)
>  {
>  	return test_bit(pirq_from_irq(irq), pirq_eoi_map);
>  }
> +#endif
>  
>  static bool pirq_needs_eoi_flag(unsigned irq)
>  {
> -- 
> 1.7.2.5
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 17:07:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 17:07:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOX56-0002KQ-IV; Wed, 17 Oct 2012 17:06:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOX54-0002KJ-TA
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 17:06:55 +0000
Received: from [85.158.143.35:8716] by server-2.bemta-4.messagelabs.com id
	20/3B-22268-EA5EE705; Wed, 17 Oct 2012 17:06:54 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1350493602!6828158!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24217 invoked from network); 17 Oct 2012 17:06:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 17:06:46 -0000
X-IronPort-AV: E=Sophos;i="4.80,602,1344211200"; d="scan'208";a="15233049"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 17:06:41 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 17 Oct 2012 18:06:41 +0100
Date: Wed, 17 Oct 2012 18:06:18 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1350463157-5068-5-git-send-email-ian.campbell@citrix.com>
Message-ID: 
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
	<1350463157-5068-5-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	"xen-devel@lists.xen.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 05/10] xen: events: pirq_check_eoi_map is
	X86 specific
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 17 Oct 2012, Ian Campbell wrote:
> On ARM I see:
> drivers/xen/events.c:280:13: warning: 'pirq_check_eoi_map' defined but not used
> [-Wunused-function]
> 
> Signed-off-by: Ian Campbell 
> Cc: Stefano Stabellini 

I hate the proliferation of #ifdefs but in this case it might be the
only thing to do


>  drivers/xen/events.c |    4 ++++
>  1 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index 59e10a1..912ac81 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
> @@ -115,7 +115,9 @@ struct irq_info {
>  #define PIRQ_SHAREABLE	(1 << 1)
>  
>  static int *evtchn_to_irq;
> +#ifdef CONFIG_X86
>  static unsigned long *pirq_eoi_map;
> +#endif
>  static bool (*pirq_needs_eoi)(unsigned irq);
>  
>  static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
> @@ -277,10 +279,12 @@ static unsigned int cpu_from_evtchn(unsigned int evtchn)
>  	return ret;
>  }
>  
> +#ifdef CONFIG_X86
>  static bool pirq_check_eoi_map(unsigned irq)
>  {
>  	return test_bit(pirq_from_irq(irq), pirq_eoi_map);
>  }
> +#endif
>  
>  static bool pirq_needs_eoi_flag(unsigned irq)
>  {
> -- 
> 1.7.2.5
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 17:07:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 17:07:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOX5E-0002LO-3v; Wed, 17 Oct 2012 17:07:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOX5C-0002L8-Nw
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 17:07:02 +0000
Received: from [85.158.143.35:8984] by server-1.bemta-4.messagelabs.com id
	C0/59-19134-6B5EE705; Wed, 17 Oct 2012 17:07:02 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1350493620!6828197!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgxNjgxMg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25231 invoked from network); 17 Oct 2012 17:07:01 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Oct 2012 17:07:01 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9HH6tB5020445
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Oct 2012 17:06:56 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9HH6sWU013224
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Oct 2012 17:06:55 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9HH6sUD029180; Wed, 17 Oct 2012 12:06:54 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 10:06:54 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B9B664035B; Wed, 17 Oct 2012 12:54:52 -0400 (EDT)
Date: Wed, 17 Oct 2012 12:54:52 -0400
From: Konrad Rzeszutek Wilk 
To: "H. Peter Anvin" 
Message-ID: <20121017165452.GA22740@phenom.dumpdata.com>
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	<507ED6C0.4020503@zytor.com>
	<20121017161036.GA10691@phenom.dumpdata.com>
	<507EE1C3.7070300@zytor.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <507EE1C3.7070300@zytor.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: linux-acpi@vger.kernel.org, x86@kernel.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] Is: axe read_tscp pvops call. Was: Re: [RFC] ACPI
 S3 and Xen (suprisingly small\!).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 17, 2012 at 09:50:11AM -0700, H. Peter Anvin wrote:
> On 10/17/2012 09:10 AM, Konrad Rzeszutek Wilk wrote:
> >On Wed, Oct 17, 2012 at 09:03:12AM -0700, H. Peter Anvin wrote:
> >>On 10/17/2012 06:49 AM, Konrad Rzeszutek Wilk wrote:
> >>>
> >>>Note: These are the other patches that went in 3.7-rc1:
> >>>xen/bootup: allow {read|write}_cr8 pvops call [https://lkml.org/lkml/2012/10/10/339]
> >>>xen/bootup: allow read_tscp call for Xen PV guests. [https://lkml.org/lkml/2012/10/10/340]
> >>>
> >>
> >>So WTF do we have a read_tscp PV call?  Again, if there isn't a user
> >>we should just axe it...
> >
> >Let me spin off a patch to see if that can be done.
> >
> 
> Could you do an audit for other pvops calls that have no users?  If
> the *only* user is lguest, we should talk about it, too...

I can do that - but I don't want to be hasty here. There is a bit of
danger here - for example the read_pmc (or read_tsc) is not in use right
now. But it might be when one starts looking at making perf be able to
analyze the hypervisor (hand-waving the implementation details). So while
removing read_pmc now sounds good, it might be needed in the future.

Or maybe not :-)

Let me do a candidate list and get some conversation going.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 17:07:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 17:07:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOX5E-0002LO-3v; Wed, 17 Oct 2012 17:07:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOX5C-0002L8-Nw
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 17:07:02 +0000
Received: from [85.158.143.35:8984] by server-1.bemta-4.messagelabs.com id
	C0/59-19134-6B5EE705; Wed, 17 Oct 2012 17:07:02 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1350493620!6828197!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgxNjgxMg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25231 invoked from network); 17 Oct 2012 17:07:01 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Oct 2012 17:07:01 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9HH6tB5020445
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Oct 2012 17:06:56 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9HH6sWU013224
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Oct 2012 17:06:55 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9HH6sUD029180; Wed, 17 Oct 2012 12:06:54 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 10:06:54 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B9B664035B; Wed, 17 Oct 2012 12:54:52 -0400 (EDT)
Date: Wed, 17 Oct 2012 12:54:52 -0400
From: Konrad Rzeszutek Wilk 
To: "H. Peter Anvin" 
Message-ID: <20121017165452.GA22740@phenom.dumpdata.com>
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	<507ED6C0.4020503@zytor.com>
	<20121017161036.GA10691@phenom.dumpdata.com>
	<507EE1C3.7070300@zytor.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <507EE1C3.7070300@zytor.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: linux-acpi@vger.kernel.org, x86@kernel.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] Is: axe read_tscp pvops call. Was: Re: [RFC] ACPI
 S3 and Xen (suprisingly small\!).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 17, 2012 at 09:50:11AM -0700, H. Peter Anvin wrote:
> On 10/17/2012 09:10 AM, Konrad Rzeszutek Wilk wrote:
> >On Wed, Oct 17, 2012 at 09:03:12AM -0700, H. Peter Anvin wrote:
> >>On 10/17/2012 06:49 AM, Konrad Rzeszutek Wilk wrote:
> >>>
> >>>Note: These are the other patches that went in 3.7-rc1:
> >>>xen/bootup: allow {read|write}_cr8 pvops call [https://lkml.org/lkml/2012/10/10/339]
> >>>xen/bootup: allow read_tscp call for Xen PV guests. [https://lkml.org/lkml/2012/10/10/340]
> >>>
> >>
> >>So WTF do we have a read_tscp PV call?  Again, if there isn't a user
> >>we should just axe it...
> >
> >Let me spin off a patch to see if that can be done.
> >
> 
> Could you do an audit for other pvops calls that have no users?  If
> the *only* user is lguest, we should talk about it, too...

I can do that - but I don't want to be hasty here. There is a bit of
danger here - for example the read_pmc (or read_tsc) is not in use right
now. But it might be when one starts looking at making perf be able to
analyze the hypervisor (hand-waving the implementation details). So while
removing read_pmc now sounds good, it might be needed in the future.

Or maybe not :-)

Let me do a candidate list and get some conversation going.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 17:07:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 17:07:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOX5X-0002Ou-IA; Wed, 17 Oct 2012 17:07:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOX5U-0002OG-0U
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 17:07:21 +0000
Received: from [85.158.139.211:17314] by server-4.bemta-5.messagelabs.com id
	66/DA-01455-7C5EE705; Wed, 17 Oct 2012 17:07:19 +0000
X-Env-Sender: Jacob.Shin@amd.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1350493637!22641855!1
X-Originating-IP: [216.32.180.14]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1188 invoked from network); 17 Oct 2012 17:07:18 -0000
Received: from va3ehsobe004.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.14)
	by server-14.tower-206.messagelabs.com with AES128-SHA encrypted SMTP;
	17 Oct 2012 17:07:18 -0000
Received: from mail255-va3-R.bigfish.com (10.7.14.253) by
	VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id
	14.1.225.23; Wed, 17 Oct 2012 17:07:17 +0000
Received: from mail255-va3 (localhost [127.0.0.1])	by
	mail255-va3-R.bigfish.com (Postfix) with ESMTP id 217AB1900140	for
	; Wed, 17 Oct 2012 17:07:17 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: -3
X-BigFish: VPS-3(zzd6eah103dKzz1202h1d1ah1d2ahzzz2dh668h839h944hd25hd2bhf0ah107ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1155h)
Received: from mail255-va3 (localhost.localdomain [127.0.0.1]) by mail255-va3
	(MessageSwitch) id 1350493635483894_13726;
	Wed, 17 Oct 2012 17:07:15 +0000 (UTC)
Received: from VA3EHSMHS024.bigfish.com (unknown [10.7.14.239])	by
	mail255-va3.bigfish.com (Postfix) with ESMTP id 69D03198003F	for
	; Wed, 17 Oct 2012 17:07:15 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS024.bigfish.com (10.7.99.34) with Microsoft SMTP Server id
	14.1.225.23; Wed, 17 Oct 2012 17:07:09 +0000
X-WSS-ID: 0MC1RJW-02-0EZ-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2CF7DC80B8	for ; Wed, 17 Oct 2012
	12:07:08 -0500 (CDT)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 17 Oct 2012 12:22:59 -0500
Received: from jshin-Toonie (163.181.55.254) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Wed, 17 Oct 2012 12:07:08 -0500
Date: Wed, 17 Oct 2012 12:07:07 -0500
From: Jacob Shin 
To: 
Message-ID: <20121017170707.GB30127@jshin-Toonie>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-OriginatorOrg: amd.com
Subject: [Xen-devel] xenoprof backtrace BUG at spinlock.c:48
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

When running xenoprof with backtrace (--callgraph) enabled, with HVM passive
domain I trigger the following BUG:

It looks like there were changes in locking over time and this code path never
kept up .. Any thoughts/hints on how to get this working again?

Thanks!

(XEN) Xen BUG at spinlock.c:48
(XEN) ----[ Xen-4.3-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    4
(XEN) RIP:    e008:[] check_lock+0x32/0x3e
(XEN) RFLAGS: 0000000000010046   CONTEXT: hypervisor
(XEN) rax: 0000000000000000   rbx: ffff8301d0111a60   rcx: 0000000000000001
(XEN) rdx: 0000000000000000   rsi: ffff8301d0111a60   rdi: ffff8301d0111a64
(XEN) rbp: ffff8302298afbb0   rsp: ffff8302298afbb0   r8:  0000000000000000
(XEN) r9:  0000000000000002   r10: 0000000000000000   r11: 0000000000000000
(XEN) r12: ffff8302298afc04   r13: ffff8301d0111a60   r14: 0000000000000001
(XEN) r15: 0000000000000000   cr0: 0000000080050033   cr4: 00000000000406f0
(XEN) cr3: 000000021fcfa000   cr2: 0000000000000000
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff8302298afbb0:
(XEN)    ffff8302298afbc8 ffff82c480124e7c ffff8302298afc84 ffff8302298afc38
(XEN)    ffff82c4801d99c4 ffff8302298afc38 ffff82c4801ddbd5 ffff83022d995000
(XEN)    00000002801c1003 ffff8302298afc58 ffff82c4801b66be ffff83022d995000
(XEN)    0000000000001ff0 0000000000001ff0 0000000000000008 0000000000000001
(XEN)    0000000000000000 ffff8302298afcb8 ffff82c4801b11c3 ffff830009258000
(XEN)    ffff82f6045b5be0 0000000000000004 ffff830009258000 ffff8302298afd30
(XEN)    0000000100000004 01008301d013d058 ffff8302298afd28 ffff83021fefa000
(XEN)    0000000000001ff0 0000000000000008 ffff8302298afd30 ffff830009258000
(XEN)    0000000000000000 ffff8302298afcc8 ffff82c4801b149d ffff8302298afcf8
(XEN)    ffff82c4801b1520 ffff8302298afd08 0000000000001ff0 0000000000000005
(XEN)    ffff8302298a8000 ffff8302298afd68 ffff82c48021a46f ffff8302298a8000
(XEN)    ffff8302298a8000 00ff8302298afd38 ffff8302298afd68 ffff82c48013797f
(XEN)    0000000000000000 000000000000e831 ffff83022d995000 ffff830009258000
(XEN)    ffff8301eff10000 0000000000000000 0000000000000000 ffff8302298afdb8
(XEN)    ffff82c480138acd ffff8302298afe68 000000000000e831 0000000000000000
(XEN)    0000000000000000 ffff82c4802ff140 0000000000000000 ffff8302298afe68
(XEN)    ffff8302298a8000 ffff8302298afe18 ffff82c480219f2f 0000000000000004
(XEN)    000000000000e831 00000000298afde8 ffff82c400000006 ffff8302298afe58
(XEN)    ffff8302298afe68 ffff8302298afe68 0000000000000000 0000000000000000
(XEN)    0000000000000000 ffff8302298afe38 ffff82c4802183da 0000000000000004
(XEN) Xen call trace:
(XEN)    [] check_lock+0x32/0x3e
(XEN)    [] _read_lock+0x11/0x55
(XEN)    [] get_page_from_gfn_p2m+0xc3/0x26a
(XEN)    [] __hvm_copy+0xdf/0x33c
(XEN)    [] hvm_copy_from_guest_virt_nofault+0x15/0x17
(XEN)    [] copy_from_user_hvm+0x81/0x9d
(XEN)    [] xenoprof_backtrace+0x133/0x254
(XEN)    [] xenoprof_log_event+0x143/0x159
(XEN)    [] athlon_check_ctrs+0x117/0x524
(XEN)    [] nmi_callback+0x2a/0x9e
(XEN)    [] do_nmi+0x34/0x13a
(XEN)    [] handle_ist_exception+0x58/0x60
(XEN)    [] svm_stgi_label+0/0x49


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 17:07:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 17:07:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOX5X-0002Ou-IA; Wed, 17 Oct 2012 17:07:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOX5U-0002OG-0U
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 17:07:21 +0000
Received: from [85.158.139.211:17314] by server-4.bemta-5.messagelabs.com id
	66/DA-01455-7C5EE705; Wed, 17 Oct 2012 17:07:19 +0000
X-Env-Sender: Jacob.Shin@amd.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1350493637!22641855!1
X-Originating-IP: [216.32.180.14]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1188 invoked from network); 17 Oct 2012 17:07:18 -0000
Received: from va3ehsobe004.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.14)
	by server-14.tower-206.messagelabs.com with AES128-SHA encrypted SMTP;
	17 Oct 2012 17:07:18 -0000
Received: from mail255-va3-R.bigfish.com (10.7.14.253) by
	VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id
	14.1.225.23; Wed, 17 Oct 2012 17:07:17 +0000
Received: from mail255-va3 (localhost [127.0.0.1])	by
	mail255-va3-R.bigfish.com (Postfix) with ESMTP id 217AB1900140	for
	; Wed, 17 Oct 2012 17:07:17 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: -3
X-BigFish: VPS-3(zzd6eah103dKzz1202h1d1ah1d2ahzzz2dh668h839h944hd25hd2bhf0ah107ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1155h)
Received: from mail255-va3 (localhost.localdomain [127.0.0.1]) by mail255-va3
	(MessageSwitch) id 1350493635483894_13726;
	Wed, 17 Oct 2012 17:07:15 +0000 (UTC)
Received: from VA3EHSMHS024.bigfish.com (unknown [10.7.14.239])	by
	mail255-va3.bigfish.com (Postfix) with ESMTP id 69D03198003F	for
	; Wed, 17 Oct 2012 17:07:15 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS024.bigfish.com (10.7.99.34) with Microsoft SMTP Server id
	14.1.225.23; Wed, 17 Oct 2012 17:07:09 +0000
X-WSS-ID: 0MC1RJW-02-0EZ-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2CF7DC80B8	for ; Wed, 17 Oct 2012
	12:07:08 -0500 (CDT)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 17 Oct 2012 12:22:59 -0500
Received: from jshin-Toonie (163.181.55.254) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Wed, 17 Oct 2012 12:07:08 -0500
Date: Wed, 17 Oct 2012 12:07:07 -0500
From: Jacob Shin 
To: 
Message-ID: <20121017170707.GB30127@jshin-Toonie>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-OriginatorOrg: amd.com
Subject: [Xen-devel] xenoprof backtrace BUG at spinlock.c:48
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

When running xenoprof with backtrace (--callgraph) enabled, with HVM passive
domain I trigger the following BUG:

It looks like there were changes in locking over time and this code path never
kept up .. Any thoughts/hints on how to get this working again?

Thanks!

(XEN) Xen BUG at spinlock.c:48
(XEN) ----[ Xen-4.3-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    4
(XEN) RIP:    e008:[] check_lock+0x32/0x3e
(XEN) RFLAGS: 0000000000010046   CONTEXT: hypervisor
(XEN) rax: 0000000000000000   rbx: ffff8301d0111a60   rcx: 0000000000000001
(XEN) rdx: 0000000000000000   rsi: ffff8301d0111a60   rdi: ffff8301d0111a64
(XEN) rbp: ffff8302298afbb0   rsp: ffff8302298afbb0   r8:  0000000000000000
(XEN) r9:  0000000000000002   r10: 0000000000000000   r11: 0000000000000000
(XEN) r12: ffff8302298afc04   r13: ffff8301d0111a60   r14: 0000000000000001
(XEN) r15: 0000000000000000   cr0: 0000000080050033   cr4: 00000000000406f0
(XEN) cr3: 000000021fcfa000   cr2: 0000000000000000
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff8302298afbb0:
(XEN)    ffff8302298afbc8 ffff82c480124e7c ffff8302298afc84 ffff8302298afc38
(XEN)    ffff82c4801d99c4 ffff8302298afc38 ffff82c4801ddbd5 ffff83022d995000
(XEN)    00000002801c1003 ffff8302298afc58 ffff82c4801b66be ffff83022d995000
(XEN)    0000000000001ff0 0000000000001ff0 0000000000000008 0000000000000001
(XEN)    0000000000000000 ffff8302298afcb8 ffff82c4801b11c3 ffff830009258000
(XEN)    ffff82f6045b5be0 0000000000000004 ffff830009258000 ffff8302298afd30
(XEN)    0000000100000004 01008301d013d058 ffff8302298afd28 ffff83021fefa000
(XEN)    0000000000001ff0 0000000000000008 ffff8302298afd30 ffff830009258000
(XEN)    0000000000000000 ffff8302298afcc8 ffff82c4801b149d ffff8302298afcf8
(XEN)    ffff82c4801b1520 ffff8302298afd08 0000000000001ff0 0000000000000005
(XEN)    ffff8302298a8000 ffff8302298afd68 ffff82c48021a46f ffff8302298a8000
(XEN)    ffff8302298a8000 00ff8302298afd38 ffff8302298afd68 ffff82c48013797f
(XEN)    0000000000000000 000000000000e831 ffff83022d995000 ffff830009258000
(XEN)    ffff8301eff10000 0000000000000000 0000000000000000 ffff8302298afdb8
(XEN)    ffff82c480138acd ffff8302298afe68 000000000000e831 0000000000000000
(XEN)    0000000000000000 ffff82c4802ff140 0000000000000000 ffff8302298afe68
(XEN)    ffff8302298a8000 ffff8302298afe18 ffff82c480219f2f 0000000000000004
(XEN)    000000000000e831 00000000298afde8 ffff82c400000006 ffff8302298afe58
(XEN)    ffff8302298afe68 ffff8302298afe68 0000000000000000 0000000000000000
(XEN)    0000000000000000 ffff8302298afe38 ffff82c4802183da 0000000000000004
(XEN) Xen call trace:
(XEN)    [] check_lock+0x32/0x3e
(XEN)    [] _read_lock+0x11/0x55
(XEN)    [] get_page_from_gfn_p2m+0xc3/0x26a
(XEN)    [] __hvm_copy+0xdf/0x33c
(XEN)    [] hvm_copy_from_guest_virt_nofault+0x15/0x17
(XEN)    [] copy_from_user_hvm+0x81/0x9d
(XEN)    [] xenoprof_backtrace+0x133/0x254
(XEN)    [] xenoprof_log_event+0x143/0x159
(XEN)    [] athlon_check_ctrs+0x117/0x524
(XEN)    [] nmi_callback+0x2a/0x9e
(XEN)    [] do_nmi+0x34/0x13a
(XEN)    [] handle_ist_exception+0x58/0x60
(XEN)    [] svm_stgi_label+0/0x49


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 17:09:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 17:09:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOX7G-0002eA-3F; Wed, 17 Oct 2012 17:09:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOX7F-0002dz-1V
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 17:09:09 +0000
Received: from [85.158.137.99:17010] by server-6.bemta-3.messagelabs.com id
	48/36-32375-436EE705; Wed, 17 Oct 2012 17:09:08 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1350493747!22009007!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11261 invoked from network); 17 Oct 2012 17:09:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 17:09:07 -0000
X-IronPort-AV: E=Sophos;i="4.80,602,1344211200"; d="scan'208";a="15233216"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 17:09:07 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 17 Oct 2012 18:09:06 +0100
Date: Wed, 17 Oct 2012 18:08:43 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1350463157-5068-4-git-send-email-ian.campbell@citrix.com>
Message-ID: 
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
	<1350463157-5068-4-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	"xen-devel@lists.xen.org" ,
	Jan Beulich ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 04/10] xen: dbgp: Fix warning when
 CONFIG_PCI is not enabled.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 17 Oct 2012, Ian Campbell wrote:
> I saw this on ARM:
> linux/drivers/xen/dbgp.c:11:23: warning: unused variable 'ctrlr' [-Wunused-variable]
> 
> Signed-off-by: Ian Campbell 
> Cc: Jan Beulich 


Acked-by: Stefano Stabellini 

>  drivers/xen/dbgp.c |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/xen/dbgp.c b/drivers/xen/dbgp.c
> index 42569c7..f3ccc80 100644
> --- a/drivers/xen/dbgp.c
> +++ b/drivers/xen/dbgp.c
> @@ -8,7 +8,9 @@
>  
>  static int xen_dbgp_op(struct usb_hcd *hcd, int op)
>  {
> +#ifdef CONFIG_PCI
>  	const struct device *ctrlr = hcd_to_bus(hcd)->controller;
> +#endif
>  	struct physdev_dbgp_op dbgp;
>  
>  	if (!xen_initial_domain())
> -- 
> 1.7.2.5
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 17:09:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 17:09:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOX7G-0002eA-3F; Wed, 17 Oct 2012 17:09:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOX7F-0002dz-1V
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 17:09:09 +0000
Received: from [85.158.137.99:17010] by server-6.bemta-3.messagelabs.com id
	48/36-32375-436EE705; Wed, 17 Oct 2012 17:09:08 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1350493747!22009007!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11261 invoked from network); 17 Oct 2012 17:09:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 17:09:07 -0000
X-IronPort-AV: E=Sophos;i="4.80,602,1344211200"; d="scan'208";a="15233216"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 17:09:07 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 17 Oct 2012 18:09:06 +0100
Date: Wed, 17 Oct 2012 18:08:43 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1350463157-5068-4-git-send-email-ian.campbell@citrix.com>
Message-ID: 
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
	<1350463157-5068-4-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	"xen-devel@lists.xen.org" ,
	Jan Beulich ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 04/10] xen: dbgp: Fix warning when
 CONFIG_PCI is not enabled.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 17 Oct 2012, Ian Campbell wrote:
> I saw this on ARM:
> linux/drivers/xen/dbgp.c:11:23: warning: unused variable 'ctrlr' [-Wunused-variable]
> 
> Signed-off-by: Ian Campbell 
> Cc: Jan Beulich 


Acked-by: Stefano Stabellini 

>  drivers/xen/dbgp.c |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/xen/dbgp.c b/drivers/xen/dbgp.c
> index 42569c7..f3ccc80 100644
> --- a/drivers/xen/dbgp.c
> +++ b/drivers/xen/dbgp.c
> @@ -8,7 +8,9 @@
>  
>  static int xen_dbgp_op(struct usb_hcd *hcd, int op)
>  {
> +#ifdef CONFIG_PCI
>  	const struct device *ctrlr = hcd_to_bus(hcd)->controller;
> +#endif
>  	struct physdev_dbgp_op dbgp;
>  
>  	if (!xen_initial_domain())
> -- 
> 1.7.2.5
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 17:10:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 17:10:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOX8a-0002nf-O7; Wed, 17 Oct 2012 17:10:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOX8Z-0002nW-UG
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 17:10:32 +0000
Received: from [85.158.143.35:36358] by server-1.bemta-4.messagelabs.com id
	C1/BB-19134-786EE705; Wed, 17 Oct 2012 17:10:31 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1350493830!15459051!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6245 invoked from network); 17 Oct 2012 17:10:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 17:10:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,602,1344211200"; d="scan'208";a="15233243"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 17:10:30 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 17 Oct 2012 18:10:30 +0100
Date: Wed, 17 Oct 2012 18:10:07 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1350463157-5068-7-git-send-email-ian.campbell@citrix.com>
Message-ID: 
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
	<1350463157-5068-7-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	"xen-devel@lists.xen.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 07/10] xen: grant: use xen_pfn_t type for
	frame_list.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 17 Oct 2012, Ian Campbell wrote:
> This correctly sizes it as 64 bit on ARM but leaves it as unsigned
> long on x86 (therefore no intended change on x86).
> 
> The long and ulong guest handles are now unused (and a bit dangerous)
> so remove them.
> 
> Signed-off-by: Ian Campbell 


Acked-by: Stefano Stabellini 

>  arch/arm/include/asm/xen/interface.h |    2 --
>  arch/arm/xen/grant-table.c           |    2 +-
>  arch/x86/include/asm/xen/interface.h |    2 --
>  drivers/xen/grant-table.c            |    8 ++++----
>  include/xen/grant_table.h            |    2 +-
>  include/xen/interface/grant_table.h  |    2 +-
>  6 files changed, 7 insertions(+), 11 deletions(-)
> 
> diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
> index 62160f2..1d6ef9c 100644
> --- a/arch/arm/include/asm/xen/interface.h
> +++ b/arch/arm/include/asm/xen/interface.h
> @@ -37,10 +37,8 @@ typedef uint64_t xen_ulong_t;
>  /* Guest handles for primitive C types. */
>  __DEFINE_GUEST_HANDLE(uchar, unsigned char);
>  __DEFINE_GUEST_HANDLE(uint,  unsigned int);
> -__DEFINE_GUEST_HANDLE(ulong, unsigned long);
>  DEFINE_GUEST_HANDLE(char);
>  DEFINE_GUEST_HANDLE(int);
> -DEFINE_GUEST_HANDLE(long);
>  DEFINE_GUEST_HANDLE(void);
>  DEFINE_GUEST_HANDLE(uint64_t);
>  DEFINE_GUEST_HANDLE(uint32_t);
> diff --git a/arch/arm/xen/grant-table.c b/arch/arm/xen/grant-table.c
> index dbd1330..859a9bb 100644
> --- a/arch/arm/xen/grant-table.c
> +++ b/arch/arm/xen/grant-table.c
> @@ -33,7 +33,7 @@
>  #include 
>  #include 
>  
> -int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes,
> +int arch_gnttab_map_shared(xen_pfn_t *frames, unsigned long nr_gframes,
>  			   unsigned long max_nr_gframes,
>  			   void **__shared)
>  {
> diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
> index ab3c67c..54d52ff 100644
> --- a/arch/x86/include/asm/xen/interface.h
> +++ b/arch/x86/include/asm/xen/interface.h
> @@ -57,10 +57,8 @@ typedef unsigned long xen_ulong_t;
>  /* Guest handles for primitive C types. */
>  __DEFINE_GUEST_HANDLE(uchar, unsigned char);
>  __DEFINE_GUEST_HANDLE(uint,  unsigned int);
> -__DEFINE_GUEST_HANDLE(ulong, unsigned long);
>  DEFINE_GUEST_HANDLE(char);
>  DEFINE_GUEST_HANDLE(int);
> -DEFINE_GUEST_HANDLE(long);
>  DEFINE_GUEST_HANDLE(void);
>  DEFINE_GUEST_HANDLE(uint64_t);
>  DEFINE_GUEST_HANDLE(uint32_t);
> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> index b2b0a37..b91f14e 100644
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -84,7 +84,7 @@ struct gnttab_ops {
>  	 * nr_gframes is the number of frames to map grant table. Returning
>  	 * GNTST_okay means success and negative value means failure.
>  	 */
> -	int (*map_frames)(unsigned long *frames, unsigned int nr_gframes);
> +	int (*map_frames)(xen_pfn_t *frames, unsigned int nr_gframes);
>  	/*
>  	 * Release a list of frames which are mapped in map_frames for grant
>  	 * entry status.
> @@ -960,7 +960,7 @@ static unsigned nr_status_frames(unsigned nr_grant_frames)
>  	return (nr_grant_frames * GREFS_PER_GRANT_FRAME + SPP - 1) / SPP;
>  }
>  
> -static int gnttab_map_frames_v1(unsigned long *frames, unsigned int nr_gframes)
> +static int gnttab_map_frames_v1(xen_pfn_t *frames, unsigned int nr_gframes)
>  {
>  	int rc;
>  
> @@ -977,7 +977,7 @@ static void gnttab_unmap_frames_v1(void)
>  	arch_gnttab_unmap(gnttab_shared.addr, nr_grant_frames);
>  }
>  
> -static int gnttab_map_frames_v2(unsigned long *frames, unsigned int nr_gframes)
> +static int gnttab_map_frames_v2(xen_pfn_t *frames, unsigned int nr_gframes)
>  {
>  	uint64_t *sframes;
>  	unsigned int nr_sframes;
> @@ -1029,7 +1029,7 @@ static void gnttab_unmap_frames_v2(void)
>  static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
>  {
>  	struct gnttab_setup_table setup;
> -	unsigned long *frames;
> +	xen_pfn_t *frames;
>  	unsigned int nr_gframes = end_idx + 1;
>  	int rc;
>  
> diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
> index aecee9d..694dcaf 100644
> --- a/include/xen/grant_table.h
> +++ b/include/xen/grant_table.h
> @@ -170,7 +170,7 @@ gnttab_set_unmap_op(struct gnttab_unmap_grant_ref *unmap, phys_addr_t addr,
>  	unmap->dev_bus_addr = 0;
>  }
>  
> -int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes,
> +int arch_gnttab_map_shared(xen_pfn_t *frames, unsigned long nr_gframes,
>  			   unsigned long max_nr_gframes,
>  			   void **__shared);
>  int arch_gnttab_map_status(uint64_t *frames, unsigned long nr_gframes,
> diff --git a/include/xen/interface/grant_table.h b/include/xen/interface/grant_table.h
> index f9f8b97..e40fae9 100644
> --- a/include/xen/interface/grant_table.h
> +++ b/include/xen/interface/grant_table.h
> @@ -310,7 +310,7 @@ struct gnttab_setup_table {
>      uint32_t nr_frames;
>      /* OUT parameters. */
>      int16_t  status;              /* GNTST_* */
> -    GUEST_HANDLE(ulong) frame_list;
> +    GUEST_HANDLE(xen_pfn_t) frame_list;
>  };
>  DEFINE_GUEST_HANDLE_STRUCT(gnttab_setup_table);
>  
> -- 
> 1.7.2.5
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 17:10:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 17:10:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOX8a-0002nf-O7; Wed, 17 Oct 2012 17:10:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOX8Z-0002nW-UG
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 17:10:32 +0000
Received: from [85.158.143.35:36358] by server-1.bemta-4.messagelabs.com id
	C1/BB-19134-786EE705; Wed, 17 Oct 2012 17:10:31 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1350493830!15459051!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6245 invoked from network); 17 Oct 2012 17:10:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 17:10:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,602,1344211200"; d="scan'208";a="15233243"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 17:10:30 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 17 Oct 2012 18:10:30 +0100
Date: Wed, 17 Oct 2012 18:10:07 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1350463157-5068-7-git-send-email-ian.campbell@citrix.com>
Message-ID: 
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
	<1350463157-5068-7-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	"xen-devel@lists.xen.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 07/10] xen: grant: use xen_pfn_t type for
	frame_list.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 17 Oct 2012, Ian Campbell wrote:
> This correctly sizes it as 64 bit on ARM but leaves it as unsigned
> long on x86 (therefore no intended change on x86).
> 
> The long and ulong guest handles are now unused (and a bit dangerous)
> so remove them.
> 
> Signed-off-by: Ian Campbell 


Acked-by: Stefano Stabellini 

>  arch/arm/include/asm/xen/interface.h |    2 --
>  arch/arm/xen/grant-table.c           |    2 +-
>  arch/x86/include/asm/xen/interface.h |    2 --
>  drivers/xen/grant-table.c            |    8 ++++----
>  include/xen/grant_table.h            |    2 +-
>  include/xen/interface/grant_table.h  |    2 +-
>  6 files changed, 7 insertions(+), 11 deletions(-)
> 
> diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
> index 62160f2..1d6ef9c 100644
> --- a/arch/arm/include/asm/xen/interface.h
> +++ b/arch/arm/include/asm/xen/interface.h
> @@ -37,10 +37,8 @@ typedef uint64_t xen_ulong_t;
>  /* Guest handles for primitive C types. */
>  __DEFINE_GUEST_HANDLE(uchar, unsigned char);
>  __DEFINE_GUEST_HANDLE(uint,  unsigned int);
> -__DEFINE_GUEST_HANDLE(ulong, unsigned long);
>  DEFINE_GUEST_HANDLE(char);
>  DEFINE_GUEST_HANDLE(int);
> -DEFINE_GUEST_HANDLE(long);
>  DEFINE_GUEST_HANDLE(void);
>  DEFINE_GUEST_HANDLE(uint64_t);
>  DEFINE_GUEST_HANDLE(uint32_t);
> diff --git a/arch/arm/xen/grant-table.c b/arch/arm/xen/grant-table.c
> index dbd1330..859a9bb 100644
> --- a/arch/arm/xen/grant-table.c
> +++ b/arch/arm/xen/grant-table.c
> @@ -33,7 +33,7 @@
>  #include 
>  #include 
>  
> -int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes,
> +int arch_gnttab_map_shared(xen_pfn_t *frames, unsigned long nr_gframes,
>  			   unsigned long max_nr_gframes,
>  			   void **__shared)
>  {
> diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
> index ab3c67c..54d52ff 100644
> --- a/arch/x86/include/asm/xen/interface.h
> +++ b/arch/x86/include/asm/xen/interface.h
> @@ -57,10 +57,8 @@ typedef unsigned long xen_ulong_t;
>  /* Guest handles for primitive C types. */
>  __DEFINE_GUEST_HANDLE(uchar, unsigned char);
>  __DEFINE_GUEST_HANDLE(uint,  unsigned int);
> -__DEFINE_GUEST_HANDLE(ulong, unsigned long);
>  DEFINE_GUEST_HANDLE(char);
>  DEFINE_GUEST_HANDLE(int);
> -DEFINE_GUEST_HANDLE(long);
>  DEFINE_GUEST_HANDLE(void);
>  DEFINE_GUEST_HANDLE(uint64_t);
>  DEFINE_GUEST_HANDLE(uint32_t);
> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> index b2b0a37..b91f14e 100644
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -84,7 +84,7 @@ struct gnttab_ops {
>  	 * nr_gframes is the number of frames to map grant table. Returning
>  	 * GNTST_okay means success and negative value means failure.
>  	 */
> -	int (*map_frames)(unsigned long *frames, unsigned int nr_gframes);
> +	int (*map_frames)(xen_pfn_t *frames, unsigned int nr_gframes);
>  	/*
>  	 * Release a list of frames which are mapped in map_frames for grant
>  	 * entry status.
> @@ -960,7 +960,7 @@ static unsigned nr_status_frames(unsigned nr_grant_frames)
>  	return (nr_grant_frames * GREFS_PER_GRANT_FRAME + SPP - 1) / SPP;
>  }
>  
> -static int gnttab_map_frames_v1(unsigned long *frames, unsigned int nr_gframes)
> +static int gnttab_map_frames_v1(xen_pfn_t *frames, unsigned int nr_gframes)
>  {
>  	int rc;
>  
> @@ -977,7 +977,7 @@ static void gnttab_unmap_frames_v1(void)
>  	arch_gnttab_unmap(gnttab_shared.addr, nr_grant_frames);
>  }
>  
> -static int gnttab_map_frames_v2(unsigned long *frames, unsigned int nr_gframes)
> +static int gnttab_map_frames_v2(xen_pfn_t *frames, unsigned int nr_gframes)
>  {
>  	uint64_t *sframes;
>  	unsigned int nr_sframes;
> @@ -1029,7 +1029,7 @@ static void gnttab_unmap_frames_v2(void)
>  static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
>  {
>  	struct gnttab_setup_table setup;
> -	unsigned long *frames;
> +	xen_pfn_t *frames;
>  	unsigned int nr_gframes = end_idx + 1;
>  	int rc;
>  
> diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
> index aecee9d..694dcaf 100644
> --- a/include/xen/grant_table.h
> +++ b/include/xen/grant_table.h
> @@ -170,7 +170,7 @@ gnttab_set_unmap_op(struct gnttab_unmap_grant_ref *unmap, phys_addr_t addr,
>  	unmap->dev_bus_addr = 0;
>  }
>  
> -int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes,
> +int arch_gnttab_map_shared(xen_pfn_t *frames, unsigned long nr_gframes,
>  			   unsigned long max_nr_gframes,
>  			   void **__shared);
>  int arch_gnttab_map_status(uint64_t *frames, unsigned long nr_gframes,
> diff --git a/include/xen/interface/grant_table.h b/include/xen/interface/grant_table.h
> index f9f8b97..e40fae9 100644
> --- a/include/xen/interface/grant_table.h
> +++ b/include/xen/interface/grant_table.h
> @@ -310,7 +310,7 @@ struct gnttab_setup_table {
>      uint32_t nr_frames;
>      /* OUT parameters. */
>      int16_t  status;              /* GNTST_* */
> -    GUEST_HANDLE(ulong) frame_list;
> +    GUEST_HANDLE(xen_pfn_t) frame_list;
>  };
>  DEFINE_GUEST_HANDLE_STRUCT(gnttab_setup_table);
>  
> -- 
> 1.7.2.5
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 17:13:56 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 17:13:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOXBi-00032P-Fe; Wed, 17 Oct 2012 17:13:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOXBg-00032I-KB
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 17:13:44 +0000
Received: from [85.158.137.99:19217] by server-12.bemta-3.messagelabs.com id
	A9/3B-27853-747EE705; Wed, 17 Oct 2012 17:13:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1350494023!17241925!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6788 invoked from network); 17 Oct 2012 17:13:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 17:13:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,602,1344211200"; d="scan'208";a="15233341"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 17:13:42 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 17 Oct 2012 18:13:42 +0100
Date: Wed, 17 Oct 2012 18:13:19 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1350463157-5068-10-git-send-email-ian.campbell@citrix.com>
Message-ID: 
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
	<1350463157-5068-10-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	"xen-devel@lists.xen.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 10/10] xen: arm: make p2m operations NOPs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 17 Oct 2012, Ian Campbell wrote:
> This makes common code less ifdef-y and is consistent with PVHVM on
> x86.
> 
> Also note that phys_to_machine_mapping_valid should take a pfn
> argument and make it do so.
> 
> Add __set_phys_to_machine, make set_phys_to_machine a simple wrapper
> (on systems with non-nop implementations the outer one can allocate
> new p2m pages).
> 
> Make __set_phys_to_machine check for identity mapping or invalid only.
> 
> Signed-off-by: Ian Campbell 

Acked-by: Stefano Stabellini 


>  arch/arm/include/asm/xen/page.h |   13 ++++++++++---
>  1 files changed, 10 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
> index 1742023..c6b9096 100644
> --- a/arch/arm/include/asm/xen/page.h
> +++ b/arch/arm/include/asm/xen/page.h
> @@ -10,7 +10,7 @@
>  #include 
>  
>  #define pfn_to_mfn(pfn)			(pfn)
> -#define phys_to_machine_mapping_valid	(1)
> +#define phys_to_machine_mapping_valid(pfn) (1)
>  #define mfn_to_pfn(mfn)			(mfn)
>  #define mfn_to_virt(m)			(__va(mfn_to_pfn(m) << PAGE_SHIFT))
>  
> @@ -30,6 +30,8 @@ typedef struct xpaddr {
>  #define XMADDR(x)	((xmaddr_t) { .maddr = (x) })
>  #define XPADDR(x)	((xpaddr_t) { .paddr = (x) })
>  
> +#define INVALID_P2M_ENTRY      (~0UL)
> +
>  static inline xmaddr_t phys_to_machine(xpaddr_t phys)
>  {
>  	unsigned offset = phys.paddr & ~PAGE_MASK;
> @@ -74,9 +76,14 @@ static inline int m2p_remove_override(struct page *page, bool clear_pte)
>  	return 0;
>  }
>  
> +static inline bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
> +{
> +	BUG_ON(pfn != mfn && mfn != INVALID_P2M_ENTRY);
> +	return true;
> +}
> +
>  static inline bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
>  {
> -	BUG();
> -	return false;
> +	return __set_phys_to_machine(pfn, mfn);
>  }
>  #endif /* _ASM_ARM_XEN_PAGE_H */
> -- 
> 1.7.2.5
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 17:13:56 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 17:13:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOXBi-00032P-Fe; Wed, 17 Oct 2012 17:13:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOXBg-00032I-KB
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 17:13:44 +0000
Received: from [85.158.137.99:19217] by server-12.bemta-3.messagelabs.com id
	A9/3B-27853-747EE705; Wed, 17 Oct 2012 17:13:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1350494023!17241925!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6788 invoked from network); 17 Oct 2012 17:13:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 17:13:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,602,1344211200"; d="scan'208";a="15233341"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 17:13:42 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 17 Oct 2012 18:13:42 +0100
Date: Wed, 17 Oct 2012 18:13:19 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1350463157-5068-10-git-send-email-ian.campbell@citrix.com>
Message-ID: 
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
	<1350463157-5068-10-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	"xen-devel@lists.xen.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 10/10] xen: arm: make p2m operations NOPs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 17 Oct 2012, Ian Campbell wrote:
> This makes common code less ifdef-y and is consistent with PVHVM on
> x86.
> 
> Also note that phys_to_machine_mapping_valid should take a pfn
> argument and make it do so.
> 
> Add __set_phys_to_machine, make set_phys_to_machine a simple wrapper
> (on systems with non-nop implementations the outer one can allocate
> new p2m pages).
> 
> Make __set_phys_to_machine check for identity mapping or invalid only.
> 
> Signed-off-by: Ian Campbell 

Acked-by: Stefano Stabellini 


>  arch/arm/include/asm/xen/page.h |   13 ++++++++++---
>  1 files changed, 10 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
> index 1742023..c6b9096 100644
> --- a/arch/arm/include/asm/xen/page.h
> +++ b/arch/arm/include/asm/xen/page.h
> @@ -10,7 +10,7 @@
>  #include 
>  
>  #define pfn_to_mfn(pfn)			(pfn)
> -#define phys_to_machine_mapping_valid	(1)
> +#define phys_to_machine_mapping_valid(pfn) (1)
>  #define mfn_to_pfn(mfn)			(mfn)
>  #define mfn_to_virt(m)			(__va(mfn_to_pfn(m) << PAGE_SHIFT))
>  
> @@ -30,6 +30,8 @@ typedef struct xpaddr {
>  #define XMADDR(x)	((xmaddr_t) { .maddr = (x) })
>  #define XPADDR(x)	((xpaddr_t) { .paddr = (x) })
>  
> +#define INVALID_P2M_ENTRY      (~0UL)
> +
>  static inline xmaddr_t phys_to_machine(xpaddr_t phys)
>  {
>  	unsigned offset = phys.paddr & ~PAGE_MASK;
> @@ -74,9 +76,14 @@ static inline int m2p_remove_override(struct page *page, bool clear_pte)
>  	return 0;
>  }
>  
> +static inline bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
> +{
> +	BUG_ON(pfn != mfn && mfn != INVALID_P2M_ENTRY);
> +	return true;
> +}
> +
>  static inline bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
>  {
> -	BUG();
> -	return false;
> +	return __set_phys_to_machine(pfn, mfn);
>  }
>  #endif /* _ASM_ARM_XEN_PAGE_H */
> -- 
> 1.7.2.5
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 17:29:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 17:29:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOXQT-0003LV-66; Wed, 17 Oct 2012 17:29:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOXQR-0003LG-Jz
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 17:28:59 +0000
Received: from [85.158.139.211:23400] by server-15.bemta-5.messagelabs.com id
	62/0A-28599-ADAEE705; Wed, 17 Oct 2012 17:28:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1350494938!22250924!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3797 invoked from network); 17 Oct 2012 17:28:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 17:28:58 -0000
X-IronPort-AV: E=Sophos;i="4.80,602,1344211200"; d="scan'208";a="15233859"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 17:28:58 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 17 Oct 2012 18:28:58 +0100
Date: Wed, 17 Oct 2012 18:28:35 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1350463157-5068-9-git-send-email-ian.campbell@citrix.com>
Message-ID: 
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
	<1350463157-5068-9-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	"xen-devel@lists.xen.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 09/10] xen: balloon: use correct type for
	frame_list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 17 Oct 2012, Ian Campbell wrote:
> This is now a xen_pfn_t.
> 
> Signed-off-by: Ian Campbell 
> ---
>  drivers/xen/balloon.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> index d7bd1b3..d6886d9 100644
> --- a/drivers/xen/balloon.c
> +++ b/drivers/xen/balloon.c
> @@ -87,7 +87,7 @@ struct balloon_stats balloon_stats;
>  EXPORT_SYMBOL_GPL(balloon_stats);
>  
>  /* We increase/decrease in batches which fit in a page */
> -static unsigned long frame_list[PAGE_SIZE / sizeof(unsigned long)];
> +static xen_pfn_t frame_list[PAGE_SIZE / sizeof(unsigned long)];
>  
>  #ifdef CONFIG_HIGHMEM
>  #define inc_totalhigh_pages() (totalhigh_pages++)

I know that we agreed to this change but it still gives me the creeps.
I would love a comment either in the code or in the commit message,
explaining why it is safe to pass a xen_pfn_t (potentially 64 bit) to 
set_phys_to_machine.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 17:29:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 17:29:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOXQT-0003LV-66; Wed, 17 Oct 2012 17:29:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOXQR-0003LG-Jz
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 17:28:59 +0000
Received: from [85.158.139.211:23400] by server-15.bemta-5.messagelabs.com id
	62/0A-28599-ADAEE705; Wed, 17 Oct 2012 17:28:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1350494938!22250924!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3797 invoked from network); 17 Oct 2012 17:28:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 17:28:58 -0000
X-IronPort-AV: E=Sophos;i="4.80,602,1344211200"; d="scan'208";a="15233859"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 17:28:58 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 17 Oct 2012 18:28:58 +0100
Date: Wed, 17 Oct 2012 18:28:35 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1350463157-5068-9-git-send-email-ian.campbell@citrix.com>
Message-ID: 
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
	<1350463157-5068-9-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	"xen-devel@lists.xen.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 09/10] xen: balloon: use correct type for
	frame_list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 17 Oct 2012, Ian Campbell wrote:
> This is now a xen_pfn_t.
> 
> Signed-off-by: Ian Campbell 
> ---
>  drivers/xen/balloon.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> index d7bd1b3..d6886d9 100644
> --- a/drivers/xen/balloon.c
> +++ b/drivers/xen/balloon.c
> @@ -87,7 +87,7 @@ struct balloon_stats balloon_stats;
>  EXPORT_SYMBOL_GPL(balloon_stats);
>  
>  /* We increase/decrease in batches which fit in a page */
> -static unsigned long frame_list[PAGE_SIZE / sizeof(unsigned long)];
> +static xen_pfn_t frame_list[PAGE_SIZE / sizeof(unsigned long)];
>  
>  #ifdef CONFIG_HIGHMEM
>  #define inc_totalhigh_pages() (totalhigh_pages++)

I know that we agreed to this change but it still gives me the creeps.
I would love a comment either in the code or in the commit message,
explaining why it is safe to pass a xen_pfn_t (potentially 64 bit) to 
set_phys_to_machine.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 17:29:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 17:29:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOXQN-0003Kl-Ks; Wed, 17 Oct 2012 17:28:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOXQL-0003Kd-HP
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 17:28:53 +0000
Received: from [193.109.254.147:27661] by server-5.bemta-14.messagelabs.com id
	D7/86-18309-4DAEE705; Wed, 17 Oct 2012 17:28:52 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1350494930!10335041!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10940 invoked from network); 17 Oct 2012 17:28:50 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 17:28:50 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so4525605eek.32
	for ; Wed, 17 Oct 2012 10:28:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=1J8PCd94ez7Zes9ne4wrhx6+aK1D5cJPuthWJoE8/vY=;
	b=scEI2I5qeX13Lpg3y8Z8BEf2b2z2STihS/qGZGLF9cQwMK/d13OSttvx1+wUY6UsDD
	Gmc67Ya83Nptx2Jzxm8R453aEIqOTpn0sRqN7mynPYBXtbXPfRW03u2Kk0NH85ZO8+LZ
	/vAl/kbpYAla134DJr9PzgpWex7A4RQFkhzH33DZH6vZlpN2OkDNbzK81nOp6yPqYgZ8
	ivAIkpn/nGi/o+NFirLxn7mlI2Lzb8tdiJdocyA7iWtehPXFbsEZ1AHvxHRFH5tYGIQ2
	juNHg7Bu+DRNZozRyFU2D4EjCTBUAYde4Gwetx/md23x769J0FyEzTvh5FaHoJwXUsBF
	b5ww==
Received: by 10.14.202.71 with SMTP id c47mr28172058eeo.42.1350494930584;
	Wed, 17 Oct 2012 10:28:50 -0700 (PDT)
Received: from [192.168.1.69]
	(host86-160-224-184.range86-160.btcentralplus.com. [86.160.224.184])
	by mx.google.com with ESMTPS id 7sm35958506eeg.5.2012.10.17.10.28.45
	(version=SSLv3 cipher=OTHER); Wed, 17 Oct 2012 10:28:49 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Wed, 17 Oct 2012 18:28:42 +0100
From: Keir Fraser 
To: Jacob Shin ,
	
Message-ID: 
Thread-Topic: [Xen-devel] xenoprof backtrace BUG at spinlock.c:48
Thread-Index: Ac2sjNo2FYQJXBAsW02tK2ZsJypx/A==
In-Reply-To: <20121017170707.GB30127@jshin-Toonie>
Mime-version: 1.0
Subject: Re: [Xen-devel] xenoprof backtrace BUG at spinlock.c:48
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/10/2012 18:07, "Jacob Shin"  wrote:

> Hi,
> 
> When running xenoprof with backtrace (--callgraph) enabled, with HVM passive
> domain I trigger the following BUG:
> 
> It looks like there were changes in locking over time and this code path never
> kept up .. Any thoughts/hints on how to get this working again?

It's never been valid to acquire locks in NMI context, due to the potential
for deadlock. The backtrace looks quite misguided, the event should be
logged to a simple buffer and then the posting to guest memory done later in
a suitable safe context. Or the guest memory needs to be pinned and mapped
in hypervisor address space so that it can be accessed from NMI context with
no need for locks.

 -- Keir

> Thanks!
> 
> (XEN) Xen BUG at spinlock.c:48
> (XEN) ----[ Xen-4.3-unstable  x86_64  debug=y  Not tainted ]----
> (XEN) CPU:    4
> (XEN) RIP:    e008:[] check_lock+0x32/0x3e
> (XEN) RFLAGS: 0000000000010046   CONTEXT: hypervisor
> (XEN) rax: 0000000000000000   rbx: ffff8301d0111a60   rcx: 0000000000000001
> (XEN) rdx: 0000000000000000   rsi: ffff8301d0111a60   rdi: ffff8301d0111a64
> (XEN) rbp: ffff8302298afbb0   rsp: ffff8302298afbb0   r8:  0000000000000000
> (XEN) r9:  0000000000000002   r10: 0000000000000000   r11: 0000000000000000
> (XEN) r12: ffff8302298afc04   r13: ffff8301d0111a60   r14: 0000000000000001
> (XEN) r15: 0000000000000000   cr0: 0000000080050033   cr4: 00000000000406f0
> (XEN) cr3: 000000021fcfa000   cr2: 0000000000000000
> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
> (XEN) Xen stack trace from rsp=ffff8302298afbb0:
> (XEN)    ffff8302298afbc8 ffff82c480124e7c ffff8302298afc84 ffff8302298afc38
> (XEN)    ffff82c4801d99c4 ffff8302298afc38 ffff82c4801ddbd5 ffff83022d995000
> (XEN)    00000002801c1003 ffff8302298afc58 ffff82c4801b66be ffff83022d995000
> (XEN)    0000000000001ff0 0000000000001ff0 0000000000000008 0000000000000001
> (XEN)    0000000000000000 ffff8302298afcb8 ffff82c4801b11c3 ffff830009258000
> (XEN)    ffff82f6045b5be0 0000000000000004 ffff830009258000 ffff8302298afd30
> (XEN)    0000000100000004 01008301d013d058 ffff8302298afd28 ffff83021fefa000
> (XEN)    0000000000001ff0 0000000000000008 ffff8302298afd30 ffff830009258000
> (XEN)    0000000000000000 ffff8302298afcc8 ffff82c4801b149d ffff8302298afcf8
> (XEN)    ffff82c4801b1520 ffff8302298afd08 0000000000001ff0 0000000000000005
> (XEN)    ffff8302298a8000 ffff8302298afd68 ffff82c48021a46f ffff8302298a8000
> (XEN)    ffff8302298a8000 00ff8302298afd38 ffff8302298afd68 ffff82c48013797f
> (XEN)    0000000000000000 000000000000e831 ffff83022d995000 ffff830009258000
> (XEN)    ffff8301eff10000 0000000000000000 0000000000000000 ffff8302298afdb8
> (XEN)    ffff82c480138acd ffff8302298afe68 000000000000e831 0000000000000000
> (XEN)    0000000000000000 ffff82c4802ff140 0000000000000000 ffff8302298afe68
> (XEN)    ffff8302298a8000 ffff8302298afe18 ffff82c480219f2f 0000000000000004
> (XEN)    000000000000e831 00000000298afde8 ffff82c400000006 ffff8302298afe58
> (XEN)    ffff8302298afe68 ffff8302298afe68 0000000000000000 0000000000000000
> (XEN)    0000000000000000 ffff8302298afe38 ffff82c4802183da 0000000000000004
> (XEN) Xen call trace:
> (XEN)    [] check_lock+0x32/0x3e
> (XEN)    [] _read_lock+0x11/0x55
> (XEN)    [] get_page_from_gfn_p2m+0xc3/0x26a
> (XEN)    [] __hvm_copy+0xdf/0x33c
> (XEN)    [] hvm_copy_from_guest_virt_nofault+0x15/0x17
> (XEN)    [] copy_from_user_hvm+0x81/0x9d
> (XEN)    [] xenoprof_backtrace+0x133/0x254
> (XEN)    [] xenoprof_log_event+0x143/0x159
> (XEN)    [] athlon_check_ctrs+0x117/0x524
> (XEN)    [] nmi_callback+0x2a/0x9e
> (XEN)    [] do_nmi+0x34/0x13a
> (XEN)    [] handle_ist_exception+0x58/0x60
> (XEN)    [] svm_stgi_label+0/0x49
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 17:29:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 17:29:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOXQN-0003Kl-Ks; Wed, 17 Oct 2012 17:28:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOXQL-0003Kd-HP
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 17:28:53 +0000
Received: from [193.109.254.147:27661] by server-5.bemta-14.messagelabs.com id
	D7/86-18309-4DAEE705; Wed, 17 Oct 2012 17:28:52 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1350494930!10335041!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10940 invoked from network); 17 Oct 2012 17:28:50 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 17:28:50 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so4525605eek.32
	for ; Wed, 17 Oct 2012 10:28:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=1J8PCd94ez7Zes9ne4wrhx6+aK1D5cJPuthWJoE8/vY=;
	b=scEI2I5qeX13Lpg3y8Z8BEf2b2z2STihS/qGZGLF9cQwMK/d13OSttvx1+wUY6UsDD
	Gmc67Ya83Nptx2Jzxm8R453aEIqOTpn0sRqN7mynPYBXtbXPfRW03u2Kk0NH85ZO8+LZ
	/vAl/kbpYAla134DJr9PzgpWex7A4RQFkhzH33DZH6vZlpN2OkDNbzK81nOp6yPqYgZ8
	ivAIkpn/nGi/o+NFirLxn7mlI2Lzb8tdiJdocyA7iWtehPXFbsEZ1AHvxHRFH5tYGIQ2
	juNHg7Bu+DRNZozRyFU2D4EjCTBUAYde4Gwetx/md23x769J0FyEzTvh5FaHoJwXUsBF
	b5ww==
Received: by 10.14.202.71 with SMTP id c47mr28172058eeo.42.1350494930584;
	Wed, 17 Oct 2012 10:28:50 -0700 (PDT)
Received: from [192.168.1.69]
	(host86-160-224-184.range86-160.btcentralplus.com. [86.160.224.184])
	by mx.google.com with ESMTPS id 7sm35958506eeg.5.2012.10.17.10.28.45
	(version=SSLv3 cipher=OTHER); Wed, 17 Oct 2012 10:28:49 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Wed, 17 Oct 2012 18:28:42 +0100
From: Keir Fraser 
To: Jacob Shin ,
	
Message-ID: 
Thread-Topic: [Xen-devel] xenoprof backtrace BUG at spinlock.c:48
Thread-Index: Ac2sjNo2FYQJXBAsW02tK2ZsJypx/A==
In-Reply-To: <20121017170707.GB30127@jshin-Toonie>
Mime-version: 1.0
Subject: Re: [Xen-devel] xenoprof backtrace BUG at spinlock.c:48
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/10/2012 18:07, "Jacob Shin"  wrote:

> Hi,
> 
> When running xenoprof with backtrace (--callgraph) enabled, with HVM passive
> domain I trigger the following BUG:
> 
> It looks like there were changes in locking over time and this code path never
> kept up .. Any thoughts/hints on how to get this working again?

It's never been valid to acquire locks in NMI context, due to the potential
for deadlock. The backtrace looks quite misguided, the event should be
logged to a simple buffer and then the posting to guest memory done later in
a suitable safe context. Or the guest memory needs to be pinned and mapped
in hypervisor address space so that it can be accessed from NMI context with
no need for locks.

 -- Keir

> Thanks!
> 
> (XEN) Xen BUG at spinlock.c:48
> (XEN) ----[ Xen-4.3-unstable  x86_64  debug=y  Not tainted ]----
> (XEN) CPU:    4
> (XEN) RIP:    e008:[] check_lock+0x32/0x3e
> (XEN) RFLAGS: 0000000000010046   CONTEXT: hypervisor
> (XEN) rax: 0000000000000000   rbx: ffff8301d0111a60   rcx: 0000000000000001
> (XEN) rdx: 0000000000000000   rsi: ffff8301d0111a60   rdi: ffff8301d0111a64
> (XEN) rbp: ffff8302298afbb0   rsp: ffff8302298afbb0   r8:  0000000000000000
> (XEN) r9:  0000000000000002   r10: 0000000000000000   r11: 0000000000000000
> (XEN) r12: ffff8302298afc04   r13: ffff8301d0111a60   r14: 0000000000000001
> (XEN) r15: 0000000000000000   cr0: 0000000080050033   cr4: 00000000000406f0
> (XEN) cr3: 000000021fcfa000   cr2: 0000000000000000
> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
> (XEN) Xen stack trace from rsp=ffff8302298afbb0:
> (XEN)    ffff8302298afbc8 ffff82c480124e7c ffff8302298afc84 ffff8302298afc38
> (XEN)    ffff82c4801d99c4 ffff8302298afc38 ffff82c4801ddbd5 ffff83022d995000
> (XEN)    00000002801c1003 ffff8302298afc58 ffff82c4801b66be ffff83022d995000
> (XEN)    0000000000001ff0 0000000000001ff0 0000000000000008 0000000000000001
> (XEN)    0000000000000000 ffff8302298afcb8 ffff82c4801b11c3 ffff830009258000
> (XEN)    ffff82f6045b5be0 0000000000000004 ffff830009258000 ffff8302298afd30
> (XEN)    0000000100000004 01008301d013d058 ffff8302298afd28 ffff83021fefa000
> (XEN)    0000000000001ff0 0000000000000008 ffff8302298afd30 ffff830009258000
> (XEN)    0000000000000000 ffff8302298afcc8 ffff82c4801b149d ffff8302298afcf8
> (XEN)    ffff82c4801b1520 ffff8302298afd08 0000000000001ff0 0000000000000005
> (XEN)    ffff8302298a8000 ffff8302298afd68 ffff82c48021a46f ffff8302298a8000
> (XEN)    ffff8302298a8000 00ff8302298afd38 ffff8302298afd68 ffff82c48013797f
> (XEN)    0000000000000000 000000000000e831 ffff83022d995000 ffff830009258000
> (XEN)    ffff8301eff10000 0000000000000000 0000000000000000 ffff8302298afdb8
> (XEN)    ffff82c480138acd ffff8302298afe68 000000000000e831 0000000000000000
> (XEN)    0000000000000000 ffff82c4802ff140 0000000000000000 ffff8302298afe68
> (XEN)    ffff8302298a8000 ffff8302298afe18 ffff82c480219f2f 0000000000000004
> (XEN)    000000000000e831 00000000298afde8 ffff82c400000006 ffff8302298afe58
> (XEN)    ffff8302298afe68 ffff8302298afe68 0000000000000000 0000000000000000
> (XEN)    0000000000000000 ffff8302298afe38 ffff82c4802183da 0000000000000004
> (XEN) Xen call trace:
> (XEN)    [] check_lock+0x32/0x3e
> (XEN)    [] _read_lock+0x11/0x55
> (XEN)    [] get_page_from_gfn_p2m+0xc3/0x26a
> (XEN)    [] __hvm_copy+0xdf/0x33c
> (XEN)    [] hvm_copy_from_guest_virt_nofault+0x15/0x17
> (XEN)    [] copy_from_user_hvm+0x81/0x9d
> (XEN)    [] xenoprof_backtrace+0x133/0x254
> (XEN)    [] xenoprof_log_event+0x143/0x159
> (XEN)    [] athlon_check_ctrs+0x117/0x524
> (XEN)    [] nmi_callback+0x2a/0x9e
> (XEN)    [] do_nmi+0x34/0x13a
> (XEN)    [] handle_ist_exception+0x58/0x60
> (XEN)    [] svm_stgi_label+0/0x49
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 17:35:35 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 17:35:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOXWc-0003fp-JX; Wed, 17 Oct 2012 17:35:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOXWb-0003fk-0J
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 17:35:21 +0000
Received: from [85.158.138.51:64846] by server-9.bemta-3.messagelabs.com id
	B3/52-16841-65CEE705; Wed, 17 Oct 2012 17:35:18 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1350495316!25879464!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6661 invoked from network); 17 Oct 2012 17:35:18 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 17:35:18 -0000
Received: by mail-vc0-f173.google.com with SMTP id fl15so10219962vcb.32
	for ; Wed, 17 Oct 2012 10:35:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=1KTWVxNa+mYVXSSq0xYFQX4qJGKJ9+cjr1SfltSJUk4=;
	b=F3KnYZXxshvtFA6/Pm2WPL6wx443grJEVQw26NQ7U6+lbogF7gyqMCHIOaJKCFi5cL
	apnNUF8CI0+HHuDWo/0B9VYjsE4cthGWMiXF0MIQzozSm4CIBYMk/rHBD5h6EnCsfFMC
	N+GZP7/kKD3Iq9fPHiRSz2/wJVXRxy4P5qruWqzyBIZL2nwLVzp6BoXlK51CEapxaAlS
	aNenIW44UZHszNhyY59yvaikpDC94oGpS5OhUXUD08kSlKnljjfDVcq19IwPc025wglJ
	/oiulvUxzFO0dU/Z8lxGUZTcagykL9ehokS+KduolTpVbmOpJ0kMK0QDy5INfe39vt0v
	cMdw==
MIME-Version: 1.0
Received: by 10.220.142.8 with SMTP id o8mr1021254vcu.23.1350495316436; Wed,
	17 Oct 2012 10:35:16 -0700 (PDT)
Received: by 10.58.231.138 with HTTP; Wed, 17 Oct 2012 10:35:16 -0700 (PDT)
In-Reply-To: 
References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default>
	<20581.55931.246130.308384@mariner.uk.xensource.com>
	<8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default>
	<20121002091017.GA95926@ocelot.phlegethon.org>
	<66cc0085-1216-40f7-8059-eaf615202c12@default>
	<20121002201624.GA98445@ocelot.phlegethon.org>
	
	<20121004100645.GC38243@ocelot.phlegethon.org>
	<1349345864.650.247.camel@zakaz.uk.xensource.com>
	<239799F4-AF29-494F-86D2-ADF45ACA8792@gridcentric.ca>
	<3e5cf0ba-4241-4f00-bef6-aaff2cc23419@default>
	<506EC710.3020606@eu.citrix.com>
	<58b5a25d-ccdd-4d0c-a0d9-9c249825f7f1@default>
	
	
Date: Wed, 17 Oct 2012 18:35:16 +0100
X-Google-Sender-Auth: 3lf7KRnnlYBcSEW_k3R8AI8z7DQ
Message-ID: 
From: George Dunlap 
To: Dan Magenheimer 
Cc: Olaf Hering , "Keir \(Xen.org\)" ,
	Ian Campbell ,
	Konrad Wilk ,
	Andres Lagar-Cavilla ,
	"Tim \(Xen.org\)" , xen-devel@lists.xen.org,
	George Shuklin ,
	Dario Faggioli , Kurt Hackel ,
	Ian Jackson 
Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and
	xl)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

[Sorry, forgot to reply-to-all]

On Tue, Oct 16, 2012 at 6:51 PM, Dan Magenheimer
 wrote:
>
> If you reread my last response with the assumption in mind:
>
>   "tmem == an instance of a memory scheduler == grand vision"
>
> then does the discussion of the "memory reservation" hypercall
> make more sense?

Sort of. :-) Unfortunately, I think it shows a bit of confusion, which
is perhaps why it was hard to understand.

But let's go back for a minute to the problem at hand: you're afraid
of free memory disappearing between a toolstack checking for the
memory, and the toolstack actually creating the VM.

There are two ways this could happen:

1. Another admin command (perhaps by another administrator) has caused
the memory to go away -- i.e,. another admin has called "xl create",
or has instructed a VM to balloon up to a higher amount of memory.

2. One of the self-directed processes in the system has allocated the
memory: a balloon driver has ballooned up, or the swapper has swapped
something in, or the page sharing daemon has had to un-share pages.

In the case of #1, I think the right answer to that is, "Don't do
that."  :-) The admins should co-ordinate with each other about what
to start where; if they both want to use a bit of memory, that's a
human interaction problem, not a technological one.  Alternately, if
we're talking a cloud orchestration layer, the cloud orchestration
should have an idea how much memory is available on each node, and not
allow different users to issue commands which would violate those.

In the case of #2, I think the answer is, "self-directed processes
should not be allowed to consume free memory without permission from
the toolstack".  The pager should not increase the memory footprint of
a VM unless either told to by an admin or a memory controller which
has been given authority by an admin.  (Yes, memory controller, not
scheduler -- more on that in another e-mail.)  A VM should be given a
fixed amount of memory above which the balloon driver cannot go.  The
page-sharing daemon should have a small amount set aside to handle
un-sharing requests; but this should be immediately replenished by
other methods (preferably by ballooning a VM down, or if necessary by
swapping pages out).  It should not be able to make arbitrarily large
allocations without permission from the toolstack.

I was chatting with Konrad yesterday, and he brought up
"self-ballooning" VMs, which apparently vonluntarily choose to balloon
down to *below* their toolstack-dictated balloon target, in order to
induce Linux to swap some pages out to tmem, and will then balloon up to
the toolstack-dictated target later.

It seems to me that the Right Thing in this case is for the toolstack
to know that this "free" memory isn't really free -- that if your 2GiB
VM is only using 1.5GiB, you nonetheless don't touch that 0.5GiB,
because you know it may use it later.  This is what xapi does.

Alternately, if you don't want to do that accounting, and just want to
use Xen's free memory to determine if you can start a VM, then you
could just have your "self-ballooning" processes *not actually free
the memory*.  That way the free memory would be an accurate
representation of how much memory is actually present on a system.

In all of this discussion, I don't see any reason to bring up tmem at
all (except to note the reason why a VM may balloon down).  It's just
another area to which memory can be allocated (along with Xen or a
domain).  It also should not be allowed to allocate free Xen memory to
itself without being specifically instructed by the toolstack, so it can't
cause the problem you're talking about.

Any system that follows the rules I've set above won't have to worry
about free memory disappearing half-way through domain creation.

I'm not fundamentally opposed to the idea of an "allocate memory to a
VM" hypercall; but the arguments adduced to support this seem
hopelessly confused, which does not bode well for the usefulness or
maintainability of such a hypercall.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 17:35:35 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 17:35:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOXWc-0003fp-JX; Wed, 17 Oct 2012 17:35:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOXWb-0003fk-0J
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 17:35:21 +0000
Received: from [85.158.138.51:64846] by server-9.bemta-3.messagelabs.com id
	B3/52-16841-65CEE705; Wed, 17 Oct 2012 17:35:18 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1350495316!25879464!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6661 invoked from network); 17 Oct 2012 17:35:18 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 17:35:18 -0000
Received: by mail-vc0-f173.google.com with SMTP id fl15so10219962vcb.32
	for ; Wed, 17 Oct 2012 10:35:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=1KTWVxNa+mYVXSSq0xYFQX4qJGKJ9+cjr1SfltSJUk4=;
	b=F3KnYZXxshvtFA6/Pm2WPL6wx443grJEVQw26NQ7U6+lbogF7gyqMCHIOaJKCFi5cL
	apnNUF8CI0+HHuDWo/0B9VYjsE4cthGWMiXF0MIQzozSm4CIBYMk/rHBD5h6EnCsfFMC
	N+GZP7/kKD3Iq9fPHiRSz2/wJVXRxy4P5qruWqzyBIZL2nwLVzp6BoXlK51CEapxaAlS
	aNenIW44UZHszNhyY59yvaikpDC94oGpS5OhUXUD08kSlKnljjfDVcq19IwPc025wglJ
	/oiulvUxzFO0dU/Z8lxGUZTcagykL9ehokS+KduolTpVbmOpJ0kMK0QDy5INfe39vt0v
	cMdw==
MIME-Version: 1.0
Received: by 10.220.142.8 with SMTP id o8mr1021254vcu.23.1350495316436; Wed,
	17 Oct 2012 10:35:16 -0700 (PDT)
Received: by 10.58.231.138 with HTTP; Wed, 17 Oct 2012 10:35:16 -0700 (PDT)
In-Reply-To: 
References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default>
	<20581.55931.246130.308384@mariner.uk.xensource.com>
	<8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default>
	<20121002091017.GA95926@ocelot.phlegethon.org>
	<66cc0085-1216-40f7-8059-eaf615202c12@default>
	<20121002201624.GA98445@ocelot.phlegethon.org>
	
	<20121004100645.GC38243@ocelot.phlegethon.org>
	<1349345864.650.247.camel@zakaz.uk.xensource.com>
	<239799F4-AF29-494F-86D2-ADF45ACA8792@gridcentric.ca>
	<3e5cf0ba-4241-4f00-bef6-aaff2cc23419@default>
	<506EC710.3020606@eu.citrix.com>
	<58b5a25d-ccdd-4d0c-a0d9-9c249825f7f1@default>
	
	
Date: Wed, 17 Oct 2012 18:35:16 +0100
X-Google-Sender-Auth: 3lf7KRnnlYBcSEW_k3R8AI8z7DQ
Message-ID: 
From: George Dunlap 
To: Dan Magenheimer 
Cc: Olaf Hering , "Keir \(Xen.org\)" ,
	Ian Campbell ,
	Konrad Wilk ,
	Andres Lagar-Cavilla ,
	"Tim \(Xen.org\)" , xen-devel@lists.xen.org,
	George Shuklin ,
	Dario Faggioli , Kurt Hackel ,
	Ian Jackson 
Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and
	xl)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

[Sorry, forgot to reply-to-all]

On Tue, Oct 16, 2012 at 6:51 PM, Dan Magenheimer
 wrote:
>
> If you reread my last response with the assumption in mind:
>
>   "tmem == an instance of a memory scheduler == grand vision"
>
> then does the discussion of the "memory reservation" hypercall
> make more sense?

Sort of. :-) Unfortunately, I think it shows a bit of confusion, which
is perhaps why it was hard to understand.

But let's go back for a minute to the problem at hand: you're afraid
of free memory disappearing between a toolstack checking for the
memory, and the toolstack actually creating the VM.

There are two ways this could happen:

1. Another admin command (perhaps by another administrator) has caused
the memory to go away -- i.e,. another admin has called "xl create",
or has instructed a VM to balloon up to a higher amount of memory.

2. One of the self-directed processes in the system has allocated the
memory: a balloon driver has ballooned up, or the swapper has swapped
something in, or the page sharing daemon has had to un-share pages.

In the case of #1, I think the right answer to that is, "Don't do
that."  :-) The admins should co-ordinate with each other about what
to start where; if they both want to use a bit of memory, that's a
human interaction problem, not a technological one.  Alternately, if
we're talking a cloud orchestration layer, the cloud orchestration
should have an idea how much memory is available on each node, and not
allow different users to issue commands which would violate those.

In the case of #2, I think the answer is, "self-directed processes
should not be allowed to consume free memory without permission from
the toolstack".  The pager should not increase the memory footprint of
a VM unless either told to by an admin or a memory controller which
has been given authority by an admin.  (Yes, memory controller, not
scheduler -- more on that in another e-mail.)  A VM should be given a
fixed amount of memory above which the balloon driver cannot go.  The
page-sharing daemon should have a small amount set aside to handle
un-sharing requests; but this should be immediately replenished by
other methods (preferably by ballooning a VM down, or if necessary by
swapping pages out).  It should not be able to make arbitrarily large
allocations without permission from the toolstack.

I was chatting with Konrad yesterday, and he brought up
"self-ballooning" VMs, which apparently vonluntarily choose to balloon
down to *below* their toolstack-dictated balloon target, in order to
induce Linux to swap some pages out to tmem, and will then balloon up to
the toolstack-dictated target later.

It seems to me that the Right Thing in this case is for the toolstack
to know that this "free" memory isn't really free -- that if your 2GiB
VM is only using 1.5GiB, you nonetheless don't touch that 0.5GiB,
because you know it may use it later.  This is what xapi does.

Alternately, if you don't want to do that accounting, and just want to
use Xen's free memory to determine if you can start a VM, then you
could just have your "self-ballooning" processes *not actually free
the memory*.  That way the free memory would be an accurate
representation of how much memory is actually present on a system.

In all of this discussion, I don't see any reason to bring up tmem at
all (except to note the reason why a VM may balloon down).  It's just
another area to which memory can be allocated (along with Xen or a
domain).  It also should not be allowed to allocate free Xen memory to
itself without being specifically instructed by the toolstack, so it can't
cause the problem you're talking about.

Any system that follows the rules I've set above won't have to worry
about free memory disappearing half-way through domain creation.

I'm not fundamentally opposed to the idea of an "allocate memory to a
VM" hypercall; but the arguments adduced to support this seem
hopelessly confused, which does not bode well for the usefulness or
maintainability of such a hypercall.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 17:35:44 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 17:35:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOXWj-0003gC-0G; Wed, 17 Oct 2012 17:35:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOXWh-0003g4-LM
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 17:35:27 +0000
Received: from [193.109.254.147:18289] by server-2.bemta-14.messagelabs.com id
	E2/20-19917-D5CEE705; Wed, 17 Oct 2012 17:35:25 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1350495323!5244821!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14788 invoked from network); 17 Oct 2012 17:35:24 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Oct 2012 17:35:24 -0000
Received: from tazenda.hos.anvin.org (c-67-188-81-177.hsd1.ca.comcast.net
	[67.188.81.177]) (authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id q9HHZFIl013431
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256
	verify=FAIL); Wed, 17 Oct 2012 10:35:16 -0700
Message-ID: <507EEC53.1010309@zytor.com>
Date: Wed, 17 Oct 2012 10:35:15 -0700
From: "H. Peter Anvin" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121009 Thunderbird/16.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk 
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	<507ED6C0.4020503@zytor.com>
	<20121017161036.GA10691@phenom.dumpdata.com>
	<507EE1C3.7070300@zytor.com>
	<20121017165452.GA22740@phenom.dumpdata.com>
In-Reply-To: <20121017165452.GA22740@phenom.dumpdata.com>
Cc: linux-acpi@vger.kernel.org, x86@kernel.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] Is: axe read_tscp pvops call. Was: Re: [RFC] ACPI
 S3 and Xen (suprisingly small\!).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/17/2012 09:54 AM, Konrad Rzeszutek Wilk wrote:
>>
>> Could you do an audit for other pvops calls that have no users?  If
>> the *only* user is lguest, we should talk about it, too...
>
> I can do that - but I don't want to be hasty here. There is a bit of
> danger here - for example the read_pmc (or read_tsc) is not in use right
> now. But it might be when one starts looking at making perf be able to
> analyze the hypervisor (hand-waving the implementation details). So while
> removing read_pmc now sounds good, it might be needed in the future.
>

We do not keep a pvop around just because it "might be needed in the 
future".  That's just crazy.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 17:35:44 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 17:35:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOXWj-0003gC-0G; Wed, 17 Oct 2012 17:35:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOXWh-0003g4-LM
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 17:35:27 +0000
Received: from [193.109.254.147:18289] by server-2.bemta-14.messagelabs.com id
	E2/20-19917-D5CEE705; Wed, 17 Oct 2012 17:35:25 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1350495323!5244821!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14788 invoked from network); 17 Oct 2012 17:35:24 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Oct 2012 17:35:24 -0000
Received: from tazenda.hos.anvin.org (c-67-188-81-177.hsd1.ca.comcast.net
	[67.188.81.177]) (authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id q9HHZFIl013431
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256
	verify=FAIL); Wed, 17 Oct 2012 10:35:16 -0700
Message-ID: <507EEC53.1010309@zytor.com>
Date: Wed, 17 Oct 2012 10:35:15 -0700
From: "H. Peter Anvin" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121009 Thunderbird/16.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk 
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	<507ED6C0.4020503@zytor.com>
	<20121017161036.GA10691@phenom.dumpdata.com>
	<507EE1C3.7070300@zytor.com>
	<20121017165452.GA22740@phenom.dumpdata.com>
In-Reply-To: <20121017165452.GA22740@phenom.dumpdata.com>
Cc: linux-acpi@vger.kernel.org, x86@kernel.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] Is: axe read_tscp pvops call. Was: Re: [RFC] ACPI
 S3 and Xen (suprisingly small\!).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/17/2012 09:54 AM, Konrad Rzeszutek Wilk wrote:
>>
>> Could you do an audit for other pvops calls that have no users?  If
>> the *only* user is lguest, we should talk about it, too...
>
> I can do that - but I don't want to be hasty here. There is a bit of
> danger here - for example the read_pmc (or read_tsc) is not in use right
> now. But it might be when one starts looking at making perf be able to
> analyze the hypervisor (hand-waving the implementation details). So while
> removing read_pmc now sounds good, it might be needed in the future.
>

We do not keep a pvop around just because it "might be needed in the 
future".  That's just crazy.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 17:35:45 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 17:35:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOXWq-0003hR-DL; Wed, 17 Oct 2012 17:35:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOXWo-0003gs-28
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 17:35:34 +0000
Received: from [85.158.139.211:64862] by server-1.bemta-5.messagelabs.com id
	E6/BA-21640-56CEE705; Wed, 17 Oct 2012 17:35:33 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1350495331!22726722!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2990 invoked from network); 17 Oct 2012 17:35:32 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 17:35:32 -0000
Received: by mail-vb0-f45.google.com with SMTP id p1so9382837vbi.32
	for ; Wed, 17 Oct 2012 10:35:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=5liOa4wbTKU6NrnJXDTGKGGqOIPj5W3wG/L/bue9RnA=;
	b=DKm+olCdNrYAv5LHFKbYSaq1omz04esXJhFWCPJ1ijCPR2seLXLffApNtW49Dw2BoD
	LErYQuVa/zNeeX7XQf0IE7WsKR/BLBdvbeVqEUHVfs2yvrWZLpvVqjyAR7Tn1SgUg2Im
	c7xd50bd+hLh44rU+Re+qmtRDQPhTnecabVW/Lc9iuRP7NqEiGGdUktHN8Ac4ZL/EB+e
	0AEjWk7L4Ryz7QcLBsut5YQB/PVXZcGRwz1Co/WJ8A2qdVbvUNdZMOVRgfF3OX873wOJ
	zeEHATj6E6gwwgfPCLcUfGs9UtYQ7ybEt+1lljeUsueI1y3/61h/Suele1slV1UhQ3Hl
	zTQQ==
MIME-Version: 1.0
Received: by 10.220.220.203 with SMTP id hz11mr1021697vcb.50.1350495331478;
	Wed, 17 Oct 2012 10:35:31 -0700 (PDT)
Received: by 10.58.231.138 with HTTP; Wed, 17 Oct 2012 10:35:31 -0700 (PDT)
In-Reply-To: 
References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default>
	<20581.55931.246130.308384@mariner.uk.xensource.com>
	<8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default>
	<20121002091017.GA95926@ocelot.phlegethon.org>
	<66cc0085-1216-40f7-8059-eaf615202c12@default>
	<20121002201624.GA98445@ocelot.phlegethon.org>
	
	<20121004100645.GC38243@ocelot.phlegethon.org>
	<1349345864.650.247.camel@zakaz.uk.xensource.com>
	<239799F4-AF29-494F-86D2-ADF45ACA8792@gridcentric.ca>
	<3e5cf0ba-4241-4f00-bef6-aaff2cc23419@default>
	<506EC710.3020606@eu.citrix.com>
	<58b5a25d-ccdd-4d0c-a0d9-9c249825f7f1@default>
	
	
Date: Wed, 17 Oct 2012 18:35:31 +0100
X-Google-Sender-Auth: p614_h1hqw3rhbtuKq0A-juA2Ck
Message-ID: 
From: George Dunlap 
To: Dan Magenheimer 
Cc: Olaf Hering , "Keir \(Xen.org\)" ,
	Ian Campbell ,
	Konrad Wilk ,
	Andres Lagar-Cavilla ,
	"Tim \(Xen.org\)" , xen-devel@lists.xen.org,
	George Shuklin ,
	Dario Faggioli , Kurt Hackel ,
	Ian Jackson 
Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and
	xl)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 17, 2012 at 6:30 PM, George Dunlap
 wrote:
> A VM should be given a
> fixed amount of memory above which the balloon driver cannot go.

I forgot to mention: there is a limit you can set in the hypervisor
such that the balloon driver cannot go up past a certain point.  And
since 4.1, I think, it has been possible to set this limit to below
what the VM currently has alloated -- the effect being, that as soon
as the VM balloons down to that point, it cannot balloon back up.
Xapi sets this value at the same time it sets the balloon target in
xenstore, so that it can have confidence that once it actually has
some free memory, it won't disappear from under its feet.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 17:35:45 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 17:35:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOXWq-0003hR-DL; Wed, 17 Oct 2012 17:35:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOXWo-0003gs-28
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 17:35:34 +0000
Received: from [85.158.139.211:64862] by server-1.bemta-5.messagelabs.com id
	E6/BA-21640-56CEE705; Wed, 17 Oct 2012 17:35:33 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1350495331!22726722!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2990 invoked from network); 17 Oct 2012 17:35:32 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 17:35:32 -0000
Received: by mail-vb0-f45.google.com with SMTP id p1so9382837vbi.32
	for ; Wed, 17 Oct 2012 10:35:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=5liOa4wbTKU6NrnJXDTGKGGqOIPj5W3wG/L/bue9RnA=;
	b=DKm+olCdNrYAv5LHFKbYSaq1omz04esXJhFWCPJ1ijCPR2seLXLffApNtW49Dw2BoD
	LErYQuVa/zNeeX7XQf0IE7WsKR/BLBdvbeVqEUHVfs2yvrWZLpvVqjyAR7Tn1SgUg2Im
	c7xd50bd+hLh44rU+Re+qmtRDQPhTnecabVW/Lc9iuRP7NqEiGGdUktHN8Ac4ZL/EB+e
	0AEjWk7L4Ryz7QcLBsut5YQB/PVXZcGRwz1Co/WJ8A2qdVbvUNdZMOVRgfF3OX873wOJ
	zeEHATj6E6gwwgfPCLcUfGs9UtYQ7ybEt+1lljeUsueI1y3/61h/Suele1slV1UhQ3Hl
	zTQQ==
MIME-Version: 1.0
Received: by 10.220.220.203 with SMTP id hz11mr1021697vcb.50.1350495331478;
	Wed, 17 Oct 2012 10:35:31 -0700 (PDT)
Received: by 10.58.231.138 with HTTP; Wed, 17 Oct 2012 10:35:31 -0700 (PDT)
In-Reply-To: 
References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default>
	<20581.55931.246130.308384@mariner.uk.xensource.com>
	<8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default>
	<20121002091017.GA95926@ocelot.phlegethon.org>
	<66cc0085-1216-40f7-8059-eaf615202c12@default>
	<20121002201624.GA98445@ocelot.phlegethon.org>
	
	<20121004100645.GC38243@ocelot.phlegethon.org>
	<1349345864.650.247.camel@zakaz.uk.xensource.com>
	<239799F4-AF29-494F-86D2-ADF45ACA8792@gridcentric.ca>
	<3e5cf0ba-4241-4f00-bef6-aaff2cc23419@default>
	<506EC710.3020606@eu.citrix.com>
	<58b5a25d-ccdd-4d0c-a0d9-9c249825f7f1@default>
	
	
Date: Wed, 17 Oct 2012 18:35:31 +0100
X-Google-Sender-Auth: p614_h1hqw3rhbtuKq0A-juA2Ck
Message-ID: 
From: George Dunlap 
To: Dan Magenheimer 
Cc: Olaf Hering , "Keir \(Xen.org\)" ,
	Ian Campbell ,
	Konrad Wilk ,
	Andres Lagar-Cavilla ,
	"Tim \(Xen.org\)" , xen-devel@lists.xen.org,
	George Shuklin ,
	Dario Faggioli , Kurt Hackel ,
	Ian Jackson 
Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and
	xl)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 17, 2012 at 6:30 PM, George Dunlap
 wrote:
> A VM should be given a
> fixed amount of memory above which the balloon driver cannot go.

I forgot to mention: there is a limit you can set in the hypervisor
such that the balloon driver cannot go up past a certain point.  And
since 4.1, I think, it has been possible to set this limit to below
what the VM currently has alloated -- the effect being, that as soon
as the VM balloons down to that point, it cannot balloon back up.
Xapi sets this value at the same time it sets the balloon target in
xenstore, so that it can have confidence that once it actually has
some free memory, it won't disappear from under its feet.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 17:36:22 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 17:36:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOXXL-0003od-S9; Wed, 17 Oct 2012 17:36:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOXXK-0003oJ-Tl
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 17:36:07 +0000
Received: from [193.109.254.147:5907] by server-12.bemta-14.messagelabs.com id
	7F/1D-13558-68CEE705; Wed, 17 Oct 2012 17:36:06 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1350495365!5244888!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16174 invoked from network); 17 Oct 2012 17:36:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 17:36:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,602,1344211200"; d="scan'208";a="15234082"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 17:36:05 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 17 Oct 2012 18:36:05 +0100
Date: Wed, 17 Oct 2012 18:35:42 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1350463157-5068-8-git-send-email-ian.campbell@citrix.com>
Message-ID: 
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
	<1350463157-5068-8-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	"xen-devel@lists.xen.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 08/10] xen: balloon: don't include e820.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 17 Oct 2012, Ian Campbell wrote:
> This breaks on !X86 and AFAICT is not required on X86 either.
> 
> Signed-off-by: Ian Campbell 

Acked-by: Stefano Stabellini 


>  drivers/xen/balloon.c |    1 -
>  1 files changed, 0 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> index 31ab82f..d7bd1b3 100644
> --- a/drivers/xen/balloon.c
> +++ b/drivers/xen/balloon.c
> @@ -55,7 +55,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  
>  #include 
>  #include 
> -- 
> 1.7.2.5
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 17:36:22 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 17:36:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOXXL-0003od-S9; Wed, 17 Oct 2012 17:36:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOXXK-0003oJ-Tl
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 17:36:07 +0000
Received: from [193.109.254.147:5907] by server-12.bemta-14.messagelabs.com id
	7F/1D-13558-68CEE705; Wed, 17 Oct 2012 17:36:06 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1350495365!5244888!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16174 invoked from network); 17 Oct 2012 17:36:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 17:36:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,602,1344211200"; d="scan'208";a="15234082"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 17:36:05 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 17 Oct 2012 18:36:05 +0100
Date: Wed, 17 Oct 2012 18:35:42 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1350463157-5068-8-git-send-email-ian.campbell@citrix.com>
Message-ID: 
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
	<1350463157-5068-8-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	"xen-devel@lists.xen.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 08/10] xen: balloon: don't include e820.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 17 Oct 2012, Ian Campbell wrote:
> This breaks on !X86 and AFAICT is not required on X86 either.
> 
> Signed-off-by: Ian Campbell 

Acked-by: Stefano Stabellini 


>  drivers/xen/balloon.c |    1 -
>  1 files changed, 0 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> index 31ab82f..d7bd1b3 100644
> --- a/drivers/xen/balloon.c
> +++ b/drivers/xen/balloon.c
> @@ -55,7 +55,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  
>  #include 
>  #include 
> -- 
> 1.7.2.5
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 17:45:12 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 17:45:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOXfx-0004Es-0B; Wed, 17 Oct 2012 17:45:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOXfv-0004En-Kc
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 17:44:59 +0000
Received: from [85.158.143.99:30762] by server-3.bemta-4.messagelabs.com id
	30/95-03544-A9EEE705; Wed, 17 Oct 2012 17:44:58 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1350495897!34180189!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODA5NzQy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7307 invoked from network); 17 Oct 2012 17:44:58 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Oct 2012 17:44:58 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9HHiqSP011010
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Oct 2012 17:44:52 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9HHipBU025688
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Oct 2012 17:44:51 GMT
Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9HHioWE018250; Wed, 17 Oct 2012 12:44:50 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 10:44:50 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id C00434035B; Wed, 17 Oct 2012 13:32:49 -0400 (EDT)
Date: Wed, 17 Oct 2012 13:32:49 -0400
From: Konrad Rzeszutek Wilk 
To: Stefano Stabellini 
Message-ID: <20121017173249.GA25260@phenom.dumpdata.com>
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
	<1350463157-5068-9-git-send-email-ian.campbell@citrix.com>
	
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 09/10] xen: balloon: use correct type for
	frame_list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 17, 2012 at 06:28:35PM +0100, Stefano Stabellini wrote:
> On Wed, 17 Oct 2012, Ian Campbell wrote:
> > This is now a xen_pfn_t.
> > 
> > Signed-off-by: Ian Campbell 
> > ---
> >  drivers/xen/balloon.c |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> > index d7bd1b3..d6886d9 100644
> > --- a/drivers/xen/balloon.c
> > +++ b/drivers/xen/balloon.c
> > @@ -87,7 +87,7 @@ struct balloon_stats balloon_stats;
> >  EXPORT_SYMBOL_GPL(balloon_stats);
> >  
> >  /* We increase/decrease in batches which fit in a page */
> > -static unsigned long frame_list[PAGE_SIZE / sizeof(unsigned long)];
> > +static xen_pfn_t frame_list[PAGE_SIZE / sizeof(unsigned long)];
> >  
> >  #ifdef CONFIG_HIGHMEM
> >  #define inc_totalhigh_pages() (totalhigh_pages++)
> 
> I know that we agreed to this change but it still gives me the creeps.
> I would love a comment either in the code or in the commit message,
> explaining why it is safe to pass a xen_pfn_t (potentially 64 bit) to 
> set_phys_to_machine.


I applied all the patches in this patchset except this one. Will
apply once a new version is out.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 17:45:12 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 17:45:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOXfx-0004Es-0B; Wed, 17 Oct 2012 17:45:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOXfv-0004En-Kc
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 17:44:59 +0000
Received: from [85.158.143.99:30762] by server-3.bemta-4.messagelabs.com id
	30/95-03544-A9EEE705; Wed, 17 Oct 2012 17:44:58 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1350495897!34180189!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODA5NzQy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7307 invoked from network); 17 Oct 2012 17:44:58 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Oct 2012 17:44:58 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9HHiqSP011010
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Oct 2012 17:44:52 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9HHipBU025688
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Oct 2012 17:44:51 GMT
Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9HHioWE018250; Wed, 17 Oct 2012 12:44:50 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 10:44:50 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id C00434035B; Wed, 17 Oct 2012 13:32:49 -0400 (EDT)
Date: Wed, 17 Oct 2012 13:32:49 -0400
From: Konrad Rzeszutek Wilk 
To: Stefano Stabellini 
Message-ID: <20121017173249.GA25260@phenom.dumpdata.com>
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
	<1350463157-5068-9-git-send-email-ian.campbell@citrix.com>
	
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 09/10] xen: balloon: use correct type for
	frame_list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 17, 2012 at 06:28:35PM +0100, Stefano Stabellini wrote:
> On Wed, 17 Oct 2012, Ian Campbell wrote:
> > This is now a xen_pfn_t.
> > 
> > Signed-off-by: Ian Campbell 
> > ---
> >  drivers/xen/balloon.c |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> > index d7bd1b3..d6886d9 100644
> > --- a/drivers/xen/balloon.c
> > +++ b/drivers/xen/balloon.c
> > @@ -87,7 +87,7 @@ struct balloon_stats balloon_stats;
> >  EXPORT_SYMBOL_GPL(balloon_stats);
> >  
> >  /* We increase/decrease in batches which fit in a page */
> > -static unsigned long frame_list[PAGE_SIZE / sizeof(unsigned long)];
> > +static xen_pfn_t frame_list[PAGE_SIZE / sizeof(unsigned long)];
> >  
> >  #ifdef CONFIG_HIGHMEM
> >  #define inc_totalhigh_pages() (totalhigh_pages++)
> 
> I know that we agreed to this change but it still gives me the creeps.
> I would love a comment either in the code or in the commit message,
> explaining why it is safe to pass a xen_pfn_t (potentially 64 bit) to 
> set_phys_to_machine.


I applied all the patches in this patchset except this one. Will
apply once a new version is out.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 17:46:28 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 17:46:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOXhD-0004Kg-2Y; Wed, 17 Oct 2012 17:46:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOXhB-0004KG-5n
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 17:46:17 +0000
Received: from [85.158.143.35:62303] by server-1.bemta-4.messagelabs.com id
	DB/01-19134-8EEEE705; Wed, 17 Oct 2012 17:46:16 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1350495969!12666564!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12763 invoked from network); 17 Oct 2012 17:46:11 -0000
Received: from mail-ia0-f171.google.com (HELO mail-ia0-f171.google.com)
	(209.85.210.171)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 17:46:11 -0000
Received: by mail-ia0-f171.google.com with SMTP id u21so6848334ial.30
	for ;
	Wed, 17 Oct 2012 10:46:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=SmCyJn7GEDYYABMvsfwnHiAeUg+dyKPcRo9KiNWG0k4=;
	b=rfaMtOf3/mvgYEOGNlUhSFA/TxkfyEuPVIt9OtlFgkpdky5ZlEWohPbImYszvqGyEK
	Bv4JW7coYhB2I5tyAiXKt2hnb8uK1MfpTKntBBY71oRAIZyt/lDsOeHrHKmBEtxbaekU
	Fk5dXO3Mmw/F3cOMVewx9x4jr8scOC4OKJLjfmQSxc4jrBOfYhOgKgsfVG2tpIBEeRCA
	tihZnte6dCuSLbIpi75P504AgGQppz16sxuAFM2oA1LKRBmpBuYNZBz1EOMBQJB+PCB6
	rrhjZJPH+W65yPpnXR7Ap/7X1Gztcma3wcvuTy7e96l+8d7x9pVXuD275x4aoVpv4Z0Y
	gPPg==
MIME-Version: 1.0
Received: by 10.50.91.168 with SMTP id cf8mr2391057igb.20.1350495969378; Wed,
	17 Oct 2012 10:46:09 -0700 (PDT)
Received: by 10.231.193.227 with HTTP; Wed, 17 Oct 2012 10:46:09 -0700 (PDT)
In-Reply-To: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
Date: Wed, 17 Oct 2012 13:46:09 -0400
X-Google-Sender-Auth: SG_uQSjC_o_t5S2ce64EWBDJkgI
Message-ID: 
From: Ben Guthro 
To: Konrad Rzeszutek Wilk 
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, hpa@zytor.com, lenb@kernel.org
Subject: Re: [Xen-devel] [RFC] ACPI S3 and Xen (suprisingly small\!).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 17, 2012 at 9:49 AM, Konrad Rzeszutek Wilk
 wrote:
[...]

> The end result is this is a nice set of patches where there is only
> _one_ change in the x86 code (and it is just more of dealing with
> error case) - and the rest are all done in Xen side.

I'm sorry to report that this series doesn't seem to work in my setup
against xen-unstable.

To verify that it was, in fact this patch series, and not another Xen
regression - I swapped out the kernel with this patch series, with an
identical one, replacing only this series with your acpi-s3.v9 branch
- and everything worked fine.

serial capture from bad run pasted below.



(XEN) Xen version 4.3-unstable (bguthro@) (gcc (Ubuntu/Linaro
4.6.3-1ubuntu5) 4.6.3) Wed Oct 17 08:53:46 EDT 2012
(XEN) Latest ChangeSet: unavailable
(XEN) Bootloader: GRUB 1.99-21ubuntu3+orc1
(XEN) Command line: com1=115200,8n1,pci console=com1
dom0_mem=auto:620M^30M cpufreq=xen cpuidle e820-verbose=1
dom0_vcpus_pin
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN) Disc information:
(XEN)  Found 1 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) Initial Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009ac00 (usable)
(XEN)  000000000009ac00 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 0000000020000000 (usable)
(XEN)  0000000020000000 - 0000000020200000 (reserved)
(XEN)  0000000020200000 - 0000000040004000 (usable)
(XEN)  0000000040004000 - 0000000040005000 (reserved)
(XEN)  0000000040005000 - 00000000a8584000 (usable)
(XEN)  00000000a8584000 - 00000000a85c7000 (reserved)
(XEN)  00000000a85c7000 - 00000000aa58a000 (usable)
(XEN)  00000000aa58a000 - 00000000aad6a000 (reserved)
(XEN)  00000000aad6a000 - 00000000aafea000 (ACPI NVS)
(XEN)  00000000aafea000 - 00000000aafff000 (ACPI data)
(XEN)  00000000aafff000 - 00000000ab000000 (usable)
(XEN)  0000000100000000 - 000000014e600000 (usable)
(XEN)  00000000ab000000 - 00000000afa00000 (reserved)
(XEN)  00000000f8000000 - 00000000fc000000 (reserved)
(XEN)  00000000fec00000 - 00000000fec01000 (reserved)
(XEN)  00000000fed10000 - 00000000fed14000 (reserved)
(XEN)  00000000fed18000 - 00000000fed1a000 (reserved)
(XEN)  00000000fed1c000 - 00000000fed20000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000ff900000 - 00000000ffc00000 (reserved)
(XEN)  00000000ffd00000 - 0000000100000000 (reserved)
(XEN) Checking MTRR ranges...
(XEN)  MTRR cap: d0a type: c00
(XEN)  MTRR[0]: base 6 mask f80000800
(XEN)  MTRR[1]: base 80000006 mask fe0000800
(XEN)  MTRR[2]: base a0000006 mask ff8000800
(XEN)  MTRR[3]: base a8000006 mask ffe000800
(XEN)  MTRR[4]: base aa000006 mask fff000800
(XEN)  MTRR[5]: base 100000006 mask fc0000800
(XEN)  MTRR[6]: base 140000006 mask ff0000800
(XEN)  MTRR[7]: base 14f000000 mask fff000800
(XEN)  MTRR[8]: base 14e800000 mask fff800800
(XEN)  MTRR[9]: base 14e600000 mask fffe00800
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009ac00 (usable)
(XEN)  000000000009ac00 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 0000000020000000 (usable)
(XEN)  0000000020000000 - 0000000020200000 (reserved)
(XEN)  0000000020200000 - 0000000040004000 (usable)
(XEN)  0000000040004000 - 0000000040005000 (reserved)
(XEN)  0000000040005000 - 00000000a8584000 (usable)
(XEN)  00000000a8584000 - 00000000a85c7000 (reserved)
(XEN)  00000000a85c7000 - 00000000aa58a000 (usable)
(XEN)  00000000aa58a000 - 00000000aad6a000 (reserved)
(XEN)  00000000aad6a000 - 00000000aafea000 (ACPI NVS)
(XEN)  00000000aafea000 - 00000000aafff000 (ACPI data)
(XEN)  00000000aafff000 - 00000000ab000000 (usable)
(XEN)  00000000ab000000 - 00000000afa00000 (reserved)
(XEN)  00000000f8000000 - 00000000fc000000 (reserved)
(XEN)  00000000fec00000 - 00000000fec01000 (reserved)
(XEN)  00000000fed10000 - 00000000fed14000 (reserved)
(XEN)  00000000fed18000 - 00000000fed1a000 (reserved)
(XEN)  00000000fed1c000 - 00000000fed20000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000ff900000 - 00000000ffc00000 (reserved)
(XEN)  00000000ffd00000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 000000014e600000 (usable)
(XEN) ACPI: RSDP 000F0410, 0024 (r2  INTEL)
(XEN) ACPI: XSDT AAFFDE18, 0074 (r1  INTEL  IVB-CPT  6222004 MSFT    10013)
(XEN) ACPI: FACP AAFE3D98, 00F4 (r4  INTEL  IVB-CPT  6222004 MSFT    10013)
(XEN) ACPI: DSDT AAFBC018, 1082F (r2  INTEL  IVB-CPT        0 INTL 20110623)
(XEN) ACPI: FACS AAFE9E40, 0040
(XEN) ACPI: APIC AAFFCF18, 00CC (r2  INTEL  IVB-CPT  6222004 MSFT    10013)
(XEN) ACPI: HPET AAFE8F18, 0038 (r1 A M I   PCHHPET  6222004 AMI.        3)
(XEN) ACPI: SSDT AAFE5018, 10A8 (r1 TrmRef PtidDevc     1000 INTL 20110623)
(XEN) ACPI: SSDT AAFE4A18, 0461 (r1    AMI PerfTune     1000 INTL 20110623)
(XEN) ACPI: MCFG AAFE8E98, 003C (r1 INTEL  SNDYBRDG  6222004 MSFT       97)
(XEN) ACPI: SSDT AAFD1818, 079A (r1  PmRef  Cpu0Ist     3000 INTL 20110623)
(XEN) ACPI: SSDT AAFD0018, 0A92 (r1  PmRef    CpuPm     3000 INTL 20110623)
(XEN) ACPI: DMAR AAFE4F18, 00B8 (r1 INTEL      SNB         1 INTL        1)
(XEN) ACPI: FPDT AAFF4018, 0064 (r1  INTEL  IVB-CPT    10000 INTL 20111107)
(XEN) System RAM: 3976MB (4072324kB)
(XEN) No NUMA configuration found
(XEN) Faking a node at 0000000000000000-000000014e600000
(XEN) Domain heap initialised
(XEN) found SMP MP-table at 000fcaa0
(XEN) DMI 2.6 present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x408
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[404,0], pm1x_evt[400,0]
(XEN) ACPI: 32/64X FACS address mismatch in FADT -
aafe9e40/0000000000000000, using 32
(XEN) ACPI:                  wakeup_vec[aafe9e4c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) Processor #0 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
(XEN) Processor #2 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
(XEN) Processor #4 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled)
(XEN) Processor #6 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x04] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x05] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x06] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x07] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x09] lapic_id[0x08] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x09] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x0a] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x0b] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x0c] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x0d] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x0e] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x10] lapic_id[0x0f] disabled)
(XEN) ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by override.
(XEN) ACPI: IRQ9 used by override.
(XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
(XEN) ACPI: HPET id: 0x8086a701 base: 0xfed00000
(XEN) Table is not found!
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) SMP: Allowing 16 CPUs (12 hotplug CPUs)
(XEN) IRQ limits: 24 GSI, 760 MSI/MSI-X
(XEN) Switched to APIC driver x2apic_cluster.
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2195.065 MHz processor.
(XEN) Initing memory sharing.
(XEN) mce_intel.c:721: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank
0 extended MCE MSR 0
(XEN) Intel machine check reporting enabled
(XEN) PCI: MCFG configuration 0: base f8000000 segment 0000 buses 00 - 3f
(XEN) PCI: MCFG area at f8000000 reserved in E820
(XEN) PCI: Using MCFG for segment 0000 bus 00-3f
(XEN) Intel VT-d supported page sizes: 4kB.
(XEN) Intel VT-d supported page sizes: 4kB.
(XEN) Intel VT-d Snoop Control not enabled.
(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
(XEN) Intel VT-d Queued Invalidation enabled.
(XEN) Intel VT-d Interrupt Remapping enabled.
(XEN) Intel VT-d Shared EPT tables not enabled.
(XEN) I/O virtualisation enabled
(XEN)  - Dom0 mode: Relaxed
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using old ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
(XEN) TSC deadline timer enabled
(XEN) Platform timer is 14.318MHz HPET
(XEN) Allocated console ring of 32 KiB.
(XEN) mwait-idle: MWAIT substates: 0x1120
(XEN) mwait-idle: v0.4 model 0x3a
(XEN) mwait-idle: lapic_timer_reliable_states 0xffffffff
(XEN) VMX: Supported advanced features:
(XEN)  - APIC MMIO access virtualisation
(XEN)  - APIC TPR shadow
(XEN)  - Extended Page Tables (EPT)
(XEN)  - Virtual-Processor Identifiers (VPID)
(XEN)  - Virtual NMI
(XEN)  - MSR direct-access bitmap
(XEN)  - Unrestricted Guest
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging (HAP) detected
(XEN) HVM: HAP page sizes: 4kB, 2MB
(XEN) microcode: collect_cpu_info : sig=0x306a4, pf=0x2, rev=0x7
(XEN) microcode: collect_cpu_info : sig=0x306a4, pf=0x2, rev=0x7
(XEN) Brought up 4 CPUs
(XEN) microcode: collect_cpu_info : sig=0x306a4, pf=0x2, rev=0x7
(XEN) ACPI sleep modes: S3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) *** LOADING DOMAIN 0 ***
(XEN) elf_parse_binary: phdr: paddr=0x1000000 memsz=0x8a2000
(XEN) elf_parse_binary: phdr: paddr=0x1a00000 memsz=0xb30f0
(XEN) elf_parse_binary: phdr: paddr=0x1ab4000 memsz=0x14600
(XEN) elf_parse_binary: phdr: paddr=0x1ac9000 memsz=0x62b000
(XEN) elf_parse_binary: memory: 0x1000000 -> 0x20f4000
(XEN) elf_xen_parse_note: GUEST_OS = "linux"
(XEN) elf_xen_parse_note: GUEST_VERSION = "2.6"
(XEN) elf_xen_parse_note: XEN_VERSION = "xen-3.0"
(XEN) elf_xen_parse_note: VIRT_BASE = 0xffffffff80000000
(XEN) elf_xen_parse_note: ENTRY = 0xffffffff81ac9210
(XEN) elf_xen_parse_note: HYPERCALL_PAGE = 0xffffffff81001000
(XEN) elf_xen_parse_note: FEATURES = "!writable_page_tables|pae_pgdir_above_4gb"
(XEN) elf_xen_parse_note: PAE_MODE = "yes"
(XEN) elf_xen_parse_note: LOADER = "generic"
(XEN) elf_xen_parse_note: unknown xen elf note (0xd)
(XEN) elf_xen_parse_note: SUSPEND_CANCEL = 0x1
(XEN) elf_xen_parse_note: HV_START_LOW = 0xffff800000000000
(XEN) elf_xen_parse_note: PADDR_OFFSET = 0x0
(XEN) elf_xen_addr_calc_check: addresses:
(XEN)     virt_base        = 0xffffffff80000000
(XEN)     elf_paddr_offset = 0x0
(XEN)     virt_offset      = 0xffffffff80000000
(XEN)     virt_kstart      = 0xffffffff81000000
(XEN)     virt_kend        = 0xffffffff820f4000
(XEN)     virt_entry       = 0xffffffff81ac9210
(XEN)     p2m_base         = 0xffffffffffffffff
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x20f4000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000140000000->0000000144000000 (161339 pages
to be allocated)
(XEN)  Init. ramdisk: 000000014bd49000->000000014e5ffc00
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff81000000->ffffffff820f4000
(XEN)  Init. ramdisk: ffffffff820f4000->ffffffff849aac00
(XEN)  Phys-Mach map: ffffffff849ab000->ffffffff84b1a790
(XEN)  Start info:    ffffffff84b1b000->ffffffff84b1b4b4
(XEN)  Page tables:   ffffffff84b1c000->ffffffff84b45000
(XEN)  Boot stack:    ffffffff84b45000->ffffffff84b46000
(XEN)  TOTAL:         ffffffff80000000->ffffffff84c00000
(XEN)  ENTRY ADDRESS: ffffffff81ac9210
(XEN) Dom0 has maximum 4 VCPUs
(XEN) elf_load_binary: phdr 0 at 0xffffffff81000000 -> 0xffffffff818a2000
(XEN) elf_load_binary: phdr 1 at 0xffffffff81a00000 -> 0xffffffff81ab30f0
(XEN) elf_load_binary: phdr 2 at 0xffffffff81ab4000 -> 0xffffffff81ac8600
(XEN) elf_load_binary: phdr 3 at 0xffffffff81ac9000 -> 0xffffffff81b9a000
(XEN) Scrubbing Free RAM: ................................done.
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
input to Xen)
(XEN) Freed 268kB init memory.
mapping kernel into physical memory
about to get started...
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.7.0-orc (bguthro@bguthro-desktop) (gcc
version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #7 SMP Wed Oct 17
13:02:38 EDT 2012
[    0.000000] Command line:
root=/dev/mapper/NxVG--eb56f027--0aeb--4e9a--9233--678d57b9dc9e-NxDisk6
ro xencons=tty console=hvc0
[    0.000000] Freeing 9a-100 pfn range: 102 pages freed
[    0.000000] Freeing 20000-20200 pfn range: 512 pages freed
[    0.000000] Released 614 pages of unused memory
[    0.000000] Set 351519 page(s) to 1-1 mapping
[    0.000000] Populating 2def2-2e158 pfn range: 614 pages added
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] Xen: [mem 0x0000000000000000-0x0000000000099fff] usable
[    0.000000] Xen: [mem 0x000000000009ac00-0x00000000000fffff] reserved
[    0.000000] Xen: [mem 0x0000000000100000-0x000000001fffffff] usable
[    0.000000] Xen: [mem 0x0000000020000000-0x00000000201fffff] reserved
[    0.000000] Xen: [mem 0x0000000020200000-0x000000002e157fff] usable
[    0.000000] Xen: [mem 0x000000002e158000-0x0000000040003fff] unusable
[    0.000000] Xen: [mem 0x0000000040004000-0x0000000040004fff] reserved
[    0.000000] Xen: [mem 0x0000000040005000-0x00000000a8583fff] unusable
[    0.000000] Xen: [mem 0x00000000a8584000-0x00000000a85c6fff] reserved
[    0.000000] Xen: [mem 0x00000000a85c7000-0x00000000aa589fff] unusable
[    0.000000] Xen: [mem 0x00000000aa58a000-0x00000000aad69fff] reserved
[    0.000000] Xen: [mem 0x00000000aad6a000-0x00000000aafe9fff] ACPI NVS
[    0.000000] Xen: [mem 0x00000000aafea000-0x00000000aaffefff] ACPI data
[    0.000000] Xen: [mem 0x00000000aafff000-0x00000000aaffffff] unusable
[    0.000000] Xen: [mem 0x00000000ab000000-0x00000000af9fffff] reserved
[    0.000000] Xen: [mem 0x00000000f8000000-0x00000000fbffffff] reserved
[    0.000000] Xen: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
[    0.000000] Xen: [mem 0x00000000fed10000-0x00000000fed13fff] reserved
[    0.000000] Xen: [mem 0x00000000fed18000-0x00000000fed19fff] reserved
[    0.000000] Xen: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved
[    0.000000] Xen: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
[    0.000000] Xen: [mem 0x00000000ff900000-0x00000000ffbfffff] reserved
[    0.000000] Xen: [mem 0x00000000ffd00000-0x00000000ffffffff] reserved
[    0.000000] Xen: [mem 0x0000000100000000-0x000000014e5fffff] unusable
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI 2.6 present.
[    0.000000] No AGP bridge found
[    0.000000] e820: last_pfn = 0x2e158 max_arch_pfn = 0x400000000
[    0.000000] x2apic enabled by BIOS, switching to x2apic ops
[    0.000000] init_memory_mapping: [mem 0x00000000-0x2e157fff]
[    0.000000] RAMDISK: [mem 0x020f4000-0x049aafff]
[    0.000000] ACPI: RSDP 00000000000f0410 00024 (v02  INTEL)
[    0.000000] ACPI: XSDT 00000000aaffde18 00074 (v01  INTEL  IVB-CPT
06222004 MSFT 00010013)
[    0.000000] ACPI: FACP 00000000aafe3d98 000F4 (v04  INTEL  IVB-CPT
06222004 MSFT 00010013)
[    0.000000] ACPI: DSDT 00000000aafbc018 1082F (v02  INTEL  IVB-CPT
00000000 INTL 20110623)
[    0.000000] ACPI: FACS 00000000aafe9e40 00040
[    0.000000] ACPI: APIC 00000000aaffcf18 000CC (v02  INTEL  IVB-CPT
06222004 MSFT 00010013)
[    0.000000] ACPI: HPET 00000000aafe8f18 00038 (v01 A M I   PCHHPET
06222004 AMI. 00000003)
[    0.000000] ACPI: SSDT 00000000aafe5018 010A8 (v01 TrmRef PtidDevc
00001000 INTL 20110623)
[    0.000000] ACPI: SSDT 00000000aafe4a18 00461 (v01    AMI PerfTune
00001000 INTL 20110623)
[    0.000000] ACPI: MCFG 00000000aafe8e98 0003C (v01 INTEL  SNDYBRDG
06222004 MSFT 00000097)
[    0.000000] ACPI: SSDT 00000000aafd1818 0079A (v01  PmRef  Cpu0Ist
00003000 INTL 20110623)
[    0.000000] ACPI: SSDT 00000000aafd0018 00A92 (v01  PmRef    CpuPm
00003000 INTL 20110623)
[    0.000000] ACPI: XMAR 00000000aafe4f18 000B8 (v01 INTEL      SNB
00000001 INTL 00000001)
[    0.000000] ACPI: FPDT 00000000aaff4018 00064 (v01  INTEL  IVB-CPT
00010000 INTL 20111107)
[    0.000000] Setting APIC routing to cluster x2apic.
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x00010000-0x00ffffff]
[    0.000000]   DMA32    [mem 0x01000000-0xffffffff]
[    0.000000]   Normal   empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x00010000-0x00099fff]
[    0.000000]   node   0: [mem 0x00100000-0x1fffffff]
[    0.000000]   node   0: [mem 0x20200000-0x2e157fff]
[    0.000000] ACPI: PM-Timer IO Port: 0x408
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x04] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x05] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x06] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x07] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x08] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x09] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x0a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x0b] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x0c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x0d] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x0e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x10] lapic_id[0x0f] disabled)
[    0.000000] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
[    0.000000] smpboot: Allowing 16 CPUs, 12 hotplug CPUs
[    0.000000] PM: Registered nosave memory: 000000000009a000 - 000000000009b000
[    0.000000] PM: Registered nosave memory: 000000000009b000 - 0000000000100000
[    0.000000] PM: Registered nosave memory: 0000000020000000 - 0000000020200000
[    0.000000] e820: [mem 0xafa00000-0xf7ffffff] available for PCI devices
[    0.000000] Booting paravirtualized kernel on Xen
[    0.000000] Xen version: 4.3-unstable (preserve-AD)
[    0.000000] setup_percpu: NR_CPUS:64 nr_cpumask_bits:64
nr_cpu_ids:16 nr_node_ids:1
[    0.000000] PERCPU: Embedded 28 pages/cpu @ffff88002da00000 s83456
r8192 d23040 u131072
[    1.854461] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 185174
[    1.854464] Kernel command line:
root=/dev/mapper/NxVG--eb56f027--0aeb--4e9a--9233--678d57b9dc9e-NxDisk6
ro xencons=tty console=hvc0
[    1.854903] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    1.854969] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
[    1.855248] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
[    1.855369] __ex_table already sorted, skipping sort
[    1.884622] software IO TLB [mem 0x28c00000-0x2cbfffff] (64MB)
mapped at [ffff880028c00000-ffff88002cbfffff]
[    1.886801] Memory: 612908k/755040k available (5817k kernel code,
2520k absent, 139612k reserved, 5136k data, 896k init)
[    1.886877] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0,
CPUs=4, Nodes=1
[    1.886905] Hierarchical RCU implementation.
[    1.886906] 	RCU dyntick-idle grace-period acceleration is enabled.
[    1.886907] 	RCU restricting CPUs from NR_CPUS=64 to nr_cpu_ids=4.
[    1.886916] NR_IRQS:4352 nr_irqs:712 16
[    1.886989] xen: sci override: global_irq=9 trigger=0 polarity=0
[    1.887024] xen: acpi sci 9
[    1.888406] Console: colour VGA+ 80x25
[    1.888704] console [hvc0] enabled
[    1.888728] installing Xen timer for CPU 0
[    1.888755] tsc: Detected 2195.064 MHz processor
[    1.888761] Calibrating delay loop (skipped), value calculated
using timer frequency.. 4390.12 BogoMIPS (lpj=21950640)
[    1.888768] pid_max: default: 32768 minimum: 301
[    1.888860] Mount-cache hash table entries: 256
[    1.889088] Initializing cgroup subsys cpuacct
[    1.889093] Initializing cgroup subsys devices
[    1.889096] Initializing cgroup subsys freezer
[    1.889100] Initializing cgroup subsys net_cls
[    1.889168] ENERGY_PERF_BIAS: Set to 'normal', was 'performance'
[    1.889168] ENERGY_PERF_BIAS: View and update with x86_energy_perf_policy(8)
[    1.889177] CPU: Physical Processor ID: 0
[    1.889179] CPU: Processor Core ID: 0
[    1.889591] mce: CPU supports 2 MCE banks
(XEN) traps.c:2485:d0 Domain attempted WRMSR 000000000000082f from
0x00000000000000f2 to 0x00000000000000f9.
[    1.889624] Last level iTLB entries: 4KB 512, 2MB 0, 4MB 0
[    1.889624] Last level dTLB entries: 4KB 512, 2MB 32, 4MB 32
[    1.889624] tlb_flushall_shift: 1
[    1.889739] Freeing SMP alternatives: 20k freed
[    1.891834] ACPI: Core revision 20120913
[    1.908378] ftrace: allocating 21833 entries in 86 pages
[    1.919224] cpu 0 spinlock event irq 41
[    1.919242] Performance Events: unsupported p6 CPU model 58 no PMU
driver, software events only.
[    1.920070] installing Xen timer for CPU 1
[    1.920082] cpu 1 spinlock event irq 48
(XEN) traps.c:2485:d0 Domain attempted WRMSR 000000000000082f from
0x00000000000000f2 to 0x00000000000000f9.
[    1.920805] installing Xen timer for CPU 2
[    1.920815] cpu 2 spinlock event irq 55
(XEN) traps.c:2485:d0 Domain attempted WRMSR 000000000000082f from
0x00000000000000f2 to 0x00000000000000f9.
[    1.921556] installing Xen timer for CPU 3
[    1.921566] cpu 3 spinlock event irq 62
(XEN) traps.c:2485:d0 Domain attempted WRMSR 000000000000082f from
0x00000000000000f2 to 0x00000000000000f9.
[    1.922256] Brought up 4 CPUs
[    1.922685] devtmpfs: initialized
[    1.922949] PM: Registering ACPI NVS region [mem
0xaad6a000-0xaafe9fff] (2621440 bytes)
[    1.923631] Grant tables using version 2 layout.
[    1.923646] Grant table initialized
[    1.923694] regulator-dummy: no parameters
[    1.923742] RTC time: 17:32:37, date: 10/17/12
[    1.923777] NET: Registered protocol family 16
[    1.924024] ACPI FADT declares the system doesn't support PCIe
ASPM, so disable it
[    1.924030] ACPI: bus type pci registered
[    1.924147] PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem
0xf8000000-0xfbffffff] (base 0xf8000000)
[    1.924153] PCI: MMCONFIG at [mem 0xf8000000-0xfbffffff] reserved in E820
[    1.937145] PCI: Using configuration type 1 for base access
[    1.937864] bio: create slab  at 0
[    1.937979] ACPI: Added _OSI(Module Device)
[    1.937983] ACPI: Added _OSI(Processor Device)
[    1.937986] ACPI: Added _OSI(3.0 _SCP Extensions)
[    1.937990] ACPI: Added _OSI(Processor Aggregator Device)
[    1.943414] ACPI: Executed 1 blocks of module-level executable AML code
[    1.961910] ACPI: SSDT 00000000aaccd018 00A4F (v01  PmRef  Cpu0Cst
00003001 INTL 20110623)
[    1.962563] ACPI: Dynamic OEM Table Load:
[    1.962568] ACPI: SSDT           (null) 00A4F (v01  PmRef  Cpu0Cst
00003001 INTL 20110623)
[    2.001604] ACPI: SSDT 00000000aaccea98 00303 (v01  PmRef    ApIst
00003000 INTL 20110623)
[    2.002283] ACPI: Dynamic OEM Table Load:
[    2.002287] ACPI: SSDT           (null) 00303 (v01  PmRef    ApIst
00003000 INTL 20110623)
[    2.041649] ACPI: SSDT 00000000aacccd98 00119 (v01  PmRef    ApCst
00003000 INTL 20110623)
[    2.042297] ACPI: Dynamic OEM Table Load:
[    2.042302] ACPI: SSDT           (null) 00119 (v01  PmRef    ApCst
00003000 INTL 20110623)
[    2.082598] ACPI: Interpreter enabled
[    2.082605] ACPI: (supports S0 S1 S3 S4 S5)
[    2.082631] ACPI: Using IOAPIC for interrupt routing
[    2.088693] ACPI: Power Resource [FN00] (off)
[    2.088768] ACPI: Power Resource [FN01] (off)
[    2.088848] ACPI: Power Resource [FN02] (off)
[    2.088921] ACPI: Power Resource [FN03] (off)
[    2.088992] ACPI: Power Resource [FN04] (off)
[    2.089894] ACPI: ACPI Dock Station Driver: 1 docks/bays found
[    2.089901] PCI: Using host bridge windows from ACPI; if necessary,
use "pci=nocrs" and report a bug
[    2.090503] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-3e])
[    2.091264] PCI host bridge to bus 0000:00
[    2.091269] pci_bus 0000:00: root bus resource [bus 00-3e]
[    2.091273] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7]
[    2.091277] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
[    2.091281] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
[    2.091285] pci_bus 0000:00: root bus resource [mem 0x000d0000-0x000d3fff]
[    2.091289] pci_bus 0000:00: root bus resource [mem 0x000d4000-0x000d7fff]
[    2.091293] pci_bus 0000:00: root bus resource [mem 0x000d8000-0x000dbfff]
[    2.091297] pci_bus 0000:00: root bus resource [mem 0x000dc000-0x000dffff]
[    2.091301] pci_bus 0000:00: root bus resource [mem 0x000e0000-0x000e3fff]
[    2.091305] pci_bus 0000:00: root bus resource [mem 0x000e4000-0x000e7fff]
[    2.091309] pci_bus 0000:00: root bus resource [mem 0xafa00000-0xfeafffff]
[    2.095857] pci 0000:00:1c.0: PCI bridge to [bus 01]
[    2.096587] pci 0000:00:1c.6: PCI bridge to [bus 02]
[    2.097102] pci 0000:00:1c.7: PCI bridge to [bus 03-04]
[    2.097749] pci 0000:03:00.0: PCI bridge to [bus 04]
[    2.098158] pci 0000:00:1e.0: PCI bridge to [bus 05] (subtractive decode)
[    2.098677]  pci0000:00: ACPI _OSC support notification failed,
disabling PCIe ASPM
[    2.098682]  pci0000:00: Unable to request _OSC control (_OSC
support mask: 0x08)
(XEN) PCI add device 0000:00:00.0
(XEN) PCI add device 0000:00:02.0
(XEN) PCI add device 0000:00:14.0
(XEN) PCI add device 0000:00:16.0
(XEN) PCI add device 0000:00:16.3
(XEN) PCI add device 0000:00:19.0
(XEN) PCI add device 0000:00:1a.0
(XEN) PCI add device 0000:00:1b.0
(XEN) PCI add device 0000:00:1c.0
(XEN) PCI add device 0000:00:1c.6
(XEN) PCI add device 0000:00:1c.7
(XEN) PCI add device 0000:00:1d.0
(XEN) PCI add device 0000:00:1e.0
(XEN) PCI add device 0000:00:1f.0
(XEN) PCI add device 0000:00:1f.2
(XEN) PCI add device 0000:00:1f.3
(XEN) PCI add device 0000:02:00.0
(XEN) PCI add device 0000:03:00.0
(XEN) PCI add device 0000:04:00.0
(XEN) PCI add device 0000:05:01.0
[    2.104211] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 10 *11 12 14 15)
[    2.104279] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 10 11 12
14 15) *0, disabled.
[    2.104348] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 *4 5 6 10 11 12 14 15)
[    2.104414] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 *10 11 12 14 15)
[    2.104480] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 *5 6 10 11 12 14 15)
[    2.104544] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 10 11 12
14 15) *0, disabled.
[    2.104612] ACPI: PCI Interrupt Link [LNKG] (IRQs *3 4 5 6 10 11 12 14 15)
[    2.104676] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 10 *11 12 14 15)
[    2.104716] xen/balloon: Initialising balloon driver.
[    2.104855] vgaarb: device added:
PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none
[    2.104869] vgaarb: loaded
[    2.104871] vgaarb: bridge control possible 0000:00:02.0
[    2.104950] SCSI subsystem initialized
[    2.104954] ACPI: bus type scsi registered
[    2.105131] ACPI: bus type usb registered
[    2.105151] usbcore: registered new interface driver usbfs
[    2.105162] usbcore: registered new interface driver hub
[    2.105304] usbcore: registered new device driver usb
[    2.105513] wmi: Mapper loaded
[    2.105519] PCI: Using ACPI for IRQ routing
[    2.111086] Switching to clocksource xen
[    2.116428] pnp: PnP ACPI init
[    2.116439] ACPI: bus type pnp registered
[    2.117207] system 00:05: [io  0x0680-0x069f] has been reserved
[    2.117212] system 00:05: [io  0x1000-0x100f] has been reserved
[    2.117216] system 00:05: [io  0xffff] has been reserved
[    2.117219] system 00:05: [io  0xffff] has been reserved
[    2.117223] system 00:05: [io  0x0400-0x0453] has been reserved
[    2.117227] system 00:05: [io  0x0458-0x047f] has been reserved
[    2.117231] system 00:05: [io  0x0500-0x057f] has been reserved
[    2.117235] system 00:05: [io  0x164e-0x164f] has been reserved
[    2.117330] system 00:07: [io  0x0454-0x0457] has been reserved
[    2.117721] system 00:08: [mem 0xfed1c000-0xfed1ffff] has been reserved
[    2.117726] system 00:08: [mem 0xfed10000-0xfed17fff] could not be reserved
[    2.117730] system 00:08: [mem 0xfed18000-0xfed18fff] has been reserved
[    2.117735] system 00:08: [mem 0xfed19000-0xfed19fff] has been reserved
[    2.117739] system 00:08: [mem 0xf8000000-0xfbffffff] has been reserved
[    2.117743] system 00:08: [mem 0xfed20000-0xfed3ffff] has been reserved
[    2.117748] system 00:08: [mem 0xfed90000-0xfed93fff] has been reserved
[    2.117753] system 00:08: [mem 0xfed45000-0xfed8ffff] has been reserved
[    2.117757] system 00:08: [mem 0xff000000-0xffffffff] could not be reserved
[    2.117762] system 00:08: [mem 0xfee00000-0xfeefffff] could not be reserved
[    2.117766] system[    3.281195] usb 3-3: new low-speed USB device
number 2 using xhci_hcd
[    3.282603] bio: create slab  at 1
[    3.304654] usb 3-3: ep 0x81 - rounding interval to 64 microframes,
ep desc says 80 microframes
[    3.311353] usbcore: registered new interface driver usbhid
[    3.311360] usbhid: USB HID core driver
[    3.421244] usb 3-4: new low-speed USB device number 3 using xhci_hcd
Begin: Running /scripts/local-premount ... [    3.448335] usb 3-4: ep
0x81 - rounding interval to 128 microframes, ep desc says 192
microframes
done.
[    3.523331] EXT4-fs (dm-3): mounted filesystem with ordered data
mode. Opts: (null)
Begin: Running /scripts/local-bottom ... done.
done.
Begin: Running /scripts/init-bottom ... udevd[290]:
inotify_add_watch(6, /dev/dm-6, 10) failed: Invalid argument

done.
(XEN) microcode: collect_cpu_info : sig=0x306a4, pf=0x2, rev=0x7
(XEN) microcode: collect_cpu_info : sig=0x306a4, pf=0x2, rev=0x7
(XEN) microcode: collect_cpu_info : sig=0x306a4, pf=0x2, rev=0x7
(XEN) microcode: collect_cpu_info : sig=0x306a4, pf=0x2, rev=0x7

NxTop Engine (99.99.pre-121017-1309-bguthro) poison-ivy hvc0

poison-ivy login: root (automatic login)
Last login: Wed Oct 17 17:27:26 UTC 2012 from
bguthro-desktop.oldroadcomputing.net on pts/8
Welcome to NxTop Engine (GNU/Linux 3.7.0-orc x86_64)

root@poison-ivy:~#
root@poison-ivy:~#
root@poison-ivy:~# [   13.645342] irq 22: nobody cared (try booting
with the "irqpoll" option)
[   13.645442] handlers:
[   13.645446] [] serial8250_interrupt
[   13.645449] Disabling IRQ #22

root@poison-ivy:~#
root@poison-ivy:~#
root@poison-ivy:~# [   26.153266] irq 22: nobody cared (try booting
with the "irqpoll" option)
[   26.153341] handlers:
[   26.153345] [] serial8250_interrupt
[   26.153349] Disabling IRQ #22
(XEN) Preparing system for ACPI S3 state.
(XEN) Disabling non-boot CPUs ...
(XEN) Breaking vcpu affinity for domain 0 vcpu 2
(XEN) Breaking vcpu affinity for domain 0 vcpu 3
(XEN) Entering ACPI S3 state.
(XEN) mce_intel.c:721: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank
0 extended MCE MSR 0
(XEN) CPU0 CMCI LVT vector (0xf2) already installed
(XEN) Finishing wakeup from ACPI S3 state.
(XEN) microcode: collect_cpu_info : sig=0x306a4, pf=0x2, rev=0x7
(XEN) Enabling non-boot CPUs  ...
(XEN) microcode: collect_cpu_info : sig=0x306a4, pf=0x2, rev=0x7
(XEN) microcode: collect_cpu_info : sig=0x306a4, pf=0x2, rev=0x7
(XEN) microcode: collect_cpu_info : sig=0x306a4, pf=0x2, rev=0x7
(XEN) mm.c:587:d0 Could not get page ref for pfn ffffffffffffffff
(XEN) mm.c:2571:d0 Error while installing new baseptr ffffffffffffffff
(XEN) mm.c:2265:d0 Bad type (saw 4400000000000001 != exp
7000000000000000) for mfn 13db97 (pfn 26eb2)
(XEN) mm.c:812:d0 Could not get page type PGT_writable_page
(XEN) mm.c:864:d0 Error getting mfn 13db97 (pfn 26eb2) from L1 entry
800000013db97063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:2265:d0 Bad type (saw 3400000000000002 != exp
7000000000000000) for mfn 13edc4 (pfn 28085)
(XEN) mm.c:812:d0 Could not get page type PGT_writable_page
(XEN) mm.c:864:d0 Error getting mfn 13edc4 (pfn 28085) from L1 entry
800000013edc4063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:2265:d0 Bad type (saw 2400000000000001 != exp
7000000000000000) for mfn 13e625 (pfn 27c24)
(XEN) mm.c:812:d0 Could not get page type PGT_writable_page
(XEN) mm.c:864:d0 Error getting mfn 13e625 (pfn 27c24) from L1 entry
800000013e625063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:2265:d0 Bad type (saw 1400000000000001 != exp
7000000000000000) for mfn 13e886 (pfn 27dc3)
(XEN) mm.c:812:d0 Could not get page type PGT_writable_page
(XEN) mm.c:864:d0 Error getting mfn 13e886 (pfn 27dc3) from L1 entry
800000013e886063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:2265:d0 Bad type (saw 1400000000000001 != exp
7000000000000000) for mfn 13ebfa (pfn 27e4f)
(XEN) mm.c:812:d0 Could not get page type PGT_writable_page
(XEN) mm.c:864:d0 Error getting mfn 13ebfa (pfn 27e4f) from L1 entry
800000013ebfa063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:2265:d0 Bad type (saw 1400000000000001 != exp
7000000000000000) for mfn 14d52f (pfn 38da)
(XEN) mm.c:812:d0 Could not get page type PGT_writable_page
(XEN) mm.c:864:d0 Error getting mfn 14d52f (pfn 38da) from L1 entry
800000014d52f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:2265:d0 Bad type (saw 3400000000000002 != exp
7000000000000000) for mfn 13e5a1 (pfn 278a8)
(XEN) mm.c:812:d0 Could not get page type PGT_writable_page
(XEN) mm.c:864:d0 Error getting mfn 13e5a1 (pfn 278a8) from L1 entry
800000013e5a1063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:2265:d0 Bad type (saw 2400000000000001 != exp
7000000000000000) for mfn 14dba6 (pfn 3f51)
(XEN) mm.c:812:d0 Could not get page type PGT_writable_page
(XEN) mm.c:864:d0 Error getting mfn 14dba6 (pfn 3f51) from L1 entry
800000014dba6063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:2265:d0 Bad type (saw 1400000000000001 != exp
7000000000000000) for mfn 13da86 (pfn 26fc3)
(XEN) mm.c:812:d0 Could not get page type PGT_writable_page
(XEN) mm.c:864:d0 Error getting mfn 13da86 (pfn 26fc3) from L1 entry
800000013da86063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:2265:d0 Bad type (saw 1400000000000001 != exp
7000000000000000) for mfn 14d50a (pfn 38b5)
(XEN) mm.c:812:d0 Could not get page type PGT_writable_page
(XEN) mm.c:864:d0 Error getting mfn 14d50a (pfn 38b5) from L1 entry
800000014d50a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:2265:d0 Bad type (saw 1400000000000001 != exp
7000000000000000) for mfn 14d0a7 (pfn 3452)
(XEN) mm.c:812:d0 Could not get page type PGT_writable_page
(XEN) mm.c:864:d0 Error getting mfn 14d0a7 (pfn 3452) from L1 entry
800000014d0a7063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:2265:d0 Bad type (saw 1400000000000001 != exp
7000000000000000) for mfn 14d6e7 (pfn 3a92)
(XEN) mm.c:812:d0 Could not get page type PGT_writable_page
(XEN) mm.c:864:d0 Error getting mfn 14d6e7 (pfn 3a92) from L1 entry
800000014d6e7063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:2265:d0 Bad type (saw 3400000000000002 != exp
7000000000000000) for mfn 14dafd (pfn 3ea8)
(XEN) mm.c:812:d0 Could not get page type PGT_writable_page
(XEN) mm.c:864:d0 Error getting mfn 14dafd (pfn 3ea8) from L1 entry
800000014dafd063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:2265:d0 Bad type (saw 2400000000000001 != exp
7000000000000000) for mfn 13d598 (pfn 268b1)
(XEN) mm.c:812:d0 Could not get page type PGT_writable_page
(XEN) mm.c:864:d0 Error getting mfn 13d598 (pfn 268b1) from L1 entry
800000013d598063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:2265:d0 Bad type (saw 1400000000000001 != exp
7000000000000000) for mfn 13daa1 (pfn 26fa8)
(XEN) mm.c:812:d0 Could not get page type PGT_writable_page
(XEN) mm.c:864:d0 Error getting mfn 13daa1 (pfn 26fa8) from L1 entry
800000013daa1063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:2265:d0 Bad type (saw 4400000000000001 != exp
7000000000000000) for mfn 14d0d5 (pfn 3480)
(XEN) mm.c:812:d0 Could not get page type PGT_writable_page
(XEN) mm.c:864:d0 Error getting mfn 14d0d5 (pfn 3480) from L1 entry
800000014d0d5063 for l1e_owner=0, pg_owner=0

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 17:46:28 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 17:46:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOXhD-0004Kg-2Y; Wed, 17 Oct 2012 17:46:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOXhB-0004KG-5n
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 17:46:17 +0000
Received: from [85.158.143.35:62303] by server-1.bemta-4.messagelabs.com id
	DB/01-19134-8EEEE705; Wed, 17 Oct 2012 17:46:16 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1350495969!12666564!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12763 invoked from network); 17 Oct 2012 17:46:11 -0000
Received: from mail-ia0-f171.google.com (HELO mail-ia0-f171.google.com)
	(209.85.210.171)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 17:46:11 -0000
Received: by mail-ia0-f171.google.com with SMTP id u21so6848334ial.30
	for ;
	Wed, 17 Oct 2012 10:46:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=SmCyJn7GEDYYABMvsfwnHiAeUg+dyKPcRo9KiNWG0k4=;
	b=rfaMtOf3/mvgYEOGNlUhSFA/TxkfyEuPVIt9OtlFgkpdky5ZlEWohPbImYszvqGyEK
	Bv4JW7coYhB2I5tyAiXKt2hnb8uK1MfpTKntBBY71oRAIZyt/lDsOeHrHKmBEtxbaekU
	Fk5dXO3Mmw/F3cOMVewx9x4jr8scOC4OKJLjfmQSxc4jrBOfYhOgKgsfVG2tpIBEeRCA
	tihZnte6dCuSLbIpi75P504AgGQppz16sxuAFM2oA1LKRBmpBuYNZBz1EOMBQJB+PCB6
	rrhjZJPH+W65yPpnXR7Ap/7X1Gztcma3wcvuTy7e96l+8d7x9pVXuD275x4aoVpv4Z0Y
	gPPg==
MIME-Version: 1.0
Received: by 10.50.91.168 with SMTP id cf8mr2391057igb.20.1350495969378; Wed,
	17 Oct 2012 10:46:09 -0700 (PDT)
Received: by 10.231.193.227 with HTTP; Wed, 17 Oct 2012 10:46:09 -0700 (PDT)
In-Reply-To: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
Date: Wed, 17 Oct 2012 13:46:09 -0400
X-Google-Sender-Auth: SG_uQSjC_o_t5S2ce64EWBDJkgI
Message-ID: 
From: Ben Guthro 
To: Konrad Rzeszutek Wilk 
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, hpa@zytor.com, lenb@kernel.org
Subject: Re: [Xen-devel] [RFC] ACPI S3 and Xen (suprisingly small\!).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 17, 2012 at 9:49 AM, Konrad Rzeszutek Wilk
 wrote:
[...]

> The end result is this is a nice set of patches where there is only
> _one_ change in the x86 code (and it is just more of dealing with
> error case) - and the rest are all done in Xen side.

I'm sorry to report that this series doesn't seem to work in my setup
against xen-unstable.

To verify that it was, in fact this patch series, and not another Xen
regression - I swapped out the kernel with this patch series, with an
identical one, replacing only this series with your acpi-s3.v9 branch
- and everything worked fine.

serial capture from bad run pasted below.



(XEN) Xen version 4.3-unstable (bguthro@) (gcc (Ubuntu/Linaro
4.6.3-1ubuntu5) 4.6.3) Wed Oct 17 08:53:46 EDT 2012
(XEN) Latest ChangeSet: unavailable
(XEN) Bootloader: GRUB 1.99-21ubuntu3+orc1
(XEN) Command line: com1=115200,8n1,pci console=com1
dom0_mem=auto:620M^30M cpufreq=xen cpuidle e820-verbose=1
dom0_vcpus_pin
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN) Disc information:
(XEN)  Found 1 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) Initial Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009ac00 (usable)
(XEN)  000000000009ac00 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 0000000020000000 (usable)
(XEN)  0000000020000000 - 0000000020200000 (reserved)
(XEN)  0000000020200000 - 0000000040004000 (usable)
(XEN)  0000000040004000 - 0000000040005000 (reserved)
(XEN)  0000000040005000 - 00000000a8584000 (usable)
(XEN)  00000000a8584000 - 00000000a85c7000 (reserved)
(XEN)  00000000a85c7000 - 00000000aa58a000 (usable)
(XEN)  00000000aa58a000 - 00000000aad6a000 (reserved)
(XEN)  00000000aad6a000 - 00000000aafea000 (ACPI NVS)
(XEN)  00000000aafea000 - 00000000aafff000 (ACPI data)
(XEN)  00000000aafff000 - 00000000ab000000 (usable)
(XEN)  0000000100000000 - 000000014e600000 (usable)
(XEN)  00000000ab000000 - 00000000afa00000 (reserved)
(XEN)  00000000f8000000 - 00000000fc000000 (reserved)
(XEN)  00000000fec00000 - 00000000fec01000 (reserved)
(XEN)  00000000fed10000 - 00000000fed14000 (reserved)
(XEN)  00000000fed18000 - 00000000fed1a000 (reserved)
(XEN)  00000000fed1c000 - 00000000fed20000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000ff900000 - 00000000ffc00000 (reserved)
(XEN)  00000000ffd00000 - 0000000100000000 (reserved)
(XEN) Checking MTRR ranges...
(XEN)  MTRR cap: d0a type: c00
(XEN)  MTRR[0]: base 6 mask f80000800
(XEN)  MTRR[1]: base 80000006 mask fe0000800
(XEN)  MTRR[2]: base a0000006 mask ff8000800
(XEN)  MTRR[3]: base a8000006 mask ffe000800
(XEN)  MTRR[4]: base aa000006 mask fff000800
(XEN)  MTRR[5]: base 100000006 mask fc0000800
(XEN)  MTRR[6]: base 140000006 mask ff0000800
(XEN)  MTRR[7]: base 14f000000 mask fff000800
(XEN)  MTRR[8]: base 14e800000 mask fff800800
(XEN)  MTRR[9]: base 14e600000 mask fffe00800
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009ac00 (usable)
(XEN)  000000000009ac00 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 0000000020000000 (usable)
(XEN)  0000000020000000 - 0000000020200000 (reserved)
(XEN)  0000000020200000 - 0000000040004000 (usable)
(XEN)  0000000040004000 - 0000000040005000 (reserved)
(XEN)  0000000040005000 - 00000000a8584000 (usable)
(XEN)  00000000a8584000 - 00000000a85c7000 (reserved)
(XEN)  00000000a85c7000 - 00000000aa58a000 (usable)
(XEN)  00000000aa58a000 - 00000000aad6a000 (reserved)
(XEN)  00000000aad6a000 - 00000000aafea000 (ACPI NVS)
(XEN)  00000000aafea000 - 00000000aafff000 (ACPI data)
(XEN)  00000000aafff000 - 00000000ab000000 (usable)
(XEN)  00000000ab000000 - 00000000afa00000 (reserved)
(XEN)  00000000f8000000 - 00000000fc000000 (reserved)
(XEN)  00000000fec00000 - 00000000fec01000 (reserved)
(XEN)  00000000fed10000 - 00000000fed14000 (reserved)
(XEN)  00000000fed18000 - 00000000fed1a000 (reserved)
(XEN)  00000000fed1c000 - 00000000fed20000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000ff900000 - 00000000ffc00000 (reserved)
(XEN)  00000000ffd00000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 000000014e600000 (usable)
(XEN) ACPI: RSDP 000F0410, 0024 (r2  INTEL)
(XEN) ACPI: XSDT AAFFDE18, 0074 (r1  INTEL  IVB-CPT  6222004 MSFT    10013)
(XEN) ACPI: FACP AAFE3D98, 00F4 (r4  INTEL  IVB-CPT  6222004 MSFT    10013)
(XEN) ACPI: DSDT AAFBC018, 1082F (r2  INTEL  IVB-CPT        0 INTL 20110623)
(XEN) ACPI: FACS AAFE9E40, 0040
(XEN) ACPI: APIC AAFFCF18, 00CC (r2  INTEL  IVB-CPT  6222004 MSFT    10013)
(XEN) ACPI: HPET AAFE8F18, 0038 (r1 A M I   PCHHPET  6222004 AMI.        3)
(XEN) ACPI: SSDT AAFE5018, 10A8 (r1 TrmRef PtidDevc     1000 INTL 20110623)
(XEN) ACPI: SSDT AAFE4A18, 0461 (r1    AMI PerfTune     1000 INTL 20110623)
(XEN) ACPI: MCFG AAFE8E98, 003C (r1 INTEL  SNDYBRDG  6222004 MSFT       97)
(XEN) ACPI: SSDT AAFD1818, 079A (r1  PmRef  Cpu0Ist     3000 INTL 20110623)
(XEN) ACPI: SSDT AAFD0018, 0A92 (r1  PmRef    CpuPm     3000 INTL 20110623)
(XEN) ACPI: DMAR AAFE4F18, 00B8 (r1 INTEL      SNB         1 INTL        1)
(XEN) ACPI: FPDT AAFF4018, 0064 (r1  INTEL  IVB-CPT    10000 INTL 20111107)
(XEN) System RAM: 3976MB (4072324kB)
(XEN) No NUMA configuration found
(XEN) Faking a node at 0000000000000000-000000014e600000
(XEN) Domain heap initialised
(XEN) found SMP MP-table at 000fcaa0
(XEN) DMI 2.6 present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x408
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[404,0], pm1x_evt[400,0]
(XEN) ACPI: 32/64X FACS address mismatch in FADT -
aafe9e40/0000000000000000, using 32
(XEN) ACPI:                  wakeup_vec[aafe9e4c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) Processor #0 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
(XEN) Processor #2 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
(XEN) Processor #4 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled)
(XEN) Processor #6 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x04] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x05] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x06] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x07] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x09] lapic_id[0x08] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x09] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x0a] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x0b] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x0c] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x0d] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x0e] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x10] lapic_id[0x0f] disabled)
(XEN) ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by override.
(XEN) ACPI: IRQ9 used by override.
(XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
(XEN) ACPI: HPET id: 0x8086a701 base: 0xfed00000
(XEN) Table is not found!
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) SMP: Allowing 16 CPUs (12 hotplug CPUs)
(XEN) IRQ limits: 24 GSI, 760 MSI/MSI-X
(XEN) Switched to APIC driver x2apic_cluster.
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2195.065 MHz processor.
(XEN) Initing memory sharing.
(XEN) mce_intel.c:721: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank
0 extended MCE MSR 0
(XEN) Intel machine check reporting enabled
(XEN) PCI: MCFG configuration 0: base f8000000 segment 0000 buses 00 - 3f
(XEN) PCI: MCFG area at f8000000 reserved in E820
(XEN) PCI: Using MCFG for segment 0000 bus 00-3f
(XEN) Intel VT-d supported page sizes: 4kB.
(XEN) Intel VT-d supported page sizes: 4kB.
(XEN) Intel VT-d Snoop Control not enabled.
(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
(XEN) Intel VT-d Queued Invalidation enabled.
(XEN) Intel VT-d Interrupt Remapping enabled.
(XEN) Intel VT-d Shared EPT tables not enabled.
(XEN) I/O virtualisation enabled
(XEN)  - Dom0 mode: Relaxed
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using old ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
(XEN) TSC deadline timer enabled
(XEN) Platform timer is 14.318MHz HPET
(XEN) Allocated console ring of 32 KiB.
(XEN) mwait-idle: MWAIT substates: 0x1120
(XEN) mwait-idle: v0.4 model 0x3a
(XEN) mwait-idle: lapic_timer_reliable_states 0xffffffff
(XEN) VMX: Supported advanced features:
(XEN)  - APIC MMIO access virtualisation
(XEN)  - APIC TPR shadow
(XEN)  - Extended Page Tables (EPT)
(XEN)  - Virtual-Processor Identifiers (VPID)
(XEN)  - Virtual NMI
(XEN)  - MSR direct-access bitmap
(XEN)  - Unrestricted Guest
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging (HAP) detected
(XEN) HVM: HAP page sizes: 4kB, 2MB
(XEN) microcode: collect_cpu_info : sig=0x306a4, pf=0x2, rev=0x7
(XEN) microcode: collect_cpu_info : sig=0x306a4, pf=0x2, rev=0x7
(XEN) Brought up 4 CPUs
(XEN) microcode: collect_cpu_info : sig=0x306a4, pf=0x2, rev=0x7
(XEN) ACPI sleep modes: S3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) *** LOADING DOMAIN 0 ***
(XEN) elf_parse_binary: phdr: paddr=0x1000000 memsz=0x8a2000
(XEN) elf_parse_binary: phdr: paddr=0x1a00000 memsz=0xb30f0
(XEN) elf_parse_binary: phdr: paddr=0x1ab4000 memsz=0x14600
(XEN) elf_parse_binary: phdr: paddr=0x1ac9000 memsz=0x62b000
(XEN) elf_parse_binary: memory: 0x1000000 -> 0x20f4000
(XEN) elf_xen_parse_note: GUEST_OS = "linux"
(XEN) elf_xen_parse_note: GUEST_VERSION = "2.6"
(XEN) elf_xen_parse_note: XEN_VERSION = "xen-3.0"
(XEN) elf_xen_parse_note: VIRT_BASE = 0xffffffff80000000
(XEN) elf_xen_parse_note: ENTRY = 0xffffffff81ac9210
(XEN) elf_xen_parse_note: HYPERCALL_PAGE = 0xffffffff81001000
(XEN) elf_xen_parse_note: FEATURES = "!writable_page_tables|pae_pgdir_above_4gb"
(XEN) elf_xen_parse_note: PAE_MODE = "yes"
(XEN) elf_xen_parse_note: LOADER = "generic"
(XEN) elf_xen_parse_note: unknown xen elf note (0xd)
(XEN) elf_xen_parse_note: SUSPEND_CANCEL = 0x1
(XEN) elf_xen_parse_note: HV_START_LOW = 0xffff800000000000
(XEN) elf_xen_parse_note: PADDR_OFFSET = 0x0
(XEN) elf_xen_addr_calc_check: addresses:
(XEN)     virt_base        = 0xffffffff80000000
(XEN)     elf_paddr_offset = 0x0
(XEN)     virt_offset      = 0xffffffff80000000
(XEN)     virt_kstart      = 0xffffffff81000000
(XEN)     virt_kend        = 0xffffffff820f4000
(XEN)     virt_entry       = 0xffffffff81ac9210
(XEN)     p2m_base         = 0xffffffffffffffff
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x20f4000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000140000000->0000000144000000 (161339 pages
to be allocated)
(XEN)  Init. ramdisk: 000000014bd49000->000000014e5ffc00
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff81000000->ffffffff820f4000
(XEN)  Init. ramdisk: ffffffff820f4000->ffffffff849aac00
(XEN)  Phys-Mach map: ffffffff849ab000->ffffffff84b1a790
(XEN)  Start info:    ffffffff84b1b000->ffffffff84b1b4b4
(XEN)  Page tables:   ffffffff84b1c000->ffffffff84b45000
(XEN)  Boot stack:    ffffffff84b45000->ffffffff84b46000
(XEN)  TOTAL:         ffffffff80000000->ffffffff84c00000
(XEN)  ENTRY ADDRESS: ffffffff81ac9210
(XEN) Dom0 has maximum 4 VCPUs
(XEN) elf_load_binary: phdr 0 at 0xffffffff81000000 -> 0xffffffff818a2000
(XEN) elf_load_binary: phdr 1 at 0xffffffff81a00000 -> 0xffffffff81ab30f0
(XEN) elf_load_binary: phdr 2 at 0xffffffff81ab4000 -> 0xffffffff81ac8600
(XEN) elf_load_binary: phdr 3 at 0xffffffff81ac9000 -> 0xffffffff81b9a000
(XEN) Scrubbing Free RAM: ................................done.
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
input to Xen)
(XEN) Freed 268kB init memory.
mapping kernel into physical memory
about to get started...
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.7.0-orc (bguthro@bguthro-desktop) (gcc
version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #7 SMP Wed Oct 17
13:02:38 EDT 2012
[    0.000000] Command line:
root=/dev/mapper/NxVG--eb56f027--0aeb--4e9a--9233--678d57b9dc9e-NxDisk6
ro xencons=tty console=hvc0
[    0.000000] Freeing 9a-100 pfn range: 102 pages freed
[    0.000000] Freeing 20000-20200 pfn range: 512 pages freed
[    0.000000] Released 614 pages of unused memory
[    0.000000] Set 351519 page(s) to 1-1 mapping
[    0.000000] Populating 2def2-2e158 pfn range: 614 pages added
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] Xen: [mem 0x0000000000000000-0x0000000000099fff] usable
[    0.000000] Xen: [mem 0x000000000009ac00-0x00000000000fffff] reserved
[    0.000000] Xen: [mem 0x0000000000100000-0x000000001fffffff] usable
[    0.000000] Xen: [mem 0x0000000020000000-0x00000000201fffff] reserved
[    0.000000] Xen: [mem 0x0000000020200000-0x000000002e157fff] usable
[    0.000000] Xen: [mem 0x000000002e158000-0x0000000040003fff] unusable
[    0.000000] Xen: [mem 0x0000000040004000-0x0000000040004fff] reserved
[    0.000000] Xen: [mem 0x0000000040005000-0x00000000a8583fff] unusable
[    0.000000] Xen: [mem 0x00000000a8584000-0x00000000a85c6fff] reserved
[    0.000000] Xen: [mem 0x00000000a85c7000-0x00000000aa589fff] unusable
[    0.000000] Xen: [mem 0x00000000aa58a000-0x00000000aad69fff] reserved
[    0.000000] Xen: [mem 0x00000000aad6a000-0x00000000aafe9fff] ACPI NVS
[    0.000000] Xen: [mem 0x00000000aafea000-0x00000000aaffefff] ACPI data
[    0.000000] Xen: [mem 0x00000000aafff000-0x00000000aaffffff] unusable
[    0.000000] Xen: [mem 0x00000000ab000000-0x00000000af9fffff] reserved
[    0.000000] Xen: [mem 0x00000000f8000000-0x00000000fbffffff] reserved
[    0.000000] Xen: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
[    0.000000] Xen: [mem 0x00000000fed10000-0x00000000fed13fff] reserved
[    0.000000] Xen: [mem 0x00000000fed18000-0x00000000fed19fff] reserved
[    0.000000] Xen: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved
[    0.000000] Xen: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
[    0.000000] Xen: [mem 0x00000000ff900000-0x00000000ffbfffff] reserved
[    0.000000] Xen: [mem 0x00000000ffd00000-0x00000000ffffffff] reserved
[    0.000000] Xen: [mem 0x0000000100000000-0x000000014e5fffff] unusable
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI 2.6 present.
[    0.000000] No AGP bridge found
[    0.000000] e820: last_pfn = 0x2e158 max_arch_pfn = 0x400000000
[    0.000000] x2apic enabled by BIOS, switching to x2apic ops
[    0.000000] init_memory_mapping: [mem 0x00000000-0x2e157fff]
[    0.000000] RAMDISK: [mem 0x020f4000-0x049aafff]
[    0.000000] ACPI: RSDP 00000000000f0410 00024 (v02  INTEL)
[    0.000000] ACPI: XSDT 00000000aaffde18 00074 (v01  INTEL  IVB-CPT
06222004 MSFT 00010013)
[    0.000000] ACPI: FACP 00000000aafe3d98 000F4 (v04  INTEL  IVB-CPT
06222004 MSFT 00010013)
[    0.000000] ACPI: DSDT 00000000aafbc018 1082F (v02  INTEL  IVB-CPT
00000000 INTL 20110623)
[    0.000000] ACPI: FACS 00000000aafe9e40 00040
[    0.000000] ACPI: APIC 00000000aaffcf18 000CC (v02  INTEL  IVB-CPT
06222004 MSFT 00010013)
[    0.000000] ACPI: HPET 00000000aafe8f18 00038 (v01 A M I   PCHHPET
06222004 AMI. 00000003)
[    0.000000] ACPI: SSDT 00000000aafe5018 010A8 (v01 TrmRef PtidDevc
00001000 INTL 20110623)
[    0.000000] ACPI: SSDT 00000000aafe4a18 00461 (v01    AMI PerfTune
00001000 INTL 20110623)
[    0.000000] ACPI: MCFG 00000000aafe8e98 0003C (v01 INTEL  SNDYBRDG
06222004 MSFT 00000097)
[    0.000000] ACPI: SSDT 00000000aafd1818 0079A (v01  PmRef  Cpu0Ist
00003000 INTL 20110623)
[    0.000000] ACPI: SSDT 00000000aafd0018 00A92 (v01  PmRef    CpuPm
00003000 INTL 20110623)
[    0.000000] ACPI: XMAR 00000000aafe4f18 000B8 (v01 INTEL      SNB
00000001 INTL 00000001)
[    0.000000] ACPI: FPDT 00000000aaff4018 00064 (v01  INTEL  IVB-CPT
00010000 INTL 20111107)
[    0.000000] Setting APIC routing to cluster x2apic.
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x00010000-0x00ffffff]
[    0.000000]   DMA32    [mem 0x01000000-0xffffffff]
[    0.000000]   Normal   empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x00010000-0x00099fff]
[    0.000000]   node   0: [mem 0x00100000-0x1fffffff]
[    0.000000]   node   0: [mem 0x20200000-0x2e157fff]
[    0.000000] ACPI: PM-Timer IO Port: 0x408
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x04] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x05] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x06] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x07] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x08] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x09] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x0a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x0b] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x0c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x0d] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x0e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x10] lapic_id[0x0f] disabled)
[    0.000000] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
[    0.000000] smpboot: Allowing 16 CPUs, 12 hotplug CPUs
[    0.000000] PM: Registered nosave memory: 000000000009a000 - 000000000009b000
[    0.000000] PM: Registered nosave memory: 000000000009b000 - 0000000000100000
[    0.000000] PM: Registered nosave memory: 0000000020000000 - 0000000020200000
[    0.000000] e820: [mem 0xafa00000-0xf7ffffff] available for PCI devices
[    0.000000] Booting paravirtualized kernel on Xen
[    0.000000] Xen version: 4.3-unstable (preserve-AD)
[    0.000000] setup_percpu: NR_CPUS:64 nr_cpumask_bits:64
nr_cpu_ids:16 nr_node_ids:1
[    0.000000] PERCPU: Embedded 28 pages/cpu @ffff88002da00000 s83456
r8192 d23040 u131072
[    1.854461] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 185174
[    1.854464] Kernel command line:
root=/dev/mapper/NxVG--eb56f027--0aeb--4e9a--9233--678d57b9dc9e-NxDisk6
ro xencons=tty console=hvc0
[    1.854903] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    1.854969] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
[    1.855248] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
[    1.855369] __ex_table already sorted, skipping sort
[    1.884622] software IO TLB [mem 0x28c00000-0x2cbfffff] (64MB)
mapped at [ffff880028c00000-ffff88002cbfffff]
[    1.886801] Memory: 612908k/755040k available (5817k kernel code,
2520k absent, 139612k reserved, 5136k data, 896k init)
[    1.886877] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0,
CPUs=4, Nodes=1
[    1.886905] Hierarchical RCU implementation.
[    1.886906] 	RCU dyntick-idle grace-period acceleration is enabled.
[    1.886907] 	RCU restricting CPUs from NR_CPUS=64 to nr_cpu_ids=4.
[    1.886916] NR_IRQS:4352 nr_irqs:712 16
[    1.886989] xen: sci override: global_irq=9 trigger=0 polarity=0
[    1.887024] xen: acpi sci 9
[    1.888406] Console: colour VGA+ 80x25
[    1.888704] console [hvc0] enabled
[    1.888728] installing Xen timer for CPU 0
[    1.888755] tsc: Detected 2195.064 MHz processor
[    1.888761] Calibrating delay loop (skipped), value calculated
using timer frequency.. 4390.12 BogoMIPS (lpj=21950640)
[    1.888768] pid_max: default: 32768 minimum: 301
[    1.888860] Mount-cache hash table entries: 256
[    1.889088] Initializing cgroup subsys cpuacct
[    1.889093] Initializing cgroup subsys devices
[    1.889096] Initializing cgroup subsys freezer
[    1.889100] Initializing cgroup subsys net_cls
[    1.889168] ENERGY_PERF_BIAS: Set to 'normal', was 'performance'
[    1.889168] ENERGY_PERF_BIAS: View and update with x86_energy_perf_policy(8)
[    1.889177] CPU: Physical Processor ID: 0
[    1.889179] CPU: Processor Core ID: 0
[    1.889591] mce: CPU supports 2 MCE banks
(XEN) traps.c:2485:d0 Domain attempted WRMSR 000000000000082f from
0x00000000000000f2 to 0x00000000000000f9.
[    1.889624] Last level iTLB entries: 4KB 512, 2MB 0, 4MB 0
[    1.889624] Last level dTLB entries: 4KB 512, 2MB 32, 4MB 32
[    1.889624] tlb_flushall_shift: 1
[    1.889739] Freeing SMP alternatives: 20k freed
[    1.891834] ACPI: Core revision 20120913
[    1.908378] ftrace: allocating 21833 entries in 86 pages
[    1.919224] cpu 0 spinlock event irq 41
[    1.919242] Performance Events: unsupported p6 CPU model 58 no PMU
driver, software events only.
[    1.920070] installing Xen timer for CPU 1
[    1.920082] cpu 1 spinlock event irq 48
(XEN) traps.c:2485:d0 Domain attempted WRMSR 000000000000082f from
0x00000000000000f2 to 0x00000000000000f9.
[    1.920805] installing Xen timer for CPU 2
[    1.920815] cpu 2 spinlock event irq 55
(XEN) traps.c:2485:d0 Domain attempted WRMSR 000000000000082f from
0x00000000000000f2 to 0x00000000000000f9.
[    1.921556] installing Xen timer for CPU 3
[    1.921566] cpu 3 spinlock event irq 62
(XEN) traps.c:2485:d0 Domain attempted WRMSR 000000000000082f from
0x00000000000000f2 to 0x00000000000000f9.
[    1.922256] Brought up 4 CPUs
[    1.922685] devtmpfs: initialized
[    1.922949] PM: Registering ACPI NVS region [mem
0xaad6a000-0xaafe9fff] (2621440 bytes)
[    1.923631] Grant tables using version 2 layout.
[    1.923646] Grant table initialized
[    1.923694] regulator-dummy: no parameters
[    1.923742] RTC time: 17:32:37, date: 10/17/12
[    1.923777] NET: Registered protocol family 16
[    1.924024] ACPI FADT declares the system doesn't support PCIe
ASPM, so disable it
[    1.924030] ACPI: bus type pci registered
[    1.924147] PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem
0xf8000000-0xfbffffff] (base 0xf8000000)
[    1.924153] PCI: MMCONFIG at [mem 0xf8000000-0xfbffffff] reserved in E820
[    1.937145] PCI: Using configuration type 1 for base access
[    1.937864] bio: create slab  at 0
[    1.937979] ACPI: Added _OSI(Module Device)
[    1.937983] ACPI: Added _OSI(Processor Device)
[    1.937986] ACPI: Added _OSI(3.0 _SCP Extensions)
[    1.937990] ACPI: Added _OSI(Processor Aggregator Device)
[    1.943414] ACPI: Executed 1 blocks of module-level executable AML code
[    1.961910] ACPI: SSDT 00000000aaccd018 00A4F (v01  PmRef  Cpu0Cst
00003001 INTL 20110623)
[    1.962563] ACPI: Dynamic OEM Table Load:
[    1.962568] ACPI: SSDT           (null) 00A4F (v01  PmRef  Cpu0Cst
00003001 INTL 20110623)
[    2.001604] ACPI: SSDT 00000000aaccea98 00303 (v01  PmRef    ApIst
00003000 INTL 20110623)
[    2.002283] ACPI: Dynamic OEM Table Load:
[    2.002287] ACPI: SSDT           (null) 00303 (v01  PmRef    ApIst
00003000 INTL 20110623)
[    2.041649] ACPI: SSDT 00000000aacccd98 00119 (v01  PmRef    ApCst
00003000 INTL 20110623)
[    2.042297] ACPI: Dynamic OEM Table Load:
[    2.042302] ACPI: SSDT           (null) 00119 (v01  PmRef    ApCst
00003000 INTL 20110623)
[    2.082598] ACPI: Interpreter enabled
[    2.082605] ACPI: (supports S0 S1 S3 S4 S5)
[    2.082631] ACPI: Using IOAPIC for interrupt routing
[    2.088693] ACPI: Power Resource [FN00] (off)
[    2.088768] ACPI: Power Resource [FN01] (off)
[    2.088848] ACPI: Power Resource [FN02] (off)
[    2.088921] ACPI: Power Resource [FN03] (off)
[    2.088992] ACPI: Power Resource [FN04] (off)
[    2.089894] ACPI: ACPI Dock Station Driver: 1 docks/bays found
[    2.089901] PCI: Using host bridge windows from ACPI; if necessary,
use "pci=nocrs" and report a bug
[    2.090503] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-3e])
[    2.091264] PCI host bridge to bus 0000:00
[    2.091269] pci_bus 0000:00: root bus resource [bus 00-3e]
[    2.091273] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7]
[    2.091277] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
[    2.091281] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
[    2.091285] pci_bus 0000:00: root bus resource [mem 0x000d0000-0x000d3fff]
[    2.091289] pci_bus 0000:00: root bus resource [mem 0x000d4000-0x000d7fff]
[    2.091293] pci_bus 0000:00: root bus resource [mem 0x000d8000-0x000dbfff]
[    2.091297] pci_bus 0000:00: root bus resource [mem 0x000dc000-0x000dffff]
[    2.091301] pci_bus 0000:00: root bus resource [mem 0x000e0000-0x000e3fff]
[    2.091305] pci_bus 0000:00: root bus resource [mem 0x000e4000-0x000e7fff]
[    2.091309] pci_bus 0000:00: root bus resource [mem 0xafa00000-0xfeafffff]
[    2.095857] pci 0000:00:1c.0: PCI bridge to [bus 01]
[    2.096587] pci 0000:00:1c.6: PCI bridge to [bus 02]
[    2.097102] pci 0000:00:1c.7: PCI bridge to [bus 03-04]
[    2.097749] pci 0000:03:00.0: PCI bridge to [bus 04]
[    2.098158] pci 0000:00:1e.0: PCI bridge to [bus 05] (subtractive decode)
[    2.098677]  pci0000:00: ACPI _OSC support notification failed,
disabling PCIe ASPM
[    2.098682]  pci0000:00: Unable to request _OSC control (_OSC
support mask: 0x08)
(XEN) PCI add device 0000:00:00.0
(XEN) PCI add device 0000:00:02.0
(XEN) PCI add device 0000:00:14.0
(XEN) PCI add device 0000:00:16.0
(XEN) PCI add device 0000:00:16.3
(XEN) PCI add device 0000:00:19.0
(XEN) PCI add device 0000:00:1a.0
(XEN) PCI add device 0000:00:1b.0
(XEN) PCI add device 0000:00:1c.0
(XEN) PCI add device 0000:00:1c.6
(XEN) PCI add device 0000:00:1c.7
(XEN) PCI add device 0000:00:1d.0
(XEN) PCI add device 0000:00:1e.0
(XEN) PCI add device 0000:00:1f.0
(XEN) PCI add device 0000:00:1f.2
(XEN) PCI add device 0000:00:1f.3
(XEN) PCI add device 0000:02:00.0
(XEN) PCI add device 0000:03:00.0
(XEN) PCI add device 0000:04:00.0
(XEN) PCI add device 0000:05:01.0
[    2.104211] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 10 *11 12 14 15)
[    2.104279] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 10 11 12
14 15) *0, disabled.
[    2.104348] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 *4 5 6 10 11 12 14 15)
[    2.104414] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 *10 11 12 14 15)
[    2.104480] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 *5 6 10 11 12 14 15)
[    2.104544] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 10 11 12
14 15) *0, disabled.
[    2.104612] ACPI: PCI Interrupt Link [LNKG] (IRQs *3 4 5 6 10 11 12 14 15)
[    2.104676] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 10 *11 12 14 15)
[    2.104716] xen/balloon: Initialising balloon driver.
[    2.104855] vgaarb: device added:
PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none
[    2.104869] vgaarb: loaded
[    2.104871] vgaarb: bridge control possible 0000:00:02.0
[    2.104950] SCSI subsystem initialized
[    2.104954] ACPI: bus type scsi registered
[    2.105131] ACPI: bus type usb registered
[    2.105151] usbcore: registered new interface driver usbfs
[    2.105162] usbcore: registered new interface driver hub
[    2.105304] usbcore: registered new device driver usb
[    2.105513] wmi: Mapper loaded
[    2.105519] PCI: Using ACPI for IRQ routing
[    2.111086] Switching to clocksource xen
[    2.116428] pnp: PnP ACPI init
[    2.116439] ACPI: bus type pnp registered
[    2.117207] system 00:05: [io  0x0680-0x069f] has been reserved
[    2.117212] system 00:05: [io  0x1000-0x100f] has been reserved
[    2.117216] system 00:05: [io  0xffff] has been reserved
[    2.117219] system 00:05: [io  0xffff] has been reserved
[    2.117223] system 00:05: [io  0x0400-0x0453] has been reserved
[    2.117227] system 00:05: [io  0x0458-0x047f] has been reserved
[    2.117231] system 00:05: [io  0x0500-0x057f] has been reserved
[    2.117235] system 00:05: [io  0x164e-0x164f] has been reserved
[    2.117330] system 00:07: [io  0x0454-0x0457] has been reserved
[    2.117721] system 00:08: [mem 0xfed1c000-0xfed1ffff] has been reserved
[    2.117726] system 00:08: [mem 0xfed10000-0xfed17fff] could not be reserved
[    2.117730] system 00:08: [mem 0xfed18000-0xfed18fff] has been reserved
[    2.117735] system 00:08: [mem 0xfed19000-0xfed19fff] has been reserved
[    2.117739] system 00:08: [mem 0xf8000000-0xfbffffff] has been reserved
[    2.117743] system 00:08: [mem 0xfed20000-0xfed3ffff] has been reserved
[    2.117748] system 00:08: [mem 0xfed90000-0xfed93fff] has been reserved
[    2.117753] system 00:08: [mem 0xfed45000-0xfed8ffff] has been reserved
[    2.117757] system 00:08: [mem 0xff000000-0xffffffff] could not be reserved
[    2.117762] system 00:08: [mem 0xfee00000-0xfeefffff] could not be reserved
[    2.117766] system[    3.281195] usb 3-3: new low-speed USB device
number 2 using xhci_hcd
[    3.282603] bio: create slab  at 1
[    3.304654] usb 3-3: ep 0x81 - rounding interval to 64 microframes,
ep desc says 80 microframes
[    3.311353] usbcore: registered new interface driver usbhid
[    3.311360] usbhid: USB HID core driver
[    3.421244] usb 3-4: new low-speed USB device number 3 using xhci_hcd
Begin: Running /scripts/local-premount ... [    3.448335] usb 3-4: ep
0x81 - rounding interval to 128 microframes, ep desc says 192
microframes
done.
[    3.523331] EXT4-fs (dm-3): mounted filesystem with ordered data
mode. Opts: (null)
Begin: Running /scripts/local-bottom ... done.
done.
Begin: Running /scripts/init-bottom ... udevd[290]:
inotify_add_watch(6, /dev/dm-6, 10) failed: Invalid argument

done.
(XEN) microcode: collect_cpu_info : sig=0x306a4, pf=0x2, rev=0x7
(XEN) microcode: collect_cpu_info : sig=0x306a4, pf=0x2, rev=0x7
(XEN) microcode: collect_cpu_info : sig=0x306a4, pf=0x2, rev=0x7
(XEN) microcode: collect_cpu_info : sig=0x306a4, pf=0x2, rev=0x7

NxTop Engine (99.99.pre-121017-1309-bguthro) poison-ivy hvc0

poison-ivy login: root (automatic login)
Last login: Wed Oct 17 17:27:26 UTC 2012 from
bguthro-desktop.oldroadcomputing.net on pts/8
Welcome to NxTop Engine (GNU/Linux 3.7.0-orc x86_64)

root@poison-ivy:~#
root@poison-ivy:~#
root@poison-ivy:~# [   13.645342] irq 22: nobody cared (try booting
with the "irqpoll" option)
[   13.645442] handlers:
[   13.645446] [] serial8250_interrupt
[   13.645449] Disabling IRQ #22

root@poison-ivy:~#
root@poison-ivy:~#
root@poison-ivy:~# [   26.153266] irq 22: nobody cared (try booting
with the "irqpoll" option)
[   26.153341] handlers:
[   26.153345] [] serial8250_interrupt
[   26.153349] Disabling IRQ #22
(XEN) Preparing system for ACPI S3 state.
(XEN) Disabling non-boot CPUs ...
(XEN) Breaking vcpu affinity for domain 0 vcpu 2
(XEN) Breaking vcpu affinity for domain 0 vcpu 3
(XEN) Entering ACPI S3 state.
(XEN) mce_intel.c:721: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank
0 extended MCE MSR 0
(XEN) CPU0 CMCI LVT vector (0xf2) already installed
(XEN) Finishing wakeup from ACPI S3 state.
(XEN) microcode: collect_cpu_info : sig=0x306a4, pf=0x2, rev=0x7
(XEN) Enabling non-boot CPUs  ...
(XEN) microcode: collect_cpu_info : sig=0x306a4, pf=0x2, rev=0x7
(XEN) microcode: collect_cpu_info : sig=0x306a4, pf=0x2, rev=0x7
(XEN) microcode: collect_cpu_info : sig=0x306a4, pf=0x2, rev=0x7
(XEN) mm.c:587:d0 Could not get page ref for pfn ffffffffffffffff
(XEN) mm.c:2571:d0 Error while installing new baseptr ffffffffffffffff
(XEN) mm.c:2265:d0 Bad type (saw 4400000000000001 != exp
7000000000000000) for mfn 13db97 (pfn 26eb2)
(XEN) mm.c:812:d0 Could not get page type PGT_writable_page
(XEN) mm.c:864:d0 Error getting mfn 13db97 (pfn 26eb2) from L1 entry
800000013db97063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:2265:d0 Bad type (saw 3400000000000002 != exp
7000000000000000) for mfn 13edc4 (pfn 28085)
(XEN) mm.c:812:d0 Could not get page type PGT_writable_page
(XEN) mm.c:864:d0 Error getting mfn 13edc4 (pfn 28085) from L1 entry
800000013edc4063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:2265:d0 Bad type (saw 2400000000000001 != exp
7000000000000000) for mfn 13e625 (pfn 27c24)
(XEN) mm.c:812:d0 Could not get page type PGT_writable_page
(XEN) mm.c:864:d0 Error getting mfn 13e625 (pfn 27c24) from L1 entry
800000013e625063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:2265:d0 Bad type (saw 1400000000000001 != exp
7000000000000000) for mfn 13e886 (pfn 27dc3)
(XEN) mm.c:812:d0 Could not get page type PGT_writable_page
(XEN) mm.c:864:d0 Error getting mfn 13e886 (pfn 27dc3) from L1 entry
800000013e886063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:2265:d0 Bad type (saw 1400000000000001 != exp
7000000000000000) for mfn 13ebfa (pfn 27e4f)
(XEN) mm.c:812:d0 Could not get page type PGT_writable_page
(XEN) mm.c:864:d0 Error getting mfn 13ebfa (pfn 27e4f) from L1 entry
800000013ebfa063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:2265:d0 Bad type (saw 1400000000000001 != exp
7000000000000000) for mfn 14d52f (pfn 38da)
(XEN) mm.c:812:d0 Could not get page type PGT_writable_page
(XEN) mm.c:864:d0 Error getting mfn 14d52f (pfn 38da) from L1 entry
800000014d52f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:2265:d0 Bad type (saw 3400000000000002 != exp
7000000000000000) for mfn 13e5a1 (pfn 278a8)
(XEN) mm.c:812:d0 Could not get page type PGT_writable_page
(XEN) mm.c:864:d0 Error getting mfn 13e5a1 (pfn 278a8) from L1 entry
800000013e5a1063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:2265:d0 Bad type (saw 2400000000000001 != exp
7000000000000000) for mfn 14dba6 (pfn 3f51)
(XEN) mm.c:812:d0 Could not get page type PGT_writable_page
(XEN) mm.c:864:d0 Error getting mfn 14dba6 (pfn 3f51) from L1 entry
800000014dba6063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:2265:d0 Bad type (saw 1400000000000001 != exp
7000000000000000) for mfn 13da86 (pfn 26fc3)
(XEN) mm.c:812:d0 Could not get page type PGT_writable_page
(XEN) mm.c:864:d0 Error getting mfn 13da86 (pfn 26fc3) from L1 entry
800000013da86063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:2265:d0 Bad type (saw 1400000000000001 != exp
7000000000000000) for mfn 14d50a (pfn 38b5)
(XEN) mm.c:812:d0 Could not get page type PGT_writable_page
(XEN) mm.c:864:d0 Error getting mfn 14d50a (pfn 38b5) from L1 entry
800000014d50a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:2265:d0 Bad type (saw 1400000000000001 != exp
7000000000000000) for mfn 14d0a7 (pfn 3452)
(XEN) mm.c:812:d0 Could not get page type PGT_writable_page
(XEN) mm.c:864:d0 Error getting mfn 14d0a7 (pfn 3452) from L1 entry
800000014d0a7063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:2265:d0 Bad type (saw 1400000000000001 != exp
7000000000000000) for mfn 14d6e7 (pfn 3a92)
(XEN) mm.c:812:d0 Could not get page type PGT_writable_page
(XEN) mm.c:864:d0 Error getting mfn 14d6e7 (pfn 3a92) from L1 entry
800000014d6e7063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:2265:d0 Bad type (saw 3400000000000002 != exp
7000000000000000) for mfn 14dafd (pfn 3ea8)
(XEN) mm.c:812:d0 Could not get page type PGT_writable_page
(XEN) mm.c:864:d0 Error getting mfn 14dafd (pfn 3ea8) from L1 entry
800000014dafd063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:2265:d0 Bad type (saw 2400000000000001 != exp
7000000000000000) for mfn 13d598 (pfn 268b1)
(XEN) mm.c:812:d0 Could not get page type PGT_writable_page
(XEN) mm.c:864:d0 Error getting mfn 13d598 (pfn 268b1) from L1 entry
800000013d598063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:2265:d0 Bad type (saw 1400000000000001 != exp
7000000000000000) for mfn 13daa1 (pfn 26fa8)
(XEN) mm.c:812:d0 Could not get page type PGT_writable_page
(XEN) mm.c:864:d0 Error getting mfn 13daa1 (pfn 26fa8) from L1 entry
800000013daa1063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:2265:d0 Bad type (saw 4400000000000001 != exp
7000000000000000) for mfn 14d0d5 (pfn 3480)
(XEN) mm.c:812:d0 Could not get page type PGT_writable_page
(XEN) mm.c:864:d0 Error getting mfn 14d0d5 (pfn 3480) from L1 entry
800000014d0d5063 for l1e_owner=0, pg_owner=0

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 17:46:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 17:46:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOXh5-0004JN-Hs; Wed, 17 Oct 2012 17:46:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOXh4-0004JG-K6
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 17:46:10 +0000
Received: from [85.158.139.83:42979] by server-8.bemta-5.messagelabs.com id
	BA/5F-23193-1EEEE705; Wed, 17 Oct 2012 17:46:09 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1350495967!32474010!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODMwNDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32350 invoked from network); 17 Oct 2012 17:46:09 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 17:46:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,602,1344211200"; d="scan'208";a="211598735"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 17:46:07 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 13:46:06 -0400
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TOXh0-0003SD-BF;
	Wed, 17 Oct 2012 18:46:06 +0100
Message-ID: <507EEEDE.7040904@citrix.com>
Date: Wed, 17 Oct 2012 18:46:06 +0100
From: Andrew Cooper 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Stefan Bader 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
	<1350482118.2460.74.camel@zakaz.uk.xensource.com>
	<507ECD06.2050407@canonical.com> <507ED038.8000806@citrix.com>
	<507EDC71.4040400@canonical.com>
In-Reply-To: <507EDC71.4040400@canonical.com>
X-Enigmail-Version: 1.4.5
Cc: "xen-devel@lists.xen.org" ,
	Ian Campbell ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 17/10/12 17:27, Stefan Bader wrote:
> On 17.10.2012 17:35, Andrew Cooper wrote:
>
>>> (XEN) Event channel information for domain 1:
>>> (XEN) Polling vCPUs: {1,4,6}
>>> (XEN) port [p/m]
>>> (XEN) 4 [1/1]: s=6 n=0 x=0
>>> (XEN) 10 [0/1]: s=6 n=1 x=0
>>> (XEN) 28 [0/1]: s=6 n=4 x=0
>>> (XEN) 40 [0/1]: s=6 n=6 x=0
>>>
>> s = state.  0 = free, 1 = reserved, 2 = unbound, 3 = inter-domain, 4 =
>> pirq, 5 = virq, 6 = ipi
>> n = target vcpu id to notify
>> x = boolean indicating whether xen is a consumer of the event channel or
>> not.
>>
>> d = target domain (when appropriate)  In this case, p is the target port.
>>
> Thanks (at least something learned today :)) One thing I noticed here, in the
> event channel info above, pending is 0 for channel 10, 28 and 40 (and set for 4
> which is the spinlock ipi for cpu 0). But in the VCPU info below (another
> unknown: has=T and F) it says upcall_pend for all of them. Unfortunately that
> might just mean that things change...

I believe the upcall_pending is just a simple bit indicating that an
event channel for that vcpu has an event pending, but doesn't identify
which event channel it is.

Of course, as the VCPU is currently descheduled in Xen waiting for a
specific event channel to end the poll, other events are likely to build
up, but will not be serviced until the VCPU resumes.

The "has=" value is a boolean from struct vcpu,  vcpu->is_running.  This
is a bit more subtle, as a vcpu is still considered running if its
context is on the hypervisor pcpu stack, but Xen has invoked the idle
loop on that PCPU.  I don't know whether this is relevant to the bug.

>
>>> (XEN) VCPU0: CPU3 [has=T] flags=0 poll=0 upcall_pend = 01, upcall_mask
>> = 01
>>> dirty_cpus={3} cpu_affinity={0-127}
>>> (XEN) No periodic timer
>>> (XEN) VCPU1: CPU7 [has=F] flags=1 poll=10 upcall_pend = 01,
>> upcall_mask = 01
>>> dirty_cpus={} cpu_affinity={0-127}
>>> (XEN) No periodic timer
>>> (XEN) VCPU4: CPU6 [has=F] flags=1 poll=28 upcall_pend = 01,
>> upcall_mask = 01
>>> dirty_cpus={} cpu_affinity={0-127}
>>> (XEN) No periodic timer
>>> (XEN) VCPU6: CPU0 [has=F] flags=1 poll=40 upcall_pend = 01,
>> upcall_mask = 01
>>> dirty_cpus={} cpu_affinity={0-127}
>>> (XEN) No periodic timer
>> So in this case, vcpu 1 is in a poll, on port 10, which is an IPI event
>> channel for itself.
>>
>> Same for vcpu 4, except it is on port 28, and for vcpu 6 on port 60.
>>
>> I wonder if there is possibly a race condition between notifying that a
>> lock has been unlocked, and another vcpu trying to poll after deciding
>> that the lock is locked.
> There has to be something somehwere, I just cannot spot it. The unlocking cpu
> will do a wmb() before setting the lock to 0, then a mb() and then check for
> spinners. When failing the quick pack a locker will first set the lockspinner
> entry, then do a wmb() and increment the spinners count. After that it clears
> the event pending and then checks lock again before actually going into poll.
>
>> The other option is that there is a bug in working out which event
>> channel to notify when a lock is unlocked.
> I had thought I saw one thing that I tried to fix with my patch. Another train
> of thought would have been any other cpu grabbing the lock always as soon as it
> gets released and so preventing any cpu in poll from success. But that would
> then show the lock as locked...

How does the unlocking code choose an event channel to invoke?  Is there
perhaps a race condition updating that value if another cpu nabs the
lock inbetween?

(I am just throwing ideas around - I am not very familar with this code)

~Andrew

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 17:46:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 17:46:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOXh5-0004JN-Hs; Wed, 17 Oct 2012 17:46:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOXh4-0004JG-K6
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 17:46:10 +0000
Received: from [85.158.139.83:42979] by server-8.bemta-5.messagelabs.com id
	BA/5F-23193-1EEEE705; Wed, 17 Oct 2012 17:46:09 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1350495967!32474010!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODMwNDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32350 invoked from network); 17 Oct 2012 17:46:09 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 17:46:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,602,1344211200"; d="scan'208";a="211598735"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 17:46:07 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 17 Oct 2012 13:46:06 -0400
Received: from andrewcoop.uk.xensource.com ([10.80.2.18])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TOXh0-0003SD-BF;
	Wed, 17 Oct 2012 18:46:06 +0100
Message-ID: <507EEEDE.7040904@citrix.com>
Date: Wed, 17 Oct 2012 18:46:06 +0100
From: Andrew Cooper 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Stefan Bader 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
	<1350482118.2460.74.camel@zakaz.uk.xensource.com>
	<507ECD06.2050407@canonical.com> <507ED038.8000806@citrix.com>
	<507EDC71.4040400@canonical.com>
In-Reply-To: <507EDC71.4040400@canonical.com>
X-Enigmail-Version: 1.4.5
Cc: "xen-devel@lists.xen.org" ,
	Ian Campbell ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 17/10/12 17:27, Stefan Bader wrote:
> On 17.10.2012 17:35, Andrew Cooper wrote:
>
>>> (XEN) Event channel information for domain 1:
>>> (XEN) Polling vCPUs: {1,4,6}
>>> (XEN) port [p/m]
>>> (XEN) 4 [1/1]: s=6 n=0 x=0
>>> (XEN) 10 [0/1]: s=6 n=1 x=0
>>> (XEN) 28 [0/1]: s=6 n=4 x=0
>>> (XEN) 40 [0/1]: s=6 n=6 x=0
>>>
>> s = state.  0 = free, 1 = reserved, 2 = unbound, 3 = inter-domain, 4 =
>> pirq, 5 = virq, 6 = ipi
>> n = target vcpu id to notify
>> x = boolean indicating whether xen is a consumer of the event channel or
>> not.
>>
>> d = target domain (when appropriate)  In this case, p is the target port.
>>
> Thanks (at least something learned today :)) One thing I noticed here, in the
> event channel info above, pending is 0 for channel 10, 28 and 40 (and set for 4
> which is the spinlock ipi for cpu 0). But in the VCPU info below (another
> unknown: has=T and F) it says upcall_pend for all of them. Unfortunately that
> might just mean that things change...

I believe the upcall_pending is just a simple bit indicating that an
event channel for that vcpu has an event pending, but doesn't identify
which event channel it is.

Of course, as the VCPU is currently descheduled in Xen waiting for a
specific event channel to end the poll, other events are likely to build
up, but will not be serviced until the VCPU resumes.

The "has=" value is a boolean from struct vcpu,  vcpu->is_running.  This
is a bit more subtle, as a vcpu is still considered running if its
context is on the hypervisor pcpu stack, but Xen has invoked the idle
loop on that PCPU.  I don't know whether this is relevant to the bug.

>
>>> (XEN) VCPU0: CPU3 [has=T] flags=0 poll=0 upcall_pend = 01, upcall_mask
>> = 01
>>> dirty_cpus={3} cpu_affinity={0-127}
>>> (XEN) No periodic timer
>>> (XEN) VCPU1: CPU7 [has=F] flags=1 poll=10 upcall_pend = 01,
>> upcall_mask = 01
>>> dirty_cpus={} cpu_affinity={0-127}
>>> (XEN) No periodic timer
>>> (XEN) VCPU4: CPU6 [has=F] flags=1 poll=28 upcall_pend = 01,
>> upcall_mask = 01
>>> dirty_cpus={} cpu_affinity={0-127}
>>> (XEN) No periodic timer
>>> (XEN) VCPU6: CPU0 [has=F] flags=1 poll=40 upcall_pend = 01,
>> upcall_mask = 01
>>> dirty_cpus={} cpu_affinity={0-127}
>>> (XEN) No periodic timer
>> So in this case, vcpu 1 is in a poll, on port 10, which is an IPI event
>> channel for itself.
>>
>> Same for vcpu 4, except it is on port 28, and for vcpu 6 on port 60.
>>
>> I wonder if there is possibly a race condition between notifying that a
>> lock has been unlocked, and another vcpu trying to poll after deciding
>> that the lock is locked.
> There has to be something somehwere, I just cannot spot it. The unlocking cpu
> will do a wmb() before setting the lock to 0, then a mb() and then check for
> spinners. When failing the quick pack a locker will first set the lockspinner
> entry, then do a wmb() and increment the spinners count. After that it clears
> the event pending and then checks lock again before actually going into poll.
>
>> The other option is that there is a bug in working out which event
>> channel to notify when a lock is unlocked.
> I had thought I saw one thing that I tried to fix with my patch. Another train
> of thought would have been any other cpu grabbing the lock always as soon as it
> gets released and so preventing any cpu in poll from success. But that would
> then show the lock as locked...

How does the unlocking code choose an event channel to invoke?  Is there
perhaps a race condition updating that value if another cpu nabs the
lock inbetween?

(I am just throwing ideas around - I am not very familar with this code)

~Andrew

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 17:55:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 17:55:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOXq6-0004lI-Jv; Wed, 17 Oct 2012 17:55:30 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOXq4-0004l3-Vk
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 17:55:29 +0000
Received: from [193.109.254.147:34169] by server-5.bemta-14.messagelabs.com id
	10/D6-18309-011FE705; Wed, 17 Oct 2012 17:55:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1350496524!3905630!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgxNjgxMg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6299 invoked from network); 17 Oct 2012 17:55:26 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Oct 2012 17:55:26 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9HHtKB1015399
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Oct 2012 17:55:21 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9HHtJaJ029753
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Oct 2012 17:55:20 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9HHtJdS032194; Wed, 17 Oct 2012 12:55:19 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 10:55:19 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9B7914035B; Wed, 17 Oct 2012 13:43:17 -0400 (EDT)
Date: Wed, 17 Oct 2012 13:43:17 -0400
From: Konrad Rzeszutek Wilk 
To: Ben Guthro 
Message-ID: <20121017174317.GA25443@phenom.dumpdata.com>
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, hpa@zytor.com, lenb@kernel.org
Subject: Re: [Xen-devel] [RFC] ACPI S3 and Xen (suprisingly small\!).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 17, 2012 at 01:46:09PM -0400, Ben Guthro wrote:
> On Wed, Oct 17, 2012 at 9:49 AM, Konrad Rzeszutek Wilk
>  wrote:
> [...]
> 
> > The end result is this is a nice set of patches where there is only
> > _one_ change in the x86 code (and it is just more of dealing with
> > error case) - and the rest are all done in Xen side.
> 
> I'm sorry to report that this series doesn't seem to work in my setup
> against xen-unstable.
> 
> To verify that it was, in fact this patch series, and not another Xen
> regression - I swapped out the kernel with this patch series, with an
> identical one, replacing only this series with your acpi-s3.v9 branch
> - and everything worked fine.

Thanks for testing it!

I had tested it with Xen 4.1.3, which could be doing something different.
Will see what is up.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 17:55:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 17:55:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOXq6-0004lI-Jv; Wed, 17 Oct 2012 17:55:30 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOXq4-0004l3-Vk
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 17:55:29 +0000
Received: from [193.109.254.147:34169] by server-5.bemta-14.messagelabs.com id
	10/D6-18309-011FE705; Wed, 17 Oct 2012 17:55:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1350496524!3905630!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgxNjgxMg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6299 invoked from network); 17 Oct 2012 17:55:26 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Oct 2012 17:55:26 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9HHtKB1015399
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Oct 2012 17:55:21 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9HHtJaJ029753
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Oct 2012 17:55:20 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9HHtJdS032194; Wed, 17 Oct 2012 12:55:19 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 10:55:19 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9B7914035B; Wed, 17 Oct 2012 13:43:17 -0400 (EDT)
Date: Wed, 17 Oct 2012 13:43:17 -0400
From: Konrad Rzeszutek Wilk 
To: Ben Guthro 
Message-ID: <20121017174317.GA25443@phenom.dumpdata.com>
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, hpa@zytor.com, lenb@kernel.org
Subject: Re: [Xen-devel] [RFC] ACPI S3 and Xen (suprisingly small\!).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 17, 2012 at 01:46:09PM -0400, Ben Guthro wrote:
> On Wed, Oct 17, 2012 at 9:49 AM, Konrad Rzeszutek Wilk
>  wrote:
> [...]
> 
> > The end result is this is a nice set of patches where there is only
> > _one_ change in the x86 code (and it is just more of dealing with
> > error case) - and the rest are all done in Xen side.
> 
> I'm sorry to report that this series doesn't seem to work in my setup
> against xen-unstable.
> 
> To verify that it was, in fact this patch series, and not another Xen
> regression - I swapped out the kernel with this patch series, with an
> identical one, replacing only this series with your acpi-s3.v9 branch
> - and everything worked fine.

Thanks for testing it!

I had tested it with Xen 4.1.3, which could be doing something different.
Will see what is up.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 17:55:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 17:55:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOXq6-0004lP-VE; Wed, 17 Oct 2012 17:55:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOXq5-0004l4-Jm
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 17:55:29 +0000
Received: from [85.158.137.99:26369] by server-4.bemta-3.messagelabs.com id
	07/EC-01405-011FE705; Wed, 17 Oct 2012 17:55:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1350496528!16837486!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17175 invoked from network); 17 Oct 2012 17:55:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 17:55:28 -0000
X-IronPort-AV: E=Sophos;i="4.80,602,1344211200"; d="scan'208";a="15234715"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 17:55:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 17 Oct 2012 18:55:27 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TOXq3-0000IS-Gi;
	Wed, 17 Oct 2012 17:55:27 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TOXq3-00038n-GK;
	Wed, 17 Oct 2012 18:55:27 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Wed, 17 Oct 2012 18:55:27 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14001: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14001 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14001/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 13967
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-pv            5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 13967
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 13967
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 13967
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 13967
 test-amd64-amd64-xl           5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                fail REGR. vs. 13967
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 13967
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 13967
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot          fail REGR. vs. 13967

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13967
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13967

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  1f4be6ee4619
baseline version:
 xen                  c1c549c4fe9e

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf 
  Huang Ying 
  Jan Beulich 
  Keir Fraser 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26063:1f4be6ee4619
tag:         tip
user:        Jan Beulich 
date:        Wed Oct 17 14:13:20 2012 +0200
    
    x86/HPET: obtain proper lock for changing IRQ affinity
    
    The IRQ descriptor lock should be held while adjusting the affinity of
    any IRQ; the HPET channel lock isn't sufficient to protect namely
    against races with moving the IRQ to a different CPU.
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    
    
changeset:   26062:ec8a091efcce
user:        Huang Ying 
date:        Wed Oct 17 14:12:06 2012 +0200
    
    ACPI/APEI: fix ERST MOVE_DATA instruction implementation
    
    The src_base and dst_base fields in apei_exec_context are physical
    address, so they should be ioremaped before being used in ERST
    MOVE_DATA instruction.
    
    Reported-by: Javier Martinez Canillas 
    Reported-by: Andrew Morton 
    Signed-off-by: Huang Ying 
    
    Replace use of ioremap() by __acpi_map_table()/set_fixmap(). Fix error
    handling.
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    Committed-by: Jan Beulich 
    
    
changeset:   26061:4b4c0c7a6031
user:        Jan Beulich 
date:        Wed Oct 17 11:23:10 2012 +0200
    
    x86/oprof: adjust off-by-one counter range checks
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    
    
changeset:   26060:4fc87c2f31a0
user:        Huang Ying 
date:        Tue Oct 16 17:26:36 2012 +0200
    
    ACPI: fix APEI related table size checking
    
    On Huang Ying's machine:
    
    erst_tab->header_length == sizeof(struct acpi_table_einj)
    
    but Yinghai reported that on his machine,
    
    erst_tab->header_length == sizeof(struct acpi_table_einj) -
    sizeof(struct acpi_table_header)
    
    To make erst table size checking code works on all systems, both
    testing are treated as PASS.
    
    Same situation applies to einj_tab->header_length, so corresponding
    table size checking is changed in similar way too.
    
    Originally-by: Yinghai Lu 
    Signed-off-by: Huang Ying 
    
    - use switch() for better readability
    - add comment explaining why a formally invalid size it also being
      accepted
    - check erst_tab->header.length before even looking at
      erst_tab->header_length
    - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    Committed-by: Jan Beulich 
    
    
changeset:   26059:c1c549c4fe9e
user:        Daniel De Graaf 
date:        Mon Oct 15 16:51:44 2012 +0100
    
    xen: Add versions of rcu_lock_*_domain without IS_PRIV
    
    These functions will be used to avoid duplication of IS_PRIV calls
    that will be introduced in XSM hooks. This also fixes a build error
    with XSM enabled introduced by 25925:d1c3375c3f11 which depends on
    this patch.
    
    Signed-off-by: Daniel De Graaf 
    Committed-by: Keir Fraser 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 17:55:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 17:55:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOXq6-0004lP-VE; Wed, 17 Oct 2012 17:55:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOXq5-0004l4-Jm
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 17:55:29 +0000
Received: from [85.158.137.99:26369] by server-4.bemta-3.messagelabs.com id
	07/EC-01405-011FE705; Wed, 17 Oct 2012 17:55:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1350496528!16837486!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17175 invoked from network); 17 Oct 2012 17:55:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 17:55:28 -0000
X-IronPort-AV: E=Sophos;i="4.80,602,1344211200"; d="scan'208";a="15234715"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 17:55:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 17 Oct 2012 18:55:27 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TOXq3-0000IS-Gi;
	Wed, 17 Oct 2012 17:55:27 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TOXq3-00038n-GK;
	Wed, 17 Oct 2012 18:55:27 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Wed, 17 Oct 2012 18:55:27 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14001: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14001 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14001/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 13967
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-pv            5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 13967
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 13967
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 13967
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 13967
 test-amd64-amd64-xl           5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                fail REGR. vs. 13967
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 13967
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 13967
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot          fail REGR. vs. 13967

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13967
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13967

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  1f4be6ee4619
baseline version:
 xen                  c1c549c4fe9e

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf 
  Huang Ying 
  Jan Beulich 
  Keir Fraser 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26063:1f4be6ee4619
tag:         tip
user:        Jan Beulich 
date:        Wed Oct 17 14:13:20 2012 +0200
    
    x86/HPET: obtain proper lock for changing IRQ affinity
    
    The IRQ descriptor lock should be held while adjusting the affinity of
    any IRQ; the HPET channel lock isn't sufficient to protect namely
    against races with moving the IRQ to a different CPU.
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    
    
changeset:   26062:ec8a091efcce
user:        Huang Ying 
date:        Wed Oct 17 14:12:06 2012 +0200
    
    ACPI/APEI: fix ERST MOVE_DATA instruction implementation
    
    The src_base and dst_base fields in apei_exec_context are physical
    address, so they should be ioremaped before being used in ERST
    MOVE_DATA instruction.
    
    Reported-by: Javier Martinez Canillas 
    Reported-by: Andrew Morton 
    Signed-off-by: Huang Ying 
    
    Replace use of ioremap() by __acpi_map_table()/set_fixmap(). Fix error
    handling.
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    Committed-by: Jan Beulich 
    
    
changeset:   26061:4b4c0c7a6031
user:        Jan Beulich 
date:        Wed Oct 17 11:23:10 2012 +0200
    
    x86/oprof: adjust off-by-one counter range checks
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    
    
changeset:   26060:4fc87c2f31a0
user:        Huang Ying 
date:        Tue Oct 16 17:26:36 2012 +0200
    
    ACPI: fix APEI related table size checking
    
    On Huang Ying's machine:
    
    erst_tab->header_length == sizeof(struct acpi_table_einj)
    
    but Yinghai reported that on his machine,
    
    erst_tab->header_length == sizeof(struct acpi_table_einj) -
    sizeof(struct acpi_table_header)
    
    To make erst table size checking code works on all systems, both
    testing are treated as PASS.
    
    Same situation applies to einj_tab->header_length, so corresponding
    table size checking is changed in similar way too.
    
    Originally-by: Yinghai Lu 
    Signed-off-by: Huang Ying 
    
    - use switch() for better readability
    - add comment explaining why a formally invalid size it also being
      accepted
    - check erst_tab->header.length before even looking at
      erst_tab->header_length
    - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    Committed-by: Jan Beulich 
    
    
changeset:   26059:c1c549c4fe9e
user:        Daniel De Graaf 
date:        Mon Oct 15 16:51:44 2012 +0100
    
    xen: Add versions of rcu_lock_*_domain without IS_PRIV
    
    These functions will be used to avoid duplication of IS_PRIV calls
    that will be introduced in XSM hooks. This also fixes a build error
    with XSM enabled introduced by 25925:d1c3375c3f11 which depends on
    this patch.
    
    Signed-off-by: Daniel De Graaf 
    Committed-by: Keir Fraser 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 18:00:47 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 18:00:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOXv0-000577-Nz; Wed, 17 Oct 2012 18:00:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOXuz-000570-5H
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 18:00:33 +0000
Received: from [85.158.137.99:31451] by server-15.bemta-3.messagelabs.com id
	7F/03-10261-042FE705; Wed, 17 Oct 2012 18:00:32 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1350496830!16631818!1
X-Originating-IP: [209.85.223.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1903 invoked from network); 17 Oct 2012 18:00:31 -0000
Received: from mail-ie0-f171.google.com (HELO mail-ie0-f171.google.com)
	(209.85.223.171)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 18:00:31 -0000
Received: by mail-ie0-f171.google.com with SMTP id s9so14891369iec.30
	for ;
	Wed, 17 Oct 2012 11:00:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=eKmf1vnIZMZnQ7VQ4aFxphI3R/ETvfHDHQ7Oi2HdCb4=;
	b=oMkZEMV0L385BrT0pl0g7/o4rmQrM7v5/1vekI4dsQSsS9eM60Q4K7tsO8VveIqFeo
	NZZFB3qRNrPBp7QfdY0q7ulSHwb34C4Sbc1MZGZyc0qyMzSOHiXGtdlJEsdVPnDrWO6Z
	q8VmnldBg9bZPDm+rLQymnvJhsE3nVraAjsWeeLt1Q17jQLhjDmCEj/AF89F7y+YCDyF
	1A0TThLlddppGQG+5ZbUASdAAiuxMRm5qeRkqwghkI7TCOMRg4F+j8q1S6S94k2ze7dn
	oxWYZOcZkuEKrLU2hl0rwaHMe6T2j63AnRCe9qhdS/AW9NBh6Ps0RKj7UYk9J/s2ywdA
	NjPw==
MIME-Version: 1.0
Received: by 10.50.190.234 with SMTP id gt10mr2412906igc.20.1350496829828;
	Wed, 17 Oct 2012 11:00:29 -0700 (PDT)
Received: by 10.231.193.227 with HTTP; Wed, 17 Oct 2012 11:00:29 -0700 (PDT)
In-Reply-To: <20121017174317.GA25443@phenom.dumpdata.com>
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	
	<20121017174317.GA25443@phenom.dumpdata.com>
Date: Wed, 17 Oct 2012 14:00:29 -0400
X-Google-Sender-Auth: NX0kViSPm9KAJNLIvontvkQ_ovU
Message-ID: 
From: Ben Guthro 
To: Konrad Rzeszutek Wilk 
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, hpa@zytor.com, lenb@kernel.org
Subject: Re: [Xen-devel] [RFC] ACPI S3 and Xen (suprisingly small\!).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I'm not sure it matters, but I'm testing against a changeset about a week old:
http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=1c4a5b37b55c56e49135e65728137f54288d1fe6

Plus patches specific to XenClient Enterprise.


On Wed, Oct 17, 2012 at 1:43 PM, Konrad Rzeszutek Wilk
 wrote:
> On Wed, Oct 17, 2012 at 01:46:09PM -0400, Ben Guthro wrote:
>> On Wed, Oct 17, 2012 at 9:49 AM, Konrad Rzeszutek Wilk
>>  wrote:
>> [...]
>>
>> > The end result is this is a nice set of patches where there is only
>> > _one_ change in the x86 code (and it is just more of dealing with
>> > error case) - and the rest are all done in Xen side.
>>
>> I'm sorry to report that this series doesn't seem to work in my setup
>> against xen-unstable.
>>
>> To verify that it was, in fact this patch series, and not another Xen
>> regression - I swapped out the kernel with this patch series, with an
>> identical one, replacing only this series with your acpi-s3.v9 branch
>> - and everything worked fine.
>
> Thanks for testing it!
>
> I had tested it with Xen 4.1.3, which could be doing something different.
> Will see what is up.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 18:00:47 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 18:00:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOXv0-000577-Nz; Wed, 17 Oct 2012 18:00:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOXuz-000570-5H
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 18:00:33 +0000
Received: from [85.158.137.99:31451] by server-15.bemta-3.messagelabs.com id
	7F/03-10261-042FE705; Wed, 17 Oct 2012 18:00:32 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1350496830!16631818!1
X-Originating-IP: [209.85.223.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1903 invoked from network); 17 Oct 2012 18:00:31 -0000
Received: from mail-ie0-f171.google.com (HELO mail-ie0-f171.google.com)
	(209.85.223.171)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 18:00:31 -0000
Received: by mail-ie0-f171.google.com with SMTP id s9so14891369iec.30
	for ;
	Wed, 17 Oct 2012 11:00:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=eKmf1vnIZMZnQ7VQ4aFxphI3R/ETvfHDHQ7Oi2HdCb4=;
	b=oMkZEMV0L385BrT0pl0g7/o4rmQrM7v5/1vekI4dsQSsS9eM60Q4K7tsO8VveIqFeo
	NZZFB3qRNrPBp7QfdY0q7ulSHwb34C4Sbc1MZGZyc0qyMzSOHiXGtdlJEsdVPnDrWO6Z
	q8VmnldBg9bZPDm+rLQymnvJhsE3nVraAjsWeeLt1Q17jQLhjDmCEj/AF89F7y+YCDyF
	1A0TThLlddppGQG+5ZbUASdAAiuxMRm5qeRkqwghkI7TCOMRg4F+j8q1S6S94k2ze7dn
	oxWYZOcZkuEKrLU2hl0rwaHMe6T2j63AnRCe9qhdS/AW9NBh6Ps0RKj7UYk9J/s2ywdA
	NjPw==
MIME-Version: 1.0
Received: by 10.50.190.234 with SMTP id gt10mr2412906igc.20.1350496829828;
	Wed, 17 Oct 2012 11:00:29 -0700 (PDT)
Received: by 10.231.193.227 with HTTP; Wed, 17 Oct 2012 11:00:29 -0700 (PDT)
In-Reply-To: <20121017174317.GA25443@phenom.dumpdata.com>
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	
	<20121017174317.GA25443@phenom.dumpdata.com>
Date: Wed, 17 Oct 2012 14:00:29 -0400
X-Google-Sender-Auth: NX0kViSPm9KAJNLIvontvkQ_ovU
Message-ID: 
From: Ben Guthro 
To: Konrad Rzeszutek Wilk 
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, hpa@zytor.com, lenb@kernel.org
Subject: Re: [Xen-devel] [RFC] ACPI S3 and Xen (suprisingly small\!).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I'm not sure it matters, but I'm testing against a changeset about a week old:
http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=1c4a5b37b55c56e49135e65728137f54288d1fe6

Plus patches specific to XenClient Enterprise.


On Wed, Oct 17, 2012 at 1:43 PM, Konrad Rzeszutek Wilk
 wrote:
> On Wed, Oct 17, 2012 at 01:46:09PM -0400, Ben Guthro wrote:
>> On Wed, Oct 17, 2012 at 9:49 AM, Konrad Rzeszutek Wilk
>>  wrote:
>> [...]
>>
>> > The end result is this is a nice set of patches where there is only
>> > _one_ change in the x86 code (and it is just more of dealing with
>> > error case) - and the rest are all done in Xen side.
>>
>> I'm sorry to report that this series doesn't seem to work in my setup
>> against xen-unstable.
>>
>> To verify that it was, in fact this patch series, and not another Xen
>> regression - I swapped out the kernel with this patch series, with an
>> identical one, replacing only this series with your acpi-s3.v9 branch
>> - and everything worked fine.
>
> Thanks for testing it!
>
> I had tested it with Xen 4.1.3, which could be doing something different.
> Will see what is up.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 18:34:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 18:34:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOYRD-0005QD-Au; Wed, 17 Oct 2012 18:33:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOYRB-0005Q6-Vz
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 18:33:50 +0000
Received: from [85.158.137.99:58961] by server-10.bemta-3.messagelabs.com id
	87/64-27386-D0AFE705; Wed, 17 Oct 2012 18:33:49 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-12.tower-217.messagelabs.com!1350498826!18862835!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4078 invoked from network); 17 Oct 2012 18:33:48 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 18:33:48 -0000
Received: by mail-ie0-f173.google.com with SMTP id 17so15221591iea.32
	for ; Wed, 17 Oct 2012 11:33:46 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=content-type:mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=lyzF8FBNx7msdgywEgDqrvQ+qZzsqwYKwIrwQw/Qeg8=;
	b=LqB5l+QsUuuNpZ9uAvHL/JkClvp4ixHv9CF6hTRZSHR0PkPr+xAMgWIaEyhEcf+0OT
	pbE4sWq8VpuRqaCPS8QtM6bKaairAkK801JqLKikb3Uf9HjuGSLiFqgwf3NOgSMFpHA1
	6WAEvHfuTx66DVc95lSK5df7XxbShFEWp+tEoPC38H1hoPbGO6xQuPP6ySHxigTQF3ry
	xWlHeB4+IpxXS1Wl/tuKUVwL19aRG9nug2zPh51XqHKdcjYYP2By/cWgCjzY344Y/PcI
	fChY36IgTYBohPB0UZLAt5T7FgGAk2dBKSWfma1X61X7C9JZZ7ZqALriYz5QFly41HS2
	V/JQ==
Received: by 10.43.92.71 with SMTP id bp7mr15170065icc.29.1350498826223;
	Wed, 17 Oct 2012 11:33:46 -0700 (PDT)
Received: from [192.168.4.87] ([206.223.182.18])
	by mx.google.com with ESMTPS id rd10sm2020122igb.1.2012.10.17.11.33.42
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 17 Oct 2012 11:33:44 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Andres Lagar-Cavilla 
In-Reply-To: 
Date: Wed, 17 Oct 2012 14:33:41 -0400
Message-Id: <34D83A40-E798-4CF7-9084-83347C7207BB@gridcentric.ca>
References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default>
	<20581.55931.246130.308384@mariner.uk.xensource.com>
	<8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default>
	<20121002091017.GA95926@ocelot.phlegethon.org>
	<66cc0085-1216-40f7-8059-eaf615202c12@default>
	<20121002201624.GA98445@ocelot.phlegethon.org>
	
	<20121004100645.GC38243@ocelot.phlegethon.org>
	<1349345864.650.247.camel@zakaz.uk.xensource.com>
	<239799F4-AF29-494F-86D2-ADF45ACA8792@gridcentric.ca>
	<3e5cf0ba-4241-4f00-bef6-aaff2cc23419@default>
	<506EC710.3020606@eu.citrix.com>
	<58b5a25d-ccdd-4d0c-a0d9-9c249825f7f1@default>
	
	
	
To: George Dunlap 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQnc2MFFxHhRIE6np+VQaOf6yk9lZNicAINwuVzEmnDnitKTT+7XP0aTfR5bNIRG6A3KTJC6
Cc: Dan Magenheimer ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	Konrad Wilk ,
	Andres Lagar-Cavilla ,
	"Tim \(Xen.org\)" , Olaf Hering ,
	xen-devel@lists.xen.org, George Shuklin ,
	Dario Faggioli , Kurt Hackel ,
	Ian Jackson 
Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and
	xl)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Oct 17, 2012, at 1:35 PM, George Dunlap  wrote:

> [Sorry, forgot to reply-to-all]
> 
> On Tue, Oct 16, 2012 at 6:51 PM, Dan Magenheimer
>  wrote:
>> 
>> If you reread my last response with the assumption in mind:
>> 
>>  "tmem == an instance of a memory scheduler == grand vision"
>> 
>> then does the discussion of the "memory reservation" hypercall
>> make more sense?
> 
> Sort of. :-) Unfortunately, I think it shows a bit of confusion, which
> is perhaps why it was hard to understand.
> 
> But let's go back for a minute to the problem at hand: you're afraid
> of free memory disappearing between a toolstack checking for the
> memory, and the toolstack actually creating the VM.
> 
> There are two ways this could happen:
> 
> 1. Another admin command (perhaps by another administrator) has caused
> the memory to go away -- i.e,. another admin has called "xl create",
> or has instructed a VM to balloon up to a higher amount of memory.
> 
> 2. One of the self-directed processes in the system has allocated the
> memory: a balloon driver has ballooned up, or the swapper has swapped
> something in, or the page sharing daemon has had to un-share pages.
> 
> In the case of #1, I think the right answer to that is, "Don't do
> that."  :-) The admins should co-ordinate with each other about what
> to start where; if they both want to use a bit of memory, that's a
> human interaction problem, not a technological one.  Alternately, if
> we're talking a cloud orchestration layer, the cloud orchestration
> should have an idea how much memory is available on each node, and not
> allow different users to issue commands which would violate those.
> 
> In the case of #2, I think the answer is, "self-directed processes
> should not be allowed to consume free memory without permission from
> the toolstack".  The pager should not increase the memory footprint of
> a VM unless either told to by an admin or a memory controller which
> has been given authority by an admin.  (Yes, memory controller, not
> scheduler -- more on that in another e-mail.)  A VM should be given a
> fixed amount of memory above which the balloon driver cannot go.  The
> page-sharing daemon should have a small amount set aside to handle
> un-sharing requests; but this should be immediately replenished by
> other methods (preferably by ballooning a VM down, or if necessary by
> swapping pages out).  It should not be able to make arbitrarily large
> allocations without permission from the toolstack.

Something that I struggle with here is the notion that we need to extend the hypervisor for any aspect of the discussion we've had so far. I just don't see that. The toolstack has (or should definitely have) a non-racy view of the memory of the host. Reservations are therefore notions the toolstack manages. 

Domains can be cajoled into obedience via the max_pages tweak -- which I profoundly dislike. If anything we should change the hypervisor to have a "current_allowance" or similar field with a more obvious meaning. The abuse of max_pages makes me cringe. Not to say I disagree with its usefulness.

Once you guarantee no "ex machina" entities fudging the view of the memory the toolstack has, then all known methods can be bounded in terms of their capacity to allocate memory unsupervised.

Note that this implies as well, I don't see the need for a pool of "unshare" pages. It's all in the heap. The toolstack ensures there is something set apart. 

I further think the pod cache could be converted to this model. Why have specific per-domain lists of cached pages in the hypervisor? Get them back from the heap! Obviously places a decoupled requirement of certain toolstack features. But allows to throw away a lot of complex code.

My two cents for the new iteration

Andres

> 
> I was chatting with Konrad yesterday, and he brought up
> "self-ballooning" VMs, which apparently vonluntarily choose to balloon
> down to *below* their toolstack-dictated balloon target, in order to
> induce Linux to swap some pages out to tmem, and will then balloon up to
> the toolstack-dictated target later.
> 
> It seems to me that the Right Thing in this case is for the toolstack
> to know that this "free" memory isn't really free -- that if your 2GiB
> VM is only using 1.5GiB, you nonetheless don't touch that 0.5GiB,
> because you know it may use it later.  This is what xapi does.
> 
> Alternately, if you don't want to do that accounting, and just want to
> use Xen's free memory to determine if you can start a VM, then you
> could just have your "self-ballooning" processes *not actually free
> the memory*.  That way the free memory would be an accurate
> representation of how much memory is actually present on a system.
> 
> In all of this discussion, I don't see any reason to bring up tmem at
> all (except to note the reason why a VM may balloon down).  It's just
> another area to which memory can be allocated (along with Xen or a
> domain).  It also should not be allowed to allocate free Xen memory to
> itself without being specifically instructed by the toolstack, so it can't
> cause the problem you're talking about.
> 
> Any system that follows the rules I've set above won't have to worry
> about free memory disappearing half-way through domain creation.
> 
> I'm not fundamentally opposed to the idea of an "allocate memory to a
> VM" hypercall; but the arguments adduced to support this seem
> hopelessly confused, which does not bode well for the usefulness or
> maintainability of such a hypercall.
> 
> -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 18:34:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 18:34:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOYRD-0005QD-Au; Wed, 17 Oct 2012 18:33:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOYRB-0005Q6-Vz
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 18:33:50 +0000
Received: from [85.158.137.99:58961] by server-10.bemta-3.messagelabs.com id
	87/64-27386-D0AFE705; Wed, 17 Oct 2012 18:33:49 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-12.tower-217.messagelabs.com!1350498826!18862835!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4078 invoked from network); 17 Oct 2012 18:33:48 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 18:33:48 -0000
Received: by mail-ie0-f173.google.com with SMTP id 17so15221591iea.32
	for ; Wed, 17 Oct 2012 11:33:46 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=content-type:mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=lyzF8FBNx7msdgywEgDqrvQ+qZzsqwYKwIrwQw/Qeg8=;
	b=LqB5l+QsUuuNpZ9uAvHL/JkClvp4ixHv9CF6hTRZSHR0PkPr+xAMgWIaEyhEcf+0OT
	pbE4sWq8VpuRqaCPS8QtM6bKaairAkK801JqLKikb3Uf9HjuGSLiFqgwf3NOgSMFpHA1
	6WAEvHfuTx66DVc95lSK5df7XxbShFEWp+tEoPC38H1hoPbGO6xQuPP6ySHxigTQF3ry
	xWlHeB4+IpxXS1Wl/tuKUVwL19aRG9nug2zPh51XqHKdcjYYP2By/cWgCjzY344Y/PcI
	fChY36IgTYBohPB0UZLAt5T7FgGAk2dBKSWfma1X61X7C9JZZ7ZqALriYz5QFly41HS2
	V/JQ==
Received: by 10.43.92.71 with SMTP id bp7mr15170065icc.29.1350498826223;
	Wed, 17 Oct 2012 11:33:46 -0700 (PDT)
Received: from [192.168.4.87] ([206.223.182.18])
	by mx.google.com with ESMTPS id rd10sm2020122igb.1.2012.10.17.11.33.42
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 17 Oct 2012 11:33:44 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Andres Lagar-Cavilla 
In-Reply-To: 
Date: Wed, 17 Oct 2012 14:33:41 -0400
Message-Id: <34D83A40-E798-4CF7-9084-83347C7207BB@gridcentric.ca>
References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default>
	<20581.55931.246130.308384@mariner.uk.xensource.com>
	<8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default>
	<20121002091017.GA95926@ocelot.phlegethon.org>
	<66cc0085-1216-40f7-8059-eaf615202c12@default>
	<20121002201624.GA98445@ocelot.phlegethon.org>
	
	<20121004100645.GC38243@ocelot.phlegethon.org>
	<1349345864.650.247.camel@zakaz.uk.xensource.com>
	<239799F4-AF29-494F-86D2-ADF45ACA8792@gridcentric.ca>
	<3e5cf0ba-4241-4f00-bef6-aaff2cc23419@default>
	<506EC710.3020606@eu.citrix.com>
	<58b5a25d-ccdd-4d0c-a0d9-9c249825f7f1@default>
	
	
	
To: George Dunlap 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQnc2MFFxHhRIE6np+VQaOf6yk9lZNicAINwuVzEmnDnitKTT+7XP0aTfR5bNIRG6A3KTJC6
Cc: Dan Magenheimer ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	Konrad Wilk ,
	Andres Lagar-Cavilla ,
	"Tim \(Xen.org\)" , Olaf Hering ,
	xen-devel@lists.xen.org, George Shuklin ,
	Dario Faggioli , Kurt Hackel ,
	Ian Jackson 
Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and
	xl)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Oct 17, 2012, at 1:35 PM, George Dunlap  wrote:

> [Sorry, forgot to reply-to-all]
> 
> On Tue, Oct 16, 2012 at 6:51 PM, Dan Magenheimer
>  wrote:
>> 
>> If you reread my last response with the assumption in mind:
>> 
>>  "tmem == an instance of a memory scheduler == grand vision"
>> 
>> then does the discussion of the "memory reservation" hypercall
>> make more sense?
> 
> Sort of. :-) Unfortunately, I think it shows a bit of confusion, which
> is perhaps why it was hard to understand.
> 
> But let's go back for a minute to the problem at hand: you're afraid
> of free memory disappearing between a toolstack checking for the
> memory, and the toolstack actually creating the VM.
> 
> There are two ways this could happen:
> 
> 1. Another admin command (perhaps by another administrator) has caused
> the memory to go away -- i.e,. another admin has called "xl create",
> or has instructed a VM to balloon up to a higher amount of memory.
> 
> 2. One of the self-directed processes in the system has allocated the
> memory: a balloon driver has ballooned up, or the swapper has swapped
> something in, or the page sharing daemon has had to un-share pages.
> 
> In the case of #1, I think the right answer to that is, "Don't do
> that."  :-) The admins should co-ordinate with each other about what
> to start where; if they both want to use a bit of memory, that's a
> human interaction problem, not a technological one.  Alternately, if
> we're talking a cloud orchestration layer, the cloud orchestration
> should have an idea how much memory is available on each node, and not
> allow different users to issue commands which would violate those.
> 
> In the case of #2, I think the answer is, "self-directed processes
> should not be allowed to consume free memory without permission from
> the toolstack".  The pager should not increase the memory footprint of
> a VM unless either told to by an admin or a memory controller which
> has been given authority by an admin.  (Yes, memory controller, not
> scheduler -- more on that in another e-mail.)  A VM should be given a
> fixed amount of memory above which the balloon driver cannot go.  The
> page-sharing daemon should have a small amount set aside to handle
> un-sharing requests; but this should be immediately replenished by
> other methods (preferably by ballooning a VM down, or if necessary by
> swapping pages out).  It should not be able to make arbitrarily large
> allocations without permission from the toolstack.

Something that I struggle with here is the notion that we need to extend the hypervisor for any aspect of the discussion we've had so far. I just don't see that. The toolstack has (or should definitely have) a non-racy view of the memory of the host. Reservations are therefore notions the toolstack manages. 

Domains can be cajoled into obedience via the max_pages tweak -- which I profoundly dislike. If anything we should change the hypervisor to have a "current_allowance" or similar field with a more obvious meaning. The abuse of max_pages makes me cringe. Not to say I disagree with its usefulness.

Once you guarantee no "ex machina" entities fudging the view of the memory the toolstack has, then all known methods can be bounded in terms of their capacity to allocate memory unsupervised.

Note that this implies as well, I don't see the need for a pool of "unshare" pages. It's all in the heap. The toolstack ensures there is something set apart. 

I further think the pod cache could be converted to this model. Why have specific per-domain lists of cached pages in the hypervisor? Get them back from the heap! Obviously places a decoupled requirement of certain toolstack features. But allows to throw away a lot of complex code.

My two cents for the new iteration

Andres

> 
> I was chatting with Konrad yesterday, and he brought up
> "self-ballooning" VMs, which apparently vonluntarily choose to balloon
> down to *below* their toolstack-dictated balloon target, in order to
> induce Linux to swap some pages out to tmem, and will then balloon up to
> the toolstack-dictated target later.
> 
> It seems to me that the Right Thing in this case is for the toolstack
> to know that this "free" memory isn't really free -- that if your 2GiB
> VM is only using 1.5GiB, you nonetheless don't touch that 0.5GiB,
> because you know it may use it later.  This is what xapi does.
> 
> Alternately, if you don't want to do that accounting, and just want to
> use Xen's free memory to determine if you can start a VM, then you
> could just have your "self-ballooning" processes *not actually free
> the memory*.  That way the free memory would be an accurate
> representation of how much memory is actually present on a system.
> 
> In all of this discussion, I don't see any reason to bring up tmem at
> all (except to note the reason why a VM may balloon down).  It's just
> another area to which memory can be allocated (along with Xen or a
> domain).  It also should not be allowed to allocate free Xen memory to
> itself without being specifically instructed by the toolstack, so it can't
> cause the problem you're talking about.
> 
> Any system that follows the rules I've set above won't have to worry
> about free memory disappearing half-way through domain creation.
> 
> I'm not fundamentally opposed to the idea of an "allocate memory to a
> VM" hypercall; but the arguments adduced to support this seem
> hopelessly confused, which does not bode well for the usefulness or
> maintainability of such a hypercall.
> 
> -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 18:40:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 18:40:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOYWw-0005ZM-4i; Wed, 17 Oct 2012 18:39:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOYWu-0005ZD-7q
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 18:39:44 +0000
Received: from [85.158.139.211:42021] by server-5.bemta-5.messagelabs.com id
	9F/07-09732-F6BFE705; Wed, 17 Oct 2012 18:39:43 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1350499181!22723743!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODA5NzQy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15733 invoked from network); 17 Oct 2012 18:39:42 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Oct 2012 18:39:42 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9HIddD7011795
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for ; Wed, 17 Oct 2012 18:39:40 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9HIdccM003136
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Wed, 17 Oct 2012 18:39:38 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9HIdcF4027109
	for ; Wed, 17 Oct 2012 13:39:38 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 11:39:37 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id CDADC4035B; Wed, 17 Oct 2012 14:27:36 -0400 (EDT)
Date: Wed, 17 Oct 2012 14:27:36 -0400
From: Konrad Rzeszutek Wilk 
To: Joe Jin 
Message-ID: <20121017182736.GA25845@phenom.dumpdata.com>
References: <507CC8F4.4080103@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <507CC8F4.4080103@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: chuang cao ,
	"xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH] tools: xend: fix wrong condition check for
	xml file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 16, 2012 at 10:39:48AM +0800, Joe Jin wrote:
> Hi Konrad,
> 
> Would you please review below fix?

Reviewed-by: Konrad Rzeszutek Wilk 
> 
> Thanks,
> Joe
> 
> 
> In commit e8d40584, it intended to check xml file size and when empty will
> return, the condition should be "if os.path.getsize(xml_path) == 0" rather
> then "if not os.path.getsize(xml_path) == 0".
> 
> Signed-off-by: Chuang Cao 
> Signed-off-by: Joe Jin 
> ---
>  tools/python/xen/xend/XendStateStore.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/python/xen/xend/XendStateStore.py b/tools/python/xen/xend/XendStateStore.py
> index 17a29f1..a66181d 100644
> --- a/tools/python/xen/xend/XendStateStore.py
> +++ b/tools/python/xen/xend/XendStateStore.py
> @@ -101,7 +101,7 @@ class XendStateStore:
>          if not os.path.exists(xml_path):
>              return {}
>  
> -        if not os.path.getsize(xml_path) == 0:
> +        if os.path.getsize(xml_path) == 0:
>              return {}
>  
>          dom = minidom.parse(xml_path)
> -- 
> 1.7.11.7

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 18:40:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 18:40:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOYWw-0005ZM-4i; Wed, 17 Oct 2012 18:39:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOYWu-0005ZD-7q
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 18:39:44 +0000
Received: from [85.158.139.211:42021] by server-5.bemta-5.messagelabs.com id
	9F/07-09732-F6BFE705; Wed, 17 Oct 2012 18:39:43 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1350499181!22723743!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODA5NzQy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15733 invoked from network); 17 Oct 2012 18:39:42 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Oct 2012 18:39:42 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9HIddD7011795
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for ; Wed, 17 Oct 2012 18:39:40 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9HIdccM003136
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Wed, 17 Oct 2012 18:39:38 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9HIdcF4027109
	for ; Wed, 17 Oct 2012 13:39:38 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 11:39:37 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id CDADC4035B; Wed, 17 Oct 2012 14:27:36 -0400 (EDT)
Date: Wed, 17 Oct 2012 14:27:36 -0400
From: Konrad Rzeszutek Wilk 
To: Joe Jin 
Message-ID: <20121017182736.GA25845@phenom.dumpdata.com>
References: <507CC8F4.4080103@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <507CC8F4.4080103@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: chuang cao ,
	"xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH] tools: xend: fix wrong condition check for
	xml file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 16, 2012 at 10:39:48AM +0800, Joe Jin wrote:
> Hi Konrad,
> 
> Would you please review below fix?

Reviewed-by: Konrad Rzeszutek Wilk 
> 
> Thanks,
> Joe
> 
> 
> In commit e8d40584, it intended to check xml file size and when empty will
> return, the condition should be "if os.path.getsize(xml_path) == 0" rather
> then "if not os.path.getsize(xml_path) == 0".
> 
> Signed-off-by: Chuang Cao 
> Signed-off-by: Joe Jin 
> ---
>  tools/python/xen/xend/XendStateStore.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/python/xen/xend/XendStateStore.py b/tools/python/xen/xend/XendStateStore.py
> index 17a29f1..a66181d 100644
> --- a/tools/python/xen/xend/XendStateStore.py
> +++ b/tools/python/xen/xend/XendStateStore.py
> @@ -101,7 +101,7 @@ class XendStateStore:
>          if not os.path.exists(xml_path):
>              return {}
>  
> -        if not os.path.getsize(xml_path) == 0:
> +        if os.path.getsize(xml_path) == 0:
>              return {}
>  
>          dom = minidom.parse(xml_path)
> -- 
> 1.7.11.7

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 18:40:48 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 18:40:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOYXd-0005cx-N3; Wed, 17 Oct 2012 18:40:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOYXc-0005cp-PP
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 18:40:28 +0000
Received: from [193.109.254.147:64198] by server-5.bemta-14.messagelabs.com id
	3B/F1-18309-C9BFE705; Wed, 17 Oct 2012 18:40:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1350499226!10431685!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgxNjgxMg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13575 invoked from network); 17 Oct 2012 18:40:27 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Oct 2012 18:40:27 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9HIeI0q006479
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Oct 2012 18:40:19 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9HIeHWw004754
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Oct 2012 18:40:18 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9HIeHg7001866; Wed, 17 Oct 2012 13:40:17 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 11:40:17 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 018FA4035B; Wed, 17 Oct 2012 14:28:15 -0400 (EDT)
Date: Wed, 17 Oct 2012 14:28:15 -0400
From: Konrad Rzeszutek Wilk 
To: liuxiaolei1124 , roger.pau@citrix.com
Message-ID: <20121017182815.GB25845@phenom.dumpdata.com>
References: <6f0a356f.934c.13a62ccac9a.Coremail.liuxiaolei1124@163.com>
	<20121015131930.GC4000@phenom.dumpdata.com>
	<77e737b0.1e761.13a67dacdbc.Coremail.liuxiaolei1124@163.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <77e737b0.1e761.13a67dacdbc.Coremail.liuxiaolei1124@163.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] about the patch: persistent grant maps for xen blk
	drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 16, 2012 at 12:35:23PM +0800, liuxiaolei1124 wrote:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> At 2012-10-15 21:19:30,"Konrad Rzeszutek Wilk"  wrote:
> >On Mon, Oct 15, 2012 at 01:01:51PM +0800, liuxiaolei1124 wrote:
> >> Dear konrad:
> >>    i have seen you put the patch "persisten grant maps for xen blk drivers" into you kernel, then dom0 crash .(https://lkml.org/lkml/2012/9/21/388 )my dom0 kernel is 2.6.32.36-0.5, and i put this patch in my kernel, there is a bug too, and the stack is much like yours. And i found  a strange phenomenon. when i add a printk log  such as "printk ("enter func") " in blkif_completion or other function in xen-blkfront.c, guest run well. But after i remove this printk log, guest crash when i start.
> >
> >
> >Hey. Roger posted a follow up patch that has this fixed. You should
> >look at that.
> sorry, but i can't find the patch Roger posted, could you show me the link of the patch? thank you.

Roger, could you repost them please?

> Best wishes.
> eric.liu

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 18:40:48 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 18:40:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOYXd-0005cx-N3; Wed, 17 Oct 2012 18:40:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOYXc-0005cp-PP
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 18:40:28 +0000
Received: from [193.109.254.147:64198] by server-5.bemta-14.messagelabs.com id
	3B/F1-18309-C9BFE705; Wed, 17 Oct 2012 18:40:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1350499226!10431685!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgxNjgxMg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13575 invoked from network); 17 Oct 2012 18:40:27 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Oct 2012 18:40:27 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9HIeI0q006479
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Oct 2012 18:40:19 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9HIeHWw004754
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Oct 2012 18:40:18 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9HIeHg7001866; Wed, 17 Oct 2012 13:40:17 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 11:40:17 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 018FA4035B; Wed, 17 Oct 2012 14:28:15 -0400 (EDT)
Date: Wed, 17 Oct 2012 14:28:15 -0400
From: Konrad Rzeszutek Wilk 
To: liuxiaolei1124 , roger.pau@citrix.com
Message-ID: <20121017182815.GB25845@phenom.dumpdata.com>
References: <6f0a356f.934c.13a62ccac9a.Coremail.liuxiaolei1124@163.com>
	<20121015131930.GC4000@phenom.dumpdata.com>
	<77e737b0.1e761.13a67dacdbc.Coremail.liuxiaolei1124@163.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <77e737b0.1e761.13a67dacdbc.Coremail.liuxiaolei1124@163.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] about the patch: persistent grant maps for xen blk
	drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 16, 2012 at 12:35:23PM +0800, liuxiaolei1124 wrote:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> At 2012-10-15 21:19:30,"Konrad Rzeszutek Wilk"  wrote:
> >On Mon, Oct 15, 2012 at 01:01:51PM +0800, liuxiaolei1124 wrote:
> >> Dear konrad:
> >>    i have seen you put the patch "persisten grant maps for xen blk drivers" into you kernel, then dom0 crash .(https://lkml.org/lkml/2012/9/21/388 )my dom0 kernel is 2.6.32.36-0.5, and i put this patch in my kernel, there is a bug too, and the stack is much like yours. And i found  a strange phenomenon. when i add a printk log  such as "printk ("enter func") " in blkif_completion or other function in xen-blkfront.c, guest run well. But after i remove this printk log, guest crash when i start.
> >
> >
> >Hey. Roger posted a follow up patch that has this fixed. You should
> >look at that.
> sorry, but i can't find the patch Roger posted, could you show me the link of the patch? thank you.

Roger, could you repost them please?

> Best wishes.
> eric.liu

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 18:45:54 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 18:45:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOYca-0005ta-Jw; Wed, 17 Oct 2012 18:45:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOYcY-0005tV-UY
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 18:45:35 +0000
Received: from [85.158.139.211:20723] by server-3.bemta-5.messagelabs.com id
	13/9F-28618-ECCFE705; Wed, 17 Oct 2012 18:45:34 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1350499531!22650101!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgxNjgxMg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18731 invoked from network); 17 Oct 2012 18:45:33 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Oct 2012 18:45:33 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9HIjGL5016264
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Oct 2012 18:45:17 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9HIjFGu025128
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Oct 2012 18:45:16 GMT
Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9HIjFaa031106; Wed, 17 Oct 2012 13:45:15 -0500
MIME-Version: 1.0
Message-ID: <023b8ee0-04b5-4a90-9378-44b1f4fd829a@default>
Date: Wed, 17 Oct 2012 11:45:13 -0700 (PDT)
From: Dan Magenheimer 
To: George Dunlap 
References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default>
	<20581.55931.246130.308384@mariner.uk.xensource.com>
	<8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default>
	<20121002091017.GA95926@ocelot.phlegethon.org>
	<66cc0085-1216-40f7-8059-eaf615202c12@default>
	<20121002201624.GA98445@ocelot.phlegethon.org>
	
	<20121004100645.GC38243@ocelot.phlegethon.org>
	<1349345864.650.247.camel@zakaz.uk.xensource.com>
	<239799F4-AF29-494F-86D2-ADF45ACA8792@gridcentric.ca>
	<3e5cf0ba-4241-4f00-bef6-aaff2cc23419@default>
	<506EC710.3020606@eu.citrix.com>
	<58b5a25d-ccdd-4d0c-a0d9-9c249825f7f1@default>
	
	
	
In-Reply-To: 
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Olaf Hering , "Keir \(Xen.org\)" ,
	Ian Campbell ,
	Konrad Wilk ,
	Andres Lagar-Cavilla ,
	"Tim \(Xen.org\)" , xen-devel@lists.xen.org,
	George Shuklin ,
	Dario Faggioli , Kurt Hackel ,
	Ian Jackson 
Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and
	xl)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: George Dunlap [mailto:George.Dunlap@eu.citrix.com]
> Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl)
> 
> On Tue, Oct 16, 2012 at 6:51 PM, Dan Magenheimer
>  wrote:
> >
> > If you reread my last response with the assumption in mind:
> >
> >   "tmem == an instance of a memory scheduler == grand vision"
> >
> > then does the discussion of the "memory reservation" hypercall
> > make more sense?
> 
> Sort of. :-) Unfortunately, I think it shows a bit of confusion, which
> is perhaps why it was hard to understand.
>    :
> I'm not fundamentally opposed to the idea of an "allocate memory to a
> VM" hypercall; but the arguments adduced to support this seem
> hopelessly confused, which does not bode well for the usefulness or
> maintainability of such a hypercall.

Hi George --

Now I think I have a better idea as to why you are not understanding
and why you think this is confusing!!!

It seems we are not only speaking different languages but are
from completely different planets!  I.e. our world views are
very very different.

You have a very very static/partitioned/restrictive/controlled view
of how memory should be managed in a virtual environment.

I have a very very dynamic view of how memory should be managed in
a virtual environment.

Tmem -- and the ability to change guest kernels to cooperate in dynamic
memory management -- very obviously drives my world view, but my view
reveals subtle deficiencies in your world view.  Xapi and the constraints
it lives under (i.e. requirement for proprietary HVM guest kernels)
and the existing Xapi memory controller model seems good enough for
you, so your view makes my need for handling subtle dynamic corner
cases appear that I must have some secret fantastical "grand design"
in mind.

> Any system that follows the rules I've set above won't have to worry
> about free memory disappearing half-way through domain creation.

Agreed.  My claim is that: (1) tmem can't possibly follow your rules
as it would decrease its value/performance by several orders of
magnitude; (2) page-unsharing/swapping can't possibly follow your rules
because the corner cases it must deal with are urgent, frequent, and
unpredictable; (3) a "cloud orchestration layer" can't follow your rules
because of complexity and communication limits, unless it greatly
constrains its flexibility/automation; (4) following your
rules serializes common administration activities even for Xapi
that otherwise don't need to be serialized.

I think your rules take an overconstrained problem (managing memory
for multiple VMs) and add more constraints.  While IMHO tmem takes away
constraints.

That's why I brought up CPU schedulers.  I know you are an expert
in CPU scheduling, and you would never apply similar rules to
CPU scheduling that you want to apply to "memory scheduling".
E.g. you would never require the toolstack to be in the critical
path for every VCPU->CPU reassignment.

And so I have to try to solve a problem that you don't have (or IMHO
that you will likely have in the future but don't admit to yet ;-)
And I think the "reservation" hypercall will solve that problem.

> In all of this discussion, I don't see any reason to bring up tmem at
> all (except to note the reason why a VM may balloon down).  It's just
> another area to which memory can be allocated (along with Xen or a
> domain).  It also should not be allowed to allocate free Xen memory to
> itself without being specifically instructed by the toolstack, so it can't
> cause the problem you're talking about.

This is all very wrong.  It's clear you don't understand why tmem exists,
how it works, and what its value is/can be in the cloud.  I'll take some
of the blame for that because I've had to spend so much time in
Linux-kernel land in the last couple of years.

But if you want to try a different world view, and understand tmem,
let me know ;-)  I don't mean to be immodest, but I truly believe it
is the first significant advance in managing RAM in a virtual
environment in ten years (since Waldspurger).

Dan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 18:45:54 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 18:45:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOYca-0005ta-Jw; Wed, 17 Oct 2012 18:45:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOYcY-0005tV-UY
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 18:45:35 +0000
Received: from [85.158.139.211:20723] by server-3.bemta-5.messagelabs.com id
	13/9F-28618-ECCFE705; Wed, 17 Oct 2012 18:45:34 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1350499531!22650101!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgxNjgxMg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18731 invoked from network); 17 Oct 2012 18:45:33 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Oct 2012 18:45:33 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9HIjGL5016264
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Oct 2012 18:45:17 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9HIjFGu025128
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Oct 2012 18:45:16 GMT
Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9HIjFaa031106; Wed, 17 Oct 2012 13:45:15 -0500
MIME-Version: 1.0
Message-ID: <023b8ee0-04b5-4a90-9378-44b1f4fd829a@default>
Date: Wed, 17 Oct 2012 11:45:13 -0700 (PDT)
From: Dan Magenheimer 
To: George Dunlap 
References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default>
	<20581.55931.246130.308384@mariner.uk.xensource.com>
	<8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default>
	<20121002091017.GA95926@ocelot.phlegethon.org>
	<66cc0085-1216-40f7-8059-eaf615202c12@default>
	<20121002201624.GA98445@ocelot.phlegethon.org>
	
	<20121004100645.GC38243@ocelot.phlegethon.org>
	<1349345864.650.247.camel@zakaz.uk.xensource.com>
	<239799F4-AF29-494F-86D2-ADF45ACA8792@gridcentric.ca>
	<3e5cf0ba-4241-4f00-bef6-aaff2cc23419@default>
	<506EC710.3020606@eu.citrix.com>
	<58b5a25d-ccdd-4d0c-a0d9-9c249825f7f1@default>
	
	
	
In-Reply-To: 
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Olaf Hering , "Keir \(Xen.org\)" ,
	Ian Campbell ,
	Konrad Wilk ,
	Andres Lagar-Cavilla ,
	"Tim \(Xen.org\)" , xen-devel@lists.xen.org,
	George Shuklin ,
	Dario Faggioli , Kurt Hackel ,
	Ian Jackson 
Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and
	xl)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: George Dunlap [mailto:George.Dunlap@eu.citrix.com]
> Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl)
> 
> On Tue, Oct 16, 2012 at 6:51 PM, Dan Magenheimer
>  wrote:
> >
> > If you reread my last response with the assumption in mind:
> >
> >   "tmem == an instance of a memory scheduler == grand vision"
> >
> > then does the discussion of the "memory reservation" hypercall
> > make more sense?
> 
> Sort of. :-) Unfortunately, I think it shows a bit of confusion, which
> is perhaps why it was hard to understand.
>    :
> I'm not fundamentally opposed to the idea of an "allocate memory to a
> VM" hypercall; but the arguments adduced to support this seem
> hopelessly confused, which does not bode well for the usefulness or
> maintainability of such a hypercall.

Hi George --

Now I think I have a better idea as to why you are not understanding
and why you think this is confusing!!!

It seems we are not only speaking different languages but are
from completely different planets!  I.e. our world views are
very very different.

You have a very very static/partitioned/restrictive/controlled view
of how memory should be managed in a virtual environment.

I have a very very dynamic view of how memory should be managed in
a virtual environment.

Tmem -- and the ability to change guest kernels to cooperate in dynamic
memory management -- very obviously drives my world view, but my view
reveals subtle deficiencies in your world view.  Xapi and the constraints
it lives under (i.e. requirement for proprietary HVM guest kernels)
and the existing Xapi memory controller model seems good enough for
you, so your view makes my need for handling subtle dynamic corner
cases appear that I must have some secret fantastical "grand design"
in mind.

> Any system that follows the rules I've set above won't have to worry
> about free memory disappearing half-way through domain creation.

Agreed.  My claim is that: (1) tmem can't possibly follow your rules
as it would decrease its value/performance by several orders of
magnitude; (2) page-unsharing/swapping can't possibly follow your rules
because the corner cases it must deal with are urgent, frequent, and
unpredictable; (3) a "cloud orchestration layer" can't follow your rules
because of complexity and communication limits, unless it greatly
constrains its flexibility/automation; (4) following your
rules serializes common administration activities even for Xapi
that otherwise don't need to be serialized.

I think your rules take an overconstrained problem (managing memory
for multiple VMs) and add more constraints.  While IMHO tmem takes away
constraints.

That's why I brought up CPU schedulers.  I know you are an expert
in CPU scheduling, and you would never apply similar rules to
CPU scheduling that you want to apply to "memory scheduling".
E.g. you would never require the toolstack to be in the critical
path for every VCPU->CPU reassignment.

And so I have to try to solve a problem that you don't have (or IMHO
that you will likely have in the future but don't admit to yet ;-)
And I think the "reservation" hypercall will solve that problem.

> In all of this discussion, I don't see any reason to bring up tmem at
> all (except to note the reason why a VM may balloon down).  It's just
> another area to which memory can be allocated (along with Xen or a
> domain).  It also should not be allowed to allocate free Xen memory to
> itself without being specifically instructed by the toolstack, so it can't
> cause the problem you're talking about.

This is all very wrong.  It's clear you don't understand why tmem exists,
how it works, and what its value is/can be in the cloud.  I'll take some
of the blame for that because I've had to spend so much time in
Linux-kernel land in the last couple of years.

But if you want to try a different world view, and understand tmem,
let me know ;-)  I don't mean to be immodest, but I truly believe it
is the first significant advance in managing RAM in a virtual
environment in ten years (since Waldspurger).

Dan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 19:47:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 19:47:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOZZn-0006Hi-Uj; Wed, 17 Oct 2012 19:46:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOZZm-0006Hc-0q
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 19:46:46 +0000
Received: from [193.109.254.147:9774] by server-2.bemta-14.messagelabs.com id
	65/5D-19917-52B0F705; Wed, 17 Oct 2012 19:46:45 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1350503202!3213576!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgxNjgxMg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15408 invoked from network); 17 Oct 2012 19:46:43 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Oct 2012 19:46:43 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9HJkUBC016119
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Oct 2012 19:46:30 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9HJkTZL004699
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Oct 2012 19:46:29 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9HJkSxS016380; Wed, 17 Oct 2012 14:46:28 -0500
MIME-Version: 1.0
Message-ID: <9a09f64d-693a-4c4a-9d8a-14428969f18b@default>
Date: Wed, 17 Oct 2012 12:46:27 -0700 (PDT)
From: Dan Magenheimer 
To: Andres Lagar-Cavilla , George Dunlap
	
References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default>
	<20581.55931.246130.308384@mariner.uk.xensource.com>
	<8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default>
	<20121002091017.GA95926@ocelot.phlegethon.org>
	<66cc0085-1216-40f7-8059-eaf615202c12@default>
	<20121002201624.GA98445@ocelot.phlegethon.org>
	
	<20121004100645.GC38243@ocelot.phlegethon.org>
	<1349345864.650.247.camel@zakaz.uk.xensource.com>
	<239799F4-AF29-494F-86D2-ADF45ACA8792@gridcentric.ca>
	<3e5cf0ba-4241-4f00-bef6-aaff2cc23419@default>
	<506EC710.3020606@eu.citrix.com>
	<58b5a25d-ccdd-4d0c-a0d9-9c249825f7f1@default>
	
	
	
	<34D83A40-E798-4CF7-9084-83347C7207BB@gridcentric.ca>
In-Reply-To: <34D83A40-E798-4CF7-9084-83347C7207BB@gridcentric.ca>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Olaf Hering , "Keir \(Xen.org\)" ,
	Ian Campbell ,
	Konrad Wilk ,
	George Shuklin ,
	"Tim \(Xen.org\)" , xen-devel@lists.xen.org,
	Dario Faggioli , Kurt Hackel ,
	Ian Jackson 
Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and
	xl)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Andres Lagar-Cavilla [mailto:andreslc@gridcentric.ca]
> Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl)

Hi Andres --

Re reply just sent to George...

I think you must be on a third planet, revolving somewhere between
George's and mine.  I say that because I agree completely with some
of your statements and disagree with the conclusions you draw from
them! :-)

> Domains can be cajoled into obedience via the max_pages tweak -- which I profoundly dislike. If
> anything we should change the hypervisor to have a "current_allowance" or similar field with a more
> obvious meaning. The abuse of max_pages makes me cringe. Not to say I disagree with its usefulness.

Me cringes too.  Though I can see from George's view that it makes
perfect sense.  Since the toolstack always controls exactly how
much memory is assigned to a domain and since it can cache the
"original max", current allowance and the hypervisors view of
max_pages must always be the same.

Only if the hypervisor or the domain or the domain's administrator
can tweak current memory usage without the knowledge of the
toolstack (which is closer to my planet) does an issue arise.
And, to me, that's the foundation of this whole thread.

> Once you guarantee no "ex machina" entities fudging the view of the memory the toolstack has, then all
> known methods can be bounded in terms of their capacity to allocate memory unsupervised.
> Note that this implies as well, I don't see the need for a pool of "unshare" pages. It's all in the
> heap. The toolstack ensures there is something set apart.

By "ex machina" do you mean "without the toolstack's knowledge"?

Then how does page-unsharing work?  Does every page-unshare done by
the hypervisor require serial notification/permission of the toolstack?
Or is this "batched", in which case a pool is necessary, isn't it?
(Not sure what you mean by "no need for a pool" and then "toolstack
ensures there is something set apart"... what's the difference?)

My point is, whether there is no pool or a pool that sometimes
runs dry, are you really going to put the toolstack in the hypervisor's
path for allocating a page so that the hypervisor can allocate
a new page for CoW to fulfill an unshare?

> Something that I struggle with here is the notion that we need to extend the hypervisor for any aspect
> of the discussion we've had so far. I just don't see that. The toolstack has (or should definitely
> have) a non-racy view of the memory of the host. Reservations are therefore notions the toolstack
> manages.

In a perfect world where the toolstack has an oracle for the
precise time-varying memory requirements for all guests, I
would agree.

In that world, there's no need for a CPU scheduler either...
the toolstack can decide exactly when to assign each VCPU for
each VM onto each PCPU, and when to stop and reassign.
And then every PCPU would be maximally utilized, right?

My point: Why would you resource-manage CPUs differently from
memory?  The demand of real-world workloads varies dramatically
for both... don't you want both to be managed dynamically,
whenever possible?

If yes (dynamic is good), in order for the toolstack's view of
memory to be non-racy, doesn't every hypervisor page allocation
need to be serialized with the toolstack granting notification/permission?

> I further think the pod cache could be converted to this model. Why have specific per-domain lists of
> cached pages in the hypervisor? Get them back from the heap! Obviously places a decoupled requirement
> of certain toolstack features. But allows to throw away a lot of complex code.

IIUC in George's (Xapi) model (or using Tim's phrase, "balloon-to-fit")
the heap is "always" empty because the toolstack has assigned all memory.
So I'm still confused... where does "page unshare" get memory from
and how does it notify and/or get permission from the toolstack?

> My two cents for the new iteration

I'll see your two cents, and raise you a penny! ;-)

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 19:47:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 19:47:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOZZn-0006Hi-Uj; Wed, 17 Oct 2012 19:46:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOZZm-0006Hc-0q
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 19:46:46 +0000
Received: from [193.109.254.147:9774] by server-2.bemta-14.messagelabs.com id
	65/5D-19917-52B0F705; Wed, 17 Oct 2012 19:46:45 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1350503202!3213576!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgxNjgxMg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15408 invoked from network); 17 Oct 2012 19:46:43 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Oct 2012 19:46:43 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9HJkUBC016119
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Oct 2012 19:46:30 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9HJkTZL004699
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Oct 2012 19:46:29 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9HJkSxS016380; Wed, 17 Oct 2012 14:46:28 -0500
MIME-Version: 1.0
Message-ID: <9a09f64d-693a-4c4a-9d8a-14428969f18b@default>
Date: Wed, 17 Oct 2012 12:46:27 -0700 (PDT)
From: Dan Magenheimer 
To: Andres Lagar-Cavilla , George Dunlap
	
References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default>
	<20581.55931.246130.308384@mariner.uk.xensource.com>
	<8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default>
	<20121002091017.GA95926@ocelot.phlegethon.org>
	<66cc0085-1216-40f7-8059-eaf615202c12@default>
	<20121002201624.GA98445@ocelot.phlegethon.org>
	
	<20121004100645.GC38243@ocelot.phlegethon.org>
	<1349345864.650.247.camel@zakaz.uk.xensource.com>
	<239799F4-AF29-494F-86D2-ADF45ACA8792@gridcentric.ca>
	<3e5cf0ba-4241-4f00-bef6-aaff2cc23419@default>
	<506EC710.3020606@eu.citrix.com>
	<58b5a25d-ccdd-4d0c-a0d9-9c249825f7f1@default>
	
	
	
	<34D83A40-E798-4CF7-9084-83347C7207BB@gridcentric.ca>
In-Reply-To: <34D83A40-E798-4CF7-9084-83347C7207BB@gridcentric.ca>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Olaf Hering , "Keir \(Xen.org\)" ,
	Ian Campbell ,
	Konrad Wilk ,
	George Shuklin ,
	"Tim \(Xen.org\)" , xen-devel@lists.xen.org,
	Dario Faggioli , Kurt Hackel ,
	Ian Jackson 
Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and
	xl)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Andres Lagar-Cavilla [mailto:andreslc@gridcentric.ca]
> Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl)

Hi Andres --

Re reply just sent to George...

I think you must be on a third planet, revolving somewhere between
George's and mine.  I say that because I agree completely with some
of your statements and disagree with the conclusions you draw from
them! :-)

> Domains can be cajoled into obedience via the max_pages tweak -- which I profoundly dislike. If
> anything we should change the hypervisor to have a "current_allowance" or similar field with a more
> obvious meaning. The abuse of max_pages makes me cringe. Not to say I disagree with its usefulness.

Me cringes too.  Though I can see from George's view that it makes
perfect sense.  Since the toolstack always controls exactly how
much memory is assigned to a domain and since it can cache the
"original max", current allowance and the hypervisors view of
max_pages must always be the same.

Only if the hypervisor or the domain or the domain's administrator
can tweak current memory usage without the knowledge of the
toolstack (which is closer to my planet) does an issue arise.
And, to me, that's the foundation of this whole thread.

> Once you guarantee no "ex machina" entities fudging the view of the memory the toolstack has, then all
> known methods can be bounded in terms of their capacity to allocate memory unsupervised.
> Note that this implies as well, I don't see the need for a pool of "unshare" pages. It's all in the
> heap. The toolstack ensures there is something set apart.

By "ex machina" do you mean "without the toolstack's knowledge"?

Then how does page-unsharing work?  Does every page-unshare done by
the hypervisor require serial notification/permission of the toolstack?
Or is this "batched", in which case a pool is necessary, isn't it?
(Not sure what you mean by "no need for a pool" and then "toolstack
ensures there is something set apart"... what's the difference?)

My point is, whether there is no pool or a pool that sometimes
runs dry, are you really going to put the toolstack in the hypervisor's
path for allocating a page so that the hypervisor can allocate
a new page for CoW to fulfill an unshare?

> Something that I struggle with here is the notion that we need to extend the hypervisor for any aspect
> of the discussion we've had so far. I just don't see that. The toolstack has (or should definitely
> have) a non-racy view of the memory of the host. Reservations are therefore notions the toolstack
> manages.

In a perfect world where the toolstack has an oracle for the
precise time-varying memory requirements for all guests, I
would agree.

In that world, there's no need for a CPU scheduler either...
the toolstack can decide exactly when to assign each VCPU for
each VM onto each PCPU, and when to stop and reassign.
And then every PCPU would be maximally utilized, right?

My point: Why would you resource-manage CPUs differently from
memory?  The demand of real-world workloads varies dramatically
for both... don't you want both to be managed dynamically,
whenever possible?

If yes (dynamic is good), in order for the toolstack's view of
memory to be non-racy, doesn't every hypervisor page allocation
need to be serialized with the toolstack granting notification/permission?

> I further think the pod cache could be converted to this model. Why have specific per-domain lists of
> cached pages in the hypervisor? Get them back from the heap! Obviously places a decoupled requirement
> of certain toolstack features. But allows to throw away a lot of complex code.

IIUC in George's (Xapi) model (or using Tim's phrase, "balloon-to-fit")
the heap is "always" empty because the toolstack has assigned all memory.
So I'm still confused... where does "page unshare" get memory from
and how does it notify and/or get permission from the toolstack?

> My two cents for the new iteration

I'll see your two cents, and raise you a penny! ;-)

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 20:07:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 20:07:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOZtP-0006qF-IA; Wed, 17 Oct 2012 20:07:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOZtO-0006q9-6G
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 20:07:02 +0000
Received: from [85.158.139.83:8213] by server-11.bemta-5.messagelabs.com id
	D2/E3-14870-5EF0F705; Wed, 17 Oct 2012 20:07:01 +0000
X-Env-Sender: stse@fsing.rootsland.net
X-Msg-Ref: server-3.tower-182.messagelabs.com!1350504420!35317420!1
X-Originating-IP: [62.141.37.30]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1154 invoked from network); 17 Oct 2012 20:07:00 -0000
Received: from fsing.rootsland.net (HELO fsing.rootsland.net) (62.141.37.30)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Oct 2012 20:07:00 -0000
Received: from osgiliath.gondor (mue-88-130-28-117.dsl.tropolys.de
	[88.130.28.117])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "Stephan Seitz", Issuer "CAcert Class 3 Root" (verified OK))
	by fsing.rootsland.net (Postfix) with ESMTPS id 7684FC95001A;
	Wed, 17 Oct 2012 22:07:00 +0200 (CEST)
X-DKIM: OpenDKIM Filter v2.6.2 fsing.rootsland.net 7684FC95001A
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fsing.rootsland.net;
	s=mail20100714; t=1350504420;
	bh=M7NHyTqwn9XdJ13G8T+PSDfozvSeoyrsKAZM6LTJg94=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To;
	b=qbVJqRp5zNyy7+da5Wh8o4g9sfJ+a6BCxfF3P6vp+qrLXzATXdyfCVR3QXD5ynjrP
	ysMHll1XMhm3vdlacKx0iwIdl0S8ZM8v9RrsWpLgEyMYY50st3vh3jMewXfNsCIEyl
	2xM3M4BzWfOvNUZ6OC8IWl9+u4DqWGAXo+QX0vz4=
Received: by osgiliath.gondor (Postfix, from userid 10009)
	id E0176600A9; Wed, 17 Oct 2012 22:06:59 +0200 (CEST)
Date: Wed, 17 Oct 2012 22:06:59 +0200
From: Stephan Seitz 
To: xen-devel 
Message-ID: <20121017T220352.GA.c4652.stse@fsing.rootsland.net>
References: <20121016T192158.GA.6e659.stse@fsing.rootsland.net>
	
MIME-Version: 1.0
In-Reply-To: 
Organization: Minas Tirith, Gondor
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] CPU microcode update under xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============2993817278915079076=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============2993817278915079076==
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
	micalg=sha1; boundary="bi5JUZtvcfApsciF"
Content-Disposition: inline


--bi5JUZtvcfApsciF
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Oct 16, 2012 at 01:54:59PM -0400, Ben Guthro wrote:
>This is not yet merged.
>
>You'll need to look at the following branch from Konrad:
>http://git.kernel.org/?p=3Dlinux/kernel/git/konrad/xen.git;a=3Dshortlog;h=
=3Drefs/heads/stable/misc

Thanks for your answer.

>primarily, the following changesets:
>23757fb5d6781bf945d21d1f5373aa71122cbea9
>f6c958ff0d00ffbf1cdc8fcf2f2a82f06fbbb5f4

Those patches are about one year old. Any reasons why they are not merged=
=20
yet?

	Stephan

--=20
| Stephan Seitz          E-Mail: stse@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |

--bi5JUZtvcfApsciF
Content-Type: application/x-pkcs7-signature
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIIOIQYJKoZIhvcNAQcCoIIOEjCCDg4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
C4wwggYIMIID8KADAgECAgEBMA0GCSqGSIb3DQEBBAUAMHkxEDAOBgNVBAoTB1Jvb3QgQ0Ex
HjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWdu
aW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnMB4XDTA1
MTAxNDA3MzY1NVoXDTMzMDMyODA3MzY1NVowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAc
BgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMg
Um9vdDCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAKtJNRFIfNImflOUz0Op3SjX
QiqL84d4GVh8D57aiX3h++tykA10oZZkq5+gJJlz2uJVdscXe/UErEa4w75/ZI0QbCTzYZzA
8pD6Ueb1aQFjww9W4kpCz+JEjCUoqMV5CX1GuYrz6fM0KQhF5Byfy5QEHIGoFLOYZcRD7E6C
jQnRvapbjZLQ7N6QxX8KwuPr5jFaXnQ+lzNZ6MMDPWAzv/fRb0fEze5ig1JuLgiapNkVGJGm
hZJHsK5I6223IeyFGmhyNav/8BBdwPSUp2rVO5J+TJAFfpPBLIukjmJ0FXFuC3ED6q8VOJrU
0gVyb4z5K+taciX5OUbjchs+BMNkJyIQKopPWKcDrb60LhPtXapI19V91Cp7XPpGBFDkzA5C
W4zt2/LP/JaT4NsRNlRiNDiPDGCbO5dWOK3z0luLoFvqTpa4fNfVoIZwQNORKbeiPK31jLvP
GpKK5DR7wNhsX+kKwsOnIJpa3yxdUly6R9Wb7yQocDggL9V/KcCyQQNokszgnMyXS0XvOhAK
q3A6mJVwrTWx6oUrpByAITGprmB6gCZIALgBwJNjVSKRPFbnr9s6JfOPMVTqJouBWfmh0VMR
xXudA/Z0EeBtsSw/LIaRmXGapneLNGDRFLQsrJ2vjBDTn8Rq+G8T/HNZ92ZCdB6K4/jc0m+Y
nMtHmJVABfvpAgMBAAGjgb8wgbwwDwYDVR0TAQH/BAUwAwEB/zBdBggrBgEFBQcBAQRRME8w
IwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLkNBY2VydC5vcmcvMCgGCCsGAQUFBzAChhxodHRw
Oi8vd3d3LkNBY2VydC5vcmcvY2EuY3J0MEoGA1UdIARDMEEwPwYIKwYBBAGBkEowMzAxBggr
BgEFBQcCARYlaHR0cDovL3d3dy5DQWNlcnQub3JnL2luZGV4LnBocD9pZD0xMDANBgkqhkiG
9w0BAQQFAAOCAgEAfwiIodoaUEnaifuhCHLzivcexDq0eVsgMLFF3sJd02Vp8cJdVFQ8hV+5
e0KRwpn9G1Gbq0aloRBTnm2IrHNuLDOm8PSe4HXBPohFqeFmQ/5WWtF6QXj3QNpKOvELW6W7
FgbmwueTuYVNl0+xHjhDgO+bDYzvuKdgAIdXfR5EHMsj75s8mZ2vtSkcRXkWlk0nbfEcbMPC
VWSzvBTi86QfHjL8JxUFz90urj6CYXvwIRAY9kTqUzn53NCaIODGu+C7Wk/EmcgHvbW9otsu
Yg1CNEG8/4uK9VEiqogwAOKw1Ly+ZbrVA1d5m+jcyE34UO2RpVIooqz7Nlg+6ZQrkVCHG9Ze
1ozM9w8QDFJO0BZh5eUKbL8Xx3JGV5yY9WxgY3pvXrlOL8i5ubtqhbyYDe35PpeENJSuAK+h
5eeSbk698+LZFItc0usBbKAXpS0Q65x6Sr297s797SJAq3A4iPUKh2rCqwVgyUgF2lPB3kR3
arPzPDztgLymOEopJF/+WTubJXpWYwBkuV2kYn1XNk+tg+8fklOgjndX3eVhET0jAJBMPPqj
YJMEo6819g5qj09KYKeFBWxGoY/0x3bjoVlX93GyxG4UXG1tQWbfG5Ox1ADD7svPPD0hgKlf
Y2X83eBfpPQr8IVxQdRnJfsasZeu1pmCE0HSbqUbmSeA5wupqAAwggV8MIIDZKADAgECAgMA
7qMwDQYJKoZIhvcNAQEFBQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0
dHA6Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDAeFw0x
MjAyMDcwOTQ3NDVaFw0xNDAyMDYwOTQ3NDVaMHoxFjAUBgNVBAMTDVN0ZXBoYW4gU2VpdHox
JzAlBgkqhkiG9w0BCQEWGHN0c2VAZnNpbmcucm9vdHNsYW5kLm5ldDE3MDUGCSqGSIb3DQEJ
ARYoYjAyOTM1ZjY0MzY2ZWJjNTMyNzRkZWFlNzdjNTlmNWQ0NjFkMzA5MjCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBANmTAhUdu+xjRo+1NWftASWgV7mYi1Gdfdukbr0OcsYL
nxveMvFuTnwzF9IvX18nGes2PKBDtZDwO/CmzBwFw9HHi9ewy1iSJSRZ1PoklFdUts4PsqHh
SF3X9m+NOYtXTHmnzzVphwjtQW4pkzo5r2eF7SWg8sUZeIw5ZTpUa1dJZ2StXhX/4IQJS+vy
4lPBwrthxABsOYeNDVo65k+r4hwuo4LujnbEXetRfgx1nsWsfklZkPmSwKrLLiGKKl7CnLLX
z2ayURu2Z5J9GM/6DJw+BCTwgHKpPc/ERLrRHUw7W7cETaaKqpgMVE4se1v/jJo2C4oKa2qS
iJXQGvxZUzkCAwEAAaOCAS8wggErMAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1Rv
IGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDov
L3d3dy5DQWNlcnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGC
NwoDBAYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcw
AYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzBNBgNVHREERjBEgRhzdHNlQGZzaW5nLnJvb3Rz
bGFuZC5uZXSBKGIwMjkzNWY2NDM2NmViYzUzMjc0ZGVhZTc3YzU5ZjVkNDYxZDMwOTIwDQYJ
KoZIhvcNAQEFBQADggIBABULJCng9rYUzDvpGoGlmz0mxmAO459Son4/lyx8cayyucnqWMgl
/RP3rmKtLg6brRPLrowTyOEpwZ12jR/JSGWv5B8rjWza3hAWHofQ+6HfP0RPTO2vTFyUaLcD
OZ4buknqHAYaS2gp1d2KVBjvrs4QjhS65/0o6tVvA3inAIkQ1h1t9bK8UC0NiA33QIzYhJKF
p3/VTqEOKC/B44mSZ57MJ2uQ0mAUpvbQKpUE74FGIsfgKgTSoZqimsaJjYB3tn4lGzBjYVff
Hi8dmVL1Q0nb93Qae/wXvJaboVW5ztNNFdKrpoQUuNkyssNBoHRA/QPpK2RVkDK+YGza0gEb
832naD4QdZTiiPuzjfV/a8p71TTyHp1eHjvkOU8yKL9DUpLPgX06VRkm+FqjXa7xWis8Jdbl
puXokx5YHifeJjDSci/9apkncZT5tMBNQvSJvjJ+TDMxdrF0rYl8rJMRzg+ckxHeSpw396XU
V8dMgoqFZTasaXqLGDIRqmT381EjBMoZIuxhQochks3Zyq+3QG3wPz98jTQorcF7nS2xMu4O
ovLlQQw6cVAySNX6W6ywVsGbZOZ3+tEIb5WuBgQqe0/eWIt6BhDco8zDzU9dyI2cTrkxxcOp
f1gijBskSDEFwAOjBtDRTzL5vhib+TS3tCQLupcXA29M6pv92YuaDW9zMYICXTCCAlkCAQEw
WzBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQu
b3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290AgMA7qMwCQYFKw4DAhoFAKCB2DAY
BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjEwMTcyMDA2NTla
MCMGCSqGSIb3DQEJBDEWBBQ/9yuiX4gmvoPrw732JBIMB5Vi1DB5BgkqhkiG9w0BCQ8xbDBq
MAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G
CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAN
BgkqhkiG9w0BAQEFAASCAQAAhNEE343jKyYHHRyNmgxodWzQnZSHcTC0X9lK/rdiFIsHJ8Ai
NHxQh0XmtRtSv2ksVwHT6E03C4pIMTGvKr3FYwGINYzCwzK3VUIY2sUwjncmhfs4LaRawjdT
TxB8fgBNI42Sp6jyzF4GREw3q2TxI84Qp5JeS8wPrRpUeAb/HzuN7UspG/lBIWhpbCa/BOG8
BuIP9XuRL0J4OOetgweEU0+S+9DNQv+5+akG14VRoMjaOgsphCrygYty1NkGKbVCstunf97h
lPopsUFNraalV1gqj0v/ZjgsQyS51gWzclBfmYlLO2zMJQ7XVubwFwYG3YfLlUc3kOolpzb9
3U+q

--bi5JUZtvcfApsciF--


--===============2993817278915079076==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2993817278915079076==--


From xen-devel-bounces@lists.xen.org Wed Oct 17 20:07:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 20:07:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOZtP-0006qF-IA; Wed, 17 Oct 2012 20:07:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOZtO-0006q9-6G
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 20:07:02 +0000
Received: from [85.158.139.83:8213] by server-11.bemta-5.messagelabs.com id
	D2/E3-14870-5EF0F705; Wed, 17 Oct 2012 20:07:01 +0000
X-Env-Sender: stse@fsing.rootsland.net
X-Msg-Ref: server-3.tower-182.messagelabs.com!1350504420!35317420!1
X-Originating-IP: [62.141.37.30]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1154 invoked from network); 17 Oct 2012 20:07:00 -0000
Received: from fsing.rootsland.net (HELO fsing.rootsland.net) (62.141.37.30)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Oct 2012 20:07:00 -0000
Received: from osgiliath.gondor (mue-88-130-28-117.dsl.tropolys.de
	[88.130.28.117])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "Stephan Seitz", Issuer "CAcert Class 3 Root" (verified OK))
	by fsing.rootsland.net (Postfix) with ESMTPS id 7684FC95001A;
	Wed, 17 Oct 2012 22:07:00 +0200 (CEST)
X-DKIM: OpenDKIM Filter v2.6.2 fsing.rootsland.net 7684FC95001A
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fsing.rootsland.net;
	s=mail20100714; t=1350504420;
	bh=M7NHyTqwn9XdJ13G8T+PSDfozvSeoyrsKAZM6LTJg94=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To;
	b=qbVJqRp5zNyy7+da5Wh8o4g9sfJ+a6BCxfF3P6vp+qrLXzATXdyfCVR3QXD5ynjrP
	ysMHll1XMhm3vdlacKx0iwIdl0S8ZM8v9RrsWpLgEyMYY50st3vh3jMewXfNsCIEyl
	2xM3M4BzWfOvNUZ6OC8IWl9+u4DqWGAXo+QX0vz4=
Received: by osgiliath.gondor (Postfix, from userid 10009)
	id E0176600A9; Wed, 17 Oct 2012 22:06:59 +0200 (CEST)
Date: Wed, 17 Oct 2012 22:06:59 +0200
From: Stephan Seitz 
To: xen-devel 
Message-ID: <20121017T220352.GA.c4652.stse@fsing.rootsland.net>
References: <20121016T192158.GA.6e659.stse@fsing.rootsland.net>
	
MIME-Version: 1.0
In-Reply-To: 
Organization: Minas Tirith, Gondor
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] CPU microcode update under xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============2993817278915079076=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============2993817278915079076==
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
	micalg=sha1; boundary="bi5JUZtvcfApsciF"
Content-Disposition: inline


--bi5JUZtvcfApsciF
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Oct 16, 2012 at 01:54:59PM -0400, Ben Guthro wrote:
>This is not yet merged.
>
>You'll need to look at the following branch from Konrad:
>http://git.kernel.org/?p=3Dlinux/kernel/git/konrad/xen.git;a=3Dshortlog;h=
=3Drefs/heads/stable/misc

Thanks for your answer.

>primarily, the following changesets:
>23757fb5d6781bf945d21d1f5373aa71122cbea9
>f6c958ff0d00ffbf1cdc8fcf2f2a82f06fbbb5f4

Those patches are about one year old. Any reasons why they are not merged=
=20
yet?

	Stephan

--=20
| Stephan Seitz          E-Mail: stse@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |

--bi5JUZtvcfApsciF
Content-Type: application/x-pkcs7-signature
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIIOIQYJKoZIhvcNAQcCoIIOEjCCDg4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
C4wwggYIMIID8KADAgECAgEBMA0GCSqGSIb3DQEBBAUAMHkxEDAOBgNVBAoTB1Jvb3QgQ0Ex
HjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWdu
aW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnMB4XDTA1
MTAxNDA3MzY1NVoXDTMzMDMyODA3MzY1NVowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAc
BgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMg
Um9vdDCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAKtJNRFIfNImflOUz0Op3SjX
QiqL84d4GVh8D57aiX3h++tykA10oZZkq5+gJJlz2uJVdscXe/UErEa4w75/ZI0QbCTzYZzA
8pD6Ueb1aQFjww9W4kpCz+JEjCUoqMV5CX1GuYrz6fM0KQhF5Byfy5QEHIGoFLOYZcRD7E6C
jQnRvapbjZLQ7N6QxX8KwuPr5jFaXnQ+lzNZ6MMDPWAzv/fRb0fEze5ig1JuLgiapNkVGJGm
hZJHsK5I6223IeyFGmhyNav/8BBdwPSUp2rVO5J+TJAFfpPBLIukjmJ0FXFuC3ED6q8VOJrU
0gVyb4z5K+taciX5OUbjchs+BMNkJyIQKopPWKcDrb60LhPtXapI19V91Cp7XPpGBFDkzA5C
W4zt2/LP/JaT4NsRNlRiNDiPDGCbO5dWOK3z0luLoFvqTpa4fNfVoIZwQNORKbeiPK31jLvP
GpKK5DR7wNhsX+kKwsOnIJpa3yxdUly6R9Wb7yQocDggL9V/KcCyQQNokszgnMyXS0XvOhAK
q3A6mJVwrTWx6oUrpByAITGprmB6gCZIALgBwJNjVSKRPFbnr9s6JfOPMVTqJouBWfmh0VMR
xXudA/Z0EeBtsSw/LIaRmXGapneLNGDRFLQsrJ2vjBDTn8Rq+G8T/HNZ92ZCdB6K4/jc0m+Y
nMtHmJVABfvpAgMBAAGjgb8wgbwwDwYDVR0TAQH/BAUwAwEB/zBdBggrBgEFBQcBAQRRME8w
IwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLkNBY2VydC5vcmcvMCgGCCsGAQUFBzAChhxodHRw
Oi8vd3d3LkNBY2VydC5vcmcvY2EuY3J0MEoGA1UdIARDMEEwPwYIKwYBBAGBkEowMzAxBggr
BgEFBQcCARYlaHR0cDovL3d3dy5DQWNlcnQub3JnL2luZGV4LnBocD9pZD0xMDANBgkqhkiG
9w0BAQQFAAOCAgEAfwiIodoaUEnaifuhCHLzivcexDq0eVsgMLFF3sJd02Vp8cJdVFQ8hV+5
e0KRwpn9G1Gbq0aloRBTnm2IrHNuLDOm8PSe4HXBPohFqeFmQ/5WWtF6QXj3QNpKOvELW6W7
FgbmwueTuYVNl0+xHjhDgO+bDYzvuKdgAIdXfR5EHMsj75s8mZ2vtSkcRXkWlk0nbfEcbMPC
VWSzvBTi86QfHjL8JxUFz90urj6CYXvwIRAY9kTqUzn53NCaIODGu+C7Wk/EmcgHvbW9otsu
Yg1CNEG8/4uK9VEiqogwAOKw1Ly+ZbrVA1d5m+jcyE34UO2RpVIooqz7Nlg+6ZQrkVCHG9Ze
1ozM9w8QDFJO0BZh5eUKbL8Xx3JGV5yY9WxgY3pvXrlOL8i5ubtqhbyYDe35PpeENJSuAK+h
5eeSbk698+LZFItc0usBbKAXpS0Q65x6Sr297s797SJAq3A4iPUKh2rCqwVgyUgF2lPB3kR3
arPzPDztgLymOEopJF/+WTubJXpWYwBkuV2kYn1XNk+tg+8fklOgjndX3eVhET0jAJBMPPqj
YJMEo6819g5qj09KYKeFBWxGoY/0x3bjoVlX93GyxG4UXG1tQWbfG5Ox1ADD7svPPD0hgKlf
Y2X83eBfpPQr8IVxQdRnJfsasZeu1pmCE0HSbqUbmSeA5wupqAAwggV8MIIDZKADAgECAgMA
7qMwDQYJKoZIhvcNAQEFBQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0
dHA6Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDAeFw0x
MjAyMDcwOTQ3NDVaFw0xNDAyMDYwOTQ3NDVaMHoxFjAUBgNVBAMTDVN0ZXBoYW4gU2VpdHox
JzAlBgkqhkiG9w0BCQEWGHN0c2VAZnNpbmcucm9vdHNsYW5kLm5ldDE3MDUGCSqGSIb3DQEJ
ARYoYjAyOTM1ZjY0MzY2ZWJjNTMyNzRkZWFlNzdjNTlmNWQ0NjFkMzA5MjCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBANmTAhUdu+xjRo+1NWftASWgV7mYi1Gdfdukbr0OcsYL
nxveMvFuTnwzF9IvX18nGes2PKBDtZDwO/CmzBwFw9HHi9ewy1iSJSRZ1PoklFdUts4PsqHh
SF3X9m+NOYtXTHmnzzVphwjtQW4pkzo5r2eF7SWg8sUZeIw5ZTpUa1dJZ2StXhX/4IQJS+vy
4lPBwrthxABsOYeNDVo65k+r4hwuo4LujnbEXetRfgx1nsWsfklZkPmSwKrLLiGKKl7CnLLX
z2ayURu2Z5J9GM/6DJw+BCTwgHKpPc/ERLrRHUw7W7cETaaKqpgMVE4se1v/jJo2C4oKa2qS
iJXQGvxZUzkCAwEAAaOCAS8wggErMAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1Rv
IGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDov
L3d3dy5DQWNlcnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGC
NwoDBAYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcw
AYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzBNBgNVHREERjBEgRhzdHNlQGZzaW5nLnJvb3Rz
bGFuZC5uZXSBKGIwMjkzNWY2NDM2NmViYzUzMjc0ZGVhZTc3YzU5ZjVkNDYxZDMwOTIwDQYJ
KoZIhvcNAQEFBQADggIBABULJCng9rYUzDvpGoGlmz0mxmAO459Son4/lyx8cayyucnqWMgl
/RP3rmKtLg6brRPLrowTyOEpwZ12jR/JSGWv5B8rjWza3hAWHofQ+6HfP0RPTO2vTFyUaLcD
OZ4buknqHAYaS2gp1d2KVBjvrs4QjhS65/0o6tVvA3inAIkQ1h1t9bK8UC0NiA33QIzYhJKF
p3/VTqEOKC/B44mSZ57MJ2uQ0mAUpvbQKpUE74FGIsfgKgTSoZqimsaJjYB3tn4lGzBjYVff
Hi8dmVL1Q0nb93Qae/wXvJaboVW5ztNNFdKrpoQUuNkyssNBoHRA/QPpK2RVkDK+YGza0gEb
832naD4QdZTiiPuzjfV/a8p71TTyHp1eHjvkOU8yKL9DUpLPgX06VRkm+FqjXa7xWis8Jdbl
puXokx5YHifeJjDSci/9apkncZT5tMBNQvSJvjJ+TDMxdrF0rYl8rJMRzg+ckxHeSpw396XU
V8dMgoqFZTasaXqLGDIRqmT381EjBMoZIuxhQochks3Zyq+3QG3wPz98jTQorcF7nS2xMu4O
ovLlQQw6cVAySNX6W6ywVsGbZOZ3+tEIb5WuBgQqe0/eWIt6BhDco8zDzU9dyI2cTrkxxcOp
f1gijBskSDEFwAOjBtDRTzL5vhib+TS3tCQLupcXA29M6pv92YuaDW9zMYICXTCCAlkCAQEw
WzBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQu
b3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290AgMA7qMwCQYFKw4DAhoFAKCB2DAY
BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjEwMTcyMDA2NTla
MCMGCSqGSIb3DQEJBDEWBBQ/9yuiX4gmvoPrw732JBIMB5Vi1DB5BgkqhkiG9w0BCQ8xbDBq
MAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G
CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAN
BgkqhkiG9w0BAQEFAASCAQAAhNEE343jKyYHHRyNmgxodWzQnZSHcTC0X9lK/rdiFIsHJ8Ai
NHxQh0XmtRtSv2ksVwHT6E03C4pIMTGvKr3FYwGINYzCwzK3VUIY2sUwjncmhfs4LaRawjdT
TxB8fgBNI42Sp6jyzF4GREw3q2TxI84Qp5JeS8wPrRpUeAb/HzuN7UspG/lBIWhpbCa/BOG8
BuIP9XuRL0J4OOetgweEU0+S+9DNQv+5+akG14VRoMjaOgsphCrygYty1NkGKbVCstunf97h
lPopsUFNraalV1gqj0v/ZjgsQyS51gWzclBfmYlLO2zMJQ7XVubwFwYG3YfLlUc3kOolpzb9
3U+q

--bi5JUZtvcfApsciF--


--===============2993817278915079076==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2993817278915079076==--


From xen-devel-bounces@lists.xen.org Wed Oct 17 20:15:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 20:15:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOa1G-0006zj-KS; Wed, 17 Oct 2012 20:15:10 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOa1E-0006ze-GD
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 20:15:08 +0000
Received: from [193.109.254.147:38654] by server-15.bemta-14.messagelabs.com
	id 94/27-16351-BC11F705; Wed, 17 Oct 2012 20:15:07 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-13.tower-27.messagelabs.com!1350504904!10347969!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23750 invoked from network); 17 Oct 2012 20:15:05 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 20:15:05 -0000
Received: by mail-ie0-f173.google.com with SMTP id 17so15428595iea.32
	for ; Wed, 17 Oct 2012 13:15:03 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=subject:mime-version:content-type:from:x-priority:in-reply-to:date
	:cc:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=YjTod45U7TsHb6NNUDmnUMBHr0gBicDDhNpOXrXN6h4=;
	b=PP3JBaALw7ouSnFOEI6z4ZDHAExGcigk9zuf6bJvGdoQQTj3cclsTzjcVvQngVCtXz
	+Gzozg1Hj4MUfRwSElxq1SegE9RaeHnordy68U9NEqc+w3SmwtqqAvRowVddxQm/n+SF
	os/+DbctAVABjQm6BtAnRncYrcDc48ogFNQ3nO8why+QbpwWHUchEwCf0U14APOkYW0h
	gdGBwlffz4M37FNRmcRu8GjaZ2Wri9KOhy/5FezsRWIX6nxQLVnngy299SGigG1dCnmU
	UD1FyL6RLlihfH28a15usIRCkn0y7ZyYWrJ0mzOtUC5BO5rS9O9pYjjfVRtjzmQArTWU
	APKA==
Received: by 10.50.183.167 with SMTP id en7mr2747028igc.49.1350504903738;
	Wed, 17 Oct 2012 13:15:03 -0700 (PDT)
Received: from [192.168.4.87] ([206.223.182.18])
	by mx.google.com with ESMTPS id eo7sm10104568igc.12.2012.10.17.13.15.01
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 17 Oct 2012 13:15:02 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Andres Lagar-Cavilla 
X-Priority: 3
In-Reply-To: <9a09f64d-693a-4c4a-9d8a-14428969f18b@default>
Date: Wed, 17 Oct 2012 16:14:57 -0400
Message-Id: 
References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default>
	<20581.55931.246130.308384@mariner.uk.xensource.com>
	<8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default>
	<20121002091017.GA95926@ocelot.phlegethon.org>
	<66cc0085-1216-40f7-8059-eaf615202c12@default>
	<20121002201624.GA98445@ocelot.phlegethon.org>
	
	<20121004100645.GC38243@ocelot.phlegethon.org>
	<1349345864.650.247.camel@zakaz.uk.xensource.com>
	<239799F4-AF29-494F-86D2-ADF45ACA8792@gridcentric.ca>
	<3e5cf0ba-4241-4f00-bef6-aaff2cc23419@default>
	<506EC710.3020606@eu.citrix.com>
	<58b5a25d-ccdd-4d0c-a0d9-9c249825f7f1@default>
	
	
	
	<34D83A40-E798-4CF7-9084-83347C7207BB@gridcentric.ca>
	<9a09f64d-693a-4c4a-9d8a-14428969f18b@default>
To: Dan Magenheimer 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQkwJflNH8o2UI85RMIzC4zXLTKIxUbz5drv8ujuWkL6bToUPXiV3cho1eMu6UHr8qEWFa0n
Cc: Olaf Hering , "Keir \(Xen.org\)" ,
	Ian Campbell ,
	Konrad Wilk ,
	George Dunlap ,
	Andres Lagar-Cavilla ,
	"Tim \(Xen.org\)" , xen-devel@lists.xen.org,
	George Shuklin ,
	Dario Faggioli , Kurt Hackel ,
	Ian Jackson 
Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and
	xl)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Oct 17, 2012, at 3:46 PM, Dan Magenheimer  w=
rote:

>> From: Andres Lagar-Cavilla [mailto:andreslc@gridcentric.ca]
>> Subject: Re: [Xen-devel] domain creation vs querying free memory (xend a=
nd xl)
> =

> Hi Andres --
> =

> Re reply just sent to George...
> =

> I think you must be on a third planet, revolving somewhere between
> George's and mine.  I say that because I agree completely with some
> of your statements and disagree with the conclusions you draw from
> them! :-)
> =

>> Domains can be cajoled into obedience via the max_pages tweak -- which I=
 profoundly dislike. If
>> anything we should change the hypervisor to have a "current_allowance" o=
r similar field with a more
>> obvious meaning. The abuse of max_pages makes me cringe. Not to say I di=
sagree with its usefulness.
> =

> Me cringes too.  Though I can see from George's view that it makes
> perfect sense.  Since the toolstack always controls exactly how
> much memory is assigned to a domain and since it can cache the
> "original max", current allowance and the hypervisors view of
> max_pages must always be the same.

No. There is room for slack. max_pages (or current_allowance) simply sets a=
n upper bound, which if met will trigger the need for memory management int=
ervention.

> =

> Only if the hypervisor or the domain or the domain's administrator
> can tweak current memory usage without the knowledge of the
> toolstack (which is closer to my planet) does an issue arise.
> And, to me, that's the foundation of this whole thread.
> =

>> Once you guarantee no "ex machina" entities fudging the view of the memo=
ry the toolstack has, then all
>> known methods can be bounded in terms of their capacity to allocate memo=
ry unsupervised.
>> Note that this implies as well, I don't see the need for a pool of "unsh=
are" pages. It's all in the
>> heap. The toolstack ensures there is something set apart.
> =

> By "ex machina" do you mean "without the toolstack's knowledge"?
> =

> Then how does page-unsharing work?  Does every page-unshare done by
> the hypervisor require serial notification/permission of the toolstack?

No of course not. But if you want to keep a domain at bay you keep its max_=
pages where you want it to stop growing. And at that point the domain will =
fall asleep (not 100% there hypervisor-wise yet but Real Soon Now (=99)), a=
nd a synchronous notification will be sent to a listener.

At that point it's again a memory management decision. Should I increase th=
e domain's reservation, page something out, etc? There is a range of possib=
ilities that are not germane to the core issue of enforcing memory limits.

> Or is this "batched", in which case a pool is necessary, isn't it?
> (Not sure what you mean by "no need for a pool" and then "toolstack
> ensures there is something set apart"... what's the difference?)

I am under the impression there is a proposal floating for a hypervisor-mai=
ntained pool of pages to immediately relief un-sharing. Much like there is =
now for PoD (the pod cache). This is what I think is not necessary.

> =

> My point is, whether there is no pool or a pool that sometimes
> runs dry, are you really going to put the toolstack in the hypervisor's
> path for allocating a page so that the hypervisor can allocate
> a new page for CoW to fulfill an unshare?

Absolutely not.

> =

>> Something that I struggle with here is the notion that we need to extend=
 the hypervisor for any aspect
>> of the discussion we've had so far. I just don't see that. The toolstack=
 has (or should definitely
>> have) a non-racy view of the memory of the host. Reservations are theref=
ore notions the toolstack
>> manages.
> =

> In a perfect world where the toolstack has an oracle for the
> precise time-varying memory requirements for all guests, I
> would agree.

With the mechanism outlined, the toolstack needs to make coarse-grained inf=
requent decisions. There is a possibility for pathological misbehavior -- I=
 think there is always that possibility. Correctness is preserved, at worst=
, performance will be hurt.

It's really important to keep things separate in this discussion. The tools=
tack+hypervisor are enabling (1) control over how memory is allocated to wh=
at (2) control over a domain's ability to grow its footprint unsupervised (=
3) control over a domain's footprint with PV mechanisms from within, or ext=
ernally.

Performance is not up to the toolstack but to the memory manager magic the =
toolstack enables with (3).

> =

> In that world, there's no need for a CPU scheduler either...
> the toolstack can decide exactly when to assign each VCPU for
> each VM onto each PCPU, and when to stop and reassign.
> And then every PCPU would be maximally utilized, right?
> =

> My point: Why would you resource-manage CPUs differently from
> memory?  The demand of real-world workloads varies dramatically
> for both... don't you want both to be managed dynamically,
> whenever possible?
> =

> If yes (dynamic is good), in order for the toolstack's view of
> memory to be non-racy, doesn't every hypervisor page allocation
> need to be serialized with the toolstack granting notification/permission?

Once you bucketize RAM and know you will get synchronous kicks as buckets f=
ill up, then you have a non-racy view. If you choose buckets of width one=
=85..

> =

>> I further think the pod cache could be converted to this model. Why have=
 specific per-domain lists of
>> cached pages in the hypervisor? Get them back from the heap! Obviously p=
laces a decoupled requirement
>> of certain toolstack features. But allows to throw away a lot of complex=
 code.
> =

> IIUC in George's (Xapi) model (or using Tim's phrase, "balloon-to-fit")
> the heap is "always" empty because the toolstack has assigned all memory.

I don't think that's what they mean. Nor is it what I mean. The toolstack m=
ay chunk memory up into abstract buckets. It can certainly assert that its =
bucketized view matches the hypervisor view. Pages flow from the heap to ea=
ch domain -- but the bucket "domain X" will not overflow unsupervised.

> So I'm still confused... where does "page unshare" get memory from
> and how does it notify and/or get permission from the toolstack?

Re sharing, as it should be clear by now, the answer is "it doesn't matter"=
. If unsharing cannot be satisfied form the heap, then memory management in=
 dom0 is invoked. Heavy-weight, but it means you've hit an admin-imposed li=
mit.

Please note that this notion of limits and enforcement is sparingly applied=
 today, to the best of my knowledge. But imho it'd be great to meaningfully=
 work towards it.

Andres
> =

>> My two cents for the new iteration
> =

> I'll see your two cents, and raise you a penny! ;-)
> =

> Dan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 20:15:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 20:15:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOa1G-0006zj-KS; Wed, 17 Oct 2012 20:15:10 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOa1E-0006ze-GD
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 20:15:08 +0000
Received: from [193.109.254.147:38654] by server-15.bemta-14.messagelabs.com
	id 94/27-16351-BC11F705; Wed, 17 Oct 2012 20:15:07 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-13.tower-27.messagelabs.com!1350504904!10347969!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23750 invoked from network); 17 Oct 2012 20:15:05 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 20:15:05 -0000
Received: by mail-ie0-f173.google.com with SMTP id 17so15428595iea.32
	for ; Wed, 17 Oct 2012 13:15:03 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=subject:mime-version:content-type:from:x-priority:in-reply-to:date
	:cc:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=YjTod45U7TsHb6NNUDmnUMBHr0gBicDDhNpOXrXN6h4=;
	b=PP3JBaALw7ouSnFOEI6z4ZDHAExGcigk9zuf6bJvGdoQQTj3cclsTzjcVvQngVCtXz
	+Gzozg1Hj4MUfRwSElxq1SegE9RaeHnordy68U9NEqc+w3SmwtqqAvRowVddxQm/n+SF
	os/+DbctAVABjQm6BtAnRncYrcDc48ogFNQ3nO8why+QbpwWHUchEwCf0U14APOkYW0h
	gdGBwlffz4M37FNRmcRu8GjaZ2Wri9KOhy/5FezsRWIX6nxQLVnngy299SGigG1dCnmU
	UD1FyL6RLlihfH28a15usIRCkn0y7ZyYWrJ0mzOtUC5BO5rS9O9pYjjfVRtjzmQArTWU
	APKA==
Received: by 10.50.183.167 with SMTP id en7mr2747028igc.49.1350504903738;
	Wed, 17 Oct 2012 13:15:03 -0700 (PDT)
Received: from [192.168.4.87] ([206.223.182.18])
	by mx.google.com with ESMTPS id eo7sm10104568igc.12.2012.10.17.13.15.01
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 17 Oct 2012 13:15:02 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Andres Lagar-Cavilla 
X-Priority: 3
In-Reply-To: <9a09f64d-693a-4c4a-9d8a-14428969f18b@default>
Date: Wed, 17 Oct 2012 16:14:57 -0400
Message-Id: 
References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default>
	<20581.55931.246130.308384@mariner.uk.xensource.com>
	<8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default>
	<20121002091017.GA95926@ocelot.phlegethon.org>
	<66cc0085-1216-40f7-8059-eaf615202c12@default>
	<20121002201624.GA98445@ocelot.phlegethon.org>
	
	<20121004100645.GC38243@ocelot.phlegethon.org>
	<1349345864.650.247.camel@zakaz.uk.xensource.com>
	<239799F4-AF29-494F-86D2-ADF45ACA8792@gridcentric.ca>
	<3e5cf0ba-4241-4f00-bef6-aaff2cc23419@default>
	<506EC710.3020606@eu.citrix.com>
	<58b5a25d-ccdd-4d0c-a0d9-9c249825f7f1@default>
	
	
	
	<34D83A40-E798-4CF7-9084-83347C7207BB@gridcentric.ca>
	<9a09f64d-693a-4c4a-9d8a-14428969f18b@default>
To: Dan Magenheimer 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQkwJflNH8o2UI85RMIzC4zXLTKIxUbz5drv8ujuWkL6bToUPXiV3cho1eMu6UHr8qEWFa0n
Cc: Olaf Hering , "Keir \(Xen.org\)" ,
	Ian Campbell ,
	Konrad Wilk ,
	George Dunlap ,
	Andres Lagar-Cavilla ,
	"Tim \(Xen.org\)" , xen-devel@lists.xen.org,
	George Shuklin ,
	Dario Faggioli , Kurt Hackel ,
	Ian Jackson 
Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and
	xl)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Oct 17, 2012, at 3:46 PM, Dan Magenheimer  w=
rote:

>> From: Andres Lagar-Cavilla [mailto:andreslc@gridcentric.ca]
>> Subject: Re: [Xen-devel] domain creation vs querying free memory (xend a=
nd xl)
> =

> Hi Andres --
> =

> Re reply just sent to George...
> =

> I think you must be on a third planet, revolving somewhere between
> George's and mine.  I say that because I agree completely with some
> of your statements and disagree with the conclusions you draw from
> them! :-)
> =

>> Domains can be cajoled into obedience via the max_pages tweak -- which I=
 profoundly dislike. If
>> anything we should change the hypervisor to have a "current_allowance" o=
r similar field with a more
>> obvious meaning. The abuse of max_pages makes me cringe. Not to say I di=
sagree with its usefulness.
> =

> Me cringes too.  Though I can see from George's view that it makes
> perfect sense.  Since the toolstack always controls exactly how
> much memory is assigned to a domain and since it can cache the
> "original max", current allowance and the hypervisors view of
> max_pages must always be the same.

No. There is room for slack. max_pages (or current_allowance) simply sets a=
n upper bound, which if met will trigger the need for memory management int=
ervention.

> =

> Only if the hypervisor or the domain or the domain's administrator
> can tweak current memory usage without the knowledge of the
> toolstack (which is closer to my planet) does an issue arise.
> And, to me, that's the foundation of this whole thread.
> =

>> Once you guarantee no "ex machina" entities fudging the view of the memo=
ry the toolstack has, then all
>> known methods can be bounded in terms of their capacity to allocate memo=
ry unsupervised.
>> Note that this implies as well, I don't see the need for a pool of "unsh=
are" pages. It's all in the
>> heap. The toolstack ensures there is something set apart.
> =

> By "ex machina" do you mean "without the toolstack's knowledge"?
> =

> Then how does page-unsharing work?  Does every page-unshare done by
> the hypervisor require serial notification/permission of the toolstack?

No of course not. But if you want to keep a domain at bay you keep its max_=
pages where you want it to stop growing. And at that point the domain will =
fall asleep (not 100% there hypervisor-wise yet but Real Soon Now (=99)), a=
nd a synchronous notification will be sent to a listener.

At that point it's again a memory management decision. Should I increase th=
e domain's reservation, page something out, etc? There is a range of possib=
ilities that are not germane to the core issue of enforcing memory limits.

> Or is this "batched", in which case a pool is necessary, isn't it?
> (Not sure what you mean by "no need for a pool" and then "toolstack
> ensures there is something set apart"... what's the difference?)

I am under the impression there is a proposal floating for a hypervisor-mai=
ntained pool of pages to immediately relief un-sharing. Much like there is =
now for PoD (the pod cache). This is what I think is not necessary.

> =

> My point is, whether there is no pool or a pool that sometimes
> runs dry, are you really going to put the toolstack in the hypervisor's
> path for allocating a page so that the hypervisor can allocate
> a new page for CoW to fulfill an unshare?

Absolutely not.

> =

>> Something that I struggle with here is the notion that we need to extend=
 the hypervisor for any aspect
>> of the discussion we've had so far. I just don't see that. The toolstack=
 has (or should definitely
>> have) a non-racy view of the memory of the host. Reservations are theref=
ore notions the toolstack
>> manages.
> =

> In a perfect world where the toolstack has an oracle for the
> precise time-varying memory requirements for all guests, I
> would agree.

With the mechanism outlined, the toolstack needs to make coarse-grained inf=
requent decisions. There is a possibility for pathological misbehavior -- I=
 think there is always that possibility. Correctness is preserved, at worst=
, performance will be hurt.

It's really important to keep things separate in this discussion. The tools=
tack+hypervisor are enabling (1) control over how memory is allocated to wh=
at (2) control over a domain's ability to grow its footprint unsupervised (=
3) control over a domain's footprint with PV mechanisms from within, or ext=
ernally.

Performance is not up to the toolstack but to the memory manager magic the =
toolstack enables with (3).

> =

> In that world, there's no need for a CPU scheduler either...
> the toolstack can decide exactly when to assign each VCPU for
> each VM onto each PCPU, and when to stop and reassign.
> And then every PCPU would be maximally utilized, right?
> =

> My point: Why would you resource-manage CPUs differently from
> memory?  The demand of real-world workloads varies dramatically
> for both... don't you want both to be managed dynamically,
> whenever possible?
> =

> If yes (dynamic is good), in order for the toolstack's view of
> memory to be non-racy, doesn't every hypervisor page allocation
> need to be serialized with the toolstack granting notification/permission?

Once you bucketize RAM and know you will get synchronous kicks as buckets f=
ill up, then you have a non-racy view. If you choose buckets of width one=
=85..

> =

>> I further think the pod cache could be converted to this model. Why have=
 specific per-domain lists of
>> cached pages in the hypervisor? Get them back from the heap! Obviously p=
laces a decoupled requirement
>> of certain toolstack features. But allows to throw away a lot of complex=
 code.
> =

> IIUC in George's (Xapi) model (or using Tim's phrase, "balloon-to-fit")
> the heap is "always" empty because the toolstack has assigned all memory.

I don't think that's what they mean. Nor is it what I mean. The toolstack m=
ay chunk memory up into abstract buckets. It can certainly assert that its =
bucketized view matches the hypervisor view. Pages flow from the heap to ea=
ch domain -- but the bucket "domain X" will not overflow unsupervised.

> So I'm still confused... where does "page unshare" get memory from
> and how does it notify and/or get permission from the toolstack?

Re sharing, as it should be clear by now, the answer is "it doesn't matter"=
. If unsharing cannot be satisfied form the heap, then memory management in=
 dom0 is invoked. Heavy-weight, but it means you've hit an admin-imposed li=
mit.

Please note that this notion of limits and enforcement is sparingly applied=
 today, to the best of my knowledge. But imho it'd be great to meaningfully=
 work towards it.

Andres
> =

>> My two cents for the new iteration
> =

> I'll see your two cents, and raise you a penny! ;-)
> =

> Dan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 21:10:15 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 21:10:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOas7-0007Lx-6x; Wed, 17 Oct 2012 21:09:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOas5-0007Lp-Mp
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 21:09:45 +0000
Received: from [85.158.139.83:63882] by server-13.bemta-5.messagelabs.com id
	45/61-30674-89E1F705; Wed, 17 Oct 2012 21:09:44 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1350508182!33139109!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODA5NzQy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20064 invoked from network); 17 Oct 2012 21:09:44 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Oct 2012 21:09:44 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9HL9VDw022769
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Oct 2012 21:09:32 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9HL9UsO002083
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Oct 2012 21:09:31 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9HL9T4Z010549; Wed, 17 Oct 2012 16:09:29 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 14:09:29 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 44B0D4035B; Wed, 17 Oct 2012 16:57:28 -0400 (EDT)
Date: Wed, 17 Oct 2012 16:57:28 -0400
From: Konrad Rzeszutek Wilk 
To: Stephan Seitz 
Message-ID: <20121017205728.GA24498@phenom.dumpdata.com>
References: <20121016T192158.GA.6e659.stse@fsing.rootsland.net>
	
	<20121017T220352.GA.c4652.stse@fsing.rootsland.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20121017T220352.GA.c4652.stse@fsing.rootsland.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel 
Subject: Re: [Xen-devel] CPU microcode update under xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 17, 2012 at 10:06:59PM +0200, Stephan Seitz wrote:
> On Tue, Oct 16, 2012 at 01:54:59PM -0400, Ben Guthro wrote:
> >This is not yet merged.
> >
> >You'll need to look at the following branch from Konrad:
> >http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=shortlog;h=refs/heads/stable/misc
> 
> Thanks for your answer.
> 
> >primarily, the following changesets:
> >23757fb5d6781bf945d21d1f5373aa71122cbea9
> >f6c958ff0d00ffbf1cdc8fcf2f2a82f06fbbb5f4
> 
> Those patches are about one year old. Any reasons why they are not
> merged yet?

Sure. If you Google for the titles of those patches you will see
Borislav being unhappy about them.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 21:10:15 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 21:10:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOas7-0007Lx-6x; Wed, 17 Oct 2012 21:09:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOas5-0007Lp-Mp
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 21:09:45 +0000
Received: from [85.158.139.83:63882] by server-13.bemta-5.messagelabs.com id
	45/61-30674-89E1F705; Wed, 17 Oct 2012 21:09:44 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1350508182!33139109!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODA5NzQy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20064 invoked from network); 17 Oct 2012 21:09:44 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Oct 2012 21:09:44 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9HL9VDw022769
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Oct 2012 21:09:32 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9HL9UsO002083
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Oct 2012 21:09:31 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9HL9T4Z010549; Wed, 17 Oct 2012 16:09:29 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 14:09:29 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 44B0D4035B; Wed, 17 Oct 2012 16:57:28 -0400 (EDT)
Date: Wed, 17 Oct 2012 16:57:28 -0400
From: Konrad Rzeszutek Wilk 
To: Stephan Seitz 
Message-ID: <20121017205728.GA24498@phenom.dumpdata.com>
References: <20121016T192158.GA.6e659.stse@fsing.rootsland.net>
	
	<20121017T220352.GA.c4652.stse@fsing.rootsland.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20121017T220352.GA.c4652.stse@fsing.rootsland.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel 
Subject: Re: [Xen-devel] CPU microcode update under xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 17, 2012 at 10:06:59PM +0200, Stephan Seitz wrote:
> On Tue, Oct 16, 2012 at 01:54:59PM -0400, Ben Guthro wrote:
> >This is not yet merged.
> >
> >You'll need to look at the following branch from Konrad:
> >http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=shortlog;h=refs/heads/stable/misc
> 
> Thanks for your answer.
> 
> >primarily, the following changesets:
> >23757fb5d6781bf945d21d1f5373aa71122cbea9
> >f6c958ff0d00ffbf1cdc8fcf2f2a82f06fbbb5f4
> 
> Those patches are about one year old. Any reasons why they are not
> merged yet?

Sure. If you Google for the titles of those patches you will see
Borislav being unhappy about them.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 21:16:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 21:16:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOayH-0007Un-34; Wed, 17 Oct 2012 21:16:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOayE-0007Ug-UU
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 21:16:07 +0000
Received: from [85.158.137.99:33026] by server-2.bemta-3.messagelabs.com id
	91/3A-00604-6102F705; Wed, 17 Oct 2012 21:16:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1350508565!17262130!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29772 invoked from network); 17 Oct 2012 21:16:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 21:16:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,602,1344211200"; d="scan'208";a="15240227"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 21:16:04 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 17 Oct 2012 22:16:05 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TOayC-0001QI-G6;
	Wed, 17 Oct 2012 21:16:04 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TOayC-0001FT-Fc;
	Wed, 17 Oct 2012 22:16:04 +0100
To: 
Message-ID: 
From: xen.org 
Date: Wed, 17 Oct 2012 22:16:04 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14007: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14007 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14007/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 13967
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-pv            5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 13967
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 13967
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 13967
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 13967
 test-amd64-amd64-xl           5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                fail REGR. vs. 13967
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 13967
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 13967
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot          fail REGR. vs. 13967

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13967
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13967

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  5c402b905e00
baseline version:
 xen                  c1c549c4fe9e

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf 
  Huang Ying 
  Ian Campbell 
  Jan Beulich 
  Keir Fraser 
  Stefano Stabellini 
  Tim Deegan 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26073:5c402b905e00
tag:         tip
user:        Ian Campbell 
date:        Wed Oct 17 16:43:55 2012 +0100
    
    arm: parameter guest handles are 32 bit on 32 bit hypervisor
    
    Handles within structs remain 64 bit such that they are consistently
    sized on both 32 and 64 bit.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Stefano Stabellini 
    Committed-by: Ian Campbell 
    
    
changeset:   26072:5529b91bd2e4
user:        Ian Campbell 
date:        Wed Oct 17 16:43:54 2012 +0100
    
    xen: remove XEN_GUEST_HANDLE(ulong)
    
    Having both this handle (always unsigned long) and
    XEN_GUEST_HANDLE(xen_ulong_t) (unsigned long on x86 and explicit size
    of ARM) is confusing and error prone.
    
    Replace the two remaining uses of the ulong handle, in grant set and
    x86 set_gdt hypercalls, with xen_ulong_t.
    
    This correctly sizes the grant frame entry as 64 bit on ARM but
    leaves it as unsigned long on x86 (therefore no intended change on
    x86). Likewise in set_gdt there is no actual change.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Keir Fraser 
    Acked-by: Stefano Stabellini 
    Committed-by: Ian Campbell 
    
    
changeset:   26071:2a1083b1d0c2
user:        Stefano Stabellini 
date:        Wed Oct 17 16:43:53 2012 +0100
    
    xen: more XEN_GUEST_HANDLE_PARAM substitutions
    
    More substitutions in this patch, not as obvious as the ones in the
    previous patch.
    
    Signed-off-by: Stefano Stabellini 
    Signed-off-by: Ian Campbell 
    Acked-by: Keir Fraser 
    Committed-by: Ian Campbell 
    
    
changeset:   26070:9eafdcd5ff0b
user:        Stefano Stabellini 
date:        Wed Oct 17 16:43:53 2012 +0100
    
    xen: replace XEN_GUEST_HANDLE with XEN_GUEST_HANDLE_PARAM when appropriate
    
    Note: these changes don't make any difference on x86.
    
    Replace XEN_GUEST_HANDLE with XEN_GUEST_HANDLE_PARAM when it is used as
    an hypercall argument.
    
    Signed-off-by: Stefano Stabellini 
    Signed-off-by: Ian Campbell 
    Acked-by: Keir Fraser 
    Committed-by: Ian Campbell 
    
    
changeset:   26069:1eb4b2f7465f
user:        Stefano Stabellini 
date:        Wed Oct 17 16:43:51 2012 +0100
    
    xen: introduce XEN_GUEST_HANDLE_PARAM
    
    XEN_GUEST_HANDLE_PARAM is going to be used to distinguish guest pointers
    stored in memory from guest pointers as hypercall parameters.
    
    guest_handle_* macros default to XEN_GUEST_HANDLE_PARAM as return type.
    Two new guest_handle_to_param and guest_handle_from_param macros are
    introduced to do conversions.
    
    Signed-off-by: Stefano Stabellini 
    Signed-off-by: Ian Campbell 
    Acked-by: Keir Fraser 
    Committed-by: Ian Campbell 
    
    
changeset:   26068:ed6c13501195
user:        Stefano Stabellini 
date:        Wed Oct 17 16:43:50 2012 +0100
    
    xen: change the limit of nr_extents to UINT_MAX >> MEMOP_EXTENT_SHIFT
    
    Currently do_memory_op has a different maximum limit for nr_extents on
    32 bit and 64 bit.
    Change the limit to UINT_MAX >> MEMOP_EXTENT_SHIFT, so that it is the
    same in both cases.
    
    Signed-off-by: Stefano Stabellini 
    Signed-off-by: Ian Campbell 
    Acked-by: Keir Fraser 
    Committed-by: Ian Campbell 
    
    
changeset:   26067:a324eea3bbc8
user:        Stefano Stabellini 
date:        Wed Oct 17 16:43:49 2012 +0100
    
    xen: xen_ulong_t substitution
    
    There is still an unwanted unsigned long in the xen public interface:
    replace it with xen_ulong_t.
    
    Also typedef xen_ulong_t to uint64_t on ARM.
    
    Signed-off-by: Stefano Stabellini 
    Signed-off-by: Ian Campbell 
    Acked-by: Keir Fraser 
    Committed-by: Ian Campbell 
    
    
changeset:   26066:980863b9fa4b
user:        Ian Campbell 
date:        Wed Oct 17 16:43:48 2012 +0100
    
    arm: tools: add arm to foreign structs checking
    
    Signed-off-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26065:b146705d70b3
user:        Stefano Stabellini 
date:        Wed Oct 17 16:43:47 2012 +0100
    
    xen/arm: grant table
    
    Implement XENMAPSPACE_grant_table and grant_table_op.
    
    Signed-off-by: Stefano Stabellini 
    Acked-by: Tim Deegan 
    [ ijc -- fixed reject in traps.c, grant table op is a 3 argument
             hypercall, rebased over "xen: arm: implement
             XENMEM_add_to_physmap_range"
    ]
    Signed-off-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26064:bbe986018949
user:        Ian Campbell 
date:        Wed Oct 17 16:43:46 2012 +0100
    
    xen: arm: implement XENMEM_add_to_physmap_range
    
    This allows for foreign mappings as well as batching, fitting all that
    into XENMEM_add_to_physmap wasn't possible.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Keir Fraser 
    Acked-by: Stefano Stabellini 
    Committed-by: Ian Campbell 
    
    
changeset:   26063:1f4be6ee4619
user:        Jan Beulich 
date:        Wed Oct 17 14:13:20 2012 +0200
    
    x86/HPET: obtain proper lock for changing IRQ affinity
    
    The IRQ descriptor lock should be held while adjusting the affinity of
    any IRQ; the HPET channel lock isn't sufficient to protect namely
    against races with moving the IRQ to a different CPU.
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    
    
changeset:   26062:ec8a091efcce
user:        Huang Ying 
date:        Wed Oct 17 14:12:06 2012 +0200
    
    ACPI/APEI: fix ERST MOVE_DATA instruction implementation
    
    The src_base and dst_base fields in apei_exec_context are physical
    address, so they should be ioremaped before being used in ERST
    MOVE_DATA instruction.
    
    Reported-by: Javier Martinez Canillas 
    Reported-by: Andrew Morton 
    Signed-off-by: Huang Ying 
    
    Replace use of ioremap() by __acpi_map_table()/set_fixmap(). Fix error
    handling.
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    Committed-by: Jan Beulich 
    
    
changeset:   26061:4b4c0c7a6031
user:        Jan Beulich 
date:        Wed Oct 17 11:23:10 2012 +0200
    
    x86/oprof: adjust off-by-one counter range checks
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    
    
changeset:   26060:4fc87c2f31a0
user:        Huang Ying 
date:        Tue Oct 16 17:26:36 2012 +0200
    
    ACPI: fix APEI related table size checking
    
    On Huang Ying's machine:
    
    erst_tab->header_length == sizeof(struct acpi_table_einj)
    
    but Yinghai reported that on his machine,
    
    erst_tab->header_length == sizeof(struct acpi_table_einj) -
    sizeof(struct acpi_table_header)
    
    To make erst table size checking code works on all systems, both
    testing are treated as PASS.
    
    Same situation applies to einj_tab->header_length, so corresponding
    table size checking is changed in similar way too.
    
    Originally-by: Yinghai Lu 
    Signed-off-by: Huang Ying 
    
    - use switch() for better readability
    - add comment explaining why a formally invalid size it also being
      accepted
    - check erst_tab->header.length before even looking at
      erst_tab->header_length
    - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    Committed-by: Jan Beulich 
    
    
changeset:   26059:c1c549c4fe9e
user:        Daniel De Graaf 
date:        Mon Oct 15 16:51:44 2012 +0100
    
    xen: Add versions of rcu_lock_*_domain without IS_PRIV
    
    These functions will be used to avoid duplication of IS_PRIV calls
    that will be introduced in XSM hooks. This also fixes a build error
    with XSM enabled introduced by 25925:d1c3375c3f11 which depends on
    this patch.
    
    Signed-off-by: Daniel De Graaf 
    Committed-by: Keir Fraser 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 21:16:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 21:16:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOayH-0007Un-34; Wed, 17 Oct 2012 21:16:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOayE-0007Ug-UU
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 21:16:07 +0000
Received: from [85.158.137.99:33026] by server-2.bemta-3.messagelabs.com id
	91/3A-00604-6102F705; Wed, 17 Oct 2012 21:16:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1350508565!17262130!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29772 invoked from network); 17 Oct 2012 21:16:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 21:16:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,602,1344211200"; d="scan'208";a="15240227"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Oct 2012 21:16:04 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 17 Oct 2012 22:16:05 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TOayC-0001QI-G6;
	Wed, 17 Oct 2012 21:16:04 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TOayC-0001FT-Fc;
	Wed, 17 Oct 2012 22:16:04 +0100
To: 
Message-ID: 
From: xen.org 
Date: Wed, 17 Oct 2012 22:16:04 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14007: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14007 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14007/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 13967
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-pv            5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 13967
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 13967
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 13967
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 13967
 test-amd64-amd64-xl           5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                fail REGR. vs. 13967
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 13967
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 13967
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot          fail REGR. vs. 13967

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13967
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13967

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  5c402b905e00
baseline version:
 xen                  c1c549c4fe9e

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf 
  Huang Ying 
  Ian Campbell 
  Jan Beulich 
  Keir Fraser 
  Stefano Stabellini 
  Tim Deegan 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26073:5c402b905e00
tag:         tip
user:        Ian Campbell 
date:        Wed Oct 17 16:43:55 2012 +0100
    
    arm: parameter guest handles are 32 bit on 32 bit hypervisor
    
    Handles within structs remain 64 bit such that they are consistently
    sized on both 32 and 64 bit.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Stefano Stabellini 
    Committed-by: Ian Campbell 
    
    
changeset:   26072:5529b91bd2e4
user:        Ian Campbell 
date:        Wed Oct 17 16:43:54 2012 +0100
    
    xen: remove XEN_GUEST_HANDLE(ulong)
    
    Having both this handle (always unsigned long) and
    XEN_GUEST_HANDLE(xen_ulong_t) (unsigned long on x86 and explicit size
    of ARM) is confusing and error prone.
    
    Replace the two remaining uses of the ulong handle, in grant set and
    x86 set_gdt hypercalls, with xen_ulong_t.
    
    This correctly sizes the grant frame entry as 64 bit on ARM but
    leaves it as unsigned long on x86 (therefore no intended change on
    x86). Likewise in set_gdt there is no actual change.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Keir Fraser 
    Acked-by: Stefano Stabellini 
    Committed-by: Ian Campbell 
    
    
changeset:   26071:2a1083b1d0c2
user:        Stefano Stabellini 
date:        Wed Oct 17 16:43:53 2012 +0100
    
    xen: more XEN_GUEST_HANDLE_PARAM substitutions
    
    More substitutions in this patch, not as obvious as the ones in the
    previous patch.
    
    Signed-off-by: Stefano Stabellini 
    Signed-off-by: Ian Campbell 
    Acked-by: Keir Fraser 
    Committed-by: Ian Campbell 
    
    
changeset:   26070:9eafdcd5ff0b
user:        Stefano Stabellini 
date:        Wed Oct 17 16:43:53 2012 +0100
    
    xen: replace XEN_GUEST_HANDLE with XEN_GUEST_HANDLE_PARAM when appropriate
    
    Note: these changes don't make any difference on x86.
    
    Replace XEN_GUEST_HANDLE with XEN_GUEST_HANDLE_PARAM when it is used as
    an hypercall argument.
    
    Signed-off-by: Stefano Stabellini 
    Signed-off-by: Ian Campbell 
    Acked-by: Keir Fraser 
    Committed-by: Ian Campbell 
    
    
changeset:   26069:1eb4b2f7465f
user:        Stefano Stabellini 
date:        Wed Oct 17 16:43:51 2012 +0100
    
    xen: introduce XEN_GUEST_HANDLE_PARAM
    
    XEN_GUEST_HANDLE_PARAM is going to be used to distinguish guest pointers
    stored in memory from guest pointers as hypercall parameters.
    
    guest_handle_* macros default to XEN_GUEST_HANDLE_PARAM as return type.
    Two new guest_handle_to_param and guest_handle_from_param macros are
    introduced to do conversions.
    
    Signed-off-by: Stefano Stabellini 
    Signed-off-by: Ian Campbell 
    Acked-by: Keir Fraser 
    Committed-by: Ian Campbell 
    
    
changeset:   26068:ed6c13501195
user:        Stefano Stabellini 
date:        Wed Oct 17 16:43:50 2012 +0100
    
    xen: change the limit of nr_extents to UINT_MAX >> MEMOP_EXTENT_SHIFT
    
    Currently do_memory_op has a different maximum limit for nr_extents on
    32 bit and 64 bit.
    Change the limit to UINT_MAX >> MEMOP_EXTENT_SHIFT, so that it is the
    same in both cases.
    
    Signed-off-by: Stefano Stabellini 
    Signed-off-by: Ian Campbell 
    Acked-by: Keir Fraser 
    Committed-by: Ian Campbell 
    
    
changeset:   26067:a324eea3bbc8
user:        Stefano Stabellini 
date:        Wed Oct 17 16:43:49 2012 +0100
    
    xen: xen_ulong_t substitution
    
    There is still an unwanted unsigned long in the xen public interface:
    replace it with xen_ulong_t.
    
    Also typedef xen_ulong_t to uint64_t on ARM.
    
    Signed-off-by: Stefano Stabellini 
    Signed-off-by: Ian Campbell 
    Acked-by: Keir Fraser 
    Committed-by: Ian Campbell 
    
    
changeset:   26066:980863b9fa4b
user:        Ian Campbell 
date:        Wed Oct 17 16:43:48 2012 +0100
    
    arm: tools: add arm to foreign structs checking
    
    Signed-off-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26065:b146705d70b3
user:        Stefano Stabellini 
date:        Wed Oct 17 16:43:47 2012 +0100
    
    xen/arm: grant table
    
    Implement XENMAPSPACE_grant_table and grant_table_op.
    
    Signed-off-by: Stefano Stabellini 
    Acked-by: Tim Deegan 
    [ ijc -- fixed reject in traps.c, grant table op is a 3 argument
             hypercall, rebased over "xen: arm: implement
             XENMEM_add_to_physmap_range"
    ]
    Signed-off-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26064:bbe986018949
user:        Ian Campbell 
date:        Wed Oct 17 16:43:46 2012 +0100
    
    xen: arm: implement XENMEM_add_to_physmap_range
    
    This allows for foreign mappings as well as batching, fitting all that
    into XENMEM_add_to_physmap wasn't possible.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Keir Fraser 
    Acked-by: Stefano Stabellini 
    Committed-by: Ian Campbell 
    
    
changeset:   26063:1f4be6ee4619
user:        Jan Beulich 
date:        Wed Oct 17 14:13:20 2012 +0200
    
    x86/HPET: obtain proper lock for changing IRQ affinity
    
    The IRQ descriptor lock should be held while adjusting the affinity of
    any IRQ; the HPET channel lock isn't sufficient to protect namely
    against races with moving the IRQ to a different CPU.
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    
    
changeset:   26062:ec8a091efcce
user:        Huang Ying 
date:        Wed Oct 17 14:12:06 2012 +0200
    
    ACPI/APEI: fix ERST MOVE_DATA instruction implementation
    
    The src_base and dst_base fields in apei_exec_context are physical
    address, so they should be ioremaped before being used in ERST
    MOVE_DATA instruction.
    
    Reported-by: Javier Martinez Canillas 
    Reported-by: Andrew Morton 
    Signed-off-by: Huang Ying 
    
    Replace use of ioremap() by __acpi_map_table()/set_fixmap(). Fix error
    handling.
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    Committed-by: Jan Beulich 
    
    
changeset:   26061:4b4c0c7a6031
user:        Jan Beulich 
date:        Wed Oct 17 11:23:10 2012 +0200
    
    x86/oprof: adjust off-by-one counter range checks
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    
    
changeset:   26060:4fc87c2f31a0
user:        Huang Ying 
date:        Tue Oct 16 17:26:36 2012 +0200
    
    ACPI: fix APEI related table size checking
    
    On Huang Ying's machine:
    
    erst_tab->header_length == sizeof(struct acpi_table_einj)
    
    but Yinghai reported that on his machine,
    
    erst_tab->header_length == sizeof(struct acpi_table_einj) -
    sizeof(struct acpi_table_header)
    
    To make erst table size checking code works on all systems, both
    testing are treated as PASS.
    
    Same situation applies to einj_tab->header_length, so corresponding
    table size checking is changed in similar way too.
    
    Originally-by: Yinghai Lu 
    Signed-off-by: Huang Ying 
    
    - use switch() for better readability
    - add comment explaining why a formally invalid size it also being
      accepted
    - check erst_tab->header.length before even looking at
      erst_tab->header_length
    - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    Committed-by: Jan Beulich 
    
    
changeset:   26059:c1c549c4fe9e
user:        Daniel De Graaf 
date:        Mon Oct 15 16:51:44 2012 +0100
    
    xen: Add versions of rcu_lock_*_domain without IS_PRIV
    
    These functions will be used to avoid duplication of IS_PRIV calls
    that will be introduced in XSM hooks. This also fixes a build error
    with XSM enabled introduced by 25925:d1c3375c3f11 which depends on
    this patch.
    
    Signed-off-by: Daniel De Graaf 
    Committed-by: Keir Fraser 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 22:08:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 22:08:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TObmW-0007p9-Ja; Wed, 17 Oct 2012 22:08:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TObmV-0007p4-My
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 22:08:04 +0000
Received: from [85.158.137.99:48099] by server-3.bemta-3.messagelabs.com id
	A3/7E-09368-24C2F705; Wed, 17 Oct 2012 22:08:02 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1350511680!22022499!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODA5NzQy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18717 invoked from network); 17 Oct 2012 22:08:02 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-4.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Oct 2012 22:08:02 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9HM7gEB011824
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Oct 2012 22:07:43 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9HM7fHR023648
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Oct 2012 22:07:42 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9HM7eFq008290; Wed, 17 Oct 2012 17:07:40 -0500
MIME-Version: 1.0
Message-ID: 
Date: Wed, 17 Oct 2012 15:07:39 -0700 (PDT)
From: Dan Magenheimer 
To: Andres Lagar-Cavilla 
References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default>
	<20581.55931.246130.308384@mariner.uk.xensource.com>
	<8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default>
	<20121002091017.GA95926@ocelot.phlegethon.org>
	<66cc0085-1216-40f7-8059-eaf615202c12@default>
	<20121002201624.GA98445@ocelot.phlegethon.org>
	
	<20121004100645.GC38243@ocelot.phlegethon.org>
	<1349345864.650.247.camel@zakaz.uk.xensource.com>
	<239799F4-AF29-494F-86D2-ADF45ACA8792@gridcentric.ca>
	<3e5cf0ba-4241-4f00-bef6-aaff2cc23419@default>
	<506EC710.3020606@eu.citrix.com>
	<58b5a25d-ccdd-4d0c-a0d9-9c249825f7f1@default>
	
	
	
	<34D83A40-E798-4CF7-9084-83347C7207BB@gridcentric.ca>
	<9a09f64d-693a-4c4a-9d8a-14428969f18b@default>
	
In-Reply-To: 
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Olaf Hering , "Keir \(Xen.org\)" ,
	Ian Campbell ,
	Konrad Wilk ,
	George Dunlap ,
	George Shuklin ,
	"Tim \(Xen.org\)" , xen-devel@lists.xen.org,
	Dario Faggioli , Kurt Hackel ,
	Ian Jackson 
Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and
	xl)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Andres --

First, the primary target of page-sharing is HVM proprietary/legacy
guests, correct?  So, as I said, we are starting from different
planets.  I'm not arguing that a toolstack-memory-controller
won't be sufficient for your needs, especially in a single server
environment, only that the work required to properly ensure that:

> >> The toolstack has (or should definitely have) a non-racy view
> >> of the memory of the host

is unnecessary if you (and the toolstack) take a slightly broader
dynamic view of memory management.  IMHO that broader view
(which requires the "memory reservation" hypercall) both encompasses
tmem and IMHO greatly simplifies memory management in the presence
of page-unsharing.  I.e. it allows the toolstack to NOT have
a non-racy view of the memory of the host.

So, if you don't mind, I will take this opportunity to
ask some questions about page-sharing stuff, in the context
of the toolstack-memory-controller and/or memory reservation
hypercall.

> >> Domains can be cajoled into obedience via the max_pages tweak -- which I profoundly dislike. If
> >> anything we should change the hypervisor to have a "current_allowance" or similar field with a more
> >> obvious meaning. The abuse of max_pages makes me cringe. Not to say I disagree with its usefulness.
> >
> > Me cringes too.  Though I can see from George's view that it makes
> > perfect sense.  Since the toolstack always controls exactly how
> > much memory is assigned to a domain and since it can cache the
> > "original max", current allowance and the hypervisors view of
> > max_pages must always be the same.
> 
> No. There is room for slack. max_pages (or current_allowance) simply sets an upper bound, which if met
> will trigger the need for memory management intervention.

I think we agree if we change my "must always be the same" to
"must always be essentially the same, ignoring some fudge factor".

Which begs the questions: How does one determine how big the
fudge factor is, what happens if it is not big enough, and if
it is too big, doesn't that potentially add up to a lot of
wasted space?

> > By "ex machina" do you mean "without the toolstack's knowledge"?
> >
> > Then how does page-unsharing work?  Does every page-unshare done by
> > the hypervisor require serial notification/permission of the toolstack?
> 
> No of course not. But if you want to keep a domain at bay you keep its max_pages where you want it to
> stop growing. And at that point the domain will fall asleep (not 100% there hypervisor-wise yet but
> Real Soon Now (T)), and a synchronous notification will be sent to a listener.
> 
> At that point it's again a memory management decision. Should I increase the domain's reservation,
> page something out, etc? There is a range of possibilities that are not germane to the core issue of
> enforcing memory limits.

Maybe we need to dive deep into page-sharing accounting for
a moment here:

When a page is shared say, by 1000 different VMs, does it get
"billed" to all VMs?  If no (which makes the most sense to me),
how is the toolstack informed that there is now 999 free
pages available so that it can use them in, say, a new domain?
Does the hypervisor notification wait until there is sufficient
pages (say, a bucket's worth)?  If yes, what's the point of
sharing if the hypervisor now has some free memory but the
the freed memory is still "billed"; and are there data
structures in the hypervisor to track this so that unsharing
does proper accounting too?

Now suppose 10000 pages are shared by 1000 different VMs at
domain launch (scenario: an online class is being set up by
a cloud user) and then the VMs suddenly get very active
and require a lot of CoWing (say the online class just
got underway).  What's the profile of interaction between
the hypervisor and toolstack?

Maybe you've got this all figured out (whether implemented or
not) and are convinced it is scalable (or don't care because the
target product is a small single system), but I'd imagine the internal
hypervisor vs toolstack accounting/notifications will get very
very messy and have concerns about scalability and memory waste.

> > Or is this "batched", in which case a pool is necessary, isn't it?
> > (Not sure what you mean by "no need for a pool" and then "toolstack
> > ensures there is something set apart"... what's the difference?)
> 
> I am under the impression there is a proposal floating for a hypervisor-maintained pool of pages to
> immediately relief un-sharing. Much like there is now for PoD (the pod cache). This is what I think is
> not necessary.

I agree it is not necessary, but don't understand who manages
the "slop" (unallocated free pages) and how a pool is different
from a "bucket" (to use your term from further down in your reply).

> > My point is, whether there is no pool or a pool that sometimes
> > runs dry, are you really going to put the toolstack in the hypervisor's
> > path for allocating a page so that the hypervisor can allocate
> > a new page for CoW to fulfill an unshare?
> 
> Absolutely not.

Good to hear.  But this begs answers to the previous questions.
Mainly: How does it all work then so that the toolstack and
hypervisor are "in sync" about the number of available pages
such that the toolstack never wrongly determines that there
is enough free space to launch a domain and (by the time
it tries to use the free space) there really isn't?

If they can't remain in sync (at least within a single "bucket",
across the entire system, not one bucket per domain), then
isn't something like the proposed "memory reservation"
hypercall still required?

> >> Something that I struggle with here is the notion that we need to extend the hypervisor for any
> aspect
> >> of the discussion we've had so far. I just don't see that. The toolstack has (or should definitely
> >> have) a non-racy view of the memory of the host. Reservations are therefore notions the toolstack
> >> manages.
> >
> > In a perfect world where the toolstack has an oracle for the
> > precise time-varying memory requirements for all guests, I
> > would agree.
> 
> With the mechanism outlined, the toolstack needs to make coarse-grained infrequent decisions. There is
> a possibility for pathological misbehavior -- I think there is always that possibility. Correctness is
> preserved, at worst, performance will be hurt.

IMHO, performance will be hurt not only for the pathological cases.
Memory will also needlessly be wasted.  But, for Windows, I don't
have a better solution, and it will probably be no worse than Microsoft's
solution.

> It's really important to keep things separate in this discussion. The toolstack+hypervisor are
> enabling (1) control over how memory is allocated to what (2) control over a domain's ability to grow
> its footprint unsupervised (3) control over a domain's footprint with PV mechanisms from within, or
> externally.
> 
> Performance is not up to the toolstack but to the memory manager magic the toolstack enables with (3).

Good dichotomy (though not entirely perfect on my planet).

> > In that world, there's no need for a CPU scheduler either...
> > the toolstack can decide exactly when to assign each VCPU for
> > each VM onto each PCPU, and when to stop and reassign.
> > And then every PCPU would be maximally utilized, right?
> >
> > My point: Why would you resource-manage CPUs differently from
> > memory?  The demand of real-world workloads varies dramatically
> > for both... don't you want both to be managed dynamically,
> > whenever possible?
> >
> > If yes (dynamic is good), in order for the toolstack's view of
> > memory to be non-racy, doesn't every hypervisor page allocation
> > need to be serialized with the toolstack granting notification/permission?
> 
> Once you bucketize RAM and know you will get synchronous kicks as buckets fill up, then you have a
> non-racy view. If you choose buckets of width one...

 ... e.g. tmem, which is saving one page of data at high frequency

> >> I further think the pod cache could be converted to this model. Why have specific per-domain lists
> of
> >> cached pages in the hypervisor? Get them back from the heap! Obviously places a decoupled
> requirement
> >> of certain toolstack features. But allows to throw away a lot of complex code.
> >
> > IIUC in George's (Xapi) model (or using Tim's phrase, "balloon-to-fit")
> > the heap is "always" empty because the toolstack has assigned all memory.
> 
> I don't think that's what they mean. Nor is it what I mean. The toolstack may chunk memory up into
> abstract buckets. It can certainly assert that its bucketized view matches the hypervisor view. Pages
> flow from the heap to each domain -- but the bucket "domain X" will not overflow unsupervised.

Right, but it is the "underflow" I am concerned with.

I don't know if that is what they mean by "balloon-to-fit" (or exactly
what you mean), but I think we are all trying to optimize the use of
a fixed amount of RAM among some number of VMs.  To me, a corollary
of that is that the size of the heap is always as small "as possible".
And another corollary is that there aren't a bunch of empty pools
of free pages lying about waiting for rare events to happen.  And
one more corollary is that, to the extent possible, guests aren't
"wasting" memory.

> > So I'm still confused... where does "page unshare" get memory from
> > and how does it notify and/or get permission from the toolstack?
> 
> Re sharing, as it should be clear by now, the answer is "it doesn't matter". If unsharing cannot be
> satisfied form the heap, then memory management in dom0 is invoked. Heavy-weight, but it means you've
> hit an admin-imposed limit.

Well it *does* matter if that fallback (unsharing cannot be
satisfied from the heap) happens too frequently.
 
> Please note that this notion of limits and enforcement is sparingly applied today, to the best of my
> knowledge. But imho it'd be great to meaningfully work towards it.

Agreed.  There's lots of policy questions around all of our different
mechanism "planets", so I hope this discussion meaningfully helps!

Thanks for the great discussion!

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 22:08:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 22:08:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TObmW-0007p9-Ja; Wed, 17 Oct 2012 22:08:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TObmV-0007p4-My
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 22:08:04 +0000
Received: from [85.158.137.99:48099] by server-3.bemta-3.messagelabs.com id
	A3/7E-09368-24C2F705; Wed, 17 Oct 2012 22:08:02 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1350511680!22022499!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODA5NzQy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18717 invoked from network); 17 Oct 2012 22:08:02 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-4.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Oct 2012 22:08:02 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9HM7gEB011824
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Oct 2012 22:07:43 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9HM7fHR023648
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Oct 2012 22:07:42 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9HM7eFq008290; Wed, 17 Oct 2012 17:07:40 -0500
MIME-Version: 1.0
Message-ID: 
Date: Wed, 17 Oct 2012 15:07:39 -0700 (PDT)
From: Dan Magenheimer 
To: Andres Lagar-Cavilla 
References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default>
	<20581.55931.246130.308384@mariner.uk.xensource.com>
	<8ba2021c-1095-4fd1-98a5-f6eec8a3498b@default>
	<20121002091017.GA95926@ocelot.phlegethon.org>
	<66cc0085-1216-40f7-8059-eaf615202c12@default>
	<20121002201624.GA98445@ocelot.phlegethon.org>
	
	<20121004100645.GC38243@ocelot.phlegethon.org>
	<1349345864.650.247.camel@zakaz.uk.xensource.com>
	<239799F4-AF29-494F-86D2-ADF45ACA8792@gridcentric.ca>
	<3e5cf0ba-4241-4f00-bef6-aaff2cc23419@default>
	<506EC710.3020606@eu.citrix.com>
	<58b5a25d-ccdd-4d0c-a0d9-9c249825f7f1@default>
	
	
	
	<34D83A40-E798-4CF7-9084-83347C7207BB@gridcentric.ca>
	<9a09f64d-693a-4c4a-9d8a-14428969f18b@default>
	
In-Reply-To: 
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Olaf Hering , "Keir \(Xen.org\)" ,
	Ian Campbell ,
	Konrad Wilk ,
	George Dunlap ,
	George Shuklin ,
	"Tim \(Xen.org\)" , xen-devel@lists.xen.org,
	Dario Faggioli , Kurt Hackel ,
	Ian Jackson 
Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and
	xl)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Andres --

First, the primary target of page-sharing is HVM proprietary/legacy
guests, correct?  So, as I said, we are starting from different
planets.  I'm not arguing that a toolstack-memory-controller
won't be sufficient for your needs, especially in a single server
environment, only that the work required to properly ensure that:

> >> The toolstack has (or should definitely have) a non-racy view
> >> of the memory of the host

is unnecessary if you (and the toolstack) take a slightly broader
dynamic view of memory management.  IMHO that broader view
(which requires the "memory reservation" hypercall) both encompasses
tmem and IMHO greatly simplifies memory management in the presence
of page-unsharing.  I.e. it allows the toolstack to NOT have
a non-racy view of the memory of the host.

So, if you don't mind, I will take this opportunity to
ask some questions about page-sharing stuff, in the context
of the toolstack-memory-controller and/or memory reservation
hypercall.

> >> Domains can be cajoled into obedience via the max_pages tweak -- which I profoundly dislike. If
> >> anything we should change the hypervisor to have a "current_allowance" or similar field with a more
> >> obvious meaning. The abuse of max_pages makes me cringe. Not to say I disagree with its usefulness.
> >
> > Me cringes too.  Though I can see from George's view that it makes
> > perfect sense.  Since the toolstack always controls exactly how
> > much memory is assigned to a domain and since it can cache the
> > "original max", current allowance and the hypervisors view of
> > max_pages must always be the same.
> 
> No. There is room for slack. max_pages (or current_allowance) simply sets an upper bound, which if met
> will trigger the need for memory management intervention.

I think we agree if we change my "must always be the same" to
"must always be essentially the same, ignoring some fudge factor".

Which begs the questions: How does one determine how big the
fudge factor is, what happens if it is not big enough, and if
it is too big, doesn't that potentially add up to a lot of
wasted space?

> > By "ex machina" do you mean "without the toolstack's knowledge"?
> >
> > Then how does page-unsharing work?  Does every page-unshare done by
> > the hypervisor require serial notification/permission of the toolstack?
> 
> No of course not. But if you want to keep a domain at bay you keep its max_pages where you want it to
> stop growing. And at that point the domain will fall asleep (not 100% there hypervisor-wise yet but
> Real Soon Now (T)), and a synchronous notification will be sent to a listener.
> 
> At that point it's again a memory management decision. Should I increase the domain's reservation,
> page something out, etc? There is a range of possibilities that are not germane to the core issue of
> enforcing memory limits.

Maybe we need to dive deep into page-sharing accounting for
a moment here:

When a page is shared say, by 1000 different VMs, does it get
"billed" to all VMs?  If no (which makes the most sense to me),
how is the toolstack informed that there is now 999 free
pages available so that it can use them in, say, a new domain?
Does the hypervisor notification wait until there is sufficient
pages (say, a bucket's worth)?  If yes, what's the point of
sharing if the hypervisor now has some free memory but the
the freed memory is still "billed"; and are there data
structures in the hypervisor to track this so that unsharing
does proper accounting too?

Now suppose 10000 pages are shared by 1000 different VMs at
domain launch (scenario: an online class is being set up by
a cloud user) and then the VMs suddenly get very active
and require a lot of CoWing (say the online class just
got underway).  What's the profile of interaction between
the hypervisor and toolstack?

Maybe you've got this all figured out (whether implemented or
not) and are convinced it is scalable (or don't care because the
target product is a small single system), but I'd imagine the internal
hypervisor vs toolstack accounting/notifications will get very
very messy and have concerns about scalability and memory waste.

> > Or is this "batched", in which case a pool is necessary, isn't it?
> > (Not sure what you mean by "no need for a pool" and then "toolstack
> > ensures there is something set apart"... what's the difference?)
> 
> I am under the impression there is a proposal floating for a hypervisor-maintained pool of pages to
> immediately relief un-sharing. Much like there is now for PoD (the pod cache). This is what I think is
> not necessary.

I agree it is not necessary, but don't understand who manages
the "slop" (unallocated free pages) and how a pool is different
from a "bucket" (to use your term from further down in your reply).

> > My point is, whether there is no pool or a pool that sometimes
> > runs dry, are you really going to put the toolstack in the hypervisor's
> > path for allocating a page so that the hypervisor can allocate
> > a new page for CoW to fulfill an unshare?
> 
> Absolutely not.

Good to hear.  But this begs answers to the previous questions.
Mainly: How does it all work then so that the toolstack and
hypervisor are "in sync" about the number of available pages
such that the toolstack never wrongly determines that there
is enough free space to launch a domain and (by the time
it tries to use the free space) there really isn't?

If they can't remain in sync (at least within a single "bucket",
across the entire system, not one bucket per domain), then
isn't something like the proposed "memory reservation"
hypercall still required?

> >> Something that I struggle with here is the notion that we need to extend the hypervisor for any
> aspect
> >> of the discussion we've had so far. I just don't see that. The toolstack has (or should definitely
> >> have) a non-racy view of the memory of the host. Reservations are therefore notions the toolstack
> >> manages.
> >
> > In a perfect world where the toolstack has an oracle for the
> > precise time-varying memory requirements for all guests, I
> > would agree.
> 
> With the mechanism outlined, the toolstack needs to make coarse-grained infrequent decisions. There is
> a possibility for pathological misbehavior -- I think there is always that possibility. Correctness is
> preserved, at worst, performance will be hurt.

IMHO, performance will be hurt not only for the pathological cases.
Memory will also needlessly be wasted.  But, for Windows, I don't
have a better solution, and it will probably be no worse than Microsoft's
solution.

> It's really important to keep things separate in this discussion. The toolstack+hypervisor are
> enabling (1) control over how memory is allocated to what (2) control over a domain's ability to grow
> its footprint unsupervised (3) control over a domain's footprint with PV mechanisms from within, or
> externally.
> 
> Performance is not up to the toolstack but to the memory manager magic the toolstack enables with (3).

Good dichotomy (though not entirely perfect on my planet).

> > In that world, there's no need for a CPU scheduler either...
> > the toolstack can decide exactly when to assign each VCPU for
> > each VM onto each PCPU, and when to stop and reassign.
> > And then every PCPU would be maximally utilized, right?
> >
> > My point: Why would you resource-manage CPUs differently from
> > memory?  The demand of real-world workloads varies dramatically
> > for both... don't you want both to be managed dynamically,
> > whenever possible?
> >
> > If yes (dynamic is good), in order for the toolstack's view of
> > memory to be non-racy, doesn't every hypervisor page allocation
> > need to be serialized with the toolstack granting notification/permission?
> 
> Once you bucketize RAM and know you will get synchronous kicks as buckets fill up, then you have a
> non-racy view. If you choose buckets of width one...

 ... e.g. tmem, which is saving one page of data at high frequency

> >> I further think the pod cache could be converted to this model. Why have specific per-domain lists
> of
> >> cached pages in the hypervisor? Get them back from the heap! Obviously places a decoupled
> requirement
> >> of certain toolstack features. But allows to throw away a lot of complex code.
> >
> > IIUC in George's (Xapi) model (or using Tim's phrase, "balloon-to-fit")
> > the heap is "always" empty because the toolstack has assigned all memory.
> 
> I don't think that's what they mean. Nor is it what I mean. The toolstack may chunk memory up into
> abstract buckets. It can certainly assert that its bucketized view matches the hypervisor view. Pages
> flow from the heap to each domain -- but the bucket "domain X" will not overflow unsupervised.

Right, but it is the "underflow" I am concerned with.

I don't know if that is what they mean by "balloon-to-fit" (or exactly
what you mean), but I think we are all trying to optimize the use of
a fixed amount of RAM among some number of VMs.  To me, a corollary
of that is that the size of the heap is always as small "as possible".
And another corollary is that there aren't a bunch of empty pools
of free pages lying about waiting for rare events to happen.  And
one more corollary is that, to the extent possible, guests aren't
"wasting" memory.

> > So I'm still confused... where does "page unshare" get memory from
> > and how does it notify and/or get permission from the toolstack?
> 
> Re sharing, as it should be clear by now, the answer is "it doesn't matter". If unsharing cannot be
> satisfied form the heap, then memory management in dom0 is invoked. Heavy-weight, but it means you've
> hit an admin-imposed limit.

Well it *does* matter if that fallback (unsharing cannot be
satisfied from the heap) happens too frequently.
 
> Please note that this notion of limits and enforcement is sparingly applied today, to the best of my
> knowledge. But imho it'd be great to meaningfully work towards it.

Agreed.  There's lots of policy questions around all of our different
mechanism "planets", so I hope this discussion meaningfully helps!

Thanks for the great discussion!

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 23:44:53 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 23:44:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOdHi-0008Kz-Di; Wed, 17 Oct 2012 23:44:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOdHh-0008Ku-PH
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 23:44:21 +0000
Received: from [85.158.139.83:24643] by server-8.bemta-5.messagelabs.com id
	73/95-23193-5D24F705; Wed, 17 Oct 2012 23:44:21 +0000
X-Env-Sender: ronny.hegewald@online.de
X-Msg-Ref: server-15.tower-182.messagelabs.com!1350517460!33149596!1
X-Originating-IP: [212.227.17.8]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjE3LjggPT4gODQwMzc=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjE3LjggPT4gODQwMzc=\n,BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28333 invoked from network); 17 Oct 2012 23:44:20 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.17.8)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 23:44:20 -0000
Received: from server2-groupware.localnet (p4FEF8564.dip0.t-ipconnect.de
	[79.239.133.100])
	by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis)
	id 0LrXNx-1TTyQu1ERp-012vGQ; Thu, 18 Oct 2012 01:44:20 +0200
From: Ronny Hegewald 
Date: Thu, 18 Oct 2012 00:49:35 +0000
User-Agent: KMail/1.11.4 (Linux/3.0.3; KDE/4.2.4; i686; ; )
MIME-Version: 1.0
Content-Disposition: inline
To: xen-devel@lists.xen.org
Message-Id: <201210180049.35688.ronny.hegewald@online.de>
X-Provags-ID: V02:K0:huewqBrXiYK6OrfXwZ64MGLs6HETis/kUXBtCEFYHsM
	/fB4l8Ekk4PLC6zZLwq5hdVLM2P+Q3qXeHLWC6T1f1NLJ5IqMb
	wFpYuXcSo9hsztGx0MgaRXES8VtyO+/V9xgW6jxDC7JF36XE6M
	v8Vv4XXvqmkGDjm62i8p51QoWbjBc3lXTnf6pA3/l1Z28oW590
	V4TbSepu1v/py/zE9VHT41Lk7ietcKqHeiG3kgAsc/60Xi8LkJ
	6sWtCYpmrhaSb4lhsCCIdwIiZftvrHV0NAjOEGyzEMzeGkJ3z0
	er09YCWE29RRJv7dZCgLWuz6TXlls7BWd23eZ8XZpFask/tubg
	KU2Oav7Dpk5YLd0TtoZuXuNdQdTO4/NKQkyyqqZq0qa9GHznkP
	LAzlBntyQXQT0sgIgxEz7k0QzdJLL21hVY=
Subject: [Xen-devel] [PATCH 0/1] fix xen-crash at panic()-call during boot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Xen is crashing for me since version 4.1.3 during boot on a AMD machine.

This happens since patch "x86-64: detect processors subject to AMD erratum 
#121 and refuse to boot."

Instead of the actual panic-message from the patch the following stacktrace 
appears (i typed it down from screen, so it might contain typos)


find_iommu_for_device
amd_iommu_ioapic_update_ire
timer_interrupt
enable_8259_A_irq
do_IRQ
printk_start_of_line
acpi_os_printf
io_apic_write
__ioapic_write_entry
ioapic_write_entry
__clear_IO_APIC_pin
clear_IO_APIC
disable_IO_APIC
__stop_this_cpu
smp_send_stop
machine_restart
panic
tasklet_schedule_on_cpu
display_cacheinfo
init_amd
generic_identify
identify_cpu
_start_xen
_high_start

Panic on CPU 0:
Xen BUG at pci_amd_iommu.c:33

=====

The patch in the next mail fixes the problem for me and the intended panic-
message appears.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 23:44:53 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 23:44:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOdHi-0008Kz-Di; Wed, 17 Oct 2012 23:44:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOdHh-0008Ku-PH
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 23:44:21 +0000
Received: from [85.158.139.83:24643] by server-8.bemta-5.messagelabs.com id
	73/95-23193-5D24F705; Wed, 17 Oct 2012 23:44:21 +0000
X-Env-Sender: ronny.hegewald@online.de
X-Msg-Ref: server-15.tower-182.messagelabs.com!1350517460!33149596!1
X-Originating-IP: [212.227.17.8]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjE3LjggPT4gODQwMzc=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjE3LjggPT4gODQwMzc=\n,BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28333 invoked from network); 17 Oct 2012 23:44:20 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.17.8)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 23:44:20 -0000
Received: from server2-groupware.localnet (p4FEF8564.dip0.t-ipconnect.de
	[79.239.133.100])
	by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis)
	id 0LrXNx-1TTyQu1ERp-012vGQ; Thu, 18 Oct 2012 01:44:20 +0200
From: Ronny Hegewald 
Date: Thu, 18 Oct 2012 00:49:35 +0000
User-Agent: KMail/1.11.4 (Linux/3.0.3; KDE/4.2.4; i686; ; )
MIME-Version: 1.0
Content-Disposition: inline
To: xen-devel@lists.xen.org
Message-Id: <201210180049.35688.ronny.hegewald@online.de>
X-Provags-ID: V02:K0:huewqBrXiYK6OrfXwZ64MGLs6HETis/kUXBtCEFYHsM
	/fB4l8Ekk4PLC6zZLwq5hdVLM2P+Q3qXeHLWC6T1f1NLJ5IqMb
	wFpYuXcSo9hsztGx0MgaRXES8VtyO+/V9xgW6jxDC7JF36XE6M
	v8Vv4XXvqmkGDjm62i8p51QoWbjBc3lXTnf6pA3/l1Z28oW590
	V4TbSepu1v/py/zE9VHT41Lk7ietcKqHeiG3kgAsc/60Xi8LkJ
	6sWtCYpmrhaSb4lhsCCIdwIiZftvrHV0NAjOEGyzEMzeGkJ3z0
	er09YCWE29RRJv7dZCgLWuz6TXlls7BWd23eZ8XZpFask/tubg
	KU2Oav7Dpk5YLd0TtoZuXuNdQdTO4/NKQkyyqqZq0qa9GHznkP
	LAzlBntyQXQT0sgIgxEz7k0QzdJLL21hVY=
Subject: [Xen-devel] [PATCH 0/1] fix xen-crash at panic()-call during boot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Xen is crashing for me since version 4.1.3 during boot on a AMD machine.

This happens since patch "x86-64: detect processors subject to AMD erratum 
#121 and refuse to boot."

Instead of the actual panic-message from the patch the following stacktrace 
appears (i typed it down from screen, so it might contain typos)


find_iommu_for_device
amd_iommu_ioapic_update_ire
timer_interrupt
enable_8259_A_irq
do_IRQ
printk_start_of_line
acpi_os_printf
io_apic_write
__ioapic_write_entry
ioapic_write_entry
__clear_IO_APIC_pin
clear_IO_APIC
disable_IO_APIC
__stop_this_cpu
smp_send_stop
machine_restart
panic
tasklet_schedule_on_cpu
display_cacheinfo
init_amd
generic_identify
identify_cpu
_start_xen
_high_start

Panic on CPU 0:
Xen BUG at pci_amd_iommu.c:33

=====

The patch in the next mail fixes the problem for me and the intended panic-
message appears.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 23:45:03 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 23:45:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOdHv-0008LY-QM; Wed, 17 Oct 2012 23:44:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOdHu-0008LR-G6
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 23:44:34 +0000
Received: from [85.158.143.35:7430] by server-1.bemta-4.messagelabs.com id
	4E/94-19134-1E24F705; Wed, 17 Oct 2012 23:44:33 +0000
X-Env-Sender: ronny.hegewald@online.de
X-Msg-Ref: server-16.tower-21.messagelabs.com!1350517473!14459301!1
X-Originating-IP: [212.227.126.171]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xNzEgPT4gNzcxMzM=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xNzEgPT4gNzcxMzM=\n,BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19740 invoked from network); 17 Oct 2012 23:44:33 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.126.171)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 23:44:33 -0000
Received: from server2-groupware.localnet (p4FEF8564.dip0.t-ipconnect.de
	[79.239.133.100])
	by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis)
	id 0LlItW-1TwJsO1D5a-00bFEz; Thu, 18 Oct 2012 01:44:32 +0200
From: Ronny Hegewald 
To: xen-devel@lists.xen.org
Date: Thu, 18 Oct 2012 00:49:56 +0000
User-Agent: KMail/1.11.4 (Linux/3.0.3; KDE/4.2.4; i686; ; )
MIME-Version: 1.0
Content-Disposition: inline
Message-Id: <201210180049.56561.ronny.hegewald@online.de>
X-Provags-ID: V02:K0:PTNX91DKS0BpTqRHMPbeMcgwgNz7ikqYIdneXOxRH9V
	CIiWN0N9phqeVNcF01o2sovvWp/gZiZ6WrE1EvaPfRnVO0Kng0
	v8Yc3E8AdHHqTMr6W4nlztul1gu6M4gXIuzJFxbNrZR0QvucQI
	Ifb8rYWwObwYZTSZ7FtEoDUO+KK5YNVptORg6xQqzOMLC8kaho
	RzHmuL2jBngrPSj5jz5tqJN90thxNKyqyyhe79J7BYA5atTPU/
	5A//zrOMrWeXy7EWqyWjXBsHrXYDfnkmm6gjsV+/oCFc+70OeZ
	4bZlSaovKnN9aMEAyyAXxcGL8H7bhNho+iJXQXyBSx7VIfQUYo
	sTLJm1Whm+wOj+thSD673+ECIvz5mOETXUY6Ubbhxef7ZTT24H
	90j1S7E6r/BByLoIJiuzbzNt5bPbo8I9jE=
Subject: [Xen-devel] [PATCH 1/1] keep iommu disabled until iommu_setup is
	called
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The iommu is enabled by default when xen is booting and later disabled in 
iommu_setup() when no iommu is present.

But under some circumstances iommu-code can be called before iommu_setup() is 
processed. If there is no iommu available xen crashes.

This can happen for example when panic(...) is called that got introduced with
patch "x86-64: detect processors subject to AMD erratum #121 and refuse to 
boot." since xen 4.1.3 and results in the following stacktrace:

   find_iommu_for_device
   amd_iommu_ioapic_update_ire
   timer_interrupt
   enable_8259_A_irq
   do_IRQ
   printk_start_of_line
   acpi_os_printf
   io_apic_write
   __ioapic_write_entry
   ioapic_write_entry
   __clear_IO_APIC_pin
   clear_IO_APIC
   disable_IO_APIC
   __stop_this_cpu
   smp_send_stop
   machine_restart
   panic
   tasklet_schedule_on_cpu
   display_cacheinfo
   init_amd
   generic_identify
   identify_cpu
   _start_xen
   _high_start


This patch fixes this by keeping the iommu disabled until iommu_setup() is 
entered. 

Signed-off-by: Ronny Hegewald@online.de

--- xen/drivers/passthrough/iommu.c.org	2012-10-05 03:38:33.000000000 +0000
+++ xen/drivers/passthrough/iommu.c	2012-10-17 22:58:07.000000000 +0000
@@ -38,7 +38,7 @@
  *   no-intremap                Disable VT-d Interrupt Remapping
  */
 custom_param("iommu", parse_iommu_param);
-bool_t __read_mostly iommu_enabled = 1;
+bool_t __read_mostly iommu_enabled = 0;
 bool_t __read_mostly force_iommu;
 bool_t __initdata iommu_dom0_strict;
 bool_t __read_mostly iommu_verbose;
@@ -51,6 +51,8 @@
 bool_t __read_mostly amd_iommu_debug;
 bool_t __read_mostly amd_iommu_perdev_intremap;
 
+bool_t iommu_enabled_default = 1;
+
 static void __init parse_iommu_param(char *s)
 {
     char *ss;
@@ -61,7 +63,7 @@
             *ss = '\0';
 
         if ( !parse_bool(s) )
-            iommu_enabled = 0;
+            iommu_enabled_default = 0;
         else if ( !strcmp(s, "force") || !strcmp(s, "required") )
             force_iommu = 1;
         else if ( !strcmp(s, "workaround_bios_bug") )
@@ -312,6 +314,7 @@
 {
     int rc = -ENODEV;
     bool_t force_intremap = force_iommu && iommu_intremap;
+    iommu_enabled = iommu_enabled_default;
 
     if ( iommu_dom0_strict )
         iommu_passthrough = 0;









_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 23:45:03 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 23:45:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOdHv-0008LY-QM; Wed, 17 Oct 2012 23:44:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOdHu-0008LR-G6
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 23:44:34 +0000
Received: from [85.158.143.35:7430] by server-1.bemta-4.messagelabs.com id
	4E/94-19134-1E24F705; Wed, 17 Oct 2012 23:44:33 +0000
X-Env-Sender: ronny.hegewald@online.de
X-Msg-Ref: server-16.tower-21.messagelabs.com!1350517473!14459301!1
X-Originating-IP: [212.227.126.171]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xNzEgPT4gNzcxMzM=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xNzEgPT4gNzcxMzM=\n,BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19740 invoked from network); 17 Oct 2012 23:44:33 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.126.171)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Oct 2012 23:44:33 -0000
Received: from server2-groupware.localnet (p4FEF8564.dip0.t-ipconnect.de
	[79.239.133.100])
	by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis)
	id 0LlItW-1TwJsO1D5a-00bFEz; Thu, 18 Oct 2012 01:44:32 +0200
From: Ronny Hegewald 
To: xen-devel@lists.xen.org
Date: Thu, 18 Oct 2012 00:49:56 +0000
User-Agent: KMail/1.11.4 (Linux/3.0.3; KDE/4.2.4; i686; ; )
MIME-Version: 1.0
Content-Disposition: inline
Message-Id: <201210180049.56561.ronny.hegewald@online.de>
X-Provags-ID: V02:K0:PTNX91DKS0BpTqRHMPbeMcgwgNz7ikqYIdneXOxRH9V
	CIiWN0N9phqeVNcF01o2sovvWp/gZiZ6WrE1EvaPfRnVO0Kng0
	v8Yc3E8AdHHqTMr6W4nlztul1gu6M4gXIuzJFxbNrZR0QvucQI
	Ifb8rYWwObwYZTSZ7FtEoDUO+KK5YNVptORg6xQqzOMLC8kaho
	RzHmuL2jBngrPSj5jz5tqJN90thxNKyqyyhe79J7BYA5atTPU/
	5A//zrOMrWeXy7EWqyWjXBsHrXYDfnkmm6gjsV+/oCFc+70OeZ
	4bZlSaovKnN9aMEAyyAXxcGL8H7bhNho+iJXQXyBSx7VIfQUYo
	sTLJm1Whm+wOj+thSD673+ECIvz5mOETXUY6Ubbhxef7ZTT24H
	90j1S7E6r/BByLoIJiuzbzNt5bPbo8I9jE=
Subject: [Xen-devel] [PATCH 1/1] keep iommu disabled until iommu_setup is
	called
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The iommu is enabled by default when xen is booting and later disabled in 
iommu_setup() when no iommu is present.

But under some circumstances iommu-code can be called before iommu_setup() is 
processed. If there is no iommu available xen crashes.

This can happen for example when panic(...) is called that got introduced with
patch "x86-64: detect processors subject to AMD erratum #121 and refuse to 
boot." since xen 4.1.3 and results in the following stacktrace:

   find_iommu_for_device
   amd_iommu_ioapic_update_ire
   timer_interrupt
   enable_8259_A_irq
   do_IRQ
   printk_start_of_line
   acpi_os_printf
   io_apic_write
   __ioapic_write_entry
   ioapic_write_entry
   __clear_IO_APIC_pin
   clear_IO_APIC
   disable_IO_APIC
   __stop_this_cpu
   smp_send_stop
   machine_restart
   panic
   tasklet_schedule_on_cpu
   display_cacheinfo
   init_amd
   generic_identify
   identify_cpu
   _start_xen
   _high_start


This patch fixes this by keeping the iommu disabled until iommu_setup() is 
entered. 

Signed-off-by: Ronny Hegewald@online.de

--- xen/drivers/passthrough/iommu.c.org	2012-10-05 03:38:33.000000000 +0000
+++ xen/drivers/passthrough/iommu.c	2012-10-17 22:58:07.000000000 +0000
@@ -38,7 +38,7 @@
  *   no-intremap                Disable VT-d Interrupt Remapping
  */
 custom_param("iommu", parse_iommu_param);
-bool_t __read_mostly iommu_enabled = 1;
+bool_t __read_mostly iommu_enabled = 0;
 bool_t __read_mostly force_iommu;
 bool_t __initdata iommu_dom0_strict;
 bool_t __read_mostly iommu_verbose;
@@ -51,6 +51,8 @@
 bool_t __read_mostly amd_iommu_debug;
 bool_t __read_mostly amd_iommu_perdev_intremap;
 
+bool_t iommu_enabled_default = 1;
+
 static void __init parse_iommu_param(char *s)
 {
     char *ss;
@@ -61,7 +63,7 @@
             *ss = '\0';
 
         if ( !parse_bool(s) )
-            iommu_enabled = 0;
+            iommu_enabled_default = 0;
         else if ( !strcmp(s, "force") || !strcmp(s, "required") )
             force_iommu = 1;
         else if ( !strcmp(s, "workaround_bios_bug") )
@@ -312,6 +314,7 @@
 {
     int rc = -ENODEV;
     bool_t force_intremap = force_iommu && iommu_intremap;
+    iommu_enabled = iommu_enabled_default;
 
     if ( iommu_dom0_strict )
         iommu_passthrough = 0;









_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 23:52:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 23:52:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOdOi-0000BS-Qf; Wed, 17 Oct 2012 23:51:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOdOg-0000BM-In
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 23:51:34 +0000
Received: from [85.158.139.83:40771] by server-12.bemta-5.messagelabs.com id
	73/09-26919-4844F705; Wed, 17 Oct 2012 23:51:32 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1350517890!35171944!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1863 invoked from network); 17 Oct 2012 23:51:31 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Oct 2012 23:51:31 -0000
Received: from tazenda.hos.anvin.org (c-67-188-81-177.hsd1.ca.comcast.net
	[67.188.81.177]) (authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id q9HNpH5W012564
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256
	verify=FAIL); Wed, 17 Oct 2012 16:51:19 -0700
Message-ID: <507F4475.80705@zytor.com>
Date: Wed, 17 Oct 2012 16:51:17 -0700
From: "H. Peter Anvin" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121009 Thunderbird/16.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk 
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	<1350481786-4969-3-git-send-email-konrad.wilk@oracle.com>
In-Reply-To: <1350481786-4969-3-git-send-email-konrad.wilk@oracle.com>
Cc: linux-acpi@vger.kernel.org, x86@kernel.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH 2/4] xen/lowlevel: Implement pvop call for
	load_idt (sidt).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/17/2012 06:49 AM, Konrad Rzeszutek Wilk wrote:
> In the past it used to point to 'sidt' (native_store_idt) operation
> which is a non-privileged operation. This resulted in the
> 'struct desc_ptr' value containing the address of Xen's IDT table,
> instead of the IDT table that Linux thinks its using. The end result
> is that doing:
>
>    store_idt(&desc);
>    load_idt(&desc);
>
> would blow up b/c xen_load_idt would try to parse the IDT contents
> (desc) and de-reference a virtual address that is outside Linux's
> __va (it is in Xen's virtual address).
>
> With this patch we are providing the last written IDT address.
>

OK... this seems like another excellent set of pvops calls that should 
be nukable to Kingdom Come.  There is no reason, ever, to read the IDT 
and GDT from the kernel... the kernel already knows what they should be!

	-hpa


-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 23:52:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 23:52:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOdOi-0000BS-Qf; Wed, 17 Oct 2012 23:51:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOdOg-0000BM-In
	for xen-devel@lists.xensource.com; Wed, 17 Oct 2012 23:51:34 +0000
Received: from [85.158.139.83:40771] by server-12.bemta-5.messagelabs.com id
	73/09-26919-4844F705; Wed, 17 Oct 2012 23:51:32 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1350517890!35171944!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1863 invoked from network); 17 Oct 2012 23:51:31 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Oct 2012 23:51:31 -0000
Received: from tazenda.hos.anvin.org (c-67-188-81-177.hsd1.ca.comcast.net
	[67.188.81.177]) (authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id q9HNpH5W012564
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256
	verify=FAIL); Wed, 17 Oct 2012 16:51:19 -0700
Message-ID: <507F4475.80705@zytor.com>
Date: Wed, 17 Oct 2012 16:51:17 -0700
From: "H. Peter Anvin" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121009 Thunderbird/16.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk 
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	<1350481786-4969-3-git-send-email-konrad.wilk@oracle.com>
In-Reply-To: <1350481786-4969-3-git-send-email-konrad.wilk@oracle.com>
Cc: linux-acpi@vger.kernel.org, x86@kernel.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH 2/4] xen/lowlevel: Implement pvop call for
	load_idt (sidt).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/17/2012 06:49 AM, Konrad Rzeszutek Wilk wrote:
> In the past it used to point to 'sidt' (native_store_idt) operation
> which is a non-privileged operation. This resulted in the
> 'struct desc_ptr' value containing the address of Xen's IDT table,
> instead of the IDT table that Linux thinks its using. The end result
> is that doing:
>
>    store_idt(&desc);
>    load_idt(&desc);
>
> would blow up b/c xen_load_idt would try to parse the IDT contents
> (desc) and de-reference a virtual address that is outside Linux's
> __va (it is in Xen's virtual address).
>
> With this patch we are providing the last written IDT address.
>

OK... this seems like another excellent set of pvops calls that should 
be nukable to Kingdom Come.  There is no reason, ever, to read the IDT 
and GDT from the kernel... the kernel already knows what they should be!

	-hpa


-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 23:57:54 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 23:57:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOdUQ-0000Lr-Tr; Wed, 17 Oct 2012 23:57:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOdUP-0000Lm-SI
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 23:57:30 +0000
Received: from [85.158.139.83:52493] by server-9.bemta-5.messagelabs.com id
	E6/DC-23053-9E54F705; Wed, 17 Oct 2012 23:57:29 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1350518247!31463567!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODExMTU5\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9656 invoked from network); 17 Oct 2012 23:57:28 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Oct 2012 23:57:28 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9HNvMco027401
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Oct 2012 23:57:22 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9HNvLCm029089
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Oct 2012 23:57:21 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9HNvL24002511; Wed, 17 Oct 2012 18:57:21 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 16:57:21 -0700
Date: Wed, 17 Oct 2012 16:57:18 -0700
From: Mukesh Rathor 
To: Ian Campbell 
Message-ID: <20121017165718.683fa30f@mantra.us.oracle.com>
In-Reply-To: <1350473532-15863-6-git-send-email-ian.campbell@citrix.com>
References: <1350473518.2460.58.camel@zakaz.uk.xensource.com>
	<1350473532-15863-6-git-send-email-ian.campbell@citrix.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel@lists.xen.org, Stefano Stabellini ,
	linux-kernel@vger.kernel.org,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 6/6] xen: x86 pvh: use
 XENMEM_add_to_physmap_range for foreign gmfn mappings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 17 Oct 2012 12:32:12 +0100
Ian Campbell  wrote:

> Squeezing the necessary fields into the existing XENMEM_add_to_physmap
> interface was proving to be a bit tricky so we have decided to go with
> a new interface upstream (the XENMAPSPACE_gmfn_foreign interface using
> XENMEM_add_to_physmap was never committed anywhere). This interface
> also allows for batching which was impossible to support at the same
> time as foreign mfns in the old interface.
> 
> This reverts the relevant parts of "PVH: basic and header changes,
> elfnote changes, ..." and followups and trivially converts
> pvh_add_to_xen_p2m over.


Hmm... I don't see xen side implementation of XENMEM_add_to_physmap_range,
and since I've already got my patches tested and cut, I'm going to send
them now. We can apply this change easily in konrad's tree.

thanks,
mukesh


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 17 23:57:54 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 17 Oct 2012 23:57:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOdUQ-0000Lr-Tr; Wed, 17 Oct 2012 23:57:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOdUP-0000Lm-SI
	for xen-devel@lists.xen.org; Wed, 17 Oct 2012 23:57:30 +0000
Received: from [85.158.139.83:52493] by server-9.bemta-5.messagelabs.com id
	E6/DC-23053-9E54F705; Wed, 17 Oct 2012 23:57:29 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1350518247!31463567!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODExMTU5\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9656 invoked from network); 17 Oct 2012 23:57:28 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Oct 2012 23:57:28 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9HNvMco027401
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 17 Oct 2012 23:57:22 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9HNvLCm029089
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 17 Oct 2012 23:57:21 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9HNvL24002511; Wed, 17 Oct 2012 18:57:21 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 16:57:21 -0700
Date: Wed, 17 Oct 2012 16:57:18 -0700
From: Mukesh Rathor 
To: Ian Campbell 
Message-ID: <20121017165718.683fa30f@mantra.us.oracle.com>
In-Reply-To: <1350473532-15863-6-git-send-email-ian.campbell@citrix.com>
References: <1350473518.2460.58.camel@zakaz.uk.xensource.com>
	<1350473532-15863-6-git-send-email-ian.campbell@citrix.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel@lists.xen.org, Stefano Stabellini ,
	linux-kernel@vger.kernel.org,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 6/6] xen: x86 pvh: use
 XENMEM_add_to_physmap_range for foreign gmfn mappings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 17 Oct 2012 12:32:12 +0100
Ian Campbell  wrote:

> Squeezing the necessary fields into the existing XENMEM_add_to_physmap
> interface was proving to be a bit tricky so we have decided to go with
> a new interface upstream (the XENMAPSPACE_gmfn_foreign interface using
> XENMEM_add_to_physmap was never committed anywhere). This interface
> also allows for batching which was impossible to support at the same
> time as foreign mfns in the old interface.
> 
> This reverts the relevant parts of "PVH: basic and header changes,
> elfnote changes, ..." and followups and trivially converts
> pvh_add_to_xen_p2m over.


Hmm... I don't see xen side implementation of XENMEM_add_to_physmap_range,
and since I've already got my patches tested and cut, I'm going to send
them now. We can apply this change easily in konrad's tree.

thanks,
mukesh


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 00:03:39 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 00:03:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOda2-0000zq-Os; Thu, 18 Oct 2012 00:03:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOda0-0000zi-JJ
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 00:03:16 +0000
Received: from [85.158.143.35:38902] by server-3.bemta-4.messagelabs.com id
	A8/13-03544-3474F705; Thu, 18 Oct 2012 00:03:15 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1350518593!19241217!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2099 invoked from network); 18 Oct 2012 00:03:15 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Oct 2012 00:03:15 -0000
Received: from tazenda.hos.anvin.org (c-67-188-81-177.hsd1.ca.comcast.net
	[67.188.81.177]) (authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id q9I039ac014629
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256
	verify=FAIL); Wed, 17 Oct 2012 17:03:11 -0700
Message-ID: <507F473D.1060700@zytor.com>
Date: Wed, 17 Oct 2012 17:03:09 -0700
From: "H. Peter Anvin" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121009 Thunderbird/16.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk 
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	<1350481786-4969-2-git-send-email-konrad.wilk@oracle.com>
In-Reply-To: <1350481786-4969-2-git-send-email-konrad.wilk@oracle.com>
Cc: linux-acpi@vger.kernel.org, x86@kernel.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH 1/4] x86/wakeup/sleep: Check whether the TSS
 GDT descriptor is empty before using it.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/17/2012 06:49 AM, Konrad Rzeszutek Wilk wrote:
> We check the TSS descriptor before we try to dereference it.
> Also fix up the value to use the #defines.
>
> Signed-off-by: Konrad Rzeszutek Wilk 
> ---
>   arch/x86/power/cpu.c |    7 +++++--
>   1 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/power/cpu.c b/arch/x86/power/cpu.c
> index 218cdb1..c17370e 100644
> --- a/arch/x86/power/cpu.c
> +++ b/arch/x86/power/cpu.c
> @@ -133,7 +133,9 @@ static void fix_processor_context(void)
>   {
>   	int cpu = smp_processor_id();
>   	struct tss_struct *t = &per_cpu(init_tss, cpu);
> -
> +#ifdef CONFIG_X86_64
> +	struct desc_struct *desc = get_cpu_gdt_table(cpu);
> +#endif
>   	set_tss_desc(cpu, t);	/*
>   				 * This just modifies memory; should not be
>   				 * necessary. But... This is necessary, because
> @@ -142,7 +144,8 @@ static void fix_processor_context(void)
>   				 */
>
>   #ifdef CONFIG_X86_64
> -	get_cpu_gdt_table(cpu)[GDT_ENTRY_TSS].type = 9;
> +	if (!desc_empty(&desc[GDT_ENTRY_TSS]))
> +		desc[GDT_ENTRY_TSS].type = DESC_TSS;
>
>   	syscall_init();				/* This sets MSR_*STAR and related */
>   #endif
>

Why is this patch necessary?  Presumably there is something further down 
the line which depends on the TSS descriptor being empty, but if so, what?

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 00:03:39 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 00:03:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOda2-0000zq-Os; Thu, 18 Oct 2012 00:03:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOda0-0000zi-JJ
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 00:03:16 +0000
Received: from [85.158.143.35:38902] by server-3.bemta-4.messagelabs.com id
	A8/13-03544-3474F705; Thu, 18 Oct 2012 00:03:15 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1350518593!19241217!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2099 invoked from network); 18 Oct 2012 00:03:15 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Oct 2012 00:03:15 -0000
Received: from tazenda.hos.anvin.org (c-67-188-81-177.hsd1.ca.comcast.net
	[67.188.81.177]) (authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id q9I039ac014629
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256
	verify=FAIL); Wed, 17 Oct 2012 17:03:11 -0700
Message-ID: <507F473D.1060700@zytor.com>
Date: Wed, 17 Oct 2012 17:03:09 -0700
From: "H. Peter Anvin" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121009 Thunderbird/16.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk 
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	<1350481786-4969-2-git-send-email-konrad.wilk@oracle.com>
In-Reply-To: <1350481786-4969-2-git-send-email-konrad.wilk@oracle.com>
Cc: linux-acpi@vger.kernel.org, x86@kernel.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH 1/4] x86/wakeup/sleep: Check whether the TSS
 GDT descriptor is empty before using it.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/17/2012 06:49 AM, Konrad Rzeszutek Wilk wrote:
> We check the TSS descriptor before we try to dereference it.
> Also fix up the value to use the #defines.
>
> Signed-off-by: Konrad Rzeszutek Wilk 
> ---
>   arch/x86/power/cpu.c |    7 +++++--
>   1 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/power/cpu.c b/arch/x86/power/cpu.c
> index 218cdb1..c17370e 100644
> --- a/arch/x86/power/cpu.c
> +++ b/arch/x86/power/cpu.c
> @@ -133,7 +133,9 @@ static void fix_processor_context(void)
>   {
>   	int cpu = smp_processor_id();
>   	struct tss_struct *t = &per_cpu(init_tss, cpu);
> -
> +#ifdef CONFIG_X86_64
> +	struct desc_struct *desc = get_cpu_gdt_table(cpu);
> +#endif
>   	set_tss_desc(cpu, t);	/*
>   				 * This just modifies memory; should not be
>   				 * necessary. But... This is necessary, because
> @@ -142,7 +144,8 @@ static void fix_processor_context(void)
>   				 */
>
>   #ifdef CONFIG_X86_64
> -	get_cpu_gdt_table(cpu)[GDT_ENTRY_TSS].type = 9;
> +	if (!desc_empty(&desc[GDT_ENTRY_TSS]))
> +		desc[GDT_ENTRY_TSS].type = DESC_TSS;
>
>   	syscall_init();				/* This sets MSR_*STAR and related */
>   #endif
>

Why is this patch necessary?  Presumably there is something further down 
the line which depends on the TSS descriptor being empty, but if so, what?

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 00:25:48 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 00:25:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOdvM-0001D9-Ge; Thu, 18 Oct 2012 00:25:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOdvL-0001D4-9M
	for Xen-devel@lists.xensource.com; Thu, 18 Oct 2012 00:25:19 +0000
Received: from [85.158.139.211:18457] by server-5.bemta-5.messagelabs.com id
	61/92-09732-E6C4F705; Thu, 18 Oct 2012 00:25:18 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1350519916!22746991!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODExMTU5\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29442 invoked from network); 18 Oct 2012 00:25:17 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Oct 2012 00:25:17 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9I0PErE014163
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 18 Oct 2012 00:25:15 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9I0PDaQ003853
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 18 Oct 2012 00:25:14 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9I0PDd9003991; Wed, 17 Oct 2012 19:25:13 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 17:25:12 -0700
Date: Wed, 17 Oct 2012 17:25:11 -0700
From: Mukesh Rathor 
To: Konrad Rzeszutek Wilk 
Message-ID: <20121017172511.40e0bb28@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" 
Subject: [Xen-devel] [PATCH V3 0/6]: PVH: PV guest with extensions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi guys,

Ok, I've made the changes from prev V2 patch submission comments. Tested
all the combinations. I am building xen patch just for the
corresponding header file changes. Following that I'll refresh xen
tree, debug, test, and send patches.

For linux kernel mailing list introduction, PVH is a PV guest that can
run in an HVM container, uses native pagetables, uses callback vector,
native IDT, and native syscalls.

They were built on top of 89d0307af2b9957d59bfb2a86aaa57464ff921de
commit.

thanks,
Mukesh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 00:25:48 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 00:25:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOdvM-0001D9-Ge; Thu, 18 Oct 2012 00:25:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOdvL-0001D4-9M
	for Xen-devel@lists.xensource.com; Thu, 18 Oct 2012 00:25:19 +0000
Received: from [85.158.139.211:18457] by server-5.bemta-5.messagelabs.com id
	61/92-09732-E6C4F705; Thu, 18 Oct 2012 00:25:18 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1350519916!22746991!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODExMTU5\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29442 invoked from network); 18 Oct 2012 00:25:17 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Oct 2012 00:25:17 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9I0PErE014163
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 18 Oct 2012 00:25:15 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9I0PDaQ003853
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 18 Oct 2012 00:25:14 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9I0PDd9003991; Wed, 17 Oct 2012 19:25:13 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 17:25:12 -0700
Date: Wed, 17 Oct 2012 17:25:11 -0700
From: Mukesh Rathor 
To: Konrad Rzeszutek Wilk 
Message-ID: <20121017172511.40e0bb28@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" 
Subject: [Xen-devel] [PATCH V3 0/6]: PVH: PV guest with extensions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi guys,

Ok, I've made the changes from prev V2 patch submission comments. Tested
all the combinations. I am building xen patch just for the
corresponding header file changes. Following that I'll refresh xen
tree, debug, test, and send patches.

For linux kernel mailing list introduction, PVH is a PV guest that can
run in an HVM container, uses native pagetables, uses callback vector,
native IDT, and native syscalls.

They were built on top of 89d0307af2b9957d59bfb2a86aaa57464ff921de
commit.

thanks,
Mukesh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 00:27:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 00:27:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOdwo-0001I8-Vs; Thu, 18 Oct 2012 00:26:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOdwo-0001I1-3J
	for Xen-devel@lists.xensource.com; Thu, 18 Oct 2012 00:26:50 +0000
Received: from [85.158.143.99:37823] by server-3.bemta-4.messagelabs.com id
	10/1B-03544-9CC4F705; Thu, 18 Oct 2012 00:26:49 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1350520007!24762534!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgxODIzOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17778 invoked from network); 18 Oct 2012 00:26:48 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Oct 2012 00:26:48 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9I0Qjvi009714
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 18 Oct 2012 00:26:45 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9I0QioX007532
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 18 Oct 2012 00:26:45 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9I0QiQj017110; Wed, 17 Oct 2012 19:26:44 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 17:26:44 -0700
Date: Wed, 17 Oct 2012 17:26:42 -0700
From: Mukesh Rathor 
To: Konrad Rzeszutek Wilk ,
	"Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" 
Message-ID: <20121017172642.349b2aae@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Subject: [Xen-devel] [PATCH V3 1/6]: PVH: basic and header changes,
	elfnote changes, ...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

[PATCH 1/6] PVH: is a PV linux guest that has extended capabilities. This patch allows it to be configured and enabled. Also, basic header file changes to add new subcalls to physmap hypercall. Lastly, mfn_to_local_pfn must return mfn for paging mode translate.

Signed-off-by: Mukesh Rathor 
---
 arch/x86/include/asm/xen/page.h |    3 +++
 arch/x86/xen/Kconfig            |   10 ++++++++++
 arch/x86/xen/xen-head.S         |   11 ++++++++++-
 include/xen/interface/memory.h  |   24 +++++++++++++++++++++++-
 include/xen/interface/physdev.h |   10 ++++++++++
 5 files changed, 56 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index 472b9b7..6af440d 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -159,6 +159,9 @@ static inline xpaddr_t machine_to_phys(xmaddr_t machine)
 static inline unsigned long mfn_to_local_pfn(unsigned long mfn)
 {
 	unsigned long pfn = mfn_to_pfn(mfn);
+
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return mfn;
 	if (get_phys_to_machine(pfn) != mfn)
 		return -1; /* force !pfn_valid() */
 	return pfn;
diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index fdce49c..822c5a0 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -50,3 +50,13 @@ config XEN_DEBUG_FS
 	  Enable statistics output and various tuning options in debugfs.
 	  Enabling this option may incur a significant performance overhead.
 
+config XEN_X86_PVH
+	bool "Support for running as a PVH guest (EXPERIMENTAL)"
+	depends on X86_64 && XEN && EXPERIMENTAL
+	default n
+	help
+	   This option enables support for running as a PVH guest (PV guest
+	   using hardware extensions) under a suitably capable hypervisor.
+	   This option is EXPERIMENTAL because the hypervisor interfaces
+	   which it uses are not yet considered stable therefore backwards and
+	   forwards compatibility is not yet guaranteed.  If unsure, say N.
diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
index 7faed58..1a6bca1 100644
--- a/arch/x86/xen/xen-head.S
+++ b/arch/x86/xen/xen-head.S
@@ -13,6 +13,15 @@
 #include 
 #include 
 
+#ifdef CONFIG_XEN_X86_PVH
+#define FEATURES_PVH "|writable_descriptor_tables" \
+		     "|auto_translated_physmap" \
+		     "|supervisor_mode_kernel" \
+		     "|hvm_callback_vector"
+#else
+#define FEATURES_PVH /* Not supported */
+#endif
+
 	__INIT
 ENTRY(startup_xen)
 	cld
@@ -95,7 +104,7 @@ NEXT_HYPERCALL(arch_6)
 #endif
 	ELFNOTE(Xen, XEN_ELFNOTE_ENTRY,          _ASM_PTR startup_xen)
 	ELFNOTE(Xen, XEN_ELFNOTE_HYPERCALL_PAGE, _ASM_PTR hypercall_page)
-	ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,       .asciz "!writable_page_tables|pae_pgdir_above_4gb")
+	ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,       .asciz "!writable_page_tables|pae_pgdir_above_4gb"FEATURES_PVH)
 	ELFNOTE(Xen, XEN_ELFNOTE_PAE_MODE,       .asciz "yes")
 	ELFNOTE(Xen, XEN_ELFNOTE_LOADER,         .asciz "generic")
 	ELFNOTE(Xen, XEN_ELFNOTE_L1_MFN_VALID,
diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index d8e33a9..425911f 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -169,7 +169,13 @@ struct xen_add_to_physmap {
     /* Source mapping space. */
 #define XENMAPSPACE_shared_info 0 /* shared info page */
 #define XENMAPSPACE_grant_table 1 /* grant table page */
-    unsigned int space;
+#define XENMAPSPACE_gmfn        2 /* GMFN */
+#define XENMAPSPACE_gmfn_range  3 /* GMFN range */
+#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */
+    uint16_t space;
+    domid_t foreign_domid;         /* IFF XENMAPSPACE_gmfn_foreign */
+
+#define XENMAPIDX_grant_table_status 0x80000000
 
     /* Index into source mapping space. */
     unsigned long idx;
@@ -237,4 +243,20 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_memory_map);
  * during a driver critical region.
  */
 extern spinlock_t xen_reservation_lock;
+
+/*
+ * Unmaps the page appearing at a particular GPFN from the specified guest's
+ * pseudophysical address space.
+ * arg == addr of xen_remove_from_physmap_t.
+ */
+#define XENMEM_remove_from_physmap      15
+struct xen_remove_from_physmap {
+    /* Which domain to change the mapping for. */
+    domid_t domid;
+
+    /* GPFN of the current mapping of the page. */
+    xen_pfn_t gpfn;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_remove_from_physmap);
+
 #endif /* __XEN_PUBLIC_MEMORY_H__ */
diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
index 9ce788d..3b9d5b6 100644
--- a/include/xen/interface/physdev.h
+++ b/include/xen/interface/physdev.h
@@ -258,6 +258,16 @@ struct physdev_pci_device {
     uint8_t devfn;
 };
 
+#define PHYSDEVOP_pvh_map_iomem        30
+struct physdev_map_iomem {
+    /* IN */
+    uint64_t first_gfn;
+    uint64_t first_mfn;
+    uint32_t nr_mfns;
+    uint32_t add_mapping;        /* 1 == add mapping;  0 == unmap */
+
+};
+
 /*
  * Notify that some PIRQ-bound event channels have been unmasked.
  * ** This command is obsolete since interface version 0x00030202 and is **
-- 
1.7.2.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 00:27:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 00:27:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOdwo-0001I8-Vs; Thu, 18 Oct 2012 00:26:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOdwo-0001I1-3J
	for Xen-devel@lists.xensource.com; Thu, 18 Oct 2012 00:26:50 +0000
Received: from [85.158.143.99:37823] by server-3.bemta-4.messagelabs.com id
	10/1B-03544-9CC4F705; Thu, 18 Oct 2012 00:26:49 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1350520007!24762534!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgxODIzOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17778 invoked from network); 18 Oct 2012 00:26:48 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Oct 2012 00:26:48 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9I0Qjvi009714
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 18 Oct 2012 00:26:45 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9I0QioX007532
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 18 Oct 2012 00:26:45 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9I0QiQj017110; Wed, 17 Oct 2012 19:26:44 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 17:26:44 -0700
Date: Wed, 17 Oct 2012 17:26:42 -0700
From: Mukesh Rathor 
To: Konrad Rzeszutek Wilk ,
	"Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" 
Message-ID: <20121017172642.349b2aae@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Subject: [Xen-devel] [PATCH V3 1/6]: PVH: basic and header changes,
	elfnote changes, ...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

[PATCH 1/6] PVH: is a PV linux guest that has extended capabilities. This patch allows it to be configured and enabled. Also, basic header file changes to add new subcalls to physmap hypercall. Lastly, mfn_to_local_pfn must return mfn for paging mode translate.

Signed-off-by: Mukesh Rathor 
---
 arch/x86/include/asm/xen/page.h |    3 +++
 arch/x86/xen/Kconfig            |   10 ++++++++++
 arch/x86/xen/xen-head.S         |   11 ++++++++++-
 include/xen/interface/memory.h  |   24 +++++++++++++++++++++++-
 include/xen/interface/physdev.h |   10 ++++++++++
 5 files changed, 56 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index 472b9b7..6af440d 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -159,6 +159,9 @@ static inline xpaddr_t machine_to_phys(xmaddr_t machine)
 static inline unsigned long mfn_to_local_pfn(unsigned long mfn)
 {
 	unsigned long pfn = mfn_to_pfn(mfn);
+
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return mfn;
 	if (get_phys_to_machine(pfn) != mfn)
 		return -1; /* force !pfn_valid() */
 	return pfn;
diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index fdce49c..822c5a0 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -50,3 +50,13 @@ config XEN_DEBUG_FS
 	  Enable statistics output and various tuning options in debugfs.
 	  Enabling this option may incur a significant performance overhead.
 
+config XEN_X86_PVH
+	bool "Support for running as a PVH guest (EXPERIMENTAL)"
+	depends on X86_64 && XEN && EXPERIMENTAL
+	default n
+	help
+	   This option enables support for running as a PVH guest (PV guest
+	   using hardware extensions) under a suitably capable hypervisor.
+	   This option is EXPERIMENTAL because the hypervisor interfaces
+	   which it uses are not yet considered stable therefore backwards and
+	   forwards compatibility is not yet guaranteed.  If unsure, say N.
diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
index 7faed58..1a6bca1 100644
--- a/arch/x86/xen/xen-head.S
+++ b/arch/x86/xen/xen-head.S
@@ -13,6 +13,15 @@
 #include 
 #include 
 
+#ifdef CONFIG_XEN_X86_PVH
+#define FEATURES_PVH "|writable_descriptor_tables" \
+		     "|auto_translated_physmap" \
+		     "|supervisor_mode_kernel" \
+		     "|hvm_callback_vector"
+#else
+#define FEATURES_PVH /* Not supported */
+#endif
+
 	__INIT
 ENTRY(startup_xen)
 	cld
@@ -95,7 +104,7 @@ NEXT_HYPERCALL(arch_6)
 #endif
 	ELFNOTE(Xen, XEN_ELFNOTE_ENTRY,          _ASM_PTR startup_xen)
 	ELFNOTE(Xen, XEN_ELFNOTE_HYPERCALL_PAGE, _ASM_PTR hypercall_page)
-	ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,       .asciz "!writable_page_tables|pae_pgdir_above_4gb")
+	ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,       .asciz "!writable_page_tables|pae_pgdir_above_4gb"FEATURES_PVH)
 	ELFNOTE(Xen, XEN_ELFNOTE_PAE_MODE,       .asciz "yes")
 	ELFNOTE(Xen, XEN_ELFNOTE_LOADER,         .asciz "generic")
 	ELFNOTE(Xen, XEN_ELFNOTE_L1_MFN_VALID,
diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index d8e33a9..425911f 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -169,7 +169,13 @@ struct xen_add_to_physmap {
     /* Source mapping space. */
 #define XENMAPSPACE_shared_info 0 /* shared info page */
 #define XENMAPSPACE_grant_table 1 /* grant table page */
-    unsigned int space;
+#define XENMAPSPACE_gmfn        2 /* GMFN */
+#define XENMAPSPACE_gmfn_range  3 /* GMFN range */
+#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */
+    uint16_t space;
+    domid_t foreign_domid;         /* IFF XENMAPSPACE_gmfn_foreign */
+
+#define XENMAPIDX_grant_table_status 0x80000000
 
     /* Index into source mapping space. */
     unsigned long idx;
@@ -237,4 +243,20 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_memory_map);
  * during a driver critical region.
  */
 extern spinlock_t xen_reservation_lock;
+
+/*
+ * Unmaps the page appearing at a particular GPFN from the specified guest's
+ * pseudophysical address space.
+ * arg == addr of xen_remove_from_physmap_t.
+ */
+#define XENMEM_remove_from_physmap      15
+struct xen_remove_from_physmap {
+    /* Which domain to change the mapping for. */
+    domid_t domid;
+
+    /* GPFN of the current mapping of the page. */
+    xen_pfn_t gpfn;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_remove_from_physmap);
+
 #endif /* __XEN_PUBLIC_MEMORY_H__ */
diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
index 9ce788d..3b9d5b6 100644
--- a/include/xen/interface/physdev.h
+++ b/include/xen/interface/physdev.h
@@ -258,6 +258,16 @@ struct physdev_pci_device {
     uint8_t devfn;
 };
 
+#define PHYSDEVOP_pvh_map_iomem        30
+struct physdev_map_iomem {
+    /* IN */
+    uint64_t first_gfn;
+    uint64_t first_mfn;
+    uint32_t nr_mfns;
+    uint32_t add_mapping;        /* 1 == add mapping;  0 == unmap */
+
+};
+
 /*
  * Notify that some PIRQ-bound event channels have been unmasked.
  * ** This command is obsolete since interface version 0x00030202 and is **
-- 
1.7.2.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 00:30:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 00:30:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOe05-0001UF-QP; Thu, 18 Oct 2012 00:30:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOe04-0001U7-BU
	for Xen-devel@lists.xensource.com; Thu, 18 Oct 2012 00:30:12 +0000
Received: from [85.158.139.211:46450] by server-9.bemta-5.messagelabs.com id
	8A/BE-23053-39D4F705; Thu, 18 Oct 2012 00:30:11 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1350520209!22714458!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgxODIzOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32069 invoked from network); 18 Oct 2012 00:30:10 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Oct 2012 00:30:10 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9I0U73K012138
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 18 Oct 2012 00:30:07 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9I0U6GM005983
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 18 Oct 2012 00:30:07 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9I0U6oJ026045; Wed, 17 Oct 2012 19:30:06 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 17:30:06 -0700
Date: Wed, 17 Oct 2012 17:30:05 -0700
From: Mukesh Rathor 
To: Konrad Rzeszutek Wilk ,
	"Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" 
Message-ID: <20121017173005.73a03eec@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Subject: [Xen-devel] [PATCH V3 2/6]: PVH: use native irq, enable callback,
 use HVM ring ops, smp, ...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

PVH: make gdt_frames[]/gdt_ents into a union with {gdtaddr, gdtsz}, PVH
only needs to send down gdtaddr and gdtsz. irq.c: PVH uses
native_irq_ops. vcpu hotplug is currently not available for PVH.
events.c: setup callback vector for PVH. smp.c: This pertains to
bringing up smp vcpus. PVH runs in ring 0, so syscalls are native.
Also, the vcpu context is send down via the hcall to be set in the
vmcs. gdtaddr and gdtsz are unionionized as PVH only needs to send
these two to be set in the vmcs. Finally, PVH ring ops uses HVM paths
for xenbus.

Signed-off-by: Mukesh Rathor 
---
 arch/x86/include/asm/xen/interface.h |   11 +++++-
 arch/x86/xen/irq.c                   |    5 ++-
 arch/x86/xen/p2m.c                   |    2 +-
 arch/x86/xen/smp.c                   |   75
++++++++++++++++++++++------------ drivers/xen/cpu_hotplug.c
|    4 +- drivers/xen/events.c                 |    9 ++++-
 drivers/xen/xenbus/xenbus_client.c   |    3 +-
 7 files changed, 77 insertions(+), 32 deletions(-)

diff --git a/arch/x86/include/asm/xen/interface.h
b/arch/x86/include/asm/xen/interface.h index 555f94d..ac5ef76 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -143,7 +143,16 @@ struct vcpu_guest_context {
     struct cpu_user_regs user_regs;         /* User-level CPU
registers     */ struct trap_info trap_ctxt[256];        /* Virtual
IDT                  */ unsigned long ldt_base, ldt_ents;       /* LDT
(linear address, # ents) */
-    unsigned long gdt_frames[16], gdt_ents; /* GDT (machine frames, #
ents) */
+    union {
+	struct {
+		/* PV: GDT (machine frames, # ents).*/
+		unsigned long gdt_frames[16], gdt_ents;
+	} pv;
+	struct {
+		/* PVH: GDTR addr and size */
+	    unsigned long gdtaddr, gdtsz;
+	} pvh;
+    } u;
     unsigned long kernel_ss, kernel_sp;     /* Virtual TSS (only
SS1/SP1)   */ /* NB. User pagetable on x86/64 is placed in ctrlreg[1].
*/ unsigned long ctrlreg[8];               /* CR0-CR7 (control
registers)  */ diff --git a/arch/x86/xen/irq.c b/arch/x86/xen/irq.c
index 1573376..31959a7 100644
--- a/arch/x86/xen/irq.c
+++ b/arch/x86/xen/irq.c
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -128,6 +129,8 @@ static const struct pv_irq_ops xen_irq_ops
__initconst = { 
 void __init xen_init_irq_ops(void)
 {
-	pv_irq_ops = xen_irq_ops;
+	/* For PVH we use default pv_irq_ops settings */
+	if (!xen_feature(XENFEAT_hvm_callback_vector))
+		pv_irq_ops = xen_irq_ops;
 	x86_init.irqs.intr_init = xen_init_IRQ;
 }
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 95fb2aa..ea553c8 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -798,7 +798,7 @@ bool __set_phys_to_machine(unsigned long pfn,
unsigned long mfn) {
 	unsigned topidx, mididx, idx;
 
-	if (unlikely(xen_feature(XENFEAT_auto_translated_physmap))) {
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
 		BUG_ON(pfn != mfn && mfn != INVALID_P2M_ENTRY);
 		return true;
 	}
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index f58dca7..cda1907 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -68,9 +68,11 @@ static void __cpuinit cpu_bringup(void)
 	touch_softlockup_watchdog();
 	preempt_disable();
 
-	xen_enable_sysenter();
-	xen_enable_syscall();
-
+	/* PVH runs in ring 0 and allows us to do native syscalls.
Yay! */
+	if (!xen_feature(XENFEAT_supervisor_mode_kernel)) {
+		xen_enable_sysenter();
+		xen_enable_syscall();
+	}
 	cpu = smp_processor_id();
 	smp_store_cpu_info(cpu);
 	cpu_data(cpu).x86_max_cores = 1;
@@ -230,10 +232,11 @@ static void __init xen_smp_prepare_boot_cpu(void)
 	BUG_ON(smp_processor_id() != 0);
 	native_smp_prepare_boot_cpu();
 
-	/* We've switched to the "real" per-cpu gdt, so make sure the
-	   old memory can be recycled */
-	make_lowmem_page_readwrite(xen_initial_gdt);
-
+	if (!xen_feature(XENFEAT_writable_page_tables)) {
+		/* We've switched to the "real" per-cpu gdt, so make
sure the
+		 * old memory can be recycled */
+		make_lowmem_page_readwrite(xen_initial_gdt);
+	}
 	xen_filter_cpu_maps();
 	xen_setup_vcpu_info_placement();
 }
@@ -300,8 +303,6 @@ cpu_initialize_context(unsigned int cpu, struct
task_struct *idle) gdt = get_cpu_gdt_table(cpu);
 
 	ctxt->flags = VGCF_IN_KERNEL;
-	ctxt->user_regs.ds = __USER_DS;
-	ctxt->user_regs.es = __USER_DS;
 	ctxt->user_regs.ss = __KERNEL_DS;
 #ifdef CONFIG_X86_32
 	ctxt->user_regs.fs = __KERNEL_PERCPU;
@@ -310,35 +311,57 @@ cpu_initialize_context(unsigned int cpu, struct
task_struct *idle) ctxt->gs_base_kernel = per_cpu_offset(cpu);
 #endif
 	ctxt->user_regs.eip = (unsigned long)cpu_bringup_and_idle;
-	ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
 
 	memset(&ctxt->fpu_ctxt, 0, sizeof(ctxt->fpu_ctxt));
 
-	xen_copy_trap_info(ctxt->trap_ctxt);
+	/* check for autoxlated to get it right for 32bit kernel */
+	if (xen_feature(XENFEAT_auto_translated_physmap) &&
+	    xen_feature(XENFEAT_supervisor_mode_kernel)) {
 
-	ctxt->ldt_ents = 0;
+		ctxt->user_regs.ds = __KERNEL_DS;
+		ctxt->user_regs.es = 0;
+		ctxt->user_regs.gs = 0;
 
-	BUG_ON((unsigned long)gdt & ~PAGE_MASK);
+		ctxt->u.pvh.gdtaddr = (unsigned long)gdt;
+		ctxt->u.pvh.gdtsz = (unsigned long)(GDT_SIZE - 1);
 
-	gdt_mfn = arbitrary_virt_to_mfn(gdt);
-	make_lowmem_page_readonly(gdt);
-	make_lowmem_page_readonly(mfn_to_virt(gdt_mfn));
+#ifdef CONFIG_X86_64
+		/* Note: PVH is not supported on x86_32. */
+		ctxt->gs_base_user = (unsigned long)
+
per_cpu(irq_stack_union.gs_base, cpu); +#endif
+	} else {
+		ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
+		ctxt->user_regs.ds = __USER_DS;
+		ctxt->user_regs.es = __USER_DS;
 
-	ctxt->gdt_frames[0] = gdt_mfn;
-	ctxt->gdt_ents      = GDT_ENTRIES;
+		xen_copy_trap_info(ctxt->trap_ctxt);
 
-	ctxt->user_regs.cs = __KERNEL_CS;
-	ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct
pt_regs);
+		ctxt->ldt_ents = 0;
 
-	ctxt->kernel_ss = __KERNEL_DS;
-	ctxt->kernel_sp = idle->thread.sp0;
+		BUG_ON((unsigned long)gdt & ~PAGE_MASK);
+
+		gdt_mfn = arbitrary_virt_to_mfn(gdt);
+		make_lowmem_page_readonly(gdt);
+		make_lowmem_page_readonly(mfn_to_virt(gdt_mfn));
+
+		ctxt->u.pv.gdt_frames[0] = gdt_mfn;
+		ctxt->u.pv.gdt_ents      = GDT_ENTRIES;
+
+		ctxt->kernel_ss = __KERNEL_DS;
+		ctxt->kernel_sp = idle->thread.sp0;
 
 #ifdef CONFIG_X86_32
-	ctxt->event_callback_cs     = __KERNEL_CS;
-	ctxt->failsafe_callback_cs  = __KERNEL_CS;
+		ctxt->event_callback_cs     = __KERNEL_CS;
+		ctxt->failsafe_callback_cs  = __KERNEL_CS;
 #endif
-	ctxt->event_callback_eip    = (unsigned
long)xen_hypervisor_callback;
-	ctxt->failsafe_callback_eip = (unsigned
long)xen_failsafe_callback;
+		ctxt->event_callback_eip    =
+					(unsigned
long)xen_hypervisor_callback;
+		ctxt->failsafe_callback_eip =
+					(unsigned
long)xen_failsafe_callback;
+	}
+	ctxt->user_regs.cs = __KERNEL_CS;
+	ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct
pt_regs); 
 	per_cpu(xen_cr3, cpu) = __pa(swapper_pg_dir);
 	ctxt->ctrlreg[3] = xen_pfn_to_cr3(virt_to_mfn(swapper_pg_dir));
diff --git a/drivers/xen/cpu_hotplug.c b/drivers/xen/cpu_hotplug.c
index 4dcfced..de6bcf9 100644
--- a/drivers/xen/cpu_hotplug.c
+++ b/drivers/xen/cpu_hotplug.c
@@ -2,6 +2,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -100,7 +101,8 @@ static int __init setup_vcpu_hotplug_event(void)
 	static struct notifier_block xsn_cpu = {
 		.notifier_call = setup_cpu_watcher };
 
-	if (!xen_pv_domain())
+	/* PVH TBD/FIXME: future work */
+	if (!xen_pv_domain() ||
xen_feature(XENFEAT_auto_translated_physmap)) return -ENODEV;
 
 	register_xenstore_notifier(&xsn_cpu);
diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index c60d162..a977612 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -1767,7 +1767,7 @@ int xen_set_callback_via(uint64_t via)
 }
 EXPORT_SYMBOL_GPL(xen_set_callback_via);
 
-#ifdef CONFIG_XEN_PVHVM
+#ifdef CONFIG_X86
 /* Vector callbacks are better than PCI interrupts to receive event
  * channel notifications because we can receive vector callbacks on any
  * vcpu and we don't need PCI support or APIC interactions. */
@@ -1826,6 +1826,13 @@ void __init xen_init_IRQ(void)
 		if (xen_initial_domain())
 			pci_xen_initial_domain();
 
+		if (xen_feature(XENFEAT_hvm_callback_vector)) {
+			xen_callback_vector();
+			return;
+		}
+
+		/* PVH: TBD/FIXME: debug and fix eio map to work with
pvh */ +
 		pirq_eoi_map = (void
*)__get_free_page(GFP_KERNEL|__GFP_ZERO); eoi_gmfn.gmfn =
virt_to_mfn(pirq_eoi_map); rc =
HYPERVISOR_physdev_op(PHYSDEVOP_pirq_eoi_gmfn_v2, &eoi_gmfn); diff
--git a/drivers/xen/xenbus/xenbus_client.c
b/drivers/xen/xenbus/xenbus_client.c index b3e146e..1bac743 100644 ---
a/drivers/xen/xenbus/xenbus_client.c +++
b/drivers/xen/xenbus/xenbus_client.c @@ -44,6 +44,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "xenbus_probe.h"
 
@@ -743,7 +744,7 @@ static const struct xenbus_ring_ops ring_ops_hvm = {
 
 void __init xenbus_ring_ops_init(void)
 {
-	if (xen_pv_domain())
+	if (xen_pv_domain()
&& !xen_feature(XENFEAT_auto_translated_physmap)) ring_ops =
&ring_ops_pv; else
 		ring_ops = &ring_ops_hvm;
-- 
1.7.2.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 00:30:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 00:30:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOe05-0001UF-QP; Thu, 18 Oct 2012 00:30:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOe04-0001U7-BU
	for Xen-devel@lists.xensource.com; Thu, 18 Oct 2012 00:30:12 +0000
Received: from [85.158.139.211:46450] by server-9.bemta-5.messagelabs.com id
	8A/BE-23053-39D4F705; Thu, 18 Oct 2012 00:30:11 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1350520209!22714458!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgxODIzOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32069 invoked from network); 18 Oct 2012 00:30:10 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Oct 2012 00:30:10 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9I0U73K012138
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 18 Oct 2012 00:30:07 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9I0U6GM005983
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 18 Oct 2012 00:30:07 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9I0U6oJ026045; Wed, 17 Oct 2012 19:30:06 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 17:30:06 -0700
Date: Wed, 17 Oct 2012 17:30:05 -0700
From: Mukesh Rathor 
To: Konrad Rzeszutek Wilk ,
	"Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" 
Message-ID: <20121017173005.73a03eec@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Subject: [Xen-devel] [PATCH V3 2/6]: PVH: use native irq, enable callback,
 use HVM ring ops, smp, ...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

PVH: make gdt_frames[]/gdt_ents into a union with {gdtaddr, gdtsz}, PVH
only needs to send down gdtaddr and gdtsz. irq.c: PVH uses
native_irq_ops. vcpu hotplug is currently not available for PVH.
events.c: setup callback vector for PVH. smp.c: This pertains to
bringing up smp vcpus. PVH runs in ring 0, so syscalls are native.
Also, the vcpu context is send down via the hcall to be set in the
vmcs. gdtaddr and gdtsz are unionionized as PVH only needs to send
these two to be set in the vmcs. Finally, PVH ring ops uses HVM paths
for xenbus.

Signed-off-by: Mukesh Rathor 
---
 arch/x86/include/asm/xen/interface.h |   11 +++++-
 arch/x86/xen/irq.c                   |    5 ++-
 arch/x86/xen/p2m.c                   |    2 +-
 arch/x86/xen/smp.c                   |   75
++++++++++++++++++++++------------ drivers/xen/cpu_hotplug.c
|    4 +- drivers/xen/events.c                 |    9 ++++-
 drivers/xen/xenbus/xenbus_client.c   |    3 +-
 7 files changed, 77 insertions(+), 32 deletions(-)

diff --git a/arch/x86/include/asm/xen/interface.h
b/arch/x86/include/asm/xen/interface.h index 555f94d..ac5ef76 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -143,7 +143,16 @@ struct vcpu_guest_context {
     struct cpu_user_regs user_regs;         /* User-level CPU
registers     */ struct trap_info trap_ctxt[256];        /* Virtual
IDT                  */ unsigned long ldt_base, ldt_ents;       /* LDT
(linear address, # ents) */
-    unsigned long gdt_frames[16], gdt_ents; /* GDT (machine frames, #
ents) */
+    union {
+	struct {
+		/* PV: GDT (machine frames, # ents).*/
+		unsigned long gdt_frames[16], gdt_ents;
+	} pv;
+	struct {
+		/* PVH: GDTR addr and size */
+	    unsigned long gdtaddr, gdtsz;
+	} pvh;
+    } u;
     unsigned long kernel_ss, kernel_sp;     /* Virtual TSS (only
SS1/SP1)   */ /* NB. User pagetable on x86/64 is placed in ctrlreg[1].
*/ unsigned long ctrlreg[8];               /* CR0-CR7 (control
registers)  */ diff --git a/arch/x86/xen/irq.c b/arch/x86/xen/irq.c
index 1573376..31959a7 100644
--- a/arch/x86/xen/irq.c
+++ b/arch/x86/xen/irq.c
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -128,6 +129,8 @@ static const struct pv_irq_ops xen_irq_ops
__initconst = { 
 void __init xen_init_irq_ops(void)
 {
-	pv_irq_ops = xen_irq_ops;
+	/* For PVH we use default pv_irq_ops settings */
+	if (!xen_feature(XENFEAT_hvm_callback_vector))
+		pv_irq_ops = xen_irq_ops;
 	x86_init.irqs.intr_init = xen_init_IRQ;
 }
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 95fb2aa..ea553c8 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -798,7 +798,7 @@ bool __set_phys_to_machine(unsigned long pfn,
unsigned long mfn) {
 	unsigned topidx, mididx, idx;
 
-	if (unlikely(xen_feature(XENFEAT_auto_translated_physmap))) {
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
 		BUG_ON(pfn != mfn && mfn != INVALID_P2M_ENTRY);
 		return true;
 	}
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index f58dca7..cda1907 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -68,9 +68,11 @@ static void __cpuinit cpu_bringup(void)
 	touch_softlockup_watchdog();
 	preempt_disable();
 
-	xen_enable_sysenter();
-	xen_enable_syscall();
-
+	/* PVH runs in ring 0 and allows us to do native syscalls.
Yay! */
+	if (!xen_feature(XENFEAT_supervisor_mode_kernel)) {
+		xen_enable_sysenter();
+		xen_enable_syscall();
+	}
 	cpu = smp_processor_id();
 	smp_store_cpu_info(cpu);
 	cpu_data(cpu).x86_max_cores = 1;
@@ -230,10 +232,11 @@ static void __init xen_smp_prepare_boot_cpu(void)
 	BUG_ON(smp_processor_id() != 0);
 	native_smp_prepare_boot_cpu();
 
-	/* We've switched to the "real" per-cpu gdt, so make sure the
-	   old memory can be recycled */
-	make_lowmem_page_readwrite(xen_initial_gdt);
-
+	if (!xen_feature(XENFEAT_writable_page_tables)) {
+		/* We've switched to the "real" per-cpu gdt, so make
sure the
+		 * old memory can be recycled */
+		make_lowmem_page_readwrite(xen_initial_gdt);
+	}
 	xen_filter_cpu_maps();
 	xen_setup_vcpu_info_placement();
 }
@@ -300,8 +303,6 @@ cpu_initialize_context(unsigned int cpu, struct
task_struct *idle) gdt = get_cpu_gdt_table(cpu);
 
 	ctxt->flags = VGCF_IN_KERNEL;
-	ctxt->user_regs.ds = __USER_DS;
-	ctxt->user_regs.es = __USER_DS;
 	ctxt->user_regs.ss = __KERNEL_DS;
 #ifdef CONFIG_X86_32
 	ctxt->user_regs.fs = __KERNEL_PERCPU;
@@ -310,35 +311,57 @@ cpu_initialize_context(unsigned int cpu, struct
task_struct *idle) ctxt->gs_base_kernel = per_cpu_offset(cpu);
 #endif
 	ctxt->user_regs.eip = (unsigned long)cpu_bringup_and_idle;
-	ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
 
 	memset(&ctxt->fpu_ctxt, 0, sizeof(ctxt->fpu_ctxt));
 
-	xen_copy_trap_info(ctxt->trap_ctxt);
+	/* check for autoxlated to get it right for 32bit kernel */
+	if (xen_feature(XENFEAT_auto_translated_physmap) &&
+	    xen_feature(XENFEAT_supervisor_mode_kernel)) {
 
-	ctxt->ldt_ents = 0;
+		ctxt->user_regs.ds = __KERNEL_DS;
+		ctxt->user_regs.es = 0;
+		ctxt->user_regs.gs = 0;
 
-	BUG_ON((unsigned long)gdt & ~PAGE_MASK);
+		ctxt->u.pvh.gdtaddr = (unsigned long)gdt;
+		ctxt->u.pvh.gdtsz = (unsigned long)(GDT_SIZE - 1);
 
-	gdt_mfn = arbitrary_virt_to_mfn(gdt);
-	make_lowmem_page_readonly(gdt);
-	make_lowmem_page_readonly(mfn_to_virt(gdt_mfn));
+#ifdef CONFIG_X86_64
+		/* Note: PVH is not supported on x86_32. */
+		ctxt->gs_base_user = (unsigned long)
+
per_cpu(irq_stack_union.gs_base, cpu); +#endif
+	} else {
+		ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
+		ctxt->user_regs.ds = __USER_DS;
+		ctxt->user_regs.es = __USER_DS;
 
-	ctxt->gdt_frames[0] = gdt_mfn;
-	ctxt->gdt_ents      = GDT_ENTRIES;
+		xen_copy_trap_info(ctxt->trap_ctxt);
 
-	ctxt->user_regs.cs = __KERNEL_CS;
-	ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct
pt_regs);
+		ctxt->ldt_ents = 0;
 
-	ctxt->kernel_ss = __KERNEL_DS;
-	ctxt->kernel_sp = idle->thread.sp0;
+		BUG_ON((unsigned long)gdt & ~PAGE_MASK);
+
+		gdt_mfn = arbitrary_virt_to_mfn(gdt);
+		make_lowmem_page_readonly(gdt);
+		make_lowmem_page_readonly(mfn_to_virt(gdt_mfn));
+
+		ctxt->u.pv.gdt_frames[0] = gdt_mfn;
+		ctxt->u.pv.gdt_ents      = GDT_ENTRIES;
+
+		ctxt->kernel_ss = __KERNEL_DS;
+		ctxt->kernel_sp = idle->thread.sp0;
 
 #ifdef CONFIG_X86_32
-	ctxt->event_callback_cs     = __KERNEL_CS;
-	ctxt->failsafe_callback_cs  = __KERNEL_CS;
+		ctxt->event_callback_cs     = __KERNEL_CS;
+		ctxt->failsafe_callback_cs  = __KERNEL_CS;
 #endif
-	ctxt->event_callback_eip    = (unsigned
long)xen_hypervisor_callback;
-	ctxt->failsafe_callback_eip = (unsigned
long)xen_failsafe_callback;
+		ctxt->event_callback_eip    =
+					(unsigned
long)xen_hypervisor_callback;
+		ctxt->failsafe_callback_eip =
+					(unsigned
long)xen_failsafe_callback;
+	}
+	ctxt->user_regs.cs = __KERNEL_CS;
+	ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct
pt_regs); 
 	per_cpu(xen_cr3, cpu) = __pa(swapper_pg_dir);
 	ctxt->ctrlreg[3] = xen_pfn_to_cr3(virt_to_mfn(swapper_pg_dir));
diff --git a/drivers/xen/cpu_hotplug.c b/drivers/xen/cpu_hotplug.c
index 4dcfced..de6bcf9 100644
--- a/drivers/xen/cpu_hotplug.c
+++ b/drivers/xen/cpu_hotplug.c
@@ -2,6 +2,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -100,7 +101,8 @@ static int __init setup_vcpu_hotplug_event(void)
 	static struct notifier_block xsn_cpu = {
 		.notifier_call = setup_cpu_watcher };
 
-	if (!xen_pv_domain())
+	/* PVH TBD/FIXME: future work */
+	if (!xen_pv_domain() ||
xen_feature(XENFEAT_auto_translated_physmap)) return -ENODEV;
 
 	register_xenstore_notifier(&xsn_cpu);
diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index c60d162..a977612 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -1767,7 +1767,7 @@ int xen_set_callback_via(uint64_t via)
 }
 EXPORT_SYMBOL_GPL(xen_set_callback_via);
 
-#ifdef CONFIG_XEN_PVHVM
+#ifdef CONFIG_X86
 /* Vector callbacks are better than PCI interrupts to receive event
  * channel notifications because we can receive vector callbacks on any
  * vcpu and we don't need PCI support or APIC interactions. */
@@ -1826,6 +1826,13 @@ void __init xen_init_IRQ(void)
 		if (xen_initial_domain())
 			pci_xen_initial_domain();
 
+		if (xen_feature(XENFEAT_hvm_callback_vector)) {
+			xen_callback_vector();
+			return;
+		}
+
+		/* PVH: TBD/FIXME: debug and fix eio map to work with
pvh */ +
 		pirq_eoi_map = (void
*)__get_free_page(GFP_KERNEL|__GFP_ZERO); eoi_gmfn.gmfn =
virt_to_mfn(pirq_eoi_map); rc =
HYPERVISOR_physdev_op(PHYSDEVOP_pirq_eoi_gmfn_v2, &eoi_gmfn); diff
--git a/drivers/xen/xenbus/xenbus_client.c
b/drivers/xen/xenbus/xenbus_client.c index b3e146e..1bac743 100644 ---
a/drivers/xen/xenbus/xenbus_client.c +++
b/drivers/xen/xenbus/xenbus_client.c @@ -44,6 +44,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "xenbus_probe.h"
 
@@ -743,7 +744,7 @@ static const struct xenbus_ring_ops ring_ops_hvm = {
 
 void __init xenbus_ring_ops_init(void)
 {
-	if (xen_pv_domain())
+	if (xen_pv_domain()
&& !xen_feature(XENFEAT_auto_translated_physmap)) ring_ops =
&ring_ops_pv; else
 		ring_ops = &ring_ops_hvm;
-- 
1.7.2.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 00:32:06 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 00:32:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOe1J-0001aK-9E; Thu, 18 Oct 2012 00:31:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOe1H-0001a4-CE
	for Xen-devel@lists.xensource.com; Thu, 18 Oct 2012 00:31:27 +0000
Received: from [85.158.138.51:41614] by server-8.bemta-3.messagelabs.com id
	A3/E1-10525-EDD4F705; Thu, 18 Oct 2012 00:31:26 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1350520283!34772884!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODExMTU5\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21318 invoked from network); 18 Oct 2012 00:31:25 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Oct 2012 00:31:25 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9I0VMcT018350
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 18 Oct 2012 00:31:22 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9I0VLcU010713
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 18 Oct 2012 00:31:21 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9I0VKmk006896; Wed, 17 Oct 2012 19:31:21 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 17:31:20 -0700
Date: Wed, 17 Oct 2012 17:31:19 -0700
From: Mukesh Rathor 
To: Konrad Rzeszutek Wilk ,
	"Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" 
Message-ID: <20121017173119.4e12b222@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: [Xen-devel] [PATCH V3 3/6]: PVH:  mmu related changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

PVH: This patch implements mmu changes for PVH. First the set/clear mmio pte function makes a hypercall to update the p2m in xen with 1:1 mapping. PVH uses mostly native mmu ops. Two local functions are introduced to add to xen physmap for xen remap interface. xen unmap interface is introduced so the privcmd pte entries can be cleared in xen p2m table.

Signed-off-by: Mukesh Rathor 
---
 arch/x86/xen/mmu.c    |  174 ++++++++++++++++++++++++++++++++++++++++++++++---
 arch/x86/xen/mmu.h    |    2 +
 drivers/xen/privcmd.c |    5 +-
 include/xen/xen-ops.h |    5 +-
 4 files changed, 174 insertions(+), 12 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 5a16824..5ed3b3e 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -73,6 +73,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "multicalls.h"
 #include "mmu.h"
@@ -331,6 +332,20 @@ static void xen_set_pte(pte_t *ptep, pte_t pteval)
 	__xen_set_pte(ptep, pteval);
 }
 
+void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn,
+			      int nr_mfns, int add_mapping)
+{
+	struct physdev_map_iomem iomem;
+
+	iomem.first_gfn = pfn;
+	iomem.first_mfn = mfn;
+	iomem.nr_mfns = nr_mfns;
+	iomem.add_mapping = add_mapping;
+
+	if (HYPERVISOR_physdev_op(PHYSDEVOP_pvh_map_iomem, &iomem))
+		BUG();
+}
+
 static void xen_set_pte_at(struct mm_struct *mm, unsigned long addr,
 		    pte_t *ptep, pte_t pteval)
 {
@@ -1220,6 +1235,8 @@ static void __init xen_pagetable_init(void)
 #endif
 	paging_init();
 	xen_setup_shared_info();
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return;
 #ifdef CONFIG_X86_64
 	if (!xen_feature(XENFEAT_auto_translated_physmap)) {
 		unsigned long new_mfn_list;
@@ -1527,6 +1544,10 @@ static void __init xen_set_pte_init(pte_t *ptep, pte_t pte)
 static void pin_pagetable_pfn(unsigned cmd, unsigned long pfn)
 {
 	struct mmuext_op op;
+
+	if (xen_feature(XENFEAT_writable_page_tables))
+		return;
+
 	op.cmd = cmd;
 	op.arg1.mfn = pfn_to_mfn(pfn);
 	if (HYPERVISOR_mmuext_op(&op, 1, NULL, DOMID_SELF))
@@ -1724,6 +1745,10 @@ static void set_page_prot(void *addr, pgprot_t prot)
 	unsigned long pfn = __pa(addr) >> PAGE_SHIFT;
 	pte_t pte = pfn_pte(pfn, prot);
 
+	/* recall for PVH, page tables are native. */
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return;
+
 	if (HYPERVISOR_update_va_mapping((unsigned long)addr, pte, 0))
 		BUG();
 }
@@ -1801,6 +1826,9 @@ static void convert_pfn_mfn(void *v)
 	pte_t *pte = v;
 	int i;
 
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return;
+
 	/* All levels are converted the same way, so just treat them
 	   as ptes. */
 	for (i = 0; i < PTRS_PER_PTE; i++)
@@ -1820,6 +1848,7 @@ static void __init check_pt_base(unsigned long *pt_base, unsigned long *pt_end,
 		(*pt_end)--;
 	}
 }
+
 /*
  * Set up the initial kernel pagetable.
  *
@@ -1830,6 +1859,7 @@ static void __init check_pt_base(unsigned long *pt_base, unsigned long *pt_end,
  * but that's enough to get __va working.  We need to fill in the rest
  * of the physical mapping once some sort of allocator has been set
  * up.
+ * NOTE: for PVH, the page tables are native.
  */
 void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn)
 {
@@ -1907,10 +1937,13 @@ void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn)
 	 * structure to attach it to, so make sure we just set kernel
 	 * pgd.
 	 */
-	xen_mc_batch();
-	__xen_write_cr3(true, __pa(init_level4_pgt));
-	xen_mc_issue(PARAVIRT_LAZY_CPU);
-
+	if (xen_feature(XENFEAT_writable_page_tables)) {
+		native_write_cr3(__pa(init_level4_pgt));
+	} else {
+		xen_mc_batch();
+		__xen_write_cr3(true, __pa(init_level4_pgt));
+		xen_mc_issue(PARAVIRT_LAZY_CPU);
+	}
 	/* We can't that easily rip out L3 and L2, as the Xen pagetables are
 	 * set out this way: [L4], [L1], [L2], [L3], [L1], [L1] ...  for
 	 * the initial domain. For guests using the toolstack, they are in:
@@ -2177,8 +2210,20 @@ static const struct pv_mmu_ops xen_mmu_ops __initconst = {
 
 void __init xen_init_mmu_ops(void)
 {
-	x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
 	x86_init.paging.pagetable_init = xen_pagetable_init;
+
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		pv_mmu_ops.flush_tlb_others = xen_flush_tlb_others;
+#if 0
+		/* For PCI devices to map iomem. */
+		if (xen_initial_domain()) {
+			pv_mmu_ops.set_pte = native_set_pte;
+			pv_mmu_ops.set_pte_at = native_set_pte_at;
+		}
+#endif
+		return;
+	}
+	x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
 	pv_mmu_ops = xen_mmu_ops;
 
 	memset(dummy_mapping, 0xff, PAGE_SIZE);
@@ -2414,6 +2459,89 @@ void __init xen_hvm_init_mmu_ops(void)
 }
 #endif
 
+/* Map foreign gmfn, fgmfn, to local pfn, lpfn. This for the user space
+ * creating new guest on PVH dom0 and needs to map domU pages.
+ */
+static int pvh_add_to_xen_p2m(unsigned long lpfn, unsigned long fgmfn,
+			      unsigned int domid)
+{
+	int rc;
+	struct xen_add_to_physmap xatp = { .foreign_domid = domid };
+
+	xatp.gpfn = lpfn;
+	xatp.idx = fgmfn;
+	xatp.domid = DOMID_SELF;
+	xatp.space = XENMAPSPACE_gmfn_foreign;
+	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
+	if (rc)
+		pr_warn("d0: Failed to map pfn (0x%lx) to mfn (0x%lx) rc:%d\n",
+			lpfn, fgmfn, rc);
+	return rc;
+}
+
+static int pvh_rem_xen_p2m(unsigned long spfn, int count)
+{
+	struct xen_remove_from_physmap xrp;
+	int i, rc;
+
+	for (i = 0; i < count; i++) {
+		xrp.domid = DOMID_SELF;
+		xrp.gpfn = spfn+i;
+		rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, &xrp);
+		if (rc) {
+			pr_warn("Failed to unmap pfn:%lx rc:%d done:%d\n",
+				spfn+i, rc, i);
+			return 1;
+		}
+	}
+	return 0;
+}
+
+struct pvh_remap_data {
+	unsigned long fgmfn;		/* foreign domain's gmfn */
+	pgprot_t prot;
+	domid_t  domid;
+	int	 index;
+	struct page **pages;
+};
+
+static int pvh_map_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr,
+			void *data)
+{
+	int rc;
+	struct pvh_remap_data *remap = data;
+	unsigned long pfn = page_to_pfn(remap->pages[remap->index++]);
+	pte_t pteval = pte_mkspecial(pfn_pte(pfn, remap->prot));
+
+	rc = pvh_add_to_xen_p2m(pfn, remap->fgmfn, remap->domid);
+	if (rc)
+		return rc;
+	native_set_pte(ptep, pteval);
+
+	return 0;
+}
+
+static int pvh_remap_gmfn_range(struct vm_area_struct *vma,
+				unsigned long addr, unsigned long mfn, int nr,
+				pgprot_t prot, unsigned domid,
+				struct page **pages)
+{
+	int err;
+	struct pvh_remap_data pvhdata;
+
+	BUG_ON(!pages);
+
+	pvhdata.fgmfn = mfn;
+	pvhdata.prot = prot;
+	pvhdata.domid = domid;
+	pvhdata.index = 0;
+	pvhdata.pages = pages;
+	err = apply_to_page_range(vma->vm_mm, addr, nr << PAGE_SHIFT,
+				  pvh_map_pte_fn, &pvhdata);
+	flush_tlb_all();
+	return err;
+}
+
 #define REMAP_BATCH_SIZE 16
 
 struct remap_data {
@@ -2438,7 +2566,9 @@ static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token,
 int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 			       unsigned long addr,
 			       unsigned long mfn, int nr,
-			       pgprot_t prot, unsigned domid)
+			       pgprot_t prot, unsigned domid,
+			       struct page **pages)
+
 {
 	struct remap_data rmd;
 	struct mmu_update mmu_update[REMAP_BATCH_SIZE];
@@ -2446,14 +2576,17 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 	unsigned long range;
 	int err = 0;
 
-	if (xen_feature(XENFEAT_auto_translated_physmap))
-		return -EINVAL;
-
 	prot = __pgprot(pgprot_val(prot) | _PAGE_IOMAP);
 
 	BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_RESERVED | VM_IO)) ==
 				(VM_PFNMAP | VM_RESERVED | VM_IO)));
 
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		/* We need to update the local page tables and the xen HAP */
+		return pvh_remap_gmfn_range(vma, addr, mfn, nr, prot, domid,
+					    pages);
+	}
+
 	rmd.mfn = mfn;
 	rmd.prot = prot;
 
@@ -2483,3 +2616,26 @@ out:
 	return err;
 }
 EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
+
+/* Returns: 0 success */
+int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
+			       int numpgs, struct page **pages)
+{
+	if (!pages || !xen_feature(XENFEAT_auto_translated_physmap))
+		return 0;
+
+	while (numpgs--) {
+
+		/* the mmu has already cleaned up the process mmu resources at
+		 * this point (lookup_address will return NULL). */
+		unsigned long pfn = page_to_pfn(pages[numpgs]);
+
+		pvh_rem_xen_p2m(pfn, 1);
+	}
+	/* We don't need to flush tlbs because as part of pvh_rem_xen_p2m(),
+	 * the hypervisor will do tlb flushes after removing the p2m entries
+	 * from the EPT/NPT */
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range);
diff --git a/arch/x86/xen/mmu.h b/arch/x86/xen/mmu.h
index 73809bb..6d0bb56 100644
--- a/arch/x86/xen/mmu.h
+++ b/arch/x86/xen/mmu.h
@@ -23,4 +23,6 @@ unsigned long xen_read_cr2_direct(void);
 
 extern void xen_init_mmu_ops(void);
 extern void xen_hvm_init_mmu_ops(void);
+extern void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn,
+				     int nr_mfns, int add_mapping);
 #endif	/* _XEN_MMU_H */
diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index ef63895..63d9ee8 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -178,7 +178,7 @@ static int mmap_mfn_range(void *data, void *state)
 					msg->va & PAGE_MASK,
 					msg->mfn, msg->npages,
 					vma->vm_page_prot,
-					st->domain);
+					st->domain, NULL);
 	if (rc < 0)
 		return rc;
 
@@ -267,7 +267,8 @@ static int mmap_batch_fn(void *data, void *state)
 	int ret;
 
 	ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
-					 st->vma->vm_page_prot, st->domain);
+					 st->vma->vm_page_prot, st->domain,
+					 NULL);
 
 	/* Store error code for second pass. */
 	*(st->err++) = ret;
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 6a198e4..990b43e 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -27,6 +27,9 @@ struct vm_area_struct;
 int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 			       unsigned long addr,
 			       unsigned long mfn, int nr,
-			       pgprot_t prot, unsigned domid);
+			       pgprot_t prot, unsigned domid,
+			       struct page **pages);
+int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
+			       int numpgs, struct page **pages);
 
 #endif /* INCLUDE_XEN_OPS_H */
-- 
1.7.2.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 00:32:06 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 00:32:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOe1J-0001aK-9E; Thu, 18 Oct 2012 00:31:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOe1H-0001a4-CE
	for Xen-devel@lists.xensource.com; Thu, 18 Oct 2012 00:31:27 +0000
Received: from [85.158.138.51:41614] by server-8.bemta-3.messagelabs.com id
	A3/E1-10525-EDD4F705; Thu, 18 Oct 2012 00:31:26 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1350520283!34772884!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODExMTU5\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21318 invoked from network); 18 Oct 2012 00:31:25 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Oct 2012 00:31:25 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9I0VMcT018350
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 18 Oct 2012 00:31:22 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9I0VLcU010713
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 18 Oct 2012 00:31:21 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9I0VKmk006896; Wed, 17 Oct 2012 19:31:21 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 17:31:20 -0700
Date: Wed, 17 Oct 2012 17:31:19 -0700
From: Mukesh Rathor 
To: Konrad Rzeszutek Wilk ,
	"Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" 
Message-ID: <20121017173119.4e12b222@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: [Xen-devel] [PATCH V3 3/6]: PVH:  mmu related changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

PVH: This patch implements mmu changes for PVH. First the set/clear mmio pte function makes a hypercall to update the p2m in xen with 1:1 mapping. PVH uses mostly native mmu ops. Two local functions are introduced to add to xen physmap for xen remap interface. xen unmap interface is introduced so the privcmd pte entries can be cleared in xen p2m table.

Signed-off-by: Mukesh Rathor 
---
 arch/x86/xen/mmu.c    |  174 ++++++++++++++++++++++++++++++++++++++++++++++---
 arch/x86/xen/mmu.h    |    2 +
 drivers/xen/privcmd.c |    5 +-
 include/xen/xen-ops.h |    5 +-
 4 files changed, 174 insertions(+), 12 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 5a16824..5ed3b3e 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -73,6 +73,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "multicalls.h"
 #include "mmu.h"
@@ -331,6 +332,20 @@ static void xen_set_pte(pte_t *ptep, pte_t pteval)
 	__xen_set_pte(ptep, pteval);
 }
 
+void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn,
+			      int nr_mfns, int add_mapping)
+{
+	struct physdev_map_iomem iomem;
+
+	iomem.first_gfn = pfn;
+	iomem.first_mfn = mfn;
+	iomem.nr_mfns = nr_mfns;
+	iomem.add_mapping = add_mapping;
+
+	if (HYPERVISOR_physdev_op(PHYSDEVOP_pvh_map_iomem, &iomem))
+		BUG();
+}
+
 static void xen_set_pte_at(struct mm_struct *mm, unsigned long addr,
 		    pte_t *ptep, pte_t pteval)
 {
@@ -1220,6 +1235,8 @@ static void __init xen_pagetable_init(void)
 #endif
 	paging_init();
 	xen_setup_shared_info();
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return;
 #ifdef CONFIG_X86_64
 	if (!xen_feature(XENFEAT_auto_translated_physmap)) {
 		unsigned long new_mfn_list;
@@ -1527,6 +1544,10 @@ static void __init xen_set_pte_init(pte_t *ptep, pte_t pte)
 static void pin_pagetable_pfn(unsigned cmd, unsigned long pfn)
 {
 	struct mmuext_op op;
+
+	if (xen_feature(XENFEAT_writable_page_tables))
+		return;
+
 	op.cmd = cmd;
 	op.arg1.mfn = pfn_to_mfn(pfn);
 	if (HYPERVISOR_mmuext_op(&op, 1, NULL, DOMID_SELF))
@@ -1724,6 +1745,10 @@ static void set_page_prot(void *addr, pgprot_t prot)
 	unsigned long pfn = __pa(addr) >> PAGE_SHIFT;
 	pte_t pte = pfn_pte(pfn, prot);
 
+	/* recall for PVH, page tables are native. */
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return;
+
 	if (HYPERVISOR_update_va_mapping((unsigned long)addr, pte, 0))
 		BUG();
 }
@@ -1801,6 +1826,9 @@ static void convert_pfn_mfn(void *v)
 	pte_t *pte = v;
 	int i;
 
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return;
+
 	/* All levels are converted the same way, so just treat them
 	   as ptes. */
 	for (i = 0; i < PTRS_PER_PTE; i++)
@@ -1820,6 +1848,7 @@ static void __init check_pt_base(unsigned long *pt_base, unsigned long *pt_end,
 		(*pt_end)--;
 	}
 }
+
 /*
  * Set up the initial kernel pagetable.
  *
@@ -1830,6 +1859,7 @@ static void __init check_pt_base(unsigned long *pt_base, unsigned long *pt_end,
  * but that's enough to get __va working.  We need to fill in the rest
  * of the physical mapping once some sort of allocator has been set
  * up.
+ * NOTE: for PVH, the page tables are native.
  */
 void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn)
 {
@@ -1907,10 +1937,13 @@ void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn)
 	 * structure to attach it to, so make sure we just set kernel
 	 * pgd.
 	 */
-	xen_mc_batch();
-	__xen_write_cr3(true, __pa(init_level4_pgt));
-	xen_mc_issue(PARAVIRT_LAZY_CPU);
-
+	if (xen_feature(XENFEAT_writable_page_tables)) {
+		native_write_cr3(__pa(init_level4_pgt));
+	} else {
+		xen_mc_batch();
+		__xen_write_cr3(true, __pa(init_level4_pgt));
+		xen_mc_issue(PARAVIRT_LAZY_CPU);
+	}
 	/* We can't that easily rip out L3 and L2, as the Xen pagetables are
 	 * set out this way: [L4], [L1], [L2], [L3], [L1], [L1] ...  for
 	 * the initial domain. For guests using the toolstack, they are in:
@@ -2177,8 +2210,20 @@ static const struct pv_mmu_ops xen_mmu_ops __initconst = {
 
 void __init xen_init_mmu_ops(void)
 {
-	x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
 	x86_init.paging.pagetable_init = xen_pagetable_init;
+
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		pv_mmu_ops.flush_tlb_others = xen_flush_tlb_others;
+#if 0
+		/* For PCI devices to map iomem. */
+		if (xen_initial_domain()) {
+			pv_mmu_ops.set_pte = native_set_pte;
+			pv_mmu_ops.set_pte_at = native_set_pte_at;
+		}
+#endif
+		return;
+	}
+	x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
 	pv_mmu_ops = xen_mmu_ops;
 
 	memset(dummy_mapping, 0xff, PAGE_SIZE);
@@ -2414,6 +2459,89 @@ void __init xen_hvm_init_mmu_ops(void)
 }
 #endif
 
+/* Map foreign gmfn, fgmfn, to local pfn, lpfn. This for the user space
+ * creating new guest on PVH dom0 and needs to map domU pages.
+ */
+static int pvh_add_to_xen_p2m(unsigned long lpfn, unsigned long fgmfn,
+			      unsigned int domid)
+{
+	int rc;
+	struct xen_add_to_physmap xatp = { .foreign_domid = domid };
+
+	xatp.gpfn = lpfn;
+	xatp.idx = fgmfn;
+	xatp.domid = DOMID_SELF;
+	xatp.space = XENMAPSPACE_gmfn_foreign;
+	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
+	if (rc)
+		pr_warn("d0: Failed to map pfn (0x%lx) to mfn (0x%lx) rc:%d\n",
+			lpfn, fgmfn, rc);
+	return rc;
+}
+
+static int pvh_rem_xen_p2m(unsigned long spfn, int count)
+{
+	struct xen_remove_from_physmap xrp;
+	int i, rc;
+
+	for (i = 0; i < count; i++) {
+		xrp.domid = DOMID_SELF;
+		xrp.gpfn = spfn+i;
+		rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, &xrp);
+		if (rc) {
+			pr_warn("Failed to unmap pfn:%lx rc:%d done:%d\n",
+				spfn+i, rc, i);
+			return 1;
+		}
+	}
+	return 0;
+}
+
+struct pvh_remap_data {
+	unsigned long fgmfn;		/* foreign domain's gmfn */
+	pgprot_t prot;
+	domid_t  domid;
+	int	 index;
+	struct page **pages;
+};
+
+static int pvh_map_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr,
+			void *data)
+{
+	int rc;
+	struct pvh_remap_data *remap = data;
+	unsigned long pfn = page_to_pfn(remap->pages[remap->index++]);
+	pte_t pteval = pte_mkspecial(pfn_pte(pfn, remap->prot));
+
+	rc = pvh_add_to_xen_p2m(pfn, remap->fgmfn, remap->domid);
+	if (rc)
+		return rc;
+	native_set_pte(ptep, pteval);
+
+	return 0;
+}
+
+static int pvh_remap_gmfn_range(struct vm_area_struct *vma,
+				unsigned long addr, unsigned long mfn, int nr,
+				pgprot_t prot, unsigned domid,
+				struct page **pages)
+{
+	int err;
+	struct pvh_remap_data pvhdata;
+
+	BUG_ON(!pages);
+
+	pvhdata.fgmfn = mfn;
+	pvhdata.prot = prot;
+	pvhdata.domid = domid;
+	pvhdata.index = 0;
+	pvhdata.pages = pages;
+	err = apply_to_page_range(vma->vm_mm, addr, nr << PAGE_SHIFT,
+				  pvh_map_pte_fn, &pvhdata);
+	flush_tlb_all();
+	return err;
+}
+
 #define REMAP_BATCH_SIZE 16
 
 struct remap_data {
@@ -2438,7 +2566,9 @@ static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token,
 int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 			       unsigned long addr,
 			       unsigned long mfn, int nr,
-			       pgprot_t prot, unsigned domid)
+			       pgprot_t prot, unsigned domid,
+			       struct page **pages)
+
 {
 	struct remap_data rmd;
 	struct mmu_update mmu_update[REMAP_BATCH_SIZE];
@@ -2446,14 +2576,17 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 	unsigned long range;
 	int err = 0;
 
-	if (xen_feature(XENFEAT_auto_translated_physmap))
-		return -EINVAL;
-
 	prot = __pgprot(pgprot_val(prot) | _PAGE_IOMAP);
 
 	BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_RESERVED | VM_IO)) ==
 				(VM_PFNMAP | VM_RESERVED | VM_IO)));
 
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		/* We need to update the local page tables and the xen HAP */
+		return pvh_remap_gmfn_range(vma, addr, mfn, nr, prot, domid,
+					    pages);
+	}
+
 	rmd.mfn = mfn;
 	rmd.prot = prot;
 
@@ -2483,3 +2616,26 @@ out:
 	return err;
 }
 EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
+
+/* Returns: 0 success */
+int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
+			       int numpgs, struct page **pages)
+{
+	if (!pages || !xen_feature(XENFEAT_auto_translated_physmap))
+		return 0;
+
+	while (numpgs--) {
+
+		/* the mmu has already cleaned up the process mmu resources at
+		 * this point (lookup_address will return NULL). */
+		unsigned long pfn = page_to_pfn(pages[numpgs]);
+
+		pvh_rem_xen_p2m(pfn, 1);
+	}
+	/* We don't need to flush tlbs because as part of pvh_rem_xen_p2m(),
+	 * the hypervisor will do tlb flushes after removing the p2m entries
+	 * from the EPT/NPT */
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range);
diff --git a/arch/x86/xen/mmu.h b/arch/x86/xen/mmu.h
index 73809bb..6d0bb56 100644
--- a/arch/x86/xen/mmu.h
+++ b/arch/x86/xen/mmu.h
@@ -23,4 +23,6 @@ unsigned long xen_read_cr2_direct(void);
 
 extern void xen_init_mmu_ops(void);
 extern void xen_hvm_init_mmu_ops(void);
+extern void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn,
+				     int nr_mfns, int add_mapping);
 #endif	/* _XEN_MMU_H */
diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index ef63895..63d9ee8 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -178,7 +178,7 @@ static int mmap_mfn_range(void *data, void *state)
 					msg->va & PAGE_MASK,
 					msg->mfn, msg->npages,
 					vma->vm_page_prot,
-					st->domain);
+					st->domain, NULL);
 	if (rc < 0)
 		return rc;
 
@@ -267,7 +267,8 @@ static int mmap_batch_fn(void *data, void *state)
 	int ret;
 
 	ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
-					 st->vma->vm_page_prot, st->domain);
+					 st->vma->vm_page_prot, st->domain,
+					 NULL);
 
 	/* Store error code for second pass. */
 	*(st->err++) = ret;
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 6a198e4..990b43e 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -27,6 +27,9 @@ struct vm_area_struct;
 int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 			       unsigned long addr,
 			       unsigned long mfn, int nr,
-			       pgprot_t prot, unsigned domid);
+			       pgprot_t prot, unsigned domid,
+			       struct page **pages);
+int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
+			       int numpgs, struct page **pages);
 
 #endif /* INCLUDE_XEN_OPS_H */
-- 
1.7.2.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 00:32:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 00:32:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOe1j-0001ck-Mq; Thu, 18 Oct 2012 00:31:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOe1i-0001cX-96
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 00:31:54 +0000
Received: from [85.158.138.51:42184] by server-13.bemta-3.messagelabs.com id
	2C/81-26794-9FD4F705; Thu, 18 Oct 2012 00:31:53 +0000
X-Env-Sender: xiantao.zhang@intel.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1350520310!33096162!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDM1MzUwNg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26005 invoked from network); 18 Oct 2012 00:31:51 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-9.tower-174.messagelabs.com with SMTP;
	18 Oct 2012 00:31:51 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 17 Oct 2012 17:31:50 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,603,1344236400"; d="scan'208";a="235303544"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by fmsmga001.fm.intel.com with ESMTP; 17 Oct 2012 17:31:49 -0700
Received: from fmsmsx102.amr.corp.intel.com (10.19.9.53) by
	FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 17 Oct 2012 17:31:49 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX102.amr.corp.intel.com (10.19.9.53) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 17 Oct 2012 17:31:49 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.186]) with mapi id
	14.01.0355.002; Thu, 18 Oct 2012 08:31:47 +0800
From: "Zhang, Xiantao" 
To: Keir Fraser , Jan Beulich , xen-devel
	
Thread-Topic: [Xen-devel] [PATCH v2 2/3] x86/HPET: allow use for broadcast
	when interrupt remapping is in effect
Thread-Index: Ac2sXt7kI3Y4TowWd0eFPhw0/ngldwAaPxjg
Date: Thu, 18 Oct 2012 00:31:46 +0000
Message-ID: 
References: <507EB6DB02000078000A1F4A@nat28.tlf.novell.com>
	
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "Zhang, Xiantao" 
Subject: Re: [Xen-devel] [PATCH v2 2/3] x86/HPET: allow use for broadcast
 when interrupt remapping is in effect
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Acked-by: Xiantao Zhang

> -----Original Message-----
> From: Keir Fraser [mailto:keir.xen@gmail.com] On Behalf Of Keir Fraser
> Sent: Wednesday, October 17, 2012 8:00 PM
> To: Jan Beulich; xen-devel
> Cc: Zhang, Xiantao
> Subject: Re: [Xen-devel] [PATCH v2 2/3] x86/HPET: allow use for broadcast
> when interrupt remapping is in effect
> 
> On 17/10/2012 12:47, "Jan Beulich"  wrote:
> 
> > This requires some additions to the VT-d side; AMD IOMMUs use the
> > "normal" MSI message format even when interrupt remapping is enabled,
> > thus making adjustments here unnecessary.
> >
> > Signed-off-by: Jan Beulich 
> 
> Acked-by: Keir Fraser 
> 
> ...for the principle, but needs an Intel ack for the details.
> 
>  -- Keir
> 
> > ---
> > v2: refresh after updating patch 1 of this series (patch 3 is
> > unchanged)
> >
> > --- a/xen/arch/x86/acpi/boot.c
> > +++ b/xen/arch/x86/acpi/boot.c
> > @@ -276,6 +276,7 @@ static int __init acpi_parse_hpet(struct }
> >
> > hpet_address = hpet_tbl->address.address;
> > + hpet_blockid = hpet_tbl->sequence;
> > printk(KERN_INFO PREFIX "HPET id: %#x base: %#lx\n",
> >       hpet_tbl->id, hpet_address);
> >
> > --- a/xen/arch/x86/hpet.c
> > +++ b/xen/arch/x86/hpet.c
> > @@ -40,7 +40,7 @@ struct hpet_event_channel
> >
> >      unsigned int idx;   /* physical channel idx */
> >      unsigned int cpu;   /* msi target */
> > -    int irq;            /* msi irq */
> > +    struct msi_desc msi;/* msi state */
> >      unsigned int flags; /* HPET_EVT_x */  } __cacheline_aligned;
> > static struct hpet_event_channel *__read_mostly hpet_events; @@ -51,6
> > +51,7 @@ static unsigned int __read_mostly num_hp
> > DEFINE_PER_CPU(struct hpet_event_channel *, cpu_bc_channel);
> >
> >  unsigned long __read_mostly hpet_address;
> > +u8 __initdata hpet_blockid;
> >
> >  /*
> >   * force_hpet_broadcast: by default legacy hpet broadcast will be
> > stopped @@ -252,6 +253,8 @@ static void hpet_msi_mask(struct irq_des
> >
> >  static void hpet_msi_write(struct hpet_event_channel *ch, struct
> > msi_msg
> > *msg)
> >  {
> > +    if ( iommu_intremap )
> > +        iommu_update_ire_from_msi(&ch->msi, msg);
> >      hpet_write32(msg->data, HPET_Tn_ROUTE(ch->idx));
> >      hpet_write32(msg->address_lo, HPET_Tn_ROUTE(ch->idx) + 4);  } @@
> > -261,6 +264,8 @@ static void hpet_msi_read(struct hpet_ev
> >      msg->data = hpet_read32(HPET_Tn_ROUTE(ch->idx));
> >      msg->address_lo = hpet_read32(HPET_Tn_ROUTE(ch->idx) + 4);
> >      msg->address_hi = 0;
> > +    if ( iommu_intremap )
> > +        iommu_read_msi_from_ire(&ch->msi, msg);
> >  }
> >
> >  static unsigned int hpet_msi_startup(struct irq_desc *desc) @@ -292,6
> > +297,7 @@ static void hpet_msi_set_affinity(struct
> >      msg.data |= MSI_DATA_VECTOR(desc->arch.vector);
> >      msg.address_lo &= ~MSI_ADDR_DEST_ID_MASK;
> >      msg.address_lo |= MSI_ADDR_DEST_ID(dest);
> > +    msg.dest32 = dest;
> >      hpet_msi_write(desc->action->dev_id, &msg);  }
> >
> > @@ -316,35 +322,48 @@ static void __hpet_setup_msi_irq(struct
> >      hpet_msi_write(desc->action->dev_id, &msg);  }
> >
> > -static int __init hpet_setup_msi_irq(unsigned int irq, struct
> > hpet_event_channel *ch)
> > +static int __init hpet_setup_msi_irq(struct hpet_event_channel *ch)
> >  {
> >      int ret;
> > -    irq_desc_t *desc = irq_to_desc(irq);
> > +    irq_desc_t *desc = irq_to_desc(ch->msi.irq);
> > +
> > +    if ( iommu_intremap )
> > +    {
> > +        ch->msi.hpet_id = hpet_blockid;
> > +        ret = iommu_setup_hpet_msi(&ch->msi);
> > +        if ( ret )
> > +            return ret;
> > +    }
> >
> >      desc->handler = &hpet_msi_type;
> > -    ret = request_irq(irq, hpet_interrupt_handler, 0, "HPET", ch);
> > +    ret = request_irq(ch->msi.irq, hpet_interrupt_handler, 0, "HPET",
> > + ch);
> >      if ( ret < 0 )
> > +    {
> > +        if ( iommu_intremap )
> > +            iommu_update_ire_from_msi(&ch->msi, NULL);
> >          return ret;
> > +    }
> >
> >      __hpet_setup_msi_irq(desc);
> >
> >      return 0;
> >  }
> >
> > -static int __init hpet_assign_irq(unsigned int idx)
> > +static int __init hpet_assign_irq(struct hpet_event_channel *ch)
> >  {
> >      int irq;
> >
> >      if ( (irq = create_irq(NUMA_NO_NODE)) < 0 )
> >          return irq;
> >
> > -    if ( hpet_setup_msi_irq(irq, hpet_events + idx) )
> > +    ch->msi.irq = irq;
> > +    if ( hpet_setup_msi_irq(ch) )
> >      {
> >          destroy_irq(irq);
> >          return -EINVAL;
> >      }
> >
> > -    return irq;
> > +    return 0;
> >  }
> >
> >  static void __init hpet_fsb_cap_lookup(void) @@ -352,14 +371,6 @@
> > static void __init hpet_fsb_cap_lookup(v
> >      u32 id;
> >      unsigned int i, num_chs;
> >
> > -    /* TODO. */
> > -    if ( iommu_intremap )
> > -    {
> > -        printk(XENLOG_INFO "HPET's MSI mode hasn't been supported when
> "
> > -            "Interrupt Remapping is enabled.\n");
> > -        return;
> > -    }
> > -
> >      id = hpet_read32(HPET_ID);
> >
> >      num_chs = ((id & HPET_ID_NUMBER) >> HPET_ID_NUMBER_SHIFT);
> @@
> > -391,8 +402,8 @@ static void __init hpet_fsb_cap_lookup(v
> >          ch->flags = 0;
> >          ch->idx = i;
> >
> > -        if ( (ch->irq = hpet_assign_irq(num_hpets_used++)) < 0 )
> > -            num_hpets_used--;
> > +        if ( hpet_assign_irq(ch) == 0 )
> > +            num_hpets_used++;
> >      }
> >
> >      printk(XENLOG_INFO "HPET: %u timers (%u will be used for
> > broadcast)\n", @@ -438,7 +449,7 @@ static struct hpet_event_channel
> > *hpet_g
> >
> >  static void set_channel_irq_affinity(const struct hpet_event_channel
> > *ch)  {
> > -    struct irq_desc *desc = irq_to_desc(ch->irq);
> > +    struct irq_desc *desc = irq_to_desc(ch->msi.irq);
> >
> >      ASSERT(!local_irq_is_enabled());
> >      spin_lock(&desc->lock);
> > @@ -530,7 +541,7 @@ void __init hpet_broadcast_init(void)
> >              hpet_events = xzalloc(struct hpet_event_channel);
> >          if ( !hpet_events || !zalloc_cpumask_var(&hpet_events->cpumask) )
> >              return;
> > -        hpet_events->irq = -1;
> > +        hpet_events->msi.irq = -1;
> >
> >          /* Start HPET legacy interrupts */
> >          cfg |= HPET_CFG_LEGACY;
> > @@ -598,8 +609,8 @@ void hpet_broadcast_resume(void)
> >
> >      for ( i = 0; i < n; i++ )
> >      {
> > -        if ( hpet_events[i].irq >= 0 )
> > -            __hpet_setup_msi_irq(irq_to_desc(hpet_events[i].irq));
> > +        if ( hpet_events[i].msi.irq >= 0 )
> > +
> > + __hpet_setup_msi_irq(irq_to_desc(hpet_events[i].msi.irq));
> >
> >          /* set HPET Tn as oneshot */
> >          cfg = hpet_read32(HPET_Tn_CFG(hpet_events[i].idx));
> > --- a/xen/drivers/passthrough/iommu.c
> > +++ b/xen/drivers/passthrough/iommu.c
> > @@ -495,6 +495,12 @@ unsigned int iommu_read_apic_from_ire(un
> >      return ops->read_apic_from_ire(apic, reg);  }
> >
> > +int __init iommu_setup_hpet_msi(struct msi_desc *msi) {
> > +    const struct iommu_ops *ops = iommu_get_ops();
> > +    return ops->setup_hpet_msi ? ops->setup_hpet_msi(msi) : 0; }
> > +
> >  void iommu_resume()
> >  {
> >      const struct iommu_ops *ops = iommu_get_ops();
> > --- a/xen/drivers/passthrough/vtd/dmar.c
> > +++ b/xen/drivers/passthrough/vtd/dmar.c
> > @@ -147,6 +147,34 @@ struct iommu * ioapic_to_iommu(unsigned
> >      return NULL;
> >  }
> >
> > +static bool_t acpi_hpet_device_match(
> > +    struct list_head *list, unsigned int hpet_id) {
> > +    struct acpi_hpet_unit *hpet;
> > +
> > +    list_for_each_entry( hpet, list, list )
> > +        if (hpet->id == hpet_id)
> > +            return 1;
> > +    return 0;
> > +}
> > +
> > +struct acpi_drhd_unit *hpet_to_drhd(unsigned int hpet_id) {
> > +    struct acpi_drhd_unit *drhd;
> > +
> > +    list_for_each_entry( drhd, &acpi_drhd_units, list )
> > +        if ( acpi_hpet_device_match(&drhd->hpet_list, hpet_id) )
> > +            return drhd;
> > +    return NULL;
> > +}
> > +
> > +struct iommu *hpet_to_iommu(unsigned int hpet_id) {
> > +    struct acpi_drhd_unit *drhd = hpet_to_drhd(hpet_id);
> > +
> > +    return drhd ? drhd->iommu : NULL; }
> > +
> >  static int __init acpi_register_atsr_unit(struct acpi_atsr_unit
> > *atsr)  {
> >      /*
> > @@ -330,6 +358,22 @@ static int __init acpi_parse_dev_scope(
> >              if ( iommu_verbose )
> >                  dprintk(VTDPREFIX, " MSI HPET: %04x:%02x:%02x.%u\n",
> >                          seg, bus, path->dev, path->fn);
> > +
> > +            if ( type == DMAR_TYPE )
> > +            {
> > +                struct acpi_drhd_unit *drhd = acpi_entry;
> > +                struct acpi_hpet_unit *acpi_hpet_unit;
> > +
> > +                acpi_hpet_unit = xmalloc(struct acpi_hpet_unit);
> > +                if ( !acpi_hpet_unit )
> > +                    return -ENOMEM;
> > +                acpi_hpet_unit->id = acpi_scope->enumeration_id;
> > +                acpi_hpet_unit->bus = bus;
> > +                acpi_hpet_unit->dev = path->dev;
> > +                acpi_hpet_unit->func = path->fn;
> > +                list_add(&acpi_hpet_unit->list, &drhd->hpet_list);
> > +            }
> > +
> >              break;
> >
> >          case ACPI_DMAR_SCOPE_TYPE_ENDPOINT:
> > @@ -407,6 +451,7 @@ acpi_parse_one_drhd(struct acpi_dmar_hea
> >      dmaru->segment = drhd->segment;
> >      dmaru->include_all = drhd->flags & ACPI_DMAR_INCLUDE_ALL;
> >      INIT_LIST_HEAD(&dmaru->ioapic_list);
> > +    INIT_LIST_HEAD(&dmaru->hpet_list);
> >      if ( iommu_verbose )
> >          dprintk(VTDPREFIX, "  dmaru->address = %"PRIx64"\n",
> >                  dmaru->address);
> > --- a/xen/drivers/passthrough/vtd/dmar.h
> > +++ b/xen/drivers/passthrough/vtd/dmar.h
> > @@ -39,6 +39,19 @@ struct acpi_ioapic_unit {
> >      }ioapic;
> >  };
> >
> > +struct acpi_hpet_unit {
> > +    struct list_head list;
> > +    unsigned int id;
> > +    union {
> > +        u16 bdf;
> > +        struct {
> > +            u16 func: 3,
> > +                dev:  5,
> > +                bus:  8;
> > +        };
> > +    };
> > +};
> > +
> >  struct dmar_scope {
> >      DECLARE_BITMAP(buses, 256);         /* buses owned by this unit */
> >      u16    *devices;                    /* devices owned by this unit */
> > @@ -53,6 +66,7 @@ struct acpi_drhd_unit {
> >      u8     include_all:1;
> >      struct iommu *iommu;
> >      struct list_head ioapic_list;
> > +    struct list_head hpet_list;
> >  };
> >
> >  struct acpi_rmrr_unit {
> > --- a/xen/drivers/passthrough/vtd/extern.h
> > +++ b/xen/drivers/passthrough/vtd/extern.h
> > @@ -54,7 +54,9 @@ int iommu_flush_iec_index(struct iommu *  void
> > clear_fault_bits(struct iommu *iommu);
> >
> >  struct iommu * ioapic_to_iommu(unsigned int apic_id);
> > +struct iommu * hpet_to_iommu(unsigned int hpet_id);
> >  struct acpi_drhd_unit * ioapic_to_drhd(unsigned int apic_id);
> > +struct acpi_drhd_unit * hpet_to_drhd(unsigned int hpet_id);
> >  struct acpi_drhd_unit * iommu_to_drhd(struct iommu *iommu);  struct
> > acpi_rhsa_unit * drhd_to_rhsa(struct acpi_drhd_unit *drhd);
> >
> > @@ -90,6 +92,8 @@ struct msi_msg;
> >  void msi_msg_read_remap_rte(struct msi_desc *, struct msi_msg *);
> > void msi_msg_write_remap_rte(struct msi_desc *, struct msi_msg *);
> >
> > +int intel_setup_hpet_msi(struct msi_desc *);
> > +
> >  int is_igd_vt_enabled_quirk(void);
> >  void platform_quirks_init(void);
> >  void vtd_ops_preamble_quirk(struct iommu* iommu);
> > --- a/xen/drivers/passthrough/vtd/intremap.c
> > +++ b/xen/drivers/passthrough/vtd/intremap.c
> > @@ -107,6 +107,19 @@ static u16 apicid_to_bdf(int apic_id)
> >      return 0;
> >  }
> >
> > +static u16 hpetid_to_bdf(unsigned int hpet_id) {
> > +    struct acpi_drhd_unit *drhd = hpet_to_drhd(hpet_id);
> > +    struct acpi_hpet_unit *acpi_hpet_unit;
> > +
> > +    list_for_each_entry ( acpi_hpet_unit, &drhd->hpet_list, list )
> > +        if ( acpi_hpet_unit->id == hpet_id )
> > +            return acpi_hpet_unit->bdf;
> > +
> > +    dprintk(XENLOG_ERR VTDPREFIX, "Didn't find the bdf for HPET
> > + %u!\n",
> > hpet_id);
> > +    return 0;
> > +}
> > +
> >  static void set_ire_sid(struct iremap_entry *ire,
> >                          unsigned int svt, unsigned int sq, unsigned
> > int sid)  { @@ -121,6 +134,16 @@ static void set_ioapic_source_id(int
> > api
> >                  apicid_to_bdf(apic_id));  }
> >
> > +static void set_hpet_source_id(unsigned int id, struct iremap_entry
> > +*ire) {
> > +    /*
> > +     * Should really use SQ_ALL_16. Some platforms are broken.
> > +     * While we figure out the right quirks for these broken platforms, use
> > +     * SQ_13_IGNORE_3 for now.
> > +     */
> > +    set_ire_sid(ire, SVT_VERIFY_SID_SQ, SQ_13_IGNORE_3,
> > +hpetid_to_bdf(id)); }
> > +
> >  int iommu_supports_eim(void)
> >  {
> >      struct acpi_drhd_unit *drhd;
> > @@ -592,7 +615,10 @@ static int msi_msg_to_remap_entry(
> >          new_ire.lo.dst = ((msg->address_lo >> MSI_ADDR_DEST_ID_SHIFT)
> >                            & 0xff) << 8;
> >
> > -    set_msi_source_id(pdev, &new_ire);
> > +    if ( pdev )
> > +        set_msi_source_id(pdev, &new_ire);
> > +    else
> > +        set_hpet_source_id(msi_desc->hpet_id, &new_ire);
> >      new_ire.hi.res_1 = 0;
> >      new_ire.lo.p = 1;    /* finally, set present bit */
> >
> > @@ -624,7 +650,9 @@ void msi_msg_read_remap_rte(
> >      struct iommu *iommu = NULL;
> >      struct ir_ctrl *ir_ctrl;
> >
> > -    if ( (drhd = acpi_find_matched_drhd_unit(pdev)) == NULL )
> > +    drhd = pdev ? acpi_find_matched_drhd_unit(pdev)
> > +                : hpet_to_drhd(msi_desc->hpet_id);
> > +    if ( !drhd )
> >          return;
> >      iommu = drhd->iommu;
> >
> > @@ -643,7 +671,9 @@ void msi_msg_write_remap_rte(
> >      struct iommu *iommu = NULL;
> >      struct ir_ctrl *ir_ctrl;
> >
> > -    if ( (drhd = acpi_find_matched_drhd_unit(pdev)) == NULL )
> > +    drhd = pdev ? acpi_find_matched_drhd_unit(pdev)
> > +                : hpet_to_drhd(msi_desc->hpet_id);
> > +    if ( !drhd )
> >          return;
> >      iommu = drhd->iommu;
> >
> > @@ -654,6 +684,32 @@ void msi_msg_write_remap_rte(
> >      msi_msg_to_remap_entry(iommu, pdev, msi_desc, msg);  }
> >
> > +int __init intel_setup_hpet_msi(struct msi_desc *msi_desc) {
> > +    struct iommu *iommu = hpet_to_iommu(msi_desc->hpet_id);
> > +    struct ir_ctrl *ir_ctrl = iommu_ir_ctrl(iommu);
> > +    unsigned long flags;
> > +    int rc = 0;
> > +
> > +    if ( !ir_ctrl || !ir_ctrl->iremap_maddr )
> > +        return 0;
> > +
> > +    spin_lock_irqsave(&ir_ctrl->iremap_lock, flags);
> > +    msi_desc->remap_index = alloc_remap_entry(iommu);
> > +    if ( msi_desc->remap_index >= IREMAP_ENTRY_NR )
> > +    {
> > +        dprintk(XENLOG_ERR VTDPREFIX,
> > +                "%s: intremap index (%d) is larger than"
> > +                " the maximum index (%d)!\n",
> > +                __func__, msi_desc->remap_index, IREMAP_ENTRY_NR - 1);
> > +        msi_desc->remap_index = -1;
> > +        rc = -ENXIO;
> > +    }
> > +    spin_unlock_irqrestore(&ir_ctrl->iremap_lock, flags);
> > +
> > +    return rc;
> > +}
> > +
> >  int enable_intremap(struct iommu *iommu, int eim)  {
> >      struct acpi_drhd_unit *drhd;
> > --- a/xen/drivers/passthrough/vtd/iommu.c
> > +++ b/xen/drivers/passthrough/vtd/iommu.c
> > @@ -2396,6 +2396,7 @@ const struct iommu_ops intel_iommu_ops =
> >      .update_ire_from_msi = msi_msg_write_remap_rte,
> >      .read_apic_from_ire = io_apic_read_remap_rte,
> >      .read_msi_from_ire = msi_msg_read_remap_rte,
> > +    .setup_hpet_msi = intel_setup_hpet_msi,
> >      .suspend = vtd_suspend,
> >      .resume = vtd_resume,
> >      .share_p2m = iommu_set_pgd,
> > --- a/xen/include/asm-x86/hpet.h
> > +++ b/xen/include/asm-x86/hpet.h
> > @@ -53,6 +53,7 @@
> >      (*(volatile u32 *)(fix_to_virt(FIX_HPET_BASE) + (x)) = (y))
> >
> >  extern unsigned long hpet_address;
> > +extern u8 hpet_blockid;
> >
> >  /*
> >   * Detect and initialise HPET hardware: return counter update frequency.
> > --- a/xen/include/asm-x86/msi.h
> > +++ b/xen/include/asm-x86/msi.h
> > @@ -97,7 +97,10 @@ struct msi_desc {
> >
> > struct list_head list;
> >
> > - void __iomem *mask_base;        /* va for the entry in mask table */
> > + union {
> > +  void __iomem *mask_base;/* va for the entry in mask table */
> > +  unsigned int hpet_id;   /* HPET (dev is NULL)             */
> > + };
> > struct pci_dev *dev;
> > int irq;
> >
> > --- a/xen/include/xen/iommu.h
> > +++ b/xen/include/xen/iommu.h
> > @@ -109,6 +109,7 @@ struct iommu_ops {
> >      void (*update_ire_from_msi)(struct msi_desc *msi_desc, struct
> > msi_msg *msg);
> >      void (*read_msi_from_ire)(struct msi_desc *msi_desc, struct
> > msi_msg *msg);
> >      unsigned int (*read_apic_from_ire)(unsigned int apic, unsigned
> > int reg);
> > +    int (*setup_hpet_msi)(struct msi_desc *);
> >      void (*suspend)(void);
> >      void (*resume)(void);
> >      void (*share_p2m)(struct domain *d); @@ -122,6 +123,7 @@ void
> > iommu_update_ire_from_apic(unsigned
> >  void iommu_update_ire_from_msi(struct msi_desc *msi_desc, struct
> > msi_msg *msg);  void iommu_read_msi_from_ire(struct msi_desc
> > *msi_desc, struct msi_msg *msg);  unsigned int
> > iommu_read_apic_from_ire(unsigned int apic, unsigned int reg);
> > +int iommu_setup_hpet_msi(struct msi_desc *);
> >
> >  void iommu_suspend(void);
> >  void iommu_resume(void);
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 00:32:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 00:32:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOe1j-0001ck-Mq; Thu, 18 Oct 2012 00:31:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOe1i-0001cX-96
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 00:31:54 +0000
Received: from [85.158.138.51:42184] by server-13.bemta-3.messagelabs.com id
	2C/81-26794-9FD4F705; Thu, 18 Oct 2012 00:31:53 +0000
X-Env-Sender: xiantao.zhang@intel.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1350520310!33096162!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDM1MzUwNg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26005 invoked from network); 18 Oct 2012 00:31:51 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-9.tower-174.messagelabs.com with SMTP;
	18 Oct 2012 00:31:51 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 17 Oct 2012 17:31:50 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,603,1344236400"; d="scan'208";a="235303544"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by fmsmga001.fm.intel.com with ESMTP; 17 Oct 2012 17:31:49 -0700
Received: from fmsmsx102.amr.corp.intel.com (10.19.9.53) by
	FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 17 Oct 2012 17:31:49 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX102.amr.corp.intel.com (10.19.9.53) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 17 Oct 2012 17:31:49 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.186]) with mapi id
	14.01.0355.002; Thu, 18 Oct 2012 08:31:47 +0800
From: "Zhang, Xiantao" 
To: Keir Fraser , Jan Beulich , xen-devel
	
Thread-Topic: [Xen-devel] [PATCH v2 2/3] x86/HPET: allow use for broadcast
	when interrupt remapping is in effect
Thread-Index: Ac2sXt7kI3Y4TowWd0eFPhw0/ngldwAaPxjg
Date: Thu, 18 Oct 2012 00:31:46 +0000
Message-ID: 
References: <507EB6DB02000078000A1F4A@nat28.tlf.novell.com>
	
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "Zhang, Xiantao" 
Subject: Re: [Xen-devel] [PATCH v2 2/3] x86/HPET: allow use for broadcast
 when interrupt remapping is in effect
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Acked-by: Xiantao Zhang

> -----Original Message-----
> From: Keir Fraser [mailto:keir.xen@gmail.com] On Behalf Of Keir Fraser
> Sent: Wednesday, October 17, 2012 8:00 PM
> To: Jan Beulich; xen-devel
> Cc: Zhang, Xiantao
> Subject: Re: [Xen-devel] [PATCH v2 2/3] x86/HPET: allow use for broadcast
> when interrupt remapping is in effect
> 
> On 17/10/2012 12:47, "Jan Beulich"  wrote:
> 
> > This requires some additions to the VT-d side; AMD IOMMUs use the
> > "normal" MSI message format even when interrupt remapping is enabled,
> > thus making adjustments here unnecessary.
> >
> > Signed-off-by: Jan Beulich 
> 
> Acked-by: Keir Fraser 
> 
> ...for the principle, but needs an Intel ack for the details.
> 
>  -- Keir
> 
> > ---
> > v2: refresh after updating patch 1 of this series (patch 3 is
> > unchanged)
> >
> > --- a/xen/arch/x86/acpi/boot.c
> > +++ b/xen/arch/x86/acpi/boot.c
> > @@ -276,6 +276,7 @@ static int __init acpi_parse_hpet(struct }
> >
> > hpet_address = hpet_tbl->address.address;
> > + hpet_blockid = hpet_tbl->sequence;
> > printk(KERN_INFO PREFIX "HPET id: %#x base: %#lx\n",
> >       hpet_tbl->id, hpet_address);
> >
> > --- a/xen/arch/x86/hpet.c
> > +++ b/xen/arch/x86/hpet.c
> > @@ -40,7 +40,7 @@ struct hpet_event_channel
> >
> >      unsigned int idx;   /* physical channel idx */
> >      unsigned int cpu;   /* msi target */
> > -    int irq;            /* msi irq */
> > +    struct msi_desc msi;/* msi state */
> >      unsigned int flags; /* HPET_EVT_x */  } __cacheline_aligned;
> > static struct hpet_event_channel *__read_mostly hpet_events; @@ -51,6
> > +51,7 @@ static unsigned int __read_mostly num_hp
> > DEFINE_PER_CPU(struct hpet_event_channel *, cpu_bc_channel);
> >
> >  unsigned long __read_mostly hpet_address;
> > +u8 __initdata hpet_blockid;
> >
> >  /*
> >   * force_hpet_broadcast: by default legacy hpet broadcast will be
> > stopped @@ -252,6 +253,8 @@ static void hpet_msi_mask(struct irq_des
> >
> >  static void hpet_msi_write(struct hpet_event_channel *ch, struct
> > msi_msg
> > *msg)
> >  {
> > +    if ( iommu_intremap )
> > +        iommu_update_ire_from_msi(&ch->msi, msg);
> >      hpet_write32(msg->data, HPET_Tn_ROUTE(ch->idx));
> >      hpet_write32(msg->address_lo, HPET_Tn_ROUTE(ch->idx) + 4);  } @@
> > -261,6 +264,8 @@ static void hpet_msi_read(struct hpet_ev
> >      msg->data = hpet_read32(HPET_Tn_ROUTE(ch->idx));
> >      msg->address_lo = hpet_read32(HPET_Tn_ROUTE(ch->idx) + 4);
> >      msg->address_hi = 0;
> > +    if ( iommu_intremap )
> > +        iommu_read_msi_from_ire(&ch->msi, msg);
> >  }
> >
> >  static unsigned int hpet_msi_startup(struct irq_desc *desc) @@ -292,6
> > +297,7 @@ static void hpet_msi_set_affinity(struct
> >      msg.data |= MSI_DATA_VECTOR(desc->arch.vector);
> >      msg.address_lo &= ~MSI_ADDR_DEST_ID_MASK;
> >      msg.address_lo |= MSI_ADDR_DEST_ID(dest);
> > +    msg.dest32 = dest;
> >      hpet_msi_write(desc->action->dev_id, &msg);  }
> >
> > @@ -316,35 +322,48 @@ static void __hpet_setup_msi_irq(struct
> >      hpet_msi_write(desc->action->dev_id, &msg);  }
> >
> > -static int __init hpet_setup_msi_irq(unsigned int irq, struct
> > hpet_event_channel *ch)
> > +static int __init hpet_setup_msi_irq(struct hpet_event_channel *ch)
> >  {
> >      int ret;
> > -    irq_desc_t *desc = irq_to_desc(irq);
> > +    irq_desc_t *desc = irq_to_desc(ch->msi.irq);
> > +
> > +    if ( iommu_intremap )
> > +    {
> > +        ch->msi.hpet_id = hpet_blockid;
> > +        ret = iommu_setup_hpet_msi(&ch->msi);
> > +        if ( ret )
> > +            return ret;
> > +    }
> >
> >      desc->handler = &hpet_msi_type;
> > -    ret = request_irq(irq, hpet_interrupt_handler, 0, "HPET", ch);
> > +    ret = request_irq(ch->msi.irq, hpet_interrupt_handler, 0, "HPET",
> > + ch);
> >      if ( ret < 0 )
> > +    {
> > +        if ( iommu_intremap )
> > +            iommu_update_ire_from_msi(&ch->msi, NULL);
> >          return ret;
> > +    }
> >
> >      __hpet_setup_msi_irq(desc);
> >
> >      return 0;
> >  }
> >
> > -static int __init hpet_assign_irq(unsigned int idx)
> > +static int __init hpet_assign_irq(struct hpet_event_channel *ch)
> >  {
> >      int irq;
> >
> >      if ( (irq = create_irq(NUMA_NO_NODE)) < 0 )
> >          return irq;
> >
> > -    if ( hpet_setup_msi_irq(irq, hpet_events + idx) )
> > +    ch->msi.irq = irq;
> > +    if ( hpet_setup_msi_irq(ch) )
> >      {
> >          destroy_irq(irq);
> >          return -EINVAL;
> >      }
> >
> > -    return irq;
> > +    return 0;
> >  }
> >
> >  static void __init hpet_fsb_cap_lookup(void) @@ -352,14 +371,6 @@
> > static void __init hpet_fsb_cap_lookup(v
> >      u32 id;
> >      unsigned int i, num_chs;
> >
> > -    /* TODO. */
> > -    if ( iommu_intremap )
> > -    {
> > -        printk(XENLOG_INFO "HPET's MSI mode hasn't been supported when
> "
> > -            "Interrupt Remapping is enabled.\n");
> > -        return;
> > -    }
> > -
> >      id = hpet_read32(HPET_ID);
> >
> >      num_chs = ((id & HPET_ID_NUMBER) >> HPET_ID_NUMBER_SHIFT);
> @@
> > -391,8 +402,8 @@ static void __init hpet_fsb_cap_lookup(v
> >          ch->flags = 0;
> >          ch->idx = i;
> >
> > -        if ( (ch->irq = hpet_assign_irq(num_hpets_used++)) < 0 )
> > -            num_hpets_used--;
> > +        if ( hpet_assign_irq(ch) == 0 )
> > +            num_hpets_used++;
> >      }
> >
> >      printk(XENLOG_INFO "HPET: %u timers (%u will be used for
> > broadcast)\n", @@ -438,7 +449,7 @@ static struct hpet_event_channel
> > *hpet_g
> >
> >  static void set_channel_irq_affinity(const struct hpet_event_channel
> > *ch)  {
> > -    struct irq_desc *desc = irq_to_desc(ch->irq);
> > +    struct irq_desc *desc = irq_to_desc(ch->msi.irq);
> >
> >      ASSERT(!local_irq_is_enabled());
> >      spin_lock(&desc->lock);
> > @@ -530,7 +541,7 @@ void __init hpet_broadcast_init(void)
> >              hpet_events = xzalloc(struct hpet_event_channel);
> >          if ( !hpet_events || !zalloc_cpumask_var(&hpet_events->cpumask) )
> >              return;
> > -        hpet_events->irq = -1;
> > +        hpet_events->msi.irq = -1;
> >
> >          /* Start HPET legacy interrupts */
> >          cfg |= HPET_CFG_LEGACY;
> > @@ -598,8 +609,8 @@ void hpet_broadcast_resume(void)
> >
> >      for ( i = 0; i < n; i++ )
> >      {
> > -        if ( hpet_events[i].irq >= 0 )
> > -            __hpet_setup_msi_irq(irq_to_desc(hpet_events[i].irq));
> > +        if ( hpet_events[i].msi.irq >= 0 )
> > +
> > + __hpet_setup_msi_irq(irq_to_desc(hpet_events[i].msi.irq));
> >
> >          /* set HPET Tn as oneshot */
> >          cfg = hpet_read32(HPET_Tn_CFG(hpet_events[i].idx));
> > --- a/xen/drivers/passthrough/iommu.c
> > +++ b/xen/drivers/passthrough/iommu.c
> > @@ -495,6 +495,12 @@ unsigned int iommu_read_apic_from_ire(un
> >      return ops->read_apic_from_ire(apic, reg);  }
> >
> > +int __init iommu_setup_hpet_msi(struct msi_desc *msi) {
> > +    const struct iommu_ops *ops = iommu_get_ops();
> > +    return ops->setup_hpet_msi ? ops->setup_hpet_msi(msi) : 0; }
> > +
> >  void iommu_resume()
> >  {
> >      const struct iommu_ops *ops = iommu_get_ops();
> > --- a/xen/drivers/passthrough/vtd/dmar.c
> > +++ b/xen/drivers/passthrough/vtd/dmar.c
> > @@ -147,6 +147,34 @@ struct iommu * ioapic_to_iommu(unsigned
> >      return NULL;
> >  }
> >
> > +static bool_t acpi_hpet_device_match(
> > +    struct list_head *list, unsigned int hpet_id) {
> > +    struct acpi_hpet_unit *hpet;
> > +
> > +    list_for_each_entry( hpet, list, list )
> > +        if (hpet->id == hpet_id)
> > +            return 1;
> > +    return 0;
> > +}
> > +
> > +struct acpi_drhd_unit *hpet_to_drhd(unsigned int hpet_id) {
> > +    struct acpi_drhd_unit *drhd;
> > +
> > +    list_for_each_entry( drhd, &acpi_drhd_units, list )
> > +        if ( acpi_hpet_device_match(&drhd->hpet_list, hpet_id) )
> > +            return drhd;
> > +    return NULL;
> > +}
> > +
> > +struct iommu *hpet_to_iommu(unsigned int hpet_id) {
> > +    struct acpi_drhd_unit *drhd = hpet_to_drhd(hpet_id);
> > +
> > +    return drhd ? drhd->iommu : NULL; }
> > +
> >  static int __init acpi_register_atsr_unit(struct acpi_atsr_unit
> > *atsr)  {
> >      /*
> > @@ -330,6 +358,22 @@ static int __init acpi_parse_dev_scope(
> >              if ( iommu_verbose )
> >                  dprintk(VTDPREFIX, " MSI HPET: %04x:%02x:%02x.%u\n",
> >                          seg, bus, path->dev, path->fn);
> > +
> > +            if ( type == DMAR_TYPE )
> > +            {
> > +                struct acpi_drhd_unit *drhd = acpi_entry;
> > +                struct acpi_hpet_unit *acpi_hpet_unit;
> > +
> > +                acpi_hpet_unit = xmalloc(struct acpi_hpet_unit);
> > +                if ( !acpi_hpet_unit )
> > +                    return -ENOMEM;
> > +                acpi_hpet_unit->id = acpi_scope->enumeration_id;
> > +                acpi_hpet_unit->bus = bus;
> > +                acpi_hpet_unit->dev = path->dev;
> > +                acpi_hpet_unit->func = path->fn;
> > +                list_add(&acpi_hpet_unit->list, &drhd->hpet_list);
> > +            }
> > +
> >              break;
> >
> >          case ACPI_DMAR_SCOPE_TYPE_ENDPOINT:
> > @@ -407,6 +451,7 @@ acpi_parse_one_drhd(struct acpi_dmar_hea
> >      dmaru->segment = drhd->segment;
> >      dmaru->include_all = drhd->flags & ACPI_DMAR_INCLUDE_ALL;
> >      INIT_LIST_HEAD(&dmaru->ioapic_list);
> > +    INIT_LIST_HEAD(&dmaru->hpet_list);
> >      if ( iommu_verbose )
> >          dprintk(VTDPREFIX, "  dmaru->address = %"PRIx64"\n",
> >                  dmaru->address);
> > --- a/xen/drivers/passthrough/vtd/dmar.h
> > +++ b/xen/drivers/passthrough/vtd/dmar.h
> > @@ -39,6 +39,19 @@ struct acpi_ioapic_unit {
> >      }ioapic;
> >  };
> >
> > +struct acpi_hpet_unit {
> > +    struct list_head list;
> > +    unsigned int id;
> > +    union {
> > +        u16 bdf;
> > +        struct {
> > +            u16 func: 3,
> > +                dev:  5,
> > +                bus:  8;
> > +        };
> > +    };
> > +};
> > +
> >  struct dmar_scope {
> >      DECLARE_BITMAP(buses, 256);         /* buses owned by this unit */
> >      u16    *devices;                    /* devices owned by this unit */
> > @@ -53,6 +66,7 @@ struct acpi_drhd_unit {
> >      u8     include_all:1;
> >      struct iommu *iommu;
> >      struct list_head ioapic_list;
> > +    struct list_head hpet_list;
> >  };
> >
> >  struct acpi_rmrr_unit {
> > --- a/xen/drivers/passthrough/vtd/extern.h
> > +++ b/xen/drivers/passthrough/vtd/extern.h
> > @@ -54,7 +54,9 @@ int iommu_flush_iec_index(struct iommu *  void
> > clear_fault_bits(struct iommu *iommu);
> >
> >  struct iommu * ioapic_to_iommu(unsigned int apic_id);
> > +struct iommu * hpet_to_iommu(unsigned int hpet_id);
> >  struct acpi_drhd_unit * ioapic_to_drhd(unsigned int apic_id);
> > +struct acpi_drhd_unit * hpet_to_drhd(unsigned int hpet_id);
> >  struct acpi_drhd_unit * iommu_to_drhd(struct iommu *iommu);  struct
> > acpi_rhsa_unit * drhd_to_rhsa(struct acpi_drhd_unit *drhd);
> >
> > @@ -90,6 +92,8 @@ struct msi_msg;
> >  void msi_msg_read_remap_rte(struct msi_desc *, struct msi_msg *);
> > void msi_msg_write_remap_rte(struct msi_desc *, struct msi_msg *);
> >
> > +int intel_setup_hpet_msi(struct msi_desc *);
> > +
> >  int is_igd_vt_enabled_quirk(void);
> >  void platform_quirks_init(void);
> >  void vtd_ops_preamble_quirk(struct iommu* iommu);
> > --- a/xen/drivers/passthrough/vtd/intremap.c
> > +++ b/xen/drivers/passthrough/vtd/intremap.c
> > @@ -107,6 +107,19 @@ static u16 apicid_to_bdf(int apic_id)
> >      return 0;
> >  }
> >
> > +static u16 hpetid_to_bdf(unsigned int hpet_id) {
> > +    struct acpi_drhd_unit *drhd = hpet_to_drhd(hpet_id);
> > +    struct acpi_hpet_unit *acpi_hpet_unit;
> > +
> > +    list_for_each_entry ( acpi_hpet_unit, &drhd->hpet_list, list )
> > +        if ( acpi_hpet_unit->id == hpet_id )
> > +            return acpi_hpet_unit->bdf;
> > +
> > +    dprintk(XENLOG_ERR VTDPREFIX, "Didn't find the bdf for HPET
> > + %u!\n",
> > hpet_id);
> > +    return 0;
> > +}
> > +
> >  static void set_ire_sid(struct iremap_entry *ire,
> >                          unsigned int svt, unsigned int sq, unsigned
> > int sid)  { @@ -121,6 +134,16 @@ static void set_ioapic_source_id(int
> > api
> >                  apicid_to_bdf(apic_id));  }
> >
> > +static void set_hpet_source_id(unsigned int id, struct iremap_entry
> > +*ire) {
> > +    /*
> > +     * Should really use SQ_ALL_16. Some platforms are broken.
> > +     * While we figure out the right quirks for these broken platforms, use
> > +     * SQ_13_IGNORE_3 for now.
> > +     */
> > +    set_ire_sid(ire, SVT_VERIFY_SID_SQ, SQ_13_IGNORE_3,
> > +hpetid_to_bdf(id)); }
> > +
> >  int iommu_supports_eim(void)
> >  {
> >      struct acpi_drhd_unit *drhd;
> > @@ -592,7 +615,10 @@ static int msi_msg_to_remap_entry(
> >          new_ire.lo.dst = ((msg->address_lo >> MSI_ADDR_DEST_ID_SHIFT)
> >                            & 0xff) << 8;
> >
> > -    set_msi_source_id(pdev, &new_ire);
> > +    if ( pdev )
> > +        set_msi_source_id(pdev, &new_ire);
> > +    else
> > +        set_hpet_source_id(msi_desc->hpet_id, &new_ire);
> >      new_ire.hi.res_1 = 0;
> >      new_ire.lo.p = 1;    /* finally, set present bit */
> >
> > @@ -624,7 +650,9 @@ void msi_msg_read_remap_rte(
> >      struct iommu *iommu = NULL;
> >      struct ir_ctrl *ir_ctrl;
> >
> > -    if ( (drhd = acpi_find_matched_drhd_unit(pdev)) == NULL )
> > +    drhd = pdev ? acpi_find_matched_drhd_unit(pdev)
> > +                : hpet_to_drhd(msi_desc->hpet_id);
> > +    if ( !drhd )
> >          return;
> >      iommu = drhd->iommu;
> >
> > @@ -643,7 +671,9 @@ void msi_msg_write_remap_rte(
> >      struct iommu *iommu = NULL;
> >      struct ir_ctrl *ir_ctrl;
> >
> > -    if ( (drhd = acpi_find_matched_drhd_unit(pdev)) == NULL )
> > +    drhd = pdev ? acpi_find_matched_drhd_unit(pdev)
> > +                : hpet_to_drhd(msi_desc->hpet_id);
> > +    if ( !drhd )
> >          return;
> >      iommu = drhd->iommu;
> >
> > @@ -654,6 +684,32 @@ void msi_msg_write_remap_rte(
> >      msi_msg_to_remap_entry(iommu, pdev, msi_desc, msg);  }
> >
> > +int __init intel_setup_hpet_msi(struct msi_desc *msi_desc) {
> > +    struct iommu *iommu = hpet_to_iommu(msi_desc->hpet_id);
> > +    struct ir_ctrl *ir_ctrl = iommu_ir_ctrl(iommu);
> > +    unsigned long flags;
> > +    int rc = 0;
> > +
> > +    if ( !ir_ctrl || !ir_ctrl->iremap_maddr )
> > +        return 0;
> > +
> > +    spin_lock_irqsave(&ir_ctrl->iremap_lock, flags);
> > +    msi_desc->remap_index = alloc_remap_entry(iommu);
> > +    if ( msi_desc->remap_index >= IREMAP_ENTRY_NR )
> > +    {
> > +        dprintk(XENLOG_ERR VTDPREFIX,
> > +                "%s: intremap index (%d) is larger than"
> > +                " the maximum index (%d)!\n",
> > +                __func__, msi_desc->remap_index, IREMAP_ENTRY_NR - 1);
> > +        msi_desc->remap_index = -1;
> > +        rc = -ENXIO;
> > +    }
> > +    spin_unlock_irqrestore(&ir_ctrl->iremap_lock, flags);
> > +
> > +    return rc;
> > +}
> > +
> >  int enable_intremap(struct iommu *iommu, int eim)  {
> >      struct acpi_drhd_unit *drhd;
> > --- a/xen/drivers/passthrough/vtd/iommu.c
> > +++ b/xen/drivers/passthrough/vtd/iommu.c
> > @@ -2396,6 +2396,7 @@ const struct iommu_ops intel_iommu_ops =
> >      .update_ire_from_msi = msi_msg_write_remap_rte,
> >      .read_apic_from_ire = io_apic_read_remap_rte,
> >      .read_msi_from_ire = msi_msg_read_remap_rte,
> > +    .setup_hpet_msi = intel_setup_hpet_msi,
> >      .suspend = vtd_suspend,
> >      .resume = vtd_resume,
> >      .share_p2m = iommu_set_pgd,
> > --- a/xen/include/asm-x86/hpet.h
> > +++ b/xen/include/asm-x86/hpet.h
> > @@ -53,6 +53,7 @@
> >      (*(volatile u32 *)(fix_to_virt(FIX_HPET_BASE) + (x)) = (y))
> >
> >  extern unsigned long hpet_address;
> > +extern u8 hpet_blockid;
> >
> >  /*
> >   * Detect and initialise HPET hardware: return counter update frequency.
> > --- a/xen/include/asm-x86/msi.h
> > +++ b/xen/include/asm-x86/msi.h
> > @@ -97,7 +97,10 @@ struct msi_desc {
> >
> > struct list_head list;
> >
> > - void __iomem *mask_base;        /* va for the entry in mask table */
> > + union {
> > +  void __iomem *mask_base;/* va for the entry in mask table */
> > +  unsigned int hpet_id;   /* HPET (dev is NULL)             */
> > + };
> > struct pci_dev *dev;
> > int irq;
> >
> > --- a/xen/include/xen/iommu.h
> > +++ b/xen/include/xen/iommu.h
> > @@ -109,6 +109,7 @@ struct iommu_ops {
> >      void (*update_ire_from_msi)(struct msi_desc *msi_desc, struct
> > msi_msg *msg);
> >      void (*read_msi_from_ire)(struct msi_desc *msi_desc, struct
> > msi_msg *msg);
> >      unsigned int (*read_apic_from_ire)(unsigned int apic, unsigned
> > int reg);
> > +    int (*setup_hpet_msi)(struct msi_desc *);
> >      void (*suspend)(void);
> >      void (*resume)(void);
> >      void (*share_p2m)(struct domain *d); @@ -122,6 +123,7 @@ void
> > iommu_update_ire_from_apic(unsigned
> >  void iommu_update_ire_from_msi(struct msi_desc *msi_desc, struct
> > msi_msg *msg);  void iommu_read_msi_from_ire(struct msi_desc
> > *msi_desc, struct msi_msg *msg);  unsigned int
> > iommu_read_apic_from_ire(unsigned int apic, unsigned int reg);
> > +int iommu_setup_hpet_msi(struct msi_desc *);
> >
> >  void iommu_suspend(void);
> >  void iommu_resume(void);
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 00:33:06 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 00:33:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOe2K-0001ij-BZ; Thu, 18 Oct 2012 00:32:32 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOe2I-0001i6-2V
	for Xen-devel@lists.xensource.com; Thu, 18 Oct 2012 00:32:30 +0000
Received: from [193.109.254.147:29243] by server-2.bemta-14.messagelabs.com id
	B3/DA-19917-D1E4F705; Thu, 18 Oct 2012 00:32:29 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1350520347!13661192!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODExMTU5\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21613 invoked from network); 18 Oct 2012 00:32:28 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Oct 2012 00:32:28 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9I0WPbo019042
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 18 Oct 2012 00:32:26 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9I0WP2P007658
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 18 Oct 2012 00:32:25 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9I0WO8J027201; Wed, 17 Oct 2012 19:32:24 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 17:32:24 -0700
Date: Wed, 17 Oct 2012 17:32:23 -0700
From: Mukesh Rathor 
To: Konrad Rzeszutek Wilk ,
	"Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" 
Message-ID: <20121017173223.7ea1901d@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: [Xen-devel] [PATCH V3 4/6]: PVH:bootup and setup related changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

PVH: bootup and setup related changes. enlighten.c: for PVH we can trap cpuid via vmexit, so don't need to use emulated prefix call. Check for vector callback early on, as it is a required feature. PVH runs at default kernel iopl. setup.c: in xen_add_extra_mem() we can skip updating p2m as it's managed by xen. PVH maps the entire IO space, but only RAM pages need to be repopulated. Finally, pure PV settings are moved to a separate function that is only called for pure pv, ie, pv with pvmmu.

Signed-off-by: Mukesh Rathor 
---
 arch/x86/xen/enlighten.c |   77 ++++++++++++++++++++++++++++++++++-----------
 arch/x86/xen/setup.c     |   64 +++++++++++++++++++++++++++++++-------
 2 files changed, 110 insertions(+), 31 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 2d932c3..18f5514 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -44,6 +44,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -106,6 +107,9 @@ RESERVE_BRK(shared_info_page_brk, PAGE_SIZE);
 __read_mostly int xen_have_vector_callback;
 EXPORT_SYMBOL_GPL(xen_have_vector_callback);
 
+#define xen_pvh_domain() (xen_pv_domain() && \
+			  xen_feature(XENFEAT_auto_translated_physmap) && \
+			  xen_have_vector_callback)
 /*
  * Point at some empty memory to start with. We map the real shared_info
  * page as soon as fixmap is up and running.
@@ -218,8 +222,9 @@ static void __init xen_banner(void)
 	struct xen_extraversion extra;
 	HYPERVISOR_xen_version(XENVER_extraversion, &extra);
 
-	printk(KERN_INFO "Booting paravirtualized kernel on %s\n",
-	       pv_info.name);
+	pr_info("Booting paravirtualized kernel %son %s\n",
+		xen_feature(XENFEAT_auto_translated_physmap) ?
+			"with PVH extensions " : "", pv_info.name);
 	printk(KERN_INFO "Xen version: %d.%d%s%s\n",
 	       version >> 16, version & 0xffff, extra.extraversion,
 	       xen_feature(XENFEAT_mmu_pt_update_preserve_ad) ? " (preserve-AD)" : "");
@@ -272,12 +277,15 @@ static void xen_cpuid(unsigned int *ax, unsigned int *bx,
 		break;
 	}
 
-	asm(XEN_EMULATE_PREFIX "cpuid"
-		: "=a" (*ax),
-		  "=b" (*bx),
-		  "=c" (*cx),
-		  "=d" (*dx)
-		: "0" (*ax), "2" (*cx));
+	if (xen_pvh_domain())
+		native_cpuid(ax, bx, cx, dx);
+	else
+		asm(XEN_EMULATE_PREFIX "cpuid"
+			: "=a" (*ax),
+			"=b" (*bx),
+			"=c" (*cx),
+			"=d" (*dx)
+			: "0" (*ax), "2" (*cx));
 
 	*bx &= maskebx;
 	*cx &= maskecx;
@@ -1045,6 +1053,10 @@ void xen_setup_shared_info(void)
 		HYPERVISOR_shared_info =
 			(struct shared_info *)__va(xen_start_info->shared_info);
 
+	/* PVH TBD/FIXME: vcpu info placement in phase 2 */
+	if (xen_pvh_domain())
+		return;
+
 #ifndef CONFIG_SMP
 	/* In UP this is as good a place as any to set up shared info */
 	xen_setup_vcpu_info_placement();
@@ -1275,6 +1287,11 @@ static const struct machine_ops xen_machine_ops __initconst = {
  */
 static void __init xen_setup_stackprotector(void)
 {
+	/* PVH TBD/FIXME: investigate setup_stack_canary_segment */
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		switch_to_new_gdt(0);
+		return;
+	}
 	pv_cpu_ops.write_gdt_entry = xen_write_gdt_entry_boot;
 	pv_cpu_ops.load_gdt = xen_load_gdt_boot;
 
@@ -1285,6 +1302,19 @@ static void __init xen_setup_stackprotector(void)
 	pv_cpu_ops.load_gdt = xen_load_gdt;
 }
 
+static void __init xen_pvh_early_guest_init(void)
+{
+	if (xen_feature(XENFEAT_hvm_callback_vector))
+		xen_have_vector_callback = 1;
+
+#ifdef CONFIG_X86_32
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		xen_raw_printk("ERROR: 32bit PVH guests are not supported\n");
+		BUG();
+	}
+#endif
+}
+
 /* First C function to be called on Xen boot */
 asmlinkage void __init xen_start_kernel(void)
 {
@@ -1296,13 +1326,18 @@ asmlinkage void __init xen_start_kernel(void)
 
 	xen_domain_type = XEN_PV_DOMAIN;
 
+	xen_setup_features();
+	xen_pvh_early_guest_init();
 	xen_setup_machphys_mapping();
 
 	/* Install Xen paravirt ops */
 	pv_info = xen_info;
 	pv_init_ops = xen_init_ops;
-	pv_cpu_ops = xen_cpu_ops;
 	pv_apic_ops = xen_apic_ops;
+	if (xen_pvh_domain())
+		pv_cpu_ops.cpuid = xen_cpuid;
+	else
+		pv_cpu_ops = xen_cpu_ops;
 
 	x86_init.resources.memory_setup = xen_memory_setup;
 	x86_init.oem.arch_setup = xen_arch_setup;
@@ -1334,8 +1369,6 @@ asmlinkage void __init xen_start_kernel(void)
 	/* Work out if we support NX */
 	x86_configure_nx();
 
-	xen_setup_features();
-
 	/* Get mfn list */
 	if (!xen_feature(XENFEAT_auto_translated_physmap))
 		xen_build_dynamic_phys_to_machine();
@@ -1406,14 +1439,18 @@ asmlinkage void __init xen_start_kernel(void)
 	/* set the limit of our address space */
 	xen_reserve_top();
 
-	/* We used to do this in xen_arch_setup, but that is too late on AMD
-	 * were early_cpu_init (run before ->arch_setup()) calls early_amd_init
-	 * which pokes 0xcf8 port.
-	 */
-	set_iopl.iopl = 1;
-	rc = HYPERVISOR_physdev_op(PHYSDEVOP_set_iopl, &set_iopl);
-	if (rc != 0)
-		xen_raw_printk("physdev_op failed %d\n", rc);
+	/* PVH: runs at default kernel iopl of 0 */
+	if (!xen_pvh_domain()) {
+		/*
+		 * We used to do this in xen_arch_setup, but that is too late
+		 * on AMD were early_cpu_init (run before ->arch_setup()) calls
+		 * early_amd_init which pokes 0xcf8 port.
+		 */
+		set_iopl.iopl = 1;
+		rc = HYPERVISOR_physdev_op(PHYSDEVOP_set_iopl, &set_iopl);
+		if (rc != 0)
+			xen_raw_printk("physdev_op failed %d\n", rc);
+	}
 
 #ifdef CONFIG_X86_32
 	/* set up basic CPUID stuff */
@@ -1480,6 +1517,8 @@ asmlinkage void __init xen_start_kernel(void)
 #endif
 }
 
+/* Use a pfn in RAM, may move to MMIO before kexec.
+ * This function also called for PVH dom0 */
 void __ref xen_hvm_init_shared_info(void)
 {
 	int cpu;
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 8971a26..8cce47b 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include "mmu.h"
 #include "xen-ops.h"
 #include "vdso.h"
 
@@ -78,6 +79,9 @@ static void __init xen_add_extra_mem(u64 start, u64 size)
 
 	memblock_reserve(start, size);
 
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return;
+
 	xen_max_p2m_pfn = PFN_DOWN(start + size);
 	for (pfn = PFN_DOWN(start); pfn < xen_max_p2m_pfn; pfn++) {
 		unsigned long mfn = pfn_to_mfn(pfn);
@@ -100,6 +104,7 @@ static unsigned long __init xen_do_chunk(unsigned long start,
 		.domid        = DOMID_SELF
 	};
 	unsigned long len = 0;
+	int xlated_phys = xen_feature(XENFEAT_auto_translated_physmap);
 	unsigned long pfn;
 	int ret;
 
@@ -113,7 +118,7 @@ static unsigned long __init xen_do_chunk(unsigned long start,
 				continue;
 			frame = mfn;
 		} else {
-			if (mfn != INVALID_P2M_ENTRY)
+			if (!xlated_phys && mfn != INVALID_P2M_ENTRY)
 				continue;
 			frame = pfn;
 		}
@@ -230,6 +235,27 @@ static void __init xen_set_identity_and_release_chunk(
 	*identity += set_phys_range_identity(start_pfn, end_pfn);
 }
 
+/* For PVH, the pfns [0..MAX] are mapped to mfn's in the EPT/NPT. The mfns
+ * are released as part of this 1:1 mapping hypercall back to the dom heap.
+ * Also, we map the entire IO space, ie, beyond max_pfn_mapped.
+ */
+static void __init xen_pvh_identity_map_chunk(unsigned long start_pfn,
+		unsigned long end_pfn, unsigned long *released,
+		unsigned long *identity, unsigned long max_pfn)
+{
+	unsigned long pfn;
+	int numpfns = 1, add_mapping = 1;
+
+	for (pfn = start_pfn; pfn < end_pfn; pfn++)
+		xen_set_clr_mmio_pvh_pte(pfn, pfn, numpfns, add_mapping);
+
+	if (start_pfn <= max_pfn) {
+		unsigned long end = min(max_pfn_mapped, end_pfn);
+		*released += end - start_pfn;
+	}
+	*identity += end_pfn - start_pfn;
+}
+
 static unsigned long __init xen_set_identity_and_release(
 	const struct e820entry *list, size_t map_size, unsigned long nr_pages)
 {
@@ -238,6 +264,7 @@ static unsigned long __init xen_set_identity_and_release(
 	unsigned long identity = 0;
 	const struct e820entry *entry;
 	int i;
+	int xlated_phys = xen_feature(XENFEAT_auto_translated_physmap);
 
 	/*
 	 * Combine non-RAM regions and gaps until a RAM region (or the
@@ -259,11 +286,17 @@ static unsigned long __init xen_set_identity_and_release(
 			if (entry->type == E820_RAM)
 				end_pfn = PFN_UP(entry->addr);
 
-			if (start_pfn < end_pfn)
-				xen_set_identity_and_release_chunk(
-					start_pfn, end_pfn, nr_pages,
-					&released, &identity);
-
+			if (start_pfn < end_pfn) {
+				if (xlated_phys) {
+					xen_pvh_identity_map_chunk(start_pfn,
+						end_pfn, &released, &identity,
+						nr_pages);
+				} else {
+					xen_set_identity_and_release_chunk(
+						start_pfn, end_pfn, nr_pages,
+						&released, &identity);
+				}
+			}
 			start = end;
 		}
 	}
@@ -526,16 +559,14 @@ void __cpuinit xen_enable_syscall(void)
 #endif /* CONFIG_X86_64 */
 }
 
-void __init xen_arch_setup(void)
+/* Non auto translated PV domain, ie, it's not PVH. */
+static __init void xen_pvmmu_arch_setup(void)
 {
-	xen_panic_handler_init();
-
 	HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_4gb_segments);
 	HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_writable_pagetables);
 
-	if (!xen_feature(XENFEAT_auto_translated_physmap))
-		HYPERVISOR_vm_assist(VMASST_CMD_enable,
-				     VMASST_TYPE_pae_extended_cr3);
+	HYPERVISOR_vm_assist(VMASST_CMD_enable,
+			     VMASST_TYPE_pae_extended_cr3);
 
 	if (register_callback(CALLBACKTYPE_event, xen_hypervisor_callback) ||
 	    register_callback(CALLBACKTYPE_failsafe, xen_failsafe_callback))
@@ -543,6 +574,15 @@ void __init xen_arch_setup(void)
 
 	xen_enable_sysenter();
 	xen_enable_syscall();
+}
+
+/* This function not called for HVM domain */
+void __init xen_arch_setup(void)
+{
+	xen_panic_handler_init();
+
+	if (!xen_feature(XENFEAT_auto_translated_physmap))
+		xen_pvmmu_arch_setup();
 
 #ifdef CONFIG_ACPI
 	if (!(xen_start_info->flags & SIF_INITDOMAIN)) {
-- 
1.7.2.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 00:33:06 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 00:33:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOe2K-0001ij-BZ; Thu, 18 Oct 2012 00:32:32 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOe2I-0001i6-2V
	for Xen-devel@lists.xensource.com; Thu, 18 Oct 2012 00:32:30 +0000
Received: from [193.109.254.147:29243] by server-2.bemta-14.messagelabs.com id
	B3/DA-19917-D1E4F705; Thu, 18 Oct 2012 00:32:29 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1350520347!13661192!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODExMTU5\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21613 invoked from network); 18 Oct 2012 00:32:28 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Oct 2012 00:32:28 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9I0WPbo019042
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 18 Oct 2012 00:32:26 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9I0WP2P007658
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 18 Oct 2012 00:32:25 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9I0WO8J027201; Wed, 17 Oct 2012 19:32:24 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 17:32:24 -0700
Date: Wed, 17 Oct 2012 17:32:23 -0700
From: Mukesh Rathor 
To: Konrad Rzeszutek Wilk ,
	"Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" 
Message-ID: <20121017173223.7ea1901d@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: [Xen-devel] [PATCH V3 4/6]: PVH:bootup and setup related changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

PVH: bootup and setup related changes. enlighten.c: for PVH we can trap cpuid via vmexit, so don't need to use emulated prefix call. Check for vector callback early on, as it is a required feature. PVH runs at default kernel iopl. setup.c: in xen_add_extra_mem() we can skip updating p2m as it's managed by xen. PVH maps the entire IO space, but only RAM pages need to be repopulated. Finally, pure PV settings are moved to a separate function that is only called for pure pv, ie, pv with pvmmu.

Signed-off-by: Mukesh Rathor 
---
 arch/x86/xen/enlighten.c |   77 ++++++++++++++++++++++++++++++++++-----------
 arch/x86/xen/setup.c     |   64 +++++++++++++++++++++++++++++++-------
 2 files changed, 110 insertions(+), 31 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 2d932c3..18f5514 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -44,6 +44,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -106,6 +107,9 @@ RESERVE_BRK(shared_info_page_brk, PAGE_SIZE);
 __read_mostly int xen_have_vector_callback;
 EXPORT_SYMBOL_GPL(xen_have_vector_callback);
 
+#define xen_pvh_domain() (xen_pv_domain() && \
+			  xen_feature(XENFEAT_auto_translated_physmap) && \
+			  xen_have_vector_callback)
 /*
  * Point at some empty memory to start with. We map the real shared_info
  * page as soon as fixmap is up and running.
@@ -218,8 +222,9 @@ static void __init xen_banner(void)
 	struct xen_extraversion extra;
 	HYPERVISOR_xen_version(XENVER_extraversion, &extra);
 
-	printk(KERN_INFO "Booting paravirtualized kernel on %s\n",
-	       pv_info.name);
+	pr_info("Booting paravirtualized kernel %son %s\n",
+		xen_feature(XENFEAT_auto_translated_physmap) ?
+			"with PVH extensions " : "", pv_info.name);
 	printk(KERN_INFO "Xen version: %d.%d%s%s\n",
 	       version >> 16, version & 0xffff, extra.extraversion,
 	       xen_feature(XENFEAT_mmu_pt_update_preserve_ad) ? " (preserve-AD)" : "");
@@ -272,12 +277,15 @@ static void xen_cpuid(unsigned int *ax, unsigned int *bx,
 		break;
 	}
 
-	asm(XEN_EMULATE_PREFIX "cpuid"
-		: "=a" (*ax),
-		  "=b" (*bx),
-		  "=c" (*cx),
-		  "=d" (*dx)
-		: "0" (*ax), "2" (*cx));
+	if (xen_pvh_domain())
+		native_cpuid(ax, bx, cx, dx);
+	else
+		asm(XEN_EMULATE_PREFIX "cpuid"
+			: "=a" (*ax),
+			"=b" (*bx),
+			"=c" (*cx),
+			"=d" (*dx)
+			: "0" (*ax), "2" (*cx));
 
 	*bx &= maskebx;
 	*cx &= maskecx;
@@ -1045,6 +1053,10 @@ void xen_setup_shared_info(void)
 		HYPERVISOR_shared_info =
 			(struct shared_info *)__va(xen_start_info->shared_info);
 
+	/* PVH TBD/FIXME: vcpu info placement in phase 2 */
+	if (xen_pvh_domain())
+		return;
+
 #ifndef CONFIG_SMP
 	/* In UP this is as good a place as any to set up shared info */
 	xen_setup_vcpu_info_placement();
@@ -1275,6 +1287,11 @@ static const struct machine_ops xen_machine_ops __initconst = {
  */
 static void __init xen_setup_stackprotector(void)
 {
+	/* PVH TBD/FIXME: investigate setup_stack_canary_segment */
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		switch_to_new_gdt(0);
+		return;
+	}
 	pv_cpu_ops.write_gdt_entry = xen_write_gdt_entry_boot;
 	pv_cpu_ops.load_gdt = xen_load_gdt_boot;
 
@@ -1285,6 +1302,19 @@ static void __init xen_setup_stackprotector(void)
 	pv_cpu_ops.load_gdt = xen_load_gdt;
 }
 
+static void __init xen_pvh_early_guest_init(void)
+{
+	if (xen_feature(XENFEAT_hvm_callback_vector))
+		xen_have_vector_callback = 1;
+
+#ifdef CONFIG_X86_32
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		xen_raw_printk("ERROR: 32bit PVH guests are not supported\n");
+		BUG();
+	}
+#endif
+}
+
 /* First C function to be called on Xen boot */
 asmlinkage void __init xen_start_kernel(void)
 {
@@ -1296,13 +1326,18 @@ asmlinkage void __init xen_start_kernel(void)
 
 	xen_domain_type = XEN_PV_DOMAIN;
 
+	xen_setup_features();
+	xen_pvh_early_guest_init();
 	xen_setup_machphys_mapping();
 
 	/* Install Xen paravirt ops */
 	pv_info = xen_info;
 	pv_init_ops = xen_init_ops;
-	pv_cpu_ops = xen_cpu_ops;
 	pv_apic_ops = xen_apic_ops;
+	if (xen_pvh_domain())
+		pv_cpu_ops.cpuid = xen_cpuid;
+	else
+		pv_cpu_ops = xen_cpu_ops;
 
 	x86_init.resources.memory_setup = xen_memory_setup;
 	x86_init.oem.arch_setup = xen_arch_setup;
@@ -1334,8 +1369,6 @@ asmlinkage void __init xen_start_kernel(void)
 	/* Work out if we support NX */
 	x86_configure_nx();
 
-	xen_setup_features();
-
 	/* Get mfn list */
 	if (!xen_feature(XENFEAT_auto_translated_physmap))
 		xen_build_dynamic_phys_to_machine();
@@ -1406,14 +1439,18 @@ asmlinkage void __init xen_start_kernel(void)
 	/* set the limit of our address space */
 	xen_reserve_top();
 
-	/* We used to do this in xen_arch_setup, but that is too late on AMD
-	 * were early_cpu_init (run before ->arch_setup()) calls early_amd_init
-	 * which pokes 0xcf8 port.
-	 */
-	set_iopl.iopl = 1;
-	rc = HYPERVISOR_physdev_op(PHYSDEVOP_set_iopl, &set_iopl);
-	if (rc != 0)
-		xen_raw_printk("physdev_op failed %d\n", rc);
+	/* PVH: runs at default kernel iopl of 0 */
+	if (!xen_pvh_domain()) {
+		/*
+		 * We used to do this in xen_arch_setup, but that is too late
+		 * on AMD were early_cpu_init (run before ->arch_setup()) calls
+		 * early_amd_init which pokes 0xcf8 port.
+		 */
+		set_iopl.iopl = 1;
+		rc = HYPERVISOR_physdev_op(PHYSDEVOP_set_iopl, &set_iopl);
+		if (rc != 0)
+			xen_raw_printk("physdev_op failed %d\n", rc);
+	}
 
 #ifdef CONFIG_X86_32
 	/* set up basic CPUID stuff */
@@ -1480,6 +1517,8 @@ asmlinkage void __init xen_start_kernel(void)
 #endif
 }
 
+/* Use a pfn in RAM, may move to MMIO before kexec.
+ * This function also called for PVH dom0 */
 void __ref xen_hvm_init_shared_info(void)
 {
 	int cpu;
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 8971a26..8cce47b 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include "mmu.h"
 #include "xen-ops.h"
 #include "vdso.h"
 
@@ -78,6 +79,9 @@ static void __init xen_add_extra_mem(u64 start, u64 size)
 
 	memblock_reserve(start, size);
 
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return;
+
 	xen_max_p2m_pfn = PFN_DOWN(start + size);
 	for (pfn = PFN_DOWN(start); pfn < xen_max_p2m_pfn; pfn++) {
 		unsigned long mfn = pfn_to_mfn(pfn);
@@ -100,6 +104,7 @@ static unsigned long __init xen_do_chunk(unsigned long start,
 		.domid        = DOMID_SELF
 	};
 	unsigned long len = 0;
+	int xlated_phys = xen_feature(XENFEAT_auto_translated_physmap);
 	unsigned long pfn;
 	int ret;
 
@@ -113,7 +118,7 @@ static unsigned long __init xen_do_chunk(unsigned long start,
 				continue;
 			frame = mfn;
 		} else {
-			if (mfn != INVALID_P2M_ENTRY)
+			if (!xlated_phys && mfn != INVALID_P2M_ENTRY)
 				continue;
 			frame = pfn;
 		}
@@ -230,6 +235,27 @@ static void __init xen_set_identity_and_release_chunk(
 	*identity += set_phys_range_identity(start_pfn, end_pfn);
 }
 
+/* For PVH, the pfns [0..MAX] are mapped to mfn's in the EPT/NPT. The mfns
+ * are released as part of this 1:1 mapping hypercall back to the dom heap.
+ * Also, we map the entire IO space, ie, beyond max_pfn_mapped.
+ */
+static void __init xen_pvh_identity_map_chunk(unsigned long start_pfn,
+		unsigned long end_pfn, unsigned long *released,
+		unsigned long *identity, unsigned long max_pfn)
+{
+	unsigned long pfn;
+	int numpfns = 1, add_mapping = 1;
+
+	for (pfn = start_pfn; pfn < end_pfn; pfn++)
+		xen_set_clr_mmio_pvh_pte(pfn, pfn, numpfns, add_mapping);
+
+	if (start_pfn <= max_pfn) {
+		unsigned long end = min(max_pfn_mapped, end_pfn);
+		*released += end - start_pfn;
+	}
+	*identity += end_pfn - start_pfn;
+}
+
 static unsigned long __init xen_set_identity_and_release(
 	const struct e820entry *list, size_t map_size, unsigned long nr_pages)
 {
@@ -238,6 +264,7 @@ static unsigned long __init xen_set_identity_and_release(
 	unsigned long identity = 0;
 	const struct e820entry *entry;
 	int i;
+	int xlated_phys = xen_feature(XENFEAT_auto_translated_physmap);
 
 	/*
 	 * Combine non-RAM regions and gaps until a RAM region (or the
@@ -259,11 +286,17 @@ static unsigned long __init xen_set_identity_and_release(
 			if (entry->type == E820_RAM)
 				end_pfn = PFN_UP(entry->addr);
 
-			if (start_pfn < end_pfn)
-				xen_set_identity_and_release_chunk(
-					start_pfn, end_pfn, nr_pages,
-					&released, &identity);
-
+			if (start_pfn < end_pfn) {
+				if (xlated_phys) {
+					xen_pvh_identity_map_chunk(start_pfn,
+						end_pfn, &released, &identity,
+						nr_pages);
+				} else {
+					xen_set_identity_and_release_chunk(
+						start_pfn, end_pfn, nr_pages,
+						&released, &identity);
+				}
+			}
 			start = end;
 		}
 	}
@@ -526,16 +559,14 @@ void __cpuinit xen_enable_syscall(void)
 #endif /* CONFIG_X86_64 */
 }
 
-void __init xen_arch_setup(void)
+/* Non auto translated PV domain, ie, it's not PVH. */
+static __init void xen_pvmmu_arch_setup(void)
 {
-	xen_panic_handler_init();
-
 	HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_4gb_segments);
 	HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_writable_pagetables);
 
-	if (!xen_feature(XENFEAT_auto_translated_physmap))
-		HYPERVISOR_vm_assist(VMASST_CMD_enable,
-				     VMASST_TYPE_pae_extended_cr3);
+	HYPERVISOR_vm_assist(VMASST_CMD_enable,
+			     VMASST_TYPE_pae_extended_cr3);
 
 	if (register_callback(CALLBACKTYPE_event, xen_hypervisor_callback) ||
 	    register_callback(CALLBACKTYPE_failsafe, xen_failsafe_callback))
@@ -543,6 +574,15 @@ void __init xen_arch_setup(void)
 
 	xen_enable_sysenter();
 	xen_enable_syscall();
+}
+
+/* This function not called for HVM domain */
+void __init xen_arch_setup(void)
+{
+	xen_panic_handler_init();
+
+	if (!xen_feature(XENFEAT_auto_translated_physmap))
+		xen_pvmmu_arch_setup();
 
 #ifdef CONFIG_ACPI
 	if (!(xen_start_info->flags & SIF_INITDOMAIN)) {
-- 
1.7.2.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 00:34:06 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 00:34:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOe3N-0001uD-Qe; Thu, 18 Oct 2012 00:33:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOe3M-0001u3-Bw
	for Xen-devel@lists.xensource.com; Thu, 18 Oct 2012 00:33:36 +0000
Received: from [85.158.138.51:46515] by server-12.bemta-3.messagelabs.com id
	92/44-27853-F5E4F705; Thu, 18 Oct 2012 00:33:35 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1350520413!28450376!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgxODIzOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6063 invoked from network); 18 Oct 2012 00:33:34 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Oct 2012 00:33:34 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9I0XUja014407
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 18 Oct 2012 00:33:31 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9I0XTMJ013216
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 18 Oct 2012 00:33:29 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9I0XTUl027657; Wed, 17 Oct 2012 19:33:29 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 17:33:29 -0700
Date: Wed, 17 Oct 2012 17:33:27 -0700
From: Mukesh Rathor 
To: Konrad Rzeszutek Wilk ,
	"Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" 
Message-ID: <20121017173327.6994152e@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: [Xen-devel] [PATCH V3 5/6]: PVH:balloon and grant changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

PVH: balloon and grant changes. For balloon changes we skip setting of local p2m as it's updated in xen. For grant, the shared grant frame is the pfn and not mfn, hence its mapped via the same code path as HVM

Signed-off-by: Mukesh Rathor 
---
 drivers/xen/balloon.c     |   15 +++++++++------
 drivers/xen/gntdev.c      |    3 ++-
 drivers/xen/grant-table.c |   26 ++++++++++++++++++++++----
 3 files changed, 33 insertions(+), 11 deletions(-)

diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 31ab82f..c825b63 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -361,7 +361,9 @@ static enum bp_state increase_reservation(unsigned long nr_pages)
 		set_phys_to_machine(pfn, frame_list[i]);
 
 		/* Link back into the page tables if not highmem. */
-		if (xen_pv_domain() && !PageHighMem(page)) {
+		if (xen_pv_domain() && !PageHighMem(page) &&
+		    !xen_feature(XENFEAT_auto_translated_physmap)) {
+
 			int ret;
 			ret = HYPERVISOR_update_va_mapping(
 				(unsigned long)__va(pfn << PAGE_SHIFT),
@@ -418,12 +420,13 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
 		scrub_page(page);
 
 		if (xen_pv_domain() && !PageHighMem(page)) {
-			ret = HYPERVISOR_update_va_mapping(
-				(unsigned long)__va(pfn << PAGE_SHIFT),
-				__pte_ma(0), 0);
-			BUG_ON(ret);
+			if (!xen_feature(XENFEAT_auto_translated_physmap)) {
+				ret = HYPERVISOR_update_va_mapping(
+					(unsigned long)__va(pfn << PAGE_SHIFT),
+					__pte_ma(0), 0);
+				BUG_ON(ret);
+			}
 		}
-
 	}
 
 	/* Ensure that ballooned highmem pages don't have kmaps. */
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 5df9fd8..36ec380 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -803,7 +803,8 @@ static int __init gntdev_init(void)
 	if (!xen_domain())
 		return -ENODEV;
 
-	use_ptemod = xen_pv_domain();
+	use_ptemod = xen_pv_domain() &&
+		     !xen_feature(XENFEAT_auto_translated_physmap);
 
 	err = misc_register(&gntdev_miscdev);
 	if (err != 0) {
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index f37faf6..1b851fa 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -976,14 +976,19 @@ static void gnttab_unmap_frames_v2(void)
 static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 {
 	struct gnttab_setup_table setup;
-	unsigned long *frames;
+	unsigned long *frames, start_gpfn;
 	unsigned int nr_gframes = end_idx + 1;
 	int rc;
 
-	if (xen_hvm_domain()) {
+	if (xen_hvm_domain() || xen_feature(XENFEAT_auto_translated_physmap)) {
 		struct xen_add_to_physmap xatp;
 		unsigned int i = end_idx;
 		rc = 0;
+
+		if (xen_hvm_domain())
+			start_gpfn = xen_hvm_resume_frames >> PAGE_SHIFT;
+		else
+			start_gpfn = virt_to_pfn(gnttab_shared.addr);
 		/*
 		 * Loop backwards, so that the first hypercall has the largest
 		 * index, ensuring that the table will grow only once.
@@ -992,7 +997,7 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 			xatp.domid = DOMID_SELF;
 			xatp.idx = i;
 			xatp.space = XENMAPSPACE_grant_table;
-			xatp.gpfn = (xen_hvm_resume_frames >> PAGE_SHIFT) + i;
+			xatp.gpfn = start_gpfn + i;
 			rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
 			if (rc != 0) {
 				printk(KERN_WARNING
@@ -1055,7 +1060,7 @@ static void gnttab_request_version(void)
 	int rc;
 	struct gnttab_set_version gsv;
 
-	if (xen_hvm_domain())
+	if (xen_hvm_domain() || xen_feature(XENFEAT_auto_translated_physmap))
 		gsv.version = 1;
 	else
 		gsv.version = 2;
@@ -1083,12 +1088,25 @@ static void gnttab_request_version(void)
 int gnttab_resume(void)
 {
 	unsigned int max_nr_gframes;
+	char *kmsg = "Failed to kmalloc pages for pv in hvm grant frames\n";
 
 	gnttab_request_version();
 	max_nr_gframes = gnttab_max_grant_frames();
 	if (max_nr_gframes < nr_grant_frames)
 		return -ENOSYS;
 
+	/* PVH note: xen will free existing kmalloc'd mfn in
+	 * XENMEM_add_to_physmap. TBD/FIXME: use xen ballooning instead of
+	 * kmalloc(). */
+	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap) &&
+	    !gnttab_shared.addr) {
+		gnttab_shared.addr =
+			kmalloc(max_nr_gframes * PAGE_SIZE, GFP_KERNEL);
+		if (!gnttab_shared.addr) {
+			pr_warn("%s", kmsg);
+			return -ENOMEM;
+		}
+	}
 	if (xen_pv_domain())
 		return gnttab_map(0, nr_grant_frames - 1);
 
-- 
1.7.2.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 00:34:06 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 00:34:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOe3N-0001uD-Qe; Thu, 18 Oct 2012 00:33:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOe3M-0001u3-Bw
	for Xen-devel@lists.xensource.com; Thu, 18 Oct 2012 00:33:36 +0000
Received: from [85.158.138.51:46515] by server-12.bemta-3.messagelabs.com id
	92/44-27853-F5E4F705; Thu, 18 Oct 2012 00:33:35 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1350520413!28450376!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgxODIzOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6063 invoked from network); 18 Oct 2012 00:33:34 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Oct 2012 00:33:34 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9I0XUja014407
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 18 Oct 2012 00:33:31 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9I0XTMJ013216
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 18 Oct 2012 00:33:29 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9I0XTUl027657; Wed, 17 Oct 2012 19:33:29 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 17:33:29 -0700
Date: Wed, 17 Oct 2012 17:33:27 -0700
From: Mukesh Rathor 
To: Konrad Rzeszutek Wilk ,
	"Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" 
Message-ID: <20121017173327.6994152e@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: [Xen-devel] [PATCH V3 5/6]: PVH:balloon and grant changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

PVH: balloon and grant changes. For balloon changes we skip setting of local p2m as it's updated in xen. For grant, the shared grant frame is the pfn and not mfn, hence its mapped via the same code path as HVM

Signed-off-by: Mukesh Rathor 
---
 drivers/xen/balloon.c     |   15 +++++++++------
 drivers/xen/gntdev.c      |    3 ++-
 drivers/xen/grant-table.c |   26 ++++++++++++++++++++++----
 3 files changed, 33 insertions(+), 11 deletions(-)

diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 31ab82f..c825b63 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -361,7 +361,9 @@ static enum bp_state increase_reservation(unsigned long nr_pages)
 		set_phys_to_machine(pfn, frame_list[i]);
 
 		/* Link back into the page tables if not highmem. */
-		if (xen_pv_domain() && !PageHighMem(page)) {
+		if (xen_pv_domain() && !PageHighMem(page) &&
+		    !xen_feature(XENFEAT_auto_translated_physmap)) {
+
 			int ret;
 			ret = HYPERVISOR_update_va_mapping(
 				(unsigned long)__va(pfn << PAGE_SHIFT),
@@ -418,12 +420,13 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
 		scrub_page(page);
 
 		if (xen_pv_domain() && !PageHighMem(page)) {
-			ret = HYPERVISOR_update_va_mapping(
-				(unsigned long)__va(pfn << PAGE_SHIFT),
-				__pte_ma(0), 0);
-			BUG_ON(ret);
+			if (!xen_feature(XENFEAT_auto_translated_physmap)) {
+				ret = HYPERVISOR_update_va_mapping(
+					(unsigned long)__va(pfn << PAGE_SHIFT),
+					__pte_ma(0), 0);
+				BUG_ON(ret);
+			}
 		}
-
 	}
 
 	/* Ensure that ballooned highmem pages don't have kmaps. */
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 5df9fd8..36ec380 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -803,7 +803,8 @@ static int __init gntdev_init(void)
 	if (!xen_domain())
 		return -ENODEV;
 
-	use_ptemod = xen_pv_domain();
+	use_ptemod = xen_pv_domain() &&
+		     !xen_feature(XENFEAT_auto_translated_physmap);
 
 	err = misc_register(&gntdev_miscdev);
 	if (err != 0) {
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index f37faf6..1b851fa 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -976,14 +976,19 @@ static void gnttab_unmap_frames_v2(void)
 static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 {
 	struct gnttab_setup_table setup;
-	unsigned long *frames;
+	unsigned long *frames, start_gpfn;
 	unsigned int nr_gframes = end_idx + 1;
 	int rc;
 
-	if (xen_hvm_domain()) {
+	if (xen_hvm_domain() || xen_feature(XENFEAT_auto_translated_physmap)) {
 		struct xen_add_to_physmap xatp;
 		unsigned int i = end_idx;
 		rc = 0;
+
+		if (xen_hvm_domain())
+			start_gpfn = xen_hvm_resume_frames >> PAGE_SHIFT;
+		else
+			start_gpfn = virt_to_pfn(gnttab_shared.addr);
 		/*
 		 * Loop backwards, so that the first hypercall has the largest
 		 * index, ensuring that the table will grow only once.
@@ -992,7 +997,7 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 			xatp.domid = DOMID_SELF;
 			xatp.idx = i;
 			xatp.space = XENMAPSPACE_grant_table;
-			xatp.gpfn = (xen_hvm_resume_frames >> PAGE_SHIFT) + i;
+			xatp.gpfn = start_gpfn + i;
 			rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
 			if (rc != 0) {
 				printk(KERN_WARNING
@@ -1055,7 +1060,7 @@ static void gnttab_request_version(void)
 	int rc;
 	struct gnttab_set_version gsv;
 
-	if (xen_hvm_domain())
+	if (xen_hvm_domain() || xen_feature(XENFEAT_auto_translated_physmap))
 		gsv.version = 1;
 	else
 		gsv.version = 2;
@@ -1083,12 +1088,25 @@ static void gnttab_request_version(void)
 int gnttab_resume(void)
 {
 	unsigned int max_nr_gframes;
+	char *kmsg = "Failed to kmalloc pages for pv in hvm grant frames\n";
 
 	gnttab_request_version();
 	max_nr_gframes = gnttab_max_grant_frames();
 	if (max_nr_gframes < nr_grant_frames)
 		return -ENOSYS;
 
+	/* PVH note: xen will free existing kmalloc'd mfn in
+	 * XENMEM_add_to_physmap. TBD/FIXME: use xen ballooning instead of
+	 * kmalloc(). */
+	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap) &&
+	    !gnttab_shared.addr) {
+		gnttab_shared.addr =
+			kmalloc(max_nr_gframes * PAGE_SIZE, GFP_KERNEL);
+		if (!gnttab_shared.addr) {
+			pr_warn("%s", kmsg);
+			return -ENOMEM;
+		}
+	}
 	if (xen_pv_domain())
 		return gnttab_map(0, nr_grant_frames - 1);
 
-- 
1.7.2.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 00:35:38 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 00:35:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOe4e-00024V-Cq; Thu, 18 Oct 2012 00:34:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOe4d-00024J-8V
	for Xen-devel@lists.xensource.com; Thu, 18 Oct 2012 00:34:55 +0000
Received: from [85.158.143.35:25233] by server-1.bemta-4.messagelabs.com id
	5C/54-19134-EAE4F705; Thu, 18 Oct 2012 00:34:54 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1350520492!15492973!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODExMTU5\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20837 invoked from network); 18 Oct 2012 00:34:53 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Oct 2012 00:34:53 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9I0YoSv020486
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 18 Oct 2012 00:34:51 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9I0Yoqr014742
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 18 Oct 2012 00:34:50 GMT
Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9I0YnZm008466; Wed, 17 Oct 2012 19:34:50 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 17:34:49 -0700
Date: Wed, 17 Oct 2012 17:34:48 -0700
From: Mukesh Rathor 
To: Konrad Rzeszutek Wilk ,
	"Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" 
Message-ID: <20121017173448.7ef4c0b1@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: [Xen-devel] [PATCH V3 6/6]: PVH:privcmd changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

PVH: privcmd changes. PVH only supports the batch interface. To map a foreign page to a process, pfn must be allocated. PVH path uses ballooning for that purpose. The returned pfn is then mapped to the foreign page. xen_unmap_domain_mfn_range() is introduced to unmap these pages via the privcmd close call.

Signed-off-by: Mukesh Rathor 
---
 drivers/xen/privcmd.c |   69 +++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 67 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 63d9ee8..835166a 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -33,11 +33,14 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "privcmd.h"
 
 MODULE_LICENSE("GPL");
 
+#define PRIV_VMA_LOCKED ((void *)1)
+
 #ifndef HAVE_ARCH_PRIVCMD_MMAP
 static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma);
 #endif
@@ -199,6 +202,10 @@ static long privcmd_ioctl_mmap(void __user *udata)
 	if (!xen_initial_domain())
 		return -EPERM;
 
+	/* We only support privcmd_ioctl_mmap_batch for auto translated. */
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return -ENOSYS;
+
 	if (copy_from_user(&mmapcmd, udata, sizeof(mmapcmd)))
 		return -EFAULT;
 
@@ -246,6 +253,7 @@ struct mmap_batch_state {
 	domid_t domain;
 	unsigned long va;
 	struct vm_area_struct *vma;
+	int index;
 	/* A tristate:
 	 *      0 for no errors
 	 *      1 if at least one error has happened (and no
@@ -260,15 +268,24 @@ struct mmap_batch_state {
 	xen_pfn_t __user *user_mfn;
 };
 
+/* auto translated dom0 note: if domU being created is PV, then mfn is
+ * mfn(addr on bus). If it's auto xlated, then mfn is pfn (input to HAP).
+ */
 static int mmap_batch_fn(void *data, void *state)
 {
 	xen_pfn_t *mfnp = data;
 	struct mmap_batch_state *st = state;
+	struct vm_area_struct *vma = st->vma;
+	struct page **pages = vma->vm_private_data;
+	struct page *cur_page = NULL;
 	int ret;
 
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		cur_page = pages[st->index++];
+
 	ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
 					 st->vma->vm_page_prot, st->domain,
-					 NULL);
+					 &cur_page);
 
 	/* Store error code for second pass. */
 	*(st->err++) = ret;
@@ -304,6 +321,32 @@ static int mmap_return_errors_v1(void *data, void *state)
 	return __put_user(*mfnp, st->user_mfn++);
 }
 
+/* Allocate pfns that are then mapped with gmfns from foreign domid. Update
+ * the vma with the page info to use later.
+ * Returns: 0 if success, otherwise -errno
+ */
+static int alloc_empty_pages(struct vm_area_struct *vma, int numpgs)
+{
+	int rc;
+	struct page **pages;
+
+	pages = kcalloc(numpgs, sizeof(pages[0]), GFP_KERNEL);
+	if (pages == NULL)
+		return -ENOMEM;
+
+	rc = alloc_xenballooned_pages(numpgs, pages, 0);
+	if (rc != 0) {
+		pr_warn("%s Could not alloc %d pfns rc:%d\n", __func__,
+			numpgs, rc);
+		kfree(pages);
+		return -ENOMEM;
+	}
+	BUG_ON(vma->vm_private_data != PRIV_VMA_LOCKED);
+	vma->vm_private_data = pages;
+
+	return 0;
+}
+
 static struct vm_operations_struct privcmd_vm_ops;
 
 static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
@@ -371,10 +414,18 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
 		up_write(&mm->mmap_sem);
 		goto out;
 	}
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		ret = alloc_empty_pages(vma, m.num);
+		if (ret < 0) {
+			up_write(&mm->mmap_sem);
+			goto out;
+		}
+	}
 
 	state.domain        = m.dom;
 	state.vma           = vma;
 	state.va            = m.addr;
+	state.index         = 0;
 	state.global_error  = 0;
 	state.err           = err_array;
 
@@ -439,6 +490,19 @@ static long privcmd_ioctl(struct file *file,
 	return ret;
 }
 
+static void privcmd_close(struct vm_area_struct *vma)
+{
+	struct page **pages = vma ? vma->vm_private_data : NULL;
+	int numpgs = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
+
+	if (!pages || !numpgs || !xen_feature(XENFEAT_auto_translated_physmap))
+		return;
+
+	xen_unmap_domain_mfn_range(vma, numpgs, pages);
+	free_xenballooned_pages(numpgs, pages);
+	kfree(pages);
+}
+
 static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
 {
 	printk(KERN_DEBUG "privcmd_fault: vma=%p %lx-%lx, pgoff=%lx, uv=%p\n",
@@ -449,6 +513,7 @@ static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
 }
 
 static struct vm_operations_struct privcmd_vm_ops = {
+	.close = privcmd_close,
 	.fault = privcmd_fault
 };
 
@@ -465,7 +530,7 @@ static int privcmd_mmap(struct file *file, struct vm_area_struct *vma)
 
 static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma)
 {
-	return (xchg(&vma->vm_private_data, (void *)1) == NULL);
+	return !cmpxchg(&vma->vm_private_data, NULL, PRIV_VMA_LOCKED);
 }
 
 const struct file_operations xen_privcmd_fops = {
-- 
1.7.2.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 00:35:38 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 00:35:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOe4e-00024V-Cq; Thu, 18 Oct 2012 00:34:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOe4d-00024J-8V
	for Xen-devel@lists.xensource.com; Thu, 18 Oct 2012 00:34:55 +0000
Received: from [85.158.143.35:25233] by server-1.bemta-4.messagelabs.com id
	5C/54-19134-EAE4F705; Thu, 18 Oct 2012 00:34:54 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1350520492!15492973!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODExMTU5\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20837 invoked from network); 18 Oct 2012 00:34:53 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Oct 2012 00:34:53 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9I0YoSv020486
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 18 Oct 2012 00:34:51 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9I0Yoqr014742
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 18 Oct 2012 00:34:50 GMT
Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9I0YnZm008466; Wed, 17 Oct 2012 19:34:50 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 17 Oct 2012 17:34:49 -0700
Date: Wed, 17 Oct 2012 17:34:48 -0700
From: Mukesh Rathor 
To: Konrad Rzeszutek Wilk ,
	"Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" 
Message-ID: <20121017173448.7ef4c0b1@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: [Xen-devel] [PATCH V3 6/6]: PVH:privcmd changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

PVH: privcmd changes. PVH only supports the batch interface. To map a foreign page to a process, pfn must be allocated. PVH path uses ballooning for that purpose. The returned pfn is then mapped to the foreign page. xen_unmap_domain_mfn_range() is introduced to unmap these pages via the privcmd close call.

Signed-off-by: Mukesh Rathor 
---
 drivers/xen/privcmd.c |   69 +++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 67 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 63d9ee8..835166a 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -33,11 +33,14 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "privcmd.h"
 
 MODULE_LICENSE("GPL");
 
+#define PRIV_VMA_LOCKED ((void *)1)
+
 #ifndef HAVE_ARCH_PRIVCMD_MMAP
 static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma);
 #endif
@@ -199,6 +202,10 @@ static long privcmd_ioctl_mmap(void __user *udata)
 	if (!xen_initial_domain())
 		return -EPERM;
 
+	/* We only support privcmd_ioctl_mmap_batch for auto translated. */
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return -ENOSYS;
+
 	if (copy_from_user(&mmapcmd, udata, sizeof(mmapcmd)))
 		return -EFAULT;
 
@@ -246,6 +253,7 @@ struct mmap_batch_state {
 	domid_t domain;
 	unsigned long va;
 	struct vm_area_struct *vma;
+	int index;
 	/* A tristate:
 	 *      0 for no errors
 	 *      1 if at least one error has happened (and no
@@ -260,15 +268,24 @@ struct mmap_batch_state {
 	xen_pfn_t __user *user_mfn;
 };
 
+/* auto translated dom0 note: if domU being created is PV, then mfn is
+ * mfn(addr on bus). If it's auto xlated, then mfn is pfn (input to HAP).
+ */
 static int mmap_batch_fn(void *data, void *state)
 {
 	xen_pfn_t *mfnp = data;
 	struct mmap_batch_state *st = state;
+	struct vm_area_struct *vma = st->vma;
+	struct page **pages = vma->vm_private_data;
+	struct page *cur_page = NULL;
 	int ret;
 
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		cur_page = pages[st->index++];
+
 	ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
 					 st->vma->vm_page_prot, st->domain,
-					 NULL);
+					 &cur_page);
 
 	/* Store error code for second pass. */
 	*(st->err++) = ret;
@@ -304,6 +321,32 @@ static int mmap_return_errors_v1(void *data, void *state)
 	return __put_user(*mfnp, st->user_mfn++);
 }
 
+/* Allocate pfns that are then mapped with gmfns from foreign domid. Update
+ * the vma with the page info to use later.
+ * Returns: 0 if success, otherwise -errno
+ */
+static int alloc_empty_pages(struct vm_area_struct *vma, int numpgs)
+{
+	int rc;
+	struct page **pages;
+
+	pages = kcalloc(numpgs, sizeof(pages[0]), GFP_KERNEL);
+	if (pages == NULL)
+		return -ENOMEM;
+
+	rc = alloc_xenballooned_pages(numpgs, pages, 0);
+	if (rc != 0) {
+		pr_warn("%s Could not alloc %d pfns rc:%d\n", __func__,
+			numpgs, rc);
+		kfree(pages);
+		return -ENOMEM;
+	}
+	BUG_ON(vma->vm_private_data != PRIV_VMA_LOCKED);
+	vma->vm_private_data = pages;
+
+	return 0;
+}
+
 static struct vm_operations_struct privcmd_vm_ops;
 
 static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
@@ -371,10 +414,18 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
 		up_write(&mm->mmap_sem);
 		goto out;
 	}
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		ret = alloc_empty_pages(vma, m.num);
+		if (ret < 0) {
+			up_write(&mm->mmap_sem);
+			goto out;
+		}
+	}
 
 	state.domain        = m.dom;
 	state.vma           = vma;
 	state.va            = m.addr;
+	state.index         = 0;
 	state.global_error  = 0;
 	state.err           = err_array;
 
@@ -439,6 +490,19 @@ static long privcmd_ioctl(struct file *file,
 	return ret;
 }
 
+static void privcmd_close(struct vm_area_struct *vma)
+{
+	struct page **pages = vma ? vma->vm_private_data : NULL;
+	int numpgs = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
+
+	if (!pages || !numpgs || !xen_feature(XENFEAT_auto_translated_physmap))
+		return;
+
+	xen_unmap_domain_mfn_range(vma, numpgs, pages);
+	free_xenballooned_pages(numpgs, pages);
+	kfree(pages);
+}
+
 static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
 {
 	printk(KERN_DEBUG "privcmd_fault: vma=%p %lx-%lx, pgoff=%lx, uv=%p\n",
@@ -449,6 +513,7 @@ static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
 }
 
 static struct vm_operations_struct privcmd_vm_ops = {
+	.close = privcmd_close,
 	.fault = privcmd_fault
 };
 
@@ -465,7 +530,7 @@ static int privcmd_mmap(struct file *file, struct vm_area_struct *vma)
 
 static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma)
 {
-	return (xchg(&vma->vm_private_data, (void *)1) == NULL);
+	return !cmpxchg(&vma->vm_private_data, NULL, PRIV_VMA_LOCKED);
 }
 
 const struct file_operations xen_privcmd_fops = {
-- 
1.7.2.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 00:49:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 00:49:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOeIZ-0002QO-2D; Thu, 18 Oct 2012 00:49:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOeIX-0002QJ-2e
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 00:49:17 +0000
Received: from [85.158.143.99:32127] by server-2.bemta-4.messagelabs.com id
	3D/7B-22268-C025F705; Thu, 18 Oct 2012 00:49:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1350521355!27018044!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23855 invoked from network); 18 Oct 2012 00:49:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 00:49:15 -0000
X-IronPort-AV: E=Sophos;i="4.80,603,1344211200"; d="scan'208";a="15242620"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 00:48:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 18 Oct 2012 01:48:46 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TOeI2-0002aY-An;
	Thu, 18 Oct 2012 00:48:46 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TOeI2-0007Zz-AP;
	Thu, 18 Oct 2012 01:48:46 +0100
To: 
Message-ID: 
From: xen.org 
Date: Thu, 18 Oct 2012 01:48:46 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14011: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14011 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14011/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 13967
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-pv            5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 13967
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 13967
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 13967
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 13967
 test-amd64-amd64-xl           5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                fail REGR. vs. 13967
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 13967
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 13967
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot          fail REGR. vs. 13967

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13967
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13967

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  5c402b905e00
baseline version:
 xen                  c1c549c4fe9e

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf 
  Huang Ying 
  Ian Campbell 
  Jan Beulich 
  Keir Fraser 
  Stefano Stabellini 
  Tim Deegan 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26073:5c402b905e00
tag:         tip
user:        Ian Campbell 
date:        Wed Oct 17 16:43:55 2012 +0100
    
    arm: parameter guest handles are 32 bit on 32 bit hypervisor
    
    Handles within structs remain 64 bit such that they are consistently
    sized on both 32 and 64 bit.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Stefano Stabellini 
    Committed-by: Ian Campbell 
    
    
changeset:   26072:5529b91bd2e4
user:        Ian Campbell 
date:        Wed Oct 17 16:43:54 2012 +0100
    
    xen: remove XEN_GUEST_HANDLE(ulong)
    
    Having both this handle (always unsigned long) and
    XEN_GUEST_HANDLE(xen_ulong_t) (unsigned long on x86 and explicit size
    of ARM) is confusing and error prone.
    
    Replace the two remaining uses of the ulong handle, in grant set and
    x86 set_gdt hypercalls, with xen_ulong_t.
    
    This correctly sizes the grant frame entry as 64 bit on ARM but
    leaves it as unsigned long on x86 (therefore no intended change on
    x86). Likewise in set_gdt there is no actual change.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Keir Fraser 
    Acked-by: Stefano Stabellini 
    Committed-by: Ian Campbell 
    
    
changeset:   26071:2a1083b1d0c2
user:        Stefano Stabellini 
date:        Wed Oct 17 16:43:53 2012 +0100
    
    xen: more XEN_GUEST_HANDLE_PARAM substitutions
    
    More substitutions in this patch, not as obvious as the ones in the
    previous patch.
    
    Signed-off-by: Stefano Stabellini 
    Signed-off-by: Ian Campbell 
    Acked-by: Keir Fraser 
    Committed-by: Ian Campbell 
    
    
changeset:   26070:9eafdcd5ff0b
user:        Stefano Stabellini 
date:        Wed Oct 17 16:43:53 2012 +0100
    
    xen: replace XEN_GUEST_HANDLE with XEN_GUEST_HANDLE_PARAM when appropriate
    
    Note: these changes don't make any difference on x86.
    
    Replace XEN_GUEST_HANDLE with XEN_GUEST_HANDLE_PARAM when it is used as
    an hypercall argument.
    
    Signed-off-by: Stefano Stabellini 
    Signed-off-by: Ian Campbell 
    Acked-by: Keir Fraser 
    Committed-by: Ian Campbell 
    
    
changeset:   26069:1eb4b2f7465f
user:        Stefano Stabellini 
date:        Wed Oct 17 16:43:51 2012 +0100
    
    xen: introduce XEN_GUEST_HANDLE_PARAM
    
    XEN_GUEST_HANDLE_PARAM is going to be used to distinguish guest pointers
    stored in memory from guest pointers as hypercall parameters.
    
    guest_handle_* macros default to XEN_GUEST_HANDLE_PARAM as return type.
    Two new guest_handle_to_param and guest_handle_from_param macros are
    introduced to do conversions.
    
    Signed-off-by: Stefano Stabellini 
    Signed-off-by: Ian Campbell 
    Acked-by: Keir Fraser 
    Committed-by: Ian Campbell 
    
    
changeset:   26068:ed6c13501195
user:        Stefano Stabellini 
date:        Wed Oct 17 16:43:50 2012 +0100
    
    xen: change the limit of nr_extents to UINT_MAX >> MEMOP_EXTENT_SHIFT
    
    Currently do_memory_op has a different maximum limit for nr_extents on
    32 bit and 64 bit.
    Change the limit to UINT_MAX >> MEMOP_EXTENT_SHIFT, so that it is the
    same in both cases.
    
    Signed-off-by: Stefano Stabellini 
    Signed-off-by: Ian Campbell 
    Acked-by: Keir Fraser 
    Committed-by: Ian Campbell 
    
    
changeset:   26067:a324eea3bbc8
user:        Stefano Stabellini 
date:        Wed Oct 17 16:43:49 2012 +0100
    
    xen: xen_ulong_t substitution
    
    There is still an unwanted unsigned long in the xen public interface:
    replace it with xen_ulong_t.
    
    Also typedef xen_ulong_t to uint64_t on ARM.
    
    Signed-off-by: Stefano Stabellini 
    Signed-off-by: Ian Campbell 
    Acked-by: Keir Fraser 
    Committed-by: Ian Campbell 
    
    
changeset:   26066:980863b9fa4b
user:        Ian Campbell 
date:        Wed Oct 17 16:43:48 2012 +0100
    
    arm: tools: add arm to foreign structs checking
    
    Signed-off-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26065:b146705d70b3
user:        Stefano Stabellini 
date:        Wed Oct 17 16:43:47 2012 +0100
    
    xen/arm: grant table
    
    Implement XENMAPSPACE_grant_table and grant_table_op.
    
    Signed-off-by: Stefano Stabellini 
    Acked-by: Tim Deegan 
    [ ijc -- fixed reject in traps.c, grant table op is a 3 argument
             hypercall, rebased over "xen: arm: implement
             XENMEM_add_to_physmap_range"
    ]
    Signed-off-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26064:bbe986018949
user:        Ian Campbell 
date:        Wed Oct 17 16:43:46 2012 +0100
    
    xen: arm: implement XENMEM_add_to_physmap_range
    
    This allows for foreign mappings as well as batching, fitting all that
    into XENMEM_add_to_physmap wasn't possible.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Keir Fraser 
    Acked-by: Stefano Stabellini 
    Committed-by: Ian Campbell 
    
    
changeset:   26063:1f4be6ee4619
user:        Jan Beulich 
date:        Wed Oct 17 14:13:20 2012 +0200
    
    x86/HPET: obtain proper lock for changing IRQ affinity
    
    The IRQ descriptor lock should be held while adjusting the affinity of
    any IRQ; the HPET channel lock isn't sufficient to protect namely
    against races with moving the IRQ to a different CPU.
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    
    
changeset:   26062:ec8a091efcce
user:        Huang Ying 
date:        Wed Oct 17 14:12:06 2012 +0200
    
    ACPI/APEI: fix ERST MOVE_DATA instruction implementation
    
    The src_base and dst_base fields in apei_exec_context are physical
    address, so they should be ioremaped before being used in ERST
    MOVE_DATA instruction.
    
    Reported-by: Javier Martinez Canillas 
    Reported-by: Andrew Morton 
    Signed-off-by: Huang Ying 
    
    Replace use of ioremap() by __acpi_map_table()/set_fixmap(). Fix error
    handling.
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    Committed-by: Jan Beulich 
    
    
changeset:   26061:4b4c0c7a6031
user:        Jan Beulich 
date:        Wed Oct 17 11:23:10 2012 +0200
    
    x86/oprof: adjust off-by-one counter range checks
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    
    
changeset:   26060:4fc87c2f31a0
user:        Huang Ying 
date:        Tue Oct 16 17:26:36 2012 +0200
    
    ACPI: fix APEI related table size checking
    
    On Huang Ying's machine:
    
    erst_tab->header_length == sizeof(struct acpi_table_einj)
    
    but Yinghai reported that on his machine,
    
    erst_tab->header_length == sizeof(struct acpi_table_einj) -
    sizeof(struct acpi_table_header)
    
    To make erst table size checking code works on all systems, both
    testing are treated as PASS.
    
    Same situation applies to einj_tab->header_length, so corresponding
    table size checking is changed in similar way too.
    
    Originally-by: Yinghai Lu 
    Signed-off-by: Huang Ying 
    
    - use switch() for better readability
    - add comment explaining why a formally invalid size it also being
      accepted
    - check erst_tab->header.length before even looking at
      erst_tab->header_length
    - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    Committed-by: Jan Beulich 
    
    
changeset:   26059:c1c549c4fe9e
user:        Daniel De Graaf 
date:        Mon Oct 15 16:51:44 2012 +0100
    
    xen: Add versions of rcu_lock_*_domain without IS_PRIV
    
    These functions will be used to avoid duplication of IS_PRIV calls
    that will be introduced in XSM hooks. This also fixes a build error
    with XSM enabled introduced by 25925:d1c3375c3f11 which depends on
    this patch.
    
    Signed-off-by: Daniel De Graaf 
    Committed-by: Keir Fraser 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 00:49:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 00:49:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOeIZ-0002QO-2D; Thu, 18 Oct 2012 00:49:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOeIX-0002QJ-2e
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 00:49:17 +0000
Received: from [85.158.143.99:32127] by server-2.bemta-4.messagelabs.com id
	3D/7B-22268-C025F705; Thu, 18 Oct 2012 00:49:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1350521355!27018044!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23855 invoked from network); 18 Oct 2012 00:49:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 00:49:15 -0000
X-IronPort-AV: E=Sophos;i="4.80,603,1344211200"; d="scan'208";a="15242620"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 00:48:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 18 Oct 2012 01:48:46 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TOeI2-0002aY-An;
	Thu, 18 Oct 2012 00:48:46 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TOeI2-0007Zz-AP;
	Thu, 18 Oct 2012 01:48:46 +0100
To: 
Message-ID: 
From: xen.org 
Date: Thu, 18 Oct 2012 01:48:46 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14011: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14011 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14011/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 13967
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-pv            5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 13967
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 13967
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 13967
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 13967
 test-amd64-amd64-xl           5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                fail REGR. vs. 13967
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 13967
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 13967
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot          fail REGR. vs. 13967

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13967
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13967

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  5c402b905e00
baseline version:
 xen                  c1c549c4fe9e

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf 
  Huang Ying 
  Ian Campbell 
  Jan Beulich 
  Keir Fraser 
  Stefano Stabellini 
  Tim Deegan 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26073:5c402b905e00
tag:         tip
user:        Ian Campbell 
date:        Wed Oct 17 16:43:55 2012 +0100
    
    arm: parameter guest handles are 32 bit on 32 bit hypervisor
    
    Handles within structs remain 64 bit such that they are consistently
    sized on both 32 and 64 bit.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Stefano Stabellini 
    Committed-by: Ian Campbell 
    
    
changeset:   26072:5529b91bd2e4
user:        Ian Campbell 
date:        Wed Oct 17 16:43:54 2012 +0100
    
    xen: remove XEN_GUEST_HANDLE(ulong)
    
    Having both this handle (always unsigned long) and
    XEN_GUEST_HANDLE(xen_ulong_t) (unsigned long on x86 and explicit size
    of ARM) is confusing and error prone.
    
    Replace the two remaining uses of the ulong handle, in grant set and
    x86 set_gdt hypercalls, with xen_ulong_t.
    
    This correctly sizes the grant frame entry as 64 bit on ARM but
    leaves it as unsigned long on x86 (therefore no intended change on
    x86). Likewise in set_gdt there is no actual change.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Keir Fraser 
    Acked-by: Stefano Stabellini 
    Committed-by: Ian Campbell 
    
    
changeset:   26071:2a1083b1d0c2
user:        Stefano Stabellini 
date:        Wed Oct 17 16:43:53 2012 +0100
    
    xen: more XEN_GUEST_HANDLE_PARAM substitutions
    
    More substitutions in this patch, not as obvious as the ones in the
    previous patch.
    
    Signed-off-by: Stefano Stabellini 
    Signed-off-by: Ian Campbell 
    Acked-by: Keir Fraser 
    Committed-by: Ian Campbell 
    
    
changeset:   26070:9eafdcd5ff0b
user:        Stefano Stabellini 
date:        Wed Oct 17 16:43:53 2012 +0100
    
    xen: replace XEN_GUEST_HANDLE with XEN_GUEST_HANDLE_PARAM when appropriate
    
    Note: these changes don't make any difference on x86.
    
    Replace XEN_GUEST_HANDLE with XEN_GUEST_HANDLE_PARAM when it is used as
    an hypercall argument.
    
    Signed-off-by: Stefano Stabellini 
    Signed-off-by: Ian Campbell 
    Acked-by: Keir Fraser 
    Committed-by: Ian Campbell 
    
    
changeset:   26069:1eb4b2f7465f
user:        Stefano Stabellini 
date:        Wed Oct 17 16:43:51 2012 +0100
    
    xen: introduce XEN_GUEST_HANDLE_PARAM
    
    XEN_GUEST_HANDLE_PARAM is going to be used to distinguish guest pointers
    stored in memory from guest pointers as hypercall parameters.
    
    guest_handle_* macros default to XEN_GUEST_HANDLE_PARAM as return type.
    Two new guest_handle_to_param and guest_handle_from_param macros are
    introduced to do conversions.
    
    Signed-off-by: Stefano Stabellini 
    Signed-off-by: Ian Campbell 
    Acked-by: Keir Fraser 
    Committed-by: Ian Campbell 
    
    
changeset:   26068:ed6c13501195
user:        Stefano Stabellini 
date:        Wed Oct 17 16:43:50 2012 +0100
    
    xen: change the limit of nr_extents to UINT_MAX >> MEMOP_EXTENT_SHIFT
    
    Currently do_memory_op has a different maximum limit for nr_extents on
    32 bit and 64 bit.
    Change the limit to UINT_MAX >> MEMOP_EXTENT_SHIFT, so that it is the
    same in both cases.
    
    Signed-off-by: Stefano Stabellini 
    Signed-off-by: Ian Campbell 
    Acked-by: Keir Fraser 
    Committed-by: Ian Campbell 
    
    
changeset:   26067:a324eea3bbc8
user:        Stefano Stabellini 
date:        Wed Oct 17 16:43:49 2012 +0100
    
    xen: xen_ulong_t substitution
    
    There is still an unwanted unsigned long in the xen public interface:
    replace it with xen_ulong_t.
    
    Also typedef xen_ulong_t to uint64_t on ARM.
    
    Signed-off-by: Stefano Stabellini 
    Signed-off-by: Ian Campbell 
    Acked-by: Keir Fraser 
    Committed-by: Ian Campbell 
    
    
changeset:   26066:980863b9fa4b
user:        Ian Campbell 
date:        Wed Oct 17 16:43:48 2012 +0100
    
    arm: tools: add arm to foreign structs checking
    
    Signed-off-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26065:b146705d70b3
user:        Stefano Stabellini 
date:        Wed Oct 17 16:43:47 2012 +0100
    
    xen/arm: grant table
    
    Implement XENMAPSPACE_grant_table and grant_table_op.
    
    Signed-off-by: Stefano Stabellini 
    Acked-by: Tim Deegan 
    [ ijc -- fixed reject in traps.c, grant table op is a 3 argument
             hypercall, rebased over "xen: arm: implement
             XENMEM_add_to_physmap_range"
    ]
    Signed-off-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26064:bbe986018949
user:        Ian Campbell 
date:        Wed Oct 17 16:43:46 2012 +0100
    
    xen: arm: implement XENMEM_add_to_physmap_range
    
    This allows for foreign mappings as well as batching, fitting all that
    into XENMEM_add_to_physmap wasn't possible.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Keir Fraser 
    Acked-by: Stefano Stabellini 
    Committed-by: Ian Campbell 
    
    
changeset:   26063:1f4be6ee4619
user:        Jan Beulich 
date:        Wed Oct 17 14:13:20 2012 +0200
    
    x86/HPET: obtain proper lock for changing IRQ affinity
    
    The IRQ descriptor lock should be held while adjusting the affinity of
    any IRQ; the HPET channel lock isn't sufficient to protect namely
    against races with moving the IRQ to a different CPU.
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    
    
changeset:   26062:ec8a091efcce
user:        Huang Ying 
date:        Wed Oct 17 14:12:06 2012 +0200
    
    ACPI/APEI: fix ERST MOVE_DATA instruction implementation
    
    The src_base and dst_base fields in apei_exec_context are physical
    address, so they should be ioremaped before being used in ERST
    MOVE_DATA instruction.
    
    Reported-by: Javier Martinez Canillas 
    Reported-by: Andrew Morton 
    Signed-off-by: Huang Ying 
    
    Replace use of ioremap() by __acpi_map_table()/set_fixmap(). Fix error
    handling.
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    Committed-by: Jan Beulich 
    
    
changeset:   26061:4b4c0c7a6031
user:        Jan Beulich 
date:        Wed Oct 17 11:23:10 2012 +0200
    
    x86/oprof: adjust off-by-one counter range checks
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    
    
changeset:   26060:4fc87c2f31a0
user:        Huang Ying 
date:        Tue Oct 16 17:26:36 2012 +0200
    
    ACPI: fix APEI related table size checking
    
    On Huang Ying's machine:
    
    erst_tab->header_length == sizeof(struct acpi_table_einj)
    
    but Yinghai reported that on his machine,
    
    erst_tab->header_length == sizeof(struct acpi_table_einj) -
    sizeof(struct acpi_table_header)
    
    To make erst table size checking code works on all systems, both
    testing are treated as PASS.
    
    Same situation applies to einj_tab->header_length, so corresponding
    table size checking is changed in similar way too.
    
    Originally-by: Yinghai Lu 
    Signed-off-by: Huang Ying 
    
    - use switch() for better readability
    - add comment explaining why a formally invalid size it also being
      accepted
    - check erst_tab->header.length before even looking at
      erst_tab->header_length
    - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    Committed-by: Jan Beulich 
    
    
changeset:   26059:c1c549c4fe9e
user:        Daniel De Graaf 
date:        Mon Oct 15 16:51:44 2012 +0100
    
    xen: Add versions of rcu_lock_*_domain without IS_PRIV
    
    These functions will be used to avoid duplication of IS_PRIV calls
    that will be introduced in XSM hooks. This also fixes a build error
    with XSM enabled introduced by 25925:d1c3375c3f11 which depends on
    this patch.
    
    Signed-off-by: Daniel De Graaf 
    Committed-by: Keir Fraser 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 01:17:13 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 01:17:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOejD-0006Zh-D5; Thu, 18 Oct 2012 01:16:51 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOejB-0006Zc-1U
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 01:16:49 +0000
Received: from [193.109.254.147:51699] by server-8.bemta-14.messagelabs.com id
	03/96-16549-0885F705; Thu, 18 Oct 2012 01:16:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1350523006!10367483!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31967 invoked from network); 18 Oct 2012 01:16:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 01:16:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,603,1344211200"; d="scan'208";a="15242697"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 01:16:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 18 Oct 2012 02:16:46 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TOej8-0002ju-DD;
	Thu, 18 Oct 2012 01:16:46 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TOej8-00070X-CG;
	Thu, 18 Oct 2012 02:16:46 +0100
To: 
Message-ID: 
From: xen.org 
Date: Thu, 18 Oct 2012 02:16:46 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete
	test-amd64-i386-xl-multivcpu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-xl-multivcpu
test xen-boot

Tree: linux git://xenbits.xen.org/linux-pvops.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 http://xenbits.xen.org/hg/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
  Bug introduced:  4fc87c2f31a0
  Bug not present: c1c549c4fe9e


  changeset:   26060:4fc87c2f31a0
  user:        Huang Ying 
  date:        Tue Oct 16 17:26:36 2012 +0200
      
      ACPI: fix APEI related table size checking
      
      On Huang Ying's machine:
      
      erst_tab->header_length == sizeof(struct acpi_table_einj)
      
      but Yinghai reported that on his machine,
      
      erst_tab->header_length == sizeof(struct acpi_table_einj) -
      sizeof(struct acpi_table_header)
      
      To make erst table size checking code works on all systems, both
      testing are treated as PASS.
      
      Same situation applies to einj_tab->header_length, so corresponding
      table size checking is changed in similar way too.
      
      Originally-by: Yinghai Lu 
      Signed-off-by: Huang Ying 
      
      - use switch() for better readability
      - add comment explaining why a formally invalid size it also being
        accepted
      - check erst_tab->header.length before even looking at
        erst_tab->header_length
      - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
      
      Signed-off-by: Jan Beulich 
      Acked-by: Keir Fraser 
      Committed-by: Jan Beulich 
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-i386-xl-multivcpu.xen-boot.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 14011 fail [host=potato-beetle] / 13979 [host=gall-mite] 13973 [host=itch-mite] 13972 [host=earwig] 13967 [host=moss-bug] 13963 [host=leaf-beetle] 13962 [host=field-cricket] 13960 ok.
Failure / basis pass flights: 14011 / 13960
Tree: linux git://xenbits.xen.org/linux-pvops.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 http://xenbits.xen.org/hg/staging/xen-unstable.hg
Latest a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 5c402b905e00
Basis pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 e0e1350dfe9b
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#a938a246d34912423c560f475ccf1ce0c71d9d00-a938a246d34912423c560f475ccf1ce0c71d9d00 git://xenbits.xen.org/staging/qemu-xen-unstable.git#bacc0d302445c75f18f4c826750fb5853b60e7ca-bacc0d302445c75f18f4c826750fb5853b60e7ca git://xenbits.xen.org/staging/qemu-upstream-unstable.git#cdf4d2bb4006805f209712fbb8ed1f83127e9984-cdf4d2bb4006805f209712fbb8ed1f83127e9984 http://xenbits.xen.org/hg/staging/xen-unstable.hg#e0e1350dfe9b-5c402b905e00
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
Loaded 252 nodes in revision graph
Searching for test results:
 13958 [host=lace-bug]
 13960 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 e0e1350dfe9b
 13967 [host=moss-bug]
 13962 [host=field-cricket]
 13972 [host=earwig]
 13963 [host=leaf-beetle]
 13956 [host=itch-mite]
 13964 []
 13973 [host=itch-mite]
 13979 [host=gall-mite]
 13995 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4b4c0c7a6031
 14002 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 e0e1350dfe9b
 14003 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4b4c0c7a6031
 14004 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 177fdda0be56
 14005 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 37bb894121c7
 14001 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 1f4be6ee4619
 14006 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
 14008 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 1f4be6ee4619
 14009 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 14007 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 5c402b905e00
 14010 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
 14012 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 e0e1350dfe9b
 14013 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 5c402b905e00
 14014 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 14015 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
 14011 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 5c402b905e00
 14016 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
Searching for interesting versions
 Result found: flight 13960 (pass), for basis pass
 Result found: flight 14007 (fail), for basis failure
 Repro found: flight 14012 (pass), for basis pass
 Repro found: flight 14013 (fail), for basis failure
 0 revisions at a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
No revisions left to test, checking graph state.
 Result found: flight 14006 (pass), for last pass
 Result found: flight 14009 (fail), for first failure
 Repro found: flight 14010 (pass), for last pass
 Repro found: flight 14014 (fail), for first failure
 Repro found: flight 14015 (pass), for last pass
 Repro found: flight 14016 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
  Bug introduced:  4fc87c2f31a0
  Bug not present: c1c549c4fe9e

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   26060:4fc87c2f31a0
  user:        Huang Ying 
  date:        Tue Oct 16 17:26:36 2012 +0200
      
      ACPI: fix APEI related table size checking
      
      On Huang Ying's machine:
      
      erst_tab->header_length == sizeof(struct acpi_table_einj)
      
      but Yinghai reported that on his machine,
      
      erst_tab->header_length == sizeof(struct acpi_table_einj) -
      sizeof(struct acpi_table_header)
      
      To make erst table size checking code works on all systems, both
      testing are treated as PASS.
      
      Same situation applies to einj_tab->header_length, so corresponding
      table size checking is changed in similar way too.
      
      Originally-by: Yinghai Lu 
      Signed-off-by: Huang Ying 
      
      - use switch() for better readability
      - add comment explaining why a formally invalid size it also being
        accepted
      - check erst_tab->header.length before even looking at
        erst_tab->header_length
      - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
      
      Signed-off-by: Jan Beulich 
      Acked-by: Keir Fraser 
      Committed-by: Jan Beulich 
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-amd64-i386-xl-multivcpu.xen-boot.{dot,ps,png,html}.
----------------------------------------
14016: tolerable ALL FAIL

flight 14016 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14016/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-multivcpu  5 xen-boot                fail baseline untested


jobs:
 test-amd64-i386-xl-multivcpu                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 01:17:13 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 01:17:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOejD-0006Zh-D5; Thu, 18 Oct 2012 01:16:51 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOejB-0006Zc-1U
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 01:16:49 +0000
Received: from [193.109.254.147:51699] by server-8.bemta-14.messagelabs.com id
	03/96-16549-0885F705; Thu, 18 Oct 2012 01:16:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1350523006!10367483!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31967 invoked from network); 18 Oct 2012 01:16:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 01:16:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,603,1344211200"; d="scan'208";a="15242697"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 01:16:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 18 Oct 2012 02:16:46 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TOej8-0002ju-DD;
	Thu, 18 Oct 2012 01:16:46 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TOej8-00070X-CG;
	Thu, 18 Oct 2012 02:16:46 +0100
To: 
Message-ID: 
From: xen.org 
Date: Thu, 18 Oct 2012 02:16:46 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete
	test-amd64-i386-xl-multivcpu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-xl-multivcpu
test xen-boot

Tree: linux git://xenbits.xen.org/linux-pvops.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 http://xenbits.xen.org/hg/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
  Bug introduced:  4fc87c2f31a0
  Bug not present: c1c549c4fe9e


  changeset:   26060:4fc87c2f31a0
  user:        Huang Ying 
  date:        Tue Oct 16 17:26:36 2012 +0200
      
      ACPI: fix APEI related table size checking
      
      On Huang Ying's machine:
      
      erst_tab->header_length == sizeof(struct acpi_table_einj)
      
      but Yinghai reported that on his machine,
      
      erst_tab->header_length == sizeof(struct acpi_table_einj) -
      sizeof(struct acpi_table_header)
      
      To make erst table size checking code works on all systems, both
      testing are treated as PASS.
      
      Same situation applies to einj_tab->header_length, so corresponding
      table size checking is changed in similar way too.
      
      Originally-by: Yinghai Lu 
      Signed-off-by: Huang Ying 
      
      - use switch() for better readability
      - add comment explaining why a formally invalid size it also being
        accepted
      - check erst_tab->header.length before even looking at
        erst_tab->header_length
      - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
      
      Signed-off-by: Jan Beulich 
      Acked-by: Keir Fraser 
      Committed-by: Jan Beulich 
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-i386-xl-multivcpu.xen-boot.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 14011 fail [host=potato-beetle] / 13979 [host=gall-mite] 13973 [host=itch-mite] 13972 [host=earwig] 13967 [host=moss-bug] 13963 [host=leaf-beetle] 13962 [host=field-cricket] 13960 ok.
Failure / basis pass flights: 14011 / 13960
Tree: linux git://xenbits.xen.org/linux-pvops.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 http://xenbits.xen.org/hg/staging/xen-unstable.hg
Latest a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 5c402b905e00
Basis pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 e0e1350dfe9b
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#a938a246d34912423c560f475ccf1ce0c71d9d00-a938a246d34912423c560f475ccf1ce0c71d9d00 git://xenbits.xen.org/staging/qemu-xen-unstable.git#bacc0d302445c75f18f4c826750fb5853b60e7ca-bacc0d302445c75f18f4c826750fb5853b60e7ca git://xenbits.xen.org/staging/qemu-upstream-unstable.git#cdf4d2bb4006805f209712fbb8ed1f83127e9984-cdf4d2bb4006805f209712fbb8ed1f83127e9984 http://xenbits.xen.org/hg/staging/xen-unstable.hg#e0e1350dfe9b-5c402b905e00
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
Loaded 252 nodes in revision graph
Searching for test results:
 13958 [host=lace-bug]
 13960 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 e0e1350dfe9b
 13967 [host=moss-bug]
 13962 [host=field-cricket]
 13972 [host=earwig]
 13963 [host=leaf-beetle]
 13956 [host=itch-mite]
 13964 []
 13973 [host=itch-mite]
 13979 [host=gall-mite]
 13995 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4b4c0c7a6031
 14002 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 e0e1350dfe9b
 14003 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4b4c0c7a6031
 14004 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 177fdda0be56
 14005 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 37bb894121c7
 14001 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 1f4be6ee4619
 14006 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
 14008 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 1f4be6ee4619
 14009 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 14007 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 5c402b905e00
 14010 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
 14012 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 e0e1350dfe9b
 14013 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 5c402b905e00
 14014 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 14015 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
 14011 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 5c402b905e00
 14016 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
Searching for interesting versions
 Result found: flight 13960 (pass), for basis pass
 Result found: flight 14007 (fail), for basis failure
 Repro found: flight 14012 (pass), for basis pass
 Repro found: flight 14013 (fail), for basis failure
 0 revisions at a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
No revisions left to test, checking graph state.
 Result found: flight 14006 (pass), for last pass
 Result found: flight 14009 (fail), for first failure
 Repro found: flight 14010 (pass), for last pass
 Repro found: flight 14014 (fail), for first failure
 Repro found: flight 14015 (pass), for last pass
 Repro found: flight 14016 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
  Bug introduced:  4fc87c2f31a0
  Bug not present: c1c549c4fe9e

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   26060:4fc87c2f31a0
  user:        Huang Ying 
  date:        Tue Oct 16 17:26:36 2012 +0200
      
      ACPI: fix APEI related table size checking
      
      On Huang Ying's machine:
      
      erst_tab->header_length == sizeof(struct acpi_table_einj)
      
      but Yinghai reported that on his machine,
      
      erst_tab->header_length == sizeof(struct acpi_table_einj) -
      sizeof(struct acpi_table_header)
      
      To make erst table size checking code works on all systems, both
      testing are treated as PASS.
      
      Same situation applies to einj_tab->header_length, so corresponding
      table size checking is changed in similar way too.
      
      Originally-by: Yinghai Lu 
      Signed-off-by: Huang Ying 
      
      - use switch() for better readability
      - add comment explaining why a formally invalid size it also being
        accepted
      - check erst_tab->header.length before even looking at
        erst_tab->header_length
      - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
      
      Signed-off-by: Jan Beulich 
      Acked-by: Keir Fraser 
      Committed-by: Jan Beulich 
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-amd64-i386-xl-multivcpu.xen-boot.{dot,ps,png,html}.
----------------------------------------
14016: tolerable ALL FAIL

flight 14016 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14016/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-multivcpu  5 xen-boot                fail baseline untested


jobs:
 test-amd64-i386-xl-multivcpu                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 02:00:51 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 02:00:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOfPS-0007Ae-Lp; Thu, 18 Oct 2012 02:00:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOfPP-0006uX-Qp
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 02:00:28 +0000
Received: from [85.158.143.35:36690] by server-3.bemta-4.messagelabs.com id
	6E/E8-03544-BB26F705; Thu, 18 Oct 2012 02:00:27 +0000
X-Env-Sender: ronghui.duan@intel.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1350525625!15497666!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjIwMTU3\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25825 invoked from network); 18 Oct 2012 02:00:25 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-15.tower-21.messagelabs.com with SMTP;
	18 Oct 2012 02:00:25 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 17 Oct 2012 19:00:24 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,604,1344236400"; d="scan'208";a="205864686"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by azsmga001.ch.intel.com with ESMTP; 17 Oct 2012 19:00:08 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 17 Oct 2012 18:59:50 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.123]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.186]) with mapi id
	14.01.0355.002; Thu, 18 Oct 2012 09:59:36 +0800
From: "Duan, Ronghui" 
To: Konrad Rzeszutek Wilk , Justin Gibbs
	, "xen-devel@lists.xensource.com"
	
Thread-Topic: xen-vbd interface (segment size expansion) - FreeBSD host have
	it.
Thread-Index: AQHNmzOxdsL4WvckRkmocWECXFe9EJe+b2bw
Date: Thu, 18 Oct 2012 01:59:36 +0000
Message-ID: 
References: 
	<20120817172838.GA3515@phenom.dumpdata.com>
	
	<61DFA8800400A143A5A7C5E136A726DC5F867490@reactor.sldomain.com>
	<20120925152600.GA967@phenom.dumpdata.com>
In-Reply-To: <20120925152600.GA967@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Subject: Re: [Xen-devel] xen-vbd interface (segment size expansion) -
 FreeBSD host have it.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, I am back from a long holiday. Sorry for the delay replay.
> I was wondering how the protocol you developed works when it comes to
> migration to a host that does not support the new features?
>
For my part, when VM migrate to a host which do not support larger segments, frontend will fall back to use original protocol with old-segments 11.

> Specifically how do deal with a guest which tries to replay in progress I/Os
> that do not fit within the old-segment size (11)?
The in-progress bio which have larger segments > 11 will receive an io error. I do not find a better way to handle it yet.

> -----Original Message-----
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: Tuesday, September 25, 2012 11:26 PM
> To: Justin Gibbs; xen-devel@lists.xensource.com
> Cc: Duan, Ronghui
> Subject: Re: xen-vbd interface (segment size expansion) - FreeBSD host have
> it.
> 
> On Mon, Aug 20, 2012 at 06:56:02PM +0000, Justin Gibbs wrote:
> > Ronghui,
> >
> > It has been a while since I've actively worked on the blkif stuff.  ...
> >
> > That said, I'm happy to help in whatever ways I can to help get the blkif
> interface sorted out.  I see several steps that should be taken:
> >
> > 1) Fix the Xen and QEMU builds so that QEMU keeps its own copy of the
> Xen interface version.  This will allow interfaces to rev safely and in a
> coordinated fashion (i.e. update interface in Xen, then add support for the
> new interface in QEMU upstream).
> >
> > 2) Complete support in drivers for the existing blkif interface so that you
> get maximum performance against systems using the existing multi-page
> extensions.
> >
> > 3) Do something to allow for larger and more numerous requests.
> >
> > On point 3, my approach was to try to perturb the existing protocol as little
> as possible in the hopes that other implementations could quickly be
> enhanced to support the feature.  However, there is a lot of ugliness in the
> existing blkif interface.  I can certainly understand the desires of some to just
> replace blkif with a blkif2.
> >
> > What are your current plans in this area?  How can I be of assistance?
> 
> Hey Justin and Ronghui,
> 
> Note: I've expanded the email thread to include xen-devel.
> 
> I was wondering how the protocol you developed works when it comes to
> migration to a host that does not support the new features?
> 
> Specifically how do deal with a guest which tries to replay in progress I/Os
> that do not fit within the old-segment size (11)?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 02:00:51 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 02:00:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOfPS-0007Ae-Lp; Thu, 18 Oct 2012 02:00:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOfPP-0006uX-Qp
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 02:00:28 +0000
Received: from [85.158.143.35:36690] by server-3.bemta-4.messagelabs.com id
	6E/E8-03544-BB26F705; Thu, 18 Oct 2012 02:00:27 +0000
X-Env-Sender: ronghui.duan@intel.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1350525625!15497666!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjIwMTU3\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25825 invoked from network); 18 Oct 2012 02:00:25 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-15.tower-21.messagelabs.com with SMTP;
	18 Oct 2012 02:00:25 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 17 Oct 2012 19:00:24 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,604,1344236400"; d="scan'208";a="205864686"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by azsmga001.ch.intel.com with ESMTP; 17 Oct 2012 19:00:08 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 17 Oct 2012 18:59:50 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.123]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.186]) with mapi id
	14.01.0355.002; Thu, 18 Oct 2012 09:59:36 +0800
From: "Duan, Ronghui" 
To: Konrad Rzeszutek Wilk , Justin Gibbs
	, "xen-devel@lists.xensource.com"
	
Thread-Topic: xen-vbd interface (segment size expansion) - FreeBSD host have
	it.
Thread-Index: AQHNmzOxdsL4WvckRkmocWECXFe9EJe+b2bw
Date: Thu, 18 Oct 2012 01:59:36 +0000
Message-ID: 
References: 
	<20120817172838.GA3515@phenom.dumpdata.com>
	
	<61DFA8800400A143A5A7C5E136A726DC5F867490@reactor.sldomain.com>
	<20120925152600.GA967@phenom.dumpdata.com>
In-Reply-To: <20120925152600.GA967@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Subject: Re: [Xen-devel] xen-vbd interface (segment size expansion) -
 FreeBSD host have it.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, I am back from a long holiday. Sorry for the delay replay.
> I was wondering how the protocol you developed works when it comes to
> migration to a host that does not support the new features?
>
For my part, when VM migrate to a host which do not support larger segments, frontend will fall back to use original protocol with old-segments 11.

> Specifically how do deal with a guest which tries to replay in progress I/Os
> that do not fit within the old-segment size (11)?
The in-progress bio which have larger segments > 11 will receive an io error. I do not find a better way to handle it yet.

> -----Original Message-----
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: Tuesday, September 25, 2012 11:26 PM
> To: Justin Gibbs; xen-devel@lists.xensource.com
> Cc: Duan, Ronghui
> Subject: Re: xen-vbd interface (segment size expansion) - FreeBSD host have
> it.
> 
> On Mon, Aug 20, 2012 at 06:56:02PM +0000, Justin Gibbs wrote:
> > Ronghui,
> >
> > It has been a while since I've actively worked on the blkif stuff.  ...
> >
> > That said, I'm happy to help in whatever ways I can to help get the blkif
> interface sorted out.  I see several steps that should be taken:
> >
> > 1) Fix the Xen and QEMU builds so that QEMU keeps its own copy of the
> Xen interface version.  This will allow interfaces to rev safely and in a
> coordinated fashion (i.e. update interface in Xen, then add support for the
> new interface in QEMU upstream).
> >
> > 2) Complete support in drivers for the existing blkif interface so that you
> get maximum performance against systems using the existing multi-page
> extensions.
> >
> > 3) Do something to allow for larger and more numerous requests.
> >
> > On point 3, my approach was to try to perturb the existing protocol as little
> as possible in the hopes that other implementations could quickly be
> enhanced to support the feature.  However, there is a lot of ugliness in the
> existing blkif interface.  I can certainly understand the desires of some to just
> replace blkif with a blkif2.
> >
> > What are your current plans in this area?  How can I be of assistance?
> 
> Hey Justin and Ronghui,
> 
> Note: I've expanded the email thread to include xen-devel.
> 
> I was wondering how the protocol you developed works when it comes to
> migration to a host that does not support the new features?
> 
> Specifically how do deal with a guest which tries to replay in progress I/Os
> that do not fit within the old-segment size (11)?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 04:16:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 04:16:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOhWh-0007pi-35; Thu, 18 Oct 2012 04:16:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOhWf-0007pd-9R
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 04:16:05 +0000
Received: from [85.158.137.99:4535] by server-4.bemta-3.messagelabs.com id
	51/08-01405-4828F705; Thu, 18 Oct 2012 04:16:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1350533760!18901778!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18432 invoked from network); 18 Oct 2012 04:16:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 04:16:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,604,1344211200"; d="scan'208";a="15243699"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 04:15:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 18 Oct 2012 05:16:00 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TOhWZ-0003fe-JU;
	Thu, 18 Oct 2012 04:15:59 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TOhWZ-0005LP-Im;
	Thu, 18 Oct 2012 05:15:59 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Thu, 18 Oct 2012 05:15:59 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14017: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14017 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14017/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 13967
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-pv            5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 13967
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 13967
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 13967
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 13967
 test-amd64-amd64-xl           5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                fail REGR. vs. 13967
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 13967
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 13967
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot          fail REGR. vs. 13967

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13967
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13967

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  5c402b905e00
baseline version:
 xen                  c1c549c4fe9e

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf 
  Huang Ying 
  Ian Campbell 
  Jan Beulich 
  Keir Fraser 
  Stefano Stabellini 
  Tim Deegan 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26073:5c402b905e00
tag:         tip
user:        Ian Campbell 
date:        Wed Oct 17 16:43:55 2012 +0100
    
    arm: parameter guest handles are 32 bit on 32 bit hypervisor
    
    Handles within structs remain 64 bit such that they are consistently
    sized on both 32 and 64 bit.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Stefano Stabellini 
    Committed-by: Ian Campbell 
    
    
changeset:   26072:5529b91bd2e4
user:        Ian Campbell 
date:        Wed Oct 17 16:43:54 2012 +0100
    
    xen: remove XEN_GUEST_HANDLE(ulong)
    
    Having both this handle (always unsigned long) and
    XEN_GUEST_HANDLE(xen_ulong_t) (unsigned long on x86 and explicit size
    of ARM) is confusing and error prone.
    
    Replace the two remaining uses of the ulong handle, in grant set and
    x86 set_gdt hypercalls, with xen_ulong_t.
    
    This correctly sizes the grant frame entry as 64 bit on ARM but
    leaves it as unsigned long on x86 (therefore no intended change on
    x86). Likewise in set_gdt there is no actual change.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Keir Fraser 
    Acked-by: Stefano Stabellini 
    Committed-by: Ian Campbell 
    
    
changeset:   26071:2a1083b1d0c2
user:        Stefano Stabellini 
date:        Wed Oct 17 16:43:53 2012 +0100
    
    xen: more XEN_GUEST_HANDLE_PARAM substitutions
    
    More substitutions in this patch, not as obvious as the ones in the
    previous patch.
    
    Signed-off-by: Stefano Stabellini 
    Signed-off-by: Ian Campbell 
    Acked-by: Keir Fraser 
    Committed-by: Ian Campbell 
    
    
changeset:   26070:9eafdcd5ff0b
user:        Stefano Stabellini 
date:        Wed Oct 17 16:43:53 2012 +0100
    
    xen: replace XEN_GUEST_HANDLE with XEN_GUEST_HANDLE_PARAM when appropriate
    
    Note: these changes don't make any difference on x86.
    
    Replace XEN_GUEST_HANDLE with XEN_GUEST_HANDLE_PARAM when it is used as
    an hypercall argument.
    
    Signed-off-by: Stefano Stabellini 
    Signed-off-by: Ian Campbell 
    Acked-by: Keir Fraser 
    Committed-by: Ian Campbell 
    
    
changeset:   26069:1eb4b2f7465f
user:        Stefano Stabellini 
date:        Wed Oct 17 16:43:51 2012 +0100
    
    xen: introduce XEN_GUEST_HANDLE_PARAM
    
    XEN_GUEST_HANDLE_PARAM is going to be used to distinguish guest pointers
    stored in memory from guest pointers as hypercall parameters.
    
    guest_handle_* macros default to XEN_GUEST_HANDLE_PARAM as return type.
    Two new guest_handle_to_param and guest_handle_from_param macros are
    introduced to do conversions.
    
    Signed-off-by: Stefano Stabellini 
    Signed-off-by: Ian Campbell 
    Acked-by: Keir Fraser 
    Committed-by: Ian Campbell 
    
    
changeset:   26068:ed6c13501195
user:        Stefano Stabellini 
date:        Wed Oct 17 16:43:50 2012 +0100
    
    xen: change the limit of nr_extents to UINT_MAX >> MEMOP_EXTENT_SHIFT
    
    Currently do_memory_op has a different maximum limit for nr_extents on
    32 bit and 64 bit.
    Change the limit to UINT_MAX >> MEMOP_EXTENT_SHIFT, so that it is the
    same in both cases.
    
    Signed-off-by: Stefano Stabellini 
    Signed-off-by: Ian Campbell 
    Acked-by: Keir Fraser 
    Committed-by: Ian Campbell 
    
    
changeset:   26067:a324eea3bbc8
user:        Stefano Stabellini 
date:        Wed Oct 17 16:43:49 2012 +0100
    
    xen: xen_ulong_t substitution
    
    There is still an unwanted unsigned long in the xen public interface:
    replace it with xen_ulong_t.
    
    Also typedef xen_ulong_t to uint64_t on ARM.
    
    Signed-off-by: Stefano Stabellini 
    Signed-off-by: Ian Campbell 
    Acked-by: Keir Fraser 
    Committed-by: Ian Campbell 
    
    
changeset:   26066:980863b9fa4b
user:        Ian Campbell 
date:        Wed Oct 17 16:43:48 2012 +0100
    
    arm: tools: add arm to foreign structs checking
    
    Signed-off-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26065:b146705d70b3
user:        Stefano Stabellini 
date:        Wed Oct 17 16:43:47 2012 +0100
    
    xen/arm: grant table
    
    Implement XENMAPSPACE_grant_table and grant_table_op.
    
    Signed-off-by: Stefano Stabellini 
    Acked-by: Tim Deegan 
    [ ijc -- fixed reject in traps.c, grant table op is a 3 argument
             hypercall, rebased over "xen: arm: implement
             XENMEM_add_to_physmap_range"
    ]
    Signed-off-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26064:bbe986018949
user:        Ian Campbell 
date:        Wed Oct 17 16:43:46 2012 +0100
    
    xen: arm: implement XENMEM_add_to_physmap_range
    
    This allows for foreign mappings as well as batching, fitting all that
    into XENMEM_add_to_physmap wasn't possible.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Keir Fraser 
    Acked-by: Stefano Stabellini 
    Committed-by: Ian Campbell 
    
    
changeset:   26063:1f4be6ee4619
user:        Jan Beulich 
date:        Wed Oct 17 14:13:20 2012 +0200
    
    x86/HPET: obtain proper lock for changing IRQ affinity
    
    The IRQ descriptor lock should be held while adjusting the affinity of
    any IRQ; the HPET channel lock isn't sufficient to protect namely
    against races with moving the IRQ to a different CPU.
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    
    
changeset:   26062:ec8a091efcce
user:        Huang Ying 
date:        Wed Oct 17 14:12:06 2012 +0200
    
    ACPI/APEI: fix ERST MOVE_DATA instruction implementation
    
    The src_base and dst_base fields in apei_exec_context are physical
    address, so they should be ioremaped before being used in ERST
    MOVE_DATA instruction.
    
    Reported-by: Javier Martinez Canillas 
    Reported-by: Andrew Morton 
    Signed-off-by: Huang Ying 
    
    Replace use of ioremap() by __acpi_map_table()/set_fixmap(). Fix error
    handling.
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    Committed-by: Jan Beulich 
    
    
changeset:   26061:4b4c0c7a6031
user:        Jan Beulich 
date:        Wed Oct 17 11:23:10 2012 +0200
    
    x86/oprof: adjust off-by-one counter range checks
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    
    
changeset:   26060:4fc87c2f31a0
user:        Huang Ying 
date:        Tue Oct 16 17:26:36 2012 +0200
    
    ACPI: fix APEI related table size checking
    
    On Huang Ying's machine:
    
    erst_tab->header_length == sizeof(struct acpi_table_einj)
    
    but Yinghai reported that on his machine,
    
    erst_tab->header_length == sizeof(struct acpi_table_einj) -
    sizeof(struct acpi_table_header)
    
    To make erst table size checking code works on all systems, both
    testing are treated as PASS.
    
    Same situation applies to einj_tab->header_length, so corresponding
    table size checking is changed in similar way too.
    
    Originally-by: Yinghai Lu 
    Signed-off-by: Huang Ying 
    
    - use switch() for better readability
    - add comment explaining why a formally invalid size it also being
      accepted
    - check erst_tab->header.length before even looking at
      erst_tab->header_length
    - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    Committed-by: Jan Beulich 
    
    
changeset:   26059:c1c549c4fe9e
user:        Daniel De Graaf 
date:        Mon Oct 15 16:51:44 2012 +0100
    
    xen: Add versions of rcu_lock_*_domain without IS_PRIV
    
    These functions will be used to avoid duplication of IS_PRIV calls
    that will be introduced in XSM hooks. This also fixes a build error
    with XSM enabled introduced by 25925:d1c3375c3f11 which depends on
    this patch.
    
    Signed-off-by: Daniel De Graaf 
    Committed-by: Keir Fraser 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 04:16:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 04:16:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOhWh-0007pi-35; Thu, 18 Oct 2012 04:16:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOhWf-0007pd-9R
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 04:16:05 +0000
Received: from [85.158.137.99:4535] by server-4.bemta-3.messagelabs.com id
	51/08-01405-4828F705; Thu, 18 Oct 2012 04:16:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1350533760!18901778!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18432 invoked from network); 18 Oct 2012 04:16:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 04:16:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,604,1344211200"; d="scan'208";a="15243699"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 04:15:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 18 Oct 2012 05:16:00 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TOhWZ-0003fe-JU;
	Thu, 18 Oct 2012 04:15:59 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TOhWZ-0005LP-Im;
	Thu, 18 Oct 2012 05:15:59 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Thu, 18 Oct 2012 05:15:59 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14017: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14017 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14017/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 13967
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-xl            5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-pv            5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 13967
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 13967
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 13967
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 13967
 test-amd64-amd64-xl           5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                fail REGR. vs. 13967
 test-amd64-i386-xl-winxpsp3-vcpus1  5 xen-boot            fail REGR. vs. 13967
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 13967
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-qemuu-win7-amd64  5 xen-boot          fail REGR. vs. 13967

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13967
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13967

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  5c402b905e00
baseline version:
 xen                  c1c549c4fe9e

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf 
  Huang Ying 
  Ian Campbell 
  Jan Beulich 
  Keir Fraser 
  Stefano Stabellini 
  Tim Deegan 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26073:5c402b905e00
tag:         tip
user:        Ian Campbell 
date:        Wed Oct 17 16:43:55 2012 +0100
    
    arm: parameter guest handles are 32 bit on 32 bit hypervisor
    
    Handles within structs remain 64 bit such that they are consistently
    sized on both 32 and 64 bit.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Stefano Stabellini 
    Committed-by: Ian Campbell 
    
    
changeset:   26072:5529b91bd2e4
user:        Ian Campbell 
date:        Wed Oct 17 16:43:54 2012 +0100
    
    xen: remove XEN_GUEST_HANDLE(ulong)
    
    Having both this handle (always unsigned long) and
    XEN_GUEST_HANDLE(xen_ulong_t) (unsigned long on x86 and explicit size
    of ARM) is confusing and error prone.
    
    Replace the two remaining uses of the ulong handle, in grant set and
    x86 set_gdt hypercalls, with xen_ulong_t.
    
    This correctly sizes the grant frame entry as 64 bit on ARM but
    leaves it as unsigned long on x86 (therefore no intended change on
    x86). Likewise in set_gdt there is no actual change.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Keir Fraser 
    Acked-by: Stefano Stabellini 
    Committed-by: Ian Campbell 
    
    
changeset:   26071:2a1083b1d0c2
user:        Stefano Stabellini 
date:        Wed Oct 17 16:43:53 2012 +0100
    
    xen: more XEN_GUEST_HANDLE_PARAM substitutions
    
    More substitutions in this patch, not as obvious as the ones in the
    previous patch.
    
    Signed-off-by: Stefano Stabellini 
    Signed-off-by: Ian Campbell 
    Acked-by: Keir Fraser 
    Committed-by: Ian Campbell 
    
    
changeset:   26070:9eafdcd5ff0b
user:        Stefano Stabellini 
date:        Wed Oct 17 16:43:53 2012 +0100
    
    xen: replace XEN_GUEST_HANDLE with XEN_GUEST_HANDLE_PARAM when appropriate
    
    Note: these changes don't make any difference on x86.
    
    Replace XEN_GUEST_HANDLE with XEN_GUEST_HANDLE_PARAM when it is used as
    an hypercall argument.
    
    Signed-off-by: Stefano Stabellini 
    Signed-off-by: Ian Campbell 
    Acked-by: Keir Fraser 
    Committed-by: Ian Campbell 
    
    
changeset:   26069:1eb4b2f7465f
user:        Stefano Stabellini 
date:        Wed Oct 17 16:43:51 2012 +0100
    
    xen: introduce XEN_GUEST_HANDLE_PARAM
    
    XEN_GUEST_HANDLE_PARAM is going to be used to distinguish guest pointers
    stored in memory from guest pointers as hypercall parameters.
    
    guest_handle_* macros default to XEN_GUEST_HANDLE_PARAM as return type.
    Two new guest_handle_to_param and guest_handle_from_param macros are
    introduced to do conversions.
    
    Signed-off-by: Stefano Stabellini 
    Signed-off-by: Ian Campbell 
    Acked-by: Keir Fraser 
    Committed-by: Ian Campbell 
    
    
changeset:   26068:ed6c13501195
user:        Stefano Stabellini 
date:        Wed Oct 17 16:43:50 2012 +0100
    
    xen: change the limit of nr_extents to UINT_MAX >> MEMOP_EXTENT_SHIFT
    
    Currently do_memory_op has a different maximum limit for nr_extents on
    32 bit and 64 bit.
    Change the limit to UINT_MAX >> MEMOP_EXTENT_SHIFT, so that it is the
    same in both cases.
    
    Signed-off-by: Stefano Stabellini 
    Signed-off-by: Ian Campbell 
    Acked-by: Keir Fraser 
    Committed-by: Ian Campbell 
    
    
changeset:   26067:a324eea3bbc8
user:        Stefano Stabellini 
date:        Wed Oct 17 16:43:49 2012 +0100
    
    xen: xen_ulong_t substitution
    
    There is still an unwanted unsigned long in the xen public interface:
    replace it with xen_ulong_t.
    
    Also typedef xen_ulong_t to uint64_t on ARM.
    
    Signed-off-by: Stefano Stabellini 
    Signed-off-by: Ian Campbell 
    Acked-by: Keir Fraser 
    Committed-by: Ian Campbell 
    
    
changeset:   26066:980863b9fa4b
user:        Ian Campbell 
date:        Wed Oct 17 16:43:48 2012 +0100
    
    arm: tools: add arm to foreign structs checking
    
    Signed-off-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26065:b146705d70b3
user:        Stefano Stabellini 
date:        Wed Oct 17 16:43:47 2012 +0100
    
    xen/arm: grant table
    
    Implement XENMAPSPACE_grant_table and grant_table_op.
    
    Signed-off-by: Stefano Stabellini 
    Acked-by: Tim Deegan 
    [ ijc -- fixed reject in traps.c, grant table op is a 3 argument
             hypercall, rebased over "xen: arm: implement
             XENMEM_add_to_physmap_range"
    ]
    Signed-off-by: Ian Campbell 
    Committed-by: Ian Campbell 
    
    
changeset:   26064:bbe986018949
user:        Ian Campbell 
date:        Wed Oct 17 16:43:46 2012 +0100
    
    xen: arm: implement XENMEM_add_to_physmap_range
    
    This allows for foreign mappings as well as batching, fitting all that
    into XENMEM_add_to_physmap wasn't possible.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Keir Fraser 
    Acked-by: Stefano Stabellini 
    Committed-by: Ian Campbell 
    
    
changeset:   26063:1f4be6ee4619
user:        Jan Beulich 
date:        Wed Oct 17 14:13:20 2012 +0200
    
    x86/HPET: obtain proper lock for changing IRQ affinity
    
    The IRQ descriptor lock should be held while adjusting the affinity of
    any IRQ; the HPET channel lock isn't sufficient to protect namely
    against races with moving the IRQ to a different CPU.
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    
    
changeset:   26062:ec8a091efcce
user:        Huang Ying 
date:        Wed Oct 17 14:12:06 2012 +0200
    
    ACPI/APEI: fix ERST MOVE_DATA instruction implementation
    
    The src_base and dst_base fields in apei_exec_context are physical
    address, so they should be ioremaped before being used in ERST
    MOVE_DATA instruction.
    
    Reported-by: Javier Martinez Canillas 
    Reported-by: Andrew Morton 
    Signed-off-by: Huang Ying 
    
    Replace use of ioremap() by __acpi_map_table()/set_fixmap(). Fix error
    handling.
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    Committed-by: Jan Beulich 
    
    
changeset:   26061:4b4c0c7a6031
user:        Jan Beulich 
date:        Wed Oct 17 11:23:10 2012 +0200
    
    x86/oprof: adjust off-by-one counter range checks
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    
    
changeset:   26060:4fc87c2f31a0
user:        Huang Ying 
date:        Tue Oct 16 17:26:36 2012 +0200
    
    ACPI: fix APEI related table size checking
    
    On Huang Ying's machine:
    
    erst_tab->header_length == sizeof(struct acpi_table_einj)
    
    but Yinghai reported that on his machine,
    
    erst_tab->header_length == sizeof(struct acpi_table_einj) -
    sizeof(struct acpi_table_header)
    
    To make erst table size checking code works on all systems, both
    testing are treated as PASS.
    
    Same situation applies to einj_tab->header_length, so corresponding
    table size checking is changed in similar way too.
    
    Originally-by: Yinghai Lu 
    Signed-off-by: Huang Ying 
    
    - use switch() for better readability
    - add comment explaining why a formally invalid size it also being
      accepted
    - check erst_tab->header.length before even looking at
      erst_tab->header_length
    - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
    
    Signed-off-by: Jan Beulich 
    Acked-by: Keir Fraser 
    Committed-by: Jan Beulich 
    
    
changeset:   26059:c1c549c4fe9e
user:        Daniel De Graaf 
date:        Mon Oct 15 16:51:44 2012 +0100
    
    xen: Add versions of rcu_lock_*_domain without IS_PRIV
    
    These functions will be used to avoid duplication of IS_PRIV calls
    that will be introduced in XSM hooks. This also fixes a build error
    with XSM enabled introduced by 25925:d1c3375c3f11 which depends on
    this patch.
    
    Signed-off-by: Daniel De Graaf 
    Committed-by: Keir Fraser 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 06:13:20 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 06:13:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOjLa-0000D1-7J; Thu, 18 Oct 2012 06:12:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOjLY-0000Cw-BX
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 06:12:44 +0000
Received: from [85.158.139.211:58021] by server-3.bemta-5.messagelabs.com id
	4D/46-28618-BDD9F705; Thu, 18 Oct 2012 06:12:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1350540762!22750470!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19278 invoked from network); 18 Oct 2012 06:12:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 06:12:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,605,1344211200"; d="scan'208";a="15244501"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 06:12:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 18 Oct 2012 07:12:42 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TOjLV-0004WX-UM;
	Thu, 18 Oct 2012 06:12:41 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TOjLV-0001Gk-Ti;
	Thu, 18 Oct 2012 07:12:41 +0100
To: 
Message-ID: 
From: xen.org 
Date: Thu, 18 Oct 2012 07:12:41 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete
	test-amd64-i386-rhel6hvm-amd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-rhel6hvm-amd
test xen-boot

Tree: linux git://xenbits.xen.org/linux-pvops.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 http://xenbits.xen.org/hg/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
  Bug introduced:  4fc87c2f31a0
  Bug not present: c1c549c4fe9e


  changeset:   26060:4fc87c2f31a0
  user:        Huang Ying 
  date:        Tue Oct 16 17:26:36 2012 +0200
      
      ACPI: fix APEI related table size checking
      
      On Huang Ying's machine:
      
      erst_tab->header_length == sizeof(struct acpi_table_einj)
      
      but Yinghai reported that on his machine,
      
      erst_tab->header_length == sizeof(struct acpi_table_einj) -
      sizeof(struct acpi_table_header)
      
      To make erst table size checking code works on all systems, both
      testing are treated as PASS.
      
      Same situation applies to einj_tab->header_length, so corresponding
      table size checking is changed in similar way too.
      
      Originally-by: Yinghai Lu 
      Signed-off-by: Huang Ying 
      
      - use switch() for better readability
      - add comment explaining why a formally invalid size it also being
        accepted
      - check erst_tab->header.length before even looking at
        erst_tab->header_length
      - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
      
      Signed-off-by: Jan Beulich 
      Acked-by: Keir Fraser 
      Committed-by: Jan Beulich 
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-i386-rhel6hvm-amd.xen-boot.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 14017 fail [host=moss-bug] / 13967 [host=lace-bug] 13963 [host=potato-beetle] 13962 ok.
Failure / basis pass flights: 14017 / 13962
Tree: linux git://xenbits.xen.org/linux-pvops.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 http://xenbits.xen.org/hg/staging/xen-unstable.hg
Latest a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 5c402b905e00
Basis pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 e0e1350dfe9b
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#a938a246d34912423c560f475ccf1ce0c71d9d00-a938a246d34912423c560f475ccf1ce0c71d9d00 git://xenbits.xen.org/staging/qemu-xen-unstable.git#bacc0d302445c75f18f4c826750fb5853b60e7ca-bacc0d302445c75f18f4c826750fb5853b60e7ca git://xenbits.xen.org/staging/qemu-upstream-unstable.git#cdf4d2bb4006805f209712fbb8ed1f83127e9984-cdf4d2bb4006805f209712fbb8ed1f83127e9984 http://xenbits.xen.org/hg/staging/xen-unstable.hg#e0e1350dfe9b-5c402b905e00
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
Loaded 252 nodes in revision graph
Searching for test results:
 13958 [host=lace-bug]
 13960 [host=leaf-beetle]
 13967 [host=lace-bug]
 13962 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 e0e1350dfe9b
 13972 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 13963 [host=potato-beetle]
 13956 [host=potato-beetle]
 13964 []
 13973 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 13979 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 13997 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 14000 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
 13996 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 e0e1350dfe9b
 13998 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 177fdda0be56
 13995 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4b4c0c7a6031
 13999 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 37bb894121c7
 14001 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 1f4be6ee4619
 14007 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 5c402b905e00
 14011 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 5c402b905e00
 14018 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 e0e1350dfe9b
 14019 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 5c402b905e00
 14020 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 14017 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 5c402b905e00
 14021 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
 14022 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 14023 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
 14024 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
Searching for interesting versions
 Result found: flight 13962 (pass), for basis pass
 Result found: flight 14007 (fail), for basis failure
 Repro found: flight 14018 (pass), for basis pass
 Repro found: flight 14019 (fail), for basis failure
 0 revisions at a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
No revisions left to test, checking graph state.
 Result found: flight 14000 (pass), for last pass
 Result found: flight 14020 (fail), for first failure
 Repro found: flight 14021 (pass), for last pass
 Repro found: flight 14022 (fail), for first failure
 Repro found: flight 14023 (pass), for last pass
 Repro found: flight 14024 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
  Bug introduced:  4fc87c2f31a0
  Bug not present: c1c549c4fe9e

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   26060:4fc87c2f31a0
  user:        Huang Ying 
  date:        Tue Oct 16 17:26:36 2012 +0200
      
      ACPI: fix APEI related table size checking
      
      On Huang Ying's machine:
      
      erst_tab->header_length == sizeof(struct acpi_table_einj)
      
      but Yinghai reported that on his machine,
      
      erst_tab->header_length == sizeof(struct acpi_table_einj) -
      sizeof(struct acpi_table_header)
      
      To make erst table size checking code works on all systems, both
      testing are treated as PASS.
      
      Same situation applies to einj_tab->header_length, so corresponding
      table size checking is changed in similar way too.
      
      Originally-by: Yinghai Lu 
      Signed-off-by: Huang Ying 
      
      - use switch() for better readability
      - add comment explaining why a formally invalid size it also being
        accepted
      - check erst_tab->header.length before even looking at
        erst_tab->header_length
      - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
      
      Signed-off-by: Jan Beulich 
      Acked-by: Keir Fraser 
      Committed-by: Jan Beulich 
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-amd64-i386-rhel6hvm-amd.xen-boot.{dot,ps,png,html}.
----------------------------------------
14024: tolerable ALL FAIL

flight 14024 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14024/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                fail baseline untested


jobs:
 test-amd64-i386-rhel6hvm-amd                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 06:13:20 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 06:13:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOjLa-0000D1-7J; Thu, 18 Oct 2012 06:12:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOjLY-0000Cw-BX
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 06:12:44 +0000
Received: from [85.158.139.211:58021] by server-3.bemta-5.messagelabs.com id
	4D/46-28618-BDD9F705; Thu, 18 Oct 2012 06:12:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1350540762!22750470!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19278 invoked from network); 18 Oct 2012 06:12:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 06:12:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,605,1344211200"; d="scan'208";a="15244501"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 06:12:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 18 Oct 2012 07:12:42 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TOjLV-0004WX-UM;
	Thu, 18 Oct 2012 06:12:41 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TOjLV-0001Gk-Ti;
	Thu, 18 Oct 2012 07:12:41 +0100
To: 
Message-ID: 
From: xen.org 
Date: Thu, 18 Oct 2012 07:12:41 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete
	test-amd64-i386-rhel6hvm-amd
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-rhel6hvm-amd
test xen-boot

Tree: linux git://xenbits.xen.org/linux-pvops.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 http://xenbits.xen.org/hg/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
  Bug introduced:  4fc87c2f31a0
  Bug not present: c1c549c4fe9e


  changeset:   26060:4fc87c2f31a0
  user:        Huang Ying 
  date:        Tue Oct 16 17:26:36 2012 +0200
      
      ACPI: fix APEI related table size checking
      
      On Huang Ying's machine:
      
      erst_tab->header_length == sizeof(struct acpi_table_einj)
      
      but Yinghai reported that on his machine,
      
      erst_tab->header_length == sizeof(struct acpi_table_einj) -
      sizeof(struct acpi_table_header)
      
      To make erst table size checking code works on all systems, both
      testing are treated as PASS.
      
      Same situation applies to einj_tab->header_length, so corresponding
      table size checking is changed in similar way too.
      
      Originally-by: Yinghai Lu 
      Signed-off-by: Huang Ying 
      
      - use switch() for better readability
      - add comment explaining why a formally invalid size it also being
        accepted
      - check erst_tab->header.length before even looking at
        erst_tab->header_length
      - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
      
      Signed-off-by: Jan Beulich 
      Acked-by: Keir Fraser 
      Committed-by: Jan Beulich 
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-i386-rhel6hvm-amd.xen-boot.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 14017 fail [host=moss-bug] / 13967 [host=lace-bug] 13963 [host=potato-beetle] 13962 ok.
Failure / basis pass flights: 14017 / 13962
Tree: linux git://xenbits.xen.org/linux-pvops.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 http://xenbits.xen.org/hg/staging/xen-unstable.hg
Latest a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 5c402b905e00
Basis pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 e0e1350dfe9b
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#a938a246d34912423c560f475ccf1ce0c71d9d00-a938a246d34912423c560f475ccf1ce0c71d9d00 git://xenbits.xen.org/staging/qemu-xen-unstable.git#bacc0d302445c75f18f4c826750fb5853b60e7ca-bacc0d302445c75f18f4c826750fb5853b60e7ca git://xenbits.xen.org/staging/qemu-upstream-unstable.git#cdf4d2bb4006805f209712fbb8ed1f83127e9984-cdf4d2bb4006805f209712fbb8ed1f83127e9984 http://xenbits.xen.org/hg/staging/xen-unstable.hg#e0e1350dfe9b-5c402b905e00
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
Loaded 252 nodes in revision graph
Searching for test results:
 13958 [host=lace-bug]
 13960 [host=leaf-beetle]
 13967 [host=lace-bug]
 13962 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 e0e1350dfe9b
 13972 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 13963 [host=potato-beetle]
 13956 [host=potato-beetle]
 13964 []
 13973 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 13979 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 13997 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 14000 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
 13996 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 e0e1350dfe9b
 13998 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 177fdda0be56
 13995 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4b4c0c7a6031
 13999 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 37bb894121c7
 14001 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 1f4be6ee4619
 14007 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 5c402b905e00
 14011 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 5c402b905e00
 14018 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 e0e1350dfe9b
 14019 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 5c402b905e00
 14020 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 14017 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 5c402b905e00
 14021 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
 14022 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 14023 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
 14024 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
Searching for interesting versions
 Result found: flight 13962 (pass), for basis pass
 Result found: flight 14007 (fail), for basis failure
 Repro found: flight 14018 (pass), for basis pass
 Repro found: flight 14019 (fail), for basis failure
 0 revisions at a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
No revisions left to test, checking graph state.
 Result found: flight 14000 (pass), for last pass
 Result found: flight 14020 (fail), for first failure
 Repro found: flight 14021 (pass), for last pass
 Repro found: flight 14022 (fail), for first failure
 Repro found: flight 14023 (pass), for last pass
 Repro found: flight 14024 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
  Bug introduced:  4fc87c2f31a0
  Bug not present: c1c549c4fe9e

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   26060:4fc87c2f31a0
  user:        Huang Ying 
  date:        Tue Oct 16 17:26:36 2012 +0200
      
      ACPI: fix APEI related table size checking
      
      On Huang Ying's machine:
      
      erst_tab->header_length == sizeof(struct acpi_table_einj)
      
      but Yinghai reported that on his machine,
      
      erst_tab->header_length == sizeof(struct acpi_table_einj) -
      sizeof(struct acpi_table_header)
      
      To make erst table size checking code works on all systems, both
      testing are treated as PASS.
      
      Same situation applies to einj_tab->header_length, so corresponding
      table size checking is changed in similar way too.
      
      Originally-by: Yinghai Lu 
      Signed-off-by: Huang Ying 
      
      - use switch() for better readability
      - add comment explaining why a formally invalid size it also being
        accepted
      - check erst_tab->header.length before even looking at
        erst_tab->header_length
      - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
      
      Signed-off-by: Jan Beulich 
      Acked-by: Keir Fraser 
      Committed-by: Jan Beulich 
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-amd64-i386-rhel6hvm-amd.xen-boot.{dot,ps,png,html}.
----------------------------------------
14024: tolerable ALL FAIL

flight 14024 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14024/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                fail baseline untested


jobs:
 test-amd64-i386-rhel6hvm-amd                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 06:50:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 06:50:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOjvr-0000RT-SI; Thu, 18 Oct 2012 06:50:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOjvq-0000RO-39
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 06:50:14 +0000
Received: from [85.158.143.99:20342] by server-1.bemta-4.messagelabs.com id
	09/11-19134-5A6AF705; Thu, 18 Oct 2012 06:50:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1350543011!34234377!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20412 invoked from network); 18 Oct 2012 06:50:12 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-216.messagelabs.com with SMTP;
	18 Oct 2012 06:50:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 18 Oct 2012 07:50:34 +0100
Message-Id: <507FC2BF02000078000A2351@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 18 Oct 2012 07:50:07 +0100
From: "Jan Beulich" 
To: "Ian Campbell" 
References: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
	<1350314444-17148-9-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1350314444-17148-9-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser , Tim Deegan ,
	Stefano Stabellini , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 09/10] xen: remove XEN_GUEST_HANDLE(ulong)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.10.12 at 17:20, Ian Campbell  wrote:
> --- a/xen/include/public/grant_table.h
> +++ b/xen/include/public/grant_table.h
> @@ -385,7 +385,7 @@ struct gnttab_setup_table {
>      uint32_t nr_frames;
>      /* OUT parameters. */
>      int16_t  status;              /* => enum grant_status */
> -    XEN_GUEST_HANDLE(ulong) frame_list;
> +    XEN_GUEST_HANDLE(xen_pfn_t) frame_list;
>  };
>  typedef struct gnttab_setup_table gnttab_setup_table_t;
>  DEFINE_XEN_GUEST_HANDLE(gnttab_setup_table_t);
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -43,8 +43,6 @@ DEFINE_XEN_GUEST_HANDLE(char);
>  __DEFINE_XEN_GUEST_HANDLE(uchar, unsigned char);
>  DEFINE_XEN_GUEST_HANDLE(int);
>  __DEFINE_XEN_GUEST_HANDLE(uint,  unsigned int);
> -DEFINE_XEN_GUEST_HANDLE(long);
> -__DEFINE_XEN_GUEST_HANDLE(ulong, unsigned long);
>  DEFINE_XEN_GUEST_HANDLE(void);
>  
>  DEFINE_XEN_GUEST_HANDLE(uint64_t);

These two must be wrapped in __XEN_INTERFACE_VERSION__
conditionals (and __XEN_LATEST_INTERFACE_VERSION__ needs
to be bumped accordingly), since the various guest handles are
distinct types (i.e. consumers will fail to build if not updated).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 06:50:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 06:50:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOjvr-0000RT-SI; Thu, 18 Oct 2012 06:50:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOjvq-0000RO-39
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 06:50:14 +0000
Received: from [85.158.143.99:20342] by server-1.bemta-4.messagelabs.com id
	09/11-19134-5A6AF705; Thu, 18 Oct 2012 06:50:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1350543011!34234377!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20412 invoked from network); 18 Oct 2012 06:50:12 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-216.messagelabs.com with SMTP;
	18 Oct 2012 06:50:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 18 Oct 2012 07:50:34 +0100
Message-Id: <507FC2BF02000078000A2351@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 18 Oct 2012 07:50:07 +0100
From: "Jan Beulich" 
To: "Ian Campbell" 
References: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
	<1350314444-17148-9-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1350314444-17148-9-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser , Tim Deegan ,
	Stefano Stabellini , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 09/10] xen: remove XEN_GUEST_HANDLE(ulong)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 15.10.12 at 17:20, Ian Campbell  wrote:
> --- a/xen/include/public/grant_table.h
> +++ b/xen/include/public/grant_table.h
> @@ -385,7 +385,7 @@ struct gnttab_setup_table {
>      uint32_t nr_frames;
>      /* OUT parameters. */
>      int16_t  status;              /* => enum grant_status */
> -    XEN_GUEST_HANDLE(ulong) frame_list;
> +    XEN_GUEST_HANDLE(xen_pfn_t) frame_list;
>  };
>  typedef struct gnttab_setup_table gnttab_setup_table_t;
>  DEFINE_XEN_GUEST_HANDLE(gnttab_setup_table_t);
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -43,8 +43,6 @@ DEFINE_XEN_GUEST_HANDLE(char);
>  __DEFINE_XEN_GUEST_HANDLE(uchar, unsigned char);
>  DEFINE_XEN_GUEST_HANDLE(int);
>  __DEFINE_XEN_GUEST_HANDLE(uint,  unsigned int);
> -DEFINE_XEN_GUEST_HANDLE(long);
> -__DEFINE_XEN_GUEST_HANDLE(ulong, unsigned long);
>  DEFINE_XEN_GUEST_HANDLE(void);
>  
>  DEFINE_XEN_GUEST_HANDLE(uint64_t);

These two must be wrapped in __XEN_INTERFACE_VERSION__
conditionals (and __XEN_LATEST_INTERFACE_VERSION__ needs
to be bumped accordingly), since the various guest handles are
distinct types (i.e. consumers will fail to build if not updated).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 07:00:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 07:00:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOk5N-0000cw-35; Thu, 18 Oct 2012 07:00:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOk5M-0000cr-9c
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 07:00:04 +0000
Received: from [85.158.143.35:54253] by server-2.bemta-4.messagelabs.com id
	E3/1B-22268-3F8AF705; Thu, 18 Oct 2012 07:00:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1350543602!14166706!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4682 invoked from network); 18 Oct 2012 07:00:02 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-21.messagelabs.com with SMTP;
	18 Oct 2012 07:00:02 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 18 Oct 2012 08:00:47 +0100
Message-Id: <507FC51102000078000A235E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 18 Oct 2012 08:00:01 +0100
From: "Jan Beulich" 
To: "Stefan Bader" ,
	"Andrew Cooper" 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
	<1350482118.2460.74.camel@zakaz.uk.xensource.com>
	<507ECD06.2050407@canonical.com> <507ED038.8000806@citrix.com>
In-Reply-To: <507ED038.8000806@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk ,
	Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 17.10.12 at 17:35, Andrew Cooper  wrote:
> In each case, the event channels are masked (no surprise given the
> conversation so far on this thread), and have no pending events. 
> Therefore, I believe we are looking at the same bug.

That seems very unlikely (albeit not impossible) to me, given that
the non-pvops kernel uses ticket locks while the pvops one doesn't.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 07:00:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 07:00:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOk5N-0000cw-35; Thu, 18 Oct 2012 07:00:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOk5M-0000cr-9c
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 07:00:04 +0000
Received: from [85.158.143.35:54253] by server-2.bemta-4.messagelabs.com id
	E3/1B-22268-3F8AF705; Thu, 18 Oct 2012 07:00:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1350543602!14166706!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4682 invoked from network); 18 Oct 2012 07:00:02 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-21.messagelabs.com with SMTP;
	18 Oct 2012 07:00:02 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 18 Oct 2012 08:00:47 +0100
Message-Id: <507FC51102000078000A235E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 18 Oct 2012 08:00:01 +0100
From: "Jan Beulich" 
To: "Stefan Bader" ,
	"Andrew Cooper" 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
	<1350482118.2460.74.camel@zakaz.uk.xensource.com>
	<507ECD06.2050407@canonical.com> <507ED038.8000806@citrix.com>
In-Reply-To: <507ED038.8000806@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk ,
	Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 17.10.12 at 17:35, Andrew Cooper  wrote:
> In each case, the event channels are masked (no surprise given the
> conversation so far on this thread), and have no pending events. 
> Therefore, I believe we are looking at the same bug.

That seems very unlikely (albeit not impossible) to me, given that
the non-pvops kernel uses ticket locks while the pvops one doesn't.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 07:09:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 07:09:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOkDk-0000vr-Ve; Thu, 18 Oct 2012 07:08:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOkDj-0000vm-Np
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 07:08:43 +0000
Received: from [85.158.139.211:48710] by server-11.bemta-5.messagelabs.com id
	6A/6E-14870-AFAAF705; Thu, 18 Oct 2012 07:08:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1350544121!21258916!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1066 invoked from network); 18 Oct 2012 07:08:41 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-206.messagelabs.com with SMTP;
	18 Oct 2012 07:08:41 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 18 Oct 2012 08:10:18 +0100
Message-Id: <507FC71502000078000A236C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 18 Oct 2012 08:08:37 +0100
From: "Jan Beulich" 
To: "Stefan Bader" ,
 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
	<1350482118.2460.74.camel@zakaz.uk.xensource.com>
	<507ECD06.2050407@canonical.com> <507ED038.8000806@citrix.com>
	<507FC51102000078000A235E@nat28.tlf.novell.com>
In-Reply-To: <507FC51102000078000A235E@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk ,
	Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 18.10.12 at 09:00, "Jan Beulich"  wrote:
>>>> On 17.10.12 at 17:35, Andrew Cooper  wrote:
>> In each case, the event channels are masked (no surprise given the
>> conversation so far on this thread), and have no pending events. 
>> Therefore, I believe we are looking at the same bug.
> 
> That seems very unlikely (albeit not impossible) to me, given that
> the non-pvops kernel uses ticket locks while the pvops one doesn't.

And in fact we had a similar problem with our original ticket lock
implementation, exposed by an open coded lock in the scheduler's
run queue management. But that was really ticket lock specific,
in that the fact that a CPU could passively become the owner of
a lock while polling - that's impossible with pvops' byte locks afaict.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 07:09:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 07:09:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOkDk-0000vr-Ve; Thu, 18 Oct 2012 07:08:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOkDj-0000vm-Np
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 07:08:43 +0000
Received: from [85.158.139.211:48710] by server-11.bemta-5.messagelabs.com id
	6A/6E-14870-AFAAF705; Thu, 18 Oct 2012 07:08:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1350544121!21258916!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1066 invoked from network); 18 Oct 2012 07:08:41 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-206.messagelabs.com with SMTP;
	18 Oct 2012 07:08:41 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 18 Oct 2012 08:10:18 +0100
Message-Id: <507FC71502000078000A236C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 18 Oct 2012 08:08:37 +0100
From: "Jan Beulich" 
To: "Stefan Bader" ,
 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
	<1350482118.2460.74.camel@zakaz.uk.xensource.com>
	<507ECD06.2050407@canonical.com> <507ED038.8000806@citrix.com>
	<507FC51102000078000A235E@nat28.tlf.novell.com>
In-Reply-To: <507FC51102000078000A235E@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk ,
	Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 18.10.12 at 09:00, "Jan Beulich"  wrote:
>>>> On 17.10.12 at 17:35, Andrew Cooper  wrote:
>> In each case, the event channels are masked (no surprise given the
>> conversation so far on this thread), and have no pending events. 
>> Therefore, I believe we are looking at the same bug.
> 
> That seems very unlikely (albeit not impossible) to me, given that
> the non-pvops kernel uses ticket locks while the pvops one doesn't.

And in fact we had a similar problem with our original ticket lock
implementation, exposed by an open coded lock in the scheduler's
run queue management. But that was really ticket lock specific,
in that the fact that a CPU could passively become the owner of
a lock while polling - that's impossible with pvops' byte locks afaict.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 07:20:35 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 07:20:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOkOq-00016H-RF; Thu, 18 Oct 2012 07:20:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOkOp-00016C-EX
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 07:20:11 +0000
Received: from [85.158.137.99:41547] by server-6.bemta-3.messagelabs.com id
	16/AC-32375-AADAF705; Thu, 18 Oct 2012 07:20:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1350544809!16690773!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29157 invoked from network); 18 Oct 2012 07:20:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 07:20:10 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15245287"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 07:20:09 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 08:20:09 +0100
Message-ID: <1350544809.28188.5.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Mukesh Rathor 
Date: Thu, 18 Oct 2012 08:20:09 +0100
In-Reply-To: <20121017165718.683fa30f@mantra.us.oracle.com>
References: <1350473518.2460.58.camel@zakaz.uk.xensource.com>
	<1350473532-15863-6-git-send-email-ian.campbell@citrix.com>
	<20121017165718.683fa30f@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	"xen-devel@lists.xen.org" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 6/6] xen: x86 pvh: use
 XENMEM_add_to_physmap_range for foreign gmfn mappings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-18 at 00:57 +0100, Mukesh Rathor wrote:
> On Wed, 17 Oct 2012 12:32:12 +0100
> Ian Campbell  wrote:
> 
> > Squeezing the necessary fields into the existing XENMEM_add_to_physmap
> > interface was proving to be a bit tricky so we have decided to go with
> > a new interface upstream (the XENMAPSPACE_gmfn_foreign interface using
> > XENMEM_add_to_physmap was never committed anywhere). This interface
> > also allows for batching which was impossible to support at the same
> > time as foreign mfns in the old interface.
> > 
> > This reverts the relevant parts of "PVH: basic and header changes,
> > elfnote changes, ..." and followups and trivially converts
> > pvh_add_to_xen_p2m over.
> 
> 
> Hmm... I don't see xen side implementation of XENMEM_add_to_physmap_range,

I said in the 0/6 patch, but should have repeated here:

        The final patch requires that XENMEM_add_to_physmap_range be implemented
        for x86 on the hypervisor side. For inspiration the ARM version can be
        found at <1350314444-17148-1-git-send-email-ian.campbell@citrix.com>
        (and will likely be in xen-unstable soon).

In the end I checked it in yesterday.

> and since I've already got my patches tested and cut, I'm going to send
> them now. We can apply this change easily in konrad's tree.

Sure, no problem.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 07:20:35 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 07:20:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOkOq-00016H-RF; Thu, 18 Oct 2012 07:20:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOkOp-00016C-EX
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 07:20:11 +0000
Received: from [85.158.137.99:41547] by server-6.bemta-3.messagelabs.com id
	16/AC-32375-AADAF705; Thu, 18 Oct 2012 07:20:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1350544809!16690773!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29157 invoked from network); 18 Oct 2012 07:20:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 07:20:10 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15245287"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 07:20:09 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 08:20:09 +0100
Message-ID: <1350544809.28188.5.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Mukesh Rathor 
Date: Thu, 18 Oct 2012 08:20:09 +0100
In-Reply-To: <20121017165718.683fa30f@mantra.us.oracle.com>
References: <1350473518.2460.58.camel@zakaz.uk.xensource.com>
	<1350473532-15863-6-git-send-email-ian.campbell@citrix.com>
	<20121017165718.683fa30f@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	"xen-devel@lists.xen.org" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 6/6] xen: x86 pvh: use
 XENMEM_add_to_physmap_range for foreign gmfn mappings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-18 at 00:57 +0100, Mukesh Rathor wrote:
> On Wed, 17 Oct 2012 12:32:12 +0100
> Ian Campbell  wrote:
> 
> > Squeezing the necessary fields into the existing XENMEM_add_to_physmap
> > interface was proving to be a bit tricky so we have decided to go with
> > a new interface upstream (the XENMAPSPACE_gmfn_foreign interface using
> > XENMEM_add_to_physmap was never committed anywhere). This interface
> > also allows for batching which was impossible to support at the same
> > time as foreign mfns in the old interface.
> > 
> > This reverts the relevant parts of "PVH: basic and header changes,
> > elfnote changes, ..." and followups and trivially converts
> > pvh_add_to_xen_p2m over.
> 
> 
> Hmm... I don't see xen side implementation of XENMEM_add_to_physmap_range,

I said in the 0/6 patch, but should have repeated here:

        The final patch requires that XENMEM_add_to_physmap_range be implemented
        for x86 on the hypervisor side. For inspiration the ARM version can be
        found at <1350314444-17148-1-git-send-email-ian.campbell@citrix.com>
        (and will likely be in xen-unstable soon).

In the end I checked it in yesterday.

> and since I've already got my patches tested and cut, I'm going to send
> them now. We can apply this change easily in konrad's tree.

Sure, no problem.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 07:21:00 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 07:21:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOkPJ-000187-9q; Thu, 18 Oct 2012 07:20:41 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOkPH-00017p-CT
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 07:20:39 +0000
Received: from [193.109.254.147:6427] by server-4.bemta-14.messagelabs.com id
	B6/52-04248-6CDAF705; Thu, 18 Oct 2012 07:20:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1350544837!9019119!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30147 invoked from network); 18 Oct 2012 07:20:37 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-27.messagelabs.com with SMTP;
	18 Oct 2012 07:20:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 18 Oct 2012 08:22:51 +0100
Message-Id: <507FC9E202000078000A237E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 18 Oct 2012 08:20:34 +0100
From: "Jan Beulich" 
To: "Ronny Hegewald" 
References: <201210180049.56561.ronny.hegewald@online.de>
In-Reply-To: <201210180049.56561.ronny.hegewald@online.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/1] keep iommu disabled until iommu_setup
 is called
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 18.10.12 at 02:49, Ronny Hegewald  wrote:
> The iommu is enabled by default when xen is booting and later disabled in 
> iommu_setup() when no iommu is present.
> 
> But under some circumstances iommu-code can be called before iommu_setup() is 
> 
> processed. If there is no iommu available xen crashes.
> 
> This can happen for example when panic(...) is called that got introduced 
> with
> patch "x86-64: detect processors subject to AMD erratum #121 and refuse to 
> boot." since xen 4.1.3 and results in the following stacktrace:
> 
>    find_iommu_for_device
>    amd_iommu_ioapic_update_ire
>    timer_interrupt
>    enable_8259_A_irq
>    do_IRQ
>    printk_start_of_line
>    acpi_os_printf
>    io_apic_write
>    __ioapic_write_entry
>    ioapic_write_entry
>    __clear_IO_APIC_pin
>    clear_IO_APIC
>    disable_IO_APIC
>    __stop_this_cpu
>    smp_send_stop
>    machine_restart
>    panic
>    tasklet_schedule_on_cpu
>    display_cacheinfo
>    init_amd
>    generic_identify
>    identify_cpu
>    _start_xen
>    _high_start
> 
> 
> This patch fixes this by keeping the iommu disabled until iommu_setup() is 
> entered. 

The concept is plausible, but I'm not convinced that there aren't
any users of iommu_enabled that actually depend on it having
its final value after command line parsing, yet before
iommu_setup() gets called. Did you fully audit all users?

As to the patch itself, ...

> Signed-off-by: Ronny Hegewald@online.de 
> 
> --- xen/drivers/passthrough/iommu.c.org	2012-10-05 03:38:33.000000000 +0000
> +++ xen/drivers/passthrough/iommu.c	2012-10-17 22:58:07.000000000 +0000
> @@ -38,7 +38,7 @@
>   *   no-intremap                Disable VT-d Interrupt Remapping
>   */
>  custom_param("iommu", parse_iommu_param);
> -bool_t __read_mostly iommu_enabled = 1;
> +bool_t __read_mostly iommu_enabled = 0;

No initializer needed.

>  bool_t __read_mostly force_iommu;
>  bool_t __initdata iommu_dom0_strict;
>  bool_t __read_mostly iommu_verbose;
> @@ -51,6 +51,8 @@
>  bool_t __read_mostly amd_iommu_debug;
>  bool_t __read_mostly amd_iommu_perdev_intremap;
>  
> +bool_t iommu_enabled_default = 1;

__initdata. Also better placed alongside iommu_enabled (see
below for the naming).

> +
>  static void __init parse_iommu_param(char *s)
>  {
>      char *ss;
> @@ -61,7 +63,7 @@
>              *ss = '\0';
>  
>          if ( !parse_bool(s) )
> -            iommu_enabled = 0;
> +            iommu_enabled_default = 0;
>          else if ( !strcmp(s, "force") || !strcmp(s, "required") )
>              force_iommu = 1;
>          else if ( !strcmp(s, "workaround_bios_bug") )
> @@ -312,6 +314,7 @@
>  {
>      int rc = -ENODEV;
>      bool_t force_intremap = force_iommu && iommu_intremap;
> +    iommu_enabled = iommu_enabled_default;

Misplaced and pointless - just make the subsequent conditional
check the new variable instead of iommu_enabled (making quite
obvious that the chosen name is somewhat odd - iommu_enable
would probably be better).

Jan

>  
>      if ( iommu_dom0_strict )
>          iommu_passthrough = 0;
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 07:21:00 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 07:21:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOkPJ-000187-9q; Thu, 18 Oct 2012 07:20:41 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOkPH-00017p-CT
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 07:20:39 +0000
Received: from [193.109.254.147:6427] by server-4.bemta-14.messagelabs.com id
	B6/52-04248-6CDAF705; Thu, 18 Oct 2012 07:20:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1350544837!9019119!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30147 invoked from network); 18 Oct 2012 07:20:37 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-27.messagelabs.com with SMTP;
	18 Oct 2012 07:20:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 18 Oct 2012 08:22:51 +0100
Message-Id: <507FC9E202000078000A237E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 18 Oct 2012 08:20:34 +0100
From: "Jan Beulich" 
To: "Ronny Hegewald" 
References: <201210180049.56561.ronny.hegewald@online.de>
In-Reply-To: <201210180049.56561.ronny.hegewald@online.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/1] keep iommu disabled until iommu_setup
 is called
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 18.10.12 at 02:49, Ronny Hegewald  wrote:
> The iommu is enabled by default when xen is booting and later disabled in 
> iommu_setup() when no iommu is present.
> 
> But under some circumstances iommu-code can be called before iommu_setup() is 
> 
> processed. If there is no iommu available xen crashes.
> 
> This can happen for example when panic(...) is called that got introduced 
> with
> patch "x86-64: detect processors subject to AMD erratum #121 and refuse to 
> boot." since xen 4.1.3 and results in the following stacktrace:
> 
>    find_iommu_for_device
>    amd_iommu_ioapic_update_ire
>    timer_interrupt
>    enable_8259_A_irq
>    do_IRQ
>    printk_start_of_line
>    acpi_os_printf
>    io_apic_write
>    __ioapic_write_entry
>    ioapic_write_entry
>    __clear_IO_APIC_pin
>    clear_IO_APIC
>    disable_IO_APIC
>    __stop_this_cpu
>    smp_send_stop
>    machine_restart
>    panic
>    tasklet_schedule_on_cpu
>    display_cacheinfo
>    init_amd
>    generic_identify
>    identify_cpu
>    _start_xen
>    _high_start
> 
> 
> This patch fixes this by keeping the iommu disabled until iommu_setup() is 
> entered. 

The concept is plausible, but I'm not convinced that there aren't
any users of iommu_enabled that actually depend on it having
its final value after command line parsing, yet before
iommu_setup() gets called. Did you fully audit all users?

As to the patch itself, ...

> Signed-off-by: Ronny Hegewald@online.de 
> 
> --- xen/drivers/passthrough/iommu.c.org	2012-10-05 03:38:33.000000000 +0000
> +++ xen/drivers/passthrough/iommu.c	2012-10-17 22:58:07.000000000 +0000
> @@ -38,7 +38,7 @@
>   *   no-intremap                Disable VT-d Interrupt Remapping
>   */
>  custom_param("iommu", parse_iommu_param);
> -bool_t __read_mostly iommu_enabled = 1;
> +bool_t __read_mostly iommu_enabled = 0;

No initializer needed.

>  bool_t __read_mostly force_iommu;
>  bool_t __initdata iommu_dom0_strict;
>  bool_t __read_mostly iommu_verbose;
> @@ -51,6 +51,8 @@
>  bool_t __read_mostly amd_iommu_debug;
>  bool_t __read_mostly amd_iommu_perdev_intremap;
>  
> +bool_t iommu_enabled_default = 1;

__initdata. Also better placed alongside iommu_enabled (see
below for the naming).

> +
>  static void __init parse_iommu_param(char *s)
>  {
>      char *ss;
> @@ -61,7 +63,7 @@
>              *ss = '\0';
>  
>          if ( !parse_bool(s) )
> -            iommu_enabled = 0;
> +            iommu_enabled_default = 0;
>          else if ( !strcmp(s, "force") || !strcmp(s, "required") )
>              force_iommu = 1;
>          else if ( !strcmp(s, "workaround_bios_bug") )
> @@ -312,6 +314,7 @@
>  {
>      int rc = -ENODEV;
>      bool_t force_intremap = force_iommu && iommu_intremap;
> +    iommu_enabled = iommu_enabled_default;

Misplaced and pointless - just make the subsequent conditional
check the new variable instead of iommu_enabled (making quite
obvious that the chosen name is somewhat odd - iommu_enable
would probably be better).

Jan

>  
>      if ( iommu_dom0_strict )
>          iommu_passthrough = 0;
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 07:25:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 07:25:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOkTv-0001NS-8D; Thu, 18 Oct 2012 07:25:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOkTu-0001NL-0r
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 07:25:26 +0000
Received: from [193.109.254.147:36635] by server-7.bemta-14.messagelabs.com id
	31/45-24122-5EEAF705; Thu, 18 Oct 2012 07:25:25 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1350545112!13134992!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14556 invoked from network); 18 Oct 2012 07:25:12 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-3.tower-27.messagelabs.com with SMTP;
	18 Oct 2012 07:25:12 -0000
Received: from p5b2e3cc2.dip.t-dialin.net ([91.46.60.194] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from )
	id 1TOkTb-0004jF-Aq; Thu, 18 Oct 2012 07:25:07 +0000
Message-ID: <507FAECA.3070506@canonical.com>
Date: Thu, 18 Oct 2012 09:24:58 +0200
From: Stefan Bader 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Jan Beulich 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
	<1350482118.2460.74.camel@zakaz.uk.xensource.com>
	<507ECD06.2050407@canonical.com> <507ED038.8000806@citrix.com>
	<507FC51102000078000A235E@nat28.tlf.novell.com>
In-Reply-To: <507FC51102000078000A235E@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.5
Cc: Andrew Cooper ,
	"xen-devel@lists.xen.org" ,
	Ian Campbell ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============7345903983062252177=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============7345903983062252177==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enigA37A44F86644D73C29FE6627"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigA37A44F86644D73C29FE6627
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 18.10.2012 09:00, Jan Beulich wrote:
>>>> On 17.10.12 at 17:35, Andrew Cooper  wrot=
e:
>> In each case, the event channels are masked (no surprise given the
>> conversation so far on this thread), and have no pending events.=20
>> Therefore, I believe we are looking at the same bug.
>=20
> That seems very unlikely (albeit not impossible) to me, given that
> the non-pvops kernel uses ticket locks while the pvops one doesn't.

True, if classic 2.6.32 actually meant non-pvops. In my memory that was t=
he
version that first introduced them, so I assumed we talk about the same b=
ase.

The one I am looking at seems (as much info there is available right now,=
 but I
try to get confirmation from reporters running a non-paravirt-spinlock ke=
rnel on
a production load) to be related directly to the paravirtualized spinlock=

implementation for Xen.


--------------enigA37A44F86644D73C29FE6627
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBCgAGBQJQf67SAAoJEOhnXe7L7s6jfhwP/3FoP6zoFKnVfj5Ox108Sl0S
DZLVVpfO4oqlbvgfSE6qgJAZtyjMAnq3bduXN+nNwTrm59izwOcoR2sRHbrH80L7
97RlcUd5UK47tMracyuIuvHQYgrJv7K2zfRZyxvdYOEpItuhe8HR3AFQnrgTq3gu
d1TADmuqlCoPWqzpqOg/AVfn0lgPecI19H/vgWmIK684eygwRXmnwJKabl7XmPlp
7SbgbxoUbTBn7FM2WO4QaR9/YizPnBSqxgf0pt15i3TsvrPBG1sMvzNJf9HD37o3
D1PZbM7+P9Z3KbJlLnPf1Ij0vWZJCly1nE4+SiDa6YAnryEqbK90gAI87Ttr/o+B
n1XmrqSvuyuLImus/lJtWvV7Q132NDuQR4AqZ1jYxJQGc/Fesba8hb5BRw4AnZ1h
ZuAcXbwK4qFMrG5UgNRAqicMs+SqFI+m0ObvotbpxVZBmhb89zTWaOBkTKSeCorI
+7qJKr2a/gQsMspQgfOhvVI5Pmbwg310Md+rtEVY+ngm/eBydeKO285wKGot+GTR
pYyiexePT/gCLu3/6vs6Y7VHE5D5n+CBLigaPsPNc612LPK3WeUsc3prGMy8htGS
OWb+qn2GHf9vBk+iQlAcIw2JIqcRZnD8vuuEs0cxIk3y9E4jqhzcvgPwp2iLe5vR
Fy5rq6ECfFaVZZ96+exL
=+/BH
-----END PGP SIGNATURE-----

--------------enigA37A44F86644D73C29FE6627--


--===============7345903983062252177==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7345903983062252177==--


From xen-devel-bounces@lists.xen.org Thu Oct 18 07:25:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 07:25:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOkTv-0001NS-8D; Thu, 18 Oct 2012 07:25:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOkTu-0001NL-0r
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 07:25:26 +0000
Received: from [193.109.254.147:36635] by server-7.bemta-14.messagelabs.com id
	31/45-24122-5EEAF705; Thu, 18 Oct 2012 07:25:25 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1350545112!13134992!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14556 invoked from network); 18 Oct 2012 07:25:12 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-3.tower-27.messagelabs.com with SMTP;
	18 Oct 2012 07:25:12 -0000
Received: from p5b2e3cc2.dip.t-dialin.net ([91.46.60.194] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from )
	id 1TOkTb-0004jF-Aq; Thu, 18 Oct 2012 07:25:07 +0000
Message-ID: <507FAECA.3070506@canonical.com>
Date: Thu, 18 Oct 2012 09:24:58 +0200
From: Stefan Bader 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Jan Beulich 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
	<1350482118.2460.74.camel@zakaz.uk.xensource.com>
	<507ECD06.2050407@canonical.com> <507ED038.8000806@citrix.com>
	<507FC51102000078000A235E@nat28.tlf.novell.com>
In-Reply-To: <507FC51102000078000A235E@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.5
Cc: Andrew Cooper ,
	"xen-devel@lists.xen.org" ,
	Ian Campbell ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============7345903983062252177=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============7345903983062252177==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enigA37A44F86644D73C29FE6627"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigA37A44F86644D73C29FE6627
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 18.10.2012 09:00, Jan Beulich wrote:
>>>> On 17.10.12 at 17:35, Andrew Cooper  wrot=
e:
>> In each case, the event channels are masked (no surprise given the
>> conversation so far on this thread), and have no pending events.=20
>> Therefore, I believe we are looking at the same bug.
>=20
> That seems very unlikely (albeit not impossible) to me, given that
> the non-pvops kernel uses ticket locks while the pvops one doesn't.

True, if classic 2.6.32 actually meant non-pvops. In my memory that was t=
he
version that first introduced them, so I assumed we talk about the same b=
ase.

The one I am looking at seems (as much info there is available right now,=
 but I
try to get confirmation from reporters running a non-paravirt-spinlock ke=
rnel on
a production load) to be related directly to the paravirtualized spinlock=

implementation for Xen.


--------------enigA37A44F86644D73C29FE6627
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBCgAGBQJQf67SAAoJEOhnXe7L7s6jfhwP/3FoP6zoFKnVfj5Ox108Sl0S
DZLVVpfO4oqlbvgfSE6qgJAZtyjMAnq3bduXN+nNwTrm59izwOcoR2sRHbrH80L7
97RlcUd5UK47tMracyuIuvHQYgrJv7K2zfRZyxvdYOEpItuhe8HR3AFQnrgTq3gu
d1TADmuqlCoPWqzpqOg/AVfn0lgPecI19H/vgWmIK684eygwRXmnwJKabl7XmPlp
7SbgbxoUbTBn7FM2WO4QaR9/YizPnBSqxgf0pt15i3TsvrPBG1sMvzNJf9HD37o3
D1PZbM7+P9Z3KbJlLnPf1Ij0vWZJCly1nE4+SiDa6YAnryEqbK90gAI87Ttr/o+B
n1XmrqSvuyuLImus/lJtWvV7Q132NDuQR4AqZ1jYxJQGc/Fesba8hb5BRw4AnZ1h
ZuAcXbwK4qFMrG5UgNRAqicMs+SqFI+m0ObvotbpxVZBmhb89zTWaOBkTKSeCorI
+7qJKr2a/gQsMspQgfOhvVI5Pmbwg310Md+rtEVY+ngm/eBydeKO285wKGot+GTR
pYyiexePT/gCLu3/6vs6Y7VHE5D5n+CBLigaPsPNc612LPK3WeUsc3prGMy8htGS
OWb+qn2GHf9vBk+iQlAcIw2JIqcRZnD8vuuEs0cxIk3y9E4jqhzcvgPwp2iLe5vR
Fy5rq6ECfFaVZZ96+exL
=+/BH
-----END PGP SIGNATURE-----

--------------enigA37A44F86644D73C29FE6627--


--===============7345903983062252177==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7345903983062252177==--


From xen-devel-bounces@lists.xen.org Thu Oct 18 07:26:34 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 07:26:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOkUo-0001Sh-Pj; Thu, 18 Oct 2012 07:26:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOkUn-0001SM-0N
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 07:26:21 +0000
Received: from [85.158.143.99:33875] by server-3.bemta-4.messagelabs.com id
	9B/F3-03544-C1FAF705; Thu, 18 Oct 2012 07:26:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1350545177!27574969!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4681 invoked from network); 18 Oct 2012 07:26:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 07:26:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15245378"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 07:26:17 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 08:26:17 +0100
Message-ID: <1350545177.28188.8.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Thu, 18 Oct 2012 08:26:17 +0100
In-Reply-To: <20121017173249.GA25260@phenom.dumpdata.com>
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
	<1350463157-5068-9-git-send-email-ian.campbell@citrix.com>
	
	<20121017173249.GA25260@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 09/10] xen: balloon: use correct type for
	frame_list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-17 at 18:32 +0100, Konrad Rzeszutek Wilk wrote:
> On Wed, Oct 17, 2012 at 06:28:35PM +0100, Stefano Stabellini wrote:
> > On Wed, 17 Oct 2012, Ian Campbell wrote:
> > > This is now a xen_pfn_t.
> > > 
> > > Signed-off-by: Ian Campbell 
> > > ---
> > >  drivers/xen/balloon.c |    2 +-
> > >  1 files changed, 1 insertions(+), 1 deletions(-)
> > > 
> > > diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> > > index d7bd1b3..d6886d9 100644
> > > --- a/drivers/xen/balloon.c
> > > +++ b/drivers/xen/balloon.c
> > > @@ -87,7 +87,7 @@ struct balloon_stats balloon_stats;
> > >  EXPORT_SYMBOL_GPL(balloon_stats);
> > >  
> > >  /* We increase/decrease in batches which fit in a page */
> > > -static unsigned long frame_list[PAGE_SIZE / sizeof(unsigned long)];
> > > +static xen_pfn_t frame_list[PAGE_SIZE / sizeof(unsigned long)];
> > >  
> > >  #ifdef CONFIG_HIGHMEM
> > >  #define inc_totalhigh_pages() (totalhigh_pages++)
> > 
> > I know that we agreed to this change but it still gives me the creeps.
> > I would love a comment either in the code or in the commit message,
> > explaining why it is safe to pass a xen_pfn_t (potentially 64 bit) to 
> > set_phys_to_machine.
> 
> 
> I applied all the patches in this patchset except this one. Will
> apply once a new version is out.

The patch is better as an incremental one I think since it doesn't
really have much to do with this change in particular, really its a more
generic facet of Linux's (totally reasonable) choice of unsigned long
for pfns and not anything to do with Xen or p2ms or anything like that.
The comment below could just as well be in a generic location and read
"hardware might support more PFNs than the kernel is prepared to deal
with in its unsigned long pfns".

But whatever, here is a comment.

8<------------------------------------------------

>From 7bbf07e67b3b93680ee229a4a8e8edabdbea072e Mon Sep 17 00:00:00 2001
From: Ian Campbell 
Date: Thu, 18 Oct 2012 08:22:03 +0100
Subject: [PATCH] xen: arm: comment on why 64-bit xen_pfn_t is safe even on 32 bit

Signed-off-by: Ian Campbell 
---
 arch/arm/include/asm/xen/interface.h |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
index 007e6da..1151188 100644
--- a/arch/arm/include/asm/xen/interface.h
+++ b/arch/arm/include/asm/xen/interface.h
@@ -29,7 +29,13 @@
 
 #ifndef __ASSEMBLY__
 /* Explicitly size integers that represent pfns in the interface with
- * Xen so that we can have one ABI that works for 32 and 64 bit guests. */
+ * Xen so that we can have one ABI that works for 32 and 64 bit guests.
+ * Note that this means that the xen_pfn_t type may be capable of
+ * representing pfn's which the guest cannot represent in its own pfn
+ * type. However since pfn space is controlled by the guest this is
+ * fine since it simply wouldn't be able to create any sure pfns in
+ * the first place.
+ */
 typedef uint64_t xen_pfn_t;
 #define PRI_xen_pfn "llx"
 typedef uint64_t xen_ulong_t;
-- 
1.7.2.5





> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 07:26:34 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 07:26:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOkUo-0001Sh-Pj; Thu, 18 Oct 2012 07:26:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOkUn-0001SM-0N
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 07:26:21 +0000
Received: from [85.158.143.99:33875] by server-3.bemta-4.messagelabs.com id
	9B/F3-03544-C1FAF705; Thu, 18 Oct 2012 07:26:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1350545177!27574969!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4681 invoked from network); 18 Oct 2012 07:26:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 07:26:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15245378"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 07:26:17 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 08:26:17 +0100
Message-ID: <1350545177.28188.8.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Thu, 18 Oct 2012 08:26:17 +0100
In-Reply-To: <20121017173249.GA25260@phenom.dumpdata.com>
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
	<1350463157-5068-9-git-send-email-ian.campbell@citrix.com>
	
	<20121017173249.GA25260@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 09/10] xen: balloon: use correct type for
	frame_list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-17 at 18:32 +0100, Konrad Rzeszutek Wilk wrote:
> On Wed, Oct 17, 2012 at 06:28:35PM +0100, Stefano Stabellini wrote:
> > On Wed, 17 Oct 2012, Ian Campbell wrote:
> > > This is now a xen_pfn_t.
> > > 
> > > Signed-off-by: Ian Campbell 
> > > ---
> > >  drivers/xen/balloon.c |    2 +-
> > >  1 files changed, 1 insertions(+), 1 deletions(-)
> > > 
> > > diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> > > index d7bd1b3..d6886d9 100644
> > > --- a/drivers/xen/balloon.c
> > > +++ b/drivers/xen/balloon.c
> > > @@ -87,7 +87,7 @@ struct balloon_stats balloon_stats;
> > >  EXPORT_SYMBOL_GPL(balloon_stats);
> > >  
> > >  /* We increase/decrease in batches which fit in a page */
> > > -static unsigned long frame_list[PAGE_SIZE / sizeof(unsigned long)];
> > > +static xen_pfn_t frame_list[PAGE_SIZE / sizeof(unsigned long)];
> > >  
> > >  #ifdef CONFIG_HIGHMEM
> > >  #define inc_totalhigh_pages() (totalhigh_pages++)
> > 
> > I know that we agreed to this change but it still gives me the creeps.
> > I would love a comment either in the code or in the commit message,
> > explaining why it is safe to pass a xen_pfn_t (potentially 64 bit) to 
> > set_phys_to_machine.
> 
> 
> I applied all the patches in this patchset except this one. Will
> apply once a new version is out.

The patch is better as an incremental one I think since it doesn't
really have much to do with this change in particular, really its a more
generic facet of Linux's (totally reasonable) choice of unsigned long
for pfns and not anything to do with Xen or p2ms or anything like that.
The comment below could just as well be in a generic location and read
"hardware might support more PFNs than the kernel is prepared to deal
with in its unsigned long pfns".

But whatever, here is a comment.

8<------------------------------------------------

>From 7bbf07e67b3b93680ee229a4a8e8edabdbea072e Mon Sep 17 00:00:00 2001
From: Ian Campbell 
Date: Thu, 18 Oct 2012 08:22:03 +0100
Subject: [PATCH] xen: arm: comment on why 64-bit xen_pfn_t is safe even on 32 bit

Signed-off-by: Ian Campbell 
---
 arch/arm/include/asm/xen/interface.h |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
index 007e6da..1151188 100644
--- a/arch/arm/include/asm/xen/interface.h
+++ b/arch/arm/include/asm/xen/interface.h
@@ -29,7 +29,13 @@
 
 #ifndef __ASSEMBLY__
 /* Explicitly size integers that represent pfns in the interface with
- * Xen so that we can have one ABI that works for 32 and 64 bit guests. */
+ * Xen so that we can have one ABI that works for 32 and 64 bit guests.
+ * Note that this means that the xen_pfn_t type may be capable of
+ * representing pfn's which the guest cannot represent in its own pfn
+ * type. However since pfn space is controlled by the guest this is
+ * fine since it simply wouldn't be able to create any sure pfns in
+ * the first place.
+ */
 typedef uint64_t xen_pfn_t;
 #define PRI_xen_pfn "llx"
 typedef uint64_t xen_ulong_t;
-- 
1.7.2.5





> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 07:29:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 07:29:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOkXv-0001e9-Hf; Thu, 18 Oct 2012 07:29:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOkXu-0001e1-HS
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 07:29:34 +0000
Received: from [193.109.254.147:42409] by server-11.bemta-14.messagelabs.com
	id 2D/18-09558-DDFAF705; Thu, 18 Oct 2012 07:29:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1350545373!13690091!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31038 invoked from network); 18 Oct 2012 07:29:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 07:29:33 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15245442"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 07:29:32 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 08:29:32 +0100
Message-ID: <1350545372.28188.11.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Thu, 18 Oct 2012 08:29:32 +0100
In-Reply-To: 
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
	<1350463157-5068-5-git-send-email-ian.campbell@citrix.com>
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 05/10] xen: events: pirq_check_eoi_map is
	X86 specific
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-17 at 18:06 +0100, Stefano Stabellini wrote:
> On Wed, 17 Oct 2012, Ian Campbell wrote:
> > On ARM I see:
> > drivers/xen/events.c:280:13: warning: 'pirq_check_eoi_map' defined but not used
> > [-Wunused-function]
> > 
> > Signed-off-by: Ian Campbell 
> > Cc: Stefano Stabellini 
> 
> I hate the proliferation of #ifdefs but in this case it might be the
> only thing to do

I wondered if there was any chance that ARM might want need an eoi map
in the future? I suppose the real question is whether any future port
might want it -- to which the answer is unknowable until one shows up
but probably "yes" given enough architectures ;-)

Ian.

> 
> 
> >  drivers/xen/events.c |    4 ++++
> >  1 files changed, 4 insertions(+), 0 deletions(-)
> > 
> > diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> > index 59e10a1..912ac81 100644
> > --- a/drivers/xen/events.c
> > +++ b/drivers/xen/events.c
> > @@ -115,7 +115,9 @@ struct irq_info {
> >  #define PIRQ_SHAREABLE	(1 << 1)
> >  
> >  static int *evtchn_to_irq;
> > +#ifdef CONFIG_X86
> >  static unsigned long *pirq_eoi_map;
> > +#endif
> >  static bool (*pirq_needs_eoi)(unsigned irq);
> >  
> >  static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
> > @@ -277,10 +279,12 @@ static unsigned int cpu_from_evtchn(unsigned int evtchn)
> >  	return ret;
> >  }
> >  
> > +#ifdef CONFIG_X86
> >  static bool pirq_check_eoi_map(unsigned irq)
> >  {
> >  	return test_bit(pirq_from_irq(irq), pirq_eoi_map);
> >  }
> > +#endif
> >  
> >  static bool pirq_needs_eoi_flag(unsigned irq)
> >  {
> > -- 
> > 1.7.2.5
> > 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 07:29:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 07:29:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOkXv-0001e9-Hf; Thu, 18 Oct 2012 07:29:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOkXu-0001e1-HS
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 07:29:34 +0000
Received: from [193.109.254.147:42409] by server-11.bemta-14.messagelabs.com
	id 2D/18-09558-DDFAF705; Thu, 18 Oct 2012 07:29:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1350545373!13690091!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31038 invoked from network); 18 Oct 2012 07:29:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 07:29:33 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15245442"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 07:29:32 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 08:29:32 +0100
Message-ID: <1350545372.28188.11.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Thu, 18 Oct 2012 08:29:32 +0100
In-Reply-To: 
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
	<1350463157-5068-5-git-send-email-ian.campbell@citrix.com>
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 05/10] xen: events: pirq_check_eoi_map is
	X86 specific
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-17 at 18:06 +0100, Stefano Stabellini wrote:
> On Wed, 17 Oct 2012, Ian Campbell wrote:
> > On ARM I see:
> > drivers/xen/events.c:280:13: warning: 'pirq_check_eoi_map' defined but not used
> > [-Wunused-function]
> > 
> > Signed-off-by: Ian Campbell 
> > Cc: Stefano Stabellini 
> 
> I hate the proliferation of #ifdefs but in this case it might be the
> only thing to do

I wondered if there was any chance that ARM might want need an eoi map
in the future? I suppose the real question is whether any future port
might want it -- to which the answer is unknowable until one shows up
but probably "yes" given enough architectures ;-)

Ian.

> 
> 
> >  drivers/xen/events.c |    4 ++++
> >  1 files changed, 4 insertions(+), 0 deletions(-)
> > 
> > diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> > index 59e10a1..912ac81 100644
> > --- a/drivers/xen/events.c
> > +++ b/drivers/xen/events.c
> > @@ -115,7 +115,9 @@ struct irq_info {
> >  #define PIRQ_SHAREABLE	(1 << 1)
> >  
> >  static int *evtchn_to_irq;
> > +#ifdef CONFIG_X86
> >  static unsigned long *pirq_eoi_map;
> > +#endif
> >  static bool (*pirq_needs_eoi)(unsigned irq);
> >  
> >  static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
> > @@ -277,10 +279,12 @@ static unsigned int cpu_from_evtchn(unsigned int evtchn)
> >  	return ret;
> >  }
> >  
> > +#ifdef CONFIG_X86
> >  static bool pirq_check_eoi_map(unsigned irq)
> >  {
> >  	return test_bit(pirq_from_irq(irq), pirq_eoi_map);
> >  }
> > +#endif
> >  
> >  static bool pirq_needs_eoi_flag(unsigned irq)
> >  {
> > -- 
> > 1.7.2.5
> > 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 07:32:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 07:32:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOkaa-0001nG-6Z; Thu, 18 Oct 2012 07:32:20 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOkaY-0001n6-Mp
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 07:32:18 +0000
Received: from [193.109.254.147:62866] by server-11.bemta-14.messagelabs.com
	id 13/EA-09558-180BF705; Thu, 18 Oct 2012 07:32:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1350545523!5303821!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11512 invoked from network); 18 Oct 2012 07:32:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 07:32:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15245486"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 07:32:03 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 08:32:03 +0100
Message-ID: <1350545522.28188.12.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Thu, 18 Oct 2012 08:32:02 +0100
In-Reply-To: 
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
	<1350463157-5068-3-git-send-email-ian.campbell@citrix.com>
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 03/10] xen: sysfs: fix build warning.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-17 at 18:02 +0100, Stefano Stabellini wrote:
> On Wed, 17 Oct 2012, Ian Campbell wrote:
> > Define PRI macros for xen_ulong_t and xen_pfn_t and use to fix:
> > drivers/xen/sys-hypervisor.c:288:4: warning: format '%lx' expects argument of type 'long unsigned int', but argument 3 has type 'xen_ulong_t' [-Wformat]
> > 
> > Ideally this would use PRIx64 on ARM but these (or equivalent) don't
> > seem to be available in the kernel.
> 
> I don't think that the PRI macros are used at all in the kernel, so you
> can actually name and define these ones the way you like.

Sure, it's just a bit annoying to have the disconnect between "uint64_t"
and to pair it with "llx" instead of PRIx64. It might almost be better
to have typedef unsigned long long xen_pfn_t et al.

Anyway, lets stick with this for now.

> These definitions seem good to me.
> 
> 
> > Signed-off-by: Ian Campbell 
> > ---
> >  arch/arm/include/asm/xen/interface.h |    2 ++
> >  arch/x86/include/asm/xen/interface.h |    2 ++
> >  drivers/xen/sys-hypervisor.c         |    3 ++-
> >  3 files changed, 6 insertions(+), 1 deletions(-)
> > 
> > diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
> > index ae05e56..62160f2 100644
> > --- a/arch/arm/include/asm/xen/interface.h
> > +++ b/arch/arm/include/asm/xen/interface.h
> > @@ -31,7 +31,9 @@
> >  /* Explicitly size integers that represent pfns in the interface with
> >   * Xen so that we can have one ABI that works for 32 and 64 bit guests. */
> >  typedef uint64_t xen_pfn_t;
> > +#define PRI_xen_pfn "llx"
> >  typedef uint64_t xen_ulong_t;
> > +#define PRI_xen_ulong "llx"
> >  /* Guest handles for primitive C types. */
> >  __DEFINE_GUEST_HANDLE(uchar, unsigned char);
> >  __DEFINE_GUEST_HANDLE(uint,  unsigned int);
> > diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
> > index 6d2f75a..ab3c67c 100644
> > --- a/arch/x86/include/asm/xen/interface.h
> > +++ b/arch/x86/include/asm/xen/interface.h
> > @@ -51,7 +51,9 @@
> >   * with Xen so that on ARM we can have one ABI that works for 32 and 64
> >   * bit guests. */
> >  typedef unsigned long xen_pfn_t;
> > +#define PRI_xen_pfn "lx"
> >  typedef unsigned long xen_ulong_t;
> > +#define PRI_xen_ulong "lx"
> >  /* Guest handles for primitive C types. */
> >  __DEFINE_GUEST_HANDLE(uchar, unsigned char);
> >  __DEFINE_GUEST_HANDLE(uint,  unsigned int);
> > diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c
> > index 66a0a14..96453f8 100644
> > --- a/drivers/xen/sys-hypervisor.c
> > +++ b/drivers/xen/sys-hypervisor.c
> > @@ -285,7 +285,8 @@ static ssize_t virtual_start_show(struct hyp_sysfs_attr *attr, char *buffer)
> >  		ret = HYPERVISOR_xen_version(XENVER_platform_parameters,
> >  					     parms);
> >  		if (!ret)
> > -			ret = sprintf(buffer, "%lx\n", parms->virt_start);
> > +			ret = sprintf(buffer, "%"PRI_xen_ulong"\n",
> > +				      parms->virt_start);
> >  		kfree(parms);
> >  	}
> >  
> > -- 
> > 1.7.2.5
> > 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 07:32:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 07:32:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOkaa-0001nG-6Z; Thu, 18 Oct 2012 07:32:20 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOkaY-0001n6-Mp
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 07:32:18 +0000
Received: from [193.109.254.147:62866] by server-11.bemta-14.messagelabs.com
	id 13/EA-09558-180BF705; Thu, 18 Oct 2012 07:32:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1350545523!5303821!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11512 invoked from network); 18 Oct 2012 07:32:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 07:32:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15245486"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 07:32:03 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 08:32:03 +0100
Message-ID: <1350545522.28188.12.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Thu, 18 Oct 2012 08:32:02 +0100
In-Reply-To: 
References: <1350463138.2460.19.camel@zakaz.uk.xensource.com>
	<1350463157-5068-3-git-send-email-ian.campbell@citrix.com>
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 03/10] xen: sysfs: fix build warning.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-17 at 18:02 +0100, Stefano Stabellini wrote:
> On Wed, 17 Oct 2012, Ian Campbell wrote:
> > Define PRI macros for xen_ulong_t and xen_pfn_t and use to fix:
> > drivers/xen/sys-hypervisor.c:288:4: warning: format '%lx' expects argument of type 'long unsigned int', but argument 3 has type 'xen_ulong_t' [-Wformat]
> > 
> > Ideally this would use PRIx64 on ARM but these (or equivalent) don't
> > seem to be available in the kernel.
> 
> I don't think that the PRI macros are used at all in the kernel, so you
> can actually name and define these ones the way you like.

Sure, it's just a bit annoying to have the disconnect between "uint64_t"
and to pair it with "llx" instead of PRIx64. It might almost be better
to have typedef unsigned long long xen_pfn_t et al.

Anyway, lets stick with this for now.

> These definitions seem good to me.
> 
> 
> > Signed-off-by: Ian Campbell 
> > ---
> >  arch/arm/include/asm/xen/interface.h |    2 ++
> >  arch/x86/include/asm/xen/interface.h |    2 ++
> >  drivers/xen/sys-hypervisor.c         |    3 ++-
> >  3 files changed, 6 insertions(+), 1 deletions(-)
> > 
> > diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
> > index ae05e56..62160f2 100644
> > --- a/arch/arm/include/asm/xen/interface.h
> > +++ b/arch/arm/include/asm/xen/interface.h
> > @@ -31,7 +31,9 @@
> >  /* Explicitly size integers that represent pfns in the interface with
> >   * Xen so that we can have one ABI that works for 32 and 64 bit guests. */
> >  typedef uint64_t xen_pfn_t;
> > +#define PRI_xen_pfn "llx"
> >  typedef uint64_t xen_ulong_t;
> > +#define PRI_xen_ulong "llx"
> >  /* Guest handles for primitive C types. */
> >  __DEFINE_GUEST_HANDLE(uchar, unsigned char);
> >  __DEFINE_GUEST_HANDLE(uint,  unsigned int);
> > diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
> > index 6d2f75a..ab3c67c 100644
> > --- a/arch/x86/include/asm/xen/interface.h
> > +++ b/arch/x86/include/asm/xen/interface.h
> > @@ -51,7 +51,9 @@
> >   * with Xen so that on ARM we can have one ABI that works for 32 and 64
> >   * bit guests. */
> >  typedef unsigned long xen_pfn_t;
> > +#define PRI_xen_pfn "lx"
> >  typedef unsigned long xen_ulong_t;
> > +#define PRI_xen_ulong "lx"
> >  /* Guest handles for primitive C types. */
> >  __DEFINE_GUEST_HANDLE(uchar, unsigned char);
> >  __DEFINE_GUEST_HANDLE(uint,  unsigned int);
> > diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c
> > index 66a0a14..96453f8 100644
> > --- a/drivers/xen/sys-hypervisor.c
> > +++ b/drivers/xen/sys-hypervisor.c
> > @@ -285,7 +285,8 @@ static ssize_t virtual_start_show(struct hyp_sysfs_attr *attr, char *buffer)
> >  		ret = HYPERVISOR_xen_version(XENVER_platform_parameters,
> >  					     parms);
> >  		if (!ret)
> > -			ret = sprintf(buffer, "%lx\n", parms->virt_start);
> > +			ret = sprintf(buffer, "%"PRI_xen_ulong"\n",
> > +				      parms->virt_start);
> >  		kfree(parms);
> >  	}
> >  
> > -- 
> > 1.7.2.5
> > 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 07:32:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 07:32:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOkam-0001oV-KW; Thu, 18 Oct 2012 07:32:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOkak-0001oB-N7
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 07:32:30 +0000
Received: from [85.158.138.51:11238] by server-6.bemta-3.messagelabs.com id
	D1/4C-32375-D80BF705; Thu, 18 Oct 2012 07:32:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1350545549!27212766!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9511 invoked from network); 18 Oct 2012 07:32:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 07:32:29 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15245493"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 07:32:29 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 08:32:28 +0100
Message-ID: <1350545548.28188.13.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Jan Beulich 
Date: Thu, 18 Oct 2012 08:32:28 +0100
In-Reply-To: <507FC2BF02000078000A2351@nat28.tlf.novell.com>
References: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
	<1350314444-17148-9-git-send-email-ian.campbell@citrix.com>
	<507FC2BF02000078000A2351@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" ,
	"xen-devel@lists.xen.org" ,
	"Keir	\(Xen.org\)" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 09/10] xen: remove XEN_GUEST_HANDLE(ulong)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-18 at 07:50 +0100, Jan Beulich wrote:
> >>> On 15.10.12 at 17:20, Ian Campbell  wrote:
> > --- a/xen/include/public/grant_table.h
> > +++ b/xen/include/public/grant_table.h
> > @@ -385,7 +385,7 @@ struct gnttab_setup_table {
> >      uint32_t nr_frames;
> >      /* OUT parameters. */
> >      int16_t  status;              /* => enum grant_status */
> > -    XEN_GUEST_HANDLE(ulong) frame_list;
> > +    XEN_GUEST_HANDLE(xen_pfn_t) frame_list;
> >  };
> >  typedef struct gnttab_setup_table gnttab_setup_table_t;
> >  DEFINE_XEN_GUEST_HANDLE(gnttab_setup_table_t);
> > --- a/xen/include/public/xen.h
> > +++ b/xen/include/public/xen.h
> > @@ -43,8 +43,6 @@ DEFINE_XEN_GUEST_HANDLE(char);
> >  __DEFINE_XEN_GUEST_HANDLE(uchar, unsigned char);
> >  DEFINE_XEN_GUEST_HANDLE(int);
> >  __DEFINE_XEN_GUEST_HANDLE(uint,  unsigned int);
> > -DEFINE_XEN_GUEST_HANDLE(long);
> > -__DEFINE_XEN_GUEST_HANDLE(ulong, unsigned long);
> >  DEFINE_XEN_GUEST_HANDLE(void);
> >  
> >  DEFINE_XEN_GUEST_HANDLE(uint64_t);
> 
> These two must be wrapped in __XEN_INTERFACE_VERSION__
> conditionals (and __XEN_LATEST_INTERFACE_VERSION__ needs
> to be bumped accordingly), since the various guest handles are
> distinct types (i.e. consumers will fail to build if not updated).

Are there external consumers of gnttab_setup_table?

Nevertheless, here is the fix.

8<-----------------------------------------------------

# HG changeset patch
# User Ian Campbell 
# Date 1350544609 -3600
# Node ID 68f0f7ed3e7b3b7b4b9dbc692a448421ebc31035
# Parent  5c402b905e00fb0871c3f439c8391dd3cfb3bc10
xen: retain ulong guest handle for older consumers.

26072:5529b91bd2e4 removed this but we need to keep it around for
older consumers. Bump __XEN_LATEST_INTERFACE_VERSION__ accordingly.

Signed-off-by: Ian Campbell 

diff -r 5c402b905e00 -r 68f0f7ed3e7b xen/include/public/grant_table.h
--- a/xen/include/public/grant_table.h	Wed Oct 17 16:43:55 2012 +0100
+++ b/xen/include/public/grant_table.h	Thu Oct 18 08:16:49 2012 +0100
@@ -385,7 +385,11 @@ struct gnttab_setup_table {
     uint32_t nr_frames;
     /* OUT parameters. */
     int16_t  status;              /* => enum grant_status */
+#if __XEN_INTERFACE_VERSION__ < 0x00040300 
+    XEN_GUEST_HANDLE(ulong) frame_list;
+#else
     XEN_GUEST_HANDLE(xen_pfn_t) frame_list;
+#endif
 };
 typedef struct gnttab_setup_table gnttab_setup_table_t;
 DEFINE_XEN_GUEST_HANDLE(gnttab_setup_table_t);
diff -r 5c402b905e00 -r 68f0f7ed3e7b xen/include/public/xen-compat.h
--- a/xen/include/public/xen-compat.h	Wed Oct 17 16:43:55 2012 +0100
+++ b/xen/include/public/xen-compat.h	Thu Oct 18 08:16:49 2012 +0100
@@ -27,7 +27,7 @@
 #ifndef __XEN_PUBLIC_XEN_COMPAT_H__
 #define __XEN_PUBLIC_XEN_COMPAT_H__
 
-#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040200
+#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040300
 
 #if defined(__XEN__) || defined(__XEN_TOOLS__)
 /* Xen is built with matching headers and implements the latest interface. */
diff -r 5c402b905e00 -r 68f0f7ed3e7b xen/include/public/xen.h
--- a/xen/include/public/xen.h	Wed Oct 17 16:43:55 2012 +0100
+++ b/xen/include/public/xen.h	Thu Oct 18 08:16:49 2012 +0100
@@ -43,6 +43,10 @@ DEFINE_XEN_GUEST_HANDLE(char);
 __DEFINE_XEN_GUEST_HANDLE(uchar, unsigned char);
 DEFINE_XEN_GUEST_HANDLE(int);
 __DEFINE_XEN_GUEST_HANDLE(uint,  unsigned int);
+#if __XEN_INTERFACE_VERSION__ < 0x00040300 
+DEFINE_XEN_GUEST_HANDLE(long);
+__DEFINE_XEN_GUEST_HANDLE(ulong, unsigned long);
+#endif
 DEFINE_XEN_GUEST_HANDLE(void);
 
 DEFINE_XEN_GUEST_HANDLE(uint64_t);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 07:32:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 07:32:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOkam-0001oV-KW; Thu, 18 Oct 2012 07:32:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOkak-0001oB-N7
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 07:32:30 +0000
Received: from [85.158.138.51:11238] by server-6.bemta-3.messagelabs.com id
	D1/4C-32375-D80BF705; Thu, 18 Oct 2012 07:32:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1350545549!27212766!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9511 invoked from network); 18 Oct 2012 07:32:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 07:32:29 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15245493"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 07:32:29 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 08:32:28 +0100
Message-ID: <1350545548.28188.13.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Jan Beulich 
Date: Thu, 18 Oct 2012 08:32:28 +0100
In-Reply-To: <507FC2BF02000078000A2351@nat28.tlf.novell.com>
References: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
	<1350314444-17148-9-git-send-email-ian.campbell@citrix.com>
	<507FC2BF02000078000A2351@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" ,
	"xen-devel@lists.xen.org" ,
	"Keir	\(Xen.org\)" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 09/10] xen: remove XEN_GUEST_HANDLE(ulong)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-18 at 07:50 +0100, Jan Beulich wrote:
> >>> On 15.10.12 at 17:20, Ian Campbell  wrote:
> > --- a/xen/include/public/grant_table.h
> > +++ b/xen/include/public/grant_table.h
> > @@ -385,7 +385,7 @@ struct gnttab_setup_table {
> >      uint32_t nr_frames;
> >      /* OUT parameters. */
> >      int16_t  status;              /* => enum grant_status */
> > -    XEN_GUEST_HANDLE(ulong) frame_list;
> > +    XEN_GUEST_HANDLE(xen_pfn_t) frame_list;
> >  };
> >  typedef struct gnttab_setup_table gnttab_setup_table_t;
> >  DEFINE_XEN_GUEST_HANDLE(gnttab_setup_table_t);
> > --- a/xen/include/public/xen.h
> > +++ b/xen/include/public/xen.h
> > @@ -43,8 +43,6 @@ DEFINE_XEN_GUEST_HANDLE(char);
> >  __DEFINE_XEN_GUEST_HANDLE(uchar, unsigned char);
> >  DEFINE_XEN_GUEST_HANDLE(int);
> >  __DEFINE_XEN_GUEST_HANDLE(uint,  unsigned int);
> > -DEFINE_XEN_GUEST_HANDLE(long);
> > -__DEFINE_XEN_GUEST_HANDLE(ulong, unsigned long);
> >  DEFINE_XEN_GUEST_HANDLE(void);
> >  
> >  DEFINE_XEN_GUEST_HANDLE(uint64_t);
> 
> These two must be wrapped in __XEN_INTERFACE_VERSION__
> conditionals (and __XEN_LATEST_INTERFACE_VERSION__ needs
> to be bumped accordingly), since the various guest handles are
> distinct types (i.e. consumers will fail to build if not updated).

Are there external consumers of gnttab_setup_table?

Nevertheless, here is the fix.

8<-----------------------------------------------------

# HG changeset patch
# User Ian Campbell 
# Date 1350544609 -3600
# Node ID 68f0f7ed3e7b3b7b4b9dbc692a448421ebc31035
# Parent  5c402b905e00fb0871c3f439c8391dd3cfb3bc10
xen: retain ulong guest handle for older consumers.

26072:5529b91bd2e4 removed this but we need to keep it around for
older consumers. Bump __XEN_LATEST_INTERFACE_VERSION__ accordingly.

Signed-off-by: Ian Campbell 

diff -r 5c402b905e00 -r 68f0f7ed3e7b xen/include/public/grant_table.h
--- a/xen/include/public/grant_table.h	Wed Oct 17 16:43:55 2012 +0100
+++ b/xen/include/public/grant_table.h	Thu Oct 18 08:16:49 2012 +0100
@@ -385,7 +385,11 @@ struct gnttab_setup_table {
     uint32_t nr_frames;
     /* OUT parameters. */
     int16_t  status;              /* => enum grant_status */
+#if __XEN_INTERFACE_VERSION__ < 0x00040300 
+    XEN_GUEST_HANDLE(ulong) frame_list;
+#else
     XEN_GUEST_HANDLE(xen_pfn_t) frame_list;
+#endif
 };
 typedef struct gnttab_setup_table gnttab_setup_table_t;
 DEFINE_XEN_GUEST_HANDLE(gnttab_setup_table_t);
diff -r 5c402b905e00 -r 68f0f7ed3e7b xen/include/public/xen-compat.h
--- a/xen/include/public/xen-compat.h	Wed Oct 17 16:43:55 2012 +0100
+++ b/xen/include/public/xen-compat.h	Thu Oct 18 08:16:49 2012 +0100
@@ -27,7 +27,7 @@
 #ifndef __XEN_PUBLIC_XEN_COMPAT_H__
 #define __XEN_PUBLIC_XEN_COMPAT_H__
 
-#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040200
+#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040300
 
 #if defined(__XEN__) || defined(__XEN_TOOLS__)
 /* Xen is built with matching headers and implements the latest interface. */
diff -r 5c402b905e00 -r 68f0f7ed3e7b xen/include/public/xen.h
--- a/xen/include/public/xen.h	Wed Oct 17 16:43:55 2012 +0100
+++ b/xen/include/public/xen.h	Thu Oct 18 08:16:49 2012 +0100
@@ -43,6 +43,10 @@ DEFINE_XEN_GUEST_HANDLE(char);
 __DEFINE_XEN_GUEST_HANDLE(uchar, unsigned char);
 DEFINE_XEN_GUEST_HANDLE(int);
 __DEFINE_XEN_GUEST_HANDLE(uint,  unsigned int);
+#if __XEN_INTERFACE_VERSION__ < 0x00040300 
+DEFINE_XEN_GUEST_HANDLE(long);
+__DEFINE_XEN_GUEST_HANDLE(ulong, unsigned long);
+#endif
 DEFINE_XEN_GUEST_HANDLE(void);
 
 DEFINE_XEN_GUEST_HANDLE(uint64_t);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 07:38:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 07:38:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOkgK-00027u-Gy; Thu, 18 Oct 2012 07:38:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOkgJ-00027O-1G
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 07:38:15 +0000
Received: from [85.158.138.51:57141] by server-6.bemta-3.messagelabs.com id
	AC/F3-32375-6E1BF705; Thu, 18 Oct 2012 07:38:14 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1350545893!26794208!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25399 invoked from network); 18 Oct 2012 07:38:13 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-6.tower-174.messagelabs.com with SMTP;
	18 Oct 2012 07:38:13 -0000
Received: from p5b2e3cc2.dip.t-dialin.net ([91.46.60.194] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from )
	id 1TOkgE-000591-BY; Thu, 18 Oct 2012 07:38:10 +0000
Message-ID: <507FB1E1.8080700@canonical.com>
Date: Thu, 18 Oct 2012 09:38:09 +0200
From: Stefan Bader 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Jan Beulich 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
	<1350482118.2460.74.camel@zakaz.uk.xensource.com>
	<507ECD06.2050407@canonical.com> <507ED038.8000806@citrix.com>
	<507FC51102000078000A235E@nat28.tlf.novell.com>
	<507FC71502000078000A236C@nat28.tlf.novell.com>
In-Reply-To: <507FC71502000078000A236C@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.5
Cc: andrew.cooper3@citrix.com,
	"xen-devel@lists.xen.org" ,
	Ian Campbell ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============7481951078212515671=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============7481951078212515671==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig3DF9695B8064AD7EAA24E73A"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig3DF9695B8064AD7EAA24E73A
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 18.10.2012 09:08, Jan Beulich wrote:
>>>> On 18.10.12 at 09:00, "Jan Beulich"  wrote:
>>>>> On 17.10.12 at 17:35, Andrew Cooper  wro=
te:
>>> In each case, the event channels are masked (no surprise given the
>>> conversation so far on this thread), and have no pending events.=20
>>> Therefore, I believe we are looking at the same bug.
>>
>> That seems very unlikely (albeit not impossible) to me, given that
>> the non-pvops kernel uses ticket locks while the pvops one doesn't.
>=20
> And in fact we had a similar problem with our original ticket lock
> implementation, exposed by an open coded lock in the scheduler's
> run queue management. But that was really ticket lock specific,
> in that the fact that a CPU could passively become the owner of
> a lock while polling - that's impossible with pvops' byte locks afaict.=


One of the trains of thought I had was whether it could happen that a cpu=
 is in
polling and the task gets moved. But I don't think it can happen as the
hypercall unlikely is a place where any schedule happens (preempt is none=
). And
it would be much more common...

One detail which I hope someone can fill in is the whole "interrupted spi=
nlock"
thing. Saving the last lock pointer stored on the per-cpu lock_spinners a=
nd so
on. Is that really only for spinlocks taken without interrupts disabled o=
r do I
miss something there?




--------------enig3DF9695B8064AD7EAA24E73A
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBCgAGBQJQf7HhAAoJEOhnXe7L7s6j3rwP/0GcDz5m/WYhsWXr3JHG+cen
gCRGK2xfhaQI7ePzpRlZTU74wbaZNjvZXqpNe6ZA/+hy3unre8EfdeHFNJQkvkaK
kMCfQjdJga44rGc4JbAnLlv1enp7IgDxzGb/G/LjDP5Ao5sDyMRegJnftvQVBKn/
GYJRSebLXUM1ZaAvvGmHZRlgmKuGF0SJ37UhsAIT/4TeiqLRssyCTNPv71UkRFhp
0brip9LboFXUzpf7Wy6oqLIpdLBovnUmEC1hd81qVwZPgAALkwzde/wNLI+brMHO
URymCdKmZ9KsMvgxn+NXGKBu1k/P6gmYDKTksXY5YlloQFILO7KLSwyBIWiEC5HO
+Nxjppm5MEp2AUEGhQQrQVFdi2OwW+h1itjQRnU10BobtOpwgwCxlPJXzo+2BPQM
+eYNgf4+2jc6zvpnZn9cf2pAQL6pgGwhzcePVXuVErHbyX9BJDJJzsmWeR8yFq9q
BIiMQoueL3f+8jZ1qF5G0ZLtxqE7U4O7B7o2jhFmYBqru/7cfiEPAHsjnK37QCbp
ZyljRFi8mSZp7wLSvz1MGdr2Fpfuz8vxSQpTFy7XfPMGLdfIVKToURL6DRPZeFW1
VHd58C2KDv1pcVkyZrgptYfhExv34e1qDmwdMxRZw0+pLSpYR1r8Qz5XxmoQCY9Q
je+zk3eBcPD+EI4N87Su
=u/Ih
-----END PGP SIGNATURE-----

--------------enig3DF9695B8064AD7EAA24E73A--


--===============7481951078212515671==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7481951078212515671==--


From xen-devel-bounces@lists.xen.org Thu Oct 18 07:38:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 07:38:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOkgK-00027u-Gy; Thu, 18 Oct 2012 07:38:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOkgJ-00027O-1G
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 07:38:15 +0000
Received: from [85.158.138.51:57141] by server-6.bemta-3.messagelabs.com id
	AC/F3-32375-6E1BF705; Thu, 18 Oct 2012 07:38:14 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1350545893!26794208!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25399 invoked from network); 18 Oct 2012 07:38:13 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-6.tower-174.messagelabs.com with SMTP;
	18 Oct 2012 07:38:13 -0000
Received: from p5b2e3cc2.dip.t-dialin.net ([91.46.60.194] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from )
	id 1TOkgE-000591-BY; Thu, 18 Oct 2012 07:38:10 +0000
Message-ID: <507FB1E1.8080700@canonical.com>
Date: Thu, 18 Oct 2012 09:38:09 +0200
From: Stefan Bader 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Jan Beulich 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
	<1350482118.2460.74.camel@zakaz.uk.xensource.com>
	<507ECD06.2050407@canonical.com> <507ED038.8000806@citrix.com>
	<507FC51102000078000A235E@nat28.tlf.novell.com>
	<507FC71502000078000A236C@nat28.tlf.novell.com>
In-Reply-To: <507FC71502000078000A236C@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.5
Cc: andrew.cooper3@citrix.com,
	"xen-devel@lists.xen.org" ,
	Ian Campbell ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============7481951078212515671=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============7481951078212515671==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig3DF9695B8064AD7EAA24E73A"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig3DF9695B8064AD7EAA24E73A
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 18.10.2012 09:08, Jan Beulich wrote:
>>>> On 18.10.12 at 09:00, "Jan Beulich"  wrote:
>>>>> On 17.10.12 at 17:35, Andrew Cooper  wro=
te:
>>> In each case, the event channels are masked (no surprise given the
>>> conversation so far on this thread), and have no pending events.=20
>>> Therefore, I believe we are looking at the same bug.
>>
>> That seems very unlikely (albeit not impossible) to me, given that
>> the non-pvops kernel uses ticket locks while the pvops one doesn't.
>=20
> And in fact we had a similar problem with our original ticket lock
> implementation, exposed by an open coded lock in the scheduler's
> run queue management. But that was really ticket lock specific,
> in that the fact that a CPU could passively become the owner of
> a lock while polling - that's impossible with pvops' byte locks afaict.=


One of the trains of thought I had was whether it could happen that a cpu=
 is in
polling and the task gets moved. But I don't think it can happen as the
hypercall unlikely is a place where any schedule happens (preempt is none=
). And
it would be much more common...

One detail which I hope someone can fill in is the whole "interrupted spi=
nlock"
thing. Saving the last lock pointer stored on the per-cpu lock_spinners a=
nd so
on. Is that really only for spinlocks taken without interrupts disabled o=
r do I
miss something there?




--------------enig3DF9695B8064AD7EAA24E73A
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBCgAGBQJQf7HhAAoJEOhnXe7L7s6j3rwP/0GcDz5m/WYhsWXr3JHG+cen
gCRGK2xfhaQI7ePzpRlZTU74wbaZNjvZXqpNe6ZA/+hy3unre8EfdeHFNJQkvkaK
kMCfQjdJga44rGc4JbAnLlv1enp7IgDxzGb/G/LjDP5Ao5sDyMRegJnftvQVBKn/
GYJRSebLXUM1ZaAvvGmHZRlgmKuGF0SJ37UhsAIT/4TeiqLRssyCTNPv71UkRFhp
0brip9LboFXUzpf7Wy6oqLIpdLBovnUmEC1hd81qVwZPgAALkwzde/wNLI+brMHO
URymCdKmZ9KsMvgxn+NXGKBu1k/P6gmYDKTksXY5YlloQFILO7KLSwyBIWiEC5HO
+Nxjppm5MEp2AUEGhQQrQVFdi2OwW+h1itjQRnU10BobtOpwgwCxlPJXzo+2BPQM
+eYNgf4+2jc6zvpnZn9cf2pAQL6pgGwhzcePVXuVErHbyX9BJDJJzsmWeR8yFq9q
BIiMQoueL3f+8jZ1qF5G0ZLtxqE7U4O7B7o2jhFmYBqru/7cfiEPAHsjnK37QCbp
ZyljRFi8mSZp7wLSvz1MGdr2Fpfuz8vxSQpTFy7XfPMGLdfIVKToURL6DRPZeFW1
VHd58C2KDv1pcVkyZrgptYfhExv34e1qDmwdMxRZw0+pLSpYR1r8Qz5XxmoQCY9Q
je+zk3eBcPD+EI4N87Su
=u/Ih
-----END PGP SIGNATURE-----

--------------enig3DF9695B8064AD7EAA24E73A--


--===============7481951078212515671==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7481951078212515671==--


From xen-devel-bounces@lists.xen.org Thu Oct 18 07:40:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 07:40:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOkiQ-0002Fn-7L; Thu, 18 Oct 2012 07:40:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOkiO-0002Ff-FZ; Thu, 18 Oct 2012 07:40:24 +0000
Received: from [85.158.139.211:53927] by server-10.bemta-5.messagelabs.com id
	75/F1-01025-762BF705; Thu, 18 Oct 2012 07:40:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1350546022!22311559!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25350 invoked from network); 18 Oct 2012 07:40:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 07:40:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15245617"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 07:40:22 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 08:40:22 +0100
Message-ID: <1350546021.28188.20.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Keir Fraser 
Date: Thu, 18 Oct 2012 08:40:21 +0100
In-Reply-To: 
References: 
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge ,
	"xen-devel@lists.xensource.com" ,
	Dan Magenheimer , Mauro ,
	Olivier Hanesse ,
	Jan Beulich , Xen Users ,
	Mark Adams 
Subject: Re: [Xen-devel] [Xen-users]   Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-17 at 17:15 +0100, Keir Fraser wrote:
> @@ -540,6 +541,14 @@ static void plt_overflow(void *unused)
>          plt_wrap = __read_platform_stime(plt_stamp64 + plt_mask + 1);
>          if ( ABS(plt_wrap - now) > ABS(plt_now - now) )
>              break;
> +        rdtscll(tsc);
> +        printk("XXX plt_overflow: plt_now=%"PRIx64" plt_wrap=%"PRIx64
> +               " now=%"PRIx64" old_stamp=%"PRIx64" new_stamp=%"PRIx64
> +               " plt_stamp64=%"PRIx64" plt_mask=%"PRIx64
> +               " tsc=%"PRIx64" tsc_stamp=%"PRIx64"\n",
> +               plt_now, plt_wrap, now, old_stamp, plt_stamp, plt_stamp64,
> +               plt_mask, tsc, this_cpu(cpu_time).local_tsc_stamp);
> +        break;

Is the break here, making the following update to plt_stamp64 dead code
deliberate?

>          plt_stamp64 += plt_mask + 1;
>      }
>      if ( i != 0 )

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 07:40:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 07:40:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOkiQ-0002Fn-7L; Thu, 18 Oct 2012 07:40:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOkiO-0002Ff-FZ; Thu, 18 Oct 2012 07:40:24 +0000
Received: from [85.158.139.211:53927] by server-10.bemta-5.messagelabs.com id
	75/F1-01025-762BF705; Thu, 18 Oct 2012 07:40:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1350546022!22311559!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25350 invoked from network); 18 Oct 2012 07:40:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 07:40:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15245617"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 07:40:22 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 08:40:22 +0100
Message-ID: <1350546021.28188.20.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Keir Fraser 
Date: Thu, 18 Oct 2012 08:40:21 +0100
In-Reply-To: 
References: 
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge ,
	"xen-devel@lists.xensource.com" ,
	Dan Magenheimer , Mauro ,
	Olivier Hanesse ,
	Jan Beulich , Xen Users ,
	Mark Adams 
Subject: Re: [Xen-devel] [Xen-users]   Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-17 at 17:15 +0100, Keir Fraser wrote:
> @@ -540,6 +541,14 @@ static void plt_overflow(void *unused)
>          plt_wrap = __read_platform_stime(plt_stamp64 + plt_mask + 1);
>          if ( ABS(plt_wrap - now) > ABS(plt_now - now) )
>              break;
> +        rdtscll(tsc);
> +        printk("XXX plt_overflow: plt_now=%"PRIx64" plt_wrap=%"PRIx64
> +               " now=%"PRIx64" old_stamp=%"PRIx64" new_stamp=%"PRIx64
> +               " plt_stamp64=%"PRIx64" plt_mask=%"PRIx64
> +               " tsc=%"PRIx64" tsc_stamp=%"PRIx64"\n",
> +               plt_now, plt_wrap, now, old_stamp, plt_stamp, plt_stamp64,
> +               plt_mask, tsc, this_cpu(cpu_time).local_tsc_stamp);
> +        break;

Is the break here, making the following update to plt_stamp64 dead code
deliberate?

>          plt_stamp64 += plt_mask + 1;
>      }
>      if ( i != 0 )

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 07:42:48 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 07:42:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOkkW-0002UI-CL; Thu, 18 Oct 2012 07:42:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOkkU-0002U8-KA
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 07:42:34 +0000
Received: from [193.109.254.147:49202] by server-6.bemta-14.messagelabs.com id
	EC/06-17826-9E2BF705; Thu, 18 Oct 2012 07:42:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1350546153!2645090!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28260 invoked from network); 18 Oct 2012 07:42:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 07:42:33 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15245672"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 07:42:33 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 08:42:32 +0100
Message-ID: <1350546152.28188.22.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Ian Jackson 
Date: Thu, 18 Oct 2012 08:42:32 +0100
In-Reply-To: <20606.55597.190403.314007@mariner.uk.xensource.com>
References: 
	<22688187afa84747de9b.1350295794@cosworth.uk.xensource.com>
	<20606.55597.190403.314007@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "linux@eikelenboom.it" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 5 of 5] xl: Introduce helper macro for
	option parsing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-17 at 17:13 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH 5 of 5] xl: Introduce helper macro for option parsing"):
> > xl: Introduce helper macro for option parsing.
> 
> The idea is a reasonable one, but I have some quibbles.
> 
> > +#define FOREACH_OPT(_opt, _opts, _lopts, _help, _req)           \
> > +    while (((_opt) = def_getopt(argc, argv, (_opts), (_lopts),  \
> > +                                (_help), (_req))) != -1)        \
> > +        switch (opt)
> 
> This macro name should have the word SWITCH in it too so you know it
> has to take cases and that "break" doesn't do what you think.
> FOREACH_SWITCH_OPT maybe.

Good idea.

> 
> > @@ -2304,8 +2309,10 @@ int main_memmax(int argc, char **argv)
> >      char *mem;
> >      int rc;
> > 
> > -    if ((opt = def_getopt(argc, argv, "", NULL, "mem-max", 2)) != -1)
> > +    FOREACH_OPT(opt, "", NULL, "mem-max", 2) {
> > +    case 0: case 2:
> >          return opt;
> > +    }
> 
> This error handling behaviour (?) is rather opaque.  I RTFM
> getopt_long and AFAICT it returns 0 only for certain long options and
> it doesn't seem to mention returning 2.

2 comes from our existing implementation of def_getopt, which returns it
in the "not enough args" case. I don't think any callers differentiate
between that and 0 which is the other error indication though.

> Perhaps this would all be clearer if FOREACH_OPT had a big comment
> explaining how to use it.

Yes, will do.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 07:42:48 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 07:42:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOkkW-0002UI-CL; Thu, 18 Oct 2012 07:42:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOkkU-0002U8-KA
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 07:42:34 +0000
Received: from [193.109.254.147:49202] by server-6.bemta-14.messagelabs.com id
	EC/06-17826-9E2BF705; Thu, 18 Oct 2012 07:42:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1350546153!2645090!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28260 invoked from network); 18 Oct 2012 07:42:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 07:42:33 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15245672"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 07:42:33 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 08:42:32 +0100
Message-ID: <1350546152.28188.22.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Ian Jackson 
Date: Thu, 18 Oct 2012 08:42:32 +0100
In-Reply-To: <20606.55597.190403.314007@mariner.uk.xensource.com>
References: 
	<22688187afa84747de9b.1350295794@cosworth.uk.xensource.com>
	<20606.55597.190403.314007@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "linux@eikelenboom.it" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 5 of 5] xl: Introduce helper macro for
	option parsing
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-17 at 17:13 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH 5 of 5] xl: Introduce helper macro for option parsing"):
> > xl: Introduce helper macro for option parsing.
> 
> The idea is a reasonable one, but I have some quibbles.
> 
> > +#define FOREACH_OPT(_opt, _opts, _lopts, _help, _req)           \
> > +    while (((_opt) = def_getopt(argc, argv, (_opts), (_lopts),  \
> > +                                (_help), (_req))) != -1)        \
> > +        switch (opt)
> 
> This macro name should have the word SWITCH in it too so you know it
> has to take cases and that "break" doesn't do what you think.
> FOREACH_SWITCH_OPT maybe.

Good idea.

> 
> > @@ -2304,8 +2309,10 @@ int main_memmax(int argc, char **argv)
> >      char *mem;
> >      int rc;
> > 
> > -    if ((opt = def_getopt(argc, argv, "", NULL, "mem-max", 2)) != -1)
> > +    FOREACH_OPT(opt, "", NULL, "mem-max", 2) {
> > +    case 0: case 2:
> >          return opt;
> > +    }
> 
> This error handling behaviour (?) is rather opaque.  I RTFM
> getopt_long and AFAICT it returns 0 only for certain long options and
> it doesn't seem to mention returning 2.

2 comes from our existing implementation of def_getopt, which returns it
in the "not enough args" case. I don't think any callers differentiate
between that and 0 which is the other error indication though.

> Perhaps this would all be clearer if FOREACH_OPT had a big comment
> explaining how to use it.

Yes, will do.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 07:45:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 07:45:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOknW-0002kw-Vm; Thu, 18 Oct 2012 07:45:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOknV-0002kp-J6
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 07:45:41 +0000
Received: from [85.158.137.99:64975] by server-3.bemta-3.messagelabs.com id
	6E/72-09368-4A3BF705; Thu, 18 Oct 2012 07:45:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1350546339!19669648!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12986 invoked from network); 18 Oct 2012 07:45:40 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-217.messagelabs.com with SMTP;
	18 Oct 2012 07:45:40 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 18 Oct 2012 08:47:53 +0100
Message-Id: <507FCFC102000078000A23C7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 18 Oct 2012 08:45:37 +0100
From: "Jan Beulich" 
To: "xen-devel" 
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part457467B1.2__="
Cc: Wei Wang , Jinsong Liu ,
	christoph.egger@amd.com
Subject: [Xen-devel] [PATCH] ACPI/APEI: accept validly sized ERST on Intel
 systems only for now
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part457467B1.2__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Various AMD systems (but [unfortunately] not mine) hang when the table
size check passes. Allow the check to pass on Intel systems only for
now (until someone can actually debug the problem).

Signed-off-by: Jan Beulich 

--- a/xen/drivers/acpi/apei/erst.c
+++ b/xen/drivers/acpi/apei/erst.c
@@ -769,6 +769,19 @@ static int __init erst_check_table(struc
=20
 	switch (erst_tab->header_length) {
 	case sizeof(*erst_tab) - sizeof(erst_tab->header):
+#ifdef CONFIG_X86
+		/* XXX
+		 * While the rest of the ERST code appears to work on =
Intel
+		 * systems with properly sized tables, various AMD systems
+		 * appear to get hung (at boot time) by allowing this. =
Until
+		 * someone with access to suitable hardware can debug =
this,
+		 * disable the rest of the code by considering this case
+		 * invalid.
+		 */
+		if (boot_cpu_data.x86_vendor !=3D X86_VENDOR_INTEL)
+			return -EINVAL;
+		/* fall through */
+#endif
 	/*
 	 * While invalid per specification, there are (early?) systems
 	 * indicating the full header size here, so accept that value too.




--=__Part457467B1.2__=
Content-Type: text/plain; name="ACPI-ERST-Intel-only.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="ACPI-ERST-Intel-only.patch"

ACPI/APEI: accept validly sized ERST on Intel systems only for now=0A=0AVar=
ious AMD systems (but [unfortunately] not mine) hang when the table=0Asize =
check passes. Allow the check to pass on Intel systems only for=0Anow =
(until someone can actually debug the problem).=0A=0ASigned-off-by: Jan =
Beulich =0A=0A--- a/xen/drivers/acpi/apei/erst.c=0A+++ =
b/xen/drivers/acpi/apei/erst.c=0A@@ -769,6 +769,19 @@ static int __init =
erst_check_table(struc=0A =0A 	switch (erst_tab->header_length) {=0A 	=
case sizeof(*erst_tab) - sizeof(erst_tab->header):=0A+#ifdef CONFIG_X86=0A+=
		/* XXX=0A+		 * While the rest of the ERST code =
appears to work on Intel=0A+		 * systems with properly sized =
tables, various AMD systems=0A+		 * appear to get hung (at boot =
time) by allowing this. Until=0A+		 * someone with access to =
suitable hardware can debug this,=0A+		 * disable the rest of the =
code by considering this case=0A+		 * invalid.=0A+		 =
*/=0A+		if (boot_cpu_data.x86_vendor !=3D X86_VENDOR_INTEL)=0A+		=
	return -EINVAL;=0A+		/* fall through */=0A+#endif=0A 	=
/*=0A 	 * While invalid per specification, there are (early?) systems=0A 	=
 * indicating the full header size here, so accept that value too.=0A
--=__Part457467B1.2__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__Part457467B1.2__=--


From xen-devel-bounces@lists.xen.org Thu Oct 18 07:45:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 07:45:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOknW-0002kw-Vm; Thu, 18 Oct 2012 07:45:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOknV-0002kp-J6
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 07:45:41 +0000
Received: from [85.158.137.99:64975] by server-3.bemta-3.messagelabs.com id
	6E/72-09368-4A3BF705; Thu, 18 Oct 2012 07:45:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1350546339!19669648!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12986 invoked from network); 18 Oct 2012 07:45:40 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-217.messagelabs.com with SMTP;
	18 Oct 2012 07:45:40 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 18 Oct 2012 08:47:53 +0100
Message-Id: <507FCFC102000078000A23C7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 18 Oct 2012 08:45:37 +0100
From: "Jan Beulich" 
To: "xen-devel" 
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part457467B1.2__="
Cc: Wei Wang , Jinsong Liu ,
	christoph.egger@amd.com
Subject: [Xen-devel] [PATCH] ACPI/APEI: accept validly sized ERST on Intel
 systems only for now
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part457467B1.2__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Various AMD systems (but [unfortunately] not mine) hang when the table
size check passes. Allow the check to pass on Intel systems only for
now (until someone can actually debug the problem).

Signed-off-by: Jan Beulich 

--- a/xen/drivers/acpi/apei/erst.c
+++ b/xen/drivers/acpi/apei/erst.c
@@ -769,6 +769,19 @@ static int __init erst_check_table(struc
=20
 	switch (erst_tab->header_length) {
 	case sizeof(*erst_tab) - sizeof(erst_tab->header):
+#ifdef CONFIG_X86
+		/* XXX
+		 * While the rest of the ERST code appears to work on =
Intel
+		 * systems with properly sized tables, various AMD systems
+		 * appear to get hung (at boot time) by allowing this. =
Until
+		 * someone with access to suitable hardware can debug =
this,
+		 * disable the rest of the code by considering this case
+		 * invalid.
+		 */
+		if (boot_cpu_data.x86_vendor !=3D X86_VENDOR_INTEL)
+			return -EINVAL;
+		/* fall through */
+#endif
 	/*
 	 * While invalid per specification, there are (early?) systems
 	 * indicating the full header size here, so accept that value too.




--=__Part457467B1.2__=
Content-Type: text/plain; name="ACPI-ERST-Intel-only.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="ACPI-ERST-Intel-only.patch"

ACPI/APEI: accept validly sized ERST on Intel systems only for now=0A=0AVar=
ious AMD systems (but [unfortunately] not mine) hang when the table=0Asize =
check passes. Allow the check to pass on Intel systems only for=0Anow =
(until someone can actually debug the problem).=0A=0ASigned-off-by: Jan =
Beulich =0A=0A--- a/xen/drivers/acpi/apei/erst.c=0A+++ =
b/xen/drivers/acpi/apei/erst.c=0A@@ -769,6 +769,19 @@ static int __init =
erst_check_table(struc=0A =0A 	switch (erst_tab->header_length) {=0A 	=
case sizeof(*erst_tab) - sizeof(erst_tab->header):=0A+#ifdef CONFIG_X86=0A+=
		/* XXX=0A+		 * While the rest of the ERST code =
appears to work on Intel=0A+		 * systems with properly sized =
tables, various AMD systems=0A+		 * appear to get hung (at boot =
time) by allowing this. Until=0A+		 * someone with access to =
suitable hardware can debug this,=0A+		 * disable the rest of the =
code by considering this case=0A+		 * invalid.=0A+		 =
*/=0A+		if (boot_cpu_data.x86_vendor !=3D X86_VENDOR_INTEL)=0A+		=
	return -EINVAL;=0A+		/* fall through */=0A+#endif=0A 	=
/*=0A 	 * While invalid per specification, there are (early?) systems=0A 	=
 * indicating the full header size here, so accept that value too.=0A
--=__Part457467B1.2__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__Part457467B1.2__=--


From xen-devel-bounces@lists.xen.org Thu Oct 18 07:48:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 07:48:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOkpr-0002tX-HD; Thu, 18 Oct 2012 07:48:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOkpq-0002tP-4i
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 07:48:06 +0000
Received: from [85.158.137.99:42817] by server-16.bemta-3.messagelabs.com id
	3C/A8-16565-534BF705; Thu, 18 Oct 2012 07:48:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1350546484!22036927!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6565 invoked from network); 18 Oct 2012 07:48:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 07:48:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15245767"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 07:48:04 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 08:48:04 +0100
Message-ID: <1350546483.28188.25.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Stefan Bader 
Date: Thu, 18 Oct 2012 08:48:03 +0100
In-Reply-To: <507FB1E1.8080700@canonical.com>
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
	<1350482118.2460.74.camel@zakaz.uk.xensource.com>
	<507ECD06.2050407@canonical.com> <507ED038.8000806@citrix.com>
	<507FC51102000078000A235E@nat28.tlf.novell.com>
	<507FC71502000078000A236C@nat28.tlf.novell.com>
	<507FB1E1.8080700@canonical.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Andrew Cooper ,
	"xen-devel@lists.xen.org" ,
	Jan Beulich ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-18 at 08:38 +0100, Stefan Bader wrote:
> On 18.10.2012 09:08, Jan Beulich wrote:
> >>>> On 18.10.12 at 09:00, "Jan Beulich"  wrote:
> >>>>> On 17.10.12 at 17:35, Andrew Cooper  wrote:
> >>> In each case, the event channels are masked (no surprise given the
> >>> conversation so far on this thread), and have no pending events. 
> >>> Therefore, I believe we are looking at the same bug.
> >>
> >> That seems very unlikely (albeit not impossible) to me, given that
> >> the non-pvops kernel uses ticket locks while the pvops one doesn't.
> > 
> > And in fact we had a similar problem with our original ticket lock
> > implementation, exposed by an open coded lock in the scheduler's
> > run queue management. But that was really ticket lock specific,
> > in that the fact that a CPU could passively become the owner of
> > a lock while polling - that's impossible with pvops' byte locks afaict.
> 
> One of the trains of thought I had was whether it could happen that a cpu is in
> polling and the task gets moved. But I don't think it can happen as the
> hypercall unlikely is a place where any schedule happens (preempt is none). And
> it would be much more common...
> 
> One detail which I hope someone can fill in is the whole "interrupted spinlock"
> thing. Saving the last lock pointer stored on the per-cpu lock_spinners and so
> on. Is that really only for spinlocks taken without interrupts disabled or do I
> miss something there?

spinning_lock() returns the old lock which the caller is expected to
remember and replace via unspinning_lock() -- it effectively implements
a stack of locks which are being waited on. xen_spin_lock_slow (the only
caller0 appears to do this correctly from a brief inspection.

Is there any chance this is just a simple AB-BA or similar type
deadlock? Do we have data which suggests all vCPUs are waiting on the
same lock or just that they are waiting on some lock? I suppose lockdep
(which I think you mentioned before?) would have caught this, unless pv
locks somehow confound it?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 07:48:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 07:48:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOkpr-0002tX-HD; Thu, 18 Oct 2012 07:48:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOkpq-0002tP-4i
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 07:48:06 +0000
Received: from [85.158.137.99:42817] by server-16.bemta-3.messagelabs.com id
	3C/A8-16565-534BF705; Thu, 18 Oct 2012 07:48:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1350546484!22036927!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6565 invoked from network); 18 Oct 2012 07:48:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 07:48:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15245767"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 07:48:04 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 08:48:04 +0100
Message-ID: <1350546483.28188.25.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Stefan Bader 
Date: Thu, 18 Oct 2012 08:48:03 +0100
In-Reply-To: <507FB1E1.8080700@canonical.com>
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
	<1350482118.2460.74.camel@zakaz.uk.xensource.com>
	<507ECD06.2050407@canonical.com> <507ED038.8000806@citrix.com>
	<507FC51102000078000A235E@nat28.tlf.novell.com>
	<507FC71502000078000A236C@nat28.tlf.novell.com>
	<507FB1E1.8080700@canonical.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Andrew Cooper ,
	"xen-devel@lists.xen.org" ,
	Jan Beulich ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-18 at 08:38 +0100, Stefan Bader wrote:
> On 18.10.2012 09:08, Jan Beulich wrote:
> >>>> On 18.10.12 at 09:00, "Jan Beulich"  wrote:
> >>>>> On 17.10.12 at 17:35, Andrew Cooper  wrote:
> >>> In each case, the event channels are masked (no surprise given the
> >>> conversation so far on this thread), and have no pending events. 
> >>> Therefore, I believe we are looking at the same bug.
> >>
> >> That seems very unlikely (albeit not impossible) to me, given that
> >> the non-pvops kernel uses ticket locks while the pvops one doesn't.
> > 
> > And in fact we had a similar problem with our original ticket lock
> > implementation, exposed by an open coded lock in the scheduler's
> > run queue management. But that was really ticket lock specific,
> > in that the fact that a CPU could passively become the owner of
> > a lock while polling - that's impossible with pvops' byte locks afaict.
> 
> One of the trains of thought I had was whether it could happen that a cpu is in
> polling and the task gets moved. But I don't think it can happen as the
> hypercall unlikely is a place where any schedule happens (preempt is none). And
> it would be much more common...
> 
> One detail which I hope someone can fill in is the whole "interrupted spinlock"
> thing. Saving the last lock pointer stored on the per-cpu lock_spinners and so
> on. Is that really only for spinlocks taken without interrupts disabled or do I
> miss something there?

spinning_lock() returns the old lock which the caller is expected to
remember and replace via unspinning_lock() -- it effectively implements
a stack of locks which are being waited on. xen_spin_lock_slow (the only
caller0 appears to do this correctly from a brief inspection.

Is there any chance this is just a simple AB-BA or similar type
deadlock? Do we have data which suggests all vCPUs are waiting on the
same lock or just that they are waiting on some lock? I suppose lockdep
(which I think you mentioned before?) would have caught this, unless pv
locks somehow confound it?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 07:50:34 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 07:50:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOks4-00033H-8X; Thu, 18 Oct 2012 07:50:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOks2-000335-Hv
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 07:50:22 +0000
Received: from [85.158.137.99:28836] by server-14.bemta-3.messagelabs.com id
	8B/F0-17276-DB4BF705; Thu, 18 Oct 2012 07:50:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1350546620!16695230!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29392 invoked from network); 18 Oct 2012 07:50:20 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-217.messagelabs.com with SMTP;
	18 Oct 2012 07:50:20 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 18 Oct 2012 08:52:34 +0100
Message-Id: <507FD0D902000078000A23CA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 18 Oct 2012 08:50:17 +0100
From: "Jan Beulich" 
To: "Ian Campbell" 
References: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
	<1350314444-17148-9-git-send-email-ian.campbell@citrix.com>
	<507FC2BF02000078000A2351@nat28.tlf.novell.com>
	<1350545548.28188.13.camel@dagon.hellion.org.uk>
In-Reply-To: <1350545548.28188.13.camel@dagon.hellion.org.uk>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Tim \(Xen.org\)" ,
	"xen-devel@lists.xen.org" ,
	"Keir \(Xen.org\)" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 09/10] xen: remove XEN_GUEST_HANDLE(ulong)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 18.10.12 at 09:32, Ian Campbell  wrote:
> On Thu, 2012-10-18 at 07:50 +0100, Jan Beulich wrote:
>> >>> On 15.10.12 at 17:20, Ian Campbell  wrote:
>> These two must be wrapped in __XEN_INTERFACE_VERSION__
>> conditionals (and __XEN_LATEST_INTERFACE_VERSION__ needs
>> to be bumped accordingly), since the various guest handles are
>> distinct types (i.e. consumers will fail to build if not updated).
> 
> Are there external consumers of gnttab_setup_table?

We can't know - it's a public, not tools-only interface.

> Nevertheless, here is the fix.
> 
> 8<-----------------------------------------------------
> 
> # HG changeset patch
> # User Ian Campbell 
> # Date 1350544609 -3600
> # Node ID 68f0f7ed3e7b3b7b4b9dbc692a448421ebc31035
> # Parent  5c402b905e00fb0871c3f439c8391dd3cfb3bc10
> xen: retain ulong guest handle for older consumers.
> 
> 26072:5529b91bd2e4 removed this but we need to keep it around for
> older consumers. Bump __XEN_LATEST_INTERFACE_VERSION__ accordingly.
> 
> Signed-off-by: Ian Campbell 

Acked-by: Jan Beulich 

> diff -r 5c402b905e00 -r 68f0f7ed3e7b xen/include/public/grant_table.h
> --- a/xen/include/public/grant_table.h	Wed Oct 17 16:43:55 2012 +0100
> +++ b/xen/include/public/grant_table.h	Thu Oct 18 08:16:49 2012 +0100
> @@ -385,7 +385,11 @@ struct gnttab_setup_table {
>      uint32_t nr_frames;
>      /* OUT parameters. */
>      int16_t  status;              /* => enum grant_status */
> +#if __XEN_INTERFACE_VERSION__ < 0x00040300 
> +    XEN_GUEST_HANDLE(ulong) frame_list;
> +#else
>      XEN_GUEST_HANDLE(xen_pfn_t) frame_list;
> +#endif
>  };
>  typedef struct gnttab_setup_table gnttab_setup_table_t;
>  DEFINE_XEN_GUEST_HANDLE(gnttab_setup_table_t);
> diff -r 5c402b905e00 -r 68f0f7ed3e7b xen/include/public/xen-compat.h
> --- a/xen/include/public/xen-compat.h	Wed Oct 17 16:43:55 2012 +0100
> +++ b/xen/include/public/xen-compat.h	Thu Oct 18 08:16:49 2012 +0100
> @@ -27,7 +27,7 @@
>  #ifndef __XEN_PUBLIC_XEN_COMPAT_H__
>  #define __XEN_PUBLIC_XEN_COMPAT_H__
>  
> -#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040200
> +#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040300
>  
>  #if defined(__XEN__) || defined(__XEN_TOOLS__)
>  /* Xen is built with matching headers and implements the latest interface. 
> */
> diff -r 5c402b905e00 -r 68f0f7ed3e7b xen/include/public/xen.h
> --- a/xen/include/public/xen.h	Wed Oct 17 16:43:55 2012 +0100
> +++ b/xen/include/public/xen.h	Thu Oct 18 08:16:49 2012 +0100
> @@ -43,6 +43,10 @@ DEFINE_XEN_GUEST_HANDLE(char);
>  __DEFINE_XEN_GUEST_HANDLE(uchar, unsigned char);
>  DEFINE_XEN_GUEST_HANDLE(int);
>  __DEFINE_XEN_GUEST_HANDLE(uint,  unsigned int);
> +#if __XEN_INTERFACE_VERSION__ < 0x00040300 
> +DEFINE_XEN_GUEST_HANDLE(long);
> +__DEFINE_XEN_GUEST_HANDLE(ulong, unsigned long);
> +#endif
>  DEFINE_XEN_GUEST_HANDLE(void);
>  
>  DEFINE_XEN_GUEST_HANDLE(uint64_t);




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 07:50:34 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 07:50:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOks4-00033H-8X; Thu, 18 Oct 2012 07:50:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOks2-000335-Hv
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 07:50:22 +0000
Received: from [85.158.137.99:28836] by server-14.bemta-3.messagelabs.com id
	8B/F0-17276-DB4BF705; Thu, 18 Oct 2012 07:50:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1350546620!16695230!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29392 invoked from network); 18 Oct 2012 07:50:20 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-217.messagelabs.com with SMTP;
	18 Oct 2012 07:50:20 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 18 Oct 2012 08:52:34 +0100
Message-Id: <507FD0D902000078000A23CA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 18 Oct 2012 08:50:17 +0100
From: "Jan Beulich" 
To: "Ian Campbell" 
References: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
	<1350314444-17148-9-git-send-email-ian.campbell@citrix.com>
	<507FC2BF02000078000A2351@nat28.tlf.novell.com>
	<1350545548.28188.13.camel@dagon.hellion.org.uk>
In-Reply-To: <1350545548.28188.13.camel@dagon.hellion.org.uk>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Tim \(Xen.org\)" ,
	"xen-devel@lists.xen.org" ,
	"Keir \(Xen.org\)" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 09/10] xen: remove XEN_GUEST_HANDLE(ulong)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 18.10.12 at 09:32, Ian Campbell  wrote:
> On Thu, 2012-10-18 at 07:50 +0100, Jan Beulich wrote:
>> >>> On 15.10.12 at 17:20, Ian Campbell  wrote:
>> These two must be wrapped in __XEN_INTERFACE_VERSION__
>> conditionals (and __XEN_LATEST_INTERFACE_VERSION__ needs
>> to be bumped accordingly), since the various guest handles are
>> distinct types (i.e. consumers will fail to build if not updated).
> 
> Are there external consumers of gnttab_setup_table?

We can't know - it's a public, not tools-only interface.

> Nevertheless, here is the fix.
> 
> 8<-----------------------------------------------------
> 
> # HG changeset patch
> # User Ian Campbell 
> # Date 1350544609 -3600
> # Node ID 68f0f7ed3e7b3b7b4b9dbc692a448421ebc31035
> # Parent  5c402b905e00fb0871c3f439c8391dd3cfb3bc10
> xen: retain ulong guest handle for older consumers.
> 
> 26072:5529b91bd2e4 removed this but we need to keep it around for
> older consumers. Bump __XEN_LATEST_INTERFACE_VERSION__ accordingly.
> 
> Signed-off-by: Ian Campbell 

Acked-by: Jan Beulich 

> diff -r 5c402b905e00 -r 68f0f7ed3e7b xen/include/public/grant_table.h
> --- a/xen/include/public/grant_table.h	Wed Oct 17 16:43:55 2012 +0100
> +++ b/xen/include/public/grant_table.h	Thu Oct 18 08:16:49 2012 +0100
> @@ -385,7 +385,11 @@ struct gnttab_setup_table {
>      uint32_t nr_frames;
>      /* OUT parameters. */
>      int16_t  status;              /* => enum grant_status */
> +#if __XEN_INTERFACE_VERSION__ < 0x00040300 
> +    XEN_GUEST_HANDLE(ulong) frame_list;
> +#else
>      XEN_GUEST_HANDLE(xen_pfn_t) frame_list;
> +#endif
>  };
>  typedef struct gnttab_setup_table gnttab_setup_table_t;
>  DEFINE_XEN_GUEST_HANDLE(gnttab_setup_table_t);
> diff -r 5c402b905e00 -r 68f0f7ed3e7b xen/include/public/xen-compat.h
> --- a/xen/include/public/xen-compat.h	Wed Oct 17 16:43:55 2012 +0100
> +++ b/xen/include/public/xen-compat.h	Thu Oct 18 08:16:49 2012 +0100
> @@ -27,7 +27,7 @@
>  #ifndef __XEN_PUBLIC_XEN_COMPAT_H__
>  #define __XEN_PUBLIC_XEN_COMPAT_H__
>  
> -#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040200
> +#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040300
>  
>  #if defined(__XEN__) || defined(__XEN_TOOLS__)
>  /* Xen is built with matching headers and implements the latest interface. 
> */
> diff -r 5c402b905e00 -r 68f0f7ed3e7b xen/include/public/xen.h
> --- a/xen/include/public/xen.h	Wed Oct 17 16:43:55 2012 +0100
> +++ b/xen/include/public/xen.h	Thu Oct 18 08:16:49 2012 +0100
> @@ -43,6 +43,10 @@ DEFINE_XEN_GUEST_HANDLE(char);
>  __DEFINE_XEN_GUEST_HANDLE(uchar, unsigned char);
>  DEFINE_XEN_GUEST_HANDLE(int);
>  __DEFINE_XEN_GUEST_HANDLE(uint,  unsigned int);
> +#if __XEN_INTERFACE_VERSION__ < 0x00040300 
> +DEFINE_XEN_GUEST_HANDLE(long);
> +__DEFINE_XEN_GUEST_HANDLE(ulong, unsigned long);
> +#endif
>  DEFINE_XEN_GUEST_HANDLE(void);
>  
>  DEFINE_XEN_GUEST_HANDLE(uint64_t);




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 07:55:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 07:55:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOkwn-0003J2-4R; Thu, 18 Oct 2012 07:55:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOkwl-0003It-EM; Thu, 18 Oct 2012 07:55:15 +0000
Received: from [85.158.137.99:46863] by server-16.bemta-3.messagelabs.com id
	7A/B3-16565-2E5BF705; Thu, 18 Oct 2012 07:55:14 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1350546913!19671157!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14996 invoked from network); 18 Oct 2012 07:55:13 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 07:55:13 -0000
Received: by mail-ee0-f43.google.com with SMTP id c13so4704437eek.30
	for ; Thu, 18 Oct 2012 00:55:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=TvZA05Xr7DUqoZH0Z/9GfiYAgCd7J8sE9jR+FGuZELw=;
	b=jm+H80rsWnykhxsLn+vXB6HmmpIuX/OgJA7vQek24UtLFmpT87zcEGf2iBwSHdoS2b
	iGlku3VbP5pYWG5fP+mWHWuR78qlqInLauS86aIUj/eHMxjwVsOOLY8G8v+CUuqE9rhi
	Ag0AMUyY4eejhjPPU9gexQxVBrGc8izb9gMM/rxO1itAKE0iU3SUIIUtMEdG2yRfo2mm
	D9LjdKaDaqhff6wez3fPYL1RUn6YMimKscABSsSNy35Hxuz8avBS9uTDznsBYK7Zsifi
	B6CFyo90uHvG6gLb+CgkrBAhDhpozNQZY8AM0+XZ/6Xx0BlfYV4zBA/8t/5HcvuDDfy/
	uMTg==
Received: by 10.14.207.9 with SMTP id m9mr30059115eeo.5.1350546913154;
	Thu, 18 Oct 2012 00:55:13 -0700 (PDT)
Received: from [192.168.1.69] (host86-178-46-35.range86-178.btcentralplus.com.
	[86.178.46.35])
	by mx.google.com with ESMTPS id 7sm38522651eeg.5.2012.10.18.00.55.09
	(version=SSLv3 cipher=OTHER); Thu, 18 Oct 2012 00:55:11 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Thu, 18 Oct 2012 08:55:04 +0100
From: Keir Fraser 
To: Ian Campbell 
Message-ID: 
Thread-Topic: [Xen-users] [Xen-devel]  Re: Xen 4 TSC problems
Thread-Index: Ac2tBeHlOLIF/qBOHEmbuvN/oAPKaA==
In-Reply-To: <1350546021.28188.20.camel@dagon.hellion.org.uk>
Mime-version: 1.0
Cc: Jeremy Fitzhardinge ,
	"xen-devel@lists.xensource.com" ,
	Dan Magenheimer , Mauro ,
	Olivier Hanesse ,
	Jan Beulich , Xen Users ,
	Mark Adams 
Subject: Re: [Xen-devel] [Xen-users]   Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 18/10/2012 08:40, "Ian Campbell"  wrote:

> On Wed, 2012-10-17 at 17:15 +0100, Keir Fraser wrote:
>> @@ -540,6 +541,14 @@ static void plt_overflow(void *unused)
>>          plt_wrap = __read_platform_stime(plt_stamp64 + plt_mask + 1);
>>          if ( ABS(plt_wrap - now) > ABS(plt_now - now) )
>>              break;
>> +        rdtscll(tsc);
>> +        printk("XXX plt_overflow: plt_now=%"PRIx64" plt_wrap=%"PRIx64
>> +               " now=%"PRIx64" old_stamp=%"PRIx64" new_stamp=%"PRIx64
>> +               " plt_stamp64=%"PRIx64" plt_mask=%"PRIx64
>> +               " tsc=%"PRIx64" tsc_stamp=%"PRIx64"\n",
>> +               plt_now, plt_wrap, now, old_stamp, plt_stamp, plt_stamp64,
>> +               plt_mask, tsc, this_cpu(cpu_time).local_tsc_stamp);
>> +        break;
> 
> Is the break here, making the following update to plt_stamp64 dead code
> deliberate?

Yes, it's a hack to disable the timer-has-apparently-wrapped workaround.

 -- Keir

>>          plt_stamp64 += plt_mask + 1;
>>      }
>>      if ( i != 0 )
> 
> Ian.
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 07:55:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 07:55:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOkwn-0003J2-4R; Thu, 18 Oct 2012 07:55:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOkwl-0003It-EM; Thu, 18 Oct 2012 07:55:15 +0000
Received: from [85.158.137.99:46863] by server-16.bemta-3.messagelabs.com id
	7A/B3-16565-2E5BF705; Thu, 18 Oct 2012 07:55:14 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1350546913!19671157!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14996 invoked from network); 18 Oct 2012 07:55:13 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 07:55:13 -0000
Received: by mail-ee0-f43.google.com with SMTP id c13so4704437eek.30
	for ; Thu, 18 Oct 2012 00:55:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=TvZA05Xr7DUqoZH0Z/9GfiYAgCd7J8sE9jR+FGuZELw=;
	b=jm+H80rsWnykhxsLn+vXB6HmmpIuX/OgJA7vQek24UtLFmpT87zcEGf2iBwSHdoS2b
	iGlku3VbP5pYWG5fP+mWHWuR78qlqInLauS86aIUj/eHMxjwVsOOLY8G8v+CUuqE9rhi
	Ag0AMUyY4eejhjPPU9gexQxVBrGc8izb9gMM/rxO1itAKE0iU3SUIIUtMEdG2yRfo2mm
	D9LjdKaDaqhff6wez3fPYL1RUn6YMimKscABSsSNy35Hxuz8avBS9uTDznsBYK7Zsifi
	B6CFyo90uHvG6gLb+CgkrBAhDhpozNQZY8AM0+XZ/6Xx0BlfYV4zBA/8t/5HcvuDDfy/
	uMTg==
Received: by 10.14.207.9 with SMTP id m9mr30059115eeo.5.1350546913154;
	Thu, 18 Oct 2012 00:55:13 -0700 (PDT)
Received: from [192.168.1.69] (host86-178-46-35.range86-178.btcentralplus.com.
	[86.178.46.35])
	by mx.google.com with ESMTPS id 7sm38522651eeg.5.2012.10.18.00.55.09
	(version=SSLv3 cipher=OTHER); Thu, 18 Oct 2012 00:55:11 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Thu, 18 Oct 2012 08:55:04 +0100
From: Keir Fraser 
To: Ian Campbell 
Message-ID: 
Thread-Topic: [Xen-users] [Xen-devel]  Re: Xen 4 TSC problems
Thread-Index: Ac2tBeHlOLIF/qBOHEmbuvN/oAPKaA==
In-Reply-To: <1350546021.28188.20.camel@dagon.hellion.org.uk>
Mime-version: 1.0
Cc: Jeremy Fitzhardinge ,
	"xen-devel@lists.xensource.com" ,
	Dan Magenheimer , Mauro ,
	Olivier Hanesse ,
	Jan Beulich , Xen Users ,
	Mark Adams 
Subject: Re: [Xen-devel] [Xen-users]   Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 18/10/2012 08:40, "Ian Campbell"  wrote:

> On Wed, 2012-10-17 at 17:15 +0100, Keir Fraser wrote:
>> @@ -540,6 +541,14 @@ static void plt_overflow(void *unused)
>>          plt_wrap = __read_platform_stime(plt_stamp64 + plt_mask + 1);
>>          if ( ABS(plt_wrap - now) > ABS(plt_now - now) )
>>              break;
>> +        rdtscll(tsc);
>> +        printk("XXX plt_overflow: plt_now=%"PRIx64" plt_wrap=%"PRIx64
>> +               " now=%"PRIx64" old_stamp=%"PRIx64" new_stamp=%"PRIx64
>> +               " plt_stamp64=%"PRIx64" plt_mask=%"PRIx64
>> +               " tsc=%"PRIx64" tsc_stamp=%"PRIx64"\n",
>> +               plt_now, plt_wrap, now, old_stamp, plt_stamp, plt_stamp64,
>> +               plt_mask, tsc, this_cpu(cpu_time).local_tsc_stamp);
>> +        break;
> 
> Is the break here, making the following update to plt_stamp64 dead code
> deliberate?

Yes, it's a hack to disable the timer-has-apparently-wrapped workaround.

 -- Keir

>>          plt_stamp64 += plt_mask + 1;
>>      }
>>      if ( i != 0 )
> 
> Ian.
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 07:55:57 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 07:55:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOkxI-0003N8-8u; Thu, 18 Oct 2012 07:55:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOkxG-0003Mq-RU
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 07:55:47 +0000
Received: from [85.158.137.99:11693] by server-7.bemta-3.messagelabs.com id
	29/13-06991-206BF705; Thu, 18 Oct 2012 07:55:46 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1350546945!16901201!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16459 invoked from network); 18 Oct 2012 07:55:45 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 07:55:45 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so4782220eek.32
	for ; Thu, 18 Oct 2012 00:55:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=+lqJYRBgzFpuKy/0XMJNPyNlZkNzRMfzmSK5HAMal34=;
	b=qHIUrbN7v2tpZ7DN0CXXWGpDKEbxRMBPQegPpjCTmzLttX0WvG8zNCyEI4FB+0IdBs
	hThRV7BQFAa+C5PTho1vG6oWgU16H/xLIZvorohLP5BQWy8Eqlczn+L8/t1PzAKCgiJW
	3fnAfvmLQ+FoS367V5N4X3ggbDYO2TsIL5snEslc9qpfVTV+iB7jsl92IyXutpQcih68
	dBdUWdbU61amPjY+wGXvIrTuTWbwR0DZFiVzChLt/hXIBYWEYAyUqajP6ovQFRgB7kAE
	Ym5rxs9cE99n+GjQSthTew+DiBubexUo/88F8WwzO4ttRDhPHJjHVPi+SP4mNWCfeGrZ
	siLg==
Received: by 10.14.200.134 with SMTP id z6mr30120047een.33.1350546945142;
	Thu, 18 Oct 2012 00:55:45 -0700 (PDT)
Received: from [192.168.1.69] (host86-178-46-35.range86-178.btcentralplus.com.
	[86.178.46.35])
	by mx.google.com with ESMTPS id e7sm38518576eep.2.2012.10.18.00.55.42
	(version=SSLv3 cipher=OTHER); Thu, 18 Oct 2012 00:55:44 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Thu, 18 Oct 2012 08:55:39 +0100
From: Keir Fraser 
To: Jan Beulich ,
	xen-devel 
Message-ID: 
Thread-Topic: [Xen-devel] [PATCH] ACPI/APEI: accept validly sized ERST on
	Intel systems only for now
Thread-Index: Ac2tBfbCkSCZC0nMikCoU4t29dPCCg==
In-Reply-To: <507FCFC102000078000A23C7@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Wei Wang , Jinsong Liu ,
	christoph.egger@amd.com
Subject: Re: [Xen-devel] [PATCH] ACPI/APEI: accept validly sized ERST on
 Intel systems only for now
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 18/10/2012 08:45, "Jan Beulich"  wrote:

> Various AMD systems (but [unfortunately] not mine) hang when the table
> size check passes. Allow the check to pass on Intel systems only for
> now (until someone can actually debug the problem).
> 
> Signed-off-by: Jan Beulich 

Acked-by: Keir Fraser 

> --- a/xen/drivers/acpi/apei/erst.c
> +++ b/xen/drivers/acpi/apei/erst.c
> @@ -769,6 +769,19 @@ static int __init erst_check_table(struc
>  
> switch (erst_tab->header_length) {
> case sizeof(*erst_tab) - sizeof(erst_tab->header):
> +#ifdef CONFIG_X86
> +  /* XXX
> +   * While the rest of the ERST code appears to work on Intel
> +   * systems with properly sized tables, various AMD systems
> +   * appear to get hung (at boot time) by allowing this. Until
> +   * someone with access to suitable hardware can debug this,
> +   * disable the rest of the code by considering this case
> +   * invalid.
> +   */
> +  if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL)
> +   return -EINVAL;
> +  /* fall through */
> +#endif
> /*
> * While invalid per specification, there are (early?) systems
> * indicating the full header size here, so accept that value too.
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 07:55:57 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 07:55:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOkxI-0003N8-8u; Thu, 18 Oct 2012 07:55:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOkxG-0003Mq-RU
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 07:55:47 +0000
Received: from [85.158.137.99:11693] by server-7.bemta-3.messagelabs.com id
	29/13-06991-206BF705; Thu, 18 Oct 2012 07:55:46 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1350546945!16901201!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16459 invoked from network); 18 Oct 2012 07:55:45 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 07:55:45 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so4782220eek.32
	for ; Thu, 18 Oct 2012 00:55:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=+lqJYRBgzFpuKy/0XMJNPyNlZkNzRMfzmSK5HAMal34=;
	b=qHIUrbN7v2tpZ7DN0CXXWGpDKEbxRMBPQegPpjCTmzLttX0WvG8zNCyEI4FB+0IdBs
	hThRV7BQFAa+C5PTho1vG6oWgU16H/xLIZvorohLP5BQWy8Eqlczn+L8/t1PzAKCgiJW
	3fnAfvmLQ+FoS367V5N4X3ggbDYO2TsIL5snEslc9qpfVTV+iB7jsl92IyXutpQcih68
	dBdUWdbU61amPjY+wGXvIrTuTWbwR0DZFiVzChLt/hXIBYWEYAyUqajP6ovQFRgB7kAE
	Ym5rxs9cE99n+GjQSthTew+DiBubexUo/88F8WwzO4ttRDhPHJjHVPi+SP4mNWCfeGrZ
	siLg==
Received: by 10.14.200.134 with SMTP id z6mr30120047een.33.1350546945142;
	Thu, 18 Oct 2012 00:55:45 -0700 (PDT)
Received: from [192.168.1.69] (host86-178-46-35.range86-178.btcentralplus.com.
	[86.178.46.35])
	by mx.google.com with ESMTPS id e7sm38518576eep.2.2012.10.18.00.55.42
	(version=SSLv3 cipher=OTHER); Thu, 18 Oct 2012 00:55:44 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Thu, 18 Oct 2012 08:55:39 +0100
From: Keir Fraser 
To: Jan Beulich ,
	xen-devel 
Message-ID: 
Thread-Topic: [Xen-devel] [PATCH] ACPI/APEI: accept validly sized ERST on
	Intel systems only for now
Thread-Index: Ac2tBfbCkSCZC0nMikCoU4t29dPCCg==
In-Reply-To: <507FCFC102000078000A23C7@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Wei Wang , Jinsong Liu ,
	christoph.egger@amd.com
Subject: Re: [Xen-devel] [PATCH] ACPI/APEI: accept validly sized ERST on
 Intel systems only for now
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 18/10/2012 08:45, "Jan Beulich"  wrote:

> Various AMD systems (but [unfortunately] not mine) hang when the table
> size check passes. Allow the check to pass on Intel systems only for
> now (until someone can actually debug the problem).
> 
> Signed-off-by: Jan Beulich 

Acked-by: Keir Fraser 

> --- a/xen/drivers/acpi/apei/erst.c
> +++ b/xen/drivers/acpi/apei/erst.c
> @@ -769,6 +769,19 @@ static int __init erst_check_table(struc
>  
> switch (erst_tab->header_length) {
> case sizeof(*erst_tab) - sizeof(erst_tab->header):
> +#ifdef CONFIG_X86
> +  /* XXX
> +   * While the rest of the ERST code appears to work on Intel
> +   * systems with properly sized tables, various AMD systems
> +   * appear to get hung (at boot time) by allowing this. Until
> +   * someone with access to suitable hardware can debug this,
> +   * disable the rest of the code by considering this case
> +   * invalid.
> +   */
> +  if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL)
> +   return -EINVAL;
> +  /* fall through */
> +#endif
> /*
> * While invalid per specification, there are (early?) systems
> * indicating the full header size here, so accept that value too.
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 08:08:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 08:08:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOl8y-0004R4-VV; Thu, 18 Oct 2012 08:07:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOl8x-0004Qz-M8
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 08:07:51 +0000
Received: from [193.109.254.147:6448] by server-11.bemta-14.messagelabs.com id
	BF/53-09558-6D8BF705; Thu, 18 Oct 2012 08:07:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1350547557!15075378!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17825 invoked from network); 18 Oct 2012 08:05:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 08:05:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15246160"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 08:05:57 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 09:05:56 +0100
Message-ID: <1350547552.28188.29.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Olaf Hering 
Date: Thu, 18 Oct 2012 09:05:52 +0100
In-Reply-To: <20121012144653.GA22206@aepfle.de>
References: <597f0885494d0441b10c.1350051258@probook.site>
	<1350052613.14806.109.camel@zakaz.uk.xensource.com>
	<20121012144653.GA22206@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] hotplug/Linux: remove hotplug support,
 rely on udev instead
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-12 at 15:46 +0100, Olaf Hering wrote:
> On Fri, Oct 12, Ian Campbell wrote:
> 
> > On Fri, 2012-10-12 at 15:14 +0100, Olaf Hering wrote:
> > > The patch by itself will have no practical impact unless someone
> > > attempts to build and run a Xen dom0 on a really old base system.
> > 
> > Does anyone have any idea what sort of timeframe hotplug agent stuff
> > really died in, just so we can document something?
> 
> SLES9 (back in 2007) had an early version of udev, hotplug was still in
> use. It looks like hotplug.rpm was finally dropped from SuSE Linux in 2005.

2005 was after 2007 though?

Any way, I've added "e.g. circa SLES9/2007 or earlier" to the end of the
commit message and will apply.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 08:08:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 08:08:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOl8y-0004R4-VV; Thu, 18 Oct 2012 08:07:52 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOl8x-0004Qz-M8
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 08:07:51 +0000
Received: from [193.109.254.147:6448] by server-11.bemta-14.messagelabs.com id
	BF/53-09558-6D8BF705; Thu, 18 Oct 2012 08:07:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1350547557!15075378!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17825 invoked from network); 18 Oct 2012 08:05:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 08:05:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15246160"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 08:05:57 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 09:05:56 +0100
Message-ID: <1350547552.28188.29.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Olaf Hering 
Date: Thu, 18 Oct 2012 09:05:52 +0100
In-Reply-To: <20121012144653.GA22206@aepfle.de>
References: <597f0885494d0441b10c.1350051258@probook.site>
	<1350052613.14806.109.camel@zakaz.uk.xensource.com>
	<20121012144653.GA22206@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] hotplug/Linux: remove hotplug support,
 rely on udev instead
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-12 at 15:46 +0100, Olaf Hering wrote:
> On Fri, Oct 12, Ian Campbell wrote:
> 
> > On Fri, 2012-10-12 at 15:14 +0100, Olaf Hering wrote:
> > > The patch by itself will have no practical impact unless someone
> > > attempts to build and run a Xen dom0 on a really old base system.
> > 
> > Does anyone have any idea what sort of timeframe hotplug agent stuff
> > really died in, just so we can document something?
> 
> SLES9 (back in 2007) had an early version of udev, hotplug was still in
> use. It looks like hotplug.rpm was finally dropped from SuSE Linux in 2005.

2005 was after 2007 though?

Any way, I've added "e.g. circa SLES9/2007 or earlier" to the end of the
commit message and will apply.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 08:08:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 08:08:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOl9K-0004Su-C3; Thu, 18 Oct 2012 08:08:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOl9I-0004Sg-SJ
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 08:08:13 +0000
Received: from [85.158.143.99:60136] by server-1.bemta-4.messagelabs.com id
	87/35-19134-CE8BF705; Thu, 18 Oct 2012 08:08:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1350547691!28330854!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12725 invoked from network); 18 Oct 2012 08:08:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 08:08:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15246216"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 08:08:10 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 09:08:10 +0100
Message-ID: <1350547689.28188.31.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Andres Lagar-Cavilla 
Date: Thu, 18 Oct 2012 09:08:09 +0100
In-Reply-To: <5171750d133ef2c27ac8.1350055853@xdev.gridcentric.ca>
References: <5171750d133ef2c27ac8.1350055853@xdev.gridcentric.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Christoph Egger ,
	"andres@gridcentric.ca" ,
	Ian Jackson ,
	"xen-devel@lists.xen.org" ,
	Attilio Rao ,
	Roger Pau Monne 
Subject: Re: [Xen-devel] [PATCH] Synchronize privcmd header constants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-12 at 16:30 +0100, Andres Lagar-Cavilla wrote:
> tools/include/xen-sys/Linux/privcmd.h |   3 +++
>  tools/libxc/xc_linux_osdep.c          |  10 +++++-----
>  xen/include/public/domctl.h           |   1 -
>  3 files changed, 8 insertions(+), 6 deletions(-)
> 
> 
> Since Linux's git commit ceb90fa0a8008059ecbbf9114cb89dc71a730bb6, the
> privcmd.h interface between Linux and libxc specifies two new constants,
> PRIVCMD_MMAPBATCH_MFN_ERROR and PRIVCMD_MMAPBATCH_PAGED_ERROR. These constants
> represent the error codes encoded in the top nibble of an mfn slot passed to
> the legacy MMAPBATCH ioctl.
> 
> In particular, libxenctrl checks for the equivalent of the latter constant when
> dealing with paged out frames that might be the target of a foreign map.
> 
> Previously, the relevant constant was defined in the domctl hypervisor
> interface header (XEN_DOMCTL_PFINFO_PAGEDTAB). Because this top-nibble encoding
> is a contract between the dom0 kernel and libxc, a domctl.h definition is
> misplaced.
> 
> - Sync the privcmd.h header to that now available in upstream Linux

Although the ioctl is Linux specific is the top-nibble behaviour (and
therefore the #define) common to other dom0s like *BSD? Can a BSD person
confirm that this change won't breaking things for them please.

> - Update libxc appropriately
> - Remove the unnecessary constant in domctl.h
> 
> Signed-off-by: Andres Lagar-Cavilla 
> 
> diff -r 4eed5e64544f -r 5171750d133e tools/include/xen-sys/Linux/privcmd.h
> --- a/tools/include/xen-sys/Linux/privcmd.h
> +++ b/tools/include/xen-sys/Linux/privcmd.h
> @@ -64,6 +64,9 @@ typedef struct privcmd_mmapbatch {
>  	xen_pfn_t __user *arr; /* array of mfns - top nibble set on err */
>  } privcmd_mmapbatch_t; 
>  
> +#define PRIVCMD_MMAPBATCH_MFN_ERROR     0xf0000000U
> +#define PRIVCMD_MMAPBATCH_PAGED_ERROR   0x80000000U
> +
>  typedef struct privcmd_mmapbatch_v2 {
>  	unsigned int num; /* number of pages to populate */
>  	domid_t dom;      /* target domain */
> diff -r 4eed5e64544f -r 5171750d133e tools/libxc/xc_linux_osdep.c
> --- a/tools/libxc/xc_linux_osdep.c
> +++ b/tools/libxc/xc_linux_osdep.c
> @@ -129,7 +129,7 @@ static int xc_map_foreign_batch_single(i
>  
>      do
>      {
> -        *mfn ^= XEN_DOMCTL_PFINFO_PAGEDTAB;
> +        *mfn ^= PRIVCMD_MMAPBATCH_PAGED_ERROR;
>          usleep(100);
>          rc = ioctl(fd, IOCTL_PRIVCMD_MMAPBATCH, &ioctlx);
>      }
> @@ -166,8 +166,8 @@ static void *linux_privcmd_map_foreign_b
>  
>          for ( i = 0; i < num; i++ )
>          {
> -            if ( (arr[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) ==
> -                 XEN_DOMCTL_PFINFO_PAGEDTAB )
> +            if ( (arr[i] & PRIVCMD_MMAPBATCH_MFN_ERROR) ==
> +                           PRIVCMD_MMAPBATCH_PAGED_ERROR )
>              {
>                  unsigned long paged_addr = (unsigned long)addr + (i << XC_PAGE_SHIFT);
>                  rc = xc_map_foreign_batch_single(fd, dom, &arr[i],
> @@ -323,12 +323,12 @@ static void *linux_privcmd_map_foreign_b
>              default:
>                  err[i] = -EINVAL;
>                  continue;
> -            case XEN_DOMCTL_PFINFO_PAGEDTAB:
> +            case PRIVCMD_MMAPBATCH_PAGED_ERROR:
>                  if ( rc != -ENOENT )
>                  {
>                      err[i] = rc ?: -EINVAL;
>                      continue;
> -                 }
> +                }
>                  rc = xc_map_foreign_batch_single(fd, dom, pfn + i,
>                          (unsigned long)addr + ((unsigned long)i<                  if ( rc < 0 )
> diff -r 4eed5e64544f -r 5171750d133e xen/include/public/domctl.h
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -135,7 +135,6 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_getme
>  #define XEN_DOMCTL_PFINFO_LPINTAB (0x1U<<31)
>  #define XEN_DOMCTL_PFINFO_XTAB    (0xfU<<28) /* invalid page */
>  #define XEN_DOMCTL_PFINFO_XALLOC  (0xeU<<28) /* allocate-only page */
> -#define XEN_DOMCTL_PFINFO_PAGEDTAB (0x8U<<28)
>  #define XEN_DOMCTL_PFINFO_LTAB_MASK (0xfU<<28)
>  
>  struct xen_domctl_getpageframeinfo {



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 08:08:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 08:08:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOl9K-0004Su-C3; Thu, 18 Oct 2012 08:08:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOl9I-0004Sg-SJ
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 08:08:13 +0000
Received: from [85.158.143.99:60136] by server-1.bemta-4.messagelabs.com id
	87/35-19134-CE8BF705; Thu, 18 Oct 2012 08:08:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1350547691!28330854!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12725 invoked from network); 18 Oct 2012 08:08:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 08:08:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15246216"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 08:08:10 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 09:08:10 +0100
Message-ID: <1350547689.28188.31.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Andres Lagar-Cavilla 
Date: Thu, 18 Oct 2012 09:08:09 +0100
In-Reply-To: <5171750d133ef2c27ac8.1350055853@xdev.gridcentric.ca>
References: <5171750d133ef2c27ac8.1350055853@xdev.gridcentric.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Christoph Egger ,
	"andres@gridcentric.ca" ,
	Ian Jackson ,
	"xen-devel@lists.xen.org" ,
	Attilio Rao ,
	Roger Pau Monne 
Subject: Re: [Xen-devel] [PATCH] Synchronize privcmd header constants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-12 at 16:30 +0100, Andres Lagar-Cavilla wrote:
> tools/include/xen-sys/Linux/privcmd.h |   3 +++
>  tools/libxc/xc_linux_osdep.c          |  10 +++++-----
>  xen/include/public/domctl.h           |   1 -
>  3 files changed, 8 insertions(+), 6 deletions(-)
> 
> 
> Since Linux's git commit ceb90fa0a8008059ecbbf9114cb89dc71a730bb6, the
> privcmd.h interface between Linux and libxc specifies two new constants,
> PRIVCMD_MMAPBATCH_MFN_ERROR and PRIVCMD_MMAPBATCH_PAGED_ERROR. These constants
> represent the error codes encoded in the top nibble of an mfn slot passed to
> the legacy MMAPBATCH ioctl.
> 
> In particular, libxenctrl checks for the equivalent of the latter constant when
> dealing with paged out frames that might be the target of a foreign map.
> 
> Previously, the relevant constant was defined in the domctl hypervisor
> interface header (XEN_DOMCTL_PFINFO_PAGEDTAB). Because this top-nibble encoding
> is a contract between the dom0 kernel and libxc, a domctl.h definition is
> misplaced.
> 
> - Sync the privcmd.h header to that now available in upstream Linux

Although the ioctl is Linux specific is the top-nibble behaviour (and
therefore the #define) common to other dom0s like *BSD? Can a BSD person
confirm that this change won't breaking things for them please.

> - Update libxc appropriately
> - Remove the unnecessary constant in domctl.h
> 
> Signed-off-by: Andres Lagar-Cavilla 
> 
> diff -r 4eed5e64544f -r 5171750d133e tools/include/xen-sys/Linux/privcmd.h
> --- a/tools/include/xen-sys/Linux/privcmd.h
> +++ b/tools/include/xen-sys/Linux/privcmd.h
> @@ -64,6 +64,9 @@ typedef struct privcmd_mmapbatch {
>  	xen_pfn_t __user *arr; /* array of mfns - top nibble set on err */
>  } privcmd_mmapbatch_t; 
>  
> +#define PRIVCMD_MMAPBATCH_MFN_ERROR     0xf0000000U
> +#define PRIVCMD_MMAPBATCH_PAGED_ERROR   0x80000000U
> +
>  typedef struct privcmd_mmapbatch_v2 {
>  	unsigned int num; /* number of pages to populate */
>  	domid_t dom;      /* target domain */
> diff -r 4eed5e64544f -r 5171750d133e tools/libxc/xc_linux_osdep.c
> --- a/tools/libxc/xc_linux_osdep.c
> +++ b/tools/libxc/xc_linux_osdep.c
> @@ -129,7 +129,7 @@ static int xc_map_foreign_batch_single(i
>  
>      do
>      {
> -        *mfn ^= XEN_DOMCTL_PFINFO_PAGEDTAB;
> +        *mfn ^= PRIVCMD_MMAPBATCH_PAGED_ERROR;
>          usleep(100);
>          rc = ioctl(fd, IOCTL_PRIVCMD_MMAPBATCH, &ioctlx);
>      }
> @@ -166,8 +166,8 @@ static void *linux_privcmd_map_foreign_b
>  
>          for ( i = 0; i < num; i++ )
>          {
> -            if ( (arr[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) ==
> -                 XEN_DOMCTL_PFINFO_PAGEDTAB )
> +            if ( (arr[i] & PRIVCMD_MMAPBATCH_MFN_ERROR) ==
> +                           PRIVCMD_MMAPBATCH_PAGED_ERROR )
>              {
>                  unsigned long paged_addr = (unsigned long)addr + (i << XC_PAGE_SHIFT);
>                  rc = xc_map_foreign_batch_single(fd, dom, &arr[i],
> @@ -323,12 +323,12 @@ static void *linux_privcmd_map_foreign_b
>              default:
>                  err[i] = -EINVAL;
>                  continue;
> -            case XEN_DOMCTL_PFINFO_PAGEDTAB:
> +            case PRIVCMD_MMAPBATCH_PAGED_ERROR:
>                  if ( rc != -ENOENT )
>                  {
>                      err[i] = rc ?: -EINVAL;
>                      continue;
> -                 }
> +                }
>                  rc = xc_map_foreign_batch_single(fd, dom, pfn + i,
>                          (unsigned long)addr + ((unsigned long)i<                  if ( rc < 0 )
> diff -r 4eed5e64544f -r 5171750d133e xen/include/public/domctl.h
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -135,7 +135,6 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_getme
>  #define XEN_DOMCTL_PFINFO_LPINTAB (0x1U<<31)
>  #define XEN_DOMCTL_PFINFO_XTAB    (0xfU<<28) /* invalid page */
>  #define XEN_DOMCTL_PFINFO_XALLOC  (0xeU<<28) /* allocate-only page */
> -#define XEN_DOMCTL_PFINFO_PAGEDTAB (0x8U<<28)
>  #define XEN_DOMCTL_PFINFO_LTAB_MASK (0xfU<<28)
>  
>  struct xen_domctl_getpageframeinfo {



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 08:11:35 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 08:11:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOlCR-0004gy-1X; Thu, 18 Oct 2012 08:11:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOlCQ-0004gs-5N
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 08:11:26 +0000
Received: from [85.158.143.99:17284] by server-2.bemta-4.messagelabs.com id
	5A/0A-22268-DA9BF705; Thu, 18 Oct 2012 08:11:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1350547884!24800761!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30744 invoked from network); 18 Oct 2012 08:11:24 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-216.messagelabs.com with SMTP;
	18 Oct 2012 08:11:24 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 18 Oct 2012 09:11:23 +0100
Message-Id: <507FD5C902000078000A240B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 18 Oct 2012 09:11:21 +0100
From: "Jan Beulich" 
To: "Keir Fraser" 
References: <507EB6DB02000078000A1F4A@nat28.tlf.novell.com>
	
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: xiantao.zhang@intel.com, xen-devel 
Subject: Re: [Xen-devel] [PATCH v2 2/3] x86/HPET: allow use for broadcast
 when interrupt remapping is in effect
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 17.10.12 at 13:59, Keir Fraser  wrote:
> On 17/10/2012 12:47, "Jan Beulich"  wrote:
> 
>> This requires some additions to the VT-d side; AMD IOMMUs use the
>> "normal" MSI message format even when interrupt remapping is enabled,
>> thus making adjustments here unnecessary.
>> 
>> Signed-off-by: Jan Beulich 
> 
> Acked-by: Keir Fraser 
> 
> ...for the principle, but needs an Intel ack for the details.
> 
>  -- Keir
> 
>> ---
>> v2: refresh after updating patch 1 of this series (patch 3 is unchanged)

Committed - how about patch 3 then?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 08:11:35 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 08:11:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOlCR-0004gy-1X; Thu, 18 Oct 2012 08:11:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOlCQ-0004gs-5N
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 08:11:26 +0000
Received: from [85.158.143.99:17284] by server-2.bemta-4.messagelabs.com id
	5A/0A-22268-DA9BF705; Thu, 18 Oct 2012 08:11:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1350547884!24800761!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30744 invoked from network); 18 Oct 2012 08:11:24 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-216.messagelabs.com with SMTP;
	18 Oct 2012 08:11:24 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 18 Oct 2012 09:11:23 +0100
Message-Id: <507FD5C902000078000A240B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 18 Oct 2012 09:11:21 +0100
From: "Jan Beulich" 
To: "Keir Fraser" 
References: <507EB6DB02000078000A1F4A@nat28.tlf.novell.com>
	
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: xiantao.zhang@intel.com, xen-devel 
Subject: Re: [Xen-devel] [PATCH v2 2/3] x86/HPET: allow use for broadcast
 when interrupt remapping is in effect
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 17.10.12 at 13:59, Keir Fraser  wrote:
> On 17/10/2012 12:47, "Jan Beulich"  wrote:
> 
>> This requires some additions to the VT-d side; AMD IOMMUs use the
>> "normal" MSI message format even when interrupt remapping is enabled,
>> thus making adjustments here unnecessary.
>> 
>> Signed-off-by: Jan Beulich 
> 
> Acked-by: Keir Fraser 
> 
> ...for the principle, but needs an Intel ack for the details.
> 
>  -- Keir
> 
>> ---
>> v2: refresh after updating patch 1 of this series (patch 3 is unchanged)

Committed - how about patch 3 then?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 08:18:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 08:18:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOlJ3-0004t5-27; Thu, 18 Oct 2012 08:18:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOlJ1-0004t0-GP
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 08:18:15 +0000
Received: from [85.158.143.99:62177] by server-3.bemta-4.messagelabs.com id
	E1/D0-03544-64BBF705; Thu, 18 Oct 2012 08:18:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1350548294!33970136!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2577 invoked from network); 18 Oct 2012 08:18:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 08:18:14 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15246633"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 08:18:14 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 09:18:13 +0100
Message-ID: <1350548293.28188.34.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Olaf Hering 
Date: Thu, 18 Oct 2012 09:18:13 +0100
In-Reply-To: 
References: 
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 4 of 8] hotplug/Linux: add sysconfig tags to
 xencommons
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-10-15 at 14:44 +0100, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering 
> # Date 1350305772 -7200
> # Node ID ed893d76098bf0e41cd2c1d5d0392b7f36547c45
> # Parent  ba9b347a31fed0aa57604d2342117282dd38b9bc
> hotplug/Linux: add sysconfig tags to xencommons
> 
> YaST2 sysconfig can logically group the various sysconfig settings if the
> files are tagged. Add the missing tags to xencommons.
> See for a description
> http://old-en.opensuse.org/Packaging/SUSE_Package_Conventions/Sysconfig

Is this specific to SuSE/YaST2 or a more general standard?

I'm going to apply anyway, since it seems harmless.

> Signed-off-by: Olaf Hering 
> 
> diff -r ba9b347a31fe -r ed893d76098b tools/hotplug/Linux/init.d/sysconfig.xencommons
> --- a/tools/hotplug/Linux/init.d/sysconfig.xencommons
> +++ b/tools/hotplug/Linux/init.d/sysconfig.xencommons
> @@ -1,15 +1,31 @@
> +## Path: System/Virtualization
> +## Type: string
> +## Default: "none"
> +#
>  # Log xenconsoled messages (cf xl dmesg)
>  #XENCONSOLED_TRACE=[none|guest|hv|all]
>  
> +## Type: string
> +## Default: xenstored
> +#
>  # Select xenstored implementation
>  #XENSTORED=[oxenstored|xenstored]
>  
> +## Type: string
> +## Default: Not defined, tracing off
> +#
>  # Log xenstored messages
>  #XENSTORED_TRACE=[yes|on|1]
>  
> +## Type: string
> +## Default: "/var/lib/xenstored"
> +#
>  # Running xenstored on XENSTORED_ROOTDIR
>  #XENSTORED_ROOTDIR=/var/lib/xenstored
>  
> +## Type: string
> +## Default: Not defined, xenbackendd debug mode off
> +#
>  # Running xenbackendd in debug mode
>  #XENBACKENDD_DEBUG=[yes|on|1]
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 08:18:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 08:18:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOlJ3-0004t5-27; Thu, 18 Oct 2012 08:18:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOlJ1-0004t0-GP
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 08:18:15 +0000
Received: from [85.158.143.99:62177] by server-3.bemta-4.messagelabs.com id
	E1/D0-03544-64BBF705; Thu, 18 Oct 2012 08:18:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1350548294!33970136!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2577 invoked from network); 18 Oct 2012 08:18:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 08:18:14 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15246633"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 08:18:14 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 09:18:13 +0100
Message-ID: <1350548293.28188.34.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Olaf Hering 
Date: Thu, 18 Oct 2012 09:18:13 +0100
In-Reply-To: 
References: 
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 4 of 8] hotplug/Linux: add sysconfig tags to
 xencommons
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-10-15 at 14:44 +0100, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering 
> # Date 1350305772 -7200
> # Node ID ed893d76098bf0e41cd2c1d5d0392b7f36547c45
> # Parent  ba9b347a31fed0aa57604d2342117282dd38b9bc
> hotplug/Linux: add sysconfig tags to xencommons
> 
> YaST2 sysconfig can logically group the various sysconfig settings if the
> files are tagged. Add the missing tags to xencommons.
> See for a description
> http://old-en.opensuse.org/Packaging/SUSE_Package_Conventions/Sysconfig

Is this specific to SuSE/YaST2 or a more general standard?

I'm going to apply anyway, since it seems harmless.

> Signed-off-by: Olaf Hering 
> 
> diff -r ba9b347a31fe -r ed893d76098b tools/hotplug/Linux/init.d/sysconfig.xencommons
> --- a/tools/hotplug/Linux/init.d/sysconfig.xencommons
> +++ b/tools/hotplug/Linux/init.d/sysconfig.xencommons
> @@ -1,15 +1,31 @@
> +## Path: System/Virtualization
> +## Type: string
> +## Default: "none"
> +#
>  # Log xenconsoled messages (cf xl dmesg)
>  #XENCONSOLED_TRACE=[none|guest|hv|all]
>  
> +## Type: string
> +## Default: xenstored
> +#
>  # Select xenstored implementation
>  #XENSTORED=[oxenstored|xenstored]
>  
> +## Type: string
> +## Default: Not defined, tracing off
> +#
>  # Log xenstored messages
>  #XENSTORED_TRACE=[yes|on|1]
>  
> +## Type: string
> +## Default: "/var/lib/xenstored"
> +#
>  # Running xenstored on XENSTORED_ROOTDIR
>  #XENSTORED_ROOTDIR=/var/lib/xenstored
>  
> +## Type: string
> +## Default: Not defined, xenbackendd debug mode off
> +#
>  # Running xenbackendd in debug mode
>  #XENBACKENDD_DEBUG=[yes|on|1]
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 08:22:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 08:22:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOlNL-000514-O7; Thu, 18 Oct 2012 08:22:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOlNJ-00050v-Uo
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 08:22:42 +0000
Received: from [85.158.143.35:23592] by server-1.bemta-4.messagelabs.com id
	CC/0C-19134-15CBF705; Thu, 18 Oct 2012 08:22:41 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1350548530!13475410!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 689 invoked from network); 18 Oct 2012 08:22:10 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 08:22:10 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so4797141eek.32
	for ; Thu, 18 Oct 2012 01:22:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=xEhP/ePUtBdFJHS7T70ZpIFOZJ5Iz7+gi8/vYPzTdZo=;
	b=MWI0NWJHl+1U8KTri2Z/bRE4BjCXPWMDBTllCFJgN0EyhPik9pj4gxfBcDnpSRV+kL
	3pUvMtGj2UiBAuISvZph6fegm32oE47aGLNznHHUTn5HXeXRKZsWh47c35XyqC6pAfO9
	bcAGBDqiNqiaFJmvuCfHlORiVsAzdoQ4eOVjbHnQlfsaKVZqL2t7ujU4nxs1DHAVFAoh
	sU6kle0LAyyUuBNAep19mdgBCPVEbIMktksAtVONXZYDYQXR1VS46cCEKnMJn0n7ISJm
	lgUGfv5imypAbclJ0ZPqviCSVs4gRBUNwAhVtPjiq5L9clmAp+aaHYMvy0qDiY7vMK6G
	KzeQ==
Received: by 10.14.193.136 with SMTP id k8mr30262990een.30.1350548530152;
	Thu, 18 Oct 2012 01:22:10 -0700 (PDT)
Received: from [192.168.1.3] (host86-178-46-35.range86-178.btcentralplus.com.
	[86.178.46.35])
	by mx.google.com with ESMTPS id k2sm5918236eep.15.2012.10.18.01.22.08
	(version=SSLv3 cipher=OTHER); Thu, 18 Oct 2012 01:22:09 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Thu, 18 Oct 2012 09:22:03 +0100
From: Keir Fraser 
To: Jan Beulich ,
	xen-devel 
Message-ID: 
Thread-Topic: [Xen-devel] [PATCH 3/3] x86/HPET: cache MSI message last written
Thread-Index: Ac2tCabl7ppBBg6uiEqft5mbMAedEA==
In-Reply-To: <507D952802000078000A1BC5@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 3/3] x86/HPET: cache MSI message last written
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 16/10/2012 16:11, "Jan Beulich"  wrote:

> Rather than spending measurable amounts of time reading back the most
> recently written message, cache it in space previously unused, and thus
> accelerate the CPU's entering of the intended C-state.
> 
> hpet_msi_read() ends up being unused after this change, but rather than
> removing the function, it's being marked "unused" in order - that way
> it can easily get used again should a new need for it arise.

Please use __attribute_used__

> Signed-off-by: Jan Beulich 

Acked-by: Keir Fraser 

> --- a/xen/arch/x86/hpet.c
> +++ b/xen/arch/x86/hpet.c
> @@ -253,17 +253,19 @@ static void hpet_msi_mask(struct irq_des
>  
>  static void hpet_msi_write(struct hpet_event_channel *ch, struct msi_msg
> *msg)
>  {
> +    ch->msi.msg = *msg;
>      if ( iommu_intremap )
>          iommu_update_ire_from_msi(&ch->msi, msg);
>      hpet_write32(msg->data, HPET_Tn_ROUTE(ch->idx));
>      hpet_write32(msg->address_lo, HPET_Tn_ROUTE(ch->idx) + 4);
>  }
>  
> -static void hpet_msi_read(struct hpet_event_channel *ch, struct msi_msg *msg)
> +static void __attribute__((__unused__))
> +hpet_msi_read(struct hpet_event_channel *ch, struct msi_msg *msg)
>  {
>      msg->data = hpet_read32(HPET_Tn_ROUTE(ch->idx));
>      msg->address_lo = hpet_read32(HPET_Tn_ROUTE(ch->idx) + 4);
> -    msg->address_hi = 0;
> +    msg->address_hi = MSI_ADDR_BASE_HI;
>      if ( iommu_intremap )
>          iommu_read_msi_from_ire(&ch->msi, msg);
>  }
> @@ -285,20 +287,19 @@ static void hpet_msi_ack(struct irq_desc
>  
>  static void hpet_msi_set_affinity(struct irq_desc *desc, const cpumask_t
> *mask)
>  {
> -    struct msi_msg msg;
> -    unsigned int dest;
> +    struct hpet_event_channel *ch = desc->action->dev_id;
> +    struct msi_msg msg = ch->msi.msg;
>  
> -    dest = set_desc_affinity(desc, mask);
> -    if (dest == BAD_APICID)
> +    msg.dest32 = set_desc_affinity(desc, mask);
> +    if ( msg.dest32 == BAD_APICID )
>          return;
>  
> -    hpet_msi_read(desc->action->dev_id, &msg);
>      msg.data &= ~MSI_DATA_VECTOR_MASK;
>      msg.data |= MSI_DATA_VECTOR(desc->arch.vector);
>      msg.address_lo &= ~MSI_ADDR_DEST_ID_MASK;
> -    msg.address_lo |= MSI_ADDR_DEST_ID(dest);
> -    msg.dest32 = dest;
> -    hpet_msi_write(desc->action->dev_id, &msg);
> +    msg.address_lo |= MSI_ADDR_DEST_ID(msg.dest32);
> +    if ( msg.data != ch->msi.msg.data || msg.dest32 != ch->msi.msg.dest32 )
> +        hpet_msi_write(ch, &msg);
>  }
>  
>  /*
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 08:22:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 08:22:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOlNL-000514-O7; Thu, 18 Oct 2012 08:22:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOlNJ-00050v-Uo
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 08:22:42 +0000
Received: from [85.158.143.35:23592] by server-1.bemta-4.messagelabs.com id
	CC/0C-19134-15CBF705; Thu, 18 Oct 2012 08:22:41 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1350548530!13475410!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 689 invoked from network); 18 Oct 2012 08:22:10 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 08:22:10 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so4797141eek.32
	for ; Thu, 18 Oct 2012 01:22:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=xEhP/ePUtBdFJHS7T70ZpIFOZJ5Iz7+gi8/vYPzTdZo=;
	b=MWI0NWJHl+1U8KTri2Z/bRE4BjCXPWMDBTllCFJgN0EyhPik9pj4gxfBcDnpSRV+kL
	3pUvMtGj2UiBAuISvZph6fegm32oE47aGLNznHHUTn5HXeXRKZsWh47c35XyqC6pAfO9
	bcAGBDqiNqiaFJmvuCfHlORiVsAzdoQ4eOVjbHnQlfsaKVZqL2t7ujU4nxs1DHAVFAoh
	sU6kle0LAyyUuBNAep19mdgBCPVEbIMktksAtVONXZYDYQXR1VS46cCEKnMJn0n7ISJm
	lgUGfv5imypAbclJ0ZPqviCSVs4gRBUNwAhVtPjiq5L9clmAp+aaHYMvy0qDiY7vMK6G
	KzeQ==
Received: by 10.14.193.136 with SMTP id k8mr30262990een.30.1350548530152;
	Thu, 18 Oct 2012 01:22:10 -0700 (PDT)
Received: from [192.168.1.3] (host86-178-46-35.range86-178.btcentralplus.com.
	[86.178.46.35])
	by mx.google.com with ESMTPS id k2sm5918236eep.15.2012.10.18.01.22.08
	(version=SSLv3 cipher=OTHER); Thu, 18 Oct 2012 01:22:09 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Thu, 18 Oct 2012 09:22:03 +0100
From: Keir Fraser 
To: Jan Beulich ,
	xen-devel 
Message-ID: 
Thread-Topic: [Xen-devel] [PATCH 3/3] x86/HPET: cache MSI message last written
Thread-Index: Ac2tCabl7ppBBg6uiEqft5mbMAedEA==
In-Reply-To: <507D952802000078000A1BC5@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 3/3] x86/HPET: cache MSI message last written
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 16/10/2012 16:11, "Jan Beulich"  wrote:

> Rather than spending measurable amounts of time reading back the most
> recently written message, cache it in space previously unused, and thus
> accelerate the CPU's entering of the intended C-state.
> 
> hpet_msi_read() ends up being unused after this change, but rather than
> removing the function, it's being marked "unused" in order - that way
> it can easily get used again should a new need for it arise.

Please use __attribute_used__

> Signed-off-by: Jan Beulich 

Acked-by: Keir Fraser 

> --- a/xen/arch/x86/hpet.c
> +++ b/xen/arch/x86/hpet.c
> @@ -253,17 +253,19 @@ static void hpet_msi_mask(struct irq_des
>  
>  static void hpet_msi_write(struct hpet_event_channel *ch, struct msi_msg
> *msg)
>  {
> +    ch->msi.msg = *msg;
>      if ( iommu_intremap )
>          iommu_update_ire_from_msi(&ch->msi, msg);
>      hpet_write32(msg->data, HPET_Tn_ROUTE(ch->idx));
>      hpet_write32(msg->address_lo, HPET_Tn_ROUTE(ch->idx) + 4);
>  }
>  
> -static void hpet_msi_read(struct hpet_event_channel *ch, struct msi_msg *msg)
> +static void __attribute__((__unused__))
> +hpet_msi_read(struct hpet_event_channel *ch, struct msi_msg *msg)
>  {
>      msg->data = hpet_read32(HPET_Tn_ROUTE(ch->idx));
>      msg->address_lo = hpet_read32(HPET_Tn_ROUTE(ch->idx) + 4);
> -    msg->address_hi = 0;
> +    msg->address_hi = MSI_ADDR_BASE_HI;
>      if ( iommu_intremap )
>          iommu_read_msi_from_ire(&ch->msi, msg);
>  }
> @@ -285,20 +287,19 @@ static void hpet_msi_ack(struct irq_desc
>  
>  static void hpet_msi_set_affinity(struct irq_desc *desc, const cpumask_t
> *mask)
>  {
> -    struct msi_msg msg;
> -    unsigned int dest;
> +    struct hpet_event_channel *ch = desc->action->dev_id;
> +    struct msi_msg msg = ch->msi.msg;
>  
> -    dest = set_desc_affinity(desc, mask);
> -    if (dest == BAD_APICID)
> +    msg.dest32 = set_desc_affinity(desc, mask);
> +    if ( msg.dest32 == BAD_APICID )
>          return;
>  
> -    hpet_msi_read(desc->action->dev_id, &msg);
>      msg.data &= ~MSI_DATA_VECTOR_MASK;
>      msg.data |= MSI_DATA_VECTOR(desc->arch.vector);
>      msg.address_lo &= ~MSI_ADDR_DEST_ID_MASK;
> -    msg.address_lo |= MSI_ADDR_DEST_ID(dest);
> -    msg.dest32 = dest;
> -    hpet_msi_write(desc->action->dev_id, &msg);
> +    msg.address_lo |= MSI_ADDR_DEST_ID(msg.dest32);
> +    if ( msg.data != ch->msi.msg.data || msg.dest32 != ch->msi.msg.dest32 )
> +        hpet_msi_write(ch, &msg);
>  }
>  
>  /*
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 08:25:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 08:25:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOlPg-00057o-A8; Thu, 18 Oct 2012 08:25:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOlPe-00057f-Ka
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 08:25:06 +0000
Received: from [85.158.143.35:33529] by server-3.bemta-4.messagelabs.com id
	1C/BC-03544-1ECBF705; Thu, 18 Oct 2012 08:25:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1350548705!19285629!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10155 invoked from network); 18 Oct 2012 08:25:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 08:25:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15246794"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 08:24:16 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 09:24:16 +0100
Message-ID: <1350548655.28188.37.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Ian Jackson 
Date: Thu, 18 Oct 2012 09:24:15 +0100
In-Reply-To: <20606.54983.746418.437132@mariner.uk.xensource.com>
References: 
	<2329dca4ef449979b140.1350295791@cosworth.uk.xensource.com>
	<20606.54983.746418.437132@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "linux@eikelenboom.it" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 2 of 5] xl: Introduce xl shutdown --all
 support for xm compatibility
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-17 at 17:03 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH 2 of 5] xl: Introduce xl shutdown --all support for xm compatibility"):
> > xl: Introduce xl shutdown --all support for xm compatibility
> ...> 
> > Based on a patch by Sander Eikelenboom
> ...
> >  int main_shutdown(int argc, char **argv)
> ...
> > +        if (wait_for_it)
> > +            deathws = calloc(nb_domain, sizeof(deathws));
> 
> This should read sizeof(*deathws).  It's a shame we don't have a macro
> to avoid this broken pattern in xl.  In libxl we have GCNEW_ARRAY of
> course.  (In fact in this particular case the two things are both
> pointers so the sizeof() is the same and the bug is theoretical.)

Oops, will fix upon commit, thanks.

> Apart from that,
> 
> Acked-by: Ian Jackson 
> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 08:25:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 08:25:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOlPg-00057o-A8; Thu, 18 Oct 2012 08:25:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOlPe-00057f-Ka
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 08:25:06 +0000
Received: from [85.158.143.35:33529] by server-3.bemta-4.messagelabs.com id
	1C/BC-03544-1ECBF705; Thu, 18 Oct 2012 08:25:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1350548705!19285629!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10155 invoked from network); 18 Oct 2012 08:25:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 08:25:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15246794"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 08:24:16 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 09:24:16 +0100
Message-ID: <1350548655.28188.37.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Ian Jackson 
Date: Thu, 18 Oct 2012 09:24:15 +0100
In-Reply-To: <20606.54983.746418.437132@mariner.uk.xensource.com>
References: 
	<2329dca4ef449979b140.1350295791@cosworth.uk.xensource.com>
	<20606.54983.746418.437132@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "linux@eikelenboom.it" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 2 of 5] xl: Introduce xl shutdown --all
 support for xm compatibility
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-17 at 17:03 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH 2 of 5] xl: Introduce xl shutdown --all support for xm compatibility"):
> > xl: Introduce xl shutdown --all support for xm compatibility
> ...> 
> > Based on a patch by Sander Eikelenboom
> ...
> >  int main_shutdown(int argc, char **argv)
> ...
> > +        if (wait_for_it)
> > +            deathws = calloc(nb_domain, sizeof(deathws));
> 
> This should read sizeof(*deathws).  It's a shame we don't have a macro
> to avoid this broken pattern in xl.  In libxl we have GCNEW_ARRAY of
> course.  (In fact in this particular case the two things are both
> pointers so the sizeof() is the same and the bug is theoretical.)

Oops, will fix upon commit, thanks.

> Apart from that,
> 
> Acked-by: Ian Jackson 
> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 08:32:21 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 08:32:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOlWR-0005KY-AA; Thu, 18 Oct 2012 08:32:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOlWQ-0005KT-EC
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 08:32:06 +0000
Received: from [85.158.137.99:53055] by server-15.bemta-3.messagelabs.com id
	88/5E-10261-58EBF705; Thu, 18 Oct 2012 08:32:05 +0000
X-Env-Sender: zhenzhong.duan@oracle.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1350549123!16993969!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgxODIzOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 453 invoked from network); 18 Oct 2012 08:32:05 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-3.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Oct 2012 08:32:05 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9I8W1rb002271
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for ; Thu, 18 Oct 2012 08:32:02 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9I8VxHb017071
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Thu, 18 Oct 2012 08:32:00 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9I8VxGF022080
	for ; Thu, 18 Oct 2012 03:31:59 -0500
Received: from [10.191.8.122] (/10.191.8.122)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 18 Oct 2012 01:31:59 -0700
Message-ID: <507FBE7F.3010403@oracle.com>
Date: Thu, 18 Oct 2012 16:31:59 +0800
From: Zhenzhong Duan 
Organization: oracle
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: xen-devel , Feng Jin ,
	Ethan Zhao 
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: [Xen-devel] ask a question about ERST
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: zhenzhong.duan@oracle.com
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi maintainer,
I found below patch reverted part of erst header size check.
This lead to mismatch with kernel upstream code and erst disabled on
some machine like X4170 M3/X3-2.
According to the ACPI spec 4.0 and 5.0, the Serialization Header Length
should be the length of Serialization Header.
After revert below patch, xen succeed with erst table init.
So could this patch be reverted now to match acpi spec and kernel upstream?

[root@zhenzhong2 xen-unstable.hg]# hg export 23760
# HG changeset patch
# User Keir Fraser 
# Date 1312909603 -3600
# Node ID ae10d7804168c185166277bcef3b18ffc9227b66
# Parent aca07ff1f0a59cc7ebb5ef76875229b7e99ba3ff
ACPI ERST: Revert change to erst_check_table() to be more permissive.

Permits tables that apparently Xen cannot handle (causes boot failure
on many systems).

Signed-off-by: Keir Fraser 

diff -r aca07ff1f0a5 -r ae10d7804168 xen/drivers/acpi/apei/erst.c
--- a/xen/drivers/acpi/apei/erst.c Tue Aug 09 17:48:16 2011 +0100
+++ b/xen/drivers/acpi/apei/erst.c Tue Aug 09 18:06:43 2011 +0100
@@ -715,13 +715,7 @@

static int __init erst_check_table(struct acpi_table_erst *erst_tab)
{
- /*
- * Some old BIOSes include the ACPI standard header in the ERST header
- * length; new BIOSes do not. Our check allows for both methods.
- */
- if ((erst_tab->header_length !=
- (sizeof(struct acpi_table_erst) - sizeof(erst_tab->header)))
- && (erst_tab->header_length != sizeof(struct acpi_table_erst)))
+ if (erst_tab->header_length != sizeof(struct acpi_table_erst))
return -EINVAL;
if (erst_tab->header.length < sizeof(struct acpi_table_erst))
return -EINVAL;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 08:32:21 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 08:32:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOlWR-0005KY-AA; Thu, 18 Oct 2012 08:32:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOlWQ-0005KT-EC
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 08:32:06 +0000
Received: from [85.158.137.99:53055] by server-15.bemta-3.messagelabs.com id
	88/5E-10261-58EBF705; Thu, 18 Oct 2012 08:32:05 +0000
X-Env-Sender: zhenzhong.duan@oracle.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1350549123!16993969!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgxODIzOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 453 invoked from network); 18 Oct 2012 08:32:05 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-3.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Oct 2012 08:32:05 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9I8W1rb002271
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for ; Thu, 18 Oct 2012 08:32:02 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9I8VxHb017071
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Thu, 18 Oct 2012 08:32:00 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9I8VxGF022080
	for ; Thu, 18 Oct 2012 03:31:59 -0500
Received: from [10.191.8.122] (/10.191.8.122)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 18 Oct 2012 01:31:59 -0700
Message-ID: <507FBE7F.3010403@oracle.com>
Date: Thu, 18 Oct 2012 16:31:59 +0800
From: Zhenzhong Duan 
Organization: oracle
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: xen-devel , Feng Jin ,
	Ethan Zhao 
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: [Xen-devel] ask a question about ERST
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: zhenzhong.duan@oracle.com
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi maintainer,
I found below patch reverted part of erst header size check.
This lead to mismatch with kernel upstream code and erst disabled on
some machine like X4170 M3/X3-2.
According to the ACPI spec 4.0 and 5.0, the Serialization Header Length
should be the length of Serialization Header.
After revert below patch, xen succeed with erst table init.
So could this patch be reverted now to match acpi spec and kernel upstream?

[root@zhenzhong2 xen-unstable.hg]# hg export 23760
# HG changeset patch
# User Keir Fraser 
# Date 1312909603 -3600
# Node ID ae10d7804168c185166277bcef3b18ffc9227b66
# Parent aca07ff1f0a59cc7ebb5ef76875229b7e99ba3ff
ACPI ERST: Revert change to erst_check_table() to be more permissive.

Permits tables that apparently Xen cannot handle (causes boot failure
on many systems).

Signed-off-by: Keir Fraser 

diff -r aca07ff1f0a5 -r ae10d7804168 xen/drivers/acpi/apei/erst.c
--- a/xen/drivers/acpi/apei/erst.c Tue Aug 09 17:48:16 2011 +0100
+++ b/xen/drivers/acpi/apei/erst.c Tue Aug 09 18:06:43 2011 +0100
@@ -715,13 +715,7 @@

static int __init erst_check_table(struct acpi_table_erst *erst_tab)
{
- /*
- * Some old BIOSes include the ACPI standard header in the ERST header
- * length; new BIOSes do not. Our check allows for both methods.
- */
- if ((erst_tab->header_length !=
- (sizeof(struct acpi_table_erst) - sizeof(erst_tab->header)))
- && (erst_tab->header_length != sizeof(struct acpi_table_erst)))
+ if (erst_tab->header_length != sizeof(struct acpi_table_erst))
return -EINVAL;
if (erst_tab->header.length < sizeof(struct acpi_table_erst))
return -EINVAL;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 08:34:13 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 08:34:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOlYI-0005Rr-1B; Thu, 18 Oct 2012 08:34:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOlYG-0005Rj-93; Thu, 18 Oct 2012 08:34:00 +0000
Received: from [193.109.254.147:41773] by server-7.bemta-14.messagelabs.com id
	AD/02-24122-7FEBF705; Thu, 18 Oct 2012 08:33:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1350549233!10404688!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12454 invoked from network); 18 Oct 2012 08:33:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 08:33:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15247068"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 08:33:53 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 09:33:53 +0100
Message-ID: <1350549232.28188.39.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Keir Fraser 
Date: Thu, 18 Oct 2012 09:33:52 +0100
In-Reply-To: 
References: 
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge ,
	"xen-devel@lists.xensource.com" ,
	Dan Magenheimer , Mauro ,
	Olivier Hanesse ,
	Jan Beulich , Xen Users ,
	Mark Adams 
Subject: Re: [Xen-devel] [Xen-users]   Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-18 at 08:55 +0100, Keir Fraser wrote:
> On 18/10/2012 08:40, "Ian Campbell"  wrote:
> 
> > On Wed, 2012-10-17 at 17:15 +0100, Keir Fraser wrote:
> >> @@ -540,6 +541,14 @@ static void plt_overflow(void *unused)
> >>          plt_wrap = __read_platform_stime(plt_stamp64 + plt_mask + 1);
> >>          if ( ABS(plt_wrap - now) > ABS(plt_now - now) )
> >>              break;
> >> +        rdtscll(tsc);
> >> +        printk("XXX plt_overflow: plt_now=%"PRIx64" plt_wrap=%"PRIx64
> >> +               " now=%"PRIx64" old_stamp=%"PRIx64" new_stamp=%"PRIx64
> >> +               " plt_stamp64=%"PRIx64" plt_mask=%"PRIx64
> >> +               " tsc=%"PRIx64" tsc_stamp=%"PRIx64"\n",
> >> +               plt_now, plt_wrap, now, old_stamp, plt_stamp, plt_stamp64,
> >> +               plt_mask, tsc, this_cpu(cpu_time).local_tsc_stamp);
> >> +        break;
> > 
> > Is the break here, making the following update to plt_stamp64 dead code
> > deliberate?
> 
> Yes, it's a hack to disable the timer-has-apparently-wrapped workaround.

OK, good.

I wonder if this explains some of the issues which have been plaguing
Debian Squeeze (4.0 based) for a while now. I'll see if I can get
someone there to give it a go.

Ian.

> 
>  -- Keir
> 
> >>          plt_stamp64 += plt_mask + 1;
> >>      }
> >>      if ( i != 0 )
> > 
> > Ian.
> > 
> > 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 08:34:13 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 08:34:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOlYI-0005Rr-1B; Thu, 18 Oct 2012 08:34:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOlYG-0005Rj-93; Thu, 18 Oct 2012 08:34:00 +0000
Received: from [193.109.254.147:41773] by server-7.bemta-14.messagelabs.com id
	AD/02-24122-7FEBF705; Thu, 18 Oct 2012 08:33:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1350549233!10404688!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12454 invoked from network); 18 Oct 2012 08:33:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 08:33:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15247068"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 08:33:53 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 09:33:53 +0100
Message-ID: <1350549232.28188.39.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Keir Fraser 
Date: Thu, 18 Oct 2012 09:33:52 +0100
In-Reply-To: 
References: 
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge ,
	"xen-devel@lists.xensource.com" ,
	Dan Magenheimer , Mauro ,
	Olivier Hanesse ,
	Jan Beulich , Xen Users ,
	Mark Adams 
Subject: Re: [Xen-devel] [Xen-users]   Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-18 at 08:55 +0100, Keir Fraser wrote:
> On 18/10/2012 08:40, "Ian Campbell"  wrote:
> 
> > On Wed, 2012-10-17 at 17:15 +0100, Keir Fraser wrote:
> >> @@ -540,6 +541,14 @@ static void plt_overflow(void *unused)
> >>          plt_wrap = __read_platform_stime(plt_stamp64 + plt_mask + 1);
> >>          if ( ABS(plt_wrap - now) > ABS(plt_now - now) )
> >>              break;
> >> +        rdtscll(tsc);
> >> +        printk("XXX plt_overflow: plt_now=%"PRIx64" plt_wrap=%"PRIx64
> >> +               " now=%"PRIx64" old_stamp=%"PRIx64" new_stamp=%"PRIx64
> >> +               " plt_stamp64=%"PRIx64" plt_mask=%"PRIx64
> >> +               " tsc=%"PRIx64" tsc_stamp=%"PRIx64"\n",
> >> +               plt_now, plt_wrap, now, old_stamp, plt_stamp, plt_stamp64,
> >> +               plt_mask, tsc, this_cpu(cpu_time).local_tsc_stamp);
> >> +        break;
> > 
> > Is the break here, making the following update to plt_stamp64 dead code
> > deliberate?
> 
> Yes, it's a hack to disable the timer-has-apparently-wrapped workaround.

OK, good.

I wonder if this explains some of the issues which have been plaguing
Debian Squeeze (4.0 based) for a while now. I'll see if I can get
someone there to give it a go.

Ian.

> 
>  -- Keir
> 
> >>          plt_stamp64 += plt_mask + 1;
> >>      }
> >>      if ( i != 0 )
> > 
> > Ian.
> > 
> > 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 08:35:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 08:35:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOlZR-0005bt-57; Thu, 18 Oct 2012 08:35:13 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOlZQ-0005bi-FS
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 08:35:12 +0000
Received: from [193.109.254.147:44940] by server-1.bemta-14.messagelabs.com id
	76/5D-20415-F3FBF705; Thu, 18 Oct 2012 08:35:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1350549309!10493320!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8402 invoked from network); 18 Oct 2012 08:35:10 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 08:35:10 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15247108"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 08:35:09 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 09:35:09 +0100
Message-ID: <1350549309.28188.40.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: "xen-devel@lists.xen.org" 
Date: Thu, 18 Oct 2012 09:35:09 +0100
In-Reply-To: 
References: 
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "linux@eikelenboom.it" ,
	Ian Jackson 
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl shutdown compatibility with xm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-10-15 at 11:09 +0100, Ian Campbell wrote:
> The following implements xm compatibility for the xl shutdown command
> and a prerequisite bug fix.
> 
> In particular add --all and --wait which are used by the xendomains
> initscript. It also adds the same options to xl reboot.

Applied these bits (first three patches) with Ian's ack.

> Lastly it cleans up and simplifies option parsing.

Ian had comments on #5 and it logically belongs with #4 so I have
skipped both for now.

Thanks.

> 
> The xl shutdown/reboot patches should go into 4.2.1, the option
> parsing cleanups should not.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 08:35:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 08:35:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOlZR-0005bt-57; Thu, 18 Oct 2012 08:35:13 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOlZQ-0005bi-FS
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 08:35:12 +0000
Received: from [193.109.254.147:44940] by server-1.bemta-14.messagelabs.com id
	76/5D-20415-F3FBF705; Thu, 18 Oct 2012 08:35:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1350549309!10493320!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8402 invoked from network); 18 Oct 2012 08:35:10 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 08:35:10 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15247108"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 08:35:09 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 09:35:09 +0100
Message-ID: <1350549309.28188.40.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: "xen-devel@lists.xen.org" 
Date: Thu, 18 Oct 2012 09:35:09 +0100
In-Reply-To: 
References: 
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "linux@eikelenboom.it" ,
	Ian Jackson 
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl shutdown compatibility with xm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-10-15 at 11:09 +0100, Ian Campbell wrote:
> The following implements xm compatibility for the xl shutdown command
> and a prerequisite bug fix.
> 
> In particular add --all and --wait which are used by the xendomains
> initscript. It also adds the same options to xl reboot.

Applied these bits (first three patches) with Ian's ack.

> Lastly it cleans up and simplifies option parsing.

Ian had comments on #5 and it logically belongs with #4 so I have
skipped both for now.

Thanks.

> 
> The xl shutdown/reboot patches should go into 4.2.1, the option
> parsing cleanups should not.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 08:35:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 08:35:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOlZU-0005cn-I3; Thu, 18 Oct 2012 08:35:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOlZT-0005cG-60
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 08:35:15 +0000
Received: from [85.158.138.51:30302] by server-15.bemta-3.messagelabs.com id
	F5/05-10261-24FBF705; Thu, 18 Oct 2012 08:35:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1350549313!27223001!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2258 invoked from network); 18 Oct 2012 08:35:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 08:35:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15247111"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 08:35:12 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 09:35:12 +0100
Message-ID: <1350549312.28188.41.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Thu, 18 Oct 2012 09:35:12 +0100
In-Reply-To: <20121017182736.GA25845@phenom.dumpdata.com>
References: <507CC8F4.4080103@oracle.com>
	<20121017182736.GA25845@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: chuang cao , Joe Jin ,
	"xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH] tools: xend: fix wrong condition check for
 xml file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-17 at 19:27 +0100, Konrad Rzeszutek Wilk wrote:
> On Tue, Oct 16, 2012 at 10:39:48AM +0800, Joe Jin wrote:
> > Hi Konrad,
> > 
> > Would you please review below fix?
> 
> Reviewed-by: Konrad Rzeszutek Wilk 

Applied, thanks.

> > 
> > Thanks,
> > Joe
> > 
> > 
> > In commit e8d40584, it intended to check xml file size and when empty will
> > return, the condition should be "if os.path.getsize(xml_path) == 0" rather
> > then "if not os.path.getsize(xml_path) == 0".
> > 
> > Signed-off-by: Chuang Cao 
> > Signed-off-by: Joe Jin 
> > ---
> >  tools/python/xen/xend/XendStateStore.py | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/tools/python/xen/xend/XendStateStore.py b/tools/python/xen/xend/XendStateStore.py
> > index 17a29f1..a66181d 100644
> > --- a/tools/python/xen/xend/XendStateStore.py
> > +++ b/tools/python/xen/xend/XendStateStore.py
> > @@ -101,7 +101,7 @@ class XendStateStore:
> >          if not os.path.exists(xml_path):
> >              return {}
> >  
> > -        if not os.path.getsize(xml_path) == 0:
> > +        if os.path.getsize(xml_path) == 0:
> >              return {}
> >  
> >          dom = minidom.parse(xml_path)
> > -- 
> > 1.7.11.7
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 08:35:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 08:35:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOlZU-0005cn-I3; Thu, 18 Oct 2012 08:35:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOlZT-0005cG-60
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 08:35:15 +0000
Received: from [85.158.138.51:30302] by server-15.bemta-3.messagelabs.com id
	F5/05-10261-24FBF705; Thu, 18 Oct 2012 08:35:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1350549313!27223001!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2258 invoked from network); 18 Oct 2012 08:35:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 08:35:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15247111"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 08:35:12 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 09:35:12 +0100
Message-ID: <1350549312.28188.41.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Thu, 18 Oct 2012 09:35:12 +0100
In-Reply-To: <20121017182736.GA25845@phenom.dumpdata.com>
References: <507CC8F4.4080103@oracle.com>
	<20121017182736.GA25845@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: chuang cao , Joe Jin ,
	"xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH] tools: xend: fix wrong condition check for
 xml file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-17 at 19:27 +0100, Konrad Rzeszutek Wilk wrote:
> On Tue, Oct 16, 2012 at 10:39:48AM +0800, Joe Jin wrote:
> > Hi Konrad,
> > 
> > Would you please review below fix?
> 
> Reviewed-by: Konrad Rzeszutek Wilk 

Applied, thanks.

> > 
> > Thanks,
> > Joe
> > 
> > 
> > In commit e8d40584, it intended to check xml file size and when empty will
> > return, the condition should be "if os.path.getsize(xml_path) == 0" rather
> > then "if not os.path.getsize(xml_path) == 0".
> > 
> > Signed-off-by: Chuang Cao 
> > Signed-off-by: Joe Jin 
> > ---
> >  tools/python/xen/xend/XendStateStore.py | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/tools/python/xen/xend/XendStateStore.py b/tools/python/xen/xend/XendStateStore.py
> > index 17a29f1..a66181d 100644
> > --- a/tools/python/xen/xend/XendStateStore.py
> > +++ b/tools/python/xen/xend/XendStateStore.py
> > @@ -101,7 +101,7 @@ class XendStateStore:
> >          if not os.path.exists(xml_path):
> >              return {}
> >  
> > -        if not os.path.getsize(xml_path) == 0:
> > +        if os.path.getsize(xml_path) == 0:
> >              return {}
> >  
> >          dom = minidom.parse(xml_path)
> > -- 
> > 1.7.11.7
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 08:35:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 08:35:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOlZW-0005de-VU; Thu, 18 Oct 2012 08:35:18 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOlZV-0005cl-1T
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 08:35:17 +0000
Received: from [193.109.254.147:58973] by server-4.bemta-14.messagelabs.com id
	2E/54-04248-44FBF705; Thu, 18 Oct 2012 08:35:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1350549309!10493320!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8911 invoked from network); 18 Oct 2012 08:35:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 08:35:15 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15247113"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 08:35:15 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 09:35:15 +0100
Message-ID: <1350549314.28188.42.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Olaf Hering 
Date: Thu, 18 Oct 2012 09:35:14 +0100
In-Reply-To: 
References: 
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 0 of 8] tools: various packaging fixes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-10-15 at 14:44 +0100, Olaf Hering wrote:
> The following changes fix some rpmlint warnings and correct the
> sysconfig metadata used by YaST2.
> 
> Please consider this series also for 4.2.1 to reduce the amount of
> patches in xen.src.rpm. Thanks.

All ack-ed and applied, thanks.

> 
> Olaf
> 
> Changes:
> stubdom: fix rpmlint warning spurious-executable-perm
> blktap2/libvhd: fix rpmlint warning spurious-executable-perm
> blktap: fix rpmlint warning spurious-executable-perm
> hotplug/Linux: add sysconfig tags to xencommons
> hotplug: install hotplugpath.sh as data file
> stubdom: install stubdompath.sh as data file
> hotplug/Linux: correct sysconfig tag in xendomains
> hotplug/Linux: install sysconfig files as data files
> 
>  stubdom/Makefile                                |    5 +++--
>  tools/blktap/lib/Makefile                       |   10 ++++++----
>  tools/blktap2/vhd/lib/Makefile                  |    2 +-
>  tools/hotplug/Linux/Makefile                    |    4 ++--
>  tools/hotplug/Linux/init.d/sysconfig.xencommons |   16 ++++++++++++++++
>  tools/hotplug/Linux/init.d/sysconfig.xendomains |    2 +-
>  tools/hotplug/common/Makefile                   |    4 ++--
>  7 files changed, 31 insertions(+), 12 deletions(-)
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 08:35:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 08:35:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOlZW-0005de-VU; Thu, 18 Oct 2012 08:35:18 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOlZV-0005cl-1T
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 08:35:17 +0000
Received: from [193.109.254.147:58973] by server-4.bemta-14.messagelabs.com id
	2E/54-04248-44FBF705; Thu, 18 Oct 2012 08:35:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1350549309!10493320!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8911 invoked from network); 18 Oct 2012 08:35:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 08:35:15 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15247113"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 08:35:15 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 09:35:15 +0100
Message-ID: <1350549314.28188.42.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Olaf Hering 
Date: Thu, 18 Oct 2012 09:35:14 +0100
In-Reply-To: 
References: 
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 0 of 8] tools: various packaging fixes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-10-15 at 14:44 +0100, Olaf Hering wrote:
> The following changes fix some rpmlint warnings and correct the
> sysconfig metadata used by YaST2.
> 
> Please consider this series also for 4.2.1 to reduce the amount of
> patches in xen.src.rpm. Thanks.

All ack-ed and applied, thanks.

> 
> Olaf
> 
> Changes:
> stubdom: fix rpmlint warning spurious-executable-perm
> blktap2/libvhd: fix rpmlint warning spurious-executable-perm
> blktap: fix rpmlint warning spurious-executable-perm
> hotplug/Linux: add sysconfig tags to xencommons
> hotplug: install hotplugpath.sh as data file
> stubdom: install stubdompath.sh as data file
> hotplug/Linux: correct sysconfig tag in xendomains
> hotplug/Linux: install sysconfig files as data files
> 
>  stubdom/Makefile                                |    5 +++--
>  tools/blktap/lib/Makefile                       |   10 ++++++----
>  tools/blktap2/vhd/lib/Makefile                  |    2 +-
>  tools/hotplug/Linux/Makefile                    |    4 ++--
>  tools/hotplug/Linux/init.d/sysconfig.xencommons |   16 ++++++++++++++++
>  tools/hotplug/Linux/init.d/sysconfig.xendomains |    2 +-
>  tools/hotplug/common/Makefile                   |    4 ++--
>  7 files changed, 31 insertions(+), 12 deletions(-)
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 08:35:28 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 08:35:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOlZZ-0005eV-D6; Thu, 18 Oct 2012 08:35:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOlZY-0005dw-7j
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 08:35:20 +0000
Received: from [193.109.254.147:33602] by server-14.bemta-14.messagelabs.com
	id CF/40-20054-74FBF705; Thu, 18 Oct 2012 08:35:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1350549309!10493320!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9184 invoked from network); 18 Oct 2012 08:35:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 08:35:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15247116"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 08:35:17 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 09:35:17 +0100
Message-ID: <1350549317.28188.43.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Ian Jackson 
Date: Thu, 18 Oct 2012 09:35:17 +0100
In-Reply-To: <20600.17791.486117.993788@mariner.uk.xensource.com>
References: <1350056739.14806.119.camel@zakaz.uk.xensource.com>
	<1350057020.14806.120.camel@zakaz.uk.xensource.com>
	<1350057962.14806.122.camel@zakaz.uk.xensource.com>
	<20600.17791.486117.993788@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Roger Pau Monne , xen-devel 
Subject: Re: [Xen-devel] Unable to start a domain with no disks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-12 at 17:29 +0100, Ian Jackson wrote:

> Subject: [PATCH] libxl: ao: cope with fast ao completion with progess events
[...]
> Signed-off-by: Ian Jackson 

Acked-by: Ian Campbell 

and applied, thanks.

> 
> diff -r 8aadb3204cfa tools/libxl/libxl_internal.h
> --- a/tools/libxl/libxl_internal.h	Thu Sep 06 21:41:27 2012 +0200
> +++ b/tools/libxl/libxl_internal.h	Fri Oct 12 17:20:10 2012 +0100
> @@ -1709,10 +1709,12 @@ _hidden void libxl__egc_cleanup(libxl__e
>  
>  #define AO_INPROGRESS ({                                        \
>          libxl_ctx *ao__ctx = libxl__gc_owner(&ao->gc);          \
> +        CTX_UNLOCK;                                             \
> +        EGC_FREE;                                               \
> +        CTX_LOCK;                                               \
>          int ao__rc = libxl__ao_inprogress(ao,                   \
>                                 __FILE__, __LINE__, __func__);   \
>          libxl__ctx_unlock(ao__ctx); /* gc is now invalid */     \
> -        EGC_FREE;                                               \
>          (ao__rc);                                               \
>     })
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 08:35:28 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 08:35:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOlZZ-0005eV-D6; Thu, 18 Oct 2012 08:35:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOlZY-0005dw-7j
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 08:35:20 +0000
Received: from [193.109.254.147:33602] by server-14.bemta-14.messagelabs.com
	id CF/40-20054-74FBF705; Thu, 18 Oct 2012 08:35:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1350549309!10493320!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9184 invoked from network); 18 Oct 2012 08:35:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 08:35:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15247116"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 08:35:17 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 09:35:17 +0100
Message-ID: <1350549317.28188.43.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Ian Jackson 
Date: Thu, 18 Oct 2012 09:35:17 +0100
In-Reply-To: <20600.17791.486117.993788@mariner.uk.xensource.com>
References: <1350056739.14806.119.camel@zakaz.uk.xensource.com>
	<1350057020.14806.120.camel@zakaz.uk.xensource.com>
	<1350057962.14806.122.camel@zakaz.uk.xensource.com>
	<20600.17791.486117.993788@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Roger Pau Monne , xen-devel 
Subject: Re: [Xen-devel] Unable to start a domain with no disks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-12 at 17:29 +0100, Ian Jackson wrote:

> Subject: [PATCH] libxl: ao: cope with fast ao completion with progess events
[...]
> Signed-off-by: Ian Jackson 

Acked-by: Ian Campbell 

and applied, thanks.

> 
> diff -r 8aadb3204cfa tools/libxl/libxl_internal.h
> --- a/tools/libxl/libxl_internal.h	Thu Sep 06 21:41:27 2012 +0200
> +++ b/tools/libxl/libxl_internal.h	Fri Oct 12 17:20:10 2012 +0100
> @@ -1709,10 +1709,12 @@ _hidden void libxl__egc_cleanup(libxl__e
>  
>  #define AO_INPROGRESS ({                                        \
>          libxl_ctx *ao__ctx = libxl__gc_owner(&ao->gc);          \
> +        CTX_UNLOCK;                                             \
> +        EGC_FREE;                                               \
> +        CTX_LOCK;                                               \
>          int ao__rc = libxl__ao_inprogress(ao,                   \
>                                 __FILE__, __LINE__, __func__);   \
>          libxl__ctx_unlock(ao__ctx); /* gc is now invalid */     \
> -        EGC_FREE;                                               \
>          (ao__rc);                                               \
>     })
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 08:35:34 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 08:35:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOlZh-0005jn-QC; Thu, 18 Oct 2012 08:35:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOlZg-0005i9-3d
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 08:35:28 +0000
Received: from [85.158.139.83:49422] by server-14.bemta-5.messagelabs.com id
	0F/A9-24068-F4FBF705; Thu, 18 Oct 2012 08:35:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1350549326!34833010!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4348 invoked from network); 18 Oct 2012 08:35:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 08:35:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15247121"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 08:35:22 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 09:35:22 +0100
Message-ID: <1350549321.28188.44.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Olaf Hering 
Date: Thu, 18 Oct 2012 09:35:21 +0100
In-Reply-To: <20121015084252.GA27650@aepfle.de>
References: <5aa14d5afe6b1f35b230.1350143968@probook.site>
	<20121013223558.GA19665@aepfle.de>
	<1350288065.14440.5.camel@dagon.hellion.org.uk>
	<20121015084252.GA27650@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] hotplug/Linux: close lockfd after lock
 attempt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-10-15 at 09:42 +0100, Olaf Hering wrote:
> On Mon, Oct 15, Ian Campbell wrote:
> 
> > On Sat, 2012-10-13 at 23:35 +0100, Olaf Hering wrote:
> > > On Sat, Oct 13, Olaf Hering wrote:
> > > 
> > > > hotplug/Linux: close lockfd after lock attempt
> > > > 
> > > > When a HVM guest is shutdown some of the 'remove' events can not claim
> > > > the lock for some reason. Instead they try to grab the lock in a busy
> > > > loop, until udev reaps the xen-hotplug-cleanup helper.
> > > > After analyzing the resulting logfile its not obvious what the cause is.
> > > > The only explanation is that bash (?) gets confused if the same lockfd
> > > > is opened again and again. Closing it in each iteration seem to fix the
> > > > issue.
> > > 
> > > Can be reproduced with this testcase on sles11sp2, not on openSuSE 11.4:
> > 
> > So this is a bash bug? Have you reported it against bash?
> 
> It does not happen with a newer bash: bash 3.2 from sles11sp2 fails,
> bash 4.1 from openSuSE 11.4 works.

I added a comment:
        # Some versions of bash appear to be buggy if the same 
        # $_lockfile is opened repeatedly. Close the current fd here.
and reference to the bash version in the commit message.

acked + applied. Thanks.
> 
> Olaf



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 08:35:34 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 08:35:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOlZh-0005jn-QC; Thu, 18 Oct 2012 08:35:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOlZg-0005i9-3d
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 08:35:28 +0000
Received: from [85.158.139.83:49422] by server-14.bemta-5.messagelabs.com id
	0F/A9-24068-F4FBF705; Thu, 18 Oct 2012 08:35:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1350549326!34833010!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4348 invoked from network); 18 Oct 2012 08:35:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 08:35:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15247121"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 08:35:22 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 09:35:22 +0100
Message-ID: <1350549321.28188.44.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Olaf Hering 
Date: Thu, 18 Oct 2012 09:35:21 +0100
In-Reply-To: <20121015084252.GA27650@aepfle.de>
References: <5aa14d5afe6b1f35b230.1350143968@probook.site>
	<20121013223558.GA19665@aepfle.de>
	<1350288065.14440.5.camel@dagon.hellion.org.uk>
	<20121015084252.GA27650@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] hotplug/Linux: close lockfd after lock
 attempt
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-10-15 at 09:42 +0100, Olaf Hering wrote:
> On Mon, Oct 15, Ian Campbell wrote:
> 
> > On Sat, 2012-10-13 at 23:35 +0100, Olaf Hering wrote:
> > > On Sat, Oct 13, Olaf Hering wrote:
> > > 
> > > > hotplug/Linux: close lockfd after lock attempt
> > > > 
> > > > When a HVM guest is shutdown some of the 'remove' events can not claim
> > > > the lock for some reason. Instead they try to grab the lock in a busy
> > > > loop, until udev reaps the xen-hotplug-cleanup helper.
> > > > After analyzing the resulting logfile its not obvious what the cause is.
> > > > The only explanation is that bash (?) gets confused if the same lockfd
> > > > is opened again and again. Closing it in each iteration seem to fix the
> > > > issue.
> > > 
> > > Can be reproduced with this testcase on sles11sp2, not on openSuSE 11.4:
> > 
> > So this is a bash bug? Have you reported it against bash?
> 
> It does not happen with a newer bash: bash 3.2 from sles11sp2 fails,
> bash 4.1 from openSuSE 11.4 works.

I added a comment:
        # Some versions of bash appear to be buggy if the same 
        # $_lockfile is opened repeatedly. Close the current fd here.
and reference to the bash version in the commit message.

acked + applied. Thanks.
> 
> Olaf



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 08:35:48 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 08:35:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOlZs-0005p9-6z; Thu, 18 Oct 2012 08:35:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOlZq-0005oF-JP
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 08:35:38 +0000
Received: from [85.158.139.83:52403] by server-3.bemta-5.messagelabs.com id
	86/1A-28618-95FBF705; Thu, 18 Oct 2012 08:35:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1350549336!21322154!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10303 invoked from network); 18 Oct 2012 08:35:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 08:35:37 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15247138"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 08:35:36 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 09:35:36 +0100
Message-ID: <1350549336.28188.45.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Olaf Hering 
Date: Thu, 18 Oct 2012 09:35:36 +0100
In-Reply-To: 
References: 
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] stubdom: fix compile errors in grub
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-10 at 15:40 +0100, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering 
> # Date 1349880048 -7200
> # Node ID a74e22faa1c90a38345be8fdf333101c07166671
> # Parent  384714804b9b2a9742cc45dffaa43b749b85513b
> stubdom: fix compile errors in grub
> 
> Building xen.rpm in SLES11 started to fail due to these compiler
> warnings:
> 
> [ 1436s] ../grub-upstream/netboot/fsys_tftp.c:213: warning: operation on 'block' may be undefined
> [ 1437s] ../grub-upstream/netboot/main.c:444: warning: operation on 'block' may be undefined
> 
> [ 1234s] E: xen sequence-point ../grub-upstream/netboot/fsys_tftp.c:213
> [ 1234s] E: xen sequence-point ../grub-upstream/netboot/main.c:444
> 
> The reason for this is that the assignment is done twice:
>  tp.u.ack.block = ((uint16_t)( (((uint16_t)((block = prevblock)) & (uint16_t)0x00ffU) << 8) | (((uint16_t)((block = prevblock)) & (uint16_t)0xff00U) >> 8)));
> 
> Fix this package build error by adding another patch for grub, which
> moves the assignment out of the macro usage.
> 
> Signed-off-by: Olaf Hering 
> 
> diff -r 384714804b9b -r a74e22faa1c9 stubdom/grub.patches/70compiler_warnings.diff
> --- /dev/null
> +++ b/stubdom/grub.patches/70compiler_warnings.diff
> @@ -0,0 +1,45 @@
> +[ 1436s] ../grub-upstream/netboot/fsys_tftp.c:213: warning: operation on 'block' may be undefined
> +[ 1437s] ../grub-upstream/netboot/main.c:444: warning: operation on 'block' may be undefined
> +
> +[ 1234s] E: xen sequence-point ../grub-upstream/netboot/fsys_tftp.c:213
> +[ 1234s] E: xen sequence-point ../grub-upstream/netboot/main.c:444
> +
> +---
> + netboot/fsys_tftp.c |    5 ++++-
> + netboot/main.c      |    5 ++++-
> + 2 files changed, 8 insertions(+), 2 deletions(-)
> +
> +Index: grub-0.97/netboot/fsys_tftp.c
> +===================================================================
> +--- grub-0.97.orig/netboot/fsys_tftp.c
> ++++ grub-0.97/netboot/fsys_tftp.c
> +@@ -209,8 +209,11 @@ buf_fill (int abort)
> + 	break;
> + 
> +       if ((block || bcounter) && (block != prevblock + (unsigned short) 1))
> ++      {
> ++	      block = prevblock;
> + 	/* Block order should be continuous */
> +-	tp.u.ack.block = htons (block = prevblock);
> ++	tp.u.ack.block = htons (block);

Both here and the other hunk this line should have been pushed in
another level I think? The existing code looks lie a terrible mixture of
tabs and spaces though, and there's no upstream to send this to so:

Acked and applied.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 08:35:48 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 08:35:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOlZs-0005p9-6z; Thu, 18 Oct 2012 08:35:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOlZq-0005oF-JP
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 08:35:38 +0000
Received: from [85.158.139.83:52403] by server-3.bemta-5.messagelabs.com id
	86/1A-28618-95FBF705; Thu, 18 Oct 2012 08:35:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1350549336!21322154!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10303 invoked from network); 18 Oct 2012 08:35:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 08:35:37 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15247138"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 08:35:36 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 09:35:36 +0100
Message-ID: <1350549336.28188.45.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Olaf Hering 
Date: Thu, 18 Oct 2012 09:35:36 +0100
In-Reply-To: 
References: 
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] stubdom: fix compile errors in grub
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-10 at 15:40 +0100, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering 
> # Date 1349880048 -7200
> # Node ID a74e22faa1c90a38345be8fdf333101c07166671
> # Parent  384714804b9b2a9742cc45dffaa43b749b85513b
> stubdom: fix compile errors in grub
> 
> Building xen.rpm in SLES11 started to fail due to these compiler
> warnings:
> 
> [ 1436s] ../grub-upstream/netboot/fsys_tftp.c:213: warning: operation on 'block' may be undefined
> [ 1437s] ../grub-upstream/netboot/main.c:444: warning: operation on 'block' may be undefined
> 
> [ 1234s] E: xen sequence-point ../grub-upstream/netboot/fsys_tftp.c:213
> [ 1234s] E: xen sequence-point ../grub-upstream/netboot/main.c:444
> 
> The reason for this is that the assignment is done twice:
>  tp.u.ack.block = ((uint16_t)( (((uint16_t)((block = prevblock)) & (uint16_t)0x00ffU) << 8) | (((uint16_t)((block = prevblock)) & (uint16_t)0xff00U) >> 8)));
> 
> Fix this package build error by adding another patch for grub, which
> moves the assignment out of the macro usage.
> 
> Signed-off-by: Olaf Hering 
> 
> diff -r 384714804b9b -r a74e22faa1c9 stubdom/grub.patches/70compiler_warnings.diff
> --- /dev/null
> +++ b/stubdom/grub.patches/70compiler_warnings.diff
> @@ -0,0 +1,45 @@
> +[ 1436s] ../grub-upstream/netboot/fsys_tftp.c:213: warning: operation on 'block' may be undefined
> +[ 1437s] ../grub-upstream/netboot/main.c:444: warning: operation on 'block' may be undefined
> +
> +[ 1234s] E: xen sequence-point ../grub-upstream/netboot/fsys_tftp.c:213
> +[ 1234s] E: xen sequence-point ../grub-upstream/netboot/main.c:444
> +
> +---
> + netboot/fsys_tftp.c |    5 ++++-
> + netboot/main.c      |    5 ++++-
> + 2 files changed, 8 insertions(+), 2 deletions(-)
> +
> +Index: grub-0.97/netboot/fsys_tftp.c
> +===================================================================
> +--- grub-0.97.orig/netboot/fsys_tftp.c
> ++++ grub-0.97/netboot/fsys_tftp.c
> +@@ -209,8 +209,11 @@ buf_fill (int abort)
> + 	break;
> + 
> +       if ((block || bcounter) && (block != prevblock + (unsigned short) 1))
> ++      {
> ++	      block = prevblock;
> + 	/* Block order should be continuous */
> +-	tp.u.ack.block = htons (block = prevblock);
> ++	tp.u.ack.block = htons (block);

Both here and the other hunk this line should have been pushed in
another level I think? The existing code looks lie a terrible mixture of
tabs and spaces though, and there's no upstream to send this to so:

Acked and applied.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 08:35:51 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 08:35:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOlZy-0005sU-K9; Thu, 18 Oct 2012 08:35:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOlZx-0005rR-5w
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 08:35:45 +0000
Received: from [85.158.139.83:38209] by server-15.bemta-5.messagelabs.com id
	63/EA-28599-06FBF705; Thu, 18 Oct 2012 08:35:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1350549343!30864653!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2998 invoked from network); 18 Oct 2012 08:35:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 08:35:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15247141"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 08:35:43 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 09:35:42 +0100
Message-ID: <1350549342.28188.46.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Jan Beulich 
Date: Thu, 18 Oct 2012 09:35:42 +0100
In-Reply-To: <507FD0D902000078000A23CA@nat28.tlf.novell.com>
References: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
	<1350314444-17148-9-git-send-email-ian.campbell@citrix.com>
	<507FC2BF02000078000A2351@nat28.tlf.novell.com>
	<1350545548.28188.13.camel@dagon.hellion.org.uk>
	<507FD0D902000078000A23CA@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" ,
	"xen-devel@lists.xen.org" ,
	"Keir	\(Xen.org\)" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 09/10] xen: remove XEN_GUEST_HANDLE(ulong)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-18 at 08:50 +0100, Jan Beulich wrote:
> >>> On 18.10.12 at 09:32, Ian Campbell  wrote:
> > On Thu, 2012-10-18 at 07:50 +0100, Jan Beulich wrote:
> >> >>> On 15.10.12 at 17:20, Ian Campbell  wrote:
> >> These two must be wrapped in __XEN_INTERFACE_VERSION__
> >> conditionals (and __XEN_LATEST_INTERFACE_VERSION__ needs
> >> to be bumped accordingly), since the various guest handles are
> >> distinct types (i.e. consumers will fail to build if not updated).
> > 
> > Are there external consumers of gnttab_setup_table?
> 
> We can't know - it's a public, not tools-only interface.

Right.

> > Nevertheless, here is the fix.
> > 
> > 8<-----------------------------------------------------
> > 
> > # HG changeset patch
> > # User Ian Campbell 
> > # Date 1350544609 -3600
> > # Node ID 68f0f7ed3e7b3b7b4b9dbc692a448421ebc31035
> > # Parent  5c402b905e00fb0871c3f439c8391dd3cfb3bc10
> > xen: retain ulong guest handle for older consumers.
> > 
> > 26072:5529b91bd2e4 removed this but we need to keep it around for
> > older consumers. Bump __XEN_LATEST_INTERFACE_VERSION__ accordingly.
> > 
> > Signed-off-by: Ian Campbell 
> 
> Acked-by: Jan Beulich 

Applied, thanks.

> 
> > diff -r 5c402b905e00 -r 68f0f7ed3e7b xen/include/public/grant_table.h
> > --- a/xen/include/public/grant_table.h	Wed Oct 17 16:43:55 2012 +0100
> > +++ b/xen/include/public/grant_table.h	Thu Oct 18 08:16:49 2012 +0100
> > @@ -385,7 +385,11 @@ struct gnttab_setup_table {
> >      uint32_t nr_frames;
> >      /* OUT parameters. */
> >      int16_t  status;              /* => enum grant_status */
> > +#if __XEN_INTERFACE_VERSION__ < 0x00040300 
> > +    XEN_GUEST_HANDLE(ulong) frame_list;
> > +#else
> >      XEN_GUEST_HANDLE(xen_pfn_t) frame_list;
> > +#endif
> >  };
> >  typedef struct gnttab_setup_table gnttab_setup_table_t;
> >  DEFINE_XEN_GUEST_HANDLE(gnttab_setup_table_t);
> > diff -r 5c402b905e00 -r 68f0f7ed3e7b xen/include/public/xen-compat.h
> > --- a/xen/include/public/xen-compat.h	Wed Oct 17 16:43:55 2012 +0100
> > +++ b/xen/include/public/xen-compat.h	Thu Oct 18 08:16:49 2012 +0100
> > @@ -27,7 +27,7 @@
> >  #ifndef __XEN_PUBLIC_XEN_COMPAT_H__
> >  #define __XEN_PUBLIC_XEN_COMPAT_H__
> >  
> > -#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040200
> > +#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040300
> >  
> >  #if defined(__XEN__) || defined(__XEN_TOOLS__)
> >  /* Xen is built with matching headers and implements the latest interface. 
> > */
> > diff -r 5c402b905e00 -r 68f0f7ed3e7b xen/include/public/xen.h
> > --- a/xen/include/public/xen.h	Wed Oct 17 16:43:55 2012 +0100
> > +++ b/xen/include/public/xen.h	Thu Oct 18 08:16:49 2012 +0100
> > @@ -43,6 +43,10 @@ DEFINE_XEN_GUEST_HANDLE(char);
> >  __DEFINE_XEN_GUEST_HANDLE(uchar, unsigned char);
> >  DEFINE_XEN_GUEST_HANDLE(int);
> >  __DEFINE_XEN_GUEST_HANDLE(uint,  unsigned int);
> > +#if __XEN_INTERFACE_VERSION__ < 0x00040300 
> > +DEFINE_XEN_GUEST_HANDLE(long);
> > +__DEFINE_XEN_GUEST_HANDLE(ulong, unsigned long);
> > +#endif
> >  DEFINE_XEN_GUEST_HANDLE(void);
> >  
> >  DEFINE_XEN_GUEST_HANDLE(uint64_t);
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 08:35:51 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 08:35:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOlZy-0005sU-K9; Thu, 18 Oct 2012 08:35:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOlZx-0005rR-5w
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 08:35:45 +0000
Received: from [85.158.139.83:38209] by server-15.bemta-5.messagelabs.com id
	63/EA-28599-06FBF705; Thu, 18 Oct 2012 08:35:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1350549343!30864653!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2998 invoked from network); 18 Oct 2012 08:35:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 08:35:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15247141"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 08:35:43 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 09:35:42 +0100
Message-ID: <1350549342.28188.46.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Jan Beulich 
Date: Thu, 18 Oct 2012 09:35:42 +0100
In-Reply-To: <507FD0D902000078000A23CA@nat28.tlf.novell.com>
References: <1350314418.18058.72.camel@zakaz.uk.xensource.com>
	<1350314444-17148-9-git-send-email-ian.campbell@citrix.com>
	<507FC2BF02000078000A2351@nat28.tlf.novell.com>
	<1350545548.28188.13.camel@dagon.hellion.org.uk>
	<507FD0D902000078000A23CA@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" ,
	"xen-devel@lists.xen.org" ,
	"Keir	\(Xen.org\)" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 09/10] xen: remove XEN_GUEST_HANDLE(ulong)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-18 at 08:50 +0100, Jan Beulich wrote:
> >>> On 18.10.12 at 09:32, Ian Campbell  wrote:
> > On Thu, 2012-10-18 at 07:50 +0100, Jan Beulich wrote:
> >> >>> On 15.10.12 at 17:20, Ian Campbell  wrote:
> >> These two must be wrapped in __XEN_INTERFACE_VERSION__
> >> conditionals (and __XEN_LATEST_INTERFACE_VERSION__ needs
> >> to be bumped accordingly), since the various guest handles are
> >> distinct types (i.e. consumers will fail to build if not updated).
> > 
> > Are there external consumers of gnttab_setup_table?
> 
> We can't know - it's a public, not tools-only interface.

Right.

> > Nevertheless, here is the fix.
> > 
> > 8<-----------------------------------------------------
> > 
> > # HG changeset patch
> > # User Ian Campbell 
> > # Date 1350544609 -3600
> > # Node ID 68f0f7ed3e7b3b7b4b9dbc692a448421ebc31035
> > # Parent  5c402b905e00fb0871c3f439c8391dd3cfb3bc10
> > xen: retain ulong guest handle for older consumers.
> > 
> > 26072:5529b91bd2e4 removed this but we need to keep it around for
> > older consumers. Bump __XEN_LATEST_INTERFACE_VERSION__ accordingly.
> > 
> > Signed-off-by: Ian Campbell 
> 
> Acked-by: Jan Beulich 

Applied, thanks.

> 
> > diff -r 5c402b905e00 -r 68f0f7ed3e7b xen/include/public/grant_table.h
> > --- a/xen/include/public/grant_table.h	Wed Oct 17 16:43:55 2012 +0100
> > +++ b/xen/include/public/grant_table.h	Thu Oct 18 08:16:49 2012 +0100
> > @@ -385,7 +385,11 @@ struct gnttab_setup_table {
> >      uint32_t nr_frames;
> >      /* OUT parameters. */
> >      int16_t  status;              /* => enum grant_status */
> > +#if __XEN_INTERFACE_VERSION__ < 0x00040300 
> > +    XEN_GUEST_HANDLE(ulong) frame_list;
> > +#else
> >      XEN_GUEST_HANDLE(xen_pfn_t) frame_list;
> > +#endif
> >  };
> >  typedef struct gnttab_setup_table gnttab_setup_table_t;
> >  DEFINE_XEN_GUEST_HANDLE(gnttab_setup_table_t);
> > diff -r 5c402b905e00 -r 68f0f7ed3e7b xen/include/public/xen-compat.h
> > --- a/xen/include/public/xen-compat.h	Wed Oct 17 16:43:55 2012 +0100
> > +++ b/xen/include/public/xen-compat.h	Thu Oct 18 08:16:49 2012 +0100
> > @@ -27,7 +27,7 @@
> >  #ifndef __XEN_PUBLIC_XEN_COMPAT_H__
> >  #define __XEN_PUBLIC_XEN_COMPAT_H__
> >  
> > -#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040200
> > +#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040300
> >  
> >  #if defined(__XEN__) || defined(__XEN_TOOLS__)
> >  /* Xen is built with matching headers and implements the latest interface. 
> > */
> > diff -r 5c402b905e00 -r 68f0f7ed3e7b xen/include/public/xen.h
> > --- a/xen/include/public/xen.h	Wed Oct 17 16:43:55 2012 +0100
> > +++ b/xen/include/public/xen.h	Thu Oct 18 08:16:49 2012 +0100
> > @@ -43,6 +43,10 @@ DEFINE_XEN_GUEST_HANDLE(char);
> >  __DEFINE_XEN_GUEST_HANDLE(uchar, unsigned char);
> >  DEFINE_XEN_GUEST_HANDLE(int);
> >  __DEFINE_XEN_GUEST_HANDLE(uint,  unsigned int);
> > +#if __XEN_INTERFACE_VERSION__ < 0x00040300 
> > +DEFINE_XEN_GUEST_HANDLE(long);
> > +__DEFINE_XEN_GUEST_HANDLE(ulong, unsigned long);
> > +#endif
> >  DEFINE_XEN_GUEST_HANDLE(void);
> >  
> >  DEFINE_XEN_GUEST_HANDLE(uint64_t);
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 08:39:21 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 08:39:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOldJ-0006ne-FQ; Thu, 18 Oct 2012 08:39:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOldH-0006nC-HM
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 08:39:11 +0000
Received: from [85.158.139.83:20696] by server-5.bemta-5.messagelabs.com id
	ED/CE-09732-E20CF705; Thu, 18 Oct 2012 08:39:10 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-182.messagelabs.com!1350549550!34727791!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NjA3NTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NjA3NTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26015 invoked from network); 18 Oct 2012 08:39:10 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Oct 2012 08:39:10 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll2M7pEAsD
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-081-221.pools.arcor-ip.net [84.57.81.221])
	by smtp.strato.de (jorabe mo1) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id e05404o9I89pEL ;
	Thu, 18 Oct 2012 10:39:09 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 1DA1718642; Thu, 18 Oct 2012 10:39:09 +0200 (CEST)
Date: Thu, 18 Oct 2012 10:39:08 +0200
From: Olaf Hering 
To: Ian Campbell 
Message-ID: <20121018083908.GA26702@aepfle.de>
References: <597f0885494d0441b10c.1350051258@probook.site>
	<1350052613.14806.109.camel@zakaz.uk.xensource.com>
	<20121012144653.GA22206@aepfle.de>
	<1350547552.28188.29.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1350547552.28188.29.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] hotplug/Linux: remove hotplug support,
 rely on udev instead
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Oct 18, Ian Campbell wrote:

> On Fri, 2012-10-12 at 15:46 +0100, Olaf Hering wrote:
> > On Fri, Oct 12, Ian Campbell wrote:
> > 
> > > On Fri, 2012-10-12 at 15:14 +0100, Olaf Hering wrote:
> > > > The patch by itself will have no practical impact unless someone
> > > > attempts to build and run a Xen dom0 on a really old base system.
> > > 
> > > Does anyone have any idea what sort of timeframe hotplug agent stuff
> > > really died in, just so we can document something?
> > 
> > SLES9 (back in 2007) had an early version of udev, hotplug was still in
> > use. It looks like hotplug.rpm was finally dropped from SuSE Linux in 2005.
> 
> 2005 was after 2007 though?
> 
> Any way, I've added "e.g. circa SLES9/2007 or earlier" to the end of the
> commit message and will apply.

Thanks.
SLES9 was branched and released in July 2004, the last service pack #4
was released in December 2007.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 08:39:21 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 08:39:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOldJ-0006ne-FQ; Thu, 18 Oct 2012 08:39:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOldH-0006nC-HM
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 08:39:11 +0000
Received: from [85.158.139.83:20696] by server-5.bemta-5.messagelabs.com id
	ED/CE-09732-E20CF705; Thu, 18 Oct 2012 08:39:10 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-182.messagelabs.com!1350549550!34727791!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NjA3NTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NjA3NTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26015 invoked from network); 18 Oct 2012 08:39:10 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Oct 2012 08:39:10 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll2M7pEAsD
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-081-221.pools.arcor-ip.net [84.57.81.221])
	by smtp.strato.de (jorabe mo1) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id e05404o9I89pEL ;
	Thu, 18 Oct 2012 10:39:09 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 1DA1718642; Thu, 18 Oct 2012 10:39:09 +0200 (CEST)
Date: Thu, 18 Oct 2012 10:39:08 +0200
From: Olaf Hering 
To: Ian Campbell 
Message-ID: <20121018083908.GA26702@aepfle.de>
References: <597f0885494d0441b10c.1350051258@probook.site>
	<1350052613.14806.109.camel@zakaz.uk.xensource.com>
	<20121012144653.GA22206@aepfle.de>
	<1350547552.28188.29.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1350547552.28188.29.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] hotplug/Linux: remove hotplug support,
 rely on udev instead
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Oct 18, Ian Campbell wrote:

> On Fri, 2012-10-12 at 15:46 +0100, Olaf Hering wrote:
> > On Fri, Oct 12, Ian Campbell wrote:
> > 
> > > On Fri, 2012-10-12 at 15:14 +0100, Olaf Hering wrote:
> > > > The patch by itself will have no practical impact unless someone
> > > > attempts to build and run a Xen dom0 on a really old base system.
> > > 
> > > Does anyone have any idea what sort of timeframe hotplug agent stuff
> > > really died in, just so we can document something?
> > 
> > SLES9 (back in 2007) had an early version of udev, hotplug was still in
> > use. It looks like hotplug.rpm was finally dropped from SuSE Linux in 2005.
> 
> 2005 was after 2007 though?
> 
> Any way, I've added "e.g. circa SLES9/2007 or earlier" to the end of the
> commit message and will apply.

Thanks.
SLES9 was branched and released in July 2004, the last service pack #4
was released in December 2007.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 08:47:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 08:47:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOlkj-0007B0-65; Thu, 18 Oct 2012 08:46:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOlki-0007Av-8w
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 08:46:52 +0000
Received: from [85.158.143.35:40539] by server-3.bemta-4.messagelabs.com id
	40/32-03544-BF1CF705; Thu, 18 Oct 2012 08:46:51 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1350549992!14509237!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMzMDUxMQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31249 invoked from network); 18 Oct 2012 08:46:33 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-16.tower-21.messagelabs.com with SMTP;
	18 Oct 2012 08:46:33 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 18 Oct 2012 01:46:31 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,606,1344236400"; d="scan'208";a="236852243"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by fmsmga002.fm.intel.com with ESMTP; 18 Oct 2012 01:46:31 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 18 Oct 2012 01:46:31 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.123]) with mapi id
	14.01.0355.002; Thu, 18 Oct 2012 16:46:28 +0800
From: "Liu, Jinsong" 
To: Keir Fraser , Jan Beulich ,
	xen-devel 
Thread-Topic: [Xen-devel] [PATCH] ACPI/APEI: accept validly sized ERST on
	Intel systems only for now
Thread-Index: AQHNrQSf4s5YR+ZtoEueCL+a96riCJe+K8iAgACUASA=
Date: Thu, 18 Oct 2012 08:46:28 +0000
Message-ID: 
References: <507FCFC102000078000A23C7@nat28.tlf.novell.com>
	
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Wei Wang ,
	"christoph.egger@amd.com" 
Subject: Re: [Xen-devel] [PATCH] ACPI/APEI: accept validly sized ERST on
 Intel systems only for now
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Fine to Intel. Both old and new Intel platform work.

Thanks,
Jinsong

Keir Fraser wrote:
> On 18/10/2012 08:45, "Jan Beulich"  wrote:
> 
>> Various AMD systems (but [unfortunately] not mine) hang when the
>> table size check passes. Allow the check to pass on Intel systems
>> only for now (until someone can actually debug the problem).
>> 
>> Signed-off-by: Jan Beulich 
> 
> Acked-by: Keir Fraser 
> 
>> --- a/xen/drivers/acpi/apei/erst.c
>> +++ b/xen/drivers/acpi/apei/erst.c
>> @@ -769,6 +769,19 @@ static int __init erst_check_table(struc
>> 
>> switch (erst_tab->header_length) {
>> case sizeof(*erst_tab) - sizeof(erst_tab->header):
>> +#ifdef CONFIG_X86
>> +  /* XXX
>> +   * While the rest of the ERST code appears to work on Intel
>> +   * systems with properly sized tables, various AMD systems
>> +   * appear to get hung (at boot time) by allowing this. Until
>> +   * someone with access to suitable hardware can debug this,
>> +   * disable the rest of the code by considering this case +   *
>> invalid. +   */
>> +  if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL) +   return
>> -EINVAL; +  /* fall through */
>> +#endif
>> /*
>> * While invalid per specification, there are (early?) systems
>> * indicating the full header size here, so accept that value too.
>> 
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 08:47:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 08:47:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOlkj-0007B0-65; Thu, 18 Oct 2012 08:46:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOlki-0007Av-8w
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 08:46:52 +0000
Received: from [85.158.143.35:40539] by server-3.bemta-4.messagelabs.com id
	40/32-03544-BF1CF705; Thu, 18 Oct 2012 08:46:51 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1350549992!14509237!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMzMDUxMQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31249 invoked from network); 18 Oct 2012 08:46:33 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-16.tower-21.messagelabs.com with SMTP;
	18 Oct 2012 08:46:33 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 18 Oct 2012 01:46:31 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,606,1344236400"; d="scan'208";a="236852243"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by fmsmga002.fm.intel.com with ESMTP; 18 Oct 2012 01:46:31 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 18 Oct 2012 01:46:31 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.123]) with mapi id
	14.01.0355.002; Thu, 18 Oct 2012 16:46:28 +0800
From: "Liu, Jinsong" 
To: Keir Fraser , Jan Beulich ,
	xen-devel 
Thread-Topic: [Xen-devel] [PATCH] ACPI/APEI: accept validly sized ERST on
	Intel systems only for now
Thread-Index: AQHNrQSf4s5YR+ZtoEueCL+a96riCJe+K8iAgACUASA=
Date: Thu, 18 Oct 2012 08:46:28 +0000
Message-ID: 
References: <507FCFC102000078000A23C7@nat28.tlf.novell.com>
	
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Wei Wang ,
	"christoph.egger@amd.com" 
Subject: Re: [Xen-devel] [PATCH] ACPI/APEI: accept validly sized ERST on
 Intel systems only for now
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Fine to Intel. Both old and new Intel platform work.

Thanks,
Jinsong

Keir Fraser wrote:
> On 18/10/2012 08:45, "Jan Beulich"  wrote:
> 
>> Various AMD systems (but [unfortunately] not mine) hang when the
>> table size check passes. Allow the check to pass on Intel systems
>> only for now (until someone can actually debug the problem).
>> 
>> Signed-off-by: Jan Beulich 
> 
> Acked-by: Keir Fraser 
> 
>> --- a/xen/drivers/acpi/apei/erst.c
>> +++ b/xen/drivers/acpi/apei/erst.c
>> @@ -769,6 +769,19 @@ static int __init erst_check_table(struc
>> 
>> switch (erst_tab->header_length) {
>> case sizeof(*erst_tab) - sizeof(erst_tab->header):
>> +#ifdef CONFIG_X86
>> +  /* XXX
>> +   * While the rest of the ERST code appears to work on Intel
>> +   * systems with properly sized tables, various AMD systems
>> +   * appear to get hung (at boot time) by allowing this. Until
>> +   * someone with access to suitable hardware can debug this,
>> +   * disable the rest of the code by considering this case +   *
>> invalid. +   */
>> +  if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL) +   return
>> -EINVAL; +  /* fall through */
>> +#endif
>> /*
>> * While invalid per specification, there are (early?) systems
>> * indicating the full header size here, so accept that value too.
>> 
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 08:49:12 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 08:49:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOlml-0007Hr-NW; Thu, 18 Oct 2012 08:48:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOlmk-0007Hj-HK
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 08:48:58 +0000
Received: from [85.158.143.35:52803] by server-2.bemta-4.messagelabs.com id
	AB/57-22268-972CF705; Thu, 18 Oct 2012 08:48:57 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-21.messagelabs.com!1350550135!12743250!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0Mzg1MTA=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0Mzg1MTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28090 invoked from network); 18 Oct 2012 08:48:55 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Oct 2012 08:48:55 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll2M7pEAsD
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-081-221.pools.arcor-ip.net [84.57.81.221])
	by smtp.strato.de (josoe mo37) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 4031e8o9I8YDwy ;
	Thu, 18 Oct 2012 10:48:55 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id C584F18642; Thu, 18 Oct 2012 10:48:54 +0200 (CEST)
Date: Thu, 18 Oct 2012 10:48:54 +0200
From: Olaf Hering 
To: Ian Campbell 
Message-ID: <20121018084854.GB26702@aepfle.de>
References: 
	
	<1350548293.28188.34.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1350548293.28188.34.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 4 of 8] hotplug/Linux: add sysconfig tags to
 xencommons
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Oct 18, Ian Campbell wrote:

> On Mon, 2012-10-15 at 14:44 +0100, Olaf Hering wrote:
> > # HG changeset patch
> > # User Olaf Hering 
> > # Date 1350305772 -7200
> > # Node ID ed893d76098bf0e41cd2c1d5d0392b7f36547c45
> > # Parent  ba9b347a31fed0aa57604d2342117282dd38b9bc
> > hotplug/Linux: add sysconfig tags to xencommons
> > 
> > YaST2 sysconfig can logically group the various sysconfig settings if the
> > files are tagged. Add the missing tags to xencommons.
> > See for a description
> > http://old-en.opensuse.org/Packaging/SUSE_Package_Conventions/Sysconfig
> 
> Is this specific to SuSE/YaST2 or a more general standard?

I'm not sure, its most likely specific to YaST2.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 08:49:12 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 08:49:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOlml-0007Hr-NW; Thu, 18 Oct 2012 08:48:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOlmk-0007Hj-HK
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 08:48:58 +0000
Received: from [85.158.143.35:52803] by server-2.bemta-4.messagelabs.com id
	AB/57-22268-972CF705; Thu, 18 Oct 2012 08:48:57 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-21.messagelabs.com!1350550135!12743250!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0Mzg1MTA=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0Mzg1MTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28090 invoked from network); 18 Oct 2012 08:48:55 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Oct 2012 08:48:55 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll2M7pEAsD
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-081-221.pools.arcor-ip.net [84.57.81.221])
	by smtp.strato.de (josoe mo37) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 4031e8o9I8YDwy ;
	Thu, 18 Oct 2012 10:48:55 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id C584F18642; Thu, 18 Oct 2012 10:48:54 +0200 (CEST)
Date: Thu, 18 Oct 2012 10:48:54 +0200
From: Olaf Hering 
To: Ian Campbell 
Message-ID: <20121018084854.GB26702@aepfle.de>
References: 
	
	<1350548293.28188.34.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1350548293.28188.34.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 4 of 8] hotplug/Linux: add sysconfig tags to
 xencommons
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Oct 18, Ian Campbell wrote:

> On Mon, 2012-10-15 at 14:44 +0100, Olaf Hering wrote:
> > # HG changeset patch
> > # User Olaf Hering 
> > # Date 1350305772 -7200
> > # Node ID ed893d76098bf0e41cd2c1d5d0392b7f36547c45
> > # Parent  ba9b347a31fed0aa57604d2342117282dd38b9bc
> > hotplug/Linux: add sysconfig tags to xencommons
> > 
> > YaST2 sysconfig can logically group the various sysconfig settings if the
> > files are tagged. Add the missing tags to xencommons.
> > See for a description
> > http://old-en.opensuse.org/Packaging/SUSE_Package_Conventions/Sysconfig
> 
> Is this specific to SuSE/YaST2 or a more general standard?

I'm not sure, its most likely specific to YaST2.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 09:05:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 09:05:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOm2y-0007sR-7o; Thu, 18 Oct 2012 09:05:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOltx-0007TY-L3; Thu, 18 Oct 2012 08:56:25 +0000
Received: from [85.158.143.99:23483] by server-2.bemta-4.messagelabs.com id
	E7/04-22268-834CF705; Thu, 18 Oct 2012 08:56:24 +0000
X-Env-Sender: mrsanna1@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1350550582!28339333!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14749 invoked from network); 18 Oct 2012 08:56:24 -0000
Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com)
	(209.85.212.43)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 08:56:24 -0000
Received: by mail-vb0-f43.google.com with SMTP id fq11so10441196vbb.30
	for ; Thu, 18 Oct 2012 01:56:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=TfBvdVOS0It+I+Se9Fo/W9Da06ADvyIozvnfaYkYmc4=;
	b=WUxNh1zHzwC/SBsdhln1VQsZ8bocOlvl3Mo+x6PFiQ7Yb4klRmxITVyCIJQtXa67Ft
	m3rOcsn2HGIaU7fYRbenaCIY8WE23rCuzNPBIRtezLL1QJHN9DBC4CgrcVHSPcBqrAZE
	OkCTOGTwgp++/GsKludKwNlyA8efWQgSoqX2AOoZ/PffJZ6AhvLy0fGsKhYcn8zRfzfX
	leVzvcg4x7RlqmZpGsiD5z6lCmwDCHUs6MNOXlhxKnARIVS4RnD2A8pN3roTOPmvvZXt
	bPxs6X3IZ4A4tFOHbF4Mt75bO2UJhrUy5HfK2FgN5WpUzL1t0S9nz9U8AMWITmnKXXuL
	8O2Q==
MIME-Version: 1.0
Received: by 10.52.27.100 with SMTP id s4mr11129287vdg.105.1350550582557; Thu,
	18 Oct 2012 01:56:22 -0700 (PDT)
Received: by 10.58.207.75 with HTTP; Thu, 18 Oct 2012 01:56:22 -0700 (PDT)
In-Reply-To: <1350549232.28188.39.camel@dagon.hellion.org.uk>
References: 
	<1350549232.28188.39.camel@dagon.hellion.org.uk>
Date: Thu, 18 Oct 2012 10:56:22 +0200
Message-ID: 
From: Mauro 
To: Ian Campbell 
X-Mailman-Approved-At: Thu, 18 Oct 2012 09:05:43 +0000
Cc: Jeremy Fitzhardinge ,
	"xen-devel@lists.xensource.com" ,
	Dan Magenheimer ,
	Olivier Hanesse ,
	Keir Fraser , Jan Beulich ,
	Xen Users ,
	Mark Adams 
Subject: Re: [Xen-devel] [Xen-users]  Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 18 October 2012 10:33, Ian Campbell  wrote:
> On Thu, 2012-10-18 at 08:55 +0100, Keir Fraser wrote:
>> On 18/10/2012 08:40, "Ian Campbell"  wrote:
>>
>> > On Wed, 2012-10-17 at 17:15 +0100, Keir Fraser wrote:
>> >> @@ -540,6 +541,14 @@ static void plt_overflow(void *unused)
>> >>          plt_wrap = __read_platform_stime(plt_stamp64 + plt_mask + 1);
>> >>          if ( ABS(plt_wrap - now) > ABS(plt_now - now) )
>> >>              break;
>> >> +        rdtscll(tsc);
>> >> +        printk("XXX plt_overflow: plt_now=%"PRIx64" plt_wrap=%"PRIx64
>> >> +               " now=%"PRIx64" old_stamp=%"PRIx64" new_stamp=%"PRIx64
>> >> +               " plt_stamp64=%"PRIx64" plt_mask=%"PRIx64
>> >> +               " tsc=%"PRIx64" tsc_stamp=%"PRIx64"\n",
>> >> +               plt_now, plt_wrap, now, old_stamp, plt_stamp, plt_stamp64,
>> >> +               plt_mask, tsc, this_cpu(cpu_time).local_tsc_stamp);
>> >> +        break;
>> >
>> > Is the break here, making the following update to plt_stamp64 dead code
>> > deliberate?
>>
>> Yes, it's a hack to disable the timer-has-apparently-wrapped workaround.
>
> OK, good.
>
> I wonder if this explains some of the issues which have been plaguing
> Debian Squeeze (4.0 based) for a while now. I'll see if I can get
> someone there to give it a go.

If that patch works debian kernel maintainers can be advised if they
can include that patch and release a new kernel working for squeeze.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 09:05:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 09:05:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOm2y-0007sR-7o; Thu, 18 Oct 2012 09:05:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOltx-0007TY-L3; Thu, 18 Oct 2012 08:56:25 +0000
Received: from [85.158.143.99:23483] by server-2.bemta-4.messagelabs.com id
	E7/04-22268-834CF705; Thu, 18 Oct 2012 08:56:24 +0000
X-Env-Sender: mrsanna1@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1350550582!28339333!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14749 invoked from network); 18 Oct 2012 08:56:24 -0000
Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com)
	(209.85.212.43)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 08:56:24 -0000
Received: by mail-vb0-f43.google.com with SMTP id fq11so10441196vbb.30
	for ; Thu, 18 Oct 2012 01:56:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=TfBvdVOS0It+I+Se9Fo/W9Da06ADvyIozvnfaYkYmc4=;
	b=WUxNh1zHzwC/SBsdhln1VQsZ8bocOlvl3Mo+x6PFiQ7Yb4klRmxITVyCIJQtXa67Ft
	m3rOcsn2HGIaU7fYRbenaCIY8WE23rCuzNPBIRtezLL1QJHN9DBC4CgrcVHSPcBqrAZE
	OkCTOGTwgp++/GsKludKwNlyA8efWQgSoqX2AOoZ/PffJZ6AhvLy0fGsKhYcn8zRfzfX
	leVzvcg4x7RlqmZpGsiD5z6lCmwDCHUs6MNOXlhxKnARIVS4RnD2A8pN3roTOPmvvZXt
	bPxs6X3IZ4A4tFOHbF4Mt75bO2UJhrUy5HfK2FgN5WpUzL1t0S9nz9U8AMWITmnKXXuL
	8O2Q==
MIME-Version: 1.0
Received: by 10.52.27.100 with SMTP id s4mr11129287vdg.105.1350550582557; Thu,
	18 Oct 2012 01:56:22 -0700 (PDT)
Received: by 10.58.207.75 with HTTP; Thu, 18 Oct 2012 01:56:22 -0700 (PDT)
In-Reply-To: <1350549232.28188.39.camel@dagon.hellion.org.uk>
References: 
	<1350549232.28188.39.camel@dagon.hellion.org.uk>
Date: Thu, 18 Oct 2012 10:56:22 +0200
Message-ID: 
From: Mauro 
To: Ian Campbell 
X-Mailman-Approved-At: Thu, 18 Oct 2012 09:05:43 +0000
Cc: Jeremy Fitzhardinge ,
	"xen-devel@lists.xensource.com" ,
	Dan Magenheimer ,
	Olivier Hanesse ,
	Keir Fraser , Jan Beulich ,
	Xen Users ,
	Mark Adams 
Subject: Re: [Xen-devel] [Xen-users]  Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 18 October 2012 10:33, Ian Campbell  wrote:
> On Thu, 2012-10-18 at 08:55 +0100, Keir Fraser wrote:
>> On 18/10/2012 08:40, "Ian Campbell"  wrote:
>>
>> > On Wed, 2012-10-17 at 17:15 +0100, Keir Fraser wrote:
>> >> @@ -540,6 +541,14 @@ static void plt_overflow(void *unused)
>> >>          plt_wrap = __read_platform_stime(plt_stamp64 + plt_mask + 1);
>> >>          if ( ABS(plt_wrap - now) > ABS(plt_now - now) )
>> >>              break;
>> >> +        rdtscll(tsc);
>> >> +        printk("XXX plt_overflow: plt_now=%"PRIx64" plt_wrap=%"PRIx64
>> >> +               " now=%"PRIx64" old_stamp=%"PRIx64" new_stamp=%"PRIx64
>> >> +               " plt_stamp64=%"PRIx64" plt_mask=%"PRIx64
>> >> +               " tsc=%"PRIx64" tsc_stamp=%"PRIx64"\n",
>> >> +               plt_now, plt_wrap, now, old_stamp, plt_stamp, plt_stamp64,
>> >> +               plt_mask, tsc, this_cpu(cpu_time).local_tsc_stamp);
>> >> +        break;
>> >
>> > Is the break here, making the following update to plt_stamp64 dead code
>> > deliberate?
>>
>> Yes, it's a hack to disable the timer-has-apparently-wrapped workaround.
>
> OK, good.
>
> I wonder if this explains some of the issues which have been plaguing
> Debian Squeeze (4.0 based) for a while now. I'll see if I can get
> someone there to give it a go.

If that patch works debian kernel maintainers can be advised if they
can include that patch and release a new kernel working for squeeze.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 09:36:59 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 09:36:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOmWr-0008I8-3l; Thu, 18 Oct 2012 09:36:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOmWq-0008Hy-6e; Thu, 18 Oct 2012 09:36:36 +0000
Received: from [85.158.138.51:60973] by server-6.bemta-3.messagelabs.com id
	15/F4-32375-3ADCF705; Thu, 18 Oct 2012 09:36:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1350552994!25962316!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18334 invoked from network); 18 Oct 2012 09:36:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 09:36:34 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15249161"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 09:36:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 10:36:32 +0100
Message-ID: <1350552990.2460.89.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Mauro 
Date: Thu, 18 Oct 2012 10:36:30 +0100
In-Reply-To: 
References: 
	<1350549232.28188.39.camel@dagon.hellion.org.uk>
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge ,
	"xen-devel@lists.xensource.com" ,
	Dan Magenheimer ,
	Olivier Hanesse ,
	Keir Fraser , Jan Beulich ,
	Xen Users ,
	Mark Adams 
Subject: Re: [Xen-devel] [Xen-users]  Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-18 at 09:56 +0100, Mauro wrote:
> On 18 October 2012 10:33, Ian Campbell  wrote:
> > On Thu, 2012-10-18 at 08:55 +0100, Keir Fraser wrote:
> >> On 18/10/2012 08:40, "Ian Campbell"  wrote:
> >>
> >> > On Wed, 2012-10-17 at 17:15 +0100, Keir Fraser wrote:
> >> >> @@ -540,6 +541,14 @@ static void plt_overflow(void *unused)
> >> >>          plt_wrap = __read_platform_stime(plt_stamp64 + plt_mask + 1);
> >> >>          if ( ABS(plt_wrap - now) > ABS(plt_now - now) )
> >> >>              break;
> >> >> +        rdtscll(tsc);
> >> >> +        printk("XXX plt_overflow: plt_now=%"PRIx64" plt_wrap=%"PRIx64
> >> >> +               " now=%"PRIx64" old_stamp=%"PRIx64" new_stamp=%"PRIx64
> >> >> +               " plt_stamp64=%"PRIx64" plt_mask=%"PRIx64
> >> >> +               " tsc=%"PRIx64" tsc_stamp=%"PRIx64"\n",
> >> >> +               plt_now, plt_wrap, now, old_stamp, plt_stamp, plt_stamp64,
> >> >> +               plt_mask, tsc, this_cpu(cpu_time).local_tsc_stamp);
> >> >> +        break;
> >> >
> >> > Is the break here, making the following update to plt_stamp64 dead code
> >> > deliberate?
> >>
> >> Yes, it's a hack to disable the timer-has-apparently-wrapped workaround.
> >
> > OK, good.
> >
> > I wonder if this explains some of the issues which have been plaguing
> > Debian Squeeze (4.0 based) for a while now. I'll see if I can get
> > someone there to give it a go.
> 
> If that patch works debian kernel maintainers can be advised if they
> can include that patch and release a new kernel working for squeeze.

AFAIK this is a debug patch, not something we would deploy as is but it
should give us the information required to work out a real fix.

Ian


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 09:36:59 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 09:36:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOmWr-0008I8-3l; Thu, 18 Oct 2012 09:36:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOmWq-0008Hy-6e; Thu, 18 Oct 2012 09:36:36 +0000
Received: from [85.158.138.51:60973] by server-6.bemta-3.messagelabs.com id
	15/F4-32375-3ADCF705; Thu, 18 Oct 2012 09:36:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1350552994!25962316!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3NzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18334 invoked from network); 18 Oct 2012 09:36:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 09:36:34 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15249161"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 09:36:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 10:36:32 +0100
Message-ID: <1350552990.2460.89.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Mauro 
Date: Thu, 18 Oct 2012 10:36:30 +0100
In-Reply-To: 
References: 
	<1350549232.28188.39.camel@dagon.hellion.org.uk>
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge ,
	"xen-devel@lists.xensource.com" ,
	Dan Magenheimer ,
	Olivier Hanesse ,
	Keir Fraser , Jan Beulich ,
	Xen Users ,
	Mark Adams 
Subject: Re: [Xen-devel] [Xen-users]  Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-18 at 09:56 +0100, Mauro wrote:
> On 18 October 2012 10:33, Ian Campbell  wrote:
> > On Thu, 2012-10-18 at 08:55 +0100, Keir Fraser wrote:
> >> On 18/10/2012 08:40, "Ian Campbell"  wrote:
> >>
> >> > On Wed, 2012-10-17 at 17:15 +0100, Keir Fraser wrote:
> >> >> @@ -540,6 +541,14 @@ static void plt_overflow(void *unused)
> >> >>          plt_wrap = __read_platform_stime(plt_stamp64 + plt_mask + 1);
> >> >>          if ( ABS(plt_wrap - now) > ABS(plt_now - now) )
> >> >>              break;
> >> >> +        rdtscll(tsc);
> >> >> +        printk("XXX plt_overflow: plt_now=%"PRIx64" plt_wrap=%"PRIx64
> >> >> +               " now=%"PRIx64" old_stamp=%"PRIx64" new_stamp=%"PRIx64
> >> >> +               " plt_stamp64=%"PRIx64" plt_mask=%"PRIx64
> >> >> +               " tsc=%"PRIx64" tsc_stamp=%"PRIx64"\n",
> >> >> +               plt_now, plt_wrap, now, old_stamp, plt_stamp, plt_stamp64,
> >> >> +               plt_mask, tsc, this_cpu(cpu_time).local_tsc_stamp);
> >> >> +        break;
> >> >
> >> > Is the break here, making the following update to plt_stamp64 dead code
> >> > deliberate?
> >>
> >> Yes, it's a hack to disable the timer-has-apparently-wrapped workaround.
> >
> > OK, good.
> >
> > I wonder if this explains some of the issues which have been plaguing
> > Debian Squeeze (4.0 based) for a while now. I'll see if I can get
> > someone there to give it a go.
> 
> If that patch works debian kernel maintainers can be advised if they
> can include that patch and release a new kernel working for squeeze.

AFAIK this is a debug patch, not something we would deploy as is but it
should give us the information required to work out a real fix.

Ian


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 09:40:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 09:40:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOmZw-00006o-Bn; Thu, 18 Oct 2012 09:39:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOmZu-00006S-Bb
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 09:39:46 +0000
Received: from [85.158.139.83:49762] by server-13.bemta-5.messagelabs.com id
	2E/10-30674-16ECF705; Thu, 18 Oct 2012 09:39:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1350553185!32565467!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16768 invoked from network); 18 Oct 2012 09:39:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 09:39:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15249260"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 09:39:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 10:39:44 +0100
Message-ID: <1350553183.2460.91.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: "zhenzhong.duan@oracle.com" 
Date: Thu, 18 Oct 2012 10:39:43 +0100
In-Reply-To: <507FBE7F.3010403@oracle.com>
References: <507FBE7F.3010403@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ethan Zhao , Feng Jin ,
	xen-devel 
Subject: Re: [Xen-devel] ask a question about ERST
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-18 at 09:31 +0100, Zhenzhong Duan wrote:
> Hi maintainer,
> I found below patch reverted part of erst header size check.
> This lead to mismatch with kernel upstream code and erst disabled on
> some machine like X4170 M3/X3-2.
> According to the ACPI spec 4.0 and 5.0, the Serialization Header Length
> should be the length of Serialization Header.
> After revert below patch, xen succeed with erst table init.
> So could this patch be reverted now to match acpi spec and kernel upstream?

Did you ask yourself *why* this patch was reverted and investigate what
has changed in order to resolve that situation?

As it happens this patch has been discussed on xen-devel just this week,
please check the archives.

> 
> [root@zhenzhong2 xen-unstable.hg]# hg export 23760
> # HG changeset patch
> # User Keir Fraser 
> # Date 1312909603 -3600
> # Node ID ae10d7804168c185166277bcef3b18ffc9227b66
> # Parent aca07ff1f0a59cc7ebb5ef76875229b7e99ba3ff
> ACPI ERST: Revert change to erst_check_table() to be more permissive.
> 
> Permits tables that apparently Xen cannot handle (causes boot failure
> on many systems).
> 
> Signed-off-by: Keir Fraser 
> 
> diff -r aca07ff1f0a5 -r ae10d7804168 xen/drivers/acpi/apei/erst.c
> --- a/xen/drivers/acpi/apei/erst.c Tue Aug 09 17:48:16 2011 +0100
> +++ b/xen/drivers/acpi/apei/erst.c Tue Aug 09 18:06:43 2011 +0100
> @@ -715,13 +715,7 @@
> 
> static int __init erst_check_table(struct acpi_table_erst *erst_tab)
> {
> - /*
> - * Some old BIOSes include the ACPI standard header in the ERST header
> - * length; new BIOSes do not. Our check allows for both methods.
> - */
> - if ((erst_tab->header_length !=
> - (sizeof(struct acpi_table_erst) - sizeof(erst_tab->header)))
> - && (erst_tab->header_length != sizeof(struct acpi_table_erst)))
> + if (erst_tab->header_length != sizeof(struct acpi_table_erst))
> return -EINVAL;
> if (erst_tab->header.length < sizeof(struct acpi_table_erst))
> return -EINVAL;
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 09:40:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 09:40:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOmZw-00006o-Bn; Thu, 18 Oct 2012 09:39:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOmZu-00006S-Bb
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 09:39:46 +0000
Received: from [85.158.139.83:49762] by server-13.bemta-5.messagelabs.com id
	2E/10-30674-16ECF705; Thu, 18 Oct 2012 09:39:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1350553185!32565467!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16768 invoked from network); 18 Oct 2012 09:39:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 09:39:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15249260"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 09:39:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 10:39:44 +0100
Message-ID: <1350553183.2460.91.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: "zhenzhong.duan@oracle.com" 
Date: Thu, 18 Oct 2012 10:39:43 +0100
In-Reply-To: <507FBE7F.3010403@oracle.com>
References: <507FBE7F.3010403@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ethan Zhao , Feng Jin ,
	xen-devel 
Subject: Re: [Xen-devel] ask a question about ERST
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-18 at 09:31 +0100, Zhenzhong Duan wrote:
> Hi maintainer,
> I found below patch reverted part of erst header size check.
> This lead to mismatch with kernel upstream code and erst disabled on
> some machine like X4170 M3/X3-2.
> According to the ACPI spec 4.0 and 5.0, the Serialization Header Length
> should be the length of Serialization Header.
> After revert below patch, xen succeed with erst table init.
> So could this patch be reverted now to match acpi spec and kernel upstream?

Did you ask yourself *why* this patch was reverted and investigate what
has changed in order to resolve that situation?

As it happens this patch has been discussed on xen-devel just this week,
please check the archives.

> 
> [root@zhenzhong2 xen-unstable.hg]# hg export 23760
> # HG changeset patch
> # User Keir Fraser 
> # Date 1312909603 -3600
> # Node ID ae10d7804168c185166277bcef3b18ffc9227b66
> # Parent aca07ff1f0a59cc7ebb5ef76875229b7e99ba3ff
> ACPI ERST: Revert change to erst_check_table() to be more permissive.
> 
> Permits tables that apparently Xen cannot handle (causes boot failure
> on many systems).
> 
> Signed-off-by: Keir Fraser 
> 
> diff -r aca07ff1f0a5 -r ae10d7804168 xen/drivers/acpi/apei/erst.c
> --- a/xen/drivers/acpi/apei/erst.c Tue Aug 09 17:48:16 2011 +0100
> +++ b/xen/drivers/acpi/apei/erst.c Tue Aug 09 18:06:43 2011 +0100
> @@ -715,13 +715,7 @@
> 
> static int __init erst_check_table(struct acpi_table_erst *erst_tab)
> {
> - /*
> - * Some old BIOSes include the ACPI standard header in the ERST header
> - * length; new BIOSes do not. Our check allows for both methods.
> - */
> - if ((erst_tab->header_length !=
> - (sizeof(struct acpi_table_erst) - sizeof(erst_tab->header)))
> - && (erst_tab->header_length != sizeof(struct acpi_table_erst)))
> + if (erst_tab->header_length != sizeof(struct acpi_table_erst))
> return -EINVAL;
> if (erst_tab->header.length < sizeof(struct acpi_table_erst))
> return -EINVAL;
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 09:49:03 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 09:49:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOmiY-0000Ql-FM; Thu, 18 Oct 2012 09:48:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOmiX-0000Qf-1M
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 09:48:41 +0000
Received: from [85.158.143.99:24040] by server-2.bemta-4.messagelabs.com id
	5F/DF-22268-870DF705; Thu, 18 Oct 2012 09:48:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1350553719!34573067!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27227 invoked from network); 18 Oct 2012 09:48:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 09:48:40 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15249499"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 09:48:39 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 10:48:39 +0100
Message-ID: <1350553718.2460.93.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Ian Jackson 
Date: Thu, 18 Oct 2012 10:48:38 +0100
In-Reply-To: <20585.51282.934073.747200@mariner.uk.xensource.com>
References: <1348487103-2113-1-git-send-email-ian.campbell@citrix.com>
	<20585.51282.934073.747200@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [DOCDAY PATCH V2] docs: document/mark-up SCHEDOP_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-10-01 at 17:44 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [DOCDAY PATCH V2] docs: document/mark-up SCHEDOP_*"):
> > The biggest subtlety here is there additional argument when op ==
> > SCHEDOP_shutdown and reason == SHUTDOWN_suspend and its interpretation by
> > xc_domain_{save,restore}. Add some clarifying comments to libxc as well.
> > 
> > This patch moves some structs around but there is no functional change
> > other than improved documentation.
> 
> Keir, should Ian just commit this ?  Do you want to review and ack
> it ?  I think it would be nice to be able to get these kind of docs
> patches in quickly in general.

Unless someone objects I'm going to push this patch today PM (BST).

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 09:49:03 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 09:49:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOmiY-0000Ql-FM; Thu, 18 Oct 2012 09:48:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOmiX-0000Qf-1M
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 09:48:41 +0000
Received: from [85.158.143.99:24040] by server-2.bemta-4.messagelabs.com id
	5F/DF-22268-870DF705; Thu, 18 Oct 2012 09:48:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1350553719!34573067!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27227 invoked from network); 18 Oct 2012 09:48:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 09:48:40 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15249499"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 09:48:39 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 10:48:39 +0100
Message-ID: <1350553718.2460.93.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Ian Jackson 
Date: Thu, 18 Oct 2012 10:48:38 +0100
In-Reply-To: <20585.51282.934073.747200@mariner.uk.xensource.com>
References: <1348487103-2113-1-git-send-email-ian.campbell@citrix.com>
	<20585.51282.934073.747200@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [DOCDAY PATCH V2] docs: document/mark-up SCHEDOP_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-10-01 at 17:44 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [DOCDAY PATCH V2] docs: document/mark-up SCHEDOP_*"):
> > The biggest subtlety here is there additional argument when op ==
> > SCHEDOP_shutdown and reason == SHUTDOWN_suspend and its interpretation by
> > xc_domain_{save,restore}. Add some clarifying comments to libxc as well.
> > 
> > This patch moves some structs around but there is no functional change
> > other than improved documentation.
> 
> Keir, should Ian just commit this ?  Do you want to review and ack
> it ?  I think it would be nice to be able to get these kind of docs
> patches in quickly in general.

Unless someone objects I'm going to push this patch today PM (BST).

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 10:02:59 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 10:02:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOmw0-0000h8-3O; Thu, 18 Oct 2012 10:02:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOmvz-0000h3-7a
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 10:02:35 +0000
Received: from [85.158.138.51:62658] by server-10.bemta-3.messagelabs.com id
	DB/86-27386-AB3DF705; Thu, 18 Oct 2012 10:02:34 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1350554552!26758659!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzczMjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23124 invoked from network); 18 Oct 2012 10:02:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 10:02:33 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="41650871"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 10:02:09 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Thu, 18 Oct 2012
	06:02:09 -0400
Message-ID: <507FD39F.4060601@citrix.com>
Date: Thu, 18 Oct 2012 11:02:07 +0100
From: David Vrabel 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	"netdev@vger.kernel.org" , "David S. Miller"
	, Jens Axboe ,
	, Bjorn Helgaas ,
	, Florian Tobias Schandinat
	, , Dmitry Torokhov
	
Cc: David Vrabel 
Subject: [Xen-devel] [PATCH 0/5] drivers: xen frontend devices should handle
 missed backend CLOSING
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Subsystem maintainers, you can either pick up the relevant driver patch
or ack it to go via Konrad's Xen tree.

The series makes all the Xen frontend drivers handle the backend
transitioning to CLOSED without the frontend having previously seen
the backend in the CLOSING state.

Backends shouldn't do this but some do.  e.g., if the host is
XenServer and the toolstack decides to do a forced shutdown of a VBD,
then the blkfront may miss the CLOSING transition and the /dev/xvdX
device will not be destroyed which prevents it being reused.

I have seen systems that ended up in this state but it's not clear if
this was the actual cause.  However, I think in general it's a good
thing to thing to improve the handling of unexpected state
transitions.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 10:02:59 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 10:02:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOmw0-0000h8-3O; Thu, 18 Oct 2012 10:02:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOmvz-0000h3-7a
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 10:02:35 +0000
Received: from [85.158.138.51:62658] by server-10.bemta-3.messagelabs.com id
	DB/86-27386-AB3DF705; Thu, 18 Oct 2012 10:02:34 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1350554552!26758659!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzczMjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23124 invoked from network); 18 Oct 2012 10:02:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 10:02:33 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="41650871"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 10:02:09 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Thu, 18 Oct 2012
	06:02:09 -0400
Message-ID: <507FD39F.4060601@citrix.com>
Date: Thu, 18 Oct 2012 11:02:07 +0100
From: David Vrabel 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	"netdev@vger.kernel.org" , "David S. Miller"
	, Jens Axboe ,
	, Bjorn Helgaas ,
	, Florian Tobias Schandinat
	, , Dmitry Torokhov
	
Cc: David Vrabel 
Subject: [Xen-devel] [PATCH 0/5] drivers: xen frontend devices should handle
 missed backend CLOSING
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Subsystem maintainers, you can either pick up the relevant driver patch
or ack it to go via Konrad's Xen tree.

The series makes all the Xen frontend drivers handle the backend
transitioning to CLOSED without the frontend having previously seen
the backend in the CLOSING state.

Backends shouldn't do this but some do.  e.g., if the host is
XenServer and the toolstack decides to do a forced shutdown of a VBD,
then the blkfront may miss the CLOSING transition and the /dev/xvdX
device will not be destroyed which prevents it being reused.

I have seen systems that ended up in this state but it's not clear if
this was the actual cause.  However, I think in general it's a good
thing to thing to improve the handling of unexpected state
transitions.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 10:04:15 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 10:04:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOmxN-0000p6-OQ; Thu, 18 Oct 2012 10:04:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOmxL-0000on-KR
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 10:03:59 +0000
Received: from [85.158.139.211:8854] by server-10.bemta-5.messagelabs.com id
	A5/2F-01025-D04DF705; Thu, 18 Oct 2012 10:03:57 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1350554635!22829339!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODMzMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7880 invoked from network); 18 Oct 2012 10:03:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 10:03:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="211697483"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 10:03:55 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 06:03:55 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TOmxG-00012c-Md;
	Thu, 18 Oct 2012 11:03:54 +0100
From: David Vrabel 
To: xen-devel@lists.xen.org
Date: Thu, 18 Oct 2012 11:03:34 +0100
Message-ID: <1350554618-14582-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <507FD39F.4060601@citrix.com>
References: <507FD39F.4060601@citrix.com>
MIME-Version: 1.0
Cc: linux-kernel@vger.kernel.org, "David S. Miller" ,
	netdev@vger.kernel.org, David Vrabel ,
	Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 1/5] xen-netfront: handle backend CLOSED without
	CLOSING
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel 

Backend drivers shouldn't transistion to CLOSED unless the frontend is
CLOSED.  If a backend does transition to CLOSED too soon then the
frontend may not see the CLOSING state and will not properly shutdown.

So, treat an unexpected backend CLOSED state the same as CLOSING.

Signed-off-by: David Vrabel 
Acked-by: Konrad Rzeszutek Wilk 
---
Cc: netdev@vger.kernel.org
Cc: "David S. Miller" 
---
 drivers/net/xen-netfront.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index caa0110..40cde51 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1701,7 +1701,6 @@ static void netback_changed(struct xenbus_device *dev,
 	case XenbusStateReconfiguring:
 	case XenbusStateReconfigured:
 	case XenbusStateUnknown:
-	case XenbusStateClosed:
 		break;
 
 	case XenbusStateInitWait:
@@ -1716,6 +1715,10 @@ static void netback_changed(struct xenbus_device *dev,
 		netdev_notify_peers(netdev);
 		break;
 
+	case XenbusStateClosed:
+		if (dev->state == XenbusStateClosed)
+			break;
+		/* Missed the backend's CLOSING state -- fallthrough */
 	case XenbusStateClosing:
 		xenbus_frontend_closed(dev);
 		break;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 10:04:15 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 10:04:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOmxN-0000p6-OQ; Thu, 18 Oct 2012 10:04:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOmxL-0000on-KR
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 10:03:59 +0000
Received: from [85.158.139.211:8854] by server-10.bemta-5.messagelabs.com id
	A5/2F-01025-D04DF705; Thu, 18 Oct 2012 10:03:57 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1350554635!22829339!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODMzMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7880 invoked from network); 18 Oct 2012 10:03:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 10:03:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="211697483"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 10:03:55 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 06:03:55 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TOmxG-00012c-Md;
	Thu, 18 Oct 2012 11:03:54 +0100
From: David Vrabel 
To: xen-devel@lists.xen.org
Date: Thu, 18 Oct 2012 11:03:34 +0100
Message-ID: <1350554618-14582-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <507FD39F.4060601@citrix.com>
References: <507FD39F.4060601@citrix.com>
MIME-Version: 1.0
Cc: linux-kernel@vger.kernel.org, "David S. Miller" ,
	netdev@vger.kernel.org, David Vrabel ,
	Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 1/5] xen-netfront: handle backend CLOSED without
	CLOSING
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel 

Backend drivers shouldn't transistion to CLOSED unless the frontend is
CLOSED.  If a backend does transition to CLOSED too soon then the
frontend may not see the CLOSING state and will not properly shutdown.

So, treat an unexpected backend CLOSED state the same as CLOSING.

Signed-off-by: David Vrabel 
Acked-by: Konrad Rzeszutek Wilk 
---
Cc: netdev@vger.kernel.org
Cc: "David S. Miller" 
---
 drivers/net/xen-netfront.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index caa0110..40cde51 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1701,7 +1701,6 @@ static void netback_changed(struct xenbus_device *dev,
 	case XenbusStateReconfiguring:
 	case XenbusStateReconfigured:
 	case XenbusStateUnknown:
-	case XenbusStateClosed:
 		break;
 
 	case XenbusStateInitWait:
@@ -1716,6 +1715,10 @@ static void netback_changed(struct xenbus_device *dev,
 		netdev_notify_peers(netdev);
 		break;
 
+	case XenbusStateClosed:
+		if (dev->state == XenbusStateClosed)
+			break;
+		/* Missed the backend's CLOSING state -- fallthrough */
 	case XenbusStateClosing:
 		xenbus_frontend_closed(dev);
 		break;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 10:04:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 10:04:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOmxQ-0000pY-E4; Thu, 18 Oct 2012 10:04:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOmxO-0000pB-QI
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 10:04:03 +0000
Received: from [85.158.138.51:33901] by server-11.bemta-3.messagelabs.com id
	18/EE-24008-114DF705; Thu, 18 Oct 2012 10:04:01 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1350554640!34330158!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzczMjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30149 invoked from network); 18 Oct 2012 10:04:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 10:04:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="41651101"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 10:03:59 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 06:03:59 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TOmxL-00012c-4X;
	Thu, 18 Oct 2012 11:03:59 +0100
From: David Vrabel 
To: xen-devel@lists.xen.org
Date: Thu, 18 Oct 2012 11:03:35 +0100
Message-ID: <1350554618-14582-2-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <507FD39F.4060601@citrix.com>
References: <507FD39F.4060601@citrix.com>
MIME-Version: 1.0
Cc: Jens Axboe , linux-kernel@vger.kernel.org,
	David Vrabel ,
	Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 2/5] xen-blkfront: handle backend CLOSED without
	CLOSING
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel 

Backend drivers shouldn't transistion to CLOSED unless the frontend is
CLOSED.  If a backend does transition to CLOSED too soon then the
frontend may not see the CLOSING state and will not properly shutdown.

So, treat an unexpected backend CLOSED state the same as CLOSING.

Signed-off-by: David Vrabel 
Acked-by: Konrad Rzeszutek Wilk 
---
Cc: Jens Axboe 
---
 drivers/block/xen-blkfront.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 007db89..5d162b5 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -1340,13 +1340,16 @@ static void blkback_changed(struct xenbus_device *dev,
 	case XenbusStateReconfiguring:
 	case XenbusStateReconfigured:
 	case XenbusStateUnknown:
-	case XenbusStateClosed:
 		break;
 
 	case XenbusStateConnected:
 		blkfront_connect(info);
 		break;
 
+	case XenbusStateClosed:
+		if (dev->state == XenbusStateClosed)
+			break;
+		/* Missed the backend's Closing state -- fallthrough */
 	case XenbusStateClosing:
 		blkfront_closing(info);
 		break;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 10:04:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 10:04:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOmxQ-0000pY-E4; Thu, 18 Oct 2012 10:04:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOmxO-0000pB-QI
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 10:04:03 +0000
Received: from [85.158.138.51:33901] by server-11.bemta-3.messagelabs.com id
	18/EE-24008-114DF705; Thu, 18 Oct 2012 10:04:01 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1350554640!34330158!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzczMjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30149 invoked from network); 18 Oct 2012 10:04:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 10:04:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="41651101"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 10:03:59 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 06:03:59 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TOmxL-00012c-4X;
	Thu, 18 Oct 2012 11:03:59 +0100
From: David Vrabel 
To: xen-devel@lists.xen.org
Date: Thu, 18 Oct 2012 11:03:35 +0100
Message-ID: <1350554618-14582-2-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <507FD39F.4060601@citrix.com>
References: <507FD39F.4060601@citrix.com>
MIME-Version: 1.0
Cc: Jens Axboe , linux-kernel@vger.kernel.org,
	David Vrabel ,
	Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 2/5] xen-blkfront: handle backend CLOSED without
	CLOSING
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel 

Backend drivers shouldn't transistion to CLOSED unless the frontend is
CLOSED.  If a backend does transition to CLOSED too soon then the
frontend may not see the CLOSING state and will not properly shutdown.

So, treat an unexpected backend CLOSED state the same as CLOSING.

Signed-off-by: David Vrabel 
Acked-by: Konrad Rzeszutek Wilk 
---
Cc: Jens Axboe 
---
 drivers/block/xen-blkfront.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 007db89..5d162b5 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -1340,13 +1340,16 @@ static void blkback_changed(struct xenbus_device *dev,
 	case XenbusStateReconfiguring:
 	case XenbusStateReconfigured:
 	case XenbusStateUnknown:
-	case XenbusStateClosed:
 		break;
 
 	case XenbusStateConnected:
 		blkfront_connect(info);
 		break;
 
+	case XenbusStateClosed:
+		if (dev->state == XenbusStateClosed)
+			break;
+		/* Missed the backend's Closing state -- fallthrough */
 	case XenbusStateClosing:
 		blkfront_closing(info);
 		break;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 10:04:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 10:04:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOmxV-0000qc-7b; Thu, 18 Oct 2012 10:04:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOmxT-0000q7-Qy
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 10:04:08 +0000
Received: from [85.158.143.99:62362] by server-1.bemta-4.messagelabs.com id
	6A/8C-19134-714DF705; Thu, 18 Oct 2012 10:04:07 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1350554643!26418563!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODMzMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16079 invoked from network); 18 Oct 2012 10:04:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 10:04:06 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="211697518"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 10:04:06 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 06:04:06 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TOmxR-00012c-KI;
	Thu, 18 Oct 2012 11:04:05 +0100
From: David Vrabel 
To: xen-devel@lists.xen.org
Date: Thu, 18 Oct 2012 11:03:37 +0100
Message-ID: <1350554618-14582-4-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <507FD39F.4060601@citrix.com>
References: <507FD39F.4060601@citrix.com>
MIME-Version: 1.0
Cc: linux-kernel@vger.kernel.org, linux-fbdev@vger.kernel.org,
	Florian Tobias Schandinat ,
	David Vrabel ,
	Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 4/5] xen-fbfront: handle backend CLOSED without
	CLOSING
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel 

Backend drivers shouldn't transistion to CLOSED unless the frontend is
CLOSED.  If a backend does transition to CLOSED too soon then the
frontend may not see the CLOSING state and will not properly shutdown.

So, treat an unexpected backend CLOSED state the same as CLOSING.

Signed-off-by: David Vrabel 
Acked-by: Konrad Rzeszutek Wilk 
---
Cc: linux-fbdev@vger.kernel.org
Cc: Florian Tobias Schandinat 
---
 drivers/video/xen-fbfront.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/drivers/video/xen-fbfront.c b/drivers/video/xen-fbfront.c
index b7f5173..917bb56 100644
--- a/drivers/video/xen-fbfront.c
+++ b/drivers/video/xen-fbfront.c
@@ -641,7 +641,6 @@ static void xenfb_backend_changed(struct xenbus_device *dev,
 	case XenbusStateReconfiguring:
 	case XenbusStateReconfigured:
 	case XenbusStateUnknown:
-	case XenbusStateClosed:
 		break;
 
 	case XenbusStateInitWait:
@@ -670,6 +669,10 @@ InitWait:
 		info->feature_resize = val;
 		break;
 
+	case XenbusStateClosed:
+		if (dev->state == XenbusStateClosed)
+			break;
+		/* Missed the backend's CLOSING state -- fallthrough */
 	case XenbusStateClosing:
 		xenbus_frontend_closed(dev);
 		break;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 10:04:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 10:04:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOmxV-0000qc-7b; Thu, 18 Oct 2012 10:04:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOmxT-0000q7-Qy
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 10:04:08 +0000
Received: from [85.158.143.99:62362] by server-1.bemta-4.messagelabs.com id
	6A/8C-19134-714DF705; Thu, 18 Oct 2012 10:04:07 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1350554643!26418563!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODMzMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16079 invoked from network); 18 Oct 2012 10:04:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 10:04:06 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="211697518"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 10:04:06 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 06:04:06 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TOmxR-00012c-KI;
	Thu, 18 Oct 2012 11:04:05 +0100
From: David Vrabel 
To: xen-devel@lists.xen.org
Date: Thu, 18 Oct 2012 11:03:37 +0100
Message-ID: <1350554618-14582-4-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <507FD39F.4060601@citrix.com>
References: <507FD39F.4060601@citrix.com>
MIME-Version: 1.0
Cc: linux-kernel@vger.kernel.org, linux-fbdev@vger.kernel.org,
	Florian Tobias Schandinat ,
	David Vrabel ,
	Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 4/5] xen-fbfront: handle backend CLOSED without
	CLOSING
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel 

Backend drivers shouldn't transistion to CLOSED unless the frontend is
CLOSED.  If a backend does transition to CLOSED too soon then the
frontend may not see the CLOSING state and will not properly shutdown.

So, treat an unexpected backend CLOSED state the same as CLOSING.

Signed-off-by: David Vrabel 
Acked-by: Konrad Rzeszutek Wilk 
---
Cc: linux-fbdev@vger.kernel.org
Cc: Florian Tobias Schandinat 
---
 drivers/video/xen-fbfront.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/drivers/video/xen-fbfront.c b/drivers/video/xen-fbfront.c
index b7f5173..917bb56 100644
--- a/drivers/video/xen-fbfront.c
+++ b/drivers/video/xen-fbfront.c
@@ -641,7 +641,6 @@ static void xenfb_backend_changed(struct xenbus_device *dev,
 	case XenbusStateReconfiguring:
 	case XenbusStateReconfigured:
 	case XenbusStateUnknown:
-	case XenbusStateClosed:
 		break;
 
 	case XenbusStateInitWait:
@@ -670,6 +669,10 @@ InitWait:
 		info->feature_resize = val;
 		break;
 
+	case XenbusStateClosed:
+		if (dev->state == XenbusStateClosed)
+			break;
+		/* Missed the backend's CLOSING state -- fallthrough */
 	case XenbusStateClosing:
 		xenbus_frontend_closed(dev);
 		break;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 10:04:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 10:04:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOmxT-0000qC-R5; Thu, 18 Oct 2012 10:04:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOmxS-0000po-5Q
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 10:04:06 +0000
Received: from [85.158.143.99:62252] by server-2.bemta-4.messagelabs.com id
	97/AA-22268-514DF705; Thu, 18 Oct 2012 10:04:05 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1350554643!26418563!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODMzMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15898 invoked from network); 18 Oct 2012 10:04:04 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 10:04:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="211697512"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 10:04:03 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 06:04:03 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TOmxO-00012c-PT;
	Thu, 18 Oct 2012 11:04:02 +0100
From: David Vrabel 
To: xen-devel@lists.xen.org
Date: Thu, 18 Oct 2012 11:03:36 +0100
Message-ID: <1350554618-14582-3-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <507FD39F.4060601@citrix.com>
References: <507FD39F.4060601@citrix.com>
MIME-Version: 1.0
Cc: Bjorn Helgaas , linux-kernel@vger.kernel.org,
	linux-pci@vger.kernel.org, David Vrabel ,
	Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 3/5] xen-pcifront: handle backend CLOSED without
	CLOSING
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel 

Backend drivers shouldn't transistion to CLOSED unless the frontend is
CLOSED.  If a backend does transition to CLOSED too soon then the
frontend may not see the CLOSING state and will not properly shutdown.

So, treat an unexpected backend CLOSED state the same as CLOSING.

Signed-off-by: David Vrabel 
Acked-by: Konrad Rzeszutek Wilk 
---
Cc: linux-pci@vger.kernel.org
Cc: Bjorn Helgaas 
---
 drivers/pci/xen-pcifront.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
index 0aab85a..a0c7312 100644
--- a/drivers/pci/xen-pcifront.c
+++ b/drivers/pci/xen-pcifront.c
@@ -1068,13 +1068,16 @@ static void __init_refok pcifront_backend_changed(struct xenbus_device *xdev,
 	case XenbusStateInitialising:
 	case XenbusStateInitWait:
 	case XenbusStateInitialised:
-	case XenbusStateClosed:
 		break;
 
 	case XenbusStateConnected:
 		pcifront_try_connect(pdev);
 		break;
 
+	case XenbusStateClosed:
+		if (xdev->state == XenbusStateClosed)
+			break;
+		/* Missed the backend's CLOSING state -- fallthrough */
 	case XenbusStateClosing:
 		dev_warn(&xdev->dev, "backend going away!\n");
 		pcifront_try_disconnect(pdev);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 10:04:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 10:04:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOmxT-0000qC-R5; Thu, 18 Oct 2012 10:04:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOmxS-0000po-5Q
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 10:04:06 +0000
Received: from [85.158.143.99:62252] by server-2.bemta-4.messagelabs.com id
	97/AA-22268-514DF705; Thu, 18 Oct 2012 10:04:05 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1350554643!26418563!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODMzMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15898 invoked from network); 18 Oct 2012 10:04:04 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 10:04:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="211697512"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 10:04:03 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 06:04:03 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TOmxO-00012c-PT;
	Thu, 18 Oct 2012 11:04:02 +0100
From: David Vrabel 
To: xen-devel@lists.xen.org
Date: Thu, 18 Oct 2012 11:03:36 +0100
Message-ID: <1350554618-14582-3-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <507FD39F.4060601@citrix.com>
References: <507FD39F.4060601@citrix.com>
MIME-Version: 1.0
Cc: Bjorn Helgaas , linux-kernel@vger.kernel.org,
	linux-pci@vger.kernel.org, David Vrabel ,
	Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 3/5] xen-pcifront: handle backend CLOSED without
	CLOSING
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel 

Backend drivers shouldn't transistion to CLOSED unless the frontend is
CLOSED.  If a backend does transition to CLOSED too soon then the
frontend may not see the CLOSING state and will not properly shutdown.

So, treat an unexpected backend CLOSED state the same as CLOSING.

Signed-off-by: David Vrabel 
Acked-by: Konrad Rzeszutek Wilk 
---
Cc: linux-pci@vger.kernel.org
Cc: Bjorn Helgaas 
---
 drivers/pci/xen-pcifront.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
index 0aab85a..a0c7312 100644
--- a/drivers/pci/xen-pcifront.c
+++ b/drivers/pci/xen-pcifront.c
@@ -1068,13 +1068,16 @@ static void __init_refok pcifront_backend_changed(struct xenbus_device *xdev,
 	case XenbusStateInitialising:
 	case XenbusStateInitWait:
 	case XenbusStateInitialised:
-	case XenbusStateClosed:
 		break;
 
 	case XenbusStateConnected:
 		pcifront_try_connect(pdev);
 		break;
 
+	case XenbusStateClosed:
+		if (xdev->state == XenbusStateClosed)
+			break;
+		/* Missed the backend's CLOSING state -- fallthrough */
 	case XenbusStateClosing:
 		dev_warn(&xdev->dev, "backend going away!\n");
 		pcifront_try_disconnect(pdev);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 10:04:21 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 10:04:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOmxY-0000rR-MF; Thu, 18 Oct 2012 10:04:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOmxX-0000r0-LC
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 10:04:11 +0000
Received: from [85.158.138.51:34733] by server-8.bemta-3.messagelabs.com id
	B2/72-10525-A14DF705; Thu, 18 Oct 2012 10:04:10 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1350554648!34831960!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzczMjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5899 invoked from network); 18 Oct 2012 10:04:10 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 10:04:10 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="41651130"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 10:04:08 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 06:04:08 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TOmxT-00012c-TN;
	Thu, 18 Oct 2012 11:04:07 +0100
From: David Vrabel 
To: xen-devel@lists.xen.org
Date: Thu, 18 Oct 2012 11:03:38 +0100
Message-ID: <1350554618-14582-5-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <507FD39F.4060601@citrix.com>
References: <507FD39F.4060601@citrix.com>
MIME-Version: 1.0
Cc: linux-kernel@vger.kernel.org, linux-input@vger.kernel.org,
	Dmitry Torokhov ,
	David Vrabel ,
	Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 5/5] xen-kbdfront: handle backend CLOSED without
	CLOSING
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel 

Backend drivers shouldn't transistion to CLOSED unless the frontend is
CLOSED.  If a backend does transition to CLOSED too soon then the
frontend may not see the CLOSING state and will not properly shutdown.

So, treat an unexpected backend CLOSED state the same as CLOSING.

Signed-off-by: David Vrabel 
Acked-by: Konrad Rzeszutek Wilk 
---
Cc: linux-input@vger.kernel.org
Cc: Dmitry Torokhov 
---
 drivers/input/misc/xen-kbdfront.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
index 02ca868..6f7d990 100644
--- a/drivers/input/misc/xen-kbdfront.c
+++ b/drivers/input/misc/xen-kbdfront.c
@@ -311,7 +311,6 @@ static void xenkbd_backend_changed(struct xenbus_device *dev,
 	case XenbusStateReconfiguring:
 	case XenbusStateReconfigured:
 	case XenbusStateUnknown:
-	case XenbusStateClosed:
 		break;
 
 	case XenbusStateInitWait:
@@ -350,6 +349,10 @@ InitWait:
 
 		break;
 
+	case XenbusStateClosed:
+		if (dev->state == XenbusStateClosed)
+			break;
+		/* Missed the backend's CLOSING state -- fallthrough */
 	case XenbusStateClosing:
 		xenbus_frontend_closed(dev);
 		break;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 10:04:21 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 10:04:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOmxY-0000rR-MF; Thu, 18 Oct 2012 10:04:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOmxX-0000r0-LC
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 10:04:11 +0000
Received: from [85.158.138.51:34733] by server-8.bemta-3.messagelabs.com id
	B2/72-10525-A14DF705; Thu, 18 Oct 2012 10:04:10 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1350554648!34831960!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzczMjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5899 invoked from network); 18 Oct 2012 10:04:10 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 10:04:10 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="41651130"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 10:04:08 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 06:04:08 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TOmxT-00012c-TN;
	Thu, 18 Oct 2012 11:04:07 +0100
From: David Vrabel 
To: xen-devel@lists.xen.org
Date: Thu, 18 Oct 2012 11:03:38 +0100
Message-ID: <1350554618-14582-5-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <507FD39F.4060601@citrix.com>
References: <507FD39F.4060601@citrix.com>
MIME-Version: 1.0
Cc: linux-kernel@vger.kernel.org, linux-input@vger.kernel.org,
	Dmitry Torokhov ,
	David Vrabel ,
	Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 5/5] xen-kbdfront: handle backend CLOSED without
	CLOSING
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel 

Backend drivers shouldn't transistion to CLOSED unless the frontend is
CLOSED.  If a backend does transition to CLOSED too soon then the
frontend may not see the CLOSING state and will not properly shutdown.

So, treat an unexpected backend CLOSED state the same as CLOSING.

Signed-off-by: David Vrabel 
Acked-by: Konrad Rzeszutek Wilk 
---
Cc: linux-input@vger.kernel.org
Cc: Dmitry Torokhov 
---
 drivers/input/misc/xen-kbdfront.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
index 02ca868..6f7d990 100644
--- a/drivers/input/misc/xen-kbdfront.c
+++ b/drivers/input/misc/xen-kbdfront.c
@@ -311,7 +311,6 @@ static void xenkbd_backend_changed(struct xenbus_device *dev,
 	case XenbusStateReconfiguring:
 	case XenbusStateReconfigured:
 	case XenbusStateUnknown:
-	case XenbusStateClosed:
 		break;
 
 	case XenbusStateInitWait:
@@ -350,6 +349,10 @@ InitWait:
 
 		break;
 
+	case XenbusStateClosed:
+		if (dev->state == XenbusStateClosed)
+			break;
+		/* Missed the backend's CLOSING state -- fallthrough */
 	case XenbusStateClosing:
 		xenbus_frontend_closed(dev);
 		break;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 10:07:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 10:07:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOn0W-0001Rk-AU; Thu, 18 Oct 2012 10:07:16 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOn0U-0001RT-MH
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 10:07:15 +0000
Received: from [193.109.254.147:17282] by server-6.bemta-14.messagelabs.com id
	C8/40-17826-1D4DF705; Thu, 18 Oct 2012 10:07:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1350554745!5328007!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 769 invoked from network); 18 Oct 2012 10:05:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 10:05:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15249981"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 10:05:45 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 11:05:45 +0100
Message-ID: <1350554743.2460.103.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Dave McCracken 
Date: Thu, 18 Oct 2012 11:05:43 +0100
In-Reply-To: <20121012173222.31965.33368.sendpatchset@magnum.int.mccr.org>
References: <20121012173222.31965.33368.sendpatchset@magnum.int.mccr.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: George Dunlap ,
	Xen Developers List ,
	"Keir \(Xen.org\)" 
Subject: Re: [Xen-devel] [PATCH] Make restore work properly with PV
 superpage flag
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George, Keir, and thoughts or opinions on this patch?

On Fri, 2012-10-12 at 18:32 +0100, Dave McCracken wrote:
> For PV guests, the superpage flag means to unconditionally allocate all
> pages as superpages, which is required for Linux hugepages to work.  Support
> for this on restore was not supported.  This patch adds proper support for
> the superpage flag on restore.
> 
> For HVM guests, the superpage flag has been used to mean attempt to allocate
> superpages if possible on restore.  This functionality has been preserved.
> 
> Signed-off-by: Dave McCracken 
> 
> --------
> 
>  xc_domain_restore.c |  130 ++++++++++++++++++++++++++++++++++++++++------------
>  1 file changed, 101 insertions(+), 29 deletions(-)
> 
> 
> --- xen-unstable/tools/libxc/xc_domain_restore.c	2012-08-18 10:04:53.000000000 -0500
> +++ xen-unstable-restore//tools/libxc/xc_domain_restore.c	2012-08-20 07:24:22.000000000 -0500
> @@ -23,6 +23,19 @@
>   *
>   */
>  
> +/*
> + * The superpages flag in restore has two different meanings depending on
> + * the type of domain.
> + *
> + * For an HVM domain, the flag means to look for properly aligned contiguous
> + * pages and try to allocate a superpage to satisfy it.  If that fails,
> + * fall back to small pages.
> + *
> + * For a PV domain, the flag means allocate all memory as superpages.  If that
> + * fails, the restore fails.  This behavior is required for PV guests who
> + * want to use superpages.
> + */
> +
>  #include 
>  #include 
>  
> @@ -41,6 +54,9 @@ struct restore_ctx {
>      xen_pfn_t *live_p2m; /* Live mapping of the table mapping each PFN to its current MFN. */
>      xen_pfn_t *p2m; /* A table mapping each PFN to its new MFN. */
>      xen_pfn_t *p2m_batch; /* A table of P2M mappings in the current region.  */
> +    xen_pfn_t *p2m_saved_batch; /* Copy of p2m_batch array for pv superpage alloc */
> +    int superpages; /* Superpage allocation has been requested */
> +    int hvm;    /* This is an hvm domain */
>      int completed; /* Set when a consistent image is available */
>      int last_checkpoint; /* Set when we should commit to the current checkpoint when it completes. */
>      int compressing; /* Set when sender signals that pages would be sent compressed (for Remus) */
> @@ -49,11 +65,6 @@ struct restore_ctx {
>  
>  #define HEARTBEAT_MS 1000
>  
> -#define SUPERPAGE_PFN_SHIFT  9
> -#define SUPERPAGE_NR_PFNS    (1UL << SUPERPAGE_PFN_SHIFT)
> -
> -#define SUPER_PAGE_START(pfn)    (((pfn) & (SUPERPAGE_NR_PFNS-1)) == 0 )
> -
>  #ifndef __MINIOS__
>  static ssize_t rdexact(xc_interface *xch, struct restore_ctx *ctx,
>                         int fd, void* buf, size_t size)
> @@ -103,6 +114,49 @@ static ssize_t rdexact(xc_interface *xch
>  #else
>  #define RDEXACT read_exact
>  #endif
> +
> +#define SUPERPAGE_PFN_SHIFT  9
> +#define SUPERPAGE_NR_PFNS    (1UL << SUPERPAGE_PFN_SHIFT)
> +#define SUPERPAGE(_pfn) ((_pfn) & (~(SUPERPAGE_NR_PFNS-1)))
> +#define SUPER_PAGE_START(pfn)    (((pfn) & (SUPERPAGE_NR_PFNS-1)) == 0 )

Why this code motion?

> +
> +/*
> +** When we're restoring into a pv superpage-allocated guest, we take
> +** a copy of the p2m_batch array to preserve the pfn, then allocate the
> +** corresponding superpages.  We then fill in the p2m array using the saved
> +** pfns.

So the pfns are not contiguous, but we back them with a super page? IOW
they are super pages in machine address space but not physical address
space?

If they are contig in p-space you just need to save the first one?

> +*/
> +static int alloc_superpage_mfns(
> +    xc_interface *xch, uint32_t dom, struct restore_ctx *ctx, int nr_mfns)
> +{
> +    int i, j, max = 0;
> +    unsigned long pfn, base_pfn, mfn;
> +    
> +    for (i = 0; i < nr_mfns; i++)
> +    {
> +        pfn = ctx->p2m_batch[i];
> +        base_pfn = SUPERPAGE(pfn);
> +        if (ctx->p2m[base_pfn] != (INVALID_P2M_ENTRY-2))
> +        {
> +            ctx->p2m_saved_batch[max] = base_pfn;

Is p2m_saved_batch used anywhere other than in this function? Could it
be a local variable?

> +            ctx->p2m_batch[max] = base_pfn;
> +            max++;
> +            ctx->p2m[base_pfn] = INVALID_P2M_ENTRY-2;

What is this magic -2? Can we get a symbolic constant (probably for the
whole expression)?

> +        }
> +    }
> +    if (xc_domain_populate_physmap_exact(xch, dom, max, SUPERPAGE_PFN_SHIFT,
> +                                         0, ctx->p2m_batch) != 0)
> +        return 1;
> +
> +    for (i = 0; i < max; i++)
> +    {
> +        mfn = ctx->p2m_batch[i];
> +        pfn = ctx->p2m_saved_batch[i];

If the orriginal was != (INVALID_P2M_ENTRY-2) then you didn't initialise
p2m_saved_batch for this index?

> +        for (j = 0; j < SUPERPAGE_NR_PFNS; j++)
> +            ctx->p2m[pfn++] = mfn++;
> +    }
> +    return 0;
> +}
>  /*
>  ** In the state file (or during transfer), all page-table pages are
>  ** converted into a 'canonical' form where references to actual mfns
> @@ -113,7 +167,7 @@ static ssize_t rdexact(xc_interface *xch
>  static int uncanonicalize_pagetable(
>      xc_interface *xch, uint32_t dom, struct restore_ctx *ctx, void *page)
>  {
> -    int i, pte_last, nr_mfns = 0;
> +    int i, rc, pte_last, nr_mfns = 0;
>      unsigned long pfn;
>      uint64_t pte;
>      struct domain_info_context *dinfo = &ctx->dinfo;
> @@ -152,13 +206,20 @@ static int uncanonicalize_pagetable(
>      }
>  
>      /* Allocate the requisite number of mfns. */
> -    if ( nr_mfns &&
> -         (xc_domain_populate_physmap_exact(xch, dom, nr_mfns, 0, 0,
> -                                            ctx->p2m_batch) != 0) )
> -    { 
> -        ERROR("Failed to allocate memory for batch.!\n"); 
> -        errno = ENOMEM;
> -        return 0; 
> +    if (nr_mfns)
> +    {
> +        if (!ctx->hvm && ctx->superpages)
> +            rc = alloc_superpage_mfns(xch, dom, ctx, nr_mfns);
> +        else
> +            rc = xc_domain_populate_physmap_exact(xch, dom, nr_mfns, 0, 0,
> +                                                  ctx->p2m_batch);

Would it be clearer to rename alloc_superpage_mfns to (e.g.)
alloc_guest_mfns and have it start:
	if ( ctx->hvm || !ctx->superpages )
		return xc_domain...

Keeps the allocation logic in one place, since it is repeated again
below.

> +    
> +        if (rc)
> +        {
> +            ERROR("Failed to allocate memory for batch.!\n"); 
> +            errno = ENOMEM;
> +            return 0; 
> +        }
>      }
>      
>      /* Second pass: uncanonicalize each present PTE */
> @@ -1018,8 +1079,8 @@ static int pagebuf_get(xc_interface *xch
>  
>  static int apply_batch(xc_interface *xch, uint32_t dom, struct restore_ctx *ctx,
>                         xen_pfn_t* region_mfn, unsigned long* pfn_type, int pae_extended_cr3,
> -                       unsigned int hvm, struct xc_mmu* mmu,
> -                       pagebuf_t* pagebuf, int curbatch, int superpages)
> +                       struct xc_mmu* mmu,
> +                       pagebuf_t* pagebuf, int curbatch)
>  {
>      int i, j, curpage, nr_mfns;
>      int k, scount;
> @@ -1061,7 +1122,7 @@ static int apply_batch(xc_interface *xch
>                  /* Is this the next expected continuation? */
>                  if ( pfn == superpage_start + scount )
>                  {
> -                    if ( !superpages )
> +                    if ( !ctx->superpages )
>                      {
>                          ERROR("Unexpexted codepath with no superpages");
>                          return -1;
> @@ -1114,16 +1175,17 @@ static int apply_batch(xc_interface *xch
>              }
>  
>              /* Are we ready to start a new superpage candidate? */
> -            if ( superpages && SUPER_PAGE_START(pfn) )
> +            if ( ctx->hvm && ctx->superpages && SUPER_PAGE_START(pfn) )

Can we push the movement of these things into the ctx struct into a
separate preparatory patch so it's easier to see the actual code
changes.

>              {
>                  superpage_start=pfn;
>                  scount++;
> -                continue;
>              }
> -            
> -            /* Add the current pfn to pfn_batch */
> -            ctx->p2m_batch[nr_mfns++] = pfn; 
> -            ctx->p2m[pfn]--;
> +            else
> +            {
> +                /* Add the current pfn to pfn_batch */
> +                ctx->p2m_batch[nr_mfns++] = pfn; 
> +                ctx->p2m[pfn]--;
> +            }
>          }
>      }
>  
> @@ -1144,9 +1206,14 @@ static int apply_batch(xc_interface *xch
>      {
>          DPRINTF("Mapping order 0,  %d; first pfn %lx\n", nr_mfns, ctx->p2m_batch[0]);
>      
> -        if(xc_domain_populate_physmap_exact(xch, dom, nr_mfns, 0,
> -                                            0, ctx->p2m_batch) != 0) 
> -        { 
> +        if (!ctx->hvm && ctx->superpages)
> +            rc = alloc_superpage_mfns(xch, dom, ctx, nr_mfns);
> +        else
> +            rc = xc_domain_populate_physmap_exact(xch, dom, nr_mfns, 0, 0,
> +                                                  ctx->p2m_batch);
> +    
> +        if (rc)
> +        {
>              ERROR("Failed to allocate memory for batch.!\n"); 
>              errno = ENOMEM;
>              return -1;
> @@ -1175,7 +1242,7 @@ static int apply_batch(xc_interface *xch
>               || pagetype == XEN_DOMCTL_PFINFO_XALLOC )
>              region_mfn[i] = ~0UL; /* map will fail but we don't care */
>          else
> -            region_mfn[i] = hvm ? pfn : ctx->p2m[pfn]; 
> +            region_mfn[i] = ctx->hvm ? pfn : ctx->p2m[pfn]; 
>      }
>  
>      /* Map relevant mfns */
> @@ -1298,7 +1365,7 @@ static int apply_batch(xc_interface *xch
>              }
>          }
>  
> -        if ( !hvm &&
> +        if ( !ctx->hvm &&
>               xc_add_mmu_update(xch, mmu,
>                                 (((unsigned long long)mfn) << PAGE_SHIFT)
>                                 | MMU_MACHPHYS_UPDATE, pfn) )
> @@ -1389,6 +1456,9 @@ int xc_domain_restore(xc_interface *xch,
>  
>      memset(ctx, 0, sizeof(*ctx));
>  
> +    ctx->superpages = superpages;
> +    ctx->hvm = hvm;
> +
>      ctxt = xc_hypercall_buffer_alloc(xch, ctxt, sizeof(*ctxt));
>  
>      if ( ctxt == NULL )
> @@ -1452,6 +1522,9 @@ int xc_domain_restore(xc_interface *xch,
>  
>      region_mfn = malloc(ROUNDUP(MAX_BATCH_SIZE * sizeof(xen_pfn_t), PAGE_SHIFT));
>      ctx->p2m_batch = malloc(ROUNDUP(MAX_BATCH_SIZE * sizeof(xen_pfn_t), PAGE_SHIFT));
> +    if (!ctx->hvm && ctx->superpages)
> +        ctx->p2m_saved_batch =
> +            malloc(ROUNDUP(MAX_BATCH_SIZE * sizeof(xen_pfn_t), PAGE_SHIFT));
>  
>      if ( (ctx->p2m == NULL) || (pfn_type == NULL) ||
>           (region_mfn == NULL) || (ctx->p2m_batch == NULL) )
> @@ -1575,8 +1648,7 @@ int xc_domain_restore(xc_interface *xch,
>              int brc;
>  
>              brc = apply_batch(xch, dom, ctx, region_mfn, pfn_type,
> -                              pae_extended_cr3, hvm, mmu, &pagebuf, curbatch,
> -                              superpages);
> +                              pae_extended_cr3, mmu, &pagebuf, curbatch);
>              if ( brc < 0 )
>                  goto out;
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 10:07:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 10:07:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOn0W-0001Rk-AU; Thu, 18 Oct 2012 10:07:16 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOn0U-0001RT-MH
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 10:07:15 +0000
Received: from [193.109.254.147:17282] by server-6.bemta-14.messagelabs.com id
	C8/40-17826-1D4DF705; Thu, 18 Oct 2012 10:07:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1350554745!5328007!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 769 invoked from network); 18 Oct 2012 10:05:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 10:05:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15249981"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 10:05:45 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 11:05:45 +0100
Message-ID: <1350554743.2460.103.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Dave McCracken 
Date: Thu, 18 Oct 2012 11:05:43 +0100
In-Reply-To: <20121012173222.31965.33368.sendpatchset@magnum.int.mccr.org>
References: <20121012173222.31965.33368.sendpatchset@magnum.int.mccr.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: George Dunlap ,
	Xen Developers List ,
	"Keir \(Xen.org\)" 
Subject: Re: [Xen-devel] [PATCH] Make restore work properly with PV
 superpage flag
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George, Keir, and thoughts or opinions on this patch?

On Fri, 2012-10-12 at 18:32 +0100, Dave McCracken wrote:
> For PV guests, the superpage flag means to unconditionally allocate all
> pages as superpages, which is required for Linux hugepages to work.  Support
> for this on restore was not supported.  This patch adds proper support for
> the superpage flag on restore.
> 
> For HVM guests, the superpage flag has been used to mean attempt to allocate
> superpages if possible on restore.  This functionality has been preserved.
> 
> Signed-off-by: Dave McCracken 
> 
> --------
> 
>  xc_domain_restore.c |  130 ++++++++++++++++++++++++++++++++++++++++------------
>  1 file changed, 101 insertions(+), 29 deletions(-)
> 
> 
> --- xen-unstable/tools/libxc/xc_domain_restore.c	2012-08-18 10:04:53.000000000 -0500
> +++ xen-unstable-restore//tools/libxc/xc_domain_restore.c	2012-08-20 07:24:22.000000000 -0500
> @@ -23,6 +23,19 @@
>   *
>   */
>  
> +/*
> + * The superpages flag in restore has two different meanings depending on
> + * the type of domain.
> + *
> + * For an HVM domain, the flag means to look for properly aligned contiguous
> + * pages and try to allocate a superpage to satisfy it.  If that fails,
> + * fall back to small pages.
> + *
> + * For a PV domain, the flag means allocate all memory as superpages.  If that
> + * fails, the restore fails.  This behavior is required for PV guests who
> + * want to use superpages.
> + */
> +
>  #include 
>  #include 
>  
> @@ -41,6 +54,9 @@ struct restore_ctx {
>      xen_pfn_t *live_p2m; /* Live mapping of the table mapping each PFN to its current MFN. */
>      xen_pfn_t *p2m; /* A table mapping each PFN to its new MFN. */
>      xen_pfn_t *p2m_batch; /* A table of P2M mappings in the current region.  */
> +    xen_pfn_t *p2m_saved_batch; /* Copy of p2m_batch array for pv superpage alloc */
> +    int superpages; /* Superpage allocation has been requested */
> +    int hvm;    /* This is an hvm domain */
>      int completed; /* Set when a consistent image is available */
>      int last_checkpoint; /* Set when we should commit to the current checkpoint when it completes. */
>      int compressing; /* Set when sender signals that pages would be sent compressed (for Remus) */
> @@ -49,11 +65,6 @@ struct restore_ctx {
>  
>  #define HEARTBEAT_MS 1000
>  
> -#define SUPERPAGE_PFN_SHIFT  9
> -#define SUPERPAGE_NR_PFNS    (1UL << SUPERPAGE_PFN_SHIFT)
> -
> -#define SUPER_PAGE_START(pfn)    (((pfn) & (SUPERPAGE_NR_PFNS-1)) == 0 )
> -
>  #ifndef __MINIOS__
>  static ssize_t rdexact(xc_interface *xch, struct restore_ctx *ctx,
>                         int fd, void* buf, size_t size)
> @@ -103,6 +114,49 @@ static ssize_t rdexact(xc_interface *xch
>  #else
>  #define RDEXACT read_exact
>  #endif
> +
> +#define SUPERPAGE_PFN_SHIFT  9
> +#define SUPERPAGE_NR_PFNS    (1UL << SUPERPAGE_PFN_SHIFT)
> +#define SUPERPAGE(_pfn) ((_pfn) & (~(SUPERPAGE_NR_PFNS-1)))
> +#define SUPER_PAGE_START(pfn)    (((pfn) & (SUPERPAGE_NR_PFNS-1)) == 0 )

Why this code motion?

> +
> +/*
> +** When we're restoring into a pv superpage-allocated guest, we take
> +** a copy of the p2m_batch array to preserve the pfn, then allocate the
> +** corresponding superpages.  We then fill in the p2m array using the saved
> +** pfns.

So the pfns are not contiguous, but we back them with a super page? IOW
they are super pages in machine address space but not physical address
space?

If they are contig in p-space you just need to save the first one?

> +*/
> +static int alloc_superpage_mfns(
> +    xc_interface *xch, uint32_t dom, struct restore_ctx *ctx, int nr_mfns)
> +{
> +    int i, j, max = 0;
> +    unsigned long pfn, base_pfn, mfn;
> +    
> +    for (i = 0; i < nr_mfns; i++)
> +    {
> +        pfn = ctx->p2m_batch[i];
> +        base_pfn = SUPERPAGE(pfn);
> +        if (ctx->p2m[base_pfn] != (INVALID_P2M_ENTRY-2))
> +        {
> +            ctx->p2m_saved_batch[max] = base_pfn;

Is p2m_saved_batch used anywhere other than in this function? Could it
be a local variable?

> +            ctx->p2m_batch[max] = base_pfn;
> +            max++;
> +            ctx->p2m[base_pfn] = INVALID_P2M_ENTRY-2;

What is this magic -2? Can we get a symbolic constant (probably for the
whole expression)?

> +        }
> +    }
> +    if (xc_domain_populate_physmap_exact(xch, dom, max, SUPERPAGE_PFN_SHIFT,
> +                                         0, ctx->p2m_batch) != 0)
> +        return 1;
> +
> +    for (i = 0; i < max; i++)
> +    {
> +        mfn = ctx->p2m_batch[i];
> +        pfn = ctx->p2m_saved_batch[i];

If the orriginal was != (INVALID_P2M_ENTRY-2) then you didn't initialise
p2m_saved_batch for this index?

> +        for (j = 0; j < SUPERPAGE_NR_PFNS; j++)
> +            ctx->p2m[pfn++] = mfn++;
> +    }
> +    return 0;
> +}
>  /*
>  ** In the state file (or during transfer), all page-table pages are
>  ** converted into a 'canonical' form where references to actual mfns
> @@ -113,7 +167,7 @@ static ssize_t rdexact(xc_interface *xch
>  static int uncanonicalize_pagetable(
>      xc_interface *xch, uint32_t dom, struct restore_ctx *ctx, void *page)
>  {
> -    int i, pte_last, nr_mfns = 0;
> +    int i, rc, pte_last, nr_mfns = 0;
>      unsigned long pfn;
>      uint64_t pte;
>      struct domain_info_context *dinfo = &ctx->dinfo;
> @@ -152,13 +206,20 @@ static int uncanonicalize_pagetable(
>      }
>  
>      /* Allocate the requisite number of mfns. */
> -    if ( nr_mfns &&
> -         (xc_domain_populate_physmap_exact(xch, dom, nr_mfns, 0, 0,
> -                                            ctx->p2m_batch) != 0) )
> -    { 
> -        ERROR("Failed to allocate memory for batch.!\n"); 
> -        errno = ENOMEM;
> -        return 0; 
> +    if (nr_mfns)
> +    {
> +        if (!ctx->hvm && ctx->superpages)
> +            rc = alloc_superpage_mfns(xch, dom, ctx, nr_mfns);
> +        else
> +            rc = xc_domain_populate_physmap_exact(xch, dom, nr_mfns, 0, 0,
> +                                                  ctx->p2m_batch);

Would it be clearer to rename alloc_superpage_mfns to (e.g.)
alloc_guest_mfns and have it start:
	if ( ctx->hvm || !ctx->superpages )
		return xc_domain...

Keeps the allocation logic in one place, since it is repeated again
below.

> +    
> +        if (rc)
> +        {
> +            ERROR("Failed to allocate memory for batch.!\n"); 
> +            errno = ENOMEM;
> +            return 0; 
> +        }
>      }
>      
>      /* Second pass: uncanonicalize each present PTE */
> @@ -1018,8 +1079,8 @@ static int pagebuf_get(xc_interface *xch
>  
>  static int apply_batch(xc_interface *xch, uint32_t dom, struct restore_ctx *ctx,
>                         xen_pfn_t* region_mfn, unsigned long* pfn_type, int pae_extended_cr3,
> -                       unsigned int hvm, struct xc_mmu* mmu,
> -                       pagebuf_t* pagebuf, int curbatch, int superpages)
> +                       struct xc_mmu* mmu,
> +                       pagebuf_t* pagebuf, int curbatch)
>  {
>      int i, j, curpage, nr_mfns;
>      int k, scount;
> @@ -1061,7 +1122,7 @@ static int apply_batch(xc_interface *xch
>                  /* Is this the next expected continuation? */
>                  if ( pfn == superpage_start + scount )
>                  {
> -                    if ( !superpages )
> +                    if ( !ctx->superpages )
>                      {
>                          ERROR("Unexpexted codepath with no superpages");
>                          return -1;
> @@ -1114,16 +1175,17 @@ static int apply_batch(xc_interface *xch
>              }
>  
>              /* Are we ready to start a new superpage candidate? */
> -            if ( superpages && SUPER_PAGE_START(pfn) )
> +            if ( ctx->hvm && ctx->superpages && SUPER_PAGE_START(pfn) )

Can we push the movement of these things into the ctx struct into a
separate preparatory patch so it's easier to see the actual code
changes.

>              {
>                  superpage_start=pfn;
>                  scount++;
> -                continue;
>              }
> -            
> -            /* Add the current pfn to pfn_batch */
> -            ctx->p2m_batch[nr_mfns++] = pfn; 
> -            ctx->p2m[pfn]--;
> +            else
> +            {
> +                /* Add the current pfn to pfn_batch */
> +                ctx->p2m_batch[nr_mfns++] = pfn; 
> +                ctx->p2m[pfn]--;
> +            }
>          }
>      }
>  
> @@ -1144,9 +1206,14 @@ static int apply_batch(xc_interface *xch
>      {
>          DPRINTF("Mapping order 0,  %d; first pfn %lx\n", nr_mfns, ctx->p2m_batch[0]);
>      
> -        if(xc_domain_populate_physmap_exact(xch, dom, nr_mfns, 0,
> -                                            0, ctx->p2m_batch) != 0) 
> -        { 
> +        if (!ctx->hvm && ctx->superpages)
> +            rc = alloc_superpage_mfns(xch, dom, ctx, nr_mfns);
> +        else
> +            rc = xc_domain_populate_physmap_exact(xch, dom, nr_mfns, 0, 0,
> +                                                  ctx->p2m_batch);
> +    
> +        if (rc)
> +        {
>              ERROR("Failed to allocate memory for batch.!\n"); 
>              errno = ENOMEM;
>              return -1;
> @@ -1175,7 +1242,7 @@ static int apply_batch(xc_interface *xch
>               || pagetype == XEN_DOMCTL_PFINFO_XALLOC )
>              region_mfn[i] = ~0UL; /* map will fail but we don't care */
>          else
> -            region_mfn[i] = hvm ? pfn : ctx->p2m[pfn]; 
> +            region_mfn[i] = ctx->hvm ? pfn : ctx->p2m[pfn]; 
>      }
>  
>      /* Map relevant mfns */
> @@ -1298,7 +1365,7 @@ static int apply_batch(xc_interface *xch
>              }
>          }
>  
> -        if ( !hvm &&
> +        if ( !ctx->hvm &&
>               xc_add_mmu_update(xch, mmu,
>                                 (((unsigned long long)mfn) << PAGE_SHIFT)
>                                 | MMU_MACHPHYS_UPDATE, pfn) )
> @@ -1389,6 +1456,9 @@ int xc_domain_restore(xc_interface *xch,
>  
>      memset(ctx, 0, sizeof(*ctx));
>  
> +    ctx->superpages = superpages;
> +    ctx->hvm = hvm;
> +
>      ctxt = xc_hypercall_buffer_alloc(xch, ctxt, sizeof(*ctxt));
>  
>      if ( ctxt == NULL )
> @@ -1452,6 +1522,9 @@ int xc_domain_restore(xc_interface *xch,
>  
>      region_mfn = malloc(ROUNDUP(MAX_BATCH_SIZE * sizeof(xen_pfn_t), PAGE_SHIFT));
>      ctx->p2m_batch = malloc(ROUNDUP(MAX_BATCH_SIZE * sizeof(xen_pfn_t), PAGE_SHIFT));
> +    if (!ctx->hvm && ctx->superpages)
> +        ctx->p2m_saved_batch =
> +            malloc(ROUNDUP(MAX_BATCH_SIZE * sizeof(xen_pfn_t), PAGE_SHIFT));
>  
>      if ( (ctx->p2m == NULL) || (pfn_type == NULL) ||
>           (region_mfn == NULL) || (ctx->p2m_batch == NULL) )
> @@ -1575,8 +1648,7 @@ int xc_domain_restore(xc_interface *xch,
>              int brc;
>  
>              brc = apply_batch(xch, dom, ctx, region_mfn, pfn_type,
> -                              pae_extended_cr3, hvm, mmu, &pagebuf, curbatch,
> -                              superpages);
> +                              pae_extended_cr3, mmu, &pagebuf, curbatch);
>              if ( brc < 0 )
>                  goto out;
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 10:10:35 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 10:10:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOn3W-0001ib-44; Thu, 18 Oct 2012 10:10:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOn3V-0001iV-8c
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 10:10:21 +0000
Received: from [193.109.254.147:26261] by server-3.bemta-14.messagelabs.com id
	3B/02-04808-C85DF705; Thu, 18 Oct 2012 10:10:20 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1350554806!11802831!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzczMjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5979 invoked from network); 18 Oct 2012 10:06:47 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 10:06:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="41651427"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 10:06:46 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 06:06:46 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TOn01-00015J-NH;
	Thu, 18 Oct 2012 11:06:45 +0100
Message-ID: <507FD38C.8080201@eu.citrix.com>
Date: Thu, 18 Oct 2012 11:01:48 +0100
From: George Dunlap 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: Ian Campbell 
References: <20121012173222.31965.33368.sendpatchset@magnum.int.mccr.org>
	<1350554743.2460.103.camel@zakaz.uk.xensource.com>
In-Reply-To: <1350554743.2460.103.camel@zakaz.uk.xensource.com>
Cc: Dave McCracken , "Keir \(Xen.org\)" ,
	Xen Developers List 
Subject: Re: [Xen-devel] [PATCH] Make restore work properly with PV
 superpage flag
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 18/10/12 11:05, Ian Campbell wrote:
> George, Keir, and thoughts or opinions on this patch?

It's on my to-review short-list.  I should be able to get to it by the 
end of the week.

  -George

>
> On Fri, 2012-10-12 at 18:32 +0100, Dave McCracken wrote:
>> For PV guests, the superpage flag means to unconditionally allocate all
>> pages as superpages, which is required for Linux hugepages to work.  Support
>> for this on restore was not supported.  This patch adds proper support for
>> the superpage flag on restore.
>>
>> For HVM guests, the superpage flag has been used to mean attempt to allocate
>> superpages if possible on restore.  This functionality has been preserved.
>>
>> Signed-off-by: Dave McCracken 
>>
>> --------
>>
>>   xc_domain_restore.c |  130 ++++++++++++++++++++++++++++++++++++++++------------
>>   1 file changed, 101 insertions(+), 29 deletions(-)
>>
>>
>> --- xen-unstable/tools/libxc/xc_domain_restore.c	2012-08-18 10:04:53.000000000 -0500
>> +++ xen-unstable-restore//tools/libxc/xc_domain_restore.c	2012-08-20 07:24:22.000000000 -0500
>> @@ -23,6 +23,19 @@
>>    *
>>    */
>>   
>> +/*
>> + * The superpages flag in restore has two different meanings depending on
>> + * the type of domain.
>> + *
>> + * For an HVM domain, the flag means to look for properly aligned contiguous
>> + * pages and try to allocate a superpage to satisfy it.  If that fails,
>> + * fall back to small pages.
>> + *
>> + * For a PV domain, the flag means allocate all memory as superpages.  If that
>> + * fails, the restore fails.  This behavior is required for PV guests who
>> + * want to use superpages.
>> + */
>> +
>>   #include 
>>   #include 
>>   
>> @@ -41,6 +54,9 @@ struct restore_ctx {
>>       xen_pfn_t *live_p2m; /* Live mapping of the table mapping each PFN to its current MFN. */
>>       xen_pfn_t *p2m; /* A table mapping each PFN to its new MFN. */
>>       xen_pfn_t *p2m_batch; /* A table of P2M mappings in the current region.  */
>> +    xen_pfn_t *p2m_saved_batch; /* Copy of p2m_batch array for pv superpage alloc */
>> +    int superpages; /* Superpage allocation has been requested */
>> +    int hvm;    /* This is an hvm domain */
>>       int completed; /* Set when a consistent image is available */
>>       int last_checkpoint; /* Set when we should commit to the current checkpoint when it completes. */
>>       int compressing; /* Set when sender signals that pages would be sent compressed (for Remus) */
>> @@ -49,11 +65,6 @@ struct restore_ctx {
>>   
>>   #define HEARTBEAT_MS 1000
>>   
>> -#define SUPERPAGE_PFN_SHIFT  9
>> -#define SUPERPAGE_NR_PFNS    (1UL << SUPERPAGE_PFN_SHIFT)
>> -
>> -#define SUPER_PAGE_START(pfn)    (((pfn) & (SUPERPAGE_NR_PFNS-1)) == 0 )
>> -
>>   #ifndef __MINIOS__
>>   static ssize_t rdexact(xc_interface *xch, struct restore_ctx *ctx,
>>                          int fd, void* buf, size_t size)
>> @@ -103,6 +114,49 @@ static ssize_t rdexact(xc_interface *xch
>>   #else
>>   #define RDEXACT read_exact
>>   #endif
>> +
>> +#define SUPERPAGE_PFN_SHIFT  9
>> +#define SUPERPAGE_NR_PFNS    (1UL << SUPERPAGE_PFN_SHIFT)
>> +#define SUPERPAGE(_pfn) ((_pfn) & (~(SUPERPAGE_NR_PFNS-1)))
>> +#define SUPER_PAGE_START(pfn)    (((pfn) & (SUPERPAGE_NR_PFNS-1)) == 0 )
> Why this code motion?
>
>> +
>> +/*
>> +** When we're restoring into a pv superpage-allocated guest, we take
>> +** a copy of the p2m_batch array to preserve the pfn, then allocate the
>> +** corresponding superpages.  We then fill in the p2m array using the saved
>> +** pfns.
> So the pfns are not contiguous, but we back them with a super page? IOW
> they are super pages in machine address space but not physical address
> space?
>
> If they are contig in p-space you just need to save the first one?
>
>> +*/
>> +static int alloc_superpage_mfns(
>> +    xc_interface *xch, uint32_t dom, struct restore_ctx *ctx, int nr_mfns)
>> +{
>> +    int i, j, max = 0;
>> +    unsigned long pfn, base_pfn, mfn;
>> +
>> +    for (i = 0; i < nr_mfns; i++)
>> +    {
>> +        pfn = ctx->p2m_batch[i];
>> +        base_pfn = SUPERPAGE(pfn);
>> +        if (ctx->p2m[base_pfn] != (INVALID_P2M_ENTRY-2))
>> +        {
>> +            ctx->p2m_saved_batch[max] = base_pfn;
> Is p2m_saved_batch used anywhere other than in this function? Could it
> be a local variable?
>
>> +            ctx->p2m_batch[max] = base_pfn;
>> +            max++;
>> +            ctx->p2m[base_pfn] = INVALID_P2M_ENTRY-2;
> What is this magic -2? Can we get a symbolic constant (probably for the
> whole expression)?
>
>> +        }
>> +    }
>> +    if (xc_domain_populate_physmap_exact(xch, dom, max, SUPERPAGE_PFN_SHIFT,
>> +                                         0, ctx->p2m_batch) != 0)
>> +        return 1;
>> +
>> +    for (i = 0; i < max; i++)
>> +    {
>> +        mfn = ctx->p2m_batch[i];
>> +        pfn = ctx->p2m_saved_batch[i];
> If the orriginal was != (INVALID_P2M_ENTRY-2) then you didn't initialise
> p2m_saved_batch for this index?
>
>> +        for (j = 0; j < SUPERPAGE_NR_PFNS; j++)
>> +            ctx->p2m[pfn++] = mfn++;
>> +    }
>> +    return 0;
>> +}
>>   /*
>>   ** In the state file (or during transfer), all page-table pages are
>>   ** converted into a 'canonical' form where references to actual mfns
>> @@ -113,7 +167,7 @@ static ssize_t rdexact(xc_interface *xch
>>   static int uncanonicalize_pagetable(
>>       xc_interface *xch, uint32_t dom, struct restore_ctx *ctx, void *page)
>>   {
>> -    int i, pte_last, nr_mfns = 0;
>> +    int i, rc, pte_last, nr_mfns = 0;
>>       unsigned long pfn;
>>       uint64_t pte;
>>       struct domain_info_context *dinfo = &ctx->dinfo;
>> @@ -152,13 +206,20 @@ static int uncanonicalize_pagetable(
>>       }
>>   
>>       /* Allocate the requisite number of mfns. */
>> -    if ( nr_mfns &&
>> -         (xc_domain_populate_physmap_exact(xch, dom, nr_mfns, 0, 0,
>> -                                            ctx->p2m_batch) != 0) )
>> -    {
>> -        ERROR("Failed to allocate memory for batch.!\n");
>> -        errno = ENOMEM;
>> -        return 0;
>> +    if (nr_mfns)
>> +    {
>> +        if (!ctx->hvm && ctx->superpages)
>> +            rc = alloc_superpage_mfns(xch, dom, ctx, nr_mfns);
>> +        else
>> +            rc = xc_domain_populate_physmap_exact(xch, dom, nr_mfns, 0, 0,
>> +                                                  ctx->p2m_batch);
> Would it be clearer to rename alloc_superpage_mfns to (e.g.)
> alloc_guest_mfns and have it start:
> 	if ( ctx->hvm || !ctx->superpages )
> 		return xc_domain...
>
> Keeps the allocation logic in one place, since it is repeated again
> below.
>
>> +
>> +        if (rc)
>> +        {
>> +            ERROR("Failed to allocate memory for batch.!\n");
>> +            errno = ENOMEM;
>> +            return 0;
>> +        }
>>       }
>>       
>>       /* Second pass: uncanonicalize each present PTE */
>> @@ -1018,8 +1079,8 @@ static int pagebuf_get(xc_interface *xch
>>   
>>   static int apply_batch(xc_interface *xch, uint32_t dom, struct restore_ctx *ctx,
>>                          xen_pfn_t* region_mfn, unsigned long* pfn_type, int pae_extended_cr3,
>> -                       unsigned int hvm, struct xc_mmu* mmu,
>> -                       pagebuf_t* pagebuf, int curbatch, int superpages)
>> +                       struct xc_mmu* mmu,
>> +                       pagebuf_t* pagebuf, int curbatch)
>>   {
>>       int i, j, curpage, nr_mfns;
>>       int k, scount;
>> @@ -1061,7 +1122,7 @@ static int apply_batch(xc_interface *xch
>>                   /* Is this the next expected continuation? */
>>                   if ( pfn == superpage_start + scount )
>>                   {
>> -                    if ( !superpages )
>> +                    if ( !ctx->superpages )
>>                       {
>>                           ERROR("Unexpexted codepath with no superpages");
>>                           return -1;
>> @@ -1114,16 +1175,17 @@ static int apply_batch(xc_interface *xch
>>               }
>>   
>>               /* Are we ready to start a new superpage candidate? */
>> -            if ( superpages && SUPER_PAGE_START(pfn) )
>> +            if ( ctx->hvm && ctx->superpages && SUPER_PAGE_START(pfn) )
> Can we push the movement of these things into the ctx struct into a
> separate preparatory patch so it's easier to see the actual code
> changes.
>
>>               {
>>                   superpage_start=pfn;
>>                   scount++;
>> -                continue;
>>               }
>> -
>> -            /* Add the current pfn to pfn_batch */
>> -            ctx->p2m_batch[nr_mfns++] = pfn;
>> -            ctx->p2m[pfn]--;
>> +            else
>> +            {
>> +                /* Add the current pfn to pfn_batch */
>> +                ctx->p2m_batch[nr_mfns++] = pfn;
>> +                ctx->p2m[pfn]--;
>> +            }
>>           }
>>       }
>>   
>> @@ -1144,9 +1206,14 @@ static int apply_batch(xc_interface *xch
>>       {
>>           DPRINTF("Mapping order 0,  %d; first pfn %lx\n", nr_mfns, ctx->p2m_batch[0]);
>>       
>> -        if(xc_domain_populate_physmap_exact(xch, dom, nr_mfns, 0,
>> -                                            0, ctx->p2m_batch) != 0)
>> -        {
>> +        if (!ctx->hvm && ctx->superpages)
>> +            rc = alloc_superpage_mfns(xch, dom, ctx, nr_mfns);
>> +        else
>> +            rc = xc_domain_populate_physmap_exact(xch, dom, nr_mfns, 0, 0,
>> +                                                  ctx->p2m_batch);
>> +
>> +        if (rc)
>> +        {
>>               ERROR("Failed to allocate memory for batch.!\n");
>>               errno = ENOMEM;
>>               return -1;
>> @@ -1175,7 +1242,7 @@ static int apply_batch(xc_interface *xch
>>                || pagetype == XEN_DOMCTL_PFINFO_XALLOC )
>>               region_mfn[i] = ~0UL; /* map will fail but we don't care */
>>           else
>> -            region_mfn[i] = hvm ? pfn : ctx->p2m[pfn];
>> +            region_mfn[i] = ctx->hvm ? pfn : ctx->p2m[pfn];
>>       }
>>   
>>       /* Map relevant mfns */
>> @@ -1298,7 +1365,7 @@ static int apply_batch(xc_interface *xch
>>               }
>>           }
>>   
>> -        if ( !hvm &&
>> +        if ( !ctx->hvm &&
>>                xc_add_mmu_update(xch, mmu,
>>                                  (((unsigned long long)mfn) << PAGE_SHIFT)
>>                                  | MMU_MACHPHYS_UPDATE, pfn) )
>> @@ -1389,6 +1456,9 @@ int xc_domain_restore(xc_interface *xch,
>>   
>>       memset(ctx, 0, sizeof(*ctx));
>>   
>> +    ctx->superpages = superpages;
>> +    ctx->hvm = hvm;
>> +
>>       ctxt = xc_hypercall_buffer_alloc(xch, ctxt, sizeof(*ctxt));
>>   
>>       if ( ctxt == NULL )
>> @@ -1452,6 +1522,9 @@ int xc_domain_restore(xc_interface *xch,
>>   
>>       region_mfn = malloc(ROUNDUP(MAX_BATCH_SIZE * sizeof(xen_pfn_t), PAGE_SHIFT));
>>       ctx->p2m_batch = malloc(ROUNDUP(MAX_BATCH_SIZE * sizeof(xen_pfn_t), PAGE_SHIFT));
>> +    if (!ctx->hvm && ctx->superpages)
>> +        ctx->p2m_saved_batch =
>> +            malloc(ROUNDUP(MAX_BATCH_SIZE * sizeof(xen_pfn_t), PAGE_SHIFT));
>>   
>>       if ( (ctx->p2m == NULL) || (pfn_type == NULL) ||
>>            (region_mfn == NULL) || (ctx->p2m_batch == NULL) )
>> @@ -1575,8 +1648,7 @@ int xc_domain_restore(xc_interface *xch,
>>               int brc;
>>   
>>               brc = apply_batch(xch, dom, ctx, region_mfn, pfn_type,
>> -                              pae_extended_cr3, hvm, mmu, &pagebuf, curbatch,
>> -                              superpages);
>> +                              pae_extended_cr3, mmu, &pagebuf, curbatch);
>>               if ( brc < 0 )
>>                   goto out;
>>   
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 10:10:35 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 10:10:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOn3W-0001ib-44; Thu, 18 Oct 2012 10:10:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOn3V-0001iV-8c
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 10:10:21 +0000
Received: from [193.109.254.147:26261] by server-3.bemta-14.messagelabs.com id
	3B/02-04808-C85DF705; Thu, 18 Oct 2012 10:10:20 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1350554806!11802831!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzczMjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5979 invoked from network); 18 Oct 2012 10:06:47 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 10:06:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="41651427"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 10:06:46 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 06:06:46 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TOn01-00015J-NH;
	Thu, 18 Oct 2012 11:06:45 +0100
Message-ID: <507FD38C.8080201@eu.citrix.com>
Date: Thu, 18 Oct 2012 11:01:48 +0100
From: George Dunlap 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: Ian Campbell 
References: <20121012173222.31965.33368.sendpatchset@magnum.int.mccr.org>
	<1350554743.2460.103.camel@zakaz.uk.xensource.com>
In-Reply-To: <1350554743.2460.103.camel@zakaz.uk.xensource.com>
Cc: Dave McCracken , "Keir \(Xen.org\)" ,
	Xen Developers List 
Subject: Re: [Xen-devel] [PATCH] Make restore work properly with PV
 superpage flag
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 18/10/12 11:05, Ian Campbell wrote:
> George, Keir, and thoughts or opinions on this patch?

It's on my to-review short-list.  I should be able to get to it by the 
end of the week.

  -George

>
> On Fri, 2012-10-12 at 18:32 +0100, Dave McCracken wrote:
>> For PV guests, the superpage flag means to unconditionally allocate all
>> pages as superpages, which is required for Linux hugepages to work.  Support
>> for this on restore was not supported.  This patch adds proper support for
>> the superpage flag on restore.
>>
>> For HVM guests, the superpage flag has been used to mean attempt to allocate
>> superpages if possible on restore.  This functionality has been preserved.
>>
>> Signed-off-by: Dave McCracken 
>>
>> --------
>>
>>   xc_domain_restore.c |  130 ++++++++++++++++++++++++++++++++++++++++------------
>>   1 file changed, 101 insertions(+), 29 deletions(-)
>>
>>
>> --- xen-unstable/tools/libxc/xc_domain_restore.c	2012-08-18 10:04:53.000000000 -0500
>> +++ xen-unstable-restore//tools/libxc/xc_domain_restore.c	2012-08-20 07:24:22.000000000 -0500
>> @@ -23,6 +23,19 @@
>>    *
>>    */
>>   
>> +/*
>> + * The superpages flag in restore has two different meanings depending on
>> + * the type of domain.
>> + *
>> + * For an HVM domain, the flag means to look for properly aligned contiguous
>> + * pages and try to allocate a superpage to satisfy it.  If that fails,
>> + * fall back to small pages.
>> + *
>> + * For a PV domain, the flag means allocate all memory as superpages.  If that
>> + * fails, the restore fails.  This behavior is required for PV guests who
>> + * want to use superpages.
>> + */
>> +
>>   #include 
>>   #include 
>>   
>> @@ -41,6 +54,9 @@ struct restore_ctx {
>>       xen_pfn_t *live_p2m; /* Live mapping of the table mapping each PFN to its current MFN. */
>>       xen_pfn_t *p2m; /* A table mapping each PFN to its new MFN. */
>>       xen_pfn_t *p2m_batch; /* A table of P2M mappings in the current region.  */
>> +    xen_pfn_t *p2m_saved_batch; /* Copy of p2m_batch array for pv superpage alloc */
>> +    int superpages; /* Superpage allocation has been requested */
>> +    int hvm;    /* This is an hvm domain */
>>       int completed; /* Set when a consistent image is available */
>>       int last_checkpoint; /* Set when we should commit to the current checkpoint when it completes. */
>>       int compressing; /* Set when sender signals that pages would be sent compressed (for Remus) */
>> @@ -49,11 +65,6 @@ struct restore_ctx {
>>   
>>   #define HEARTBEAT_MS 1000
>>   
>> -#define SUPERPAGE_PFN_SHIFT  9
>> -#define SUPERPAGE_NR_PFNS    (1UL << SUPERPAGE_PFN_SHIFT)
>> -
>> -#define SUPER_PAGE_START(pfn)    (((pfn) & (SUPERPAGE_NR_PFNS-1)) == 0 )
>> -
>>   #ifndef __MINIOS__
>>   static ssize_t rdexact(xc_interface *xch, struct restore_ctx *ctx,
>>                          int fd, void* buf, size_t size)
>> @@ -103,6 +114,49 @@ static ssize_t rdexact(xc_interface *xch
>>   #else
>>   #define RDEXACT read_exact
>>   #endif
>> +
>> +#define SUPERPAGE_PFN_SHIFT  9
>> +#define SUPERPAGE_NR_PFNS    (1UL << SUPERPAGE_PFN_SHIFT)
>> +#define SUPERPAGE(_pfn) ((_pfn) & (~(SUPERPAGE_NR_PFNS-1)))
>> +#define SUPER_PAGE_START(pfn)    (((pfn) & (SUPERPAGE_NR_PFNS-1)) == 0 )
> Why this code motion?
>
>> +
>> +/*
>> +** When we're restoring into a pv superpage-allocated guest, we take
>> +** a copy of the p2m_batch array to preserve the pfn, then allocate the
>> +** corresponding superpages.  We then fill in the p2m array using the saved
>> +** pfns.
> So the pfns are not contiguous, but we back them with a super page? IOW
> they are super pages in machine address space but not physical address
> space?
>
> If they are contig in p-space you just need to save the first one?
>
>> +*/
>> +static int alloc_superpage_mfns(
>> +    xc_interface *xch, uint32_t dom, struct restore_ctx *ctx, int nr_mfns)
>> +{
>> +    int i, j, max = 0;
>> +    unsigned long pfn, base_pfn, mfn;
>> +
>> +    for (i = 0; i < nr_mfns; i++)
>> +    {
>> +        pfn = ctx->p2m_batch[i];
>> +        base_pfn = SUPERPAGE(pfn);
>> +        if (ctx->p2m[base_pfn] != (INVALID_P2M_ENTRY-2))
>> +        {
>> +            ctx->p2m_saved_batch[max] = base_pfn;
> Is p2m_saved_batch used anywhere other than in this function? Could it
> be a local variable?
>
>> +            ctx->p2m_batch[max] = base_pfn;
>> +            max++;
>> +            ctx->p2m[base_pfn] = INVALID_P2M_ENTRY-2;
> What is this magic -2? Can we get a symbolic constant (probably for the
> whole expression)?
>
>> +        }
>> +    }
>> +    if (xc_domain_populate_physmap_exact(xch, dom, max, SUPERPAGE_PFN_SHIFT,
>> +                                         0, ctx->p2m_batch) != 0)
>> +        return 1;
>> +
>> +    for (i = 0; i < max; i++)
>> +    {
>> +        mfn = ctx->p2m_batch[i];
>> +        pfn = ctx->p2m_saved_batch[i];
> If the orriginal was != (INVALID_P2M_ENTRY-2) then you didn't initialise
> p2m_saved_batch for this index?
>
>> +        for (j = 0; j < SUPERPAGE_NR_PFNS; j++)
>> +            ctx->p2m[pfn++] = mfn++;
>> +    }
>> +    return 0;
>> +}
>>   /*
>>   ** In the state file (or during transfer), all page-table pages are
>>   ** converted into a 'canonical' form where references to actual mfns
>> @@ -113,7 +167,7 @@ static ssize_t rdexact(xc_interface *xch
>>   static int uncanonicalize_pagetable(
>>       xc_interface *xch, uint32_t dom, struct restore_ctx *ctx, void *page)
>>   {
>> -    int i, pte_last, nr_mfns = 0;
>> +    int i, rc, pte_last, nr_mfns = 0;
>>       unsigned long pfn;
>>       uint64_t pte;
>>       struct domain_info_context *dinfo = &ctx->dinfo;
>> @@ -152,13 +206,20 @@ static int uncanonicalize_pagetable(
>>       }
>>   
>>       /* Allocate the requisite number of mfns. */
>> -    if ( nr_mfns &&
>> -         (xc_domain_populate_physmap_exact(xch, dom, nr_mfns, 0, 0,
>> -                                            ctx->p2m_batch) != 0) )
>> -    {
>> -        ERROR("Failed to allocate memory for batch.!\n");
>> -        errno = ENOMEM;
>> -        return 0;
>> +    if (nr_mfns)
>> +    {
>> +        if (!ctx->hvm && ctx->superpages)
>> +            rc = alloc_superpage_mfns(xch, dom, ctx, nr_mfns);
>> +        else
>> +            rc = xc_domain_populate_physmap_exact(xch, dom, nr_mfns, 0, 0,
>> +                                                  ctx->p2m_batch);
> Would it be clearer to rename alloc_superpage_mfns to (e.g.)
> alloc_guest_mfns and have it start:
> 	if ( ctx->hvm || !ctx->superpages )
> 		return xc_domain...
>
> Keeps the allocation logic in one place, since it is repeated again
> below.
>
>> +
>> +        if (rc)
>> +        {
>> +            ERROR("Failed to allocate memory for batch.!\n");
>> +            errno = ENOMEM;
>> +            return 0;
>> +        }
>>       }
>>       
>>       /* Second pass: uncanonicalize each present PTE */
>> @@ -1018,8 +1079,8 @@ static int pagebuf_get(xc_interface *xch
>>   
>>   static int apply_batch(xc_interface *xch, uint32_t dom, struct restore_ctx *ctx,
>>                          xen_pfn_t* region_mfn, unsigned long* pfn_type, int pae_extended_cr3,
>> -                       unsigned int hvm, struct xc_mmu* mmu,
>> -                       pagebuf_t* pagebuf, int curbatch, int superpages)
>> +                       struct xc_mmu* mmu,
>> +                       pagebuf_t* pagebuf, int curbatch)
>>   {
>>       int i, j, curpage, nr_mfns;
>>       int k, scount;
>> @@ -1061,7 +1122,7 @@ static int apply_batch(xc_interface *xch
>>                   /* Is this the next expected continuation? */
>>                   if ( pfn == superpage_start + scount )
>>                   {
>> -                    if ( !superpages )
>> +                    if ( !ctx->superpages )
>>                       {
>>                           ERROR("Unexpexted codepath with no superpages");
>>                           return -1;
>> @@ -1114,16 +1175,17 @@ static int apply_batch(xc_interface *xch
>>               }
>>   
>>               /* Are we ready to start a new superpage candidate? */
>> -            if ( superpages && SUPER_PAGE_START(pfn) )
>> +            if ( ctx->hvm && ctx->superpages && SUPER_PAGE_START(pfn) )
> Can we push the movement of these things into the ctx struct into a
> separate preparatory patch so it's easier to see the actual code
> changes.
>
>>               {
>>                   superpage_start=pfn;
>>                   scount++;
>> -                continue;
>>               }
>> -
>> -            /* Add the current pfn to pfn_batch */
>> -            ctx->p2m_batch[nr_mfns++] = pfn;
>> -            ctx->p2m[pfn]--;
>> +            else
>> +            {
>> +                /* Add the current pfn to pfn_batch */
>> +                ctx->p2m_batch[nr_mfns++] = pfn;
>> +                ctx->p2m[pfn]--;
>> +            }
>>           }
>>       }
>>   
>> @@ -1144,9 +1206,14 @@ static int apply_batch(xc_interface *xch
>>       {
>>           DPRINTF("Mapping order 0,  %d; first pfn %lx\n", nr_mfns, ctx->p2m_batch[0]);
>>       
>> -        if(xc_domain_populate_physmap_exact(xch, dom, nr_mfns, 0,
>> -                                            0, ctx->p2m_batch) != 0)
>> -        {
>> +        if (!ctx->hvm && ctx->superpages)
>> +            rc = alloc_superpage_mfns(xch, dom, ctx, nr_mfns);
>> +        else
>> +            rc = xc_domain_populate_physmap_exact(xch, dom, nr_mfns, 0, 0,
>> +                                                  ctx->p2m_batch);
>> +
>> +        if (rc)
>> +        {
>>               ERROR("Failed to allocate memory for batch.!\n");
>>               errno = ENOMEM;
>>               return -1;
>> @@ -1175,7 +1242,7 @@ static int apply_batch(xc_interface *xch
>>                || pagetype == XEN_DOMCTL_PFINFO_XALLOC )
>>               region_mfn[i] = ~0UL; /* map will fail but we don't care */
>>           else
>> -            region_mfn[i] = hvm ? pfn : ctx->p2m[pfn];
>> +            region_mfn[i] = ctx->hvm ? pfn : ctx->p2m[pfn];
>>       }
>>   
>>       /* Map relevant mfns */
>> @@ -1298,7 +1365,7 @@ static int apply_batch(xc_interface *xch
>>               }
>>           }
>>   
>> -        if ( !hvm &&
>> +        if ( !ctx->hvm &&
>>                xc_add_mmu_update(xch, mmu,
>>                                  (((unsigned long long)mfn) << PAGE_SHIFT)
>>                                  | MMU_MACHPHYS_UPDATE, pfn) )
>> @@ -1389,6 +1456,9 @@ int xc_domain_restore(xc_interface *xch,
>>   
>>       memset(ctx, 0, sizeof(*ctx));
>>   
>> +    ctx->superpages = superpages;
>> +    ctx->hvm = hvm;
>> +
>>       ctxt = xc_hypercall_buffer_alloc(xch, ctxt, sizeof(*ctxt));
>>   
>>       if ( ctxt == NULL )
>> @@ -1452,6 +1522,9 @@ int xc_domain_restore(xc_interface *xch,
>>   
>>       region_mfn = malloc(ROUNDUP(MAX_BATCH_SIZE * sizeof(xen_pfn_t), PAGE_SHIFT));
>>       ctx->p2m_batch = malloc(ROUNDUP(MAX_BATCH_SIZE * sizeof(xen_pfn_t), PAGE_SHIFT));
>> +    if (!ctx->hvm && ctx->superpages)
>> +        ctx->p2m_saved_batch =
>> +            malloc(ROUNDUP(MAX_BATCH_SIZE * sizeof(xen_pfn_t), PAGE_SHIFT));
>>   
>>       if ( (ctx->p2m == NULL) || (pfn_type == NULL) ||
>>            (region_mfn == NULL) || (ctx->p2m_batch == NULL) )
>> @@ -1575,8 +1648,7 @@ int xc_domain_restore(xc_interface *xch,
>>               int brc;
>>   
>>               brc = apply_batch(xch, dom, ctx, region_mfn, pfn_type,
>> -                              pae_extended_cr3, hvm, mmu, &pagebuf, curbatch,
>> -                              superpages);
>> +                              pae_extended_cr3, mmu, &pagebuf, curbatch);
>>               if ( brc < 0 )
>>                   goto out;
>>   
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 10:19:53 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 10:19:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOnCU-0001v5-6f; Thu, 18 Oct 2012 10:19:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOnCS-0001v0-V9
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 10:19:37 +0000
Received: from [85.158.139.211:8230] by server-2.bemta-5.messagelabs.com id
	5D/1C-10520-8B7DF705; Thu, 18 Oct 2012 10:19:36 +0000
X-Env-Sender: zpengxen@gmail.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1350555573!22784812!1
X-Originating-IP: [209.85.223.171]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17250 invoked from network); 18 Oct 2012 10:19:35 -0000
Received: from mail-ie0-f171.google.com (HELO mail-ie0-f171.google.com)
	(209.85.223.171)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 10:19:35 -0000
Received: by mail-ie0-f171.google.com with SMTP id s9so16309695iec.30
	for ;
	Thu, 18 Oct 2012 03:19:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=lbaSXXY/+ai+k5dODCON2u0B2/+lIdaqELA78r8iCAc=;
	b=qCnUX3JmNirGotvpkvIortSgZtXh2ErrfL+x46n7aLNTjvtUZfNVwMSCCdYlH0qPcd
	ueB8VwpyNPPK52NlzwpCTymfMIneut6Qaor7oqyt2bkSenoH1Rw/Jr7jR8E20UNqHlOI
	3aTFNu6ZsIrwWGbAVQO9yvrAOL1UKCSdCujsYWoOiwINW8/Sv++SIh1cHiMdZLSVPMJ+
	Hb4a84qDiHRIZauogXn0JI1Kp9vundIN7oDlRrnsgJE5QktVaGEp5p/hxVpWBq8s5/9h
	Mdw50q3kUh7O+iwgvsW1McaWulIIdWpeju2lrTt23WuSqggYJYnyqR3iKV5bpsvi2keX
	UgxQ==
MIME-Version: 1.0
Received: by 10.50.7.232 with SMTP id m8mr4219825iga.48.1350555573192; Thu, 18
	Oct 2012 03:19:33 -0700 (PDT)
Received: by 10.50.128.137 with HTTP; Thu, 18 Oct 2012 03:19:33 -0700 (PDT)
In-Reply-To: 
References: 
	<1338987918.32319.84.camel@zakaz.uk.xensource.com>
	
	<1339049291.6557.11.camel@dagon.hellion.org.uk>
	
	<1341325462.21547.20.camel@zakaz.uk.xensource.com>
	
	
Date: Thu, 18 Oct 2012 18:19:33 +0800
Message-ID: 
From: ZhouPeng 
To: Ian Campbell ,
	George Dunlap 
Content-Type: multipart/mixed; boundary=f46d04462dd23088ac04cc52b9d0
Cc: "Xen-Devel \(E-mail\)" ,
	Ian Jackson ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 2/3] tools:libxl: Add qxl vga interface
 support v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--f46d04462dd23088ac04cc52b9d0
Content-Type: text/plain; charset=ISO-8859-1

v4

test and fix conflict with the latest Xen
-----


tools:libxl: Add qxl vga interface support for upstream-qemu-xen.

Usage:
  qxl=1|0

Signed-off-by: Zhou Peng 

diff -r c1c549c4fe9e docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5	Mon Oct 15 16:51:44 2012 +0100
+++ b/docs/man/xl.cfg.pod.5	Thu Oct 18 17:53:25 2012 +0800
@@ -930,10 +930,13 @@ in the B for configurin

 Sets the amount of RAM which the emulated video card will contain,
 which in turn limits the resolutions and bit depths which will be
-available. This option is only available when using the B
-option (see below).
+available. This option is only available when using the B and
+B option (see below).
 The default amount of video ram for stdvga is 8MB which is sufficient
 for e.g. 1600x1200 at 32bpp.
+For B option, the default is 128MB. If B is set greater
+than 128MB, it will be trimmed to 128MB; if set less than 128MB, an
+error will be triggered.

 When using the emulated Cirrus graphics card (B)
 the amount of video ram is fixed at 4MB which is sufficient
@@ -951,6 +954,14 @@ a Cirrus Logic GD5446 VGA card. If your
 a Cirrus Logic GD5446 VGA card. If your guest supports VBE 2.0 or
 later (e.g. Windows XP onwards) then you should enable this.
 stdvga supports more video ram and bigger resolutions than Cirrus.
+
+=item B
+
+Select a QXL VGA card as the emulated graphics device.
+In general, QXL should work with the Spice remote display protocol
+for acceleration, and QXL driver is necessary in guest in this case.
+QXL can also work with the VNC protocol, but it will be like a standard
+VGA without acceleration.

 =item B

diff -r c1c549c4fe9e tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Oct 15 16:51:44 2012 +0100
+++ b/tools/libxl/libxl_create.c	Thu Oct 18 17:53:25 2012 +0800
@@ -232,8 +232,29 @@ int libxl__domain_build_info_setdefault(
     case LIBXL_DOMAIN_TYPE_HVM:
         if (b_info->shadow_memkb == LIBXL_MEMKB_DEFAULT)
             b_info->shadow_memkb = 0;
+
+        if (b_info->device_model_version == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN
+            && b_info->u.hvm.vga.kind == LIBXL_VGA_INTERFACE_TYPE_QXL) {
+            /*
+             * QXL needs 128 Mib video ram by default.
+             */
+            if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT) {
+                b_info->video_memkb = 128 * 1024;
+            }
+            if (b_info->video_memkb < 128 * 1024) {
+                LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
+                    "128 Mib videoram is necessary for qxl default");
+                return ERROR_INVAL;
+            }
+            if (b_info->video_memkb > 128 * 1024) {
+                b_info->video_memkb = 128 * 1024;
+                LIBXL__LOG(CTX, LIBXL__LOG_WARNING,
+                            "trim videoram to qxl default: 128 Mib");
+            }
+        }
         if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
             b_info->video_memkb = 8 * 1024;
+
         if (b_info->u.hvm.timer_mode == LIBXL_TIMER_MODE_DEFAULT)
             b_info->u.hvm.timer_mode =
                 LIBXL_TIMER_MODE_NO_DELAY_FOR_MISSED_TICKS;
diff -r c1c549c4fe9e tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Oct 15 16:51:44 2012 +0100
+++ b/tools/libxl/libxl_dm.c	Thu Oct 18 17:53:25 2012 +0800
@@ -181,6 +181,8 @@ static char ** libxl__build_device_model
             break;
         case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
             break;
+        case LIBXL_VGA_INTERFACE_TYPE_QXL:
+             break;
         }

         if (b_info->u.hvm.boot) {
@@ -430,6 +432,9 @@ static char ** libxl__build_device_model
             break;
         case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
             flexarray_vappend(dm_args, "-vga", "cirrus", NULL);
+            break;
+        case LIBXL_VGA_INTERFACE_TYPE_QXL:
+            flexarray_vappend(dm_args, "-vga", "qxl", NULL);
             break;
         }

diff -r c1c549c4fe9e tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Oct 15 16:51:44 2012 +0100
+++ b/tools/libxl/libxl_types.idl	Thu Oct 18 17:53:25 2012 +0800
@@ -130,6 +130,7 @@ libxl_vga_interface_type = Enumeration("
 libxl_vga_interface_type = Enumeration("vga_interface_type", [
     (1, "CIRRUS"),
     (2, "STD"),
+    (3, "QXL"),
     ], init_val = 0)

 #
diff -r c1c549c4fe9e tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Oct 15 16:51:44 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Thu Oct 18 17:53:25 2012 +0800
@@ -1402,6 +1402,14 @@ skip_vfb:
             b_info->u.hvm.vga.kind = l ? LIBXL_VGA_INTERFACE_TYPE_STD :
                                          LIBXL_VGA_INTERFACE_TYPE_CIRRUS;

+        if (!xlu_cfg_get_long(config, "qxl", &l, 0)) {
+            if (l) {
+                b_info->u.hvm.vga.kind = LIBXL_VGA_INTERFACE_TYPE_QXL;
+            } else if (!b_info->u.hvm.vga.kind) {
+                b_info->u.hvm.vga.kind = LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
+            }
+        }
+
         xlu_cfg_get_defbool(config, "vnc", &b_info->u.hvm.vnc.enable, 0);
         xlu_cfg_replace_string (config, "vnclisten",
                                 &b_info->u.hvm.vnc.listen, 0);

On Sun, Oct 14, 2012 at 1:16 PM, ZhouPeng  wrote:
> On Thu, Oct 11, 2012 at 12:50 AM, George Dunlap
>  wrote:
>> On Tue, Jul 3, 2012 at 3:24 PM, Ian Campbell  wrote:
>>> On Tue, 2012-07-03 at 12:30 +0100, ZhouPeng wrote:
>>>> qxl support and docs accordingly
>>>> v3
>>>> --
>>>>
>>>> tools:libxl: Add qxl vga interface support for upstream-qemu-xen.
>>>>
>>>> Usage:
>>>>   qxl=1|0
>>>>
>>>> Signed-off-by: Zhou Peng 
>>>
>>> Thanks. As previously mentioned we think this is 4.3 material. Please
>>> could you resubmit (or otherwise remind us) once the 4.3 development
>>> branch has opened.
>>
>> Now that 4.3 development has started, what's the status of this patch?
>>  Does it need a refresh?
>
> I will have a test with the latest Xen to response to you.
>> Zhou Peng, if you're planning to get this
>> working for 4.3, can I add this to my 4.3 feature tracking list?
>
> I think it's ok to add to 4.3 feature tracking list.
>
> Thanks,
> - Zhou Peng
>>
>> Thanks,
>>  -George



-- 
Zhou Peng

--f46d04462dd23088ac04cc52b9d0
Content-Type: application/octet-stream; 
	name="spice.tools.libxl.qxl.support+docs.v4.diff"
Content-Disposition: attachment; 
	filename="spice.tools.libxl.qxl.support+docs.v4.diff"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h8fpv8rr0

dG9vbHM6bGlieGw6IEFkZCBxeGwgdmdhIGludGVyZmFjZSBzdXBwb3J0IGZvciB1cHN0cmVhbS1x
ZW11LXhlbi4KClVzYWdlOgogIHF4bD0xfDAKClNpZ25lZC1vZmYtYnk6IFpob3UgUGVuZyA8YWls
dnBlbmcyNUBnbWFpbC5jb20+CgpkaWZmIC1yIGMxYzU0OWM0ZmU5ZSBkb2NzL21hbi94bC5jZmcu
cG9kLjUKLS0tIGEvZG9jcy9tYW4veGwuY2ZnLnBvZC41CU1vbiBPY3QgMTUgMTY6NTE6NDQgMjAx
MiArMDEwMAorKysgYi9kb2NzL21hbi94bC5jZmcucG9kLjUJVGh1IE9jdCAxOCAxNzo1MzoyNSAy
MDEyICswODAwCkBAIC05MzAsMTAgKzkzMCwxMyBAQCBpbiB0aGUgQjxWRkJfU1BFQ19TVFJJTkc+
IGZvciBjb25maWd1cmluCiAKIFNldHMgdGhlIGFtb3VudCBvZiBSQU0gd2hpY2ggdGhlIGVtdWxh
dGVkIHZpZGVvIGNhcmQgd2lsbCBjb250YWluLAogd2hpY2ggaW4gdHVybiBsaW1pdHMgdGhlIHJl
c29sdXRpb25zIGFuZCBiaXQgZGVwdGhzIHdoaWNoIHdpbGwgYmUKLWF2YWlsYWJsZS4gVGhpcyBv
cHRpb24gaXMgb25seSBhdmFpbGFibGUgd2hlbiB1c2luZyB0aGUgQjxzdGR2Z2E+Ci1vcHRpb24g
KHNlZSBiZWxvdykuCithdmFpbGFibGUuIFRoaXMgb3B0aW9uIGlzIG9ubHkgYXZhaWxhYmxlIHdo
ZW4gdXNpbmcgdGhlIEI8c3RkdmdhPiBhbmQKK0I8cXhsPiBvcHRpb24gKHNlZSBiZWxvdykuCiBU
aGUgZGVmYXVsdCBhbW91bnQgb2YgdmlkZW8gcmFtIGZvciBzdGR2Z2EgaXMgOE1CIHdoaWNoIGlz
IHN1ZmZpY2llbnQKIGZvciBlLmcuIDE2MDB4MTIwMCBhdCAzMmJwcC4KK0ZvciBCPHF4bD4gb3B0
aW9uLCB0aGUgZGVmYXVsdCBpcyAxMjhNQi4gSWYgQjx2aWRlb3JhbT4gaXMgc2V0IGdyZWF0ZXIK
K3RoYW4gMTI4TUIsIGl0IHdpbGwgYmUgdHJpbW1lZCB0byAxMjhNQjsgaWYgc2V0IGxlc3MgdGhh
biAxMjhNQiwgYW4KK2Vycm9yIHdpbGwgYmUgdHJpZ2dlcmVkLgogCiBXaGVuIHVzaW5nIHRoZSBl
bXVsYXRlZCBDaXJydXMgZ3JhcGhpY3MgY2FyZCAoQjxzdGR2Z2E9MD4pCiB0aGUgYW1vdW50IG9m
IHZpZGVvIHJhbSBpcyBmaXhlZCBhdCA0TUIgd2hpY2ggaXMgc3VmZmljaWVudApAQCAtOTUxLDYg
Kzk1NCwxNCBAQCBhIENpcnJ1cyBMb2dpYyBHRDU0NDYgVkdBIGNhcmQuIElmIHlvdXIgCiBhIENp
cnJ1cyBMb2dpYyBHRDU0NDYgVkdBIGNhcmQuIElmIHlvdXIgZ3Vlc3Qgc3VwcG9ydHMgVkJFIDIu
MCBvcgogbGF0ZXIgKGUuZy4gV2luZG93cyBYUCBvbndhcmRzKSB0aGVuIHlvdSBzaG91bGQgZW5h
YmxlIHRoaXMuCiBzdGR2Z2Egc3VwcG9ydHMgbW9yZSB2aWRlbyByYW0gYW5kIGJpZ2dlciByZXNv
bHV0aW9ucyB0aGFuIENpcnJ1cy4KKworPWl0ZW0gQjxxeGw9Qk9PTEVBTj4KKworU2VsZWN0IGEg
UVhMIFZHQSBjYXJkIGFzIHRoZSBlbXVsYXRlZCBncmFwaGljcyBkZXZpY2UuCitJbiBnZW5lcmFs
LCBRWEwgc2hvdWxkIHdvcmsgd2l0aCB0aGUgU3BpY2UgcmVtb3RlIGRpc3BsYXkgcHJvdG9jb2wK
K2ZvciBhY2NlbGVyYXRpb24sIGFuZCBRWEwgZHJpdmVyIGlzIG5lY2Vzc2FyeSBpbiBndWVzdCBp
biB0aGlzIGNhc2UuCitRWEwgY2FuIGFsc28gd29yayB3aXRoIHRoZSBWTkMgcHJvdG9jb2wsIGJ1
dCBpdCB3aWxsIGJlIGxpa2UgYSBzdGFuZGFyZAorVkdBIHdpdGhvdXQgYWNjZWxlcmF0aW9uLgog
CiA9aXRlbSBCPHZuYz1CT09MRUFOPgogCmRpZmYgLXIgYzFjNTQ5YzRmZTllIHRvb2xzL2xpYnhs
L2xpYnhsX2NyZWF0ZS5jCi0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsX2NyZWF0ZS5jCU1vbiBPY3Qg
MTUgMTY6NTE6NDQgMjAxMiArMDEwMAorKysgYi90b29scy9saWJ4bC9saWJ4bF9jcmVhdGUuYwlU
aHUgT2N0IDE4IDE3OjUzOjI1IDIwMTIgKzA4MDAKQEAgLTIzMiw4ICsyMzIsMjkgQEAgaW50IGxp
YnhsX19kb21haW5fYnVpbGRfaW5mb19zZXRkZWZhdWx0KAogICAgIGNhc2UgTElCWExfRE9NQUlO
X1RZUEVfSFZNOgogICAgICAgICBpZiAoYl9pbmZvLT5zaGFkb3dfbWVta2IgPT0gTElCWExfTUVN
S0JfREVGQVVMVCkKICAgICAgICAgICAgIGJfaW5mby0+c2hhZG93X21lbWtiID0gMDsKKworICAg
ICAgICBpZiAoYl9pbmZvLT5kZXZpY2VfbW9kZWxfdmVyc2lvbiA9PSBMSUJYTF9ERVZJQ0VfTU9E
RUxfVkVSU0lPTl9RRU1VX1hFTgorICAgICAgICAgICAgJiYgYl9pbmZvLT51Lmh2bS52Z2Eua2lu
ZCA9PSBMSUJYTF9WR0FfSU5URVJGQUNFX1RZUEVfUVhMKSB7CisgICAgICAgICAgICAvKgorICAg
ICAgICAgICAgICogUVhMIG5lZWRzIDEyOCBNaWIgdmlkZW8gcmFtIGJ5IGRlZmF1bHQuCisgICAg
ICAgICAgICAgKi8KKyAgICAgICAgICAgIGlmIChiX2luZm8tPnZpZGVvX21lbWtiID09IExJQlhM
X01FTUtCX0RFRkFVTFQpIHsKKyAgICAgICAgICAgICAgICBiX2luZm8tPnZpZGVvX21lbWtiID0g
MTI4ICogMTAyNDsKKyAgICAgICAgICAgIH0KKyAgICAgICAgICAgIGlmIChiX2luZm8tPnZpZGVv
X21lbWtiIDwgMTI4ICogMTAyNCkgeworICAgICAgICAgICAgICAgIExJQlhMX19MT0coQ1RYLCBM
SUJYTF9fTE9HX0VSUk9SLAorICAgICAgICAgICAgICAgICAgICAiMTI4IE1pYiB2aWRlb3JhbSBp
cyBuZWNlc3NhcnkgZm9yIHF4bCBkZWZhdWx0Iik7CisgICAgICAgICAgICAgICAgcmV0dXJuIEVS
Uk9SX0lOVkFMOworICAgICAgICAgICAgfQorICAgICAgICAgICAgaWYgKGJfaW5mby0+dmlkZW9f
bWVta2IgPiAxMjggKiAxMDI0KSB7CisgICAgICAgICAgICAgICAgYl9pbmZvLT52aWRlb19tZW1r
YiA9IDEyOCAqIDEwMjQ7CisgICAgICAgICAgICAgICAgTElCWExfX0xPRyhDVFgsIExJQlhMX19M
T0dfV0FSTklORywKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAidHJpbSB2aWRlb3JhbSB0
byBxeGwgZGVmYXVsdDogMTI4IE1pYiIpOworICAgICAgICAgICAgfQorICAgICAgICB9CiAgICAg
ICAgIGlmIChiX2luZm8tPnZpZGVvX21lbWtiID09IExJQlhMX01FTUtCX0RFRkFVTFQpCiAgICAg
ICAgICAgICBiX2luZm8tPnZpZGVvX21lbWtiID0gOCAqIDEwMjQ7CisKICAgICAgICAgaWYgKGJf
aW5mby0+dS5odm0udGltZXJfbW9kZSA9PSBMSUJYTF9USU1FUl9NT0RFX0RFRkFVTFQpCiAgICAg
ICAgICAgICBiX2luZm8tPnUuaHZtLnRpbWVyX21vZGUgPQogICAgICAgICAgICAgICAgIExJQlhM
X1RJTUVSX01PREVfTk9fREVMQVlfRk9SX01JU1NFRF9USUNLUzsKZGlmZiAtciBjMWM1NDljNGZl
OWUgdG9vbHMvbGlieGwvbGlieGxfZG0uYwotLS0gYS90b29scy9saWJ4bC9saWJ4bF9kbS5jCU1v
biBPY3QgMTUgMTY6NTE6NDQgMjAxMiArMDEwMAorKysgYi90b29scy9saWJ4bC9saWJ4bF9kbS5j
CVRodSBPY3QgMTggMTc6NTM6MjUgMjAxMiArMDgwMApAQCAtMTgxLDYgKzE4MSw4IEBAIHN0YXRp
YyBjaGFyICoqIGxpYnhsX19idWlsZF9kZXZpY2VfbW9kZWwKICAgICAgICAgICAgIGJyZWFrOwog
ICAgICAgICBjYXNlIExJQlhMX1ZHQV9JTlRFUkZBQ0VfVFlQRV9DSVJSVVM6CiAgICAgICAgICAg
ICBicmVhazsKKyAgICAgICAgY2FzZSBMSUJYTF9WR0FfSU5URVJGQUNFX1RZUEVfUVhMOgorICAg
ICAgICAgICAgIGJyZWFrOwogICAgICAgICB9CiAKICAgICAgICAgaWYgKGJfaW5mby0+dS5odm0u
Ym9vdCkgewpAQCAtNDMwLDYgKzQzMiw5IEBAIHN0YXRpYyBjaGFyICoqIGxpYnhsX19idWlsZF9k
ZXZpY2VfbW9kZWwKICAgICAgICAgICAgIGJyZWFrOwogICAgICAgICBjYXNlIExJQlhMX1ZHQV9J
TlRFUkZBQ0VfVFlQRV9DSVJSVVM6CiAgICAgICAgICAgICBmbGV4YXJyYXlfdmFwcGVuZChkbV9h
cmdzLCAiLXZnYSIsICJjaXJydXMiLCBOVUxMKTsKKyAgICAgICAgICAgIGJyZWFrOworICAgICAg
ICBjYXNlIExJQlhMX1ZHQV9JTlRFUkZBQ0VfVFlQRV9RWEw6CisgICAgICAgICAgICBmbGV4YXJy
YXlfdmFwcGVuZChkbV9hcmdzLCAiLXZnYSIsICJxeGwiLCBOVUxMKTsKICAgICAgICAgICAgIGJy
ZWFrOwogICAgICAgICB9CiAKZGlmZiAtciBjMWM1NDljNGZlOWUgdG9vbHMvbGlieGwvbGlieGxf
dHlwZXMuaWRsCi0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsX3R5cGVzLmlkbAlNb24gT2N0IDE1IDE2
OjUxOjQ0IDIwMTIgKzAxMDAKKysrIGIvdG9vbHMvbGlieGwvbGlieGxfdHlwZXMuaWRsCVRodSBP
Y3QgMTggMTc6NTM6MjUgMjAxMiArMDgwMApAQCAtMTMwLDYgKzEzMCw3IEBAIGxpYnhsX3ZnYV9p
bnRlcmZhY2VfdHlwZSA9IEVudW1lcmF0aW9uKCIKIGxpYnhsX3ZnYV9pbnRlcmZhY2VfdHlwZSA9
IEVudW1lcmF0aW9uKCJ2Z2FfaW50ZXJmYWNlX3R5cGUiLCBbCiAgICAgKDEsICJDSVJSVVMiKSwK
ICAgICAoMiwgIlNURCIpLAorICAgICgzLCAiUVhMIiksCiAgICAgXSwgaW5pdF92YWwgPSAwKQog
CiAjCmRpZmYgLXIgYzFjNTQ5YzRmZTllIHRvb2xzL2xpYnhsL3hsX2NtZGltcGwuYwotLS0gYS90
b29scy9saWJ4bC94bF9jbWRpbXBsLmMJTW9uIE9jdCAxNSAxNjo1MTo0NCAyMDEyICswMTAwCisr
KyBiL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYwlUaHUgT2N0IDE4IDE3OjUzOjI1IDIwMTIgKzA4
MDAKQEAgLTE0MDIsNiArMTQwMiwxNCBAQCBza2lwX3ZmYjoKICAgICAgICAgICAgIGJfaW5mby0+
dS5odm0udmdhLmtpbmQgPSBsID8gTElCWExfVkdBX0lOVEVSRkFDRV9UWVBFX1NURCA6CiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIExJQlhMX1ZHQV9JTlRFUkZBQ0Vf
VFlQRV9DSVJSVVM7CiAKKyAgICAgICAgaWYgKCF4bHVfY2ZnX2dldF9sb25nKGNvbmZpZywgInF4
bCIsICZsLCAwKSkgeworICAgICAgICAgICAgaWYgKGwpIHsKKyAgICAgICAgICAgICAgICBiX2lu
Zm8tPnUuaHZtLnZnYS5raW5kID0gTElCWExfVkdBX0lOVEVSRkFDRV9UWVBFX1FYTDsKKyAgICAg
ICAgICAgIH0gZWxzZSBpZiAoIWJfaW5mby0+dS5odm0udmdhLmtpbmQpIHsKKyAgICAgICAgICAg
ICAgICBiX2luZm8tPnUuaHZtLnZnYS5raW5kID0gTElCWExfVkdBX0lOVEVSRkFDRV9UWVBFX0NJ
UlJVUzsKKyAgICAgICAgICAgIH0KKyAgICAgICAgfQorCiAgICAgICAgIHhsdV9jZmdfZ2V0X2Rl
ZmJvb2woY29uZmlnLCAidm5jIiwgJmJfaW5mby0+dS5odm0udm5jLmVuYWJsZSwgMCk7CiAgICAg
ICAgIHhsdV9jZmdfcmVwbGFjZV9zdHJpbmcgKGNvbmZpZywgInZuY2xpc3RlbiIsCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICZiX2luZm8tPnUuaHZtLnZuYy5saXN0ZW4sIDApOwo=
--f46d04462dd23088ac04cc52b9d0
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--f46d04462dd23088ac04cc52b9d0--


From xen-devel-bounces@lists.xen.org Thu Oct 18 10:19:53 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 10:19:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOnCU-0001v5-6f; Thu, 18 Oct 2012 10:19:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOnCS-0001v0-V9
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 10:19:37 +0000
Received: from [85.158.139.211:8230] by server-2.bemta-5.messagelabs.com id
	5D/1C-10520-8B7DF705; Thu, 18 Oct 2012 10:19:36 +0000
X-Env-Sender: zpengxen@gmail.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1350555573!22784812!1
X-Originating-IP: [209.85.223.171]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17250 invoked from network); 18 Oct 2012 10:19:35 -0000
Received: from mail-ie0-f171.google.com (HELO mail-ie0-f171.google.com)
	(209.85.223.171)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 10:19:35 -0000
Received: by mail-ie0-f171.google.com with SMTP id s9so16309695iec.30
	for ;
	Thu, 18 Oct 2012 03:19:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=lbaSXXY/+ai+k5dODCON2u0B2/+lIdaqELA78r8iCAc=;
	b=qCnUX3JmNirGotvpkvIortSgZtXh2ErrfL+x46n7aLNTjvtUZfNVwMSCCdYlH0qPcd
	ueB8VwpyNPPK52NlzwpCTymfMIneut6Qaor7oqyt2bkSenoH1Rw/Jr7jR8E20UNqHlOI
	3aTFNu6ZsIrwWGbAVQO9yvrAOL1UKCSdCujsYWoOiwINW8/Sv++SIh1cHiMdZLSVPMJ+
	Hb4a84qDiHRIZauogXn0JI1Kp9vundIN7oDlRrnsgJE5QktVaGEp5p/hxVpWBq8s5/9h
	Mdw50q3kUh7O+iwgvsW1McaWulIIdWpeju2lrTt23WuSqggYJYnyqR3iKV5bpsvi2keX
	UgxQ==
MIME-Version: 1.0
Received: by 10.50.7.232 with SMTP id m8mr4219825iga.48.1350555573192; Thu, 18
	Oct 2012 03:19:33 -0700 (PDT)
Received: by 10.50.128.137 with HTTP; Thu, 18 Oct 2012 03:19:33 -0700 (PDT)
In-Reply-To: 
References: 
	<1338987918.32319.84.camel@zakaz.uk.xensource.com>
	
	<1339049291.6557.11.camel@dagon.hellion.org.uk>
	
	<1341325462.21547.20.camel@zakaz.uk.xensource.com>
	
	
Date: Thu, 18 Oct 2012 18:19:33 +0800
Message-ID: 
From: ZhouPeng 
To: Ian Campbell ,
	George Dunlap 
Content-Type: multipart/mixed; boundary=f46d04462dd23088ac04cc52b9d0
Cc: "Xen-Devel \(E-mail\)" ,
	Ian Jackson ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 2/3] tools:libxl: Add qxl vga interface
 support v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--f46d04462dd23088ac04cc52b9d0
Content-Type: text/plain; charset=ISO-8859-1

v4

test and fix conflict with the latest Xen
-----


tools:libxl: Add qxl vga interface support for upstream-qemu-xen.

Usage:
  qxl=1|0

Signed-off-by: Zhou Peng 

diff -r c1c549c4fe9e docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5	Mon Oct 15 16:51:44 2012 +0100
+++ b/docs/man/xl.cfg.pod.5	Thu Oct 18 17:53:25 2012 +0800
@@ -930,10 +930,13 @@ in the B for configurin

 Sets the amount of RAM which the emulated video card will contain,
 which in turn limits the resolutions and bit depths which will be
-available. This option is only available when using the B
-option (see below).
+available. This option is only available when using the B and
+B option (see below).
 The default amount of video ram for stdvga is 8MB which is sufficient
 for e.g. 1600x1200 at 32bpp.
+For B option, the default is 128MB. If B is set greater
+than 128MB, it will be trimmed to 128MB; if set less than 128MB, an
+error will be triggered.

 When using the emulated Cirrus graphics card (B)
 the amount of video ram is fixed at 4MB which is sufficient
@@ -951,6 +954,14 @@ a Cirrus Logic GD5446 VGA card. If your
 a Cirrus Logic GD5446 VGA card. If your guest supports VBE 2.0 or
 later (e.g. Windows XP onwards) then you should enable this.
 stdvga supports more video ram and bigger resolutions than Cirrus.
+
+=item B
+
+Select a QXL VGA card as the emulated graphics device.
+In general, QXL should work with the Spice remote display protocol
+for acceleration, and QXL driver is necessary in guest in this case.
+QXL can also work with the VNC protocol, but it will be like a standard
+VGA without acceleration.

 =item B

diff -r c1c549c4fe9e tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Oct 15 16:51:44 2012 +0100
+++ b/tools/libxl/libxl_create.c	Thu Oct 18 17:53:25 2012 +0800
@@ -232,8 +232,29 @@ int libxl__domain_build_info_setdefault(
     case LIBXL_DOMAIN_TYPE_HVM:
         if (b_info->shadow_memkb == LIBXL_MEMKB_DEFAULT)
             b_info->shadow_memkb = 0;
+
+        if (b_info->device_model_version == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN
+            && b_info->u.hvm.vga.kind == LIBXL_VGA_INTERFACE_TYPE_QXL) {
+            /*
+             * QXL needs 128 Mib video ram by default.
+             */
+            if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT) {
+                b_info->video_memkb = 128 * 1024;
+            }
+            if (b_info->video_memkb < 128 * 1024) {
+                LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
+                    "128 Mib videoram is necessary for qxl default");
+                return ERROR_INVAL;
+            }
+            if (b_info->video_memkb > 128 * 1024) {
+                b_info->video_memkb = 128 * 1024;
+                LIBXL__LOG(CTX, LIBXL__LOG_WARNING,
+                            "trim videoram to qxl default: 128 Mib");
+            }
+        }
         if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
             b_info->video_memkb = 8 * 1024;
+
         if (b_info->u.hvm.timer_mode == LIBXL_TIMER_MODE_DEFAULT)
             b_info->u.hvm.timer_mode =
                 LIBXL_TIMER_MODE_NO_DELAY_FOR_MISSED_TICKS;
diff -r c1c549c4fe9e tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Oct 15 16:51:44 2012 +0100
+++ b/tools/libxl/libxl_dm.c	Thu Oct 18 17:53:25 2012 +0800
@@ -181,6 +181,8 @@ static char ** libxl__build_device_model
             break;
         case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
             break;
+        case LIBXL_VGA_INTERFACE_TYPE_QXL:
+             break;
         }

         if (b_info->u.hvm.boot) {
@@ -430,6 +432,9 @@ static char ** libxl__build_device_model
             break;
         case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
             flexarray_vappend(dm_args, "-vga", "cirrus", NULL);
+            break;
+        case LIBXL_VGA_INTERFACE_TYPE_QXL:
+            flexarray_vappend(dm_args, "-vga", "qxl", NULL);
             break;
         }

diff -r c1c549c4fe9e tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Oct 15 16:51:44 2012 +0100
+++ b/tools/libxl/libxl_types.idl	Thu Oct 18 17:53:25 2012 +0800
@@ -130,6 +130,7 @@ libxl_vga_interface_type = Enumeration("
 libxl_vga_interface_type = Enumeration("vga_interface_type", [
     (1, "CIRRUS"),
     (2, "STD"),
+    (3, "QXL"),
     ], init_val = 0)

 #
diff -r c1c549c4fe9e tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Oct 15 16:51:44 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Thu Oct 18 17:53:25 2012 +0800
@@ -1402,6 +1402,14 @@ skip_vfb:
             b_info->u.hvm.vga.kind = l ? LIBXL_VGA_INTERFACE_TYPE_STD :
                                          LIBXL_VGA_INTERFACE_TYPE_CIRRUS;

+        if (!xlu_cfg_get_long(config, "qxl", &l, 0)) {
+            if (l) {
+                b_info->u.hvm.vga.kind = LIBXL_VGA_INTERFACE_TYPE_QXL;
+            } else if (!b_info->u.hvm.vga.kind) {
+                b_info->u.hvm.vga.kind = LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
+            }
+        }
+
         xlu_cfg_get_defbool(config, "vnc", &b_info->u.hvm.vnc.enable, 0);
         xlu_cfg_replace_string (config, "vnclisten",
                                 &b_info->u.hvm.vnc.listen, 0);

On Sun, Oct 14, 2012 at 1:16 PM, ZhouPeng  wrote:
> On Thu, Oct 11, 2012 at 12:50 AM, George Dunlap
>  wrote:
>> On Tue, Jul 3, 2012 at 3:24 PM, Ian Campbell  wrote:
>>> On Tue, 2012-07-03 at 12:30 +0100, ZhouPeng wrote:
>>>> qxl support and docs accordingly
>>>> v3
>>>> --
>>>>
>>>> tools:libxl: Add qxl vga interface support for upstream-qemu-xen.
>>>>
>>>> Usage:
>>>>   qxl=1|0
>>>>
>>>> Signed-off-by: Zhou Peng 
>>>
>>> Thanks. As previously mentioned we think this is 4.3 material. Please
>>> could you resubmit (or otherwise remind us) once the 4.3 development
>>> branch has opened.
>>
>> Now that 4.3 development has started, what's the status of this patch?
>>  Does it need a refresh?
>
> I will have a test with the latest Xen to response to you.
>> Zhou Peng, if you're planning to get this
>> working for 4.3, can I add this to my 4.3 feature tracking list?
>
> I think it's ok to add to 4.3 feature tracking list.
>
> Thanks,
> - Zhou Peng
>>
>> Thanks,
>>  -George



-- 
Zhou Peng

--f46d04462dd23088ac04cc52b9d0
Content-Type: application/octet-stream; 
	name="spice.tools.libxl.qxl.support+docs.v4.diff"
Content-Disposition: attachment; 
	filename="spice.tools.libxl.qxl.support+docs.v4.diff"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h8fpv8rr0

dG9vbHM6bGlieGw6IEFkZCBxeGwgdmdhIGludGVyZmFjZSBzdXBwb3J0IGZvciB1cHN0cmVhbS1x
ZW11LXhlbi4KClVzYWdlOgogIHF4bD0xfDAKClNpZ25lZC1vZmYtYnk6IFpob3UgUGVuZyA8YWls
dnBlbmcyNUBnbWFpbC5jb20+CgpkaWZmIC1yIGMxYzU0OWM0ZmU5ZSBkb2NzL21hbi94bC5jZmcu
cG9kLjUKLS0tIGEvZG9jcy9tYW4veGwuY2ZnLnBvZC41CU1vbiBPY3QgMTUgMTY6NTE6NDQgMjAx
MiArMDEwMAorKysgYi9kb2NzL21hbi94bC5jZmcucG9kLjUJVGh1IE9jdCAxOCAxNzo1MzoyNSAy
MDEyICswODAwCkBAIC05MzAsMTAgKzkzMCwxMyBAQCBpbiB0aGUgQjxWRkJfU1BFQ19TVFJJTkc+
IGZvciBjb25maWd1cmluCiAKIFNldHMgdGhlIGFtb3VudCBvZiBSQU0gd2hpY2ggdGhlIGVtdWxh
dGVkIHZpZGVvIGNhcmQgd2lsbCBjb250YWluLAogd2hpY2ggaW4gdHVybiBsaW1pdHMgdGhlIHJl
c29sdXRpb25zIGFuZCBiaXQgZGVwdGhzIHdoaWNoIHdpbGwgYmUKLWF2YWlsYWJsZS4gVGhpcyBv
cHRpb24gaXMgb25seSBhdmFpbGFibGUgd2hlbiB1c2luZyB0aGUgQjxzdGR2Z2E+Ci1vcHRpb24g
KHNlZSBiZWxvdykuCithdmFpbGFibGUuIFRoaXMgb3B0aW9uIGlzIG9ubHkgYXZhaWxhYmxlIHdo
ZW4gdXNpbmcgdGhlIEI8c3RkdmdhPiBhbmQKK0I8cXhsPiBvcHRpb24gKHNlZSBiZWxvdykuCiBU
aGUgZGVmYXVsdCBhbW91bnQgb2YgdmlkZW8gcmFtIGZvciBzdGR2Z2EgaXMgOE1CIHdoaWNoIGlz
IHN1ZmZpY2llbnQKIGZvciBlLmcuIDE2MDB4MTIwMCBhdCAzMmJwcC4KK0ZvciBCPHF4bD4gb3B0
aW9uLCB0aGUgZGVmYXVsdCBpcyAxMjhNQi4gSWYgQjx2aWRlb3JhbT4gaXMgc2V0IGdyZWF0ZXIK
K3RoYW4gMTI4TUIsIGl0IHdpbGwgYmUgdHJpbW1lZCB0byAxMjhNQjsgaWYgc2V0IGxlc3MgdGhh
biAxMjhNQiwgYW4KK2Vycm9yIHdpbGwgYmUgdHJpZ2dlcmVkLgogCiBXaGVuIHVzaW5nIHRoZSBl
bXVsYXRlZCBDaXJydXMgZ3JhcGhpY3MgY2FyZCAoQjxzdGR2Z2E9MD4pCiB0aGUgYW1vdW50IG9m
IHZpZGVvIHJhbSBpcyBmaXhlZCBhdCA0TUIgd2hpY2ggaXMgc3VmZmljaWVudApAQCAtOTUxLDYg
Kzk1NCwxNCBAQCBhIENpcnJ1cyBMb2dpYyBHRDU0NDYgVkdBIGNhcmQuIElmIHlvdXIgCiBhIENp
cnJ1cyBMb2dpYyBHRDU0NDYgVkdBIGNhcmQuIElmIHlvdXIgZ3Vlc3Qgc3VwcG9ydHMgVkJFIDIu
MCBvcgogbGF0ZXIgKGUuZy4gV2luZG93cyBYUCBvbndhcmRzKSB0aGVuIHlvdSBzaG91bGQgZW5h
YmxlIHRoaXMuCiBzdGR2Z2Egc3VwcG9ydHMgbW9yZSB2aWRlbyByYW0gYW5kIGJpZ2dlciByZXNv
bHV0aW9ucyB0aGFuIENpcnJ1cy4KKworPWl0ZW0gQjxxeGw9Qk9PTEVBTj4KKworU2VsZWN0IGEg
UVhMIFZHQSBjYXJkIGFzIHRoZSBlbXVsYXRlZCBncmFwaGljcyBkZXZpY2UuCitJbiBnZW5lcmFs
LCBRWEwgc2hvdWxkIHdvcmsgd2l0aCB0aGUgU3BpY2UgcmVtb3RlIGRpc3BsYXkgcHJvdG9jb2wK
K2ZvciBhY2NlbGVyYXRpb24sIGFuZCBRWEwgZHJpdmVyIGlzIG5lY2Vzc2FyeSBpbiBndWVzdCBp
biB0aGlzIGNhc2UuCitRWEwgY2FuIGFsc28gd29yayB3aXRoIHRoZSBWTkMgcHJvdG9jb2wsIGJ1
dCBpdCB3aWxsIGJlIGxpa2UgYSBzdGFuZGFyZAorVkdBIHdpdGhvdXQgYWNjZWxlcmF0aW9uLgog
CiA9aXRlbSBCPHZuYz1CT09MRUFOPgogCmRpZmYgLXIgYzFjNTQ5YzRmZTllIHRvb2xzL2xpYnhs
L2xpYnhsX2NyZWF0ZS5jCi0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsX2NyZWF0ZS5jCU1vbiBPY3Qg
MTUgMTY6NTE6NDQgMjAxMiArMDEwMAorKysgYi90b29scy9saWJ4bC9saWJ4bF9jcmVhdGUuYwlU
aHUgT2N0IDE4IDE3OjUzOjI1IDIwMTIgKzA4MDAKQEAgLTIzMiw4ICsyMzIsMjkgQEAgaW50IGxp
YnhsX19kb21haW5fYnVpbGRfaW5mb19zZXRkZWZhdWx0KAogICAgIGNhc2UgTElCWExfRE9NQUlO
X1RZUEVfSFZNOgogICAgICAgICBpZiAoYl9pbmZvLT5zaGFkb3dfbWVta2IgPT0gTElCWExfTUVN
S0JfREVGQVVMVCkKICAgICAgICAgICAgIGJfaW5mby0+c2hhZG93X21lbWtiID0gMDsKKworICAg
ICAgICBpZiAoYl9pbmZvLT5kZXZpY2VfbW9kZWxfdmVyc2lvbiA9PSBMSUJYTF9ERVZJQ0VfTU9E
RUxfVkVSU0lPTl9RRU1VX1hFTgorICAgICAgICAgICAgJiYgYl9pbmZvLT51Lmh2bS52Z2Eua2lu
ZCA9PSBMSUJYTF9WR0FfSU5URVJGQUNFX1RZUEVfUVhMKSB7CisgICAgICAgICAgICAvKgorICAg
ICAgICAgICAgICogUVhMIG5lZWRzIDEyOCBNaWIgdmlkZW8gcmFtIGJ5IGRlZmF1bHQuCisgICAg
ICAgICAgICAgKi8KKyAgICAgICAgICAgIGlmIChiX2luZm8tPnZpZGVvX21lbWtiID09IExJQlhM
X01FTUtCX0RFRkFVTFQpIHsKKyAgICAgICAgICAgICAgICBiX2luZm8tPnZpZGVvX21lbWtiID0g
MTI4ICogMTAyNDsKKyAgICAgICAgICAgIH0KKyAgICAgICAgICAgIGlmIChiX2luZm8tPnZpZGVv
X21lbWtiIDwgMTI4ICogMTAyNCkgeworICAgICAgICAgICAgICAgIExJQlhMX19MT0coQ1RYLCBM
SUJYTF9fTE9HX0VSUk9SLAorICAgICAgICAgICAgICAgICAgICAiMTI4IE1pYiB2aWRlb3JhbSBp
cyBuZWNlc3NhcnkgZm9yIHF4bCBkZWZhdWx0Iik7CisgICAgICAgICAgICAgICAgcmV0dXJuIEVS
Uk9SX0lOVkFMOworICAgICAgICAgICAgfQorICAgICAgICAgICAgaWYgKGJfaW5mby0+dmlkZW9f
bWVta2IgPiAxMjggKiAxMDI0KSB7CisgICAgICAgICAgICAgICAgYl9pbmZvLT52aWRlb19tZW1r
YiA9IDEyOCAqIDEwMjQ7CisgICAgICAgICAgICAgICAgTElCWExfX0xPRyhDVFgsIExJQlhMX19M
T0dfV0FSTklORywKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAidHJpbSB2aWRlb3JhbSB0
byBxeGwgZGVmYXVsdDogMTI4IE1pYiIpOworICAgICAgICAgICAgfQorICAgICAgICB9CiAgICAg
ICAgIGlmIChiX2luZm8tPnZpZGVvX21lbWtiID09IExJQlhMX01FTUtCX0RFRkFVTFQpCiAgICAg
ICAgICAgICBiX2luZm8tPnZpZGVvX21lbWtiID0gOCAqIDEwMjQ7CisKICAgICAgICAgaWYgKGJf
aW5mby0+dS5odm0udGltZXJfbW9kZSA9PSBMSUJYTF9USU1FUl9NT0RFX0RFRkFVTFQpCiAgICAg
ICAgICAgICBiX2luZm8tPnUuaHZtLnRpbWVyX21vZGUgPQogICAgICAgICAgICAgICAgIExJQlhM
X1RJTUVSX01PREVfTk9fREVMQVlfRk9SX01JU1NFRF9USUNLUzsKZGlmZiAtciBjMWM1NDljNGZl
OWUgdG9vbHMvbGlieGwvbGlieGxfZG0uYwotLS0gYS90b29scy9saWJ4bC9saWJ4bF9kbS5jCU1v
biBPY3QgMTUgMTY6NTE6NDQgMjAxMiArMDEwMAorKysgYi90b29scy9saWJ4bC9saWJ4bF9kbS5j
CVRodSBPY3QgMTggMTc6NTM6MjUgMjAxMiArMDgwMApAQCAtMTgxLDYgKzE4MSw4IEBAIHN0YXRp
YyBjaGFyICoqIGxpYnhsX19idWlsZF9kZXZpY2VfbW9kZWwKICAgICAgICAgICAgIGJyZWFrOwog
ICAgICAgICBjYXNlIExJQlhMX1ZHQV9JTlRFUkZBQ0VfVFlQRV9DSVJSVVM6CiAgICAgICAgICAg
ICBicmVhazsKKyAgICAgICAgY2FzZSBMSUJYTF9WR0FfSU5URVJGQUNFX1RZUEVfUVhMOgorICAg
ICAgICAgICAgIGJyZWFrOwogICAgICAgICB9CiAKICAgICAgICAgaWYgKGJfaW5mby0+dS5odm0u
Ym9vdCkgewpAQCAtNDMwLDYgKzQzMiw5IEBAIHN0YXRpYyBjaGFyICoqIGxpYnhsX19idWlsZF9k
ZXZpY2VfbW9kZWwKICAgICAgICAgICAgIGJyZWFrOwogICAgICAgICBjYXNlIExJQlhMX1ZHQV9J
TlRFUkZBQ0VfVFlQRV9DSVJSVVM6CiAgICAgICAgICAgICBmbGV4YXJyYXlfdmFwcGVuZChkbV9h
cmdzLCAiLXZnYSIsICJjaXJydXMiLCBOVUxMKTsKKyAgICAgICAgICAgIGJyZWFrOworICAgICAg
ICBjYXNlIExJQlhMX1ZHQV9JTlRFUkZBQ0VfVFlQRV9RWEw6CisgICAgICAgICAgICBmbGV4YXJy
YXlfdmFwcGVuZChkbV9hcmdzLCAiLXZnYSIsICJxeGwiLCBOVUxMKTsKICAgICAgICAgICAgIGJy
ZWFrOwogICAgICAgICB9CiAKZGlmZiAtciBjMWM1NDljNGZlOWUgdG9vbHMvbGlieGwvbGlieGxf
dHlwZXMuaWRsCi0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsX3R5cGVzLmlkbAlNb24gT2N0IDE1IDE2
OjUxOjQ0IDIwMTIgKzAxMDAKKysrIGIvdG9vbHMvbGlieGwvbGlieGxfdHlwZXMuaWRsCVRodSBP
Y3QgMTggMTc6NTM6MjUgMjAxMiArMDgwMApAQCAtMTMwLDYgKzEzMCw3IEBAIGxpYnhsX3ZnYV9p
bnRlcmZhY2VfdHlwZSA9IEVudW1lcmF0aW9uKCIKIGxpYnhsX3ZnYV9pbnRlcmZhY2VfdHlwZSA9
IEVudW1lcmF0aW9uKCJ2Z2FfaW50ZXJmYWNlX3R5cGUiLCBbCiAgICAgKDEsICJDSVJSVVMiKSwK
ICAgICAoMiwgIlNURCIpLAorICAgICgzLCAiUVhMIiksCiAgICAgXSwgaW5pdF92YWwgPSAwKQog
CiAjCmRpZmYgLXIgYzFjNTQ5YzRmZTllIHRvb2xzL2xpYnhsL3hsX2NtZGltcGwuYwotLS0gYS90
b29scy9saWJ4bC94bF9jbWRpbXBsLmMJTW9uIE9jdCAxNSAxNjo1MTo0NCAyMDEyICswMTAwCisr
KyBiL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYwlUaHUgT2N0IDE4IDE3OjUzOjI1IDIwMTIgKzA4
MDAKQEAgLTE0MDIsNiArMTQwMiwxNCBAQCBza2lwX3ZmYjoKICAgICAgICAgICAgIGJfaW5mby0+
dS5odm0udmdhLmtpbmQgPSBsID8gTElCWExfVkdBX0lOVEVSRkFDRV9UWVBFX1NURCA6CiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIExJQlhMX1ZHQV9JTlRFUkZBQ0Vf
VFlQRV9DSVJSVVM7CiAKKyAgICAgICAgaWYgKCF4bHVfY2ZnX2dldF9sb25nKGNvbmZpZywgInF4
bCIsICZsLCAwKSkgeworICAgICAgICAgICAgaWYgKGwpIHsKKyAgICAgICAgICAgICAgICBiX2lu
Zm8tPnUuaHZtLnZnYS5raW5kID0gTElCWExfVkdBX0lOVEVSRkFDRV9UWVBFX1FYTDsKKyAgICAg
ICAgICAgIH0gZWxzZSBpZiAoIWJfaW5mby0+dS5odm0udmdhLmtpbmQpIHsKKyAgICAgICAgICAg
ICAgICBiX2luZm8tPnUuaHZtLnZnYS5raW5kID0gTElCWExfVkdBX0lOVEVSRkFDRV9UWVBFX0NJ
UlJVUzsKKyAgICAgICAgICAgIH0KKyAgICAgICAgfQorCiAgICAgICAgIHhsdV9jZmdfZ2V0X2Rl
ZmJvb2woY29uZmlnLCAidm5jIiwgJmJfaW5mby0+dS5odm0udm5jLmVuYWJsZSwgMCk7CiAgICAg
ICAgIHhsdV9jZmdfcmVwbGFjZV9zdHJpbmcgKGNvbmZpZywgInZuY2xpc3RlbiIsCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICZiX2luZm8tPnUuaHZtLnZuYy5saXN0ZW4sIDApOwo=
--f46d04462dd23088ac04cc52b9d0
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--f46d04462dd23088ac04cc52b9d0--


From xen-devel-bounces@lists.xen.org Thu Oct 18 10:20:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 10:20:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOnDB-0001yV-Qx; Thu, 18 Oct 2012 10:20:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOnD9-0001yD-Rx
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 10:20:20 +0000
Received: from [85.158.139.211:4243] by server-6.bemta-5.messagelabs.com id
	E2/21-32589-3E7DF705; Thu, 18 Oct 2012 10:20:19 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1350555616!22832231!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14463 invoked from network); 18 Oct 2012 10:20:16 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-16.tower-206.messagelabs.com with SMTP;
	18 Oct 2012 10:20:16 -0000
Received: from p5b2e3cc2.dip.t-dialin.net ([91.46.60.194] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from )
	id 1TOnD5-0001FP-BB; Thu, 18 Oct 2012 10:20:15 +0000
Message-ID: <507FD7DE.2010209@canonical.com>
Date: Thu, 18 Oct 2012 12:20:14 +0200
From: Stefan Bader 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Ian Campbell 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
	<1350482118.2460.74.camel@zakaz.uk.xensource.com>
	<507ECD06.2050407@canonical.com> <507ED038.8000806@citrix.com>
	<507FC51102000078000A235E@nat28.tlf.novell.com>
	<507FC71502000078000A236C@nat28.tlf.novell.com>
	<507FB1E1.8080700@canonical.com>
	<1350546483.28188.25.camel@dagon.hellion.org.uk>
In-Reply-To: <1350546483.28188.25.camel@dagon.hellion.org.uk>
X-Enigmail-Version: 1.4.5
Cc: Andrew Cooper ,
	Konrad Rzeszutek Wilk ,
	Jan Beulich ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============3410626000692852923=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============3410626000692852923==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig8243ECFB12C8B34C5DC00DE5"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig8243ECFB12C8B34C5DC00DE5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 18.10.2012 09:48, Ian Campbell wrote:
> On Thu, 2012-10-18 at 08:38 +0100, Stefan Bader wrote:
>> On 18.10.2012 09:08, Jan Beulich wrote:
>>>>>> On 18.10.12 at 09:00, "Jan Beulich"  wrote:
>>>>>>> On 17.10.12 at 17:35, Andrew Cooper  w=
rote:
>>>>> In each case, the event channels are masked (no surprise given the
>>>>> conversation so far on this thread), and have no pending events.=20
>>>>> Therefore, I believe we are looking at the same bug.
>>>>
>>>> That seems very unlikely (albeit not impossible) to me, given that
>>>> the non-pvops kernel uses ticket locks while the pvops one doesn't.
>>>
>>> And in fact we had a similar problem with our original ticket lock
>>> implementation, exposed by an open coded lock in the scheduler's
>>> run queue management. But that was really ticket lock specific,
>>> in that the fact that a CPU could passively become the owner of
>>> a lock while polling - that's impossible with pvops' byte locks afaic=
t.
>>
>> One of the trains of thought I had was whether it could happen that a =
cpu is in
>> polling and the task gets moved. But I don't think it can happen as th=
e
>> hypercall unlikely is a place where any schedule happens (preempt is n=
one). And
>> it would be much more common...
>>
>> One detail which I hope someone can fill in is the whole "interrupted =
spinlock"
>> thing. Saving the last lock pointer stored on the per-cpu lock_spinner=
s and so
>> on. Is that really only for spinlocks taken without interrupts disable=
d or do I
>> miss something there?
>=20
> spinning_lock() returns the old lock which the caller is expected to
> remember and replace via unspinning_lock() -- it effectively implements=

> a stack of locks which are being waited on. xen_spin_lock_slow (the onl=
y
> caller0 appears to do this correctly from a brief inspection.

Yes, just *when* can there be a stack of locks (spinlocks). The poll_irq
hypercall seems to be an active (in the sense of not preemting to another=
 task)
process. How could there be a situation that another lock (on the same cp=
u is
tried to be taken).
>=20
> Is there any chance this is just a simple AB-BA or similar type
> deadlock? Do we have data which suggests all vCPUs are waiting on the
> same lock or just that they are waiting on some lock? I suppose lockdep=

> (which I think you mentioned before?) would have caught this, unless pv=

> locks somehow confound it?

The one situation where I went deeper into the tasks that appeared to be =
on a
cpu it was one waiting for signalling a task that looked to be just sched=
uled
out and the cpu it was running on doing a idle balance that waited on the=
 lock
for cpu#0's runqueue. Which cpu#0 itself seemed to be waiting slow (the l=
ock
pointer was on lock_spinners[0]) but the lock itself was 0.
Though there is a chance that this is always just a coincidental state wh=
ere the
lock just was released and more related to how the Xen stack does a guest=
 dump.
So it would be to find who holds the other lock.
Unfortunately at least a full lock debugging enabled kernel is sufficient=
ly
different in timing that I cannot reproduce the issue on a test machine. =
And
from reported crashes in production I have no data.

>=20
> Ian.
>=20
>=20
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>=20



--------------enig8243ECFB12C8B34C5DC00DE5
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBCgAGBQJQf9feAAoJEOhnXe7L7s6jWi0QAIUmb9NQ1ilLciNpEM9r0ytT
/MKqWbj5nrwXiYnwV5TLX/aEf+f0sDX/YMQuY6rFcroGSRTzVhfP6Br2eWe095jQ
uyaJj7CsNP/tkHhohLLG5V3gYQu2dr5Gbxt2hCUuC8URYULsLI5ghBcawHeMNVll
hfU4DKlMEHWu6BxhEWZWvhvoA3o4j/GH5Kj16Jaqv1ejuxHxXfx4QXg7GseRPx7S
7Z+lRLmEkyTpj3E7yVyZatah3umm6CxsFX4biDKxolgbDAoROE2L04i5Lu/oQLdy
hcZiC5kiJDDN4A6tY5GmdDj4bbthDCwrWjudFrHXo0paR37qtzS7T/K8gUr8ZhtI
Bm7Wka7X3k6JTfDb8u4+h3TcTh6q/TRjEvyDOeyQHAt91GYDChfWxYwBxAjVHF/w
DvxAyz2r2atUdJwmza+vm11iuDr/8s41Hi6LUV7dKd3iEAp6tRC+G1FNQhi0/yxM
gzr4PNBGYdKkhQpDhm4Rm+X2FdrnLlP3B31gSMuQwBUzwkum5R1jk2IbUOkuEOgU
hr7BYCMVfapaQWp+AhXU8hzq/kZhB7zakO6hOu2C7I7oGIEyrBAeUiWPAw/ARMy+
t0lGYaf+zGl7rgvpvUXIJNKVvGx0IPYCfGioOcyafsuHS/7kfqsitpE5npj79bWa
o4bdTimUXvwj2qjF1yoa
=Qoqm
-----END PGP SIGNATURE-----

--------------enig8243ECFB12C8B34C5DC00DE5--


--===============3410626000692852923==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3410626000692852923==--


From xen-devel-bounces@lists.xen.org Thu Oct 18 10:20:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 10:20:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOnDB-0001yV-Qx; Thu, 18 Oct 2012 10:20:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOnD9-0001yD-Rx
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 10:20:20 +0000
Received: from [85.158.139.211:4243] by server-6.bemta-5.messagelabs.com id
	E2/21-32589-3E7DF705; Thu, 18 Oct 2012 10:20:19 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1350555616!22832231!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14463 invoked from network); 18 Oct 2012 10:20:16 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-16.tower-206.messagelabs.com with SMTP;
	18 Oct 2012 10:20:16 -0000
Received: from p5b2e3cc2.dip.t-dialin.net ([91.46.60.194] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from )
	id 1TOnD5-0001FP-BB; Thu, 18 Oct 2012 10:20:15 +0000
Message-ID: <507FD7DE.2010209@canonical.com>
Date: Thu, 18 Oct 2012 12:20:14 +0200
From: Stefan Bader 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Ian Campbell 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
	<1350482118.2460.74.camel@zakaz.uk.xensource.com>
	<507ECD06.2050407@canonical.com> <507ED038.8000806@citrix.com>
	<507FC51102000078000A235E@nat28.tlf.novell.com>
	<507FC71502000078000A236C@nat28.tlf.novell.com>
	<507FB1E1.8080700@canonical.com>
	<1350546483.28188.25.camel@dagon.hellion.org.uk>
In-Reply-To: <1350546483.28188.25.camel@dagon.hellion.org.uk>
X-Enigmail-Version: 1.4.5
Cc: Andrew Cooper ,
	Konrad Rzeszutek Wilk ,
	Jan Beulich ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============3410626000692852923=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============3410626000692852923==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig8243ECFB12C8B34C5DC00DE5"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig8243ECFB12C8B34C5DC00DE5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 18.10.2012 09:48, Ian Campbell wrote:
> On Thu, 2012-10-18 at 08:38 +0100, Stefan Bader wrote:
>> On 18.10.2012 09:08, Jan Beulich wrote:
>>>>>> On 18.10.12 at 09:00, "Jan Beulich"  wrote:
>>>>>>> On 17.10.12 at 17:35, Andrew Cooper  w=
rote:
>>>>> In each case, the event channels are masked (no surprise given the
>>>>> conversation so far on this thread), and have no pending events.=20
>>>>> Therefore, I believe we are looking at the same bug.
>>>>
>>>> That seems very unlikely (albeit not impossible) to me, given that
>>>> the non-pvops kernel uses ticket locks while the pvops one doesn't.
>>>
>>> And in fact we had a similar problem with our original ticket lock
>>> implementation, exposed by an open coded lock in the scheduler's
>>> run queue management. But that was really ticket lock specific,
>>> in that the fact that a CPU could passively become the owner of
>>> a lock while polling - that's impossible with pvops' byte locks afaic=
t.
>>
>> One of the trains of thought I had was whether it could happen that a =
cpu is in
>> polling and the task gets moved. But I don't think it can happen as th=
e
>> hypercall unlikely is a place where any schedule happens (preempt is n=
one). And
>> it would be much more common...
>>
>> One detail which I hope someone can fill in is the whole "interrupted =
spinlock"
>> thing. Saving the last lock pointer stored on the per-cpu lock_spinner=
s and so
>> on. Is that really only for spinlocks taken without interrupts disable=
d or do I
>> miss something there?
>=20
> spinning_lock() returns the old lock which the caller is expected to
> remember and replace via unspinning_lock() -- it effectively implements=

> a stack of locks which are being waited on. xen_spin_lock_slow (the onl=
y
> caller0 appears to do this correctly from a brief inspection.

Yes, just *when* can there be a stack of locks (spinlocks). The poll_irq
hypercall seems to be an active (in the sense of not preemting to another=
 task)
process. How could there be a situation that another lock (on the same cp=
u is
tried to be taken).
>=20
> Is there any chance this is just a simple AB-BA or similar type
> deadlock? Do we have data which suggests all vCPUs are waiting on the
> same lock or just that they are waiting on some lock? I suppose lockdep=

> (which I think you mentioned before?) would have caught this, unless pv=

> locks somehow confound it?

The one situation where I went deeper into the tasks that appeared to be =
on a
cpu it was one waiting for signalling a task that looked to be just sched=
uled
out and the cpu it was running on doing a idle balance that waited on the=
 lock
for cpu#0's runqueue. Which cpu#0 itself seemed to be waiting slow (the l=
ock
pointer was on lock_spinners[0]) but the lock itself was 0.
Though there is a chance that this is always just a coincidental state wh=
ere the
lock just was released and more related to how the Xen stack does a guest=
 dump.
So it would be to find who holds the other lock.
Unfortunately at least a full lock debugging enabled kernel is sufficient=
ly
different in timing that I cannot reproduce the issue on a test machine. =
And
from reported crashes in production I have no data.

>=20
> Ian.
>=20
>=20
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>=20



--------------enig8243ECFB12C8B34C5DC00DE5
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBCgAGBQJQf9feAAoJEOhnXe7L7s6jWi0QAIUmb9NQ1ilLciNpEM9r0ytT
/MKqWbj5nrwXiYnwV5TLX/aEf+f0sDX/YMQuY6rFcroGSRTzVhfP6Br2eWe095jQ
uyaJj7CsNP/tkHhohLLG5V3gYQu2dr5Gbxt2hCUuC8URYULsLI5ghBcawHeMNVll
hfU4DKlMEHWu6BxhEWZWvhvoA3o4j/GH5Kj16Jaqv1ejuxHxXfx4QXg7GseRPx7S
7Z+lRLmEkyTpj3E7yVyZatah3umm6CxsFX4biDKxolgbDAoROE2L04i5Lu/oQLdy
hcZiC5kiJDDN4A6tY5GmdDj4bbthDCwrWjudFrHXo0paR37qtzS7T/K8gUr8ZhtI
Bm7Wka7X3k6JTfDb8u4+h3TcTh6q/TRjEvyDOeyQHAt91GYDChfWxYwBxAjVHF/w
DvxAyz2r2atUdJwmza+vm11iuDr/8s41Hi6LUV7dKd3iEAp6tRC+G1FNQhi0/yxM
gzr4PNBGYdKkhQpDhm4Rm+X2FdrnLlP3B31gSMuQwBUzwkum5R1jk2IbUOkuEOgU
hr7BYCMVfapaQWp+AhXU8hzq/kZhB7zakO6hOu2C7I7oGIEyrBAeUiWPAw/ARMy+
t0lGYaf+zGl7rgvpvUXIJNKVvGx0IPYCfGioOcyafsuHS/7kfqsitpE5npj79bWa
o4bdTimUXvwj2qjF1yoa
=Qoqm
-----END PGP SIGNATURE-----

--------------enig8243ECFB12C8B34C5DC00DE5--


--===============3410626000692852923==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3410626000692852923==--


From xen-devel-bounces@lists.xen.org Thu Oct 18 10:36:13 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 10:36:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOnSH-0002JQ-FP; Thu, 18 Oct 2012 10:35:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOnSF-0002JL-Ts
	for Xen-devel@lists.xensource.com; Thu, 18 Oct 2012 10:35:56 +0000
Received: from [85.158.139.83:49857] by server-13.bemta-5.messagelabs.com id
	70/7F-30674-B8BDF705; Thu, 18 Oct 2012 10:35:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1350556554!34857378!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31062 invoked from network); 18 Oct 2012 10:35:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 10:35:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15250985"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 10:35:54 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 11:35:54 +0100
Message-ID: <1350556553.2460.108.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Mukesh Rathor 
Date: Thu, 18 Oct 2012 11:35:53 +0100
In-Reply-To: <20121017173448.7ef4c0b1@mantra.us.oracle.com>
References: <20121017173448.7ef4c0b1@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V3 6/6]: PVH:privcmd changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


> @@ -439,6 +490,19 @@ static long privcmd_ioctl(struct file *file,
>  	return ret;
>  }
>  
> +static void privcmd_close(struct vm_area_struct *vma)
> +{
> +	struct page **pages = vma ? vma->vm_private_data : NULL;

Can VMA really be NULL?...

> +	int numpgs = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;

...I assume not since you unconditionally dereference it here.

> +	if (!pages || !numpgs || !xen_feature(XENFEAT_auto_translated_physmap))

In the non-xlat case pages will (or should!) be 1 here which will pass
the first clause of the test.

Although the later clauses will catch this I think it would be worth
ordering the checks such that they are each valid, perhaps by pulling
the feature check to the front or by separating the !xlat case from the
other two which are valid iff xlat == True.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 10:36:13 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 10:36:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOnSH-0002JQ-FP; Thu, 18 Oct 2012 10:35:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOnSF-0002JL-Ts
	for Xen-devel@lists.xensource.com; Thu, 18 Oct 2012 10:35:56 +0000
Received: from [85.158.139.83:49857] by server-13.bemta-5.messagelabs.com id
	70/7F-30674-B8BDF705; Thu, 18 Oct 2012 10:35:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1350556554!34857378!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31062 invoked from network); 18 Oct 2012 10:35:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 10:35:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15250985"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 10:35:54 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 11:35:54 +0100
Message-ID: <1350556553.2460.108.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Mukesh Rathor 
Date: Thu, 18 Oct 2012 11:35:53 +0100
In-Reply-To: <20121017173448.7ef4c0b1@mantra.us.oracle.com>
References: <20121017173448.7ef4c0b1@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V3 6/6]: PVH:privcmd changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


> @@ -439,6 +490,19 @@ static long privcmd_ioctl(struct file *file,
>  	return ret;
>  }
>  
> +static void privcmd_close(struct vm_area_struct *vma)
> +{
> +	struct page **pages = vma ? vma->vm_private_data : NULL;

Can VMA really be NULL?...

> +	int numpgs = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;

...I assume not since you unconditionally dereference it here.

> +	if (!pages || !numpgs || !xen_feature(XENFEAT_auto_translated_physmap))

In the non-xlat case pages will (or should!) be 1 here which will pass
the first clause of the test.

Although the later clauses will catch this I think it would be worth
ordering the checks such that they are each valid, perhaps by pulling
the feature check to the front or by separating the !xlat case from the
other two which are valid iff xlat == True.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 10:39:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 10:39:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOnVs-0002TF-44; Thu, 18 Oct 2012 10:39:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOnVq-0002T9-Ob
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 10:39:38 +0000
Received: from [85.158.138.51:5771] by server-9.bemta-3.messagelabs.com id
	5A/BC-16841-A6CDF705; Thu, 18 Oct 2012 10:39:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1350556777!34837908!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13739 invoked from network); 18 Oct 2012 10:39:37 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-174.messagelabs.com with SMTP;
	18 Oct 2012 10:39:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 18 Oct 2012 11:39:36 +0100
Message-Id: <507FF88702000078000A24FE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 18 Oct 2012 11:39:35 +0100
From: "Jan Beulich" 
To: "Keir Fraser" 
References: <507D952802000078000A1BC5@nat28.tlf.novell.com>
	
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel 
Subject: Re: [Xen-devel] [PATCH 3/3] x86/HPET: cache MSI message last written
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 18.10.12 at 10:22, Keir Fraser  wrote:
> On 16/10/2012 16:11, "Jan Beulich"  wrote:
> 
>> Rather than spending measurable amounts of time reading back the most
>> recently written message, cache it in space previously unused, and thus
>> accelerate the CPU's entering of the intended C-state.
>> 
>> hpet_msi_read() ends up being unused after this change, but rather than
>> removing the function, it's being marked "unused" in order - that way
>> it can easily get used again should a new need for it arise.
> 
> Please use __attribute_used__

That wouldn't be correct: The function _is_ unused (and there's
no issue if it was used afaik), and the __used__ attribute ought
to tell the compiler to keep the function around despite not
having (visible to it) callers.

Jan

>> Signed-off-by: Jan Beulich 
> 
> Acked-by: Keir Fraser 
> 
>> --- a/xen/arch/x86/hpet.c
>> +++ b/xen/arch/x86/hpet.c
>> @@ -253,17 +253,19 @@ static void hpet_msi_mask(struct irq_des
>>  
>>  static void hpet_msi_write(struct hpet_event_channel *ch, struct msi_msg
>> *msg)
>>  {
>> +    ch->msi.msg = *msg;
>>      if ( iommu_intremap )
>>          iommu_update_ire_from_msi(&ch->msi, msg);
>>      hpet_write32(msg->data, HPET_Tn_ROUTE(ch->idx));
>>      hpet_write32(msg->address_lo, HPET_Tn_ROUTE(ch->idx) + 4);
>>  }
>>  
>> -static void hpet_msi_read(struct hpet_event_channel *ch, struct msi_msg 
> *msg)
>> +static void __attribute__((__unused__))
>> +hpet_msi_read(struct hpet_event_channel *ch, struct msi_msg *msg)
>>  {
>>      msg->data = hpet_read32(HPET_Tn_ROUTE(ch->idx));
>>      msg->address_lo = hpet_read32(HPET_Tn_ROUTE(ch->idx) + 4);
>> -    msg->address_hi = 0;
>> +    msg->address_hi = MSI_ADDR_BASE_HI;
>>      if ( iommu_intremap )
>>          iommu_read_msi_from_ire(&ch->msi, msg);
>>  }
>> @@ -285,20 +287,19 @@ static void hpet_msi_ack(struct irq_desc
>>  
>>  static void hpet_msi_set_affinity(struct irq_desc *desc, const cpumask_t
>> *mask)
>>  {
>> -    struct msi_msg msg;
>> -    unsigned int dest;
>> +    struct hpet_event_channel *ch = desc->action->dev_id;
>> +    struct msi_msg msg = ch->msi.msg;
>>  
>> -    dest = set_desc_affinity(desc, mask);
>> -    if (dest == BAD_APICID)
>> +    msg.dest32 = set_desc_affinity(desc, mask);
>> +    if ( msg.dest32 == BAD_APICID )
>>          return;
>>  
>> -    hpet_msi_read(desc->action->dev_id, &msg);
>>      msg.data &= ~MSI_DATA_VECTOR_MASK;
>>      msg.data |= MSI_DATA_VECTOR(desc->arch.vector);
>>      msg.address_lo &= ~MSI_ADDR_DEST_ID_MASK;
>> -    msg.address_lo |= MSI_ADDR_DEST_ID(dest);
>> -    msg.dest32 = dest;
>> -    hpet_msi_write(desc->action->dev_id, &msg);
>> +    msg.address_lo |= MSI_ADDR_DEST_ID(msg.dest32);
>> +    if ( msg.data != ch->msi.msg.data || msg.dest32 != ch->msi.msg.dest32 )
>> +        hpet_msi_write(ch, &msg);
>>  }
>>  
>>  /*
>> 
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org 
>> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 10:39:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 10:39:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOnVs-0002TF-44; Thu, 18 Oct 2012 10:39:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOnVq-0002T9-Ob
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 10:39:38 +0000
Received: from [85.158.138.51:5771] by server-9.bemta-3.messagelabs.com id
	5A/BC-16841-A6CDF705; Thu, 18 Oct 2012 10:39:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1350556777!34837908!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13739 invoked from network); 18 Oct 2012 10:39:37 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-174.messagelabs.com with SMTP;
	18 Oct 2012 10:39:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 18 Oct 2012 11:39:36 +0100
Message-Id: <507FF88702000078000A24FE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 18 Oct 2012 11:39:35 +0100
From: "Jan Beulich" 
To: "Keir Fraser" 
References: <507D952802000078000A1BC5@nat28.tlf.novell.com>
	
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel 
Subject: Re: [Xen-devel] [PATCH 3/3] x86/HPET: cache MSI message last written
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 18.10.12 at 10:22, Keir Fraser  wrote:
> On 16/10/2012 16:11, "Jan Beulich"  wrote:
> 
>> Rather than spending measurable amounts of time reading back the most
>> recently written message, cache it in space previously unused, and thus
>> accelerate the CPU's entering of the intended C-state.
>> 
>> hpet_msi_read() ends up being unused after this change, but rather than
>> removing the function, it's being marked "unused" in order - that way
>> it can easily get used again should a new need for it arise.
> 
> Please use __attribute_used__

That wouldn't be correct: The function _is_ unused (and there's
no issue if it was used afaik), and the __used__ attribute ought
to tell the compiler to keep the function around despite not
having (visible to it) callers.

Jan

>> Signed-off-by: Jan Beulich 
> 
> Acked-by: Keir Fraser 
> 
>> --- a/xen/arch/x86/hpet.c
>> +++ b/xen/arch/x86/hpet.c
>> @@ -253,17 +253,19 @@ static void hpet_msi_mask(struct irq_des
>>  
>>  static void hpet_msi_write(struct hpet_event_channel *ch, struct msi_msg
>> *msg)
>>  {
>> +    ch->msi.msg = *msg;
>>      if ( iommu_intremap )
>>          iommu_update_ire_from_msi(&ch->msi, msg);
>>      hpet_write32(msg->data, HPET_Tn_ROUTE(ch->idx));
>>      hpet_write32(msg->address_lo, HPET_Tn_ROUTE(ch->idx) + 4);
>>  }
>>  
>> -static void hpet_msi_read(struct hpet_event_channel *ch, struct msi_msg 
> *msg)
>> +static void __attribute__((__unused__))
>> +hpet_msi_read(struct hpet_event_channel *ch, struct msi_msg *msg)
>>  {
>>      msg->data = hpet_read32(HPET_Tn_ROUTE(ch->idx));
>>      msg->address_lo = hpet_read32(HPET_Tn_ROUTE(ch->idx) + 4);
>> -    msg->address_hi = 0;
>> +    msg->address_hi = MSI_ADDR_BASE_HI;
>>      if ( iommu_intremap )
>>          iommu_read_msi_from_ire(&ch->msi, msg);
>>  }
>> @@ -285,20 +287,19 @@ static void hpet_msi_ack(struct irq_desc
>>  
>>  static void hpet_msi_set_affinity(struct irq_desc *desc, const cpumask_t
>> *mask)
>>  {
>> -    struct msi_msg msg;
>> -    unsigned int dest;
>> +    struct hpet_event_channel *ch = desc->action->dev_id;
>> +    struct msi_msg msg = ch->msi.msg;
>>  
>> -    dest = set_desc_affinity(desc, mask);
>> -    if (dest == BAD_APICID)
>> +    msg.dest32 = set_desc_affinity(desc, mask);
>> +    if ( msg.dest32 == BAD_APICID )
>>          return;
>>  
>> -    hpet_msi_read(desc->action->dev_id, &msg);
>>      msg.data &= ~MSI_DATA_VECTOR_MASK;
>>      msg.data |= MSI_DATA_VECTOR(desc->arch.vector);
>>      msg.address_lo &= ~MSI_ADDR_DEST_ID_MASK;
>> -    msg.address_lo |= MSI_ADDR_DEST_ID(dest);
>> -    msg.dest32 = dest;
>> -    hpet_msi_write(desc->action->dev_id, &msg);
>> +    msg.address_lo |= MSI_ADDR_DEST_ID(msg.dest32);
>> +    if ( msg.data != ch->msi.msg.data || msg.dest32 != ch->msi.msg.dest32 )
>> +        hpet_msi_write(ch, &msg);
>>  }
>>  
>>  /*
>> 
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org 
>> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 10:45:39 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 10:45:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOnbL-0002dq-2m; Thu, 18 Oct 2012 10:45:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOnbJ-0002dl-MS
	for Xen-devel@lists.xensource.com; Thu, 18 Oct 2012 10:45:17 +0000
Received: from [85.158.139.83:11761] by server-11.bemta-5.messagelabs.com id
	51/28-14870-DBDDF705; Thu, 18 Oct 2012 10:45:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1350557115!35248652!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17855 invoked from network); 18 Oct 2012 10:45:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 10:45:16 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15251209"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 10:44:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 11:44:38 +0100
Message-ID: <1350557077.2460.113.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Mukesh Rathor 
Date: Thu, 18 Oct 2012 11:44:37 +0100
In-Reply-To: <20121017173005.73a03eec@mantra.us.oracle.com>
References: <20121017173005.73a03eec@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V3 2/6]: PVH: use native irq, enable callback,
 use HVM ring ops, smp, ...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-18 at 01:30 +0100, Mukesh Rathor wrote:
> PVH: make gdt_frames[]/gdt_ents into a union with {gdtaddr, gdtsz}, PVH
> only needs to send down gdtaddr and gdtsz. irq.c: PVH uses
> native_irq_ops. vcpu hotplug is currently not available for PVH.
> events.c: setup callback vector for PVH. smp.c: This pertains to
> bringing up smp vcpus. PVH runs in ring 0, so syscalls are native.
> Also, the vcpu context is send down via the hcall to be set in the
> vmcs. gdtaddr and gdtsz are unionionized as PVH only needs to send
> these two to be set in the vmcs. Finally, PVH ring ops uses HVM paths
> for xenbus.
> 
> Signed-off-by: Mukesh Rathor 
> ---
>  arch/x86/include/asm/xen/interface.h |   11 +++++-
>  arch/x86/xen/irq.c                   |    5 ++-
>  arch/x86/xen/p2m.c                   |    2 +-
>  arch/x86/xen/smp.c                   |   75
> ++++++++++++++++++++++------------ drivers/xen/cpu_hotplug.c
> |    4 +- drivers/xen/events.c                 |    9 ++++-
>  drivers/xen/xenbus/xenbus_client.c   |    3 +-

This patch seems to have been horribly whitespace damaged.

Have you seen "git send-email" ? It's very useful for avoiding this sort
of thing and also takes a lot of the grunt work out of reposting a
series.

It also chains the patches as replies to the introductory zero-th mail
-- which is something I've been meaning to ask you to do for a while.
It's useful because it joins the series together in a thread which makes
it easier to keep track of in my INBOX.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 10:45:39 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 10:45:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOnbL-0002dq-2m; Thu, 18 Oct 2012 10:45:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOnbJ-0002dl-MS
	for Xen-devel@lists.xensource.com; Thu, 18 Oct 2012 10:45:17 +0000
Received: from [85.158.139.83:11761] by server-11.bemta-5.messagelabs.com id
	51/28-14870-DBDDF705; Thu, 18 Oct 2012 10:45:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1350557115!35248652!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17855 invoked from network); 18 Oct 2012 10:45:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 10:45:16 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15251209"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 10:44:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 11:44:38 +0100
Message-ID: <1350557077.2460.113.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Mukesh Rathor 
Date: Thu, 18 Oct 2012 11:44:37 +0100
In-Reply-To: <20121017173005.73a03eec@mantra.us.oracle.com>
References: <20121017173005.73a03eec@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V3 2/6]: PVH: use native irq, enable callback,
 use HVM ring ops, smp, ...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-18 at 01:30 +0100, Mukesh Rathor wrote:
> PVH: make gdt_frames[]/gdt_ents into a union with {gdtaddr, gdtsz}, PVH
> only needs to send down gdtaddr and gdtsz. irq.c: PVH uses
> native_irq_ops. vcpu hotplug is currently not available for PVH.
> events.c: setup callback vector for PVH. smp.c: This pertains to
> bringing up smp vcpus. PVH runs in ring 0, so syscalls are native.
> Also, the vcpu context is send down via the hcall to be set in the
> vmcs. gdtaddr and gdtsz are unionionized as PVH only needs to send
> these two to be set in the vmcs. Finally, PVH ring ops uses HVM paths
> for xenbus.
> 
> Signed-off-by: Mukesh Rathor 
> ---
>  arch/x86/include/asm/xen/interface.h |   11 +++++-
>  arch/x86/xen/irq.c                   |    5 ++-
>  arch/x86/xen/p2m.c                   |    2 +-
>  arch/x86/xen/smp.c                   |   75
> ++++++++++++++++++++++------------ drivers/xen/cpu_hotplug.c
> |    4 +- drivers/xen/events.c                 |    9 ++++-
>  drivers/xen/xenbus/xenbus_client.c   |    3 +-

This patch seems to have been horribly whitespace damaged.

Have you seen "git send-email" ? It's very useful for avoiding this sort
of thing and also takes a lot of the grunt work out of reposting a
series.

It also chains the patches as replies to the introductory zero-th mail
-- which is something I've been meaning to ask you to do for a while.
It's useful because it joins the series together in a thread which makes
it easier to keep track of in my INBOX.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 10:47:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 10:47:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOndC-0002j1-Ju; Thu, 18 Oct 2012 10:47:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOndB-0002iv-Mk
	for Xen-devel@lists.xensource.com; Thu, 18 Oct 2012 10:47:13 +0000
Received: from [85.158.138.51:53563] by server-9.bemta-3.messagelabs.com id
	B4/1B-16841-03EDF705; Thu, 18 Oct 2012 10:47:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1350557232!34838962!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8882 invoked from network); 18 Oct 2012 10:47:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 10:47:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15251257"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 10:47:12 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 11:47:12 +0100
Message-ID: <1350557230.2460.115.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Mukesh Rathor 
Date: Thu, 18 Oct 2012 11:47:10 +0100
In-Reply-To: <20121017173119.4e12b222@mantra.us.oracle.com>
References: <20121017173119.4e12b222@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V3 3/6]: PVH:  mmu related changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-18 at 01:31 +0100, Mukesh Rathor wrote:
>          * the initial domain. For guests using the toolstack, they are in:
> @@ -2177,8 +2210,20 @@ static const struct pv_mmu_ops xen_mmu_ops __initconst = {
> 
>  void __init xen_init_mmu_ops(void)
>  {
> -       x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
>         x86_init.paging.pagetable_init = xen_pagetable_init;
> +
> +       if (xen_feature(XENFEAT_auto_translated_physmap)) {
> +               pv_mmu_ops.flush_tlb_others = xen_flush_tlb_others;
> +#if 0

I don't recall seeing this #if 0 before -- is it new and/or deliberate?

If it is a marker for future work can we leave it out for now?

> +               /* For PCI devices to map iomem. */
> +               if (xen_initial_domain()) {
> +                       pv_mmu_ops.set_pte = native_set_pte;
> +                       pv_mmu_ops.set_pte_at = native_set_pte_at;
> +               }
> +#endif
> +               return;
> +       }
> +       x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
>         pv_mmu_ops = xen_mmu_ops;
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 10:47:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 10:47:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOndC-0002j1-Ju; Thu, 18 Oct 2012 10:47:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOndB-0002iv-Mk
	for Xen-devel@lists.xensource.com; Thu, 18 Oct 2012 10:47:13 +0000
Received: from [85.158.138.51:53563] by server-9.bemta-3.messagelabs.com id
	B4/1B-16841-03EDF705; Thu, 18 Oct 2012 10:47:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1350557232!34838962!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8882 invoked from network); 18 Oct 2012 10:47:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 10:47:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15251257"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 10:47:12 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 11:47:12 +0100
Message-ID: <1350557230.2460.115.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Mukesh Rathor 
Date: Thu, 18 Oct 2012 11:47:10 +0100
In-Reply-To: <20121017173119.4e12b222@mantra.us.oracle.com>
References: <20121017173119.4e12b222@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V3 3/6]: PVH:  mmu related changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-18 at 01:31 +0100, Mukesh Rathor wrote:
>          * the initial domain. For guests using the toolstack, they are in:
> @@ -2177,8 +2210,20 @@ static const struct pv_mmu_ops xen_mmu_ops __initconst = {
> 
>  void __init xen_init_mmu_ops(void)
>  {
> -       x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
>         x86_init.paging.pagetable_init = xen_pagetable_init;
> +
> +       if (xen_feature(XENFEAT_auto_translated_physmap)) {
> +               pv_mmu_ops.flush_tlb_others = xen_flush_tlb_others;
> +#if 0

I don't recall seeing this #if 0 before -- is it new and/or deliberate?

If it is a marker for future work can we leave it out for now?

> +               /* For PCI devices to map iomem. */
> +               if (xen_initial_domain()) {
> +                       pv_mmu_ops.set_pte = native_set_pte;
> +                       pv_mmu_ops.set_pte_at = native_set_pte_at;
> +               }
> +#endif
> +               return;
> +       }
> +       x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
>         pv_mmu_ops = xen_mmu_ops;
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 10:47:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 10:47:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOndG-0002jS-WD; Thu, 18 Oct 2012 10:47:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOndF-0002jD-JI
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 10:47:17 +0000
Received: from [85.158.137.99:18937] by server-8.bemta-3.messagelabs.com id
	10/E8-10525-43EDF705; Thu, 18 Oct 2012 10:47:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1350557236!16931126!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17595 invoked from network); 18 Oct 2012 10:47:16 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-217.messagelabs.com with SMTP;
	18 Oct 2012 10:47:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 18 Oct 2012 11:47:15 +0100
Message-Id: <507FFA5102000078000A250D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 18 Oct 2012 11:47:13 +0100
From: "Jan Beulich" 
To: "Stefan Bader" 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
	<1350482118.2460.74.camel@zakaz.uk.xensource.com>
	<507ECD06.2050407@canonical.com> <507ED038.8000806@citrix.com>
	<507FC51102000078000A235E@nat28.tlf.novell.com>
	<507FC71502000078000A236C@nat28.tlf.novell.com>
	<507FB1E1.8080700@canonical.com>
	<1350546483.28188.25.camel@dagon.hellion.org.uk>
	<507FD7DE.2010209@canonical.com>
In-Reply-To: <507FD7DE.2010209@canonical.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper ,
	Konrad Rzeszutek Wilk ,
	Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 18.10.12 at 12:20, Stefan Bader  wrote:
> On 18.10.2012 09:48, Ian Campbell wrote:
>> spinning_lock() returns the old lock which the caller is expected to
>> remember and replace via unspinning_lock() -- it effectively implements
>> a stack of locks which are being waited on. xen_spin_lock_slow (the only
>> caller0 appears to do this correctly from a brief inspection.
> 
> Yes, just *when* can there be a stack of locks (spinlocks). The poll_irq
> hypercall seems to be an active (in the sense of not preemting to another 
> task)
> process. How could there be a situation that another lock (on the same cpu 
> is tried to be taken).

Obviously when this is an acquire not disabling interrupts, and
an interrupt comes in while in the poll hypercall (or about to go
there, or just having come back from one).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 10:47:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 10:47:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOndG-0002jS-WD; Thu, 18 Oct 2012 10:47:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOndF-0002jD-JI
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 10:47:17 +0000
Received: from [85.158.137.99:18937] by server-8.bemta-3.messagelabs.com id
	10/E8-10525-43EDF705; Thu, 18 Oct 2012 10:47:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1350557236!16931126!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17595 invoked from network); 18 Oct 2012 10:47:16 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-217.messagelabs.com with SMTP;
	18 Oct 2012 10:47:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 18 Oct 2012 11:47:15 +0100
Message-Id: <507FFA5102000078000A250D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 18 Oct 2012 11:47:13 +0100
From: "Jan Beulich" 
To: "Stefan Bader" 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
	<1350482118.2460.74.camel@zakaz.uk.xensource.com>
	<507ECD06.2050407@canonical.com> <507ED038.8000806@citrix.com>
	<507FC51102000078000A235E@nat28.tlf.novell.com>
	<507FC71502000078000A236C@nat28.tlf.novell.com>
	<507FB1E1.8080700@canonical.com>
	<1350546483.28188.25.camel@dagon.hellion.org.uk>
	<507FD7DE.2010209@canonical.com>
In-Reply-To: <507FD7DE.2010209@canonical.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper ,
	Konrad Rzeszutek Wilk ,
	Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 18.10.12 at 12:20, Stefan Bader  wrote:
> On 18.10.2012 09:48, Ian Campbell wrote:
>> spinning_lock() returns the old lock which the caller is expected to
>> remember and replace via unspinning_lock() -- it effectively implements
>> a stack of locks which are being waited on. xen_spin_lock_slow (the only
>> caller0 appears to do this correctly from a brief inspection.
> 
> Yes, just *when* can there be a stack of locks (spinlocks). The poll_irq
> hypercall seems to be an active (in the sense of not preemting to another 
> task)
> process. How could there be a situation that another lock (on the same cpu 
> is tried to be taken).

Obviously when this is an acquire not disabling interrupts, and
an interrupt comes in while in the poll hypercall (or about to go
there, or just having come back from one).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 10:50:33 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 10:50:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOng7-0002zn-Ng; Thu, 18 Oct 2012 10:50:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOng6-0002zf-7V
	for Xen-devel@lists.xensource.com; Thu, 18 Oct 2012 10:50:14 +0000
Received: from [85.158.137.99:61803] by server-14.bemta-3.messagelabs.com id
	9F/FA-17276-5EEDF705; Thu, 18 Oct 2012 10:50:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1350557410!22040626!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24217 invoked from network); 18 Oct 2012 10:50:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 10:50:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15251311"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 10:49:33 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 11:49:33 +0100
Message-ID: <1350557371.2460.117.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Mukesh Rathor 
Date: Thu, 18 Oct 2012 11:49:31 +0100
In-Reply-To: <20121017173223.7ea1901d@mantra.us.oracle.com>
References: <20121017173223.7ea1901d@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V3 4/6]: PVH:bootup and setup related
 changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-18 at 01:32 +0100, Mukesh Rathor wrote:
> 
> +       /* PVH TBD/FIXME: vcpu info placement in phase 2 */
> +       if (xen_pvh_domain())
> +               return; 

Do you have a list of future work before PVH is "feature complete"
somewhere?

I wouldn't count vcpu placement specifically against completeness but
the TBD triggered the thought.

For example I was reviewing a migration patch this morning and was
wondering if that sort of thing had been investigated yet.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 10:50:33 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 10:50:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOng7-0002zn-Ng; Thu, 18 Oct 2012 10:50:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOng6-0002zf-7V
	for Xen-devel@lists.xensource.com; Thu, 18 Oct 2012 10:50:14 +0000
Received: from [85.158.137.99:61803] by server-14.bemta-3.messagelabs.com id
	9F/FA-17276-5EEDF705; Thu, 18 Oct 2012 10:50:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1350557410!22040626!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24217 invoked from network); 18 Oct 2012 10:50:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 10:50:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15251311"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 10:49:33 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 11:49:33 +0100
Message-ID: <1350557371.2460.117.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Mukesh Rathor 
Date: Thu, 18 Oct 2012 11:49:31 +0100
In-Reply-To: <20121017173223.7ea1901d@mantra.us.oracle.com>
References: <20121017173223.7ea1901d@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V3 4/6]: PVH:bootup and setup related
 changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-18 at 01:32 +0100, Mukesh Rathor wrote:
> 
> +       /* PVH TBD/FIXME: vcpu info placement in phase 2 */
> +       if (xen_pvh_domain())
> +               return; 

Do you have a list of future work before PVH is "feature complete"
somewhere?

I wouldn't count vcpu placement specifically against completeness but
the TBD triggered the thought.

For example I was reviewing a migration patch this morning and was
wondering if that sort of thing had been investigated yet.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 10:57:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 10:57:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOnnM-0003FD-Qg; Thu, 18 Oct 2012 10:57:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOnnL-0003F8-RI
	for Xen-devel@lists.xensource.com; Thu, 18 Oct 2012 10:57:44 +0000
Received: from [85.158.138.51:64923] by server-15.bemta-3.messagelabs.com id
	C4/A8-10261-7A0EF705; Thu, 18 Oct 2012 10:57:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1350557862!25975015!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7794 invoked from network); 18 Oct 2012 10:57:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 10:57:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15251514"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 10:57:42 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 18 Oct 2012 11:57:42 +0100
Date: Thu, 18 Oct 2012 11:57:18 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Mukesh Rathor 
In-Reply-To: <20121017172642.349b2aae@mantra.us.oracle.com>
Message-ID: 
References: <20121017172642.349b2aae@mantra.us.oracle.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V3 1/6]: PVH: basic and header changes,
 elfnote changes, ...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 18 Oct 2012, Mukesh Rathor wrote:
> [PATCH 1/6] PVH: is a PV linux guest that has extended capabilities. This patch allows it to be configured and enabled. Also, basic header file changes to add new subcalls to physmap hypercall. Lastly, mfn_to_local_pfn must return mfn for paging mode translate.
> 
> Signed-off-by: Mukesh Rathor 
> ---
>  arch/x86/include/asm/xen/page.h |    3 +++
>  arch/x86/xen/Kconfig            |   10 ++++++++++
>  arch/x86/xen/xen-head.S         |   11 ++++++++++-
>  include/xen/interface/memory.h  |   24 +++++++++++++++++++++++-
>  include/xen/interface/physdev.h |   10 ++++++++++
>  5 files changed, 56 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
> index 472b9b7..6af440d 100644
> --- a/arch/x86/include/asm/xen/page.h
> +++ b/arch/x86/include/asm/xen/page.h
> @@ -159,6 +159,9 @@ static inline xpaddr_t machine_to_phys(xmaddr_t machine)
>  static inline unsigned long mfn_to_local_pfn(unsigned long mfn)
>  {
>  	unsigned long pfn = mfn_to_pfn(mfn);
> +
> +	if (xen_feature(XENFEAT_auto_translated_physmap))
> +		return mfn;
>  	if (get_phys_to_machine(pfn) != mfn)
>  		return -1; /* force !pfn_valid() */
>  	return pfn;
> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> index fdce49c..822c5a0 100644
> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@ -50,3 +50,13 @@ config XEN_DEBUG_FS
>  	  Enable statistics output and various tuning options in debugfs.
>  	  Enabling this option may incur a significant performance overhead.
>  
> +config XEN_X86_PVH
> +	bool "Support for running as a PVH guest (EXPERIMENTAL)"
> +	depends on X86_64 && XEN && EXPERIMENTAL
> +	default n
> +	help
> +	   This option enables support for running as a PVH guest (PV guest
> +	   using hardware extensions) under a suitably capable hypervisor.
> +	   This option is EXPERIMENTAL because the hypervisor interfaces
> +	   which it uses are not yet considered stable therefore backwards and
> +	   forwards compatibility is not yet guaranteed.  If unsure, say N.

Do we really need the kconfig symbol? Why can't we have it always
enabled?


> diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
> index 7faed58..1a6bca1 100644
> --- a/arch/x86/xen/xen-head.S
> +++ b/arch/x86/xen/xen-head.S
> @@ -13,6 +13,15 @@
>  #include 
>  #include 
>  
> +#ifdef CONFIG_XEN_X86_PVH
> +#define FEATURES_PVH "|writable_descriptor_tables" \
> +		     "|auto_translated_physmap" \
> +		     "|supervisor_mode_kernel" \
> +		     "|hvm_callback_vector"
> +#else
> +#define FEATURES_PVH /* Not supported */
> +#endif
> +
>  	__INIT
>  ENTRY(startup_xen)
>  	cld
> @@ -95,7 +104,7 @@ NEXT_HYPERCALL(arch_6)
>  #endif
>  	ELFNOTE(Xen, XEN_ELFNOTE_ENTRY,          _ASM_PTR startup_xen)
>  	ELFNOTE(Xen, XEN_ELFNOTE_HYPERCALL_PAGE, _ASM_PTR hypercall_page)
> -	ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,       .asciz "!writable_page_tables|pae_pgdir_above_4gb")
> +	ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,       .asciz "!writable_page_tables|pae_pgdir_above_4gb"FEATURES_PVH)
>  	ELFNOTE(Xen, XEN_ELFNOTE_PAE_MODE,       .asciz "yes")
>  	ELFNOTE(Xen, XEN_ELFNOTE_LOADER,         .asciz "generic")
>  	ELFNOTE(Xen, XEN_ELFNOTE_L1_MFN_VALID,

Considering that the PVH capability ends up in an ELF note, the kconfig
symbol is actually useful at least for debugging: it is the only way to
disable it from the guest side. However I would imaging that Xen would
always provide an option to disable PVH features in a VM or dom0.


> diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
> index d8e33a9..425911f 100644
> --- a/include/xen/interface/memory.h
> +++ b/include/xen/interface/memory.h
> @@ -169,7 +169,13 @@ struct xen_add_to_physmap {
>      /* Source mapping space. */
>  #define XENMAPSPACE_shared_info 0 /* shared info page */
>  #define XENMAPSPACE_grant_table 1 /* grant table page */
> -    unsigned int space;
> +#define XENMAPSPACE_gmfn        2 /* GMFN */
> +#define XENMAPSPACE_gmfn_range  3 /* GMFN range */
> +#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */
> +    uint16_t space;
> +    domid_t foreign_domid;         /* IFF XENMAPSPACE_gmfn_foreign */
> +
> +#define XENMAPIDX_grant_table_status 0x80000000
>  
>      /* Index into source mapping space. */
>      unsigned long idx;
> @@ -237,4 +243,20 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_memory_map);
>   * during a driver critical region.
>   */
>  extern spinlock_t xen_reservation_lock;
> +
> +/*
> + * Unmaps the page appearing at a particular GPFN from the specified guest's
> + * pseudophysical address space.
> + * arg == addr of xen_remove_from_physmap_t.
> + */
> +#define XENMEM_remove_from_physmap      15
> +struct xen_remove_from_physmap {
> +    /* Which domain to change the mapping for. */
> +    domid_t domid;
> +
> +    /* GPFN of the current mapping of the page. */
> +    xen_pfn_t gpfn;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_remove_from_physmap);
> +
>  #endif /* __XEN_PUBLIC_MEMORY_H__ */

these bits have been submitted separately by Ian, if I am not mistaken.


> diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
> index 9ce788d..3b9d5b6 100644
> --- a/include/xen/interface/physdev.h
> +++ b/include/xen/interface/physdev.h
> @@ -258,6 +258,16 @@ struct physdev_pci_device {
>      uint8_t devfn;
>  };
>  
> +#define PHYSDEVOP_pvh_map_iomem        30

I would just call this PHYSDEVOP_map_iomem, we might use it on non-PVH
guests as well one day.


> +struct physdev_map_iomem {
> +    /* IN */
> +    uint64_t first_gfn;
> +    uint64_t first_mfn;
> +    uint32_t nr_mfns;
> +    uint32_t add_mapping;        /* 1 == add mapping;  0 == unmap */
> +
> +};
> +
>  /*
>   * Notify that some PIRQ-bound event channels have been unmasked.
>   * ** This command is obsolete since interface version 0x00030202 and is **
> -- 
> 1.7.2.3
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 10:57:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 10:57:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOnnM-0003FD-Qg; Thu, 18 Oct 2012 10:57:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOnnL-0003F8-RI
	for Xen-devel@lists.xensource.com; Thu, 18 Oct 2012 10:57:44 +0000
Received: from [85.158.138.51:64923] by server-15.bemta-3.messagelabs.com id
	C4/A8-10261-7A0EF705; Thu, 18 Oct 2012 10:57:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1350557862!25975015!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7794 invoked from network); 18 Oct 2012 10:57:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 10:57:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15251514"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 10:57:42 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 18 Oct 2012 11:57:42 +0100
Date: Thu, 18 Oct 2012 11:57:18 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Mukesh Rathor 
In-Reply-To: <20121017172642.349b2aae@mantra.us.oracle.com>
Message-ID: 
References: <20121017172642.349b2aae@mantra.us.oracle.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V3 1/6]: PVH: basic and header changes,
 elfnote changes, ...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 18 Oct 2012, Mukesh Rathor wrote:
> [PATCH 1/6] PVH: is a PV linux guest that has extended capabilities. This patch allows it to be configured and enabled. Also, basic header file changes to add new subcalls to physmap hypercall. Lastly, mfn_to_local_pfn must return mfn for paging mode translate.
> 
> Signed-off-by: Mukesh Rathor 
> ---
>  arch/x86/include/asm/xen/page.h |    3 +++
>  arch/x86/xen/Kconfig            |   10 ++++++++++
>  arch/x86/xen/xen-head.S         |   11 ++++++++++-
>  include/xen/interface/memory.h  |   24 +++++++++++++++++++++++-
>  include/xen/interface/physdev.h |   10 ++++++++++
>  5 files changed, 56 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
> index 472b9b7..6af440d 100644
> --- a/arch/x86/include/asm/xen/page.h
> +++ b/arch/x86/include/asm/xen/page.h
> @@ -159,6 +159,9 @@ static inline xpaddr_t machine_to_phys(xmaddr_t machine)
>  static inline unsigned long mfn_to_local_pfn(unsigned long mfn)
>  {
>  	unsigned long pfn = mfn_to_pfn(mfn);
> +
> +	if (xen_feature(XENFEAT_auto_translated_physmap))
> +		return mfn;
>  	if (get_phys_to_machine(pfn) != mfn)
>  		return -1; /* force !pfn_valid() */
>  	return pfn;
> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> index fdce49c..822c5a0 100644
> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@ -50,3 +50,13 @@ config XEN_DEBUG_FS
>  	  Enable statistics output and various tuning options in debugfs.
>  	  Enabling this option may incur a significant performance overhead.
>  
> +config XEN_X86_PVH
> +	bool "Support for running as a PVH guest (EXPERIMENTAL)"
> +	depends on X86_64 && XEN && EXPERIMENTAL
> +	default n
> +	help
> +	   This option enables support for running as a PVH guest (PV guest
> +	   using hardware extensions) under a suitably capable hypervisor.
> +	   This option is EXPERIMENTAL because the hypervisor interfaces
> +	   which it uses are not yet considered stable therefore backwards and
> +	   forwards compatibility is not yet guaranteed.  If unsure, say N.

Do we really need the kconfig symbol? Why can't we have it always
enabled?


> diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
> index 7faed58..1a6bca1 100644
> --- a/arch/x86/xen/xen-head.S
> +++ b/arch/x86/xen/xen-head.S
> @@ -13,6 +13,15 @@
>  #include 
>  #include 
>  
> +#ifdef CONFIG_XEN_X86_PVH
> +#define FEATURES_PVH "|writable_descriptor_tables" \
> +		     "|auto_translated_physmap" \
> +		     "|supervisor_mode_kernel" \
> +		     "|hvm_callback_vector"
> +#else
> +#define FEATURES_PVH /* Not supported */
> +#endif
> +
>  	__INIT
>  ENTRY(startup_xen)
>  	cld
> @@ -95,7 +104,7 @@ NEXT_HYPERCALL(arch_6)
>  #endif
>  	ELFNOTE(Xen, XEN_ELFNOTE_ENTRY,          _ASM_PTR startup_xen)
>  	ELFNOTE(Xen, XEN_ELFNOTE_HYPERCALL_PAGE, _ASM_PTR hypercall_page)
> -	ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,       .asciz "!writable_page_tables|pae_pgdir_above_4gb")
> +	ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,       .asciz "!writable_page_tables|pae_pgdir_above_4gb"FEATURES_PVH)
>  	ELFNOTE(Xen, XEN_ELFNOTE_PAE_MODE,       .asciz "yes")
>  	ELFNOTE(Xen, XEN_ELFNOTE_LOADER,         .asciz "generic")
>  	ELFNOTE(Xen, XEN_ELFNOTE_L1_MFN_VALID,

Considering that the PVH capability ends up in an ELF note, the kconfig
symbol is actually useful at least for debugging: it is the only way to
disable it from the guest side. However I would imaging that Xen would
always provide an option to disable PVH features in a VM or dom0.


> diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
> index d8e33a9..425911f 100644
> --- a/include/xen/interface/memory.h
> +++ b/include/xen/interface/memory.h
> @@ -169,7 +169,13 @@ struct xen_add_to_physmap {
>      /* Source mapping space. */
>  #define XENMAPSPACE_shared_info 0 /* shared info page */
>  #define XENMAPSPACE_grant_table 1 /* grant table page */
> -    unsigned int space;
> +#define XENMAPSPACE_gmfn        2 /* GMFN */
> +#define XENMAPSPACE_gmfn_range  3 /* GMFN range */
> +#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */
> +    uint16_t space;
> +    domid_t foreign_domid;         /* IFF XENMAPSPACE_gmfn_foreign */
> +
> +#define XENMAPIDX_grant_table_status 0x80000000
>  
>      /* Index into source mapping space. */
>      unsigned long idx;
> @@ -237,4 +243,20 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_memory_map);
>   * during a driver critical region.
>   */
>  extern spinlock_t xen_reservation_lock;
> +
> +/*
> + * Unmaps the page appearing at a particular GPFN from the specified guest's
> + * pseudophysical address space.
> + * arg == addr of xen_remove_from_physmap_t.
> + */
> +#define XENMEM_remove_from_physmap      15
> +struct xen_remove_from_physmap {
> +    /* Which domain to change the mapping for. */
> +    domid_t domid;
> +
> +    /* GPFN of the current mapping of the page. */
> +    xen_pfn_t gpfn;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_remove_from_physmap);
> +
>  #endif /* __XEN_PUBLIC_MEMORY_H__ */

these bits have been submitted separately by Ian, if I am not mistaken.


> diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
> index 9ce788d..3b9d5b6 100644
> --- a/include/xen/interface/physdev.h
> +++ b/include/xen/interface/physdev.h
> @@ -258,6 +258,16 @@ struct physdev_pci_device {
>      uint8_t devfn;
>  };
>  
> +#define PHYSDEVOP_pvh_map_iomem        30

I would just call this PHYSDEVOP_map_iomem, we might use it on non-PVH
guests as well one day.


> +struct physdev_map_iomem {
> +    /* IN */
> +    uint64_t first_gfn;
> +    uint64_t first_mfn;
> +    uint32_t nr_mfns;
> +    uint32_t add_mapping;        /* 1 == add mapping;  0 == unmap */
> +
> +};
> +
>  /*
>   * Notify that some PIRQ-bound event channels have been unmasked.
>   * ** This command is obsolete since interface version 0x00030202 and is **
> -- 
> 1.7.2.3
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 11:22:39 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 11:22:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOoBB-0003YS-6g; Thu, 18 Oct 2012 11:22:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOoB9-0003YN-GO
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 11:22:20 +0000
Received: from [85.158.137.99:42845] by server-2.bemta-3.messagelabs.com id
	89/9E-00604-A66EF705; Thu, 18 Oct 2012 11:22:18 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1350559337!18929622!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12607 invoked from network); 18 Oct 2012 11:22:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 11:22:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15252244"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 11:22:17 +0000
Received: from mac.citrite.net (10.31.3.234) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 12:22:17 +0100
From: Roger Pau Monne 
To: 
Date: Thu, 18 Oct 2012 13:22:01 +0200
Message-ID: <1350559321-19066-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
MIME-Version: 1.0
Cc: Oliver Chick , konrad.wilk@oracle.com,
	linux-kernel@vger.kernel.org, Roger Pau Monne 
Subject: [Xen-devel] [PATCH RFC] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch implements persistent grants for the xen-blk{front,back}
mechanism. The effect of this change is to reduce the number of unmap
operations performed, since they cause a (costly) TLB shootdown. This
allows the I/O performance to scale better when a large number of VMs
are performing I/O.

Previously, the blkfront driver was supplied a bvec[] from the request
queue. This was granted to dom0; dom0 performed the I/O and wrote
directly into the grant-mapped memory and unmapped it; blkfront then
removed foreign access for that grant. The cost of unmapping scales
badly with the number of CPUs in Dom0. An experiment showed that when
Dom0 has 24 VCPUs, and guests are performing parallel I/O to a
ramdisk, the IPIs from performing unmap's is a bottleneck at 5 guests
(at which point 650,000 IOPS are being performed in total). If more
than 5 guests are used, the performance declines. By 10 guests, only
400,000 IOPS are being performed.

This patch improves performance by only unmapping when the connection
between blkfront and back is broken.

On startup blkfront notifies blkback that it is using persistent
grants, and blkback will do the same. If blkback is not capable of
persistent mapping, blkfront will still use the same grants, since it
is compatible with the previous protocol, and simplifies the code
complexity in blkfront.

To perform a read, in persistent mode, blkfront uses a separate pool
of pages that it maps to dom0. When a request comes in, blkfront
transmutes the request so that blkback will write into one of these
free pages. Blkback keeps note of which grefs it has already
mapped. When a new ring request comes to blkback, it looks to see if
it has already mapped that page. If so, it will not map it again. If
the page hasn't been previously mapped, it is mapped now, and a record
is kept of this mapping. Blkback proceeds as usual. When blkfront is
notified that blkback has completed a request, it memcpy's from the
shared memory, into the bvec supplied. A record that the {gref, page}
tuple is mapped, and not inflight is kept.

Writes are similar, except that the memcpy is peformed from the
supplied bvecs, into the shared pages, before the request is put onto
the ring.

Blkback stores a mapping of grefs=>{page mapped to by gref} in
a red-black tree. As the grefs are not known apriori, and provide no
guarantees on their ordering, we have to perform a search
through this tree to find the page, for every gref we receive. This
operation takes O(log n) time in the worst case.

The maximum number of grants that blkback will persistenly map is
currently set to RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, to
prevent a malicios guest from attempting a DoS, by supplying fresh
grefs, causing the Dom0 kernel to map excessively. If a guest
is using persistent grants and exceeds the maximum number of grants to
map persistenly the newly passed grefs will be mapped and unmaped.
Using this approach, we can have requests that mix persistent and
non-persistent grants, and we need to handle them correctly.
This allows us to set the maximum number of persistent grants to a
lower value than RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, although
setting it will lead to unpredictable performance.

In writing this patch, the question arrises as to if the additional
cost of performing memcpys in the guest (to/from the pool of granted
pages) outweigh the gains of not performing TLB shootdowns. The answer
to that question is `no'. There appears to be very little, if any
additional cost to the guest of using persistent grants. There is
perhaps a small saving, from the reduced number of hypercalls
performed in granting, and ending foreign access.

Signed-off-by: Oliver Chick 
Signed-off-by: Roger Pau Monne 
Cc: 
Cc: 
---
Benchmarks showing the impact of this patch in blk performance can be
found at:

http://xenbits.xensource.com/people/royger/persistent_grants/
---
 drivers/block/xen-blkback/blkback.c |  279 +++++++++++++++++++++++++++++++---
 drivers/block/xen-blkback/common.h  |   17 ++
 drivers/block/xen-blkback/xenbus.c  |   16 ++-
 drivers/block/xen-blkfront.c        |  183 ++++++++++++++++++++----
 4 files changed, 442 insertions(+), 53 deletions(-)

diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
index c6decb9..2b982b2 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -78,6 +78,7 @@ struct pending_req {
 	unsigned short		operation;
 	int			status;
 	struct list_head	free_list;
+	unsigned int		unmap_seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 };
 
 #define BLKBACK_INVALID_HANDLE (~0)
@@ -98,6 +99,30 @@ struct xen_blkbk {
 static struct xen_blkbk *blkbk;
 
 /*
+ * Maximum number of grant pages that can be mapped in blkback.
+ * BLKIF_MAX_SEGMENTS_PER_REQUEST * RING_SIZE is the maximum number of
+ * pages that blkback will persistently map.
+ */
+static inline unsigned int max_mapped_grant_pages(enum blkif_protocol protocol)
+{
+	switch (protocol) {
+	case BLKIF_PROTOCOL_NATIVE:
+		return __CONST_RING_SIZE(blkif, PAGE_SIZE) *
+			   BLKIF_MAX_SEGMENTS_PER_REQUEST;
+	case BLKIF_PROTOCOL_X86_32:
+		return __CONST_RING_SIZE(blkif_x86_32, PAGE_SIZE) *
+			   BLKIF_MAX_SEGMENTS_PER_REQUEST;
+	case BLKIF_PROTOCOL_X86_64:
+		return __CONST_RING_SIZE(blkif_x86_64, PAGE_SIZE) *
+			   BLKIF_MAX_SEGMENTS_PER_REQUEST;
+	default:
+		BUG();
+	}
+	return 0;
+}
+
+
+/*
  * Little helpful macro to figure out the index and virtual address of the
  * pending_pages[..]. For each 'pending_req' we have have up to
  * BLKIF_MAX_SEGMENTS_PER_REQUEST (11) pages. The seg would be from 0 through
@@ -128,6 +153,57 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 static void make_response(struct xen_blkif *blkif, u64 id,
 			  unsigned short op, int st);
 
+#define foreach_grant(pos, rbtree, node) \
+	for ((pos) = container_of(rb_first((rbtree)), typeof(*(pos)), node); \
+	     &(pos)->node != NULL; \
+	     (pos) = container_of(rb_next(&(pos)->node), typeof(*(pos)), node))
+
+
+static void add_persistent_gnt(struct rb_root *root,
+			       struct persistent_gnt *persistent_gnt)
+{
+	struct rb_node **new = &(root->rb_node), *parent = NULL;
+	struct persistent_gnt *this;
+
+	/* Figure out where to put new node */
+	while (*new) {
+		this = container_of(*new, struct persistent_gnt, node);
+
+		parent = *new;
+		if (persistent_gnt->gnt < this->gnt)
+			new = &((*new)->rb_left);
+		else if (persistent_gnt->gnt > this->gnt)
+			new = &((*new)->rb_right);
+		else {
+			pr_alert(DRV_PFX " trying to add a gref that's already in the tree\n");
+			BUG();
+		}
+	}
+
+	/* Add new node and rebalance tree. */
+	rb_link_node(&(persistent_gnt->node), parent, new);
+	rb_insert_color(&(persistent_gnt->node), root);
+}
+
+static struct persistent_gnt *get_persistent_gnt(struct rb_root *root,
+						 grant_ref_t gref)
+{
+	struct persistent_gnt *data;
+	struct rb_node *node = root->rb_node;
+
+	while (node) {
+		data = container_of(node, struct persistent_gnt, node);
+
+		if (gref < data->gnt)
+			node = node->rb_left;
+		else if (gref > data->gnt)
+			node = node->rb_right;
+		else
+			return data;
+	}
+	return NULL;
+}
+
 /*
  * Retrieve from the 'pending_reqs' a free pending_req structure to be used.
  */
@@ -274,6 +350,11 @@ int xen_blkif_schedule(void *arg)
 {
 	struct xen_blkif *blkif = arg;
 	struct xen_vbd *vbd = &blkif->vbd;
+	struct gnttab_unmap_grant_ref unmap[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct persistent_gnt *persistent_gnt;
+	int ret = 0;
+	int segs_to_unmap = 0;
 
 	xen_blkif_get(blkif);
 
@@ -301,6 +382,32 @@ int xen_blkif_schedule(void *arg)
 			print_stats(blkif);
 	}
 
+	/* Free all persistent grant pages */
+	foreach_grant(persistent_gnt, &blkif->persistent_gnts, node) {
+		BUG_ON(persistent_gnt->handle == BLKBACK_INVALID_HANDLE);
+		gnttab_set_unmap_op(&unmap[segs_to_unmap],
+		    (unsigned long) pfn_to_kaddr(page_to_pfn(
+			persistent_gnt->page)),
+		    GNTMAP_host_map,
+		    persistent_gnt->handle);
+
+		pages[segs_to_unmap] = persistent_gnt->page;
+		rb_erase(&persistent_gnt->node, &blkif->persistent_gnts);
+		kfree(persistent_gnt);
+		blkif->persistent_gnt_c--;
+
+		if (++segs_to_unmap == BLKIF_MAX_SEGMENTS_PER_REQUEST ||
+			!rb_next(&persistent_gnt->node)) {
+			ret = gnttab_unmap_refs(unmap, NULL, pages,
+						segs_to_unmap);
+			BUG_ON(ret);
+			segs_to_unmap = 0;
+		}
+	}
+
+	BUG_ON(blkif->persistent_gnt_c != 0);
+	BUG_ON(!RB_EMPTY_ROOT(&blkif->persistent_gnts));
+
 	if (log_stats)
 		print_stats(blkif);
 
@@ -327,6 +434,8 @@ static void xen_blkbk_unmap(struct pending_req *req)
 	int ret;
 
 	for (i = 0; i < req->nr_pages; i++) {
+		if (!req->unmap_seg[i])
+			continue;
 		handle = pending_handle(req, i);
 		if (handle == BLKBACK_INVALID_HANDLE)
 			continue;
@@ -343,12 +452,26 @@ static void xen_blkbk_unmap(struct pending_req *req)
 
 static int xen_blkbk_map(struct blkif_request *req,
 			 struct pending_req *pending_req,
-			 struct seg_buf seg[])
+			 struct seg_buf seg[],
+			 struct page *pages[])
 {
 	struct gnttab_map_grant_ref map[BLKIF_MAX_SEGMENTS_PER_REQUEST];
-	int i;
+	struct persistent_gnt *persistent_gnts[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct page *pages_to_gnt[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct persistent_gnt *persistent_gnt = NULL;
+	struct xen_blkif *blkif = pending_req->blkif;
+	phys_addr_t addr = 0;
+	int i, j;
+	int new_map;
 	int nseg = req->u.rw.nr_segments;
+	int segs_to_map = 0;
 	int ret = 0;
+	int use_persistent_gnts;
+
+	use_persistent_gnts = (blkif->vbd.feature_gnt_persistent);
+
+	BUG_ON(blkif->persistent_gnt_c >
+		   max_mapped_grant_pages(pending_req->blkif->blk_protocol));
 
 	/*
 	 * Fill out preq.nr_sects with proper amount of sectors, and setup
@@ -358,36 +481,141 @@ static int xen_blkbk_map(struct blkif_request *req,
 	for (i = 0; i < nseg; i++) {
 		uint32_t flags;
 
-		flags = GNTMAP_host_map;
-		if (pending_req->operation != BLKIF_OP_READ)
-			flags |= GNTMAP_readonly;
-		gnttab_set_map_op(&map[i], vaddr(pending_req, i), flags,
-				  req->u.rw.seg[i].gref,
-				  pending_req->blkif->domid);
+		if (use_persistent_gnts)
+			persistent_gnt = get_persistent_gnt(
+				&blkif->persistent_gnts,
+				req->u.rw.seg[i].gref);
+
+		if (persistent_gnt) {
+			/*
+			 * We are using persistent grants and
+			 * the grant is already mapped
+			 */
+			new_map = 0;
+		} else if (use_persistent_gnts &&
+			   blkif->persistent_gnt_c <
+			   max_mapped_grant_pages(blkif->blk_protocol)) {
+			/*
+			 * We are using persistent grants, the grant is
+			 * not mapped but we have room for it
+			 */
+			new_map = 1;
+			persistent_gnt = kzalloc(
+				sizeof(struct persistent_gnt),
+				GFP_KERNEL);
+			if (!persistent_gnt)
+				return -ENOMEM;
+			persistent_gnt->page = alloc_page(GFP_KERNEL);
+			if (!persistent_gnt->page) {
+				kfree(persistent_gnt);
+				return -ENOMEM;
+			}
+			persistent_gnt->gnt = req->u.rw.seg[i].gref;
+
+			pages_to_gnt[segs_to_map] =
+				persistent_gnt->page;
+			addr = (unsigned long) pfn_to_kaddr(
+				page_to_pfn(persistent_gnt->page));
+
+			add_persistent_gnt(&blkif->persistent_gnts,
+				persistent_gnt);
+			blkif->persistent_gnt_c++;
+			pr_debug(DRV_PFX " grant %u added to the tree of persistent grants, using %u/%u\n",
+				 persistent_gnt->gnt, blkif->persistent_gnt_c,
+				 max_mapped_grant_pages(blkif->blk_protocol));
+		} else {
+			/*
+			 * We are either using persistent grants and
+			 * hit the maximum limit of grants mapped,
+			 * or we are not using persistent grants.
+			 */
+			if (use_persistent_gnts &&
+				!blkif->vbd.overflow_max_grants) {
+				blkif->vbd.overflow_max_grants = 1;
+				pr_alert(DRV_PFX " domain %u, device %#x is using maximum number of persistent grants\n",
+					 blkif->domid, blkif->vbd.handle);
+			}
+			new_map = 1;
+			pages[i] = blkbk->pending_page(pending_req, i);
+			addr = vaddr(pending_req, i);
+			pages_to_gnt[segs_to_map] =
+				blkbk->pending_page(pending_req, i);
+		}
+
+		if (persistent_gnt) {
+			pages[i] = persistent_gnt->page;
+			persistent_gnts[i] = persistent_gnt;
+		} else {
+			persistent_gnts[i] = NULL;
+		}
+
+		if (new_map) {
+			flags = GNTMAP_host_map;
+			if (!persistent_gnt &&
+			    (pending_req->operation != BLKIF_OP_READ))
+				flags |= GNTMAP_readonly;
+			gnttab_set_map_op(&map[segs_to_map++], addr,
+					  flags, req->u.rw.seg[i].gref,
+					  blkif->domid);
+		}
 	}
 
-	ret = gnttab_map_refs(map, NULL, &blkbk->pending_page(pending_req, 0), nseg);
-	BUG_ON(ret);
+	if (segs_to_map) {
+		ret = gnttab_map_refs(map, NULL, pages_to_gnt, segs_to_map);
+		BUG_ON(ret);
+	}
 
 	/*
 	 * Now swizzle the MFN in our domain with the MFN from the other domain
 	 * so that when we access vaddr(pending_req,i) it has the contents of
 	 * the page from the other domain.
 	 */
-	for (i = 0; i < nseg; i++) {
-		if (unlikely(map[i].status != 0)) {
-			pr_debug(DRV_PFX "invalid buffer -- could not remap it\n");
-			map[i].handle = BLKBACK_INVALID_HANDLE;
-			ret |= 1;
+	for (i = 0, j = 0; i < nseg; i++) {
+		if (!persistent_gnts[i] || !persistent_gnts[i]->handle) {
+			/* This is a newly mapped grant */
+			BUG_ON(j >= segs_to_map);
+			if (unlikely(map[j].status != 0)) {
+				pr_debug(DRV_PFX "invalid buffer -- could not remap it\n");
+				map[j].handle = BLKBACK_INVALID_HANDLE;
+				ret |= 1;
+				if (persistent_gnts[i]) {
+					rb_erase(&persistent_gnts[i]->node,
+						 &blkif->persistent_gnts);
+					blkif->persistent_gnt_c--;
+					kfree(persistent_gnts[i]);
+					persistent_gnts[i] = NULL;
+				}
+			}
+		}
+		if (persistent_gnts[i]) {
+			if (!persistent_gnts[i]->handle) {
+				/*
+				 * If this is a new persistent grant
+				 * save the handler
+				 */
+				persistent_gnts[i]->handle = map[j].handle;
+				persistent_gnts[i]->dev_bus_addr =
+					map[j++].dev_bus_addr;
+			}
+			pending_handle(pending_req, i) =
+				persistent_gnts[i]->handle;
+			pending_req->unmap_seg[i] = 0;
+
+			if (ret)
+				continue;
+
+			seg[i].buf = persistent_gnts[i]->dev_bus_addr |
+				(req->u.rw.seg[i].first_sect << 9);
+		} else {
+			pending_handle(pending_req, i) = map[j].handle;
+			pending_req->unmap_seg[i] = 1;
+
+			if (ret)
+				continue;
+
+			seg[i].buf = map[j++].dev_bus_addr |
+				(req->u.rw.seg[i].first_sect << 9);
 		}
-
-		pending_handle(pending_req, i) = map[i].handle;
-
-		if (ret)
-			continue;
-
-		seg[i].buf  = map[i].dev_bus_addr |
-			(req->u.rw.seg[i].first_sect << 9);
 	}
 	return ret;
 }
@@ -590,6 +818,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 	int operation;
 	struct blk_plug plug;
 	bool drain = false;
+	struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 
 	switch (req->operation) {
 	case BLKIF_OP_READ:
@@ -676,7 +905,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 	 * the hypercall to unmap the grants - that is all done in
 	 * xen_blkbk_unmap.
 	 */
-	if (xen_blkbk_map(req, pending_req, seg))
+	if (xen_blkbk_map(req, pending_req, seg, pages))
 		goto fail_flush;
 
 	/*
@@ -688,7 +917,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 	for (i = 0; i < nseg; i++) {
 		while ((bio == NULL) ||
 		       (bio_add_page(bio,
-				     blkbk->pending_page(pending_req, i),
+				     pages[i],
 				     seg[i].nsec << 9,
 				     seg[i].buf & ~PAGE_MASK) == 0)) {
 
diff --git a/drivers/block/xen-blkback/common.h b/drivers/block/xen-blkback/common.h
index 9ad3b5e..6c08ee9 100644
--- a/drivers/block/xen-blkback/common.h
+++ b/drivers/block/xen-blkback/common.h
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -160,10 +161,22 @@ struct xen_vbd {
 	sector_t		size;
 	bool			flush_support;
 	bool			discard_secure;
+
+	unsigned int		feature_gnt_persistent:1;
+	unsigned int		overflow_max_grants:1;
 };
 
 struct backend_info;
 
+
+struct persistent_gnt {
+	struct page *page;
+	grant_ref_t gnt;
+	grant_handle_t handle;
+	uint64_t dev_bus_addr;
+	struct rb_node node;
+};
+
 struct xen_blkif {
 	/* Unique identifier for this interface. */
 	domid_t			domid;
@@ -190,6 +203,10 @@ struct xen_blkif {
 	struct task_struct	*xenblkd;
 	unsigned int		waiting_reqs;
 
+	/* frontend feature information */
+	struct rb_root		persistent_gnts;
+	unsigned int		persistent_gnt_c;
+
 	/* statistics */
 	unsigned long		st_print;
 	int			st_rd_req;
diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c
index 4f66171..9f88b4e 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -118,6 +118,7 @@ static struct xen_blkif *xen_blkif_alloc(domid_t domid)
 	atomic_set(&blkif->drain, 0);
 	blkif->st_print = jiffies;
 	init_waitqueue_head(&blkif->waiting_to_free);
+	blkif->persistent_gnts.rb_node = NULL;
 
 	return blkif;
 }
@@ -721,6 +722,7 @@ static int connect_ring(struct backend_info *be)
 	struct xenbus_device *dev = be->dev;
 	unsigned long ring_ref;
 	unsigned int evtchn;
+	unsigned int pers_grants;
 	char protocol[64] = "";
 	int err;
 
@@ -750,8 +752,18 @@ static int connect_ring(struct backend_info *be)
 		xenbus_dev_fatal(dev, err, "unknown fe protocol %s", protocol);
 		return -1;
 	}
-	pr_info(DRV_PFX "ring-ref %ld, event-channel %d, protocol %d (%s)\n",
-		ring_ref, evtchn, be->blkif->blk_protocol, protocol);
+	err = xenbus_gather(XBT_NIL, dev->otherend,
+			    "feature-persistent-grants", "%u",
+			    &pers_grants, NULL);
+	if (err)
+		pers_grants = 0;
+
+	be->blkif->vbd.feature_gnt_persistent = pers_grants;
+	be->blkif->vbd.overflow_max_grants = 0;
+
+	pr_info(DRV_PFX "ring-ref %ld, event-channel %d, protocol %d (%s) persistent %d\n",
+		ring_ref, evtchn, be->blkif->blk_protocol, protocol,
+		pers_grants);
 
 	/* Map the shared frame, irq etc. */
 	err = xen_blkif_map(be->blkif, ring_ref, evtchn);
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 2c2d2e5..206d422 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -44,6 +44,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -64,10 +65,17 @@ enum blkif_state {
 	BLKIF_STATE_SUSPENDED,
 };
 
+struct grant {
+	grant_ref_t gref;
+	unsigned long pfn;
+	struct llist_node node;
+};
+
 struct blk_shadow {
 	struct blkif_request req;
 	struct request *request;
 	unsigned long frame[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct grant *grants_used[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 };
 
 static DEFINE_MUTEX(blkfront_mutex);
@@ -97,6 +105,8 @@ struct blkfront_info
 	struct work_struct work;
 	struct gnttab_free_callback callback;
 	struct blk_shadow shadow[BLK_RING_SIZE];
+	struct llist_head persistent_gnts;
+	unsigned int persistent_gnts_c;
 	unsigned long shadow_free;
 	unsigned int feature_flush;
 	unsigned int flush_op;
@@ -287,21 +297,36 @@ static int blkif_queue_request(struct request *req)
 	unsigned long id;
 	unsigned int fsect, lsect;
 	int i, ref;
+
+	/*
+	 * Used to store if we are able to queue the request by just using
+	 * existing persistent grants (0), or if we have to get new grants,
+	 * as there are not sufficiently many free.
+	 */
+	int new_persistent_gnts;
 	grant_ref_t gref_head;
+	struct page *granted_page;
+	struct grant *gnt_list_entry = NULL;
 	struct scatterlist *sg;
 
 	if (unlikely(info->connected != BLKIF_STATE_CONNECTED))
 		return 1;
 
-	if (gnttab_alloc_grant_references(
-		BLKIF_MAX_SEGMENTS_PER_REQUEST, &gref_head) < 0) {
-		gnttab_request_free_callback(
-			&info->callback,
-			blkif_restart_queue_callback,
-			info,
-			BLKIF_MAX_SEGMENTS_PER_REQUEST);
-		return 1;
-	}
+	/* Check if we have enought grants to allocate a requests */
+	if (info->persistent_gnts_c < BLKIF_MAX_SEGMENTS_PER_REQUEST) {
+		new_persistent_gnts = 1;
+		if (gnttab_alloc_grant_references(
+		    BLKIF_MAX_SEGMENTS_PER_REQUEST - info->persistent_gnts_c,
+		    &gref_head) < 0) {
+			gnttab_request_free_callback(
+				&info->callback,
+				blkif_restart_queue_callback,
+				info,
+				BLKIF_MAX_SEGMENTS_PER_REQUEST);
+			return 1;
+		}
+	} else
+		new_persistent_gnts = 0;
 
 	/* Fill out a communications ring structure. */
 	ring_req = RING_GET_REQUEST(&info->ring, info->ring.req_prod_pvt);
@@ -341,18 +366,73 @@ static int blkif_queue_request(struct request *req)
 		       BLKIF_MAX_SEGMENTS_PER_REQUEST);
 
 		for_each_sg(info->sg, sg, ring_req->u.rw.nr_segments, i) {
-			buffer_mfn = pfn_to_mfn(page_to_pfn(sg_page(sg)));
 			fsect = sg->offset >> 9;
 			lsect = fsect + (sg->length >> 9) - 1;
-			/* install a grant reference. */
-			ref = gnttab_claim_grant_reference(&gref_head);
-			BUG_ON(ref == -ENOSPC);
 
-			gnttab_grant_foreign_access_ref(
-					ref,
+			if (info->persistent_gnts_c) {
+				BUG_ON(llist_empty(&info->persistent_gnts));
+				gnt_list_entry = llist_entry(
+					llist_del_first(&info->persistent_gnts),
+					struct grant, node);
+
+				ref = gnt_list_entry->gref;
+				buffer_mfn = pfn_to_mfn(gnt_list_entry->pfn);
+				info->persistent_gnts_c--;
+			} else {
+				ref = gnttab_claim_grant_reference(&gref_head);
+				BUG_ON(ref == -ENOSPC);
+
+				gnt_list_entry =
+					kmalloc(sizeof(struct grant),
+							 GFP_ATOMIC);
+				if (!gnt_list_entry)
+					return -ENOMEM;
+
+				granted_page = alloc_page(GFP_ATOMIC);
+				if (!granted_page) {
+					kfree(gnt_list_entry);
+					return -ENOMEM;
+				}
+
+				gnt_list_entry->pfn =
+					page_to_pfn(granted_page);
+				gnt_list_entry->gref = ref;
+
+				buffer_mfn = pfn_to_mfn(page_to_pfn(
+								granted_page));
+				gnttab_grant_foreign_access_ref(ref,
 					info->xbdev->otherend_id,
-					buffer_mfn,
-					rq_data_dir(req));
+					buffer_mfn, 0);
+			}
+
+			info->shadow[id].grants_used[i] = gnt_list_entry;
+
+			if (rq_data_dir(req)) {
+				char *bvec_data;
+				void *shared_data;
+
+				BUG_ON(sg->offset + sg->length > PAGE_SIZE);
+
+				shared_data = kmap_atomic(
+					pfn_to_page(gnt_list_entry->pfn));
+				bvec_data = kmap_atomic(sg_page(sg));
+
+				/*
+				 * this does not wipe data stored outside the
+				 * range sg->offset..sg->offset+sg->length.
+				 * Therefore, blkback *could* see data from
+				 * previous requests. This is OK as long as
+				 * persistent grants are shared with just one
+				 * domain. It may need refactoring if This
+				 * changes
+				 */
+				memcpy(shared_data + sg->offset,
+				       bvec_data   + sg->offset,
+				       sg->length);
+
+				kunmap_atomic(bvec_data);
+				kunmap_atomic(shared_data);
+			}
 
 			info->shadow[id].frame[i] = mfn_to_pfn(buffer_mfn);
 			ring_req->u.rw.seg[i] =
@@ -368,7 +448,8 @@ static int blkif_queue_request(struct request *req)
 	/* Keep a private copy so we can reissue requests when recovering. */
 	info->shadow[id].req = *ring_req;
 
-	gnttab_free_grant_references(gref_head);
+	if (new_persistent_gnts)
+		gnttab_free_grant_references(gref_head);
 
 	return 0;
 }
@@ -480,7 +561,7 @@ static int xlvbd_init_blk_queue(struct gendisk *gd, u16 sector_size)
 static void xlvbd_flush(struct blkfront_info *info)
 {
 	blk_queue_flush(info->rq, info->feature_flush);
-	printk(KERN_INFO "blkfront: %s: %s: %s\n",
+	printk(KERN_INFO "blkfront: %s: %s: %s, using persistent grants\n",
 	       info->gd->disk_name,
 	       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
 		"barrier" : (info->flush_op == BLKIF_OP_FLUSH_DISKCACHE ?
@@ -707,6 +788,9 @@ static void blkif_restart_queue(struct work_struct *work)
 
 static void blkif_free(struct blkfront_info *info, int suspend)
 {
+	struct llist_node *all_gnts;
+	struct grant *persistent_gnt;
+
 	/* Prevent new requests being issued until we fix things up. */
 	spin_lock_irq(&info->io_lock);
 	info->connected = suspend ?
@@ -714,6 +798,17 @@ static void blkif_free(struct blkfront_info *info, int suspend)
 	/* No more blkif_request(). */
 	if (info->rq)
 		blk_stop_queue(info->rq);
+
+	/* Remove all persistent grants */
+	if (info->persistent_gnts_c) {
+		all_gnts = llist_del_all(&info->persistent_gnts);
+		llist_for_each_entry(persistent_gnt, all_gnts, node) {
+			gnttab_end_foreign_access(persistent_gnt->gref, 0, 0UL);
+			kfree(persistent_gnt);
+		}
+		info->persistent_gnts_c = 0;
+	}
+
 	/* No more gnttab callback work. */
 	gnttab_cancel_free_callback(&info->callback);
 	spin_unlock_irq(&info->io_lock);
@@ -734,13 +829,42 @@ static void blkif_free(struct blkfront_info *info, int suspend)
 
 }
 
-static void blkif_completion(struct blk_shadow *s)
+static void blkif_completion(struct blk_shadow *s, struct blkfront_info *info,
+			     struct blkif_response *bret)
 {
 	int i;
-	/* Do not let BLKIF_OP_DISCARD as nr_segment is in the same place
-	 * flag. */
-	for (i = 0; i < s->req.u.rw.nr_segments; i++)
-		gnttab_end_foreign_access(s->req.u.rw.seg[i].gref, 0, 0UL);
+	struct bio_vec *bvec;
+	struct req_iterator iter;
+	unsigned long flags;
+	char *bvec_data;
+	void *shared_data;
+	unsigned int offset = 0;
+
+	if (bret->operation == BLKIF_OP_READ) {
+		/*
+		 * Copy the data received from the backend into the bvec.
+		 * Since bv_len can be different from PAGE_SIZE, we need to
+		 * be sure we are actually copying the data from the right
+		 * shared page.
+		 */
+		rq_for_each_segment(bvec, s->request, iter) {
+			BUG_ON((bvec->bv_offset + bvec->bv_len) > PAGE_SIZE);
+			i = offset >> PAGE_SHIFT;
+			shared_data = kmap_atomic(
+				pfn_to_page(s->grants_used[i]->pfn));
+			bvec_data = bvec_kmap_irq(bvec, &flags);
+			memcpy(bvec_data, shared_data + bvec->bv_offset,
+				bvec->bv_len);
+			bvec_kunmap_irq(bvec_data, &flags);
+			kunmap_atomic(shared_data);
+			offset += bvec->bv_len;
+		}
+	}
+	/* Add the persistent grant into the list of free grants */
+	for (i = 0; i < s->req.u.rw.nr_segments; i++) {
+		llist_add(&s->grants_used[i]->node, &info->persistent_gnts);
+		info->persistent_gnts_c++;
+	}
 }
 
 static irqreturn_t blkif_interrupt(int irq, void *dev_id)
@@ -783,7 +907,7 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
 		req  = info->shadow[id].request;
 
 		if (bret->operation != BLKIF_OP_DISCARD)
-			blkif_completion(&info->shadow[id]);
+			blkif_completion(&info->shadow[id], info, bret);
 
 		if (add_id_to_freelist(info, id)) {
 			WARN(1, "%s: response to %s (id %ld) couldn't be recycled!\n",
@@ -942,6 +1066,11 @@ again:
 		message = "writing protocol";
 		goto abort_transaction;
 	}
+	err = xenbus_printf(xbt, dev->nodename,
+			    "feature-persistent-grants", "%d", 1);
+	if (err)
+		dev_warn(&dev->dev,
+			 "writing persistent grants feature to xenbus");
 
 	err = xenbus_transaction_end(xbt, 0);
 	if (err) {
@@ -1029,6 +1158,8 @@ static int blkfront_probe(struct xenbus_device *dev,
 	spin_lock_init(&info->io_lock);
 	info->xbdev = dev;
 	info->vdevice = vdevice;
+	init_llist_head(&info->persistent_gnts);
+	info->persistent_gnts_c = 0;
 	info->connected = BLKIF_STATE_DISCONNECTED;
 	INIT_WORK(&info->work, blkif_restart_queue);
 
@@ -1093,7 +1224,7 @@ static int blkif_recover(struct blkfront_info *info)
 					req->u.rw.seg[j].gref,
 					info->xbdev->otherend_id,
 					pfn_to_mfn(info->shadow[req->u.rw.id].frame[j]),
-					rq_data_dir(info->shadow[req->u.rw.id].request));
+					0);
 		}
 		info->shadow[req->u.rw.id].req = *req;
 
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 11:22:39 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 11:22:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOoBB-0003YS-6g; Thu, 18 Oct 2012 11:22:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOoB9-0003YN-GO
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 11:22:20 +0000
Received: from [85.158.137.99:42845] by server-2.bemta-3.messagelabs.com id
	89/9E-00604-A66EF705; Thu, 18 Oct 2012 11:22:18 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1350559337!18929622!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12607 invoked from network); 18 Oct 2012 11:22:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 11:22:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15252244"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 11:22:17 +0000
Received: from mac.citrite.net (10.31.3.234) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 12:22:17 +0100
From: Roger Pau Monne 
To: 
Date: Thu, 18 Oct 2012 13:22:01 +0200
Message-ID: <1350559321-19066-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
MIME-Version: 1.0
Cc: Oliver Chick , konrad.wilk@oracle.com,
	linux-kernel@vger.kernel.org, Roger Pau Monne 
Subject: [Xen-devel] [PATCH RFC] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch implements persistent grants for the xen-blk{front,back}
mechanism. The effect of this change is to reduce the number of unmap
operations performed, since they cause a (costly) TLB shootdown. This
allows the I/O performance to scale better when a large number of VMs
are performing I/O.

Previously, the blkfront driver was supplied a bvec[] from the request
queue. This was granted to dom0; dom0 performed the I/O and wrote
directly into the grant-mapped memory and unmapped it; blkfront then
removed foreign access for that grant. The cost of unmapping scales
badly with the number of CPUs in Dom0. An experiment showed that when
Dom0 has 24 VCPUs, and guests are performing parallel I/O to a
ramdisk, the IPIs from performing unmap's is a bottleneck at 5 guests
(at which point 650,000 IOPS are being performed in total). If more
than 5 guests are used, the performance declines. By 10 guests, only
400,000 IOPS are being performed.

This patch improves performance by only unmapping when the connection
between blkfront and back is broken.

On startup blkfront notifies blkback that it is using persistent
grants, and blkback will do the same. If blkback is not capable of
persistent mapping, blkfront will still use the same grants, since it
is compatible with the previous protocol, and simplifies the code
complexity in blkfront.

To perform a read, in persistent mode, blkfront uses a separate pool
of pages that it maps to dom0. When a request comes in, blkfront
transmutes the request so that blkback will write into one of these
free pages. Blkback keeps note of which grefs it has already
mapped. When a new ring request comes to blkback, it looks to see if
it has already mapped that page. If so, it will not map it again. If
the page hasn't been previously mapped, it is mapped now, and a record
is kept of this mapping. Blkback proceeds as usual. When blkfront is
notified that blkback has completed a request, it memcpy's from the
shared memory, into the bvec supplied. A record that the {gref, page}
tuple is mapped, and not inflight is kept.

Writes are similar, except that the memcpy is peformed from the
supplied bvecs, into the shared pages, before the request is put onto
the ring.

Blkback stores a mapping of grefs=>{page mapped to by gref} in
a red-black tree. As the grefs are not known apriori, and provide no
guarantees on their ordering, we have to perform a search
through this tree to find the page, for every gref we receive. This
operation takes O(log n) time in the worst case.

The maximum number of grants that blkback will persistenly map is
currently set to RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, to
prevent a malicios guest from attempting a DoS, by supplying fresh
grefs, causing the Dom0 kernel to map excessively. If a guest
is using persistent grants and exceeds the maximum number of grants to
map persistenly the newly passed grefs will be mapped and unmaped.
Using this approach, we can have requests that mix persistent and
non-persistent grants, and we need to handle them correctly.
This allows us to set the maximum number of persistent grants to a
lower value than RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, although
setting it will lead to unpredictable performance.

In writing this patch, the question arrises as to if the additional
cost of performing memcpys in the guest (to/from the pool of granted
pages) outweigh the gains of not performing TLB shootdowns. The answer
to that question is `no'. There appears to be very little, if any
additional cost to the guest of using persistent grants. There is
perhaps a small saving, from the reduced number of hypercalls
performed in granting, and ending foreign access.

Signed-off-by: Oliver Chick 
Signed-off-by: Roger Pau Monne 
Cc: 
Cc: 
---
Benchmarks showing the impact of this patch in blk performance can be
found at:

http://xenbits.xensource.com/people/royger/persistent_grants/
---
 drivers/block/xen-blkback/blkback.c |  279 +++++++++++++++++++++++++++++++---
 drivers/block/xen-blkback/common.h  |   17 ++
 drivers/block/xen-blkback/xenbus.c  |   16 ++-
 drivers/block/xen-blkfront.c        |  183 ++++++++++++++++++++----
 4 files changed, 442 insertions(+), 53 deletions(-)

diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
index c6decb9..2b982b2 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -78,6 +78,7 @@ struct pending_req {
 	unsigned short		operation;
 	int			status;
 	struct list_head	free_list;
+	unsigned int		unmap_seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 };
 
 #define BLKBACK_INVALID_HANDLE (~0)
@@ -98,6 +99,30 @@ struct xen_blkbk {
 static struct xen_blkbk *blkbk;
 
 /*
+ * Maximum number of grant pages that can be mapped in blkback.
+ * BLKIF_MAX_SEGMENTS_PER_REQUEST * RING_SIZE is the maximum number of
+ * pages that blkback will persistently map.
+ */
+static inline unsigned int max_mapped_grant_pages(enum blkif_protocol protocol)
+{
+	switch (protocol) {
+	case BLKIF_PROTOCOL_NATIVE:
+		return __CONST_RING_SIZE(blkif, PAGE_SIZE) *
+			   BLKIF_MAX_SEGMENTS_PER_REQUEST;
+	case BLKIF_PROTOCOL_X86_32:
+		return __CONST_RING_SIZE(blkif_x86_32, PAGE_SIZE) *
+			   BLKIF_MAX_SEGMENTS_PER_REQUEST;
+	case BLKIF_PROTOCOL_X86_64:
+		return __CONST_RING_SIZE(blkif_x86_64, PAGE_SIZE) *
+			   BLKIF_MAX_SEGMENTS_PER_REQUEST;
+	default:
+		BUG();
+	}
+	return 0;
+}
+
+
+/*
  * Little helpful macro to figure out the index and virtual address of the
  * pending_pages[..]. For each 'pending_req' we have have up to
  * BLKIF_MAX_SEGMENTS_PER_REQUEST (11) pages. The seg would be from 0 through
@@ -128,6 +153,57 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 static void make_response(struct xen_blkif *blkif, u64 id,
 			  unsigned short op, int st);
 
+#define foreach_grant(pos, rbtree, node) \
+	for ((pos) = container_of(rb_first((rbtree)), typeof(*(pos)), node); \
+	     &(pos)->node != NULL; \
+	     (pos) = container_of(rb_next(&(pos)->node), typeof(*(pos)), node))
+
+
+static void add_persistent_gnt(struct rb_root *root,
+			       struct persistent_gnt *persistent_gnt)
+{
+	struct rb_node **new = &(root->rb_node), *parent = NULL;
+	struct persistent_gnt *this;
+
+	/* Figure out where to put new node */
+	while (*new) {
+		this = container_of(*new, struct persistent_gnt, node);
+
+		parent = *new;
+		if (persistent_gnt->gnt < this->gnt)
+			new = &((*new)->rb_left);
+		else if (persistent_gnt->gnt > this->gnt)
+			new = &((*new)->rb_right);
+		else {
+			pr_alert(DRV_PFX " trying to add a gref that's already in the tree\n");
+			BUG();
+		}
+	}
+
+	/* Add new node and rebalance tree. */
+	rb_link_node(&(persistent_gnt->node), parent, new);
+	rb_insert_color(&(persistent_gnt->node), root);
+}
+
+static struct persistent_gnt *get_persistent_gnt(struct rb_root *root,
+						 grant_ref_t gref)
+{
+	struct persistent_gnt *data;
+	struct rb_node *node = root->rb_node;
+
+	while (node) {
+		data = container_of(node, struct persistent_gnt, node);
+
+		if (gref < data->gnt)
+			node = node->rb_left;
+		else if (gref > data->gnt)
+			node = node->rb_right;
+		else
+			return data;
+	}
+	return NULL;
+}
+
 /*
  * Retrieve from the 'pending_reqs' a free pending_req structure to be used.
  */
@@ -274,6 +350,11 @@ int xen_blkif_schedule(void *arg)
 {
 	struct xen_blkif *blkif = arg;
 	struct xen_vbd *vbd = &blkif->vbd;
+	struct gnttab_unmap_grant_ref unmap[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct persistent_gnt *persistent_gnt;
+	int ret = 0;
+	int segs_to_unmap = 0;
 
 	xen_blkif_get(blkif);
 
@@ -301,6 +382,32 @@ int xen_blkif_schedule(void *arg)
 			print_stats(blkif);
 	}
 
+	/* Free all persistent grant pages */
+	foreach_grant(persistent_gnt, &blkif->persistent_gnts, node) {
+		BUG_ON(persistent_gnt->handle == BLKBACK_INVALID_HANDLE);
+		gnttab_set_unmap_op(&unmap[segs_to_unmap],
+		    (unsigned long) pfn_to_kaddr(page_to_pfn(
+			persistent_gnt->page)),
+		    GNTMAP_host_map,
+		    persistent_gnt->handle);
+
+		pages[segs_to_unmap] = persistent_gnt->page;
+		rb_erase(&persistent_gnt->node, &blkif->persistent_gnts);
+		kfree(persistent_gnt);
+		blkif->persistent_gnt_c--;
+
+		if (++segs_to_unmap == BLKIF_MAX_SEGMENTS_PER_REQUEST ||
+			!rb_next(&persistent_gnt->node)) {
+			ret = gnttab_unmap_refs(unmap, NULL, pages,
+						segs_to_unmap);
+			BUG_ON(ret);
+			segs_to_unmap = 0;
+		}
+	}
+
+	BUG_ON(blkif->persistent_gnt_c != 0);
+	BUG_ON(!RB_EMPTY_ROOT(&blkif->persistent_gnts));
+
 	if (log_stats)
 		print_stats(blkif);
 
@@ -327,6 +434,8 @@ static void xen_blkbk_unmap(struct pending_req *req)
 	int ret;
 
 	for (i = 0; i < req->nr_pages; i++) {
+		if (!req->unmap_seg[i])
+			continue;
 		handle = pending_handle(req, i);
 		if (handle == BLKBACK_INVALID_HANDLE)
 			continue;
@@ -343,12 +452,26 @@ static void xen_blkbk_unmap(struct pending_req *req)
 
 static int xen_blkbk_map(struct blkif_request *req,
 			 struct pending_req *pending_req,
-			 struct seg_buf seg[])
+			 struct seg_buf seg[],
+			 struct page *pages[])
 {
 	struct gnttab_map_grant_ref map[BLKIF_MAX_SEGMENTS_PER_REQUEST];
-	int i;
+	struct persistent_gnt *persistent_gnts[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct page *pages_to_gnt[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct persistent_gnt *persistent_gnt = NULL;
+	struct xen_blkif *blkif = pending_req->blkif;
+	phys_addr_t addr = 0;
+	int i, j;
+	int new_map;
 	int nseg = req->u.rw.nr_segments;
+	int segs_to_map = 0;
 	int ret = 0;
+	int use_persistent_gnts;
+
+	use_persistent_gnts = (blkif->vbd.feature_gnt_persistent);
+
+	BUG_ON(blkif->persistent_gnt_c >
+		   max_mapped_grant_pages(pending_req->blkif->blk_protocol));
 
 	/*
 	 * Fill out preq.nr_sects with proper amount of sectors, and setup
@@ -358,36 +481,141 @@ static int xen_blkbk_map(struct blkif_request *req,
 	for (i = 0; i < nseg; i++) {
 		uint32_t flags;
 
-		flags = GNTMAP_host_map;
-		if (pending_req->operation != BLKIF_OP_READ)
-			flags |= GNTMAP_readonly;
-		gnttab_set_map_op(&map[i], vaddr(pending_req, i), flags,
-				  req->u.rw.seg[i].gref,
-				  pending_req->blkif->domid);
+		if (use_persistent_gnts)
+			persistent_gnt = get_persistent_gnt(
+				&blkif->persistent_gnts,
+				req->u.rw.seg[i].gref);
+
+		if (persistent_gnt) {
+			/*
+			 * We are using persistent grants and
+			 * the grant is already mapped
+			 */
+			new_map = 0;
+		} else if (use_persistent_gnts &&
+			   blkif->persistent_gnt_c <
+			   max_mapped_grant_pages(blkif->blk_protocol)) {
+			/*
+			 * We are using persistent grants, the grant is
+			 * not mapped but we have room for it
+			 */
+			new_map = 1;
+			persistent_gnt = kzalloc(
+				sizeof(struct persistent_gnt),
+				GFP_KERNEL);
+			if (!persistent_gnt)
+				return -ENOMEM;
+			persistent_gnt->page = alloc_page(GFP_KERNEL);
+			if (!persistent_gnt->page) {
+				kfree(persistent_gnt);
+				return -ENOMEM;
+			}
+			persistent_gnt->gnt = req->u.rw.seg[i].gref;
+
+			pages_to_gnt[segs_to_map] =
+				persistent_gnt->page;
+			addr = (unsigned long) pfn_to_kaddr(
+				page_to_pfn(persistent_gnt->page));
+
+			add_persistent_gnt(&blkif->persistent_gnts,
+				persistent_gnt);
+			blkif->persistent_gnt_c++;
+			pr_debug(DRV_PFX " grant %u added to the tree of persistent grants, using %u/%u\n",
+				 persistent_gnt->gnt, blkif->persistent_gnt_c,
+				 max_mapped_grant_pages(blkif->blk_protocol));
+		} else {
+			/*
+			 * We are either using persistent grants and
+			 * hit the maximum limit of grants mapped,
+			 * or we are not using persistent grants.
+			 */
+			if (use_persistent_gnts &&
+				!blkif->vbd.overflow_max_grants) {
+				blkif->vbd.overflow_max_grants = 1;
+				pr_alert(DRV_PFX " domain %u, device %#x is using maximum number of persistent grants\n",
+					 blkif->domid, blkif->vbd.handle);
+			}
+			new_map = 1;
+			pages[i] = blkbk->pending_page(pending_req, i);
+			addr = vaddr(pending_req, i);
+			pages_to_gnt[segs_to_map] =
+				blkbk->pending_page(pending_req, i);
+		}
+
+		if (persistent_gnt) {
+			pages[i] = persistent_gnt->page;
+			persistent_gnts[i] = persistent_gnt;
+		} else {
+			persistent_gnts[i] = NULL;
+		}
+
+		if (new_map) {
+			flags = GNTMAP_host_map;
+			if (!persistent_gnt &&
+			    (pending_req->operation != BLKIF_OP_READ))
+				flags |= GNTMAP_readonly;
+			gnttab_set_map_op(&map[segs_to_map++], addr,
+					  flags, req->u.rw.seg[i].gref,
+					  blkif->domid);
+		}
 	}
 
-	ret = gnttab_map_refs(map, NULL, &blkbk->pending_page(pending_req, 0), nseg);
-	BUG_ON(ret);
+	if (segs_to_map) {
+		ret = gnttab_map_refs(map, NULL, pages_to_gnt, segs_to_map);
+		BUG_ON(ret);
+	}
 
 	/*
 	 * Now swizzle the MFN in our domain with the MFN from the other domain
 	 * so that when we access vaddr(pending_req,i) it has the contents of
 	 * the page from the other domain.
 	 */
-	for (i = 0; i < nseg; i++) {
-		if (unlikely(map[i].status != 0)) {
-			pr_debug(DRV_PFX "invalid buffer -- could not remap it\n");
-			map[i].handle = BLKBACK_INVALID_HANDLE;
-			ret |= 1;
+	for (i = 0, j = 0; i < nseg; i++) {
+		if (!persistent_gnts[i] || !persistent_gnts[i]->handle) {
+			/* This is a newly mapped grant */
+			BUG_ON(j >= segs_to_map);
+			if (unlikely(map[j].status != 0)) {
+				pr_debug(DRV_PFX "invalid buffer -- could not remap it\n");
+				map[j].handle = BLKBACK_INVALID_HANDLE;
+				ret |= 1;
+				if (persistent_gnts[i]) {
+					rb_erase(&persistent_gnts[i]->node,
+						 &blkif->persistent_gnts);
+					blkif->persistent_gnt_c--;
+					kfree(persistent_gnts[i]);
+					persistent_gnts[i] = NULL;
+				}
+			}
+		}
+		if (persistent_gnts[i]) {
+			if (!persistent_gnts[i]->handle) {
+				/*
+				 * If this is a new persistent grant
+				 * save the handler
+				 */
+				persistent_gnts[i]->handle = map[j].handle;
+				persistent_gnts[i]->dev_bus_addr =
+					map[j++].dev_bus_addr;
+			}
+			pending_handle(pending_req, i) =
+				persistent_gnts[i]->handle;
+			pending_req->unmap_seg[i] = 0;
+
+			if (ret)
+				continue;
+
+			seg[i].buf = persistent_gnts[i]->dev_bus_addr |
+				(req->u.rw.seg[i].first_sect << 9);
+		} else {
+			pending_handle(pending_req, i) = map[j].handle;
+			pending_req->unmap_seg[i] = 1;
+
+			if (ret)
+				continue;
+
+			seg[i].buf = map[j++].dev_bus_addr |
+				(req->u.rw.seg[i].first_sect << 9);
 		}
-
-		pending_handle(pending_req, i) = map[i].handle;
-
-		if (ret)
-			continue;
-
-		seg[i].buf  = map[i].dev_bus_addr |
-			(req->u.rw.seg[i].first_sect << 9);
 	}
 	return ret;
 }
@@ -590,6 +818,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 	int operation;
 	struct blk_plug plug;
 	bool drain = false;
+	struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 
 	switch (req->operation) {
 	case BLKIF_OP_READ:
@@ -676,7 +905,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 	 * the hypercall to unmap the grants - that is all done in
 	 * xen_blkbk_unmap.
 	 */
-	if (xen_blkbk_map(req, pending_req, seg))
+	if (xen_blkbk_map(req, pending_req, seg, pages))
 		goto fail_flush;
 
 	/*
@@ -688,7 +917,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 	for (i = 0; i < nseg; i++) {
 		while ((bio == NULL) ||
 		       (bio_add_page(bio,
-				     blkbk->pending_page(pending_req, i),
+				     pages[i],
 				     seg[i].nsec << 9,
 				     seg[i].buf & ~PAGE_MASK) == 0)) {
 
diff --git a/drivers/block/xen-blkback/common.h b/drivers/block/xen-blkback/common.h
index 9ad3b5e..6c08ee9 100644
--- a/drivers/block/xen-blkback/common.h
+++ b/drivers/block/xen-blkback/common.h
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -160,10 +161,22 @@ struct xen_vbd {
 	sector_t		size;
 	bool			flush_support;
 	bool			discard_secure;
+
+	unsigned int		feature_gnt_persistent:1;
+	unsigned int		overflow_max_grants:1;
 };
 
 struct backend_info;
 
+
+struct persistent_gnt {
+	struct page *page;
+	grant_ref_t gnt;
+	grant_handle_t handle;
+	uint64_t dev_bus_addr;
+	struct rb_node node;
+};
+
 struct xen_blkif {
 	/* Unique identifier for this interface. */
 	domid_t			domid;
@@ -190,6 +203,10 @@ struct xen_blkif {
 	struct task_struct	*xenblkd;
 	unsigned int		waiting_reqs;
 
+	/* frontend feature information */
+	struct rb_root		persistent_gnts;
+	unsigned int		persistent_gnt_c;
+
 	/* statistics */
 	unsigned long		st_print;
 	int			st_rd_req;
diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c
index 4f66171..9f88b4e 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -118,6 +118,7 @@ static struct xen_blkif *xen_blkif_alloc(domid_t domid)
 	atomic_set(&blkif->drain, 0);
 	blkif->st_print = jiffies;
 	init_waitqueue_head(&blkif->waiting_to_free);
+	blkif->persistent_gnts.rb_node = NULL;
 
 	return blkif;
 }
@@ -721,6 +722,7 @@ static int connect_ring(struct backend_info *be)
 	struct xenbus_device *dev = be->dev;
 	unsigned long ring_ref;
 	unsigned int evtchn;
+	unsigned int pers_grants;
 	char protocol[64] = "";
 	int err;
 
@@ -750,8 +752,18 @@ static int connect_ring(struct backend_info *be)
 		xenbus_dev_fatal(dev, err, "unknown fe protocol %s", protocol);
 		return -1;
 	}
-	pr_info(DRV_PFX "ring-ref %ld, event-channel %d, protocol %d (%s)\n",
-		ring_ref, evtchn, be->blkif->blk_protocol, protocol);
+	err = xenbus_gather(XBT_NIL, dev->otherend,
+			    "feature-persistent-grants", "%u",
+			    &pers_grants, NULL);
+	if (err)
+		pers_grants = 0;
+
+	be->blkif->vbd.feature_gnt_persistent = pers_grants;
+	be->blkif->vbd.overflow_max_grants = 0;
+
+	pr_info(DRV_PFX "ring-ref %ld, event-channel %d, protocol %d (%s) persistent %d\n",
+		ring_ref, evtchn, be->blkif->blk_protocol, protocol,
+		pers_grants);
 
 	/* Map the shared frame, irq etc. */
 	err = xen_blkif_map(be->blkif, ring_ref, evtchn);
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 2c2d2e5..206d422 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -44,6 +44,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -64,10 +65,17 @@ enum blkif_state {
 	BLKIF_STATE_SUSPENDED,
 };
 
+struct grant {
+	grant_ref_t gref;
+	unsigned long pfn;
+	struct llist_node node;
+};
+
 struct blk_shadow {
 	struct blkif_request req;
 	struct request *request;
 	unsigned long frame[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct grant *grants_used[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 };
 
 static DEFINE_MUTEX(blkfront_mutex);
@@ -97,6 +105,8 @@ struct blkfront_info
 	struct work_struct work;
 	struct gnttab_free_callback callback;
 	struct blk_shadow shadow[BLK_RING_SIZE];
+	struct llist_head persistent_gnts;
+	unsigned int persistent_gnts_c;
 	unsigned long shadow_free;
 	unsigned int feature_flush;
 	unsigned int flush_op;
@@ -287,21 +297,36 @@ static int blkif_queue_request(struct request *req)
 	unsigned long id;
 	unsigned int fsect, lsect;
 	int i, ref;
+
+	/*
+	 * Used to store if we are able to queue the request by just using
+	 * existing persistent grants (0), or if we have to get new grants,
+	 * as there are not sufficiently many free.
+	 */
+	int new_persistent_gnts;
 	grant_ref_t gref_head;
+	struct page *granted_page;
+	struct grant *gnt_list_entry = NULL;
 	struct scatterlist *sg;
 
 	if (unlikely(info->connected != BLKIF_STATE_CONNECTED))
 		return 1;
 
-	if (gnttab_alloc_grant_references(
-		BLKIF_MAX_SEGMENTS_PER_REQUEST, &gref_head) < 0) {
-		gnttab_request_free_callback(
-			&info->callback,
-			blkif_restart_queue_callback,
-			info,
-			BLKIF_MAX_SEGMENTS_PER_REQUEST);
-		return 1;
-	}
+	/* Check if we have enought grants to allocate a requests */
+	if (info->persistent_gnts_c < BLKIF_MAX_SEGMENTS_PER_REQUEST) {
+		new_persistent_gnts = 1;
+		if (gnttab_alloc_grant_references(
+		    BLKIF_MAX_SEGMENTS_PER_REQUEST - info->persistent_gnts_c,
+		    &gref_head) < 0) {
+			gnttab_request_free_callback(
+				&info->callback,
+				blkif_restart_queue_callback,
+				info,
+				BLKIF_MAX_SEGMENTS_PER_REQUEST);
+			return 1;
+		}
+	} else
+		new_persistent_gnts = 0;
 
 	/* Fill out a communications ring structure. */
 	ring_req = RING_GET_REQUEST(&info->ring, info->ring.req_prod_pvt);
@@ -341,18 +366,73 @@ static int blkif_queue_request(struct request *req)
 		       BLKIF_MAX_SEGMENTS_PER_REQUEST);
 
 		for_each_sg(info->sg, sg, ring_req->u.rw.nr_segments, i) {
-			buffer_mfn = pfn_to_mfn(page_to_pfn(sg_page(sg)));
 			fsect = sg->offset >> 9;
 			lsect = fsect + (sg->length >> 9) - 1;
-			/* install a grant reference. */
-			ref = gnttab_claim_grant_reference(&gref_head);
-			BUG_ON(ref == -ENOSPC);
 
-			gnttab_grant_foreign_access_ref(
-					ref,
+			if (info->persistent_gnts_c) {
+				BUG_ON(llist_empty(&info->persistent_gnts));
+				gnt_list_entry = llist_entry(
+					llist_del_first(&info->persistent_gnts),
+					struct grant, node);
+
+				ref = gnt_list_entry->gref;
+				buffer_mfn = pfn_to_mfn(gnt_list_entry->pfn);
+				info->persistent_gnts_c--;
+			} else {
+				ref = gnttab_claim_grant_reference(&gref_head);
+				BUG_ON(ref == -ENOSPC);
+
+				gnt_list_entry =
+					kmalloc(sizeof(struct grant),
+							 GFP_ATOMIC);
+				if (!gnt_list_entry)
+					return -ENOMEM;
+
+				granted_page = alloc_page(GFP_ATOMIC);
+				if (!granted_page) {
+					kfree(gnt_list_entry);
+					return -ENOMEM;
+				}
+
+				gnt_list_entry->pfn =
+					page_to_pfn(granted_page);
+				gnt_list_entry->gref = ref;
+
+				buffer_mfn = pfn_to_mfn(page_to_pfn(
+								granted_page));
+				gnttab_grant_foreign_access_ref(ref,
 					info->xbdev->otherend_id,
-					buffer_mfn,
-					rq_data_dir(req));
+					buffer_mfn, 0);
+			}
+
+			info->shadow[id].grants_used[i] = gnt_list_entry;
+
+			if (rq_data_dir(req)) {
+				char *bvec_data;
+				void *shared_data;
+
+				BUG_ON(sg->offset + sg->length > PAGE_SIZE);
+
+				shared_data = kmap_atomic(
+					pfn_to_page(gnt_list_entry->pfn));
+				bvec_data = kmap_atomic(sg_page(sg));
+
+				/*
+				 * this does not wipe data stored outside the
+				 * range sg->offset..sg->offset+sg->length.
+				 * Therefore, blkback *could* see data from
+				 * previous requests. This is OK as long as
+				 * persistent grants are shared with just one
+				 * domain. It may need refactoring if This
+				 * changes
+				 */
+				memcpy(shared_data + sg->offset,
+				       bvec_data   + sg->offset,
+				       sg->length);
+
+				kunmap_atomic(bvec_data);
+				kunmap_atomic(shared_data);
+			}
 
 			info->shadow[id].frame[i] = mfn_to_pfn(buffer_mfn);
 			ring_req->u.rw.seg[i] =
@@ -368,7 +448,8 @@ static int blkif_queue_request(struct request *req)
 	/* Keep a private copy so we can reissue requests when recovering. */
 	info->shadow[id].req = *ring_req;
 
-	gnttab_free_grant_references(gref_head);
+	if (new_persistent_gnts)
+		gnttab_free_grant_references(gref_head);
 
 	return 0;
 }
@@ -480,7 +561,7 @@ static int xlvbd_init_blk_queue(struct gendisk *gd, u16 sector_size)
 static void xlvbd_flush(struct blkfront_info *info)
 {
 	blk_queue_flush(info->rq, info->feature_flush);
-	printk(KERN_INFO "blkfront: %s: %s: %s\n",
+	printk(KERN_INFO "blkfront: %s: %s: %s, using persistent grants\n",
 	       info->gd->disk_name,
 	       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
 		"barrier" : (info->flush_op == BLKIF_OP_FLUSH_DISKCACHE ?
@@ -707,6 +788,9 @@ static void blkif_restart_queue(struct work_struct *work)
 
 static void blkif_free(struct blkfront_info *info, int suspend)
 {
+	struct llist_node *all_gnts;
+	struct grant *persistent_gnt;
+
 	/* Prevent new requests being issued until we fix things up. */
 	spin_lock_irq(&info->io_lock);
 	info->connected = suspend ?
@@ -714,6 +798,17 @@ static void blkif_free(struct blkfront_info *info, int suspend)
 	/* No more blkif_request(). */
 	if (info->rq)
 		blk_stop_queue(info->rq);
+
+	/* Remove all persistent grants */
+	if (info->persistent_gnts_c) {
+		all_gnts = llist_del_all(&info->persistent_gnts);
+		llist_for_each_entry(persistent_gnt, all_gnts, node) {
+			gnttab_end_foreign_access(persistent_gnt->gref, 0, 0UL);
+			kfree(persistent_gnt);
+		}
+		info->persistent_gnts_c = 0;
+	}
+
 	/* No more gnttab callback work. */
 	gnttab_cancel_free_callback(&info->callback);
 	spin_unlock_irq(&info->io_lock);
@@ -734,13 +829,42 @@ static void blkif_free(struct blkfront_info *info, int suspend)
 
 }
 
-static void blkif_completion(struct blk_shadow *s)
+static void blkif_completion(struct blk_shadow *s, struct blkfront_info *info,
+			     struct blkif_response *bret)
 {
 	int i;
-	/* Do not let BLKIF_OP_DISCARD as nr_segment is in the same place
-	 * flag. */
-	for (i = 0; i < s->req.u.rw.nr_segments; i++)
-		gnttab_end_foreign_access(s->req.u.rw.seg[i].gref, 0, 0UL);
+	struct bio_vec *bvec;
+	struct req_iterator iter;
+	unsigned long flags;
+	char *bvec_data;
+	void *shared_data;
+	unsigned int offset = 0;
+
+	if (bret->operation == BLKIF_OP_READ) {
+		/*
+		 * Copy the data received from the backend into the bvec.
+		 * Since bv_len can be different from PAGE_SIZE, we need to
+		 * be sure we are actually copying the data from the right
+		 * shared page.
+		 */
+		rq_for_each_segment(bvec, s->request, iter) {
+			BUG_ON((bvec->bv_offset + bvec->bv_len) > PAGE_SIZE);
+			i = offset >> PAGE_SHIFT;
+			shared_data = kmap_atomic(
+				pfn_to_page(s->grants_used[i]->pfn));
+			bvec_data = bvec_kmap_irq(bvec, &flags);
+			memcpy(bvec_data, shared_data + bvec->bv_offset,
+				bvec->bv_len);
+			bvec_kunmap_irq(bvec_data, &flags);
+			kunmap_atomic(shared_data);
+			offset += bvec->bv_len;
+		}
+	}
+	/* Add the persistent grant into the list of free grants */
+	for (i = 0; i < s->req.u.rw.nr_segments; i++) {
+		llist_add(&s->grants_used[i]->node, &info->persistent_gnts);
+		info->persistent_gnts_c++;
+	}
 }
 
 static irqreturn_t blkif_interrupt(int irq, void *dev_id)
@@ -783,7 +907,7 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
 		req  = info->shadow[id].request;
 
 		if (bret->operation != BLKIF_OP_DISCARD)
-			blkif_completion(&info->shadow[id]);
+			blkif_completion(&info->shadow[id], info, bret);
 
 		if (add_id_to_freelist(info, id)) {
 			WARN(1, "%s: response to %s (id %ld) couldn't be recycled!\n",
@@ -942,6 +1066,11 @@ again:
 		message = "writing protocol";
 		goto abort_transaction;
 	}
+	err = xenbus_printf(xbt, dev->nodename,
+			    "feature-persistent-grants", "%d", 1);
+	if (err)
+		dev_warn(&dev->dev,
+			 "writing persistent grants feature to xenbus");
 
 	err = xenbus_transaction_end(xbt, 0);
 	if (err) {
@@ -1029,6 +1158,8 @@ static int blkfront_probe(struct xenbus_device *dev,
 	spin_lock_init(&info->io_lock);
 	info->xbdev = dev;
 	info->vdevice = vdevice;
+	init_llist_head(&info->persistent_gnts);
+	info->persistent_gnts_c = 0;
 	info->connected = BLKIF_STATE_DISCONNECTED;
 	INIT_WORK(&info->work, blkif_restart_queue);
 
@@ -1093,7 +1224,7 @@ static int blkif_recover(struct blkfront_info *info)
 					req->u.rw.seg[j].gref,
 					info->xbdev->otherend_id,
 					pfn_to_mfn(info->shadow[req->u.rw.id].frame[j]),
-					rq_data_dir(info->shadow[req->u.rw.id].request));
+					0);
 		}
 		info->shadow[req->u.rw.id].req = *req;
 
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 11:23:35 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 11:23:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOoC2-0003bz-RX; Thu, 18 Oct 2012 11:23:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOoC2-0003bo-0F
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 11:23:14 +0000
Received: from [85.158.138.51:16407] by server-13.bemta-3.messagelabs.com id
	8F/55-26794-1A6EF705; Thu, 18 Oct 2012 11:23:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1350559392!26924097!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14858 invoked from network); 18 Oct 2012 11:23:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 11:23:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15252284"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 11:23:12 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 12:23:12 +0100
Message-ID: <1350559390.2460.124.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Dario Faggioli 
Date: Thu, 18 Oct 2012 12:23:10 +0100
In-Reply-To: <6d7a403305dd057f61bd.1350408388@Solace>
References: 
	<6d7a403305dd057f61bd.1350408388@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Andre Przywara ,
	Ian Jackson ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 3 of 3] xl: allow for node-wise
 specification of vcpu pinning
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-16 at 18:26 +0100, Dario Faggioli wrote:

> +            isnot = 1;
> +        }
> +        /* Check if we're dealing with a full node */
> +        if (strstr(toka, "node:") == toka || strstr(toka, "nodes:") == toka) {

Isn't strstr(FOO, "thing") == FOO just an expensive way of writing
strncmp(FOO, "ting", sizeof(...))?

Ian


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 11:23:35 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 11:23:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOoC2-0003bz-RX; Thu, 18 Oct 2012 11:23:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOoC2-0003bo-0F
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 11:23:14 +0000
Received: from [85.158.138.51:16407] by server-13.bemta-3.messagelabs.com id
	8F/55-26794-1A6EF705; Thu, 18 Oct 2012 11:23:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1350559392!26924097!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14858 invoked from network); 18 Oct 2012 11:23:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 11:23:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15252284"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 11:23:12 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 12:23:12 +0100
Message-ID: <1350559390.2460.124.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Dario Faggioli 
Date: Thu, 18 Oct 2012 12:23:10 +0100
In-Reply-To: <6d7a403305dd057f61bd.1350408388@Solace>
References: 
	<6d7a403305dd057f61bd.1350408388@Solace>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Andre Przywara ,
	Ian Jackson ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 3 of 3] xl: allow for node-wise
 specification of vcpu pinning
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-16 at 18:26 +0100, Dario Faggioli wrote:

> +            isnot = 1;
> +        }
> +        /* Check if we're dealing with a full node */
> +        if (strstr(toka, "node:") == toka || strstr(toka, "nodes:") == toka) {

Isn't strstr(FOO, "thing") == FOO just an expensive way of writing
strncmp(FOO, "ting", sizeof(...))?

Ian


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 11:32:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 11:32:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOoK7-0003t4-SH; Thu, 18 Oct 2012 11:31:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOoK6-0003sz-4f
	for Xen-devel@lists.xensource.com; Thu, 18 Oct 2012 11:31:34 +0000
Received: from [85.158.137.99:4080] by server-10.bemta-3.messagelabs.com id
	F8/24-27386-598EF705; Thu, 18 Oct 2012 11:31:33 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1350559892!18958785!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6032 invoked from network); 18 Oct 2012 11:31:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 11:31:32 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15252487"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 11:31:32 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 18 Oct 2012 12:31:32 +0100
Date: Thu, 18 Oct 2012 12:31:08 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Mukesh Rathor 
In-Reply-To: <20121017173119.4e12b222@mantra.us.oracle.com>
Message-ID: 
References: <20121017173119.4e12b222@mantra.us.oracle.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V3 3/6]: PVH:  mmu related changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 18 Oct 2012, Mukesh Rathor wrote:
> PVH: This patch implements mmu changes for PVH. First the set/clear mmio pte function makes a hypercall to update the p2m in xen with 1:1 mapping. PVH uses mostly native mmu ops. Two local functions are introduced to add to xen physmap for xen remap interface. xen unmap interface is introduced so the privcmd pte entries can be cleared in xen p2m table.
> 
> Signed-off-by: Mukesh Rathor 
> ---
>  arch/x86/xen/mmu.c    |  174 ++++++++++++++++++++++++++++++++++++++++++++++---
>  arch/x86/xen/mmu.h    |    2 +
>  drivers/xen/privcmd.c |    5 +-
>  include/xen/xen-ops.h |    5 +-
>  4 files changed, 174 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index 5a16824..5ed3b3e 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -73,6 +73,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "multicalls.h"
>  #include "mmu.h"
> @@ -331,6 +332,20 @@ static void xen_set_pte(pte_t *ptep, pte_t pteval)
>  	__xen_set_pte(ptep, pteval);
>  }
>  
> +void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn,
> +			      int nr_mfns, int add_mapping)
> +{
> +	struct physdev_map_iomem iomem;
> +
> +	iomem.first_gfn = pfn;
> +	iomem.first_mfn = mfn;
> +	iomem.nr_mfns = nr_mfns;
> +	iomem.add_mapping = add_mapping;
> +
> +	if (HYPERVISOR_physdev_op(PHYSDEVOP_pvh_map_iomem, &iomem))
> +		BUG();
> +}

You introduce this function here but it is unused. It is not clear from
the patch description why you are introducing it.


>  static void xen_set_pte_at(struct mm_struct *mm, unsigned long addr,
>  		    pte_t *ptep, pte_t pteval)
>  {
> @@ -1220,6 +1235,8 @@ static void __init xen_pagetable_init(void)
>  #endif
>  	paging_init();
>  	xen_setup_shared_info();
> +	if (xen_feature(XENFEAT_auto_translated_physmap))
> +		return;
>  #ifdef CONFIG_X86_64
>  	if (!xen_feature(XENFEAT_auto_translated_physmap)) {
>  		unsigned long new_mfn_list;
> @@ -1527,6 +1544,10 @@ static void __init xen_set_pte_init(pte_t *ptep, pte_t pte)
>  static void pin_pagetable_pfn(unsigned cmd, unsigned long pfn)
>  {
>  	struct mmuext_op op;
> +
> +	if (xen_feature(XENFEAT_writable_page_tables))
> +		return;
> +
>  	op.cmd = cmd;
>  	op.arg1.mfn = pfn_to_mfn(pfn);
>  	if (HYPERVISOR_mmuext_op(&op, 1, NULL, DOMID_SELF))
> @@ -1724,6 +1745,10 @@ static void set_page_prot(void *addr, pgprot_t prot)
>  	unsigned long pfn = __pa(addr) >> PAGE_SHIFT;
>  	pte_t pte = pfn_pte(pfn, prot);
>  
> +	/* recall for PVH, page tables are native. */
> +	if (xen_feature(XENFEAT_auto_translated_physmap))
> +		return;
> +
>  	if (HYPERVISOR_update_va_mapping((unsigned long)addr, pte, 0))
>  		BUG();
>  }
> @@ -1801,6 +1826,9 @@ static void convert_pfn_mfn(void *v)
>  	pte_t *pte = v;
>  	int i;
>  
> +	if (xen_feature(XENFEAT_auto_translated_physmap))
> +		return;
> +
>  	/* All levels are converted the same way, so just treat them
>  	   as ptes. */
>  	for (i = 0; i < PTRS_PER_PTE; i++)
> @@ -1820,6 +1848,7 @@ static void __init check_pt_base(unsigned long *pt_base, unsigned long *pt_end,
>  		(*pt_end)--;
>  	}
>  }
> +
>  /*
>   * Set up the initial kernel pagetable.
>   *
> @@ -1830,6 +1859,7 @@ static void __init check_pt_base(unsigned long *pt_base, unsigned long *pt_end,
>   * but that's enough to get __va working.  We need to fill in the rest
>   * of the physical mapping once some sort of allocator has been set
>   * up.
> + * NOTE: for PVH, the page tables are native.
>   */
>  void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn)
>  {
> @@ -1907,10 +1937,13 @@ void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn)
>  	 * structure to attach it to, so make sure we just set kernel
>  	 * pgd.
>  	 */
> -	xen_mc_batch();
> -	__xen_write_cr3(true, __pa(init_level4_pgt));
> -	xen_mc_issue(PARAVIRT_LAZY_CPU);
> -
> +	if (xen_feature(XENFEAT_writable_page_tables)) {
> +		native_write_cr3(__pa(init_level4_pgt));
> +	} else {
> +		xen_mc_batch();
> +		__xen_write_cr3(true, __pa(init_level4_pgt));
> +		xen_mc_issue(PARAVIRT_LAZY_CPU);
> +	}
>  	/* We can't that easily rip out L3 and L2, as the Xen pagetables are
>  	 * set out this way: [L4], [L1], [L2], [L3], [L1], [L1] ...  for
>  	 * the initial domain. For guests using the toolstack, they are in:
> @@ -2177,8 +2210,20 @@ static const struct pv_mmu_ops xen_mmu_ops __initconst = {
>  
>  void __init xen_init_mmu_ops(void)
>  {
> -	x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
>  	x86_init.paging.pagetable_init = xen_pagetable_init;
> +
> +	if (xen_feature(XENFEAT_auto_translated_physmap)) {
> +		pv_mmu_ops.flush_tlb_others = xen_flush_tlb_others;
> +#if 0
> +		/* For PCI devices to map iomem. */
> +		if (xen_initial_domain()) {
> +			pv_mmu_ops.set_pte = native_set_pte;
> +			pv_mmu_ops.set_pte_at = native_set_pte_at;
> +		}
> +#endif

just remove the commented out code

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 11:32:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 11:32:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOoK7-0003t4-SH; Thu, 18 Oct 2012 11:31:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOoK6-0003sz-4f
	for Xen-devel@lists.xensource.com; Thu, 18 Oct 2012 11:31:34 +0000
Received: from [85.158.137.99:4080] by server-10.bemta-3.messagelabs.com id
	F8/24-27386-598EF705; Thu, 18 Oct 2012 11:31:33 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1350559892!18958785!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6032 invoked from network); 18 Oct 2012 11:31:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 11:31:32 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15252487"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 11:31:32 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 18 Oct 2012 12:31:32 +0100
Date: Thu, 18 Oct 2012 12:31:08 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Mukesh Rathor 
In-Reply-To: <20121017173119.4e12b222@mantra.us.oracle.com>
Message-ID: 
References: <20121017173119.4e12b222@mantra.us.oracle.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V3 3/6]: PVH:  mmu related changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 18 Oct 2012, Mukesh Rathor wrote:
> PVH: This patch implements mmu changes for PVH. First the set/clear mmio pte function makes a hypercall to update the p2m in xen with 1:1 mapping. PVH uses mostly native mmu ops. Two local functions are introduced to add to xen physmap for xen remap interface. xen unmap interface is introduced so the privcmd pte entries can be cleared in xen p2m table.
> 
> Signed-off-by: Mukesh Rathor 
> ---
>  arch/x86/xen/mmu.c    |  174 ++++++++++++++++++++++++++++++++++++++++++++++---
>  arch/x86/xen/mmu.h    |    2 +
>  drivers/xen/privcmd.c |    5 +-
>  include/xen/xen-ops.h |    5 +-
>  4 files changed, 174 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index 5a16824..5ed3b3e 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -73,6 +73,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "multicalls.h"
>  #include "mmu.h"
> @@ -331,6 +332,20 @@ static void xen_set_pte(pte_t *ptep, pte_t pteval)
>  	__xen_set_pte(ptep, pteval);
>  }
>  
> +void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn,
> +			      int nr_mfns, int add_mapping)
> +{
> +	struct physdev_map_iomem iomem;
> +
> +	iomem.first_gfn = pfn;
> +	iomem.first_mfn = mfn;
> +	iomem.nr_mfns = nr_mfns;
> +	iomem.add_mapping = add_mapping;
> +
> +	if (HYPERVISOR_physdev_op(PHYSDEVOP_pvh_map_iomem, &iomem))
> +		BUG();
> +}

You introduce this function here but it is unused. It is not clear from
the patch description why you are introducing it.


>  static void xen_set_pte_at(struct mm_struct *mm, unsigned long addr,
>  		    pte_t *ptep, pte_t pteval)
>  {
> @@ -1220,6 +1235,8 @@ static void __init xen_pagetable_init(void)
>  #endif
>  	paging_init();
>  	xen_setup_shared_info();
> +	if (xen_feature(XENFEAT_auto_translated_physmap))
> +		return;
>  #ifdef CONFIG_X86_64
>  	if (!xen_feature(XENFEAT_auto_translated_physmap)) {
>  		unsigned long new_mfn_list;
> @@ -1527,6 +1544,10 @@ static void __init xen_set_pte_init(pte_t *ptep, pte_t pte)
>  static void pin_pagetable_pfn(unsigned cmd, unsigned long pfn)
>  {
>  	struct mmuext_op op;
> +
> +	if (xen_feature(XENFEAT_writable_page_tables))
> +		return;
> +
>  	op.cmd = cmd;
>  	op.arg1.mfn = pfn_to_mfn(pfn);
>  	if (HYPERVISOR_mmuext_op(&op, 1, NULL, DOMID_SELF))
> @@ -1724,6 +1745,10 @@ static void set_page_prot(void *addr, pgprot_t prot)
>  	unsigned long pfn = __pa(addr) >> PAGE_SHIFT;
>  	pte_t pte = pfn_pte(pfn, prot);
>  
> +	/* recall for PVH, page tables are native. */
> +	if (xen_feature(XENFEAT_auto_translated_physmap))
> +		return;
> +
>  	if (HYPERVISOR_update_va_mapping((unsigned long)addr, pte, 0))
>  		BUG();
>  }
> @@ -1801,6 +1826,9 @@ static void convert_pfn_mfn(void *v)
>  	pte_t *pte = v;
>  	int i;
>  
> +	if (xen_feature(XENFEAT_auto_translated_physmap))
> +		return;
> +
>  	/* All levels are converted the same way, so just treat them
>  	   as ptes. */
>  	for (i = 0; i < PTRS_PER_PTE; i++)
> @@ -1820,6 +1848,7 @@ static void __init check_pt_base(unsigned long *pt_base, unsigned long *pt_end,
>  		(*pt_end)--;
>  	}
>  }
> +
>  /*
>   * Set up the initial kernel pagetable.
>   *
> @@ -1830,6 +1859,7 @@ static void __init check_pt_base(unsigned long *pt_base, unsigned long *pt_end,
>   * but that's enough to get __va working.  We need to fill in the rest
>   * of the physical mapping once some sort of allocator has been set
>   * up.
> + * NOTE: for PVH, the page tables are native.
>   */
>  void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn)
>  {
> @@ -1907,10 +1937,13 @@ void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn)
>  	 * structure to attach it to, so make sure we just set kernel
>  	 * pgd.
>  	 */
> -	xen_mc_batch();
> -	__xen_write_cr3(true, __pa(init_level4_pgt));
> -	xen_mc_issue(PARAVIRT_LAZY_CPU);
> -
> +	if (xen_feature(XENFEAT_writable_page_tables)) {
> +		native_write_cr3(__pa(init_level4_pgt));
> +	} else {
> +		xen_mc_batch();
> +		__xen_write_cr3(true, __pa(init_level4_pgt));
> +		xen_mc_issue(PARAVIRT_LAZY_CPU);
> +	}
>  	/* We can't that easily rip out L3 and L2, as the Xen pagetables are
>  	 * set out this way: [L4], [L1], [L2], [L3], [L1], [L1] ...  for
>  	 * the initial domain. For guests using the toolstack, they are in:
> @@ -2177,8 +2210,20 @@ static const struct pv_mmu_ops xen_mmu_ops __initconst = {
>  
>  void __init xen_init_mmu_ops(void)
>  {
> -	x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
>  	x86_init.paging.pagetable_init = xen_pagetable_init;
> +
> +	if (xen_feature(XENFEAT_auto_translated_physmap)) {
> +		pv_mmu_ops.flush_tlb_others = xen_flush_tlb_others;
> +#if 0
> +		/* For PCI devices to map iomem. */
> +		if (xen_initial_domain()) {
> +			pv_mmu_ops.set_pte = native_set_pte;
> +			pv_mmu_ops.set_pte_at = native_set_pte_at;
> +		}
> +#endif

just remove the commented out code

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 11:41:59 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 11:41:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOoTm-00047p-30; Thu, 18 Oct 2012 11:41:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOoTk-00047k-0U
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 11:41:32 +0000
Received: from [85.158.139.211:52376] by server-15.bemta-5.messagelabs.com id
	C9/F7-28599-BEAEF705; Thu, 18 Oct 2012 11:41:31 +0000
X-Env-Sender: Conny.Seidel@amd.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1350560488!22770164!1
X-Originating-IP: [216.32.180.187]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20553 invoked from network); 18 Oct 2012 11:41:30 -0000
Received: from co1ehsobe004.messaging.microsoft.com (HELO
	co1outboundpool.messaging.microsoft.com) (216.32.180.187)
	by server-5.tower-206.messagelabs.com with AES128-SHA encrypted SMTP;
	18 Oct 2012 11:41:30 -0000
Received: from mail72-co1-R.bigfish.com (10.243.78.251) by
	CO1EHSOBE003.bigfish.com (10.243.66.66) with Microsoft SMTP Server id
	14.1.225.23; Thu, 18 Oct 2012 11:41:28 +0000
Received: from mail72-co1 (localhost [127.0.0.1])	by mail72-co1-R.bigfish.com
	(Postfix) with ESMTP id 15C7C9A019B	for
	; Thu,
	18 Oct 2012 11:41:28 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: -2
X-BigFish: VPS-2(zzd6eah1be0Izz1202h1d1ah1d2ahzz8275bh15d4Iz2dh668h839hd24he5bhf0ah107ah1288h12a5h12bdh137ah139eh1441h34h1155h)
Received: from mail72-co1 (localhost.localdomain [127.0.0.1]) by mail72-co1
	(MessageSwitch) id 1350560485678596_10986;
	Thu, 18 Oct 2012 11:41:25 +0000 (UTC)
Received: from CO1EHSMHS001.bigfish.com (unknown [10.243.78.228])	by
	mail72-co1.bigfish.com (Postfix) with ESMTP id A1F851C0047	for
	; Thu, 18 Oct 2012 11:41:25 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CO1EHSMHS001.bigfish.com (10.243.66.11) with Microsoft SMTP Server id
	14.1.225.23; Thu, 18 Oct 2012 11:41:24 +0000
X-WSS-ID: 0MC374Y-01-7CF-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 24EE01028092	for ;
	Thu, 18 Oct 2012 06:41:22 -0500 (CDT)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 18 Oct 2012 06:57:16 -0500
Received: from STOREXDAG03.amd.com (10.1.13.12) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Thu, 18 Oct 2012 06:41:22 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexdag03.amd.com
	(10.1.13.12) with Microsoft SMTP Server id 14.1.323.3; Thu, 18 Oct 2012
	07:41:21 -0400
Received: from marah.osrc.amd.com (marah.osrc.amd.com [165.204.15.125])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 7B6E149C0D5	for
	; Thu, 18 Oct 2012 12:41:20 +0100 (BST)
Date: Thu, 18 Oct 2012 13:41:40 +0200
From: Conny Seidel 
To: xen-devel 
Message-ID: <20121018134140.3f5ac937.conny.seidel@amd.com>
Organization: Advanced Micro Devices GmbH; Einsteinring 24; 85609 Dornach
	bei Muenchen; Geschaeftsfuehrer: Alberto Bozzo; Sitz: Dornach, Gemeinde
	Aschheim, Landkreis Muenchen; Registergericht Muenchen, HRB Nr. 43632
X-Mailer: Claws Mail 3.8.1cvs92 (GTK+ 2.24.10; x86_64-pc-linux-gnu)
MIME-Version: 1.0
X-OriginatorOrg: amd.com
Subject: [Xen-devel] XEN-HV Panic on 4.1.3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============3501566560696499167=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3501566560696499167==
Content-Type: multipart/signed; micalg=PGP-SHA1;
	boundary="Sig_/6620CtkCOMPtl+gap/ssX2a";
	protocol="application/pgp-signature"

--Sig_/6620CtkCOMPtl+gap/ssX2a
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Hi,

we are seeing lately a lot of these HV-panics.

This happens when we try to start a guest/multiple guests.


(XEN) sh error: shadow_unhook_mappings(): top-level shadow has bad type 000=
00001
(XEN) Xen BUG at common.c:1305
(XEN) ----[ Xen-4.1.3  x86_32p  debug=3Dn  Not tainted ]----
(XEN) CPU:    19
(XEN) EIP:    e008:[] shadow_unhook_mappings+0x46/0xb0
(XEN) EFLAGS: 00010282   CONTEXT: hypervisor
(XEN) eax: 00000000   ebx: 00000001   ecx: 00000000   edx: 00000000
(XEN) esi: ff998000   edi: ffaf5e18   ebp: 00225965   esp: ffa9fc9c
(XEN) cr0: 8005003b   cr4: 000006f0   cr3: 00998c80   cr2: b7656fd0
(XEN) ds: e010   es: e010   fs: 00d8   gs: 00e0   ss: e010   cs: e008
(XEN) Xen stack trace from esp=3Dffa9fc9c:
(XEN)    ff20cb84 ff1e724f 00000001 00000000 ffa9ffb0 00000001 ffa9ffb0 ff1=
d25b5
(XEN)    ff998000 00000000 00000001 ffa9fd08 00000000 ff998000 ffaf5e18 000=
31dc1
(XEN)    00225bc1 ffa9ffb0 00000004 ff999040 31f65000 00000000 00000001 000=
00001
(XEN)    00000000 00000000 00000009 00000007 00000010 00000001 00000001 ff9=
a0000
(XEN)    00000000 f1dc1e88 00000009 ff19ea96 ff998000 31f65000 00000000 ffa=
9ffb0
(XEN)    ffa9fdbc 00000000 fbb58d14 fbb58d08 00000000 fbb58d08 00000000 ff1=
5c406
(XEN)    fbb58d08 00000000 00106800 ff1d12c7 7908b063 80000003 ff9a0000 000=
00029
(XEN)    00000296 ff998058 ff998058 80000003 90ceccdd ff998000 ff998000 fe7=
ffdd0
(XEN)    ff998000 ff9a0000 00000029 003d47fb ff998000 003d5a54 c0947ff0 802=
0001d
(XEN)    31f65000 00000000 00000000 003d5a54 d5a54067 b7656fd0 31445001 ff9=
a0000
(XEN)    6e68b067 00000001 6acd6025 00000022 ffa9ffb0 ff998000 ff992000 ff1=
9b6c1
(XEN)    00000009 f1dc1e88 00000000 f2203480 f22034b8 f1dc1ea4 0000000f 000=
00007
(XEN)    0c930068 ffffffff 00000000 00000000 00000000 00000003 00000081 ff1=
b06f6
(XEN)    ffa9ffb0 ffa9ff88 00000001 00000000 fedb4840 ff19d818 fedb4840 002=
2031a
(XEN)    0000002c ffa9fe98 00000001 ff998000 ffa9fea4 ffa9ffb0 ff99807c ff9=
98000
(XEN)    ffaf5e18 ff1ad36f ff998de8 00000000 ff121fb0 00000013 00000004 ff9=
98000
(XEN)    00000013 ff998ed0 00000013 00000082 ff12215e ff2112b4 0000002c ffa=
9ffb0
(XEN)    00000000 ff9a0000 00000006 00000082 ff122182 ff2112b4 00000082 000=
00046
(XEN)    ff105c9c ff998ed0 ff998000 00000080 00000000 6833feb3 00000029 2c7=
e820e
(XEN)    00000000 90c08188 00000029 00000000 90cf902d 00000029 90ceccdd 000=
00029
(XEN) Xen call trace:
(XEN)    [] shadow_unhook_mappings+0x46/0xb0
(XEN)    [] sh_pagetable_dying+0x195/0x410
(XEN)    [] do_hvm_op+0xbd6/0x1bf0
(XEN)    [] put_page_and_type+0x16/0x20
(XEN)    [] shadow_set_l1e+0x317/0x670
(XEN)    [] hvm_do_hypercall+0x91/0x170
(XEN)    [] svm_vmexit_handler+0x166/0x1540
(XEN)    [] __hvm_copy+0xa8/0x300
(XEN)    [] pt_restore_timer+0x1f/0xd0
(XEN)    [] tasklet_enqueue+0xb0/0xc0
(XEN)    [] tasklet_schedule_on_cpu+0x7e/0x80
(XEN)    [] tasklet_schedule+0x22/0x30
(XEN)    [] evtchn_set_pending+0x7c/0x150
(XEN)    [] pt_update_irq+0x2e/0x230
(XEN)    [] hvm_vcpu_has_pending_irq+0x5a/0xc0
(XEN)    [] svm_intr_assist+0x40/0x1a0
(XEN)    [] __do_softirq+0x5f/0x90
(XEN)    [] svm_stgi_label+0x8/0x34
(XEN)
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 19:
(XEN) Xen BUG at common.c:1305
(XEN) ****************************************

--
Kind regards.

Conny Seidel

##################################################################
# Email : conny.seidel@amd.com            GnuPG-Key : 0xA6AB055D #
# Fingerprint: 17C4 5DB2 7C4C C1C7 1452 8148 F139 7C09 A6AB 055D #
##################################################################
# Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach      #
# General Managers: Alberto Bozzo                                #
# Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen #
#               HRB Nr. 43632                                    #
##################################################################

--Sig_/6620CtkCOMPtl+gap/ssX2a
Content-Type: application/pgp-signature; name="signature.asc"
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlB/6vQACgkQ8Tl8CaarBV2NogCdEgVRfceGIo4H98FjQGnVjdmJ
S0oAoOylNvQB/Vy+pjuuv84qWsmQkysC
=Wl2A
-----END PGP SIGNATURE-----

--Sig_/6620CtkCOMPtl+gap/ssX2a--


--===============3501566560696499167==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3501566560696499167==--


From xen-devel-bounces@lists.xen.org Thu Oct 18 11:41:59 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 11:41:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOoTm-00047p-30; Thu, 18 Oct 2012 11:41:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOoTk-00047k-0U
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 11:41:32 +0000
Received: from [85.158.139.211:52376] by server-15.bemta-5.messagelabs.com id
	C9/F7-28599-BEAEF705; Thu, 18 Oct 2012 11:41:31 +0000
X-Env-Sender: Conny.Seidel@amd.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1350560488!22770164!1
X-Originating-IP: [216.32.180.187]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20553 invoked from network); 18 Oct 2012 11:41:30 -0000
Received: from co1ehsobe004.messaging.microsoft.com (HELO
	co1outboundpool.messaging.microsoft.com) (216.32.180.187)
	by server-5.tower-206.messagelabs.com with AES128-SHA encrypted SMTP;
	18 Oct 2012 11:41:30 -0000
Received: from mail72-co1-R.bigfish.com (10.243.78.251) by
	CO1EHSOBE003.bigfish.com (10.243.66.66) with Microsoft SMTP Server id
	14.1.225.23; Thu, 18 Oct 2012 11:41:28 +0000
Received: from mail72-co1 (localhost [127.0.0.1])	by mail72-co1-R.bigfish.com
	(Postfix) with ESMTP id 15C7C9A019B	for
	; Thu,
	18 Oct 2012 11:41:28 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: -2
X-BigFish: VPS-2(zzd6eah1be0Izz1202h1d1ah1d2ahzz8275bh15d4Iz2dh668h839hd24he5bhf0ah107ah1288h12a5h12bdh137ah139eh1441h34h1155h)
Received: from mail72-co1 (localhost.localdomain [127.0.0.1]) by mail72-co1
	(MessageSwitch) id 1350560485678596_10986;
	Thu, 18 Oct 2012 11:41:25 +0000 (UTC)
Received: from CO1EHSMHS001.bigfish.com (unknown [10.243.78.228])	by
	mail72-co1.bigfish.com (Postfix) with ESMTP id A1F851C0047	for
	; Thu, 18 Oct 2012 11:41:25 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CO1EHSMHS001.bigfish.com (10.243.66.11) with Microsoft SMTP Server id
	14.1.225.23; Thu, 18 Oct 2012 11:41:24 +0000
X-WSS-ID: 0MC374Y-01-7CF-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 24EE01028092	for ;
	Thu, 18 Oct 2012 06:41:22 -0500 (CDT)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 18 Oct 2012 06:57:16 -0500
Received: from STOREXDAG03.amd.com (10.1.13.12) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Thu, 18 Oct 2012 06:41:22 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexdag03.amd.com
	(10.1.13.12) with Microsoft SMTP Server id 14.1.323.3; Thu, 18 Oct 2012
	07:41:21 -0400
Received: from marah.osrc.amd.com (marah.osrc.amd.com [165.204.15.125])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 7B6E149C0D5	for
	; Thu, 18 Oct 2012 12:41:20 +0100 (BST)
Date: Thu, 18 Oct 2012 13:41:40 +0200
From: Conny Seidel 
To: xen-devel 
Message-ID: <20121018134140.3f5ac937.conny.seidel@amd.com>
Organization: Advanced Micro Devices GmbH; Einsteinring 24; 85609 Dornach
	bei Muenchen; Geschaeftsfuehrer: Alberto Bozzo; Sitz: Dornach, Gemeinde
	Aschheim, Landkreis Muenchen; Registergericht Muenchen, HRB Nr. 43632
X-Mailer: Claws Mail 3.8.1cvs92 (GTK+ 2.24.10; x86_64-pc-linux-gnu)
MIME-Version: 1.0
X-OriginatorOrg: amd.com
Subject: [Xen-devel] XEN-HV Panic on 4.1.3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============3501566560696499167=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3501566560696499167==
Content-Type: multipart/signed; micalg=PGP-SHA1;
	boundary="Sig_/6620CtkCOMPtl+gap/ssX2a";
	protocol="application/pgp-signature"

--Sig_/6620CtkCOMPtl+gap/ssX2a
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Hi,

we are seeing lately a lot of these HV-panics.

This happens when we try to start a guest/multiple guests.


(XEN) sh error: shadow_unhook_mappings(): top-level shadow has bad type 000=
00001
(XEN) Xen BUG at common.c:1305
(XEN) ----[ Xen-4.1.3  x86_32p  debug=3Dn  Not tainted ]----
(XEN) CPU:    19
(XEN) EIP:    e008:[] shadow_unhook_mappings+0x46/0xb0
(XEN) EFLAGS: 00010282   CONTEXT: hypervisor
(XEN) eax: 00000000   ebx: 00000001   ecx: 00000000   edx: 00000000
(XEN) esi: ff998000   edi: ffaf5e18   ebp: 00225965   esp: ffa9fc9c
(XEN) cr0: 8005003b   cr4: 000006f0   cr3: 00998c80   cr2: b7656fd0
(XEN) ds: e010   es: e010   fs: 00d8   gs: 00e0   ss: e010   cs: e008
(XEN) Xen stack trace from esp=3Dffa9fc9c:
(XEN)    ff20cb84 ff1e724f 00000001 00000000 ffa9ffb0 00000001 ffa9ffb0 ff1=
d25b5
(XEN)    ff998000 00000000 00000001 ffa9fd08 00000000 ff998000 ffaf5e18 000=
31dc1
(XEN)    00225bc1 ffa9ffb0 00000004 ff999040 31f65000 00000000 00000001 000=
00001
(XEN)    00000000 00000000 00000009 00000007 00000010 00000001 00000001 ff9=
a0000
(XEN)    00000000 f1dc1e88 00000009 ff19ea96 ff998000 31f65000 00000000 ffa=
9ffb0
(XEN)    ffa9fdbc 00000000 fbb58d14 fbb58d08 00000000 fbb58d08 00000000 ff1=
5c406
(XEN)    fbb58d08 00000000 00106800 ff1d12c7 7908b063 80000003 ff9a0000 000=
00029
(XEN)    00000296 ff998058 ff998058 80000003 90ceccdd ff998000 ff998000 fe7=
ffdd0
(XEN)    ff998000 ff9a0000 00000029 003d47fb ff998000 003d5a54 c0947ff0 802=
0001d
(XEN)    31f65000 00000000 00000000 003d5a54 d5a54067 b7656fd0 31445001 ff9=
a0000
(XEN)    6e68b067 00000001 6acd6025 00000022 ffa9ffb0 ff998000 ff992000 ff1=
9b6c1
(XEN)    00000009 f1dc1e88 00000000 f2203480 f22034b8 f1dc1ea4 0000000f 000=
00007
(XEN)    0c930068 ffffffff 00000000 00000000 00000000 00000003 00000081 ff1=
b06f6
(XEN)    ffa9ffb0 ffa9ff88 00000001 00000000 fedb4840 ff19d818 fedb4840 002=
2031a
(XEN)    0000002c ffa9fe98 00000001 ff998000 ffa9fea4 ffa9ffb0 ff99807c ff9=
98000
(XEN)    ffaf5e18 ff1ad36f ff998de8 00000000 ff121fb0 00000013 00000004 ff9=
98000
(XEN)    00000013 ff998ed0 00000013 00000082 ff12215e ff2112b4 0000002c ffa=
9ffb0
(XEN)    00000000 ff9a0000 00000006 00000082 ff122182 ff2112b4 00000082 000=
00046
(XEN)    ff105c9c ff998ed0 ff998000 00000080 00000000 6833feb3 00000029 2c7=
e820e
(XEN)    00000000 90c08188 00000029 00000000 90cf902d 00000029 90ceccdd 000=
00029
(XEN) Xen call trace:
(XEN)    [] shadow_unhook_mappings+0x46/0xb0
(XEN)    [] sh_pagetable_dying+0x195/0x410
(XEN)    [] do_hvm_op+0xbd6/0x1bf0
(XEN)    [] put_page_and_type+0x16/0x20
(XEN)    [] shadow_set_l1e+0x317/0x670
(XEN)    [] hvm_do_hypercall+0x91/0x170
(XEN)    [] svm_vmexit_handler+0x166/0x1540
(XEN)    [] __hvm_copy+0xa8/0x300
(XEN)    [] pt_restore_timer+0x1f/0xd0
(XEN)    [] tasklet_enqueue+0xb0/0xc0
(XEN)    [] tasklet_schedule_on_cpu+0x7e/0x80
(XEN)    [] tasklet_schedule+0x22/0x30
(XEN)    [] evtchn_set_pending+0x7c/0x150
(XEN)    [] pt_update_irq+0x2e/0x230
(XEN)    [] hvm_vcpu_has_pending_irq+0x5a/0xc0
(XEN)    [] svm_intr_assist+0x40/0x1a0
(XEN)    [] __do_softirq+0x5f/0x90
(XEN)    [] svm_stgi_label+0x8/0x34
(XEN)
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 19:
(XEN) Xen BUG at common.c:1305
(XEN) ****************************************

--
Kind regards.

Conny Seidel

##################################################################
# Email : conny.seidel@amd.com            GnuPG-Key : 0xA6AB055D #
# Fingerprint: 17C4 5DB2 7C4C C1C7 1452 8148 F139 7C09 A6AB 055D #
##################################################################
# Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach      #
# General Managers: Alberto Bozzo                                #
# Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen #
#               HRB Nr. 43632                                    #
##################################################################

--Sig_/6620CtkCOMPtl+gap/ssX2a
Content-Type: application/pgp-signature; name="signature.asc"
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlB/6vQACgkQ8Tl8CaarBV2NogCdEgVRfceGIo4H98FjQGnVjdmJ
S0oAoOylNvQB/Vy+pjuuv84qWsmQkysC
=Wl2A
-----END PGP SIGNATURE-----

--Sig_/6620CtkCOMPtl+gap/ssX2a--


--===============3501566560696499167==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3501566560696499167==--


From xen-devel-bounces@lists.xen.org Thu Oct 18 11:45:07 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 11:45:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOoWr-0004EY-RI; Thu, 18 Oct 2012 11:44:45 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOoWq-0004ES-K7
	for Xen-devel@lists.xensource.com; Thu, 18 Oct 2012 11:44:44 +0000
Received: from [193.109.254.147:53160] by server-10.bemta-14.messagelabs.com
	id 23/C2-12590-BABEF705; Thu, 18 Oct 2012 11:44:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1350560680!10522792!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17059 invoked from network); 18 Oct 2012 11:44:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 11:44:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15252812"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 11:44:40 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 18 Oct 2012 12:44:40 +0100
Date: Thu, 18 Oct 2012 12:44:16 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Mukesh Rathor 
In-Reply-To: <20121017173327.6994152e@mantra.us.oracle.com>
Message-ID: 
References: <20121017173327.6994152e@mantra.us.oracle.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V3 5/6]: PVH:balloon and grant changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 18 Oct 2012, Mukesh Rathor wrote:
> PVH: balloon and grant changes. For balloon changes we skip setting of local p2m as it's updated in xen. For grant, the shared grant frame is the pfn and not mfn, hence its mapped via the same code path as HVM
> 
> Signed-off-by: Mukesh Rathor 

this patch looks good


>  drivers/xen/balloon.c     |   15 +++++++++------
>  drivers/xen/gntdev.c      |    3 ++-
>  drivers/xen/grant-table.c |   26 ++++++++++++++++++++++----
>  3 files changed, 33 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> index 31ab82f..c825b63 100644
> --- a/drivers/xen/balloon.c
> +++ b/drivers/xen/balloon.c
> @@ -361,7 +361,9 @@ static enum bp_state increase_reservation(unsigned long nr_pages)
>  		set_phys_to_machine(pfn, frame_list[i]);
>  
>  		/* Link back into the page tables if not highmem. */
> -		if (xen_pv_domain() && !PageHighMem(page)) {
> +		if (xen_pv_domain() && !PageHighMem(page) &&
> +		    !xen_feature(XENFEAT_auto_translated_physmap)) {
> +
>  			int ret;
>  			ret = HYPERVISOR_update_va_mapping(
>  				(unsigned long)__va(pfn << PAGE_SHIFT),
> @@ -418,12 +420,13 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
>  		scrub_page(page);
>  
>  		if (xen_pv_domain() && !PageHighMem(page)) {
> -			ret = HYPERVISOR_update_va_mapping(
> -				(unsigned long)__va(pfn << PAGE_SHIFT),
> -				__pte_ma(0), 0);
> -			BUG_ON(ret);
> +			if (!xen_feature(XENFEAT_auto_translated_physmap)) {
> +				ret = HYPERVISOR_update_va_mapping(
> +					(unsigned long)__va(pfn << PAGE_SHIFT),
> +					__pte_ma(0), 0);
> +				BUG_ON(ret);
> +			}
>  		}
> -
>  	}
>  
>  	/* Ensure that ballooned highmem pages don't have kmaps. */
> diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
> index 5df9fd8..36ec380 100644
> --- a/drivers/xen/gntdev.c
> +++ b/drivers/xen/gntdev.c
> @@ -803,7 +803,8 @@ static int __init gntdev_init(void)
>  	if (!xen_domain())
>  		return -ENODEV;
>  
> -	use_ptemod = xen_pv_domain();
> +	use_ptemod = xen_pv_domain() &&
> +		     !xen_feature(XENFEAT_auto_translated_physmap);
>  
>  	err = misc_register(&gntdev_miscdev);
>  	if (err != 0) {
> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> index f37faf6..1b851fa 100644
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -976,14 +976,19 @@ static void gnttab_unmap_frames_v2(void)
>  static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
>  {
>  	struct gnttab_setup_table setup;
> -	unsigned long *frames;
> +	unsigned long *frames, start_gpfn;
>  	unsigned int nr_gframes = end_idx + 1;
>  	int rc;
>  
> -	if (xen_hvm_domain()) {
> +	if (xen_hvm_domain() || xen_feature(XENFEAT_auto_translated_physmap)) {
>  		struct xen_add_to_physmap xatp;
>  		unsigned int i = end_idx;
>  		rc = 0;
> +
> +		if (xen_hvm_domain())
> +			start_gpfn = xen_hvm_resume_frames >> PAGE_SHIFT;
> +		else
> +			start_gpfn = virt_to_pfn(gnttab_shared.addr);
>  		/*
>  		 * Loop backwards, so that the first hypercall has the largest
>  		 * index, ensuring that the table will grow only once.
> @@ -992,7 +997,7 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
>  			xatp.domid = DOMID_SELF;
>  			xatp.idx = i;
>  			xatp.space = XENMAPSPACE_grant_table;
> -			xatp.gpfn = (xen_hvm_resume_frames >> PAGE_SHIFT) + i;
> +			xatp.gpfn = start_gpfn + i;
>  			rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
>  			if (rc != 0) {
>  				printk(KERN_WARNING
> @@ -1055,7 +1060,7 @@ static void gnttab_request_version(void)
>  	int rc;
>  	struct gnttab_set_version gsv;
>  
> -	if (xen_hvm_domain())
> +	if (xen_hvm_domain() || xen_feature(XENFEAT_auto_translated_physmap))
>  		gsv.version = 1;
>  	else
>  		gsv.version = 2;
> @@ -1083,12 +1088,25 @@ static void gnttab_request_version(void)
>  int gnttab_resume(void)
>  {
>  	unsigned int max_nr_gframes;
> +	char *kmsg = "Failed to kmalloc pages for pv in hvm grant frames\n";
>  
>  	gnttab_request_version();
>  	max_nr_gframes = gnttab_max_grant_frames();
>  	if (max_nr_gframes < nr_grant_frames)
>  		return -ENOSYS;
>  
> +	/* PVH note: xen will free existing kmalloc'd mfn in
> +	 * XENMEM_add_to_physmap. TBD/FIXME: use xen ballooning instead of
> +	 * kmalloc(). */
> +	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap) &&
> +	    !gnttab_shared.addr) {
> +		gnttab_shared.addr =
> +			kmalloc(max_nr_gframes * PAGE_SIZE, GFP_KERNEL);
> +		if (!gnttab_shared.addr) {
> +			pr_warn("%s", kmsg);
> +			return -ENOMEM;
> +		}
> +	}
>  	if (xen_pv_domain())
>  		return gnttab_map(0, nr_grant_frames - 1);
>  
> -- 
> 1.7.2.3
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 11:45:07 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 11:45:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOoWr-0004EY-RI; Thu, 18 Oct 2012 11:44:45 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOoWq-0004ES-K7
	for Xen-devel@lists.xensource.com; Thu, 18 Oct 2012 11:44:44 +0000
Received: from [193.109.254.147:53160] by server-10.bemta-14.messagelabs.com
	id 23/C2-12590-BABEF705; Thu, 18 Oct 2012 11:44:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1350560680!10522792!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17059 invoked from network); 18 Oct 2012 11:44:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 11:44:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15252812"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 11:44:40 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 18 Oct 2012 12:44:40 +0100
Date: Thu, 18 Oct 2012 12:44:16 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Mukesh Rathor 
In-Reply-To: <20121017173327.6994152e@mantra.us.oracle.com>
Message-ID: 
References: <20121017173327.6994152e@mantra.us.oracle.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V3 5/6]: PVH:balloon and grant changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 18 Oct 2012, Mukesh Rathor wrote:
> PVH: balloon and grant changes. For balloon changes we skip setting of local p2m as it's updated in xen. For grant, the shared grant frame is the pfn and not mfn, hence its mapped via the same code path as HVM
> 
> Signed-off-by: Mukesh Rathor 

this patch looks good


>  drivers/xen/balloon.c     |   15 +++++++++------
>  drivers/xen/gntdev.c      |    3 ++-
>  drivers/xen/grant-table.c |   26 ++++++++++++++++++++++----
>  3 files changed, 33 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> index 31ab82f..c825b63 100644
> --- a/drivers/xen/balloon.c
> +++ b/drivers/xen/balloon.c
> @@ -361,7 +361,9 @@ static enum bp_state increase_reservation(unsigned long nr_pages)
>  		set_phys_to_machine(pfn, frame_list[i]);
>  
>  		/* Link back into the page tables if not highmem. */
> -		if (xen_pv_domain() && !PageHighMem(page)) {
> +		if (xen_pv_domain() && !PageHighMem(page) &&
> +		    !xen_feature(XENFEAT_auto_translated_physmap)) {
> +
>  			int ret;
>  			ret = HYPERVISOR_update_va_mapping(
>  				(unsigned long)__va(pfn << PAGE_SHIFT),
> @@ -418,12 +420,13 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
>  		scrub_page(page);
>  
>  		if (xen_pv_domain() && !PageHighMem(page)) {
> -			ret = HYPERVISOR_update_va_mapping(
> -				(unsigned long)__va(pfn << PAGE_SHIFT),
> -				__pte_ma(0), 0);
> -			BUG_ON(ret);
> +			if (!xen_feature(XENFEAT_auto_translated_physmap)) {
> +				ret = HYPERVISOR_update_va_mapping(
> +					(unsigned long)__va(pfn << PAGE_SHIFT),
> +					__pte_ma(0), 0);
> +				BUG_ON(ret);
> +			}
>  		}
> -
>  	}
>  
>  	/* Ensure that ballooned highmem pages don't have kmaps. */
> diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
> index 5df9fd8..36ec380 100644
> --- a/drivers/xen/gntdev.c
> +++ b/drivers/xen/gntdev.c
> @@ -803,7 +803,8 @@ static int __init gntdev_init(void)
>  	if (!xen_domain())
>  		return -ENODEV;
>  
> -	use_ptemod = xen_pv_domain();
> +	use_ptemod = xen_pv_domain() &&
> +		     !xen_feature(XENFEAT_auto_translated_physmap);
>  
>  	err = misc_register(&gntdev_miscdev);
>  	if (err != 0) {
> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> index f37faf6..1b851fa 100644
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -976,14 +976,19 @@ static void gnttab_unmap_frames_v2(void)
>  static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
>  {
>  	struct gnttab_setup_table setup;
> -	unsigned long *frames;
> +	unsigned long *frames, start_gpfn;
>  	unsigned int nr_gframes = end_idx + 1;
>  	int rc;
>  
> -	if (xen_hvm_domain()) {
> +	if (xen_hvm_domain() || xen_feature(XENFEAT_auto_translated_physmap)) {
>  		struct xen_add_to_physmap xatp;
>  		unsigned int i = end_idx;
>  		rc = 0;
> +
> +		if (xen_hvm_domain())
> +			start_gpfn = xen_hvm_resume_frames >> PAGE_SHIFT;
> +		else
> +			start_gpfn = virt_to_pfn(gnttab_shared.addr);
>  		/*
>  		 * Loop backwards, so that the first hypercall has the largest
>  		 * index, ensuring that the table will grow only once.
> @@ -992,7 +997,7 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
>  			xatp.domid = DOMID_SELF;
>  			xatp.idx = i;
>  			xatp.space = XENMAPSPACE_grant_table;
> -			xatp.gpfn = (xen_hvm_resume_frames >> PAGE_SHIFT) + i;
> +			xatp.gpfn = start_gpfn + i;
>  			rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
>  			if (rc != 0) {
>  				printk(KERN_WARNING
> @@ -1055,7 +1060,7 @@ static void gnttab_request_version(void)
>  	int rc;
>  	struct gnttab_set_version gsv;
>  
> -	if (xen_hvm_domain())
> +	if (xen_hvm_domain() || xen_feature(XENFEAT_auto_translated_physmap))
>  		gsv.version = 1;
>  	else
>  		gsv.version = 2;
> @@ -1083,12 +1088,25 @@ static void gnttab_request_version(void)
>  int gnttab_resume(void)
>  {
>  	unsigned int max_nr_gframes;
> +	char *kmsg = "Failed to kmalloc pages for pv in hvm grant frames\n";
>  
>  	gnttab_request_version();
>  	max_nr_gframes = gnttab_max_grant_frames();
>  	if (max_nr_gframes < nr_grant_frames)
>  		return -ENOSYS;
>  
> +	/* PVH note: xen will free existing kmalloc'd mfn in
> +	 * XENMEM_add_to_physmap. TBD/FIXME: use xen ballooning instead of
> +	 * kmalloc(). */
> +	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap) &&
> +	    !gnttab_shared.addr) {
> +		gnttab_shared.addr =
> +			kmalloc(max_nr_gframes * PAGE_SIZE, GFP_KERNEL);
> +		if (!gnttab_shared.addr) {
> +			pr_warn("%s", kmsg);
> +			return -ENOMEM;
> +		}
> +	}
>  	if (xen_pv_domain())
>  		return gnttab_map(0, nr_grant_frames - 1);
>  
> -- 
> 1.7.2.3
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 11:52:54 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 11:52:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOoeP-0004R5-2H; Thu, 18 Oct 2012 11:52:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOoeN-0004R0-Rt
	for Xen-devel@lists.xensource.com; Thu, 18 Oct 2012 11:52:32 +0000
Received: from [85.158.138.51:40178] by server-13.bemta-3.messagelabs.com id
	26/7A-26794-F7DEF705; Thu, 18 Oct 2012 11:52:31 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1350561149!33077333!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29108 invoked from network); 18 Oct 2012 11:52:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 11:52:29 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15252989"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 11:52:29 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 18 Oct 2012 12:52:29 +0100
Date: Thu, 18 Oct 2012 12:52:05 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Mukesh Rathor 
In-Reply-To: <20121017173448.7ef4c0b1@mantra.us.oracle.com>
Message-ID: 
References: <20121017173448.7ef4c0b1@mantra.us.oracle.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V3 6/6]: PVH:privcmd changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 18 Oct 2012, Mukesh Rathor wrote:
> PVH: privcmd changes. PVH only supports the batch interface. To map a foreign page to a process, pfn must be allocated. PVH path uses ballooning for that purpose. The returned pfn is then mapped to the foreign page. xen_unmap_domain_mfn_range() is introduced to unmap these pages via the privcmd close call.
> 
> Signed-off-by: Mukesh Rathor 

this one also looks all right


>  drivers/xen/privcmd.c |   69 +++++++++++++++++++++++++++++++++++++++++++++++-
>  1 files changed, 67 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> index 63d9ee8..835166a 100644
> --- a/drivers/xen/privcmd.c
> +++ b/drivers/xen/privcmd.c
> @@ -33,11 +33,14 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "privcmd.h"
>  
>  MODULE_LICENSE("GPL");
>  
> +#define PRIV_VMA_LOCKED ((void *)1)
> +
>  #ifndef HAVE_ARCH_PRIVCMD_MMAP
>  static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma);
>  #endif
> @@ -199,6 +202,10 @@ static long privcmd_ioctl_mmap(void __user *udata)
>  	if (!xen_initial_domain())
>  		return -EPERM;
>  
> +	/* We only support privcmd_ioctl_mmap_batch for auto translated. */
> +	if (xen_feature(XENFEAT_auto_translated_physmap))
> +		return -ENOSYS;
> +
>  	if (copy_from_user(&mmapcmd, udata, sizeof(mmapcmd)))
>  		return -EFAULT;
>  
> @@ -246,6 +253,7 @@ struct mmap_batch_state {
>  	domid_t domain;
>  	unsigned long va;
>  	struct vm_area_struct *vma;
> +	int index;
>  	/* A tristate:
>  	 *      0 for no errors
>  	 *      1 if at least one error has happened (and no
> @@ -260,15 +268,24 @@ struct mmap_batch_state {
>  	xen_pfn_t __user *user_mfn;
>  };
>  
> +/* auto translated dom0 note: if domU being created is PV, then mfn is
> + * mfn(addr on bus). If it's auto xlated, then mfn is pfn (input to HAP).
> + */
>  static int mmap_batch_fn(void *data, void *state)
>  {
>  	xen_pfn_t *mfnp = data;
>  	struct mmap_batch_state *st = state;
> +	struct vm_area_struct *vma = st->vma;
> +	struct page **pages = vma->vm_private_data;
> +	struct page *cur_page = NULL;
>  	int ret;
>  
> +	if (xen_feature(XENFEAT_auto_translated_physmap))
> +		cur_page = pages[st->index++];
> +
>  	ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
>  					 st->vma->vm_page_prot, st->domain,
> -					 NULL);
> +					 &cur_page);
>  
>  	/* Store error code for second pass. */
>  	*(st->err++) = ret;
> @@ -304,6 +321,32 @@ static int mmap_return_errors_v1(void *data, void *state)
>  	return __put_user(*mfnp, st->user_mfn++);
>  }
>  
> +/* Allocate pfns that are then mapped with gmfns from foreign domid. Update
> + * the vma with the page info to use later.
> + * Returns: 0 if success, otherwise -errno
> + */
> +static int alloc_empty_pages(struct vm_area_struct *vma, int numpgs)
> +{
> +	int rc;
> +	struct page **pages;
> +
> +	pages = kcalloc(numpgs, sizeof(pages[0]), GFP_KERNEL);
> +	if (pages == NULL)
> +		return -ENOMEM;
> +
> +	rc = alloc_xenballooned_pages(numpgs, pages, 0);
> +	if (rc != 0) {
> +		pr_warn("%s Could not alloc %d pfns rc:%d\n", __func__,
> +			numpgs, rc);
> +		kfree(pages);
> +		return -ENOMEM;
> +	}
> +	BUG_ON(vma->vm_private_data != PRIV_VMA_LOCKED);
> +	vma->vm_private_data = pages;
> +
> +	return 0;
> +}
> +
>  static struct vm_operations_struct privcmd_vm_ops;
>  
>  static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
> @@ -371,10 +414,18 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
>  		up_write(&mm->mmap_sem);
>  		goto out;
>  	}
> +	if (xen_feature(XENFEAT_auto_translated_physmap)) {
> +		ret = alloc_empty_pages(vma, m.num);
> +		if (ret < 0) {
> +			up_write(&mm->mmap_sem);
> +			goto out;
> +		}
> +	}
>  
>  	state.domain        = m.dom;
>  	state.vma           = vma;
>  	state.va            = m.addr;
> +	state.index         = 0;
>  	state.global_error  = 0;
>  	state.err           = err_array;
>  
> @@ -439,6 +490,19 @@ static long privcmd_ioctl(struct file *file,
>  	return ret;
>  }
>  
> +static void privcmd_close(struct vm_area_struct *vma)
> +{
> +	struct page **pages = vma ? vma->vm_private_data : NULL;
> +	int numpgs = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
> +
> +	if (!pages || !numpgs || !xen_feature(XENFEAT_auto_translated_physmap))
> +		return;
> +
> +	xen_unmap_domain_mfn_range(vma, numpgs, pages);
> +	free_xenballooned_pages(numpgs, pages);
> +	kfree(pages);
> +}
> +
>  static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
>  {
>  	printk(KERN_DEBUG "privcmd_fault: vma=%p %lx-%lx, pgoff=%lx, uv=%p\n",
> @@ -449,6 +513,7 @@ static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
>  }
>  
>  static struct vm_operations_struct privcmd_vm_ops = {
> +	.close = privcmd_close,
>  	.fault = privcmd_fault
>  };
>  
> @@ -465,7 +530,7 @@ static int privcmd_mmap(struct file *file, struct vm_area_struct *vma)
>  
>  static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma)
>  {
> -	return (xchg(&vma->vm_private_data, (void *)1) == NULL);
> +	return !cmpxchg(&vma->vm_private_data, NULL, PRIV_VMA_LOCKED);
>  }
>  
>  const struct file_operations xen_privcmd_fops = {
> -- 
> 1.7.2.3
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 11:52:54 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 11:52:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOoeP-0004R5-2H; Thu, 18 Oct 2012 11:52:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOoeN-0004R0-Rt
	for Xen-devel@lists.xensource.com; Thu, 18 Oct 2012 11:52:32 +0000
Received: from [85.158.138.51:40178] by server-13.bemta-3.messagelabs.com id
	26/7A-26794-F7DEF705; Thu, 18 Oct 2012 11:52:31 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1350561149!33077333!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29108 invoked from network); 18 Oct 2012 11:52:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 11:52:29 -0000
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="15252989"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 11:52:29 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 18 Oct 2012 12:52:29 +0100
Date: Thu, 18 Oct 2012 12:52:05 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Mukesh Rathor 
In-Reply-To: <20121017173448.7ef4c0b1@mantra.us.oracle.com>
Message-ID: 
References: <20121017173448.7ef4c0b1@mantra.us.oracle.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V3 6/6]: PVH:privcmd changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 18 Oct 2012, Mukesh Rathor wrote:
> PVH: privcmd changes. PVH only supports the batch interface. To map a foreign page to a process, pfn must be allocated. PVH path uses ballooning for that purpose. The returned pfn is then mapped to the foreign page. xen_unmap_domain_mfn_range() is introduced to unmap these pages via the privcmd close call.
> 
> Signed-off-by: Mukesh Rathor 

this one also looks all right


>  drivers/xen/privcmd.c |   69 +++++++++++++++++++++++++++++++++++++++++++++++-
>  1 files changed, 67 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> index 63d9ee8..835166a 100644
> --- a/drivers/xen/privcmd.c
> +++ b/drivers/xen/privcmd.c
> @@ -33,11 +33,14 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "privcmd.h"
>  
>  MODULE_LICENSE("GPL");
>  
> +#define PRIV_VMA_LOCKED ((void *)1)
> +
>  #ifndef HAVE_ARCH_PRIVCMD_MMAP
>  static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma);
>  #endif
> @@ -199,6 +202,10 @@ static long privcmd_ioctl_mmap(void __user *udata)
>  	if (!xen_initial_domain())
>  		return -EPERM;
>  
> +	/* We only support privcmd_ioctl_mmap_batch for auto translated. */
> +	if (xen_feature(XENFEAT_auto_translated_physmap))
> +		return -ENOSYS;
> +
>  	if (copy_from_user(&mmapcmd, udata, sizeof(mmapcmd)))
>  		return -EFAULT;
>  
> @@ -246,6 +253,7 @@ struct mmap_batch_state {
>  	domid_t domain;
>  	unsigned long va;
>  	struct vm_area_struct *vma;
> +	int index;
>  	/* A tristate:
>  	 *      0 for no errors
>  	 *      1 if at least one error has happened (and no
> @@ -260,15 +268,24 @@ struct mmap_batch_state {
>  	xen_pfn_t __user *user_mfn;
>  };
>  
> +/* auto translated dom0 note: if domU being created is PV, then mfn is
> + * mfn(addr on bus). If it's auto xlated, then mfn is pfn (input to HAP).
> + */
>  static int mmap_batch_fn(void *data, void *state)
>  {
>  	xen_pfn_t *mfnp = data;
>  	struct mmap_batch_state *st = state;
> +	struct vm_area_struct *vma = st->vma;
> +	struct page **pages = vma->vm_private_data;
> +	struct page *cur_page = NULL;
>  	int ret;
>  
> +	if (xen_feature(XENFEAT_auto_translated_physmap))
> +		cur_page = pages[st->index++];
> +
>  	ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
>  					 st->vma->vm_page_prot, st->domain,
> -					 NULL);
> +					 &cur_page);
>  
>  	/* Store error code for second pass. */
>  	*(st->err++) = ret;
> @@ -304,6 +321,32 @@ static int mmap_return_errors_v1(void *data, void *state)
>  	return __put_user(*mfnp, st->user_mfn++);
>  }
>  
> +/* Allocate pfns that are then mapped with gmfns from foreign domid. Update
> + * the vma with the page info to use later.
> + * Returns: 0 if success, otherwise -errno
> + */
> +static int alloc_empty_pages(struct vm_area_struct *vma, int numpgs)
> +{
> +	int rc;
> +	struct page **pages;
> +
> +	pages = kcalloc(numpgs, sizeof(pages[0]), GFP_KERNEL);
> +	if (pages == NULL)
> +		return -ENOMEM;
> +
> +	rc = alloc_xenballooned_pages(numpgs, pages, 0);
> +	if (rc != 0) {
> +		pr_warn("%s Could not alloc %d pfns rc:%d\n", __func__,
> +			numpgs, rc);
> +		kfree(pages);
> +		return -ENOMEM;
> +	}
> +	BUG_ON(vma->vm_private_data != PRIV_VMA_LOCKED);
> +	vma->vm_private_data = pages;
> +
> +	return 0;
> +}
> +
>  static struct vm_operations_struct privcmd_vm_ops;
>  
>  static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
> @@ -371,10 +414,18 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
>  		up_write(&mm->mmap_sem);
>  		goto out;
>  	}
> +	if (xen_feature(XENFEAT_auto_translated_physmap)) {
> +		ret = alloc_empty_pages(vma, m.num);
> +		if (ret < 0) {
> +			up_write(&mm->mmap_sem);
> +			goto out;
> +		}
> +	}
>  
>  	state.domain        = m.dom;
>  	state.vma           = vma;
>  	state.va            = m.addr;
> +	state.index         = 0;
>  	state.global_error  = 0;
>  	state.err           = err_array;
>  
> @@ -439,6 +490,19 @@ static long privcmd_ioctl(struct file *file,
>  	return ret;
>  }
>  
> +static void privcmd_close(struct vm_area_struct *vma)
> +{
> +	struct page **pages = vma ? vma->vm_private_data : NULL;
> +	int numpgs = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
> +
> +	if (!pages || !numpgs || !xen_feature(XENFEAT_auto_translated_physmap))
> +		return;
> +
> +	xen_unmap_domain_mfn_range(vma, numpgs, pages);
> +	free_xenballooned_pages(numpgs, pages);
> +	kfree(pages);
> +}
> +
>  static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
>  {
>  	printk(KERN_DEBUG "privcmd_fault: vma=%p %lx-%lx, pgoff=%lx, uv=%p\n",
> @@ -449,6 +513,7 @@ static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
>  }
>  
>  static struct vm_operations_struct privcmd_vm_ops = {
> +	.close = privcmd_close,
>  	.fault = privcmd_fault
>  };
>  
> @@ -465,7 +530,7 @@ static int privcmd_mmap(struct file *file, struct vm_area_struct *vma)
>  
>  static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma)
>  {
> -	return (xchg(&vma->vm_private_data, (void *)1) == NULL);
> +	return !cmpxchg(&vma->vm_private_data, NULL, PRIV_VMA_LOCKED);
>  }
>  
>  const struct file_operations xen_privcmd_fops = {
> -- 
> 1.7.2.3
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 12:08:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 12:08:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOotP-0004qD-1p; Thu, 18 Oct 2012 12:08:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOotO-0004q8-2a
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 12:08:02 +0000
Received: from [193.109.254.147:28304] by server-9.bemta-14.messagelabs.com id
	A1/05-09620-121FF705; Thu, 18 Oct 2012 12:08:01 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1350562010!3304692!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31065 invoked from network); 18 Oct 2012 12:06:51 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 12:06:51 -0000
Received: by mail-vb0-f45.google.com with SMTP id p1so10580021vbi.32
	for ; Thu, 18 Oct 2012 05:06:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=b5jLbf/jRvnTiKi79BnsehajoKBx8gO6JYb2dyUSZEY=;
	b=fvzD+0qW2O6XQkT65HH/bdQ3TnCpbE3Ip+h+s9ndcqtSivNB2wagJ8lyERlV9niBSm
	OujxybSbk3ULS0ANUmVzRkb3384u8im+j3Auzd7IFXzt1En5jKPl2t6cqTVl0vczktWM
	w1i8Fu/Ji/gk+Qu7Ci38TeuFZEKpPqKuNVcAnPVB1Q1snc7PG3rWVqSFbw6expe2YFNC
	JzDfAvrlo1ONlQGELauwu10BSkwkRVjZ+s4rWoZ46Zolhy7/ZTIzP0hZnRWT6LH2zFAz
	EpBOl3f7n7w35WTgWkfS81oIVTkOo1jIvXO/F9mPFkN3u3NYEzCqQumrRZQosWnkfgCA
	KHBw==
Received: by 10.58.116.175 with SMTP id jx15mr14956110veb.6.1350562009829;
	Thu, 18 Oct 2012 05:06:49 -0700 (PDT)
Received: from localhost.localdomain
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id zx18sm3433500veb.3.2012.10.18.05.06.48
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 18 Oct 2012 05:06:49 -0700 (PDT)
Date: Thu, 18 Oct 2012 08:06:29 -0400
From: Konrad Rzeszutek Wilk 
To: Zhenzhong Duan 
Message-ID: <20121018120627.GA13485@localhost.localdomain>
References: <507FBE7F.3010403@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <507FBE7F.3010403@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Ethan Zhao , Feng Jin ,
	xen-devel 
Subject: Re: [Xen-devel] ask a question about ERST
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Oct 18, 2012 at 04:31:59PM +0800, Zhenzhong Duan wrote:
> Hi maintainer,
> I found below patch reverted part of erst header size check.
> This lead to mismatch with kernel upstream code and erst disabled on
> some machine like X4170 M3/X3-2.
> According to the ACPI spec 4.0 and 5.0, the Serialization Header Length
> should be the length of Serialization Header.
> After revert below patch, xen succeed with erst table init.
> So could this patch be reverted now to match acpi spec and kernel upstream?

There was a discussion about this on xen-devel. Search for Jan and ERST
and I believe the idea was that an AMD machine needs to be checked
to figure out what to do.

> 
> [root@zhenzhong2 xen-unstable.hg]# hg export 23760
> # HG changeset patch
> # User Keir Fraser 
> # Date 1312909603 -3600
> # Node ID ae10d7804168c185166277bcef3b18ffc9227b66
> # Parent aca07ff1f0a59cc7ebb5ef76875229b7e99ba3ff
> ACPI ERST: Revert change to erst_check_table() to be more permissive.
> 
> Permits tables that apparently Xen cannot handle (causes boot failure
> on many systems).
> 
> Signed-off-by: Keir Fraser 
> 
> diff -r aca07ff1f0a5 -r ae10d7804168 xen/drivers/acpi/apei/erst.c
> --- a/xen/drivers/acpi/apei/erst.c Tue Aug 09 17:48:16 2011 +0100
> +++ b/xen/drivers/acpi/apei/erst.c Tue Aug 09 18:06:43 2011 +0100
> @@ -715,13 +715,7 @@
> 
> static int __init erst_check_table(struct acpi_table_erst *erst_tab)
> {
> - /*
> - * Some old BIOSes include the ACPI standard header in the ERST header
> - * length; new BIOSes do not. Our check allows for both methods.
> - */
> - if ((erst_tab->header_length !=
> - (sizeof(struct acpi_table_erst) - sizeof(erst_tab->header)))
> - && (erst_tab->header_length != sizeof(struct acpi_table_erst)))
> + if (erst_tab->header_length != sizeof(struct acpi_table_erst))
> return -EINVAL;
> if (erst_tab->header.length < sizeof(struct acpi_table_erst))
> return -EINVAL;

Gosh, your mailer mangled that patch :-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 12:08:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 12:08:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOotP-0004qD-1p; Thu, 18 Oct 2012 12:08:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOotO-0004q8-2a
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 12:08:02 +0000
Received: from [193.109.254.147:28304] by server-9.bemta-14.messagelabs.com id
	A1/05-09620-121FF705; Thu, 18 Oct 2012 12:08:01 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1350562010!3304692!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31065 invoked from network); 18 Oct 2012 12:06:51 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 12:06:51 -0000
Received: by mail-vb0-f45.google.com with SMTP id p1so10580021vbi.32
	for ; Thu, 18 Oct 2012 05:06:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=b5jLbf/jRvnTiKi79BnsehajoKBx8gO6JYb2dyUSZEY=;
	b=fvzD+0qW2O6XQkT65HH/bdQ3TnCpbE3Ip+h+s9ndcqtSivNB2wagJ8lyERlV9niBSm
	OujxybSbk3ULS0ANUmVzRkb3384u8im+j3Auzd7IFXzt1En5jKPl2t6cqTVl0vczktWM
	w1i8Fu/Ji/gk+Qu7Ci38TeuFZEKpPqKuNVcAnPVB1Q1snc7PG3rWVqSFbw6expe2YFNC
	JzDfAvrlo1ONlQGELauwu10BSkwkRVjZ+s4rWoZ46Zolhy7/ZTIzP0hZnRWT6LH2zFAz
	EpBOl3f7n7w35WTgWkfS81oIVTkOo1jIvXO/F9mPFkN3u3NYEzCqQumrRZQosWnkfgCA
	KHBw==
Received: by 10.58.116.175 with SMTP id jx15mr14956110veb.6.1350562009829;
	Thu, 18 Oct 2012 05:06:49 -0700 (PDT)
Received: from localhost.localdomain
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id zx18sm3433500veb.3.2012.10.18.05.06.48
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 18 Oct 2012 05:06:49 -0700 (PDT)
Date: Thu, 18 Oct 2012 08:06:29 -0400
From: Konrad Rzeszutek Wilk 
To: Zhenzhong Duan 
Message-ID: <20121018120627.GA13485@localhost.localdomain>
References: <507FBE7F.3010403@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <507FBE7F.3010403@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Ethan Zhao , Feng Jin ,
	xen-devel 
Subject: Re: [Xen-devel] ask a question about ERST
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Oct 18, 2012 at 04:31:59PM +0800, Zhenzhong Duan wrote:
> Hi maintainer,
> I found below patch reverted part of erst header size check.
> This lead to mismatch with kernel upstream code and erst disabled on
> some machine like X4170 M3/X3-2.
> According to the ACPI spec 4.0 and 5.0, the Serialization Header Length
> should be the length of Serialization Header.
> After revert below patch, xen succeed with erst table init.
> So could this patch be reverted now to match acpi spec and kernel upstream?

There was a discussion about this on xen-devel. Search for Jan and ERST
and I believe the idea was that an AMD machine needs to be checked
to figure out what to do.

> 
> [root@zhenzhong2 xen-unstable.hg]# hg export 23760
> # HG changeset patch
> # User Keir Fraser 
> # Date 1312909603 -3600
> # Node ID ae10d7804168c185166277bcef3b18ffc9227b66
> # Parent aca07ff1f0a59cc7ebb5ef76875229b7e99ba3ff
> ACPI ERST: Revert change to erst_check_table() to be more permissive.
> 
> Permits tables that apparently Xen cannot handle (causes boot failure
> on many systems).
> 
> Signed-off-by: Keir Fraser 
> 
> diff -r aca07ff1f0a5 -r ae10d7804168 xen/drivers/acpi/apei/erst.c
> --- a/xen/drivers/acpi/apei/erst.c Tue Aug 09 17:48:16 2011 +0100
> +++ b/xen/drivers/acpi/apei/erst.c Tue Aug 09 18:06:43 2011 +0100
> @@ -715,13 +715,7 @@
> 
> static int __init erst_check_table(struct acpi_table_erst *erst_tab)
> {
> - /*
> - * Some old BIOSes include the ACPI standard header in the ERST header
> - * length; new BIOSes do not. Our check allows for both methods.
> - */
> - if ((erst_tab->header_length !=
> - (sizeof(struct acpi_table_erst) - sizeof(erst_tab->header)))
> - && (erst_tab->header_length != sizeof(struct acpi_table_erst)))
> + if (erst_tab->header_length != sizeof(struct acpi_table_erst))
> return -EINVAL;
> if (erst_tab->header.length < sizeof(struct acpi_table_erst))
> return -EINVAL;

Gosh, your mailer mangled that patch :-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 12:43:48 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 12:43:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOpRa-000592-GO; Thu, 18 Oct 2012 12:43:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOpRZ-00058x-S6
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 12:43:22 +0000
Received: from [85.158.139.211:19681] by server-13.bemta-5.messagelabs.com id
	37/BC-30674-969FF705; Thu, 18 Oct 2012 12:43:21 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1350564200!21312496!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7854 invoked from network); 18 Oct 2012 12:43:20 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-9.tower-206.messagelabs.com with SMTP;
	18 Oct 2012 12:43:20 -0000
Received: from p5b2e3cc2.dip.t-dialin.net ([91.46.60.194] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from )
	id 1TOpRV-00056g-RW; Thu, 18 Oct 2012 12:43:17 +0000
Message-ID: <507FF964.9090009@canonical.com>
Date: Thu, 18 Oct 2012 14:43:16 +0200
From: Stefan Bader 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Jan Beulich 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
	<1350482118.2460.74.camel@zakaz.uk.xensource.com>
	<507ECD06.2050407@canonical.com> <507ED038.8000806@citrix.com>
	<507FC51102000078000A235E@nat28.tlf.novell.com>
	<507FC71502000078000A236C@nat28.tlf.novell.com>
	<507FB1E1.8080700@canonical.com>
	<1350546483.28188.25.camel@dagon.hellion.org.uk>
	<507FD7DE.2010209@canonical.com>
	<507FFA5102000078000A250D@nat28.tlf.novell.com>
In-Reply-To: <507FFA5102000078000A250D@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.5
Cc: Andrew Cooper ,
	Konrad Rzeszutek Wilk ,
	Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============7077398237862403059=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============7077398237862403059==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enigB9EE666080330C7C1DAF7137"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigB9EE666080330C7C1DAF7137
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 18.10.2012 12:47, Jan Beulich wrote:
>>>> On 18.10.12 at 12:20, Stefan Bader  wrot=
e:
>> On 18.10.2012 09:48, Ian Campbell wrote:
>>> spinning_lock() returns the old lock which the caller is expected to
>>> remember and replace via unspinning_lock() -- it effectively implemen=
ts
>>> a stack of locks which are being waited on. xen_spin_lock_slow (the o=
nly
>>> caller0 appears to do this correctly from a brief inspection.
>>
>> Yes, just *when* can there be a stack of locks (spinlocks). The poll_i=
rq
>> hypercall seems to be an active (in the sense of not preemting to anot=
her=20
>> task)
>> process. How could there be a situation that another lock (on the same=
 cpu=20
>> is tried to be taken).
>=20
> Obviously when this is an acquire not disabling interrupts, and
> an interrupt comes in while in the poll hypercall (or about to go
> there, or just having come back from one).
>=20
> Jan
>=20
Obviously. ;) Ok, so my thinking there was ok and its one level deep max.=
 At
some point staring at things I start question my sanity.
A wild thinking would be whether in that case the interrupted spinlock ma=
y miss
a wakeup forever when the unlocker only can check for the toplevel. Hm, b=
ut that
should be easy to rule out by just adding an error to spin_unlock_slow wh=
en it
fails to find anything...



--------------enigB9EE666080330C7C1DAF7137
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBCgAGBQJQf/lkAAoJEOhnXe7L7s6jYAgP/jIqqQosyyCp/wdPBclVSws3
qK4wLJYOdJWuiWMNMSxgob2eXmWRdThh4MvGM73PH54QOsoynd0aafd8aOAiJ0Hu
GPvRRdIPjh3zFK78WAcIr6NAwaYwNwrIecbvqtBzjjVDgFuDImCqq9dmRwfWekAW
NF422nKmcHQYTEL2lSDs/vqjF27rsNrtZP6cISStxnu70YXBzaSextob/jBbGkd6
GSJovcirPG0yG1piYJYBO99neUKpibqEWOQOqZPFa0jpzCsRlpPkIvLf4vyrIZsK
zuPKp1gGtHj5WBhNlrHhLN9Jp90qBjL5ZV4nmC3LUwMax4zayOXU4zu0rkbJC5RP
KigYCYEL1E068nxAF80jzm88H6aGGGy09gRWxYxVGBJby8q7pDmP0FxMbopMfGBF
bCAEj8Wie7pXz1JfrXJRXfAxj0QAnutWbfKNESCgs6/yg3wzDIPgtYLGLNPHnQD9
XlII3jf4Zb+8tfi0Q0d2/wOyj8mwwwqOXk27mGiUNTU4HNHaunOvCssKJJLe4hyS
4cN7BShxXmLpNjm4iXI9T2xxrnpeuwRA+yg36yEM7GqwCioYnO6Q8se6d56bSf5X
ciU+UGMOQxCjjUBVLBeseIFr8ke+KC+sCsCvJVBAKkGXOHgmYaBjfvUcfHu4jpAR
BlFKUuadDSPm8uG5dp4N
=Mvbw
-----END PGP SIGNATURE-----

--------------enigB9EE666080330C7C1DAF7137--


--===============7077398237862403059==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7077398237862403059==--


From xen-devel-bounces@lists.xen.org Thu Oct 18 12:43:48 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 12:43:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOpRa-000592-GO; Thu, 18 Oct 2012 12:43:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOpRZ-00058x-S6
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 12:43:22 +0000
Received: from [85.158.139.211:19681] by server-13.bemta-5.messagelabs.com id
	37/BC-30674-969FF705; Thu, 18 Oct 2012 12:43:21 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1350564200!21312496!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7854 invoked from network); 18 Oct 2012 12:43:20 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-9.tower-206.messagelabs.com with SMTP;
	18 Oct 2012 12:43:20 -0000
Received: from p5b2e3cc2.dip.t-dialin.net ([91.46.60.194] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from )
	id 1TOpRV-00056g-RW; Thu, 18 Oct 2012 12:43:17 +0000
Message-ID: <507FF964.9090009@canonical.com>
Date: Thu, 18 Oct 2012 14:43:16 +0200
From: Stefan Bader 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Jan Beulich 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
	<1350482118.2460.74.camel@zakaz.uk.xensource.com>
	<507ECD06.2050407@canonical.com> <507ED038.8000806@citrix.com>
	<507FC51102000078000A235E@nat28.tlf.novell.com>
	<507FC71502000078000A236C@nat28.tlf.novell.com>
	<507FB1E1.8080700@canonical.com>
	<1350546483.28188.25.camel@dagon.hellion.org.uk>
	<507FD7DE.2010209@canonical.com>
	<507FFA5102000078000A250D@nat28.tlf.novell.com>
In-Reply-To: <507FFA5102000078000A250D@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.5
Cc: Andrew Cooper ,
	Konrad Rzeszutek Wilk ,
	Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============7077398237862403059=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============7077398237862403059==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enigB9EE666080330C7C1DAF7137"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigB9EE666080330C7C1DAF7137
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 18.10.2012 12:47, Jan Beulich wrote:
>>>> On 18.10.12 at 12:20, Stefan Bader  wrot=
e:
>> On 18.10.2012 09:48, Ian Campbell wrote:
>>> spinning_lock() returns the old lock which the caller is expected to
>>> remember and replace via unspinning_lock() -- it effectively implemen=
ts
>>> a stack of locks which are being waited on. xen_spin_lock_slow (the o=
nly
>>> caller0 appears to do this correctly from a brief inspection.
>>
>> Yes, just *when* can there be a stack of locks (spinlocks). The poll_i=
rq
>> hypercall seems to be an active (in the sense of not preemting to anot=
her=20
>> task)
>> process. How could there be a situation that another lock (on the same=
 cpu=20
>> is tried to be taken).
>=20
> Obviously when this is an acquire not disabling interrupts, and
> an interrupt comes in while in the poll hypercall (or about to go
> there, or just having come back from one).
>=20
> Jan
>=20
Obviously. ;) Ok, so my thinking there was ok and its one level deep max.=
 At
some point staring at things I start question my sanity.
A wild thinking would be whether in that case the interrupted spinlock ma=
y miss
a wakeup forever when the unlocker only can check for the toplevel. Hm, b=
ut that
should be easy to rule out by just adding an error to spin_unlock_slow wh=
en it
fails to find anything...



--------------enigB9EE666080330C7C1DAF7137
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBCgAGBQJQf/lkAAoJEOhnXe7L7s6jYAgP/jIqqQosyyCp/wdPBclVSws3
qK4wLJYOdJWuiWMNMSxgob2eXmWRdThh4MvGM73PH54QOsoynd0aafd8aOAiJ0Hu
GPvRRdIPjh3zFK78WAcIr6NAwaYwNwrIecbvqtBzjjVDgFuDImCqq9dmRwfWekAW
NF422nKmcHQYTEL2lSDs/vqjF27rsNrtZP6cISStxnu70YXBzaSextob/jBbGkd6
GSJovcirPG0yG1piYJYBO99neUKpibqEWOQOqZPFa0jpzCsRlpPkIvLf4vyrIZsK
zuPKp1gGtHj5WBhNlrHhLN9Jp90qBjL5ZV4nmC3LUwMax4zayOXU4zu0rkbJC5RP
KigYCYEL1E068nxAF80jzm88H6aGGGy09gRWxYxVGBJby8q7pDmP0FxMbopMfGBF
bCAEj8Wie7pXz1JfrXJRXfAxj0QAnutWbfKNESCgs6/yg3wzDIPgtYLGLNPHnQD9
XlII3jf4Zb+8tfi0Q0d2/wOyj8mwwwqOXk27mGiUNTU4HNHaunOvCssKJJLe4hyS
4cN7BShxXmLpNjm4iXI9T2xxrnpeuwRA+yg36yEM7GqwCioYnO6Q8se6d56bSf5X
ciU+UGMOQxCjjUBVLBeseIFr8ke+KC+sCsCvJVBAKkGXOHgmYaBjfvUcfHu4jpAR
BlFKUuadDSPm8uG5dp4N
=Mvbw
-----END PGP SIGNATURE-----

--------------enigB9EE666080330C7C1DAF7137--


--===============7077398237862403059==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7077398237862403059==--


From xen-devel-bounces@lists.xen.org Thu Oct 18 13:12:26 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 13:12:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOpsY-0005UQ-85; Thu, 18 Oct 2012 13:11:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOpsW-0005UL-FJ
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 13:11:12 +0000
Received: from [85.158.139.83:33484] by server-12.bemta-5.messagelabs.com id
	D7/2B-26919-FEFFF705; Thu, 18 Oct 2012 13:11:11 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1350565870!30918446!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29658 invoked from network); 18 Oct 2012 13:11:10 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 13:11:10 -0000
X-IronPort-AV: E=Sophos;i="4.80,607,1344211200"; 
	d="asc'?scan'208";a="15255004"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 13:11:10 +0000
Received: from [IPv6:::1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 14:11:10 +0100
Message-ID: <1350565867.24760.9.camel@Abyss>
From: Dario Faggioli 
To: Ian Campbell 
Date: Thu, 18 Oct 2012 15:11:07 +0200
In-Reply-To: <1350559390.2460.124.camel@zakaz.uk.xensource.com>
References: 
	<6d7a403305dd057f61bd.1350408388@Solace>
	<1350559390.2460.124.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
MIME-Version: 1.0
Cc: Andre Przywara ,
	Ian Jackson ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 3 of 3] xl: allow for node-wise
 specification of vcpu pinning
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1955831591141418740=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1955831591141418740==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-TqI0ElFErC3rnAjyLiYJ"

--=-TqI0ElFErC3rnAjyLiYJ
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-10-18 at 12:23 +0100, Ian Campbell wrote:=20
> On Tue, 2012-10-16 at 18:26 +0100, Dario Faggioli wrote:
>=20
> > +            isnot =3D 1;
> > +        }
> > +        /* Check if we're dealing with a full node */
> > +        if (strstr(toka, "node:") =3D=3D toka || strstr(toka, "nodes:"=
) =3D=3D toka) {
>=20
> Isn't strstr(FOO, "thing") =3D=3D FOO just an expensive way of writing
> strncmp(FOO, "ting", sizeof(...))?
>=20
Mmm... what I wanted was to make sure that "thing" not only is part of
FOO, but that also is the very beginning of that same string. That's why
I exploited the fact that strstr() returns a pointer to the beginning of
the substring "thing" within FOO.

Now that you mentioned it, I think that I actually can achieve the same
with strncmp, limiting the comparison at strlen("thing"). If that was
what you meant, the answer is yes, I can do that (and I agree it's
probably better).

Thanks for looking into this,
Dario

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-TqI0ElFErC3rnAjyLiYJ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlB//+wACgkQk4XaBE3IOsSjwQCeJL44zfytkembqsXxhVxceXET
BoQAoIge9m39HwaQnwhR8hVogmu02mYV
=iwqb
-----END PGP SIGNATURE-----

--=-TqI0ElFErC3rnAjyLiYJ--


--===============1955831591141418740==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1955831591141418740==--


From xen-devel-bounces@lists.xen.org Thu Oct 18 13:12:26 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 13:12:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOpsY-0005UQ-85; Thu, 18 Oct 2012 13:11:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOpsW-0005UL-FJ
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 13:11:12 +0000
Received: from [85.158.139.83:33484] by server-12.bemta-5.messagelabs.com id
	D7/2B-26919-FEFFF705; Thu, 18 Oct 2012 13:11:11 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1350565870!30918446!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29658 invoked from network); 18 Oct 2012 13:11:10 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 13:11:10 -0000
X-IronPort-AV: E=Sophos;i="4.80,607,1344211200"; 
	d="asc'?scan'208";a="15255004"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 13:11:10 +0000
Received: from [IPv6:::1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 14:11:10 +0100
Message-ID: <1350565867.24760.9.camel@Abyss>
From: Dario Faggioli 
To: Ian Campbell 
Date: Thu, 18 Oct 2012 15:11:07 +0200
In-Reply-To: <1350559390.2460.124.camel@zakaz.uk.xensource.com>
References: 
	<6d7a403305dd057f61bd.1350408388@Solace>
	<1350559390.2460.124.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
MIME-Version: 1.0
Cc: Andre Przywara ,
	Ian Jackson ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 3 of 3] xl: allow for node-wise
 specification of vcpu pinning
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1955831591141418740=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1955831591141418740==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-TqI0ElFErC3rnAjyLiYJ"

--=-TqI0ElFErC3rnAjyLiYJ
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-10-18 at 12:23 +0100, Ian Campbell wrote:=20
> On Tue, 2012-10-16 at 18:26 +0100, Dario Faggioli wrote:
>=20
> > +            isnot =3D 1;
> > +        }
> > +        /* Check if we're dealing with a full node */
> > +        if (strstr(toka, "node:") =3D=3D toka || strstr(toka, "nodes:"=
) =3D=3D toka) {
>=20
> Isn't strstr(FOO, "thing") =3D=3D FOO just an expensive way of writing
> strncmp(FOO, "ting", sizeof(...))?
>=20
Mmm... what I wanted was to make sure that "thing" not only is part of
FOO, but that also is the very beginning of that same string. That's why
I exploited the fact that strstr() returns a pointer to the beginning of
the substring "thing" within FOO.

Now that you mentioned it, I think that I actually can achieve the same
with strncmp, limiting the comparison at strlen("thing"). If that was
what you meant, the answer is yes, I can do that (and I agree it's
probably better).

Thanks for looking into this,
Dario

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-TqI0ElFErC3rnAjyLiYJ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlB//+wACgkQk4XaBE3IOsSjwQCeJL44zfytkembqsXxhVxceXET
BoQAoIge9m39HwaQnwhR8hVogmu02mYV
=iwqb
-----END PGP SIGNATURE-----

--=-TqI0ElFErC3rnAjyLiYJ--


--===============1955831591141418740==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1955831591141418740==--


From xen-devel-bounces@lists.xen.org Thu Oct 18 13:12:38 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 13:12:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOpt9-0005Vg-MR; Thu, 18 Oct 2012 13:11:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOpt7-0005VX-La
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 13:11:49 +0000
Received: from [85.158.139.83:44885] by server-1.bemta-5.messagelabs.com id
	3A/1B-21640-41000805; Thu, 18 Oct 2012 13:11:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1350565907!35276439!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 476 invoked from network); 18 Oct 2012 13:11:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 13:11:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,607,1344211200"; d="scan'208";a="15255027"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 13:11:47 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 18 Oct 2012 14:11:47 +0100
Date: Thu, 18 Oct 2012 14:11:23 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1350473532-15863-1-git-send-email-ian.campbell@citrix.com>
Message-ID: 
References: <1350473518.2460.58.camel@zakaz.uk.xensource.com>
	<1350473532-15863-1-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	"xen-devel@lists.xen.org" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 1/6] xen: balloon: allow PVMMU interfaces to
 be compiled out
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 17 Oct 2012, Ian Campbell wrote:
> The ARM platform has no concept of PVMMU and therefor no
> HYPERVISOR_update_va_mapping et al. Allow this code to be compiled out
> when not required.
> 
> In some similar situations (e.g. P2M) we have defined dummy functions
> to avoid this, however I think we can/should draw the line at dummying
> out actual hypercalls.
> 
> Signed-off-by: Ian Campbell 

It is OK for me


>  arch/x86/xen/Kconfig  |    1 +
>  drivers/xen/Kconfig   |    3 +++
>  drivers/xen/balloon.c |    4 ++++
>  3 files changed, 8 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> index 9323b8c..6d101a1 100644
> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@ -6,6 +6,7 @@ config XEN
>  	bool "Xen guest support"
>  	select PARAVIRT
>  	select PARAVIRT_CLOCK
> +	select XEN_HAVE_PVMMU
>  	depends on X86_64 || (X86_32 && X86_PAE && !X86_VISWS)
>  	depends on X86_CMPXCHG && X86_TSC
>  	help
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index d4dffcd..9c00652 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -204,4 +204,7 @@ config XEN_MCE_LOG
>  	  Allow kernel fetching MCE error from Xen platform and
>  	  converting it into Linux mcelog format for mcelog tools
>  
> +config XEN_HAVE_PVMMU
> +       bool
> +
>  endmenu
> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> index db3aa34..92449a0 100644
> --- a/drivers/xen/balloon.c
> +++ b/drivers/xen/balloon.c
> @@ -360,6 +360,7 @@ static enum bp_state increase_reservation(unsigned long nr_pages)
>  		if (!xen_feature(XENFEAT_auto_translated_physmap))
>  			set_phys_to_machine(pfn, frame_list[i]);
>  
> +#ifdef CONFIG_XEN_HAVE_PVMMU
>  		/* Link back into the page tables if not highmem. */
>  		if (xen_pv_domain() && !PageHighMem(page) &&
>  		    !xen_feature(XENFEAT_auto_translated_physmap)) {
> @@ -371,6 +372,7 @@ static enum bp_state increase_reservation(unsigned long nr_pages)
>  				0);
>  			BUG_ON(ret);
>  		}
> +#endif
>  
>  		/* Relinquish the page back to the allocator. */
>  		ClearPageReserved(page);
> @@ -419,6 +421,7 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
>  
>  		scrub_page(page);
>  
> +#ifdef CONFIG_XEN_HAVE_PVMMU
>  		if (xen_pv_domain() && !PageHighMem(page)) {
>  			if (!xen_feature(XENFEAT_auto_translated_physmap)) {
>  				ret = HYPERVISOR_update_va_mapping(
> @@ -427,6 +430,7 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
>  				BUG_ON(ret);
>  			}
>  		}
> +#endif
>  	}
>  
>  	/* Ensure that ballooned highmem pages don't have kmaps. */
> -- 
> 1.7.2.5
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 13:12:38 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 13:12:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOpt9-0005Vg-MR; Thu, 18 Oct 2012 13:11:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOpt7-0005VX-La
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 13:11:49 +0000
Received: from [85.158.139.83:44885] by server-1.bemta-5.messagelabs.com id
	3A/1B-21640-41000805; Thu, 18 Oct 2012 13:11:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1350565907!35276439!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 476 invoked from network); 18 Oct 2012 13:11:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 13:11:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,607,1344211200"; d="scan'208";a="15255027"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 13:11:47 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 18 Oct 2012 14:11:47 +0100
Date: Thu, 18 Oct 2012 14:11:23 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1350473532-15863-1-git-send-email-ian.campbell@citrix.com>
Message-ID: 
References: <1350473518.2460.58.camel@zakaz.uk.xensource.com>
	<1350473532-15863-1-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	"xen-devel@lists.xen.org" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 1/6] xen: balloon: allow PVMMU interfaces to
 be compiled out
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 17 Oct 2012, Ian Campbell wrote:
> The ARM platform has no concept of PVMMU and therefor no
> HYPERVISOR_update_va_mapping et al. Allow this code to be compiled out
> when not required.
> 
> In some similar situations (e.g. P2M) we have defined dummy functions
> to avoid this, however I think we can/should draw the line at dummying
> out actual hypercalls.
> 
> Signed-off-by: Ian Campbell 

It is OK for me


>  arch/x86/xen/Kconfig  |    1 +
>  drivers/xen/Kconfig   |    3 +++
>  drivers/xen/balloon.c |    4 ++++
>  3 files changed, 8 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> index 9323b8c..6d101a1 100644
> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@ -6,6 +6,7 @@ config XEN
>  	bool "Xen guest support"
>  	select PARAVIRT
>  	select PARAVIRT_CLOCK
> +	select XEN_HAVE_PVMMU
>  	depends on X86_64 || (X86_32 && X86_PAE && !X86_VISWS)
>  	depends on X86_CMPXCHG && X86_TSC
>  	help
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index d4dffcd..9c00652 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -204,4 +204,7 @@ config XEN_MCE_LOG
>  	  Allow kernel fetching MCE error from Xen platform and
>  	  converting it into Linux mcelog format for mcelog tools
>  
> +config XEN_HAVE_PVMMU
> +       bool
> +
>  endmenu
> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> index db3aa34..92449a0 100644
> --- a/drivers/xen/balloon.c
> +++ b/drivers/xen/balloon.c
> @@ -360,6 +360,7 @@ static enum bp_state increase_reservation(unsigned long nr_pages)
>  		if (!xen_feature(XENFEAT_auto_translated_physmap))
>  			set_phys_to_machine(pfn, frame_list[i]);
>  
> +#ifdef CONFIG_XEN_HAVE_PVMMU
>  		/* Link back into the page tables if not highmem. */
>  		if (xen_pv_domain() && !PageHighMem(page) &&
>  		    !xen_feature(XENFEAT_auto_translated_physmap)) {
> @@ -371,6 +372,7 @@ static enum bp_state increase_reservation(unsigned long nr_pages)
>  				0);
>  			BUG_ON(ret);
>  		}
> +#endif
>  
>  		/* Relinquish the page back to the allocator. */
>  		ClearPageReserved(page);
> @@ -419,6 +421,7 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
>  
>  		scrub_page(page);
>  
> +#ifdef CONFIG_XEN_HAVE_PVMMU
>  		if (xen_pv_domain() && !PageHighMem(page)) {
>  			if (!xen_feature(XENFEAT_auto_translated_physmap)) {
>  				ret = HYPERVISOR_update_va_mapping(
> @@ -427,6 +430,7 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
>  				BUG_ON(ret);
>  			}
>  		}
> +#endif
>  	}
>  
>  	/* Ensure that ballooned highmem pages don't have kmaps. */
> -- 
> 1.7.2.5
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 13:16:35 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 13:16:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOpwy-0005iE-BB; Thu, 18 Oct 2012 13:15:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOpww-0005i5-RS
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 13:15:47 +0000
Received: from [193.109.254.147:35329] by server-15.bemta-14.messagelabs.com
	id B2/23-16351-20100805; Thu, 18 Oct 2012 13:15:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1350566138!5355070!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5391 invoked from network); 18 Oct 2012 13:15:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 13:15:39 -0000
X-IronPort-AV: E=Sophos;i="4.80,607,1344211200"; d="scan'208";a="15255138"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 13:15:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 14:15:36 +0100
Message-ID: <1350566135.2460.137.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Dario Faggioli 
Date: Thu, 18 Oct 2012 14:15:35 +0100
In-Reply-To: <1350565867.24760.9.camel@Abyss>
References: 
	<6d7a403305dd057f61bd.1350408388@Solace>
	<1350559390.2460.124.camel@zakaz.uk.xensource.com>
	<1350565867.24760.9.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Andre Przywara ,
	Ian Jackson ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 3 of 3] xl: allow for node-wise
 specification of vcpu pinning
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-18 at 14:11 +0100, Dario Faggioli wrote:
> On Thu, 2012-10-18 at 12:23 +0100, Ian Campbell wrote: 
> > On Tue, 2012-10-16 at 18:26 +0100, Dario Faggioli wrote:
> > 
> > > +            isnot = 1;
> > > +        }
> > > +        /* Check if we're dealing with a full node */
> > > +        if (strstr(toka, "node:") == toka || strstr(toka, "nodes:") == toka) {
> > 
> > Isn't strstr(FOO, "thing") == FOO just an expensive way of writing
> > strncmp(FOO, "ting", sizeof(...))?
> > 
> Mmm... what I wanted was to make sure that "thing" not only is part of
> FOO, but that also is the very beginning of that same string. That's why
> I exploited the fact that strstr() returns a pointer to the beginning of
> the substring "thing" within FOO.
> 
> Now that you mentioned it, I think that I actually can achieve the same
> with strncmp, limiting the comparison at strlen("thing"). If that was
> what you meant, the answer is yes, I can do that (and I agree it's
> probably better).

Right, With the strstr method if there is 1000 characters in the input
before the "thing" you've wasted a bunch of time scanning for it just to
throw it away, whereas with str*cmp you would give up after the first
non-matching char.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 13:16:35 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 13:16:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOpwy-0005iE-BB; Thu, 18 Oct 2012 13:15:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOpww-0005i5-RS
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 13:15:47 +0000
Received: from [193.109.254.147:35329] by server-15.bemta-14.messagelabs.com
	id B2/23-16351-20100805; Thu, 18 Oct 2012 13:15:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1350566138!5355070!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5391 invoked from network); 18 Oct 2012 13:15:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 13:15:39 -0000
X-IronPort-AV: E=Sophos;i="4.80,607,1344211200"; d="scan'208";a="15255138"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 13:15:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 14:15:36 +0100
Message-ID: <1350566135.2460.137.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Dario Faggioli 
Date: Thu, 18 Oct 2012 14:15:35 +0100
In-Reply-To: <1350565867.24760.9.camel@Abyss>
References: 
	<6d7a403305dd057f61bd.1350408388@Solace>
	<1350559390.2460.124.camel@zakaz.uk.xensource.com>
	<1350565867.24760.9.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Andre Przywara ,
	Ian Jackson ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 3 of 3] xl: allow for node-wise
 specification of vcpu pinning
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-18 at 14:11 +0100, Dario Faggioli wrote:
> On Thu, 2012-10-18 at 12:23 +0100, Ian Campbell wrote: 
> > On Tue, 2012-10-16 at 18:26 +0100, Dario Faggioli wrote:
> > 
> > > +            isnot = 1;
> > > +        }
> > > +        /* Check if we're dealing with a full node */
> > > +        if (strstr(toka, "node:") == toka || strstr(toka, "nodes:") == toka) {
> > 
> > Isn't strstr(FOO, "thing") == FOO just an expensive way of writing
> > strncmp(FOO, "ting", sizeof(...))?
> > 
> Mmm... what I wanted was to make sure that "thing" not only is part of
> FOO, but that also is the very beginning of that same string. That's why
> I exploited the fact that strstr() returns a pointer to the beginning of
> the substring "thing" within FOO.
> 
> Now that you mentioned it, I think that I actually can achieve the same
> with strncmp, limiting the comparison at strlen("thing"). If that was
> what you meant, the answer is yes, I can do that (and I agree it's
> probably better).

Right, With the strstr method if there is 1000 characters in the input
before the "thing" you've wasted a bunch of time scanning for it just to
throw it away, whereas with str*cmp you would give up after the first
non-matching char.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 13:18:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 13:18:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOpzE-0005q9-Tb; Thu, 18 Oct 2012 13:18:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOpzD-0005q0-8L
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 13:18:07 +0000
Received: from [85.158.139.211:34053] by server-14.bemta-5.messagelabs.com id
	73/0F-24068-E8100805; Thu, 18 Oct 2012 13:18:06 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1350566285!22859906!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22082 invoked from network); 18 Oct 2012 13:18:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 13:18:06 -0000
X-IronPort-AV: E=Sophos;i="4.80,607,1344211200"; 
	d="asc'?scan'208";a="15255187"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 13:18:05 +0000
Received: from [IPv6:::1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 14:18:05 +0100
Message-ID: <1350566283.24760.10.camel@Abyss>
From: Dario Faggioli 
To: Ian Campbell 
Date: Thu, 18 Oct 2012 15:18:03 +0200
In-Reply-To: <1350566135.2460.137.camel@zakaz.uk.xensource.com>
References: 
	<6d7a403305dd057f61bd.1350408388@Solace>
	<1350559390.2460.124.camel@zakaz.uk.xensource.com>
	<1350565867.24760.9.camel@Abyss>
	<1350566135.2460.137.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
MIME-Version: 1.0
Cc: Andre Przywara ,
	Ian Jackson ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 3 of 3] xl: allow for node-wise
 specification of vcpu pinning
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============8164544700396267158=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8164544700396267158==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-U9IZsVlg3tWrMIPwXNBF"

--=-U9IZsVlg3tWrMIPwXNBF
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-10-18 at 14:15 +0100, Ian Campbell wrote:=20
> Right, With the strstr method if there is 1000 characters in the input
> before the "thing" you've wasted a bunch of time scanning for it just to
> throw it away, whereas with str*cmp you would give up after the first
> non-matching char.
>=20
Ok, I'll go for it.

Thanks and Regards,
Dario

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-U9IZsVlg3tWrMIPwXNBF
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlCAAYsACgkQk4XaBE3IOsR56ACfZbo8YKuxjz8ETw3GmcEwEPHI
toAAn2HnINDm/Ucr2QK09A2sgxnMN+Fy
=otMl
-----END PGP SIGNATURE-----

--=-U9IZsVlg3tWrMIPwXNBF--


--===============8164544700396267158==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8164544700396267158==--


From xen-devel-bounces@lists.xen.org Thu Oct 18 13:18:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 13:18:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOpzE-0005q9-Tb; Thu, 18 Oct 2012 13:18:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOpzD-0005q0-8L
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 13:18:07 +0000
Received: from [85.158.139.211:34053] by server-14.bemta-5.messagelabs.com id
	73/0F-24068-E8100805; Thu, 18 Oct 2012 13:18:06 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1350566285!22859906!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22082 invoked from network); 18 Oct 2012 13:18:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 13:18:06 -0000
X-IronPort-AV: E=Sophos;i="4.80,607,1344211200"; 
	d="asc'?scan'208";a="15255187"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 13:18:05 +0000
Received: from [IPv6:::1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 14:18:05 +0100
Message-ID: <1350566283.24760.10.camel@Abyss>
From: Dario Faggioli 
To: Ian Campbell 
Date: Thu, 18 Oct 2012 15:18:03 +0200
In-Reply-To: <1350566135.2460.137.camel@zakaz.uk.xensource.com>
References: 
	<6d7a403305dd057f61bd.1350408388@Solace>
	<1350559390.2460.124.camel@zakaz.uk.xensource.com>
	<1350565867.24760.9.camel@Abyss>
	<1350566135.2460.137.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
MIME-Version: 1.0
Cc: Andre Przywara ,
	Ian Jackson ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 3 of 3] xl: allow for node-wise
 specification of vcpu pinning
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============8164544700396267158=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8164544700396267158==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-U9IZsVlg3tWrMIPwXNBF"

--=-U9IZsVlg3tWrMIPwXNBF
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-10-18 at 14:15 +0100, Ian Campbell wrote:=20
> Right, With the strstr method if there is 1000 characters in the input
> before the "thing" you've wasted a bunch of time scanning for it just to
> throw it away, whereas with str*cmp you would give up after the first
> non-matching char.
>=20
Ok, I'll go for it.

Thanks and Regards,
Dario

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-U9IZsVlg3tWrMIPwXNBF
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlCAAYsACgkQk4XaBE3IOsR56ACfZbo8YKuxjz8ETw3GmcEwEPHI
toAAn2HnINDm/Ucr2QK09A2sgxnMN+Fy
=otMl
-----END PGP SIGNATURE-----

--=-U9IZsVlg3tWrMIPwXNBF--


--===============8164544700396267158==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8164544700396267158==--


From xen-devel-bounces@lists.xen.org Thu Oct 18 13:21:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 13:21:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOq1z-0005zY-Fn; Thu, 18 Oct 2012 13:20:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOq1x-0005zP-T8
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 13:20:58 +0000
Received: from [85.158.137.99:2253] by server-14.bemta-3.messagelabs.com id
	D1/08-17276-93200805; Thu, 18 Oct 2012 13:20:57 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1350566456!16751912!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18661 invoked from network); 18 Oct 2012 13:20:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 13:20:56 -0000
X-IronPort-AV: E=Sophos;i="4.80,607,1344211200"; d="scan'208";a="15255304"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 13:20:56 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 18 Oct 2012 14:20:56 +0100
Date: Thu, 18 Oct 2012 14:20:32 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1350473532-15863-2-git-send-email-ian.campbell@citrix.com>
Message-ID: 
References: <1350473518.2460.58.camel@zakaz.uk.xensource.com>
	<1350473532-15863-2-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	"xen-devel@lists.xen.org" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 2/6] xen: arm: enable balloon driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 17 Oct 2012, Ian Campbell wrote:
> The code is no in a state where can just enable it.
> 
> Drop the *_xenballloned_pages duplicates since these are now supplied
> by the balloon code.
> 
> Signed-off-by: Ian Campbell 


Acked-by: Stefano Stabellini 

>  arch/arm/xen/enlighten.c |   23 +++++------------------
>  drivers/xen/Makefile     |    4 ++--
>  2 files changed, 7 insertions(+), 20 deletions(-)
> 
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index 59bcb96..ba5cc13 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -8,6 +8,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -29,6 +30,10 @@ struct shared_info *HYPERVISOR_shared_info = (void *)&xen_dummy_shared_info;
>  
>  DEFINE_PER_CPU(struct vcpu_info *, xen_vcpu);
>  
> +/* These are unused until we support booting "pre-ballooned" */
> +unsigned long xen_released_pages;
> +struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata;
> +
>  /* TODO: to be removed */
>  __read_mostly int xen_have_vector_callback;
>  EXPORT_SYMBOL_GPL(xen_have_vector_callback);
> @@ -148,21 +153,3 @@ static int __init xen_init_events(void)
>  	return 0;
>  }
>  postcore_initcall(xen_init_events);
> -
> -/* XXX: only until balloon is properly working */
> -int alloc_xenballooned_pages(int nr_pages, struct page **pages, bool highmem)
> -{
> -	*pages = alloc_pages(highmem ? GFP_HIGHUSER : GFP_KERNEL,
> -			get_order(nr_pages));
> -	if (*pages == NULL)
> -		return -ENOMEM;
> -	return 0;
> -}
> -EXPORT_SYMBOL_GPL(alloc_xenballooned_pages);
> -
> -void free_xenballooned_pages(int nr_pages, struct page **pages)
> -{
> -	kfree(*pages);
> -	*pages = NULL;
> -}
> -EXPORT_SYMBOL_GPL(free_xenballooned_pages);
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index 0e863703..909bb56 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -1,8 +1,8 @@
>  ifneq ($(CONFIG_ARM),y)
> -obj-y	+= manage.o balloon.o
> +obj-y	+= manage.o
>  obj-$(CONFIG_HOTPLUG_CPU)		+= cpu_hotplug.o
>  endif
> -obj-y	+= grant-table.o features.o events.o
> +obj-y	+= grant-table.o features.o events.o balloon.o
>  obj-y	+= xenbus/
>  
>  nostackp := $(call cc-option, -fno-stack-protector)
> -- 
> 1.7.2.5
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 13:21:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 13:21:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOq1z-0005zY-Fn; Thu, 18 Oct 2012 13:20:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOq1x-0005zP-T8
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 13:20:58 +0000
Received: from [85.158.137.99:2253] by server-14.bemta-3.messagelabs.com id
	D1/08-17276-93200805; Thu, 18 Oct 2012 13:20:57 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1350566456!16751912!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18661 invoked from network); 18 Oct 2012 13:20:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 13:20:56 -0000
X-IronPort-AV: E=Sophos;i="4.80,607,1344211200"; d="scan'208";a="15255304"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 13:20:56 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 18 Oct 2012 14:20:56 +0100
Date: Thu, 18 Oct 2012 14:20:32 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1350473532-15863-2-git-send-email-ian.campbell@citrix.com>
Message-ID: 
References: <1350473518.2460.58.camel@zakaz.uk.xensource.com>
	<1350473532-15863-2-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	"xen-devel@lists.xen.org" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 2/6] xen: arm: enable balloon driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 17 Oct 2012, Ian Campbell wrote:
> The code is no in a state where can just enable it.
> 
> Drop the *_xenballloned_pages duplicates since these are now supplied
> by the balloon code.
> 
> Signed-off-by: Ian Campbell 


Acked-by: Stefano Stabellini 

>  arch/arm/xen/enlighten.c |   23 +++++------------------
>  drivers/xen/Makefile     |    4 ++--
>  2 files changed, 7 insertions(+), 20 deletions(-)
> 
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index 59bcb96..ba5cc13 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -8,6 +8,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -29,6 +30,10 @@ struct shared_info *HYPERVISOR_shared_info = (void *)&xen_dummy_shared_info;
>  
>  DEFINE_PER_CPU(struct vcpu_info *, xen_vcpu);
>  
> +/* These are unused until we support booting "pre-ballooned" */
> +unsigned long xen_released_pages;
> +struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata;
> +
>  /* TODO: to be removed */
>  __read_mostly int xen_have_vector_callback;
>  EXPORT_SYMBOL_GPL(xen_have_vector_callback);
> @@ -148,21 +153,3 @@ static int __init xen_init_events(void)
>  	return 0;
>  }
>  postcore_initcall(xen_init_events);
> -
> -/* XXX: only until balloon is properly working */
> -int alloc_xenballooned_pages(int nr_pages, struct page **pages, bool highmem)
> -{
> -	*pages = alloc_pages(highmem ? GFP_HIGHUSER : GFP_KERNEL,
> -			get_order(nr_pages));
> -	if (*pages == NULL)
> -		return -ENOMEM;
> -	return 0;
> -}
> -EXPORT_SYMBOL_GPL(alloc_xenballooned_pages);
> -
> -void free_xenballooned_pages(int nr_pages, struct page **pages)
> -{
> -	kfree(*pages);
> -	*pages = NULL;
> -}
> -EXPORT_SYMBOL_GPL(free_xenballooned_pages);
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index 0e863703..909bb56 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -1,8 +1,8 @@
>  ifneq ($(CONFIG_ARM),y)
> -obj-y	+= manage.o balloon.o
> +obj-y	+= manage.o
>  obj-$(CONFIG_HOTPLUG_CPU)		+= cpu_hotplug.o
>  endif
> -obj-y	+= grant-table.o features.o events.o
> +obj-y	+= grant-table.o features.o events.o balloon.o
>  obj-y	+= xenbus/
>  
>  nostackp := $(call cc-option, -fno-stack-protector)
> -- 
> 1.7.2.5
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 13:24:18 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 13:24:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOq4x-0006B9-8G; Thu, 18 Oct 2012 13:24:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOq4u-0006B3-UD
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 13:24:01 +0000
Received: from [85.158.137.99:53160] by server-8.bemta-3.messagelabs.com id
	70/F4-10525-0F200805; Thu, 18 Oct 2012 13:24:00 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1350566639!22133399!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3589 invoked from network); 18 Oct 2012 13:23:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 13:23:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,607,1344211200"; d="scan'208";a="15255386"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 13:23:59 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 18 Oct 2012 14:23:59 +0100
Date: Thu, 18 Oct 2012 14:23:35 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1350473532-15863-4-git-send-email-ian.campbell@citrix.com>
Message-ID: 
References: <1350473518.2460.58.camel@zakaz.uk.xensource.com>
	<1350473532-15863-4-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	"xen-devel@lists.xen.org" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 4/6] xen: correctly use xen_pfn_t in
 remap_domain_mfn_range.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 17 Oct 2012, Ian Campbell wrote:
> For Xen on ARM a PFN is 64 bits so we need to use the appropriate
> type here.
> 
> Signed-off-by: Ian Campbell 

Acked-by: Stefano Stabellini 

In general every mfn/pfn type should be xen_pfn_t, we might have to do a
closer audit of the code.


>  arch/x86/xen/mmu.c    |    2 +-
>  include/xen/xen-ops.h |    2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index 1c5812b..d779e96 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -2603,7 +2603,7 @@ static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token,
>  
>  int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
>  			       unsigned long addr,
> -			       unsigned long mfn, int nr,
> +			       xen_pfn_t mfn, int nr,
>  			       pgprot_t prot, unsigned domid,
>  			       struct page **pages)
>  
> diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
> index 6a40253..dc63e80 100644
> --- a/include/xen/xen-ops.h
> +++ b/include/xen/xen-ops.h
> @@ -26,7 +26,7 @@ void xen_destroy_contiguous_region(unsigned long vstart, unsigned int order);
>  struct vm_area_struct;
>  int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
>  			       unsigned long addr,
> -			       unsigned long mfn, int nr,
> +			       xen_pfn_t mfn, int nr,
>  			       pgprot_t prot, unsigned domid,
>  			       struct page **pages);
>  int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
> -- 
> 1.7.2.5
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 13:24:18 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 13:24:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOq4x-0006B9-8G; Thu, 18 Oct 2012 13:24:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOq4u-0006B3-UD
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 13:24:01 +0000
Received: from [85.158.137.99:53160] by server-8.bemta-3.messagelabs.com id
	70/F4-10525-0F200805; Thu, 18 Oct 2012 13:24:00 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1350566639!22133399!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3589 invoked from network); 18 Oct 2012 13:23:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 13:23:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,607,1344211200"; d="scan'208";a="15255386"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 13:23:59 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 18 Oct 2012 14:23:59 +0100
Date: Thu, 18 Oct 2012 14:23:35 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1350473532-15863-4-git-send-email-ian.campbell@citrix.com>
Message-ID: 
References: <1350473518.2460.58.camel@zakaz.uk.xensource.com>
	<1350473532-15863-4-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	"xen-devel@lists.xen.org" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 4/6] xen: correctly use xen_pfn_t in
 remap_domain_mfn_range.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 17 Oct 2012, Ian Campbell wrote:
> For Xen on ARM a PFN is 64 bits so we need to use the appropriate
> type here.
> 
> Signed-off-by: Ian Campbell 

Acked-by: Stefano Stabellini 

In general every mfn/pfn type should be xen_pfn_t, we might have to do a
closer audit of the code.


>  arch/x86/xen/mmu.c    |    2 +-
>  include/xen/xen-ops.h |    2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index 1c5812b..d779e96 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -2603,7 +2603,7 @@ static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token,
>  
>  int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
>  			       unsigned long addr,
> -			       unsigned long mfn, int nr,
> +			       xen_pfn_t mfn, int nr,
>  			       pgprot_t prot, unsigned domid,
>  			       struct page **pages)
>  
> diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
> index 6a40253..dc63e80 100644
> --- a/include/xen/xen-ops.h
> +++ b/include/xen/xen-ops.h
> @@ -26,7 +26,7 @@ void xen_destroy_contiguous_region(unsigned long vstart, unsigned int order);
>  struct vm_area_struct;
>  int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
>  			       unsigned long addr,
> -			       unsigned long mfn, int nr,
> +			       xen_pfn_t mfn, int nr,
>  			       pgprot_t prot, unsigned domid,
>  			       struct page **pages);
>  int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
> -- 
> 1.7.2.5
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 13:28:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 13:28:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOq9C-0006Ts-Mn; Thu, 18 Oct 2012 13:28:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOq9A-0006TZ-EM
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 13:28:24 +0000
Received: from [85.158.139.83:13379] by server-14.bemta-5.messagelabs.com id
	F9/48-24068-7F300805; Thu, 18 Oct 2012 13:28:23 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1350566902!31169322!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32635 invoked from network); 18 Oct 2012 13:28:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 13:28:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,607,1344211200"; d="scan'208";a="15255521"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 13:28:01 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 18 Oct 2012 14:28:01 +0100
Date: Thu, 18 Oct 2012 14:27:37 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1350473532-15863-5-git-send-email-ian.campbell@citrix.com>
Message-ID: 
References: <1350473518.2460.58.camel@zakaz.uk.xensource.com>
	<1350473532-15863-5-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	"xen-devel@lists.xen.org" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 5/6] xen: arm: implement remap interfaces
 needed for privcmd mappings.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 17 Oct 2012, Ian Campbell wrote:
> We use XENMEM_add_to_physmap_range which is the preferred interface
> for foreign mappings.
> 
> Signed-off-by: Ian Campbell 

It looks OK but there are few code style issues, please run the patch
through checkpatch.


>  arch/arm/include/asm/xen/interface.h |    1 +
>  arch/arm/xen/enlighten.c             |  100 +++++++++++++++++++++++++++++++++-
>  arch/x86/include/asm/xen/interface.h |    1 +
>  include/xen/interface/memory.h       |   18 ++++++
>  4 files changed, 117 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
> index 1d6ef9c..007e6da 100644
> --- a/arch/arm/include/asm/xen/interface.h
> +++ b/arch/arm/include/asm/xen/interface.h
> @@ -43,6 +43,7 @@ DEFINE_GUEST_HANDLE(void);
>  DEFINE_GUEST_HANDLE(uint64_t);
>  DEFINE_GUEST_HANDLE(uint32_t);
>  DEFINE_GUEST_HANDLE(xen_pfn_t);
> +DEFINE_GUEST_HANDLE(xen_ulong_t);
>  
>  /* Maximum number of virtual CPUs in multi-processor guests. */
>  #define MAX_VIRT_CPUS 1
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index ba5cc13..6bb4630 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -9,6 +9,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -18,6 +19,8 @@
>  #include 
>  #include 
>  
> +#include 
> +
>  struct start_info _xen_start_info;
>  struct start_info *xen_start_info = &_xen_start_info;
>  EXPORT_SYMBOL_GPL(xen_start_info);
> @@ -43,15 +46,106 @@ EXPORT_SYMBOL_GPL(xen_platform_pci_unplug);
>  
>  static __read_mostly int xen_events_irq = -1;
>  
> +/* map fgmfn of domid to lpfn in the current domain */
> +static int map_foreign_page(unsigned long lpfn, unsigned long fgmfn,
> +			    unsigned int domid)
> +{
> +	int rc;
> +	struct xen_add_to_physmap_range xatp = {
> +		.domid = DOMID_SELF,
> +		.foreign_domid = domid,
> +		.size = 1,
> +		.space = XENMAPSPACE_gmfn_foreign,
> +	};
> +	xen_ulong_t idx = fgmfn;
> +	xen_pfn_t gpfn = lpfn;
> +
> +	set_xen_guest_handle(xatp.idxs, &idx);
> +	set_xen_guest_handle(xatp.gpfns, &gpfn);
> +
> +	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap_range, &xatp);
> +	if (rc) {
> +		pr_warn("Failed to map pfn to mfn rc:%d pfn:%lx mfn:%lx\n",
> +			rc, lpfn, fgmfn);
> +		return 1;
> +	}
> +	return 0;
> +}
> +
> +struct remap_data {
> +	xen_pfn_t fgmfn; /* foreign domain's gmfn */
> +	pgprot_t prot;
> +	domid_t  domid;
> +	struct vm_area_struct *vma;
> +	int index;
> +	struct page **pages;
> +	struct xen_remap_mfn_info *info;
> +};
> +
> +static int remap_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr,
> +			void *data)
> +{
> +	struct remap_data *info = data;
> +	struct page *page = info->pages[info->index++];
> +	unsigned long pfn = page_to_pfn(page);
> +	pte_t pte = pfn_pte(pfn, info->prot);
> +
> +	if (map_foreign_page(pfn, info->fgmfn, info->domid))
> +		return -EFAULT;
> +	set_pte_at(info->vma->vm_mm, addr, ptep, pte);
> +
> +	return 0;
> +}
> +
>  int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
>  			       unsigned long addr,
> -			       unsigned long mfn, int nr,
> -			       pgprot_t prot, unsigned domid)
> +			       xen_pfn_t mfn, int nr,
> +			       pgprot_t prot, unsigned domid,
> +			       struct page **pages)
>  {
> -	return -ENOSYS;
> +	int err;
> +	struct remap_data data;
> +
> +	/* TBD: Batching, current sole caller only does page at a time */
> +	if (nr > 1)
> +		return -EINVAL;
> +
> +	data.fgmfn = mfn;
> +	data.prot = prot;
> +	data.domid = domid;
> +	data.vma = vma;
> +	data.index = 0;
> +	data.pages = pages;
> +	err = apply_to_page_range(vma->vm_mm, addr, nr << PAGE_SHIFT,
> +				  remap_pte_fn, &data);
> +	return err;
>  }
>  EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
>  
> +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
> +			       struct page **pages, int nr)
> +{
> +	int i;
> +
> +	for (i=0; i +		struct xen_remove_from_physmap xrp;
> +		unsigned long rc, pfn;
> +
> +		pfn = page_to_pfn(pages[i]);
> +
> +		xrp.domid = DOMID_SELF;
> +		xrp.gpfn = pfn;
> +		rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, &xrp);
> +		if (rc) {
> +			pr_warn("Failed to unmap pfn:%lx rc:%ld\n",
> +				pfn, rc);
> +			return rc;
> +		}
> +	}
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range);
> +
>  /*
>   * see Documentation/devicetree/bindings/arm/xen.txt for the
>   * documentation of the Xen Device Tree format.
> diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
> index 25669c3..6246d80 100644
> --- a/arch/x86/include/asm/xen/interface.h
> +++ b/arch/x86/include/asm/xen/interface.h
> @@ -63,6 +63,7 @@ DEFINE_GUEST_HANDLE(void);
>  DEFINE_GUEST_HANDLE(uint64_t);
>  DEFINE_GUEST_HANDLE(uint32_t);
>  DEFINE_GUEST_HANDLE(xen_pfn_t);
> +DEFINE_GUEST_HANDLE(xen_ulong_t);
>  #endif
>  
>  #ifndef HYPERVISOR_VIRT_START
> diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
> index 91bdc2a..eb2d3e5 100644
> --- a/include/xen/interface/memory.h
> +++ b/include/xen/interface/memory.h
> @@ -190,6 +190,24 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_physmap);
>  /*** REMOVED ***/
>  /*#define XENMEM_translate_gpfn_list  8*/
>  
> +#define XENMEM_add_to_physmap_range 23
> +struct xen_add_to_physmap_range {
> +    /* Which domain to change the mapping for. */
> +    domid_t domid;
> +    uint16_t space; /* => enum phys_map_space */
> +
> +    /* Number of pages to go through */
> +    uint16_t size;
> +    domid_t foreign_domid; /* IFF gmfn_foreign */
> +
> +    /* Indexes into space being mapped. */
> +    GUEST_HANDLE(xen_ulong_t) idxs;
> +
> +    /* GPFN in domid where the source mapping page should appear. */
> +    GUEST_HANDLE(xen_pfn_t) gpfns;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_physmap_range);
> +
>  /*
>   * Returns the pseudo-physical memory map as it was when the domain
>   * was started (specified by XENMEM_set_memory_map).
> -- 
> 1.7.2.5
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 13:28:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 13:28:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOq9C-0006Ts-Mn; Thu, 18 Oct 2012 13:28:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOq9A-0006TZ-EM
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 13:28:24 +0000
Received: from [85.158.139.83:13379] by server-14.bemta-5.messagelabs.com id
	F9/48-24068-7F300805; Thu, 18 Oct 2012 13:28:23 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1350566902!31169322!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32635 invoked from network); 18 Oct 2012 13:28:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 13:28:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,607,1344211200"; d="scan'208";a="15255521"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 13:28:01 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 18 Oct 2012 14:28:01 +0100
Date: Thu, 18 Oct 2012 14:27:37 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1350473532-15863-5-git-send-email-ian.campbell@citrix.com>
Message-ID: 
References: <1350473518.2460.58.camel@zakaz.uk.xensource.com>
	<1350473532-15863-5-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	"xen-devel@lists.xen.org" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 5/6] xen: arm: implement remap interfaces
 needed for privcmd mappings.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 17 Oct 2012, Ian Campbell wrote:
> We use XENMEM_add_to_physmap_range which is the preferred interface
> for foreign mappings.
> 
> Signed-off-by: Ian Campbell 

It looks OK but there are few code style issues, please run the patch
through checkpatch.


>  arch/arm/include/asm/xen/interface.h |    1 +
>  arch/arm/xen/enlighten.c             |  100 +++++++++++++++++++++++++++++++++-
>  arch/x86/include/asm/xen/interface.h |    1 +
>  include/xen/interface/memory.h       |   18 ++++++
>  4 files changed, 117 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
> index 1d6ef9c..007e6da 100644
> --- a/arch/arm/include/asm/xen/interface.h
> +++ b/arch/arm/include/asm/xen/interface.h
> @@ -43,6 +43,7 @@ DEFINE_GUEST_HANDLE(void);
>  DEFINE_GUEST_HANDLE(uint64_t);
>  DEFINE_GUEST_HANDLE(uint32_t);
>  DEFINE_GUEST_HANDLE(xen_pfn_t);
> +DEFINE_GUEST_HANDLE(xen_ulong_t);
>  
>  /* Maximum number of virtual CPUs in multi-processor guests. */
>  #define MAX_VIRT_CPUS 1
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index ba5cc13..6bb4630 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -9,6 +9,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -18,6 +19,8 @@
>  #include 
>  #include 
>  
> +#include 
> +
>  struct start_info _xen_start_info;
>  struct start_info *xen_start_info = &_xen_start_info;
>  EXPORT_SYMBOL_GPL(xen_start_info);
> @@ -43,15 +46,106 @@ EXPORT_SYMBOL_GPL(xen_platform_pci_unplug);
>  
>  static __read_mostly int xen_events_irq = -1;
>  
> +/* map fgmfn of domid to lpfn in the current domain */
> +static int map_foreign_page(unsigned long lpfn, unsigned long fgmfn,
> +			    unsigned int domid)
> +{
> +	int rc;
> +	struct xen_add_to_physmap_range xatp = {
> +		.domid = DOMID_SELF,
> +		.foreign_domid = domid,
> +		.size = 1,
> +		.space = XENMAPSPACE_gmfn_foreign,
> +	};
> +	xen_ulong_t idx = fgmfn;
> +	xen_pfn_t gpfn = lpfn;
> +
> +	set_xen_guest_handle(xatp.idxs, &idx);
> +	set_xen_guest_handle(xatp.gpfns, &gpfn);
> +
> +	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap_range, &xatp);
> +	if (rc) {
> +		pr_warn("Failed to map pfn to mfn rc:%d pfn:%lx mfn:%lx\n",
> +			rc, lpfn, fgmfn);
> +		return 1;
> +	}
> +	return 0;
> +}
> +
> +struct remap_data {
> +	xen_pfn_t fgmfn; /* foreign domain's gmfn */
> +	pgprot_t prot;
> +	domid_t  domid;
> +	struct vm_area_struct *vma;
> +	int index;
> +	struct page **pages;
> +	struct xen_remap_mfn_info *info;
> +};
> +
> +static int remap_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr,
> +			void *data)
> +{
> +	struct remap_data *info = data;
> +	struct page *page = info->pages[info->index++];
> +	unsigned long pfn = page_to_pfn(page);
> +	pte_t pte = pfn_pte(pfn, info->prot);
> +
> +	if (map_foreign_page(pfn, info->fgmfn, info->domid))
> +		return -EFAULT;
> +	set_pte_at(info->vma->vm_mm, addr, ptep, pte);
> +
> +	return 0;
> +}
> +
>  int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
>  			       unsigned long addr,
> -			       unsigned long mfn, int nr,
> -			       pgprot_t prot, unsigned domid)
> +			       xen_pfn_t mfn, int nr,
> +			       pgprot_t prot, unsigned domid,
> +			       struct page **pages)
>  {
> -	return -ENOSYS;
> +	int err;
> +	struct remap_data data;
> +
> +	/* TBD: Batching, current sole caller only does page at a time */
> +	if (nr > 1)
> +		return -EINVAL;
> +
> +	data.fgmfn = mfn;
> +	data.prot = prot;
> +	data.domid = domid;
> +	data.vma = vma;
> +	data.index = 0;
> +	data.pages = pages;
> +	err = apply_to_page_range(vma->vm_mm, addr, nr << PAGE_SHIFT,
> +				  remap_pte_fn, &data);
> +	return err;
>  }
>  EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
>  
> +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
> +			       struct page **pages, int nr)
> +{
> +	int i;
> +
> +	for (i=0; i +		struct xen_remove_from_physmap xrp;
> +		unsigned long rc, pfn;
> +
> +		pfn = page_to_pfn(pages[i]);
> +
> +		xrp.domid = DOMID_SELF;
> +		xrp.gpfn = pfn;
> +		rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, &xrp);
> +		if (rc) {
> +			pr_warn("Failed to unmap pfn:%lx rc:%ld\n",
> +				pfn, rc);
> +			return rc;
> +		}
> +	}
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range);
> +
>  /*
>   * see Documentation/devicetree/bindings/arm/xen.txt for the
>   * documentation of the Xen Device Tree format.
> diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
> index 25669c3..6246d80 100644
> --- a/arch/x86/include/asm/xen/interface.h
> +++ b/arch/x86/include/asm/xen/interface.h
> @@ -63,6 +63,7 @@ DEFINE_GUEST_HANDLE(void);
>  DEFINE_GUEST_HANDLE(uint64_t);
>  DEFINE_GUEST_HANDLE(uint32_t);
>  DEFINE_GUEST_HANDLE(xen_pfn_t);
> +DEFINE_GUEST_HANDLE(xen_ulong_t);
>  #endif
>  
>  #ifndef HYPERVISOR_VIRT_START
> diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
> index 91bdc2a..eb2d3e5 100644
> --- a/include/xen/interface/memory.h
> +++ b/include/xen/interface/memory.h
> @@ -190,6 +190,24 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_physmap);
>  /*** REMOVED ***/
>  /*#define XENMEM_translate_gpfn_list  8*/
>  
> +#define XENMEM_add_to_physmap_range 23
> +struct xen_add_to_physmap_range {
> +    /* Which domain to change the mapping for. */
> +    domid_t domid;
> +    uint16_t space; /* => enum phys_map_space */
> +
> +    /* Number of pages to go through */
> +    uint16_t size;
> +    domid_t foreign_domid; /* IFF gmfn_foreign */
> +
> +    /* Indexes into space being mapped. */
> +    GUEST_HANDLE(xen_ulong_t) idxs;
> +
> +    /* GPFN in domid where the source mapping page should appear. */
> +    GUEST_HANDLE(xen_pfn_t) gpfns;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_physmap_range);
> +
>  /*
>   * Returns the pseudo-physical memory map as it was when the domain
>   * was started (specified by XENMEM_set_memory_map).
> -- 
> 1.7.2.5
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 13:31:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 13:31:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOqC0-0006hu-8v; Thu, 18 Oct 2012 13:31:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOqBz-0006hj-BI
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 13:31:19 +0000
Received: from [85.158.143.35:48380] by server-3.bemta-4.messagelabs.com id
	2F/2F-03544-6A400805; Thu, 18 Oct 2012 13:31:18 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1350567077!13531030!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19219 invoked from network); 18 Oct 2012 13:31:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 13:31:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,607,1344211200"; d="scan'208";a="15255641"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 13:31:17 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 18 Oct 2012 14:31:17 +0100
Date: Thu, 18 Oct 2012 14:30:53 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1350473532-15863-6-git-send-email-ian.campbell@citrix.com>
Message-ID: 
References: <1350473518.2460.58.camel@zakaz.uk.xensource.com>
	<1350473532-15863-6-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	"xen-devel@lists.xen.org" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 6/6] xen: x86 pvh: use
 XENMEM_add_to_physmap_range for foreign gmfn mappings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 17 Oct 2012, Ian Campbell wrote:
> Squeezing the necessary fields into the existing XENMEM_add_to_physmap
> interface was proving to be a bit tricky so we have decided to go with
> a new interface upstream (the XENMAPSPACE_gmfn_foreign interface using
> XENMEM_add_to_physmap was never committed anywhere). This interface
> also allows for batching which was impossible to support at the same
> time as foreign mfns in the old interface.
> 
> This reverts the relevant parts of "PVH: basic and header changes,
> elfnote changes, ..." and followups and trivially converts
> pvh_add_to_xen_p2m over.
> 
> Signed-off-by: Ian Campbell 


Acked-by: Stefano Stabellini 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 13:31:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 13:31:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOqC0-0006hu-8v; Thu, 18 Oct 2012 13:31:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOqBz-0006hj-BI
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 13:31:19 +0000
Received: from [85.158.143.35:48380] by server-3.bemta-4.messagelabs.com id
	2F/2F-03544-6A400805; Thu, 18 Oct 2012 13:31:18 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1350567077!13531030!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19219 invoked from network); 18 Oct 2012 13:31:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 13:31:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,607,1344211200"; d="scan'208";a="15255641"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 13:31:17 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 18 Oct 2012 14:31:17 +0100
Date: Thu, 18 Oct 2012 14:30:53 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1350473532-15863-6-git-send-email-ian.campbell@citrix.com>
Message-ID: 
References: <1350473518.2460.58.camel@zakaz.uk.xensource.com>
	<1350473532-15863-6-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	"xen-devel@lists.xen.org" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 6/6] xen: x86 pvh: use
 XENMEM_add_to_physmap_range for foreign gmfn mappings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 17 Oct 2012, Ian Campbell wrote:
> Squeezing the necessary fields into the existing XENMEM_add_to_physmap
> interface was proving to be a bit tricky so we have decided to go with
> a new interface upstream (the XENMAPSPACE_gmfn_foreign interface using
> XENMEM_add_to_physmap was never committed anywhere). This interface
> also allows for batching which was impossible to support at the same
> time as foreign mfns in the old interface.
> 
> This reverts the relevant parts of "PVH: basic and header changes,
> elfnote changes, ..." and followups and trivially converts
> pvh_add_to_xen_p2m over.
> 
> Signed-off-by: Ian Campbell 


Acked-by: Stefano Stabellini 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 13:33:49 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 13:33:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOqE9-0006sA-Qe; Thu, 18 Oct 2012 13:33:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOqE8-0006s3-To
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 13:33:33 +0000
Received: from [85.158.138.51:47279] by server-8.bemta-3.messagelabs.com id
	F3/D4-10525-C2500805; Thu, 18 Oct 2012 13:33:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1350567211!26002069!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11286 invoked from network); 18 Oct 2012 13:33:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 13:33:31 -0000
X-IronPort-AV: E=Sophos;i="4.80,607,1344211200"; d="scan'208";a="15255715"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 13:33:31 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 14:33:31 +0100
Message-ID: <1350567209.2460.145.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Thu, 18 Oct 2012 14:33:29 +0100
In-Reply-To: 
References: <1350473518.2460.58.camel@zakaz.uk.xensource.com>
	<1350473532-15863-5-git-send-email-ian.campbell@citrix.com>
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 5/6] xen: arm: implement remap interfaces
 needed for privcmd mappings.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-18 at 14:27 +0100, Stefano Stabellini wrote:
> On Wed, 17 Oct 2012, Ian Campbell wrote:
> > We use XENMEM_add_to_physmap_range which is the preferred interface
> > for foreign mappings.
> > 
> > Signed-off-by: Ian Campbell 
> 
> It looks OK but there are few code style issues, please run the patch
> through checkpatch.

The only one I get is:
WARNING: please, no spaces at the start of a line
#83: FILE: include/xen/interface/memory.h:175:
+    uint16_t    size;$

total: 0 errors, 1 warnings, 64 lines checked

The prevailing indentation in that file is 4 spaces so I think we should
ignore the warning in this case in the interests of consistency with the
surrounding code.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 13:33:49 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 13:33:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOqE9-0006sA-Qe; Thu, 18 Oct 2012 13:33:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOqE8-0006s3-To
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 13:33:33 +0000
Received: from [85.158.138.51:47279] by server-8.bemta-3.messagelabs.com id
	F3/D4-10525-C2500805; Thu, 18 Oct 2012 13:33:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1350567211!26002069!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11286 invoked from network); 18 Oct 2012 13:33:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 13:33:31 -0000
X-IronPort-AV: E=Sophos;i="4.80,607,1344211200"; d="scan'208";a="15255715"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 13:33:31 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 14:33:31 +0100
Message-ID: <1350567209.2460.145.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Thu, 18 Oct 2012 14:33:29 +0100
In-Reply-To: 
References: <1350473518.2460.58.camel@zakaz.uk.xensource.com>
	<1350473532-15863-5-git-send-email-ian.campbell@citrix.com>
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 5/6] xen: arm: implement remap interfaces
 needed for privcmd mappings.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-18 at 14:27 +0100, Stefano Stabellini wrote:
> On Wed, 17 Oct 2012, Ian Campbell wrote:
> > We use XENMEM_add_to_physmap_range which is the preferred interface
> > for foreign mappings.
> > 
> > Signed-off-by: Ian Campbell 
> 
> It looks OK but there are few code style issues, please run the patch
> through checkpatch.

The only one I get is:
WARNING: please, no spaces at the start of a line
#83: FILE: include/xen/interface/memory.h:175:
+    uint16_t    size;$

total: 0 errors, 1 warnings, 64 lines checked

The prevailing indentation in that file is 4 spaces so I think we should
ignore the warning in this case in the interests of consistency with the
surrounding code.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 13:36:39 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 13:36:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOqH0-000763-E6; Thu, 18 Oct 2012 13:36:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOqGz-00075w-9h
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 13:36:29 +0000
Received: from [85.158.138.51:14576] by server-7.bemta-3.messagelabs.com id
	E3/29-06991-CD500805; Thu, 18 Oct 2012 13:36:28 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1350567375!16184203!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13087 invoked from network); 18 Oct 2012 13:36:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 13:36:16 -0000
X-IronPort-AV: E=Sophos;i="4.80,607,1344211200"; d="scan'208";a="15255810"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 13:36:15 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 18 Oct 2012 14:36:15 +0100
Date: Thu, 18 Oct 2012 14:35:51 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1350567209.2460.145.camel@zakaz.uk.xensource.com>
Message-ID: 
References: <1350473518.2460.58.camel@zakaz.uk.xensource.com>
	<1350473532-15863-5-git-send-email-ian.campbell@citrix.com>
	
	<1350567209.2460.145.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk ,
	"xen-devel@lists.xen.org" ,
	"linux-kernel@vger.kernel.org" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 5/6] xen: arm: implement remap interfaces
 needed for privcmd mappings.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 18 Oct 2012, Ian Campbell wrote:
> On Thu, 2012-10-18 at 14:27 +0100, Stefano Stabellini wrote:
> > On Wed, 17 Oct 2012, Ian Campbell wrote:
> > > We use XENMEM_add_to_physmap_range which is the preferred interface
> > > for foreign mappings.
> > > 
> > > Signed-off-by: Ian Campbell 
> > 
> > It looks OK but there are few code style issues, please run the patch
> > through checkpatch.
> 
> The only one I get is:
> WARNING: please, no spaces at the start of a line
> #83: FILE: include/xen/interface/memory.h:175:
> +    uint16_t    size;$
> 
> total: 0 errors, 1 warnings, 64 lines checked
> 
> The prevailing indentation in that file is 4 spaces so I think we should
> ignore the warning in this case in the interests of consistency with the
> surrounding code.

Strange, I get:

ERROR: spaces required around that '=' (ctx:VxV)
#140: FILE: arch/arm/xen/enlighten.c:130:
+       for (i=0; i enum phys_map_space */$

WARNING: please, no spaces at the start of a line
#189: FILE: include/xen/interface/memory.h:200:
+    uint16_t size;$

WARNING: please, no spaces at the start of a line
#190: FILE: include/xen/interface/memory.h:201:
+    domid_t foreign_domid; /* IFF gmfn_foreign */$

WARNING: please, no spaces at the start of a line
#193: FILE: include/xen/interface/memory.h:204:
+    GUEST_HANDLE(xen_ulong_t) idxs;$

WARNING: please, no spaces at the start of a line
#196: FILE: include/xen/interface/memory.h:207:
+    GUEST_HANDLE(xen_pfn_t) gpfns;$

total: 2 errors, 6 warnings, 162 lines checked



The ones that bother me a bit are:

+       for (i=0; i
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 13:36:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOqH0-000763-E6; Thu, 18 Oct 2012 13:36:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOqGz-00075w-9h
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 13:36:29 +0000
Received: from [85.158.138.51:14576] by server-7.bemta-3.messagelabs.com id
	E3/29-06991-CD500805; Thu, 18 Oct 2012 13:36:28 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1350567375!16184203!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13087 invoked from network); 18 Oct 2012 13:36:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 13:36:16 -0000
X-IronPort-AV: E=Sophos;i="4.80,607,1344211200"; d="scan'208";a="15255810"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 13:36:15 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 18 Oct 2012 14:36:15 +0100
Date: Thu, 18 Oct 2012 14:35:51 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1350567209.2460.145.camel@zakaz.uk.xensource.com>
Message-ID: 
References: <1350473518.2460.58.camel@zakaz.uk.xensource.com>
	<1350473532-15863-5-git-send-email-ian.campbell@citrix.com>
	
	<1350567209.2460.145.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk ,
	"xen-devel@lists.xen.org" ,
	"linux-kernel@vger.kernel.org" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 5/6] xen: arm: implement remap interfaces
 needed for privcmd mappings.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 18 Oct 2012, Ian Campbell wrote:
> On Thu, 2012-10-18 at 14:27 +0100, Stefano Stabellini wrote:
> > On Wed, 17 Oct 2012, Ian Campbell wrote:
> > > We use XENMEM_add_to_physmap_range which is the preferred interface
> > > for foreign mappings.
> > > 
> > > Signed-off-by: Ian Campbell 
> > 
> > It looks OK but there are few code style issues, please run the patch
> > through checkpatch.
> 
> The only one I get is:
> WARNING: please, no spaces at the start of a line
> #83: FILE: include/xen/interface/memory.h:175:
> +    uint16_t    size;$
> 
> total: 0 errors, 1 warnings, 64 lines checked
> 
> The prevailing indentation in that file is 4 spaces so I think we should
> ignore the warning in this case in the interests of consistency with the
> surrounding code.

Strange, I get:

ERROR: spaces required around that '=' (ctx:VxV)
#140: FILE: arch/arm/xen/enlighten.c:130:
+       for (i=0; i enum phys_map_space */$

WARNING: please, no spaces at the start of a line
#189: FILE: include/xen/interface/memory.h:200:
+    uint16_t size;$

WARNING: please, no spaces at the start of a line
#190: FILE: include/xen/interface/memory.h:201:
+    domid_t foreign_domid; /* IFF gmfn_foreign */$

WARNING: please, no spaces at the start of a line
#193: FILE: include/xen/interface/memory.h:204:
+    GUEST_HANDLE(xen_ulong_t) idxs;$

WARNING: please, no spaces at the start of a line
#196: FILE: include/xen/interface/memory.h:207:
+    GUEST_HANDLE(xen_pfn_t) gpfns;$

total: 2 errors, 6 warnings, 162 lines checked



The ones that bother me a bit are:

+       for (i=0; i
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 13:43:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOqNm-0007MZ-9Y; Thu, 18 Oct 2012 13:43:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOqNk-0007MQ-1Y; Thu, 18 Oct 2012 13:43:28 +0000
Received: from [85.158.143.99:59870] by server-2.bemta-4.messagelabs.com id
	52/54-22268-F7700805; Thu, 18 Oct 2012 13:43:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1350567806!34677100!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12790 invoked from network); 18 Oct 2012 13:43:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 13:43:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,607,1344211200"; d="scan'208";a="15256018"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 13:42:53 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 18 Oct 2012 14:42:53 +0100
Date: Thu, 18 Oct 2012 14:42:29 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1350466992.2460.47.camel@zakaz.uk.xensource.com>
Message-ID: 
References: 
	<1350466992.2460.47.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-users@lists.xen.org" ,
	kk s ,
	Stefano Stabellini ,
	Konrad Rzeszutek Wilk ,
	xen-devel 
Subject: Re: [Xen-devel] [Xen-users] Fedora 17 Dom-U booting issue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 17 Oct 2012, Ian Campbell wrote:
> Adding xen-devel and the relevant maintainers.
> 
> On Tue, 2012-10-16 at 20:24 +0100, kk s wrote:
> > Hi Folks,
> > 
> > 
> > I have upgraded Fedora 16 to 17 on one of Xen HVM Dom-U and it refuses
> > to boot fine and getting the below error on console,
> > 
> > 
> > --------
> > Booting 'Fedora (3.6.1-1.fc17.x86_64)'
> > 
> > 
> > Loading Fedora (3.6.1-1.fc17.x86_64)
> > Loading initial ramdisk ...
> > [   0.000000] Cannot get hvm parameter 18: -22!
> 
> HVM parameter 18 is HVM_PARAM_CONSOLE_EVTCHN.

-22 is EINVAL, that Xen would return only if:

- the requested parameter is out of range
this is not the case, 18 < 30

- the domain is not actually an HVM domain
can you please post your VM config file?



> I'm not sure it's related but commit 5842f5768599 "xen/hvc: Check
> HVM_PARAM_CONSOLE_[EVTCHN|PFN] for correctness." looks a bit dogy to me,
> in particular:
> +       /*
> +        * If the toolstack (or the hypervisor) hasn't set these values, the
> +        * default value is 0. Even though mfn = 0 and evtchn = 0 are
> +        * theoretically correct values, in practice they never are and they
> +        * mean that a legacy toolstack hasn't initialized the pv console correc
> +        */
> 
> The only reason 0 isn't used is pure coincidence because libxl (and
> presumably xend) do:
>     state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, state->store_domid);
>     state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, state->console_domid);
> 
> so the store happens to become port 0 and the console port 1, but I
> think relying on this never changing is pretty fragile.
> 
> If this is being relied on then I suggest that a patch to the hypervisor
> to reject port 0 as a console port would be wise in case someone decides
> to refactor this code and inadvertently changes the order of the
> allocation. At the same time perhaps making the default be some invalid
> port number on the hypervisor side would be a good idea for future
> proofing.

Even if the toolstack didn't set HVM_PARAM_CONSOLE_EVTCHN, or if the
check for 0 is not correct, the guest shouldn't get -EINVAL. I don't
think the error is related to this issue.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 13:43:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 13:43:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOqNm-0007MZ-9Y; Thu, 18 Oct 2012 13:43:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOqNk-0007MQ-1Y; Thu, 18 Oct 2012 13:43:28 +0000
Received: from [85.158.143.99:59870] by server-2.bemta-4.messagelabs.com id
	52/54-22268-F7700805; Thu, 18 Oct 2012 13:43:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1350567806!34677100!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12790 invoked from network); 18 Oct 2012 13:43:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 13:43:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,607,1344211200"; d="scan'208";a="15256018"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 13:42:53 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 18 Oct 2012 14:42:53 +0100
Date: Thu, 18 Oct 2012 14:42:29 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1350466992.2460.47.camel@zakaz.uk.xensource.com>
Message-ID: 
References: 
	<1350466992.2460.47.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-users@lists.xen.org" ,
	kk s ,
	Stefano Stabellini ,
	Konrad Rzeszutek Wilk ,
	xen-devel 
Subject: Re: [Xen-devel] [Xen-users] Fedora 17 Dom-U booting issue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 17 Oct 2012, Ian Campbell wrote:
> Adding xen-devel and the relevant maintainers.
> 
> On Tue, 2012-10-16 at 20:24 +0100, kk s wrote:
> > Hi Folks,
> > 
> > 
> > I have upgraded Fedora 16 to 17 on one of Xen HVM Dom-U and it refuses
> > to boot fine and getting the below error on console,
> > 
> > 
> > --------
> > Booting 'Fedora (3.6.1-1.fc17.x86_64)'
> > 
> > 
> > Loading Fedora (3.6.1-1.fc17.x86_64)
> > Loading initial ramdisk ...
> > [   0.000000] Cannot get hvm parameter 18: -22!
> 
> HVM parameter 18 is HVM_PARAM_CONSOLE_EVTCHN.

-22 is EINVAL, that Xen would return only if:

- the requested parameter is out of range
this is not the case, 18 < 30

- the domain is not actually an HVM domain
can you please post your VM config file?



> I'm not sure it's related but commit 5842f5768599 "xen/hvc: Check
> HVM_PARAM_CONSOLE_[EVTCHN|PFN] for correctness." looks a bit dogy to me,
> in particular:
> +       /*
> +        * If the toolstack (or the hypervisor) hasn't set these values, the
> +        * default value is 0. Even though mfn = 0 and evtchn = 0 are
> +        * theoretically correct values, in practice they never are and they
> +        * mean that a legacy toolstack hasn't initialized the pv console correc
> +        */
> 
> The only reason 0 isn't used is pure coincidence because libxl (and
> presumably xend) do:
>     state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, state->store_domid);
>     state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, state->console_domid);
> 
> so the store happens to become port 0 and the console port 1, but I
> think relying on this never changing is pretty fragile.
> 
> If this is being relied on then I suggest that a patch to the hypervisor
> to reject port 0 as a console port would be wise in case someone decides
> to refactor this code and inadvertently changes the order of the
> allocation. At the same time perhaps making the default be some invalid
> port number on the hypervisor side would be a good idea for future
> proofing.

Even if the toolstack didn't set HVM_PARAM_CONSOLE_EVTCHN, or if the
check for 0 is not correct, the guest shouldn't get -EINVAL. I don't
think the error is related to this issue.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 13:46:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 13:46:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOqQP-0007cL-GI; Thu, 18 Oct 2012 13:46:13 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOqQN-0007c5-I1; Thu, 18 Oct 2012 13:46:11 +0000
Received: from [193.109.254.147:57347] by server-8.bemta-14.messagelabs.com id
	70/11-16549-22800805; Thu, 18 Oct 2012 13:46:10 +0000
X-Env-Sender: Philippe.Simonet@swisscom.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1350567966!10328614!1
X-Originating-IP: [193.222.81.100]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkzLjIyMi44MS4xMDAgPT4gOTg2OTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7447 invoked from network); 18 Oct 2012 13:46:07 -0000
Received: from outmail100.swisscom.com (HELO mail.swisscom.com)
	(193.222.81.100)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Oct 2012 13:46:07 -0000
Received: by mail.swisscom.com; Thu, 18 Oct 2012 15:45:52 +0200
From: 
To: , 
Thread-Topic: [Xen-devel] [Xen-users]   Re: Xen 4 TSC problems
Thread-Index: AQHNrQPokzEo6fEyWkKWYKkQrivnaZe/Ekkg
Date: Thu, 18 Oct 2012 13:45:43 +0000
Message-ID: 
References: 
	<1350546021.28188.20.camel@dagon.hellion.org.uk>
In-Reply-To: <1350546021.28188.20.camel@dagon.hellion.org.uk>
Accept-Language: en-US, de-CH
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.65.122.36]
MIME-Version: 1.0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, dan.magenheimer@oracle.com,
	mrsanna1@gmail.com, olivier.hanesse@gmail.com, JBeulich@suse.com,
	xen-users@lists.xensource.com, mark@campbell-lange.net
Subject: Re: [Xen-devel] [Xen-users]   Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

in the meantime, it would be cool to have a kernel boot parameter that could disable this wrapping'
correction' ? like 

> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
> bounces@lists.xen.org] On Behalf Of Ian Campbell
> Sent: Thursday, October 18, 2012 9:40 AM
> To: Keir Fraser
> Cc: Jeremy Fitzhardinge; xen-devel@lists.xensource.com; Dan
> Magenheimer; Mauro; Olivier Hanesse; Jan Beulich; Xen Users; Mark Adams
> Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
> 
> On Wed, 2012-10-17 at 17:15 +0100, Keir Fraser wrote:
> > @@ -540,6 +541,14 @@ static void plt_overflow(void *unused)
> >          plt_wrap = __read_platform_stime(plt_stamp64 + plt_mask + 1);
> >          if ( ABS(plt_wrap - now) > ABS(plt_now - now) )
> >              break;
> > +        rdtscll(tsc);
> > +        printk("XXX plt_overflow: plt_now=%"PRIx64" plt_wrap=%"PRIx64
> > +               " now=%"PRIx64" old_stamp=%"PRIx64" new_stamp=%"PRIx64
> > +               " plt_stamp64=%"PRIx64" plt_mask=%"PRIx64
> > +               " tsc=%"PRIx64" tsc_stamp=%"PRIx64"\n",
> > +               plt_now, plt_wrap, now, old_stamp, plt_stamp, plt_stamp64,
> > +               plt_mask, tsc, this_cpu(cpu_time).local_tsc_stamp);
> > +        break;
> 
> Is the break here, making the following update to plt_stamp64 dead code
> deliberate?
> 
> >          plt_stamp64 += plt_mask + 1;
> >      }
> >      if ( i != 0 )
> 
> Ian.
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 13:46:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 13:46:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOqQP-0007cL-GI; Thu, 18 Oct 2012 13:46:13 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOqQN-0007c5-I1; Thu, 18 Oct 2012 13:46:11 +0000
Received: from [193.109.254.147:57347] by server-8.bemta-14.messagelabs.com id
	70/11-16549-22800805; Thu, 18 Oct 2012 13:46:10 +0000
X-Env-Sender: Philippe.Simonet@swisscom.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1350567966!10328614!1
X-Originating-IP: [193.222.81.100]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkzLjIyMi44MS4xMDAgPT4gOTg2OTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7447 invoked from network); 18 Oct 2012 13:46:07 -0000
Received: from outmail100.swisscom.com (HELO mail.swisscom.com)
	(193.222.81.100)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Oct 2012 13:46:07 -0000
Received: by mail.swisscom.com; Thu, 18 Oct 2012 15:45:52 +0200
From: 
To: , 
Thread-Topic: [Xen-devel] [Xen-users]   Re: Xen 4 TSC problems
Thread-Index: AQHNrQPokzEo6fEyWkKWYKkQrivnaZe/Ekkg
Date: Thu, 18 Oct 2012 13:45:43 +0000
Message-ID: 
References: 
	<1350546021.28188.20.camel@dagon.hellion.org.uk>
In-Reply-To: <1350546021.28188.20.camel@dagon.hellion.org.uk>
Accept-Language: en-US, de-CH
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.65.122.36]
MIME-Version: 1.0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, dan.magenheimer@oracle.com,
	mrsanna1@gmail.com, olivier.hanesse@gmail.com, JBeulich@suse.com,
	xen-users@lists.xensource.com, mark@campbell-lange.net
Subject: Re: [Xen-devel] [Xen-users]   Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

in the meantime, it would be cool to have a kernel boot parameter that could disable this wrapping'
correction' ? like 

> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
> bounces@lists.xen.org] On Behalf Of Ian Campbell
> Sent: Thursday, October 18, 2012 9:40 AM
> To: Keir Fraser
> Cc: Jeremy Fitzhardinge; xen-devel@lists.xensource.com; Dan
> Magenheimer; Mauro; Olivier Hanesse; Jan Beulich; Xen Users; Mark Adams
> Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
> 
> On Wed, 2012-10-17 at 17:15 +0100, Keir Fraser wrote:
> > @@ -540,6 +541,14 @@ static void plt_overflow(void *unused)
> >          plt_wrap = __read_platform_stime(plt_stamp64 + plt_mask + 1);
> >          if ( ABS(plt_wrap - now) > ABS(plt_now - now) )
> >              break;
> > +        rdtscll(tsc);
> > +        printk("XXX plt_overflow: plt_now=%"PRIx64" plt_wrap=%"PRIx64
> > +               " now=%"PRIx64" old_stamp=%"PRIx64" new_stamp=%"PRIx64
> > +               " plt_stamp64=%"PRIx64" plt_mask=%"PRIx64
> > +               " tsc=%"PRIx64" tsc_stamp=%"PRIx64"\n",
> > +               plt_now, plt_wrap, now, old_stamp, plt_stamp, plt_stamp64,
> > +               plt_mask, tsc, this_cpu(cpu_time).local_tsc_stamp);
> > +        break;
> 
> Is the break here, making the following update to plt_stamp64 dead code
> deliberate?
> 
> >          plt_stamp64 += plt_mask + 1;
> >      }
> >      if ( i != 0 )
> 
> Ian.
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 13:47:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 13:47:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOqRP-0007jS-7J; Thu, 18 Oct 2012 13:47:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOqRN-0007jD-IQ
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 13:47:13 +0000
Received: from [85.158.139.83:26320] by server-16.bemta-5.messagelabs.com id
	51/CB-09196-06800805; Thu, 18 Oct 2012 13:47:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1350568032!28127537!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31559 invoked from network); 18 Oct 2012 13:47:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 13:47:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,607,1344211200"; d="scan'208";a="15256152"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 13:47:11 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 14:47:12 +0100
Message-ID: <1350568030.2460.149.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Thu, 18 Oct 2012 14:47:10 +0100
In-Reply-To: 
References: <1350473518.2460.58.camel@zakaz.uk.xensource.com>
	<1350473532-15863-5-git-send-email-ian.campbell@citrix.com>
	
	<1350567209.2460.145.camel@zakaz.uk.xensource.com>
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 5/6] xen: arm: implement remap interfaces
 needed for privcmd mappings.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-18 at 14:35 +0100, Stefano Stabellini wrote:
> On Thu, 18 Oct 2012, Ian Campbell wrote:
> > On Thu, 2012-10-18 at 14:27 +0100, Stefano Stabellini wrote:
> > > On Wed, 17 Oct 2012, Ian Campbell wrote:
> > > > We use XENMEM_add_to_physmap_range which is the preferred interface
> > > > for foreign mappings.
> > > > 
> > > > Signed-off-by: Ian Campbell 
> > > 
> > > It looks OK but there are few code style issues, please run the patch
> > > through checkpatch.
> > 
> > The only one I get is:
> > WARNING: please, no spaces at the start of a line
> > #83: FILE: include/xen/interface/memory.h:175:
> > +    uint16_t    size;$
> > 
> > total: 0 errors, 1 warnings, 64 lines checked
> > 
> > The prevailing indentation in that file is 4 spaces so I think we should
> > ignore the warning in this case in the interests of consistency with the
> > surrounding code.
> 
> Strange, I get:

I'm running v3.7-rc1-187-g7bbf07e so it is pretty recent.
[...]

> total: 2 errors, 6 warnings, 162 lines checked

Ah, I was looking at patch 6/6... 

The warnings in this one are all of the same class as before (4 space
indentation). But you are right, the other two need fixing. Done in my
tree.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 13:47:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 13:47:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOqRP-0007jS-7J; Thu, 18 Oct 2012 13:47:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOqRN-0007jD-IQ
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 13:47:13 +0000
Received: from [85.158.139.83:26320] by server-16.bemta-5.messagelabs.com id
	51/CB-09196-06800805; Thu, 18 Oct 2012 13:47:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1350568032!28127537!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31559 invoked from network); 18 Oct 2012 13:47:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 13:47:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,607,1344211200"; d="scan'208";a="15256152"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 13:47:11 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 14:47:12 +0100
Message-ID: <1350568030.2460.149.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Thu, 18 Oct 2012 14:47:10 +0100
In-Reply-To: 
References: <1350473518.2460.58.camel@zakaz.uk.xensource.com>
	<1350473532-15863-5-git-send-email-ian.campbell@citrix.com>
	
	<1350567209.2460.145.camel@zakaz.uk.xensource.com>
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 5/6] xen: arm: implement remap interfaces
 needed for privcmd mappings.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-18 at 14:35 +0100, Stefano Stabellini wrote:
> On Thu, 18 Oct 2012, Ian Campbell wrote:
> > On Thu, 2012-10-18 at 14:27 +0100, Stefano Stabellini wrote:
> > > On Wed, 17 Oct 2012, Ian Campbell wrote:
> > > > We use XENMEM_add_to_physmap_range which is the preferred interface
> > > > for foreign mappings.
> > > > 
> > > > Signed-off-by: Ian Campbell 
> > > 
> > > It looks OK but there are few code style issues, please run the patch
> > > through checkpatch.
> > 
> > The only one I get is:
> > WARNING: please, no spaces at the start of a line
> > #83: FILE: include/xen/interface/memory.h:175:
> > +    uint16_t    size;$
> > 
> > total: 0 errors, 1 warnings, 64 lines checked
> > 
> > The prevailing indentation in that file is 4 spaces so I think we should
> > ignore the warning in this case in the interests of consistency with the
> > surrounding code.
> 
> Strange, I get:

I'm running v3.7-rc1-187-g7bbf07e so it is pretty recent.
[...]

> total: 2 errors, 6 warnings, 162 lines checked

Ah, I was looking at patch 6/6... 

The warnings in this one are all of the same class as before (4 space
indentation). But you are right, the other two need fixing. Done in my
tree.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 13:49:49 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 13:49:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOqTi-0007y9-PP; Thu, 18 Oct 2012 13:49:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOqTh-0007xu-8o; Thu, 18 Oct 2012 13:49:37 +0000
Received: from [85.158.143.35:62840] by server-1.bemta-4.messagelabs.com id
	DE/10-19134-0F800805; Thu, 18 Oct 2012 13:49:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1350568156!5837639!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22733 invoked from network); 18 Oct 2012 13:49:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 13:49:16 -0000
X-IronPort-AV: E=Sophos;i="4.80,607,1344211200"; d="scan'208";a="15256201"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 13:49:16 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 14:49:16 +0100
Message-ID: <1350568154.2460.151.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Thu, 18 Oct 2012 14:49:14 +0100
In-Reply-To: 
References: 
	<1350466992.2460.47.camel@zakaz.uk.xensource.com>
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-users@lists.xen.org" ,
	kk s , Konrad Rzeszutek Wilk ,
	xen-devel 
Subject: Re: [Xen-devel] [Xen-users] Fedora 17 Dom-U booting issue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-18 at 14:42 +0100, Stefano Stabellini wrote:
> On Wed, 17 Oct 2012, Ian Campbell wrote:
> > Adding xen-devel and the relevant maintainers.
> > 
> > On Tue, 2012-10-16 at 20:24 +0100, kk s wrote:
> > > Hi Folks,
> > > 
> > > 
> > > I have upgraded Fedora 16 to 17 on one of Xen HVM Dom-U and it refuses
> > > to boot fine and getting the below error on console,
> > > 
> > > 
> > > --------
> > > Booting 'Fedora (3.6.1-1.fc17.x86_64)'
> > > 
> > > 
> > > Loading Fedora (3.6.1-1.fc17.x86_64)
> > > Loading initial ramdisk ...
> > > [   0.000000] Cannot get hvm parameter 18: -22!
> > 
> > HVM parameter 18 is HVM_PARAM_CONSOLE_EVTCHN.
> 
> -22 is EINVAL, that Xen would return only if:
> 
> - the requested parameter is out of range
> this is not the case, 18 < 30

The hypervisor here is 3.4.3 where the largest hvm param is:
$ grep define.HVM_PARAM xen-3.4-testing.hg/xen/include/public/hvm/params.h | sort -k3 -n | tail -n 3
#define HVM_PARAM_ACPI_S_STATE 14
#define HVM_PARAM_VM86_TSS     15
#define HVM_PARAM_VPT_ALIGN    16

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 13:49:49 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 13:49:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOqTi-0007y9-PP; Thu, 18 Oct 2012 13:49:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOqTh-0007xu-8o; Thu, 18 Oct 2012 13:49:37 +0000
Received: from [85.158.143.35:62840] by server-1.bemta-4.messagelabs.com id
	DE/10-19134-0F800805; Thu, 18 Oct 2012 13:49:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1350568156!5837639!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22733 invoked from network); 18 Oct 2012 13:49:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 13:49:16 -0000
X-IronPort-AV: E=Sophos;i="4.80,607,1344211200"; d="scan'208";a="15256201"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 13:49:16 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 18 Oct 2012 14:49:16 +0100
Message-ID: <1350568154.2460.151.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Thu, 18 Oct 2012 14:49:14 +0100
In-Reply-To: 
References: 
	<1350466992.2460.47.camel@zakaz.uk.xensource.com>
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-users@lists.xen.org" ,
	kk s , Konrad Rzeszutek Wilk ,
	xen-devel 
Subject: Re: [Xen-devel] [Xen-users] Fedora 17 Dom-U booting issue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-18 at 14:42 +0100, Stefano Stabellini wrote:
> On Wed, 17 Oct 2012, Ian Campbell wrote:
> > Adding xen-devel and the relevant maintainers.
> > 
> > On Tue, 2012-10-16 at 20:24 +0100, kk s wrote:
> > > Hi Folks,
> > > 
> > > 
> > > I have upgraded Fedora 16 to 17 on one of Xen HVM Dom-U and it refuses
> > > to boot fine and getting the below error on console,
> > > 
> > > 
> > > --------
> > > Booting 'Fedora (3.6.1-1.fc17.x86_64)'
> > > 
> > > 
> > > Loading Fedora (3.6.1-1.fc17.x86_64)
> > > Loading initial ramdisk ...
> > > [   0.000000] Cannot get hvm parameter 18: -22!
> > 
> > HVM parameter 18 is HVM_PARAM_CONSOLE_EVTCHN.
> 
> -22 is EINVAL, that Xen would return only if:
> 
> - the requested parameter is out of range
> this is not the case, 18 < 30

The hypervisor here is 3.4.3 where the largest hvm param is:
$ grep define.HVM_PARAM xen-3.4-testing.hg/xen/include/public/hvm/params.h | sort -k3 -n | tail -n 3
#define HVM_PARAM_ACPI_S_STATE 14
#define HVM_PARAM_VM86_TSS     15
#define HVM_PARAM_VPT_ALIGN    16

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 14:42:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 14:42:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOrIP-0000iF-WE; Thu, 18 Oct 2012 14:42:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOrIO-0000i7-3N
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 14:42:00 +0000
Received: from [85.158.143.99:50234] by server-3.bemta-4.messagelabs.com id
	0C/09-03544-73510805; Thu, 18 Oct 2012 14:41:59 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1350571317!24866107!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4839 invoked from network); 18 Oct 2012 14:41:58 -0000
Received: from mail-vc0-f171.google.com (HELO mail-vc0-f171.google.com)
	(209.85.220.171)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 14:41:58 -0000
Received: by mail-vc0-f171.google.com with SMTP id m18so12014746vcm.30
	for ;
	Thu, 18 Oct 2012 07:41:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=NkZJLPc4jzkiDiC+DiCfzpYVyeBgG/AZESDYF+Ywpkw=;
	b=Ko4I7PI2CUx80busVFgmf7vBX5DwQvWwyHcefDFiFqOTfM2UtAW2EsgliF0dJ4PMm3
	Qy+cfj2IDD3QN4gmY9aC1/xPrzHsM+zSwbdZ1VO+2+XJeqV2PWIUt3FGJQRGrBSGcbQI
	V6Hco3t/YVCR8JdtCrQdnejsTlSjnBuZ/7WOda4qaOBlxEn7MPPiBSCEydWvtQIrufBQ
	BPlJxQ8C+8byYhoV8uab6t6TmWKJ0fpPHX1XUa5Jt0DxN6Po3eN3ocTqNTTPHsHndJeI
	O8rdXkrHhh9+kxU/eYtOYWK3ISP15sXar/3CecGJlze4tHqz98W7m8Jo0zN/Uw18uMiM
	Jr8g==
MIME-Version: 1.0
Received: by 10.220.152.11 with SMTP id e11mr5654782vcw.61.1350571317227; Thu,
	18 Oct 2012 07:41:57 -0700 (PDT)
Received: by 10.58.231.138 with HTTP; Thu, 18 Oct 2012 07:41:57 -0700 (PDT)
In-Reply-To: <20121012173222.31965.33368.sendpatchset@magnum.int.mccr.org>
References: <20121012173222.31965.33368.sendpatchset@magnum.int.mccr.org>
Date: Thu, 18 Oct 2012 15:41:57 +0100
X-Google-Sender-Auth: jmxN7Ai5R-X9e_3CmYPfKbOmGJ0
Message-ID: 
From: George Dunlap 
To: Dave McCracken 
Cc: Xen Developers List ,
	Keir Fraser 
Subject: Re: [Xen-devel] [PATCH] Make restore work properly with PV
	superpage flag
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 12, 2012 at 6:32 PM, Dave McCracken  wrote:
> For PV guests, the superpage flag means to unconditionally allocate all
> pages as superpages, which is required for Linux hugepages to work.  Support
> for this on restore was not supported.  This patch adds proper support for
> the superpage flag on restore.
>
> For HVM guests, the superpage flag has been used to mean attempt to allocate
> superpages if possible on restore.  This functionality has been preserved.
>
> Signed-off-by: Dave McCracken 

Looks good -- boy, when you know that all of your pages have to be
superpages, it makes the logic a lot easier. :-)  Unfortunately that's
not the case for HVM guests, so we need to keep the complicated
detection logic.

I was trying to think of a way to make the "hvm" and "superpage" based
on the desired behavior (e.g, "detect_superpages",
"always_superpages", or something like that), rather than having to
encode "!hvm && superpage" all over the place, but I think in the end
the way you've written it is fine.

Acked-by: George Dunlap 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 14:42:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 14:42:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOrIP-0000iF-WE; Thu, 18 Oct 2012 14:42:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOrIO-0000i7-3N
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 14:42:00 +0000
Received: from [85.158.143.99:50234] by server-3.bemta-4.messagelabs.com id
	0C/09-03544-73510805; Thu, 18 Oct 2012 14:41:59 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1350571317!24866107!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4839 invoked from network); 18 Oct 2012 14:41:58 -0000
Received: from mail-vc0-f171.google.com (HELO mail-vc0-f171.google.com)
	(209.85.220.171)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 14:41:58 -0000
Received: by mail-vc0-f171.google.com with SMTP id m18so12014746vcm.30
	for ;
	Thu, 18 Oct 2012 07:41:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=NkZJLPc4jzkiDiC+DiCfzpYVyeBgG/AZESDYF+Ywpkw=;
	b=Ko4I7PI2CUx80busVFgmf7vBX5DwQvWwyHcefDFiFqOTfM2UtAW2EsgliF0dJ4PMm3
	Qy+cfj2IDD3QN4gmY9aC1/xPrzHsM+zSwbdZ1VO+2+XJeqV2PWIUt3FGJQRGrBSGcbQI
	V6Hco3t/YVCR8JdtCrQdnejsTlSjnBuZ/7WOda4qaOBlxEn7MPPiBSCEydWvtQIrufBQ
	BPlJxQ8C+8byYhoV8uab6t6TmWKJ0fpPHX1XUa5Jt0DxN6Po3eN3ocTqNTTPHsHndJeI
	O8rdXkrHhh9+kxU/eYtOYWK3ISP15sXar/3CecGJlze4tHqz98W7m8Jo0zN/Uw18uMiM
	Jr8g==
MIME-Version: 1.0
Received: by 10.220.152.11 with SMTP id e11mr5654782vcw.61.1350571317227; Thu,
	18 Oct 2012 07:41:57 -0700 (PDT)
Received: by 10.58.231.138 with HTTP; Thu, 18 Oct 2012 07:41:57 -0700 (PDT)
In-Reply-To: <20121012173222.31965.33368.sendpatchset@magnum.int.mccr.org>
References: <20121012173222.31965.33368.sendpatchset@magnum.int.mccr.org>
Date: Thu, 18 Oct 2012 15:41:57 +0100
X-Google-Sender-Auth: jmxN7Ai5R-X9e_3CmYPfKbOmGJ0
Message-ID: 
From: George Dunlap 
To: Dave McCracken 
Cc: Xen Developers List ,
	Keir Fraser 
Subject: Re: [Xen-devel] [PATCH] Make restore work properly with PV
	superpage flag
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 12, 2012 at 6:32 PM, Dave McCracken  wrote:
> For PV guests, the superpage flag means to unconditionally allocate all
> pages as superpages, which is required for Linux hugepages to work.  Support
> for this on restore was not supported.  This patch adds proper support for
> the superpage flag on restore.
>
> For HVM guests, the superpage flag has been used to mean attempt to allocate
> superpages if possible on restore.  This functionality has been preserved.
>
> Signed-off-by: Dave McCracken 

Looks good -- boy, when you know that all of your pages have to be
superpages, it makes the logic a lot easier. :-)  Unfortunately that's
not the case for HVM guests, so we need to keep the complicated
detection logic.

I was trying to think of a way to make the "hvm" and "superpage" based
on the desired behavior (e.g, "detect_superpages",
"always_superpages", or something like that), rather than having to
encode "!hvm && superpage" all over the place, but I think in the end
the way you've written it is fine.

Acked-by: George Dunlap 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 14:46:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 14:46:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOrMK-0000sm-Lp; Thu, 18 Oct 2012 14:46:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOrMJ-0000sg-Ll
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 14:46:03 +0000
Received: from [85.158.139.83:8656] by server-3.bemta-5.messagelabs.com id
	22/E6-28618-92610805; Thu, 18 Oct 2012 14:46:01 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1350571558!35452980!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgxOTgxMA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1124 invoked from network); 18 Oct 2012 14:45:59 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Oct 2012 14:45:59 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9IEjt50017283
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 18 Oct 2012 14:45:55 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9IEjs9v011140
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 18 Oct 2012 14:45:54 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9IEjs16028814; Thu, 18 Oct 2012 09:45:54 -0500
Received: from localhost.localdomain (/208.54.36.186)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 18 Oct 2012 07:45:53 -0700
Date: Thu, 18 Oct 2012 10:45:41 -0400
From: Konrad Rzeszutek Wilk 
To: "H. Peter Anvin" 
Message-ID: <20121018144538.GA19782@localhost.localdomain>
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	<1350481786-4969-3-git-send-email-konrad.wilk@oracle.com>
	<507F4475.80705@zytor.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <507F4475.80705@zytor.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: linux-acpi@vger.kernel.org, x86@kernel.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH 2/4] xen/lowlevel: Implement pvop call for
 load_idt (sidt).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 17, 2012 at 04:51:17PM -0700, H. Peter Anvin wrote:
> On 10/17/2012 06:49 AM, Konrad Rzeszutek Wilk wrote:
> >In the past it used to point to 'sidt' (native_store_idt) operation
> >which is a non-privileged operation. This resulted in the
> >'struct desc_ptr' value containing the address of Xen's IDT table,
> >instead of the IDT table that Linux thinks its using. The end result
> >is that doing:
> >
> >   store_idt(&desc);
> >   load_idt(&desc);
> >
> >would blow up b/c xen_load_idt would try to parse the IDT contents
> >(desc) and de-reference a virtual address that is outside Linux's
> >__va (it is in Xen's virtual address).
> >
> >With this patch we are providing the last written IDT address.
> >
> 
> OK... this seems like another excellent set of pvops calls that
> should be nukable to Kingdom Come.  There is no reason, ever, to
> read the IDT and GDT from the kernel... the kernel already knows
> what they should be!

Even during suspend and resume cycle? There are the sequence of
sidt/lidt calls being done there. And we do need to filter at
least the sidt call - and in the case of ACPI suspend path,
the lidt.
> 
> 	-hpa
> 
> 
> -- 
> H. Peter Anvin, Intel Open Source Technology Center
> I work for Intel.  I don't speak on their behalf.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 14:46:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 14:46:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOrMK-0000sm-Lp; Thu, 18 Oct 2012 14:46:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOrMJ-0000sg-Ll
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 14:46:03 +0000
Received: from [85.158.139.83:8656] by server-3.bemta-5.messagelabs.com id
	22/E6-28618-92610805; Thu, 18 Oct 2012 14:46:01 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1350571558!35452980!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgxOTgxMA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1124 invoked from network); 18 Oct 2012 14:45:59 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Oct 2012 14:45:59 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9IEjt50017283
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 18 Oct 2012 14:45:55 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9IEjs9v011140
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 18 Oct 2012 14:45:54 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9IEjs16028814; Thu, 18 Oct 2012 09:45:54 -0500
Received: from localhost.localdomain (/208.54.36.186)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 18 Oct 2012 07:45:53 -0700
Date: Thu, 18 Oct 2012 10:45:41 -0400
From: Konrad Rzeszutek Wilk 
To: "H. Peter Anvin" 
Message-ID: <20121018144538.GA19782@localhost.localdomain>
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	<1350481786-4969-3-git-send-email-konrad.wilk@oracle.com>
	<507F4475.80705@zytor.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <507F4475.80705@zytor.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: linux-acpi@vger.kernel.org, x86@kernel.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH 2/4] xen/lowlevel: Implement pvop call for
 load_idt (sidt).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 17, 2012 at 04:51:17PM -0700, H. Peter Anvin wrote:
> On 10/17/2012 06:49 AM, Konrad Rzeszutek Wilk wrote:
> >In the past it used to point to 'sidt' (native_store_idt) operation
> >which is a non-privileged operation. This resulted in the
> >'struct desc_ptr' value containing the address of Xen's IDT table,
> >instead of the IDT table that Linux thinks its using. The end result
> >is that doing:
> >
> >   store_idt(&desc);
> >   load_idt(&desc);
> >
> >would blow up b/c xen_load_idt would try to parse the IDT contents
> >(desc) and de-reference a virtual address that is outside Linux's
> >__va (it is in Xen's virtual address).
> >
> >With this patch we are providing the last written IDT address.
> >
> 
> OK... this seems like another excellent set of pvops calls that
> should be nukable to Kingdom Come.  There is no reason, ever, to
> read the IDT and GDT from the kernel... the kernel already knows
> what they should be!

Even during suspend and resume cycle? There are the sequence of
sidt/lidt calls being done there. And we do need to filter at
least the sidt call - and in the case of ACPI suspend path,
the lidt.
> 
> 	-hpa
> 
> 
> -- 
> H. Peter Anvin, Intel Open Source Technology Center
> I work for Intel.  I don't speak on their behalf.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 14:47:06 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 14:47:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOrN1-0000w2-36; Thu, 18 Oct 2012 14:46:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOrMz-0000vs-UR
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 14:46:46 +0000
Received: from [85.158.137.99:8214] by server-13.bemta-3.messagelabs.com id
	A4/3E-26794-55610805; Thu, 18 Oct 2012 14:46:45 +0000
X-Env-Sender: dcm@mccr.org
X-Msg-Ref: server-11.tower-217.messagelabs.com!1350571603!20900082!1
X-Originating-IP: [204.13.248.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA0LjEzLjI0OC43NCA9PiA3NjE1MA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17730 invoked from network); 18 Oct 2012 14:46:44 -0000
Received: from mho-04-ewr.mailhop.org (HELO mho-02-ewr.mailhop.org)
	(204.13.248.74)
	by server-11.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Oct 2012 14:46:44 -0000
Received: from [67.21.176.24] (helo=magnum.localnet)
	by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256)
	(Exim 4.72) (envelope-from )
	id 1TOrMx-000MPx-LA; Thu, 18 Oct 2012 14:46:43 +0000
X-Mail-Handler: Dyn Standard SMTP by Dyn
X-Originating-IP: 67.21.176.24
X-Report-Abuse-To: abuse@dyndns.com (see
	http://www.dyndns.com/services/sendlabs/outbound_abuse.html for
	abuse reporting information)
X-MHO-User: U2FsdGVkX18FkfyFMKc5cJgiq7zcXzjZnTuC1T31SIM=
From: Dave McCracken 
To: George Dunlap 
Date: Thu, 18 Oct 2012 09:46:41 -0500
User-Agent: KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; )
References: <20121012173222.31965.33368.sendpatchset@magnum.int.mccr.org>
	
In-Reply-To: 
MIME-Version: 1.0
Message-Id: <201210180946.41472.dcm@mccr.org>
Cc: Xen Developers List ,
	Keir Fraser 
Subject: Re: [Xen-devel] [PATCH] Make restore work properly with PV
	superpage flag
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thursday, October 18, 2012, George Dunlap wrote:
> Looks good -- boy, when you know that all of your pages have to be
> superpages, it makes the logic a lot easier. :-)  Unfortunately that's
> not the case for HVM guests, so we need to keep the complicated
> detection logic.
> 
> I was trying to think of a way to make the "hvm" and "superpage" based
> on the desired behavior (e.g, "detect_superpages",
> "always_superpages", or something like that), rather than having to
> encode "!hvm && superpage" all over the place, but I think in the end
> the way you've written it is fine.

Yeah, I spent a lot of time trying to make some integrated way to do both 
types of allocation, but finally gave up and kept the two code paths separate.  
In the end I think it's cleaner that way.

Dave

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 14:47:06 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 14:47:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOrN1-0000w2-36; Thu, 18 Oct 2012 14:46:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOrMz-0000vs-UR
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 14:46:46 +0000
Received: from [85.158.137.99:8214] by server-13.bemta-3.messagelabs.com id
	A4/3E-26794-55610805; Thu, 18 Oct 2012 14:46:45 +0000
X-Env-Sender: dcm@mccr.org
X-Msg-Ref: server-11.tower-217.messagelabs.com!1350571603!20900082!1
X-Originating-IP: [204.13.248.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA0LjEzLjI0OC43NCA9PiA3NjE1MA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17730 invoked from network); 18 Oct 2012 14:46:44 -0000
Received: from mho-04-ewr.mailhop.org (HELO mho-02-ewr.mailhop.org)
	(204.13.248.74)
	by server-11.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Oct 2012 14:46:44 -0000
Received: from [67.21.176.24] (helo=magnum.localnet)
	by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256)
	(Exim 4.72) (envelope-from )
	id 1TOrMx-000MPx-LA; Thu, 18 Oct 2012 14:46:43 +0000
X-Mail-Handler: Dyn Standard SMTP by Dyn
X-Originating-IP: 67.21.176.24
X-Report-Abuse-To: abuse@dyndns.com (see
	http://www.dyndns.com/services/sendlabs/outbound_abuse.html for
	abuse reporting information)
X-MHO-User: U2FsdGVkX18FkfyFMKc5cJgiq7zcXzjZnTuC1T31SIM=
From: Dave McCracken 
To: George Dunlap 
Date: Thu, 18 Oct 2012 09:46:41 -0500
User-Agent: KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; )
References: <20121012173222.31965.33368.sendpatchset@magnum.int.mccr.org>
	
In-Reply-To: 
MIME-Version: 1.0
Message-Id: <201210180946.41472.dcm@mccr.org>
Cc: Xen Developers List ,
	Keir Fraser 
Subject: Re: [Xen-devel] [PATCH] Make restore work properly with PV
	superpage flag
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thursday, October 18, 2012, George Dunlap wrote:
> Looks good -- boy, when you know that all of your pages have to be
> superpages, it makes the logic a lot easier. :-)  Unfortunately that's
> not the case for HVM guests, so we need to keep the complicated
> detection logic.
> 
> I was trying to think of a way to make the "hvm" and "superpage" based
> on the desired behavior (e.g, "detect_superpages",
> "always_superpages", or something like that), rather than having to
> encode "!hvm && superpage" all over the place, but I think in the end
> the way you've written it is fine.

Yeah, I spent a lot of time trying to make some integrated way to do both 
types of allocation, but finally gave up and kept the two code paths separate.  
In the end I think it's cleaner that way.

Dave

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 14:47:47 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 14:47:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOrNf-00011f-HI; Thu, 18 Oct 2012 14:47:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOrNe-00011N-5v
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 14:47:26 +0000
Received: from [85.158.139.211:4880] by server-1.bemta-5.messagelabs.com id
	9E/63-21640-D7610805; Thu, 18 Oct 2012 14:47:25 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1350571643!22874251!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgxOTgxMA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 352 invoked from network); 18 Oct 2012 14:47:24 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Oct 2012 14:47:24 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9IElGQs019092
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 18 Oct 2012 14:47:16 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9IElFd4010880
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 18 Oct 2012 14:47:16 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9IElF7H009902; Thu, 18 Oct 2012 09:47:15 -0500
Received: from localhost.localdomain (/208.54.36.186)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 18 Oct 2012 07:47:15 -0700
Date: Thu, 18 Oct 2012 10:47:12 -0400
From: Konrad Rzeszutek Wilk 
To: "H. Peter Anvin" 
Message-ID: <20121018144709.GB19782@localhost.localdomain>
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	<1350481786-4969-2-git-send-email-konrad.wilk@oracle.com>
	<507F473D.1060700@zytor.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <507F473D.1060700@zytor.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: linux-acpi@vger.kernel.org, x86@kernel.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH 1/4] x86/wakeup/sleep: Check whether the TSS
 GDT descriptor is empty before using it.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 17, 2012 at 05:03:09PM -0700, H. Peter Anvin wrote:
> On 10/17/2012 06:49 AM, Konrad Rzeszutek Wilk wrote:
> >We check the TSS descriptor before we try to dereference it.
> >Also fix up the value to use the #defines.
> >
> >Signed-off-by: Konrad Rzeszutek Wilk 
> >---
> >  arch/x86/power/cpu.c |    7 +++++--
> >  1 files changed, 5 insertions(+), 2 deletions(-)
> >
> >diff --git a/arch/x86/power/cpu.c b/arch/x86/power/cpu.c
> >index 218cdb1..c17370e 100644
> >--- a/arch/x86/power/cpu.c
> >+++ b/arch/x86/power/cpu.c
> >@@ -133,7 +133,9 @@ static void fix_processor_context(void)
> >  {
> >  	int cpu = smp_processor_id();
> >  	struct tss_struct *t = &per_cpu(init_tss, cpu);
> >-
> >+#ifdef CONFIG_X86_64
> >+	struct desc_struct *desc = get_cpu_gdt_table(cpu);
> >+#endif
> >  	set_tss_desc(cpu, t);	/*
> >  				 * This just modifies memory; should not be
> >  				 * necessary. But... This is necessary, because
> >@@ -142,7 +144,8 @@ static void fix_processor_context(void)
> >  				 */
> >
> >  #ifdef CONFIG_X86_64
> >-	get_cpu_gdt_table(cpu)[GDT_ENTRY_TSS].type = 9;
> >+	if (!desc_empty(&desc[GDT_ENTRY_TSS]))
> >+		desc[GDT_ENTRY_TSS].type = DESC_TSS;
> >
> >  	syscall_init();				/* This sets MSR_*STAR and related */
> >  #endif
> >
> 
> Why is this patch necessary?  Presumably there is something further
> down the line which depends on the TSS descriptor being empty, but
> if so, what?

I could not find it. This write has been in the code since the initial
git history. Is the pre-git bitkeeper tree somewhere available?
> 
> 	-hpa
> 
> -- 
> H. Peter Anvin, Intel Open Source Technology Center
> I work for Intel.  I don't speak on their behalf.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 14:47:47 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 14:47:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOrNf-00011f-HI; Thu, 18 Oct 2012 14:47:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOrNe-00011N-5v
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 14:47:26 +0000
Received: from [85.158.139.211:4880] by server-1.bemta-5.messagelabs.com id
	9E/63-21640-D7610805; Thu, 18 Oct 2012 14:47:25 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1350571643!22874251!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgxOTgxMA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 352 invoked from network); 18 Oct 2012 14:47:24 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Oct 2012 14:47:24 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9IElGQs019092
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 18 Oct 2012 14:47:16 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9IElFd4010880
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 18 Oct 2012 14:47:16 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9IElF7H009902; Thu, 18 Oct 2012 09:47:15 -0500
Received: from localhost.localdomain (/208.54.36.186)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 18 Oct 2012 07:47:15 -0700
Date: Thu, 18 Oct 2012 10:47:12 -0400
From: Konrad Rzeszutek Wilk 
To: "H. Peter Anvin" 
Message-ID: <20121018144709.GB19782@localhost.localdomain>
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	<1350481786-4969-2-git-send-email-konrad.wilk@oracle.com>
	<507F473D.1060700@zytor.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <507F473D.1060700@zytor.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: linux-acpi@vger.kernel.org, x86@kernel.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH 1/4] x86/wakeup/sleep: Check whether the TSS
 GDT descriptor is empty before using it.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 17, 2012 at 05:03:09PM -0700, H. Peter Anvin wrote:
> On 10/17/2012 06:49 AM, Konrad Rzeszutek Wilk wrote:
> >We check the TSS descriptor before we try to dereference it.
> >Also fix up the value to use the #defines.
> >
> >Signed-off-by: Konrad Rzeszutek Wilk 
> >---
> >  arch/x86/power/cpu.c |    7 +++++--
> >  1 files changed, 5 insertions(+), 2 deletions(-)
> >
> >diff --git a/arch/x86/power/cpu.c b/arch/x86/power/cpu.c
> >index 218cdb1..c17370e 100644
> >--- a/arch/x86/power/cpu.c
> >+++ b/arch/x86/power/cpu.c
> >@@ -133,7 +133,9 @@ static void fix_processor_context(void)
> >  {
> >  	int cpu = smp_processor_id();
> >  	struct tss_struct *t = &per_cpu(init_tss, cpu);
> >-
> >+#ifdef CONFIG_X86_64
> >+	struct desc_struct *desc = get_cpu_gdt_table(cpu);
> >+#endif
> >  	set_tss_desc(cpu, t);	/*
> >  				 * This just modifies memory; should not be
> >  				 * necessary. But... This is necessary, because
> >@@ -142,7 +144,8 @@ static void fix_processor_context(void)
> >  				 */
> >
> >  #ifdef CONFIG_X86_64
> >-	get_cpu_gdt_table(cpu)[GDT_ENTRY_TSS].type = 9;
> >+	if (!desc_empty(&desc[GDT_ENTRY_TSS]))
> >+		desc[GDT_ENTRY_TSS].type = DESC_TSS;
> >
> >  	syscall_init();				/* This sets MSR_*STAR and related */
> >  #endif
> >
> 
> Why is this patch necessary?  Presumably there is something further
> down the line which depends on the TSS descriptor being empty, but
> if so, what?

I could not find it. This write has been in the code since the initial
git history. Is the pre-git bitkeeper tree somewhere available?
> 
> 	-hpa
> 
> -- 
> H. Peter Anvin, Intel Open Source Technology Center
> I work for Intel.  I don't speak on their behalf.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 14:51:33 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 14:51:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOrRP-0001Ke-7S; Thu, 18 Oct 2012 14:51:19 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOrRO-0001KV-J5
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 14:51:18 +0000
Received: from [193.109.254.147:46851] by server-8.bemta-14.messagelabs.com id
	B7/A8-16549-56710805; Thu, 18 Oct 2012 14:51:17 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1350571843!2712592!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgxOTgxMA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17674 invoked from network); 18 Oct 2012 14:50:44 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Oct 2012 14:50:44 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9IEoa8x023276
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 18 Oct 2012 14:50:37 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9IEoZ16021510
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 18 Oct 2012 14:50:36 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9IEoZcX021852; Thu, 18 Oct 2012 09:50:35 -0500
Received: from localhost.localdomain (/208.54.36.186)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 18 Oct 2012 07:50:34 -0700
Date: Thu, 18 Oct 2012 10:50:32 -0400
From: Konrad Rzeszutek Wilk 
To: "Duan, Ronghui" , justing@spectralogic.com
Message-ID: <20121018145030.GD19782@localhost.localdomain>
References: 
	<20120817172838.GA3515@phenom.dumpdata.com>
	
	<61DFA8800400A143A5A7C5E136A726DC5F867490@reactor.sldomain.com>
	<20120925152600.GA967@phenom.dumpdata.com>
	
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Justin Gibbs ,
	"xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] xen-vbd interface (segment size expansion) -
 FreeBSD host have it.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Oct 18, 2012 at 01:59:36AM +0000, Duan, Ronghui wrote:
> Hi, I am back from a long holiday. Sorry for the delay replay.
> > I was wondering how the protocol you developed works when it comes to
> > migration to a host that does not support the new features?
> >
> For my part, when VM migrate to a host which do not support larger segments, frontend will fall back to use original protocol with old-segments 11.
> 
> > Specifically how do deal with a guest which tries to replay in progress I/Os
> > that do not fit within the old-segment size (11)?
> The in-progress bio which have larger segments > 11 will receive an io error. I do not find a better way to handle it yet.

Justin, how did you guys handle it in FreeBSD? Or is it dependent on
the backends always supporting these large segments?

thanks!
> 
> > -----Original Message-----
> > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> > Sent: Tuesday, September 25, 2012 11:26 PM
> > To: Justin Gibbs; xen-devel@lists.xensource.com
> > Cc: Duan, Ronghui
> > Subject: Re: xen-vbd interface (segment size expansion) - FreeBSD host have
> > it.
> > 
> > On Mon, Aug 20, 2012 at 06:56:02PM +0000, Justin Gibbs wrote:
> > > Ronghui,
> > >
> > > It has been a while since I've actively worked on the blkif stuff.  ...
> > >
> > > That said, I'm happy to help in whatever ways I can to help get the blkif
> > interface sorted out.  I see several steps that should be taken:
> > >
> > > 1) Fix the Xen and QEMU builds so that QEMU keeps its own copy of the
> > Xen interface version.  This will allow interfaces to rev safely and in a
> > coordinated fashion (i.e. update interface in Xen, then add support for the
> > new interface in QEMU upstream).
> > >
> > > 2) Complete support in drivers for the existing blkif interface so that you
> > get maximum performance against systems using the existing multi-page
> > extensions.
> > >
> > > 3) Do something to allow for larger and more numerous requests.
> > >
> > > On point 3, my approach was to try to perturb the existing protocol as little
> > as possible in the hopes that other implementations could quickly be
> > enhanced to support the feature.  However, there is a lot of ugliness in the
> > existing blkif interface.  I can certainly understand the desires of some to just
> > replace blkif with a blkif2.
> > >
> > > What are your current plans in this area?  How can I be of assistance?
> > 
> > Hey Justin and Ronghui,
> > 
> > Note: I've expanded the email thread to include xen-devel.
> > 
> > I was wondering how the protocol you developed works when it comes to
> > migration to a host that does not support the new features?
> > 
> > Specifically how do deal with a guest which tries to replay in progress I/Os
> > that do not fit within the old-segment size (11)?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 14:51:33 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 14:51:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOrRP-0001Ke-7S; Thu, 18 Oct 2012 14:51:19 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOrRO-0001KV-J5
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 14:51:18 +0000
Received: from [193.109.254.147:46851] by server-8.bemta-14.messagelabs.com id
	B7/A8-16549-56710805; Thu, 18 Oct 2012 14:51:17 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1350571843!2712592!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgxOTgxMA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17674 invoked from network); 18 Oct 2012 14:50:44 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Oct 2012 14:50:44 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9IEoa8x023276
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 18 Oct 2012 14:50:37 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9IEoZ16021510
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 18 Oct 2012 14:50:36 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9IEoZcX021852; Thu, 18 Oct 2012 09:50:35 -0500
Received: from localhost.localdomain (/208.54.36.186)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 18 Oct 2012 07:50:34 -0700
Date: Thu, 18 Oct 2012 10:50:32 -0400
From: Konrad Rzeszutek Wilk 
To: "Duan, Ronghui" , justing@spectralogic.com
Message-ID: <20121018145030.GD19782@localhost.localdomain>
References: 
	<20120817172838.GA3515@phenom.dumpdata.com>
	
	<61DFA8800400A143A5A7C5E136A726DC5F867490@reactor.sldomain.com>
	<20120925152600.GA967@phenom.dumpdata.com>
	
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Justin Gibbs ,
	"xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] xen-vbd interface (segment size expansion) -
 FreeBSD host have it.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Oct 18, 2012 at 01:59:36AM +0000, Duan, Ronghui wrote:
> Hi, I am back from a long holiday. Sorry for the delay replay.
> > I was wondering how the protocol you developed works when it comes to
> > migration to a host that does not support the new features?
> >
> For my part, when VM migrate to a host which do not support larger segments, frontend will fall back to use original protocol with old-segments 11.
> 
> > Specifically how do deal with a guest which tries to replay in progress I/Os
> > that do not fit within the old-segment size (11)?
> The in-progress bio which have larger segments > 11 will receive an io error. I do not find a better way to handle it yet.

Justin, how did you guys handle it in FreeBSD? Or is it dependent on
the backends always supporting these large segments?

thanks!
> 
> > -----Original Message-----
> > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> > Sent: Tuesday, September 25, 2012 11:26 PM
> > To: Justin Gibbs; xen-devel@lists.xensource.com
> > Cc: Duan, Ronghui
> > Subject: Re: xen-vbd interface (segment size expansion) - FreeBSD host have
> > it.
> > 
> > On Mon, Aug 20, 2012 at 06:56:02PM +0000, Justin Gibbs wrote:
> > > Ronghui,
> > >
> > > It has been a while since I've actively worked on the blkif stuff.  ...
> > >
> > > That said, I'm happy to help in whatever ways I can to help get the blkif
> > interface sorted out.  I see several steps that should be taken:
> > >
> > > 1) Fix the Xen and QEMU builds so that QEMU keeps its own copy of the
> > Xen interface version.  This will allow interfaces to rev safely and in a
> > coordinated fashion (i.e. update interface in Xen, then add support for the
> > new interface in QEMU upstream).
> > >
> > > 2) Complete support in drivers for the existing blkif interface so that you
> > get maximum performance against systems using the existing multi-page
> > extensions.
> > >
> > > 3) Do something to allow for larger and more numerous requests.
> > >
> > > On point 3, my approach was to try to perturb the existing protocol as little
> > as possible in the hopes that other implementations could quickly be
> > enhanced to support the feature.  However, there is a lot of ugliness in the
> > existing blkif interface.  I can certainly understand the desires of some to just
> > replace blkif with a blkif2.
> > >
> > > What are your current plans in this area?  How can I be of assistance?
> > 
> > Hey Justin and Ronghui,
> > 
> > Note: I've expanded the email thread to include xen-devel.
> > 
> > I was wondering how the protocol you developed works when it comes to
> > migration to a host that does not support the new features?
> > 
> > Specifically how do deal with a guest which tries to replay in progress I/Os
> > that do not fit within the old-segment size (11)?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 15:01:59 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 15:01:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOrbQ-0001Z6-Ho; Thu, 18 Oct 2012 15:01:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOrbP-0001Z1-Bc
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 15:01:39 +0000
Received: from [85.158.137.99:22076] by server-15.bemta-3.messagelabs.com id
	60/4F-10261-2D910805; Thu, 18 Oct 2012 15:01:38 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1350572495!20902442!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20243 invoked from network); 18 Oct 2012 15:01:37 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-11.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Oct 2012 15:01:37 -0000
Received: from tazenda.hos.anvin.org (c-67-188-81-177.hsd1.ca.comcast.net
	[67.188.81.177]) (authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id q9IF1SIt008611
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256
	verify=FAIL); Thu, 18 Oct 2012 08:01:28 -0700
Message-ID: <508019C8.4030902@zytor.com>
Date: Thu, 18 Oct 2012 08:01:28 -0700
From: "H. Peter Anvin" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121009 Thunderbird/16.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk 
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	<1350481786-4969-2-git-send-email-konrad.wilk@oracle.com>
	<507F473D.1060700@zytor.com>
	<20121018144709.GB19782@localhost.localdomain>
In-Reply-To: <20121018144709.GB19782@localhost.localdomain>
Cc: linux-acpi@vger.kernel.org, x86@kernel.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH 1/4] x86/wakeup/sleep: Check whether the TSS
 GDT descriptor is empty before using it.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/18/2012 07:47 AM, Konrad Rzeszutek Wilk wrote:
>>
>> Why is this patch necessary?  Presumably there is something further
>> down the line which depends on the TSS descriptor being empty, but
>> if so, what?
>
> I could not find it. This write has been in the code since the initial
> git history. Is the pre-git bitkeeper tree somewhere available?

I didn't ask why the write was necessary, but why you need it to be 
conditional.

I know why the write is necessary: it is (presumably) there to clear the 
TSS busy bit.

However, as for older records:

-bk era history (2.5.0-2.6.12-rc2):
git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git

Ancient history (pre-2.4.0):
git://git.kernel.org/pub/scm/linux/kernel/git/davej/history.git

There doesn't seem to be any git trees known for the bridge between 
2.4.0 and 2.5.0.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 15:01:59 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 15:01:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOrbQ-0001Z6-Ho; Thu, 18 Oct 2012 15:01:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOrbP-0001Z1-Bc
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 15:01:39 +0000
Received: from [85.158.137.99:22076] by server-15.bemta-3.messagelabs.com id
	60/4F-10261-2D910805; Thu, 18 Oct 2012 15:01:38 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1350572495!20902442!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20243 invoked from network); 18 Oct 2012 15:01:37 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-11.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Oct 2012 15:01:37 -0000
Received: from tazenda.hos.anvin.org (c-67-188-81-177.hsd1.ca.comcast.net
	[67.188.81.177]) (authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id q9IF1SIt008611
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256
	verify=FAIL); Thu, 18 Oct 2012 08:01:28 -0700
Message-ID: <508019C8.4030902@zytor.com>
Date: Thu, 18 Oct 2012 08:01:28 -0700
From: "H. Peter Anvin" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121009 Thunderbird/16.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk 
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	<1350481786-4969-2-git-send-email-konrad.wilk@oracle.com>
	<507F473D.1060700@zytor.com>
	<20121018144709.GB19782@localhost.localdomain>
In-Reply-To: <20121018144709.GB19782@localhost.localdomain>
Cc: linux-acpi@vger.kernel.org, x86@kernel.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH 1/4] x86/wakeup/sleep: Check whether the TSS
 GDT descriptor is empty before using it.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/18/2012 07:47 AM, Konrad Rzeszutek Wilk wrote:
>>
>> Why is this patch necessary?  Presumably there is something further
>> down the line which depends on the TSS descriptor being empty, but
>> if so, what?
>
> I could not find it. This write has been in the code since the initial
> git history. Is the pre-git bitkeeper tree somewhere available?

I didn't ask why the write was necessary, but why you need it to be 
conditional.

I know why the write is necessary: it is (presumably) there to clear the 
TSS busy bit.

However, as for older records:

-bk era history (2.5.0-2.6.12-rc2):
git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git

Ancient history (pre-2.4.0):
git://git.kernel.org/pub/scm/linux/kernel/git/davej/history.git

There doesn't seem to be any git trees known for the bridge between 
2.4.0 and 2.5.0.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 15:03:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 15:03:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOrca-0001dA-04; Thu, 18 Oct 2012 15:02:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOrcY-0001cx-Ki
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 15:02:50 +0000
Received: from [85.158.139.83:33368] by server-15.bemta-5.messagelabs.com id
	D5/2D-28599-91A10805; Thu, 18 Oct 2012 15:02:49 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1350572567!35298042!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31776 invoked from network); 18 Oct 2012 15:02:49 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Oct 2012 15:02:49 -0000
Received: from tazenda.hos.anvin.org (c-67-188-81-177.hsd1.ca.comcast.net
	[67.188.81.177]) (authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id q9IF2iuZ008733
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256
	verify=FAIL); Thu, 18 Oct 2012 08:02:44 -0700
Message-ID: <50801A14.5010003@zytor.com>
Date: Thu, 18 Oct 2012 08:02:44 -0700
From: "H. Peter Anvin" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121009 Thunderbird/16.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk 
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	<1350481786-4969-3-git-send-email-konrad.wilk@oracle.com>
	<507F4475.80705@zytor.com>
	<20121018144538.GA19782@localhost.localdomain>
In-Reply-To: <20121018144538.GA19782@localhost.localdomain>
Cc: linux-acpi@vger.kernel.org, x86@kernel.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH 2/4] xen/lowlevel: Implement pvop call for
	load_idt (sidt).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/18/2012 07:45 AM, Konrad Rzeszutek Wilk wrote:
>>
>> OK... this seems like another excellent set of pvops calls that
>> should be nukable to Kingdom Come.  There is no reason, ever, to
>> read the IDT and GDT from the kernel... the kernel already knows
>> what they should be!
>
> Even during suspend and resume cycle? There are the sequence of
> sidt/lidt calls being done there. And we do need to filter at
> least the sidt call - and in the case of ACPI suspend path,
> the lidt.

Yes, I am pretty sure we can make static guarantees on the IDT and GDTs.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 15:03:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 15:03:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOrca-0001dA-04; Thu, 18 Oct 2012 15:02:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOrcY-0001cx-Ki
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 15:02:50 +0000
Received: from [85.158.139.83:33368] by server-15.bemta-5.messagelabs.com id
	D5/2D-28599-91A10805; Thu, 18 Oct 2012 15:02:49 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1350572567!35298042!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31776 invoked from network); 18 Oct 2012 15:02:49 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Oct 2012 15:02:49 -0000
Received: from tazenda.hos.anvin.org (c-67-188-81-177.hsd1.ca.comcast.net
	[67.188.81.177]) (authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id q9IF2iuZ008733
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256
	verify=FAIL); Thu, 18 Oct 2012 08:02:44 -0700
Message-ID: <50801A14.5010003@zytor.com>
Date: Thu, 18 Oct 2012 08:02:44 -0700
From: "H. Peter Anvin" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121009 Thunderbird/16.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk 
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	<1350481786-4969-3-git-send-email-konrad.wilk@oracle.com>
	<507F4475.80705@zytor.com>
	<20121018144538.GA19782@localhost.localdomain>
In-Reply-To: <20121018144538.GA19782@localhost.localdomain>
Cc: linux-acpi@vger.kernel.org, x86@kernel.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH 2/4] xen/lowlevel: Implement pvop call for
	load_idt (sidt).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/18/2012 07:45 AM, Konrad Rzeszutek Wilk wrote:
>>
>> OK... this seems like another excellent set of pvops calls that
>> should be nukable to Kingdom Come.  There is no reason, ever, to
>> read the IDT and GDT from the kernel... the kernel already knows
>> what they should be!
>
> Even during suspend and resume cycle? There are the sequence of
> sidt/lidt calls being done there. And we do need to filter at
> least the sidt call - and in the case of ACPI suspend path,
> the lidt.

Yes, I am pretty sure we can make static guarantees on the IDT and GDTs.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 15:17:54 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 15:17:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOrqt-0001zO-Nl; Thu, 18 Oct 2012 15:17:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOrqs-0001zJ-Bf
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 15:17:38 +0000
Received: from [85.158.143.35:52155] by server-1.bemta-4.messagelabs.com id
	DC/CA-19134-19D10805; Thu, 18 Oct 2012 15:17:37 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1350573455!5852693!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27182 invoked from network); 18 Oct 2012 15:17:36 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 15:17:36 -0000
Received: by mail-vb0-f45.google.com with SMTP id p1so10918888vbi.32
	for ; Thu, 18 Oct 2012 08:17:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=UryjT/5uc7ccrNXCmYD261I8ePXR5ln5Gbu9h0NqDcU=;
	b=jmh9IQbOsVRlWjJn37yXSgDphh4gE5rtx5/oFeIuNx6hN1mE/hsplwOYImJhlUyeHD
	Wf+7Xts6tUewEt0DJJr5NPqmjsWYEUHN/xSdXjFkBu+Qy/gZlL3Q6CC/RNBQTc6iWhii
	SuII/0IjkMS/WeoPkbKuFl/7FsbFGzPM/o6R9tsUEtAPMrrqhe81AHJboRULR6dhbxqk
	7ZGNZyD0x2fDAfevF98WW7KJMUqozdwRlGzjS826wgZwgFX93gFjPFX7CpWasPMNle+g
	yuHC2EtnzYr71Vxh0wr6poOA84L535hHZpnuLOo6vL+R5qM6FSpMuISt+QfUTOINgno/
	YSZQ==
MIME-Version: 1.0
Received: by 10.52.17.19 with SMTP id k19mr12654610vdd.0.1350573455102; Thu,
	18 Oct 2012 08:17:35 -0700 (PDT)
Received: by 10.58.231.138 with HTTP; Thu, 18 Oct 2012 08:17:35 -0700 (PDT)
In-Reply-To: 
References: 
	
Date: Thu, 18 Oct 2012 16:17:35 +0100
X-Google-Sender-Auth: WEelMoqedFSVnDAlD5pf8iQX35c
Message-ID: 
From: George Dunlap 
To: Dario Faggioli 
Cc: Andre Przywara ,
	Ian Jackson ,
	Ian Campbell , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1 of 3] libxl: take node distances into
 account during NUMA placement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 16, 2012 at 6:26 PM, Dario Faggioli
 wrote:
> In fact, among placement candidates with the same number of nodes, the
> closer the various nodes are to each others, the better the performances
> for a domain placed there.

Looks good overall -- my only worry is the N^2 nature of the
algorithm.  We're already doing some big combinatorial thing to
generate the candidates, right?  And now we're doing N^2 for each
candidate? Suppose we get an ARM system with 4096 cores and 128 NUMA
nodes?  If Xen 4.4 doesn't come out until March 2014, there will still
be distros using 4.3 through mid-2015.

I seem to remember having a discussion about this issue already, but I
can't remember what the outcome was...

 -George


>
> Signed-off-by: Dario Faggioli 
>
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -105,6 +105,9 @@ out:
>   *  - the number of vcpus runnable on the candidates is considered, and
>   *    candidates with fewer of them are preferred. If two candidate have
>   *    the same number of runnable vcpus,
> + *  - the sum of the node distances in the candidates is considered, and
> + *    candidates with smaller total distance are preferred. If total
> + *    distance is the same for the two candidatess,
>   *  - the amount of free memory in the candidates is considered, and the
>   *    candidate with greater amount of it is preferred.
>   *
> @@ -114,6 +117,10 @@ out:
>   * overloading large (from a memory POV) nodes. That's right the effect
>   * that counting the vcpus able to run on the nodes tries to prevent.
>   *
> + * The relative distance within the nodes in the candidates is considered
> + * as the closer the nodes, the better for the domain ending up on the
> + * candidate.
> + *
>   * Note that this completely ignore the number of nodes each candidate span,
>   * as the fact that fewer nodes is better is already accounted for in the
>   * algorithm.
> @@ -124,6 +131,9 @@ static int numa_cmpf(const libxl__numa_c
>      if (c1->nr_vcpus != c2->nr_vcpus)
>          return c1->nr_vcpus - c2->nr_vcpus;
>
> +    if (c1->dists_sum != c2->dists_sum)
> +        return c1->dists_sum - c2->dists_sum;
> +
>      return c2->free_memkb - c1->free_memkb;
>  }
>
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -2732,6 +2732,7 @@ static inline void libxl__ctx_unlock(lib
>  typedef struct {
>      int nr_cpus, nr_nodes;
>      int nr_vcpus;
> +    int dists_sum;
>      uint32_t free_memkb;
>      libxl_bitmap nodemap;
>  } libxl__numa_candidate;
> diff --git a/tools/libxl/libxl_numa.c b/tools/libxl/libxl_numa.c
> --- a/tools/libxl/libxl_numa.c
> +++ b/tools/libxl/libxl_numa.c
> @@ -218,6 +218,40 @@ static int nodemap_to_nr_vcpus(libxl__gc
>      return nr_vcpus;
>  }
>
> +/* Sum the relative distances of nodes in the nodemap to help finding
> + * out which candidate is the "tightest" one. */
> +static int nodemap_to_dists_sum(libxl_numainfo *ninfo, libxl_bitmap *nodemap)
> +{
> +    int tot_dist = 0;
> +    int i, j, a = 0, b;
> +
> +    for (i = 0; i < libxl_bitmap_count_set(nodemap); i++) {
> +        while (!libxl_bitmap_test(nodemap, a))
> +            a++;
> +
> +        /* As it is usually non-zero, we do take the latency of
> +         * of a node to itself into account. */
> +        b = a;
> +        for (j = 0; j < libxl_bitmap_count_set(nodemap) - i; j++) {
> +            while (!libxl_bitmap_test(nodemap, b))
> +                b++;
> +
> +            /*
> +             * In most architectures, going from node A to node B costs
> +             * exactly as much as going from B to A does. However, let's
> +             * not rely on this and consider both contributions, just to
> +             * be ready for everything future might reserve for us.
> +             */
> +            tot_dist += ninfo[a].dists[b];
> +            tot_dist += ninfo[b].dists[a];
> +            b++;
> +        }
> +        a++;
> +    }
> +
> +    return tot_dist;
> +}
> +
>  /*
>   * This function tries to figure out if the host has a consistent number
>   * of cpus along all its NUMA nodes. In fact, if that is the case, we can
> @@ -415,6 +449,7 @@ int libxl__get_numa_candidate(libxl__gc
>               */
>              libxl__numa_candidate_put_nodemap(gc, &new_cndt, &nodemap);
>              new_cndt.nr_vcpus = nodemap_to_nr_vcpus(gc, tinfo, &nodemap);
> +            new_cndt.dists_sum = nodemap_to_dists_sum(ninfo, &nodemap);
>              new_cndt.free_memkb = nodes_free_memkb;
>              new_cndt.nr_nodes = libxl_bitmap_count_set(&nodemap);
>              new_cndt.nr_cpus = nodes_cpus;
> @@ -430,12 +465,14 @@ int libxl__get_numa_candidate(libxl__gc
>
>                  LOG(DEBUG, "New best NUMA placement candidate found: "
>                             "nr_nodes=%d, nr_cpus=%d, nr_vcpus=%d, "
> -                           "free_memkb=%"PRIu32"", new_cndt.nr_nodes,
> -                           new_cndt.nr_cpus, new_cndt.nr_vcpus,
> +                           "dists_sum=%d, free_memkb=%"PRIu32"",
> +                           new_cndt.nr_nodes, new_cndt.nr_cpus,
> +                           new_cndt.nr_vcpus, new_cndt.dists_sum,
>                             new_cndt.free_memkb / 1024);
>
>                  libxl__numa_candidate_put_nodemap(gc, cndt_out, &nodemap);
>                  cndt_out->nr_vcpus = new_cndt.nr_vcpus;
> +                cndt_out->dists_sum = new_cndt.dists_sum;
>                  cndt_out->free_memkb = new_cndt.free_memkb;
>                  cndt_out->nr_nodes = new_cndt.nr_nodes;
>                  cndt_out->nr_cpus = new_cndt.nr_cpus;
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 15:17:54 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 15:17:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOrqt-0001zO-Nl; Thu, 18 Oct 2012 15:17:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOrqs-0001zJ-Bf
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 15:17:38 +0000
Received: from [85.158.143.35:52155] by server-1.bemta-4.messagelabs.com id
	DC/CA-19134-19D10805; Thu, 18 Oct 2012 15:17:37 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1350573455!5852693!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27182 invoked from network); 18 Oct 2012 15:17:36 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 15:17:36 -0000
Received: by mail-vb0-f45.google.com with SMTP id p1so10918888vbi.32
	for ; Thu, 18 Oct 2012 08:17:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=UryjT/5uc7ccrNXCmYD261I8ePXR5ln5Gbu9h0NqDcU=;
	b=jmh9IQbOsVRlWjJn37yXSgDphh4gE5rtx5/oFeIuNx6hN1mE/hsplwOYImJhlUyeHD
	Wf+7Xts6tUewEt0DJJr5NPqmjsWYEUHN/xSdXjFkBu+Qy/gZlL3Q6CC/RNBQTc6iWhii
	SuII/0IjkMS/WeoPkbKuFl/7FsbFGzPM/o6R9tsUEtAPMrrqhe81AHJboRULR6dhbxqk
	7ZGNZyD0x2fDAfevF98WW7KJMUqozdwRlGzjS826wgZwgFX93gFjPFX7CpWasPMNle+g
	yuHC2EtnzYr71Vxh0wr6poOA84L535hHZpnuLOo6vL+R5qM6FSpMuISt+QfUTOINgno/
	YSZQ==
MIME-Version: 1.0
Received: by 10.52.17.19 with SMTP id k19mr12654610vdd.0.1350573455102; Thu,
	18 Oct 2012 08:17:35 -0700 (PDT)
Received: by 10.58.231.138 with HTTP; Thu, 18 Oct 2012 08:17:35 -0700 (PDT)
In-Reply-To: 
References: 
	
Date: Thu, 18 Oct 2012 16:17:35 +0100
X-Google-Sender-Auth: WEelMoqedFSVnDAlD5pf8iQX35c
Message-ID: 
From: George Dunlap 
To: Dario Faggioli 
Cc: Andre Przywara ,
	Ian Jackson ,
	Ian Campbell , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1 of 3] libxl: take node distances into
 account during NUMA placement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 16, 2012 at 6:26 PM, Dario Faggioli
 wrote:
> In fact, among placement candidates with the same number of nodes, the
> closer the various nodes are to each others, the better the performances
> for a domain placed there.

Looks good overall -- my only worry is the N^2 nature of the
algorithm.  We're already doing some big combinatorial thing to
generate the candidates, right?  And now we're doing N^2 for each
candidate? Suppose we get an ARM system with 4096 cores and 128 NUMA
nodes?  If Xen 4.4 doesn't come out until March 2014, there will still
be distros using 4.3 through mid-2015.

I seem to remember having a discussion about this issue already, but I
can't remember what the outcome was...

 -George


>
> Signed-off-by: Dario Faggioli 
>
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -105,6 +105,9 @@ out:
>   *  - the number of vcpus runnable on the candidates is considered, and
>   *    candidates with fewer of them are preferred. If two candidate have
>   *    the same number of runnable vcpus,
> + *  - the sum of the node distances in the candidates is considered, and
> + *    candidates with smaller total distance are preferred. If total
> + *    distance is the same for the two candidatess,
>   *  - the amount of free memory in the candidates is considered, and the
>   *    candidate with greater amount of it is preferred.
>   *
> @@ -114,6 +117,10 @@ out:
>   * overloading large (from a memory POV) nodes. That's right the effect
>   * that counting the vcpus able to run on the nodes tries to prevent.
>   *
> + * The relative distance within the nodes in the candidates is considered
> + * as the closer the nodes, the better for the domain ending up on the
> + * candidate.
> + *
>   * Note that this completely ignore the number of nodes each candidate span,
>   * as the fact that fewer nodes is better is already accounted for in the
>   * algorithm.
> @@ -124,6 +131,9 @@ static int numa_cmpf(const libxl__numa_c
>      if (c1->nr_vcpus != c2->nr_vcpus)
>          return c1->nr_vcpus - c2->nr_vcpus;
>
> +    if (c1->dists_sum != c2->dists_sum)
> +        return c1->dists_sum - c2->dists_sum;
> +
>      return c2->free_memkb - c1->free_memkb;
>  }
>
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -2732,6 +2732,7 @@ static inline void libxl__ctx_unlock(lib
>  typedef struct {
>      int nr_cpus, nr_nodes;
>      int nr_vcpus;
> +    int dists_sum;
>      uint32_t free_memkb;
>      libxl_bitmap nodemap;
>  } libxl__numa_candidate;
> diff --git a/tools/libxl/libxl_numa.c b/tools/libxl/libxl_numa.c
> --- a/tools/libxl/libxl_numa.c
> +++ b/tools/libxl/libxl_numa.c
> @@ -218,6 +218,40 @@ static int nodemap_to_nr_vcpus(libxl__gc
>      return nr_vcpus;
>  }
>
> +/* Sum the relative distances of nodes in the nodemap to help finding
> + * out which candidate is the "tightest" one. */
> +static int nodemap_to_dists_sum(libxl_numainfo *ninfo, libxl_bitmap *nodemap)
> +{
> +    int tot_dist = 0;
> +    int i, j, a = 0, b;
> +
> +    for (i = 0; i < libxl_bitmap_count_set(nodemap); i++) {
> +        while (!libxl_bitmap_test(nodemap, a))
> +            a++;
> +
> +        /* As it is usually non-zero, we do take the latency of
> +         * of a node to itself into account. */
> +        b = a;
> +        for (j = 0; j < libxl_bitmap_count_set(nodemap) - i; j++) {
> +            while (!libxl_bitmap_test(nodemap, b))
> +                b++;
> +
> +            /*
> +             * In most architectures, going from node A to node B costs
> +             * exactly as much as going from B to A does. However, let's
> +             * not rely on this and consider both contributions, just to
> +             * be ready for everything future might reserve for us.
> +             */
> +            tot_dist += ninfo[a].dists[b];
> +            tot_dist += ninfo[b].dists[a];
> +            b++;
> +        }
> +        a++;
> +    }
> +
> +    return tot_dist;
> +}
> +
>  /*
>   * This function tries to figure out if the host has a consistent number
>   * of cpus along all its NUMA nodes. In fact, if that is the case, we can
> @@ -415,6 +449,7 @@ int libxl__get_numa_candidate(libxl__gc
>               */
>              libxl__numa_candidate_put_nodemap(gc, &new_cndt, &nodemap);
>              new_cndt.nr_vcpus = nodemap_to_nr_vcpus(gc, tinfo, &nodemap);
> +            new_cndt.dists_sum = nodemap_to_dists_sum(ninfo, &nodemap);
>              new_cndt.free_memkb = nodes_free_memkb;
>              new_cndt.nr_nodes = libxl_bitmap_count_set(&nodemap);
>              new_cndt.nr_cpus = nodes_cpus;
> @@ -430,12 +465,14 @@ int libxl__get_numa_candidate(libxl__gc
>
>                  LOG(DEBUG, "New best NUMA placement candidate found: "
>                             "nr_nodes=%d, nr_cpus=%d, nr_vcpus=%d, "
> -                           "free_memkb=%"PRIu32"", new_cndt.nr_nodes,
> -                           new_cndt.nr_cpus, new_cndt.nr_vcpus,
> +                           "dists_sum=%d, free_memkb=%"PRIu32"",
> +                           new_cndt.nr_nodes, new_cndt.nr_cpus,
> +                           new_cndt.nr_vcpus, new_cndt.dists_sum,
>                             new_cndt.free_memkb / 1024);
>
>                  libxl__numa_candidate_put_nodemap(gc, cndt_out, &nodemap);
>                  cndt_out->nr_vcpus = new_cndt.nr_vcpus;
> +                cndt_out->dists_sum = new_cndt.dists_sum;
>                  cndt_out->free_memkb = new_cndt.free_memkb;
>                  cndt_out->nr_nodes = new_cndt.nr_nodes;
>                  cndt_out->nr_cpus = new_cndt.nr_cpus;
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 15:21:56 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 15:21:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOrum-000275-Kt; Thu, 18 Oct 2012 15:21:40 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOrul-00026y-Kx
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 15:21:39 +0000
Received: from [193.109.254.147:5384] by server-14.bemta-14.messagelabs.com id
	C0/33-20054-38E10805; Thu, 18 Oct 2012 15:21:39 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1350573696!11851150!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17826 invoked from network); 18 Oct 2012 15:21:38 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 15:21:38 -0000
Received: by mail-vc0-f173.google.com with SMTP id fl15so11819377vcb.32
	for ; Thu, 18 Oct 2012 08:21:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=pKSP+RG+KneE40cef/l/Ssrj3bV6Ffz95qKF0AqwBMs=;
	b=h3FPOPG6yduIzNlRFXC1JzfwNCFHDsDe9xJJcTMD3vExSmC5NHX/bbE3Eg7VTBXgwq
	jYF3CddCgjaWFGevPzJhf1JWMr+VIFOyK+NN5nJlDc9R85Uf4i6IbOSkvxBSuBcOnOlu
	njvaIqvDg61JLwJUbe25Ojr0WNy9MMLn1jwhv8gTYYUJ+XOiv3Wgh6H648fe0vTTN9WN
	gC97wBG1orlQhfsmScLVgrK0igzDGknWU0c+igwoAhLf7elhPEFqYGqapHqGiJipybtp
	vXc/knBPlYnMWnXrFFqC9Ws9di+AV/sRT+zanEQtCkhXVZvPCkbRqhuFOIWCfmlfYyKR
	zX2A==
MIME-Version: 1.0
Received: by 10.52.139.136 with SMTP id qy8mr12675282vdb.39.1350573696570;
	Thu, 18 Oct 2012 08:21:36 -0700 (PDT)
Received: by 10.58.231.138 with HTTP; Thu, 18 Oct 2012 08:21:36 -0700 (PDT)
In-Reply-To: <55f27c485238772388bb.1350408387@Solace>
References: 
	<55f27c485238772388bb.1350408387@Solace>
Date: Thu, 18 Oct 2012 16:21:36 +0100
X-Google-Sender-Auth: kdO_97VwxZft6AEDyowJDtio1JQ
Message-ID: 
From: George Dunlap 
To: Dario Faggioli 
Cc: Andre Przywara ,
	Ian Jackson ,
	Ian Campbell , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2 of 3] libxl,
 xl: user can ask for min and max nodes to use during placement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 16, 2012 at 6:26 PM, Dario Faggioli
 wrote:
> And the placement algorithm will stick to that, or fail. This happens
> adding support for "minnodes=" and "maxnodes=" in the domain config
> file parser.
>
> Signed-off-by: Dario Faggioli 

Acked-by: George Dunlap 

>
> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
> @@ -133,6 +133,18 @@ the same time, achieving efficient utili
>
>  =back
>
> +=item B
> +
> +Tells libxl to place the new domain on at least `N` nodes. This is only
> +effective if automatic NUMA placement occurs (i.e., if no `cpus=` option
> +is specified).
> +
> +=item B
> +
> +Tells libxl to place the new domain on at most `M` nodes. This is only
> +effective if automatic NUMA placement occurs (i.e., if no `cpus=` option
> +is specified).
> +
>  =head3 CPU Scheduling
>
>  =over 4
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -219,6 +219,11 @@ int libxl__domain_build_info_setdefault(
>
>      libxl_defbool_setdefault(&b_info->numa_placement, true);
>
> +    if (!b_info->min_nodes)
> +        b_info->min_nodes = 0;
> +    if (!b_info->max_nodes)
> +        b_info->max_nodes = 0;
> +
>      if (b_info->max_memkb == LIBXL_MEMKB_DEFAULT)
>          b_info->max_memkb = 32 * 1024;
>      if (b_info->target_memkb == LIBXL_MEMKB_DEFAULT)
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -174,7 +174,8 @@ static int numa_place_domain(libxl__gc *
>      /* Find the best candidate with enough free memory and at least
>       * as much pcpus as the domain has vcpus.  */
>      rc = libxl__get_numa_candidate(gc, memkb, info->max_vcpus,
> -                                   0, 0, &cpupool_info.cpumap,
> +                                   info->min_nodes, info->max_nodes,
> +                                   &cpupool_info.cpumap,
>                                     numa_cmpf, &candidate, &found);
>      if (rc)
>          goto out;
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -262,6 +262,8 @@ libxl_domain_build_info = Struct("domain
>      ("avail_vcpus",     libxl_bitmap),
>      ("cpumap",          libxl_bitmap),
>      ("numa_placement",  libxl_defbool),
> +    ("min_nodes",       integer),
> +    ("max_nodes",       integer),
>      ("tsc_mode",        libxl_tsc_mode),
>      ("max_memkb",       MemKB),
>      ("target_memkb",    MemKB),
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -731,6 +731,11 @@ static void parse_config_data(const char
>          libxl_defbool_set(&b_info->numa_placement, false);
>      }
>
> +    if (!xlu_cfg_get_long (config, "minnodes", &l, 0))
> +        b_info->min_nodes = l;
> +    if (!xlu_cfg_get_long (config, "maxnodes", &l, 0))
> +        b_info->max_nodes = l;
> +
>      if (!xlu_cfg_get_long (config, "memory", &l, 0)) {
>          b_info->max_memkb = l * 1024;
>          b_info->target_memkb = b_info->max_memkb;
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 15:21:56 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 15:21:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOrum-000275-Kt; Thu, 18 Oct 2012 15:21:40 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOrul-00026y-Kx
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 15:21:39 +0000
Received: from [193.109.254.147:5384] by server-14.bemta-14.messagelabs.com id
	C0/33-20054-38E10805; Thu, 18 Oct 2012 15:21:39 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1350573696!11851150!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17826 invoked from network); 18 Oct 2012 15:21:38 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 15:21:38 -0000
Received: by mail-vc0-f173.google.com with SMTP id fl15so11819377vcb.32
	for ; Thu, 18 Oct 2012 08:21:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=pKSP+RG+KneE40cef/l/Ssrj3bV6Ffz95qKF0AqwBMs=;
	b=h3FPOPG6yduIzNlRFXC1JzfwNCFHDsDe9xJJcTMD3vExSmC5NHX/bbE3Eg7VTBXgwq
	jYF3CddCgjaWFGevPzJhf1JWMr+VIFOyK+NN5nJlDc9R85Uf4i6IbOSkvxBSuBcOnOlu
	njvaIqvDg61JLwJUbe25Ojr0WNy9MMLn1jwhv8gTYYUJ+XOiv3Wgh6H648fe0vTTN9WN
	gC97wBG1orlQhfsmScLVgrK0igzDGknWU0c+igwoAhLf7elhPEFqYGqapHqGiJipybtp
	vXc/knBPlYnMWnXrFFqC9Ws9di+AV/sRT+zanEQtCkhXVZvPCkbRqhuFOIWCfmlfYyKR
	zX2A==
MIME-Version: 1.0
Received: by 10.52.139.136 with SMTP id qy8mr12675282vdb.39.1350573696570;
	Thu, 18 Oct 2012 08:21:36 -0700 (PDT)
Received: by 10.58.231.138 with HTTP; Thu, 18 Oct 2012 08:21:36 -0700 (PDT)
In-Reply-To: <55f27c485238772388bb.1350408387@Solace>
References: 
	<55f27c485238772388bb.1350408387@Solace>
Date: Thu, 18 Oct 2012 16:21:36 +0100
X-Google-Sender-Auth: kdO_97VwxZft6AEDyowJDtio1JQ
Message-ID: 
From: George Dunlap 
To: Dario Faggioli 
Cc: Andre Przywara ,
	Ian Jackson ,
	Ian Campbell , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2 of 3] libxl,
 xl: user can ask for min and max nodes to use during placement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 16, 2012 at 6:26 PM, Dario Faggioli
 wrote:
> And the placement algorithm will stick to that, or fail. This happens
> adding support for "minnodes=" and "maxnodes=" in the domain config
> file parser.
>
> Signed-off-by: Dario Faggioli 

Acked-by: George Dunlap 

>
> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
> @@ -133,6 +133,18 @@ the same time, achieving efficient utili
>
>  =back
>
> +=item B
> +
> +Tells libxl to place the new domain on at least `N` nodes. This is only
> +effective if automatic NUMA placement occurs (i.e., if no `cpus=` option
> +is specified).
> +
> +=item B
> +
> +Tells libxl to place the new domain on at most `M` nodes. This is only
> +effective if automatic NUMA placement occurs (i.e., if no `cpus=` option
> +is specified).
> +
>  =head3 CPU Scheduling
>
>  =over 4
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -219,6 +219,11 @@ int libxl__domain_build_info_setdefault(
>
>      libxl_defbool_setdefault(&b_info->numa_placement, true);
>
> +    if (!b_info->min_nodes)
> +        b_info->min_nodes = 0;
> +    if (!b_info->max_nodes)
> +        b_info->max_nodes = 0;
> +
>      if (b_info->max_memkb == LIBXL_MEMKB_DEFAULT)
>          b_info->max_memkb = 32 * 1024;
>      if (b_info->target_memkb == LIBXL_MEMKB_DEFAULT)
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -174,7 +174,8 @@ static int numa_place_domain(libxl__gc *
>      /* Find the best candidate with enough free memory and at least
>       * as much pcpus as the domain has vcpus.  */
>      rc = libxl__get_numa_candidate(gc, memkb, info->max_vcpus,
> -                                   0, 0, &cpupool_info.cpumap,
> +                                   info->min_nodes, info->max_nodes,
> +                                   &cpupool_info.cpumap,
>                                     numa_cmpf, &candidate, &found);
>      if (rc)
>          goto out;
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -262,6 +262,8 @@ libxl_domain_build_info = Struct("domain
>      ("avail_vcpus",     libxl_bitmap),
>      ("cpumap",          libxl_bitmap),
>      ("numa_placement",  libxl_defbool),
> +    ("min_nodes",       integer),
> +    ("max_nodes",       integer),
>      ("tsc_mode",        libxl_tsc_mode),
>      ("max_memkb",       MemKB),
>      ("target_memkb",    MemKB),
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -731,6 +731,11 @@ static void parse_config_data(const char
>          libxl_defbool_set(&b_info->numa_placement, false);
>      }
>
> +    if (!xlu_cfg_get_long (config, "minnodes", &l, 0))
> +        b_info->min_nodes = l;
> +    if (!xlu_cfg_get_long (config, "maxnodes", &l, 0))
> +        b_info->max_nodes = l;
> +
>      if (!xlu_cfg_get_long (config, "memory", &l, 0)) {
>          b_info->max_memkb = l * 1024;
>          b_info->target_memkb = b_info->max_memkb;
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 15:23:23 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 15:23:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOrw9-0002Ce-4l; Thu, 18 Oct 2012 15:23:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOrw7-0002CW-M5
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 15:23:03 +0000
Received: from [85.158.137.99:12952] by server-15.bemta-3.messagelabs.com id
	A8/E8-10261-6DE10805; Thu, 18 Oct 2012 15:23:02 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1350573779!20906038!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODEyNzI4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6053 invoked from network); 18 Oct 2012 15:23:01 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Oct 2012 15:23:01 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9IFMsEo000601
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 18 Oct 2012 15:22:54 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9IFMrXj005602
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 18 Oct 2012 15:22:53 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9IFMqFq017717; Thu, 18 Oct 2012 10:22:52 -0500
MIME-Version: 1.0
Message-ID: <84b3cbf9-7c84-4d7e-a2d7-46b0d1cc5975@default>
Date: Thu, 18 Oct 2012 08:22:50 -0700 (PDT)
From: Dan Magenheimer 
To: "H. Peter Anvin" , Konrad Wilk 
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	<507ED6C0.4020503@zytor.com>
	<20121017161036.GA10691@phenom.dumpdata.com>
	<507EE1C3.7070300@zytor.com>
	<20121017165452.GA22740@phenom.dumpdata.com>
	<507EEC53.1010309@zytor.com>
In-Reply-To: <507EEC53.1010309@zytor.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: linux-acpi@vger.kernel.org, x86@kernel.org, xen-devel@lists.xensource.com,
	lenb@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] Is: axe read_tscp pvops call. Was: Re: [RFC] ACPI
 S3 and Xen (suprisingly small\!).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: H. Peter Anvin [mailto:hpa@zytor.com]
> Sent: Wednesday, October 17, 2012 11:35 AM
> To: Konrad Rzeszutek Wilk
> Cc: linux-acpi@vger.kernel.org; x86@kernel.org; xen-devel@lists.xensource.com; linux-
> kernel@vger.kernel.org; lenb@kernel.org
> Subject: Re: [Xen-devel] Is: axe read_tscp pvops call. Was: Re: [RFC] ACPI S3 and Xen (suprisingly
> small\!).
> 
> On 10/17/2012 09:54 AM, Konrad Rzeszutek Wilk wrote:
> >>
> >> Could you do an audit for other pvops calls that have no users?  If
> >> the *only* user is lguest, we should talk about it, too...
> >
> > I can do that - but I don't want to be hasty here. There is a bit of
> > danger here - for example the read_pmc (or read_tsc) is not in use right
> > now. But it might be when one starts looking at making perf be able to
> > analyze the hypervisor (hand-waving the implementation details). So while
> > removing read_pmc now sounds good, it might be needed in the future.
> >
> 
> We do not keep a pvop around just because it "might be needed in the
> future".  That's just crazy.
> 
> 	-hpa

It's a bit more complicated than that.  The problem is that if
any patch is ever submitted to the kernel that uses the rdtscp
instruction *in kernel space* in some clever way, the resultant
kernel may not behave as expected (depending on how the instruction
is used) on a 32-bit[1] PV kernel running on Xen, up to and including
the possibility of data corruption.

I don't know how one would implement it, but it's like a
BUILD_BUG_ON is needed if any kernel developer uses rdtscp
(one that never gets invoked by vdso code), that prints:

"WARNING: Please do not use this instruction in the kernel
without notifying the Xen maintainer as there is a possibility
it may behave unpredictably in some Xen environments.
See Documentation/.../xen_pv_limitations for detail."

The other virtualization-unsafe instructions may have similar
problems.

Just FYI...

Dan

[1] I _think_ this is not a problem on 64-bit kernels but
am not certain.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 15:23:23 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 15:23:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOrw9-0002Ce-4l; Thu, 18 Oct 2012 15:23:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOrw7-0002CW-M5
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 15:23:03 +0000
Received: from [85.158.137.99:12952] by server-15.bemta-3.messagelabs.com id
	A8/E8-10261-6DE10805; Thu, 18 Oct 2012 15:23:02 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1350573779!20906038!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODEyNzI4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6053 invoked from network); 18 Oct 2012 15:23:01 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Oct 2012 15:23:01 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9IFMsEo000601
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 18 Oct 2012 15:22:54 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9IFMrXj005602
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 18 Oct 2012 15:22:53 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9IFMqFq017717; Thu, 18 Oct 2012 10:22:52 -0500
MIME-Version: 1.0
Message-ID: <84b3cbf9-7c84-4d7e-a2d7-46b0d1cc5975@default>
Date: Thu, 18 Oct 2012 08:22:50 -0700 (PDT)
From: Dan Magenheimer 
To: "H. Peter Anvin" , Konrad Wilk 
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	<507ED6C0.4020503@zytor.com>
	<20121017161036.GA10691@phenom.dumpdata.com>
	<507EE1C3.7070300@zytor.com>
	<20121017165452.GA22740@phenom.dumpdata.com>
	<507EEC53.1010309@zytor.com>
In-Reply-To: <507EEC53.1010309@zytor.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: linux-acpi@vger.kernel.org, x86@kernel.org, xen-devel@lists.xensource.com,
	lenb@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] Is: axe read_tscp pvops call. Was: Re: [RFC] ACPI
 S3 and Xen (suprisingly small\!).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: H. Peter Anvin [mailto:hpa@zytor.com]
> Sent: Wednesday, October 17, 2012 11:35 AM
> To: Konrad Rzeszutek Wilk
> Cc: linux-acpi@vger.kernel.org; x86@kernel.org; xen-devel@lists.xensource.com; linux-
> kernel@vger.kernel.org; lenb@kernel.org
> Subject: Re: [Xen-devel] Is: axe read_tscp pvops call. Was: Re: [RFC] ACPI S3 and Xen (suprisingly
> small\!).
> 
> On 10/17/2012 09:54 AM, Konrad Rzeszutek Wilk wrote:
> >>
> >> Could you do an audit for other pvops calls that have no users?  If
> >> the *only* user is lguest, we should talk about it, too...
> >
> > I can do that - but I don't want to be hasty here. There is a bit of
> > danger here - for example the read_pmc (or read_tsc) is not in use right
> > now. But it might be when one starts looking at making perf be able to
> > analyze the hypervisor (hand-waving the implementation details). So while
> > removing read_pmc now sounds good, it might be needed in the future.
> >
> 
> We do not keep a pvop around just because it "might be needed in the
> future".  That's just crazy.
> 
> 	-hpa

It's a bit more complicated than that.  The problem is that if
any patch is ever submitted to the kernel that uses the rdtscp
instruction *in kernel space* in some clever way, the resultant
kernel may not behave as expected (depending on how the instruction
is used) on a 32-bit[1] PV kernel running on Xen, up to and including
the possibility of data corruption.

I don't know how one would implement it, but it's like a
BUILD_BUG_ON is needed if any kernel developer uses rdtscp
(one that never gets invoked by vdso code), that prints:

"WARNING: Please do not use this instruction in the kernel
without notifying the Xen maintainer as there is a possibility
it may behave unpredictably in some Xen environments.
See Documentation/.../xen_pv_limitations for detail."

The other virtualization-unsafe instructions may have similar
problems.

Just FYI...

Dan

[1] I _think_ this is not a problem on 64-bit kernels but
am not certain.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 15:29:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 15:29:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOs1p-0002Qt-6C; Thu, 18 Oct 2012 15:28:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOs1n-0002Qo-NC
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 15:28:55 +0000
Received: from [193.109.254.147:34697] by server-13.bemta-14.messagelabs.com
	id 8C/46-21440-63020805; Thu, 18 Oct 2012 15:28:54 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1350574132!13762789!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1459 invoked from network); 18 Oct 2012 15:28:54 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Oct 2012 15:28:54 -0000
Received: from tazenda.hos.anvin.org (c-67-188-81-177.hsd1.ca.comcast.net
	[67.188.81.177]) (authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id q9IFSm0k016503
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256
	verify=FAIL); Thu, 18 Oct 2012 08:28:49 -0700
Message-ID: <50802030.8070107@zytor.com>
Date: Thu, 18 Oct 2012 08:28:48 -0700
From: "H. Peter Anvin" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121009 Thunderbird/16.0
MIME-Version: 1.0
To: Dan Magenheimer 
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	<507ED6C0.4020503@zytor.com>
	<20121017161036.GA10691@phenom.dumpdata.com>
	<507EE1C3.7070300@zytor.com>
	<20121017165452.GA22740@phenom.dumpdata.com>
	<507EEC53.1010309@zytor.com>
	<84b3cbf9-7c84-4d7e-a2d7-46b0d1cc5975@default>
In-Reply-To: <84b3cbf9-7c84-4d7e-a2d7-46b0d1cc5975@default>
Cc: xen-devel@lists.xensource.com, Konrad Wilk ,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] Is: axe read_tscp pvops call. Was: Re: [RFC] ACPI
 S3 and Xen (suprisingly small\!).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/18/2012 08:22 AM, Dan Magenheimer wrote:
>
> It's a bit more complicated than that.  The problem is that if
> any patch is ever submitted to the kernel that uses the rdtscp
> instruction *in kernel space* in some clever way, the resultant
> kernel may not behave as expected (depending on how the instruction
> is used) on a 32-bit[1] PV kernel running on Xen, up to and including
> the possibility of data corruption.
>
> I don't know how one would implement it, but it's like a
> BUILD_BUG_ON is needed if any kernel developer uses rdtscp
> (one that never gets invoked by vdso code), that prints:
>
> "WARNING: Please do not use this instruction in the kernel
> without notifying the Xen maintainer as there is a possibility
> it may behave unpredictably in some Xen environments.
> See Documentation/.../xen_pv_limitations for detail."
>
> The other virtualization-unsafe instructions may have similar
> problems.
>

Good frakking God.  This is the sort of things that makes me think that 
Xen PV should just be thrown out of the kernel once and for all.

Do you notice that the document you just claimed doesn't even exist at 
this point, never mind being somehow enforced?  In other word, there is 
ABSOLUTELY NO WAY a mainline kernel developer can have any idea what 
amount of violence Xen does to the architecture that it is parasiting on.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 15:29:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 15:29:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOs1p-0002Qt-6C; Thu, 18 Oct 2012 15:28:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOs1n-0002Qo-NC
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 15:28:55 +0000
Received: from [193.109.254.147:34697] by server-13.bemta-14.messagelabs.com
	id 8C/46-21440-63020805; Thu, 18 Oct 2012 15:28:54 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1350574132!13762789!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1459 invoked from network); 18 Oct 2012 15:28:54 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Oct 2012 15:28:54 -0000
Received: from tazenda.hos.anvin.org (c-67-188-81-177.hsd1.ca.comcast.net
	[67.188.81.177]) (authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id q9IFSm0k016503
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256
	verify=FAIL); Thu, 18 Oct 2012 08:28:49 -0700
Message-ID: <50802030.8070107@zytor.com>
Date: Thu, 18 Oct 2012 08:28:48 -0700
From: "H. Peter Anvin" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121009 Thunderbird/16.0
MIME-Version: 1.0
To: Dan Magenheimer 
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	<507ED6C0.4020503@zytor.com>
	<20121017161036.GA10691@phenom.dumpdata.com>
	<507EE1C3.7070300@zytor.com>
	<20121017165452.GA22740@phenom.dumpdata.com>
	<507EEC53.1010309@zytor.com>
	<84b3cbf9-7c84-4d7e-a2d7-46b0d1cc5975@default>
In-Reply-To: <84b3cbf9-7c84-4d7e-a2d7-46b0d1cc5975@default>
Cc: xen-devel@lists.xensource.com, Konrad Wilk ,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] Is: axe read_tscp pvops call. Was: Re: [RFC] ACPI
 S3 and Xen (suprisingly small\!).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/18/2012 08:22 AM, Dan Magenheimer wrote:
>
> It's a bit more complicated than that.  The problem is that if
> any patch is ever submitted to the kernel that uses the rdtscp
> instruction *in kernel space* in some clever way, the resultant
> kernel may not behave as expected (depending on how the instruction
> is used) on a 32-bit[1] PV kernel running on Xen, up to and including
> the possibility of data corruption.
>
> I don't know how one would implement it, but it's like a
> BUILD_BUG_ON is needed if any kernel developer uses rdtscp
> (one that never gets invoked by vdso code), that prints:
>
> "WARNING: Please do not use this instruction in the kernel
> without notifying the Xen maintainer as there is a possibility
> it may behave unpredictably in some Xen environments.
> See Documentation/.../xen_pv_limitations for detail."
>
> The other virtualization-unsafe instructions may have similar
> problems.
>

Good frakking God.  This is the sort of things that makes me think that 
Xen PV should just be thrown out of the kernel once and for all.

Do you notice that the document you just claimed doesn't even exist at 
this point, never mind being somehow enforced?  In other word, there is 
ABSOLUTELY NO WAY a mainline kernel developer can have any idea what 
amount of violence Xen does to the architecture that it is parasiting on.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 15:31:15 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 15:31:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOs3k-0002Xd-Rh; Thu, 18 Oct 2012 15:30:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOs3j-0002XU-2A
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 15:30:55 +0000
Received: from [193.109.254.147:21604] by server-6.bemta-14.messagelabs.com id
	7E/A6-17826-EA020805; Thu, 18 Oct 2012 15:30:54 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1350574250!1797073!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30925 invoked from network); 18 Oct 2012 15:30:51 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 15:30:51 -0000
Received: by mail-vb0-f45.google.com with SMTP id p1so10942073vbi.32
	for ; Thu, 18 Oct 2012 08:30:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=e7IHB4ubhVO1dBl+rOqIWfc5uyICbc7B7aG2lMJln/c=;
	b=ZbTlQg+8s1B6itG4j/G/76MkRAzPqphe3nIAkb3vXrxTabPZ3soWkuw/+bkwk9xtKi
	ElIXJqkjPQhw9nEUuqJ//qI9mZW2PkoocFqzkUeqh2zXK2ttBqacAtxE3FQ8XJLnsf79
	Qh5REPBkrqnF5eVEo/N4/zCfClphh65v+mEVNuPna9OWk83xCQk4MQkJf8IsGaPl/xPd
	rZtOypFda5OdXOiNARILcuZ4QkmfuQnH9YNV7mtGYY6n/+plgQLIuo/KIqLbGmJlTl6x
	k5rRVwPrA8TD4REPSHMmnUB7jg2cHDP+/fESJosTCEeA9ZWaE4QamOILNU9tUkp6nw7j
	ER4g==
MIME-Version: 1.0
Received: by 10.58.132.241 with SMTP id ox17mr16424147veb.42.1350574250233;
	Thu, 18 Oct 2012 08:30:50 -0700 (PDT)
Received: by 10.58.231.138 with HTTP; Thu, 18 Oct 2012 08:30:50 -0700 (PDT)
In-Reply-To: <6d7a403305dd057f61bd.1350408388@Solace>
References: 
	<6d7a403305dd057f61bd.1350408388@Solace>
Date: Thu, 18 Oct 2012 16:30:50 +0100
X-Google-Sender-Auth: io0uIgaMf2WiFXBATzi2liqjn6E
Message-ID: 
From: George Dunlap 
To: Dario Faggioli 
Cc: Andre Przywara ,
	Ian Jackson ,
	Ian Campbell , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3 of 3] xl: allow for node-wise
 specification of vcpu pinning
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 16, 2012 at 6:26 PM, Dario Faggioli
 wrote:
> Making it possible to use something like the following:
>  * "nodes:0-3": all pCPUs of nodes 0,1,2,3;
>  * "nodes:0-3,^node:2": all pCPUS of nodes 0,1,3;
>  * "1,nodes:1-2,^6": pCPU 1 plus all pCPUs of nodes 1,2 but not pCPU 6;
>  * ...
>
> In both domain config file and `xl vcpu-pin'.
>
> Signed-off-by: Dario Faggioli 

Is it OK if I give this an "I'm OK with the idea but I'm too lazy to
figure out if the parsing code is doing the right thing" Ack? :-)

 -George

>
> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
> @@ -109,7 +109,7 @@ some cpus on its own (see below). A C
>  =over 4
>
> -=item "all"
> +=item "all" (or "nodes:all")
>
>  To allow all the vcpus of the guest to run on all the cpus on the host.
>
> @@ -117,6 +117,14 @@ To allow all the vcpus of the guest to r
>
>  To allow all the vcpus of the guest to run on cpus 0,2,3,5.
>
> +=item "nodes:0-3,^node:2"
> +
> +To allow all the vcpus of the guest to run on the cpus belonging to
> +the NUMA nodes 0,1,3 of the host. Notice that it is possible to combine
> +this syntax with the one above. That means, something like "1,node:2,^6"
> +is possible and means all the vcpus of the guest will run on cpus 1 plus
> +on all the cpus of node 2, but never on cpu 6.
> +
>  =item ["2", "3"] (or [2, 3])
>
>  To ask for specific vcpu mapping. That means (in this example), vcpu #0
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -506,31 +506,58 @@ static void split_string_into_string_lis
>
>  static int vcpupin_parse(char *cpu, libxl_bitmap *cpumap)
>  {
> -    libxl_bitmap exclude_cpumap;
> -    uint32_t cpuida, cpuidb;
> +    libxl_bitmap nodemap, cpu_nodemap;
> +    libxl_bitmap exclude_cpumap, exclude_nodemap;
> +    uint32_t ida, idb;
>      char *endptr, *toka, *tokb, *saveptr = NULL;
> -    int i, rc = 0, rmcpu;
> -
> -    if (!strcmp(cpu, "all")) {
> +    int i, rc = 0, isnot, isnode;
> +
> +    if (!strcmp(cpu, "all") || !strcmp(cpu, "nodes:all")) {
>          libxl_bitmap_set_any(cpumap);
>          return 0;
>      }
>
> -    if (libxl_cpu_bitmap_alloc(ctx, &exclude_cpumap, 0)) {
> +    libxl_bitmap_init(&cpu_nodemap);
> +    libxl_bitmap_init(&nodemap);
> +    libxl_bitmap_init(&exclude_nodemap);
> +    libxl_bitmap_init(&exclude_nodemap);
> +
> +    rc = libxl_node_bitmap_alloc(ctx, &cpu_nodemap, 0);
> +    if (rc) {
> +        fprintf(stderr, "Error: Failed to allocate nodemap.\n");
> +        goto vcpp_out;
> +    }
> +    rc = libxl_node_bitmap_alloc(ctx, &nodemap, 0);
> +    if (rc) {
> +        fprintf(stderr, "Error: Failed to allocate nodemap.\n");
> +        goto vcpp_out;
> +    }
> +    rc = libxl_node_bitmap_alloc(ctx, &exclude_nodemap, 0);
> +    if (rc) {
> +        fprintf(stderr, "Error: Failed to allocate nodemap.\n");
> +        goto vcpp_out;
> +    }
> +    rc = libxl_cpu_bitmap_alloc(ctx, &exclude_cpumap, 0);
> +    if (rc) {
>          fprintf(stderr, "Error: Failed to allocate cpumap.\n");
> -        return ENOMEM;
> +        goto vcpp_out;
>      }
>
>      for (toka = strtok_r(cpu, ",", &saveptr); toka;
>           toka = strtok_r(NULL, ",", &saveptr)) {
> -        rmcpu = 0;
> +        isnot = 0; isnode = 0;
>          if (*toka == '^') {
> -            /* This (These) Cpu(s) will be removed from the map */
> +            /* This (These) Cpu(s)/Node(s) will be removed from the map */
>              toka++;
> -            rmcpu = 1;
> -        }
> -        /* Extract a valid (range of) cpu(s) */
> -        cpuida = cpuidb = strtoul(toka, &endptr, 10);
> +            isnot = 1;
> +        }
> +        /* Check if we're dealing with a full node */
> +        if (strstr(toka, "node:") == toka || strstr(toka, "nodes:") == toka) {
> +            toka += 5 + (toka[4] == 's');
> +            isnode = 1;
> +        }
> +        /* Extract a valid (range of) cpu(s) or node(s) */
> +        ida = idb = strtoul(toka, &endptr, 10);
>          if (endptr == toka) {
>              fprintf(stderr, "Error: Invalid argument.\n");
>              rc = EINVAL;
> @@ -538,27 +565,48 @@ static int vcpupin_parse(char *cpu, libx
>          }
>          if (*endptr == '-') {
>              tokb = endptr + 1;
> -            cpuidb = strtoul(tokb, &endptr, 10);
> -            if (endptr == tokb || cpuida > cpuidb) {
> +            idb = strtoul(tokb, &endptr, 10);
> +            if (endptr == tokb || ida > idb) {
>                  fprintf(stderr, "Error: Invalid argument.\n");
>                  rc = EINVAL;
>                  goto vcpp_out;
>              }
>          }
> -        while (cpuida <= cpuidb) {
> -            rmcpu == 0 ? libxl_bitmap_set(cpumap, cpuida) :
> -                         libxl_bitmap_set(&exclude_cpumap, cpuida);
> -            cpuida++;
> -        }
> -    }
> -
> -    /* Clear all the cpus from the removal list */
> +        while (ida <= idb) {
> +            if (!isnode)
> +                isnot == 0 ? libxl_bitmap_set(cpumap, ida) :
> +                             libxl_bitmap_set(&exclude_cpumap, ida);
> +            else
> +                isnot == 0 ? libxl_bitmap_set(&nodemap, ida) :
> +                             libxl_bitmap_set(&exclude_nodemap, ida);
> +            ida++;
> +        }
> +    }
> +
> +    /* Add the cpus that have been specified via "node:" items */
> +    rc = libxl_nodemap_to_cpumap(ctx, &nodemap, &cpu_nodemap);
> +    if (rc)
> +        goto vcpp_out;
> +    libxl_for_each_set_bit(i, cpu_nodemap) {
> +        libxl_bitmap_set(cpumap, i);
> +    }
> +
> +    /* Clear all the cpus from the removal cpu and node lists */
>      libxl_for_each_set_bit(i, exclude_cpumap) {
>          libxl_bitmap_reset(cpumap, i);
>      }
> +    rc = libxl_nodemap_to_cpumap(ctx, &exclude_nodemap, &cpu_nodemap);
> +    if (rc)
> +        goto vcpp_out;
> +    libxl_for_each_set_bit(i, cpu_nodemap) {
> +        libxl_bitmap_reset(cpumap, i);
> +    }
>
>  vcpp_out:
>      libxl_bitmap_dispose(&exclude_cpumap);
> +    libxl_bitmap_dispose(&exclude_nodemap);
> +    libxl_bitmap_dispose(&nodemap);
> +    libxl_bitmap_dispose(&cpu_nodemap);
>
>      return rc;
>  }
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 15:31:15 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 15:31:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOs3k-0002Xd-Rh; Thu, 18 Oct 2012 15:30:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOs3j-0002XU-2A
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 15:30:55 +0000
Received: from [193.109.254.147:21604] by server-6.bemta-14.messagelabs.com id
	7E/A6-17826-EA020805; Thu, 18 Oct 2012 15:30:54 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1350574250!1797073!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30925 invoked from network); 18 Oct 2012 15:30:51 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 15:30:51 -0000
Received: by mail-vb0-f45.google.com with SMTP id p1so10942073vbi.32
	for ; Thu, 18 Oct 2012 08:30:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=e7IHB4ubhVO1dBl+rOqIWfc5uyICbc7B7aG2lMJln/c=;
	b=ZbTlQg+8s1B6itG4j/G/76MkRAzPqphe3nIAkb3vXrxTabPZ3soWkuw/+bkwk9xtKi
	ElIXJqkjPQhw9nEUuqJ//qI9mZW2PkoocFqzkUeqh2zXK2ttBqacAtxE3FQ8XJLnsf79
	Qh5REPBkrqnF5eVEo/N4/zCfClphh65v+mEVNuPna9OWk83xCQk4MQkJf8IsGaPl/xPd
	rZtOypFda5OdXOiNARILcuZ4QkmfuQnH9YNV7mtGYY6n/+plgQLIuo/KIqLbGmJlTl6x
	k5rRVwPrA8TD4REPSHMmnUB7jg2cHDP+/fESJosTCEeA9ZWaE4QamOILNU9tUkp6nw7j
	ER4g==
MIME-Version: 1.0
Received: by 10.58.132.241 with SMTP id ox17mr16424147veb.42.1350574250233;
	Thu, 18 Oct 2012 08:30:50 -0700 (PDT)
Received: by 10.58.231.138 with HTTP; Thu, 18 Oct 2012 08:30:50 -0700 (PDT)
In-Reply-To: <6d7a403305dd057f61bd.1350408388@Solace>
References: 
	<6d7a403305dd057f61bd.1350408388@Solace>
Date: Thu, 18 Oct 2012 16:30:50 +0100
X-Google-Sender-Auth: io0uIgaMf2WiFXBATzi2liqjn6E
Message-ID: 
From: George Dunlap 
To: Dario Faggioli 
Cc: Andre Przywara ,
	Ian Jackson ,
	Ian Campbell , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3 of 3] xl: allow for node-wise
 specification of vcpu pinning
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 16, 2012 at 6:26 PM, Dario Faggioli
 wrote:
> Making it possible to use something like the following:
>  * "nodes:0-3": all pCPUs of nodes 0,1,2,3;
>  * "nodes:0-3,^node:2": all pCPUS of nodes 0,1,3;
>  * "1,nodes:1-2,^6": pCPU 1 plus all pCPUs of nodes 1,2 but not pCPU 6;
>  * ...
>
> In both domain config file and `xl vcpu-pin'.
>
> Signed-off-by: Dario Faggioli 

Is it OK if I give this an "I'm OK with the idea but I'm too lazy to
figure out if the parsing code is doing the right thing" Ack? :-)

 -George

>
> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
> @@ -109,7 +109,7 @@ some cpus on its own (see below). A C
>  =over 4
>
> -=item "all"
> +=item "all" (or "nodes:all")
>
>  To allow all the vcpus of the guest to run on all the cpus on the host.
>
> @@ -117,6 +117,14 @@ To allow all the vcpus of the guest to r
>
>  To allow all the vcpus of the guest to run on cpus 0,2,3,5.
>
> +=item "nodes:0-3,^node:2"
> +
> +To allow all the vcpus of the guest to run on the cpus belonging to
> +the NUMA nodes 0,1,3 of the host. Notice that it is possible to combine
> +this syntax with the one above. That means, something like "1,node:2,^6"
> +is possible and means all the vcpus of the guest will run on cpus 1 plus
> +on all the cpus of node 2, but never on cpu 6.
> +
>  =item ["2", "3"] (or [2, 3])
>
>  To ask for specific vcpu mapping. That means (in this example), vcpu #0
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -506,31 +506,58 @@ static void split_string_into_string_lis
>
>  static int vcpupin_parse(char *cpu, libxl_bitmap *cpumap)
>  {
> -    libxl_bitmap exclude_cpumap;
> -    uint32_t cpuida, cpuidb;
> +    libxl_bitmap nodemap, cpu_nodemap;
> +    libxl_bitmap exclude_cpumap, exclude_nodemap;
> +    uint32_t ida, idb;
>      char *endptr, *toka, *tokb, *saveptr = NULL;
> -    int i, rc = 0, rmcpu;
> -
> -    if (!strcmp(cpu, "all")) {
> +    int i, rc = 0, isnot, isnode;
> +
> +    if (!strcmp(cpu, "all") || !strcmp(cpu, "nodes:all")) {
>          libxl_bitmap_set_any(cpumap);
>          return 0;
>      }
>
> -    if (libxl_cpu_bitmap_alloc(ctx, &exclude_cpumap, 0)) {
> +    libxl_bitmap_init(&cpu_nodemap);
> +    libxl_bitmap_init(&nodemap);
> +    libxl_bitmap_init(&exclude_nodemap);
> +    libxl_bitmap_init(&exclude_nodemap);
> +
> +    rc = libxl_node_bitmap_alloc(ctx, &cpu_nodemap, 0);
> +    if (rc) {
> +        fprintf(stderr, "Error: Failed to allocate nodemap.\n");
> +        goto vcpp_out;
> +    }
> +    rc = libxl_node_bitmap_alloc(ctx, &nodemap, 0);
> +    if (rc) {
> +        fprintf(stderr, "Error: Failed to allocate nodemap.\n");
> +        goto vcpp_out;
> +    }
> +    rc = libxl_node_bitmap_alloc(ctx, &exclude_nodemap, 0);
> +    if (rc) {
> +        fprintf(stderr, "Error: Failed to allocate nodemap.\n");
> +        goto vcpp_out;
> +    }
> +    rc = libxl_cpu_bitmap_alloc(ctx, &exclude_cpumap, 0);
> +    if (rc) {
>          fprintf(stderr, "Error: Failed to allocate cpumap.\n");
> -        return ENOMEM;
> +        goto vcpp_out;
>      }
>
>      for (toka = strtok_r(cpu, ",", &saveptr); toka;
>           toka = strtok_r(NULL, ",", &saveptr)) {
> -        rmcpu = 0;
> +        isnot = 0; isnode = 0;
>          if (*toka == '^') {
> -            /* This (These) Cpu(s) will be removed from the map */
> +            /* This (These) Cpu(s)/Node(s) will be removed from the map */
>              toka++;
> -            rmcpu = 1;
> -        }
> -        /* Extract a valid (range of) cpu(s) */
> -        cpuida = cpuidb = strtoul(toka, &endptr, 10);
> +            isnot = 1;
> +        }
> +        /* Check if we're dealing with a full node */
> +        if (strstr(toka, "node:") == toka || strstr(toka, "nodes:") == toka) {
> +            toka += 5 + (toka[4] == 's');
> +            isnode = 1;
> +        }
> +        /* Extract a valid (range of) cpu(s) or node(s) */
> +        ida = idb = strtoul(toka, &endptr, 10);
>          if (endptr == toka) {
>              fprintf(stderr, "Error: Invalid argument.\n");
>              rc = EINVAL;
> @@ -538,27 +565,48 @@ static int vcpupin_parse(char *cpu, libx
>          }
>          if (*endptr == '-') {
>              tokb = endptr + 1;
> -            cpuidb = strtoul(tokb, &endptr, 10);
> -            if (endptr == tokb || cpuida > cpuidb) {
> +            idb = strtoul(tokb, &endptr, 10);
> +            if (endptr == tokb || ida > idb) {
>                  fprintf(stderr, "Error: Invalid argument.\n");
>                  rc = EINVAL;
>                  goto vcpp_out;
>              }
>          }
> -        while (cpuida <= cpuidb) {
> -            rmcpu == 0 ? libxl_bitmap_set(cpumap, cpuida) :
> -                         libxl_bitmap_set(&exclude_cpumap, cpuida);
> -            cpuida++;
> -        }
> -    }
> -
> -    /* Clear all the cpus from the removal list */
> +        while (ida <= idb) {
> +            if (!isnode)
> +                isnot == 0 ? libxl_bitmap_set(cpumap, ida) :
> +                             libxl_bitmap_set(&exclude_cpumap, ida);
> +            else
> +                isnot == 0 ? libxl_bitmap_set(&nodemap, ida) :
> +                             libxl_bitmap_set(&exclude_nodemap, ida);
> +            ida++;
> +        }
> +    }
> +
> +    /* Add the cpus that have been specified via "node:" items */
> +    rc = libxl_nodemap_to_cpumap(ctx, &nodemap, &cpu_nodemap);
> +    if (rc)
> +        goto vcpp_out;
> +    libxl_for_each_set_bit(i, cpu_nodemap) {
> +        libxl_bitmap_set(cpumap, i);
> +    }
> +
> +    /* Clear all the cpus from the removal cpu and node lists */
>      libxl_for_each_set_bit(i, exclude_cpumap) {
>          libxl_bitmap_reset(cpumap, i);
>      }
> +    rc = libxl_nodemap_to_cpumap(ctx, &exclude_nodemap, &cpu_nodemap);
> +    if (rc)
> +        goto vcpp_out;
> +    libxl_for_each_set_bit(i, cpu_nodemap) {
> +        libxl_bitmap_reset(cpumap, i);
> +    }
>
>  vcpp_out:
>      libxl_bitmap_dispose(&exclude_cpumap);
> +    libxl_bitmap_dispose(&exclude_nodemap);
> +    libxl_bitmap_dispose(&nodemap);
> +    libxl_bitmap_dispose(&cpu_nodemap);
>
>      return rc;
>  }
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 15:34:59 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 15:34:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOs7K-0002mi-Ls; Thu, 18 Oct 2012 15:34:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOs7I-0002mV-Gz
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 15:34:36 +0000
Received: from [85.158.139.83:57493] by server-9.bemta-5.messagelabs.com id
	59/83-23053-98120805; Thu, 18 Oct 2012 15:34:33 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1350574468!35462094!1
X-Originating-IP: [8.30.156.6]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17927 invoked from network); 18 Oct 2012 15:34:30 -0000
Received: from mail5.spectralogic.com (HELO mail5.spectralogic.com)
	(8.30.156.6)
	by server-3.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	18 Oct 2012 15:34:30 -0000
From: Justin Gibbs 
To: Konrad Rzeszutek Wilk 
Thread-Topic: xen-vbd interface (segment size expansion) - FreeBSD host have
	it.
Thread-Index: AQHNmzOnmOc+lKmZ60q/y1gwuMXhJ5e+1qAAgADXZgCAAAxKgA==
Date: Thu, 18 Oct 2012 15:34:27 +0000
Message-ID: <61DFA8800400A143A5A7C5E136A726DC5F9D0C67@reactor.sldomain.com>
References: 
	<20120817172838.GA3515@phenom.dumpdata.com>
	
	<61DFA8800400A143A5A7C5E136A726DC5F867490@reactor.sldomain.com>
	<20120925152600.GA967@phenom.dumpdata.com>
	
	<20121018145030.GD19782@localhost.localdomain>
In-Reply-To: <20121018145030.GD19782@localhost.localdomain>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [70.89.174.89]
Content-ID: <412FFC995945FA4CBDF82902946265A1@spectralogic.com>
MIME-Version: 1.0
Cc: "Duan, Ronghui" ,
	"xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] xen-vbd interface (segment size expansion) -
 FreeBSD host have it.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Oct 18, 2012, at 8:50 AM, Konrad Rzeszutek Wilk 
 wrote:

> On Thu, Oct 18, 2012 at 01:59:36AM +0000, Duan, Ronghui wrote:
>> Hi, I am back from a long holiday. Sorry for the delay replay.
>>> I was wondering how the protocol you developed works when it comes to
>>> migration to a host that does not support the new features?
>>> 
>> For my part, when VM migrate to a host which do not support larger segments, frontend will fall back to use original protocol with old-segments 11.
>> 
>>> Specifically how do deal with a guest which tries to replay in progress I/Os
>>> that do not fit within the old-segment size (11)?
>> The in-progress bio which have larger segments > 11 will receive an io error. I do not find a better way to handle it yet.
> 
> Justin, how did you guys handle it in FreeBSD? Or is it dependent on
> the backends always supporting these large segments?

The current API forces I/Os larger than 44k to get chopped up in
order to transit blkif.  The ability to negotiate a larger blkif
request size just means that you can sometimes reduce the amount
of "scatter-gather" work performed by the driver.  You must still
deal with the fact that a logical I/O submitted to blkfront may
need to be broken up, or may not completely fit within the size of
the negotiated ring.  Upon reconnect, the newly negotiated parameters
are in effect and reissued I/Os are subject to the rules that apply
to that connection.

I'd have to go review the FreeBSD blkfront driver to see if it
handles correctly all of the issues that arise with a ring that
shrinks (e.g. it may assume that an I/O will fit within an empty
ring), but there is certainly no technical reason that these issues
can't be addressed.

--
Justin


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 15:34:59 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 15:34:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOs7K-0002mi-Ls; Thu, 18 Oct 2012 15:34:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOs7I-0002mV-Gz
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 15:34:36 +0000
Received: from [85.158.139.83:57493] by server-9.bemta-5.messagelabs.com id
	59/83-23053-98120805; Thu, 18 Oct 2012 15:34:33 +0000
X-Env-Sender: justing@spectralogic.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1350574468!35462094!1
X-Originating-IP: [8.30.156.6]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	received_headers: No Received headers
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17927 invoked from network); 18 Oct 2012 15:34:30 -0000
Received: from mail5.spectralogic.com (HELO mail5.spectralogic.com)
	(8.30.156.6)
	by server-3.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	18 Oct 2012 15:34:30 -0000
From: Justin Gibbs 
To: Konrad Rzeszutek Wilk 
Thread-Topic: xen-vbd interface (segment size expansion) - FreeBSD host have
	it.
Thread-Index: AQHNmzOnmOc+lKmZ60q/y1gwuMXhJ5e+1qAAgADXZgCAAAxKgA==
Date: Thu, 18 Oct 2012 15:34:27 +0000
Message-ID: <61DFA8800400A143A5A7C5E136A726DC5F9D0C67@reactor.sldomain.com>
References: 
	<20120817172838.GA3515@phenom.dumpdata.com>
	
	<61DFA8800400A143A5A7C5E136A726DC5F867490@reactor.sldomain.com>
	<20120925152600.GA967@phenom.dumpdata.com>
	
	<20121018145030.GD19782@localhost.localdomain>
In-Reply-To: <20121018145030.GD19782@localhost.localdomain>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [70.89.174.89]
Content-ID: <412FFC995945FA4CBDF82902946265A1@spectralogic.com>
MIME-Version: 1.0
Cc: "Duan, Ronghui" ,
	"xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] xen-vbd interface (segment size expansion) -
 FreeBSD host have it.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Oct 18, 2012, at 8:50 AM, Konrad Rzeszutek Wilk 
 wrote:

> On Thu, Oct 18, 2012 at 01:59:36AM +0000, Duan, Ronghui wrote:
>> Hi, I am back from a long holiday. Sorry for the delay replay.
>>> I was wondering how the protocol you developed works when it comes to
>>> migration to a host that does not support the new features?
>>> 
>> For my part, when VM migrate to a host which do not support larger segments, frontend will fall back to use original protocol with old-segments 11.
>> 
>>> Specifically how do deal with a guest which tries to replay in progress I/Os
>>> that do not fit within the old-segment size (11)?
>> The in-progress bio which have larger segments > 11 will receive an io error. I do not find a better way to handle it yet.
> 
> Justin, how did you guys handle it in FreeBSD? Or is it dependent on
> the backends always supporting these large segments?

The current API forces I/Os larger than 44k to get chopped up in
order to transit blkif.  The ability to negotiate a larger blkif
request size just means that you can sometimes reduce the amount
of "scatter-gather" work performed by the driver.  You must still
deal with the fact that a logical I/O submitted to blkfront may
need to be broken up, or may not completely fit within the size of
the negotiated ring.  Upon reconnect, the newly negotiated parameters
are in effect and reissued I/Os are subject to the rules that apply
to that connection.

I'd have to go review the FreeBSD blkfront driver to see if it
handles correctly all of the issues that arise with a ring that
shrinks (e.g. it may assume that an I/O will fit within an empty
ring), but there is certainly no technical reason that these issues
can't be addressed.

--
Justin


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 15:57:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 15:57:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOsSr-00032Y-A5; Thu, 18 Oct 2012 15:56:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOsSp-00032R-8g
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 15:56:51 +0000
Received: from [85.158.143.99:26618] by server-2.bemta-4.messagelabs.com id
	2B/A4-22268-2C620805; Thu, 18 Oct 2012 15:56:50 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1350575808!26528188!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODEyNzI4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31416 invoked from network); 18 Oct 2012 15:56:49 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Oct 2012 15:56:49 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9IFuhRO013734
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 18 Oct 2012 15:56:44 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9IFugJk002563
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 18 Oct 2012 15:56:43 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9IFugEG004272; Thu, 18 Oct 2012 10:56:42 -0500
MIME-Version: 1.0
Message-ID: 
Date: Thu, 18 Oct 2012 08:56:40 -0700 (PDT)
From: Dan Magenheimer 
To: "H. Peter Anvin" 
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	<507ED6C0.4020503@zytor.com>
	<20121017161036.GA10691@phenom.dumpdata.com>
	<507EE1C3.7070300@zytor.com>
	<20121017165452.GA22740@phenom.dumpdata.com>
	<507EEC53.1010309@zytor.com>
	<84b3cbf9-7c84-4d7e-a2d7-46b0d1cc5975@default>
	<50802030.8070107@zytor.com>
In-Reply-To: <50802030.8070107@zytor.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xensource.com, Konrad Wilk ,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] Is: axe read_tscp pvops call. Was: Re: [RFC] ACPI
 S3 and Xen (suprisingly small\!).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: H. Peter Anvin [mailto:hpa@zytor.com]
> Subject: Re: [Xen-devel] Is: axe read_tscp pvops call. Was: Re: [RFC] ACPI S3 and Xen (suprisingly
> small\!).
> 
> On 10/18/2012 08:22 AM, Dan Magenheimer wrote:
> >
> > It's a bit more complicated than that.  The problem is that if
> > any patch is ever submitted to the kernel that uses the rdtscp
> > instruction *in kernel space* in some clever way, the resultant
> > kernel may not behave as expected (depending on how the instruction
> > is used) on a 32-bit[1] PV kernel running on Xen, up to and including
> > the possibility of data corruption.
> >
> > I don't know how one would implement it, but it's like a
> > BUILD_BUG_ON is needed if any kernel developer uses rdtscp
> > (one that never gets invoked by vdso code), that prints:
> >
> > "WARNING: Please do not use this instruction in the kernel
> > without notifying the Xen maintainer as there is a possibility
> > it may behave unpredictably in some Xen environments.
> > See Documentation/.../xen_pv_limitations for detail."
> >
> > The other virtualization-unsafe instructions may have similar
> > problems.
> >
> 
> Good frakking God.  This is the sort of things that makes me think that
> Xen PV should just be thrown out of the kernel once and for all.

I agree the whole idea of paravirtualization is a hack, but it
is a hack to workaround some poor architectural design decisions
many years ago by Intel processor designers who should have known
better.  Go yell at them.

Worse, the rdtscp instruction was a poor design decision by
AMD processor designers to hack around tsc skew problems.
Go yell at them too.

And both Intel and AMD chose to perpetuate the problem
with a complicated VT/SVM implementation that will never
perform as well as native.  At least they tried ;-)
 
> Do you notice that the document you just claimed doesn't even exist at
> this point, never mind being somehow enforced?  In other word, there is
> ABSOLUTELY NO WAY a mainline kernel developer can have any idea what
> amount of violence Xen does to the architecture that it is parasiting on.

Of course I know it doesn't exist.  I probably should have
noted that in my email.  But it should exist because else
subtle issues like this will get lost in the mist of time.
And I have no clue how to enforce it (though some BUILD_BUG_ON
might help).

Like so many other things in the kernel (and computing in general),
paravirtualization is a tradeoff of maintainability for kernel/software
developers vs significant performance improvement for (a large
number of) users.  That tradeoff is above my pay grade.  But
it does provide job security.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 15:57:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 15:57:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOsSr-00032Y-A5; Thu, 18 Oct 2012 15:56:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOsSp-00032R-8g
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 15:56:51 +0000
Received: from [85.158.143.99:26618] by server-2.bemta-4.messagelabs.com id
	2B/A4-22268-2C620805; Thu, 18 Oct 2012 15:56:50 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1350575808!26528188!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODEyNzI4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31416 invoked from network); 18 Oct 2012 15:56:49 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Oct 2012 15:56:49 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9IFuhRO013734
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 18 Oct 2012 15:56:44 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9IFugJk002563
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 18 Oct 2012 15:56:43 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9IFugEG004272; Thu, 18 Oct 2012 10:56:42 -0500
MIME-Version: 1.0
Message-ID: 
Date: Thu, 18 Oct 2012 08:56:40 -0700 (PDT)
From: Dan Magenheimer 
To: "H. Peter Anvin" 
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	<507ED6C0.4020503@zytor.com>
	<20121017161036.GA10691@phenom.dumpdata.com>
	<507EE1C3.7070300@zytor.com>
	<20121017165452.GA22740@phenom.dumpdata.com>
	<507EEC53.1010309@zytor.com>
	<84b3cbf9-7c84-4d7e-a2d7-46b0d1cc5975@default>
	<50802030.8070107@zytor.com>
In-Reply-To: <50802030.8070107@zytor.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xensource.com, Konrad Wilk ,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] Is: axe read_tscp pvops call. Was: Re: [RFC] ACPI
 S3 and Xen (suprisingly small\!).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: H. Peter Anvin [mailto:hpa@zytor.com]
> Subject: Re: [Xen-devel] Is: axe read_tscp pvops call. Was: Re: [RFC] ACPI S3 and Xen (suprisingly
> small\!).
> 
> On 10/18/2012 08:22 AM, Dan Magenheimer wrote:
> >
> > It's a bit more complicated than that.  The problem is that if
> > any patch is ever submitted to the kernel that uses the rdtscp
> > instruction *in kernel space* in some clever way, the resultant
> > kernel may not behave as expected (depending on how the instruction
> > is used) on a 32-bit[1] PV kernel running on Xen, up to and including
> > the possibility of data corruption.
> >
> > I don't know how one would implement it, but it's like a
> > BUILD_BUG_ON is needed if any kernel developer uses rdtscp
> > (one that never gets invoked by vdso code), that prints:
> >
> > "WARNING: Please do not use this instruction in the kernel
> > without notifying the Xen maintainer as there is a possibility
> > it may behave unpredictably in some Xen environments.
> > See Documentation/.../xen_pv_limitations for detail."
> >
> > The other virtualization-unsafe instructions may have similar
> > problems.
> >
> 
> Good frakking God.  This is the sort of things that makes me think that
> Xen PV should just be thrown out of the kernel once and for all.

I agree the whole idea of paravirtualization is a hack, but it
is a hack to workaround some poor architectural design decisions
many years ago by Intel processor designers who should have known
better.  Go yell at them.

Worse, the rdtscp instruction was a poor design decision by
AMD processor designers to hack around tsc skew problems.
Go yell at them too.

And both Intel and AMD chose to perpetuate the problem
with a complicated VT/SVM implementation that will never
perform as well as native.  At least they tried ;-)
 
> Do you notice that the document you just claimed doesn't even exist at
> this point, never mind being somehow enforced?  In other word, there is
> ABSOLUTELY NO WAY a mainline kernel developer can have any idea what
> amount of violence Xen does to the architecture that it is parasiting on.

Of course I know it doesn't exist.  I probably should have
noted that in my email.  But it should exist because else
subtle issues like this will get lost in the mist of time.
And I have no clue how to enforce it (though some BUILD_BUG_ON
might help).

Like so many other things in the kernel (and computing in general),
paravirtualization is a tradeoff of maintainability for kernel/software
developers vs significant performance improvement for (a large
number of) users.  That tradeoff is above my pay grade.  But
it does provide job security.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 16:13:48 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 16:13:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOsir-0003hX-4h; Thu, 18 Oct 2012 16:13:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOsip-0003hS-Lp
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 16:13:23 +0000
Received: from [85.158.139.211:59089] by server-11.bemta-5.messagelabs.com id
	50/30-14870-2AA20805; Thu, 18 Oct 2012 16:13:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1350576802!21844506!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5277 invoked from network); 18 Oct 2012 16:13:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 16:13:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,608,1344211200"; d="scan'208";a="15260108"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 16:13:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 18 Oct 2012 17:13:21 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TOsim-0000Pu-SY;
	Thu, 18 Oct 2012 16:13:20 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TOsim-0007kl-Ru;
	Thu, 18 Oct 2012 17:13:20 +0100
To: 
Message-ID: 
From: xen.org 
Date: Thu, 18 Oct 2012 17:13:20 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14032: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14032 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14032/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 13967
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 13967
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 13967
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 13967
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 13967

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13967
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13967
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13967
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13967

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  3fa2ab30bb05
baseline version:
 xen                  c1c549c4fe9e

------------------------------------------------------------
People who touched revisions under test:
  Chuang Cao 
  Daniel De Graaf 
  Huang Ying 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Joe Jin 
  Keir Fraser 
  Olaf Hering 
  Sander Eikelenboom 
  Stefano Stabellini 
  Tim Deegan 
  Xiantao Zhang
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 592 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 16:13:48 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 16:13:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOsir-0003hX-4h; Thu, 18 Oct 2012 16:13:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOsip-0003hS-Lp
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 16:13:23 +0000
Received: from [85.158.139.211:59089] by server-11.bemta-5.messagelabs.com id
	50/30-14870-2AA20805; Thu, 18 Oct 2012 16:13:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1350576802!21844506!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5277 invoked from network); 18 Oct 2012 16:13:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 16:13:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,608,1344211200"; d="scan'208";a="15260108"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 16:13:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 18 Oct 2012 17:13:21 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TOsim-0000Pu-SY;
	Thu, 18 Oct 2012 16:13:20 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TOsim-0007kl-Ru;
	Thu, 18 Oct 2012 17:13:20 +0100
To: 
Message-ID: 
From: xen.org 
Date: Thu, 18 Oct 2012 17:13:20 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14032: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14032 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14032/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 13967
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 13967
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 13967
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 13967
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 13967

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13967
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13967
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13967
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13967

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  3fa2ab30bb05
baseline version:
 xen                  c1c549c4fe9e

------------------------------------------------------------
People who touched revisions under test:
  Chuang Cao 
  Daniel De Graaf 
  Huang Ying 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Joe Jin 
  Keir Fraser 
  Olaf Hering 
  Sander Eikelenboom 
  Stefano Stabellini 
  Tim Deegan 
  Xiantao Zhang
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 592 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 16:17:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 16:17:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOsmQ-0003od-QW; Thu, 18 Oct 2012 16:17:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOsmO-0003oV-GP
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 16:17:05 +0000
Received: from [85.158.137.99:2269] by server-8.bemta-3.messagelabs.com id
	35/35-10525-B7B20805; Thu, 18 Oct 2012 16:16:59 +0000
X-Env-Sender: bp@alien8.de
X-Msg-Ref: server-6.tower-217.messagelabs.com!1350577018!16984345!1
X-Originating-IP: [78.46.96.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12980 invoked from network); 18 Oct 2012 16:16:58 -0000
Received: from mail.skyhub.de (HELO mail.skyhub.de) (78.46.96.112)
	by server-6.tower-217.messagelabs.com with SMTP;
	18 Oct 2012 16:16:58 -0000
X-Virus-Scanned: Nedap ESD1 at mail.skyhub.de
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alien8.de; s=alien8;
	t=1350577018; bh=PnT+EtFeAghxWm3lE0k52Mp240OaUzZKW7PuQVlmA8I=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	Content-Type:In-Reply-To; b=AbrlYgUjA+Xoir2XG1m3oMAMaIjxriEPXlbV9i
	h2UpK0gjVO6h6T09P0uTe9ZsNeFyjxRXX7ZyAmRSxTccyh46w0Hkrjj47ARYOZmNH2r
	cTgImbbE1t9UdSsvVarQOSLuhzefX4133OCODmYLrgkkhuv/bmpXMiIcfvFtIR1fEc=
Received: from mail.skyhub.de ([127.0.0.1])
	by localhost (door.skyhub.de [127.0.0.1]) (amavisd-new, port 10026)
	with ESMTP id 3yLNnuZDRtc4; Thu, 18 Oct 2012 18:16:57 +0200 (CEST)
Received: from x1.localdomain (unknown [217.9.48.21])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id
	B03261D95EB; Thu, 18 Oct 2012 18:16:57 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alien8.de; s=alien8;
	t=1350577017; bh=PnT+EtFeAghxWm3lE0k52Mp240OaUzZKW7PuQVlmA8I=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	Content-Type:In-Reply-To; b=cSS4i+GbwW0VlRt2+EDpumGlhrqVg6vtC9vr96
	jUFhMJu+UjzlC/6zNaj1+UWobImJCjJMfsIAehxanw+f0HGlg/09b2zdmvF1Nou59Tn
	MQrS1n9wFHzaq0E2UeoB0z6lCrIaY6dkd10dbK22s561C8/5CissxWLNiloJCRHs4c=
Received: by x1.localdomain (Postfix, from userid 1000)
	id A2C59AA0BF; Thu, 18 Oct 2012 18:17:00 +0200 (CEST)
Date: Thu, 18 Oct 2012 18:17:00 +0200
From: Borislav Petkov 
To: Dan Magenheimer 
Message-ID: <20121018161659.GA20354@x1.osrc.amd.com>
Mail-Followup-To: Borislav Petkov ,
	Dan Magenheimer ,
	"H. Peter Anvin" ,
	Konrad Wilk , linux-acpi@vger.kernel.org,
	x86@kernel.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, lenb@kernel.org
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	<507ED6C0.4020503@zytor.com>
	<20121017161036.GA10691@phenom.dumpdata.com>
	<507EE1C3.7070300@zytor.com>
	<20121017165452.GA22740@phenom.dumpdata.com>
	<507EEC53.1010309@zytor.com>
	<84b3cbf9-7c84-4d7e-a2d7-46b0d1cc5975@default>
	<50802030.8070107@zytor.com>
	
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xensource.com, Konrad Wilk ,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, "H. Peter Anvin" ,
	lenb@kernel.org
Subject: Re: [Xen-devel] Is: axe read_tscp pvops call. Was: Re: [RFC] ACPI
 S3 and Xen (suprisingly small\!).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Oct 18, 2012 at 08:56:40AM -0700, Dan Magenheimer wrote:
> I agree the whole idea of paravirtualization is a hack, but it is a
> hack to workaround some poor architectural design decisions many years
> ago by Intel processor designers who should have known better. Go yell
> at them.
>
> Worse, the rdtscp instruction was a poor design decision by AMD
> processor designers to hack around tsc skew problems. Go yell at them
> too.
>
> And both Intel and AMD chose to perpetuate the problem with a
> complicated VT/SVM implementation that will never perform as well as
> native. At least they tried ;-)

Looks like xen people seem to know better so maybe they should design
their own processor, add xen support for it and leave the linux kernel
alone so that both camps can finally get on with their lives.

-- 
Regards/Gruss,
Boris.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 16:17:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 16:17:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOsmQ-0003od-QW; Thu, 18 Oct 2012 16:17:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOsmO-0003oV-GP
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 16:17:05 +0000
Received: from [85.158.137.99:2269] by server-8.bemta-3.messagelabs.com id
	35/35-10525-B7B20805; Thu, 18 Oct 2012 16:16:59 +0000
X-Env-Sender: bp@alien8.de
X-Msg-Ref: server-6.tower-217.messagelabs.com!1350577018!16984345!1
X-Originating-IP: [78.46.96.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12980 invoked from network); 18 Oct 2012 16:16:58 -0000
Received: from mail.skyhub.de (HELO mail.skyhub.de) (78.46.96.112)
	by server-6.tower-217.messagelabs.com with SMTP;
	18 Oct 2012 16:16:58 -0000
X-Virus-Scanned: Nedap ESD1 at mail.skyhub.de
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alien8.de; s=alien8;
	t=1350577018; bh=PnT+EtFeAghxWm3lE0k52Mp240OaUzZKW7PuQVlmA8I=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	Content-Type:In-Reply-To; b=AbrlYgUjA+Xoir2XG1m3oMAMaIjxriEPXlbV9i
	h2UpK0gjVO6h6T09P0uTe9ZsNeFyjxRXX7ZyAmRSxTccyh46w0Hkrjj47ARYOZmNH2r
	cTgImbbE1t9UdSsvVarQOSLuhzefX4133OCODmYLrgkkhuv/bmpXMiIcfvFtIR1fEc=
Received: from mail.skyhub.de ([127.0.0.1])
	by localhost (door.skyhub.de [127.0.0.1]) (amavisd-new, port 10026)
	with ESMTP id 3yLNnuZDRtc4; Thu, 18 Oct 2012 18:16:57 +0200 (CEST)
Received: from x1.localdomain (unknown [217.9.48.21])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id
	B03261D95EB; Thu, 18 Oct 2012 18:16:57 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alien8.de; s=alien8;
	t=1350577017; bh=PnT+EtFeAghxWm3lE0k52Mp240OaUzZKW7PuQVlmA8I=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	Content-Type:In-Reply-To; b=cSS4i+GbwW0VlRt2+EDpumGlhrqVg6vtC9vr96
	jUFhMJu+UjzlC/6zNaj1+UWobImJCjJMfsIAehxanw+f0HGlg/09b2zdmvF1Nou59Tn
	MQrS1n9wFHzaq0E2UeoB0z6lCrIaY6dkd10dbK22s561C8/5CissxWLNiloJCRHs4c=
Received: by x1.localdomain (Postfix, from userid 1000)
	id A2C59AA0BF; Thu, 18 Oct 2012 18:17:00 +0200 (CEST)
Date: Thu, 18 Oct 2012 18:17:00 +0200
From: Borislav Petkov 
To: Dan Magenheimer 
Message-ID: <20121018161659.GA20354@x1.osrc.amd.com>
Mail-Followup-To: Borislav Petkov ,
	Dan Magenheimer ,
	"H. Peter Anvin" ,
	Konrad Wilk , linux-acpi@vger.kernel.org,
	x86@kernel.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, lenb@kernel.org
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	<507ED6C0.4020503@zytor.com>
	<20121017161036.GA10691@phenom.dumpdata.com>
	<507EE1C3.7070300@zytor.com>
	<20121017165452.GA22740@phenom.dumpdata.com>
	<507EEC53.1010309@zytor.com>
	<84b3cbf9-7c84-4d7e-a2d7-46b0d1cc5975@default>
	<50802030.8070107@zytor.com>
	
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xensource.com, Konrad Wilk ,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, "H. Peter Anvin" ,
	lenb@kernel.org
Subject: Re: [Xen-devel] Is: axe read_tscp pvops call. Was: Re: [RFC] ACPI
 S3 and Xen (suprisingly small\!).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Oct 18, 2012 at 08:56:40AM -0700, Dan Magenheimer wrote:
> I agree the whole idea of paravirtualization is a hack, but it is a
> hack to workaround some poor architectural design decisions many years
> ago by Intel processor designers who should have known better. Go yell
> at them.
>
> Worse, the rdtscp instruction was a poor design decision by AMD
> processor designers to hack around tsc skew problems. Go yell at them
> too.
>
> And both Intel and AMD chose to perpetuate the problem with a
> complicated VT/SVM implementation that will never perform as well as
> native. At least they tried ;-)

Looks like xen people seem to know better so maybe they should design
their own processor, add xen support for it and leave the linux kernel
alone so that both camps can finally get on with their lives.

-- 
Regards/Gruss,
Boris.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 16:21:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 16:21:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOsqj-00047a-A2; Thu, 18 Oct 2012 16:21:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOsqh-00047M-P5; Thu, 18 Oct 2012 16:21:31 +0000
Received: from [85.158.139.83:56656] by server-15.bemta-5.messagelabs.com id
	EB/A2-28599-A8C20805; Thu, 18 Oct 2012 16:21:30 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1350577290!30953790!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30333 invoked from network); 18 Oct 2012 16:21:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 16:21:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,608,1344211200"; d="scan'208";a="15260281"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 16:21:30 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 18 Oct 2012 17:21:30 +0100
Date: Thu, 18 Oct 2012 17:21:06 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1350568154.2460.151.camel@zakaz.uk.xensource.com>
Message-ID: 
References: 
	<1350466992.2460.47.camel@zakaz.uk.xensource.com>
	
	<1350568154.2460.151.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-users@lists.xen.org" ,
	kk s , xen-devel ,
	Konrad Rzeszutek Wilk ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [Xen-users] Fedora 17 Dom-U booting issue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 18 Oct 2012, Ian Campbell wrote:
> On Thu, 2012-10-18 at 14:42 +0100, Stefano Stabellini wrote:
> > On Wed, 17 Oct 2012, Ian Campbell wrote:
> > > Adding xen-devel and the relevant maintainers.
> > > 
> > > On Tue, 2012-10-16 at 20:24 +0100, kk s wrote:
> > > > Hi Folks,
> > > > 
> > > > 
> > > > I have upgraded Fedora 16 to 17 on one of Xen HVM Dom-U and it refuses
> > > > to boot fine and getting the below error on console,
> > > > 
> > > > 
> > > > --------
> > > > Booting 'Fedora (3.6.1-1.fc17.x86_64)'
> > > > 
> > > > 
> > > > Loading Fedora (3.6.1-1.fc17.x86_64)
> > > > Loading initial ramdisk ...
> > > > [   0.000000] Cannot get hvm parameter 18: -22!
> > > 
> > > HVM parameter 18 is HVM_PARAM_CONSOLE_EVTCHN.
> > 
> > -22 is EINVAL, that Xen would return only if:
> > 
> > - the requested parameter is out of range
> > this is not the case, 18 < 30
> 
> The hypervisor here is 3.4.3 where the largest hvm param is:
> $ grep define.HVM_PARAM xen-3.4-testing.hg/xen/include/public/hvm/params.h | sort -k3 -n | tail -n 3
> #define HVM_PARAM_ACPI_S_STATE 14
> #define HVM_PARAM_VM86_TSS     15
> #define HVM_PARAM_VPT_ALIGN    16

OK, we know that the console is not working because it is not provided
by the hypervisor.
However that shouldn't prevent the domain from booting, the emulated
serial should work fine.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 16:21:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 16:21:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOsqj-00047a-A2; Thu, 18 Oct 2012 16:21:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOsqh-00047M-P5; Thu, 18 Oct 2012 16:21:31 +0000
Received: from [85.158.139.83:56656] by server-15.bemta-5.messagelabs.com id
	EB/A2-28599-A8C20805; Thu, 18 Oct 2012 16:21:30 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1350577290!30953790!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30333 invoked from network); 18 Oct 2012 16:21:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 16:21:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,608,1344211200"; d="scan'208";a="15260281"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 16:21:30 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 18 Oct 2012 17:21:30 +0100
Date: Thu, 18 Oct 2012 17:21:06 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1350568154.2460.151.camel@zakaz.uk.xensource.com>
Message-ID: 
References: 
	<1350466992.2460.47.camel@zakaz.uk.xensource.com>
	
	<1350568154.2460.151.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-users@lists.xen.org" ,
	kk s , xen-devel ,
	Konrad Rzeszutek Wilk ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [Xen-users] Fedora 17 Dom-U booting issue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 18 Oct 2012, Ian Campbell wrote:
> On Thu, 2012-10-18 at 14:42 +0100, Stefano Stabellini wrote:
> > On Wed, 17 Oct 2012, Ian Campbell wrote:
> > > Adding xen-devel and the relevant maintainers.
> > > 
> > > On Tue, 2012-10-16 at 20:24 +0100, kk s wrote:
> > > > Hi Folks,
> > > > 
> > > > 
> > > > I have upgraded Fedora 16 to 17 on one of Xen HVM Dom-U and it refuses
> > > > to boot fine and getting the below error on console,
> > > > 
> > > > 
> > > > --------
> > > > Booting 'Fedora (3.6.1-1.fc17.x86_64)'
> > > > 
> > > > 
> > > > Loading Fedora (3.6.1-1.fc17.x86_64)
> > > > Loading initial ramdisk ...
> > > > [   0.000000] Cannot get hvm parameter 18: -22!
> > > 
> > > HVM parameter 18 is HVM_PARAM_CONSOLE_EVTCHN.
> > 
> > -22 is EINVAL, that Xen would return only if:
> > 
> > - the requested parameter is out of range
> > this is not the case, 18 < 30
> 
> The hypervisor here is 3.4.3 where the largest hvm param is:
> $ grep define.HVM_PARAM xen-3.4-testing.hg/xen/include/public/hvm/params.h | sort -k3 -n | tail -n 3
> #define HVM_PARAM_ACPI_S_STATE 14
> #define HVM_PARAM_VM86_TSS     15
> #define HVM_PARAM_VPT_ALIGN    16

OK, we know that the console is not working because it is not provided
by the hypervisor.
However that shouldn't prevent the domain from booting, the emulated
serial should work fine.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 16:32:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 16:32:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOt0d-0004ks-3S; Thu, 18 Oct 2012 16:31:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOt0b-0004kg-Sz
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 16:31:46 +0000
Received: from [85.158.139.83:33938] by server-5.bemta-5.messagelabs.com id
	E1/3B-09732-1FE20805; Thu, 18 Oct 2012 16:31:45 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1350577903!29875546!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODMzMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23522 invoked from network); 18 Oct 2012 16:31:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 16:31:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,608,1344211200"; d="scan'208";a="211748677"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 16:31:42 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Thu, 18 Oct 2012
	12:31:42 -0400
Message-ID: <50802EEC.6060102@citrix.com>
Date: Thu, 18 Oct 2012 17:31:40 +0100
From: David Vrabel 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk 
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>	<507ED6C0.4020503@zytor.com>	<20121017161036.GA10691@phenom.dumpdata.com>	<507EE1C3.7070300@zytor.com>
	<20121017165452.GA22740@phenom.dumpdata.com>
In-Reply-To: <20121017165452.GA22740@phenom.dumpdata.com>
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, "H. Peter Anvin" ,
	lenb@kernel.org
Subject: Re: [Xen-devel] Is: axe read_tscp pvops call. Was: Re: [RFC] ACPI
 S3 and Xen (suprisingly small\!).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/10/12 17:54, Konrad Rzeszutek Wilk wrote:
> On Wed, Oct 17, 2012 at 09:50:11AM -0700, H. Peter Anvin wrote:
>> On 10/17/2012 09:10 AM, Konrad Rzeszutek Wilk wrote:
>>> On Wed, Oct 17, 2012 at 09:03:12AM -0700, H. Peter Anvin wrote:
>>>> On 10/17/2012 06:49 AM, Konrad Rzeszutek Wilk wrote:
>>>>>
>>>>> Note: These are the other patches that went in 3.7-rc1:
>>>>> xen/bootup: allow {read|write}_cr8 pvops call [https://lkml.org/lkml/2012/10/10/339]
>>>>> xen/bootup: allow read_tscp call for Xen PV guests. [https://lkml.org/lkml/2012/10/10/340]
>>>>>
>>>>
>>>> So WTF do we have a read_tscp PV call?  Again, if there isn't a user
>>>> we should just axe it...
>>>
>>> Let me spin off a patch to see if that can be done.
>>>
>>
>> Could you do an audit for other pvops calls that have no users?  If
>> the *only* user is lguest, we should talk about it, too...
> 
> I can do that - but I don't want to be hasty here. There is a bit of
> danger here - for example the read_pmc (or read_tsc) is not in use right
> now. But it might be when one starts looking at making perf be able to
> analyze the hypervisor (hand-waving the implementation details). So while
> removing read_pmc now sounds good, it might be needed in the future.

I don't see any reason why would ever need a PV-specific implementation
of either read_pmc or read_tsc.  And I certainly agree with hpa that
leaving them around 'just in case' isn't useful.

As for 'perf', since Xen already provides a virtual PMU for HVM guests
It's not clear why we would spend the effort to implement another
mechanism for PV guests (instead of using the virtual PMU from a PVH guest).

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 16:32:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 16:32:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOt0d-0004ks-3S; Thu, 18 Oct 2012 16:31:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOt0b-0004kg-Sz
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 16:31:46 +0000
Received: from [85.158.139.83:33938] by server-5.bemta-5.messagelabs.com id
	E1/3B-09732-1FE20805; Thu, 18 Oct 2012 16:31:45 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1350577903!29875546!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODMzMjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23522 invoked from network); 18 Oct 2012 16:31:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 16:31:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,608,1344211200"; d="scan'208";a="211748677"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 16:31:42 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Thu, 18 Oct 2012
	12:31:42 -0400
Message-ID: <50802EEC.6060102@citrix.com>
Date: Thu, 18 Oct 2012 17:31:40 +0100
From: David Vrabel 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk 
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>	<507ED6C0.4020503@zytor.com>	<20121017161036.GA10691@phenom.dumpdata.com>	<507EE1C3.7070300@zytor.com>
	<20121017165452.GA22740@phenom.dumpdata.com>
In-Reply-To: <20121017165452.GA22740@phenom.dumpdata.com>
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, "H. Peter Anvin" ,
	lenb@kernel.org
Subject: Re: [Xen-devel] Is: axe read_tscp pvops call. Was: Re: [RFC] ACPI
 S3 and Xen (suprisingly small\!).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/10/12 17:54, Konrad Rzeszutek Wilk wrote:
> On Wed, Oct 17, 2012 at 09:50:11AM -0700, H. Peter Anvin wrote:
>> On 10/17/2012 09:10 AM, Konrad Rzeszutek Wilk wrote:
>>> On Wed, Oct 17, 2012 at 09:03:12AM -0700, H. Peter Anvin wrote:
>>>> On 10/17/2012 06:49 AM, Konrad Rzeszutek Wilk wrote:
>>>>>
>>>>> Note: These are the other patches that went in 3.7-rc1:
>>>>> xen/bootup: allow {read|write}_cr8 pvops call [https://lkml.org/lkml/2012/10/10/339]
>>>>> xen/bootup: allow read_tscp call for Xen PV guests. [https://lkml.org/lkml/2012/10/10/340]
>>>>>
>>>>
>>>> So WTF do we have a read_tscp PV call?  Again, if there isn't a user
>>>> we should just axe it...
>>>
>>> Let me spin off a patch to see if that can be done.
>>>
>>
>> Could you do an audit for other pvops calls that have no users?  If
>> the *only* user is lguest, we should talk about it, too...
> 
> I can do that - but I don't want to be hasty here. There is a bit of
> danger here - for example the read_pmc (or read_tsc) is not in use right
> now. But it might be when one starts looking at making perf be able to
> analyze the hypervisor (hand-waving the implementation details). So while
> removing read_pmc now sounds good, it might be needed in the future.

I don't see any reason why would ever need a PV-specific implementation
of either read_pmc or read_tsc.  And I certainly agree with hpa that
leaving them around 'just in case' isn't useful.

As for 'perf', since Xen already provides a virtual PMU for HVM guests
It's not clear why we would spend the effort to implement another
mechanism for PV guests (instead of using the virtual PMU from a PVH guest).

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 16:38:12 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 16:38:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOt6U-00051b-Tl; Thu, 18 Oct 2012 16:37:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOt6T-00051W-Lh
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 16:37:49 +0000
Received: from [85.158.143.35:25485] by server-1.bemta-4.messagelabs.com id
	62/B4-19134-D5030805; Thu, 18 Oct 2012 16:37:49 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1350578266!11368940!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30815 invoked from network); 18 Oct 2012 16:37:48 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Oct 2012 16:37:48 -0000
Received: from tazenda.hos.anvin.org (c-67-188-81-177.hsd1.ca.comcast.net
	[67.188.81.177]) (authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id q9IGbhJ9010252
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256
	verify=FAIL); Thu, 18 Oct 2012 09:37:44 -0700
Message-ID: <50803057.5000307@zytor.com>
Date: Thu, 18 Oct 2012 09:37:43 -0700
From: "H. Peter Anvin" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121009 Thunderbird/16.0
MIME-Version: 1.0
To: Dan Magenheimer 
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	<507ED6C0.4020503@zytor.com>
	<20121017161036.GA10691@phenom.dumpdata.com>
	<507EE1C3.7070300@zytor.com>
	<20121017165452.GA22740@phenom.dumpdata.com>
	<507EEC53.1010309@zytor.com>
	<84b3cbf9-7c84-4d7e-a2d7-46b0d1cc5975@default>
	<50802030.8070107@zytor.com>
	
In-Reply-To: 
Cc: xen-devel@lists.xensource.com, Konrad Wilk ,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] Is: axe read_tscp pvops call. Was: Re: [RFC] ACPI
 S3 and Xen (suprisingly small\!).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/18/2012 08:56 AM, Dan Magenheimer wrote:
>
>> Do you notice that the document you just claimed doesn't even exist at
>> this point, never mind being somehow enforced?  In other word, there is
>> ABSOLUTELY NO WAY a mainline kernel developer can have any idea what
>> amount of violence Xen does to the architecture that it is parasiting on.
>
> Of course I know it doesn't exist.  I probably should have
> noted that in my email.  But it should exist because else
> subtle issues like this will get lost in the mist of time.
> And I have no clue how to enforce it (though some BUILD_BUG_ON
> might help).
>

Do you know for how long I have been yelling at various Xen people for 
*not documenting their architecture*?  There are plenty of 
paravirtualized architectures out there which are perfectly well 
documented and supportable, but Xen has resisted doing that for years, 
and all we ever get are vague future promises.

	-hpa


-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 16:38:12 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 16:38:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOt6U-00051b-Tl; Thu, 18 Oct 2012 16:37:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOt6T-00051W-Lh
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 16:37:49 +0000
Received: from [85.158.143.35:25485] by server-1.bemta-4.messagelabs.com id
	62/B4-19134-D5030805; Thu, 18 Oct 2012 16:37:49 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1350578266!11368940!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30815 invoked from network); 18 Oct 2012 16:37:48 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Oct 2012 16:37:48 -0000
Received: from tazenda.hos.anvin.org (c-67-188-81-177.hsd1.ca.comcast.net
	[67.188.81.177]) (authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id q9IGbhJ9010252
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256
	verify=FAIL); Thu, 18 Oct 2012 09:37:44 -0700
Message-ID: <50803057.5000307@zytor.com>
Date: Thu, 18 Oct 2012 09:37:43 -0700
From: "H. Peter Anvin" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121009 Thunderbird/16.0
MIME-Version: 1.0
To: Dan Magenheimer 
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	<507ED6C0.4020503@zytor.com>
	<20121017161036.GA10691@phenom.dumpdata.com>
	<507EE1C3.7070300@zytor.com>
	<20121017165452.GA22740@phenom.dumpdata.com>
	<507EEC53.1010309@zytor.com>
	<84b3cbf9-7c84-4d7e-a2d7-46b0d1cc5975@default>
	<50802030.8070107@zytor.com>
	
In-Reply-To: 
Cc: xen-devel@lists.xensource.com, Konrad Wilk ,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] Is: axe read_tscp pvops call. Was: Re: [RFC] ACPI
 S3 and Xen (suprisingly small\!).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/18/2012 08:56 AM, Dan Magenheimer wrote:
>
>> Do you notice that the document you just claimed doesn't even exist at
>> this point, never mind being somehow enforced?  In other word, there is
>> ABSOLUTELY NO WAY a mainline kernel developer can have any idea what
>> amount of violence Xen does to the architecture that it is parasiting on.
>
> Of course I know it doesn't exist.  I probably should have
> noted that in my email.  But it should exist because else
> subtle issues like this will get lost in the mist of time.
> And I have no clue how to enforce it (though some BUILD_BUG_ON
> might help).
>

Do you know for how long I have been yelling at various Xen people for 
*not documenting their architecture*?  There are plenty of 
paravirtualized architectures out there which are perfectly well 
documented and supportable, but Xen has resisted doing that for years, 
and all we ever get are vague future promises.

	-hpa


-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 16:42:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 16:42:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOtAe-00059C-JD; Thu, 18 Oct 2012 16:42:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOtAd-000595-Oz
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 16:42:07 +0000
Received: from [85.158.139.211:58613] by server-6.bemta-5.messagelabs.com id
	D5/10-32589-E5130805; Thu, 18 Oct 2012 16:42:06 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1350578526!18878392!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2150 invoked from network); 18 Oct 2012 16:42:06 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 16:42:06 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so5089620eek.32
	for ; Thu, 18 Oct 2012 09:42:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=VjJZyHO7yMI3N+On2iSjjhZhHpp4wMCGLsPm431riME=;
	b=YsT7JqtUojO2N9WEkaXIo5Qu9+zror67UI/kQ084QD63WlsXGZKoEUD1Xr89xZkHGA
	rqBMxE9ph/3E9Me8uZwNcsrzQMZVFhK3lmRawaEfGUVqdLoD3MX1vCs2q9OrUVB1Gz9m
	TyV4P2sn+PHVCBBBQL4ZfHvtzFAleQ1sUNO6i8schCPHjfKNwgUm1p/RPPHXE0qU9kdX
	hOlpjIlzj191aPiNLs3voX5E+PpTaK7X6s4TR3hsbJjTeF0pJDldfUTBMdyb7PMYz6qP
	7SA5Njclba2xOmTYCejduoaU0S/odso0M3zUc5xUKEykx2kNlGv/SuH4xQWuinmii4p1
	PVCA==
Received: by 10.14.173.195 with SMTP id v43mr13197235eel.39.1350578526194;
	Thu, 18 Oct 2012 09:42:06 -0700 (PDT)
Received: from [192.168.1.69] (host86-178-46-35.range86-178.btcentralplus.com.
	[86.178.46.35])
	by mx.google.com with ESMTPS id i41sm40652718eem.7.2012.10.18.09.42.03
	(version=SSLv3 cipher=OTHER); Thu, 18 Oct 2012 09:42:05 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Thu, 18 Oct 2012 17:42:00 +0100
From: Keir Fraser 
To: Jan Beulich 
Message-ID: 
Thread-Topic: [Xen-devel] [PATCH 3/3] x86/HPET: cache MSI message last written
Thread-Index: Ac2tT36ACrPQ3CGQ2kKh5v++DW6VrQ==
In-Reply-To: <507FF88702000078000A24FE@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel 
Subject: Re: [Xen-devel] [PATCH 3/3] x86/HPET: cache MSI message last written
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 18/10/2012 11:39, "Jan Beulich"  wrote:

>>>> On 18.10.12 at 10:22, Keir Fraser  wrote:
>> On 16/10/2012 16:11, "Jan Beulich"  wrote:
>> 
>>> Rather than spending measurable amounts of time reading back the most
>>> recently written message, cache it in space previously unused, and thus
>>> accelerate the CPU's entering of the intended C-state.
>>> 
>>> hpet_msi_read() ends up being unused after this change, but rather than
>>> removing the function, it's being marked "unused" in order - that way
>>> it can easily get used again should a new need for it arise.
>> 
>> Please use __attribute_used__
> 
> That wouldn't be correct: The function _is_ unused (and there's
> no issue if it was used afaik), and the __used__ attribute ought
> to tell the compiler to keep the function around despite not
> having (visible to it) callers.

Perhaps our __attribute_used__ definition should change, then?

 -- Keir

> Jan
> 
>>> Signed-off-by: Jan Beulich 
>> 
>> Acked-by: Keir Fraser 
>> 
>>> --- a/xen/arch/x86/hpet.c
>>> +++ b/xen/arch/x86/hpet.c
>>> @@ -253,17 +253,19 @@ static void hpet_msi_mask(struct irq_des
>>>  
>>>  static void hpet_msi_write(struct hpet_event_channel *ch, struct msi_msg
>>> *msg)
>>>  {
>>> +    ch->msi.msg = *msg;
>>>      if ( iommu_intremap )
>>>          iommu_update_ire_from_msi(&ch->msi, msg);
>>>      hpet_write32(msg->data, HPET_Tn_ROUTE(ch->idx));
>>>      hpet_write32(msg->address_lo, HPET_Tn_ROUTE(ch->idx) + 4);
>>>  }
>>>  
>>> -static void hpet_msi_read(struct hpet_event_channel *ch, struct msi_msg
>> *msg)
>>> +static void __attribute__((__unused__))
>>> +hpet_msi_read(struct hpet_event_channel *ch, struct msi_msg *msg)
>>>  {
>>>      msg->data = hpet_read32(HPET_Tn_ROUTE(ch->idx));
>>>      msg->address_lo = hpet_read32(HPET_Tn_ROUTE(ch->idx) + 4);
>>> -    msg->address_hi = 0;
>>> +    msg->address_hi = MSI_ADDR_BASE_HI;
>>>      if ( iommu_intremap )
>>>          iommu_read_msi_from_ire(&ch->msi, msg);
>>>  }
>>> @@ -285,20 +287,19 @@ static void hpet_msi_ack(struct irq_desc
>>>  
>>>  static void hpet_msi_set_affinity(struct irq_desc *desc, const cpumask_t
>>> *mask)
>>>  {
>>> -    struct msi_msg msg;
>>> -    unsigned int dest;
>>> +    struct hpet_event_channel *ch = desc->action->dev_id;
>>> +    struct msi_msg msg = ch->msi.msg;
>>>  
>>> -    dest = set_desc_affinity(desc, mask);
>>> -    if (dest == BAD_APICID)
>>> +    msg.dest32 = set_desc_affinity(desc, mask);
>>> +    if ( msg.dest32 == BAD_APICID )
>>>          return;
>>>  
>>> -    hpet_msi_read(desc->action->dev_id, &msg);
>>>      msg.data &= ~MSI_DATA_VECTOR_MASK;
>>>      msg.data |= MSI_DATA_VECTOR(desc->arch.vector);
>>>      msg.address_lo &= ~MSI_ADDR_DEST_ID_MASK;
>>> -    msg.address_lo |= MSI_ADDR_DEST_ID(dest);
>>> -    msg.dest32 = dest;
>>> -    hpet_msi_write(desc->action->dev_id, &msg);
>>> +    msg.address_lo |= MSI_ADDR_DEST_ID(msg.dest32);
>>> +    if ( msg.data != ch->msi.msg.data || msg.dest32 != ch->msi.msg.dest32 )
>>> +        hpet_msi_write(ch, &msg);
>>>  }
>>>  
>>>  /*
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xen.org/xen-devel
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 16:42:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 16:42:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOtAe-00059C-JD; Thu, 18 Oct 2012 16:42:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOtAd-000595-Oz
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 16:42:07 +0000
Received: from [85.158.139.211:58613] by server-6.bemta-5.messagelabs.com id
	D5/10-32589-E5130805; Thu, 18 Oct 2012 16:42:06 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1350578526!18878392!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2150 invoked from network); 18 Oct 2012 16:42:06 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 16:42:06 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so5089620eek.32
	for ; Thu, 18 Oct 2012 09:42:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=VjJZyHO7yMI3N+On2iSjjhZhHpp4wMCGLsPm431riME=;
	b=YsT7JqtUojO2N9WEkaXIo5Qu9+zror67UI/kQ084QD63WlsXGZKoEUD1Xr89xZkHGA
	rqBMxE9ph/3E9Me8uZwNcsrzQMZVFhK3lmRawaEfGUVqdLoD3MX1vCs2q9OrUVB1Gz9m
	TyV4P2sn+PHVCBBBQL4ZfHvtzFAleQ1sUNO6i8schCPHjfKNwgUm1p/RPPHXE0qU9kdX
	hOlpjIlzj191aPiNLs3voX5E+PpTaK7X6s4TR3hsbJjTeF0pJDldfUTBMdyb7PMYz6qP
	7SA5Njclba2xOmTYCejduoaU0S/odso0M3zUc5xUKEykx2kNlGv/SuH4xQWuinmii4p1
	PVCA==
Received: by 10.14.173.195 with SMTP id v43mr13197235eel.39.1350578526194;
	Thu, 18 Oct 2012 09:42:06 -0700 (PDT)
Received: from [192.168.1.69] (host86-178-46-35.range86-178.btcentralplus.com.
	[86.178.46.35])
	by mx.google.com with ESMTPS id i41sm40652718eem.7.2012.10.18.09.42.03
	(version=SSLv3 cipher=OTHER); Thu, 18 Oct 2012 09:42:05 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Thu, 18 Oct 2012 17:42:00 +0100
From: Keir Fraser 
To: Jan Beulich 
Message-ID: 
Thread-Topic: [Xen-devel] [PATCH 3/3] x86/HPET: cache MSI message last written
Thread-Index: Ac2tT36ACrPQ3CGQ2kKh5v++DW6VrQ==
In-Reply-To: <507FF88702000078000A24FE@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel 
Subject: Re: [Xen-devel] [PATCH 3/3] x86/HPET: cache MSI message last written
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 18/10/2012 11:39, "Jan Beulich"  wrote:

>>>> On 18.10.12 at 10:22, Keir Fraser  wrote:
>> On 16/10/2012 16:11, "Jan Beulich"  wrote:
>> 
>>> Rather than spending measurable amounts of time reading back the most
>>> recently written message, cache it in space previously unused, and thus
>>> accelerate the CPU's entering of the intended C-state.
>>> 
>>> hpet_msi_read() ends up being unused after this change, but rather than
>>> removing the function, it's being marked "unused" in order - that way
>>> it can easily get used again should a new need for it arise.
>> 
>> Please use __attribute_used__
> 
> That wouldn't be correct: The function _is_ unused (and there's
> no issue if it was used afaik), and the __used__ attribute ought
> to tell the compiler to keep the function around despite not
> having (visible to it) callers.

Perhaps our __attribute_used__ definition should change, then?

 -- Keir

> Jan
> 
>>> Signed-off-by: Jan Beulich 
>> 
>> Acked-by: Keir Fraser 
>> 
>>> --- a/xen/arch/x86/hpet.c
>>> +++ b/xen/arch/x86/hpet.c
>>> @@ -253,17 +253,19 @@ static void hpet_msi_mask(struct irq_des
>>>  
>>>  static void hpet_msi_write(struct hpet_event_channel *ch, struct msi_msg
>>> *msg)
>>>  {
>>> +    ch->msi.msg = *msg;
>>>      if ( iommu_intremap )
>>>          iommu_update_ire_from_msi(&ch->msi, msg);
>>>      hpet_write32(msg->data, HPET_Tn_ROUTE(ch->idx));
>>>      hpet_write32(msg->address_lo, HPET_Tn_ROUTE(ch->idx) + 4);
>>>  }
>>>  
>>> -static void hpet_msi_read(struct hpet_event_channel *ch, struct msi_msg
>> *msg)
>>> +static void __attribute__((__unused__))
>>> +hpet_msi_read(struct hpet_event_channel *ch, struct msi_msg *msg)
>>>  {
>>>      msg->data = hpet_read32(HPET_Tn_ROUTE(ch->idx));
>>>      msg->address_lo = hpet_read32(HPET_Tn_ROUTE(ch->idx) + 4);
>>> -    msg->address_hi = 0;
>>> +    msg->address_hi = MSI_ADDR_BASE_HI;
>>>      if ( iommu_intremap )
>>>          iommu_read_msi_from_ire(&ch->msi, msg);
>>>  }
>>> @@ -285,20 +287,19 @@ static void hpet_msi_ack(struct irq_desc
>>>  
>>>  static void hpet_msi_set_affinity(struct irq_desc *desc, const cpumask_t
>>> *mask)
>>>  {
>>> -    struct msi_msg msg;
>>> -    unsigned int dest;
>>> +    struct hpet_event_channel *ch = desc->action->dev_id;
>>> +    struct msi_msg msg = ch->msi.msg;
>>>  
>>> -    dest = set_desc_affinity(desc, mask);
>>> -    if (dest == BAD_APICID)
>>> +    msg.dest32 = set_desc_affinity(desc, mask);
>>> +    if ( msg.dest32 == BAD_APICID )
>>>          return;
>>>  
>>> -    hpet_msi_read(desc->action->dev_id, &msg);
>>>      msg.data &= ~MSI_DATA_VECTOR_MASK;
>>>      msg.data |= MSI_DATA_VECTOR(desc->arch.vector);
>>>      msg.address_lo &= ~MSI_ADDR_DEST_ID_MASK;
>>> -    msg.address_lo |= MSI_ADDR_DEST_ID(dest);
>>> -    msg.dest32 = dest;
>>> -    hpet_msi_write(desc->action->dev_id, &msg);
>>> +    msg.address_lo |= MSI_ADDR_DEST_ID(msg.dest32);
>>> +    if ( msg.data != ch->msi.msg.data || msg.dest32 != ch->msi.msg.dest32 )
>>> +        hpet_msi_write(ch, &msg);
>>>  }
>>>  
>>>  /*
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xen.org/xen-devel
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 16:43:50 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 16:43:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOtC5-0005Es-2E; Thu, 18 Oct 2012 16:43:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOtC3-0005Eh-Ue; Thu, 18 Oct 2012 16:43:36 +0000
Received: from [85.158.143.35:55871] by server-3.bemta-4.messagelabs.com id
	6D/10-03544-7B130805; Thu, 18 Oct 2012 16:43:35 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1350578614!14534524!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24147 invoked from network); 18 Oct 2012 16:43:34 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 16:43:34 -0000
Received: by mail-ee0-f43.google.com with SMTP id c13so5006382eek.30
	for ; Thu, 18 Oct 2012 09:43:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=hr6Ubfx4NFelFPQKp8tAjXj6ueew+dQG552GFJfYTzA=;
	b=R/j4uMkuxVqdi09M8pbm0Ut0USbHeM8So8fVXFdawCGXFrIMRXi7bMc/+6hL6q/tfv
	8YDcCDo/lcHjWSpxtQDwHu++Gu1wVrhKNYqVX2oQrkjxz/OvSa0A56ZVNjGmt4CeLz6c
	XTTuls3jZy8K0cRsjkfDe7hcaftUVQnUSKcqVASjjS2IjvwgJzqf/BWdzUHe5Csj1J6R
	xRZ+MZ6f3LCkF1MhEO7MB+nUF3Ta0tCylplOSRn37ROMu6OUMrHnt1meuT03U8YPNyOS
	Wx/WMZjfowaJA1CNiSefV9+GqjKcJC7PW8iv55YlbzDelEdptomQjOTqqLevQ9BBHSHC
	uHVw==
Received: by 10.14.179.1 with SMTP id g1mr32707937eem.14.1350578613982;
	Thu, 18 Oct 2012 09:43:33 -0700 (PDT)
Received: from [192.168.1.69] (host86-178-46-35.range86-178.btcentralplus.com.
	[86.178.46.35])
	by mx.google.com with ESMTPS id g5sm40652499eem.4.2012.10.18.09.43.31
	(version=SSLv3 cipher=OTHER); Thu, 18 Oct 2012 09:43:32 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Thu, 18 Oct 2012 17:43:26 +0100
From: Keir Fraser 
To: ,
	
Message-ID: 
Thread-Topic: [Xen-devel] [Xen-users]   Re: Xen 4 TSC problems
Thread-Index: AQHNrQPokzEo6fEyWkKWYKkQrivnaZe/EkkggAAzEug=
In-Reply-To: 
Mime-version: 1.0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, dan.magenheimer@oracle.com,
	mrsanna1@gmail.com, olivier.hanesse@gmail.com, JBeulich@suse.com,
	xen-users@lists.xensource.com, mark@campbell-lange.net
Subject: Re: [Xen-devel] [Xen-users]   Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We have no idea yet whether this workaround even does any good.

 -- Keir

On 18/10/2012 14:45, "Philippe.Simonet@swisscom.com"
 wrote:

> in the meantime, it would be cool to have a kernel boot parameter that could
> disable this wrapping'
> correction' ? like 
> 
>> -----Original Message-----
>> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
>> bounces@lists.xen.org] On Behalf Of Ian Campbell
>> Sent: Thursday, October 18, 2012 9:40 AM
>> To: Keir Fraser
>> Cc: Jeremy Fitzhardinge; xen-devel@lists.xensource.com; Dan
>> Magenheimer; Mauro; Olivier Hanesse; Jan Beulich; Xen Users; Mark Adams
>> Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
>> 
>> On Wed, 2012-10-17 at 17:15 +0100, Keir Fraser wrote:
>>> @@ -540,6 +541,14 @@ static void plt_overflow(void *unused)
>>>          plt_wrap = __read_platform_stime(plt_stamp64 + plt_mask + 1);
>>>          if ( ABS(plt_wrap - now) > ABS(plt_now - now) )
>>>              break;
>>> +        rdtscll(tsc);
>>> +        printk("XXX plt_overflow: plt_now=%"PRIx64" plt_wrap=%"PRIx64
>>> +               " now=%"PRIx64" old_stamp=%"PRIx64" new_stamp=%"PRIx64
>>> +               " plt_stamp64=%"PRIx64" plt_mask=%"PRIx64
>>> +               " tsc=%"PRIx64" tsc_stamp=%"PRIx64"\n",
>>> +               plt_now, plt_wrap, now, old_stamp, plt_stamp, plt_stamp64,
>>> +               plt_mask, tsc, this_cpu(cpu_time).local_tsc_stamp);
>>> +        break;
>> 
>> Is the break here, making the following update to plt_stamp64 dead code
>> deliberate?
>> 
>>>          plt_stamp64 += plt_mask + 1;
>>>      }
>>>      if ( i != 0 )
>> 
>> Ian.
>> 
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 16:43:50 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 16:43:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOtC5-0005Es-2E; Thu, 18 Oct 2012 16:43:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOtC3-0005Eh-Ue; Thu, 18 Oct 2012 16:43:36 +0000
Received: from [85.158.143.35:55871] by server-3.bemta-4.messagelabs.com id
	6D/10-03544-7B130805; Thu, 18 Oct 2012 16:43:35 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1350578614!14534524!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24147 invoked from network); 18 Oct 2012 16:43:34 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 16:43:34 -0000
Received: by mail-ee0-f43.google.com with SMTP id c13so5006382eek.30
	for ; Thu, 18 Oct 2012 09:43:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=hr6Ubfx4NFelFPQKp8tAjXj6ueew+dQG552GFJfYTzA=;
	b=R/j4uMkuxVqdi09M8pbm0Ut0USbHeM8So8fVXFdawCGXFrIMRXi7bMc/+6hL6q/tfv
	8YDcCDo/lcHjWSpxtQDwHu++Gu1wVrhKNYqVX2oQrkjxz/OvSa0A56ZVNjGmt4CeLz6c
	XTTuls3jZy8K0cRsjkfDe7hcaftUVQnUSKcqVASjjS2IjvwgJzqf/BWdzUHe5Csj1J6R
	xRZ+MZ6f3LCkF1MhEO7MB+nUF3Ta0tCylplOSRn37ROMu6OUMrHnt1meuT03U8YPNyOS
	Wx/WMZjfowaJA1CNiSefV9+GqjKcJC7PW8iv55YlbzDelEdptomQjOTqqLevQ9BBHSHC
	uHVw==
Received: by 10.14.179.1 with SMTP id g1mr32707937eem.14.1350578613982;
	Thu, 18 Oct 2012 09:43:33 -0700 (PDT)
Received: from [192.168.1.69] (host86-178-46-35.range86-178.btcentralplus.com.
	[86.178.46.35])
	by mx.google.com with ESMTPS id g5sm40652499eem.4.2012.10.18.09.43.31
	(version=SSLv3 cipher=OTHER); Thu, 18 Oct 2012 09:43:32 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Thu, 18 Oct 2012 17:43:26 +0100
From: Keir Fraser 
To: ,
	
Message-ID: 
Thread-Topic: [Xen-devel] [Xen-users]   Re: Xen 4 TSC problems
Thread-Index: AQHNrQPokzEo6fEyWkKWYKkQrivnaZe/EkkggAAzEug=
In-Reply-To: 
Mime-version: 1.0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, dan.magenheimer@oracle.com,
	mrsanna1@gmail.com, olivier.hanesse@gmail.com, JBeulich@suse.com,
	xen-users@lists.xensource.com, mark@campbell-lange.net
Subject: Re: [Xen-devel] [Xen-users]   Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We have no idea yet whether this workaround even does any good.

 -- Keir

On 18/10/2012 14:45, "Philippe.Simonet@swisscom.com"
 wrote:

> in the meantime, it would be cool to have a kernel boot parameter that could
> disable this wrapping'
> correction' ? like 
> 
>> -----Original Message-----
>> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
>> bounces@lists.xen.org] On Behalf Of Ian Campbell
>> Sent: Thursday, October 18, 2012 9:40 AM
>> To: Keir Fraser
>> Cc: Jeremy Fitzhardinge; xen-devel@lists.xensource.com; Dan
>> Magenheimer; Mauro; Olivier Hanesse; Jan Beulich; Xen Users; Mark Adams
>> Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
>> 
>> On Wed, 2012-10-17 at 17:15 +0100, Keir Fraser wrote:
>>> @@ -540,6 +541,14 @@ static void plt_overflow(void *unused)
>>>          plt_wrap = __read_platform_stime(plt_stamp64 + plt_mask + 1);
>>>          if ( ABS(plt_wrap - now) > ABS(plt_now - now) )
>>>              break;
>>> +        rdtscll(tsc);
>>> +        printk("XXX plt_overflow: plt_now=%"PRIx64" plt_wrap=%"PRIx64
>>> +               " now=%"PRIx64" old_stamp=%"PRIx64" new_stamp=%"PRIx64
>>> +               " plt_stamp64=%"PRIx64" plt_mask=%"PRIx64
>>> +               " tsc=%"PRIx64" tsc_stamp=%"PRIx64"\n",
>>> +               plt_now, plt_wrap, now, old_stamp, plt_stamp, plt_stamp64,
>>> +               plt_mask, tsc, this_cpu(cpu_time).local_tsc_stamp);
>>> +        break;
>> 
>> Is the break here, making the following update to plt_stamp64 dead code
>> deliberate?
>> 
>>>          plt_stamp64 += plt_mask + 1;
>>>      }
>>>      if ( i != 0 )
>> 
>> Ian.
>> 
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 16:45:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 16:45:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOtDF-0005Ko-MP; Thu, 18 Oct 2012 16:44:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOtDD-0005Kd-Uf
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 16:44:48 +0000
Received: from [193.109.254.147:24182] by server-5.bemta-14.messagelabs.com id
	5F/E1-18309-FF130805; Thu, 18 Oct 2012 16:44:47 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1350578686!11861094!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21241 invoked from network); 18 Oct 2012 16:44:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 16:44:46 -0000
X-IronPort-AV: E=Sophos;i="4.80,608,1344211200"; d="scan'208";a="15260778"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 16:44:46 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 18 Oct 2012 17:44:46 +0100
Date: Thu, 18 Oct 2012 17:44:22 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Borislav Petkov 
In-Reply-To: <20121018161659.GA20354@x1.osrc.amd.com>
Message-ID: 
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	<507ED6C0.4020503@zytor.com>
	<20121017161036.GA10691@phenom.dumpdata.com>
	<507EE1C3.7070300@zytor.com>
	<20121017165452.GA22740@phenom.dumpdata.com>
	<507EEC53.1010309@zytor.com>
	<84b3cbf9-7c84-4d7e-a2d7-46b0d1cc5975@default>
	<50802030.8070107@zytor.com>
	
	<20121018161659.GA20354@x1.osrc.amd.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Dan Magenheimer ,
	"xen-devel@lists.xensource.com" ,
	Konrad Wilk , "x86@kernel.org" ,
	"linux-kernel@vger.kernel.org" ,
	"linux-acpi@vger.kernel.org" ,
	"H. Peter Anvin" , "lenb@kernel.org" 
Subject: Re: [Xen-devel] Is: axe read_tscp pvops call. Was: Re: [RFC] ACPI
 S3 and Xen (suprisingly small\!).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 18 Oct 2012, Borislav Petkov wrote:
> On Thu, Oct 18, 2012 at 08:56:40AM -0700, Dan Magenheimer wrote:
> > I agree the whole idea of paravirtualization is a hack, but it is a
> > hack to workaround some poor architectural design decisions many years
> > ago by Intel processor designers who should have known better. Go yell
> > at them.
> >
> > Worse, the rdtscp instruction was a poor design decision by AMD
> > processor designers to hack around tsc skew problems. Go yell at them
> > too.
> >
> > And both Intel and AMD chose to perpetuate the problem with a
> > complicated VT/SVM implementation that will never perform as well as
> > native. At least they tried ;-)
> 
> Looks like xen people seem to know better so maybe they should design
> their own processor, add xen support for it and leave the linux kernel
> alone so that both camps can finally get on with their lives.

I know that it is obvious but it is worth stating it in clear letters:

these are Dan's personal opinions and by no means represent the position
of the Xen community as a whole on this topic.

I, for one, have no idea what he is talking about.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 16:45:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 16:45:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOtDF-0005Ko-MP; Thu, 18 Oct 2012 16:44:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOtDD-0005Kd-Uf
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 16:44:48 +0000
Received: from [193.109.254.147:24182] by server-5.bemta-14.messagelabs.com id
	5F/E1-18309-FF130805; Thu, 18 Oct 2012 16:44:47 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1350578686!11861094!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21241 invoked from network); 18 Oct 2012 16:44:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 16:44:46 -0000
X-IronPort-AV: E=Sophos;i="4.80,608,1344211200"; d="scan'208";a="15260778"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 16:44:46 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 18 Oct 2012 17:44:46 +0100
Date: Thu, 18 Oct 2012 17:44:22 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Borislav Petkov 
In-Reply-To: <20121018161659.GA20354@x1.osrc.amd.com>
Message-ID: 
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	<507ED6C0.4020503@zytor.com>
	<20121017161036.GA10691@phenom.dumpdata.com>
	<507EE1C3.7070300@zytor.com>
	<20121017165452.GA22740@phenom.dumpdata.com>
	<507EEC53.1010309@zytor.com>
	<84b3cbf9-7c84-4d7e-a2d7-46b0d1cc5975@default>
	<50802030.8070107@zytor.com>
	
	<20121018161659.GA20354@x1.osrc.amd.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Dan Magenheimer ,
	"xen-devel@lists.xensource.com" ,
	Konrad Wilk , "x86@kernel.org" ,
	"linux-kernel@vger.kernel.org" ,
	"linux-acpi@vger.kernel.org" ,
	"H. Peter Anvin" , "lenb@kernel.org" 
Subject: Re: [Xen-devel] Is: axe read_tscp pvops call. Was: Re: [RFC] ACPI
 S3 and Xen (suprisingly small\!).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 18 Oct 2012, Borislav Petkov wrote:
> On Thu, Oct 18, 2012 at 08:56:40AM -0700, Dan Magenheimer wrote:
> > I agree the whole idea of paravirtualization is a hack, but it is a
> > hack to workaround some poor architectural design decisions many years
> > ago by Intel processor designers who should have known better. Go yell
> > at them.
> >
> > Worse, the rdtscp instruction was a poor design decision by AMD
> > processor designers to hack around tsc skew problems. Go yell at them
> > too.
> >
> > And both Intel and AMD chose to perpetuate the problem with a
> > complicated VT/SVM implementation that will never perform as well as
> > native. At least they tried ;-)
> 
> Looks like xen people seem to know better so maybe they should design
> their own processor, add xen support for it and leave the linux kernel
> alone so that both camps can finally get on with their lives.

I know that it is obvious but it is worth stating it in clear letters:

these are Dan's personal opinions and by no means represent the position
of the Xen community as a whole on this topic.

I, for one, have no idea what he is talking about.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 17:05:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 17:05:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOtWj-0005f6-KB; Thu, 18 Oct 2012 17:04:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOtWh-0005f1-RS
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 17:04:56 +0000
Received: from [85.158.143.99:19379] by server-3.bemta-4.messagelabs.com id
	B8/51-03544-7B630805; Thu, 18 Oct 2012 17:04:55 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1350579892!28413434!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11753 invoked from network); 18 Oct 2012 17:04:54 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Oct 2012 17:04:54 -0000
Received: from tazenda.hos.anvin.org (c-67-188-81-177.hsd1.ca.comcast.net
	[67.188.81.177]) (authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id q9IH4R47024026
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256
	verify=FAIL); Thu, 18 Oct 2012 10:04:28 -0700
Message-ID: <5080369B.3080204@zytor.com>
Date: Thu, 18 Oct 2012 10:04:27 -0700
From: "H. Peter Anvin" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121009 Thunderbird/16.0
MIME-Version: 1.0
To: Stefano Stabellini 
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	<507ED6C0.4020503@zytor.com>
	<20121017161036.GA10691@phenom.dumpdata.com>
	<507EE1C3.7070300@zytor.com>
	<20121017165452.GA22740@phenom.dumpdata.com>
	<507EEC53.1010309@zytor.com>
	<84b3cbf9-7c84-4d7e-a2d7-46b0d1cc5975@default>
	<50802030.8070107@zytor.com>
	
	<20121018161659.GA20354@x1.osrc.amd.com>
	
In-Reply-To: 
Cc: Dan Magenheimer ,
	"xen-devel@lists.xensource.com" ,
	Konrad Wilk , "x86@kernel.org" ,
	"linux-kernel@vger.kernel.org" ,
	"linux-acpi@vger.kernel.org" ,
	Borislav Petkov , "lenb@kernel.org" 
Subject: Re: [Xen-devel] Is: axe read_tscp pvops call. Was: Re: [RFC] ACPI
 S3 and Xen (suprisingly small\!).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/18/2012 09:44 AM, Stefano Stabellini wrote:
>
> I know that it is obvious but it is worth stating it in clear letters:
>
> these are Dan's personal opinions and by no means represent the position
> of the Xen community as a whole on this topic.
>
> I, for one, have no idea what he is talking about.
>

He is referring to the non-self-virtualizability of the pre-VT-x x86 
architecture; search for "Popek and Goldberg Virtualization Criteria". 
However, his response is misguided, because the issue at hand isn't the 
paravirtualization itself but the lack of documentation.

Paravirtualization creates a new platform, and that platform needs to be 
documented as much as any hardware platform.  Once that documentation 
exists it is possible to make a reasoned judgement if that platform can 
be unified with an existing platform like native x86.

However, the Xen platform is not documented in any useful way at all, 
and having "fun" little bits like this coming out of nowhere is just 
plain unacceptable.

Either way, it doesn't change the starting point of this -- we don't 
keep around hooks that aren't even used.  End of story.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 17:05:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 17:05:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOtWj-0005f6-KB; Thu, 18 Oct 2012 17:04:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOtWh-0005f1-RS
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 17:04:56 +0000
Received: from [85.158.143.99:19379] by server-3.bemta-4.messagelabs.com id
	B8/51-03544-7B630805; Thu, 18 Oct 2012 17:04:55 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1350579892!28413434!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11753 invoked from network); 18 Oct 2012 17:04:54 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Oct 2012 17:04:54 -0000
Received: from tazenda.hos.anvin.org (c-67-188-81-177.hsd1.ca.comcast.net
	[67.188.81.177]) (authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id q9IH4R47024026
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256
	verify=FAIL); Thu, 18 Oct 2012 10:04:28 -0700
Message-ID: <5080369B.3080204@zytor.com>
Date: Thu, 18 Oct 2012 10:04:27 -0700
From: "H. Peter Anvin" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121009 Thunderbird/16.0
MIME-Version: 1.0
To: Stefano Stabellini 
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	<507ED6C0.4020503@zytor.com>
	<20121017161036.GA10691@phenom.dumpdata.com>
	<507EE1C3.7070300@zytor.com>
	<20121017165452.GA22740@phenom.dumpdata.com>
	<507EEC53.1010309@zytor.com>
	<84b3cbf9-7c84-4d7e-a2d7-46b0d1cc5975@default>
	<50802030.8070107@zytor.com>
	
	<20121018161659.GA20354@x1.osrc.amd.com>
	
In-Reply-To: 
Cc: Dan Magenheimer ,
	"xen-devel@lists.xensource.com" ,
	Konrad Wilk , "x86@kernel.org" ,
	"linux-kernel@vger.kernel.org" ,
	"linux-acpi@vger.kernel.org" ,
	Borislav Petkov , "lenb@kernel.org" 
Subject: Re: [Xen-devel] Is: axe read_tscp pvops call. Was: Re: [RFC] ACPI
 S3 and Xen (suprisingly small\!).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/18/2012 09:44 AM, Stefano Stabellini wrote:
>
> I know that it is obvious but it is worth stating it in clear letters:
>
> these are Dan's personal opinions and by no means represent the position
> of the Xen community as a whole on this topic.
>
> I, for one, have no idea what he is talking about.
>

He is referring to the non-self-virtualizability of the pre-VT-x x86 
architecture; search for "Popek and Goldberg Virtualization Criteria". 
However, his response is misguided, because the issue at hand isn't the 
paravirtualization itself but the lack of documentation.

Paravirtualization creates a new platform, and that platform needs to be 
documented as much as any hardware platform.  Once that documentation 
exists it is possible to make a reasoned judgement if that platform can 
be unified with an existing platform like native x86.

However, the Xen platform is not documented in any useful way at all, 
and having "fun" little bits like this coming out of nowhere is just 
plain unacceptable.

Either way, it doesn't change the starting point of this -- we don't 
keep around hooks that aren't even used.  End of story.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 17:13:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 17:13:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOteN-0005qZ-OP; Thu, 18 Oct 2012 17:12:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOteM-0005qU-I7
	for Xen-devel@lists.xensource.com; Thu, 18 Oct 2012 17:12:50 +0000
Received: from [85.158.139.211:20032] by server-16.bemta-5.messagelabs.com id
	49/0A-09196-19830805; Thu, 18 Oct 2012 17:12:49 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1350580367!22868887!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODEyNzI4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8785 invoked from network); 18 Oct 2012 17:12:48 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Oct 2012 17:12:48 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9IHCh1v006835
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 18 Oct 2012 17:12:44 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9IHChiu018951
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 18 Oct 2012 17:12:43 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9IHCgWg031920; Thu, 18 Oct 2012 12:12:42 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 18 Oct 2012 10:12:42 -0700
Date: Thu, 18 Oct 2012 10:12:40 -0700
From: Mukesh Rathor 
To: Stefano Stabellini 
Message-ID: <20121018101240.12bdbec3@mantra.us.oracle.com>
In-Reply-To: 
References: <20121017173119.4e12b222@mantra.us.oracle.com>
	
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V3 3/6]: PVH:  mmu related changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 18 Oct 2012 12:31:08 +0100
Stefano Stabellini  wrote:

> On Thu, 18 Oct 2012, Mukesh Rathor wrote:
> > PVH: This patch implements mmu changes for PVH. First the set/clear
> > mmio pte function makes a hypercall to update the p2m in xen with
> > 1:1 mapping. PVH uses mostly native mmu ops. Two local functions
> > are introduced to add to xen physmap for xen remap interface. xen
> > unmap interface is introduced so the privcmd pte entries can be
> > cleared in xen p2m table.
> > 
> > Signed-off-by: Mukesh Rathor 
> > ---
> >  arch/x86/xen/mmu.c    |  174
> > ++++++++++++++++++++++++++++++++++++++++++++++---
> > arch/x86/xen/mmu.h    |    2 + drivers/xen/privcmd.c |    5 +-
> >  include/xen/xen-ops.h |    5 +-
> >  4 files changed, 174 insertions(+), 12 deletions(-)
> > 
> > diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> > index 5a16824..5ed3b3e 100644
> > --- a/arch/x86/xen/mmu.c
> > +++ b/arch/x86/xen/mmu.c
> > @@ -73,6 +73,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #include "multicalls.h"
> >  #include "mmu.h"
> > @@ -331,6 +332,20 @@ static void xen_set_pte(pte_t *ptep, pte_t
> > pteval) __xen_set_pte(ptep, pteval);
> >  }
> >  
> > +void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn,
> > +			      int nr_mfns, int add_mapping)
> > +{
> > +	struct physdev_map_iomem iomem;
> > +
> > +	iomem.first_gfn = pfn;
> > +	iomem.first_mfn = mfn;
> > +	iomem.nr_mfns = nr_mfns;
> > +	iomem.add_mapping = add_mapping;
> > +
> > +	if (HYPERVISOR_physdev_op(PHYSDEVOP_pvh_map_iomem, &iomem))
> > +		BUG();
> > +}
> 
> You introduce this function here but it is unused. It is not clear
> from the patch description why you are introducing it.
> 
> 
> >  static void xen_set_pte_at(struct mm_struct *mm, unsigned long
> > addr, pte_t *ptep, pte_t pteval)
> >  {
> > @@ -1220,6 +1235,8 @@ static void __init xen_pagetable_init(void)
> >  #endif
> >  	paging_init();
> >  	xen_setup_shared_info();
> > +	if (xen_feature(XENFEAT_auto_translated_physmap))
> > +		return;
> >  #ifdef CONFIG_X86_64
> >  	if (!xen_feature(XENFEAT_auto_translated_physmap)) {
> >  		unsigned long new_mfn_list;
> > @@ -1527,6 +1544,10 @@ static void __init xen_set_pte_init(pte_t
> > *ptep, pte_t pte) static void pin_pagetable_pfn(unsigned cmd,
> > unsigned long pfn) {
> >  	struct mmuext_op op;
> > +
> > +	if (xen_feature(XENFEAT_writable_page_tables))
> > +		return;
> > +
> >  	op.cmd = cmd;
> >  	op.arg1.mfn = pfn_to_mfn(pfn);
> >  	if (HYPERVISOR_mmuext_op(&op, 1, NULL, DOMID_SELF))
> > @@ -1724,6 +1745,10 @@ static void set_page_prot(void *addr,
> > pgprot_t prot) unsigned long pfn = __pa(addr) >> PAGE_SHIFT;
> >  	pte_t pte = pfn_pte(pfn, prot);
> >  
> > +	/* recall for PVH, page tables are native. */
> > +	if (xen_feature(XENFEAT_auto_translated_physmap))
> > +		return;
> > +
> >  	if (HYPERVISOR_update_va_mapping((unsigned long)addr, pte,
> > 0)) BUG();
> >  }
> > @@ -1801,6 +1826,9 @@ static void convert_pfn_mfn(void *v)
> >  	pte_t *pte = v;
> >  	int i;
> >  
> > +	if (xen_feature(XENFEAT_auto_translated_physmap))
> > +		return;
> > +
> >  	/* All levels are converted the same way, so just treat
> > them as ptes. */
> >  	for (i = 0; i < PTRS_PER_PTE; i++)
> > @@ -1820,6 +1848,7 @@ static void __init check_pt_base(unsigned
> > long *pt_base, unsigned long *pt_end, (*pt_end)--;
> >  	}
> >  }
> > +
> >  /*
> >   * Set up the initial kernel pagetable.
> >   *
> > @@ -1830,6 +1859,7 @@ static void __init check_pt_base(unsigned
> > long *pt_base, unsigned long *pt_end,
> >   * but that's enough to get __va working.  We need to fill in the
> > rest
> >   * of the physical mapping once some sort of allocator has been set
> >   * up.
> > + * NOTE: for PVH, the page tables are native.
> >   */
> >  void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long
> > max_pfn) {
> > @@ -1907,10 +1937,13 @@ void __init
> > xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn)
> >  	 * structure to attach it to, so make sure we just set
> > kernel
> >  	 * pgd.
> >  	 */
> > -	xen_mc_batch();
> > -	__xen_write_cr3(true, __pa(init_level4_pgt));
> > -	xen_mc_issue(PARAVIRT_LAZY_CPU);
> > -
> > +	if (xen_feature(XENFEAT_writable_page_tables)) {
> > +		native_write_cr3(__pa(init_level4_pgt));
> > +	} else {
> > +		xen_mc_batch();
> > +		__xen_write_cr3(true, __pa(init_level4_pgt));
> > +		xen_mc_issue(PARAVIRT_LAZY_CPU);
> > +	}
> >  	/* We can't that easily rip out L3 and L2, as the Xen
> > pagetables are
> >  	 * set out this way: [L4], [L1], [L2], [L3], [L1],
> > [L1] ...  for
> >  	 * the initial domain. For guests using the toolstack,
> > they are in: @@ -2177,8 +2210,20 @@ static const struct pv_mmu_ops
> > xen_mmu_ops __initconst = { 
> >  void __init xen_init_mmu_ops(void)
> >  {
> > -	x86_init.mapping.pagetable_reserve =
> > xen_mapping_pagetable_reserve; x86_init.paging.pagetable_init =
> > xen_pagetable_init; +
> > +	if (xen_feature(XENFEAT_auto_translated_physmap)) {
> > +		pv_mmu_ops.flush_tlb_others = xen_flush_tlb_others;
> > +#if 0
> > +		/* For PCI devices to map iomem. */
> > +		if (xen_initial_domain()) {
> > +			pv_mmu_ops.set_pte = native_set_pte;
> > +			pv_mmu_ops.set_pte_at = native_set_pte_at;
> > +		}
> > +#endif
> 
> just remove the commented out code

Rats, this got sneaked in! I meant to remove it. I was testing it out
without the code. That if statement has been changing constantly to the
point where it became just native, and could be removed. 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 17:13:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 17:13:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOteN-0005qZ-OP; Thu, 18 Oct 2012 17:12:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOteM-0005qU-I7
	for Xen-devel@lists.xensource.com; Thu, 18 Oct 2012 17:12:50 +0000
Received: from [85.158.139.211:20032] by server-16.bemta-5.messagelabs.com id
	49/0A-09196-19830805; Thu, 18 Oct 2012 17:12:49 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1350580367!22868887!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODEyNzI4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8785 invoked from network); 18 Oct 2012 17:12:48 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Oct 2012 17:12:48 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9IHCh1v006835
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 18 Oct 2012 17:12:44 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9IHChiu018951
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 18 Oct 2012 17:12:43 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9IHCgWg031920; Thu, 18 Oct 2012 12:12:42 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 18 Oct 2012 10:12:42 -0700
Date: Thu, 18 Oct 2012 10:12:40 -0700
From: Mukesh Rathor 
To: Stefano Stabellini 
Message-ID: <20121018101240.12bdbec3@mantra.us.oracle.com>
In-Reply-To: 
References: <20121017173119.4e12b222@mantra.us.oracle.com>
	
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V3 3/6]: PVH:  mmu related changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 18 Oct 2012 12:31:08 +0100
Stefano Stabellini  wrote:

> On Thu, 18 Oct 2012, Mukesh Rathor wrote:
> > PVH: This patch implements mmu changes for PVH. First the set/clear
> > mmio pte function makes a hypercall to update the p2m in xen with
> > 1:1 mapping. PVH uses mostly native mmu ops. Two local functions
> > are introduced to add to xen physmap for xen remap interface. xen
> > unmap interface is introduced so the privcmd pte entries can be
> > cleared in xen p2m table.
> > 
> > Signed-off-by: Mukesh Rathor 
> > ---
> >  arch/x86/xen/mmu.c    |  174
> > ++++++++++++++++++++++++++++++++++++++++++++++---
> > arch/x86/xen/mmu.h    |    2 + drivers/xen/privcmd.c |    5 +-
> >  include/xen/xen-ops.h |    5 +-
> >  4 files changed, 174 insertions(+), 12 deletions(-)
> > 
> > diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> > index 5a16824..5ed3b3e 100644
> > --- a/arch/x86/xen/mmu.c
> > +++ b/arch/x86/xen/mmu.c
> > @@ -73,6 +73,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #include "multicalls.h"
> >  #include "mmu.h"
> > @@ -331,6 +332,20 @@ static void xen_set_pte(pte_t *ptep, pte_t
> > pteval) __xen_set_pte(ptep, pteval);
> >  }
> >  
> > +void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn,
> > +			      int nr_mfns, int add_mapping)
> > +{
> > +	struct physdev_map_iomem iomem;
> > +
> > +	iomem.first_gfn = pfn;
> > +	iomem.first_mfn = mfn;
> > +	iomem.nr_mfns = nr_mfns;
> > +	iomem.add_mapping = add_mapping;
> > +
> > +	if (HYPERVISOR_physdev_op(PHYSDEVOP_pvh_map_iomem, &iomem))
> > +		BUG();
> > +}
> 
> You introduce this function here but it is unused. It is not clear
> from the patch description why you are introducing it.
> 
> 
> >  static void xen_set_pte_at(struct mm_struct *mm, unsigned long
> > addr, pte_t *ptep, pte_t pteval)
> >  {
> > @@ -1220,6 +1235,8 @@ static void __init xen_pagetable_init(void)
> >  #endif
> >  	paging_init();
> >  	xen_setup_shared_info();
> > +	if (xen_feature(XENFEAT_auto_translated_physmap))
> > +		return;
> >  #ifdef CONFIG_X86_64
> >  	if (!xen_feature(XENFEAT_auto_translated_physmap)) {
> >  		unsigned long new_mfn_list;
> > @@ -1527,6 +1544,10 @@ static void __init xen_set_pte_init(pte_t
> > *ptep, pte_t pte) static void pin_pagetable_pfn(unsigned cmd,
> > unsigned long pfn) {
> >  	struct mmuext_op op;
> > +
> > +	if (xen_feature(XENFEAT_writable_page_tables))
> > +		return;
> > +
> >  	op.cmd = cmd;
> >  	op.arg1.mfn = pfn_to_mfn(pfn);
> >  	if (HYPERVISOR_mmuext_op(&op, 1, NULL, DOMID_SELF))
> > @@ -1724,6 +1745,10 @@ static void set_page_prot(void *addr,
> > pgprot_t prot) unsigned long pfn = __pa(addr) >> PAGE_SHIFT;
> >  	pte_t pte = pfn_pte(pfn, prot);
> >  
> > +	/* recall for PVH, page tables are native. */
> > +	if (xen_feature(XENFEAT_auto_translated_physmap))
> > +		return;
> > +
> >  	if (HYPERVISOR_update_va_mapping((unsigned long)addr, pte,
> > 0)) BUG();
> >  }
> > @@ -1801,6 +1826,9 @@ static void convert_pfn_mfn(void *v)
> >  	pte_t *pte = v;
> >  	int i;
> >  
> > +	if (xen_feature(XENFEAT_auto_translated_physmap))
> > +		return;
> > +
> >  	/* All levels are converted the same way, so just treat
> > them as ptes. */
> >  	for (i = 0; i < PTRS_PER_PTE; i++)
> > @@ -1820,6 +1848,7 @@ static void __init check_pt_base(unsigned
> > long *pt_base, unsigned long *pt_end, (*pt_end)--;
> >  	}
> >  }
> > +
> >  /*
> >   * Set up the initial kernel pagetable.
> >   *
> > @@ -1830,6 +1859,7 @@ static void __init check_pt_base(unsigned
> > long *pt_base, unsigned long *pt_end,
> >   * but that's enough to get __va working.  We need to fill in the
> > rest
> >   * of the physical mapping once some sort of allocator has been set
> >   * up.
> > + * NOTE: for PVH, the page tables are native.
> >   */
> >  void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long
> > max_pfn) {
> > @@ -1907,10 +1937,13 @@ void __init
> > xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn)
> >  	 * structure to attach it to, so make sure we just set
> > kernel
> >  	 * pgd.
> >  	 */
> > -	xen_mc_batch();
> > -	__xen_write_cr3(true, __pa(init_level4_pgt));
> > -	xen_mc_issue(PARAVIRT_LAZY_CPU);
> > -
> > +	if (xen_feature(XENFEAT_writable_page_tables)) {
> > +		native_write_cr3(__pa(init_level4_pgt));
> > +	} else {
> > +		xen_mc_batch();
> > +		__xen_write_cr3(true, __pa(init_level4_pgt));
> > +		xen_mc_issue(PARAVIRT_LAZY_CPU);
> > +	}
> >  	/* We can't that easily rip out L3 and L2, as the Xen
> > pagetables are
> >  	 * set out this way: [L4], [L1], [L2], [L3], [L1],
> > [L1] ...  for
> >  	 * the initial domain. For guests using the toolstack,
> > they are in: @@ -2177,8 +2210,20 @@ static const struct pv_mmu_ops
> > xen_mmu_ops __initconst = { 
> >  void __init xen_init_mmu_ops(void)
> >  {
> > -	x86_init.mapping.pagetable_reserve =
> > xen_mapping_pagetable_reserve; x86_init.paging.pagetable_init =
> > xen_pagetable_init; +
> > +	if (xen_feature(XENFEAT_auto_translated_physmap)) {
> > +		pv_mmu_ops.flush_tlb_others = xen_flush_tlb_others;
> > +#if 0
> > +		/* For PCI devices to map iomem. */
> > +		if (xen_initial_domain()) {
> > +			pv_mmu_ops.set_pte = native_set_pte;
> > +			pv_mmu_ops.set_pte_at = native_set_pte_at;
> > +		}
> > +#endif
> 
> just remove the commented out code

Rats, this got sneaked in! I meant to remove it. I was testing it out
without the code. That if statement has been changing constantly to the
point where it became just native, and could be removed. 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 17:29:45 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 17:29:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOtuN-00068y-Ux; Thu, 18 Oct 2012 17:29:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOtuM-00068p-VC
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 17:29:23 +0000
Received: from [85.158.137.99:56182] by server-4.bemta-3.messagelabs.com id
	E9/3B-01405-27C30805; Thu, 18 Oct 2012 17:29:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1350581361!22169127!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1890 invoked from network); 18 Oct 2012 17:29:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 17:29:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,608,1344211200"; d="scan'208";a="15261656"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 17:29:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 18 Oct 2012 18:29:21 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TOtuK-0000qn-VA; Thu, 18 Oct 2012 17:29:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TOtuK-0000xf-Q5;
	Thu, 18 Oct 2012 18:29:20 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20608.15472.714307.754027@mariner.uk.xensource.com>
Date: Thu, 18 Oct 2012 18:29:20 +0100
To: 
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Campbell 
Subject: [Xen-devel] Xen.org automatic Xen test system, de-tentacled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I have been working on disentangling the automatic test system
("osstest" on xenbits) enough that it can be run without all of its
supporting infrastructure.

I think I have now succeeded.  Well, I have a branch which the brave
might like to try.  When we have ironed out the configuration bugs and
so forth I will try it on the live production system and try to fix
the breakages I have no doubt introduced there.

If you would like to have a go:
 - You will need local DHCP and TFTP servers, ideally on the
   same machine
 - You will probably need a dedicated test box.  The test system
   likes to reinstall although it is now possible to avoid this
 - git clone git://xenbits.xen.org/osstest.git
 - cd osstest
 - git checkout standalone
 - less README

And follow the instructions.  The README is also here:
 http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=standalone

The instructions are still sketchy and I'm sure there are many hurdles
and wrinkles.  So as I say this is for the brave only.  But if one or
two people (Ian C has expressed an interest) would like to try it that
would be helpful.

The ultimate intent is to make it much easier for other people to
contribute test cases, and also to make it easier to integrate our
test cases into some other continuous integration system.

I have tested, more or less recently, installing a host, running a
complete job (including a build and a test job).

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 17:29:45 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 17:29:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOtuN-00068y-Ux; Thu, 18 Oct 2012 17:29:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOtuM-00068p-VC
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 17:29:23 +0000
Received: from [85.158.137.99:56182] by server-4.bemta-3.messagelabs.com id
	E9/3B-01405-27C30805; Thu, 18 Oct 2012 17:29:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1350581361!22169127!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1890 invoked from network); 18 Oct 2012 17:29:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 17:29:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,608,1344211200"; d="scan'208";a="15261656"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 17:29:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 18 Oct 2012 18:29:21 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TOtuK-0000qn-VA; Thu, 18 Oct 2012 17:29:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TOtuK-0000xf-Q5;
	Thu, 18 Oct 2012 18:29:20 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20608.15472.714307.754027@mariner.uk.xensource.com>
Date: Thu, 18 Oct 2012 18:29:20 +0100
To: 
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Campbell 
Subject: [Xen-devel] Xen.org automatic Xen test system, de-tentacled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I have been working on disentangling the automatic test system
("osstest" on xenbits) enough that it can be run without all of its
supporting infrastructure.

I think I have now succeeded.  Well, I have a branch which the brave
might like to try.  When we have ironed out the configuration bugs and
so forth I will try it on the live production system and try to fix
the breakages I have no doubt introduced there.

If you would like to have a go:
 - You will need local DHCP and TFTP servers, ideally on the
   same machine
 - You will probably need a dedicated test box.  The test system
   likes to reinstall although it is now possible to avoid this
 - git clone git://xenbits.xen.org/osstest.git
 - cd osstest
 - git checkout standalone
 - less README

And follow the instructions.  The README is also here:
 http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=standalone

The instructions are still sketchy and I'm sure there are many hurdles
and wrinkles.  So as I say this is for the brave only.  But if one or
two people (Ian C has expressed an interest) would like to try it that
would be helpful.

The ultimate intent is to make it much easier for other people to
contribute test cases, and also to make it easier to integrate our
test cases into some other continuous integration system.

I have tested, more or less recently, installing a host, running a
complete job (including a build and a test job).

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 17:42:47 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 17:42:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOu72-0006w0-Dg; Thu, 18 Oct 2012 17:42:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOu71-0006vv-Fa
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 17:42:27 +0000
Received: from [85.158.143.35:30141] by server-3.bemta-4.messagelabs.com id
	F2/B9-03544-28F30805; Thu, 18 Oct 2012 17:42:26 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1350582137!12057047!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24876 invoked from network); 18 Oct 2012 17:42:18 -0000
Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com)
	(209.85.212.43)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 17:42:18 -0000
Received: by mail-vb0-f43.google.com with SMTP id fq11so11273767vbb.30
	for ;
	Thu, 18 Oct 2012 10:42:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=daIL0e5rFu3VLDX92HebGv76qy3NUxVFH9FRfaqIjYk=;
	b=A2SYfNDHoPBPBMn/r+jET7GM3aGtIn+kFkc8wzHKr4thNWZhFwdGvSbcwqNQui4glC
	bPTJiUO/9Ji+iAAXIMsIRTo7UbM9/7Y/Wi5voRsMq8qgmw9oo+IQl8aAQOZ8xi7hsL/k
	WxyrHGhITYEhalak1f7obgUNEKfi3BqC4Ro5xaDqAxW2Qv3mKiugW26QM3BwZbyi7oLs
	x1OO7lcnGLnZNjXjh7BQAWIPOnfGkA8gkb+zsGqXdH6KtJhw6pXy4hZMioFXiYvNNed7
	sfu2pZ7GSYuXWLdvRxdR/Yng8btC14/ERZiZ6fdfiOIVJ2T5rsb97yL5alv0oo9isPeW
	csXA==
Received: by 10.58.180.134 with SMTP id do6mr17190463vec.13.1350582136787;
	Thu, 18 Oct 2012 10:42:16 -0700 (PDT)
Received: from localhost.localdomain (mba2436d0.tmodns.net. [208.54.36.186])
	by mx.google.com with ESMTPS id v9sm4035650ves.8.2012.10.18.10.42.11
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 18 Oct 2012 10:42:16 -0700 (PDT)
Date: Thu, 18 Oct 2012 13:42:03 -0400
From: Konrad Rzeszutek Wilk 
To: David Vrabel 
Message-ID: <20121018174200.GA20508@localhost.localdomain>
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	<507ED6C0.4020503@zytor.com>
	<20121017161036.GA10691@phenom.dumpdata.com>
	<507EE1C3.7070300@zytor.com>
	<20121017165452.GA22740@phenom.dumpdata.com>
	<50802EEC.6060102@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50802EEC.6060102@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk , x86@kernel.org,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	"H. Peter Anvin" , lenb@kernel.org
Subject: Re: [Xen-devel] Is: axe read_tscp pvops call. Was: Re: [RFC] ACPI
 S3 and Xen (suprisingly small\!).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> As for 'perf', since Xen already provides a virtual PMU for HVM guests
> It's not clear why we would spend the effort to implement another
> mechanism for PV guests (instead of using the virtual PMU from a PVH guest).

Would that allow one to evaluate the performance/bottlenecks that the
hypervisor might have?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 17:42:47 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 17:42:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOu72-0006w0-Dg; Thu, 18 Oct 2012 17:42:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOu71-0006vv-Fa
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 17:42:27 +0000
Received: from [85.158.143.35:30141] by server-3.bemta-4.messagelabs.com id
	F2/B9-03544-28F30805; Thu, 18 Oct 2012 17:42:26 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1350582137!12057047!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24876 invoked from network); 18 Oct 2012 17:42:18 -0000
Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com)
	(209.85.212.43)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 17:42:18 -0000
Received: by mail-vb0-f43.google.com with SMTP id fq11so11273767vbb.30
	for ;
	Thu, 18 Oct 2012 10:42:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=daIL0e5rFu3VLDX92HebGv76qy3NUxVFH9FRfaqIjYk=;
	b=A2SYfNDHoPBPBMn/r+jET7GM3aGtIn+kFkc8wzHKr4thNWZhFwdGvSbcwqNQui4glC
	bPTJiUO/9Ji+iAAXIMsIRTo7UbM9/7Y/Wi5voRsMq8qgmw9oo+IQl8aAQOZ8xi7hsL/k
	WxyrHGhITYEhalak1f7obgUNEKfi3BqC4Ro5xaDqAxW2Qv3mKiugW26QM3BwZbyi7oLs
	x1OO7lcnGLnZNjXjh7BQAWIPOnfGkA8gkb+zsGqXdH6KtJhw6pXy4hZMioFXiYvNNed7
	sfu2pZ7GSYuXWLdvRxdR/Yng8btC14/ERZiZ6fdfiOIVJ2T5rsb97yL5alv0oo9isPeW
	csXA==
Received: by 10.58.180.134 with SMTP id do6mr17190463vec.13.1350582136787;
	Thu, 18 Oct 2012 10:42:16 -0700 (PDT)
Received: from localhost.localdomain (mba2436d0.tmodns.net. [208.54.36.186])
	by mx.google.com with ESMTPS id v9sm4035650ves.8.2012.10.18.10.42.11
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 18 Oct 2012 10:42:16 -0700 (PDT)
Date: Thu, 18 Oct 2012 13:42:03 -0400
From: Konrad Rzeszutek Wilk 
To: David Vrabel 
Message-ID: <20121018174200.GA20508@localhost.localdomain>
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	<507ED6C0.4020503@zytor.com>
	<20121017161036.GA10691@phenom.dumpdata.com>
	<507EE1C3.7070300@zytor.com>
	<20121017165452.GA22740@phenom.dumpdata.com>
	<50802EEC.6060102@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50802EEC.6060102@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk , x86@kernel.org,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	"H. Peter Anvin" , lenb@kernel.org
Subject: Re: [Xen-devel] Is: axe read_tscp pvops call. Was: Re: [RFC] ACPI
 S3 and Xen (suprisingly small\!).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> As for 'perf', since Xen already provides a virtual PMU for HVM guests
> It's not clear why we would spend the effort to implement another
> mechanism for PV guests (instead of using the virtual PMU from a PVH guest).

Would that allow one to evaluate the performance/bottlenecks that the
hypervisor might have?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 18:02:39 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 18:02:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOuQD-0007F5-Vo; Thu, 18 Oct 2012 18:02:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOuQC-0007F0-5V
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 18:02:16 +0000
Received: from [193.109.254.147:57969] by server-9.bemta-14.messagelabs.com id
	8A/98-09620-72440805; Thu, 18 Oct 2012 18:02:15 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1350583325!10359650!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzczMjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4811 invoked from network); 18 Oct 2012 18:02:07 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 18:02:07 -0000
X-IronPort-AV: E=Sophos;i="4.80,608,1344211200"; d="scan'208";a="41718371"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 18:02:04 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Thu, 18 Oct 2012
	14:02:04 -0400
Message-ID: <5080441A.4020907@citrix.com>
Date: Thu, 18 Oct 2012 19:02:02 +0100
From: David Vrabel 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk 
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	<507ED6C0.4020503@zytor.com>
	<20121017161036.GA10691@phenom.dumpdata.com>
	<507EE1C3.7070300@zytor.com>
	<20121017165452.GA22740@phenom.dumpdata.com>
	<50802EEC.6060102@citrix.com>
	<20121018174200.GA20508@localhost.localdomain>
In-Reply-To: <20121018174200.GA20508@localhost.localdomain>
Cc: "xen-devel@lists.xensource.com" ,
	Konrad Rzeszutek Wilk ,
	"x86@kernel.org" ,
	"linux-kernel@vger.kernel.org" ,
	"linux-acpi@vger.kernel.org" ,
	"H. Peter Anvin" , "lenb@kernel.org" 
Subject: Re: [Xen-devel] Is: axe read_tscp pvops call. Was: Re: [RFC] ACPI
 S3 and Xen (suprisingly small\!).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 18/10/12 18:42, Konrad Rzeszutek Wilk wrote:
>> As for 'perf', since Xen already provides a virtual PMU for HVM guests
>> It's not clear why we would spend the effort to implement another
>> mechanism for PV guests (instead of using the virtual PMU from a PVH guest).
> 
> Would that allow one to evaluate the performance/bottlenecks that the
> hypervisor might have?

Not right now, no. But I don't so why it couldn't be possible.

David


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 18:02:39 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 18:02:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOuQD-0007F5-Vo; Thu, 18 Oct 2012 18:02:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOuQC-0007F0-5V
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 18:02:16 +0000
Received: from [193.109.254.147:57969] by server-9.bemta-14.messagelabs.com id
	8A/98-09620-72440805; Thu, 18 Oct 2012 18:02:15 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1350583325!10359650!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzczMjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4811 invoked from network); 18 Oct 2012 18:02:07 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 18:02:07 -0000
X-IronPort-AV: E=Sophos;i="4.80,608,1344211200"; d="scan'208";a="41718371"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 18:02:04 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Thu, 18 Oct 2012
	14:02:04 -0400
Message-ID: <5080441A.4020907@citrix.com>
Date: Thu, 18 Oct 2012 19:02:02 +0100
From: David Vrabel 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk 
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	<507ED6C0.4020503@zytor.com>
	<20121017161036.GA10691@phenom.dumpdata.com>
	<507EE1C3.7070300@zytor.com>
	<20121017165452.GA22740@phenom.dumpdata.com>
	<50802EEC.6060102@citrix.com>
	<20121018174200.GA20508@localhost.localdomain>
In-Reply-To: <20121018174200.GA20508@localhost.localdomain>
Cc: "xen-devel@lists.xensource.com" ,
	Konrad Rzeszutek Wilk ,
	"x86@kernel.org" ,
	"linux-kernel@vger.kernel.org" ,
	"linux-acpi@vger.kernel.org" ,
	"H. Peter Anvin" , "lenb@kernel.org" 
Subject: Re: [Xen-devel] Is: axe read_tscp pvops call. Was: Re: [RFC] ACPI
 S3 and Xen (suprisingly small\!).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 18/10/12 18:42, Konrad Rzeszutek Wilk wrote:
>> As for 'perf', since Xen already provides a virtual PMU for HVM guests
>> It's not clear why we would spend the effort to implement another
>> mechanism for PV guests (instead of using the virtual PMU from a PVH guest).
> 
> Would that allow one to evaluate the performance/bottlenecks that the
> hypervisor might have?

Not right now, no. But I don't so why it couldn't be possible.

David


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 20:41:44 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 20:41:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOwu1-0008EO-Pa; Thu, 18 Oct 2012 20:41:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOwu0-0008EJ-5q
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 20:41:12 +0000
Received: from [85.158.139.83:14488] by server-4.bemta-5.messagelabs.com id
	88/DD-01455-76960805; Thu, 18 Oct 2012 20:41:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1350592870!28296255!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23121 invoked from network); 18 Oct 2012 20:41:10 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 20:41:10 -0000
X-IronPort-AV: E=Sophos;i="4.80,609,1344211200"; d="scan'208";a="15264120"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 20:41:09 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 18 Oct 2012 21:41:09 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TOwtx-0001vZ-9Z;
	Thu, 18 Oct 2012 20:41:09 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TOwtx-0003tW-8D;
	Thu, 18 Oct 2012 21:41:09 +0100
To: 
Message-ID: 
From: xen.org 
Date: Thu, 18 Oct 2012 21:41:09 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14038: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14038 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14038/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 13967
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 13967
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 13967
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 13967

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13967
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13967
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13967
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13967

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  3fa2ab30bb05
baseline version:
 xen                  c1c549c4fe9e

------------------------------------------------------------
People who touched revisions under test:
  Chuang Cao 
  Daniel De Graaf 
  Huang Ying 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Joe Jin 
  Keir Fraser 
  Olaf Hering 
  Sander Eikelenboom 
  Stefano Stabellini 
  Tim Deegan 
  Xiantao Zhang
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 592 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 20:41:44 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 20:41:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOwu1-0008EO-Pa; Thu, 18 Oct 2012 20:41:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOwu0-0008EJ-5q
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 20:41:12 +0000
Received: from [85.158.139.83:14488] by server-4.bemta-5.messagelabs.com id
	88/DD-01455-76960805; Thu, 18 Oct 2012 20:41:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1350592870!28296255!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23121 invoked from network); 18 Oct 2012 20:41:10 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 20:41:10 -0000
X-IronPort-AV: E=Sophos;i="4.80,609,1344211200"; d="scan'208";a="15264120"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 20:41:09 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 18 Oct 2012 21:41:09 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TOwtx-0001vZ-9Z;
	Thu, 18 Oct 2012 20:41:09 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TOwtx-0003tW-8D;
	Thu, 18 Oct 2012 21:41:09 +0100
To: 
Message-ID: 
From: xen.org 
Date: Thu, 18 Oct 2012 21:41:09 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14038: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14038 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14038/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 13967
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 13967
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 13967
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 13967

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13967
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13967
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13967
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13967

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  3fa2ab30bb05
baseline version:
 xen                  c1c549c4fe9e

------------------------------------------------------------
People who touched revisions under test:
  Chuang Cao 
  Daniel De Graaf 
  Huang Ying 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Joe Jin 
  Keir Fraser 
  Olaf Hering 
  Sander Eikelenboom 
  Stefano Stabellini 
  Tim Deegan 
  Xiantao Zhang
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 592 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 20:53:06 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 20:53:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOx55-0008OD-3E; Thu, 18 Oct 2012 20:52:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOx53-0008O8-Pn
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 20:52:38 +0000
Received: from [85.158.137.99:4004] by server-10.bemta-3.messagelabs.com id
	92/6B-27386-51C60805; Thu, 18 Oct 2012 20:52:37 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1350593555!22145147!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22520 invoked from network); 18 Oct 2012 20:52:35 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-16.tower-217.messagelabs.com with SMTP;
	18 Oct 2012 20:52:35 -0000
Received: from p5b2e3cc2.dip.t-dialin.net ([91.46.60.194] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from )
	id 1TOx4v-0000lH-Gp; Thu, 18 Oct 2012 20:52:29 +0000
Message-ID: <50806C0B.1060504@canonical.com>
Date: Thu, 18 Oct 2012 22:52:27 +0200
From: Stefan Bader 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Jan Beulich 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
	<1350482118.2460.74.camel@zakaz.uk.xensource.com>
	<507ECD06.2050407@canonical.com> <507ED038.8000806@citrix.com>
	<507FC51102000078000A235E@nat28.tlf.novell.com>
	<507FC71502000078000A236C@nat28.tlf.novell.com>
	<507FB1E1.8080700@canonical.com>
	<1350546483.28188.25.camel@dagon.hellion.org.uk>
	<507FD7DE.2010209@canonical.com>
	<507FFA5102000078000A250D@nat28.tlf.novell.com>
	<507FF964.9090009@canonical.com>
In-Reply-To: <507FF964.9090009@canonical.com>
X-Enigmail-Version: 1.4.5
Cc: Andrew Cooper ,
	"xen-devel@lists.xen.org" ,
	Ian Campbell ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============2958323107161820582=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============2958323107161820582==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig07495305BB5B4065E9069FF1"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig07495305BB5B4065E9069FF1
Content-Type: multipart/mixed;
 boundary="------------000604000200030200050803"

This is a multi-part message in MIME format.
--------------000604000200030200050803
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 18.10.2012 14:43, Stefan Bader wrote:
>> Obviously when this is an acquire not disabling interrupts, and
>> an interrupt comes in while in the poll hypercall (or about to go
>> there, or just having come back from one).
>>
>> Jan
>>
> Obviously. ;) Ok, so my thinking there was ok and its one level deep ma=
x. At
> some point staring at things I start question my sanity.
> A wild thinking would be whether in that case the interrupted spinlock =
may miss
> a wakeup forever when the unlocker only can check for the toplevel. Hm,=
 but that
> should be easy to rule out by just adding an error to spin_unlock_slow =
when it
> fails to find anything...
>=20
Actually I begin to suspect that it could be possible that I just overloo=
ked the
most obvious thing. Provoking question: are we sure we are on the same pa=
ge
about the purpose of the spin_lock_flags variant of the pv lock ops inter=
face?

I begin to suspect that it really is not for giving a chance to re-enable=

interrupts. Just what it should be used for I am not clear. Anyway it see=
ms all
other places more or less ignore the flags and map themselves back to an
ignorant version of spinlock.
Also I believe that the only high level function that would end up in pas=
sing
any flags, would be the spin_lock_irqsave one. And I am pretty sure that =
this
one will expect interrupts to stay disabled.

So I tried below approach and that seems to be surviving the previously b=
reaking
testcase for much longer than anything I tried before.

-Stefan

=46rom f2ebb6626f3e3a00932bf1f4f75265f826c7fba9 Mon Sep 17 00:00:00 2001
From: Stefan Bader 
Date: Thu, 18 Oct 2012 21:40:37 +0200
Subject: [PATCH 1/2] xen/pv-spinlock: Never enable interrupts in
 xen_spin_lock_slow()

I am not sure what exactly the spin_lock_flags variant of the
pv-spinlocks (or even in the arch spinlocks) should be used for.
But it should not be used as an invitation to enable irqs.

The only high-level variant that seems to end up there is the
spin_lock_irqsave one and that would always be used in a context
that expects the interrupts to be disabled.
The generic paravirt-spinlock code just maps the flags variant
to the one without flags, so just do the same and get rid of
all the stuff that is not needed anymore.

This seems to be resolving a weird locking issue seen when having
a high i/o database load on a PV Xen guest with multiple (8+ in
local experiments) CPUs. Well, thinking about it a second time
it seems like one of those "how did that ever work?" cases.

Signed-off-by: Stefan Bader 
---
 arch/x86/xen/spinlock.c |   23 +++++------------------
 1 file changed, 5 insertions(+), 18 deletions(-)

diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
index 83e866d..3330a1d 100644
--- a/arch/x86/xen/spinlock.c
+++ b/arch/x86/xen/spinlock.c
@@ -24,7 +24,6 @@ static struct xen_spinlock_stats
 	u32 taken_slow_nested;
 	u32 taken_slow_pickup;
 	u32 taken_slow_spurious;
-	u32 taken_slow_irqenable;

 	u64 released;
 	u32 released_slow;
@@ -197,7 +196,7 @@ static inline void unspinning_lock(struct xen_spinloc=
k *xl,
struct xen_spinlock
 	__this_cpu_write(lock_spinners, prev);
 }

-static noinline int xen_spin_lock_slow(struct arch_spinlock *lock, bool =
irq_enable)
+static noinline int xen_spin_lock_slow(struct arch_spinlock *lock)
 {
 	struct xen_spinlock *xl =3D (struct xen_spinlock *)lock;
 	struct xen_spinlock *prev;
@@ -218,8 +217,6 @@ static noinline int xen_spin_lock_slow(struct arch_sp=
inlock
*lock, bool irq_enab
 	ADD_STATS(taken_slow_nested, prev !=3D NULL);

 	do {
-		unsigned long flags;
-
 		/* clear pending */
 		xen_clear_irq_pending(irq);

@@ -239,12 +236,6 @@ static noinline int xen_spin_lock_slow(struct arch_s=
pinlock
*lock, bool irq_enab
 			goto out;
 		}

-		flags =3D arch_local_save_flags();
-		if (irq_enable) {
-			ADD_STATS(taken_slow_irqenable, 1);
-			raw_local_irq_enable();
-		}
-
 		/*
 		 * Block until irq becomes pending.  If we're
 		 * interrupted at this point (after the trylock but
@@ -256,8 +247,6 @@ static noinline int xen_spin_lock_slow(struct arch_sp=
inlock
*lock, bool irq_enab
 		 */
 		xen_poll_irq(irq);

-		raw_local_irq_restore(flags);
-
 		ADD_STATS(taken_slow_spurious, !xen_test_irq_pending(irq));
 	} while (!xen_test_irq_pending(irq)); /* check for spurious wakeups */

@@ -270,7 +259,7 @@ out:
 	return ret;
 }

-static inline void __xen_spin_lock(struct arch_spinlock *lock, bool irq_=
enable)
+static inline void __xen_spin_lock(struct arch_spinlock *lock)
 {
 	struct xen_spinlock *xl =3D (struct xen_spinlock *)lock;
 	unsigned timeout;
@@ -302,19 +291,19 @@ static inline void __xen_spin_lock(struct arch_spin=
lock
*lock, bool irq_enable)
 		spin_time_accum_spinning(start_spin_fast);

 	} while (unlikely(oldval !=3D 0 &&
-			  (TIMEOUT =3D=3D ~0 || !xen_spin_lock_slow(lock, irq_enable))));
+			  (TIMEOUT =3D=3D ~0 || !xen_spin_lock_slow(lock))));

 	spin_time_accum_total(start_spin);
 }

 static void xen_spin_lock(struct arch_spinlock *lock)
 {
-	__xen_spin_lock(lock, false);
+	__xen_spin_lock(lock);
 }

 static void xen_spin_lock_flags(struct arch_spinlock *lock, unsigned lon=
g flags)
 {
-	__xen_spin_lock(lock, !raw_irqs_disabled_flags(flags));
+	__xen_spin_lock(lock);
 }

 static noinline void xen_spin_unlock_slow(struct xen_spinlock *xl)
@@ -424,8 +413,6 @@ static int __init xen_spinlock_debugfs(void)
 			   &spinlock_stats.taken_slow_pickup);
 	debugfs_create_u32("taken_slow_spurious", 0444, d_spin_debug,
 			   &spinlock_stats.taken_slow_spurious);
-	debugfs_create_u32("taken_slow_irqenable", 0444, d_spin_debug,
-			   &spinlock_stats.taken_slow_irqenable);

 	debugfs_create_u64("released", 0444, d_spin_debug, &spinlock_stats.rele=
ased);
 	debugfs_create_u32("released_slow", 0444, d_spin_debug,
--=20
1.7.9.5


--------------000604000200030200050803
Content-Type: text/x-diff;
 name="0001-xen-pv-spinlock-Never-enable-interrupts-in-xen_spin_.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename*0="0001-xen-pv-spinlock-Never-enable-interrupts-in-xen_spin_.pa";
 filename*1="tch"

=46rom f2ebb6626f3e3a00932bf1f4f75265f826c7fba9 Mon Sep 17 00:00:00 2001
From: Stefan Bader 
Date: Thu, 18 Oct 2012 21:40:37 +0200
Subject: [PATCH 1/2] xen/pv-spinlock: Never enable interrupts in
 xen_spin_lock_slow()

I am not sure what exactly the spin_lock_flags variant of the
pv-spinlocks (or even in the arch spinlocks) should be used for.
But it should not be used as an invitation to enable irqs.

The only high-level variant that seems to end up there is the
spinlock_irqsave one and that would always be used in a context
that expects the interrupts to be disabled.
The generic paravirt-spinlock code just maps the flags variant
to the one without flags, so just do the same and get rid of
all the stuff that is not needed anymore.

This seems to be resolving a weird locking issue seen when having
a high i/o database load on a PV Xen guest with multiple (8+ in
local experiments) CPUs. Well, thinking about it a second time
it seems like one of those "how did that ever work?" cases.

Signed-off-by: Stefan Bader 
---
 arch/x86/xen/spinlock.c |   23 +++++------------------
 1 file changed, 5 insertions(+), 18 deletions(-)

diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
index 83e866d..3330a1d 100644
--- a/arch/x86/xen/spinlock.c
+++ b/arch/x86/xen/spinlock.c
@@ -24,7 +24,6 @@ static struct xen_spinlock_stats
 	u32 taken_slow_nested;
 	u32 taken_slow_pickup;
 	u32 taken_slow_spurious;
-	u32 taken_slow_irqenable;
=20
 	u64 released;
 	u32 released_slow;
@@ -197,7 +196,7 @@ static inline void unspinning_lock(struct xen_spinloc=
k *xl, struct xen_spinlock
 	__this_cpu_write(lock_spinners, prev);
 }
=20
-static noinline int xen_spin_lock_slow(struct arch_spinlock *lock, bool =
irq_enable)
+static noinline int xen_spin_lock_slow(struct arch_spinlock *lock)
 {
 	struct xen_spinlock *xl =3D (struct xen_spinlock *)lock;
 	struct xen_spinlock *prev;
@@ -218,8 +217,6 @@ static noinline int xen_spin_lock_slow(struct arch_sp=
inlock *lock, bool irq_enab
 	ADD_STATS(taken_slow_nested, prev !=3D NULL);
=20
 	do {
-		unsigned long flags;
-
 		/* clear pending */
 		xen_clear_irq_pending(irq);
=20
@@ -239,12 +236,6 @@ static noinline int xen_spin_lock_slow(struct arch_s=
pinlock *lock, bool irq_enab
 			goto out;
 		}
=20
-		flags =3D arch_local_save_flags();
-		if (irq_enable) {
-			ADD_STATS(taken_slow_irqenable, 1);
-			raw_local_irq_enable();
-		}
-
 		/*
 		 * Block until irq becomes pending.  If we're
 		 * interrupted at this point (after the trylock but
@@ -256,8 +247,6 @@ static noinline int xen_spin_lock_slow(struct arch_sp=
inlock *lock, bool irq_enab
 		 */
 		xen_poll_irq(irq);
=20
-		raw_local_irq_restore(flags);
-
 		ADD_STATS(taken_slow_spurious, !xen_test_irq_pending(irq));
 	} while (!xen_test_irq_pending(irq)); /* check for spurious wakeups */
=20
@@ -270,7 +259,7 @@ out:
 	return ret;
 }
=20
-static inline void __xen_spin_lock(struct arch_spinlock *lock, bool irq_=
enable)
+static inline void __xen_spin_lock(struct arch_spinlock *lock)
 {
 	struct xen_spinlock *xl =3D (struct xen_spinlock *)lock;
 	unsigned timeout;
@@ -302,19 +291,19 @@ static inline void __xen_spin_lock(struct arch_spin=
lock *lock, bool irq_enable)
 		spin_time_accum_spinning(start_spin_fast);
=20
 	} while (unlikely(oldval !=3D 0 &&
-			  (TIMEOUT =3D=3D ~0 || !xen_spin_lock_slow(lock, irq_enable))));
+			  (TIMEOUT =3D=3D ~0 || !xen_spin_lock_slow(lock))));
=20
 	spin_time_accum_total(start_spin);
 }
=20
 static void xen_spin_lock(struct arch_spinlock *lock)
 {
-	__xen_spin_lock(lock, false);
+	__xen_spin_lock(lock);
 }
=20
 static void xen_spin_lock_flags(struct arch_spinlock *lock, unsigned lon=
g flags)
 {
-	__xen_spin_lock(lock, !raw_irqs_disabled_flags(flags));
+	__xen_spin_lock(lock);
 }
=20
 static noinline void xen_spin_unlock_slow(struct xen_spinlock *xl)
@@ -424,8 +413,6 @@ static int __init xen_spinlock_debugfs(void)
 			   &spinlock_stats.taken_slow_pickup);
 	debugfs_create_u32("taken_slow_spurious", 0444, d_spin_debug,
 			   &spinlock_stats.taken_slow_spurious);
-	debugfs_create_u32("taken_slow_irqenable", 0444, d_spin_debug,
-			   &spinlock_stats.taken_slow_irqenable);
=20
 	debugfs_create_u64("released", 0444, d_spin_debug, &spinlock_stats.rele=
ased);
 	debugfs_create_u32("released_slow", 0444, d_spin_debug,
--=20
1.7.9.5


--------------000604000200030200050803--

--------------enig07495305BB5B4065E9069FF1
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBCgAGBQJQgGwLAAoJEOhnXe7L7s6jZjwP/jiw4qycURVgcb1Spwn4dW6b
Pyn6WoT014e6Fj4V9n24esDOYexjg8ORFf77trqi7qpp04KAxp7aAyTMQca6FAcW
GpVSuOPKkEaS0qexHvUZVChBmUz+47oSf4jdrhsowHAd+qWHIzLt5qN/NBFJArjf
3F4lAvqniqheHmp0TqW1oVyt2R82cFU0Ezik/mquABlUrE4kXIEJMaoJtTL93WsU
WhgRkdspJAHGEqN0VRXEd+uiVPkJTgjyZh+z8PBaAPhznCzlhuO1F+LUWAEANLzW
lmMq7iM7+SdkKupWYkPNuHJHOjlgn2Hm4lEhnXTCqQBQJzUmjSSk5fW4x9oYoOqu
Sy7RUEO8vFMJ9GRYzvhDCTHekXe1uWJ38JEoPZ2JFhL4f24OOk+ClGAIE0hh0If3
CdIvaNJoPxmCrEG4TQfLyEb9LWsSV1jDgOyYp4pHXPClLCaw/ceXk0cof2Phxu49
7OsuXcVrfrboQ1Pb0Mweqc/N+KAqIyxYFvNTcmmwTGBeX9Aj1CsVzF3TD49uZnb+
A6n7W56boqMt8Mg+u6FCkZH1a3sE2oH45YmlTU6YQ+WRGeZcLFx/mi8VQHsxB7zB
PG1oCS12+GltlJjZhedUFonaIIlLrpUt2effedpyLPoPX9BJhBJYW/JOheViaXUa
yC3XC3ehlhefqTd8ymmF
=OYGm
-----END PGP SIGNATURE-----

--------------enig07495305BB5B4065E9069FF1--


--===============2958323107161820582==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2958323107161820582==--


From xen-devel-bounces@lists.xen.org Thu Oct 18 20:53:06 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 20:53:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOx55-0008OD-3E; Thu, 18 Oct 2012 20:52:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOx53-0008O8-Pn
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 20:52:38 +0000
Received: from [85.158.137.99:4004] by server-10.bemta-3.messagelabs.com id
	92/6B-27386-51C60805; Thu, 18 Oct 2012 20:52:37 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1350593555!22145147!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22520 invoked from network); 18 Oct 2012 20:52:35 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-16.tower-217.messagelabs.com with SMTP;
	18 Oct 2012 20:52:35 -0000
Received: from p5b2e3cc2.dip.t-dialin.net ([91.46.60.194] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from )
	id 1TOx4v-0000lH-Gp; Thu, 18 Oct 2012 20:52:29 +0000
Message-ID: <50806C0B.1060504@canonical.com>
Date: Thu, 18 Oct 2012 22:52:27 +0200
From: Stefan Bader 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Jan Beulich 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
	<1350482118.2460.74.camel@zakaz.uk.xensource.com>
	<507ECD06.2050407@canonical.com> <507ED038.8000806@citrix.com>
	<507FC51102000078000A235E@nat28.tlf.novell.com>
	<507FC71502000078000A236C@nat28.tlf.novell.com>
	<507FB1E1.8080700@canonical.com>
	<1350546483.28188.25.camel@dagon.hellion.org.uk>
	<507FD7DE.2010209@canonical.com>
	<507FFA5102000078000A250D@nat28.tlf.novell.com>
	<507FF964.9090009@canonical.com>
In-Reply-To: <507FF964.9090009@canonical.com>
X-Enigmail-Version: 1.4.5
Cc: Andrew Cooper ,
	"xen-devel@lists.xen.org" ,
	Ian Campbell ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============2958323107161820582=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============2958323107161820582==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig07495305BB5B4065E9069FF1"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig07495305BB5B4065E9069FF1
Content-Type: multipart/mixed;
 boundary="------------000604000200030200050803"

This is a multi-part message in MIME format.
--------------000604000200030200050803
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 18.10.2012 14:43, Stefan Bader wrote:
>> Obviously when this is an acquire not disabling interrupts, and
>> an interrupt comes in while in the poll hypercall (or about to go
>> there, or just having come back from one).
>>
>> Jan
>>
> Obviously. ;) Ok, so my thinking there was ok and its one level deep ma=
x. At
> some point staring at things I start question my sanity.
> A wild thinking would be whether in that case the interrupted spinlock =
may miss
> a wakeup forever when the unlocker only can check for the toplevel. Hm,=
 but that
> should be easy to rule out by just adding an error to spin_unlock_slow =
when it
> fails to find anything...
>=20
Actually I begin to suspect that it could be possible that I just overloo=
ked the
most obvious thing. Provoking question: are we sure we are on the same pa=
ge
about the purpose of the spin_lock_flags variant of the pv lock ops inter=
face?

I begin to suspect that it really is not for giving a chance to re-enable=

interrupts. Just what it should be used for I am not clear. Anyway it see=
ms all
other places more or less ignore the flags and map themselves back to an
ignorant version of spinlock.
Also I believe that the only high level function that would end up in pas=
sing
any flags, would be the spin_lock_irqsave one. And I am pretty sure that =
this
one will expect interrupts to stay disabled.

So I tried below approach and that seems to be surviving the previously b=
reaking
testcase for much longer than anything I tried before.

-Stefan

=46rom f2ebb6626f3e3a00932bf1f4f75265f826c7fba9 Mon Sep 17 00:00:00 2001
From: Stefan Bader 
Date: Thu, 18 Oct 2012 21:40:37 +0200
Subject: [PATCH 1/2] xen/pv-spinlock: Never enable interrupts in
 xen_spin_lock_slow()

I am not sure what exactly the spin_lock_flags variant of the
pv-spinlocks (or even in the arch spinlocks) should be used for.
But it should not be used as an invitation to enable irqs.

The only high-level variant that seems to end up there is the
spin_lock_irqsave one and that would always be used in a context
that expects the interrupts to be disabled.
The generic paravirt-spinlock code just maps the flags variant
to the one without flags, so just do the same and get rid of
all the stuff that is not needed anymore.

This seems to be resolving a weird locking issue seen when having
a high i/o database load on a PV Xen guest with multiple (8+ in
local experiments) CPUs. Well, thinking about it a second time
it seems like one of those "how did that ever work?" cases.

Signed-off-by: Stefan Bader 
---
 arch/x86/xen/spinlock.c |   23 +++++------------------
 1 file changed, 5 insertions(+), 18 deletions(-)

diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
index 83e866d..3330a1d 100644
--- a/arch/x86/xen/spinlock.c
+++ b/arch/x86/xen/spinlock.c
@@ -24,7 +24,6 @@ static struct xen_spinlock_stats
 	u32 taken_slow_nested;
 	u32 taken_slow_pickup;
 	u32 taken_slow_spurious;
-	u32 taken_slow_irqenable;

 	u64 released;
 	u32 released_slow;
@@ -197,7 +196,7 @@ static inline void unspinning_lock(struct xen_spinloc=
k *xl,
struct xen_spinlock
 	__this_cpu_write(lock_spinners, prev);
 }

-static noinline int xen_spin_lock_slow(struct arch_spinlock *lock, bool =
irq_enable)
+static noinline int xen_spin_lock_slow(struct arch_spinlock *lock)
 {
 	struct xen_spinlock *xl =3D (struct xen_spinlock *)lock;
 	struct xen_spinlock *prev;
@@ -218,8 +217,6 @@ static noinline int xen_spin_lock_slow(struct arch_sp=
inlock
*lock, bool irq_enab
 	ADD_STATS(taken_slow_nested, prev !=3D NULL);

 	do {
-		unsigned long flags;
-
 		/* clear pending */
 		xen_clear_irq_pending(irq);

@@ -239,12 +236,6 @@ static noinline int xen_spin_lock_slow(struct arch_s=
pinlock
*lock, bool irq_enab
 			goto out;
 		}

-		flags =3D arch_local_save_flags();
-		if (irq_enable) {
-			ADD_STATS(taken_slow_irqenable, 1);
-			raw_local_irq_enable();
-		}
-
 		/*
 		 * Block until irq becomes pending.  If we're
 		 * interrupted at this point (after the trylock but
@@ -256,8 +247,6 @@ static noinline int xen_spin_lock_slow(struct arch_sp=
inlock
*lock, bool irq_enab
 		 */
 		xen_poll_irq(irq);

-		raw_local_irq_restore(flags);
-
 		ADD_STATS(taken_slow_spurious, !xen_test_irq_pending(irq));
 	} while (!xen_test_irq_pending(irq)); /* check for spurious wakeups */

@@ -270,7 +259,7 @@ out:
 	return ret;
 }

-static inline void __xen_spin_lock(struct arch_spinlock *lock, bool irq_=
enable)
+static inline void __xen_spin_lock(struct arch_spinlock *lock)
 {
 	struct xen_spinlock *xl =3D (struct xen_spinlock *)lock;
 	unsigned timeout;
@@ -302,19 +291,19 @@ static inline void __xen_spin_lock(struct arch_spin=
lock
*lock, bool irq_enable)
 		spin_time_accum_spinning(start_spin_fast);

 	} while (unlikely(oldval !=3D 0 &&
-			  (TIMEOUT =3D=3D ~0 || !xen_spin_lock_slow(lock, irq_enable))));
+			  (TIMEOUT =3D=3D ~0 || !xen_spin_lock_slow(lock))));

 	spin_time_accum_total(start_spin);
 }

 static void xen_spin_lock(struct arch_spinlock *lock)
 {
-	__xen_spin_lock(lock, false);
+	__xen_spin_lock(lock);
 }

 static void xen_spin_lock_flags(struct arch_spinlock *lock, unsigned lon=
g flags)
 {
-	__xen_spin_lock(lock, !raw_irqs_disabled_flags(flags));
+	__xen_spin_lock(lock);
 }

 static noinline void xen_spin_unlock_slow(struct xen_spinlock *xl)
@@ -424,8 +413,6 @@ static int __init xen_spinlock_debugfs(void)
 			   &spinlock_stats.taken_slow_pickup);
 	debugfs_create_u32("taken_slow_spurious", 0444, d_spin_debug,
 			   &spinlock_stats.taken_slow_spurious);
-	debugfs_create_u32("taken_slow_irqenable", 0444, d_spin_debug,
-			   &spinlock_stats.taken_slow_irqenable);

 	debugfs_create_u64("released", 0444, d_spin_debug, &spinlock_stats.rele=
ased);
 	debugfs_create_u32("released_slow", 0444, d_spin_debug,
--=20
1.7.9.5


--------------000604000200030200050803
Content-Type: text/x-diff;
 name="0001-xen-pv-spinlock-Never-enable-interrupts-in-xen_spin_.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename*0="0001-xen-pv-spinlock-Never-enable-interrupts-in-xen_spin_.pa";
 filename*1="tch"

=46rom f2ebb6626f3e3a00932bf1f4f75265f826c7fba9 Mon Sep 17 00:00:00 2001
From: Stefan Bader 
Date: Thu, 18 Oct 2012 21:40:37 +0200
Subject: [PATCH 1/2] xen/pv-spinlock: Never enable interrupts in
 xen_spin_lock_slow()

I am not sure what exactly the spin_lock_flags variant of the
pv-spinlocks (or even in the arch spinlocks) should be used for.
But it should not be used as an invitation to enable irqs.

The only high-level variant that seems to end up there is the
spinlock_irqsave one and that would always be used in a context
that expects the interrupts to be disabled.
The generic paravirt-spinlock code just maps the flags variant
to the one without flags, so just do the same and get rid of
all the stuff that is not needed anymore.

This seems to be resolving a weird locking issue seen when having
a high i/o database load on a PV Xen guest with multiple (8+ in
local experiments) CPUs. Well, thinking about it a second time
it seems like one of those "how did that ever work?" cases.

Signed-off-by: Stefan Bader 
---
 arch/x86/xen/spinlock.c |   23 +++++------------------
 1 file changed, 5 insertions(+), 18 deletions(-)

diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
index 83e866d..3330a1d 100644
--- a/arch/x86/xen/spinlock.c
+++ b/arch/x86/xen/spinlock.c
@@ -24,7 +24,6 @@ static struct xen_spinlock_stats
 	u32 taken_slow_nested;
 	u32 taken_slow_pickup;
 	u32 taken_slow_spurious;
-	u32 taken_slow_irqenable;
=20
 	u64 released;
 	u32 released_slow;
@@ -197,7 +196,7 @@ static inline void unspinning_lock(struct xen_spinloc=
k *xl, struct xen_spinlock
 	__this_cpu_write(lock_spinners, prev);
 }
=20
-static noinline int xen_spin_lock_slow(struct arch_spinlock *lock, bool =
irq_enable)
+static noinline int xen_spin_lock_slow(struct arch_spinlock *lock)
 {
 	struct xen_spinlock *xl =3D (struct xen_spinlock *)lock;
 	struct xen_spinlock *prev;
@@ -218,8 +217,6 @@ static noinline int xen_spin_lock_slow(struct arch_sp=
inlock *lock, bool irq_enab
 	ADD_STATS(taken_slow_nested, prev !=3D NULL);
=20
 	do {
-		unsigned long flags;
-
 		/* clear pending */
 		xen_clear_irq_pending(irq);
=20
@@ -239,12 +236,6 @@ static noinline int xen_spin_lock_slow(struct arch_s=
pinlock *lock, bool irq_enab
 			goto out;
 		}
=20
-		flags =3D arch_local_save_flags();
-		if (irq_enable) {
-			ADD_STATS(taken_slow_irqenable, 1);
-			raw_local_irq_enable();
-		}
-
 		/*
 		 * Block until irq becomes pending.  If we're
 		 * interrupted at this point (after the trylock but
@@ -256,8 +247,6 @@ static noinline int xen_spin_lock_slow(struct arch_sp=
inlock *lock, bool irq_enab
 		 */
 		xen_poll_irq(irq);
=20
-		raw_local_irq_restore(flags);
-
 		ADD_STATS(taken_slow_spurious, !xen_test_irq_pending(irq));
 	} while (!xen_test_irq_pending(irq)); /* check for spurious wakeups */
=20
@@ -270,7 +259,7 @@ out:
 	return ret;
 }
=20
-static inline void __xen_spin_lock(struct arch_spinlock *lock, bool irq_=
enable)
+static inline void __xen_spin_lock(struct arch_spinlock *lock)
 {
 	struct xen_spinlock *xl =3D (struct xen_spinlock *)lock;
 	unsigned timeout;
@@ -302,19 +291,19 @@ static inline void __xen_spin_lock(struct arch_spin=
lock *lock, bool irq_enable)
 		spin_time_accum_spinning(start_spin_fast);
=20
 	} while (unlikely(oldval !=3D 0 &&
-			  (TIMEOUT =3D=3D ~0 || !xen_spin_lock_slow(lock, irq_enable))));
+			  (TIMEOUT =3D=3D ~0 || !xen_spin_lock_slow(lock))));
=20
 	spin_time_accum_total(start_spin);
 }
=20
 static void xen_spin_lock(struct arch_spinlock *lock)
 {
-	__xen_spin_lock(lock, false);
+	__xen_spin_lock(lock);
 }
=20
 static void xen_spin_lock_flags(struct arch_spinlock *lock, unsigned lon=
g flags)
 {
-	__xen_spin_lock(lock, !raw_irqs_disabled_flags(flags));
+	__xen_spin_lock(lock);
 }
=20
 static noinline void xen_spin_unlock_slow(struct xen_spinlock *xl)
@@ -424,8 +413,6 @@ static int __init xen_spinlock_debugfs(void)
 			   &spinlock_stats.taken_slow_pickup);
 	debugfs_create_u32("taken_slow_spurious", 0444, d_spin_debug,
 			   &spinlock_stats.taken_slow_spurious);
-	debugfs_create_u32("taken_slow_irqenable", 0444, d_spin_debug,
-			   &spinlock_stats.taken_slow_irqenable);
=20
 	debugfs_create_u64("released", 0444, d_spin_debug, &spinlock_stats.rele=
ased);
 	debugfs_create_u32("released_slow", 0444, d_spin_debug,
--=20
1.7.9.5


--------------000604000200030200050803--

--------------enig07495305BB5B4065E9069FF1
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBCgAGBQJQgGwLAAoJEOhnXe7L7s6jZjwP/jiw4qycURVgcb1Spwn4dW6b
Pyn6WoT014e6Fj4V9n24esDOYexjg8ORFf77trqi7qpp04KAxp7aAyTMQca6FAcW
GpVSuOPKkEaS0qexHvUZVChBmUz+47oSf4jdrhsowHAd+qWHIzLt5qN/NBFJArjf
3F4lAvqniqheHmp0TqW1oVyt2R82cFU0Ezik/mquABlUrE4kXIEJMaoJtTL93WsU
WhgRkdspJAHGEqN0VRXEd+uiVPkJTgjyZh+z8PBaAPhznCzlhuO1F+LUWAEANLzW
lmMq7iM7+SdkKupWYkPNuHJHOjlgn2Hm4lEhnXTCqQBQJzUmjSSk5fW4x9oYoOqu
Sy7RUEO8vFMJ9GRYzvhDCTHekXe1uWJ38JEoPZ2JFhL4f24OOk+ClGAIE0hh0If3
CdIvaNJoPxmCrEG4TQfLyEb9LWsSV1jDgOyYp4pHXPClLCaw/ceXk0cof2Phxu49
7OsuXcVrfrboQ1Pb0Mweqc/N+KAqIyxYFvNTcmmwTGBeX9Aj1CsVzF3TD49uZnb+
A6n7W56boqMt8Mg+u6FCkZH1a3sE2oH45YmlTU6YQ+WRGeZcLFx/mi8VQHsxB7zB
PG1oCS12+GltlJjZhedUFonaIIlLrpUt2effedpyLPoPX9BJhBJYW/JOheViaXUa
yC3XC3ehlhefqTd8ymmF
=OYGm
-----END PGP SIGNATURE-----

--------------enig07495305BB5B4065E9069FF1--


--===============2958323107161820582==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2958323107161820582==--


From xen-devel-bounces@lists.xen.org Thu Oct 18 22:04:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 22:04:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOyCI-0000UJ-1P; Thu, 18 Oct 2012 22:04:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOyCG-0000U7-1X
	for Xen-devel@lists.xensource.com; Thu, 18 Oct 2012 22:04:08 +0000
Received: from [85.158.143.35:16765] by server-3.bemta-4.messagelabs.com id
	03/92-03544-7DC70805; Thu, 18 Oct 2012 22:04:07 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1350597845!14617512!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODE0MTgy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21460 invoked from network); 18 Oct 2012 22:04:06 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Oct 2012 22:04:06 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9IM42AJ021861
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 18 Oct 2012 22:04:03 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9IM41DT023546
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 18 Oct 2012 22:04:02 GMT
Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9IM415Y018346; Thu, 18 Oct 2012 17:04:01 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 18 Oct 2012 15:04:01 -0700
Date: Thu, 18 Oct 2012 15:03:59 -0700
From: Mukesh Rathor 
To: Ian Campbell 
Message-ID: <20121018150359.794768d2@mantra.us.oracle.com>
In-Reply-To: <1350557077.2460.113.camel@zakaz.uk.xensource.com>
References: <20121017173005.73a03eec@mantra.us.oracle.com>
	<1350557077.2460.113.camel@zakaz.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V3 2/6]: PVH: use native irq, enable callback,
 use HVM ring ops, smp, ...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 18 Oct 2012 11:44:37 +0100
Ian Campbell  wrote:

> On Thu, 2012-10-18 at 01:30 +0100, Mukesh Rathor wrote:
> > PVH: make gdt_frames[]/gdt_ents into a union with {gdtaddr, gdtsz},
> > PVH only needs to send down gdtaddr and gdtsz. irq.c: PVH uses
> > native_irq_ops. vcpu hotplug is currently not available for PVH.
> > events.c: setup callback vector for PVH. smp.c: This pertains to
> > bringing up smp vcpus. PVH runs in ring 0, so syscalls are native.
> > Also, the vcpu context is send down via the hcall to be set in the
> > vmcs. gdtaddr and gdtsz are unionionized as PVH only needs to send
> > these two to be set in the vmcs. Finally, PVH ring ops uses HVM
> > paths for xenbus.
> > 
> > Signed-off-by: Mukesh Rathor 
> > ---
> >  arch/x86/include/asm/xen/interface.h |   11 +++++-
> >  arch/x86/xen/irq.c                   |    5 ++-
> >  arch/x86/xen/p2m.c                   |    2 +-
> >  arch/x86/xen/smp.c                   |   75
> > ++++++++++++++++++++++------------ drivers/xen/cpu_hotplug.c
> > |    4 +- drivers/xen/events.c                 |    9 ++++-
> >  drivers/xen/xenbus/xenbus_client.c   |    3 +-
> 
> This patch seems to have been horribly whitespace damaged.

Hmm.. not sure what happened. Resending. See another email.

> Have you seen "git send-email" ? It's very useful for avoiding this
> sort of thing and also takes a lot of the grunt work out of reposting
> a series.

> It also chains the patches as replies to the introductory zero-th mail
> -- which is something I've been meaning to ask you to do for a while.
> It's useful because it joins the series together in a thread which
> makes it easier to keep track of in my INBOX.

I prefer different thread-sets for different version. Otherwise too
many emails makes much harder to manage and figure. Besides, as
comments come in, path x of y,  may contain different files/changes in
a subsequent version.

thanks
Mukesh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 22:04:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 22:04:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOyCI-0000UJ-1P; Thu, 18 Oct 2012 22:04:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOyCG-0000U7-1X
	for Xen-devel@lists.xensource.com; Thu, 18 Oct 2012 22:04:08 +0000
Received: from [85.158.143.35:16765] by server-3.bemta-4.messagelabs.com id
	03/92-03544-7DC70805; Thu, 18 Oct 2012 22:04:07 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1350597845!14617512!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODE0MTgy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21460 invoked from network); 18 Oct 2012 22:04:06 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Oct 2012 22:04:06 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9IM42AJ021861
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 18 Oct 2012 22:04:03 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9IM41DT023546
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 18 Oct 2012 22:04:02 GMT
Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9IM415Y018346; Thu, 18 Oct 2012 17:04:01 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 18 Oct 2012 15:04:01 -0700
Date: Thu, 18 Oct 2012 15:03:59 -0700
From: Mukesh Rathor 
To: Ian Campbell 
Message-ID: <20121018150359.794768d2@mantra.us.oracle.com>
In-Reply-To: <1350557077.2460.113.camel@zakaz.uk.xensource.com>
References: <20121017173005.73a03eec@mantra.us.oracle.com>
	<1350557077.2460.113.camel@zakaz.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V3 2/6]: PVH: use native irq, enable callback,
 use HVM ring ops, smp, ...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 18 Oct 2012 11:44:37 +0100
Ian Campbell  wrote:

> On Thu, 2012-10-18 at 01:30 +0100, Mukesh Rathor wrote:
> > PVH: make gdt_frames[]/gdt_ents into a union with {gdtaddr, gdtsz},
> > PVH only needs to send down gdtaddr and gdtsz. irq.c: PVH uses
> > native_irq_ops. vcpu hotplug is currently not available for PVH.
> > events.c: setup callback vector for PVH. smp.c: This pertains to
> > bringing up smp vcpus. PVH runs in ring 0, so syscalls are native.
> > Also, the vcpu context is send down via the hcall to be set in the
> > vmcs. gdtaddr and gdtsz are unionionized as PVH only needs to send
> > these two to be set in the vmcs. Finally, PVH ring ops uses HVM
> > paths for xenbus.
> > 
> > Signed-off-by: Mukesh Rathor 
> > ---
> >  arch/x86/include/asm/xen/interface.h |   11 +++++-
> >  arch/x86/xen/irq.c                   |    5 ++-
> >  arch/x86/xen/p2m.c                   |    2 +-
> >  arch/x86/xen/smp.c                   |   75
> > ++++++++++++++++++++++------------ drivers/xen/cpu_hotplug.c
> > |    4 +- drivers/xen/events.c                 |    9 ++++-
> >  drivers/xen/xenbus/xenbus_client.c   |    3 +-
> 
> This patch seems to have been horribly whitespace damaged.

Hmm.. not sure what happened. Resending. See another email.

> Have you seen "git send-email" ? It's very useful for avoiding this
> sort of thing and also takes a lot of the grunt work out of reposting
> a series.

> It also chains the patches as replies to the introductory zero-th mail
> -- which is something I've been meaning to ask you to do for a while.
> It's useful because it joins the series together in a thread which
> makes it easier to keep track of in my INBOX.

I prefer different thread-sets for different version. Otherwise too
many emails makes much harder to manage and figure. Besides, as
comments come in, path x of y,  may contain different files/changes in
a subsequent version.

thanks
Mukesh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 22:38:53 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 22:38:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOyjV-0000mb-DS; Thu, 18 Oct 2012 22:38:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOyjU-0000mW-4s
	for Xen-devel@lists.xensource.com; Thu, 18 Oct 2012 22:38:28 +0000
Received: from [85.158.139.211:13940] by server-9.bemta-5.messagelabs.com id
	26/E5-23053-3E480805; Thu, 18 Oct 2012 22:38:27 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1350599905!22893405!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgyMTI5Ng==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29630 invoked from network); 18 Oct 2012 22:38:26 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Oct 2012 22:38:26 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9IMcMc7019411
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 18 Oct 2012 22:38:23 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9IMcLPE015796
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 18 Oct 2012 22:38:21 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9IMcKoR008070; Thu, 18 Oct 2012 17:38:20 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 18 Oct 2012 15:38:20 -0700
Date: Thu, 18 Oct 2012 15:38:19 -0700
From: Mukesh Rathor 
To: Ian Campbell 
Message-ID: <20121018153819.03a1d63e@mantra.us.oracle.com>
In-Reply-To: <1350557077.2460.113.camel@zakaz.uk.xensource.com>
References: <20121017173005.73a03eec@mantra.us.oracle.com>
	<1350557077.2460.113.camel@zakaz.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V3 2/6]: (RESEND) PVH: use native irq,
 enable callback, use HVM ring ops, smp, ...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

PVH: make gdt_frames[]/gdt_ents into a union with {gdtaddr, gdtsz}, PVH
only needs to send down gdtaddr and gdtsz. irq.c: PVH uses
native_irq_ops. vcpu hotplug is currently not available for PVH.
events.c: setup callback vector for PVH. Finally, PVH ring ops uses HVM
paths for xenbus.

Signed-off-by: Mukesh Rathor 
---
 arch/x86/include/asm/xen/interface.h |   11 +++++-
 arch/x86/xen/irq.c                   |    5 ++-
 arch/x86/xen/p2m.c                   |    2 +-
 arch/x86/xen/smp.c                   |   75 ++++++++++++++++++++++------------
 drivers/xen/cpu_hotplug.c            |    4 +-
 drivers/xen/events.c                 |    9 ++++-
 drivers/xen/xenbus/xenbus_client.c   |    3 +-
 7 files changed, 77 insertions(+), 32 deletions(-)

diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
index 555f94d..ac5ef76 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -143,7 +143,16 @@ struct vcpu_guest_context {
     struct cpu_user_regs user_regs;         /* User-level CPU registers     */
     struct trap_info trap_ctxt[256];        /* Virtual IDT                  */
     unsigned long ldt_base, ldt_ents;       /* LDT (linear address, # ents) */
-    unsigned long gdt_frames[16], gdt_ents; /* GDT (machine frames, # ents) */
+    union {
+	struct {
+		/* PV: GDT (machine frames, # ents).*/
+		unsigned long gdt_frames[16], gdt_ents;
+	} pv;
+	struct {
+		/* PVH: GDTR addr and size */
+	    unsigned long gdtaddr, gdtsz;
+	} pvh;
+    } u;
     unsigned long kernel_ss, kernel_sp;     /* Virtual TSS (only SS1/SP1)   */
     /* NB. User pagetable on x86/64 is placed in ctrlreg[1]. */
     unsigned long ctrlreg[8];               /* CR0-CR7 (control registers)  */
diff --git a/arch/x86/xen/irq.c b/arch/x86/xen/irq.c
index 1573376..31959a7 100644
--- a/arch/x86/xen/irq.c
+++ b/arch/x86/xen/irq.c
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -128,6 +129,8 @@ static const struct pv_irq_ops xen_irq_ops __initconst = {
 
 void __init xen_init_irq_ops(void)
 {
-	pv_irq_ops = xen_irq_ops;
+	/* For PVH we use default pv_irq_ops settings */
+	if (!xen_feature(XENFEAT_hvm_callback_vector))
+		pv_irq_ops = xen_irq_ops;
 	x86_init.irqs.intr_init = xen_init_IRQ;
 }
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 95fb2aa..ea553c8 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -798,7 +798,7 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 {
 	unsigned topidx, mididx, idx;
 
-	if (unlikely(xen_feature(XENFEAT_auto_translated_physmap))) {
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
 		BUG_ON(pfn != mfn && mfn != INVALID_P2M_ENTRY);
 		return true;
 	}
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index f58dca7..cda1907 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -68,9 +68,11 @@ static void __cpuinit cpu_bringup(void)
 	touch_softlockup_watchdog();
 	preempt_disable();
 
-	xen_enable_sysenter();
-	xen_enable_syscall();
-
+	/* PVH runs in ring 0 and allows us to do native syscalls. Yay! */
+	if (!xen_feature(XENFEAT_supervisor_mode_kernel)) {
+		xen_enable_sysenter();
+		xen_enable_syscall();
+	}
 	cpu = smp_processor_id();
 	smp_store_cpu_info(cpu);
 	cpu_data(cpu).x86_max_cores = 1;
@@ -230,10 +232,11 @@ static void __init xen_smp_prepare_boot_cpu(void)
 	BUG_ON(smp_processor_id() != 0);
 	native_smp_prepare_boot_cpu();
 
-	/* We've switched to the "real" per-cpu gdt, so make sure the
-	   old memory can be recycled */
-	make_lowmem_page_readwrite(xen_initial_gdt);
-
+	if (!xen_feature(XENFEAT_writable_page_tables)) {
+		/* We've switched to the "real" per-cpu gdt, so make sure the
+		 * old memory can be recycled */
+		make_lowmem_page_readwrite(xen_initial_gdt);
+	}
 	xen_filter_cpu_maps();
 	xen_setup_vcpu_info_placement();
 }
@@ -300,8 +303,6 @@ cpu_initialize_context(unsigned int cpu, struct task_struct *idle)
 	gdt = get_cpu_gdt_table(cpu);
 
 	ctxt->flags = VGCF_IN_KERNEL;
-	ctxt->user_regs.ds = __USER_DS;
-	ctxt->user_regs.es = __USER_DS;
 	ctxt->user_regs.ss = __KERNEL_DS;
 #ifdef CONFIG_X86_32
 	ctxt->user_regs.fs = __KERNEL_PERCPU;
@@ -310,35 +311,57 @@ cpu_initialize_context(unsigned int cpu, struct task_struct *idle)
 	ctxt->gs_base_kernel = per_cpu_offset(cpu);
 #endif
 	ctxt->user_regs.eip = (unsigned long)cpu_bringup_and_idle;
-	ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
 
 	memset(&ctxt->fpu_ctxt, 0, sizeof(ctxt->fpu_ctxt));
 
-	xen_copy_trap_info(ctxt->trap_ctxt);
+	/* check for autoxlated to get it right for 32bit kernel */
+	if (xen_feature(XENFEAT_auto_translated_physmap) &&
+	    xen_feature(XENFEAT_supervisor_mode_kernel)) {
 
-	ctxt->ldt_ents = 0;
+		ctxt->user_regs.ds = __KERNEL_DS;
+		ctxt->user_regs.es = 0;
+		ctxt->user_regs.gs = 0;
 
-	BUG_ON((unsigned long)gdt & ~PAGE_MASK);
+		ctxt->u.pvh.gdtaddr = (unsigned long)gdt;
+		ctxt->u.pvh.gdtsz = (unsigned long)(GDT_SIZE - 1);
 
-	gdt_mfn = arbitrary_virt_to_mfn(gdt);
-	make_lowmem_page_readonly(gdt);
-	make_lowmem_page_readonly(mfn_to_virt(gdt_mfn));
+#ifdef CONFIG_X86_64
+		/* Note: PVH is not supported on x86_32. */
+		ctxt->gs_base_user = (unsigned long)
+					per_cpu(irq_stack_union.gs_base, cpu);
+#endif
+	} else {
+		ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
+		ctxt->user_regs.ds = __USER_DS;
+		ctxt->user_regs.es = __USER_DS;
 
-	ctxt->gdt_frames[0] = gdt_mfn;
-	ctxt->gdt_ents      = GDT_ENTRIES;
+		xen_copy_trap_info(ctxt->trap_ctxt);
 
-	ctxt->user_regs.cs = __KERNEL_CS;
-	ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct pt_regs);
+		ctxt->ldt_ents = 0;
 
-	ctxt->kernel_ss = __KERNEL_DS;
-	ctxt->kernel_sp = idle->thread.sp0;
+		BUG_ON((unsigned long)gdt & ~PAGE_MASK);
+
+		gdt_mfn = arbitrary_virt_to_mfn(gdt);
+		make_lowmem_page_readonly(gdt);
+		make_lowmem_page_readonly(mfn_to_virt(gdt_mfn));
+
+		ctxt->u.pv.gdt_frames[0] = gdt_mfn;
+		ctxt->u.pv.gdt_ents      = GDT_ENTRIES;
+
+		ctxt->kernel_ss = __KERNEL_DS;
+		ctxt->kernel_sp = idle->thread.sp0;
 
 #ifdef CONFIG_X86_32
-	ctxt->event_callback_cs     = __KERNEL_CS;
-	ctxt->failsafe_callback_cs  = __KERNEL_CS;
+		ctxt->event_callback_cs     = __KERNEL_CS;
+		ctxt->failsafe_callback_cs  = __KERNEL_CS;
 #endif
-	ctxt->event_callback_eip    = (unsigned long)xen_hypervisor_callback;
-	ctxt->failsafe_callback_eip = (unsigned long)xen_failsafe_callback;
+		ctxt->event_callback_eip    =
+					(unsigned long)xen_hypervisor_callback;
+		ctxt->failsafe_callback_eip =
+					(unsigned long)xen_failsafe_callback;
+	}
+	ctxt->user_regs.cs = __KERNEL_CS;
+	ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct pt_regs);
 
 	per_cpu(xen_cr3, cpu) = __pa(swapper_pg_dir);
 	ctxt->ctrlreg[3] = xen_pfn_to_cr3(virt_to_mfn(swapper_pg_dir));
diff --git a/drivers/xen/cpu_hotplug.c b/drivers/xen/cpu_hotplug.c
index 4dcfced..de6bcf9 100644
--- a/drivers/xen/cpu_hotplug.c
+++ b/drivers/xen/cpu_hotplug.c
@@ -2,6 +2,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -100,7 +101,8 @@ static int __init setup_vcpu_hotplug_event(void)
 	static struct notifier_block xsn_cpu = {
 		.notifier_call = setup_cpu_watcher };
 
-	if (!xen_pv_domain())
+	/* PVH TBD/FIXME: future work */
+	if (!xen_pv_domain() || xen_feature(XENFEAT_auto_translated_physmap))
 		return -ENODEV;
 
 	register_xenstore_notifier(&xsn_cpu);
diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index c60d162..a977612 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -1767,7 +1767,7 @@ int xen_set_callback_via(uint64_t via)
 }
 EXPORT_SYMBOL_GPL(xen_set_callback_via);
 
-#ifdef CONFIG_XEN_PVHVM
+#ifdef CONFIG_X86
 /* Vector callbacks are better than PCI interrupts to receive event
  * channel notifications because we can receive vector callbacks on any
  * vcpu and we don't need PCI support or APIC interactions. */
@@ -1826,6 +1826,13 @@ void __init xen_init_IRQ(void)
 		if (xen_initial_domain())
 			pci_xen_initial_domain();
 
+		if (xen_feature(XENFEAT_hvm_callback_vector)) {
+			xen_callback_vector();
+			return;
+		}
+
+		/* PVH: TBD/FIXME: debug and fix eio map to work with pvh */
+
 		pirq_eoi_map = (void *)__get_free_page(GFP_KERNEL|__GFP_ZERO);
 		eoi_gmfn.gmfn = virt_to_mfn(pirq_eoi_map);
 		rc = HYPERVISOR_physdev_op(PHYSDEVOP_pirq_eoi_gmfn_v2, &eoi_gmfn);
diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
index b3e146e..1bac743 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -44,6 +44,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "xenbus_probe.h"
 
@@ -743,7 +744,7 @@ static const struct xenbus_ring_ops ring_ops_hvm = {
 
 void __init xenbus_ring_ops_init(void)
 {
-	if (xen_pv_domain())
+	if (xen_pv_domain() && !xen_feature(XENFEAT_auto_translated_physmap))
 		ring_ops = &ring_ops_pv;
 	else
 		ring_ops = &ring_ops_hvm;
-- 
1.7.2.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 22:38:53 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 22:38:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOyjV-0000mb-DS; Thu, 18 Oct 2012 22:38:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOyjU-0000mW-4s
	for Xen-devel@lists.xensource.com; Thu, 18 Oct 2012 22:38:28 +0000
Received: from [85.158.139.211:13940] by server-9.bemta-5.messagelabs.com id
	26/E5-23053-3E480805; Thu, 18 Oct 2012 22:38:27 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1350599905!22893405!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgyMTI5Ng==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29630 invoked from network); 18 Oct 2012 22:38:26 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Oct 2012 22:38:26 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9IMcMc7019411
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 18 Oct 2012 22:38:23 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9IMcLPE015796
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 18 Oct 2012 22:38:21 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9IMcKoR008070; Thu, 18 Oct 2012 17:38:20 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 18 Oct 2012 15:38:20 -0700
Date: Thu, 18 Oct 2012 15:38:19 -0700
From: Mukesh Rathor 
To: Ian Campbell 
Message-ID: <20121018153819.03a1d63e@mantra.us.oracle.com>
In-Reply-To: <1350557077.2460.113.camel@zakaz.uk.xensource.com>
References: <20121017173005.73a03eec@mantra.us.oracle.com>
	<1350557077.2460.113.camel@zakaz.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V3 2/6]: (RESEND) PVH: use native irq,
 enable callback, use HVM ring ops, smp, ...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

PVH: make gdt_frames[]/gdt_ents into a union with {gdtaddr, gdtsz}, PVH
only needs to send down gdtaddr and gdtsz. irq.c: PVH uses
native_irq_ops. vcpu hotplug is currently not available for PVH.
events.c: setup callback vector for PVH. Finally, PVH ring ops uses HVM
paths for xenbus.

Signed-off-by: Mukesh Rathor 
---
 arch/x86/include/asm/xen/interface.h |   11 +++++-
 arch/x86/xen/irq.c                   |    5 ++-
 arch/x86/xen/p2m.c                   |    2 +-
 arch/x86/xen/smp.c                   |   75 ++++++++++++++++++++++------------
 drivers/xen/cpu_hotplug.c            |    4 +-
 drivers/xen/events.c                 |    9 ++++-
 drivers/xen/xenbus/xenbus_client.c   |    3 +-
 7 files changed, 77 insertions(+), 32 deletions(-)

diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
index 555f94d..ac5ef76 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -143,7 +143,16 @@ struct vcpu_guest_context {
     struct cpu_user_regs user_regs;         /* User-level CPU registers     */
     struct trap_info trap_ctxt[256];        /* Virtual IDT                  */
     unsigned long ldt_base, ldt_ents;       /* LDT (linear address, # ents) */
-    unsigned long gdt_frames[16], gdt_ents; /* GDT (machine frames, # ents) */
+    union {
+	struct {
+		/* PV: GDT (machine frames, # ents).*/
+		unsigned long gdt_frames[16], gdt_ents;
+	} pv;
+	struct {
+		/* PVH: GDTR addr and size */
+	    unsigned long gdtaddr, gdtsz;
+	} pvh;
+    } u;
     unsigned long kernel_ss, kernel_sp;     /* Virtual TSS (only SS1/SP1)   */
     /* NB. User pagetable on x86/64 is placed in ctrlreg[1]. */
     unsigned long ctrlreg[8];               /* CR0-CR7 (control registers)  */
diff --git a/arch/x86/xen/irq.c b/arch/x86/xen/irq.c
index 1573376..31959a7 100644
--- a/arch/x86/xen/irq.c
+++ b/arch/x86/xen/irq.c
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -128,6 +129,8 @@ static const struct pv_irq_ops xen_irq_ops __initconst = {
 
 void __init xen_init_irq_ops(void)
 {
-	pv_irq_ops = xen_irq_ops;
+	/* For PVH we use default pv_irq_ops settings */
+	if (!xen_feature(XENFEAT_hvm_callback_vector))
+		pv_irq_ops = xen_irq_ops;
 	x86_init.irqs.intr_init = xen_init_IRQ;
 }
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 95fb2aa..ea553c8 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -798,7 +798,7 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 {
 	unsigned topidx, mididx, idx;
 
-	if (unlikely(xen_feature(XENFEAT_auto_translated_physmap))) {
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
 		BUG_ON(pfn != mfn && mfn != INVALID_P2M_ENTRY);
 		return true;
 	}
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index f58dca7..cda1907 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -68,9 +68,11 @@ static void __cpuinit cpu_bringup(void)
 	touch_softlockup_watchdog();
 	preempt_disable();
 
-	xen_enable_sysenter();
-	xen_enable_syscall();
-
+	/* PVH runs in ring 0 and allows us to do native syscalls. Yay! */
+	if (!xen_feature(XENFEAT_supervisor_mode_kernel)) {
+		xen_enable_sysenter();
+		xen_enable_syscall();
+	}
 	cpu = smp_processor_id();
 	smp_store_cpu_info(cpu);
 	cpu_data(cpu).x86_max_cores = 1;
@@ -230,10 +232,11 @@ static void __init xen_smp_prepare_boot_cpu(void)
 	BUG_ON(smp_processor_id() != 0);
 	native_smp_prepare_boot_cpu();
 
-	/* We've switched to the "real" per-cpu gdt, so make sure the
-	   old memory can be recycled */
-	make_lowmem_page_readwrite(xen_initial_gdt);
-
+	if (!xen_feature(XENFEAT_writable_page_tables)) {
+		/* We've switched to the "real" per-cpu gdt, so make sure the
+		 * old memory can be recycled */
+		make_lowmem_page_readwrite(xen_initial_gdt);
+	}
 	xen_filter_cpu_maps();
 	xen_setup_vcpu_info_placement();
 }
@@ -300,8 +303,6 @@ cpu_initialize_context(unsigned int cpu, struct task_struct *idle)
 	gdt = get_cpu_gdt_table(cpu);
 
 	ctxt->flags = VGCF_IN_KERNEL;
-	ctxt->user_regs.ds = __USER_DS;
-	ctxt->user_regs.es = __USER_DS;
 	ctxt->user_regs.ss = __KERNEL_DS;
 #ifdef CONFIG_X86_32
 	ctxt->user_regs.fs = __KERNEL_PERCPU;
@@ -310,35 +311,57 @@ cpu_initialize_context(unsigned int cpu, struct task_struct *idle)
 	ctxt->gs_base_kernel = per_cpu_offset(cpu);
 #endif
 	ctxt->user_regs.eip = (unsigned long)cpu_bringup_and_idle;
-	ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
 
 	memset(&ctxt->fpu_ctxt, 0, sizeof(ctxt->fpu_ctxt));
 
-	xen_copy_trap_info(ctxt->trap_ctxt);
+	/* check for autoxlated to get it right for 32bit kernel */
+	if (xen_feature(XENFEAT_auto_translated_physmap) &&
+	    xen_feature(XENFEAT_supervisor_mode_kernel)) {
 
-	ctxt->ldt_ents = 0;
+		ctxt->user_regs.ds = __KERNEL_DS;
+		ctxt->user_regs.es = 0;
+		ctxt->user_regs.gs = 0;
 
-	BUG_ON((unsigned long)gdt & ~PAGE_MASK);
+		ctxt->u.pvh.gdtaddr = (unsigned long)gdt;
+		ctxt->u.pvh.gdtsz = (unsigned long)(GDT_SIZE - 1);
 
-	gdt_mfn = arbitrary_virt_to_mfn(gdt);
-	make_lowmem_page_readonly(gdt);
-	make_lowmem_page_readonly(mfn_to_virt(gdt_mfn));
+#ifdef CONFIG_X86_64
+		/* Note: PVH is not supported on x86_32. */
+		ctxt->gs_base_user = (unsigned long)
+					per_cpu(irq_stack_union.gs_base, cpu);
+#endif
+	} else {
+		ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
+		ctxt->user_regs.ds = __USER_DS;
+		ctxt->user_regs.es = __USER_DS;
 
-	ctxt->gdt_frames[0] = gdt_mfn;
-	ctxt->gdt_ents      = GDT_ENTRIES;
+		xen_copy_trap_info(ctxt->trap_ctxt);
 
-	ctxt->user_regs.cs = __KERNEL_CS;
-	ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct pt_regs);
+		ctxt->ldt_ents = 0;
 
-	ctxt->kernel_ss = __KERNEL_DS;
-	ctxt->kernel_sp = idle->thread.sp0;
+		BUG_ON((unsigned long)gdt & ~PAGE_MASK);
+
+		gdt_mfn = arbitrary_virt_to_mfn(gdt);
+		make_lowmem_page_readonly(gdt);
+		make_lowmem_page_readonly(mfn_to_virt(gdt_mfn));
+
+		ctxt->u.pv.gdt_frames[0] = gdt_mfn;
+		ctxt->u.pv.gdt_ents      = GDT_ENTRIES;
+
+		ctxt->kernel_ss = __KERNEL_DS;
+		ctxt->kernel_sp = idle->thread.sp0;
 
 #ifdef CONFIG_X86_32
-	ctxt->event_callback_cs     = __KERNEL_CS;
-	ctxt->failsafe_callback_cs  = __KERNEL_CS;
+		ctxt->event_callback_cs     = __KERNEL_CS;
+		ctxt->failsafe_callback_cs  = __KERNEL_CS;
 #endif
-	ctxt->event_callback_eip    = (unsigned long)xen_hypervisor_callback;
-	ctxt->failsafe_callback_eip = (unsigned long)xen_failsafe_callback;
+		ctxt->event_callback_eip    =
+					(unsigned long)xen_hypervisor_callback;
+		ctxt->failsafe_callback_eip =
+					(unsigned long)xen_failsafe_callback;
+	}
+	ctxt->user_regs.cs = __KERNEL_CS;
+	ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct pt_regs);
 
 	per_cpu(xen_cr3, cpu) = __pa(swapper_pg_dir);
 	ctxt->ctrlreg[3] = xen_pfn_to_cr3(virt_to_mfn(swapper_pg_dir));
diff --git a/drivers/xen/cpu_hotplug.c b/drivers/xen/cpu_hotplug.c
index 4dcfced..de6bcf9 100644
--- a/drivers/xen/cpu_hotplug.c
+++ b/drivers/xen/cpu_hotplug.c
@@ -2,6 +2,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -100,7 +101,8 @@ static int __init setup_vcpu_hotplug_event(void)
 	static struct notifier_block xsn_cpu = {
 		.notifier_call = setup_cpu_watcher };
 
-	if (!xen_pv_domain())
+	/* PVH TBD/FIXME: future work */
+	if (!xen_pv_domain() || xen_feature(XENFEAT_auto_translated_physmap))
 		return -ENODEV;
 
 	register_xenstore_notifier(&xsn_cpu);
diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index c60d162..a977612 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -1767,7 +1767,7 @@ int xen_set_callback_via(uint64_t via)
 }
 EXPORT_SYMBOL_GPL(xen_set_callback_via);
 
-#ifdef CONFIG_XEN_PVHVM
+#ifdef CONFIG_X86
 /* Vector callbacks are better than PCI interrupts to receive event
  * channel notifications because we can receive vector callbacks on any
  * vcpu and we don't need PCI support or APIC interactions. */
@@ -1826,6 +1826,13 @@ void __init xen_init_IRQ(void)
 		if (xen_initial_domain())
 			pci_xen_initial_domain();
 
+		if (xen_feature(XENFEAT_hvm_callback_vector)) {
+			xen_callback_vector();
+			return;
+		}
+
+		/* PVH: TBD/FIXME: debug and fix eio map to work with pvh */
+
 		pirq_eoi_map = (void *)__get_free_page(GFP_KERNEL|__GFP_ZERO);
 		eoi_gmfn.gmfn = virt_to_mfn(pirq_eoi_map);
 		rc = HYPERVISOR_physdev_op(PHYSDEVOP_pirq_eoi_gmfn_v2, &eoi_gmfn);
diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
index b3e146e..1bac743 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -44,6 +44,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "xenbus_probe.h"
 
@@ -743,7 +744,7 @@ static const struct xenbus_ring_ops ring_ops_hvm = {
 
 void __init xenbus_ring_ops_init(void)
 {
-	if (xen_pv_domain())
+	if (xen_pv_domain() && !xen_feature(XENFEAT_auto_translated_physmap))
 		ring_ops = &ring_ops_pv;
 	else
 		ring_ops = &ring_ops_hvm;
-- 
1.7.2.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 23:23:20 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 23:23:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOzQR-000156-KM; Thu, 18 Oct 2012 23:22:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOzQP-000151-Sc
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 23:22:50 +0000
Received: from [85.158.139.211:27955] by server-8.bemta-5.messagelabs.com id
	C6/F2-23193-94F80805; Thu, 18 Oct 2012 23:22:49 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1350602568!22422481!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 490 invoked from network); 18 Oct 2012 23:22:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 23:22:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,609,1344211200"; 
	d="asc'?scan'208";a="15265618"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 23:22:46 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 19 Oct 2012 00:22:44 +0100
Message-ID: <1350599732.26152.77.camel@Solace>
From: Dario Faggioli 
To: George Dunlap 
In-Reply-To: 
References: 
	<6d7a403305dd057f61bd.1350408388@Solace>
	
Date: Fri, 19 Oct 2012 00:35:32 +0200
MIME-Version: 1.0
X-Mailer: Evolution 3.4.3-1 
Cc: Andre Przywara ,
	Ian Jackson ,
	Ian Campbell , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3 of 3] xl: allow for node-wise
 specification of vcpu pinning
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============7202025049269973123=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7202025049269973123==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-Y/SO53KfmecvzmEBwZ5m"

--=-Y/SO53KfmecvzmEBwZ5m
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-10-18 at 16:30 +0100, George Dunlap wrote:
> On Tue, Oct 16, 2012 at 6:26 PM, Dario Faggioli
>  wrote:
> > Making it possible to use something like the following:
> >  * "nodes:0-3": all pCPUs of nodes 0,1,2,3;
> >  * "nodes:0-3,^node:2": all pCPUS of nodes 0,1,3;
> >  * "1,nodes:1-2,^6": pCPU 1 plus all pCPUs of nodes 1,2 but not pCPU 6;
> >  * ...
> >
> > In both domain config file and `xl vcpu-pin'.
> >
> > Signed-off-by: Dario Faggioli 
>=20
> Is it OK if I give this an "I'm OK with the idea but I'm too lazy to
> figure out if the parsing code is doing the right thing" Ack? :-)
>=20
Well, it's certainly ok with me... :-)

Actually, the new parsing code is nothing particularly sexy, and the
only relevant bit is the one IanC commented about, i.e., checking for a
"node:" substring at the beginning of each ',' separated element of the
original string.

That's it.

The reason why this requires this whole lot of + lines is that I need a
couple of nodemap where to store the data, and declaring, initializing,
allocating and freeing them requires that. :-(

Thanks and Regards,
Dario

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-Y/SO53KfmecvzmEBwZ5m
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlCAhDQACgkQk4XaBE3IOsTFSACfbt9glAKOeQ5HydPmgE/CLPJX
vCsAn0ahqhbyv5H9Qk1HJ2pvcT2KGlGE
=jo6f
-----END PGP SIGNATURE-----

--=-Y/SO53KfmecvzmEBwZ5m--


--===============7202025049269973123==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7202025049269973123==--


From xen-devel-bounces@lists.xen.org Thu Oct 18 23:23:20 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 23:23:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOzQR-000156-KM; Thu, 18 Oct 2012 23:22:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOzQP-000151-Sc
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 23:22:50 +0000
Received: from [85.158.139.211:27955] by server-8.bemta-5.messagelabs.com id
	C6/F2-23193-94F80805; Thu, 18 Oct 2012 23:22:49 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1350602568!22422481!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ3ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 490 invoked from network); 18 Oct 2012 23:22:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 23:22:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,609,1344211200"; 
	d="asc'?scan'208";a="15265618"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 23:22:46 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 19 Oct 2012 00:22:44 +0100
Message-ID: <1350599732.26152.77.camel@Solace>
From: Dario Faggioli 
To: George Dunlap 
In-Reply-To: 
References: 
	<6d7a403305dd057f61bd.1350408388@Solace>
	
Date: Fri, 19 Oct 2012 00:35:32 +0200
MIME-Version: 1.0
X-Mailer: Evolution 3.4.3-1 
Cc: Andre Przywara ,
	Ian Jackson ,
	Ian Campbell , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3 of 3] xl: allow for node-wise
 specification of vcpu pinning
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============7202025049269973123=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7202025049269973123==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-Y/SO53KfmecvzmEBwZ5m"

--=-Y/SO53KfmecvzmEBwZ5m
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-10-18 at 16:30 +0100, George Dunlap wrote:
> On Tue, Oct 16, 2012 at 6:26 PM, Dario Faggioli
>  wrote:
> > Making it possible to use something like the following:
> >  * "nodes:0-3": all pCPUs of nodes 0,1,2,3;
> >  * "nodes:0-3,^node:2": all pCPUS of nodes 0,1,3;
> >  * "1,nodes:1-2,^6": pCPU 1 plus all pCPUs of nodes 1,2 but not pCPU 6;
> >  * ...
> >
> > In both domain config file and `xl vcpu-pin'.
> >
> > Signed-off-by: Dario Faggioli 
>=20
> Is it OK if I give this an "I'm OK with the idea but I'm too lazy to
> figure out if the parsing code is doing the right thing" Ack? :-)
>=20
Well, it's certainly ok with me... :-)

Actually, the new parsing code is nothing particularly sexy, and the
only relevant bit is the one IanC commented about, i.e., checking for a
"node:" substring at the beginning of each ',' separated element of the
original string.

That's it.

The reason why this requires this whole lot of + lines is that I need a
couple of nodemap where to store the data, and declaring, initializing,
allocating and freeing them requires that. :-(

Thanks and Regards,
Dario

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-Y/SO53KfmecvzmEBwZ5m
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlCAhDQACgkQk4XaBE3IOsTFSACfbt9glAKOeQ5HydPmgE/CLPJX
vCsAn0ahqhbyv5H9Qk1HJ2pvcT2KGlGE
=jo6f
-----END PGP SIGNATURE-----

--=-Y/SO53KfmecvzmEBwZ5m--


--===============7202025049269973123==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7202025049269973123==--


From xen-devel-bounces@lists.xen.org Thu Oct 18 23:23:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 23:23:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOzQW-00015P-14; Thu, 18 Oct 2012 23:22:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOzQV-00015F-9S
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 23:22:55 +0000
Received: from [85.158.139.211:28088] by server-13.bemta-5.messagelabs.com id
	E5/FA-30674-E4F80805; Thu, 18 Oct 2012 23:22:54 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1350602573!22860984!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ5MzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15080 invoked from network); 18 Oct 2012 23:22:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 23:22:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,609,1344211200"; 
	d="asc'?scan'208";a="15265619"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 23:22:53 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 19 Oct 2012 00:22:53 +0100
Message-ID: <1350602433.26152.106.camel@Solace>
From: Dario Faggioli 
To: George Dunlap 
In-Reply-To: 
References: 
	
	
Date: Fri, 19 Oct 2012 01:20:33 +0200
MIME-Version: 1.0
X-Mailer: Evolution 3.4.3-1 
Cc: Andre Przywara ,
	Ian Campbell ,
	Stefano Stabellini ,
	Juergen Gross ,
	Ian Jackson ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 1 of 3] libxl: take node distances into
 account during NUMA placement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============5294901881647590138=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5294901881647590138==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-9tJFK9bD/u2CbAXmdpFr"

--=-9tJFK9bD/u2CbAXmdpFr
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-10-18 at 16:17 +0100, George Dunlap wrote:
> On Tue, Oct 16, 2012 at 6:26 PM, Dario Faggioli
>  wrote:
> > In fact, among placement candidates with the same number of nodes, the
> > closer the various nodes are to each others, the better the performance=
s
> > for a domain placed there.
>=20
> Looks good overall -- my only worry is the N^2 nature of the
> algorithm.  We're already doing some big combinatorial thing to
> generate the candidates, right? =20
>
It is, with N being the number of nodes, which we discussed thoroughly
already a couple of months ago, and reached consensus on the fact that N
will stay less than 8 for the next 5 (but probably even more) years. :-)

In any case, if something really unexpected happens, and N jumps to
anything bigger than 16, the placement algorithm won't even start, and
we'll never reach this point!.

Moreover, given the number we're playing with, I don't think this
specific patch is adding much complexity, as we already have the
function that counts the number of vCPUs (as it was for xend) bound to a
candidate, which is Ndoms*Nvcpus, and we're very likely going o have
much more domains than nodes. :-)

> And now we're doing N^2 for each
> candidate?=20
>
Again, yes, but that is turning it from Ndoms*Nvcpus to
Ndoms*Nvcpus+Nnodes^2, which is still dominated by the first term. IIRC,
Andre tried to start >50 domains with 2 vCPUs on a 8 nodes system, which
means 50*2 vs 8*8.

> Suppose we get an ARM system with 4096 cores and 128 NUMA
> nodes?  If Xen 4.4 doesn't come out until March 2014, there will still
> be distros using 4.3 through mid-2015.
>=20
Right, but I really don't think that monster is actually made out of
4096 cores arranged in 128 _NUMA_ nodes on which you run the same
instance of the hypervisor.

I also recall hearing the numbers and the use of the word "node", but I
really think they was rather referred to a cluster architecture where "a
node" means something more like "a server", each one running their copy
of Xen (although they'll be packed all together in the same rack,
talking via some super-fast interconnect).
I'm pretty sure I remember Stefano speculating about the need to use
some orchestration layer (like {Cloud,Open}Stack) _within_ those big
irons to deal exactly with that... Stefano, am I talking nonsense? :-D

Finally, allow me to say that the whole placement algorithm already
interacts quite nicely with cpupools. Thus, even in the unlikely event
of an actual 128 NUMA nodes machine, you can have, say, 16 cpupools with
8 nodes each (or vice versa), and the algorithm will be back dealing
with _no_more_than_ 8 (or 16) nodes. Yes, right now this would require
for someone to manually setup the pools and decide which domain to put
where. However, it would be very very easy to add, at that point,
something doing this pooling and more coarse placing automatically (and
quickly). In fact, we can even think about having it for 4.3, if you
really believe it's necessary.

> I seem to remember having a discussion about this issue already, but I
> can't remember what the outcome was...
>=20
Yep, we did, and the outcome was right what I tried to summarize
above. :-)

Thanks and Regards,
Dario

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-9tJFK9bD/u2CbAXmdpFr
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlCAjsEACgkQk4XaBE3IOsRFTQCgr1AfcmhHdRppaow6h7qWlaRS
2U8AoJ/7UxvQ7eOm7Suaum11EC2s0w89
=g0s+
-----END PGP SIGNATURE-----

--=-9tJFK9bD/u2CbAXmdpFr--


--===============5294901881647590138==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5294901881647590138==--


From xen-devel-bounces@lists.xen.org Thu Oct 18 23:23:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 23:23:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOzQW-00015P-14; Thu, 18 Oct 2012 23:22:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOzQV-00015F-9S
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 23:22:55 +0000
Received: from [85.158.139.211:28088] by server-13.bemta-5.messagelabs.com id
	E5/FA-30674-E4F80805; Thu, 18 Oct 2012 23:22:54 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1350602573!22860984!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ5MzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15080 invoked from network); 18 Oct 2012 23:22:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 23:22:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,609,1344211200"; 
	d="asc'?scan'208";a="15265619"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 23:22:53 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 19 Oct 2012 00:22:53 +0100
Message-ID: <1350602433.26152.106.camel@Solace>
From: Dario Faggioli 
To: George Dunlap 
In-Reply-To: 
References: 
	
	
Date: Fri, 19 Oct 2012 01:20:33 +0200
MIME-Version: 1.0
X-Mailer: Evolution 3.4.3-1 
Cc: Andre Przywara ,
	Ian Campbell ,
	Stefano Stabellini ,
	Juergen Gross ,
	Ian Jackson ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 1 of 3] libxl: take node distances into
 account during NUMA placement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============5294901881647590138=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5294901881647590138==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-9tJFK9bD/u2CbAXmdpFr"

--=-9tJFK9bD/u2CbAXmdpFr
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-10-18 at 16:17 +0100, George Dunlap wrote:
> On Tue, Oct 16, 2012 at 6:26 PM, Dario Faggioli
>  wrote:
> > In fact, among placement candidates with the same number of nodes, the
> > closer the various nodes are to each others, the better the performance=
s
> > for a domain placed there.
>=20
> Looks good overall -- my only worry is the N^2 nature of the
> algorithm.  We're already doing some big combinatorial thing to
> generate the candidates, right? =20
>
It is, with N being the number of nodes, which we discussed thoroughly
already a couple of months ago, and reached consensus on the fact that N
will stay less than 8 for the next 5 (but probably even more) years. :-)

In any case, if something really unexpected happens, and N jumps to
anything bigger than 16, the placement algorithm won't even start, and
we'll never reach this point!.

Moreover, given the number we're playing with, I don't think this
specific patch is adding much complexity, as we already have the
function that counts the number of vCPUs (as it was for xend) bound to a
candidate, which is Ndoms*Nvcpus, and we're very likely going o have
much more domains than nodes. :-)

> And now we're doing N^2 for each
> candidate?=20
>
Again, yes, but that is turning it from Ndoms*Nvcpus to
Ndoms*Nvcpus+Nnodes^2, which is still dominated by the first term. IIRC,
Andre tried to start >50 domains with 2 vCPUs on a 8 nodes system, which
means 50*2 vs 8*8.

> Suppose we get an ARM system with 4096 cores and 128 NUMA
> nodes?  If Xen 4.4 doesn't come out until March 2014, there will still
> be distros using 4.3 through mid-2015.
>=20
Right, but I really don't think that monster is actually made out of
4096 cores arranged in 128 _NUMA_ nodes on which you run the same
instance of the hypervisor.

I also recall hearing the numbers and the use of the word "node", but I
really think they was rather referred to a cluster architecture where "a
node" means something more like "a server", each one running their copy
of Xen (although they'll be packed all together in the same rack,
talking via some super-fast interconnect).
I'm pretty sure I remember Stefano speculating about the need to use
some orchestration layer (like {Cloud,Open}Stack) _within_ those big
irons to deal exactly with that... Stefano, am I talking nonsense? :-D

Finally, allow me to say that the whole placement algorithm already
interacts quite nicely with cpupools. Thus, even in the unlikely event
of an actual 128 NUMA nodes machine, you can have, say, 16 cpupools with
8 nodes each (or vice versa), and the algorithm will be back dealing
with _no_more_than_ 8 (or 16) nodes. Yes, right now this would require
for someone to manually setup the pools and decide which domain to put
where. However, it would be very very easy to add, at that point,
something doing this pooling and more coarse placing automatically (and
quickly). In fact, we can even think about having it for 4.3, if you
really believe it's necessary.

> I seem to remember having a discussion about this issue already, but I
> can't remember what the outcome was...
>=20
Yep, we did, and the outcome was right what I tried to summarize
above. :-)

Thanks and Regards,
Dario

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-9tJFK9bD/u2CbAXmdpFr
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlCAjsEACgkQk4XaBE3IOsRFTQCgr1AfcmhHdRppaow6h7qWlaRS
2U8AoJ/7UxvQ7eOm7Suaum11EC2s0w89
=g0s+
-----END PGP SIGNATURE-----

--=-9tJFK9bD/u2CbAXmdpFr--


--===============5294901881647590138==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5294901881647590138==--


From xen-devel-bounces@lists.xen.org Thu Oct 18 23:30:13 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 23:30:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOzXB-0001Mx-1A; Thu, 18 Oct 2012 23:29:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOzX9-0001Mo-Qh
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 23:29:48 +0000
Received: from [85.158.138.51:33025] by server-7.bemta-3.messagelabs.com id
	BF/40-06991-AE090805; Thu, 18 Oct 2012 23:29:46 +0000
X-Env-Sender: ronny.hegewald@online.de
X-Msg-Ref: server-4.tower-174.messagelabs.com!1350602986!34420288!1
X-Originating-IP: [212.227.17.8]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjE3LjggPT4gODUwMzY=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjE3LjggPT4gODUwMzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 453 invoked from network); 18 Oct 2012 23:29:46 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.17.8)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 23:29:46 -0000
Received: from server2-groupware.localnet (p4FEF8E9C.dip0.t-ipconnect.de
	[79.239.142.156])
	by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis)
	id 0Mfwoa-1Tm95f1YWK-00NBQf; Fri, 19 Oct 2012 01:29:46 +0200
From: Ronny Hegewald 
To: xen-devel@lists.xen.org
Date: Fri, 19 Oct 2012 00:35:13 +0000
User-Agent: KMail/1.11.4 (Linux/3.0.3; KDE/4.2.4; i686; ; )
References: <201210180049.56561.ronny.hegewald@online.de>
	<507FC9E202000078000A237E@nat28.tlf.novell.com>
In-Reply-To: <507FC9E202000078000A237E@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
Message-Id: <201210190035.13872.ronny.hegewald@online.de>
X-Provags-ID: V02:K0:tKmXI9XpYRO17YVyBVlmU3B396H/UnkOexnYmhmAQAT
	+i25ofiAids1STXF30Ojnap95rSsIHk9Xz2WjZYMPDDQKIzEia
	oQXV2dlv1Rt+QI78DEJCvaoqeXCyAJO7zJshUb11uXPC4nHx0O
	1mwKJgwNScdWzp+RIgT/pMKo9BWvEEmvZnBUcTv8w+ruyIoWCa
	XB+5zQ/XZyDxRlaSTEH2e9Y5TYMGc8+6hEW8XN0+A+8YS8okp8
	+E7Gu8Qfzhk9E6Hfv/U7xZEi6DFafqwrNZ4q7Gz/oPrJsm9S8Q
	up57WE2bXKIBJgEsz+qYT2OAsyAdHuq5bx9qF597EPMzfCIA63
	VALYmp+IFr3ZPXrrwYd5QY9T0x90LI6TjFViz4OOphvwXanipe
	vn9AhxS+W3PdCoA69pAGAK/4yXA3eeooUw=
Cc: Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 1/1] keep iommu disabled until iommu_setup
	is called
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> The concept is plausible, but I'm not convinced that there aren't
> any users of iommu_enabled that actually depend on it having
> its final value after command line parsing, yet before
> iommu_setup() gets called. 

But that is currently only true for systems with a iommu. For the ones without 
one have iommu_enabled=1 first, until iommu_setup() is called and 
iommu_enabled is set to 0 because of the not detectable iommu.

So, with or without my patch, a similiar problem seems to be present, just for 
different systems.

> Did you fully audit all users?

No, because there is just no way i can make a meaningfull judgement how the 
iommu code interdepends with all the other parts that check iommu_enabled. 

> As to the patch itself, ...

I will send a 2. version which addresses your comments as soon its clear if 
the approach in the patch is the right one to fix the crash.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 23:30:13 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 23:30:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOzXB-0001Mx-1A; Thu, 18 Oct 2012 23:29:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOzX9-0001Mo-Qh
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 23:29:48 +0000
Received: from [85.158.138.51:33025] by server-7.bemta-3.messagelabs.com id
	BF/40-06991-AE090805; Thu, 18 Oct 2012 23:29:46 +0000
X-Env-Sender: ronny.hegewald@online.de
X-Msg-Ref: server-4.tower-174.messagelabs.com!1350602986!34420288!1
X-Originating-IP: [212.227.17.8]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjE3LjggPT4gODUwMzY=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjE3LjggPT4gODUwMzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 453 invoked from network); 18 Oct 2012 23:29:46 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.17.8)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 23:29:46 -0000
Received: from server2-groupware.localnet (p4FEF8E9C.dip0.t-ipconnect.de
	[79.239.142.156])
	by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis)
	id 0Mfwoa-1Tm95f1YWK-00NBQf; Fri, 19 Oct 2012 01:29:46 +0200
From: Ronny Hegewald 
To: xen-devel@lists.xen.org
Date: Fri, 19 Oct 2012 00:35:13 +0000
User-Agent: KMail/1.11.4 (Linux/3.0.3; KDE/4.2.4; i686; ; )
References: <201210180049.56561.ronny.hegewald@online.de>
	<507FC9E202000078000A237E@nat28.tlf.novell.com>
In-Reply-To: <507FC9E202000078000A237E@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
Message-Id: <201210190035.13872.ronny.hegewald@online.de>
X-Provags-ID: V02:K0:tKmXI9XpYRO17YVyBVlmU3B396H/UnkOexnYmhmAQAT
	+i25ofiAids1STXF30Ojnap95rSsIHk9Xz2WjZYMPDDQKIzEia
	oQXV2dlv1Rt+QI78DEJCvaoqeXCyAJO7zJshUb11uXPC4nHx0O
	1mwKJgwNScdWzp+RIgT/pMKo9BWvEEmvZnBUcTv8w+ruyIoWCa
	XB+5zQ/XZyDxRlaSTEH2e9Y5TYMGc8+6hEW8XN0+A+8YS8okp8
	+E7Gu8Qfzhk9E6Hfv/U7xZEi6DFafqwrNZ4q7Gz/oPrJsm9S8Q
	up57WE2bXKIBJgEsz+qYT2OAsyAdHuq5bx9qF597EPMzfCIA63
	VALYmp+IFr3ZPXrrwYd5QY9T0x90LI6TjFViz4OOphvwXanipe
	vn9AhxS+W3PdCoA69pAGAK/4yXA3eeooUw=
Cc: Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 1/1] keep iommu disabled until iommu_setup
	is called
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> The concept is plausible, but I'm not convinced that there aren't
> any users of iommu_enabled that actually depend on it having
> its final value after command line parsing, yet before
> iommu_setup() gets called. 

But that is currently only true for systems with a iommu. For the ones without 
one have iommu_enabled=1 first, until iommu_setup() is called and 
iommu_enabled is set to 0 because of the not detectable iommu.

So, with or without my patch, a similiar problem seems to be present, just for 
different systems.

> Did you fully audit all users?

No, because there is just no way i can make a meaningfull judgement how the 
iommu code interdepends with all the other parts that check iommu_enabled. 

> As to the patch itself, ...

I will send a 2. version which addresses your comments as soon its clear if 
the approach in the patch is the right one to fix the crash.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 23:35:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 23:35:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOzcO-0001Zz-3T; Thu, 18 Oct 2012 23:35:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOzcN-0001Zl-1B
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 23:35:11 +0000
Received: from [85.158.139.83:30875] by server-14.bemta-5.messagelabs.com id
	65/15-24068-E2290805; Thu, 18 Oct 2012 23:35:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1350603308!31235876!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ5MzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 614 invoked from network); 18 Oct 2012 23:35:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 23:35:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,609,1344211200"; d="scan'208";a="15265687"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 23:34:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 19 Oct 2012 00:34:47 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TOzbz-0002vL-9Q;
	Thu, 18 Oct 2012 23:34:47 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TOzbz-0007oT-8o;
	Fri, 19 Oct 2012 00:34:47 +0100
To: 
Message-ID: 
From: xen.org 
Date: Fri, 19 Oct 2012 00:34:47 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete test-amd64-i386-pair
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-pair
test xen-boot/src_host

Tree: linux git://xenbits.xen.org/linux-pvops.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 http://xenbits.xen.org/hg/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
  Bug introduced:  4fc87c2f31a0
  Bug not present: c1c549c4fe9e


  changeset:   26060:4fc87c2f31a0
  user:        Huang Ying 
  date:        Tue Oct 16 17:26:36 2012 +0200
      
      ACPI: fix APEI related table size checking
      
      On Huang Ying's machine:
      
      erst_tab->header_length == sizeof(struct acpi_table_einj)
      
      but Yinghai reported that on his machine,
      
      erst_tab->header_length == sizeof(struct acpi_table_einj) -
      sizeof(struct acpi_table_header)
      
      To make erst table size checking code works on all systems, both
      testing are treated as PASS.
      
      Same situation applies to einj_tab->header_length, so corresponding
      table size checking is changed in similar way too.
      
      Originally-by: Yinghai Lu 
      Signed-off-by: Huang Ying 
      
      - use switch() for better readability
      - add comment explaining why a formally invalid size it also being
        accepted
      - check erst_tab->header.length before even looking at
        erst_tab->header_length
      - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
      
      Signed-off-by: Jan Beulich 
      Acked-by: Keir Fraser 
      Committed-by: Jan Beulich 
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-i386-pair.xen-boot--src_host.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 14038 fail [dst_host=leaf-beetle,src_host=potato-beetle] / 13967 [dst_host=bush-cricket,src_host=field-cricket] 13963 [dst_host=potato-beetle,src_host=leaf-beetle] 13962 [dst_host=itch-mite,src_host=gall-mite] 13960 [dst_host=lace-bug,src_host=moss-bug] 13958 [dst_host=bush-cricket,src_host=field-cricket] 13956 [dst_host=gall-mite,src_host=itch-mite] 13953 [dst_host=potato-beetle,src_host=leaf-beetle] 13952 ok.
Failure / basis pass flights: 14038 / 13952
Tree: linux git://xenbits.xen.org/linux-pvops.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 http://xenbits.xen.org/hg/staging/xen-unstable.hg
Latest a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 3fa2ab30bb05
Basis pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 b91f57f54f47
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#a938a246d34912423c560f475ccf1ce0c71d9d00-a938a246d34912423c560f475ccf1ce0c71d9d00 git://xenbits.xen.org/staging/qemu-xen-unstable.git#bacc0d302445c75f18f4c826750fb5853b60e7ca-bacc0d302445c75f18f4c826750fb5853b60e7ca git://xenbits.xen.org/staging/qemu-upstream-unstable.git#cdf4d2bb4006805f209712fbb8ed1f83127e9984-cdf4d2bb4006805f209712fbb8ed1f83127e9984 http://xenbits.xen.org/hg/staging/xen-unstable.hg#b91f57f54f47-3fa2ab30bb05
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
Loaded 270 nodes in revision graph
Searching for test results:
 13958 [dst_host=bush-cricket,src_host=field-cricket]
 13960 [dst_host=lace-bug,src_host=moss-bug]
 13967 [dst_host=bush-cricket,src_host=field-cricket]
 13962 [dst_host=itch-mite,src_host=gall-mite]
 13972 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 13952 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 b91f57f54f47
 13963 [dst_host=potato-beetle,src_host=leaf-beetle]
 13953 [dst_host=potato-beetle,src_host=leaf-beetle]
 13956 [dst_host=gall-mite,src_host=itch-mite]
 13964 []
 13973 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 13979 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 13995 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4b4c0c7a6031
 14001 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 1f4be6ee4619
 14007 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 5c402b905e00
 14039 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 b91f57f54f47
 14040 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 3fa2ab30bb05
 14041 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 137dfbd3190e
 14011 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 5c402b905e00
 14042 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 177fdda0be56
 14043 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 37bb894121c7
 14017 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 5c402b905e00
 14038 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 3fa2ab30bb05
 14044 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
 14046 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 14047 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
 14048 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 14049 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
 14050 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 14032 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 3fa2ab30bb05
Searching for interesting versions
 Result found: flight 13952 (pass), for basis pass
 Result found: flight 14032 (fail), for basis failure
 Repro found: flight 14039 (pass), for basis pass
 Repro found: flight 14040 (fail), for basis failure
 0 revisions at a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
No revisions left to test, checking graph state.
 Result found: flight 14044 (pass), for last pass
 Result found: flight 14046 (fail), for first failure
 Repro found: flight 14047 (pass), for last pass
 Repro found: flight 14048 (fail), for first failure
 Repro found: flight 14049 (pass), for last pass
 Repro found: flight 14050 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
  Bug introduced:  4fc87c2f31a0
  Bug not present: c1c549c4fe9e

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   26060:4fc87c2f31a0
  user:        Huang Ying 
  date:        Tue Oct 16 17:26:36 2012 +0200
      
      ACPI: fix APEI related table size checking
      
      On Huang Ying's machine:
      
      erst_tab->header_length == sizeof(struct acpi_table_einj)
      
      but Yinghai reported that on his machine,
      
      erst_tab->header_length == sizeof(struct acpi_table_einj) -
      sizeof(struct acpi_table_header)
      
      To make erst table size checking code works on all systems, both
      testing are treated as PASS.
      
      Same situation applies to einj_tab->header_length, so corresponding
      table size checking is changed in similar way too.
      
      Originally-by: Yinghai Lu 
      Signed-off-by: Huang Ying 
      
      - use switch() for better readability
      - add comment explaining why a formally invalid size it also being
        accepted
      - check erst_tab->header.length before even looking at
        erst_tab->header_length
      - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
      
      Signed-off-by: Jan Beulich 
      Acked-by: Keir Fraser 
      Committed-by: Jan Beulich 
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-amd64-i386-pair.xen-boot--src_host.{dot,ps,png,html}.
No revision to test.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 23:35:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 23:35:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOzcO-0001Zz-3T; Thu, 18 Oct 2012 23:35:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOzcN-0001Zl-1B
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 23:35:11 +0000
Received: from [85.158.139.83:30875] by server-14.bemta-5.messagelabs.com id
	65/15-24068-E2290805; Thu, 18 Oct 2012 23:35:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1350603308!31235876!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ5MzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 614 invoked from network); 18 Oct 2012 23:35:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 23:35:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,609,1344211200"; d="scan'208";a="15265687"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 23:34:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 19 Oct 2012 00:34:47 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TOzbz-0002vL-9Q;
	Thu, 18 Oct 2012 23:34:47 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TOzbz-0007oT-8o;
	Fri, 19 Oct 2012 00:34:47 +0100
To: 
Message-ID: 
From: xen.org 
Date: Fri, 19 Oct 2012 00:34:47 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete test-amd64-i386-pair
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-pair
test xen-boot/src_host

Tree: linux git://xenbits.xen.org/linux-pvops.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 http://xenbits.xen.org/hg/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
  Bug introduced:  4fc87c2f31a0
  Bug not present: c1c549c4fe9e


  changeset:   26060:4fc87c2f31a0
  user:        Huang Ying 
  date:        Tue Oct 16 17:26:36 2012 +0200
      
      ACPI: fix APEI related table size checking
      
      On Huang Ying's machine:
      
      erst_tab->header_length == sizeof(struct acpi_table_einj)
      
      but Yinghai reported that on his machine,
      
      erst_tab->header_length == sizeof(struct acpi_table_einj) -
      sizeof(struct acpi_table_header)
      
      To make erst table size checking code works on all systems, both
      testing are treated as PASS.
      
      Same situation applies to einj_tab->header_length, so corresponding
      table size checking is changed in similar way too.
      
      Originally-by: Yinghai Lu 
      Signed-off-by: Huang Ying 
      
      - use switch() for better readability
      - add comment explaining why a formally invalid size it also being
        accepted
      - check erst_tab->header.length before even looking at
        erst_tab->header_length
      - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
      
      Signed-off-by: Jan Beulich 
      Acked-by: Keir Fraser 
      Committed-by: Jan Beulich 
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-i386-pair.xen-boot--src_host.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 14038 fail [dst_host=leaf-beetle,src_host=potato-beetle] / 13967 [dst_host=bush-cricket,src_host=field-cricket] 13963 [dst_host=potato-beetle,src_host=leaf-beetle] 13962 [dst_host=itch-mite,src_host=gall-mite] 13960 [dst_host=lace-bug,src_host=moss-bug] 13958 [dst_host=bush-cricket,src_host=field-cricket] 13956 [dst_host=gall-mite,src_host=itch-mite] 13953 [dst_host=potato-beetle,src_host=leaf-beetle] 13952 ok.
Failure / basis pass flights: 14038 / 13952
Tree: linux git://xenbits.xen.org/linux-pvops.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 http://xenbits.xen.org/hg/staging/xen-unstable.hg
Latest a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 3fa2ab30bb05
Basis pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 b91f57f54f47
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#a938a246d34912423c560f475ccf1ce0c71d9d00-a938a246d34912423c560f475ccf1ce0c71d9d00 git://xenbits.xen.org/staging/qemu-xen-unstable.git#bacc0d302445c75f18f4c826750fb5853b60e7ca-bacc0d302445c75f18f4c826750fb5853b60e7ca git://xenbits.xen.org/staging/qemu-upstream-unstable.git#cdf4d2bb4006805f209712fbb8ed1f83127e9984-cdf4d2bb4006805f209712fbb8ed1f83127e9984 http://xenbits.xen.org/hg/staging/xen-unstable.hg#b91f57f54f47-3fa2ab30bb05
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
Loaded 270 nodes in revision graph
Searching for test results:
 13958 [dst_host=bush-cricket,src_host=field-cricket]
 13960 [dst_host=lace-bug,src_host=moss-bug]
 13967 [dst_host=bush-cricket,src_host=field-cricket]
 13962 [dst_host=itch-mite,src_host=gall-mite]
 13972 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 13952 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 b91f57f54f47
 13963 [dst_host=potato-beetle,src_host=leaf-beetle]
 13953 [dst_host=potato-beetle,src_host=leaf-beetle]
 13956 [dst_host=gall-mite,src_host=itch-mite]
 13964 []
 13973 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 13979 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 13995 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4b4c0c7a6031
 14001 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 1f4be6ee4619
 14007 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 5c402b905e00
 14039 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 b91f57f54f47
 14040 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 3fa2ab30bb05
 14041 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 137dfbd3190e
 14011 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 5c402b905e00
 14042 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 177fdda0be56
 14043 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 37bb894121c7
 14017 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 5c402b905e00
 14038 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 3fa2ab30bb05
 14044 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
 14046 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 14047 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
 14048 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 14049 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
 14050 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 14032 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 3fa2ab30bb05
Searching for interesting versions
 Result found: flight 13952 (pass), for basis pass
 Result found: flight 14032 (fail), for basis failure
 Repro found: flight 14039 (pass), for basis pass
 Repro found: flight 14040 (fail), for basis failure
 0 revisions at a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
No revisions left to test, checking graph state.
 Result found: flight 14044 (pass), for last pass
 Result found: flight 14046 (fail), for first failure
 Repro found: flight 14047 (pass), for last pass
 Repro found: flight 14048 (fail), for first failure
 Repro found: flight 14049 (pass), for last pass
 Repro found: flight 14050 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
  Bug introduced:  4fc87c2f31a0
  Bug not present: c1c549c4fe9e

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   26060:4fc87c2f31a0
  user:        Huang Ying 
  date:        Tue Oct 16 17:26:36 2012 +0200
      
      ACPI: fix APEI related table size checking
      
      On Huang Ying's machine:
      
      erst_tab->header_length == sizeof(struct acpi_table_einj)
      
      but Yinghai reported that on his machine,
      
      erst_tab->header_length == sizeof(struct acpi_table_einj) -
      sizeof(struct acpi_table_header)
      
      To make erst table size checking code works on all systems, both
      testing are treated as PASS.
      
      Same situation applies to einj_tab->header_length, so corresponding
      table size checking is changed in similar way too.
      
      Originally-by: Yinghai Lu 
      Signed-off-by: Huang Ying 
      
      - use switch() for better readability
      - add comment explaining why a formally invalid size it also being
        accepted
      - check erst_tab->header.length before even looking at
        erst_tab->header_length
      - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
      
      Signed-off-by: Jan Beulich 
      Acked-by: Keir Fraser 
      Committed-by: Jan Beulich 
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-amd64-i386-pair.xen-boot--src_host.{dot,ps,png,html}.
No revision to test.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 23:35:34 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 23:35:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOzcO-0001a6-Fg; Thu, 18 Oct 2012 23:35:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOzcN-0001Zm-AF
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 23:35:11 +0000
Received: from [85.158.139.83:30880] by server-15.bemta-5.messagelabs.com id
	93/D2-28599-E2290805; Thu, 18 Oct 2012 23:35:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1350603308!31235876!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ5MzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 617 invoked from network); 18 Oct 2012 23:35:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 23:35:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,609,1344211200"; d="scan'208";a="15265686"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 23:34:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 19 Oct 2012 00:34:29 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TOzbh-0002vE-EN;
	Thu, 18 Oct 2012 23:34:29 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TOzbh-0007im-DE;
	Fri, 19 Oct 2012 00:34:29 +0100
To: 
Message-ID: 
From: xen.org 
Date: Fri, 19 Oct 2012 00:34:29 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete test-amd64-i386-pair
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-pair
test xen-boot/dst_host

Tree: linux git://xenbits.xen.org/linux-pvops.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 http://xenbits.xen.org/hg/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
  Bug introduced:  4fc87c2f31a0
  Bug not present: c1c549c4fe9e


  changeset:   26060:4fc87c2f31a0
  user:        Huang Ying 
  date:        Tue Oct 16 17:26:36 2012 +0200
      
      ACPI: fix APEI related table size checking
      
      On Huang Ying's machine:
      
      erst_tab->header_length == sizeof(struct acpi_table_einj)
      
      but Yinghai reported that on his machine,
      
      erst_tab->header_length == sizeof(struct acpi_table_einj) -
      sizeof(struct acpi_table_header)
      
      To make erst table size checking code works on all systems, both
      testing are treated as PASS.
      
      Same situation applies to einj_tab->header_length, so corresponding
      table size checking is changed in similar way too.
      
      Originally-by: Yinghai Lu 
      Signed-off-by: Huang Ying 
      
      - use switch() for better readability
      - add comment explaining why a formally invalid size it also being
        accepted
      - check erst_tab->header.length before even looking at
        erst_tab->header_length
      - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
      
      Signed-off-by: Jan Beulich 
      Acked-by: Keir Fraser 
      Committed-by: Jan Beulich 
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-i386-pair.xen-boot--dst_host.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 14038 fail [dst_host=leaf-beetle,src_host=potato-beetle] / 13967 [dst_host=bush-cricket,src_host=field-cricket] 13963 [dst_host=potato-beetle,src_host=leaf-beetle] 13962 [dst_host=itch-mite,src_host=gall-mite] 13960 [dst_host=lace-bug,src_host=moss-bug] 13958 [dst_host=bush-cricket,src_host=field-cricket] 13956 [dst_host=gall-mite,src_host=itch-mite] 13953 [dst_host=potato-beetle,src_host=leaf-beetle] 13952 ok.
Failure / basis pass flights: 14038 / 13952
Tree: linux git://xenbits.xen.org/linux-pvops.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 http://xenbits.xen.org/hg/staging/xen-unstable.hg
Latest a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 3fa2ab30bb05
Basis pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 b91f57f54f47
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#a938a246d34912423c560f475ccf1ce0c71d9d00-a938a246d34912423c560f475ccf1ce0c71d9d00 git://xenbits.xen.org/staging/qemu-xen-unstable.git#bacc0d302445c75f18f4c826750fb5853b60e7ca-bacc0d302445c75f18f4c826750fb5853b60e7ca git://xenbits.xen.org/staging/qemu-upstream-unstable.git#cdf4d2bb4006805f209712fbb8ed1f83127e9984-cdf4d2bb4006805f209712fbb8ed1f83127e9984 http://xenbits.xen.org/hg/staging/xen-unstable.hg#b91f57f54f47-3fa2ab30bb05
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
Loaded 270 nodes in revision graph
Searching for test results:
 13958 [dst_host=bush-cricket,src_host=field-cricket]
 13960 [dst_host=lace-bug,src_host=moss-bug]
 13967 [dst_host=bush-cricket,src_host=field-cricket]
 13962 [dst_host=itch-mite,src_host=gall-mite]
 13972 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 13952 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 b91f57f54f47
 13963 [dst_host=potato-beetle,src_host=leaf-beetle]
 13953 [dst_host=potato-beetle,src_host=leaf-beetle]
 13956 [dst_host=gall-mite,src_host=itch-mite]
 13964 []
 13973 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 13979 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 13995 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4b4c0c7a6031
 14001 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 1f4be6ee4619
 14007 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 5c402b905e00
 14039 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 b91f57f54f47
 14040 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 3fa2ab30bb05
 14041 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 137dfbd3190e
 14011 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 5c402b905e00
 14042 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 177fdda0be56
 14043 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 37bb894121c7
 14017 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 5c402b905e00
 14038 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 3fa2ab30bb05
 14044 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
 14046 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 14047 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
 14048 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 14049 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
 14050 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 14032 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 3fa2ab30bb05
Searching for interesting versions
 Result found: flight 13952 (pass), for basis pass
 Result found: flight 14032 (fail), for basis failure
 Repro found: flight 14039 (pass), for basis pass
 Repro found: flight 14040 (fail), for basis failure
 0 revisions at a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
No revisions left to test, checking graph state.
 Result found: flight 14044 (pass), for last pass
 Result found: flight 14046 (fail), for first failure
 Repro found: flight 14047 (pass), for last pass
 Repro found: flight 14048 (fail), for first failure
 Repro found: flight 14049 (pass), for last pass
 Repro found: flight 14050 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
  Bug introduced:  4fc87c2f31a0
  Bug not present: c1c549c4fe9e

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   26060:4fc87c2f31a0
  user:        Huang Ying 
  date:        Tue Oct 16 17:26:36 2012 +0200
      
      ACPI: fix APEI related table size checking
      
      On Huang Ying's machine:
      
      erst_tab->header_length == sizeof(struct acpi_table_einj)
      
      but Yinghai reported that on his machine,
      
      erst_tab->header_length == sizeof(struct acpi_table_einj) -
      sizeof(struct acpi_table_header)
      
      To make erst table size checking code works on all systems, both
      testing are treated as PASS.
      
      Same situation applies to einj_tab->header_length, so corresponding
      table size checking is changed in similar way too.
      
      Originally-by: Yinghai Lu 
      Signed-off-by: Huang Ying 
      
      - use switch() for better readability
      - add comment explaining why a formally invalid size it also being
        accepted
      - check erst_tab->header.length before even looking at
        erst_tab->header_length
      - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
      
      Signed-off-by: Jan Beulich 
      Acked-by: Keir Fraser 
      Committed-by: Jan Beulich 
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-amd64-i386-pair.xen-boot--dst_host.{dot,ps,png,html}.
----------------------------------------
14050: tolerable ALL FAIL

flight 14050 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14050/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-pair          8 xen-boot/dst_host       fail baseline untested
 test-amd64-i386-pair          7 xen-boot/src_host       fail baseline untested


jobs:
 test-amd64-i386-pair                                         fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 23:35:34 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 23:35:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOzcO-0001a6-Fg; Thu, 18 Oct 2012 23:35:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOzcN-0001Zm-AF
	for xen-devel@lists.xensource.com; Thu, 18 Oct 2012 23:35:11 +0000
Received: from [85.158.139.83:30880] by server-15.bemta-5.messagelabs.com id
	93/D2-28599-E2290805; Thu, 18 Oct 2012 23:35:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1350603308!31235876!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ5MzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 617 invoked from network); 18 Oct 2012 23:35:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 23:35:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,609,1344211200"; d="scan'208";a="15265686"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Oct 2012 23:34:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 19 Oct 2012 00:34:29 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TOzbh-0002vE-EN;
	Thu, 18 Oct 2012 23:34:29 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TOzbh-0007im-DE;
	Fri, 19 Oct 2012 00:34:29 +0100
To: 
Message-ID: 
From: xen.org 
Date: Fri, 19 Oct 2012 00:34:29 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete test-amd64-i386-pair
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-pair
test xen-boot/dst_host

Tree: linux git://xenbits.xen.org/linux-pvops.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 http://xenbits.xen.org/hg/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
  Bug introduced:  4fc87c2f31a0
  Bug not present: c1c549c4fe9e


  changeset:   26060:4fc87c2f31a0
  user:        Huang Ying 
  date:        Tue Oct 16 17:26:36 2012 +0200
      
      ACPI: fix APEI related table size checking
      
      On Huang Ying's machine:
      
      erst_tab->header_length == sizeof(struct acpi_table_einj)
      
      but Yinghai reported that on his machine,
      
      erst_tab->header_length == sizeof(struct acpi_table_einj) -
      sizeof(struct acpi_table_header)
      
      To make erst table size checking code works on all systems, both
      testing are treated as PASS.
      
      Same situation applies to einj_tab->header_length, so corresponding
      table size checking is changed in similar way too.
      
      Originally-by: Yinghai Lu 
      Signed-off-by: Huang Ying 
      
      - use switch() for better readability
      - add comment explaining why a formally invalid size it also being
        accepted
      - check erst_tab->header.length before even looking at
        erst_tab->header_length
      - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
      
      Signed-off-by: Jan Beulich 
      Acked-by: Keir Fraser 
      Committed-by: Jan Beulich 
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-i386-pair.xen-boot--dst_host.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 14038 fail [dst_host=leaf-beetle,src_host=potato-beetle] / 13967 [dst_host=bush-cricket,src_host=field-cricket] 13963 [dst_host=potato-beetle,src_host=leaf-beetle] 13962 [dst_host=itch-mite,src_host=gall-mite] 13960 [dst_host=lace-bug,src_host=moss-bug] 13958 [dst_host=bush-cricket,src_host=field-cricket] 13956 [dst_host=gall-mite,src_host=itch-mite] 13953 [dst_host=potato-beetle,src_host=leaf-beetle] 13952 ok.
Failure / basis pass flights: 14038 / 13952
Tree: linux git://xenbits.xen.org/linux-pvops.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 http://xenbits.xen.org/hg/staging/xen-unstable.hg
Latest a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 3fa2ab30bb05
Basis pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 b91f57f54f47
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#a938a246d34912423c560f475ccf1ce0c71d9d00-a938a246d34912423c560f475ccf1ce0c71d9d00 git://xenbits.xen.org/staging/qemu-xen-unstable.git#bacc0d302445c75f18f4c826750fb5853b60e7ca-bacc0d302445c75f18f4c826750fb5853b60e7ca git://xenbits.xen.org/staging/qemu-upstream-unstable.git#cdf4d2bb4006805f209712fbb8ed1f83127e9984-cdf4d2bb4006805f209712fbb8ed1f83127e9984 http://xenbits.xen.org/hg/staging/xen-unstable.hg#b91f57f54f47-3fa2ab30bb05
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
Loaded 270 nodes in revision graph
Searching for test results:
 13958 [dst_host=bush-cricket,src_host=field-cricket]
 13960 [dst_host=lace-bug,src_host=moss-bug]
 13967 [dst_host=bush-cricket,src_host=field-cricket]
 13962 [dst_host=itch-mite,src_host=gall-mite]
 13972 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 13952 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 b91f57f54f47
 13963 [dst_host=potato-beetle,src_host=leaf-beetle]
 13953 [dst_host=potato-beetle,src_host=leaf-beetle]
 13956 [dst_host=gall-mite,src_host=itch-mite]
 13964 []
 13973 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 13979 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 13995 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4b4c0c7a6031
 14001 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 1f4be6ee4619
 14007 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 5c402b905e00
 14039 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 b91f57f54f47
 14040 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 3fa2ab30bb05
 14041 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 137dfbd3190e
 14011 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 5c402b905e00
 14042 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 177fdda0be56
 14043 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 37bb894121c7
 14017 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 5c402b905e00
 14038 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 3fa2ab30bb05
 14044 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
 14046 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 14047 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
 14048 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 14049 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
 14050 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 14032 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 3fa2ab30bb05
Searching for interesting versions
 Result found: flight 13952 (pass), for basis pass
 Result found: flight 14032 (fail), for basis failure
 Repro found: flight 14039 (pass), for basis pass
 Repro found: flight 14040 (fail), for basis failure
 0 revisions at a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
No revisions left to test, checking graph state.
 Result found: flight 14044 (pass), for last pass
 Result found: flight 14046 (fail), for first failure
 Repro found: flight 14047 (pass), for last pass
 Repro found: flight 14048 (fail), for first failure
 Repro found: flight 14049 (pass), for last pass
 Repro found: flight 14050 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
  Bug introduced:  4fc87c2f31a0
  Bug not present: c1c549c4fe9e

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   26060:4fc87c2f31a0
  user:        Huang Ying 
  date:        Tue Oct 16 17:26:36 2012 +0200
      
      ACPI: fix APEI related table size checking
      
      On Huang Ying's machine:
      
      erst_tab->header_length == sizeof(struct acpi_table_einj)
      
      but Yinghai reported that on his machine,
      
      erst_tab->header_length == sizeof(struct acpi_table_einj) -
      sizeof(struct acpi_table_header)
      
      To make erst table size checking code works on all systems, both
      testing are treated as PASS.
      
      Same situation applies to einj_tab->header_length, so corresponding
      table size checking is changed in similar way too.
      
      Originally-by: Yinghai Lu 
      Signed-off-by: Huang Ying 
      
      - use switch() for better readability
      - add comment explaining why a formally invalid size it also being
        accepted
      - check erst_tab->header.length before even looking at
        erst_tab->header_length
      - prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
      
      Signed-off-by: Jan Beulich 
      Acked-by: Keir Fraser 
      Committed-by: Jan Beulich 
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-amd64-i386-pair.xen-boot--dst_host.{dot,ps,png,html}.
----------------------------------------
14050: tolerable ALL FAIL

flight 14050 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14050/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-pair          8 xen-boot/dst_host       fail baseline untested
 test-amd64-i386-pair          7 xen-boot/src_host       fail baseline untested


jobs:
 test-amd64-i386-pair                                         fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 23:43:23 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 23:43:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOzk3-0001rS-FH; Thu, 18 Oct 2012 23:43:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOzk1-0001rL-IK
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 23:43:06 +0000
Received: from [85.158.138.51:41723] by server-8.bemta-3.messagelabs.com id
	23/85-10525-80490805; Thu, 18 Oct 2012 23:43:04 +0000
X-Env-Sender: avs.009@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1350603780!27330639!1
X-Originating-IP: [209.85.219.45]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_20_30, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26455 invoked from network); 18 Oct 2012 23:43:02 -0000
Received: from mail-oa0-f45.google.com (HELO mail-oa0-f45.google.com)
	(209.85.219.45)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 23:43:02 -0000
Received: by mail-oa0-f45.google.com with SMTP id i18so11905704oag.32
	for ; Thu, 18 Oct 2012 16:43:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=4ZlBahKqnHaAskc5BZl3Rq5V4lKclUN5hOKZzW92eKs=;
	b=WUFx+kY91XpbW7kafe0KUqMnB8PtAZxJqRnxBa7E4pfB0q3fZgKJ1CDZHvBf+f0E4X
	0Wjm0MMTXH6L7i86bOdUBvJl4NLpqCdSe8IZJKbBSZdFaPf8MBLjwQavvjj076TaBX6w
	YRGQpeLVoSxnffIi6Y+97Innd2gAfpoj5VsteyJVKSR96I9lI1rVKWmIoEnTHi7RFeqx
	UzAo43PwosHRNSTH8dIaZBdEcq+CmkrwukmIhwci4UXaWRetp+g4J+CbJ1ic5Mipn2Q+
	r1wYYdbAtchUlol5RX9ltVmvEub6BjkxdyzvVYECntEESaupAJkWJd94+xX1FJvjUFpu
	iP0Q==
MIME-Version: 1.0
Received: by 10.60.7.73 with SMTP id h9mr20703024oea.13.1350603780442; Thu, 18
	Oct 2012 16:43:00 -0700 (PDT)
Received: by 10.60.161.233 with HTTP; Thu, 18 Oct 2012 16:43:00 -0700 (PDT)
In-Reply-To: 
References: 
	<507C075302000078000A1593@nat28.tlf.novell.com>
	
Date: Thu, 18 Oct 2012 20:43:00 -0300
Message-ID: 
From: Allan Scheid 
To: xen-devel@lists.xen.org, Jan Beulich 
Subject: Re: [Xen-devel] Xen 4.2 with EFI on IBM x3650 ACPI Bug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============6472223189753976237=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6472223189753976237==
Content-Type: multipart/alternative; boundary=e89a8f9218e090cc3c04cc5df288

--e89a8f9218e090cc3c04cc5df288
Content-Type: text/plain; charset=ISO-8859-1

Bad news, i am seeing the log output and after the xen.efi boot this still
appears on log:

Into messages:
Oct 18 20:27:36 lca-fw kernel: [    0.000000] ACPI BIOS Bug: Error: A valid
RSDP was not found (20120711/tbxfroot-219)
Oct 18 20:27:36 lca-fw kernel: [    0.000000] NUMA turned off
Oct 18 20:27:36 lca-fw kernel: [    3.759750] pci 0000:00:01.0: can't find
IRQ for PCI INT A; please try using pci=biosirq
Oct 18 20:27:36 lca-fw kernel: [    3.764011] pci 0000:00:1a.0: can't find
IRQ for PCI INT A; please try using pci=biosirq

This still causes don't work USB ports and some PCI cards on the system.

xl dmesg log:

(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x588
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[584,0], pm1x_evt[580,0]
(XEN) ACPI:                  wakeup_vec[7f6eb00c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
(XEN) Processor #0 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled)
(XEN) Processor #2 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled)
(XEN) Processor #4 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x10] enabled)
(XEN) Processor #16 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x12] enabled)
(XEN) Processor #18 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x14] enabled)
(XEN) Processor #20 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x20] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x22] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x24] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x09] lapic_id[0x30] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x32] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x34] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x01] enabled)
(XEN) Processor #1 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x03] enabled)
(XEN) Processor #3 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x05] enabled)
(XEN) Processor #5 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x11] enabled)
(XEN) Processor #17 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x10] lapic_id[0x13] enabled)
(XEN) Processor #19 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x11] lapic_id[0x15] enabled)
(XEN) Processor #21 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x12] lapic_id[0x21] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x13] lapic_id[0x23] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x14] lapic_id[0x25] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x15] lapic_id[0x31] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x16] lapic_id[0x33] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x17] lapic_id[0x35] disabled)
(XEN) ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1])

(XEN) Overriding APIC driver with bigsmp
(XEN) ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: IOAPIC (id[0x09] address[0xfec80000] gsi_base[24])
(XEN) IOAPIC[1]: apic_id 9, version 32, address 0xfec80000, GSI 24-47
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by override.
(XEN) ACPI: IRQ9 used by override.
(XEN) Enabling APIC mode:  Phys.  Using 2 I/O APICs
(XEN) ACPI: HPET id: 0x8086a301 base: 0xfed00000
(XEN) ERST table is invalid
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) SMP: Allowing 24 CPUs (12 hotplug CPUs)
(XEN) IRQ limits: 48 GSI, 2272 MSI/MSI-X
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2400.170 MHz processor.
(XEN) EFI memory map:
(XEN)  0000000000000-0000000000fff type=3 attr=000000000000000f
(XEN)  0000000001000-000000001cfff type=7 attr=000000000000000f
(XEN)  000000001d000-000000001ffff type=2 attr=000000000000000f
(XEN)  0000000020000-000000006bfff type=3 attr=000000000000000f
(XEN)  000000006c000-000000006cfff type=10 attr=000000000000000f
(XEN)  000000006d000-000000006dfff type=4 attr=000000000000000f
(XEN)  000000006e000-000000009efff type=3 attr=000000000000000f
(XEN)  000000009f000-000000009ffff type=10 attr=000000000000000f
(XEN)  0000000100000-00000007fffff type=7 attr=000000000000000f
(XEN)  0000000800000-0000000ffffff type=3 attr=000000000000000f
(XEN)  0000001000000-000007860bfff type=7 attr=000000000000000f
(XEN)  000007860c000-000007890cfff type=4 attr=000000000000000f
.
.
.
(XEN)  000007f7ff000-000007f7fffff type=4 attr=000000000000000f
(XEN)  00000ff800000-00000ffffffff type=11 attr=8000000000000001
(XEN)  0000100000000-000017fffffff type=7 attr=000000000000000f
(XEN)  0000080000000-000008fffffff type=11 attr=8000000000000001
(XEN)  00000fed1c000-00000fed1ffff type=11 attr=8000000000000000
(XEN) Unknown cachability for MFNs 0xfed1c-0xfed1f
(XEN) Initing memory sharing.
(XEN) mce_intel.c:1239: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank 0
extended MCE MSR 0
(XEN) Intel machine check reporting enabled
(XEN) PCI: MCFG configuration 0: base 80000000 segment 0000 buses 00 - ff
(XEN) PCI: MCFG area at 80000000 reserved in E820
(XEN) PCI: Using MCFG for segment 0000 bus 00-ff
(XEN) Intel VT-d supported page sizes: 4kB.
(XEN) Intel VT-d Snoop Control enabled.
(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
(XEN) Intel VT-d Queued Invalidation enabled.
(XEN) Intel VT-d Interrupt Remapping enabled.
(XEN) Intel VT-d Shared EPT tables not enabled.
(XEN) I/O virtualisation enabled
(XEN)  - Dom0 mode: Relaxed
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using old ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
(XEN) Platform timer is 14.318MHz HPET
(XEN) Allocated console ring of 128 KiB.
(XEN) VMX: Supported advanced features:
(XEN)  - APIC MMIO access virtualisation
(XEN)  - APIC TPR shadow
(XEN)  - Extended Page Tables (EPT)
(XEN)  - Virtual-Processor Identifiers (VPID)
(XEN)  - Virtual NMI
(XEN)  - MSR direct-access bitmap
(XEN)  - Unrestricted Guest
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging (HAP) detected
(XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB
(XEN) Brought up 12 CPUs
(XEN) ACPI sleep modes: S3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1c30000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000174000000->0000000178000000 (971715 pages to
be allocated)
(XEN)  Init. ramdisk: 000000017fd21000->000000017ffffa26
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff81000000->ffffffff81c30000
(XEN)  Init. ramdisk: ffffffff81c30000->ffffffff81f0ea26
(XEN)  Phys-Mach map: ffffffff81f0f000->ffffffff8269a510
(XEN)  Start info:    ffffffff8269b000->ffffffff8269b4b4
(XEN)  Page tables:   ffffffff8269c000->ffffffff826b3000
(XEN)  Boot stack:    ffffffff826b3000->ffffffff826b4000
(XEN)  TOTAL:         ffffffff80000000->ffffffff82800000
(XEN)  ENTRY ADDRESS: ffffffff816a7210
(XEN) Dom0 has maximum 12 VCPUs
(XEN) Scrubbing Free RAM: .done.
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input
to Xen)
(XEN) Freed 260kB init memory.
(XEN) PCI add device 0000:00:00.0
(XEN) PCI add device 0000:00:01.0
(XEN) PCI add device 0000:00:02.0
(XEN) PCI add device 0000:00:03.0
(XEN) PCI add device 0000:00:05.0
(XEN) PCI add device 0000:00:07.0
(XEN) PCI add device 0000:00:09.0
(XEN) PCI add device 0000:00:10.0
(XEN) PCI add device 0000:00:10.1
(XEN) PCI add device 0000:00:11.0
(XEN) PCI add device 0000:00:11.1
(XEN) PCI add device 0000:00:14.0
(XEN) PCI add device 0000:00:14.1
(XEN) PCI add device 0000:00:14.2
(XEN) PCI add device 0000:00:14.3
(XEN) PCI add device 0000:00:15.0
(XEN) PCI add device 0000:00:16.0
(XEN) PCI add device 0000:00:16.1
(XEN) PCI add device 0000:00:16.2
(XEN) PCI add device 0000:00:16.3
(XEN) PCI add device 0000:00:16.4
(XEN) PCI add device 0000:00:16.5
(XEN) PCI add device 0000:00:16.6
(XEN) PCI add device 0000:00:16.7
(XEN) PCI add device 0000:00:1a.0
(XEN) PCI add device 0000:00:1a.1
(XEN) PCI add device 0000:00:1a.7
(XEN) PCI add device 0000:00:1c.0
(XEN) PCI add device 0000:00:1c.4
(XEN) PCI add device 0000:00:1d.0
(XEN) PCI add device 0000:00:1d.1
(XEN) PCI add device 0000:00:1d.2
(XEN) PCI add device 0000:00:1d.7
(XEN) PCI add device 0000:00:1e.0
(XEN) PCI add device 0000:00:1f.0
(XEN) PCI add device 0000:00:1f.2
(XEN) PCI add device 0000:00:1f.3
(XEN) PCI add device 0000:00:1f.5
(XEN) PCI add device 0000:0b:00.0
(XEN) PCI add device 0000:0b:00.1
(XEN) PCI add device 0000:01:00.0
(XEN) PCI add device 0000:06:00.0
(XEN) PCI add device 0000:07:00.0

This is my xen.cfg to boot xen.efi:
[global]
default=debian

[debian]
options=console=vga,com2 vga=gfx-1366x768x24 com2=115200,8n1 cpufreq=xen
loglvl=all noreboot=true iommu
kernel=vmlinuz-3.6.1-xen root=/dev/mapper/xen-fw_root ro #earlyprintk=xen
ramdisk=initrd.img-3.6.1-xen

--e89a8f9218e090cc3c04cc5df288
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Bad news, i am seeing the log output and after the xen.efi boot this still =
appears on log:

Into messages:
Oct 18 20:=
27:36 lca-fw kernel: [ =A0 =A00.000000] ACPI BIOS Bug: Error: A valid RSDP =
was not found (20120711/tbxfroot-219)


Oct 18 20:27:36 lca-fw kernel: [ =A0 =A00.000000] NUMA turned off
Oct 18 20:27:36 lca-fw kernel: [ =A0 =A03.759750] pci 0000:00:01.0: c=
an't find IRQ for PCI INT A; please try using pci=3Dbiosirq
=

Oct 18 20:27:36 lca-fw kernel: [ =A0 =A03.764011] pci 0000:00:1a.0: ca=
n't find IRQ for PCI INT A; please try using pci=3Dbiosirq



This still causes don't work USB ports and some PCI car=
ds on the system.

xl dmesg log:


(XEN) Using APIC driver default
(XEN) ACPI: P=
M-Timer IO Port: 0x588
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[584,=
0], pm1x_evt[580,0]
(XEN) ACPI: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0wakeup_vec[7f6eb00c], vec_size[20]


(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC =
(acpi_id[0x00] lapic_id[0x00] enabled)
(XEN) Processor #0 6:12 AP=
IC version 21
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] ena=
bled)


(XEN) Processor #2 6:12 APIC version 21
(XEN) ACPI: LAPIC (a=
cpi_id[0x02] lapic_id[0x04] enabled)
(XEN) Processor #4 6:12 APIC=
 version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x10] enabl=
ed)


(XEN) Processor #16 6:12 APIC version 21
(XEN) ACPI: LAPIC (=
acpi_id[0x04] lapic_id[0x12] enabled)
(XEN) Processor #18 6:12 AP=
IC version 21
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x14] ena=
bled)


(XEN) Processor #20 6:12 APIC version 21
(XEN) ACPI: LAPIC (=
acpi_id[0x06] lapic_id[0x20] disabled)
(XEN) ACPI: LAPIC (acpi_id=
[0x07] lapic_id[0x22] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x08] =
lapic_id[0x24] disabled)


(XEN) ACPI: LAPIC (acpi_id[0x09] lapic_id[0x30] disabled)
(X=
EN) ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x32] disabled)
(XEN) ACP=
I: LAPIC (acpi_id[0x0b] lapic_id[0x34] disabled)
(XEN) ACPI: LAPI=
C (acpi_id[0x0c] lapic_id[0x01] enabled)


(XEN) Processor #1 6:12 APIC version 21
(XEN) ACPI: LAPIC (a=
cpi_id[0x0d] lapic_id[0x03] enabled)
(XEN) Processor #3 6:12 APIC=
 version 21
(XEN) ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x05] enabl=
ed)


(XEN) Processor #5 6:12 APIC version 21
(XEN) ACPI: LAPIC (a=
cpi_id[0x0f] lapic_id[0x11] enabled)
(XEN) Processor #17 6:12 API=
C version 21
(XEN) ACPI: LAPIC (acpi_id[0x10] lapic_id[0x13] enab=
led)


(XEN) Processor #19 6:12 APIC version 21
(XEN) ACPI: LAPIC (=
acpi_id[0x11] lapic_id[0x15] enabled)
(XEN) Processor #21 6:12 AP=
IC version 21
(XEN) ACPI: LAPIC (acpi_id[0x12] lapic_id[0x21] dis=
abled)


(XEN) ACPI: LAPIC (acpi_id[0x13] lapic_id[0x23] disabled)
(X=
EN) ACPI: LAPIC (acpi_id[0x14] lapic_id[0x25] disabled)
(XEN) ACP=
I: LAPIC (acpi_id[0x15] lapic_id[0x31] disabled)
(XEN) ACPI: LAPI=
C (acpi_id[0x16] lapic_id[0x33] disabled)


(XEN) ACPI: LAPIC (acpi_id[0x17] lapic_id[0x35] disabled)
(X=
EN) ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1])

<=
/div>
(XEN) Overriding APIC driver with bigsmp
(XEN) ACP=
I: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])


(XEN) IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: IOAPIC (id[0x09] address[0xfec80000] gsi_base[24])
(XEN) IOAPIC[1]: apic_id 9, version 32, address 0xfec80000, GSI 24-4=
7


(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
<=
div>(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by o=
verride.


(XEN) ACPI: IRQ9 used by override.
(XEN) Enabling APIC mode:=
 =A0Phys. =A0Using 2 I/O APICs
(XEN) ACPI: HPET id: 0x8086a301 ba=
se: 0xfed00000
(XEN) ERST table is invalid
(XEN) Using =
ACPI (MADT) for SMP configuration information


(XEN) SMP: Allowing 24 CPUs (12 hotplug CPUs)
(XEN) IRQ limi=
ts: 48 GSI, 2272 MSI/MSI-X
(XEN) Using scheduler: SMP Credit Sche=
duler (credit)
(XEN) Detected 2400.170 MHz processor.

(XEN) EFI memory map:
(XEN) =A00000000000000-0000000000fff type=
=3D3 attr=3D000000000000000f
(XEN) =A00000000001000-000000001cfff=
 type=3D7 attr=3D000000000000000f
(XEN) =A0000000001d000-00000000=
1ffff type=3D2 attr=3D000000000000000f


(XEN) =A00000000020000-000000006bfff type=3D3 attr=3D000000000000000f<=
/div>
(XEN) =A0000000006c000-000000006cfff type=3D10 attr=3D00000000000=
0000f
(XEN) =A0000000006d000-000000006dfff type=3D4 attr=3D000000=
000000000f


(XEN) =A0000000006e000-000000009efff type=3D3 attr=3D000000000000000f<=
/div>
(XEN) =A0000000009f000-000000009ffff type=3D10 attr=3D00000000000=
0000f
(XEN) =A00000000100000-00000007fffff type=3D7 attr=3D000000=
000000000f


(XEN) =A00000000800000-0000000ffffff type=3D3 attr=3D000000000000000f<=
/div>
(XEN) =A00000001000000-000007860bfff type=3D7 attr=3D000000000000=
000f
(XEN) =A0000007860c000-000007890cfff type=3D4 attr=3D0000000=
00000000f


.
.
.
(XEN) =A0000007f7ff000-=
000007f7fffff type=3D4 attr=3D000000000000000f
(XEN) =A000000ff80=
0000-00000ffffffff type=3D11 attr=3D8000000000000001
(XEN) =A0000=
0100000000-000017fffffff type=3D7 attr=3D000000000000000f


(XEN) =A00000080000000-000008fffffff type=3D11 attr=3D8000000000000001=

(XEN) =A000000fed1c000-00000fed1ffff type=3D11 attr=3D8000000000=
000000
(XEN) Unknown cachability for MFNs 0xfed1c-0xfed1f
(XEN) Initing memory sharing.


(XEN) mce_intel.c:1239: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank=
 0 extended MCE MSR 0
(XEN) Intel machine check reporting enabled=

(XEN) PCI: MCFG configuration 0: base 80000000 segment 0000 buse=
s 00 - ff


(XEN) PCI: MCFG area at 80000000 reserved in E820
(XEN) PCI:=
 Using MCFG for segment 0000 bus 00-ff
(XEN) Intel VT-d supported=
 page sizes: 4kB.
(XEN) Intel VT-d Snoop Control enabled.


(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
(XEN) Int=
el VT-d Queued Invalidation enabled.
(XEN) Intel VT-d Interrupt R=
emapping enabled.
(XEN) Intel VT-d Shared EPT tables not enabled.=



(XEN) I/O virtualisation enabled
(XEN) =A0- Dom0 mode: Relax=
ed
(XEN) Enabled directed EOI with ioapic_ack_old on!
(=
XEN) ENABLING IO-APIC IRQs
(XEN) =A0-> Using old ACK method

(XEN) ..TIMER: vector=3D0xF0 apic1=3D0 pin1=3D2 apic2=3D-1 pin2=3D-1
(XEN) Platform timer is 14.318MHz HPET
(XEN) Allocated c=
onsole ring of 128 KiB.
(XEN) VMX: Supported advanced features:

(XEN) =A0- APIC MMIO access virtualisation
(XEN) =A0- APIC TPR sh=
adow
(XEN) =A0- Extended Page Tables (EPT)
(XEN) =A0- V=
irtual-Processor Identifiers (VPID)
(XEN) =A0- Virtual NMI
<=
div>(XEN) =A0- MSR direct-access bitmap


(XEN) =A0- Unrestricted Guest
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging =
(HAP) detected
(XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB

(XEN) Brought up 12 CPUs
(XEN) ACPI sleep modes: S3
(XE=
N) mcheck_poll: Machine check polling timer started.
(XEN) *** LO=
ADING DOMAIN 0 ***
(XEN) =A0Xen =A0kernel: 64-bit, lsb, compat32<=
/div>

(XEN) =A0Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1c3000=
0
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN) =A0Dom0 allo=
c.: =A0 0000000174000000->0000000178000000 (971715 pages to be allocated=
)


(XEN) =A0Init. ramdisk: 000000017fd21000->000000017ffffa26
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN) =A0Loaded kernel: fffff=
fff81000000->ffffffff81c30000
(XEN) =A0Init. ramdisk: ffffffff=
81c30000->ffffffff81f0ea26


(XEN) =A0Phys-Mach map: ffffffff81f0f000->ffffffff8269a510
(XEN) =A0Start info: =A0 =A0ffffffff8269b000->ffffffff8269b4b4
(XEN) =A0Page tables: =A0 ffffffff8269c000->ffffffff826b3000
(XEN) =A0Boot stack: =A0 =A0ffffffff826b3000->ffffffff826b4000


(XEN) =A0TOTAL: =A0 =A0 =A0 =A0 ffffffff80000000->ffffffff82800000<=
/div>
(XEN) =A0ENTRY ADDRESS: ffffffff816a7210
(XEN) Dom0 has=
 maximum 12 VCPUs
(XEN) Scrubbing Free RAM: .done.
(XEN=
) Initial low memory virq threshold set at 0x4000 pages.


(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: Nothing (Rate=
-limited: Errors and warnings)
(XEN) Xen is relinquishing VGA con=
sole.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' th=
ree times to switch input to Xen)


(XEN) Freed 260kB init memory.
(XEN) PCI add device 0000:00:=
00.0
(XEN) PCI add device 0000:00:01.0
(XEN) PCI add de=
vice 0000:00:02.0
(XEN) PCI add device 0000:00:03.0

(XEN) PCI add device 0000:00:05.0
(XEN) PCI add device 0000:00:07=
.0
(XEN) PCI add device 0000:00:09.0
(XEN) PCI add devi=
ce 0000:00:10.0
(XEN) PCI add device 0000:00:10.1
(XEN)=
 PCI add device 0000:00:11.0


(XEN) PCI add device 0000:00:11.1
(XEN) PCI add device 0000:=
00:14.0
(XEN) PCI add device 0000:00:14.1
(XEN) PCI add=
 device 0000:00:14.2
(XEN) PCI add device 0000:00:14.3

(XEN) PCI add device 0000:00:15.0
(XEN) PCI add device 0000:00:16=
.0
(XEN) PCI add device 0000:00:16.1
(XEN) PCI add devi=
ce 0000:00:16.2
(XEN) PCI add device 0000:00:16.3
(XEN)=
 PCI add device 0000:00:16.4


(XEN) PCI add device 0000:00:16.5
(XEN) PCI add device 0000:=
00:16.6
(XEN) PCI add device 0000:00:16.7
(XEN) PCI add=
 device 0000:00:1a.0
(XEN) PCI add device 0000:00:1a.1

(XEN) PCI add device 0000:00:1a.7
(XEN) PCI add device 0000:00:1c=
.0
(XEN) PCI add device 0000:00:1c.4
(XEN) PCI add devi=
ce 0000:00:1d.0
(XEN) PCI add device 0000:00:1d.1
(XEN)=
 PCI add device 0000:00:1d.2


(XEN) PCI add device 0000:00:1d.7
(XEN) PCI add device 0000:=
00:1e.0
(XEN) PCI add device 0000:00:1f.0
(XEN) PCI add=
 device 0000:00:1f.2
(XEN) PCI add device 0000:00:1f.3

(XEN) PCI add device 0000:00:1f.5
(XEN) PCI add device 0000:0b:00=
.0
(XEN) PCI add device 0000:0b:00.1
(XEN) PCI add devi=
ce 0000:01:00.0
(XEN) PCI add device 0000:06:00.0
(XEN)=
 PCI add device 0000:07:00.0



This is my xen.cfg to boot xen.efi:
[global]
default=3Ddebian

[debian]
options=3Dconsole=3Dvga,com2 vga=3Dgfx-1366x768x24 com2=3D115200,8n1=
 cpufreq=3Dxen loglvl=3Dall noreboot=3Dtrue iommu


kernel=3Dvmlinuz-3.6.1-xen root=3D/dev/mapper/xen-fw_root ro #earlypri=
ntk=3Dxen
ramdisk=3Dinitrd.img-3.6.1-xen


--e89a8f9218e090cc3c04cc5df288--


--===============6472223189753976237==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6472223189753976237==--


From xen-devel-bounces@lists.xen.org Thu Oct 18 23:43:23 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 23:43:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOzk3-0001rS-FH; Thu, 18 Oct 2012 23:43:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOzk1-0001rL-IK
	for xen-devel@lists.xen.org; Thu, 18 Oct 2012 23:43:06 +0000
Received: from [85.158.138.51:41723] by server-8.bemta-3.messagelabs.com id
	23/85-10525-80490805; Thu, 18 Oct 2012 23:43:04 +0000
X-Env-Sender: avs.009@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1350603780!27330639!1
X-Originating-IP: [209.85.219.45]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_20_30, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26455 invoked from network); 18 Oct 2012 23:43:02 -0000
Received: from mail-oa0-f45.google.com (HELO mail-oa0-f45.google.com)
	(209.85.219.45)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Oct 2012 23:43:02 -0000
Received: by mail-oa0-f45.google.com with SMTP id i18so11905704oag.32
	for ; Thu, 18 Oct 2012 16:43:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=4ZlBahKqnHaAskc5BZl3Rq5V4lKclUN5hOKZzW92eKs=;
	b=WUFx+kY91XpbW7kafe0KUqMnB8PtAZxJqRnxBa7E4pfB0q3fZgKJ1CDZHvBf+f0E4X
	0Wjm0MMTXH6L7i86bOdUBvJl4NLpqCdSe8IZJKbBSZdFaPf8MBLjwQavvjj076TaBX6w
	YRGQpeLVoSxnffIi6Y+97Innd2gAfpoj5VsteyJVKSR96I9lI1rVKWmIoEnTHi7RFeqx
	UzAo43PwosHRNSTH8dIaZBdEcq+CmkrwukmIhwci4UXaWRetp+g4J+CbJ1ic5Mipn2Q+
	r1wYYdbAtchUlol5RX9ltVmvEub6BjkxdyzvVYECntEESaupAJkWJd94+xX1FJvjUFpu
	iP0Q==
MIME-Version: 1.0
Received: by 10.60.7.73 with SMTP id h9mr20703024oea.13.1350603780442; Thu, 18
	Oct 2012 16:43:00 -0700 (PDT)
Received: by 10.60.161.233 with HTTP; Thu, 18 Oct 2012 16:43:00 -0700 (PDT)
In-Reply-To: 
References: 
	<507C075302000078000A1593@nat28.tlf.novell.com>
	
Date: Thu, 18 Oct 2012 20:43:00 -0300
Message-ID: 
From: Allan Scheid 
To: xen-devel@lists.xen.org, Jan Beulich 
Subject: Re: [Xen-devel] Xen 4.2 with EFI on IBM x3650 ACPI Bug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============6472223189753976237=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6472223189753976237==
Content-Type: multipart/alternative; boundary=e89a8f9218e090cc3c04cc5df288

--e89a8f9218e090cc3c04cc5df288
Content-Type: text/plain; charset=ISO-8859-1

Bad news, i am seeing the log output and after the xen.efi boot this still
appears on log:

Into messages:
Oct 18 20:27:36 lca-fw kernel: [    0.000000] ACPI BIOS Bug: Error: A valid
RSDP was not found (20120711/tbxfroot-219)
Oct 18 20:27:36 lca-fw kernel: [    0.000000] NUMA turned off
Oct 18 20:27:36 lca-fw kernel: [    3.759750] pci 0000:00:01.0: can't find
IRQ for PCI INT A; please try using pci=biosirq
Oct 18 20:27:36 lca-fw kernel: [    3.764011] pci 0000:00:1a.0: can't find
IRQ for PCI INT A; please try using pci=biosirq

This still causes don't work USB ports and some PCI cards on the system.

xl dmesg log:

(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x588
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[584,0], pm1x_evt[580,0]
(XEN) ACPI:                  wakeup_vec[7f6eb00c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
(XEN) Processor #0 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled)
(XEN) Processor #2 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled)
(XEN) Processor #4 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x10] enabled)
(XEN) Processor #16 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x12] enabled)
(XEN) Processor #18 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x14] enabled)
(XEN) Processor #20 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x20] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x22] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x24] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x09] lapic_id[0x30] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x32] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x34] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x01] enabled)
(XEN) Processor #1 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x03] enabled)
(XEN) Processor #3 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x05] enabled)
(XEN) Processor #5 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x11] enabled)
(XEN) Processor #17 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x10] lapic_id[0x13] enabled)
(XEN) Processor #19 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x11] lapic_id[0x15] enabled)
(XEN) Processor #21 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x12] lapic_id[0x21] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x13] lapic_id[0x23] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x14] lapic_id[0x25] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x15] lapic_id[0x31] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x16] lapic_id[0x33] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x17] lapic_id[0x35] disabled)
(XEN) ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1])

(XEN) Overriding APIC driver with bigsmp
(XEN) ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: IOAPIC (id[0x09] address[0xfec80000] gsi_base[24])
(XEN) IOAPIC[1]: apic_id 9, version 32, address 0xfec80000, GSI 24-47
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by override.
(XEN) ACPI: IRQ9 used by override.
(XEN) Enabling APIC mode:  Phys.  Using 2 I/O APICs
(XEN) ACPI: HPET id: 0x8086a301 base: 0xfed00000
(XEN) ERST table is invalid
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) SMP: Allowing 24 CPUs (12 hotplug CPUs)
(XEN) IRQ limits: 48 GSI, 2272 MSI/MSI-X
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2400.170 MHz processor.
(XEN) EFI memory map:
(XEN)  0000000000000-0000000000fff type=3 attr=000000000000000f
(XEN)  0000000001000-000000001cfff type=7 attr=000000000000000f
(XEN)  000000001d000-000000001ffff type=2 attr=000000000000000f
(XEN)  0000000020000-000000006bfff type=3 attr=000000000000000f
(XEN)  000000006c000-000000006cfff type=10 attr=000000000000000f
(XEN)  000000006d000-000000006dfff type=4 attr=000000000000000f
(XEN)  000000006e000-000000009efff type=3 attr=000000000000000f
(XEN)  000000009f000-000000009ffff type=10 attr=000000000000000f
(XEN)  0000000100000-00000007fffff type=7 attr=000000000000000f
(XEN)  0000000800000-0000000ffffff type=3 attr=000000000000000f
(XEN)  0000001000000-000007860bfff type=7 attr=000000000000000f
(XEN)  000007860c000-000007890cfff type=4 attr=000000000000000f
.
.
.
(XEN)  000007f7ff000-000007f7fffff type=4 attr=000000000000000f
(XEN)  00000ff800000-00000ffffffff type=11 attr=8000000000000001
(XEN)  0000100000000-000017fffffff type=7 attr=000000000000000f
(XEN)  0000080000000-000008fffffff type=11 attr=8000000000000001
(XEN)  00000fed1c000-00000fed1ffff type=11 attr=8000000000000000
(XEN) Unknown cachability for MFNs 0xfed1c-0xfed1f
(XEN) Initing memory sharing.
(XEN) mce_intel.c:1239: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank 0
extended MCE MSR 0
(XEN) Intel machine check reporting enabled
(XEN) PCI: MCFG configuration 0: base 80000000 segment 0000 buses 00 - ff
(XEN) PCI: MCFG area at 80000000 reserved in E820
(XEN) PCI: Using MCFG for segment 0000 bus 00-ff
(XEN) Intel VT-d supported page sizes: 4kB.
(XEN) Intel VT-d Snoop Control enabled.
(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
(XEN) Intel VT-d Queued Invalidation enabled.
(XEN) Intel VT-d Interrupt Remapping enabled.
(XEN) Intel VT-d Shared EPT tables not enabled.
(XEN) I/O virtualisation enabled
(XEN)  - Dom0 mode: Relaxed
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using old ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
(XEN) Platform timer is 14.318MHz HPET
(XEN) Allocated console ring of 128 KiB.
(XEN) VMX: Supported advanced features:
(XEN)  - APIC MMIO access virtualisation
(XEN)  - APIC TPR shadow
(XEN)  - Extended Page Tables (EPT)
(XEN)  - Virtual-Processor Identifiers (VPID)
(XEN)  - Virtual NMI
(XEN)  - MSR direct-access bitmap
(XEN)  - Unrestricted Guest
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging (HAP) detected
(XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB
(XEN) Brought up 12 CPUs
(XEN) ACPI sleep modes: S3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1c30000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000174000000->0000000178000000 (971715 pages to
be allocated)
(XEN)  Init. ramdisk: 000000017fd21000->000000017ffffa26
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff81000000->ffffffff81c30000
(XEN)  Init. ramdisk: ffffffff81c30000->ffffffff81f0ea26
(XEN)  Phys-Mach map: ffffffff81f0f000->ffffffff8269a510
(XEN)  Start info:    ffffffff8269b000->ffffffff8269b4b4
(XEN)  Page tables:   ffffffff8269c000->ffffffff826b3000
(XEN)  Boot stack:    ffffffff826b3000->ffffffff826b4000
(XEN)  TOTAL:         ffffffff80000000->ffffffff82800000
(XEN)  ENTRY ADDRESS: ffffffff816a7210
(XEN) Dom0 has maximum 12 VCPUs
(XEN) Scrubbing Free RAM: .done.
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input
to Xen)
(XEN) Freed 260kB init memory.
(XEN) PCI add device 0000:00:00.0
(XEN) PCI add device 0000:00:01.0
(XEN) PCI add device 0000:00:02.0
(XEN) PCI add device 0000:00:03.0
(XEN) PCI add device 0000:00:05.0
(XEN) PCI add device 0000:00:07.0
(XEN) PCI add device 0000:00:09.0
(XEN) PCI add device 0000:00:10.0
(XEN) PCI add device 0000:00:10.1
(XEN) PCI add device 0000:00:11.0
(XEN) PCI add device 0000:00:11.1
(XEN) PCI add device 0000:00:14.0
(XEN) PCI add device 0000:00:14.1
(XEN) PCI add device 0000:00:14.2
(XEN) PCI add device 0000:00:14.3
(XEN) PCI add device 0000:00:15.0
(XEN) PCI add device 0000:00:16.0
(XEN) PCI add device 0000:00:16.1
(XEN) PCI add device 0000:00:16.2
(XEN) PCI add device 0000:00:16.3
(XEN) PCI add device 0000:00:16.4
(XEN) PCI add device 0000:00:16.5
(XEN) PCI add device 0000:00:16.6
(XEN) PCI add device 0000:00:16.7
(XEN) PCI add device 0000:00:1a.0
(XEN) PCI add device 0000:00:1a.1
(XEN) PCI add device 0000:00:1a.7
(XEN) PCI add device 0000:00:1c.0
(XEN) PCI add device 0000:00:1c.4
(XEN) PCI add device 0000:00:1d.0
(XEN) PCI add device 0000:00:1d.1
(XEN) PCI add device 0000:00:1d.2
(XEN) PCI add device 0000:00:1d.7
(XEN) PCI add device 0000:00:1e.0
(XEN) PCI add device 0000:00:1f.0
(XEN) PCI add device 0000:00:1f.2
(XEN) PCI add device 0000:00:1f.3
(XEN) PCI add device 0000:00:1f.5
(XEN) PCI add device 0000:0b:00.0
(XEN) PCI add device 0000:0b:00.1
(XEN) PCI add device 0000:01:00.0
(XEN) PCI add device 0000:06:00.0
(XEN) PCI add device 0000:07:00.0

This is my xen.cfg to boot xen.efi:
[global]
default=debian

[debian]
options=console=vga,com2 vga=gfx-1366x768x24 com2=115200,8n1 cpufreq=xen
loglvl=all noreboot=true iommu
kernel=vmlinuz-3.6.1-xen root=/dev/mapper/xen-fw_root ro #earlyprintk=xen
ramdisk=initrd.img-3.6.1-xen

--e89a8f9218e090cc3c04cc5df288
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Bad news, i am seeing the log output and after the xen.efi boot this still =
appears on log:

Into messages:
Oct 18 20:=
27:36 lca-fw kernel: [ =A0 =A00.000000] ACPI BIOS Bug: Error: A valid RSDP =
was not found (20120711/tbxfroot-219)


Oct 18 20:27:36 lca-fw kernel: [ =A0 =A00.000000] NUMA turned off
Oct 18 20:27:36 lca-fw kernel: [ =A0 =A03.759750] pci 0000:00:01.0: c=
an't find IRQ for PCI INT A; please try using pci=3Dbiosirq
=

Oct 18 20:27:36 lca-fw kernel: [ =A0 =A03.764011] pci 0000:00:1a.0: ca=
n't find IRQ for PCI INT A; please try using pci=3Dbiosirq



This still causes don't work USB ports and some PCI car=
ds on the system.

xl dmesg log:


(XEN) Using APIC driver default
(XEN) ACPI: P=
M-Timer IO Port: 0x588
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[584,=
0], pm1x_evt[580,0]
(XEN) ACPI: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0wakeup_vec[7f6eb00c], vec_size[20]


(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC =
(acpi_id[0x00] lapic_id[0x00] enabled)
(XEN) Processor #0 6:12 AP=
IC version 21
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] ena=
bled)


(XEN) Processor #2 6:12 APIC version 21
(XEN) ACPI: LAPIC (a=
cpi_id[0x02] lapic_id[0x04] enabled)
(XEN) Processor #4 6:12 APIC=
 version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x10] enabl=
ed)


(XEN) Processor #16 6:12 APIC version 21
(XEN) ACPI: LAPIC (=
acpi_id[0x04] lapic_id[0x12] enabled)
(XEN) Processor #18 6:12 AP=
IC version 21
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x14] ena=
bled)


(XEN) Processor #20 6:12 APIC version 21
(XEN) ACPI: LAPIC (=
acpi_id[0x06] lapic_id[0x20] disabled)
(XEN) ACPI: LAPIC (acpi_id=
[0x07] lapic_id[0x22] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x08] =
lapic_id[0x24] disabled)


(XEN) ACPI: LAPIC (acpi_id[0x09] lapic_id[0x30] disabled)
(X=
EN) ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x32] disabled)
(XEN) ACP=
I: LAPIC (acpi_id[0x0b] lapic_id[0x34] disabled)
(XEN) ACPI: LAPI=
C (acpi_id[0x0c] lapic_id[0x01] enabled)


(XEN) Processor #1 6:12 APIC version 21
(XEN) ACPI: LAPIC (a=
cpi_id[0x0d] lapic_id[0x03] enabled)
(XEN) Processor #3 6:12 APIC=
 version 21
(XEN) ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x05] enabl=
ed)


(XEN) Processor #5 6:12 APIC version 21
(XEN) ACPI: LAPIC (a=
cpi_id[0x0f] lapic_id[0x11] enabled)
(XEN) Processor #17 6:12 API=
C version 21
(XEN) ACPI: LAPIC (acpi_id[0x10] lapic_id[0x13] enab=
led)


(XEN) Processor #19 6:12 APIC version 21
(XEN) ACPI: LAPIC (=
acpi_id[0x11] lapic_id[0x15] enabled)
(XEN) Processor #21 6:12 AP=
IC version 21
(XEN) ACPI: LAPIC (acpi_id[0x12] lapic_id[0x21] dis=
abled)


(XEN) ACPI: LAPIC (acpi_id[0x13] lapic_id[0x23] disabled)
(X=
EN) ACPI: LAPIC (acpi_id[0x14] lapic_id[0x25] disabled)
(XEN) ACP=
I: LAPIC (acpi_id[0x15] lapic_id[0x31] disabled)
(XEN) ACPI: LAPI=
C (acpi_id[0x16] lapic_id[0x33] disabled)


(XEN) ACPI: LAPIC (acpi_id[0x17] lapic_id[0x35] disabled)
(X=
EN) ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1])

<=
/div>
(XEN) Overriding APIC driver with bigsmp
(XEN) ACP=
I: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])


(XEN) IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: IOAPIC (id[0x09] address[0xfec80000] gsi_base[24])
(XEN) IOAPIC[1]: apic_id 9, version 32, address 0xfec80000, GSI 24-4=
7


(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
<=
div>(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by o=
verride.


(XEN) ACPI: IRQ9 used by override.
(XEN) Enabling APIC mode:=
 =A0Phys. =A0Using 2 I/O APICs
(XEN) ACPI: HPET id: 0x8086a301 ba=
se: 0xfed00000
(XEN) ERST table is invalid
(XEN) Using =
ACPI (MADT) for SMP configuration information


(XEN) SMP: Allowing 24 CPUs (12 hotplug CPUs)
(XEN) IRQ limi=
ts: 48 GSI, 2272 MSI/MSI-X
(XEN) Using scheduler: SMP Credit Sche=
duler (credit)
(XEN) Detected 2400.170 MHz processor.

(XEN) EFI memory map:
(XEN) =A00000000000000-0000000000fff type=
=3D3 attr=3D000000000000000f
(XEN) =A00000000001000-000000001cfff=
 type=3D7 attr=3D000000000000000f
(XEN) =A0000000001d000-00000000=
1ffff type=3D2 attr=3D000000000000000f


(XEN) =A00000000020000-000000006bfff type=3D3 attr=3D000000000000000f<=
/div>
(XEN) =A0000000006c000-000000006cfff type=3D10 attr=3D00000000000=
0000f
(XEN) =A0000000006d000-000000006dfff type=3D4 attr=3D000000=
000000000f


(XEN) =A0000000006e000-000000009efff type=3D3 attr=3D000000000000000f<=
/div>
(XEN) =A0000000009f000-000000009ffff type=3D10 attr=3D00000000000=
0000f
(XEN) =A00000000100000-00000007fffff type=3D7 attr=3D000000=
000000000f


(XEN) =A00000000800000-0000000ffffff type=3D3 attr=3D000000000000000f<=
/div>
(XEN) =A00000001000000-000007860bfff type=3D7 attr=3D000000000000=
000f
(XEN) =A0000007860c000-000007890cfff type=3D4 attr=3D0000000=
00000000f


.
.
.
(XEN) =A0000007f7ff000-=
000007f7fffff type=3D4 attr=3D000000000000000f
(XEN) =A000000ff80=
0000-00000ffffffff type=3D11 attr=3D8000000000000001
(XEN) =A0000=
0100000000-000017fffffff type=3D7 attr=3D000000000000000f


(XEN) =A00000080000000-000008fffffff type=3D11 attr=3D8000000000000001=

(XEN) =A000000fed1c000-00000fed1ffff type=3D11 attr=3D8000000000=
000000
(XEN) Unknown cachability for MFNs 0xfed1c-0xfed1f
(XEN) Initing memory sharing.


(XEN) mce_intel.c:1239: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank=
 0 extended MCE MSR 0
(XEN) Intel machine check reporting enabled=

(XEN) PCI: MCFG configuration 0: base 80000000 segment 0000 buse=
s 00 - ff


(XEN) PCI: MCFG area at 80000000 reserved in E820
(XEN) PCI:=
 Using MCFG for segment 0000 bus 00-ff
(XEN) Intel VT-d supported=
 page sizes: 4kB.
(XEN) Intel VT-d Snoop Control enabled.


(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
(XEN) Int=
el VT-d Queued Invalidation enabled.
(XEN) Intel VT-d Interrupt R=
emapping enabled.
(XEN) Intel VT-d Shared EPT tables not enabled.=



(XEN) I/O virtualisation enabled
(XEN) =A0- Dom0 mode: Relax=
ed
(XEN) Enabled directed EOI with ioapic_ack_old on!
(=
XEN) ENABLING IO-APIC IRQs
(XEN) =A0-> Using old ACK method

(XEN) ..TIMER: vector=3D0xF0 apic1=3D0 pin1=3D2 apic2=3D-1 pin2=3D-1
(XEN) Platform timer is 14.318MHz HPET
(XEN) Allocated c=
onsole ring of 128 KiB.
(XEN) VMX: Supported advanced features:

(XEN) =A0- APIC MMIO access virtualisation
(XEN) =A0- APIC TPR sh=
adow
(XEN) =A0- Extended Page Tables (EPT)
(XEN) =A0- V=
irtual-Processor Identifiers (VPID)
(XEN) =A0- Virtual NMI
<=
div>(XEN) =A0- MSR direct-access bitmap


(XEN) =A0- Unrestricted Guest
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging =
(HAP) detected
(XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB

(XEN) Brought up 12 CPUs
(XEN) ACPI sleep modes: S3
(XE=
N) mcheck_poll: Machine check polling timer started.
(XEN) *** LO=
ADING DOMAIN 0 ***
(XEN) =A0Xen =A0kernel: 64-bit, lsb, compat32<=
/div>

(XEN) =A0Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1c3000=
0
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN) =A0Dom0 allo=
c.: =A0 0000000174000000->0000000178000000 (971715 pages to be allocated=
)


(XEN) =A0Init. ramdisk: 000000017fd21000->000000017ffffa26
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN) =A0Loaded kernel: fffff=
fff81000000->ffffffff81c30000
(XEN) =A0Init. ramdisk: ffffffff=
81c30000->ffffffff81f0ea26


(XEN) =A0Phys-Mach map: ffffffff81f0f000->ffffffff8269a510
(XEN) =A0Start info: =A0 =A0ffffffff8269b000->ffffffff8269b4b4
(XEN) =A0Page tables: =A0 ffffffff8269c000->ffffffff826b3000
(XEN) =A0Boot stack: =A0 =A0ffffffff826b3000->ffffffff826b4000


(XEN) =A0TOTAL: =A0 =A0 =A0 =A0 ffffffff80000000->ffffffff82800000<=
/div>
(XEN) =A0ENTRY ADDRESS: ffffffff816a7210
(XEN) Dom0 has=
 maximum 12 VCPUs
(XEN) Scrubbing Free RAM: .done.
(XEN=
) Initial low memory virq threshold set at 0x4000 pages.


(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: Nothing (Rate=
-limited: Errors and warnings)
(XEN) Xen is relinquishing VGA con=
sole.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' th=
ree times to switch input to Xen)


(XEN) Freed 260kB init memory.
(XEN) PCI add device 0000:00:=
00.0
(XEN) PCI add device 0000:00:01.0
(XEN) PCI add de=
vice 0000:00:02.0
(XEN) PCI add device 0000:00:03.0

(XEN) PCI add device 0000:00:05.0
(XEN) PCI add device 0000:00:07=
.0
(XEN) PCI add device 0000:00:09.0
(XEN) PCI add devi=
ce 0000:00:10.0
(XEN) PCI add device 0000:00:10.1
(XEN)=
 PCI add device 0000:00:11.0


(XEN) PCI add device 0000:00:11.1
(XEN) PCI add device 0000:=
00:14.0
(XEN) PCI add device 0000:00:14.1
(XEN) PCI add=
 device 0000:00:14.2
(XEN) PCI add device 0000:00:14.3

(XEN) PCI add device 0000:00:15.0
(XEN) PCI add device 0000:00:16=
.0
(XEN) PCI add device 0000:00:16.1
(XEN) PCI add devi=
ce 0000:00:16.2
(XEN) PCI add device 0000:00:16.3
(XEN)=
 PCI add device 0000:00:16.4


(XEN) PCI add device 0000:00:16.5
(XEN) PCI add device 0000:=
00:16.6
(XEN) PCI add device 0000:00:16.7
(XEN) PCI add=
 device 0000:00:1a.0
(XEN) PCI add device 0000:00:1a.1

(XEN) PCI add device 0000:00:1a.7
(XEN) PCI add device 0000:00:1c=
.0
(XEN) PCI add device 0000:00:1c.4
(XEN) PCI add devi=
ce 0000:00:1d.0
(XEN) PCI add device 0000:00:1d.1
(XEN)=
 PCI add device 0000:00:1d.2


(XEN) PCI add device 0000:00:1d.7
(XEN) PCI add device 0000:=
00:1e.0
(XEN) PCI add device 0000:00:1f.0
(XEN) PCI add=
 device 0000:00:1f.2
(XEN) PCI add device 0000:00:1f.3

(XEN) PCI add device 0000:00:1f.5
(XEN) PCI add device 0000:0b:00=
.0
(XEN) PCI add device 0000:0b:00.1
(XEN) PCI add devi=
ce 0000:01:00.0
(XEN) PCI add device 0000:06:00.0
(XEN)=
 PCI add device 0000:07:00.0



This is my xen.cfg to boot xen.efi:
[global]
default=3Ddebian

[debian]
options=3Dconsole=3Dvga,com2 vga=3Dgfx-1366x768x24 com2=3D115200,8n1=
 cpufreq=3Dxen loglvl=3Dall noreboot=3Dtrue iommu


kernel=3Dvmlinuz-3.6.1-xen root=3D/dev/mapper/xen-fw_root ro #earlypri=
ntk=3Dxen
ramdisk=3Dinitrd.img-3.6.1-xen


--e89a8f9218e090cc3c04cc5df288--


--===============6472223189753976237==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6472223189753976237==--


From xen-devel-bounces@lists.xen.org Thu Oct 18 23:56:01 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 23:56:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOzwD-00023G-3n; Thu, 18 Oct 2012 23:55:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOzwC-00023B-31
	for Xen-devel@lists.xensource.com; Thu, 18 Oct 2012 23:55:40 +0000
Received: from [85.158.139.83:39106] by server-4.bemta-5.messagelabs.com id
	DA/15-01455-BF690805; Thu, 18 Oct 2012 23:55:39 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1350604536!34854885!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODEyNzI4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2413 invoked from network); 18 Oct 2012 23:55:38 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Oct 2012 23:55:38 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9INtYmp005996
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 18 Oct 2012 23:55:34 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9INtXmS004020
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 18 Oct 2012 23:55:33 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9INtWFw016051; Thu, 18 Oct 2012 18:55:33 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 18 Oct 2012 16:55:32 -0700
Date: Thu, 18 Oct 2012 16:55:31 -0700
From: Mukesh Rathor 
To: Ian Campbell 
Message-ID: <20121018165531.34d2040c@mantra.us.oracle.com>
In-Reply-To: <1350557371.2460.117.camel@zakaz.uk.xensource.com>
References: <20121017173223.7ea1901d@mantra.us.oracle.com>
	<1350557371.2460.117.camel@zakaz.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V3 4/6]: PVH:bootup and setup related
 changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 18 Oct 2012 11:49:31 +0100
Ian Campbell  wrote:

> On Thu, 2012-10-18 at 01:32 +0100, Mukesh Rathor wrote:
> > 
> > +       /* PVH TBD/FIXME: vcpu info placement in phase 2 */
> > +       if (xen_pvh_domain())
> > +               return; 
> 
> Do you have a list of future work before PVH is "feature complete"
> somewhere?
> 
> I wouldn't count vcpu placement specifically against completeness but
> the TBD triggered the thought.
> 
> For example I was reviewing a migration patch this morning and was
> wondering if that sort of thing had been investigated yet.
> 
> Ian.

Yes, I was gonna post it in a separate email, so one can easily
find/track it. 

No, haven't thought of migration, phase II or III.

thanks
Mukesh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 18 23:56:01 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 18 Oct 2012 23:56:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TOzwD-00023G-3n; Thu, 18 Oct 2012 23:55:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TOzwC-00023B-31
	for Xen-devel@lists.xensource.com; Thu, 18 Oct 2012 23:55:40 +0000
Received: from [85.158.139.83:39106] by server-4.bemta-5.messagelabs.com id
	DA/15-01455-BF690805; Thu, 18 Oct 2012 23:55:39 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1350604536!34854885!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODEyNzI4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2413 invoked from network); 18 Oct 2012 23:55:38 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Oct 2012 23:55:38 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9INtYmp005996
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 18 Oct 2012 23:55:34 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9INtXmS004020
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 18 Oct 2012 23:55:33 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9INtWFw016051; Thu, 18 Oct 2012 18:55:33 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 18 Oct 2012 16:55:32 -0700
Date: Thu, 18 Oct 2012 16:55:31 -0700
From: Mukesh Rathor 
To: Ian Campbell 
Message-ID: <20121018165531.34d2040c@mantra.us.oracle.com>
In-Reply-To: <1350557371.2460.117.camel@zakaz.uk.xensource.com>
References: <20121017173223.7ea1901d@mantra.us.oracle.com>
	<1350557371.2460.117.camel@zakaz.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V3 4/6]: PVH:bootup and setup related
 changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 18 Oct 2012 11:49:31 +0100
Ian Campbell  wrote:

> On Thu, 2012-10-18 at 01:32 +0100, Mukesh Rathor wrote:
> > 
> > +       /* PVH TBD/FIXME: vcpu info placement in phase 2 */
> > +       if (xen_pvh_domain())
> > +               return; 
> 
> Do you have a list of future work before PVH is "feature complete"
> somewhere?
> 
> I wouldn't count vcpu placement specifically against completeness but
> the TBD triggered the thought.
> 
> For example I was reviewing a migration patch this morning and was
> wondering if that sort of thing had been investigated yet.
> 
> Ian.

Yes, I was gonna post it in a separate email, so one can easily
find/track it. 

No, haven't thought of migration, phase II or III.

thanks
Mukesh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 00:02:49 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 00:02:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP02s-0002e7-1Q; Fri, 19 Oct 2012 00:02:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP02q-0002e2-E9
	for Xen-devel@lists.xensource.com; Fri, 19 Oct 2012 00:02:32 +0000
Received: from [85.158.143.35:13905] by server-1.bemta-4.messagelabs.com id
	98/6C-19134-79890805; Fri, 19 Oct 2012 00:02:31 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1350604950!14568047!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgyMTI5Ng==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16354 invoked from network); 19 Oct 2012 00:02:31 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Oct 2012 00:02:31 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9J02Qnf013919
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Oct 2012 00:02:27 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9J02PRc020102
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 19 Oct 2012 00:02:26 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9J02PUu029964; Thu, 18 Oct 2012 19:02:25 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 18 Oct 2012 17:02:24 -0700
Date: Thu, 18 Oct 2012 17:02:23 -0700
From: Mukesh Rathor 
To: Ian Campbell 
Message-ID: <20121018170223.03ef0913@mantra.us.oracle.com>
In-Reply-To: <1350556553.2460.108.camel@zakaz.uk.xensource.com>
References: <20121017173448.7ef4c0b1@mantra.us.oracle.com>
	<1350556553.2460.108.camel@zakaz.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V3 6/6]: PVH:privcmd changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 18 Oct 2012 11:35:53 +0100
Ian Campbell  wrote:

> 
> > @@ -439,6 +490,19 @@ static long privcmd_ioctl(struct file *file,
> >  	return ret;
> >  }
> >  
> > +static void privcmd_close(struct vm_area_struct *vma)
> > +{
> > +	struct page **pages = vma ? vma->vm_private_data : NULL;
> 
> Can VMA really be NULL?...

Good programming I thought!

> > +	int numpgs = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
> 
> ...I assume not since you unconditionally dereference it here.

Added this later, and just didn't change the earlier part.

> > +	if (!pages || !numpgs
> > || !xen_feature(XENFEAT_auto_translated_physmap))
> 
> In the non-xlat case pages will (or should!) be 1 here which will pass
> the first clause of the test.
> 
> Although the later clauses will catch this I think it would be worth
> ordering the checks such that they are each valid, perhaps by pulling
> the feature check to the front or by separating the !xlat case from
> the other two which are valid iff xlat == True.
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 00:02:49 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 00:02:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP02s-0002e7-1Q; Fri, 19 Oct 2012 00:02:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP02q-0002e2-E9
	for Xen-devel@lists.xensource.com; Fri, 19 Oct 2012 00:02:32 +0000
Received: from [85.158.143.35:13905] by server-1.bemta-4.messagelabs.com id
	98/6C-19134-79890805; Fri, 19 Oct 2012 00:02:31 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1350604950!14568047!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgyMTI5Ng==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16354 invoked from network); 19 Oct 2012 00:02:31 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Oct 2012 00:02:31 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9J02Qnf013919
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Oct 2012 00:02:27 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9J02PRc020102
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 19 Oct 2012 00:02:26 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9J02PUu029964; Thu, 18 Oct 2012 19:02:25 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 18 Oct 2012 17:02:24 -0700
Date: Thu, 18 Oct 2012 17:02:23 -0700
From: Mukesh Rathor 
To: Ian Campbell 
Message-ID: <20121018170223.03ef0913@mantra.us.oracle.com>
In-Reply-To: <1350556553.2460.108.camel@zakaz.uk.xensource.com>
References: <20121017173448.7ef4c0b1@mantra.us.oracle.com>
	<1350556553.2460.108.camel@zakaz.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V3 6/6]: PVH:privcmd changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 18 Oct 2012 11:35:53 +0100
Ian Campbell  wrote:

> 
> > @@ -439,6 +490,19 @@ static long privcmd_ioctl(struct file *file,
> >  	return ret;
> >  }
> >  
> > +static void privcmd_close(struct vm_area_struct *vma)
> > +{
> > +	struct page **pages = vma ? vma->vm_private_data : NULL;
> 
> Can VMA really be NULL?...

Good programming I thought!

> > +	int numpgs = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
> 
> ...I assume not since you unconditionally dereference it here.

Added this later, and just didn't change the earlier part.

> > +	if (!pages || !numpgs
> > || !xen_feature(XENFEAT_auto_translated_physmap))
> 
> In the non-xlat case pages will (or should!) be 1 here which will pass
> the first clause of the test.
> 
> Although the later clauses will catch this I think it would be worth
> ordering the checks such that they are each valid, perhaps by pulling
> the feature check to the front or by separating the !xlat case from
> the other two which are valid iff xlat == True.
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 00:07:33 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 00:07:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP07N-0002pA-Oh; Fri, 19 Oct 2012 00:07:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP07M-0002p1-CL
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 00:07:12 +0000
Received: from [85.158.137.99:47874] by server-11.bemta-3.messagelabs.com id
	BB/00-24008-FA990805; Fri, 19 Oct 2012 00:07:11 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1350605230!19012455!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ5MzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1030 invoked from network); 19 Oct 2012 00:07:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 00:07:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,609,1344211200"; 
	d="asc'?scan'208";a="15265838"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 00:07:10 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 19 Oct 2012 01:07:10 +0100
Message-ID: <1350605228.5700.17.camel@Solace>
From: Dario Faggioli 
To: Ian Jackson 
Date: Fri, 19 Oct 2012 02:07:08 +0200
In-Reply-To: <20608.15472.714307.754027@mariner.uk.xensource.com>
References: <20608.15472.714307.754027@mariner.uk.xensource.com>
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Campbell , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen.org automatic Xen test system, de-tentacled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1675266950094202988=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1675266950094202988==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-jEX3YozeSJzjtCiWxvYV"

--=-jEX3YozeSJzjtCiWxvYV
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-10-18 at 18:29 +0100, Ian Jackson wrote:
> I have been working on disentangling the automatic test system
> ("osstest" on xenbits) enough that it can be run without all of its
> supporting infrastructure.
>=20
That is really great news! :-)

> If you would like to have a go:
>  - You will need local DHCP and TFTP servers, ideally on the
>    same machine
>  - You will probably need a dedicated test box.  The test system
>    likes to reinstall although it is now possible to avoid this
>  - git clone git://xenbits.xen.org/osstest.git
>  - cd osstest
>  - git checkout standalone
>  - less README
>=20
> And follow the instructions.  The README is also here:
>  http://xenbits.xen.org/gitweb/?p=3Dosstest.git;a=3Dblob;f=3DREADME;hb=3D=
standalone
>=20
Cool. I'm definitely giving it a try (probably next week).

> The instructions are still sketchy and I'm sure there are many hurdles
> and wrinkles.  So as I say this is for the brave only.  But if one or
> two people (Ian C has expressed an interest) would like to try it that
> would be helpful.
>=20
Although I have very few perl, I'll do my best to be useful too.

> I have tested, more or less recently, installing a host, running a
> complete job (including a build and a test job).
>=20
Thanks a lot for doing this... I'll finally be able to get rid of my
wonky bash scripts to achieve basically the same and start building on
top and, hopefully, contributing to something more serious, structured
and really useful to everyone! :-)

Regards,
Dario

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-jEX3YozeSJzjtCiWxvYV
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlCAmawACgkQk4XaBE3IOsT5HwCglrHUL0qHmDDO9/hk0/sXqT8I
wTUAnRw3Qa8jjo1Ncdvp+EYq43uScXT9
=dmsn
-----END PGP SIGNATURE-----

--=-jEX3YozeSJzjtCiWxvYV--


--===============1675266950094202988==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1675266950094202988==--


From xen-devel-bounces@lists.xen.org Fri Oct 19 00:07:33 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 00:07:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP07N-0002pA-Oh; Fri, 19 Oct 2012 00:07:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP07M-0002p1-CL
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 00:07:12 +0000
Received: from [85.158.137.99:47874] by server-11.bemta-3.messagelabs.com id
	BB/00-24008-FA990805; Fri, 19 Oct 2012 00:07:11 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1350605230!19012455!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ5MzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1030 invoked from network); 19 Oct 2012 00:07:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 00:07:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,609,1344211200"; 
	d="asc'?scan'208";a="15265838"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 00:07:10 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 19 Oct 2012 01:07:10 +0100
Message-ID: <1350605228.5700.17.camel@Solace>
From: Dario Faggioli 
To: Ian Jackson 
Date: Fri, 19 Oct 2012 02:07:08 +0200
In-Reply-To: <20608.15472.714307.754027@mariner.uk.xensource.com>
References: <20608.15472.714307.754027@mariner.uk.xensource.com>
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Campbell , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen.org automatic Xen test system, de-tentacled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1675266950094202988=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1675266950094202988==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-jEX3YozeSJzjtCiWxvYV"

--=-jEX3YozeSJzjtCiWxvYV
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-10-18 at 18:29 +0100, Ian Jackson wrote:
> I have been working on disentangling the automatic test system
> ("osstest" on xenbits) enough that it can be run without all of its
> supporting infrastructure.
>=20
That is really great news! :-)

> If you would like to have a go:
>  - You will need local DHCP and TFTP servers, ideally on the
>    same machine
>  - You will probably need a dedicated test box.  The test system
>    likes to reinstall although it is now possible to avoid this
>  - git clone git://xenbits.xen.org/osstest.git
>  - cd osstest
>  - git checkout standalone
>  - less README
>=20
> And follow the instructions.  The README is also here:
>  http://xenbits.xen.org/gitweb/?p=3Dosstest.git;a=3Dblob;f=3DREADME;hb=3D=
standalone
>=20
Cool. I'm definitely giving it a try (probably next week).

> The instructions are still sketchy and I'm sure there are many hurdles
> and wrinkles.  So as I say this is for the brave only.  But if one or
> two people (Ian C has expressed an interest) would like to try it that
> would be helpful.
>=20
Although I have very few perl, I'll do my best to be useful too.

> I have tested, more or less recently, installing a host, running a
> complete job (including a build and a test job).
>=20
Thanks a lot for doing this... I'll finally be able to get rid of my
wonky bash scripts to achieve basically the same and start building on
top and, hopefully, contributing to something more serious, structured
and really useful to everyone! :-)

Regards,
Dario

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-jEX3YozeSJzjtCiWxvYV
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlCAmawACgkQk4XaBE3IOsT5HwCglrHUL0qHmDDO9/hk0/sXqT8I
wTUAnRw3Qa8jjo1Ncdvp+EYq43uScXT9
=dmsn
-----END PGP SIGNATURE-----

--=-jEX3YozeSJzjtCiWxvYV--


--===============1675266950094202988==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1675266950094202988==--


From xen-devel-bounces@lists.xen.org Fri Oct 19 00:22:22 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 00:22:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP0LX-0003Uw-7w; Fri, 19 Oct 2012 00:21:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP0LV-0003Ur-92
	for Xen-devel@lists.xensource.com; Fri, 19 Oct 2012 00:21:49 +0000
Received: from [85.158.137.99:46307] by server-16.bemta-3.messagelabs.com id
	21/9E-16565-C1D90805; Fri, 19 Oct 2012 00:21:48 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1350606106!16816684!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgyMTI5Ng==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22696 invoked from network); 19 Oct 2012 00:21:47 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Oct 2012 00:21:47 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9J0LdIM026694
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Oct 2012 00:21:40 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9J0Lc99016271
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 19 Oct 2012 00:21:39 GMT
Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9J0Laxc019028; Thu, 18 Oct 2012 19:21:37 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 18 Oct 2012 17:21:35 -0700
Date: Thu, 18 Oct 2012 17:21:34 -0700
From: Mukesh Rathor 
To: "Xen-devel@lists.xensource.com" , Konrad
	Rzeszutek Wilk , Ian Campbell
	, "stefano.stabellini@eu.citrix.com"
	
Message-ID: <20121018172134.16b0ee25@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: [Xen-devel] PVH: Future work.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Here's my list of things remaining for PVH. Most are small, except
migration which I have no idea at this point what changes it would
incur:

 1. VCPU hotplug. See setup_vcpu_hotplug_event().

 2. debug and fix eio map to work with pvh. See xen_init_IRQ()

 3. have_vcpu_info_placement: enable it.

 4. investigate setup_stack_canary_segment in xen_setup_stackprotector.

 5. Use ballooning for pfn's instead of kmalloc in gnttab_resume().
 
 6. Migration.

Thanks,
Mukesh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 00:22:22 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 00:22:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP0LX-0003Uw-7w; Fri, 19 Oct 2012 00:21:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP0LV-0003Ur-92
	for Xen-devel@lists.xensource.com; Fri, 19 Oct 2012 00:21:49 +0000
Received: from [85.158.137.99:46307] by server-16.bemta-3.messagelabs.com id
	21/9E-16565-C1D90805; Fri, 19 Oct 2012 00:21:48 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1350606106!16816684!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgyMTI5Ng==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22696 invoked from network); 19 Oct 2012 00:21:47 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Oct 2012 00:21:47 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9J0LdIM026694
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Oct 2012 00:21:40 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9J0Lc99016271
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 19 Oct 2012 00:21:39 GMT
Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9J0Laxc019028; Thu, 18 Oct 2012 19:21:37 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 18 Oct 2012 17:21:35 -0700
Date: Thu, 18 Oct 2012 17:21:34 -0700
From: Mukesh Rathor 
To: "Xen-devel@lists.xensource.com" , Konrad
	Rzeszutek Wilk , Ian Campbell
	, "stefano.stabellini@eu.citrix.com"
	
Message-ID: <20121018172134.16b0ee25@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: [Xen-devel] PVH: Future work.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Here's my list of things remaining for PVH. Most are small, except
migration which I have no idea at this point what changes it would
incur:

 1. VCPU hotplug. See setup_vcpu_hotplug_event().

 2. debug and fix eio map to work with pvh. See xen_init_IRQ()

 3. have_vcpu_info_placement: enable it.

 4. investigate setup_stack_canary_segment in xen_setup_stackprotector.

 5. Use ballooning for pfn's instead of kmalloc in gnttab_resume().
 
 6. Migration.

Thanks,
Mukesh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 00:37:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 00:37:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP0a2-0003qU-RM; Fri, 19 Oct 2012 00:36:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP0a1-0003q7-DN
	for Xen-devel@lists.xensource.com; Fri, 19 Oct 2012 00:36:49 +0000
Received: from [85.158.139.83:42857] by server-7.bemta-5.messagelabs.com id
	85/96-23102-0A0A0805; Fri, 19 Oct 2012 00:36:48 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1350607006!35509548!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODE0MTgy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31507 invoked from network); 19 Oct 2012 00:36:48 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Oct 2012 00:36:48 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9J0afut000610
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Oct 2012 00:36:42 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9J0afCa014638
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 19 Oct 2012 00:36:41 GMT
Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9J0aejm014365; Thu, 18 Oct 2012 19:36:40 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 18 Oct 2012 17:36:40 -0700
Date: Thu, 18 Oct 2012 17:36:39 -0700
From: Mukesh Rathor 
To: Mukesh Rathor 
Message-ID: <20121018173639.3010f282@mantra.us.oracle.com>
In-Reply-To: <20121018172134.16b0ee25@mantra.us.oracle.com>
References: <20121018172134.16b0ee25@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "Xen-devel@lists.xensource.com" ,
	Ian Campbell ,
	"stefano.stabellini@eu.citrix.com" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] PVH: Future work.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 18 Oct 2012 17:21:34 -0700
Mukesh Rathor  wrote:

> Here's my list of things remaining for PVH. Most are small, except
> migration which I have no idea at this point what changes it would
> incur:
> 
>  1. VCPU hotplug. See setup_vcpu_hotplug_event().
> 
>  2. debug and fix eio map to work with pvh. See xen_init_IRQ()
> 
>  3. have_vcpu_info_placement: enable it.
> 
>  4. investigate setup_stack_canary_segment in
> xen_setup_stackprotector.
> 
>  5. Use ballooning for pfn's instead of kmalloc in gnttab_resume().
>  
>  6. Migration.

Add one more:

   7. Replace xen_add_to_physmap with xen_add_to_physmap_range.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 00:37:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 00:37:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP0a2-0003qU-RM; Fri, 19 Oct 2012 00:36:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP0a1-0003q7-DN
	for Xen-devel@lists.xensource.com; Fri, 19 Oct 2012 00:36:49 +0000
Received: from [85.158.139.83:42857] by server-7.bemta-5.messagelabs.com id
	85/96-23102-0A0A0805; Fri, 19 Oct 2012 00:36:48 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1350607006!35509548!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODE0MTgy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31507 invoked from network); 19 Oct 2012 00:36:48 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Oct 2012 00:36:48 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9J0afut000610
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Oct 2012 00:36:42 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9J0afCa014638
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 19 Oct 2012 00:36:41 GMT
Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9J0aejm014365; Thu, 18 Oct 2012 19:36:40 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 18 Oct 2012 17:36:40 -0700
Date: Thu, 18 Oct 2012 17:36:39 -0700
From: Mukesh Rathor 
To: Mukesh Rathor 
Message-ID: <20121018173639.3010f282@mantra.us.oracle.com>
In-Reply-To: <20121018172134.16b0ee25@mantra.us.oracle.com>
References: <20121018172134.16b0ee25@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "Xen-devel@lists.xensource.com" ,
	Ian Campbell ,
	"stefano.stabellini@eu.citrix.com" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] PVH: Future work.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 18 Oct 2012 17:21:34 -0700
Mukesh Rathor  wrote:

> Here's my list of things remaining for PVH. Most are small, except
> migration which I have no idea at this point what changes it would
> incur:
> 
>  1. VCPU hotplug. See setup_vcpu_hotplug_event().
> 
>  2. debug and fix eio map to work with pvh. See xen_init_IRQ()
> 
>  3. have_vcpu_info_placement: enable it.
> 
>  4. investigate setup_stack_canary_segment in
> xen_setup_stackprotector.
> 
>  5. Use ballooning for pfn's instead of kmalloc in gnttab_resume().
>  
>  6. Migration.

Add one more:

   7. Replace xen_add_to_physmap with xen_add_to_physmap_range.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 01:08:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 01:08:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP14I-00080P-Re; Fri, 19 Oct 2012 01:08:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP14H-00080K-VL
	for xen-devel@lists.xensource.com; Fri, 19 Oct 2012 01:08:06 +0000
Received: from [85.158.137.99:32326] by server-6.bemta-3.messagelabs.com id
	EA/D4-32375-5F7A0805; Fri, 19 Oct 2012 01:08:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1350608884!17436024!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ5MzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15806 invoked from network); 19 Oct 2012 01:08:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 01:08:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,609,1344211200"; d="scan'208";a="15266079"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 01:08:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 19 Oct 2012 02:08:03 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TP14F-0003Po-Gk;
	Fri, 19 Oct 2012 01:08:03 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TP14F-0007kJ-FC;
	Fri, 19 Oct 2012 02:08:03 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Fri, 19 Oct 2012 02:08:03 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14045: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14045 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14045/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 13967
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 13967
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 13967
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 13967

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                    fail pass in 14038

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13967
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13967
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13967
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13967

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  3fa2ab30bb05
baseline version:
 xen                  c1c549c4fe9e

------------------------------------------------------------
People who touched revisions under test:
  Chuang Cao 
  Daniel De Graaf 
  Huang Ying 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Joe Jin 
  Keir Fraser 
  Olaf Hering 
  Sander Eikelenboom 
  Stefano Stabellini 
  Tim Deegan 
  Xiantao Zhang
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 592 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 01:08:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 01:08:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP14I-00080P-Re; Fri, 19 Oct 2012 01:08:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP14H-00080K-VL
	for xen-devel@lists.xensource.com; Fri, 19 Oct 2012 01:08:06 +0000
Received: from [85.158.137.99:32326] by server-6.bemta-3.messagelabs.com id
	EA/D4-32375-5F7A0805; Fri, 19 Oct 2012 01:08:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1350608884!17436024!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ5MzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15806 invoked from network); 19 Oct 2012 01:08:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 01:08:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,609,1344211200"; d="scan'208";a="15266079"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 01:08:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 19 Oct 2012 02:08:03 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TP14F-0003Po-Gk;
	Fri, 19 Oct 2012 01:08:03 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TP14F-0007kJ-FC;
	Fri, 19 Oct 2012 02:08:03 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Fri, 19 Oct 2012 02:08:03 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14045: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14045 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14045/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 13967
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 13967
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 13967
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 13967

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                    fail pass in 14038

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13967
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13967
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13967
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13967

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  3fa2ab30bb05
baseline version:
 xen                  c1c549c4fe9e

------------------------------------------------------------
People who touched revisions under test:
  Chuang Cao 
  Daniel De Graaf 
  Huang Ying 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Joe Jin 
  Keir Fraser 
  Olaf Hering 
  Sander Eikelenboom 
  Stefano Stabellini 
  Tim Deegan 
  Xiantao Zhang
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 592 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 01:35:26 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 01:35:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP1UN-0008DU-HE; Fri, 19 Oct 2012 01:35:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP1UL-0008DP-Np
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 01:35:01 +0000
Received: from [85.158.139.83:48686] by server-8.bemta-5.messagelabs.com id
	10/61-23193-44EA0805; Fri, 19 Oct 2012 01:35:00 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-11.tower-182.messagelabs.com!1350610496!28315891!1
X-Originating-IP: [203.16.207.99]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6359 invoked from network); 19 Oct 2012 01:34:59 -0000
Received: from mail.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-11.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	19 Oct 2012 01:34:59 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp2.bendigoit.com.au with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP1U9-0000AO-9Z; Fri, 19 Oct 2012 12:34:49 +1100
Received: from BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d]) by
	BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d%12]) with mapi id
	14.01.0421.002; Fri, 19 Oct 2012 12:34:43 +1100
From: James Harper 
To: Roger Pau Monne , "xen-devel@lists.xen.org"
	
Thread-Topic: [Xen-devel] [PATCH RFC] Persistent grant maps for xen blk drivers
Thread-Index: AQHNrSPHQ3cOVHsv2Ui1q3f+GnpWRpe+90Qg
Date: Fri, 19 Oct 2012 01:34:40 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B32C1043A@BITCOM1.int.sbss.com.au>
References: <1350559321-19066-1-git-send-email-roger.pau@citrix.com>
In-Reply-To: <1350559321-19066-1-git-send-email-roger.pau@citrix.com>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.222.114]
x-tm-as-product-ver: SMEX-10.2.0.2087-7.000.1014-19286.001
x-tm-as-result: No--39.354100-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Cc: Oliver Chick ,
	"linux-kernel@vger.kernel.org" ,
	"konrad.wilk@oracle.com" 
Subject: Re: [Xen-devel] [PATCH RFC] Persistent grant maps for xen blk
 drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> 
> This patch implements persistent grants for the xen-blk{front,back}
> mechanism. The effect of this change is to reduce the number of unmap
> operations performed, since they cause a (costly) TLB shootdown. This allows
> the I/O performance to scale better when a large number of VMs are
> performing I/O.
> 
> Previously, the blkfront driver was supplied a bvec[] from the request
> queue. This was granted to dom0; dom0 performed the I/O and wrote
> directly into the grant-mapped memory and unmapped it; blkfront then
> removed foreign access for that grant. The cost of unmapping scales badly
> with the number of CPUs in Dom0. An experiment showed that when
> Dom0 has 24 VCPUs, and guests are performing parallel I/O to a ramdisk, the
> IPIs from performing unmap's is a bottleneck at 5 guests (at which point
> 650,000 IOPS are being performed in total). If more than 5 guests are used,
> the performance declines. By 10 guests, only
> 400,000 IOPS are being performed.
> 
> This patch improves performance by only unmapping when the connection
> between blkfront and back is broken.

I assume network drivers would suffer from the same affliction... Would a more general persistent map solution be worth considering (or be possible)? So a common interface to this persistent mapping allowing the persistent pool to be shared between all drivers in the DomU?

James


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 01:35:26 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 01:35:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP1UN-0008DU-HE; Fri, 19 Oct 2012 01:35:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP1UL-0008DP-Np
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 01:35:01 +0000
Received: from [85.158.139.83:48686] by server-8.bemta-5.messagelabs.com id
	10/61-23193-44EA0805; Fri, 19 Oct 2012 01:35:00 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-11.tower-182.messagelabs.com!1350610496!28315891!1
X-Originating-IP: [203.16.207.99]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6359 invoked from network); 19 Oct 2012 01:34:59 -0000
Received: from mail.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-11.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	19 Oct 2012 01:34:59 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp2.bendigoit.com.au with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP1U9-0000AO-9Z; Fri, 19 Oct 2012 12:34:49 +1100
Received: from BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d]) by
	BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d%12]) with mapi id
	14.01.0421.002; Fri, 19 Oct 2012 12:34:43 +1100
From: James Harper 
To: Roger Pau Monne , "xen-devel@lists.xen.org"
	
Thread-Topic: [Xen-devel] [PATCH RFC] Persistent grant maps for xen blk drivers
Thread-Index: AQHNrSPHQ3cOVHsv2Ui1q3f+GnpWRpe+90Qg
Date: Fri, 19 Oct 2012 01:34:40 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B32C1043A@BITCOM1.int.sbss.com.au>
References: <1350559321-19066-1-git-send-email-roger.pau@citrix.com>
In-Reply-To: <1350559321-19066-1-git-send-email-roger.pau@citrix.com>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.222.114]
x-tm-as-product-ver: SMEX-10.2.0.2087-7.000.1014-19286.001
x-tm-as-result: No--39.354100-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Cc: Oliver Chick ,
	"linux-kernel@vger.kernel.org" ,
	"konrad.wilk@oracle.com" 
Subject: Re: [Xen-devel] [PATCH RFC] Persistent grant maps for xen blk
 drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> 
> This patch implements persistent grants for the xen-blk{front,back}
> mechanism. The effect of this change is to reduce the number of unmap
> operations performed, since they cause a (costly) TLB shootdown. This allows
> the I/O performance to scale better when a large number of VMs are
> performing I/O.
> 
> Previously, the blkfront driver was supplied a bvec[] from the request
> queue. This was granted to dom0; dom0 performed the I/O and wrote
> directly into the grant-mapped memory and unmapped it; blkfront then
> removed foreign access for that grant. The cost of unmapping scales badly
> with the number of CPUs in Dom0. An experiment showed that when
> Dom0 has 24 VCPUs, and guests are performing parallel I/O to a ramdisk, the
> IPIs from performing unmap's is a bottleneck at 5 guests (at which point
> 650,000 IOPS are being performed in total). If more than 5 guests are used,
> the performance declines. By 10 guests, only
> 400,000 IOPS are being performed.
> 
> This patch improves performance by only unmapping when the connection
> between blkfront and back is broken.

I assume network drivers would suffer from the same affliction... Would a more general persistent map solution be worth considering (or be possible)? So a common interface to this persistent mapping allowing the persistent pool to be shared between all drivers in the DomU?

James


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 01:47:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 01:47:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP1gI-0008RE-Vb; Fri, 19 Oct 2012 01:47:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP1gI-0008R9-1v
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 01:47:22 +0000
Received: from [85.158.137.99:33195] by server-5.bemta-3.messagelabs.com id
	CB/E7-12440-921B0805; Fri, 19 Oct 2012 01:47:21 +0000
X-Env-Sender: george.shuklin@gmail.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1350611239!17112533!1
X-Originating-IP: [209.85.215.45]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_60_70,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2831 invoked from network); 19 Oct 2012 01:47:19 -0000
Received: from mail-la0-f45.google.com (HELO mail-la0-f45.google.com)
	(209.85.215.45)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 01:47:19 -0000
Received: by mail-la0-f45.google.com with SMTP id m13so7650808lah.32
	for ; Thu, 18 Oct 2012 18:47:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:subject:references
	:in-reply-to:content-type;
	bh=nlv5uelM29j9VCaEUKyODZAo5R2ZrydooGW4E4SIRp4=;
	b=OM+oINUVyI1G77Ox6mJJPzdG7DULDM5u7HpRX7rvBxrZUrJteX3SMVVD90Yux/rIIX
	l2USZ7dzxS8Mv0tbalVF+gkhHIloCQCH0bumsbL2sOSf9V36YMw6vsXDwa232fGxce1M
	Bt6dtxFeXTAuhKHMWGT6yhW3ty4sh9Xm0dA+b7qin/lO7TE/IbFGukUOaK/6A/zGwBI3
	DV4taC5cbuO54QPrDFg/49gMyXPCGKT5HdxoIQesRnml2Iy2VZ/kSc1uHbOneTdJ3tKs
	YndQVQMmce0yZO2qoet9WaJ1E3skOj4nf7Qgkdbaha4Wp5JNvQy3XkSkIklDQ/IgkWJj
	tDNA==
Received: by 10.112.24.40 with SMTP id r8mr26080lbf.99.1350611238684;
	Thu, 18 Oct 2012 18:47:18 -0700 (PDT)
Received: from home.desunote.ru ([2a00:11d8:1201:0:962b:18:e716:fb97])
	by mx.google.com with ESMTPS id xw14sm59987lab.15.2012.10.18.18.47.17
	(version=SSLv3 cipher=OTHER); Thu, 18 Oct 2012 18:47:17 -0700 (PDT)
Message-ID: <5080B158.6030908@gmail.com>
Date: Fri, 19 Oct 2012 05:48:08 +0400
From: George Shuklin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.7) Gecko/20120922 Icedove/10.0.7
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <1349936188.70593.YahooMailNeo@web120006.mail.ne1.yahoo.com>
In-Reply-To: <1349936188.70593.YahooMailNeo@web120006.mail.ne1.yahoo.com>
Subject: Re: [Xen-devel] Dom0 IO handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============8326202991560825680=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============8326202991560825680==
Content-Type: multipart/alternative;
 boundary="------------030909090509070501010003"

This is a multi-part message in MIME format.
--------------030909090509070501010003
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

AFAIK dom0 is pv-domain.
All interrupts are handled by xen and passed down to dom0 via events 
(kinda internal  xen interrupt-like stuff). PV kernel accepts them and 
process as normal interrupts.

Is Xen use IOMMU to protect itself from misbehave devices or not... I'm 
not sure.

On 11.10.2012 10:16, maheen butt wrote:
> Hi all,
>
> I'm investigating the source code of Xenified kernel. From 
> documentations related to
> Xen told me that all guest domains run in less privilege mode ( ring 1 
> in case of x86).
> Dom0 is also running in ring 1. But it can have direct access to IO 
> devices. It means
> Dom0 has a special bahaviour that it is running in ring1 but can 
> directly access IO devices.
> How Dom0 access IO devices directly?
> how can I relate this special way of Dom0 with its source code?
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

--------------030909090509070501010003
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    AFAIK dom0 is pv-domain.

    All interrupts are handled by xen and passed down to dom0 via events
    (kinda internal  xen interrupt-like stuff). PV kernel accepts them
    and process as normal interrupts. 

    

    Is Xen use IOMMU to protect itself from misbehave devices or not...
    I'm not sure.

    

    On 11.10.2012 10:16, maheen butt wrote:
    

      

        
Hi all,

        


        

        
I'm investigating the source
          code of Xenified kernel. From documentations related to 

        

        
Xen told me that all guest
          domains run in less privilege mode ( ring 1 in case of x86).

        
Dom0 is also running in ring
          1. But it can have direct access to IO devices. It means 

        

        
Dom0 has a special bahaviour
          that it is running in ring1 but can directly access IO
          devices.

        
How Dom0 access IO devices
          directly?

        
 how can I relate this
          special way of Dom0 with its source code?

      

      

      

      

      
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


    

  


--------------030909090509070501010003--


--===============8326202991560825680==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8326202991560825680==--


From xen-devel-bounces@lists.xen.org Fri Oct 19 01:47:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 01:47:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP1gI-0008RE-Vb; Fri, 19 Oct 2012 01:47:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP1gI-0008R9-1v
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 01:47:22 +0000
Received: from [85.158.137.99:33195] by server-5.bemta-3.messagelabs.com id
	CB/E7-12440-921B0805; Fri, 19 Oct 2012 01:47:21 +0000
X-Env-Sender: george.shuklin@gmail.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1350611239!17112533!1
X-Originating-IP: [209.85.215.45]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_60_70,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2831 invoked from network); 19 Oct 2012 01:47:19 -0000
Received: from mail-la0-f45.google.com (HELO mail-la0-f45.google.com)
	(209.85.215.45)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 01:47:19 -0000
Received: by mail-la0-f45.google.com with SMTP id m13so7650808lah.32
	for ; Thu, 18 Oct 2012 18:47:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:subject:references
	:in-reply-to:content-type;
	bh=nlv5uelM29j9VCaEUKyODZAo5R2ZrydooGW4E4SIRp4=;
	b=OM+oINUVyI1G77Ox6mJJPzdG7DULDM5u7HpRX7rvBxrZUrJteX3SMVVD90Yux/rIIX
	l2USZ7dzxS8Mv0tbalVF+gkhHIloCQCH0bumsbL2sOSf9V36YMw6vsXDwa232fGxce1M
	Bt6dtxFeXTAuhKHMWGT6yhW3ty4sh9Xm0dA+b7qin/lO7TE/IbFGukUOaK/6A/zGwBI3
	DV4taC5cbuO54QPrDFg/49gMyXPCGKT5HdxoIQesRnml2Iy2VZ/kSc1uHbOneTdJ3tKs
	YndQVQMmce0yZO2qoet9WaJ1E3skOj4nf7Qgkdbaha4Wp5JNvQy3XkSkIklDQ/IgkWJj
	tDNA==
Received: by 10.112.24.40 with SMTP id r8mr26080lbf.99.1350611238684;
	Thu, 18 Oct 2012 18:47:18 -0700 (PDT)
Received: from home.desunote.ru ([2a00:11d8:1201:0:962b:18:e716:fb97])
	by mx.google.com with ESMTPS id xw14sm59987lab.15.2012.10.18.18.47.17
	(version=SSLv3 cipher=OTHER); Thu, 18 Oct 2012 18:47:17 -0700 (PDT)
Message-ID: <5080B158.6030908@gmail.com>
Date: Fri, 19 Oct 2012 05:48:08 +0400
From: George Shuklin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.7) Gecko/20120922 Icedove/10.0.7
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <1349936188.70593.YahooMailNeo@web120006.mail.ne1.yahoo.com>
In-Reply-To: <1349936188.70593.YahooMailNeo@web120006.mail.ne1.yahoo.com>
Subject: Re: [Xen-devel] Dom0 IO handling
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============8326202991560825680=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============8326202991560825680==
Content-Type: multipart/alternative;
 boundary="------------030909090509070501010003"

This is a multi-part message in MIME format.
--------------030909090509070501010003
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

AFAIK dom0 is pv-domain.
All interrupts are handled by xen and passed down to dom0 via events 
(kinda internal  xen interrupt-like stuff). PV kernel accepts them and 
process as normal interrupts.

Is Xen use IOMMU to protect itself from misbehave devices or not... I'm 
not sure.

On 11.10.2012 10:16, maheen butt wrote:
> Hi all,
>
> I'm investigating the source code of Xenified kernel. From 
> documentations related to
> Xen told me that all guest domains run in less privilege mode ( ring 1 
> in case of x86).
> Dom0 is also running in ring 1. But it can have direct access to IO 
> devices. It means
> Dom0 has a special bahaviour that it is running in ring1 but can 
> directly access IO devices.
> How Dom0 access IO devices directly?
> how can I relate this special way of Dom0 with its source code?
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

--------------030909090509070501010003
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    AFAIK dom0 is pv-domain.

    All interrupts are handled by xen and passed down to dom0 via events
    (kinda internal  xen interrupt-like stuff). PV kernel accepts them
    and process as normal interrupts. 

    

    Is Xen use IOMMU to protect itself from misbehave devices or not...
    I'm not sure.

    

    On 11.10.2012 10:16, maheen butt wrote:
    

      

        
Hi all,

        


        

        
I'm investigating the source
          code of Xenified kernel. From documentations related to 

        

        
Xen told me that all guest
          domains run in less privilege mode ( ring 1 in case of x86).

        
Dom0 is also running in ring
          1. But it can have direct access to IO devices. It means 

        

        
Dom0 has a special bahaviour
          that it is running in ring1 but can directly access IO
          devices.

        
How Dom0 access IO devices
          directly?

        
 how can I relate this
          special way of Dom0 with its source code?

      

      

      

      

      
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


    

  


--------------030909090509070501010003--


--===============8326202991560825680==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8326202991560825680==--


From xen-devel-bounces@lists.xen.org Fri Oct 19 02:13:21 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 02:13:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP24s-0000aV-Oe; Fri, 19 Oct 2012 02:12:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP24r-0000aQ-7R
	for xen-devel@lists.xensource.com; Fri, 19 Oct 2012 02:12:45 +0000
Received: from [85.158.139.211:24914] by server-3.bemta-5.messagelabs.com id
	28/39-28618-C17B0805; Fri, 19 Oct 2012 02:12:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1350612763!22853594!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ5MzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31823 invoked from network); 19 Oct 2012 02:12:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 02:12:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,610,1344211200"; d="scan'208";a="15266263"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 02:12:43 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 19 Oct 2012 03:12:43 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TP24p-0003mh-1O;
	Fri, 19 Oct 2012 02:12:43 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TP24o-0000VW-OY;
	Fri, 19 Oct 2012 03:12:42 +0100
To: 
Message-ID: 
From: xen.org 
Date: Fri, 19 Oct 2012 03:12:42 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete build-amd64-oldkern
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

branch xen-unstable
xen branch xen-unstable
job build-amd64-oldkern
test xen-build

Tree: linux http://xenbits.xen.org/linux-2.6.18-xen.hg
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen http://xenbits.xen.org/hg/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux http://xenbits.xen.org/linux-2.6.18-xen.hg
  Bug introduced:  c5d77641c738
  Bug not present: 9db2ee23611e


  changeset:   1199:c5d77641c738
  tag:         tip
  user:        Jan Beulich 
  date:        Wed Oct 17 10:58:39 2012 +0200
      
      fix hypercall fallback code for very old hypervisors
      
      While copying the argument structures in HYPERVISOR_event_channel_op()
      and HYPERVISOR_physdev_op() into the local variable is sufficiently
      safe even if the actual structure is smaller than the container one,
      copying back eventual output values the same way isn't: This may
      collide with on-stack variables (particularly "rc") which may change
      between the first and second memcpy() (i.e. the second memcpy() could
      discard that change).
      
      Move the fallback code into out-of-line functions, and handle all of
      the operations known by this old a hypervisor individually: Some don't
      require copying back anything at all, and for the rest use the
      individual argument structures' sizes rather than the container's.
      
      Reported-by: Dan Carpenter 
      Signed-off-by: Jan Beulich 
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.build-amd64-oldkern.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 14045 fail [host=lace-bug] / 13979 [host=gall-mite] 13973 ok.
Failure / basis pass flights: 14045 / 13973
Tree: linux http://xenbits.xen.org/linux-2.6.18-xen.hg
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
Latest c5d77641c738 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 3fa2ab30bb05
Basis pass 480fbb0fc4b5 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
Generating revisions with ./adhoc-revtuple-generator  http://xenbits.xen.org/linux-2.6.18-xen.hg#480fbb0fc4b5-c5d77641c738 git://xenbits.xen.org/staging/qemu-xen-unstable.git#bacc0d302445c75f18f4c826750fb5853b60e7ca-bacc0d302445c75f18f4c826750fb5853b60e7ca git://xenbits.xen.org/staging/qemu-upstream-unstable.git#cdf4d2bb4006805f209712fbb8ed1f83127e9984-cdf4d2bb4006805f209712fbb8ed1f83127e9984 http://xenbits.xen.org/hg/staging/xen-unstable.hg#4fc87c2f31a0-3fa2ab30bb05
pulling from ssh://xen@xenbits.xen.org/HG/linux-2.6.18-xen.hg
searching for changes
no changes found
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
pulling from ssh://xen@xenbits.xen.org/HG/linux-2.6.18-xen.hg
searching for changes
no changes found
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
Loaded 1273 nodes in revision graph
Searching for test results:
 13972 pass 480fbb0fc4b5 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 13973 pass 480fbb0fc4b5 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 13979 [host=gall-mite]
 13995 fail c5d77641c738 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4b4c0c7a6031
 14001 fail c5d77641c738 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 1f4be6ee4619
 14007 fail c5d77641c738 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 5c402b905e00
 14060 fail c5d77641c738 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 14011 fail c5d77641c738 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 5c402b905e00
 14017 fail c5d77641c738 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 5c402b905e00
 14038 fail c5d77641c738 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 3fa2ab30bb05
 14052 pass 480fbb0fc4b5 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 14032 fail c5d77641c738 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 3fa2ab30bb05
 14053 fail c5d77641c738 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 3fa2ab30bb05
 14054 pass 9db2ee23611e bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 14055 fail c5d77641c738 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 14045 fail c5d77641c738 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 3fa2ab30bb05
 14056 pass 9db2ee23611e bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 14058 fail c5d77641c738 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 14059 pass 9db2ee23611e bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
Searching for interesting versions
 Result found: flight 13972 (pass), for basis pass
 Result found: flight 14032 (fail), for basis failure
 Repro found: flight 14052 (pass), for basis pass
 Repro found: flight 14053 (fail), for basis failure
 0 revisions at 9db2ee23611e bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
No revisions left to test, checking graph state.
 Result found: flight 14054 (pass), for last pass
 Result found: flight 14055 (fail), for first failure
 Repro found: flight 14056 (pass), for last pass
 Repro found: flight 14058 (fail), for first failure
 Repro found: flight 14059 (pass), for last pass
 Repro found: flight 14060 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux http://xenbits.xen.org/linux-2.6.18-xen.hg
  Bug introduced:  c5d77641c738
  Bug not present: 9db2ee23611e

pulling from ssh://xen@xenbits.xen.org/HG/linux-2.6.18-xen.hg
searching for changes
no changes found

  changeset:   1199:c5d77641c738
  tag:         tip
  user:        Jan Beulich 
  date:        Wed Oct 17 10:58:39 2012 +0200
      
      fix hypercall fallback code for very old hypervisors
      
      While copying the argument structures in HYPERVISOR_event_channel_op()
      and HYPERVISOR_physdev_op() into the local variable is sufficiently
      safe even if the actual structure is smaller than the container one,
      copying back eventual output values the same way isn't: This may
      collide with on-stack variables (particularly "rc") which may change
      between the first and second memcpy() (i.e. the second memcpy() could
      discard that change).
      
      Move the fallback code into out-of-line functions, and handle all of
      the operations known by this old a hypervisor individually: Some don't
      require copying back anything at all, and for the rest use the
      individual argument structures' sizes rather than the container's.
      
      Reported-by: Dan Carpenter 
      Signed-off-by: Jan Beulich 
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.build-amd64-oldkern.xen-build.{dot,ps,png,html}.
----------------------------------------
14060: tolerable ALL FAIL

flight 14060 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14060/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 build-amd64-oldkern           4 xen-build               fail baseline untested


jobs:
 build-amd64-oldkern                                          fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 02:13:21 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 02:13:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP24s-0000aV-Oe; Fri, 19 Oct 2012 02:12:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP24r-0000aQ-7R
	for xen-devel@lists.xensource.com; Fri, 19 Oct 2012 02:12:45 +0000
Received: from [85.158.139.211:24914] by server-3.bemta-5.messagelabs.com id
	28/39-28618-C17B0805; Fri, 19 Oct 2012 02:12:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1350612763!22853594!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ5MzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31823 invoked from network); 19 Oct 2012 02:12:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 02:12:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,610,1344211200"; d="scan'208";a="15266263"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 02:12:43 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 19 Oct 2012 03:12:43 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TP24p-0003mh-1O;
	Fri, 19 Oct 2012 02:12:43 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TP24o-0000VW-OY;
	Fri, 19 Oct 2012 03:12:42 +0100
To: 
Message-ID: 
From: xen.org 
Date: Fri, 19 Oct 2012 03:12:42 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete build-amd64-oldkern
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

branch xen-unstable
xen branch xen-unstable
job build-amd64-oldkern
test xen-build

Tree: linux http://xenbits.xen.org/linux-2.6.18-xen.hg
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen http://xenbits.xen.org/hg/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux http://xenbits.xen.org/linux-2.6.18-xen.hg
  Bug introduced:  c5d77641c738
  Bug not present: 9db2ee23611e


  changeset:   1199:c5d77641c738
  tag:         tip
  user:        Jan Beulich 
  date:        Wed Oct 17 10:58:39 2012 +0200
      
      fix hypercall fallback code for very old hypervisors
      
      While copying the argument structures in HYPERVISOR_event_channel_op()
      and HYPERVISOR_physdev_op() into the local variable is sufficiently
      safe even if the actual structure is smaller than the container one,
      copying back eventual output values the same way isn't: This may
      collide with on-stack variables (particularly "rc") which may change
      between the first and second memcpy() (i.e. the second memcpy() could
      discard that change).
      
      Move the fallback code into out-of-line functions, and handle all of
      the operations known by this old a hypervisor individually: Some don't
      require copying back anything at all, and for the rest use the
      individual argument structures' sizes rather than the container's.
      
      Reported-by: Dan Carpenter 
      Signed-off-by: Jan Beulich 
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.build-amd64-oldkern.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 14045 fail [host=lace-bug] / 13979 [host=gall-mite] 13973 ok.
Failure / basis pass flights: 14045 / 13973
Tree: linux http://xenbits.xen.org/linux-2.6.18-xen.hg
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
Latest c5d77641c738 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 3fa2ab30bb05
Basis pass 480fbb0fc4b5 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
Generating revisions with ./adhoc-revtuple-generator  http://xenbits.xen.org/linux-2.6.18-xen.hg#480fbb0fc4b5-c5d77641c738 git://xenbits.xen.org/staging/qemu-xen-unstable.git#bacc0d302445c75f18f4c826750fb5853b60e7ca-bacc0d302445c75f18f4c826750fb5853b60e7ca git://xenbits.xen.org/staging/qemu-upstream-unstable.git#cdf4d2bb4006805f209712fbb8ed1f83127e9984-cdf4d2bb4006805f209712fbb8ed1f83127e9984 http://xenbits.xen.org/hg/staging/xen-unstable.hg#4fc87c2f31a0-3fa2ab30bb05
pulling from ssh://xen@xenbits.xen.org/HG/linux-2.6.18-xen.hg
searching for changes
no changes found
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
pulling from ssh://xen@xenbits.xen.org/HG/linux-2.6.18-xen.hg
searching for changes
no changes found
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
Loaded 1273 nodes in revision graph
Searching for test results:
 13972 pass 480fbb0fc4b5 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 13973 pass 480fbb0fc4b5 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 13979 [host=gall-mite]
 13995 fail c5d77641c738 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4b4c0c7a6031
 14001 fail c5d77641c738 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 1f4be6ee4619
 14007 fail c5d77641c738 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 5c402b905e00
 14060 fail c5d77641c738 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 14011 fail c5d77641c738 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 5c402b905e00
 14017 fail c5d77641c738 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 5c402b905e00
 14038 fail c5d77641c738 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 3fa2ab30bb05
 14052 pass 480fbb0fc4b5 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 14032 fail c5d77641c738 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 3fa2ab30bb05
 14053 fail c5d77641c738 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 3fa2ab30bb05
 14054 pass 9db2ee23611e bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 14055 fail c5d77641c738 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 14045 fail c5d77641c738 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 3fa2ab30bb05
 14056 pass 9db2ee23611e bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 14058 fail c5d77641c738 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
 14059 pass 9db2ee23611e bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
Searching for interesting versions
 Result found: flight 13972 (pass), for basis pass
 Result found: flight 14032 (fail), for basis failure
 Repro found: flight 14052 (pass), for basis pass
 Repro found: flight 14053 (fail), for basis failure
 0 revisions at 9db2ee23611e bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
No revisions left to test, checking graph state.
 Result found: flight 14054 (pass), for last pass
 Result found: flight 14055 (fail), for first failure
 Repro found: flight 14056 (pass), for last pass
 Repro found: flight 14058 (fail), for first failure
 Repro found: flight 14059 (pass), for last pass
 Repro found: flight 14060 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux http://xenbits.xen.org/linux-2.6.18-xen.hg
  Bug introduced:  c5d77641c738
  Bug not present: 9db2ee23611e

pulling from ssh://xen@xenbits.xen.org/HG/linux-2.6.18-xen.hg
searching for changes
no changes found

  changeset:   1199:c5d77641c738
  tag:         tip
  user:        Jan Beulich 
  date:        Wed Oct 17 10:58:39 2012 +0200
      
      fix hypercall fallback code for very old hypervisors
      
      While copying the argument structures in HYPERVISOR_event_channel_op()
      and HYPERVISOR_physdev_op() into the local variable is sufficiently
      safe even if the actual structure is smaller than the container one,
      copying back eventual output values the same way isn't: This may
      collide with on-stack variables (particularly "rc") which may change
      between the first and second memcpy() (i.e. the second memcpy() could
      discard that change).
      
      Move the fallback code into out-of-line functions, and handle all of
      the operations known by this old a hypervisor individually: Some don't
      require copying back anything at all, and for the rest use the
      individual argument structures' sizes rather than the container's.
      
      Reported-by: Dan Carpenter 
      Signed-off-by: Jan Beulich 
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.build-amd64-oldkern.xen-build.{dot,ps,png,html}.
----------------------------------------
14060: tolerable ALL FAIL

flight 14060 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14060/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 build-amd64-oldkern           4 xen-build               fail baseline untested


jobs:
 build-amd64-oldkern                                          fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 02:20:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 02:20:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP2C1-0000ja-Ne; Fri, 19 Oct 2012 02:20:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP2C0-0000jS-Nc
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 02:20:09 +0000
Received: from [85.158.137.99:4275] by server-1.bemta-3.messagelabs.com id
	C2/39-31728-7D8B0805; Fri, 19 Oct 2012 02:20:07 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-7.tower-217.messagelabs.com!1350613204!17373685!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8551 invoked from network); 19 Oct 2012 02:20:06 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 02:20:06 -0000
Received: by mail-ie0-f173.google.com with SMTP id 17so18302041iea.32
	for ; Thu, 18 Oct 2012 19:20:04 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=content-type:mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=TU6FXngUVTasI2VDjLnLb1DBDCqYRHiAYsE553zW674=;
	b=MrR3bdJdottyBHj8Zm8Gs9LMVWbUw08nO+VJQLmdW26EewW6DV+S1dySHRKnIKKUTQ
	qzvt8LOZEP+XOmvpu7bGbF43D//Q/hEI4ArJmqpQKfZMSqltcurU1UyPyNMisHJRIO70
	G2/iC94GnqfF3LnWm09qVQPmrGWshVevDEfKpTzwCQ8+lx9UKfexcYgISATjEBLSwxEq
	KnvhRBbb4BNAqqErJgiy2lFtgiEzBSjfvIDYi4Q5wFjwacVieWbW8Z0oT3rn3WrMkHtj
	KsN4H7sqijJVJrZ2veMx78tV9K5UbNcTA1e+iWV1BK8kEzYqCLhWpbfvxjK2UB5kWs0x
	Tm5g==
Received: by 10.50.0.168 with SMTP id 8mr7001903igf.24.1350613204417;
	Thu, 18 Oct 2012 19:20:04 -0700 (PDT)
Received: from [192.168.1.101] (69-165-161-147.dsl.teksavvy.com.
	[69.165.161.147])
	by mx.google.com with ESMTPS id vq4sm14849036igb.10.2012.10.18.19.20.01
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 18 Oct 2012 19:20:02 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Andres Lagar-Cavilla 
In-Reply-To: <1350547689.28188.31.camel@dagon.hellion.org.uk>
Date: Thu, 18 Oct 2012 22:20:03 -0400
Message-Id: 
References: <5171750d133ef2c27ac8.1350055853@xdev.gridcentric.ca>
	<1350547689.28188.31.camel@dagon.hellion.org.uk>
To: Ian Campbell 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQmtMp48zsfrA03TizvkaCPVzaK4m0T0+0GfZ/WuG67e3JJOSkXnsIsUoiQvzKVeHvHMSQkg
Cc: Christoph Egger ,
	Ian Jackson ,
	"xen-devel@lists.xen.org" ,
	Andres Lagar-Cavilla ,
	Attilio Rao ,
	Roger Pau Monne 
Subject: Re: [Xen-devel] [PATCH] Synchronize privcmd header constants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I've had a look. The xen.org tree knows about three other OSes: minios, solaris and netbsd. None knows about paged out frames. None uses the XEN_DOMCTL_PFINFO_PAGEDTAB constant in domctl.h

1. The domctl.h constant can still go away without hurting other OSes.
2. It is trivial to add the PRIVCMD_MMAPBATCH_* constants to the privcmd.h of other OSes. It can't hurt. I can do it here. Each OS Xen maintainer would have to take care of syncing that up in the respective upstream. However ...
3. Not that trivial to teach all these OSes about paged out frames. Does anyone care?

Please advise.
Thanks
Andres

On Oct 18, 2012, at 4:08 AM, Ian Campbell  wrote:

> On Fri, 2012-10-12 at 16:30 +0100, Andres Lagar-Cavilla wrote:
>> tools/include/xen-sys/Linux/privcmd.h |   3 +++
>> tools/libxc/xc_linux_osdep.c          |  10 +++++-----
>> xen/include/public/domctl.h           |   1 -
>> 3 files changed, 8 insertions(+), 6 deletions(-)
>> 
>> 
>> Since Linux's git commit ceb90fa0a8008059ecbbf9114cb89dc71a730bb6, the
>> privcmd.h interface between Linux and libxc specifies two new constants,
>> PRIVCMD_MMAPBATCH_MFN_ERROR and PRIVCMD_MMAPBATCH_PAGED_ERROR. These constants
>> represent the error codes encoded in the top nibble of an mfn slot passed to
>> the legacy MMAPBATCH ioctl.
>> 
>> In particular, libxenctrl checks for the equivalent of the latter constant when
>> dealing with paged out frames that might be the target of a foreign map.
>> 
>> Previously, the relevant constant was defined in the domctl hypervisor
>> interface header (XEN_DOMCTL_PFINFO_PAGEDTAB). Because this top-nibble encoding
>> is a contract between the dom0 kernel and libxc, a domctl.h definition is
>> misplaced.
>> 
>> - Sync the privcmd.h header to that now available in upstream Linux
> 
> Although the ioctl is Linux specific is the top-nibble behaviour (and
> therefore the #define) common to other dom0s like *BSD? Can a BSD person
> confirm that this change won't breaking things for them please.
> 
>> - Update libxc appropriately
>> - Remove the unnecessary constant in domctl.h
>> 
>> Signed-off-by: Andres Lagar-Cavilla 
>> 
>> diff -r 4eed5e64544f -r 5171750d133e tools/include/xen-sys/Linux/privcmd.h
>> --- a/tools/include/xen-sys/Linux/privcmd.h
>> +++ b/tools/include/xen-sys/Linux/privcmd.h
>> @@ -64,6 +64,9 @@ typedef struct privcmd_mmapbatch {
>> 	xen_pfn_t __user *arr; /* array of mfns - top nibble set on err */
>> } privcmd_mmapbatch_t; 
>> 
>> +#define PRIVCMD_MMAPBATCH_MFN_ERROR     0xf0000000U
>> +#define PRIVCMD_MMAPBATCH_PAGED_ERROR   0x80000000U
>> +
>> typedef struct privcmd_mmapbatch_v2 {
>> 	unsigned int num; /* number of pages to populate */
>> 	domid_t dom;      /* target domain */
>> diff -r 4eed5e64544f -r 5171750d133e tools/libxc/xc_linux_osdep.c
>> --- a/tools/libxc/xc_linux_osdep.c
>> +++ b/tools/libxc/xc_linux_osdep.c
>> @@ -129,7 +129,7 @@ static int xc_map_foreign_batch_single(i
>> 
>>     do
>>     {
>> -        *mfn ^= XEN_DOMCTL_PFINFO_PAGEDTAB;
>> +        *mfn ^= PRIVCMD_MMAPBATCH_PAGED_ERROR;
>>         usleep(100);
>>         rc = ioctl(fd, IOCTL_PRIVCMD_MMAPBATCH, &ioctlx);
>>     }
>> @@ -166,8 +166,8 @@ static void *linux_privcmd_map_foreign_b
>> 
>>         for ( i = 0; i < num; i++ )
>>         {
>> -            if ( (arr[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) ==
>> -                 XEN_DOMCTL_PFINFO_PAGEDTAB )
>> +            if ( (arr[i] & PRIVCMD_MMAPBATCH_MFN_ERROR) ==
>> +                           PRIVCMD_MMAPBATCH_PAGED_ERROR )
>>             {
>>                 unsigned long paged_addr = (unsigned long)addr + (i << XC_PAGE_SHIFT);
>>                 rc = xc_map_foreign_batch_single(fd, dom, &arr[i],
>> @@ -323,12 +323,12 @@ static void *linux_privcmd_map_foreign_b
>>             default:
>>                 err[i] = -EINVAL;
>>                 continue;
>> -            case XEN_DOMCTL_PFINFO_PAGEDTAB:
>> +            case PRIVCMD_MMAPBATCH_PAGED_ERROR:
>>                 if ( rc != -ENOENT )
>>                 {
>>                     err[i] = rc ?: -EINVAL;
>>                     continue;
>> -                 }
>> +                }
>>                 rc = xc_map_foreign_batch_single(fd, dom, pfn + i,
>>                         (unsigned long)addr + ((unsigned long)i<>                 if ( rc < 0 )
>> diff -r 4eed5e64544f -r 5171750d133e xen/include/public/domctl.h
>> --- a/xen/include/public/domctl.h
>> +++ b/xen/include/public/domctl.h
>> @@ -135,7 +135,6 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_getme
>> #define XEN_DOMCTL_PFINFO_LPINTAB (0x1U<<31)
>> #define XEN_DOMCTL_PFINFO_XTAB    (0xfU<<28) /* invalid page */
>> #define XEN_DOMCTL_PFINFO_XALLOC  (0xeU<<28) /* allocate-only page */
>> -#define XEN_DOMCTL_PFINFO_PAGEDTAB (0x8U<<28)
>> #define XEN_DOMCTL_PFINFO_LTAB_MASK (0xfU<<28)
>> 
>> struct xen_domctl_getpageframeinfo {
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 02:20:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 02:20:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP2C1-0000ja-Ne; Fri, 19 Oct 2012 02:20:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP2C0-0000jS-Nc
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 02:20:09 +0000
Received: from [85.158.137.99:4275] by server-1.bemta-3.messagelabs.com id
	C2/39-31728-7D8B0805; Fri, 19 Oct 2012 02:20:07 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-7.tower-217.messagelabs.com!1350613204!17373685!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8551 invoked from network); 19 Oct 2012 02:20:06 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 02:20:06 -0000
Received: by mail-ie0-f173.google.com with SMTP id 17so18302041iea.32
	for ; Thu, 18 Oct 2012 19:20:04 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=content-type:mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=TU6FXngUVTasI2VDjLnLb1DBDCqYRHiAYsE553zW674=;
	b=MrR3bdJdottyBHj8Zm8Gs9LMVWbUw08nO+VJQLmdW26EewW6DV+S1dySHRKnIKKUTQ
	qzvt8LOZEP+XOmvpu7bGbF43D//Q/hEI4ArJmqpQKfZMSqltcurU1UyPyNMisHJRIO70
	G2/iC94GnqfF3LnWm09qVQPmrGWshVevDEfKpTzwCQ8+lx9UKfexcYgISATjEBLSwxEq
	KnvhRBbb4BNAqqErJgiy2lFtgiEzBSjfvIDYi4Q5wFjwacVieWbW8Z0oT3rn3WrMkHtj
	KsN4H7sqijJVJrZ2veMx78tV9K5UbNcTA1e+iWV1BK8kEzYqCLhWpbfvxjK2UB5kWs0x
	Tm5g==
Received: by 10.50.0.168 with SMTP id 8mr7001903igf.24.1350613204417;
	Thu, 18 Oct 2012 19:20:04 -0700 (PDT)
Received: from [192.168.1.101] (69-165-161-147.dsl.teksavvy.com.
	[69.165.161.147])
	by mx.google.com with ESMTPS id vq4sm14849036igb.10.2012.10.18.19.20.01
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 18 Oct 2012 19:20:02 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Andres Lagar-Cavilla 
In-Reply-To: <1350547689.28188.31.camel@dagon.hellion.org.uk>
Date: Thu, 18 Oct 2012 22:20:03 -0400
Message-Id: 
References: <5171750d133ef2c27ac8.1350055853@xdev.gridcentric.ca>
	<1350547689.28188.31.camel@dagon.hellion.org.uk>
To: Ian Campbell 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQmtMp48zsfrA03TizvkaCPVzaK4m0T0+0GfZ/WuG67e3JJOSkXnsIsUoiQvzKVeHvHMSQkg
Cc: Christoph Egger ,
	Ian Jackson ,
	"xen-devel@lists.xen.org" ,
	Andres Lagar-Cavilla ,
	Attilio Rao ,
	Roger Pau Monne 
Subject: Re: [Xen-devel] [PATCH] Synchronize privcmd header constants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I've had a look. The xen.org tree knows about three other OSes: minios, solaris and netbsd. None knows about paged out frames. None uses the XEN_DOMCTL_PFINFO_PAGEDTAB constant in domctl.h

1. The domctl.h constant can still go away without hurting other OSes.
2. It is trivial to add the PRIVCMD_MMAPBATCH_* constants to the privcmd.h of other OSes. It can't hurt. I can do it here. Each OS Xen maintainer would have to take care of syncing that up in the respective upstream. However ...
3. Not that trivial to teach all these OSes about paged out frames. Does anyone care?

Please advise.
Thanks
Andres

On Oct 18, 2012, at 4:08 AM, Ian Campbell  wrote:

> On Fri, 2012-10-12 at 16:30 +0100, Andres Lagar-Cavilla wrote:
>> tools/include/xen-sys/Linux/privcmd.h |   3 +++
>> tools/libxc/xc_linux_osdep.c          |  10 +++++-----
>> xen/include/public/domctl.h           |   1 -
>> 3 files changed, 8 insertions(+), 6 deletions(-)
>> 
>> 
>> Since Linux's git commit ceb90fa0a8008059ecbbf9114cb89dc71a730bb6, the
>> privcmd.h interface between Linux and libxc specifies two new constants,
>> PRIVCMD_MMAPBATCH_MFN_ERROR and PRIVCMD_MMAPBATCH_PAGED_ERROR. These constants
>> represent the error codes encoded in the top nibble of an mfn slot passed to
>> the legacy MMAPBATCH ioctl.
>> 
>> In particular, libxenctrl checks for the equivalent of the latter constant when
>> dealing with paged out frames that might be the target of a foreign map.
>> 
>> Previously, the relevant constant was defined in the domctl hypervisor
>> interface header (XEN_DOMCTL_PFINFO_PAGEDTAB). Because this top-nibble encoding
>> is a contract between the dom0 kernel and libxc, a domctl.h definition is
>> misplaced.
>> 
>> - Sync the privcmd.h header to that now available in upstream Linux
> 
> Although the ioctl is Linux specific is the top-nibble behaviour (and
> therefore the #define) common to other dom0s like *BSD? Can a BSD person
> confirm that this change won't breaking things for them please.
> 
>> - Update libxc appropriately
>> - Remove the unnecessary constant in domctl.h
>> 
>> Signed-off-by: Andres Lagar-Cavilla 
>> 
>> diff -r 4eed5e64544f -r 5171750d133e tools/include/xen-sys/Linux/privcmd.h
>> --- a/tools/include/xen-sys/Linux/privcmd.h
>> +++ b/tools/include/xen-sys/Linux/privcmd.h
>> @@ -64,6 +64,9 @@ typedef struct privcmd_mmapbatch {
>> 	xen_pfn_t __user *arr; /* array of mfns - top nibble set on err */
>> } privcmd_mmapbatch_t; 
>> 
>> +#define PRIVCMD_MMAPBATCH_MFN_ERROR     0xf0000000U
>> +#define PRIVCMD_MMAPBATCH_PAGED_ERROR   0x80000000U
>> +
>> typedef struct privcmd_mmapbatch_v2 {
>> 	unsigned int num; /* number of pages to populate */
>> 	domid_t dom;      /* target domain */
>> diff -r 4eed5e64544f -r 5171750d133e tools/libxc/xc_linux_osdep.c
>> --- a/tools/libxc/xc_linux_osdep.c
>> +++ b/tools/libxc/xc_linux_osdep.c
>> @@ -129,7 +129,7 @@ static int xc_map_foreign_batch_single(i
>> 
>>     do
>>     {
>> -        *mfn ^= XEN_DOMCTL_PFINFO_PAGEDTAB;
>> +        *mfn ^= PRIVCMD_MMAPBATCH_PAGED_ERROR;
>>         usleep(100);
>>         rc = ioctl(fd, IOCTL_PRIVCMD_MMAPBATCH, &ioctlx);
>>     }
>> @@ -166,8 +166,8 @@ static void *linux_privcmd_map_foreign_b
>> 
>>         for ( i = 0; i < num; i++ )
>>         {
>> -            if ( (arr[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) ==
>> -                 XEN_DOMCTL_PFINFO_PAGEDTAB )
>> +            if ( (arr[i] & PRIVCMD_MMAPBATCH_MFN_ERROR) ==
>> +                           PRIVCMD_MMAPBATCH_PAGED_ERROR )
>>             {
>>                 unsigned long paged_addr = (unsigned long)addr + (i << XC_PAGE_SHIFT);
>>                 rc = xc_map_foreign_batch_single(fd, dom, &arr[i],
>> @@ -323,12 +323,12 @@ static void *linux_privcmd_map_foreign_b
>>             default:
>>                 err[i] = -EINVAL;
>>                 continue;
>> -            case XEN_DOMCTL_PFINFO_PAGEDTAB:
>> +            case PRIVCMD_MMAPBATCH_PAGED_ERROR:
>>                 if ( rc != -ENOENT )
>>                 {
>>                     err[i] = rc ?: -EINVAL;
>>                     continue;
>> -                 }
>> +                }
>>                 rc = xc_map_foreign_batch_single(fd, dom, pfn + i,
>>                         (unsigned long)addr + ((unsigned long)i<>                 if ( rc < 0 )
>> diff -r 4eed5e64544f -r 5171750d133e xen/include/public/domctl.h
>> --- a/xen/include/public/domctl.h
>> +++ b/xen/include/public/domctl.h
>> @@ -135,7 +135,6 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_getme
>> #define XEN_DOMCTL_PFINFO_LPINTAB (0x1U<<31)
>> #define XEN_DOMCTL_PFINFO_XTAB    (0xfU<<28) /* invalid page */
>> #define XEN_DOMCTL_PFINFO_XALLOC  (0xeU<<28) /* allocate-only page */
>> -#define XEN_DOMCTL_PFINFO_PAGEDTAB (0x8U<<28)
>> #define XEN_DOMCTL_PFINFO_LTAB_MASK (0xfU<<28)
>> 
>> struct xen_domctl_getpageframeinfo {
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 02:31:12 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 02:31:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP2MP-0000tY-17; Fri, 19 Oct 2012 02:30:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP2MN-0000tT-EE
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 02:30:51 +0000
Received: from [85.158.139.211:17003] by server-9.bemta-5.messagelabs.com id
	80/59-23053-A5BB0805; Fri, 19 Oct 2012 02:30:50 +0000
X-Env-Sender: zhenzhong.duan@oracle.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1350613848!22433457!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgyMTI5Ng==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24325 invoked from network); 19 Oct 2012 02:30:50 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Oct 2012 02:30:50 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9J2UeYb014289
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Oct 2012 02:30:41 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9J2UdC5007903
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 19 Oct 2012 02:30:39 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9J2Udf5003915; Thu, 18 Oct 2012 21:30:39 -0500
Received: from [10.191.1.52] (/10.191.1.52)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 18 Oct 2012 19:30:38 -0700
Message-ID: <5080BB5B.4070004@oracle.com>
Date: Fri, 19 Oct 2012 10:30:51 +0800
From: Zhenzhong Duan 
Organization: oracle
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk 
References: <507FBE7F.3010403@oracle.com>
	<20121018120627.GA13485@localhost.localdomain>
In-Reply-To: <20121018120627.GA13485@localhost.localdomain>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Ethan Zhao , Feng Jin ,
	xen-devel 
Subject: Re: [Xen-devel] ask a question about ERST
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: zhenzhong.duan@oracle.com
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 2012-10-18 20:06, Konrad Rzeszutek Wilk wrote:
> On Thu, Oct 18, 2012 at 04:31:59PM +0800, Zhenzhong Duan wrote:
>> Hi maintainer,
>> I found below patch reverted part of erst header size check.
>> This lead to mismatch with kernel upstream code and erst disabled on
>> some machine like X4170 M3/X3-2.
>> According to the ACPI spec 4.0 and 5.0, the Serialization Header Length
>> should be the length of Serialization Header.
>> After revert below patch, xen succeed with erst table init.
>> So could this patch be reverted now to match acpi spec and kernel upstream?
> There was a discussion about this on xen-devel. Search for Jan and ERST
> and I believe the idea was that an AMD machine needs to be checked
> to figure out what to do.
Well, I see. I'll wait for the final fix.
thanks all

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 02:31:12 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 02:31:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP2MP-0000tY-17; Fri, 19 Oct 2012 02:30:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP2MN-0000tT-EE
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 02:30:51 +0000
Received: from [85.158.139.211:17003] by server-9.bemta-5.messagelabs.com id
	80/59-23053-A5BB0805; Fri, 19 Oct 2012 02:30:50 +0000
X-Env-Sender: zhenzhong.duan@oracle.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1350613848!22433457!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgyMTI5Ng==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24325 invoked from network); 19 Oct 2012 02:30:50 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Oct 2012 02:30:50 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9J2UeYb014289
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Oct 2012 02:30:41 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9J2UdC5007903
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 19 Oct 2012 02:30:39 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9J2Udf5003915; Thu, 18 Oct 2012 21:30:39 -0500
Received: from [10.191.1.52] (/10.191.1.52)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 18 Oct 2012 19:30:38 -0700
Message-ID: <5080BB5B.4070004@oracle.com>
Date: Fri, 19 Oct 2012 10:30:51 +0800
From: Zhenzhong Duan 
Organization: oracle
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk 
References: <507FBE7F.3010403@oracle.com>
	<20121018120627.GA13485@localhost.localdomain>
In-Reply-To: <20121018120627.GA13485@localhost.localdomain>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Ethan Zhao , Feng Jin ,
	xen-devel 
Subject: Re: [Xen-devel] ask a question about ERST
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: zhenzhong.duan@oracle.com
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 2012-10-18 20:06, Konrad Rzeszutek Wilk wrote:
> On Thu, Oct 18, 2012 at 04:31:59PM +0800, Zhenzhong Duan wrote:
>> Hi maintainer,
>> I found below patch reverted part of erst header size check.
>> This lead to mismatch with kernel upstream code and erst disabled on
>> some machine like X4170 M3/X3-2.
>> According to the ACPI spec 4.0 and 5.0, the Serialization Header Length
>> should be the length of Serialization Header.
>> After revert below patch, xen succeed with erst table init.
>> So could this patch be reverted now to match acpi spec and kernel upstream?
> There was a discussion about this on xen-devel. Search for Jan and ERST
> and I believe the idea was that an AMD machine needs to be checked
> to figure out what to do.
Well, I see. I'll wait for the final fix.
thanks all

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 03:41:06 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 03:41:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP3Rw-0001Pz-TO; Fri, 19 Oct 2012 03:40:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP3Rv-0001Pr-2l; Fri, 19 Oct 2012 03:40:39 +0000
Received: from [85.158.138.51:41885] by server-12.bemta-3.messagelabs.com id
	67/7B-27853-6BBC0805; Fri, 19 Oct 2012 03:40:38 +0000
X-Env-Sender: hufan@websense.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1350618037!34859683!1
X-Originating-IP: [85.115.56.190]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODUuMTE1LjU2LjE5MCA9PiA5MjU3MjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19646 invoked from network); 19 Oct 2012 03:40:37 -0000
Received: from cluster-b.mailcontrol.com (HELO cluster-b.mailcontrol.com)
	(85.115.56.190)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Oct 2012 03:40:37 -0000
Received: from ssdwbsnapp.websense.com (static-204-15-65-158.websense.com
	[204.15.65.158] (may be forged))
	by rly39b.srv.mailcontrol.com (MailControl) with ESMTP id
	q9J3eX1n028148
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 19 Oct 2012 04:40:35 +0100
Received: from SSDEXCH1B.websense.com (unknown [10.8.2.91])
	by Websense Email Security Gateway with ESMTP id 821A71000002;
	Thu, 18 Oct 2012 20:40:17 -0700 (PDT)
Received: from SBJEXCH2B.websense.com (10.32.8.112) by SSDEXCH1B.websense.com
	(10.8.2.91) with Microsoft SMTP Server (TLS) id 14.2.283.3;
	Thu, 18 Oct 2012 20:40:33 -0700
Received: from SBJEXCH1A.websense.com ([169.254.1.70]) by
	SBJEXCH2B.websense.com ([::1]) with mapi id 14.02.0283.003;
	Fri, 19 Oct 2012 11:40:29 +0800
From: "Fan, Huaxiang" 
To: "xen-devel@lists.xen.org" 
Thread-Topic: e820_host and 3G limit
Thread-Index: Ac2tqU9Lub39PN+YQ/+qrymARk/PPg==
Date: Fri, 19 Oct 2012 03:40:28 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.32.134.111]
MIME-Version: 1.0
X-Scanned-By: MailControl 10515.0 (www.mailcontrol.com) on 10.66.0.149
Cc: "xen-users@lists.xen.org" 
Subject: [Xen-devel] e820_host and 3G limit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============4450744637235770775=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4450744637235770775==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_E71FC5D6F96C3C4B93FC8FF942D924C6774396BESBJEXCH1Awebsen_"

--_000_E71FC5D6F96C3C4B93FC8FF942D924C6774396BESBJEXCH1Awebsen_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

I was told e820_host is used to solve 3G limit on domu problem when PCI pas=
sthru happens. But I failed to tackle this problem using xen 4.2 and kernel=
 3.4.4

Here is my environment:
Xen hypervisor and tools: 4.2
Dom0 kernel 2.6.32.57
Domu kernel 3.4.4
All above is 64bit

Here is my domu cfg:
kernel =3D "/root/domainWCG.kernel"
ramdisk =3D "/root/domainWCG.initrd.img"
e820_host=3D1
memory=3D5120
name =3D "wcg"
vif  =3D [ 'ip=3D169.254.254.1,vifname=3Dwcg.0' ]
disk =3D ['phy:/dev/lv_appliance/wcg,xvda1,w',
        'phy:/dev/sdb,xvdb,w']
root  =3D "/dev/xvda1 ro"
extra=3D"iommu=3Dsoft printk.printk_time=3D1 console=3Dhvc0"
#pci=3D['01:00.0','01:00.1']
vcpus=3D4
cpus=3D"4,5,6,7"

Here is the output on dom0:
# xl list
Name                                        ID   Mem VCPUs      State   Tim=
e(s)
Domain-0                                     0  1677     2     r-----    22=
37.9
wcg                                         72  4086     4     -b----      =
34.9

My question#1:
Dom0 memory has been shrink from 2048 to 1677. Wcg domu only allocated with=
 4086 even I assigned 5120. Why?

Here is the output on wcg domu:
# cat /proc/meminfo | head -10
MemTotal:        2999156 kB
MemFree:         2919760 kB
Buffers:            4000 kB
Cached:            40656 kB
SwapCached:            0 kB
Active:            22852 kB
Inactive:          31776 kB
Active(anon):      10080 kB
Inactive(anon):       12 kB
Active(file):      12772 kB

My question#2:
Why the domu kernel only recognizes 3G memory even I actually allocate 5G t=
o it?

Appendix
E820 memory map on wcg domu

[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  Xen: 0000000000000000 - 00000000000a0000 (usable)
[    0.000000]  Xen: 00000000000a0000 - 0000000000100000 (reserved)
[    0.000000]  Xen: 0000000000100000 - 00000000bf699000 (usable)
[    0.000000]  Xen: 00000000bf699000 - 00000000bf6af000 (reserved)
[    0.000000]  Xen: 00000000bf6af000 - 00000000bf6ce000 (ACPI data)
[    0.000000]  Xen: 00000000bf6ce000 - 00000000c0000000 (reserved)
[    0.000000]  Xen: 00000000e0000000 - 00000000f0000000 (reserved)
[    0.000000]  Xen: 00000000fe000000 - 0000000100000000 (reserved)

E820 memory map on dom0
BIOS-provided physical RAM map:
Oct 18 05:26:34 localhost kernel: BIOS-e820: 0000000000000000 - 00000000000=
9d000 (usable)
Oct 18 05:26:34 localhost kernel: BIOS-e820: 0000000000100000 - 00000000bf6=
99000 (usable)
Oct 18 05:26:34 localhost kernel: BIOS-e820: 00000000bf699000 - 00000000bf6=
af000 (reserved)
Oct 18 05:26:34 localhost kernel: BIOS-e820: 00000000bf6af000 - 00000000bf6=
ce000 (ACPI data)
Oct 18 05:26:34 localhost kernel: BIOS-e820: 00000000bf6ce000 - 00000000c00=
00000 (reserved)
Oct 18 05:26:34 localhost kernel: BIOS-e820: 00000000e0000000 - 00000000f00=
00000 (reserved)
Oct 18 05:26:34 localhost kernel: BIOS-e820: 00000000fe000000 - 00000001000=
00000 (reserved)
Oct 18 05:26:34 localhost kernel: BIOS-e820: 0000000100000000 - 00000002400=
00000 (usable)

I am looking forward your reply. Thanks in advance.
HUAXIANG FAN
Software Engineer II

WEBSENSE NETWORK SECURITY TECHNOLOGY R&D (BEIJING) CO. LTD.
ph: +8610.5884.4327
fax: +8610.5884.4727
www.websense.cn

Websense TRITON(tm)
For Essential Information Protection(tm)
Web Security | Data Security | Email Security



 Protected by Websense Hosted Email Security -- www.websense.com=20

--_000_E71FC5D6F96C3C4B93FC8FF942D924C6774396BESBJEXCH1Awebsen_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi,


 


I was told e820_host is used to solve 3G limit on do=
mu problem when PCI passthru happens. But I failed to tackle this problem u=
sing xen 4.2 and kernel 3.4.4


 


Here is my environment:


Xen hypervisor and tools: 4.2


Dom0 kernel 2.6.32.57


Domu kernel 3.4.4


All above is 64bit


 


Here is my domu cfg:


kernel =3D "/root/domainWCG.kernel"


ramdisk =3D "/root/domainWCG.initrd.img"


e820_host=3D1


memory=3D5120


name =3D "wcg"


vif  =3D [ 'ip=3D169.254.254.1,vifname=3Dwcg.0'=
 ]


disk =3D ['phy:/dev/lv_appliance/wcg,xvda1,w',<=
/o:p>


        'phy:/dev=
/sdb,xvdb,w']


root  =3D "/dev/xvda1 ro"<=
/p>

extra=3D"iommu=3Dsoft printk.printk_time=3D1 co=
nsole=3Dhvc0"


#pci=3D['01:00.0','01:00.1']


vcpus=3D4


cpus=3D"4,5,6,7"


 


Here is the output on dom0:


# xl list


Name        =
            &nb=
sp;            =
       ID   Mem VCPUs  &n=
bsp;   State   Time(s)


Domain-0       &n=
bsp;            =
;            &n=
bsp;    0  1677     2  &n=
bsp;  r-----    2237.9


wcg        &=
nbsp;           &nbs=
p;            &=
nbsp;       72  4086   &n=
bsp; 4     -b----      34.9


 


My question#1:


Dom0 memory has been shrink from 2048 to 1677. Wcg d=
omu only allocated with 4086 even I assigned 5120. Why?


 


Here is the output on wcg domu:


# cat /proc/meminfo | head -10


MemTotal:        =
2999156 kB


MemFree:       &n=
bsp; 2919760 kB


Buffers:       &n=
bsp;    4000 kB


Cached:       &nb=
sp;    40656 kB


SwapCached:       =
;     0 kB


Active:       &nb=
sp;    22852 kB


Inactive:       &=
nbsp;  31776 kB


Active(anon):      10080 kB=



Inactive(anon):       =
12 kB


Active(file):      12772 kB=



 


My question#2:


Why the domu kernel only recognizes 3G memory even I=
 actually allocate 5G to it?


 


Appendix


E820 memory map on wcg domu


 


[    0.000000] BIOS-provided physical=
 RAM map:


[    0.000000]  Xen: 00000000000=
00000 - 00000000000a0000 (usable)


[    0.000000]  Xen: 00000000000=
a0000 - 0000000000100000 (reserved)


[    0.000000]  Xen: 00000000001=
00000 - 00000000bf699000 (usable)


[    0.000000]  Xen: 00000000bf6=
99000 - 00000000bf6af000 (reserved)


[    0.000000]  Xen: 00000000bf6=
af000 - 00000000bf6ce000 (ACPI data)


[    0.000000]  Xen: 00000000bf6=
ce000 - 00000000c0000000 (reserved)


[    0.000000]  Xen: 00000000e00=
00000 - 00000000f0000000 (reserved)


[    0.000000]  Xen: 00000000fe0=
00000 - 0000000100000000 (reserved)


 


E820 memory map on dom0


BIOS-provided physical RAM map:


Oct 18 05:26:34 localhost kernel: BIOS-e820: 0000000=
000000000 - 000000000009d000 (usable)


Oct 18 05:26:34 localhost kernel: BIOS-e820: 0000000=
000100000 - 00000000bf699000 (usable)


Oct 18 05:26:34 localhost kernel: BIOS-e820: 0000000=
0bf699000 - 00000000bf6af000 (reserved)


Oct 18 05:26:34 localhost kernel: BIOS-e820: 0000000=
0bf6af000 - 00000000bf6ce000 (ACPI data)


Oct 18 05:26:34 localhost kernel: BIOS-e820: 0000000=
0bf6ce000 - 00000000c0000000 (reserved)


Oct 18 05:26:34 localhost kernel: BIOS-e820: 0000000=
0e0000000 - 00000000f0000000 (reserved)


Oct 18 05:26:34 localhost kernel: BIOS-e820: 0000000=
0fe000000 - 0000000100000000 (reserved)


Oct 18 05:26:34 localhost kernel: BIOS-e820: 0000000=
100000000 - 0000000240000000 (usable)


 


I am looking forward your reply. Thanks in advance.<=
o:p>


HUAXIANG FAN

Software Engineer II



WEBSENSE NETWORK SECURITY TECHNOLOGY R&am=
p;D (BEIJING) CO. LTD.

ph: +8610.5884.4327

fax: +8610.5884.4727

www.websense.cn



Websense TRITON™

For Essential Information Protection™

Web Security |
=
Data Security=
 |
Email Security











Protected by Websense Hosted Email Security =
212; www.websense.com




--_000_E71FC5D6F96C3C4B93FC8FF942D924C6774396BESBJEXCH1Awebsen_--


--===============4450744637235770775==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4450744637235770775==--


From xen-devel-bounces@lists.xen.org Fri Oct 19 03:41:06 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 03:41:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP3Rw-0001Pz-TO; Fri, 19 Oct 2012 03:40:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP3Rv-0001Pr-2l; Fri, 19 Oct 2012 03:40:39 +0000
Received: from [85.158.138.51:41885] by server-12.bemta-3.messagelabs.com id
	67/7B-27853-6BBC0805; Fri, 19 Oct 2012 03:40:38 +0000
X-Env-Sender: hufan@websense.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1350618037!34859683!1
X-Originating-IP: [85.115.56.190]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODUuMTE1LjU2LjE5MCA9PiA5MjU3MjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19646 invoked from network); 19 Oct 2012 03:40:37 -0000
Received: from cluster-b.mailcontrol.com (HELO cluster-b.mailcontrol.com)
	(85.115.56.190)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Oct 2012 03:40:37 -0000
Received: from ssdwbsnapp.websense.com (static-204-15-65-158.websense.com
	[204.15.65.158] (may be forged))
	by rly39b.srv.mailcontrol.com (MailControl) with ESMTP id
	q9J3eX1n028148
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 19 Oct 2012 04:40:35 +0100
Received: from SSDEXCH1B.websense.com (unknown [10.8.2.91])
	by Websense Email Security Gateway with ESMTP id 821A71000002;
	Thu, 18 Oct 2012 20:40:17 -0700 (PDT)
Received: from SBJEXCH2B.websense.com (10.32.8.112) by SSDEXCH1B.websense.com
	(10.8.2.91) with Microsoft SMTP Server (TLS) id 14.2.283.3;
	Thu, 18 Oct 2012 20:40:33 -0700
Received: from SBJEXCH1A.websense.com ([169.254.1.70]) by
	SBJEXCH2B.websense.com ([::1]) with mapi id 14.02.0283.003;
	Fri, 19 Oct 2012 11:40:29 +0800
From: "Fan, Huaxiang" 
To: "xen-devel@lists.xen.org" 
Thread-Topic: e820_host and 3G limit
Thread-Index: Ac2tqU9Lub39PN+YQ/+qrymARk/PPg==
Date: Fri, 19 Oct 2012 03:40:28 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.32.134.111]
MIME-Version: 1.0
X-Scanned-By: MailControl 10515.0 (www.mailcontrol.com) on 10.66.0.149
Cc: "xen-users@lists.xen.org" 
Subject: [Xen-devel] e820_host and 3G limit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============4450744637235770775=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4450744637235770775==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_E71FC5D6F96C3C4B93FC8FF942D924C6774396BESBJEXCH1Awebsen_"

--_000_E71FC5D6F96C3C4B93FC8FF942D924C6774396BESBJEXCH1Awebsen_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

I was told e820_host is used to solve 3G limit on domu problem when PCI pas=
sthru happens. But I failed to tackle this problem using xen 4.2 and kernel=
 3.4.4

Here is my environment:
Xen hypervisor and tools: 4.2
Dom0 kernel 2.6.32.57
Domu kernel 3.4.4
All above is 64bit

Here is my domu cfg:
kernel =3D "/root/domainWCG.kernel"
ramdisk =3D "/root/domainWCG.initrd.img"
e820_host=3D1
memory=3D5120
name =3D "wcg"
vif  =3D [ 'ip=3D169.254.254.1,vifname=3Dwcg.0' ]
disk =3D ['phy:/dev/lv_appliance/wcg,xvda1,w',
        'phy:/dev/sdb,xvdb,w']
root  =3D "/dev/xvda1 ro"
extra=3D"iommu=3Dsoft printk.printk_time=3D1 console=3Dhvc0"
#pci=3D['01:00.0','01:00.1']
vcpus=3D4
cpus=3D"4,5,6,7"

Here is the output on dom0:
# xl list
Name                                        ID   Mem VCPUs      State   Tim=
e(s)
Domain-0                                     0  1677     2     r-----    22=
37.9
wcg                                         72  4086     4     -b----      =
34.9

My question#1:
Dom0 memory has been shrink from 2048 to 1677. Wcg domu only allocated with=
 4086 even I assigned 5120. Why?

Here is the output on wcg domu:
# cat /proc/meminfo | head -10
MemTotal:        2999156 kB
MemFree:         2919760 kB
Buffers:            4000 kB
Cached:            40656 kB
SwapCached:            0 kB
Active:            22852 kB
Inactive:          31776 kB
Active(anon):      10080 kB
Inactive(anon):       12 kB
Active(file):      12772 kB

My question#2:
Why the domu kernel only recognizes 3G memory even I actually allocate 5G t=
o it?

Appendix
E820 memory map on wcg domu

[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  Xen: 0000000000000000 - 00000000000a0000 (usable)
[    0.000000]  Xen: 00000000000a0000 - 0000000000100000 (reserved)
[    0.000000]  Xen: 0000000000100000 - 00000000bf699000 (usable)
[    0.000000]  Xen: 00000000bf699000 - 00000000bf6af000 (reserved)
[    0.000000]  Xen: 00000000bf6af000 - 00000000bf6ce000 (ACPI data)
[    0.000000]  Xen: 00000000bf6ce000 - 00000000c0000000 (reserved)
[    0.000000]  Xen: 00000000e0000000 - 00000000f0000000 (reserved)
[    0.000000]  Xen: 00000000fe000000 - 0000000100000000 (reserved)

E820 memory map on dom0
BIOS-provided physical RAM map:
Oct 18 05:26:34 localhost kernel: BIOS-e820: 0000000000000000 - 00000000000=
9d000 (usable)
Oct 18 05:26:34 localhost kernel: BIOS-e820: 0000000000100000 - 00000000bf6=
99000 (usable)
Oct 18 05:26:34 localhost kernel: BIOS-e820: 00000000bf699000 - 00000000bf6=
af000 (reserved)
Oct 18 05:26:34 localhost kernel: BIOS-e820: 00000000bf6af000 - 00000000bf6=
ce000 (ACPI data)
Oct 18 05:26:34 localhost kernel: BIOS-e820: 00000000bf6ce000 - 00000000c00=
00000 (reserved)
Oct 18 05:26:34 localhost kernel: BIOS-e820: 00000000e0000000 - 00000000f00=
00000 (reserved)
Oct 18 05:26:34 localhost kernel: BIOS-e820: 00000000fe000000 - 00000001000=
00000 (reserved)
Oct 18 05:26:34 localhost kernel: BIOS-e820: 0000000100000000 - 00000002400=
00000 (usable)

I am looking forward your reply. Thanks in advance.
HUAXIANG FAN
Software Engineer II

WEBSENSE NETWORK SECURITY TECHNOLOGY R&D (BEIJING) CO. LTD.
ph: +8610.5884.4327
fax: +8610.5884.4727
www.websense.cn

Websense TRITON(tm)
For Essential Information Protection(tm)
Web Security | Data Security | Email Security



 Protected by Websense Hosted Email Security -- www.websense.com=20

--_000_E71FC5D6F96C3C4B93FC8FF942D924C6774396BESBJEXCH1Awebsen_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi,


 


I was told e820_host is used to solve 3G limit on do=
mu problem when PCI passthru happens. But I failed to tackle this problem u=
sing xen 4.2 and kernel 3.4.4


 


Here is my environment:


Xen hypervisor and tools: 4.2


Dom0 kernel 2.6.32.57


Domu kernel 3.4.4


All above is 64bit


 


Here is my domu cfg:


kernel =3D "/root/domainWCG.kernel"


ramdisk =3D "/root/domainWCG.initrd.img"


e820_host=3D1


memory=3D5120


name =3D "wcg"


vif  =3D [ 'ip=3D169.254.254.1,vifname=3Dwcg.0'=
 ]


disk =3D ['phy:/dev/lv_appliance/wcg,xvda1,w',<=
/o:p>


        'phy:/dev=
/sdb,xvdb,w']


root  =3D "/dev/xvda1 ro"<=
/p>

extra=3D"iommu=3Dsoft printk.printk_time=3D1 co=
nsole=3Dhvc0"


#pci=3D['01:00.0','01:00.1']


vcpus=3D4


cpus=3D"4,5,6,7"


 


Here is the output on dom0:


# xl list


Name        =
            &nb=
sp;            =
       ID   Mem VCPUs  &n=
bsp;   State   Time(s)


Domain-0       &n=
bsp;            =
;            &n=
bsp;    0  1677     2  &n=
bsp;  r-----    2237.9


wcg        &=
nbsp;           &nbs=
p;            &=
nbsp;       72  4086   &n=
bsp; 4     -b----      34.9


 


My question#1:


Dom0 memory has been shrink from 2048 to 1677. Wcg d=
omu only allocated with 4086 even I assigned 5120. Why?


 


Here is the output on wcg domu:


# cat /proc/meminfo | head -10


MemTotal:        =
2999156 kB


MemFree:       &n=
bsp; 2919760 kB


Buffers:       &n=
bsp;    4000 kB


Cached:       &nb=
sp;    40656 kB


SwapCached:       =
;     0 kB


Active:       &nb=
sp;    22852 kB


Inactive:       &=
nbsp;  31776 kB


Active(anon):      10080 kB=



Inactive(anon):       =
12 kB


Active(file):      12772 kB=



 


My question#2:


Why the domu kernel only recognizes 3G memory even I=
 actually allocate 5G to it?


 


Appendix


E820 memory map on wcg domu


 


[    0.000000] BIOS-provided physical=
 RAM map:


[    0.000000]  Xen: 00000000000=
00000 - 00000000000a0000 (usable)


[    0.000000]  Xen: 00000000000=
a0000 - 0000000000100000 (reserved)


[    0.000000]  Xen: 00000000001=
00000 - 00000000bf699000 (usable)


[    0.000000]  Xen: 00000000bf6=
99000 - 00000000bf6af000 (reserved)


[    0.000000]  Xen: 00000000bf6=
af000 - 00000000bf6ce000 (ACPI data)


[    0.000000]  Xen: 00000000bf6=
ce000 - 00000000c0000000 (reserved)


[    0.000000]  Xen: 00000000e00=
00000 - 00000000f0000000 (reserved)


[    0.000000]  Xen: 00000000fe0=
00000 - 0000000100000000 (reserved)


 


E820 memory map on dom0


BIOS-provided physical RAM map:


Oct 18 05:26:34 localhost kernel: BIOS-e820: 0000000=
000000000 - 000000000009d000 (usable)


Oct 18 05:26:34 localhost kernel: BIOS-e820: 0000000=
000100000 - 00000000bf699000 (usable)


Oct 18 05:26:34 localhost kernel: BIOS-e820: 0000000=
0bf699000 - 00000000bf6af000 (reserved)


Oct 18 05:26:34 localhost kernel: BIOS-e820: 0000000=
0bf6af000 - 00000000bf6ce000 (ACPI data)


Oct 18 05:26:34 localhost kernel: BIOS-e820: 0000000=
0bf6ce000 - 00000000c0000000 (reserved)


Oct 18 05:26:34 localhost kernel: BIOS-e820: 0000000=
0e0000000 - 00000000f0000000 (reserved)


Oct 18 05:26:34 localhost kernel: BIOS-e820: 0000000=
0fe000000 - 0000000100000000 (reserved)


Oct 18 05:26:34 localhost kernel: BIOS-e820: 0000000=
100000000 - 0000000240000000 (usable)


 


I am looking forward your reply. Thanks in advance.<=
o:p>


HUAXIANG FAN

Software Engineer II



WEBSENSE NETWORK SECURITY TECHNOLOGY R&am=
p;D (BEIJING) CO. LTD.

ph: +8610.5884.4327

fax: +8610.5884.4727

www.websense.cn



Websense TRITON™

For Essential Information Protection™

Web Security |
=
Data Security=
 |
Email Security











Protected by Websense Hosted Email Security =
212; www.websense.com




--_000_E71FC5D6F96C3C4B93FC8FF942D924C6774396BESBJEXCH1Awebsen_--


--===============4450744637235770775==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4450744637235770775==--


From xen-devel-bounces@lists.xen.org Fri Oct 19 04:45:35 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 04:45:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP4S7-0002Ct-Jl; Fri, 19 Oct 2012 04:44:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP4S6-0002Co-1Q
	for xen-devel@lists.xensource.com; Fri, 19 Oct 2012 04:44:54 +0000
Received: from [85.158.138.51:55454] by server-1.bemta-3.messagelabs.com id
	FC/74-31728-5CAD0805; Fri, 19 Oct 2012 04:44:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1350621892!34942934!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ5MzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29753 invoked from network); 19 Oct 2012 04:44:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 04:44:52 -0000
X-IronPort-AV: E=Sophos;i="4.80,610,1344211200"; d="scan'208";a="15267209"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 04:44:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 19 Oct 2012 05:44:51 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TP4S3-0004Ze-IF;
	Fri, 19 Oct 2012 04:44:51 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TP4S3-00015z-8k;
	Fri, 19 Oct 2012 05:44:51 +0100
To: 
Message-ID: 
From: xen.org 
Date: Fri, 19 Oct 2012 05:44:51 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14057: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14057 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14057/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 13967
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 13967
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 13967
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 13967

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                    fail pass in 14038
 test-amd64-i386-xl            5 xen-boot                    fail pass in 14045
 test-amd64-amd64-pair         8 xen-boot/dst_host           fail pass in 14045
 test-amd64-amd64-pair         7 xen-boot/src_host           fail pass in 14045

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13967
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13967
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13967
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13967

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  3fa2ab30bb05
baseline version:
 xen                  c1c549c4fe9e

------------------------------------------------------------
People who touched revisions under test:
  Chuang Cao 
  Daniel De Graaf 
  Huang Ying 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Joe Jin 
  Keir Fraser 
  Olaf Hering 
  Sander Eikelenboom 
  Stefano Stabellini 
  Tim Deegan 
  Xiantao Zhang
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 592 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 04:45:35 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 04:45:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP4S7-0002Ct-Jl; Fri, 19 Oct 2012 04:44:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP4S6-0002Co-1Q
	for xen-devel@lists.xensource.com; Fri, 19 Oct 2012 04:44:54 +0000
Received: from [85.158.138.51:55454] by server-1.bemta-3.messagelabs.com id
	FC/74-31728-5CAD0805; Fri, 19 Oct 2012 04:44:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1350621892!34942934!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ5MzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29753 invoked from network); 19 Oct 2012 04:44:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 04:44:52 -0000
X-IronPort-AV: E=Sophos;i="4.80,610,1344211200"; d="scan'208";a="15267209"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 04:44:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 19 Oct 2012 05:44:51 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TP4S3-0004Ze-IF;
	Fri, 19 Oct 2012 04:44:51 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TP4S3-00015z-8k;
	Fri, 19 Oct 2012 05:44:51 +0100
To: 
Message-ID: 
From: xen.org 
Date: Fri, 19 Oct 2012 05:44:51 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14057: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14057 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14057/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 13967
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 13967
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 13967
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 13967

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                    fail pass in 14038
 test-amd64-i386-xl            5 xen-boot                    fail pass in 14045
 test-amd64-amd64-pair         8 xen-boot/dst_host           fail pass in 14045
 test-amd64-amd64-pair         7 xen-boot/src_host           fail pass in 14045

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13967
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13967
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13967
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13967

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  3fa2ab30bb05
baseline version:
 xen                  c1c549c4fe9e

------------------------------------------------------------
People who touched revisions under test:
  Chuang Cao 
  Daniel De Graaf 
  Huang Ying 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Joe Jin 
  Keir Fraser 
  Olaf Hering 
  Sander Eikelenboom 
  Stefano Stabellini 
  Tim Deegan 
  Xiantao Zhang
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 592 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 06:48:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 06:48:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP6ND-0003SI-6I; Fri, 19 Oct 2012 06:47:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP6NC-0003SD-9t
	for Xen-devel@lists.xensource.com; Fri, 19 Oct 2012 06:47:58 +0000
Received: from [85.158.139.211:34625] by server-16.bemta-5.messagelabs.com id
	49/63-09196-C97F0805; Fri, 19 Oct 2012 06:47:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1350629275!22924469!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ5MzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20410 invoked from network); 19 Oct 2012 06:47:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 06:47:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,610,1344211200"; d="scan'208";a="15268085"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 06:47:55 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 19 Oct 2012 07:47:54 +0100
Message-ID: <1350629274.28188.48.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Mukesh Rathor 
Date: Fri, 19 Oct 2012 07:47:54 +0100
In-Reply-To: <20121018150359.794768d2@mantra.us.oracle.com>
References: <20121017173005.73a03eec@mantra.us.oracle.com>
	<1350557077.2460.113.camel@zakaz.uk.xensource.com>
	<20121018150359.794768d2@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V3 2/6]: PVH: use native irq, enable callback,
 use HVM ring ops, smp, ...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-18 at 23:03 +0100, Mukesh Rathor wrote:
> On Thu, 18 Oct 2012 11:44:37 +0100
> Ian Campbell  wrote:
> 
> > On Thu, 2012-10-18 at 01:30 +0100, Mukesh Rathor wrote:
> > > PVH: make gdt_frames[]/gdt_ents into a union with {gdtaddr, gdtsz},
> > > PVH only needs to send down gdtaddr and gdtsz. irq.c: PVH uses
> > > native_irq_ops. vcpu hotplug is currently not available for PVH.
> > > events.c: setup callback vector for PVH. smp.c: This pertains to
> > > bringing up smp vcpus. PVH runs in ring 0, so syscalls are native.
> > > Also, the vcpu context is send down via the hcall to be set in the
> > > vmcs. gdtaddr and gdtsz are unionionized as PVH only needs to send
> > > these two to be set in the vmcs. Finally, PVH ring ops uses HVM
> > > paths for xenbus.
> > > 
> > > Signed-off-by: Mukesh Rathor 
> > > ---
> > >  arch/x86/include/asm/xen/interface.h |   11 +++++-
> > >  arch/x86/xen/irq.c                   |    5 ++-
> > >  arch/x86/xen/p2m.c                   |    2 +-
> > >  arch/x86/xen/smp.c                   |   75
> > > ++++++++++++++++++++++------------ drivers/xen/cpu_hotplug.c
> > > |    4 +- drivers/xen/events.c                 |    9 ++++-
> > >  drivers/xen/xenbus/xenbus_client.c   |    3 +-
> > 
> > This patch seems to have been horribly whitespace damaged.
> 
> Hmm.. not sure what happened. Resending. See another email.
> 
> > Have you seen "git send-email" ? It's very useful for avoiding this
> > sort of thing and also takes a lot of the grunt work out of reposting
> > a series.
> 
> > It also chains the patches as replies to the introductory zero-th mail
> > -- which is something I've been meaning to ask you to do for a while.
> > It's useful because it joins the series together in a thread which
> > makes it easier to keep track of in my INBOX.
> 
> I prefer different thread-sets for different version. Otherwise too
> many emails makes much harder to manage and figure. Besides, as
> comments come in, path x of y,  may contain different files/changes in
> a subsequent version.

I meant one thread per posting, not one thread for all all them. Which
seems to be what you are saying you prefer but not what you are doing.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 06:48:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 06:48:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP6ND-0003SI-6I; Fri, 19 Oct 2012 06:47:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP6NC-0003SD-9t
	for Xen-devel@lists.xensource.com; Fri, 19 Oct 2012 06:47:58 +0000
Received: from [85.158.139.211:34625] by server-16.bemta-5.messagelabs.com id
	49/63-09196-C97F0805; Fri, 19 Oct 2012 06:47:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1350629275!22924469!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ5MzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20410 invoked from network); 19 Oct 2012 06:47:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 06:47:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,610,1344211200"; d="scan'208";a="15268085"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 06:47:55 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 19 Oct 2012 07:47:54 +0100
Message-ID: <1350629274.28188.48.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Mukesh Rathor 
Date: Fri, 19 Oct 2012 07:47:54 +0100
In-Reply-To: <20121018150359.794768d2@mantra.us.oracle.com>
References: <20121017173005.73a03eec@mantra.us.oracle.com>
	<1350557077.2460.113.camel@zakaz.uk.xensource.com>
	<20121018150359.794768d2@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V3 2/6]: PVH: use native irq, enable callback,
 use HVM ring ops, smp, ...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-18 at 23:03 +0100, Mukesh Rathor wrote:
> On Thu, 18 Oct 2012 11:44:37 +0100
> Ian Campbell  wrote:
> 
> > On Thu, 2012-10-18 at 01:30 +0100, Mukesh Rathor wrote:
> > > PVH: make gdt_frames[]/gdt_ents into a union with {gdtaddr, gdtsz},
> > > PVH only needs to send down gdtaddr and gdtsz. irq.c: PVH uses
> > > native_irq_ops. vcpu hotplug is currently not available for PVH.
> > > events.c: setup callback vector for PVH. smp.c: This pertains to
> > > bringing up smp vcpus. PVH runs in ring 0, so syscalls are native.
> > > Also, the vcpu context is send down via the hcall to be set in the
> > > vmcs. gdtaddr and gdtsz are unionionized as PVH only needs to send
> > > these two to be set in the vmcs. Finally, PVH ring ops uses HVM
> > > paths for xenbus.
> > > 
> > > Signed-off-by: Mukesh Rathor 
> > > ---
> > >  arch/x86/include/asm/xen/interface.h |   11 +++++-
> > >  arch/x86/xen/irq.c                   |    5 ++-
> > >  arch/x86/xen/p2m.c                   |    2 +-
> > >  arch/x86/xen/smp.c                   |   75
> > > ++++++++++++++++++++++------------ drivers/xen/cpu_hotplug.c
> > > |    4 +- drivers/xen/events.c                 |    9 ++++-
> > >  drivers/xen/xenbus/xenbus_client.c   |    3 +-
> > 
> > This patch seems to have been horribly whitespace damaged.
> 
> Hmm.. not sure what happened. Resending. See another email.
> 
> > Have you seen "git send-email" ? It's very useful for avoiding this
> > sort of thing and also takes a lot of the grunt work out of reposting
> > a series.
> 
> > It also chains the patches as replies to the introductory zero-th mail
> > -- which is something I've been meaning to ask you to do for a while.
> > It's useful because it joins the series together in a thread which
> > makes it easier to keep track of in my INBOX.
> 
> I prefer different thread-sets for different version. Otherwise too
> many emails makes much harder to manage and figure. Besides, as
> comments come in, path x of y,  may contain different files/changes in
> a subsequent version.

I meant one thread per posting, not one thread for all all them. Which
seems to be what you are saying you prefer but not what you are doing.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 07:11:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 07:11:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP6jB-0003ua-RI; Fri, 19 Oct 2012 07:10:41 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP6jA-0003uV-7k
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 07:10:40 +0000
Received: from [193.109.254.147:29723] by server-5.bemta-14.messagelabs.com id
	91/C7-18309-FECF0805; Fri, 19 Oct 2012 07:10:39 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1350630637!4106393!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32153 invoked from network); 19 Oct 2012 07:10:37 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-6.tower-27.messagelabs.com with SMTP;
	19 Oct 2012 07:10:37 -0000
Received: from p5b2e238c.dip.t-dialin.net ([91.46.35.140] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from )
	id 1TP6j3-0001Lp-EK; Fri, 19 Oct 2012 07:10:33 +0000
Message-ID: <5080FCE6.906@canonical.com>
Date: Fri, 19 Oct 2012 09:10:30 +0200
From: Stefan Bader 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Jan Beulich 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
	<1350482118.2460.74.camel@zakaz.uk.xensource.com>
	<507ECD06.2050407@canonical.com> <507ED038.8000806@citrix.com>
	<507FC51102000078000A235E@nat28.tlf.novell.com>
	<507FC71502000078000A236C@nat28.tlf.novell.com>
	<507FB1E1.8080700@canonical.com>
	<1350546483.28188.25.camel@dagon.hellion.org.uk>
	<507FD7DE.2010209@canonical.com>
	<507FFA5102000078000A250D@nat28.tlf.novell.com>
	<507FF964.9090009@canonical.com> <50806C0B.1060504@canonical.com>
In-Reply-To: <50806C0B.1060504@canonical.com>
X-Enigmail-Version: 1.4.5
Cc: Andrew Cooper ,
	Konrad Rzeszutek Wilk ,
	Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============7737577943205625628=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============7737577943205625628==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enigCAE020D9B8986FF1DDE9B1EA"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigCAE020D9B8986FF1DDE9B1EA
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 18.10.2012 22:52, Stefan Bader wrote:
> On 18.10.2012 14:43, Stefan Bader wrote:

> So I tried below approach and that seems to be surviving the previously=
 breaking
> testcase for much longer than anything I tried before.
>=20
> -Stefan
>=20
> From f2ebb6626f3e3a00932bf1f4f75265f826c7fba9 Mon Sep 17 00:00:00 2001
> From: Stefan Bader 
> Date: Thu, 18 Oct 2012 21:40:37 +0200
> Subject: [PATCH 1/2] xen/pv-spinlock: Never enable interrupts in
>  xen_spin_lock_slow()
>=20

Testcase ran the whole night without problems. Now re-started it with a c=
leaner
kernel (only the patch above applied and no debugging and it has again pa=
ssed
the threshold it would have broken before.

-Stefan

Oh, just in case this *is* the solution, it should very definitely be mar=
ked
with a cc: stable.



--------------enigCAE020D9B8986FF1DDE9B1EA
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBCgAGBQJQgPzmAAoJEOhnXe7L7s6j8bUP/ittlWh6RnaAsI12Yh33XJ5t
pnquYNqbo84YSc8SnyOs5G5f//sMxJgStUoAPKCCLWTW0yPkX00tstreoAxjuJ5R
+cLZK4ib8BdCvgAdxUwq7zbt/QNe/FA7AK7LpPM0mKhV+GycxDJ8JqeQbrTI3GLO
O9JKiX2KM8hzw3G8qdQ9fnuDnOLKIPXNDHlKUHE4LcIAuFkfDBYIuA/wGweO9b4h
Can3oOBvi9S02CPzn8ygZN3bOL82jFYPlK2kmX2z3O7kX2JTSPy1c4PivWsuf/wY
ukV0c7OrdZR0PGveTUHzQzIdA6H8NxV5AERuEaCAOuS7p/EER48Z4+gmlafHKmXv
mpfaooFKsGWmnfkpKj7PvA1vN3zURRIhb/U4rM1EEHnHCHKxG/I1HcUn5g3K1cMs
/FnW/BsU8o5j4U6ZtdMfrQihgCJxDKmBiAgU2P6SkH+yb1RUxgZPVzKtxGeEnM7R
O2CCLzDvdcPciG+XuYG+3JJrY6Zs9xn7gZrqMutYgbhz3YSG5+v3ALVX5Z0boff6
X6cLGEQjmH2gw0uATBH9VgLtA7a5zBOd5YxGUhyVou6YdBqsO3/LiqJjPEGsGiM6
slE/OdBrXU6Ic7cn1JlGiDHxNuEjQgjxHZVRMcY1ccAwnJh5ZpXZ5kwDj1MKPVgx
mh6qvbLxyGkbzQ6TEqOW
=x0Oj
-----END PGP SIGNATURE-----

--------------enigCAE020D9B8986FF1DDE9B1EA--


--===============7737577943205625628==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7737577943205625628==--


From xen-devel-bounces@lists.xen.org Fri Oct 19 07:11:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 07:11:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP6jB-0003ua-RI; Fri, 19 Oct 2012 07:10:41 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP6jA-0003uV-7k
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 07:10:40 +0000
Received: from [193.109.254.147:29723] by server-5.bemta-14.messagelabs.com id
	91/C7-18309-FECF0805; Fri, 19 Oct 2012 07:10:39 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1350630637!4106393!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32153 invoked from network); 19 Oct 2012 07:10:37 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-6.tower-27.messagelabs.com with SMTP;
	19 Oct 2012 07:10:37 -0000
Received: from p5b2e238c.dip.t-dialin.net ([91.46.35.140] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from )
	id 1TP6j3-0001Lp-EK; Fri, 19 Oct 2012 07:10:33 +0000
Message-ID: <5080FCE6.906@canonical.com>
Date: Fri, 19 Oct 2012 09:10:30 +0200
From: Stefan Bader 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Jan Beulich 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
	<1350482118.2460.74.camel@zakaz.uk.xensource.com>
	<507ECD06.2050407@canonical.com> <507ED038.8000806@citrix.com>
	<507FC51102000078000A235E@nat28.tlf.novell.com>
	<507FC71502000078000A236C@nat28.tlf.novell.com>
	<507FB1E1.8080700@canonical.com>
	<1350546483.28188.25.camel@dagon.hellion.org.uk>
	<507FD7DE.2010209@canonical.com>
	<507FFA5102000078000A250D@nat28.tlf.novell.com>
	<507FF964.9090009@canonical.com> <50806C0B.1060504@canonical.com>
In-Reply-To: <50806C0B.1060504@canonical.com>
X-Enigmail-Version: 1.4.5
Cc: Andrew Cooper ,
	Konrad Rzeszutek Wilk ,
	Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============7737577943205625628=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============7737577943205625628==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enigCAE020D9B8986FF1DDE9B1EA"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigCAE020D9B8986FF1DDE9B1EA
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 18.10.2012 22:52, Stefan Bader wrote:
> On 18.10.2012 14:43, Stefan Bader wrote:

> So I tried below approach and that seems to be surviving the previously=
 breaking
> testcase for much longer than anything I tried before.
>=20
> -Stefan
>=20
> From f2ebb6626f3e3a00932bf1f4f75265f826c7fba9 Mon Sep 17 00:00:00 2001
> From: Stefan Bader 
> Date: Thu, 18 Oct 2012 21:40:37 +0200
> Subject: [PATCH 1/2] xen/pv-spinlock: Never enable interrupts in
>  xen_spin_lock_slow()
>=20

Testcase ran the whole night without problems. Now re-started it with a c=
leaner
kernel (only the patch above applied and no debugging and it has again pa=
ssed
the threshold it would have broken before.

-Stefan

Oh, just in case this *is* the solution, it should very definitely be mar=
ked
with a cc: stable.



--------------enigCAE020D9B8986FF1DDE9B1EA
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBCgAGBQJQgPzmAAoJEOhnXe7L7s6j8bUP/ittlWh6RnaAsI12Yh33XJ5t
pnquYNqbo84YSc8SnyOs5G5f//sMxJgStUoAPKCCLWTW0yPkX00tstreoAxjuJ5R
+cLZK4ib8BdCvgAdxUwq7zbt/QNe/FA7AK7LpPM0mKhV+GycxDJ8JqeQbrTI3GLO
O9JKiX2KM8hzw3G8qdQ9fnuDnOLKIPXNDHlKUHE4LcIAuFkfDBYIuA/wGweO9b4h
Can3oOBvi9S02CPzn8ygZN3bOL82jFYPlK2kmX2z3O7kX2JTSPy1c4PivWsuf/wY
ukV0c7OrdZR0PGveTUHzQzIdA6H8NxV5AERuEaCAOuS7p/EER48Z4+gmlafHKmXv
mpfaooFKsGWmnfkpKj7PvA1vN3zURRIhb/U4rM1EEHnHCHKxG/I1HcUn5g3K1cMs
/FnW/BsU8o5j4U6ZtdMfrQihgCJxDKmBiAgU2P6SkH+yb1RUxgZPVzKtxGeEnM7R
O2CCLzDvdcPciG+XuYG+3JJrY6Zs9xn7gZrqMutYgbhz3YSG5+v3ALVX5Z0boff6
X6cLGEQjmH2gw0uATBH9VgLtA7a5zBOd5YxGUhyVou6YdBqsO3/LiqJjPEGsGiM6
slE/OdBrXU6Ic7cn1JlGiDHxNuEjQgjxHZVRMcY1ccAwnJh5ZpXZ5kwDj1MKPVgx
mh6qvbLxyGkbzQ6TEqOW
=x0Oj
-----END PGP SIGNATURE-----

--------------enigCAE020D9B8986FF1DDE9B1EA--


--===============7737577943205625628==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7737577943205625628==--


From xen-devel-bounces@lists.xen.org Fri Oct 19 07:58:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 07:58:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP7Si-0004F2-Pz; Fri, 19 Oct 2012 07:57:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP7Sg-0004Ex-RU
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 07:57:42 +0000
Received: from [193.109.254.147:56226] by server-9.bemta-14.messagelabs.com id
	24/65-09620-6F701805; Fri, 19 Oct 2012 07:57:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1350633461!1869895!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5MDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25145 invoked from network); 19 Oct 2012 07:57:41 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-27.messagelabs.com with SMTP;
	19 Oct 2012 07:57:41 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 19 Oct 2012 08:57:40 +0100
Message-Id: <5081241402000078000A2837@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 19 Oct 2012 08:57:40 +0100
From: "Jan Beulich" 
To: "Keir Fraser" 
References: <507FF88702000078000A24FE@nat28.tlf.novell.com>
	
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel 
Subject: Re: [Xen-devel] [PATCH 3/3] x86/HPET: cache MSI message last written
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 18.10.12 at 18:42, Keir Fraser  wrote:
> On 18/10/2012 11:39, "Jan Beulich"  wrote:
> 
>>>>> On 18.10.12 at 10:22, Keir Fraser  wrote:
>>> On 16/10/2012 16:11, "Jan Beulich"  wrote:
>>> 
>>>> Rather than spending measurable amounts of time reading back the most
>>>> recently written message, cache it in space previously unused, and thus
>>>> accelerate the CPU's entering of the intended C-state.
>>>> 
>>>> hpet_msi_read() ends up being unused after this change, but rather than
>>>> removing the function, it's being marked "unused" in order - that way
>>>> it can easily get used again should a new need for it arise.
>>> 
>>> Please use __attribute_used__
>> 
>> That wouldn't be correct: The function _is_ unused (and there's
>> no issue if it was used afaik), and the __used__ attribute ought
>> to tell the compiler to keep the function around despite not
>> having (visible to it) callers.
> 
> Perhaps our __attribute_used__ definition should change, then?

I don't think so - this has its own value as is. We may want to add
a Linux-like __maybe_unused, though.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 07:58:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 07:58:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP7Si-0004F2-Pz; Fri, 19 Oct 2012 07:57:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP7Sg-0004Ex-RU
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 07:57:42 +0000
Received: from [193.109.254.147:56226] by server-9.bemta-14.messagelabs.com id
	24/65-09620-6F701805; Fri, 19 Oct 2012 07:57:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1350633461!1869895!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5MDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25145 invoked from network); 19 Oct 2012 07:57:41 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-27.messagelabs.com with SMTP;
	19 Oct 2012 07:57:41 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 19 Oct 2012 08:57:40 +0100
Message-Id: <5081241402000078000A2837@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 19 Oct 2012 08:57:40 +0100
From: "Jan Beulich" 
To: "Keir Fraser" 
References: <507FF88702000078000A24FE@nat28.tlf.novell.com>
	
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel 
Subject: Re: [Xen-devel] [PATCH 3/3] x86/HPET: cache MSI message last written
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 18.10.12 at 18:42, Keir Fraser  wrote:
> On 18/10/2012 11:39, "Jan Beulich"  wrote:
> 
>>>>> On 18.10.12 at 10:22, Keir Fraser  wrote:
>>> On 16/10/2012 16:11, "Jan Beulich"  wrote:
>>> 
>>>> Rather than spending measurable amounts of time reading back the most
>>>> recently written message, cache it in space previously unused, and thus
>>>> accelerate the CPU's entering of the intended C-state.
>>>> 
>>>> hpet_msi_read() ends up being unused after this change, but rather than
>>>> removing the function, it's being marked "unused" in order - that way
>>>> it can easily get used again should a new need for it arise.
>>> 
>>> Please use __attribute_used__
>> 
>> That wouldn't be correct: The function _is_ unused (and there's
>> no issue if it was used afaik), and the __used__ attribute ought
>> to tell the compiler to keep the function around despite not
>> having (visible to it) callers.
> 
> Perhaps our __attribute_used__ definition should change, then?

I don't think so - this has its own value as is. We may want to add
a Linux-like __maybe_unused, though.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 08:07:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 08:07:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP7bi-0004uA-1m; Fri, 19 Oct 2012 08:07:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP7bg-0004u5-BK
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 08:07:00 +0000
Received: from [85.158.139.211:42369] by server-5.bemta-5.messagelabs.com id
	09/C0-09732-32A01805; Fri, 19 Oct 2012 08:06:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1350634019!22858162!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5MDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6241 invoked from network); 19 Oct 2012 08:06:59 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-206.messagelabs.com with SMTP;
	19 Oct 2012 08:06:59 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 19 Oct 2012 09:06:58 +0100
Message-Id: <5081264002000078000A2841@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 19 Oct 2012 09:06:56 +0100
From: "Jan Beulich" 
To: "Stefan Bader" 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
	<1350482118.2460.74.camel@zakaz.uk.xensource.com>
	<507ECD06.2050407@canonical.com> <507ED038.8000806@citrix.com>
	<507FC51102000078000A235E@nat28.tlf.novell.com>
	<507FC71502000078000A236C@nat28.tlf.novell.com>
	<507FB1E1.8080700@canonical.com>
	<1350546483.28188.25.camel@dagon.hellion.org.uk>
	<507FD7DE.2010209@canonical.com>
	<507FFA5102000078000A250D@nat28.tlf.novell.com>
	<507FF964.9090009@canonical.com> <50806C0B.1060504@canonical.com>
In-Reply-To: <50806C0B.1060504@canonical.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper ,
	Konrad Rzeszutek Wilk ,
	Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 18.10.12 at 22:52, Stefan Bader  wrote:
> Actually I begin to suspect that it could be possible that I just overlooked 
> the
> most obvious thing. Provoking question: are we sure we are on the same page
> about the purpose of the spin_lock_flags variant of the pv lock ops 
> interface?
> 
> I begin to suspect that it really is not for giving a chance to re-enable
> interrupts. Just what it should be used for I am not clear. Anyway it seems 
> all
> other places more or less ignore the flags and map themselves back to an
> ignorant version of spinlock.
> Also I believe that the only high level function that would end up in 
> passing
> any flags, would be the spin_lock_irqsave one. And I am pretty sure that 
> this
> one will expect interrupts to stay disabled.

No - the only requirement here is that from the point on where
the lock is owned interrupt must remain disabled. Re-enabling
intermediately is quite okay (and used to be done by the
native kernel prior to the conversion to ticket locks iirc).

> So I tried below approach and that seems to be surviving the previously 
> breaking
> testcase for much longer than anything I tried before.

If that indeed fixes your problem, then (minus eventual problems
with the scope of the interrupts-enabled window) this rather
points at a bug in the users of the spinlock interfaces.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 08:07:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 08:07:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP7bi-0004uA-1m; Fri, 19 Oct 2012 08:07:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP7bg-0004u5-BK
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 08:07:00 +0000
Received: from [85.158.139.211:42369] by server-5.bemta-5.messagelabs.com id
	09/C0-09732-32A01805; Fri, 19 Oct 2012 08:06:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1350634019!22858162!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5MDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6241 invoked from network); 19 Oct 2012 08:06:59 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-206.messagelabs.com with SMTP;
	19 Oct 2012 08:06:59 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 19 Oct 2012 09:06:58 +0100
Message-Id: <5081264002000078000A2841@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 19 Oct 2012 09:06:56 +0100
From: "Jan Beulich" 
To: "Stefan Bader" 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
	<1350482118.2460.74.camel@zakaz.uk.xensource.com>
	<507ECD06.2050407@canonical.com> <507ED038.8000806@citrix.com>
	<507FC51102000078000A235E@nat28.tlf.novell.com>
	<507FC71502000078000A236C@nat28.tlf.novell.com>
	<507FB1E1.8080700@canonical.com>
	<1350546483.28188.25.camel@dagon.hellion.org.uk>
	<507FD7DE.2010209@canonical.com>
	<507FFA5102000078000A250D@nat28.tlf.novell.com>
	<507FF964.9090009@canonical.com> <50806C0B.1060504@canonical.com>
In-Reply-To: <50806C0B.1060504@canonical.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper ,
	Konrad Rzeszutek Wilk ,
	Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 18.10.12 at 22:52, Stefan Bader  wrote:
> Actually I begin to suspect that it could be possible that I just overlooked 
> the
> most obvious thing. Provoking question: are we sure we are on the same page
> about the purpose of the spin_lock_flags variant of the pv lock ops 
> interface?
> 
> I begin to suspect that it really is not for giving a chance to re-enable
> interrupts. Just what it should be used for I am not clear. Anyway it seems 
> all
> other places more or less ignore the flags and map themselves back to an
> ignorant version of spinlock.
> Also I believe that the only high level function that would end up in 
> passing
> any flags, would be the spin_lock_irqsave one. And I am pretty sure that 
> this
> one will expect interrupts to stay disabled.

No - the only requirement here is that from the point on where
the lock is owned interrupt must remain disabled. Re-enabling
intermediately is quite okay (and used to be done by the
native kernel prior to the conversion to ticket locks iirc).

> So I tried below approach and that seems to be surviving the previously 
> breaking
> testcase for much longer than anything I tried before.

If that indeed fixes your problem, then (minus eventual problems
with the scope of the interrupts-enabled window) this rather
points at a bug in the users of the spinlock interfaces.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 08:11:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 08:11:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP7fF-00051T-R0; Fri, 19 Oct 2012 08:10:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP7fE-00051O-Pd
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 08:10:40 +0000
Received: from [85.158.139.211:24182] by server-10.bemta-5.messagelabs.com id
	36/18-01025-00B01805; Fri, 19 Oct 2012 08:10:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1350634238!22883902!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5MDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28728 invoked from network); 19 Oct 2012 08:10:38 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-206.messagelabs.com with SMTP;
	19 Oct 2012 08:10:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 19 Oct 2012 09:10:37 +0100
Message-Id: <5081271C02000078000A2844@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 19 Oct 2012 09:10:36 +0100
From: "Jan Beulich" 
To: "Allan Scheid" 
References: 
	<507C075302000078000A1593@nat28.tlf.novell.com>
	
	
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2 with EFI on IBM x3650 ACPI Bug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 19.10.12 at 01:43, Allan Scheid  wrote:
> Bad news, i am seeing the log output and after the xen.efi boot this still
> appears on log:
> 
> Into messages:
> Oct 18 20:27:36 lca-fw kernel: [    0.000000] ACPI BIOS Bug: Error: A valid
> RSDP was not found (20120711/tbxfroot-219)
> Oct 18 20:27:36 lca-fw kernel: [    0.000000] NUMA turned off
> Oct 18 20:27:36 lca-fw kernel: [    3.759750] pci 0000:00:01.0: can't find
> IRQ for PCI INT A; please try using pci=biosirq
> Oct 18 20:27:36 lca-fw kernel: [    3.764011] pci 0000:00:1a.0: can't find
> IRQ for PCI INT A; please try using pci=biosirq

Of course - you also need the kernel to be capable of obtaining
the necessary EFI information from Xen. That's a separate patch
(an early port of the one we have to the pvops kernel was
posted on the list a few months ago, but I don't know what its
status or disposition is - Konrad?).

> This still causes don't work USB ports and some PCI cards on the system.
> 
> xl dmesg log:
> 
> (XEN) Using APIC driver default

The below shows that Xen is working fine now.

Jan

> (XEN) ACPI: PM-Timer IO Port: 0x588
> (XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[584,0], pm1x_evt[580,0]
> (XEN) ACPI:                  wakeup_vec[7f6eb00c], vec_size[20]
> (XEN) ACPI: Local APIC address 0xfee00000
> (XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
> (XEN) Processor #0 6:12 APIC version 21
> (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled)
> (XEN) Processor #2 6:12 APIC version 21
> (XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled)
> (XEN) Processor #4 6:12 APIC version 21
> (XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x10] enabled)
> (XEN) Processor #16 6:12 APIC version 21
> (XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x12] enabled)
> (XEN) Processor #18 6:12 APIC version 21
> (XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x14] enabled)
> (XEN) Processor #20 6:12 APIC version 21
> (XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x20] disabled)
> (XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x22] disabled)
> (XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x24] disabled)
> (XEN) ACPI: LAPIC (acpi_id[0x09] lapic_id[0x30] disabled)
> (XEN) ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x32] disabled)
> (XEN) ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x34] disabled)
> (XEN) ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x01] enabled)
> (XEN) Processor #1 6:12 APIC version 21
> (XEN) ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x03] enabled)
> (XEN) Processor #3 6:12 APIC version 21
> (XEN) ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x05] enabled)
> (XEN) Processor #5 6:12 APIC version 21
> (XEN) ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x11] enabled)
> (XEN) Processor #17 6:12 APIC version 21
> (XEN) ACPI: LAPIC (acpi_id[0x10] lapic_id[0x13] enabled)
> (XEN) Processor #19 6:12 APIC version 21
> (XEN) ACPI: LAPIC (acpi_id[0x11] lapic_id[0x15] enabled)
> (XEN) Processor #21 6:12 APIC version 21
> (XEN) ACPI: LAPIC (acpi_id[0x12] lapic_id[0x21] disabled)
> (XEN) ACPI: LAPIC (acpi_id[0x13] lapic_id[0x23] disabled)
> (XEN) ACPI: LAPIC (acpi_id[0x14] lapic_id[0x25] disabled)
> (XEN) ACPI: LAPIC (acpi_id[0x15] lapic_id[0x31] disabled)
> (XEN) ACPI: LAPIC (acpi_id[0x16] lapic_id[0x33] disabled)
> (XEN) ACPI: LAPIC (acpi_id[0x17] lapic_id[0x35] disabled)
> (XEN) ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1])
> 
> (XEN) Overriding APIC driver with bigsmp
> (XEN) ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
> (XEN) IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
> (XEN) ACPI: IOAPIC (id[0x09] address[0xfec80000] gsi_base[24])
> (XEN) IOAPIC[1]: apic_id 9, version 32, address 0xfec80000, GSI 24-47
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
> (XEN) ACPI: IRQ0 used by override.
> (XEN) ACPI: IRQ2 used by override.
> (XEN) ACPI: IRQ9 used by override.
> (XEN) Enabling APIC mode:  Phys.  Using 2 I/O APICs
> (XEN) ACPI: HPET id: 0x8086a301 base: 0xfed00000
> (XEN) ERST table is invalid
> (XEN) Using ACPI (MADT) for SMP configuration information


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 08:11:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 08:11:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP7fF-00051T-R0; Fri, 19 Oct 2012 08:10:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP7fE-00051O-Pd
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 08:10:40 +0000
Received: from [85.158.139.211:24182] by server-10.bemta-5.messagelabs.com id
	36/18-01025-00B01805; Fri, 19 Oct 2012 08:10:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1350634238!22883902!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5MDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28728 invoked from network); 19 Oct 2012 08:10:38 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-206.messagelabs.com with SMTP;
	19 Oct 2012 08:10:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 19 Oct 2012 09:10:37 +0100
Message-Id: <5081271C02000078000A2844@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 19 Oct 2012 09:10:36 +0100
From: "Jan Beulich" 
To: "Allan Scheid" 
References: 
	<507C075302000078000A1593@nat28.tlf.novell.com>
	
	
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2 with EFI on IBM x3650 ACPI Bug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 19.10.12 at 01:43, Allan Scheid  wrote:
> Bad news, i am seeing the log output and after the xen.efi boot this still
> appears on log:
> 
> Into messages:
> Oct 18 20:27:36 lca-fw kernel: [    0.000000] ACPI BIOS Bug: Error: A valid
> RSDP was not found (20120711/tbxfroot-219)
> Oct 18 20:27:36 lca-fw kernel: [    0.000000] NUMA turned off
> Oct 18 20:27:36 lca-fw kernel: [    3.759750] pci 0000:00:01.0: can't find
> IRQ for PCI INT A; please try using pci=biosirq
> Oct 18 20:27:36 lca-fw kernel: [    3.764011] pci 0000:00:1a.0: can't find
> IRQ for PCI INT A; please try using pci=biosirq

Of course - you also need the kernel to be capable of obtaining
the necessary EFI information from Xen. That's a separate patch
(an early port of the one we have to the pvops kernel was
posted on the list a few months ago, but I don't know what its
status or disposition is - Konrad?).

> This still causes don't work USB ports and some PCI cards on the system.
> 
> xl dmesg log:
> 
> (XEN) Using APIC driver default

The below shows that Xen is working fine now.

Jan

> (XEN) ACPI: PM-Timer IO Port: 0x588
> (XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[584,0], pm1x_evt[580,0]
> (XEN) ACPI:                  wakeup_vec[7f6eb00c], vec_size[20]
> (XEN) ACPI: Local APIC address 0xfee00000
> (XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
> (XEN) Processor #0 6:12 APIC version 21
> (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled)
> (XEN) Processor #2 6:12 APIC version 21
> (XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled)
> (XEN) Processor #4 6:12 APIC version 21
> (XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x10] enabled)
> (XEN) Processor #16 6:12 APIC version 21
> (XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x12] enabled)
> (XEN) Processor #18 6:12 APIC version 21
> (XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x14] enabled)
> (XEN) Processor #20 6:12 APIC version 21
> (XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x20] disabled)
> (XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x22] disabled)
> (XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x24] disabled)
> (XEN) ACPI: LAPIC (acpi_id[0x09] lapic_id[0x30] disabled)
> (XEN) ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x32] disabled)
> (XEN) ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x34] disabled)
> (XEN) ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x01] enabled)
> (XEN) Processor #1 6:12 APIC version 21
> (XEN) ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x03] enabled)
> (XEN) Processor #3 6:12 APIC version 21
> (XEN) ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x05] enabled)
> (XEN) Processor #5 6:12 APIC version 21
> (XEN) ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x11] enabled)
> (XEN) Processor #17 6:12 APIC version 21
> (XEN) ACPI: LAPIC (acpi_id[0x10] lapic_id[0x13] enabled)
> (XEN) Processor #19 6:12 APIC version 21
> (XEN) ACPI: LAPIC (acpi_id[0x11] lapic_id[0x15] enabled)
> (XEN) Processor #21 6:12 APIC version 21
> (XEN) ACPI: LAPIC (acpi_id[0x12] lapic_id[0x21] disabled)
> (XEN) ACPI: LAPIC (acpi_id[0x13] lapic_id[0x23] disabled)
> (XEN) ACPI: LAPIC (acpi_id[0x14] lapic_id[0x25] disabled)
> (XEN) ACPI: LAPIC (acpi_id[0x15] lapic_id[0x31] disabled)
> (XEN) ACPI: LAPIC (acpi_id[0x16] lapic_id[0x33] disabled)
> (XEN) ACPI: LAPIC (acpi_id[0x17] lapic_id[0x35] disabled)
> (XEN) ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1])
> 
> (XEN) Overriding APIC driver with bigsmp
> (XEN) ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
> (XEN) IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
> (XEN) ACPI: IOAPIC (id[0x09] address[0xfec80000] gsi_base[24])
> (XEN) IOAPIC[1]: apic_id 9, version 32, address 0xfec80000, GSI 24-47
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
> (XEN) ACPI: IRQ0 used by override.
> (XEN) ACPI: IRQ2 used by override.
> (XEN) ACPI: IRQ9 used by override.
> (XEN) Enabling APIC mode:  Phys.  Using 2 I/O APICs
> (XEN) ACPI: HPET id: 0x8086a301 base: 0xfed00000
> (XEN) ERST table is invalid
> (XEN) Using ACPI (MADT) for SMP configuration information


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 08:12:26 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 08:12:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP7ge-00056U-BS; Fri, 19 Oct 2012 08:12:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP7gc-00056J-7L
	for xen-devel@lists.xensource.com; Fri, 19 Oct 2012 08:12:06 +0000
Received: from [85.158.137.99:26345] by server-15.bemta-3.messagelabs.com id
	E4/A7-10261-55B01805; Fri, 19 Oct 2012 08:12:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1350634324!19051337!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ5MzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10507 invoked from network); 19 Oct 2012 08:12:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 08:12:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,612,1344211200"; d="scan'208";a="15269568"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 08:11:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 19 Oct 2012 09:11:42 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TP7gE-0005ue-BH;
	Fri, 19 Oct 2012 08:11:42 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TP7gD-000807-W7;
	Fri, 19 Oct 2012 09:11:42 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Fri, 19 Oct 2012 09:11:42 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14061: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14061 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14061/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 13967
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 13967
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 13967
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 13967

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                    fail pass in 14038
 test-amd64-i386-xl            5 xen-boot                    fail pass in 14045
 test-amd64-i386-pv            5 xen-boot                    fail pass in 14057
 test-amd64-amd64-pair         8 xen-boot/dst_host           fail pass in 14045
 test-amd64-amd64-pair         7 xen-boot/src_host           fail pass in 14045

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13967
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13967
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13967
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13967

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  3fa2ab30bb05
baseline version:
 xen                  c1c549c4fe9e

------------------------------------------------------------
People who touched revisions under test:
  Chuang Cao 
  Daniel De Graaf 
  Huang Ying 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Joe Jin 
  Keir Fraser 
  Olaf Hering 
  Sander Eikelenboom 
  Stefano Stabellini 
  Tim Deegan 
  Xiantao Zhang
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 592 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 08:12:26 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 08:12:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP7ge-00056U-BS; Fri, 19 Oct 2012 08:12:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP7gc-00056J-7L
	for xen-devel@lists.xensource.com; Fri, 19 Oct 2012 08:12:06 +0000
Received: from [85.158.137.99:26345] by server-15.bemta-3.messagelabs.com id
	E4/A7-10261-55B01805; Fri, 19 Oct 2012 08:12:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1350634324!19051337!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ5MzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10507 invoked from network); 19 Oct 2012 08:12:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 08:12:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,612,1344211200"; d="scan'208";a="15269568"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 08:11:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 19 Oct 2012 09:11:42 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TP7gE-0005ue-BH;
	Fri, 19 Oct 2012 08:11:42 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TP7gD-000807-W7;
	Fri, 19 Oct 2012 09:11:42 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Fri, 19 Oct 2012 09:11:42 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14061: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14061 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14061/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 13967
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 13967
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 13967
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 13967

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                    fail pass in 14038
 test-amd64-i386-xl            5 xen-boot                    fail pass in 14045
 test-amd64-i386-pv            5 xen-boot                    fail pass in 14057
 test-amd64-amd64-pair         8 xen-boot/dst_host           fail pass in 14045
 test-amd64-amd64-pair         7 xen-boot/src_host           fail pass in 14045

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13967
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13967
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13967
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13967

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  3fa2ab30bb05
baseline version:
 xen                  c1c549c4fe9e

------------------------------------------------------------
People who touched revisions under test:
  Chuang Cao 
  Daniel De Graaf 
  Huang Ying 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Joe Jin 
  Keir Fraser 
  Olaf Hering 
  Sander Eikelenboom 
  Stefano Stabellini 
  Tim Deegan 
  Xiantao Zhang
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 592 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 08:26:54 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 08:26:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP7ug-0005Ml-2S; Fri, 19 Oct 2012 08:26:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP7ue-0005Mg-Qc
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 08:26:37 +0000
Received: from [85.158.143.99:27318] by server-1.bemta-4.messagelabs.com id
	54/4A-19134-CBE01805; Fri, 19 Oct 2012 08:26:36 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1350635194!29439870!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ5MzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12579 invoked from network); 19 Oct 2012 08:26:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 08:26:34 -0000
X-IronPort-AV: E=Sophos;i="4.80,612,1344211200"; d="scan'208";a="15269907"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 08:26:33 +0000
Received: from [192.168.1.30] (10.31.3.231) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 19 Oct 2012 09:26:33 +0100
Message-ID: <50810EB8.3060801@citrix.com>
Date: Fri, 19 Oct 2012 10:26:32 +0200
From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: James Harper 
References: <1350559321-19066-1-git-send-email-roger.pau@citrix.com>
	<6035A0D088A63A46850C3988ED045A4B32C1043A@BITCOM1.int.sbss.com.au>
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B32C1043A@BITCOM1.int.sbss.com.au>
Cc: Oliver Chick ,
	"konrad.wilk@oracle.com" ,
	"linux-kernel@vger.kernel.org" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH RFC] Persistent grant maps for xen blk
	drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 19/10/12 03:34, James Harper wrote:
>>
>> This patch implements persistent grants for the xen-blk{front,back}
>> mechanism. The effect of this change is to reduce the number of unmap
>> operations performed, since they cause a (costly) TLB shootdown. This allows
>> the I/O performance to scale better when a large number of VMs are
>> performing I/O.
>>
>> Previously, the blkfront driver was supplied a bvec[] from the request
>> queue. This was granted to dom0; dom0 performed the I/O and wrote
>> directly into the grant-mapped memory and unmapped it; blkfront then
>> removed foreign access for that grant. The cost of unmapping scales badly
>> with the number of CPUs in Dom0. An experiment showed that when
>> Dom0 has 24 VCPUs, and guests are performing parallel I/O to a ramdisk, the
>> IPIs from performing unmap's is a bottleneck at 5 guests (at which point
>> 650,000 IOPS are being performed in total). If more than 5 guests are used,
>> the performance declines. By 10 guests, only
>> 400,000 IOPS are being performed.
>>
>> This patch improves performance by only unmapping when the connection
>> between blkfront and back is broken.
> 
> I assume network drivers would suffer from the same affliction... Would a more general persistent map solution be worth considering (or be possible)? So a common interface to this persistent mapping allowing the persistent pool to be shared between all drivers in the DomU?

Yes, there are plans to implement the same for network drivers. I would
generally avoid having a shared pool of grants for all the devices of a
DomU, as said in the description of the patch:

Blkback stores a mapping of grefs=>{page mapped to by gref} in
a red-black tree. As the grefs are not known apriori, and provide no
guarantees on their ordering, we have to perform a search
through this tree to find the page, for every gref we receive. This
operation takes O(log n) time in the worst case.

Having a shared pool with all grants would mean that n will become much
higher, and so the search time for a grant would increase. Also, if the
pool is shared some kind of concurrency control should be added, which
will make it even slower.

What should be shared are the structures used to save the grants (struct
grant and struct persistent_gnt for front and back drivers
respectively), and the red-black tree implementation (foreach_grant,
add_persistent_gnt and get_persistent_gnt). This functions should be
moved to a common header for the net implementation.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 08:26:54 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 08:26:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP7ug-0005Ml-2S; Fri, 19 Oct 2012 08:26:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP7ue-0005Mg-Qc
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 08:26:37 +0000
Received: from [85.158.143.99:27318] by server-1.bemta-4.messagelabs.com id
	54/4A-19134-CBE01805; Fri, 19 Oct 2012 08:26:36 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1350635194!29439870!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ5MzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12579 invoked from network); 19 Oct 2012 08:26:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 08:26:34 -0000
X-IronPort-AV: E=Sophos;i="4.80,612,1344211200"; d="scan'208";a="15269907"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 08:26:33 +0000
Received: from [192.168.1.30] (10.31.3.231) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 19 Oct 2012 09:26:33 +0100
Message-ID: <50810EB8.3060801@citrix.com>
Date: Fri, 19 Oct 2012 10:26:32 +0200
From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: James Harper 
References: <1350559321-19066-1-git-send-email-roger.pau@citrix.com>
	<6035A0D088A63A46850C3988ED045A4B32C1043A@BITCOM1.int.sbss.com.au>
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B32C1043A@BITCOM1.int.sbss.com.au>
Cc: Oliver Chick ,
	"konrad.wilk@oracle.com" ,
	"linux-kernel@vger.kernel.org" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH RFC] Persistent grant maps for xen blk
	drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 19/10/12 03:34, James Harper wrote:
>>
>> This patch implements persistent grants for the xen-blk{front,back}
>> mechanism. The effect of this change is to reduce the number of unmap
>> operations performed, since they cause a (costly) TLB shootdown. This allows
>> the I/O performance to scale better when a large number of VMs are
>> performing I/O.
>>
>> Previously, the blkfront driver was supplied a bvec[] from the request
>> queue. This was granted to dom0; dom0 performed the I/O and wrote
>> directly into the grant-mapped memory and unmapped it; blkfront then
>> removed foreign access for that grant. The cost of unmapping scales badly
>> with the number of CPUs in Dom0. An experiment showed that when
>> Dom0 has 24 VCPUs, and guests are performing parallel I/O to a ramdisk, the
>> IPIs from performing unmap's is a bottleneck at 5 guests (at which point
>> 650,000 IOPS are being performed in total). If more than 5 guests are used,
>> the performance declines. By 10 guests, only
>> 400,000 IOPS are being performed.
>>
>> This patch improves performance by only unmapping when the connection
>> between blkfront and back is broken.
> 
> I assume network drivers would suffer from the same affliction... Would a more general persistent map solution be worth considering (or be possible)? So a common interface to this persistent mapping allowing the persistent pool to be shared between all drivers in the DomU?

Yes, there are plans to implement the same for network drivers. I would
generally avoid having a shared pool of grants for all the devices of a
DomU, as said in the description of the patch:

Blkback stores a mapping of grefs=>{page mapped to by gref} in
a red-black tree. As the grefs are not known apriori, and provide no
guarantees on their ordering, we have to perform a search
through this tree to find the page, for every gref we receive. This
operation takes O(log n) time in the worst case.

Having a shared pool with all grants would mean that n will become much
higher, and so the search time for a grant would increase. Also, if the
pool is shared some kind of concurrency control should be added, which
will make it even slower.

What should be shared are the structures used to save the grants (struct
grant and struct persistent_gnt for front and back drivers
respectively), and the red-black tree implementation (foreach_grant,
add_persistent_gnt and get_persistent_gnt). This functions should be
moved to a common header for the net implementation.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 08:31:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 08:31:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP7z9-0005WK-WD; Fri, 19 Oct 2012 08:31:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP7z8-0005WE-35
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 08:31:14 +0000
Received: from [85.158.143.35:58570] by server-1.bemta-4.messagelabs.com id
	56/E1-19134-1DF01805; Fri, 19 Oct 2012 08:31:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1350635463!14609636!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5MDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22592 invoked from network); 19 Oct 2012 08:31:03 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-21.messagelabs.com with SMTP;
	19 Oct 2012 08:31:03 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 19 Oct 2012 09:31:02 +0100
Message-Id: <50812BE502000078000A2864@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 19 Oct 2012 09:31:01 +0100
From: "Jan Beulich" 
To: "Ronny Hegewald" 
References: <201210180049.56561.ronny.hegewald@online.de>
	<507FC9E202000078000A237E@nat28.tlf.novell.com>
	<201210190035.13872.ronny.hegewald@online.de>
In-Reply-To: <201210190035.13872.ronny.hegewald@online.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/1] keep iommu disabled until iommu_setup
 is called
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 19.10.12 at 02:35, Ronny Hegewald  wrote:
>>  The concept is plausible, but I'm not convinced that there aren't
>> any users of iommu_enabled that actually depend on it having
>> its final value after command line parsing, yet before
>> iommu_setup() gets called. 
> 
> But that is currently only true for systems with a iommu. For the ones 
> without 
> one have iommu_enabled=1 first, until iommu_setup() is called and 
> iommu_enabled is set to 0 because of the not detectable iommu.

That's a valid argument.

> So, with or without my patch, a similiar problem seems to be present, just 
> for different systems.
> 
>> Did you fully audit all users?
> 
> No, because there is just no way i can make a meaningfull judgement how the 
> iommu code interdepends with all the other parts that check iommu_enabled. 

I did a brief check, and it seems to be okay. I guess we'll have to
deal with eventual fallout then.

>> As to the patch itself, ...
> 
> I will send a 2. version which addresses your comments as soon its clear if 
> the approach in the patch is the right one to fix the crash.

Please do.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 08:31:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 08:31:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP7z9-0005WK-WD; Fri, 19 Oct 2012 08:31:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP7z8-0005WE-35
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 08:31:14 +0000
Received: from [85.158.143.35:58570] by server-1.bemta-4.messagelabs.com id
	56/E1-19134-1DF01805; Fri, 19 Oct 2012 08:31:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1350635463!14609636!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5MDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22592 invoked from network); 19 Oct 2012 08:31:03 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-21.messagelabs.com with SMTP;
	19 Oct 2012 08:31:03 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 19 Oct 2012 09:31:02 +0100
Message-Id: <50812BE502000078000A2864@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 19 Oct 2012 09:31:01 +0100
From: "Jan Beulich" 
To: "Ronny Hegewald" 
References: <201210180049.56561.ronny.hegewald@online.de>
	<507FC9E202000078000A237E@nat28.tlf.novell.com>
	<201210190035.13872.ronny.hegewald@online.de>
In-Reply-To: <201210190035.13872.ronny.hegewald@online.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/1] keep iommu disabled until iommu_setup
 is called
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 19.10.12 at 02:35, Ronny Hegewald  wrote:
>>  The concept is plausible, but I'm not convinced that there aren't
>> any users of iommu_enabled that actually depend on it having
>> its final value after command line parsing, yet before
>> iommu_setup() gets called. 
> 
> But that is currently only true for systems with a iommu. For the ones 
> without 
> one have iommu_enabled=1 first, until iommu_setup() is called and 
> iommu_enabled is set to 0 because of the not detectable iommu.

That's a valid argument.

> So, with or without my patch, a similiar problem seems to be present, just 
> for different systems.
> 
>> Did you fully audit all users?
> 
> No, because there is just no way i can make a meaningfull judgement how the 
> iommu code interdepends with all the other parts that check iommu_enabled. 

I did a brief check, and it seems to be okay. I guess we'll have to
deal with eventual fallout then.

>> As to the patch itself, ...
> 
> I will send a 2. version which addresses your comments as soon its clear if 
> the approach in the patch is the right one to fix the crash.

Please do.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 08:33:33 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 08:33:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP818-0005h8-IO; Fri, 19 Oct 2012 08:33:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP818-0005h2-1w
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 08:33:18 +0000
Received: from [85.158.143.35:10758] by server-1.bemta-4.messagelabs.com id
	96/55-19134-D4011805; Fri, 19 Oct 2012 08:33:17 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1350635596!14609978!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30564 invoked from network); 19 Oct 2012 08:33:16 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-13.tower-21.messagelabs.com with SMTP;
	19 Oct 2012 08:33:16 -0000
Received: from p5b2e238c.dip.t-dialin.net ([91.46.35.140] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from )
	id 1TP815-0003TO-9D; Fri, 19 Oct 2012 08:33:15 +0000
Message-ID: <50811047.4080200@canonical.com>
Date: Fri, 19 Oct 2012 10:33:11 +0200
From: Stefan Bader 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Jan Beulich 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
	<1350482118.2460.74.camel@zakaz.uk.xensource.com>
	<507ECD06.2050407@canonical.com> <507ED038.8000806@citrix.com>
	<507FC51102000078000A235E@nat28.tlf.novell.com>
	<507FC71502000078000A236C@nat28.tlf.novell.com>
	<507FB1E1.8080700@canonical.com>
	<1350546483.28188.25.camel@dagon.hellion.org.uk>
	<507FD7DE.2010209@canonical.com>
	<507FFA5102000078000A250D@nat28.tlf.novell.com>
	<507FF964.9090009@canonical.com> <50806C0B.1060504@canonical.com>
	<5081264002000078000A2841@nat28.tlf.novell.com>
In-Reply-To: <5081264002000078000A2841@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.5
Cc: Andrew Cooper ,
	Konrad Rzeszutek Wilk ,
	Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============6728416877343941212=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============6728416877343941212==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig686397E221017B7B45E4895C"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig686397E221017B7B45E4895C
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 19.10.2012 10:06, Jan Beulich wrote:
>>>> On 18.10.12 at 22:52, Stefan Bader  wrot=
e:
>> Actually I begin to suspect that it could be possible that I just over=
looked=20
>> the
>> most obvious thing. Provoking question: are we sure we are on the same=
 page
>> about the purpose of the spin_lock_flags variant of the pv lock ops=20
>> interface?
>>
>> I begin to suspect that it really is not for giving a chance to re-ena=
ble
>> interrupts. Just what it should be used for I am not clear. Anyway it =
seems=20
>> all
>> other places more or less ignore the flags and map themselves back to =
an
>> ignorant version of spinlock.
>> Also I believe that the only high level function that would end up in =

>> passing
>> any flags, would be the spin_lock_irqsave one. And I am pretty sure th=
at=20
>> this
>> one will expect interrupts to stay disabled.
>=20
> No - the only requirement here is that from the point on where
> the lock is owned interrupt must remain disabled. Re-enabling
> intermediately is quite okay (and used to be done by the
> native kernel prior to the conversion to ticket locks iirc).

Though it seems rather dangerous then. Don't remember the old code, but i=
mo it
always opens up a (even microscopic) window to unexpected interruptions.

>=20
>> So I tried below approach and that seems to be surviving the previousl=
y=20
>> breaking
>> testcase for much longer than anything I tried before.
>=20
> If that indeed fixes your problem, then (minus eventual problems
> with the scope of the interrupts-enabled window) this rather
> points at a bug in the users of the spinlock interfaces.

I would be pragmatic here, none of the other current implementations seem=
 to
re-enable interrupts and so this only affects xen pv. And how much really=
 is
gained from enabling it compared to the risk of being affected by somethi=
ng that
nobody else will be?

>=20
> Jan
>=20



--------------enig686397E221017B7B45E4895C
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBCgAGBQJQgRBIAAoJEOhnXe7L7s6jX74P/2FVJXa6TrkGNg+tACUfwktI
+Ev8d/spqMqO2Y3tG8KghRB4yWLr1Vp5R9b7dKxf30nnG6eFoEYOuJ0+kSkgIlU7
vrVcxCjrSPrRXCNenGMMcKxRzu8BIY58Jr2NUWaOz5mHvpFKK5Y2Poecy0Sb7hFf
vFDGkDcrdzQN7sV8f5R1haoDpNT5KlLtXo49M2Hiul6oMOlQrbgqo8OcBRggpU3V
jSZGFHZfc/XaaAFR1GNDnQYIctFZt1HtFw8f2oZLw6GZFp1uLrcaCt6xkmHIjoTf
4vf8fxrGCSO/ZFKzFhQMQNv/TtWn+fhgj73V7qb/4of91Or/WXfN+NVkCduws0ZL
628b7HvbARTt5Wlas8WMZyIqbgQ5S0SZlrOMPJUKXgAM4ETwQqKCmH7h4hd285CL
tPyqFifCRy8BT1Rp39WNfJ/IQ2Wbvg5RO/0y6TogHOI5b7haQuZjqDXUjANOsWZ+
teV06pEXq96dG+mGGegWWklfpWbUIpgtNzadBn7uQjABzgUh0KEzzipwZwuZpo3L
S8shFOcZGjoqRMdMiWOoquofkQklj67wufXBBn4y8ln+pJ0MDlGJ33BJJDMiL+cK
/qsyQhgcFEBR9svUnz7fdtSwtN5uyZ52WDBFh/H3kIOmVJaFyzByqnIBHi4PUH+N
25R89WMtF9wIxVZ8i691
=q4sc
-----END PGP SIGNATURE-----

--------------enig686397E221017B7B45E4895C--


--===============6728416877343941212==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6728416877343941212==--


From xen-devel-bounces@lists.xen.org Fri Oct 19 08:33:33 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 08:33:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP818-0005h8-IO; Fri, 19 Oct 2012 08:33:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP818-0005h2-1w
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 08:33:18 +0000
Received: from [85.158.143.35:10758] by server-1.bemta-4.messagelabs.com id
	96/55-19134-D4011805; Fri, 19 Oct 2012 08:33:17 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1350635596!14609978!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30564 invoked from network); 19 Oct 2012 08:33:16 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-13.tower-21.messagelabs.com with SMTP;
	19 Oct 2012 08:33:16 -0000
Received: from p5b2e238c.dip.t-dialin.net ([91.46.35.140] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from )
	id 1TP815-0003TO-9D; Fri, 19 Oct 2012 08:33:15 +0000
Message-ID: <50811047.4080200@canonical.com>
Date: Fri, 19 Oct 2012 10:33:11 +0200
From: Stefan Bader 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Jan Beulich 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
	<1350482118.2460.74.camel@zakaz.uk.xensource.com>
	<507ECD06.2050407@canonical.com> <507ED038.8000806@citrix.com>
	<507FC51102000078000A235E@nat28.tlf.novell.com>
	<507FC71502000078000A236C@nat28.tlf.novell.com>
	<507FB1E1.8080700@canonical.com>
	<1350546483.28188.25.camel@dagon.hellion.org.uk>
	<507FD7DE.2010209@canonical.com>
	<507FFA5102000078000A250D@nat28.tlf.novell.com>
	<507FF964.9090009@canonical.com> <50806C0B.1060504@canonical.com>
	<5081264002000078000A2841@nat28.tlf.novell.com>
In-Reply-To: <5081264002000078000A2841@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.5
Cc: Andrew Cooper ,
	Konrad Rzeszutek Wilk ,
	Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============6728416877343941212=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============6728416877343941212==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig686397E221017B7B45E4895C"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig686397E221017B7B45E4895C
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 19.10.2012 10:06, Jan Beulich wrote:
>>>> On 18.10.12 at 22:52, Stefan Bader  wrot=
e:
>> Actually I begin to suspect that it could be possible that I just over=
looked=20
>> the
>> most obvious thing. Provoking question: are we sure we are on the same=
 page
>> about the purpose of the spin_lock_flags variant of the pv lock ops=20
>> interface?
>>
>> I begin to suspect that it really is not for giving a chance to re-ena=
ble
>> interrupts. Just what it should be used for I am not clear. Anyway it =
seems=20
>> all
>> other places more or less ignore the flags and map themselves back to =
an
>> ignorant version of spinlock.
>> Also I believe that the only high level function that would end up in =

>> passing
>> any flags, would be the spin_lock_irqsave one. And I am pretty sure th=
at=20
>> this
>> one will expect interrupts to stay disabled.
>=20
> No - the only requirement here is that from the point on where
> the lock is owned interrupt must remain disabled. Re-enabling
> intermediately is quite okay (and used to be done by the
> native kernel prior to the conversion to ticket locks iirc).

Though it seems rather dangerous then. Don't remember the old code, but i=
mo it
always opens up a (even microscopic) window to unexpected interruptions.

>=20
>> So I tried below approach and that seems to be surviving the previousl=
y=20
>> breaking
>> testcase for much longer than anything I tried before.
>=20
> If that indeed fixes your problem, then (minus eventual problems
> with the scope of the interrupts-enabled window) this rather
> points at a bug in the users of the spinlock interfaces.

I would be pragmatic here, none of the other current implementations seem=
 to
re-enable interrupts and so this only affects xen pv. And how much really=
 is
gained from enabling it compared to the risk of being affected by somethi=
ng that
nobody else will be?

>=20
> Jan
>=20



--------------enig686397E221017B7B45E4895C
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBCgAGBQJQgRBIAAoJEOhnXe7L7s6jX74P/2FVJXa6TrkGNg+tACUfwktI
+Ev8d/spqMqO2Y3tG8KghRB4yWLr1Vp5R9b7dKxf30nnG6eFoEYOuJ0+kSkgIlU7
vrVcxCjrSPrRXCNenGMMcKxRzu8BIY58Jr2NUWaOz5mHvpFKK5Y2Poecy0Sb7hFf
vFDGkDcrdzQN7sV8f5R1haoDpNT5KlLtXo49M2Hiul6oMOlQrbgqo8OcBRggpU3V
jSZGFHZfc/XaaAFR1GNDnQYIctFZt1HtFw8f2oZLw6GZFp1uLrcaCt6xkmHIjoTf
4vf8fxrGCSO/ZFKzFhQMQNv/TtWn+fhgj73V7qb/4of91Or/WXfN+NVkCduws0ZL
628b7HvbARTt5Wlas8WMZyIqbgQ5S0SZlrOMPJUKXgAM4ETwQqKCmH7h4hd285CL
tPyqFifCRy8BT1Rp39WNfJ/IQ2Wbvg5RO/0y6TogHOI5b7haQuZjqDXUjANOsWZ+
teV06pEXq96dG+mGGegWWklfpWbUIpgtNzadBn7uQjABzgUh0KEzzipwZwuZpo3L
S8shFOcZGjoqRMdMiWOoquofkQklj67wufXBBn4y8ln+pJ0MDlGJ33BJJDMiL+cK
/qsyQhgcFEBR9svUnz7fdtSwtN5uyZ52WDBFh/H3kIOmVJaFyzByqnIBHi4PUH+N
25R89WMtF9wIxVZ8i691
=q4sc
-----END PGP SIGNATURE-----

--------------enig686397E221017B7B45E4895C--


--===============6728416877343941212==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6728416877343941212==--


From xen-devel-bounces@lists.xen.org Fri Oct 19 08:37:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 08:37:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP85L-0005vz-ET; Fri, 19 Oct 2012 08:37:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP85K-0005vt-6c
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 08:37:38 +0000
Received: from [85.158.143.35:9370] by server-1.bemta-4.messagelabs.com id
	2F/9B-19134-15111805; Fri, 19 Oct 2012 08:37:37 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1350635846!14668575!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ5MzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 584 invoked from network); 19 Oct 2012 08:37:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 08:37:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,612,1344211200"; d="scan'208";a="15270232"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 08:37:26 +0000
Received: from [192.168.1.30] (10.31.3.231) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 19 Oct 2012 09:37:26 +0100
Message-ID: <50811145.3030705@citrix.com>
Date: Fri, 19 Oct 2012 10:37:25 +0200
From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: Andres Lagar-Cavilla 
References: <5171750d133ef2c27ac8.1350055853@xdev.gridcentric.ca>
	<1350547689.28188.31.camel@dagon.hellion.org.uk>
	
In-Reply-To: 
Cc: Christoph Egger ,
	Ian Campbell ,
	Ian Jackson ,
	"xen-devel@lists.xen.org" ,
	Andres Lagar-Cavilla ,
	Attilio Rao 
Subject: Re: [Xen-devel] [PATCH] Synchronize privcmd header constants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 19/10/12 04:20, Andres Lagar-Cavilla wrote:
> I've had a look. The xen.org tree knows about three other OSes: minios, solaris and netbsd. None knows about paged out frames. None uses the XEN_DOMCTL_PFINFO_PAGEDTAB constant in domctl.h
> 
> 1. The domctl.h constant can still go away without hurting other OSes.

I've checked and NetBSD doesn't use XEN_DOMCTL_PFINFO_PAGEDTAB, so as
Andres says I guess it's safe to remove it.

> 2. It is trivial to add the PRIVCMD_MMAPBATCH_* constants to the privcmd.h of other OSes. It can't hurt. I can do it here. Each OS Xen maintainer would have to take care of syncing that up in the respective upstream. However ...
> 3. Not that trivial to teach all these OSes about paged out frames. Does anyone care?

Well, I'm sure the NetBSD community would be interested in this, but
finding someone to actually work on it is a whole different story...

> Please advise.
> Thanks
> Andres
> 
> On Oct 18, 2012, at 4:08 AM, Ian Campbell  wrote:
> 
>> On Fri, 2012-10-12 at 16:30 +0100, Andres Lagar-Cavilla wrote:
>>> tools/include/xen-sys/Linux/privcmd.h |   3 +++
>>> tools/libxc/xc_linux_osdep.c          |  10 +++++-----
>>> xen/include/public/domctl.h           |   1 -
>>> 3 files changed, 8 insertions(+), 6 deletions(-)
>>>
>>>
>>> Since Linux's git commit ceb90fa0a8008059ecbbf9114cb89dc71a730bb6, the
>>> privcmd.h interface between Linux and libxc specifies two new constants,
>>> PRIVCMD_MMAPBATCH_MFN_ERROR and PRIVCMD_MMAPBATCH_PAGED_ERROR. These constants
>>> represent the error codes encoded in the top nibble of an mfn slot passed to
>>> the legacy MMAPBATCH ioctl.
>>>
>>> In particular, libxenctrl checks for the equivalent of the latter constant when
>>> dealing with paged out frames that might be the target of a foreign map.
>>>
>>> Previously, the relevant constant was defined in the domctl hypervisor
>>> interface header (XEN_DOMCTL_PFINFO_PAGEDTAB). Because this top-nibble encoding
>>> is a contract between the dom0 kernel and libxc, a domctl.h definition is
>>> misplaced.
>>>
>>> - Sync the privcmd.h header to that now available in upstream Linux
>>
>> Although the ioctl is Linux specific is the top-nibble behaviour (and
>> therefore the #define) common to other dom0s like *BSD? Can a BSD person
>> confirm that this change won't breaking things for them please.
>>
>>> - Update libxc appropriately
>>> - Remove the unnecessary constant in domctl.h
>>>
>>> Signed-off-by: Andres Lagar-Cavilla 
>>>
>>> diff -r 4eed5e64544f -r 5171750d133e tools/include/xen-sys/Linux/privcmd.h
>>> --- a/tools/include/xen-sys/Linux/privcmd.h
>>> +++ b/tools/include/xen-sys/Linux/privcmd.h
>>> @@ -64,6 +64,9 @@ typedef struct privcmd_mmapbatch {
>>> 	xen_pfn_t __user *arr; /* array of mfns - top nibble set on err */
>>> } privcmd_mmapbatch_t; 
>>>
>>> +#define PRIVCMD_MMAPBATCH_MFN_ERROR     0xf0000000U
>>> +#define PRIVCMD_MMAPBATCH_PAGED_ERROR   0x80000000U
>>> +
>>> typedef struct privcmd_mmapbatch_v2 {
>>> 	unsigned int num; /* number of pages to populate */
>>> 	domid_t dom;      /* target domain */
>>> diff -r 4eed5e64544f -r 5171750d133e tools/libxc/xc_linux_osdep.c
>>> --- a/tools/libxc/xc_linux_osdep.c
>>> +++ b/tools/libxc/xc_linux_osdep.c
>>> @@ -129,7 +129,7 @@ static int xc_map_foreign_batch_single(i
>>>
>>>     do
>>>     {
>>> -        *mfn ^= XEN_DOMCTL_PFINFO_PAGEDTAB;
>>> +        *mfn ^= PRIVCMD_MMAPBATCH_PAGED_ERROR;
>>>         usleep(100);
>>>         rc = ioctl(fd, IOCTL_PRIVCMD_MMAPBATCH, &ioctlx);
>>>     }
>>> @@ -166,8 +166,8 @@ static void *linux_privcmd_map_foreign_b
>>>
>>>         for ( i = 0; i < num; i++ )
>>>         {
>>> -            if ( (arr[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) ==
>>> -                 XEN_DOMCTL_PFINFO_PAGEDTAB )
>>> +            if ( (arr[i] & PRIVCMD_MMAPBATCH_MFN_ERROR) ==
>>> +                           PRIVCMD_MMAPBATCH_PAGED_ERROR )
>>>             {
>>>                 unsigned long paged_addr = (unsigned long)addr + (i << XC_PAGE_SHIFT);
>>>                 rc = xc_map_foreign_batch_single(fd, dom, &arr[i],
>>> @@ -323,12 +323,12 @@ static void *linux_privcmd_map_foreign_b
>>>             default:
>>>                 err[i] = -EINVAL;
>>>                 continue;
>>> -            case XEN_DOMCTL_PFINFO_PAGEDTAB:
>>> +            case PRIVCMD_MMAPBATCH_PAGED_ERROR:
>>>                 if ( rc != -ENOENT )
>>>                 {
>>>                     err[i] = rc ?: -EINVAL;
>>>                     continue;
>>> -                 }
>>> +                }
>>>                 rc = xc_map_foreign_batch_single(fd, dom, pfn + i,
>>>                         (unsigned long)addr + ((unsigned long)i<>>                 if ( rc < 0 )
>>> diff -r 4eed5e64544f -r 5171750d133e xen/include/public/domctl.h
>>> --- a/xen/include/public/domctl.h
>>> +++ b/xen/include/public/domctl.h
>>> @@ -135,7 +135,6 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_getme
>>> #define XEN_DOMCTL_PFINFO_LPINTAB (0x1U<<31)
>>> #define XEN_DOMCTL_PFINFO_XTAB    (0xfU<<28) /* invalid page */
>>> #define XEN_DOMCTL_PFINFO_XALLOC  (0xeU<<28) /* allocate-only page */
>>> -#define XEN_DOMCTL_PFINFO_PAGEDTAB (0x8U<<28)
>>> #define XEN_DOMCTL_PFINFO_LTAB_MASK (0xfU<<28)
>>>
>>> struct xen_domctl_getpageframeinfo {
>>
>>
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 08:37:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 08:37:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP85L-0005vz-ET; Fri, 19 Oct 2012 08:37:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP85K-0005vt-6c
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 08:37:38 +0000
Received: from [85.158.143.35:9370] by server-1.bemta-4.messagelabs.com id
	2F/9B-19134-15111805; Fri, 19 Oct 2012 08:37:37 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1350635846!14668575!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTQ5MzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 584 invoked from network); 19 Oct 2012 08:37:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 08:37:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,612,1344211200"; d="scan'208";a="15270232"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 08:37:26 +0000
Received: from [192.168.1.30] (10.31.3.231) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 19 Oct 2012 09:37:26 +0100
Message-ID: <50811145.3030705@citrix.com>
Date: Fri, 19 Oct 2012 10:37:25 +0200
From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: Andres Lagar-Cavilla 
References: <5171750d133ef2c27ac8.1350055853@xdev.gridcentric.ca>
	<1350547689.28188.31.camel@dagon.hellion.org.uk>
	
In-Reply-To: 
Cc: Christoph Egger ,
	Ian Campbell ,
	Ian Jackson ,
	"xen-devel@lists.xen.org" ,
	Andres Lagar-Cavilla ,
	Attilio Rao 
Subject: Re: [Xen-devel] [PATCH] Synchronize privcmd header constants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 19/10/12 04:20, Andres Lagar-Cavilla wrote:
> I've had a look. The xen.org tree knows about three other OSes: minios, solaris and netbsd. None knows about paged out frames. None uses the XEN_DOMCTL_PFINFO_PAGEDTAB constant in domctl.h
> 
> 1. The domctl.h constant can still go away without hurting other OSes.

I've checked and NetBSD doesn't use XEN_DOMCTL_PFINFO_PAGEDTAB, so as
Andres says I guess it's safe to remove it.

> 2. It is trivial to add the PRIVCMD_MMAPBATCH_* constants to the privcmd.h of other OSes. It can't hurt. I can do it here. Each OS Xen maintainer would have to take care of syncing that up in the respective upstream. However ...
> 3. Not that trivial to teach all these OSes about paged out frames. Does anyone care?

Well, I'm sure the NetBSD community would be interested in this, but
finding someone to actually work on it is a whole different story...

> Please advise.
> Thanks
> Andres
> 
> On Oct 18, 2012, at 4:08 AM, Ian Campbell  wrote:
> 
>> On Fri, 2012-10-12 at 16:30 +0100, Andres Lagar-Cavilla wrote:
>>> tools/include/xen-sys/Linux/privcmd.h |   3 +++
>>> tools/libxc/xc_linux_osdep.c          |  10 +++++-----
>>> xen/include/public/domctl.h           |   1 -
>>> 3 files changed, 8 insertions(+), 6 deletions(-)
>>>
>>>
>>> Since Linux's git commit ceb90fa0a8008059ecbbf9114cb89dc71a730bb6, the
>>> privcmd.h interface between Linux and libxc specifies two new constants,
>>> PRIVCMD_MMAPBATCH_MFN_ERROR and PRIVCMD_MMAPBATCH_PAGED_ERROR. These constants
>>> represent the error codes encoded in the top nibble of an mfn slot passed to
>>> the legacy MMAPBATCH ioctl.
>>>
>>> In particular, libxenctrl checks for the equivalent of the latter constant when
>>> dealing with paged out frames that might be the target of a foreign map.
>>>
>>> Previously, the relevant constant was defined in the domctl hypervisor
>>> interface header (XEN_DOMCTL_PFINFO_PAGEDTAB). Because this top-nibble encoding
>>> is a contract between the dom0 kernel and libxc, a domctl.h definition is
>>> misplaced.
>>>
>>> - Sync the privcmd.h header to that now available in upstream Linux
>>
>> Although the ioctl is Linux specific is the top-nibble behaviour (and
>> therefore the #define) common to other dom0s like *BSD? Can a BSD person
>> confirm that this change won't breaking things for them please.
>>
>>> - Update libxc appropriately
>>> - Remove the unnecessary constant in domctl.h
>>>
>>> Signed-off-by: Andres Lagar-Cavilla 
>>>
>>> diff -r 4eed5e64544f -r 5171750d133e tools/include/xen-sys/Linux/privcmd.h
>>> --- a/tools/include/xen-sys/Linux/privcmd.h
>>> +++ b/tools/include/xen-sys/Linux/privcmd.h
>>> @@ -64,6 +64,9 @@ typedef struct privcmd_mmapbatch {
>>> 	xen_pfn_t __user *arr; /* array of mfns - top nibble set on err */
>>> } privcmd_mmapbatch_t; 
>>>
>>> +#define PRIVCMD_MMAPBATCH_MFN_ERROR     0xf0000000U
>>> +#define PRIVCMD_MMAPBATCH_PAGED_ERROR   0x80000000U
>>> +
>>> typedef struct privcmd_mmapbatch_v2 {
>>> 	unsigned int num; /* number of pages to populate */
>>> 	domid_t dom;      /* target domain */
>>> diff -r 4eed5e64544f -r 5171750d133e tools/libxc/xc_linux_osdep.c
>>> --- a/tools/libxc/xc_linux_osdep.c
>>> +++ b/tools/libxc/xc_linux_osdep.c
>>> @@ -129,7 +129,7 @@ static int xc_map_foreign_batch_single(i
>>>
>>>     do
>>>     {
>>> -        *mfn ^= XEN_DOMCTL_PFINFO_PAGEDTAB;
>>> +        *mfn ^= PRIVCMD_MMAPBATCH_PAGED_ERROR;
>>>         usleep(100);
>>>         rc = ioctl(fd, IOCTL_PRIVCMD_MMAPBATCH, &ioctlx);
>>>     }
>>> @@ -166,8 +166,8 @@ static void *linux_privcmd_map_foreign_b
>>>
>>>         for ( i = 0; i < num; i++ )
>>>         {
>>> -            if ( (arr[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) ==
>>> -                 XEN_DOMCTL_PFINFO_PAGEDTAB )
>>> +            if ( (arr[i] & PRIVCMD_MMAPBATCH_MFN_ERROR) ==
>>> +                           PRIVCMD_MMAPBATCH_PAGED_ERROR )
>>>             {
>>>                 unsigned long paged_addr = (unsigned long)addr + (i << XC_PAGE_SHIFT);
>>>                 rc = xc_map_foreign_batch_single(fd, dom, &arr[i],
>>> @@ -323,12 +323,12 @@ static void *linux_privcmd_map_foreign_b
>>>             default:
>>>                 err[i] = -EINVAL;
>>>                 continue;
>>> -            case XEN_DOMCTL_PFINFO_PAGEDTAB:
>>> +            case PRIVCMD_MMAPBATCH_PAGED_ERROR:
>>>                 if ( rc != -ENOENT )
>>>                 {
>>>                     err[i] = rc ?: -EINVAL;
>>>                     continue;
>>> -                 }
>>> +                }
>>>                 rc = xc_map_foreign_batch_single(fd, dom, pfn + i,
>>>                         (unsigned long)addr + ((unsigned long)i<>>                 if ( rc < 0 )
>>> diff -r 4eed5e64544f -r 5171750d133e xen/include/public/domctl.h
>>> --- a/xen/include/public/domctl.h
>>> +++ b/xen/include/public/domctl.h
>>> @@ -135,7 +135,6 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_getme
>>> #define XEN_DOMCTL_PFINFO_LPINTAB (0x1U<<31)
>>> #define XEN_DOMCTL_PFINFO_XTAB    (0xfU<<28) /* invalid page */
>>> #define XEN_DOMCTL_PFINFO_XALLOC  (0xeU<<28) /* allocate-only page */
>>> -#define XEN_DOMCTL_PFINFO_PAGEDTAB (0x8U<<28)
>>> #define XEN_DOMCTL_PFINFO_LTAB_MASK (0xfU<<28)
>>>
>>> struct xen_domctl_getpageframeinfo {
>>
>>
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 09:18:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 09:18:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP8i2-0006Ih-2f; Fri, 19 Oct 2012 09:17:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP8i0-0006IX-Fy
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 09:17:36 +0000
Received: from [85.158.138.51:24151] by server-14.bemta-3.messagelabs.com id
	75/B3-17276-FAA11805; Fri, 19 Oct 2012 09:17:35 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1350638254!26110022!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NDA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15236 invoked from network); 19 Oct 2012 09:17:34 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-174.messagelabs.com with SMTP;
	19 Oct 2012 09:17:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 19 Oct 2012 10:17:33 +0100
Message-Id: <508136CD02000078000A2888@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 19 Oct 2012 10:17:33 +0100
From: "Jan Beulich" 
To: "xen-devel" 
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part1E2FC2BD.1__="
Cc: Wei Wang 
Subject: [Xen-devel] [PATCH] IOMMU: fail HPET MSI setup on AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part1E2FC2BD.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

While the MSI message format doesn't need adjustment for AMD IOMMUs,
the interrupt remapping tables still need updating. The respective code
has to be able to determine the IOMMU responsible, which currently
requires an associated PCI device. The absence of that device in the
HPET case causes the code to crash, and the code determining the source
ID to be used for HPETs (parse_ivhd_device_special() afaict) isn't even
looking at whether it's dealing with an IO-APIC or a HPET (i.e. ignores
the "variety" structure member). If I tried to fix that, I would have
no way to test that I did things right, so all I can do to fix the
crash is make the setup fail if the IOMMU did not provide a handler
(which, considering the above, is the right thing anyway).

Signed-off-by: Jan Beulich 

--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -498,7 +498,7 @@ unsigned int iommu_read_apic_from_ire(un
 int __init iommu_setup_hpet_msi(struct msi_desc *msi)
 {
     const struct iommu_ops *ops =3D iommu_get_ops();
-    return ops->setup_hpet_msi ? ops->setup_hpet_msi(msi) : 0;
+    return ops->setup_hpet_msi ? ops->setup_hpet_msi(msi) : -ENODEV;
 }
=20
 void iommu_resume()




--=__Part1E2FC2BD.1__=
Content-Type: text/plain; name="x86-HPET-intremap-Intel-only.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-HPET-intremap-Intel-only.patch"

IOMMU: fail HPET MSI setup on AMD=0A=0AWhile the MSI message format =
doesn't need adjustment for AMD IOMMUs,=0Athe interrupt remapping tables =
still need updating. The respective code=0Ahas to be able to determine the =
IOMMU responsible, which currently=0Arequires an associated PCI device. =
The absence of that device in the=0AHPET case causes the code to crash, =
and the code determining the source=0AID to be used for HPETs (parse_ivhd_d=
evice_special() afaict) isn't even=0Alooking at whether it's dealing with =
an IO-APIC or a HPET (i.e. ignores=0Athe "variety" structure member). If I =
tried to fix that, I would have=0Ano way to test that I did things right, =
so all I can do to fix the=0Acrash is make the setup fail if the IOMMU did =
not provide a handler=0A(which, considering the above, is the right thing =
anyway).=0A=0ASigned-off-by: Jan Beulich =0A=0A--- =
a/xen/drivers/passthrough/iommu.c=0A+++ b/xen/drivers/passthrough/iommu.c=
=0A@@ -498,7 +498,7 @@ unsigned int iommu_read_apic_from_ire(un=0A int =
__init iommu_setup_hpet_msi(struct msi_desc *msi)=0A {=0A     const struct =
iommu_ops *ops =3D iommu_get_ops();=0A-    return ops->setup_hpet_msi ? =
ops->setup_hpet_msi(msi) : 0;=0A+    return ops->setup_hpet_msi ? =
ops->setup_hpet_msi(msi) : -ENODEV;=0A }=0A =0A void iommu_resume()=0A
--=__Part1E2FC2BD.1__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__Part1E2FC2BD.1__=--


From xen-devel-bounces@lists.xen.org Fri Oct 19 09:18:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 09:18:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP8i2-0006Ih-2f; Fri, 19 Oct 2012 09:17:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP8i0-0006IX-Fy
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 09:17:36 +0000
Received: from [85.158.138.51:24151] by server-14.bemta-3.messagelabs.com id
	75/B3-17276-FAA11805; Fri, 19 Oct 2012 09:17:35 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1350638254!26110022!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NDA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15236 invoked from network); 19 Oct 2012 09:17:34 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-174.messagelabs.com with SMTP;
	19 Oct 2012 09:17:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 19 Oct 2012 10:17:33 +0100
Message-Id: <508136CD02000078000A2888@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 19 Oct 2012 10:17:33 +0100
From: "Jan Beulich" 
To: "xen-devel" 
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part1E2FC2BD.1__="
Cc: Wei Wang 
Subject: [Xen-devel] [PATCH] IOMMU: fail HPET MSI setup on AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part1E2FC2BD.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

While the MSI message format doesn't need adjustment for AMD IOMMUs,
the interrupt remapping tables still need updating. The respective code
has to be able to determine the IOMMU responsible, which currently
requires an associated PCI device. The absence of that device in the
HPET case causes the code to crash, and the code determining the source
ID to be used for HPETs (parse_ivhd_device_special() afaict) isn't even
looking at whether it's dealing with an IO-APIC or a HPET (i.e. ignores
the "variety" structure member). If I tried to fix that, I would have
no way to test that I did things right, so all I can do to fix the
crash is make the setup fail if the IOMMU did not provide a handler
(which, considering the above, is the right thing anyway).

Signed-off-by: Jan Beulich 

--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -498,7 +498,7 @@ unsigned int iommu_read_apic_from_ire(un
 int __init iommu_setup_hpet_msi(struct msi_desc *msi)
 {
     const struct iommu_ops *ops =3D iommu_get_ops();
-    return ops->setup_hpet_msi ? ops->setup_hpet_msi(msi) : 0;
+    return ops->setup_hpet_msi ? ops->setup_hpet_msi(msi) : -ENODEV;
 }
=20
 void iommu_resume()




--=__Part1E2FC2BD.1__=
Content-Type: text/plain; name="x86-HPET-intremap-Intel-only.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-HPET-intremap-Intel-only.patch"

IOMMU: fail HPET MSI setup on AMD=0A=0AWhile the MSI message format =
doesn't need adjustment for AMD IOMMUs,=0Athe interrupt remapping tables =
still need updating. The respective code=0Ahas to be able to determine the =
IOMMU responsible, which currently=0Arequires an associated PCI device. =
The absence of that device in the=0AHPET case causes the code to crash, =
and the code determining the source=0AID to be used for HPETs (parse_ivhd_d=
evice_special() afaict) isn't even=0Alooking at whether it's dealing with =
an IO-APIC or a HPET (i.e. ignores=0Athe "variety" structure member). If I =
tried to fix that, I would have=0Ano way to test that I did things right, =
so all I can do to fix the=0Acrash is make the setup fail if the IOMMU did =
not provide a handler=0A(which, considering the above, is the right thing =
anyway).=0A=0ASigned-off-by: Jan Beulich =0A=0A--- =
a/xen/drivers/passthrough/iommu.c=0A+++ b/xen/drivers/passthrough/iommu.c=
=0A@@ -498,7 +498,7 @@ unsigned int iommu_read_apic_from_ire(un=0A int =
__init iommu_setup_hpet_msi(struct msi_desc *msi)=0A {=0A     const struct =
iommu_ops *ops =3D iommu_get_ops();=0A-    return ops->setup_hpet_msi ? =
ops->setup_hpet_msi(msi) : 0;=0A+    return ops->setup_hpet_msi ? =
ops->setup_hpet_msi(msi) : -ENODEV;=0A }=0A =0A void iommu_resume()=0A
--=__Part1E2FC2BD.1__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__Part1E2FC2BD.1__=--


From xen-devel-bounces@lists.xen.org Fri Oct 19 09:25:06 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 09:25:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP8ow-0006dn-JP; Fri, 19 Oct 2012 09:24:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP8ov-0006di-QR
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 09:24:46 +0000
Received: from [85.158.138.51:15942] by server-4.bemta-3.messagelabs.com id
	DF/7C-01405-C5C11805; Fri, 19 Oct 2012 09:24:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1350638683!33204468!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5MDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22809 invoked from network); 19 Oct 2012 09:24:44 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-174.messagelabs.com with SMTP;
	19 Oct 2012 09:24:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 19 Oct 2012 10:24:43 +0100
Message-Id: <5081387B02000078000A288D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 19 Oct 2012 10:24:43 +0100
From: "Jan Beulich" 
To: "Stefan Bader" 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
	<1350482118.2460.74.camel@zakaz.uk.xensource.com>
	<507ECD06.2050407@canonical.com> <507ED038.8000806@citrix.com>
	<507FC51102000078000A235E@nat28.tlf.novell.com>
	<507FC71502000078000A236C@nat28.tlf.novell.com>
	<507FB1E1.8080700@canonical.com>
	<1350546483.28188.25.camel@dagon.hellion.org.uk>
	<507FD7DE.2010209@canonical.com>
	<507FFA5102000078000A250D@nat28.tlf.novell.com>
	<507FF964.9090009@canonical.com> <50806C0B.1060504@canonical.com>
	<5081264002000078000A2841@nat28.tlf.novell.com>
	<50811047.4080200@canonical.com>
In-Reply-To: <50811047.4080200@canonical.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper ,
	Konrad Rzeszutek Wilk ,
	Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 19.10.12 at 10:33, Stefan Bader  wrote:
> On 19.10.2012 10:06, Jan Beulich wrote:
>>>>> On 18.10.12 at 22:52, Stefan Bader  wrote:
>>> Actually I begin to suspect that it could be possible that I just overlooked 
> 
>>> the
>>> most obvious thing. Provoking question: are we sure we are on the same page
>>> about the purpose of the spin_lock_flags variant of the pv lock ops 
>>> interface?
>>>
>>> I begin to suspect that it really is not for giving a chance to re-enable
>>> interrupts. Just what it should be used for I am not clear. Anyway it seems 
>>> all
>>> other places more or less ignore the flags and map themselves back to an
>>> ignorant version of spinlock.
>>> Also I believe that the only high level function that would end up in 
>>> passing
>>> any flags, would be the spin_lock_irqsave one. And I am pretty sure that 
>>> this
>>> one will expect interrupts to stay disabled.
>> 
>> No - the only requirement here is that from the point on where
>> the lock is owned interrupt must remain disabled. Re-enabling
>> intermediately is quite okay (and used to be done by the
>> native kernel prior to the conversion to ticket locks iirc).
> 
> Though it seems rather dangerous then. Don't remember the old code, but imo 
> it
> always opens up a (even microscopic) window to unexpected interruptions.

There just can't be unexpected interruptions. Whenever interrupts
are enabled, it is expected that they can occur.

>>> So I tried below approach and that seems to be surviving the previously 
>>> breaking
>>> testcase for much longer than anything I tried before.
>> 
>> If that indeed fixes your problem, then (minus eventual problems
>> with the scope of the interrupts-enabled window) this rather
>> points at a bug in the users of the spinlock interfaces.
> 
> I would be pragmatic here, none of the other current implementations seem to
> re-enable interrupts and so this only affects xen pv.

I don't think you really checked - the first arch I looked at (s390,
as being the most obvious one to look at when it comes to
virtualization) quite prominently re-enableds interrupts in
arch_spin_lock_wait_flags().

> And how much really is
> gained from enabling it compared to the risk of being affected by something 
> that nobody else will be?

The main difference between the native and virtualized cases is
that the period of time you spend waiting for the lock to become
available is pretty much unbounded (even more so without ticket
locks), and keeping interrupts disabled for such an extended
period of time is just going to ask for other problems.

And note that this isn't the case just for Xen PV - all virtualization
scenarios suffer from that.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 09:25:06 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 09:25:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP8ow-0006dn-JP; Fri, 19 Oct 2012 09:24:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP8ov-0006di-QR
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 09:24:46 +0000
Received: from [85.158.138.51:15942] by server-4.bemta-3.messagelabs.com id
	DF/7C-01405-C5C11805; Fri, 19 Oct 2012 09:24:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1350638683!33204468!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5MDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22809 invoked from network); 19 Oct 2012 09:24:44 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-174.messagelabs.com with SMTP;
	19 Oct 2012 09:24:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 19 Oct 2012 10:24:43 +0100
Message-Id: <5081387B02000078000A288D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 19 Oct 2012 10:24:43 +0100
From: "Jan Beulich" 
To: "Stefan Bader" 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
	<1350482118.2460.74.camel@zakaz.uk.xensource.com>
	<507ECD06.2050407@canonical.com> <507ED038.8000806@citrix.com>
	<507FC51102000078000A235E@nat28.tlf.novell.com>
	<507FC71502000078000A236C@nat28.tlf.novell.com>
	<507FB1E1.8080700@canonical.com>
	<1350546483.28188.25.camel@dagon.hellion.org.uk>
	<507FD7DE.2010209@canonical.com>
	<507FFA5102000078000A250D@nat28.tlf.novell.com>
	<507FF964.9090009@canonical.com> <50806C0B.1060504@canonical.com>
	<5081264002000078000A2841@nat28.tlf.novell.com>
	<50811047.4080200@canonical.com>
In-Reply-To: <50811047.4080200@canonical.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper ,
	Konrad Rzeszutek Wilk ,
	Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 19.10.12 at 10:33, Stefan Bader  wrote:
> On 19.10.2012 10:06, Jan Beulich wrote:
>>>>> On 18.10.12 at 22:52, Stefan Bader  wrote:
>>> Actually I begin to suspect that it could be possible that I just overlooked 
> 
>>> the
>>> most obvious thing. Provoking question: are we sure we are on the same page
>>> about the purpose of the spin_lock_flags variant of the pv lock ops 
>>> interface?
>>>
>>> I begin to suspect that it really is not for giving a chance to re-enable
>>> interrupts. Just what it should be used for I am not clear. Anyway it seems 
>>> all
>>> other places more or less ignore the flags and map themselves back to an
>>> ignorant version of spinlock.
>>> Also I believe that the only high level function that would end up in 
>>> passing
>>> any flags, would be the spin_lock_irqsave one. And I am pretty sure that 
>>> this
>>> one will expect interrupts to stay disabled.
>> 
>> No - the only requirement here is that from the point on where
>> the lock is owned interrupt must remain disabled. Re-enabling
>> intermediately is quite okay (and used to be done by the
>> native kernel prior to the conversion to ticket locks iirc).
> 
> Though it seems rather dangerous then. Don't remember the old code, but imo 
> it
> always opens up a (even microscopic) window to unexpected interruptions.

There just can't be unexpected interruptions. Whenever interrupts
are enabled, it is expected that they can occur.

>>> So I tried below approach and that seems to be surviving the previously 
>>> breaking
>>> testcase for much longer than anything I tried before.
>> 
>> If that indeed fixes your problem, then (minus eventual problems
>> with the scope of the interrupts-enabled window) this rather
>> points at a bug in the users of the spinlock interfaces.
> 
> I would be pragmatic here, none of the other current implementations seem to
> re-enable interrupts and so this only affects xen pv.

I don't think you really checked - the first arch I looked at (s390,
as being the most obvious one to look at when it comes to
virtualization) quite prominently re-enableds interrupts in
arch_spin_lock_wait_flags().

> And how much really is
> gained from enabling it compared to the risk of being affected by something 
> that nobody else will be?

The main difference between the native and virtualized cases is
that the period of time you spend waiting for the lock to become
available is pretty much unbounded (even more so without ticket
locks), and keeping interrupts disabled for such an extended
period of time is just going to ask for other problems.

And note that this isn't the case just for Xen PV - all virtualization
scenarios suffer from that.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 09:33:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 09:33:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP8wy-0006wr-MR; Fri, 19 Oct 2012 09:33:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP8wx-0006wj-Je
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 09:33:03 +0000
Received: from [193.109.254.147:27987] by server-16.bemta-14.messagelabs.com
	id C6/73-13226-E4E11805; Fri, 19 Oct 2012 09:33:02 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1350639181!10643261!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10178 invoked from network); 19 Oct 2012 09:33:02 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 09:33:02 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so124451eek.32
	for ; Fri, 19 Oct 2012 02:33:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=pngUwseXKbRKTuTN8Y78st1E40dqOyHN2SbrFyiiv8I=;
	b=ooXmfcxf8EItZQC/iptalu4sfyvMEAlDfOk/r2k1aVRGuXhlmjvgx0oPWx9l+VaxQG
	qcCU8JUK/QOqz6df/avPH/hCbrfpOB3WbSchKL02X6u9QXX0apOFQuljKo6nny/grLJB
	+RLVf81OxZuafUzfXaq/4Ay7T9HHztSRQGNYWDbWWrohds2NQuQDGxNEKwzjN/oWFLB7
	wWlRALj20t2lsgwRgJU0OYw62KRZmJwHZE4DaSny2X8eYKDfXBepU6a5uxtfWxkA25e5
	ZNuqbPzNWJS2LZOillGs1y4mMFREvwo+N94xmp3jqwbFHxcjDRnTbfBwsSeFqL8yxLx2
	vvQQ==
Received: by 10.14.175.71 with SMTP id y47mr849538eel.36.1350639181703;
	Fri, 19 Oct 2012 02:33:01 -0700 (PDT)
Received: from [192.168.1.3] (host86-178-46-35.range86-178.btcentralplus.com.
	[86.178.46.35])
	by mx.google.com with ESMTPS id i41sm1675492eem.7.2012.10.19.02.33.00
	(version=SSLv3 cipher=OTHER); Fri, 19 Oct 2012 02:33:01 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Fri, 19 Oct 2012 10:32:56 +0100
From: Keir Fraser 
To: Jan Beulich 
Message-ID: 
Thread-Topic: [Xen-devel] [PATCH 3/3] x86/HPET: cache MSI message last written
Thread-Index: Ac2t3LhLHerXcl9j3k2nz6DzN33JkQ==
In-Reply-To: <5081241402000078000A2837@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel 
Subject: Re: [Xen-devel] [PATCH 3/3] x86/HPET: cache MSI message last written
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 19/10/2012 08:57, "Jan Beulich"  wrote:

>>> That wouldn't be correct: The function _is_ unused (and there's
>>> no issue if it was used afaik), and the __used__ attribute ought
>>> to tell the compiler to keep the function around despite not
>>> having (visible to it) callers.
>> 
>> Perhaps our __attribute_used__ definition should change, then?
> 
> I don't think so - this has its own value as is. We may want to add
> a Linux-like __maybe_unused, though.

Could you do that, and add comments to the definitions of __attribute_used__
and __maybe_unused, describing exactly what they are to be used for?

 Thanks,
 Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 09:33:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 09:33:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP8wy-0006wr-MR; Fri, 19 Oct 2012 09:33:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP8wx-0006wj-Je
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 09:33:03 +0000
Received: from [193.109.254.147:27987] by server-16.bemta-14.messagelabs.com
	id C6/73-13226-E4E11805; Fri, 19 Oct 2012 09:33:02 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1350639181!10643261!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10178 invoked from network); 19 Oct 2012 09:33:02 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 09:33:02 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so124451eek.32
	for ; Fri, 19 Oct 2012 02:33:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=pngUwseXKbRKTuTN8Y78st1E40dqOyHN2SbrFyiiv8I=;
	b=ooXmfcxf8EItZQC/iptalu4sfyvMEAlDfOk/r2k1aVRGuXhlmjvgx0oPWx9l+VaxQG
	qcCU8JUK/QOqz6df/avPH/hCbrfpOB3WbSchKL02X6u9QXX0apOFQuljKo6nny/grLJB
	+RLVf81OxZuafUzfXaq/4Ay7T9HHztSRQGNYWDbWWrohds2NQuQDGxNEKwzjN/oWFLB7
	wWlRALj20t2lsgwRgJU0OYw62KRZmJwHZE4DaSny2X8eYKDfXBepU6a5uxtfWxkA25e5
	ZNuqbPzNWJS2LZOillGs1y4mMFREvwo+N94xmp3jqwbFHxcjDRnTbfBwsSeFqL8yxLx2
	vvQQ==
Received: by 10.14.175.71 with SMTP id y47mr849538eel.36.1350639181703;
	Fri, 19 Oct 2012 02:33:01 -0700 (PDT)
Received: from [192.168.1.3] (host86-178-46-35.range86-178.btcentralplus.com.
	[86.178.46.35])
	by mx.google.com with ESMTPS id i41sm1675492eem.7.2012.10.19.02.33.00
	(version=SSLv3 cipher=OTHER); Fri, 19 Oct 2012 02:33:01 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Fri, 19 Oct 2012 10:32:56 +0100
From: Keir Fraser 
To: Jan Beulich 
Message-ID: 
Thread-Topic: [Xen-devel] [PATCH 3/3] x86/HPET: cache MSI message last written
Thread-Index: Ac2t3LhLHerXcl9j3k2nz6DzN33JkQ==
In-Reply-To: <5081241402000078000A2837@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel 
Subject: Re: [Xen-devel] [PATCH 3/3] x86/HPET: cache MSI message last written
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 19/10/2012 08:57, "Jan Beulich"  wrote:

>>> That wouldn't be correct: The function _is_ unused (and there's
>>> no issue if it was used afaik), and the __used__ attribute ought
>>> to tell the compiler to keep the function around despite not
>>> having (visible to it) callers.
>> 
>> Perhaps our __attribute_used__ definition should change, then?
> 
> I don't think so - this has its own value as is. We may want to add
> a Linux-like __maybe_unused, though.

Could you do that, and add comments to the definitions of __attribute_used__
and __maybe_unused, describing exactly what they are to be used for?

 Thanks,
 Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 09:40:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 09:40:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP93v-00079e-PW; Fri, 19 Oct 2012 09:40:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP93u-00079Z-Vb
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 09:40:15 +0000
Received: from [193.109.254.147:34301] by server-16.bemta-14.messagelabs.com
	id 32/1D-13226-EFF11805; Fri, 19 Oct 2012 09:40:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1350639612!15234267!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NDA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17177 invoked from network); 19 Oct 2012 09:40:12 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-27.messagelabs.com with SMTP;
	19 Oct 2012 09:40:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 19 Oct 2012 10:40:12 +0100
Message-Id: <50813C1B02000078000A289E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 19 Oct 2012 10:40:11 +0100
From: "Jan Beulich" 
To: "Keir Fraser" 
References: <5081241402000078000A2837@nat28.tlf.novell.com>
	
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel 
Subject: Re: [Xen-devel] [PATCH 3/3] x86/HPET: cache MSI message last written
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 19.10.12 at 11:32, Keir Fraser  wrote:
> On 19/10/2012 08:57, "Jan Beulich"  wrote:
> 
>>>> That wouldn't be correct: The function _is_ unused (and there's
>>>> no issue if it was used afaik), and the __used__ attribute ought
>>>> to tell the compiler to keep the function around despite not
>>>> having (visible to it) callers.
>>> 
>>> Perhaps our __attribute_used__ definition should change, then?
>> 
>> I don't think so - this has its own value as is. We may want to add
>> a Linux-like __maybe_unused, though.
> 
> Could you do that, and add comments to the definitions of __attribute_used__
> and __maybe_unused, describing exactly what they are to be used for?

Sure, will do.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 09:40:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 09:40:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP93v-00079e-PW; Fri, 19 Oct 2012 09:40:15 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP93u-00079Z-Vb
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 09:40:15 +0000
Received: from [193.109.254.147:34301] by server-16.bemta-14.messagelabs.com
	id 32/1D-13226-EFF11805; Fri, 19 Oct 2012 09:40:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1350639612!15234267!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NDA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17177 invoked from network); 19 Oct 2012 09:40:12 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-27.messagelabs.com with SMTP;
	19 Oct 2012 09:40:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 19 Oct 2012 10:40:12 +0100
Message-Id: <50813C1B02000078000A289E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 19 Oct 2012 10:40:11 +0100
From: "Jan Beulich" 
To: "Keir Fraser" 
References: <5081241402000078000A2837@nat28.tlf.novell.com>
	
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel 
Subject: Re: [Xen-devel] [PATCH 3/3] x86/HPET: cache MSI message last written
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 19.10.12 at 11:32, Keir Fraser  wrote:
> On 19/10/2012 08:57, "Jan Beulich"  wrote:
> 
>>>> That wouldn't be correct: The function _is_ unused (and there's
>>>> no issue if it was used afaik), and the __used__ attribute ought
>>>> to tell the compiler to keep the function around despite not
>>>> having (visible to it) callers.
>>> 
>>> Perhaps our __attribute_used__ definition should change, then?
>> 
>> I don't think so - this has its own value as is. We may want to add
>> a Linux-like __maybe_unused, though.
> 
> Could you do that, and add comments to the definitions of __attribute_used__
> and __maybe_unused, describing exactly what they are to be used for?

Sure, will do.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 10:04:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 10:04:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP9Qg-0007UX-AC; Fri, 19 Oct 2012 10:03:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP9Qe-0007US-F5
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 10:03:44 +0000
Received: from [85.158.139.211:35477] by server-3.bemta-5.messagelabs.com id
	35/6F-28618-F7521805; Fri, 19 Oct 2012 10:03:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1350641023!22977836!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUwMDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23446 invoked from network); 19 Oct 2012 10:03:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 10:03:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,612,1344211200"; d="scan'208";a="15272356"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 10:03:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 19 Oct 2012 11:03:42 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TP9Qc-0006hZ-Ii; Fri, 19 Oct 2012 10:03:42 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TP9Qc-0001Zi-Dq;
	Fri, 19 Oct 2012 11:03:42 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20609.9598.286219.485359@mariner.uk.xensource.com>
Date: Fri, 19 Oct 2012 11:03:42 +0100
To: Dario Faggioli 
In-Reply-To: <1350602433.26152.106.camel@Solace>
References: 
	
	
	<1350602433.26152.106.camel@Solace>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Andre Przywara ,
	Ian Campbell ,
	Stefano Stabellini ,
	George Dunlap ,
	Juergen Gross ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 1 of 3] libxl: take node distances into
 account during NUMA placement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dario Faggioli writes ("Re: [Xen-devel] [PATCH 1 of 3] libxl: take node distances into account during NUMA placement"):
> On Thu, 2012-10-18 at 16:17 +0100, George Dunlap wrote:
> > Looks good overall -- my only worry is the N^2 nature of the
> > algorithm.  We're already doing some big combinatorial thing to
> > generate the candidates, right?  
> >
> It is, with N being the number of nodes, which we discussed thoroughly
> already a couple of months ago, and reached consensus on the fact that N
> will stay less than 8 for the next 5 (but probably even more) years. :-)

No, I don't think we did reach consensus about that.  It was asserted
but I dissented.  I don't think this is a reasonable assumption.

> In any case, if something really unexpected happens, and N jumps to
> anything bigger than 16, the placement algorithm won't even start, and
> we'll never reach this point!.

And that is the safety catch you put in because I didn't think the
assumption about numbers of cpus was reasonable.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 10:04:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 10:04:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP9Qg-0007UX-AC; Fri, 19 Oct 2012 10:03:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP9Qe-0007US-F5
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 10:03:44 +0000
Received: from [85.158.139.211:35477] by server-3.bemta-5.messagelabs.com id
	35/6F-28618-F7521805; Fri, 19 Oct 2012 10:03:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1350641023!22977836!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUwMDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23446 invoked from network); 19 Oct 2012 10:03:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 10:03:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,612,1344211200"; d="scan'208";a="15272356"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 10:03:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 19 Oct 2012 11:03:42 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TP9Qc-0006hZ-Ii; Fri, 19 Oct 2012 10:03:42 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TP9Qc-0001Zi-Dq;
	Fri, 19 Oct 2012 11:03:42 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20609.9598.286219.485359@mariner.uk.xensource.com>
Date: Fri, 19 Oct 2012 11:03:42 +0100
To: Dario Faggioli 
In-Reply-To: <1350602433.26152.106.camel@Solace>
References: 
	
	
	<1350602433.26152.106.camel@Solace>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Andre Przywara ,
	Ian Campbell ,
	Stefano Stabellini ,
	George Dunlap ,
	Juergen Gross ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 1 of 3] libxl: take node distances into
 account during NUMA placement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dario Faggioli writes ("Re: [Xen-devel] [PATCH 1 of 3] libxl: take node distances into account during NUMA placement"):
> On Thu, 2012-10-18 at 16:17 +0100, George Dunlap wrote:
> > Looks good overall -- my only worry is the N^2 nature of the
> > algorithm.  We're already doing some big combinatorial thing to
> > generate the candidates, right?  
> >
> It is, with N being the number of nodes, which we discussed thoroughly
> already a couple of months ago, and reached consensus on the fact that N
> will stay less than 8 for the next 5 (but probably even more) years. :-)

No, I don't think we did reach consensus about that.  It was asserted
but I dissented.  I don't think this is a reasonable assumption.

> In any case, if something really unexpected happens, and N jumps to
> anything bigger than 16, the placement algorithm won't even start, and
> we'll never reach this point!.

And that is the safety catch you put in because I didn't think the
assumption about numbers of cpus was reasonable.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 10:25:13 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 10:25:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP9l3-0007jE-PQ; Fri, 19 Oct 2012 10:24:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP9l1-0007j6-Nm
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 10:24:47 +0000
Received: from [85.158.143.35:8651] by server-3.bemta-4.messagelabs.com id
	66/A8-03544-F6A21805; Fri, 19 Oct 2012 10:24:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1350642155!12144673!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUwMDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21149 invoked from network); 19 Oct 2012 10:22:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 10:22:39 -0000
X-IronPort-AV: E=Sophos;i="4.80,612,1344211200"; d="scan'208";a="15272839"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 10:21:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 19 Oct 2012 11:21:46 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TP9i5-0006nM-WC; Fri, 19 Oct 2012 10:21:46 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TP9i5-0001aq-Rr;
	Fri, 19 Oct 2012 11:21:45 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20609.10681.742423.773459@mariner.uk.xensource.com>
Date: Fri, 19 Oct 2012 11:21:45 +0100
To: Ian Campbell 
In-Reply-To: <1350301533.18058.35.camel@zakaz.uk.xensource.com>
References: 
	<692244188.20121015123235@eikelenboom.it>
	<1350297477.18058.27.camel@zakaz.uk.xensource.com>
	<751865457.20121015132140@eikelenboom.it>
	<1350301533.18058.35.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Sander Eikelenboom ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl shutdown compatibility with xm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [PATCH 0 of 5] xl shutdown compatibility with xm"):
> On Mon, 2012-10-15 at 12:21 +0100, Sander Eikelenboom wrote:
> >     - On shutdown with xl as toolstack and when the guest doesn't
> > support pv shutdown, the init.d/xendomains script doesn't even attempt
> > to shutdown this guest by acpi fallback.
> >     - As a result when using xl as toolstack, the guest is terminated
> > non gracefully when the whole machine finally shutsdown, which seems
> > less desirable then at least *trying* to shut it down gracefully by
> > using the acpi button.
> 
> Using the ACPI fallback is a decision which can only be made locally
> with full knowledge of the configuration of the guests.

I'm still with Sander on this, I'm afraid.

Certainly in the init scripts the default should be to try
 xl shutdown -F
and only do destroy if that didn't seem to work.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 10:25:13 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 10:25:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP9l3-0007jE-PQ; Fri, 19 Oct 2012 10:24:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TP9l1-0007j6-Nm
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 10:24:47 +0000
Received: from [85.158.143.35:8651] by server-3.bemta-4.messagelabs.com id
	66/A8-03544-F6A21805; Fri, 19 Oct 2012 10:24:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1350642155!12144673!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUwMDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21149 invoked from network); 19 Oct 2012 10:22:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 10:22:39 -0000
X-IronPort-AV: E=Sophos;i="4.80,612,1344211200"; d="scan'208";a="15272839"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 10:21:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 19 Oct 2012 11:21:46 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TP9i5-0006nM-WC; Fri, 19 Oct 2012 10:21:46 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TP9i5-0001aq-Rr;
	Fri, 19 Oct 2012 11:21:45 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20609.10681.742423.773459@mariner.uk.xensource.com>
Date: Fri, 19 Oct 2012 11:21:45 +0100
To: Ian Campbell 
In-Reply-To: <1350301533.18058.35.camel@zakaz.uk.xensource.com>
References: 
	<692244188.20121015123235@eikelenboom.it>
	<1350297477.18058.27.camel@zakaz.uk.xensource.com>
	<751865457.20121015132140@eikelenboom.it>
	<1350301533.18058.35.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Sander Eikelenboom ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl shutdown compatibility with xm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [PATCH 0 of 5] xl shutdown compatibility with xm"):
> On Mon, 2012-10-15 at 12:21 +0100, Sander Eikelenboom wrote:
> >     - On shutdown with xl as toolstack and when the guest doesn't
> > support pv shutdown, the init.d/xendomains script doesn't even attempt
> > to shutdown this guest by acpi fallback.
> >     - As a result when using xl as toolstack, the guest is terminated
> > non gracefully when the whole machine finally shutsdown, which seems
> > less desirable then at least *trying* to shut it down gracefully by
> > using the acpi button.
> 
> Using the ACPI fallback is a decision which can only be made locally
> with full knowledge of the configuration of the guests.

I'm still with Sander on this, I'm afraid.

Certainly in the init scripts the default should be to try
 xl shutdown -F
and only do destroy if that didn't seem to work.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 10:36:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 10:36:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP9w4-0007y4-1l; Fri, 19 Oct 2012 10:36:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP9w2-0007xz-WE
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 10:36:11 +0000
Received: from [85.158.137.99:34189] by server-1.bemta-3.messagelabs.com id
	C9/72-31728-A1D21805; Fri, 19 Oct 2012 10:36:10 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1350642969!22112541!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUwMDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20996 invoked from network); 19 Oct 2012 10:36:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 10:36:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,612,1344211200"; d="scan'208";a="15273213"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 10:36:07 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 19 Oct 2012 11:36:07 +0100
Date: Fri, 19 Oct 2012 11:35:43 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Dario Faggioli 
In-Reply-To: <1350602433.26152.106.camel@Solace>
Message-ID: 
References: 
	
	
	<1350602433.26152.106.camel@Solace>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Andre Przywara ,
	Ian Campbell ,
	Stefano Stabellini ,
	George Dunlap ,
	Juergen Gross ,
	Ian Jackson ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 1 of 3] libxl: take node distances into
 account during NUMA placement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 19 Oct 2012, Dario Faggioli wrote:
> > Suppose we get an ARM system with 4096 cores and 128 NUMA
> > nodes?  If Xen 4.4 doesn't come out until March 2014, there will still
> > be distros using 4.3 through mid-2015.
> > 
> Right, but I really don't think that monster is actually made out of
> 4096 cores arranged in 128 _NUMA_ nodes on which you run the same
> instance of the hypervisor.

In fact it does not. It would be 4096 cores arranged in 1024 nodes, each
node completely independent from one another.


> I also recall hearing the numbers and the use of the word "node", but I
> really think they was rather referred to a cluster architecture where "a
> node" means something more like "a server", each one running their copy
> of Xen (although they'll be packed all together in the same rack,
> talking via some super-fast interconnect).

Exactly right.


> I'm pretty sure I remember Stefano speculating about the need to use
> some orchestration layer (like {Cloud,Open}Stack) _within_ those big
> irons to deal exactly with that... Stefano, am I talking nonsense? :-D

Nope, all true.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 10:36:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 10:36:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP9w4-0007y4-1l; Fri, 19 Oct 2012 10:36:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP9w2-0007xz-WE
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 10:36:11 +0000
Received: from [85.158.137.99:34189] by server-1.bemta-3.messagelabs.com id
	C9/72-31728-A1D21805; Fri, 19 Oct 2012 10:36:10 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1350642969!22112541!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUwMDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20996 invoked from network); 19 Oct 2012 10:36:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 10:36:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,612,1344211200"; d="scan'208";a="15273213"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 10:36:07 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 19 Oct 2012 11:36:07 +0100
Date: Fri, 19 Oct 2012 11:35:43 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Dario Faggioli 
In-Reply-To: <1350602433.26152.106.camel@Solace>
Message-ID: 
References: 
	
	
	<1350602433.26152.106.camel@Solace>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Andre Przywara ,
	Ian Campbell ,
	Stefano Stabellini ,
	George Dunlap ,
	Juergen Gross ,
	Ian Jackson ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 1 of 3] libxl: take node distances into
 account during NUMA placement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 19 Oct 2012, Dario Faggioli wrote:
> > Suppose we get an ARM system with 4096 cores and 128 NUMA
> > nodes?  If Xen 4.4 doesn't come out until March 2014, there will still
> > be distros using 4.3 through mid-2015.
> > 
> Right, but I really don't think that monster is actually made out of
> 4096 cores arranged in 128 _NUMA_ nodes on which you run the same
> instance of the hypervisor.

In fact it does not. It would be 4096 cores arranged in 1024 nodes, each
node completely independent from one another.


> I also recall hearing the numbers and the use of the word "node", but I
> really think they was rather referred to a cluster architecture where "a
> node" means something more like "a server", each one running their copy
> of Xen (although they'll be packed all together in the same rack,
> talking via some super-fast interconnect).

Exactly right.


> I'm pretty sure I remember Stefano speculating about the need to use
> some orchestration layer (like {Cloud,Open}Stack) _within_ those big
> irons to deal exactly with that... Stefano, am I talking nonsense? :-D

Nope, all true.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 10:40:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 10:40:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP9zc-00085B-NO; Fri, 19 Oct 2012 10:39:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP9za-000856-UL
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 10:39:51 +0000
Received: from [85.158.139.83:9782] by server-14.bemta-5.messagelabs.com id
	D3/0E-24068-6FD21805; Fri, 19 Oct 2012 10:39:50 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1350643167!31707924!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUwMDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19887 invoked from network); 19 Oct 2012 10:39:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 10:39:27 -0000
X-IronPort-AV: E=Sophos;i="4.80,612,1344211200"; d="scan'208";a="15273301"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 10:39:27 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 19 Oct 2012 11:39:26 +0100
Date: Fri, 19 Oct 2012 11:39:02 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Jackson 
In-Reply-To: <20609.9598.286219.485359@mariner.uk.xensource.com>
Message-ID: 
References: 
	
	
	<1350602433.26152.106.camel@Solace>
	<20609.9598.286219.485359@mariner.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Andre Przywara ,
	Ian Campbell ,
	Stefano Stabellini ,
	George Dunlap ,
	Dario Faggioli ,
	"xen-devel@lists.xen.org" ,
	Juergen Gross 
Subject: Re: [Xen-devel] [PATCH 1 of 3] libxl: take node distances into
 account during NUMA placement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 19 Oct 2012, Ian Jackson wrote:
> Dario Faggioli writes ("Re: [Xen-devel] [PATCH 1 of 3] libxl: take node distances into account during NUMA placement"):
> > On Thu, 2012-10-18 at 16:17 +0100, George Dunlap wrote:
> > > Looks good overall -- my only worry is the N^2 nature of the
> > > algorithm.  We're already doing some big combinatorial thing to
> > > generate the candidates, right?  
> > >
> > It is, with N being the number of nodes, which we discussed thoroughly
> > already a couple of months ago, and reached consensus on the fact that N
> > will stay less than 8 for the next 5 (but probably even more) years. :-)
> 
> No, I don't think we did reach consensus about that.  It was asserted
> but I dissented.  I don't think this is a reasonable assumption.

When Dario speaks about consensus in terms of hardware that is going to
reach the market, he really means what Intel and AMD have told us.

Sorry but your opinion doesn't count that much in the matter of cpu
architecture being produces in the near future, unless you have already
started a secret Californian cpu startup, that nobody knows about yet
;-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 10:40:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 10:40:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP9zc-00085B-NO; Fri, 19 Oct 2012 10:39:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TP9za-000856-UL
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 10:39:51 +0000
Received: from [85.158.139.83:9782] by server-14.bemta-5.messagelabs.com id
	D3/0E-24068-6FD21805; Fri, 19 Oct 2012 10:39:50 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1350643167!31707924!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUwMDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19887 invoked from network); 19 Oct 2012 10:39:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 10:39:27 -0000
X-IronPort-AV: E=Sophos;i="4.80,612,1344211200"; d="scan'208";a="15273301"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 10:39:27 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 19 Oct 2012 11:39:26 +0100
Date: Fri, 19 Oct 2012 11:39:02 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Jackson 
In-Reply-To: <20609.9598.286219.485359@mariner.uk.xensource.com>
Message-ID: 
References: 
	
	
	<1350602433.26152.106.camel@Solace>
	<20609.9598.286219.485359@mariner.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Andre Przywara ,
	Ian Campbell ,
	Stefano Stabellini ,
	George Dunlap ,
	Dario Faggioli ,
	"xen-devel@lists.xen.org" ,
	Juergen Gross 
Subject: Re: [Xen-devel] [PATCH 1 of 3] libxl: take node distances into
 account during NUMA placement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 19 Oct 2012, Ian Jackson wrote:
> Dario Faggioli writes ("Re: [Xen-devel] [PATCH 1 of 3] libxl: take node distances into account during NUMA placement"):
> > On Thu, 2012-10-18 at 16:17 +0100, George Dunlap wrote:
> > > Looks good overall -- my only worry is the N^2 nature of the
> > > algorithm.  We're already doing some big combinatorial thing to
> > > generate the candidates, right?  
> > >
> > It is, with N being the number of nodes, which we discussed thoroughly
> > already a couple of months ago, and reached consensus on the fact that N
> > will stay less than 8 for the next 5 (but probably even more) years. :-)
> 
> No, I don't think we did reach consensus about that.  It was asserted
> but I dissented.  I don't think this is a reasonable assumption.

When Dario speaks about consensus in terms of hardware that is going to
reach the market, he really means what Intel and AMD have told us.

Sorry but your opinion doesn't count that much in the matter of cpu
architecture being produces in the near future, unless you have already
started a secret Californian cpu startup, that nobody knows about yet
;-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 10:47:28 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 10:47:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPA6f-0008GC-Nm; Fri, 19 Oct 2012 10:47:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPA6d-0008G6-T4
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 10:47:08 +0000
Received: from [85.158.139.211:21979] by server-10.bemta-5.messagelabs.com id
	2C/FA-01025-BAF21805; Fri, 19 Oct 2012 10:47:07 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-5.tower-206.messagelabs.com!1350643622!22906504!1
X-Originating-IP: [203.16.224.4]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7491 invoked from network); 19 Oct 2012 10:47:05 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-5.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	19 Oct 2012 10:47:05 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp1.bendigoit.com.au with esmtp (Exim 4.69)
	(envelope-from )
	id 1TPA6T-0007Ie-Bx; Fri, 19 Oct 2012 21:46:57 +1100
Received: from BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d]) by
	BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d%12]) with mapi id
	14.01.0421.002; Fri, 19 Oct 2012 21:46:57 +1100
From: James Harper 
To: =?iso-8859-1?Q?Roger_Pau_Monn=E9?= 
Thread-Topic: [Xen-devel] [PATCH RFC] Persistent grant maps for xen blk drivers
Thread-Index: AQHNrSPHQ3cOVHsv2Ui1q3f+GnpWRpe+90QggACc8ACAANDKAA==
Date: Fri, 19 Oct 2012 10:46:56 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B32C11932@BITCOM1.int.sbss.com.au>
References: <1350559321-19066-1-git-send-email-roger.pau@citrix.com>
	<6035A0D088A63A46850C3988ED045A4B32C1043A@BITCOM1.int.sbss.com.au>
	<50810EB8.3060801@citrix.com>
In-Reply-To: <50810EB8.3060801@citrix.com>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.16.3.132]
x-tm-as-product-ver: SMEX-10.2.0.2087-7.000.1014-19288.000
x-tm-as-result: No--60.495500-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH RFC] Persistent grant maps for xen blk
 drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> 
> On 19/10/12 03:34, James Harper wrote:
> >>
> >> This patch implements persistent grants for the xen-blk{front,back}
> >> mechanism. The effect of this change is to reduce the number of unmap
> >> operations performed, since they cause a (costly) TLB shootdown. This
> >> allows the I/O performance to scale better when a large number of VMs
> >> are performing I/O.
> >>
> >> Previously, the blkfront driver was supplied a bvec[] from the
> >> request queue. This was granted to dom0; dom0 performed the I/O and
> >> wrote directly into the grant-mapped memory and unmapped it; blkfront
> >> then removed foreign access for that grant. The cost of unmapping
> >> scales badly with the number of CPUs in Dom0. An experiment showed
> >> that when
> >> Dom0 has 24 VCPUs, and guests are performing parallel I/O to a
> >> ramdisk, the IPIs from performing unmap's is a bottleneck at 5 guests
> >> (at which point
> >> 650,000 IOPS are being performed in total). If more than 5 guests are
> >> used, the performance declines. By 10 guests, only
> >> 400,000 IOPS are being performed.
> >>
> >> This patch improves performance by only unmapping when the
> connection
> >> between blkfront and back is broken.
> >
> > I assume network drivers would suffer from the same affliction... Would a
> more general persistent map solution be worth considering (or be possible)?
> So a common interface to this persistent mapping allowing the persistent
> pool to be shared between all drivers in the DomU?
> 
> Yes, there are plans to implement the same for network drivers. I would
> generally avoid having a shared pool of grants for all the devices of a DomU,
> as said in the description of the patch:
> 
> Blkback stores a mapping of grefs=>{page mapped to by gref} in a red-black
> tree. As the grefs are not known apriori, and provide no guarantees on their
> ordering, we have to perform a search through this tree to find the page, for
> every gref we receive. This operation takes O(log n) time in the worst case.
> 
> Having a shared pool with all grants would mean that n will become much
> higher, and so the search time for a grant would increase.

I'm asking because I vaguely started a similar project a while back, but didn't get much further than investigating data structures. I had something like the following:

. redefined gref so that high bit indicates a persistent mapping (on the basis that no DomU is ever going to have >2^31 grants). High bit set indicates a persistent grant which is handled differently.

. New hypercall mem-op's to allocate/deallocate a persistent grant, returning a handle from Dom0 (with high bit set). Dom0 maintains a table of mapped grants with the handle being the index. Ref counting tracks usage so that an unmap won't be allowed when ref>0. I was taking the approach that a chunk of persistent grants would be allocated at boot time and so the actual map/unmap is not done often so the requirement of a hypercall wasn't a big deal. I hadn't figured out how to manage the size of this table yet.

. Mapping a gref with the high bit set in Dom0 becomes a lookup into the persistent table and a ref++ rather than an actual mapping operation. Unmapping becomes a ref--.

> Also, if the pool is
> shared some kind of concurrency control should be added, which will make it
> even slower.
> 

Yes, but I think I only needed to worry about that for the actual alloc/dealloc of the persistent map entry which would be an infrequent event. As I said, I never got much further than the above concept so I hadn't fully explored that - at the time I was chasing an imaginary problem with grant tables which turned out to be freelist contention in DomU.

James


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 10:47:28 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 10:47:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPA6f-0008GC-Nm; Fri, 19 Oct 2012 10:47:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPA6d-0008G6-T4
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 10:47:08 +0000
Received: from [85.158.139.211:21979] by server-10.bemta-5.messagelabs.com id
	2C/FA-01025-BAF21805; Fri, 19 Oct 2012 10:47:07 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-5.tower-206.messagelabs.com!1350643622!22906504!1
X-Originating-IP: [203.16.224.4]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7491 invoked from network); 19 Oct 2012 10:47:05 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-5.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	19 Oct 2012 10:47:05 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp1.bendigoit.com.au with esmtp (Exim 4.69)
	(envelope-from )
	id 1TPA6T-0007Ie-Bx; Fri, 19 Oct 2012 21:46:57 +1100
Received: from BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d]) by
	BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d%12]) with mapi id
	14.01.0421.002; Fri, 19 Oct 2012 21:46:57 +1100
From: James Harper 
To: =?iso-8859-1?Q?Roger_Pau_Monn=E9?= 
Thread-Topic: [Xen-devel] [PATCH RFC] Persistent grant maps for xen blk drivers
Thread-Index: AQHNrSPHQ3cOVHsv2Ui1q3f+GnpWRpe+90QggACc8ACAANDKAA==
Date: Fri, 19 Oct 2012 10:46:56 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B32C11932@BITCOM1.int.sbss.com.au>
References: <1350559321-19066-1-git-send-email-roger.pau@citrix.com>
	<6035A0D088A63A46850C3988ED045A4B32C1043A@BITCOM1.int.sbss.com.au>
	<50810EB8.3060801@citrix.com>
In-Reply-To: <50810EB8.3060801@citrix.com>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.16.3.132]
x-tm-as-product-ver: SMEX-10.2.0.2087-7.000.1014-19288.000
x-tm-as-result: No--60.495500-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH RFC] Persistent grant maps for xen blk
 drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> 
> On 19/10/12 03:34, James Harper wrote:
> >>
> >> This patch implements persistent grants for the xen-blk{front,back}
> >> mechanism. The effect of this change is to reduce the number of unmap
> >> operations performed, since they cause a (costly) TLB shootdown. This
> >> allows the I/O performance to scale better when a large number of VMs
> >> are performing I/O.
> >>
> >> Previously, the blkfront driver was supplied a bvec[] from the
> >> request queue. This was granted to dom0; dom0 performed the I/O and
> >> wrote directly into the grant-mapped memory and unmapped it; blkfront
> >> then removed foreign access for that grant. The cost of unmapping
> >> scales badly with the number of CPUs in Dom0. An experiment showed
> >> that when
> >> Dom0 has 24 VCPUs, and guests are performing parallel I/O to a
> >> ramdisk, the IPIs from performing unmap's is a bottleneck at 5 guests
> >> (at which point
> >> 650,000 IOPS are being performed in total). If more than 5 guests are
> >> used, the performance declines. By 10 guests, only
> >> 400,000 IOPS are being performed.
> >>
> >> This patch improves performance by only unmapping when the
> connection
> >> between blkfront and back is broken.
> >
> > I assume network drivers would suffer from the same affliction... Would a
> more general persistent map solution be worth considering (or be possible)?
> So a common interface to this persistent mapping allowing the persistent
> pool to be shared between all drivers in the DomU?
> 
> Yes, there are plans to implement the same for network drivers. I would
> generally avoid having a shared pool of grants for all the devices of a DomU,
> as said in the description of the patch:
> 
> Blkback stores a mapping of grefs=>{page mapped to by gref} in a red-black
> tree. As the grefs are not known apriori, and provide no guarantees on their
> ordering, we have to perform a search through this tree to find the page, for
> every gref we receive. This operation takes O(log n) time in the worst case.
> 
> Having a shared pool with all grants would mean that n will become much
> higher, and so the search time for a grant would increase.

I'm asking because I vaguely started a similar project a while back, but didn't get much further than investigating data structures. I had something like the following:

. redefined gref so that high bit indicates a persistent mapping (on the basis that no DomU is ever going to have >2^31 grants). High bit set indicates a persistent grant which is handled differently.

. New hypercall mem-op's to allocate/deallocate a persistent grant, returning a handle from Dom0 (with high bit set). Dom0 maintains a table of mapped grants with the handle being the index. Ref counting tracks usage so that an unmap won't be allowed when ref>0. I was taking the approach that a chunk of persistent grants would be allocated at boot time and so the actual map/unmap is not done often so the requirement of a hypercall wasn't a big deal. I hadn't figured out how to manage the size of this table yet.

. Mapping a gref with the high bit set in Dom0 becomes a lookup into the persistent table and a ref++ rather than an actual mapping operation. Unmapping becomes a ref--.

> Also, if the pool is
> shared some kind of concurrency control should be added, which will make it
> even slower.
> 

Yes, but I think I only needed to worry about that for the actual alloc/dealloc of the persistent map entry which would be an infrequent event. As I said, I never got much further than the above concept so I hadn't fully explored that - at the time I was chasing an imaginary problem with grant tables which turned out to be freelist contention in DomU.

James


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 10:55:03 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 10:55:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPAE3-0008Pl-OJ; Fri, 19 Oct 2012 10:54:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPAE2-0008Pa-Ov
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 10:54:46 +0000
Received: from [85.158.137.99:39638] by server-13.bemta-3.messagelabs.com id
	03/31-26794-67131805; Fri, 19 Oct 2012 10:54:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1350644085!22115127!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUwMDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22888 invoked from network); 19 Oct 2012 10:54:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 10:54:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,612,1344211200"; d="scan'208";a="15273624"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 10:54:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 19 Oct 2012 11:54:06 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TPADO-000786-Ix; Fri, 19 Oct 2012 10:54:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TPADO-0001dD-Ev;
	Fri, 19 Oct 2012 11:54:06 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20609.12622.366009.448395@mariner.uk.xensource.com>
Date: Fri, 19 Oct 2012 11:54:06 +0100
To: Ian Campbell 
In-Reply-To: 
References: 
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] libxl: Use libxl__realloc in a couple of
 places in libxl_events.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[PATCH] libxl: Use libxl__realloc in a couple of places in libxl_events.c"):
> libxl: Use libxl__realloc in a couple of places in libxl_events.c
> 
> This avoids us having to think about the error handling on failure.

As far as it goes,

Acked-by: Ian Jackson 

But...

> Signed-off-by: Ian Campbell 
> 
> diff -r 33487389f7f2 -r fd0989ae4407 tools/libxl/libxl_event.c
> --- a/tools/libxl/libxl_event.c	Tue Oct 16 16:45:43 2012 +0100
> +++ b/tools/libxl/libxl_event.c	Tue Oct 16 16:46:18 2012 +0100
> @@ -489,7 +489,8 @@ int libxl__ev_xswatch_register(libxl__gc
>          int newarraysize = (CTX->watch_nslots + 1) << 2;
>          int i;
>          libxl__ev_watch_slot *newarray =
> -            realloc(CTX->watch_slots, sizeof(*newarray) * newarraysize);
> +            libxl__realloc(NOGC,
> +                           CTX->watch_slots, sizeof(*newarray) * newarraysize);
>          if (!newarray) goto out_nomem;

So did you want to remove the error exits then too ?

> -            realloc(poller->fd_polls, sizeof(*newarray) * nfds);
> +            libxl__realloc(NOGC, poller->fd_polls, sizeof(*newarray) * nfds);
>  
>          if (!newarray) { rc = ERROR_NOMEM; goto out; }

And here.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 10:55:03 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 10:55:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPAE3-0008Pl-OJ; Fri, 19 Oct 2012 10:54:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPAE2-0008Pa-Ov
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 10:54:46 +0000
Received: from [85.158.137.99:39638] by server-13.bemta-3.messagelabs.com id
	03/31-26794-67131805; Fri, 19 Oct 2012 10:54:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1350644085!22115127!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUwMDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22888 invoked from network); 19 Oct 2012 10:54:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 10:54:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,612,1344211200"; d="scan'208";a="15273624"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 10:54:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 19 Oct 2012 11:54:06 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TPADO-000786-Ix; Fri, 19 Oct 2012 10:54:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TPADO-0001dD-Ev;
	Fri, 19 Oct 2012 11:54:06 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20609.12622.366009.448395@mariner.uk.xensource.com>
Date: Fri, 19 Oct 2012 11:54:06 +0100
To: Ian Campbell 
In-Reply-To: 
References: 
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] libxl: Use libxl__realloc in a couple of
 places in libxl_events.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[PATCH] libxl: Use libxl__realloc in a couple of places in libxl_events.c"):
> libxl: Use libxl__realloc in a couple of places in libxl_events.c
> 
> This avoids us having to think about the error handling on failure.

As far as it goes,

Acked-by: Ian Jackson 

But...

> Signed-off-by: Ian Campbell 
> 
> diff -r 33487389f7f2 -r fd0989ae4407 tools/libxl/libxl_event.c
> --- a/tools/libxl/libxl_event.c	Tue Oct 16 16:45:43 2012 +0100
> +++ b/tools/libxl/libxl_event.c	Tue Oct 16 16:46:18 2012 +0100
> @@ -489,7 +489,8 @@ int libxl__ev_xswatch_register(libxl__gc
>          int newarraysize = (CTX->watch_nslots + 1) << 2;
>          int i;
>          libxl__ev_watch_slot *newarray =
> -            realloc(CTX->watch_slots, sizeof(*newarray) * newarraysize);
> +            libxl__realloc(NOGC,
> +                           CTX->watch_slots, sizeof(*newarray) * newarraysize);
>          if (!newarray) goto out_nomem;

So did you want to remove the error exits then too ?

> -            realloc(poller->fd_polls, sizeof(*newarray) * nfds);
> +            libxl__realloc(NOGC, poller->fd_polls, sizeof(*newarray) * nfds);
>  
>          if (!newarray) { rc = ERROR_NOMEM; goto out; }

And here.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 10:55:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 10:55:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPAE4-0008Pv-3U; Fri, 19 Oct 2012 10:54:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPAE2-0008Pb-Tv
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 10:54:47 +0000
Received: from [85.158.137.99:29008] by server-9.bemta-3.messagelabs.com id
	E4/2C-16841-67131805; Fri, 19 Oct 2012 10:54:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1350644085!22115127!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUwMDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22910 invoked from network); 19 Oct 2012 10:54:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 10:54:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,612,1344211200"; d="scan'208";a="15273627"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 10:54:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 19 Oct 2012 11:54:26 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TPADh-00078F-UN; Fri, 19 Oct 2012 10:54:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TPADh-0001dH-Q4;
	Fri, 19 Oct 2012 11:54:25 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20609.12641.710380.815515@mariner.uk.xensource.com>
Date: Fri, 19 Oct 2012 11:54:25 +0100
To: Ian Campbell 
In-Reply-To: 
References: 
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] xl: Do not leak events when a domain exits
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[PATCH] xl: Do not leak events when a domain exits"):
> xl: Do not leak events when a domain exits.

Acked-by: Ian Jackson 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 10:55:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 10:55:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPAE4-0008Pv-3U; Fri, 19 Oct 2012 10:54:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPAE2-0008Pb-Tv
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 10:54:47 +0000
Received: from [85.158.137.99:29008] by server-9.bemta-3.messagelabs.com id
	E4/2C-16841-67131805; Fri, 19 Oct 2012 10:54:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1350644085!22115127!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUwMDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22910 invoked from network); 19 Oct 2012 10:54:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 10:54:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,612,1344211200"; d="scan'208";a="15273627"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 10:54:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 19 Oct 2012 11:54:26 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TPADh-00078F-UN; Fri, 19 Oct 2012 10:54:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TPADh-0001dH-Q4;
	Fri, 19 Oct 2012 11:54:25 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20609.12641.710380.815515@mariner.uk.xensource.com>
Date: Fri, 19 Oct 2012 11:54:25 +0100
To: Ian Campbell 
In-Reply-To: 
References: 
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] xl: Do not leak events when a domain exits
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[PATCH] xl: Do not leak events when a domain exits"):
> xl: Do not leak events when a domain exits.

Acked-by: Ian Jackson 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 10:56:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 10:56:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPAFC-00007k-PK; Fri, 19 Oct 2012 10:55:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPAFB-00007U-5r
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 10:55:57 +0000
Received: from [193.109.254.147:15391] by server-7.bemta-14.messagelabs.com id
	B1/B8-24122-CB131805; Fri, 19 Oct 2012 10:55:56 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1350644154!5979141!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzc3ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13835 invoked from network); 19 Oct 2012 10:55:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 10:55:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,612,1344211200"; d="scan'208";a="41806384"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 10:55:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 19 Oct 2012 06:55:53 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TPAF7-0006Wj-8B;
	Fri, 19 Oct 2012 11:55:53 +0100
Message-ID: <5081308E.4000004@eu.citrix.com>
Date: Fri, 19 Oct 2012 11:50:54 +0100
From: George Dunlap 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: Dario Faggioli 
References: 
	
	
	<1350602433.26152.106.camel@Solace>
In-Reply-To: <1350602433.26152.106.camel@Solace>
Cc: Andre Przywara ,
	Ian Campbell ,
	Stefano Stabellini ,
	Juergen Gross ,
	Ian Jackson ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 1 of 3] libxl: take node distances into
 account during NUMA placement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 19/10/12 00:20, Dario Faggioli wrote:
> On Thu, 2012-10-18 at 16:17 +0100, George Dunlap wrote:
>> On Tue, Oct 16, 2012 at 6:26 PM, Dario Faggioli
>>  wrote:
>>> In fact, among placement candidates with the same number of nodes, the
>>> closer the various nodes are to each others, the better the performances
>>> for a domain placed there.
>> Looks good overall -- my only worry is the N^2 nature of the
>> algorithm.  We're already doing some big combinatorial thing to
>> generate the candidates, right?
>>
> It is, with N being the number of nodes, which we discussed thoroughly
> already a couple of months ago, and reached consensus on the fact that N
> will stay less than 8 for the next 5 (but probably even more) years. :-)
>
> In any case, if something really unexpected happens, and N jumps to
> anything bigger than 16, the placement algorithm won't even start, and
> we'll never reach this point!.

Ah, right -- Yes, I think the "safety valve" was the thing I wanted to 
have in place.

In that case:

Acked-by: George Dunlap 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 10:56:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 10:56:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPAFC-00007k-PK; Fri, 19 Oct 2012 10:55:58 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPAFB-00007U-5r
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 10:55:57 +0000
Received: from [193.109.254.147:15391] by server-7.bemta-14.messagelabs.com id
	B1/B8-24122-CB131805; Fri, 19 Oct 2012 10:55:56 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1350644154!5979141!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzc3ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13835 invoked from network); 19 Oct 2012 10:55:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 10:55:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,612,1344211200"; d="scan'208";a="41806384"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 10:55:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 19 Oct 2012 06:55:53 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TPAF7-0006Wj-8B;
	Fri, 19 Oct 2012 11:55:53 +0100
Message-ID: <5081308E.4000004@eu.citrix.com>
Date: Fri, 19 Oct 2012 11:50:54 +0100
From: George Dunlap 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: Dario Faggioli 
References: 
	
	
	<1350602433.26152.106.camel@Solace>
In-Reply-To: <1350602433.26152.106.camel@Solace>
Cc: Andre Przywara ,
	Ian Campbell ,
	Stefano Stabellini ,
	Juergen Gross ,
	Ian Jackson ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 1 of 3] libxl: take node distances into
 account during NUMA placement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 19/10/12 00:20, Dario Faggioli wrote:
> On Thu, 2012-10-18 at 16:17 +0100, George Dunlap wrote:
>> On Tue, Oct 16, 2012 at 6:26 PM, Dario Faggioli
>>  wrote:
>>> In fact, among placement candidates with the same number of nodes, the
>>> closer the various nodes are to each others, the better the performances
>>> for a domain placed there.
>> Looks good overall -- my only worry is the N^2 nature of the
>> algorithm.  We're already doing some big combinatorial thing to
>> generate the candidates, right?
>>
> It is, with N being the number of nodes, which we discussed thoroughly
> already a couple of months ago, and reached consensus on the fact that N
> will stay less than 8 for the next 5 (but probably even more) years. :-)
>
> In any case, if something really unexpected happens, and N jumps to
> anything bigger than 16, the placement algorithm won't even start, and
> we'll never reach this point!.

Ah, right -- Yes, I think the "safety valve" was the thing I wanted to 
have in place.

In that case:

Acked-by: George Dunlap 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 10:56:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 10:56:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPAFZ-0000Ab-5y; Fri, 19 Oct 2012 10:56:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPAFX-0000AK-P9
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 10:56:19 +0000
Received: from [193.109.254.147:25342] by server-4.bemta-14.messagelabs.com id
	F6/EB-04248-3D131805; Fri, 19 Oct 2012 10:56:19 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1350644169!3433935!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUwMDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23461 invoked from network); 19 Oct 2012 10:56:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 10:56:10 -0000
X-IronPort-AV: E=Sophos;i="4.80,612,1344211200"; 
	d="asc'?scan'208";a="15273684"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 10:56:09 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 19 Oct 2012 11:56:09 +0100
Message-ID: <1350644168.6053.15.camel@Solace>
From: Dario Faggioli 
To: Stefano Stabellini 
Date: Fri, 19 Oct 2012 12:56:08 +0200
In-Reply-To: 
References: 
	
	
	<1350602433.26152.106.camel@Solace>
	<20609.9598.286219.485359@mariner.uk.xensource.com>
	
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Andre Przywara , Ian
	Campbell ,
	George Dunlap ,
	Juergen Gross ,
	Ian Jackson ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 1 of 3] libxl: take node distances into
 account during NUMA placement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============8168972353356251796=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8168972353356251796==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-U+ShO+wra6Cot9Xg8jqD"

--=-U+ShO+wra6Cot9Xg8jqD
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-10-19 at 11:39 +0100, Stefano Stabellini wrote:
> On Fri, 19 Oct 2012, Ian Jackson wrote:
> > Dario Faggioli writes ("Re: [Xen-devel] [PATCH 1 of 3] libxl: take node=
 distances into account during NUMA placement"):
> > > It is, with N being the number of nodes, which we discussed thoroughl=
y
> > > already a couple of months ago, and reached consensus on the fact tha=
t N
> > > will stay less than 8 for the next 5 (but probably even more) years. =
:-)
> >=20
> > No, I don't think we did reach consensus about that.  It was asserted
> > but I dissented.  I don't think this is a reasonable assumption.
>=20
> When Dario speaks about consensus in terms of hardware that is going to
> reach the market, he really means what Intel and AMD have told us.
>=20
Indeed.

That being said, I really wanted to avoid re-starting that discussion
so, while trying to summarize it as quickly as possible, I've no problem
admitting that "reach consensus" could not be the perfect choice of
words. My bad.

The whole point is that the solution we have (and that I'm trying to
keep up improving with these patches) is both viable with current and
near future hardware and no harms with any crazy unexpectable
breakthrough in CPU design --thanks to the safety catch IanJ suggested.=20

Moreover, it is easily amendable, for example taking more advantage of
cpupools (with witch the placement algorithm is already integrated up to
some extent), in case the latter happens.
This is so true that, as I already said, I've no problem even starting
to think about how to put it together. Maybe not from tomorrow (I'm
quite busy with other stuff :-D), but definitely before 4.3, if we think
it's something we couldn't live without.

> Sorry but your opinion doesn't count that much in the matter of cpu
> architecture being produces in the near future, unless you have already
> started a secret Californian cpu startup, that nobody knows about yet
> ;-)
>
:-D

Regards,
Dario

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-U+ShO+wra6Cot9Xg8jqD
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlCBMcgACgkQk4XaBE3IOsS7cwCfTXPRjcQ0PevaLVUS5CbGZ5tw
7XQAn1pClT8F9Y6VN1yUaRyNoAT04fWC
=a2vp
-----END PGP SIGNATURE-----

--=-U+ShO+wra6Cot9Xg8jqD--


--===============8168972353356251796==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8168972353356251796==--


From xen-devel-bounces@lists.xen.org Fri Oct 19 10:56:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 10:56:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPAFZ-0000Ab-5y; Fri, 19 Oct 2012 10:56:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPAFX-0000AK-P9
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 10:56:19 +0000
Received: from [193.109.254.147:25342] by server-4.bemta-14.messagelabs.com id
	F6/EB-04248-3D131805; Fri, 19 Oct 2012 10:56:19 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1350644169!3433935!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUwMDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23461 invoked from network); 19 Oct 2012 10:56:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 10:56:10 -0000
X-IronPort-AV: E=Sophos;i="4.80,612,1344211200"; 
	d="asc'?scan'208";a="15273684"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 10:56:09 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 19 Oct 2012 11:56:09 +0100
Message-ID: <1350644168.6053.15.camel@Solace>
From: Dario Faggioli 
To: Stefano Stabellini 
Date: Fri, 19 Oct 2012 12:56:08 +0200
In-Reply-To: 
References: 
	
	
	<1350602433.26152.106.camel@Solace>
	<20609.9598.286219.485359@mariner.uk.xensource.com>
	
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Andre Przywara , Ian
	Campbell ,
	George Dunlap ,
	Juergen Gross ,
	Ian Jackson ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 1 of 3] libxl: take node distances into
 account during NUMA placement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============8168972353356251796=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8168972353356251796==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-U+ShO+wra6Cot9Xg8jqD"

--=-U+ShO+wra6Cot9Xg8jqD
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-10-19 at 11:39 +0100, Stefano Stabellini wrote:
> On Fri, 19 Oct 2012, Ian Jackson wrote:
> > Dario Faggioli writes ("Re: [Xen-devel] [PATCH 1 of 3] libxl: take node=
 distances into account during NUMA placement"):
> > > It is, with N being the number of nodes, which we discussed thoroughl=
y
> > > already a couple of months ago, and reached consensus on the fact tha=
t N
> > > will stay less than 8 for the next 5 (but probably even more) years. =
:-)
> >=20
> > No, I don't think we did reach consensus about that.  It was asserted
> > but I dissented.  I don't think this is a reasonable assumption.
>=20
> When Dario speaks about consensus in terms of hardware that is going to
> reach the market, he really means what Intel and AMD have told us.
>=20
Indeed.

That being said, I really wanted to avoid re-starting that discussion
so, while trying to summarize it as quickly as possible, I've no problem
admitting that "reach consensus" could not be the perfect choice of
words. My bad.

The whole point is that the solution we have (and that I'm trying to
keep up improving with these patches) is both viable with current and
near future hardware and no harms with any crazy unexpectable
breakthrough in CPU design --thanks to the safety catch IanJ suggested.=20

Moreover, it is easily amendable, for example taking more advantage of
cpupools (with witch the placement algorithm is already integrated up to
some extent), in case the latter happens.
This is so true that, as I already said, I've no problem even starting
to think about how to put it together. Maybe not from tomorrow (I'm
quite busy with other stuff :-D), but definitely before 4.3, if we think
it's something we couldn't live without.

> Sorry but your opinion doesn't count that much in the matter of cpu
> architecture being produces in the near future, unless you have already
> started a secret Californian cpu startup, that nobody knows about yet
> ;-)
>
:-D

Regards,
Dario

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-U+ShO+wra6Cot9Xg8jqD
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlCBMcgACgkQk4XaBE3IOsS7cwCfTXPRjcQ0PevaLVUS5CbGZ5tw
7XQAn1pClT8F9Y6VN1yUaRyNoAT04fWC
=a2vp
-----END PGP SIGNATURE-----

--=-U+ShO+wra6Cot9Xg8jqD--


--===============8168972353356251796==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8168972353356251796==--


From xen-devel-bounces@lists.xen.org Fri Oct 19 11:00:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 11:00:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPAJb-0000ZL-1Z; Fri, 19 Oct 2012 11:00:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPAJZ-0000ZB-3q
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 11:00:29 +0000
Received: from [85.158.139.83:51663] by server-12.bemta-5.messagelabs.com id
	3A/10-26919-CC231805; Fri, 19 Oct 2012 11:00:28 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1350644427!32750780!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUwMDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13170 invoked from network); 19 Oct 2012 11:00:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 11:00:27 -0000
X-IronPort-AV: E=Sophos;i="4.80,612,1344211200"; 
	d="asc'?scan'208";a="15273793"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 11:00:27 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 19 Oct 2012 12:00:27 +0100
Message-ID: <1350644425.6053.17.camel@Solace>
From: Dario Faggioli 
To: George Dunlap 
Date: Fri, 19 Oct 2012 13:00:25 +0200
In-Reply-To: <5081308E.4000004@eu.citrix.com>
References: 
	
	
	<1350602433.26152.106.camel@Solace> <5081308E.4000004@eu.citrix.com>
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Andre Przywara , Ian
	Campbell ,
	Stefano Stabellini ,
	Juergen Gross ,
	Ian Jackson ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 1 of 3] libxl: take node distances into
 account during NUMA placement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0296818313177177610=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0296818313177177610==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-gToits8Ttto7tCRijljg"

--=-gToits8Ttto7tCRijljg
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-10-19 at 11:50 +0100, George Dunlap wrote:
> > In any case, if something really unexpected happens, and N jumps to
> > anything bigger than 16, the placement algorithm won't even start, and
> > we'll never reach this point!.
>=20
> Ah, right -- Yes, I think the "safety valve" was the thing I wanted to=
=20
> have in place.
>=20
Both you and Ian Jackson, yes. :-)

> In that case:
>=20
> Acked-by: George Dunlap 
>=20
Cool. I'll add you're Acks and respin. :-)

Thanks and Regards,
Dario

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-gToits8Ttto7tCRijljg
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlCBMskACgkQk4XaBE3IOsS/lwCfZI7uJiHitPZbb9pon5/0rdhK
V4QAnjkgt362kv4yNbxZ4rHhn8eLmmn6
=nL7F
-----END PGP SIGNATURE-----

--=-gToits8Ttto7tCRijljg--


--===============0296818313177177610==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0296818313177177610==--


From xen-devel-bounces@lists.xen.org Fri Oct 19 11:00:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 11:00:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPAJb-0000ZL-1Z; Fri, 19 Oct 2012 11:00:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPAJZ-0000ZB-3q
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 11:00:29 +0000
Received: from [85.158.139.83:51663] by server-12.bemta-5.messagelabs.com id
	3A/10-26919-CC231805; Fri, 19 Oct 2012 11:00:28 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1350644427!32750780!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUwMDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13170 invoked from network); 19 Oct 2012 11:00:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 11:00:27 -0000
X-IronPort-AV: E=Sophos;i="4.80,612,1344211200"; 
	d="asc'?scan'208";a="15273793"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 11:00:27 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 19 Oct 2012 12:00:27 +0100
Message-ID: <1350644425.6053.17.camel@Solace>
From: Dario Faggioli 
To: George Dunlap 
Date: Fri, 19 Oct 2012 13:00:25 +0200
In-Reply-To: <5081308E.4000004@eu.citrix.com>
References: 
	
	
	<1350602433.26152.106.camel@Solace> <5081308E.4000004@eu.citrix.com>
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Andre Przywara , Ian
	Campbell ,
	Stefano Stabellini ,
	Juergen Gross ,
	Ian Jackson ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 1 of 3] libxl: take node distances into
 account during NUMA placement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0296818313177177610=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0296818313177177610==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-gToits8Ttto7tCRijljg"

--=-gToits8Ttto7tCRijljg
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-10-19 at 11:50 +0100, George Dunlap wrote:
> > In any case, if something really unexpected happens, and N jumps to
> > anything bigger than 16, the placement algorithm won't even start, and
> > we'll never reach this point!.
>=20
> Ah, right -- Yes, I think the "safety valve" was the thing I wanted to=
=20
> have in place.
>=20
Both you and Ian Jackson, yes. :-)

> In that case:
>=20
> Acked-by: George Dunlap 
>=20
Cool. I'll add you're Acks and respin. :-)

Thanks and Regards,
Dario

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-gToits8Ttto7tCRijljg
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlCBMskACgkQk4XaBE3IOsS/lwCfZI7uJiHitPZbb9pon5/0rdhK
V4QAnjkgt362kv4yNbxZ4rHhn8eLmmn6
=nL7F
-----END PGP SIGNATURE-----

--=-gToits8Ttto7tCRijljg--


--===============0296818313177177610==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0296818313177177610==--


From xen-devel-bounces@lists.xen.org Fri Oct 19 11:20:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 11:20:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPAcZ-0000sA-6E; Fri, 19 Oct 2012 11:20:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPAcX-0000s5-Ue
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 11:20:06 +0000
Received: from [85.158.143.35:63580] by server-2.bemta-4.messagelabs.com id
	50/AD-22268-56731805; Fri, 19 Oct 2012 11:20:05 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-11.tower-21.messagelabs.com!1350645561!11470701!1
X-Originating-IP: [203.16.207.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7441 invoked from network); 19 Oct 2012 11:19:24 -0000
Received: from mail.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-11.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	19 Oct 2012 11:19:24 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp2.bendigoit.com.au with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPAbl-0002Ff-JY; Fri, 19 Oct 2012 22:19:17 +1100
Received: from BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d]) by
	BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d%12]) with mapi id
	14.01.0421.002; Fri, 19 Oct 2012 22:19:17 +1100
From: James Harper 
To: James Harper ,
	=?iso-8859-1?Q?Roger_Pau_Monn=E9?= 
Thread-Topic: [Xen-devel] [PATCH RFC] Persistent grant maps for xen blk drivers
Thread-Index: AQHNrSPHQ3cOVHsv2Ui1q3f+GnpWRpe+90QggACc8ACAANDKAIAAF3AA
Date: Fri, 19 Oct 2012 11:19:16 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B32C11A59@BITCOM1.int.sbss.com.au>
References: <1350559321-19066-1-git-send-email-roger.pau@citrix.com>
	<6035A0D088A63A46850C3988ED045A4B32C1043A@BITCOM1.int.sbss.com.au>
	<50810EB8.3060801@citrix.com>
	<6035A0D088A63A46850C3988ED045A4B32C11932@BITCOM1.int.sbss.com.au>
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B32C11932@BITCOM1.int.sbss.com.au>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.16.3.132]
x-tm-as-product-ver: SMEX-10.2.0.2087-7.000.1014-19288.001
x-tm-as-result: No--29.134600-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH RFC] Persistent grant maps for xen blk
 drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> 
> . New hypercall mem-op's to allocate/deallocate a persistent grant, returning
> a handle from Dom0 (with high bit set). Dom0 maintains a table of mapped
> grants with the handle being the index. Ref counting tracks usage so that an
> unmap won't be allowed when ref>0. I was taking the approach that a chunk
> of persistent grants would be allocated at boot time and so the actual
> map/unmap is not done often so the requirement of a hypercall wasn't a big
> deal. I hadn't figured out how to manage the size of this table yet.
> 

Actually it was this bit that I didn't progress any further... the hypercall wouldn't do the job as Dom0 needed to get the message which would really need yet another shared ring which meant yet more complexity.

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 11:20:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 11:20:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPAcZ-0000sA-6E; Fri, 19 Oct 2012 11:20:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPAcX-0000s5-Ue
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 11:20:06 +0000
Received: from [85.158.143.35:63580] by server-2.bemta-4.messagelabs.com id
	50/AD-22268-56731805; Fri, 19 Oct 2012 11:20:05 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-11.tower-21.messagelabs.com!1350645561!11470701!1
X-Originating-IP: [203.16.207.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7441 invoked from network); 19 Oct 2012 11:19:24 -0000
Received: from mail.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-11.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	19 Oct 2012 11:19:24 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp2.bendigoit.com.au with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPAbl-0002Ff-JY; Fri, 19 Oct 2012 22:19:17 +1100
Received: from BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d]) by
	BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d%12]) with mapi id
	14.01.0421.002; Fri, 19 Oct 2012 22:19:17 +1100
From: James Harper 
To: James Harper ,
	=?iso-8859-1?Q?Roger_Pau_Monn=E9?= 
Thread-Topic: [Xen-devel] [PATCH RFC] Persistent grant maps for xen blk drivers
Thread-Index: AQHNrSPHQ3cOVHsv2Ui1q3f+GnpWRpe+90QggACc8ACAANDKAIAAF3AA
Date: Fri, 19 Oct 2012 11:19:16 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B32C11A59@BITCOM1.int.sbss.com.au>
References: <1350559321-19066-1-git-send-email-roger.pau@citrix.com>
	<6035A0D088A63A46850C3988ED045A4B32C1043A@BITCOM1.int.sbss.com.au>
	<50810EB8.3060801@citrix.com>
	<6035A0D088A63A46850C3988ED045A4B32C11932@BITCOM1.int.sbss.com.au>
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B32C11932@BITCOM1.int.sbss.com.au>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.16.3.132]
x-tm-as-product-ver: SMEX-10.2.0.2087-7.000.1014-19288.001
x-tm-as-result: No--29.134600-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH RFC] Persistent grant maps for xen blk
 drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> 
> . New hypercall mem-op's to allocate/deallocate a persistent grant, returning
> a handle from Dom0 (with high bit set). Dom0 maintains a table of mapped
> grants with the handle being the index. Ref counting tracks usage so that an
> unmap won't be allowed when ref>0. I was taking the approach that a chunk
> of persistent grants would be allocated at boot time and so the actual
> map/unmap is not done often so the requirement of a hypercall wasn't a big
> deal. I hadn't figured out how to manage the size of this table yet.
> 

Actually it was this bit that I didn't progress any further... the hypercall wouldn't do the job as Dom0 needed to get the message which would really need yet another shared ring which meant yet more complexity.

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 11:29:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 11:29:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPAl0-00011U-MN; Fri, 19 Oct 2012 11:28:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPAkz-00011P-AL
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 11:28:49 +0000
Received: from [85.158.139.211:48518] by server-6.bemta-5.messagelabs.com id
	CD/BB-32589-07931805; Fri, 19 Oct 2012 11:28:48 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1350646127!22913094!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUwMDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31994 invoked from network); 19 Oct 2012 11:28:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 11:28:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,612,1344211200"; d="scan'208";a="15274399"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 11:28:47 +0000
Received: from [192.168.1.30] (10.31.3.231) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 19 Oct 2012 12:28:47 +0100
Message-ID: <5081396E.4040409@citrix.com>
Date: Fri, 19 Oct 2012 13:28:46 +0200
From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: James Harper 
References: <1350559321-19066-1-git-send-email-roger.pau@citrix.com>
	<6035A0D088A63A46850C3988ED045A4B32C1043A@BITCOM1.int.sbss.com.au>
	<50810EB8.3060801@citrix.com>
	<6035A0D088A63A46850C3988ED045A4B32C11932@BITCOM1.int.sbss.com.au>
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B32C11932@BITCOM1.int.sbss.com.au>
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH RFC] Persistent grant maps for xen blk
	drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 19/10/12 12:46, James Harper wrote:
>>
>> On 19/10/12 03:34, James Harper wrote:
>>>>
>>>> This patch implements persistent grants for the xen-blk{front,back}
>>>> mechanism. The effect of this change is to reduce the number of unmap
>>>> operations performed, since they cause a (costly) TLB shootdown. This
>>>> allows the I/O performance to scale better when a large number of VMs
>>>> are performing I/O.
>>>>
>>>> Previously, the blkfront driver was supplied a bvec[] from the
>>>> request queue. This was granted to dom0; dom0 performed the I/O and
>>>> wrote directly into the grant-mapped memory and unmapped it; blkfront
>>>> then removed foreign access for that grant. The cost of unmapping
>>>> scales badly with the number of CPUs in Dom0. An experiment showed
>>>> that when
>>>> Dom0 has 24 VCPUs, and guests are performing parallel I/O to a
>>>> ramdisk, the IPIs from performing unmap's is a bottleneck at 5 guests
>>>> (at which point
>>>> 650,000 IOPS are being performed in total). If more than 5 guests are
>>>> used, the performance declines. By 10 guests, only
>>>> 400,000 IOPS are being performed.
>>>>
>>>> This patch improves performance by only unmapping when the
>> connection
>>>> between blkfront and back is broken.
>>>
>>> I assume network drivers would suffer from the same affliction... Would a
>> more general persistent map solution be worth considering (or be possible)?
>> So a common interface to this persistent mapping allowing the persistent
>> pool to be shared between all drivers in the DomU?
>>
>> Yes, there are plans to implement the same for network drivers. I would
>> generally avoid having a shared pool of grants for all the devices of a DomU,
>> as said in the description of the patch:
>>
>> Blkback stores a mapping of grefs=>{page mapped to by gref} in a red-black
>> tree. As the grefs are not known apriori, and provide no guarantees on their
>> ordering, we have to perform a search through this tree to find the page, for
>> every gref we receive. This operation takes O(log n) time in the worst case.
>>
>> Having a shared pool with all grants would mean that n will become much
>> higher, and so the search time for a grant would increase.
> 
> I'm asking because I vaguely started a similar project a while back, but didn't get much further than investigating data structures. I had something like the following:
> 
> . redefined gref so that high bit indicates a persistent mapping (on the basis that no DomU is ever going to have >2^31 grants). High bit set indicates a persistent grant which is handled differently.

I don't understand why you need to change the way to pass a gref
arround, this will break compatibility with non-persistent backends,
unless you negotiate the use of persistent grants before actually
starting the data tranfer, but if you do that you already know you are
using persistent grants, so there's no need to set any bit in the gref.

> . New hypercall mem-op's to allocate/deallocate a persistent grant, returning a handle from Dom0 (with high bit set). Dom0 maintains a table of mapped grants with the handle being the index. Ref counting tracks usage so that an unmap won't be allowed when ref>0. I was taking the approach that a chunk of persistent grants would be allocated at boot time and so the actual map/unmap is not done often so the requirement of a hypercall wasn't a big deal. I hadn't figured out how to manage the size of this table yet.

The so called persistent grants are no different from normal grants,
it's just that we agree in blk{front/back} that the same set of grants
will be used for all transations, there's no need to introduce any new
hypercalls, since they are just "regular" grants.

I agree that we could allocate them when initializing blkfront, but I
prefer to allocate them on request, since we won't probably use the
maximum number (RING_SIZE * SEGMENTS_PER_REQUEST).

> . Mapping a gref with the high bit set in Dom0 becomes a lookup into the persistent table and a ref++ rather than an actual mapping operation. Unmapping becomes a ref--.
>
>> Also, if the pool is
>> shared some kind of concurrency control should be added, which will make it
>> even slower.
>>
> 
> Yes, but I think I only needed to worry about that for the actual alloc/dealloc of the persistent map entry which would be an infrequent event. As I said, I never got much further than the above concept so I hadn't fully explored that - at the time I was chasing an imaginary problem with grant tables which turned out to be freelist contention in DomU.

As far as I can see (correct me if I'm wrong), you are proposing a
solution that involves changes to both the guests and the hypervisor
side, I think this introduces uncessary complexity to a problem that can
be solved by merely changing the way blk{front/back} behaves, without
requiring the hypervisor to know if we are using persistent grants or not.

> James
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 11:29:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 11:29:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPAl0-00011U-MN; Fri, 19 Oct 2012 11:28:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPAkz-00011P-AL
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 11:28:49 +0000
Received: from [85.158.139.211:48518] by server-6.bemta-5.messagelabs.com id
	CD/BB-32589-07931805; Fri, 19 Oct 2012 11:28:48 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1350646127!22913094!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUwMDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31994 invoked from network); 19 Oct 2012 11:28:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 11:28:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,612,1344211200"; d="scan'208";a="15274399"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 11:28:47 +0000
Received: from [192.168.1.30] (10.31.3.231) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 19 Oct 2012 12:28:47 +0100
Message-ID: <5081396E.4040409@citrix.com>
Date: Fri, 19 Oct 2012 13:28:46 +0200
From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: James Harper 
References: <1350559321-19066-1-git-send-email-roger.pau@citrix.com>
	<6035A0D088A63A46850C3988ED045A4B32C1043A@BITCOM1.int.sbss.com.au>
	<50810EB8.3060801@citrix.com>
	<6035A0D088A63A46850C3988ED045A4B32C11932@BITCOM1.int.sbss.com.au>
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B32C11932@BITCOM1.int.sbss.com.au>
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH RFC] Persistent grant maps for xen blk
	drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 19/10/12 12:46, James Harper wrote:
>>
>> On 19/10/12 03:34, James Harper wrote:
>>>>
>>>> This patch implements persistent grants for the xen-blk{front,back}
>>>> mechanism. The effect of this change is to reduce the number of unmap
>>>> operations performed, since they cause a (costly) TLB shootdown. This
>>>> allows the I/O performance to scale better when a large number of VMs
>>>> are performing I/O.
>>>>
>>>> Previously, the blkfront driver was supplied a bvec[] from the
>>>> request queue. This was granted to dom0; dom0 performed the I/O and
>>>> wrote directly into the grant-mapped memory and unmapped it; blkfront
>>>> then removed foreign access for that grant. The cost of unmapping
>>>> scales badly with the number of CPUs in Dom0. An experiment showed
>>>> that when
>>>> Dom0 has 24 VCPUs, and guests are performing parallel I/O to a
>>>> ramdisk, the IPIs from performing unmap's is a bottleneck at 5 guests
>>>> (at which point
>>>> 650,000 IOPS are being performed in total). If more than 5 guests are
>>>> used, the performance declines. By 10 guests, only
>>>> 400,000 IOPS are being performed.
>>>>
>>>> This patch improves performance by only unmapping when the
>> connection
>>>> between blkfront and back is broken.
>>>
>>> I assume network drivers would suffer from the same affliction... Would a
>> more general persistent map solution be worth considering (or be possible)?
>> So a common interface to this persistent mapping allowing the persistent
>> pool to be shared between all drivers in the DomU?
>>
>> Yes, there are plans to implement the same for network drivers. I would
>> generally avoid having a shared pool of grants for all the devices of a DomU,
>> as said in the description of the patch:
>>
>> Blkback stores a mapping of grefs=>{page mapped to by gref} in a red-black
>> tree. As the grefs are not known apriori, and provide no guarantees on their
>> ordering, we have to perform a search through this tree to find the page, for
>> every gref we receive. This operation takes O(log n) time in the worst case.
>>
>> Having a shared pool with all grants would mean that n will become much
>> higher, and so the search time for a grant would increase.
> 
> I'm asking because I vaguely started a similar project a while back, but didn't get much further than investigating data structures. I had something like the following:
> 
> . redefined gref so that high bit indicates a persistent mapping (on the basis that no DomU is ever going to have >2^31 grants). High bit set indicates a persistent grant which is handled differently.

I don't understand why you need to change the way to pass a gref
arround, this will break compatibility with non-persistent backends,
unless you negotiate the use of persistent grants before actually
starting the data tranfer, but if you do that you already know you are
using persistent grants, so there's no need to set any bit in the gref.

> . New hypercall mem-op's to allocate/deallocate a persistent grant, returning a handle from Dom0 (with high bit set). Dom0 maintains a table of mapped grants with the handle being the index. Ref counting tracks usage so that an unmap won't be allowed when ref>0. I was taking the approach that a chunk of persistent grants would be allocated at boot time and so the actual map/unmap is not done often so the requirement of a hypercall wasn't a big deal. I hadn't figured out how to manage the size of this table yet.

The so called persistent grants are no different from normal grants,
it's just that we agree in blk{front/back} that the same set of grants
will be used for all transations, there's no need to introduce any new
hypercalls, since they are just "regular" grants.

I agree that we could allocate them when initializing blkfront, but I
prefer to allocate them on request, since we won't probably use the
maximum number (RING_SIZE * SEGMENTS_PER_REQUEST).

> . Mapping a gref with the high bit set in Dom0 becomes a lookup into the persistent table and a ref++ rather than an actual mapping operation. Unmapping becomes a ref--.
>
>> Also, if the pool is
>> shared some kind of concurrency control should be added, which will make it
>> even slower.
>>
> 
> Yes, but I think I only needed to worry about that for the actual alloc/dealloc of the persistent map entry which would be an infrequent event. As I said, I never got much further than the above concept so I hadn't fully explored that - at the time I was chasing an imaginary problem with grant tables which turned out to be freelist contention in DomU.

As far as I can see (correct me if I'm wrong), you are proposing a
solution that involves changes to both the guests and the hypervisor
side, I think this introduces uncessary complexity to a problem that can
be solved by merely changing the way blk{front/back} behaves, without
requiring the hypervisor to know if we are using persistent grants or not.

> James
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 11:43:20 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 11:43:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPAyZ-0001Vt-NL; Fri, 19 Oct 2012 11:42:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPAyX-0001Vo-Ft
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 11:42:49 +0000
Received: from [85.158.139.211:13924] by server-8.bemta-5.messagelabs.com id
	30/68-23193-8BC31805; Fri, 19 Oct 2012 11:42:48 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1350646967!22915416!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17593 invoked from network); 19 Oct 2012 11:42:47 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 11:42:47 -0000
Received: by mail-bk0-f45.google.com with SMTP id jf3so169370bkc.32
	for ; Fri, 19 Oct 2012 04:42:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:to
	:subject:references:in-reply-to:content-type;
	bh=Nv8ULFGYv00kngQKFG+09Eu72SAk0BSf7LYXgxdH7b8=;
	b=OcNJZ//4iK4yAY7GIZSx0Q6YZhS8+auXgZk3AIHI4x5R3ciluy9vBMFPJPctMbn1Iq
	mmA0RuE4flyk1xk9AF+l2QZIGNGBvn3Icic5KV25ABugPjql1t9bd0/KBcLOfJzTqzj6
	CYQUxzooov/nl1sbymOEKJftC5tM0XGMWmQUL9GNrbQqCq5KD2rLktLCrcJbUcq0A0CZ
	y20i9ElsU4yaycOk31MTemmzYNnIEkplCi9xYS/PRRbT62U78WWlBA0YEMx0mVgL7w5a
	4ff/IwORyFEZIL01Cm5aWE6Hbs3QVelEmpf4uZr3t4ivyw7bMGL9GiGsGFyicjgbpM4Z
	8+zw==
Received: by 10.204.150.198 with SMTP id z6mr308045bkv.91.1350646967300;
	Fri, 19 Oct 2012 04:42:47 -0700 (PDT)
Received: from [172.16.26.11] ([46.233.68.235])
	by mx.google.com with ESMTPS id ht18sm794137bkc.14.2012.10.19.04.42.39
	(version=SSLv3 cipher=OTHER); Fri, 19 Oct 2012 04:42:46 -0700 (PDT)
Message-ID: <50813CAD.1040202@xen.org>
Date: Fri, 19 Oct 2012 12:42:37 +0100
From: Lars Kurth 
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <20608.15472.714307.754027@mariner.uk.xensource.com>
	<1350605228.5700.17.camel@Solace>
In-Reply-To: <1350605228.5700.17.camel@Solace>
Subject: Re: [Xen-devel] Xen.org automatic Xen test system, de-tentacled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: lars.kurth@xen.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============7799598688880721873=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============7799598688880721873==
Content-Type: multipart/alternative;
 boundary="------------090907010302030704090508"

This is a multi-part message in MIME format.
--------------090907010302030704090508
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Good news indeed,
when we are confident that this all works in a few different set-ups, we 
should create a set of docs pointing to the test system on the wiki. I 
guess the other bit which in the longer run would be useful, would be a 
quick guide that describes how to add tests.
Best Regards
Lars

On 19/10/2012 01:07, Dario Faggioli wrote:
> On Thu, 2012-10-18 at 18:29 +0100, Ian Jackson wrote:
>> I have been working on disentangling the automatic test system
>> ("osstest" on xenbits) enough that it can be run without all of its
>> supporting infrastructure.
>>
> That is really great news! :-)
>
>> If you would like to have a go:
>>   - You will need local DHCP and TFTP servers, ideally on the
>>     same machine
>>   - You will probably need a dedicated test box.  The test system
>>     likes to reinstall although it is now possible to avoid this
>>   - git clone git://xenbits.xen.org/osstest.git
>>   - cd osstest
>>   - git checkout standalone
>>   - less README
>>
>> And follow the instructions.  The README is also here:
>>   http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=standalone
>>
> Cool. I'm definitely giving it a try (probably next week).
>
>> The instructions are still sketchy and I'm sure there are many hurdles
>> and wrinkles.  So as I say this is for the brave only.  But if one or
>> two people (Ian C has expressed an interest) would like to try it that
>> would be helpful.
>>
> Although I have very few perl, I'll do my best to be useful too.
>
>> I have tested, more or less recently, installing a host, running a
>> complete job (including a build and a test job).
>>
> Thanks a lot for doing this... I'll finally be able to get rid of my
> wonky bash scripts to achieve basically the same and start building on
> top and, hopefully, contributing to something more serious, structured
> and really useful to everyone! :-)
>
> Regards,
> Dario
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


--------------090907010302030704090508
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
Good news indeed,

      when we are confident that this all works in a few different
      set-ups, we should create a set of docs pointing to the test
      system on the wiki. I guess the other bit which in the longer run
      would be useful, would be a quick guide that describes how to add
      tests.

      Best Regards

      Lars

      

      On 19/10/2012 01:07, Dario Faggioli wrote:

    

    

      
On Thu, 2012-10-18 at 18:29 +0100, Ian Jackson wrote:


      

        
I have been working on disentangling the automatic test system
("osstest" on xenbits) enough that it can be run without all of its
supporting infrastructure.



      

      
That is really great news! :-)



      

        
If you would like to have a go:
 - You will need local DHCP and TFTP servers, ideally on the
   same machine
 - You will probably need a dedicated test box.  The test system
   likes to reinstall although it is now possible to avoid this
 - git clone git://xenbits.xen.org/osstest.git
 - cd osstest
 - git checkout standalone
 - less README

And follow the instructions.  The README is also here:
 http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=standalone



      

      
Cool. I'm definitely giving it a try (probably next week).



      

        
The instructions are still sketchy and I'm sure there are many hurdles
and wrinkles.  So as I say this is for the brave only.  But if one or
two people (Ian C has expressed an interest) would like to try it that
would be helpful.



      

      
Although I have very few perl, I'll do my best to be useful too.



      

        
I have tested, more or less recently, installing a host, running a
complete job (including a build and a test job).



      

      
Thanks a lot for doing this... I'll finally be able to get rid of my
wonky bash scripts to achieve basically the same and start building on
top and, hopefully, contributing to something more serious, structured
and really useful to everyone! :-)

Regards,
Dario



      

      

      

      
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


    

    

  


--------------090907010302030704090508--


--===============7799598688880721873==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7799598688880721873==--


From xen-devel-bounces@lists.xen.org Fri Oct 19 11:43:20 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 11:43:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPAyZ-0001Vt-NL; Fri, 19 Oct 2012 11:42:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPAyX-0001Vo-Ft
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 11:42:49 +0000
Received: from [85.158.139.211:13924] by server-8.bemta-5.messagelabs.com id
	30/68-23193-8BC31805; Fri, 19 Oct 2012 11:42:48 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1350646967!22915416!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17593 invoked from network); 19 Oct 2012 11:42:47 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 11:42:47 -0000
Received: by mail-bk0-f45.google.com with SMTP id jf3so169370bkc.32
	for ; Fri, 19 Oct 2012 04:42:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:to
	:subject:references:in-reply-to:content-type;
	bh=Nv8ULFGYv00kngQKFG+09Eu72SAk0BSf7LYXgxdH7b8=;
	b=OcNJZ//4iK4yAY7GIZSx0Q6YZhS8+auXgZk3AIHI4x5R3ciluy9vBMFPJPctMbn1Iq
	mmA0RuE4flyk1xk9AF+l2QZIGNGBvn3Icic5KV25ABugPjql1t9bd0/KBcLOfJzTqzj6
	CYQUxzooov/nl1sbymOEKJftC5tM0XGMWmQUL9GNrbQqCq5KD2rLktLCrcJbUcq0A0CZ
	y20i9ElsU4yaycOk31MTemmzYNnIEkplCi9xYS/PRRbT62U78WWlBA0YEMx0mVgL7w5a
	4ff/IwORyFEZIL01Cm5aWE6Hbs3QVelEmpf4uZr3t4ivyw7bMGL9GiGsGFyicjgbpM4Z
	8+zw==
Received: by 10.204.150.198 with SMTP id z6mr308045bkv.91.1350646967300;
	Fri, 19 Oct 2012 04:42:47 -0700 (PDT)
Received: from [172.16.26.11] ([46.233.68.235])
	by mx.google.com with ESMTPS id ht18sm794137bkc.14.2012.10.19.04.42.39
	(version=SSLv3 cipher=OTHER); Fri, 19 Oct 2012 04:42:46 -0700 (PDT)
Message-ID: <50813CAD.1040202@xen.org>
Date: Fri, 19 Oct 2012 12:42:37 +0100
From: Lars Kurth 
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <20608.15472.714307.754027@mariner.uk.xensource.com>
	<1350605228.5700.17.camel@Solace>
In-Reply-To: <1350605228.5700.17.camel@Solace>
Subject: Re: [Xen-devel] Xen.org automatic Xen test system, de-tentacled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: lars.kurth@xen.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============7799598688880721873=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============7799598688880721873==
Content-Type: multipart/alternative;
 boundary="------------090907010302030704090508"

This is a multi-part message in MIME format.
--------------090907010302030704090508
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Good news indeed,
when we are confident that this all works in a few different set-ups, we 
should create a set of docs pointing to the test system on the wiki. I 
guess the other bit which in the longer run would be useful, would be a 
quick guide that describes how to add tests.
Best Regards
Lars

On 19/10/2012 01:07, Dario Faggioli wrote:
> On Thu, 2012-10-18 at 18:29 +0100, Ian Jackson wrote:
>> I have been working on disentangling the automatic test system
>> ("osstest" on xenbits) enough that it can be run without all of its
>> supporting infrastructure.
>>
> That is really great news! :-)
>
>> If you would like to have a go:
>>   - You will need local DHCP and TFTP servers, ideally on the
>>     same machine
>>   - You will probably need a dedicated test box.  The test system
>>     likes to reinstall although it is now possible to avoid this
>>   - git clone git://xenbits.xen.org/osstest.git
>>   - cd osstest
>>   - git checkout standalone
>>   - less README
>>
>> And follow the instructions.  The README is also here:
>>   http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=standalone
>>
> Cool. I'm definitely giving it a try (probably next week).
>
>> The instructions are still sketchy and I'm sure there are many hurdles
>> and wrinkles.  So as I say this is for the brave only.  But if one or
>> two people (Ian C has expressed an interest) would like to try it that
>> would be helpful.
>>
> Although I have very few perl, I'll do my best to be useful too.
>
>> I have tested, more or less recently, installing a host, running a
>> complete job (including a build and a test job).
>>
> Thanks a lot for doing this... I'll finally be able to get rid of my
> wonky bash scripts to achieve basically the same and start building on
> top and, hopefully, contributing to something more serious, structured
> and really useful to everyone! :-)
>
> Regards,
> Dario
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


--------------090907010302030704090508
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
Good news indeed,

      when we are confident that this all works in a few different
      set-ups, we should create a set of docs pointing to the test
      system on the wiki. I guess the other bit which in the longer run
      would be useful, would be a quick guide that describes how to add
      tests.

      Best Regards

      Lars

      

      On 19/10/2012 01:07, Dario Faggioli wrote:

    

    

      
On Thu, 2012-10-18 at 18:29 +0100, Ian Jackson wrote:


      

        
I have been working on disentangling the automatic test system
("osstest" on xenbits) enough that it can be run without all of its
supporting infrastructure.



      

      
That is really great news! :-)



      

        
If you would like to have a go:
 - You will need local DHCP and TFTP servers, ideally on the
   same machine
 - You will probably need a dedicated test box.  The test system
   likes to reinstall although it is now possible to avoid this
 - git clone git://xenbits.xen.org/osstest.git
 - cd osstest
 - git checkout standalone
 - less README

And follow the instructions.  The README is also here:
 http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=standalone



      

      
Cool. I'm definitely giving it a try (probably next week).



      

        
The instructions are still sketchy and I'm sure there are many hurdles
and wrinkles.  So as I say this is for the brave only.  But if one or
two people (Ian C has expressed an interest) would like to try it that
would be helpful.



      

      
Although I have very few perl, I'll do my best to be useful too.



      

        
I have tested, more or less recently, installing a host, running a
complete job (including a build and a test job).



      

      
Thanks a lot for doing this... I'll finally be able to get rid of my
wonky bash scripts to achieve basically the same and start building on
top and, hopefully, contributing to something more serious, structured
and really useful to everyone! :-)

Regards,
Dario



      

      

      

      
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


    

    

  


--------------090907010302030704090508--


--===============7799598688880721873==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7799598688880721873==--


From xen-devel-bounces@lists.xen.org Fri Oct 19 13:11:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 13:11:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPCM1-0002ud-Js; Fri, 19 Oct 2012 13:11:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPCM0-0002uU-9w
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 13:11:08 +0000
Received: from [85.158.139.83:55595] by server-7.bemta-5.messagelabs.com id
	5F/20-23102-B6151805; Fri, 19 Oct 2012 13:11:07 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1350652265!31735248!1
X-Originating-IP: [65.55.88.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3467 invoked from network); 19 Oct 2012 13:11:06 -0000
Received: from tx2ehsobe005.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.15)
	by server-6.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	19 Oct 2012 13:11:06 -0000
Received: from mail200-tx2-R.bigfish.com (10.9.14.242) by
	TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id
	14.1.225.23; Fri, 19 Oct 2012 13:11:05 +0000
Received: from mail200-tx2 (localhost [127.0.0.1])	by
	mail200-tx2-R.bigfish.com (Postfix) with ESMTP id DD6BF402F7	for
	; Fri, 19 Oct 2012 13:11:04 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: -3
X-BigFish: VPS-3(zzbb2dI98dI1432Izz1202h1d1ah1d2ahzz8275bhz2dh668h839he5bhf0ah107ah1288h12a5h12a9h12bdh137ah13b6h1441h1155h)
Received: from mail200-tx2 (localhost.localdomain [127.0.0.1]) by mail200-tx2
	(MessageSwitch) id 1350652263294212_16615;
	Fri, 19 Oct 2012 13:11:03 +0000 (UTC)
Received: from TX2EHSMHS005.bigfish.com (unknown [10.9.14.242])	by
	mail200-tx2.bigfish.com (Postfix) with ESMTP id 45E0B980046	for
	; Fri, 19 Oct 2012 13:11:03 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS005.bigfish.com (10.9.99.105) with Microsoft SMTP Server id
	14.1.225.23; Fri, 19 Oct 2012 13:11:02 +0000
X-WSS-ID: 0MC55YD-01-7T7-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1) with ESMTP id 234501028090	for ;
	Fri, 19 Oct 2012 08:11:00 -0500 (CDT)
Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 19 Oct 2012 08:26:58 -0500
Received: from STOREXDAG01.amd.com (10.1.13.10) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Fri, 19 Oct 2012 08:11:00 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag01.amd.com
	(10.1.13.10) with Microsoft SMTP Server id 14.1.323.3; Fri, 19 Oct 2012
	09:10:59 -0400
Message-ID: <50815162.4090601@amd.com>
Date: Fri, 19 Oct 2012 15:10:58 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" 
References: <506EE9A7.6090009@amd.com>
In-Reply-To: <506EE9A7.6090009@amd.com>
X-OriginatorOrg: amd.com
Subject: Re: [Xen-devel] [PATCH] tools/xen-mceinj: support AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Ping?

On 10/05/12 16:07, Christoph Egger wrote:
> 
> xen-mceinj: Support AMD
> 
> Signed-off-by: Christoph Egger 
> 


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 13:11:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 13:11:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPCM1-0002ud-Js; Fri, 19 Oct 2012 13:11:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPCM0-0002uU-9w
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 13:11:08 +0000
Received: from [85.158.139.83:55595] by server-7.bemta-5.messagelabs.com id
	5F/20-23102-B6151805; Fri, 19 Oct 2012 13:11:07 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1350652265!31735248!1
X-Originating-IP: [65.55.88.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3467 invoked from network); 19 Oct 2012 13:11:06 -0000
Received: from tx2ehsobe005.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.15)
	by server-6.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	19 Oct 2012 13:11:06 -0000
Received: from mail200-tx2-R.bigfish.com (10.9.14.242) by
	TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id
	14.1.225.23; Fri, 19 Oct 2012 13:11:05 +0000
Received: from mail200-tx2 (localhost [127.0.0.1])	by
	mail200-tx2-R.bigfish.com (Postfix) with ESMTP id DD6BF402F7	for
	; Fri, 19 Oct 2012 13:11:04 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: -3
X-BigFish: VPS-3(zzbb2dI98dI1432Izz1202h1d1ah1d2ahzz8275bhz2dh668h839he5bhf0ah107ah1288h12a5h12a9h12bdh137ah13b6h1441h1155h)
Received: from mail200-tx2 (localhost.localdomain [127.0.0.1]) by mail200-tx2
	(MessageSwitch) id 1350652263294212_16615;
	Fri, 19 Oct 2012 13:11:03 +0000 (UTC)
Received: from TX2EHSMHS005.bigfish.com (unknown [10.9.14.242])	by
	mail200-tx2.bigfish.com (Postfix) with ESMTP id 45E0B980046	for
	; Fri, 19 Oct 2012 13:11:03 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS005.bigfish.com (10.9.99.105) with Microsoft SMTP Server id
	14.1.225.23; Fri, 19 Oct 2012 13:11:02 +0000
X-WSS-ID: 0MC55YD-01-7T7-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1) with ESMTP id 234501028090	for ;
	Fri, 19 Oct 2012 08:11:00 -0500 (CDT)
Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 19 Oct 2012 08:26:58 -0500
Received: from STOREXDAG01.amd.com (10.1.13.10) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Fri, 19 Oct 2012 08:11:00 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag01.amd.com
	(10.1.13.10) with Microsoft SMTP Server id 14.1.323.3; Fri, 19 Oct 2012
	09:10:59 -0400
Message-ID: <50815162.4090601@amd.com>
Date: Fri, 19 Oct 2012 15:10:58 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" 
References: <506EE9A7.6090009@amd.com>
In-Reply-To: <506EE9A7.6090009@amd.com>
X-OriginatorOrg: amd.com
Subject: Re: [Xen-devel] [PATCH] tools/xen-mceinj: support AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Ping?

On 10/05/12 16:07, Christoph Egger wrote:
> 
> xen-mceinj: Support AMD
> 
> Signed-off-by: Christoph Egger 
> 


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 13:12:06 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 13:12:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPCMI-0002vc-0I; Fri, 19 Oct 2012 13:11:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPCMG-0002vT-Ez
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 13:11:24 +0000
Received: from [85.158.143.99:10875] by server-2.bemta-4.messagelabs.com id
	36/96-22268-B7151805; Fri, 19 Oct 2012 13:11:23 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1350652282!34166036!1
X-Originating-IP: [213.199.154.140]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9757 invoked from network); 19 Oct 2012 13:11:23 -0000
Received: from db3ehsobe002.messaging.microsoft.com (HELO
	db3outboundpool.messaging.microsoft.com) (213.199.154.140)
	by server-3.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	19 Oct 2012 13:11:23 -0000
Received: from mail46-db3-R.bigfish.com (10.3.81.249) by
	DB3EHSOBE010.bigfish.com (10.3.84.30) with Microsoft SMTP Server id
	14.1.225.23; Fri, 19 Oct 2012 13:11:22 +0000
Received: from mail46-db3 (localhost [127.0.0.1])	by mail46-db3-R.bigfish.com
	(Postfix) with ESMTP id 5C9DA2200BF	for ;
	Fri, 19 Oct 2012 13:11:22 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: -3
X-BigFish: VPS-3(zzbb2dI98dI1432Izz1202h1d1ah1d2ahzz8275bhz2dh668h839he5bhf0ah107ah1288h12a5h12a9h12bdh137ah13b6h1441h1155h)
Received: from mail46-db3 (localhost.localdomain [127.0.0.1]) by mail46-db3
	(MessageSwitch) id 1350652279466587_7009;
	Fri, 19 Oct 2012 13:11:19 +0000 (UTC)
Received: from DB3EHSMHS002.bigfish.com (unknown [10.3.81.250])	by
	mail46-db3.bigfish.com (Postfix) with ESMTP id 70222200044	for
	; Fri, 19 Oct 2012 13:11:19 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS002.bigfish.com (10.3.87.102) with Microsoft SMTP Server id
	14.1.225.23; Fri, 19 Oct 2012 13:11:17 +0000
X-WSS-ID: 0MC55YR-01-7TX-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1) with ESMTP id 2C9841028092	for ;
	Fri, 19 Oct 2012 08:11:14 -0500 (CDT)
Received: from SAUSEXDAG05.amd.com (163.181.55.6) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 19 Oct 2012 08:27:13 -0500
Received: from STOREXDAG01.amd.com (10.1.13.10) by sausexdag05.amd.com
	(163.181.55.6) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Fri, 19 Oct 2012 08:11:15 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag01.amd.com
	(10.1.13.10) with Microsoft SMTP Server id 14.1.323.3; Fri, 19 Oct 2012
	09:11:13 -0400
Message-ID: <50815171.70603@amd.com>
Date: Fri, 19 Oct 2012 15:11:13 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" 
References: <50782D4B.50607@amd.com>
In-Reply-To: <50782D4B.50607@amd.com>
X-OriginatorOrg: amd.com
Subject: Re: [Xen-devel] [PATCH] x86/MCE: Implement clearbank callback for
 AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ping?

On 10/12/12 16:46, Christoph Egger wrote:
> 
> Implement clearbank callbank for AMD.
> 
> Signed-off-by: Christoph Egger 
> 


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 13:12:06 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 13:12:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPCMI-0002vc-0I; Fri, 19 Oct 2012 13:11:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPCMG-0002vT-Ez
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 13:11:24 +0000
Received: from [85.158.143.99:10875] by server-2.bemta-4.messagelabs.com id
	36/96-22268-B7151805; Fri, 19 Oct 2012 13:11:23 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1350652282!34166036!1
X-Originating-IP: [213.199.154.140]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9757 invoked from network); 19 Oct 2012 13:11:23 -0000
Received: from db3ehsobe002.messaging.microsoft.com (HELO
	db3outboundpool.messaging.microsoft.com) (213.199.154.140)
	by server-3.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	19 Oct 2012 13:11:23 -0000
Received: from mail46-db3-R.bigfish.com (10.3.81.249) by
	DB3EHSOBE010.bigfish.com (10.3.84.30) with Microsoft SMTP Server id
	14.1.225.23; Fri, 19 Oct 2012 13:11:22 +0000
Received: from mail46-db3 (localhost [127.0.0.1])	by mail46-db3-R.bigfish.com
	(Postfix) with ESMTP id 5C9DA2200BF	for ;
	Fri, 19 Oct 2012 13:11:22 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: -3
X-BigFish: VPS-3(zzbb2dI98dI1432Izz1202h1d1ah1d2ahzz8275bhz2dh668h839he5bhf0ah107ah1288h12a5h12a9h12bdh137ah13b6h1441h1155h)
Received: from mail46-db3 (localhost.localdomain [127.0.0.1]) by mail46-db3
	(MessageSwitch) id 1350652279466587_7009;
	Fri, 19 Oct 2012 13:11:19 +0000 (UTC)
Received: from DB3EHSMHS002.bigfish.com (unknown [10.3.81.250])	by
	mail46-db3.bigfish.com (Postfix) with ESMTP id 70222200044	for
	; Fri, 19 Oct 2012 13:11:19 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS002.bigfish.com (10.3.87.102) with Microsoft SMTP Server id
	14.1.225.23; Fri, 19 Oct 2012 13:11:17 +0000
X-WSS-ID: 0MC55YR-01-7TX-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1) with ESMTP id 2C9841028092	for ;
	Fri, 19 Oct 2012 08:11:14 -0500 (CDT)
Received: from SAUSEXDAG05.amd.com (163.181.55.6) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 19 Oct 2012 08:27:13 -0500
Received: from STOREXDAG01.amd.com (10.1.13.10) by sausexdag05.amd.com
	(163.181.55.6) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Fri, 19 Oct 2012 08:11:15 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag01.amd.com
	(10.1.13.10) with Microsoft SMTP Server id 14.1.323.3; Fri, 19 Oct 2012
	09:11:13 -0400
Message-ID: <50815171.70603@amd.com>
Date: Fri, 19 Oct 2012 15:11:13 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" 
References: <50782D4B.50607@amd.com>
In-Reply-To: <50782D4B.50607@amd.com>
X-OriginatorOrg: amd.com
Subject: Re: [Xen-devel] [PATCH] x86/MCE: Implement clearbank callback for
 AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ping?

On 10/12/12 16:46, Christoph Egger wrote:
> 
> Implement clearbank callbank for AMD.
> 
> Signed-off-by: Christoph Egger 
> 


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 13:12:18 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 13:12:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPCMP-0002wb-DC; Fri, 19 Oct 2012 13:11:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPCMN-0002wD-80
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 13:11:31 +0000
Received: from [85.158.139.211:55759] by server-9.bemta-5.messagelabs.com id
	B3/DE-23053-28151805; Fri, 19 Oct 2012 13:11:30 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1350652288!22960080!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODE1Njg1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31839 invoked from network); 19 Oct 2012 13:11:29 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Oct 2012 13:11:29 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9JDBOEh024770
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Oct 2012 13:11:25 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9JDBNQa001854
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 19 Oct 2012 13:11:24 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9JDBN56027569; Fri, 19 Oct 2012 08:11:23 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Oct 2012 06:11:23 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 24E0A4035B; Fri, 19 Oct 2012 08:59:19 -0400 (EDT)
Date: Fri, 19 Oct 2012 08:59:19 -0400
From: Konrad Rzeszutek Wilk 
To: David Vrabel , bhelgaas@google.com
Message-ID: <20121019125919.GC26830@phenom.dumpdata.com>
References: <507FD39F.4060601@citrix.com>
	<1350554618-14582-3-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1350554618-14582-3-git-send-email-david.vrabel@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Bjorn Helgaas , linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3/5] xen-pcifront: handle backend CLOSED
	without CLOSING
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Oct 18, 2012 at 11:03:36AM +0100, David Vrabel wrote:
> From: David Vrabel 
> 
> Backend drivers shouldn't transistion to CLOSED unless the frontend is
> CLOSED.  If a backend does transition to CLOSED too soon then the
> frontend may not see the CLOSING state and will not properly shutdown.
> 
> So, treat an unexpected backend CLOSED state the same as CLOSING.
> 
> Signed-off-by: David Vrabel 
> Acked-by: Konrad Rzeszutek Wilk 
> ---
> Cc: linux-pci@vger.kernel.org
> Cc: Bjorn Helgaas 

Bjorn, do you want me to prep a git pull with this patch
or can I have your Ack to put it my tree and have it part of my
git pull to Linus?

Thx.
> ---
>  drivers/pci/xen-pcifront.c |    5 ++++-
>  1 files changed, 4 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
> index 0aab85a..a0c7312 100644
> --- a/drivers/pci/xen-pcifront.c
> +++ b/drivers/pci/xen-pcifront.c
> @@ -1068,13 +1068,16 @@ static void __init_refok pcifront_backend_changed(struct xenbus_device *xdev,
>  	case XenbusStateInitialising:
>  	case XenbusStateInitWait:
>  	case XenbusStateInitialised:
> -	case XenbusStateClosed:
>  		break;
>  
>  	case XenbusStateConnected:
>  		pcifront_try_connect(pdev);
>  		break;
>  
> +	case XenbusStateClosed:
> +		if (xdev->state == XenbusStateClosed)
> +			break;
> +		/* Missed the backend's CLOSING state -- fallthrough */
>  	case XenbusStateClosing:
>  		dev_warn(&xdev->dev, "backend going away!\n");
>  		pcifront_try_disconnect(pdev);
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 13:12:18 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 13:12:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPCMP-0002wb-DC; Fri, 19 Oct 2012 13:11:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPCMN-0002wD-80
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 13:11:31 +0000
Received: from [85.158.139.211:55759] by server-9.bemta-5.messagelabs.com id
	B3/DE-23053-28151805; Fri, 19 Oct 2012 13:11:30 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1350652288!22960080!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODE1Njg1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31839 invoked from network); 19 Oct 2012 13:11:29 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Oct 2012 13:11:29 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9JDBOEh024770
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Oct 2012 13:11:25 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9JDBNQa001854
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 19 Oct 2012 13:11:24 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9JDBN56027569; Fri, 19 Oct 2012 08:11:23 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Oct 2012 06:11:23 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 24E0A4035B; Fri, 19 Oct 2012 08:59:19 -0400 (EDT)
Date: Fri, 19 Oct 2012 08:59:19 -0400
From: Konrad Rzeszutek Wilk 
To: David Vrabel , bhelgaas@google.com
Message-ID: <20121019125919.GC26830@phenom.dumpdata.com>
References: <507FD39F.4060601@citrix.com>
	<1350554618-14582-3-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1350554618-14582-3-git-send-email-david.vrabel@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Bjorn Helgaas , linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3/5] xen-pcifront: handle backend CLOSED
	without CLOSING
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Oct 18, 2012 at 11:03:36AM +0100, David Vrabel wrote:
> From: David Vrabel 
> 
> Backend drivers shouldn't transistion to CLOSED unless the frontend is
> CLOSED.  If a backend does transition to CLOSED too soon then the
> frontend may not see the CLOSING state and will not properly shutdown.
> 
> So, treat an unexpected backend CLOSED state the same as CLOSING.
> 
> Signed-off-by: David Vrabel 
> Acked-by: Konrad Rzeszutek Wilk 
> ---
> Cc: linux-pci@vger.kernel.org
> Cc: Bjorn Helgaas 

Bjorn, do you want me to prep a git pull with this patch
or can I have your Ack to put it my tree and have it part of my
git pull to Linus?

Thx.
> ---
>  drivers/pci/xen-pcifront.c |    5 ++++-
>  1 files changed, 4 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
> index 0aab85a..a0c7312 100644
> --- a/drivers/pci/xen-pcifront.c
> +++ b/drivers/pci/xen-pcifront.c
> @@ -1068,13 +1068,16 @@ static void __init_refok pcifront_backend_changed(struct xenbus_device *xdev,
>  	case XenbusStateInitialising:
>  	case XenbusStateInitWait:
>  	case XenbusStateInitialised:
> -	case XenbusStateClosed:
>  		break;
>  
>  	case XenbusStateConnected:
>  		pcifront_try_connect(pdev);
>  		break;
>  
> +	case XenbusStateClosed:
> +		if (xdev->state == XenbusStateClosed)
> +			break;
> +		/* Missed the backend's CLOSING state -- fallthrough */
>  	case XenbusStateClosing:
>  		dev_warn(&xdev->dev, "backend going away!\n");
>  		pcifront_try_disconnect(pdev);
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 13:12:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 13:12:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPCNF-00035q-Ry; Fri, 19 Oct 2012 13:12:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPCNE-00035S-Lg
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 13:12:24 +0000
Received: from [85.158.139.211:26141] by server-7.bemta-5.messagelabs.com id
	D9/82-23102-7B151805; Fri, 19 Oct 2012 13:12:23 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1350652341!22988123!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgyMjgwMg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14135 invoked from network); 19 Oct 2012 13:12:22 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-4.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Oct 2012 13:12:22 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9JDCG8A002596
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Oct 2012 13:12:17 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9JDCGQr020619
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 19 Oct 2012 13:12:16 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9JDCG7r003972; Fri, 19 Oct 2012 08:12:16 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Oct 2012 06:12:15 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 7A1AD4035B; Fri, 19 Oct 2012 09:00:11 -0400 (EDT)
Date: Fri, 19 Oct 2012 09:00:11 -0400
From: Konrad Rzeszutek Wilk 
To: David Vrabel , FlorianSchandinat@gmx.de
Message-ID: <20121019130011.GD26830@phenom.dumpdata.com>
References: <507FD39F.4060601@citrix.com>
	<1350554618-14582-4-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1350554618-14582-4-git-send-email-david.vrabel@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: linux-fbdev@vger.kernel.org,
	Florian Tobias Schandinat ,
	linux-kernel@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 4/5] xen-fbfront: handle backend CLOSED
	without CLOSING
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Oct 18, 2012 at 11:03:37AM +0100, David Vrabel wrote:
> From: David Vrabel 
> 
> Backend drivers shouldn't transistion to CLOSED unless the frontend is
> CLOSED.  If a backend does transition to CLOSED too soon then the
> frontend may not see the CLOSING state and will not properly shutdown.
> 
> So, treat an unexpected backend CLOSED state the same as CLOSING.
> 
> Signed-off-by: David Vrabel 
> Acked-by: Konrad Rzeszutek Wilk 
> ---
> Cc: linux-fbdev@vger.kernel.org
> Cc: Florian Tobias Schandinat 

Hey Florian,

Should I prep a git pull for you with this or would it be OK
if I just have your Ack to put this in my git pull for Linus?

Thanks!
> ---
>  drivers/video/xen-fbfront.c |    5 ++++-
>  1 files changed, 4 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/video/xen-fbfront.c b/drivers/video/xen-fbfront.c
> index b7f5173..917bb56 100644
> --- a/drivers/video/xen-fbfront.c
> +++ b/drivers/video/xen-fbfront.c
> @@ -641,7 +641,6 @@ static void xenfb_backend_changed(struct xenbus_device *dev,
>  	case XenbusStateReconfiguring:
>  	case XenbusStateReconfigured:
>  	case XenbusStateUnknown:
> -	case XenbusStateClosed:
>  		break;
>  
>  	case XenbusStateInitWait:
> @@ -670,6 +669,10 @@ InitWait:
>  		info->feature_resize = val;
>  		break;
>  
> +	case XenbusStateClosed:
> +		if (dev->state == XenbusStateClosed)
> +			break;
> +		/* Missed the backend's CLOSING state -- fallthrough */
>  	case XenbusStateClosing:
>  		xenbus_frontend_closed(dev);
>  		break;
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 13:12:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 13:12:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPCNF-00035q-Ry; Fri, 19 Oct 2012 13:12:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPCNE-00035S-Lg
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 13:12:24 +0000
Received: from [85.158.139.211:26141] by server-7.bemta-5.messagelabs.com id
	D9/82-23102-7B151805; Fri, 19 Oct 2012 13:12:23 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1350652341!22988123!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgyMjgwMg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14135 invoked from network); 19 Oct 2012 13:12:22 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-4.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Oct 2012 13:12:22 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9JDCG8A002596
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Oct 2012 13:12:17 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9JDCGQr020619
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 19 Oct 2012 13:12:16 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9JDCG7r003972; Fri, 19 Oct 2012 08:12:16 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Oct 2012 06:12:15 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 7A1AD4035B; Fri, 19 Oct 2012 09:00:11 -0400 (EDT)
Date: Fri, 19 Oct 2012 09:00:11 -0400
From: Konrad Rzeszutek Wilk 
To: David Vrabel , FlorianSchandinat@gmx.de
Message-ID: <20121019130011.GD26830@phenom.dumpdata.com>
References: <507FD39F.4060601@citrix.com>
	<1350554618-14582-4-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1350554618-14582-4-git-send-email-david.vrabel@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: linux-fbdev@vger.kernel.org,
	Florian Tobias Schandinat ,
	linux-kernel@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 4/5] xen-fbfront: handle backend CLOSED
	without CLOSING
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Oct 18, 2012 at 11:03:37AM +0100, David Vrabel wrote:
> From: David Vrabel 
> 
> Backend drivers shouldn't transistion to CLOSED unless the frontend is
> CLOSED.  If a backend does transition to CLOSED too soon then the
> frontend may not see the CLOSING state and will not properly shutdown.
> 
> So, treat an unexpected backend CLOSED state the same as CLOSING.
> 
> Signed-off-by: David Vrabel 
> Acked-by: Konrad Rzeszutek Wilk 
> ---
> Cc: linux-fbdev@vger.kernel.org
> Cc: Florian Tobias Schandinat 

Hey Florian,

Should I prep a git pull for you with this or would it be OK
if I just have your Ack to put this in my git pull for Linus?

Thanks!
> ---
>  drivers/video/xen-fbfront.c |    5 ++++-
>  1 files changed, 4 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/video/xen-fbfront.c b/drivers/video/xen-fbfront.c
> index b7f5173..917bb56 100644
> --- a/drivers/video/xen-fbfront.c
> +++ b/drivers/video/xen-fbfront.c
> @@ -641,7 +641,6 @@ static void xenfb_backend_changed(struct xenbus_device *dev,
>  	case XenbusStateReconfiguring:
>  	case XenbusStateReconfigured:
>  	case XenbusStateUnknown:
> -	case XenbusStateClosed:
>  		break;
>  
>  	case XenbusStateInitWait:
> @@ -670,6 +669,10 @@ InitWait:
>  		info->feature_resize = val;
>  		break;
>  
> +	case XenbusStateClosed:
> +		if (dev->state == XenbusStateClosed)
> +			break;
> +		/* Missed the backend's CLOSING state -- fallthrough */
>  	case XenbusStateClosing:
>  		xenbus_frontend_closed(dev);
>  		break;
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 13:13:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 13:13:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPCNz-0003De-As; Fri, 19 Oct 2012 13:13:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPCNx-0003DM-Rt
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 13:13:10 +0000
Received: from [85.158.139.211:9594] by server-16.bemta-5.messagelabs.com id
	40/DB-09196-5E151805; Fri, 19 Oct 2012 13:13:09 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1350652387!22980162!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODE1Njg1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6506 invoked from network); 19 Oct 2012 13:13:08 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Oct 2012 13:13:08 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9JDD4ud026601
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Oct 2012 13:13:05 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9JDD3dX009057
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 19 Oct 2012 13:13:04 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9JDD3eM017028; Fri, 19 Oct 2012 08:13:03 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Oct 2012 06:13:03 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 3FFF04035B; Fri, 19 Oct 2012 09:00:59 -0400 (EDT)
Date: Fri, 19 Oct 2012 09:00:59 -0400
From: Konrad Rzeszutek Wilk 
To: David Vrabel , dmitry.torokhov@gmail.com
Message-ID: <20121019130059.GE26830@phenom.dumpdata.com>
References: <507FD39F.4060601@citrix.com>
	<1350554618-14582-5-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1350554618-14582-5-git-send-email-david.vrabel@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: linux-input@vger.kernel.org, Dmitry Torokhov ,
	linux-kernel@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 5/5] xen-kbdfront: handle backend CLOSED
	without CLOSING
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Oct 18, 2012 at 11:03:38AM +0100, David Vrabel wrote:
> From: David Vrabel 
> 
> Backend drivers shouldn't transistion to CLOSED unless the frontend is
> CLOSED.  If a backend does transition to CLOSED too soon then the
> frontend may not see the CLOSING state and will not properly shutdown.
> 
> So, treat an unexpected backend CLOSED state the same as CLOSING.
> 
> Signed-off-by: David Vrabel 
> Acked-by: Konrad Rzeszutek Wilk 
> ---
> Cc: linux-input@vger.kernel.org
> Cc: Dmitry Torokhov 

Hey Dmitry,

Should I prep a git pull for you for this or are you OK giving
an Ack for me to put this patch in my git pull for Linus?

Thx.
> ---
>  drivers/input/misc/xen-kbdfront.c |    5 ++++-
>  1 files changed, 4 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
> index 02ca868..6f7d990 100644
> --- a/drivers/input/misc/xen-kbdfront.c
> +++ b/drivers/input/misc/xen-kbdfront.c
> @@ -311,7 +311,6 @@ static void xenkbd_backend_changed(struct xenbus_device *dev,
>  	case XenbusStateReconfiguring:
>  	case XenbusStateReconfigured:
>  	case XenbusStateUnknown:
> -	case XenbusStateClosed:
>  		break;
>  
>  	case XenbusStateInitWait:
> @@ -350,6 +349,10 @@ InitWait:
>  
>  		break;
>  
> +	case XenbusStateClosed:
> +		if (dev->state == XenbusStateClosed)
> +			break;
> +		/* Missed the backend's CLOSING state -- fallthrough */
>  	case XenbusStateClosing:
>  		xenbus_frontend_closed(dev);
>  		break;
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 13:13:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 13:13:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPCNz-0003De-As; Fri, 19 Oct 2012 13:13:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPCNx-0003DM-Rt
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 13:13:10 +0000
Received: from [85.158.139.211:9594] by server-16.bemta-5.messagelabs.com id
	40/DB-09196-5E151805; Fri, 19 Oct 2012 13:13:09 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1350652387!22980162!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODE1Njg1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6506 invoked from network); 19 Oct 2012 13:13:08 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Oct 2012 13:13:08 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9JDD4ud026601
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Oct 2012 13:13:05 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9JDD3dX009057
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 19 Oct 2012 13:13:04 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9JDD3eM017028; Fri, 19 Oct 2012 08:13:03 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Oct 2012 06:13:03 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 3FFF04035B; Fri, 19 Oct 2012 09:00:59 -0400 (EDT)
Date: Fri, 19 Oct 2012 09:00:59 -0400
From: Konrad Rzeszutek Wilk 
To: David Vrabel , dmitry.torokhov@gmail.com
Message-ID: <20121019130059.GE26830@phenom.dumpdata.com>
References: <507FD39F.4060601@citrix.com>
	<1350554618-14582-5-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1350554618-14582-5-git-send-email-david.vrabel@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: linux-input@vger.kernel.org, Dmitry Torokhov ,
	linux-kernel@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 5/5] xen-kbdfront: handle backend CLOSED
	without CLOSING
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Oct 18, 2012 at 11:03:38AM +0100, David Vrabel wrote:
> From: David Vrabel 
> 
> Backend drivers shouldn't transistion to CLOSED unless the frontend is
> CLOSED.  If a backend does transition to CLOSED too soon then the
> frontend may not see the CLOSING state and will not properly shutdown.
> 
> So, treat an unexpected backend CLOSED state the same as CLOSING.
> 
> Signed-off-by: David Vrabel 
> Acked-by: Konrad Rzeszutek Wilk 
> ---
> Cc: linux-input@vger.kernel.org
> Cc: Dmitry Torokhov 

Hey Dmitry,

Should I prep a git pull for you for this or are you OK giving
an Ack for me to put this patch in my git pull for Linus?

Thx.
> ---
>  drivers/input/misc/xen-kbdfront.c |    5 ++++-
>  1 files changed, 4 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
> index 02ca868..6f7d990 100644
> --- a/drivers/input/misc/xen-kbdfront.c
> +++ b/drivers/input/misc/xen-kbdfront.c
> @@ -311,7 +311,6 @@ static void xenkbd_backend_changed(struct xenbus_device *dev,
>  	case XenbusStateReconfiguring:
>  	case XenbusStateReconfigured:
>  	case XenbusStateUnknown:
> -	case XenbusStateClosed:
>  		break;
>  
>  	case XenbusStateInitWait:
> @@ -350,6 +349,10 @@ InitWait:
>  
>  		break;
>  
> +	case XenbusStateClosed:
> +		if (dev->state == XenbusStateClosed)
> +			break;
> +		/* Missed the backend's CLOSING state -- fallthrough */
>  	case XenbusStateClosing:
>  		xenbus_frontend_closed(dev);
>  		break;
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 13:20:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 13:20:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPCUR-0003k7-Gl; Fri, 19 Oct 2012 13:19:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPCUP-0003jv-Tn
	for Xen-devel@lists.xensource.com; Fri, 19 Oct 2012 13:19:50 +0000
Received: from [85.158.138.51:52928] by server-14.bemta-3.messagelabs.com id
	D3/1C-17276-57351805; Fri, 19 Oct 2012 13:19:49 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1350652787!16329553!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODE1Njg1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7633 invoked from network); 19 Oct 2012 13:19:48 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Oct 2012 13:19:48 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9JDJjxr005510
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Oct 2012 13:19:46 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9JDJipU018121
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 19 Oct 2012 13:19:45 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9JDJiQL021973; Fri, 19 Oct 2012 08:19:44 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Oct 2012 06:19:44 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D4D7B4035B; Fri, 19 Oct 2012 09:07:39 -0400 (EDT)
Date: Fri, 19 Oct 2012 09:07:39 -0400
From: Konrad Rzeszutek Wilk 
To: Mukesh Rathor 
Message-ID: <20121019130739.GF26830@phenom.dumpdata.com>
References: <20121017172642.349b2aae@mantra.us.oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20121017172642.349b2aae@mantra.us.oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" 
Subject: Re: [Xen-devel] [PATCH V3 1/6]: PVH: basic and header changes,
 elfnote changes, ...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 17, 2012 at 05:26:42PM -0700, Mukesh Rathor wrote:
> [PATCH 1/6] PVH: is a PV linux guest that has extended capabilities. This patch allows it to be configured and enabled. Also, basic header file changes to add new subcalls to physmap hypercall. Lastly, mfn_to_local_pfn must return mfn for paging mode translate.

Usually one splits that description. So you have:

(for title)
"xen/pvh: Introduce ParaVirtualized Hardware support."

And then in the body do (and split it in 80 lines for
easier readability):

ParaVirtualized Hardware (PVH) support allows a PV linux guest that has extended capabilities.

[Q:Like what kind of extended capabilities? Can you explain
what they are?]

This patch allows it to be configured and enabled. Also, basic header file changes to
add new subcalls to physmap hypercall. 

Lastly, mfn_to_local_pfn must return mfn for paging mode translate.

[Q: You should explain why. There is nothing in this description
saying why we do not need the PV MMU anymore]

[note: the verb tense is wrong since I meshed your description
with mine, so it would have to be fixed]
> 
> Signed-off-by: Mukesh Rathor 
> ---
>  arch/x86/include/asm/xen/page.h |    3 +++
>  arch/x86/xen/Kconfig            |   10 ++++++++++
>  arch/x86/xen/xen-head.S         |   11 ++++++++++-
>  include/xen/interface/memory.h  |   24 +++++++++++++++++++++++-
>  include/xen/interface/physdev.h |   10 ++++++++++
>  5 files changed, 56 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
> index 472b9b7..6af440d 100644
> --- a/arch/x86/include/asm/xen/page.h
> +++ b/arch/x86/include/asm/xen/page.h
> @@ -159,6 +159,9 @@ static inline xpaddr_t machine_to_phys(xmaddr_t machine)
>  static inline unsigned long mfn_to_local_pfn(unsigned long mfn)
>  {
>  	unsigned long pfn = mfn_to_pfn(mfn);
> +
> +	if (xen_feature(XENFEAT_auto_translated_physmap))
> +		return mfn;
>  	if (get_phys_to_machine(pfn) != mfn)
>  		return -1; /* force !pfn_valid() */
>  	return pfn;
> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> index fdce49c..822c5a0 100644
> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@ -50,3 +50,13 @@ config XEN_DEBUG_FS
>  	  Enable statistics output and various tuning options in debugfs.
>  	  Enabling this option may incur a significant performance overhead.
>  
> +config XEN_X86_PVH
> +	bool "Support for running as a PVH guest (EXPERIMENTAL)"
> +	depends on X86_64 && XEN && EXPERIMENTAL
> +	default n
> +	help
> +	   This option enables support for running as a PVH guest (PV guest
> +	   using hardware extensions) under a suitably capable hypervisor.
> +	   This option is EXPERIMENTAL because the hypervisor interfaces
> +	   which it uses are not yet considered stable therefore backwards and
> +	   forwards compatibility is not yet guaranteed.  If unsure, say N.
> diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
> index 7faed58..1a6bca1 100644
> --- a/arch/x86/xen/xen-head.S
> +++ b/arch/x86/xen/xen-head.S
> @@ -13,6 +13,15 @@
>  #include 
>  #include 
>  
> +#ifdef CONFIG_XEN_X86_PVH
> +#define FEATURES_PVH "|writable_descriptor_tables" \
> +		     "|auto_translated_physmap" \
> +		     "|supervisor_mode_kernel" \
> +		     "|hvm_callback_vector"
> +#else
> +#define FEATURES_PVH /* Not supported */
> +#endif
> +
>  	__INIT
>  ENTRY(startup_xen)
>  	cld
> @@ -95,7 +104,7 @@ NEXT_HYPERCALL(arch_6)
>  #endif
>  	ELFNOTE(Xen, XEN_ELFNOTE_ENTRY,          _ASM_PTR startup_xen)
>  	ELFNOTE(Xen, XEN_ELFNOTE_HYPERCALL_PAGE, _ASM_PTR hypercall_page)
> -	ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,       .asciz "!writable_page_tables|pae_pgdir_above_4gb")
> +	ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,       .asciz "!writable_page_tables|pae_pgdir_above_4gb"FEATURES_PVH)
>  	ELFNOTE(Xen, XEN_ELFNOTE_PAE_MODE,       .asciz "yes")
>  	ELFNOTE(Xen, XEN_ELFNOTE_LOADER,         .asciz "generic")
>  	ELFNOTE(Xen, XEN_ELFNOTE_L1_MFN_VALID,
> diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
> index d8e33a9..425911f 100644
> --- a/include/xen/interface/memory.h
> +++ b/include/xen/interface/memory.h
> @@ -169,7 +169,13 @@ struct xen_add_to_physmap {
>      /* Source mapping space. */
>  #define XENMAPSPACE_shared_info 0 /* shared info page */
>  #define XENMAPSPACE_grant_table 1 /* grant table page */
> -    unsigned int space;
> +#define XENMAPSPACE_gmfn        2 /* GMFN */
> +#define XENMAPSPACE_gmfn_range  3 /* GMFN range */
> +#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */
> +    uint16_t space;
> +    domid_t foreign_domid;         /* IFF XENMAPSPACE_gmfn_foreign */
> +
> +#define XENMAPIDX_grant_table_status 0x80000000
>  
>      /* Index into source mapping space. */
>      unsigned long idx;
> @@ -237,4 +243,20 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_memory_map);
>   * during a driver critical region.
>   */
>  extern spinlock_t xen_reservation_lock;
> +
> +/*
> + * Unmaps the page appearing at a particular GPFN from the specified guest's
> + * pseudophysical address space.
> + * arg == addr of xen_remove_from_physmap_t.
> + */
> +#define XENMEM_remove_from_physmap      15
> +struct xen_remove_from_physmap {
> +    /* Which domain to change the mapping for. */
> +    domid_t domid;
> +
> +    /* GPFN of the current mapping of the page. */
> +    xen_pfn_t gpfn;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_remove_from_physmap);
> +
>  #endif /* __XEN_PUBLIC_MEMORY_H__ */
> diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
> index 9ce788d..3b9d5b6 100644
> --- a/include/xen/interface/physdev.h
> +++ b/include/xen/interface/physdev.h
> @@ -258,6 +258,16 @@ struct physdev_pci_device {
>      uint8_t devfn;
>  };
>  
> +#define PHYSDEVOP_pvh_map_iomem        30
> +struct physdev_map_iomem {
> +    /* IN */
> +    uint64_t first_gfn;
> +    uint64_t first_mfn;
> +    uint32_t nr_mfns;
> +    uint32_t add_mapping;        /* 1 == add mapping;  0 == unmap */
> +
> +};
> +
>  /*
>   * Notify that some PIRQ-bound event channels have been unmasked.
>   * ** This command is obsolete since interface version 0x00030202 and is **
> -- 
> 1.7.2.3

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 13:20:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 13:20:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPCUR-0003k7-Gl; Fri, 19 Oct 2012 13:19:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPCUP-0003jv-Tn
	for Xen-devel@lists.xensource.com; Fri, 19 Oct 2012 13:19:50 +0000
Received: from [85.158.138.51:52928] by server-14.bemta-3.messagelabs.com id
	D3/1C-17276-57351805; Fri, 19 Oct 2012 13:19:49 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1350652787!16329553!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODE1Njg1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7633 invoked from network); 19 Oct 2012 13:19:48 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Oct 2012 13:19:48 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9JDJjxr005510
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Oct 2012 13:19:46 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9JDJipU018121
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 19 Oct 2012 13:19:45 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9JDJiQL021973; Fri, 19 Oct 2012 08:19:44 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Oct 2012 06:19:44 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D4D7B4035B; Fri, 19 Oct 2012 09:07:39 -0400 (EDT)
Date: Fri, 19 Oct 2012 09:07:39 -0400
From: Konrad Rzeszutek Wilk 
To: Mukesh Rathor 
Message-ID: <20121019130739.GF26830@phenom.dumpdata.com>
References: <20121017172642.349b2aae@mantra.us.oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20121017172642.349b2aae@mantra.us.oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" 
Subject: Re: [Xen-devel] [PATCH V3 1/6]: PVH: basic and header changes,
 elfnote changes, ...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 17, 2012 at 05:26:42PM -0700, Mukesh Rathor wrote:
> [PATCH 1/6] PVH: is a PV linux guest that has extended capabilities. This patch allows it to be configured and enabled. Also, basic header file changes to add new subcalls to physmap hypercall. Lastly, mfn_to_local_pfn must return mfn for paging mode translate.

Usually one splits that description. So you have:

(for title)
"xen/pvh: Introduce ParaVirtualized Hardware support."

And then in the body do (and split it in 80 lines for
easier readability):

ParaVirtualized Hardware (PVH) support allows a PV linux guest that has extended capabilities.

[Q:Like what kind of extended capabilities? Can you explain
what they are?]

This patch allows it to be configured and enabled. Also, basic header file changes to
add new subcalls to physmap hypercall. 

Lastly, mfn_to_local_pfn must return mfn for paging mode translate.

[Q: You should explain why. There is nothing in this description
saying why we do not need the PV MMU anymore]

[note: the verb tense is wrong since I meshed your description
with mine, so it would have to be fixed]
> 
> Signed-off-by: Mukesh Rathor 
> ---
>  arch/x86/include/asm/xen/page.h |    3 +++
>  arch/x86/xen/Kconfig            |   10 ++++++++++
>  arch/x86/xen/xen-head.S         |   11 ++++++++++-
>  include/xen/interface/memory.h  |   24 +++++++++++++++++++++++-
>  include/xen/interface/physdev.h |   10 ++++++++++
>  5 files changed, 56 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
> index 472b9b7..6af440d 100644
> --- a/arch/x86/include/asm/xen/page.h
> +++ b/arch/x86/include/asm/xen/page.h
> @@ -159,6 +159,9 @@ static inline xpaddr_t machine_to_phys(xmaddr_t machine)
>  static inline unsigned long mfn_to_local_pfn(unsigned long mfn)
>  {
>  	unsigned long pfn = mfn_to_pfn(mfn);
> +
> +	if (xen_feature(XENFEAT_auto_translated_physmap))
> +		return mfn;
>  	if (get_phys_to_machine(pfn) != mfn)
>  		return -1; /* force !pfn_valid() */
>  	return pfn;
> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> index fdce49c..822c5a0 100644
> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@ -50,3 +50,13 @@ config XEN_DEBUG_FS
>  	  Enable statistics output and various tuning options in debugfs.
>  	  Enabling this option may incur a significant performance overhead.
>  
> +config XEN_X86_PVH
> +	bool "Support for running as a PVH guest (EXPERIMENTAL)"
> +	depends on X86_64 && XEN && EXPERIMENTAL
> +	default n
> +	help
> +	   This option enables support for running as a PVH guest (PV guest
> +	   using hardware extensions) under a suitably capable hypervisor.
> +	   This option is EXPERIMENTAL because the hypervisor interfaces
> +	   which it uses are not yet considered stable therefore backwards and
> +	   forwards compatibility is not yet guaranteed.  If unsure, say N.
> diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
> index 7faed58..1a6bca1 100644
> --- a/arch/x86/xen/xen-head.S
> +++ b/arch/x86/xen/xen-head.S
> @@ -13,6 +13,15 @@
>  #include 
>  #include 
>  
> +#ifdef CONFIG_XEN_X86_PVH
> +#define FEATURES_PVH "|writable_descriptor_tables" \
> +		     "|auto_translated_physmap" \
> +		     "|supervisor_mode_kernel" \
> +		     "|hvm_callback_vector"
> +#else
> +#define FEATURES_PVH /* Not supported */
> +#endif
> +
>  	__INIT
>  ENTRY(startup_xen)
>  	cld
> @@ -95,7 +104,7 @@ NEXT_HYPERCALL(arch_6)
>  #endif
>  	ELFNOTE(Xen, XEN_ELFNOTE_ENTRY,          _ASM_PTR startup_xen)
>  	ELFNOTE(Xen, XEN_ELFNOTE_HYPERCALL_PAGE, _ASM_PTR hypercall_page)
> -	ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,       .asciz "!writable_page_tables|pae_pgdir_above_4gb")
> +	ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,       .asciz "!writable_page_tables|pae_pgdir_above_4gb"FEATURES_PVH)
>  	ELFNOTE(Xen, XEN_ELFNOTE_PAE_MODE,       .asciz "yes")
>  	ELFNOTE(Xen, XEN_ELFNOTE_LOADER,         .asciz "generic")
>  	ELFNOTE(Xen, XEN_ELFNOTE_L1_MFN_VALID,
> diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
> index d8e33a9..425911f 100644
> --- a/include/xen/interface/memory.h
> +++ b/include/xen/interface/memory.h
> @@ -169,7 +169,13 @@ struct xen_add_to_physmap {
>      /* Source mapping space. */
>  #define XENMAPSPACE_shared_info 0 /* shared info page */
>  #define XENMAPSPACE_grant_table 1 /* grant table page */
> -    unsigned int space;
> +#define XENMAPSPACE_gmfn        2 /* GMFN */
> +#define XENMAPSPACE_gmfn_range  3 /* GMFN range */
> +#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */
> +    uint16_t space;
> +    domid_t foreign_domid;         /* IFF XENMAPSPACE_gmfn_foreign */
> +
> +#define XENMAPIDX_grant_table_status 0x80000000
>  
>      /* Index into source mapping space. */
>      unsigned long idx;
> @@ -237,4 +243,20 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_memory_map);
>   * during a driver critical region.
>   */
>  extern spinlock_t xen_reservation_lock;
> +
> +/*
> + * Unmaps the page appearing at a particular GPFN from the specified guest's
> + * pseudophysical address space.
> + * arg == addr of xen_remove_from_physmap_t.
> + */
> +#define XENMEM_remove_from_physmap      15
> +struct xen_remove_from_physmap {
> +    /* Which domain to change the mapping for. */
> +    domid_t domid;
> +
> +    /* GPFN of the current mapping of the page. */
> +    xen_pfn_t gpfn;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_remove_from_physmap);
> +
>  #endif /* __XEN_PUBLIC_MEMORY_H__ */
> diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
> index 9ce788d..3b9d5b6 100644
> --- a/include/xen/interface/physdev.h
> +++ b/include/xen/interface/physdev.h
> @@ -258,6 +258,16 @@ struct physdev_pci_device {
>      uint8_t devfn;
>  };
>  
> +#define PHYSDEVOP_pvh_map_iomem        30
> +struct physdev_map_iomem {
> +    /* IN */
> +    uint64_t first_gfn;
> +    uint64_t first_mfn;
> +    uint32_t nr_mfns;
> +    uint32_t add_mapping;        /* 1 == add mapping;  0 == unmap */
> +
> +};
> +
>  /*
>   * Notify that some PIRQ-bound event channels have been unmasked.
>   * ** This command is obsolete since interface version 0x00030202 and is **
> -- 
> 1.7.2.3

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 13:27:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 13:27:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPCbv-0003wY-Of; Fri, 19 Oct 2012 13:27:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPCbt-0003wQ-LU
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 13:27:33 +0000
Received: from [85.158.139.211:5636] by server-9.bemta-5.messagelabs.com id
	C9/53-23053-44551805; Fri, 19 Oct 2012 13:27:32 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1350653251!22948628!1
X-Originating-IP: [216.32.180.31]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15571 invoked from network); 19 Oct 2012 13:27:32 -0000
Received: from va3ehsobe005.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.31)
	by server-10.tower-206.messagelabs.com with AES128-SHA encrypted SMTP;
	19 Oct 2012 13:27:32 -0000
Received: from mail199-va3-R.bigfish.com (10.7.14.237) by
	VA3EHSOBE011.bigfish.com (10.7.40.61) with Microsoft SMTP Server id
	14.1.225.23; Fri, 19 Oct 2012 13:27:31 +0000
Received: from mail199-va3 (localhost [127.0.0.1])	by
	mail199-va3-R.bigfish.com (Postfix) with ESMTP id EBF7846009D;
	Fri, 19 Oct 2012 13:27:30 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: -4
X-BigFish: VPS-4(z551bizbb2dI98dI9371I1432I4015Izz1202h1d1ah1d2ahzz8275bhz2dh668h839he5bhf0ah107ah1288h12a5h12a9h12bdh137ah13b6h1441h1155h)
Received: from mail199-va3 (localhost.localdomain [127.0.0.1]) by mail199-va3
	(MessageSwitch) id 1350653249274706_28427;
	Fri, 19 Oct 2012 13:27:29 +0000 (UTC)
Received: from VA3EHSMHS013.bigfish.com (unknown [10.7.14.245])	by
	mail199-va3.bigfish.com (Postfix) with ESMTP id 3B8E018021B;
	Fri, 19 Oct 2012 13:27:29 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS013.bigfish.com (10.7.99.23) with Microsoft SMTP Server id
	14.1.225.23; Fri, 19 Oct 2012 13:27:21 +0000
X-WSS-ID: 0MC56PD-02-92K-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 21558C80C5;	Fri, 19 Oct 2012 08:27:13 -0500 (CDT)
Received: from SAUSEXDAG06.amd.com (163.181.55.7) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 19 Oct 2012 08:43:15 -0500
Received: from STOREXDAG02.amd.com (10.1.13.11) by sausexdag06.amd.com
	(163.181.55.7) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Fri, 19 Oct 2012 08:27:17 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexdag02.amd.com
	(10.1.13.11) with Microsoft SMTP Server id 14.1.323.3; Fri, 19 Oct 2012
	09:27:16 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 15A9949C69B; Fri, 19 Oct 2012
	14:27:16 +0100 (BST)
Message-ID: <50815551.2010303@amd.com>
Date: Fri, 19 Oct 2012 15:27:45 +0200
From: Wei Wang 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120421 Thunderbird/12.0
MIME-Version: 1.0
To: Jan Beulich 
References: <508136CD02000078000A2888@nat28.tlf.novell.com>
In-Reply-To: <508136CD02000078000A2888@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: xen-devel 
Subject: Re: [Xen-devel] [PATCH] IOMMU: fail HPET MSI setup on AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/19/2012 11:17 AM, Jan Beulich wrote:
> While the MSI message format doesn't need adjustment for AMD IOMMUs,
> the interrupt remapping tables still need updating. The respective code
> has to be able to determine the IOMMU responsible, which currently
> requires an associated PCI device. The absence of that device in the
> HPET case causes the code to crash, and the code determining the source
> ID to be used for HPETs (parse_ivhd_device_special() afaict) isn't even
> looking at whether it's dealing with an IO-APIC or a HPET (i.e. ignores
> the "variety" structure member). If I tried to fix that, I would have
> no way to test that I did things right, so all I can do to fix the
> crash is make the setup fail if the IOMMU did not provide a handler
> (which, considering the above, is the right thing anyway).
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -498,7 +498,7 @@ unsigned int iommu_read_apic_from_ire(un
>   int __init iommu_setup_hpet_msi(struct msi_desc *msi)
>   {
>       const struct iommu_ops *ops = iommu_get_ops();
> -    return ops->setup_hpet_msi ? ops->setup_hpet_msi(msi) : 0;
> +    return ops->setup_hpet_msi ? ops->setup_hpet_msi(msi) : -ENODEV;
>   }
>
>   void iommu_resume()
>
>
>

Acked, I will work on AMD part for HPET MSI remapping.

Thanks,
Wei


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 13:27:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 13:27:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPCbv-0003wY-Of; Fri, 19 Oct 2012 13:27:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPCbt-0003wQ-LU
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 13:27:33 +0000
Received: from [85.158.139.211:5636] by server-9.bemta-5.messagelabs.com id
	C9/53-23053-44551805; Fri, 19 Oct 2012 13:27:32 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1350653251!22948628!1
X-Originating-IP: [216.32.180.31]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15571 invoked from network); 19 Oct 2012 13:27:32 -0000
Received: from va3ehsobe005.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.31)
	by server-10.tower-206.messagelabs.com with AES128-SHA encrypted SMTP;
	19 Oct 2012 13:27:32 -0000
Received: from mail199-va3-R.bigfish.com (10.7.14.237) by
	VA3EHSOBE011.bigfish.com (10.7.40.61) with Microsoft SMTP Server id
	14.1.225.23; Fri, 19 Oct 2012 13:27:31 +0000
Received: from mail199-va3 (localhost [127.0.0.1])	by
	mail199-va3-R.bigfish.com (Postfix) with ESMTP id EBF7846009D;
	Fri, 19 Oct 2012 13:27:30 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: -4
X-BigFish: VPS-4(z551bizbb2dI98dI9371I1432I4015Izz1202h1d1ah1d2ahzz8275bhz2dh668h839he5bhf0ah107ah1288h12a5h12a9h12bdh137ah13b6h1441h1155h)
Received: from mail199-va3 (localhost.localdomain [127.0.0.1]) by mail199-va3
	(MessageSwitch) id 1350653249274706_28427;
	Fri, 19 Oct 2012 13:27:29 +0000 (UTC)
Received: from VA3EHSMHS013.bigfish.com (unknown [10.7.14.245])	by
	mail199-va3.bigfish.com (Postfix) with ESMTP id 3B8E018021B;
	Fri, 19 Oct 2012 13:27:29 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS013.bigfish.com (10.7.99.23) with Microsoft SMTP Server id
	14.1.225.23; Fri, 19 Oct 2012 13:27:21 +0000
X-WSS-ID: 0MC56PD-02-92K-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 21558C80C5;	Fri, 19 Oct 2012 08:27:13 -0500 (CDT)
Received: from SAUSEXDAG06.amd.com (163.181.55.7) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 19 Oct 2012 08:43:15 -0500
Received: from STOREXDAG02.amd.com (10.1.13.11) by sausexdag06.amd.com
	(163.181.55.7) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Fri, 19 Oct 2012 08:27:17 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexdag02.amd.com
	(10.1.13.11) with Microsoft SMTP Server id 14.1.323.3; Fri, 19 Oct 2012
	09:27:16 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 15A9949C69B; Fri, 19 Oct 2012
	14:27:16 +0100 (BST)
Message-ID: <50815551.2010303@amd.com>
Date: Fri, 19 Oct 2012 15:27:45 +0200
From: Wei Wang 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120421 Thunderbird/12.0
MIME-Version: 1.0
To: Jan Beulich 
References: <508136CD02000078000A2888@nat28.tlf.novell.com>
In-Reply-To: <508136CD02000078000A2888@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: xen-devel 
Subject: Re: [Xen-devel] [PATCH] IOMMU: fail HPET MSI setup on AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/19/2012 11:17 AM, Jan Beulich wrote:
> While the MSI message format doesn't need adjustment for AMD IOMMUs,
> the interrupt remapping tables still need updating. The respective code
> has to be able to determine the IOMMU responsible, which currently
> requires an associated PCI device. The absence of that device in the
> HPET case causes the code to crash, and the code determining the source
> ID to be used for HPETs (parse_ivhd_device_special() afaict) isn't even
> looking at whether it's dealing with an IO-APIC or a HPET (i.e. ignores
> the "variety" structure member). If I tried to fix that, I would have
> no way to test that I did things right, so all I can do to fix the
> crash is make the setup fail if the IOMMU did not provide a handler
> (which, considering the above, is the right thing anyway).
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -498,7 +498,7 @@ unsigned int iommu_read_apic_from_ire(un
>   int __init iommu_setup_hpet_msi(struct msi_desc *msi)
>   {
>       const struct iommu_ops *ops = iommu_get_ops();
> -    return ops->setup_hpet_msi ? ops->setup_hpet_msi(msi) : 0;
> +    return ops->setup_hpet_msi ? ops->setup_hpet_msi(msi) : -ENODEV;
>   }
>
>   void iommu_resume()
>
>
>

Acked, I will work on AMD part for HPET MSI remapping.

Thanks,
Wei


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 13:29:40 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 13:29:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPCdi-00041l-8x; Fri, 19 Oct 2012 13:29:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPCdg-00041c-N1
	for Xen-devel@lists.xensource.com; Fri, 19 Oct 2012 13:29:25 +0000
Received: from [85.158.138.51:58281] by server-2.bemta-3.messagelabs.com id
	13/38-00604-FA551805; Fri, 19 Oct 2012 13:29:19 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1350653357!33335452!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODE1Njg1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1000 invoked from network); 19 Oct 2012 13:29:19 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Oct 2012 13:29:19 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9JDTDW9016125
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Oct 2012 13:29:14 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9JDTC2k013650
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 19 Oct 2012 13:29:13 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9JDTCa3028834; Fri, 19 Oct 2012 08:29:12 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Oct 2012 06:29:11 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 499D34035B; Fri, 19 Oct 2012 09:17:07 -0400 (EDT)
Date: Fri, 19 Oct 2012 09:17:07 -0400
From: Konrad Rzeszutek Wilk 
To: Stefano Stabellini 
Message-ID: <20121019131707.GG26830@phenom.dumpdata.com>
References: <20121017172642.349b2aae@mantra.us.oracle.com>
	
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" 
Subject: Re: [Xen-devel] [PATCH V3 1/6]: PVH: basic and header changes,
 elfnote changes, ...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > +config XEN_X86_PVH
> > +	bool "Support for running as a PVH guest (EXPERIMENTAL)"
> > +	depends on X86_64 && XEN && EXPERIMENTAL
> > +	default n
> > +	help
> > +	   This option enables support for running as a PVH guest (PV guest
> > +	   using hardware extensions) under a suitably capable hypervisor.
> > +	   This option is EXPERIMENTAL because the hypervisor interfaces
> > +	   which it uses are not yet considered stable therefore backwards and
> > +	   forwards compatibility is not yet guaranteed.  If unsure, say N.
> 
> Do we really need the kconfig symbol? Why can't we have it always

Yes for right now. That is to make sure that we can test for regressions
PV guests on a hypervisor without PVH extensions - or vice-versa:
PVH hypervisors with an normal PV guest.

Until most bugs and the other work is completed this is a bit of a safety
valve, in case we mess up.

> enabled?

You know what Linus's thinks about the 'y' be default. He usually rips
one's behind for that - especially for this which is still in its infancy
period. Later on when we get bugs and kinks worked out then we can
re-evaluate.

> 
> 
> > diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
> > index 7faed58..1a6bca1 100644
> > --- a/arch/x86/xen/xen-head.S
> > +++ b/arch/x86/xen/xen-head.S
> > @@ -13,6 +13,15 @@
> >  #include 
> >  #include 
> >  
> > +#ifdef CONFIG_XEN_X86_PVH
> > +#define FEATURES_PVH "|writable_descriptor_tables" \
> > +		     "|auto_translated_physmap" \
> > +		     "|supervisor_mode_kernel" \
> > +		     "|hvm_callback_vector"
> > +#else
> > +#define FEATURES_PVH /* Not supported */
> > +#endif
> > +
> >  	__INIT
> >  ENTRY(startup_xen)
> >  	cld
> > @@ -95,7 +104,7 @@ NEXT_HYPERCALL(arch_6)
> >  #endif
> >  	ELFNOTE(Xen, XEN_ELFNOTE_ENTRY,          _ASM_PTR startup_xen)
> >  	ELFNOTE(Xen, XEN_ELFNOTE_HYPERCALL_PAGE, _ASM_PTR hypercall_page)
> > -	ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,       .asciz "!writable_page_tables|pae_pgdir_above_4gb")
> > +	ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,       .asciz "!writable_page_tables|pae_pgdir_above_4gb"FEATURES_PVH)
> >  	ELFNOTE(Xen, XEN_ELFNOTE_PAE_MODE,       .asciz "yes")
> >  	ELFNOTE(Xen, XEN_ELFNOTE_LOADER,         .asciz "generic")
> >  	ELFNOTE(Xen, XEN_ELFNOTE_L1_MFN_VALID,
> 
> Considering that the PVH capability ends up in an ELF note, the kconfig
> symbol is actually useful at least for debugging: it is the only way to
> disable it from the guest side. However I would imaging that Xen would
> always provide an option to disable PVH features in a VM or dom0.

Right.
> 
> 
> > diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
> > index d8e33a9..425911f 100644
> > --- a/include/xen/interface/memory.h
> > +++ b/include/xen/interface/memory.h
> > @@ -169,7 +169,13 @@ struct xen_add_to_physmap {
> >      /* Source mapping space. */
> >  #define XENMAPSPACE_shared_info 0 /* shared info page */
> >  #define XENMAPSPACE_grant_table 1 /* grant table page */
> > -    unsigned int space;
> > +#define XENMAPSPACE_gmfn        2 /* GMFN */
> > +#define XENMAPSPACE_gmfn_range  3 /* GMFN range */
> > +#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */
> > +    uint16_t space;
> > +    domid_t foreign_domid;         /* IFF XENMAPSPACE_gmfn_foreign */
> > +
> > +#define XENMAPIDX_grant_table_status 0x80000000
> >  
> >      /* Index into source mapping space. */
> >      unsigned long idx;
> > @@ -237,4 +243,20 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_memory_map);
> >   * during a driver critical region.
> >   */
> >  extern spinlock_t xen_reservation_lock;
> > +
> > +/*
> > + * Unmaps the page appearing at a particular GPFN from the specified guest's
> > + * pseudophysical address space.
> > + * arg == addr of xen_remove_from_physmap_t.
> > + */
> > +#define XENMEM_remove_from_physmap      15
> > +struct xen_remove_from_physmap {
> > +    /* Which domain to change the mapping for. */
> > +    domid_t domid;
> > +
> > +    /* GPFN of the current mapping of the page. */
> > +    xen_pfn_t gpfn;
> > +};
> > +DEFINE_GUEST_HANDLE_STRUCT(xen_remove_from_physmap);
> > +
> >  #endif /* __XEN_PUBLIC_MEMORY_H__ */
> 
> these bits have been submitted separately by Ian, if I am not mistaken.

I can take of care of doing the merge/conflict resolution.

> 
> 
> > diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
> > index 9ce788d..3b9d5b6 100644
> > --- a/include/xen/interface/physdev.h
> > +++ b/include/xen/interface/physdev.h
> > @@ -258,6 +258,16 @@ struct physdev_pci_device {
> >      uint8_t devfn;
> >  };
> >  
> > +#define PHYSDEVOP_pvh_map_iomem        30
> 
> I would just call this PHYSDEVOP_map_iomem, we might use it on non-PVH
> guests as well one day.

I completely lost track of the naming now :-( Isn't the ARM version
called range something?
> 
> 
> > +struct physdev_map_iomem {
> > +    /* IN */
> > +    uint64_t first_gfn;
> > +    uint64_t first_mfn;
> > +    uint32_t nr_mfns;
> > +    uint32_t add_mapping;        /* 1 == add mapping;  0 == unmap */
> > +
> > +};
> > +
> >  /*
> >   * Notify that some PIRQ-bound event channels have been unmasked.
> >   * ** This command is obsolete since interface version 0x00030202 and is **
> > -- 
> > 1.7.2.3
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> > 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 13:29:40 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 13:29:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPCdi-00041l-8x; Fri, 19 Oct 2012 13:29:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPCdg-00041c-N1
	for Xen-devel@lists.xensource.com; Fri, 19 Oct 2012 13:29:25 +0000
Received: from [85.158.138.51:58281] by server-2.bemta-3.messagelabs.com id
	13/38-00604-FA551805; Fri, 19 Oct 2012 13:29:19 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1350653357!33335452!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODE1Njg1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1000 invoked from network); 19 Oct 2012 13:29:19 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Oct 2012 13:29:19 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9JDTDW9016125
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Oct 2012 13:29:14 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9JDTC2k013650
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 19 Oct 2012 13:29:13 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9JDTCa3028834; Fri, 19 Oct 2012 08:29:12 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Oct 2012 06:29:11 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 499D34035B; Fri, 19 Oct 2012 09:17:07 -0400 (EDT)
Date: Fri, 19 Oct 2012 09:17:07 -0400
From: Konrad Rzeszutek Wilk 
To: Stefano Stabellini 
Message-ID: <20121019131707.GG26830@phenom.dumpdata.com>
References: <20121017172642.349b2aae@mantra.us.oracle.com>
	
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" 
Subject: Re: [Xen-devel] [PATCH V3 1/6]: PVH: basic and header changes,
 elfnote changes, ...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > +config XEN_X86_PVH
> > +	bool "Support for running as a PVH guest (EXPERIMENTAL)"
> > +	depends on X86_64 && XEN && EXPERIMENTAL
> > +	default n
> > +	help
> > +	   This option enables support for running as a PVH guest (PV guest
> > +	   using hardware extensions) under a suitably capable hypervisor.
> > +	   This option is EXPERIMENTAL because the hypervisor interfaces
> > +	   which it uses are not yet considered stable therefore backwards and
> > +	   forwards compatibility is not yet guaranteed.  If unsure, say N.
> 
> Do we really need the kconfig symbol? Why can't we have it always

Yes for right now. That is to make sure that we can test for regressions
PV guests on a hypervisor without PVH extensions - or vice-versa:
PVH hypervisors with an normal PV guest.

Until most bugs and the other work is completed this is a bit of a safety
valve, in case we mess up.

> enabled?

You know what Linus's thinks about the 'y' be default. He usually rips
one's behind for that - especially for this which is still in its infancy
period. Later on when we get bugs and kinks worked out then we can
re-evaluate.

> 
> 
> > diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
> > index 7faed58..1a6bca1 100644
> > --- a/arch/x86/xen/xen-head.S
> > +++ b/arch/x86/xen/xen-head.S
> > @@ -13,6 +13,15 @@
> >  #include 
> >  #include 
> >  
> > +#ifdef CONFIG_XEN_X86_PVH
> > +#define FEATURES_PVH "|writable_descriptor_tables" \
> > +		     "|auto_translated_physmap" \
> > +		     "|supervisor_mode_kernel" \
> > +		     "|hvm_callback_vector"
> > +#else
> > +#define FEATURES_PVH /* Not supported */
> > +#endif
> > +
> >  	__INIT
> >  ENTRY(startup_xen)
> >  	cld
> > @@ -95,7 +104,7 @@ NEXT_HYPERCALL(arch_6)
> >  #endif
> >  	ELFNOTE(Xen, XEN_ELFNOTE_ENTRY,          _ASM_PTR startup_xen)
> >  	ELFNOTE(Xen, XEN_ELFNOTE_HYPERCALL_PAGE, _ASM_PTR hypercall_page)
> > -	ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,       .asciz "!writable_page_tables|pae_pgdir_above_4gb")
> > +	ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,       .asciz "!writable_page_tables|pae_pgdir_above_4gb"FEATURES_PVH)
> >  	ELFNOTE(Xen, XEN_ELFNOTE_PAE_MODE,       .asciz "yes")
> >  	ELFNOTE(Xen, XEN_ELFNOTE_LOADER,         .asciz "generic")
> >  	ELFNOTE(Xen, XEN_ELFNOTE_L1_MFN_VALID,
> 
> Considering that the PVH capability ends up in an ELF note, the kconfig
> symbol is actually useful at least for debugging: it is the only way to
> disable it from the guest side. However I would imaging that Xen would
> always provide an option to disable PVH features in a VM or dom0.

Right.
> 
> 
> > diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
> > index d8e33a9..425911f 100644
> > --- a/include/xen/interface/memory.h
> > +++ b/include/xen/interface/memory.h
> > @@ -169,7 +169,13 @@ struct xen_add_to_physmap {
> >      /* Source mapping space. */
> >  #define XENMAPSPACE_shared_info 0 /* shared info page */
> >  #define XENMAPSPACE_grant_table 1 /* grant table page */
> > -    unsigned int space;
> > +#define XENMAPSPACE_gmfn        2 /* GMFN */
> > +#define XENMAPSPACE_gmfn_range  3 /* GMFN range */
> > +#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */
> > +    uint16_t space;
> > +    domid_t foreign_domid;         /* IFF XENMAPSPACE_gmfn_foreign */
> > +
> > +#define XENMAPIDX_grant_table_status 0x80000000
> >  
> >      /* Index into source mapping space. */
> >      unsigned long idx;
> > @@ -237,4 +243,20 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_memory_map);
> >   * during a driver critical region.
> >   */
> >  extern spinlock_t xen_reservation_lock;
> > +
> > +/*
> > + * Unmaps the page appearing at a particular GPFN from the specified guest's
> > + * pseudophysical address space.
> > + * arg == addr of xen_remove_from_physmap_t.
> > + */
> > +#define XENMEM_remove_from_physmap      15
> > +struct xen_remove_from_physmap {
> > +    /* Which domain to change the mapping for. */
> > +    domid_t domid;
> > +
> > +    /* GPFN of the current mapping of the page. */
> > +    xen_pfn_t gpfn;
> > +};
> > +DEFINE_GUEST_HANDLE_STRUCT(xen_remove_from_physmap);
> > +
> >  #endif /* __XEN_PUBLIC_MEMORY_H__ */
> 
> these bits have been submitted separately by Ian, if I am not mistaken.

I can take of care of doing the merge/conflict resolution.

> 
> 
> > diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
> > index 9ce788d..3b9d5b6 100644
> > --- a/include/xen/interface/physdev.h
> > +++ b/include/xen/interface/physdev.h
> > @@ -258,6 +258,16 @@ struct physdev_pci_device {
> >      uint8_t devfn;
> >  };
> >  
> > +#define PHYSDEVOP_pvh_map_iomem        30
> 
> I would just call this PHYSDEVOP_map_iomem, we might use it on non-PVH
> guests as well one day.

I completely lost track of the naming now :-( Isn't the ARM version
called range something?
> 
> 
> > +struct physdev_map_iomem {
> > +    /* IN */
> > +    uint64_t first_gfn;
> > +    uint64_t first_mfn;
> > +    uint32_t nr_mfns;
> > +    uint32_t add_mapping;        /* 1 == add mapping;  0 == unmap */
> > +
> > +};
> > +
> >  /*
> >   * Notify that some PIRQ-bound event channels have been unmasked.
> >   * ** This command is obsolete since interface version 0x00030202 and is **
> > -- 
> > 1.7.2.3
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> > 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 13:31:49 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 13:31:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPCfo-0004AG-QP; Fri, 19 Oct 2012 13:31:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPCfn-0004A8-4b
	for Xen-devel@lists.xensource.com; Fri, 19 Oct 2012 13:31:35 +0000
Received: from [85.158.143.35:35213] by server-2.bemta-4.messagelabs.com id
	F4/93-22268-63651805; Fri, 19 Oct 2012 13:31:34 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1350653487!15746083!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgyMjgwMg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26313 invoked from network); 19 Oct 2012 13:31:29 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Oct 2012 13:31:29 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9JDVMJJ027834
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Oct 2012 13:31:23 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9JDVMaI009144
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 19 Oct 2012 13:31:22 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9JDVMP3030512; Fri, 19 Oct 2012 08:31:22 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Oct 2012 06:31:21 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 29A984035B; Fri, 19 Oct 2012 09:19:17 -0400 (EDT)
Date: Fri, 19 Oct 2012 09:19:17 -0400
From: Konrad Rzeszutek Wilk 
To: Stefano Stabellini 
Message-ID: <20121019131917.GH26830@phenom.dumpdata.com>
References: <20121017173327.6994152e@mantra.us.oracle.com>
	
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" 
Subject: Re: [Xen-devel] [PATCH V3 5/6]: PVH:balloon and grant changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Oct 18, 2012 at 12:44:16PM +0100, Stefano Stabellini wrote:
> On Thu, 18 Oct 2012, Mukesh Rathor wrote:
> > PVH: balloon and grant changes. For balloon changes we skip setting of local p2m as it's updated in xen. For grant, the shared grant frame is the pfn and not mfn, hence its mapped via the same code path as HVM
> > 
> > Signed-off-by: Mukesh Rathor 
> 
> this patch looks good

Allright! We got an ACK!! Five more to go :-)

> 
> 
> >  drivers/xen/balloon.c     |   15 +++++++++------
> >  drivers/xen/gntdev.c      |    3 ++-
> >  drivers/xen/grant-table.c |   26 ++++++++++++++++++++++----
> >  3 files changed, 33 insertions(+), 11 deletions(-)
> > 
> > diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> > index 31ab82f..c825b63 100644
> > --- a/drivers/xen/balloon.c
> > +++ b/drivers/xen/balloon.c
> > @@ -361,7 +361,9 @@ static enum bp_state increase_reservation(unsigned long nr_pages)
> >  		set_phys_to_machine(pfn, frame_list[i]);
> >  
> >  		/* Link back into the page tables if not highmem. */
> > -		if (xen_pv_domain() && !PageHighMem(page)) {
> > +		if (xen_pv_domain() && !PageHighMem(page) &&
> > +		    !xen_feature(XENFEAT_auto_translated_physmap)) {
> > +
> >  			int ret;
> >  			ret = HYPERVISOR_update_va_mapping(
> >  				(unsigned long)__va(pfn << PAGE_SHIFT),
> > @@ -418,12 +420,13 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
> >  		scrub_page(page);
> >  
> >  		if (xen_pv_domain() && !PageHighMem(page)) {
> > -			ret = HYPERVISOR_update_va_mapping(
> > -				(unsigned long)__va(pfn << PAGE_SHIFT),
> > -				__pte_ma(0), 0);
> > -			BUG_ON(ret);
> > +			if (!xen_feature(XENFEAT_auto_translated_physmap)) {
> > +				ret = HYPERVISOR_update_va_mapping(
> > +					(unsigned long)__va(pfn << PAGE_SHIFT),
> > +					__pte_ma(0), 0);
> > +				BUG_ON(ret);
> > +			}
> >  		}
> > -
> >  	}
> >  
> >  	/* Ensure that ballooned highmem pages don't have kmaps. */
> > diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
> > index 5df9fd8..36ec380 100644
> > --- a/drivers/xen/gntdev.c
> > +++ b/drivers/xen/gntdev.c
> > @@ -803,7 +803,8 @@ static int __init gntdev_init(void)
> >  	if (!xen_domain())
> >  		return -ENODEV;
> >  
> > -	use_ptemod = xen_pv_domain();
> > +	use_ptemod = xen_pv_domain() &&
> > +		     !xen_feature(XENFEAT_auto_translated_physmap);
> >  
> >  	err = misc_register(&gntdev_miscdev);
> >  	if (err != 0) {
> > diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> > index f37faf6..1b851fa 100644
> > --- a/drivers/xen/grant-table.c
> > +++ b/drivers/xen/grant-table.c
> > @@ -976,14 +976,19 @@ static void gnttab_unmap_frames_v2(void)
> >  static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
> >  {
> >  	struct gnttab_setup_table setup;
> > -	unsigned long *frames;
> > +	unsigned long *frames, start_gpfn;
> >  	unsigned int nr_gframes = end_idx + 1;
> >  	int rc;
> >  
> > -	if (xen_hvm_domain()) {
> > +	if (xen_hvm_domain() || xen_feature(XENFEAT_auto_translated_physmap)) {
> >  		struct xen_add_to_physmap xatp;
> >  		unsigned int i = end_idx;
> >  		rc = 0;
> > +
> > +		if (xen_hvm_domain())
> > +			start_gpfn = xen_hvm_resume_frames >> PAGE_SHIFT;
> > +		else
> > +			start_gpfn = virt_to_pfn(gnttab_shared.addr);
> >  		/*
> >  		 * Loop backwards, so that the first hypercall has the largest
> >  		 * index, ensuring that the table will grow only once.
> > @@ -992,7 +997,7 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
> >  			xatp.domid = DOMID_SELF;
> >  			xatp.idx = i;
> >  			xatp.space = XENMAPSPACE_grant_table;
> > -			xatp.gpfn = (xen_hvm_resume_frames >> PAGE_SHIFT) + i;
> > +			xatp.gpfn = start_gpfn + i;
> >  			rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
> >  			if (rc != 0) {
> >  				printk(KERN_WARNING
> > @@ -1055,7 +1060,7 @@ static void gnttab_request_version(void)
> >  	int rc;
> >  	struct gnttab_set_version gsv;
> >  
> > -	if (xen_hvm_domain())
> > +	if (xen_hvm_domain() || xen_feature(XENFEAT_auto_translated_physmap))
> >  		gsv.version = 1;
> >  	else
> >  		gsv.version = 2;
> > @@ -1083,12 +1088,25 @@ static void gnttab_request_version(void)
> >  int gnttab_resume(void)
> >  {
> >  	unsigned int max_nr_gframes;
> > +	char *kmsg = "Failed to kmalloc pages for pv in hvm grant frames\n";
> >  
> >  	gnttab_request_version();
> >  	max_nr_gframes = gnttab_max_grant_frames();
> >  	if (max_nr_gframes < nr_grant_frames)
> >  		return -ENOSYS;
> >  
> > +	/* PVH note: xen will free existing kmalloc'd mfn in
> > +	 * XENMEM_add_to_physmap. TBD/FIXME: use xen ballooning instead of
> > +	 * kmalloc(). */
> > +	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap) &&
> > +	    !gnttab_shared.addr) {
> > +		gnttab_shared.addr =
> > +			kmalloc(max_nr_gframes * PAGE_SIZE, GFP_KERNEL);
> > +		if (!gnttab_shared.addr) {
> > +			pr_warn("%s", kmsg);
> > +			return -ENOMEM;
> > +		}
> > +	}
> >  	if (xen_pv_domain())
> >  		return gnttab_map(0, nr_grant_frames - 1);
> >  
> > -- 
> > 1.7.2.3
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> > 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 13:31:49 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 13:31:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPCfo-0004AG-QP; Fri, 19 Oct 2012 13:31:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPCfn-0004A8-4b
	for Xen-devel@lists.xensource.com; Fri, 19 Oct 2012 13:31:35 +0000
Received: from [85.158.143.35:35213] by server-2.bemta-4.messagelabs.com id
	F4/93-22268-63651805; Fri, 19 Oct 2012 13:31:34 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1350653487!15746083!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgyMjgwMg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26313 invoked from network); 19 Oct 2012 13:31:29 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Oct 2012 13:31:29 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9JDVMJJ027834
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Oct 2012 13:31:23 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9JDVMaI009144
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 19 Oct 2012 13:31:22 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9JDVMP3030512; Fri, 19 Oct 2012 08:31:22 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Oct 2012 06:31:21 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 29A984035B; Fri, 19 Oct 2012 09:19:17 -0400 (EDT)
Date: Fri, 19 Oct 2012 09:19:17 -0400
From: Konrad Rzeszutek Wilk 
To: Stefano Stabellini 
Message-ID: <20121019131917.GH26830@phenom.dumpdata.com>
References: <20121017173327.6994152e@mantra.us.oracle.com>
	
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" 
Subject: Re: [Xen-devel] [PATCH V3 5/6]: PVH:balloon and grant changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Oct 18, 2012 at 12:44:16PM +0100, Stefano Stabellini wrote:
> On Thu, 18 Oct 2012, Mukesh Rathor wrote:
> > PVH: balloon and grant changes. For balloon changes we skip setting of local p2m as it's updated in xen. For grant, the shared grant frame is the pfn and not mfn, hence its mapped via the same code path as HVM
> > 
> > Signed-off-by: Mukesh Rathor 
> 
> this patch looks good

Allright! We got an ACK!! Five more to go :-)

> 
> 
> >  drivers/xen/balloon.c     |   15 +++++++++------
> >  drivers/xen/gntdev.c      |    3 ++-
> >  drivers/xen/grant-table.c |   26 ++++++++++++++++++++++----
> >  3 files changed, 33 insertions(+), 11 deletions(-)
> > 
> > diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> > index 31ab82f..c825b63 100644
> > --- a/drivers/xen/balloon.c
> > +++ b/drivers/xen/balloon.c
> > @@ -361,7 +361,9 @@ static enum bp_state increase_reservation(unsigned long nr_pages)
> >  		set_phys_to_machine(pfn, frame_list[i]);
> >  
> >  		/* Link back into the page tables if not highmem. */
> > -		if (xen_pv_domain() && !PageHighMem(page)) {
> > +		if (xen_pv_domain() && !PageHighMem(page) &&
> > +		    !xen_feature(XENFEAT_auto_translated_physmap)) {
> > +
> >  			int ret;
> >  			ret = HYPERVISOR_update_va_mapping(
> >  				(unsigned long)__va(pfn << PAGE_SHIFT),
> > @@ -418,12 +420,13 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
> >  		scrub_page(page);
> >  
> >  		if (xen_pv_domain() && !PageHighMem(page)) {
> > -			ret = HYPERVISOR_update_va_mapping(
> > -				(unsigned long)__va(pfn << PAGE_SHIFT),
> > -				__pte_ma(0), 0);
> > -			BUG_ON(ret);
> > +			if (!xen_feature(XENFEAT_auto_translated_physmap)) {
> > +				ret = HYPERVISOR_update_va_mapping(
> > +					(unsigned long)__va(pfn << PAGE_SHIFT),
> > +					__pte_ma(0), 0);
> > +				BUG_ON(ret);
> > +			}
> >  		}
> > -
> >  	}
> >  
> >  	/* Ensure that ballooned highmem pages don't have kmaps. */
> > diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
> > index 5df9fd8..36ec380 100644
> > --- a/drivers/xen/gntdev.c
> > +++ b/drivers/xen/gntdev.c
> > @@ -803,7 +803,8 @@ static int __init gntdev_init(void)
> >  	if (!xen_domain())
> >  		return -ENODEV;
> >  
> > -	use_ptemod = xen_pv_domain();
> > +	use_ptemod = xen_pv_domain() &&
> > +		     !xen_feature(XENFEAT_auto_translated_physmap);
> >  
> >  	err = misc_register(&gntdev_miscdev);
> >  	if (err != 0) {
> > diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> > index f37faf6..1b851fa 100644
> > --- a/drivers/xen/grant-table.c
> > +++ b/drivers/xen/grant-table.c
> > @@ -976,14 +976,19 @@ static void gnttab_unmap_frames_v2(void)
> >  static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
> >  {
> >  	struct gnttab_setup_table setup;
> > -	unsigned long *frames;
> > +	unsigned long *frames, start_gpfn;
> >  	unsigned int nr_gframes = end_idx + 1;
> >  	int rc;
> >  
> > -	if (xen_hvm_domain()) {
> > +	if (xen_hvm_domain() || xen_feature(XENFEAT_auto_translated_physmap)) {
> >  		struct xen_add_to_physmap xatp;
> >  		unsigned int i = end_idx;
> >  		rc = 0;
> > +
> > +		if (xen_hvm_domain())
> > +			start_gpfn = xen_hvm_resume_frames >> PAGE_SHIFT;
> > +		else
> > +			start_gpfn = virt_to_pfn(gnttab_shared.addr);
> >  		/*
> >  		 * Loop backwards, so that the first hypercall has the largest
> >  		 * index, ensuring that the table will grow only once.
> > @@ -992,7 +997,7 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
> >  			xatp.domid = DOMID_SELF;
> >  			xatp.idx = i;
> >  			xatp.space = XENMAPSPACE_grant_table;
> > -			xatp.gpfn = (xen_hvm_resume_frames >> PAGE_SHIFT) + i;
> > +			xatp.gpfn = start_gpfn + i;
> >  			rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
> >  			if (rc != 0) {
> >  				printk(KERN_WARNING
> > @@ -1055,7 +1060,7 @@ static void gnttab_request_version(void)
> >  	int rc;
> >  	struct gnttab_set_version gsv;
> >  
> > -	if (xen_hvm_domain())
> > +	if (xen_hvm_domain() || xen_feature(XENFEAT_auto_translated_physmap))
> >  		gsv.version = 1;
> >  	else
> >  		gsv.version = 2;
> > @@ -1083,12 +1088,25 @@ static void gnttab_request_version(void)
> >  int gnttab_resume(void)
> >  {
> >  	unsigned int max_nr_gframes;
> > +	char *kmsg = "Failed to kmalloc pages for pv in hvm grant frames\n";
> >  
> >  	gnttab_request_version();
> >  	max_nr_gframes = gnttab_max_grant_frames();
> >  	if (max_nr_gframes < nr_grant_frames)
> >  		return -ENOSYS;
> >  
> > +	/* PVH note: xen will free existing kmalloc'd mfn in
> > +	 * XENMEM_add_to_physmap. TBD/FIXME: use xen ballooning instead of
> > +	 * kmalloc(). */
> > +	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap) &&
> > +	    !gnttab_shared.addr) {
> > +		gnttab_shared.addr =
> > +			kmalloc(max_nr_gframes * PAGE_SIZE, GFP_KERNEL);
> > +		if (!gnttab_shared.addr) {
> > +			pr_warn("%s", kmsg);
> > +			return -ENOMEM;
> > +		}
> > +	}
> >  	if (xen_pv_domain())
> >  		return gnttab_map(0, nr_grant_frames - 1);
> >  
> > -- 
> > 1.7.2.3
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> > 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 14:03:47 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 14:03:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPDAb-0004oO-Fr; Fri, 19 Oct 2012 14:03:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPDAa-0004oG-3W
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 14:03:24 +0000
Received: from [85.158.143.35:18771] by server-1.bemta-4.messagelabs.com id
	5B/83-19134-BAD51805; Fri, 19 Oct 2012 14:03:23 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1350655402!3940655!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13110 invoked from network); 19 Oct 2012 14:03:22 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-5.tower-21.messagelabs.com with SMTP;
	19 Oct 2012 14:03:22 -0000
Received: from p5b2e238c.dip.t-dialin.net ([91.46.35.140] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from )
	id 1TPDAT-0003yl-Qo; Fri, 19 Oct 2012 14:03:17 +0000
Message-ID: <50815DA1.10303@canonical.com>
Date: Fri, 19 Oct 2012 16:03:13 +0200
From: Stefan Bader 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Jan Beulich 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
	<1350482118.2460.74.camel@zakaz.uk.xensource.com>
	<507ECD06.2050407@canonical.com> <507ED038.8000806@citrix.com>
	<507FC51102000078000A235E@nat28.tlf.novell.com>
	<507FC71502000078000A236C@nat28.tlf.novell.com>
	<507FB1E1.8080700@canonical.com>
	<1350546483.28188.25.camel@dagon.hellion.org.uk>
	<507FD7DE.2010209@canonical.com>
	<507FFA5102000078000A250D@nat28.tlf.novell.com>
	<507FF964.9090009@canonical.com> <50806C0B.1060504@canonical.com>
	<5081264002000078000A2841@nat28.tlf.novell.com>
	<50811047.4080200@canonical.com>
	<5081387B02000078000A288D@nat28.tlf.novell.com>
In-Reply-To: <5081387B02000078000A288D@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.5
Cc: Andrew Cooper ,
	"xen-devel@lists.xen.org" ,
	Ian Campbell ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1550538253537960605=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============1550538253537960605==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig6155E8BB71A4A409BC8AC38D"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig6155E8BB71A4A409BC8AC38D
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 19.10.2012 11:24, Jan Beulich wrote:
>>>> On 19.10.12 at 10:33, Stefan Bader  wrot=
e:
>> On 19.10.2012 10:06, Jan Beulich wrote:
>>>>>> On 18.10.12 at 22:52, Stefan Bader 
>>>>>> wrote:
>>>> Actually I begin to suspect that it could be possible that I just
>>>> overlooked
>>=20
>>>> the most obvious thing. Provoking question: are we sure we are on th=
e
>>>> same page about the purpose of the spin_lock_flags variant of the pv=

>>>> lock ops interface?
>>>>=20
>>>> I begin to suspect that it really is not for giving a chance to
>>>> re-enable interrupts. Just what it should be used for I am not clear=
=2E
>>>> Anyway it seems all other places more or less ignore the flags and m=
ap
>>>> themselves back to an ignorant version of spinlock. Also I believe t=
hat
>>>> the only high level function that would end up in passing any flags,=

>>>> would be the spin_lock_irqsave one. And I am pretty sure that this o=
ne
>>>> will expect interrupts to stay disabled.
>>>=20
>>> No - the only requirement here is that from the point on where the lo=
ck
>>> is owned interrupt must remain disabled. Re-enabling intermediately i=
s
>>> quite okay (and used to be done by the native kernel prior to the
>>> conversion to ticket locks iirc).
>>=20
>> Though it seems rather dangerous then. Don't remember the old code, bu=
t imo
>>  it always opens up a (even microscopic) window to unexpected
>> interruptions.
>=20
> There just can't be unexpected interruptions. Whenever interrupts are
> enabled, it is expected that they can occur.

Probably one thing that makes things a bit more complicated is that in th=
e PVM
case interrupts maps to vcpu->evtchn_upcall_mask.

>=20
>>>> So I tried below approach and that seems to be surviving the previou=
sly
>>>>  breaking testcase for much longer than anything I tried before.
>>>=20
>>> If that indeed fixes your problem, then (minus eventual problems with=
 the
>>> scope of the interrupts-enabled window) this rather points at a bug i=
n
>>> the users of the spinlock interfaces.
>>=20
>> I would be pragmatic here, none of the other current implementations s=
eem
>> to re-enable interrupts and so this only affects xen pv.
>=20
> I don't think you really checked - the first arch I looked at (s390, as=
 being
> the most obvious one to look at when it comes to virtualization) quite
> prominently re-enableds interrupts in arch_spin_lock_wait_flags().

No, I assumed that you saying native kernel did prior to ticket lock conv=
ersion,
that this involves more historic search. And yes s390 is doing virtualiza=
tion
quite a bit back into history. Just not paravirtualization.
And when I look at arch_spin_lock_wait_flags() enabling/disabling is done=
 close
by (at least I am not leaving off into some hypercall fog).

>=20
>> And how much really is gained from enabling it compared to the risk of=

>> being affected by something that nobody else will be?
>=20
> The main difference between the native and virtualized cases is that th=
e
> period of time you spend waiting for the lock to become available is pr=
etty
> much unbounded (even more so without ticket locks), and keeping interru=
pts
> disabled for such an extended period of time is just going to ask for o=
ther
> problems.

So not sure I followed all of the right paths here, but I think xen_poll_=
irq
ends up doing a hypercall via syscall. Syscall seems to mask of some bits=
 of the
flags (maybe irq) but certainly that will not translate automatically int=
o the
upcall mask.
Then, again hopefully the right place, in the mini-os part, the
hypervisor_callback there is some annotation about leaving the events mas=
ked off
until having checked for being already interrupted. Could be the same mas=
k that
is checked here that the guest has cleared to enable interrupts... Would =
that be
expected?

>=20
> And note that this isn't the case just for Xen PV - all virtualization =

> scenarios suffer from that.
>=20
> Jan
>=20
>=20
> _______________________________________________ Xen-devel mailing list =

> Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
>=20



--------------enig6155E8BB71A4A409BC8AC38D
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBCgAGBQJQgV2iAAoJEOhnXe7L7s6jnSAQAMq1+YooxH+c51fR0OKfk2FV
hr5DPD4nRUpvyxXu/Z/la9csOeAONflQpsZiYp9v0UmxWkHkXrldXQTC3tX2rjNJ
ZrkIJEpK5caImdchrtcO5fdxDS5QCyh9qrIRvOOqCaRscnmtvgaWIBm8lc5jklrT
1QjBZwTk8dkVtafw1uC3R4B8U7WvA/QCTza47u2whkd8RKDGVYTfdjH4z4LlU3SC
jhYtYrwV8GfdaU+U9bWfHP6nmmywIDHsr3guaSjowNPmDzWMCRbNrrWsPgvnG0GL
sW9B6FO/v+P6MRa8mpn/raTmAr9DkGS12sLdm5msZ2/3jfhtpVD6vs9MkundpMNj
8IpDIgNAvTpsIyZUR6boUSa/Icz3wGFuFCeKeEcXrtb3IeTpwqb/HNXiHlaI8Ado
ug0kwLFd+9PmDfBHsbVIoaAWuRJmzEvQUt4RMR0N6MfJhVyZtT+ttYInEqrD9dNU
nnGeWTFnsRY5ce1cJdTdo+GAKh+UO+dZ5UHdR6msIX4Mg4xff11pCnguCGjvlgkd
umEEG5U+a4DV2xl0DnQjHEcIMo4zH8tvsq7NpRVbBS5e7aLgXpTXN+Ie73FBdg4w
z0r6TEkF7uR3ZdlHotZy34uj2EhirIDSGqtgErqHy6QIiD+xlMDqb7sogpYNZ5yj
01OxpQvRosMfyRbaajCZ
=OdpA
-----END PGP SIGNATURE-----

--------------enig6155E8BB71A4A409BC8AC38D--


--===============1550538253537960605==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1550538253537960605==--


From xen-devel-bounces@lists.xen.org Fri Oct 19 14:03:47 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 14:03:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPDAb-0004oO-Fr; Fri, 19 Oct 2012 14:03:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPDAa-0004oG-3W
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 14:03:24 +0000
Received: from [85.158.143.35:18771] by server-1.bemta-4.messagelabs.com id
	5B/83-19134-BAD51805; Fri, 19 Oct 2012 14:03:23 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1350655402!3940655!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13110 invoked from network); 19 Oct 2012 14:03:22 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-5.tower-21.messagelabs.com with SMTP;
	19 Oct 2012 14:03:22 -0000
Received: from p5b2e238c.dip.t-dialin.net ([91.46.35.140] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from )
	id 1TPDAT-0003yl-Qo; Fri, 19 Oct 2012 14:03:17 +0000
Message-ID: <50815DA1.10303@canonical.com>
Date: Fri, 19 Oct 2012 16:03:13 +0200
From: Stefan Bader 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Jan Beulich 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
	<1350482118.2460.74.camel@zakaz.uk.xensource.com>
	<507ECD06.2050407@canonical.com> <507ED038.8000806@citrix.com>
	<507FC51102000078000A235E@nat28.tlf.novell.com>
	<507FC71502000078000A236C@nat28.tlf.novell.com>
	<507FB1E1.8080700@canonical.com>
	<1350546483.28188.25.camel@dagon.hellion.org.uk>
	<507FD7DE.2010209@canonical.com>
	<507FFA5102000078000A250D@nat28.tlf.novell.com>
	<507FF964.9090009@canonical.com> <50806C0B.1060504@canonical.com>
	<5081264002000078000A2841@nat28.tlf.novell.com>
	<50811047.4080200@canonical.com>
	<5081387B02000078000A288D@nat28.tlf.novell.com>
In-Reply-To: <5081387B02000078000A288D@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.5
Cc: Andrew Cooper ,
	"xen-devel@lists.xen.org" ,
	Ian Campbell ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1550538253537960605=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============1550538253537960605==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig6155E8BB71A4A409BC8AC38D"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig6155E8BB71A4A409BC8AC38D
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 19.10.2012 11:24, Jan Beulich wrote:
>>>> On 19.10.12 at 10:33, Stefan Bader  wrot=
e:
>> On 19.10.2012 10:06, Jan Beulich wrote:
>>>>>> On 18.10.12 at 22:52, Stefan Bader 
>>>>>> wrote:
>>>> Actually I begin to suspect that it could be possible that I just
>>>> overlooked
>>=20
>>>> the most obvious thing. Provoking question: are we sure we are on th=
e
>>>> same page about the purpose of the spin_lock_flags variant of the pv=

>>>> lock ops interface?
>>>>=20
>>>> I begin to suspect that it really is not for giving a chance to
>>>> re-enable interrupts. Just what it should be used for I am not clear=
=2E
>>>> Anyway it seems all other places more or less ignore the flags and m=
ap
>>>> themselves back to an ignorant version of spinlock. Also I believe t=
hat
>>>> the only high level function that would end up in passing any flags,=

>>>> would be the spin_lock_irqsave one. And I am pretty sure that this o=
ne
>>>> will expect interrupts to stay disabled.
>>>=20
>>> No - the only requirement here is that from the point on where the lo=
ck
>>> is owned interrupt must remain disabled. Re-enabling intermediately i=
s
>>> quite okay (and used to be done by the native kernel prior to the
>>> conversion to ticket locks iirc).
>>=20
>> Though it seems rather dangerous then. Don't remember the old code, bu=
t imo
>>  it always opens up a (even microscopic) window to unexpected
>> interruptions.
>=20
> There just can't be unexpected interruptions. Whenever interrupts are
> enabled, it is expected that they can occur.

Probably one thing that makes things a bit more complicated is that in th=
e PVM
case interrupts maps to vcpu->evtchn_upcall_mask.

>=20
>>>> So I tried below approach and that seems to be surviving the previou=
sly
>>>>  breaking testcase for much longer than anything I tried before.
>>>=20
>>> If that indeed fixes your problem, then (minus eventual problems with=
 the
>>> scope of the interrupts-enabled window) this rather points at a bug i=
n
>>> the users of the spinlock interfaces.
>>=20
>> I would be pragmatic here, none of the other current implementations s=
eem
>> to re-enable interrupts and so this only affects xen pv.
>=20
> I don't think you really checked - the first arch I looked at (s390, as=
 being
> the most obvious one to look at when it comes to virtualization) quite
> prominently re-enableds interrupts in arch_spin_lock_wait_flags().

No, I assumed that you saying native kernel did prior to ticket lock conv=
ersion,
that this involves more historic search. And yes s390 is doing virtualiza=
tion
quite a bit back into history. Just not paravirtualization.
And when I look at arch_spin_lock_wait_flags() enabling/disabling is done=
 close
by (at least I am not leaving off into some hypercall fog).

>=20
>> And how much really is gained from enabling it compared to the risk of=

>> being affected by something that nobody else will be?
>=20
> The main difference between the native and virtualized cases is that th=
e
> period of time you spend waiting for the lock to become available is pr=
etty
> much unbounded (even more so without ticket locks), and keeping interru=
pts
> disabled for such an extended period of time is just going to ask for o=
ther
> problems.

So not sure I followed all of the right paths here, but I think xen_poll_=
irq
ends up doing a hypercall via syscall. Syscall seems to mask of some bits=
 of the
flags (maybe irq) but certainly that will not translate automatically int=
o the
upcall mask.
Then, again hopefully the right place, in the mini-os part, the
hypervisor_callback there is some annotation about leaving the events mas=
ked off
until having checked for being already interrupted. Could be the same mas=
k that
is checked here that the guest has cleared to enable interrupts... Would =
that be
expected?

>=20
> And note that this isn't the case just for Xen PV - all virtualization =

> scenarios suffer from that.
>=20
> Jan
>=20
>=20
> _______________________________________________ Xen-devel mailing list =

> Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
>=20



--------------enig6155E8BB71A4A409BC8AC38D
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBCgAGBQJQgV2iAAoJEOhnXe7L7s6jnSAQAMq1+YooxH+c51fR0OKfk2FV
hr5DPD4nRUpvyxXu/Z/la9csOeAONflQpsZiYp9v0UmxWkHkXrldXQTC3tX2rjNJ
ZrkIJEpK5caImdchrtcO5fdxDS5QCyh9qrIRvOOqCaRscnmtvgaWIBm8lc5jklrT
1QjBZwTk8dkVtafw1uC3R4B8U7WvA/QCTza47u2whkd8RKDGVYTfdjH4z4LlU3SC
jhYtYrwV8GfdaU+U9bWfHP6nmmywIDHsr3guaSjowNPmDzWMCRbNrrWsPgvnG0GL
sW9B6FO/v+P6MRa8mpn/raTmAr9DkGS12sLdm5msZ2/3jfhtpVD6vs9MkundpMNj
8IpDIgNAvTpsIyZUR6boUSa/Icz3wGFuFCeKeEcXrtb3IeTpwqb/HNXiHlaI8Ado
ug0kwLFd+9PmDfBHsbVIoaAWuRJmzEvQUt4RMR0N6MfJhVyZtT+ttYInEqrD9dNU
nnGeWTFnsRY5ce1cJdTdo+GAKh+UO+dZ5UHdR6msIX4Mg4xff11pCnguCGjvlgkd
umEEG5U+a4DV2xl0DnQjHEcIMo4zH8tvsq7NpRVbBS5e7aLgXpTXN+Ie73FBdg4w
z0r6TEkF7uR3ZdlHotZy34uj2EhirIDSGqtgErqHy6QIiD+xlMDqb7sogpYNZ5yj
01OxpQvRosMfyRbaajCZ
=OdpA
-----END PGP SIGNATURE-----

--------------enig6155E8BB71A4A409BC8AC38D--


--===============1550538253537960605==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1550538253537960605==--


From xen-devel-bounces@lists.xen.org Fri Oct 19 14:10:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 14:10:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPDGi-00052d-I0; Fri, 19 Oct 2012 14:09:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPDGg-00052W-RV
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 14:09:43 +0000
Received: from [85.158.139.83:40717] by server-9.bemta-5.messagelabs.com id
	FA/17-23053-62F51805; Fri, 19 Oct 2012 14:09:42 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-182.messagelabs.com!1350655781!35613296!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0NDA5NzE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0NDA5NzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17287 invoked from network); 19 Oct 2012 14:09:41 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Oct 2012 14:09:41 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGiC0MEcre
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-086-220.pools.arcor-ip.net [88.65.86.220])
	by smtp.strato.de (jorabe mo41) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id i05eaeo9JDOqKi
	for ; Fri, 19 Oct 2012 16:09:41 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id D7084183A7
	for ; Fri, 19 Oct 2012 16:09:40 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 8ebe7b80f02900d5a83e023c2833de26b70f3ff1
Message-Id: <8ebe7b80f02900d5a83e.1350655780@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Fri, 19 Oct 2012 16:09:40 +0200
From: Olaf Hering 
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] hvm: handle PoD and grant pages in
	HVMOP_get_mem_type
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering 
# Date 1350655745 -7200
# Node ID 8ebe7b80f02900d5a83e023c2833de26b70f3ff1
# Parent  3fa2ab30bb05297f30d9a33b30f29db960900971
hvm: handle PoD and grant pages in HVMOP_get_mem_type

During kexec in a ballooned PVonHVM guest the new kernel needs to check
each pfn if its backed by a mfn to find ballooned pages. Currently all
PoD and grant pages will appear as HVMMEM_mmio_dm, so the new kernel has
to assume they are ballooned. This is wrong: PoD pages may turn into
real RAM at runtime, grant pages are also RAM.

Signed-off-by: Olaf Hering 

diff -r 3fa2ab30bb05 -r 8ebe7b80f029 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4086,6 +4086,10 @@ long do_hvm_op(unsigned long op, XEN_GUE
                 a.mem_type =  HVMMEM_ram_ro;
             else if ( p2m_is_ram(t) )
                 a.mem_type =  HVMMEM_ram_rw;
+            else if ( p2m_is_magic(t) )
+                a.mem_type =  HVMMEM_ram_rw;
+            else if ( p2m_is_grant(t) )
+                a.mem_type =  HVMMEM_ram_rw;
             else
                 a.mem_type =  HVMMEM_mmio_dm;
             rc = copy_to_guest(arg, &a, 1) ? -EFAULT : 0;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 14:10:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 14:10:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPDGi-00052d-I0; Fri, 19 Oct 2012 14:09:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPDGg-00052W-RV
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 14:09:43 +0000
Received: from [85.158.139.83:40717] by server-9.bemta-5.messagelabs.com id
	FA/17-23053-62F51805; Fri, 19 Oct 2012 14:09:42 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-182.messagelabs.com!1350655781!35613296!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0NDA5NzE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0NDA5NzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17287 invoked from network); 19 Oct 2012 14:09:41 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Oct 2012 14:09:41 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGiC0MEcre
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-086-220.pools.arcor-ip.net [88.65.86.220])
	by smtp.strato.de (jorabe mo41) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id i05eaeo9JDOqKi
	for ; Fri, 19 Oct 2012 16:09:41 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id D7084183A7
	for ; Fri, 19 Oct 2012 16:09:40 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 8ebe7b80f02900d5a83e023c2833de26b70f3ff1
Message-Id: <8ebe7b80f02900d5a83e.1350655780@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Fri, 19 Oct 2012 16:09:40 +0200
From: Olaf Hering 
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] hvm: handle PoD and grant pages in
	HVMOP_get_mem_type
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering 
# Date 1350655745 -7200
# Node ID 8ebe7b80f02900d5a83e023c2833de26b70f3ff1
# Parent  3fa2ab30bb05297f30d9a33b30f29db960900971
hvm: handle PoD and grant pages in HVMOP_get_mem_type

During kexec in a ballooned PVonHVM guest the new kernel needs to check
each pfn if its backed by a mfn to find ballooned pages. Currently all
PoD and grant pages will appear as HVMMEM_mmio_dm, so the new kernel has
to assume they are ballooned. This is wrong: PoD pages may turn into
real RAM at runtime, grant pages are also RAM.

Signed-off-by: Olaf Hering 

diff -r 3fa2ab30bb05 -r 8ebe7b80f029 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4086,6 +4086,10 @@ long do_hvm_op(unsigned long op, XEN_GUE
                 a.mem_type =  HVMMEM_ram_ro;
             else if ( p2m_is_ram(t) )
                 a.mem_type =  HVMMEM_ram_rw;
+            else if ( p2m_is_magic(t) )
+                a.mem_type =  HVMMEM_ram_rw;
+            else if ( p2m_is_grant(t) )
+                a.mem_type =  HVMMEM_ram_rw;
             else
                 a.mem_type =  HVMMEM_mmio_dm;
             rc = copy_to_guest(arg, &a, 1) ? -EFAULT : 0;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 14:15:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 14:15:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPDLe-0005Be-Vb; Fri, 19 Oct 2012 14:14:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPDLd-0005BQ-JV
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 14:14:49 +0000
Received: from [85.158.138.51:29952] by server-15.bemta-3.messagelabs.com id
	50/65-10261-85061805; Fri, 19 Oct 2012 14:14:48 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-174.messagelabs.com!1350656088!27098146!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0NDA5NzE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0NDA5NzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21596 invoked from network); 19 Oct 2012 14:14:48 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Oct 2012 14:14:48 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGiC0MEcre
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-086-220.pools.arcor-ip.net [88.65.86.220])
	by smtp.strato.de (jored mo20) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id z06763o9JED4sM
	for ; Fri, 19 Oct 2012 16:14:48 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 9248B18642; Fri, 19 Oct 2012 16:14:47 +0200 (CEST)
Date: Fri, 19 Oct 2012 16:14:47 +0200
From: Olaf Hering 
To: xen-devel@lists.xen.org
Message-ID: <20121019141447.GA12321@aepfle.de>
References: <8ebe7b80f02900d5a83e.1350655780@probook.site>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <8ebe7b80f02900d5a83e.1350655780@probook.site>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Subject: Re: [Xen-devel] [PATCH] hvm: handle PoD and grant pages in
 HVMOP_get_mem_type
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 19, Olaf Hering wrote:

> +            else if ( p2m_is_grant(t) )

I'm not sure if p2m_is_grant() can be true in a HVM guest.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 14:15:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 14:15:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPDLe-0005Be-Vb; Fri, 19 Oct 2012 14:14:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPDLd-0005BQ-JV
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 14:14:49 +0000
Received: from [85.158.138.51:29952] by server-15.bemta-3.messagelabs.com id
	50/65-10261-85061805; Fri, 19 Oct 2012 14:14:48 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-174.messagelabs.com!1350656088!27098146!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0NDA5NzE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0NDA5NzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21596 invoked from network); 19 Oct 2012 14:14:48 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Oct 2012 14:14:48 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGiC0MEcre
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-086-220.pools.arcor-ip.net [88.65.86.220])
	by smtp.strato.de (jored mo20) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id z06763o9JED4sM
	for ; Fri, 19 Oct 2012 16:14:48 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 9248B18642; Fri, 19 Oct 2012 16:14:47 +0200 (CEST)
Date: Fri, 19 Oct 2012 16:14:47 +0200
From: Olaf Hering 
To: xen-devel@lists.xen.org
Message-ID: <20121019141447.GA12321@aepfle.de>
References: <8ebe7b80f02900d5a83e.1350655780@probook.site>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <8ebe7b80f02900d5a83e.1350655780@probook.site>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Subject: Re: [Xen-devel] [PATCH] hvm: handle PoD and grant pages in
 HVMOP_get_mem_type
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 19, Olaf Hering wrote:

> +            else if ( p2m_is_grant(t) )

I'm not sure if p2m_is_grant() can be true in a HVM guest.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 14:27:22 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 14:27:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPDXX-0005ec-DQ; Fri, 19 Oct 2012 14:27:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPDXV-0005eX-Pp
	for xen-devel@lists.xensource.com; Fri, 19 Oct 2012 14:27:05 +0000
Received: from [193.109.254.147:12512] by server-2.bemta-14.messagelabs.com id
	99/01-19917-93361805; Fri, 19 Oct 2012 14:27:05 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1350656822!13332832!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgyMjgwMg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28900 invoked from network); 19 Oct 2012 14:27:03 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Oct 2012 14:27:03 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9JEQw2Y030193
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Oct 2012 14:26:58 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9JEQvm2027187
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 19 Oct 2012 14:26:58 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9JEQv9r020584; Fri, 19 Oct 2012 09:26:57 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Oct 2012 07:26:57 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 402E34035B; Fri, 19 Oct 2012 10:14:53 -0400 (EDT)
Date: Fri, 19 Oct 2012 10:14:53 -0400
From: Konrad Rzeszutek Wilk 
To: Justin Gibbs 
Message-ID: <20121019141453.GL26830@phenom.dumpdata.com>
References: 
	<20120817172838.GA3515@phenom.dumpdata.com>
	
	<61DFA8800400A143A5A7C5E136A726DC5F867490@reactor.sldomain.com>
	<20120925152600.GA967@phenom.dumpdata.com>
	
	<20121018145030.GD19782@localhost.localdomain>
	<61DFA8800400A143A5A7C5E136A726DC5F9D0C67@reactor.sldomain.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <61DFA8800400A143A5A7C5E136A726DC5F9D0C67@reactor.sldomain.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "Duan, Ronghui" ,
	"xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] xen-vbd interface (segment size expansion) -
 FreeBSD host have it.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Oct 18, 2012 at 03:34:27PM +0000, Justin Gibbs wrote:
> On Oct 18, 2012, at 8:50 AM, Konrad Rzeszutek Wilk 
>  wrote:
> 
> > On Thu, Oct 18, 2012 at 01:59:36AM +0000, Duan, Ronghui wrote:
> >> Hi, I am back from a long holiday. Sorry for the delay replay.
> >>> I was wondering how the protocol you developed works when it comes to
> >>> migration to a host that does not support the new features?
> >>> 
> >> For my part, when VM migrate to a host which do not support larger segments, frontend will fall back to use original protocol with old-segments 11.
> >> 
> >>> Specifically how do deal with a guest which tries to replay in progress I/Os
> >>> that do not fit within the old-segment size (11)?
> >> The in-progress bio which have larger segments > 11 will receive an io error. I do not find a better way to handle it yet.
> > 
> > Justin, how did you guys handle it in FreeBSD? Or is it dependent on
> > the backends always supporting these large segments?
> 
> The current API forces I/Os larger than 44k to get chopped up in
> order to transit blkif.  The ability to negotiate a larger blkif
> request size just means that you can sometimes reduce the amount
> of "scatter-gather" work performed by the driver.  You must still
> deal with the fact that a logical I/O submitted to blkfront may
> need to be broken up, or may not completely fit within the size of
> the negotiated ring.  Upon reconnect, the newly negotiated parameters
> are in effect and reissued I/Os are subject to the rules that apply
> to that connection.
> I'd have to go review the FreeBSD blkfront driver to see if it
> handles correctly all of the issues that arise with a ring that
> shrinks (e.g. it may assume that an I/O will fit within an empty
> ring), but there is certainly no technical reason that these issues
> can't be addressed.

OK, so the one issue I keep on circling back to is there an benefit
of doing a seperate ring for segments - as opposed of re-using the existing
ring and just shrinking/expanding the number of segments?

I do like re-using the ring and just shrinking/expanding it b/c it
ends up being all neatly tucked inside the existing ring.


> 
> --
> Justin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 14:27:22 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 14:27:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPDXX-0005ec-DQ; Fri, 19 Oct 2012 14:27:07 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPDXV-0005eX-Pp
	for xen-devel@lists.xensource.com; Fri, 19 Oct 2012 14:27:05 +0000
Received: from [193.109.254.147:12512] by server-2.bemta-14.messagelabs.com id
	99/01-19917-93361805; Fri, 19 Oct 2012 14:27:05 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1350656822!13332832!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgyMjgwMg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28900 invoked from network); 19 Oct 2012 14:27:03 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Oct 2012 14:27:03 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9JEQw2Y030193
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Oct 2012 14:26:58 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9JEQvm2027187
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 19 Oct 2012 14:26:58 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9JEQv9r020584; Fri, 19 Oct 2012 09:26:57 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Oct 2012 07:26:57 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 402E34035B; Fri, 19 Oct 2012 10:14:53 -0400 (EDT)
Date: Fri, 19 Oct 2012 10:14:53 -0400
From: Konrad Rzeszutek Wilk 
To: Justin Gibbs 
Message-ID: <20121019141453.GL26830@phenom.dumpdata.com>
References: 
	<20120817172838.GA3515@phenom.dumpdata.com>
	
	<61DFA8800400A143A5A7C5E136A726DC5F867490@reactor.sldomain.com>
	<20120925152600.GA967@phenom.dumpdata.com>
	
	<20121018145030.GD19782@localhost.localdomain>
	<61DFA8800400A143A5A7C5E136A726DC5F9D0C67@reactor.sldomain.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <61DFA8800400A143A5A7C5E136A726DC5F9D0C67@reactor.sldomain.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "Duan, Ronghui" ,
	"xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] xen-vbd interface (segment size expansion) -
 FreeBSD host have it.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Oct 18, 2012 at 03:34:27PM +0000, Justin Gibbs wrote:
> On Oct 18, 2012, at 8:50 AM, Konrad Rzeszutek Wilk 
>  wrote:
> 
> > On Thu, Oct 18, 2012 at 01:59:36AM +0000, Duan, Ronghui wrote:
> >> Hi, I am back from a long holiday. Sorry for the delay replay.
> >>> I was wondering how the protocol you developed works when it comes to
> >>> migration to a host that does not support the new features?
> >>> 
> >> For my part, when VM migrate to a host which do not support larger segments, frontend will fall back to use original protocol with old-segments 11.
> >> 
> >>> Specifically how do deal with a guest which tries to replay in progress I/Os
> >>> that do not fit within the old-segment size (11)?
> >> The in-progress bio which have larger segments > 11 will receive an io error. I do not find a better way to handle it yet.
> > 
> > Justin, how did you guys handle it in FreeBSD? Or is it dependent on
> > the backends always supporting these large segments?
> 
> The current API forces I/Os larger than 44k to get chopped up in
> order to transit blkif.  The ability to negotiate a larger blkif
> request size just means that you can sometimes reduce the amount
> of "scatter-gather" work performed by the driver.  You must still
> deal with the fact that a logical I/O submitted to blkfront may
> need to be broken up, or may not completely fit within the size of
> the negotiated ring.  Upon reconnect, the newly negotiated parameters
> are in effect and reissued I/Os are subject to the rules that apply
> to that connection.
> I'd have to go review the FreeBSD blkfront driver to see if it
> handles correctly all of the issues that arise with a ring that
> shrinks (e.g. it may assume that an I/O will fit within an empty
> ring), but there is certainly no technical reason that these issues
> can't be addressed.

OK, so the one issue I keep on circling back to is there an benefit
of doing a seperate ring for segments - as opposed of re-using the existing
ring and just shrinking/expanding the number of segments?

I do like re-using the ring and just shrinking/expanding it b/c it
ends up being all neatly tucked inside the existing ring.


> 
> --
> Justin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 14:28:51 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 14:28:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPDYy-0005kc-U2; Fri, 19 Oct 2012 14:28:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPDYx-0005kU-Pt
	for xen-devel@lists.xensource.com; Fri, 19 Oct 2012 14:28:36 +0000
Received: from [85.158.138.51:62712] by server-14.bemta-3.messagelabs.com id
	16/B6-17276-29361805; Fri, 19 Oct 2012 14:28:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1350656913!27006358!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUwMDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25103 invoked from network); 19 Oct 2012 14:28:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 14:28:34 -0000
X-IronPort-AV: E=Sophos;i="4.80,612,1344211200"; d="scan'208";a="15278758"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 14:28:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 19 Oct 2012 15:28:31 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TPDYt-0000Lf-2d;
	Fri, 19 Oct 2012 14:28:31 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TPDYs-0002KK-Sd;
	Fri, 19 Oct 2012 15:28:30 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Fri, 19 Oct 2012 15:28:30 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14062: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14062 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14062/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 13967
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 13967
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 13967
 build-amd64-oldkern           4 xen-build        fail in 14038 REGR. vs. 13967

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                    fail pass in 14038
 test-amd64-i386-xl            5 xen-boot                    fail pass in 14045
 test-amd64-i386-pv            5 xen-boot                    fail pass in 14057
 test-amd64-amd64-pair         8 xen-boot/dst_host           fail pass in 14045
 test-amd64-amd64-pair         7 xen-boot/src_host           fail pass in 14045

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13967
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13967
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13967
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13967

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  3fa2ab30bb05
baseline version:
 xen                  c1c549c4fe9e

------------------------------------------------------------
People who touched revisions under test:
  Chuang Cao 
  Daniel De Graaf 
  Huang Ying 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Joe Jin 
  Keir Fraser 
  Olaf Hering 
  Sander Eikelenboom 
  Stefano Stabellini 
  Tim Deegan 
  Xiantao Zhang
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 592 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 14:28:51 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 14:28:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPDYy-0005kc-U2; Fri, 19 Oct 2012 14:28:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPDYx-0005kU-Pt
	for xen-devel@lists.xensource.com; Fri, 19 Oct 2012 14:28:36 +0000
Received: from [85.158.138.51:62712] by server-14.bemta-3.messagelabs.com id
	16/B6-17276-29361805; Fri, 19 Oct 2012 14:28:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1350656913!27006358!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUwMDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25103 invoked from network); 19 Oct 2012 14:28:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 14:28:34 -0000
X-IronPort-AV: E=Sophos;i="4.80,612,1344211200"; d="scan'208";a="15278758"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 14:28:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 19 Oct 2012 15:28:31 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TPDYt-0000Lf-2d;
	Fri, 19 Oct 2012 14:28:31 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TPDYs-0002KK-Sd;
	Fri, 19 Oct 2012 15:28:30 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Fri, 19 Oct 2012 15:28:30 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14062: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14062 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14062/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 13967
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 13967
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 13967
 build-amd64-oldkern           4 xen-build        fail in 14038 REGR. vs. 13967

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                    fail pass in 14038
 test-amd64-i386-xl            5 xen-boot                    fail pass in 14045
 test-amd64-i386-pv            5 xen-boot                    fail pass in 14057
 test-amd64-amd64-pair         8 xen-boot/dst_host           fail pass in 14045
 test-amd64-amd64-pair         7 xen-boot/src_host           fail pass in 14045

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13967
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13967
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13967
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13967

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  3fa2ab30bb05
baseline version:
 xen                  c1c549c4fe9e

------------------------------------------------------------
People who touched revisions under test:
  Chuang Cao 
  Daniel De Graaf 
  Huang Ying 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Joe Jin 
  Keir Fraser 
  Olaf Hering 
  Sander Eikelenboom 
  Stefano Stabellini 
  Tim Deegan 
  Xiantao Zhang
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 592 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 14:33:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 14:33:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPDdV-0005xS-Lo; Fri, 19 Oct 2012 14:33:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPDdT-0005xH-QS; Fri, 19 Oct 2012 14:33:16 +0000
Received: from [85.158.143.99:33496] by server-1.bemta-4.messagelabs.com id
	A8/EA-19134-BA461805; Fri, 19 Oct 2012 14:33:15 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1350657193!34454172!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODE1Njg1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26790 invoked from network); 19 Oct 2012 14:33:14 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Oct 2012 14:33:14 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9JEX6kW029273
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Oct 2012 14:33:07 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9JEX5Uh019283
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 19 Oct 2012 14:33:06 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9JEX5Vr000963; Fri, 19 Oct 2012 09:33:05 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Oct 2012 07:33:05 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id A0A314035B; Fri, 19 Oct 2012 10:21:00 -0400 (EDT)
Date: Fri, 19 Oct 2012 10:21:00 -0400
From: Konrad Rzeszutek Wilk 
To: Stefano Stabellini 
Message-ID: <20121019142100.GN26830@phenom.dumpdata.com>
References: 
	<1350466992.2460.47.camel@zakaz.uk.xensource.com>
	
	<1350568154.2460.151.camel@zakaz.uk.xensource.com>
	
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "xen-users@lists.xen.org" ,
	kk s , Ian Campbell ,
	xen-devel 
Subject: Re: [Xen-devel] [Xen-users] Fedora 17 Dom-U booting issue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Oct 18, 2012 at 05:21:06PM +0100, Stefano Stabellini wrote:
> On Thu, 18 Oct 2012, Ian Campbell wrote:
> > On Thu, 2012-10-18 at 14:42 +0100, Stefano Stabellini wrote:
> > > On Wed, 17 Oct 2012, Ian Campbell wrote:
> > > > Adding xen-devel and the relevant maintainers.
> > > > 
> > > > On Tue, 2012-10-16 at 20:24 +0100, kk s wrote:
> > > > > Hi Folks,
> > > > > 
> > > > > 
> > > > > I have upgraded Fedora 16 to 17 on one of Xen HVM Dom-U and it refuses
> > > > > to boot fine and getting the below error on console,
> > > > > 
> > > > > 
> > > > > --------
> > > > > Booting 'Fedora (3.6.1-1.fc17.x86_64)'
> > > > > 
> > > > > 
> > > > > Loading Fedora (3.6.1-1.fc17.x86_64)
> > > > > Loading initial ramdisk ...
> > > > > [   0.000000] Cannot get hvm parameter 18: -22!
> > > > 
> > > > HVM parameter 18 is HVM_PARAM_CONSOLE_EVTCHN.
> > > 
> > > -22 is EINVAL, that Xen would return only if:
> > > 
> > > - the requested parameter is out of range
> > > this is not the case, 18 < 30
> > 
> > The hypervisor here is 3.4.3 where the largest hvm param is:
> > $ grep define.HVM_PARAM xen-3.4-testing.hg/xen/include/public/hvm/params.h | sort -k3 -n | tail -n 3
> > #define HVM_PARAM_ACPI_S_STATE 14
> > #define HVM_PARAM_VM86_TSS     15
> > #define HVM_PARAM_VPT_ALIGN    16
> 
> OK, we know that the console is not working because it is not provided
> by the hypervisor.
> However that shouldn't prevent the domain from booting, the emulated
> serial should work fine.

Maybe it does? Mr. KK can you boot your guest with this in guest config:

serial='pty'

and on your Linux line, do 'loglevel=8 initcall_debug console=ttyS0,115200 debug' please?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 14:33:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 14:33:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPDdV-0005xS-Lo; Fri, 19 Oct 2012 14:33:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPDdT-0005xH-QS; Fri, 19 Oct 2012 14:33:16 +0000
Received: from [85.158.143.99:33496] by server-1.bemta-4.messagelabs.com id
	A8/EA-19134-BA461805; Fri, 19 Oct 2012 14:33:15 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1350657193!34454172!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODE1Njg1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26790 invoked from network); 19 Oct 2012 14:33:14 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Oct 2012 14:33:14 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9JEX6kW029273
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Oct 2012 14:33:07 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9JEX5Uh019283
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 19 Oct 2012 14:33:06 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9JEX5Vr000963; Fri, 19 Oct 2012 09:33:05 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Oct 2012 07:33:05 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id A0A314035B; Fri, 19 Oct 2012 10:21:00 -0400 (EDT)
Date: Fri, 19 Oct 2012 10:21:00 -0400
From: Konrad Rzeszutek Wilk 
To: Stefano Stabellini 
Message-ID: <20121019142100.GN26830@phenom.dumpdata.com>
References: 
	<1350466992.2460.47.camel@zakaz.uk.xensource.com>
	
	<1350568154.2460.151.camel@zakaz.uk.xensource.com>
	
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "xen-users@lists.xen.org" ,
	kk s , Ian Campbell ,
	xen-devel 
Subject: Re: [Xen-devel] [Xen-users] Fedora 17 Dom-U booting issue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Oct 18, 2012 at 05:21:06PM +0100, Stefano Stabellini wrote:
> On Thu, 18 Oct 2012, Ian Campbell wrote:
> > On Thu, 2012-10-18 at 14:42 +0100, Stefano Stabellini wrote:
> > > On Wed, 17 Oct 2012, Ian Campbell wrote:
> > > > Adding xen-devel and the relevant maintainers.
> > > > 
> > > > On Tue, 2012-10-16 at 20:24 +0100, kk s wrote:
> > > > > Hi Folks,
> > > > > 
> > > > > 
> > > > > I have upgraded Fedora 16 to 17 on one of Xen HVM Dom-U and it refuses
> > > > > to boot fine and getting the below error on console,
> > > > > 
> > > > > 
> > > > > --------
> > > > > Booting 'Fedora (3.6.1-1.fc17.x86_64)'
> > > > > 
> > > > > 
> > > > > Loading Fedora (3.6.1-1.fc17.x86_64)
> > > > > Loading initial ramdisk ...
> > > > > [   0.000000] Cannot get hvm parameter 18: -22!
> > > > 
> > > > HVM parameter 18 is HVM_PARAM_CONSOLE_EVTCHN.
> > > 
> > > -22 is EINVAL, that Xen would return only if:
> > > 
> > > - the requested parameter is out of range
> > > this is not the case, 18 < 30
> > 
> > The hypervisor here is 3.4.3 where the largest hvm param is:
> > $ grep define.HVM_PARAM xen-3.4-testing.hg/xen/include/public/hvm/params.h | sort -k3 -n | tail -n 3
> > #define HVM_PARAM_ACPI_S_STATE 14
> > #define HVM_PARAM_VM86_TSS     15
> > #define HVM_PARAM_VPT_ALIGN    16
> 
> OK, we know that the console is not working because it is not provided
> by the hypervisor.
> However that shouldn't prevent the domain from booting, the emulated
> serial should work fine.

Maybe it does? Mr. KK can you boot your guest with this in guest config:

serial='pty'

and on your Linux line, do 'loglevel=8 initcall_debug console=ttyS0,115200 debug' please?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 14:45:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 14:45:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPDpO-0006QQ-78; Fri, 19 Oct 2012 14:45:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPDpN-0006QE-B9
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 14:45:33 +0000
Received: from [85.158.139.83:49666] by server-5.bemta-5.messagelabs.com id
	BA/F3-09732-C8761805; Fri, 19 Oct 2012 14:45:32 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1350657929!35619704!2
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9918 invoked from network); 19 Oct 2012 14:45:31 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 14:45:31 -0000
Received: by mail-wg0-f51.google.com with SMTP id ed3so303221wgb.32
	for ; Fri, 19 Oct 2012 07:45:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=M5PWRqQWRTVgjZnNG4fdfvh23qo/5tbSAfy8TeTZLY8=;
	b=l97RsXktdrzAwGQpCrFSysrsWE6zXjJZpjSbkX81qtzgXrWu6pEC3FWPwiUkoPGhi7
	to0/lLajFTRKtONPZWYqdIdeYIz/sF+BgXTLmCpo70UlYy8jAFSWhapGGhSkXDNXNqMn
	6rzvmSEDss4mK2OWWX+mHeLKu+GtqlgsMD+ovg6evG0xtpsYoULMfdpKNWOwZ06lZKh1
	nRES9vgGI/nCcGr2a4ja4lY8ClWujNi+cjiVNN4FpYuyHN2PpEaEn/SGDuNbkL1DJiEs
	Om5Z0iDn/ofBEmupAwEj4A22TZwpJZ9uB4M9fT0WrboF//iI1ZeM8lhLIOsdOUNxXDI2
	RIwA==
Received: by 10.180.19.71 with SMTP id c7mr19579166wie.2.1350657931697;
	Fri, 19 Oct 2012 07:45:31 -0700 (PDT)
Received: from [127.0.1.1] (ip-143-153.sn3.eutelia.it. [213.136.143.153])
	by mx.google.com with ESMTPS id k20sm35252230wiv.11.2012.10.19.07.45.29
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 19 Oct 2012 07:45:30 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 09276c114a9a3dcc6058937a1f1bd1e9ef26fe85
Message-Id: <09276c114a9a3dcc6058.1350657294@Solace>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 19 Oct 2012 16:34:54 +0200
From: Dario Faggioli 
To: xen-devel@lists.xen.org
Cc: Andre Przywara ,
	Ian Jackson ,
	Ian Campbell 
Subject: [Xen-devel] [PATCH 1 of 3 v2] libxl: take node distances into
 account during NUMA placement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In fact, among placement candidates with the same number of nodes, the
closer the various nodes are to each others, the better the performances
for a domain placed there.

Signed-off-by: Dario Faggioli 
Acked-by: George Dunlap 

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -105,6 +105,9 @@ out:
  *  - the number of vcpus runnable on the candidates is considered, and
  *    candidates with fewer of them are preferred. If two candidate have
  *    the same number of runnable vcpus,
+ *  - the sum of the node distances in the candidates is considered, and
+ *    candidates with smaller total distance are preferred. If total
+ *    distance is the same for the two candidatess,
  *  - the amount of free memory in the candidates is considered, and the
  *    candidate with greater amount of it is preferred.
  *
@@ -114,6 +117,10 @@ out:
  * overloading large (from a memory POV) nodes. That's right the effect
  * that counting the vcpus able to run on the nodes tries to prevent.
  *
+ * The relative distance within the nodes in the candidates is considered
+ * as the closer the nodes, the better for the domain ending up on the
+ * candidate.
+ *
  * Note that this completely ignore the number of nodes each candidate span,
  * as the fact that fewer nodes is better is already accounted for in the
  * algorithm.
@@ -124,6 +131,9 @@ static int numa_cmpf(const libxl__numa_c
     if (c1->nr_vcpus != c2->nr_vcpus)
         return c1->nr_vcpus - c2->nr_vcpus;
 
+    if (c1->dists_sum != c2->dists_sum)
+        return c1->dists_sum - c2->dists_sum;
+
     return c2->free_memkb - c1->free_memkb;
 }
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -2735,6 +2735,7 @@ static inline void libxl__ctx_unlock(lib
 typedef struct {
     int nr_cpus, nr_nodes;
     int nr_vcpus;
+    int dists_sum;
     uint32_t free_memkb;
     libxl_bitmap nodemap;
 } libxl__numa_candidate;
diff --git a/tools/libxl/libxl_numa.c b/tools/libxl/libxl_numa.c
--- a/tools/libxl/libxl_numa.c
+++ b/tools/libxl/libxl_numa.c
@@ -218,6 +218,40 @@ static int nodemap_to_nr_vcpus(libxl__gc
     return nr_vcpus;
 }
 
+/* Sum the relative distances of nodes in the nodemap to help finding
+ * out which candidate is the "tightest" one. */
+static int nodemap_to_dists_sum(libxl_numainfo *ninfo, libxl_bitmap *nodemap)
+{
+    int tot_dist = 0;
+    int i, j, a = 0, b;
+
+    for (i = 0; i < libxl_bitmap_count_set(nodemap); i++) {
+        while (!libxl_bitmap_test(nodemap, a))
+            a++;
+
+        /* As it is usually non-zero, we do take the latency of
+         * of a node to itself into account. */
+        b = a;
+        for (j = 0; j < libxl_bitmap_count_set(nodemap) - i; j++) {
+            while (!libxl_bitmap_test(nodemap, b))
+                b++;
+
+            /*
+             * In most architectures, going from node A to node B costs
+             * exactly as much as going from B to A does. However, let's
+             * not rely on this and consider both contributions, just to
+             * be ready for everything future might reserve for us.
+             */
+            tot_dist += ninfo[a].dists[b];
+            tot_dist += ninfo[b].dists[a];
+            b++;
+        }
+        a++;
+    }
+
+    return tot_dist;
+}
+
 /*
  * This function tries to figure out if the host has a consistent number
  * of cpus along all its NUMA nodes. In fact, if that is the case, we can
@@ -415,6 +449,7 @@ int libxl__get_numa_candidate(libxl__gc 
              */
             libxl__numa_candidate_put_nodemap(gc, &new_cndt, &nodemap);
             new_cndt.nr_vcpus = nodemap_to_nr_vcpus(gc, tinfo, &nodemap);
+            new_cndt.dists_sum = nodemap_to_dists_sum(ninfo, &nodemap);
             new_cndt.free_memkb = nodes_free_memkb;
             new_cndt.nr_nodes = libxl_bitmap_count_set(&nodemap);
             new_cndt.nr_cpus = nodes_cpus;
@@ -430,12 +465,14 @@ int libxl__get_numa_candidate(libxl__gc 
 
                 LOG(DEBUG, "New best NUMA placement candidate found: "
                            "nr_nodes=%d, nr_cpus=%d, nr_vcpus=%d, "
-                           "free_memkb=%"PRIu32"", new_cndt.nr_nodes,
-                           new_cndt.nr_cpus, new_cndt.nr_vcpus,
+                           "dists_sum=%d, free_memkb=%"PRIu32"",
+                           new_cndt.nr_nodes, new_cndt.nr_cpus,
+                           new_cndt.nr_vcpus, new_cndt.dists_sum,
                            new_cndt.free_memkb / 1024);
 
                 libxl__numa_candidate_put_nodemap(gc, cndt_out, &nodemap);
                 cndt_out->nr_vcpus = new_cndt.nr_vcpus;
+                cndt_out->dists_sum = new_cndt.dists_sum;
                 cndt_out->free_memkb = new_cndt.free_memkb;
                 cndt_out->nr_nodes = new_cndt.nr_nodes;
                 cndt_out->nr_cpus = new_cndt.nr_cpus;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 14:45:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 14:45:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPDpO-0006QQ-78; Fri, 19 Oct 2012 14:45:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPDpN-0006QE-B9
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 14:45:33 +0000
Received: from [85.158.139.83:49666] by server-5.bemta-5.messagelabs.com id
	BA/F3-09732-C8761805; Fri, 19 Oct 2012 14:45:32 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1350657929!35619704!2
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9918 invoked from network); 19 Oct 2012 14:45:31 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 14:45:31 -0000
Received: by mail-wg0-f51.google.com with SMTP id ed3so303221wgb.32
	for ; Fri, 19 Oct 2012 07:45:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=M5PWRqQWRTVgjZnNG4fdfvh23qo/5tbSAfy8TeTZLY8=;
	b=l97RsXktdrzAwGQpCrFSysrsWE6zXjJZpjSbkX81qtzgXrWu6pEC3FWPwiUkoPGhi7
	to0/lLajFTRKtONPZWYqdIdeYIz/sF+BgXTLmCpo70UlYy8jAFSWhapGGhSkXDNXNqMn
	6rzvmSEDss4mK2OWWX+mHeLKu+GtqlgsMD+ovg6evG0xtpsYoULMfdpKNWOwZ06lZKh1
	nRES9vgGI/nCcGr2a4ja4lY8ClWujNi+cjiVNN4FpYuyHN2PpEaEn/SGDuNbkL1DJiEs
	Om5Z0iDn/ofBEmupAwEj4A22TZwpJZ9uB4M9fT0WrboF//iI1ZeM8lhLIOsdOUNxXDI2
	RIwA==
Received: by 10.180.19.71 with SMTP id c7mr19579166wie.2.1350657931697;
	Fri, 19 Oct 2012 07:45:31 -0700 (PDT)
Received: from [127.0.1.1] (ip-143-153.sn3.eutelia.it. [213.136.143.153])
	by mx.google.com with ESMTPS id k20sm35252230wiv.11.2012.10.19.07.45.29
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 19 Oct 2012 07:45:30 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 09276c114a9a3dcc6058937a1f1bd1e9ef26fe85
Message-Id: <09276c114a9a3dcc6058.1350657294@Solace>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 19 Oct 2012 16:34:54 +0200
From: Dario Faggioli 
To: xen-devel@lists.xen.org
Cc: Andre Przywara ,
	Ian Jackson ,
	Ian Campbell 
Subject: [Xen-devel] [PATCH 1 of 3 v2] libxl: take node distances into
 account during NUMA placement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In fact, among placement candidates with the same number of nodes, the
closer the various nodes are to each others, the better the performances
for a domain placed there.

Signed-off-by: Dario Faggioli 
Acked-by: George Dunlap 

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -105,6 +105,9 @@ out:
  *  - the number of vcpus runnable on the candidates is considered, and
  *    candidates with fewer of them are preferred. If two candidate have
  *    the same number of runnable vcpus,
+ *  - the sum of the node distances in the candidates is considered, and
+ *    candidates with smaller total distance are preferred. If total
+ *    distance is the same for the two candidatess,
  *  - the amount of free memory in the candidates is considered, and the
  *    candidate with greater amount of it is preferred.
  *
@@ -114,6 +117,10 @@ out:
  * overloading large (from a memory POV) nodes. That's right the effect
  * that counting the vcpus able to run on the nodes tries to prevent.
  *
+ * The relative distance within the nodes in the candidates is considered
+ * as the closer the nodes, the better for the domain ending up on the
+ * candidate.
+ *
  * Note that this completely ignore the number of nodes each candidate span,
  * as the fact that fewer nodes is better is already accounted for in the
  * algorithm.
@@ -124,6 +131,9 @@ static int numa_cmpf(const libxl__numa_c
     if (c1->nr_vcpus != c2->nr_vcpus)
         return c1->nr_vcpus - c2->nr_vcpus;
 
+    if (c1->dists_sum != c2->dists_sum)
+        return c1->dists_sum - c2->dists_sum;
+
     return c2->free_memkb - c1->free_memkb;
 }
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -2735,6 +2735,7 @@ static inline void libxl__ctx_unlock(lib
 typedef struct {
     int nr_cpus, nr_nodes;
     int nr_vcpus;
+    int dists_sum;
     uint32_t free_memkb;
     libxl_bitmap nodemap;
 } libxl__numa_candidate;
diff --git a/tools/libxl/libxl_numa.c b/tools/libxl/libxl_numa.c
--- a/tools/libxl/libxl_numa.c
+++ b/tools/libxl/libxl_numa.c
@@ -218,6 +218,40 @@ static int nodemap_to_nr_vcpus(libxl__gc
     return nr_vcpus;
 }
 
+/* Sum the relative distances of nodes in the nodemap to help finding
+ * out which candidate is the "tightest" one. */
+static int nodemap_to_dists_sum(libxl_numainfo *ninfo, libxl_bitmap *nodemap)
+{
+    int tot_dist = 0;
+    int i, j, a = 0, b;
+
+    for (i = 0; i < libxl_bitmap_count_set(nodemap); i++) {
+        while (!libxl_bitmap_test(nodemap, a))
+            a++;
+
+        /* As it is usually non-zero, we do take the latency of
+         * of a node to itself into account. */
+        b = a;
+        for (j = 0; j < libxl_bitmap_count_set(nodemap) - i; j++) {
+            while (!libxl_bitmap_test(nodemap, b))
+                b++;
+
+            /*
+             * In most architectures, going from node A to node B costs
+             * exactly as much as going from B to A does. However, let's
+             * not rely on this and consider both contributions, just to
+             * be ready for everything future might reserve for us.
+             */
+            tot_dist += ninfo[a].dists[b];
+            tot_dist += ninfo[b].dists[a];
+            b++;
+        }
+        a++;
+    }
+
+    return tot_dist;
+}
+
 /*
  * This function tries to figure out if the host has a consistent number
  * of cpus along all its NUMA nodes. In fact, if that is the case, we can
@@ -415,6 +449,7 @@ int libxl__get_numa_candidate(libxl__gc 
              */
             libxl__numa_candidate_put_nodemap(gc, &new_cndt, &nodemap);
             new_cndt.nr_vcpus = nodemap_to_nr_vcpus(gc, tinfo, &nodemap);
+            new_cndt.dists_sum = nodemap_to_dists_sum(ninfo, &nodemap);
             new_cndt.free_memkb = nodes_free_memkb;
             new_cndt.nr_nodes = libxl_bitmap_count_set(&nodemap);
             new_cndt.nr_cpus = nodes_cpus;
@@ -430,12 +465,14 @@ int libxl__get_numa_candidate(libxl__gc 
 
                 LOG(DEBUG, "New best NUMA placement candidate found: "
                            "nr_nodes=%d, nr_cpus=%d, nr_vcpus=%d, "
-                           "free_memkb=%"PRIu32"", new_cndt.nr_nodes,
-                           new_cndt.nr_cpus, new_cndt.nr_vcpus,
+                           "dists_sum=%d, free_memkb=%"PRIu32"",
+                           new_cndt.nr_nodes, new_cndt.nr_cpus,
+                           new_cndt.nr_vcpus, new_cndt.dists_sum,
                            new_cndt.free_memkb / 1024);
 
                 libxl__numa_candidate_put_nodemap(gc, cndt_out, &nodemap);
                 cndt_out->nr_vcpus = new_cndt.nr_vcpus;
+                cndt_out->dists_sum = new_cndt.dists_sum;
                 cndt_out->free_memkb = new_cndt.free_memkb;
                 cndt_out->nr_nodes = new_cndt.nr_nodes;
                 cndt_out->nr_cpus = new_cndt.nr_cpus;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 14:45:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 14:45:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPDpM-0006QF-Qy; Fri, 19 Oct 2012 14:45:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPDpK-0006Q7-RL
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 14:45:31 +0000
Received: from [85.158.139.83:61152] by server-3.bemta-5.messagelabs.com id
	6E/E1-28618-98761805; Fri, 19 Oct 2012 14:45:29 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1350657929!35619704!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9752 invoked from network); 19 Oct 2012 14:45:29 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 14:45:29 -0000
Received: by mail-wg0-f51.google.com with SMTP id ed3so303221wgb.32
	for ; Fri, 19 Oct 2012 07:45:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to:cc;
	bh=D1CncvCh2easdeR7/iACHeYz9QApOULT+iDClLqKnQE=;
	b=jrvkv61T5mW2bHNcataSkHio767kaYO2pn1oAmIU6/T4Lmf86mdVQgxhegt5XTGYIP
	1osLtjvSeUD27tFpLtlJ81BIP/w3HAgILvcK2O1Tl/TzgjqX8aXx+4lMRENwOHUFSRJk
	ockJW+uab2o4sG3takAeQ4S9gcL9t341fk2a4e6v3Hj1lXUnCY5f2c9MeiDv9RlChzca
	GRbAdZGUZ+lDJ9HtRwMtD73SSNxY6oOr9/J118iulg9PjiB78/aMlHjKXWhpFZaM53hI
	KRbmsn4xSXjd6HDtPBiWmVXbqDxRl/DZVLJ3txDWRgERGbns0rukkWi87NtnnqdtDerq
	9YIA==
Received: by 10.216.131.132 with SMTP id m4mr1058467wei.23.1350657929230;
	Fri, 19 Oct 2012 07:45:29 -0700 (PDT)
Received: from [127.0.1.1] (ip-143-153.sn3.eutelia.it. [213.136.143.153])
	by mx.google.com with ESMTPS id k20sm35252230wiv.11.2012.10.19.07.45.27
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 19 Oct 2012 07:45:28 -0700 (PDT)
MIME-Version: 1.0
Message-Id: 
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 19 Oct 2012 16:34:53 +0200
From: Dario Faggioli 
To: xen-devel@lists.xen.org
Cc: Andre Przywara ,
	Ian Jackson ,
	Ian Campbell 
Subject: [Xen-devel] [PATCH 0 of 3 v2] Some small NUMA placement improvements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi again,

Take 2 of this series, with the only comment about strstr()-vs-strncmp() in
patch 2 addressed, and all the three patches already Acked-by George.

Just as a quick reminder, the series is about:
 - use node distances information during automatic placement (patch 1);
 - let the user specify a minimum and a maximum number of NUMA nodes they want
   the automaic placement to use (patch 2);
 - enhance the syntax of the "cpus=" config switch so that full nodes can be
   specified instead of just single CPUs (patch 3).

Thanks and Regards,
Dario

--
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 14:45:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 14:45:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPDpM-0006QF-Qy; Fri, 19 Oct 2012 14:45:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPDpK-0006Q7-RL
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 14:45:31 +0000
Received: from [85.158.139.83:61152] by server-3.bemta-5.messagelabs.com id
	6E/E1-28618-98761805; Fri, 19 Oct 2012 14:45:29 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1350657929!35619704!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9752 invoked from network); 19 Oct 2012 14:45:29 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 14:45:29 -0000
Received: by mail-wg0-f51.google.com with SMTP id ed3so303221wgb.32
	for ; Fri, 19 Oct 2012 07:45:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to:cc;
	bh=D1CncvCh2easdeR7/iACHeYz9QApOULT+iDClLqKnQE=;
	b=jrvkv61T5mW2bHNcataSkHio767kaYO2pn1oAmIU6/T4Lmf86mdVQgxhegt5XTGYIP
	1osLtjvSeUD27tFpLtlJ81BIP/w3HAgILvcK2O1Tl/TzgjqX8aXx+4lMRENwOHUFSRJk
	ockJW+uab2o4sG3takAeQ4S9gcL9t341fk2a4e6v3Hj1lXUnCY5f2c9MeiDv9RlChzca
	GRbAdZGUZ+lDJ9HtRwMtD73SSNxY6oOr9/J118iulg9PjiB78/aMlHjKXWhpFZaM53hI
	KRbmsn4xSXjd6HDtPBiWmVXbqDxRl/DZVLJ3txDWRgERGbns0rukkWi87NtnnqdtDerq
	9YIA==
Received: by 10.216.131.132 with SMTP id m4mr1058467wei.23.1350657929230;
	Fri, 19 Oct 2012 07:45:29 -0700 (PDT)
Received: from [127.0.1.1] (ip-143-153.sn3.eutelia.it. [213.136.143.153])
	by mx.google.com with ESMTPS id k20sm35252230wiv.11.2012.10.19.07.45.27
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 19 Oct 2012 07:45:28 -0700 (PDT)
MIME-Version: 1.0
Message-Id: 
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 19 Oct 2012 16:34:53 +0200
From: Dario Faggioli 
To: xen-devel@lists.xen.org
Cc: Andre Przywara ,
	Ian Jackson ,
	Ian Campbell 
Subject: [Xen-devel] [PATCH 0 of 3 v2] Some small NUMA placement improvements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi again,

Take 2 of this series, with the only comment about strstr()-vs-strncmp() in
patch 2 addressed, and all the three patches already Acked-by George.

Just as a quick reminder, the series is about:
 - use node distances information during automatic placement (patch 1);
 - let the user specify a minimum and a maximum number of NUMA nodes they want
   the automaic placement to use (patch 2);
 - enhance the syntax of the "cpus=" config switch so that full nodes can be
   specified instead of just single CPUs (patch 3).

Thanks and Regards,
Dario

--
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 14:45:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 14:45:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPDpW-0006Rv-OL; Fri, 19 Oct 2012 14:45:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPDpU-0006RT-Oh
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 14:45:40 +0000
Received: from [85.158.143.99:3184] by server-1.bemta-4.messagelabs.com id
	32/2C-19134-49761805; Fri, 19 Oct 2012 14:45:40 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1350657933!28539999!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10989 invoked from network); 19 Oct 2012 14:45:34 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 14:45:34 -0000
Received: by mail-we0-f173.google.com with SMTP id t11so359505wey.32
	for ; Fri, 19 Oct 2012 07:45:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=i03j5q0J4TQKglej0Ia1Gp0rIAdqMdngiy1qxGN+wo0=;
	b=hdoCzW7N3Xl9T20WtYdYlbPhibmUyRh+pJQiDtpJVguFjdyeg8IDPMi/TlL2q3LMpS
	mscfpkoR4PUvmdVDPwGKPF8IXn/1axoAG1TKb4aub2K8hG1+sp9OAvmlBff67wUC5Kml
	4oAtM+/MYsYmpITaW2SI6LwO657HM9xFhW9QakOhOFGhOZ9Lk6CtSsSfQdNHwybRIRde
	Bo27uYfBiyQy2iBnM6nGXm7MJ6m51Iv0WgDKqqvd8y/xJ2JCNMGbK459AFvwvMDasalu
	WX7Be/TBq4Xxp3LwBT2xeaO4UpR6N4kWEl/2DS+hHmiceN7Y2hPXs42Vs6Sa1Dz0QcRz
	EU7Q==
Received: by 10.180.8.40 with SMTP id o8mr19545621wia.9.1350657933635;
	Fri, 19 Oct 2012 07:45:33 -0700 (PDT)
Received: from [127.0.1.1] (ip-143-153.sn3.eutelia.it. [213.136.143.153])
	by mx.google.com with ESMTPS id k20sm35252230wiv.11.2012.10.19.07.45.31
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 19 Oct 2012 07:45:32 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 4e5e196ea494ba7c4aaf96db52650f05a972b74b
Message-Id: <4e5e196ea494ba7c4aaf.1350657295@Solace>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 19 Oct 2012 16:34:55 +0200
From: Dario Faggioli 
To: xen-devel@lists.xen.org
Cc: Andre Przywara ,
	Ian Jackson ,
	Ian Campbell 
Subject: [Xen-devel] [PATCH 2 of 3 v2] libxl,
 xl: user can ask for min and max nodes to use during placement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

And the placement algorithm will stick to that, or fail. This happens
adding support for "minnodes=" and "maxnodes=" in the domain config
file parser.

Signed-off-by: Dario Faggioli 
Acked-by: George Dunlap 

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -133,6 +133,18 @@ the same time, achieving efficient utili
 
 =back
 
+=item B
+
+Tells libxl to place the new domain on at least `N` nodes. This is only
+effective if automatic NUMA placement occurs (i.e., if no `cpus=` option
+is specified).
+
+=item B
+
+Tells libxl to place the new domain on at most `M` nodes. This is only
+effective if automatic NUMA placement occurs (i.e., if no `cpus=` option
+is specified).
+
 =head3 CPU Scheduling
 
 =over 4
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -219,6 +219,11 @@ int libxl__domain_build_info_setdefault(
 
     libxl_defbool_setdefault(&b_info->numa_placement, true);
 
+    if (!b_info->min_nodes)
+        b_info->min_nodes = 0;
+    if (!b_info->max_nodes)
+        b_info->max_nodes = 0;
+
     if (b_info->max_memkb == LIBXL_MEMKB_DEFAULT)
         b_info->max_memkb = 32 * 1024;
     if (b_info->target_memkb == LIBXL_MEMKB_DEFAULT)
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -174,7 +174,8 @@ static int numa_place_domain(libxl__gc *
     /* Find the best candidate with enough free memory and at least
      * as much pcpus as the domain has vcpus.  */
     rc = libxl__get_numa_candidate(gc, memkb, info->max_vcpus,
-                                   0, 0, &cpupool_info.cpumap,
+                                   info->min_nodes, info->max_nodes,
+                                   &cpupool_info.cpumap,
                                    numa_cmpf, &candidate, &found);
     if (rc)
         goto out;
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -262,6 +262,8 @@ libxl_domain_build_info = Struct("domain
     ("avail_vcpus",     libxl_bitmap),
     ("cpumap",          libxl_bitmap),
     ("numa_placement",  libxl_defbool),
+    ("min_nodes",       integer),
+    ("max_nodes",       integer),
     ("tsc_mode",        libxl_tsc_mode),
     ("max_memkb",       MemKB),
     ("target_memkb",    MemKB),
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -731,6 +731,11 @@ static void parse_config_data(const char
         libxl_defbool_set(&b_info->numa_placement, false);
     }
 
+    if (!xlu_cfg_get_long (config, "minnodes", &l, 0))
+        b_info->min_nodes = l;
+    if (!xlu_cfg_get_long (config, "maxnodes", &l, 0))
+        b_info->max_nodes = l;
+
     if (!xlu_cfg_get_long (config, "memory", &l, 0)) {
         b_info->max_memkb = l * 1024;
         b_info->target_memkb = b_info->max_memkb;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 14:45:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 14:45:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPDpW-0006Rv-OL; Fri, 19 Oct 2012 14:45:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPDpU-0006RT-Oh
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 14:45:40 +0000
Received: from [85.158.143.99:3184] by server-1.bemta-4.messagelabs.com id
	32/2C-19134-49761805; Fri, 19 Oct 2012 14:45:40 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1350657933!28539999!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10989 invoked from network); 19 Oct 2012 14:45:34 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 14:45:34 -0000
Received: by mail-we0-f173.google.com with SMTP id t11so359505wey.32
	for ; Fri, 19 Oct 2012 07:45:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=i03j5q0J4TQKglej0Ia1Gp0rIAdqMdngiy1qxGN+wo0=;
	b=hdoCzW7N3Xl9T20WtYdYlbPhibmUyRh+pJQiDtpJVguFjdyeg8IDPMi/TlL2q3LMpS
	mscfpkoR4PUvmdVDPwGKPF8IXn/1axoAG1TKb4aub2K8hG1+sp9OAvmlBff67wUC5Kml
	4oAtM+/MYsYmpITaW2SI6LwO657HM9xFhW9QakOhOFGhOZ9Lk6CtSsSfQdNHwybRIRde
	Bo27uYfBiyQy2iBnM6nGXm7MJ6m51Iv0WgDKqqvd8y/xJ2JCNMGbK459AFvwvMDasalu
	WX7Be/TBq4Xxp3LwBT2xeaO4UpR6N4kWEl/2DS+hHmiceN7Y2hPXs42Vs6Sa1Dz0QcRz
	EU7Q==
Received: by 10.180.8.40 with SMTP id o8mr19545621wia.9.1350657933635;
	Fri, 19 Oct 2012 07:45:33 -0700 (PDT)
Received: from [127.0.1.1] (ip-143-153.sn3.eutelia.it. [213.136.143.153])
	by mx.google.com with ESMTPS id k20sm35252230wiv.11.2012.10.19.07.45.31
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 19 Oct 2012 07:45:32 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 4e5e196ea494ba7c4aaf96db52650f05a972b74b
Message-Id: <4e5e196ea494ba7c4aaf.1350657295@Solace>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 19 Oct 2012 16:34:55 +0200
From: Dario Faggioli 
To: xen-devel@lists.xen.org
Cc: Andre Przywara ,
	Ian Jackson ,
	Ian Campbell 
Subject: [Xen-devel] [PATCH 2 of 3 v2] libxl,
 xl: user can ask for min and max nodes to use during placement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

And the placement algorithm will stick to that, or fail. This happens
adding support for "minnodes=" and "maxnodes=" in the domain config
file parser.

Signed-off-by: Dario Faggioli 
Acked-by: George Dunlap 

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -133,6 +133,18 @@ the same time, achieving efficient utili
 
 =back
 
+=item B
+
+Tells libxl to place the new domain on at least `N` nodes. This is only
+effective if automatic NUMA placement occurs (i.e., if no `cpus=` option
+is specified).
+
+=item B
+
+Tells libxl to place the new domain on at most `M` nodes. This is only
+effective if automatic NUMA placement occurs (i.e., if no `cpus=` option
+is specified).
+
 =head3 CPU Scheduling
 
 =over 4
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -219,6 +219,11 @@ int libxl__domain_build_info_setdefault(
 
     libxl_defbool_setdefault(&b_info->numa_placement, true);
 
+    if (!b_info->min_nodes)
+        b_info->min_nodes = 0;
+    if (!b_info->max_nodes)
+        b_info->max_nodes = 0;
+
     if (b_info->max_memkb == LIBXL_MEMKB_DEFAULT)
         b_info->max_memkb = 32 * 1024;
     if (b_info->target_memkb == LIBXL_MEMKB_DEFAULT)
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -174,7 +174,8 @@ static int numa_place_domain(libxl__gc *
     /* Find the best candidate with enough free memory and at least
      * as much pcpus as the domain has vcpus.  */
     rc = libxl__get_numa_candidate(gc, memkb, info->max_vcpus,
-                                   0, 0, &cpupool_info.cpumap,
+                                   info->min_nodes, info->max_nodes,
+                                   &cpupool_info.cpumap,
                                    numa_cmpf, &candidate, &found);
     if (rc)
         goto out;
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -262,6 +262,8 @@ libxl_domain_build_info = Struct("domain
     ("avail_vcpus",     libxl_bitmap),
     ("cpumap",          libxl_bitmap),
     ("numa_placement",  libxl_defbool),
+    ("min_nodes",       integer),
+    ("max_nodes",       integer),
     ("tsc_mode",        libxl_tsc_mode),
     ("max_memkb",       MemKB),
     ("target_memkb",    MemKB),
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -731,6 +731,11 @@ static void parse_config_data(const char
         libxl_defbool_set(&b_info->numa_placement, false);
     }
 
+    if (!xlu_cfg_get_long (config, "minnodes", &l, 0))
+        b_info->min_nodes = l;
+    if (!xlu_cfg_get_long (config, "maxnodes", &l, 0))
+        b_info->max_nodes = l;
+
     if (!xlu_cfg_get_long (config, "memory", &l, 0)) {
         b_info->max_memkb = l * 1024;
         b_info->target_memkb = b_info->max_memkb;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 14:45:59 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 14:45:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPDpc-0006Sw-5Q; Fri, 19 Oct 2012 14:45:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPDpa-0006SG-0F
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 14:45:46 +0000
Received: from [85.158.137.99:7827] by server-6.bemta-3.messagelabs.com id
	12/75-32375-99761805; Fri, 19 Oct 2012 14:45:45 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1350657943!17532847!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17061 invoked from network); 19 Oct 2012 14:45:44 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 14:45:44 -0000
Received: by mail-wi0-f173.google.com with SMTP id hm4so265083wib.14
	for ; Fri, 19 Oct 2012 07:45:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=/W9+ErX6hRUbhEPZvzwU8BjgZgO76ofkXx37BW2htJA=;
	b=wcZLBl01zcyF1NzXYJ6y+2hfKy6djBgG466XrezhNBjYLE/NA6MI9pNEEaY52utpCj
	cSPRVRVxhuEkzJIPJlAMGx7r9cTs02CvatAgGSwASqoEMyopID39UNPKQl3+TQjGA1Z6
	LQdAzO8rn5MoZPCJ4AlEX4IBJ7byP+SGMCqG67adTcSbsfXVPa94qH0dQ3zGmung/Jm0
	GIwvVTiCzmYIQlkbOGjQeJxgi89mgsiRPbrRhRiLLH8Lq+wYbkrtbzjjYXhAESgnoNL9
	AKbzf46+e0fdg/44y7yvzX9zWgIUQdFT+YRW4VIx5J8hWqyQgRO+f1xP3lHTBKY7H+Lj
	RQxQ==
Received: by 10.180.87.34 with SMTP id u2mr3802715wiz.4.1350657943786;
	Fri, 19 Oct 2012 07:45:43 -0700 (PDT)
Received: from [127.0.1.1] (ip-143-153.sn3.eutelia.it. [213.136.143.153])
	by mx.google.com with ESMTPS id k20sm35252230wiv.11.2012.10.19.07.45.33
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 19 Oct 2012 07:45:34 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 1aa5c493a305c0145a0db50e115906cca2221fca
Message-Id: <1aa5c493a305c0145a0d.1350657296@Solace>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 19 Oct 2012 16:34:56 +0200
From: Dario Faggioli 
To: xen-devel@lists.xen.org
Cc: Andre Przywara ,
	Ian Jackson ,
	Ian Campbell 
Subject: [Xen-devel] [PATCH 3 of 3 v2] xl: allow for node-wise specification
 of vcpu pinning
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Making it possible to use something like the following:
 * "nodes:0-3": all pCPUs of nodes 0,1,2,3;
 * "nodes:0-3,^node:2": all pCPUS of nodes 0,1,3;
 * "1,nodes:1-2,^6": pCPU 1 plus all pCPUs of nodes 1,2 but not pCPU 6;
 * ...

In both domain config file and `xl vcpu-pin'.

Signed-off-by: Dario Faggioli 
Acked-by: George Dunlap 
---
Changes since v1:
 * strstr() replaced with strncmp().

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -109,7 +109,7 @@ some cpus on its own (see below). A C cpuidb) {
+            idb = strtoul(tokb, &endptr, 10);
+            if (endptr == tokb || ida > idb) {
                 fprintf(stderr, "Error: Invalid argument.\n");
                 rc = EINVAL;
                 goto vcpp_out;
             }
         }
-        while (cpuida <= cpuidb) {
-            rmcpu == 0 ? libxl_bitmap_set(cpumap, cpuida) :
-                         libxl_bitmap_set(&exclude_cpumap, cpuida);
-            cpuida++;
-        }
-    }
-
-    /* Clear all the cpus from the removal list */
+        while (ida <= idb) {
+            if (!isnode)
+                isnot == 0 ? libxl_bitmap_set(cpumap, ida) :
+                             libxl_bitmap_set(&exclude_cpumap, ida);
+            else
+                isnot == 0 ? libxl_bitmap_set(&nodemap, ida) :
+                             libxl_bitmap_set(&exclude_nodemap, ida);
+            ida++;
+        }
+    }
+
+    /* Add the cpus that have been specified via "node:" items */
+    rc = libxl_nodemap_to_cpumap(ctx, &nodemap, &cpu_nodemap);
+    if (rc)
+        goto vcpp_out;
+    libxl_for_each_set_bit(i, cpu_nodemap) {
+        libxl_bitmap_set(cpumap, i);
+    }
+
+    /* Clear all the cpus from the removal cpu and node lists */
     libxl_for_each_set_bit(i, exclude_cpumap) {
         libxl_bitmap_reset(cpumap, i);
     }
+    rc = libxl_nodemap_to_cpumap(ctx, &exclude_nodemap, &cpu_nodemap);
+    if (rc)
+        goto vcpp_out;
+    libxl_for_each_set_bit(i, cpu_nodemap) {
+        libxl_bitmap_reset(cpumap, i);
+    }
 
 vcpp_out:
     libxl_bitmap_dispose(&exclude_cpumap);
+    libxl_bitmap_dispose(&exclude_nodemap);
+    libxl_bitmap_dispose(&nodemap);
+    libxl_bitmap_dispose(&cpu_nodemap);
 
     return rc;
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 14:45:59 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 14:45:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPDpc-0006Sw-5Q; Fri, 19 Oct 2012 14:45:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPDpa-0006SG-0F
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 14:45:46 +0000
Received: from [85.158.137.99:7827] by server-6.bemta-3.messagelabs.com id
	12/75-32375-99761805; Fri, 19 Oct 2012 14:45:45 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1350657943!17532847!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17061 invoked from network); 19 Oct 2012 14:45:44 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 14:45:44 -0000
Received: by mail-wi0-f173.google.com with SMTP id hm4so265083wib.14
	for ; Fri, 19 Oct 2012 07:45:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=/W9+ErX6hRUbhEPZvzwU8BjgZgO76ofkXx37BW2htJA=;
	b=wcZLBl01zcyF1NzXYJ6y+2hfKy6djBgG466XrezhNBjYLE/NA6MI9pNEEaY52utpCj
	cSPRVRVxhuEkzJIPJlAMGx7r9cTs02CvatAgGSwASqoEMyopID39UNPKQl3+TQjGA1Z6
	LQdAzO8rn5MoZPCJ4AlEX4IBJ7byP+SGMCqG67adTcSbsfXVPa94qH0dQ3zGmung/Jm0
	GIwvVTiCzmYIQlkbOGjQeJxgi89mgsiRPbrRhRiLLH8Lq+wYbkrtbzjjYXhAESgnoNL9
	AKbzf46+e0fdg/44y7yvzX9zWgIUQdFT+YRW4VIx5J8hWqyQgRO+f1xP3lHTBKY7H+Lj
	RQxQ==
Received: by 10.180.87.34 with SMTP id u2mr3802715wiz.4.1350657943786;
	Fri, 19 Oct 2012 07:45:43 -0700 (PDT)
Received: from [127.0.1.1] (ip-143-153.sn3.eutelia.it. [213.136.143.153])
	by mx.google.com with ESMTPS id k20sm35252230wiv.11.2012.10.19.07.45.33
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 19 Oct 2012 07:45:34 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 1aa5c493a305c0145a0db50e115906cca2221fca
Message-Id: <1aa5c493a305c0145a0d.1350657296@Solace>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.2.2
Date: Fri, 19 Oct 2012 16:34:56 +0200
From: Dario Faggioli 
To: xen-devel@lists.xen.org
Cc: Andre Przywara ,
	Ian Jackson ,
	Ian Campbell 
Subject: [Xen-devel] [PATCH 3 of 3 v2] xl: allow for node-wise specification
 of vcpu pinning
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Making it possible to use something like the following:
 * "nodes:0-3": all pCPUs of nodes 0,1,2,3;
 * "nodes:0-3,^node:2": all pCPUS of nodes 0,1,3;
 * "1,nodes:1-2,^6": pCPU 1 plus all pCPUs of nodes 1,2 but not pCPU 6;
 * ...

In both domain config file and `xl vcpu-pin'.

Signed-off-by: Dario Faggioli 
Acked-by: George Dunlap 
---
Changes since v1:
 * strstr() replaced with strncmp().

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -109,7 +109,7 @@ some cpus on its own (see below). A C cpuidb) {
+            idb = strtoul(tokb, &endptr, 10);
+            if (endptr == tokb || ida > idb) {
                 fprintf(stderr, "Error: Invalid argument.\n");
                 rc = EINVAL;
                 goto vcpp_out;
             }
         }
-        while (cpuida <= cpuidb) {
-            rmcpu == 0 ? libxl_bitmap_set(cpumap, cpuida) :
-                         libxl_bitmap_set(&exclude_cpumap, cpuida);
-            cpuida++;
-        }
-    }
-
-    /* Clear all the cpus from the removal list */
+        while (ida <= idb) {
+            if (!isnode)
+                isnot == 0 ? libxl_bitmap_set(cpumap, ida) :
+                             libxl_bitmap_set(&exclude_cpumap, ida);
+            else
+                isnot == 0 ? libxl_bitmap_set(&nodemap, ida) :
+                             libxl_bitmap_set(&exclude_nodemap, ida);
+            ida++;
+        }
+    }
+
+    /* Add the cpus that have been specified via "node:" items */
+    rc = libxl_nodemap_to_cpumap(ctx, &nodemap, &cpu_nodemap);
+    if (rc)
+        goto vcpp_out;
+    libxl_for_each_set_bit(i, cpu_nodemap) {
+        libxl_bitmap_set(cpumap, i);
+    }
+
+    /* Clear all the cpus from the removal cpu and node lists */
     libxl_for_each_set_bit(i, exclude_cpumap) {
         libxl_bitmap_reset(cpumap, i);
     }
+    rc = libxl_nodemap_to_cpumap(ctx, &exclude_nodemap, &cpu_nodemap);
+    if (rc)
+        goto vcpp_out;
+    libxl_for_each_set_bit(i, cpu_nodemap) {
+        libxl_bitmap_reset(cpumap, i);
+    }
 
 vcpp_out:
     libxl_bitmap_dispose(&exclude_cpumap);
+    libxl_bitmap_dispose(&exclude_nodemap);
+    libxl_bitmap_dispose(&nodemap);
+    libxl_bitmap_dispose(&cpu_nodemap);
 
     return rc;
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 14:49:15 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 14:49:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPDsl-0006uS-RV; Fri, 19 Oct 2012 14:49:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPDsl-0006u0-3c
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 14:49:03 +0000
Received: from [85.158.139.211:38266] by server-13.bemta-5.messagelabs.com id
	9D/87-30674-E5861805; Fri, 19 Oct 2012 14:49:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1350658142!21475550!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NDA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21293 invoked from network); 19 Oct 2012 14:49:02 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-206.messagelabs.com with SMTP;
	19 Oct 2012 14:49:02 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 19 Oct 2012 15:49:01 +0100
Message-Id: <5081847E02000078000A2A09@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 19 Oct 2012 15:49:02 +0100
From: "Jan Beulich" 
To: "Stefan Bader" 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
	<1350482118.2460.74.camel@zakaz.uk.xensource.com>
	<507ECD06.2050407@canonical.com> <507ED038.8000806@citrix.com>
	<507FC51102000078000A235E@nat28.tlf.novell.com>
	<507FC71502000078000A236C@nat28.tlf.novell.com>
	<507FB1E1.8080700@canonical.com>
	<1350546483.28188.25.camel@dagon.hellion.org.uk>
	<507FD7DE.2010209@canonical.com>
	<507FFA5102000078000A250D@nat28.tlf.novell.com>
	<507FF964.9090009@canonical.com> <50806C0B.1060504@canonical.com>
	<5081264002000078000A2841@nat28.tlf.novell.com>
	<50811047.4080200@canonical.com>
	<5081387B02000078000A288D@nat28.tlf.novell.com>
	<50815DA1.10303@canonical.com>
In-Reply-To: <50815DA1.10303@canonical.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper ,
	Konrad Rzeszutek Wilk ,
	Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 19.10.12 at 16:03, Stefan Bader  wrote:
> On 19.10.2012 11:24, Jan Beulich wrote:
>>>>> On 19.10.12 at 10:33, Stefan Bader  wrote:
>>> I would be pragmatic here, none of the other current implementations seem
>>> to re-enable interrupts and so this only affects xen pv.
>> 
>> I don't think you really checked - the first arch I looked at (s390, as being
>> the most obvious one to look at when it comes to virtualization) quite
>> prominently re-enableds interrupts in arch_spin_lock_wait_flags().
> 
> No, I assumed that you saying native kernel did prior to ticket lock 
> conversion,

I indeed did say that. Just go look back at the old code.

Jan

> that this involves more historic search. And yes s390 is doing 
> virtualization
> quite a bit back into history. Just not paravirtualization.
> And when I look at arch_spin_lock_wait_flags() enabling/disabling is done 
> close
> by (at least I am not leaving off into some hypercall fog).



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 14:49:15 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 14:49:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPDsl-0006uS-RV; Fri, 19 Oct 2012 14:49:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPDsl-0006u0-3c
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 14:49:03 +0000
Received: from [85.158.139.211:38266] by server-13.bemta-5.messagelabs.com id
	9D/87-30674-E5861805; Fri, 19 Oct 2012 14:49:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1350658142!21475550!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NDA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21293 invoked from network); 19 Oct 2012 14:49:02 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-206.messagelabs.com with SMTP;
	19 Oct 2012 14:49:02 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 19 Oct 2012 15:49:01 +0100
Message-Id: <5081847E02000078000A2A09@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 19 Oct 2012 15:49:02 +0100
From: "Jan Beulich" 
To: "Stefan Bader" 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
	<1350482118.2460.74.camel@zakaz.uk.xensource.com>
	<507ECD06.2050407@canonical.com> <507ED038.8000806@citrix.com>
	<507FC51102000078000A235E@nat28.tlf.novell.com>
	<507FC71502000078000A236C@nat28.tlf.novell.com>
	<507FB1E1.8080700@canonical.com>
	<1350546483.28188.25.camel@dagon.hellion.org.uk>
	<507FD7DE.2010209@canonical.com>
	<507FFA5102000078000A250D@nat28.tlf.novell.com>
	<507FF964.9090009@canonical.com> <50806C0B.1060504@canonical.com>
	<5081264002000078000A2841@nat28.tlf.novell.com>
	<50811047.4080200@canonical.com>
	<5081387B02000078000A288D@nat28.tlf.novell.com>
	<50815DA1.10303@canonical.com>
In-Reply-To: <50815DA1.10303@canonical.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper ,
	Konrad Rzeszutek Wilk ,
	Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 19.10.12 at 16:03, Stefan Bader  wrote:
> On 19.10.2012 11:24, Jan Beulich wrote:
>>>>> On 19.10.12 at 10:33, Stefan Bader  wrote:
>>> I would be pragmatic here, none of the other current implementations seem
>>> to re-enable interrupts and so this only affects xen pv.
>> 
>> I don't think you really checked - the first arch I looked at (s390, as being
>> the most obvious one to look at when it comes to virtualization) quite
>> prominently re-enableds interrupts in arch_spin_lock_wait_flags().
> 
> No, I assumed that you saying native kernel did prior to ticket lock 
> conversion,

I indeed did say that. Just go look back at the old code.

Jan

> that this involves more historic search. And yes s390 is doing 
> virtualization
> quite a bit back into history. Just not paravirtualization.
> And when I look at arch_spin_lock_wait_flags() enabling/disabling is done 
> close
> by (at least I am not leaving off into some hypercall fog).



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 14:52:34 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 14:52:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPDvy-0007AY-HB; Fri, 19 Oct 2012 14:52:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPDvw-0007AM-Pi
	for xen-devel@lists.xensource.com; Fri, 19 Oct 2012 14:52:21 +0000
Received: from [85.158.137.99:6900] by server-14.bemta-3.messagelabs.com id
	E4/5F-17276-F1961805; Fri, 19 Oct 2012 14:52:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1350658334!17120109!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUwMDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4950 invoked from network); 19 Oct 2012 14:52:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 14:52:15 -0000
X-IronPort-AV: E=Sophos;i="4.80,612,1344211200"; d="scan'208";a="15279294"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 14:52:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 19 Oct 2012 15:52:14 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TPDvq-0000VV-Dn; Fri, 19 Oct 2012 14:52:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TPDvq-0001pq-8y;
	Fri, 19 Oct 2012 15:52:14 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20609.26910.2416.305293@mariner.uk.xensource.com>
Date: Fri, 19 Oct 2012 15:52:14 +0100
To: "Liu, Jinsong" 
Newsgroups: chiark.mail.xen.devel
In-Reply-To: 
References: 
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration when
	vMCE	occur
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Liu, Jinsong writes ("[Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration when vMCE occur"):
> This patch monitor the critical area of live migration (from vMCE
> point of view, the copypages stage of migration is the critical area
> while other areas are not).

Sorry for the delay reviewing this.

Just to be clear, can you explain what a vMCE is ?  I think I know but
I'm not entirely sure and it would be helpful if you'd confirm, as I
seem to have missed the background here.  I couldn't easily find the
0/5 posting of your series (in part because the tool you're using to
send your series doesn't link the messages together in the same
thread).

> If a vMCE occur at the critical area of live migration, there is
> risk that error data may be copied to the target. Currently we don't
> have convenient way to handle this case, so for the sake of safe, we
> abort it and try migration later (at that time broken page would not
> be mapped and copied to the target).

The "error data" that you refer to is erroneous page contents, or
something else ?

When you say "we abort it and try migration later", that's not
actually implemented in your patch, is it ?  What actually happens is
that the migration is aborted and the user is expected to retry later.

I think this situation deserves a specific error code at the very
least.  That specific error code should be plumbed up to libxl.

Wouldn't it be better to actually restart the migration somehow ?

I have some more minor comments about the implementation:

> @@ -1109,6 +1111,12 @@
>          goto out;
>      }
>  
> +    if ( xc_domain_vmce_monitor_start(xch, dom) )
> +    {
> +        PERROR("Error when start vmce monitor\n");

"Error starting vmc monitor" would be better English.  Messages sent
with PERROR should not have a \n.

> +    vmce_while_monitor = xc_domain_vmce_monitor_end(xch, dom);
> +    if ( vmce_while_monitor < 0 )
> +    {
> +        PERROR("Error when end vmce monitor\n");

Grammar and \n again.

> +    else if ( vmce_while_monitor > 0 )
> +    {
> +        fprintf(stderr, "vMCE occurred, abort this time and try later.\n");
> +        goto out;

This message should be sent with one of the logging macros, not
fprintf.  ERROR, probably.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 14:52:34 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 14:52:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPDvy-0007AY-HB; Fri, 19 Oct 2012 14:52:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPDvw-0007AM-Pi
	for xen-devel@lists.xensource.com; Fri, 19 Oct 2012 14:52:21 +0000
Received: from [85.158.137.99:6900] by server-14.bemta-3.messagelabs.com id
	E4/5F-17276-F1961805; Fri, 19 Oct 2012 14:52:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1350658334!17120109!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUwMDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4950 invoked from network); 19 Oct 2012 14:52:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 14:52:15 -0000
X-IronPort-AV: E=Sophos;i="4.80,612,1344211200"; d="scan'208";a="15279294"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 14:52:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 19 Oct 2012 15:52:14 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TPDvq-0000VV-Dn; Fri, 19 Oct 2012 14:52:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TPDvq-0001pq-8y;
	Fri, 19 Oct 2012 15:52:14 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20609.26910.2416.305293@mariner.uk.xensource.com>
Date: Fri, 19 Oct 2012 15:52:14 +0100
To: "Liu, Jinsong" 
Newsgroups: chiark.mail.xen.devel
In-Reply-To: 
References: 
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration when
	vMCE	occur
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Liu, Jinsong writes ("[Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration when vMCE occur"):
> This patch monitor the critical area of live migration (from vMCE
> point of view, the copypages stage of migration is the critical area
> while other areas are not).

Sorry for the delay reviewing this.

Just to be clear, can you explain what a vMCE is ?  I think I know but
I'm not entirely sure and it would be helpful if you'd confirm, as I
seem to have missed the background here.  I couldn't easily find the
0/5 posting of your series (in part because the tool you're using to
send your series doesn't link the messages together in the same
thread).

> If a vMCE occur at the critical area of live migration, there is
> risk that error data may be copied to the target. Currently we don't
> have convenient way to handle this case, so for the sake of safe, we
> abort it and try migration later (at that time broken page would not
> be mapped and copied to the target).

The "error data" that you refer to is erroneous page contents, or
something else ?

When you say "we abort it and try migration later", that's not
actually implemented in your patch, is it ?  What actually happens is
that the migration is aborted and the user is expected to retry later.

I think this situation deserves a specific error code at the very
least.  That specific error code should be plumbed up to libxl.

Wouldn't it be better to actually restart the migration somehow ?

I have some more minor comments about the implementation:

> @@ -1109,6 +1111,12 @@
>          goto out;
>      }
>  
> +    if ( xc_domain_vmce_monitor_start(xch, dom) )
> +    {
> +        PERROR("Error when start vmce monitor\n");

"Error starting vmc monitor" would be better English.  Messages sent
with PERROR should not have a \n.

> +    vmce_while_monitor = xc_domain_vmce_monitor_end(xch, dom);
> +    if ( vmce_while_monitor < 0 )
> +    {
> +        PERROR("Error when end vmce monitor\n");

Grammar and \n again.

> +    else if ( vmce_while_monitor > 0 )
> +    {
> +        fprintf(stderr, "vMCE occurred, abort this time and try later.\n");
> +        goto out;

This message should be sent with one of the logging macros, not
fprintf.  ERROR, probably.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 14:58:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 14:58:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPE1R-0007Ml-Or; Fri, 19 Oct 2012 14:58:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPE1P-0007Me-5y
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 14:57:59 +0000
Received: from [85.158.139.83:24380] by server-13.bemta-5.messagelabs.com id
	FA/49-30674-67A61805; Fri, 19 Oct 2012 14:57:58 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1350658677!35921091!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22566 invoked from network); 19 Oct 2012 14:57:57 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-10.tower-182.messagelabs.com with SMTP;
	19 Oct 2012 14:57:57 -0000
Received: from p5b2e238c.dip.t-dialin.net ([91.46.35.140] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from )
	id 1TPE1K-0005XX-76; Fri, 19 Oct 2012 14:57:54 +0000
Message-ID: <50816A6E.5010602@canonical.com>
Date: Fri, 19 Oct 2012 16:57:50 +0200
From: Stefan Bader 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Jan Beulich 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
	<1350482118.2460.74.camel@zakaz.uk.xensource.com>
	<507ECD06.2050407@canonical.com> <507ED038.8000806@citrix.com>
	<507FC51102000078000A235E@nat28.tlf.novell.com>
	<507FC71502000078000A236C@nat28.tlf.novell.com>
	<507FB1E1.8080700@canonical.com>
	<1350546483.28188.25.camel@dagon.hellion.org.uk>
	<507FD7DE.2010209@canonical.com>
	<507FFA5102000078000A250D@nat28.tlf.novell.com>
	<507FF964.9090009@canonical.com> <50806C0B.1060504@canonical.com>
	<5081264002000078000A2841@nat28.tlf.novell.com>
	<50811047.4080200@canonical.com>
	<5081387B02000078000A288D@nat28.tlf.novell.com>
	<50815DA1.10303@canonical.com>
	<5081847E02000078000A2A09@nat28.tlf.novell.com>
In-Reply-To: <5081847E02000078000A2A09@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.5
Cc: Andrew Cooper ,
	"xen-devel@lists.xen.org" ,
	Ian Campbell ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============4635424189953540683=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============4635424189953540683==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig9142175BC7ABA196A9E7D577"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig9142175BC7ABA196A9E7D577
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 19.10.2012 16:49, Jan Beulich wrote:

>> No, I assumed that you saying native kernel did prior to ticket lock=20
>> conversion,
>=20
> I indeed did say that. Just go look back at the old code.

No, sorry, but no. Just that old code did it does not help me here. I di =
believe
you there. Still it seems there is something wrong doing it there in a pv=
 guest.
Though I cannot give a satisfying explanation, yet.




--------------enig9142175BC7ABA196A9E7D577
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBCgAGBQJQgWpuAAoJEOhnXe7L7s6jS1kQAOTc3dspTUgYTybVm23Oec2g
ERzN4iAIbdNlSn5Ewzy6hXR/zsJ0fxYDJnZFVkKQz5LMU7wHnn534qNuq5Gnjh2b
G4YmxIz66AmLL4s3vNPDzCDejiA2I9PtSMFWtAIBLLpAsqoC06bs5U/Lh7D25jSJ
MWnwEBYThHiv9mQdNXdGMfJ4TLblffk73Y99MMVGcJi/ZC+6/BO6cosIJaViVK4B
+jxOs2Wh30n7ZZ11fC8jlFNFFgDZTUQp77jFv7U4suI6eU5x/KUOI4t0ofFIZnqV
nJAY8pnnz+Ky+XAVpEWaUQVV1iffbSAaVxX292/WRxdIgsWxnyQ89R/Obzt9QUic
2BuN8sIOoLq9a1t4psip580vE5SwlTTGbOrGkLEfwESlBUQLp4/LUrvJVR2zlkFe
D3Dgn9CsffrTkccR7lP7GT+zr5Qn+TZFXiePBMSTS8Bj5yM/sr18Oa6DfQj11dKx
Uat7aEE1p8pE3ZWZbIveLCeX0LieDZxpQR2FtDpskkRkYkG+Mj5yEfM7BIHm78xK
D+jakJF0wIjsXEL1OUYfLOiN+/U+bt9fQqqpQV+vyubHn4Cx6VeiGr3SOwnPXAZf
OaWl8ngHSqKR4ixmBhZ63YlAUWqhiqPfeeU5NzUCdLwwmXnYLFvB+hzw5GGwfepp
uGhDC9vd0JQallSH2iDf
=R/iq
-----END PGP SIGNATURE-----

--------------enig9142175BC7ABA196A9E7D577--


--===============4635424189953540683==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4635424189953540683==--


From xen-devel-bounces@lists.xen.org Fri Oct 19 14:58:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 14:58:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPE1R-0007Ml-Or; Fri, 19 Oct 2012 14:58:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPE1P-0007Me-5y
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 14:57:59 +0000
Received: from [85.158.139.83:24380] by server-13.bemta-5.messagelabs.com id
	FA/49-30674-67A61805; Fri, 19 Oct 2012 14:57:58 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1350658677!35921091!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22566 invoked from network); 19 Oct 2012 14:57:57 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-10.tower-182.messagelabs.com with SMTP;
	19 Oct 2012 14:57:57 -0000
Received: from p5b2e238c.dip.t-dialin.net ([91.46.35.140] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from )
	id 1TPE1K-0005XX-76; Fri, 19 Oct 2012 14:57:54 +0000
Message-ID: <50816A6E.5010602@canonical.com>
Date: Fri, 19 Oct 2012 16:57:50 +0200
From: Stefan Bader 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Jan Beulich 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
	<1350482118.2460.74.camel@zakaz.uk.xensource.com>
	<507ECD06.2050407@canonical.com> <507ED038.8000806@citrix.com>
	<507FC51102000078000A235E@nat28.tlf.novell.com>
	<507FC71502000078000A236C@nat28.tlf.novell.com>
	<507FB1E1.8080700@canonical.com>
	<1350546483.28188.25.camel@dagon.hellion.org.uk>
	<507FD7DE.2010209@canonical.com>
	<507FFA5102000078000A250D@nat28.tlf.novell.com>
	<507FF964.9090009@canonical.com> <50806C0B.1060504@canonical.com>
	<5081264002000078000A2841@nat28.tlf.novell.com>
	<50811047.4080200@canonical.com>
	<5081387B02000078000A288D@nat28.tlf.novell.com>
	<50815DA1.10303@canonical.com>
	<5081847E02000078000A2A09@nat28.tlf.novell.com>
In-Reply-To: <5081847E02000078000A2A09@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.5
Cc: Andrew Cooper ,
	"xen-devel@lists.xen.org" ,
	Ian Campbell ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============4635424189953540683=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============4635424189953540683==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig9142175BC7ABA196A9E7D577"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig9142175BC7ABA196A9E7D577
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 19.10.2012 16:49, Jan Beulich wrote:

>> No, I assumed that you saying native kernel did prior to ticket lock=20
>> conversion,
>=20
> I indeed did say that. Just go look back at the old code.

No, sorry, but no. Just that old code did it does not help me here. I di =
believe
you there. Still it seems there is something wrong doing it there in a pv=
 guest.
Though I cannot give a satisfying explanation, yet.




--------------enig9142175BC7ABA196A9E7D577
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBCgAGBQJQgWpuAAoJEOhnXe7L7s6jS1kQAOTc3dspTUgYTybVm23Oec2g
ERzN4iAIbdNlSn5Ewzy6hXR/zsJ0fxYDJnZFVkKQz5LMU7wHnn534qNuq5Gnjh2b
G4YmxIz66AmLL4s3vNPDzCDejiA2I9PtSMFWtAIBLLpAsqoC06bs5U/Lh7D25jSJ
MWnwEBYThHiv9mQdNXdGMfJ4TLblffk73Y99MMVGcJi/ZC+6/BO6cosIJaViVK4B
+jxOs2Wh30n7ZZ11fC8jlFNFFgDZTUQp77jFv7U4suI6eU5x/KUOI4t0ofFIZnqV
nJAY8pnnz+Ky+XAVpEWaUQVV1iffbSAaVxX292/WRxdIgsWxnyQ89R/Obzt9QUic
2BuN8sIOoLq9a1t4psip580vE5SwlTTGbOrGkLEfwESlBUQLp4/LUrvJVR2zlkFe
D3Dgn9CsffrTkccR7lP7GT+zr5Qn+TZFXiePBMSTS8Bj5yM/sr18Oa6DfQj11dKx
Uat7aEE1p8pE3ZWZbIveLCeX0LieDZxpQR2FtDpskkRkYkG+Mj5yEfM7BIHm78xK
D+jakJF0wIjsXEL1OUYfLOiN+/U+bt9fQqqpQV+vyubHn4Cx6VeiGr3SOwnPXAZf
OaWl8ngHSqKR4ixmBhZ63YlAUWqhiqPfeeU5NzUCdLwwmXnYLFvB+hzw5GGwfepp
uGhDC9vd0JQallSH2iDf
=R/iq
-----END PGP SIGNATURE-----

--------------enig9142175BC7ABA196A9E7D577--


--===============4635424189953540683==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4635424189953540683==--


From xen-devel-bounces@lists.xen.org Fri Oct 19 14:58:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 14:58:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPE1W-0007N8-5m; Fri, 19 Oct 2012 14:58:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPE1U-0007My-Go
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 14:58:04 +0000
Received: from [85.158.139.211:48466] by server-15.bemta-5.messagelabs.com id
	18/B1-28599-B7A61805; Fri, 19 Oct 2012 14:58:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1350658683!22918488!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NDA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22446 invoked from network); 19 Oct 2012 14:58:03 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-206.messagelabs.com with SMTP;
	19 Oct 2012 14:58:03 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 19 Oct 2012 15:58:02 +0100
Message-Id: <5081869B02000078000A2A1F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 19 Oct 2012 15:58:03 +0100
From: "Jan Beulich" 
To: "Christoph Egger" 
References: <506EE9A7.6090009@amd.com> <50815162.4090601@amd.com>
In-Reply-To: <50815162.4090601@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser , Ian Jackson ,
	Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] tools/xen-mceinj: support AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 19.10.12 at 15:10, Christoph Egger  wrote:
> Ping?

I'm afraid it's not really clear who should commit this - it's tools
side code, so IanJ or IanC would normally be the ones, but otoh
it's code requiring low level hardware knowledge to review the
patch, so both of them might want to rather not do the review.
In the past it was usually Keir who eventually committed such
patches, but I don't know whether he put this on his to-look-at-
and-eventually-commit list.

Jan

> On 10/05/12 16:07, Christoph Egger wrote:
>> 
>> xen-mceinj: Support AMD
>> 
>> Signed-off-by: Christoph Egger 
>> 
> 
> 
> -- 
> ---to satisfy European Law for business letters:
> Advanced Micro Devices GmbH
> Einsteinring 24, 85689 Dornach b. Muenchen
> Geschaeftsfuehrer: Alberto Bozzo
> Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
> Registergericht Muenchen, HRB Nr. 43632
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 14:58:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 14:58:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPE1W-0007N8-5m; Fri, 19 Oct 2012 14:58:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPE1U-0007My-Go
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 14:58:04 +0000
Received: from [85.158.139.211:48466] by server-15.bemta-5.messagelabs.com id
	18/B1-28599-B7A61805; Fri, 19 Oct 2012 14:58:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1350658683!22918488!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NDA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22446 invoked from network); 19 Oct 2012 14:58:03 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-206.messagelabs.com with SMTP;
	19 Oct 2012 14:58:03 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 19 Oct 2012 15:58:02 +0100
Message-Id: <5081869B02000078000A2A1F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 19 Oct 2012 15:58:03 +0100
From: "Jan Beulich" 
To: "Christoph Egger" 
References: <506EE9A7.6090009@amd.com> <50815162.4090601@amd.com>
In-Reply-To: <50815162.4090601@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser , Ian Jackson ,
	Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] tools/xen-mceinj: support AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 19.10.12 at 15:10, Christoph Egger  wrote:
> Ping?

I'm afraid it's not really clear who should commit this - it's tools
side code, so IanJ or IanC would normally be the ones, but otoh
it's code requiring low level hardware knowledge to review the
patch, so both of them might want to rather not do the review.
In the past it was usually Keir who eventually committed such
patches, but I don't know whether he put this on his to-look-at-
and-eventually-commit list.

Jan

> On 10/05/12 16:07, Christoph Egger wrote:
>> 
>> xen-mceinj: Support AMD
>> 
>> Signed-off-by: Christoph Egger 
>> 
> 
> 
> -- 
> ---to satisfy European Law for business letters:
> Advanced Micro Devices GmbH
> Einsteinring 24, 85689 Dornach b. Muenchen
> Geschaeftsfuehrer: Alberto Bozzo
> Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
> Registergericht Muenchen, HRB Nr. 43632
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 14:59:12 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 14:59:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPE2P-0007VW-S4; Fri, 19 Oct 2012 14:59:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPE2P-0007VF-3l
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 14:59:01 +0000
Received: from [85.158.143.35:31757] by server-2.bemta-4.messagelabs.com id
	D1/EA-22268-4BA61805; Fri, 19 Oct 2012 14:59:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1350658739!15759818!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUwMDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1907 invoked from network); 19 Oct 2012 14:59:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 14:59:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,613,1344211200"; d="scan'208";a="15279443"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 14:57:49 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 19 Oct 2012 15:57:49 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TPE1E-0000XU-K4; Fri, 19 Oct 2012 14:57:48 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TPE1E-0001qc-GF;
	Fri, 19 Oct 2012 15:57:48 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20609.27239.778582.985508@mariner.uk.xensource.com>
Date: Fri, 19 Oct 2012 15:57:43 +0100
To: Dario Faggioli 
In-Reply-To: <1350602433.26152.106.camel@Solace>
References: 
	
	
	<1350602433.26152.106.camel@Solace>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Andre Przywara ,
	Ian Campbell ,
	Stefano Stabellini ,
	George Dunlap ,
	Juergen Gross ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 1 of 3] libxl: take node distances into
 account during NUMA placement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dario Faggioli writes ("Re: [Xen-devel] [PATCH 1 of 3] libxl: take node distances into account during NUMA placement"):
> On Thu, 2012-10-18 at 16:17 +0100, George Dunlap wrote:
> > And now we're doing N^2 for each
> > candidate? 
> 
> Again, yes, but that is turning it from Ndoms*Nvcpus to
> Ndoms*Nvcpus+Nnodes^2, which is still dominated by the first term. IIRC,
> Andre tried to start >50 domains with 2 vCPUs on a 8 nodes system, which
> means 50*2 vs 8*8.

Are you sure about this calculation ?  It seems to me that 
doing Nnodes^2 for each candidate multiplies the cost by the number of
candidates, rather than adding Nnodes^2.

There are in the worst case nearly 2^Nnodes candidates (combinations
of nodes).  So the cost is
  <= 2^Nnodes * Nnodes^2

Your algorithm runs with up to 16 nodes.  Your change here increases
the worst-case cost from
  2^16 = 65556
to
  2^16 * 16^2 = 16777216

I don't think that's a good idea.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 14:59:12 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 14:59:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPE2P-0007VW-S4; Fri, 19 Oct 2012 14:59:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPE2P-0007VF-3l
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 14:59:01 +0000
Received: from [85.158.143.35:31757] by server-2.bemta-4.messagelabs.com id
	D1/EA-22268-4BA61805; Fri, 19 Oct 2012 14:59:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1350658739!15759818!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUwMDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1907 invoked from network); 19 Oct 2012 14:59:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 14:59:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,613,1344211200"; d="scan'208";a="15279443"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 14:57:49 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 19 Oct 2012 15:57:49 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TPE1E-0000XU-K4; Fri, 19 Oct 2012 14:57:48 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TPE1E-0001qc-GF;
	Fri, 19 Oct 2012 15:57:48 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20609.27239.778582.985508@mariner.uk.xensource.com>
Date: Fri, 19 Oct 2012 15:57:43 +0100
To: Dario Faggioli 
In-Reply-To: <1350602433.26152.106.camel@Solace>
References: 
	
	
	<1350602433.26152.106.camel@Solace>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Andre Przywara ,
	Ian Campbell ,
	Stefano Stabellini ,
	George Dunlap ,
	Juergen Gross ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 1 of 3] libxl: take node distances into
 account during NUMA placement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dario Faggioli writes ("Re: [Xen-devel] [PATCH 1 of 3] libxl: take node distances into account during NUMA placement"):
> On Thu, 2012-10-18 at 16:17 +0100, George Dunlap wrote:
> > And now we're doing N^2 for each
> > candidate? 
> 
> Again, yes, but that is turning it from Ndoms*Nvcpus to
> Ndoms*Nvcpus+Nnodes^2, which is still dominated by the first term. IIRC,
> Andre tried to start >50 domains with 2 vCPUs on a 8 nodes system, which
> means 50*2 vs 8*8.

Are you sure about this calculation ?  It seems to me that 
doing Nnodes^2 for each candidate multiplies the cost by the number of
candidates, rather than adding Nnodes^2.

There are in the worst case nearly 2^Nnodes candidates (combinations
of nodes).  So the cost is
  <= 2^Nnodes * Nnodes^2

Your algorithm runs with up to 16 nodes.  Your change here increases
the worst-case cost from
  2^16 = 65556
to
  2^16 * 16^2 = 16777216

I don't think that's a good idea.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 14:59:44 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 14:59:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPE2y-0007a3-Cm; Fri, 19 Oct 2012 14:59:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPE2x-0007Zl-0W
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 14:59:35 +0000
Received: from [85.158.139.83:34816] by server-6.bemta-5.messagelabs.com id
	CD/0E-32589-6DA61805; Fri, 19 Oct 2012 14:59:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1350658773!28422743!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NDA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24624 invoked from network); 19 Oct 2012 14:59:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-182.messagelabs.com with SMTP;
	19 Oct 2012 14:59:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 19 Oct 2012 15:59:33 +0100
Message-Id: <508186F602000078000A2A22@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 19 Oct 2012 15:59:34 +0100
From: "Jan Beulich" 
To: "Christoph Egger" 
References: <50782D4B.50607@amd.com> <50815171.70603@amd.com>
In-Reply-To: <50815171.70603@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] x86/MCE: Implement clearbank callback for
 AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 19.10.12 at 15:11, Christoph Egger  wrote:
> Ping?

I have this on my radar to review (and commit if no significant
reason not to turns up), but I can't currently tell when I'll be able
to get to it (some time not too early next week maybe).

Sorry, Jan

> On 10/12/12 16:46, Christoph Egger wrote:
>> 
>> Implement clearbank callbank for AMD.
>> 
>> Signed-off-by: Christoph Egger 
>> 
> 
> 
> -- 
> ---to satisfy European Law for business letters:
> Advanced Micro Devices GmbH
> Einsteinring 24, 85689 Dornach b. Muenchen
> Geschaeftsfuehrer: Alberto Bozzo
> Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
> Registergericht Muenchen, HRB Nr. 43632
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 14:59:44 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 14:59:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPE2y-0007a3-Cm; Fri, 19 Oct 2012 14:59:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPE2x-0007Zl-0W
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 14:59:35 +0000
Received: from [85.158.139.83:34816] by server-6.bemta-5.messagelabs.com id
	CD/0E-32589-6DA61805; Fri, 19 Oct 2012 14:59:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1350658773!28422743!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NDA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24624 invoked from network); 19 Oct 2012 14:59:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-182.messagelabs.com with SMTP;
	19 Oct 2012 14:59:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 19 Oct 2012 15:59:33 +0100
Message-Id: <508186F602000078000A2A22@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 19 Oct 2012 15:59:34 +0100
From: "Jan Beulich" 
To: "Christoph Egger" 
References: <50782D4B.50607@amd.com> <50815171.70603@amd.com>
In-Reply-To: <50815171.70603@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] x86/MCE: Implement clearbank callback for
 AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 19.10.12 at 15:11, Christoph Egger  wrote:
> Ping?

I have this on my radar to review (and commit if no significant
reason not to turns up), but I can't currently tell when I'll be able
to get to it (some time not too early next week maybe).

Sorry, Jan

> On 10/12/12 16:46, Christoph Egger wrote:
>> 
>> Implement clearbank callbank for AMD.
>> 
>> Signed-off-by: Christoph Egger 
>> 
> 
> 
> -- 
> ---to satisfy European Law for business letters:
> Advanced Micro Devices GmbH
> Einsteinring 24, 85689 Dornach b. Muenchen
> Geschaeftsfuehrer: Alberto Bozzo
> Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
> Registergericht Muenchen, HRB Nr. 43632
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 15:01:20 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 15:01:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPE4R-0007nj-TC; Fri, 19 Oct 2012 15:01:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPE4Q-0007nQ-Ns
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 15:01:06 +0000
Received: from [85.158.139.211:42305] by server-14.bemta-5.messagelabs.com id
	4F/5B-24068-23B61805; Fri, 19 Oct 2012 15:01:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1350658865!23002624!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUwMDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17780 invoked from network); 19 Oct 2012 15:01:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 15:01:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,613,1344211200"; d="scan'208";a="15279520"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 15:01:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 19 Oct 2012 16:01:05 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TPE4O-0000Yd-Mn; Fri, 19 Oct 2012 15:01:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TPE4O-0001qz-In;
	Fri, 19 Oct 2012 16:01:04 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20609.27440.478178.971262@mariner.uk.xensource.com>
Date: Fri, 19 Oct 2012 16:01:04 +0100
To: Jan Beulich 
In-Reply-To: <5081869B02000078000A2A1F@nat28.tlf.novell.com>
References: <506EE9A7.6090009@amd.com> <50815162.4090601@amd.com>
	<5081869B02000078000A2A1F@nat28.tlf.novell.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Christoph Egger ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] tools/xen-mceinj: support AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Jan Beulich writes ("Re: [Xen-devel] [PATCH] tools/xen-mceinj: support AMD"):
> >>> On 19.10.12 at 15:10, Christoph Egger  wrote:
> > Ping?
> 
> I'm afraid it's not really clear who should commit this - it's tools
> side code, so IanJ or IanC would normally be the ones, but otoh
> it's code requiring low level hardware knowledge to review the
> patch, so both of them might want to rather not do the review.
> In the past it was usually Keir who eventually committed such
> patches, but I don't know whether he put this on his to-look-at-
> and-eventually-commit list.

My view is that I would like an ack from someone who understands
what's going on ...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 15:01:20 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 15:01:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPE4R-0007nj-TC; Fri, 19 Oct 2012 15:01:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPE4Q-0007nQ-Ns
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 15:01:06 +0000
Received: from [85.158.139.211:42305] by server-14.bemta-5.messagelabs.com id
	4F/5B-24068-23B61805; Fri, 19 Oct 2012 15:01:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1350658865!23002624!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUwMDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17780 invoked from network); 19 Oct 2012 15:01:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 15:01:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,613,1344211200"; d="scan'208";a="15279520"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 15:01:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 19 Oct 2012 16:01:05 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TPE4O-0000Yd-Mn; Fri, 19 Oct 2012 15:01:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TPE4O-0001qz-In;
	Fri, 19 Oct 2012 16:01:04 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20609.27440.478178.971262@mariner.uk.xensource.com>
Date: Fri, 19 Oct 2012 16:01:04 +0100
To: Jan Beulich 
In-Reply-To: <5081869B02000078000A2A1F@nat28.tlf.novell.com>
References: <506EE9A7.6090009@amd.com> <50815162.4090601@amd.com>
	<5081869B02000078000A2A1F@nat28.tlf.novell.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Christoph Egger ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] tools/xen-mceinj: support AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Jan Beulich writes ("Re: [Xen-devel] [PATCH] tools/xen-mceinj: support AMD"):
> >>> On 19.10.12 at 15:10, Christoph Egger  wrote:
> > Ping?
> 
> I'm afraid it's not really clear who should commit this - it's tools
> side code, so IanJ or IanC would normally be the ones, but otoh
> it's code requiring low level hardware knowledge to review the
> patch, so both of them might want to rather not do the review.
> In the past it was usually Keir who eventually committed such
> patches, but I don't know whether he put this on his to-look-at-
> and-eventually-commit list.

My view is that I would like an ack from someone who understands
what's going on ...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 15:06:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 15:06:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPE99-00087t-SI; Fri, 19 Oct 2012 15:05:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPE99-00087n-69
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 15:05:59 +0000
Received: from [85.158.143.99:19555] by server-1.bemta-4.messagelabs.com id
	E8/45-19134-65C61805; Fri, 19 Oct 2012 15:05:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1350659157!34766993!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NDA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29148 invoked from network); 19 Oct 2012 15:05:57 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-216.messagelabs.com with SMTP;
	19 Oct 2012 15:05:57 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 19 Oct 2012 16:05:56 +0100
Message-Id: <5081887502000078000A2A51@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 19 Oct 2012 16:05:57 +0100
From: "Jan Beulich" 
To: "Ian Jackson" 
References: <506EE9A7.6090009@amd.com> <50815162.4090601@amd.com>
	<5081869B02000078000A2A1F@nat28.tlf.novell.com>
	<20609.27440.478178.971262@mariner.uk.xensource.com>
In-Reply-To: <20609.27440.478178.971262@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Christoph Egger ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] tools/xen-mceinj: support AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 19.10.12 at 17:01, Ian Jackson  wrote:
> Jan Beulich writes ("Re: [Xen-devel] [PATCH] tools/xen-mceinj: support AMD"):
>> >>> On 19.10.12 at 15:10, Christoph Egger  wrote:
>> > Ping?
>> 
>> I'm afraid it's not really clear who should commit this - it's tools
>> side code, so IanJ or IanC would normally be the ones, but otoh
>> it's code requiring low level hardware knowledge to review the
>> patch, so both of them might want to rather not do the review.
>> In the past it was usually Keir who eventually committed such
>> patches, but I don't know whether he put this on his to-look-at-
>> and-eventually-commit list.
> 
> My view is that I would like an ack from someone who understands
> what's going on ...

Which would ideally be those who introduced the code, i.e.
Intel folks if I'm not mistaken...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 15:06:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 15:06:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPE99-00087t-SI; Fri, 19 Oct 2012 15:05:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPE99-00087n-69
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 15:05:59 +0000
Received: from [85.158.143.99:19555] by server-1.bemta-4.messagelabs.com id
	E8/45-19134-65C61805; Fri, 19 Oct 2012 15:05:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1350659157!34766993!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NDA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29148 invoked from network); 19 Oct 2012 15:05:57 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-216.messagelabs.com with SMTP;
	19 Oct 2012 15:05:57 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 19 Oct 2012 16:05:56 +0100
Message-Id: <5081887502000078000A2A51@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 19 Oct 2012 16:05:57 +0100
From: "Jan Beulich" 
To: "Ian Jackson" 
References: <506EE9A7.6090009@amd.com> <50815162.4090601@amd.com>
	<5081869B02000078000A2A1F@nat28.tlf.novell.com>
	<20609.27440.478178.971262@mariner.uk.xensource.com>
In-Reply-To: <20609.27440.478178.971262@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Christoph Egger ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] tools/xen-mceinj: support AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 19.10.12 at 17:01, Ian Jackson  wrote:
> Jan Beulich writes ("Re: [Xen-devel] [PATCH] tools/xen-mceinj: support AMD"):
>> >>> On 19.10.12 at 15:10, Christoph Egger  wrote:
>> > Ping?
>> 
>> I'm afraid it's not really clear who should commit this - it's tools
>> side code, so IanJ or IanC would normally be the ones, but otoh
>> it's code requiring low level hardware knowledge to review the
>> patch, so both of them might want to rather not do the review.
>> In the past it was usually Keir who eventually committed such
>> patches, but I don't know whether he put this on his to-look-at-
>> and-eventually-commit list.
> 
> My view is that I would like an ack from someone who understands
> what's going on ...

Which would ideally be those who introduced the code, i.e.
Intel folks if I'm not mistaken...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 15:08:47 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 15:08:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPEBi-0008Fc-E5; Fri, 19 Oct 2012 15:08:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPEBh-0008FX-4U
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 15:08:37 +0000
Received: from [85.158.143.99:45570] by server-3.bemta-4.messagelabs.com id
	0D/4F-03544-4FC61805; Fri, 19 Oct 2012 15:08:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1350659316!34182258!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NDA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9756 invoked from network); 19 Oct 2012 15:08:36 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-216.messagelabs.com with SMTP;
	19 Oct 2012 15:08:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 19 Oct 2012 16:08:35 +0100
Message-Id: <5081891502000078000A2A5E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 19 Oct 2012 16:08:37 +0100
From: "Jan Beulich" 
To: "Stefan Bader" 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
	<1350482118.2460.74.camel@zakaz.uk.xensource.com>
	<507ECD06.2050407@canonical.com> <507ED038.8000806@citrix.com>
	<507FC51102000078000A235E@nat28.tlf.novell.com>
	<507FC71502000078000A236C@nat28.tlf.novell.com>
	<507FB1E1.8080700@canonical.com>
	<1350546483.28188.25.camel@dagon.hellion.org.uk>
	<507FD7DE.2010209@canonical.com>
	<507FFA5102000078000A250D@nat28.tlf.novell.com>
	<507FF964.9090009@canonical.com> <50806C0B.1060504@canonical.com>
	<5081264002000078000A2841@nat28.tlf.novell.com>
	<50811047.4080200@canonical.com>
	<5081387B02000078000A288D@nat28.tlf.novell.com>
	<50815DA1.10303@canonical.com>
	<5081847E02000078000A2A09@nat28.tlf.novell.com>
	<50816A6E.5010602@canonical.com>
In-Reply-To: <50816A6E.5010602@canonical.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper ,
	Konrad Rzeszutek Wilk ,
	Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 19.10.12 at 16:57, Stefan Bader  wrote:
> On 19.10.2012 16:49, Jan Beulich wrote:
> 
>>> No, I assumed that you saying native kernel did prior to ticket lock 
>>> conversion,
>> 
>> I indeed did say that. Just go look back at the old code.
> 
> No, sorry, but no. Just that old code did it does not help me here. I di 
> believe
> you there. Still it seems there is something wrong doing it there in a pv 
> guest.

PV guest may be a little broad - did you observe such a problem
with a recent kernel of ours?

> Though I cannot give a satisfying explanation, yet.

But that's going to be necessary in order to judge whether the
brute force approach you take is really the only alternative (and
whether it's fixing the problem rather than just making it less
likely).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 15:08:47 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 15:08:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPEBi-0008Fc-E5; Fri, 19 Oct 2012 15:08:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPEBh-0008FX-4U
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 15:08:37 +0000
Received: from [85.158.143.99:45570] by server-3.bemta-4.messagelabs.com id
	0D/4F-03544-4FC61805; Fri, 19 Oct 2012 15:08:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1350659316!34182258!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NDA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9756 invoked from network); 19 Oct 2012 15:08:36 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-216.messagelabs.com with SMTP;
	19 Oct 2012 15:08:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 19 Oct 2012 16:08:35 +0100
Message-Id: <5081891502000078000A2A5E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 19 Oct 2012 16:08:37 +0100
From: "Jan Beulich" 
To: "Stefan Bader" 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
	<1350482118.2460.74.camel@zakaz.uk.xensource.com>
	<507ECD06.2050407@canonical.com> <507ED038.8000806@citrix.com>
	<507FC51102000078000A235E@nat28.tlf.novell.com>
	<507FC71502000078000A236C@nat28.tlf.novell.com>
	<507FB1E1.8080700@canonical.com>
	<1350546483.28188.25.camel@dagon.hellion.org.uk>
	<507FD7DE.2010209@canonical.com>
	<507FFA5102000078000A250D@nat28.tlf.novell.com>
	<507FF964.9090009@canonical.com> <50806C0B.1060504@canonical.com>
	<5081264002000078000A2841@nat28.tlf.novell.com>
	<50811047.4080200@canonical.com>
	<5081387B02000078000A288D@nat28.tlf.novell.com>
	<50815DA1.10303@canonical.com>
	<5081847E02000078000A2A09@nat28.tlf.novell.com>
	<50816A6E.5010602@canonical.com>
In-Reply-To: <50816A6E.5010602@canonical.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper ,
	Konrad Rzeszutek Wilk ,
	Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 19.10.12 at 16:57, Stefan Bader  wrote:
> On 19.10.2012 16:49, Jan Beulich wrote:
> 
>>> No, I assumed that you saying native kernel did prior to ticket lock 
>>> conversion,
>> 
>> I indeed did say that. Just go look back at the old code.
> 
> No, sorry, but no. Just that old code did it does not help me here. I di 
> believe
> you there. Still it seems there is something wrong doing it there in a pv 
> guest.

PV guest may be a little broad - did you observe such a problem
with a recent kernel of ours?

> Though I cannot give a satisfying explanation, yet.

But that's going to be necessary in order to judge whether the
brute force approach you take is really the only alternative (and
whether it's fixing the problem rather than just making it less
likely).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 15:15:12 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 15:15:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPEHo-00008z-Lg; Fri, 19 Oct 2012 15:14:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPEHn-00008p-Au
	for xen-devel@lists.xensource.com; Fri, 19 Oct 2012 15:14:55 +0000
Received: from [193.109.254.147:39582] by server-10.bemta-14.messagelabs.com
	id E7/BF-12590-E6E61805; Fri, 19 Oct 2012 15:14:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1350659692!10477360!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUwMDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7963 invoked from network); 19 Oct 2012 15:14:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 15:14:53 -0000
X-IronPort-AV: E=Sophos;i="4.80,613,1344211200"; d="scan'208";a="15279814"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 15:14:49 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 19 Oct 2012 16:14:49 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TPEHg-0000g0-K2; Fri, 19 Oct 2012 15:14:48 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TPEHg-0001s6-GC;
	Fri, 19 Oct 2012 16:14:48 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20609.28264.158580.995717@mariner.uk.xensource.com>
Date: Fri, 19 Oct 2012 16:14:48 +0100
To: "Liu, Jinsong" 
Newsgroups: chiark.mail.xen.devel
In-Reply-To: 
References: 
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 5/5] X86/vMCE: guest broken page handling
	when	migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Liu, Jinsong writes ("[Xen-devel] [PATCH 5/5] X86/vMCE: guest broken page handling when migration"):
> X86/vMCE: guest broken page handling when migration
> 
> This patch is used to handle guest broken page when migration.

This looks plausible to me, as far as the tools go.  Can you explain
how you have tested this ?  Did you manage to do any tests of the
remus codepaths ?

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 15:15:12 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 15:15:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPEHo-00008z-Lg; Fri, 19 Oct 2012 15:14:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPEHn-00008p-Au
	for xen-devel@lists.xensource.com; Fri, 19 Oct 2012 15:14:55 +0000
Received: from [193.109.254.147:39582] by server-10.bemta-14.messagelabs.com
	id E7/BF-12590-E6E61805; Fri, 19 Oct 2012 15:14:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1350659692!10477360!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUwMDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7963 invoked from network); 19 Oct 2012 15:14:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 15:14:53 -0000
X-IronPort-AV: E=Sophos;i="4.80,613,1344211200"; d="scan'208";a="15279814"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 15:14:49 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 19 Oct 2012 16:14:49 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TPEHg-0000g0-K2; Fri, 19 Oct 2012 15:14:48 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TPEHg-0001s6-GC;
	Fri, 19 Oct 2012 16:14:48 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20609.28264.158580.995717@mariner.uk.xensource.com>
Date: Fri, 19 Oct 2012 16:14:48 +0100
To: "Liu, Jinsong" 
Newsgroups: chiark.mail.xen.devel
In-Reply-To: 
References: 
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 5/5] X86/vMCE: guest broken page handling
	when	migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Liu, Jinsong writes ("[Xen-devel] [PATCH 5/5] X86/vMCE: guest broken page handling when migration"):
> X86/vMCE: guest broken page handling when migration
> 
> This patch is used to handle guest broken page when migration.

This looks plausible to me, as far as the tools go.  Can you explain
how you have tested this ?  Did you manage to do any tests of the
remus codepaths ?

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 15:21:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 15:21:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPENt-0000LS-K2; Fri, 19 Oct 2012 15:21:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPENs-0000LN-Cx
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 15:21:12 +0000
Received: from [85.158.143.99:22212] by server-3.bemta-4.messagelabs.com id
	A0/5E-03544-7EF61805; Fri, 19 Oct 2012 15:21:11 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1350660071!25189920!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12112 invoked from network); 19 Oct 2012 15:21:11 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-14.tower-216.messagelabs.com with SMTP;
	19 Oct 2012 15:21:11 -0000
Received: from p5b2e238c.dip.t-dialin.net ([91.46.35.140] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from )
	id 1TPENo-0006A6-5P; Fri, 19 Oct 2012 15:21:08 +0000
Message-ID: <50816FE0.8040005@canonical.com>
Date: Fri, 19 Oct 2012 17:21:04 +0200
From: Stefan Bader 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Jan Beulich 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
	<1350482118.2460.74.camel@zakaz.uk.xensource.com>
	<507ECD06.2050407@canonical.com> <507ED038.8000806@citrix.com>
	<507FC51102000078000A235E@nat28.tlf.novell.com>
	<507FC71502000078000A236C@nat28.tlf.novell.com>
	<507FB1E1.8080700@canonical.com>
	<1350546483.28188.25.camel@dagon.hellion.org.uk>
	<507FD7DE.2010209@canonical.com>
	<507FFA5102000078000A250D@nat28.tlf.novell.com>
	<507FF964.9090009@canonical.com> <50806C0B.1060504@canonical.com>
	<5081264002000078000A2841@nat28.tlf.novell.com>
	<50811047.4080200@canonical.com>
	<5081387B02000078000A288D@nat28.tlf.novell.com>
	<50815DA1.10303@canonical.com>
	<5081847E02000078000A2A09@nat28.tlf.novell.com>
	<50816A6E.5010602@canonical.com>
	<5081891502000078000A2A5E@nat28.tlf.novell.com>
In-Reply-To: <5081891502000078000A2A5E@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.5
Cc: Andrew Cooper ,
	Konrad Rzeszutek Wilk ,
	Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============8997834106549331608=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============8997834106549331608==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig2B081FC376051B1C34B5D444"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig2B081FC376051B1C34B5D444
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 19.10.2012 17:08, Jan Beulich wrote:
>>>> On 19.10.12 at 16:57, Stefan Bader  wrot=
e:
>> On 19.10.2012 16:49, Jan Beulich wrote:
>>
>>>> No, I assumed that you saying native kernel did prior to ticket lock=
=20
>>>> conversion,
>>>
>>> I indeed did say that. Just go look back at the old code.
>>
>> No, sorry, but no. Just that old code did it does not help me here. I =
di=20
>> believe
>> you there. Still it seems there is something wrong doing it there in a=
 pv=20
>> guest.
>=20
> PV guest may be a little broad - did you observe such a problem
> with a recent kernel of ours?

3.2 (ok, older) and 3.5 up to now, certainly can and should retry with at=
 least
3.6. And on the host side it was on Amazon EC2 and locally with a 4.1.2 h=
ost.

>=20
>> Though I cannot give a satisfying explanation, yet.
>=20
> But that's going to be necessary in order to judge whether the
> brute force approach you take is really the only alternative (and
> whether it's fixing the problem rather than just making it less
> likely).

I know. Unfortunately that means digging quite deeply in the not-so-well-=
known.
And it does not help either that the backtraces in the dump seem not comp=
letely
trustworthy. Like vcpus that the host says are polling on a certain event=
channel
do not seem to be sitting on the hypercall.
>=20
> Jan
>=20



--------------enig2B081FC376051B1C34B5D444
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBCgAGBQJQgW/gAAoJEOhnXe7L7s6jrtcP+weopkZ7G+evMPbIzjfeAETk
N7ANMgK+x9Cx1SkRo5ZvchKiHQgj6vWUlqQ5d0zCt80oRKcNInOrpiFvytnLI1bE
6X9CVAI+ppHH5B1H76z3lg3joKU5Il6hwhDtCeRd+KQ9Rd/etQty8/5MbHQ3oTG8
vY3E8ZpzKRjNyLO5l9dRenPLa9W8KrtcmUv+IUNsziVz91fooHZEsn+HdvQYIc67
AbddXjv9ODL8a4i4Mpe+WkpdEnYyjoFsryjrgrxpKHYQ8/Sp3kDwF6aknNRChAUF
BcwGaSnUrC1Rl1TKeYc8L0lQa2/pWtTjc4Vezek3Fk8P0BIiWFs+Akop8IZVH1m3
Qe0gP68vbyLHDECzXMm1CzFfNWIpqtKR7YMLKEwHhD4jM2xflULrD2PYRbsgs8MF
eDTqQQG5t2V6nRS0Dv4aHE9dxYzjWwqKPiiAOv6hTgkoo7m0rm5KmVFpb3+TGDSS
x+YMhdMIRN/hCzd7Q47fqf2HMPetnsOs8MdKt+52ljJ0AR0BZ+CwR3cMfJlImPeL
jArTz4rsGhyH75t9JZ/xV4nP+TQsAIJSOKqjBBD/AccqS7mVvje/R51dHHL6XqKn
Uq2KaRfU1tQXqJnvXxcRdyaajx2g5UbCkoJOKr6vzdAl1CLMyAYIT37koTzKbazZ
QZZF2lQkuat1BJrc8BXQ
=KzR2
-----END PGP SIGNATURE-----

--------------enig2B081FC376051B1C34B5D444--


--===============8997834106549331608==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8997834106549331608==--


From xen-devel-bounces@lists.xen.org Fri Oct 19 15:21:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 15:21:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPENt-0000LS-K2; Fri, 19 Oct 2012 15:21:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPENs-0000LN-Cx
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 15:21:12 +0000
Received: from [85.158.143.99:22212] by server-3.bemta-4.messagelabs.com id
	A0/5E-03544-7EF61805; Fri, 19 Oct 2012 15:21:11 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1350660071!25189920!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12112 invoked from network); 19 Oct 2012 15:21:11 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-14.tower-216.messagelabs.com with SMTP;
	19 Oct 2012 15:21:11 -0000
Received: from p5b2e238c.dip.t-dialin.net ([91.46.35.140] helo=[192.168.2.5])
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
	(envelope-from )
	id 1TPENo-0006A6-5P; Fri, 19 Oct 2012 15:21:08 +0000
Message-ID: <50816FE0.8040005@canonical.com>
Date: Fri, 19 Oct 2012 17:21:04 +0200
From: Stefan Bader 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Jan Beulich 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
	<1350482118.2460.74.camel@zakaz.uk.xensource.com>
	<507ECD06.2050407@canonical.com> <507ED038.8000806@citrix.com>
	<507FC51102000078000A235E@nat28.tlf.novell.com>
	<507FC71502000078000A236C@nat28.tlf.novell.com>
	<507FB1E1.8080700@canonical.com>
	<1350546483.28188.25.camel@dagon.hellion.org.uk>
	<507FD7DE.2010209@canonical.com>
	<507FFA5102000078000A250D@nat28.tlf.novell.com>
	<507FF964.9090009@canonical.com> <50806C0B.1060504@canonical.com>
	<5081264002000078000A2841@nat28.tlf.novell.com>
	<50811047.4080200@canonical.com>
	<5081387B02000078000A288D@nat28.tlf.novell.com>
	<50815DA1.10303@canonical.com>
	<5081847E02000078000A2A09@nat28.tlf.novell.com>
	<50816A6E.5010602@canonical.com>
	<5081891502000078000A2A5E@nat28.tlf.novell.com>
In-Reply-To: <5081891502000078000A2A5E@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.5
Cc: Andrew Cooper ,
	Konrad Rzeszutek Wilk ,
	Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============8997834106549331608=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============8997834106549331608==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig2B081FC376051B1C34B5D444"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig2B081FC376051B1C34B5D444
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 19.10.2012 17:08, Jan Beulich wrote:
>>>> On 19.10.12 at 16:57, Stefan Bader  wrot=
e:
>> On 19.10.2012 16:49, Jan Beulich wrote:
>>
>>>> No, I assumed that you saying native kernel did prior to ticket lock=
=20
>>>> conversion,
>>>
>>> I indeed did say that. Just go look back at the old code.
>>
>> No, sorry, but no. Just that old code did it does not help me here. I =
di=20
>> believe
>> you there. Still it seems there is something wrong doing it there in a=
 pv=20
>> guest.
>=20
> PV guest may be a little broad - did you observe such a problem
> with a recent kernel of ours?

3.2 (ok, older) and 3.5 up to now, certainly can and should retry with at=
 least
3.6. And on the host side it was on Amazon EC2 and locally with a 4.1.2 h=
ost.

>=20
>> Though I cannot give a satisfying explanation, yet.
>=20
> But that's going to be necessary in order to judge whether the
> brute force approach you take is really the only alternative (and
> whether it's fixing the problem rather than just making it less
> likely).

I know. Unfortunately that means digging quite deeply in the not-so-well-=
known.
And it does not help either that the backtraces in the dump seem not comp=
letely
trustworthy. Like vcpus that the host says are polling on a certain event=
channel
do not seem to be sitting on the hypercall.
>=20
> Jan
>=20



--------------enig2B081FC376051B1C34B5D444
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBCgAGBQJQgW/gAAoJEOhnXe7L7s6jrtcP+weopkZ7G+evMPbIzjfeAETk
N7ANMgK+x9Cx1SkRo5ZvchKiHQgj6vWUlqQ5d0zCt80oRKcNInOrpiFvytnLI1bE
6X9CVAI+ppHH5B1H76z3lg3joKU5Il6hwhDtCeRd+KQ9Rd/etQty8/5MbHQ3oTG8
vY3E8ZpzKRjNyLO5l9dRenPLa9W8KrtcmUv+IUNsziVz91fooHZEsn+HdvQYIc67
AbddXjv9ODL8a4i4Mpe+WkpdEnYyjoFsryjrgrxpKHYQ8/Sp3kDwF6aknNRChAUF
BcwGaSnUrC1Rl1TKeYc8L0lQa2/pWtTjc4Vezek3Fk8P0BIiWFs+Akop8IZVH1m3
Qe0gP68vbyLHDECzXMm1CzFfNWIpqtKR7YMLKEwHhD4jM2xflULrD2PYRbsgs8MF
eDTqQQG5t2V6nRS0Dv4aHE9dxYzjWwqKPiiAOv6hTgkoo7m0rm5KmVFpb3+TGDSS
x+YMhdMIRN/hCzd7Q47fqf2HMPetnsOs8MdKt+52ljJ0AR0BZ+CwR3cMfJlImPeL
jArTz4rsGhyH75t9JZ/xV4nP+TQsAIJSOKqjBBD/AccqS7mVvje/R51dHHL6XqKn
Uq2KaRfU1tQXqJnvXxcRdyaajx2g5UbCkoJOKr6vzdAl1CLMyAYIT37koTzKbazZ
QZZF2lQkuat1BJrc8BXQ
=KzR2
-----END PGP SIGNATURE-----

--------------enig2B081FC376051B1C34B5D444--


--===============8997834106549331608==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8997834106549331608==--


From xen-devel-bounces@lists.xen.org Fri Oct 19 15:29:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 15:29:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPEVr-0000Yp-Ta; Fri, 19 Oct 2012 15:29:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPEVq-0000Yj-QQ
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 15:29:27 +0000
Received: from [85.158.139.211:31790] by server-11.bemta-5.messagelabs.com id
	CE/A0-14870-6D171805; Fri, 19 Oct 2012 15:29:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1350660564!22998569!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NDA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13124 invoked from network); 19 Oct 2012 15:29:25 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-206.messagelabs.com with SMTP;
	19 Oct 2012 15:29:25 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 19 Oct 2012 16:29:24 +0100
Message-Id: <50818DF502000078000A2A84@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 19 Oct 2012 16:29:24 +0100
From: "Jan Beulich" 
To: "David Vrabel" 
References: <1350480580-4844-1-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1350480580-4844-1-git-send-email-david.vrabel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Frediano Ziglio ,
	Konrad Rzeszutek Wilk ,
	stable@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCHv2] xen/x86: don't corrupt %eip when
 returning from a signal handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 17.10.12 at 15:29, David Vrabel  wrote:
> From: David Vrabel 
> 
> In 32 bit guests, if a userspace process has %eax == -ERESTARTSYS
> (-512) or -ERESTARTNOINTR (-513) when it is interrupted by an event
> /and/ the process has a pending signal then %eip (and %eax) are
> corrupted when returning to the main process after handling the
> signal.  The application may then crash with SIGSEGV or a SIGILL or it
> may have subtly incorrect behaviour (depending on what instruction it
> returned to).
> 
> The occurs because handle_signal() is incorrectly thinking that there
> is a system call that needs to restarted so it adjusts %eip and %eax
> to re-execute the system call instruction (even though user space had
> not done a system call).
> 
> If %eax == -514 (-ERESTARTNOHAND (-514) or -ERESTART_RESTARTBLOCK
> (-516) then handle_signal() only corrupted %eax (by setting it to
> -EINTR).  This may cause the application to crash or have incorrect
> behaviour.
> 
> handle_signal() assumes that regs->orig_ax >= 0 means a system call so
> any kernel entry point that is not for a system call must push a
> negative value for orig_ax.  For example, for physical interrupts on
> bare metal the inverse of the vector is pushed and page_fault() sets
> regs->orig_ax to -1, overwriting the hardware provided error code.
> 
> xen_hypervisor_callback() was incorrectly pushing 0 for orig_ax
> instead of -1.
> 
> Classic Xen kernels pushed %eax which works as %eax cannot be both
> non-negative and -RESTARTSYS (etc.), but using -1 is consistent with
> other non-system call entry points.
> 
> There were similar bugs in xen_failsafe_callback(), if the fault was
> corrected and normal return path was used.  64 bit guests would push 0
> which is broken.  32 bit guests would push %eax which is safe (see
> previous paragraph), but for consistency this is also changed to -1.
> 
> Signed-off-by: David Vrabel 
> Acked-by: Jan Beulich 
> Acked-by: Ian Campbell 
> Cc: stable@vger.kernel.org 
> ---
>  arch/x86/kernel/entry_32.S |    4 ++--
>  arch/x86/kernel/entry_64.S |    2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
> index 2c63407..6a19e66 100644
> --- a/arch/x86/kernel/entry_32.S
> +++ b/arch/x86/kernel/entry_32.S
> @@ -1042,7 +1042,7 @@ ENTRY(xen_sysenter_target)
>  
>  ENTRY(xen_hypervisor_callback)
>  	CFI_STARTPROC
> -	pushl_cfi $0
> +	pushl_cfi $-1 /* orig_ax = -1 => not a system call */
>  	SAVE_ALL
>  	TRACE_IRQS_OFF
>  
> @@ -1078,7 +1078,7 @@ ENDPROC(xen_hypervisor_callback)
>  # We distinguish between categories by maintaining a status value in EAX.
>  ENTRY(xen_failsafe_callback)
>  	CFI_STARTPROC
> -	pushl_cfi %eax
> +	pushl_cfi $-1  /* orig_ax = -1 => not a system call */

While making this apply to the 2.6.18 tree, I noticed that you
replaced the wrong push here, thus causing register corruption.
Just like on the 64-bit side, the one that needs fixing is the one
right before the SAVE_ALL (and hence it's again not just for
consistency, as zero is being pushed there too).

Jan

>  	movl $1,%eax
>  1:	mov 4(%esp),%ds
>  2:	mov 8(%esp),%es
> diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
> index cdc790c..430b1fc 100644
> --- a/arch/x86/kernel/entry_64.S
> +++ b/arch/x86/kernel/entry_64.S
> @@ -1451,7 +1451,7 @@ ENTRY(xen_failsafe_callback)
>  	CFI_RESTORE r11
>  	addq $0x30,%rsp
>  	CFI_ADJUST_CFA_OFFSET -0x30
> -	pushq_cfi $0
> +	pushq_cfi $-1 /* orig_ax = -1 => not a system call */
>  	SAVE_ALL
>  	jmp error_exit
>  	CFI_ENDPROC
> -- 
> 1.7.2.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 15:29:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 15:29:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPEVr-0000Yp-Ta; Fri, 19 Oct 2012 15:29:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPEVq-0000Yj-QQ
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 15:29:27 +0000
Received: from [85.158.139.211:31790] by server-11.bemta-5.messagelabs.com id
	CE/A0-14870-6D171805; Fri, 19 Oct 2012 15:29:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1350660564!22998569!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NDA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13124 invoked from network); 19 Oct 2012 15:29:25 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-206.messagelabs.com with SMTP;
	19 Oct 2012 15:29:25 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 19 Oct 2012 16:29:24 +0100
Message-Id: <50818DF502000078000A2A84@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 19 Oct 2012 16:29:24 +0100
From: "Jan Beulich" 
To: "David Vrabel" 
References: <1350480580-4844-1-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1350480580-4844-1-git-send-email-david.vrabel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Frediano Ziglio ,
	Konrad Rzeszutek Wilk ,
	stable@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCHv2] xen/x86: don't corrupt %eip when
 returning from a signal handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 17.10.12 at 15:29, David Vrabel  wrote:
> From: David Vrabel 
> 
> In 32 bit guests, if a userspace process has %eax == -ERESTARTSYS
> (-512) or -ERESTARTNOINTR (-513) when it is interrupted by an event
> /and/ the process has a pending signal then %eip (and %eax) are
> corrupted when returning to the main process after handling the
> signal.  The application may then crash with SIGSEGV or a SIGILL or it
> may have subtly incorrect behaviour (depending on what instruction it
> returned to).
> 
> The occurs because handle_signal() is incorrectly thinking that there
> is a system call that needs to restarted so it adjusts %eip and %eax
> to re-execute the system call instruction (even though user space had
> not done a system call).
> 
> If %eax == -514 (-ERESTARTNOHAND (-514) or -ERESTART_RESTARTBLOCK
> (-516) then handle_signal() only corrupted %eax (by setting it to
> -EINTR).  This may cause the application to crash or have incorrect
> behaviour.
> 
> handle_signal() assumes that regs->orig_ax >= 0 means a system call so
> any kernel entry point that is not for a system call must push a
> negative value for orig_ax.  For example, for physical interrupts on
> bare metal the inverse of the vector is pushed and page_fault() sets
> regs->orig_ax to -1, overwriting the hardware provided error code.
> 
> xen_hypervisor_callback() was incorrectly pushing 0 for orig_ax
> instead of -1.
> 
> Classic Xen kernels pushed %eax which works as %eax cannot be both
> non-negative and -RESTARTSYS (etc.), but using -1 is consistent with
> other non-system call entry points.
> 
> There were similar bugs in xen_failsafe_callback(), if the fault was
> corrected and normal return path was used.  64 bit guests would push 0
> which is broken.  32 bit guests would push %eax which is safe (see
> previous paragraph), but for consistency this is also changed to -1.
> 
> Signed-off-by: David Vrabel 
> Acked-by: Jan Beulich 
> Acked-by: Ian Campbell 
> Cc: stable@vger.kernel.org 
> ---
>  arch/x86/kernel/entry_32.S |    4 ++--
>  arch/x86/kernel/entry_64.S |    2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
> index 2c63407..6a19e66 100644
> --- a/arch/x86/kernel/entry_32.S
> +++ b/arch/x86/kernel/entry_32.S
> @@ -1042,7 +1042,7 @@ ENTRY(xen_sysenter_target)
>  
>  ENTRY(xen_hypervisor_callback)
>  	CFI_STARTPROC
> -	pushl_cfi $0
> +	pushl_cfi $-1 /* orig_ax = -1 => not a system call */
>  	SAVE_ALL
>  	TRACE_IRQS_OFF
>  
> @@ -1078,7 +1078,7 @@ ENDPROC(xen_hypervisor_callback)
>  # We distinguish between categories by maintaining a status value in EAX.
>  ENTRY(xen_failsafe_callback)
>  	CFI_STARTPROC
> -	pushl_cfi %eax
> +	pushl_cfi $-1  /* orig_ax = -1 => not a system call */

While making this apply to the 2.6.18 tree, I noticed that you
replaced the wrong push here, thus causing register corruption.
Just like on the 64-bit side, the one that needs fixing is the one
right before the SAVE_ALL (and hence it's again not just for
consistency, as zero is being pushed there too).

Jan

>  	movl $1,%eax
>  1:	mov 4(%esp),%ds
>  2:	mov 8(%esp),%es
> diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
> index cdc790c..430b1fc 100644
> --- a/arch/x86/kernel/entry_64.S
> +++ b/arch/x86/kernel/entry_64.S
> @@ -1451,7 +1451,7 @@ ENTRY(xen_failsafe_callback)
>  	CFI_RESTORE r11
>  	addq $0x30,%rsp
>  	CFI_ADJUST_CFA_OFFSET -0x30
> -	pushq_cfi $0
> +	pushq_cfi $-1 /* orig_ax = -1 => not a system call */
>  	SAVE_ALL
>  	jmp error_exit
>  	CFI_ENDPROC
> -- 
> 1.7.2.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 15:34:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 15:34:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPEa4-0000jt-UV; Fri, 19 Oct 2012 15:33:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPEa2-0000jn-Nv
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 15:33:46 +0000
Received: from [85.158.138.51:11549] by server-16.bemta-3.messagelabs.com id
	36/31-16565-9D271805; Fri, 19 Oct 2012 15:33:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1350660825!34955531!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NDA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3391 invoked from network); 19 Oct 2012 15:33:45 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-174.messagelabs.com with SMTP;
	19 Oct 2012 15:33:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 19 Oct 2012 16:33:44 +0100
Message-Id: <50818EF902000078000A2A92@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 19 Oct 2012 16:33:45 +0100
From: "Jan Beulich" 
To: "Stefan Bader" 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
	<1350482118.2460.74.camel@zakaz.uk.xensource.com>
	<507ECD06.2050407@canonical.com> <507ED038.8000806@citrix.com>
	<507FC51102000078000A235E@nat28.tlf.novell.com>
	<507FC71502000078000A236C@nat28.tlf.novell.com>
	<507FB1E1.8080700@canonical.com>
	<1350546483.28188.25.camel@dagon.hellion.org.uk>
	<507FD7DE.2010209@canonical.com>
	<507FFA5102000078000A250D@nat28.tlf.novell.com>
	<507FF964.9090009@canonical.com> <50806C0B.1060504@canonical.com>
	<5081264002000078000A2841@nat28.tlf.novell.com>
	<50811047.4080200@canonical.com>
	<5081387B02000078000A288D@nat28.tlf.novell.com>
	<50815DA1.10303@canonical.com>
	<5081847E02000078000A2A09@nat28.tlf.novell.com>
	<50816A6E.5010602@canonical.com>
	<5081891502000078000A2A5E@nat28.tlf.novell.com>
	<50816FE0.8040005@canonical.com>
In-Reply-To: <50816FE0.8040005@canonical.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper ,
	Konrad Rzeszutek Wilk ,
	Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 19.10.12 at 17:21, Stefan Bader  wrote:
> On 19.10.2012 17:08, Jan Beulich wrote:
>>>>> On 19.10.12 at 16:57, Stefan Bader  wrote:
>>> On 19.10.2012 16:49, Jan Beulich wrote:
>>>
>>>>> No, I assumed that you saying native kernel did prior to ticket lock 
>>>>> conversion,
>>>>
>>>> I indeed did say that. Just go look back at the old code.
>>>
>>> No, sorry, but no. Just that old code did it does not help me here. I di 
>>> believe
>>> you there. Still it seems there is something wrong doing it there in a pv 
>>> guest.
>> 
>> PV guest may be a little broad - did you observe such a problem
>> with a recent kernel of ours?
> 
> 3.2 (ok, older) and 3.5 up to now, certainly can and should retry with at 
> least
> 3.6. And on the host side it was on Amazon EC2 and locally with a 4.1.2 
> host.

Anything 3.0 and newer is more or less the same spin lock wise; did
you ever open a bug report for this?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 15:34:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 15:34:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPEa4-0000jt-UV; Fri, 19 Oct 2012 15:33:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPEa2-0000jn-Nv
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 15:33:46 +0000
Received: from [85.158.138.51:11549] by server-16.bemta-3.messagelabs.com id
	36/31-16565-9D271805; Fri, 19 Oct 2012 15:33:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1350660825!34955531!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NDA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3391 invoked from network); 19 Oct 2012 15:33:45 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-174.messagelabs.com with SMTP;
	19 Oct 2012 15:33:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 19 Oct 2012 16:33:44 +0100
Message-Id: <50818EF902000078000A2A92@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 19 Oct 2012 16:33:45 +0100
From: "Jan Beulich" 
To: "Stefan Bader" 
References: <1350479456-4007-1-git-send-email-stefan.bader@canonical.com>
	<507EB27D.8050308@citrix.com>
	<1350482118.2460.74.camel@zakaz.uk.xensource.com>
	<507ECD06.2050407@canonical.com> <507ED038.8000806@citrix.com>
	<507FC51102000078000A235E@nat28.tlf.novell.com>
	<507FC71502000078000A236C@nat28.tlf.novell.com>
	<507FB1E1.8080700@canonical.com>
	<1350546483.28188.25.camel@dagon.hellion.org.uk>
	<507FD7DE.2010209@canonical.com>
	<507FFA5102000078000A250D@nat28.tlf.novell.com>
	<507FF964.9090009@canonical.com> <50806C0B.1060504@canonical.com>
	<5081264002000078000A2841@nat28.tlf.novell.com>
	<50811047.4080200@canonical.com>
	<5081387B02000078000A288D@nat28.tlf.novell.com>
	<50815DA1.10303@canonical.com>
	<5081847E02000078000A2A09@nat28.tlf.novell.com>
	<50816A6E.5010602@canonical.com>
	<5081891502000078000A2A5E@nat28.tlf.novell.com>
	<50816FE0.8040005@canonical.com>
In-Reply-To: <50816FE0.8040005@canonical.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Andrew Cooper ,
	Konrad Rzeszutek Wilk ,
	Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Xen PVM: Strange lockups when running PostgreSQL
 load
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 19.10.12 at 17:21, Stefan Bader  wrote:
> On 19.10.2012 17:08, Jan Beulich wrote:
>>>>> On 19.10.12 at 16:57, Stefan Bader  wrote:
>>> On 19.10.2012 16:49, Jan Beulich wrote:
>>>
>>>>> No, I assumed that you saying native kernel did prior to ticket lock 
>>>>> conversion,
>>>>
>>>> I indeed did say that. Just go look back at the old code.
>>>
>>> No, sorry, but no. Just that old code did it does not help me here. I di 
>>> believe
>>> you there. Still it seems there is something wrong doing it there in a pv 
>>> guest.
>> 
>> PV guest may be a little broad - did you observe such a problem
>> with a recent kernel of ours?
> 
> 3.2 (ok, older) and 3.5 up to now, certainly can and should retry with at 
> least
> 3.6. And on the host side it was on Amazon EC2 and locally with a 4.1.2 
> host.

Anything 3.0 and newer is more or less the same spin lock wise; did
you ever open a bug report for this?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 15:44:22 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 15:44:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPEk2-0000wo-Dl; Fri, 19 Oct 2012 15:44:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPEk1-0000wj-3S
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 15:44:05 +0000
Received: from [85.158.139.211:23216] by server-3.bemta-5.messagelabs.com id
	3A/A0-28618-44571805; Fri, 19 Oct 2012 15:44:04 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1350661442!22980632!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzc3ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7505 invoked from network); 19 Oct 2012 15:44:03 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 15:44:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,613,1344211200"; d="scan'208";a="41842567"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 15:44:01 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Fri, 19 Oct 2012
	11:44:01 -0400
Message-ID: <50817540.5070908@citrix.com>
Date: Fri, 19 Oct 2012 16:44:00 +0100
From: David Vrabel 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Jan Beulich 
References: <1350480580-4844-1-git-send-email-david.vrabel@citrix.com>
	<50818DF502000078000A2A84@nat28.tlf.novell.com>
In-Reply-To: <50818DF502000078000A2A84@nat28.tlf.novell.com>
Cc: Frediano Ziglio ,
	Konrad Rzeszutek Wilk ,
	"stable@vger.kernel.org" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCHv2] xen/x86: don't corrupt %eip when
 returning from a signal handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 19/10/12 16:29, Jan Beulich wrote:
>>>> On 17.10.12 at 15:29, David Vrabel  wrote:
>> From: David Vrabel 
>>
>> In 32 bit guests, if a userspace process has %eax == -ERESTARTSYS
>> (-512) or -ERESTARTNOINTR (-513) when it is interrupted by an event
>> /and/ the process has a pending signal then %eip (and %eax) are
>> corrupted when returning to the main process after handling the
>> signal.  The application may then crash with SIGSEGV or a SIGILL or it
>> may have subtly incorrect behaviour (depending on what instruction it
>> returned to).
>>
[...]
>> diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
>> index 2c63407..6a19e66 100644
>> --- a/arch/x86/kernel/entry_32.S
>> +++ b/arch/x86/kernel/entry_32.S
>> @@ -1042,7 +1042,7 @@ ENTRY(xen_sysenter_target)
>>  
>>  ENTRY(xen_hypervisor_callback)
>>  	CFI_STARTPROC
>> -	pushl_cfi $0
>> +	pushl_cfi $-1 /* orig_ax = -1 => not a system call */
>>  	SAVE_ALL
>>  	TRACE_IRQS_OFF
>>  
>> @@ -1078,7 +1078,7 @@ ENDPROC(xen_hypervisor_callback)
>>  # We distinguish between categories by maintaining a status value in EAX.
>>  ENTRY(xen_failsafe_callback)
>>  	CFI_STARTPROC
>> -	pushl_cfi %eax
>> +	pushl_cfi $-1  /* orig_ax = -1 => not a system call */
> 
> While making this apply to the 2.6.18 tree, I noticed that you
> replaced the wrong push here, thus causing register corruption.
> Just like on the 64-bit side, the one that needs fixing is the one
> right before the SAVE_ALL (and hence it's again not just for
> consistency, as zero is being pushed there too).

Oops.

We would have liked to test this path but could not see how to.  Do you
have any ideas?

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 15:44:22 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 15:44:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPEk2-0000wo-Dl; Fri, 19 Oct 2012 15:44:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPEk1-0000wj-3S
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 15:44:05 +0000
Received: from [85.158.139.211:23216] by server-3.bemta-5.messagelabs.com id
	3A/A0-28618-44571805; Fri, 19 Oct 2012 15:44:04 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1350661442!22980632!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzc3ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7505 invoked from network); 19 Oct 2012 15:44:03 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 15:44:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,613,1344211200"; d="scan'208";a="41842567"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 15:44:01 +0000
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Fri, 19 Oct 2012
	11:44:01 -0400
Message-ID: <50817540.5070908@citrix.com>
Date: Fri, 19 Oct 2012 16:44:00 +0100
From: David Vrabel 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Jan Beulich 
References: <1350480580-4844-1-git-send-email-david.vrabel@citrix.com>
	<50818DF502000078000A2A84@nat28.tlf.novell.com>
In-Reply-To: <50818DF502000078000A2A84@nat28.tlf.novell.com>
Cc: Frediano Ziglio ,
	Konrad Rzeszutek Wilk ,
	"stable@vger.kernel.org" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCHv2] xen/x86: don't corrupt %eip when
 returning from a signal handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 19/10/12 16:29, Jan Beulich wrote:
>>>> On 17.10.12 at 15:29, David Vrabel  wrote:
>> From: David Vrabel 
>>
>> In 32 bit guests, if a userspace process has %eax == -ERESTARTSYS
>> (-512) or -ERESTARTNOINTR (-513) when it is interrupted by an event
>> /and/ the process has a pending signal then %eip (and %eax) are
>> corrupted when returning to the main process after handling the
>> signal.  The application may then crash with SIGSEGV or a SIGILL or it
>> may have subtly incorrect behaviour (depending on what instruction it
>> returned to).
>>
[...]
>> diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
>> index 2c63407..6a19e66 100644
>> --- a/arch/x86/kernel/entry_32.S
>> +++ b/arch/x86/kernel/entry_32.S
>> @@ -1042,7 +1042,7 @@ ENTRY(xen_sysenter_target)
>>  
>>  ENTRY(xen_hypervisor_callback)
>>  	CFI_STARTPROC
>> -	pushl_cfi $0
>> +	pushl_cfi $-1 /* orig_ax = -1 => not a system call */
>>  	SAVE_ALL
>>  	TRACE_IRQS_OFF
>>  
>> @@ -1078,7 +1078,7 @@ ENDPROC(xen_hypervisor_callback)
>>  # We distinguish between categories by maintaining a status value in EAX.
>>  ENTRY(xen_failsafe_callback)
>>  	CFI_STARTPROC
>> -	pushl_cfi %eax
>> +	pushl_cfi $-1  /* orig_ax = -1 => not a system call */
> 
> While making this apply to the 2.6.18 tree, I noticed that you
> replaced the wrong push here, thus causing register corruption.
> Just like on the 64-bit side, the one that needs fixing is the one
> right before the SAVE_ALL (and hence it's again not just for
> consistency, as zero is being pushed there too).

Oops.

We would have liked to test this path but could not see how to.  Do you
have any ideas?

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 15:46:01 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 15:46:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPElb-00011j-Vk; Fri, 19 Oct 2012 15:45:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPEla-00011b-ER
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 15:45:42 +0000
Received: from [85.158.137.99:54290] by server-12.bemta-3.messagelabs.com id
	7A/64-27853-5A571805; Fri, 19 Oct 2012 15:45:41 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-13.tower-217.messagelabs.com!1350661539!22303344!1
X-Originating-IP: [209.85.210.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10933 invoked from network); 19 Oct 2012 15:45:40 -0000
Received: from mail-ia0-f173.google.com (HELO mail-ia0-f173.google.com)
	(209.85.210.173)
	by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 15:45:40 -0000
Received: by mail-ia0-f173.google.com with SMTP id m10so519070iam.32
	for ; Fri, 19 Oct 2012 08:45:39 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=content-type:mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=8WpkpH3XnUU5O/eazZy0PlrMr53dkorPbHTuPRuV8G8=;
	b=NvAsuvtqc8t9RqANlxLatgSXhifNBbTY5VdFSnCDiub5eTcZkRixy0+zL2gmmeSe+6
	R766gcNroVrApa3nSkYxUA4Ad8MqIB+I7JhJt6D253vwBaI7Rw8qjQKQd0ZBJdEuWYnb
	FwwmWoPfJhjRBx86AfjtctjTL1n7Xrd7zdxxpV1+yWe/385doRqzfoNwfiVIDnVJp7S8
	v4ljxxrLPNQoDicDyvTl8Uf1kQs5RKHdVHojBiRUMccqIwOOUP/4nMqEde/Fi1yNaGQc
	T/2KfS9zhtAHetKGx9+viT78Cvf+FVcKeL20+DZPkXCrQbsKntiMMfEaIU574+Pyk08l
	mnew==
Received: by 10.50.183.199 with SMTP id eo7mr1843216igc.36.1350661539014;
	Fri, 19 Oct 2012 08:45:39 -0700 (PDT)
Received: from andress-macbook.gridcentric.ca ([206.223.182.18])
	by mx.google.com with ESMTPS id ex10sm1643836igc.15.2012.10.19.08.45.36
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 19 Oct 2012 08:45:37 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Andres Lagar-Cavilla 
In-Reply-To: 
Date: Fri, 19 Oct 2012 11:45:36 -0400
Message-Id: <918914F5-6729-40C8-8D46-5EABB8FAB35B@gridcentric.ca>
References: 
To: xen-devel@lists.xen.org
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQnxrWGKabHx/wySJw5Mz1zVzzuS7kSrT6Z/I7wFZqxw4Oe51Qs6d4U1S9e6z/SGTMQ+bv/p
Cc: Olaf Hering 
Subject: Re: [Xen-devel] [PATCH] hvm: handle PoD and grant pages in
	HVMOP_get_mem_type
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> # HG changeset patch
> # User Olaf Hering 
> # Date 1350655745 -7200
> # Node ID 8ebe7b80f02900d5a83e023c2833de26b70f3ff1
> # Parent  3fa2ab30bb05297f30d9a33b30f29db960900971
> hvm: handle PoD and grant pages in HVMOP_get_mem_type
> 
> During kexec in a ballooned PVonHVM guest the new kernel needs to check
> each pfn if its backed by a mfn to find ballooned pages. Currently all
> PoD and grant pages will appear as HVMMEM_mmio_dm, so the new kernel has
> to assume they are ballooned. This is wrong: PoD pages may turn into
> real RAM at runtime, grant pages are also RAM.

> 
> Signed-off-by: Olaf Hering 
> 
> diff -r 3fa2ab30bb05 -r 8ebe7b80f029 xen/arch/x86/hvm/hvm.c
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4086,6 +4086,10 @@ long do_hvm_op(unsigned long op, XEN_GUE
>                 a.mem_type =  HVMMEM_ram_ro;
>             else if ( p2m_is_ram(t) )
>                 a.mem_type =  HVMMEM_ram_rw;
> +            else if ( p2m_is_magic(t) )
> +                a.mem_type =  HVMMEM_ram_rw;
p2m_is_magic is this bizarre thing that should just be p2m_is_pod. Can you take advantage of this opportunity and fix it?

> +            else if ( p2m_is_grant(t) )
> +                a.mem_type =  HVMMEM_ram_rw;

Yes there can be p2m_is_grant pages in an HVM, if it is running a backend. Note that you need to discriminate whether the grant is mapped writable in order to return ram_rw or ram_ro.

It might be a good idea to extend this interface to return HVMMEM_grant_rw/ro. These are, in essence, different types of ram from an HVM point of view. However, it might be overkill for the current users.

Thanks
Andres
>             else
>                 a.mem_type =  HVMMEM_mmio_dm;
>             rc = copy_to_guest(arg, &a, 1) ? -EFAULT : 0;
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 15:46:01 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 15:46:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPElb-00011j-Vk; Fri, 19 Oct 2012 15:45:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPEla-00011b-ER
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 15:45:42 +0000
Received: from [85.158.137.99:54290] by server-12.bemta-3.messagelabs.com id
	7A/64-27853-5A571805; Fri, 19 Oct 2012 15:45:41 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-13.tower-217.messagelabs.com!1350661539!22303344!1
X-Originating-IP: [209.85.210.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10933 invoked from network); 19 Oct 2012 15:45:40 -0000
Received: from mail-ia0-f173.google.com (HELO mail-ia0-f173.google.com)
	(209.85.210.173)
	by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 15:45:40 -0000
Received: by mail-ia0-f173.google.com with SMTP id m10so519070iam.32
	for ; Fri, 19 Oct 2012 08:45:39 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=content-type:mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=8WpkpH3XnUU5O/eazZy0PlrMr53dkorPbHTuPRuV8G8=;
	b=NvAsuvtqc8t9RqANlxLatgSXhifNBbTY5VdFSnCDiub5eTcZkRixy0+zL2gmmeSe+6
	R766gcNroVrApa3nSkYxUA4Ad8MqIB+I7JhJt6D253vwBaI7Rw8qjQKQd0ZBJdEuWYnb
	FwwmWoPfJhjRBx86AfjtctjTL1n7Xrd7zdxxpV1+yWe/385doRqzfoNwfiVIDnVJp7S8
	v4ljxxrLPNQoDicDyvTl8Uf1kQs5RKHdVHojBiRUMccqIwOOUP/4nMqEde/Fi1yNaGQc
	T/2KfS9zhtAHetKGx9+viT78Cvf+FVcKeL20+DZPkXCrQbsKntiMMfEaIU574+Pyk08l
	mnew==
Received: by 10.50.183.199 with SMTP id eo7mr1843216igc.36.1350661539014;
	Fri, 19 Oct 2012 08:45:39 -0700 (PDT)
Received: from andress-macbook.gridcentric.ca ([206.223.182.18])
	by mx.google.com with ESMTPS id ex10sm1643836igc.15.2012.10.19.08.45.36
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 19 Oct 2012 08:45:37 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Andres Lagar-Cavilla 
In-Reply-To: 
Date: Fri, 19 Oct 2012 11:45:36 -0400
Message-Id: <918914F5-6729-40C8-8D46-5EABB8FAB35B@gridcentric.ca>
References: 
To: xen-devel@lists.xen.org
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQnxrWGKabHx/wySJw5Mz1zVzzuS7kSrT6Z/I7wFZqxw4Oe51Qs6d4U1S9e6z/SGTMQ+bv/p
Cc: Olaf Hering 
Subject: Re: [Xen-devel] [PATCH] hvm: handle PoD and grant pages in
	HVMOP_get_mem_type
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> # HG changeset patch
> # User Olaf Hering 
> # Date 1350655745 -7200
> # Node ID 8ebe7b80f02900d5a83e023c2833de26b70f3ff1
> # Parent  3fa2ab30bb05297f30d9a33b30f29db960900971
> hvm: handle PoD and grant pages in HVMOP_get_mem_type
> 
> During kexec in a ballooned PVonHVM guest the new kernel needs to check
> each pfn if its backed by a mfn to find ballooned pages. Currently all
> PoD and grant pages will appear as HVMMEM_mmio_dm, so the new kernel has
> to assume they are ballooned. This is wrong: PoD pages may turn into
> real RAM at runtime, grant pages are also RAM.

> 
> Signed-off-by: Olaf Hering 
> 
> diff -r 3fa2ab30bb05 -r 8ebe7b80f029 xen/arch/x86/hvm/hvm.c
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4086,6 +4086,10 @@ long do_hvm_op(unsigned long op, XEN_GUE
>                 a.mem_type =  HVMMEM_ram_ro;
>             else if ( p2m_is_ram(t) )
>                 a.mem_type =  HVMMEM_ram_rw;
> +            else if ( p2m_is_magic(t) )
> +                a.mem_type =  HVMMEM_ram_rw;
p2m_is_magic is this bizarre thing that should just be p2m_is_pod. Can you take advantage of this opportunity and fix it?

> +            else if ( p2m_is_grant(t) )
> +                a.mem_type =  HVMMEM_ram_rw;

Yes there can be p2m_is_grant pages in an HVM, if it is running a backend. Note that you need to discriminate whether the grant is mapped writable in order to return ram_rw or ram_ro.

It might be a good idea to extend this interface to return HVMMEM_grant_rw/ro. These are, in essence, different types of ram from an HVM point of view. However, it might be overkill for the current users.

Thanks
Andres
>             else
>                 a.mem_type =  HVMMEM_mmio_dm;
>             rc = copy_to_guest(arg, &a, 1) ? -EFAULT : 0;
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 15:46:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 15:46:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPEmV-00016P-F4; Fri, 19 Oct 2012 15:46:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPEmT-00016B-Ty
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 15:46:38 +0000
Received: from [85.158.139.211:42821] by server-3.bemta-5.messagelabs.com id
	EC/64-28618-DD571805; Fri, 19 Oct 2012 15:46:37 +0000
X-Env-Sender: andres.lagarcavilla@gmail.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1350661594!23044120!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10142 invoked from network); 19 Oct 2012 15:46:35 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 15:46:35 -0000
Received: by mail-ie0-f173.google.com with SMTP id 17so1102940iea.32
	for ; Fri, 19 Oct 2012 08:46:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=content-type:mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer;
	bh=OYYHThxIRhGw3Y4fARc2kEjV5esbR3t+PtTrGrkAWzI=;
	b=dZIkrC68hITye1G6BbWwLcSu2eH2sHhXk3OxtufujAe3yoMMPg5LmthHv/Ytll5Vtr
	im1cUIJN3lN8uzyZCoasweRiwOPQQlzHSECZMb+5K5fohCGwNmXwSYgkeZtG2J4jPCAS
	MFj6NAerJXvGIQ1wWrWruoRJ2/exhNX6x4OjlW7raAbK+cnTpEXJOOqFU08HP7nIzgie
	glPkNCx1k67N8UnwF4xtcLc4ItRRoEabQgpzrn/E38E02GYbikm1k+1tX4U//iLSlDWS
	12DI5y4Fu+xK1R97j7mWstjWhA9kwJ2kkF0y9ltIDRoF9XK49iTcyanzw7p5BkvurlT/
	vKtw==
Received: by 10.50.6.225 with SMTP id e1mr1807135iga.68.1350661594233;
	Fri, 19 Oct 2012 08:46:34 -0700 (PDT)
Received: from andress-macbook.gridcentric.ca ([206.223.182.18])
	by mx.google.com with ESMTPS id 10sm16043102ign.5.2012.10.19.08.46.31
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 19 Oct 2012 08:46:33 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Andres Lagar-Cavilla 
In-Reply-To: <50811145.3030705@citrix.com>
Date: Fri, 19 Oct 2012 11:46:33 -0400
Message-Id: <94CA9621-D7BF-45CB-A6A2-7F68E14D3C23@gmail.com>
References: <5171750d133ef2c27ac8.1350055853@xdev.gridcentric.ca>
	<1350547689.28188.31.camel@dagon.hellion.org.uk>
	
	<50811145.3030705@citrix.com>
To: =?windows-1252?Q?Roger_Pau_Monn=E9?= 
X-Mailer: Apple Mail (2.1499)
Cc: Christoph Egger ,
	Ian Campbell ,
	Andres Lagar-Cavilla ,
	Ian Jackson ,
	"xen-devel@lists.xen.org" ,
	Andres Lagar-Cavilla ,
	Attilio Rao 
Subject: Re: [Xen-devel] [PATCH] Synchronize privcmd header constants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On Oct 19, 2012, at 4:37 AM, Roger Pau Monn=E9  wrote:

> On 19/10/12 04:20, Andres Lagar-Cavilla wrote:
>> I've had a look. The xen.org tree knows about three other OSes: minios, =
solaris and netbsd. None knows about paged out frames. None uses the XEN_DO=
MCTL_PFINFO_PAGEDTAB constant in domctl.h
>> =

>> 1. The domctl.h constant can still go away without hurting other OSes.
> =

> I've checked and NetBSD doesn't use XEN_DOMCTL_PFINFO_PAGEDTAB, so as
> Andres says I guess it's safe to remove it.
> =

>> 2. It is trivial to add the PRIVCMD_MMAPBATCH_* constants to the privcmd=
.h of other OSes. It can't hurt. I can do it here. Each OS Xen maintainer w=
ould have to take care of syncing that up in the respective upstream. Howev=
er ...
>> 3. Not that trivial to teach all these OSes about paged out frames. Does=
 anyone care?
> =

> Well, I'm sure the NetBSD community would be interested in this, but
> finding someone to actually work on it is a whole different story=85

Thanks Roger. Ian should I expect a response from Solaris?
Andres
> =

>> Please advise.
>> Thanks
>> Andres
>> =

>> On Oct 18, 2012, at 4:08 AM, Ian Campbell  wrot=
e:
>> =

>>> On Fri, 2012-10-12 at 16:30 +0100, Andres Lagar-Cavilla wrote:
>>>> tools/include/xen-sys/Linux/privcmd.h |   3 +++
>>>> tools/libxc/xc_linux_osdep.c          |  10 +++++-----
>>>> xen/include/public/domctl.h           |   1 -
>>>> 3 files changed, 8 insertions(+), 6 deletions(-)
>>>> =

>>>> =

>>>> Since Linux's git commit ceb90fa0a8008059ecbbf9114cb89dc71a730bb6, the
>>>> privcmd.h interface between Linux and libxc specifies two new constant=
s,
>>>> PRIVCMD_MMAPBATCH_MFN_ERROR and PRIVCMD_MMAPBATCH_PAGED_ERROR. These c=
onstants
>>>> represent the error codes encoded in the top nibble of an mfn slot pas=
sed to
>>>> the legacy MMAPBATCH ioctl.
>>>> =

>>>> In particular, libxenctrl checks for the equivalent of the latter cons=
tant when
>>>> dealing with paged out frames that might be the target of a foreign ma=
p.
>>>> =

>>>> Previously, the relevant constant was defined in the domctl hypervisor
>>>> interface header (XEN_DOMCTL_PFINFO_PAGEDTAB). Because this top-nibble=
 encoding
>>>> is a contract between the dom0 kernel and libxc, a domctl.h definition=
 is
>>>> misplaced.
>>>> =

>>>> - Sync the privcmd.h header to that now available in upstream Linux
>>> =

>>> Although the ioctl is Linux specific is the top-nibble behaviour (and
>>> therefore the #define) common to other dom0s like *BSD? Can a BSD person
>>> confirm that this change won't breaking things for them please.
>>> =

>>>> - Update libxc appropriately
>>>> - Remove the unnecessary constant in domctl.h
>>>> =

>>>> Signed-off-by: Andres Lagar-Cavilla 
>>>> =

>>>> diff -r 4eed5e64544f -r 5171750d133e tools/include/xen-sys/Linux/privc=
md.h
>>>> --- a/tools/include/xen-sys/Linux/privcmd.h
>>>> +++ b/tools/include/xen-sys/Linux/privcmd.h
>>>> @@ -64,6 +64,9 @@ typedef struct privcmd_mmapbatch {
>>>> 	xen_pfn_t __user *arr; /* array of mfns - top nibble set on err */
>>>> } privcmd_mmapbatch_t; =

>>>> =

>>>> +#define PRIVCMD_MMAPBATCH_MFN_ERROR     0xf0000000U
>>>> +#define PRIVCMD_MMAPBATCH_PAGED_ERROR   0x80000000U
>>>> +
>>>> typedef struct privcmd_mmapbatch_v2 {
>>>> 	unsigned int num; /* number of pages to populate */
>>>> 	domid_t dom;      /* target domain */
>>>> diff -r 4eed5e64544f -r 5171750d133e tools/libxc/xc_linux_osdep.c
>>>> --- a/tools/libxc/xc_linux_osdep.c
>>>> +++ b/tools/libxc/xc_linux_osdep.c
>>>> @@ -129,7 +129,7 @@ static int xc_map_foreign_batch_single(i
>>>> =

>>>>    do
>>>>    {
>>>> -        *mfn ^=3D XEN_DOMCTL_PFINFO_PAGEDTAB;
>>>> +        *mfn ^=3D PRIVCMD_MMAPBATCH_PAGED_ERROR;
>>>>        usleep(100);
>>>>        rc =3D ioctl(fd, IOCTL_PRIVCMD_MMAPBATCH, &ioctlx);
>>>>    }
>>>> @@ -166,8 +166,8 @@ static void *linux_privcmd_map_foreign_b
>>>> =

>>>>        for ( i =3D 0; i < num; i++ )
>>>>        {
>>>> -            if ( (arr[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) =3D=3D
>>>> -                 XEN_DOMCTL_PFINFO_PAGEDTAB )
>>>> +            if ( (arr[i] & PRIVCMD_MMAPBATCH_MFN_ERROR) =3D=3D
>>>> +                           PRIVCMD_MMAPBATCH_PAGED_ERROR )
>>>>            {
>>>>                unsigned long paged_addr =3D (unsigned long)addr + (i <=
< XC_PAGE_SHIFT);
>>>>                rc =3D xc_map_foreign_batch_single(fd, dom, &arr[i],
>>>> @@ -323,12 +323,12 @@ static void *linux_privcmd_map_foreign_b
>>>>            default:
>>>>                err[i] =3D -EINVAL;
>>>>                continue;
>>>> -            case XEN_DOMCTL_PFINFO_PAGEDTAB:
>>>> +            case PRIVCMD_MMAPBATCH_PAGED_ERROR:
>>>>                if ( rc !=3D -ENOENT )
>>>>                {
>>>>                    err[i] =3D rc ?: -EINVAL;
>>>>                    continue;
>>>> -                 }
>>>> +                }
>>>>                rc =3D xc_map_foreign_batch_single(fd, dom, pfn + i,
>>>>                        (unsigned long)addr + ((unsigned long)i<>>>                if ( rc < 0 )
>>>> diff -r 4eed5e64544f -r 5171750d133e xen/include/public/domctl.h
>>>> --- a/xen/include/public/domctl.h
>>>> +++ b/xen/include/public/domctl.h
>>>> @@ -135,7 +135,6 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_getme
>>>> #define XEN_DOMCTL_PFINFO_LPINTAB (0x1U<<31)
>>>> #define XEN_DOMCTL_PFINFO_XTAB    (0xfU<<28) /* invalid page */
>>>> #define XEN_DOMCTL_PFINFO_XALLOC  (0xeU<<28) /* allocate-only page */
>>>> -#define XEN_DOMCTL_PFINFO_PAGEDTAB (0x8U<<28)
>>>> #define XEN_DOMCTL_PFINFO_LTAB_MASK (0xfU<<28)
>>>> =

>>>> struct xen_domctl_getpageframeinfo {
>>> =

>>> =

>> =

> =



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 15:46:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 15:46:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPEmV-00016P-F4; Fri, 19 Oct 2012 15:46:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPEmT-00016B-Ty
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 15:46:38 +0000
Received: from [85.158.139.211:42821] by server-3.bemta-5.messagelabs.com id
	EC/64-28618-DD571805; Fri, 19 Oct 2012 15:46:37 +0000
X-Env-Sender: andres.lagarcavilla@gmail.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1350661594!23044120!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10142 invoked from network); 19 Oct 2012 15:46:35 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 15:46:35 -0000
Received: by mail-ie0-f173.google.com with SMTP id 17so1102940iea.32
	for ; Fri, 19 Oct 2012 08:46:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=content-type:mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer;
	bh=OYYHThxIRhGw3Y4fARc2kEjV5esbR3t+PtTrGrkAWzI=;
	b=dZIkrC68hITye1G6BbWwLcSu2eH2sHhXk3OxtufujAe3yoMMPg5LmthHv/Ytll5Vtr
	im1cUIJN3lN8uzyZCoasweRiwOPQQlzHSECZMb+5K5fohCGwNmXwSYgkeZtG2J4jPCAS
	MFj6NAerJXvGIQ1wWrWruoRJ2/exhNX6x4OjlW7raAbK+cnTpEXJOOqFU08HP7nIzgie
	glPkNCx1k67N8UnwF4xtcLc4ItRRoEabQgpzrn/E38E02GYbikm1k+1tX4U//iLSlDWS
	12DI5y4Fu+xK1R97j7mWstjWhA9kwJ2kkF0y9ltIDRoF9XK49iTcyanzw7p5BkvurlT/
	vKtw==
Received: by 10.50.6.225 with SMTP id e1mr1807135iga.68.1350661594233;
	Fri, 19 Oct 2012 08:46:34 -0700 (PDT)
Received: from andress-macbook.gridcentric.ca ([206.223.182.18])
	by mx.google.com with ESMTPS id 10sm16043102ign.5.2012.10.19.08.46.31
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 19 Oct 2012 08:46:33 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Andres Lagar-Cavilla 
In-Reply-To: <50811145.3030705@citrix.com>
Date: Fri, 19 Oct 2012 11:46:33 -0400
Message-Id: <94CA9621-D7BF-45CB-A6A2-7F68E14D3C23@gmail.com>
References: <5171750d133ef2c27ac8.1350055853@xdev.gridcentric.ca>
	<1350547689.28188.31.camel@dagon.hellion.org.uk>
	
	<50811145.3030705@citrix.com>
To: =?windows-1252?Q?Roger_Pau_Monn=E9?= 
X-Mailer: Apple Mail (2.1499)
Cc: Christoph Egger ,
	Ian Campbell ,
	Andres Lagar-Cavilla ,
	Ian Jackson ,
	"xen-devel@lists.xen.org" ,
	Andres Lagar-Cavilla ,
	Attilio Rao 
Subject: Re: [Xen-devel] [PATCH] Synchronize privcmd header constants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On Oct 19, 2012, at 4:37 AM, Roger Pau Monn=E9  wrote:

> On 19/10/12 04:20, Andres Lagar-Cavilla wrote:
>> I've had a look. The xen.org tree knows about three other OSes: minios, =
solaris and netbsd. None knows about paged out frames. None uses the XEN_DO=
MCTL_PFINFO_PAGEDTAB constant in domctl.h
>> =

>> 1. The domctl.h constant can still go away without hurting other OSes.
> =

> I've checked and NetBSD doesn't use XEN_DOMCTL_PFINFO_PAGEDTAB, so as
> Andres says I guess it's safe to remove it.
> =

>> 2. It is trivial to add the PRIVCMD_MMAPBATCH_* constants to the privcmd=
.h of other OSes. It can't hurt. I can do it here. Each OS Xen maintainer w=
ould have to take care of syncing that up in the respective upstream. Howev=
er ...
>> 3. Not that trivial to teach all these OSes about paged out frames. Does=
 anyone care?
> =

> Well, I'm sure the NetBSD community would be interested in this, but
> finding someone to actually work on it is a whole different story=85

Thanks Roger. Ian should I expect a response from Solaris?
Andres
> =

>> Please advise.
>> Thanks
>> Andres
>> =

>> On Oct 18, 2012, at 4:08 AM, Ian Campbell  wrot=
e:
>> =

>>> On Fri, 2012-10-12 at 16:30 +0100, Andres Lagar-Cavilla wrote:
>>>> tools/include/xen-sys/Linux/privcmd.h |   3 +++
>>>> tools/libxc/xc_linux_osdep.c          |  10 +++++-----
>>>> xen/include/public/domctl.h           |   1 -
>>>> 3 files changed, 8 insertions(+), 6 deletions(-)
>>>> =

>>>> =

>>>> Since Linux's git commit ceb90fa0a8008059ecbbf9114cb89dc71a730bb6, the
>>>> privcmd.h interface between Linux and libxc specifies two new constant=
s,
>>>> PRIVCMD_MMAPBATCH_MFN_ERROR and PRIVCMD_MMAPBATCH_PAGED_ERROR. These c=
onstants
>>>> represent the error codes encoded in the top nibble of an mfn slot pas=
sed to
>>>> the legacy MMAPBATCH ioctl.
>>>> =

>>>> In particular, libxenctrl checks for the equivalent of the latter cons=
tant when
>>>> dealing with paged out frames that might be the target of a foreign ma=
p.
>>>> =

>>>> Previously, the relevant constant was defined in the domctl hypervisor
>>>> interface header (XEN_DOMCTL_PFINFO_PAGEDTAB). Because this top-nibble=
 encoding
>>>> is a contract between the dom0 kernel and libxc, a domctl.h definition=
 is
>>>> misplaced.
>>>> =

>>>> - Sync the privcmd.h header to that now available in upstream Linux
>>> =

>>> Although the ioctl is Linux specific is the top-nibble behaviour (and
>>> therefore the #define) common to other dom0s like *BSD? Can a BSD person
>>> confirm that this change won't breaking things for them please.
>>> =

>>>> - Update libxc appropriately
>>>> - Remove the unnecessary constant in domctl.h
>>>> =

>>>> Signed-off-by: Andres Lagar-Cavilla 
>>>> =

>>>> diff -r 4eed5e64544f -r 5171750d133e tools/include/xen-sys/Linux/privc=
md.h
>>>> --- a/tools/include/xen-sys/Linux/privcmd.h
>>>> +++ b/tools/include/xen-sys/Linux/privcmd.h
>>>> @@ -64,6 +64,9 @@ typedef struct privcmd_mmapbatch {
>>>> 	xen_pfn_t __user *arr; /* array of mfns - top nibble set on err */
>>>> } privcmd_mmapbatch_t; =

>>>> =

>>>> +#define PRIVCMD_MMAPBATCH_MFN_ERROR     0xf0000000U
>>>> +#define PRIVCMD_MMAPBATCH_PAGED_ERROR   0x80000000U
>>>> +
>>>> typedef struct privcmd_mmapbatch_v2 {
>>>> 	unsigned int num; /* number of pages to populate */
>>>> 	domid_t dom;      /* target domain */
>>>> diff -r 4eed5e64544f -r 5171750d133e tools/libxc/xc_linux_osdep.c
>>>> --- a/tools/libxc/xc_linux_osdep.c
>>>> +++ b/tools/libxc/xc_linux_osdep.c
>>>> @@ -129,7 +129,7 @@ static int xc_map_foreign_batch_single(i
>>>> =

>>>>    do
>>>>    {
>>>> -        *mfn ^=3D XEN_DOMCTL_PFINFO_PAGEDTAB;
>>>> +        *mfn ^=3D PRIVCMD_MMAPBATCH_PAGED_ERROR;
>>>>        usleep(100);
>>>>        rc =3D ioctl(fd, IOCTL_PRIVCMD_MMAPBATCH, &ioctlx);
>>>>    }
>>>> @@ -166,8 +166,8 @@ static void *linux_privcmd_map_foreign_b
>>>> =

>>>>        for ( i =3D 0; i < num; i++ )
>>>>        {
>>>> -            if ( (arr[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) =3D=3D
>>>> -                 XEN_DOMCTL_PFINFO_PAGEDTAB )
>>>> +            if ( (arr[i] & PRIVCMD_MMAPBATCH_MFN_ERROR) =3D=3D
>>>> +                           PRIVCMD_MMAPBATCH_PAGED_ERROR )
>>>>            {
>>>>                unsigned long paged_addr =3D (unsigned long)addr + (i <=
< XC_PAGE_SHIFT);
>>>>                rc =3D xc_map_foreign_batch_single(fd, dom, &arr[i],
>>>> @@ -323,12 +323,12 @@ static void *linux_privcmd_map_foreign_b
>>>>            default:
>>>>                err[i] =3D -EINVAL;
>>>>                continue;
>>>> -            case XEN_DOMCTL_PFINFO_PAGEDTAB:
>>>> +            case PRIVCMD_MMAPBATCH_PAGED_ERROR:
>>>>                if ( rc !=3D -ENOENT )
>>>>                {
>>>>                    err[i] =3D rc ?: -EINVAL;
>>>>                    continue;
>>>> -                 }
>>>> +                }
>>>>                rc =3D xc_map_foreign_batch_single(fd, dom, pfn + i,
>>>>                        (unsigned long)addr + ((unsigned long)i<>>>                if ( rc < 0 )
>>>> diff -r 4eed5e64544f -r 5171750d133e xen/include/public/domctl.h
>>>> --- a/xen/include/public/domctl.h
>>>> +++ b/xen/include/public/domctl.h
>>>> @@ -135,7 +135,6 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_getme
>>>> #define XEN_DOMCTL_PFINFO_LPINTAB (0x1U<<31)
>>>> #define XEN_DOMCTL_PFINFO_XTAB    (0xfU<<28) /* invalid page */
>>>> #define XEN_DOMCTL_PFINFO_XALLOC  (0xeU<<28) /* allocate-only page */
>>>> -#define XEN_DOMCTL_PFINFO_PAGEDTAB (0x8U<<28)
>>>> #define XEN_DOMCTL_PFINFO_LTAB_MASK (0xfU<<28)
>>>> =

>>>> struct xen_domctl_getpageframeinfo {
>>> =

>>> =

>> =

> =



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 15:47:56 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 15:47:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPEnY-0001DX-Tp; Fri, 19 Oct 2012 15:47:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPEnX-0001DM-VW
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 15:47:44 +0000
Received: from [85.158.139.83:20086] by server-11.bemta-5.messagelabs.com id
	BA/A1-14870-F1671805; Fri, 19 Oct 2012 15:47:43 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1350661662!32798922!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUwMDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24387 invoked from network); 19 Oct 2012 15:47:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 15:47:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,613,1344211200"; d="scan'208";a="15280455"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 15:47:15 +0000
Received: from mac.citrite.net (10.31.3.233) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 19 Oct 2012 16:47:15 +0100
From: Roger Pau Monne 
To: 
Date: Fri, 19 Oct 2012 17:47:07 +0200
Message-ID: <1350661627-20775-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
MIME-Version: 1.0
Cc: Roger Pau Monne 
Subject: [Xen-devel] [PATCH] xen: restore GNTTABOP_dump_table
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This operation was dropped long time ago, but I found it quite helpful
for debugging purposes. This re-implementation uses the code already
present in gnttab_usage_print and adds the maptrack-table dump.

Signed-off-by: Roger Pau Monne 
---
 xen/common/grant_table.c      |   83 ++++++++++++++++++++++++++++++++++++++---
 xen/include/xen/grant_table.h |    3 +
 2 files changed, 80 insertions(+), 6 deletions(-)

diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index c8e342b..a5de9c6 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -1393,6 +1393,40 @@ gnttab_setup_table(
     return 0;
 }
 
+static long
+gnttab_dump_table(
+    XEN_GUEST_HANDLE(gnttab_dump_table_t) uop, unsigned int count)
+{
+    struct gnttab_dump_table   op;
+    struct domain        *d;
+
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+
+    if ( unlikely(copy_from_guest(&op, uop, sizeof(op)) != 0) )
+    {
+        gdprintk(XENLOG_INFO, "Fault while reading gnttab_dump_table_t.\n");
+        return -EFAULT;
+    }
+
+    d = gt_lock_target_domain_by_id(op.dom);
+    if ( IS_ERR(d) )
+    {
+        op.status = PTR_ERR(d);
+        goto out;
+    }
+
+    gnttab_usage_print(d, 1);
+
+    rcu_unlock_domain(d);
+
+out:
+    if ( unlikely(copy_to_guest(uop, &op, 1)) )
+        return -EFAULT;
+
+    return 0;
+}
+
 static long 
 gnttab_query_size(
     XEN_GUEST_HANDLE(gnttab_query_size_t) uop, unsigned int count)
@@ -2495,6 +2529,12 @@ do_grant_table_op(
         ASSERT(rc <= 0);
         break;
     }
+    case GNTTABOP_dump_table:
+    {
+        rc = gnttab_dump_table(guest_handle_cast(uop, gnttab_dump_table_t),
+                               count);
+        break;
+    }
     case GNTTABOP_transfer:
     {
         XEN_GUEST_HANDLE(gnttab_transfer_t) transfer =
@@ -2796,7 +2836,7 @@ grant_table_destroy(
     d->grant_table = NULL;
 }
 
-void gnttab_usage_print(struct domain *rd)
+void gnttab_usage_print(struct domain *rd, int print_maptrack)
 {
     int first = 1;
     grant_ref_t ref;
@@ -2808,7 +2848,7 @@ void gnttab_usage_print(struct domain *rd)
     spin_lock(>->lock);
 
     if ( gt->gt_version == 0 )
-        goto out;
+        goto out_grant;
 
     for ( ref = 0; ref != nr_grant_entries(gt); ref++ )
     {
@@ -2853,12 +2893,43 @@ void gnttab_usage_print(struct domain *rd)
                sha->domid, frame, status);
     }
 
- out:
-    spin_unlock(>->lock);
-
+out_grant:
     if ( first )
         printk("grant-table for remote domain:%5d ... "
                "no active grant table entries\n", rd->domain_id);
+
+    if ( !print_maptrack )
+        goto out;
+
+    first = 1;
+
+    printk("      -------- maptrack --------\n");
+    printk("[ref] domid         gnt    flags\n");
+
+    for ( ref = 0; ref != gt->maptrack_limit; ref++ )
+    {
+        struct grant_mapping *maptrack = &maptrack_entry(gt, ref);
+
+        if ( maptrack->flags ) {
+
+            if ( first )
+            {
+                printk("maptrack-table for remote domain:%5d\n",
+                       rd->domain_id);
+                first = 0;
+            }
+            /*      [ddd] ddddd 0xXXXXXXXX  0xXX */
+            printk("[%3d] %5d  0x%08x     0x%02x\n",
+                    ref, maptrack->domid, maptrack->ref, maptrack->flags);
+        }
+    }
+
+    if ( first )
+        printk("maptrack-table for remote domain:%5d ... "
+               "no active maptrack table entries\n", rd->domain_id);
+
+ out:
+    spin_unlock(>->lock);
 }
 
 static void gnttab_usage_print_all(unsigned char key)
@@ -2866,7 +2937,7 @@ static void gnttab_usage_print_all(unsigned char key)
     struct domain *d;
     printk("%s [ key '%c' pressed\n", __FUNCTION__, key);
     for_each_domain ( d )
-        gnttab_usage_print(d);
+        gnttab_usage_print(d, 0);
     printk("%s ] done\n", __FUNCTION__);
 }
 
diff --git a/xen/include/xen/grant_table.h b/xen/include/xen/grant_table.h
index 0820da1..34a8304 100644
--- a/xen/include/xen/grant_table.h
+++ b/xen/include/xen/grant_table.h
@@ -111,6 +111,9 @@ gnttab_release_mappings(
 int
 gnttab_grow_table(struct domain *d, unsigned int req_nr_frames);
 
+/* Print grant table for given domain. */
+void gnttab_usage_print(struct domain *rd, int print_maptrack);
+
 /* Number of grant table frames. Caller must hold d's grant table lock. */
 static inline unsigned int nr_grant_frames(struct grant_table *gt)
 {
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 15:47:56 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 15:47:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPEnY-0001DX-Tp; Fri, 19 Oct 2012 15:47:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPEnX-0001DM-VW
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 15:47:44 +0000
Received: from [85.158.139.83:20086] by server-11.bemta-5.messagelabs.com id
	BA/A1-14870-F1671805; Fri, 19 Oct 2012 15:47:43 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1350661662!32798922!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUwMDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24387 invoked from network); 19 Oct 2012 15:47:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 15:47:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,613,1344211200"; d="scan'208";a="15280455"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 15:47:15 +0000
Received: from mac.citrite.net (10.31.3.233) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 19 Oct 2012 16:47:15 +0100
From: Roger Pau Monne 
To: 
Date: Fri, 19 Oct 2012 17:47:07 +0200
Message-ID: <1350661627-20775-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
MIME-Version: 1.0
Cc: Roger Pau Monne 
Subject: [Xen-devel] [PATCH] xen: restore GNTTABOP_dump_table
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This operation was dropped long time ago, but I found it quite helpful
for debugging purposes. This re-implementation uses the code already
present in gnttab_usage_print and adds the maptrack-table dump.

Signed-off-by: Roger Pau Monne 
---
 xen/common/grant_table.c      |   83 ++++++++++++++++++++++++++++++++++++++---
 xen/include/xen/grant_table.h |    3 +
 2 files changed, 80 insertions(+), 6 deletions(-)

diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index c8e342b..a5de9c6 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -1393,6 +1393,40 @@ gnttab_setup_table(
     return 0;
 }
 
+static long
+gnttab_dump_table(
+    XEN_GUEST_HANDLE(gnttab_dump_table_t) uop, unsigned int count)
+{
+    struct gnttab_dump_table   op;
+    struct domain        *d;
+
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+
+    if ( unlikely(copy_from_guest(&op, uop, sizeof(op)) != 0) )
+    {
+        gdprintk(XENLOG_INFO, "Fault while reading gnttab_dump_table_t.\n");
+        return -EFAULT;
+    }
+
+    d = gt_lock_target_domain_by_id(op.dom);
+    if ( IS_ERR(d) )
+    {
+        op.status = PTR_ERR(d);
+        goto out;
+    }
+
+    gnttab_usage_print(d, 1);
+
+    rcu_unlock_domain(d);
+
+out:
+    if ( unlikely(copy_to_guest(uop, &op, 1)) )
+        return -EFAULT;
+
+    return 0;
+}
+
 static long 
 gnttab_query_size(
     XEN_GUEST_HANDLE(gnttab_query_size_t) uop, unsigned int count)
@@ -2495,6 +2529,12 @@ do_grant_table_op(
         ASSERT(rc <= 0);
         break;
     }
+    case GNTTABOP_dump_table:
+    {
+        rc = gnttab_dump_table(guest_handle_cast(uop, gnttab_dump_table_t),
+                               count);
+        break;
+    }
     case GNTTABOP_transfer:
     {
         XEN_GUEST_HANDLE(gnttab_transfer_t) transfer =
@@ -2796,7 +2836,7 @@ grant_table_destroy(
     d->grant_table = NULL;
 }
 
-void gnttab_usage_print(struct domain *rd)
+void gnttab_usage_print(struct domain *rd, int print_maptrack)
 {
     int first = 1;
     grant_ref_t ref;
@@ -2808,7 +2848,7 @@ void gnttab_usage_print(struct domain *rd)
     spin_lock(>->lock);
 
     if ( gt->gt_version == 0 )
-        goto out;
+        goto out_grant;
 
     for ( ref = 0; ref != nr_grant_entries(gt); ref++ )
     {
@@ -2853,12 +2893,43 @@ void gnttab_usage_print(struct domain *rd)
                sha->domid, frame, status);
     }
 
- out:
-    spin_unlock(>->lock);
-
+out_grant:
     if ( first )
         printk("grant-table for remote domain:%5d ... "
                "no active grant table entries\n", rd->domain_id);
+
+    if ( !print_maptrack )
+        goto out;
+
+    first = 1;
+
+    printk("      -------- maptrack --------\n");
+    printk("[ref] domid         gnt    flags\n");
+
+    for ( ref = 0; ref != gt->maptrack_limit; ref++ )
+    {
+        struct grant_mapping *maptrack = &maptrack_entry(gt, ref);
+
+        if ( maptrack->flags ) {
+
+            if ( first )
+            {
+                printk("maptrack-table for remote domain:%5d\n",
+                       rd->domain_id);
+                first = 0;
+            }
+            /*      [ddd] ddddd 0xXXXXXXXX  0xXX */
+            printk("[%3d] %5d  0x%08x     0x%02x\n",
+                    ref, maptrack->domid, maptrack->ref, maptrack->flags);
+        }
+    }
+
+    if ( first )
+        printk("maptrack-table for remote domain:%5d ... "
+               "no active maptrack table entries\n", rd->domain_id);
+
+ out:
+    spin_unlock(>->lock);
 }
 
 static void gnttab_usage_print_all(unsigned char key)
@@ -2866,7 +2937,7 @@ static void gnttab_usage_print_all(unsigned char key)
     struct domain *d;
     printk("%s [ key '%c' pressed\n", __FUNCTION__, key);
     for_each_domain ( d )
-        gnttab_usage_print(d);
+        gnttab_usage_print(d, 0);
     printk("%s ] done\n", __FUNCTION__);
 }
 
diff --git a/xen/include/xen/grant_table.h b/xen/include/xen/grant_table.h
index 0820da1..34a8304 100644
--- a/xen/include/xen/grant_table.h
+++ b/xen/include/xen/grant_table.h
@@ -111,6 +111,9 @@ gnttab_release_mappings(
 int
 gnttab_grow_table(struct domain *d, unsigned int req_nr_frames);
 
+/* Print grant table for given domain. */
+void gnttab_usage_print(struct domain *rd, int print_maptrack);
+
 /* Number of grant table frames. Caller must hold d's grant table lock. */
 static inline unsigned int nr_grant_frames(struct grant_table *gt)
 {
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 15:50:12 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 15:50:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPEpl-0001Qo-G2; Fri, 19 Oct 2012 15:50:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPEpj-0001Qd-Rg
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 15:50:00 +0000
Received: from [85.158.139.211:11960] by server-13.bemta-5.messagelabs.com id
	5F/AB-30674-7A671805; Fri, 19 Oct 2012 15:49:59 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1350661798!21482808!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUwMDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32657 invoked from network); 19 Oct 2012 15:49:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 15:49:58 -0000
X-IronPort-AV: E=Sophos;i="4.80,613,1344211200"; d="scan'208";a="15280524"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 15:49:58 +0000
Received: from [192.168.1.30] (10.31.3.233) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 19 Oct 2012 16:49:58 +0100
Message-ID: <508176A5.10401@citrix.com>
Date: Fri, 19 Oct 2012 17:49:57 +0200
From: =?windows-1252?Q?Roger_Pau_Monn=E9?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: Andres Lagar-Cavilla 
References: <5171750d133ef2c27ac8.1350055853@xdev.gridcentric.ca>
	<1350547689.28188.31.camel@dagon.hellion.org.uk>
	
	<50811145.3030705@citrix.com>
	<94CA9621-D7BF-45CB-A6A2-7F68E14D3C23@gmail.com>
In-Reply-To: <94CA9621-D7BF-45CB-A6A2-7F68E14D3C23@gmail.com>
Cc: Christoph Egger ,
	Ian Campbell ,
	Andres Lagar-Cavilla ,
	Ian Jackson ,
	"xen-devel@lists.xen.org" ,
	Andres Lagar-Cavilla ,
	Attilio Rao 
Subject: Re: [Xen-devel] [PATCH] Synchronize privcmd header constants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 19/10/12 17:46, Andres Lagar-Cavilla wrote:
> =

> On Oct 19, 2012, at 4:37 AM, Roger Pau Monn=E9  wro=
te:
> =

>> On 19/10/12 04:20, Andres Lagar-Cavilla wrote:
>>> I've had a look. The xen.org tree knows about three other OSes: minios,=
 solaris and netbsd. None knows about paged out frames. None uses the XEN_D=
OMCTL_PFINFO_PAGEDTAB constant in domctl.h
>>>
>>> 1. The domctl.h constant can still go away without hurting other OSes.
>>
>> I've checked and NetBSD doesn't use XEN_DOMCTL_PFINFO_PAGEDTAB, so as
>> Andres says I guess it's safe to remove it.
>>
>>> 2. It is trivial to add the PRIVCMD_MMAPBATCH_* constants to the privcm=
d.h of other OSes. It can't hurt. I can do it here. Each OS Xen maintainer =
would have to take care of syncing that up in the respective upstream. Howe=
ver ...
>>> 3. Not that trivial to teach all these OSes about paged out frames. Doe=
s anyone care?
>>
>> Well, I'm sure the NetBSD community would be interested in this, but
>> finding someone to actually work on it is a whole different story=85
> =

> Thanks Roger. Ian should I expect a response from Solaris?

Solaris (Illumos) is currently pretty broken, and has gone the KVM side
as far as I know, so I wouldn't expect any response.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 15:50:12 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 15:50:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPEpl-0001Qo-G2; Fri, 19 Oct 2012 15:50:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPEpj-0001Qd-Rg
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 15:50:00 +0000
Received: from [85.158.139.211:11960] by server-13.bemta-5.messagelabs.com id
	5F/AB-30674-7A671805; Fri, 19 Oct 2012 15:49:59 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1350661798!21482808!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUwMDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32657 invoked from network); 19 Oct 2012 15:49:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 15:49:58 -0000
X-IronPort-AV: E=Sophos;i="4.80,613,1344211200"; d="scan'208";a="15280524"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 15:49:58 +0000
Received: from [192.168.1.30] (10.31.3.233) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 19 Oct 2012 16:49:58 +0100
Message-ID: <508176A5.10401@citrix.com>
Date: Fri, 19 Oct 2012 17:49:57 +0200
From: =?windows-1252?Q?Roger_Pau_Monn=E9?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: Andres Lagar-Cavilla 
References: <5171750d133ef2c27ac8.1350055853@xdev.gridcentric.ca>
	<1350547689.28188.31.camel@dagon.hellion.org.uk>
	
	<50811145.3030705@citrix.com>
	<94CA9621-D7BF-45CB-A6A2-7F68E14D3C23@gmail.com>
In-Reply-To: <94CA9621-D7BF-45CB-A6A2-7F68E14D3C23@gmail.com>
Cc: Christoph Egger ,
	Ian Campbell ,
	Andres Lagar-Cavilla ,
	Ian Jackson ,
	"xen-devel@lists.xen.org" ,
	Andres Lagar-Cavilla ,
	Attilio Rao 
Subject: Re: [Xen-devel] [PATCH] Synchronize privcmd header constants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 19/10/12 17:46, Andres Lagar-Cavilla wrote:
> =

> On Oct 19, 2012, at 4:37 AM, Roger Pau Monn=E9  wro=
te:
> =

>> On 19/10/12 04:20, Andres Lagar-Cavilla wrote:
>>> I've had a look. The xen.org tree knows about three other OSes: minios,=
 solaris and netbsd. None knows about paged out frames. None uses the XEN_D=
OMCTL_PFINFO_PAGEDTAB constant in domctl.h
>>>
>>> 1. The domctl.h constant can still go away without hurting other OSes.
>>
>> I've checked and NetBSD doesn't use XEN_DOMCTL_PFINFO_PAGEDTAB, so as
>> Andres says I guess it's safe to remove it.
>>
>>> 2. It is trivial to add the PRIVCMD_MMAPBATCH_* constants to the privcm=
d.h of other OSes. It can't hurt. I can do it here. Each OS Xen maintainer =
would have to take care of syncing that up in the respective upstream. Howe=
ver ...
>>> 3. Not that trivial to teach all these OSes about paged out frames. Doe=
s anyone care?
>>
>> Well, I'm sure the NetBSD community would be interested in this, but
>> finding someone to actually work on it is a whole different story=85
> =

> Thanks Roger. Ian should I expect a response from Solaris?

Solaris (Illumos) is currently pretty broken, and has gone the KVM side
as far as I know, so I wouldn't expect any response.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 15:54:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 15:54:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPEtt-0001gE-Gg; Fri, 19 Oct 2012 15:54:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPEts-0001g7-4L
	for Xen-devel@lists.xensource.com; Fri, 19 Oct 2012 15:54:16 +0000
Received: from [85.158.139.211:36343] by server-7.bemta-5.messagelabs.com id
	0F/1A-23102-7A771805; Fri, 19 Oct 2012 15:54:15 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1350662054!22981453!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUwMDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6788 invoked from network); 19 Oct 2012 15:54:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 15:54:14 -0000
X-IronPort-AV: E=Sophos;i="4.80,613,1344211200"; d="scan'208";a="15280622"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 15:54:14 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 19 Oct 2012 16:54:14 +0100
Date: Fri, 19 Oct 2012 16:53:49 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Konrad Rzeszutek Wilk 
In-Reply-To: <20121019131707.GG26830@phenom.dumpdata.com>
Message-ID: 
References: <20121017172642.349b2aae@mantra.us.oracle.com>
	
	<20121019131707.GG26830@phenom.dumpdata.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH V3 1/6]: PVH: basic and header changes,
 elfnote changes, ...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 19 Oct 2012, Konrad Rzeszutek Wilk wrote:
> > > diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
> > > index 9ce788d..3b9d5b6 100644
> > > --- a/include/xen/interface/physdev.h
> > > +++ b/include/xen/interface/physdev.h
> > > @@ -258,6 +258,16 @@ struct physdev_pci_device {
> > >      uint8_t devfn;
> > >  };
> > >  
> > > +#define PHYSDEVOP_pvh_map_iomem        30
> > 
> > I would just call this PHYSDEVOP_map_iomem, we might use it on non-PVH
> > guests as well one day.
> 
> I completely lost track of the naming now :-( Isn't the ARM version
> called range something?

That is XENMEM_add_to_physmap_range, a different hypercall.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 15:54:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 15:54:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPEtt-0001gE-Gg; Fri, 19 Oct 2012 15:54:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPEts-0001g7-4L
	for Xen-devel@lists.xensource.com; Fri, 19 Oct 2012 15:54:16 +0000
Received: from [85.158.139.211:36343] by server-7.bemta-5.messagelabs.com id
	0F/1A-23102-7A771805; Fri, 19 Oct 2012 15:54:15 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1350662054!22981453!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUwMDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6788 invoked from network); 19 Oct 2012 15:54:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 15:54:14 -0000
X-IronPort-AV: E=Sophos;i="4.80,613,1344211200"; d="scan'208";a="15280622"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 15:54:14 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 19 Oct 2012 16:54:14 +0100
Date: Fri, 19 Oct 2012 16:53:49 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Konrad Rzeszutek Wilk 
In-Reply-To: <20121019131707.GG26830@phenom.dumpdata.com>
Message-ID: 
References: <20121017172642.349b2aae@mantra.us.oracle.com>
	
	<20121019131707.GG26830@phenom.dumpdata.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH V3 1/6]: PVH: basic and header changes,
 elfnote changes, ...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 19 Oct 2012, Konrad Rzeszutek Wilk wrote:
> > > diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
> > > index 9ce788d..3b9d5b6 100644
> > > --- a/include/xen/interface/physdev.h
> > > +++ b/include/xen/interface/physdev.h
> > > @@ -258,6 +258,16 @@ struct physdev_pci_device {
> > >      uint8_t devfn;
> > >  };
> > >  
> > > +#define PHYSDEVOP_pvh_map_iomem        30
> > 
> > I would just call this PHYSDEVOP_map_iomem, we might use it on non-PVH
> > guests as well one day.
> 
> I completely lost track of the naming now :-( Isn't the ARM version
> called range something?

That is XENMEM_add_to_physmap_range, a different hypercall.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 16:01:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 16:01:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPF0W-0002J2-RP; Fri, 19 Oct 2012 16:01:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPF0V-0002Iw-1n
	for xen-devel@lists.xensource.com; Fri, 19 Oct 2012 16:01:07 +0000
Received: from [193.109.254.147:24242] by server-10.bemta-14.messagelabs.com
	id 2A/37-12590-24971805; Fri, 19 Oct 2012 16:01:06 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1350662464!3472528!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODE1Njg1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25157 invoked from network); 19 Oct 2012 16:01:05 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Oct 2012 16:01:05 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9JG11EB010379
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Oct 2012 16:01:01 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9JG10Mr028989
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 19 Oct 2012 16:01:00 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9JG0xhV006715; Fri, 19 Oct 2012 11:00:59 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Oct 2012 09:00:59 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1C78B4035B; Fri, 19 Oct 2012 11:48:55 -0400 (EDT)
Date: Fri, 19 Oct 2012 11:48:55 -0400
From: Konrad Rzeszutek Wilk 
To: "H. Peter Anvin" 
Message-ID: <20121019154854.GO26830@phenom.dumpdata.com>
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	<507ED6C0.4020503@zytor.com>
	<20121017161036.GA10691@phenom.dumpdata.com>
	<507EE1C3.7070300@zytor.com>
	<20121017165452.GA22740@phenom.dumpdata.com>
	<507EEC53.1010309@zytor.com>
	<84b3cbf9-7c84-4d7e-a2d7-46b0d1cc5975@default>
	<50802030.8070107@zytor.com>
	
	<50803057.5000307@zytor.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50803057.5000307@zytor.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Dan Magenheimer , xen-devel@lists.xensource.com,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, lenb@kernel.org
Subject: [Xen-devel] Is: Xen architecture document. Was: Re: Is: axe
 read_tscp pvops call. Was: Re: [RFC] ACPI S3 and Xen (suprisingly small\!).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> paravirtualized architectures out there which are perfectly well
> documented and supportable, but Xen has resisted doing that for
> years, and all we ever get are vague future promises.

There is no resistance - and it is being done. Every month we document
various APIs, man-pages, etc so that knowledge won't be lost. The
end-result of that is to create a PDF similar to the PowerPC architecture
document.

I have not been pointing you to it, b/c as of right what we have is
raw data (various header files growing in size) that keep on growing.
I need to hire/cajole an editor to help us get from the "raw" brain
dump to a book and some sense of milestones/schedule or whatever one
does in the book-world.

And Peter, just in case it is not clear, every suggestion you make is
appreciated and taken seriously. If there are things that have been
dropped or forgotten by me - please remind me.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 16:01:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 16:01:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPF0W-0002J2-RP; Fri, 19 Oct 2012 16:01:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPF0V-0002Iw-1n
	for xen-devel@lists.xensource.com; Fri, 19 Oct 2012 16:01:07 +0000
Received: from [193.109.254.147:24242] by server-10.bemta-14.messagelabs.com
	id 2A/37-12590-24971805; Fri, 19 Oct 2012 16:01:06 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1350662464!3472528!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODE1Njg1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25157 invoked from network); 19 Oct 2012 16:01:05 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Oct 2012 16:01:05 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9JG11EB010379
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Oct 2012 16:01:01 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9JG10Mr028989
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 19 Oct 2012 16:01:00 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9JG0xhV006715; Fri, 19 Oct 2012 11:00:59 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Oct 2012 09:00:59 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1C78B4035B; Fri, 19 Oct 2012 11:48:55 -0400 (EDT)
Date: Fri, 19 Oct 2012 11:48:55 -0400
From: Konrad Rzeszutek Wilk 
To: "H. Peter Anvin" 
Message-ID: <20121019154854.GO26830@phenom.dumpdata.com>
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	<507ED6C0.4020503@zytor.com>
	<20121017161036.GA10691@phenom.dumpdata.com>
	<507EE1C3.7070300@zytor.com>
	<20121017165452.GA22740@phenom.dumpdata.com>
	<507EEC53.1010309@zytor.com>
	<84b3cbf9-7c84-4d7e-a2d7-46b0d1cc5975@default>
	<50802030.8070107@zytor.com>
	
	<50803057.5000307@zytor.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50803057.5000307@zytor.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Dan Magenheimer , xen-devel@lists.xensource.com,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, lenb@kernel.org
Subject: [Xen-devel] Is: Xen architecture document. Was: Re: Is: axe
 read_tscp pvops call. Was: Re: [RFC] ACPI S3 and Xen (suprisingly small\!).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> paravirtualized architectures out there which are perfectly well
> documented and supportable, but Xen has resisted doing that for
> years, and all we ever get are vague future promises.

There is no resistance - and it is being done. Every month we document
various APIs, man-pages, etc so that knowledge won't be lost. The
end-result of that is to create a PDF similar to the PowerPC architecture
document.

I have not been pointing you to it, b/c as of right what we have is
raw data (various header files growing in size) that keep on growing.
I need to hire/cajole an editor to help us get from the "raw" brain
dump to a book and some sense of milestones/schedule or whatever one
does in the book-world.

And Peter, just in case it is not clear, every suggestion you make is
appreciated and taken seriously. If there are things that have been
dropped or forgotten by me - please remind me.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 16:03:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 16:03:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPF2R-0002Om-CK; Fri, 19 Oct 2012 16:03:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPF2P-0002Oe-E4
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 16:03:05 +0000
Received: from [85.158.143.99:64110] by server-3.bemta-4.messagelabs.com id
	17/AF-03544-8B971805; Fri, 19 Oct 2012 16:03:04 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1350662583!28548900!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NDA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32128 invoked from network); 19 Oct 2012 16:03:04 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-216.messagelabs.com with SMTP;
	19 Oct 2012 16:03:04 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 19 Oct 2012 17:03:03 +0100
Message-Id: <5081960102000078000A2AC8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 19 Oct 2012 17:03:45 +0100
From: "Jan Beulich" 
To: "David Vrabel" 
References: <1350480580-4844-1-git-send-email-david.vrabel@citrix.com>
	<50818DF502000078000A2A84@nat28.tlf.novell.com>
	<50817540.5070908@citrix.com>
In-Reply-To: <50817540.5070908@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Frediano Ziglio ,
	Konrad Rzeszutek Wilk ,
	"stable@vger.kernel.org" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCHv2] xen/x86: don't corrupt %eip when
 returning from a signal handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 19.10.12 at 17:44, David Vrabel  wrote:
> On 19/10/12 16:29, Jan Beulich wrote:
>>>>> On 17.10.12 at 15:29, David Vrabel  wrote:
>>> @@ -1078,7 +1078,7 @@ ENDPROC(xen_hypervisor_callback)
>>>  # We distinguish between categories by maintaining a status value in EAX.
>>>  ENTRY(xen_failsafe_callback)
>>>  	CFI_STARTPROC
>>> -	pushl_cfi %eax
>>> +	pushl_cfi $-1  /* orig_ax = -1 => not a system call */
>> 
>> While making this apply to the 2.6.18 tree, I noticed that you
>> replaced the wrong push here, thus causing register corruption.
>> Just like on the 64-bit side, the one that needs fixing is the one
>> right before the SAVE_ALL (and hence it's again not just for
>> consistency, as zero is being pushed there too).
> 
> Oops.
> 
> We would have liked to test this path but could not see how to.  Do you
> have any ideas?

I'm not aware of a way to reliably trigger this without adding
assisting code to the kernel.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 16:03:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 16:03:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPF2R-0002Om-CK; Fri, 19 Oct 2012 16:03:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPF2P-0002Oe-E4
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 16:03:05 +0000
Received: from [85.158.143.99:64110] by server-3.bemta-4.messagelabs.com id
	17/AF-03544-8B971805; Fri, 19 Oct 2012 16:03:04 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1350662583!28548900!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NDA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32128 invoked from network); 19 Oct 2012 16:03:04 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-216.messagelabs.com with SMTP;
	19 Oct 2012 16:03:04 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 19 Oct 2012 17:03:03 +0100
Message-Id: <5081960102000078000A2AC8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 19 Oct 2012 17:03:45 +0100
From: "Jan Beulich" 
To: "David Vrabel" 
References: <1350480580-4844-1-git-send-email-david.vrabel@citrix.com>
	<50818DF502000078000A2A84@nat28.tlf.novell.com>
	<50817540.5070908@citrix.com>
In-Reply-To: <50817540.5070908@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Frediano Ziglio ,
	Konrad Rzeszutek Wilk ,
	"stable@vger.kernel.org" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCHv2] xen/x86: don't corrupt %eip when
 returning from a signal handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 19.10.12 at 17:44, David Vrabel  wrote:
> On 19/10/12 16:29, Jan Beulich wrote:
>>>>> On 17.10.12 at 15:29, David Vrabel  wrote:
>>> @@ -1078,7 +1078,7 @@ ENDPROC(xen_hypervisor_callback)
>>>  # We distinguish between categories by maintaining a status value in EAX.
>>>  ENTRY(xen_failsafe_callback)
>>>  	CFI_STARTPROC
>>> -	pushl_cfi %eax
>>> +	pushl_cfi $-1  /* orig_ax = -1 => not a system call */
>> 
>> While making this apply to the 2.6.18 tree, I noticed that you
>> replaced the wrong push here, thus causing register corruption.
>> Just like on the 64-bit side, the one that needs fixing is the one
>> right before the SAVE_ALL (and hence it's again not just for
>> consistency, as zero is being pushed there too).
> 
> Oops.
> 
> We would have liked to test this path but could not see how to.  Do you
> have any ideas?

I'm not aware of a way to reliably trigger this without adding
assisting code to the kernel.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 16:30:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 16:30:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPFSH-0002hM-Tx; Fri, 19 Oct 2012 16:29:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPFSG-0002hG-B0
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 16:29:48 +0000
Received: from [85.158.139.83:20856] by server-11.bemta-5.messagelabs.com id
	CF/B3-14870-BFF71805; Fri, 19 Oct 2012 16:29:47 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1350664185!28320301!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzc3ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 374 invoked from network); 19 Oct 2012 16:29:46 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 16:29:46 -0000
X-IronPort-AV: E=Sophos;i="4.80,613,1344211200"; d="scan'208";a="41848980"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 16:29:22 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 19 Oct 2012 12:29:21 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TPFRp-0003JM-CJ;
	Fri, 19 Oct 2012 17:29:21 +0100
From: David Vrabel 
To: xen-devel@lists.xen.org
Date: Fri, 19 Oct 2012 17:29:07 +0100
Message-ID: <1350664147-26621-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: David Vrabel , stable@vger.kernel.org,
	Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCHv3] xen/x86: don't corrupt %eip when returning
	from a signal handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel 

In 32 bit guests, if a userspace process has %eax == -ERESTARTSYS
(-512) or -ERESTARTNOINTR (-513) when it is interrupted by an event
/and/ the process has a pending signal then %eip (and %eax) are
corrupted when returning to the main process after handling the
signal.  The application may then crash with SIGSEGV or a SIGILL or it
may have subtly incorrect behaviour (depending on what instruction it
returned to).

The occurs because handle_signal() is incorrectly thinking that there
is a system call that needs to restarted so it adjusts %eip and %eax
to re-execute the system call instruction (even though user space had
not done a system call).

If %eax == -514 (-ERESTARTNOHAND (-514) or -ERESTART_RESTARTBLOCK
(-516) then handle_signal() only corrupted %eax (by setting it to
-EINTR).  This may cause the application to crash or have incorrect
behaviour.

handle_signal() assumes that regs->orig_ax >= 0 means a system call so
any kernel entry point that is not for a system call must push a
negative value for orig_ax.  For example, for physical interrupts on
bare metal the inverse of the vector is pushed and page_fault() sets
regs->orig_ax to -1, overwriting the hardware provided error code.

xen_hypervisor_callback() was incorrectly pushing 0 for orig_ax
instead of -1.

Classic Xen kernels pushed %eax which works as %eax cannot be both
non-negative and -RESTARTSYS (etc.), but using -1 is consistent with
other non-system call entry points and avoids some of the tests in
handle_signal().

There were similar bugs in xen_failsafe_callback() of both 32 and
64-bit guests. If the fault was corrected and the normal return path
was used then 0 was incorrectly pushed as the value for orig_ax.

Signed-off-by: David Vrabel 
Acked-by: Jan Beulich 
Acked-by: Ian Campbell 
Cc: stable@vger.kernel.org
---
v3:
  - fixup the right push in the 32-bit xen_failsafe_callback().
---
 arch/x86/kernel/entry_32.S |    8 +++++---
 arch/x86/kernel/entry_64.S |    2 +-
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
index 2c63407..985f7b3 100644
--- a/arch/x86/kernel/entry_32.S
+++ b/arch/x86/kernel/entry_32.S
@@ -1042,7 +1042,7 @@ ENTRY(xen_sysenter_target)
 
 ENTRY(xen_hypervisor_callback)
 	CFI_STARTPROC
-	pushl_cfi $0
+	pushl_cfi $-1 /* orig_ax = -1 => not a system call */
 	SAVE_ALL
 	TRACE_IRQS_OFF
 
@@ -1084,14 +1084,16 @@ ENTRY(xen_failsafe_callback)
 2:	mov 8(%esp),%es
 3:	mov 12(%esp),%fs
 4:	mov 16(%esp),%gs
+	/* EAX == 0 => Category 1 (Bad segment)
+	   EAX != 0 => Category 2 (Bad IRET) */
 	testl %eax,%eax
 	popl_cfi %eax
 	lea 16(%esp),%esp
 	CFI_ADJUST_CFA_OFFSET -16
 	jz 5f
 	addl $16,%esp
-	jmp iret_exc		# EAX != 0 => Category 2 (Bad IRET)
-5:	pushl_cfi $0		# EAX == 0 => Category 1 (Bad segment)
+	jmp iret_exc
+5:	pushl_cfi $-1 /* orig_ax = -1 => not a system call */
 	SAVE_ALL
 	jmp ret_from_exception
 	CFI_ENDPROC
diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index cdc790c..430b1fc 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -1451,7 +1451,7 @@ ENTRY(xen_failsafe_callback)
 	CFI_RESTORE r11
 	addq $0x30,%rsp
 	CFI_ADJUST_CFA_OFFSET -0x30
-	pushq_cfi $0
+	pushq_cfi $-1 /* orig_ax = -1 => not a system call */
 	SAVE_ALL
 	jmp error_exit
 	CFI_ENDPROC
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 16:30:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 16:30:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPFSH-0002hM-Tx; Fri, 19 Oct 2012 16:29:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPFSG-0002hG-B0
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 16:29:48 +0000
Received: from [85.158.139.83:20856] by server-11.bemta-5.messagelabs.com id
	CF/B3-14870-BFF71805; Fri, 19 Oct 2012 16:29:47 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1350664185!28320301!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzc3ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 374 invoked from network); 19 Oct 2012 16:29:46 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 16:29:46 -0000
X-IronPort-AV: E=Sophos;i="4.80,613,1344211200"; d="scan'208";a="41848980"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 16:29:22 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 19 Oct 2012 12:29:21 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TPFRp-0003JM-CJ;
	Fri, 19 Oct 2012 17:29:21 +0100
From: David Vrabel 
To: xen-devel@lists.xen.org
Date: Fri, 19 Oct 2012 17:29:07 +0100
Message-ID: <1350664147-26621-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: David Vrabel , stable@vger.kernel.org,
	Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCHv3] xen/x86: don't corrupt %eip when returning
	from a signal handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel 

In 32 bit guests, if a userspace process has %eax == -ERESTARTSYS
(-512) or -ERESTARTNOINTR (-513) when it is interrupted by an event
/and/ the process has a pending signal then %eip (and %eax) are
corrupted when returning to the main process after handling the
signal.  The application may then crash with SIGSEGV or a SIGILL or it
may have subtly incorrect behaviour (depending on what instruction it
returned to).

The occurs because handle_signal() is incorrectly thinking that there
is a system call that needs to restarted so it adjusts %eip and %eax
to re-execute the system call instruction (even though user space had
not done a system call).

If %eax == -514 (-ERESTARTNOHAND (-514) or -ERESTART_RESTARTBLOCK
(-516) then handle_signal() only corrupted %eax (by setting it to
-EINTR).  This may cause the application to crash or have incorrect
behaviour.

handle_signal() assumes that regs->orig_ax >= 0 means a system call so
any kernel entry point that is not for a system call must push a
negative value for orig_ax.  For example, for physical interrupts on
bare metal the inverse of the vector is pushed and page_fault() sets
regs->orig_ax to -1, overwriting the hardware provided error code.

xen_hypervisor_callback() was incorrectly pushing 0 for orig_ax
instead of -1.

Classic Xen kernels pushed %eax which works as %eax cannot be both
non-negative and -RESTARTSYS (etc.), but using -1 is consistent with
other non-system call entry points and avoids some of the tests in
handle_signal().

There were similar bugs in xen_failsafe_callback() of both 32 and
64-bit guests. If the fault was corrected and the normal return path
was used then 0 was incorrectly pushed as the value for orig_ax.

Signed-off-by: David Vrabel 
Acked-by: Jan Beulich 
Acked-by: Ian Campbell 
Cc: stable@vger.kernel.org
---
v3:
  - fixup the right push in the 32-bit xen_failsafe_callback().
---
 arch/x86/kernel/entry_32.S |    8 +++++---
 arch/x86/kernel/entry_64.S |    2 +-
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
index 2c63407..985f7b3 100644
--- a/arch/x86/kernel/entry_32.S
+++ b/arch/x86/kernel/entry_32.S
@@ -1042,7 +1042,7 @@ ENTRY(xen_sysenter_target)
 
 ENTRY(xen_hypervisor_callback)
 	CFI_STARTPROC
-	pushl_cfi $0
+	pushl_cfi $-1 /* orig_ax = -1 => not a system call */
 	SAVE_ALL
 	TRACE_IRQS_OFF
 
@@ -1084,14 +1084,16 @@ ENTRY(xen_failsafe_callback)
 2:	mov 8(%esp),%es
 3:	mov 12(%esp),%fs
 4:	mov 16(%esp),%gs
+	/* EAX == 0 => Category 1 (Bad segment)
+	   EAX != 0 => Category 2 (Bad IRET) */
 	testl %eax,%eax
 	popl_cfi %eax
 	lea 16(%esp),%esp
 	CFI_ADJUST_CFA_OFFSET -16
 	jz 5f
 	addl $16,%esp
-	jmp iret_exc		# EAX != 0 => Category 2 (Bad IRET)
-5:	pushl_cfi $0		# EAX == 0 => Category 1 (Bad segment)
+	jmp iret_exc
+5:	pushl_cfi $-1 /* orig_ax = -1 => not a system call */
 	SAVE_ALL
 	jmp ret_from_exception
 	CFI_ENDPROC
diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index cdc790c..430b1fc 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -1451,7 +1451,7 @@ ENTRY(xen_failsafe_callback)
 	CFI_RESTORE r11
 	addq $0x30,%rsp
 	CFI_ADJUST_CFA_OFFSET -0x30
-	pushq_cfi $0
+	pushq_cfi $-1 /* orig_ax = -1 => not a system call */
 	SAVE_ALL
 	jmp error_exit
 	CFI_ENDPROC
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 16:36:03 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 16:36:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPFY0-0002sl-RK; Fri, 19 Oct 2012 16:35:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPFXy-0002sf-SF
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 16:35:43 +0000
Received: from [193.109.254.147:42865] by server-5.bemta-14.messagelabs.com id
	E6/CE-18309-E5181805; Fri, 19 Oct 2012 16:35:42 +0000
X-Env-Sender: dmitry.torokhov@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1350664539!4182428!1
X-Originating-IP: [209.85.220.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12691 invoked from network); 19 Oct 2012 16:35:40 -0000
Received: from mail-pa0-f45.google.com (HELO mail-pa0-f45.google.com)
	(209.85.220.45)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 16:35:40 -0000
Received: by mail-pa0-f45.google.com with SMTP id fb10so526168pad.32
	for ; Fri, 19 Oct 2012 09:34:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=xXrGA93B/NQaNxBXj1gPPm/7K5CzI5c3m+Gx4fAaG/A=;
	b=VqT80P+eMBhT9Lghq7GMfEwayR6vZd7oJc7yW/vxcJA4mhzj/gPnxjuc/PTmhTxqno
	/LHa9BNikItcYfIWEh2pN0KDNFuAzIiyzOwGn5wv3c9ktDurKGgihFGgR8Yu6OpxOyM/
	4XUtOTQkgrws01viTt2ulKmAEo+r2tgbRgF8Gm5DZvhzUSK+ceTwJym/PHyIcHB/3AZZ
	Lf9j3Ev9vk3T0ojdAM4nfjssoOHRbNOR0uzS1LRayWSFUZfnxU3M8cFjTfTthWCb0Xlg
	TuaYZg8tKL281TtUZu4tZf1rspJ820PVgpp1guEPGcE+CnX3ZElL+GOjyQqdJZcR+sw1
	zMsQ==
Received: by 10.68.237.232 with SMTP id vf8mr7274881pbc.65.1350664479621;
	Fri, 19 Oct 2012 09:34:39 -0700 (PDT)
Received: from mailhub.coreip.homeip.net (c-67-188-112-76.hsd1.ca.comcast.net.
	[67.188.112.76])
	by mx.google.com with ESMTPS id kc4sm1461557pbc.23.2012.10.19.09.34.37
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 19 Oct 2012 09:34:38 -0700 (PDT)
Date: Fri, 19 Oct 2012 09:34:36 -0700
From: Dmitry Torokhov 
To: Konrad Rzeszutek Wilk 
Message-ID: <20121019163436.GB2152@core.coreip.homeip.net>
References: <507FD39F.4060601@citrix.com>
	<1350554618-14582-5-git-send-email-david.vrabel@citrix.com>
	<20121019130059.GE26830@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20121019130059.GE26830@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: linux-kernel@vger.kernel.org, linux-input@vger.kernel.org,
	David Vrabel , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 5/5] xen-kbdfront: handle backend CLOSED
	without CLOSING
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 19, 2012 at 09:00:59AM -0400, Konrad Rzeszutek Wilk wrote:
> On Thu, Oct 18, 2012 at 11:03:38AM +0100, David Vrabel wrote:
> > From: David Vrabel 
> > 
> > Backend drivers shouldn't transistion to CLOSED unless the frontend is
> > CLOSED.  If a backend does transition to CLOSED too soon then the
> > frontend may not see the CLOSING state and will not properly shutdown.
> > 
> > So, treat an unexpected backend CLOSED state the same as CLOSING.
> > 
> > Signed-off-by: David Vrabel 
> > Acked-by: Konrad Rzeszutek Wilk 
> > ---
> > Cc: linux-input@vger.kernel.org
> > Cc: Dmitry Torokhov 
> 
> Hey Dmitry,
> 
> Should I prep a git pull for you for this or are you OK giving
> an Ack for me to put this patch in my git pull for Linus?

Sure, please merge with the rest through your tree.

Acked-by: Dmitry Torokhov 

Thanks!

> 
> Thx.
> > ---
> >  drivers/input/misc/xen-kbdfront.c |    5 ++++-
> >  1 files changed, 4 insertions(+), 1 deletions(-)
> > 
> > diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
> > index 02ca868..6f7d990 100644
> > --- a/drivers/input/misc/xen-kbdfront.c
> > +++ b/drivers/input/misc/xen-kbdfront.c
> > @@ -311,7 +311,6 @@ static void xenkbd_backend_changed(struct xenbus_device *dev,
> >  	case XenbusStateReconfiguring:
> >  	case XenbusStateReconfigured:
> >  	case XenbusStateUnknown:
> > -	case XenbusStateClosed:
> >  		break;
> >  
> >  	case XenbusStateInitWait:
> > @@ -350,6 +349,10 @@ InitWait:
> >  
> >  		break;
> >  
> > +	case XenbusStateClosed:
> > +		if (dev->state == XenbusStateClosed)
> > +			break;
> > +		/* Missed the backend's CLOSING state -- fallthrough */
> >  	case XenbusStateClosing:
> >  		xenbus_frontend_closed(dev);
> >  		break;
> > -- 
> > 1.7.2.5

-- 
Dmitry

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 16:36:03 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 16:36:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPFY0-0002sl-RK; Fri, 19 Oct 2012 16:35:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPFXy-0002sf-SF
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 16:35:43 +0000
Received: from [193.109.254.147:42865] by server-5.bemta-14.messagelabs.com id
	E6/CE-18309-E5181805; Fri, 19 Oct 2012 16:35:42 +0000
X-Env-Sender: dmitry.torokhov@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1350664539!4182428!1
X-Originating-IP: [209.85.220.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12691 invoked from network); 19 Oct 2012 16:35:40 -0000
Received: from mail-pa0-f45.google.com (HELO mail-pa0-f45.google.com)
	(209.85.220.45)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 16:35:40 -0000
Received: by mail-pa0-f45.google.com with SMTP id fb10so526168pad.32
	for ; Fri, 19 Oct 2012 09:34:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=xXrGA93B/NQaNxBXj1gPPm/7K5CzI5c3m+Gx4fAaG/A=;
	b=VqT80P+eMBhT9Lghq7GMfEwayR6vZd7oJc7yW/vxcJA4mhzj/gPnxjuc/PTmhTxqno
	/LHa9BNikItcYfIWEh2pN0KDNFuAzIiyzOwGn5wv3c9ktDurKGgihFGgR8Yu6OpxOyM/
	4XUtOTQkgrws01viTt2ulKmAEo+r2tgbRgF8Gm5DZvhzUSK+ceTwJym/PHyIcHB/3AZZ
	Lf9j3Ev9vk3T0ojdAM4nfjssoOHRbNOR0uzS1LRayWSFUZfnxU3M8cFjTfTthWCb0Xlg
	TuaYZg8tKL281TtUZu4tZf1rspJ820PVgpp1guEPGcE+CnX3ZElL+GOjyQqdJZcR+sw1
	zMsQ==
Received: by 10.68.237.232 with SMTP id vf8mr7274881pbc.65.1350664479621;
	Fri, 19 Oct 2012 09:34:39 -0700 (PDT)
Received: from mailhub.coreip.homeip.net (c-67-188-112-76.hsd1.ca.comcast.net.
	[67.188.112.76])
	by mx.google.com with ESMTPS id kc4sm1461557pbc.23.2012.10.19.09.34.37
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 19 Oct 2012 09:34:38 -0700 (PDT)
Date: Fri, 19 Oct 2012 09:34:36 -0700
From: Dmitry Torokhov 
To: Konrad Rzeszutek Wilk 
Message-ID: <20121019163436.GB2152@core.coreip.homeip.net>
References: <507FD39F.4060601@citrix.com>
	<1350554618-14582-5-git-send-email-david.vrabel@citrix.com>
	<20121019130059.GE26830@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20121019130059.GE26830@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: linux-kernel@vger.kernel.org, linux-input@vger.kernel.org,
	David Vrabel , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 5/5] xen-kbdfront: handle backend CLOSED
	without CLOSING
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 19, 2012 at 09:00:59AM -0400, Konrad Rzeszutek Wilk wrote:
> On Thu, Oct 18, 2012 at 11:03:38AM +0100, David Vrabel wrote:
> > From: David Vrabel 
> > 
> > Backend drivers shouldn't transistion to CLOSED unless the frontend is
> > CLOSED.  If a backend does transition to CLOSED too soon then the
> > frontend may not see the CLOSING state and will not properly shutdown.
> > 
> > So, treat an unexpected backend CLOSED state the same as CLOSING.
> > 
> > Signed-off-by: David Vrabel 
> > Acked-by: Konrad Rzeszutek Wilk 
> > ---
> > Cc: linux-input@vger.kernel.org
> > Cc: Dmitry Torokhov 
> 
> Hey Dmitry,
> 
> Should I prep a git pull for you for this or are you OK giving
> an Ack for me to put this patch in my git pull for Linus?

Sure, please merge with the rest through your tree.

Acked-by: Dmitry Torokhov 

Thanks!

> 
> Thx.
> > ---
> >  drivers/input/misc/xen-kbdfront.c |    5 ++++-
> >  1 files changed, 4 insertions(+), 1 deletions(-)
> > 
> > diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
> > index 02ca868..6f7d990 100644
> > --- a/drivers/input/misc/xen-kbdfront.c
> > +++ b/drivers/input/misc/xen-kbdfront.c
> > @@ -311,7 +311,6 @@ static void xenkbd_backend_changed(struct xenbus_device *dev,
> >  	case XenbusStateReconfiguring:
> >  	case XenbusStateReconfigured:
> >  	case XenbusStateUnknown:
> > -	case XenbusStateClosed:
> >  		break;
> >  
> >  	case XenbusStateInitWait:
> > @@ -350,6 +349,10 @@ InitWait:
> >  
> >  		break;
> >  
> > +	case XenbusStateClosed:
> > +		if (dev->state == XenbusStateClosed)
> > +			break;
> > +		/* Missed the backend's CLOSING state -- fallthrough */
> >  	case XenbusStateClosing:
> >  		xenbus_frontend_closed(dev);
> >  		break;
> > -- 
> > 1.7.2.5

-- 
Dmitry

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 16:52:07 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 16:52:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPFnW-0003KN-60; Fri, 19 Oct 2012 16:51:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPFnU-0003KI-1w
	for xen-devel@lists.xensource.com; Fri, 19 Oct 2012 16:51:44 +0000
Received: from [85.158.138.51:19475] by server-7.bemta-3.messagelabs.com id
	7F/F7-06991-F1581805; Fri, 19 Oct 2012 16:51:43 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1350665501!34535331!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25292 invoked from network); 19 Oct 2012 16:51:42 -0000
Received: from mail-vc0-f171.google.com (HELO mail-vc0-f171.google.com)
	(209.85.220.171)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 16:51:42 -0000
Received: by mail-vc0-f171.google.com with SMTP id m18so902633vcm.30
	for ;
	Fri, 19 Oct 2012 09:51:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=xgKXR3yVjK1Vuc4ICZU8fI/Fu5QyS9Hsoc7g1WbEvK4=;
	b=zVctDrKBtNET9RN17hd5eHl0GZOG3ubtjlXQmJn0nWN0RimqbS1yvOMr4Ez449rU+i
	UOdqiesr3zZIkkQVSABnfEUr2mCf+lvcFDzyNqsw1MrnyBCjyOQkFwMi8m6bWwS/8qfB
	Ffg6l7TVG3Q49JR1t1tutMu6dh1kyc2gYxWXf9HXBpfgqOqDvGxV6KqPfyi2rPBuoPLn
	E0B47CfeCernr5m0LATUnEzGOAMLlmbCQWw8t9g1SUaDbpxiwjZ/fqXFXJCTnwgkJZ4F
	QqqW+H5nGBgF78XPjCbCYxzm8FyZHt+P84EdQh9rfbfXfICMrLpp+T5zGa5kitCEvK77
	tQgQ==
MIME-Version: 1.0
Received: by 10.52.16.110 with SMTP id f14mr1941153vdd.8.1350665500857; Fri,
	19 Oct 2012 09:51:40 -0700 (PDT)
Received: by 10.58.231.138 with HTTP; Fri, 19 Oct 2012 09:51:40 -0700 (PDT)
In-Reply-To: 
References: 
Date: Fri, 19 Oct 2012 17:51:40 +0100
X-Google-Sender-Auth: _isD3Qkfu3F7FMBX_RhFc4fYEc0
Message-ID: 
From: George Dunlap 
To: "Liu, Jinsong" 
Cc: Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	Ian Jackson , Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration when vMCE
	occur
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 10, 2012 at 3:46 PM, Liu, Jinsong  wrote:
> Xen/MCE: Abort live migration when vMCE occur
>
> This patch monitor the critical area of live migration (from vMCE point of view,
> the copypages stage of migration is the critical area while other areas are not).
>
> If a vMCE occur at the critical area of live migration, there is risk that error
> data may be copied to the target. Currently we don't have convenient way to handle
> this case, so for the sake of safe, we abort it and try migration later (at that
> time broken page would not be mapped and copied to the target).
>
> Signed-off-by: Liu, Jinsong 

I'm not sure exactly what this patch is meant to do -- it won't
actually stop the broken page from being read, and it won't stop the
migration in the middle; instead it will finish copying the memory
before deciding to quit.

Wouldn't your patch 5 be sufficient to deal with this case?  It seems
like the broken page would get marked as such, and then get marked
broken on the receiving side, wouldn't it?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 16:52:07 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 16:52:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPFnW-0003KN-60; Fri, 19 Oct 2012 16:51:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPFnU-0003KI-1w
	for xen-devel@lists.xensource.com; Fri, 19 Oct 2012 16:51:44 +0000
Received: from [85.158.138.51:19475] by server-7.bemta-3.messagelabs.com id
	7F/F7-06991-F1581805; Fri, 19 Oct 2012 16:51:43 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1350665501!34535331!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25292 invoked from network); 19 Oct 2012 16:51:42 -0000
Received: from mail-vc0-f171.google.com (HELO mail-vc0-f171.google.com)
	(209.85.220.171)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 16:51:42 -0000
Received: by mail-vc0-f171.google.com with SMTP id m18so902633vcm.30
	for ;
	Fri, 19 Oct 2012 09:51:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=xgKXR3yVjK1Vuc4ICZU8fI/Fu5QyS9Hsoc7g1WbEvK4=;
	b=zVctDrKBtNET9RN17hd5eHl0GZOG3ubtjlXQmJn0nWN0RimqbS1yvOMr4Ez449rU+i
	UOdqiesr3zZIkkQVSABnfEUr2mCf+lvcFDzyNqsw1MrnyBCjyOQkFwMi8m6bWwS/8qfB
	Ffg6l7TVG3Q49JR1t1tutMu6dh1kyc2gYxWXf9HXBpfgqOqDvGxV6KqPfyi2rPBuoPLn
	E0B47CfeCernr5m0LATUnEzGOAMLlmbCQWw8t9g1SUaDbpxiwjZ/fqXFXJCTnwgkJZ4F
	QqqW+H5nGBgF78XPjCbCYxzm8FyZHt+P84EdQh9rfbfXfICMrLpp+T5zGa5kitCEvK77
	tQgQ==
MIME-Version: 1.0
Received: by 10.52.16.110 with SMTP id f14mr1941153vdd.8.1350665500857; Fri,
	19 Oct 2012 09:51:40 -0700 (PDT)
Received: by 10.58.231.138 with HTTP; Fri, 19 Oct 2012 09:51:40 -0700 (PDT)
In-Reply-To: 
References: 
Date: Fri, 19 Oct 2012 17:51:40 +0100
X-Google-Sender-Auth: _isD3Qkfu3F7FMBX_RhFc4fYEc0
Message-ID: 
From: George Dunlap 
To: "Liu, Jinsong" 
Cc: Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	Ian Jackson , Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration when vMCE
	occur
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 10, 2012 at 3:46 PM, Liu, Jinsong  wrote:
> Xen/MCE: Abort live migration when vMCE occur
>
> This patch monitor the critical area of live migration (from vMCE point of view,
> the copypages stage of migration is the critical area while other areas are not).
>
> If a vMCE occur at the critical area of live migration, there is risk that error
> data may be copied to the target. Currently we don't have convenient way to handle
> this case, so for the sake of safe, we abort it and try migration later (at that
> time broken page would not be mapped and copied to the target).
>
> Signed-off-by: Liu, Jinsong 

I'm not sure exactly what this patch is meant to do -- it won't
actually stop the broken page from being read, and it won't stop the
migration in the middle; instead it will finish copying the memory
before deciding to quit.

Wouldn't your patch 5 be sufficient to deal with this case?  It seems
like the broken page would get marked as such, and then get marked
broken on the receiving side, wouldn't it?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 16:54:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 16:54:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPFpu-0003Qt-PI; Fri, 19 Oct 2012 16:54:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPFpt-0003Qm-CQ
	for xen-devel@lists.xensource.com; Fri, 19 Oct 2012 16:54:13 +0000
Received: from [85.158.138.51:29903] by server-9.bemta-3.messagelabs.com id
	9D/4A-16841-4B581805; Fri, 19 Oct 2012 16:54:12 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1350665650!34989765!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15957 invoked from network); 19 Oct 2012 16:54:11 -0000
Received: from mail-vc0-f171.google.com (HELO mail-vc0-f171.google.com)
	(209.85.220.171)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 16:54:11 -0000
Received: by mail-vc0-f171.google.com with SMTP id m18so906054vcm.30
	for ;
	Fri, 19 Oct 2012 09:54:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=QqiBtkX8xcjpiGHj5s0egpHEULNNvwfvrJ9FBIDEVTc=;
	b=yoYMizHxteEq7IJSD0UQi7FgEW33+DgtpicqhiTtnBLIcW6cb4zJlTNh58PGbxi2iN
	49QSfvKDVspqt32P1yvv5RyuPjseEQfRXqCnznn6bKffGeOxJpIvwF/6WJGEnQGBgl2S
	j6My4CqqJKlRs3pvXD3zKGJ/rE67bKWWfX29IgXyD4+tEBlOXewNFDKpbaPB33SEq6po
	QQYUiybT+px8QnKZB6LqxVE4mixicwERhTC0CchLTK+FTwZra7DDK3GINgkgM1O0gtYh
	iA7kSLMlz29fe84g+lPvX6csScC1Su4a789KG4uIavcjVVbF9gO6hgGGTzSX7YLranTC
	B7PQ==
MIME-Version: 1.0
Received: by 10.58.189.33 with SMTP id gf1mr2524561vec.41.1350665650347; Fri,
	19 Oct 2012 09:54:10 -0700 (PDT)
Received: by 10.58.231.138 with HTTP; Fri, 19 Oct 2012 09:54:10 -0700 (PDT)
In-Reply-To: 
References: 
Date: Fri, 19 Oct 2012 17:54:10 +0100
X-Google-Sender-Auth: GcJcyGg5uKreU8rUlknaVJkVkHc
Message-ID: 
From: George Dunlap 
To: "Liu, Jinsong" 
Cc: Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	Ian Jackson , Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 5/5] X86/vMCE: guest broken page handling
	when migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 10, 2012 at 3:47 PM, Liu, Jinsong  wrote:
> X86/vMCE: guest broken page handling when migration
>
> This patch is used to handle guest broken page when migration.
>
> At sender, the broken page would not be mapped, and the error page
> content would not be copied to target, otherwise it may trigger more
> serious error (i.e. SRAR error). While its pfn_type and pfn number
> would be transferred to target so that target take appropriate action.
>
> At target, it would set p2m as p2m_ram_broken for broken page, so that
> if guest access the broken page again, it would kill guest as expected.
>
> Signed-off-by: Liu, Jinsong 

The changes to the save/restore code look correct to me; they
shouldn't break backwards-compatibility (i.e., migrating 4.2 -> 4.3).

(Save/restore algorithm) Acked-by: George Dunlap 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 16:54:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 16:54:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPFpu-0003Qt-PI; Fri, 19 Oct 2012 16:54:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPFpt-0003Qm-CQ
	for xen-devel@lists.xensource.com; Fri, 19 Oct 2012 16:54:13 +0000
Received: from [85.158.138.51:29903] by server-9.bemta-3.messagelabs.com id
	9D/4A-16841-4B581805; Fri, 19 Oct 2012 16:54:12 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1350665650!34989765!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15957 invoked from network); 19 Oct 2012 16:54:11 -0000
Received: from mail-vc0-f171.google.com (HELO mail-vc0-f171.google.com)
	(209.85.220.171)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 16:54:11 -0000
Received: by mail-vc0-f171.google.com with SMTP id m18so906054vcm.30
	for ;
	Fri, 19 Oct 2012 09:54:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=QqiBtkX8xcjpiGHj5s0egpHEULNNvwfvrJ9FBIDEVTc=;
	b=yoYMizHxteEq7IJSD0UQi7FgEW33+DgtpicqhiTtnBLIcW6cb4zJlTNh58PGbxi2iN
	49QSfvKDVspqt32P1yvv5RyuPjseEQfRXqCnznn6bKffGeOxJpIvwF/6WJGEnQGBgl2S
	j6My4CqqJKlRs3pvXD3zKGJ/rE67bKWWfX29IgXyD4+tEBlOXewNFDKpbaPB33SEq6po
	QQYUiybT+px8QnKZB6LqxVE4mixicwERhTC0CchLTK+FTwZra7DDK3GINgkgM1O0gtYh
	iA7kSLMlz29fe84g+lPvX6csScC1Su4a789KG4uIavcjVVbF9gO6hgGGTzSX7YLranTC
	B7PQ==
MIME-Version: 1.0
Received: by 10.58.189.33 with SMTP id gf1mr2524561vec.41.1350665650347; Fri,
	19 Oct 2012 09:54:10 -0700 (PDT)
Received: by 10.58.231.138 with HTTP; Fri, 19 Oct 2012 09:54:10 -0700 (PDT)
In-Reply-To: 
References: 
Date: Fri, 19 Oct 2012 17:54:10 +0100
X-Google-Sender-Auth: GcJcyGg5uKreU8rUlknaVJkVkHc
Message-ID: 
From: George Dunlap 
To: "Liu, Jinsong" 
Cc: Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	Ian Jackson , Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 5/5] X86/vMCE: guest broken page handling
	when migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 10, 2012 at 3:47 PM, Liu, Jinsong  wrote:
> X86/vMCE: guest broken page handling when migration
>
> This patch is used to handle guest broken page when migration.
>
> At sender, the broken page would not be mapped, and the error page
> content would not be copied to target, otherwise it may trigger more
> serious error (i.e. SRAR error). While its pfn_type and pfn number
> would be transferred to target so that target take appropriate action.
>
> At target, it would set p2m as p2m_ram_broken for broken page, so that
> if guest access the broken page again, it would kill guest as expected.
>
> Signed-off-by: Liu, Jinsong 

The changes to the save/restore code look correct to me; they
shouldn't break backwards-compatibility (i.e., migrating 4.2 -> 4.3).

(Save/restore algorithm) Acked-by: George Dunlap 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 17:01:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 17:01:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPFwI-0003kX-SB; Fri, 19 Oct 2012 17:00:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPFwG-0003kP-Nk
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 17:00:49 +0000
Received: from [85.158.138.51:15349] by server-7.bemta-3.messagelabs.com id
	FC/EE-06991-F3781805; Fri, 19 Oct 2012 17:00:47 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1350666046!34958126!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUwMDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18726 invoked from network); 19 Oct 2012 17:00:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 17:00:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,613,1344211200"; 
	d="asc'?scan'208";a="15281842"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 17:00:43 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 19 Oct 2012 18:00:43 +0100
Message-ID: <1350666041.6053.69.camel@Solace>
From: Dario Faggioli 
To: 
Date: Fri, 19 Oct 2012 19:00:41 +0200
In-Reply-To: <09276c114a9a3dcc6058.1350657294@Solace>
References: 
	<09276c114a9a3dcc6058.1350657294@Solace>
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Andre Przywara ,
	Ian Jackson ,
	Ian Campbell 
Subject: Re: [Xen-devel] [PATCH 1 of 3 v2] libxl: take node distances into
 account during NUMA placement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============3591020288452518665=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3591020288452518665==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-B02XjIDsPoANG7wF79NB"

--=-B02XjIDsPoANG7wF79NB
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-10-19 at 16:34 +0200, Dario Faggioli wrote:
> In fact, among placement candidates with the same number of nodes, the
> closer the various nodes are to each others, the better the performances
> for a domain placed there.
>=20
So, it seems we need to discuss a bit more about this patch... Please,
ignore it for now.

OTOH, patches 2 and 3 can be considered for further review/ack/commit,
even without this one, as they are pretty much unrelated from this one
(and within each other). I'd expect them to apply cleanly, but if I need
to rebase and resend, let me know.

Thanks and Regards,
Dario

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-B02XjIDsPoANG7wF79NB
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlCBhzkACgkQk4XaBE3IOsQOzACfXnRsOThj757zXFl+O/u9cF/f
NF4AnRW2x+wBBM6CqLzxEiLTF/SpLwDN
=nSWj
-----END PGP SIGNATURE-----

--=-B02XjIDsPoANG7wF79NB--


--===============3591020288452518665==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3591020288452518665==--


From xen-devel-bounces@lists.xen.org Fri Oct 19 17:01:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 17:01:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPFwI-0003kX-SB; Fri, 19 Oct 2012 17:00:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPFwG-0003kP-Nk
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 17:00:49 +0000
Received: from [85.158.138.51:15349] by server-7.bemta-3.messagelabs.com id
	FC/EE-06991-F3781805; Fri, 19 Oct 2012 17:00:47 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1350666046!34958126!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUwMDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18726 invoked from network); 19 Oct 2012 17:00:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 17:00:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,613,1344211200"; 
	d="asc'?scan'208";a="15281842"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 17:00:43 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 19 Oct 2012 18:00:43 +0100
Message-ID: <1350666041.6053.69.camel@Solace>
From: Dario Faggioli 
To: 
Date: Fri, 19 Oct 2012 19:00:41 +0200
In-Reply-To: <09276c114a9a3dcc6058.1350657294@Solace>
References: 
	<09276c114a9a3dcc6058.1350657294@Solace>
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Andre Przywara ,
	Ian Jackson ,
	Ian Campbell 
Subject: Re: [Xen-devel] [PATCH 1 of 3 v2] libxl: take node distances into
 account during NUMA placement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============3591020288452518665=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3591020288452518665==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-B02XjIDsPoANG7wF79NB"

--=-B02XjIDsPoANG7wF79NB
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-10-19 at 16:34 +0200, Dario Faggioli wrote:
> In fact, among placement candidates with the same number of nodes, the
> closer the various nodes are to each others, the better the performances
> for a domain placed there.
>=20
So, it seems we need to discuss a bit more about this patch... Please,
ignore it for now.

OTOH, patches 2 and 3 can be considered for further review/ack/commit,
even without this one, as they are pretty much unrelated from this one
(and within each other). I'd expect them to apply cleanly, but if I need
to rebase and resend, let me know.

Thanks and Regards,
Dario

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-B02XjIDsPoANG7wF79NB
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlCBhzkACgkQk4XaBE3IOsQOzACfXnRsOThj757zXFl+O/u9cF/f
NF4AnRW2x+wBBM6CqLzxEiLTF/SpLwDN
=nSWj
-----END PGP SIGNATURE-----

--=-B02XjIDsPoANG7wF79NB--


--===============3591020288452518665==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3591020288452518665==--


From xen-devel-bounces@lists.xen.org Fri Oct 19 17:09:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 17:09:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPG4k-0003wS-BV; Fri, 19 Oct 2012 17:09:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPG4j-0003wN-7g
	for xen-devel@lists.xensource.com; Fri, 19 Oct 2012 17:09:33 +0000
Received: from [85.158.143.99:22551] by server-3.bemta-4.messagelabs.com id
	68/94-03544-C4981805; Fri, 19 Oct 2012 17:09:32 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1350666570!26626497!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18200 invoked from network); 19 Oct 2012 17:09:31 -0000
Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com)
	(209.85.212.43)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 17:09:31 -0000
Received: by mail-vb0-f43.google.com with SMTP id fq11so926737vbb.30
	for ;
	Fri, 19 Oct 2012 10:09:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=5jwL9FY55vZYMW3433RLz6c4k7gNdJl0wgwG25rVQXg=;
	b=S9K+7hxEBTI7QDSHlt+5ABR3CLn3R6Z1wKNBme7hO3dnFVzvoWw6ESmObWnIakuxtl
	Lp5qWNregoQ9gluODE9BnmvopuEN0QZQd37mrVdK3s7+VYEbe8Tw7N62DUfjaVzp5iHT
	eADkB22jIhaW8b/B35O48lhADZ5SCLMe7sQgV0sVtbsArvZu2d60GbjWICefeoJYoq+J
	24QQFhO6KKtAd/yshWKva78slE3BEE0VmWLT0sn780gBqP1bpP7KtTjkNB81+Ym4B2uq
	vOBJxARGUJGYBIzsDKTIs9cImyye1/p4DK3YsHvzrgf60AgY3zxYD8fdsJMf7/HPJAIa
	jVFQ==
MIME-Version: 1.0
Received: by 10.220.142.8 with SMTP id o8mr2524877vcu.23.1350666570353; Fri,
	19 Oct 2012 10:09:30 -0700 (PDT)
Received: by 10.58.231.138 with HTTP; Fri, 19 Oct 2012 10:09:30 -0700 (PDT)
In-Reply-To: <20609.28264.158580.995717@mariner.uk.xensource.com>
References: 
	<20609.28264.158580.995717@mariner.uk.xensource.com>
Date: Fri, 19 Oct 2012 18:09:30 +0100
X-Google-Sender-Auth: UQPotfXBG3Iu06Gdo1hBV_EAueE
Message-ID: 
From: George Dunlap 
To: Ian Jackson 
Cc: "Liu, Jinsong" ,
	Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 5/5] X86/vMCE: guest broken page handling
	when migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 19, 2012 at 4:14 PM, Ian Jackson  wrote:
> Liu, Jinsong writes ("[Xen-devel] [PATCH 5/5] X86/vMCE: guest broken page handling when migration"):
>> X86/vMCE: guest broken page handling when migration
>>
>> This patch is used to handle guest broken page when migration.
>
> This looks plausible to me, as far as the tools go.  Can you explain
> how you have tested this ?  Did you manage to do any tests of the
> remus codepaths ?

I'm pretty sure that this shouldn't cause any problems with Remus.  If
it's difficult for Jinsong to test Remus, I think probably OK to
commit it, and then revert it if the Remus guys have any problems.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 17:09:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 17:09:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPG4k-0003wS-BV; Fri, 19 Oct 2012 17:09:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPG4j-0003wN-7g
	for xen-devel@lists.xensource.com; Fri, 19 Oct 2012 17:09:33 +0000
Received: from [85.158.143.99:22551] by server-3.bemta-4.messagelabs.com id
	68/94-03544-C4981805; Fri, 19 Oct 2012 17:09:32 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1350666570!26626497!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18200 invoked from network); 19 Oct 2012 17:09:31 -0000
Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com)
	(209.85.212.43)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 17:09:31 -0000
Received: by mail-vb0-f43.google.com with SMTP id fq11so926737vbb.30
	for ;
	Fri, 19 Oct 2012 10:09:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=5jwL9FY55vZYMW3433RLz6c4k7gNdJl0wgwG25rVQXg=;
	b=S9K+7hxEBTI7QDSHlt+5ABR3CLn3R6Z1wKNBme7hO3dnFVzvoWw6ESmObWnIakuxtl
	Lp5qWNregoQ9gluODE9BnmvopuEN0QZQd37mrVdK3s7+VYEbe8Tw7N62DUfjaVzp5iHT
	eADkB22jIhaW8b/B35O48lhADZ5SCLMe7sQgV0sVtbsArvZu2d60GbjWICefeoJYoq+J
	24QQFhO6KKtAd/yshWKva78slE3BEE0VmWLT0sn780gBqP1bpP7KtTjkNB81+Ym4B2uq
	vOBJxARGUJGYBIzsDKTIs9cImyye1/p4DK3YsHvzrgf60AgY3zxYD8fdsJMf7/HPJAIa
	jVFQ==
MIME-Version: 1.0
Received: by 10.220.142.8 with SMTP id o8mr2524877vcu.23.1350666570353; Fri,
	19 Oct 2012 10:09:30 -0700 (PDT)
Received: by 10.58.231.138 with HTTP; Fri, 19 Oct 2012 10:09:30 -0700 (PDT)
In-Reply-To: <20609.28264.158580.995717@mariner.uk.xensource.com>
References: 
	<20609.28264.158580.995717@mariner.uk.xensource.com>
Date: Fri, 19 Oct 2012 18:09:30 +0100
X-Google-Sender-Auth: UQPotfXBG3Iu06Gdo1hBV_EAueE
Message-ID: 
From: George Dunlap 
To: Ian Jackson 
Cc: "Liu, Jinsong" ,
	Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 5/5] X86/vMCE: guest broken page handling
	when migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 19, 2012 at 4:14 PM, Ian Jackson  wrote:
> Liu, Jinsong writes ("[Xen-devel] [PATCH 5/5] X86/vMCE: guest broken page handling when migration"):
>> X86/vMCE: guest broken page handling when migration
>>
>> This patch is used to handle guest broken page when migration.
>
> This looks plausible to me, as far as the tools go.  Can you explain
> how you have tested this ?  Did you manage to do any tests of the
> remus codepaths ?

I'm pretty sure that this shouldn't cause any problems with Remus.  If
it's difficult for Jinsong to test Remus, I think probably OK to
commit it, and then revert it if the Remus guys have any problems.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 17:35:33 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 17:35:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPGTY-0004TW-Lh; Fri, 19 Oct 2012 17:35:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPGTX-0004TQ-Dy
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 17:35:11 +0000
Received: from [85.158.143.35:24443] by server-3.bemta-4.messagelabs.com id
	48/42-03544-E4F81805; Fri, 19 Oct 2012 17:35:10 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1350668108!5661323!1
X-Originating-IP: [72.21.196.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk2LjI1ID0+IDE0MjQ5Nw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9989 invoked from network); 19 Oct 2012 17:35:09 -0000
Received: from smtp-fw-2101.amazon.com (HELO smtp-fw-2101.amazon.com)
	(72.21.196.25)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 17:35:09 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt;
	s=amazon201209; t=1350668109; x=1382204109;
	h=from:to:cc:subject:date:message-id:mime-version;
	bh=5+sfTaOX72SSPl2xIsesAnSdQuXq9pnWmV8Jt8WR2Hk=;
	b=iBGZRogv9+xJoxWHtP86BHQQdsFgfkHB+/v7bOW1Uj6W3jGdFAZQyIur
	Zd9do6YIlv0ROJrQyt1veYKdf4QH3FtUw0d6aXay3Mpu9FAiSq+EtNRIK
	2Fd93+BnSsXa6jdal8p16cbm49PDLEkf6iTYShlp/HCygqeOQGHmLxkJo M=;
X-IronPort-AV: E=Sophos;i="4.80,614,1344211200"; d="scan'208";a="457175116"
Received: from smtp-in-1104.vdc.amazon.com ([10.140.10.25])
	by smtp-border-fw-out-2101.iad2.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Oct 2012 17:35:07 +0000
Received: from ex10-hub-31005.ant.amazon.com (ex10-hub-31005.sea31.amazon.com
	[10.185.176.12])
	by smtp-in-1104.vdc.amazon.com (8.13.8/8.13.8) with ESMTP id
	q9JHZ6ug025748
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Fri, 19 Oct 2012 17:35:07 GMT
Received: from kaos-source-31003.sea31.amazon.com (10.224.80.38) by
	ex10-hub-31005.ant.amazon.com (10.185.176.12) with Microsoft SMTP
	Server id 14.2.247.3; Fri, 19 Oct 2012 10:35:04 -0700
From: Matt Wilson 
To: Konrad Rzeszutek Wilk 
Date: Fri, 19 Oct 2012 17:34:35 +0000
Message-ID: <1350668075-5840-1-git-send-email-msw@amazon.com>
X-Mailer: git-send-email 1.7.4.5
MIME-Version: 1.0
Cc: Paul Harvey , Nikita Borzykh ,
	Ian Campbell ,
	Matt Wilson , xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] xen-netback: allow changing the MAC address of
	the interface
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Reported-by: Nikita Borzykh 
Reported-by: Paul Harvey 
Suggested-by: Ian Campbell 
Signed-off-by: Matt Wilson 
---
 drivers/net/xen-netback/interface.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index b7d41f8..f733cae 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -238,6 +238,8 @@ static const struct net_device_ops xenvif_netdev_ops = {
 	.ndo_stop	= xenvif_close,
 	.ndo_change_mtu	= xenvif_change_mtu,
 	.ndo_fix_features = xenvif_fix_features,
+	.ndo_set_mac_address = eth_mac_addr,
+	.ndo_validate_addr   = eth_validate_addr,
 };
 
 struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
-- 
1.7.4.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 17:35:33 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 17:35:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPGTY-0004TW-Lh; Fri, 19 Oct 2012 17:35:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPGTX-0004TQ-Dy
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 17:35:11 +0000
Received: from [85.158.143.35:24443] by server-3.bemta-4.messagelabs.com id
	48/42-03544-E4F81805; Fri, 19 Oct 2012 17:35:10 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1350668108!5661323!1
X-Originating-IP: [72.21.196.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk2LjI1ID0+IDE0MjQ5Nw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9989 invoked from network); 19 Oct 2012 17:35:09 -0000
Received: from smtp-fw-2101.amazon.com (HELO smtp-fw-2101.amazon.com)
	(72.21.196.25)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 17:35:09 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt;
	s=amazon201209; t=1350668109; x=1382204109;
	h=from:to:cc:subject:date:message-id:mime-version;
	bh=5+sfTaOX72SSPl2xIsesAnSdQuXq9pnWmV8Jt8WR2Hk=;
	b=iBGZRogv9+xJoxWHtP86BHQQdsFgfkHB+/v7bOW1Uj6W3jGdFAZQyIur
	Zd9do6YIlv0ROJrQyt1veYKdf4QH3FtUw0d6aXay3Mpu9FAiSq+EtNRIK
	2Fd93+BnSsXa6jdal8p16cbm49PDLEkf6iTYShlp/HCygqeOQGHmLxkJo M=;
X-IronPort-AV: E=Sophos;i="4.80,614,1344211200"; d="scan'208";a="457175116"
Received: from smtp-in-1104.vdc.amazon.com ([10.140.10.25])
	by smtp-border-fw-out-2101.iad2.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Oct 2012 17:35:07 +0000
Received: from ex10-hub-31005.ant.amazon.com (ex10-hub-31005.sea31.amazon.com
	[10.185.176.12])
	by smtp-in-1104.vdc.amazon.com (8.13.8/8.13.8) with ESMTP id
	q9JHZ6ug025748
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Fri, 19 Oct 2012 17:35:07 GMT
Received: from kaos-source-31003.sea31.amazon.com (10.224.80.38) by
	ex10-hub-31005.ant.amazon.com (10.185.176.12) with Microsoft SMTP
	Server id 14.2.247.3; Fri, 19 Oct 2012 10:35:04 -0700
From: Matt Wilson 
To: Konrad Rzeszutek Wilk 
Date: Fri, 19 Oct 2012 17:34:35 +0000
Message-ID: <1350668075-5840-1-git-send-email-msw@amazon.com>
X-Mailer: git-send-email 1.7.4.5
MIME-Version: 1.0
Cc: Paul Harvey , Nikita Borzykh ,
	Ian Campbell ,
	Matt Wilson , xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] xen-netback: allow changing the MAC address of
	the interface
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Reported-by: Nikita Borzykh 
Reported-by: Paul Harvey 
Suggested-by: Ian Campbell 
Signed-off-by: Matt Wilson 
---
 drivers/net/xen-netback/interface.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index b7d41f8..f733cae 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -238,6 +238,8 @@ static const struct net_device_ops xenvif_netdev_ops = {
 	.ndo_stop	= xenvif_close,
 	.ndo_change_mtu	= xenvif_change_mtu,
 	.ndo_fix_features = xenvif_fix_features,
+	.ndo_set_mac_address = eth_mac_addr,
+	.ndo_validate_addr   = eth_validate_addr,
 };
 
 struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
-- 
1.7.4.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 17:41:54 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 17:41:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPGZk-0004g6-OM; Fri, 19 Oct 2012 17:41:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPGZj-0004g1-Bw
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 17:41:35 +0000
Received: from [85.158.138.51:7398] by server-9.bemta-3.messagelabs.com id
	1F/FE-16841-EC091805; Fri, 19 Oct 2012 17:41:34 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-13.tower-174.messagelabs.com!1350668492!16361727!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MjAzNjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29835 invoked from network); 19 Oct 2012 17:41:32 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Oct 2012 17:41:32 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 5C01E2F58;
	Fri, 19 Oct 2012 20:41:29 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id E881B20058; Fri, 19 Oct 2012 20:41:28 +0300 (EEST)
Date: Fri, 19 Oct 2012 20:41:28 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= 
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= 
Message-ID: <20121019174128.GQ8912@reaktio.net>
References: <5171750d133ef2c27ac8.1350055853@xdev.gridcentric.ca>
	<1350547689.28188.31.camel@dagon.hellion.org.uk>
	
	<50811145.3030705@citrix.com>
	<94CA9621-D7BF-45CB-A6A2-7F68E14D3C23@gmail.com>
	<508176A5.10401@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <508176A5.10401@citrix.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Christoph Egger ,
	Ian Campbell ,
	Andres Lagar-Cavilla ,
	Ian Jackson ,
	"xen-devel@lists.xen.org" ,
	Andres Lagar-Cavilla ,
	Attilio Rao ,
	Andres Lagar-Cavilla 
Subject: Re: [Xen-devel] [PATCH] Synchronize privcmd header constants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 19, 2012 at 05:49:57PM +0200, Roger Pau Monn=E9 wrote:
> On 19/10/12 17:46, Andres Lagar-Cavilla wrote:
> > =

> > On Oct 19, 2012, at 4:37 AM, Roger Pau Monn=E9  w=
rote:
> > =

> >> On 19/10/12 04:20, Andres Lagar-Cavilla wrote:
> >>> I've had a look. The xen.org tree knows about three other OSes: minio=
s, solaris and netbsd. None knows about paged out frames. None uses the XEN=
_DOMCTL_PFINFO_PAGEDTAB constant in domctl.h
> >>>
> >>> 1. The domctl.h constant can still go away without hurting other OSes.
> >>
> >> I've checked and NetBSD doesn't use XEN_DOMCTL_PFINFO_PAGEDTAB, so as
> >> Andres says I guess it's safe to remove it.
> >>
> >>> 2. It is trivial to add the PRIVCMD_MMAPBATCH_* constants to the priv=
cmd.h of other OSes. It can't hurt. I can do it here. Each OS Xen maintaine=
r would have to take care of syncing that up in the respective upstream. Ho=
wever ...
> >>> 3. Not that trivial to teach all these OSes about paged out frames. D=
oes anyone care?
> >>
> >> Well, I'm sure the NetBSD community would be interested in this, but
> >> finding someone to actually work on it is a whole different story?
> > =

> > Thanks Roger. Ian should I expect a response from Solaris?
> =

> Solaris (Illumos) is currently pretty broken, and has gone the KVM side
> as far as I know, so I wouldn't expect any response.
> =


Around one month ago there was an Illumos developer posting to xen-devel,
he was working on porting the OpenSolaris XVM (Xen hypervisor) patches to x=
en-unstable.

Also he said the current Illumos kernel still works as dom0, for him at lea=
st.

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 17:41:54 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 17:41:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPGZk-0004g6-OM; Fri, 19 Oct 2012 17:41:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPGZj-0004g1-Bw
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 17:41:35 +0000
Received: from [85.158.138.51:7398] by server-9.bemta-3.messagelabs.com id
	1F/FE-16841-EC091805; Fri, 19 Oct 2012 17:41:34 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-13.tower-174.messagelabs.com!1350668492!16361727!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MjAzNjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29835 invoked from network); 19 Oct 2012 17:41:32 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Oct 2012 17:41:32 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 5C01E2F58;
	Fri, 19 Oct 2012 20:41:29 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id E881B20058; Fri, 19 Oct 2012 20:41:28 +0300 (EEST)
Date: Fri, 19 Oct 2012 20:41:28 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= 
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= 
Message-ID: <20121019174128.GQ8912@reaktio.net>
References: <5171750d133ef2c27ac8.1350055853@xdev.gridcentric.ca>
	<1350547689.28188.31.camel@dagon.hellion.org.uk>
	
	<50811145.3030705@citrix.com>
	<94CA9621-D7BF-45CB-A6A2-7F68E14D3C23@gmail.com>
	<508176A5.10401@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <508176A5.10401@citrix.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Christoph Egger ,
	Ian Campbell ,
	Andres Lagar-Cavilla ,
	Ian Jackson ,
	"xen-devel@lists.xen.org" ,
	Andres Lagar-Cavilla ,
	Attilio Rao ,
	Andres Lagar-Cavilla 
Subject: Re: [Xen-devel] [PATCH] Synchronize privcmd header constants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 19, 2012 at 05:49:57PM +0200, Roger Pau Monn=E9 wrote:
> On 19/10/12 17:46, Andres Lagar-Cavilla wrote:
> > =

> > On Oct 19, 2012, at 4:37 AM, Roger Pau Monn=E9  w=
rote:
> > =

> >> On 19/10/12 04:20, Andres Lagar-Cavilla wrote:
> >>> I've had a look. The xen.org tree knows about three other OSes: minio=
s, solaris and netbsd. None knows about paged out frames. None uses the XEN=
_DOMCTL_PFINFO_PAGEDTAB constant in domctl.h
> >>>
> >>> 1. The domctl.h constant can still go away without hurting other OSes.
> >>
> >> I've checked and NetBSD doesn't use XEN_DOMCTL_PFINFO_PAGEDTAB, so as
> >> Andres says I guess it's safe to remove it.
> >>
> >>> 2. It is trivial to add the PRIVCMD_MMAPBATCH_* constants to the priv=
cmd.h of other OSes. It can't hurt. I can do it here. Each OS Xen maintaine=
r would have to take care of syncing that up in the respective upstream. Ho=
wever ...
> >>> 3. Not that trivial to teach all these OSes about paged out frames. D=
oes anyone care?
> >>
> >> Well, I'm sure the NetBSD community would be interested in this, but
> >> finding someone to actually work on it is a whole different story?
> > =

> > Thanks Roger. Ian should I expect a response from Solaris?
> =

> Solaris (Illumos) is currently pretty broken, and has gone the KVM side
> as far as I know, so I wouldn't expect any response.
> =


Around one month ago there was an Illumos developer posting to xen-devel,
he was working on porting the OpenSolaris XVM (Xen hypervisor) patches to x=
en-unstable.

Also he said the current Illumos kernel still works as dom0, for him at lea=
st.

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 17:45:38 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 17:45:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPGdL-0004oE-Dl; Fri, 19 Oct 2012 17:45:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPGdK-0004o7-7Y
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 17:45:18 +0000
Received: from [85.158.138.51:18461] by server-5.bemta-3.messagelabs.com id
	31/2D-12440-DA191805; Fri, 19 Oct 2012 17:45:17 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1350668715!33365179!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODE1Njg1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11946 invoked from network); 19 Oct 2012 17:45:16 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Oct 2012 17:45:16 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9JHjCmO021705
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Oct 2012 17:45:13 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9JHjCLG029710
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 19 Oct 2012 17:45:12 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9JHjBPl028685; Fri, 19 Oct 2012 12:45:11 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Oct 2012 10:45:11 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 7598F4035B; Fri, 19 Oct 2012 13:33:07 -0400 (EDT)
Date: Fri, 19 Oct 2012 13:33:07 -0400
From: Konrad Rzeszutek Wilk 
To: Jan Beulich , Daniel Kiper 
Message-ID: <20121019173307.GT26830@phenom.dumpdata.com>
References: 
	<507C075302000078000A1593@nat28.tlf.novell.com>
	
	
	<5081271C02000078000A2844@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5081271C02000078000A2844@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Allan Scheid , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2 with EFI on IBM x3650 ACPI Bug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 19, 2012 at 09:10:36AM +0100, Jan Beulich wrote:
> >>> On 19.10.12 at 01:43, Allan Scheid  wrote:
> > Bad news, i am seeing the log output and after the xen.efi boot this still
> > appears on log:
> > 
> > Into messages:
> > Oct 18 20:27:36 lca-fw kernel: [    0.000000] ACPI BIOS Bug: Error: A valid
> > RSDP was not found (20120711/tbxfroot-219)
> > Oct 18 20:27:36 lca-fw kernel: [    0.000000] NUMA turned off
> > Oct 18 20:27:36 lca-fw kernel: [    3.759750] pci 0000:00:01.0: can't find
> > IRQ for PCI INT A; please try using pci=biosirq
> > Oct 18 20:27:36 lca-fw kernel: [    3.764011] pci 0000:00:1a.0: can't find
> > IRQ for PCI INT A; please try using pci=biosirq
> 
> Of course - you also need the kernel to be capable of obtaining
> the necessary EFI information from Xen. That's a separate patch
> (an early port of the one we have to the pvops kernel was
> posted on the list a few months ago, but I don't know what its
> status or disposition is - Konrad?).

Daniel is taking a stab at it. He got the hardware. But this is good
to know that there is hardware that removes the RSDT from the low memory
and only allows to get it from the EFI. 
> 
> > This still causes don't work USB ports and some PCI cards on the system.
> > 
> > xl dmesg log:
> > 
> > (XEN) Using APIC driver default
> 
> The below shows that Xen is working fine now.
> 
> Jan
> 
> > (XEN) ACPI: PM-Timer IO Port: 0x588
> > (XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[584,0], pm1x_evt[580,0]
> > (XEN) ACPI:                  wakeup_vec[7f6eb00c], vec_size[20]
> > (XEN) ACPI: Local APIC address 0xfee00000
> > (XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
> > (XEN) Processor #0 6:12 APIC version 21
> > (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled)
> > (XEN) Processor #2 6:12 APIC version 21
> > (XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled)
> > (XEN) Processor #4 6:12 APIC version 21
> > (XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x10] enabled)
> > (XEN) Processor #16 6:12 APIC version 21
> > (XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x12] enabled)
> > (XEN) Processor #18 6:12 APIC version 21
> > (XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x14] enabled)
> > (XEN) Processor #20 6:12 APIC version 21
> > (XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x20] disabled)
> > (XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x22] disabled)
> > (XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x24] disabled)
> > (XEN) ACPI: LAPIC (acpi_id[0x09] lapic_id[0x30] disabled)
> > (XEN) ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x32] disabled)
> > (XEN) ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x34] disabled)
> > (XEN) ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x01] enabled)
> > (XEN) Processor #1 6:12 APIC version 21
> > (XEN) ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x03] enabled)
> > (XEN) Processor #3 6:12 APIC version 21
> > (XEN) ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x05] enabled)
> > (XEN) Processor #5 6:12 APIC version 21
> > (XEN) ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x11] enabled)
> > (XEN) Processor #17 6:12 APIC version 21
> > (XEN) ACPI: LAPIC (acpi_id[0x10] lapic_id[0x13] enabled)
> > (XEN) Processor #19 6:12 APIC version 21
> > (XEN) ACPI: LAPIC (acpi_id[0x11] lapic_id[0x15] enabled)
> > (XEN) Processor #21 6:12 APIC version 21
> > (XEN) ACPI: LAPIC (acpi_id[0x12] lapic_id[0x21] disabled)
> > (XEN) ACPI: LAPIC (acpi_id[0x13] lapic_id[0x23] disabled)
> > (XEN) ACPI: LAPIC (acpi_id[0x14] lapic_id[0x25] disabled)
> > (XEN) ACPI: LAPIC (acpi_id[0x15] lapic_id[0x31] disabled)
> > (XEN) ACPI: LAPIC (acpi_id[0x16] lapic_id[0x33] disabled)
> > (XEN) ACPI: LAPIC (acpi_id[0x17] lapic_id[0x35] disabled)
> > (XEN) ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1])
> > 
> > (XEN) Overriding APIC driver with bigsmp
> > (XEN) ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
> > (XEN) IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
> > (XEN) ACPI: IOAPIC (id[0x09] address[0xfec80000] gsi_base[24])
> > (XEN) IOAPIC[1]: apic_id 9, version 32, address 0xfec80000, GSI 24-47
> > (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
> > (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
> > (XEN) ACPI: IRQ0 used by override.
> > (XEN) ACPI: IRQ2 used by override.
> > (XEN) ACPI: IRQ9 used by override.
> > (XEN) Enabling APIC mode:  Phys.  Using 2 I/O APICs
> > (XEN) ACPI: HPET id: 0x8086a301 base: 0xfed00000
> > (XEN) ERST table is invalid
> > (XEN) Using ACPI (MADT) for SMP configuration information

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 17:45:38 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 17:45:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPGdL-0004oE-Dl; Fri, 19 Oct 2012 17:45:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPGdK-0004o7-7Y
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 17:45:18 +0000
Received: from [85.158.138.51:18461] by server-5.bemta-3.messagelabs.com id
	31/2D-12440-DA191805; Fri, 19 Oct 2012 17:45:17 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1350668715!33365179!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODE1Njg1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11946 invoked from network); 19 Oct 2012 17:45:16 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Oct 2012 17:45:16 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9JHjCmO021705
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Oct 2012 17:45:13 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9JHjCLG029710
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 19 Oct 2012 17:45:12 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9JHjBPl028685; Fri, 19 Oct 2012 12:45:11 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Oct 2012 10:45:11 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 7598F4035B; Fri, 19 Oct 2012 13:33:07 -0400 (EDT)
Date: Fri, 19 Oct 2012 13:33:07 -0400
From: Konrad Rzeszutek Wilk 
To: Jan Beulich , Daniel Kiper 
Message-ID: <20121019173307.GT26830@phenom.dumpdata.com>
References: 
	<507C075302000078000A1593@nat28.tlf.novell.com>
	
	
	<5081271C02000078000A2844@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5081271C02000078000A2844@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Allan Scheid , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2 with EFI on IBM x3650 ACPI Bug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 19, 2012 at 09:10:36AM +0100, Jan Beulich wrote:
> >>> On 19.10.12 at 01:43, Allan Scheid  wrote:
> > Bad news, i am seeing the log output and after the xen.efi boot this still
> > appears on log:
> > 
> > Into messages:
> > Oct 18 20:27:36 lca-fw kernel: [    0.000000] ACPI BIOS Bug: Error: A valid
> > RSDP was not found (20120711/tbxfroot-219)
> > Oct 18 20:27:36 lca-fw kernel: [    0.000000] NUMA turned off
> > Oct 18 20:27:36 lca-fw kernel: [    3.759750] pci 0000:00:01.0: can't find
> > IRQ for PCI INT A; please try using pci=biosirq
> > Oct 18 20:27:36 lca-fw kernel: [    3.764011] pci 0000:00:1a.0: can't find
> > IRQ for PCI INT A; please try using pci=biosirq
> 
> Of course - you also need the kernel to be capable of obtaining
> the necessary EFI information from Xen. That's a separate patch
> (an early port of the one we have to the pvops kernel was
> posted on the list a few months ago, but I don't know what its
> status or disposition is - Konrad?).

Daniel is taking a stab at it. He got the hardware. But this is good
to know that there is hardware that removes the RSDT from the low memory
and only allows to get it from the EFI. 
> 
> > This still causes don't work USB ports and some PCI cards on the system.
> > 
> > xl dmesg log:
> > 
> > (XEN) Using APIC driver default
> 
> The below shows that Xen is working fine now.
> 
> Jan
> 
> > (XEN) ACPI: PM-Timer IO Port: 0x588
> > (XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[584,0], pm1x_evt[580,0]
> > (XEN) ACPI:                  wakeup_vec[7f6eb00c], vec_size[20]
> > (XEN) ACPI: Local APIC address 0xfee00000
> > (XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
> > (XEN) Processor #0 6:12 APIC version 21
> > (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled)
> > (XEN) Processor #2 6:12 APIC version 21
> > (XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled)
> > (XEN) Processor #4 6:12 APIC version 21
> > (XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x10] enabled)
> > (XEN) Processor #16 6:12 APIC version 21
> > (XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x12] enabled)
> > (XEN) Processor #18 6:12 APIC version 21
> > (XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x14] enabled)
> > (XEN) Processor #20 6:12 APIC version 21
> > (XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x20] disabled)
> > (XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x22] disabled)
> > (XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x24] disabled)
> > (XEN) ACPI: LAPIC (acpi_id[0x09] lapic_id[0x30] disabled)
> > (XEN) ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x32] disabled)
> > (XEN) ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x34] disabled)
> > (XEN) ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x01] enabled)
> > (XEN) Processor #1 6:12 APIC version 21
> > (XEN) ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x03] enabled)
> > (XEN) Processor #3 6:12 APIC version 21
> > (XEN) ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x05] enabled)
> > (XEN) Processor #5 6:12 APIC version 21
> > (XEN) ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x11] enabled)
> > (XEN) Processor #17 6:12 APIC version 21
> > (XEN) ACPI: LAPIC (acpi_id[0x10] lapic_id[0x13] enabled)
> > (XEN) Processor #19 6:12 APIC version 21
> > (XEN) ACPI: LAPIC (acpi_id[0x11] lapic_id[0x15] enabled)
> > (XEN) Processor #21 6:12 APIC version 21
> > (XEN) ACPI: LAPIC (acpi_id[0x12] lapic_id[0x21] disabled)
> > (XEN) ACPI: LAPIC (acpi_id[0x13] lapic_id[0x23] disabled)
> > (XEN) ACPI: LAPIC (acpi_id[0x14] lapic_id[0x25] disabled)
> > (XEN) ACPI: LAPIC (acpi_id[0x15] lapic_id[0x31] disabled)
> > (XEN) ACPI: LAPIC (acpi_id[0x16] lapic_id[0x33] disabled)
> > (XEN) ACPI: LAPIC (acpi_id[0x17] lapic_id[0x35] disabled)
> > (XEN) ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1])
> > 
> > (XEN) Overriding APIC driver with bigsmp
> > (XEN) ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
> > (XEN) IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
> > (XEN) ACPI: IOAPIC (id[0x09] address[0xfec80000] gsi_base[24])
> > (XEN) IOAPIC[1]: apic_id 9, version 32, address 0xfec80000, GSI 24-47
> > (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
> > (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
> > (XEN) ACPI: IRQ0 used by override.
> > (XEN) ACPI: IRQ2 used by override.
> > (XEN) ACPI: IRQ9 used by override.
> > (XEN) Enabling APIC mode:  Phys.  Using 2 I/O APICs
> > (XEN) ACPI: HPET id: 0x8086a301 base: 0xfed00000
> > (XEN) ERST table is invalid
> > (XEN) Using ACPI (MADT) for SMP configuration information

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 17:46:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 17:46:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPGdn-0004qW-R3; Fri, 19 Oct 2012 17:45:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPGdm-0004qM-VN
	for xen-devel@lists.xensource.com; Fri, 19 Oct 2012 17:45:47 +0000
Received: from [85.158.138.51:19528] by server-13.bemta-3.messagelabs.com id
	70/4E-26794-AC191805; Fri, 19 Oct 2012 17:45:46 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1350668743!28718975!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6045 invoked from network); 19 Oct 2012 17:45:45 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Oct 2012 17:45:45 -0000
Received: from anacreon.sc.intel.com (fmdmzpr03-ext.fm.intel.com
	[192.55.54.38]) (authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id q9JHjd3p007689
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO);
	Fri, 19 Oct 2012 10:45:40 -0700
Message-ID: <508191BD.4000107@zytor.com>
Date: Fri, 19 Oct 2012 10:45:33 -0700
From: "H. Peter Anvin" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120605 Thunderbird/13.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk 
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	<507ED6C0.4020503@zytor.com>
	<20121017161036.GA10691@phenom.dumpdata.com>
	<507EE1C3.7070300@zytor.com>
	<20121017165452.GA22740@phenom.dumpdata.com>
	<507EEC53.1010309@zytor.com>
	<84b3cbf9-7c84-4d7e-a2d7-46b0d1cc5975@default>
	<50802030.8070107@zytor.com>
	
	<50803057.5000307@zytor.com>
	<20121019154854.GO26830@phenom.dumpdata.com>
In-Reply-To: <20121019154854.GO26830@phenom.dumpdata.com>
X-Enigmail-Version: 1.4.3
Cc: Dan Magenheimer , xen-devel@lists.xensource.com,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] Is: Xen architecture document. Was: Re: Is: axe
 read_tscp pvops call. Was: Re: [RFC] ACPI S3 and Xen (suprisingly small\!).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/19/2012 08:48 AM, Konrad Rzeszutek Wilk wrote:
>> paravirtualized architectures out there which are perfectly well
>> documented and supportable, but Xen has resisted doing that for
>> years, and all we ever get are vague future promises.
> 
> There is no resistance - and it is being done. Every month we document
> various APIs, man-pages, etc so that knowledge won't be lost. The
> end-result of that is to create a PDF similar to the PowerPC architecture
> document.
> 
> I have not been pointing you to it, b/c as of right what we have is
> raw data (various header files growing in size) that keep on growing.
> I need to hire/cajole an editor to help us get from the "raw" brain
> dump to a book and some sense of milestones/schedule or whatever one
> does in the book-world.
> 
> And Peter, just in case it is not clear, every suggestion you make is
> appreciated and taken seriously. If there are things that have been
> dropped or forgotten by me - please remind me.
> 

Right... so for those who don't know, this is something I have discussed
with Konrad over the course of the last several years.  It is good to
know progress is happening.  It is late, of course -- this should have
happened before Xen was integrated -- but we can't change the past.

	-hpa

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 17:46:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 17:46:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPGdn-0004qW-R3; Fri, 19 Oct 2012 17:45:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPGdm-0004qM-VN
	for xen-devel@lists.xensource.com; Fri, 19 Oct 2012 17:45:47 +0000
Received: from [85.158.138.51:19528] by server-13.bemta-3.messagelabs.com id
	70/4E-26794-AC191805; Fri, 19 Oct 2012 17:45:46 +0000
X-Env-Sender: hpa@zytor.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1350668743!28718975!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6045 invoked from network); 19 Oct 2012 17:45:45 -0000
Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Oct 2012 17:45:45 -0000
Received: from anacreon.sc.intel.com (fmdmzpr03-ext.fm.intel.com
	[192.55.54.38]) (authenticated bits=0)
	by mail.zytor.com (8.14.5/8.14.5) with ESMTP id q9JHjd3p007689
	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO);
	Fri, 19 Oct 2012 10:45:40 -0700
Message-ID: <508191BD.4000107@zytor.com>
Date: Fri, 19 Oct 2012 10:45:33 -0700
From: "H. Peter Anvin" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120605 Thunderbird/13.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk 
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	<507ED6C0.4020503@zytor.com>
	<20121017161036.GA10691@phenom.dumpdata.com>
	<507EE1C3.7070300@zytor.com>
	<20121017165452.GA22740@phenom.dumpdata.com>
	<507EEC53.1010309@zytor.com>
	<84b3cbf9-7c84-4d7e-a2d7-46b0d1cc5975@default>
	<50802030.8070107@zytor.com>
	
	<50803057.5000307@zytor.com>
	<20121019154854.GO26830@phenom.dumpdata.com>
In-Reply-To: <20121019154854.GO26830@phenom.dumpdata.com>
X-Enigmail-Version: 1.4.3
Cc: Dan Magenheimer , xen-devel@lists.xensource.com,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] Is: Xen architecture document. Was: Re: Is: axe
 read_tscp pvops call. Was: Re: [RFC] ACPI S3 and Xen (suprisingly small\!).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/19/2012 08:48 AM, Konrad Rzeszutek Wilk wrote:
>> paravirtualized architectures out there which are perfectly well
>> documented and supportable, but Xen has resisted doing that for
>> years, and all we ever get are vague future promises.
> 
> There is no resistance - and it is being done. Every month we document
> various APIs, man-pages, etc so that knowledge won't be lost. The
> end-result of that is to create a PDF similar to the PowerPC architecture
> document.
> 
> I have not been pointing you to it, b/c as of right what we have is
> raw data (various header files growing in size) that keep on growing.
> I need to hire/cajole an editor to help us get from the "raw" brain
> dump to a book and some sense of milestones/schedule or whatever one
> does in the book-world.
> 
> And Peter, just in case it is not clear, every suggestion you make is
> appreciated and taken seriously. If there are things that have been
> dropped or forgotten by me - please remind me.
> 

Right... so for those who don't know, this is something I have discussed
with Konrad over the course of the last several years.  It is good to
know progress is happening.  It is late, of course -- this should have
happened before Xen was integrated -- but we can't change the past.

	-hpa

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 18:03:03 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 18:03:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPGuD-0005Em-LU; Fri, 19 Oct 2012 18:02:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPGuC-0005Eh-6L
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 18:02:44 +0000
Received: from [85.158.139.211:27281] by server-16.bemta-5.messagelabs.com id
	56/64-09196-3C591805; Fri, 19 Oct 2012 18:02:43 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1350669762!23020406!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUwMDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15367 invoked from network); 19 Oct 2012 18:02:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 18:02:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,613,1344211200"; 
	d="asc'?scan'208";a="15283399"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 18:02:42 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 19 Oct 2012 19:02:42 +0100
Message-ID: <1350669760.6053.97.camel@Solace>
From: Dario Faggioli 
To: Ian Jackson 
Date: Fri, 19 Oct 2012 20:02:40 +0200
In-Reply-To: <20609.27239.778582.985508@mariner.uk.xensource.com>
References: 
	
	
	<1350602433.26152.106.camel@Solace>
	<20609.27239.778582.985508@mariner.uk.xensource.com>
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Andre Przywara ,
	Ian Campbell ,
	Stefano Stabellini ,
	George Dunlap ,
	Juergen Gross ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 1 of 3] libxl: take node distances into
 account during NUMA placement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1251683894785785529=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1251683894785785529==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-7JHPGosVOqT5WXceiQG+"

--=-7JHPGosVOqT5WXceiQG+
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-10-19 at 15:57 +0100, Ian Jackson wrote:
> Dario Faggioli writes ("Re: [Xen-devel] [PATCH 1 of 3] libxl: take node d=
istances into account during NUMA placement"):
> > On Thu, 2012-10-18 at 16:17 +0100, George Dunlap wrote:
> > > And now we're doing N^2 for each
> > > candidate?=20
> >=20
> > Again, yes, but that is turning it from Ndoms*Nvcpus to
> > Ndoms*Nvcpus+Nnodes^2, which is still dominated by the first term. IIRC=
,
> > Andre tried to start >50 domains with 2 vCPUs on a 8 nodes system, whic=
h
> > means 50*2 vs 8*8.
>=20
> Are you sure about this calculation ? =20
>
I am. In fact, I think they answer George's question which was "by how
much we are increasing the complexity of each step?" and not "by how
much we are increasing the overall complexity?".

That of course doesn't mean I don't care about the overall complexity,
just that I don't think this is making things worse than what we have
(which is, btw, the result of the long discussion we had pre 4.2
release).

> It seems to me that=20
> doing Nnodes^2 for each candidate multiplies the cost by the number of
> candidates, rather than adding Nnodes^2.
>=20
That is definitely true. Again the key is the difference between talking
about "each candidate", as we were, and total.

> There are in the worst case nearly 2^Nnodes candidates (combinations
> of nodes).  So the cost is
>   <=3D 2^Nnodes * Nnodes^2
>=20
> Your algorithm runs with up to 16 nodes.  Your change here increases
> the worst-case cost from
>   2^16 =3D 65556
> to
>   2^16 * 16^2 =3D 16777216
>=20
Ok, I'm fine with the "let's throw numbers" game, so let me throw
mine[*] ones before proposing a couple of possible strategies. :-D

So, the current exact calculation for the number of candidates that are
generated (in the worst case, i.e., when the only suitable candidate for
the domain being created is the very last one evaluated):

combs=3D0;
N=3D16;
for k=3D1:N
  combs=3Dcombs+bincoeff(N,k);
endfor;
combs
combs =3D  65535

Now, the change about distances adds to each step something that can be
upper bounded by this:

steps=3D0;
N=3D16;
for i=3D0:N
  for j=3D1:N-i
    steps++;
  endfor;
endfor;
steps
steps =3D  136

Hence:

combs*steps
ans =3D  8912760

But this is of course not tight, and a more accurate calculation of the
worst case overall required number of "steps" you're interested in
should look more like this:

combs=3D0;
N=3D16;
for k=3D1:N
  steps=3D0;
  for i=3D0:k
    for j=3D1:k-i
      steps++;
    endfor;
  endfor;
  combs=3Dcombs+bincoeff(n,k)*steps;
endfor;
combs
combs =3D  2490368

So not exactly 16777216, although, don't get me wrong, I agree it is
huge.

So, now that the math has been taken care of, here it comes the time for
the proposals I was talking about before.

1. For this specific issue, I can try to change the way I use the=20
  distances matrix and the way I define and calculate a measure of how
  distant the nodes in a candidate are from each others, trying to make
  it at least linear in computation time. It's not immediate, mainly
  because it's a matrix after all, but maybe I can save some
  intermediate results during the process and amortize the complexity
  (I've ideas, but nothing precise enough to share yet). Does that make
  sense to you?

2. Independently from this specific issue, I think we need something to
  determine where a reasonable limit lie, and whether what we have and
  the changes we will make result or not in a decent domain creation =20
  time.
  That's something very hard to do, but I was thinking about writing
  some sort of 'simulator', i.e., a standalone program that calls the
  placement function and intercept the libxl_ calls it does, to create
  and let it run in an artificial scenario of choice.
  Something like that has already been suggested during one of the last
  rounds of review (although for different purposes), and I thought it
  was a real good idea... Now I think is something we definitely
  need. :-)
  I know it's not going to reach usec-level precision (hypercall being
  simulated by function calls, and stuff like that), but I think it
  could be useful... You?

Thanks again for looking into this and Regards,
Dario

[*] copying and pasting the lines in octave should work.

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-7JHPGosVOqT5WXceiQG+
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlCBlcAACgkQk4XaBE3IOsRJPwCfY6oJ5oAJHIBBDU9zMmLc1DsU
F+oAnjquxtp/9pSUKTG981oiJefDct0W
=SqRi
-----END PGP SIGNATURE-----

--=-7JHPGosVOqT5WXceiQG+--


--===============1251683894785785529==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1251683894785785529==--


From xen-devel-bounces@lists.xen.org Fri Oct 19 18:03:03 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 18:03:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPGuD-0005Em-LU; Fri, 19 Oct 2012 18:02:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPGuC-0005Eh-6L
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 18:02:44 +0000
Received: from [85.158.139.211:27281] by server-16.bemta-5.messagelabs.com id
	56/64-09196-3C591805; Fri, 19 Oct 2012 18:02:43 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1350669762!23020406!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUwMDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15367 invoked from network); 19 Oct 2012 18:02:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 18:02:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,613,1344211200"; 
	d="asc'?scan'208";a="15283399"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 18:02:42 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 19 Oct 2012 19:02:42 +0100
Message-ID: <1350669760.6053.97.camel@Solace>
From: Dario Faggioli 
To: Ian Jackson 
Date: Fri, 19 Oct 2012 20:02:40 +0200
In-Reply-To: <20609.27239.778582.985508@mariner.uk.xensource.com>
References: 
	
	
	<1350602433.26152.106.camel@Solace>
	<20609.27239.778582.985508@mariner.uk.xensource.com>
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Andre Przywara ,
	Ian Campbell ,
	Stefano Stabellini ,
	George Dunlap ,
	Juergen Gross ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 1 of 3] libxl: take node distances into
 account during NUMA placement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1251683894785785529=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1251683894785785529==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-7JHPGosVOqT5WXceiQG+"

--=-7JHPGosVOqT5WXceiQG+
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-10-19 at 15:57 +0100, Ian Jackson wrote:
> Dario Faggioli writes ("Re: [Xen-devel] [PATCH 1 of 3] libxl: take node d=
istances into account during NUMA placement"):
> > On Thu, 2012-10-18 at 16:17 +0100, George Dunlap wrote:
> > > And now we're doing N^2 for each
> > > candidate?=20
> >=20
> > Again, yes, but that is turning it from Ndoms*Nvcpus to
> > Ndoms*Nvcpus+Nnodes^2, which is still dominated by the first term. IIRC=
,
> > Andre tried to start >50 domains with 2 vCPUs on a 8 nodes system, whic=
h
> > means 50*2 vs 8*8.
>=20
> Are you sure about this calculation ? =20
>
I am. In fact, I think they answer George's question which was "by how
much we are increasing the complexity of each step?" and not "by how
much we are increasing the overall complexity?".

That of course doesn't mean I don't care about the overall complexity,
just that I don't think this is making things worse than what we have
(which is, btw, the result of the long discussion we had pre 4.2
release).

> It seems to me that=20
> doing Nnodes^2 for each candidate multiplies the cost by the number of
> candidates, rather than adding Nnodes^2.
>=20
That is definitely true. Again the key is the difference between talking
about "each candidate", as we were, and total.

> There are in the worst case nearly 2^Nnodes candidates (combinations
> of nodes).  So the cost is
>   <=3D 2^Nnodes * Nnodes^2
>=20
> Your algorithm runs with up to 16 nodes.  Your change here increases
> the worst-case cost from
>   2^16 =3D 65556
> to
>   2^16 * 16^2 =3D 16777216
>=20
Ok, I'm fine with the "let's throw numbers" game, so let me throw
mine[*] ones before proposing a couple of possible strategies. :-D

So, the current exact calculation for the number of candidates that are
generated (in the worst case, i.e., when the only suitable candidate for
the domain being created is the very last one evaluated):

combs=3D0;
N=3D16;
for k=3D1:N
  combs=3Dcombs+bincoeff(N,k);
endfor;
combs
combs =3D  65535

Now, the change about distances adds to each step something that can be
upper bounded by this:

steps=3D0;
N=3D16;
for i=3D0:N
  for j=3D1:N-i
    steps++;
  endfor;
endfor;
steps
steps =3D  136

Hence:

combs*steps
ans =3D  8912760

But this is of course not tight, and a more accurate calculation of the
worst case overall required number of "steps" you're interested in
should look more like this:

combs=3D0;
N=3D16;
for k=3D1:N
  steps=3D0;
  for i=3D0:k
    for j=3D1:k-i
      steps++;
    endfor;
  endfor;
  combs=3Dcombs+bincoeff(n,k)*steps;
endfor;
combs
combs =3D  2490368

So not exactly 16777216, although, don't get me wrong, I agree it is
huge.

So, now that the math has been taken care of, here it comes the time for
the proposals I was talking about before.

1. For this specific issue, I can try to change the way I use the=20
  distances matrix and the way I define and calculate a measure of how
  distant the nodes in a candidate are from each others, trying to make
  it at least linear in computation time. It's not immediate, mainly
  because it's a matrix after all, but maybe I can save some
  intermediate results during the process and amortize the complexity
  (I've ideas, but nothing precise enough to share yet). Does that make
  sense to you?

2. Independently from this specific issue, I think we need something to
  determine where a reasonable limit lie, and whether what we have and
  the changes we will make result or not in a decent domain creation =20
  time.
  That's something very hard to do, but I was thinking about writing
  some sort of 'simulator', i.e., a standalone program that calls the
  placement function and intercept the libxl_ calls it does, to create
  and let it run in an artificial scenario of choice.
  Something like that has already been suggested during one of the last
  rounds of review (although for different purposes), and I thought it
  was a real good idea... Now I think is something we definitely
  need. :-)
  I know it's not going to reach usec-level precision (hypercall being
  simulated by function calls, and stuff like that), but I think it
  could be useful... You?

Thanks again for looking into this and Regards,
Dario

[*] copying and pasting the lines in octave should work.

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-7JHPGosVOqT5WXceiQG+
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlCBlcAACgkQk4XaBE3IOsRJPwCfY6oJ5oAJHIBBDU9zMmLc1DsU
F+oAnjquxtp/9pSUKTG981oiJefDct0W
=SqRi
-----END PGP SIGNATURE-----

--=-7JHPGosVOqT5WXceiQG+--


--===============1251683894785785529==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1251683894785785529==--


From xen-devel-bounces@lists.xen.org Fri Oct 19 18:28:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 18:28:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPHIJ-0005U1-7b; Fri, 19 Oct 2012 18:27:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPHII-0005Tw-5C
	for xen-devel@lists.xensource.com; Fri, 19 Oct 2012 18:27:38 +0000
Received: from [85.158.139.83:50261] by server-14.bemta-5.messagelabs.com id
	2F/34-24068-99B91805; Fri, 19 Oct 2012 18:27:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1350671255!32815569!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUwMDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 928 invoked from network); 19 Oct 2012 18:27:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 18:27:36 -0000
X-IronPort-AV: E=Sophos;i="4.80,613,1344211200"; d="scan'208";a="15284060"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 18:27:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 19 Oct 2012 19:27:35 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TPHIE-0001sP-Sf;
	Fri, 19 Oct 2012 18:27:34 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TPHIB-0002Ek-Me;
	Fri, 19 Oct 2012 19:27:32 +0100
To: 
Message-ID: 
From: xen.org 
Date: Fri, 19 Oct 2012 19:27:31 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14063: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14063 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14063/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 13967
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 13967
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 13967
 build-amd64-oldkern           4 xen-build        fail in 14038 REGR. vs. 13967

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                    fail pass in 14038
 test-amd64-i386-xl            5 xen-boot                    fail pass in 14045
 test-amd64-i386-pv            5 xen-boot                    fail pass in 14057
 test-amd64-amd64-pair         8 xen-boot/dst_host           fail pass in 14045
 test-amd64-amd64-pair         7 xen-boot/src_host           fail pass in 14045
 test-amd64-i386-xl-credit2    5 xen-boot                    fail pass in 14062

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13967
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13967
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13967
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13967

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  3fa2ab30bb05
baseline version:
 xen                  c1c549c4fe9e

------------------------------------------------------------
People who touched revisions under test:
  Chuang Cao 
  Daniel De Graaf 
  Huang Ying 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Joe Jin 
  Keir Fraser 
  Olaf Hering 
  Sander Eikelenboom 
  Stefano Stabellini 
  Tim Deegan 
  Xiantao Zhang
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 592 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 18:28:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 18:28:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPHIJ-0005U1-7b; Fri, 19 Oct 2012 18:27:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPHII-0005Tw-5C
	for xen-devel@lists.xensource.com; Fri, 19 Oct 2012 18:27:38 +0000
Received: from [85.158.139.83:50261] by server-14.bemta-5.messagelabs.com id
	2F/34-24068-99B91805; Fri, 19 Oct 2012 18:27:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1350671255!32815569!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUwMDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 928 invoked from network); 19 Oct 2012 18:27:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 18:27:36 -0000
X-IronPort-AV: E=Sophos;i="4.80,613,1344211200"; d="scan'208";a="15284060"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 18:27:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 19 Oct 2012 19:27:35 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TPHIE-0001sP-Sf;
	Fri, 19 Oct 2012 18:27:34 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TPHIB-0002Ek-Me;
	Fri, 19 Oct 2012 19:27:32 +0100
To: 
Message-ID: 
From: xen.org 
Date: Fri, 19 Oct 2012 19:27:31 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14063: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14063 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14063/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  5 xen-boot            fail REGR. vs. 13967
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 13967
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 13967
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 13967
 build-amd64-oldkern           4 xen-build        fail in 14038 REGR. vs. 13967

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                    fail pass in 14038
 test-amd64-i386-xl            5 xen-boot                    fail pass in 14045
 test-amd64-i386-pv            5 xen-boot                    fail pass in 14057
 test-amd64-amd64-pair         8 xen-boot/dst_host           fail pass in 14045
 test-amd64-amd64-pair         7 xen-boot/src_host           fail pass in 14045
 test-amd64-i386-xl-credit2    5 xen-boot                    fail pass in 14062

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13967
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13967
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13967
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13967

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  3fa2ab30bb05
baseline version:
 xen                  c1c549c4fe9e

------------------------------------------------------------
People who touched revisions under test:
  Chuang Cao 
  Daniel De Graaf 
  Huang Ying 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Joe Jin 
  Keir Fraser 
  Olaf Hering 
  Sander Eikelenboom 
  Stefano Stabellini 
  Tim Deegan 
  Xiantao Zhang
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 592 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 18:45:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 18:45:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPHZb-0005gA-42; Fri, 19 Oct 2012 18:45:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPHZZ-0005g5-9D
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 18:45:29 +0000
Received: from [85.158.143.35:51749] by server-2.bemta-4.messagelabs.com id
	C3/68-22268-8CF91805; Fri, 19 Oct 2012 18:45:28 +0000
X-Env-Sender: chien.yen@oracle.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1350672325!19526615!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODE1Njg1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6685 invoked from network); 19 Oct 2012 18:45:27 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Oct 2012 18:45:27 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9JIjOTv022757
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for ; Fri, 19 Oct 2012 18:45:25 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9JIjOfA013395
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Fri, 19 Oct 2012 18:45:24 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9JIjNIm016512
	for ; Fri, 19 Oct 2012 13:45:23 -0500
Received: from [130.35.68.126] (/130.35.68.126)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Oct 2012 11:45:23 -0700
Message-ID: <50819FC3.5050308@oracle.com>
Date: Fri, 19 Oct 2012 11:45:23 -0700
From: Chien-Hua Yen 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.7) Gecko/20120829 Thunderbird/10.0.7
MIME-Version: 1.0
To: xen-devel@lists.xen.org
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Subject: [Xen-devel] Why guest is disallowed to change mask bit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

I am curious to know why Xen disallows guest to change the mask bit of 
MSI-X
vector control as show in the comment out section in msixtbl_write().
Our SR-IOV driver got driver reload failure because it cannot enable 
interrupt.

      /* Do not allow the mask bit to be changed. */
#if 0 /* XXX
        * As the mask bit is the only defined bit in the word, and as the
        * host MSI-X code doesn't preserve the other bits anyway, doing
        * this is pointless. So for now just discard the write (also
        * saving us from having to determine the matching irq_desc).
        */
     spin_lock_irqsave(&desc->lock, flags);
     orig = readl(virt);
     val &= ~PCI_MSIX_VECTOR_BITMASK;
     val |= orig & PCI_MSIX_VECTOR_BITMASK;
     writel(val, virt);
     spin_unlock_irqrestore(&desc->lock, flags);
#endif

     r = X86EMUL_OKAY;

Thanks.

Chien

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 18:45:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 18:45:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPHZb-0005gA-42; Fri, 19 Oct 2012 18:45:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPHZZ-0005g5-9D
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 18:45:29 +0000
Received: from [85.158.143.35:51749] by server-2.bemta-4.messagelabs.com id
	C3/68-22268-8CF91805; Fri, 19 Oct 2012 18:45:28 +0000
X-Env-Sender: chien.yen@oracle.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1350672325!19526615!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODE1Njg1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6685 invoked from network); 19 Oct 2012 18:45:27 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Oct 2012 18:45:27 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9JIjOTv022757
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for ; Fri, 19 Oct 2012 18:45:25 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9JIjOfA013395
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Fri, 19 Oct 2012 18:45:24 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9JIjNIm016512
	for ; Fri, 19 Oct 2012 13:45:23 -0500
Received: from [130.35.68.126] (/130.35.68.126)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Oct 2012 11:45:23 -0700
Message-ID: <50819FC3.5050308@oracle.com>
Date: Fri, 19 Oct 2012 11:45:23 -0700
From: Chien-Hua Yen 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.7) Gecko/20120829 Thunderbird/10.0.7
MIME-Version: 1.0
To: xen-devel@lists.xen.org
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Subject: [Xen-devel] Why guest is disallowed to change mask bit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

I am curious to know why Xen disallows guest to change the mask bit of 
MSI-X
vector control as show in the comment out section in msixtbl_write().
Our SR-IOV driver got driver reload failure because it cannot enable 
interrupt.

      /* Do not allow the mask bit to be changed. */
#if 0 /* XXX
        * As the mask bit is the only defined bit in the word, and as the
        * host MSI-X code doesn't preserve the other bits anyway, doing
        * this is pointless. So for now just discard the write (also
        * saving us from having to determine the matching irq_desc).
        */
     spin_lock_irqsave(&desc->lock, flags);
     orig = readl(virt);
     val &= ~PCI_MSIX_VECTOR_BITMASK;
     val |= orig & PCI_MSIX_VECTOR_BITMASK;
     writel(val, virt);
     spin_unlock_irqrestore(&desc->lock, flags);
#endif

     r = X86EMUL_OKAY;

Thanks.

Chien

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 19:01:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 19:01:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPHox-0005sh-RF; Fri, 19 Oct 2012 19:01:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPHow-0005sc-H0
	for xen-devel@lists.xensource.com; Fri, 19 Oct 2012 19:01:22 +0000
Received: from [85.158.139.211:52388] by server-8.bemta-5.messagelabs.com id
	43/5D-23193-183A1805; Fri, 19 Oct 2012 19:01:21 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1350673279!22940471!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODE1Njg1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22980 invoked from network); 19 Oct 2012 19:01:20 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Oct 2012 19:01:20 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9JJ1Eg0006450
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Oct 2012 19:01:15 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9JJ1Dkr006508
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 19 Oct 2012 19:01:14 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9JJ1CNi002267; Fri, 19 Oct 2012 14:01:12 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Oct 2012 12:01:12 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 3B0C44035B; Fri, 19 Oct 2012 14:49:08 -0400 (EDT)
Date: Fri, 19 Oct 2012 14:49:08 -0400
From: Konrad Rzeszutek Wilk 
To: Ben Guthro 
Message-ID: <20121019184908.GA19834@phenom.dumpdata.com>
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	
	<20121017174317.GA25443@phenom.dumpdata.com>
	
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, hpa@zytor.com, lenb@kernel.org
Subject: Re: [Xen-devel] [RFC] ACPI S3 and Xen (suprisingly small\!).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 17, 2012 at 02:00:29PM -0400, Ben Guthro wrote:
> I'm not sure it matters, but I'm testing against a changeset about a week old:
> http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=1c4a5b37b55c56e49135e65728137f54288d1fe6

I was able to reproduce it with Xen 4.2 so found the culprit.

.. And then another issue :-(

> 
> Plus patches specific to XenClient Enterprise.
> 
> 
> On Wed, Oct 17, 2012 at 1:43 PM, Konrad Rzeszutek Wilk
>  wrote:
> > On Wed, Oct 17, 2012 at 01:46:09PM -0400, Ben Guthro wrote:
> >> On Wed, Oct 17, 2012 at 9:49 AM, Konrad Rzeszutek Wilk
> >>  wrote:
> >> [...]
> >>
> >> > The end result is this is a nice set of patches where there is only
> >> > _one_ change in the x86 code (and it is just more of dealing with
> >> > error case) - and the rest are all done in Xen side.
> >>
> >> I'm sorry to report that this series doesn't seem to work in my setup
> >> against xen-unstable.
> >>
> >> To verify that it was, in fact this patch series, and not another Xen
> >> regression - I swapped out the kernel with this patch series, with an
> >> identical one, replacing only this series with your acpi-s3.v9 branch
> >> - and everything worked fine.
> >
> > Thanks for testing it!
> >
> > I had tested it with Xen 4.1.3, which could be doing something different.
> > Will see what is up.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 19:01:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 19:01:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPHox-0005sh-RF; Fri, 19 Oct 2012 19:01:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPHow-0005sc-H0
	for xen-devel@lists.xensource.com; Fri, 19 Oct 2012 19:01:22 +0000
Received: from [85.158.139.211:52388] by server-8.bemta-5.messagelabs.com id
	43/5D-23193-183A1805; Fri, 19 Oct 2012 19:01:21 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1350673279!22940471!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODE1Njg1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22980 invoked from network); 19 Oct 2012 19:01:20 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Oct 2012 19:01:20 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9JJ1Eg0006450
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Oct 2012 19:01:15 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9JJ1Dkr006508
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 19 Oct 2012 19:01:14 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9JJ1CNi002267; Fri, 19 Oct 2012 14:01:12 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Oct 2012 12:01:12 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 3B0C44035B; Fri, 19 Oct 2012 14:49:08 -0400 (EDT)
Date: Fri, 19 Oct 2012 14:49:08 -0400
From: Konrad Rzeszutek Wilk 
To: Ben Guthro 
Message-ID: <20121019184908.GA19834@phenom.dumpdata.com>
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	
	<20121017174317.GA25443@phenom.dumpdata.com>
	
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, hpa@zytor.com, lenb@kernel.org
Subject: Re: [Xen-devel] [RFC] ACPI S3 and Xen (suprisingly small\!).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 17, 2012 at 02:00:29PM -0400, Ben Guthro wrote:
> I'm not sure it matters, but I'm testing against a changeset about a week old:
> http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=1c4a5b37b55c56e49135e65728137f54288d1fe6

I was able to reproduce it with Xen 4.2 so found the culprit.

.. And then another issue :-(

> 
> Plus patches specific to XenClient Enterprise.
> 
> 
> On Wed, Oct 17, 2012 at 1:43 PM, Konrad Rzeszutek Wilk
>  wrote:
> > On Wed, Oct 17, 2012 at 01:46:09PM -0400, Ben Guthro wrote:
> >> On Wed, Oct 17, 2012 at 9:49 AM, Konrad Rzeszutek Wilk
> >>  wrote:
> >> [...]
> >>
> >> > The end result is this is a nice set of patches where there is only
> >> > _one_ change in the x86 code (and it is just more of dealing with
> >> > error case) - and the rest are all done in Xen side.
> >>
> >> I'm sorry to report that this series doesn't seem to work in my setup
> >> against xen-unstable.
> >>
> >> To verify that it was, in fact this patch series, and not another Xen
> >> regression - I swapped out the kernel with this patch series, with an
> >> identical one, replacing only this series with your acpi-s3.v9 branch
> >> - and everything worked fine.
> >
> > Thanks for testing it!
> >
> > I had tested it with Xen 4.1.3, which could be doing something different.
> > Will see what is up.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 19:15:38 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 19:15:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPI2M-00063k-BZ; Fri, 19 Oct 2012 19:15:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPI2L-00063f-3u
	for xen-devel@lists.xensource.com; Fri, 19 Oct 2012 19:15:13 +0000
Received: from [85.158.138.51:23697] by server-15.bemta-3.messagelabs.com id
	67/F4-10261-0C6A1805; Fri, 19 Oct 2012 19:15:12 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1350674109!35050213!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgyMjgwMg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17679 invoked from network); 19 Oct 2012 19:15:11 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Oct 2012 19:15:11 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9JJF7OT030068
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Oct 2012 19:15:08 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9JJF6GL014080
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 19 Oct 2012 19:15:07 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9JJF6LO023771; Fri, 19 Oct 2012 14:15:06 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Oct 2012 12:15:05 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B4DA64035B; Fri, 19 Oct 2012 15:03:01 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Date: Fri, 19 Oct 2012 15:03:01 -0400
Message-Id: <1350673381-20342-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH] xen/hvm: If we fail to fetch an HVM parameter
	print out which flag it is.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Makes it easier to troubleshoot in the field.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 include/xen/hvm.h |   31 +++++++++++++++++++++++++++++--
 1 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/include/xen/hvm.h b/include/xen/hvm.h
index b193fa2..c2a4238 100644
--- a/include/xen/hvm.h
+++ b/include/xen/hvm.h
@@ -5,6 +5,33 @@
 #include 
 #include 
 
+static const char *param_name(int op)
+{
+	static const char *const names[] = {
+		[HVM_PARAM_CALLBACK_IRQ] = "HVM_PARAM_CALLBACK_IRQ",
+		[HVM_PARAM_STORE_PFN] = "HVM_PARAM_STORE_PFN",
+		[HVM_PARAM_STORE_EVTCHN] = "HVM_PARAM_STORE_EVTCHN",
+		[HVM_PARAM_PAE_ENABLED] = "HVM_PARAM_PAE_ENABLED",
+		[HVM_PARAM_IOREQ_PFN] = "HVM_PARAM_IOREQ_PFN",
+		[HVM_PARAM_BUFIOREQ_PFN] = "HVM_PARAM_BUFIOREQ_PFN",
+		[HVM_PARAM_TIMER_MODE] = "HVM_PARAM_TIMER_MODE",
+		[HVM_PARAM_HPET_ENABLED] = "HVM_PARAM_HPET_ENABLED",
+		[HVM_PARAM_IDENT_PT] = "HVM_PARAM_IDENT_PT",
+		[HVM_PARAM_DM_DOMAIN] = "HVM_PARAM_DM_DOMAIN",
+		[HVM_PARAM_ACPI_S_STATE] = "HVM_PARAM_ACPI_S_STATE",
+		[HVM_PARAM_VM86_TSS] = "HVM_PARAM_VM86_TSS",
+		[HVM_PARAM_VPT_ALIGN] = "HVM_PARAM_VPT_ALIGN",
+		[HVM_PARAM_CONSOLE_PFN] = "HVM_PARAM_CONSOLE_PFN",
+		[HVM_PARAM_CONSOLE_EVTCHN] = "HVM_PARAM_CONSOLE_EVTCHN" };
+
+	if (op >= ARRAY_SIZE(names))
+		return "unknown";
+
+	if (!names[op])
+		return "reserved";
+
+	return names[op];
+}
 static inline int hvm_get_parameter(int idx, uint64_t *value)
 {
 	struct xen_hvm_param xhv;
@@ -14,8 +41,8 @@ static inline int hvm_get_parameter(int idx, uint64_t *value)
 	xhv.index = idx;
 	r = HYPERVISOR_hvm_op(HVMOP_get_param, &xhv);
 	if (r < 0) {
-		printk(KERN_ERR "Cannot get hvm parameter %d: %d!\n",
-			idx, r);
+		printk(KERN_ERR "Cannot get hvm parameter %s (%d): %d!\n",
+			param_name(idx), idx, r);
 		return r;
 	}
 	*value = xhv.value;
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 19:15:38 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 19:15:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPI2M-00063k-BZ; Fri, 19 Oct 2012 19:15:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPI2L-00063f-3u
	for xen-devel@lists.xensource.com; Fri, 19 Oct 2012 19:15:13 +0000
Received: from [85.158.138.51:23697] by server-15.bemta-3.messagelabs.com id
	67/F4-10261-0C6A1805; Fri, 19 Oct 2012 19:15:12 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1350674109!35050213!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgyMjgwMg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17679 invoked from network); 19 Oct 2012 19:15:11 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Oct 2012 19:15:11 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9JJF7OT030068
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Oct 2012 19:15:08 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9JJF6GL014080
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 19 Oct 2012 19:15:07 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9JJF6LO023771; Fri, 19 Oct 2012 14:15:06 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Oct 2012 12:15:05 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B4DA64035B; Fri, 19 Oct 2012 15:03:01 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Date: Fri, 19 Oct 2012 15:03:01 -0400
Message-Id: <1350673381-20342-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH] xen/hvm: If we fail to fetch an HVM parameter
	print out which flag it is.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Makes it easier to troubleshoot in the field.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 include/xen/hvm.h |   31 +++++++++++++++++++++++++++++--
 1 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/include/xen/hvm.h b/include/xen/hvm.h
index b193fa2..c2a4238 100644
--- a/include/xen/hvm.h
+++ b/include/xen/hvm.h
@@ -5,6 +5,33 @@
 #include 
 #include 
 
+static const char *param_name(int op)
+{
+	static const char *const names[] = {
+		[HVM_PARAM_CALLBACK_IRQ] = "HVM_PARAM_CALLBACK_IRQ",
+		[HVM_PARAM_STORE_PFN] = "HVM_PARAM_STORE_PFN",
+		[HVM_PARAM_STORE_EVTCHN] = "HVM_PARAM_STORE_EVTCHN",
+		[HVM_PARAM_PAE_ENABLED] = "HVM_PARAM_PAE_ENABLED",
+		[HVM_PARAM_IOREQ_PFN] = "HVM_PARAM_IOREQ_PFN",
+		[HVM_PARAM_BUFIOREQ_PFN] = "HVM_PARAM_BUFIOREQ_PFN",
+		[HVM_PARAM_TIMER_MODE] = "HVM_PARAM_TIMER_MODE",
+		[HVM_PARAM_HPET_ENABLED] = "HVM_PARAM_HPET_ENABLED",
+		[HVM_PARAM_IDENT_PT] = "HVM_PARAM_IDENT_PT",
+		[HVM_PARAM_DM_DOMAIN] = "HVM_PARAM_DM_DOMAIN",
+		[HVM_PARAM_ACPI_S_STATE] = "HVM_PARAM_ACPI_S_STATE",
+		[HVM_PARAM_VM86_TSS] = "HVM_PARAM_VM86_TSS",
+		[HVM_PARAM_VPT_ALIGN] = "HVM_PARAM_VPT_ALIGN",
+		[HVM_PARAM_CONSOLE_PFN] = "HVM_PARAM_CONSOLE_PFN",
+		[HVM_PARAM_CONSOLE_EVTCHN] = "HVM_PARAM_CONSOLE_EVTCHN" };
+
+	if (op >= ARRAY_SIZE(names))
+		return "unknown";
+
+	if (!names[op])
+		return "reserved";
+
+	return names[op];
+}
 static inline int hvm_get_parameter(int idx, uint64_t *value)
 {
 	struct xen_hvm_param xhv;
@@ -14,8 +41,8 @@ static inline int hvm_get_parameter(int idx, uint64_t *value)
 	xhv.index = idx;
 	r = HYPERVISOR_hvm_op(HVMOP_get_param, &xhv);
 	if (r < 0) {
-		printk(KERN_ERR "Cannot get hvm parameter %d: %d!\n",
-			idx, r);
+		printk(KERN_ERR "Cannot get hvm parameter %s (%d): %d!\n",
+			param_name(idx), idx, r);
 		return r;
 	}
 	*value = xhv.value;
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 19:35:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 19:35:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPILZ-0006FS-Ab; Fri, 19 Oct 2012 19:35:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPHkl-0005q2-4V
	for xen-devel@lists.xensource.com; Fri, 19 Oct 2012 18:57:03 +0000
Received: from [85.158.139.83:18182] by server-12.bemta-5.messagelabs.com id
	66/40-26919-E72A1805; Fri, 19 Oct 2012 18:57:02 +0000
X-Env-Sender: carnold@suse.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1350673021!35100347!1
X-Originating-IP: [137.65.248.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM3LjY1LjI0OC43NCA9PiA0MzU3\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26543 invoked from network); 19 Oct 2012 18:57:01 -0000
Received: from novprvoes0310.provo.novell.com (HELO
	novprvoes0310.provo.novell.com) (137.65.248.74)
	by server-13.tower-182.messagelabs.com with SMTP;
	19 Oct 2012 18:57:01 -0000
Received: from INET-PRV-MTA by novprvoes0310.provo.novell.com
	with Novell_GroupWise; Fri, 19 Oct 2012 12:57:00 -0600
Message-Id: <50814E190200009100082117@novprvoes0310.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 19 Oct 2012 12:56:57 -0600
From: "Charles Arnold" 
To: 
Mime-Version: 1.0
Content-Disposition: inline
X-Mailman-Approved-At: Fri, 19 Oct 2012 19:35:05 +0000
Subject: [Xen-devel]  [PATCH] pygrub: Add option to list grub entries
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# Parent aa479945f718ff775c18afa2f37a391fca573114
# User carnold@suse.com
# Date 1350668686 21600
pygrub: Add option to list grub entries

The argument to "--entry" allows 2 syntaxes, either directly the entry number
in menu.lst, or the whole string behind the "title" key word. This poses the
following issue:
>From Dom0 there is no way to guess the number and, or the complete title
string because this string contains the kernel version, which will change
with a kernel update.
This patch adds [-l|--list-entries] as an argument to pygrub.

Signed-off-by: Charles Arnold 

diff -r c1c549c4fe9e tools/pygrub/src/pygrub
--- a/tools/pygrub/src/pygrub	Mon Oct 15 16:51:44 2012 +0100
+++ b/tools/pygrub/src/pygrub	Fri Oct 19 11:40:49 2012 -0600
@@ -595,7 +595,17 @@ def run_grub(file, entry, fs, cfg_args):
         sel = g.run()
 
     g = Grub(file, fs)
-    if interactive:
+
+    if list_entries:
+        for i in range(len(g.cf.images)):
+            img = g.cf.images[i]
+            print "title: %s" % img.title
+            print "  root: %s" % img.root
+            print "  kernel: %s" % img.kernel[1]
+            print "  args: %s" % img.args
+            print "  initrd: %s" % img.initrd[1]
+
+    if interactive and not list_entries:
         curses.wrapper(run_main)
     else:
         sel = g.cf.default
@@ -702,7 +712,7 @@ if __name__ == "__main__":
     sel = None
     
     def usage():
-        print >> sys.stderr, "Usage: %s [-q|--quiet] [-i|--interactive] [-n|--not-really] [--output=] [--kernel=] [--ramdisk=] [--args=] [--entry=] [--output-directory=] [--output-format=sxp|simple|simple0] " %(sys.argv[0],)
+        print >> sys.stderr, "Usage: %s [-q|--quiet] [-i|--interactive] [-l|--list-entries] [-n|--not-really] [--output=] [--kernel=] [--ramdisk=] [--args=] [--entry=] [--output-directory=] [--output-format=sxp|simple|simple0] " %(sys.argv[0],)
 
     def copy_from_image(fs, file_to_read, file_type, output_directory,
                         not_really):
@@ -736,8 +746,8 @@ if __name__ == "__main__":
             dataoff += len(data)
 
     try:
-        opts, args = getopt.gnu_getopt(sys.argv[1:], 'qinh::',
-                                   ["quiet", "interactive", "not-really", "help", 
+        opts, args = getopt.gnu_getopt(sys.argv[1:], 'qilnh::',
+                                   ["quiet", "interactive", "list-entries", "not-really", "help",
                                     "output=", "output-format=", "output-directory=",
                                     "entry=", "kernel=", 
                                     "ramdisk=", "args=", "isconfig", "debug"])
@@ -753,6 +763,7 @@ if __name__ == "__main__":
     output = None
     entry = None
     interactive = True
+    list_entries = False
     isconfig = False
     debug = False
     not_really = False
@@ -771,6 +782,8 @@ if __name__ == "__main__":
             interactive = False
         elif o in ("-i", "--interactive"):
             interactive = True
+        elif o in ("-l", "--list-entries"):
+            list_entries = True
         elif o in ("-n", "--not-really"):
             not_really = True
         elif o in ("-h", "--help"):
@@ -855,6 +868,9 @@ if __name__ == "__main__":
             fs = None
             continue
 
+    if list_entries:
+        sys.exit(0)
+
     # Did looping through partitions find us a kernel?
     if not fs:
         raise RuntimeError, "Unable to find partition containing kernel"



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 19:35:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 19:35:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPILZ-0006FS-Ab; Fri, 19 Oct 2012 19:35:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPHkl-0005q2-4V
	for xen-devel@lists.xensource.com; Fri, 19 Oct 2012 18:57:03 +0000
Received: from [85.158.139.83:18182] by server-12.bemta-5.messagelabs.com id
	66/40-26919-E72A1805; Fri, 19 Oct 2012 18:57:02 +0000
X-Env-Sender: carnold@suse.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1350673021!35100347!1
X-Originating-IP: [137.65.248.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM3LjY1LjI0OC43NCA9PiA0MzU3\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26543 invoked from network); 19 Oct 2012 18:57:01 -0000
Received: from novprvoes0310.provo.novell.com (HELO
	novprvoes0310.provo.novell.com) (137.65.248.74)
	by server-13.tower-182.messagelabs.com with SMTP;
	19 Oct 2012 18:57:01 -0000
Received: from INET-PRV-MTA by novprvoes0310.provo.novell.com
	with Novell_GroupWise; Fri, 19 Oct 2012 12:57:00 -0600
Message-Id: <50814E190200009100082117@novprvoes0310.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Fri, 19 Oct 2012 12:56:57 -0600
From: "Charles Arnold" 
To: 
Mime-Version: 1.0
Content-Disposition: inline
X-Mailman-Approved-At: Fri, 19 Oct 2012 19:35:05 +0000
Subject: [Xen-devel]  [PATCH] pygrub: Add option to list grub entries
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# Parent aa479945f718ff775c18afa2f37a391fca573114
# User carnold@suse.com
# Date 1350668686 21600
pygrub: Add option to list grub entries

The argument to "--entry" allows 2 syntaxes, either directly the entry number
in menu.lst, or the whole string behind the "title" key word. This poses the
following issue:
>From Dom0 there is no way to guess the number and, or the complete title
string because this string contains the kernel version, which will change
with a kernel update.
This patch adds [-l|--list-entries] as an argument to pygrub.

Signed-off-by: Charles Arnold 

diff -r c1c549c4fe9e tools/pygrub/src/pygrub
--- a/tools/pygrub/src/pygrub	Mon Oct 15 16:51:44 2012 +0100
+++ b/tools/pygrub/src/pygrub	Fri Oct 19 11:40:49 2012 -0600
@@ -595,7 +595,17 @@ def run_grub(file, entry, fs, cfg_args):
         sel = g.run()
 
     g = Grub(file, fs)
-    if interactive:
+
+    if list_entries:
+        for i in range(len(g.cf.images)):
+            img = g.cf.images[i]
+            print "title: %s" % img.title
+            print "  root: %s" % img.root
+            print "  kernel: %s" % img.kernel[1]
+            print "  args: %s" % img.args
+            print "  initrd: %s" % img.initrd[1]
+
+    if interactive and not list_entries:
         curses.wrapper(run_main)
     else:
         sel = g.cf.default
@@ -702,7 +712,7 @@ if __name__ == "__main__":
     sel = None
     
     def usage():
-        print >> sys.stderr, "Usage: %s [-q|--quiet] [-i|--interactive] [-n|--not-really] [--output=] [--kernel=] [--ramdisk=] [--args=] [--entry=] [--output-directory=] [--output-format=sxp|simple|simple0] " %(sys.argv[0],)
+        print >> sys.stderr, "Usage: %s [-q|--quiet] [-i|--interactive] [-l|--list-entries] [-n|--not-really] [--output=] [--kernel=] [--ramdisk=] [--args=] [--entry=] [--output-directory=] [--output-format=sxp|simple|simple0] " %(sys.argv[0],)
 
     def copy_from_image(fs, file_to_read, file_type, output_directory,
                         not_really):
@@ -736,8 +746,8 @@ if __name__ == "__main__":
             dataoff += len(data)
 
     try:
-        opts, args = getopt.gnu_getopt(sys.argv[1:], 'qinh::',
-                                   ["quiet", "interactive", "not-really", "help", 
+        opts, args = getopt.gnu_getopt(sys.argv[1:], 'qilnh::',
+                                   ["quiet", "interactive", "list-entries", "not-really", "help",
                                     "output=", "output-format=", "output-directory=",
                                     "entry=", "kernel=", 
                                     "ramdisk=", "args=", "isconfig", "debug"])
@@ -753,6 +763,7 @@ if __name__ == "__main__":
     output = None
     entry = None
     interactive = True
+    list_entries = False
     isconfig = False
     debug = False
     not_really = False
@@ -771,6 +782,8 @@ if __name__ == "__main__":
             interactive = False
         elif o in ("-i", "--interactive"):
             interactive = True
+        elif o in ("-l", "--list-entries"):
+            list_entries = True
         elif o in ("-n", "--not-really"):
             not_really = True
         elif o in ("-h", "--help"):
@@ -855,6 +868,9 @@ if __name__ == "__main__":
             fs = None
             continue
 
+    if list_entries:
+        sys.exit(0)
+
     # Did looping through partitions find us a kernel?
     if not fs:
         raise RuntimeError, "Unable to find partition containing kernel"



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 19:35:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 19:35:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPILg-0006Fw-Or; Fri, 19 Oct 2012 19:35:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPILf-0006Fm-P5
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 19:35:12 +0000
Received: from [193.109.254.147:62834] by server-2.bemta-14.messagelabs.com id
	AB/DD-19917-E6BA1805; Fri, 19 Oct 2012 19:35:10 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1350675308!9252597!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4768 invoked from network); 19 Oct 2012 19:35:09 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 19:35:09 -0000
Received: by mail-qa0-f45.google.com with SMTP id s11so347578qaa.11
	for ; Fri, 19 Oct 2012 12:35:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=2ecs/K2adXMlPLhsBzY2G/rukWrBzy1hy0N31gRshIc=;
	b=iwNVbFYuOj9+zKwObVKPfP19l+9QCszUqgRIghAU+FQrF1GBhqzgdiydeqchvuuic9
	9niS5I0+E/dad81E8I3EvRT8zsKO4LR1CzUlwJ5GrDmpH6Yb9xN47Gd5ubj3IFwdxiCk
	jtzA1iwpTNeHZ+3EA1J+LQsYoVitzo3KkuDBEhqsA4AFG/HRebjuepBoBjrJ1HlTNUcx
	qhqSf5ghSy8jlpcHSAxoHp6EkXOcrJbSyASSstsPyJ0B9+h0k1abwzQI18+NhzcBEdan
	yS6Gswp6pumxvJFyIx5V8XEnFZgu3jFg9Wrwv9GC2s0LT9J5EE3WnqPcYUb3WChe/LZQ
	wt0Q==
Received: by 10.229.193.161 with SMTP id du33mr254092qcb.22.1350675307702;
	Fri, 19 Oct 2012 12:35:07 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id gz7sm743181qab.8.2012.10.19.12.35.06
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 19 Oct 2012 12:35:07 -0700 (PDT)
Date: Fri, 19 Oct 2012 15:23:01 -0400
From: Konrad Rzeszutek Wilk 
To: Jan Beulich 
Message-ID: <20121019192300.GA20513@phenom.dumpdata.com>
References: <507D6F3D02000078000A1B13@nat28.tlf.novell.com>
	<507D814D02000078000A1B51@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <507D814D02000078000A1B51@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Ian Campbell ,
	Dan Carpenter ,
	xen-devel 
Subject: Re: [Xen-devel] [PATCH,
 v2] linux-2.6.18: fix hypercall fallback code for very old
 hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 16, 2012 at 02:46:21PM +0100, Jan Beulich wrote:
> While copying the argument structures in HYPERVISOR_event_channel_op()
> and HYPERVISOR_physdev_op() into the local variable is sufficiently
> safe even if the actual structure is smaller than the container one,
> copying back eventual output values the same way isn't: This may
> collide with on-stack variables (particularly "rc") which may change
> between the first and second memcpy() (i.e. the second memcpy() could
> discard that change).
> 
> Move the fallback code into out-of-line functions, and handle all of
> the operations known by this old a hypervisor individually: Some don't
> require copying back anything at all, and for the rest use the
> individual argument structures' sizes rather than the container's.
> 
> Reported-by: Dan Carpenter 
> Signed-off-by: Jan Beulich 
> ---
> v2: Reduce #define/#undef usage in HYPERVISOR_physdev_op_compat().
> 
> --- a/drivers/xen/core/Makefile
> +++ b/drivers/xen/core/Makefile
> @@ -2,7 +2,7 @@
>  # Makefile for the linux kernel.
>  #
>  
> -obj-y := evtchn.o gnttab.o features.o reboot.o machine_reboot.o
> +obj-y := evtchn.o gnttab.o features.o reboot.o machine_reboot.o fallback.o
>  
>  obj-$(CONFIG_PCI)		+= pci.o
>  obj-$(CONFIG_XEN_PRIVILEGED_GUEST) += firmware.o
> --- /dev/null
> +++ b/drivers/xen/core/fallback.c
> @@ -0,0 +1,84 @@
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#if 1//temp CONFIG_XEN_COMPAT <= 0x030002

Um?

> +
> +#include 
> +#include 
> +
> +int HYPERVISOR_event_channel_op_compat(int cmd, void *arg)
> +{
> +	struct evtchn_op op;
> +	int rc;
> +
> +	op.cmd = cmd;
> +	memcpy(&op.u, arg, sizeof(op.u));
> +	rc = _hypercall1(int, event_channel_op_compat, &op);
> +
> +	switch (cmd) {
> +	case EVTCHNOP_close:
> +	case EVTCHNOP_send:
> +	case EVTCHNOP_bind_vcpu:
> +	case EVTCHNOP_unmask:
> +		/* no output */
> +		break;
> +
> +#define COPY_BACK(eop) \
> +	case EVTCHNOP_##eop: \
> +		memcpy(arg, &op.u.eop, sizeof(op.u.eop)); \
> +		break
> +
> +	COPY_BACK(bind_interdomain);
> +	COPY_BACK(bind_virq);
> +	COPY_BACK(bind_pirq);
> +	COPY_BACK(status);
> +	COPY_BACK(alloc_unbound);
> +	COPY_BACK(bind_ipi);
> +#undef COPY_BACK
> +
> +	default:
> +		WARN_ON(rc != -ENOSYS);
> +		break;
> +	}
> +
> +	return rc;
> +}
> +
> +int HYPERVISOR_physdev_op_compat(int cmd, void *arg)
> +{
> +	struct physdev_op op;
> +	int rc;
> +
> +	op.cmd = cmd;
> +	memcpy(&op.u, arg, sizeof(op.u));
> +	rc = _hypercall1(int, physdev_op_compat, &op);
> +
> +	switch (cmd) {
> +	case PHYSDEVOP_IRQ_UNMASK_NOTIFY:
> +	case PHYSDEVOP_set_iopl:
> +	case PHYSDEVOP_set_iobitmap:
> +	case PHYSDEVOP_apic_write:
> +		/* no output */
> +		break;
> +
> +#define COPY_BACK(pop, fld) \
> +	case PHYSDEVOP_##pop: \
> +		memcpy(arg, &op.u.fld, sizeof(op.u.fld)); \
> +		break
> +
> +	COPY_BACK(irq_status_query, irq_status_query);
> +	COPY_BACK(apic_read, apic_op);
> +	COPY_BACK(ASSIGN_VECTOR, irq_op);
> +#undef COPY_BACK
> +
> +	default:
> +		WARN_ON(rc != -ENOSYS);
> +		break;
> +	}
> +
> +	return rc;
> +}
> +
> +#endif /* CONFIG_XEN_COMPAT <= 0x030002 */
> --- a/include/asm-i386/mach-xen/asm/hypercall.h
> +++ b/include/asm-i386/mach-xen/asm/hypercall.h
> @@ -33,7 +33,6 @@
>  #ifndef __HYPERCALL_H__
>  #define __HYPERCALL_H__
>  
> -#include  /* memcpy() */
>  #include 
>  
>  #ifndef __HYPERVISOR_H__
> @@ -128,6 +127,11 @@
>  	__res;							\
>  })
>  
> +#if CONFIG_XEN_COMPAT <= 0x030002
> +int __must_check HYPERVISOR_event_channel_op_compat(int, void *);
> +int __must_check HYPERVISOR_physdev_op_compat(int, void *);
> +#endif
> +
>  static inline int __must_check
>  HYPERVISOR_set_trap_table(
>  	const trap_info_t *table)
> @@ -267,13 +271,8 @@ HYPERVISOR_event_channel_op(
>  	int rc = _hypercall2(int, event_channel_op, cmd, arg);
>  
>  #if CONFIG_XEN_COMPAT <= 0x030002
> -	if (unlikely(rc == -ENOSYS)) {
> -		struct evtchn_op op;
> -		op.cmd = cmd;
> -		memcpy(&op.u, arg, sizeof(op.u));
> -		rc = _hypercall1(int, event_channel_op_compat, &op);
> -		memcpy(arg, &op.u, sizeof(op.u));
> -	}
> +	if (unlikely(rc == -ENOSYS))
> +		rc = HYPERVISOR_event_channel_op_compat(cmd, arg);
>  #endif
>  
>  	return rc;
> @@ -300,13 +299,8 @@ HYPERVISOR_physdev_op(
>  	int rc = _hypercall2(int, physdev_op, cmd, arg);
>  
>  #if CONFIG_XEN_COMPAT <= 0x030002
> -	if (unlikely(rc == -ENOSYS)) {
> -		struct physdev_op op;
> -		op.cmd = cmd;
> -		memcpy(&op.u, arg, sizeof(op.u));
> -		rc = _hypercall1(int, physdev_op_compat, &op);
> -		memcpy(arg, &op.u, sizeof(op.u));
> -	}
> +	if (unlikely(rc == -ENOSYS))
> +		rc = HYPERVISOR_physdev_op_compat(cmd, arg);
>  #endif
>  
>  	return rc;
> --- a/include/asm-i386/mach-xen/asm/hypervisor.h
> +++ b/include/asm-i386/mach-xen/asm/hypervisor.h
> @@ -39,8 +39,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
> -#include 
>  #include 
>  #include 
>  #include 
> 
> 

> fix hypercall fallback code for very old hypervisors
> 
> While copying the argument structures in HYPERVISOR_event_channel_op()
> and HYPERVISOR_physdev_op() into the local variable is sufficiently
> safe even if the actual structure is smaller than the container one,
> copying back eventual output values the same way isn't: This may
> collide with on-stack variables (particularly "rc") which may change
> between the first and second memcpy() (i.e. the second memcpy() could
> discard that change).
> 
> Move the fallback code into out-of-line functions, and handle all of
> the operations known by this old a hypervisor individually: Some don't
> require copying back anything at all, and for the rest use the
> individual argument structures' sizes rather than the container's.
> 
> Reported-by: Dan Carpenter 
> Signed-off-by: Jan Beulich 
> ---
> v2: Reduce #define/#undef usage in HYPERVISOR_physdev_op_compat().
> 
> --- a/drivers/xen/core/Makefile
> +++ b/drivers/xen/core/Makefile
> @@ -2,7 +2,7 @@
>  # Makefile for the linux kernel.
>  #
>  
> -obj-y := evtchn.o gnttab.o features.o reboot.o machine_reboot.o
> +obj-y := evtchn.o gnttab.o features.o reboot.o machine_reboot.o fallback.o
>  
>  obj-$(CONFIG_PCI)		+= pci.o
>  obj-$(CONFIG_XEN_PRIVILEGED_GUEST) += firmware.o
> --- /dev/null
> +++ b/drivers/xen/core/fallback.c
> @@ -0,0 +1,84 @@
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#if 1//temp CONFIG_XEN_COMPAT <= 0x030002
> +
> +#include 
> +#include 
> +
> +int HYPERVISOR_event_channel_op_compat(int cmd, void *arg)
> +{
> +	struct evtchn_op op;
> +	int rc;
> +
> +	op.cmd = cmd;
> +	memcpy(&op.u, arg, sizeof(op.u));
> +	rc = _hypercall1(int, event_channel_op_compat, &op);
> +
> +	switch (cmd) {
> +	case EVTCHNOP_close:
> +	case EVTCHNOP_send:
> +	case EVTCHNOP_bind_vcpu:
> +	case EVTCHNOP_unmask:
> +		/* no output */
> +		break;
> +
> +#define COPY_BACK(eop) \
> +	case EVTCHNOP_##eop: \
> +		memcpy(arg, &op.u.eop, sizeof(op.u.eop)); \
> +		break
> +
> +	COPY_BACK(bind_interdomain);
> +	COPY_BACK(bind_virq);
> +	COPY_BACK(bind_pirq);
> +	COPY_BACK(status);
> +	COPY_BACK(alloc_unbound);
> +	COPY_BACK(bind_ipi);
> +#undef COPY_BACK
> +
> +	default:
> +		WARN_ON(rc != -ENOSYS);
> +		break;
> +	}
> +
> +	return rc;
> +}
> +
> +int HYPERVISOR_physdev_op_compat(int cmd, void *arg)
> +{
> +	struct physdev_op op;
> +	int rc;
> +
> +	op.cmd = cmd;
> +	memcpy(&op.u, arg, sizeof(op.u));
> +	rc = _hypercall1(int, physdev_op_compat, &op);
> +
> +	switch (cmd) {
> +	case PHYSDEVOP_IRQ_UNMASK_NOTIFY:
> +	case PHYSDEVOP_set_iopl:
> +	case PHYSDEVOP_set_iobitmap:
> +	case PHYSDEVOP_apic_write:
> +		/* no output */
> +		break;
> +
> +#define COPY_BACK(pop, fld) \
> +	case PHYSDEVOP_##pop: \
> +		memcpy(arg, &op.u.fld, sizeof(op.u.fld)); \
> +		break
> +
> +	COPY_BACK(irq_status_query, irq_status_query);
> +	COPY_BACK(apic_read, apic_op);
> +	COPY_BACK(ASSIGN_VECTOR, irq_op);
> +#undef COPY_BACK
> +
> +	default:
> +		WARN_ON(rc != -ENOSYS);
> +		break;
> +	}
> +
> +	return rc;
> +}
> +
> +#endif /* CONFIG_XEN_COMPAT <= 0x030002 */
> --- a/include/asm-i386/mach-xen/asm/hypercall.h
> +++ b/include/asm-i386/mach-xen/asm/hypercall.h
> @@ -33,7 +33,6 @@
>  #ifndef __HYPERCALL_H__
>  #define __HYPERCALL_H__
>  
> -#include  /* memcpy() */
>  #include 
>  
>  #ifndef __HYPERVISOR_H__
> @@ -128,6 +127,11 @@
>  	__res;							\
>  })
>  
> +#if CONFIG_XEN_COMPAT <= 0x030002
> +int __must_check HYPERVISOR_event_channel_op_compat(int, void *);
> +int __must_check HYPERVISOR_physdev_op_compat(int, void *);
> +#endif
> +
>  static inline int __must_check
>  HYPERVISOR_set_trap_table(
>  	const trap_info_t *table)
> @@ -267,13 +271,8 @@ HYPERVISOR_event_channel_op(
>  	int rc = _hypercall2(int, event_channel_op, cmd, arg);
>  
>  #if CONFIG_XEN_COMPAT <= 0x030002
> -	if (unlikely(rc == -ENOSYS)) {
> -		struct evtchn_op op;
> -		op.cmd = cmd;
> -		memcpy(&op.u, arg, sizeof(op.u));
> -		rc = _hypercall1(int, event_channel_op_compat, &op);
> -		memcpy(arg, &op.u, sizeof(op.u));
> -	}
> +	if (unlikely(rc == -ENOSYS))
> +		rc = HYPERVISOR_event_channel_op_compat(cmd, arg);
>  #endif
>  
>  	return rc;
> @@ -300,13 +299,8 @@ HYPERVISOR_physdev_op(
>  	int rc = _hypercall2(int, physdev_op, cmd, arg);
>  
>  #if CONFIG_XEN_COMPAT <= 0x030002
> -	if (unlikely(rc == -ENOSYS)) {
> -		struct physdev_op op;
> -		op.cmd = cmd;
> -		memcpy(&op.u, arg, sizeof(op.u));
> -		rc = _hypercall1(int, physdev_op_compat, &op);
> -		memcpy(arg, &op.u, sizeof(op.u));
> -	}
> +	if (unlikely(rc == -ENOSYS))
> +		rc = HYPERVISOR_physdev_op_compat(cmd, arg);
>  #endif
>  
>  	return rc;
> --- a/include/asm-i386/mach-xen/asm/hypervisor.h
> +++ b/include/asm-i386/mach-xen/asm/hypervisor.h
> @@ -39,8 +39,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
> -#include 
>  #include 
>  #include 
>  #include 

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 19:35:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 19:35:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPILg-0006Fw-Or; Fri, 19 Oct 2012 19:35:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPILf-0006Fm-P5
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 19:35:12 +0000
Received: from [193.109.254.147:62834] by server-2.bemta-14.messagelabs.com id
	AB/DD-19917-E6BA1805; Fri, 19 Oct 2012 19:35:10 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1350675308!9252597!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4768 invoked from network); 19 Oct 2012 19:35:09 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 19:35:09 -0000
Received: by mail-qa0-f45.google.com with SMTP id s11so347578qaa.11
	for ; Fri, 19 Oct 2012 12:35:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=2ecs/K2adXMlPLhsBzY2G/rukWrBzy1hy0N31gRshIc=;
	b=iwNVbFYuOj9+zKwObVKPfP19l+9QCszUqgRIghAU+FQrF1GBhqzgdiydeqchvuuic9
	9niS5I0+E/dad81E8I3EvRT8zsKO4LR1CzUlwJ5GrDmpH6Yb9xN47Gd5ubj3IFwdxiCk
	jtzA1iwpTNeHZ+3EA1J+LQsYoVitzo3KkuDBEhqsA4AFG/HRebjuepBoBjrJ1HlTNUcx
	qhqSf5ghSy8jlpcHSAxoHp6EkXOcrJbSyASSstsPyJ0B9+h0k1abwzQI18+NhzcBEdan
	yS6Gswp6pumxvJFyIx5V8XEnFZgu3jFg9Wrwv9GC2s0LT9J5EE3WnqPcYUb3WChe/LZQ
	wt0Q==
Received: by 10.229.193.161 with SMTP id du33mr254092qcb.22.1350675307702;
	Fri, 19 Oct 2012 12:35:07 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id gz7sm743181qab.8.2012.10.19.12.35.06
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 19 Oct 2012 12:35:07 -0700 (PDT)
Date: Fri, 19 Oct 2012 15:23:01 -0400
From: Konrad Rzeszutek Wilk 
To: Jan Beulich 
Message-ID: <20121019192300.GA20513@phenom.dumpdata.com>
References: <507D6F3D02000078000A1B13@nat28.tlf.novell.com>
	<507D814D02000078000A1B51@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <507D814D02000078000A1B51@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Ian Campbell ,
	Dan Carpenter ,
	xen-devel 
Subject: Re: [Xen-devel] [PATCH,
 v2] linux-2.6.18: fix hypercall fallback code for very old
 hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 16, 2012 at 02:46:21PM +0100, Jan Beulich wrote:
> While copying the argument structures in HYPERVISOR_event_channel_op()
> and HYPERVISOR_physdev_op() into the local variable is sufficiently
> safe even if the actual structure is smaller than the container one,
> copying back eventual output values the same way isn't: This may
> collide with on-stack variables (particularly "rc") which may change
> between the first and second memcpy() (i.e. the second memcpy() could
> discard that change).
> 
> Move the fallback code into out-of-line functions, and handle all of
> the operations known by this old a hypervisor individually: Some don't
> require copying back anything at all, and for the rest use the
> individual argument structures' sizes rather than the container's.
> 
> Reported-by: Dan Carpenter 
> Signed-off-by: Jan Beulich 
> ---
> v2: Reduce #define/#undef usage in HYPERVISOR_physdev_op_compat().
> 
> --- a/drivers/xen/core/Makefile
> +++ b/drivers/xen/core/Makefile
> @@ -2,7 +2,7 @@
>  # Makefile for the linux kernel.
>  #
>  
> -obj-y := evtchn.o gnttab.o features.o reboot.o machine_reboot.o
> +obj-y := evtchn.o gnttab.o features.o reboot.o machine_reboot.o fallback.o
>  
>  obj-$(CONFIG_PCI)		+= pci.o
>  obj-$(CONFIG_XEN_PRIVILEGED_GUEST) += firmware.o
> --- /dev/null
> +++ b/drivers/xen/core/fallback.c
> @@ -0,0 +1,84 @@
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#if 1//temp CONFIG_XEN_COMPAT <= 0x030002

Um?

> +
> +#include 
> +#include 
> +
> +int HYPERVISOR_event_channel_op_compat(int cmd, void *arg)
> +{
> +	struct evtchn_op op;
> +	int rc;
> +
> +	op.cmd = cmd;
> +	memcpy(&op.u, arg, sizeof(op.u));
> +	rc = _hypercall1(int, event_channel_op_compat, &op);
> +
> +	switch (cmd) {
> +	case EVTCHNOP_close:
> +	case EVTCHNOP_send:
> +	case EVTCHNOP_bind_vcpu:
> +	case EVTCHNOP_unmask:
> +		/* no output */
> +		break;
> +
> +#define COPY_BACK(eop) \
> +	case EVTCHNOP_##eop: \
> +		memcpy(arg, &op.u.eop, sizeof(op.u.eop)); \
> +		break
> +
> +	COPY_BACK(bind_interdomain);
> +	COPY_BACK(bind_virq);
> +	COPY_BACK(bind_pirq);
> +	COPY_BACK(status);
> +	COPY_BACK(alloc_unbound);
> +	COPY_BACK(bind_ipi);
> +#undef COPY_BACK
> +
> +	default:
> +		WARN_ON(rc != -ENOSYS);
> +		break;
> +	}
> +
> +	return rc;
> +}
> +
> +int HYPERVISOR_physdev_op_compat(int cmd, void *arg)
> +{
> +	struct physdev_op op;
> +	int rc;
> +
> +	op.cmd = cmd;
> +	memcpy(&op.u, arg, sizeof(op.u));
> +	rc = _hypercall1(int, physdev_op_compat, &op);
> +
> +	switch (cmd) {
> +	case PHYSDEVOP_IRQ_UNMASK_NOTIFY:
> +	case PHYSDEVOP_set_iopl:
> +	case PHYSDEVOP_set_iobitmap:
> +	case PHYSDEVOP_apic_write:
> +		/* no output */
> +		break;
> +
> +#define COPY_BACK(pop, fld) \
> +	case PHYSDEVOP_##pop: \
> +		memcpy(arg, &op.u.fld, sizeof(op.u.fld)); \
> +		break
> +
> +	COPY_BACK(irq_status_query, irq_status_query);
> +	COPY_BACK(apic_read, apic_op);
> +	COPY_BACK(ASSIGN_VECTOR, irq_op);
> +#undef COPY_BACK
> +
> +	default:
> +		WARN_ON(rc != -ENOSYS);
> +		break;
> +	}
> +
> +	return rc;
> +}
> +
> +#endif /* CONFIG_XEN_COMPAT <= 0x030002 */
> --- a/include/asm-i386/mach-xen/asm/hypercall.h
> +++ b/include/asm-i386/mach-xen/asm/hypercall.h
> @@ -33,7 +33,6 @@
>  #ifndef __HYPERCALL_H__
>  #define __HYPERCALL_H__
>  
> -#include  /* memcpy() */
>  #include 
>  
>  #ifndef __HYPERVISOR_H__
> @@ -128,6 +127,11 @@
>  	__res;							\
>  })
>  
> +#if CONFIG_XEN_COMPAT <= 0x030002
> +int __must_check HYPERVISOR_event_channel_op_compat(int, void *);
> +int __must_check HYPERVISOR_physdev_op_compat(int, void *);
> +#endif
> +
>  static inline int __must_check
>  HYPERVISOR_set_trap_table(
>  	const trap_info_t *table)
> @@ -267,13 +271,8 @@ HYPERVISOR_event_channel_op(
>  	int rc = _hypercall2(int, event_channel_op, cmd, arg);
>  
>  #if CONFIG_XEN_COMPAT <= 0x030002
> -	if (unlikely(rc == -ENOSYS)) {
> -		struct evtchn_op op;
> -		op.cmd = cmd;
> -		memcpy(&op.u, arg, sizeof(op.u));
> -		rc = _hypercall1(int, event_channel_op_compat, &op);
> -		memcpy(arg, &op.u, sizeof(op.u));
> -	}
> +	if (unlikely(rc == -ENOSYS))
> +		rc = HYPERVISOR_event_channel_op_compat(cmd, arg);
>  #endif
>  
>  	return rc;
> @@ -300,13 +299,8 @@ HYPERVISOR_physdev_op(
>  	int rc = _hypercall2(int, physdev_op, cmd, arg);
>  
>  #if CONFIG_XEN_COMPAT <= 0x030002
> -	if (unlikely(rc == -ENOSYS)) {
> -		struct physdev_op op;
> -		op.cmd = cmd;
> -		memcpy(&op.u, arg, sizeof(op.u));
> -		rc = _hypercall1(int, physdev_op_compat, &op);
> -		memcpy(arg, &op.u, sizeof(op.u));
> -	}
> +	if (unlikely(rc == -ENOSYS))
> +		rc = HYPERVISOR_physdev_op_compat(cmd, arg);
>  #endif
>  
>  	return rc;
> --- a/include/asm-i386/mach-xen/asm/hypervisor.h
> +++ b/include/asm-i386/mach-xen/asm/hypervisor.h
> @@ -39,8 +39,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
> -#include 
>  #include 
>  #include 
>  #include 
> 
> 

> fix hypercall fallback code for very old hypervisors
> 
> While copying the argument structures in HYPERVISOR_event_channel_op()
> and HYPERVISOR_physdev_op() into the local variable is sufficiently
> safe even if the actual structure is smaller than the container one,
> copying back eventual output values the same way isn't: This may
> collide with on-stack variables (particularly "rc") which may change
> between the first and second memcpy() (i.e. the second memcpy() could
> discard that change).
> 
> Move the fallback code into out-of-line functions, and handle all of
> the operations known by this old a hypervisor individually: Some don't
> require copying back anything at all, and for the rest use the
> individual argument structures' sizes rather than the container's.
> 
> Reported-by: Dan Carpenter 
> Signed-off-by: Jan Beulich 
> ---
> v2: Reduce #define/#undef usage in HYPERVISOR_physdev_op_compat().
> 
> --- a/drivers/xen/core/Makefile
> +++ b/drivers/xen/core/Makefile
> @@ -2,7 +2,7 @@
>  # Makefile for the linux kernel.
>  #
>  
> -obj-y := evtchn.o gnttab.o features.o reboot.o machine_reboot.o
> +obj-y := evtchn.o gnttab.o features.o reboot.o machine_reboot.o fallback.o
>  
>  obj-$(CONFIG_PCI)		+= pci.o
>  obj-$(CONFIG_XEN_PRIVILEGED_GUEST) += firmware.o
> --- /dev/null
> +++ b/drivers/xen/core/fallback.c
> @@ -0,0 +1,84 @@
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#if 1//temp CONFIG_XEN_COMPAT <= 0x030002
> +
> +#include 
> +#include 
> +
> +int HYPERVISOR_event_channel_op_compat(int cmd, void *arg)
> +{
> +	struct evtchn_op op;
> +	int rc;
> +
> +	op.cmd = cmd;
> +	memcpy(&op.u, arg, sizeof(op.u));
> +	rc = _hypercall1(int, event_channel_op_compat, &op);
> +
> +	switch (cmd) {
> +	case EVTCHNOP_close:
> +	case EVTCHNOP_send:
> +	case EVTCHNOP_bind_vcpu:
> +	case EVTCHNOP_unmask:
> +		/* no output */
> +		break;
> +
> +#define COPY_BACK(eop) \
> +	case EVTCHNOP_##eop: \
> +		memcpy(arg, &op.u.eop, sizeof(op.u.eop)); \
> +		break
> +
> +	COPY_BACK(bind_interdomain);
> +	COPY_BACK(bind_virq);
> +	COPY_BACK(bind_pirq);
> +	COPY_BACK(status);
> +	COPY_BACK(alloc_unbound);
> +	COPY_BACK(bind_ipi);
> +#undef COPY_BACK
> +
> +	default:
> +		WARN_ON(rc != -ENOSYS);
> +		break;
> +	}
> +
> +	return rc;
> +}
> +
> +int HYPERVISOR_physdev_op_compat(int cmd, void *arg)
> +{
> +	struct physdev_op op;
> +	int rc;
> +
> +	op.cmd = cmd;
> +	memcpy(&op.u, arg, sizeof(op.u));
> +	rc = _hypercall1(int, physdev_op_compat, &op);
> +
> +	switch (cmd) {
> +	case PHYSDEVOP_IRQ_UNMASK_NOTIFY:
> +	case PHYSDEVOP_set_iopl:
> +	case PHYSDEVOP_set_iobitmap:
> +	case PHYSDEVOP_apic_write:
> +		/* no output */
> +		break;
> +
> +#define COPY_BACK(pop, fld) \
> +	case PHYSDEVOP_##pop: \
> +		memcpy(arg, &op.u.fld, sizeof(op.u.fld)); \
> +		break
> +
> +	COPY_BACK(irq_status_query, irq_status_query);
> +	COPY_BACK(apic_read, apic_op);
> +	COPY_BACK(ASSIGN_VECTOR, irq_op);
> +#undef COPY_BACK
> +
> +	default:
> +		WARN_ON(rc != -ENOSYS);
> +		break;
> +	}
> +
> +	return rc;
> +}
> +
> +#endif /* CONFIG_XEN_COMPAT <= 0x030002 */
> --- a/include/asm-i386/mach-xen/asm/hypercall.h
> +++ b/include/asm-i386/mach-xen/asm/hypercall.h
> @@ -33,7 +33,6 @@
>  #ifndef __HYPERCALL_H__
>  #define __HYPERCALL_H__
>  
> -#include  /* memcpy() */
>  #include 
>  
>  #ifndef __HYPERVISOR_H__
> @@ -128,6 +127,11 @@
>  	__res;							\
>  })
>  
> +#if CONFIG_XEN_COMPAT <= 0x030002
> +int __must_check HYPERVISOR_event_channel_op_compat(int, void *);
> +int __must_check HYPERVISOR_physdev_op_compat(int, void *);
> +#endif
> +
>  static inline int __must_check
>  HYPERVISOR_set_trap_table(
>  	const trap_info_t *table)
> @@ -267,13 +271,8 @@ HYPERVISOR_event_channel_op(
>  	int rc = _hypercall2(int, event_channel_op, cmd, arg);
>  
>  #if CONFIG_XEN_COMPAT <= 0x030002
> -	if (unlikely(rc == -ENOSYS)) {
> -		struct evtchn_op op;
> -		op.cmd = cmd;
> -		memcpy(&op.u, arg, sizeof(op.u));
> -		rc = _hypercall1(int, event_channel_op_compat, &op);
> -		memcpy(arg, &op.u, sizeof(op.u));
> -	}
> +	if (unlikely(rc == -ENOSYS))
> +		rc = HYPERVISOR_event_channel_op_compat(cmd, arg);
>  #endif
>  
>  	return rc;
> @@ -300,13 +299,8 @@ HYPERVISOR_physdev_op(
>  	int rc = _hypercall2(int, physdev_op, cmd, arg);
>  
>  #if CONFIG_XEN_COMPAT <= 0x030002
> -	if (unlikely(rc == -ENOSYS)) {
> -		struct physdev_op op;
> -		op.cmd = cmd;
> -		memcpy(&op.u, arg, sizeof(op.u));
> -		rc = _hypercall1(int, physdev_op_compat, &op);
> -		memcpy(arg, &op.u, sizeof(op.u));
> -	}
> +	if (unlikely(rc == -ENOSYS))
> +		rc = HYPERVISOR_physdev_op_compat(cmd, arg);
>  #endif
>  
>  	return rc;
> --- a/include/asm-i386/mach-xen/asm/hypervisor.h
> +++ b/include/asm-i386/mach-xen/asm/hypervisor.h
> @@ -39,8 +39,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
> -#include 
>  #include 
>  #include 
>  #include 

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 19:47:57 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 19:47:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPIXj-0006aF-C9; Fri, 19 Oct 2012 19:47:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPIXh-0006aA-CO
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 19:47:37 +0000
Received: from [85.158.138.51:48864] by server-6.bemta-3.messagelabs.com id
	A5/19-32375-85EA1805; Fri, 19 Oct 2012 19:47:36 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1350676054!35052480!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgyMjgwMg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28593 invoked from network); 19 Oct 2012 19:47:36 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Oct 2012 19:47:36 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9JJlTxX000794
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Oct 2012 19:47:30 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9JJlTNP024662
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 19 Oct 2012 19:47:29 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9JJlS9w023424; Fri, 19 Oct 2012 14:47:29 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Oct 2012 12:47:28 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 838854035B; Fri, 19 Oct 2012 15:35:24 -0400 (EDT)
Date: Fri, 19 Oct 2012 15:35:24 -0400
From: Konrad Rzeszutek Wilk 
To: Sander Eikelenboom 
Message-ID: <20121019193523.GA27109@phenom.dumpdata.com>
References: <571433688.20120519104615@eikelenboom.it>
	<20120730190006.GM4547@phenom.dumpdata.com>
	<1811240070.20120730214741@eikelenboom.it>
	<20120731152558.GM4789@phenom.dumpdata.com>
	<1896498692.20120731174014@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1896498692.20120731174014@eikelenboom.it>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel 
Subject: Re: [Xen-devel] xen-pciback.hide syntax
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Jul 31, 2012 at 05:40:14PM +0200, Sander Eikelenboom wrote:
> Hello Konrad,
> 
> Tuesday, July 31, 2012, 5:25:58 PM, you wrote:
> 
> > On Mon, Jul 30, 2012 at 09:47:41PM +0200, Sander Eikelenboom wrote:
> >> Monday, July 30, 2012, 9:00:06 PM, you wrote:
> >> 
> >> > On Sat, May 19, 2012 at 10:46:15AM +0200, Sander Eikelenboom wrote:
> >> >> Hi Konrad,
> >> >> 
> >> >> The syntax for specifying the devices for pciback to hide is "bus:device.function".
> >> >> While thinking about cooking up a patch to be able to use a "*" wildcard for the function, i was wondering if not hiding all functions of a device is feasible at all.
> >> >> 
> >> >> For what I understand of PCI, function 0 is always required, so if I only hide function 0, i can't use the other functions in dom0, since those functions would require a function 0, which is hidden.
> >> >> 
> >> >> So would it be more logical to drop/ignore the function from the BDF, and always hide all functions from a device ?
> >> 
> >> > That might run afoul of the SR-IOV virtual devices. They (when loaded) provide a fake
> >> > bus:device:function, where the device is port (so if the SR-IOV card has two
> >> > jacks, you get 00 and 01), and the function is for the amount of VFs it can make.
> >> > On the Intel SR-IOV NIC with 'igbvf.max_vfs=7' I end up with 14 PCI devices, where
> >> > the function bear no resemblence to each other (and can be passed in different guests).
> >> 
> >> > The PCI restriction I know of is if the device is behind a bridge. The issue here
> >> > is that .. well, you could pass in a different function to a different guest, but
> >> > one guest's hardware device could listen on the other guests' function. It would
> >> > require tweaking the driver to dump the contents of some registers and some deep
> >> > hacking, but that is the security issue with that.
> >> 
> >> Hmm that would mean there are three possibilities:
> >> 1) Accept a Wildcard syntax like "bus:device.*", which would mean hide all functions of device.
> 
> > Which in this context actually makes sense. You probably don't want to use the VF's in
> > your host.
> 
> In my use cases i always hide all functions, and since my usb controllers have 7 functions, that leads to quite some long lines.
> 
> >> 2) Accept not providing the function as a wildcard "bus:device", would mean hide all functions of device.
> 
> > .
> >> 
> >> 3) Do nothing, the gained overview on grub lines isn't worth the effort :-)
> 
> > Heh!
> 
> > I think I like 2).
> 
> I think that would be the most simple and straightforward to implement, the only thing is that the .cfg files seem to use the "bus:device.*" scheme ...
> Don't know if there are any other related cmd options for the kernel that use a certain syntax that could be preferred ?
> 

So Jan implemented this and it is in v3.7.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 19:47:57 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 19:47:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPIXj-0006aF-C9; Fri, 19 Oct 2012 19:47:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPIXh-0006aA-CO
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 19:47:37 +0000
Received: from [85.158.138.51:48864] by server-6.bemta-3.messagelabs.com id
	A5/19-32375-85EA1805; Fri, 19 Oct 2012 19:47:36 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1350676054!35052480!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgyMjgwMg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28593 invoked from network); 19 Oct 2012 19:47:36 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Oct 2012 19:47:36 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9JJlTxX000794
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 19 Oct 2012 19:47:30 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9JJlTNP024662
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 19 Oct 2012 19:47:29 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9JJlS9w023424; Fri, 19 Oct 2012 14:47:29 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Oct 2012 12:47:28 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 838854035B; Fri, 19 Oct 2012 15:35:24 -0400 (EDT)
Date: Fri, 19 Oct 2012 15:35:24 -0400
From: Konrad Rzeszutek Wilk 
To: Sander Eikelenboom 
Message-ID: <20121019193523.GA27109@phenom.dumpdata.com>
References: <571433688.20120519104615@eikelenboom.it>
	<20120730190006.GM4547@phenom.dumpdata.com>
	<1811240070.20120730214741@eikelenboom.it>
	<20120731152558.GM4789@phenom.dumpdata.com>
	<1896498692.20120731174014@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1896498692.20120731174014@eikelenboom.it>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel 
Subject: Re: [Xen-devel] xen-pciback.hide syntax
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Jul 31, 2012 at 05:40:14PM +0200, Sander Eikelenboom wrote:
> Hello Konrad,
> 
> Tuesday, July 31, 2012, 5:25:58 PM, you wrote:
> 
> > On Mon, Jul 30, 2012 at 09:47:41PM +0200, Sander Eikelenboom wrote:
> >> Monday, July 30, 2012, 9:00:06 PM, you wrote:
> >> 
> >> > On Sat, May 19, 2012 at 10:46:15AM +0200, Sander Eikelenboom wrote:
> >> >> Hi Konrad,
> >> >> 
> >> >> The syntax for specifying the devices for pciback to hide is "bus:device.function".
> >> >> While thinking about cooking up a patch to be able to use a "*" wildcard for the function, i was wondering if not hiding all functions of a device is feasible at all.
> >> >> 
> >> >> For what I understand of PCI, function 0 is always required, so if I only hide function 0, i can't use the other functions in dom0, since those functions would require a function 0, which is hidden.
> >> >> 
> >> >> So would it be more logical to drop/ignore the function from the BDF, and always hide all functions from a device ?
> >> 
> >> > That might run afoul of the SR-IOV virtual devices. They (when loaded) provide a fake
> >> > bus:device:function, where the device is port (so if the SR-IOV card has two
> >> > jacks, you get 00 and 01), and the function is for the amount of VFs it can make.
> >> > On the Intel SR-IOV NIC with 'igbvf.max_vfs=7' I end up with 14 PCI devices, where
> >> > the function bear no resemblence to each other (and can be passed in different guests).
> >> 
> >> > The PCI restriction I know of is if the device is behind a bridge. The issue here
> >> > is that .. well, you could pass in a different function to a different guest, but
> >> > one guest's hardware device could listen on the other guests' function. It would
> >> > require tweaking the driver to dump the contents of some registers and some deep
> >> > hacking, but that is the security issue with that.
> >> 
> >> Hmm that would mean there are three possibilities:
> >> 1) Accept a Wildcard syntax like "bus:device.*", which would mean hide all functions of device.
> 
> > Which in this context actually makes sense. You probably don't want to use the VF's in
> > your host.
> 
> In my use cases i always hide all functions, and since my usb controllers have 7 functions, that leads to quite some long lines.
> 
> >> 2) Accept not providing the function as a wildcard "bus:device", would mean hide all functions of device.
> 
> > .
> >> 
> >> 3) Do nothing, the gained overview on grub lines isn't worth the effort :-)
> 
> > Heh!
> 
> > I think I like 2).
> 
> I think that would be the most simple and straightforward to implement, the only thing is that the .cfg files seem to use the "bus:device.*" scheme ...
> Don't know if there are any other related cmd options for the kernel that use a certain syntax that could be preferred ?
> 

So Jan implemented this and it is in v3.7.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 19:48:45 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 19:48:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPIYT-0006cy-Qd; Fri, 19 Oct 2012 19:48:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPIYS-0006cp-QS
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 19:48:25 +0000
Received: from [85.158.139.83:41842] by server-15.bemta-5.messagelabs.com id
	6E/D2-28599-88EA1805; Fri, 19 Oct 2012 19:48:24 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-10.tower-182.messagelabs.com!1350676103!35951226!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3893 invoked from network); 19 Oct 2012 19:48:23 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-10.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	19 Oct 2012 19:48:23 -0000
Received: from 50-66-ftth.onsneteindhoven.nl ([88.159.66.50]:50749
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TPIaC-00049m-OJ; Fri, 19 Oct 2012 21:50:12 +0200
Date: Fri, 19 Oct 2012 21:48:18 +0200
From: Sander Eikelenboom 
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1145711007.20121019214818@eikelenboom.it>
To: Konrad Rzeszutek Wilk 
In-Reply-To: <20121019193523.GA27109@phenom.dumpdata.com>
References: <571433688.20120519104615@eikelenboom.it>
	<20120730190006.GM4547@phenom.dumpdata.com>
	<1811240070.20120730214741@eikelenboom.it>
	<20120731152558.GM4789@phenom.dumpdata.com>
	<1896498692.20120731174014@eikelenboom.it>
	<20121019193523.GA27109@phenom.dumpdata.com>
MIME-Version: 1.0
Cc: xen-devel 
Subject: Re: [Xen-devel] xen-pciback.hide syntax
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Friday, October 19, 2012, 9:35:24 PM, you wrote:

> On Tue, Jul 31, 2012 at 05:40:14PM +0200, Sander Eikelenboom wrote:
>> Hello Konrad,
>> 
>> Tuesday, July 31, 2012, 5:25:58 PM, you wrote:
>> 
>> > On Mon, Jul 30, 2012 at 09:47:41PM +0200, Sander Eikelenboom wrote:
>> >> Monday, July 30, 2012, 9:00:06 PM, you wrote:
>> >> 
>> >> > On Sat, May 19, 2012 at 10:46:15AM +0200, Sander Eikelenboom wrote:
>> >> >> Hi Konrad,
>> >> >> 
>> >> >> The syntax for specifying the devices for pciback to hide is "bus:device.function".
>> >> >> While thinking about cooking up a patch to be able to use a "*" wildcard for the function, i was wondering if not hiding all functions of a device is feasible at all.
>> >> >> 
>> >> >> For what I understand of PCI, function 0 is always required, so if I only hide function 0, i can't use the other functions in dom0, since those functions would require a function 0, which is hidden.
>> >> >> 
>> >> >> So would it be more logical to drop/ignore the function from the BDF, and always hide all functions from a device ?
>> >> 
>> >> > That might run afoul of the SR-IOV virtual devices. They (when loaded) provide a fake
>> >> > bus:device:function, where the device is port (so if the SR-IOV card has two
>> >> > jacks, you get 00 and 01), and the function is for the amount of VFs it can make.
>> >> > On the Intel SR-IOV NIC with 'igbvf.max_vfs=7' I end up with 14 PCI devices, where
>> >> > the function bear no resemblence to each other (and can be passed in different guests).
>> >> 
>> >> > The PCI restriction I know of is if the device is behind a bridge. The issue here
>> >> > is that .. well, you could pass in a different function to a different guest, but
>> >> > one guest's hardware device could listen on the other guests' function. It would
>> >> > require tweaking the driver to dump the contents of some registers and some deep
>> >> > hacking, but that is the security issue with that.
>> >> 
>> >> Hmm that would mean there are three possibilities:
>> >> 1) Accept a Wildcard syntax like "bus:device.*", which would mean hide all functions of device.
>> 
>> > Which in this context actually makes sense. You probably don't want to use the VF's in
>> > your host.
>> 
>> In my use cases i always hide all functions, and since my usb controllers have 7 functions, that leads to quite some long lines.
>> 
>> >> 2) Accept not providing the function as a wildcard "bus:device", would mean hide all functions of device.
>> 
>> > .
>> >> 
>> >> 3) Do nothing, the gained overview on grub lines isn't worth the effort :-)
>> 
>> > Heh!
>> 
>> > I think I like 2).
>> 
>> I think that would be the most simple and straightforward to implement, the only thing is that the .cfg files seem to use the "bus:device.*" scheme ...
>> Don't know if there are any other related cmd options for the kernel that use a certain syntax that could be preferred ?
>> 

> So Jan implemented this and it is in v3.7.


Yes i saw it :-)
Thx !


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 19:48:45 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 19:48:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPIYT-0006cy-Qd; Fri, 19 Oct 2012 19:48:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPIYS-0006cp-QS
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 19:48:25 +0000
Received: from [85.158.139.83:41842] by server-15.bemta-5.messagelabs.com id
	6E/D2-28599-88EA1805; Fri, 19 Oct 2012 19:48:24 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-10.tower-182.messagelabs.com!1350676103!35951226!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3893 invoked from network); 19 Oct 2012 19:48:23 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-10.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	19 Oct 2012 19:48:23 -0000
Received: from 50-66-ftth.onsneteindhoven.nl ([88.159.66.50]:50749
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TPIaC-00049m-OJ; Fri, 19 Oct 2012 21:50:12 +0200
Date: Fri, 19 Oct 2012 21:48:18 +0200
From: Sander Eikelenboom 
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1145711007.20121019214818@eikelenboom.it>
To: Konrad Rzeszutek Wilk 
In-Reply-To: <20121019193523.GA27109@phenom.dumpdata.com>
References: <571433688.20120519104615@eikelenboom.it>
	<20120730190006.GM4547@phenom.dumpdata.com>
	<1811240070.20120730214741@eikelenboom.it>
	<20120731152558.GM4789@phenom.dumpdata.com>
	<1896498692.20120731174014@eikelenboom.it>
	<20121019193523.GA27109@phenom.dumpdata.com>
MIME-Version: 1.0
Cc: xen-devel 
Subject: Re: [Xen-devel] xen-pciback.hide syntax
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Friday, October 19, 2012, 9:35:24 PM, you wrote:

> On Tue, Jul 31, 2012 at 05:40:14PM +0200, Sander Eikelenboom wrote:
>> Hello Konrad,
>> 
>> Tuesday, July 31, 2012, 5:25:58 PM, you wrote:
>> 
>> > On Mon, Jul 30, 2012 at 09:47:41PM +0200, Sander Eikelenboom wrote:
>> >> Monday, July 30, 2012, 9:00:06 PM, you wrote:
>> >> 
>> >> > On Sat, May 19, 2012 at 10:46:15AM +0200, Sander Eikelenboom wrote:
>> >> >> Hi Konrad,
>> >> >> 
>> >> >> The syntax for specifying the devices for pciback to hide is "bus:device.function".
>> >> >> While thinking about cooking up a patch to be able to use a "*" wildcard for the function, i was wondering if not hiding all functions of a device is feasible at all.
>> >> >> 
>> >> >> For what I understand of PCI, function 0 is always required, so if I only hide function 0, i can't use the other functions in dom0, since those functions would require a function 0, which is hidden.
>> >> >> 
>> >> >> So would it be more logical to drop/ignore the function from the BDF, and always hide all functions from a device ?
>> >> 
>> >> > That might run afoul of the SR-IOV virtual devices. They (when loaded) provide a fake
>> >> > bus:device:function, where the device is port (so if the SR-IOV card has two
>> >> > jacks, you get 00 and 01), and the function is for the amount of VFs it can make.
>> >> > On the Intel SR-IOV NIC with 'igbvf.max_vfs=7' I end up with 14 PCI devices, where
>> >> > the function bear no resemblence to each other (and can be passed in different guests).
>> >> 
>> >> > The PCI restriction I know of is if the device is behind a bridge. The issue here
>> >> > is that .. well, you could pass in a different function to a different guest, but
>> >> > one guest's hardware device could listen on the other guests' function. It would
>> >> > require tweaking the driver to dump the contents of some registers and some deep
>> >> > hacking, but that is the security issue with that.
>> >> 
>> >> Hmm that would mean there are three possibilities:
>> >> 1) Accept a Wildcard syntax like "bus:device.*", which would mean hide all functions of device.
>> 
>> > Which in this context actually makes sense. You probably don't want to use the VF's in
>> > your host.
>> 
>> In my use cases i always hide all functions, and since my usb controllers have 7 functions, that leads to quite some long lines.
>> 
>> >> 2) Accept not providing the function as a wildcard "bus:device", would mean hide all functions of device.
>> 
>> > .
>> >> 
>> >> 3) Do nothing, the gained overview on grub lines isn't worth the effort :-)
>> 
>> > Heh!
>> 
>> > I think I like 2).
>> 
>> I think that would be the most simple and straightforward to implement, the only thing is that the .cfg files seem to use the "bus:device.*" scheme ...
>> Don't know if there are any other related cmd options for the kernel that use a certain syntax that could be preferred ?
>> 

> So Jan implemented this and it is in v3.7.


Yes i saw it :-)
Thx !


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 20:05:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 20:05:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPIoJ-0006yM-Io; Fri, 19 Oct 2012 20:04:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPIoH-0006yE-OP
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 20:04:46 +0000
Received: from [85.158.143.35:2155] by server-2.bemta-4.messagelabs.com id
	5F/86-22268-C52B1805; Fri, 19 Oct 2012 20:04:44 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1350677083!7158955!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13246 invoked from network); 19 Oct 2012 20:04:44 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 20:04:44 -0000
Received: by mail-qa0-f45.google.com with SMTP id s11so360531qaa.11
	for ; Fri, 19 Oct 2012 13:04:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=QRqPKFj7NVcVxJKYustpvN0aHtPl7W22DUShxPKwbdk=;
	b=FCambXumQTPNQkE2pkkCOuat5HDwxvf02/oEOvs7AyMfO/fwvfgY1OIhD10e3/PIs8
	8Ohy1Prclgfk5hsXb1yQVKa/WD2wwqyziaW1xcAuWeatpD2hr81mlf3nKqhWnqK/A1C3
	FrCimjO8JxBpAPByr3GPzkZFjevphtmbFYGhw/WnqYLneF+oZPLlBm168145m4TnnOCW
	/ae2+ThlqF+v+i5rWDfLjiQEZJ6ufNd6kbqRL3zwdJ/96S5A5tmo6Mf3kb7TiJQ/2qj3
	wJDLG4j8tZKRGl8dqPyH745xIc0mjCUX/nldo+tQ6571T/SliHb78tizxpqoykZ5oHdX
	xmGw==
Received: by 10.224.138.143 with SMTP id a15mr1169808qau.64.1350677082664;
	Fri, 19 Oct 2012 13:04:42 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id hw8sm768365qab.9.2012.10.19.13.04.41
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 19 Oct 2012 13:04:42 -0700 (PDT)
Date: Fri, 19 Oct 2012 15:52:36 -0400
From: Konrad Rzeszutek Wilk 
To: Jan Beulich 
Message-ID: <20121019195235.GB20513@phenom.dumpdata.com>
References: <507D6F3D02000078000A1B13@nat28.tlf.novell.com>
	<507D814D02000078000A1B51@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <507D814D02000078000A1B51@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Ian Campbell ,
	Dan Carpenter ,
	xen-devel 
Subject: Re: [Xen-devel] [PATCH,
 v2] linux-2.6.18: fix hypercall fallback code for very old
 hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 16, 2012 at 02:46:21PM +0100, Jan Beulich wrote:
> While copying the argument structures in HYPERVISOR_event_channel_op()
> and HYPERVISOR_physdev_op() into the local variable is sufficiently
> safe even if the actual structure is smaller than the container one,
> copying back eventual output values the same way isn't: This may
> collide with on-stack variables (particularly "rc") which may change
> between the first and second memcpy() (i.e. the second memcpy() could
> discard that change).
> 
> Move the fallback code into out-of-line functions, and handle all of
> the operations known by this old a hypervisor individually: Some don't
> require copying back anything at all, and for the rest use the
> individual argument structures' sizes rather than the container's.
> 
> Reported-by: Dan Carpenter 
> Signed-off-by: Jan Beulich 
> ---
> v2: Reduce #define/#undef usage in HYPERVISOR_physdev_op_compat().

And here is the upstream version.

>From 7e3619ca4049957e1d869dc382c651766a722e3d Mon Sep 17 00:00:00 2001
From: Jan Beulich 
Date: Fri, 19 Oct 2012 15:25:37 -0400
Subject: [PATCH] xen/hypercall: fix hypercall fallback code for very old
 hypervisors

While copying the argument structures in HYPERVISOR_event_channel_op()
and HYPERVISOR_physdev_op() into the local variable is sufficiently
safe even if the actual structure is smaller than the container one,
copying back eventual output values the same way isn't: This may
collide with on-stack variables (particularly "rc") which may change
between the first and second memcpy() (i.e. the second memcpy() could
discard that change).

Move the fallback code into out-of-line functions, and handle all of
the operations known by this old a hypervisor individually: Some don't
require copying back anything at all, and for the rest use the
individual argument structures' sizes rather than the container's.

Reported-by: Dan Carpenter 
Signed-off-by: Jan Beulich 
[v2: Reduce #define/#undef usage in HYPERVISOR_physdev_op_compat().]
Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/include/asm/xen/hypercall.h |   21 +++------
 drivers/xen/Makefile                 |    2 +-
 drivers/xen/fallback.c               |   78 ++++++++++++++++++++++++++++++++++
 3 files changed, 86 insertions(+), 15 deletions(-)
 create mode 100644 drivers/xen/fallback.c

diff --git a/arch/x86/include/asm/xen/hypercall.h b/arch/x86/include/asm/xen/hypercall.h
index 59c226d..c812360 100644
--- a/arch/x86/include/asm/xen/hypercall.h
+++ b/arch/x86/include/asm/xen/hypercall.h
@@ -359,18 +359,14 @@ HYPERVISOR_update_va_mapping(unsigned long va, pte_t new_val,
 		return _hypercall4(int, update_va_mapping, va,
 				   new_val.pte, new_val.pte >> 32, flags);
 }
+int __must_check HYPERVISOR_event_channel_op_compat(int, void *);
 
 static inline int
 HYPERVISOR_event_channel_op(int cmd, void *arg)
 {
 	int rc = _hypercall2(int, event_channel_op, cmd, arg);
-	if (unlikely(rc == -ENOSYS)) {
-		struct evtchn_op op;
-		op.cmd = cmd;
-		memcpy(&op.u, arg, sizeof(op.u));
-		rc = _hypercall1(int, event_channel_op_compat, &op);
-		memcpy(arg, &op.u, sizeof(op.u));
-	}
+	if (unlikely(rc == -ENOSYS))
+		rc = HYPERVISOR_event_channel_op_compat(cmd, arg);
 	return rc;
 }
 
@@ -386,17 +382,14 @@ HYPERVISOR_console_io(int cmd, int count, char *str)
 	return _hypercall3(int, console_io, cmd, count, str);
 }
 
+int __must_check HYPERVISOR_physdev_op_compat(int, void *);
+
 static inline int
 HYPERVISOR_physdev_op(int cmd, void *arg)
 {
 	int rc = _hypercall2(int, physdev_op, cmd, arg);
-	if (unlikely(rc == -ENOSYS)) {
-		struct physdev_op op;
-		op.cmd = cmd;
-		memcpy(&op.u, arg, sizeof(op.u));
-		rc = _hypercall1(int, physdev_op_compat, &op);
-		memcpy(arg, &op.u, sizeof(op.u));
-	}
+	if (unlikely(rc == -ENOSYS))
+		rc = HYPERVISOR_physdev_op_compat(cmd, arg);
 	return rc;
 }
 
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 0e863703..46de6cd 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -2,7 +2,7 @@ ifneq ($(CONFIG_ARM),y)
 obj-y	+= manage.o balloon.o
 obj-$(CONFIG_HOTPLUG_CPU)		+= cpu_hotplug.o
 endif
-obj-y	+= grant-table.o features.o events.o
+obj-y	+= grant-table.o features.o events.o fallback.o
 obj-y	+= xenbus/
 
 nostackp := $(call cc-option, -fno-stack-protector)
diff --git a/drivers/xen/fallback.c b/drivers/xen/fallback.c
new file mode 100644
index 0000000..0bdc468
--- /dev/null
+++ b/drivers/xen/fallback.c
@@ -0,0 +1,78 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+
+int HYPERVISOR_event_channel_op_compat(int cmd, void *arg)
+{
+	struct evtchn_op op;
+	int rc;
+
+	op.cmd = cmd;
+	memcpy(&op.u, arg, sizeof(op.u));
+	rc = _hypercall1(int, event_channel_op_compat, &op);
+
+	switch (cmd) {
+	case EVTCHNOP_close:
+	case EVTCHNOP_send:
+	case EVTCHNOP_bind_vcpu:
+	case EVTCHNOP_unmask:
+		/* no output */
+		break;
+
+#define COPY_BACK(eop) \
+	case EVTCHNOP_##eop: \
+		memcpy(arg, &op.u.eop, sizeof(op.u.eop)); \
+		break
+
+	COPY_BACK(bind_interdomain);
+	COPY_BACK(bind_virq);
+	COPY_BACK(bind_pirq);
+	COPY_BACK(status);
+	COPY_BACK(alloc_unbound);
+	COPY_BACK(bind_ipi);
+#undef COPY_BACK
+
+	default:
+		WARN_ON(rc != -ENOSYS);
+		break;
+	}
+
+	return rc;
+}
+
+int HYPERVISOR_physdev_op_compat(int cmd, void *arg)
+{
+	struct physdev_op op;
+	int rc;
+
+	op.cmd = cmd;
+	memcpy(&op.u, arg, sizeof(op.u));
+	rc = _hypercall1(int, physdev_op_compat, &op);
+
+	switch (cmd) {
+	case PHYSDEVOP_IRQ_UNMASK_NOTIFY:
+	case PHYSDEVOP_set_iopl:
+	case PHYSDEVOP_set_iobitmap:
+	case PHYSDEVOP_apic_write:
+		/* no output */
+		break;
+
+#define COPY_BACK(pop, fld) \
+	case PHYSDEVOP_##pop: \
+		memcpy(arg, &op.u.fld, sizeof(op.u.fld)); \
+		break
+
+	COPY_BACK(irq_status_query, irq_status_query);
+	COPY_BACK(apic_read, apic_op);
+	COPY_BACK(ASSIGN_VECTOR, irq_op);
+#undef COPY_BACK
+
+	default:
+		WARN_ON(rc != -ENOSYS);
+		break;
+	}
+
+	return rc;
+}
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 20:05:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 20:05:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPIoJ-0006yM-Io; Fri, 19 Oct 2012 20:04:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPIoH-0006yE-OP
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 20:04:46 +0000
Received: from [85.158.143.35:2155] by server-2.bemta-4.messagelabs.com id
	5F/86-22268-C52B1805; Fri, 19 Oct 2012 20:04:44 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1350677083!7158955!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13246 invoked from network); 19 Oct 2012 20:04:44 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 20:04:44 -0000
Received: by mail-qa0-f45.google.com with SMTP id s11so360531qaa.11
	for ; Fri, 19 Oct 2012 13:04:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=QRqPKFj7NVcVxJKYustpvN0aHtPl7W22DUShxPKwbdk=;
	b=FCambXumQTPNQkE2pkkCOuat5HDwxvf02/oEOvs7AyMfO/fwvfgY1OIhD10e3/PIs8
	8Ohy1Prclgfk5hsXb1yQVKa/WD2wwqyziaW1xcAuWeatpD2hr81mlf3nKqhWnqK/A1C3
	FrCimjO8JxBpAPByr3GPzkZFjevphtmbFYGhw/WnqYLneF+oZPLlBm168145m4TnnOCW
	/ae2+ThlqF+v+i5rWDfLjiQEZJ6ufNd6kbqRL3zwdJ/96S5A5tmo6Mf3kb7TiJQ/2qj3
	wJDLG4j8tZKRGl8dqPyH745xIc0mjCUX/nldo+tQ6571T/SliHb78tizxpqoykZ5oHdX
	xmGw==
Received: by 10.224.138.143 with SMTP id a15mr1169808qau.64.1350677082664;
	Fri, 19 Oct 2012 13:04:42 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id hw8sm768365qab.9.2012.10.19.13.04.41
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 19 Oct 2012 13:04:42 -0700 (PDT)
Date: Fri, 19 Oct 2012 15:52:36 -0400
From: Konrad Rzeszutek Wilk 
To: Jan Beulich 
Message-ID: <20121019195235.GB20513@phenom.dumpdata.com>
References: <507D6F3D02000078000A1B13@nat28.tlf.novell.com>
	<507D814D02000078000A1B51@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <507D814D02000078000A1B51@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Ian Campbell ,
	Dan Carpenter ,
	xen-devel 
Subject: Re: [Xen-devel] [PATCH,
 v2] linux-2.6.18: fix hypercall fallback code for very old
 hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 16, 2012 at 02:46:21PM +0100, Jan Beulich wrote:
> While copying the argument structures in HYPERVISOR_event_channel_op()
> and HYPERVISOR_physdev_op() into the local variable is sufficiently
> safe even if the actual structure is smaller than the container one,
> copying back eventual output values the same way isn't: This may
> collide with on-stack variables (particularly "rc") which may change
> between the first and second memcpy() (i.e. the second memcpy() could
> discard that change).
> 
> Move the fallback code into out-of-line functions, and handle all of
> the operations known by this old a hypervisor individually: Some don't
> require copying back anything at all, and for the rest use the
> individual argument structures' sizes rather than the container's.
> 
> Reported-by: Dan Carpenter 
> Signed-off-by: Jan Beulich 
> ---
> v2: Reduce #define/#undef usage in HYPERVISOR_physdev_op_compat().

And here is the upstream version.

>From 7e3619ca4049957e1d869dc382c651766a722e3d Mon Sep 17 00:00:00 2001
From: Jan Beulich 
Date: Fri, 19 Oct 2012 15:25:37 -0400
Subject: [PATCH] xen/hypercall: fix hypercall fallback code for very old
 hypervisors

While copying the argument structures in HYPERVISOR_event_channel_op()
and HYPERVISOR_physdev_op() into the local variable is sufficiently
safe even if the actual structure is smaller than the container one,
copying back eventual output values the same way isn't: This may
collide with on-stack variables (particularly "rc") which may change
between the first and second memcpy() (i.e. the second memcpy() could
discard that change).

Move the fallback code into out-of-line functions, and handle all of
the operations known by this old a hypervisor individually: Some don't
require copying back anything at all, and for the rest use the
individual argument structures' sizes rather than the container's.

Reported-by: Dan Carpenter 
Signed-off-by: Jan Beulich 
[v2: Reduce #define/#undef usage in HYPERVISOR_physdev_op_compat().]
Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/include/asm/xen/hypercall.h |   21 +++------
 drivers/xen/Makefile                 |    2 +-
 drivers/xen/fallback.c               |   78 ++++++++++++++++++++++++++++++++++
 3 files changed, 86 insertions(+), 15 deletions(-)
 create mode 100644 drivers/xen/fallback.c

diff --git a/arch/x86/include/asm/xen/hypercall.h b/arch/x86/include/asm/xen/hypercall.h
index 59c226d..c812360 100644
--- a/arch/x86/include/asm/xen/hypercall.h
+++ b/arch/x86/include/asm/xen/hypercall.h
@@ -359,18 +359,14 @@ HYPERVISOR_update_va_mapping(unsigned long va, pte_t new_val,
 		return _hypercall4(int, update_va_mapping, va,
 				   new_val.pte, new_val.pte >> 32, flags);
 }
+int __must_check HYPERVISOR_event_channel_op_compat(int, void *);
 
 static inline int
 HYPERVISOR_event_channel_op(int cmd, void *arg)
 {
 	int rc = _hypercall2(int, event_channel_op, cmd, arg);
-	if (unlikely(rc == -ENOSYS)) {
-		struct evtchn_op op;
-		op.cmd = cmd;
-		memcpy(&op.u, arg, sizeof(op.u));
-		rc = _hypercall1(int, event_channel_op_compat, &op);
-		memcpy(arg, &op.u, sizeof(op.u));
-	}
+	if (unlikely(rc == -ENOSYS))
+		rc = HYPERVISOR_event_channel_op_compat(cmd, arg);
 	return rc;
 }
 
@@ -386,17 +382,14 @@ HYPERVISOR_console_io(int cmd, int count, char *str)
 	return _hypercall3(int, console_io, cmd, count, str);
 }
 
+int __must_check HYPERVISOR_physdev_op_compat(int, void *);
+
 static inline int
 HYPERVISOR_physdev_op(int cmd, void *arg)
 {
 	int rc = _hypercall2(int, physdev_op, cmd, arg);
-	if (unlikely(rc == -ENOSYS)) {
-		struct physdev_op op;
-		op.cmd = cmd;
-		memcpy(&op.u, arg, sizeof(op.u));
-		rc = _hypercall1(int, physdev_op_compat, &op);
-		memcpy(arg, &op.u, sizeof(op.u));
-	}
+	if (unlikely(rc == -ENOSYS))
+		rc = HYPERVISOR_physdev_op_compat(cmd, arg);
 	return rc;
 }
 
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 0e863703..46de6cd 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -2,7 +2,7 @@ ifneq ($(CONFIG_ARM),y)
 obj-y	+= manage.o balloon.o
 obj-$(CONFIG_HOTPLUG_CPU)		+= cpu_hotplug.o
 endif
-obj-y	+= grant-table.o features.o events.o
+obj-y	+= grant-table.o features.o events.o fallback.o
 obj-y	+= xenbus/
 
 nostackp := $(call cc-option, -fno-stack-protector)
diff --git a/drivers/xen/fallback.c b/drivers/xen/fallback.c
new file mode 100644
index 0000000..0bdc468
--- /dev/null
+++ b/drivers/xen/fallback.c
@@ -0,0 +1,78 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+
+int HYPERVISOR_event_channel_op_compat(int cmd, void *arg)
+{
+	struct evtchn_op op;
+	int rc;
+
+	op.cmd = cmd;
+	memcpy(&op.u, arg, sizeof(op.u));
+	rc = _hypercall1(int, event_channel_op_compat, &op);
+
+	switch (cmd) {
+	case EVTCHNOP_close:
+	case EVTCHNOP_send:
+	case EVTCHNOP_bind_vcpu:
+	case EVTCHNOP_unmask:
+		/* no output */
+		break;
+
+#define COPY_BACK(eop) \
+	case EVTCHNOP_##eop: \
+		memcpy(arg, &op.u.eop, sizeof(op.u.eop)); \
+		break
+
+	COPY_BACK(bind_interdomain);
+	COPY_BACK(bind_virq);
+	COPY_BACK(bind_pirq);
+	COPY_BACK(status);
+	COPY_BACK(alloc_unbound);
+	COPY_BACK(bind_ipi);
+#undef COPY_BACK
+
+	default:
+		WARN_ON(rc != -ENOSYS);
+		break;
+	}
+
+	return rc;
+}
+
+int HYPERVISOR_physdev_op_compat(int cmd, void *arg)
+{
+	struct physdev_op op;
+	int rc;
+
+	op.cmd = cmd;
+	memcpy(&op.u, arg, sizeof(op.u));
+	rc = _hypercall1(int, physdev_op_compat, &op);
+
+	switch (cmd) {
+	case PHYSDEVOP_IRQ_UNMASK_NOTIFY:
+	case PHYSDEVOP_set_iopl:
+	case PHYSDEVOP_set_iobitmap:
+	case PHYSDEVOP_apic_write:
+		/* no output */
+		break;
+
+#define COPY_BACK(pop, fld) \
+	case PHYSDEVOP_##pop: \
+		memcpy(arg, &op.u.fld, sizeof(op.u.fld)); \
+		break
+
+	COPY_BACK(irq_status_query, irq_status_query);
+	COPY_BACK(apic_read, apic_op);
+	COPY_BACK(ASSIGN_VECTOR, irq_op);
+#undef COPY_BACK
+
+	default:
+		WARN_ON(rc != -ENOSYS);
+		break;
+	}
+
+	return rc;
+}
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 20:13:57 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 20:13:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPIwv-000783-OG; Fri, 19 Oct 2012 20:13:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPIwt-00077y-3b
	for xen-devel@lists.xensource.com; Fri, 19 Oct 2012 20:13:40 +0000
Received: from [85.158.138.51:26800] by server-1.bemta-3.messagelabs.com id
	E9/F5-31728-274B1805; Fri, 19 Oct 2012 20:13:38 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1350677611!33283098!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMzMTM2Mg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1495 invoked from network); 19 Oct 2012 20:13:32 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-15.tower-174.messagelabs.com with SMTP;
	19 Oct 2012 20:13:32 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 19 Oct 2012 13:13:30 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,615,1344236400"; 
	d="pdf'?scan'208";a="236127249"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by fmsmga001.fm.intel.com with ESMTP; 19 Oct 2012 13:13:30 -0700
Received: from fmsmsx152.amr.corp.intel.com (10.19.17.221) by
	FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 19 Oct 2012 13:13:29 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	fmsmsx152.amr.corp.intel.com (10.19.17.221) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 19 Oct 2012 13:13:28 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.123]) with mapi id
	14.01.0355.002; Sat, 20 Oct 2012 04:13:26 +0800
From: "Liu, Jinsong" 
To: Ian Jackson 
Thread-Topic: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration when
	vMCE	occur
Thread-Index: AQHNrglhllpCBVDw6Ui6h+f8GVa/apfA6fPQ
Date: Fri, 19 Oct 2012 20:13:25 +0000
Message-ID: 
References: 
	<20609.26910.2416.305293@mariner.uk.xensource.com>
In-Reply-To: <20609.26910.2416.305293@mariner.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC82923353610F0SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration when
	vMCE	occur
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC82923353610F0SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Ian Jackson wrote:
> Liu, Jinsong writes ("[Xen-devel] [PATCH 4/5] Xen/MCE: Abort live
> migration when vMCE occur"):=20
>> This patch monitor the critical area of live migration (from vMCE
>> point of view, the copypages stage of migration is the critical area
>> while other areas are not).
>=20
> Sorry for the delay reviewing this.
>=20
> Just to be clear, can you explain what a vMCE is ?  I think I know but
> I'm not entirely sure and it would be helpful if you'd confirm, as I
> seem to have missed the background here.  I couldn't easily find the
> 0/5 posting of your series (in part because the tool you're using to
> send your series doesn't link the messages together in the same
> thread).
>=20

vMCE is a virtual MCE interface to guest. Its general purpose is to emulate=
 a well defined interface to guest, so that when MCE occur in the range of =
guest, hypervisor can filter/expose necessary MCE error information to gues=
t which would continue handle it.

These vMCE series patches is used to replace old xen vMCE implement, since =
old vMCE has some issues, including
1). old vMCE bound to host MCE, which would bring troubles like non-arch is=
sue, save/restore issue, etc;
2). weird per-domain msr semantic
3). questionable vMCE injection method

I don't know if I have introduced it clear, but we have the Xen vMCE design=
 doc as attached, including many vMCE details.

>> If a vMCE occur at the critical area of live migration, there is
>> risk that error data may be copied to the target. Currently we don't
>> have convenient way to handle this case, so for the sake of safe, we
>> abort it and try migration later (at that time broken page would not
>> be mapped and copied to the target).
>=20
> The "error data" that you refer to is erroneous page contents, or
> something else ?

Yes, it's erroneous page contents.

>=20
> When you say "we abort it and try migration later", that's not
> actually implemented in your patch, is it ?  What actually happens is
> that the migration is aborted and the user is expected to retry later.

Yes, and to make it more accurate how about update as "... we abort it. Use=
r can try migration later (at that time the broken page would not be mapped=
 and copied to the target)"?

>=20
> I think this situation deserves a specific error code at the very
> least.  That specific error code should be plumbed up to libxl.
>=20
> Wouldn't it be better to actually restart the migration somehow ?

Seems libxl save/restore changed greatly recently, and I know almost nothin=
g about the new save helper mechanism (I spend some time to study it but st=
ill not quite clear).
Maybe to achieve 'restart migration' is some overkilled/complicated for vMC=
E itself? after all mce during migration rarely occur in real life, and the=
 main target of this patch is only for the sake of safe, so 'abort migratio=
n' is an acceptable option?

>=20
> I have some more minor comments about the implementation:
>=20
>> @@ -1109,6 +1111,12 @@
>>          goto out;
>>      }
>>=20
>> +    if ( xc_domain_vmce_monitor_start(xch, dom) )
>> +    {
>> +        PERROR("Error when start vmce monitor\n");
>=20
> "Error starting vmc monitor" would be better English.  Messages sent
> with PERROR should not have a \n.
>=20
>> +    vmce_while_monitor =3D xc_domain_vmce_monitor_end(xch, dom);
>> +    if ( vmce_while_monitor < 0 )
>> +    {
>> +        PERROR("Error when end vmce monitor\n");
>=20
> Grammar and \n again.
>=20
>> +    else if ( vmce_while_monitor > 0 )
>> +    {
>> +        fprintf(stderr, "vMCE occurred, abort this time and try
>> later.\n"); +        goto out;
>=20
> This message should be sent with one of the logging macros, not
> fprintf.  ERROR, probably.
>=20
> Ian.

Will update accordingly.

Thanks,
Jinsong


--_002_DE8DF0795D48FD4CA783C40EC82923353610F0SHSMSX101ccrcorpi_
Content-Type: application/pdf; name="xen vMCE design (v0 2).pdf"
Content-Description: xen vMCE design (v0 2).pdf
Content-Disposition: attachment; filename="xen vMCE design (v0 2).pdf";
	size=256622; creation-date="Wed, 27 Jun 2012 03:21:05 GMT";
	modification-date="Wed, 27 Jun 2012 03:18:50 GMT"
Content-Transfer-Encoding: base64

JVBERi0xLjUNCiW1tbW1DQoxIDAgb2JqDQo8PC9UeXBlL0NhdGFsb2cvUGFnZXMgMiAwIFIvTGFu
Zyhlbi1VUykgL1N0cnVjdFRyZWVSb290IDc4IDAgUi9NYXJrSW5mbzw8L01hcmtlZCB0cnVlPj4+
Pg0KZW5kb2JqDQoyIDAgb2JqDQo8PC9UeXBlL1BhZ2VzL0NvdW50IDE0L0tpZHNbIDMgMCBSIDE0
IDAgUiA0MSAwIFIgNTQgMCBSIDU2IDAgUiA1OCAwIFIgNjAgMCBSIDYyIDAgUiA2NSAwIFIgNjcg
MCBSIDY5IDAgUiA3MSAwIFIgNzMgMCBSIDc1IDAgUl0gPj4NCmVuZG9iag0KMyAwIG9iag0KPDwv
VHlwZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8PC9YT2JqZWN0PDwvSW1hZ2U1IDUgMCBS
L0ltYWdlNiA2IDAgUi9JbWFnZTcgNyAwIFIvSW1hZ2U4IDggMCBSPj4vRm9udDw8L0YxIDkgMCBS
L0YyIDEyIDAgUj4+L0V4dEdTdGF0ZTw8L0dTMTEgMTEgMCBSPj4vUHJvY1NldFsvUERGL1RleHQv
SW1hZ2VCL0ltYWdlQy9JbWFnZUldID4+L01lZGlhQm94WyAwIDAgNzIwIDU0MF0gL0NvbnRlbnRz
IDQgMCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9U
YWJzL1MvU3RydWN0UGFyZW50cyAwPj4NCmVuZG9iag0KNCAwIG9iag0KPDwvRmlsdGVyL0ZsYXRl
RGVjb2RlL0xlbmd0aCA2NDA+Pg0Kc3RyZWFtDQp4nKWU32/aMBDH3yPlf7hHpyqOzz9jCVVdoauK
WqnbkLqp2gNqKU0FQStj0/77nU0oBAJ72EOc5GLf9/s5nwP5HXS7+W3vug/i7Awu+j34kSYCBBdC
oJTCgZMCjBbwNk6T+xOo6DMXCjXNUc7SaI2Ht8n7KiEsCt1Y9nySJp/SBC5vewBbkrgn2bJ4penQ
c2eApoFR60cuDS2Ax1ma5Nez0WRsoD+HNiW5UerUQgK9qzkLhdiiacRaUnuO0oBCXlDEx0VbsvaQ
rNqXNQb9cVntiGtFasBGYR1ItxXdIUW9r2gLbVeKUmtsKy4K9V5cERGt8MGEi+ob2eKQrMlvRtUE
2OuoM7jLag8XQ1r3EaHgtKXDZ9KJEkgiiheK4tpJGM5CR1lfAPVQfvWFajJZrENXafLAZNbRTIQB
wxBfc5vT3TCXfYfhIE0uhy2u7JaRd21juJRb2g8MjuVwh8jWCbVDTsek4MqsE+KxhEVrDrsqyCbH
UVO+UWEJSu6WWKLhgj4o6mFf17j91O6HP8eqfx1XkGn267Z3Cf3xopxkilVbphr+PflvqP0DAMUO
Adn1xQ4C9aA3gB65UnXSmzIzbHmaWUrfQcMG9FqSy2pBD3PaJ4pq1n0tKwou5mGccBqmdJVZR7Hl
+fqp+klZxlMeuulxHnppdnYAz5AT3TRynA5b6GwDDh39xOhmNdemzjmI1hSjfjslECnYt2X1sqH6
EwGqF5pGQf5ajiLfeRkQCEezccCYhmmc8jyGOJF5NqO3g3D0OzW66eQ4nWzpYCld5FGOG1dn+bCc
0q48RRZk9zRGvGl9Ubhg3d+74eB8tAwb9vSfZJo2jM5Tw9Me2V+R5XLyDQplbmRzdHJlYW0NCmVu
ZG9iag0KNSAwIG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvV2lkdGggMTAyNC9I
ZWlnaHQgNzY4L0NvbG9yU3BhY2UvRGV2aWNlUkdCL0JpdHNQZXJDb21wb25lbnQgOC9GaWx0ZXIv
RENURGVjb2RlL0ludGVycG9sYXRlIHRydWUvTGVuZ3RoIDE4NzExPj4NCnN0cmVhbQ0K/9j/4AAQ
SkZJRgABAQEAAAAAAAD/7AARRHVja3kAAQAEAAAAZAAA/9sAQwAIBgYHBgUIBwcHCQkICgwUDQwL
CwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04MjwuMzQy/9sAQwEJCQkMCwwY
DQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy
/8AAEQgDAAQAAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQ
AAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYX
GBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqS
k5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz
9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQE
AAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1
Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKj
pKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwD
AQACEQMRAD8A9/ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigDxD/hcfiH/nz0v/
AL9Sf/F0f8Lj8Q/8+el/9+pP/i688or6X6pQ/lR839br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPx
D/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi
688oo+qUP5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/z
M9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcfiH/n
z0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH/C4/
EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/36k/+
Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH
1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/AOFx+If+
fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/AL9Sf/F0
f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH/C4/EP8Az56X/wB+
pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6pQ/lQ
fW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9D/4X
H4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/AOFx+If+fPS/+/Un/wAX
R/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8+el/
9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH/C4/EP8Az56X/wB+pP8A4uvPKKPq
lD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDh
cfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L/wC/
Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/AM+e
l/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i688oo+
qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH/C4/EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br/wAz
PQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1
J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP
/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLr
zyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz
0P8A4XH4h/589L/79Sf/ABdH/C4/EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fP
S/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q
/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4u
vPKKPqlD+VB9br/zM9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW
6/8AMz0P/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/58
9L/79Sf/ABdH/C4/EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/
wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k
/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9
br/zM9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcf
iH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH
/C4/EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/3
6k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qU
P5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/AOFx
+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/AL9S
f/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH/C4/EP8Az56X
/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6p
Q/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9
D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/AOFx+If+fPS/+/Un
/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8
+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH/C4/EP8Az56X/wB+pP8A4uvP
KKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ
/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L
/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/
AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i68
8oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH/C4/EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br
/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0
v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C
4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zMKKKK6DnCiiigAoPAopD0oA27uLR7BoYZbK6mkaGORnF
wFBLDPAxUH2nQ/8AoGXf/gV/9jRr3/H7B/16Q/8AoAqna2FzeJNJDC7QwKHmkVciNc4yfasopct2
/wATVt81kvwLn2nQ/wDoGXf/AIFf/Y0n2rQ/+gZd59rr/wCxqVL3RtPH+j6edQmH/La8Yqn4Iv8A
U1ZbxbrdsQkS21iCAVSKyROPxGTSs3svvZSaW7+5XKP2rQx10y7H/b0P/iaVU0e8bZG1xYyn7rTM
JIyfcgZH1rWsPE/iTUpZIhDbakI4zJJFNaxt8g6k8A0/UNIsNX0O41bTbQ2F3aKr3diG3IY26SJ3
A9qnm5XaWnzuVy8yvHX5WOYuraazuZLedNkqHBGc/iD3FRVpXjfaNC0+4c5ljZ7fd3KjBX8skVm1
vF3WpzyST0CiiimIKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo
oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii
igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK
ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKOldZa6BoekwR3XiXUt0joHTT7I75CD
yNzdF+lROahuXCDnscrFFJPKIoY3kkPREUsT+ArqNN+HPibUlDiw+zRn+O5YJx9OtW2+IR02MweG
tGtNMi6eYy+ZKfqa56/8Sa3qjE3mqXUoPVfMIX8hxWTdaWyS9dX/AF8zRKjHdt+mh1y/DCG2XOqe
J9PtiOqqQSPzIpw8F+Co+JvGSs3+yV/+vXnRAJyeT6mjA9BR7Gq96j+5Fe2pLamvvZ6UvgLwjdfL
aeMY9/YOyf4iorr4Raj5Rl0zVLO9TsM7SfxGRXnW0HsKt2OqX2mTCSxvZ7Zwesbkfp0NS6VZfDP7
0Cq0X8UPuZPq2g6poc3l6lZS25PRmGVb6MODWdXqnhr4kQ6qF0bxVDDLFN8guCo2k9t47fUVheP/
AAQPDU631hubTJ2wATkxN6Z7g9jRTxEuf2dVWfTsx1KEeT2lJ3XXujiKKKK6jlCiiigAooooAKKK
KACiiigApD0paQ9KBG/dWDap4j02wQ4a4ht48+mVGT/OtqzW1v4PFXlxlLextBHaqrFcKHxk4PzE
9Tn1rIl1D+yfFGlaht3C3it5CvqAoz+ma1dY0DVrFrzUvDrSXmi6kpJe3G8hCclHXqCDXHPom7bW
+/U7YLdpX7/cbOoaHoD3F/pEeiwwyQaSL1LuOVt+/bnGCcYq5f6bp2ta/aRX1pERY6LHdM7SMBNx
gK2Oijk8c8157Lr2vfbZriSSYXEtt9lkJhxmLGNuMVbstW8X3MliLM30r2a7ICkGSFIxtJxyPrWb
oVEk+b8WWq8G2uX8Dr9LtdGi1WS40p7ZZZtIuftMFq7PGjADBUtzg1z+jW8nh/wVq2qX4MTanCLW
zhf70gJyXx6CtiPw94vvphq2u6pDpMUcLRF5NinyyPmUKOOfevPb7ULvUZEa7uZJzEgjj3HhUHAA
HYU6UOdtKV9r9dvMVWfIk3G29um/kTyceGrb/r6k/wDQRWfWjJ/yLVt/19Sf+gis6u2PU459Aooo
qiQooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK
ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA
KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo
oooAKKKKACiiigAooooAKKKKACtHTNEvNVt7y5hULbWcRkmmc4VcdF+p9KrWFlPqWoW9lbLumnkE
aD3Ndl47uIdFtbXwjppxb2qiS7cdZpTzz/P8ayqVGpKEd3+RrTppxc5bL8xNMt/Bj+BZJb2WAa75
UhVTIwbdzt46elcLkDqea9e0DSdOm+EM15JY273It5iJWjBYEE4OaX4X6bplx4Qu7q8sLe5aOdzu
kiDNgKDjmuRYlU1OWrs7f8MdTw7qOEdFdX/4c8g3D1FbnhTw9/wk+urppuTb7o2fzAu7p2xXp/h7
WvCHi7UJNLi8OxxOYy/7yBACB15HTrWP4Y0eLQfjFcafbk+RHC7RgnJClQcfhVSxbcZRs4ySuTHC
pSjK/NFuxwvijQh4b1+bSxcG48tVbzCu3ORnpWMSB1Net/EfVNMvL6Xw/DpedYmeJVuti9yMDPWr
t1B4W+GumWqXWni+v5xyxQMzkdTzwBRDFyVON4tyf4+Y54VOcrSSivw8jxgEEcV6tp3h/SJPhFJq
b6fA16LaRhOV+bIJwc1N4j0HRPFng1/Eeh2q21zCjOVVNm4L95WA4z71c0r/AJIdL/16Sf8AoRrO
tiPaQi46PmSZpRw/s5yT1Ti2jy2W80pvDUVqlnjUQ+Wmx1H1r1bQpT4q+Ec8F388sUMkW48klBlT
/KvEhwo+le3eHIT4Z+EtxcXQKPLDJOVPBBcYUfyqsalGMbb30IwcnKUr7W1PER0FLSDpzS16BwBR
RRQAUUUUAFFFFABRRRQAUHpRQehoEbWtWjS3Vu4ns1zaQ8SXUaMPlHUEg0aTqGr6HIX03WLW3z95
Vv4irfUFsVwXj8f8VKv/AF6Qf+ixWFdaTf2NvDcXVpLDFMMxs64DV4k8fNXhyppHuQwEHafM02e/
J8RvE6rh7zQ5T/eeaHP/AKFUNz8QfFlwpVdX0qAH/njcQA/mWNeBx2F1LaG6SB2gEgj3gcFiM4Hv
iq+OeawWKX8kfuN3hW/ty+89fvpdR1OQyX+r21y/rLqMTY/Ddiqn2Fs/8fWn/wDgdF/8VXleKOK2
WZVFokv6+Zi8tpt3cn/XyPYbqEw+HLVTJC+bqTmGZZB90d1JrKqn4Z/5ExP+v5//AEAVcr1cLUdS
kpvqeXiqap1XBdAooorc5wooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAO5+E9mtz4zEzjP2aBpF+p4/qa5nxFcvd
+JdTnkJLNcvn8CQP5V0vwovVtfGixOQBcwPGPqMEfyNZnj3RpNG8XXqMuIrhzPC3YqxyfyOa5Iu2
Kkn2Vjqkr4ZNd3c9E8OH/iys/wD17z/zNR/Cz/kQdS/66S/+gCvO9J8ZajpWg3miqkc1ncoy7X4M
ZYYJB/pVnw746vfDmiz6Zb2cEsczMzO7EEZGO1YVMLUcZpdZXOiGJpqUG+isaHwk/wCR3P8A17Sf
zFdVbHHx3uc/8+p/9AFeZ+GfEU/hjVzqNvBHNIY2j2SEgYOPT6VLf+K9QvPFP/CQRBLW8BUqI+VG
Bjv1BFa1cPOdWTWzjYypV4QpRi91K51vi+Oax+LNtqU8Eq2aywMZih2Y6deldv431y80SO2ubfQY
9UgcFXcjcYz24APBrzDX/iPqPiLQ5NLurK1RJCpaSMtnIOehqfQvinrOj2SWk8MV9FGNqNISrgdh
kdawlhqsowcopuOlr7o3jiaUZSSk7S1vbY3b3x9ra+HJpn8JrbWE4aHzdxUAsMZxj9a0tJIPwOlw
c4tJR/48a4nxH8SdX8Q2T2PlQ2drIMSJH8zOPQk9vpWZpXifV7XR7nQLVftFtdgoIdhZlJ6lcVX1
WTgtEndPcj6zHneras1sdN8P/h82qi31rVNo08HfFDnJlIPU+i8fjT/id4xh1ORdD02QPaQNmeRf
uu46KPYVy0ni/WF8PwaDDN9mtIFKMIuHfkkhj/hWBW8aEpVfa1XtsjGVeMaXs6a33YUUUV1nIFFF
FABRRRQAUUUUAFFFFABQehooPT8KAOb8f8eJl/69IP8A0AVrxappEkVvc3t/ZvrDQmOO5WFmRfkA
VpVIxuGMAgGl8WeF9W1jWEvLC3jmga2hUOJ0HIQAjBOaw/8AhBPEf/Pin/gRH/8AFV8xUhLnenU+
npzjyLXodHF4usba/sI7a8jjt4r8yOVtwFAMSqzgY4BfccehqG21TwubWF74W0l/5ZkkkEBwJIid
ijAwRJkZ47Vhf8IJ4i/58U/8CY//AIqj/hBPEX/Pin/gRH/8VWfJLsXzx7o3n1vQ7bRP3E8Mt8sD
i3kaAF0JVeCNoA53AdfWsvxVqmlXumWsenpbYyjLtXbJF8gDKflAwWyepqr/AMIJ4i/58U/8CY//
AIqj/hBPEf8Az4p/4ER//FUckuwc8e6Nzwz/AMiYn/X8/wD6AKuUabpd3o/heK1vkWOdrt3CCRWO
3aBngmivocEmqEU/P8z5/HNOvK3l+QUUUV1HKFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBNZ3c1hewXdu22aBw
6H0Ir3CJ9D+KPhtFmPlXkQ+YL/rIHxyR6qa8JqxY393pl4l3Y3EkE6dHQ4/A+ormxGH9raUXaS2Z
0Yev7O6krxe6Om1v4b+INHdmjtzfW46S24yce69RXKSwywOUmikiYdVkUqf1r0/RfjHNEqxa1Yeb
jgz25wfxU/0NdZB4/wDB2qqBPdQqT1W6hx/MEVz/AFjE09KkL+aOj6vh6mtOdvJngG4eoo3D1FfQ
4uPAtz827RGz6iMU8Xfgi2G4SaImO4EdDzB/yMf1Bfzo+eoYJrhtsMMkh9EQt/Kt3T/AviXUyPJ0
qaNT/HP+7H617LL468H6evyajajH8MEZP8hWHf8Axi0WEEWVnd3TdiwEY/Wl9bxE/gp/f/SD6rQh
8dQydI+DcjFX1jUQq94rYcn/AIEa7eDTfC/gexaYLb2Y24M0pzI34nk/QV5fqvxY8QXytHZrBYRn
vGN7/mf8K4u7vbrUJzPeXMtxKeryuWNL6tiK38aVl2Q/rOHo/wAKN33Yy4YPczOpyrOzA+xNR0UV
6Z5oUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAmB6UYHpS0UAJgelGB6UtFACYHpRgelLRQAmAKWii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAEwPQUbR6ClooAKKKKACiiigAooooAKKKKACi
iigAooooA//ZDQplbmRzdHJlYW0NCmVuZG9iag0KNiAwIG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1
YnR5cGUvSW1hZ2UvV2lkdGggNzIvSGVpZ2h0IDcwL0NvbG9yU3BhY2UvRGV2aWNlUkdCL0JpdHNQ
ZXJDb21wb25lbnQgOC9GaWx0ZXIvRENURGVjb2RlL0ludGVycG9sYXRlIHRydWUvTGVuZ3RoIDcy
OT4+DQpzdHJlYW0NCv/Y/+AAEEpGSUYAAQEBAEgASAAA/9sAQwAIBgYHBgUIBwcHCQkICgwUDQwL
CwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04MjwuMzQy/9sAQwEJCQkMCwwY
DQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy
/8AAEQgARgBIAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQ
AAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYX
GBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqS
k5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz
9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQE
AAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1
Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKj
pKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwD
AQACEQMRAD8A4yiiivrT5MKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC
iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA//
2Q0KZW5kc3RyZWFtDQplbmRvYmoNCjcgMCBvYmoNCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0lt
YWdlL1dpZHRoIDk5L0hlaWdodCAxMTUvQ29sb3JTcGFjZS9EZXZpY2VSR0IvQml0c1BlckNvbXBv
bmVudCA4L0ZpbHRlci9EQ1REZWNvZGUvSW50ZXJwb2xhdGUgdHJ1ZS9MZW5ndGggNDQ5Nz4+DQpz
dHJlYW0NCv/Y/+AAEEpGSUYAAQEBAEgASAAA/9sAQwAIBgYHBgUIBwcHCQkICgwUDQwLCwwZEhMP
FB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEc
ITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgA
cwBjAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMC
BAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYn
KCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeY
mZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5
+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwAB
AgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpD
REVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ip
qrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMR
AD8Aq2jaZpvhCzv7jRba/uLi7liLTSOu1VVSMbSPU1W/4SHSP+hR03/v/N/8VRef8k/0r/sIXH/o
KVz1fTQgpXbvu+rPmpzcbJW2XRdjov8AhIdI/wChR03/AL/zf/FUf8JDpH/Qo6b/AN/5v/iq52ir
9lHz+9/5ke1l5fcv8jov+Eh0j/oUdN/7/wA3/wAVR/wkOkf9Cjpv/f8Am/8Aiq5+OOSaRY4keSRu
AiKST+Arp7L4eeI7uITTWsdjB/z0vZRGPy6/pUTVKHxO3zf+ZcJVZ/Cr/Jf5EH/CQ6R/0KOm/wDf
+b/4qj/hIdI/6FHTf+/83/xVaf8AwhOiWpxqPjTTY2HVbdfMx+OalHhrwL0PjNyfUWxx/Ks+el0v
/wCTGnJV62/8lMf/AISHSP8AoUdN/wC/83/xVH9v6K3EnhGw299lzMp/Pca208BaJqB26T4ysZZD
0SZdhP6/0rH1vwF4g0KNpp7Pz7ZRkz2x3qB6kdR+VOM6Ena7v5tr8xShWir2VvJJglj4d1s+Xp1x
NpV633IL5w8Mh9BIACp/3h+NYd9Y3Wm3klpeQPDcRnDI45H+I96rdR7V1NnK3ifQpdOuDv1PToTN
ZSn70kS8vET3wPmH0IrV3p63uvyMlappaz/M5eiiitTI6C8/5J/pX/YQuP8A0FK56uhvP+Sf6V/2
ELj/ANBSufVSzBVBLE4AA5JrOls/V/maVd16L8hACSAASScACtKxtbKC7P8Abi3sECpuWOKLDynP
3QW4A9+a1dS0eHw//Ztk37zXpJY5pgW+S3B+7GfUnIJPatrx3aeItX8S6TY6rFYRXc6eXALd2KHL
fxE9OazdZNpLZ319OxaotJt7q2nr3MY+NZ7GJrfw9YW2kQkYLxr5k7D/AGpG5/LFc/eX95qEplvb
ue4cnJaWQt/Ou0/4VF4m/vWH/f4//E1X8K+HJbD4jWmka3ZRscOWikAdHGwkEdiKmNWhFOUGm0r+
ZcqddtRndJu3kcUAO1LXdfEPwhc6VrL31tbwJY3cyxW0EH3t20cbQO5BpIPhP4mmsxOy2sTkZELy
/P8AQ4GAfxq1iaXIpt2uQ8NV53FK9jjbSwutRn8iztZbibBbZEhY4HfArpfDnivxF4XupIgtxPaQ
HFzaTAkIO/X7prV+GFncaf8AEKS0u4WhuIreRXRhyDxWD4qvri28Wa/DFJtjmunEgx1GamUlUm6T
SatcqMXTgqqbTvY6Tx14d06+0SDxfoKBLWfBuIlGApJxux2IPBFch4UuTa+LNKlHT7SiMPVWO0j8
ia77wdmb4Q6/Hccwr52zP+4D/OvOdA/5GLS/+vuL/wBDFRRb5J03ra6+RdZLnhUWl7P5kOpQLaar
eW6/dindB9AxFFTa7/yMOpf9fUv/AKGaK646xTOSWkmaN5/yT/Sv+whcf+gpV74a6bFf+Lo5rhd0
NjE1ywPcr0/U5/CqN5/yT/Sv+whcf+gpW78JJY/+Enu7SQ4+1Wbov4EE/pmuWq2qE2vP8zqpJOvB
Py/I5WS/l1TxSL6ZiZLi8WQ/i4wPyr1Lxx/yU7wp/vL/AOh15Nf2lxousz2soKT2sxHPqDkH+Rrp
tW8eDWPEWiaxNYlJNPx5qK/EhDZ+X0/GlVpOUoyhtZ/itApVFGMoz3uvwept+Prq5h+KOnrFcSxr
/o/COQPvntXTa0B/wuPw+ccmzfP/AI/XmXiTxXFr3i221pLR4Uh8vMTOCTsbPWr+vfEB9R8Wabr1
haNbyWUezy5X3B+TkcdiDisfq9RxirfZaN/rEFKTv9pM6OELc/HaWKd2aONi8aMxIDCIYIFWtbuP
Dlr43k1C98Vahb31tKpNuEOxAAPl6dCP51yniHx/Bqt1Zajp2krYapbzCVrnIYvgY2ngEj61qP8A
ErQb6SO81TwpFPqKAfvAVIJHTkjP55qXRq+7Lle1tLf1qUq1P3o8y3vrf+tDe0vV9K1z4sw32kzC
ZG05llYKV+YN7+2K8/1nRr7XviJqtjp8DSyvePk4+VBnqx7CmQ+NJ7Txm/iO2sLaAvkPbJwrKRg5
PqeufWr9n8QrzSLrWrqzsFjuNVmEyNKciIc9Bj5uv0rWNGpTd4LolqzKVWnUVpvq3odH41ubTwf4
HtvCVlKHup1BnYdducsx/wB48D2rzbQP+Rj0z/r7i/8AQxVW7vLi/u5bq7mea4lbc8jnJJq1oH/I
x6Z/19xf+hit6dL2VNpu7d2/UwqVfaVE0rJWS9A13/kYdS/6+pf/AEM0Ua7/AMjDqX/X1L/6GaK3
h8KMJ/EzRvP+Sf6V/wBhC4/9BSsnS9RuNI1O31C1bbPA4dc9D6g+xHFa15/yT/Sv+whcf+gpXPVn
TScWn3f5mlRtSTXZfke0XWmaB8U9OS/s5xZ6vGgWQdWHs6/xD0Yf/Wrg9T+G/ifTXbGnm7jHSS2Y
Pn8Ov6VzFrdXFlcJcWs8kE6HKyRsVYfiK7jS/i34hsUWO7S3vlH8Ui7H/Nf8K5/ZV6OlJ3XZnR7W
hW1qqz7o4+XRtVgJE2mXiEf3oGH9KbHpWpSnEenXbn/ZgY/0r1OH41QFR5+iTBu/lzgj9QKkb41W
OPl0a6J95VFL2+J/59/iHsMN/wA/PwPOrTwX4lvSBDot3g95E2D82xXTab8H9buSrX9zbWadwD5j
/px+taF18ablhi00WJD6zTlv0AFc5qPxO8UagCq3iWiHtbRhT/30cmi+MnslEdsJDq5Hodp4H8H+
EYVvNVmjmkXkSXrjGf8AZTv+teYeOtZstd8UTXmnbjaiNI0LLtztGOB6VgXFzcXkxmup5Z5T1eVy
x/M1FWlHDuEuecm2ZVsQpx5IRsgrQ0D/AJGPTP8Ar7i/9DFZ9aGgf8jHpn/X3F/6GK6J/CzCHxIN
d/5GHUv+vqX/ANDNFGu/8jDqX/X1L/6GaKcPhQp/EzTu9W0PSvh/pba3b6hMkl/cCL7E6KQQqZzu
H0rnv+Ev8B/9A/xF/wB/4f8ACmeOP+ScaD/2Ebr/ANBjrzSvBr4mrCrKMZWVz3aGHpTpRlKN3Y9O
/wCEv8B/9A/xF/3/AIf8KP8AhL/Af/QP8Rf9/wCH/CvMaKy+uV/5jX6pQ/lPTv8AhL/Af/QP8Rf9
/wCH/Cj/AIS/wH/0D/EX/f8Ah/wrzGij65X/AJg+qUP5T07/AIS/wH/0D/EX/f8Ah/wo/wCEv8B/
9A/xF/3/AIf8K8xoo+uV/wCYPqlD+U9O/wCEv8B/9A/xF/3/AIf8KP8AhL/Af/QP8Rf9/wCH/CvM
aKPrlf8AmD6pQ/lPTv8AhL/Af/QP8Rf9/wCH/CtDQfFfgmbxFpkVvYa+Jnu4ljMk0JUMXGM4HTNe
Q1r+FP8AkcdE/wCv+D/0YtJ4uu18Q1hKCfwnouu/8jDqX/X1L/6GaKNe/wCRh1P/AK+pf/QzRX0k
PhR87P4mZ3jj/knGg/8AYRuv/QY680r0vxx/yTjQf+wjdf8AoMdeaV83iv40vU+iwv8ABj6Hfa54
c8I+GZE0zU59dfUWtUm+1QJF9nZnQMNqnll5xnPY1zmleDvEWuWMl7pmj3d1bISDJGmQSOoH94+w
zXovhXRfE9xaxaH4v0V5vCwhZ1vrrH+gLtJEkU2eB0+XJB6Yqo2j63rum+Brnw1HPPaWUPlSSQNh
bacTMzM/9zIKtk9RXOdBj+E/h/LqvhvVNdvtN1G4htwq20NrIkZkYkhySwOAu3kY5qldfDTxHbeG
rLWhZSPHdSFfKUAtGMqEJOedxbAx6V0WuXdrd6V8SrmwkVraXVbZo2jOFYGSTkexrLuYL9/hP4dv
rGCaWOw1C7eeSJSywnMRUvj7uccZoA4qbT7y3uLmCW2lWW1YrOpQ5jIOCG9OeKu2XhfXNRezSz0u
5ma9R5LfYn+sVThmHsDxmvabuS207V3RyiQeObrLdOYXtwAf+/03/jtc9daDDeeIodAuori4n8P+
Ho8adbS+W91cHDvGDgnrISQBn5aAPPZvB3iO31qLR5dGuxqEy74oBHkuv94Y4I4PPtUw8CeKG1Zt
LXRblr1YhM0agHahOASQcAZHc16tZxtbw+GI30qfSHTS9ZAtJ3dnQeXkHL/Ng8kVyfgWOLUfh7rm
nR6Xdardm+gmksrS58qZ4grDdwpLqGPIA7g0Aee6lpl9o99JY6jay2t1GfnilXawq74U/wCRx0T/
AK/4P/Ri1tfEK6u5b3SrW80SfSXs7FYEiuLjzpWQMxUucAjrjBHQCsXwp/yOOif9f8H/AKMWgD0X
Xv8AkYdT/wCvqX/0M0Ua9/yMOp/9fUv/AKGaK+sh8KPlJ/EzO8cf8k40H/sI3X/oMdeaV6j4xtLm
7+HOhC2tppiuo3WfLjLY+WPrivO/7G1T/oG3n/fhv8K+bxX8aXqfR4X+DH0K/wBpnMHkedJ5PXy9
52/lSRzzRI6RyuiuMOqsQG+vrVn+xtU/6Bt5/wB+G/wo/sbVP+gbef8Afhv8K5zoKgdgpUMQrdRn
g05Z5o4niSV1jf7yBiA31HerP9jap/0Dbz/vw3+FH9jap/0Dbz/vw3+FAFVppG2bpHOwYTLE7R7e
lKZ5TN5xlfzc537juz65qz/Y2qf9A28/78N/hR/Y2qf9A28/78N/hQBXkuriWTzJJ5XkxjczknHp
mmxSyQyCSKR43HRkbBH41a/sbVP+gbef9+G/wo/sbVP+gbef9+G/woAqO7SOXdizHksxyTWr4U/5
HHRP+v8Ag/8ARi1V/sbVP+gbef8Afhv8K1/C2kakni7RXfTrtVW+gJJgYADzB7UAdxr3/Iw6n/19
S/8AoZoo17/kYdT/AOvqX/0M0V9ZD4UfKz+JiWfiHWNKhMFhqd1bQk7ikUhUZ9cCrH/CZ+Jv+g7f
/wDf9qKKPZwerSBVJrRMP+Ez8Tf9B2//AO/7Uf8ACZ+Jv+g7f/8Af9qKKXsqf8q+4ftZ92H/AAmf
ib/oO3//AH/aj/hM/E3/AEHb/wD7/tRRR7Kn/KvuD2s+7D/hM/E3/Qdv/wDv+1H/AAmfib/oO3//
AH/aiij2VP8AlX3B7Wfdh/wmfib/AKDt/wD9/wBqP+Ez8Tf9B2//AO/7UUUeyp/yr7g9rPuw/wCE
z8Tf9B2//wC/7Uf8Jn4m/wCg7f8A/f8Aaiij2VP+VfcHtZ92ZbyPNI0sjF5HJZmJyST1NFFFUQf/
2Q0KZW5kc3RyZWFtDQplbmRvYmoNCjggMCBvYmoNCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0lt
YWdlL1dpZHRoIDIwMC9IZWlnaHQgOTgvQ29sb3JTcGFjZS9EZXZpY2VSR0IvQml0c1BlckNvbXBv
bmVudCA4L0ZpbHRlci9EQ1REZWNvZGUvSW50ZXJwb2xhdGUgdHJ1ZS9MZW5ndGggNTQ5ND4+DQpz
dHJlYW0NCv/Y/+AAEEpGSUYAAQEBASwBLAAA/9sAQwAIBgYHBgUIBwcHCQkICgwUDQwLCwwZEhMP
FB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEc
ITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgA
YgDIAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMC
BAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYn
KCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeY
mZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5
+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwAB
AgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpD
REVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ip
qrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMR
AD8A4yiiivrT5IKKKKBhRRRQAUUmaWgAooooAKKKKACijNFABRRRQAUUUUAFFFFABRRRQAUUUUAF
FFFABRWt4a/5GC1/4H/6AaP+El1f/n7/APIaf4Vw1MRX9u6NGCdkm25NbuS6Rl/KdlOhR9iqtWbV
21pFPZJ9ZLuZNXLDSrvUi/2aPcE+8ScCrX/CS6v/AM/f/kNP8Ks2niy/gLfaNtwCOMgJj8hWGJq5
mqTdGnDm/wATf4OMfzRtQp5e6iVWpLl/wpf+3S/Iw5YngleKRSrodrKexrovDcVrZ6JrXiG5tYrt
7BYo7eCYbo2kkbAZh3A64NYF3cveXUlxJjfI2TjoK6Pw3C2reFPEmh2w3X8whubeLPMojbLKB3OO
cV11XP2Cc9Hpe34nNSUPbNQ1Wtv0LOgau/jWa70bVrKy82S2kltLmC3WJ4pEG4DKgZU4OQaz7fwi
xsbG4vNb0mye+iWW3inlYMynoThcDmrvgzTr3Q72713VLOezsrG0m3PcRmPe7KVVFyOWJNQ+J9G1
LVNL8I/YtPurkHSIk3RRMy7sngkDA6j865udwqcsHZHTyKdPmmrsq2/g/U31K/s7trexXT8G7uLm
TbHGD93nvkdMdaLjwleLLp/2O6s7+2v5/s8NzbyZQSf3WyAVPfp0rutYkiurXxFpsemprN3ZrZef
ZrK4LbUwxBQhm2nqBWJod1fw3Gh2K+E20bTZdZhl8x2lO6XBHHmEnoD09KSxdRq/9bfeN4Smnb+t
/uMk+CJpHuLaz1rSbzULdWaSzhmYudvULlQCR6fWs/wiumz+K9Nj1Up9heXEm84UnB2g+27FbHgx
f+L1hu/2y8/9AlrjtLsLnVJktLSB57hwSkaDJOAScD6Amt4TnJShJ9N/W5hOEIuMorr+VjqfEGve
IbC4utK1jRtMhV1ZI0+woAqkEBomGOnY5PQVXs/CU0mnWt5farpmmLdjNsl5MVaQdA2ADhfc1t+G
4dbubC+0XxJZXJ0OC1kl868hZTZsq5Uo7DI5GNv9M1n+LtJ1DXf+Ee1DTLK4vLSXSoIUe3jZwjrk
MhwOCDWMajg+RWXmbSpqa53d+Rn3HhXUbO31qW68uJtJMPnITkuJWwpUjgjvUWn+HrvU9LjvreSL
El9HYpGxIJkfoemMc13esxyX+meKdFtAbjUrfTNMjkhi+di0blpMY64BFZvhmxvbDwvpa3lpcWzP
4ns2UTRshYcDIz1HWmsXPkb63X5ITwkOdLpZ/mY7+CZzff2ba6tpt3qYkMclrBIxMeM7ixKgALjm
ql14aMbwxWGr6Zqc8sywCC0mJfefQEDK+44rZ0IBvip4otgwWe7OoQQZOMyMzYGe3Q1neCtKvtE8
Y6VeapYXNpbpdeU0s8LIodlIAyRjrTVepq29lf1E6FPRJdbeg6fwVcILiK21XS7y/tkLzWUE5Mqh
fvYyAGI7gGuYDBhxXeWj6joniea4sPh4yX1u8n7/AM24ZMEEFssxQggnnpzXn8AITmtsNVnNvm/r
7jHEUoQS5SWiiius5QooooAKKKKANbw1/wAjBa/8D/8AQDWTWt4a/wCRgtf+B/8AoBrJrhp/79U/
wQ/Oodk/9zp/4p/lAKdHFJNII4o3kc9FRck/gKbWjoWu3PhvV4tTtYYpZYlYBJM7TkEdj712TbUW
0tTlgk5JPYr/ANnX3/Plc/8Aflv8Ka1hqEJE6W11E0fzCQRspX3zjivavhz471Lxjd6jFfWdtbi2
RGQw7vm3E9ck+lcXrfxb12e71XRk0uyMZkmtFYBy5GSmevWvPWLqym4OH4noPCU4xU1P8DhL2/1T
U0Vb/Ury7RfuiedpAPpkmtrWPFd5NY6NZ6RqGoWiWlglvcJHM0au4Jzwp5GD3rUsfhZ4pubNZnt4
ICy5Ec0uH/IA4P1rm9V0e+0K+NnqVq1vOBuAYghh6gjgitkqFRpRa0MG69NNyT1KFu1zaXAube5m
huASfNjkKvk+45q7DJrusapb+XeaheagpzAfOd5AQM5U5yMYzx6V0GjfDvxFrdkl5Bbxw28g3Rvc
Ps3j1AwTj3xWr4U8Oap4Z+J+iW+pwqhmE7RsjhlcCJ89Pw60VKlFKXK02kx06dZtcyaTZxE0WqaN
qrGZruz1FDuLlmSUFhyc9eQTz71UiDwkNG7I6nKspwQfY16r4z8AeIfEPje9v7OGFbNkjVJJZQu4
hADgDJ6+orgvEHhzVPDN0kGpwCPzBmORW3I4HXB/p1p0K9Oolqr9ia9GpTb3t3M+71PWNQgFvear
fXEA6RzXDuo/AnFNs73U9NieKw1K8tY3++kE7IG+oB5rsbb4WeKbhAz20FvntLOM/wDjuazNf8Ea
74bt/tN9bK1tkKZoX3qpPr3H4imp4dvlTQOGIS5mmc3bvdWdz9qtrqeC5Bz5sUhV/fkc1NPf6rdz
xz3WqXs0sTh45JLhmZGHQgk8EetaeheGdW8STOmmWpkWP/WSMwVE+pPf2rU1j4deI9Fs3u5raOeC
MbpGt5NxQepHBx9KcnQUuVtXJiq7jzJOxgW+jaxqME+qQWt5crG7PNdKGbDj5mJb15yT71Xu7/U9
SRUvtRvLpE+6s87OF+mTxXq3w7fPwp8RsD0kucf9+Erzfwz4b1fxLuTTbUyCPHmSMwVE+pPf261l
CrCU5KaSUeprOlNQi43bkVJNU1ia1FpLq19JagY8l7hymP8Adziq6rtGK6zWPh14j0Wze7mto54I
xudreTcUHqRwcfSsHStLvtbvUs9OtnuJ2Gdq9h6k9APc10U50uVyg1YwqRq3UZp3KdFdyfhN4oEe
8LZk/wBwT8/yx+tUrL4c+Ib2/u7Ex20FzaqjOksw5V87WBXII+U0vrNH+ZB9Wrfys5OinvDJHdPb
Mh85JDGyd9wOMfnW54k8H6n4Vht5dRe2xcMVjWKQsTgZPYeo/OtHUgmk3uQqc2m0tjAoooqyDW8N
f8jBa/8AA/8A0A1k1reGv+Rgtf8Agf8A6Aaya4af+/VP8EPzqHZP/c6f+Kf5QCiiiu44z1D4KD/i
Y6z/ANcov5tWH4GtIbv4wXQlUMIru5lUEfxBmx+ROfwrc+Cp/wCJlrP/AFyi/m1choWvReG/ibda
lcAm2F9cRzEDJCMzDI+nB/CvJqJutVS7foetTaVGm33/AFPQ/F3h74h6t4me60fWI7PTotot4o7p
o84AyXUDDEnPXPGKl+I+mte+H/DcmprH9vF9bwTtH93MgxIAfTIH5VR8SfDkeMdXfxBoXiJBBdhS
6BiybgoGVKnuAMj1zXE+KfC8fgibTZ/7dXUtQS5ErW4OPL2YIJG4nr3IFctJXceV6ryOmq7KV1o/
M6r40a1qdje6TpmnXk1nbtE0j/Z3MZY5AAOOwx096534e6jqmo/EXQRqN/cXfkCcRmeQuVBifIye
e1d54l8OWHxPstO1fRtUijlhQqQw3fK2DtYA5VgQfzrB0XwxD4T+KHh20GqR3lxKs7Sqi7fKxE2M
jJPOfbpWtKVL2Di/iszKrGr7ZSXw3RjfFPXNci8e3Vla6ve29rDHEY4oZ2RQSgJOARk5J5roviRL
JefCDQL+5bzLpvs0jSHqWaE7j+Jrkvilz8SNR/65Q/8AosV1XxBOfgj4fxz8tn/6JNHKowpSW4KT
lOpFlr423+oWVpoq2F9c2olklEnkTMm/AXGcHml8FXd3rHwg16PVbiS7MIuIkeZizbRErDk8nBJx
+HpUHxyIMGg45/eTfySnfDw4+E/iT/fuf/RCVmor6spdbmjk/rLj0sLDqE/hn4Cw3+lt5V3OinzR
1DSSYLfUDgfQVT+DviLWr/Wr3TNT1C4vYGtTOpuZDIyMGVcAnJwQ/T2qXwVd6X41+Gv/AAh95dpa
38K7EB+8wDbkdRxuxwCB+ma1fDnhnT/hjBea1rerQtI0RiQKu35cgkKCcsxIHA9KHycs1P4m9AXN
zQcPhS1HeHLWKx8H+PLSAbYYdQvkjUfwr5K4H4Cs63vp/C/wDgvdKbyruZFPmjqGkkwW+oHA+gqX
wRqLat8O/GepSLsa7vL2fb/dDQqQPw6VU8FXel+Nfhr/AMIfeXaWt/CuxAfvMA25HUcbscAgfpmo
s9XLurl3WnL2diL4O+I9a1DWr3TNTv7i9ga1M6m5kMjIwZVwCecEP09q2/Atnb6LJ41uraJc2t7L
HEpHREBYL9Pm/Sk8OeGdP+GMF5rWt6tCztEYk2jb8uQSFBOWYkDgelYPw18X2V5q3iGz1aRLZdYu
HuId7BRl8hkz64K4+hq6lpOTpfDoRTvFRVX4tTl/BGva9qHjzSpbzWL6UT3I8xGuG2sDnjbnGPbp
XpVxq50/47xWjviG+0xYeem8FmU/+Okf8CrO8PfCa+0PxNaX41K2ls7abzEG1g7L2BHQH8a574pX
smm/FOy1CHPmW0EEq4OMlXY4qpKnVqKNPsTF1KdNyqdyxc+Hifjr9i2ZhluVvvYrje2f+BAiqnxh
1U33jaHTkbMen24DD0d/mP8A47sr12HT9Ovddt/F0M8bp/Z5gVxyChYPuz7fMPxr5wv9RbWtf1DV
X/5erh5FHopPA/AYH4VphW6tWN/sozxSVKnK32mMooor2TxzW8Nf8jBa/wDA/wD0A1k1reGv+Rgt
f+B/+gGj/hGtX/59P/Iif415UsVQoY6ftpqN4QtdpdZ9z0o4atWwcPZQcrSlsm+kOxk0Vrf8I1q/
/Pp/5ET/ABo/4RrV/wDn0/8AIif41v8A2pgf+f0P/Al/mY/2djP+fUv/AAF/5GJNCso5ojhVE29q
2/8AhGtX/wCfT/yIn+NH/CNav/z6f+RE/wAaX9pYC9/bQ/8AAl/mP6hjbW9lL/wF/wCRg/ZijExS
PHnrtYjNJFaJF0rf/wCEa1f/AJ9P/Iif40f8I1q//Pp/5ET/ABqf7Qy+9/bQ/wDAl/mV9Sx1reyl
/wCAv/IwjbkOXjdkYjGVODTFs1AOeSeuTXRR+GNVeRVa3CKTgsZFIHvwabrGhS6SsbmUSxvxkDGD
9KUcwwE6ypQqRcpbWd/xWgSwWNhSdScGorurfnqYcVuI+FHJ7VqzeCtdS1N7Jo16INu4sYTwPUjr
itf4fQxTeNbIyoHWFZJwrDgsqEr+RwfwrnDrGr3d5LeyajdefKSXcTMCc9RwenPSumbfPyRWxjBL
k55PcqR2yK+4UslushBNdRY6Zo2neGodb11ryVbmZoba2tSqltv3mZmB47YFM1fRbKFtFvNNnnbT
NXz5PngeZGyuEdTjg4JHNCq078gnSqW5jmmtUZcelMa03uHldnYDALNk16E2jeEF8WN4WJ1lbsy+
Qt2ZIynmHp8uPu5/Gk+H6abb+Lp9PvrWWW+h89FkVx5YCqQQVI68HBzWcq1NxcuXY0jRqKSjfc4B
7VGxxStaoygeneum0bTtH1/V7uWA3djo1laNdXBkZZJdq9QpAAySeKkksdB1jRNRv9BN/bz6cFkm
gu2VhJGTjcpUDBHcGr9tTvZoj2VS10zkmtN8geV2dgMAsc8V0PhpPC/2meHxOJ1tnQCKWHd8jZ77
eensa0EsfDul+FtH1bVY9SuZtTM+2O2lREQRvt5yCSTkfrXLv5cruUVhGWO0NyQO1CUKkXGGnmDc
6bUp6+R6Zpdt8L/DuowavD4ku7h7U+ZDBJIXVTjjCqgOfqayjq3hLxz4t1bUPEF9c6bbhIotPwdp
ZBu3FjtYA5wce/euD+yx5zinGFCMY4rGOCafNzO5vLGprl5dD0nVPEvhPwn4Kv8AQvCl7Je3eobg
8p5KhgFLM2APu8ADvXmlvH5cQFKtvGhyBUtb4fD+yu27tnPXxHtbJKyQUUUV0nOFFFFAgooooGFF
FFABRRRQA+KV4JVliYq6HKkdjVm+1S71EobmXcEHygDA/SqdFZyoUpVFVlFOS2dtUaRrVIwdNSfK
910Zr+FtYh0HxNZ6hcqzWylo5gvXYylSfwzn8KsTeFbG3WaeHxToslkAWiPnnzmHYGMDIb9K58jI
qPyFzmonSlz88XYqFSPJySVzutD1y5ufBttpel+I7fRdRs7iRmFzL5STxtzneQRkHtWRrVzevrGk
rqXia31h4ZQxaFy8cALLn5yADnHb0rnWiVhyKFhVRWawtpuRq8TeKiddNe2Z+Mn9oC6gNp/aSv8A
aBIDHtyOd2cY96b4Z1KxtfibdXdxdRRWss10qzs3yDeHCkn0ORz71ygjUCjy1xij6srWv0sL6y73
t1udX4SuY/Cut39jcatawNe2LQx39rKJo4JDgqxK8Y459Min6zc66mjXKaj46sL6ORdq2lrcmczc
jg4XCjvz6VyAhUDGKQQKDkCk8LeXM2NYm0eVHQa3dW0/gbwhax3EUk9v9s86JXBaPdKCu4dRkcjN
YYGBTRGM5p9dFKnyKxhVqc7uFFFFaGYUUUUAFFFFABRRRQIKKKKBhRRRQAUUUUAFFFFABRRRQAUU
UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAf/9kNCmVuZHN0cmVhbQ0KZW5kb2JqDQo5IDAgb2Jq
DQo8PC9UeXBlL0ZvbnQvU3VidHlwZS9UcnVlVHlwZS9OYW1lL0YxL0Jhc2VGb250L0FCQ0RFRStW
ZXJkYW5hLEJvbGQvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0ZvbnREZXNjcmlwdG9yIDEwIDAg
Ui9GaXJzdENoYXIgMzIvTGFzdENoYXIgMTIxL1dpZHRocyA5MzQgMCBSPj4NCmVuZG9iag0KMTAg
MCBvYmoNCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvQUJDREVFK1ZlcmRhbmEsQm9s
ZC9GbGFncyAzMi9JdGFsaWNBbmdsZSAwL0FzY2VudCAxMDA1L0Rlc2NlbnQgLTIwNy9DYXBIZWln
aHQgNzY1L0F2Z1dpZHRoIDU2OC9NYXhXaWR0aCAyMjU3L0ZvbnRXZWlnaHQgNzAwL1hIZWlnaHQg
MjUwL1N0ZW1WIDU2L0ZvbnRCQm94WyAtNTUwIC0yMDcgMTcwNyA3NjVdIC9Gb250RmlsZTIgOTM1
IDAgUj4+DQplbmRvYmoNCjExIDAgb2JqDQo8PC9UeXBlL0V4dEdTdGF0ZS9CTS9Ob3JtYWwvQ0Eg
MT4+DQplbmRvYmoNCjEyIDAgb2JqDQo8PC9UeXBlL0ZvbnQvU3VidHlwZS9UcnVlVHlwZS9OYW1l
L0YyL0Jhc2VGb250L0FCQ0RFRStWZXJkYW5hL0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9Gb250
RGVzY3JpcHRvciAxMyAwIFIvRmlyc3RDaGFyIDMyL0xhc3RDaGFyIDEyMi9XaWR0aHMgOTM5IDAg
Uj4+DQplbmRvYmoNCjEzIDAgb2JqDQo8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0FC
Q0RFRStWZXJkYW5hL0ZsYWdzIDMyL0l0YWxpY0FuZ2xlIDAvQXNjZW50IDEwMDUvRGVzY2VudCAt
MjA3L0NhcEhlaWdodCA3NjUvQXZnV2lkdGggNTA4L01heFdpZHRoIDIwMDYvRm9udFdlaWdodCA0
MDAvWEhlaWdodCAyNTAvU3RlbVYgNTAvRm9udEJCb3hbIC01NjAgLTIwNyAxNDQ3IDc2NV0gL0Zv
bnRGaWxlMiA5MzcgMCBSPj4NCmVuZG9iag0KMTQgMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQg
MiAwIFIvUmVzb3VyY2VzPDwvWE9iamVjdDw8L0ltYWdlNSA1IDAgUi9JbWFnZTE2IDE2IDAgUi9J
bWFnZTcgNyAwIFIvSW1hZ2U4IDggMCBSL0ltYWdlMTcgMTcgMCBSL0ltYWdlMjggMjggMCBSPj4v
Rm9udDw8L0YyIDEyIDAgUi9GMSA5IDAgUi9GMyAzOSAwIFI+Pi9QYXR0ZXJuPDwvUDIwIDIwIDAg
Ui9QMzEgMzEgMCBSPj4vRXh0R1N0YXRlPDwvR1MyNyAyNyAwIFIvR1MzOCAzOCAwIFI+Pi9Qcm9j
U2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAgMCA3MjAg
NTQwXSAvQ29udGVudHMgMTUgMCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9D
Uy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyAxPj4NCmVuZG9iag0KMTUgMCBvYmoN
Cjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMjY2NT4+DQpzdHJlYW0NCnicpVrbTxw3F39H
4n+w1JfZSgy+X6SqUksoTfUh0YQmldI+oO1yiRZIgfC1/31/x56Zndm1PTR9YMFnfa4+Vxt2eMa+
+ebw9Oj1K8a//ZZ9/+qI/bm/xxlvOedCSu6Yk5wZzdnDan/v/dfsDl+3XAmNPcpZfFoT2MPVgMW5
FVxP0C6/3t/7eX+PHZ8eMTZiKXZYZpATTydC6wzDNmZU/2crDRDY8nZ/7/D17cXVyrBX9yzHSW44
HXSMuAiu09MrITI8De9Z6tAKaZgSrQckRKQRW2FLfNUuX2NEqPPVDoolVQ2zkbMmVccsXYmj3uVo
vbaJo9Ra5KwruBqsy6OOlgcSwkXuG7a+xNZkDCytrjuSxaFqHdkKxVtjmTat10xYoPmxgYvq2o6v
IPn/H31TO0FeqRU+hRXszcn+3p4UnvQRTrVWMSV96z1xU0Ajgd5maLuO9vfnkOMHyYRk55cwVhKY
KS+JqRSqhXznt+XA2AWTTB8atvidnf+0v3d8nuHuR9y3WIrgW5dYzhAJFSJeQ6CXEBG8QsWGNryM
ipiYUzChcVZTi2rZSsskhy/IjuaP948L2zwtVMNOjxYHsjkeMRkLpIVtpZgi1wWSW+crXRvsRCC4
bSsD095u7P3r6g6SHLPFgW2+e1joZnmNj5un1fLp88OqIJwRcFA/JVQXbpQ5Ds8unp5WD3ds+Ygt
iKLHJYLn8OStdOzqEfnCM9C2cE+jx/lWksfHmLCGQsIFiU/vZQqJHbRcDAi9HQQ7p2bgjQFBi2+k
LsUBcaRkgFR5vsSpvi8YykrVajMmBjBh1K2VSz9czaQfLSTlnMgYqQDW0ZbykZIaaW+UfmQx7Qm7
bR6z7UPGtCCsBXl2Ovg/7smPb+HSvGAFQU7sp1h1A7iSuygxuIvyyV0cqhnlQJvSgKA0IIiVGXtP
yWtmsLNO5DNW8ltehNgXUFmZ1tScKJlPRfP9Uoo2jxItRrTmrNenyUICl4rqLzJ9YLfDSilPFlgT
wGYBtB+rawLItMPRjkjDRIBWA4of7UhYl7lGZtymbWpeNtwE+8jYB8Ui799hGfYH27MmtTJBd6Jo
tFPwjA6wjieYbaHEYKRtxyAboW2LJVXESqxgI2LS2pFT8ZkaPUMi51lSZoqKnXqWQD/l0VrAtFp+
UZ3+hUrQ6oEtBG8ekew/XSxXbCGpLOnmvvtZPy5Mw35rfjj97vB2SRG+WrhmfQ/o1cI3vy0KzqqC
bdHnjcSb8Vap6t6qA7o2aqKit9KKGh8pqPFZE8AMANkDuv3J73RQCYB62NGgLhRJRqf9IX3tKcgq
rtqXDjpqZelTouBEEQVV2+R++HMTBlrwrZUcwkGjJZTQNCKhNjue9ugIrcjRFweD/p0YpzDuVpuo
NTJkAZswNkqlHX0YG3StE/mNdKMdFZnsTMYxjik3ZAusNLd9qsCe6arb2eUaciZuBtQhoGgzTqH7
riKbqwa6BGtEaadziEGt9CjICw14GS0b2H62W5RoFSCTsqAYviiuKUxVs1rfX7FCcEqB84ScliIh
xebN3VPMBpcXqEDLUsMnvaM+ZoJZj+rw0klGxvFXuDigCR73y9iMl4ypcg08lSAUcuFNNGyt4naN
N0Mae0up7hKaU0d+8/BnKamhPVAT4jPqq011yautTfQfUhsNRzd6yWpxUDKjtkYB5CZJVvSaHbVf
v31T6jWQRowa05vTdCZ9KzQPSMwiCDoeSnbQnHqsBFiPALwDDCg94JpgLsLghzaSUUr0m2yHlXYE
1QEK+UDpaj7AUceoJlIYhamV0LHFeGnZrxLInqvJzaOo8hgu/kM2OHvHTj7Dq1ePVNZR7F1TSgvK
2pT3R9Fdn04VimbU86X5QNli9VTek5UkNMYvujmBN4xigYzeZ5EpdrL3DHrW5C4XSuhqcZQS7shV
Z/IQeQUuR/LuQpPBnzFGl4Z5p1vrxqTnzOXrUWV0LMzCx/7BONuv1qNVbG+Gnbqv+s4kgI+oXqRV
qvf9d7IWQGEmtxmfhikXg8DExUzjq/l2fZRbQ3lMwBLlARPgl4TDmxXK3CPFA6LhiQplKRoMZSZH
1mx979uE+Pdjj0kkbksTPzSVYYpdPWottqbJsDNyo7FQgm8i7XpxYJrnW7q3gVJFPZBGUa0k3WcM
1X5xIHRzR/gfFwe6IaMsnwhqGmrt70q0UKfg7hNada1yxUqh4SRdOFT0HZVPZNBnBouSNrqcoxDY
2kICt8H9Um0UPFPLKa26NirXcXAUHCgTm+hE5Pn1QqjmDan0c6mTQpZRcopW593Xq839Vz7sXLrq
7u6EBY6LfooRZ7YatD2kjaEPSw2t9NULZW1nm1qPQDRDUa62J8voCZ9RqAQOT8WujH7WN3elrlTY
eI4j6nO2dDOpK9qArsBfbIOdxn6auJBeAw1d6HKtrxvg0wVV3CuM4uS9+PPykubwG3xULIDj02Py
cxbIXaE7qpagQu8UfXTHfLm8p7B6pnz3wKJ4yyeKtpv7UmgJoiWmpKoCGV5uDNIc2A243Wozz+JY
soDNgKtcSDv6yRMmT4OaGlDUaEe55pk+SRueWvVuYE6r0cDMeRYwGvuDT4BUubt5Jw3/huv+u4oo
cmbWTtW3v93rVtRSx65YepMHbG73fEwBNFClVptoEECLAUWNdlREVXOlTdPFOCVRQ81bpa5/aL46
OSt1V9BFjGnMuZzODlLQCUTsJi2/O00tsGn+oppCQ2JBgBAvuybIdQnMTB6SOh5PZ3Kair2r3S+Y
+VQsfSqgyBh25kr69O2bWoMkTaASJrVufX8hTfPzar2idHG7ImQCPPxdLOamDVMCdXu5GZ+nHOh5
769Yja6ind1adTs7b0eykV4MqDFWez93sv+u4uS+mMC0kXRuXSj2K91fX2nDqUHeBQyhqE3sx6Xu
VdMm5Ys07BCK9nHe0XxGyrk3ge5BOd2mgpNAuqULigRYjwCuAwwoPeCaNvm0SQ1kZALYgUy3I2yw
cgJbPpc7YGWEDaJOUgms5A5Gb2g6PdQdlXwaEvMJsZc81Nn6I4JGC6H85DbAVa4TcsE4SyOXDWzu
GWHrfQqlBm72H+4Xfnx3Gnu1k890w2AqY0h06n9xuWBIKP0vLhes2upli8ZUcYdPtwPx7o1ul8uG
zFYKBKXBfMg96TXzQKxM9KKjs9LjnvauNWJM7UWOZ7aiY/eh1lIXi3RvWt0b8deFEs2q1LqhBG0j
1GXoa87o7W73fib/bKdMTCZgFtuyboVUy+kxQNBrsQzx2Tpau18sqUcKaXaLAGMU3RF2mP0KVGln
t0KGDOTwCQ+VB0m4o5oWS3qMSTwToJcnYY5kXcZ0VXhRtLlLJeoQDV1LWSLce//xVyXXRwVAmZ9s
rx/CdP5QmVDXcAT4q0T+Tg62W6h2j+1D836VegDBm4uHVfx9vSr+Rwi9oiFYN0zm5A6H/7u4u2LN
x4uDn84WW/nK76Yr1XoFuHZ9yFmM7lf9H1FiSd0Hpw9BH3F5aA8lTSyuJozLPSgY+k8HOWI5o5ET
JY02t4DwUgeKaviPHlmlmL3wxwgTLaHK/xb0D2jXEfsNCmVuZHN0cmVhbQ0KZW5kb2JqDQoxNiAw
IG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvV2lkdGggNzIvSGVpZ2h0IDcwL0Nv
bG9yU3BhY2UvRGV2aWNlUkdCL0JpdHNQZXJDb21wb25lbnQgOC9GaWx0ZXIvRENURGVjb2RlL0lu
dGVycG9sYXRlIHRydWUvTGVuZ3RoIDcyOT4+DQpzdHJlYW0NCv/Y/+AAEEpGSUYAAQEBAEgASAAA
/9sAQwAIBgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0
NB8nOT04MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy
MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgARgBIAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEB
AAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQci
cRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpj
ZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfI
ycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgME
BQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkj
M1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2
d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ
2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A4yiiivrT5MKKKKACiiigAooooAKKKKAC
iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK
KKACiiigAooooAKKKKACiiigAooooA//2Q0KZW5kc3RyZWFtDQplbmRvYmoNCjE3IDAgb2JqDQo8
PC9UeXBlL1hPYmplY3QvU3VidHlwZS9JbWFnZS9XaWR0aCAxNzIxL0hlaWdodCAzNjMvQ29sb3JT
cGFjZS9EZXZpY2VSR0IvQml0c1BlckNvbXBvbmVudCA4L0ZpbHRlci9EQ1REZWNvZGUvSW50ZXJw
b2xhdGUgdHJ1ZS9TTWFzayAxOCAwIFIvTGVuZ3RoIDI5NDEyPj4NCnN0cmVhbQ0K/9j/4AAQSkZJ
RgABAQEAeAB4AAD/4QBaRXhpZgAATU0AKgAAAAgABQMBAAUAAAABAAAASgMDAAEAAAABAAAAAFEQ
AAEAAAABAQAAAFERAAQAAAABAAASdFESAAQAAAABAAASdAAAAAAAAYagAACxj//bAEMACAYGBwYF
CAcHBwkJCAoMFA0MCwsMGRITDxQdGh8eHRocHCAkLicgIiwjHBwoNyksMDE0NDQfJzk9ODI8LjM0
Mv/bAEMBCQkJDAsMGA0NGDIhHCEyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy
MjIyMjIyMjIyMjIyMv/AABEIAWsGuQMBIgACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQID
BAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHB
FVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2
d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna
4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1
EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ0
4SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeI
iYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery
8/T19vf4+fr/2gAMAwEAAhEDEQA/APn+ur+H2gWXiPxFJZ36sYFt2kwrEHO5R2/3q5Su/wDhB/yN
8/8A15t/6MjqoK8kTN2iz0EfB/wyRkLPj/ro3+NL/wAKe8M/3Z/+/jf411N1dzwShY32rtzjANQf
2jdf89f/AB0f4V1csexyc0+5zv8Awp7wz/dn/wC/jf40f8Ke8M/3Z/8Av43+NdF/aN1/z1/8dH+F
H9o3X/PX/wAdH+FHLHsHNPuc7/wp7wz/AHZ/+/jf40f8Ke8M/wB2f/v43+NdF/aN1/z1/wDHR/hR
/aN1/wA9f/HR/hRyx7BzT7nO/wDCnvDP92f/AL+N/jR/wp7wz/dn/wC/jf410X9o3X/PX/x0f4Uf
2jdf89f/AB0f4Ucsewc0+5zv/CnvDP8Adn/7+N/jR/wp7wz/AHZ/+/jf410X9o3X/PX/AMdH+FH9
o3X/AD1/8dH+FHLHsHNPuc7/AMKe8M/3Z/8Av43+NH/CnvDP92f/AL+N/jXRf2jdf89f/HR/hR/a
N1/z1/8AHR/hRyx7BzT7nO/8Ke8M/wB2f/v43+NH/CnvDP8Adn/7+N/jXRf2jdf89f8Ax0f4Uf2j
df8APX/x0f4Ucsewc0+5zv8Awp7wz/dn/wC/jf40f8Ke8M/3Z/8Av43+NdF/aN1/z1/8dH+FH9o3
X/PX/wAdH+FHLHsHNPuc7/wp7wz/AHZ/+/jf40f8Ke8M/wB2f/v43+NdF/aN1/z1/wDHR/hR/aN1
/wA9f/HR/hRyx7BzT7nO/wDCnvDP92f/AL+N/jR/wp7wz/dn/wC/jf410X9o3X/PX/x0f4Uf2jdf
89f/AB0f4Ucsewc0+5zv/CnvDP8Adn/7+N/jR/wp7wz/AHZ/+/jf410X9o3X/PX/AMdH+FH9o3X/
AD1/8dH+FHLHsHNPuc7/AMKe8M/3Z/8Av43+NH/CnvDP92f/AL+N/jXRf2jdf89f/HR/hR/aN1/z
1/8AHR/hRyx7BzT7nO/8Ke8M/wB2f/v43+NH/CnvDP8Adn/7+N/jXRf2jdf89f8Ax0f4Uf2jdf8A
PX/x0f4Ucsewc0+5zv8Awp7wz/dn/wC/jf40f8Ke8M/3Z/8Av43+NdF/aN1/z1/8dH+FH9o3X/PX
/wAdH+FHLHsHNPuc7/wp7wz/AHZ/+/jf40f8Ke8M/wB2f/v43+NdF/aN1/z1/wDHR/hR/aN1/wA9
f/HR/hRyx7BzT7nO/wDCnvDP92f/AL+N/jR/wp7wz/dn/wC/jf410X9o3X/PX/x0f4Uf2jdf89f/
AB0f4Ucsewc0+5zv/CnvDP8Adn/7+N/jR/wp7wz/AHZ/+/jf410X9o3X/PX/AMdH+FH9o3X/AD1/
8dH+FHLHsHNPuc7/AMKe8M/3Z/8Av43+NH/CnvDP92f/AL+N/jXRf2jdf89f/HR/hR/aN1/z1/8A
HR/hRyx7BzT7nO/8Ke8M/wB2f/v43+NH/CnvDP8Adn/7+N/jXRf2jdf89f8Ax0f4Uf2jdf8APX/x
0f4Ucsewc0+5zv8Awp7wz/dn/wC/jf40f8Ke8M/3Z/8Av43+NdF/aN1/z1/8dH+FH9o3X/PX/wAd
H+FHLHsHNPuc7/wp7wz/AHZ/+/jf40f8Ke8M/wB2f/v43+NdF/aN1/z1/wDHR/hR/aN1/wA9f/HR
/hRyx7BzT7nO/wDCnvDP92f/AL+N/jR/wp7wz/dn/wC/jf410X9o3X/PX/x0f4Uf2jdf89f/AB0f
4Ucsewc0+5zv/CnvDP8Adn/7+N/jR/wp7wz/AHZ/+/jf410X9o3X/PX/AMdH+FH9o3X/AD1/8dH+
FHLHsHNPuc7/AMKe8M/3Z/8Av43+NH/CnvDP92f/AL+N/jXRf2jdf89f/HR/hR/aN1/z1/8AHR/h
Ryx7BzT7nO/8Ke8M/wB2f/v43+NH/CnvDP8Adn/7+N/jXRf2jdf89f8Ax0f4Uf2jdf8APX/x0f4U
csewc0+5zv8Awp7wz/dn/wC/jf40f8Ke8M/3Z/8Av43+NdF/aN1/z1/8dH+FH9o3X/PX/wAdH+FH
LHsHNPuc7/wp7wz/AHZ/+/jf40f8Ke8M/wB2f/v43+NdF/aN1/z1/wDHR/hR/aN1/wA9f/HR/hRy
x7BzT7nO/wDCnvDP92f/AL+N/jR/wp7wz/dn/wC/jf410X9o3X/PX/x0f4Uf2jdf89f/AB0f4Ucs
ewc0+5zv/CnvDP8Adn/7+N/jR/wp7wz/AHZ/+/jf410X9o3X/PX/AMdH+FH9o3X/AD1/8dH+FHLH
sHNPuc7/AMKe8M/3Z/8Av43+NH/CnvDP92f/AL+N/jXRf2jdf89f/HR/hR/aN1/z1/8AHR/hRyx7
BzT7nO/8Ke8M/wB2f/v43+NH/CnvDP8Adn/7+N/jXRf2jdf89f8Ax0f4Uf2jdf8APX/x0f4Ucsew
c0+5zv8Awp7wz/dn/wC/jf40f8Ke8M/3Z/8Av43+NdF/aN1/z1/8dH+FH9o3X/PX/wAdH+FHLHsH
NPuc7/wp7wz/AHZ/+/jf40f8Ke8M/wB2f/v43+NdF/aN1/z1/wDHR/hR/aN1/wA9f/HR/hRyx7Bz
T7nO/wDCnvDP92f/AL+N/jR/wp7wz/dn/wC/jf410X9o3X/PX/x0f4Uf2jdf89f/AB0f4Ucsewc0
+5zv/CnvDP8Adn/7+N/jR/wp7wz/AHZ/+/jf410X9o3X/PX/AMdH+FH9o3X/AD1/8dH+FHLHsHNP
uc7/AMKe8M/3Z/8Av43+NH/CnvDP92f/AL+N/jXRf2jdf89f/HR/hR/aN1/z1/8AHR/hRyx7BzT7
nO/8Ke8M/wB2f/v43+NH/CnvDP8Adn/7+N/jXRf2jdf89f8Ax0f4Uf2jdf8APX/x0f4Ucsewc0+5
zv8Awp7wz/dn/wC/jf40f8Ke8M/3Z/8Av43+NdF/aN1/z1/8dH+FH9o3X/PX/wAdH+FHLHsHNPuc
7/wp7wz/AHZ/+/jf40f8Ke8M/wB2f/v43+NdF/aN1/z1/wDHR/hR/aN1/wA9f/HR/hRyx7BzT7nO
/wDCnvDP92f/AL+N/jR/wp7wz/dn/wC/jf410X9o3X/PX/x0f4Uf2jdf89f/AB0f4Ucsewc0+5zv
/CnvDP8Adn/7+N/jR/wp7wz/AHZ/+/jf410X9o3X/PX/AMdH+FH9o3X/AD1/8dH+FHLHsHNPuc7/
AMKe8M/3Z/8Av43+NH/CnvDP92f/AL+N/jXRf2jdf89f/HR/hR/aN1/z1/8AHR/hRyx7BzT7nO/8
Ke8M/wB2f/v43+NH/CnvDP8Adn/7+N/jXRf2jdf89f8Ax0f4Uf2jdf8APX/x0f4Ucsewc0+5zv8A
wp7wz/dn/wC/jf40f8Ke8M/3Z/8Av43+NdF/aN1/z1/8dH+FH9o3X/PX/wAdH+FHLHsHNPuc7/wp
7wz/AHZ/+/jf40f8Ke8M/wB2f/v43+NdF/aN1/z1/wDHR/hR/aN1/wA9f/HR/hRyx7BzT7nO/wDC
nvDP92f/AL+N/jR/wp7wz/dn/wC/jf410X9o3X/PX/x0f4Uf2jdf89f/AB0f4Ucsewc0+5zv/Cnv
DP8Adn/7+N/jR/wp7wz/AHZ/+/jf410X9o3X/PX/AMdH+FH9o3X/AD1/8dH+FHLHsHNPuc7/AMKe
8M/3Z/8Av43+NH/CnvDP92f/AL+N/jXRf2jdf89f/HR/hR/aN1/z1/8AHR/hRyx7BzT7nO/8Ke8M
/wB2f/v43+NH/CnvDP8Adn/7+N/jXRf2jdf89f8Ax0f4Uf2jdf8APX/x0f4Ucsewc0+5zv8Awp7w
z/dn/wC/jf40f8Ke8M/3Z/8Av43+NdF/aN1/z1/8dH+FH9o3X/PX/wAdH+FHLHsHNPuc7/wp7wz/
AHZ/+/jf40f8Ke8M/wB2f/v43+NdF/aN1/z1/wDHR/hR/aN1/wA9f/HR/hRyx7BzT7nO/wDCnvDP
92f/AL+N/jR/wp7wz/dn/wC/jf410X9o3X/PX/x0f4Uf2jdf89f/AB0f4Ucsewc0+5zv/CnvDP8A
dn/7+N/jR/wp7wz/AHZ/+/jf410X9o3X/PX/AMdH+FH9o3X/AD1/8dH+FHLHsHNPuc7/AMKe8M/3
Z/8Av43+NH/CnvDP92f/AL+N/jXRf2jdf89f/HR/hR/aN1/z1/8AHR/hRyx7BzT7nO/8Ke8M/wB2
f/v43+NH/CnvDP8Adn/7+N/jXRf2jdf89f8Ax0f4Uf2jdf8APX/x0f4Ucsewc0+5zv8Awp7wz/dn
/wC/jf40f8Ke8M/3Z/8Av43+NdF/aN1/z1/8dH+FH9o3X/PX/wAdH+FHLHsHNPuc7/wp7wz/AHZ/
+/jf40f8Ke8M/wB2f/v43+NdF/aN1/z1/wDHR/hR/aN1/wA9f/HR/hRyx7BzT7nO/wDCnvDP92f/
AL+N/jR/wp7wz/dn/wC/jf410X9o3X/PX/x0f4Uf2jdf89f/AB0f4Ucsewc0+5zv/CnvDP8Adn/7
+N/jR/wp7wz/AHZ/+/jf410X9o3X/PX/AMdH+FH9o3X/AD1/8dH+FHLHsHNPuc7/AMKe8M/3Z/8A
v43+NH/CnvDP92f/AL+N/jXRf2jdf89f/HR/hR/aN1/z1/8AHR/hRyx7BzT7nO/8Ke8M/wB2f/v4
3+NH/CnvDP8Adn/7+N/jXRf2jdf89f8Ax0f4Uf2jdf8APX/x0f4Ucsewc0+5zv8Awp7wz/dn/wC/
jf40f8Ke8M/3Z/8Av43+NdF/aN1/z1/8dH+FH9o3X/PX/wAdH+FHLHsHNPuc7/wp7wz/AHZ/+/jf
40f8Ke8M/wB2f/v43+NdF/aN1/z1/wDHR/hR/aN1/wA9f/HR/hRyx7BzT7nO/wDCnvDP92f/AL+N
/jR/wp7wz/dn/wC/jf410X9o3X/PX/x0f4Uf2jdf89f/AB0f4Ucsewc0+5zv/CnvDP8Adn/7+N/j
R/wp7wz/AHZ/+/jf410X9o3X/PX/AMdH+FH9o3X/AD1/8dH+FHLHsHNPuc7/AMKe8M/3Z/8Av43+
NH/CnvDP92f/AL+N/jXRf2jdf89f/HR/hR/aN1/z1/8AHR/hRyx7BzT7nO/8Ke8M/wB2f/v43+NH
/CnvDP8Adn/7+N/jXRf2jdf89f8Ax0f4Uf2jdf8APX/x0f4Ucsewc0+5zv8Awp7wz/dn/wC/jf40
f8Ke8M/3Z/8Av43+NdF/aN1/z1/8dH+FH9o3X/PX/wAdH+FHLHsHNPuc7/wp7wz/AHZ/+/jf40f8
Ke8M/wB2f/v43+NdF/aN1/z1/wDHR/hR/aN1/wA9f/HR/hRyx7BzT7nO/wDCnvDP92f/AL+N/jR/
wp7wz/dn/wC/jf410X9o3X/PX/x0f4Uf2jdf89f/AB0f4Ucsewc0+5zv/CnvDP8Adn/7+N/jR/wp
7wz/AHZ/+/jf410X9o3X/PX/AMdH+FH9o3X/AD1/8dH+FHLHsHNPuc7/AMKe8M/3Z/8Av43+NH/C
nvDP92f/AL+N/jXRf2jdf89f/HR/hR/aN1/z1/8AHR/hRyx7BzT7nO/8Ke8M/wB2f/v43+NH/Cnv
DP8Adn/7+N/jXRf2jdf89f8Ax0f4Uf2jdf8APX/x0f4Ucsewc0+5zv8Awp7wz/dn/wC/jf40f8Ke
8M/3Z/8Av43+NdF/aN1/z1/8dH+FH9o3X/PX/wAdH+FHLHsHNPuc7/wp7wz/AHZ/+/jf40f8Ke8M
/wB2f/v43+NdF/aN1/z1/wDHR/hR/aN1/wA9f/HR/hRyx7BzT7nO/wDCnvDP92f/AL+N/jR/wp7w
z/dn/wC/jf410X9o3X/PX/x0f4Uf2jdf89f/AB0f4Ucsewc0+5zv/CnvDP8Adn/7+N/jR/wp7wz/
AHZ/+/jf410X9o3X/PX/AMdH+FH9o3X/AD1/8dH+FHLHsHNPuc7/AMKe8M/3Z/8Av43+NH/CnvDP
92f/AL+N/jXRf2jdf89f/HR/hR/aN1/z1/8AHR/hRyx7BzT7nO/8Ke8M/wB2f/v43+NH/CnvDP8A
dn/7+N/jXRf2jdf89f8Ax0f4Uf2jdf8APX/x0f4Ucsewc0+5zv8Awp7wz/dn/wC/jf40f8Ke8M/3
Z/8Av43+NdF/aN1/z1/8dH+FH9o3X/PX/wAdH+FHLHsHNPuc7/wp7wz/AHZ/+/jf40f8Ke8M/wB2
f/v43+NdF/aN1/z1/wDHR/hR/aN1/wA9f/HR/hRyx7BzT7nO/wDCnvDP92f/AL+N/jR/wp7wz/dn
/wC/jf410X9o3X/PX/x0f4Uf2jdf89f/AB0f4Ucsewc0+5zv/CnvDP8Adn/7+N/jR/wp7wz/AHZ/
+/jf410X9o3X/PX/AMdH+FH9o3X/AD1/8dH+FHLHsHNPuc7/AMKe8M/3Z/8Av43+NH/CnvDP92f/
AL+N/jXRf2jdf89f/HR/hR/aN1/z1/8AHR/hRyx7BzT7nO/8Ke8M/wB2f/v43+NH/CnvDP8Adn/7
+N/jXRf2jdf89f8Ax0f4Uf2jdf8APX/x0f4Ucsewc0+5zv8Awp7wz/dn/wC/jf40f8Ke8M/3Z/8A
v43+NdF/aN1/z1/8dH+FH9o3X/PX/wAdH+FHLHsHNPuc7/wp7wz/AHZ/+/jf40f8Ke8M/wB2f/v4
3+NdF/aN1/z1/wDHR/hR/aN1/wA9f/HR/hRyx7BzT7nO/wDCnvDP92f/AL+N/jR/wp7wz/dn/wC/
jf410X9o3X/PX/x0f4Uf2jdf89f/AB0f4Ucsewc0+5zv/CnvDP8Adn/7+N/jR/wp7wz/AHZ/+/jf
410X9o3X/PX/AMdH+FH9o3X/AD1/8dH+FHLHsHNPuc7/AMKe8M/3Z/8Av43+NH/CnvDP92f/AL+N
/jXRf2jdf89f/HR/hR/aN1/z1/8AHR/hRyx7BzT7nO/8Ke8M/wB2f/v43+NH/CnvDP8Adn/7+N/j
XRf2jdf89f8Ax0f4Uf2jdf8APX/x0f4Ucsewc0+5zv8Awp7wz/dn/wC/jf40f8Ke8M/3Z/8Av43+
NdF/aN1/z1/8dH+FH9o3X/PX/wAdH+FHLHsHNPuc7/wp7wz/AHZ/+/jf40f8Ke8M/wB2f/v43+Nd
F/aN1/z1/wDHR/hR/aN1/wA9f/HR/hRyx7BzT7nO/wDCnvDP92f/AL+N/jR/wp7wz/dn/wC/jf41
0X9o3X/PX/x0f4Uf2jdf89f/AB0f4Ucsewc0+5zv/CnvDP8Adn/7+N/jR/wp7wz/AHZ/+/jf410X
9o3X/PX/AMdH+FH9o3X/AD1/8dH+FHLHsHNPuc7/AMKe8M/3Z/8Av43+NH/CnvDP92f/AL+N/jXR
f2jdf89f/HR/hR/aN1/z1/8AHR/hRyx7BzT7nO/8Ke8M/wB2f/v43+NH/CnvDP8Adn/7+N/jXRf2
jdf89f8Ax0f4Uf2jdf8APX/x0f4Ucsewc0+5zv8Awp7wz/dn/wC/jf40f8Ke8M/3Z/8Av43+NdF/
aN1/z1/8dH+FH9o3X/PX/wAdH+FHLHsHNPuc7/wp7wz/AHZ/+/jf40f8Ke8M/wB2f/v43+NdF/aN
1/z1/wDHR/hR/aN1/wA9f/HR/hRyx7BzT7nO/wDCnvDP92f/AL+N/jR/wp7wz/dn/wC/jf410X9o
3X/PX/x0f4Uf2jdf89f/AB0f4Ucsewc0+5zv/CnvDP8Adn/7+N/jR/wp7wz/AHZ/+/jf410X9o3X
/PX/AMdH+FH9o3X/AD1/8dH+FHLHsHNPuc7/AMKe8M/3Z/8Av43+NH/CnvDP92f/AL+N/jXRf2jd
f89f/HR/hR/aN1/z1/8AHR/hRyx7BzT7nO/8Ke8M/wB2f/v43+NH/CnvDP8Adn/7+N/jXRf2jdf8
9f8Ax0f4Uf2jdf8APX/x0f4Ucsewc0+5zv8Awp7wz/dn/wC/jf40f8Ke8M/3Z/8Av43+NdF/aN1/
z1/8dH+FH9o3X/PX/wAdH+FHLHsHNPuc7/wp7wz/AHZ/+/jf40f8Ke8M/wB2f/v43+NdF/aN1/z1
/wDHR/hR/aN1/wA9f/HR/hRyx7BzT7nO/wDCnvDP92f/AL+N/jQPg94Zzytxj/rqf8a6L+0br/nr
/wCOj/CnJqF0zqvm9Tj7o/wo5Y9g5p9zxz4i/D+Hw2qahpXnPY5CTI/zGJj0bP8AdPTnocc8gDz2
vqu9jjuBNFOivFIpV1cZDKRggj0xXypWFWKT0OilNyVmFd/8IP8Akb5/+vNv/RkdcBXofweiLeKb
qXHC2pU/i6n+lTD4kVU+FnsOof69f93+pqpVi/Obgeyiqua6jjHUU3NGaQx1FNzRmgB1FNzRmgB1
FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzR
mgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1
FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzR
mgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1
FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzR
mgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1
FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzR
mgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1
FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzR
mgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1
FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1SQf6+P8A3h/Ooc1JAf8ASIv98fzp
gS65P9n0jUZ+R5dvI/HspNfL9fS3ir/kVtb/AOvKf/0Bq+aawrbo3obMK9S+C8YN9qsvdViUfjvP
9K8tr1X4Lf6/V/8Atj/KSop/Ei6vwM9KvTm6f2x/Kq9TXn/H2/4fyqCuo5RaKSikAtFJRQAtFJRQ
AtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJ
RQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAt
FJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQ
AtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJ
RQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAt
FJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQ
AtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJ
RQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAt
SQf8fEX++P51FU1qM3UY980wIfFX/Ira3/15T/8AoDV8019K+LGC+FdaJOB9inH5oa+aqwrbo3ob
MK9U+C/+v1f/ALY/ykryuvWfgvFhNWm7M0S/kG/+KqKfxIur8DPRLz/j7f8AD+VQVJdnN1Ifeoa6
TlHUU2igY6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOopt
FADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOopt
FADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOopt
FADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOopt
FADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOopt
FADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOopt
FADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOopt
FADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOopt
FADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOqxZf8AH3H+P8qq1Ysv+PuP
8f5GgRl+PpzB4I1aQHGYgn/fTBf618717/8AEn/kQNT/AO2X/o1K8ArCt8R0UPhCvZ/g2gGgXsnd
rpl/JU/xrxivafg7/wAi3df9fb/+gR0qXxDrfCddcHNxJ/vGo806f/j4k/3j/OmV0HMLmjNJRQMX
NGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigB
c0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKA
FzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkoo
AXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSi
gBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpK
KAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmk
ooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGa
SigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0Z
pKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzR
mkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXN
GaSigBc0ZpKKAFzRmkooAXNGaSigBc1Ysv8Aj7T8f5VWq1p4zdA+gNAmYXxJ/wCRA1P/ALZf+jUr
wCvfviUwHgHUgTyxiA9/3q14DWFb4joofCFe0fB7/kW7r/r7f/0COvF69u+EcPl+FJXx/rLl2/RR
/wCy0qXxDrfCdNOf9Ik/3z/Oo80srbpnPqxpma6DnHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc
0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM0
3NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmj
NNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZ
ozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB
2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0Zo
AdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NG
aAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNz
RmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozT
c0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM
03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdm
jNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAH
ZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmg
B2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2at6ef37f7h/mKpZq
5px/fv8A7h/mKEJnLfFibyvBoT/nrdRp+jN/SvDq9q+L/wDyKdr/ANfyf+i5K8Vrnq/EdNH4Qr3r
4YqF8EWZHVjIT/38cf0rwWve/hmf+KHsf+2n/o16dH4hVvhNItmjNNzRmtjAdmjNNzRmgB2aM03N
GaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNN
zRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZoz
Tc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2a
M03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAd
mjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaA
HZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRm
gB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0
ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03
NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjN
NzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZo
zTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2
aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoA
dmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGa
AHZq3px/ft/uH+Yqlmr2mj55D7AU0D2OQ+L/APyKdr/1/J/6LkrxWvafjA4HhazTub1SPwR/8a8W
rnq/EdFH4Qr3r4af8iPY/wDbT/0Y9eC1794Bj+z+B7Af9M2f82Lf1p0fiFW+EtUU3NGa2MR1FNzR
mgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1
FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzR
mgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1
FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzR
mgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1
FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzR
mgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1
FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzR
mgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1
FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzR
mgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1aGl9Zfw/
rWbmtHSj80n4f1poT2OD+MsxWz0iHPDySvj6BR/7NXkleq/Gf/mCf9t//adeVVzVPiZ00vgQV9De
GQE8F6eB/wA+UZ/8hg18819C+HD/AMUZYf8AXlH/AOixVUd2TW2QmaM0zNGa2MR+aM0zNGaAH5oz
TM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+a
M0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAf
mjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaA
H5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRm
gB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0
ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0z
NGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjN
MzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5o
zTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+
aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoA
fmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGa
AH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzR
mgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM
0ZoAfmtHST80n4f1rLzWrpP3WPq39KEJ7Hn3xn/5gn/bf/2nXlVep/GZ1Mmix5+ZRMxHsdn+Bryy
uep8TOml8CCvoPw4ceDbD/ryj/8ARYr58r6H02P7L4YtYsY2WyJj6KBVUt2TW2RWzRmmZozWpiPz
RmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD
80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQ
A/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM
0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZm
jNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmm
ZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80Z
pmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/N
GaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0AP
zRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNA
D80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZoz
QA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80Zpma
M0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZ
mjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRm
mZozQA/NGaZmjNAD81saOcxt/vH+QrEzW1opzG/1P9KaE9jy/wCMMpbxFYw9ktN35uw/9lrzqvQP
i/8A8jZa/wDXin/oySvP655/Ezqp/Cgr6NmwulELwAAAPxr5yr6LuD/xLG/D/wBCq6XUit0MzNGa
ZmjNaGQ/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD8
0ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA
/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0
APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmj
NAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZ
ozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80Zp
maM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NG
aZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APz
RmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD
80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQ
A/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM
0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZm
jNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmm
ZozQA/NGaZmjNAD80ZpmaM0APzW3of3H+p/pWDmt7RP9X9Qf501uKWx5Z8X/APkbLX/rxT/0ZJXn
9d78XJA/i+BR1SzRT/305/rXBVzT+JnTT+FBX0TcnGmN+H86+fbKLz7+2i/vyqv5kCvfr1tungeu
K0pdSKvQzM0ZqPNGasyJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPN
GaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0
ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGa
AJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0Zq
PNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJ
M0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPN
GaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0
ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGa
AJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0Zq
PNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJ
M0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPN
GaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0
ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGa
AJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM10W
h82+fQf1Nczmum0A5tG/z3NVHcUtjxn4mymTx3fKc/u0iUf98Kf61yNdV8Sf+R/1P/tl/wCikrla
5pfEzqh8KL+hc+INNz0+1Rf+hivcdRP+gx/7w/ka8O0L/kYNN/6+ov8A0MV7dqJ/0GP/AHh/I1pT
2ZnV3RnZozUeaM1ZmSZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0
ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozU
eaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0AS
ZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUea
M0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZo
zUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0
ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozU
eaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0AS
ZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUea
M0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZo
zUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0
ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozU
eaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0AS
ZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZrpvD/
APx6t+H8zXK5rq9AGLZvov8AWnHcmWx4t8Sf+R/1P/tl/wCikrla6f4hyrN481Rl6BkX8RGoP8q5
iueXxM6ofCi/of8AyMGm/wDX1F/6EK9r1I4sox/tD+RrxvwxH5viXT1xnEob8uf6V7BqzYiiX3Na
U9mZ1N0Z2aM1Huo3VRBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZoz
Ue6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR
7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Hu
o3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6j
dQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1
AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UA
SZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJ
mjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEma
M1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZoz
Ue6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR
7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Hu
o3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6j
dQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1
AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UA
SZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZrsNBH+gbvX
A/QVxe6u18PnOmD/AHv/AGUVUdyZ7HgXi2UzeMNYY9ReSr+TEf0rGrV8T/8AI2az/wBf0/8A6Mas
quZ7nVHZG74N/wCRrsc+r/8AoDV6pq5/1P8AwL+leVeDv+Rqsv8Agf8A6A1epawf9T/wL+la0/hM
qnxGfmjNR7qN1USSZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo
3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jd
QBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1A
EmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UAS
ZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJm
jNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM
1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozU
e6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7
qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo
3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jd
QBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1A
EmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UAS
ZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJm
jNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM
1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEma7fw9/yDP+Bf8A
sorhN1d5oAI09v8ArocfkKqO5E9j5+8T/wDI2az/ANf0/wD6MasqtHxBKJ/EmqSjGJLyVhj3cms6
uZ7nUtjc8HDPiqy+r/8AoDV6frDf6n/gX9K848DR7/Esbf3I2b+Q/rXoOrt++jX0XP61rD4TKfxF
HNGaZmjNMkfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRm
gB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0
ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0z
NGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjN
MzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5o
zTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+
aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoA
fmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGa
AH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzR
mgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM
0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0
zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmj
NMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5
ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5r0PRFxpcZ/vFj+uK85zXo+i86TB/wAC/wDQjVw3InsfM8sh
lleQ9XYsfxplFFcp1nVeAP8AkYZP+vc/+hLXb6uf9LT/AHB/M1w/gH/kYJP+uB/9CWu11Y/6Uv8A
uD+ZraHwmM/iKWaM03NGaYh2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNN
zRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZoz
Tc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2a
M03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAd
mjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaA
HZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRm
gB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0
ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03
NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjN
NzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZo
zTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2
aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoA
dmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGa
AHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAeOSBXpGh/wDIHg/4F/6Ea82j5lQerCvRdMk+
zeHklPOyN3/UmqgZ1Nj5pooormOs6nwED/b8h7eQf/QlrstWP+lr/uD+Zrlfh9HnULqTH3UUfnn/
AArpdUbN8w9AB+lax+Exl8RVzRmm5ozTEOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGa
bmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzR
mm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs
0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA
7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0
AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmj
NADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5
ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0Zp
uaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NG
abmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOz
Rmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNAD
s0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQ
A7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM
0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNAEsR/fJ/vCu91BjB4DvHXqunSOM
evlk15/Ef3yf7wr0DVv+Sf33/YLk/wDRRq47Mie6PnOiiiuY6jtfh7/r776J/wCzVu6kf9Pl/D+Q
rB+H3+vvvon/ALNW5qR/0+X8P5CtY/CYy+Ir5ozTM0ZpgPzRmmZozQA/NGaZmjNAD80ZpmaM0APz
RmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD
80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQ
A/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM
0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZm
jNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmm
ZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80Z
pmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/N
GaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0AP
zRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNA
D80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZoz
QA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80Zpma
M0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZ
mjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAE0PMyf7wr0DVv+
Sf33/YKk/wDRRrz625nSu98QyfZfh7fZOMaeY/zTb/WrjszOe6PniiiiuY6jtPh+D5t8e2E/9mra
1Fs38uPb+QrM8Api0upPWTb+QH+NXrxt15Mf9sitV8Ji/iZFmjNJRQAuaM0lFAC5ozSUUALmjNJR
QAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0l
FAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozS
UUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjN
JRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM
0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5o
zSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALm
jNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAu
aM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC
5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUA
LmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQ
AuaM0lFAC5ozSUUATWx/fr+P8q7b4h5h+H2oheyxL+HmIK4i2P79fx/lXb/En/kQNT/7Zf8Ao1Kt
fCyJfEjwCiiiuc6Tv/Af/ILuP+ux/wDQVqe6/wCPub/ro386r+A/+QXcf9dj/wCgrU90f9Lm/wCu
jfzrVfCjF/EyOikzRmgYtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0U
maM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALR
SZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAt
FJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC
0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0A
LRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQ
AtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjN
AC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM
0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZo
zQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJm
jNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0AT23+vX2zXcfEn/kQNT/
AO2X/o1K4mwTzLpU9eP1rsPifN5XgW7Tj97JGn/j4b/2WrXwszl8SPBqKKK5zpO/8CqRpU5PeYkf
kKkuTm6lPq5/nUngxAmgo399mP6kf0quzbmJ9TmtuiMftMKKSikMWikooAWikooAWikooAWikooA
WikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWiko
oAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWi
kooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooA
WikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWiko
oAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWi
kooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooA
WikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWiko
oAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooA0dDUPrNq
p6NKg/8AHhW58XmK+EbYDo16gP8A3w5/pWJoB/4nln/12T/0IVtfF/8A5FO1/wCv5P8A0XJVfYZm
/jR4rRRRWB0nc+CdWt5I10m4jCyjc0LgnDjqQffqfp9Oex+wW3/PL/x4/wCNeLo7xSLJGzI6kMrK
cEEdCDWr/wAJTrf/AEEZfyH+FaRnZamcoNu6PU/sFt/zy/8AHj/jR9gtv+eX/jx/xryz/hKdb/6C
Mv5D/Cj/AISnW/8AoIy/kP8ACnzon2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZf
yH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/w
lOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QR
l/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FH
Og9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7n
qf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+
eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8
aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf8
8v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP
+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/C
U63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQ
Rl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+F
H/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/
9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If
4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9n
Luep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C
2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/j
x/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsF
t/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8A
x4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeW
f8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/
ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/I
f4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU
63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX
8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6
D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep
/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55
f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo
+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy
/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/4
15Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JT
rf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBG
X8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf
8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0
EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/h
RzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu
56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb
/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH
/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3
/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDH
j/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/
wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A
0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/
hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTr
f/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfy
H+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoP
Zy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9
gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/
48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7
Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/
AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jX
ln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt
/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZf
yH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/w
lOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QR
l/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FH
Og9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7n
qf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+
eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8
aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf8
8v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP
+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/C
U63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQ
Rl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+F
H/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/
9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If
4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9n
Luep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C
2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/j
x/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsF
t/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8A
x4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeW
f8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/
ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/I
f4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU
63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX
8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6
D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep
/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55
f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo
+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy
/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/4
15Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JT
rf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBG
X8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf
8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0
EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/h
RzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu
56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb
/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH
/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3
/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDH
j/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/
wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A
0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/
hR/wlOt/9BGX8h/hRzoPZy7nq8FrBb3EcyRDfG4dck9Qc+tVfircpd+C7OVDwb5MjPQ+XJxXmX/C
U63/ANBGX8h/hVe91vUtRtxBd3kksQYPsOMbgCAf1P50OorWBU3dMoUUUVkbH//ZDQplbmRzdHJl
YW0NCmVuZG9iag0KMTggMCBvYmoNCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0ltYWdlL1dpZHRo
IDE3MjEvSGVpZ2h0IDM2My9Db2xvclNwYWNlL0RldmljZUdyYXkvTWF0dGVbIDAgMCAwXSAvQml0
c1BlckNvbXBvbmVudCA4L0ludGVycG9sYXRlIGZhbHNlL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5n
dGggMjgyMT4+DQpzdHJlYW0NCnic7d1LcpvHGYZRLQVLwU7IbCRkFpKQWUPudmz4LsuWI9mObEuy
Atm6BAAJQgB/8CaqFFcTnDTb/zDdX9U5w2/0zp4CCtW4dQsAAID/g9/+HgAaVQrX6C0AtKoQrnHt
TQDw626Gq/YiAOjxB+ECIBThAiAW4QIgFuECIJRxKVx3AaAxj9frq0gJFwARCBcAoTwVLgAieSFc
AEQyEy4AIrkOl18VAhDCYn2aGjUSLgAiWK/PUqP2hAuACNbr89SoHeECIALhAiCU9foiNWpLuACI
YL1+nRo1FC4AIlivL1OjBsIFQATCBUAo6/WbwsMZm3B9CQBtuVt+8Um4AGhU15XCNUi389rjACDX
F65V7XEAkCuHa5huB7XHAUCuHK5t4QKgTeVw7abbi9rjACDXF65x7XEAkCuHaz/dfqg9DgBy5XCN
hAuANpXDNU63r2uPA4BcX7hqbwOAG8rh8uITAI0SLgBCES4AIrkvXABEIlwAhPJAuACI5JFwARDJ
WLgAiOS5cAEQiXABEMp0E66xcAEQwdEmXCPhAiCCo+5EuACIo+tOU6P2hAuACLruLDVqR7gAiKDr
zlOjtoQLgAiuwzUULgAi6LrXvx6uLwCgLb+E6zI1aiBcAETQdW8KD2cIFwCNEi4AQik/VXgVrvPa
4wAgVw7XQLgAaFM5XMN0W9UeBwC5cri20+2g9jgAyPWF60XtcQCQK4drN93+U3scAOTK4doXLgDa
VA7XKN2+rz0OAHJ94fq69jgAyJXDNRYuANpUDpcXnwBolHABEIpwARCKcAEQyT3hAiCSB33hugMA
bfnikXABEMlD4QIgkrFwARDJc+ECIJKpcAEQyXW4xsIFQARH3Ulq1Ei4AIig605To/aEC4AIuu4s
NWpHuACIQLgACKXrzlOjtoQLgAi67nVq1FC4AIig6y5TowbCBUAEwgVAKF33pvBwhnAB0Kjyi0+b
cH0OAI05LoZrkG5ntccBQO74uBSuYbqtao8DgFxfuA5qjwOAXDlc28IFQJvK4dpNt2e1xwFArhyu
/XT7sfY4AMiVwzVKtwe1xwFAri9c92qPA4BcOVxj4QKgTeVweTgDgEYJFwCh9IXrNgC0RrgAiOQr
4QIgEuECIJRvhAuASH4QLgAieSJcAETys3ABEIlwARDKZBOusXABEMF8E66RcAEQwfx4LVwAxHF8
fJIatVcK12cA0JZfwnWaGrUjXABEsFqdp0ZtCRcAEaxWZ6lRQ+ECIILV6kK4AIhjtXqdGjUQLgAi
WK3eFB7OEC4AGiVcAISyWpWeKhyk21ntcQCQ6wvXqvY4AMiVwzVMt9mnANCYcri2hQuANpXDtZtu
P9ceBwC5vnA9qj0OAHLlcO2n27e1xwFArhyukXAB0KZyuMbpdrf2OADI9YWr9jYAuKEcrrfCBUCb
hAuAUIQLgFD6wvUJADTmC+ECIJJ7y6VwARDHA+ECIBLhAiCUx8IFQCRPhQuASF4KFwCRXIdrXArX
xwDQmMPlcWrUSLgAiGC57FKj9oQLgAiWy5PUqB3hAiAC4QIglOXyLDVqS7gAiGC5vEiNGgoXABEs
l69TowbCBUAEwgVAKMvlm8LDGcIFQKPKLz5dhev0IwBozKtiuAbCBUCbXr0qhWuYbq9qjwOAXDlc
2+k2qT0OAHJ94fqp9jgAyJXDtZtuD2uPA4BcOVz7wgVAm8rhGqXbN7XHAUCuL1x3PgSAxpTDNRYu
ANpUDtfVrfY2ALhBuAAIRbgACEW4AIjktnABEIlwARDK3b5wfQAAbfnwW+ECIJLvFwvhAiCOJ8IF
QCTCBUAozzbhGgsXABFMN+EaCRcAEUwXS+ECII7FYpUatSdcAESwWKxTo3ZK4RoBQGMWi9PUqC3h
AiCC63ANhQuACBaLC+ECII7F4nVq1EC4AIhgsXhTeDhDuABolHABEEr5qcJBup3WHgcAuXK4hul2
VHscAOT6wvXyfQBoy6+Ea1u4AGjT0VEpXLtXf3VSexwA5Mrh2k+372uPA4BcOVyjdLtfexwA5PrC
dbv2OADIlcM1Fi4A2lQO19Wt9jYAuKEvXO8BQFuEC4BghAuAUIQLgEg+Fi4AIrkjXABEck+4AIhE
uAAI5TvhAiCSx33h+icANOapcAEQydP5PDVqLFwARPDf+SI1aiRcAEQwny9To/aEC4AI5vMuNWpH
uACIQLgACGU+X6dGbQkXABHM52epUUPhAiCC+fwiNWpQCte7ANAW4QIglvn8svBwhnAB0KjNwxlZ
uAbpdlJ7HADk+sI1rz0OAHLlcA3T7WXtcQCQK4drW7gAaFM5XLvp9qT2OADI9YXr37XHAUCuHK79
dLv7DgA05rAYrpFwAdCmw8NSuMbp9nHtcQCQ6wtX7W0AcEM5XG+FC4A2CRcAoQgXAKEIFwCRfCBc
AEQiXACEclu4AIjkq75w/QMAGvONcAEQyUPhAiAS4QIglPEmXGPhAiCCl5twjYQLgAheHi6EC4A4
Dg9fpUbtCRcAERweHqdG7QgXABEcHq5To7ZK4fo7ADTmOlxD4QIggoODU+ECII6Dg4vUqIFwARDB
wcFl4eEM4QKgUX3hOqk9DgByBwelpwoHwgVAm8rhGqbbvPY4AMiVw7Wdbi9qjwOAXF+4fqw9DgBy
5XDtptu3tccBQK4crn3hAqBN5XCN0u1O7XEAkCuHa5xuH/wNABojXACEUg7X1a32NgC4QbgACEW4
AAhFuAAIRbgAiOQ94QIgkk+EC4BIvhQuACIRLgBC+Vq4AIjkh75w/RUAGvNEuACI5Mlslho1Fi4A
Ing+m6dGjYQLgAhms0Vq1J5wARDBbLYSLgDiuA7XjnABEMFstk6N2hIuACKYzU5To4bCBUAEs9lF
atRAuACIQLgACGU2uyw8nCFcADRq83BGFq5Bup3UHgcAuXK4huk2rz0OAHJ94XpeexwA5Mrh2k63
Z38BgMaUw7Wbbo9qjwOAXDlc++l2v/Y4AMiVwzVKt9u1xwFAri9co9rjACBXDtdYuABoUzlcV7fa
2wDgBuECIBThAiAU4QIgFOECIJJ3hQuASIQLgFA+Ei4AIrkjXABEck+4AIjkO+ECIBLhAiCUJ5tw
jYULgAiezeZXD8GXwvVnAGiLcAEQy3S6SI3aEy4AIphOV6lRO8IFQATTaZcatSVcAERwHa6hcAEQ
wXR6KlwAxDGdXqRGDYQLgAim08vCwxnCBUCjyuEapNu69jgAyE2npacKr8I1rz0OAHLlcA3T7Vnt
cQCQK4drW7gAaFM5XLvp9rD2OADI9YXrfu1xAJArh2s/3T6rPQ4AcuVwjYQLgDaVwzVOt/drjwOA
XF+4am8DgBvK4fLiEwCNEi4AQhEuAEIRLgBCES4AInlHuACI5EPhAiCSz4ULgEiEC4BQ/iVcAETy
oC9cfwKAxvwoXABE8ngySY0aCxcAEfw0OUiNGgkXABFMJkepUXvCBUAEk8lSuACI4zpcO8IFQAST
SZcatSVcAEQwmZykRg2FC4AIJpPz1KiBcAEQgXABEMpkcll4OOMqXOva4wAgt3k4IwvXQLgAaFM5
XMN0m9ceBwC5cri20+1Z7XEAkOsL18Pa4wAgVw7Xbrrdqz0OAHLlcO0LFwBtKodrlG6f1h4HALly
uMbp9l7tcQCQEy4AQimHy4tPADRKuAAIpS9cEwBoj3ABEEopXE/fAkDTbpU+cgFAq24pFwCR5OFS
LgCadiNcv6m9CAB63AiXH2gA0LKb4fJlIQANK4Tr1h8BoFG/K4ULAEL4H94CKEINCmVuZHN0cmVh
bQ0KZW5kb2JqDQoxOSAwIG9iag0KPDwvRnVuY3Rpb25UeXBlIDAvU2l6ZVsgMjU2XSAvRGVjb2Rl
WyAwIDEgMCAxIDAgMV0gL1JhbmdlWyAwIDEgMCAxIDAgMV0gL0JpdHNQZXJTYW1wbGUgOC9Eb21h
aW5bIDAgMV0gL0VuY29kZVsgMCAyNTVdIC9PcmRlciAxL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5n
dGggNDgyPj4NCnN0cmVhbQ0KeJyNwmVXWgEYAOBfuFI23Ryl5KUuXLq7u7tBBRsFAxDFANe6bv/J
3nsuR4/7sLPnPPWL6/q/j69r49//8dfk6M7q7Z/48zsr+B/4s79+L8PTm9+IpRPi18khvjj8cvv4
c+Hm0SeYx3/MDyZzgw+5Q+L7bJ94le3hM73LTBef7r5LHxDfpvbhG5jce01M7L7Cd17GYfsFjLUv
YjtwHN2Go2hrFGmdw/DWWXgTnobgxkkQrg+Da8cBuHrkhysDH2weept9b6PvafQ8y133EjxwL+67
YH3PWdt11jqOasdebdsrO7Yy3LaWWtZiy1LcshQ2zfkNaMqtG7NrxsyqAaZX9KmmLtXQJZe1iSWo
iS9qYnV1tKaCkaoyXFGGyopQSR4sygNFmb8g8+elvhzmzWKejAS602JXCnUmUWdC5IgL7TGhLSaw
RQXWCN8S5ptDPHMIMQURY4Br8HMMPo7ex9Z52VoPS+tmaVxMtYuhdjJUjgWlfV5hg3S5lS6z0GRm
mtRMxUxUzEiRGChiA1msJ6O656h2TqSdE2rgM4H6KV+F5ylneYpZRDGDyGe4MviEI4WP2RgksSQk
lpjEFE8z0WkGOsUQTS1A4aN5KMDT+Q8hDfIeQCpE7lMgF96DZA78A4Rh2QoNCmVuZHN0cmVhbQ0K
ZW5kb2JqDQoyMCAwIG9iag0KPDwvUGF0dGVyblR5cGUgMi9TaGFkaW5nPDwvQ29sb3JTcGFjZS9E
ZXZpY2VSR0IvU2hhZGluZ1R5cGUgMi9Db29yZHNbIDM1NCAxMzIgMzU0IDc4XSAvRXh0ZW5kWyB0
cnVlIHRydWVdIC9GdW5jdGlvbiAxOSAwIFI+Pj4+DQplbmRvYmoNCjIxIDAgb2JqDQo8PC9UeXBl
L01hc2svUy9MdW1pbm9zaXR5L0cgMjIgMCBSL0JDIDIzIDAgUj4+DQplbmRvYmoNCjIyIDAgb2Jq
DQo8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9Gb3JtL0JCb3hbIDQ4IDc4IDY2MCAxMzJdIC9Hcm91
cCAyNCAwIFIvUmVzb3VyY2VzPDwvUGF0dGVybjw8L1AyNiAyNiAwIFI+Pj4+L0xlbmd0aCA0Mz4+
DQpzdHJlYW0NCi9QYXR0ZXJuIGNzIC9QMjYgc2NuDQo0OCA3OCA2MTIgNTQgcmUNCmYqDQoNCmVu
ZHN0cmVhbQ0KZW5kb2JqDQoyMyAwIG9iag0KWyAwIDAgMF0gDQplbmRvYmoNCjI0IDAgb2JqDQo8
PC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pg0KZW5kb2JqDQoyNSAwIG9iag0KPDwvRnVu
Y3Rpb25UeXBlIDAvU2l6ZVsgMjU2XSAvRGVjb2RlWyAwIDEgMCAxIDAgMV0gL1JhbmdlWyAwIDEg
MCAxIDAgMV0gL0JpdHNQZXJTYW1wbGUgOC9Eb21haW5bIDAgMV0gL0VuY29kZVsgMCAyNTVdIC9P
cmRlciAxL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTU4Pj4NCnN0cmVhbQ0KeJx9wYVOgmEA
htG7pUukRErpkhBQCYtUlLxBtmd7t+8fP5xzPNo4XLW/YGdne2Zj9W/4s1obfuXHsJKlLGQuM5ni
W77wKR94lwnGGGEob3jFCwboo4dndNFBGy08oYkG6qihigrKKKGIAvJ4xANyyEoGaaRwL0ncSQJx
iSEqEbmVsNxIyBCUgMFv5TN4rTxn3HZcFzivctg5AUDupZANCmVuZHN0cmVhbQ0KZW5kb2JqDQoy
NiAwIG9iag0KPDwvUGF0dGVyblR5cGUgMi9TaGFkaW5nPDwvQ29sb3JTcGFjZS9EZXZpY2VSR0Iv
U2hhZGluZ1R5cGUgMi9Db29yZHNbIDM1NCAxMzIgMzU0IDc4XSAvRXh0ZW5kWyB0cnVlIHRydWVd
IC9GdW5jdGlvbiAyNSAwIFI+Pj4+DQplbmRvYmoNCjI3IDAgb2JqDQo8PC9UeXBlL0V4dEdTdGF0
ZS9CTS9Ob3JtYWwvY2EgMS9TTWFzayAyMSAwIFI+Pg0KZW5kb2JqDQoyOCAwIG9iag0KPDwvVHlw
ZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvV2lkdGggMTE0Ni9IZWlnaHQgNDA2L0NvbG9yU3BhY2Uv
RGV2aWNlUkdCL0JpdHNQZXJDb21wb25lbnQgOC9GaWx0ZXIvRENURGVjb2RlL0ludGVycG9sYXRl
IHRydWUvU01hc2sgMjkgMCBSL0xlbmd0aCAyMDIyOT4+DQpzdHJlYW0NCv/Y/+AAEEpGSUYAAQEB
AHgAeAAA/+EAWkV4aWYAAE1NACoAAAAIAAUDAQAFAAAAAQAAAEoDAwABAAAAAQAAAABREAABAAAA
AQEAAABREQAEAAAAAQAAEnRREgAEAAAAAQAAEnQAAAAAAAGGoAAAsY//2wBDAAgGBgcGBQgHBwcJ
CQgKDBQNDAsLDBkSEw8UHRofHh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBD
AQkJCQwLDBgNDRgyIRwhMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy
MjIyMjIyMjL/wAARCAGWBHoDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcI
CQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAk
M2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqD
hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl
5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgEC
BAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcY
GRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOU
lZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3
+Pn6/9oADAMBAAIRAxEAPwDwO3gkurmK3hUNLK4RASBkk4HJ4H410f8AwrzxSf8AmGD/AMCYv/iq
xdH/AOQ3Yf8AXzH/AOhCvqEEjpWlOCluZVKjjsfPH/CvPFP/AECx/wCBMX/xVH/CvPFP/QLH/gTF
/wDFV9AS3kkchUBSB6imfb5f7qfka09lEz9tI8C/4V54p/6BY/8AAmL/AOKo/wCFeeKf+gWP/AmL
/wCKr337fL/dT8jR9vl/up+Ro9lEPbSPA/8AhXfin/oFj/wIi/8AiqP+Fd+Kv+gWP/AiL/4qvfPt
8v8AdT8jR9vl/up+Ro9lEPbSPA/+Fd+Kv+gWP/AiL/4qj/hXfir/AKBY/wDAiL/4qvfPt8v91PyN
H2+X+6n5Gj2UQ9tI8D/4V34q/wCgWP8AwIi/+Ko/4V34q/6BY/8AAiL/AOKr3z7fL/dT8jR9vl/u
p+Ro9lEPbSPA/wDhXfir/oFj/wACYv8A4qj/AIV34q/6BY/8CYv/AIqvfPt8v91PyNH2+X+6n5Gj
2UQ9tI8D/wCFd+Kv+gWP/AmL/wCKo/4V34q/6BY/8CYv/iq98+3y/wB1PyNH2+X+6n5Gj2UQ9tI8
D/4V34q/6BY/8CYv/iqP+Fd+Kv8AoFj/AMCYv/iq98+3y/3U/I0fb5f7qfkaPZRD20jwP/hXfir/
AKBY/wDAmL/4qj/hXfir/oFj/wACYv8A4qvfPt8v91PyNH2+X+6n5Gj2UQ9tI8D/AOFd+Kv+gWP/
AAJi/wDiqP8AhXfir/oFj/wJi/8Aiq98+3y/3U/I0fb5f7qfkaPZRD20jwP/AIV34q/6BY/8CYv/
AIqj/hXfir/oFj/wJi/+Kr3z7fL/AHU/I0fb5f7qfkaPZRD20jwP/hXfir/oFj/wJi/+Ko/4V34q
/wCgWP8AwJi/+Kr3z7fL/dT8jR9vl/up+Ro9lEPbSPA/+Fd+Kv8AoFj/AMCYv/iqP+Fd+Kv+gWP/
AAJi/wDiq98+3y/3U/I0fb5f7qfkaPZRD20jwP8A4V34q/6BY/8AAmL/AOKo/wCFd+Kv+gWP/AmL
/wCKr3z7fL/dT8jR9vl/up+Ro9lEPbSPA/8AhXfir/oFj/wJi/8AiqP+Fd+Kv+gWP/AmL/4qvfPt
8v8AdT8jR9vl/up+Ro9lEPbSPA/+Fd+Kv+gWP/AmL/4qj/hXfir/AKBY/wDAmL/4qvfPt8v91PyN
H2+X+6n5Gj2UQ9tI8D/4V34q/wCgWP8AwJi/+Ko/4V14q/6BY/8AAmL/AOKr3z7fL/dT8jR9vl/u
p+Ro9lEPbSPA/wDhXXir/oFj/wACYv8A4qj/AIV14q/6BY/8CYv/AIqvfPt8v91PyNH2+X+6n5Gj
2UQ9tI8D/wCFdeKv+gWP/AmL/wCKo/4V14q/6BY/8CYv/iq98+3y/wB1PyNH2+X+6n5Gj2UQ9tI8
D/4V14q/6BY/8CYv/iqP+FdeKv8AoFj/AMCYv/iq98+3y/3U/I0fb5f7qfkaPZRD20jwP/hXXir/
AKBY/wDAmL/4qj/hXXir/oFj/wACYv8A4qvfPt8v91PyNH2+X+6n5Gj2UQ9tI8D/AOFdeKv+gWP/
AAJi/wDiqP8AhXXir/oFj/wJi/8Aiq98+3y/3U/I0fb5f7qfkaPZRD20jwP/AIV14q/6BY/8CYv/
AIqj/hXXir/oFj/wJi/+Kr3z7fL/AHU/I0fb5f7qfkaPZRD20jwP/hXXir/oFj/wJi/+Ko/4V14q
/wCgWP8AwJi/+Kr3z7fL/dT8jR9vl/up+Ro9lEPbSPA/+FdeKv8AoFj/AMCYv/iqP+FdeKv+gWP/
AAJi/wDiq98+3y/3U/I0fb5f7qfkaPZRD20jwP8A4V14q/6BY/8AAmL/AOKo/wCFdeKv+gWP/AmL
/wCKr3z7fL/dT8jR9vl/up+Ro9lEPbSPA/8AhXXir/oFj/wJi/8AiqP+FdeKv+gWP/AmL/4qvfPt
8v8AdT8jR9vl/up+Ro9lEPbSPA/+FdeKv+gWP/AmL/4qj/hXXir/AKBY/wDAmL/4qvfPt8v91PyN
H2+X+6n5Gj2UQ9tI8D/4V14q/wCgWP8AwJi/+Ko/4V14q/6BY/8AAmL/AOKr3z7fL/dT8jR9vl/u
p+Ro9lEPbSPBP+FdeKv+gWP/AAJi/wDiqP8AhXXiv/oFj/wJi/8Aiq97+3y/3U/I0fb5f7qfkaPZ
RD20jwT/AIV14r/6BY/8CYv/AIqj/hXPiv8A6BY/8CYv/iq97+3y/wB1PyNH2+X+6n5Gj2UQ9tI8
E/4Vz4r/AOgWP/AmL/4qj/hXPiv/AKBY/wDAmL/4qve/t8v91PyNH2+X+6n5Gj2UQ9tI8E/4Vz4r
/wCgWP8AwJi/+Ko/4Vz4r/6BY/8AAmL/AOKr3v7fL/dT8jR9vl/up+Ro9lEPbSPBP+Fc+K/+gWP/
AAJi/wDiqP8AhXPiv/oFj/wJi/8Aiq97+3y/3U/I0fb5f7qfkaPZRD20jwT/AIVz4r/6BY/8CYv/
AIqj/hXPiv8A6BY/8CYv/iq97+3y/wB1PyNH2+X+6n5Gj2UQ9tI8E/4Vz4r/AOgWP/AmL/4qj/hX
Piv/AKBY/wDAmL/4qve/t8v91PyNH2+X+6n5Gj2UQ9tI8E/4Vz4r/wCgWP8AwJi/+Ko/4Vz4r/6B
Y/8AAmL/AOKr3v7fL/dT8jR9vl/up+Ro9lEPbSPBP+Fc+K/+gWP/AAJi/wDiqP8AhXPiv/oFj/wJ
i/8Aiq97+3y/3U/I0fb5f7qfkaPZRD20jwT/AIVz4r/6BY/8CYv/AIqj/hXPiv8A6BY/8CYv/iq9
7+3y/wB1PyNH2+X+6n5Gj2UQ9tI8E/4Vz4r/AOgWP/AmL/4qj/hXPiv/AKBY/wDAmL/4qve/t8v9
1PyNH2+X+6n5Gj2UQ9tI8E/4Vz4r/wCgWP8AwJi/+Ko/4Vz4r/6BY/8AAmL/AOKr3v7fL/dT8jR9
vl/up+Ro9lEPbSPBP+Fc+K/+gWP/AAJi/wDiqP8AhXPiv/oFj/wJi/8Aiq97+3y/3U/I0fb5f7qf
kaPZRD20jwT/AIVz4r/6BY/8CYv/AIqj/hXPiv8A6BY/8CYv/iq97+3y/wB1PyNH2+X+6n5Gj2UQ
9tI8E/4Vz4r/AOgWP/AmL/4qj/hXPiv/AKBY/wDAmL/4qve/t8v91PyNH2+X+6n5Gj2UQ9tI8E/4
Vz4r/wCgWP8AwJi/+Ko/4Vx4r/6BQ/8AAmL/AOKr3v7fL/dT8jR9vl/up+Ro9lEPbSPBP+FceK/+
gUP/AAJi/wDiqP8AhXHiv/oFD/wJi/8Aiq97+3y/3U/I0fb5f7qfkaPZRD20jwT/AIVx4r/6BQ/8
CYv/AIqj/hXHiv8A6BQ/8CYv/iq97+3y/wB1PyNH2+X+6n5Gj2UQ9tI8E/4Vx4r/AOgUP/AmL/4q
j/hXHiv/AKBQ/wDAmL/4qve/t8v91PyNH2+X+6n5Gj2UQ9tI8E/4Vx4r/wCgUP8AwJi/+Ko/4Vx4
r/6BQ/8AAmL/AOKr3v7fL/dT8jR9vl/up+Ro9lEPbSPBP+FceK/+gUP/AAJi/wDiqP8AhXHiv/oF
D/wJi/8Aiq97+3y/3U/I0fb5f7qfkaPZRD20jwT/AIVx4r/6BQ/8CYv/AIqj/hXHiv8A6BQ/8CYv
/iq97+3y/wB1PyNH2+X+6n5Gj2UQ9tI8E/4Vx4r/AOgUP/AmL/4qj/hXHiv/AKBQ/wDAmL/4qve/
t8v91PyNH2+X+6n5Gj2UQ9tI8E/4Vx4s/wCgUP8AwJi/+Ko/4Vx4s/6BQ/8AAmL/AOKr3v7fL/dT
8jR9vl/up+Ro9lEPbSPBf+FceLP+gUP/AAJi/wDiqP8AhXHiz/oFD/wJi/8Aiq96+3y/3U/I0fb5
f7qfkaPZRD20jwX/AIVx4s/6BQ/8CYv/AIqj/hXHiz/oFD/wJi/+Kr3r7fL/AHU/I0fb5f7qfkaP
ZRD20jwX/hXHiz/oFD/wJi/+Ko/4Vx4s/wCgUP8AwJi/+Kr3r7fL/dT8jR9vl/up+Ro9lEPbSPBf
+FceLP8AoFD/AMCYv/iqP+FceLP+gUP/AAJi/wDiq96+3y/3U/I0fb5f7qfkaPZRD20jwX/hXHiz
/oFD/wACYv8A4qj/AIVx4s/6BQ/8CYv/AIqvevt8v91PyNH2+X+6n5Gj2UQ9tI8F/wCFceLP+gUP
/AmL/wCKo/4Vx4s/6BQ/8CYv/iq96+3y/wB1PyNH2+X+6n5Gj2UQ9tI8F/4Vx4s/6BQ/8CYv/iqP
+FceLP8AoFD/AMCYv/iq96+3y/3U/I0fb5f7qfkaPZRD20jwX/hXHiz/AKBQ/wDAmL/4qj/hXHiz
/oFD/wACYv8A4qvevt8v91PyNH2+X+6n5Gj2UQ9tI8F/4Vx4s/6BQ/8AAmL/AOKo/wCFceLP+gUP
/AmL/wCKr3r7fL/dT8jR9vl/up+Ro9lEPbSPBf8AhXHiz/oFD/wJi/8AiqP+FceLP+gUP/AmL/4q
vevt8v8AdT8jR9vl/up+Ro9lEPbSPBf+FceLP+gUP/AmL/4qj/hXHiz/AKBQ/wDAmL/4qvevt8v9
1PyNH2+X+6n5Gj2UQ9tI8F/4Vv4s/wCgUP8AwJi/+Ko/4Vv4s/6BQ/8AAmL/AOLr3r7fL/dT8jR9
vl/up+Ro9lEPbSPBf+Fb+LP+gUP/AAJi/wDi6P8AhW/iz/oFD/wJi/8Ai696+3y/3U/I0fb5f7qf
kaPZRD20jwX/AIVv4s/6BQ/8CYv/AIqj/hW/iz/oFD/wJi/+Kr3r7fL/AHU/I0fb5f7qfkaPZRD2
0jwX/hW/iz/oFD/wJi/+Ko/4Vv4s/wCgUP8AwJi/+Kr3r7fL/dT8jR9vl/up+Ro9lEPbSPBf+Fb+
LP8AoFD/AMCYv/iqP+Fb+LP+gUP/AAJi/wDiq96+3y/3U/I0fb5f7qfkaPZRD20jwX/hW/iz/oFD
/wACYv8A4qj/AIVv4s/6BQ/8CYv/AIqvevt8v91PyNH2+X+6n5Gj2UQ9tI+ctb8L6z4dW3bVbP7O
txu8o+Yj7tuM/dJx1HWsivb/AIrKt34RhllUbonLpjjB3Kv8mNeIVlOPK7I2pycldl3R/wDkN2H/
AF8x/wDoQr6fr5g0f/kN2H/XzH/6EK+n60o7Myr7oo3H+vb8P5VFUtx/r2/D+VRVqYhRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHK/E3/AJEv8f8A2oleIV7f
8Tf+RL/H/wBqJXiFYVfiOmj8Jd0f/kN2H/XzH/6EK+nc18xaP/yG7D/r5j/9CFfTtXR2ZFfdFG4/
17fh/KoqluP9e34fyqKtTEKKKKQBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB
RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF
FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU
UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ
AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB
RRRQAUUUUAct8TP+RL/H/wBqJXiNe3fEz/kS/wAf/aiV4jWFX4jpo/CXdH/5Ddh/18x/+hCvpyvm
PR/+Q3Yf9fMf/oQr6cqqOzIr7oo3H+vb8P5VFUtx/r2/D+VRVsYhRRRSGFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBy/xL/wCRL/H/ANqJXiNe3fEv/kS/x/8AaiV4
jXPV+I6KPwl3R/8AkN2H/XzH/wChCvpuvmTR/wDkN2H/AF8x/wDoQr6bzV0dmRX3RQuf9e34fyqK
pbk/v2/D+VRZrUxCijNGaBhRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmj
NABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRm
jNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRR
mjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABR
RmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNAB
RRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNA
BRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNAHMfEr/AJEv8f8A2oleJV7b8Sv+RL/H/wBq
JXiVc9X4joo/CXdH/wCQ3Yf9fMf/AKEK+mc18zaP/wAhuw/6+Y//AEIV9MVdHZkV90Ubk/v2/D+V
RZqS5/17fh/Koq1MRc0ZpKKBi5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSU
UALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJ
RQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0
lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5oz
SUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmj
NJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAua
M0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5
ozSUUALmjNJRQBzXxJ/5Ev8AH/2oleJ17Z8SD/xRZ+v/ALUSvE656vxHRR+Eu6P/AMhqw/6+I/8A
0IV9L180aR/yGrD/AK+I/wD0IV9LVdHZkV90Ubk/6Q34fyqLNSXP/Hw34fyqGtTIdmjNNooAdmjN
NooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooA
dmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjN
NooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooA
dmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjN
NooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooA
dmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjN
NooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooA
dmjNNooA5z4j/wDIln6/+1ErxSvaviP/AMiWfr/7USvFa56vxHRR+EuaR/yGrD/r4j/9CFfSua+a
tI/5DVh/18R/+hCvpSro7Mivuijcn/SG/D+VQ5qS5/4+G/D+VRVqZC5ozSUUgFzRmkooAXNGaSig
Bc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKK
AFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmko
oAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaS
igBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0Zp
KKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRm
kooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNG
aSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigDnfiKf+KLP1/8AaiV4tXtHxE/5
Etvr/wC1ErxesKvxHRR+EuaR/wAhqx/6+I//AEIV9JZr5t0j/kNWP/XxH/6EK+kM1dHZkVt0Ubk/
6Q34fyqHNSXJ/wBIb8P5VFmtDIXNGaTNGaBi5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM
0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozS
ZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJm
jNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM
0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQ
AuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC
5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALm
jNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM
0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0Ac/8Q/+RLb6/wDt
RK8Yr2b4hHPgtvr/AO1ErxmsKvxG9L4S5pP/ACGbH/r4j/8AQhX0dmvnHSf+QzY/9fEf/oQr6MzV
0tmRW3RRuT/pD/h/Koc1Jcn/AEh/w/lUOa0Mh2aM03NGaBjs0ZpuaM0AOzRmm5ozQA7NGabmjNAD
s0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQ
A7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM
0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabm
jNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm
5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0Z
puaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7N
GabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AO
zRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNA
Ds0ZpuaM0AOzRmm5ozQBhfEH/kS3+v8A7USvGq9k8fn/AIot/qP/AEYleN1hV+I3pfCXNJ/5DNj/
ANfEf/oQr6KzXzrpP/IYsf8Ar4j/APQhX0RmqpdSa26KN0f9If8AD+VQ5p90f9If8P5VDmtTIfmj
NMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5
ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB
+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0Zo
AfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNG
aAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMz
RmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozT
M0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM
0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfm
jNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAxfHx/wCKLf6j/wBGJXjl
ew+PDnwXJ9R/6MSvHqwq/Eb0vhLelf8AIYsf+viP/wBCFfQ+a+eNK/5DFl/18R/+hCvoTNVS2ZNb
dFG6P+kP+H8qhzT7o/6Q/wCH8qhzWhmPzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZm
jNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmm
ZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80Z
pmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/N
GaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0AP
zRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNA
D80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZoz
QA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80Zpma
M0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZ
mjNAD80ZpmaM0AY/js/8UXJ9R/6MSvH69f8AHJz4Ll+o/wDRiV5BWNTc3pfCW9K/5C9l/wBfEf8A
6EK+gs18+6V/yF7L/rvH/wChCvf81VLqRW3RQuj/AKS/4fyqHNPuj/pL/h/Koc1oZj80ZpmaM0AP
zRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNA
D80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZoz
QA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80Zpma
M0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZ
mjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRm
mZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80
ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/
NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0A
PzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAGV43OfBcv1H/AKMWvIq9c8anPgub
6j/0YteR1jU3N6Wxb0v/AJC9l/13T/0IV77n3rwLS/8AkLWX/XdP/QhXvWaql1IrdDPuj/pL/h/K
oc1JdH/SX/D+VQ5qyB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB
2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0Zo
AdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NG
aAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNz
RmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozT
c0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM
03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdm
jNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAH
ZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmg
DM8ZnPguf6j/ANGLXktes+MjnwZP9V/9GLXk1ZVNzalsWtL/AOQtZ/8AXdP/AEIV7xmvB9M/5C1n
/wBd0/8AQhXu2aql1Jq9DPuz/pL/AIfyqHNPuz/pL/h/Koc1ZmPzRmmZozQA/NGaZmjNAD80Zpma
M0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZ
mjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRm
mZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80
ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/
NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0A
PzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjN
AD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZo
zQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80Zpm
aM0APzRmmZozQA/NGaZmjNAD80ZpmaM0AZ/jA58GXH1X/wBGLXlFereLjnwZcfVf/Ri15TWVTc2p
7FrTP+QrZ/8AXdP/AEIV7nmvDNM/5Ctn/wBd0/8AQhXuGadMmr0M+7P+kv8Ah/Koc0+7P+lP+H8q
gzVkEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEm
aM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1Hmj
NAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM
1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNA
EmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1H
mjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEm
aM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1Hmj
NAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM
1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNA
EmaM1HmjNAFPxYf+KMufqv8A6MWvK69S8VHPgy5+q/8Aoxa8trKpua09i1pv/IVs/wDrun/oQr27
NeI6b/yFLT/rsn/oQr2vNVTJq9DOuz/pT/h/Koc0+7P+lP8Ah/Koc1ZA/NGaZmjNAx+aM0zNGaAH
5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmg
B+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0Z
oAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zN
GaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNM
zRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5oz
TM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+a
M0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAf
mjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaA
H5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAq+KDnwZdfVf8A0YteXV6f4mOfBt39U/8ARi15
hWVTc0p7FnTf+Qpaf9dk/wDQhXtOa8W07/kKWn/XZP8A0IV7Pmqpk1ehm3h/0p/w/lUGalvD/pT/
AIfyqDNUSOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQ
A7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM
0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabm
jNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm
5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0Z
puaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7N
GabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AO
zRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNA
Ds0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AV/Epz4Nu
/qn/AKMWvMq9M8RnPg28+qf+jFrzOs57mlPYs6d/yE7T/rsn/oQr2TNeN6d/yE7T/rsn/oQr2LNV
TFU3Rm3h/wBKf8P5VBmpbw/6U/4fyqDNUQh2aM03NGaBjs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0
ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7
NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0A
OzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjN
ADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5o
zQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0Zpu
aM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGa
bmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzR
mm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs
0ZpuaM0AOzRmm5ozQBF4hP8AxRt59U/9GLXmlek+IDnwbe/VP/Rgrzas57mlPYs6d/yE7T/rsn/o
Qr2HNePaf/yErX/rsn8xXr2aqmTUM28P+lP+H8qgzUl4f9Kf8P5VBmmSPzRmmZozQA/NGaZmjNAD
80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQ
A/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM
0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZm
jNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmm
ZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80Z
pmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/N
GaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0AP
zRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNA
D80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0AM1858G3v1T/0YK83r0fXT/wAUdffVP/Rgrzio
nuaQ2LGn/wDIStf+uyfzFeu5ryLT/wDkJWv/AF2T+Yr1vNOmTUMy8P8ApT/h/KoM1LeH/Sn/AA/l
UGaokdmjNNzRmgY7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NG
abmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOz
Rmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNAD
s0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQ
A7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM
0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabm
jNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm
5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0Z
puaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AJrZ/4o6++sf/
AKMFec16LrX/ACJ19/2z/wDRgrzqonuXDYsaf/yErX/rsn8xXrVeS2H/ACEbX/rsn8xXrOadMmoZ
d4f9Kf8AD+VV81NeH/S3/D+VQZqhC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0AL
mjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAua
M0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5oz
SZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJ
mjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0ma
M0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZoz
QAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNA
C5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0AL
mjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNABrP/ACJ1/wD9
s/8A0YK87r0PWDnwdf8A/bP/ANGCvPKie5cNixYf8hG1/wCuyfzFer15RYf8hG1/66p/MV6tmnTJ
qGXef8fT/h/KoKmvD/pT/h/KoM1QkLRSZozSAWikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTNGaAF
opM0ZoAWikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTNGaAFopM0ZoA
WikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTNGaAFopM0ZoAWikzRmg
BaKTNGaAFopM0ZoAWikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTNGa
AFopM0ZoAWikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTNGaAFopM0Z
oAWikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTNGaAFopM0ZoAWikzR
mgBaKTNGaAFopM0ZoAWikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTN
GaAFopM0ZoAWikzRmgBaKTNGaADV/wDkTtQ/7Z/+jBXnteg6v/yJ+of9s/8A0YK8+qZ7lw2LFh/y
EbX/AK6p/MV6pmvK7D/kI2v/AF1T+Yr1PNOAqhl3h/0p/wAP5VBmprz/AI+n/D+VQVRKFzRmkopD
FzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkoo
AXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSi
gBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpK
KAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmk
ooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGa
SigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0Z
pKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigB2rf8ifqH/b
P/0YK8+r0DVf+RP1D/tn/wCjBXn9TPcqGzLFh/yEbb/rqn8xXqWa8u05S2p2ijqZkH/jwr1DNOAp
mXeH/Sn/AA/lUGatXUUj3Lsq5Bx39qh8iX+7+oqiSPNGak8iX+7+oo8iX+7+opAR5ozUnkS/3f1F
HkS/3f1FAEeaM1J5Ev8Ad/UUeRL/AHf1FAEeaM1J5Ev939RR5Ev939RQBHmjNSeRL/d/UUeRL/d/
UUAR5ozUnkS/3f1FHkS/3f1FAEeaM1J5Ev8Ad/UUeRL/AHf1FAEeaM1J5Ev939RR5Ev939RQBHmj
NSeRL/d/UUeRL/d/UUAR5ozUnkS/3f1FHkS/3f1FAEeaM1J5Ev8Ad/UUeRL/AHf1FAEeaM1J5Ev9
39RR5Ev939RQBHmjNSeRL/d/UUeRL/d/UUAR5ozUnkS/3f1FHkS/3f1FAEeaM1J5Ev8Ad/UUeRL/
AHf1FAEeaM1J5Ev939RR5Ev939RQBHmjNSeRL/d/UUeRL/d/UUAR5ozUnkS/3f1FHkS/3f1FAEea
M1J5Ev8Ad/UUeRL/AHf1FAEeaM1J5Ev939RR5Ev939RQBHmjNSeRL/d/UUeRL/d/UUAR5ozUnkS/
3f1FHkS/3f1FAEeaM1J5Ev8Ad/UUeRL/AHf1FAEeaM1J5Ev939RR5Ev939RQBHmjNSeRL/d/UUeR
L/d/UUAR5ozUnkS/3f1FHkS/3f1FAEeaM1J5Ev8Ad/UUeRL/AHf1FAEeaM1J5Ev939RR5Ev939RQ
BHmjNSeRL/d/UUeRL/d/UUAR5ozUnkS/3f1FHkS/3f1FAEeaM1J5Ev8Ad/UUeRL/AHf1FAEeaM1J
5Ev939RR5Ev939RQBHmjNSeRL/d/UUeRL/d/UUAR5ozUnkS/3f1FHkS/3f1FAEeaM1J5Ev8Ad/UU
eRL/AHf1FAEeaM1J5Ev939RR5Ev939RQBHmjNSeRL/d/UUeRL/d/UUAR5ozUnkS/3f1FHkS/3f1F
AEeaM1J5Ev8Ad/UUeRL/AHf1FAEeaM1J5Ev939RR5Ev939RQBHmjNSeRL/d/UUeRL/d/UUAR5ozU
nkS/3f1FHkS/3f1FAEeaM1J5Ev8Ad/UUeRL/AHf1FAEeaM1J5Ev939RR5Ev939RQBHmjNSeRL/d/
UUeRL/d/UUAR5ozUnkS/3f1FHkS/3f1FAEeaM1J5Ev8Ad/UUeRL/AHf1FAEeaM1J5Ev939RR5Ev9
39RQBHmjNSeRL/d/UUeRL/d/UUAR5ozUnkS/3f1FHkS/3f1FAEeaM1J5Ev8Ad/UUeRL/AHf1FAEe
aM1J5Ev939RR5Ev939RQBHmjNSeRL/d/UUeRL/d/UUAR5ozUnkS/3f1FHkS/3f1FAEeaM1J5Ev8A
d/UUeRL/AHf1FAEeaM1J5Ev939RR5Ev939RQBHmjNSeRL/d/UUeRL/d/UUAR5ozUnkS/3f1FHkS/
3f1FAEeaM1J5Ev8Ad/UUeRL/AHf1FAEeaM1J5Ev939RR5Ev939RQBHmjNSeRL/d/UUeRL/d/UUAR
5ozUnkS/3f1FHkS/3f1FAEeaM1J5Ev8Ad/UUeRL/AHf1FAEeaM1J5Ev939RR5Ev939RQBHmjNSeR
L/d/UUeRL/d/UUAR5ozUnkS/3f1FHkS/3f1FAEeaM1J5Ev8Ad/UUeRL/AHf1FAEeaM1J5Ev939RR
5Ev939RQBHmjNSeRL/d/UUeRL/d/UUAN1X/kT9R/7Z/+jBXn9egaspXwjqIYYP7v/wBGCvP6me5c
NgqaG6uLdSsM8sYJyQjkZ/KiioLLo8QaoAB9q6f7C/4Uf8JDqn/P1/5DX/Ciindisg/4SHVP+fr/
AMhr/hR/wkOqf8/X/kNf8KKKLsLIP+Eh1T/n6/8AIa/4Uf8ACQ6p/wA/X/kNf8KKKLsLIP8AhIdU
/wCfr/yGv+FH/CQ6p/z9f+Q1/wAKKKLsLIP+Eh1T/n6/8hr/AIUf8JDqn/P1/wCQ1/wooouwsg/4
SHVP+fr/AMhr/hR/wkOqf8/X/kNf8KKKLsLIP+Eh1T/n6/8AIa/4Uf8ACQ6p/wA/X/kNf8KKKLsL
IP8AhIdU/wCfr/yGv+FH/CQ6p/z9f+Q1/wAKKKLsLIP+Eh1T/n6/8hr/AIUf8JDqn/P1/wCQ1/wo
oouwsg/4SHVP+fr/AMhr/hR/wkOqf8/X/kNf8KKKLsLIP+Eh1T/n6/8AIa/4Uf8ACQ6p/wA/X/kN
f8KKKLsLIP8AhIdU/wCfr/yGv+FH/CQ6p/z9f+Q1/wAKKKLsLIP+Eh1T/n6/8hr/AIUf8JDqn/P1
/wCQ1/wooouwsg/4SHVP+fr/AMhr/hR/wkOqf8/X/kNf8KKKLsLIP+Eh1T/n6/8AIa/4Uf8ACQ6p
/wA/X/kNf8KKKLsLIP8AhIdU/wCfr/yGv+FH/CQ6p/z9f+Q1/wAKKKLsLIP+Eh1T/n6/8hr/AIUf
8JDqn/P1/wCQ1/wooouwsg/4SHVP+fr/AMhr/hR/wkOqf8/X/kNf8KKKLsLIP+Eh1T/n6/8AIa/4
Uf8ACQ6p/wA/X/kNf8KKKLsLIP8AhIdU/wCfr/yGv+FH/CQ6p/z9f+Q1/wAKKKLsLIP+Eh1T/n6/
8hr/AIUf8JDqn/P1/wCQ1/wooouwsg/4SHVP+fr/AMhr/hR/wkOqf8/X/kNf8KKKLsLIP+Eh1T/n
6/8AIa/4Uf8ACQ6p/wA/X/kNf8KKKLsLIP8AhIdU/wCfr/yGv+FH/CQ6p/z9f+Q1/wAKKKLsLIP+
Eh1T/n6/8hr/AIUf8JDqn/P1/wCQ1/wooouwsg/4SHVP+fr/AMhr/hR/wkOqf8/X/kNf8KKKLsLI
P+Eh1T/n6/8AIa/4Uf8ACQ6p/wA/X/kNf8KKKLsLIP8AhIdU/wCfr/yGv+FH/CQ6p/z9f+Q1/wAK
KKLsLIP+Eh1T/n6/8hr/AIUf8JDqn/P1/wCQ1/wooouwsg/4SHVP+fr/AMhr/hR/wkOqf8/X/kNf
8KKKLsLIP+Eh1T/n6/8AIa/4Uf8ACQ6p/wA/X/kNf8KKKLsLIP8AhIdU/wCfr/yGv+FH/CQ6p/z9
f+Q1/wAKKKLsLIP+Eh1T/n6/8hr/AIUf8JDqn/P1/wCQ1/wooouwsg/4SHVP+fr/AMhr/hR/wkOq
f8/X/kNf8KKKLsLIP+Eh1T/n6/8AIa/4Uf8ACQ6p/wA/X/kNf8KKKLsLIP8AhIdU/wCfr/yGv+FH
/CQ6p/z9f+Q1/wAKKKLsLIP+Eh1T/n6/8hr/AIUf8JDqn/P1/wCQ1/wooouwsg/4SHVP+fr/AMhr
/hR/wkOqf8/X/kNf8KKKLsLIP+Eh1T/n6/8AIa/4Uf8ACQ6p/wA/X/kNf8KKKLsLIP8AhIdU/wCf
r/yGv+FH/CQ6p/z9f+Q1/wAKKKLsLIP+Eh1T/n6/8hr/AIUf8JDqn/P1/wCQ1/wooouwsg/4SHVP
+fr/AMhr/hR/wkOqf8/X/kNf8KKKLsLIP+Eh1T/n6/8AIa/4Uf8ACQ6p/wA/X/kNf8KKKLsLIP8A
hIdU/wCfr/yGv+FH/CQ6p/z9f+Q1/wAKKKLsLIP+Eh1T/n6/8hr/AIUf8JDqn/P1/wCQ1/wooouw
sg/4SHVP+fr/AMhr/hR/wkOqf8/X/kNf8KKKLsLIP+Eh1T/n6/8AIa/4Uf8ACQ6p/wA/X/kNf8KK
KLsLIP8AhIdU/wCfr/yGv+FH/CQ6p/z9f+Q1/wAKKKLsLIP+Eh1T/n6/8hr/AIUf8JDqn/P1/wCQ
1/wooouwsg/4SHVP+fr/AMhr/hR/wkOqf8/X/kNf8KKKLsLIP+Eh1T/n6/8AIa/4Uf8ACQ6p/wA/
X/kNf8KKKLsLIP8AhIdU/wCfr/yGv+FH/CQ6p/z9f+Q1/wAKKKLsLIP+Eh1T/n6/8hr/AIUf8JDq
n/P1/wCQ1/wooouwsg/4SHVP+fr/AMhr/hR/wkOqf8/X/kNf8KKKLsLIP+Eh1T/n6/8AIa/4Uf8A
CQ6p/wA/X/kNf8KKKLsLIP8AhIdU/wCfr/yGv+FH/CQ6p/z9f+Q1/wAKKKLsLIP+Eh1T/n6/8hr/
AIUf8JDqn/P1/wCQ1/wooouwsg/4SHVP+fr/AMhr/hR/wkOqf8/X/kNf8KKKLsLIP+Eh1T/n6/8A
Ia/4Uf8ACQ6p/wA/X/kNf8KKKLsLIP8AhIdU/wCfr/yGv+FH/CQ6p/z9f+Q1/wAKKKLsLIP+Eh1T
/n6/8hr/AIUf8JDqn/P1/wCQ1/wooouwsg/4SHVP+fr/AMhr/hR/wkOqf8/X/kNf8KKKLsLIP+Eh
1T/n6/8AIa/4Uf8ACQ6p/wA/X/kNf8KKKLsLIP8AhIdU/wCfr/yGv+FH/CQ6p/z9f+Q1/wAKKKLs
LIP+Eh1T/n6/8hr/AIUf8JDqn/P1/wCQ1/wooouwsg/4SHVP+fr/AMhr/hR/wkOqf8/X/kNf8KKK
LsLIP+Eh1T/n6/8AIa/4Uf8ACQ6p/wA/X/kNf8KKKLsLIP8AhIdU/wCfr/yGv+FH/CQ6p/z9f+Q1
/wAKKKLsLIP+Eh1T/n6/8hr/AIUf8JDqn/P1/wCQ1/wooouwsg/4SHVP+fr/AMhr/hR/wkOqf8/X
/kNf8KKKLsLIjn1rUbm3e3muC0UmNy7FGcHI6D1AqhRRSGf/2Q0KZW5kc3RyZWFtDQplbmRvYmoN
CjI5IDAgb2JqDQo8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9JbWFnZS9XaWR0aCAxMTQ2L0hlaWdo
dCA0MDYvQ29sb3JTcGFjZS9EZXZpY2VHcmF5L01hdHRlWyAwIDAgMF0gL0JpdHNQZXJDb21wb25l
bnQgOC9JbnRlcnBvbGF0ZSBmYWxzZS9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDE0MTg+Pg0K
c3RyZWFtDQp4nO3Wx00dUBQAUTpzra7BOAeccwc4xw84hzWWl0i85Z0vpHOKGM3ODgAAAAAAAJwp
xwAF5QF655QH6CkP0FMeoLd3enmeAww5/HtiepQHCCgP0FMeoKc8QE95gJ7yAD3lAXrKA/SUB+gp
D9BTHqCnPEBPeYCe8gA95QF6ygP0lAfoKQ/QUx6gpzxAb12eZwBDDpQHyB38UR6gpjxAT3mAnvIA
PeUBesoD9JQH6CkP0FMeoKc8QE95gJ7yAD3lAXrKA/SUB+gpD9BTHqCnPEBPeYCe8gA95QF6ygP0
lAfoKQ/QUx6gpzxAT3mAnvIAPeUBesoD9NbleQowRHmAnvIAPeUBesoD9JQH6CkP0FMeoKc8QE95
gJ7yAD3lAXrKA/SUB+gpD9BTHqCnPEBPeYCe8gA95QF6ygP0lAforcvzBGCI8gA95QF6ygP0lAfo
KQ/QUx6gpzxAT3mAnvIAPeUBesoD9JQH6CkP0FMeoKc8QE95gN66PI8Bhmx+Kw9QUx6gpzxAT3mA
nvIAPeUBesoD9JQH6CkP0FMeoKc8QE95gJ7yAL11eR4BDFEeoKc8QE95gJ7yAD3lAXrKA/SUB+gp
D9BTHqCnPEBPeYCe8gC9dXkeAsxQHmALPv9SHqCmPEBPeYCe8gA95QF6ygP0lAfoKQ/QUx6gty7P
A4AhygP0lAfoKQ/QUx6gpzxAT3mAnvIAPeUBesoD9JQH6CkP0FMeoLcuz32AIZ9+Kg9QUx6gpzxA
T3mAnvIAPeUBesoD9JQH6K3Lcw9giPIAPeUBesoD9JQH6CkP0FMeoKc8QE95gJ7yAD3lAXrr8twF
GPLxh/IANeUBesoD9JQH6CkP0FMeoKc8QE95gN66PHcAhnxQHiCnPEBPeYCe8gA95QF6ygP0lAfo
KQ/QW5fnNsAQ5QF6778rD1BTHqCnPEBPeYCe8gA95QF6ygP01uXZA5ihPMAWKA/QUx6gpzxAT3mA
nvIAPeUBesoD9JQH6CkP0FuX5xbAEOUBeu++KQ9QUx6gpzxAT3mAnvIAPeUBesoD9NbluQkwQ3mA
LXirPEBOeYCe8gA95QF6ygP0lAfoKQ/QUx6gty7PDYAhb74qD1BTHqCnPEBPeYCe8gA95QF6ygP0
lAfoKQ/QW5fnOsAM5QG2QHmAnvIAPeUBesoD9JQH6CkP0FMeoKc8QG9dnmsAQ15/UR6gpjxAT3mA
nvIAPeUBesoD9JQH6CkP0FMeoKc8QE95gN66PFcBhigP0FMeoKc8QE95gJ7yAD3lAXrKA/SUB+gp
D9BTHqC3Ls8VgCGvjpQHqCkP0FMeoKc8QE95gJ7yAD3lAXrKA/SUB+gpD9BTHqCnPEBPeYDeujyX
AYYoD9BTHqCnPEBPeYCe8gA95QF6ygP0lAfoKQ/QUx6gpzxAT3mA3ro8lwBGKA+wDS8PlQeoKQ/Q
Ux6gpzxAT3mAnvIAPeUBesoD9JQH6CkP0FMeoKc8QE95gJ7yAD3lAXrr8lwEmKE8wBYoD9BTHqCn
PEBPeYCe8gA95QF6ygP0lAfoKQ/QUx6gpzxAT3mAnvIAPeUBesoD9JQH6CkP0FMeoKc8QE95gN66
PLsAQ14cKA9QUx6gpzxAT3mAnvIAPeUBesoD9JQH6CkP0FMeoKc8QE95gJ7yAD3lAXrKA/SUB+gp
D9BTHqCnPEBPeYCe8gA95QF6ygP0lAfoKQ/QUx6gpzxAT3mAnvIAPeUBesoD9NbluQAwY3dfeYDc
/kZ5gJryAD3lAXrKA/SUB+gpD9BTHqCnPEBPeYCe8gA95QF6ygP0lAfoKQ/QUx6gpzxAT3mAnvIA
PeUBesoD9JQH6CkP0FMeoKc8QG9dng3AmFV5jgDGnCjPf+ePAcbtnEJ+gFmnlQcAAACAs+kfpG8Q
rA0KZW5kc3RyZWFtDQplbmRvYmoNCjMwIDAgb2JqDQo8PC9GdW5jdGlvblR5cGUgMC9TaXplWyA1
MTJdIC9EZWNvZGVbIDAgMSAwIDEgMCAxXSAvUmFuZ2VbIDAgMSAwIDEgMCAxXSAvQml0c1BlclNh
bXBsZSA4L0RvbWFpblsgMCAxXSAvRW5jb2RlWyAwIDUxMV0gL09yZGVyIDEvRmlsdGVyL0ZsYXRl
RGVjb2RlL0xlbmd0aCA4NTA+Pg0Kc3RyZWFtDQp4nJWU5zubYRhH/0KrulvEliAiNkmERKwIIgRB
xGoRe+89W1106/pPeu48b40PPvS6zmfyPvfvnKiErChBH5Woj77GEJ1kiBGyY3RCrJATmyzECblx
KWCEe6mQJ6SZ4iEd8u9DhlnILHgQ4WFWITzSFwmGYnicXQJPckojlD3NhfJnxgp4nmd5brIkmKwJ
JltCvi3RXJloticVQJWusEpXVJ1c5EgudqQUO1NKalJLXZBWVptWXpcOFfUZlgbItDZmWd1ZtiZ9
pUdv9xjszYaqluxqaM1xeHOcbblOn7HGZ3S157k68mr9pjq/qb4zv77L3NBtbgwUgLunsKm30NNX
BM3B4pb+kpZQSetAqXegzDtY1jZU7huGivaRio4XFv9Li3/U2jlq7RqzdY1XdocrA2F7YMLeM1nV
OwXVfdOO4IwjOOvsn3WG5mpC8zUD867BBdfgYu3QUu3wUt3wct3ISj28WG14uQaNo+uNoxvusQ33
+GbT+FZTeMsT3vZMwE7z5C60TO1B6/R+6/SBdwYOvbOHbXNH4Js79s3DSfsCnLYvnnYsvupYeu1X
LJ91wsobYfVtl/Cuew3eC+vvA+sfAhtw3gObcAG9W/BR2P7Yt/1JY+dzUONLcFfoh72vV4T2voX2
r/gOAweKS43Dy0HhxzVHwtDRz1scK37B8E1OFL/vYgRO//wfd/+1CJH/eOM3DGlEfuHtn62+5dbX
HconX39+5DXUy1w/1N63m2/Yv6u9rTxy5LV59qsTcA7tLlsX6lJyso3zgPCBU3JQ7bJr7zg05+bo
2vWXzxiDWgXzYCRMRQazcMJ4ZEJzx2pRTEsGNnPA2Jic2p7aIYOUWYa3mShDZa6MlukyYLVkJs2w
mTcjZ+oMntkzfhRABHRACtRAEDRRviAO+iARKiEUWiEXiiEauiGdsg8NkRElERM9kRRVERZtkReF
ERmdkRq1ERzNkR3lER/9iQApIAhkgTiQCEJBLogG6SAgZET1hLCQFyJDalRziA8JIkTkiCiRJgJF
pogVySJcki+TlZQRNFU2EkfoyJ3qnmqg6qFqo+qkaibx1Cqanh8vSGDJrNbbVKMqsKSYICdrfZZQ
67RuS8CTJOaS9H95J/US/Ej5/wKcWpEGDQplbmRzdHJlYW0NCmVuZG9iag0KMzEgMCBvYmoNCjw8
L1BhdHRlcm5UeXBlIDIvU2hhZGluZzw8L0NvbG9yU3BhY2UvRGV2aWNlUkdCL1NoYWRpbmdUeXBl
IDIvQ29vcmRzWyA1NjkuODEgNjA5LjI1IDU2OS44MSAzMjYuNzVdIC9FeHRlbmRbIHRydWUgdHJ1
ZV0gL0Z1bmN0aW9uIDMwIDAgUj4+Pj4NCmVuZG9iag0KMzIgMCBvYmoNCjw8L1R5cGUvTWFzay9T
L0x1bWlub3NpdHkvRyAzMyAwIFIvQkMgMzQgMCBSPj4NCmVuZG9iag0KMzMgMCBvYmoNCjw8L1R5
cGUvWE9iamVjdC9TdWJ0eXBlL0Zvcm0vQkJveFsgNDc5LjEzIDMyNi43NSA2NjAuNSA0NjhdIC9H
cm91cCAzNSAwIFIvUmVzb3VyY2VzPDwvUGF0dGVybjw8L1AzNyAzNyAwIFI+Pj4+L0xlbmd0aCA1
OD4+DQpzdHJlYW0NCi9QYXR0ZXJuIGNzIC9QMzcgc2NuDQo0NzkuMTMgMzI2Ljc1IDE4MS4zNyAx
NDEuMjUgcmUNCmYqDQoNCmVuZHN0cmVhbQ0KZW5kb2JqDQozNCAwIG9iag0KWyAwIDAgMF0gDQpl
bmRvYmoNCjM1IDAgb2JqDQo8PC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pg0KZW5kb2Jq
DQozNiAwIG9iag0KPDwvRnVuY3Rpb25UeXBlIDAvU2l6ZVsgNTEyXSAvRGVjb2RlWyAwIDEgMCAx
IDAgMV0gL1JhbmdlWyAwIDEgMCAxIDAgMV0gL0JpdHNQZXJTYW1wbGUgOC9Eb21haW5bIDAgMV0g
L0VuY29kZVsgMCA1MTFdIC9PcmRlciAxL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTI4Pj4N
CnN0cmVhbQ0KeJy91IcNwCAQA8D95yG99z5UBrAd9CDlJkC8bedCJBFSi8wn1wqhFCqmZhrQMh3o
wQBGMDEzWJiV2YRdOLTT57K4Izw/inmn6UO83/txGnVNdX0aFRoqzB6NKCYZ046NwNbQcmEHaVVp
qdUCqMX4GBnvQJnmLmZXg4bcvQ6mfT0NCmVuZHN0cmVhbQ0KZW5kb2JqDQozNyAwIG9iag0KPDwv
UGF0dGVyblR5cGUgMi9TaGFkaW5nPDwvQ29sb3JTcGFjZS9EZXZpY2VSR0IvU2hhZGluZ1R5cGUg
Mi9Db29yZHNbIDU2OS44MSA2MDkuMjUgNTY5LjgxIDMyNi43NV0gL0V4dGVuZFsgdHJ1ZSB0cnVl
XSAvRnVuY3Rpb24gMzYgMCBSPj4+Pg0KZW5kb2JqDQozOCAwIG9iag0KPDwvVHlwZS9FeHRHU3Rh
dGUvQk0vTm9ybWFsL2NhIDEvU01hc2sgMzIgMCBSPj4NCmVuZG9iag0KMzkgMCBvYmoNCjw8L1R5
cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL05hbWUvRjMvQmFzZUZvbnQvQUJDREVFK1ZlcmRhbmEs
SXRhbGljL0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9Gb250RGVzY3JpcHRvciA0MCAwIFIvRmly
c3RDaGFyIDMyL0xhc3RDaGFyIDExNC9XaWR0aHMgOTQwIDAgUj4+DQplbmRvYmoNCjQwIDAgb2Jq
DQo8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0FCQ0RFRStWZXJkYW5hLEl0YWxpYy9G
bGFncyAzMi9JdGFsaWNBbmdsZSAtMTMvQXNjZW50IDEwMDUvRGVzY2VudCAtMjA3L0NhcEhlaWdo
dCA3NjUvQXZnV2lkdGggNTA4L01heFdpZHRoIDE5MTQvRm9udFdlaWdodCA0MDAvWEhlaWdodCAy
NTAvU3RlbVYgNTAvRm9udEJCb3hbIC00NTMgLTIwNyAxNDYxIDc2NV0gL0ZvbnRGaWxlMiA5NDEg
MCBSPj4NCmVuZG9iag0KNDEgMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQgMiAwIFIvUmVzb3Vy
Y2VzPDwvWE9iamVjdDw8L0ltYWdlNDMgNDMgMCBSL0ltYWdlNiA2IDAgUi9JbWFnZTcgNyAwIFIv
SW1hZ2U4IDggMCBSPj4vRm9udDw8L0YxIDkgMCBSL0YyIDEyIDAgUi9GNCA0NCAwIFIvRjUgNDkg
MCBSPj4vRXh0R1N0YXRlPDwvR1MxMSAxMSAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIv
SW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAgMCA3MjAgNTQwXSAvQ29udGVudHMgNDIgMCBS
L0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1Mv
U3RydWN0UGFyZW50cyAyPj4NCmVuZG9iag0KNDIgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29k
ZS9MZW5ndGggMTI5MT4+DQpzdHJlYW0NCnicnVdLb+M2EL4b8H/gkVrUNN+kgCCHPLrdRV1skxRb
IOhBdRTH2UjKynL69ztD24lkS4rig2mb0jy+mfmGQzL9Rk5OprPzLxeEn56Ss4tz8nM84oQzzrmQ
kjviJCdGc1Km49H3TySHx4wroeEd5Sys1sSkXLxKcW4F1w2x+0/j0Z/jEbmcnRNSMykOTLYIb2w6
ETNnCLxGjNr9ZNKAAJln49H0S5YsUq3IRUHaTMk3U5OtJS5itwXqlRAtRg3f2dQxE9IQJZiHnTgI
1ezaLrPq0KwxIu43qx0A20A1xAbDGqHWLboui/rQovXabixKrUVbdAVXr9HlAaLlMTrhgvU3s77L
rJn+nuQLQh+Tyddv0daHsxuQ+1UQzyCnN/dgJ5gQYEQxr2BfO0luMiwpG3sCRTT9fA0xWax2W5/H
o1sqo4mmHBeBS/g7tVP4NtRF/5Cbr+PR5U2LV7bmyKttY5iUNdu3lPTpcF3Idgq1Ewx44pkyO4Wq
T6Fv1WE3AXnT0etU3IiwJNKx2DZCLEEj0EF7y5zbxridtofbVyHqZ8n8x6KMNC3WGPD8ruZQw3ct
mfN1S+84L3jDe02k2PdeIN9AJ1CBb3WecO7dadOFAJ3vV5eCWPqmMP07jSzNSQbrPI0UOGjovMhg
fS7yFEDm1aoDnzSKiT11/fhEA58hwjO/RwCzwSc1i+NXfGeXLfjAdF3SOWZ9UxLA5SSaWDoDYOeX
0URS8uUav646IInYMiOaSvohycGQgNrqOEg1yTZIq+K+WuJe+bMrU1BITjQV9cNSQ2EpD6o3OgVy
xeIqoeyRQs2dwJ6PQa9pv6UvMwDckTfgOeSt8Xo/QD0YoOVMxMc0ig9CfbNzSy+KjJNsnj5FE0WL
ReDlxNElNva8SkvYuE+Arx3p9p6JpkIStfnB4OBr9UV5ZoZR2gxtWYo75s2RLasuTBXJEuhPjwUs
JXkuIBjLCOOyIpGnxT2BXga1gr35Enee4GGxWEaOzjsCpqRhMC81rPTDtkPLR3rz2v0/VhB1Sfpb
8R+WAnbnqiCbOnhM51W9F3QUA5xC8Z62fmxuMDarmTgOW01yD1uarUPVJxWePqHsEd/1VecxBAe6
2VPZD9APBgixM8cBrEnuAXzC5IUMvqQkCz+Q4CUC7jpoDVO6qfOQ0KKH0HBhYbEeFJx4KKFFzHFe
PI7QdWE6Sx5xmipDvnH8yFdVmdRpLfmW1/N1WaZhN2zuaN7Fa+eZbdrqBS/50MoQFlqsPqYy6pL0
rFjndwSK4qFYVV3Z5xoH1oZcPwqxl0Jh9lMYCyZgoBbaI3V6U3goLOAKJExDGEp8telFDzhEVvBJ
y2KR5mmxXm1orDj9t0yTH2FkiSaeZiHBii4g1bBXbf8W+S/wWHo6T3L4mxeoVyisigobfoFUetqc
iFLRl2VC5s9rrJSuOdxycFQ3/e0PoBwcQBkzdXQAa8L0D2RA3jXeaI63oIbApPNd6AJ77ybl/AHD
FYcIrzAja8zTCjcFUCskZYY91mBchaEpXgHWeHQmMFzabt9UrJBjdXP9wW0bLW07ySBxQr5Hsq6e
V5em3wFyGioM2m15t4Hp6PN2u+wKprUhmHVVnYF3Guetxrt3mFWYVvR2dCMz+NlzlMH1w+mmiv5g
Dh5j4RJq3g1lWxhrgvSvPE+qdZk8YdMlkZD1a0i4goShZImPi5ys0gy7eF4F8PMu1CqWrOnhIej/
AQcEAa0NCmVuZHN0cmVhbQ0KZW5kb2JqDQo0MyAwIG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1YnR5
cGUvSW1hZ2UvV2lkdGggMTAyNC9IZWlnaHQgNzY4L0NvbG9yU3BhY2UvRGV2aWNlUkdCL0JpdHNQ
ZXJDb21wb25lbnQgOC9GaWx0ZXIvRENURGVjb2RlL0ludGVycG9sYXRlIHRydWUvTGVuZ3RoIDE4
NzExPj4NCnN0cmVhbQ0K/9j/4AAQSkZJRgABAQEAAAAAAAD/7AARRHVja3kAAQAEAAAAZAAA/9sA
QwAIBgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8n
OT04MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy
MjIyMjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgDAAQAAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAA
AAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQy
gZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVm
Z2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS
09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYH
CAkKC//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1Lw
FWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5
eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj
5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A9/ooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigDxD/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i688or6X6pQ/lR839br/wAz
PQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1
J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP
/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLr
zyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz
0P8A4XH4h/589L/79Sf/ABdH/C4/EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fP
S/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q
/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4u
vPKKPqlD+VB9br/zM9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW
6/8AMz0P/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/58
9L/79Sf/ABdH/C4/EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/
wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k
/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9
br/zM9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcf
iH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH
/C4/EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/3
6k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qU
P5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/AOFx
+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/AL9S
f/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH/C4/EP8Az56X
/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6p
Q/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9
D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/AOFx+If+fPS/+/Un
/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8
+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH/C4/EP8Az56X/wB+pP8A4uvP
KKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ
/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L
/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/
AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i68
8oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH/C4/EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br
/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0
v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C
4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/
AOLrzyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1u
v/Mz0P8A4XH4h/589L/79Sf/ABdH/C4/EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+I
f+fPS/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8
Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fq
T/4uvPKKPqlD+VB9br/zM9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/
lQfW6/8AMz0P/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4
h/589L/79Sf/ABdH/C4/EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/
8XR/wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/
AH6k/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD
+VB9br/zM9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P
/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/
ABdH/C4/EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z5
6X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688o
o+qUP5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/
AOFx+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/
AL9Sf/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH/C4/EP8A
z56X/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/36k/+Lrzy
ij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/
ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zMKKKK6DnCiiigAoP
AopD0oA27uLR7BoYZbK6mkaGORnFwFBLDPAxUH2nQ/8AoGXf/gV/9jRr3/H7B/16Q/8AoAqna2Fz
eJNJDC7QwKHmkVciNc4yfasopct2/wATVt81kvwLn2nQ/wDoGXf/AIFf/Y0n2rQ/+gZd59rr/wCx
qVL3RtPH+j6edQmH/La8Yqn4Iv8AU1ZbxbrdsQkS21iCAVSKyROPxGTSs3svvZSaW7+5XKP2rQx1
0y7H/b0P/iaVU0e8bZG1xYyn7rTMJIyfcgZH1rWsPE/iTUpZIhDbakI4zJJFNaxt8g6k8A0/UNIs
NX0O41bTbQ2F3aKr3diG3IY26SJ3A9qnm5XaWnzuVy8yvHX5WOYuraazuZLedNkqHBGc/iD3FRVp
XjfaNC0+4c5ljZ7fd3KjBX8skVm1vF3WpzyST0CiiimIKKKKACiiigAooooAKKKKACiiigAooooA
KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo
oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii
igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKOl
dZa6BoekwR3XiXUt0joHTT7I75CDyNzdF+lROahuXCDnscrFFJPKIoY3kkPREUsT+ArqNN+HPibU
lDiw+zRn+O5YJx9OtW2+IR02MweGtGtNMi6eYy+ZKfqa56/8Sa3qjE3mqXUoPVfMIX8hxWTdaWyS
9dX/AF8zRKjHdt+mh1y/DCG2XOqeJ9PtiOqqQSPzIpw8F+Co+JvGSs3+yV/+vXnRAJyeT6mjA9BR
7Gq96j+5Fe2pLamvvZ6UvgLwjdfLaeMY9/YOyf4iorr4Raj5Rl0zVLO9TsM7SfxGRXnW0HsKt2Oq
X2mTCSxvZ7Zwesbkfp0NS6VZfDP70Cq0X8UPuZPq2g6poc3l6lZS25PRmGVb6MODWdXqnhr4kQ6q
F0bxVDDLFN8guCo2k9t47fUVheP/AAQPDU631hubTJ2wATkxN6Z7g9jRTxEuf2dVWfTsx1KEeT2l
J3XXujiKKKK6jlCiiigAooooAKKKKACiiigApD0paQ9KBG/dWDap4j02wQ4a4ht48+mVGT/OtqzW
1v4PFXlxlLextBHaqrFcKHxk4PzE9Tn1rIl1D+yfFGlaht3C3it5CvqAoz+ma1dY0DVrFrzUvDrS
Xmi6kpJe3G8hCclHXqCDXHPom7bW+/U7YLdpX7/cbOoaHoD3F/pEeiwwyQaSL1LuOVt+/bnGCcYq
5f6bp2ta/aRX1pERY6LHdM7SMBNxgK2Oijk8c8157Lr2vfbZriSSYXEtt9lkJhxmLGNuMVbstW8X
3MliLM30r2a7ICkGSFIxtJxyPrWboVEk+b8WWq8G2uX8Dr9LtdGi1WS40p7ZZZtIuftMFq7PGjAD
BUtzg1z+jW8nh/wVq2qX4MTanCLWzhf70gJyXx6CtiPw94vvphq2u6pDpMUcLRF5NinyyPmUKOOf
evPb7ULvUZEa7uZJzEgjj3HhUHAAHYU6UOdtKV9r9dvMVWfIk3G29um/kTyceGrb/r6k/wDQRWfW
jJ/yLVt/19Sf+gis6u2PU459AoooqiQooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii
igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK
ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA
KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACtHTNEvNVt7y5hULbWcRkmm
c4VcdF+p9KrWFlPqWoW9lbLumnkEaD3Ndl47uIdFtbXwjppxb2qiS7cdZpTzz/P8ayqVGpKEd3+R
rTppxc5bL8xNMt/Bj+BZJb2WAa75UhVTIwbdzt46elcLkDqea9e0DSdOm+EM15JY273It5iJWjBY
EE4OaX4X6bplx4Qu7q8sLe5aOdzukiDNgKDjmuRYlU1OWrs7f8MdTw7qOEdFdX/4c8g3D1FbnhTw
9/wk+urppuTb7o2fzAu7p2xXp/h7WvCHi7UJNLi8OxxOYy/7yBACB15HTrWP4Y0eLQfjFcafbk+R
HC7RgnJClQcfhVSxbcZRs4ySuTHCpSjK/NFuxwvijQh4b1+bSxcG48tVbzCu3ORnpWMSB1Net/Ef
VNMvL6Xw/DpedYmeJVuti9yMDPWrt1B4W+GumWqXWni+v5xyxQMzkdTzwBRDFyVON4tyf4+Y54VO
crSSivw8jxgEEcV6tp3h/SJPhFJqb6fA16LaRhOV+bIJwc1N4j0HRPFng1/Eeh2q21zCjOVVNm4L
95WA4z71c0r/AJIdL/16Sf8AoRrOtiPaQi46PmSZpRw/s5yT1Ti2jy2W80pvDUVqlnjUQ+Wmx1H1
r1bQpT4q+Ec8F388sUMkW48klBlT/KvEhwo+le3eHIT4Z+EtxcXQKPLDJOVPBBcYUfyqsalGMbb3
0IwcnKUr7W1PER0FLSDpzS16BwBRRRQAUUUUAFFFFABRRRQAUHpRQehoEbWtWjS3Vu4ns1zaQ8SX
UaMPlHUEg0aTqGr6HIX03WLW3z95Vv4irfUFsVwXj8f8VKv/AF6Qf+ixWFdaTf2NvDcXVpLDFMMx
s64DV4k8fNXhyppHuQwEHafM02e/J8RvE6rh7zQ5T/eeaHP/AKFUNz8QfFlwpVdX0qAH/njcQA/m
WNeBx2F1LaG6SB2gEgj3gcFiM4Hviq+OeawWKX8kfuN3hW/ty+89fvpdR1OQyX+r21y/rLqMTY/D
diqn2Fs/8fWn/wDgdF/8VXleKOK2WZVFokv6+Zi8tpt3cn/XyPYbqEw+HLVTJC+bqTmGZZB90d1J
rKqn4Z/5ExP+v5//AEAVcr1cLUdSkpvqeXiqap1XBdAooorc5wooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAO5+E
9mtz4zEzjP2aBpF+p4/qa5nxFcvd+JdTnkJLNcvn8CQP5V0vwovVtfGixOQBcwPGPqMEfyNZnj3R
pNG8XXqMuIrhzPC3YqxyfyOa5Iu2Kkn2Vjqkr4ZNd3c9E8OH/iys/wD17z/zNR/Cz/kQdS/66S/+
gCvO9J8ZajpWg3miqkc1ncoy7X4MZYYJB/pVnw746vfDmiz6Zb2cEsczMzO7EEZGO1YVMLUcZpdZ
XOiGJpqUG+isaHwk/wCR3P8A17SfzFdVbHHx3uc/8+p/9AFeZ+GfEU/hjVzqNvBHNIY2j2SEgYOP
T6VLf+K9QvPFP/CQRBLW8BUqI+VGBjv1BFa1cPOdWTWzjYypV4QpRi91K51vi+Oax+LNtqU8Eq2a
ywMZih2Y6deldv431y80SO2ubfQY9UgcFXcjcYz24APBrzDX/iPqPiLQ5NLurK1RJCpaSMtnIOeh
qfQvinrOj2SWk8MV9FGNqNISrgdhkdawlhqsowcopuOlr7o3jiaUZSSk7S1vbY3b3x9ra+HJpn8J
rbWE4aHzdxUAsMZxj9a0tJIPwOlwc4tJR/48a4nxH8SdX8Q2T2PlQ2drIMSJH8zOPQk9vpWZpXif
V7XR7nQLVftFtdgoIdhZlJ6lcVX1WTgtEndPcj6zHneras1sdN8P/h82qi31rVNo08HfFDnJlIPU
+i8fjT/id4xh1ORdD02QPaQNmeRfuu46KPYVy0ni/WF8PwaDDN9mtIFKMIuHfkkhj/hWBW8aEpVf
a1XtsjGVeMaXs6a33YUUUV1nIFFFFABRRRQAUUUUAFFFFABQehooPT8KAOb8f8eJl/69IP8A0AVr
xappEkVvc3t/ZvrDQmOO5WFmRfkAVpVIxuGMAgGl8WeF9W1jWEvLC3jmga2hUOJ0HIQAjBOaw/8A
hBPEf/Pin/gRH/8AFV8xUhLnenU+npzjyLXodHF4usba/sI7a8jjt4r8yOVtwFAMSqzgY4Bfcceh
qG21TwubWF74W0l/5ZkkkEBwJIidijAwRJkZ47Vhf8IJ4i/58U/8CY//AIqj/hBPEX/Pin/gRH/8
VWfJLsXzx7o3n1vQ7bRP3E8Mt8sDi3kaAF0JVeCNoA53AdfWsvxVqmlXumWsenpbYyjLtXbJF8gD
KflAwWyepqr/AMIJ4i/58U/8CY//AIqj/hBPEf8Az4p/4ER//FUckuwc8e6Nzwz/AMiYn/X8/wD6
AKuUabpd3o/heK1vkWOdrt3CCRWO3aBngmivocEmqEU/P8z5/HNOvK3l+QUUUV1HKFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQBNZ3c1hewXdu22aBw6H0Ir3CJ9D+KPhtFmPlXkQ+YL/rIHxyR6qa8JqxY393pl4l3
Y3EkE6dHQ4/A+ormxGH9raUXaS2Z0Yev7O6krxe6Om1v4b+INHdmjtzfW46S24yce69RXKSwywOU
mikiYdVkUqf1r0/RfjHNEqxa1Yebjgz25wfxU/0NdZB4/wDB2qqBPdQqT1W6hx/MEVz/AFjE09Kk
L+aOj6vh6mtOdvJngG4eoo3D1FfQ4uPAtz827RGz6iMU8Xfgi2G4SaImO4EdDzB/yMf1Bfzo+eoY
JrhtsMMkh9EQt/Kt3T/AviXUyPJ0qaNT/HP+7H617LL468H6evyajajH8MEZP8hWHf8Axi0WEEWV
nd3TdiwEY/Wl9bxE/gp/f/SD6rQh8dQydI+DcjFX1jUQq94rYcn/AIEa7eDTfC/gexaYLb2Y24M0
pzI34nk/QV5fqvxY8QXytHZrBYRnvGN7/mf8K4u7vbrUJzPeXMtxKeryuWNL6tiK38aVl2Q/rOHo
/wAKN33Yy4YPczOpyrOzA+xNR0UV6Z5oUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAmB6UYHpS0UAJ
gelGB6UtFACYHpRgelLRQAmAKWiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAEwPQUbR6
ClooAKKKKACiiigAooooAKKKKACiiigAooooA//ZDQplbmRzdHJlYW0NCmVuZG9iag0KNDQgMCBv
YmoNCjw8L1R5cGUvRm9udC9TdWJ0eXBlL1R5cGUwL0Jhc2VGb250L0FCQ0RFRStWZXJkYW5hL0Vu
Y29kaW5nL0lkZW50aXR5LUgvRGVzY2VuZGFudEZvbnRzIDQ1IDAgUi9Ub1VuaWNvZGUgOTM2IDAg
Uj4+DQplbmRvYmoNCjQ1IDAgb2JqDQpbIDQ2IDAgUl0gDQplbmRvYmoNCjQ2IDAgb2JqDQo8PC9C
YXNlRm9udC9BQkNERUUrVmVyZGFuYS9TdWJ0eXBlL0NJREZvbnRUeXBlMi9UeXBlL0ZvbnQvQ0lE
VG9HSURNYXAvSWRlbnRpdHkvRFcgMTAwMC9DSURTeXN0ZW1JbmZvIDQ3IDAgUi9Gb250RGVzY3Jp
cHRvciA0OCAwIFIvVyA5MzggMCBSPj4NCmVuZG9iag0KNDcgMCBvYmoNCjw8L09yZGVyaW5nKElk
ZW50aXR5KSAvUmVnaXN0cnkoQWRvYmUpIC9TdXBwbGVtZW50IDA+Pg0KZW5kb2JqDQo0OCAwIG9i
ag0KPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9BQkNERUUrVmVyZGFuYS9GbGFncyAz
Mi9JdGFsaWNBbmdsZSAwL0FzY2VudCAxMDA1L0Rlc2NlbnQgLTIwNy9DYXBIZWlnaHQgNzY1L0F2
Z1dpZHRoIDUwOC9NYXhXaWR0aCAyMDA2L0ZvbnRXZWlnaHQgNDAwL1hIZWlnaHQgMjUwL1N0ZW1W
IDUwL0ZvbnRCQm94WyAtNTYwIC0yMDcgMTQ0NyA3NjVdIC9Gb250RmlsZTIgOTM3IDAgUj4+DQpl
bmRvYmoNCjQ5IDAgb2JqDQo8PC9UeXBlL0ZvbnQvU3VidHlwZS9UeXBlMC9CYXNlRm9udC9BQkNE
RUUrV2luZ2RpbmdzL0VuY29kaW5nL0lkZW50aXR5LUgvRGVzY2VuZGFudEZvbnRzIDUwIDAgUi9U
b1VuaWNvZGUgOTQyIDAgUj4+DQplbmRvYmoNCjUwIDAgb2JqDQpbIDUxIDAgUl0gDQplbmRvYmoN
CjUxIDAgb2JqDQo8PC9CYXNlRm9udC9BQkNERUUrV2luZ2RpbmdzL1N1YnR5cGUvQ0lERm9udFR5
cGUyL1R5cGUvRm9udC9DSURUb0dJRE1hcC9JZGVudGl0eS9EVyAxMDAwL0NJRFN5c3RlbUluZm8g
NTIgMCBSL0ZvbnREZXNjcmlwdG9yIDUzIDAgUi9XIDk0NCAwIFI+Pg0KZW5kb2JqDQo1MiAwIG9i
ag0KPDwvT3JkZXJpbmcoSWRlbnRpdHkpIC9SZWdpc3RyeShBZG9iZSkgL1N1cHBsZW1lbnQgMD4+
DQplbmRvYmoNCjUzIDAgb2JqDQo8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0FCQ0RF
RStXaW5nZGluZ3MvRmxhZ3MgMzIvSXRhbGljQW5nbGUgMC9Bc2NlbnQgODk5L0Rlc2NlbnQgMjA1
L0NhcEhlaWdodCA3NzEvQXZnV2lkdGggODkwL01heFdpZHRoIDEzNTkvRm9udFdlaWdodCA0MDAv
WEhlaWdodCAyNTAvU3RlbVYgODkvRm9udEJCb3hbIDAgMjA1IDEzNTkgNzcxXSAvRm9udEZpbGUy
IDk0MyAwIFI+Pg0KZW5kb2JqDQo1NCAwIG9iag0KPDwvVHlwZS9QYWdlL1BhcmVudCAyIDAgUi9S
ZXNvdXJjZXM8PC9YT2JqZWN0PDwvSW1hZ2U1IDUgMCBSL0ltYWdlNiA2IDAgUi9JbWFnZTcgNyAw
IFIvSW1hZ2U4IDggMCBSPj4vRm9udDw8L0YxIDkgMCBSL0YyIDEyIDAgUi9GNCA0NCAwIFIvRjUg
NDkgMCBSPj4vRXh0R1N0YXRlPDwvR1MxMSAxMSAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFn
ZUIvSW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAgMCA3MjAgNTQwXSAvQ29udGVudHMgNTUg
MCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJz
L1MvU3RydWN0UGFyZW50cyAzPj4NCmVuZG9iag0KNTUgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURl
Y29kZS9MZW5ndGggNTAxMT4+DQpzdHJlYW0NCnicnVtZbxtJkn434P9QwAKD4mBVyvsAGgJst93b
g/aO1/bsLtAzD7RM2eqWRC0p293/fuOLyCxWUayirAdJrGBFxpFxZ6o5fdP88MPp6xc//9ios7Pm
+Y8vmv97+kQ1qlNKaWNUbKJRjXeq2ayePvmfvzY39HWnrHb0jo2Bfgefm82nHkupoJUboV389emT
/3r6pHn5+kXTDEjqeyQPIAvNqHMXfUOvNd7Wj53xhNCcXz99cvrz9fLTyjc/rptDlMyO0kkhpHSO
Rc5ktT5A06tK0uVOG99Y3SWCZEYakA1TZO19st7rPE/WRZJLJPVNYMIOkg4pximK7j7FkFwQisY5
fUi5WtleuYpFDCqDicjUd2TTFFl/+svy5lPT/rY8+dubReHh+XvCe6Wb1NGWvr8gOkxCExHbJUtw
F03z/hoWFXJqyIZOf3pHOvm0raCfnj75tTWLE9cq/NL4xY+n4ZT++jYu/tW8/9vTJy/fH+AqDBjp
aXvfGTOg/WvbzK0RpySrC7qoO3KT1FlfF3RzC6aDawRRyG6NWabySMOmMbHLYaRinU3nbeNS6GIs
Oj7stffBb1nr/7u6ab6+fvGyWZzEdnl7u1m4dr08h/I/E0yn9p+t/udiwOZIzSZ03g3pHxFJq5FM
jiTo0lgk3QUdGudsZ2XFH5RK8WzMANShx4gmd26I1r5bnNh2dbuw7XKzvFs1n76stneQybQkML5s
vrGRNZ/XixPT0peAH5bUWtNZO1p/XlA9EtQ3mvbejB2EQkAglo3vQuhFff7ykKi+y2mMHCkujnDb
f9yQqFe0f5f08/sKkob2/PbL5SK0HyfE0oHcdm+debnM/ga6fb9PlsXSir+Y3cF7uFrpfeSWzHNx
EloyUePb8+VNs9C6vVgWIbUi2C2ePlwuThIpgAz5Er/uFlk+rLakAcIm0JqRyRKw/bAGXd65oI+m
vVnBEFZT2nLKdCmPuZvXln2gtmx2XTaP1NYQ+bC2riHWcvv7wrcs8pTGLklVUVQ10MqXmxt2pfMV
3GW7XW7+nFQQMZTHDM0ryB1wkwNOYmOiJHXcScJ9Hxmiti+vv8BDEA5IJbpd4k/7jXcdX1xN+Umi
2Dtmoz2Zejf7Tu+9+3F1ARqX5KE3q48g6ltslMFGnWT54m5Fvzdk2aTlc/ZfS0Zs2zXHqglqImMw
Xaz+y3GO0P59AawTY9vz9c0WQYHAvt0ClmTRi4lFDVk45eXRsvP76B9q6LSfOjzW0AfI7c83lzD0
u7/cbtYf2DJ3dkuq3CzJXCeks5GlG642L13Yl053ewxSHgODlkqeY0HPjDFt3Mdsn2NvllsE7vPl
Ff2Gaf4Jg/DtxXrD5vCJtvIL7XCJZOzZ7MeuRR7A37sFdHKiY/sXWFpzSy9t1qinPjDiRKYztlN5
zNC8duJDtWOo7EyP0s4Ak3KZiLddfiCBoJqVOAiJ/48Xb6c2nWpdv7fSlAcbssC89y50DcVuVrA6
CSJEnkl/FE8jRVNgJSAxJlm4ZuO78lc2a0rxVFug/RhSnVd82lN8vlclaKqDoT8Iv9P8c31A8weQ
o0VVMERu36wXCT6moQ0S5u6Ky4wVpY0t9kRMzihKtSX8qOHrv8FP8fI5tAKd0ZufodE1mfl2IV8S
3Br+tCEoftblL33jXL92olgHc67U76Y0G2Ln8liQec3mB5q0yRRDHmPRA0SxCtgW283DDTp2No0W
mrZniuPjVyfN+Bx83AL+OCOmSjLaEalZTZv9hiDf63HEhE3yVEAfNeFwyIKHuO1/rsWOyDCvYY0k
/wmEQ4XDVubLt59hWmtkTBiqJZm/3AJ0i1cBx6t3ZafsDsSGeVORJ22yKGrI2rym9ENtkoS2s0nI
TRnlGNPFM4s/L84c/fGBPjr68Wce0FcMdensBC8pe3YS6a/FAILeNM/k2Rn5HjAbz06Aal6dnRjg
yBKEqk0h4KMsLiQdSL48G67PHLwaclC/oVKSKT0PshRYcVlYN0LQewFXJt0LMIjPggoGrTB41I9R
41JMGarsyP7td06Tlk5VlwqPtPQBbvsTO2sQW6y2vZSAjd9SU1CVv+ZIO7L7U9j1Nyr/ERaKa3zA
Bw64n4rV09u3PRAr9L6xnSwvbMbIYsTovN72e6hJvXndmcfqbYDbPvu65hIDGmLhm+v1xxVHQoBE
7u3tisQ8x1vUjV7yWOG8QVAVxC2azpKdJjShPEYKI9LzmnAPLLKNDShwH1dkD5Hbl5sN1ZsTfQ4F
DbX3/mRPRLXN3qtSqF+sdz04qvaLubI9dDqNF5nX172mZCpiGjscwXxPGh9gtn9HIqlDmFKuX6+W
1Kd4Bn+in4svpWaVevEbzOtzLeNv+jpS0jP5KjnlaoN1pXDfsLY+DRH4AwZcU1MLm3Pn9JjVeb09
tN1BmxgfpbYdYvuKZKxlxl0tLzZSGkrf8rEWKLUS+Soqae64MsQrB7sh0iN/y2rtF7le3tDHSWWR
Nzo9YnBeV/Ghcz5NCcM8cs43xG1/WS2/rrjI+LzeNX4XV4hQf1x+uBxMAaHPqVmNsa5LYbz0vKhp
bx59f+BSJI3kof5BS96rsyfGwZq2xebvnwcP8TiYwR42PNW6hD/d/CaTLVR4HuNBGZ5MldEahwqj
NWfFs+ph0y1t+WTmMdOtIWr7rDRUaFOXHB+2F6tNI0M+Kuv/5O5rMp5nj4ZitOK8ePcq0ol8pHXq
tH9kPhoit69413hieQfJDG3h+mZmuA2BhgtMJqjourhH7N3bZ38/fQeLefvsLRvIh+XN75OdjwqI
HKMV5tX30FE6Du7UscOQSfUNkNv3m+XN9opTC4daViCiCM/Rlx8/blbbLX0Ohyblur4wpQDiNtsx
wXkFPHQ6juGrfux0fIjc/ri6knErGdDXaU9AEtjDnJfkXmVGC5iDOZPszIejQ7BO7WNL4hxity/J
p7/Cr6+ofv8irXxsebKdW8pyOPaRQkM+ra4wUQRGnz8jFR+wg+v1doFhMyeTQNU7KafMVHV9fcMj
4ymdWer4bRwzOK+zWp1NHFm66DttG2c4HOnEx/RWdb6/bOCab5Mnm0fQ3x1iKBzNb94YnAI7Sp1R
hNSgHPDbEAR8jyFyyvrTl1Udv3M0nj5nDCohdw4oHFNjPKJGCoLGN1nxIT9i/J4WJxU4h3hQf4fO
vL2JqDrhiyp/h8b+g4MSmeKcqhwsbrD0MVXlI6oyrgsUwJLhdSUPagKSHR3V1hHcQwpzg8s4mhT7
DbLRYiTbb03za2jIl5p/kazNx4YIGCxpjG5IUh8UVsbTFS9+8JZIzc/3Ve6p7SV8bahSy7wgVRPk
LRRFg8GSPmoqVfjZyrPIR9upmOZnMJHQwztNQVrWoIIGUc5UjPqtLxgXh7g0+243bhmclFsm0W77
7/E5xKy9nuA1/XpHnviWDzInLzXYzushwSN25ewBw3fe4vhP59A3ErBptCIP40JH5KAh/jwT7hAT
DimMSv20G1K9X2RMgqg5ohRB9C/6HlKqR54JI9v/iSp5NRfzPcUD2uzR8vNM+kmLdAn+YnF8fI0n
J/ZJYTDDeFziwxEKRTBYBhjU92SPlCn5mVyIPM8kjJcYoHB4qakPSIkBEUcc5JtUxfcA1POWPMsI
gJG1ZeJlUX7Ddy5UQMryhq5sBFnCVT6tYyJO1iRJFDAUDhsLgBgCo7kQ8V2ILEosbwSMFuGc4jmO
KhEbWHhfXYnzG8oeA2SoDB6aeNKSZRmMtkgasgFZJRp+gfxJF/k1K8S7yistkWWepgoKUcyMUnil
1o52wSXww8+0OLhw/Qt8SQlcBNezirShg+2cF05JF/QcKqMh804Rf8pWTgvA2CqKIk4D6aE+u8RL
xlSp0HoJhbzqXFEInnIJYBClfC0WNRWOahXgSS5HxbyXgOvZSCxFM4l/3rNpWKrVxCC9h5TAcHV9
T5olES1qU1NWoRzKHHvSIX9nsQcz/NT87igTGwTYAEdgH2FSjsoUU+yGtwUA2mA84VIhPZH94Ul7
DujE7rnYlNMMMKZaHV+9YQMudpmQA+Bo5VnjBV2fXSdXdWxv+uS9DpcKXfUNks0pThMFYAAIOFou
7kQMK49zueKzmdSucBWyAkyQizeh+myQiybOVZ/NkYdc2VcAxW2bU2/VESctliJp8hWgAfCd5E+2
atyjsfhTjAWbkzVspgDwguot1GExCx33AFqSdGh75yPGLUnsTbVpkh23Qnx1PotbIoRXXmDDtSEX
g4Bb4Pg1+IJB6TbTI+5u1meDiVWosYjcg/SIEZbpAcSvdWQy8ixyOt2pVAEaM3lfN4SIkedZLvTK
M05OKfKoWAGGAJTmfagAHcWOexRol3bd9HxWQOgBYvop95IkXrRsakhClu8RFQDqd+LL6qqcwnkf
Q+Bcrro31KlwqO6ruhCFiCruvtq6Axrq4vBbACmyhm3uIyaOj90gpDrDe+TqrpOQFpE2VjvRxDhM
LlfTgqxk6CVBwPiIKjmT35knuucIsy0GzKaTaxYiQGLj2/mAhcmb3lwz31fIrkZ2chsvFh59dTQ2
+YjdKwB2ioSbm8U3yR6dUhCgem9kT/Ox+rfP9RJcCQDGsbdq36e2zP5cvABSOnZ4r2uQgX/Hrs90
SSJEcDXTMQJ7eYlpxnCUKepK8AIEoUqCD/URpQoTpCdrGFBsJ7FHAVDSKbk1l6rDHEUwr5kOOTSi
K6kqSjyvtUDk8KZ5qDQTsPfHpPfOnHzkxO5UvUt6vxr6VU7Svp5+5knF9dTtL5/E+4j7OnJBw+Qm
r4uhKodnofSpdaUcWPEpYbmfEdrzu0s+v1jz2cVEA4YSNY7Xmi//8qEOUXOhPLoz+N+v+Woc0f7j
slyDO3AF7vCtFa85/yDy1q7wJxLozb9NaUSi4fD9WSG8mu8iPYVBQzGQCmOtnJj30fZxEulQ3+j1
fMcUNEc0g2yV661wVENE0NkGhaiut8L3wdI7vXj2pp4ryBEMPr14Dwv5RZ4nLILKXko4hqJgqMp8
Tf3F0W4nUCWHRmWIOL8L465R8+X4PUsIVLNRaMDspx5w/DFFH9l49OY8dbu/A/emj47SCpW71vHE
6KFtK/8HR8D/LJzPH74iyiF+75YnMJCmBtyIZ7jWt0MYHsFO4PjEMlD2N2Oc+ZNabxSnxSHevD4P
Na9BBupI6dk9yoz5iqjbXRGdMVzNSQ0Fh3bfIWnAsYEe481L6nczH4Mil0eYmY0gU5MwMAWZAuUm
IA/1YyCFoZChvEW0ouIcZSSLTUyBfNjFq0PaC5YbEW1MaXWC4xwIQOA8D4CVNwgfT9yd8jwKT7QQ
nhLaikDRFKeK1MlbK8halreoWQLMTxp9YgJP2slTFmx+C22/jYJteQpCAAfStpOpmovyEPiJKgNG
dqhltFysYuTArTeFBlcAkZtzk0uBF9DIWhkJBAF47pGpnw8FQNGYu/ecK0PoK00uHQpkwICTiKRQ
BWaWa/cOQJBZmzQTrEEZZdj6HKTfV0LEZnDM/X6oADSv8m8aV7JpXtZwtRgJVPdHTBpwhnotz+jm
aXXNBoJ4mD335lKNBW+lWY/9G3zxFf2+MgLgUQAA3tQ1MJjBn1wByvIbUmqCLEUYLJrLooqbd+ek
aA4uywu6UnVJ+Bq05oG6GnCCWrxIE1mLVIsX3hNmMjjjy6YCqF7loUFhJKADACDqKgzmELk0hpAW
eqcly05BH5mJys6AkSDekLipuhYANpxqXdmKwKlDuvPyDI+gZlIGPmAMeZ0ALlaANYziC93IVkdL
5lgBmHZhptVvbzAIxkZxoXstAGLToL1OQtnCT3F7WUpWsEp+BIAthLhRAIo1FUBaxKKup2NRf+C6
SKUDlRsTS5+PZ6xqXTWS4PhyD5eiRQPyXDYCGhKEsuEEkBVlVAI+KfqC5E7tvCmGjEbHygVinYvV
uwlAPmFoE22/ERWQKqCgpN3WyKLG94S4VTNkxskKIY5BJujSOGK7yhu5jr4PFf6+TmrYfWVSo0ON
qLQWRjG2Dwn4tyvNCRJPWiY1Wp6MTHGopCghFY2Ydn2QMrV/KZI7bkt5UmNq1Kqjmh6QhsMaBDr8
5yCGNX2wNDKr8fUZPKtd1OJRHw9rbHVb/Keeql0nALE0iLp6OviiFrLaHw9QMKwpwdLzBBltqNU1
emCogbF3D4iJW1kVa8Dh+Y6tOQIbwy2QTPrgxc5x/5x2bh15WKN6x0cTRN1njXscR9EDFBV7qT3Q
ileHtNzn594m8D8+mDrkPvoYHtZUNuV/HvphAgeSzOMGnwZWj4FE6P0E0wXn66KBp82ogFwxYAM2
rO8d3EBoS9ko9oBSxxhXY4LCeCaVCQUAmFBgkGkqAINMVUcDzGgBxApgFFPGIACgZcJ0tBe2lk9D
4Ykv3wcei3ENRbheXSxY3YDEe+Z8pen55ALKKVxhBwyrr1gbbRGJZCWklU3E0C64mjW9DGNok1Sf
3qyMa4rjeCvdcBykNx95XON78/OZxzXFcTwfN2JcU/lQgpLK3I6NXIaF0VQ38Dyucb3jZM8dr+od
x2a28ZCqryUj45q+cjEy1NzVNiHIuCb2xU4Z1/jq4c4PxjUcA7z4a6wAY2Vc0xc3QaY1faDhEVDs
SxnDsxWKEsU7na4z38q5hvAINKHWNjZJJOpLmeg4VpXsQABlOZrJbJXDp0Szoj/LZwp4w/f5Qf6H
C3RKlrIyrt9VZXz4mIqsg5j9/1aP5s4NCmVuZHN0cmVhbQ0KZW5kb2JqDQo1NiAwIG9iag0KPDwv
VHlwZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8PC9YT2JqZWN0PDwvSW1hZ2U1IDUgMCBS
L0ltYWdlNiA2IDAgUi9JbWFnZTcgNyAwIFIvSW1hZ2U4IDggMCBSPj4vRm9udDw8L0YxIDkgMCBS
L0YyIDEyIDAgUi9GNCA0NCAwIFIvRjUgNDkgMCBSPj4vRXh0R1N0YXRlPDwvR1MxMSAxMSAwIFI+
Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAg
MCA3MjAgNTQwXSAvQ29udGVudHMgNTcgMCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFy
ZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyA0Pj4NCmVuZG9iag0KNTcg
MCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTg3Mj4+DQpzdHJlYW0NCnicnVht
b9s2EP4eIP+BnwZ6qGW+kxoCA42bFC2aIWsDbEA7DKoru+5iy5PsdP33uyPlWLQt2TOQWLLM5+6e
493xTmRwT66uBnejN68IGw7J9asR+efyghGWMMa4EMwSKxjRipEyv7z4/WeygJ8TJrmCNdIa+DQ6
JeX0GcWY4UxFsMnPlxe/XV6Qm7sRIQ2VfE/lAXDQaXmaWE1gGdFyc5sIDQAynl9eDN7Ms2muyauC
HNIktpr6tSLGU1vzdJLzAzo126hUacKFJpInDp6kHtRQa9rUyn21WvO0W62ywCsw1cR4xQqZNjXa
No1qX6NxygSNQil+yLmcyWfnMk/RsBSNsF77Vq1rU6sH77LFlNBvWf/tfa+24foBcLecuAS29GEC
erwKDkpk4iQ8V1aQhzlGlEkdgRgavP4APplWm0evLy8+UtHrK8rwg+OH/zowA7hqant/koe3lxc3
DwesMg1DnnVrnQjR0P2Rki4Zto3ZRqCyPIE0cYnUG4G6S6A7KMMEh2xldBqVRh4WRNgkNZGLeSoS
LYlyJrG29vHhrN1//N57/Y98QZ7uRjek17c0Wy7LnqJFNkbnf4Vn3NFPVHzqNcyM3CxMolVT/xFK
nEWcFDBIXEQJsk+mgigI0ZQHkVeMOTuMLUB/8BiJ6atjJL3rSfrhfUXy+foROWWrWa8vabFoIcRT
lVgVy+gmxCNCmnCzQ8jYQEjKRNhnQtc3hwjp3Q12aZLqGEzv12UOtGB3HK0GPU2/w21K8zncAkvt
SZp2jkLpRLpYZjdHcSpHJJCey7EBpr9iGGL8Mbpo3yyooVBmI2C/ba1WYGK8NivHGOOC0xn4s6pA
5xo9W4WH2TSbtfowlYmOpXW7UO7Gvdotl1ie0ULG8NId+PtgwXfB9LYoSY8LOsmA2HyG4fKIWf6j
NfZ5AsU4ktHqzhSqmIrXzosvOSbXI+kJBy4FVVW1zuGbpmVRrMAYTidlMYcbFkzJp+Bpmo1/QNTC
OkuXZTH2QqqqKFt0K6sTG6vu9r3a9T1PdrwHvQbIks5ije9wPWBFjNT2AFJY6AAE/HNIAgNXO1Tw
mMlh38JVwSOlsEmAqzu0v7ESAUVSu0jJEcb6VMZWJfxYlT3MuIGkr7G0riFzwtatcDeXPdx1PLw/
b34gWKHGORlnS4jI7DN8zOD/sb6u6msQgslv6BNWsizcYy0fgSpD/8IVo5f3IO4FAMgCbgqMJBTh
T7IxakCLUOCXtkByHIM4otLtV3NqFksN/tVnZnET/JzFz9nVmpEi4TG0K3mhWYzWVksvfTybzMak
Jxv521oBGVTASEa37+ypMakMNCtnZWGMFOlQX2EiDvviKmQbk/6PCczAkU9KBT/Lq/BI2mEfIeI2
QNjtJm+5lxBSGVdswCjnZijr5OaY3XWyb9SiPqX8EhXEqduoGkB58gb4QmEigOYBZw9rCOWjb67q
chJMe64yL4MMF2S4oKXBYSvvJQob9tWWWK1ig/I26SbzRknzMrwBJjzAZdc6lD9fBrf224YEHJPk
0DQcs7GR4X2Nt37FtTlemTRkAKZzIwqOhKQ7NSShVWKd2dwakjGyIySl8UR9GIqwF3iMoNNMA6LS
rY8lG24iV40wklEKRjHOgOEqnZesomAOu7Bx9rXfhsgsE/wfIrE1bmUzbo9vDwyliXKRR6Ltibu1
4D0Bc8tpZ3x64lwhUmh+O8/4trmiiaT1yCSwjdFYKzV9gk7H+j5L0ymcPOWxWUOINDEmlttJUrAT
+3BhbWLlmX14E0xvSjzDFW3rxbhkOEREmNZjR1oYx+O12HgvJtjpQ5N49+E9nNbVL63+gnNaxfhu
f/FTj2th4PDsPHM6jusmmC4L32gvVo/YqOQwVECQwIFq6KognyFE0roVn0J85G2diYBStiO4m+mp
E5qf/c6OjAaYvlnMoOtawf79tESOGCeSIsM+V0e3ErLRxvK6+Z08PmFS2bN3sgGmVfYEBPNBWTe1
RRlGmTtki32ohj5U+Ta0j30oNrg4wkzqhm311e92lf2NYuARjOSTMJCtV9ialr5gQDPsH+b/rvJF
5UOjtWJoONowA5pmdvttb/Rp9Rv8AjPGmX5rgI/4beZneu+4h3c9R0VbhDgQGQtuPSyCETxNsas9
xSt741HLYcFhMpDHnHLwsGgiw+By4wvBDKvC4ls+xrNBdbyHspAgaSymm5M5sQJwbfAN13kVoAmm
12WRfUFW46zy45t/JyWkv6tf3mSPjzDA+VdVT+PlumrbbTBO7IjvpmtPpSu3UfH/6TbAdOQnzHKR
l55OIN02HXGnIXwjfDefvVa0LVG5kIkzZyZqExw2BFKT0SFZjn0RX1cvwnkFdcwPgJtQxdeJUKZS
WozHa6xvjmZ+2M78xL15n1Mspv5LgMzD1I+w7yHvF1+K723DeGqTHQO7PbbX8UHzLg6275zDqCqO
veVI2C46NKFNNH3w3RC+ZM3L8D4ZSnjuOYfjsCW+uUNakag9dv8BXj+mtg0KZW5kc3RyZWFtDQpl
bmRvYmoNCjU4IDAgb2JqDQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jlc291cmNlczw8L1hP
YmplY3Q8PC9JbWFnZTUgNSAwIFIvSW1hZ2U2IDYgMCBSL0ltYWdlNyA3IDAgUi9JbWFnZTggOCAw
IFI+Pi9Gb250PDwvRjEgOSAwIFIvRjIgMTIgMCBSPj4vRXh0R1N0YXRlPDwvR1MxMSAxMSAwIFI+
Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAg
MCA3MjAgNTQwXSAvQ29udGVudHMgNTkgMCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFy
ZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyA1Pj4NCmVuZG9iag0KNTkg
MCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNDIxPj4NCnN0cmVhbQ0KeJx9k09P
8zAMxu+V+h187JCW2knsJBLiwAYIBBIvVOKAOExoTCAG4s/3F263bt27dhe3dWP/Hj9JoLyF4+Py
ZnI5BTw5gdPpBL7yDAENIpK1GCBYBPYI3/M8eziCD/1t0JHXNS6IRuEE34tNFaIQ+p2yl6M8+5dn
cHYzAeggaQ/ZU7xiBkomMOgyYNe+GstaAM/LPCsvl7PFnGH6CX0kuyWN1yCkFNZzRkfUw2RskT4Z
sgyOTNRMaoo6WBnCun0sM6XDWB90rtWkDNKAfT1plxiGiH6fKNHLimi9pz5zCd3GXGxGFEy1iNDQ
t9g4hOXyevaxgOJtNr66Ha01nFZad04QjW5p9aKcBkEKcSY6zftgoVrWJ0pSBD1D5cW9erL4aVMX
efZY2NHYF1gHqkPzWUqpTy7C6Amqqzw7q3pUSUfIhs1srO2wHws41CMMTdY29IGMXpNoHLcN5VDD
2NtDVoZsexwUlXYctuBkx1+bdPeiZtVmvza4/8rup+8ay6fz39nr+8gVPx0Z7X7+R/PWGpEubVf9
gMjIJiYtIzFuaOY/qW/tbg0KZW5kc3RyZWFtDQplbmRvYmoNCjYwIDAgb2JqDQo8PC9UeXBlL1Bh
Z2UvUGFyZW50IDIgMCBSL1Jlc291cmNlczw8L1hPYmplY3Q8PC9JbWFnZTUgNSAwIFIvSW1hZ2U2
IDYgMCBSL0ltYWdlNyA3IDAgUi9JbWFnZTggOCAwIFI+Pi9Gb250PDwvRjEgOSAwIFIvRjIgMTIg
MCBSL0Y0IDQ0IDAgUi9GNSA0OSAwIFI+Pi9FeHRHU3RhdGU8PC9HUzExIDExIDAgUj4+L1Byb2NT
ZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFnZUMvSW1hZ2VJXSA+Pi9NZWRpYUJveFsgMCAwIDcyMCA1
NDBdIC9Db250ZW50cyA2MSAwIFIvR3JvdXA8PC9UeXBlL0dyb3VwL1MvVHJhbnNwYXJlbmN5L0NT
L0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1Y3RQYXJlbnRzIDY+Pg0KZW5kb2JqDQo2MSAwIG9iag0K
PDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA0MTEwPj4NCnN0cmVhbQ0KeJytG2tv20byuwH/
BwIFDlQR0fveZa5nIFactEVS+GIXVyA9GLIiO25tySfZTXO//mb2Qe5SXEry9UNkajWvnZ33MsXR
WfHdd0fvJz+8LsjxcXHyelL85/CAFKQihFDGiC40I4UUpFjNDw/+9W2xgJ8rwqkAGK4VfCpZF6ub
BosQRYlI0K6/PTz45+FBcfp+UhQRS7rBsgfZ8dS0rrQsAKyQPDxWTAJCMbs/PDj64X56M5fF62XR
x4m1nMaeEaG19vs0nNIenpIElqKuKJMFp5WBldoiRWxVji3fZCslrYfZCg37cjuVhbKMBe405qhz
HMUmR2WEchyZELRPuZTwRrnEblGRGoXQlnvL1uTYyqN308VNUf42Hf94NvIynFwA3htamAqO9OIa
+FgWFJjwynBYF5oVF/doUao2BdjQ0dtz0MnNOiy9PTz4WLLRWJQEPyh+2K9H6gj+ylKP/l1c/Hh4
cHrRI5WKBGl4S1kxFvH+WBZDNHRuZ4Gg0LQCNzEVl4HgoFCml4ZyCmlpDApVJxpmBdNVbVIdU6Uq
MHBUNQlK7nfbzeUPVu1ny9vFY0FfFu/PR6L8UIzGupzfP91NH2+XsLAoUP+/lvTXUSRqqmpWMRGL
sGVbNMQgUklj7YFr0IkpwGwrI+F3g3YKNiqauCIMGClvIDhHu00gFCMRDSM2SOCmQeZK1ww+jWFW
L541VzXai2ctZKWAfod5gHHMOzCevYdx7DsggRXjYJURK73JyYM0nPQmIwfSMNIbfJjWlWaDfALI
AB8PMsQH4mU9vJ8AMsTHgQzwoYZWUg9ZR4DIW4eH6LGOwITLygwrLYAMbMaDDGymBn/UcpBPABng
40H6+NDiS9bpwWl/KxqXggjCdXHf8DWmqmVxd3hwfnjQeFUD5BcSIK5tLvOuB0CaqGghhfIe0kL5
hQ6UM+8Iyi2kUN44Wyi/0IFyphVBuYUUyptGC+UXOlDuZCMot+CgGK58sdAmVZtfSNSmiUwPwC/0
6lZJ/BPp1i2kUN4eWii/4KA2AzHtJBjKkuQiIKTDJ5RFYD4Y2DF8giHZwBmeXRZ5P+Ll5O1orMrL
0RgeX52NZJIF4ozB67qCHYDmuPIJYzZ9AITpFWScW/h35/8++r9zJLrOkEMF0pTccP5hfQUDQ2eJ
N/uxfD1fz1bIGUV4gB0GcZajMSsXuXwIbgSOllAalof3yKOw/BVdea5vQYoF/LMK+QQPOR0rrro6
RskXfhcWf3U9nc1xK3kiEFPAjEE3tfBUrpdWJcUNnNdTkGT9mKNg6g0Kw8oQPcrgBjIpt3bDha9y
mMQCWwBxCEiE+SKnu+qsc7LEYvLJ6w73b8sc0KZy8qO9fcqZFxbLLGa+bQuyr/ZD9DqlMjn72Z4g
iHIFD9MFSPE7fKXSyony3l8FEVc5DROsJ/cRr69eVqyuOtIR5Nr5eDES0TfqnjJy1XBmah+59MDJ
S2hdqD/5WmHsqQmWcQxO2p18d7U/Ll1gNfsObd5+PxsUqLeGlwaKuligbduq+6INoZXSKRX0ZnTR
NURBaS3Snrs1j/w2cq4rGa2gx+IQRnjg8OXz3AUuT3V2B4wsk2nOuqRRVv8xmcHtMtJnXaA0cP9o
u9ipClNczMDOstFHO8eLsSzGsAB0wIyIbsNQR6env1w0z4NmwfrSh5DWzBMGw2L2BX1JsT1Jqdjz
+fMxhAE8vE9pAoCTXM1R9ptRPknKWmFVsYeAfYE4HGRMJRsAIC2jp+zOsS9u+pNjCmqrZ0T+ruMA
ox1OuC9CCoXddyTItt30hTPJgQhNiKBIuTODytjwPVj2BSx/ZDEROnxiu/PrC23hwKiqBO93tQvr
b+ejXbyN98UT9DZoGRIeg5LyvqCAJZ/RPZLeXkI9A0Hx0Zc462yQJXYoxAjD2tFRuPJhHKsMidtT
+PEyfONNTJ+i02KRTBk8zz7nIzlUchSykUa99kfy9TxXgElj80CCPayqvvAWjChW1TYr2v1w+EYb
UhGWzrm8VeG4izyvDpDWAnl5efoLqu7iEkvCyU8Xg5L1xUCc4kEgiETZtr++uCadzSRU7jEd2yrw
doQloICILsrrp5Eu72w7NWYKjh4rg0XXWnraNwntJNg3lVBr0F2SHnfGmBrT5nZ660fwBBxWxLyG
laK3H7orShMVETsgdp8vQCfN98EidI+zMsMtcbBDCB1M/f/5CEeupx8u8ftwFOyLtEKRippYli2b
E32xVBKCSSahsn7yDS/+s83u6hH7ElWuj0DpX+C59l3JCmOYA8kHMI0FHEVzDBxcwTJbjkz5B9qc
I/Y1R0HXmDYTCsM77Yv3PoglO90SxPbQLUsMB9hAwO3M6gnEcQbHxkNBtOes/jtCjD7u8XsJUS9h
xQzEvoTVx/KHBUYVTGx/e7DntUSdX83xYDHiQG1pJwN2KvAyoxcKZSRP6Q6rJY3tEt08FVUopxVh
Ku0owjZPTvu2mboiFEdEJ4h9U6jMNphtmmPc4W2I7jbgLNN9GOb2wRWWJoMbqbvHRQmaRoJbfsAd
zKFGmuYGE5RJO2iKscYbaUH0sOMQOGRXVMmOJf6hx2P8K94cg13gwoQQ8uYYHwk/Hhv8zRwr/AUv
Os3xWMfgQsCiPh6LFk7AV+7RGQkwyi0g8om05OUrvDi1j2ISuHtcTypIEKQMQkccrIBAXJwgI7fe
bOpVQg1lOFHH2mNy7tcsdxrjKYtTO8DeE+1ezPkjhTMKjvJlBYn8FryNl49zN4MycMK6vAazvbY9
HfTkWDrCL1x40LWFxGmQ7f6w65uDH1/bMhMBFs5QdHaAxRirUkmGbV3ubOuUB5J7m3qLWr6+tRFo
Pb26szkGjb74efIhZ/aKYv0VU+hafXw7KkUC+oT5aoEfKzv8UOWd5Q7F/ljY7598hc45TqUxOpKy
+LXMKVdoTMIti/3q0lzhwiRPJd/3Wjd7XcsgC6b6H7YGtdUaKDX2SKEE3NsauOqglu8nby8nF+/A
6i/P/oF5imDdi1PbMdYirgwm7pT6DAfwAehyYov8d7kbCEiZKmE7rAS9qxK4qZ+rhAjVKuEUdvPL
RVDCC2eRC1duyRA8VPnnozPRYM43dh7/woFwbtetsu7X+HiEjxCJhP/ugK6XED9WA1c2QUZtKtUM
8BhYKM7jqCHfZz2QV0QleBYl77HaDo0aeKSOnim/P7KvhRj7LceOMfvaR4ye48SYvZlIONVIW3+P
Cq3B+W3IXc9HtdfSW9Da2TdZkxIVS+kN25TZNcxyrEWfF2Yj1PJ05APf9Aq36cKedRk0pZ8nuNls
zMXS2STk8idoI1cMulekLdAKC6zhhoIuVD4RCxwma3shKTh8QoYIwbG77IJjrupn0L5Cg5EQ/qui
rqpEcpRbrKPutBObJ+wDjhSRcfS2B9mA06JuMQ4MRxenECLO7dTkDM+MdSPy9A98diHZnez9cuQf
29O39NYPWMLMEJbiLdwYOsBZzq8gExqTCDuoOUl21Zxgz9Zci7qD5s5th88yals/PSD2Q1hd2Sat
cYz10ZdiNXK5zbXLcx+qc80yl3UlWSLjsMLorgrj5NkKa1F3UJgdiUMsuLQak3F2shqb/j7iAQO+
o9aubcR4CLaGwA3W/dSXzmByLmtmFIfvEbBE1mHFdVv+rOKoebbiWlSruPsnHPd2A6nTAyuu0Mym
C1TF7+tQJHTszdYHtgpGzOzFPVPu+pbumM4k31RGtyUCF8bMQGBnJq+OBlyzHnB8F9i2j9CZMezM
To+xa4OWFjoz1wi6zo2FfpH7zhKxbJfKWzT/syUoXUvIfGNp2s7RgmjXI1LSEm+pacf9xNEQkYyy
R0bRkredpuXjUR0oNKWICG03H2g5Oxbj9MVq+85GuCdAW3AxOXY0Kssre+/rbIUWj0tMv8YDobXc
tCF8/ehjEZZCTfzxhidk43H4z4WwXGQCYzKphMNGJbZ6mLMpZnhDcncX8wqLcMv3t/b1ixv3xoX0
PnbbaMVGkeLLEnZsfeguSneLpS/Fr9wrJQFn9rvXVq5B96VjIsiwXuSuetH0+XqJcEuIx9QGWbCR
cPhT13W5jX4Fo1IQguxo8TOq5uu6KQdmFhRUNB+ZjqVIb0NWUbOg1rYzcQcAUuXKTS+sIlighu7p
FKz2mxf2aszJ8oADF6T6h5+qLL0kjgscKN880Jm36+n6M37/e+74bMJIJBg+vY2WOjMTxdkC2VL5
9w9FY8yBl0de2tkSY7l3T/z7BVSj2uDA3R3A1ndqePmP3FyDE4bVXCLfsLI2Wu+csjjDhPUcZUWY
4QJ40txT50YIlFG8wEuQh3eyc8PHmL3YGdhKn8e7jq+Dy5XLiTKeqdpp5qnLMLybGMMcF5IOw8Eo
FZiOcC7qRsBvfB40IW/WzRS2ZdCMY/2QmB3Hy2EsHLFyQ11kw+3vzdA1TGJF7b8w/0srRDMqdlIq
n71lPOfdJe5xQqtU+VsOtN51KsSIecaBugqwg8tpO2Lnye5ru91kFm9H99zN1u0xWFV0B+Z2JI+1
CQsKt6pjuOCKLA71DetcAcguf0/Rz/VVW1ZFNwENuzDxz47xB8dQtNb4NnXQSSsDbpJ37i+iywph
kGXrESfOpil1kiEY53Ep2Jn9ewtLRJbej2BVRzYekNuLBgQRbPvdxR63IHtcc+xYQ3r9GvgjvQ90
+oerdvBqf1kXkBnsk820Pl9j4zFdjaLGrplchuYWaDky9w9t4kXw+/niEVdyr7KxWuB/OEqEHHRU
RXZ1VKpFQ3Pf+W2MCyWIKySbObTXSa/2UkXZMmT9NG2LyLjC6vTCVuduplt8mkPuumraO1fA73Yf
6Dag7P8PbO4DuTcqH0u9pTfL3nqjm7E3sZG3PzeRumv4niBpDbh12r4QFjliN3w1DnKSBn7iYUKX
Z+l2k09fnqN0p5TBdKUSxW2xRLqzJUoaH8Z+lhjhJpV7t/dHG6LlbAW18PS/WNB9De8F42BuHkzT
efOiBehaMVTaUCP+5l6yR+v1lB9DG2VJhcgAZtvGi3Z80SW6l+kKgm+3Ngkhc7+85dL4L0oj1tbZ
K8eyW4ggVnzb/MqKE/tZyzGuoqhP38kYAqmhLNLVTRtZo3WYHc0Z/zepSrS5xZ7ZjtU5BUcJr0jm
zLm/Oo8x+6pzCK9s4C0PfPEopjC8nY23VXIlOqXPSRSuRI9xy/O59xU79KzLy9OfnMdBT+xczvWi
mc4Zr06wlW2vtaPZcetlwQfXn5d3dtqeHUWAiMKkIg6rbOc3Yyi0fsMqy3c1HVxbBLtaNyp7o1KM
p6VpKItep6+lRM6IPoLlbyiD2SS87OH9NC3rmpDxKs2RXTf3GZHTiHuTTzvse1i0L8tsabLEq6wM
EJyisnx3K60xh4TXipLBejsNiy7hZ+0AfjmSSeHiABauJslNcXTVYTlsdTu/o6Lrlua+jhrjlue2
ILPTz6M4ra0fl3a0NFYhl0nt56743Q0MMYHe39pJSme0mLuMYNzghWEiwoZK/geeLqEoDQplbmRz
dHJlYW0NCmVuZG9iag0KNjIgMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQgMiAwIFIvUmVzb3Vy
Y2VzPDwvWE9iamVjdDw8L0ltYWdlNSA1IDAgUi9JbWFnZTYgNiAwIFIvSW1hZ2U2NCA2NCAwIFIv
SW1hZ2U4IDggMCBSPj4vRm9udDw8L0YxIDkgMCBSL0YyIDEyIDAgUi9GNCA0NCAwIFIvRjUgNDkg
MCBSPj4vRXh0R1N0YXRlPDwvR1MxMSAxMSAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIv
SW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAgMCA3MjAgNTQwXSAvQ29udGVudHMgNjMgMCBS
L0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1Mv
U3RydWN0UGFyZW50cyA3Pj4NCmVuZG9iag0KNjMgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29k
ZS9MZW5ndGggMTQ1ND4+DQpzdHJlYW0NCnicxVhbT+NGFH5Hyn8YqS/jFZnMfcar7UoQWMSqqJSk
24fdqjLEsGmTeGsnIP59z7ET8DixifLSBxx7fC5zvvnOxZDBNfnwYXA1vDwj/ONHcno2JP/2jjjh
jHMupOSOOMmJ0Zzkae/oj3dkAa8ZV0KDjHIWrtbEJH940eLcCq4Dtft3vaPfekfk/GpISM2l2HK5
Q7ny6UTMnCEgRoza3DJpQIHczXtHg8t58pAacpaRXZ7kq6f+2hEXsVvH6ZUQO3wavnGpYyakIUow
DytxqVRza9vcqm23xoi42612EFcVqSG2dKwx0sCjbnOpt11ar23lUmotdqEruHpBl5cxWh7jLlzp
/tWvb3NrBr8kiwdC/076n6+j9R5Ox6D3SRDP4EzH9+CndCHAiWJewbp2koznSCkbewIkGlyMAJSH
YrN00Tv6SmXU15TjReClfBzYAfwa6qI/yfhz7+h8vGNXtraRF9/GMClrvr9S0mXDtUW2MaidYJAn
nimzMei7DPqdNmwFyKuNzk3FAcKSSMdiG0AsrGVAcO0tc26N8e603V6+KVG/zqaLJYn6ior35GoU
KXoDT56m89UsWU6zBUH8v1H5LaptNYRaMqnre3gjLMGDuDSRgsU+5E7MLNrUihld2fzAuXcfwy2U
oEBoNlQGnJQPtel5nmeRpXlLEM4xz32o0m+RhUBj2ZCdRoYu7jMSCVndL9Mcfu6Tu7TFihSexSa0
0g2bCGAzBAw0UNOmgg3KqHpB7fR8B2rCB4rWM4nhvyrSE7IEMuTJorhP8YbMor6lyXPaBqGEYgJZ
XbfRHY9s0ECYJr29YFZ7omI4HdlNg23lON5Spp8iDcej6Az+MLw0B3oLOK5s0RKVcIY5FVppI4bw
ksUN2dENuDn5dTCK+o7eYJ6d4ApmnKe3yeKfosWYUorphrFuPNXeeEIdcofC+apLx8iOGUCaLFMg
O8QkFf2eFcvqwdNkMskx5LQAoQLfixL2DG/pwwrWTblQnUIo3oKLlhKyO9hHNyx6b1igZxh/KC41
ZXoG+09nEBty7THN37cRxioGHT/Q7Q7GNINRTMmwJQgH5R3oY6EWvBGMbrZsoUxTmZ4/JhDODPm7
SjBvUqhyjiYLuJ+QKKaTFE+zFJji5RGzSni6/J7i6zkQonwuUniDomjAQu7lWfkIT5wuM/IIgN39
WPG2PgN7DTZG2lBdBwH1UeyXOXbfyipjGCsOqaw1RXoFwA0v/hqNT8a/j9piiBWzIlDrDsHty3Lp
YAo8tJjWlenpdJ29Fk9R4eW9ItUJYwan+WM6OcZU5/SpXJ6DcIElV0pafAeRbDWbYO5regukAO4U
yRyM4r1QNMGSAT17Mi+VQCoDToFa/oTWMLkKfKwKz8X1Ty1gWsWZCffexp1NnDDT2L1w93tTR8YH
UudVsaJOmWRv0Mdr7Fp11e4w4h30acSx4Q93+zSP5jwXN5XpEDtHmpSzBTaL22dSsWQK68uyUWsK
M3lJBV4cVwftgErTJUxyL2+BXaIgd2hohf0EuGdpxbGLaxBqY4XWcMY22FKTFZ25IGAO3K9qS74v
SbAhCH8IS+qadZqcnJ3hh9TN4AqgWa9dAUCXo2HbHGcNfCyEBrvDE/vWHqHFwYNHTZeeYyFZYYOt
Jg+sIVJv6kUye0qei6pgYI1A4R8zLBR4ly42sx9qKQffNgusRCjPq1ozgOdNweqvKxYIQoEhVZOD
NSxwKxyMv0XHJd8664mAocVsBmucDvAP58AvcC6aXqLZ0fALpsHP5ScweuTVfmHGehmuFhlJJrin
ST4oE+A+a2M3hwqgA8fdh7j3NC64wAHswFOsKUMFwENJ8gr62+dyGEDgq3PDQ8LfqgYY/N8AtI3j
zXC5KRYNQUBJlILkDpYSKAnrgfKtLrGuB8EOuyHbe+D2nEl1aM+tK/+vI3ewkS1k/gMc9TgFDQpl
bmRzdHJlYW0NCmVuZG9iag0KNjQgMCBvYmoNCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0ltYWdl
L1dpZHRoIDk5L0hlaWdodCAxMTUvQ29sb3JTcGFjZS9EZXZpY2VSR0IvQml0c1BlckNvbXBvbmVu
dCA4L0ZpbHRlci9EQ1REZWNvZGUvSW50ZXJwb2xhdGUgdHJ1ZS9MZW5ndGggNDQ5Nz4+DQpzdHJl
YW0NCv/Y/+AAEEpGSUYAAQEBAEgASAAA/9sAQwAIBgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0a
Hx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIy
MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAcwBj
AwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMF
BQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkq
NDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqi
o6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/E
AB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwABAgMR
BAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVG
R0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKz
tLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A
q2jaZpvhCzv7jRba/uLi7liLTSOu1VVSMbSPU1W/4SHSP+hR03/v/N/8VRef8k/0r/sIXH/oKVz1
fTQgpXbvu+rPmpzcbJW2XRdjov8AhIdI/wChR03/AL/zf/FUf8JDpH/Qo6b/AN/5v/iq52ir9lHz
+9/5ke1l5fcv8jov+Eh0j/oUdN/7/wA3/wAVR/wkOkf9Cjpv/f8Am/8Aiq5+OOSaRY4keSRuAiKS
T+Arp7L4eeI7uITTWsdjB/z0vZRGPy6/pUTVKHxO3zf+ZcJVZ/Cr/Jf5EH/CQ6R/0KOm/wDf+b/4
qj/hIdI/6FHTf+/83/xVaf8AwhOiWpxqPjTTY2HVbdfMx+OalHhrwL0PjNyfUWxx/Ks+el0v/wCT
GnJV62/8lMf/AISHSP8AoUdN/wC/83/xVH9v6K3EnhGw299lzMp/Pca208BaJqB26T4ysZZD0SZd
hP6/0rH1vwF4g0KNpp7Pz7ZRkz2x3qB6kdR+VOM6Ena7v5tr8xShWir2VvJJglj4d1s+Xp1xNpV6
33IL5w8Mh9BIACp/3h+NYd9Y3Wm3klpeQPDcRnDI45H+I96rdR7V1NnK3ifQpdOuDv1PToTNZSn7
0kS8vET3wPmH0IrV3p63uvyMlappaz/M5eiiitTI6C8/5J/pX/YQuP8A0FK56uhvP+Sf6V/2ELj/
ANBSufVSzBVBLE4AA5JrOls/V/maVd16L8hACSAASScACtKxtbKC7P8Abi3sECpuWOKLDynP3QW4
A9+a1dS0eHw//Ztk37zXpJY5pgW+S3B+7GfUnIJPatrx3aeItX8S6TY6rFYRXc6eXALd2KHLfxE9
OazdZNpLZ319OxaotJt7q2nr3MY+NZ7GJrfw9YW2kQkYLxr5k7D/AGpG5/LFc/eX95qEplvbue4c
nJaWQt/Ou0/4VF4m/vWH/f4//E1X8K+HJbD4jWmka3ZRscOWikAdHGwkEdiKmNWhFOUGm0r+Zcqd
dtRndJu3kcUAO1LXdfEPwhc6VrL31tbwJY3cyxW0EH3t20cbQO5BpIPhP4mmsxOy2sTkZELy/P8A
Q4GAfxq1iaXIpt2uQ8NV53FK9jjbSwutRn8iztZbibBbZEhY4HfArpfDnivxF4XupIgtxPaQHFza
TAkIO/X7prV+GFncaf8AEKS0u4WhuIreRXRhyDxWD4qvri28Wa/DFJtjmunEgx1GamUlUm6TSatc
qMXTgqqbTvY6Tx14d06+0SDxfoKBLWfBuIlGApJxux2IPBFch4UuTa+LNKlHT7SiMPVWO0j8ia77
wdmb4Q6/Hccwr52zP+4D/OvOdA/5GLS/+vuL/wBDFRRb5J03ra6+RdZLnhUWl7P5kOpQLaareW6/
dindB9AxFFTa7/yMOpf9fUv/AKGaK646xTOSWkmaN5/yT/Sv+whcf+gpV74a6bFf+Lo5rhd0NjE1
ywPcr0/U5/CqN5/yT/Sv+whcf+gpW78JJY/+Enu7SQ4+1Wbov4EE/pmuWq2qE2vP8zqpJOvBPy/I
5WS/l1TxSL6ZiZLi8WQ/i4wPyr1Lxx/yU7wp/vL/AOh15Nf2lxousz2soKT2sxHPqDkH+RrptW8e
DWPEWiaxNYlJNPx5qK/EhDZ+X0/GlVpOUoyhtZ/itApVFGMoz3uvwept+Prq5h+KOnrFcSxr/o/C
OQPvntXTa0B/wuPw+ccmzfP/AI/XmXiTxXFr3i221pLR4Uh8vMTOCTsbPWr+vfEB9R8Wabr1haNb
yWUezy5X3B+TkcdiDisfq9RxirfZaN/rEFKTv9pM6OELc/HaWKd2aONi8aMxIDCIYIFWtbuPDlr4
3k1C98Vahb31tKpNuEOxAAPl6dCP51yniHx/Bqt1Zajp2krYapbzCVrnIYvgY2ngEj61qP8AErQb
6SO81TwpFPqKAfvAVIJHTkjP55qXRq+7Lle1tLf1qUq1P3o8y3vrf+tDe0vV9K1z4sw32kzCZG05
llYKV+YN7+2K8/1nRr7XviJqtjp8DSyvePk4+VBnqx7CmQ+NJ7Txm/iO2sLaAvkPbJwrKRg5Pqeu
fWr9n8QrzSLrWrqzsFjuNVmEyNKciIc9Bj5uv0rWNGpTd4LolqzKVWnUVpvq3odH41ubTwf4HtvC
VlKHup1BnYdducsx/wB48D2rzbQP+Rj0z/r7i/8AQxVW7vLi/u5bq7mea4lbc8jnJJq1oH/Ix6Z/
19xf+hit6dL2VNpu7d2/UwqVfaVE0rJWS9A13/kYdS/6+pf/AEM0Ua7/AMjDqX/X1L/6GaK3h8KM
J/EzRvP+Sf6V/wBhC4/9BSsnS9RuNI1O31C1bbPA4dc9D6g+xHFa15/yT/Sv+whcf+gpXPVnTScW
n3f5mlRtSTXZfke0XWmaB8U9OS/s5xZ6vGgWQdWHs6/xD0Yf/Wrg9T+G/ifTXbGnm7jHSS2YPn8O
v6VzFrdXFlcJcWs8kE6HKyRsVYfiK7jS/i34hsUWO7S3vlH8Ui7H/Nf8K5/ZV6OlJ3XZnR7WhW1q
qz7o4+XRtVgJE2mXiEf3oGH9KbHpWpSnEenXbn/ZgY/0r1OH41QFR5+iTBu/lzgj9QKkb41WOPl0
a6J95VFL2+J/59/iHsMN/wA/PwPOrTwX4lvSBDot3g95E2D82xXTab8H9buSrX9zbWadwD5j/px+
taF18ablhi00WJD6zTlv0AFc5qPxO8UagCq3iWiHtbRhT/30cmi+MnslEdsJDq5Hodp4H8H+EYVv
NVmjmkXkSXrjGf8AZTv+teYeOtZstd8UTXmnbjaiNI0LLtztGOB6VgXFzcXkxmup5Z5T1eVyx/M1
FWlHDuEuecm2ZVsQpx5IRsgrQ0D/AJGPTP8Ar7i/9DFZ9aGgf8jHpn/X3F/6GK6J/CzCHxINd/5G
HUv+vqX/ANDNFGu/8jDqX/X1L/6GaKcPhQp/EzTu9W0PSvh/pba3b6hMkl/cCL7E6KQQqZzuH0rn
v+Ev8B/9A/xF/wB/4f8ACmeOP+ScaD/2Ebr/ANBjrzSvBr4mrCrKMZWVz3aGHpTpRlKN3Y9O/wCE
v8B/9A/xF/3/AIf8KP8AhL/Af/QP8Rf9/wCH/CvMaKy+uV/5jX6pQ/lPTv8AhL/Af/QP8Rf9/wCH
/Cj/AIS/wH/0D/EX/f8Ah/wrzGij65X/AJg+qUP5T07/AIS/wH/0D/EX/f8Ah/wo/wCEv8B/9A/x
F/3/AIf8K8xoo+uV/wCYPqlD+U9O/wCEv8B/9A/xF/3/AIf8KP8AhL/Af/QP8Rf9/wCH/CvMaKPr
lf8AmD6pQ/lPTv8AhL/Af/QP8Rf9/wCH/CtDQfFfgmbxFpkVvYa+Jnu4ljMk0JUMXGM4HTNeQ1r+
FP8AkcdE/wCv+D/0YtJ4uu18Q1hKCfwnouu/8jDqX/X1L/6GaKNe/wCRh1P/AK+pf/QzRX0kPhR8
7P4mZ3jj/knGg/8AYRuv/QY680r0vxx/yTjQf+wjdf8AoMdeaV83iv40vU+iwv8ABj6Hfa54c8I+
GZE0zU59dfUWtUm+1QJF9nZnQMNqnll5xnPY1zmleDvEWuWMl7pmj3d1bISDJGmQSOoH94+wzXov
hXRfE9xaxaH4v0V5vCwhZ1vrrH+gLtJEkU2eB0+XJB6Yqo2j63rum+Brnw1HPPaWUPlSSQNhbacT
MzM/9zIKtk9RXOdBj+E/h/LqvhvVNdvtN1G4htwq20NrIkZkYkhySwOAu3kY5qldfDTxHbeGrLWh
ZSPHdSFfKUAtGMqEJOedxbAx6V0WuXdrd6V8SrmwkVraXVbZo2jOFYGSTkexrLuYL9/hP4dvrGCa
WOw1C7eeSJSywnMRUvj7uccZoA4qbT7y3uLmCW2lWW1YrOpQ5jIOCG9OeKu2XhfXNRezSz0u5ma9
R5LfYn+sVThmHsDxmvabuS207V3RyiQeObrLdOYXtwAf+/03/jtc9daDDeeIodAuori4n8P+Ho8a
dbS+W91cHDvGDgnrISQBn5aAPPZvB3iO31qLR5dGuxqEy74oBHkuv94Y4I4PPtUw8CeKG1ZtLXRb
lr1YhM0agHahOASQcAZHc16tZxtbw+GI30qfSHTS9ZAtJ3dnQeXkHL/Ng8kVyfgWOLUfh7rmnR6X
dardm+gmksrS58qZ4grDdwpLqGPIA7g0Aee6lpl9o99JY6jay2t1GfnilXawq74U/wCRx0T/AK/4
P/Ri1tfEK6u5b3SrW80SfSXs7FYEiuLjzpWQMxUucAjrjBHQCsXwp/yOOif9f8H/AKMWgD0XXv8A
kYdT/wCvqX/0M0Ua9/yMOp/9fUv/AKGaK+sh8KPlJ/EzO8cf8k40H/sI3X/oMdeaV6j4xtLm7+HO
hC2tppiuo3WfLjLY+WPrivO/7G1T/oG3n/fhv8K+bxX8aXqfR4X+DH0K/wBpnMHkedJ5PXy952/l
SRzzRI6RyuiuMOqsQG+vrVn+xtU/6Bt5/wB+G/wo/sbVP+gbef8Afhv8K5zoKgdgpUMQrdRng05Z
5o4niSV1jf7yBiA31HerP9jap/0Dbz/vw3+FH9jap/0Dbz/vw3+FAFVppG2bpHOwYTLE7R7elKZ5
TN5xlfzc537juz65qz/Y2qf9A28/78N/hR/Y2qf9A28/78N/hQBXkuriWTzJJ5XkxjczknHpmmxS
yQyCSKR43HRkbBH41a/sbVP+gbef9+G/wo/sbVP+gbef9+G/woAqO7SOXdizHksxyTWr4U/5HHRP
+v8Ag/8ARi1V/sbVP+gbef8Afhv8K1/C2kakni7RXfTrtVW+gJJgYADzB7UAdxr3/Iw6n/19S/8A
oZoo17/kYdT/AOvqX/0M0V9ZD4UfKz+JiWfiHWNKhMFhqd1bQk7ikUhUZ9cCrH/CZ+Jv+g7f/wDf
9qKKPZwerSBVJrRMP+Ez8Tf9B2//AO/7Uf8ACZ+Jv+g7f/8Af9qKKXsqf8q+4ftZ92H/AAmfib/o
O3//AH/aj/hM/E3/AEHb/wD7/tRRR7Kn/KvuD2s+7D/hM/E3/Qdv/wDv+1H/AAmfib/oO3//AH/a
iij2VP8AlX3B7Wfdh/wmfib/AKDt/wD9/wBqP+Ez8Tf9B2//AO/7UUUeyp/yr7g9rPuw/wCEz8Tf
9B2//wC/7Uf8Jn4m/wCg7f8A/f8Aaiij2VP+VfcHtZ92ZbyPNI0sjF5HJZmJyST1NFFFUQf/2Q0K
ZW5kc3RyZWFtDQplbmRvYmoNCjY1IDAgb2JqDQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jl
c291cmNlczw8L1hPYmplY3Q8PC9JbWFnZTUgNSAwIFIvSW1hZ2U2IDYgMCBSL0ltYWdlNyA3IDAg
Ui9JbWFnZTggOCAwIFI+Pi9Gb250PDwvRjEgOSAwIFIvRjIgMTIgMCBSL0Y0IDQ0IDAgUi9GNSA0
OSAwIFI+Pi9FeHRHU3RhdGU8PC9HUzExIDExIDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdl
Qi9JbWFnZUMvSW1hZ2VJXSA+Pi9NZWRpYUJveFsgMCAwIDcyMCA1NDBdIC9Db250ZW50cyA2NiAw
IFIvR3JvdXA8PC9UeXBlL0dyb3VwL1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQj4+L1RhYnMv
Uy9TdHJ1Y3RQYXJlbnRzIDg+Pg0KZW5kb2JqDQo2NiAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVj
b2RlL0xlbmd0aCAxNzg5Pj4NCnN0cmVhbQ0KeJydWNtu4zYQfQ/gf+CjXNQ0h3cVqYHEuWAXmzbd
uOjDbrHwOk7qIo5TO1tg/74zpGSJtiS7ebBkUXPhHB4OZ8SGt+z0dHgzfnfBxGjEzi/G7J/eiWCC
CyFASuGYk4IZLdh63jv54wf2jK+5UKBRRjmLV2tytn7caglhQehE7eGH3slvvRN2eTNmrOYS9lw2
KEefDnLuDEMxZlT5l0uDCmy27J0M3y2nj3PDLlasyZOsPA0KRwJyV8TpFUCDTyNKlzrnIA1TwD2O
5EGp5ta2uVX7bo2BvNutdhhXjNQwGxxrirTu0bV51Pserdc2epRaQxO4INQWXBFCtCKnSbjgvXLr
29ya4Yfp8yPL/p4O3t/2izmcT1DvCpjnuKSTB/QTXAA6UdwrHNdOssmSGGVzz5BDw+s7xORxUw5d
904+ZbI/0JmgC9AlPA7tEO8mc/0/2eR97+Ry0jArW5vI1rcxXMqa708Z67Lh2iIrDWoHHLeJ58qU
BvMug77Rho2AVDY6J5UnCEsmHc9tAjFYy5Hf2lvuXIFx867dH/4YUL9dLZ5fWX+gMviJ3dz1VfYR
n3w2X357mr4uVs+M8P+cqc/92lRTqCWXuj6HA2GBSOLSTALPfcqdnFuyqRU3Oto8FcK7UTqFAAqG
ZlNlxEn5VDv7ZYWhsb7JnlfPLYHkuOO1T9UGLbIgPAeXyk7XaH72F+uDyxb4d7P5Nu/rbIMDPps+
4t/pou+zNvfSA5cqNdmNIyQ4Ggae78CoTcQR06rawnh+2QAj+ETRei6FrytmV6s1e5guF8SHJ7p8
b8PGeJ6rRLcVRuu4yBPR5eoeV2qOHiSGDzILDissBzZbr1ZIWZc9rFdLhoIumz/2bTadfWcva1rn
WZDdrNabNs5qyXEP1v12Qy13KAtmdyvi6llkj8od97KdsjWyNYhLN9J4MxJ/gCtl8e4wpavRwOG4
xmet6XTBu8fxq5E5ja+B/ugzfOfjO2PDO+NGqi5iSESOBjQYRKMJXXgBexpdhymEwWCqFCfPRhUz
GNMr8tbEpz2AVC6RjEnEB0BXR4OOidV1p4l93XIFKt3sOpLsFTdvSILEJjyFvs7xCXS2LKlFj7jV
py/Tr4snZN4CX7zij+7zTRRQIvt3MWXEzpvx9Zcxpdiz2x/jS8wCRGEk9uzl2wIt3LcRFYsRm8yx
GzLdcOyUIOGRaPxRVsyxiUUpycG/JbPUNUNqoX2vad+3JxUPqVp7VgmnYiK7eSHrM7yEfPKwoEQy
C+kkSTBtyTk3eIKmJrsxtEeTF/A89m9lb02ZSibKmTYQFeHEp3Y8reZKpfqteGLtY3ZkNy9z2g20
PYj1DwFEwlNZfCAon3D4vhVP5znWIInJbjzdLp6KK5kWQ+CwsMGlAu46MnDAU+8Wq6DMrnJ2QwiO
rymyLxjQePIBj+/hDQI8XuCGdhkOtIUnODYAibXu8PzR4TlF5dYbw6spF+HhwoEI8d1Nzia/37H+
rj3dYE9iXqIA08mcw1GTkVpQLZ1MZtdtJauxVWmY+N3414tQWWHimFNyDYUAjuSBmzgwW9DIwwJZ
qbBEWK9X67BBZqTQ7E27nHvbPrP9ddut0WFn0YwKuBsXQDhsUO4Wx615Qyo8FOwb80ZdObvCxSds
VDyatsfV5AOSXQeytzPdYx4xqb3uAOFopuPtUF5sJXqlG04XKiT3t3M8jaXL7hcU+Gb69YkOBDzu
pckCe/CQBsCDnJTwMJfQYOXLbd9FMz8z0UYs+ragk2l1o7RXcLahBHm9tv9/KNV0d1CqskLH0svw
PaFupDumvXquca+AVxzaU0r9UNqTVjbWz7GM1uN4oxr1siqDQyWtq9L3KkiVNTaWUKE4DrW3bUJT
7iUz6+rzOICCPg4F7IykPR6GVFxiaa7zImTqC2Iv4MMI1uux/A/dRdVBlB1GqO2py7gYDYLaOAjo
snswo0EN3RLrwui2VTHRVyJUvjRlmzMayDr0qrBRrkiQDB2JiR5ssXS1abtWL0HQxmeSPjf11mak
GgzQlzsVPBas2GIliq4KtnM6L0z7Q9GGeUA051IahvZpHBdnz3eBe9HaFVw+i60YxFsBYB2egNpZ
rUOLUDU3aSn1rM2JRHUuHeCyaWg3SgIb4Pqo2kceXSoDVR0dtc/OIbcjLvOquTYVW2n9FH02tREw
LSmP4M/Rp9R4Vz6OkbwSBZdIiQZJUcm4KYoGvuQGiLCyxWKF9Q8LpqvOu+rMbWytdbFLIzUCH/Ji
ZnbLqzAJXTbkJqUCCeTlZpaxuT+ySTd0qKTIHVi8o+tygKRXbDipmgrN8qRKlVXxYQQBijkhpPgQ
uYQqvcc8dRW3Ib6DPGaZuESRDXGl4kK5iFdMmfVPKWEbHVXaxr6mPt19/P4D8pwsBQ0KZW5kc3Ry
ZWFtDQplbmRvYmoNCjY3IDAgb2JqDQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jlc291cmNl
czw8L1hPYmplY3Q8PC9JbWFnZTUgNSAwIFIvSW1hZ2U2IDYgMCBSL0ltYWdlNyA3IDAgUi9JbWFn
ZTggOCAwIFI+Pi9Gb250PDwvRjEgOSAwIFIvRjIgMTIgMCBSL0Y0IDQ0IDAgUi9GNSA0OSAwIFI+
Pi9FeHRHU3RhdGU8PC9HUzExIDExIDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFn
ZUMvSW1hZ2VJXSA+Pi9NZWRpYUJveFsgMCAwIDcyMCA1NDBdIC9Db250ZW50cyA2OCAwIFIvR3Jv
dXA8PC9UeXBlL0dyb3VwL1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1
Y3RQYXJlbnRzIDk+Pg0KZW5kb2JqDQo2OCAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xl
bmd0aCAyMTczPj4NCnN0cmVhbQ0KeJydWVtv28YSfjfg/7BAgWJVVNTelwwCAbFiGy1iwKcx0Ie0
CGiZknUiiT6iHDf//szMkjIpkbSqB9Hk7s7t29mZ2TEb3bL370c3k98+MjEes4uPE/a/8zPBRCSE
kEoJz7wSzBrBNtn52Z+/sDVMR0JLA2u0d/B0NmGb+Y5KCCeFaZDNfjk/+8/5Gbu8mTBWEykPRLYQ
B5leJpG3DJYxq6vXSFkgYNPV+dnot1U6zyz7mLM2SepV0rAUJGTiSztjLWWLTCsqkSaJpLJMyyiG
kYSIamJdl1h9KNZamfSLNR7sCpZa5kiwQUvrEn2XRHMo0cXGBYnKGNkGrhR6B64gE51IUAlP0l/F
xl1i7ehTup4z/t90+PvtoNTh4g7oriSLI9jSuxnIIREShOgo1jBuvGJ3K/Qol8QMfGh0/RkwmRfV
0PX52ReuBkPDBT4kPuhz5Ebw13I/+Jvd/X5+dnnXopWrKbKTbW2kVE32F876ePguyyqGxssIjkkc
aRsYItZGO3Y3/cKl6OMdt7GLVQQHqs6OOPUqmTQQV0z5KHENyGWSRDH4sYoSWULefogPh/+gTbjN
F+stGww1V+/YcvE9Y6vBUPHFfJNuF/m6pl0DbakjYety37BEioYpBhQHvZuWgFOCKVZHzgeW74WI
/bipAcIgm5TaRXHcpORLdKIFPtAiepkPNEej0NZ8zQblfFE8ZwPD33VYqpTEfWsw77dUNiy1TLo9
S8FTyVLQW+idpReXbZba/Q33PnJxkxjs0HyGVhoO24bbt4WRDHZVST7b5HiwVjACAzH/QM+/ACHH
080cV+NKqfl9uv721wDePdHnSM8v4OlgeQF4IY90iYQ4VRF0AGeci6xrKtoPnNp3EbMfYBIZSTg+
RonI6Dd85IBYQuyTtkHMX8AFpEBv8eHBBsrz61u0+Sc2iHm6BVDZANYAEIa/PGboPmuWAhzTaYYI
FQUbaMtv8H0S+H2FpZO7Tx3IaCci2dSjHxh9NDDCRlp2A7MPRXO5+iiEMWMLr1aCQ7rw6iDD6LEU
+K5xBfz18BfGzUWY0/U5W85fjYdEP6E1Spa8rApzHr8TeI8Dj6TkQfS4xoZ1OI5rrBgPUU61FudL
3rLiTfITUhtJpArsTBxISbwP7MN4UA3Xa2CvEARYoz4E1Y0am2oIOGsdhsXVThPt3jekkuKTYJzx
tAR1VR8CNa4W7ihvxUwNibK+RW94iWnxEtfqJjoBB3wrxh5Sl15Tp+YXEBKeMVqwCwoLUvJpCt4P
8VUqCLNLjD0/KPbA1Gb0QuNFvspo4GZCyQZP3lc4UZOB53Bs8MRpiE7wMsPzl23oBGIYdxThDN9m
XWHHWAiQTSXZ4F/EB+0tprZjELdH5jQNdWZyUk6rU/L0CQx/wiyWp9PH/YSFFdkeE5AN5UaTSb9F
7sjcpbWK9Km5q07Mr8CmfINBlfJStsF0pfimY3uliaGQbbIYdq21Diu4xlpMlesZpTYI2Z//AOlF
V+bXNrKmSd6Pnj82TmvA1Z+awOrE/ClfIGzr7RLPRlYUCB6dnm3O7uGQJXRsYjw22+yhy9QYSkLX
5Lx/aPa1EDJyxwWm+EinUrGJYnmiU9WJ952KNn0B8QUD1c9P5F85zt5TjaTecgQjI6OaEvotTo4O
xcoBmvGpobhODUZDzbah+BrC6vVXGJl8uO0yC1JLkjR59JqlDmp4wGUv4HhSCzY0dm8YpZqUELb3
KPFCCBt4D/uWrmF7vhVgzq+UHIZQpK3RXPL2a3zewudPLERHLOvv4W2JuQOZrLDan6bP8CyyB6x2
PS34waqlQQLOWOL8DL/VPaQ0ou+KRlCDRMo0te6HUB4LoYGb1UkIvhLyz5go4YcXg2X5C8YX6fcK
mxG8bDKMHsUW8AnRl77ZyyNeI6jgDbcHj8HEVzep7FeCb5qviwUg9VAt3iwQzHkgAWGzZzp6hkAt
WSMvdE1briHCf7YV4CivWFTqdN5CjcE7f93kfvQPbhhd6CvImOYk+GuUgMxqBWaTbz1UCC7LDVlX
cNEo2YneW+1XaXg5va1G4OKhd3tJI1BRDROePsA3bc56h/srEYJuwv5uFtPtwL1yfWyoUWpcEw7R
pL5PRbZleFwaq+Y778DSbPrYauFTdV7psezYUhf7KE6aMPbv6dGXIwW545hQ2x5pa8T8qgqzLVe+
GMJWV7x1kZRNTv2mHVT0Xe4KufjEeFujpHABcUH/+7ggWwND6StVoJWhBfNc0RJbco0iZ9+yDEnQ
SVhROVhwHnTX4Ma4toPFfTU0C3l/Z0I6Kw9VCE2MNquu7KJi3xVlnNfYM21A1b9vB/eCLpeU4O09
1/Vej6zR7jnkNSJZ+uPoBsybwG9BA/By9wl2R0MwXtN1akZNMKgMCWCZ1DoeKV3eyrYIzDwtsZii
eUB51ZUToV52De36wXJHOrmEbfBvHd9WJ69TAkSaEHKAEDjE5A7N/xSsh0oQwzTGriLFumNXQHQW
znDFgMK5IaHf3IM7Qpe5TkSx6jPXdJnbpNRirMsmhplgTwPfQwND+/BXXYXeB7ZS1K5PEtooE2qB
ULPnclx2PULvxtOMVTva0PUw1LYh2itaUc1IE6RdIPfWJkjTHKy3m9Z030lKyw0kj+OyxrF3Eqlp
f066ktRo+STEzzW2MuAQTdMCXetdmVfR0zRdU75nNL8qP2vtXPzEtvVQS/7yuKAyQFet2+83k0tq
1+bT6TMG7s7uiMKmbF2zfpzabjLtoQxgODW51mh5ep9vIG2ATa/3VgpRnf+LUDLG/zrVmfTapA+u
MZ02CYG9pBONqhHzdb4N0fZHCK4JXM9zurIX8BVjBsSIu32k3ha1xqgpBq9K8Hm+ZThRQiMg72EZ
uH0uaPrn0FvL0qITIziVEXpzXacDkP4PSmk7Wg0KZW5kc3RyZWFtDQplbmRvYmoNCjY5IDAgb2Jq
DQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jlc291cmNlczw8L1hPYmplY3Q8PC9JbWFnZTUg
NSAwIFIvSW1hZ2U2IDYgMCBSL0ltYWdlNyA3IDAgUi9JbWFnZTggOCAwIFI+Pi9Gb250PDwvRjEg
OSAwIFIvRjIgMTIgMCBSL0Y0IDQ0IDAgUi9GNSA0OSAwIFI+Pi9FeHRHU3RhdGU8PC9HUzExIDEx
IDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFnZUMvSW1hZ2VJXSA+Pi9NZWRpYUJv
eFsgMCAwIDcyMCA1NDBdIC9Db250ZW50cyA3MCAwIFIvR3JvdXA8PC9UeXBlL0dyb3VwL1MvVHJh
bnNwYXJlbmN5L0NTL0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1Y3RQYXJlbnRzIDEwPj4NCmVuZG9i
ag0KNzAgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTE0NT4+DQpzdHJlYW0N
CnicnVbfT9tIEH6PlP9hHtdVs9nfu64QJwi0oioSd43UB3oPvmCSlGDn4gTKf3+zawfsJDYcL2t7
vTPffJ9nxgPDKzg6Gl6OLs6AHR/D6dkI/u33GDDKGONCMAtWMNCKwSrt9358gAxfUya5wjPSGlyN
jmE1fbZizHCmGma3H/q9P/s9OL8cAdQg+R7kAeMS0/KYWg14DLTc3lKh0QAm9/3e8OI+maYaznI4
hCRekAYVEOOxrXg6yfkBTM22kCqmXGiQnDrciYNRDda0wcp9WK153A2rLPIqmWowAVh5pnVE24ao
9hGNU6ZEFErxQ+JyJp/FZYGiYbEPwgb0F1jXBquH35JsCuRXMvh6FVUxnI7R7jMHR/GTjm8RJ0Bw
BJHUSdxXVsD43meUiR1gDg2/fEdNpsV260u/d01ENFCE+YX7JTwOzRCvmtjobxh/7ffOxweiMrVA
nrG1pkLUsK8JdPmwbcy2DpXlFMvEUalLh15rJQ2MJ9eE8y7f7pA7JygWVN1d8NQZZNxQXICwNDYN
yQVTlFv0bqi1leaHq3h/+6/wFa7yebaGaCCJ/ASXo3O8NWSe/UonkSTreZ7VAmwIzhWN68CvcOGs
QUaB4LtklKBcKVDYCIwrfR4x5uxxM4KgBNtLvpjGrGlMLpBGZMgE+XFGHi5HPsWQIVdknQO+SRaR
JYtIk8D6YbLcFC10JRNU8Kb7br68wVcDd9Q1Q7au5Ms1xcuW7+n5Ab7cNSw5wx7WMCQn2ZP/iIBk
VnNfQsWdv3+cpRkEYnAMy8kyUmRTfES6MUmyG3yCuafuv/d67uXJswLyyWSzgmQNCQR90FueTSPZ
YFxXp4xHxjJQDPGU3u5T8NaP+GBJdpOjj8c/WpwIgXR400u3xGInpVCPeEdjjmmKeS+toFJ159Qh
ayl2rclnFC1fBQWRliSZ++hljAZckzXepQUm1rrcsmSON9nN3Gdh4gvKH/BnY5LftaWaNFTJJmi3
DvKADuagDJr7LvmqDOagCjXjSoUy4wYOc0SSIMbmd6WGKDfWUXVikmTbW7+XL1JcV8m6TBC/NZtj
vhZeHImni61Skvwk4zx7CqbfNhPcv/sZtXUl/8vbCbVbO/Vm7SSj/L3SvdjuKvc9XySreYHUP5b6
SPZ24bhoKmd2hTvxjmd5u2C+geMcUQ+wWy/9Zr2Yw3p6r2A1YzLKMZ1I5r98uso+le0aq232tExX
D/6dF6wIRSkUKWZe4c3ixj9y8k8K003qVakkRctkmuXFusrZSWsucV+AjVC6tTFvbfnCaardO1p+
3ZCcLJc+FfJkMoPIkVsUIKhRdXls+D7L/Jlqp63h4OzEZN0394OC8auwLswPzZ1ydOgWw765OQuj
/Kj1junl/7fyGtY1thXft1IsJuzPVT3NQ6K0/KF8vLLpo1sEtyuCpFI048LR3MelNOWvtRe1O/Rw
43aNyY98VfgswKFHMN8PkBh3JPyBizAIhXJ4PnEXpoWFfx0WPBKXp9dFuvC/udu2vEF0nPcb6Hty
/AePjAe7DQplbmRzdHJlYW0NCmVuZG9iag0KNzEgMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQg
MiAwIFIvUmVzb3VyY2VzPDwvWE9iamVjdDw8L0ltYWdlNSA1IDAgUi9JbWFnZTYgNiAwIFIvSW1h
Z2U3IDcgMCBSL0ltYWdlOCA4IDAgUj4+L0ZvbnQ8PC9GMSA5IDAgUi9GMiAxMiAwIFI+Pi9FeHRH
U3RhdGU8PC9HUzExIDExIDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFnZUMvSW1h
Z2VJXSA+Pi9NZWRpYUJveFsgMCAwIDcyMCA1NDBdIC9Db250ZW50cyA3MiAwIFIvR3JvdXA8PC9U
eXBlL0dyb3VwL1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1Y3RQYXJl
bnRzIDExPj4NCmVuZG9iag0KNzIgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGgg
NDI4Pj4NCnN0cmVhbQ0KeJx9k01PwzAMhu+V+h987JCW2kmcDwlx2AYIBBIflThMHKZpmwQan+L/
43bryFi7S9q6sZ/XrxMo7+D0tLwdX00Az85gNBnDZ54hoEJE0ho9eI3AFuFrkWdPJ/AmvxUasrLH
eCer4whfq10WoiO0e2nLkzy7zzM4vx0DJEg6QHYkb5ieovIMsg3YtK9KsyTAfJ1n5dV6tlowTN6h
i6T/SMMtCCn6bZ/BEHUwGVukjYo0gyEVJBKbpATr+rDmEMtM8TjWeulr0ymDa8C27jQl+j6iPSS6
YN2GqK2lLnMJzc5cbFp0GGsRvqH/YUMflsub2dsKipfZ8PpusNUwqiTvgiAoGWm1FE6DIIEYFYzE
rddQresT5WIAOUPl5aN4svpuQ5d5Ni30YGgLrBeql+azdKU8ufCDZ6iu8+y86lDlEiE7NrPSOmFP
CzhWw/d11ha0npRck6AMbwrWXlvjoJpPC9LHaoeuckEruVBpuabSUZFxz3ENNT3xW0fpWYLiut36
3X2DD8MPzQRGs/nrz0eioB3tP5DVTgWXkvaF9+gLrEKUNHLK9M3kFyfA77oNCmVuZHN0cmVhbQ0K
ZW5kb2JqDQo3MyAwIG9iag0KPDwvVHlwZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8PC9Y
T2JqZWN0PDwvSW1hZ2U1IDUgMCBSL0ltYWdlNiA2IDAgUi9JbWFnZTcgNyAwIFIvSW1hZ2U4IDgg
MCBSPj4vRm9udDw8L0YxIDkgMCBSL0YyIDEyIDAgUj4+L0V4dEdTdGF0ZTw8L0dTMTEgMTEgMCBS
Pj4vUHJvY1NldFsvUERGL1RleHQvSW1hZ2VCL0ltYWdlQy9JbWFnZUldID4+L01lZGlhQm94WyAw
IDAgNzIwIDU0MF0gL0NvbnRlbnRzIDc0IDAgUi9Hcm91cDw8L1R5cGUvR3JvdXAvUy9UcmFuc3Bh
cmVuY3kvQ1MvRGV2aWNlUkdCPj4vVGFicy9TL1N0cnVjdFBhcmVudHMgMTI+Pg0KZW5kb2JqDQo3
NCAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAxMjA5Pj4NCnN0cmVhbQ0KeJyt
V9tuIzcMfTfgf+BTMRPAsiTqCiwWyNppkMUaSGMXfQgWCydNjGxzq9Oiv19yfNkZW5qpnT54PHFE
HfKQOqRgeAkfPgwno4sxyI8f4dN4BH/2exKkkFIqraUHryVYI2F51+/9dgLP9G8hURlag97R09kI
y8XWSkqnpGmY3Z/0e7/0e3A2GQHUINUeZMJ4helVFN4CLQOLm1ehLRnA7VO/N7x4mi/uLIxfIIWk
fyAN1kBSRb+OM6BSCUwrN5AmCqUtoBKBfomVUQ3W5WBxH9ZaFdthjae4VpFacBWw4UjriD6HaPYR
XTBuhaiNUSlylcQtubIK0cnITvgK/QdsyMHa4Zf58wKK7/PB58ty7cOnGdn9rCAISunsnnAqCAVo
gqDYgjBew+yJK8rFAFRDw/MpcbJ42/x03u9dF7ocmELyQ/Gj+nPohvRtC19+hdnnfu9slvDK1RzZ
YscooqlhXxfQtofPRbbdUFkRNG2IdrUhc23Qwez2ulDYtndIbae9QNPYrtqp1cnYYFwD7RFdg3Id
rIgKTHDC+zXn6VO8//NVlYXJ6AzKgSsm0xKLq7eaO3X3DaLAOkyH52ojO0yaV4xokJ7KqcodRaUS
AmgbQNHBcJoIqip0oysG/qmc3jVmp9utpyl31A6TiopXN6tX+cAZ0i4KxDWV0TF6lJpFyYc1k7u/
roksTTE6/1baYnR6maFROzp6vo7RxaPu4pEkDEFLIxxmqMyz2G6bJBL3iNwhMQrnQNPhifYoEpFJ
HM3o+0uWRMfs1TC6SNyoJyNihbvxgzng4K3MkNc02fKWtUmSZhOCQGkQYfV1ZLlVTE1npdPFaWl9
Mft1mmOMVIJafg2rizHXXnZI58dz41QcfsUC/tey67JNMuhTkmoC2WkR/bH0PZQDX2yKjTtQTvzo
1DawuugL2YLj6LFN+BIF12qTpGu3cSTkDtFy/36f3D1w5/hGb9syDAWzma1EQ2fH6AMEUMtWKl2H
9mXYbDNLEar3+8fO5GMqMt8le6tqPB2PeRC6yhJI1gdon9Yt/FX6f5D2tdokmcPkyfWCBvz3ad+K
rknpiovpKHtyaVCIBwifrg3amZGJtv0OcK3Ifw1fCQZ+hx7KCIY+hMCvCnm0h8eKk+TFxe6OdjvD
SCRYDdHRQK2PmusWjy835UAX88dsG9WCbhA1iC5u3J7PSVUJVB+SkrbZ9PVumXEB/aov1VcPcmt5
0o3NtTfz5z+y58Tw+N5Y3h5dqsVoa3ngNZoPQmc4OlI4qrk6G46kcLC59vb179xqGnjdjh/t0YT2
Bm69FJYSqOkmSNMx8qGu3epzvbvFLHn49/qQblSLJcLomPBAR3V7uA5cPFPreaDPX/T5iav9lZRh
+cI3yBt6uysH2OCpzqmjBuCpD1gKJq45ZWGZlqy+JMFv1b3oJGfOU6BqmremBPOdzBLXiu5WrKx7
uUiocHZ9KgmoEoVtg+RS1YryGY5g/my5ZG5fmPPccXCKLeoY+ePgqKG5nbWc2GdKyP0LJSLs5Saz
kcZKgEjW1GajbApRCauaa9tT2HEb49GCkoHO8oR72G2syzaZ2o7bGFoqDkMyS/Or+l+G5FybrVS2
hpMg8l+7eAi/DQplbmRzdHJlYW0NCmVuZG9iag0KNzUgMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJl
bnQgMiAwIFIvUmVzb3VyY2VzPDwvWE9iamVjdDw8L0ltYWdlNSA1IDAgUi9JbWFnZTYgNiAwIFIv
SW1hZ2U3IDcgMCBSL0ltYWdlOCA4IDAgUj4+L0ZvbnQ8PC9GMiAxMiAwIFIvRjEgOSAwIFI+Pi9F
eHRHU3RhdGU8PC9HUzExIDExIDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFnZUMv
SW1hZ2VJXSA+Pi9NZWRpYUJveFsgMCAwIDcyMCA1NDBdIC9Db250ZW50cyA3NiAwIFIvR3JvdXA8
PC9UeXBlL0dyb3VwL1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1Y3RQ
YXJlbnRzIDEzPj4NCmVuZG9iag0KNzYgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5n
dGggMTg5NT4+DQpzdHJlYW0NCnicrVlNb9s4EL0b8H/gUS4aWfyUhC0KpEm266Ipso2LFgj24NqK
m21sZ2Wn3f77nSEpm5RFJgL2UMUSR+89zgw5Q5WMr8irV+PLs8k5yV6/Jm/Oz8g/w0FGsjTLMspY
lpOcZUSKjNTVcPD5BVnDcJpxKsCG5wquSpakXu7fyjJFM+G9dvtiOPhzOCAXl2eEOJT0iLLjZcOZ
0zLNJQEzInnzM2USXiDz1XAwnqxmy0qS8w3pYmIHphNLlNEyt/MsOKUdnDJrKEWZUiYJp2kBT0r9
kkOrQrT8mFZKWsZpRQ7zMjOVRGligTN1GfMQozhmVIVQhpEJQbucSzO+d26mp6iyEkXkmv1AW4Ro
paV9MwXT3xlheVoqMr0FbA1LCQMf5gw8WUDCkOkqmEbjt9fgluW20+Dj2+HgJvlSrcnH02syOpHJ
djfbPW5Hf5Hpu+HgYtqhTTnaGjVCKUB11dwkJAaSWxCQUaAYqSWVimrNTKG3hAQ0mLtJVVZqTzb5
zyAI1oCCk4/GeanSPQTPuiDQBTCBNC8ZXIuCudyU4h/LDSnE29zGwHC3xi23sbDcbQjNwpV0WZTH
YActg2qh29EGXbWRaRlBNoMhZDMaQma51L60yDz1/WKHLbY7atDteIPuGsD+k2M8bFCUEw7GhTsd
2iY1w5aUHpOa8YbUe13j06JMD/AibQXbDFt4b9Tgm/EG3n/d4MPDQyrDTTuVrcGe4jiVrcWBpDhi
KU1+B6dhx8PzsAadE4F3ioLsIyKl3suCXHY8zGUNOrko+YkX2Jxgb/mbmAVXlGRlsdETktwPB9fD
QbPazLDFdg04gg2YTju7H4BhninngbGkrqVZvY6leWBJjZFdhAcj+8A3MuvJMTIPPCO7LA5G9oFv
ZNLYMTIPPCOTiwcbc++bmFRybMwDz8jmwsHIPmiMzDZpg2JSwgsLvnWwsHe+ifV0UXiCzb1nYnPl
YGMfGKOj4lK0qictvNLJeSokJJTK04zpYkUxr3W+3SSTXTUSySpWvMqOCpjD/EoP9IkKSLMOFCa5
dpqLcv1kRaa0AwqaoZTzPoJYV2HHVqbwUc42q1W13sUl8Q4w6C7TopePhBdJCg9SaGe7ggmbOo21
QcHm5/JsdMKSUzKiMrlb345UUs+2cN2NeFI/QirMd3itK0eoOyla0BQaiIOAp+YkI3F3QLbA//jw
sKnhL2qpFgEBHFzAyh4COhs4G2cH5HLzowKv5MktemIzksmKLEYnPNnA/Sojuw14iXz7Bc55qEYn
4KIfd1uwwuE6oFUJqbvWZ2vNuzLbhJyXILlJyQsMIhmVyWwNehZklCefzj6chmLGYbV6AHEVRThk
LkjfkD1fQNeOY0PmgnxCBVW9fZjNK+MQLrSSjf13jwbkHn8ulxjLu/WSjFjuuE3/mt3/wjVwtw3F
EUhVDw+yrs2uiSO0xqpsZrCeb/RqQylVXetkgr5gDslY/wqogWM1lAMfKC6na8NsAuqi9I7o8yVE
dlsP5VJHcrWpcaFhhqOmef349auJndy7KSBNYpBUH2lde3cjjcMW3qC8xwzisEdkSfXvw/3dXGcU
+gl0qeQn3tZwL5LQ5ikBDrW5qCdB2zwVLQVfZ/PvwFU85QNFoc3zX427QETyNaNwaN3XQkzVA792
BqQrxgwfRLKWFnnahouLilQOD6V31j5fQqR2eCjnsx2UghluNfBn4booFF4G7hV9tHTVBquFFXA+
alAmayxLTj2/Q1FrgrW+2s2/mQR+Qh1Ueap83Li6rpphM4jBoYPmTbfCuMTPSVxy/CPFvl85HjAd
y+kVLqyLiW5Z3lx8xLtpKMmoXjQO41O6u0qNTTIP5fPpJETKyhzT6vmkvKs8NKF0Uc6xOEDvgaHS
28v6JYQSd0V9N9ObDd5+x02nXlf34CTo6KrZIrQMFZe4BfUQ29lt28hSlaoGxYsThkkk1+E4Ka3C
fT+uoqt+NHFyUfpuBj0kROqEh9JE7dBkBLpGvRKhAQgVMplmLehQsVCwjbRMfza9a/092J3SVLI+
HoiUCZrDuYB2psLkw7tgGnBU4L0bVxCpCR5K3zToISFSEzyU48UbkIBfALJeXogcEyiD0ybvisMf
F9fTMX7zfgu/QgFRJZ7uPJC4lMhZwUP5MA6dTlgBO1LehzNyPPBQ/t+F6EHHF6Jn+uyF+HwPiMj5
omApy1nLA19wCayJrp34Px85nIR22A/UtzPsr0MNK2MKp+5hxpVFjhoeyufJVTAfwA1lH87I2cJD
WemOvbrfLF/qU+D8Ae8fIfpUB2h9f7eGlKj0KsEHt/YfPK90j7/YYCpVv+kFRbDyNpfA0jYqlIRe
r+mjXNZvG/vpZbZYvNRfH1YVjjbnH3ecwE+tcolBhdNQ5LBatjjj/uPj9zM4XCV/z07eXY1a36CK
o09QokglRDMV1rEZHLT0p3LzQzdtDJdYhheKF307VmOGns2jYjprTAnbknAon5qRDM3o8LlQpgUD
RC4NIvacgisynd8kVETBuwoAh7XLhYenoY5k/gdpUVQoDQplbmRzdHJlYW0NCmVuZG9iag0KNzcg
MCBvYmoNCjw8L1RpdGxlKFZlcmRhbmEgQm9sZCAzMCkgL0F1dGhvcihJbnRlbCBDb3Jwb3JhdGlv
bikgL0NyZWF0aW9uRGF0ZShEOjIwMTIwNjI3MTExODQ5KzA4JzAwJykgL01vZERhdGUoRDoyMDEy
MDYyNzExMTg0OSswOCcwMCcpIC9Qcm9kdWNlcij+/wBNAGkAYwByAG8AcwBvAGYAdACuACAAUABv
AHcAZQByAFAAbwBpAG4AdACuACAAMgAwADEAMCkgL0NyZWF0b3Io/v8ATQBpAGMAcgBvAHMAbwBm
AHQArgAgAFAAbwB3AGUAcgBQAG8AaQBuAHQArgAgADIAMAAxADApID4+DQplbmRvYmoNCjg0IDAg
b2JqDQo8PC9UeXBlL09ialN0bS9OIDUwMC9GaXJzdCA0ODA4L0ZpbHRlci9GbGF0ZURlY29kZS9M
ZW5ndGggNjA1MT4+DQpzdHJlYW0NCnicrV1djyy5bX0PkP9Qj87TLYmkPgDDQIIkSGA/LLz7ZgSL
Xe+FbWDjXWx2Yfvfh0dN9fT0lMia7nmYW7o9JZISeQ4pqaqn5W3fmmyStla2lGRrdUu1b61tmWnr
+0ZZ/9c3annreWPmraeNe906byJ967SVlLZetlK1Q91qlq23rVa9ReWhu/56ly3tu/7khH/0R+9O
u/4katrgLWX8D/flgk/UHhL0Uos4dW3oD1ftnlSOZO2hepOonpRUYCGI156l4Vf6U2uG+C21jMHp
T9MBYZSps/6T6pZ3SFXpea/opcNOucEWbeh4U85bzqIq1O5MUJhJGxVmis4Rq0A1JXPHCMqWRdBd
JRe9EbJ0NPqJGpcro7vqqjoxiVRg0wlMpCo6hkMquTd8whvtgk9kI1iXqGoDw6GiHsFwdNbUNapd
LSBSXyVSL1Efs7URF9Wln5JgJjhrA7Oq7qOiCpOOn8q4WSVXgRyV3OAHVskNN+un1OEvVskdQ9Y4
4V316PRvPJymVnLC/AhtnIdDijbGzbIxoifpjDBpnOA+DSC9uewby7i5a6PozWouF9xcVHLBZBaV
XMfNKrnterPex23crHJ6gqsLQhHO75vsOjfqfG1gWuquUY051IiRjDnU+yQjNtTTQoxPaBNG1NWi
jYLQVywIhqxRpZ6UAQYpCNGqkgtCoqnkKogmldxws2JDGgCk0qULPlFU7IhlFVF2tS4psAqiKel9
BQqThkXJiB81V4eOOO1bIQxZ1RTG/CjWCmPIgJlgfjR0imB+9KcU9VVSL5YKBAwM6pSkrnIa4KA4
1OhDmKscGKbxvtVdUaK31F1nBKCrRScrq7UKGA1BRV6tbUBiq029mPX+ikDIirwGxGT9abt6SNGi
8EZMq7UN488ab03hoA3a1AgVqJ5qVACtujUGSFRWU1dqA/SjQZlVcSs7GiqwlIE6JaMBPxVYddKz
oqo1RqNoo0MguEnDK6sFfde4zwq4vuvgsgZ5R3gpaJW4AHVFVc8VDeUpUmhlDZhOHQ2lLBYAe1fS
SmioHAELKvK6ukARrnLqjobeUzF2cGEb4FeBTYMg6329MxqD7nSyM4Pr9oIWWG1QA1y8IzSyDEpk
MAkYbkwXjVbBxBUwI5SDs5QR4AvIK+qILBcWBecwWnDZIMzhMwToPpwGdO4dUQC20Rvx2wb2BCmB
JxKiKhdwIyzKZdBywmeDQTV+M9ChhKKjRYQpJego62BTtSMjwtOwCrSeRkAN9q1gwDrIFrN5IVmM
aBB5x3wOAu/aLwMVGpAgRtDqrtGvXAnuRTw18CkiL7dBzGpRBkLV1WiBfwlzCrpV36AF3hbMKcCp
UwKCheSCuALTKjmrpcCemoYWJFeEVgdXN8QWyFr/qzoGx4MIlaZB6YghcCjtKoGQ3gg8mPtgdUVE
7mBqjDUrWSjBg7XhQYJ9BFIj2EegCoJ9BFKlon4jJD6FDVqQUsHvICuqiO8KCxQp+hm0dXA0sh/v
O5LPaGGGQB4MCiakTQasCDmRMbME2mAa2aWg1dFCDxbch4yrLKotyBP1EY18UAitkTR0ngiZjqug
BXlNLSLkKIU4WpCnyNMWsgsiUXMZ0gtSDtKTgEFGchWQWC74DFEIz+qMImuNREIdWQ+piTXqCBQn
orIIKU1E55lopCCMkpBxSh/pEblHEQHU61xk9IXkprFCSBsC1BKQVzB/8JO2ChIpEg8yO4GqC9if
gOkC1I68W2A5bNSWxrKmXiQv5F6wQEGtRMB+UbO2Qe+lJMiDtuFfZAytnlQe+KAAySSQrNyorZHf
1LejHCpACo3EtmNOge6qQEeCR7LDnALdFfFHMvIerAK6K+zN0KbBrjqA7loTWqNcUsQS4qU2xClw
XpVVtTWKQsU0jUy2I5oQYQ3VFQHJDemRwAcN9Ep1VF3wFligYQyYG4U+vDWynwYMCg6kSIwcONdy
iEalqUlS0ILkinEA563Cv8B5Q1VJwLk6EC1I7qhk+kin8CDQrfQCHciIqNYI6O5IrgR09zwKnJFc
E1pIqhjXKKI0INBCX2SqUb90GUUSWmWMHNm3dPwW2oZ9YIYO+xg477CPgfMO+3gHg8M+Rq7bYR8K
EM3PGa2RqXWEDF7ckTsYnLqDM3jkXfiRE/I2Z7SQ0lntYI0PTeGEFnoU1cQJOlB+MlKaVrhaLo2i
V3O3tqCjocwa9S9KUEYBrLlCtYEhNfmghcSP4p1R8aZRvOWR+vVuRsWQwEY8ambgipE5EkaIOllb
YJqKHoIoKZBXGPViRU2gMcWjggAuGTkJbtUW7usoMFEh63SoXuSfjCqfUSznURsiA2YkfgYfZ+QJ
JtQEQB2rPVpBqAcuhQejZBw1hGCekauVaFCXQl5VX/AoR4ZVyCEqTmeSIaVn/BZSOsaLnKR0jc9Q
J+i0oahFwQGrkEcJdcelrkDO0koXxYfaC3bVVkcZjL64W+kVhYjOGqNaUDhraxQwBfOs86At6C2X
BQjuyyhUMBsF8lC0MwoTDXRU0ZA3fFlG1QK9mHsNJG0hQzNqYkZ2Z1RQjHqQkRexzNKqBmOro9DB
vCBDM6xk1HIM3mWUUwzUcoWOgnFUyKsJLdyHUokb5KFW4jYqIYyjjqoHEYuyUfaE34KfdtU+qkPB
IolHnYRqiVFBCHiXRzWDPMsouwQ8x6gWBDHAHdURKhQVj5oIqxXUK1IQ931UR2PpAL0VcTVqJxSZ
jNyvhf9YWKBiUuQIECXgXUbmLQpH/QxVD1YaajiqKI0aHrlL8aifjdoJKwXgvAAVMvIyuEX2keM0
VgSYLlgJCfBbsBQa9UpBBuNRWVWVP0rS0jTGBdgvWGwI8KsrJbQEtRj0AskVhbkAyRULDixntIU1
Sh5VmUY/Vs9aqe1ooe5CxhDgo4IBBDiv8KiABaoQWpCnQ9dWRUsjSYBQTRpoQXLFWgm41PyBFvo2
jBe41DUvWozaTu0V4LKhFoV0rY5orMXQUp9pokeVhxkCQhsyrKC8b8hAY8HQwBkC1DZEA5hPyzXF
KVZJWu9h5OA6zR+QDB1Y3Y4aWqdPfwvUNiAFvbQFbwG/mvLQQjUITAuQ11FByajtUJULkNxRrwqQ
3FFhyKgVaWyLjFpRvTdq4w6fCdhCVxRqH9Ddi1y2T5RK8NtRmSL/okbQvIkIK6PORIQB05o/sACt
qDN3tFD57fqvoErZUaFgqa+ZYsQLPkM9KMhsO3iYR/0I7hNUZbtgGVxHdakeFeR+XajqXKG+UMfo
7FbIUzdoa9SZmElkbSUQlVxHTQm/ob5QUtbPUB0l1MByqS415sGz2sLYFN1ae2JsowYE/0kbNSDG
hkotAQeCnJ4wQkGu1lILrYTWWGBDXmW0IK8pEn/9609fYJtp337/6ctPX/74zV8/ffWPHz9/+vLn
n37548//8f3n//30xZ82Gr//7bb/5jf//E+vu/znX/70y0+fP/3r9z//Kv/L9qbzb/+wpf/ZrjLc
/nzcPz/Zn872/+HnP379189/+/rb73/5/PV3P/3w4//9+ZvvfvjbsVQ+lNpN6hdHXWQrrilfff77
z9/+8Pejruphveeod0+eSl33P6wyL1WS9f6vdNjxYY281CjeINP+QJ/DqAz6+JHojazgHuzxjktb
jbO2CcTv//Ld5yNJbXgFO8/jcpHbLnJbu1z6RUu6XOhykeXczphdgT/xG/Rf+5xG/0WIK8CH/+MC
6LSARwjghNjj/uL3D71Rrn1Q1XsccKgo6NQe6dQf6TTRu5oIB1Y42EBw41zjck12veGue2sSudYE
8epZk9jROpnlmDNTEOWu2rJUez4a0zFKcK7jzVYAAtfs/hFmH6MIZ06e2eVxs/M6tN5h9gKTmV2z
j0F5zmz5CLOPAX5eQA6wHpJeTjeT5RZb+QlE0f4Bk5XP552FgGczTA5STCwgwEnsrvriLiquu56I
baqxu2JT+42pbmTREwmLT0RWaCrdgICza+oTIGD6ABBQAIJ4rHwzVjeCKIh2d6wfEUF0U5GxH0HH
9H/KVPkIbqIAbfFYb9AibkHFT6BFnIJK3KUaP1HGybqewnMYntYn4CbN0epGEwcY87SWj4gmDhJV
GE0sL2MtfjQ9UbmVdTS9w9SbjFZcPuInMlpZ8xGe0/G0BiWaq/UjKnIJ8B4LOL9jsBBwjEI8s+RM
nDyBourwVHV5Sp5YQNUT674wnuUGetWNLHkCevVDIivImrGAAJGxgMUGR3MjqzyRAdtHcFa5qReb
y1nliQTWPqKGKnRjqpv1yhPI6eusl/z99PJEkdk/YuegHKMwdXfnoDxRcPb1zkHqfjQ9kQG7kwG7
y1MFz2c+oXhNVXgE1FFc01Yfxw8OH1eK42OBtNsO6J7tSnZlu4pdi12rXS9nBrYrOvcpxxPel6v9
Ppv8bDus2e7PJj+b3Gz98uxnO7Rk/cjsI+tP1p9ML5kcsv5k/dn6s/Vn68fWj60fWz+2fmL9xPqJ
6RXrJ2av2P3F7i92f7H7i91fTE8xPdXmpVq/av2q9avWr5qeav2a9WvWz851LJWMp58vV9PXZj+z
0053kh3vGP4nIidGZsguwnnuHaxo+TLpr05+XjqdPvq5SPEl+Gc/T0ig8xIeOf15I/fcAfDSHI8g
0o0r7wWkc6fAj+nNjt5TR8GPqWVH7VyG/+7ffvjuH96p0pueM2P97r+Ptba11ryHWhchn7qvNSdH
aw61LmASaiVHK4daF9AKtYqjtYRaF8ALtVYnmq5aj7teqNocMadmGrsYSAsHIo8FaO5rrZRCrQsC
ot3XSg4HEIVa64NaHQogCbUuSC/U6vg1CBWrcmxKppELM2IOW9BnFCLkcBiHHJYXzEkBwtjhMA5D
JC+Y83q+sdLqhAiHIZIXzBlqdULkZZ6Ou1posBMaHIZGXpBv6CQvNHqodUG+kVbxKhcfUWzka3W/
Tc00diFSXJG2tLGUMbl68sIE5hzVMxXMOkriFV22FVy2lVu2lVu2lVveZ4Vvw7BnX6wkm7NwbL5E
D3zK22e+XjqdrvyFF2pPV/5PSKDzEh6p/N/I9TdPZ+W/NMcLJLmJxHsBxd+TmJX/Q3pLcvROBLiV
/2NqyVEbV4j7oueVFY5J6vbM5U3fkBrTIuSvpzULrXVfa62nK/83PVOg1Znherryf7dWcWb4Ok/H
XY3+b09a3qg/vXh4t5Oc0KhxaMiiZ6C1OaHR4tBYEE4LnNSc0GhxaNQHtTqh0eJCeUFyLSiUW3O0
JjcgmxMSLQ6JBT1G09SdkOhhSOQFM/ZIqxcS/jTdnnm8URtGU16QajhNTjT1uLZekGoPoqk70dTj
2npBqoFWvIn2sHOskuxOeVF9XrZta2OGibgJgRla09dzNIeqaA93L/KCvwMmpX0dhbTHUXjM37RT
oHUdhbSHuSof83es1ctVrjNtKqZxj+Vp87sda5hPp9WLEYV7ZXmRVYK8TbtXN/uLxGIDsXMdKy7m
FE6jF6LZF22iyhkR7sOy9zOZ4hRwnHgo+YxKyfFfCrdZ6DjxUOJAq8MWKYwaOs4e9HJ4sNC6jhqK
jwDoOHuEWvN6rUXxEQAdZ49Yq+PXHPv1mI8pB37Nnl+vFh93dUg1ubiziJk+nLM6rY1wcSzysjdj
Rj/CBobZafwzq+Zpiw0vOYv38/s/JDdudbc46IkdDsoOU7/D2JeHM+l6FnJs7BPbIkROUXu0vbTY
n4q2SOLnbhf1/DskLCjSf1eDFwXyuclbQ4XIf7Q12tFz1Tqkzu4WGq82/M6o5TMgjN202EF4h4QI
nLGE4xqM2H8O/xmcsZMm2H8Q/4ntR2KnLjvPRfKyc07iBphEu+WeseKUDeK+GyTPoFicukHc2lWe
QbE42V9czpJnUCxOej+PIHkaxfI0iuUYxSeOo+wBuiy2krcH6LLYasYepLNzkHkuMc8JZhk0vpfu
crVqzE7dLF+P7567XO1+ezDQUtLMEZO0xzfKXa7Wzx4MNF6aRDG+M25cxfrZeCxaZ/iMb4C7XO3+
st5foRKyQTE22A86nT9GKwu154/RHpdA5yU8dIx2L/fkMdrKHA/Gt++33AuoJ4/RHtFbk6P33DHa
Q2rJUXv+GO2+p3+MRq/OSu77nj9Gu+8Z7PS8Oiu56/uyCxoeo71Xa3a0nj9Gu+8Z7PC9Oiu57xuf
lSyAF5yV0Kuzkvu+58/A3qm1e369ztOxwUb8zUF9j0NjQTiRk7oTGvHBx/UY7b5npNUJjR5DfkFy
oVYH8oGT7FyAXp0LLFF47GcTYUcP5tNpdURixxxmuX/uYjdHVA/3IdOCxCMm7evA5RNnJcf8je84
9bTyvg5cPnFWcszfHJxa8L4O3BuLj7uy0zU+Zjmm/nia1jHP+/nDvvuefsLhtKZDTnFIHFN/rNUL
icA5FyRx8kogF4wW6jOEpk+n1Yu5iJ83XSSkAJScnGhLcbQdZxNOkVYn2uKDkHycTWKtDgHlONqO
swnnAFnZibb4rYR8TLacAwLKDgFlP8azFxJ+bNvbdJwfzlUWdDMMprELUf5RhJ1x0jzjtHfIDOMT
VXNQz6xM1gLinQiyHQWaOwrz4MPOValY4Wev6NnSbi615iwsXD0hvFzRX+y7XdG/dDq/om8LtedX
9I9LoPMSHlrR38m9vh4SrOhX5jiBxLcviLzR625Mv6zoH9JbHL3uznR/Rmtbao1hw7bxxvZGLtvG
G9vGG19Otaa/5vzN8SzGGr3Yb08nv4LLtdNpuFyk+BJ8uDwhgc5LeAQu93L9L7m6wmVpjhdAt19z
9Uav/x2iEy6P6e1rvdezEXcD7CG1t2cjb9RG7z5fIzfdhK7/pVNpEa7XA5Gv/v3YzuLY6bJJWoR3
qLE5Gt1XmNMCDpHG2230pS+++v2xtcZEdsTA4oRTcc+80gJ0L1XLwnpyNLrHXXPj690axdHoUkRa
MESo0SGHyENWktlcTAsXdvjxVa/bUG86Nn8A1Qmx66sJx0oXLBNqzI5Gt+yZuzPv1shPOMkSvz3S
yNUJ6uqGGP4uxoJ5rquV1QCcKPO/fyovmCfU6LBFc0998oItIo3tTN5ZOMnWYDYX08KF9X6IyXW7
4U3HHAzAibLmpsC51fBujQ5hNDcF5gVbhBq9FBg4yb6kxeZiWngsq/sh1q8Px74ZQPcH0J0o624W
pEWdEmp0CMP//ilasEWo0cmCkZO6rW+65abuBHV3Qwx/lm1BBddDldUAnCjrbiLEX3ZbwDdQij+6
tFIqu5sIaQHfUKOTCEM/WVV3mY5p4cJ6P8ra9aHKNx0pGMA60GR3cyEfwzfWuOYM8f9gAh/DN9bo
rcJ8J9nEz7mYFkZrs2++/f54L8K+hctWDbM2neXPzLCTxCdPzDicQz2ehvglCD5mIwlegpDkaQ0f
lufj+kWClyAkrVOjxHv/fExcErwYIGkdLBK/BMHHq55Qa3awn8MzHT7mS3l5fWKhdZ0ZJH4Jgo85
M9bq+dV9CcKmYhq3UB8+CcLHlVPspDX2heLQWDD09a85LLSSExoUQl4WLB1qdSBP4WGULJg61Or4
9fpo/lrrgt5CrU5GovBIWxb0dn2mf6H19i8i3Pfl8JBRFvQWal0XLBJ/WZEs6C3U6hGN+7VB5oA5
JdPIh9jDNv4NNTOOZ2TNUUTJ6jjemxGTqbBXrIyM5iAX0x4yrSz4Pcqg7DBt/FVLsuD3UKszjRLS
pCzImQMQO3veInFgL8hZglwmTmBL6NeyIOdQq+NXCf1aFuQcanX8yj6Irey1KZlGPoQ0e4zdrF2M
JCTtsqqEg9h2dvOlhMm4LFJFCepvZxdeSpiMyyJVhFqdZBx/G1FZpIpQ6+OhYZvxNiXTyGjJc8zn
Fqj2lWnG0ZM1Z7zPSJujWqjafVVmdXK2ac6c+kla23DilNxeK2F7rYTttRK210rYZsCOaeex6TzG
nAvpOdqF769mrM4eLxC6PTV/6XT+1Dwv1J4/NX9cAp2X8NCp+Z3c4K9sXE/NV+Z4AXX7dzbe6HU3
Dl9OzR/S2xy9Ewn+qfkjal+dONwJaGEFMV8bedMzyKqvjhzu+8ZPri9CvvlPOMqrjfv7vvFLDQuY
tGAZ0J0ZPvFGwgJaodbsaI39ugBeqPXQr/8Pgj3xPA0KZW5kc3RyZWFtDQplbmRvYmoNCjU5OCAw
IG9iag0KPDwvVHlwZS9PYmpTdG0vTiAzNTQvRmlyc3QgMzM1OC9GaWx0ZXIvRmxhdGVEZWNvZGUv
TGVuZ3RoIDU2MDE+Pg0Kc3RyZWFtDQp4nK1c244kt5F9X2D/IR93nzp5JwHDgHdlw4bWgjAS4Adj
IbQ0vdLAo2lh1IKtv99zsg6rqmuSwepqvTSjs5IRwbgcXpOplWVdUstLqijS4hzKWhdXypLXdfGZ
P7cl4HlewxIKS7/EkFG6JTaWaUkpoYxLdgEl3iksy1KCQ5mX0lC6dalpxf9taXwH77bM0i9u9WDk
oMBaSURoEsmuLM5vfDOI7EG4xQXvoSVeDtA/VVRPjk/wUyptSWDq8la9sSUQ6fFT9dAJNV2tDURY
XKPWPi5+xe8ZGni38qcEIqO6r4v3nk8KiIonASYJkU/a4iMMkgOqR7YihMUntiLg5cRWwEZ+UyOi
VmErAmoVtiL6xVdPwoGo0DBAVosk0hJWmC4HD6KwOuzu8GKOBQS8lGNegk+QDnOGQJtDpxAK3sHT
EGn1hOqRLUUjQ6LOKS6BTsnJgcggYoVHA0XgnbpSBN6pbE6CiIZ254yXG0ybEQpoMfjANHFtJMIS
YXEQeYnekUggCjTMDTESSFQQDRpCuRipM/wRkyPDAoI6wyKRBsgJtQqbg3CMhWYB91gptOCd2hhZ
eNLQuFwQtStiKuO9tNLL9L3zfAdRDDeDQGh6mC3DjglG3AIzBUYnbJRiYETh5QQDZARSopoZnk4F
cZERYwgoimCGwCS5IuAaHUfLHqQzI9DuvIU4AiSzgqt8woBjxDfP0AHDRr/CNpl5A0stBUkGN+Bx
2zyU8CTQ1iQ8LRtAJLafBBsAXxR6sUYS1AlVC53XEjlXsoj4g6du5Tt44hL/80vxjgSeehgSj5Gi
gQQqBIQWrV9iIoGniY+RegXmQI11KYzKQhZs5aZTSSTwtFIOcqcwfmi+0pAOhY1slURe6or4ggpL
dSuJBgJOK/AZspNw4UG0A27UQDVgUDSURARRqGYAjFANVKhwBghwZiqgBUtFm0GAYaEaCMFaPQ2A
J5UNhNVgMPBBsrUVgVSgU3O0DRKtOQRSQX41H0gkEPBwQcI2pBMtujTqA2MvjfbJ4AXD0yEOeJbJ
py6tsBZ0apubkHGtEQ8hrzWEX0EmuJXpVBJRz9FMSFBQCEPYm5AY+QzAt4aVzxqpzGfAtxUJR3eQ
onUzQTTRvJk1CMYlk/OmUWbdzUvExpWpVRDpQNtIaiXFwCnk1xIp8IMymQ4mVUgRlh1jC1qAohUL
qS2W8AZ+DAyAlRSNDecCyNHWUsEZME2KnJn3jGTnmIgFCQuKIZUpg+0vmb9u+mXy28wXKa0xGAn/
fqXOlX0EWC80ufPEoYLsBAWZzF63QTaiEVRklCFTQTFy0ALnE6UhV9HBMAra1tWwRewQPSOwVL7H
/xHKoBraUVdyhsMXAicSn7ELP4HCOxVZ7AJ7kbqyo0LXwOgHBUwHVUgVPoO0QCSoyFdQjc8gA5Cd
mSag2OdVdpKB+Fq3HpA5WB1lULfKnjNURj27zlDJhV0mnADOiH0X141LIbVxgbRIuKrsG6MjFyS4
i55c2E1GNAlUJEUu7DFjJBckOSj4u3rySxuXTGrjQmnskGogv7JxoTR6tQZKI/8ayK/CZzVQWot8
Bs6JvV9FlIHKhIGy9e+QhjwHhehiSx2AHe1AfIBqlAYZKSDWmHEuRWY8MhoU7Rw5SmD/XCM5J8RA
jeSXNy6USwgujdIYhTVyFMEOmIMWl5mhFVEGqhGBwA/g3ohFoOBgUInjDsYGMxm9NH8FP3TK4MIo
Rse2gRYojgEqszYT6CujPTPHKzMg0z+V2Y0eBzoz49GdEOfAD2DPGpkU44/ZXTYLMbvLZiFmN0CY
1EqqUQPoB0QExUwG3PHXQIp+Y/4WIkhlxkMVYij5sTeuzPPCHqQSGQrxoTJ/C+3EEQyAnO1gniOF
SHGoRQSpzNVKBKlAKle3qGNG1S3qiBF1yw9mLYKB/CopcKjMVbiM1EoK2VmZqzA2KXLZBpbM7sqh
SSUe1K0noS8rs6kypyutzb7SVfbgxDtQ0KoxfxugFdRKqpEfdG6OAM6sRQX+yjGjr3wGfugPth6E
FPsAZm2LiVTh2BL/0yKg4JXGrG1562oog900UQRglkjxPeZ4YyY32rgxk1vb5DZSsF1DTPt1zfwV
o0ykNDuqlRTbgZjBUBbWZftANVIYYGI4QLkYjq4RrWkc4KLX4K8c/DI6OdQDxXZwHLxyaNg4yF05
fGgcCa/sY9AtgtryN/E9WrEhpzFyRtY1jo/duj3DewR3UNAFYMx+vJCq7CFAEErgewy1V2IoiLpB
AIhGL8ErqNU2XUFxVMYxL2AdcRLA2aOzwTiRugVOTiIH04EDsoSY99Fvo3pSxIJMzpFj6BI5eKev
MVQBz3XDfzxDd06kIBVhy9/97u7LbXK0Lm/uvrr7n/96fPvr3de//vRw99XTx1++e/rj+4cf7z7/
O/Dif5e7L7+HLL75+9//+7+pZuo1/7JXLW2Trzf7ddEI1d2vmo2qyawK4+HnhQB4KIPKNGbZ2tQG
eabMrg04xxxJ5TxzJrUMarqJ1HCr+aTUQGycKlxvNNPYOZzRzaS2Qc08kVpvN9M4tjn/nyjs19vM
5IxoctNo8m5QcxJNbhxNXMmYSfU3SjVCwk0xy4cbpVqYZYfEwQHdJF3JAStvseLqyoZZB5Ts+NTz
vidiD/Aecb11A5HOFimYrAZM5g7aXz/86+nbx3/tMxoDSOn1v3r/7u3Dbu0s9C5C7+JVSr0SVSaV
RaXq1bEFuBAi8T/df/hEOiscHPz5su5U+tO773/5+HD3h/dP/+H/c9mFIYlNA7FnHOI+B/9qDuF6
Do9P333z4eGf33z7/peHb95+fPzp5x/u3z7+c59v3Ofre0p8uevNJU/UMQKJ65UnV17KLZZcTEFe
I7cacju0/9nt1W2vEBvWsdgQpl3gOqh5BJp9vAvRkDofGQ5CPkz6sVAMqfOx2CBNQrWlRsPC0U2l
DlJrKtUbbbV7lCBYj85gYfYk8mHXcsDC7BkUfF3ZCYvdfHQD9IjXTz0ua04CLBoBFq8f7F/WnLg6
GQGWrh/sX9acDFlSMKReP2J/qVQjGqI5uZMpunIzB+/7V5mRjMyI0WahzIi3Z0a8PSMGPUVeZ/7y
A6BPzfZXNiyVp92LHwB9nnQv2XBxTlOpA6CfSjVGDscx7HzqcFmzTKS2sdQy9+sAI2dSi+VXu284
mKIrNwurfRbqGw7VurYDVjYqHEK/Kz1gUUwWyfDAJJXTNSiwm8p+0EWV+Rx10M2USedWDCOX+drD
oJspk86tGlFSbLQuVmbYKF2E0sXwTwk2i2tQelDVgK/rBvXq6qLyJGrintSsQ0Bvu/+HctyXzyfP
PA6ycfFaJvDi6iXdS7pXtnpJ96oXDCw5Lh8MJ8+H3Hw2eT5Wun7yXAZir588384hXM/hpsnzJd/u
0cnkeaSOFXj1POUuGLTVknuaPN8itzlDbu+O7MnzTWKDIXY+y1gHNSdA/GyD47LufJYxCPlmAzFP
1Iykliu2FPbTpEy2FMo6tnC5Yl9gP7XmUpMhde7X/cSbS7X8ao5i5IBukq7kLLz2o6uJxTilyjod
zR5n0C+L7bKOAaS4+WLJPnYVt9pSnTekzqOsDGqGiVQjyk4a71eNRtV5gO5D7dxM4wAtbg48+0hb
3AR4vAE8fr77tA+yxU+S0RvA4+e7T/sgO5dqhISfj+wHIDuVavnVBh6N9WSSruRAjevnwC8NEQM1
whQ1/ACvwyQdgoUattmCAa7zVXe/D65TMwUDNear7n4ArpNV9xKM6ArzkBiA61Sq1ZFMnHOYJZVn
i9cvxGd1opoSKfR7SHUf91bsi4jzxZsbcTwa0Rfn0TfA8Wgvj5VoRN9p3XUkNQxwfCrVAKSJEzV7
LnHspMlgSkOWPhTofXOPwO7j3oqBCHupomlO38RyVenG3eaVkxsjNueLAlWLAFWT/6rJv84Y8MT/
odRqYNM6XFO9ZkVLX48bLgocBiPniwKnStcvCrSB2OsXBW7nEK7ncNOiwAXf447NZFFgpI4RSOXZ
ns2l3GzJPS0K3CS3GHJ7BNuLAjeJbWOxeT5RXgc1J2O4HAypU3R1g5DPcSI1G1Lnk8RBmkw2H0o2
LDzf8nCD1JpJfbblcSl17tdB4k2lGn4t86lpulGqkbLZ7I/k9u6Ibpqu7KAh8ynrAIBmAVoMDJhv
Whxn9pc1JwPtZ5sWF3XrPFQGoFcnEFCtULGHvM9Oz73M3zoCV6qRHtnc7xA+9ajs4dCVHrC0x25Z
UZeNqLsKzbPRrOkoqEQlQ1IyJI0HdRahJI0Lk6bP2qBR99RbOZDe/TIaBR0A6/ko6Fjp6lHQgYvN
wR4FvYJDuJ7DLaOgS77N3HI9joKG6liB1M5S7BO5wZJ7HAXdJjcacs1zlO01UvNY6jxtNFkomiQU
TRKKPrIomizIX91+vT2Dts4mDdrPfZYu7cWThgMXm8MkXW7nEK7ncFO6POdb1+smDUN1jACq51sw
n8i9btJwm9xiyL1q0nCb2DYU+4LIdafQrc7EMjcLV0vZ8+2SVyjrz5Q1I8nN4tpUdhxIL1E2nilr
ngLvQ+7blK2/ibL5pKw3d937APcmZb37TZStZ8qa/aB7TYL5+Fso688SzJso5F+TYH4MQi9R9izB
jl8Q7Cv7mgQ7/4Lgmp5n0PkN+pjjQXPzFNxtioeh4jWYgORf07MFo2cLdky9JlvDbxNTZ9ka7Jh6
TbbGa2Jqqmw4y9ZoxlF4TbbGcRy9RNmzbI3muDy8JlvP90MuGcwH5tpk4CUdh9Kp9CqDyqgyq1Q9
p3raF6naF1H/v12ucSiLysOAX73YdoHGoVQ9HSkUFm+XZBxK1QuSowORSuueZ9uFF4dS70e9H/W+
Dk7WaOTsdDeifPp9X335bkRJA7HXTyxu5xCu53DTxOKC73E3Yn+gfZpZjPSxMuB8O+ITwflaX5az
SiYO1uO84FLW8STvZ7v1ztd+Lutme3C/nsb3LxXqDaH26MyfxukvFRqv8MjXb/a9qczNytzzfZBP
GmD2rm4QjMfdk5H2xZBonrU9ThVeKrGNJRZ7vD9InJnE872Pl3ooC2u1MVCLEdfFDrEyqOUn2hvx
Vcyuti/Fv1hiNiTa08cBWkwl1ts9pK/cZYuu4T6vasZXP233ifbN1r4a8VXtGcAA6KYSDZyo9uB/
0J1Oag2wcaqnfFKNiJr5t2r0pDMZ0nTQChOx/AAja5m0wkAs+7sAP8DImcRmRFSzI2qAkZNaA2ya
6qnca6/oA7U8Lkt2TQetsGeYA7xrk/6hGYjR7Iga4N1U4jiieAWVITEMMGoisa2v6AN1SEu26BoO
tDf7wLCPd221+4e2juOrrfZ0cx/v5hLHiNVWsw8M+1g5l3h7Hyird1t0Dff1cHZ87WNkW22kb24c
X83Zqxf7GDmXOO4Dm70iH/Yxci7xmrnXwENaO5AtuoYD7e342sfqdvxyYqT9OL6aMyeBYR9XpxK9
gRPenAOGfVydSzT6jqmHijxzmJM1b0S0N+Mr7mN0O24QjLQfx1ez1+vjAFenEg2c8GbPFwe4OpVo
jKVmHtJnGrJF13C2mHL/7fvd5cCq74g1we/TyD5Z6YPbPgjqXWwH8g4XPSh70/fNEkzQjbyn8vZF
oRaMULW3IGJa4iuWo1oYt3m+IFt1wKjqgFHVAaOqA0ZVB4y0otYDpFuzt21H+pmwrz8+PLx5fHy6
e/P4/uGv9z8tmrN8ef/x4cP266JZ4baFeWB88KyXp730ClqmiQrAqIXX1C+F0MF4nVDvZ7T6oZO+
xt1NS72PSnwBI3/+8Otpq/ZP0PnD49PD3Rf888cPb0//dId89fDd092fH+7fPnw80KzT6b98eP/u
w8NXP9zTEnzwhw/gcP/07vGD/v/49O7/7kFs//3t8eM/vn18/MfdZ4/f/fIjlNqe/PzDw8MTtXy6
++v9dx8fz/7/7x/w9+z/z97dv3/8/uzBwe2ndw9y8Nr3H+9/1Jqr2vrFLz/+/PeFVzhv9nHbPa+b
5bd7Xjfbb/e8blbf7nnd7L7d87pZfLvndbPxds/rZuXtntfNnds9rxvndbvodSPddtPrRvrtqteN
DNtdr5t3qBy3MxV7Aglhg6BBSPCs8M8KYZYiV32MgIv83bpKNa+yqxpVJpVS9jC245Xsaofqa1fC
aYThtCvhBE9O/ZtT/+ZkHKddCaddCaddCee7cVRPpnZKPqfdCafdCaevgpx2KVwQn6D62q1w+mrE
yWFOH6o47Va4qHpKHieQcAIJp2R0AgkncHACByc4d7obxSlpnQ5Vuqz3BfdO5zadblF0Ch+n2xSd
ugOnWxSdznc63aLo1E04rVM4Jb9T4Dglv1MEOcWOU/A4hY1TwDjNqZ26G6eYcT1Cj+DkzstDMHkF
j1fQeAWNV9B4bWV5Bc2p9BdlVKn39SmYV5B4BYlXcHhtWXkFg1cQeG1VeTnfy+lezva6UMrLyb7f
BrY1JnX41ctJQuVprw7caxX9WMrjp1JKy9NeHvZaOfRaOfTyqJcnvUDDy3NeHvPymJenvDzlNT8O
yuigjA5yRpATgjI3yPhB+4hBmRqUoUFGDzJ6UEYGGT3I6EEZGWT8oEwMckJQJgZlYlC3FeSMoP3C
oEwMck6Qc4KcE4ScoXeHAuQgvwT5IygDg/wR8plTg9IwKA2D0jBooT3ISSG356XS8VRKuJwW5LSg
tAtyWpDTgpwWlGZBTgtKr6C0inJalNOinBblrKgMicqQ6Prvqi84jX0wz0ZHeSzKY1Eei8LQKM9F
eexU5ovyrOOIAtIo90W5L8p9UUAaBaSnsj0v5c7Y+1elV5Qbo4A0Ko2iPBblqah0OpXSR4AZS7ko
JVdAGQWQp1Ly5bmoc7KnUnrIg7HVZ2VS+p1KXYcrj57KolKjOKVhUhomeTQpDZOmH0lpmNQhJjkx
Ke2S0i0p3ZL8lOSnJP8kpVdSeiX5IQnukvyQ5IckP6Q++pEfUt/CY1Bcfxdwvijr81LplOSUpF4r
KY2S0ihpfKN76/vd7f029X5Jeb82vN/G3e/H7jdWn+6QZiOuv5MpX5T1eak004Wt/QrVfqlpv2b0
7KYp/a6hhm6J7Pc2nm6gUseim/r63Xn9Nrt+v9zZDVX9c9EzILz+G9P2vFQanEopKQ/oqpt++Uy/
DqZf0NIvKenXhvSLPPr9GP3Gin6HRL/Vod+z0K8r6BcI9O/y+5fy/dv1/p12/3L69C0zG3/9pyXp
oiwXpYQpJ/RJX//Irn/21j9E65+G9S+r+rdOp6+PNuWuPsDvL8p4UZ63+OrDR+miLBelViWOh5FU
/3gYSfWOh5H64aV+GElyj4eRNLc+HkaSnH4YSTl0OowkOUI5ncw7HUZSbp0OI+n942GkM6NcvwCQ
LkoJFSSeSn9Rxouy15MxFB7aY+87330/uu/s9v3Wy/3MvjPY9+su98P6zlLf7+m7MH0/o+8y9LX/
vore17b7inNfu+0rqn2ds68Y9nW8vrrWF4TOynBe0vj/D0bVnZoNCmVuZHN0cmVhbQ0KZW5kb2Jq
DQo5MzQgMCBvYmoNClsgMzQyIDAgMCAwIDAgMCAwIDAgNTQzIDU0MyAwIDAgMzYxIDQ4MCAwIDY4
OSA3MTEgNzExIDcxMSA3MTEgNzExIDcxMSA3MTEgNzExIDcxMSA3MTEgMCA0MDIgMCAwIDAgMCAw
IDc3NiA3NjIgNzI0IDgzMCA2ODMgNjUwIDgxMSA4MzcgNTQ2IDU1NSAwIDYzNyA5NDggODQ3IDAg
NzMzIDAgNzgyIDcxMCA2ODIgODEyIDc2NCAxMTI4IDc2NCAwIDAgMCAwIDAgMCAwIDAgNjY4IDY5
OSA1ODggNjk5IDY2NCA0MjIgNjk5IDcxMiAzNDIgMCA2NzEgMzQyIDEwNTggNzEyIDY4NyA2OTkg
Njk5IDQ5NyA1OTMgNDU2IDcxMiA2NTAgOTc5IDY2OSA2NTFdIA0KZW5kb2JqDQo5MzUgMCBvYmoN
Cjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMjA0NzUvTGVuZ3RoMSA1NTQ5Mj4+DQpzdHJl
YW0NCnic7H0JeFTV3ff/3Dt3mf3OPpPJzJ3JTBKSSZjsO2RICBACEkiABAhJSJBFkCgosgYVRQLW
AmpRaKt9XbHVibgEixi7aKu1itZ9qftWUOveQma+/7mTBK18X5+vvj6+j+/8kvO755x7lnuW3/n/
78CTAQIANiQVNE5sqp8srF3YDHD/NAD3BZMn1k2CDPbXAIc7sJR3cuOMJqHUUIXpLZgum9w0u+bN
4LsZmB7A9JXTmpumdL2d9RSABsuz981oChesfunCFgDyHN7vmDNxesuav29cCWBIBeBe7VrZ2fP6
fb3nA6yciGV+0XX+Gt8c/5m5AGvvwvTHZ/YsWbm+7oMgwNnvYvkHlnSu7gEHqLG/RmxPWrJi3Zlv
VjdvBlh3C8DYFUu7V14Q3PXnCQCWkwCtU5Yu7ux+UXrvZ9jWAixfshQzTI2aeZi+EtPBpSvXXLDo
GfkgAFMGII5Zsaqr8271gR6AW6wAwtkrOy/o4YN8DZan4/Od3bly8bQPznkd4I6tALpf9qxavSZ+
AeB4D+fR+z3nLu55ZcPLRwHW4POwaqBzy3Hyxj0/ym43Vn0GbhEofrWi6Ut6/f3Yuq4T1w7t0d8i
7sGyamAgAawnamOzcJ7K8P45+luUlr6KhTSHvQcmAKukGZAgArMxwnEPJHJUO5jDwIHIXcsVYpPp
iSt7HTzFciIwWlHFcioVo7oe+HgEfPPpjNKK05t8PsAfdjPvjbXCI6KW3O4D8nN6T9XFHaUjBSIO
PxL2oQS2DB5VHYSb4TRQtcKDGG4aSTNvQoB9Fs6mcW4rbOCi0MNFiQavhzDsxNCM4QYMl2LYj6EL
w1JaHvuZfro++BJw8k44wj0CS/gb8LoWQxEc4Tdh+iAcUS2EDapzIFvp0wVHhKvw3kNwREm/nLji
Sh/h7oCV3BrI4nvhVj4VnGoBauj1dH1+FVwLzOH2wgHV3dCC13lcI7SwnRBS4gfhAM7RdUq5hUr8
gLgWDtB8brNS/gAtx/4T6z8A7eyNWO8gXI/r5RWegVxuHqRwxeD9d8+QRBJJJJFEEv9zwN5DiNWa
naUknGhIiQHIKSRMMmhJplE2jM0yESD5JjCAwZpmSA+mj7Si4yVep+WzrJBpzclS87yOaLJkSWf4
fgaVRBL/G0ASUgUdfCnGQQQxHsP3FA2yRmEtaJF1oEPWgz4+RJWLbAQjsqSwCUzIZjDHT4IFLMhW
sCHbFLaDHdkBjvgJ9LKdyC5IQU4BN7Jb4VRIjf8TPOBB9oIXWQYfsk9hP/jj/4A0SEMOQAA5COnI
6ZCBnIH8JWRCJvIYGIOcBVnI2RBCDiF/ATmQg5wLuchjYSxyGPKQ8yA//jnkK1wABciFUIhcBEXI
xVAS/wxKFC6FUuQyKEMuh3LkCqiMfwqVUIVcBeOQxyk8HsYjV0N1/BN8Y5uAPEHhGqhBroVa5Ikw
Mf4x1MEk5EkwGXmywlNgCnI91Mf/DlNhKnIDTEOeBtORpyt8BpwR/whmwAzkRpiJPBNmIc9C/hCa
oAm5GZqRZ8Ns5DkwF3kutMQ/gBaFW6EVeR7MQ54PC5AXQFv8GLQpvBAWIrdDO3IHdCB3wqL432CR
wl3QhdwN3ciLYTHymbAk/j4sgaXISxVeBsuQl8Ny5LPgrPh7sAJWIq9U+Gw4G3kVrELugZ74u3AO
nIt8rsKrYTXyGliDfB6cF38HzofzkdfCBcgXKLwO1iGvh/Xxt2EDbEDeCJuQNym8GTYj90Jv/C3Y
AluQL4SLkC+Ci5EvVngrbI2/CZfAJciXwqXI2+Ay5MsU3g7b429AH/Qh74AdyDvhcuTL4UfIP0J+
Ha6AK5B/DD9G3gW7kHfDHuQ9yK/BlXAl8lVwFfLVcDXyT2Av8l64Jv4qXKPwtbAPeZ/C+2E/8k/h
Z/G/ws8U/jlch3ydwtfD9ci/gP+KvwL/BTcg36DwjXAT8k0K3ww3x1+GW+BW5FsVPgC3Id+m8C/h
l/GX4FdwO/LtcAfyHRBFjircD/3xF+FOuBP5INyFfBfcjXw33IN8D/ILcC/cizwAh5APwX3I98Gv
kX+N/DwchsPI98P9yEfgAeQHYBB5EB6MPwcPKvwb+A3yb+F3yL+D3yP/HvlZeAgeQn4YHkb+A/wB
+Y/wCPIj8Gj8GXgU/oT8J4Ufg8eQ/wyPIz8OT8SfhicUPgpHkZ+EJ5GfgqeQ/wJPxzEo/Aw8i/ys
ws/Bc8jPwwvxp+AFeBH5RXgJ+SWFX4aXkV+BV+JPwl/hVeRXFX4NXkd+XeE34I34UXgT3kJ+C95G
fhveQX5H4Xfh3fgT8B68h/w+/A35bwofg2PIx+F4/HH4AD5A/hA+Qv4I/o78d/gY+WPkP8Mn8Any
p/Ap8mfwOfLn8AXyF8iPwZfwJfI/4B/I/4QTyCfgZPxPcBKGkIcghhxTOA5xZKCfa7ADaq0aWFbF
KSc+hxdWBfwpgEq5IQq8wPOCgAV4UQD8oSmtMGIqeJ5TflngWTWtp+IwhbHvxXAlkcQPHRqdhuo2
ITCqW5SwcArDulWLgloQRBGFyKtF6sMJvCjqxJFWBIGKWhBYEFgtrcfxmMIq38+gkkjiBw6tTgsq
lSohMGofUcLiKYzqVqS/1IAKGjXVLc04pVtRRFFzoqgCUaWj9XgBUxpRPH2nSSSRxLeCzqBD3XIJ
3VL7SHWrHgUkHGiMoQg1Gl4AUasBNWaIGrVBPdLK6XWrS+o2iSS+E+gNetQtf0q3KGH1N3SrQaB0
tVS3uhHdagyakVYwqVZzajXVrYHW40Verdap1afvNIkkkvhWMEgGfK3lE4aR2kfUreYUIPHiq0Vo
1FotFlDrtaABrUaj1UrakVbQGmvUvEajArXKQOsJIk/tcVK3SSTxXcAoGaluEwIb0a12FMO61Wm1
Oo1GRx1fDTrWWszQ6L6iW42GOtFUtxqVpOhWLVB7rDl9p0kkkcS3gmSWTumW2kc0vdpv6lan02s1
er2oBo1RDzrQa3V6nVk30opWi8ZY0GoV3dJ6olrQaiRtUrdJJPFdwGQxAc8LCYEN61Z3CpB48dXr
dQad1kAdXy061qhbnc6gt+hHWkFrrNMKOh0PWt5M64kaUac1abWn7zSJJJL4VjBbzVS3CYFRv1ZQ
g04/imHdGgx6o05nNGIBrckIejDodUaDdfQ/vqI11utEvZ4HHW/RY321VqT2WHf6TpNIIolvBYvN
AoIgfk23esMoIPGBldFgkFCpkgbfbNGxNmCG3mi0GUda0aNu9aLeIIBesBr0VLdqgw4V/P0MKokk
fuCwOqxUtwmBUb8WXWbDN3QrGQ0mg16ijq8eHWsjSChko+OUbg3oNosGRbc2Wk+jUxv0Vr3+9J0m
kUQS3wo2p+3ruhVRt8ZRjOhWMpoMBpNZi2+26FgbFSFLTmmkFYMR3Wa10SiAQbAbsb5GpzEaUMHf
y5iSSOKHDrvLDqKoThhG+j6KLrNRGgUkPmg2mSSz0WCmL6wGdKwlMElGs8llGmnFaES3WW2URDCK
Dgn1rtVrJAMq+PsZVBJJ/MDhSHFQ3SYERv1a1K30Dd2azSaLZLRYsIDRbgETmCXJYk4xj7RilNBt
1kiKbp20ntagoX608fSdJpFEEt8KTrcTdas5pVu1Dq3rKCDxD0QWs8mKSqUvrEZ8ITaDxYS6dY/q
VjKh26wxmUSQRJdJMpl0Bi31o6XvZUxJJPFDh9vrBrVaKykJah81erCcAiQ+aLbZrHaz2U4NqAkN
tBVsFrPd5rWNtGK2oIy1FosazGoPraeXdNQem0/bZxJJJPHt4PF7QKPRJd5UqX1E02u1jQISH1g5
7Dan1eKkBtTsdoENHDar0+63j7RisZqsFp3VpgGLRrZZrVaDSW+zpKLuk0giif9++II+0Gr1CYGh
Xww6I9gdo4DEB1Yup8Ntt6W4TWawooF2gMthT3EGR/8SqM1usdsMdocWbNo0h91ulyxGh0222U7f
aRJJJPGt4E/3n9It9Wt1Eji+odsUl9PtsLlTsYBNpn+5N8XhcLvSXSOt2B0Wh93gcGrBrg04sZ5k
NTptPntSt0kk8V0gPTsd9HpjwuO1WgH0Zkg5BUh8IuxJdcsup1e22sAZkMENnhSXNzU7daQVV4o9
xSWlpOjBpc9McaWkmO0mtMeuf/unuZNIIon/ANnhbDAYTAnLifYVjFbweEcBiRdfv88b8LjTAljA
PSYIMvi9njRf2DfSSqrH5Uk1e7wGSDXkeD0ej81l8bqzUt3fy5iSSOKHjrFFY0GSLAmBuVC+Jjv4
/KOAhAMdDPgzZG96pisFPDmZkAZBv5weKAqMtCL73D7Z4vNLIEv5fp/P53Db/N5cOfk1FEkk8V2g
oKwATCarR0m4Ub5mJ6QFRwFW5UZmRjA7zZ+V7U4FHxrodMgMpmVllGWMtOIPeAJ+WyBogjRTcTAt
EHB5HUF/Puo+iSSS+E7ADH8dlhVYGiMpGHgY/douwjAw+u1eI6Df4DX8R5e1Ovr/pcBssdrsDqcr
BbWdMLPB9IzMMVnZoZxcCOflQyEUl5SWlVdUjrQxsW7S5Cn1UxumwRkzGmfOamqePWduS+u8+Qv+
uwfI/mfVVHAZshckbMCAPkYW5EI5VMJUOAMaoQWWwTq4Dn7Fbo7HgX6v2BjIgTDenwDT8P4s6ISz
Ru7H3zjtT1e86+R13/h+tG8gUtFcVlpSXFRYkJ8XHpubE8rOGpOZkR4MpPl9steT6k5xOR12m9Vi
NklGg16n1ahFgedULEMgh0SdtS39LiHkRvepNXc4nfL1dJRNlz72R8H8tULuf6mU+i9pz7+kvaPp
M6JgjU4K1E6kDffDpLejYIkSaxRoL8QyHXsarlTXvTxQtyzqqu3u6MAaEwOSLzrpo/Dwoyht92s1
tYHaxZrcHOjXaDGqxRiW7eknk8YTJcJMqqvoZ0DU5+ZEzaEok15Hw/JoZEcHRgITsSW8Yzl1ZyA+
uPOrtwCrjcQsiRiJ8rVRQenXtywa6YzCDl9/zmDfzgEJFnWEdN2B7s4FOHOd+Iz9wKbXLW2m81hH
Q8dSX1SFjSvkxhxf3VJfX4BOR93SDuTARKx12nzMVte2bPMPuqNmvNZFTaHoZCwxef2bbravzrnM
R5N9fdt80etmtnz1rp9ya2urEx+4ry6ADWJjdctrcCjOcG5OYkzDE9DdsZz2ubyTPmfdcl/fjsXK
s+5UnkEpWrcUF6bz35Xq66vrDtR1d3bXJFqvjUaalQs0z2tRBohTN7F1OGu4AN5RKXc6Jrb6E5Pd
MKullj5YoHOiO7HsozkdwzmYUTdy00efoB4biPq6fFGY1RLAomWUFpdBX1eZsnn8rQRrNZ6qFeXS
pYCv7zOIko7A8WNfz+kczuHTpc+ARicFJnX09U0K+Cb1dfR1DsS3LAr4pEBff0NDX09dB/ba2IK1
BuL37XBHJ+1sjUodS0kFzj3dAZNmtVS7/abWkWTjSBJwS+HG0irDwVnA3/rhC84yNLf4fThRs1ta
3ThPLTTejPHElW4k3LhluMbD00bnaHHZ6PTUDkf9fro7dwxEYBEmoltmtiTSPljkvhMi4RCuRwe9
Mzhyxzab3tkycme0ekcAe7lLOaJsUTFj9Nco2S11SyuixP7/uL04cT9qqW1h3UxrIsa4WRrThFDp
VVFHCONjQn24CE8EolIoyrUMuqtafZIJTwC6ek2BhpnzWnx1faO7IJEzPFK6D3CrBzqX9g1LiW56
PApq+gPkspn9EXJZ07yWQxKez5c1t9zJEKa2o6a1P4j3Wg758GhVcpnRXJry0RQ00A14JyMqt9yH
IgBblLsqJUNJdw0QUPLEkTwCXQNMIk9S8hC5EFE3v/tOUH7nbZOMyxfpfkYnlUSeJ8/uNsmPYfgT
hkcxPILhjxgexHDrvqC8H8O1+3zyNfvGyPt2u+W/77XJN+91yT/Zmy1fvTddvgrjkb1kLxY3fkyu
3O2S9+wOybt2+2XYTWhHC3ZrpRLjYflw+DAb/jWBQ9IhxojPfDfxfdn7JSN94fsi8gXb+xmRPvV9
yvg+aPyACR+rPjbjGJv3dM/TzME7x8h3HjTJ4YPVBzuiPdGev3BvvRmU38AQfpN2cPA3OBDaUfwu
jDzZO1Y+iuGJXp/8eK9JHsTwAIYrjsSPMMb7Sfx+0n+HSe65g0i3+G5hdmzPk/u2h+XtvYXyZVud
8jYMl26tly/ZapIv3lohb8VmVh247kD0wEcHVJHribTAtyCygP0EW7yo1ylf2DtV3oLXzdjjJgyN
vR29Pb2sZPTLdlu2LPB+2eXMllWsX7aYs+WcXGN2yDAmy5iRaQimG9MCBp/f6JUN7lSPHn0WPbou
evRg9EbJpNPpDTq1RqvjBVGHTo4OPSCdZNxiZCL8Fp6JsFtYxgjVMAN6QWVEi18NEc8qTDwAj0Mc
RHelKBsrRJktF2UoE+XGQhI1N0BDc03UQvDaVBMtDDUMiDArWhBqiKob57f0E/KjVsyNMpfh8jRH
VZfhLmrG83/e/JYB4qK3L1HMAcYGyJZLLr/cPRprbQ15ot0NTS3RHk9rtIBGfuxphRBi9ZrVq1eH
/i/oV9Peu2fV9L+nosaiM/peYGL/++8phiP6fmAiGa761TYwio2OphK/XwGEzlPy13yjO6USHhO8
lf5XXu4oyCP8NZerC5TPcOKvKfzySDzWHf/sP3PivglxOPz/gBxlsr5tv+QKcinZQprJWrKSnEeW
kQjpIq3IF2NqFdyuFLoR3iM+4iIGQkiAmIgAJ0g68RALUYEG08ewzKdKyZ8q/CmpgE8YZbZgB4YH
4C/wJhyHGDHAEfxZgj8H4Hr67UjESzJJOZkCH2Dr9F+mroV+OIRl/oB1XoS34SMiknnkfNJHrmT0
zGRmHpZzklqynZnOnFAFQSBrGTNZwt5HPiU8sZEg3Ad/ghfYaPxdch28yuYyB+EC9H2fIkUkwt7I
ZrMyc5S5EXtiqIEQ6N/gYvFivZdnVEBD+LGXH1MoP89v8pvSkQiW+ucWDk7QK2yhrxgMPIq0EncL
rZ0RsbMswwh/5uBl1ZPsyzO4do7hZqhJW7jtzaE3ITxUEK7OzyOsnyXYHrNybOy+sWRfbAW5kjt6
4iVV8J9hImKbN7MPq3S8VWmzJBLgBWyUJfC4ke1ge1iE6nEQJGGV0CuohLA6omawg+OFGKC6MGwu
L6d9BJQfla7q9ap+DLx16CAznQb6hvRgrJs9iD3YoCqSM4M0MA38DKGdtAuryCpmFY8tk16ml+8V
DAIQt2ikZtQ4qLrbLn1K+ymEajqONuLPYEySudRvMxCBZ2xWs8NLHOzB2LbBQ4cGybqZe6qrGurH
V/2kMdb9GnmJuPHnpdc89Yc2ro29csNtsfc3nv/gZPo8N+Hz7B15nol4kEUsE62NbKOlg+lgOywd
1h6mh+2x9FgNZlC5MRCVSjsI9zikz7/2PBIj+IvHk9ISc3ERkzmWZBb77WZ276HB2LbGvZXj6xuq
qvfMJOsGDzFVsbdiwdc8kwfXbiT2224gaWs3Hqr3vBYL4tMEYj9ilpPtOP/5kaCRGBknyERGmYVJ
mCmHalLNaJkX2edVuDuZXjTRdOZxZugjqEnAwiyP7f3r78n2IY45QUd3NsOzy9gMbC81IpFnGQk6
6FsrE+ZmcLh0OAAI08q4J9hltBLDEx/W2xA7rHpY2QclESO+AJPfMqwVtwKtOxB/N2JQS6XgpET3
MT5FYRgPsupwft42bmxo26bfqYmfqB4++U7sMdbOW7+8RWjBfnvir3ER7kNw4HlWF8mvY+o0Uw1T
7WuYNZoNhg120b2vwjzVzJgF/75ivo5neJdzu/JWne7dDjqiw8GaEnut7Tj+5ue1ESsjGEggLSMz
gykuMpeOJ4UFdofdzEkZgTTeJNkLC0q4yMQpU989cPOx+qk1E6dOPXbDbe9Ora+JbVq+YcPyFevW
rWDeOxx7tr2zq3vRIhI4/Bvi7Vq0aHH3othrh4nhrbdiH8W+eP99fAqCJ7TqGPc0GKE4InO39vKE
53W8gd1PjLcYdIY+lmNuAbaaXYUyCbd9WiAdL5cU5VXTZ87PyyKoZn9xQQk+ZSnGVMdOeklF7KEp
W3OKilSkgRQSFWv5xGRzNVadCNNxH0JrMJX7ADywI5Jn2KiXShmT1eTXp5uK9EWmyaY5pkW2NTYN
MEaj9hqLwKReSzqgI7UHelJVqdQFsSsrlMqI27fYid2+U5akkeWSPseHMpfjurUpz4ibuba5JeI2
MlqnzLidYSbkrHROdc7n5jvP4s5y9jr0ba10xkNZpLgkiGMoLqJzLARMJcFCn8pm5XElBD839cSq
S4l+5rozL96w4NG5vsnEtgMPzIzLd80fyGR++nnnCzPOu332maumVZIGefzfnr08tq358lQ62p24
OwLcRxCBqyM9ymjDlLRatsCtNReEtGOltLGBggpthbFobFFB0bh67aSCunEzSat2pmtWVTdZru12
dZadT9Zr15S5x4/z7u9A7eTl5Vwjq4sEvd50jdqV0VcxQ26XGTnfsT1frhin0rFsTWJr4c4yO8qP
h8NtYdxgOB3V5nJknCV6quG4Q2grEqMMpAUzTYVe3GsliXlAvYeI6avJ0ZnB7ZioZvMS1UB+RdOc
5jd+cSj2RVPmnA+7Ki4Lp+dU5ef3Vc6afcYF2Tk5YwOZyzMWvrQkfRZJ2XX5X+pmNV67ufBc5r7s
nrZl90yorq0IkslF0yw+1+TaCZONEks0GrOlelxuqWTWTRhHav3j8rPydy7c+Fu3QchGxTXHT6Il
OIrehR7OjUzPEgivt+vDwlRhkr5VaNavEM7UrxfO02t1jfoOfY+e1fO8wKuJfh+1IL0cy3GswLMz
NO0aRiOodaodGkKMMh9GcSpTVoizU0BPEZwtZaoK8DTZJr3cphokbW0kQLe8CY+XQmSu/dHYrqEw
c4hse3ToodgMMjd2I5lPUtiOk1czKUNv4x64AfdANj5vCHoiZ2iV5RfdYq6Yqy9kK8VKXaFpAlsv
TjBNdbSITdnLxHWi5PWm7MtIuzaDl3mNxnAN7/Kl7ZAjWlOpbN3ukzVWPEFy0UvQKI+LOx6XOHQ8
PLrC1DIqy0sSS4sn978ubWItcSC2xPHiJVz23KYFH15z8Iszsuc/ubR6TygtEE4v2Tt+3o3jc1SB
oUlye3DDg5Pmn0m+XPPw5Gn1pDSN1JdM8WTIkdqiBoffJhvZKbE3PmHYcHbp3dSWX4rjnsIdh3QY
B8sjDXnqQk1eWURdq5lQ1pja7G0MzA52exflr9asMayRVrvPTV1davbw4f0+uz1ln483C5X7eZen
2G7XZeF4JXrGVxd/7czE5TGjATmOY8YR04lQjk/+a8dnYr+aAokxj4yWfHUirLzNSjPpwTqledrM
p6+49OUZ8zvmnbmIlD9Xf3tKhvvCWYPP2Kff1jX3qkhTd6xcTs9ODy4qyukYw+RnpU7L8TeSE6sf
qZt6Rn3DHCLd/zuSd17PRisXe1HvP3zL2PIxORW/i+1Ma2usb0tNtVmNmrGBDT/Plj1e3B378TwM
4e7gYXokD90SsgNNEn2/ZK/leIaw0MDMZ5hsppqZwbQzq5gNDM+gQ4WOLVrthMJxk7bhHsD9OlTQ
pmzV49sGCRorXF4uNLQw1swcHmJVV6huPTFXdRfxoAXsir/CTec+gVQYi2fTYGQ2m2XNKnSOy5/g
nJ7fTNo1raZ2d2vOwvzm8ubq5UKXdrFpsa3LfVbBRsMa2xrX+gInz4SL83IiOU057cWLcs7N6S0W
i3UpOSrWt9+CK8e6PH12elzLLnep3Q7Feim83ZUzvI41GdslqaxPVhO14mopy4m72FRejrEQPauq
j+PJ1UaPb7u7oLKgoYAtqCxW4VNW5mzNUmXl+Ezm8jYalAPcqvKn0dUsLiopLaaXoD9xfOMJRRJn
uoEkFtkxnliUlc9UchKi4KbH7oi9cOOx6dPqL77+ovVkChGIlZRvvWz/1bGu8zqDDbIno3Zaamfd
2DHylB7/5lCo7qoLfHPkYA657qGTE6sqfza/51cT+Kp7Luh//bHblt9UwVf+gRkzbZ7ZZCoNVNb4
dQF7yZyhzVOm5hlzpMxVdUs3WKyO8VQlS+Nv4OnwoaKSjkhteVpVsCpralp9sD5rnjTP3G5rT5nn
XlhxVsUaZh23ybh+zMYKs9VXtt+Rs9/B++jfmt7Hu6wZarUnA1VSXbDdo8zmiDaoj0xPhBFtMAKv
oto4dR6UJsRCJw38CUdjVBgjc0ZLFpVw2R2LlsceOjr1l+4x3lUdZ1xdUjlNP/eqVc3XVDd1kenE
sOPZM+YviF0YzvJMy86c7Jczs9MD7WW5yz0sW/Xr2JGz1641CyTd4MvMzt3WXlCcFap8cM+HJBdF
E/t82/qfhnypbr9v6ZRJ7aluu0OnzaLzMx29xyvxbZF675MihUbOyDtVMifzY1RhLsyXqaq5al5L
nmc4/kXheZH/ywxVu2qVqleFgCdm4NtVuA0nIeFSVh9P+Nkmv4U6lnNjfeT8cdS7ZF5A/zIj4WEy
9PsmeS9qUkAbc3tkFs/QL8thyIWYodawqos4ji/ly4QGfqIwn28WVvKLhM38OQI6LSLD7unBgxk0
aqISeG49OlQsRxhWxQuiWqPmNMBxDAzE/xoxa6RSzo8ERh0BnawjHJVzGzqdbbj1Uc30otgfqgL1
dJjObYJNnKqtlbRtk4YGBwcVFgfx9l3V6ulqBtpa/X58HULlaxneG1u9ZOi5JbFNTAa5L3TvvSQ3
9hR39ORKxj70Pn0/O4InzwCO0gZBKIR5kcoGawvTbFvGdNt6dD36cwOixZxzJXglL9PhvcPLeL2C
Z4/I5u4R7JvNOUajkL4JBoq9Ob3C3UXS50MFOL/KpjuO7nc1jbadM+xmJE5knPWvOg7k6y6G5etJ
bmDutJanfjF0PlNz182zZjedu3T3bTFrejh70znBqvlb0ot8C0trcn82pzn1Fzsrq3LJH1YcKKsp
4446s0K72lbcOFb03EMeT59qltjY73mTo37oycnTLXomdjnjcjVRz2wJ6u5s9EML4dJDEIpvPYh2
2TaQuJoG4r+JzFbrSsPjkUSP0xNgM1RZYlgd9gQCrUyraq6mNXVO8Dx2vdoYtlRbVll6LSqLJWWX
TuXLzcvtyO3JVeXmZuwCiyV3oBiKZxS3F7O+Tfy9RThJbdLnBYqpblMIJwjdsFCIQwfsqxbLTo1W
Blox5fTiFRNlV46rkpLSQhP1aXi2/abYO4sXr1q+uJPIBxb+JFK7MisndXZJ6Zb6mbvHV9bPqBp3
df2k7RX5ze4xZWeW1W/xLOrsJGlH+olvSdcKm8kStsZ+4qzx+XIKK8sPX7rzcElpODvoqXHG9rty
JJsdtYC7hB+Hu8SAHntVJLvVPNu9mFmuP59Zp+ftu0XWsVswbtLAeiw6IMtyRG6UWQduCS++S7ZJ
n7YldsOps4fuAtXoITO63vy4I7tWxk7eOfQJk3oPEedd2x9bfdaayg0bOzu3bxm3bBHzzhOxe1tq
irij48oWxh58es/RSo/t5AKXv+qPdDXxKVWf4FNqYXIkRb0rj4/wHXwPv4WP0u94JdwuhtXsIiI1
SEbJViqqRAA9r+4ld+vo1qVOH9qd0Y2Lz+v3m0Z/VJ+ceFRVPFTPXDK0gbmXOxp7NRbH8OORnt/D
ntVQE7Fyu/KYCNPB0I8tyC6RFVgWaJ8mtR7fWbRh7Qwtw3A4OxraKzXeocIwKn2kU3Kqy/eGmpgN
Q5fELlKFVP2xv8VeHdqKvdB9+xr3Bu7bIFx9CIyJ/aodiL8aCeJWDXAhIeQIuFvszalncv+HvS+B
iuLYGq7qZaZ7hlkZ9mVm2AQHmQFEQBQGBRUBFxB3IruMIowwiBgVRKImRk1ciVnckhg1RmMSjVGj
ZnvGaKJZ1KcvMYnZE41RY/IiNN+tngaJ+r73/f85///Od05sqbm1dNW9t27drZvBIZ/JzpPP0c8M
8AhZaQ2tCaVCCTLJEECFhvK0VZWmqlE1qRiVyrCSZ4JW0Z7W0JEwKBTJVCrzfIQi7BHYfx4r85KF
y2jZvnDtzcLLoscZb9URjEUzDSJMKhYxdgVBDodNNiGdFpF9vkOCoa1fIiGPvVQm7H1aaBXy8B7c
ugortlgCq+L6Pz6u4tlBaVlYhpF3grdwltpV0CsXP4mrwKXeljBS2OKVG2CKGZA6YH/jb8IfFIXD
sJ97D9hfxd0fZLfQj9o4O1fEOblmbjcn4zhWIacxq+epJrRXhVQkKKA5uol1b30hKVBafFr8PTae
/VVo7nhXaMbNVCL8PNLhZE93XKTMJJsAKvSSuGayPYRnVsloBb0Kc8pNiiYImjchGtO0ysOosqns
EIMwIo9IAN1xI06MTTvixOg5Xke88FBdPH2pve3GDbryxg3M0UcxJ/zenkbkq3fn9/Q7sI4virMH
TqCw1yofGoz+Spmnj4/Cq6mZpBL8m7piAdEndlv9y3/yhXv4/4Qw+p0hmVnvt03dmxlmqxztmOnr
IxN2UJ/gV0p2pKRlatQ4Rm9Mioutn0SNxnpJyq8CFiwKtRvAmj0KqxYhJ3ngLmfgFMngtOvcmZe0
rqwAc/XW+8C0PezpWyOlkyI7C3N4oFf2IxoEcRCILmMXw+EApUVJI95DoVFq+UCFURlBRzNWhVWZ
okhRjuSzFHOUrfxDytX8OsXjSkM/xQRFE9XEMgoiz4FqfSLb7KFNpEjBUgqatzJpTBHjBBeADPCF
ZkaJGFrO03IlzxJBUCM12JjOI/vgMLAt8ldUQIClkFAhOtLE8opmONZmAXsMYZ/FAlSBT00o47FZ
dlZoEX4SfoOftfh1PBKPwK/TX3c0UovbA0BGvKgfJYo5UTcctGeNpOxyagXVLAcH3puikEwrM8mG
4izZbLkMUX0wllFyDlMMLaPpUJkN23E+LsJO3ABHB1NyOyAqb0Z7lXDYj+wFpiElpiQCqGaGaBQg
wALSbAESCt00EMfBz0KFyVOovvJsCtwVCtwVqkTeRDnlHqLrDEN267LzxtuVckxRLSQYkskXi/mu
CeBooMKZtVFYpBoKGScs71gibMTvUUZcRAvtFDgUO+gCt51glwKtWmQEHeyXr63Q1DO030q5nPdd
CVuim9cfDSdGQlSHHqAOzUaz3Uz5yZv4V0zaG5I6JPZCVIe3xdciru6OUe9wEpYOSZ9wYcvPQjM1
e/mb2ROnCHUZfQbUThlUXdJkCTfTt8oOp4+fKMCGxMamvPpQ2iS9LysM8g0zTUCSZRsvWjYjarTn
eWj9tdHagdpc7WRtgd8o/ypthX+TVqnTLtAYNfHGwcY6I2304lal6UbqmnS0TmeQr/KiNQanETs1
GM0LNAYaNBqziRDF6ZsMQJSk4yE2s14uhC2JlxQ9RC1imNZxBJzRP5MEEhaq6+kpMTgmqVdl5tJZ
k+f2jgwHl9UiTHtRaKFaW1/PH1P62HKGTxrlo5ULNXqTMbu9HxXS8Rl7OjgubsPsZ05lggzO6Pya
rWB/Aj/n4H4U0tlsV4PscM1QsMG8OtH4aueX9iEAKH0DfPvh/gGZeHjA6PhyfhZf7znbpyHWQ0YB
r3T+FiaITgPH0hy+KogxyW1yp5yWy5VgNEyWef66eSZ/cWt5mAqhBOLpfEP2k6QmpMxEoWQrJLFk
LAZLf12CZbgu0zJRV2CZriu33K9zWUAsiUMLdsxCiRIqekcYbIeYofJmeqYxusIW0dKE/SnMA2mp
EJYKR/YLl2f3bsC9loTWhkUn548acyDv4DO4HoevwkZH1ETh1hLblOheSRPn5a0bt2ML/vgfwuX0
OFw+pcJDre+XEDvU0xAaMPD046ewPNkibBtWrNJrBvZKSfPXmQKTjhK9BmEKmy1GC9F2f8w8CucX
TcJN7KQmklfnOS1v55t42m0BxAcXovLvsvVstmAVmgUrG8K8eGsk86KYq94GVv4MzKlDSfZwnZz2
WJlAZ9L1NE17apuadY/oKJ3O0+6JuSYkXyHfAFthdZtmKZEcD/ODBTYhP1hGDHJB7bNnhN3Cfrhe
xC0tKx95ALdQAaC/zuMI7Enva5/yeNvKTfQmWJ3EP4yYk1hoVyLQV4ilaNodtmggYqHFsIVYHo62
kkUtFjFZJm6sMo4dxOaxRayTZcn+kbY+cma8jGIZVtYCd7HMApqie+FIajDOoWrxPEoWgkLoQWgQ
XYfqaFmhO76BHw4OyASSdgeVK2M6vhDyOr7Aq3AlrmRP/2EFw/ID4w0TDgJE3iaWBY+3BxF8aZbj
lSC5MpriNOo5qB7cF7NCkyhSoCYAUhvVdnWRmnan/EDHozRJY+5Hys7PXwK1Cu7i50S90iYowAxI
xExzcS4lRdt9ghLpMWpt4ggqncnicvlBiiHKKdQoZjw3mR+jqKGKGQc3jS9XVCgbuSbeqZilXEq1
Mkv5VsUS5eMQ0z7Or1bcwLdYk4qiGCOlZayUiUmlYplkbiAfp+in9GCIX8cHxyVSJigUXTWe1ETL
xgMOFEEE+s7YB3oFJfK9oWiiMKX0WACccYIIcvImGQtOMM/qcRAbgvuw8XgAC6xnx+IJbAmewcIW
sFopqJRK3PU4F/QWFGQTxH3whMKTe1uoEcYJvwrtUNbgR7/GetyE2atkU+jj7f1gYzoZTH5QD2lS
oo/tTiXFcAGUgWM0FOKAaC5RkUMN5iZT+VwFB1aJ82jE9XQ92yCfw89Rwv4BJUipYGUsJ+cYXs+H
8FQU35+n+GYFrcAQ9Ss5OQJvO0qeLJ8tvyZn5C1AKwexOCOjiYNwEXSSNlFmJo8NSM0HAIbUFMAV
hZJhIBK4nUsDu28VH2Bb04jxJ0q6cObiI0e07nAbYA4ibi0p2CPEPBaazURpu//LGCFDOAwnbDyl
7biFD+B+OA1v6/gd/yB4U1eoS4INn+qIBn06tvNLZh+zEGmQDVXYh2p82Wg/3yw2K3ACOyFwOuvQ
TA+cFV4b5eyjwr8YjRbvXnaVJrFXr9CtFq1qq7e3zYhtrdbX4qxxWBNpjKQiI+Wtfgdi3Y/vRI82
jphR4gdadF3GNEGNeyZ0fMQq+IYkZ9YvLPGORx/gI+ZlbY/ul+zh62PP6FfTO2hsREJtxsZz1eVl
OHJD2+oJx6PNyRgvwPFYJzyOw3+Qeal16Qmh0QaDZ/RD3ql6X5931t//BITBvKxwaJoOazRRh453
MED99s4f2FSZAXyFINBvYZk4M2icpkLTxDb5yQxr1VoeBbTR3pxuITpolPkoW7n9wSJNEDyLZLl9
Wy0ijq2cKFGS1dVLeT6dO4+bKly4cN9yu0bYiivzd8785BthWcXC+KrYXkNiVzxMpYPnticyIklm
6Dg/KE84Kfy4drMxqOOEWvEcSOx42J2ZTAvqhZbYQ210Gp/iFxtgpzOZHC6Hz/HLCMg2TjJON841
qSNM4Fsa4PCRMExNDqgXNGiJs2bTYq3WZ52HNi0Mh4mZUGgMCwtah7y1KEwb1hRGh1mjcFhUURT2
Xyg7EElSAyT/Q56/XiaukGgvLW4PlO1Ob7oz2CSf7U7SdecwE+N1akxdX3V94oQSx32TrjTXvTEm
3ivFElWS/sjjG1ZmzAgL6esdX7A/eEhW1mdrnvwqe+iguEjhpN7m4x2078nNzxm9DNFewslIK+zQ
xM4vmCuwQ57IhFLtkcMVw/1namlTbxXRhiCKeuS7Tq3FwWtZb52BakWvhQQs5A6YgQS38KVdJvtE
UC+MIoIXGkLpbuMOrmQP1JkrQlvh5mknb+YPy3ijuHxBBq4U2iLGhC5fXjs/tro+ZxgegD1WfDoy
O99ixp/dCqF6adUvPvnMmnDAk+xUO7MIeaFAVG3PD6MsinhqgGIwlcvmKgarc7QT2UmKggCHbDpf
ZCjycVGNvEvtMhjwL4GBHn5b9VrEabl8rpSrE//YdZuHN897t6KDwdZgHIhbNQeC3DEieU7f5cR0
nSezO6IiXJcCXijD3YlTpr39GLf/5dozqZFzzi0UXhDacAGOAjVpENbT05yVizj8c+vDeVbhYmw0
tmE/7I0zIchvL5hZW9UAEmiB6LJFFgy6024Pg9irzQsrOfVWnUZF/pKDv8bf6A+WjdN5tGqmQBBP
qUBqLoObKSqxZDGlkJycJj4Gwu4nH0HY7EWOSmhCPEgR2Qa6JcA3N3paNvYWbgpt69df+GxUSxzr
IdfnzOBvtD9K19wwvv++kifSIExgrsB5iAAvssCeNMJ7RJ8R8YXehfEO72nx87g5HvWhc+KVXmG+
lnVmbYQmdq0vRKjrZIE8HxDWywukIyFmYcCBvqCeiJ8f1xWiWslJFt+vKAy/R6A6EJMWdFtuEu+U
m4mjR3/9SP2l/OhBr2eXzTMbA9OfKv6pE40YOuho+aQ1A1W4UGgzTgxbvryxoV/lgqfODUxNDDRg
P39LeIipbIhXQirsccjS49lDRlgi4to7cYdKs2Xl5uYQYrW2g1enhxPgDRoqFHt5eg3QOb0YrFVx
azy1aqTCQJavzbfIl9IqW1X7faRcAlFQXUSZzbq+XdkP0dfrR/juxeqFtWqdITcztjwF5KKy6MWq
vSepPhmLTYBWaPtXoJM+yh718UckRtkIRaD07kqs3cw+5Q4baYgYNZh5ErWyTyKsxRQexRfxTnAy
uzzMtK6n8+SpPKUn6yiEVjyXKd2IdV305cHMSnTMPgYEiFcrjdjI98FWPg0nUWn8CJzNF+IpfDWe
wTfhefwi5TZqk/IwtUd5nPpV6UfeoVkMd2s4I0dxw3nM23Q+ifwSyqaEgBRT9Kud5+wBANMKpUKO
OAROmULDxisHK/OVdUp36B4MylJBKRW0+7mQVYWRmC6hOLqV3e8hBVBAlBiOu2Na0CposfaIhTti
YTssMxnwVSRPEeJUufRsFrN5QqHwdgmhG7fiDUIV/r5BWC4ztE/BV4VAN/2UXuRskF1PfjGiVWKk
6LkSRpKtdPPQzT8Y7L5PfgbOQiS6z57OeNOBXoGRvlu9nw3Y5703gItY46/V+RgpRs2vMWg1GnVw
q3G7D26ldKpW9XZEaSn41zsK9bb1HtXb2bsrLdRBXqy4IckOkCjqF50oPm590uNJrVh69ehkbghr
Ob0+a1BCWSTBs3D71JrttqoTJXsPCWvlet3wwX3G0oHtX1GxeXVhYWaLb/tXTOncrLzSokmV5092
hFOx+bXQbuyWeqDu3lKv+b+Req//mdQDSqLQE53+KRsBOl2JQpHZrvdq47VmcAc04A2EB4ChDBP1
iPsZYVeY49a+uF+/hL73yJizEcIh4R9wHcKZOATCnXQhMzQ0zGSa2Lfv6HBzrxCzaUJy7AQqFlTw
UfDYvLAPThWOdJy3NE4vXRQZFRLYu9eSqZMXR/UKM5NTuV0oY1OBS8Q6ptktGVSGJsOUp8nzLNeU
eYKzH8j7rNVpPTTB62TeygADIB6iDuBbPfab3W4M8Cut240xEFRFzdfFrG5Pxo18akHmsL2VRYuG
ELaBK/Ph98IyZyO4MmF5kcSVWfrV8BGjosKFaLazHnyZE8JPT68GX+Y9NbdV1N1lou4muKbYexFL
nmuaZJpucmrnmOTEius1xIzjgD8ZcklV98DTrLvDjN+ljoW28c853v9VNONTFgwT1W+3HRfKKMXQ
IbdNOSjcj25bclHy6HPMVKRHSfuwh9ODAqtHVIQPhJrMGo1GqeE5hAxWA/aQt/L7PbuSK4BhWofF
/b5D6F2HhT5n8qkIyZ2VQXjXsHu4p01Pe3CcwbdDy5Q+UzGY/MYTRlPA25kDPLKhFrs2zprlO9Ra
jxuVjQH1oXIjcerMEOaxJihSdKA9/SOZIHoUBEPEzTObw7cGaeUEVU+SopOrt9Le5siF/rqFZn+5
mBNRiDmROGcclruDTX2PrIjF7euRtEih6C9Jz7J18d6S9LpFGv6Tp9px7qdCbq77iEOYOcIx4Ze1
N4abA4amJy0fPa1iwJjIB5MeWw2euWL+t+nGUScd4xr6lSU22ZcvwWUvfJIUgiM9+/j7mK0xUeE6
3ksTuW3+5rPxQcJXiZm26MjeXkovbfgG4oV0/kDPZp9GAWi4PVrBBrCURgkRnFKrkm9VKjQBAT5A
q5q8rICCNEGYU2lbFVyNnJAZH08euurcbxOSdLTonpCHXeHuoIM4IuJGkfyE9Ig5np7dv+W+D0+u
Xg1ae7Swi9Koh2YETtIHKzS67e9TqhtwcA/fEGpTxoeGRvkqYN1NnV+wPFMK+irVHqWQ+ctyPCd5
Vnk2yed4yikvltfo1oBoi4LtVlskmPARH02RtL9VfHeEaC3JS40g2fFufHRmlhfayp6te+1dPE1p
8MzNjHH2xZVzc0aeOU1d6PioYGZ4eEiImSb2JBg0pxdgIkNV9rDdLDh0ftRQdjzLkKzHYjHrsYim
6DI8nXLh+ylGjEXNvCaRJgVJsGioOaievI3IWbmRHIVoLYyHcM6dV3fjCWF5z9wIKpSSI6yXMFKo
FPLwPMxgzJTeepIpbW+nGSLdfcBibQPMPNAe+0yekjF+lDcTRUUwyTiNsjEpfLwiC4+k7Ew2P1gx
iSpgJvP5iiqqjKniixXzKCczj69VBFLKRR7YgxDCcIzcIKduwD4vghB6NL6PLcfT2Jm4iZXVc3XK
29kXDcWJZPp1B+BITRwYrdokJl9kXckXd+6FJEULxSBbjLWhJC+AmpWExADyX75NeFpo+foLYR5E
dXOOXMVpXx0itFK/diiB3j9oGfkhNPvDbtiBZiW6bNdYKRM3lprAMdRwd1Znrz0CgEDWU9mfTVCO
wIPpwfIR/AQ8lh7PjpVP4Mcp1UqS82HJ2Y8mGaA70hDZ3e5OjyRENjDk1c5Tdh10yJd0JyE04laT
fJLCveUSL+7MQRDnh9EyFOPe8ntlIiw9MhGWP2ciSAJLDLaUYqImgLhAdmHy1ZtCGT4g5OCnf7qM
nxSy8ShhNxVLxQl78fCOs4RTwWDLfIBTcrTMnsaxw9nx9AS2gmahAahlduD94BQtJm/JPi3fK6fE
LVfSctaXDqctbBI9jb2fqqfnsC6ZkiL0hYI0y4hIU4h1v/CqYZkAiuKt/EhefOpB3rJza27yikMP
qS4UMyxHCEW4sCvbRD2DEa7teESYswfQn4OXUWf+wPhpZhJCyChdWWhOj+sNzItXLM6FazZ5Q5ha
TMfSD8JRbGM+YttkkXCV9Lg+kY+Rf8elcLO53Xx/3sU/x//I/6hQKRYp2hXtygK4jnk0emzx+FLV
X82rV915afSaEs0lCPu3aH/Qlem26j7Wfawfo3fqL3qaPWs9jxkCDRMN33gles31etd7sPc5n35/
XX9df11/XX9df13/Oy7x986G0CO6v8MgDnV9cQQGVyFOginEoKMSTCMr2iXBDHif+yWYBfgdCZYB
/JkEy9G87nl4cBR/kGAVzkG/S7Aa9aYyyLdXMDSspQa/3g0zKIyqFmEW2hXUZglmkD+1UoRl0C6j
Dkowg7yp50VYDu0c9aEEM8iXekOEyW+OeVBXJZhBIdR5ESZ/VqiMapdgjNR0kQTDPMx8CabRfcxE
CYY5mWoJZgFeIsEygF+VYDn6o3seHgUypyRYRbUxP0mwGo2Ru+lVENrl30kwg4Ll50RYCe16TibB
gLP8pgh7ENy4SAkGfDhfEVZDu5YbLsEMMnH9RVgrzhMpwTCPNN6T8JCbJsHAQ85No4HgwzVLMODD
OUXYC9oN3FMSDHvELRdhb3H8GxJMxu8RYT9x/OcSTMa7+RBA9pRnJBj2lLshwkHinn4owWRP3XMa
xfHBEgzjebUIh5E95ZMkmEGBvJvGPuL4MRJMxosyxvXgM9eDz1wP/Lke+Hv0GO/RY7xHD/57SPzf
Zoqz2ZJMuY7S2pq6mgqXaXBNrbOmttjlqKmOMaVXVZnyHFMrXXWmvPK68tpZ5WUxY8try4qri02O
OlO5w1VZXmsqNtWWT3XUucpry8tMrtrisvIZxbXTTTWkp0e14t6rmBzVJpjGVFDtcMH9+a5iV3md
qbi6zAoT1IgLlNbUV7tqHeV1Md0z9O9CY1BNVRmp1JGpEmJscabI7kFR0qA+ZFBusQsmazANLq4F
TCfU1JtmFDea6uvKYXWgpaKm2mUqrjM5y2tnOFwEk5JGEa/Mgpx06K0VK87amrL6UhfBuaHSUVrZ
4174dFSXVtWXESbUmMocdc4qWAAIgbscMKAURpVXu2JMXWvXVFc1miIdUabyGSXkpttTVXcNvidG
4vAyR/VU4Hsd8KWUsLHH6iJDpblSRAQiHbCKq3wG4XmtA1Ytq2morqop7rko4FzsxhQ43s36mnqX
s95lKiuf5SgtJ2Mqy6ucdxBU6XI5+1utDQ0NMTO6WB9TWjPD6mp01kytLXZWNlrJEnVWNBaVo1pU
hopRNfzEIhvqh0xoBLROhfZy5ILWP48xQVs9VgH8/V09FVAvu6t1iDiP695r0UvoQ/Rb9GEoX0Tb
YHQctNtQEkC5yIFK4Y4aVAc/FTCDCQ0GqBY5xbIYWhwAVaMY6ElHVXCZUB60TUWV0Fcn1srhk6w7
S8Qt5i7sHOK4cvh0wV2kzyS214o8IL0usZXcTWgn65ZBbQZ81qLp0FbTfc+9eyv+j2ghGFWLcxFs
TKgAag4RB7J+vrgjLpEqk0hDGVhTNwY1PSgohVo99BKMHOLomHvg0P8ubgyCniqod/XUdWOVADPY
YHfItxzdPVPUHTP16Z4pV8TXjVmDSDXhjJunE0QsTSK3GuGzXtwrN+3ufakQV3eJtJK6U7xvhsiR
Lp6UiPd28SsTOJYD0uC+t7ZHj1PEuAxWKRVndPO5QVyrFMp7r+uuk7GlQE+9uLtuSaiBskzsd0KP
mwL3jrjXckgzlEpzlYslkdU76Sb9VSIUCXdFifI4A+jqWuleWFXfNfP/nEe3Zy8TZ5oqyXudJC+l
3dJ4b9pvS+if8UrpwQFCiZsWl7hel5yT+d20lkFLg0h5jXhq7k2pm8/Ff+JpuSTvd0o94aoLxtWL
dxJsZ4nUlHfPQ0ZWwYj/focqRc454RRY4WoQrxiRo3+W+hjxzhkwxgUUEQqnijQ6YYZGaO2iog7d
qWlv61jHPXVsDrRXAjQLZiAj6u8aMVRcqU48MS6Rurv17vdA63R0E2b5Hnru7B8r3nln6zAoq+CO
inv2jpJorAf5cUtI439L2V1YMUYmlUlhBjP9mCTGzgxkspnku2YY8y8tTDbBDsdC7e4eIsFOoPdu
TuSI594BsPRFcJ316KN/8SUdNHkkjbQId3a6vw1P/ENI3kj6ljz6FZLp7hHjIKRAfcGS4apiVzXc
Cz5yzphhJuSdNzLXhAJhrU5xxR5l931JYJ/ufV9wjztw9ydGVFVNaRVSi6VBnAdLs4HHC5GAu6aV
PiOI34kY+kH6IXop/TAib+z+E/0BXUZsEmscwvQycRaXNJs0X0ApQtJXdqKASbaWgHEyvveiYYt+
U2E5tbElYBg0ZVAYxyptvIy1qGnKn0W2YpnCIsMMbkmkMLMx3zbaFt2jJXBzcHMgGiBeI0GA6kQT
US4evFRy2cw9JmMMHR9cb571yDfhfWK/y3hhZ1712l8yXt3Y4t3b1sLobS3UHxtJ+p3SQGC5dMCA
JbrTqTdLf7pot6m6MSWRns0Za7FFyegCRukZMrjG2VhL/GdTZGmUKTY5OfEOHzgmNtgW6B7sdU/v
ONZsM5J+2tP3dn9eTY3LlF7vqqypdbgabcE+quREW2yszZZog38TfVRxtti4+Fip+h/AqAWH9GQL
ZhHdgjUI2hVUC8ZoG3XoqPOblGsjAiI3rJt9n+2HzduWhU/5XViTs2Wf8ORmU+rc0Zsf37yiKG76
6UFljVeen/XumPPXfnxiUeCKDa0VL709fU5J6JmgAZ9p8Mrv1r51uE/F+vWVEY+d6h992OOV8RFH
h3yrSE1aG70tMvm5n7IWDrrUqjmwvqqg+PmWuZuK+jTkfP/Yy2Up60cFxnJhhg3bvn3U4vvNwLZS
Q9F4tnxDUGLe4t+2/ryaeifgo8MFmS892Hy4/09jVo94oWPrnBmuEbt8T6zlI81o3CNFjsQD2Xr5
gLGdk249XaHgnv1wwdhxP+9Nuc97QQNz/ubrLzSvEXafbDqz1b928oDjB69yW0JsL8keePclU4Pn
AxfJ977gLQuesy14xrZgM3AzCDML1tsWrGvWTjrl/NlR+1To6PmGPbnLO9/bVPv/f/9a/o2M02QP
13ynPLLs+jrfhMuv4rBzDbrrk4viNjylfC+VfXTJinf7f2O+dnXcquhXNg49VvJz+9kTKSkTt/Ub
4xDCZqS9e2L7Z+zcT2OXDdygdU47IOhH+jqOtJ8afEk30TTyh5L7d233O2ZJDO/zevkm/UPhmtIt
v40J/Kf53TNe1/Oerx4cJ+9o8fn966lVqtE3D/2S97dD375lazfF8kuC1kT5534SRD3zS/Pn9MuT
brz46bFxV8qz/pY3Zu/LdKS+85EzV7kV819d9/aOxOiv5nz1XMOlWRvRqWlpRz/s99Dn6frnEqYF
TLuQ8MXHgcxXz2UyxybGJ1XnBqpK9ik2P/zRJ2PShpwMLHjWeUHff/Gq+g1bP9wIWqHI1kLnuLWC
ImaH7h+jOic/+d6RLp0S9J9SBnDuk+LgH2iAOFAGsXFQTehSBo2iBoVJZJ5UQX6sp01HKpynYlxx
XSXElC5YRmtTk0a5pzyvvGxGTXVZF2KKf4VYqM3sRsy/Z39ZuSnfMbWaRKqjBqf/W62wr3HemcKX
MpOf6/t87Pl/hidkNRy5ZXzqb5kzfz495LuPH35zek5eyY3HqDdzz2VVWcNSyw+/H7pPOWxfU/2n
mYe2r1CPejvccm3jt6pQ4+n0sD9KHvvAL/OZVcONj518yRry5vA+c2v+7hWc8nCyNvnTQ1E3KlL6
4LhOodewZ1+pwoufuPXantKmln9O3rig9YHlu6+9unrLB0nPjnrAp9fiEZ/abqKBN97558AFry+6
XJW8NabvzZdjdinmlTw6u+KJtjrVol3X3rpu2j9Sv6z0vei/x2X6XTkwfG3KqHzf9ytGN27fufjY
2NQNLaOWVLMvJhy9P+xQXsXAx0acsMyPr24dKjv91Knhi6jqRejpI4sv5kta4Q/bgt9snkQphDMe
NoWMA4PGsnKa/t+hKjQER0+MOxnWRsOHLYg0qBlvxnAi6P1ZyDlp1y/n3xqxfnRGzJaM0qs2JenW
MOS7Yxf1ODqijrl/xwvzh0dce//gCNfm8b1cvetfWtSxI2f1bJT7/fEfff/heFu9ee51avA7xxef
+D3/xBsbDo2tuVqasS0DXVl7bP0nga8qN/ipVp89H7wzat7Pl5+te37FZ8nLB7ZNO5g048Mlu0I7
Ln5/xsE/uuSQ8AU60Pf6b3P/qdXHsD9GrV01aHrkzH1JKz6Xq94trDx5qDl9esVzB/YdWN73+DVa
O3fOrx9+Puji/cIXXzwv3Lz4ieol55mVl0buTdo8t8/HAy/0VZYkUhsWTAt98Obk0hW7Jx5IPlv0
cEGrf/yvKW0bWzw2T1n6UvS+Tc+8t+O8ae9hm98DJoOq98G8G+mf32e7tDLSsfio88vrW3e83zyo
dpYadMw00DF5ko4p1szOdTuNPc8RC3rmP3iquxROvM0GGiceFI4t2RZHqvGkanP9P0FN6qf/Rf+/
1TWbLyiWffDG0azHT27v33dn6ITpF6peN4fsW33shxcOv/NJxBtxuqUHzxdG3+o3NtjL8sIK1aeG
LdWROU3eaenPL7O/OGSJ6u8LVu9cJzs1LmPW5B9+aVd/2eTaEv+e6+ufLxVvmk/vy+z8JFX/ye7j
96lO3X9tn6eqvWha5AP1D+/befCB73xefuT1X733lhRe1l3sf8U8aemu5ro3My+tebCh6PFvdzYc
TVwWb7B6Xih59wX/bSPbpu782JRsm/n5sqlDvnwn8IZqlCvd+h0bNs08PWv3yrf2JP9t0DMzJvsO
37Hi7PKFqbMVQ889vac19M0vr91f8eJw16GI9Ownig1FI2zHWq6fUjrnXinIbfiQK5i1QNI1v9sW
/CryPkhDTiwcQtmRHgf2utm+fO7o38dkt33tc3bawr5sTMR391ZNRE8EhTK+Nu/mex/zDDLAyAy0
pdiSNyZuTFgUL6UNS2ur7kgbOqc7SKtVSrbWWQfng6DFQJNtWNeS4IcMsPW3JXXVbdSi6H+ZhxQn
LK/tMZPrjgMkahv7uJr8qU+ZFvbF6m98sgfs/PHcgqYrqkZXw8h1Q32vIy/H/Aslj2zumLrpia8i
o/4oOPuYMOrwffxL+5+93HK9Lbhmwh+//vKFx0dLuVRvH9PpI69kDuUiisbx2auvcidey62++uUw
fWTCUnPtxSl7dzn0YauvfN+XvzC/umalIu9475ys7XHRi77bdKIw4uDBAZ9P2rNQ+VpC4MjWzKGd
B1ZvmiDftvbT2YfGNT2zdcSJazufWJ/+5XuTw1L/0dR36IibHxy7/8kf9777RKkhf9fO9T+fPfzB
xk071hyfY1kc/V87cPzmnxzmW/st1n68GCMpzn/g+6mGZQIcUncnKD/fsNDH7tUGQbUKvoM6O5dk
H++3AZY2c4GlTSustPGseQuZKBu40iYkMze1uCQxtwC5tDEzsDQ0MzA0NTUCN28MwVwjAxDXoHEZ
TdymbqAKqSjl8pwzC0AD4y7BrgquwX5WhgYuFrqmFibmus5ObhYwhczCcjg8EZxaBBpKJ1hAvdrF
mnziZuW6Fhe7pZuPvPWZp3LfskyO85qRV0TFJe2bS9knvH9u+3uvWs3i309r64zO37TttjT/9OOG
tYnYlUlNv03eZLQWSfU/2OHzYEfrZ2MupoOLyopNfWI/bn/oVSu7Y0rF7f9yraJOboXn6tXDhS42
+1uf/3XvW/dbe4bHV+8l/hTv9V7SaPM10+HVw8797P67Sqpf8jx1f7U65+PV9EaOH2KnaoV3Fz/i
9PmV9PvtAstZVv9eC55IlEuKuMEV0nzV2tv7Uehe/QSpvkmszrdiXzdxKU/nXMBqmNo92U/OUXHR
pAl/XV1c8003upqvzVyZ+tPEeaP4IWvLhwI9n6TaH4cEyFvPNVyLXEAhCqS6og969mGaD1S/Z+xg
/OP9sO78YzuUsif/hZ/99J0mq73b+vfMebXG2tH52AWKyp6S4oLkRKqUPTCTSrCVoBwYpTCWAiqz
qomTR+zivfNunXr7L5pUNdarazhqfb6sOIlv+tr44DjNn28PhnitqP0ufIFb5KfvpzZRhrzHzbIa
rst1LI3u5s8yj3qnHNQfwtxrv3xOisU3sxMiztus7Gac5D1c2KjxOW254aOY2P6fQUEPY15PnjA3
k9On8+LFMh8T3qyHNS7LtaObQ+pdVSRVj3S5HVV9LNmQqSnyTfzYByWdRrc47S8/lx0rt1PO/7ks
pbVvURLvSl25FU8n2NX/39D3Z/qbj39Z1p/1PBdVsubXZ2F5actzi7dc2/Nly7sTaz+Fyf22+Xji
mpbLnv1z7GvTJM5uUkjmOuVgm2okWbNph+1BNQ8/JcmZeT0GBz9ORC2gBLK4Z/ofYFBdLXjbVT6i
Kn0RejE1MJ0vaOlkYGJiDiqdLIHcAeh8YRSchMqbO+Z5v9efcPIqlDhxzsMu+MCv1SK7dIx2C/kH
nWh+a2d809Nwksa2iSkP5ANadh3yvljP+uN96b7u4yuursssSKtQT3uxbfv71p1n3636K7SEO1JJ
U/+8w80wFumyrbkpuV4ht+9+vLd/fvPxhvv1PkzmU74emMcRJpfhfvbmgbIY/dptqixbwqKzZJL/
N9TYvLvKouprWV7CHnso5kabuU7pSb5XcpacNWX/5ubkVT14Y9c/fV4hX7yWv0RSgtG8S81+2kox
Ga7d9/RbBAI2/dwq1ZvzTnW28I/TAtdb+b40lRWbHZtatehMAtsb1g1txtt/TIlucWyJaJ2St0Fe
x+NM/hznB1kv6tX6siHlTROjBjBEVLDn0CHR/RJg44QOgIoygu/jQCo9sRaOknANIkwsPHJcDMHg
0XZnBkfUrhlGvw5LATXFV9DwUE3AbsG+hYnsjHw9Ba6974tD9tpzsur+3xEY3Crz1nLi9sVh3Pd6
tllLX/y9ZvnJ7RsDFaXzOTLrspkXKbm9zdmSW6O0w+1yy+de/n3sXWYHX9e9LIh1nT/p0plzd/sO
PNyvdbbmzcl1Rlfbd55OPmJ2UUJxf9k961mbpYvnKXbc2LJFKKTny5xDqV6zNNTmJHTxWx8XTq3w
2H1+bbOV/4akiHsGL19ayj7u/HTLsvGnsGJPSkMyG8u0T7OYnPWr3Tp2/We6mfrT694t5pLJm1nz
eM7MvaORWOPxUXyOoKIFk0z7Graj04x2PHU4Fmy7d2XnvRdp5r1flKbNObOhPCTQ6lqRyyblb4ZN
LPOBhdRsJkZGg8b2AeyVofQVEWPcCxpPGYjA41uD0ZCdmRU8RwFKBdDI5GQ25EEeVge6BsHjNuQz
QJYVNVBGaGQxBKaxX1++i0rZvClsN4/J0L04S6MpbvcMgxAkLTyGbgYuC6QaJHBNBi9Ua1AhYkmB
AlpxxtLEyNApdtvqRZdJ+ramx7rBXGsPH2GY0+dy/dKvV3zrl95rm7w30crKbE3FxELBszb8Pzwd
w27cKlspYh3nGGb36/qc01ztfEt3anr+/LLxZX5zQ9glpkOCrIFFb0qkQ3rlBRfzBmw5oda1himz
wLA95t9sXeE+TZNQ20plGZ4l86zfHeBg+2FYHjFf68BCrX9X/ppI+fuppHNMCSm+LWx+47vNaXHV
fzsultqnnyq/qn/Ydaba9M1feo488Mxl3WbO9OiUeszKHq8Or4DlSg1aW/tbimY5Rt1dn+maJTKB
K3Xek6cSznvyeVyWBsls1cqcKsz4VdoiO9b7YZN0DpPFsaJN/bJHOFwVX7EdZNuwsIlJ3qCJSRoR
J2yGTUw8QCEOuidJ9BoIpUPBDk2SC2INJJBTHjdi1ocRaCdchtWQH1i1WhgaGIMqUktQSx894dnO
XMiyfNXfo4v+q+V+TK4rz/TLtUAro0BJJNtG5vTB8unfHp3iT/G48lO4+4vDwgq/+0LiWyOyhLPc
+oRfekS3Tdf5/GRO+qzTIYbvFT6KNs15w8vgEa1eljLBdeW0ysM1daY9S+KFUnbP3l4iLbv/MFv7
7sV3U0VNhSwmVL+p89uuIzT9k3Vlnvnb7HNeiyJ15+kYpLf2qG158SBUSPn6dLOziSyFF62qU65M
O3Zn5blNr+9tOfpy7TyRsLlNZyXXzj51rGKO+uunnZaK6TEH//RbGtnJ7l0z9axthLtBpt+87qUb
zbamJtU2eNsd3z5v8Tx52U/NZhF9T1ef1P632Z+7c4vETb9X/wr/BdeLShy/KiV3Q5u7KnD764YW
A7nKk5s2Sx36xAAARFDsww0KZW5kc3RyZWFtDQplbmRvYmoNCjkzNiAwIG9iag0KPDwvRmlsdGVy
L0ZsYXRlRGVjb2RlL0xlbmd0aCAzNDM+Pg0Kc3RyZWFtDQp4nH1STW+DMAy98yty7A4VJAHWSgip
pavEYR9atx9AE9MhjRAFeuDfL9isWztpkSB6z8/2i+ywKHelaQYWvrhOHWBgdWO0g747OwXsCKfG
BDxhulHDjPCv2soGoU8+jP0AbWnqLsgyFr76YD+4kS02ujvCXRA+Ow2uMSe2eC8OHh/O1n5CC2Zg
UZDnTEPtCz1W9qlqgYWYtiy1jzfDuPQ5P4q30QITiDmZUZ2G3lYKXGVOEGSRPznL9v7kARh9E5eU
dazVR+VQLb06ikSUI0oJSUJ7QgVWmnPS7wqXhpyjjMekfsBcMaN7vGJO5JrIDZEpkQWROyLXRFJr
Se7iAklJ7uQKr0TOtsgIv31ZLEi2/+2e/3Efk9GE2qf8qqi4Lbqa3iMiIdDQliPi8v8W2wRrb1NS
r65aTDOaVumyAOrsnJ897hsOfRp3Y+CykrazU9b0fQFbEcp/DQplbmRzdHJlYW0NCmVuZG9iag0K
OTM3IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDI2OTI2L0xlbmd0aDEgNzE5
MjA+Pg0Kc3RyZWFtDQp4nOydeXgb1dX/z6ya0cxotIx2SxpJlmxLtuVNduw4lhLbSRwnOIuTOouJ
Eww4gSQOSdOQ0CYUQkKgIUBL2UqBUmihBWchJCwl7JQ9UGgp0DdQoPCWAG0ppUCk99xxwtIf7/Mq
f/Tp7wk69nxm5s6dq3uv7veecyVbAgoAXAgWBjpmdU2a7to2BHB4GMC/cVJH50SIM3cBfHou5gpO
mt4zy9RkacXzG/B8zKRZsye8XvpWHM9fxvPvT+2dNfnKic0/A5BKAZg7e2al6s6YedV4AOotvD4w
p2Na3+q/nLUMwHIQgDt40rJFw5+eO3QvwBYr5rn+pDWr9anXj6cBLjodzy8/ZfjUZTc8tWwGwPm7
Aeg7T120ahjcIOLjrcbyrKeefuYpf77wDy8BXMwCzNw6NLhs7bJewQOg7QdYNX3o5EWDz3/01CIs
C8uDxiFMUMsErB9F6l86tGz12isfqr4Vy54MILx82slnLK8/t7IH4M942dR2+oqTFlW/6TsH4I/b
8Xz5skVrh/kE8228/1HMoC9ftOzkd17MLgT4axbA7BhesWp1vgfWYv16yfXhM04eFobfw2sXYn/S
nwLpa44Ljbz64vyFauvfwS8AsZu/01FB9g9Vt+ifnHf4UulSAZ8DbCcNo4b3CVJuJoBciddXSpca
JX3R9pIUZg9MB8Y4p8EKKZiDB2Z8XCOFtVHbgQOBu5KrxyJjo3vmWlhL3yQALfEsw7EszV4HfD4L
+nzSw+TGabN0HTBBj/DB3Fx4TJCoW3Wgfkyusf3cAdJSoIQjVaKfGd2YOBVlfgE/4y+EB45WknsG
VpE9cz3cjtulnAtuMu55Gy7F8ytwf5i5Pv8app/PuSgX7q87mgf3d42mw5W4rcNtJXM9NQ/vexMf
I4fb3/kLKZnth2uxV0e4teDjzoJHuctgFZ/AvQqPslfAo3wDnjPwKHMinM/8BCqNVqzG9F9hnk9x
PxVWsc+N7rntmLYWzmPfxcd/CXaSMk1vwwJuPXSw7wAPX2GcK2/0N/sUDLGfwj42CUtwfzr7ICzF
fukgx5wV9tF1cBt9X/5+9m64D4/vMj0K+0g6+xIsNe7DfMxS4/7lTBm04bUdmHcctnMO7lvJMdsA
/V9Vh//fDJ+Tff/pOhRiOKau+OI5Hc8fouNw7X+oOkUrWtGKVrT/uDF7KKqkpMZiIbEYRVmAUilK
QgMCCVMsFkmus1i9UadFXW2GqlKLoiiWuspAXXWJzSiDAkxQlBJF2k1Zdtskq6IkbDbJbFXNtoIr
8q9x3/9uEsldePaiFe04NaJYNJDhIyEPAgj5HK6tzEizQRQxUgYZqYCSPwwWsCBVUJFWgzawIe1g
x+jeAQ6kBk6k06ALSNTvBnf+E/CAB+kFH9IHfqTfYAmU5D+GAASQQQgiQ6AjdYNhCOf/CRGIIKMQ
RZZCDBmDODKO/AjKoAxZDuXICqhAJiCJTCL/gSuZSmQVVCGroRqZghpkDdTmP4Rag3VQh6yHemQD
NCDT0Jj/OzQabIIm5BgYg2yGZmQLjM1/AGOhFdkK45DjDLZBGzIDmfzfcGU4Hjne4ASYgGyHdmQH
dOT/Cp0wETkRJiEnGZwMk5Fd0JX/C0yBKchumIqcCtOQ0wyeACfk34ce6EFOhxnIGTATORP5HsyC
Wche6EXOhtnIOfAN5DegL/8u9BmcC3OR82Aecj4sQC6A/vw7uF4iPBFORC6EhcgBGEAugsX5P8Ni
gyfBSchBGESeDCcjT4FT8/8Np8IQcsjgEliCXApLkafBafm34XRYhlxmcDksR66AFchhGM6/BSvh
DOQZBlfBKuRqWI38Jnwz/ydYA2uQ34K1yLUGz4QzketgXf5NWA/rkWfBt5HfNvgd+A5yA2zIvwEb
YSPybPgu8rtwDvIcg+fCufnXYRNsQp4H5yE3wxbkFoPnw/n5P8JW2Iq8AC5AXgjfQ34PtiG3IV+D
i+Ai5HbYjrwYLkZeApciL0W+Ct+H7yN/AD9AXgaXIX8IlyMvhyvyB3EdRXglXIW8yuDVcDXyR3BN
/r/gGoM/hmuR1xq8Dq5DXg8/yf8BfgI3IG8w+FO4EXmjwZvgpvwr8DP4OfLnBm+GW5C3GPwF/CL/
MvwSbkXeCrchb4MR5IjBHbAjjyt42IncBbuRu+F25O2wB7kH+Xu4A+5A7oV9yH1wJ/JOuAt5F/JF
uBvuRt4D9yB/Bfci74X9yP1wX/53cJ/B++F+5APwIPJBeAj5EPK38DA8jHwEHkE+Co8ifw2PIR+D
x/MvwOPwBPIJg0/Ck8in4Gnk0/BM/nl4xuABOIB8Fp5FPgfPIX8Dz+dxM/gC/Bb5W4O/g98hX4Tf
55+D38NLyJfgZeTLBl+BV5B/gD/kn4X/goPIgwZfhdeQrxn8I/wxfwBehzeQb8CbyDfhT8g/GXwL
3so/A2/D28j/hj8j/2zwHXgHeQgO5Z+Gd+Fd5HvwPvJ9+AvyL/BX5F+RT8Hf4G/ID+AD5N/hQ+SH
8A/kP5BPwkfwEfKf8E/kx/AJ8hP4NP8EfAqHkYchh8wZzEMeCTiPArNXNIvAMBxnAjABy5qA4RjW
hAYEJpYc82bBJAgmXhA4DnhREE0ipgq4NxmOggeeGIO/DM+I5JjFH97E81zB3qbwnORBafr/zFa0
oh2/ZpbMKFeWE4geiHxZjuU+1y3HCYLAm4lK+aO6RdWKAqaYpM90ixlR4yYTw5gYydA7z5p4VPxX
vkb7lXZsumWYY21o0Yp2HBl57YPoVgRcUX2VbkVRRH8riKIJPe1n/lYgHlgSRnVL8vKjumWP6JZD
3RKvXLhuC89Z1G3RvvYmKzLqluPN5P1l9K6GbtHHCkAgGLo1yUS3gkkUUbcms2gWUMioXeWIbkle
dMasIBi6Ne4zcYY/NhVckcJzkjfJi7ot2tfaFEVBuXKcoVueR+2ir/xct5iCulVEolvcOAyJJUO3
mCwqomiUcVTjX9ItFiKZhKJui1a0f4NZVAvqluclXOp+plsiSiAQ8YIkCRaz2SyJgmRG3SIl3NDr
mlXzqG5FMEJndM0MJzCKcZ+A8TTeIhRckcJzkgdl2WNtaNGKdhyZqqpEtyaZvJNuMpmJbk0oUzMQ
mE0mWZYFFWUriaIs4fpXUCRZlFG30me6NaPGiTMmuhUZVTSP6pb4Y7HgihSuWwwNirot2tfbrDYr
eRfHpOBS19Atb+K/pFsMpEUrOl3ZLMoyrldFRVbMCjpcWbJJklEGySuYzbwZ/bHIqeQ+XsR18DHp
tvCcRd0W7WtvNpsNdWsSLES3uCQF9JTC539hJwgWi0W0odNFqSoKxr2iRUHdyrJZlm2y2ShDAoyi
JTOG1Bxv5mwYSEsm0SSZMbz+d+iWTBZc4W8bFa1ox5/Z7XZDtyqAYujWJJi+pFsMpM12lK0FdWhB
3ZpVPLQosqTIdnnU35K8oiQZupU4u3Ef6lZSMbngipgLzlnUbdG+9uZwOMg7taIVwILLVIyVRRMG
xLIMBLIoWq1WswODZVWWVIsggmS1qJKqKLJFcSiyUYYMGEXLEi6FeZPE28l9gtkkSxheF67GwnOS
By3qtmhfa9M0DXUrEN2qqFvF0K1C3h0iUAzdShoGy6oiW1WiW5tqla0Wi6xaNMuobhUwwmaTrPAm
mUc1o97NAuaXjzjkQqzwnLgUL+q2aF9vczqdRLfkX71UMJsxVjYL5s91azbjAlhyomytqEOrYAbZ
brUpNtWiqBanRTHKIHklRTEphm41Q+8S6tb279PtMfwBZdGKdvyZy+XCZa1otpNPwzCbLYZu0b1a
gMBiNuMCWHbhItdmUWw2M+rWYehWtVhVl2oxyrCAseQVLBZeUHhUs8UiSqJFsStHAulCrPCc5EGL
ui3a19rcbjfRreQAsKFuVUO3KnlXl0A1m3EBrLgxWLarip3oVnHY7Ba71WqxWd3WUd2qqHHZYhEs
Ki9YeFQz6l0WVYvDYilcjUrBOVUo6rZoX3PzeDyGbjWiW0nCNa4kSp/rVpJwAax4rFabA3VoN0ug
aHaHxWGzqnarx6oaZaBuVQybBdXQrdvQuyKS9a+lcDUWdVu0ohVsfr8f3awkuwA0kGX0ubJZtpF3
dQlwhYqBtOq3OxxOm9WpSTKobs1pdTrsNs3ud4x+AIoNrDZ0v7gUNolWk89mxfssks3qsh5xyIWY
WnBO8qDH8A8LRSva8WeBQIDoVvEAOEFR7CApkmIn7+oS4AoVHbI1gE7XZbe5XIoCVo/LbXNrmt2p
BTS7UYYdbHYVg2i7XTTbxBJyn6xKdpvHZitcjdaCc5IHPYY/fC5a0Y4/03Udw2NF9eFSF0Nj9Lmq
rGrk3SECTVV9Pp9NR6fr1exej6KC3e/xOrwul+Z26S7NKEMDh2bTHBhS4zpZDGkOTbPYFM3hczgK
/0SywnOSBz2GP6AsWtGOPwuHwxgeK6ofl7qoW6ehWyd5d4jAqaoYSNvDbrfb63T4vES3JV6f5nO7
NY877B7VrRM0p82pyU4nrpNF3ak5nahbp+bXtMLVaC84pxOKui3a19xisRiGx6otiEtdXNJ6QLEp
Ng95tYoAI91gMKjFvF5fwO0MlFht4AyVBFwBn9ft98a8bqMMD7jcDrdLcbvNistc6na53VaH6nYF
XS5HwRXRCs6JIT2G9sfa0KIV7TiyRCKBbtbmiJDPiXM4/KA6VIefvFpF4Hc4IpGIO4GrYN3vCet2
B7ijobA3HAj4QoFEwGeU4Qevz+Xzqj6/bPHKFX6vz2d32fzeiNfrKrgi7oJzYmgAUuF/plG0oh1/
Vl1dDVar3RnHkBlD4wDYMOQNkFerCAJOZzwe91aHdD0a8JVG7U7wlUVKS0r1UEkkVKWXGGUEoCTg
CfitgYBs9ctVgZJAQPPYA/643+8puCLegnMGcJMLf2O4aEU7/qyurg7sds1dAVAKbrcOdrfdrZNX
qwh0t7uiosJfF4lEy/RAWdzphpJErCxYFo2EYpHaSMgoQ4dgyBcK2kM6xttqrR4MhZw+TQ9WBIO+
giviLzinDuTjdY6xnUUr2vFkjY2NGB47vZUAZeD1RkDzal6MjSNAgJFuZWVloDEWiycioUSF2wvB
6vJkOBmPhctj6VjYKCMCeqQkomNIrTp0NR0JY2hd4ozolfoRh1yIBQrOiSE9hvbH2tCiFe04spaW
FtA0tz+FS13w+WLg9Dl9MfJqFUHM50ulUnpLeXlFVSxcVenxgV6brI5Wl5eXJsqby0uNMmIQLQ2W
RrXSmKpF1DGxaGmpN+iORVKRSLDgiugF54zhZrUeWzOLVrTjytrb28Hj8YWaAGohGEyCJ+gJJtGA
IBkMNjU1xdqrq1MNibKGukAQYmPq0uXpVHVFbfWEauPrQiEJ5YlootyTSNjd5fbxiYpEIhD1Jcqb
ysujBVckVnDOJJB/9z/WhhataMeRdXd3o5sNRsYBNGFoXAP+iD9SgwYENZHIuHHjKrrr6xtaUsmW
MaEIJDJjxlaNbaivbqqfUl9tlFEDVamyVBW6Zqev0tmVqkYXXRZMVY6rrCwruCIVBeesAfJvw8fY
zqIV7XiyWbNmQSAQjncAtEI8noZgPBhPowFBOh7v6OiomtXc3JJtqMm2ReJQPbFtfN34lub6cc0z
m+uNMtJQ15BsqA00pD2BWs+MdF1DQzQZTtd21NZWFlyRqoJzpoH8++GxNrRoRTuObMGCBaDrpYlu
DJkhkWiBcCKcaCGrXoKWRAIdct2CTCY7qSU9qbMsAfUndE5umpzNNLdn5meajTJaoKm5prlJb27x
6I2euS1jmpvLakpbGrsbG2sKrkhdwTlbcPMW/rZR0Yp2/Nng4CBEo2XVMwG6oKoqC6VVpVVZNCDI
VlXNnDmzabCjc+K0TPMJ3YkqGNPb3dPaM7GjravjpM42o4wstLY1tLVG2zL+yFj/osy4trZkQ1lm
7MyxY9MFV6Sp4JxZIP/GdIztLFrRjjOjj3zLuAYMOaJ8uPGff/U4Rb6z8l+/thIvMizHk49PlWQF
VKvN7tCcLvB4ff6SQDCkhyPR0li8rLwikaysglRNbV19Q7qxaUxzy9hWo4QJgJPBpMldU7qnTjuh
Z/qMmbN6Z8/5Rt/cefMX9Bde982FZBr9TpIduN2+p/CigYUtyCBYsQALRCEOGG3AFJgLC2EdXAu/
ZL6jO3SvHsnngbweHodyqMQofipeX/TZdQ+5nv/jv/yclD/p02sPXnPwRwdP/r+/4z3rnN3b1FiX
qq6qjMdCmsNuU2SOpSv1ESbWGe2MLhraqncO6VujHQMdVZXdM/s6O/zh8NyqSh2TO/QRakDvHJm4
ZsiztZNkGLEnR+hYJ9mWjmQvGMCDaEc4HMYrjs+v7M3vv/ALl/QlI9lFI3CBvqNy/9YL91ph8UBS
HowOLlrQN8IswsfaAViZod4+UieyDQzpIyzebcCPKUeqSK4NDSCjHXjXV6Zjstjetzm83z9ix33n
iC05MglzTFr3up/Z2ulZopPTrVs36yPXzuj74tUw4dy5cz1f6oaJ0YkDW7dOjOoTtw5sXbQ3v3Fx
VLdGt+7o7t463Dmgj8D0vhEK0++8wD8y8cK5I9aBIaoFm0zaMXFmX8YftmEp4TBp7wV7s7AYT0Y2
zugbPddhsX8nZFPJuSP0ALmy/+gV52xyZePRK5/dPhA1+rq9j/HTWHD3rGj3jHl9eufWgSMVPpIy
ZvRsBw0TdkSpLTN2ZKkts+b17bPiaNvS27eTpuj2gQlzd5Titb59Og4UI5UmqSSRnOjkBLop7I6d
tGDk9+/LAmw0rrJGgnF+0l4KjDThaBoFJ+2lR9OsR9NoTGNH07JGGjFsDN3e2/fFWuNG6g6wD3rz
+7PBnRV1jdad+s7szuk7h3du3HntzpGdz+w8uNO8f+f7O2kca9nh292exlAHpc4JzaF7Zi+cTa/o
pX7ce1svPWOWm505y8XOmulkp3TNZCd2NbGTuurYybh1pZvZ1kwdOy4zjm3LhNn2TICdkJnJjsct
i1smXcfW1Q+y9ekGNt3Qyzakg+wzDQcb3m9g9ubf3bU7Nrlxb/7grt3WKO7fzSq7RbVxt28yu2bX
ebuwWu/v2mXk+Dib3yWWNu7SJrPnb3Gww6cPr6XVq//rGjr7I5e3MXu1y9+Y/aEbjy5z+xvP2+QI
qeeqm9Rt6kXq9tC5oW2hi1LbNm7auOWii7dv2r55+xY1+13R2qieETqDzq4U5UZ1GaU/SumPUJmH
33uY1h/KPkTDYgoWWxfT2UXXLqLV+VSVZmMrtRib1JrZhOZgKzQnG9KCbFhvZ3Wtlf21r5P1+Sex
fl8r69PqWCfmc2B17ZqPteE2rFFZbXx7o2pJhICnlAe6Q/L93SHz/u6QiBt3d3eIvac7xOzrDtF3
doeoPd0huKM79MD9idD+exOhe7Jz7g6H7twXDt2xJxy6/4EHlXv336fcfc+v5H133iXvuWOvbL17
4910dt/GfbS6J7OnZ8+GPay6J4WHK/Dw3j1P78nvEcxiEysrNM5dDE1TQE/nqL1Unhqxd0N374QR
B4X7WRN2iHXJ7pHBmRM2fe97gZHLcOSObAzM3StgHtTpCLVt7ojQPevI4ejbJ6tWr1qV/AobYTpH
+M6hRSN8tGMVObGQEwvOFpbOEZUcq9GOJDWidQ6NaHj0/xSy6qglVx25OPpABuCbX/WYpC6rkckk
H+Q17n3uAHsW28+8Qv7jNf+n/Ku5tbnB3Fzm++R7rOEyuBkl8jA89dlkfzfcb+zXwE7YD49/yRGc
Dd+HG+EJ+D2891na5XAN3AIjX8q33Ui9AX4Ot8IuuBMewLQtcDGm/hR+8YV8K9B/XgRXoa96jjr6
dxgP0Bo1WoO3QaYPUKuobeBDv9YBC2AVfAfOw3o9Sk3FtHGYNh1Tz4C1cAmm7oNHv8J5jYM50A9L
YTk64H1wn5GWwNReGMRUkjZqK9Gnng/XwU1wF9ZrHdbsYrjyK8o7mw7TYVgNb+Cdj1E/oB/GFt0E
m3iNfLIsd4D0Kttv9C3kXwXIDeb/jhHAYvoD+nr6YriNXor+mSYu10S+SpTBnXYHT7NAttSTrzxp
oLYmbAvbYggKc328kYNPyB42ko+1pKkogsHHIncvynoYHM2m2ZygihT0s7Is07PZJNPP7c2/sttq
pWfjwTu7VdU4+Hi3ohgHv9stSaOXsmZRpGerXIijuVS/MYZeP5x8vR8yh+pTmdoaiokyjmi6nmZ8
N5e88MQT3IFPfs02fZx6DmfjnzEHGJbXjJrEs06a5xkTpYpZkWYqgUzhbKUpdai+P3UIi2utT7WO
Fkd+GDZ5bvJnuPHa4XvodrKROA/HCvdrbJsf+3BHdmU2PEdczQ2L6x3rXevd632o4WDApTqpU52U
MyirVocmaSYhVOIGDzXkoTxBjqZ8vJdf7NUWD0uUxNgkm5dhFfBTfr/i9lEB1nq7I0hzIivfrppU
h4eVQKM0RpV6JFoSINOf6be7m1OHRjcqVZ8yzlOp/tdTr9fWbN6Pdrh/Jdnt32z94hnVT4WZsDPM
RB3Glg4bWz1jbBxe436d27WAasj9fOjsodxfCV6gpi3IPUF9Y8nZSygLQSKXzr17ImVnbsht2Zyb
T/2UbJuptZupG3PzyLYpdy7296r8q7yDex8k8EAnvJpdIapetVWucdYE0lVt43p8kwI9HWeWSEtj
A5n13BphvbomsC423DacETmBT/BNmuAKaAmtyZmpkBOBeFONUGPOCllzlzxe6ylpD0zUp4bHV41v
nSHMVebHlnCnCKepA4FgRnYF9KiXIT5zrN3dxNzsVSrFNi6apl2ZqDkoVCptTAq0MbyWysidDj2Q
GsP64hCkgsFOTfFRPp/DGV810fohjq5+stmwd232Zuzt1CE8hEzmUAb3h5IpTMTf2pr+fuzZhng0
wjs1l7ux0UHxvIknJ/V1jZRT401UtIzno5HSdENjU2NjUzw+elBf5yJXMTeFqY3xNONZ2bdgdc85
i0++PxcJtYVKSm/5Uf8d1Gl1rdS6D99Y9f6GZ3KHGqLRofTyRel03XWLfvmCJ6CvOZFaZbFQNMXe
tHDZ+rndq3uimw8D9axamyhb3nnJrvn0rQMD7y/LbT+4beXfHlpwXm1qVmjyJSvaz6yrab3tvMoV
lbXz9Nxl5QMNY7bWoCRuzw0yKmrGCXOy7SIlmryU11TOlHM91GRmMtdjWkgtNK2gVpg2UGvptfwG
k91EUfI6lhLI3aDK6MJmq7Ih2hC7xWX94FAyif3YihIjcu2nonHaZrU31TtJN9FOze52udyM+saO
Bx/c8caMSzOt3V1trVdOyw0+Th2kqvDn4OPmrns3rM/97oZbcq9vXP9IJ1lhXZobpA8Z9VyabeYZ
3uFknI44FWfijrhzEpVlso5JzunMdMcAM+A4E9bQw8ywY43mtFOs/E2g7BmWYllpb/6D3aTC5CCr
kkpLIZDJbASXuK0fJv+17lbaFE2TJ8uebqDL4vGydL3LTh/Cik+7amxb15RxmUtnYEPo1txzOf1x
c+cj6zdSJbfcQJWv33Bvl/nxnI41v4lew67Emttge1bscVC2rGhtEsiI7cOD+fR8rlfqtZxGn8YN
SoOW9fR6bpW0yiJTvGqWLIKNo3mZ72GnszRrVmVsDaU6Qg4abErWSlkFk9yDz5rVQuMKVOKVcnFY
puRUfz1OFnU4VeBAJsAG1fdjy+rJ3FGfqsdRTCWT/ZQp5og6uLIqqolj6pmYm2NXZnOX8WdzuR+O
p76dO2c8tZQ/20Sdls2dy3xr+fO5y6mhF5Y//fTy56lTc1f8ZvmTo8/MNjqDHpOBdDbuoxJUkk5D
M90Jk7FX59KD6J4eYmSaZuaw6I1oH4bkWJEUWD+oS5FOFqmog87k3rzkVipweCV9ESnzCrqWEek3
sUw9q1ETVAzuVa4HeriFsJB8mjJN5kFAxWIBOKkx4uHt9DBdezu59zDiHaM++h56DiVAFbU3/1bW
TJ7lFJVB5aBfOYT+BP1a1FZPvfPee5ibyr+We4ZZYHiPxmyMoYCjXFSMGgNd0EHNoU6lvkWdR5kp
O82ksDZk7JNKQCbVj3XYfKh/835sCMUsOFz/S/oxXvvoblMH8SDn519lL+Lew5kxCpuzkUaqWWqQ
x9rHehqCnVSX1CF327s9HUHZ2SXS4S7GrOLI3EOcphoGDLkNTwlktPqJhwQPuQTXxNRYKEb7De/q
D/OYMesgOXkrGdO8TPLyl5fiiE7imO4/ssc2k1aTYR3WiSjDuh2nonRDHIc2zmejsxjKEycy9qJP
ch/lPvjHx5RIyf/I/TPq9ZZGz1x44vrSiNdVGj5z8MSz6LdzK3LnU2dRW6nvUetzGz69fcZLV15+
8IRpJ5zQM+XdbVc/O+uEmSfgk0G58Hlv5V4AFbZk09xEnpcZCzOZElRbyEZzdEilVFW2GI2xKLLM
z7bodIZZwQwzDCOTmAHn94NZiTSQcZEGMqRDAqSRTJDcxfAkjmCsisIjSQlM6mgEilJIJokWUvWo
gsN1mfoUeeZx1NjC6Tpjgq63hdnWT39PNeYey2yPVafZq6iay5k3tzg177TxH9+Pz/V12IKL0b/p
6NtmTA8NhGiO4W0uxmkrtY3lxihpSyaQCTaHurnJSqelJ9AT7AotZPrZfm6+OMe20Huiv79kYWBh
cCkzyJ9sW+xcERymV9s2+DaUbAjGsDVv7SaVpsk4zZAjUK1qlZAqqVGzKq9mjfGQlbF1qipNcdB0
aAolhGgh7DLmLpcx/bpY0iEu0jVecoPLRUpyufRrImokFKGxI68IWz/EniAw+uaQvdnoEnR82FG1
NWRK6MeuITMeGRZkTJD5r54soQzPhb9h9uJPrUuem79/2xXnz//NyeZJh1a8QbHJRNmS7tNeP4kJ
H5i3e+6dL21YfU52wrPRllfumX3phLa1XUse6iVzIarhLOzHcbA3u02SuJRPcqYqpHiqorVVSmu1
kYbUFKlTa4+0p+ZQc7m50uzUUumU1NLWtdKa1Or0+lZfQ0tHCz22BfuXqrJV0VVVFVNCYi2tKiGF
VhTbFNEcDTcZQ6mJJYOiiSe90BSsdoWZ6mALLrkYnzFkZGOYXJtRM6EMLV/ZZn2z3/pmMmlzN1sP
YXhFeseIOfsz9maySx3GaZSIx3XEi0cjhjsgYmn6TEQYmdZ9QVCjnUckRe5xulyspaZtSnv342ee
9f40dfabp2W2VVZX1VdVbZwyb+Llt1dXJBe3LXxhIenTZTe2T55y27dqzqKfTH731FNuzkxsHxs9
MGZKoqJy6YzpS4Ih940b1jXO8Pm0jrYD0bHllTVb5p+1z2MR6rGf78J+3oRxawJ+mB1nFnxCUhgn
pG3jXN1Ch22e0FuxVFgnyIGAr4tMJDjdxcJTYnyQVs0hM202W6bwZj2i9wSoAAnJq8nACrhItwUs
pFMDhsYCWhj0gAjGBfhxpVoZqqTFq5KjPWlrJh1pKPBQ6vOeTPUfJtN+P/W/9yH2mw3jVtvRrmM3
TZ0w+ZFz1r12gmXmy0snbWqorEqnGn6woO8nY5mNh8cn54XP3DN1eh/14tCvxk/sri99rqGrvC65
tmfaUj0e8sh0/rbcapataGi69ch8fBN3CCLQBD/IjuEVl9Icq6+tb+qKTahtb1pIzVGm69PDJ4e/
WWvxMRVdAYfDPSXAqHQaJ2dfZcoeDYNdxBn53c+nZsmYmo1BB6S/VNJHcHWz2hxqplNhkUzpJLN4
+RgSYxjjDEca6R/0zWRWtjdjr2DA2Wz0DJBuidPpBntTYynpA2eUdAuYjvaI6Stn7Jtyz7+4fHfn
nP7Z/X2Ua9/Y6RXmkpVjf5sHZ+9PTlt48dS+uY83/Q/r3gIfRXX2PefMffa+2fsm2Ww2982yIdkl
BBJ2CIEkBEy4BBJgSQIJlwASINx5jVYFvFtsxUu9a6v2eytFVND8qhVL0dZW661qixWRKgpatZRC
dvKdc2ZmCWBbv/f9MLueTWZn5jzn/zzP//k/ZxKj+mpad02HcGLVqBWJ7/8YfPSR8mHdpFnA/stD
oHzjmgHJ9LzFr3z9cUU8FK959qbklkiOo6jEVRy495l4afHPEbZQHcr8EGGLo5rlchFIMA80gCbY
BjfTPEqbIAelelwSTmVpKFiEgLAV0jQFIWPBSZMhFUwVmjgmWSlbFeYAO6wnd+B6BSVQFJeZH6YW
vg1fHdpDn2O+Omdmc59AOXnL8BHmR+zXlJcqoiqBcIAqQFTOhIyav18b5OmDkD7IxYuzAY8i4Ziz
IjdWGKuoc07MrSucXNHinO+d558XmJ3bEW4v7Rg9u2J2ZaewyLzIvsjbGeos3GDeYN9aut2excHH
Cn4chQUuKcrQWfVWGG9AQMihMkBGBhWVTMVBylWQoznBPeqa5wRNBBd40U2m8iC3eyypMPDaH1M9
A73ZKqJrTpKcjFhZctLsNjm7vfS6UlhcWk7Ho8XRMaHJoTmh7tCdBZwvJ0QXZOHahBQoyXaEExLB
CVhIoRHHZUaeFqlRpKHTJYqLVCkEMoV6ncL8SHnj2FfKh7devWkdcLz1AZCu2HLjD04+cuUVD8yY
mX9D7eJpgRkbon3JeauevWXXE+C+Xw5TZw9ue3k8J9+x9tG/vP1Iz8FKrnoPbF4xsGlJw/Ji+7iM
2ptT6xasHusqyB39aO+OPbcjX1sz/BHhPtjXrpGrBMbLFDPV+dXh+Khp+dPCk0a1MR3upGemvw9s
zbfYssobHcWNDi5Li0Bxm4icTfQRHwsRb7Oq9Ee1cmnQR+iOj8G/9d2OnUvzLuJbVSS5RUnU0V0L
8hxzPujYK9UQhE1HEdeyp10r7VcoMDG3tM+br5w6EFuQJ2X1TvzzOUfy4a4FP2xqawelf1y5f3Lr
glfksdGViVt/MkaOrKy97P4pgKZrDyov9q3dZjAihwLip2PL8mI1g1cfA9mTJs1Szj1892AsUrjv
oY5NkYCzpMhZTEEwD7lNI5Mk+kW+7AJzIMvNYQWeinCAwjNFXAqT1+pUtUblACKwNvSCjV+gf7QM
ss49hMUrSB1HrHyXdq5pcqXESpyP9XElbJiLM1XcZKaBa2XauW6mn/kVbyGX4vg5AsclmGZUajBU
RL0YMqBO1skFk/iSGZiyo0s2YtaOrzr0gs7cFWo6eyXzGxQdOvatY0EpWryjcoHkqaSz8VuAiqLQ
gCOBLIAyQRYgw6KoIIMWwssrcEBMYmZfkUS5Y3RZ06w22cAys2lIc5hA7LCm0A/7QjtI5oM4cALA
XnnuCuZ7Q2vpm6dDsA2Cfcp6ZT22wN9BL7ub/hmxQFzOYWdzYDaHKwlZBGVYFEJXjlJYxUeXB+Ti
yfTVT0a10gKRxCC7+9xC5kH8os33pwbvx5zWiOZ5M5ln175tNCgFeJ5FaIosnicbAFEAWQs6rz5P
Gs8zCsqADOh/OVOamc2yHJwNLpgpQDNFP+zN566gbx5ay3wPXpYa3gduADfsSw2j+0c3RJ9EfpaJ
+OlyuR6zvTwHHfc0w2a6ma3zLGBne5Yzy63dnn5Pf6ZR6EMVI+fLdrnsMR8UAq3ZQk44EOACA+j3
FqfoxlUr5VYD9UkiixAqhJ0JSyNJkr+1DM47Q7ZL6aILICJEn5xSNXbXzCcn7i4bJ9+5eeUvx0pT
3ul855/K+t/+llm36M7xVd3RD8Ho/LZIbPWcNavrQr/1h18/exQreXuGs/nL0IxqqWbqbflBDloY
AyuJFr8505KwyC4YYDLZgD+Q6ch1FAYSgYn5sJQpZaP+aGZebk5hNBGdWC/XNcxpyJJYtrC98XKx
x7TctyzYU7gksWRiv2urv6+wv6p/vMXO2gR7/UyzQ3b6Kx0MM32WEImUzDALNaOzZ4yugZYIiLC2
SfaIY6o9YQAGy4ycGdBT7DBUWpCxB3A3Na+4ckWLKiAh45xMIoNFK1LlyG9Q0U0yPPpTFL1eDaN3
XJFr5oN8kOhEKPjYcfCJV9gqsB1hYUFeKJfRxRIGxyAnEZRGkAIGxSpg0yMVOoS/bEaT0uCfurPt
0ZdP/7Sxb+J9X5eE57e1KUOP3K/8o6Nz1bKOxUC6Z84zs7sebX9WeXHtuiu39/eDCU+9BGK9vWtS
tyS6q67a1b910na4+wZlaEV/tawc+wiYg8GyoaebPmx/GBg7O5f2L1qkfHHXI8oXXT1LXZ6bnZaB
tetA7cEDILF+/fZtfX3KrxQZclnefT9+6CcTsBf6KIpdiNgCT0nUS08i12P3D58h1Q6nD3iSpvFo
KjeZh6IoCXAH8hwH+pIo0TsYwDiQV2zj1vGQjkkyrgglGXOsMkmW+iRaEiWOBltYwAoWI+B4kWaN
VB5VheAzj+ql+tF5qMuN6E8SG2bHsNPZVraH3crybLcBcVVUDhFNFS1XsjqBBROURXCkQ+6XJKoq
/p+A+AnuciSDITpII56SgULPwjd2pbbtehlmA2Gbck45C+5TutjXhzbB91P5CBqH0dzDaO5OdDMV
wCTbWaPTWGhshXOcA17ObiuNZWMZyIFTW3Y2nxUT6EiMF1xOe6klzSstOaT62z/8lZyJ52wpwFUu
/i2uBvl8J0VKZBRnj+uMFFeTZPAV0dfR4Ng+/CX8J5lUhdSauCUux2F2qYM346+jNRgiGjwavKcS
F17AKYfHTBefDg1OkNOhwd/I6fDgabKAK2NEYSD/UuVJ/QNKumqdicKIynPQ55NYQ9WjRwjF15Hl
EdCqKPRbHFNU0kIOwh/Z8Oz62S/fnfoSHHjowakzp66ct/tnypN5RdHtiz8HVPLyaLRwYEx92XWL
lJcB970fx8fGwCurH6+sHcu+7ikI71jY+8OIEPgNZMZMdftNysyM7OyO1F3zevO9ltTb/rzCbpy/
1g1/zE5hP0eV02p5DgtMIudwAb/ocOY7xzgnOeYLbVKbeb51flEn3eXogxssfY4Ml8sXs8OSkoIY
J7moNagQArgWipYmSleXsjlOowNb1piJ7WlcFlZpCrJStdrUQC9skXxOrYjyvoX6X0D0KyvYKZXt
DTW3zHlQ+ceizpXLFnUA08Obvthl2frV9Wueqp88vXXSlOeW3XJ2lXmlp8Sd4Z/f1QHyX9wPcru7
loxr/GzpwsbpTR/ffs/R+qn1ixYhH8U43YtwaqayqEE5VGVvtC+Hy0yMCwHSjQC5gQIWJyURmHGk
1kHJLl3+7CPMBKNDQ903spegrT9gCUQDcqAzwLj//8As+zzMTp5HWVInQyq/U0HFnOdyiLCo8Nn7
89uWnHtV2Qn63wOg/Y7Hf79lc9uh65999pa32levhn/9jfL0/ATCSqKyQ3np7Se+nFxeeO7qkqr6
TzAukI2Ye5CNDNStz4hxirNykMPOm0dkNw6wcUhLcSAwlAAEap3JYgKc6ABk1kCfNUjPGpBZA33W
QJ81GnxKZo0HZNZgpfEi56pOVqe9aQ3Rski5TF7MPUNh+q2hv9EW/GJf36Ms25N6R7v/AXT/InX3
XnSv+Nad+EYg5EFcoHmBopsNuFDbP/ym7CPr122wGBCJAfgu2P/RAv5FX8DPtQWURkwljObyTZik
SS0yYMZFpoH8nxlIWeCO1OZD9DNsUFmwJ1WBbp7450fsg8g/86hX5PE84jGcOYvLMAfNcXMjmGie
Ye7hegyLzf3m/kxLblwOgVDISFut7pgRZsVoaYMIcq25ojW4f1iRM/CNB1dSDEG2VUP2aR3Zxy5B
9lk9jJ6TQySMri+wFMgF0OcU7fjbInFx0YiPEpflq7JrGqjhk2GU/qNRFa8VmEupCjZyfUbzeyuF
oYudnlQhlA3/YkwlYaEPblE+2PEz5ciSpX3gAbByAIh32gMbqiY/sfqs8mdELLnO5xuUNXDW5WNn
dXZ2gdBB0APuqWn8zHOZL1CsPK+cUj5Qni/IBqt+puKBHU/wfHQvHSftCBeZt2AVoCCwEqrlWUGE
DlTJvqCnkbP7tFTzzT7NWMdVDFCCbio5jxxrJxazEHNlEFNtQi4hm1pMtEA7EAf4g94MHtJbvxqc
WHIqVkcRq+OKDPD58IDAib3EM8LnP1GJ6kQ1MvCasKrzY1BVoPcKdvyhlPfQIfjXQ/DdVCH7emo/
bED2uA6RlbeIPXrkkMiUc7RElwPBtEoSDPMkB83CeZoWTcR1ev/wEYITWscJGijkRvFemqeJHr0q
fX/flFtT6HWcqK2pcgz0IKJ7oXjQiau3t1L7Dh6E0w4evIN54I47znWg+ykd/gyeINxhjezoBdsA
tFc4aZ43xGgxI8PuICFYW42zOmJP6Yg9pSP2PRyL8XqQlYBkJTa6LW7A9biwTpeGJm5lpNQaD+fm
i4Q5jD944ouXy+4fYyjelFiwyue3KL+CAFz90ps24wFzdklhUf80uudeLdJsQHfOUuufhjSDYiLh
HSoKKN7CIzr3v4qLJ7S4yI3MBraKKOlvkHCIBf0NQzMPwU/Y189+oKH9NLonI2iU58+RwFg4lh0j
rYad9Gq2UxqAffQA2ycZWsU50jwD3U330+sRiZQgLXKQggyhnIyMb40hxBOFDKaOmc2gf7xBpAGK
gZIBYQRvjjKRsOqgsnVfkaer+qCqYJAVksjy+MipPGRpjKqTmC3mgLnFjAgs8QKiKbIMQXsGb/1/
j8An9Ah8SovAphFGw9rsyI823O9W3QZz3Umz2/bFmF4GJtvRcG83A5LtiCfjgLWWSq5FTgVCAMdq
AILs6UPKog1KzwFgBjeBK0EGSw/tppefTSE6fJCu0TIoOxZnIBCWZSMf4GP8ZH4G38Wv4fkNHLAA
yAWAk4txddwsbgXo5AZAH2cwAoaD80ArhxOVgGg+I3AA8rh20Cb9jT7ps+oUM0h8ujhQHZUnjwhU
angqIPYn0RqvCLY/SnmyAUJyFCTWh6SBADMYYn1Gtz6Ttj5DDmZ06zO69RmVf3PkT+TWmJH57yLr
p4girNsfG3ntmmQSlxuqiVHgGvv31IQDoAJec4CNncUbX2TmBcTe1g1/yL7Hfkm5qRD1CzmXoRhk
NYPdTbk5r9FrnwvmsrP4DkObqc3WkTHLbXXibqEHT0YkU9ogbnZCf8wJgzFR8qD5kXv1OGl9qjQu
LbQQd1QPcV/KMRLj1uVb8gFuIiTy6WwC1GynhSRDC2nVWThSvpC/WJapHUnckkzqI5IMk1gBQfzN
ZXeqFO5CFpxhpdRcWFFOsdnzuxa3Lzj3wD3K8Lx5XZ0L2gB71/3D9crQhx8pKSAcOQJ4tqBbObJ/
v/Lnrp4lyxYvBjkHngbBpYuWLU91gVwwHhWpR5T3UZFQSansl7kd4dJKBag/yWXjHDVZTY6mrBbz
bEuPhffGKN7KQ54XPTGJFgVLMBCENmcOVUbJVB/FjMTYGdlA0KV3Ar7U8+YnOm84oZVfq4OWYCII
vbxDJJFQ1G0tpmElEliJOqxEHVaifjo0+Jgslbgy58I8+I3W+TypU6vkyRElVwjjaWQbQefHzO2T
J0z/w/2HDoEfbH+2oTX5uzGVZVsXvvSTTbejwoqxLH5swvTpKZQjI2VVj++YvjYv4E/9dzha1osx
qGxkzyAM5lOjqV/J9Rh/jIfJwvhzelxZCwztpnbbAoS+ud65Wf051tZAT2B9Vn+Eyc8PxmlDcSyb
EwkOnTCKUJidwVEV6wqQUWQznmGB00+JXBZt8etQ9OtQ9GMoFmHD+NdVWCqApSJQkaigSy8EoQa/
co2RqR0YFO7KrSfDx6NE3koQ9SahdaeSQFWGLy3IEEStkNcKMXokMM9Ur6/52RuiJ+K8EJrt87s+
GGS6ryle4/F/PhKmym0W0/N7GfoCiHZh6CpfKNc3rb3CK9H3XQRYtVq7Q8PrOXmWALJABIwDVVmT
LQ2Ohqx5YI6l3bEaLIedUo/hCrDeYIPgSXS0lffFIMle+J1rlSGAkPXECNHDsJaDtM2J6hYTRnIW
tpspE5vYRCKkyYNtaDJZsTpIkEww7aVF0kh1UKz5PzG6NJFLU7u/aUTuPIDLUV0QDSerqqJpCFer
GCZ6AmkWbUl5XsB9ahBMQxnrBxkXlXt3KMOKWfn0EHhgx76GGfMfvLkrEgtvaPn08MIbR0fCsCW1
h309FKm4e+MD71aCh+TFuVnu1O+CkZJVOFttH/6YhajOKEMrQ0W1hBLRM8sonNZ34ZGHzNpN3l3k
3UloooOUy4gbBKiQX3AEioUiT14gL1oljLGOzYgHxpRMFSZbGzMmB6YW1pW0Ifi2BlojK7xL/D2B
JeHO6FZXX6Avp7+kP7LdHhJls7VSwG+Ijth8RUwWFwzmx0ijJMZJwSKnj+Dch53BiG3rszmpoE+k
dH/B0Ui2kLjUX24p7yuHYu9oveWtdWq1Nq1amrircEPK2WabW7TMtrRos21D0XW27UW7bXcWSbj9
hNZGDzl6KzcPM0Ym3f8u1BtSuJzJO9+LcrlYOKOx5a3bH1CGrzWvAUXf2/9q1+KmJxYdeh5Uf30P
YqbmVuWz79/3y87N8uczf/woeGzu4+PlhurxZxYuuX7d4oU+h89R8puHnvuiuvREQ8c1y5K9meYi
Z+le7SEd5hRRG9fJXsDEOZoWLGJAbBZpaj6AhFs6UD4+LUskRc9vZrEgeUI2EOwKGnBP7NMQ+9Ul
iB0mkiWrbS9JfhNWN6dqpB7jMR5kTqU+P5T6HN1J8OwHbHAPvrO9KEsXozvLon4r+0P2kKeGrhGn
0dPEjRkb3UKmiXaihfQ7AiOqrTN6Xjkh2wh3IZxQ6zRiPTCLHCiN4C8bApZAICAHaIvDuH/4T+q0
jGRjiDFdrBnJeYy40sWnMuqJykj6puhkRnUPEhqs+FbFRd0akai+oI2PVhvx7hFNM/SRLa6fMf13
1934Wv2M+kPBwtLdvStujxQGD8E5D/6tZdqUqQ0zP3mM3jq0dfONVRNrJ9ZW3baKvh7ZSteMOepG
eUk9aEBhimF5bi63naM5B7ImyzNzme0MzThoSAugjrSf14FtkKNYuJ4GNA2FydRUvK+eZqg8apym
A3PU5YJFAOjHQIfpON1K99BbaY7u5rEOjOaXtJG9ciQXpCVg/CaQ9nQQVGDVN3VUOZM6+iZ4A7yB
6osoeh1ls9F9L0DlzU24yqBelh+vp5fSm2naBAyQYSDLCkaDG3hpD+sVvIZiulgoNoyHVXQ5ExOq
xQppnKEJ1jF1wjRxktRkaAXzEDrnsXP5drFV6gG9sIfpZXvFHlyrMOuEbeJaaZthlNGBrso7OBbh
HNCkPhHJO0VTIkRwRsGZgxyyxngqxjVRddwWaj3HUWtRkZEwd5gHzAy31GQ9hcIAnjUWwck+IKA2
nwDin7gnj37QvNEPf5PyXx8ov1Z+956y4TegCsRQRgKV2AbMm+dKESMtYd4+l80cRXdVp7F9A/Wi
vHs92MJDiWElH+OUSpmQVClOZ2qlNrqDaWPnii3SXMMyehWzjF0qdkpLDVuZdZLbgOcmOgReoB0o
U7EOjuNZhgeSgYMC3llgAhx0wQI4BtZDVhS8QrFQJTQILBR4icFVg4lyUQXUGKqeakErv8QkiJyX
K+aquAaug+O4Jag6T5bjlw1vqEbrr5pA24+g/yATJEVIjEBWf2xKgeBjpVfp/CPkFfYY+D64i309
lZOywJ7U3fAT+GnqIZik8FZ5ijmOLCBQb8oLSkEpU8THeRnIjMy38MuYPl5ycV6hkCsS5nDtQg/X
KwgCnjPnQGiHlInFmwwZiqcZVF4iBOE5SwGpWRqQGBTMUBmdDmeqEjCyBFGIJMBgrqhVJ1/qRclZ
vSg5K5OiEwfBAZTr0kEuisOaXqRUWY/p0FAdAttEBQYKdtgizPHUN4dSX70PdoO7UbU3mFoHN9Ht
qSXwLuSpw0PKm6xveBoCpO1p0AIRKmAU1eqU3l9lfdh5lDc3IWazbPhDJovZhBatAiyX240SE/JK
zhATtuP7LCXvEfLebp6RvaB0ubkza3Vkq7TF0Ze1tVSCQlFNmU22QZstR2jOBJmZnkQOM3qiIAHB
kgWybIVx4hxQF62hXjzigcrMoY/KMlAcqR7taY1LDb8e4lk+LToP6RIL2ZnIkZqSU+t9pyhyuvj1
/bglHogn4vQoHNDxdwl3MOGvjBLwV0b5DXgtKglfIOKSQcDHGYiYaCDp3ECqKIMLn9hAClIDCfuG
a0d0XrSS8nj6M94GkSKkSlNZE+oOd1wQkP0QOHmjCjOudR7Ufep5ld+6f422jdjmzmQ9520tim6Z
ufsPq3qWgOyHIyVFfTVTn+6SKl/r2fCEnKh9bs6ndTO6+zcufnijrcbuDhy+e+CeSCRHyJJne9zW
wvznLXmF0VG7VipZKIA4MtxdrZ1d0xEGDiAM3IqCfAaVA+xycQzGLeOdZTl1cLKlySnnzLUvtQ8I
WzONZpFz19oYI8iWOckgONSl5Fod+v5Zh3/k/tkv9Vz6jWwgC2jWd2vtI4ulfx0NvpaLycrdmhvI
TeRCs180qqouKcMEfLhIHEf0GbEKSFIsFhguTK6n9Jx6WjaQNMvhb5JkS1Lr/uEvnibJdmfwQhUA
rVa6hMNLShYOU+CqC/Itj/VMvDp2dacPb1N3gd3aPKn+8SUdN0827hls3rv60McvXnPbzEcbWtY1
/ujnsPLGv0xrbo4UxDhH6s2Js5TXlOOHf18/NnVlXibZy718+K/018xGKkg9JU+zhJpDMAxyzSWu
PM84EDePc8U9jaBZqjM3uyZ62kGreTnoMW8B68wZVqsjYWSCQV+CFi0hopeFyLbVdDF8RDf0EXkU
se9NITdBtdsvEryLAjEw8QCR0FmRmAzVuWeIpcRrc9M9n7A2GtlCS5IemsZFrNSI7pkKWrLVl/56
4WMdm19paGwBkX90HpguzXlm7v0Hnnq4akO0uMEpTYmU1zc0/Ok2YAdjxxS+PqnhnddeeTfb44za
EDZXImxO0rAJ5fxqX1nm2JxmX21mQ04bt4zrs4p2AG2sZ6KZAUJ2LSvZHP8i1pjUWJMra/A8LYdI
yCEElLKOYHslxHySFnROyRESayzqJmFix10qTrXN4GRnpt8vePCZBNzlCOOzCeRsAlEfBXKkQLbH
CgTJgoDPJFwbvECeGimoE2SWl1M6FBPI3CRwhHKhTX+6xW2roEduSWAmDc7Ys/TwZzMm1z3V1baz
aXBw2qb6e/fsvL3l4fVTLgMxYLv5yGXTWvILwbGzw/CqXN+fXvn17+uxJtM7fJzpZLZRHlTjHpYL
C5iwqYwZb6rOnsQ0mZqy55laXL2mTvcm05ZsM6gOBCyZNU78dMcneOszCosGPmFBThok8T5IgOjF
VjaRkY/KSbcq64gNbwniAjgRpAOAGAcQOg38dmJGOzGbneDTTsxmJ3+3Q/xl+7Xp6hUZSfVdHIkr
1HIqTKpXIqsHz3dw8X6OHFU4sDu1YMt0Dr08YUzsljlr/zpa6ji0SjmhHAbhb47+/Rlw2+27nzRC
/9I7R5eVzS99tWgMKvmdCKO1ypmvS37w4N5rVMZF27lsZLNfy0t9BFk+Uu4LjirHepZGdCThpAzm
CYKNNQkU3gElWkQzwpxRTTQkxRCXMxBUGABJMT6LjTLLJmul2YUxas7BZzaT75jT0c08Cl/JjBFK
sqHZjs9jxp0ybUc/Ppf5Ou9ITJWXl6fUQVTriyUqSH+E9MNRbtK816n2BEPxCpSgMM5ouxToLti8
CsxSnhwcGDj0XKKnhF0oZqy4seDeoYn08/fm//oto4A9VmlnJiEchVAdH5UjNRkTSspLx5XViU0Z
00pqS5vK5oMkO8/VC1ayva5tbF+OLZe1B51FcjbD65UYHsh+PCmeN8i0adREJ2/hABfMKydGtusu
btddHA9kFSE+ivMQ/57xHfzbd6lvlwfKE+UwTKAXJqsS9ntIp9KDfTsfn8lDgqWHrJ+HPAnhIUfi
MXq/dvTIbII3oH47PTipPgaQdu98KxW8sAt0sbtXXuzuiqJ80/7YTGnU4e7OK0Kh7Na7NyHvnzLx
2QVdVzeifNR0lXz33mvunPnIgHJMOe11v2CPjyouvLxuSd0kVFvxt74+rb65sKhs6G3YlZv12qHB
FxMI1wcQcDtQ1HWBCjmDdrqc65201STUZjBmAEzCt0bYMyTZQL2OhT7SxdV6AkOyjSwDM2IZMJ/T
BorGEHJ1frePLAvmaDGSwgigtbL7+56Ap9MDrRf4kDDCh3wmnSOY0g+xmMjBJp0jmPRK3ESUCHw1
EzmFCW+BIKobVsqICLfTPbLLSRbvgjBNIk8Ya2YJleIFQ7bzu+p1yuByMh2Ddo93YdP0R6cPDrYN
Ln7qF3Db9B0FJcXTxg/9ApGDVxtnvvcqjsRPIFpwNfs+2UX5kJwB6iAyTyWkOVTR4v2Cu4hBS4mt
OhkyMe2hXxJJGLXE8AFIunudA0RvOaI3fzWDaN0u3SCsbhBWXRbS8x1WpcKdQnq6yWOqBY6FSfWa
IBsIyMZD/FjX1W++aRwcZD0Hz+YzSTST4ReVdugkM/FSr8shic1kYXo6rgle1mCwyLyp2Q3cAxKQ
QKdLR5ZLF4Jc+v24dGS5fGT+6mNZnZK7zwu8RAX0Eh7jxXSHTNFLRFD0+ZjaJPBCLSmpe7S8+LmB
DHxqL4/P62Xxcnt3+UcubrK8XJ9yNBlNag1bMu8kmfelfdtQPAidyBKHHy26ulTK7Ig0tLlcpk/B
I9gw0kuHrcYnDZlFRUVrZtDX3IsZ4C+Rtz2BvM1AnZXriuAfwfsiLQKLKQCyYMAUAVFTmUE2zDYs
h1sAfqgP+NChgrgPGiRaEiArsTwqkgUD7JT68KMkJMkWEQ+iTDkm2YSKd7LaNEEJzeA5aw/j+EZC
4+hF0EgjIo2R46qvsIyGkH+o0hwaEF9hrzNe6iu4TYxqILXRllBVHvzY9Ja/e5gXsOyBhZ41wRBQ
nQXVt8wTZxR5y+AgDJxM/RN82q/cwDmGfDCaGsLP2SCTbSTPDP6XXAgBEDC+d2kxRWW+xJO19q5v
AACgzxGk4Q+M6aa31uvWsiogUwOYAJPBTuY8+MmEjmtPqpIHGTcODhJ1DEdM3o2yXhgclpvoPLo4
Iy+juC6nruCZEv7pfJAfyMoU3LVFuUwWC6yZghwBgUhZRI60RPoi7L+++QhOhG58wxHCqABpIgJB
6+CfILUWwOttI/MpIwdlalP6ioRRgHXoMJkMIU+gy5pvyNSeHybXtJBrWsg1LT4rsQW+jpVcB33+
g1qOWwvw0VaSOa044uPTW/XQjwbnCBzQYFgO4ktZAz5yGR+5jI9cxkcu4/Nl6ouSmVZJM8nBmTrw
MvXVyUxznEwJnyJTlQLUgWzGV8rsClhl65VW2hpNKyk6Aq0Xfsba+/lDtPCNlahqBM/qVDnZb31R
GEfFuO2iqO5UE7Ia23n3oMnpnjOj+d5mmlGH0+/GYf6JxWvvK1w7uGL/E3Bbw/aicGlzjbsmOxWH
26ZeWxQO49DPJLc1zuxs7Wz94DCl516EJBcovjj3sv/D3OsekXvVZryeaBVd+P4LXuGLEi3uSRUR
NJ5PuSTZqon3X6dcgsoLcq3qW+kk/L9Nuf8p4zq/Q8YlZkcJF1c+HzJrkMUNlBtFYN94c8wac4x3
NZnrrHWOJpdgSYiMM0FLRn0HhFE3vRG3BIjJjH6vrNl0SNc9/qJ6kfYA8f7h93RWc0qvy0/rAshZ
uUYVQLwWb8Cb8K72MnaiNdqJxe3EynY/5yJPGRNVjCMElSO1EYcplBefHT+NjN5J8xX/Db1f6/k3
+0/C4fM7OUc0VtNPMmGOuUb55LOTyqfAffIz4Hnx8d13Pvb4Hbf/FI5SvlBeAtXAhv6rUQ4qX7z7
xhvv/uHdd7CipHQztyKL4qo9V84vh1XO8pxJsNFZmzPHvtR+hbAtU9LVJDZb5kSD0aHbFA1OExRr
apJmzNd0OH+pbX+zX7zh+lKrnv63spLxu8pK6Z5NWl/SotF30pcuFZj+jcKUBu/FCtNl9bVPds+9
qXFwsOm53lc+fPH6W2Y83NSyrvGePbB654eXTZ1RUKSUsv9cn2hVfq98/srhKVWpHXm+N0k91k3q
MbwWvBweT9f4yjLH5Uyjm3xTMqfmYAWFhTbGI5sZYMyuZUWbQ9VIvnOk+a5Kylm5XVVp/6OSQjZv
CxxRTuyX6CdmfBZB+HcqykUp4GIZBYRs/6muGpz7f7p/fXJWXe3exfNuaECF1GWbpjz0+HW3zXxY
6Ya+pkZEU8y3/rmpsaWosGzoebgplPnnF196o16L4PRaRIDt1KDsoExWxMEQ/7KguD5JsrCiMPK5
AW0jBUU5ZEefAxp5YjieTJcn8OIJQnmfqCNUTJMYDc46QvHGFdlGdL08DE9R0rU8Ak80+Kcq6u3M
+HaWhlFZrT5xRIx0SbKj10olzWPmPtg0ONj30/bRpaX0rZI4vWbor0zykXlNLI9nf/nwx/Q7zCaq
AsyS53JQ9Duh118gluSVi9V5teK0vIVs0jUrOCc6u3w1u9LVmdMd7Sl3bGEHbP05m4v6w9eDnaZr
fTuKfgDu8hsos6eYyaavzEVhBGMiN7dggqoTyITs87xhAi0GzRhcYWyMYmK5YmKzYn+cxGQP0ZI8
ZAOgh6QcVMifforU62Yd22aiUxPdxE8FPTzJoHozOL21Tdtt5NBiTzrknNFDzhm5kOD6Zq0H0REf
iLM8Cds8aSXwPrKc22OkaXC+dUB2BITD0XRcTktZ6I08gao/ATai3ojHCtNtfx3Jaf3Vrbb+3S76
ndT7234/RWp/r3vbjQUFK4uuit+2tWrc2P9e0f1qndTwu8VLbw6XLIxdFb66vh7U3vnS+NAbk5pb
5tTm5npEj7lw9+WTt5RFK0eHXo43Nl82ORRyGT1SduNUtNYThk/AFHsv5af2yrVG1seGWdpg5SeY
DBLr97sTtNicNZAFzdSNWYLJStBqJQtkJSzbSpbJ6pMEHotdPK7cbGTDJRG8NF/Q4c2n4c1nEmmI
nAM/qqCmYN5N9l3uzLxQ71LxHbWeLteqt4oKdcORKlzjeq0C7151Bs930itg6v+29x1gUSXN2idN
IicViYMEQRCGzJAECUpQkKgIK2nAQWAQBhBFSYq6iDktZswBFQNm0TVhFnfNWddddY2orJG51c2A
o8vevf/z3+/uc5/7eeSd6u7qquo63dV9zukz4zzefuO2kpL95MS2Yq5u90FhtqndlZTUtHafpiKW
kr5tjUvb6KEp1pbm+jzU6+thDRELY747qe+jo8zuyRnLoSlWNx5Lsz9LieR2fVO6tYtg+tzHsD2Y
/mm1RsnD6JOOZUSrj6PCzRG19njavlL763sj3I5Hl9zOZbf8RnWHn7kdcyoXuRZPdFwsgtuxUAPi
LY4k3Mk9vnkW9tUd7HbX46nOU75Oc5Y7XWHbgqYjE7t/xGbx1qP7NfT0YyKC6kL2F4eEX7lAXfo8
MbrI2sYy1IPuDz72Qu9TgI/ZRLWPrwVjxXZhhOxAJojNtmIJWT6sIaxEFouthx7h6tEUbUn0pt0I
VzqYGEDnk2MprnyjAoviUiR66eKQjxlPw1WFMCAyiLEEQ1SjjQo0rU2L6HyaoQ3wRsxyDgzRBJhR
Etr3iiruU4D/6FG1/GE9U9LmeaCt3xkyjoSe8HElk/BpMl0E1sQQBJiaQKgQLXsILjhXvrGz5cve
Rfxq3hufyXgZTBvSNmQfyoo2ZyxYZlxrZSfSg+VPhrBiyaHMMFaschaVzKRyM3ipSqOUi8jxVC4j
5Y7j5SmNVTZSQc3n6LFZbIKnwaN4HRsUlNjRnXsTwAHqbGO2HZsm9HCEs8AdaLqahlo/NYkaTbDR
Gh6vNDv2MrHxLmu8tMR70tgV8k3NDjiCyR9Xf72RAf20FGndsZlBG1ykzXZpu7W57V7bg7q260fP
kj0WkUY/IlfRCZ+Qu5bRSegPjSdPONel4DNl4p7PNJ6yPqlD63D0eb3p3hxPwoN0op0YJ7YTx4Pn
pRRKhJD+tD/jz/bnhPAGKcWR0XQcK5oTx4tWlpCJtJiVyJHw0pRN1SmC248ScMMoH+54Kgc6tZ6S
shJ2Fr6lQusxLIakWDBg2MxYJh+5igGaZFOqJDhNmWGUcLfpBd2GDUZWo1eO0Neg+KiOUGXYFEMy
ONIz5eg2SIID3t5ijfY64FtH+GvlutjqYNK508GRZEqfwVL68A1yR1v4M9KD9LzZFkTWtUVSfSkB
+va3z9eRd7xgTYdGAoeY5uPL4P3b4exEdg6bzaM5rJ50D1YgGUQPJWLJIppHcVCfYOkxNBNEBDIU
QVMMi1KhRpIkSdE009kkNBKC8VhgEdU8dR5JM9pMACNi8sEv5VyNX9rbg5tDdNzJkY+DQ/KNK9rt
I+Gz9OSFNr8zZCwZxyR84JAXmd6fjtKeyPYEWB09ANt5RIyPezeuO+3MDaYDuPF0FDeRW0LncJU4
HNobOinF9Sa5DJemOByG4k1XNlbupzxCWaJcosyiJiqhjXS/wIhEL/vK36OQP8QwMXFGuxy6kSb0
g09jqarPFXT651xqWRXtvKTyU/s1NpStYpThnGvvomkI4OwpKugbegg7/F6gjvzBPEyn9KqbNTU3
btTU3KTm488bN/B3ZXky46mbBE3o+qiQUWiLBf76RMouQXGjBTP+kwH9C+WJ3l6XPaMfkpX4vpXt
TkoXpjv0FVnbeSqu+FUNVfA/iV7/p2AuodDuWEf0zjdpjR7JgE8rv2979YZ+SNmB9uXwKcSS7GCp
CZX1kDRdEEXpdoihQQxBkWCQoij8vV/Ctlffr2brfG4GYfifsfxIJapJE3y0kW1UBLWFNoYjiE6n
K+jNjICZxXJmPWY9ZhdwenAiuDbco9wnPAveKF4N765SkLKt8iaVSlVCdbZqi1qM2gf1cvVTGr3h
GA2x/o5WibaJ9hWd77uJum3rPrD7qh59emzUtVU4/HX9ewbqsfTm6gfpPzDIMgwzUjPKM2YbLzF+
ZKJqcryXxNTZ9LlZlnmK+SOLGovW3jMtjS3HWzb+C447/4LjffthZWQV8O/j38e/j38f/z7+Lx54
viUJguMOk7QDmyC4pA1ceTTIFhPqgLaEBmEmOwdoI7sP2BfyNQgX2VNAV1kGoBCXumP0kG0F9JRJ
Af0xzzDZVcA4TA/HPPE4JwFQk1CXTQDUkCUC1sumACKNZpBzDtBF1groCvlmhBumhbKjaCM3LvUE
XWZErAy9BT4Ulw7D+XFgpxloQXQ9xp0YG0COOWh8CqhBKAFqYtoVZJrD0kSJsMB6LXCt3sCJUBOj
K0Z34O8NbWwF9ATailBv+xlQE6MhyLEijDD2gqsFK/DbYkBXwgjQH9MDQY4VEQFoA7ruA9YD9sVW
9cX29IVarYQd9okdYQE5dkQfjH1hNWRHOGDaVRYDKJTNBnQHyXZgD+IfhnPiMdbjnAZAB5B/H1AT
I2qLA26FA26FI26FI26FIz7XjmC9DqA/pgdiRDY7YTlOWI4zWLgYEHnPGctxBv6rgIjfGfM7w3lB
+fGyk4D1mL9Btpdwwe11we11AY0IXWRPAIeBZBfcW1yg1n3wnXrbbUAN6GmuYCGiDWVuyKcYkZ9d
QcIUQAvQ7gq+QugA2l1B5htAV9DoCrZBfyUCZdCfwEKEwdDTXMFOREdjaTGyUMChmB6GMQ5jPMYE
8LkrtCKDcMP2u2H73fD5EmI7hbj/CLGdQrBzK6ARRjPwkhD3ASFoRxiBcSjOj5c1AqJe547luGM5
7iAfvbSA5LhjOe747LhjOe5YjjuW4w72HwUcihFJc8fSPEDOVkALsNADPIPQAaM/Lh0I/B4gAeFQ
8LYH1EX89YCe2BJPkCAF1MQ08rwn9rwnWIJ4UG/0BGmIZwCcBU+QOQEwGGM42OZJDMEYgXMiMR2F
6WhMx0Bf9QTtCIfhnHqQ5g/0S8A4sNYfrHpJBOC+F4B9HgA5H4lAsO0pIOqBgVDrKTEQaCkRBNeK
noAqMF6CCFXo5UE4zgRhrwaBhCmAvYhswHiQH4R9FUQ0AGcI6H0KiPSGQOlTYjDu54OhXYiOwIh6
cjjmDMec4ZhzCM4ZgnOG4JwIbHMEtjkCSl8BDsd0PNCRuDQSl0biFkVjn0fjdkVjn0eDb28C1uOc
BogksVB6FRBZHgv5iG6A0ToMpIUCotJhIBPR/pgeKHsOGIER8ccB515ApCUOOBHtj2mkZTj20nAY
KYgeAFqGg4RHgMGYjsA08lg8yOkPiDTGgxxE+2M6EHTF47rxWHs8rhuPbYiHs49oZEkCtiEB+FsB
B2AcCGM2AfMnAD+iozCNbKvH/b8ez0T1eCaqxzNRPZ6J6vFMVI9nh3o8E9Xjmaget64ez0T1OLbU
45moHs9E9Xgm2oljdQO0yBZQE2N7jiv0kwYYnamA7tCvGuAP5cSA3xrA95Z4/rSlbDt/s8iB6Pih
KJLgQKqdpoA+LKdpyN0ipxkFHhZ6Z0hOsxXyOcT4TppHqBH35LQqGUq8kNNqRB/KA/1aFUODLhVK
hGkW0BpUPqbZOH8Spjk4fxamuZhegWkeSEql6uU0SajR3eQ0RagxjnKaJlIZdTnNKPCwCF3GT06z
FfI5xIdOmkcYMHlyWpVayMyQ02pEFKc3ppUU7FdGtnHGYVpFIV8N0ZwqTGsg2ziLMK0NtBZnPaZ1
FPi74Ta2090V8nviuvswrY91tcs0VOAxVqDNMP9JTPfF9BVEcxVs5irIV1HIV5Hbv57vIBC48QeJ
U3IleZI0Kd9PkpsjyU2SiiXZtnzfzEx+hDh9pDSPHyHKE+UWiFJtY0S5qUnZSXxxHl8klo4U5fKT
+LmidHGeVJQrSuVLc5NSRVlJuaP4ElSikEzrWgtfnM0HMfzobLEU6kdKk6SiPH5SdqodCJBgBSmS
/GxprliUZ9spwb3DjAhRen5mUi5K5yFpzrYCB75lJ5/VoCQpyCjk+yXlgoHDJPn8rKQifn6eCJRC
E9Ik2VJ+Uh4/R5SbJZYiA5KLsDkB0aG+UJqLEzm5ktT8FCkytXCkOGWkQl34FGenZOanorZL+Kni
vJxMUAD2Qy0xMKQAlyhbasvv0C3JziziW4qt+KKsZFTpi6jsDuYuLcLsqeLsdHB3HrgjBXlPQTv2
o1yWBzbAUgxapKIs5OpcMWhNlRRmZ0qSFJWCzUntloKjOz0uyZfm5Ev5qaICcYoI8YwUZeZ806CR
UmmOu51dYWGhbVaHu21TJFl20qIcSXpuUs7IIjukIs8OJikJkUtkEUlEJoSrIkglE0WkKiHCPzvz
GP6+lEcSUvjMhhCXBHmpdA1dTx+gG+FvD72X3kSsJ/gQfgRwuAE1iBATKcAnIfLgLw3q8gk/LC0H
YxLkiIHKJmyhxBfkZ8JnBOSlEyOhLA+nRPApAu4CwFTgjMGpVGxHEvoCS8wngk8p1EJlfJyfC3Q6
LpXiXFSbDzTSmwqpLNyGUZAn6azTdWna/1NbkEXZWBayhg+TcTa2rV1/uweluFV8uS/t5BZIFFqQ
Aql8KEUWiTG3bRc2uP/JGxG41fngSWR/R3lep23OIEcA54gP09Gf5VlBHrKu3Y5C3EYkp92Dw7BN
fOybIvjMx2emvaXtZyENa5HilqF0Dq6Xhdvf4YFkXLfDOwHgn1A49+11cxVKcrBlqaAlBUts92oh
1pUC2LXe9jTiTQEf5ONz2X7eJYCpuDwHe6eo0//tusRyCSlyWSKMqGd+225UnokpS6hlhXtfFrSr
Q1NXVmX/SfJ/3UdfpKdiSeny3p0n7x0pnX2v67Z/6Y9f2+Wh4AHUkva2SLG+jl6N5Le3NRVyCnHL
JXiMdN3Sdj8nfeVTkbx3f9vHkVelwJePayJrC3BrRJ1yEGcmcPznZ2gk9lwO9HY7OArxYYs9+nXv
tsU1s4BHCi1CLUzHbcwBCUWQ29GKPEIxKqK4J+5M38NRUvRV1BR9FRdxZGSMGHsmhBnAeAEKgTsJ
2oa8hqKpL3Dkykd3UscPbBKwDh/TxS92ta8C8cqLIGWy9l8ZhdUfQXQn5L8+Su/EL/5+WUsShBJc
e7sQZGaSNBvqwronNGogn+geETaITxiALhnWqICd9dwghHRdz0ihBtn5SRJUpiQlk1DDqIPlkHJp
FFrbyVMa8k8LtBYiGHoq/T1dRU+DFEW8Jz5AkTHJxykuQdLVWIpULk0uT19MEFgD/NNPEpTrJ7B5
fSoHVv6hSnKo5eX6gyErmCJJe2UBj82yVqMpPRYhSGIrWbNJhix3pUhmeaRgiMBGIceg1qjUABbq
6AiDUYb6CjqjqHd5o0NgoiCM0Xkr1DkRuH7OjrQny0I9prrXe8x0m7W8vHsfQTmjJSinPiyn0bek
qMMCvsrTc4pms3drytM7PgLVTkvRSluQY28tsGLT0Yyydi8/SU5RLlrH8S1TrPj2QqHrN2sxW3sj
gUE7c7cuV2n2JgJjVE5r634pj5BIpHzffOlISa5YWiQw6qEqdBXY2wsErgL4F9dD1QH9qqy9PPkP
WFRO9lJ0C8ki6HJSnYB8JaqcJIn11IHDOb96tAzWt1y2YMx3gie166vNR7xrmxe6clfbklq+d/GQ
2kW1MxIdRjX3Ty16vqngZNT1lt8XVxrMWDYxbfuxUWOTTS8bet5WJ2c/mn+0sW9aTc1Iix8uuNs0
quwcanE48Dclb7f5NustheueBlX0fzBRfV9NZnTSpvLiFYl9C0Mf/7Aj1aMm3MCea6azbP1vs6x1
f/VamKKTOJQlWmboGjH5j7Uv5lLH9X9qjA7YPrW00f1p1NzBmz+vHZslHbxF98x8nqUJETszUey6
L0SL4xkjG/5xVZoSd83FspjYFw0e33UvK2Sutx7cXDqvbevZkstr9XLjPU/tf8ld2UuwnT3p5HZ+
ofakOxT6bYSVZesEZasFZbXgTUOSKasRlC0o1Rh+IeeFOHep6ZAJOtsGTZedXpH7P3/+yv+mj9Po
HM57pHyo+vUCXednu0mzq4War+MTHZYtVT7tzZo1ZcZJ919NWl7GzrHZuXxAU/KLT1fOeHjErXeJ
EreZZfU7eWbDbVbxLftqr2UaORn72rTCdMWHPl3we6AZxw97kjxuy4aeTdau5n0PilZofW+unrLy
jyiD9yYnL3d7HbEp28+B87m8x7uH6ZmqQ1oPvIo4ceC3o4JPfHveFMN5VnqDLhlSq1+V3qV3DH9T
f6sp9rko6EREVMMO2lJLNvPyS+6MCbsXHNvoavPL2F/WFT4oWE5cyOh3+KLL93d9tdY5Z+hn3HC+
97MB88u6AKYpztEte5CBavIupdppP12K6hd41iB6Tc4NLffJc/KXrb24HKJCoqCcDm2PCkq2GzVv
hsvil5w+1BFTDP+pYADj3s0B/kEEcIBgYO8ASeeOYFCEIygIYWtT0ZH22gJNlOBqK8Um5Y2Eixwp
qNEQqKFMjjYnQpSaJclO7TBM6a8MMxWYtBump1ieKuJHitOz0aVTuJ/v30aFXUXjLydsDxCuc9pk
f/29uXNQ4aGPxktPBIx+0Rz46OdpR0aFRiS/+YE6MuhqUKadmbeo8ZzpLuWBu0rybwUc2DBDLfyY
uXXL8t9UTY2bfc0+JP9wvmfA6jnBxj+c3W7X60hw32LJtW5GHtOEGsJbB6zepHn0JR1kbb0HrtmZ
SU5e/HHvtpSS8vfxy8smTpq+tWX33JXn3daET+rRe/LgW4JWwuvN8fdeZQcrn2UK19o6te6w3aI0
PnnWmLTFC/NUK7e0HH3N3xOmVZ1y2uaaQ0DP5/uC53uER+qeSxtStKFuclOM97Ly8CnZrHrnw+PM
DkSkef0w+Iz1BMfsiQPYzUsvBFdS2ZXEqkOT70TKo8IHQdkfAm0UFMwZFYESmwsTGovFoen/HaFC
HdmoTZIyhiWg4UNgiDLUmO6MzhnDcwVEzvAtr64fHVwzxN92pX/KS4EyKlZnGBhGlQpDB8eYcRs3
Twi2aDm3f7C0dmhvaZ/87ZWfN4bOHUMMenzqd92b4mNqtcWvKb/jpyafeRd55sdlB2IkL1P81/sT
z+c31Vwy2K28rKfq3CvXjeqsxr94tiZv04zbwuleCzP2u2VdnLLF9POdx5fFvFlTDrTdI/Y5vf6j
+L2Gli3rd6v5c/qPshy9y23GXY7qyYSRZw+U+o5KW7dv177pTqdaaI3isW8v3u1/Z1zbvXub2lrv
XFLdnnN59oOwBrfa4r4/e91wUk52pZaVZZhObY1PmbE1bp/wSuK06Il6jm89Fi4vV6kdUbXdZteK
1ac3Xuc3NAp6TuLrqPbZH/HG9+53ggezLcWTD+fcf71247nS/rkFahBjMiDGRMhjTJL6mEHti0bF
ccSCOPMPjuqOgOMoEEDEcYSAIxAKHFDSESUF0n+JafJy+i/K/zbW1N5Qqj7/4+GgRWc3uDvVmQ4b
dSPzoEmvXXObnmxuPH7J4kcHzar91xNsPrrEGHWz3jxD9ZbOymzL0JLu/Xw3VfvUB05RvVY2t24B
+0Ksf0H8k1ef1O6XSFc6npY+fPEgacUEeleA7JK31qWtp75TvTCuZZe26qfEDMtJ+dN21e2f9KjH
jpkH33ZvSE54pnnH/bnJ8KotpXlHAh7Mm1qYuOi3usLDrtWOOnbaN5JPbtZbH7Ywve5nvlAw+m51
euD94wZvVMOlvnaPWGYZJqOCts4+uk14ov/qrHjd4I0zrkyv8B6jNODqqm0TTY/cbxmXVh8sPWDh
G7I4SSdxsKCp/PUF5Zzi59GDCi9yowvK5LHmnaDsLfa9oToasTAI2YcUBuxrE5/pxUPeRYUsfNjj
SkaFE8vW4lHXoQnFCUNTRlfQvbTrYe6PGIwZL4GHQLjcdblzpaP8PlZKbuY397FyRolRrp387l+e
nV8kdDRbyBIM7FAJ6xBPgbvArSMtoCpt/vLGGBYoylWQJP1mAOFo4xMriUxfyq9wItV+7RHiWff7
1bKS56pF0sKwBQN0XxPdxBNuJM+s/Zy+YvEvllYfoq/80Bbe+B1v+541z8pfLzSSDPvw9tU9lZ+q
uN7de/CbD+0MGMC1SIzlhcx9yT2zd1D2y/sDtSydq0xy74xo2CLWMpv7/LET78aEbMlspYhTfUKD
NjjYVD5acSbBYv9+z7vDt1Uo73U2CJsYMEC2b+6KYZz182+NORBbsnrt4DMtdYtrfO+fjjfzvlni
NGBw6/mmcUt+bzi5OEUncktdzYsrjeeXr9g479RY68k2h05c+5RJX290q3vVHN+zh/qhP06VrtHg
6t2aafrb1hWh3k+2alqMUTtss2fVqBMzPCHaLIFoM6kj2gQVP2t/IPHPRZsocZYoT5qUlaMYbVwE
QnsXgb2zswNe3tjjpIMAJQVla/4ltvUWmLdPlEbZfuIcdKfWPzKAHxA52N1e4O/W19nNybWvX/9A
tw5GWtvoLxoRKcpF93b/NkA92ctKabpWtHmiv/fq7UefhS41uyMsMOJddggeOuai9bXVnJkvfvP6
eMCieOXHh+MnOJy/5lUldG15d9XDqfvPs8s/Oj0dOSlXb8bd3aF3d0967ahEHa4tyHMOTXi1617w
eMPdc8fckBlN6tY/cPS5kt6xWs0VYR7nP9xurXrWj3hw6XbS+x7VIavKPN+KfZ7cm9rICdsrHfdY
5eGAJxszX11KL+O+635qvPa+vPu80A/JH58tF9a4t/2u2ZRklDz0qlJUxSWPkJD70QfsEvWmz2b5
XU/4vVzJdAFvOcteVDVnsJGvSe3smZ8D/AMkzvUBrnXi9aL3Tn71PX70EN7TmNaiN/lBVLixxxL7
OsUA9SUgTch9adsvxuqu+R8jd5OfQu5NOP/A+6vYI3k0uN+CPU4bQypn7F/8ZJOHr9/xC/9fsUea
l5OS9N8SezokSbuKoNw/ReEuApR4bDlPpXvz7fOBU20bm53GlpX0tvTt8/onk9lqC+pGRH5n9f7Z
4ajgdeP/0L6grPN+UEtlNyL7QYWhZcBaG6HDLUmNa9xz04gZUXR1v7WLU91aXZp0/BrcvReeVD0y
uszyddpa+/vxCTPeR0Tci/99zswlYl7o1ObmglAn1Yx7xf5rrYdXRJUEmPU0P/p94DHzBz1LxVY6
rT2Ov+xlUxb4nfWb92uOF3qbSt6vSZ00vTZZdX1fo3UPZ3qXyLZO/7Tg6avPzJazQefipJs+vNY2
1heeW7nj8v43O5431bXEGH30fNV0uY///sbF/can6Z7dxk9ROuXjJXLoWbxtt9dhi4GDe/X8IXua
4PCrWV8HKI0M5R/CDhHmGzVvBBgPHZte+22Y+mcuvuTRSeDk5IqikxCS/8DF158C59/Fm5uu2R+3
NPUPHq3bdG6gd+ShDxt19to47NMKi2iqeObteC3IfrZlw6zUu8bhE/f+GNJcwnr3Iv9g1Yl1lzaL
c9LG9E571LDrxaQ9Z59v+Ky1SnlYLyu78z7XYhj9gp1ZqVnBUTduvbrduKziROmdklDKde7bQ0u5
MUYjB5y9dqgg3m58gzmzI2Z4hkGKrLTY8/klxnyQsFDKSfgx/mqlq03+SbUnRkJecUHbkszssXef
es9YsHS02og+YbrJiQ5LL1YMtu4VPzKg6rbdRI3wbe936lVnPjdfpP3utMaVSWpvygvyXI7PG1t7
JpH9lLW10nHXu7nDJ/pOHDppbvZWY5uBZySL/e5mPCqxmD6qPd6Uk5bgEbOuR+j/issvDTZPfgO0
G4muqQiF6NllcOzZWUGHYlSMlIhIIp9IJvwI368vzf50XddFgJo7SNP+x+LwfZrTVyRxSLVpOQHV
L/KiDvTjsfrKdg+JnGTwTDhr18oY5dvTGjz0mz9uWntyV/0QE30JVzxhFF3bK/BZ5o6s4l67A3+a
+Lpa/SDne5fDv094nJMQsGz2xTPnbk0/dK+xz9nipyc3O1yavOd0ylGXZl2TxoLbHjXb9fOWmky5
umOHVtS0N4t/FAXXWFosTvxe3eOEtmjMwH3n6yrcw7YmD70tePxYaPhgast1Ydl7bZNpqaUpbGZ+
Sw3lZzcucMpeGXVN9D749nVaOmc7K1vlzJKblknFA1/1WKxp4kYZTN7EPjbfYfdDn+ORXgfWT739
KM21+k2v+YvPbC2MGuJ+Odd/m2mrfTmzGoLUCookBWWT/8Grsq+uFb/c415edkGg03m+LUl7Ds3C
zyhQL5CfTB5tr6J4Wx2s+ZJStlcTKJZ2E5h+qcjYQx8rXdRUzu+de/DXA0WFd6Ke6WfnlXkI4hSq
qNiHCoKX80uN/vPnmyssSs3+C0+6+d8ENaacJHTzdM4V2XifOWEuHS3YWVXVbN2/rXufC5XeOx7Y
RrqteTv+lhvdf8SIBEt9/Vm93pYnL2lzqNhurb+s9khCwxbfg88+fZjHuNyKcalYp3a5u8flDN0U
6eTXGXveOHv1beMISkoWu3t9iP/5qX+i/6n40Pr0GbNWrF/es2lqqFbvj2Z9romLCh9PXzXssu5j
swU+Cyf0M8saLya8Qs9XLRrab9Tv22InaYzKe5DbsnBhIRUeT+3WsW0mHxYt1mH78LYzNk41u+M+
WExccK1tJ/FpLGu9SHdP6QSrXe5Ro+cbOac9jbmsP7e5cuW8D2HVqd4WWcETikz6V6WEFKQePhVx
/Y3+9ojRg94eWLSinDIWlFP6X84M276cUoEs7v94x/x2HvrqsoIj75jLEwS6iv1P+cuzHxJ0dpaw
7NVhgnWzFzii6VTo4Bz3p+63WisiX/zTuH5LaobfWa+daei4enTeN5EKdZEx1jNPM2YuA1ZEbV9b
8avB+5TmI7onPU0P2/D/uDLdZOmWCR/Ol1snzMm/pFxTHdc615D+fOO3yS5Kk/oVON6qWHQ/1ngt
19rHdCLn12Mtg+Zt2U2VW+atTZg7r3/l2hJLzXHNsqLSvhcZ6pcR5j/l+akEJ1hYutqPvHXl5jGZ
V/RSzyc2OoY/+/bdseH55iPmhybvSI6r1tzhUxU+QOfo61vWL5TDDj6Pmaed+VNPFZfj/DQR++1C
U8PG4UeaNlwwPpFu/u7nY8uIQzvm3xfKni/ZlNH7Ji+2xLLbs9bj8RuEi7qFzQxrZKbeVOcsOGpp
crublsqNmNWzfp06556yxbFe9IvyotkZdb10gsH9/wFpnva+DQplbmRzdHJlYW0NCmVuZG9iag0K
OTM4IDAgb2JqDQpbIDBbIDEwMDBdICAzWyAzNTJdICA2WyA4MThdICA5WyA3MjddICAxMVsgNDU0
IDQ1NCA2MzZdICAxNVsgMzY0IDQ1NCAzNjQgNDU0IDYzNiA2MzYgNjM2IDYzNl0gIDI0WyA2MzYg
NjM2IDYzNiA2MzYgNjM2IDQ1NCA0NTQgODE4IDgxOCA4MTggNTQ1IDEwMDAgNjg0IDY4NiA2OTgg
NzcxIDYzMiA1NzUgNzc1IDc1MSA0MjEgNDU1XSAgNDdbIDU1NyA4NDMgNzQ4IDc4NyA2MDMgNzg3
IDY5NSA2ODQgNjE2IDczMiA2ODQgOTg5IDY4NSA2MTVdICA2NlsgNjM2XSAgNjhbIDYwMSA2MjMg
NTIxIDYyMyA1OTYgMzUyIDYyMyA2MzMgMjc0IDM0NCA1OTIgMjc0IDk3MyA2MzMgNjA3IDYyMyA2
MjMgNDI3IDUyMSAzOTQgNjMzIDU5MiA4MTggNTkyIDU5MiA1MjVdICAxMzVbIDU0NV0gIDE3N1sg
NjM2XSAgMTgxWyAyNjkgMjY5XSBdIA0KZW5kb2JqDQo5MzkgMCBvYmoNClsgMzUyIDAgMCA4MTgg
MCAwIDcyNyAwIDQ1NCA0NTQgNjM2IDAgMzY0IDQ1NCAzNjQgNDU0IDYzNiA2MzYgNjM2IDYzNiAw
IDYzNiA2MzYgNjM2IDYzNiA2MzYgNDU0IDQ1NCA4MTggODE4IDgxOCA1NDUgMTAwMCA2ODQgNjg2
IDY5OCA3NzEgNjMyIDU3NSA3NzUgNzUxIDQyMSA0NTUgMCA1NTcgODQzIDc0OCA3ODcgNjAzIDc4
NyA2OTUgNjg0IDYxNiA3MzIgNjg0IDk4OSA2ODUgNjE1IDAgMCAwIDAgMCA2MzYgMCA2MDEgNjIz
IDUyMSA2MjMgNTk2IDM1MiA2MjMgNjMzIDI3NCAzNDQgNTkyIDI3NCA5NzMgNjMzIDYwNyA2MjMg
NjIzIDQyNyA1MjEgMzk0IDYzMyA1OTIgODE4IDU5MiA1OTIgNTI1XSANCmVuZG9iag0KOTQwIDAg
b2JqDQpbIDM1MiAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg
MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw
IDAgMCA5OTAgMCAwIDAgMCAwIDAgMCAwIDAgNjAxIDAgMCAwIDU5NiAwIDAgNjMzIDAgMCAwIDAg
MCAwIDAgMCAwIDQyN10gDQplbmRvYmoNCjk0MSAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2Rl
L0xlbmd0aCAxMTk5OS9MZW5ndGgxIDUyMTcyPj4NCnN0cmVhbQ0KeJzsfQl8E9X2/5mZ7GnSNEnX
tM2EtKWlpUlb6EaB0g2wLKULtECloQm00CW2KYuylAoUyyaLgLhQ4amoKEFQQLbiCogKuD1REJ6I
oFYRFZUtvzOTNA2ID/r+j/f+7/OZ73S+c+65955777nLzE3SBAgA8EXiQV5WweCBZ64tOQ1gzwPQ
zBiYlZ0DEdQugM1mTBU6MG94gTBJnobhuRhOHlhQlHEm7FwEhndjeOWQwoJBo2KMfweQFAJQrw0v
MMTX5T/gACBQB2Ujs4YW236aUQ0gVwDwT5VXm6ymkU9IAZrTMU1d+RQb3TdniApgGaYnzk6wTqxe
++rI+QALtmH67yaa6q3gD2IsD+2DYmLV9AlprR8cBVjRBiBsrDBXT6PCNzwOoLoAUJ9XYTGZjxtH
nEdbYzF9YgUqFDrRmxheieGwimrbtNQwfgsAmQwgCqqqLTc1p8/bA/AY1kdYU22aZhX0F2DbiR2Y
nq4xVVuEsn5PAqy3A3g1WWvrbY4MmIb16cXEW+ss1qCfHqoEWNKK7U8Exrd8vrb7mfLqcd5pv4JG
BAxe3L27hrm+FZtdfrXs2gqpXVQBJLaLBCcwn0h6PR/LiMD4c1I7yIACT4xi0lCvQqIrDwkKGABF
KOj43zk1PB/iYeCDiL+WnwAxRDh7HUK1wjTyWRGQUgGP4vOkJO8pEDjSgR7DeJTJOLSAptE6Da2C
0OslcEgkJV5CxTomjlfKP8q0FAgR2zgs5ojzpCJgE7WJiIP/EQj2Qs6dpBN+T+jvJB3vfejulq9C
Ee9NKO4I8xWQfCc2qEl3lo4DBw4cOHD4/xPUqwQRHGwk7jxHmFvycUuYnU8AdFrp8W+pHAcOHP4a
BBAMwAt+FzlABCLHddybSJAlLEtBiuwFXsgykDmugRzkyN7gjaxg2Qd8kJWgdFwFFaiQ1eCL7Muy
H/gh+4O/4woEQAByIAQhB4EGWcNyMAQ7LkMIhCCHQiiyFmhkmmUd6Bx/QDfohqwHPXIYhCOHQwRy
BPLv+DzeHTkSIpGjIAq5B0QjRyP/BjEQg9wTeiLHQiyyAYzIRohzXII4luMhHjkBEpB7QS/k3pDo
+BV3XQwnQRJyMiQjp0AKcir0cfwCfSANOQ36IvdluR/0Q+4P/R0/QzoMQB7AcgZkIGdCJnIWZDku
QjbkIOfAQOSBLA+CQciDYbDjJ7gH7kHOhSHIQ2Ao8lCWh8EwxwUYDsOR82AE8gjIR85H/hEKoAC5
EAqRi6AIeSSMQh4FxY4fcJfCcAmUII+G0chjYCzyWCh1fA+lLN8L9yKPg3HIZVCGbILxju9gPMvl
UI5sBjOyBSzIE2Ci41uYCBXIFSxXQiXyJJiEPBkmO85DFVQjV7NcAzXItVCLbAWr4xzcB3XIdSzX
Qz2yDWzIDdDg+AamwBTkqTANeRrL02E68v1wv+MsPAAPIM+AmcgzWZ4Fs5Bnw2zH19AIjchzoAm5
CR5EfpDluTDXcQbmwTzk+TAfuRkWIC9g+SF4yPEVtEAL8kJYiLwIFiMvhiXIS5D/AUthKfLD8DDy
MliGvBxWIK9APg0rYSXyI/AI8ipYhbwa1iCvgUcdp+BRltfCY8iPsfw4PI78BDzp+BKeZHkdtCK3
svwUPIW8HjY4TsIG+Bvy31h+Gp5BfoblZ+FZxwnYCM8hP8fy8/AC8gssb4JNji/gRXgJ+SXYjLwZ
7Mh2lrfAFsfn8DK8jLwVtiFvg1eQX4FXkV9FPg7bYTvyDtiJvBNeQ34NdiHvQv4MdsNu5D2wB3kv
7EPeB23IbbDf8XfYz/Lr8DryG/Am8pvwFvJbyJ/C2/A28jvwDvIBOIB8EA4hH4J3HZ/Au3AY+TDL
78F7yO/DB8gfwBHHx3CE5aNwFPkYHEP+ED5E/gg+duDJ8ifwKfKnLP8d/o78GRx3fAjH4XPkz+EL
5C9YPgEnkE/CSccx+BJOIZ9i+TT8A/kfLH8FXzmOwhn4GvlrOIt8Fr5B/oblc3DOcQTOw3nkb+E7
5O9Y/h6+R26HdscH8AP8gPwjXEC+AD8h/wQXkS8ivw8/w8/Iv8AvyL/CJeRL8Bvyb8jvwe/wO/If
8AfyZbiCfAWuOg7DVbiGfA2uI19n2QEOZMB1FKgdYrEYKIrHu/Pbgsgtid0SH0DAnG5FF+xx4MCh
q5BIJMDj8fh3nqNz3krcEk5YgYCbtxw4/IcglUpx3vK7MG8777JStyTEPyF7caEL9jhw4NBVeHl5
MfNWcPuUHei8y3q5Jde87bwVc/OWA4e7CJlMBnx+V+Zt5122c97ihBWJPOdtF+xx4MChq5DL5Thv
BV2YZ52zVe6WcMKKRZ6P0Ny85cDhLsLb25uZt8Lbp+yArDOvW8IJKxZz85YDh/8QFAoFCATC/8d5
K2FemL7pBWYOHDjcLfj4+DDzVnT7lB3ofDru/IQdTlip5KYXmDlw4HC3oFQquzhvO++ySrckZd5Q
8py3XbDHgQOHrkKlUoFQKBTfPmUHFJ153RJOWC/pTS8wc+DA4W5BrVbjvBV1Yd52Ph2r3ZIX80aw
59a3C/Y4cODQVfj6+jLzVnL7lB3ofDr2dUsy5o1gbt5y4PAfgp+fH4hE4i7M286nYz+3hBNWLvN8
yYqbtxw43EX4+/sz81Z6+5Qd6Jy3/m5JznyA46Y3hjhw4HC3EBAQ0MV527mrDXBLzJzl5i0HDv8p
aDQakEikXrdP2YHOu6zGLSkAfBSeL1l1wR4HDhy6ipCQEGbeym6fsgOdd9kQt4QTVunj+ZIVN285
cLiLoGkapFKZ9+1TdqDzLku7JdzzqlWej9By4MCBw12DTqcDL6+uzNvgzrxuCSesr9rzjSFu3nLg
cBcRHh4OMpm3z+1TdkDbmdct+eG2189z66v4d9SNAwcOt0aPHj3A29tHdfuUHej8evzOr+cNBAgK
9HyEVgIHDhzuGmJjY0GhUPrePmUH3D9XAbFuCZ+dQzSeL1SpgQMHDncN8fHxoFSq/W+fsgOdd9l4
txSKj8+hni9UdWEd4MCBQ1eRmJgIKpVv4J3n6LzL9nZLNEA35nQrurAOcODAoatITU0Ftdpfc/uU
Hej8SbsUt4R73jC95wtVXVgHOHDg0FVkZmZCQECQ9vYpO9D5U4oZbikSH58jPR+hQ4ADBw53Dbm5
uRAUFNrt9ik70N8t3eOWegIYmNOtoP8ddePAgcOtUVBQACEhuog7z9H5c8r5bikeoFec54b3jn5L
mQMHDv8axo4dCzQd1oVfSh3mlsa4pSTc7OKZ6lZ0Bw4cONw1mM1m0Ou7x94+ZQcK3VK5W0oD6Jfm
+Qgd/W+pHAcOHP4KpOsXytVAMRIRhKeg82fLCZJk0twIjKS68iN+RrfUeU/OAhg4CHfYbkVRFyt+
p6D+tWw8KAbmk18KNEBCNxgKo8AEFqiAOmh1OIDZxTt15g6d46sbjnK45S/Ip6cVpqYkJyX27pUQ
H2c0xPaMie4RFdk9IjxM301Ha0NDgjVBgQH+fr5qldJH4S2XeUklYpFQwOdRJAExhD0gs3hLoDBa
o9PpSnq6wkE3hu1UuOKizg7KGxJpbsoUfFM45KZwqDs8zA5qe44+M4sxvAVyztpBZSfUdmBKIVRD
sSRXpmzzJH12pT0w01xWhjmy9ArannPB4KoKa3uLVJKpz7RIesbAFokURSlKmNa6hcjpR7ACmZOd
uoUEkaxnjF0ZbSfDs5lzkj19YRkK+iy0hDGqzpgdjrZFnlGA2ToklVMi7IJMu5Atl660p5vssJDe
EtPWsmiHAsaXRXuZ9WbTWPScCeu4Bajw7IpCxo/ZzFlWQdt5aJwlDWro7Aq6Rc+4I7uiDFmfhblu
qUe1OLO4WdemsSvxmm33ibYPxBQD7z+joVqyAyppJtjS0kzbW0cUe8bqGC4pKQnACrdk69EgGsue
lIFNCTD0jHG2yeUAc9kkpsxJJqae2ZPoloUWtq6L2DqwSbMrsGNMt0vV0pJt1mebTeYMp/VMe3oh
e4HC0cVsA9F1WSUulSsBxvDYmLKsEp3T2bn5xZlMxfSmLI2z292aMpcGFdkdkTRTg8FowE6X03bI
L9Zj0mSGLMnQUp7MDh5dCYG58jpz2fnhCj3d8ivYiTJ9+/c3akwujSBc8SswYo4+p6ylJUdP57SU
tZh2OBrH62mFvmVLbm6LNbsMS80rxlw7HK8t1NhzFpXYFWUVRCr6nhkBOfnF/TU6n5KOYF5HEHBI
4cCSss1BL+DfYNcFvQyFxToaHVVUXKJBPxUzciHKziszkHDgJmMfu9zG+MiS7HZPpkvU6ZjRuXBH
OozHgL1xRLEzTMN4zcuQbojG/ihjYto6YnyLmJjGjhh39jI9lrKNXZh87aII95+3wk+VXZFqJ/z+
SbTFGW9XZRZTGrLEKZEaipEk0TjT0+z+0ShHRrdgJxzR2xXRdn5xmyathFb44ArA9F6BPnfE6GI6
u8U9CpwaV0uZcYBDXW+qaHFNJWbQ4/AgsIPSMwfpDZCGZmhGkWNP12cY2BjzKbBTpzACF42MLXpi
wYgt6cSCgtHFOxW4Ti8oLH6ZJMjMsoySLWEYV7yTxmWY1ZJuLROimRDkMkP1ZVLERml2pgM0srE8
VsGGy3cQwOpEHToCyneQTp2C1SF6Qrq48Nw3gdqz3wRpsaPTH3zHPzDxH99FaL//LkZLf5b+GTn8
8LjD5LuHlNraQ8S6Q5sPkQeXi7T7t4VpH1+bpH1sbbz2UTzXLovXrlll1K5eNUj7CJ6rlvfUrkTd
imWx2mXLc7Ta5Ybl5PJltHb4snHLyHXLiPRTp06RipP0SRJOKk4aT6afzDtpPSlI3y2WJjL1yNvl
pUhUvEak7xArEmG7Yju9nSp7xfoK+dXXeu2Zr2kttBvby9qpvI+J9I/yPrJ+RF2c46u9sC1e+yOe
67YRnx+P0R7/XKf94kSs9sReJdO4rR/KFaxxx4cSReKxvSLtUYzwPqI9YjhCfbA3UNuG576Zudo9
e7XavbNTtEsW5WoXL8zVLloYqW1ZmKl9CM+Fswdqn5gXpF0wL1bbPK+Hdv48s3buvDztg3imz0vr
mzgPM7Y2KbVNjbnaObNztemNA7ISG2dHamdiYPasbK11FpE+a0BmYpS5jznXXGIuM9vMAoW3Tuvn
20MrFOi0gQE9tDxKp1Upe2hjenr3iJZHRnlHdJeHhXt308tpnXeoVq4JDpEFBAbJfP38ZUqVWuat
8PHyksm9xBKpl0Ao8sKHHy98MvJSeDd6k+mCRgGZTjVSpDduXYZDesRs4HmDAQO1MBv2wQfgAJGm
j0jrnSrSUikiLSSLtHkJhF2ZC7mFGXYVgdeCDHtCdO4OEeTb46Nz7eK8McVbCGJJCWrt5AIcboV2
3gIcYYV4Fxk9pngHEchEz2NvKijtIBrnLV6scUslJdEhdnNuQbHdGlJij2eEh0NKIBpRb6uvr4/+
C2wRM6Wb8zO2nOcxtxyT/bw+a8u359nbj/1bfRZhN+PEzKq3z8qusM/SZ0X/panozihGYAvF08bW
AOpt0Q03JrZFd1QLQKBmvsOFf5T5txon3/BoVurUOE7fyNfNjl//tYe9P0MEXf96Y+IoGXWTZmKX
Cz4Kb8N+2Maeb8Bu2I7HS/Ak6t+BPahjTiscgI2wAbXLYBOshydgFTzDhuYSJOYC2AwP32D1IXyI
Pw31KI2EarDBHFgEK2Ad5hqIuvkQB8kwHUrweB52YFmXoBUehwUwDcdwIzTDEngUNa/Ah3CeUME1
QkkkEGlkMJlFriNCSAO5lKrH+ryMNdlMjiN1xHriGuZaiXXbBlPQwiLKDt2xTo+RdtKB9XwMhmAs
Voq51QiZH1yh8KLeLiB5wJyG9068x1KcUeej8wlHIjDV5UY+XGGu0MhsP0hsPZDHcYQwufumR5LU
PiCiiT7EUGIcUUvMJgRoX/iBQTybP1u8lM/jUxRJCg/zwXAt3tDfSBhK8ZpQ2nytLU5M6FWUPimB
PH69/fkTTYfjDvOPXjnIS7ps+BBrGUcdpdoFarYcQ7qGomWKJCFDAiFaxC3GMZLkHaMFhMBQ2p5g
aIf+CQZlSkqckYiOJii9So8n1f7q3LKNeArU1/aQmcyJt40cHO3vYwu8YHP6XDGJGyuxXBpEKii1
WCulKT0vShonTpFmUenigZJ7pON446RVvEpJrXQqzOZNFUyXzJZqxkumkzN5lBfMkZJCERCJRA5x
L7Z/JrafkIv5gkahSChLEWVECBOFOcJRwilCvlAml6UKX5HxSQklns0jeFLgUUIxhe3rr/RPMZQi
GQnF2WihovRMtAJd1Eb4JBhKm9va0FtQSpTq9OgzitATOhWh4085QERc2zDl2PVju4hiQnGQzCJU
vJ+uPkfNunyOf/TqG1RfnA6EHmfVaLa169JHdCcMVKw4EZKIVFwWc4jB1DDxKGqU2EJUiWeQ06kH
xD5SXHFb0UuEVNIkpkiKJxLOEvAFo/kz+CTFF4lxPSYFFN6GSYoSwA7Hl+nBEkWSBHdtNLPxk6fL
rXKSz6cFRkG6gMLOwRYwrYhWphgScIlmmoqdVNqswPYpmrFpbSiK2ohSZ9uoBBWBf6LR13p/HXNt
7xd9D0aSA/HM5R+9bOAdvWLAQRLD++gKzTuFo7G74zRvNG8atq43LEovAYPKEOMbbkhV9zIM9s0y
FPaY0GNKD2kweMl6h/YODZ0f10sdF9crMaVXRlxiUmJqVJRf3GtJggf90pWBSX6wpkdwQnBmMBUc
3FM1PIqIigpf3VPRS/yIyg/6txv6tzNNwWaUtuM4jm5XnPVJMWBnnYlulsdG82cq3myWp6Xx33wz
zoidJSeEcsJX7ZcQn5gkZAP6bhG9e2GpYUn9iN69IrrHokYg1GMoIR73njiu9dSktT8OG1E4fuKY
PflhmlJjwqz8ec801N9H9D8sEEXo9aXJRcezJOEpX1iOHBELNu8ihwr0Ot19hYOGjEh5XNHH11/7
2Mx521NTEgTBUX7GNKVSlqTZ7R3RtFjTV3NNgv4qcpzm98BZpQI9zEsfPThocLdJvNkiq88MjUCp
1ut1FIljZj6pUpOkKixFlRFB9iazyZFkA8knw8LDUhW4fuDzVi05m2wkHyYFJBkuEQeJyZAHxbvC
VOC/yltB0o8IXA7DCa+41M72/33OYd0cG42OkivSRGnoLBzV2OtJLt8ona7wV1FO17j9x+9xfc1u
zezHxjy50zyy6FxTyaoB1pWZcwZXbEjtnVI5pXDzPQL1H983jOp7YN9ThLZq8syICOLMtUa9zjxq
+MmK++cUxjMrV7HjLK+JNwPEuC6Wp8fzlAq5WlmgKdPM9rIqheI16f6Ev79EsEah0OlCVkv8csSF
YpuY0ulUMrF/EDVPxTxrScXeSSpVVNCDsl2Ril/asWXR7T4pKeywAGaE9G9H8b72OGMpwXYz0xCi
W1hvBeicvaxzNyvBOS6oNj6vYc6SL7oTgnPXfyfmEqF7D/morh4U8Dc9WXN+uDQqPq9fvzJyY0hk
wORp9oev9Tt+DO8F2/e8ENo0MiQ5YPFTIxPfVYZ6eytw1ibjvXo19m8grN6epMpRjVRRATscx9NH
i2VJgb5R6ijfSnmF7/3yab7WAGugmC8SzSd4aoLgeXvL1Go/lUKlUMz3Uap9fJQ8HyXxGnqHCEpR
ZkT49PbJ9hnp0+DD9wnSBKX67AzyesRfoQS+DxgS+vdv71y4ShWXmtuc3SwUYTfj5AhgZwd2djRR
SrADXeX2DaUnEii233mrxaKNu1d4yQqqhmwftX83MXF30+Rd5cs3UPcG5GuvRZMzeg/vXlhUmHp1
L67n7+XmrQBni6nz+HyihJr0oEBZojRHWiTleQmFfJFUis0TS9RisUTJ9F2UWJGkVKqtakKVIsmI
EPcWZ4tHihvEfLFKrUoV71Sh8x7x9pZ6i3FF7o/3KY9GMR3tbpQ8LQ4boneOUmxMgtA5cKm9ksjs
uHt3Fm3b69gbMW9nUVxMD2q1RFyUdvUbXunTpYP4zO8laV1HAd6l78bx258PYsItjuvMQc4gf2AO
auItjjbu4A7u4A7u4I7/xYPdiedQw9zvCzH/AumUCdxXxrtkEje4+10yhTvzzS6ZB3LY6ZL5uMc4
4JIFqD/lkoUw021HjPofXLKMGAJXXbIcepCDmHf7eMw7W3KyySXzIJSsY2U+q291yYz+YVYWoN6L
3OuSeRBMvsTKQlZ/3CUz+kOsLGL0FM8l86Ab+QMrM9+Hb6YULpkAOWVzyZiet9wlUzCeV+OS0Sav
ySXzIYDX6pIFqD/ikoVw2W1HjPrvXbKMXMMXuWQ5FAqdeSUebZd4tF2KerWrLbglhjBXW7xQrxDx
XDIPaOEvrCxHvUgU5pJ5ECBi30nlKRj7ojSXjPZFMaysYvWjXTKjv4eV1R4+VHv40JdNP80lM+kr
WNmP1a9yyYx+PisHMnZE21wy2hH9jZU1bPojLplJ38bKIR7lhniUq2Xt/OCSGTsnWTmMsSOWuGTG
zmVW7smkF0e6ZEwvDmBkkYefRR5+FnnUX+RRfy+P9F4e6b08/O/l8v9zdLzRmEwPrSyvq62vnWCj
M2vrrLV1JltlbU0sPaCqis6vnFhhq6fzLfWWuikWc+xIS53ZVGOiK+tpS6WtwlJHm+g6y8TKepul
zmKmbXUms6XaVDeZrmViPIITbl0KXVlDoxm6qKbShvkLbCabpZ421ZgNaKCWLaC8tqHGVldpqY91
W0jtqMZgm6mqspwJ1jPGesca4+lId7IoV7KezmRDTTY0OJXONNVhbUtqG+hq03S6od6CNcD2TKit
sdGmetpqqauutDG1GT+drVt20ZABGFvHBqx1teaGchtT76kVleUVHnnxWllTXtVgZhxRS5sr661V
WAA2BnNVYoJyTGWpscXSHWXX1lRNpyMro2hL9XgmU6epmo7Et6wRm9xcWTMRfV+PvilnXOlROutU
l60+bAUiK7EUm6Wa8XtdJZZqrp1aU1Vr8iwU62xy1hS97nZ/bYPN2mCjzZYpleUWJk2Fpcp6U4Mq
bDZrqsEwderU2OoO58eW11YbbNOttRPrTNaK6QamiHoDjAQL1IEZTFCDJw2Z0IDheqiEKRi+OXYy
G3s/tP+TWGfem+NyPeJqkW0YvjFNHBghEWiqldpFbaK2UjupLfAc5oxHvRH3ocynEyqhHHPUop1a
mIA2mPrWosbKsgk1lSjVQCzGDIAqPGjIR91EqMC4ejZkwStT7hRkM6a8uaaVbDoLW8cKNo5m9XUo
T2RjbayWyU2jXMd+YsIC1XitQx/QbF2ceW4dO6FLbWFqVMPaYmpDQxGGKtk6MOUXoGRiQ/VsmTWo
NbhqUOvRgnIMNWAsU6NKNnXsLeqQ+idvDGbtV7EpO2Lr3TXrjVaM2EM0RN7CWtRN1nreYG0oW29n
DaeyrWc85PRtCVtbmvXadLw2sH3m9IGzfyawNbCxbWbCVjZfNeuZDt+MZ/N2+C0bPTcER4Uzb51H
jJWttRlLKWctOv09lS2rHPnW5TrDTNpybFED28vOEVGLbGbjrRjjbIGzZ5xlVboslLtsWVhmxuzN
7Wbiq1gpEnNFseOyGtvVUdKtalXzJ8t37qNO62bW0kTXuK93jZty96i8dds7R+qN9erj4QGmJc62
2NjyOsY7Y9/ZVjNqprItr2Vnz61b6vSz6QafWlzj/ubRz3jVhuka2JxMbaewrbG47TApqzDFP++h
CtZzVpwJBjymskcs69EbR34sm7Ma09iwRUwLJ7JttKKF6ajtaEU9/HkF7pwj92F9LX+KzyJGYKzt
Fit3rccK+9frugVL/6vVeTq258/rOlOj065Z+yfLvCBeJi+dN4CXzIv/C7t/cb8gjO6WTv5Tzjyo
JUxsP9XcojXZmPN+V4j9QJzjZzyHwLS/eA+SAubJXQGEw+H8VCD7Dd9+4Pq0IPUKMs9j78L84kYv
vBsRVSZbDebFZ98hhYNo8MsfPpRmvpaJ/bzcDezOl4z3mFvnC/XIQbivBJBVteVVIGdZzdohXNZI
di/kDClc1wjmeRJ41ENUC7WQWoQhEv6AyxilJWg2JAKCWsxasbmsuexpmHdvXd8hpRlnbNKMEYh7
zB80/zcZISRbmzRDUDWIJIg4qVEs4EfLKTKID0aTQBItIHhEUxJJ8FoLjCOMMR6a4PWhjcGQxh7D
cfFgpkAVdhczafoxh1HnYYyn3ifRnnl9xm/J3sceDbpwJcEuMYV819rk18PYxFMam8jLrRRJkKQ3
bhgXpqUt8Dna71L591+mG2XumjI7OKM1LtoYJaCKeFJVt8xa6/Q65rmYjiyPouNSUpJueraNjQs1
BjsT+97yqTdOZ9Qy8ZQqoDM+v7bWRg9osFXU1lXaphtD/WUpSca4OKMxyYgY7S+LN8bFJ8S5gv+F
GjUR3TzdQvCBaiK8AfUSsokg4Dlyz37r2T4Xh2ki162edq/x2/XPLQ4f9/v1R4Zs2H79ifV0vxkj
1j+2fmlZ/OSjGebpP2yacrDw+MXvHp8fvHTd3Alb35p8/3j9JyFpJ72J5edWvbmv54S1aysiHj2S
GrPP65XiiP0530j6Ja+KeS4yZeP3gx/M+Gqu9661VUWmTU0znirrOXXI+Ue3mfuszQuOE4Wp1z33
zbLogLN915Sry4r5lnUhSfnNvz3740rybc2H+4qytz7UuC/1+8KVw1669uz91bZhmwMOrxJH6mDU
w2WVSbtylcK0kY4xV/42QSJ65tickaN+fLXPvX5zpvKOX9r7UuMj1+3vzf7k2aC6sWmHdl8Qbehm
3CqYd3ArPVU170uSwoG/Yc5G45ynjXPWozdDCN6ctcY5qxsVY45Yf6yse1I/Ypb65aFLHO8+Vfef
77+m24xxiunDR85J2xb/vDqgd/sOIuzvU31+HlsWv+5J6bv9+MsWLD2YelZ38cKoFTGvtA48MP7H
q58e7tNn9HOJhZXXw6r7Hzz8/En+jBNxi/uuU1gn7bquHB5Q2Xb1SOZXPqPp4d+Of2Dz84EHopPC
e+61PKVsCfcu3/BbYfAfuoOf+P6cv6kmM154rcn/968nVslGXNrzU/47e75503iVjhMvCHkkKmjo
xyHk0z81nqK2jflly4kDo36wDH4nv/DVbVSk0vHwJxdES2ftWP3WC0kxZ+4/s3HqV1Na4cik/vuP
JbacGqDc2HuSZtLnvU9/FMw7szGbd2B0QnLN0GDZ+O2S9Ys+/Liwf857wUXPWD9XpjavaFj37LFW
XBXKjE3UEOeqIIl9weeLPMfYJ95t61hTQv5biwHO++R4BK4A8bgYxMVjsHfHYjCdXUHRiEBFFhXE
qYw+TECkkowy1VfgPtGGxSiMckYpVAnzLebq2hpzR8Ukf1UxvVHnrFiQZ7zZQhdUTqxhdp95mQNu
uypsnz7zk9Kt2Skbe22KO/5HeO/BU9uuaJ98J/u+H4/mnPto0RuTh+SP/+VR8o2hfx9cZQjrZ9n3
vn67dND22Q0nsvc8v1Se91Z49MXWb2R67dEBYZfHP/pBYPbTK+7RPvreVkO3N+7pOaP2M9/QPotS
FCkn9kT9MqFPTyLecb37oGdeqSKaH7/y2svls5v+GNs6Z+68JfaLO1Zu+CD5mbx5/t2bh50wXoK+
v7z9R985e+e3V6U8G9vr0rbYzZKZ45dNm/D4mnrZ/M0X3/yZ3jlcubj83ZjP4rMDf9h1z6o+eQUB
708YMf35F5sPjOy3rilvQQ1/S+/9D4TtyZ/Q99Fhh6NnJdTMHSg4+uSRe+aTNfPhb23NXxa4VoXL
xjm/GVXMohDO8zJKBCK8ofH5Qor631gqvJk6qgjCweMbKbwYQxiFnOfHUx8OeX8KWMds/un4m8PW
jsiK3ZBVfsEoZaK9ecwn7ud7TB12jXnghZdm3RNx8f3dw2zri7vbejRsnX/thSErp8HQ84e+C/ii
8i35+hk/k5lvH2o+/HvB4dfX7RlZe6E867ks+GHVgbUfB++QrguUrfz0eOiLUTN/bH+mftPSkylL
+q6ZtDu5+tiCzfprX57/pFK8bMGe66dhV6+ff5vxh0IZy/8uatWKjMmR921PXnpKKDtYWvHensYB
kyds3LV915Jehy5Sihn3/3rsVMaXD1w/fXrT9Utffizbav1k+VfDX01eP6PnR30/7yUdn0SumzNJ
/9ClseVL7aN3pXxatqhoblDCr33WtDZ5rR+3cGvM9qeefveF4/Sr+4yB82i1rMfu/F8GnLrX+NXy
yMrm/dZ//PzsC+83ZtRNkeMaMwnXmHzXGmPynjbU+dDoOY/4uM78F2d1x4KTYDTiipOAC44xxRjP
BBOYoNF2V6rmiqf+Iv62a836zyWLP3h9/+DH3ns+tdeL+pLJn1ft1XXbvvLAty/te/vjiNfjfRbu
Pl4acyVxZKhv9EtLZSfUG2oih8z26z9g0+L0LTkLZJ/NWfniasGRUVlTxn7701X5/1Vv5vFQbn8c
N4xlbNmyG8aWasoMI8YyiLFnMJKK7IrsJmSfGaNkTZI0hBZ1M5Fki2u9tixNN9lKlutmCVmSpfgN
VzeV+7u/1+u39Pr9+T3Pc87zPOd8v+9zvp/znKEI3A3FJ7iR6WGH7HCGEvRaJ4qns6DlBMfTkNkS
Xo6P9u5ypDNxJZQK0qhAUdLP7/mLHW0nuV+rTkGOx+ZH+tehhy/HBNpfe0MJrFGOV+ST5+1zbL4v
fBeTdpLyXAIJ8x2IP6k31CA6z2GG05YfZZR2h5w2LEiuL0Q2HrzlaSNodC+xK4GICmLV775ZGCVV
NzQb4vrACFcpq21MduCzN4U1EeaesvmETh0+FPiM5XAAfpM1izD8+42+F9uxHrG0IGSq3hKwcxCt
hFDzRUvjtBGBLncignG/7Oj2aFrnhJgUUBDGH7l9mOuu3yAO1ICpwZBZyllK0YqbUqCTn8c3UqDP
abf1UvlNAdVfXgdLc7T9tCKYwedH0tYh6jBVmMpnG0YfDf1LbXGjQRe/LS3hvgmgDdpoHfHGnsyU
ICIAnL8LGKtTJrrxEVMcZ3GBmCv6gnN0O93C+xyTcj6dzCb/Jrd7+XDX1VWzqhOgh2W3JwlzaWDv
o8vvZwbZf41lQfELSFCrH6H1WWTtj4CMU96xtJYf8no3ZMAjpxQL8XttV5zvxiOdMjWGAPWFe3kn
s1q07DEx/EkBGj2a3WorW1GhPnC8kMhWriSKiULrrz1OyT7KfDf1VVDlkYhbuaatsxRyuvbQExtp
1MsIhL7pQkdTSMZEcTPZiQ+bT0mf7qrqyMq+d7kleO85aHVjz0cPht4qFcoM1UZIYEf1h5bI21ws
wq+SpN4UZJugxgu4ZYM4a6BlN083JqrTaJNBow3pM20MQyf/2AD7cbSxdPN08cc5ePpspc0BGBJ+
AAZXUlLYWN7AN0wF2LoJw9/+r7zbLpjMHxMl2EvHzWdd7NbFoiXQWFNVOExXZZ+SCkJ5n85BPZXP
NzLwgv/iI7Aufuvy+N8Caryc0amp5+z9KF3UrYf1kyaZ0q+RAWDQCwUj66Bne3tuMSdNv9FYqZQN
vbEyEhau0NGjEYtUnl3sVkPwP08mrCDeniL5CScOlJoMlJLmFFnpa3IC/JVMbGdKBo3CxEpTgvrW
wKSdB/V82yN2HeGhEjFqHcv9C7GTmnTDnf0OSwLxxjfx6u/dtMYHY6qYMeW4kDH2Ef3xex4znSfx
LIv8LWG8j/2HQCbLjiuTWch01dUJ7iYHsKN1N6slsVPN2HjocKW8vXBCMqNOr+0EgVXqCiiLEe4S
e8kUrA3JSU76hNZFeys9QCtT3O66LCF0HgjUqiEHueJmhc8NW5qJq2XAKVsB9QVI4X7v9mta7R6Q
+XCqFPDReDC8Yxj1FXu8R001r5Qh7hlHJ1aQx/PUtHUanv5b7MH5+zg5/EfY87kl3HYEZfmOwtsA
yi2YAGLnp/Z36MXsr6IigvERu+S098z9CknmvEKxw57YvTRZY2l0J+wD71M2vqVDs9E76byGiWJy
6FwoUuGVd7rysSkpi0RLhnjNXLKzysKBJj6dYlVUWjNHnS9ebs41Fz5kY5u4ZGExaDNxKSnDDWQS
Q6UGmCA43AdDdXP3HidaRqClhWTqL+j9IjMsFOm2m29BoOGdJBSvd2Lv/NLthkCUlPfSbWdSQo4j
x9194DsjSaiItYKEj1feznwC5rcZth/D5S3P8YqLINtvFL2omC+aaqLMWoFX1GeaXuzRragia4a5
CrYVSjixtmhpuCgIhRaWatTIGphKCl31ioPVzFz8GlBc7mxXMdV0Mve4+9Di1sEnc77F1I9Jvjbp
BEMglNfphKSZPyD5+g6cf8ebl8peK/lNB418BZvaDVDY6uV7fOVQhcc8GIsm4iRKsccQnixXfNF5
QNwsqrzWmBrBuDh95ufYxjud9918XIN2uY4Wl0yTytqmfvrEc5PtqORu+Q6tHiugSMAjT2dPI8u+
VzP9VdeJjZGvI0zolVPeV2eyWIFP6bf1VAfYyIcVywCLrI67izqtRYaqT3UCZQ4hA3HMtrU23dHK
0DPNnONgJCg0YDXDwyt44C0q8UqmL6fdHoygo71C5jOi6V5Jm1Po2H75KC6zwqVHwvEeUzLXeBef
cHWROOcJAf4HGi4H57TaM71lLIhWLFlMOR6lHWVNSvEqEIcatHqTdQbcRyNkE07/wRsCQI7WI9Lb
R+j/RfrFxQTaFEB3AjZOMW+h57ZwFPqzAh89kB3MSoelO0PnSKdDp/11avZdXrcNoFIOccNrQ80e
cydkOzADOON80PHT/paVmiDGfWul5liS6CTyYskNK7b+uGI1EepKXm5zyQNziIg3i1v4aYYcSb1J
jyLPUMlSvV+j5uJ3/Mx84UDNRPiYjy36evKz1vZXCdWDVXvaQt8231foPFf2xKn+AFUQUhXQr5b+
UMQ/E3K+u6iIxzJunlzrYpQuJ0u2v7BDrZHXJcjgcQeFqIopcLTuh42NIcWGY2Z7kfglXkicc6QT
EzB1Np1eRz5E73z5Gn2Py5JRfy8D7tJDRi/21oyXcg6hBjMCZG6ICr3ouTymX1IVSke0GrAalXdj
+kddlePnJVPJrQWBluaqL/x0C6UW4ATgDRqkrtMDADD8uR+YlX2VK37RuLPw7TC+P8dbDgBnZmDc
OLS/7gWbgwligLNvldVpb/PFYoNzwrZe3QmT+lIRCKf52EIJZmcpcHmafOP34CCimVQHzjwSZr2l
CjvcCGaQta7M/5MN3WzZSOl/4VcBiW+QBiQA6DLLlvtkyPpzcfWefg/q0YdrjzWIQM1V6Z5XB3S1
WRmSZJRPHz1jyLsU5aHhdov1vGLyKYPphXymzv2aMmNKZ2u5OisB/uHVT4VaJkpq+BymTOmPcVwY
m9cST8u/XpdRVFXFFQbPaqlP521n840Nql090sXKihWQpnpYTRkkHkGp72o00sBin0Mj1IINMbud
cyQCh6+N6EOApPiusFfSa5msbakHVXxn7C/Ig5o+WYtj0dhOltWQ5TVB7VF8yOXZshVuzuTGTEZb
AIVgP+LiIgZNIZsnVpiCLISlLg5LZ7pMp/kS3X4zmSpsNLd8s5SxavdsjR1Qh39LhdjBh/h4DYqy
CfTiMAK9yJdxYYIT6NlpRSz/c7f8dhb6Kqlg3nTLLFuY4FbvY/uy8wOgPfPPK4zwHbTpVQUOU1yf
TJEKSse+c76AEz15ZxmDKsCr1uBLTqZ5omT5gm84te4iTDJ93lqKGIIUSkLx2nC63lUGDP7J2tlb
551z26hsupdEX6ri69QCS7NuZqQVNDMM/Q5ywAzXtZY6mIsJ3IU+11K5ELqPvIKAHk9IeU3U7XrC
bwwMHjBSss4sVbofO2b3iVoblxSclhj/wgNNcphAcz/q7pXINrTb507p5YMzkWtYHzSkNonrOEBZ
vahNhxYspCILmsGPTzWnoNbC+3MLGSUd++8n9Nq+Cb1KJxKDA5j47IjBDULwAaZrkYiqYzx5SukH
PT4w77UhVEbHj6cBW+sVu/q9HlKFS8h3TEYmAKzh4b6HuUeUplILnkqZlmSSOrJnOLRue96cxr9/
3elqJ0L3Dw8XazsNCmVuZHN0cmVhbQ0KZW5kb2JqDQo5NDIgMCBvYmoNCjw8L0ZpbHRlci9GbGF0
ZURlY29kZS9MZW5ndGggMjI1Pj4NCnN0cmVhbQ0KeJxdkMFqwzAMhu9+Ch27Q3G6Uw8hsLUb5LB1
NNsDOLaSGRbZKM4hbz/ZDR1MYIP8/5/4LX1qzy35BPqDg+0wweDJMc5hYYvQ4+hJHSpw3qatK7ed
TFRa4G6dE04tDUHVNeiriHPiFXZPLvT4oPSFHbKnEXZfp076bonxByekBJVqGnA4yKA3E9/NhKAL
tm+d6D6te2H+HJ9rRHgs/eEWxgaHczQW2dCIqq6kGqhfpRqF5P7pG9UP9ttwdj+/ZHd1Phb39p65
/L17KLswS56ygxIkR/CE9zXFEDOVzy8cpG9rDQplbmRzdHJlYW0NCmVuZG9iag0KOTQzIDAgb2Jq
DQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDEzMTUzL0xlbmd0aDEgMjgyODg+Pg0Kc3Ry
ZWFtDQp4nNx8CXyTRfr/M++bq/d9QDjeNLQUeiRt6QUFCj04yl2OFlGaJm+b2DSJSdpSDxYQAQuu
7Iq6sKvgjSgawAPwRlHU9Vp1F0TFA491xcVdkfWg+T0z75s2pRQDH3/7/33+8zLfmXfmmWeea+ad
N00AAgDxCAoQKmunTZn4zl/iAWozAbR1M+bXTlXw3KcAykqk+nx2rSE/7/XjZgCyHe8XLqycWdf6
attCAFU20nxkbjW5GrL+WQ2g8yLNYnO7V3jIcP/9AKNXY//YJldz6wvfjfMBpL2JEy5tNnlcGj2E
43yJyC+x2d7Z9OqMK+IADM8izxesltZlj3ZfvRggMhIgyWoVTZYj5KUvkTfOB0W0IT4h3I73Frwf
YW31Lpu4S/EMAIe3fKXdaTYZp+Q+j6Q4P3mx1bTMxesVp7C+DgkEh6lVXFC/9HWAkhkAg+9zOT1e
/zhAXvO+o/0ut+ia/dLIpQAjjchvPlBbKVG68I9sS2PKTmm0GqDpnp03ddPyucl/twJ0zwk/ps7D
20hGTxOW6rzuOQARGwD8b4Qf6+kJpGdZyydwKWhAjeJzEAsGKMWhXyuWYh9e6mFkI86uUbyuQIn5
5EAJFl6IpGINkGbWCgKUnxROHlZlkbshT51HfCt6ehUA7EYl32smwPSwTNg0ILv/Y0nzKez8b82l
/t1/b67/K0mt+/9PZ9UlsJPmX5HlJ4TgEj17VZ8nnYf0Arj8SoNDF5wqSVWNhP9o/HSv8ndDGGgQ
wyHMfwYiIBzrkRCB9SiIRIxmGANRiLEQjRgHMf6fIR5iERMgDjER4hGTIAExGRL9P0EKJCGmMhwE
yYiDIQVRC6n+H2EIDEIcCoMRh4EWcTgM8f8AAgxF1DFMg2GIehiOOAIE/38gHXSIGZCGOBL0iJkw
AnEUpPtPw2iGWZCBmA0jEXMgEzEXRvm/x714NKIRshDzIBsxH3L8p6CA4RjIRSwEA2IRGBGLIc//
HZRAPmIpFCCOhTGI46AQsQyK/P+G8QwnQDHiRChBLIdS/79gEoxFnAzjECugDLESxiNWwQT/t1DN
cApMRJwK5YjTYBLidJjsPwk1UIE4AyoRZ0I14iyGsxH/CXNgCuJcmIo4D6Yh1sJ0/zcwH2oQF8AM
xIUwE3ERzEKsQzwB9TAbcTHMQbwE5iIugXmIl0Kt/2u4DOYjLoUFiA2wENHEsBEW+f8BZqhDtEA9
ogiLEZvgEv9X0AxLEK1wKaINLkO8HJYitiD+HezQgNgKJkQHNCI6wYzoAov/S7gCREQ3NCF6oBnR
y7ANrP4voB1siB1wOeIyaEHsBLv/c7gSWhGvAgfi1eBEvIbhcnD5P4PfwBWIK8CNuBI8iKvAi3gt
tPmPw2poR7wOOhDXMFwLyxDXQaf/U7gerkTsgqsQ18PViBvgGv8ncAMsR/wt/AbxRliBuJHh72Cl
/2P4PaxCvAmuRdwE1yHezPAWWOP/CG6FtYh/gHWImxlugesR/whd/mPwJ1iPeBtsQLwdbkDcCr/1
fwjb4EbEO2Aj4p0M74LfId4Nv/d/APfATYj3wibE++BmxO1wC+L9cKv/fdgBf0B8gOGDsBlxJ/wJ
8SHEo/Aw3Ibog9sRd8FWxN2wzf8e7IE7EB+BOxEfhbsQH4O7ER+He/xHYC/DfXAv4n64D/EJ2I74
JNzvPwxPwQ7Ep+EBxGfgQcRnYaf/b/AcPIR4gOHz8DDiC+BDPAi7/H+FF2E34kuwB/EQPIL4MjyK
+Ao85n8XXmX4Z3gc8TXYi/g67EN8A/b734E34QnEt+BJxL/AU4hvw9P+t+EdeAbxXYZ/hWcRUQrE
w3DA/xc4As8jvgcvIB6FFxHfZ/gBvOR/Cz6EQ4jHGH4ELyN+DK8gfgKv+t+ET+HPiMfhNcTP4HXE
z+EN/xvwBbyJ+CW8hfh3hl/BXxD/AW/7X4ev4R3EE/Au4jfwV8R/wt8QT8Jh/2vwLRxB/Be8h/hv
ht/BUcRT8L7/z/A9fIB4Gj5E/A8cQ/wBPvK/Cj/Cx4g/wSeIP8OniGcYdsNx/yvgh88QAXdcgOMR
USrc2iOiQn+ARA7cFR46l19pcFhYCESR0Sp8cEVGh872POaICJ3LrzQ4PBTLRMWo0YJRMaGzPY85
zuPiX04XNTgkHWPiMFIRQ2d7HtILiIb+6QKWS2+KDMUysfEatGBsfOhsz0N6AdHQP12UgaJCsUxc
QhhaMD4hdLbnIY0NnUv/dFEGig7FMgnJ4WjBxOTQ2SYN3HUB0dA/XcBy6U0xoVgmKTUCzZ+cGjrb
lIG7EkPn0j9dQCj1prhQLJOqjUTzD9KGzvY8pOdR/5fTeeJj4JQQimW0wzFSYcjw0NkOG7hrcOhc
+qcLCKXelBSKZYbqYvB1c5gudLbCwF0XEA3900UZKCWU0BHSY9GCuvTQ2Y4YuOs8Lv7lNPRiBg0a
FAKRLiMOBkFaRuhsz2OOC4j4/umidBwcivfTRyfAEMgYHTrbUQN36UPn0j9dwHLpTUNDscxoYxKu
sCxj6GwNA3dlhs6lf7qA5dKbdKFYJrcwBc1vKAydbcHAXdmhc+mfzhMfA6f0UCyTXzoIMmBMaehs
SwbuOo+LfznlXMygzFBCp2iCFi1YMiF0tmUDd53Hxb+cjBczKCsrBKKxk4diiJVNDp1t+cBdxaFz
6Z/GXMyg3NwQiCpmpkE+VM0Mne30gbsmhs6lfzpPfAycCkPZSGoWZuAKm7kwdLa1A3dNCZ1L/1Rx
MYPKQrFM7dLRMAEWLg2d7ZKBu2aHzqV/Ok98DJwmh7LIlthyoQqW2kJn2zRw16LQufRP8y5m0LRp
IRBZ3PlQA83u0Nk6B+66gGjon+ovZtDsEEOHk/9Qlwg8LQgeAYkKgr8w0P9PefReMfDf+fsl47mb
a/rcrQud38Wnp54OlVLBHiGRoEELKU6mnZx50nLSffKw3w9wUiff/c3vj/kUry9ik2M+P9tK5cUl
xWMK8vOMhtyc7KzRozJHZqSP0KfphOHDhg7RDh6UmpKclJgQHxcbEx0VGREeplGrlAqeI5Bdpa9u
EHwZDT5Fhn7q1Bx6rzdhgymoocEnYFN1Xxqf0MDIhL6U5UjZdBZluURZ3kNJYoUyKMvJFqr0gu+1
Sr2wlyyeW4f1Gyr19YLvBKvPZHVFBruJwhudDkcIVanWSsFHGoQqX3W7tauqoRL57YoIr9BXiOE5
2bArPAKrEVjzVetdu0j1BMIqXHXV2F0caKJQKt90fWWVb5q+korg49OrTBbfnLl1VZVana4+J9tH
Ksz6Rh/oJ/tishgJVLBpfKoKn5pNI9ioOrBe2JX9bNeGvbHQ2JAVadFbTEvqfLypns4Rl+Wboq/0
TbnyeGpO9l5y7/w6X1jFXgLz6/bBdP+KXdNWVFbW09niK+rWMvIUJE+58riW76pKtQn0tqtrreDb
NrcuuFdHsb4emeZk18yr06HU+qoNAlVjXh3TAJmSVAMKSduompLCor6KtjRcLvjC9JP11q7LG9BZ
g7t8MK9Tt3vw9PJ9/o9gepXQNb9Or/NN1OrrTZVDdiVC17zOPdPKhWl9e3Kyd8XGSZbeFR0jVyKj
gitiTx+rMXJaQ6kDpiZUIv00DBGfYBZQkjq9j0svoSCWQJe5BMkw1RO0qA3t19AVO5Y6Qpkeqxe6
TgEGgv7E131bTHKLKj32FNAqDZeekMP+QN2XleUbPZpGiroCXYuSTWD3hTnZ7b4avStW8NWgyWBO
HQ6qH2tAk+t01Mvr95ZDI974Vsytk+4FaNTuhnJDVr2Pa6A9zwZ6khbQnhWBnp7hDXoM50fYQk7y
aTJ6/sXEJidUWcf6SPJ5ukWpH5dPlbBLoUzvmlOXYepar81o6NpQj66pxqXY1VWtF6q7GrpMe/0r
GvVCrL5rV01Nl6uqIaDSXv+z67W+8g31VoJG9RVI1vAlVNTxWq5eqnFavj4HyiOhuhpFiY/TlE8V
9nJFu6fmY3EtK8iDUvGAVNwvFdul4j6puEsq7pCKrVIxTSqmSsUUqZgsFeVSMUEqyqSiVCpUUqGQ
Cl4qSPlsLN/HfBTze5j/ivl5zI9hfhTzw5h3Yn4Q83bM92Heivl2zLdh3oD5WsxmzEsZz4cl1jul
YodU3CsV90jF3VJxu1RUSsUkqRgvFSVSoZYKpVRwUgHl5Vgewfwu5kOYX8L8IuaDmB/H/AjmPZgf
wrwN8+8xd2K2TM1PDEsMK964l7SXT1NvvEO98Sb1xhvUG53qjXb1xib1RlG9cYl642L1xnr1xjr1
CE2aRtAM0wzRDNakapI1iZp4TawmWhOpCddoNCqNQsNp8AHkS+BruJrayaTG96wZahoF3/e1+r0k
fO5in1I/mfjia6Bm/uRUX0mWj1vHdrO9xL+LkN9ep6Ub2T4gxH/dDVq5rK+H5Kz+KbXPXc2czidh
OCkGNWLBHvXwF9S0tRZbN7LWjbR1I2tNJbvnQH6NaX3DUDgH495Eztvbh7LKRtWdU7dLA5PrK5ZI
5R4uIhz1adDq6icnx7omMOXG6VKXa/cr6BdBI3A9R+IDIgoz7cqZlDOJdimAdUXTZ4fclbp8nE67
n2yXu2KxOQ5N+esdNH6l9NaAPXl4mUkdt5JbjLU/QiPiFswWzJthE2zi9kg0+E5vBh/WpsMXykP4
iulm7QVwNWIl/AcNt4a1lEEj9jci9UEsJ2CfGUvCeGwiG1h5DaxG3t9ye7gD3AHWOxH5TqcU0sXt
UR7CdsrvWngIPiT0+6RXwU3Ytw/eoqOQ8ybYCadJJl7ryWfkBDcHWwmdH/m0IPUmlPdpOAL/Jolk
AukiTyJNPLeSySLNtgJpDuL1FuNCr5nETpzETa5Hnsc5nitErk5uHbeN83EH+HrFBOUhVbyqWG1n
32Hl8LQbhxpSbrPwJbMRryt6uErXm4Qjc8l8YiW3kG0ow0FyAq/vuBxuIlqdXjfzDYpIxZfKFuWd
eB1SLVDfplEhbyWoYDAIkA5jUKsqnGMuymyBy+FKdl2F19Voy1WwFbbBHXA/7IL98BydE47Ch3Aa
rRODF9WrmJSSRXjV4+Umy8lqtMf6oOsG8ieyh+xH+V4l73LDUWvpsqP2kpTXclu4R7hXuT9zx7jj
3FfctzzwYfxSvpH38PfwO/g3+DcUUxXbFHco3le8ryRKH7NUvCpRdalqPV4b1GHqFvVq9e/Ut6kf
C8+FFNQrG/Wajm9uZuhETa7Gw3sX89ouvB6BR/E6BF9RPfDyy5rQq5RUkmqyAK96shhPAK3EQ5b1
aHQ3uZdsJ4+gLu/idZgcJR+Tf5Bv2HWaU3HJXFaPfnO4Wm4R18Ldwm3m/sQ9gBG5h3uSO8x9iDoe
506hjhF8PJ/ED+Or+Gq85vOX8Mv4a/md/AH+KH8C/RapGK+YoFiguBR1f1FxXPElepJT8sp0ZaFy
LF5WpUO5XLleeTtG9AnlCVUks0q8KkE1TrVWtVW1R3VEdUadpE5Wp+GVq85T16rt6nb1DvVx9Rea
B8MmhdnC3OHZsAPffx4/a/U+Sr/Lw12qMsBgchSj4Qo+BqkEuva4SLU9zMbtodKpa0kmeuoDOM2H
QY3iRVjEXwJ2ZSMfof4athOPYiV5gK+GB+EedTt5km/gT/D3KNNV4yR7clv4HepOdYP6C5T0O/4m
pVWdSyYp15Pt3ERc0W4yF74np+AynNnLjYYX4XpYR9rxgbNJ8yCJwrV2kBtO1ivv5HcrtvFVyuVk
FHpQqzzEXweFkITvRpmQhrGuxHdH+jLI0e9v8ytw9fP4gNCXx6jfIYp3yF34LuUHpZ/fRz4DMHSf
iD0BE79BzDMWxOni0nVxuhU8nFnBQTcoD/1YskJxiH4JfLr/qPo75QnkHIH8B4MexsHd5ZkKlSYs
Ij4xdbBOH8FFxyWN40tTtGP4fKUwIj0jR5UF+asiSak1ei9XuDsri9tLrivPBi5okGJYRpIhlkSO
SB8zTlUEgjbTOywnLtZbpEzxGm4ctpcbs7uoSLGPCCjriVLDmTMnSmNPlLIcF5+CWSqlTmw8wVpT
SllfSmmeMYWQ5ATMKekZI0lRQX6SmmAlOYkhvvKx25T0osIxGfo0dd9iOpmuXPp10o+38a23phOi
/+NPcXERmYQfrxPO6HL5STHaM6qE+Ci+LDL6p5hSUlwZFT10SllScsqUiZFROQXp5CdFypTuH3/6
u6JlzkPP7634ebIiI5y7alD0mZIII7dcN/iMQOJio7VcZ5bw8ydTl5QNjYzQl2YkJKQVjYqIGEnt
vglAswl9mIJPiLEwBebDErizPLpkQiGpX1BUMpafNSZ1AVr38VrgBg2doKzfyxXv0RrWTMMTaLkw
a83oijXh2trwFaNh0aChYwrHLkIjXzKSjMhP5eZGX4JnyfLE/IRl0cvKRywbeePcanXNsvK5+XzR
PqKDHMOJlFI0qeHECfZPsjX7l1JqgInMDbFnvj9B6dD+pbI/DIY8I1GPzBg5MqNwDFqcvlir1aqk
xJTkFJ66IIWo6H1SSkqyWqVPQ6pian9lMcE7dEZyQT6zPw4hdBzeY7c+LT2fYlIi77uhJrHtzX90
Lrzq0iUKwrkTE6YoLh86uGvtT7NLkpIXcrx6y5YdCx0PkPFWUrGFf/sqV86YH7V5k0fN2VRfOJPM
+sxWXr66e2IGEfPyjHzzwpyygkua/zDXVVvr0BhSkiOmjgmP6D7NPacoPjNFp9EItWGD8tatWLmo
YlHLi5PGqPKWnHk9X6OA1OGueV3TCxb8/PWNk/MyM19vmfoPAyZcsTv9RzWbcbVkQhbk4sodA8Xo
vfFwW3mOdtTobKPCEA+R0dqRWbl5+QVjItJTCotKSseVqVQkonjseKWwKiV9VXx8ioGul2GqiKEG
I6UrKi4pHRtRmDNqdNa4svGqbD4iOozfT2bjQTK/PGLkjdG5Q7O9OTnRhfu4BRBmYK7DfOa748xt
0opA+aQe6rW4lN52dFqSIi4R9GlQGJteWFQsOY96o5ium0TqnJHolqRkUpyQUMCTFKJMURJ1eoKa
50cm8HbS1P3y+0e7XyZN+dPXmK7dV/hs56jxYTG5rdU3f1B6Z92qSVxC5vdlBalk6qjuL0mNpvs9
Upfa/XCBcfphw30K67rfd299v/sVUoTNt60bHJnUfMPW3HsEZfrIsv3GdfdGkxm67idJZfdRkj68
+z2VQdv9zaiPu/fHkSHd18QRL93xdsIm1XG24w2Hyx9VxCclK9STwsntuJC0iFFoKVqP4pTlYZDI
x6pwdYXvJ6UwjIzbrYyPnRSB9VQyDpKIiEyUFDkz3Xow0L/DrQeztASoEXHTpEbMMxYX6pJIkq5Q
h6EMBfmA8a7D26JAFO9UFf884cx6sm8ZGXTgABm0jOw9s/6OA9eteW7Tpk1cddemqzY/TeK7v3l6
81WbuqwPr37mmdUPM21A1ca0CYNx5eEaPCWtglUKJW6j08ujVCsUqAp/I3ejIgzoK6LmToWBbY9n
4kphIqvRNZtnTI/TJajjinVxauXMnw4Q80Elf9CsGP/TgUas/HjmoGQ5UD7M5lLBwt1KlWovt6Y8
iuMTOZWC41UKlVJBW1IJl0gIpyC8Atvps+RGjleqFLCP4HnQ8DluGDDxcxZNa5W5WZprYl9Yq8lN
zVJiRRfG6XRE+fCP3Uque/6ZSO4Jchk9HZwZwl3m9/dIMAWeUi2hP3wqp0/mDPn6hDz1v3FxnRd1
ffT/6uKT/2vXIjyR/ioXO2GlkwM9n8jmQ+AzbIKRXSTXOVArv5TrPGiVH8p1RRCNEiKVP8h1FcSp
lHJdDStUyXJdA4mqW+R6uPJBnE2qR0C+aodcjyIzVe/TT9gV9P0gUjOK1env62I1haxOvyps0VTJ
dQLxml1ynYPoxCS5zkNRIpHriiAaJaQmFst1FaQlzpbragKJV8h1DWQmBerhEXWa++V6BFiSNsv1
KG5L0hlWD6dypt7K6hFUztR7WD0yqD2WyibXE7Aen/ooqycG0WjZ2JdYfWhQ+wg29m+0rknubY+U
571fyDcai4SZNrPb6XE2eYUKp9vldJu8NqcjV5hktwvzbM1Wr0eYJ3pEd7toyZ1vFYVFNkezBbNH
aHI6sLNDdIuCRfTYmh2iRWjsFGrcNo8w1WlvFT2CyWERKqwmtx3rk23Not3ZIdgcQl5pqZH1YSUv
V4gKjwqnrIMYOt22ZpvDZLd3sh9uWoQZbWabxSRMMzsdnmxhktvt7MCS8qj1mtwewesUzM5Wl11s
FR1ewYvc5BFecZmXcRaaTK025Ici0m4Psg3I7fbkopJsomzBLTrdzSaH7Up6Qydwi3bR5EEZJMnz
BZMnyGg99shmbL1WtxjQxOV2ttssomAS0AStTofN2eZBAXqM5RG9grNJsFGdcBaXG+3s8CIvxgnV
wTFMK6dDpPyQ1oWyOtEurLnNK7oFT6fHK7ZKpqbDRMkEjLrZbXJZbWYkb0MPovw4oMlkFj09NkdT
mzBLIjQ53cKcimyBiup1urOFFrGz0WlyW2gTckAN3SZzSyO6JZuqZBEsbls7NltsnhbR66UEJhdK
bvJ4pFuXm82ZjbZfli2IXnNuNrVeh4jBhWXvtE02O7Wa3YL6IT+nuY0pgRObbHYJG53LRGzosDks
zPdmu80lS0d17zChHRpNVJBcYZpDMFksNhrJ2UERa3OY7W1ofnniDpvXKjQ6EVAviRpNRZn1Whc9
ZWtCEzrMqI6nzWxl8rttkpucTrtkeSuCh8aOic4kNNupCWQhXbTFY7Z5PE6qXKNIzdfobG3Ebqto
bhFkzYIM0+pEpwQLZWs1NaPcPQKIJvS1JB6b1o7LBV2E0dDaiDJRZl630+5sZt6XyUSH2eY22zHy
HGhet4nRYRTaRTOdhkaMqZVGGFWGqcW853Y2mlh8u+w4A1Lj6sDVhGsZSRkZ1ttw1VsDgTXHaZPi
WOJhQSGkW9SqyS1e0UbXaFObg01L3RIUqb1BivZ20r6AJ+kaN6HTcEX1kdkVmE12gvccuxTq6kTa
JrSZie0dlLEZ5Wlqs9PJLSZJFGTXIdJdj4lusdERVFiLzS3K0tIOj7fTTpWtxtBtN7ltordT0rXV
ZTJ7qYca2+x20Ss5QkTbtMi7ldNNtxkW2ouoZaiIvcJhXeLXszk0i85W0eu2mQXJd9QqV7Sh4NQf
TntnM9sPcQtslmZjwuGGmNtrgXlic5vd5B4rzKwdy7b8hTgRtV1hrtHYQ5YjkwWtFnS2jYWZCSOs
2UYVQcFoWIqtJncL6oI9QbdN536WUFNTnyzAXUVk+7VXejQYkIGTTWB2tjlQSWrSXhbzO11OFhed
Vq/XNdZg6OjoyG0NdOfiGjV43W1oepdoYF42dARkN9Q723DT6KT7Hs5tk8KA+gXDu9Xm9UqPKipV
1YIZk9gWRG9wx7a0oQNR4g4MR2vQWFvP9mGhgYhbnstukrzOdjnUASPXgZuPEJjc6cDdPtM2ShBb
G+moXl6OAPU5RWLkbB9BN1PfB5aJPD2zp8xrHJMg04az4GOAmtxNH3K4RTrsTlPwpGz1yBuy0GN5
Z5sXdzp8JrXbzCKlsYp211kagQOc4KY/0QQ71IIXSwdYEN2I94OAxzEjXkVYmwk2MGO7EzyYm5BW
gAo22sXQhC02rDnwFVqAScjPjuU8bGsGK/Z52J2IpYjU7YgWpJyPfSL2LEI6B1Ja5JJSNzFu0sgO
NopSWhgPytXBeAjQCJ2INdhvY7RTcZwddRLZnaQRldXK9LLL7ZMZDxHvnchdYPMK+PJfipcxaJzU
kse0iqK/w8IckPrcEjqZJM2Mo4nZgcpH662yxDOgDW1pY5YWYBrWKR8PZDPLuZmVO+T7gBySd9xs
Li/2C2xUK1qfakQ5O5hPvLJsfefwYtsy1h+QmdaoRDZZPsmKgdEeWdqz7U3nz5U92asRlZPqTjVv
ZhLb4MqenoAGbmZtEe89sh2CbZ7PKD0DRFr/+MgOkpaWlPvZPnExLu3MCiLjL8hR0MqoaLy2IaVk
gf6RReX0Mo82MWkDfpJ0cTH0yJaX5OqVSfKONE+vr5yMd0A+ia9LtqtTjpde6jbmNzeTpBOzl3k6
OKoDs4l9oqCXdzNbmS6kotJL3NvkNSjZX5qBxoKZadM/zt2y7aQy2ApNzOMCzMHVRf0RsKqXtdOW
FhzTibHllPeUAJUkg+RDN5u7Bamk1ZLd4yUL8wpdTe0ytYWt8RbmF28PBxOzocA09MheC/S62PiA
ntly3C9jNUpnRo2ze2Kvg1nS3nN/Lm2b2JoJxJqdxY1bjkgL/Yk7atfrCUljExsTXKc2WcYsns3m
tTGP9q57M9LYUPq+tgv4vYPJR3VqZDXJIrlsN3EwOguzVWBPzh5gj6U1OlObHP19Ne5gHKxsd3DK
NclfwbxNsr0kyc4Vu9KasjHLmRmlWfaOh+1S1iD7u2XOgdXkZDYOjnmrXPP07DumHp1oxNt7oqCv
JV09NB62M3rYmgt4rlH2fLasbSuiNJquARqfwlk+O3fEtDKe4nksZWMx0Czbu78FRPYstZ5lvV5t
7fLTRVpF0t7QymSzB0nmZXsffbo1B639vtxE5gkbUppZRFvYc0qKXjcbEeAn7YV2ZomANoE9xsT8
La2BgGd6vdW79qg8jaw9sH+7WOR5evYv6dkhPZuk57IoP/EC3KT2NvlZb+23Y83BXluf/ThYDots
ieBet7ySaXkFchZ7JGhj1gloG1gt595Tz7WTSvHt7Bl39poMPMdN8kqzyE/egezs6qdb35XgDfEs
JfnVKfNtkuPMFHTuCEhslu1DbWHv0dwSdNbrfdJQXwXOer1Wt7BV3yQ/RSTLWljEiWfZNjCCRm6n
fEqjnq2Wd912JouN7XOdffxKo8/EuAXWUCOT185og1eEKMdNy1lnKzpD4DTTu2sv6omZgBXPZTmP
7MFe+fqfHJrZ2aiVtblZ1Ah91l0gVmj8meRTRbbscXo2aQ46H0qnwOY+uvVaziSf0M4VA/PYCmtj
+6MbxgI9adWyMnDKXyhrFIi7QuREe/pzyzmL27mfLdLKtgXtZiZ5D2tmvV45LixBu6XIdkc322+d
PWPO3dsEF/JeEojqwDpZIJ9VxKDztReC3xoMsgTOIA3MbP9xyJ4MROm5pJiPnnOx/TewX3Sy1eHF
+ljkbcA1Q69cdgrvOzpXfo4a2DxtctTTXdYQtJYN8rkh2O4GqGcSSicNulKks5akt63PbhBYL9Lu
3cqsEbBH3/eBKvrfCuG7Se8pKNAjnbEt7Cnm7bFxh7w7WgeY13aO04elZ0eUTnkuFlvBa733LCfI
pxSvvGKpD4R+mlMK6WyfieNGsWhsZU96y4ByOfrxDt1Kvdx7zyPSag6s+7OfJn21743PvnKNC7IB
1UTSRXobCES5u+dNTjpFOtiT0jSgpr3Pnr4nZOEcMe9kpznpTCe9J7UzbcQePlb21HL9go9mQe+n
DWLQnYmdaYI/f5BOvAGKj7HfwUaY2D5rAfq5hfSbCwB/Cf2/Hs+ZFOwXCEOAaJCa/vqA/RWLsL8r
YdbS/w9T/t8JtGXGVdoSVdjoNVPXnI4iam7bKu0obErnCMmLMIaplFnRPDdYCUaTKjxLRRRkVTFH
FNtqjXON2UEtQ+4ctmIIlLFrNkaDh+3hIrPCBHoZdUHMFIkLdnQ+/tmtm8kDmY8bdzT98fq0q45o
tq1KOmZcxb+AOWcbzxGOi53yzKCbj90wr7ri9NHWqVF5dxujekQlShRq5XomJL9AoUrgFk/KSzIm
0BtNQuQikX685xAqTC4xL9EYT5vVCRGVbe5Gk6PdZreLeTHIDVvDE1TzraYOr5g31KilDREJiVKD
UCG6vezTcvqBVd5w41DazScky93zba04i6mVfSBeMck4LCXKWJCXbxxjZGlxSlQevS3ILygsLSxd
bKwNEnZBbV6KMUmaP3qh6LbV2pod2cI0hzk3L8s4SpooLdDBpqKfNEpz1Ypu+vGWh066iqQFW4Uo
gV9FYgDbw7lVhMD9r+y++8+vCQ+HX3P9g2vbTj4y69tjz8U802x66i7LkPee+OGVggdWG6+vW77h
aMsHRbfHPPPW18v+1XHvcmfZMzc9HLXf+p190ytPzct5YOr4U4+9e+lSLbf1R0PLsLtP37Xl3sGH
uI9/M2Pep9ENX5cPWb4v6sOJLz1ybO1TS6+8PC+X37wyYfsU4fU8T9SinNeWjSm4OX5z/L4PrYYd
n396oGvD6OfX69Y2PXVt3SJn2zNlOzLWXvpKbFLZ1tVfzX8u3PFC98HpH+xTx92advXRCSPfGrbs
6615L3/7edqgoy/smVKxZfDSbcM2Hr/s1DdXf3vNA43kxlMzIz58M23h9ptfe2hd+0Pf7I/69/GZ
R7b9ZN32UOK4PWufe4LjMfDvWnnUuPKwcYxKgxGrVKoJUWQaM4wjAvdGsiZV/lDWafa4ctvpR9xo
d/qhLIudoQmE+BUaowoLjoBxEm0brhhrLDEWbRuzLX+NUR5udtv7jDZIsRIcKhWTcpGKRerQdEWk
MTwgBa8xRtPGGDoX/V2PCiXE+zgFRubdg4wpgfjmEyLn107CQCvJycspLDhrVfArV8L0lh++qjtQ
OSTv+s7NWbc8s+pB8tchM17zddU5jmlG3XXZoVduSvhCMS/qn1NGGqDEd/zlm2ZteSetMen0xGLd
bFfeim/Xl6zd8+WXt0L3GwtumTXiL/ePnHXlQ4+bJv179OtfvHzksg+eyLpuwqO3PXrk40X+px85
uPzUG5G3n7y1O+vtcfO02pKRpydOxzXsN67ivpDXcdTfs06+c3jUutR8ZdhlW9rXnb2O/1dWRv/l
aCwJXo6LQpzUYMyRJs34pUlr2R9ff3FJ7p6TOfWDt61Xrk6tbGq7dPkLe7eaM/zjK/50dVxJbPoC
z5G2kbYzs/YJS94O/2GbdvSJBQt1psPDjh5/sqDlpX9+cFex+FvtTZGP1Q5bcnVT4VJlV1V3+6xj
tSvuXCnc9tC6JXdqTn9m/OGbtOIZk/+nevOOairZ43iA0GGRDlKkRqToDcWg0psiIr0j0oIUpXcU
SVSaCAKGqpAEA4QqIkUpEgUEDIqCKMiCLjVIkaqIwkuAVXbVt++8c97bs3/lzJ3cm5k7v99nvt+Z
CdOTodZdzb0WJIR6lWmebBFV+Dy26IrSWu7YCU/aXFWv4ftpTWtExxWNcXq0zjuEiTdOer46fofU
dNIAHTraOCviKAMrINSxI8frA8m6DIzXyLwtNZHEU6IybOZj0K10o8rHVagyTbZOdTzs3ZnwFZ4x
SGn5bKZZjYYsqjasaK3HtHhPYKTW1AFhrCfPmE2dhPsrUJT2jpgor62U7AAQj/7LlGT5mpLUZKWu
sJmMsoA0IIWGoCWixX6WjIEBAXIuThvpx7ORfpRH/JsMpGv6jzJQ8c8ZSBnlmFDf/uOmVCJ2b8La
kUDzl7v8aQ3JoIcNnZ2ti7+8Wl8xbFJwBthblgIFelIGT14X4aw4q9to3HlhPIr3QsHu1FOceqsd
tRmaNMRsEzvay+cLfRYEjAUk9s57XDkt9qGugwc1zRLY5B7S9y7TOYYQcPVjXGC4eHFeRkR6xYek
PX6Ge4MEjmj2v69iFTHvDUGnI108vjA+jX8fVMeY3bfCbgHJcpJvDKe+FRHdiH14WUw29JlScH1K
gP3K3bFj3EzixJHnPYp79TW4VdgcwyVacW6zaU9936mNL7JGDjw7mxfs50G4bnQYUBKtwJbvdFaR
6UsskqaPeMVXaR/x2w2cz5pKXCmABHOQEfBpEwFsIALosopKLPsztWWXqSGN7W8MTCaA7++5zcwp
pu3jG+a/sWkp5bKHckQB9qeNuL1QYUBw88vcP9yig4oCuzaHie9bvamPT6CIZlCgu4+/R2AYBQ8H
YAAUCgCwLTzIU04wQreKf0OL/nIqp24g+I4dmj8uIJWbHuoATGLxVyRPflxDHcurWbuBFVE7a4LN
xiY5yns903INmykJbjfvn393PVowKfeiW2WLV7izeK+QyiAbVcpEWvN9ObesLHdIZtdB2fssVdYQ
gt44k5pymixe6kDhlP4FreGLbHVZpy2cSpBnMY5yIcdImXdcD2UZC0IZJLhy8ePJMnxjqhkuXI7W
tPBcIZhpzIeC2WvUrQLd9y10K+Oi7h+cMr92vOxLQfiZwOPlfMQ0RilRkNVVRw9YnQEHvYrlut3q
TTcmhvznCEur2epDDjyIEHD/cmNZFGrtVuf53oKd/vYqHfXvGfLEgEq6S+2VIiGcl4a2uFEIIHAA
AkvJSyowIgtApEftsOvynfXwzxE3ieS6bZi4/hjj//8fP+RfxPgGFVATzE1XFtL5lKZrqSRehbAv
2DvK5+YwP1ajTY5Naj84Jjr/3ipVtgp9uM159vNL4qFDtvj95h5rEmfU24lFg7Rnf4VeUc3d4etZ
t8ZhxOfR9LlLe5jdVsRo0jmivIi/TQYmKdcIx3DES7K55H0wF1wRbe/lXjAt8daWp/+C5P04euo0
q8lyw5zpo4bxZuCzCJQxVgi1Z6fhCyFq3FzUG5o7dosVv7ZZzcD1H5maV9+hkeJYv9r7niEpsja9
pRgmOxI+UhgyHIwGdXmqE57vj3+jyVGo5Cng+VrpbY8geKRQF9xmq6DsbSjI6lzDhE3ofmGurtcp
aJHv+5rjYExqUG7BczSZCg/J4qB8Sxh4MmcaNYGEitn7m6kxbrvv/W4ShP4uJAD7yXpBEQpTVIQq
UgQ8GfHy+39HAiL/j5KBE2DftBtMVk4B7mQpEEj+nR0bUwjZbNCbwl3P+Hi7/t4ypp+17GfdlCf/
6HfdFAdEN7uxc3uNK3xDfFDUiPGGKRD5niSsFJIwbJDkIVHkSv3QuprxTPiDHgnJ5eAnouud0pbH
O67XIG8rhcmBmgsZXri01+CWSQRCb0VCGpb+E1s10jTrHbK1YUdLYdOM18VEM4E640+uVHEEnh6k
O0gjVGeJQ/n4qovJm0+qd0dhFUMu9OKH/DQUDy96lekt7Q4QFnusxS9sUm2a1Z3XxdnKr+5Hd2Ye
JapzUmu6qT3TVaSWoPgZqzMWcVtoX23+4CJmKFuUbc0aqmmhHFluPT4yZRMmWfxBeh+7unKomtb5
AveRSDF33rGjKc2hOqaHMUYX41Kzm05FTDKuRtOcW870U5EpcMsgDsn9JkO9k03xCHxJhaN8LkZQ
CGLqQyTHHk0ekkqa/D4gP9LhNP8MvHDQMW4ZcG4yX6hpaEDgDYsq9AuYB8wl+VHG4ESbv3np6DJa
mpdnlbBihgD4v97CRQ1mEWYCmYGCyHZdG6QJMG8Inw3foQewfRVYtAAN+WNbXm5gzGX4zQJt7a1J
ZmbFZ0ioWpyz7guGghUneNtemk/KRzSfVs3vvtA93GJpVljF/4Q4Nodesaw+cu2wxCh+10B4zzJP
OMfrhasCUwwnKi9dvZtgXSdIRHWjriksJg+ux2Y7GOgbH4AcFBEwh30+Z8+d+nBAMPG9k6nKKP20
22zYVNITKxc4ik8fHT4ErxmClK21cVS3YomtJy/7LnS8LkZ60w/A+e8WLkc/YNTKmIOUeIRXEGQK
brntwpXHMHilc9be2p8pTJvHqZzXVAKo3RN9CeR3OHMIlltdGZ0LZ7/noMICm0slpMQeB9vS2j96
2ovve3suOXT36h1vXBKdgnWFgzQ7G4CkVSCjTGATY0xOejmPKf8ZBcG/W6H4pyDjG/sOKCoo7qe4
JRhZG5GLSpQiEPg/6cdWPc1P6v9SEnUi0pTL7LHzhKHBrmLUlV6VG7suPzwRvffE+wr/peKSWM+q
/gqxCOa2NpxBsoMYJ2llSfxG1aJ3cNnszE2VR81NNvbqxZUBCpB8Z4RTGMZ50TsW1eX966Pc5zdN
2IOd7vnGwzFpPHEFJxBdOm6jry1zNDo+DwRL7NUBQKO95yJQ7C+shfImjJjbYwewvWaZpztcOjI9
s1IcjhmyT+zrtrNzOGmaFyCHq7uoy5rAzx38mKE/K9+Xe8JwyuPLidteSdN7TGDKl1v19LmvGWfc
WnS/+XKQ0e9UYE5IgtAlr/TJ8ZO6xDdjfqzPXECpEdCMROY7nA2VXTNzQ6IzeEenGZi26sNNSYSk
SiG/kcTvvMs3GMz0eeGDzDqNZgSO89MJ510vfnrty0/Ih6dcFQcjMAAiJ+qHFMEE3vw7+Pe9WDDY
NH46gBaggVZDq0Qf3Gb8/niyztfLg3J139aJuIB9lASgxD859uU3DKHRNieqDWgC6l+dKHW0wk9P
7G08F+7//QMDf+QJlftmUcrZ9hlcJ8y9PYao28YrV7sfGJbuKz5vztovX/3Rc4x1VXRniBrOPfwO
KjLefl67+UI2/FyssclZJNfShYCX2Eb7DmrfJ5DTvPWmXLi4ppoRDBETdCPZT1WgyRJkWfXxIqTf
QWG1VzLcIas/f3VxXnNniYVe6ZGBZGVOa0b9uQVozK56cKIdB5yGxGzShWGJz2zoIxR2MXBLilZV
W8UJPrOLVsJ1fCmKmcLD1Gu0vYZF5nTrI8tIcxa3MUfq4Y1min3tE3QuYLpQb+P1I3XZk9q2Ma9L
maKWbFpkR0bP2x0dlQ+bEbuUwiJXaWzX+kDD2rr4eefwPkLn1JlcWBgUCX5MxuYjaioqAFH1j4Hj
HwD/bRkbjZgAuL5OqFJUUHoa2o3leco0uzX0jDRQlu0r5+SmfysxQ38BttdyA+LfbgRDyXmriLrt
EXV+wQiT8bRdQwahWV+d3wT4b7uFBeoKOKOVo/b/cDNO7+vGx082OTGQKImfn0b9emD1z2oSjKQC
AcoHn7+2uapq7BGfbCVS7tTXSwJ1O3HdECd0algOOoQ6mz94pk0KtCpgWvvlPsnm1HW2mMaPftav
Wm8KFw6IOV0QeZRYgWe/uOuI7fIFosHNalmIbVayhGydz6eWXzHoIhquPD/2JT0R4i7NUWec3oup
dcbQ57wxZ1vmJ6ZjVyNb3Cp0lnOOyWbkxWeQhvlCPtytm87MqiyfNCwSNPIuF1G/9dIkie2+JJ9c
qU/9RGyRccp4ScIs8h7fyTBSevQdaFNktS58RasJT8dgV6Jnsc/bfJB/NLL8RQ6srQzAO6Zm+H0h
JazBqbAJT6wk1ns8R6JrZM492W9S7dn+sp/v7cOWZAySLIuQVKvfRowOiqSaIl+aoIT3qf/JouYP
llJZ6Bg2G0BNpgzaBuDbHnvM37Z2qMih97WGFspGme/JE7y8vII8VP6ALZm/20KPA7xjtBSHPsrJ
cND1Zmi1ve9bxR+EgJ/rJx7eTwujozSc5WrzOk9D5YYbcaK2k7+tTpjoKuC8qs8+GMi4eOejFLc+
fpokb7xYq5Gjb4CM4siruNyNM2A5lZBE4nNWH0EtjDRYTb5E8SphDjSswIQx/RPzJ23QryYJOdc5
WF0VgypCEmUr+5N6Fj3jJuATs3ifElsca6o75EX+cEXxOnJIVaiFaNQwIJogEAwx5b1ry8miZZMi
WRu0tnO5xIoteNWRlPyu/Ty7Az+2lbcv/r3KW5y+bsAINf6xnHtxub4oi0v107bEzkvXM6WnqHSc
j2b0BN3+rUc5MTHLAjLVyk9j/6q97SrdeVLVYn1Xc/rl0lVJTnxilnr2vwDOyM6hDQplbmRzdHJl
YW0NCmVuZG9iag0KOTQ0IDAgb2JqDQpbIDBbIDUwMF0gIDE5MFsgNzk0XSBdIA0KZW5kb2JqDQo5
NDUgMCBvYmoNCjw8L1R5cGUvWFJlZi9TaXplIDk0NS9XWyAxIDQgMl0gL1Jvb3QgMSAwIFIvSW5m
byA3NyAwIFIvSURbPDhDMTIzOTlGNzlGQkVCNDZCNzU4NUFERjNEOTQ1NjUzPjw4QzEyMzk5Rjc5
RkJFQjQ2Qjc1ODVBREYzRDk0NTY1Mz5dIC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDE5MTc+
Pg0Kc3RyZWFtDQp4nDXZBZgV5QLH4f0v2AWKXkzAQkQFBEWxECwMjIuJXhUxMBDEJMQEExHzYmOL
jYEoNohid6MgKoLdAXj43mGfffZ95uyc2T1nZr7ffHPq6mpf8+en9rNxXd0ChhRiqb5nYZF1Ct1/
KOx1aqH3hMLAzwuDRhYGD8fEwpCjCqcfUBg6r3DBuMKILReQTC8sc2+h0b6YVWjcGt8Xll8anQsr
3Fpo0hEDC723LRw9qtB3bOH4nXFRoV8fDEN5DTkhuBEzCgOuKJxYXlhO+qkwqFth0ooYjfGFyfvj
5sILnj5lNXTCJ4UXWxZespWpJxWm9Sh89lDh6z0Ks64tzPbPz5lTmLtDYd4dC6hvOKaw0sxC0+0L
zUYUmn9XaPVooXXTQpvyT9S3W7/QvkWhQ9/C5gMKnZ4udKkt1de+98me2Av/rVHXo245VKv0qD2h
64iyVHswqEcDNMSiWASLYzEsiSWwLJbC0lgGJ6GRv763pcZYHiugCVbESlgV/0FTrIxVsDpWQzOs
geZYEy2wFtbB2lgX66ElWmF9tMaG2AAboQ3aoh02Rge0xyboiE2xGTphc2yBLbE1tsI22Bad0QVd
sT22w47YAd2wE3bBztgVu2F3dMce2At7ogeqw63axftgX+yP/dATB+BA/A8H4WAcgkNxGHqhN47A
4TgSfXAUjsHROBZ9cRz64XicgP44EQNwK052QFcv8xScitMwEIMxCKdjCM7AUNyCm3EWzsSFOAdn
YxjOxXkYjgtwPi7GRbgcl2AELsVIXIZRuBJXYAyuxlW4DqPxf1yLa3ADrsdNuLGQaiy4zdtaHTa3
4w7cibtwN8biXtyD+3EfvscneBAP4GM8hHF4DI/gYYzHo3gcE/ABJuIJvIGn8CSewdN4Hs/hWUzG
JLyIKXgBU/ESXscreBmv4VW8hTfxPt7B23gP7+IjfIhP8R0+wzR8i+n4HHPwBWbgS8zE1/gKs/EN
ZuEH/IQf8TN+xS/4Db/jD/yFP/EP/sY8zMV8x6AoRhSjhtHGyGC0MdoYUYwoRhQjipHBiGIkMqIY
SU4jqGEMqlnBGWCojChGFCOKUcPIYEQxShlRjChGFGOgjtE7EhmJjCxFGyOYkcjoZnQsghnBjChG
KSOfEcyoaCQyuhlRjGBGRSOYkc9oYwQzchaljFJGIiOR0c1IZAQzohjBjGBGIqObEcUoZTQu2hjd
jDZGN6N/kcjIZyQyghkVjY6Vi6/abhS+SGR1+VNFoxrkFq5S7XBtjDZGDSORcRrmYJuuVpHISGS0
MUoZUYxSRhsjmJHISGQ0JxIZ4YtSRj4jmBHMCGYEM8IXiYx8xqVf5DMSmZOheJHICGaUMkoZpYxS
RuqihtHNyGCUMjIYiYziRRQjihHFiGLUMNIaUYwoRhQjihHFiGJEMaoWbYw2RhQjilHDqGF0M0oZ
bYwoRhQjiqmiKFkRqbjyiKuEGKEjkbkNShKljG5GIqOb0cYoZVQ0ShkVjURGIiNLkchIZLQx2hht
jDZGFKOiUbyIYnQzahjBjBpGKSN80cYoXkQxmhpRjChG/yKKEcWoYdQwahg1jBpGDaNxUcOoYdQw
ahh9z/vlxKvmHZlWlhaesKIY/YsaRviieFHDKF7UMFKXr216ZVRDuijmGw9Wo77eZo4Hq0i5xIlA
RykjnxHM/OQJ9QgWTB97jq7mhmWqV6MhFsdiWBRLYgksg6WxFJbDslgJjWEaWKdxZf5XY0U0wX5Y
1bt7oKXVsDrWQDO0QHOshTWxDtbGvmiLllgXbdAK62EjtMb62BAboB22wpZoj42xBTZBB3RCR2yK
zbEZtsZu2BW7oDO2wc7ogm2xHbqiG3bA9tgJO6I79sHe6IE9sDvErc59hjp3Hcolf4397biDLB2A
nqj2ZvU7HSsTvxqH4hAchl64GlfhcPTG8TgSR6Av+uAoHIOjcRyORX/0w5UYgBNgxlduaNQ4Eafi
FIzAQJyGMzEYg3A6huAMDMXZOAvDcC7OwXkYjotxAc7HRbgQI3EJrsAoXIrLcRkmYrS9We2ja3At
rsP1uBE3YAxuwi24GU/gcZjxlWl1jQm4A7fjAdyFO3E3xuJe3IP7cR/G4UE8hofxEMbjUTyCF/Gk
t6A6Wp/C03gGz+J5PIfJmIQpeAF/4SWbro75qXgZr+BVvI7X8CbewNt4C+/gPbyLqlwf4gN8hE/w
MT7FZ9C4MqurMQPT8QW+xEx8hVmoqlYFrErWbHyHb/EDvseP+BlVuX7Bb/gVv+NP/OH9rAarvy1V
A8s/mIt5mG8VNUx1i9QQG6WM1EUUy6SwhhpGMKOUUcpUtzrVMIIZpYxSRiIjkWU6V0MNo5RRw4Wz
QRWNUkb44mKhzP9qVMFcBRIZ3YxuRvEimBHMCGYEM2oYwYx8RgajjdHGiGJEMaIYUYzURWgjrVHD
CGZkMEoZ3YwaRg2jhlHDqGh0M6oWiYz6RhQjilHDqGEkMsIXbYzwRRQjkRHFyG5kN8KX7rVjpL9b
+APaFJ4rH1HUT2q1gAYblU9NGrTtVWg3tbBx+YyhwaGvF3rNLVw5oa7uX/K2AYQNCmVuZHN0cmVh
bQ0KZW5kb2JqDQp4cmVmDQowIDk0Ng0KMDAwMDAwMDA3OCA2NTUzNSBmDQowMDAwMDAwMDE3IDAw
MDAwIG4NCjAwMDAwMDAxMjUgMDAwMDAgbg0KMDAwMDAwMDI3MyAwMDAwMCBuDQowMDAwMDAwNjAz
IDAwMDAwIG4NCjAwMDAwMDEzMTcgMDAwMDAgbg0KMDAwMDAyMDIwOCAwMDAwMCBuDQowMDAwMDIx
MTEyIDAwMDAwIG4NCjAwMDAwMjU3ODYgMDAwMDAgbg0KMDAwMDAzMTQ1NyAwMDAwMCBuDQowMDAw
MDMxNjMyIDAwMDAwIG4NCjAwMDAwMzE4NzkgMDAwMDAgbg0KMDAwMDAzMTkzMyAwMDAwMCBuDQow
MDAwMDMyMTA0IDAwMDAwIG4NCjAwMDAwMzIzNDYgMDAwMDAgbg0KMDAwMDAzMjc2NiAwMDAwMCBu
DQowMDAwMDM1NTA3IDAwMDAwIG4NCjAwMDAwMzY0MTIgMDAwMDAgbg0KMDAwMDA2NjAxOCAwMDAw
MCBuDQowMDAwMDY5MDM4IDAwMDAwIG4NCjAwMDAwNjk3MTkgMDAwMDAgbg0KMDAwMDA2OTg2NSAw
MDAwMCBuDQowMDAwMDY5OTMxIDAwMDAwIG4NCjAwMDAwNzAxMjcgMDAwMDAgbg0KMDAwMDA3MDE1
NiAwMDAwMCBuDQowMDAwMDcwMjA4IDAwMDAwIG4NCjAwMDAwNzA1NjUgMDAwMDAgbg0KMDAwMDA3
MDcxMSAwMDAwMCBuDQowMDAwMDcwNzc4IDAwMDAwIG4NCjAwMDAwOTEyMDEgMDAwMDAgbg0KMDAw
MDA5MjgxOCAwMDAwMCBuDQowMDAwMDkzODY3IDAwMDAwIG4NCjAwMDAwOTQwMjYgMDAwMDAgbg0K
MDAwMDA5NDA5MiAwMDAwMCBuDQowMDAwMDk0MzEzIDAwMDAwIG4NCjAwMDAwOTQzNDIgMDAwMDAg
bg0KMDAwMDA5NDM5NCAwMDAwMCBuDQowMDAwMDk0NzIxIDAwMDAwIG4NCjAwMDAwOTQ4ODAgMDAw
MDAgbg0KMDAwMDA5NDk0NyAwMDAwMCBuDQowMDAwMDk1MTI1IDAwMDAwIG4NCjAwMDAwOTUzNzYg
MDAwMDAgbg0KMDAwMDA5NTczMCAwMDAwMCBuDQowMDAwMDk3MDk3IDAwMDAwIG4NCjAwMDAxMTU5
ODkgMDAwMDAgbg0KMDAwMDExNjEyMiAwMDAwMCBuDQowMDAwMTE2MTUyIDAwMDAwIG4NCjAwMDAx
MTYzMTMgMDAwMDAgbg0KMDAwMDExNjM4NyAwMDAwMCBuDQowMDAwMTE2NjI5IDAwMDAwIG4NCjAw
MDAxMTY3NjQgMDAwMDAgbg0KMDAwMDExNjc5NCAwMDAwMCBuDQowMDAwMTE2OTU3IDAwMDAwIG4N
CjAwMDAxMTcwMzEgMDAwMDAgbg0KMDAwMDExNzI2OSAwMDAwMCBuDQowMDAwMTE3NjIxIDAwMDAw
IG4NCjAwMDAxMjI3MDggMDAwMDAgbg0KMDAwMDEyMzA2MCAwMDAwMCBuDQowMDAwMTI1MDA4IDAw
MDAwIG4NCjAwMDAxMjUzNDAgMDAwMDAgbg0KMDAwMDEyNTgzNiAwMDAwMCBuDQowMDAwMTI2MTg4
IDAwMDAwIG4NCjAwMDAxMzAzNzQgMDAwMDAgbg0KMDAwMDEzMDcyOCAwMDAwMCBuDQowMDAwMTMy
MjU4IDAwMDAwIG4NCjAwMDAxMzY5MzMgMDAwMDAgbg0KMDAwMDEzNzI4NSAwMDAwMCBuDQowMDAw
MTM5MTUwIDAwMDAwIG4NCjAwMDAxMzk1MDIgMDAwMDAgbg0KMDAwMDE0MTc1MSAwMDAwMCBuDQow
MDAwMTQyMTA0IDAwMDAwIG4NCjAwMDAxNDMzMjUgMDAwMDAgbg0KMDAwMDE0MzY1OCAwMDAwMCBu
DQowMDAwMTQ0MTYxIDAwMDAwIG4NCjAwMDAxNDQ0OTQgMDAwMDAgbg0KMDAwMDE0NTc3OSAwMDAw
MCBuDQowMDAwMTQ2MTEyIDAwMDAwIG4NCjAwMDAxNDgwODMgMDAwMDAgbg0KMDAwMDAwMDA3OSA2
NTUzNSBmDQowMDAwMDAwMDgwIDY1NTM1IGYNCjAwMDAwMDAwODEgNjU1MzUgZg0KMDAwMDAwMDA4
MiA2NTUzNSBmDQowMDAwMDAwMDgzIDY1NTM1IGYNCjAwMDAwMDAwODQgNjU1MzUgZg0KMDAwMDAw
MDA4NSA2NTUzNSBmDQowMDAwMDAwMDg2IDY1NTM1IGYNCjAwMDAwMDAwODcgNjU1MzUgZg0KMDAw
MDAwMDA4OCA2NTUzNSBmDQowMDAwMDAwMDg5IDY1NTM1IGYNCjAwMDAwMDAwOTAgNjU1MzUgZg0K
MDAwMDAwMDA5MSA2NTUzNSBmDQowMDAwMDAwMDkyIDY1NTM1IGYNCjAwMDAwMDAwOTMgNjU1MzUg
Zg0KMDAwMDAwMDA5NCA2NTUzNSBmDQowMDAwMDAwMDk1IDY1NTM1IGYNCjAwMDAwMDAwOTYgNjU1
MzUgZg0KMDAwMDAwMDA5NyA2NTUzNSBmDQowMDAwMDAwMDk4IDY1NTM1IGYNCjAwMDAwMDAwOTkg
NjU1MzUgZg0KMDAwMDAwMDEwMCA2NTUzNSBmDQowMDAwMDAwMTAxIDY1NTM1IGYNCjAwMDAwMDAx
MDIgNjU1MzUgZg0KMDAwMDAwMDEwMyA2NTUzNSBmDQowMDAwMDAwMTA0IDY1NTM1IGYNCjAwMDAw
MDAxMDUgNjU1MzUgZg0KMDAwMDAwMDEwNiA2NTUzNSBmDQowMDAwMDAwMTA3IDY1NTM1IGYNCjAw
MDAwMDAxMDggNjU1MzUgZg0KMDAwMDAwMDEwOSA2NTUzNSBmDQowMDAwMDAwMTEwIDY1NTM1IGYN
CjAwMDAwMDAxMTEgNjU1MzUgZg0KMDAwMDAwMDExMiA2NTUzNSBmDQowMDAwMDAwMTEzIDY1NTM1
IGYNCjAwMDAwMDAxMTQgNjU1MzUgZg0KMDAwMDAwMDExNSA2NTUzNSBmDQowMDAwMDAwMTE2IDY1
NTM1IGYNCjAwMDAwMDAxMTcgNjU1MzUgZg0KMDAwMDAwMDExOCA2NTUzNSBmDQowMDAwMDAwMTE5
IDY1NTM1IGYNCjAwMDAwMDAxMjAgNjU1MzUgZg0KMDAwMDAwMDEyMSA2NTUzNSBmDQowMDAwMDAw
MTIyIDY1NTM1IGYNCjAwMDAwMDAxMjMgNjU1MzUgZg0KMDAwMDAwMDEyNCA2NTUzNSBmDQowMDAw
MDAwMTI1IDY1NTM1IGYNCjAwMDAwMDAxMjYgNjU1MzUgZg0KMDAwMDAwMDEyNyA2NTUzNSBmDQow
MDAwMDAwMTI4IDY1NTM1IGYNCjAwMDAwMDAxMjkgNjU1MzUgZg0KMDAwMDAwMDEzMCA2NTUzNSBm
DQowMDAwMDAwMTMxIDY1NTM1IGYNCjAwMDAwMDAxMzIgNjU1MzUgZg0KMDAwMDAwMDEzMyA2NTUz
NSBmDQowMDAwMDAwMTM0IDY1NTM1IGYNCjAwMDAwMDAxMzUgNjU1MzUgZg0KMDAwMDAwMDEzNiA2
NTUzNSBmDQowMDAwMDAwMTM3IDY1NTM1IGYNCjAwMDAwMDAxMzggNjU1MzUgZg0KMDAwMDAwMDEz
OSA2NTUzNSBmDQowMDAwMDAwMTQwIDY1NTM1IGYNCjAwMDAwMDAxNDEgNjU1MzUgZg0KMDAwMDAw
MDE0MiA2NTUzNSBmDQowMDAwMDAwMTQzIDY1NTM1IGYNCjAwMDAwMDAxNDQgNjU1MzUgZg0KMDAw
MDAwMDE0NSA2NTUzNSBmDQowMDAwMDAwMTQ2IDY1NTM1IGYNCjAwMDAwMDAxNDcgNjU1MzUgZg0K
MDAwMDAwMDE0OCA2NTUzNSBmDQowMDAwMDAwMTQ5IDY1NTM1IGYNCjAwMDAwMDAxNTAgNjU1MzUg
Zg0KMDAwMDAwMDE1MSA2NTUzNSBmDQowMDAwMDAwMTUyIDY1NTM1IGYNCjAwMDAwMDAxNTMgNjU1
MzUgZg0KMDAwMDAwMDE1NCA2NTUzNSBmDQowMDAwMDAwMTU1IDY1NTM1IGYNCjAwMDAwMDAxNTYg
NjU1MzUgZg0KMDAwMDAwMDE1NyA2NTUzNSBmDQowMDAwMDAwMTU4IDY1NTM1IGYNCjAwMDAwMDAx
NTkgNjU1MzUgZg0KMDAwMDAwMDE2MCA2NTUzNSBmDQowMDAwMDAwMTYxIDY1NTM1IGYNCjAwMDAw
MDAxNjIgNjU1MzUgZg0KMDAwMDAwMDE2MyA2NTUzNSBmDQowMDAwMDAwMTY0IDY1NTM1IGYNCjAw
MDAwMDAxNjUgNjU1MzUgZg0KMDAwMDAwMDE2NiA2NTUzNSBmDQowMDAwMDAwMTY3IDY1NTM1IGYN
CjAwMDAwMDAxNjggNjU1MzUgZg0KMDAwMDAwMDE2OSA2NTUzNSBmDQowMDAwMDAwMTcwIDY1NTM1
IGYNCjAwMDAwMDAxNzEgNjU1MzUgZg0KMDAwMDAwMDE3MiA2NTUzNSBmDQowMDAwMDAwMTczIDY1
NTM1IGYNCjAwMDAwMDAxNzQgNjU1MzUgZg0KMDAwMDAwMDE3NSA2NTUzNSBmDQowMDAwMDAwMTc2
IDY1NTM1IGYNCjAwMDAwMDAxNzcgNjU1MzUgZg0KMDAwMDAwMDE3OCA2NTUzNSBmDQowMDAwMDAw
MTc5IDY1NTM1IGYNCjAwMDAwMDAxODAgNjU1MzUgZg0KMDAwMDAwMDE4MSA2NTUzNSBmDQowMDAw
MDAwMTgyIDY1NTM1IGYNCjAwMDAwMDAxODMgNjU1MzUgZg0KMDAwMDAwMDE4NCA2NTUzNSBmDQow
MDAwMDAwMTg1IDY1NTM1IGYNCjAwMDAwMDAxODYgNjU1MzUgZg0KMDAwMDAwMDE4NyA2NTUzNSBm
DQowMDAwMDAwMTg4IDY1NTM1IGYNCjAwMDAwMDAxODkgNjU1MzUgZg0KMDAwMDAwMDE5MCA2NTUz
NSBmDQowMDAwMDAwMTkxIDY1NTM1IGYNCjAwMDAwMDAxOTIgNjU1MzUgZg0KMDAwMDAwMDE5MyA2
NTUzNSBmDQowMDAwMDAwMTk0IDY1NTM1IGYNCjAwMDAwMDAxOTUgNjU1MzUgZg0KMDAwMDAwMDE5
NiA2NTUzNSBmDQowMDAwMDAwMTk3IDY1NTM1IGYNCjAwMDAwMDAxOTggNjU1MzUgZg0KMDAwMDAw
MDE5OSA2NTUzNSBmDQowMDAwMDAwMjAwIDY1NTM1IGYNCjAwMDAwMDAyMDEgNjU1MzUgZg0KMDAw
MDAwMDIwMiA2NTUzNSBmDQowMDAwMDAwMjAzIDY1NTM1IGYNCjAwMDAwMDAyMDQgNjU1MzUgZg0K
MDAwMDAwMDIwNSA2NTUzNSBmDQowMDAwMDAwMjA2IDY1NTM1IGYNCjAwMDAwMDAyMDcgNjU1MzUg
Zg0KMDAwMDAwMDIwOCA2NTUzNSBmDQowMDAwMDAwMjA5IDY1NTM1IGYNCjAwMDAwMDAyMTAgNjU1
MzUgZg0KMDAwMDAwMDIxMSA2NTUzNSBmDQowMDAwMDAwMjEyIDY1NTM1IGYNCjAwMDAwMDAyMTMg
NjU1MzUgZg0KMDAwMDAwMDIxNCA2NTUzNSBmDQowMDAwMDAwMjE1IDY1NTM1IGYNCjAwMDAwMDAy
MTYgNjU1MzUgZg0KMDAwMDAwMDIxNyA2NTUzNSBmDQowMDAwMDAwMjE4IDY1NTM1IGYNCjAwMDAw
MDAyMTkgNjU1MzUgZg0KMDAwMDAwMDIyMCA2NTUzNSBmDQowMDAwMDAwMjIxIDY1NTM1IGYNCjAw
MDAwMDAyMjIgNjU1MzUgZg0KMDAwMDAwMDIyMyA2NTUzNSBmDQowMDAwMDAwMjI0IDY1NTM1IGYN
CjAwMDAwMDAyMjUgNjU1MzUgZg0KMDAwMDAwMDIyNiA2NTUzNSBmDQowMDAwMDAwMjI3IDY1NTM1
IGYNCjAwMDAwMDAyMjggNjU1MzUgZg0KMDAwMDAwMDIyOSA2NTUzNSBmDQowMDAwMDAwMjMwIDY1
NTM1IGYNCjAwMDAwMDAyMzEgNjU1MzUgZg0KMDAwMDAwMDIzMiA2NTUzNSBmDQowMDAwMDAwMjMz
IDY1NTM1IGYNCjAwMDAwMDAyMzQgNjU1MzUgZg0KMDAwMDAwMDIzNSA2NTUzNSBmDQowMDAwMDAw
MjM2IDY1NTM1IGYNCjAwMDAwMDAyMzcgNjU1MzUgZg0KMDAwMDAwMDIzOCA2NTUzNSBmDQowMDAw
MDAwMjM5IDY1NTM1IGYNCjAwMDAwMDAyNDAgNjU1MzUgZg0KMDAwMDAwMDI0MSA2NTUzNSBmDQow
MDAwMDAwMjQyIDY1NTM1IGYNCjAwMDAwMDAyNDMgNjU1MzUgZg0KMDAwMDAwMDI0NCA2NTUzNSBm
DQowMDAwMDAwMjQ1IDY1NTM1IGYNCjAwMDAwMDAyNDYgNjU1MzUgZg0KMDAwMDAwMDI0NyA2NTUz
NSBmDQowMDAwMDAwMjQ4IDY1NTM1IGYNCjAwMDAwMDAyNDkgNjU1MzUgZg0KMDAwMDAwMDI1MCA2
NTUzNSBmDQowMDAwMDAwMjUxIDY1NTM1IGYNCjAwMDAwMDAyNTIgNjU1MzUgZg0KMDAwMDAwMDI1
MyA2NTUzNSBmDQowMDAwMDAwMjU0IDY1NTM1IGYNCjAwMDAwMDAyNTUgNjU1MzUgZg0KMDAwMDAw
MDI1NiA2NTUzNSBmDQowMDAwMDAwMjU3IDY1NTM1IGYNCjAwMDAwMDAyNTggNjU1MzUgZg0KMDAw
MDAwMDI1OSA2NTUzNSBmDQowMDAwMDAwMjYwIDY1NTM1IGYNCjAwMDAwMDAyNjEgNjU1MzUgZg0K
MDAwMDAwMDI2MiA2NTUzNSBmDQowMDAwMDAwMjYzIDY1NTM1IGYNCjAwMDAwMDAyNjQgNjU1MzUg
Zg0KMDAwMDAwMDI2NSA2NTUzNSBmDQowMDAwMDAwMjY2IDY1NTM1IGYNCjAwMDAwMDAyNjcgNjU1
MzUgZg0KMDAwMDAwMDI2OCA2NTUzNSBmDQowMDAwMDAwMjY5IDY1NTM1IGYNCjAwMDAwMDAyNzAg
NjU1MzUgZg0KMDAwMDAwMDI3MSA2NTUzNSBmDQowMDAwMDAwMjcyIDY1NTM1IGYNCjAwMDAwMDAy
NzMgNjU1MzUgZg0KMDAwMDAwMDI3NCA2NTUzNSBmDQowMDAwMDAwMjc1IDY1NTM1IGYNCjAwMDAw
MDAyNzYgNjU1MzUgZg0KMDAwMDAwMDI3NyA2NTUzNSBmDQowMDAwMDAwMjc4IDY1NTM1IGYNCjAw
MDAwMDAyNzkgNjU1MzUgZg0KMDAwMDAwMDI4MCA2NTUzNSBmDQowMDAwMDAwMjgxIDY1NTM1IGYN
CjAwMDAwMDAyODIgNjU1MzUgZg0KMDAwMDAwMDI4MyA2NTUzNSBmDQowMDAwMDAwMjg0IDY1NTM1
IGYNCjAwMDAwMDAyODUgNjU1MzUgZg0KMDAwMDAwMDI4NiA2NTUzNSBmDQowMDAwMDAwMjg3IDY1
NTM1IGYNCjAwMDAwMDAyODggNjU1MzUgZg0KMDAwMDAwMDI4OSA2NTUzNSBmDQowMDAwMDAwMjkw
IDY1NTM1IGYNCjAwMDAwMDAyOTEgNjU1MzUgZg0KMDAwMDAwMDI5MiA2NTUzNSBmDQowMDAwMDAw
MjkzIDY1NTM1IGYNCjAwMDAwMDAyOTQgNjU1MzUgZg0KMDAwMDAwMDI5NSA2NTUzNSBmDQowMDAw
MDAwMjk2IDY1NTM1IGYNCjAwMDAwMDAyOTcgNjU1MzUgZg0KMDAwMDAwMDI5OCA2NTUzNSBmDQow
MDAwMDAwMjk5IDY1NTM1IGYNCjAwMDAwMDAzMDAgNjU1MzUgZg0KMDAwMDAwMDMwMSA2NTUzNSBm
DQowMDAwMDAwMzAyIDY1NTM1IGYNCjAwMDAwMDAzMDMgNjU1MzUgZg0KMDAwMDAwMDMwNCA2NTUz
NSBmDQowMDAwMDAwMzA1IDY1NTM1IGYNCjAwMDAwMDAzMDYgNjU1MzUgZg0KMDAwMDAwMDMwNyA2
NTUzNSBmDQowMDAwMDAwMzA4IDY1NTM1IGYNCjAwMDAwMDAzMDkgNjU1MzUgZg0KMDAwMDAwMDMx
MCA2NTUzNSBmDQowMDAwMDAwMzExIDY1NTM1IGYNCjAwMDAwMDAzMTIgNjU1MzUgZg0KMDAwMDAw
MDMxMyA2NTUzNSBmDQowMDAwMDAwMzE0IDY1NTM1IGYNCjAwMDAwMDAzMTUgNjU1MzUgZg0KMDAw
MDAwMDMxNiA2NTUzNSBmDQowMDAwMDAwMzE3IDY1NTM1IGYNCjAwMDAwMDAzMTggNjU1MzUgZg0K
MDAwMDAwMDMxOSA2NTUzNSBmDQowMDAwMDAwMzIwIDY1NTM1IGYNCjAwMDAwMDAzMjEgNjU1MzUg
Zg0KMDAwMDAwMDMyMiA2NTUzNSBmDQowMDAwMDAwMzIzIDY1NTM1IGYNCjAwMDAwMDAzMjQgNjU1
MzUgZg0KMDAwMDAwMDMyNSA2NTUzNSBmDQowMDAwMDAwMzI2IDY1NTM1IGYNCjAwMDAwMDAzMjcg
NjU1MzUgZg0KMDAwMDAwMDMyOCA2NTUzNSBmDQowMDAwMDAwMzI5IDY1NTM1IGYNCjAwMDAwMDAz
MzAgNjU1MzUgZg0KMDAwMDAwMDMzMSA2NTUzNSBmDQowMDAwMDAwMzMyIDY1NTM1IGYNCjAwMDAw
MDAzMzMgNjU1MzUgZg0KMDAwMDAwMDMzNCA2NTUzNSBmDQowMDAwMDAwMzM1IDY1NTM1IGYNCjAw
MDAwMDAzMzYgNjU1MzUgZg0KMDAwMDAwMDMzNyA2NTUzNSBmDQowMDAwMDAwMzM4IDY1NTM1IGYN
CjAwMDAwMDAzMzkgNjU1MzUgZg0KMDAwMDAwMDM0MCA2NTUzNSBmDQowMDAwMDAwMzQxIDY1NTM1
IGYNCjAwMDAwMDAzNDIgNjU1MzUgZg0KMDAwMDAwMDM0MyA2NTUzNSBmDQowMDAwMDAwMzQ0IDY1
NTM1IGYNCjAwMDAwMDAzNDUgNjU1MzUgZg0KMDAwMDAwMDM0NiA2NTUzNSBmDQowMDAwMDAwMzQ3
IDY1NTM1IGYNCjAwMDAwMDAzNDggNjU1MzUgZg0KMDAwMDAwMDM0OSA2NTUzNSBmDQowMDAwMDAw
MzUwIDY1NTM1IGYNCjAwMDAwMDAzNTEgNjU1MzUgZg0KMDAwMDAwMDM1MiA2NTUzNSBmDQowMDAw
MDAwMzUzIDY1NTM1IGYNCjAwMDAwMDAzNTQgNjU1MzUgZg0KMDAwMDAwMDM1NSA2NTUzNSBmDQow
MDAwMDAwMzU2IDY1NTM1IGYNCjAwMDAwMDAzNTcgNjU1MzUgZg0KMDAwMDAwMDM1OCA2NTUzNSBm
DQowMDAwMDAwMzU5IDY1NTM1IGYNCjAwMDAwMDAzNjAgNjU1MzUgZg0KMDAwMDAwMDM2MSA2NTUz
NSBmDQowMDAwMDAwMzYyIDY1NTM1IGYNCjAwMDAwMDAzNjMgNjU1MzUgZg0KMDAwMDAwMDM2NCA2
NTUzNSBmDQowMDAwMDAwMzY1IDY1NTM1IGYNCjAwMDAwMDAzNjYgNjU1MzUgZg0KMDAwMDAwMDM2
NyA2NTUzNSBmDQowMDAwMDAwMzY4IDY1NTM1IGYNCjAwMDAwMDAzNjkgNjU1MzUgZg0KMDAwMDAw
MDM3MCA2NTUzNSBmDQowMDAwMDAwMzcxIDY1NTM1IGYNCjAwMDAwMDAzNzIgNjU1MzUgZg0KMDAw
MDAwMDM3MyA2NTUzNSBmDQowMDAwMDAwMzc0IDY1NTM1IGYNCjAwMDAwMDAzNzUgNjU1MzUgZg0K
MDAwMDAwMDM3NiA2NTUzNSBmDQowMDAwMDAwMzc3IDY1NTM1IGYNCjAwMDAwMDAzNzggNjU1MzUg
Zg0KMDAwMDAwMDM3OSA2NTUzNSBmDQowMDAwMDAwMzgwIDY1NTM1IGYNCjAwMDAwMDAzODEgNjU1
MzUgZg0KMDAwMDAwMDM4MiA2NTUzNSBmDQowMDAwMDAwMzgzIDY1NTM1IGYNCjAwMDAwMDAzODQg
NjU1MzUgZg0KMDAwMDAwMDM4NSA2NTUzNSBmDQowMDAwMDAwMzg2IDY1NTM1IGYNCjAwMDAwMDAz
ODcgNjU1MzUgZg0KMDAwMDAwMDM4OCA2NTUzNSBmDQowMDAwMDAwMzg5IDY1NTM1IGYNCjAwMDAw
MDAzOTAgNjU1MzUgZg0KMDAwMDAwMDM5MSA2NTUzNSBmDQowMDAwMDAwMzkyIDY1NTM1IGYNCjAw
MDAwMDAzOTMgNjU1MzUgZg0KMDAwMDAwMDM5NCA2NTUzNSBmDQowMDAwMDAwMzk1IDY1NTM1IGYN
CjAwMDAwMDAzOTYgNjU1MzUgZg0KMDAwMDAwMDM5NyA2NTUzNSBmDQowMDAwMDAwMzk4IDY1NTM1
IGYNCjAwMDAwMDAzOTkgNjU1MzUgZg0KMDAwMDAwMDQwMCA2NTUzNSBmDQowMDAwMDAwNDAxIDY1
NTM1IGYNCjAwMDAwMDA0MDIgNjU1MzUgZg0KMDAwMDAwMDQwMyA2NTUzNSBmDQowMDAwMDAwNDA0
IDY1NTM1IGYNCjAwMDAwMDA0MDUgNjU1MzUgZg0KMDAwMDAwMDQwNiA2NTUzNSBmDQowMDAwMDAw
NDA3IDY1NTM1IGYNCjAwMDAwMDA0MDggNjU1MzUgZg0KMDAwMDAwMDQwOSA2NTUzNSBmDQowMDAw
MDAwNDEwIDY1NTM1IGYNCjAwMDAwMDA0MTEgNjU1MzUgZg0KMDAwMDAwMDQxMiA2NTUzNSBmDQow
MDAwMDAwNDEzIDY1NTM1IGYNCjAwMDAwMDA0MTQgNjU1MzUgZg0KMDAwMDAwMDQxNSA2NTUzNSBm
DQowMDAwMDAwNDE2IDY1NTM1IGYNCjAwMDAwMDA0MTcgNjU1MzUgZg0KMDAwMDAwMDQxOCA2NTUz
NSBmDQowMDAwMDAwNDE5IDY1NTM1IGYNCjAwMDAwMDA0MjAgNjU1MzUgZg0KMDAwMDAwMDQyMSA2
NTUzNSBmDQowMDAwMDAwNDIyIDY1NTM1IGYNCjAwMDAwMDA0MjMgNjU1MzUgZg0KMDAwMDAwMDQy
NCA2NTUzNSBmDQowMDAwMDAwNDI1IDY1NTM1IGYNCjAwMDAwMDA0MjYgNjU1MzUgZg0KMDAwMDAw
MDQyNyA2NTUzNSBmDQowMDAwMDAwNDI4IDY1NTM1IGYNCjAwMDAwMDA0MjkgNjU1MzUgZg0KMDAw
MDAwMDQzMCA2NTUzNSBmDQowMDAwMDAwNDMxIDY1NTM1IGYNCjAwMDAwMDA0MzIgNjU1MzUgZg0K
MDAwMDAwMDQzMyA2NTUzNSBmDQowMDAwMDAwNDM0IDY1NTM1IGYNCjAwMDAwMDA0MzUgNjU1MzUg
Zg0KMDAwMDAwMDQzNiA2NTUzNSBmDQowMDAwMDAwNDM3IDY1NTM1IGYNCjAwMDAwMDA0MzggNjU1
MzUgZg0KMDAwMDAwMDQzOSA2NTUzNSBmDQowMDAwMDAwNDQwIDY1NTM1IGYNCjAwMDAwMDA0NDEg
NjU1MzUgZg0KMDAwMDAwMDQ0MiA2NTUzNSBmDQowMDAwMDAwNDQzIDY1NTM1IGYNCjAwMDAwMDA0
NDQgNjU1MzUgZg0KMDAwMDAwMDQ0NSA2NTUzNSBmDQowMDAwMDAwNDQ2IDY1NTM1IGYNCjAwMDAw
MDA0NDcgNjU1MzUgZg0KMDAwMDAwMDQ0OCA2NTUzNSBmDQowMDAwMDAwNDQ5IDY1NTM1IGYNCjAw
MDAwMDA0NTAgNjU1MzUgZg0KMDAwMDAwMDQ1MSA2NTUzNSBmDQowMDAwMDAwNDUyIDY1NTM1IGYN
CjAwMDAwMDA0NTMgNjU1MzUgZg0KMDAwMDAwMDQ1NCA2NTUzNSBmDQowMDAwMDAwNDU1IDY1NTM1
IGYNCjAwMDAwMDA0NTYgNjU1MzUgZg0KMDAwMDAwMDQ1NyA2NTUzNSBmDQowMDAwMDAwNDU4IDY1
NTM1IGYNCjAwMDAwMDA0NTkgNjU1MzUgZg0KMDAwMDAwMDQ2MCA2NTUzNSBmDQowMDAwMDAwNDYx
IDY1NTM1IGYNCjAwMDAwMDA0NjIgNjU1MzUgZg0KMDAwMDAwMDQ2MyA2NTUzNSBmDQowMDAwMDAw
NDY0IDY1NTM1IGYNCjAwMDAwMDA0NjUgNjU1MzUgZg0KMDAwMDAwMDQ2NiA2NTUzNSBmDQowMDAw
MDAwNDY3IDY1NTM1IGYNCjAwMDAwMDA0NjggNjU1MzUgZg0KMDAwMDAwMDQ2OSA2NTUzNSBmDQow
MDAwMDAwNDcwIDY1NTM1IGYNCjAwMDAwMDA0NzEgNjU1MzUgZg0KMDAwMDAwMDQ3MiA2NTUzNSBm
DQowMDAwMDAwNDczIDY1NTM1IGYNCjAwMDAwMDA0NzQgNjU1MzUgZg0KMDAwMDAwMDQ3NSA2NTUz
NSBmDQowMDAwMDAwNDc2IDY1NTM1IGYNCjAwMDAwMDA0NzcgNjU1MzUgZg0KMDAwMDAwMDQ3OCA2
NTUzNSBmDQowMDAwMDAwNDc5IDY1NTM1IGYNCjAwMDAwMDA0ODAgNjU1MzUgZg0KMDAwMDAwMDQ4
MSA2NTUzNSBmDQowMDAwMDAwNDgyIDY1NTM1IGYNCjAwMDAwMDA0ODMgNjU1MzUgZg0KMDAwMDAw
MDQ4NCA2NTUzNSBmDQowMDAwMDAwNDg1IDY1NTM1IGYNCjAwMDAwMDA0ODYgNjU1MzUgZg0KMDAw
MDAwMDQ4NyA2NTUzNSBmDQowMDAwMDAwNDg4IDY1NTM1IGYNCjAwMDAwMDA0ODkgNjU1MzUgZg0K
MDAwMDAwMDQ5MCA2NTUzNSBmDQowMDAwMDAwNDkxIDY1NTM1IGYNCjAwMDAwMDA0OTIgNjU1MzUg
Zg0KMDAwMDAwMDQ5MyA2NTUzNSBmDQowMDAwMDAwNDk0IDY1NTM1IGYNCjAwMDAwMDA0OTUgNjU1
MzUgZg0KMDAwMDAwMDQ5NiA2NTUzNSBmDQowMDAwMDAwNDk3IDY1NTM1IGYNCjAwMDAwMDA0OTgg
NjU1MzUgZg0KMDAwMDAwMDQ5OSA2NTUzNSBmDQowMDAwMDAwNTAwIDY1NTM1IGYNCjAwMDAwMDA1
MDEgNjU1MzUgZg0KMDAwMDAwMDUwMiA2NTUzNSBmDQowMDAwMDAwNTAzIDY1NTM1IGYNCjAwMDAw
MDA1MDQgNjU1MzUgZg0KMDAwMDAwMDUwNSA2NTUzNSBmDQowMDAwMDAwNTA2IDY1NTM1IGYNCjAw
MDAwMDA1MDcgNjU1MzUgZg0KMDAwMDAwMDUwOCA2NTUzNSBmDQowMDAwMDAwNTA5IDY1NTM1IGYN
CjAwMDAwMDA1MTAgNjU1MzUgZg0KMDAwMDAwMDUxMSA2NTUzNSBmDQowMDAwMDAwNTEyIDY1NTM1
IGYNCjAwMDAwMDA1MTMgNjU1MzUgZg0KMDAwMDAwMDUxNCA2NTUzNSBmDQowMDAwMDAwNTE1IDY1
NTM1IGYNCjAwMDAwMDA1MTYgNjU1MzUgZg0KMDAwMDAwMDUxNyA2NTUzNSBmDQowMDAwMDAwNTE4
IDY1NTM1IGYNCjAwMDAwMDA1MTkgNjU1MzUgZg0KMDAwMDAwMDUyMCA2NTUzNSBmDQowMDAwMDAw
NTIxIDY1NTM1IGYNCjAwMDAwMDA1MjIgNjU1MzUgZg0KMDAwMDAwMDUyMyA2NTUzNSBmDQowMDAw
MDAwNTI0IDY1NTM1IGYNCjAwMDAwMDA1MjUgNjU1MzUgZg0KMDAwMDAwMDUyNiA2NTUzNSBmDQow
MDAwMDAwNTI3IDY1NTM1IGYNCjAwMDAwMDA1MjggNjU1MzUgZg0KMDAwMDAwMDUyOSA2NTUzNSBm
DQowMDAwMDAwNTMwIDY1NTM1IGYNCjAwMDAwMDA1MzEgNjU1MzUgZg0KMDAwMDAwMDUzMiA2NTUz
NSBmDQowMDAwMDAwNTMzIDY1NTM1IGYNCjAwMDAwMDA1MzQgNjU1MzUgZg0KMDAwMDAwMDUzNSA2
NTUzNSBmDQowMDAwMDAwNTM2IDY1NTM1IGYNCjAwMDAwMDA1MzcgNjU1MzUgZg0KMDAwMDAwMDUz
OCA2NTUzNSBmDQowMDAwMDAwNTM5IDY1NTM1IGYNCjAwMDAwMDA1NDAgNjU1MzUgZg0KMDAwMDAw
MDU0MSA2NTUzNSBmDQowMDAwMDAwNTQyIDY1NTM1IGYNCjAwMDAwMDA1NDMgNjU1MzUgZg0KMDAw
MDAwMDU0NCA2NTUzNSBmDQowMDAwMDAwNTQ1IDY1NTM1IGYNCjAwMDAwMDA1NDYgNjU1MzUgZg0K
MDAwMDAwMDU0NyA2NTUzNSBmDQowMDAwMDAwNTQ4IDY1NTM1IGYNCjAwMDAwMDA1NDkgNjU1MzUg
Zg0KMDAwMDAwMDU1MCA2NTUzNSBmDQowMDAwMDAwNTUxIDY1NTM1IGYNCjAwMDAwMDA1NTIgNjU1
MzUgZg0KMDAwMDAwMDU1MyA2NTUzNSBmDQowMDAwMDAwNTU0IDY1NTM1IGYNCjAwMDAwMDA1NTUg
NjU1MzUgZg0KMDAwMDAwMDU1NiA2NTUzNSBmDQowMDAwMDAwNTU3IDY1NTM1IGYNCjAwMDAwMDA1
NTggNjU1MzUgZg0KMDAwMDAwMDU1OSA2NTUzNSBmDQowMDAwMDAwNTYwIDY1NTM1IGYNCjAwMDAw
MDA1NjEgNjU1MzUgZg0KMDAwMDAwMDU2MiA2NTUzNSBmDQowMDAwMDAwNTYzIDY1NTM1IGYNCjAw
MDAwMDA1NjQgNjU1MzUgZg0KMDAwMDAwMDU2NSA2NTUzNSBmDQowMDAwMDAwNTY2IDY1NTM1IGYN
CjAwMDAwMDA1NjcgNjU1MzUgZg0KMDAwMDAwMDU2OCA2NTUzNSBmDQowMDAwMDAwNTY5IDY1NTM1
IGYNCjAwMDAwMDA1NzAgNjU1MzUgZg0KMDAwMDAwMDU3MSA2NTUzNSBmDQowMDAwMDAwNTcyIDY1
NTM1IGYNCjAwMDAwMDA1NzMgNjU1MzUgZg0KMDAwMDAwMDU3NCA2NTUzNSBmDQowMDAwMDAwNTc1
IDY1NTM1IGYNCjAwMDAwMDA1NzYgNjU1MzUgZg0KMDAwMDAwMDU3NyA2NTUzNSBmDQowMDAwMDAw
NTc4IDY1NTM1IGYNCjAwMDAwMDA1NzkgNjU1MzUgZg0KMDAwMDAwMDU4MCA2NTUzNSBmDQowMDAw
MDAwNTgxIDY1NTM1IGYNCjAwMDAwMDA1ODIgNjU1MzUgZg0KMDAwMDAwMDU4MyA2NTUzNSBmDQow
MDAwMDAwNTg0IDY1NTM1IGYNCjAwMDAwMDA1ODUgNjU1MzUgZg0KMDAwMDAwMDU4NiA2NTUzNSBm
DQowMDAwMDAwNTg3IDY1NTM1IGYNCjAwMDAwMDA1ODggNjU1MzUgZg0KMDAwMDAwMDU4OSA2NTUz
NSBmDQowMDAwMDAwNTkwIDY1NTM1IGYNCjAwMDAwMDA1OTEgNjU1MzUgZg0KMDAwMDAwMDU5MiA2
NTUzNSBmDQowMDAwMDAwNTkzIDY1NTM1IGYNCjAwMDAwMDA1OTQgNjU1MzUgZg0KMDAwMDAwMDU5
NSA2NTUzNSBmDQowMDAwMDAwNTk2IDY1NTM1IGYNCjAwMDAwMDA1OTcgNjU1MzUgZg0KMDAwMDAw
MDU5OCA2NTUzNSBmDQowMDAwMDAwNTk5IDY1NTM1IGYNCjAwMDAwMDA2MDAgNjU1MzUgZg0KMDAw
MDAwMDYwMSA2NTUzNSBmDQowMDAwMDAwNjAyIDY1NTM1IGYNCjAwMDAwMDA2MDMgNjU1MzUgZg0K
MDAwMDAwMDYwNCA2NTUzNSBmDQowMDAwMDAwNjA1IDY1NTM1IGYNCjAwMDAwMDA2MDYgNjU1MzUg
Zg0KMDAwMDAwMDYwNyA2NTUzNSBmDQowMDAwMDAwNjA4IDY1NTM1IGYNCjAwMDAwMDA2MDkgNjU1
MzUgZg0KMDAwMDAwMDYxMCA2NTUzNSBmDQowMDAwMDAwNjExIDY1NTM1IGYNCjAwMDAwMDA2MTIg
NjU1MzUgZg0KMDAwMDAwMDYxMyA2NTUzNSBmDQowMDAwMDAwNjE0IDY1NTM1IGYNCjAwMDAwMDA2
MTUgNjU1MzUgZg0KMDAwMDAwMDYxNiA2NTUzNSBmDQowMDAwMDAwNjE3IDY1NTM1IGYNCjAwMDAw
MDA2MTggNjU1MzUgZg0KMDAwMDAwMDYxOSA2NTUzNSBmDQowMDAwMDAwNjIwIDY1NTM1IGYNCjAw
MDAwMDA2MjEgNjU1MzUgZg0KMDAwMDAwMDYyMiA2NTUzNSBmDQowMDAwMDAwNjIzIDY1NTM1IGYN
CjAwMDAwMDA2MjQgNjU1MzUgZg0KMDAwMDAwMDYyNSA2NTUzNSBmDQowMDAwMDAwNjI2IDY1NTM1
IGYNCjAwMDAwMDA2MjcgNjU1MzUgZg0KMDAwMDAwMDYyOCA2NTUzNSBmDQowMDAwMDAwNjI5IDY1
NTM1IGYNCjAwMDAwMDA2MzAgNjU1MzUgZg0KMDAwMDAwMDYzMSA2NTUzNSBmDQowMDAwMDAwNjMy
IDY1NTM1IGYNCjAwMDAwMDA2MzMgNjU1MzUgZg0KMDAwMDAwMDYzNCA2NTUzNSBmDQowMDAwMDAw
NjM1IDY1NTM1IGYNCjAwMDAwMDA2MzYgNjU1MzUgZg0KMDAwMDAwMDYzNyA2NTUzNSBmDQowMDAw
MDAwNjM4IDY1NTM1IGYNCjAwMDAwMDA2MzkgNjU1MzUgZg0KMDAwMDAwMDY0MCA2NTUzNSBmDQow
MDAwMDAwNjQxIDY1NTM1IGYNCjAwMDAwMDA2NDIgNjU1MzUgZg0KMDAwMDAwMDY0MyA2NTUzNSBm
DQowMDAwMDAwNjQ0IDY1NTM1IGYNCjAwMDAwMDA2NDUgNjU1MzUgZg0KMDAwMDAwMDY0NiA2NTUz
NSBmDQowMDAwMDAwNjQ3IDY1NTM1IGYNCjAwMDAwMDA2NDggNjU1MzUgZg0KMDAwMDAwMDY0OSA2
NTUzNSBmDQowMDAwMDAwNjUwIDY1NTM1IGYNCjAwMDAwMDA2NTEgNjU1MzUgZg0KMDAwMDAwMDY1
MiA2NTUzNSBmDQowMDAwMDAwNjUzIDY1NTM1IGYNCjAwMDAwMDA2NTQgNjU1MzUgZg0KMDAwMDAw
MDY1NSA2NTUzNSBmDQowMDAwMDAwNjU2IDY1NTM1IGYNCjAwMDAwMDA2NTcgNjU1MzUgZg0KMDAw
MDAwMDY1OCA2NTUzNSBmDQowMDAwMDAwNjU5IDY1NTM1IGYNCjAwMDAwMDA2NjAgNjU1MzUgZg0K
MDAwMDAwMDY2MSA2NTUzNSBmDQowMDAwMDAwNjYyIDY1NTM1IGYNCjAwMDAwMDA2NjMgNjU1MzUg
Zg0KMDAwMDAwMDY2NCA2NTUzNSBmDQowMDAwMDAwNjY1IDY1NTM1IGYNCjAwMDAwMDA2NjYgNjU1
MzUgZg0KMDAwMDAwMDY2NyA2NTUzNSBmDQowMDAwMDAwNjY4IDY1NTM1IGYNCjAwMDAwMDA2Njkg
NjU1MzUgZg0KMDAwMDAwMDY3MCA2NTUzNSBmDQowMDAwMDAwNjcxIDY1NTM1IGYNCjAwMDAwMDA2
NzIgNjU1MzUgZg0KMDAwMDAwMDY3MyA2NTUzNSBmDQowMDAwMDAwNjc0IDY1NTM1IGYNCjAwMDAw
MDA2NzUgNjU1MzUgZg0KMDAwMDAwMDY3NiA2NTUzNSBmDQowMDAwMDAwNjc3IDY1NTM1IGYNCjAw
MDAwMDA2NzggNjU1MzUgZg0KMDAwMDAwMDY3OSA2NTUzNSBmDQowMDAwMDAwNjgwIDY1NTM1IGYN
CjAwMDAwMDA2ODEgNjU1MzUgZg0KMDAwMDAwMDY4MiA2NTUzNSBmDQowMDAwMDAwNjgzIDY1NTM1
IGYNCjAwMDAwMDA2ODQgNjU1MzUgZg0KMDAwMDAwMDY4NSA2NTUzNSBmDQowMDAwMDAwNjg2IDY1
NTM1IGYNCjAwMDAwMDA2ODcgNjU1MzUgZg0KMDAwMDAwMDY4OCA2NTUzNSBmDQowMDAwMDAwNjg5
IDY1NTM1IGYNCjAwMDAwMDA2OTAgNjU1MzUgZg0KMDAwMDAwMDY5MSA2NTUzNSBmDQowMDAwMDAw
NjkyIDY1NTM1IGYNCjAwMDAwMDA2OTMgNjU1MzUgZg0KMDAwMDAwMDY5NCA2NTUzNSBmDQowMDAw
MDAwNjk1IDY1NTM1IGYNCjAwMDAwMDA2OTYgNjU1MzUgZg0KMDAwMDAwMDY5NyA2NTUzNSBmDQow
MDAwMDAwNjk4IDY1NTM1IGYNCjAwMDAwMDA2OTkgNjU1MzUgZg0KMDAwMDAwMDcwMCA2NTUzNSBm
DQowMDAwMDAwNzAxIDY1NTM1IGYNCjAwMDAwMDA3MDIgNjU1MzUgZg0KMDAwMDAwMDcwMyA2NTUz
NSBmDQowMDAwMDAwNzA0IDY1NTM1IGYNCjAwMDAwMDA3MDUgNjU1MzUgZg0KMDAwMDAwMDcwNiA2
NTUzNSBmDQowMDAwMDAwNzA3IDY1NTM1IGYNCjAwMDAwMDA3MDggNjU1MzUgZg0KMDAwMDAwMDcw
OSA2NTUzNSBmDQowMDAwMDAwNzEwIDY1NTM1IGYNCjAwMDAwMDA3MTEgNjU1MzUgZg0KMDAwMDAw
MDcxMiA2NTUzNSBmDQowMDAwMDAwNzEzIDY1NTM1IGYNCjAwMDAwMDA3MTQgNjU1MzUgZg0KMDAw
MDAwMDcxNSA2NTUzNSBmDQowMDAwMDAwNzE2IDY1NTM1IGYNCjAwMDAwMDA3MTcgNjU1MzUgZg0K
MDAwMDAwMDcxOCA2NTUzNSBmDQowMDAwMDAwNzE5IDY1NTM1IGYNCjAwMDAwMDA3MjAgNjU1MzUg
Zg0KMDAwMDAwMDcyMSA2NTUzNSBmDQowMDAwMDAwNzIyIDY1NTM1IGYNCjAwMDAwMDA3MjMgNjU1
MzUgZg0KMDAwMDAwMDcyNCA2NTUzNSBmDQowMDAwMDAwNzI1IDY1NTM1IGYNCjAwMDAwMDA3MjYg
NjU1MzUgZg0KMDAwMDAwMDcyNyA2NTUzNSBmDQowMDAwMDAwNzI4IDY1NTM1IGYNCjAwMDAwMDA3
MjkgNjU1MzUgZg0KMDAwMDAwMDczMCA2NTUzNSBmDQowMDAwMDAwNzMxIDY1NTM1IGYNCjAwMDAw
MDA3MzIgNjU1MzUgZg0KMDAwMDAwMDczMyA2NTUzNSBmDQowMDAwMDAwNzM0IDY1NTM1IGYNCjAw
MDAwMDA3MzUgNjU1MzUgZg0KMDAwMDAwMDczNiA2NTUzNSBmDQowMDAwMDAwNzM3IDY1NTM1IGYN
CjAwMDAwMDA3MzggNjU1MzUgZg0KMDAwMDAwMDczOSA2NTUzNSBmDQowMDAwMDAwNzQwIDY1NTM1
IGYNCjAwMDAwMDA3NDEgNjU1MzUgZg0KMDAwMDAwMDc0MiA2NTUzNSBmDQowMDAwMDAwNzQzIDY1
NTM1IGYNCjAwMDAwMDA3NDQgNjU1MzUgZg0KMDAwMDAwMDc0NSA2NTUzNSBmDQowMDAwMDAwNzQ2
IDY1NTM1IGYNCjAwMDAwMDA3NDcgNjU1MzUgZg0KMDAwMDAwMDc0OCA2NTUzNSBmDQowMDAwMDAw
NzQ5IDY1NTM1IGYNCjAwMDAwMDA3NTAgNjU1MzUgZg0KMDAwMDAwMDc1MSA2NTUzNSBmDQowMDAw
MDAwNzUyIDY1NTM1IGYNCjAwMDAwMDA3NTMgNjU1MzUgZg0KMDAwMDAwMDc1NCA2NTUzNSBmDQow
MDAwMDAwNzU1IDY1NTM1IGYNCjAwMDAwMDA3NTYgNjU1MzUgZg0KMDAwMDAwMDc1NyA2NTUzNSBm
DQowMDAwMDAwNzU4IDY1NTM1IGYNCjAwMDAwMDA3NTkgNjU1MzUgZg0KMDAwMDAwMDc2MCA2NTUz
NSBmDQowMDAwMDAwNzYxIDY1NTM1IGYNCjAwMDAwMDA3NjIgNjU1MzUgZg0KMDAwMDAwMDc2MyA2
NTUzNSBmDQowMDAwMDAwNzY0IDY1NTM1IGYNCjAwMDAwMDA3NjUgNjU1MzUgZg0KMDAwMDAwMDc2
NiA2NTUzNSBmDQowMDAwMDAwNzY3IDY1NTM1IGYNCjAwMDAwMDA3NjggNjU1MzUgZg0KMDAwMDAw
MDc2OSA2NTUzNSBmDQowMDAwMDAwNzcwIDY1NTM1IGYNCjAwMDAwMDA3NzEgNjU1MzUgZg0KMDAw
MDAwMDc3MiA2NTUzNSBmDQowMDAwMDAwNzczIDY1NTM1IGYNCjAwMDAwMDA3NzQgNjU1MzUgZg0K
MDAwMDAwMDc3NSA2NTUzNSBmDQowMDAwMDAwNzc2IDY1NTM1IGYNCjAwMDAwMDA3NzcgNjU1MzUg
Zg0KMDAwMDAwMDc3OCA2NTUzNSBmDQowMDAwMDAwNzc5IDY1NTM1IGYNCjAwMDAwMDA3ODAgNjU1
MzUgZg0KMDAwMDAwMDc4MSA2NTUzNSBmDQowMDAwMDAwNzgyIDY1NTM1IGYNCjAwMDAwMDA3ODMg
NjU1MzUgZg0KMDAwMDAwMDc4NCA2NTUzNSBmDQowMDAwMDAwNzg1IDY1NTM1IGYNCjAwMDAwMDA3
ODYgNjU1MzUgZg0KMDAwMDAwMDc4NyA2NTUzNSBmDQowMDAwMDAwNzg4IDY1NTM1IGYNCjAwMDAw
MDA3ODkgNjU1MzUgZg0KMDAwMDAwMDc5MCA2NTUzNSBmDQowMDAwMDAwNzkxIDY1NTM1IGYNCjAw
MDAwMDA3OTIgNjU1MzUgZg0KMDAwMDAwMDc5MyA2NTUzNSBmDQowMDAwMDAwNzk0IDY1NTM1IGYN
CjAwMDAwMDA3OTUgNjU1MzUgZg0KMDAwMDAwMDc5NiA2NTUzNSBmDQowMDAwMDAwNzk3IDY1NTM1
IGYNCjAwMDAwMDA3OTggNjU1MzUgZg0KMDAwMDAwMDc5OSA2NTUzNSBmDQowMDAwMDAwODAwIDY1
NTM1IGYNCjAwMDAwMDA4MDEgNjU1MzUgZg0KMDAwMDAwMDgwMiA2NTUzNSBmDQowMDAwMDAwODAz
IDY1NTM1IGYNCjAwMDAwMDA4MDQgNjU1MzUgZg0KMDAwMDAwMDgwNSA2NTUzNSBmDQowMDAwMDAw
ODA2IDY1NTM1IGYNCjAwMDAwMDA4MDcgNjU1MzUgZg0KMDAwMDAwMDgwOCA2NTUzNSBmDQowMDAw
MDAwODA5IDY1NTM1IGYNCjAwMDAwMDA4MTAgNjU1MzUgZg0KMDAwMDAwMDgxMSA2NTUzNSBmDQow
MDAwMDAwODEyIDY1NTM1IGYNCjAwMDAwMDA4MTMgNjU1MzUgZg0KMDAwMDAwMDgxNCA2NTUzNSBm
DQowMDAwMDAwODE1IDY1NTM1IGYNCjAwMDAwMDA4MTYgNjU1MzUgZg0KMDAwMDAwMDgxNyA2NTUz
NSBmDQowMDAwMDAwODE4IDY1NTM1IGYNCjAwMDAwMDA4MTkgNjU1MzUgZg0KMDAwMDAwMDgyMCA2
NTUzNSBmDQowMDAwMDAwODIxIDY1NTM1IGYNCjAwMDAwMDA4MjIgNjU1MzUgZg0KMDAwMDAwMDgy
MyA2NTUzNSBmDQowMDAwMDAwODI0IDY1NTM1IGYNCjAwMDAwMDA4MjUgNjU1MzUgZg0KMDAwMDAw
MDgyNiA2NTUzNSBmDQowMDAwMDAwODI3IDY1NTM1IGYNCjAwMDAwMDA4MjggNjU1MzUgZg0KMDAw
MDAwMDgyOSA2NTUzNSBmDQowMDAwMDAwODMwIDY1NTM1IGYNCjAwMDAwMDA4MzEgNjU1MzUgZg0K
MDAwMDAwMDgzMiA2NTUzNSBmDQowMDAwMDAwODMzIDY1NTM1IGYNCjAwMDAwMDA4MzQgNjU1MzUg
Zg0KMDAwMDAwMDgzNSA2NTUzNSBmDQowMDAwMDAwODM2IDY1NTM1IGYNCjAwMDAwMDA4MzcgNjU1
MzUgZg0KMDAwMDAwMDgzOCA2NTUzNSBmDQowMDAwMDAwODM5IDY1NTM1IGYNCjAwMDAwMDA4NDAg
NjU1MzUgZg0KMDAwMDAwMDg0MSA2NTUzNSBmDQowMDAwMDAwODQyIDY1NTM1IGYNCjAwMDAwMDA4
NDMgNjU1MzUgZg0KMDAwMDAwMDg0NCA2NTUzNSBmDQowMDAwMDAwODQ1IDY1NTM1IGYNCjAwMDAw
MDA4NDYgNjU1MzUgZg0KMDAwMDAwMDg0NyA2NTUzNSBmDQowMDAwMDAwODQ4IDY1NTM1IGYNCjAw
MDAwMDA4NDkgNjU1MzUgZg0KMDAwMDAwMDg1MCA2NTUzNSBmDQowMDAwMDAwODUxIDY1NTM1IGYN
CjAwMDAwMDA4NTIgNjU1MzUgZg0KMDAwMDAwMDg1MyA2NTUzNSBmDQowMDAwMDAwODU0IDY1NTM1
IGYNCjAwMDAwMDA4NTUgNjU1MzUgZg0KMDAwMDAwMDg1NiA2NTUzNSBmDQowMDAwMDAwODU3IDY1
NTM1IGYNCjAwMDAwMDA4NTggNjU1MzUgZg0KMDAwMDAwMDg1OSA2NTUzNSBmDQowMDAwMDAwODYw
IDY1NTM1IGYNCjAwMDAwMDA4NjEgNjU1MzUgZg0KMDAwMDAwMDg2MiA2NTUzNSBmDQowMDAwMDAw
ODYzIDY1NTM1IGYNCjAwMDAwMDA4NjQgNjU1MzUgZg0KMDAwMDAwMDg2NSA2NTUzNSBmDQowMDAw
MDAwODY2IDY1NTM1IGYNCjAwMDAwMDA4NjcgNjU1MzUgZg0KMDAwMDAwMDg2OCA2NTUzNSBmDQow
MDAwMDAwODY5IDY1NTM1IGYNCjAwMDAwMDA4NzAgNjU1MzUgZg0KMDAwMDAwMDg3MSA2NTUzNSBm
DQowMDAwMDAwODcyIDY1NTM1IGYNCjAwMDAwMDA4NzMgNjU1MzUgZg0KMDAwMDAwMDg3NCA2NTUz
NSBmDQowMDAwMDAwODc1IDY1NTM1IGYNCjAwMDAwMDA4NzYgNjU1MzUgZg0KMDAwMDAwMDg3NyA2
NTUzNSBmDQowMDAwMDAwODc4IDY1NTM1IGYNCjAwMDAwMDA4NzkgNjU1MzUgZg0KMDAwMDAwMDg4
MCA2NTUzNSBmDQowMDAwMDAwODgxIDY1NTM1IGYNCjAwMDAwMDA4ODIgNjU1MzUgZg0KMDAwMDAw
MDg4MyA2NTUzNSBmDQowMDAwMDAwODg0IDY1NTM1IGYNCjAwMDAwMDA4ODUgNjU1MzUgZg0KMDAw
MDAwMDg4NiA2NTUzNSBmDQowMDAwMDAwODg3IDY1NTM1IGYNCjAwMDAwMDA4ODggNjU1MzUgZg0K
MDAwMDAwMDg4OSA2NTUzNSBmDQowMDAwMDAwODkwIDY1NTM1IGYNCjAwMDAwMDA4OTEgNjU1MzUg
Zg0KMDAwMDAwMDg5MiA2NTUzNSBmDQowMDAwMDAwODkzIDY1NTM1IGYNCjAwMDAwMDA4OTQgNjU1
MzUgZg0KMDAwMDAwMDg5NSA2NTUzNSBmDQowMDAwMDAwODk2IDY1NTM1IGYNCjAwMDAwMDA4OTcg
NjU1MzUgZg0KMDAwMDAwMDg5OCA2NTUzNSBmDQowMDAwMDAwODk5IDY1NTM1IGYNCjAwMDAwMDA5
MDAgNjU1MzUgZg0KMDAwMDAwMDkwMSA2NTUzNSBmDQowMDAwMDAwOTAyIDY1NTM1IGYNCjAwMDAw
MDA5MDMgNjU1MzUgZg0KMDAwMDAwMDkwNCA2NTUzNSBmDQowMDAwMDAwOTA1IDY1NTM1IGYNCjAw
MDAwMDA5MDYgNjU1MzUgZg0KMDAwMDAwMDkwNyA2NTUzNSBmDQowMDAwMDAwOTA4IDY1NTM1IGYN
CjAwMDAwMDA5MDkgNjU1MzUgZg0KMDAwMDAwMDkxMCA2NTUzNSBmDQowMDAwMDAwOTExIDY1NTM1
IGYNCjAwMDAwMDA5MTIgNjU1MzUgZg0KMDAwMDAwMDkxMyA2NTUzNSBmDQowMDAwMDAwOTE0IDY1
NTM1IGYNCjAwMDAwMDA5MTUgNjU1MzUgZg0KMDAwMDAwMDkxNiA2NTUzNSBmDQowMDAwMDAwOTE3
IDY1NTM1IGYNCjAwMDAwMDA5MTggNjU1MzUgZg0KMDAwMDAwMDkxOSA2NTUzNSBmDQowMDAwMDAw
OTIwIDY1NTM1IGYNCjAwMDAwMDA5MjEgNjU1MzUgZg0KMDAwMDAwMDkyMiA2NTUzNSBmDQowMDAw
MDAwOTIzIDY1NTM1IGYNCjAwMDAwMDA5MjQgNjU1MzUgZg0KMDAwMDAwMDkyNSA2NTUzNSBmDQow
MDAwMDAwOTI2IDY1NTM1IGYNCjAwMDAwMDA5MjcgNjU1MzUgZg0KMDAwMDAwMDkyOCA2NTUzNSBm
DQowMDAwMDAwOTI5IDY1NTM1IGYNCjAwMDAwMDA5MzAgNjU1MzUgZg0KMDAwMDAwMDkzMSA2NTUz
NSBmDQowMDAwMDAwOTMyIDY1NTM1IGYNCjAwMDAwMDA5MzMgNjU1MzUgZg0KMDAwMDAwMDAwMCA2
NTUzNSBmDQowMDAwMTYwMjI5IDAwMDAwIG4NCjAwMDAxNjA1NTkgMDAwMDAgbg0KMDAwMDE4MTEy
NiAwMDAwMCBuDQowMDAwMTgxNTQ1IDAwMDAwIG4NCjAwMDAyMDg1NjMgMDAwMDAgbg0KMDAwMDIw
ODk5NCAwMDAwMCBuDQowMDAwMjA5MzU1IDAwMDAwIG4NCjAwMDAyMDk1NTcgMDAwMDAgbg0KMDAw
MDIyMTY0OCAwMDAwMCBuDQowMDAwMjIxOTQ5IDAwMDAwIG4NCjAwMDAyMzUxOTQgMDAwMDAgbg0K
MDAwMDIzNTIzOCAwMDAwMCBuDQp0cmFpbGVyDQo8PC9TaXplIDk0Ni9Sb290IDEgMCBSL0luZm8g
NzcgMCBSL0lEWzw4QzEyMzk5Rjc5RkJFQjQ2Qjc1ODVBREYzRDk0NTY1Mz48OEMxMjM5OUY3OUZC
RUI0NkI3NTg1QURGM0Q5NDU2NTM+XSA+Pg0Kc3RhcnR4cmVmDQoyMzczNTkNCiUlRU9GDQp4cmVm
DQowIDANCnRyYWlsZXINCjw8L1NpemUgOTQ2L1Jvb3QgMSAwIFIvSW5mbyA3NyAwIFIvSURbPDhD
MTIzOTlGNzlGQkVCNDZCNzU4NUFERjNEOTQ1NjUzPjw4QzEyMzk5Rjc5RkJFQjQ2Qjc1ODVBREYz
RDk0NTY1Mz5dIC9QcmV2IDIzNzM1OS9YUmVmU3RtIDIzNTIzOD4+DQpzdGFydHhyZWYNCjI1NjQz
OQ0KJSVFT0Y=

--_002_DE8DF0795D48FD4CA783C40EC82923353610F0SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC82923353610F0SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Fri Oct 19 20:13:57 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 20:13:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPIwv-000783-OG; Fri, 19 Oct 2012 20:13:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPIwt-00077y-3b
	for xen-devel@lists.xensource.com; Fri, 19 Oct 2012 20:13:40 +0000
Received: from [85.158.138.51:26800] by server-1.bemta-3.messagelabs.com id
	E9/F5-31728-274B1805; Fri, 19 Oct 2012 20:13:38 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1350677611!33283098!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMzMTM2Mg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1495 invoked from network); 19 Oct 2012 20:13:32 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-15.tower-174.messagelabs.com with SMTP;
	19 Oct 2012 20:13:32 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 19 Oct 2012 13:13:30 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,615,1344236400"; 
	d="pdf'?scan'208";a="236127249"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by fmsmga001.fm.intel.com with ESMTP; 19 Oct 2012 13:13:30 -0700
Received: from fmsmsx152.amr.corp.intel.com (10.19.17.221) by
	FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 19 Oct 2012 13:13:29 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	fmsmsx152.amr.corp.intel.com (10.19.17.221) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 19 Oct 2012 13:13:28 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.123]) with mapi id
	14.01.0355.002; Sat, 20 Oct 2012 04:13:26 +0800
From: "Liu, Jinsong" 
To: Ian Jackson 
Thread-Topic: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration when
	vMCE	occur
Thread-Index: AQHNrglhllpCBVDw6Ui6h+f8GVa/apfA6fPQ
Date: Fri, 19 Oct 2012 20:13:25 +0000
Message-ID: 
References: 
	<20609.26910.2416.305293@mariner.uk.xensource.com>
In-Reply-To: <20609.26910.2416.305293@mariner.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC82923353610F0SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration when
	vMCE	occur
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC82923353610F0SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Ian Jackson wrote:
> Liu, Jinsong writes ("[Xen-devel] [PATCH 4/5] Xen/MCE: Abort live
> migration when vMCE occur"):=20
>> This patch monitor the critical area of live migration (from vMCE
>> point of view, the copypages stage of migration is the critical area
>> while other areas are not).
>=20
> Sorry for the delay reviewing this.
>=20
> Just to be clear, can you explain what a vMCE is ?  I think I know but
> I'm not entirely sure and it would be helpful if you'd confirm, as I
> seem to have missed the background here.  I couldn't easily find the
> 0/5 posting of your series (in part because the tool you're using to
> send your series doesn't link the messages together in the same
> thread).
>=20

vMCE is a virtual MCE interface to guest. Its general purpose is to emulate=
 a well defined interface to guest, so that when MCE occur in the range of =
guest, hypervisor can filter/expose necessary MCE error information to gues=
t which would continue handle it.

These vMCE series patches is used to replace old xen vMCE implement, since =
old vMCE has some issues, including
1). old vMCE bound to host MCE, which would bring troubles like non-arch is=
sue, save/restore issue, etc;
2). weird per-domain msr semantic
3). questionable vMCE injection method

I don't know if I have introduced it clear, but we have the Xen vMCE design=
 doc as attached, including many vMCE details.

>> If a vMCE occur at the critical area of live migration, there is
>> risk that error data may be copied to the target. Currently we don't
>> have convenient way to handle this case, so for the sake of safe, we
>> abort it and try migration later (at that time broken page would not
>> be mapped and copied to the target).
>=20
> The "error data" that you refer to is erroneous page contents, or
> something else ?

Yes, it's erroneous page contents.

>=20
> When you say "we abort it and try migration later", that's not
> actually implemented in your patch, is it ?  What actually happens is
> that the migration is aborted and the user is expected to retry later.

Yes, and to make it more accurate how about update as "... we abort it. Use=
r can try migration later (at that time the broken page would not be mapped=
 and copied to the target)"?

>=20
> I think this situation deserves a specific error code at the very
> least.  That specific error code should be plumbed up to libxl.
>=20
> Wouldn't it be better to actually restart the migration somehow ?

Seems libxl save/restore changed greatly recently, and I know almost nothin=
g about the new save helper mechanism (I spend some time to study it but st=
ill not quite clear).
Maybe to achieve 'restart migration' is some overkilled/complicated for vMC=
E itself? after all mce during migration rarely occur in real life, and the=
 main target of this patch is only for the sake of safe, so 'abort migratio=
n' is an acceptable option?

>=20
> I have some more minor comments about the implementation:
>=20
>> @@ -1109,6 +1111,12 @@
>>          goto out;
>>      }
>>=20
>> +    if ( xc_domain_vmce_monitor_start(xch, dom) )
>> +    {
>> +        PERROR("Error when start vmce monitor\n");
>=20
> "Error starting vmc monitor" would be better English.  Messages sent
> with PERROR should not have a \n.
>=20
>> +    vmce_while_monitor =3D xc_domain_vmce_monitor_end(xch, dom);
>> +    if ( vmce_while_monitor < 0 )
>> +    {
>> +        PERROR("Error when end vmce monitor\n");
>=20
> Grammar and \n again.
>=20
>> +    else if ( vmce_while_monitor > 0 )
>> +    {
>> +        fprintf(stderr, "vMCE occurred, abort this time and try
>> later.\n"); +        goto out;
>=20
> This message should be sent with one of the logging macros, not
> fprintf.  ERROR, probably.
>=20
> Ian.

Will update accordingly.

Thanks,
Jinsong


--_002_DE8DF0795D48FD4CA783C40EC82923353610F0SHSMSX101ccrcorpi_
Content-Type: application/pdf; name="xen vMCE design (v0 2).pdf"
Content-Description: xen vMCE design (v0 2).pdf
Content-Disposition: attachment; filename="xen vMCE design (v0 2).pdf";
	size=256622; creation-date="Wed, 27 Jun 2012 03:21:05 GMT";
	modification-date="Wed, 27 Jun 2012 03:18:50 GMT"
Content-Transfer-Encoding: base64

JVBERi0xLjUNCiW1tbW1DQoxIDAgb2JqDQo8PC9UeXBlL0NhdGFsb2cvUGFnZXMgMiAwIFIvTGFu
Zyhlbi1VUykgL1N0cnVjdFRyZWVSb290IDc4IDAgUi9NYXJrSW5mbzw8L01hcmtlZCB0cnVlPj4+
Pg0KZW5kb2JqDQoyIDAgb2JqDQo8PC9UeXBlL1BhZ2VzL0NvdW50IDE0L0tpZHNbIDMgMCBSIDE0
IDAgUiA0MSAwIFIgNTQgMCBSIDU2IDAgUiA1OCAwIFIgNjAgMCBSIDYyIDAgUiA2NSAwIFIgNjcg
MCBSIDY5IDAgUiA3MSAwIFIgNzMgMCBSIDc1IDAgUl0gPj4NCmVuZG9iag0KMyAwIG9iag0KPDwv
VHlwZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8PC9YT2JqZWN0PDwvSW1hZ2U1IDUgMCBS
L0ltYWdlNiA2IDAgUi9JbWFnZTcgNyAwIFIvSW1hZ2U4IDggMCBSPj4vRm9udDw8L0YxIDkgMCBS
L0YyIDEyIDAgUj4+L0V4dEdTdGF0ZTw8L0dTMTEgMTEgMCBSPj4vUHJvY1NldFsvUERGL1RleHQv
SW1hZ2VCL0ltYWdlQy9JbWFnZUldID4+L01lZGlhQm94WyAwIDAgNzIwIDU0MF0gL0NvbnRlbnRz
IDQgMCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9U
YWJzL1MvU3RydWN0UGFyZW50cyAwPj4NCmVuZG9iag0KNCAwIG9iag0KPDwvRmlsdGVyL0ZsYXRl
RGVjb2RlL0xlbmd0aCA2NDA+Pg0Kc3RyZWFtDQp4nKWU32/aMBDH3yPlf7hHpyqOzz9jCVVdoauK
WqnbkLqp2gNqKU0FQStj0/77nU0oBAJ72EOc5GLf9/s5nwP5HXS7+W3vug/i7Awu+j34kSYCBBdC
oJTCgZMCjBbwNk6T+xOo6DMXCjXNUc7SaI2Ht8n7KiEsCt1Y9nySJp/SBC5vewBbkrgn2bJ4penQ
c2eApoFR60cuDS2Ax1ma5Nez0WRsoD+HNiW5UerUQgK9qzkLhdiiacRaUnuO0oBCXlDEx0VbsvaQ
rNqXNQb9cVntiGtFasBGYR1ItxXdIUW9r2gLbVeKUmtsKy4K9V5cERGt8MGEi+ob2eKQrMlvRtUE
2OuoM7jLag8XQ1r3EaHgtKXDZ9KJEkgiiheK4tpJGM5CR1lfAPVQfvWFajJZrENXafLAZNbRTIQB
wxBfc5vT3TCXfYfhIE0uhy2u7JaRd21juJRb2g8MjuVwh8jWCbVDTsek4MqsE+KxhEVrDrsqyCbH
UVO+UWEJSu6WWKLhgj4o6mFf17j91O6HP8eqfx1XkGn267Z3Cf3xopxkilVbphr+PflvqP0DAMUO
Adn1xQ4C9aA3gB65UnXSmzIzbHmaWUrfQcMG9FqSy2pBD3PaJ4pq1n0tKwou5mGccBqmdJVZR7Hl
+fqp+klZxlMeuulxHnppdnYAz5AT3TRynA5b6GwDDh39xOhmNdemzjmI1hSjfjslECnYt2X1sqH6
EwGqF5pGQf5ajiLfeRkQCEezccCYhmmc8jyGOJF5NqO3g3D0OzW66eQ4nWzpYCld5FGOG1dn+bCc
0q48RRZk9zRGvGl9Ubhg3d+74eB8tAwb9vSfZJo2jM5Tw9Me2V+R5XLyDQplbmRzdHJlYW0NCmVu
ZG9iag0KNSAwIG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvV2lkdGggMTAyNC9I
ZWlnaHQgNzY4L0NvbG9yU3BhY2UvRGV2aWNlUkdCL0JpdHNQZXJDb21wb25lbnQgOC9GaWx0ZXIv
RENURGVjb2RlL0ludGVycG9sYXRlIHRydWUvTGVuZ3RoIDE4NzExPj4NCnN0cmVhbQ0K/9j/4AAQ
SkZJRgABAQEAAAAAAAD/7AARRHVja3kAAQAEAAAAZAAA/9sAQwAIBgYHBgUIBwcHCQkICgwUDQwL
CwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04MjwuMzQy/9sAQwEJCQkMCwwY
DQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy
/8AAEQgDAAQAAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQ
AAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYX
GBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqS
k5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz
9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQE
AAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1
Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKj
pKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwD
AQACEQMRAD8A9/ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigDxD/hcfiH/nz0v/
AL9Sf/F0f8Lj8Q/8+el/9+pP/i688or6X6pQ/lR839br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPx
D/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi
688oo+qUP5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/z
M9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcfiH/n
z0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH/C4/
EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/36k/+
Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH
1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/AOFx+If+
fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/AL9Sf/F0
f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH/C4/EP8Az56X/wB+
pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6pQ/lQ
fW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9D/4X
H4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/AOFx+If+fPS/+/Un/wAX
R/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8+el/
9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH/C4/EP8Az56X/wB+pP8A4uvPKKPq
lD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDh
cfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L/wC/
Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/AM+e
l/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i688oo+
qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH/C4/EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br/wAz
PQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1
J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP
/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLr
zyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz
0P8A4XH4h/589L/79Sf/ABdH/C4/EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fP
S/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q
/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4u
vPKKPqlD+VB9br/zM9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW
6/8AMz0P/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/58
9L/79Sf/ABdH/C4/EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/
wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k
/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9
br/zM9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcf
iH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH
/C4/EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/3
6k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qU
P5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/AOFx
+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/AL9S
f/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH/C4/EP8Az56X
/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6p
Q/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9
D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/AOFx+If+fPS/+/Un
/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8
+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH/C4/EP8Az56X/wB+pP8A4uvP
KKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ
/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L
/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/
AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i68
8oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH/C4/EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br
/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0
v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C
4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zMKKKK6DnCiiigAoPAopD0oA27uLR7BoYZbK6mkaGORnF
wFBLDPAxUH2nQ/8AoGXf/gV/9jRr3/H7B/16Q/8AoAqna2FzeJNJDC7QwKHmkVciNc4yfasopct2
/wATVt81kvwLn2nQ/wDoGXf/AIFf/Y0n2rQ/+gZd59rr/wCxqVL3RtPH+j6edQmH/La8Yqn4Iv8A
U1ZbxbrdsQkS21iCAVSKyROPxGTSs3svvZSaW7+5XKP2rQx10y7H/b0P/iaVU0e8bZG1xYyn7rTM
JIyfcgZH1rWsPE/iTUpZIhDbakI4zJJFNaxt8g6k8A0/UNIsNX0O41bTbQ2F3aKr3diG3IY26SJ3
A9qnm5XaWnzuVy8yvHX5WOYuraazuZLedNkqHBGc/iD3FRVpXjfaNC0+4c5ljZ7fd3KjBX8skVm1
vF3WpzyST0CiiimIKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo
oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii
igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK
ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKOldZa6BoekwR3XiXUt0joHTT7I75CD
yNzdF+lROahuXCDnscrFFJPKIoY3kkPREUsT+ArqNN+HPibUlDiw+zRn+O5YJx9OtW2+IR02MweG
tGtNMi6eYy+ZKfqa56/8Sa3qjE3mqXUoPVfMIX8hxWTdaWyS9dX/AF8zRKjHdt+mh1y/DCG2XOqe
J9PtiOqqQSPzIpw8F+Co+JvGSs3+yV/+vXnRAJyeT6mjA9BR7Gq96j+5Fe2pLamvvZ6UvgLwjdfL
aeMY9/YOyf4iorr4Raj5Rl0zVLO9TsM7SfxGRXnW0HsKt2OqX2mTCSxvZ7Zwesbkfp0NS6VZfDP7
0Cq0X8UPuZPq2g6poc3l6lZS25PRmGVb6MODWdXqnhr4kQ6qF0bxVDDLFN8guCo2k9t47fUVheP/
AAQPDU631hubTJ2wATkxN6Z7g9jRTxEuf2dVWfTsx1KEeT2lJ3XXujiKKKK6jlCiiigAooooAKKK
KACiiigApD0paQ9KBG/dWDap4j02wQ4a4ht48+mVGT/OtqzW1v4PFXlxlLextBHaqrFcKHxk4PzE
9Tn1rIl1D+yfFGlaht3C3it5CvqAoz+ma1dY0DVrFrzUvDrSXmi6kpJe3G8hCclHXqCDXHPom7bW
+/U7YLdpX7/cbOoaHoD3F/pEeiwwyQaSL1LuOVt+/bnGCcYq5f6bp2ta/aRX1pERY6LHdM7SMBNx
gK2Oijk8c8157Lr2vfbZriSSYXEtt9lkJhxmLGNuMVbstW8X3MliLM30r2a7ICkGSFIxtJxyPrWb
oVEk+b8WWq8G2uX8Dr9LtdGi1WS40p7ZZZtIuftMFq7PGjADBUtzg1z+jW8nh/wVq2qX4MTanCLW
zhf70gJyXx6CtiPw94vvphq2u6pDpMUcLRF5NinyyPmUKOOfevPb7ULvUZEa7uZJzEgjj3HhUHAA
HYU6UOdtKV9r9dvMVWfIk3G29um/kTyceGrb/r6k/wDQRWfWjJ/yLVt/19Sf+gis6u2PU459Aooo
qiQooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK
ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA
KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo
oooAKKKKACiiigAooooAKKKKACtHTNEvNVt7y5hULbWcRkmmc4VcdF+p9KrWFlPqWoW9lbLumnkE
aD3Ndl47uIdFtbXwjppxb2qiS7cdZpTzz/P8ayqVGpKEd3+RrTppxc5bL8xNMt/Bj+BZJb2WAa75
UhVTIwbdzt46elcLkDqea9e0DSdOm+EM15JY273It5iJWjBYEE4OaX4X6bplx4Qu7q8sLe5aOdzu
kiDNgKDjmuRYlU1OWrs7f8MdTw7qOEdFdX/4c8g3D1FbnhTw9/wk+urppuTb7o2fzAu7p2xXp/h7
WvCHi7UJNLi8OxxOYy/7yBACB15HTrWP4Y0eLQfjFcafbk+RHC7RgnJClQcfhVSxbcZRs4ySuTHC
pSjK/NFuxwvijQh4b1+bSxcG48tVbzCu3ORnpWMSB1Net/EfVNMvL6Xw/DpedYmeJVuti9yMDPWr
t1B4W+GumWqXWni+v5xyxQMzkdTzwBRDFyVON4tyf4+Y54VOcrSSivw8jxgEEcV6tp3h/SJPhFJq
b6fA16LaRhOV+bIJwc1N4j0HRPFng1/Eeh2q21zCjOVVNm4L95WA4z71c0r/AJIdL/16Sf8AoRrO
tiPaQi46PmSZpRw/s5yT1Ti2jy2W80pvDUVqlnjUQ+Wmx1H1r1bQpT4q+Ec8F388sUMkW48klBlT
/KvEhwo+le3eHIT4Z+EtxcXQKPLDJOVPBBcYUfyqsalGMbb30IwcnKUr7W1PER0FLSDpzS16BwBR
RRQAUUUUAFFFFABRRRQAUHpRQehoEbWtWjS3Vu4ns1zaQ8SXUaMPlHUEg0aTqGr6HIX03WLW3z95
Vv4irfUFsVwXj8f8VKv/AF6Qf+ixWFdaTf2NvDcXVpLDFMMxs64DV4k8fNXhyppHuQwEHafM02e/
J8RvE6rh7zQ5T/eeaHP/AKFUNz8QfFlwpVdX0qAH/njcQA/mWNeBx2F1LaG6SB2gEgj3gcFiM4Hv
iq+OeawWKX8kfuN3hW/ty+89fvpdR1OQyX+r21y/rLqMTY/Ddiqn2Fs/8fWn/wDgdF/8VXleKOK2
WZVFokv6+Zi8tpt3cn/XyPYbqEw+HLVTJC+bqTmGZZB90d1JrKqn4Z/5ExP+v5//AEAVcr1cLUdS
kpvqeXiqap1XBdAooorc5wooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAO5+E9mtz4zEzjP2aBpF+p4/qa5nxFcvd
+JdTnkJLNcvn8CQP5V0vwovVtfGixOQBcwPGPqMEfyNZnj3RpNG8XXqMuIrhzPC3YqxyfyOa5Iu2
Kkn2Vjqkr4ZNd3c9E8OH/iys/wD17z/zNR/Cz/kQdS/66S/+gCvO9J8ZajpWg3miqkc1ncoy7X4M
ZYYJB/pVnw746vfDmiz6Zb2cEsczMzO7EEZGO1YVMLUcZpdZXOiGJpqUG+isaHwk/wCR3P8A17Sf
zFdVbHHx3uc/8+p/9AFeZ+GfEU/hjVzqNvBHNIY2j2SEgYOPT6VLf+K9QvPFP/CQRBLW8BUqI+VG
Bjv1BFa1cPOdWTWzjYypV4QpRi91K51vi+Oax+LNtqU8Eq2aywMZih2Y6deldv431y80SO2ubfQY
9UgcFXcjcYz24APBrzDX/iPqPiLQ5NLurK1RJCpaSMtnIOehqfQvinrOj2SWk8MV9FGNqNISrgdh
kdawlhqsowcopuOlr7o3jiaUZSSk7S1vbY3b3x9ra+HJpn8JrbWE4aHzdxUAsMZxj9a0tJIPwOlw
c4tJR/48a4nxH8SdX8Q2T2PlQ2drIMSJH8zOPQk9vpWZpXifV7XR7nQLVftFtdgoIdhZlJ6lcVX1
WTgtEndPcj6zHneras1sdN8P/h82qi31rVNo08HfFDnJlIPU+i8fjT/id4xh1ORdD02QPaQNmeRf
uu46KPYVy0ni/WF8PwaDDN9mtIFKMIuHfkkhj/hWBW8aEpVfa1XtsjGVeMaXs6a33YUUUV1nIFFF
FABRRRQAUUUUAFFFFABQehooPT8KAOb8f8eJl/69IP8A0AVrxappEkVvc3t/ZvrDQmOO5WFmRfkA
VpVIxuGMAgGl8WeF9W1jWEvLC3jmga2hUOJ0HIQAjBOaw/8AhBPEf/Pin/gRH/8AFV8xUhLnenU+
npzjyLXodHF4usba/sI7a8jjt4r8yOVtwFAMSqzgY4BfccehqG21TwubWF74W0l/5ZkkkEBwJIid
ijAwRJkZ47Vhf8IJ4i/58U/8CY//AIqj/hBPEX/Pin/gRH/8VWfJLsXzx7o3n1vQ7bRP3E8Mt8sD
i3kaAF0JVeCNoA53AdfWsvxVqmlXumWsenpbYyjLtXbJF8gDKflAwWyepqr/AMIJ4i/58U/8CY//
AIqj/hBPEf8Az4p/4ER//FUckuwc8e6Nzwz/AMiYn/X8/wD6AKuUabpd3o/heK1vkWOdrt3CCRWO
3aBngmivocEmqEU/P8z5/HNOvK3l+QUUUV1HKFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBNZ3c1hewXdu22aBw
6H0Ir3CJ9D+KPhtFmPlXkQ+YL/rIHxyR6qa8JqxY393pl4l3Y3EkE6dHQ4/A+ormxGH9raUXaS2Z
0Yev7O6krxe6Om1v4b+INHdmjtzfW46S24yce69RXKSwywOUmikiYdVkUqf1r0/RfjHNEqxa1Yeb
jgz25wfxU/0NdZB4/wDB2qqBPdQqT1W6hx/MEVz/AFjE09KkL+aOj6vh6mtOdvJngG4eoo3D1FfQ
4uPAtz827RGz6iMU8Xfgi2G4SaImO4EdDzB/yMf1Bfzo+eoYJrhtsMMkh9EQt/Kt3T/AviXUyPJ0
qaNT/HP+7H617LL468H6evyajajH8MEZP8hWHf8Axi0WEEWVnd3TdiwEY/Wl9bxE/gp/f/SD6rQh
8dQydI+DcjFX1jUQq94rYcn/AIEa7eDTfC/gexaYLb2Y24M0pzI34nk/QV5fqvxY8QXytHZrBYRn
vGN7/mf8K4u7vbrUJzPeXMtxKeryuWNL6tiK38aVl2Q/rOHo/wAKN33Yy4YPczOpyrOzA+xNR0UV
6Z5oUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAmB6UYHpS0UAJgelGB6UtFACYHpRgelLRQAmAKWii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAEwPQUbR6ClooAKKKKACiiigAooooAKKKKACi
iigAooooA//ZDQplbmRzdHJlYW0NCmVuZG9iag0KNiAwIG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1
YnR5cGUvSW1hZ2UvV2lkdGggNzIvSGVpZ2h0IDcwL0NvbG9yU3BhY2UvRGV2aWNlUkdCL0JpdHNQ
ZXJDb21wb25lbnQgOC9GaWx0ZXIvRENURGVjb2RlL0ludGVycG9sYXRlIHRydWUvTGVuZ3RoIDcy
OT4+DQpzdHJlYW0NCv/Y/+AAEEpGSUYAAQEBAEgASAAA/9sAQwAIBgYHBgUIBwcHCQkICgwUDQwL
CwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04MjwuMzQy/9sAQwEJCQkMCwwY
DQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy
/8AAEQgARgBIAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQ
AAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYX
GBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqS
k5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz
9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQE
AAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1
Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKj
pKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwD
AQACEQMRAD8A4yiiivrT5MKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC
iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA//
2Q0KZW5kc3RyZWFtDQplbmRvYmoNCjcgMCBvYmoNCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0lt
YWdlL1dpZHRoIDk5L0hlaWdodCAxMTUvQ29sb3JTcGFjZS9EZXZpY2VSR0IvQml0c1BlckNvbXBv
bmVudCA4L0ZpbHRlci9EQ1REZWNvZGUvSW50ZXJwb2xhdGUgdHJ1ZS9MZW5ndGggNDQ5Nz4+DQpz
dHJlYW0NCv/Y/+AAEEpGSUYAAQEBAEgASAAA/9sAQwAIBgYHBgUIBwcHCQkICgwUDQwLCwwZEhMP
FB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEc
ITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgA
cwBjAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMC
BAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYn
KCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeY
mZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5
+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwAB
AgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpD
REVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ip
qrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMR
AD8Aq2jaZpvhCzv7jRba/uLi7liLTSOu1VVSMbSPU1W/4SHSP+hR03/v/N/8VRef8k/0r/sIXH/o
KVz1fTQgpXbvu+rPmpzcbJW2XRdjov8AhIdI/wChR03/AL/zf/FUf8JDpH/Qo6b/AN/5v/iq52ir
9lHz+9/5ke1l5fcv8jov+Eh0j/oUdN/7/wA3/wAVR/wkOkf9Cjpv/f8Am/8Aiq5+OOSaRY4keSRu
AiKST+Arp7L4eeI7uITTWsdjB/z0vZRGPy6/pUTVKHxO3zf+ZcJVZ/Cr/Jf5EH/CQ6R/0KOm/wDf
+b/4qj/hIdI/6FHTf+/83/xVaf8AwhOiWpxqPjTTY2HVbdfMx+OalHhrwL0PjNyfUWxx/Ks+el0v
/wCTGnJV62/8lMf/AISHSP8AoUdN/wC/83/xVH9v6K3EnhGw299lzMp/Pca208BaJqB26T4ysZZD
0SZdhP6/0rH1vwF4g0KNpp7Pz7ZRkz2x3qB6kdR+VOM6Ena7v5tr8xShWir2VvJJglj4d1s+Xp1x
NpV633IL5w8Mh9BIACp/3h+NYd9Y3Wm3klpeQPDcRnDI45H+I96rdR7V1NnK3ifQpdOuDv1PToTN
ZSn70kS8vET3wPmH0IrV3p63uvyMlappaz/M5eiiitTI6C8/5J/pX/YQuP8A0FK56uhvP+Sf6V/2
ELj/ANBSufVSzBVBLE4AA5JrOls/V/maVd16L8hACSAASScACtKxtbKC7P8Abi3sECpuWOKLDynP
3QW4A9+a1dS0eHw//Ztk37zXpJY5pgW+S3B+7GfUnIJPatrx3aeItX8S6TY6rFYRXc6eXALd2KHL
fxE9OazdZNpLZ319OxaotJt7q2nr3MY+NZ7GJrfw9YW2kQkYLxr5k7D/AGpG5/LFc/eX95qEplvb
ue4cnJaWQt/Ou0/4VF4m/vWH/f4//E1X8K+HJbD4jWmka3ZRscOWikAdHGwkEdiKmNWhFOUGm0r+
ZcqddtRndJu3kcUAO1LXdfEPwhc6VrL31tbwJY3cyxW0EH3t20cbQO5BpIPhP4mmsxOy2sTkZELy
/P8AQ4GAfxq1iaXIpt2uQ8NV53FK9jjbSwutRn8iztZbibBbZEhY4HfArpfDnivxF4XupIgtxPaQ
HFzaTAkIO/X7prV+GFncaf8AEKS0u4WhuIreRXRhyDxWD4qvri28Wa/DFJtjmunEgx1GamUlUm6T
SatcqMXTgqqbTvY6Tx14d06+0SDxfoKBLWfBuIlGApJxux2IPBFch4UuTa+LNKlHT7SiMPVWO0j8
ia77wdmb4Q6/Hccwr52zP+4D/OvOdA/5GLS/+vuL/wBDFRRb5J03ra6+RdZLnhUWl7P5kOpQLaar
eW6/dindB9AxFFTa7/yMOpf9fUv/AKGaK646xTOSWkmaN5/yT/Sv+whcf+gpV74a6bFf+Lo5rhd0
NjE1ywPcr0/U5/CqN5/yT/Sv+whcf+gpW78JJY/+Enu7SQ4+1Wbov4EE/pmuWq2qE2vP8zqpJOvB
Py/I5WS/l1TxSL6ZiZLi8WQ/i4wPyr1Lxx/yU7wp/vL/AOh15Nf2lxousz2soKT2sxHPqDkH+Rrp
tW8eDWPEWiaxNYlJNPx5qK/EhDZ+X0/GlVpOUoyhtZ/itApVFGMoz3uvwept+Prq5h+KOnrFcSxr
/o/COQPvntXTa0B/wuPw+ccmzfP/AI/XmXiTxXFr3i221pLR4Uh8vMTOCTsbPWr+vfEB9R8Wabr1
haNbyWUezy5X3B+TkcdiDisfq9RxirfZaN/rEFKTv9pM6OELc/HaWKd2aONi8aMxIDCIYIFWtbuP
Dlr43k1C98Vahb31tKpNuEOxAAPl6dCP51yniHx/Bqt1Zajp2krYapbzCVrnIYvgY2ngEj61qP8A
ErQb6SO81TwpFPqKAfvAVIJHTkjP55qXRq+7Lle1tLf1qUq1P3o8y3vrf+tDe0vV9K1z4sw32kzC
ZG05llYKV+YN7+2K8/1nRr7XviJqtjp8DSyvePk4+VBnqx7CmQ+NJ7Txm/iO2sLaAvkPbJwrKRg5
PqeufWr9n8QrzSLrWrqzsFjuNVmEyNKciIc9Bj5uv0rWNGpTd4LolqzKVWnUVpvq3odH41ubTwf4
HtvCVlKHup1BnYdducsx/wB48D2rzbQP+Rj0z/r7i/8AQxVW7vLi/u5bq7mea4lbc8jnJJq1oH/I
x6Z/19xf+hit6dL2VNpu7d2/UwqVfaVE0rJWS9A13/kYdS/6+pf/AEM0Ua7/AMjDqX/X1L/6GaK3
h8KMJ/EzRvP+Sf6V/wBhC4/9BSsnS9RuNI1O31C1bbPA4dc9D6g+xHFa15/yT/Sv+whcf+gpXPVn
TScWn3f5mlRtSTXZfke0XWmaB8U9OS/s5xZ6vGgWQdWHs6/xD0Yf/Wrg9T+G/ifTXbGnm7jHSS2Y
Pn8Ov6VzFrdXFlcJcWs8kE6HKyRsVYfiK7jS/i34hsUWO7S3vlH8Ui7H/Nf8K5/ZV6OlJ3XZnR7W
hW1qqz7o4+XRtVgJE2mXiEf3oGH9KbHpWpSnEenXbn/ZgY/0r1OH41QFR5+iTBu/lzgj9QKkb41W
OPl0a6J95VFL2+J/59/iHsMN/wA/PwPOrTwX4lvSBDot3g95E2D82xXTab8H9buSrX9zbWadwD5j
/px+taF18ablhi00WJD6zTlv0AFc5qPxO8UagCq3iWiHtbRhT/30cmi+MnslEdsJDq5Hodp4H8H+
EYVvNVmjmkXkSXrjGf8AZTv+teYeOtZstd8UTXmnbjaiNI0LLtztGOB6VgXFzcXkxmup5Z5T1eVy
x/M1FWlHDuEuecm2ZVsQpx5IRsgrQ0D/AJGPTP8Ar7i/9DFZ9aGgf8jHpn/X3F/6GK6J/CzCHxIN
d/5GHUv+vqX/ANDNFGu/8jDqX/X1L/6GaKcPhQp/EzTu9W0PSvh/pba3b6hMkl/cCL7E6KQQqZzu
H0rnv+Ev8B/9A/xF/wB/4f8ACmeOP+ScaD/2Ebr/ANBjrzSvBr4mrCrKMZWVz3aGHpTpRlKN3Y9O
/wCEv8B/9A/xF/3/AIf8KP8AhL/Af/QP8Rf9/wCH/CvMaKy+uV/5jX6pQ/lPTv8AhL/Af/QP8Rf9
/wCH/Cj/AIS/wH/0D/EX/f8Ah/wrzGij65X/AJg+qUP5T07/AIS/wH/0D/EX/f8Ah/wo/wCEv8B/
9A/xF/3/AIf8K8xoo+uV/wCYPqlD+U9O/wCEv8B/9A/xF/3/AIf8KP8AhL/Af/QP8Rf9/wCH/CvM
aKPrlf8AmD6pQ/lPTv8AhL/Af/QP8Rf9/wCH/CtDQfFfgmbxFpkVvYa+Jnu4ljMk0JUMXGM4HTNe
Q1r+FP8AkcdE/wCv+D/0YtJ4uu18Q1hKCfwnouu/8jDqX/X1L/6GaKNe/wCRh1P/AK+pf/QzRX0k
PhR87P4mZ3jj/knGg/8AYRuv/QY680r0vxx/yTjQf+wjdf8AoMdeaV83iv40vU+iwv8ABj6Hfa54
c8I+GZE0zU59dfUWtUm+1QJF9nZnQMNqnll5xnPY1zmleDvEWuWMl7pmj3d1bISDJGmQSOoH94+w
zXovhXRfE9xaxaH4v0V5vCwhZ1vrrH+gLtJEkU2eB0+XJB6Yqo2j63rum+Brnw1HPPaWUPlSSQNh
bacTMzM/9zIKtk9RXOdBj+E/h/LqvhvVNdvtN1G4htwq20NrIkZkYkhySwOAu3kY5qldfDTxHbeG
rLWhZSPHdSFfKUAtGMqEJOedxbAx6V0WuXdrd6V8SrmwkVraXVbZo2jOFYGSTkexrLuYL9/hP4dv
rGCaWOw1C7eeSJSywnMRUvj7uccZoA4qbT7y3uLmCW2lWW1YrOpQ5jIOCG9OeKu2XhfXNRezSz0u
5ma9R5LfYn+sVThmHsDxmvabuS207V3RyiQeObrLdOYXtwAf+/03/jtc9daDDeeIodAuori4n8P+
Ho8adbS+W91cHDvGDgnrISQBn5aAPPZvB3iO31qLR5dGuxqEy74oBHkuv94Y4I4PPtUw8CeKG1Zt
LXRblr1YhM0agHahOASQcAZHc16tZxtbw+GI30qfSHTS9ZAtJ3dnQeXkHL/Ng8kVyfgWOLUfh7rm
nR6Xdardm+gmksrS58qZ4grDdwpLqGPIA7g0Aee6lpl9o99JY6jay2t1GfnilXawq74U/wCRx0T/
AK/4P/Ri1tfEK6u5b3SrW80SfSXs7FYEiuLjzpWQMxUucAjrjBHQCsXwp/yOOif9f8H/AKMWgD0X
Xv8AkYdT/wCvqX/0M0Ua9/yMOp/9fUv/AKGaK+sh8KPlJ/EzO8cf8k40H/sI3X/oMdeaV6j4xtLm
7+HOhC2tppiuo3WfLjLY+WPrivO/7G1T/oG3n/fhv8K+bxX8aXqfR4X+DH0K/wBpnMHkedJ5PXy9
52/lSRzzRI6RyuiuMOqsQG+vrVn+xtU/6Bt5/wB+G/wo/sbVP+gbef8Afhv8K5zoKgdgpUMQrdRn
g05Z5o4niSV1jf7yBiA31HerP9jap/0Dbz/vw3+FH9jap/0Dbz/vw3+FAFVppG2bpHOwYTLE7R7e
lKZ5TN5xlfzc537juz65qz/Y2qf9A28/78N/hR/Y2qf9A28/78N/hQBXkuriWTzJJ5XkxjczknHp
mmxSyQyCSKR43HRkbBH41a/sbVP+gbef9+G/wo/sbVP+gbef9+G/woAqO7SOXdizHksxyTWr4U/5
HHRP+v8Ag/8ARi1V/sbVP+gbef8Afhv8K1/C2kakni7RXfTrtVW+gJJgYADzB7UAdxr3/Iw6n/19
S/8AoZoo17/kYdT/AOvqX/0M0V9ZD4UfKz+JiWfiHWNKhMFhqd1bQk7ikUhUZ9cCrH/CZ+Jv+g7f
/wDf9qKKPZwerSBVJrRMP+Ez8Tf9B2//AO/7Uf8ACZ+Jv+g7f/8Af9qKKXsqf8q+4ftZ92H/AAmf
ib/oO3//AH/aj/hM/E3/AEHb/wD7/tRRR7Kn/KvuD2s+7D/hM/E3/Qdv/wDv+1H/AAmfib/oO3//
AH/aiij2VP8AlX3B7Wfdh/wmfib/AKDt/wD9/wBqP+Ez8Tf9B2//AO/7UUUeyp/yr7g9rPuw/wCE
z8Tf9B2//wC/7Uf8Jn4m/wCg7f8A/f8Aaiij2VP+VfcHtZ92ZbyPNI0sjF5HJZmJyST1NFFFUQf/
2Q0KZW5kc3RyZWFtDQplbmRvYmoNCjggMCBvYmoNCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0lt
YWdlL1dpZHRoIDIwMC9IZWlnaHQgOTgvQ29sb3JTcGFjZS9EZXZpY2VSR0IvQml0c1BlckNvbXBv
bmVudCA4L0ZpbHRlci9EQ1REZWNvZGUvSW50ZXJwb2xhdGUgdHJ1ZS9MZW5ndGggNTQ5ND4+DQpz
dHJlYW0NCv/Y/+AAEEpGSUYAAQEBASwBLAAA/9sAQwAIBgYHBgUIBwcHCQkICgwUDQwLCwwZEhMP
FB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEc
ITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgA
YgDIAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMC
BAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYn
KCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeY
mZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5
+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwAB
AgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpD
REVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ip
qrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMR
AD8A4yiiivrT5IKKKKBhRRRQAUUmaWgAooooAKKKKACijNFABRRRQAUUUUAFFFFABRRRQAUUUUAF
FFFABRWt4a/5GC1/4H/6AaP+El1f/n7/APIaf4Vw1MRX9u6NGCdkm25NbuS6Rl/KdlOhR9iqtWbV
21pFPZJ9ZLuZNXLDSrvUi/2aPcE+8ScCrX/CS6v/AM/f/kNP8Ks2niy/gLfaNtwCOMgJj8hWGJq5
mqTdGnDm/wATf4OMfzRtQp5e6iVWpLl/wpf+3S/Iw5YngleKRSrodrKexrovDcVrZ6JrXiG5tYrt
7BYo7eCYbo2kkbAZh3A64NYF3cveXUlxJjfI2TjoK6Pw3C2reFPEmh2w3X8whubeLPMojbLKB3OO
cV11XP2Cc9Hpe34nNSUPbNQ1Wtv0LOgau/jWa70bVrKy82S2kltLmC3WJ4pEG4DKgZU4OQaz7fwi
xsbG4vNb0mye+iWW3inlYMynoThcDmrvgzTr3Q72713VLOezsrG0m3PcRmPe7KVVFyOWJNQ+J9G1
LVNL8I/YtPurkHSIk3RRMy7sngkDA6j865udwqcsHZHTyKdPmmrsq2/g/U31K/s7trexXT8G7uLm
TbHGD93nvkdMdaLjwleLLp/2O6s7+2v5/s8NzbyZQSf3WyAVPfp0rutYkiurXxFpsemprN3ZrZef
ZrK4LbUwxBQhm2nqBWJod1fw3Gh2K+E20bTZdZhl8x2lO6XBHHmEnoD09KSxdRq/9bfeN4Smnb+t
/uMk+CJpHuLaz1rSbzULdWaSzhmYudvULlQCR6fWs/wiumz+K9Nj1Up9heXEm84UnB2g+27FbHgx
f+L1hu/2y8/9AlrjtLsLnVJktLSB57hwSkaDJOAScD6Amt4TnJShJ9N/W5hOEIuMorr+VjqfEGve
IbC4utK1jRtMhV1ZI0+woAqkEBomGOnY5PQVXs/CU0mnWt5farpmmLdjNsl5MVaQdA2ADhfc1t+G
4dbubC+0XxJZXJ0OC1kl868hZTZsq5Uo7DI5GNv9M1n+LtJ1DXf+Ee1DTLK4vLSXSoIUe3jZwjrk
MhwOCDWMajg+RWXmbSpqa53d+Rn3HhXUbO31qW68uJtJMPnITkuJWwpUjgjvUWn+HrvU9LjvreSL
El9HYpGxIJkfoemMc13esxyX+meKdFtAbjUrfTNMjkhi+di0blpMY64BFZvhmxvbDwvpa3lpcWzP
4ns2UTRshYcDIz1HWmsXPkb63X5ITwkOdLpZ/mY7+CZzff2ba6tpt3qYkMclrBIxMeM7ixKgALjm
ql14aMbwxWGr6Zqc8sywCC0mJfefQEDK+44rZ0IBvip4otgwWe7OoQQZOMyMzYGe3Q1neCtKvtE8
Y6VeapYXNpbpdeU0s8LIodlIAyRjrTVepq29lf1E6FPRJdbeg6fwVcILiK21XS7y/tkLzWUE5Mqh
fvYyAGI7gGuYDBhxXeWj6joniea4sPh4yX1u8n7/AM24ZMEEFssxQggnnpzXn8AITmtsNVnNvm/r
7jHEUoQS5SWiiius5QooooAKKKKANbw1/wAjBa/8D/8AQDWTWt4a/wCRgtf+B/8AoBrJrhp/79U/
wQ/Oodk/9zp/4p/lAKdHFJNII4o3kc9FRck/gKbWjoWu3PhvV4tTtYYpZYlYBJM7TkEdj712TbUW
0tTlgk5JPYr/ANnX3/Plc/8Aflv8Ka1hqEJE6W11E0fzCQRspX3zjivavhz471Lxjd6jFfWdtbi2
RGQw7vm3E9ck+lcXrfxb12e71XRk0uyMZkmtFYBy5GSmevWvPWLqym4OH4noPCU4xU1P8DhL2/1T
U0Vb/Ury7RfuiedpAPpkmtrWPFd5NY6NZ6RqGoWiWlglvcJHM0au4Jzwp5GD3rUsfhZ4pubNZnt4
ICy5Ec0uH/IA4P1rm9V0e+0K+NnqVq1vOBuAYghh6gjgitkqFRpRa0MG69NNyT1KFu1zaXAube5m
huASfNjkKvk+45q7DJrusapb+XeaheagpzAfOd5AQM5U5yMYzx6V0GjfDvxFrdkl5Bbxw28g3Rvc
Ps3j1AwTj3xWr4U8Oap4Z+J+iW+pwqhmE7RsjhlcCJ89Pw60VKlFKXK02kx06dZtcyaTZxE0WqaN
qrGZruz1FDuLlmSUFhyc9eQTz71UiDwkNG7I6nKspwQfY16r4z8AeIfEPje9v7OGFbNkjVJJZQu4
hADgDJ6+orgvEHhzVPDN0kGpwCPzBmORW3I4HXB/p1p0K9Oolqr9ia9GpTb3t3M+71PWNQgFvear
fXEA6RzXDuo/AnFNs73U9NieKw1K8tY3++kE7IG+oB5rsbb4WeKbhAz20FvntLOM/wDjuazNf8Ea
74bt/tN9bK1tkKZoX3qpPr3H4imp4dvlTQOGIS5mmc3bvdWdz9qtrqeC5Bz5sUhV/fkc1NPf6rdz
xz3WqXs0sTh45JLhmZGHQgk8EetaeheGdW8STOmmWpkWP/WSMwVE+pPf2rU1j4deI9Fs3u5raOeC
MbpGt5NxQepHBx9KcnQUuVtXJiq7jzJOxgW+jaxqME+qQWt5crG7PNdKGbDj5mJb15yT71Xu7/U9
SRUvtRvLpE+6s87OF+mTxXq3w7fPwp8RsD0kucf9+Erzfwz4b1fxLuTTbUyCPHmSMwVE+pPf261l
CrCU5KaSUeprOlNQi43bkVJNU1ia1FpLq19JagY8l7hymP8Adziq6rtGK6zWPh14j0Wze7mto54I
xudreTcUHqRwcfSsHStLvtbvUs9OtnuJ2Gdq9h6k9APc10U50uVyg1YwqRq3UZp3KdFdyfhN4oEe
8LZk/wBwT8/yx+tUrL4c+Ib2/u7Ex20FzaqjOksw5V87WBXII+U0vrNH+ZB9Wrfys5OinvDJHdPb
Mh85JDGyd9wOMfnW54k8H6n4Vht5dRe2xcMVjWKQsTgZPYeo/OtHUgmk3uQqc2m0tjAoooqyDW8N
f8jBa/8AA/8A0A1k1reGv+Rgtf8Agf8A6Aaya4af+/VP8EPzqHZP/c6f+Kf5QCiiiu44z1D4KD/i
Y6z/ANcov5tWH4GtIbv4wXQlUMIru5lUEfxBmx+ROfwrc+Cp/wCJlrP/AFyi/m1choWvReG/ibda
lcAm2F9cRzEDJCMzDI+nB/CvJqJutVS7foetTaVGm33/AFPQ/F3h74h6t4me60fWI7PTotot4o7p
o84AyXUDDEnPXPGKl+I+mte+H/DcmprH9vF9bwTtH93MgxIAfTIH5VR8SfDkeMdXfxBoXiJBBdhS
6BiybgoGVKnuAMj1zXE+KfC8fgibTZ/7dXUtQS5ErW4OPL2YIJG4nr3IFctJXceV6ryOmq7KV1o/
M6r40a1qdje6TpmnXk1nbtE0j/Z3MZY5AAOOwx096534e6jqmo/EXQRqN/cXfkCcRmeQuVBifIye
e1d54l8OWHxPstO1fRtUijlhQqQw3fK2DtYA5VgQfzrB0XwxD4T+KHh20GqR3lxKs7Sqi7fKxE2M
jJPOfbpWtKVL2Di/iszKrGr7ZSXw3RjfFPXNci8e3Vla6ve29rDHEY4oZ2RQSgJOARk5J5roviRL
JefCDQL+5bzLpvs0jSHqWaE7j+Jrkvilz8SNR/65Q/8AosV1XxBOfgj4fxz8tn/6JNHKowpSW4KT
lOpFlr423+oWVpoq2F9c2olklEnkTMm/AXGcHml8FXd3rHwg16PVbiS7MIuIkeZizbRErDk8nBJx
+HpUHxyIMGg45/eTfySnfDw4+E/iT/fuf/RCVmor6spdbmjk/rLj0sLDqE/hn4Cw3+lt5V3OinzR
1DSSYLfUDgfQVT+DviLWr/Wr3TNT1C4vYGtTOpuZDIyMGVcAnJwQ/T2qXwVd6X41+Gv/AAh95dpa
38K7EB+8wDbkdRxuxwCB+ma1fDnhnT/hjBea1rerQtI0RiQKu35cgkKCcsxIHA9KHycs1P4m9AXN
zQcPhS1HeHLWKx8H+PLSAbYYdQvkjUfwr5K4H4Cs63vp/C/wDgvdKbyruZFPmjqGkkwW+oHA+gqX
wRqLat8O/GepSLsa7vL2fb/dDQqQPw6VU8FXel+Nfhr/AMIfeXaWt/CuxAfvMA25HUcbscAgfpmo
s9XLurl3WnL2diL4O+I9a1DWr3TNTv7i9ga1M6m5kMjIwZVwCecEP09q2/Atnb6LJ41uraJc2t7L
HEpHREBYL9Pm/Sk8OeGdP+GMF5rWt6tCztEYk2jb8uQSFBOWYkDgelYPw18X2V5q3iGz1aRLZdYu
HuId7BRl8hkz64K4+hq6lpOTpfDoRTvFRVX4tTl/BGva9qHjzSpbzWL6UT3I8xGuG2sDnjbnGPbp
XpVxq50/47xWjviG+0xYeem8FmU/+Okf8CrO8PfCa+0PxNaX41K2ls7abzEG1g7L2BHQH8a574pX
smm/FOy1CHPmW0EEq4OMlXY4qpKnVqKNPsTF1KdNyqdyxc+Hifjr9i2ZhluVvvYrje2f+BAiqnxh
1U33jaHTkbMen24DD0d/mP8A47sr12HT9Ovddt/F0M8bp/Z5gVxyChYPuz7fMPxr5wv9RbWtf1DV
X/5erh5FHopPA/AYH4VphW6tWN/sozxSVKnK32mMooor2TxzW8Nf8jBa/wDA/wD0A1k1reGv+Rgt
f+B/+gGj/hGtX/59P/Iif415UsVQoY6ftpqN4QtdpdZ9z0o4atWwcPZQcrSlsm+kOxk0Vrf8I1q/
/Pp/5ET/ABo/4RrV/wDn0/8AIif41v8A2pgf+f0P/Al/mY/2djP+fUv/AAF/5GJNCso5ojhVE29q
2/8AhGtX/wCfT/yIn+NH/CNav/z6f+RE/wAaX9pYC9/bQ/8AAl/mP6hjbW9lL/wF/wCRg/ZijExS
PHnrtYjNJFaJF0rf/wCEa1f/AJ9P/Iif40f8I1q//Pp/5ET/ABqf7Qy+9/bQ/wDAl/mV9Sx1reyl
/wCAv/IwjbkOXjdkYjGVODTFs1AOeSeuTXRR+GNVeRVa3CKTgsZFIHvwabrGhS6SsbmUSxvxkDGD
9KUcwwE6ypQqRcpbWd/xWgSwWNhSdScGorurfnqYcVuI+FHJ7VqzeCtdS1N7Jo16INu4sYTwPUjr
itf4fQxTeNbIyoHWFZJwrDgsqEr+RwfwrnDrGr3d5LeyajdefKSXcTMCc9RwenPSumbfPyRWxjBL
k55PcqR2yK+4UslushBNdRY6Zo2neGodb11ryVbmZoba2tSqltv3mZmB47YFM1fRbKFtFvNNnnbT
NXz5PngeZGyuEdTjg4JHNCq078gnSqW5jmmtUZcelMa03uHldnYDALNk16E2jeEF8WN4WJ1lbsy+
Qt2ZIynmHp8uPu5/Gk+H6abb+Lp9PvrWWW+h89FkVx5YCqQQVI68HBzWcq1NxcuXY0jRqKSjfc4B
7VGxxStaoygeneum0bTtH1/V7uWA3djo1laNdXBkZZJdq9QpAAySeKkksdB1jRNRv9BN/bz6cFkm
gu2VhJGTjcpUDBHcGr9tTvZoj2VS10zkmtN8geV2dgMAsc8V0PhpPC/2meHxOJ1tnQCKWHd8jZ77
eensa0EsfDul+FtH1bVY9SuZtTM+2O2lREQRvt5yCSTkfrXLv5cruUVhGWO0NyQO1CUKkXGGnmDc
6bUp6+R6Zpdt8L/DuowavD4ku7h7U+ZDBJIXVTjjCqgOfqayjq3hLxz4t1bUPEF9c6bbhIotPwdp
ZBu3FjtYA5wce/euD+yx5zinGFCMY4rGOCafNzO5vLGprl5dD0nVPEvhPwn4Kv8AQvCl7Je3eobg
8p5KhgFLM2APu8ADvXmlvH5cQFKtvGhyBUtb4fD+yu27tnPXxHtbJKyQUUUV0nOFFFFAgooooGFF
FFABRRRQA+KV4JVliYq6HKkdjVm+1S71EobmXcEHygDA/SqdFZyoUpVFVlFOS2dtUaRrVIwdNSfK
910Zr+FtYh0HxNZ6hcqzWylo5gvXYylSfwzn8KsTeFbG3WaeHxToslkAWiPnnzmHYGMDIb9K58jI
qPyFzmonSlz88XYqFSPJySVzutD1y5ufBttpel+I7fRdRs7iRmFzL5STxtzneQRkHtWRrVzevrGk
rqXia31h4ZQxaFy8cALLn5yADnHb0rnWiVhyKFhVRWawtpuRq8TeKiddNe2Z+Mn9oC6gNp/aSv8A
aBIDHtyOd2cY96b4Z1KxtfibdXdxdRRWss10qzs3yDeHCkn0ORz71ygjUCjy1xij6srWv0sL6y73
t1udX4SuY/Cut39jcatawNe2LQx39rKJo4JDgqxK8Y459Min6zc66mjXKaj46sL6ORdq2lrcmczc
jg4XCjvz6VyAhUDGKQQKDkCk8LeXM2NYm0eVHQa3dW0/gbwhax3EUk9v9s86JXBaPdKCu4dRkcjN
YYGBTRGM5p9dFKnyKxhVqc7uFFFFaGYUUUUAFFFFABRRRQIKKKKBhRRRQAUUUUAFFFFABRRRQAUU
UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAf/9kNCmVuZHN0cmVhbQ0KZW5kb2JqDQo5IDAgb2Jq
DQo8PC9UeXBlL0ZvbnQvU3VidHlwZS9UcnVlVHlwZS9OYW1lL0YxL0Jhc2VGb250L0FCQ0RFRStW
ZXJkYW5hLEJvbGQvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0ZvbnREZXNjcmlwdG9yIDEwIDAg
Ui9GaXJzdENoYXIgMzIvTGFzdENoYXIgMTIxL1dpZHRocyA5MzQgMCBSPj4NCmVuZG9iag0KMTAg
MCBvYmoNCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvQUJDREVFK1ZlcmRhbmEsQm9s
ZC9GbGFncyAzMi9JdGFsaWNBbmdsZSAwL0FzY2VudCAxMDA1L0Rlc2NlbnQgLTIwNy9DYXBIZWln
aHQgNzY1L0F2Z1dpZHRoIDU2OC9NYXhXaWR0aCAyMjU3L0ZvbnRXZWlnaHQgNzAwL1hIZWlnaHQg
MjUwL1N0ZW1WIDU2L0ZvbnRCQm94WyAtNTUwIC0yMDcgMTcwNyA3NjVdIC9Gb250RmlsZTIgOTM1
IDAgUj4+DQplbmRvYmoNCjExIDAgb2JqDQo8PC9UeXBlL0V4dEdTdGF0ZS9CTS9Ob3JtYWwvQ0Eg
MT4+DQplbmRvYmoNCjEyIDAgb2JqDQo8PC9UeXBlL0ZvbnQvU3VidHlwZS9UcnVlVHlwZS9OYW1l
L0YyL0Jhc2VGb250L0FCQ0RFRStWZXJkYW5hL0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9Gb250
RGVzY3JpcHRvciAxMyAwIFIvRmlyc3RDaGFyIDMyL0xhc3RDaGFyIDEyMi9XaWR0aHMgOTM5IDAg
Uj4+DQplbmRvYmoNCjEzIDAgb2JqDQo8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0FC
Q0RFRStWZXJkYW5hL0ZsYWdzIDMyL0l0YWxpY0FuZ2xlIDAvQXNjZW50IDEwMDUvRGVzY2VudCAt
MjA3L0NhcEhlaWdodCA3NjUvQXZnV2lkdGggNTA4L01heFdpZHRoIDIwMDYvRm9udFdlaWdodCA0
MDAvWEhlaWdodCAyNTAvU3RlbVYgNTAvRm9udEJCb3hbIC01NjAgLTIwNyAxNDQ3IDc2NV0gL0Zv
bnRGaWxlMiA5MzcgMCBSPj4NCmVuZG9iag0KMTQgMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQg
MiAwIFIvUmVzb3VyY2VzPDwvWE9iamVjdDw8L0ltYWdlNSA1IDAgUi9JbWFnZTE2IDE2IDAgUi9J
bWFnZTcgNyAwIFIvSW1hZ2U4IDggMCBSL0ltYWdlMTcgMTcgMCBSL0ltYWdlMjggMjggMCBSPj4v
Rm9udDw8L0YyIDEyIDAgUi9GMSA5IDAgUi9GMyAzOSAwIFI+Pi9QYXR0ZXJuPDwvUDIwIDIwIDAg
Ui9QMzEgMzEgMCBSPj4vRXh0R1N0YXRlPDwvR1MyNyAyNyAwIFIvR1MzOCAzOCAwIFI+Pi9Qcm9j
U2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAgMCA3MjAg
NTQwXSAvQ29udGVudHMgMTUgMCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9D
Uy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyAxPj4NCmVuZG9iag0KMTUgMCBvYmoN
Cjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMjY2NT4+DQpzdHJlYW0NCnicpVrbTxw3F39H
4n+w1JfZSgy+X6SqUksoTfUh0YQmldI+oO1yiRZIgfC1/31/x56Zndm1PTR9YMFnfa4+Vxt2eMa+
+ebw9Oj1K8a//ZZ9/+qI/bm/xxlvOedCSu6Yk5wZzdnDan/v/dfsDl+3XAmNPcpZfFoT2MPVgMW5
FVxP0C6/3t/7eX+PHZ8eMTZiKXZYZpATTydC6wzDNmZU/2crDRDY8nZ/7/D17cXVyrBX9yzHSW44
HXSMuAiu09MrITI8De9Z6tAKaZgSrQckRKQRW2FLfNUuX2NEqPPVDoolVQ2zkbMmVccsXYmj3uVo
vbaJo9Ra5KwruBqsy6OOlgcSwkXuG7a+xNZkDCytrjuSxaFqHdkKxVtjmTat10xYoPmxgYvq2o6v
IPn/H31TO0FeqRU+hRXszcn+3p4UnvQRTrVWMSV96z1xU0Ajgd5maLuO9vfnkOMHyYRk55cwVhKY
KS+JqRSqhXznt+XA2AWTTB8atvidnf+0v3d8nuHuR9y3WIrgW5dYzhAJFSJeQ6CXEBG8QsWGNryM
ipiYUzChcVZTi2rZSsskhy/IjuaP948L2zwtVMNOjxYHsjkeMRkLpIVtpZgi1wWSW+crXRvsRCC4
bSsD095u7P3r6g6SHLPFgW2+e1joZnmNj5un1fLp88OqIJwRcFA/JVQXbpQ5Ds8unp5WD3ds+Ygt
iKLHJYLn8OStdOzqEfnCM9C2cE+jx/lWksfHmLCGQsIFiU/vZQqJHbRcDAi9HQQ7p2bgjQFBi2+k
LsUBcaRkgFR5vsSpvi8YykrVajMmBjBh1K2VSz9czaQfLSTlnMgYqQDW0ZbykZIaaW+UfmQx7Qm7
bR6z7UPGtCCsBXl2Ovg/7smPb+HSvGAFQU7sp1h1A7iSuygxuIvyyV0cqhnlQJvSgKA0IIiVGXtP
yWtmsLNO5DNW8ltehNgXUFmZ1tScKJlPRfP9Uoo2jxItRrTmrNenyUICl4rqLzJ9YLfDSilPFlgT
wGYBtB+rawLItMPRjkjDRIBWA4of7UhYl7lGZtymbWpeNtwE+8jYB8Ui799hGfYH27MmtTJBd6Jo
tFPwjA6wjieYbaHEYKRtxyAboW2LJVXESqxgI2LS2pFT8ZkaPUMi51lSZoqKnXqWQD/l0VrAtFp+
UZ3+hUrQ6oEtBG8ekew/XSxXbCGpLOnmvvtZPy5Mw35rfjj97vB2SRG+WrhmfQ/o1cI3vy0KzqqC
bdHnjcSb8Vap6t6qA7o2aqKit9KKGh8pqPFZE8AMANkDuv3J73RQCYB62NGgLhRJRqf9IX3tKcgq
rtqXDjpqZelTouBEEQVV2+R++HMTBlrwrZUcwkGjJZTQNCKhNjue9ugIrcjRFweD/p0YpzDuVpuo
NTJkAZswNkqlHX0YG3StE/mNdKMdFZnsTMYxjik3ZAusNLd9qsCe6arb2eUaciZuBtQhoGgzTqH7
riKbqwa6BGtEaadziEGt9CjICw14GS0b2H62W5RoFSCTsqAYviiuKUxVs1rfX7FCcEqB84ScliIh
xebN3VPMBpcXqEDLUsMnvaM+ZoJZj+rw0klGxvFXuDigCR73y9iMl4ypcg08lSAUcuFNNGyt4naN
N0Mae0up7hKaU0d+8/BnKamhPVAT4jPqq011yautTfQfUhsNRzd6yWpxUDKjtkYB5CZJVvSaHbVf
v31T6jWQRowa05vTdCZ9KzQPSMwiCDoeSnbQnHqsBFiPALwDDCg94JpgLsLghzaSUUr0m2yHlXYE
1QEK+UDpaj7AUceoJlIYhamV0LHFeGnZrxLInqvJzaOo8hgu/kM2OHvHTj7Dq1ePVNZR7F1TSgvK
2pT3R9Fdn04VimbU86X5QNli9VTek5UkNMYvujmBN4xigYzeZ5EpdrL3DHrW5C4XSuhqcZQS7shV
Z/IQeQUuR/LuQpPBnzFGl4Z5p1vrxqTnzOXrUWV0LMzCx/7BONuv1qNVbG+Gnbqv+s4kgI+oXqRV
qvf9d7IWQGEmtxmfhikXg8DExUzjq/l2fZRbQ3lMwBLlARPgl4TDmxXK3CPFA6LhiQplKRoMZSZH
1mx979uE+Pdjj0kkbksTPzSVYYpdPWottqbJsDNyo7FQgm8i7XpxYJrnW7q3gVJFPZBGUa0k3WcM
1X5xIHRzR/gfFwe6IaMsnwhqGmrt70q0UKfg7hNada1yxUqh4SRdOFT0HZVPZNBnBouSNrqcoxDY
2kICt8H9Um0UPFPLKa26NirXcXAUHCgTm+hE5Pn1QqjmDan0c6mTQpZRcopW593Xq839Vz7sXLrq
7u6EBY6LfooRZ7YatD2kjaEPSw2t9NULZW1nm1qPQDRDUa62J8voCZ9RqAQOT8WujH7WN3elrlTY
eI4j6nO2dDOpK9qArsBfbIOdxn6auJBeAw1d6HKtrxvg0wVV3CuM4uS9+PPykubwG3xULIDj02Py
cxbIXaE7qpagQu8UfXTHfLm8p7B6pnz3wKJ4yyeKtpv7UmgJoiWmpKoCGV5uDNIc2A243Wozz+JY
soDNgKtcSDv6yRMmT4OaGlDUaEe55pk+SRueWvVuYE6r0cDMeRYwGvuDT4BUubt5Jw3/huv+u4oo
cmbWTtW3v93rVtRSx65YepMHbG73fEwBNFClVptoEECLAUWNdlREVXOlTdPFOCVRQ81bpa5/aL46
OSt1V9BFjGnMuZzODlLQCUTsJi2/O00tsGn+oppCQ2JBgBAvuybIdQnMTB6SOh5PZ3Kair2r3S+Y
+VQsfSqgyBh25kr69O2bWoMkTaASJrVufX8hTfPzar2idHG7ImQCPPxdLOamDVMCdXu5GZ+nHOh5
769Yja6ind1adTs7b0eykV4MqDFWez93sv+u4uS+mMC0kXRuXSj2K91fX2nDqUHeBQyhqE3sx6Xu
VdMm5Ys07BCK9nHe0XxGyrk3ge5BOd2mgpNAuqULigRYjwCuAwwoPeCaNvm0SQ1kZALYgUy3I2yw
cgJbPpc7YGWEDaJOUgms5A5Gb2g6PdQdlXwaEvMJsZc81Nn6I4JGC6H85DbAVa4TcsE4SyOXDWzu
GWHrfQqlBm72H+4Xfnx3Gnu1k890w2AqY0h06n9xuWBIKP0vLhes2upli8ZUcYdPtwPx7o1ul8uG
zFYKBKXBfMg96TXzQKxM9KKjs9LjnvauNWJM7UWOZ7aiY/eh1lIXi3RvWt0b8deFEs2q1LqhBG0j
1GXoa87o7W73fib/bKdMTCZgFtuyboVUy+kxQNBrsQzx2Tpau18sqUcKaXaLAGMU3RF2mP0KVGln
t0KGDOTwCQ+VB0m4o5oWS3qMSTwToJcnYY5kXcZ0VXhRtLlLJeoQDV1LWSLce//xVyXXRwVAmZ9s
rx/CdP5QmVDXcAT4q0T+Tg62W6h2j+1D836VegDBm4uHVfx9vSr+Rwi9oiFYN0zm5A6H/7u4u2LN
x4uDn84WW/nK76Yr1XoFuHZ9yFmM7lf9H1FiSd0Hpw9BH3F5aA8lTSyuJozLPSgY+k8HOWI5o5ET
JY02t4DwUgeKaviPHlmlmL3wxwgTLaHK/xb0D2jXEfsNCmVuZHN0cmVhbQ0KZW5kb2JqDQoxNiAw
IG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvV2lkdGggNzIvSGVpZ2h0IDcwL0Nv
bG9yU3BhY2UvRGV2aWNlUkdCL0JpdHNQZXJDb21wb25lbnQgOC9GaWx0ZXIvRENURGVjb2RlL0lu
dGVycG9sYXRlIHRydWUvTGVuZ3RoIDcyOT4+DQpzdHJlYW0NCv/Y/+AAEEpGSUYAAQEBAEgASAAA
/9sAQwAIBgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0
NB8nOT04MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy
MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgARgBIAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEB
AAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQci
cRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpj
ZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfI
ycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgME
BQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkj
M1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2
d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ
2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A4yiiivrT5MKKKKACiiigAooooAKKKKAC
iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK
KKACiiigAooooAKKKKACiiigAooooA//2Q0KZW5kc3RyZWFtDQplbmRvYmoNCjE3IDAgb2JqDQo8
PC9UeXBlL1hPYmplY3QvU3VidHlwZS9JbWFnZS9XaWR0aCAxNzIxL0hlaWdodCAzNjMvQ29sb3JT
cGFjZS9EZXZpY2VSR0IvQml0c1BlckNvbXBvbmVudCA4L0ZpbHRlci9EQ1REZWNvZGUvSW50ZXJw
b2xhdGUgdHJ1ZS9TTWFzayAxOCAwIFIvTGVuZ3RoIDI5NDEyPj4NCnN0cmVhbQ0K/9j/4AAQSkZJ
RgABAQEAeAB4AAD/4QBaRXhpZgAATU0AKgAAAAgABQMBAAUAAAABAAAASgMDAAEAAAABAAAAAFEQ
AAEAAAABAQAAAFERAAQAAAABAAASdFESAAQAAAABAAASdAAAAAAAAYagAACxj//bAEMACAYGBwYF
CAcHBwkJCAoMFA0MCwsMGRITDxQdGh8eHRocHCAkLicgIiwjHBwoNyksMDE0NDQfJzk9ODI8LjM0
Mv/bAEMBCQkJDAsMGA0NGDIhHCEyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy
MjIyMjIyMjIyMjIyMv/AABEIAWsGuQMBIgACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQID
BAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHB
FVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2
d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna
4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1
EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ0
4SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeI
iYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery
8/T19vf4+fr/2gAMAwEAAhEDEQA/APn+ur+H2gWXiPxFJZ36sYFt2kwrEHO5R2/3q5Su/wDhB/yN
8/8A15t/6MjqoK8kTN2iz0EfB/wyRkLPj/ro3+NL/wAKe8M/3Z/+/jf411N1dzwShY32rtzjANQf
2jdf89f/AB0f4V1csexyc0+5zv8Awp7wz/dn/wC/jf40f8Ke8M/3Z/8Av43+NdF/aN1/z1/8dH+F
H9o3X/PX/wAdH+FHLHsHNPuc7/wp7wz/AHZ/+/jf40f8Ke8M/wB2f/v43+NdF/aN1/z1/wDHR/hR
/aN1/wA9f/HR/hRyx7BzT7nO/wDCnvDP92f/AL+N/jR/wp7wz/dn/wC/jf410X9o3X/PX/x0f4Uf
2jdf89f/AB0f4Ucsewc0+5zv/CnvDP8Adn/7+N/jR/wp7wz/AHZ/+/jf410X9o3X/PX/AMdH+FH9
o3X/AD1/8dH+FHLHsHNPuc7/AMKe8M/3Z/8Av43+NH/CnvDP92f/AL+N/jXRf2jdf89f/HR/hR/a
N1/z1/8AHR/hRyx7BzT7nO/8Ke8M/wB2f/v43+NH/CnvDP8Adn/7+N/jXRf2jdf89f8Ax0f4Uf2j
df8APX/x0f4Ucsewc0+5zv8Awp7wz/dn/wC/jf40f8Ke8M/3Z/8Av43+NdF/aN1/z1/8dH+FH9o3
X/PX/wAdH+FHLHsHNPuc7/wp7wz/AHZ/+/jf40f8Ke8M/wB2f/v43+NdF/aN1/z1/wDHR/hR/aN1
/wA9f/HR/hRyx7BzT7nO/wDCnvDP92f/AL+N/jR/wp7wz/dn/wC/jf410X9o3X/PX/x0f4Uf2jdf
89f/AB0f4Ucsewc0+5zv/CnvDP8Adn/7+N/jR/wp7wz/AHZ/+/jf410X9o3X/PX/AMdH+FH9o3X/
AD1/8dH+FHLHsHNPuc7/AMKe8M/3Z/8Av43+NH/CnvDP92f/AL+N/jXRf2jdf89f/HR/hR/aN1/z
1/8AHR/hRyx7BzT7nO/8Ke8M/wB2f/v43+NH/CnvDP8Adn/7+N/jXRf2jdf89f8Ax0f4Uf2jdf8A
PX/x0f4Ucsewc0+5zv8Awp7wz/dn/wC/jf40f8Ke8M/3Z/8Av43+NdF/aN1/z1/8dH+FH9o3X/PX
/wAdH+FHLHsHNPuc7/wp7wz/AHZ/+/jf40f8Ke8M/wB2f/v43+NdF/aN1/z1/wDHR/hR/aN1/wA9
f/HR/hRyx7BzT7nO/wDCnvDP92f/AL+N/jR/wp7wz/dn/wC/jf410X9o3X/PX/x0f4Uf2jdf89f/
AB0f4Ucsewc0+5zv/CnvDP8Adn/7+N/jR/wp7wz/AHZ/+/jf410X9o3X/PX/AMdH+FH9o3X/AD1/
8dH+FHLHsHNPuc7/AMKe8M/3Z/8Av43+NH/CnvDP92f/AL+N/jXRf2jdf89f/HR/hR/aN1/z1/8A
HR/hRyx7BzT7nO/8Ke8M/wB2f/v43+NH/CnvDP8Adn/7+N/jXRf2jdf89f8Ax0f4Uf2jdf8APX/x
0f4Ucsewc0+5zv8Awp7wz/dn/wC/jf40f8Ke8M/3Z/8Av43+NdF/aN1/z1/8dH+FH9o3X/PX/wAd
H+FHLHsHNPuc7/wp7wz/AHZ/+/jf40f8Ke8M/wB2f/v43+NdF/aN1/z1/wDHR/hR/aN1/wA9f/HR
/hRyx7BzT7nO/wDCnvDP92f/AL+N/jR/wp7wz/dn/wC/jf410X9o3X/PX/x0f4Uf2jdf89f/AB0f
4Ucsewc0+5zv/CnvDP8Adn/7+N/jR/wp7wz/AHZ/+/jf410X9o3X/PX/AMdH+FH9o3X/AD1/8dH+
FHLHsHNPuc7/AMKe8M/3Z/8Av43+NH/CnvDP92f/AL+N/jXRf2jdf89f/HR/hR/aN1/z1/8AHR/h
Ryx7BzT7nO/8Ke8M/wB2f/v43+NH/CnvDP8Adn/7+N/jXRf2jdf89f8Ax0f4Uf2jdf8APX/x0f4U
csewc0+5zv8Awp7wz/dn/wC/jf40f8Ke8M/3Z/8Av43+NdF/aN1/z1/8dH+FH9o3X/PX/wAdH+FH
LHsHNPuc7/wp7wz/AHZ/+/jf40f8Ke8M/wB2f/v43+NdF/aN1/z1/wDHR/hR/aN1/wA9f/HR/hRy
x7BzT7nO/wDCnvDP92f/AL+N/jR/wp7wz/dn/wC/jf410X9o3X/PX/x0f4Uf2jdf89f/AB0f4Ucs
ewc0+5zv/CnvDP8Adn/7+N/jR/wp7wz/AHZ/+/jf410X9o3X/PX/AMdH+FH9o3X/AD1/8dH+FHLH
sHNPuc7/AMKe8M/3Z/8Av43+NH/CnvDP92f/AL+N/jXRf2jdf89f/HR/hR/aN1/z1/8AHR/hRyx7
BzT7nO/8Ke8M/wB2f/v43+NH/CnvDP8Adn/7+N/jXRf2jdf89f8Ax0f4Uf2jdf8APX/x0f4Ucsew
c0+5zv8Awp7wz/dn/wC/jf40f8Ke8M/3Z/8Av43+NdF/aN1/z1/8dH+FH9o3X/PX/wAdH+FHLHsH
NPuc7/wp7wz/AHZ/+/jf40f8Ke8M/wB2f/v43+NdF/aN1/z1/wDHR/hR/aN1/wA9f/HR/hRyx7Bz
T7nO/wDCnvDP92f/AL+N/jR/wp7wz/dn/wC/jf410X9o3X/PX/x0f4Uf2jdf89f/AB0f4Ucsewc0
+5zv/CnvDP8Adn/7+N/jR/wp7wz/AHZ/+/jf410X9o3X/PX/AMdH+FH9o3X/AD1/8dH+FHLHsHNP
uc7/AMKe8M/3Z/8Av43+NH/CnvDP92f/AL+N/jXRf2jdf89f/HR/hR/aN1/z1/8AHR/hRyx7BzT7
nO/8Ke8M/wB2f/v43+NH/CnvDP8Adn/7+N/jXRf2jdf89f8Ax0f4Uf2jdf8APX/x0f4Ucsewc0+5
zv8Awp7wz/dn/wC/jf40f8Ke8M/3Z/8Av43+NdF/aN1/z1/8dH+FH9o3X/PX/wAdH+FHLHsHNPuc
7/wp7wz/AHZ/+/jf40f8Ke8M/wB2f/v43+NdF/aN1/z1/wDHR/hR/aN1/wA9f/HR/hRyx7BzT7nO
/wDCnvDP92f/AL+N/jR/wp7wz/dn/wC/jf410X9o3X/PX/x0f4Uf2jdf89f/AB0f4Ucsewc0+5zv
/CnvDP8Adn/7+N/jR/wp7wz/AHZ/+/jf410X9o3X/PX/AMdH+FH9o3X/AD1/8dH+FHLHsHNPuc7/
AMKe8M/3Z/8Av43+NH/CnvDP92f/AL+N/jXRf2jdf89f/HR/hR/aN1/z1/8AHR/hRyx7BzT7nO/8
Ke8M/wB2f/v43+NH/CnvDP8Adn/7+N/jXRf2jdf89f8Ax0f4Uf2jdf8APX/x0f4Ucsewc0+5zv8A
wp7wz/dn/wC/jf40f8Ke8M/3Z/8Av43+NdF/aN1/z1/8dH+FH9o3X/PX/wAdH+FHLHsHNPuc7/wp
7wz/AHZ/+/jf40f8Ke8M/wB2f/v43+NdF/aN1/z1/wDHR/hR/aN1/wA9f/HR/hRyx7BzT7nO/wDC
nvDP92f/AL+N/jR/wp7wz/dn/wC/jf410X9o3X/PX/x0f4Uf2jdf89f/AB0f4Ucsewc0+5zv/Cnv
DP8Adn/7+N/jR/wp7wz/AHZ/+/jf410X9o3X/PX/AMdH+FH9o3X/AD1/8dH+FHLHsHNPuc7/AMKe
8M/3Z/8Av43+NH/CnvDP92f/AL+N/jXRf2jdf89f/HR/hR/aN1/z1/8AHR/hRyx7BzT7nO/8Ke8M
/wB2f/v43+NH/CnvDP8Adn/7+N/jXRf2jdf89f8Ax0f4Uf2jdf8APX/x0f4Ucsewc0+5zv8Awp7w
z/dn/wC/jf40f8Ke8M/3Z/8Av43+NdF/aN1/z1/8dH+FH9o3X/PX/wAdH+FHLHsHNPuc7/wp7wz/
AHZ/+/jf40f8Ke8M/wB2f/v43+NdF/aN1/z1/wDHR/hR/aN1/wA9f/HR/hRyx7BzT7nO/wDCnvDP
92f/AL+N/jR/wp7wz/dn/wC/jf410X9o3X/PX/x0f4Uf2jdf89f/AB0f4Ucsewc0+5zv/CnvDP8A
dn/7+N/jR/wp7wz/AHZ/+/jf410X9o3X/PX/AMdH+FH9o3X/AD1/8dH+FHLHsHNPuc7/AMKe8M/3
Z/8Av43+NH/CnvDP92f/AL+N/jXRf2jdf89f/HR/hR/aN1/z1/8AHR/hRyx7BzT7nO/8Ke8M/wB2
f/v43+NH/CnvDP8Adn/7+N/jXRf2jdf89f8Ax0f4Uf2jdf8APX/x0f4Ucsewc0+5zv8Awp7wz/dn
/wC/jf40f8Ke8M/3Z/8Av43+NdF/aN1/z1/8dH+FH9o3X/PX/wAdH+FHLHsHNPuc7/wp7wz/AHZ/
+/jf40f8Ke8M/wB2f/v43+NdF/aN1/z1/wDHR/hR/aN1/wA9f/HR/hRyx7BzT7nO/wDCnvDP92f/
AL+N/jR/wp7wz/dn/wC/jf410X9o3X/PX/x0f4Uf2jdf89f/AB0f4Ucsewc0+5zv/CnvDP8Adn/7
+N/jR/wp7wz/AHZ/+/jf410X9o3X/PX/AMdH+FH9o3X/AD1/8dH+FHLHsHNPuc7/AMKe8M/3Z/8A
v43+NH/CnvDP92f/AL+N/jXRf2jdf89f/HR/hR/aN1/z1/8AHR/hRyx7BzT7nO/8Ke8M/wB2f/v4
3+NH/CnvDP8Adn/7+N/jXRf2jdf89f8Ax0f4Uf2jdf8APX/x0f4Ucsewc0+5zv8Awp7wz/dn/wC/
jf40f8Ke8M/3Z/8Av43+NdF/aN1/z1/8dH+FH9o3X/PX/wAdH+FHLHsHNPuc7/wp7wz/AHZ/+/jf
40f8Ke8M/wB2f/v43+NdF/aN1/z1/wDHR/hR/aN1/wA9f/HR/hRyx7BzT7nO/wDCnvDP92f/AL+N
/jR/wp7wz/dn/wC/jf410X9o3X/PX/x0f4Uf2jdf89f/AB0f4Ucsewc0+5zv/CnvDP8Adn/7+N/j
R/wp7wz/AHZ/+/jf410X9o3X/PX/AMdH+FH9o3X/AD1/8dH+FHLHsHNPuc7/AMKe8M/3Z/8Av43+
NH/CnvDP92f/AL+N/jXRf2jdf89f/HR/hR/aN1/z1/8AHR/hRyx7BzT7nO/8Ke8M/wB2f/v43+NH
/CnvDP8Adn/7+N/jXRf2jdf89f8Ax0f4Uf2jdf8APX/x0f4Ucsewc0+5zv8Awp7wz/dn/wC/jf40
f8Ke8M/3Z/8Av43+NdF/aN1/z1/8dH+FH9o3X/PX/wAdH+FHLHsHNPuc7/wp7wz/AHZ/+/jf40f8
Ke8M/wB2f/v43+NdF/aN1/z1/wDHR/hR/aN1/wA9f/HR/hRyx7BzT7nO/wDCnvDP92f/AL+N/jR/
wp7wz/dn/wC/jf410X9o3X/PX/x0f4Uf2jdf89f/AB0f4Ucsewc0+5zv/CnvDP8Adn/7+N/jR/wp
7wz/AHZ/+/jf410X9o3X/PX/AMdH+FH9o3X/AD1/8dH+FHLHsHNPuc7/AMKe8M/3Z/8Av43+NH/C
nvDP92f/AL+N/jXRf2jdf89f/HR/hR/aN1/z1/8AHR/hRyx7BzT7nO/8Ke8M/wB2f/v43+NH/Cnv
DP8Adn/7+N/jXRf2jdf89f8Ax0f4Uf2jdf8APX/x0f4Ucsewc0+5zv8Awp7wz/dn/wC/jf40f8Ke
8M/3Z/8Av43+NdF/aN1/z1/8dH+FH9o3X/PX/wAdH+FHLHsHNPuc7/wp7wz/AHZ/+/jf40f8Ke8M
/wB2f/v43+NdF/aN1/z1/wDHR/hR/aN1/wA9f/HR/hRyx7BzT7nO/wDCnvDP92f/AL+N/jR/wp7w
z/dn/wC/jf410X9o3X/PX/x0f4Uf2jdf89f/AB0f4Ucsewc0+5zv/CnvDP8Adn/7+N/jR/wp7wz/
AHZ/+/jf410X9o3X/PX/AMdH+FH9o3X/AD1/8dH+FHLHsHNPuc7/AMKe8M/3Z/8Av43+NH/CnvDP
92f/AL+N/jXRf2jdf89f/HR/hR/aN1/z1/8AHR/hRyx7BzT7nO/8Ke8M/wB2f/v43+NH/CnvDP8A
dn/7+N/jXRf2jdf89f8Ax0f4Uf2jdf8APX/x0f4Ucsewc0+5zv8Awp7wz/dn/wC/jf40f8Ke8M/3
Z/8Av43+NdF/aN1/z1/8dH+FH9o3X/PX/wAdH+FHLHsHNPuc7/wp7wz/AHZ/+/jf40f8Ke8M/wB2
f/v43+NdF/aN1/z1/wDHR/hR/aN1/wA9f/HR/hRyx7BzT7nO/wDCnvDP92f/AL+N/jR/wp7wz/dn
/wC/jf410X9o3X/PX/x0f4Uf2jdf89f/AB0f4Ucsewc0+5zv/CnvDP8Adn/7+N/jR/wp7wz/AHZ/
+/jf410X9o3X/PX/AMdH+FH9o3X/AD1/8dH+FHLHsHNPuc7/AMKe8M/3Z/8Av43+NH/CnvDP92f/
AL+N/jXRf2jdf89f/HR/hR/aN1/z1/8AHR/hRyx7BzT7nO/8Ke8M/wB2f/v43+NH/CnvDP8Adn/7
+N/jXRf2jdf89f8Ax0f4Uf2jdf8APX/x0f4Ucsewc0+5zv8Awp7wz/dn/wC/jf40f8Ke8M/3Z/8A
v43+NdF/aN1/z1/8dH+FH9o3X/PX/wAdH+FHLHsHNPuc7/wp7wz/AHZ/+/jf40f8Ke8M/wB2f/v4
3+NdF/aN1/z1/wDHR/hR/aN1/wA9f/HR/hRyx7BzT7nO/wDCnvDP92f/AL+N/jR/wp7wz/dn/wC/
jf410X9o3X/PX/x0f4Uf2jdf89f/AB0f4Ucsewc0+5zv/CnvDP8Adn/7+N/jR/wp7wz/AHZ/+/jf
410X9o3X/PX/AMdH+FH9o3X/AD1/8dH+FHLHsHNPuc7/AMKe8M/3Z/8Av43+NH/CnvDP92f/AL+N
/jXRf2jdf89f/HR/hR/aN1/z1/8AHR/hRyx7BzT7nO/8Ke8M/wB2f/v43+NH/CnvDP8Adn/7+N/j
XRf2jdf89f8Ax0f4Uf2jdf8APX/x0f4Ucsewc0+5zv8Awp7wz/dn/wC/jf40f8Ke8M/3Z/8Av43+
NdF/aN1/z1/8dH+FH9o3X/PX/wAdH+FHLHsHNPuc7/wp7wz/AHZ/+/jf40f8Ke8M/wB2f/v43+Nd
F/aN1/z1/wDHR/hR/aN1/wA9f/HR/hRyx7BzT7nO/wDCnvDP92f/AL+N/jR/wp7wz/dn/wC/jf41
0X9o3X/PX/x0f4Uf2jdf89f/AB0f4Ucsewc0+5zv/CnvDP8Adn/7+N/jR/wp7wz/AHZ/+/jf410X
9o3X/PX/AMdH+FH9o3X/AD1/8dH+FHLHsHNPuc7/AMKe8M/3Z/8Av43+NH/CnvDP92f/AL+N/jXR
f2jdf89f/HR/hR/aN1/z1/8AHR/hRyx7BzT7nO/8Ke8M/wB2f/v43+NH/CnvDP8Adn/7+N/jXRf2
jdf89f8Ax0f4Uf2jdf8APX/x0f4Ucsewc0+5zv8Awp7wz/dn/wC/jf40f8Ke8M/3Z/8Av43+NdF/
aN1/z1/8dH+FH9o3X/PX/wAdH+FHLHsHNPuc7/wp7wz/AHZ/+/jf40f8Ke8M/wB2f/v43+NdF/aN
1/z1/wDHR/hR/aN1/wA9f/HR/hRyx7BzT7nO/wDCnvDP92f/AL+N/jR/wp7wz/dn/wC/jf410X9o
3X/PX/x0f4Uf2jdf89f/AB0f4Ucsewc0+5zv/CnvDP8Adn/7+N/jR/wp7wz/AHZ/+/jf410X9o3X
/PX/AMdH+FH9o3X/AD1/8dH+FHLHsHNPuc7/AMKe8M/3Z/8Av43+NH/CnvDP92f/AL+N/jXRf2jd
f89f/HR/hR/aN1/z1/8AHR/hRyx7BzT7nO/8Ke8M/wB2f/v43+NH/CnvDP8Adn/7+N/jXRf2jdf8
9f8Ax0f4Uf2jdf8APX/x0f4Ucsewc0+5zv8Awp7wz/dn/wC/jf40f8Ke8M/3Z/8Av43+NdF/aN1/
z1/8dH+FH9o3X/PX/wAdH+FHLHsHNPuc7/wp7wz/AHZ/+/jf40f8Ke8M/wB2f/v43+NdF/aN1/z1
/wDHR/hR/aN1/wA9f/HR/hRyx7BzT7nO/wDCnvDP92f/AL+N/jQPg94Zzytxj/rqf8a6L+0br/nr
/wCOj/CnJqF0zqvm9Tj7o/wo5Y9g5p9zxz4i/D+Hw2qahpXnPY5CTI/zGJj0bP8AdPTnocc8gDz2
vqu9jjuBNFOivFIpV1cZDKRggj0xXypWFWKT0OilNyVmFd/8IP8Akb5/+vNv/RkdcBXofweiLeKb
qXHC2pU/i6n+lTD4kVU+FnsOof69f93+pqpVi/Obgeyiqua6jjHUU3NGaQx1FNzRmgB1FNzRmgB1
FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzR
mgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1
FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzR
mgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1
FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzR
mgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1
FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzR
mgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1
FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzR
mgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1
FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1SQf6+P8A3h/Ooc1JAf8ASIv98fzp
gS65P9n0jUZ+R5dvI/HspNfL9fS3ir/kVtb/AOvKf/0Bq+aawrbo3obMK9S+C8YN9qsvdViUfjvP
9K8tr1X4Lf6/V/8Atj/KSop/Ei6vwM9KvTm6f2x/Kq9TXn/H2/4fyqCuo5RaKSikAtFJRQAtFJRQ
AtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJ
RQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAt
FJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQ
AtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJ
RQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAt
FJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQ
AtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJ
RQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAtFJRQAt
SQf8fEX++P51FU1qM3UY980wIfFX/Ira3/15T/8AoDV8019K+LGC+FdaJOB9inH5oa+aqwrbo3ob
MK9U+C/+v1f/ALY/ykryuvWfgvFhNWm7M0S/kG/+KqKfxIur8DPRLz/j7f8AD+VQVJdnN1Ifeoa6
TlHUU2igY6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOopt
FADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOopt
FADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOopt
FADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOopt
FADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOopt
FADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOopt
FADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOopt
FADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOopt
FADqKbRQA6im0UAOoptFADqKbRQA6im0UAOoptFADqKbRQA6im0UAOqxZf8AH3H+P8qq1Ysv+PuP
8f5GgRl+PpzB4I1aQHGYgn/fTBf618717/8AEn/kQNT/AO2X/o1K8ArCt8R0UPhCvZ/g2gGgXsnd
rpl/JU/xrxivafg7/wAi3df9fb/+gR0qXxDrfCddcHNxJ/vGo806f/j4k/3j/OmV0HMLmjNJRQMX
NGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigB
c0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKA
FzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkoo
AXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSi
gBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpK
KAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmk
ooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGa
SigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0Z
pKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzR
mkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXN
GaSigBc0ZpKKAFzRmkooAXNGaSigBc1Ysv8Aj7T8f5VWq1p4zdA+gNAmYXxJ/wCRA1P/ALZf+jUr
wCvfviUwHgHUgTyxiA9/3q14DWFb4joofCFe0fB7/kW7r/r7f/0COvF69u+EcPl+FJXx/rLl2/RR
/wCy0qXxDrfCdNOf9Ik/3z/Oo80srbpnPqxpma6DnHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc
0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM0
3NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmj
NNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZ
ozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB
2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0Zo
AdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NG
aAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNz
RmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozT
c0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM
03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdm
jNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAH
ZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmg
B2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2at6ef37f7h/mKpZq
5px/fv8A7h/mKEJnLfFibyvBoT/nrdRp+jN/SvDq9q+L/wDyKdr/ANfyf+i5K8Vrnq/EdNH4Qr3r
4YqF8EWZHVjIT/38cf0rwWve/hmf+KHsf+2n/o16dH4hVvhNItmjNNzRmtjAdmjNNzRmgB2aM03N
GaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNN
zRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZoz
Tc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2a
M03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAd
mjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaA
HZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRm
gB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0
ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03
NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjN
NzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZo
zTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2
aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoA
dmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGa
AHZq3px/ft/uH+Yqlmr2mj55D7AU0D2OQ+L/APyKdr/1/J/6LkrxWvafjA4HhazTub1SPwR/8a8W
rnq/EdFH4Qr3r4af8iPY/wDbT/0Y9eC1794Bj+z+B7Af9M2f82Lf1p0fiFW+EtUU3NGa2MR1FNzR
mgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1
FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzR
mgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1
FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzR
mgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1
FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzR
mgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1
FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzR
mgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1
FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzR
mgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1FNzRmgB1aGl9Zfw/
rWbmtHSj80n4f1poT2OD+MsxWz0iHPDySvj6BR/7NXkleq/Gf/mCf9t//adeVVzVPiZ00vgQV9De
GQE8F6eB/wA+UZ/8hg18819C+HD/AMUZYf8AXlH/AOixVUd2TW2QmaM0zNGa2MR+aM0zNGaAH5oz
TM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+a
M0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAf
mjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaA
H5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRm
gB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0
ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0z
NGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjN
MzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5o
zTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+
aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoA
fmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGa
AH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzR
mgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM
0ZoAfmtHST80n4f1rLzWrpP3WPq39KEJ7Hn3xn/5gn/bf/2nXlVep/GZ1Mmix5+ZRMxHsdn+Bryy
uep8TOml8CCvoPw4ceDbD/ryj/8ARYr58r6H02P7L4YtYsY2WyJj6KBVUt2TW2RWzRmmZozWpiPz
RmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD
80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQ
A/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM
0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZm
jNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmm
ZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80Z
pmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/N
GaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0AP
zRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNA
D80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZoz
QA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80Zpma
M0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZ
mjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRm
mZozQA/NGaZmjNAD81saOcxt/vH+QrEzW1opzG/1P9KaE9jy/wCMMpbxFYw9ktN35uw/9lrzqvQP
i/8A8jZa/wDXin/oySvP655/Ezqp/Cgr6NmwulELwAAAPxr5yr6LuD/xLG/D/wBCq6XUit0MzNGa
ZmjNaGQ/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD8
0ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA
/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0
APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmj
NAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZ
ozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80Zp
maM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NG
aZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APz
RmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD
80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQ
A/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM
0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZm
jNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmm
ZozQA/NGaZmjNAD80ZpmaM0APzW3of3H+p/pWDmt7RP9X9Qf501uKWx5Z8X/APkbLX/rxT/0ZJXn
9d78XJA/i+BR1SzRT/305/rXBVzT+JnTT+FBX0TcnGmN+H86+fbKLz7+2i/vyqv5kCvfr1tungeu
K0pdSKvQzM0ZqPNGasyJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPN
GaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0
ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGa
AJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0Zq
PNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJ
M0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPN
GaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0
ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGa
AJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0Zq
PNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJ
M0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPN
GaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0
ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGa
AJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM0ZqPNGaAJM10W
h82+fQf1Nczmum0A5tG/z3NVHcUtjxn4mymTx3fKc/u0iUf98Kf61yNdV8Sf+R/1P/tl/wCikrla
5pfEzqh8KL+hc+INNz0+1Rf+hivcdRP+gx/7w/ka8O0L/kYNN/6+ov8A0MV7dqJ/0GP/AHh/I1pT
2ZnV3RnZozUeaM1ZmSZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0
ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozU
eaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0AS
ZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUea
M0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZo
zUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0
ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozU
eaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0AS
ZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUea
M0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZo
zUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0
ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozU
eaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0AS
ZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZozUeaM0ASZrpvD/
APx6t+H8zXK5rq9AGLZvov8AWnHcmWx4t8Sf+R/1P/tl/wCikrla6f4hyrN481Rl6BkX8RGoP8q5
iueXxM6ofCi/of8AyMGm/wDX1F/6EK9r1I4sox/tD+RrxvwxH5viXT1xnEob8uf6V7BqzYiiX3Na
U9mZ1N0Z2aM1Huo3VRBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZoz
Ue6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR
7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Hu
o3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6j
dQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1
AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UA
SZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJ
mjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEma
M1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZoz
Ue6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR
7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Hu
o3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6j
dQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1
AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UA
SZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZrsNBH+gbvX
A/QVxe6u18PnOmD/AHv/AGUVUdyZ7HgXi2UzeMNYY9ReSr+TEf0rGrV8T/8AI2az/wBf0/8A6Mas
quZ7nVHZG74N/wCRrsc+r/8AoDV6pq5/1P8AwL+leVeDv+Rqsv8Agf8A6A1epawf9T/wL+la0/hM
qnxGfmjNR7qN1USSZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo
3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jd
QBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1A
EmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UAS
ZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJm
jNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM
1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozU
e6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7
qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo
3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jd
QBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1A
EmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UAS
ZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJm
jNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM
1Huo3UASZozUe6jdQBJmjNR7qN1AEmaM1Huo3UASZozUe6jdQBJmjNR7qN1AEma7fw9/yDP+Bf8A
sorhN1d5oAI09v8ArocfkKqO5E9j5+8T/wDI2az/ANf0/wD6MasqtHxBKJ/EmqSjGJLyVhj3cms6
uZ7nUtjc8HDPiqy+r/8AoDV6frDf6n/gX9K848DR7/Esbf3I2b+Q/rXoOrt++jX0XP61rD4TKfxF
HNGaZmjNMkfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRm
gB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0
ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0z
NGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjN
MzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5o
zTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+
aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoA
fmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGa
AH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzR
mgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM
0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0
zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmj
NMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5
ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5r0PRFxpcZ/vFj+uK85zXo+i86TB/wAC/wDQjVw3InsfM8sh
lleQ9XYsfxplFFcp1nVeAP8AkYZP+vc/+hLXb6uf9LT/AHB/M1w/gH/kYJP+uB/9CWu11Y/6Uv8A
uD+ZraHwmM/iKWaM03NGaYh2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNN
zRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZoz
Tc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2a
M03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAd
mjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaA
HZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRm
gB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0
ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03
NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjN
NzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZo
zTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2
aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoA
dmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGa
AHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAeOSBXpGh/wDIHg/4F/6Ea82j5lQerCvRdMk+
zeHklPOyN3/UmqgZ1Nj5pooormOs6nwED/b8h7eQf/QlrstWP+lr/uD+Zrlfh9HnULqTH3UUfnn/
AArpdUbN8w9AB+lax+Exl8RVzRmm5ozTEOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGa
bmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzR
mm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs
0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA
7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0
AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmj
NADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5
ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0Zp
uaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NG
abmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOz
Rmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNAD
s0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQ
A7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM
0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNAEsR/fJ/vCu91BjB4DvHXqunSOM
evlk15/Ef3yf7wr0DVv+Sf33/YLk/wDRRq47Mie6PnOiiiuY6jtfh7/r776J/wCzVu6kf9Pl/D+Q
rB+H3+vvvon/ALNW5qR/0+X8P5CtY/CYy+Ir5ozTM0ZpgPzRmmZozQA/NGaZmjNAD80ZpmaM0APz
RmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD
80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQ
A/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM
0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZm
jNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmm
ZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80Z
pmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/N
GaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0AP
zRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNA
D80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZoz
QA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80Zpma
M0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZ
mjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAE0PMyf7wr0DVv+
Sf33/YKk/wDRRrz625nSu98QyfZfh7fZOMaeY/zTb/WrjszOe6PniiiiuY6jtPh+D5t8e2E/9mra
1Fs38uPb+QrM8Api0upPWTb+QH+NXrxt15Mf9sitV8Ji/iZFmjNJRQAuaM0lFAC5ozSUUALmjNJR
QAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0l
FAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozS
UUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjN
JRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM
0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5o
zSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALm
jNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAu
aM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC
5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUA
LmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQ
AuaM0lFAC5ozSUUATWx/fr+P8q7b4h5h+H2oheyxL+HmIK4i2P79fx/lXb/En/kQNT/7Zf8Ao1Kt
fCyJfEjwCiiiuc6Tv/Af/ILuP+ux/wDQVqe6/wCPub/ro386r+A/+QXcf9dj/wCgrU90f9Lm/wCu
jfzrVfCjF/EyOikzRmgYtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0U
maM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALR
SZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAt
FJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC
0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0A
LRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQ
AtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjN
AC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM
0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZo
zQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJm
jNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0ALRSZozQAtFJmjNAC0UmaM0AT23+vX2zXcfEn/kQNT/
AO2X/o1K4mwTzLpU9eP1rsPifN5XgW7Tj97JGn/j4b/2WrXwszl8SPBqKKK5zpO/8CqRpU5PeYkf
kKkuTm6lPq5/nUngxAmgo399mP6kf0quzbmJ9TmtuiMftMKKSikMWikooAWikooAWikooAWikooA
WikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWiko
oAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWi
kooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooA
WikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWiko
oAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWi
kooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooA
WikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWiko
oAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooAWikooA0dDUPrNq
p6NKg/8AHhW58XmK+EbYDo16gP8A3w5/pWJoB/4nln/12T/0IVtfF/8A5FO1/wCv5P8A0XJVfYZm
/jR4rRRRWB0nc+CdWt5I10m4jCyjc0LgnDjqQffqfp9Oex+wW3/PL/x4/wCNeLo7xSLJGzI6kMrK
cEEdCDWr/wAJTrf/AEEZfyH+FaRnZamcoNu6PU/sFt/zy/8AHj/jR9gtv+eX/jx/xryz/hKdb/6C
Mv5D/Cj/AISnW/8AoIy/kP8ACnzon2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZf
yH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/w
lOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QR
l/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FH
Og9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7n
qf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+
eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8
aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf8
8v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP
+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/C
U63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQ
Rl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+F
H/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/
9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If
4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9n
Luep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C
2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/j
x/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsF
t/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8A
x4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeW
f8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/
ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/I
f4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU
63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX
8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6
D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep
/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55
f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo
+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy
/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/4
15Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JT
rf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBG
X8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf
8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0
EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/h
RzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu
56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb
/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH
/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3
/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDH
j/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/
wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A
0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/
hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTr
f/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfy
H+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoP
Zy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9
gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/
48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7
Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/
AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jX
ln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt
/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZf
yH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/w
lOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QR
l/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FH
Og9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7n
qf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+
eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8
aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf8
8v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP
+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/C
U63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQ
Rl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+F
H/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/
9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If
4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9n
Luep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C
2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/j
x/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsF
t/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8A
x4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeW
f8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/
ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/I
f4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU
63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX
8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6
D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep
/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55
f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo
+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy
/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/4
15Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JT
rf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBG
X8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf
8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0
EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/h
RzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu
56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb
/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH
/Gj7Bbf88v8Ax4/415Z/wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3
/PL/AMeP+NeWf8JTrf8A0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDH
j/jXln/CU63/ANBGX8h/hR/wlOt/9BGX8h/hRzoPZy7nqf2C2/55f+PH/Gj7Bbf88v8Ax4/415Z/
wlOt/wDQRl/If4Uf8JTrf/QRl/If4Uc6D2cu56n9gtv+eX/jx/xo+wW3/PL/AMeP+NeWf8JTrf8A
0EZfyH+FH/CU63/0EZfyH+FHOg9nLuep/YLb/nl/48f8aPsFt/zy/wDHj/jXln/CU63/ANBGX8h/
hR/wlOt/9BGX8h/hRzoPZy7nq8FrBb3EcyRDfG4dck9Qc+tVfircpd+C7OVDwb5MjPQ+XJxXmX/C
U63/ANBGX8h/hVe91vUtRtxBd3kksQYPsOMbgCAf1P50OorWBU3dMoUUUVkbH//ZDQplbmRzdHJl
YW0NCmVuZG9iag0KMTggMCBvYmoNCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0ltYWdlL1dpZHRo
IDE3MjEvSGVpZ2h0IDM2My9Db2xvclNwYWNlL0RldmljZUdyYXkvTWF0dGVbIDAgMCAwXSAvQml0
c1BlckNvbXBvbmVudCA4L0ludGVycG9sYXRlIGZhbHNlL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5n
dGggMjgyMT4+DQpzdHJlYW0NCnic7d1LcpvHGYZRLQVLwU7IbCRkFpKQWUPudmz4LsuWI9mObEuy
Atm6BAAJQgB/8CaqFFcTnDTb/zDdX9U5w2/0zp4CCtW4dQsAAID/g9/+HgAaVQrX6C0AtKoQrnHt
TQDw626Gq/YiAOjxB+ECIBThAiAW4QIgFuECIJRxKVx3AaAxj9frq0gJFwARCBcAoTwVLgAieSFc
AEQyEy4AIrkOl18VAhDCYn2aGjUSLgAiWK/PUqP2hAuACNbr89SoHeECIALhAiCU9foiNWpLuACI
YL1+nRo1FC4AIlivL1OjBsIFQATCBUAo6/WbwsMZm3B9CQBtuVt+8Um4AGhU15XCNUi389rjACDX
F65V7XEAkCuHa5huB7XHAUCuHK5t4QKgTeVw7abbi9rjACDXF65x7XEAkCuHaz/dfqg9DgBy5XCN
hAuANpXDNU63r2uPA4BcX7hqbwOAG8rh8uITAI0SLgBCES4AIrkvXABEIlwAhPJAuACI5JFwARDJ
WLgAiOS5cAEQiXABEMp0E66xcAEQwdEmXCPhAiCCo+5EuACIo+tOU6P2hAuACLruLDVqR7gAiKDr
zlOjtoQLgAiuwzUULgAi6LrXvx6uLwCgLb+E6zI1aiBcAETQdW8KD2cIFwCNEi4AQik/VXgVrvPa
4wAgVw7XQLgAaFM5XMN0W9UeBwC5cri20+2g9jgAyPWF60XtcQCQK4drN93+U3scAOTK4doXLgDa
VA7XKN2+rz0OAHJ94fq69jgAyJXDNRYuANpUDpcXnwBolHABEIpwARCKcAEQyT3hAiCSB33hugMA
bfnikXABEMlD4QIgkrFwARDJc+ECIJKpcAEQyXW4xsIFQARH3Ulq1Ei4AIig605To/aEC4AIuu4s
NWpHuACIQLgACKXrzlOjtoQLgAi67nVq1FC4AIig6y5TowbCBUAEwgVAKF33pvBwhnAB0Kjyi0+b
cH0OAI05LoZrkG5ntccBQO74uBSuYbqtao8DgFxfuA5qjwOAXDlc28IFQJvK4dpNt2e1xwFArhyu
/XT7sfY4AMiVwzVKtwe1xwFAri9c92qPA4BcOVxj4QKgTeVweTgDgEYJFwCh9IXrNgC0RrgAiOQr
4QIgEuECIJRvhAuASH4QLgAieSJcAETys3ABEIlwARDKZBOusXABEMF8E66RcAEQwfx4LVwAxHF8
fJIatVcK12cA0JZfwnWaGrUjXABEsFqdp0ZtCRcAEaxWZ6lRQ+ECIILV6kK4AIhjtXqdGjUQLgAi
WK3eFB7OEC4AGiVcAISyWpWeKhyk21ntcQCQ6wvXqvY4AMiVwzVMt9mnANCYcri2hQuANpXDtZtu
P9ceBwC5vnA9qj0OAHLlcO2n27e1xwFArhyukXAB0KZyuMbpdrf2OADI9YWr9jYAuKEcrrfCBUCb
hAuAUIQLgFD6wvUJADTmC+ECIJJ7y6VwARDHA+ECIBLhAiCUx8IFQCRPhQuASF4KFwCRXIdrXArX
xwDQmMPlcWrUSLgAiGC57FKj9oQLgAiWy5PUqB3hAiAC4QIglOXyLDVqS7gAiGC5vEiNGgoXABEs
l69TowbCBUAEwgVAKMvlm8LDGcIFQKPKLz5dhev0IwBozKtiuAbCBUCbXr0qhWuYbq9qjwOAXDlc
2+k2qT0OAHJ94fqp9jgAyJXDtZtuD2uPA4BcOVz7wgVAm8rhGqXbN7XHAUCuL1x3PgSAxpTDNRYu
ANpUDtfVrfY2ALhBuAAIRbgACEW4AIjktnABEIlwARDK3b5wfQAAbfnwW+ECIJLvFwvhAiCOJ8IF
QCTCBUAozzbhGgsXABFMN+EaCRcAEUwXS+ECII7FYpUatSdcAESwWKxTo3ZK4RoBQGMWi9PUqC3h
AiCC63ANhQuACBaLC+ECII7F4nVq1EC4AIhgsXhTeDhDuABolHABEEr5qcJBup3WHgcAuXK4hul2
VHscAOT6wvXyfQBoy6+Ea1u4AGjT0VEpXLtXf3VSexwA5Mrh2k+372uPA4BcOVyjdLtfexwA5PrC
dbv2OADIlcM1Fi4A2lQO19Wt9jYAuKEvXO8BQFuEC4BghAuAUIQLgEg+Fi4AIrkjXABEck+4AIhE
uAAI5TvhAiCSx33h+icANOapcAEQydP5PDVqLFwARPDf+SI1aiRcAEQwny9To/aEC4AI5vMuNWpH
uACIQLgACGU+X6dGbQkXABHM52epUUPhAiCC+fwiNWpQCte7ANAW4QIglvn8svBwhnAB0KjNwxlZ
uAbpdlJ7HADk+sI1rz0OAHLlcA3T7WXtcQCQK4drW7gAaFM5XLvp9qT2OADI9YXr37XHAUCuHK79
dLv7DgA05rAYrpFwAdCmw8NSuMbp9nHtcQCQ6wtX7W0AcEM5XG+FC4A2CRcAoQgXAKEIFwCRfCBc
AEQiXACEclu4AIjkq75w/QMAGvONcAEQyUPhAiAS4QIglPEmXGPhAiCCl5twjYQLgAheHi6EC4A4
Dg9fpUbtCRcAERweHqdG7QgXABEcHq5To7ZK4fo7ADTmOlxD4QIggoODU+ECII6Dg4vUqIFwARDB
wcFl4eEM4QKgUX3hOqk9DgByBwelpwoHwgVAm8rhGqbbvPY4AMiVw7Wdbi9qjwOAXF+4fqw9DgBy
5XDtptu3tccBQK4crn3hAqBN5XCN0u1O7XEAkCuHa5xuH/wNABojXACEUg7X1a32NgC4QbgACEW4
AAhFuAAIRbgAiOQ94QIgkk+EC4BIvhQuACIRLgBC+Vq4AIjkh75w/RUAGvNEuACI5Mlslho1Fi4A
Ing+m6dGjYQLgAhms0Vq1J5wARDBbLYSLgDiuA7XjnABEMFstk6N2hIuACKYzU5To4bCBUAEs9lF
atRAuACIQLgACGU2uyw8nCFcADRq83BGFq5Bup3UHgcAuXK4huk2rz0OAHJ94XpeexwA5Mrh2k63
Z38BgMaUw7Wbbo9qjwOAXDlc++l2v/Y4AMiVwzVKt9u1xwFAri9co9rjACBXDtdYuABoUzlcV7fa
2wDgBuECIBThAiAU4QIgFOECIJJ3hQuASIQLgFA+Ei4AIrkjXABEck+4AIjkO+ECIBLhAiCUJ5tw
jYULgAiezeZXD8GXwvVnAGiLcAEQy3S6SI3aEy4AIphOV6lRO8IFQATTaZcatSVcAERwHa6hcAEQ
wXR6KlwAxDGdXqRGDYQLgAim08vCwxnCBUCjyuEapNu69jgAyE2npacKr8I1rz0OAHLlcA3T7Vnt
cQCQK4drW7gAaFM5XLvp9rD2OADI9YXrfu1xAJArh2s/3T6rPQ4AcuVwjYQLgDaVwzVOt/drjwOA
XF+4am8DgBvK4fLiEwCNEi4AQhEuAEIRLgBCES4AInlHuACI5EPhAiCSz4ULgEiEC4BQ/iVcAETy
oC9cfwKAxvwoXABE8ngySY0aCxcAEfw0OUiNGgkXABFMJkepUXvCBUAEk8lSuACI4zpcO8IFQAST
SZcatSVcAEQwmZykRg2FC4AIJpPz1KiBcAEQgXABEMpkcll4OOMqXOva4wAgt3k4IwvXQLgAaFM5
XMN0m9ceBwC5cri20+1Z7XEAkOsL18Pa4wAgVw7Xbrrdqz0OAHLlcO0LFwBtKodrlG6f1h4HALly
uMbp9l7tcQCQEy4AQimHy4tPADRKuAAIpS9cEwBoj3ABEEopXE/fAkDTbpU+cgFAq24pFwCR5OFS
LgCadiNcv6m9CAB63AiXH2gA0LKb4fJlIQANK4Tr1h8BoFG/K4ULAEL4H94CKEINCmVuZHN0cmVh
bQ0KZW5kb2JqDQoxOSAwIG9iag0KPDwvRnVuY3Rpb25UeXBlIDAvU2l6ZVsgMjU2XSAvRGVjb2Rl
WyAwIDEgMCAxIDAgMV0gL1JhbmdlWyAwIDEgMCAxIDAgMV0gL0JpdHNQZXJTYW1wbGUgOC9Eb21h
aW5bIDAgMV0gL0VuY29kZVsgMCAyNTVdIC9PcmRlciAxL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5n
dGggNDgyPj4NCnN0cmVhbQ0KeJyNwmVXWgEYAOBfuFI23Ryl5KUuXLq7u7tBBRsFAxDFANe6bv/J
3nsuR4/7sLPnPPWL6/q/j69r49//8dfk6M7q7Z/48zsr+B/4s79+L8PTm9+IpRPi18khvjj8cvv4
c+Hm0SeYx3/MDyZzgw+5Q+L7bJ94le3hM73LTBef7r5LHxDfpvbhG5jce01M7L7Cd17GYfsFjLUv
YjtwHN2Go2hrFGmdw/DWWXgTnobgxkkQrg+Da8cBuHrkhysDH2weept9b6PvafQ8y133EjxwL+67
YH3PWdt11jqOasdebdsrO7Yy3LaWWtZiy1LcshQ2zfkNaMqtG7NrxsyqAaZX9KmmLtXQJZe1iSWo
iS9qYnV1tKaCkaoyXFGGyopQSR4sygNFmb8g8+elvhzmzWKejAS602JXCnUmUWdC5IgL7TGhLSaw
RQXWCN8S5ptDPHMIMQURY4Br8HMMPo7ex9Z52VoPS+tmaVxMtYuhdjJUjgWlfV5hg3S5lS6z0GRm
mtRMxUxUzEiRGChiA1msJ6O656h2TqSdE2rgM4H6KV+F5ylneYpZRDGDyGe4MviEI4WP2RgksSQk
lpjEFE8z0WkGOsUQTS1A4aN5KMDT+Q8hDfIeQCpE7lMgF96DZA78A4Rh2QoNCmVuZHN0cmVhbQ0K
ZW5kb2JqDQoyMCAwIG9iag0KPDwvUGF0dGVyblR5cGUgMi9TaGFkaW5nPDwvQ29sb3JTcGFjZS9E
ZXZpY2VSR0IvU2hhZGluZ1R5cGUgMi9Db29yZHNbIDM1NCAxMzIgMzU0IDc4XSAvRXh0ZW5kWyB0
cnVlIHRydWVdIC9GdW5jdGlvbiAxOSAwIFI+Pj4+DQplbmRvYmoNCjIxIDAgb2JqDQo8PC9UeXBl
L01hc2svUy9MdW1pbm9zaXR5L0cgMjIgMCBSL0JDIDIzIDAgUj4+DQplbmRvYmoNCjIyIDAgb2Jq
DQo8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9Gb3JtL0JCb3hbIDQ4IDc4IDY2MCAxMzJdIC9Hcm91
cCAyNCAwIFIvUmVzb3VyY2VzPDwvUGF0dGVybjw8L1AyNiAyNiAwIFI+Pj4+L0xlbmd0aCA0Mz4+
DQpzdHJlYW0NCi9QYXR0ZXJuIGNzIC9QMjYgc2NuDQo0OCA3OCA2MTIgNTQgcmUNCmYqDQoNCmVu
ZHN0cmVhbQ0KZW5kb2JqDQoyMyAwIG9iag0KWyAwIDAgMF0gDQplbmRvYmoNCjI0IDAgb2JqDQo8
PC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pg0KZW5kb2JqDQoyNSAwIG9iag0KPDwvRnVu
Y3Rpb25UeXBlIDAvU2l6ZVsgMjU2XSAvRGVjb2RlWyAwIDEgMCAxIDAgMV0gL1JhbmdlWyAwIDEg
MCAxIDAgMV0gL0JpdHNQZXJTYW1wbGUgOC9Eb21haW5bIDAgMV0gL0VuY29kZVsgMCAyNTVdIC9P
cmRlciAxL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTU4Pj4NCnN0cmVhbQ0KeJx9wYVOgmEA
htG7pUukRErpkhBQCYtUlLxBtmd7t+8fP5xzPNo4XLW/YGdne2Zj9W/4s1obfuXHsJKlLGQuM5ni
W77wKR94lwnGGGEob3jFCwboo4dndNFBGy08oYkG6qihigrKKKGIAvJ4xANyyEoGaaRwL0ncSQJx
iSEqEbmVsNxIyBCUgMFv5TN4rTxn3HZcFzivctg5AUDupZANCmVuZHN0cmVhbQ0KZW5kb2JqDQoy
NiAwIG9iag0KPDwvUGF0dGVyblR5cGUgMi9TaGFkaW5nPDwvQ29sb3JTcGFjZS9EZXZpY2VSR0Iv
U2hhZGluZ1R5cGUgMi9Db29yZHNbIDM1NCAxMzIgMzU0IDc4XSAvRXh0ZW5kWyB0cnVlIHRydWVd
IC9GdW5jdGlvbiAyNSAwIFI+Pj4+DQplbmRvYmoNCjI3IDAgb2JqDQo8PC9UeXBlL0V4dEdTdGF0
ZS9CTS9Ob3JtYWwvY2EgMS9TTWFzayAyMSAwIFI+Pg0KZW5kb2JqDQoyOCAwIG9iag0KPDwvVHlw
ZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvV2lkdGggMTE0Ni9IZWlnaHQgNDA2L0NvbG9yU3BhY2Uv
RGV2aWNlUkdCL0JpdHNQZXJDb21wb25lbnQgOC9GaWx0ZXIvRENURGVjb2RlL0ludGVycG9sYXRl
IHRydWUvU01hc2sgMjkgMCBSL0xlbmd0aCAyMDIyOT4+DQpzdHJlYW0NCv/Y/+AAEEpGSUYAAQEB
AHgAeAAA/+EAWkV4aWYAAE1NACoAAAAIAAUDAQAFAAAAAQAAAEoDAwABAAAAAQAAAABREAABAAAA
AQEAAABREQAEAAAAAQAAEnRREgAEAAAAAQAAEnQAAAAAAAGGoAAAsY//2wBDAAgGBgcGBQgHBwcJ
CQgKDBQNDAsLDBkSEw8UHRofHh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBD
AQkJCQwLDBgNDRgyIRwhMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy
MjIyMjIyMjL/wAARCAGWBHoDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcI
CQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAk
M2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqD
hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl
5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgEC
BAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcY
GRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOU
lZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3
+Pn6/9oADAMBAAIRAxEAPwDwO3gkurmK3hUNLK4RASBkk4HJ4H410f8AwrzxSf8AmGD/AMCYv/iq
xdH/AOQ3Yf8AXzH/AOhCvqEEjpWlOCluZVKjjsfPH/CvPFP/AECx/wCBMX/xVH/CvPFP/QLH/gTF
/wDFV9AS3kkchUBSB6imfb5f7qfka09lEz9tI8C/4V54p/6BY/8AAmL/AOKo/wCFeeKf+gWP/AmL
/wCKr337fL/dT8jR9vl/up+Ro9lEPbSPA/8AhXfin/oFj/wIi/8AiqP+Fd+Kv+gWP/AiL/4qvfPt
8v8AdT8jR9vl/up+Ro9lEPbSPA/+Fd+Kv+gWP/AiL/4qj/hXfir/AKBY/wDAiL/4qvfPt8v91PyN
H2+X+6n5Gj2UQ9tI8D/4V34q/wCgWP8AwIi/+Ko/4V34q/6BY/8AAiL/AOKr3z7fL/dT8jR9vl/u
p+Ro9lEPbSPA/wDhXfir/oFj/wACYv8A4qj/AIV34q/6BY/8CYv/AIqvfPt8v91PyNH2+X+6n5Gj
2UQ9tI8D/wCFd+Kv+gWP/AmL/wCKo/4V34q/6BY/8CYv/iq98+3y/wB1PyNH2+X+6n5Gj2UQ9tI8
D/4V34q/6BY/8CYv/iqP+Fd+Kv8AoFj/AMCYv/iq98+3y/3U/I0fb5f7qfkaPZRD20jwP/hXfir/
AKBY/wDAmL/4qj/hXfir/oFj/wACYv8A4qvfPt8v91PyNH2+X+6n5Gj2UQ9tI8D/AOFd+Kv+gWP/
AAJi/wDiqP8AhXfir/oFj/wJi/8Aiq98+3y/3U/I0fb5f7qfkaPZRD20jwP/AIV34q/6BY/8CYv/
AIqj/hXfir/oFj/wJi/+Kr3z7fL/AHU/I0fb5f7qfkaPZRD20jwP/hXfir/oFj/wJi/+Ko/4V34q
/wCgWP8AwJi/+Kr3z7fL/dT8jR9vl/up+Ro9lEPbSPA/+Fd+Kv8AoFj/AMCYv/iqP+Fd+Kv+gWP/
AAJi/wDiq98+3y/3U/I0fb5f7qfkaPZRD20jwP8A4V34q/6BY/8AAmL/AOKo/wCFd+Kv+gWP/AmL
/wCKr3z7fL/dT8jR9vl/up+Ro9lEPbSPA/8AhXfir/oFj/wJi/8AiqP+Fd+Kv+gWP/AmL/4qvfPt
8v8AdT8jR9vl/up+Ro9lEPbSPA/+Fd+Kv+gWP/AmL/4qj/hXfir/AKBY/wDAmL/4qvfPt8v91PyN
H2+X+6n5Gj2UQ9tI8D/4V34q/wCgWP8AwJi/+Ko/4V14q/6BY/8AAmL/AOKr3z7fL/dT8jR9vl/u
p+Ro9lEPbSPA/wDhXXir/oFj/wACYv8A4qj/AIV14q/6BY/8CYv/AIqvfPt8v91PyNH2+X+6n5Gj
2UQ9tI8D/wCFdeKv+gWP/AmL/wCKo/4V14q/6BY/8CYv/iq98+3y/wB1PyNH2+X+6n5Gj2UQ9tI8
D/4V14q/6BY/8CYv/iqP+FdeKv8AoFj/AMCYv/iq98+3y/3U/I0fb5f7qfkaPZRD20jwP/hXXir/
AKBY/wDAmL/4qj/hXXir/oFj/wACYv8A4qvfPt8v91PyNH2+X+6n5Gj2UQ9tI8D/AOFdeKv+gWP/
AAJi/wDiqP8AhXXir/oFj/wJi/8Aiq98+3y/3U/I0fb5f7qfkaPZRD20jwP/AIV14q/6BY/8CYv/
AIqj/hXXir/oFj/wJi/+Kr3z7fL/AHU/I0fb5f7qfkaPZRD20jwP/hXXir/oFj/wJi/+Ko/4V14q
/wCgWP8AwJi/+Kr3z7fL/dT8jR9vl/up+Ro9lEPbSPA/+FdeKv8AoFj/AMCYv/iqP+FdeKv+gWP/
AAJi/wDiq98+3y/3U/I0fb5f7qfkaPZRD20jwP8A4V14q/6BY/8AAmL/AOKo/wCFdeKv+gWP/AmL
/wCKr3z7fL/dT8jR9vl/up+Ro9lEPbSPA/8AhXXir/oFj/wJi/8AiqP+FdeKv+gWP/AmL/4qvfPt
8v8AdT8jR9vl/up+Ro9lEPbSPA/+FdeKv+gWP/AmL/4qj/hXXir/AKBY/wDAmL/4qvfPt8v91PyN
H2+X+6n5Gj2UQ9tI8D/4V14q/wCgWP8AwJi/+Ko/4V14q/6BY/8AAmL/AOKr3z7fL/dT8jR9vl/u
p+Ro9lEPbSPBP+FdeKv+gWP/AAJi/wDiqP8AhXXiv/oFj/wJi/8Aiq97+3y/3U/I0fb5f7qfkaPZ
RD20jwT/AIV14r/6BY/8CYv/AIqj/hXPiv8A6BY/8CYv/iq97+3y/wB1PyNH2+X+6n5Gj2UQ9tI8
E/4Vz4r/AOgWP/AmL/4qj/hXPiv/AKBY/wDAmL/4qve/t8v91PyNH2+X+6n5Gj2UQ9tI8E/4Vz4r
/wCgWP8AwJi/+Ko/4Vz4r/6BY/8AAmL/AOKr3v7fL/dT8jR9vl/up+Ro9lEPbSPBP+Fc+K/+gWP/
AAJi/wDiqP8AhXPiv/oFj/wJi/8Aiq97+3y/3U/I0fb5f7qfkaPZRD20jwT/AIVz4r/6BY/8CYv/
AIqj/hXPiv8A6BY/8CYv/iq97+3y/wB1PyNH2+X+6n5Gj2UQ9tI8E/4Vz4r/AOgWP/AmL/4qj/hX
Piv/AKBY/wDAmL/4qve/t8v91PyNH2+X+6n5Gj2UQ9tI8E/4Vz4r/wCgWP8AwJi/+Ko/4Vz4r/6B
Y/8AAmL/AOKr3v7fL/dT8jR9vl/up+Ro9lEPbSPBP+Fc+K/+gWP/AAJi/wDiqP8AhXPiv/oFj/wJ
i/8Aiq97+3y/3U/I0fb5f7qfkaPZRD20jwT/AIVz4r/6BY/8CYv/AIqj/hXPiv8A6BY/8CYv/iq9
7+3y/wB1PyNH2+X+6n5Gj2UQ9tI8E/4Vz4r/AOgWP/AmL/4qj/hXPiv/AKBY/wDAmL/4qve/t8v9
1PyNH2+X+6n5Gj2UQ9tI8E/4Vz4r/wCgWP8AwJi/+Ko/4Vz4r/6BY/8AAmL/AOKr3v7fL/dT8jR9
vl/up+Ro9lEPbSPBP+Fc+K/+gWP/AAJi/wDiqP8AhXPiv/oFj/wJi/8Aiq97+3y/3U/I0fb5f7qf
kaPZRD20jwT/AIVz4r/6BY/8CYv/AIqj/hXPiv8A6BY/8CYv/iq97+3y/wB1PyNH2+X+6n5Gj2UQ
9tI8E/4Vz4r/AOgWP/AmL/4qj/hXPiv/AKBY/wDAmL/4qve/t8v91PyNH2+X+6n5Gj2UQ9tI8E/4
Vz4r/wCgWP8AwJi/+Ko/4Vx4r/6BQ/8AAmL/AOKr3v7fL/dT8jR9vl/up+Ro9lEPbSPBP+FceK/+
gUP/AAJi/wDiqP8AhXHiv/oFD/wJi/8Aiq97+3y/3U/I0fb5f7qfkaPZRD20jwT/AIVx4r/6BQ/8
CYv/AIqj/hXHiv8A6BQ/8CYv/iq97+3y/wB1PyNH2+X+6n5Gj2UQ9tI8E/4Vx4r/AOgUP/AmL/4q
j/hXHiv/AKBQ/wDAmL/4qve/t8v91PyNH2+X+6n5Gj2UQ9tI8E/4Vx4r/wCgUP8AwJi/+Ko/4Vx4
r/6BQ/8AAmL/AOKr3v7fL/dT8jR9vl/up+Ro9lEPbSPBP+FceK/+gUP/AAJi/wDiqP8AhXHiv/oF
D/wJi/8Aiq97+3y/3U/I0fb5f7qfkaPZRD20jwT/AIVx4r/6BQ/8CYv/AIqj/hXHiv8A6BQ/8CYv
/iq97+3y/wB1PyNH2+X+6n5Gj2UQ9tI8E/4Vx4r/AOgUP/AmL/4qj/hXHiv/AKBQ/wDAmL/4qve/
t8v91PyNH2+X+6n5Gj2UQ9tI8E/4Vx4s/wCgUP8AwJi/+Ko/4Vx4s/6BQ/8AAmL/AOKr3v7fL/dT
8jR9vl/up+Ro9lEPbSPBf+FceLP+gUP/AAJi/wDiqP8AhXHiz/oFD/wJi/8Aiq96+3y/3U/I0fb5
f7qfkaPZRD20jwX/AIVx4s/6BQ/8CYv/AIqj/hXHiz/oFD/wJi/+Kr3r7fL/AHU/I0fb5f7qfkaP
ZRD20jwX/hXHiz/oFD/wJi/+Ko/4Vx4s/wCgUP8AwJi/+Kr3r7fL/dT8jR9vl/up+Ro9lEPbSPBf
+FceLP8AoFD/AMCYv/iqP+FceLP+gUP/AAJi/wDiq96+3y/3U/I0fb5f7qfkaPZRD20jwX/hXHiz
/oFD/wACYv8A4qj/AIVx4s/6BQ/8CYv/AIqvevt8v91PyNH2+X+6n5Gj2UQ9tI8F/wCFceLP+gUP
/AmL/wCKo/4Vx4s/6BQ/8CYv/iq96+3y/wB1PyNH2+X+6n5Gj2UQ9tI8F/4Vx4s/6BQ/8CYv/iqP
+FceLP8AoFD/AMCYv/iq96+3y/3U/I0fb5f7qfkaPZRD20jwX/hXHiz/AKBQ/wDAmL/4qj/hXHiz
/oFD/wACYv8A4qvevt8v91PyNH2+X+6n5Gj2UQ9tI8F/4Vx4s/6BQ/8AAmL/AOKo/wCFceLP+gUP
/AmL/wCKr3r7fL/dT8jR9vl/up+Ro9lEPbSPBf8AhXHiz/oFD/wJi/8AiqP+FceLP+gUP/AmL/4q
vevt8v8AdT8jR9vl/up+Ro9lEPbSPBf+FceLP+gUP/AmL/4qj/hXHiz/AKBQ/wDAmL/4qvevt8v9
1PyNH2+X+6n5Gj2UQ9tI8F/4Vv4s/wCgUP8AwJi/+Ko/4Vv4s/6BQ/8AAmL/AOLr3r7fL/dT8jR9
vl/up+Ro9lEPbSPBf+Fb+LP+gUP/AAJi/wDi6P8AhW/iz/oFD/wJi/8Ai696+3y/3U/I0fb5f7qf
kaPZRD20jwX/AIVv4s/6BQ/8CYv/AIqj/hW/iz/oFD/wJi/+Kr3r7fL/AHU/I0fb5f7qfkaPZRD2
0jwX/hW/iz/oFD/wJi/+Ko/4Vv4s/wCgUP8AwJi/+Kr3r7fL/dT8jR9vl/up+Ro9lEPbSPBf+Fb+
LP8AoFD/AMCYv/iqP+Fb+LP+gUP/AAJi/wDiq96+3y/3U/I0fb5f7qfkaPZRD20jwX/hW/iz/oFD
/wACYv8A4qj/AIVv4s/6BQ/8CYv/AIqvevt8v91PyNH2+X+6n5Gj2UQ9tI+ctb8L6z4dW3bVbP7O
txu8o+Yj7tuM/dJx1HWsivb/AIrKt34RhllUbonLpjjB3Kv8mNeIVlOPK7I2pycldl3R/wDkN2H/
AF8x/wDoQr6fr5g0f/kN2H/XzH/6EK+n60o7Myr7oo3H+vb8P5VFUtx/r2/D+VRVqYhRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHK/E3/AJEv8f8A2oleIV7f
8Tf+RL/H/wBqJXiFYVfiOmj8Jd0f/kN2H/XzH/6EK+nc18xaP/yG7D/r5j/9CFfTtXR2ZFfdFG4/
17fh/KoqluP9e34fyqKtTEKKKKQBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB
RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF
FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU
UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ
AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB
RRRQAUUUUAct8TP+RL/H/wBqJXiNe3fEz/kS/wAf/aiV4jWFX4jpo/CXdH/5Ddh/18x/+hCvpyvm
PR/+Q3Yf9fMf/oQr6cqqOzIr7oo3H+vb8P5VFUtx/r2/D+VRVsYhRRRSGFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBy/xL/wCRL/H/ANqJXiNe3fEv/kS/x/8AaiV4
jXPV+I6KPwl3R/8AkN2H/XzH/wChCvpuvmTR/wDkN2H/AF8x/wDoQr6bzV0dmRX3RQuf9e34fyqK
pbk/v2/D+VRZrUxCijNGaBhRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmj
NABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRm
jNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRR
mjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABR
RmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNAB
RRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNA
BRRmjNABRRmjNABRRmjNABRRmjNABRRmjNABRRmjNAHMfEr/AJEv8f8A2oleJV7b8Sv+RL/H/wBq
JXiVc9X4joo/CXdH/wCQ3Yf9fMf/AKEK+mc18zaP/wAhuw/6+Y//AEIV9MVdHZkV90Ubk/v2/D+V
RZqS5/17fh/Koq1MRc0ZpKKBi5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSU
UALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJ
RQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0
lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5oz
SUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmj
NJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAua
M0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5ozSUUALmjNJRQAuaM0lFAC5
ozSUUALmjNJRQBzXxJ/5Ev8AH/2oleJ17Z8SD/xRZ+v/ALUSvE656vxHRR+Eu6P/AMhqw/6+I/8A
0IV9L180aR/yGrD/AK+I/wD0IV9LVdHZkV90Ubk/6Q34fyqLNSXP/Hw34fyqGtTIdmjNNooAdmjN
NooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooA
dmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjN
NooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooA
dmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjN
NooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooA
dmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjN
NooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooAdmjNNooA
dmjNNooA5z4j/wDIln6/+1ErxSvaviP/AMiWfr/7USvFa56vxHRR+EuaR/yGrD/r4j/9CFfSua+a
tI/5DVh/18R/+hCvpSro7Mivuijcn/SG/D+VQ5qS5/4+G/D+VRVqZC5ozSUUgFzRmkooAXNGaSig
Bc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKK
AFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmko
oAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaS
igBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0Zp
KKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRm
kooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNG
aSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigDnfiKf+KLP1/8AaiV4tXtHxE/5
Etvr/wC1ErxesKvxHRR+EuaR/wAhqx/6+I//AEIV9JZr5t0j/kNWP/XxH/6EK+kM1dHZkVt0Ubk/
6Q34fyqHNSXJ/wBIb8P5VFmtDIXNGaTNGaBi5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM
0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozS
ZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJm
jNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM
0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQ
AuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC
5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALm
jNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM
0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0Ac/8Q/+RLb6/wDt
RK8Yr2b4hHPgtvr/AO1ErxmsKvxG9L4S5pP/ACGbH/r4j/8AQhX0dmvnHSf+QzY/9fEf/oQr6MzV
0tmRW3RRuT/pD/h/Koc1Jcn/AEh/w/lUOa0Mh2aM03NGaBjs0ZpuaM0AOzRmm5ozQA7NGabmjNAD
s0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQ
A7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM
0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabm
jNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm
5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0Z
puaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7N
GabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AO
zRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNA
Ds0ZpuaM0AOzRmm5ozQBhfEH/kS3+v8A7USvGq9k8fn/AIot/qP/AEYleN1hV+I3pfCXNJ/5DNj/
ANfEf/oQr6KzXzrpP/IYsf8Ar4j/APQhX0RmqpdSa26KN0f9If8AD+VQ5p90f9If8P5VDmtTIfmj
NMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5
ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB
+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0Zo
AfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNG
aAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMz
RmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozT
M0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM
0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfm
jNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAxfHx/wCKLf6j/wBGJXjl
ew+PDnwXJ9R/6MSvHqwq/Eb0vhLelf8AIYsf+viP/wBCFfQ+a+eNK/5DFl/18R/+hCvoTNVS2ZNb
dFG6P+kP+H8qhzT7o/6Q/wCH8qhzWhmPzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZm
jNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmm
ZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80Z
pmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/N
GaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0AP
zRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNA
D80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZoz
QA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80Zpma
M0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZ
mjNAD80ZpmaM0AY/js/8UXJ9R/6MSvH69f8AHJz4Ll+o/wDRiV5BWNTc3pfCW9K/5C9l/wBfEf8A
6EK+gs18+6V/yF7L/rvH/wChCvf81VLqRW3RQuj/AKS/4fyqHNPuj/pL/h/Koc1oZj80ZpmaM0AP
zRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNA
D80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZoz
QA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80Zpma
M0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZ
mjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRm
mZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80
ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/
NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0A
PzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAGV43OfBcv1H/AKMWvIq9c8anPgub
6j/0YteR1jU3N6Wxb0v/AJC9l/13T/0IV77n3rwLS/8AkLWX/XdP/QhXvWaql1IrdDPuj/pL/h/K
oc1JdH/SX/D+VQ5qyB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB
2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0Zo
AdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NG
aAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNz
RmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozT
c0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM
03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdm
jNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAH
ZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmg
DM8ZnPguf6j/ANGLXktes+MjnwZP9V/9GLXk1ZVNzalsWtL/AOQtZ/8AXdP/AEIV7xmvB9M/5C1n
/wBd0/8AQhXu2aql1Jq9DPuz/pL/AIfyqHNPuz/pL/h/Koc1ZmPzRmmZozQA/NGaZmjNAD80Zpma
M0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZ
mjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRm
mZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80
ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/
NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0A
PzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjN
AD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZo
zQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80Zpm
aM0APzRmmZozQA/NGaZmjNAD80ZpmaM0AZ/jA58GXH1X/wBGLXlFereLjnwZcfVf/Ri15TWVTc2p
7FrTP+QrZ/8AXdP/AEIV7nmvDNM/5Ctn/wBd0/8AQhXuGadMmr0M+7P+kv8Ah/Koc0+7P+lP+H8q
gzVkEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEm
aM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1Hmj
NAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM
1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNA
EmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1H
mjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEm
aM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1Hmj
NAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM
1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNAEmaM1HmjNA
EmaM1HmjNAFPxYf+KMufqv8A6MWvK69S8VHPgy5+q/8Aoxa8trKpua09i1pv/IVs/wDrun/oQr27
NeI6b/yFLT/rsn/oQr2vNVTJq9DOuz/pT/h/Koc0+7P+lP8Ah/Koc1ZA/NGaZmjNAx+aM0zNGaAH
5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmg
B+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0Z
oAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zN
GaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNM
zRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5oz
TM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+a
M0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAf
mjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAfmjNMzRmgB+aM0zNGaA
H5ozTM0ZoAfmjNMzRmgB+aM0zNGaAH5ozTM0ZoAq+KDnwZdfVf8A0YteXV6f4mOfBt39U/8ARi15
hWVTc0p7FnTf+Qpaf9dk/wDQhXtOa8W07/kKWn/XZP8A0IV7Pmqpk1ehm3h/0p/w/lUGalvD/pT/
AIfyqDNUSOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQ
A7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM
0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabm
jNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm
5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0Z
puaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7N
GabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AO
zRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNA
Ds0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AV/Epz4Nu
/qn/AKMWvMq9M8RnPg28+qf+jFrzOs57mlPYs6d/yE7T/rsn/oQr2TNeN6d/yE7T/rsn/oQr2LNV
TFU3Rm3h/wBKf8P5VBmpbw/6U/4fyqDNUQh2aM03NGaBjs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0
ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7
NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0A
OzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjN
ADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5o
zQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0Zpu
aM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGa
bmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzR
mm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs
0ZpuaM0AOzRmm5ozQBF4hP8AxRt59U/9GLXmlek+IDnwbe/VP/Rgrzas57mlPYs6d/yE7T/rsn/o
Qr2HNePaf/yErX/rsn8xXr2aqmTUM28P+lP+H8qgzUl4f9Kf8P5VBmmSPzRmmZozQA/NGaZmjNAD
80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQ
A/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM
0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZm
jNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmm
ZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80Z
pmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/N
GaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0AP
zRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0APzRmmZozQA/NGaZmjNA
D80ZpmaM0APzRmmZozQA/NGaZmjNAD80ZpmaM0AM1858G3v1T/0YK83r0fXT/wAUdffVP/Rgrzio
nuaQ2LGn/wDIStf+uyfzFeu5ryLT/wDkJWv/AF2T+Yr1vNOmTUMy8P8ApT/h/KoM1LeH/Sn/AA/l
UGaokdmjNNzRmgY7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NG
abmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOz
Rmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNAD
s0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQ
A7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM
0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabm
jNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm
5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0Z
puaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AOzRmm5ozQA7NGabmjNADs0ZpuaM0AJrZ/4o6++sf/
AKMFec16LrX/ACJ19/2z/wDRgrzqonuXDYsaf/yErX/rsn8xXrVeS2H/ACEbX/rsn8xXrOadMmoZ
d4f9Kf8AD+VV81NeH/S3/D+VQZqhC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0AL
mjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAua
M0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5oz
SZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJ
mjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0ma
M0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZoz
QAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNA
C5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0AL
mjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNAC5ozSZozQAuaM0maM0ALmjNJmjNABrP/ACJ1/wD9
s/8A0YK87r0PWDnwdf8A/bP/ANGCvPKie5cNixYf8hG1/wCuyfzFer15RYf8hG1/66p/MV6tmnTJ
qGXef8fT/h/KoKmvD/pT/h/KoM1QkLRSZozSAWikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTNGaAF
opM0ZoAWikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTNGaAFopM0ZoA
WikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTNGaAFopM0ZoAWikzRmg
BaKTNGaAFopM0ZoAWikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTNGa
AFopM0ZoAWikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTNGaAFopM0Z
oAWikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTNGaAFopM0ZoAWikzR
mgBaKTNGaAFopM0ZoAWikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTNGaAFopM0ZoAWikzRmgBaKTN
GaAFopM0ZoAWikzRmgBaKTNGaADV/wDkTtQ/7Z/+jBXnteg6v/yJ+of9s/8A0YK8+qZ7lw2LFh/y
EbX/AK6p/MV6pmvK7D/kI2v/AF1T+Yr1PNOAqhl3h/0p/wAP5VBmprz/AI+n/D+VQVRKFzRmkopD
FzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkoo
AXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSi
gBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpK
KAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmk
ooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGa
SigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0Z
pKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigBc0ZpKKAFzRmkooAXNGaSigB2rf8ifqH/b
P/0YK8+r0DVf+RP1D/tn/wCjBXn9TPcqGzLFh/yEbb/rqn8xXqWa8u05S2p2ijqZkH/jwr1DNOAp
mXeH/Sn/AA/lUGatXUUj3Lsq5Bx39qh8iX+7+oqiSPNGak8iX+7+oo8iX+7+opAR5ozUnkS/3f1F
HkS/3f1FAEeaM1J5Ev8Ad/UUeRL/AHf1FAEeaM1J5Ev939RR5Ev939RQBHmjNSeRL/d/UUeRL/d/
UUAR5ozUnkS/3f1FHkS/3f1FAEeaM1J5Ev8Ad/UUeRL/AHf1FAEeaM1J5Ev939RR5Ev939RQBHmj
NSeRL/d/UUeRL/d/UUAR5ozUnkS/3f1FHkS/3f1FAEeaM1J5Ev8Ad/UUeRL/AHf1FAEeaM1J5Ev9
39RR5Ev939RQBHmjNSeRL/d/UUeRL/d/UUAR5ozUnkS/3f1FHkS/3f1FAEeaM1J5Ev8Ad/UUeRL/
AHf1FAEeaM1J5Ev939RR5Ev939RQBHmjNSeRL/d/UUeRL/d/UUAR5ozUnkS/3f1FHkS/3f1FAEea
M1J5Ev8Ad/UUeRL/AHf1FAEeaM1J5Ev939RR5Ev939RQBHmjNSeRL/d/UUeRL/d/UUAR5ozUnkS/
3f1FHkS/3f1FAEeaM1J5Ev8Ad/UUeRL/AHf1FAEeaM1J5Ev939RR5Ev939RQBHmjNSeRL/d/UUeR
L/d/UUAR5ozUnkS/3f1FHkS/3f1FAEeaM1J5Ev8Ad/UUeRL/AHf1FAEeaM1J5Ev939RR5Ev939RQ
BHmjNSeRL/d/UUeRL/d/UUAR5ozUnkS/3f1FHkS/3f1FAEeaM1J5Ev8Ad/UUeRL/AHf1FAEeaM1J
5Ev939RR5Ev939RQBHmjNSeRL/d/UUeRL/d/UUAR5ozUnkS/3f1FHkS/3f1FAEeaM1J5Ev8Ad/UU
eRL/AHf1FAEeaM1J5Ev939RR5Ev939RQBHmjNSeRL/d/UUeRL/d/UUAR5ozUnkS/3f1FHkS/3f1F
AEeaM1J5Ev8Ad/UUeRL/AHf1FAEeaM1J5Ev939RR5Ev939RQBHmjNSeRL/d/UUeRL/d/UUAR5ozU
nkS/3f1FHkS/3f1FAEeaM1J5Ev8Ad/UUeRL/AHf1FAEeaM1J5Ev939RR5Ev939RQBHmjNSeRL/d/
UUeRL/d/UUAR5ozUnkS/3f1FHkS/3f1FAEeaM1J5Ev8Ad/UUeRL/AHf1FAEeaM1J5Ev939RR5Ev9
39RQBHmjNSeRL/d/UUeRL/d/UUAR5ozUnkS/3f1FHkS/3f1FAEeaM1J5Ev8Ad/UUeRL/AHf1FAEe
aM1J5Ev939RR5Ev939RQBHmjNSeRL/d/UUeRL/d/UUAR5ozUnkS/3f1FHkS/3f1FAEeaM1J5Ev8A
d/UUeRL/AHf1FAEeaM1J5Ev939RR5Ev939RQBHmjNSeRL/d/UUeRL/d/UUAR5ozUnkS/3f1FHkS/
3f1FAEeaM1J5Ev8Ad/UUeRL/AHf1FAEeaM1J5Ev939RR5Ev939RQBHmjNSeRL/d/UUeRL/d/UUAR
5ozUnkS/3f1FHkS/3f1FAEeaM1J5Ev8Ad/UUeRL/AHf1FAEeaM1J5Ev939RR5Ev939RQBHmjNSeR
L/d/UUeRL/d/UUAR5ozUnkS/3f1FHkS/3f1FAEeaM1J5Ev8Ad/UUeRL/AHf1FAEeaM1J5Ev939RR
5Ev939RQBHmjNSeRL/d/UUeRL/d/UUAN1X/kT9R/7Z/+jBXn9egaspXwjqIYYP7v/wBGCvP6me5c
NgqaG6uLdSsM8sYJyQjkZ/KiioLLo8QaoAB9q6f7C/4Uf8JDqn/P1/5DX/Ciindisg/4SHVP+fr/
AMhr/hR/wkOqf8/X/kNf8KKKLsLIP+Eh1T/n6/8AIa/4Uf8ACQ6p/wA/X/kNf8KKKLsLIP8AhIdU
/wCfr/yGv+FH/CQ6p/z9f+Q1/wAKKKLsLIP+Eh1T/n6/8hr/AIUf8JDqn/P1/wCQ1/wooouwsg/4
SHVP+fr/AMhr/hR/wkOqf8/X/kNf8KKKLsLIP+Eh1T/n6/8AIa/4Uf8ACQ6p/wA/X/kNf8KKKLsL
IP8AhIdU/wCfr/yGv+FH/CQ6p/z9f+Q1/wAKKKLsLIP+Eh1T/n6/8hr/AIUf8JDqn/P1/wCQ1/wo
oouwsg/4SHVP+fr/AMhr/hR/wkOqf8/X/kNf8KKKLsLIP+Eh1T/n6/8AIa/4Uf8ACQ6p/wA/X/kN
f8KKKLsLIP8AhIdU/wCfr/yGv+FH/CQ6p/z9f+Q1/wAKKKLsLIP+Eh1T/n6/8hr/AIUf8JDqn/P1
/wCQ1/wooouwsg/4SHVP+fr/AMhr/hR/wkOqf8/X/kNf8KKKLsLIP+Eh1T/n6/8AIa/4Uf8ACQ6p
/wA/X/kNf8KKKLsLIP8AhIdU/wCfr/yGv+FH/CQ6p/z9f+Q1/wAKKKLsLIP+Eh1T/n6/8hr/AIUf
8JDqn/P1/wCQ1/wooouwsg/4SHVP+fr/AMhr/hR/wkOqf8/X/kNf8KKKLsLIP+Eh1T/n6/8AIa/4
Uf8ACQ6p/wA/X/kNf8KKKLsLIP8AhIdU/wCfr/yGv+FH/CQ6p/z9f+Q1/wAKKKLsLIP+Eh1T/n6/
8hr/AIUf8JDqn/P1/wCQ1/wooouwsg/4SHVP+fr/AMhr/hR/wkOqf8/X/kNf8KKKLsLIP+Eh1T/n
6/8AIa/4Uf8ACQ6p/wA/X/kNf8KKKLsLIP8AhIdU/wCfr/yGv+FH/CQ6p/z9f+Q1/wAKKKLsLIP+
Eh1T/n6/8hr/AIUf8JDqn/P1/wCQ1/wooouwsg/4SHVP+fr/AMhr/hR/wkOqf8/X/kNf8KKKLsLI
P+Eh1T/n6/8AIa/4Uf8ACQ6p/wA/X/kNf8KKKLsLIP8AhIdU/wCfr/yGv+FH/CQ6p/z9f+Q1/wAK
KKLsLIP+Eh1T/n6/8hr/AIUf8JDqn/P1/wCQ1/wooouwsg/4SHVP+fr/AMhr/hR/wkOqf8/X/kNf
8KKKLsLIP+Eh1T/n6/8AIa/4Uf8ACQ6p/wA/X/kNf8KKKLsLIP8AhIdU/wCfr/yGv+FH/CQ6p/z9
f+Q1/wAKKKLsLIP+Eh1T/n6/8hr/AIUf8JDqn/P1/wCQ1/wooouwsg/4SHVP+fr/AMhr/hR/wkOq
f8/X/kNf8KKKLsLIP+Eh1T/n6/8AIa/4Uf8ACQ6p/wA/X/kNf8KKKLsLIP8AhIdU/wCfr/yGv+FH
/CQ6p/z9f+Q1/wAKKKLsLIP+Eh1T/n6/8hr/AIUf8JDqn/P1/wCQ1/wooouwsg/4SHVP+fr/AMhr
/hR/wkOqf8/X/kNf8KKKLsLIP+Eh1T/n6/8AIa/4Uf8ACQ6p/wA/X/kNf8KKKLsLIP8AhIdU/wCf
r/yGv+FH/CQ6p/z9f+Q1/wAKKKLsLIP+Eh1T/n6/8hr/AIUf8JDqn/P1/wCQ1/wooouwsg/4SHVP
+fr/AMhr/hR/wkOqf8/X/kNf8KKKLsLIP+Eh1T/n6/8AIa/4Uf8ACQ6p/wA/X/kNf8KKKLsLIP8A
hIdU/wCfr/yGv+FH/CQ6p/z9f+Q1/wAKKKLsLIP+Eh1T/n6/8hr/AIUf8JDqn/P1/wCQ1/wooouw
sg/4SHVP+fr/AMhr/hR/wkOqf8/X/kNf8KKKLsLIP+Eh1T/n6/8AIa/4Uf8ACQ6p/wA/X/kNf8KK
KLsLIP8AhIdU/wCfr/yGv+FH/CQ6p/z9f+Q1/wAKKKLsLIP+Eh1T/n6/8hr/AIUf8JDqn/P1/wCQ
1/wooouwsg/4SHVP+fr/AMhr/hR/wkOqf8/X/kNf8KKKLsLIP+Eh1T/n6/8AIa/4Uf8ACQ6p/wA/
X/kNf8KKKLsLIP8AhIdU/wCfr/yGv+FH/CQ6p/z9f+Q1/wAKKKLsLIP+Eh1T/n6/8hr/AIUf8JDq
n/P1/wCQ1/wooouwsg/4SHVP+fr/AMhr/hR/wkOqf8/X/kNf8KKKLsLIP+Eh1T/n6/8AIa/4Uf8A
CQ6p/wA/X/kNf8KKKLsLIP8AhIdU/wCfr/yGv+FH/CQ6p/z9f+Q1/wAKKKLsLIP+Eh1T/n6/8hr/
AIUf8JDqn/P1/wCQ1/wooouwsg/4SHVP+fr/AMhr/hR/wkOqf8/X/kNf8KKKLsLIP+Eh1T/n6/8A
Ia/4Uf8ACQ6p/wA/X/kNf8KKKLsLIP8AhIdU/wCfr/yGv+FH/CQ6p/z9f+Q1/wAKKKLsLIP+Eh1T
/n6/8hr/AIUf8JDqn/P1/wCQ1/wooouwsg/4SHVP+fr/AMhr/hR/wkOqf8/X/kNf8KKKLsLIP+Eh
1T/n6/8AIa/4Uf8ACQ6p/wA/X/kNf8KKKLsLIP8AhIdU/wCfr/yGv+FH/CQ6p/z9f+Q1/wAKKKLs
LIP+Eh1T/n6/8hr/AIUf8JDqn/P1/wCQ1/wooouwsg/4SHVP+fr/AMhr/hR/wkOqf8/X/kNf8KKK
LsLIP+Eh1T/n6/8AIa/4Uf8ACQ6p/wA/X/kNf8KKKLsLIP8AhIdU/wCfr/yGv+FH/CQ6p/z9f+Q1
/wAKKKLsLIP+Eh1T/n6/8hr/AIUf8JDqn/P1/wCQ1/wooouwsg/4SHVP+fr/AMhr/hR/wkOqf8/X
/kNf8KKKLsLIjn1rUbm3e3muC0UmNy7FGcHI6D1AqhRRSGf/2Q0KZW5kc3RyZWFtDQplbmRvYmoN
CjI5IDAgb2JqDQo8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9JbWFnZS9XaWR0aCAxMTQ2L0hlaWdo
dCA0MDYvQ29sb3JTcGFjZS9EZXZpY2VHcmF5L01hdHRlWyAwIDAgMF0gL0JpdHNQZXJDb21wb25l
bnQgOC9JbnRlcnBvbGF0ZSBmYWxzZS9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDE0MTg+Pg0K
c3RyZWFtDQp4nO3Wx00dUBQAUTpzra7BOAeccwc4xw84hzWWl0i85Z0vpHOKGM3ODgAAAAAAAJwp
xwAF5QF655QH6CkP0FMeoLd3enmeAww5/HtiepQHCCgP0FMeoKc8QE95gJ7yAD3lAXrKA/SUB+gp
D9BTHqCnPEBPeYCe8gA95QF6ygP0lAfoKQ/QUx6gpzxAb12eZwBDDpQHyB38UR6gpjxAT3mAnvIA
PeUBesoD9JQH6CkP0FMeoKc8QE95gJ7yAD3lAXrKA/SUB+gpD9BTHqCnPEBPeYCe8gA95QF6ygP0
lAfoKQ/QUx6gpzxAT3mAnvIAPeUBesoD9NbleQowRHmAnvIAPeUBesoD9JQH6CkP0FMeoKc8QE95
gJ7yAD3lAXrKA/SUB+gpD9BTHqCnPEBPeYCe8gA95QF6ygP0lAforcvzBGCI8gA95QF6ygP0lAfo
KQ/QUx6gpzxAT3mAnvIAPeUBesoD9JQH6CkP0FMeoKc8QE95gN66PI8Bhmx+Kw9QUx6gpzxAT3mA
nvIAPeUBesoD9JQH6CkP0FMeoKc8QE95gJ7yAL11eR4BDFEeoKc8QE95gJ7yAD3lAXrKA/SUB+gp
D9BTHqCnPEBPeYCe8gC9dXkeAsxQHmALPv9SHqCmPEBPeYCe8gA95QF6ygP0lAfoKQ/QUx6gty7P
A4AhygP0lAfoKQ/QUx6gpzxAT3mAnvIAPeUBesoD9JQH6CkP0FMeoLcuz32AIZ9+Kg9QUx6gpzxA
T3mAnvIAPeUBesoD9JQH6K3Lcw9giPIAPeUBesoD9JQH6CkP0FMeoKc8QE95gJ7yAD3lAXrr8twF
GPLxh/IANeUBesoD9JQH6CkP0FMeoKc8QE95gN66PHcAhnxQHiCnPEBPeYCe8gA95QF6ygP0lAfo
KQ/QW5fnNsAQ5QF6778rD1BTHqCnPEBPeYCe8gA95QF6ygP01uXZA5ihPMAWKA/QUx6gpzxAT3mA
nvIAPeUBesoD9JQH6CkP0FuX5xbAEOUBeu++KQ9QUx6gpzxAT3mAnvIAPeUBesoD9NbluQkwQ3mA
LXirPEBOeYCe8gA95QF6ygP0lAfoKQ/QUx6gty7PDYAhb74qD1BTHqCnPEBPeYCe8gA95QF6ygP0
lAfoKQ/QW5fnOsAM5QG2QHmAnvIAPeUBesoD9JQH6CkP0FMeoKc8QG9dnmsAQ15/UR6gpjxAT3mA
nvIAPeUBesoD9JQH6CkP0FMeoKc8QE95gN66PFcBhigP0FMeoKc8QE95gJ7yAD3lAXrKA/SUB+gp
D9BTHqC3Ls8VgCGvjpQHqCkP0FMeoKc8QE95gJ7yAD3lAXrKA/SUB+gpD9BTHqCnPEBPeYDeujyX
AYYoD9BTHqCnPEBPeYCe8gA95QF6ygP0lAfoKQ/QUx6gpzxAT3mA3ro8lwBGKA+wDS8PlQeoKQ/Q
Ux6gpzxAT3mAnvIAPeUBesoD9JQH6CkP0FMeoKc8QE95gJ7yAD3lAXrr8lwEmKE8wBYoD9BTHqCn
PEBPeYCe8gA95QF6ygP0lAfoKQ/QUx6gpzxAT3mAnvIAPeUBesoD9JQH6CkP0FMeoKc8QE95gN66
PLsAQ14cKA9QUx6gpzxAT3mAnvIAPeUBesoD9JQH6CkP0FMeoKc8QE95gJ7yAD3lAXrKA/SUB+gp
D9BTHqCnPEBPeYCe8gA95QF6ygP0lAfoKQ/QUx6gpzxAT3mAnvIAPeUBesoD9NbluQAwY3dfeYDc
/kZ5gJryAD3lAXrKA/SUB+gpD9BTHqCnPEBPeYCe8gA95QF6ygP0lAfoKQ/QUx6gpzxAT3mAnvIA
PeUBesoD9JQH6CkP0FMeoKc8QG9dng3AmFV5jgDGnCjPf+ePAcbtnEJ+gFmnlQcAAACAs+kfpG8Q
rA0KZW5kc3RyZWFtDQplbmRvYmoNCjMwIDAgb2JqDQo8PC9GdW5jdGlvblR5cGUgMC9TaXplWyA1
MTJdIC9EZWNvZGVbIDAgMSAwIDEgMCAxXSAvUmFuZ2VbIDAgMSAwIDEgMCAxXSAvQml0c1BlclNh
bXBsZSA4L0RvbWFpblsgMCAxXSAvRW5jb2RlWyAwIDUxMV0gL09yZGVyIDEvRmlsdGVyL0ZsYXRl
RGVjb2RlL0xlbmd0aCA4NTA+Pg0Kc3RyZWFtDQp4nJWU5zubYRhH/0KrulvEliAiNkmERKwIIgRB
xGoRe+89W1106/pPeu48b40PPvS6zmfyPvfvnKiErChBH5Woj77GEJ1kiBGyY3RCrJATmyzECblx
KWCEe6mQJ6SZ4iEd8u9DhlnILHgQ4WFWITzSFwmGYnicXQJPckojlD3NhfJnxgp4nmd5brIkmKwJ
JltCvi3RXJloticVQJWusEpXVJ1c5EgudqQUO1NKalJLXZBWVptWXpcOFfUZlgbItDZmWd1ZtiZ9
pUdv9xjszYaqluxqaM1xeHOcbblOn7HGZ3S157k68mr9pjq/qb4zv77L3NBtbgwUgLunsKm30NNX
BM3B4pb+kpZQSetAqXegzDtY1jZU7huGivaRio4XFv9Li3/U2jlq7RqzdY1XdocrA2F7YMLeM1nV
OwXVfdOO4IwjOOvsn3WG5mpC8zUD867BBdfgYu3QUu3wUt3wct3ISj28WG14uQaNo+uNoxvusQ33
+GbT+FZTeMsT3vZMwE7z5C60TO1B6/R+6/SBdwYOvbOHbXNH4Js79s3DSfsCnLYvnnYsvupYeu1X
LJ91wsobYfVtl/Cuew3eC+vvA+sfAhtw3gObcAG9W/BR2P7Yt/1JY+dzUONLcFfoh72vV4T2voX2
r/gOAweKS43Dy0HhxzVHwtDRz1scK37B8E1OFL/vYgRO//wfd/+1CJH/eOM3DGlEfuHtn62+5dbX
HconX39+5DXUy1w/1N63m2/Yv6u9rTxy5LV59qsTcA7tLlsX6lJyso3zgPCBU3JQ7bJr7zg05+bo
2vWXzxiDWgXzYCRMRQazcMJ4ZEJzx2pRTEsGNnPA2Jic2p7aIYOUWYa3mShDZa6MlukyYLVkJs2w
mTcjZ+oMntkzfhRABHRACtRAEDRRviAO+iARKiEUWiEXiiEauiGdsg8NkRElERM9kRRVERZtkReF
ERmdkRq1ERzNkR3lER/9iQApIAhkgTiQCEJBLogG6SAgZET1hLCQFyJDalRziA8JIkTkiCiRJgJF
pogVySJcki+TlZQRNFU2EkfoyJ3qnmqg6qFqo+qkaibx1Cqanh8vSGDJrNbbVKMqsKSYICdrfZZQ
67RuS8CTJOaS9H95J/US/Ej5/wKcWpEGDQplbmRzdHJlYW0NCmVuZG9iag0KMzEgMCBvYmoNCjw8
L1BhdHRlcm5UeXBlIDIvU2hhZGluZzw8L0NvbG9yU3BhY2UvRGV2aWNlUkdCL1NoYWRpbmdUeXBl
IDIvQ29vcmRzWyA1NjkuODEgNjA5LjI1IDU2OS44MSAzMjYuNzVdIC9FeHRlbmRbIHRydWUgdHJ1
ZV0gL0Z1bmN0aW9uIDMwIDAgUj4+Pj4NCmVuZG9iag0KMzIgMCBvYmoNCjw8L1R5cGUvTWFzay9T
L0x1bWlub3NpdHkvRyAzMyAwIFIvQkMgMzQgMCBSPj4NCmVuZG9iag0KMzMgMCBvYmoNCjw8L1R5
cGUvWE9iamVjdC9TdWJ0eXBlL0Zvcm0vQkJveFsgNDc5LjEzIDMyNi43NSA2NjAuNSA0NjhdIC9H
cm91cCAzNSAwIFIvUmVzb3VyY2VzPDwvUGF0dGVybjw8L1AzNyAzNyAwIFI+Pj4+L0xlbmd0aCA1
OD4+DQpzdHJlYW0NCi9QYXR0ZXJuIGNzIC9QMzcgc2NuDQo0NzkuMTMgMzI2Ljc1IDE4MS4zNyAx
NDEuMjUgcmUNCmYqDQoNCmVuZHN0cmVhbQ0KZW5kb2JqDQozNCAwIG9iag0KWyAwIDAgMF0gDQpl
bmRvYmoNCjM1IDAgb2JqDQo8PC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pg0KZW5kb2Jq
DQozNiAwIG9iag0KPDwvRnVuY3Rpb25UeXBlIDAvU2l6ZVsgNTEyXSAvRGVjb2RlWyAwIDEgMCAx
IDAgMV0gL1JhbmdlWyAwIDEgMCAxIDAgMV0gL0JpdHNQZXJTYW1wbGUgOC9Eb21haW5bIDAgMV0g
L0VuY29kZVsgMCA1MTFdIC9PcmRlciAxL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTI4Pj4N
CnN0cmVhbQ0KeJy91IcNwCAQA8D95yG99z5UBrAd9CDlJkC8bedCJBFSi8wn1wqhFCqmZhrQMh3o
wQBGMDEzWJiV2YRdOLTT57K4Izw/inmn6UO83/txGnVNdX0aFRoqzB6NKCYZ046NwNbQcmEHaVVp
qdUCqMX4GBnvQJnmLmZXg4bcvQ6mfT0NCmVuZHN0cmVhbQ0KZW5kb2JqDQozNyAwIG9iag0KPDwv
UGF0dGVyblR5cGUgMi9TaGFkaW5nPDwvQ29sb3JTcGFjZS9EZXZpY2VSR0IvU2hhZGluZ1R5cGUg
Mi9Db29yZHNbIDU2OS44MSA2MDkuMjUgNTY5LjgxIDMyNi43NV0gL0V4dGVuZFsgdHJ1ZSB0cnVl
XSAvRnVuY3Rpb24gMzYgMCBSPj4+Pg0KZW5kb2JqDQozOCAwIG9iag0KPDwvVHlwZS9FeHRHU3Rh
dGUvQk0vTm9ybWFsL2NhIDEvU01hc2sgMzIgMCBSPj4NCmVuZG9iag0KMzkgMCBvYmoNCjw8L1R5
cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL05hbWUvRjMvQmFzZUZvbnQvQUJDREVFK1ZlcmRhbmEs
SXRhbGljL0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9Gb250RGVzY3JpcHRvciA0MCAwIFIvRmly
c3RDaGFyIDMyL0xhc3RDaGFyIDExNC9XaWR0aHMgOTQwIDAgUj4+DQplbmRvYmoNCjQwIDAgb2Jq
DQo8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0FCQ0RFRStWZXJkYW5hLEl0YWxpYy9G
bGFncyAzMi9JdGFsaWNBbmdsZSAtMTMvQXNjZW50IDEwMDUvRGVzY2VudCAtMjA3L0NhcEhlaWdo
dCA3NjUvQXZnV2lkdGggNTA4L01heFdpZHRoIDE5MTQvRm9udFdlaWdodCA0MDAvWEhlaWdodCAy
NTAvU3RlbVYgNTAvRm9udEJCb3hbIC00NTMgLTIwNyAxNDYxIDc2NV0gL0ZvbnRGaWxlMiA5NDEg
MCBSPj4NCmVuZG9iag0KNDEgMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQgMiAwIFIvUmVzb3Vy
Y2VzPDwvWE9iamVjdDw8L0ltYWdlNDMgNDMgMCBSL0ltYWdlNiA2IDAgUi9JbWFnZTcgNyAwIFIv
SW1hZ2U4IDggMCBSPj4vRm9udDw8L0YxIDkgMCBSL0YyIDEyIDAgUi9GNCA0NCAwIFIvRjUgNDkg
MCBSPj4vRXh0R1N0YXRlPDwvR1MxMSAxMSAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIv
SW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAgMCA3MjAgNTQwXSAvQ29udGVudHMgNDIgMCBS
L0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1Mv
U3RydWN0UGFyZW50cyAyPj4NCmVuZG9iag0KNDIgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29k
ZS9MZW5ndGggMTI5MT4+DQpzdHJlYW0NCnicnVdLb+M2EL4b8H/gkVrUNN+kgCCHPLrdRV1skxRb
IOhBdRTH2UjKynL69ztD24lkS4rig2mb0jy+mfmGQzL9Rk5OprPzLxeEn56Ss4tz8nM84oQzzrmQ
kjviJCdGc1Km49H3TySHx4wroeEd5Sys1sSkXLxKcW4F1w2x+0/j0Z/jEbmcnRNSMykOTLYIb2w6
ETNnCLxGjNr9ZNKAAJln49H0S5YsUq3IRUHaTMk3U5OtJS5itwXqlRAtRg3f2dQxE9IQJZiHnTgI
1ezaLrPq0KwxIu43qx0A20A1xAbDGqHWLboui/rQovXabixKrUVbdAVXr9HlAaLlMTrhgvU3s77L
rJn+nuQLQh+Tyddv0daHsxuQ+1UQzyCnN/dgJ5gQYEQxr2BfO0luMiwpG3sCRTT9fA0xWax2W5/H
o1sqo4mmHBeBS/g7tVP4NtRF/5Cbr+PR5U2LV7bmyKttY5iUNdu3lPTpcF3Idgq1Ewx44pkyO4Wq
T6Fv1WE3AXnT0etU3IiwJNKx2DZCLEEj0EF7y5zbxridtofbVyHqZ8n8x6KMNC3WGPD8ruZQw3ct
mfN1S+84L3jDe02k2PdeIN9AJ1CBb3WecO7dadOFAJ3vV5eCWPqmMP07jSzNSQbrPI0UOGjovMhg
fS7yFEDm1aoDnzSKiT11/fhEA58hwjO/RwCzwSc1i+NXfGeXLfjAdF3SOWZ9UxLA5SSaWDoDYOeX
0URS8uUav646IInYMiOaSvohycGQgNrqOEg1yTZIq+K+WuJe+bMrU1BITjQV9cNSQ2EpD6o3OgVy
xeIqoeyRQs2dwJ6PQa9pv6UvMwDckTfgOeSt8Xo/QD0YoOVMxMc0ig9CfbNzSy+KjJNsnj5FE0WL
ReDlxNElNva8SkvYuE+Arx3p9p6JpkIStfnB4OBr9UV5ZoZR2gxtWYo75s2RLasuTBXJEuhPjwUs
JXkuIBjLCOOyIpGnxT2BXga1gr35Enee4GGxWEaOzjsCpqRhMC81rPTDtkPLR3rz2v0/VhB1Sfpb
8R+WAnbnqiCbOnhM51W9F3QUA5xC8Z62fmxuMDarmTgOW01yD1uarUPVJxWePqHsEd/1VecxBAe6
2VPZD9APBgixM8cBrEnuAXzC5IUMvqQkCz+Q4CUC7jpoDVO6qfOQ0KKH0HBhYbEeFJx4KKFFzHFe
PI7QdWE6Sx5xmipDvnH8yFdVmdRpLfmW1/N1WaZhN2zuaN7Fa+eZbdrqBS/50MoQFlqsPqYy6pL0
rFjndwSK4qFYVV3Z5xoH1oZcPwqxl0Jh9lMYCyZgoBbaI3V6U3goLOAKJExDGEp8telFDzhEVvBJ
y2KR5mmxXm1orDj9t0yTH2FkiSaeZiHBii4g1bBXbf8W+S/wWHo6T3L4mxeoVyisigobfoFUetqc
iFLRl2VC5s9rrJSuOdxycFQ3/e0PoBwcQBkzdXQAa8L0D2RA3jXeaI63oIbApPNd6AJ77ybl/AHD
FYcIrzAja8zTCjcFUCskZYY91mBchaEpXgHWeHQmMFzabt9UrJBjdXP9wW0bLW07ySBxQr5Hsq6e
V5em3wFyGioM2m15t4Hp6PN2u+wKprUhmHVVnYF3Guetxrt3mFWYVvR2dCMz+NlzlMH1w+mmiv5g
Dh5j4RJq3g1lWxhrgvSvPE+qdZk8YdMlkZD1a0i4goShZImPi5ys0gy7eF4F8PMu1CqWrOnhIej/
AQcEAa0NCmVuZHN0cmVhbQ0KZW5kb2JqDQo0MyAwIG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1YnR5
cGUvSW1hZ2UvV2lkdGggMTAyNC9IZWlnaHQgNzY4L0NvbG9yU3BhY2UvRGV2aWNlUkdCL0JpdHNQ
ZXJDb21wb25lbnQgOC9GaWx0ZXIvRENURGVjb2RlL0ludGVycG9sYXRlIHRydWUvTGVuZ3RoIDE4
NzExPj4NCnN0cmVhbQ0K/9j/4AAQSkZJRgABAQEAAAAAAAD/7AARRHVja3kAAQAEAAAAZAAA/9sA
QwAIBgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8n
OT04MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy
MjIyMjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgDAAQAAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAA
AAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQy
gZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVm
Z2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS
09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYH
CAkKC//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1Lw
FWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5
eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj
5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A9/ooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigDxD/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i688or6X6pQ/lR839br/wAz
PQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1
J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP
/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLr
zyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz
0P8A4XH4h/589L/79Sf/ABdH/C4/EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fP
S/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q
/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4u
vPKKPqlD+VB9br/zM9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW
6/8AMz0P/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/58
9L/79Sf/ABdH/C4/EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/
wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k
/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9
br/zM9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcf
iH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH
/C4/EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/3
6k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qU
P5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/AOFx
+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/AL9S
f/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH/C4/EP8Az56X
/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6p
Q/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9
D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/AOFx+If+fPS/+/Un
/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8
+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH/C4/EP8Az56X/wB+pP8A4uvP
KKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ
/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L
/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/
AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i68
8oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH/C4/EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br
/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0
v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C
4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/
AOLrzyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1u
v/Mz0P8A4XH4h/589L/79Sf/ABdH/C4/EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+I
f+fPS/8Av1J/8XR/wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8
Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fq
T/4uvPKKPqlD+VB9br/zM9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/
lQfW6/8AMz0P/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4
h/589L/79Sf/ABdH/C4/EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/
8XR/wuPxD/z56X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/
AH6k/wDi688oo+qUP5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD
+VB9br/zM9D/AOFx+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P
/hcfiH/nz0v/AL9Sf/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/
ABdH/C4/EP8Az56X/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z5
6X/36k/+Lrzyij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688o
o+qUP5UH1uv/ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zM9D/
AOFx+If+fPS/+/Un/wAXR/wuPxD/AM+el/8AfqT/AOLrzyij6pQ/lQfW6/8AMz0P/hcfiH/nz0v/
AL9Sf/F0f8Lj8Q/8+el/9+pP/i688oo+qUP5UH1uv/Mz0P8A4XH4h/589L/79Sf/ABdH/C4/EP8A
z56X/wB+pP8A4uvPKKPqlD+VB9br/wAzPQ/+Fx+If+fPS/8Av1J/8XR/wuPxD/z56X/36k/+Lrzy
ij6pQ/lQfW6/8zPQ/wDhcfiH/nz0v/v1J/8AF0f8Lj8Q/wDPnpf/AH6k/wDi688oo+qUP5UH1uv/
ADM9D/4XH4h/589L/wC/Un/xdH/C4/EP/Pnpf/fqT/4uvPKKPqlD+VB9br/zMKKKK6DnCiiigAoP
AopD0oA27uLR7BoYZbK6mkaGORnFwFBLDPAxUH2nQ/8AoGXf/gV/9jRr3/H7B/16Q/8AoAqna2Fz
eJNJDC7QwKHmkVciNc4yfasopct2/wATVt81kvwLn2nQ/wDoGXf/AIFf/Y0n2rQ/+gZd59rr/wCx
qVL3RtPH+j6edQmH/La8Yqn4Iv8AU1ZbxbrdsQkS21iCAVSKyROPxGTSs3svvZSaW7+5XKP2rQx1
0y7H/b0P/iaVU0e8bZG1xYyn7rTMJIyfcgZH1rWsPE/iTUpZIhDbakI4zJJFNaxt8g6k8A0/UNIs
NX0O41bTbQ2F3aKr3diG3IY26SJ3A9qnm5XaWnzuVy8yvHX5WOYuraazuZLedNkqHBGc/iD3FRVp
XjfaNC0+4c5ljZ7fd3KjBX8skVm1vF3WpzyST0CiiimIKKKKACiiigAooooAKKKKACiiigAooooA
KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo
oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii
igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKOl
dZa6BoekwR3XiXUt0joHTT7I75CDyNzdF+lROahuXCDnscrFFJPKIoY3kkPREUsT+ArqNN+HPibU
lDiw+zRn+O5YJx9OtW2+IR02MweGtGtNMi6eYy+ZKfqa56/8Sa3qjE3mqXUoPVfMIX8hxWTdaWyS
9dX/AF8zRKjHdt+mh1y/DCG2XOqeJ9PtiOqqQSPzIpw8F+Co+JvGSs3+yV/+vXnRAJyeT6mjA9BR
7Gq96j+5Fe2pLamvvZ6UvgLwjdfLaeMY9/YOyf4iorr4Raj5Rl0zVLO9TsM7SfxGRXnW0HsKt2Oq
X2mTCSxvZ7Zwesbkfp0NS6VZfDP70Cq0X8UPuZPq2g6poc3l6lZS25PRmGVb6MODWdXqnhr4kQ6q
F0bxVDDLFN8guCo2k9t47fUVheP/AAQPDU631hubTJ2wATkxN6Z7g9jRTxEuf2dVWfTsx1KEeT2l
J3XXujiKKKK6jlCiiigAooooAKKKKACiiigApD0paQ9KBG/dWDap4j02wQ4a4ht48+mVGT/OtqzW
1v4PFXlxlLextBHaqrFcKHxk4PzE9Tn1rIl1D+yfFGlaht3C3it5CvqAoz+ma1dY0DVrFrzUvDrS
Xmi6kpJe3G8hCclHXqCDXHPom7bW+/U7YLdpX7/cbOoaHoD3F/pEeiwwyQaSL1LuOVt+/bnGCcYq
5f6bp2ta/aRX1pERY6LHdM7SMBNxgK2Oijk8c8157Lr2vfbZriSSYXEtt9lkJhxmLGNuMVbstW8X
3MliLM30r2a7ICkGSFIxtJxyPrWboVEk+b8WWq8G2uX8Dr9LtdGi1WS40p7ZZZtIuftMFq7PGjAD
BUtzg1z+jW8nh/wVq2qX4MTanCLWzhf70gJyXx6CtiPw94vvphq2u6pDpMUcLRF5NinyyPmUKOOf
evPb7ULvUZEa7uZJzEgjj3HhUHAAHYU6UOdtKV9r9dvMVWfIk3G29um/kTyceGrb/r6k/wDQRWfW
jJ/yLVt/19Sf+gis6u2PU459AoooqiQooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii
igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK
ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA
KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACtHTNEvNVt7y5hULbWcRkmm
c4VcdF+p9KrWFlPqWoW9lbLumnkEaD3Ndl47uIdFtbXwjppxb2qiS7cdZpTzz/P8ayqVGpKEd3+R
rTppxc5bL8xNMt/Bj+BZJb2WAa75UhVTIwbdzt46elcLkDqea9e0DSdOm+EM15JY273It5iJWjBY
EE4OaX4X6bplx4Qu7q8sLe5aOdzukiDNgKDjmuRYlU1OWrs7f8MdTw7qOEdFdX/4c8g3D1FbnhTw
9/wk+urppuTb7o2fzAu7p2xXp/h7WvCHi7UJNLi8OxxOYy/7yBACB15HTrWP4Y0eLQfjFcafbk+R
HC7RgnJClQcfhVSxbcZRs4ySuTHCpSjK/NFuxwvijQh4b1+bSxcG48tVbzCu3ORnpWMSB1Net/Ef
VNMvL6Xw/DpedYmeJVuti9yMDPWrt1B4W+GumWqXWni+v5xyxQMzkdTzwBRDFyVON4tyf4+Y54VO
crSSivw8jxgEEcV6tp3h/SJPhFJqb6fA16LaRhOV+bIJwc1N4j0HRPFng1/Eeh2q21zCjOVVNm4L
95WA4z71c0r/AJIdL/16Sf8AoRrOtiPaQi46PmSZpRw/s5yT1Ti2jy2W80pvDUVqlnjUQ+Wmx1H1
r1bQpT4q+Ec8F388sUMkW48klBlT/KvEhwo+le3eHIT4Z+EtxcXQKPLDJOVPBBcYUfyqsalGMbb3
0IwcnKUr7W1PER0FLSDpzS16BwBRRRQAUUUUAFFFFABRRRQAUHpRQehoEbWtWjS3Vu4ns1zaQ8SX
UaMPlHUEg0aTqGr6HIX03WLW3z95Vv4irfUFsVwXj8f8VKv/AF6Qf+ixWFdaTf2NvDcXVpLDFMMx
s64DV4k8fNXhyppHuQwEHafM02e/J8RvE6rh7zQ5T/eeaHP/AKFUNz8QfFlwpVdX0qAH/njcQA/m
WNeBx2F1LaG6SB2gEgj3gcFiM4Hviq+OeawWKX8kfuN3hW/ty+89fvpdR1OQyX+r21y/rLqMTY/D
diqn2Fs/8fWn/wDgdF/8VXleKOK2WZVFokv6+Zi8tpt3cn/XyPYbqEw+HLVTJC+bqTmGZZB90d1J
rKqn4Z/5ExP+v5//AEAVcr1cLUdSkpvqeXiqap1XBdAooorc5wooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAO5+E
9mtz4zEzjP2aBpF+p4/qa5nxFcvd+JdTnkJLNcvn8CQP5V0vwovVtfGixOQBcwPGPqMEfyNZnj3R
pNG8XXqMuIrhzPC3YqxyfyOa5Iu2Kkn2Vjqkr4ZNd3c9E8OH/iys/wD17z/zNR/Cz/kQdS/66S/+
gCvO9J8ZajpWg3miqkc1ncoy7X4MZYYJB/pVnw746vfDmiz6Zb2cEsczMzO7EEZGO1YVMLUcZpdZ
XOiGJpqUG+isaHwk/wCR3P8A17SfzFdVbHHx3uc/8+p/9AFeZ+GfEU/hjVzqNvBHNIY2j2SEgYOP
T6VLf+K9QvPFP/CQRBLW8BUqI+VGBjv1BFa1cPOdWTWzjYypV4QpRi91K51vi+Oax+LNtqU8Eq2a
ywMZih2Y6deldv431y80SO2ubfQY9UgcFXcjcYz24APBrzDX/iPqPiLQ5NLurK1RJCpaSMtnIOeh
qfQvinrOj2SWk8MV9FGNqNISrgdhkdawlhqsowcopuOlr7o3jiaUZSSk7S1vbY3b3x9ra+HJpn8J
rbWE4aHzdxUAsMZxj9a0tJIPwOlwc4tJR/48a4nxH8SdX8Q2T2PlQ2drIMSJH8zOPQk9vpWZpXif
V7XR7nQLVftFtdgoIdhZlJ6lcVX1WTgtEndPcj6zHneras1sdN8P/h82qi31rVNo08HfFDnJlIPU
+i8fjT/id4xh1ORdD02QPaQNmeRfuu46KPYVy0ni/WF8PwaDDN9mtIFKMIuHfkkhj/hWBW8aEpVf
a1XtsjGVeMaXs6a33YUUUV1nIFFFFABRRRQAUUUUAFFFFABQehooPT8KAOb8f8eJl/69IP8A0AVr
xappEkVvc3t/ZvrDQmOO5WFmRfkAVpVIxuGMAgGl8WeF9W1jWEvLC3jmga2hUOJ0HIQAjBOaw/8A
hBPEf/Pin/gRH/8AFV8xUhLnenU+npzjyLXodHF4usba/sI7a8jjt4r8yOVtwFAMSqzgY4Bfcceh
qG21TwubWF74W0l/5ZkkkEBwJIidijAwRJkZ47Vhf8IJ4i/58U/8CY//AIqj/hBPEX/Pin/gRH/8
VWfJLsXzx7o3n1vQ7bRP3E8Mt8sDi3kaAF0JVeCNoA53AdfWsvxVqmlXumWsenpbYyjLtXbJF8gD
KflAwWyepqr/AMIJ4i/58U/8CY//AIqj/hBPEf8Az4p/4ER//FUckuwc8e6Nzwz/AMiYn/X8/wD6
AKuUabpd3o/heK1vkWOdrt3CCRWO3aBngmivocEmqEU/P8z5/HNOvK3l+QUUUV1HKFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQBNZ3c1hewXdu22aBw6H0Ir3CJ9D+KPhtFmPlXkQ+YL/rIHxyR6qa8JqxY393pl4l3
Y3EkE6dHQ4/A+ormxGH9raUXaS2Z0Yev7O6krxe6Om1v4b+INHdmjtzfW46S24yce69RXKSwywOU
mikiYdVkUqf1r0/RfjHNEqxa1Yebjgz25wfxU/0NdZB4/wDB2qqBPdQqT1W6hx/MEVz/AFjE09Kk
L+aOj6vh6mtOdvJngG4eoo3D1FfQ4uPAtz827RGz6iMU8Xfgi2G4SaImO4EdDzB/yMf1Bfzo+eoY
JrhtsMMkh9EQt/Kt3T/AviXUyPJ0qaNT/HP+7H617LL468H6evyajajH8MEZP8hWHf8Axi0WEEWV
nd3TdiwEY/Wl9bxE/gp/f/SD6rQh8dQydI+DcjFX1jUQq94rYcn/AIEa7eDTfC/gexaYLb2Y24M0
pzI34nk/QV5fqvxY8QXytHZrBYRnvGN7/mf8K4u7vbrUJzPeXMtxKeryuWNL6tiK38aVl2Q/rOHo
/wAKN33Yy4YPczOpyrOzA+xNR0UV6Z5oUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAmB6UYHpS0UAJ
gelGB6UtFACYHpRgelLRQAmAKWiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAEwPQUbR6
ClooAKKKKACiiigAooooAKKKKACiiigAooooA//ZDQplbmRzdHJlYW0NCmVuZG9iag0KNDQgMCBv
YmoNCjw8L1R5cGUvRm9udC9TdWJ0eXBlL1R5cGUwL0Jhc2VGb250L0FCQ0RFRStWZXJkYW5hL0Vu
Y29kaW5nL0lkZW50aXR5LUgvRGVzY2VuZGFudEZvbnRzIDQ1IDAgUi9Ub1VuaWNvZGUgOTM2IDAg
Uj4+DQplbmRvYmoNCjQ1IDAgb2JqDQpbIDQ2IDAgUl0gDQplbmRvYmoNCjQ2IDAgb2JqDQo8PC9C
YXNlRm9udC9BQkNERUUrVmVyZGFuYS9TdWJ0eXBlL0NJREZvbnRUeXBlMi9UeXBlL0ZvbnQvQ0lE
VG9HSURNYXAvSWRlbnRpdHkvRFcgMTAwMC9DSURTeXN0ZW1JbmZvIDQ3IDAgUi9Gb250RGVzY3Jp
cHRvciA0OCAwIFIvVyA5MzggMCBSPj4NCmVuZG9iag0KNDcgMCBvYmoNCjw8L09yZGVyaW5nKElk
ZW50aXR5KSAvUmVnaXN0cnkoQWRvYmUpIC9TdXBwbGVtZW50IDA+Pg0KZW5kb2JqDQo0OCAwIG9i
ag0KPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9BQkNERUUrVmVyZGFuYS9GbGFncyAz
Mi9JdGFsaWNBbmdsZSAwL0FzY2VudCAxMDA1L0Rlc2NlbnQgLTIwNy9DYXBIZWlnaHQgNzY1L0F2
Z1dpZHRoIDUwOC9NYXhXaWR0aCAyMDA2L0ZvbnRXZWlnaHQgNDAwL1hIZWlnaHQgMjUwL1N0ZW1W
IDUwL0ZvbnRCQm94WyAtNTYwIC0yMDcgMTQ0NyA3NjVdIC9Gb250RmlsZTIgOTM3IDAgUj4+DQpl
bmRvYmoNCjQ5IDAgb2JqDQo8PC9UeXBlL0ZvbnQvU3VidHlwZS9UeXBlMC9CYXNlRm9udC9BQkNE
RUUrV2luZ2RpbmdzL0VuY29kaW5nL0lkZW50aXR5LUgvRGVzY2VuZGFudEZvbnRzIDUwIDAgUi9U
b1VuaWNvZGUgOTQyIDAgUj4+DQplbmRvYmoNCjUwIDAgb2JqDQpbIDUxIDAgUl0gDQplbmRvYmoN
CjUxIDAgb2JqDQo8PC9CYXNlRm9udC9BQkNERUUrV2luZ2RpbmdzL1N1YnR5cGUvQ0lERm9udFR5
cGUyL1R5cGUvRm9udC9DSURUb0dJRE1hcC9JZGVudGl0eS9EVyAxMDAwL0NJRFN5c3RlbUluZm8g
NTIgMCBSL0ZvbnREZXNjcmlwdG9yIDUzIDAgUi9XIDk0NCAwIFI+Pg0KZW5kb2JqDQo1MiAwIG9i
ag0KPDwvT3JkZXJpbmcoSWRlbnRpdHkpIC9SZWdpc3RyeShBZG9iZSkgL1N1cHBsZW1lbnQgMD4+
DQplbmRvYmoNCjUzIDAgb2JqDQo8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0FCQ0RF
RStXaW5nZGluZ3MvRmxhZ3MgMzIvSXRhbGljQW5nbGUgMC9Bc2NlbnQgODk5L0Rlc2NlbnQgMjA1
L0NhcEhlaWdodCA3NzEvQXZnV2lkdGggODkwL01heFdpZHRoIDEzNTkvRm9udFdlaWdodCA0MDAv
WEhlaWdodCAyNTAvU3RlbVYgODkvRm9udEJCb3hbIDAgMjA1IDEzNTkgNzcxXSAvRm9udEZpbGUy
IDk0MyAwIFI+Pg0KZW5kb2JqDQo1NCAwIG9iag0KPDwvVHlwZS9QYWdlL1BhcmVudCAyIDAgUi9S
ZXNvdXJjZXM8PC9YT2JqZWN0PDwvSW1hZ2U1IDUgMCBSL0ltYWdlNiA2IDAgUi9JbWFnZTcgNyAw
IFIvSW1hZ2U4IDggMCBSPj4vRm9udDw8L0YxIDkgMCBSL0YyIDEyIDAgUi9GNCA0NCAwIFIvRjUg
NDkgMCBSPj4vRXh0R1N0YXRlPDwvR1MxMSAxMSAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFn
ZUIvSW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAgMCA3MjAgNTQwXSAvQ29udGVudHMgNTUg
MCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJz
L1MvU3RydWN0UGFyZW50cyAzPj4NCmVuZG9iag0KNTUgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURl
Y29kZS9MZW5ndGggNTAxMT4+DQpzdHJlYW0NCnicnVtZbxtJkn434P9QwAKD4mBVyvsAGgJst93b
g/aO1/bsLtAzD7RM2eqWRC0p293/fuOLyCxWUayirAdJrGBFxpFxZ6o5fdP88MPp6xc//9ios7Pm
+Y8vmv97+kQ1qlNKaWNUbKJRjXeq2ayePvmfvzY39HWnrHb0jo2Bfgefm82nHkupoJUboV389emT
/3r6pHn5+kXTDEjqeyQPIAvNqHMXfUOvNd7Wj53xhNCcXz99cvrz9fLTyjc/rptDlMyO0kkhpHSO
Rc5ktT5A06tK0uVOG99Y3SWCZEYakA1TZO19st7rPE/WRZJLJPVNYMIOkg4pximK7j7FkFwQisY5
fUi5WtleuYpFDCqDicjUd2TTFFl/+svy5lPT/rY8+dubReHh+XvCe6Wb1NGWvr8gOkxCExHbJUtw
F03z/hoWFXJqyIZOf3pHOvm0raCfnj75tTWLE9cq/NL4xY+n4ZT++jYu/tW8/9vTJy/fH+AqDBjp
aXvfGTOg/WvbzK0RpySrC7qoO3KT1FlfF3RzC6aDawRRyG6NWabySMOmMbHLYaRinU3nbeNS6GIs
Oj7stffBb1nr/7u6ab6+fvGyWZzEdnl7u1m4dr08h/I/E0yn9p+t/udiwOZIzSZ03g3pHxFJq5FM
jiTo0lgk3QUdGudsZ2XFH5RK8WzMANShx4gmd26I1r5bnNh2dbuw7XKzvFs1n76stneQybQkML5s
vrGRNZ/XixPT0peAH5bUWtNZO1p/XlA9EtQ3mvbejB2EQkAglo3vQuhFff7ykKi+y2mMHCkujnDb
f9yQqFe0f5f08/sKkob2/PbL5SK0HyfE0oHcdm+debnM/ga6fb9PlsXSir+Y3cF7uFrpfeSWzHNx
EloyUePb8+VNs9C6vVgWIbUi2C2ePlwuThIpgAz5Er/uFlk+rLakAcIm0JqRyRKw/bAGXd65oI+m
vVnBEFZT2nLKdCmPuZvXln2gtmx2XTaP1NYQ+bC2riHWcvv7wrcs8pTGLklVUVQ10MqXmxt2pfMV
3GW7XW7+nFQQMZTHDM0ryB1wkwNOYmOiJHXcScJ9Hxmiti+vv8BDEA5IJbpd4k/7jXcdX1xN+Umi
2Dtmoz2Zejf7Tu+9+3F1ARqX5KE3q48g6ltslMFGnWT54m5Fvzdk2aTlc/ZfS0Zs2zXHqglqImMw
Xaz+y3GO0P59AawTY9vz9c0WQYHAvt0ClmTRi4lFDVk45eXRsvP76B9q6LSfOjzW0AfI7c83lzD0
u7/cbtYf2DJ3dkuq3CzJXCeks5GlG642L13Yl053ewxSHgODlkqeY0HPjDFt3Mdsn2NvllsE7vPl
Ff2Gaf4Jg/DtxXrD5vCJtvIL7XCJZOzZ7MeuRR7A37sFdHKiY/sXWFpzSy9t1qinPjDiRKYztlN5
zNC8duJDtWOo7EyP0s4Ak3KZiLddfiCBoJqVOAiJ/48Xb6c2nWpdv7fSlAcbssC89y50DcVuVrA6
CSJEnkl/FE8jRVNgJSAxJlm4ZuO78lc2a0rxVFug/RhSnVd82lN8vlclaKqDoT8Iv9P8c31A8weQ
o0VVMERu36wXCT6moQ0S5u6Ky4wVpY0t9kRMzihKtSX8qOHrv8FP8fI5tAKd0ZufodE1mfl2IV8S
3Br+tCEoftblL33jXL92olgHc67U76Y0G2Ln8liQec3mB5q0yRRDHmPRA0SxCtgW283DDTp2No0W
mrZniuPjVyfN+Bx83AL+OCOmSjLaEalZTZv9hiDf63HEhE3yVEAfNeFwyIKHuO1/rsWOyDCvYY0k
/wmEQ4XDVubLt59hWmtkTBiqJZm/3AJ0i1cBx6t3ZafsDsSGeVORJ22yKGrI2rym9ENtkoS2s0nI
TRnlGNPFM4s/L84c/fGBPjr68Wce0FcMdensBC8pe3YS6a/FAILeNM/k2Rn5HjAbz06Aal6dnRjg
yBKEqk0h4KMsLiQdSL48G67PHLwaclC/oVKSKT0PshRYcVlYN0LQewFXJt0LMIjPggoGrTB41I9R
41JMGarsyP7td06Tlk5VlwqPtPQBbvsTO2sQW6y2vZSAjd9SU1CVv+ZIO7L7U9j1Nyr/ERaKa3zA
Bw64n4rV09u3PRAr9L6xnSwvbMbIYsTovN72e6hJvXndmcfqbYDbPvu65hIDGmLhm+v1xxVHQoBE
7u3tisQ8x1vUjV7yWOG8QVAVxC2azpKdJjShPEYKI9LzmnAPLLKNDShwH1dkD5Hbl5sN1ZsTfQ4F
DbX3/mRPRLXN3qtSqF+sdz04qvaLubI9dDqNF5nX172mZCpiGjscwXxPGh9gtn9HIqlDmFKuX6+W
1Kd4Bn+in4svpWaVevEbzOtzLeNv+jpS0jP5KjnlaoN1pXDfsLY+DRH4AwZcU1MLm3Pn9JjVeb09
tN1BmxgfpbYdYvuKZKxlxl0tLzZSGkrf8rEWKLUS+Soqae64MsQrB7sh0iN/y2rtF7le3tDHSWWR
Nzo9YnBeV/Ghcz5NCcM8cs43xG1/WS2/rrjI+LzeNX4XV4hQf1x+uBxMAaHPqVmNsa5LYbz0vKhp
bx59f+BSJI3kof5BS96rsyfGwZq2xebvnwcP8TiYwR42PNW6hD/d/CaTLVR4HuNBGZ5MldEahwqj
NWfFs+ph0y1t+WTmMdOtIWr7rDRUaFOXHB+2F6tNI0M+Kuv/5O5rMp5nj4ZitOK8ePcq0ol8pHXq
tH9kPhoit69413hieQfJDG3h+mZmuA2BhgtMJqjourhH7N3bZ38/fQeLefvsLRvIh+XN75OdjwqI
HKMV5tX30FE6Du7UscOQSfUNkNv3m+XN9opTC4daViCiCM/Rlx8/blbbLX0Ohyblur4wpQDiNtsx
wXkFPHQ6juGrfux0fIjc/ri6knErGdDXaU9AEtjDnJfkXmVGC5iDOZPszIejQ7BO7WNL4hxity/J
p7/Cr6+ofv8irXxsebKdW8pyOPaRQkM+ra4wUQRGnz8jFR+wg+v1doFhMyeTQNU7KafMVHV9fcMj
4ymdWer4bRwzOK+zWp1NHFm66DttG2c4HOnEx/RWdb6/bOCab5Mnm0fQ3x1iKBzNb94YnAI7Sp1R
hNSgHPDbEAR8jyFyyvrTl1Udv3M0nj5nDCohdw4oHFNjPKJGCoLGN1nxIT9i/J4WJxU4h3hQf4fO
vL2JqDrhiyp/h8b+g4MSmeKcqhwsbrD0MVXlI6oyrgsUwJLhdSUPagKSHR3V1hHcQwpzg8s4mhT7
DbLRYiTbb03za2jIl5p/kazNx4YIGCxpjG5IUh8UVsbTFS9+8JZIzc/3Ve6p7SV8bahSy7wgVRPk
LRRFg8GSPmoqVfjZyrPIR9upmOZnMJHQwztNQVrWoIIGUc5UjPqtLxgXh7g0+243bhmclFsm0W77
7/E5xKy9nuA1/XpHnviWDzInLzXYzushwSN25ewBw3fe4vhP59A3ErBptCIP40JH5KAh/jwT7hAT
DimMSv20G1K9X2RMgqg5ohRB9C/6HlKqR54JI9v/iSp5NRfzPcUD2uzR8vNM+kmLdAn+YnF8fI0n
J/ZJYTDDeFziwxEKRTBYBhjU92SPlCn5mVyIPM8kjJcYoHB4qakPSIkBEUcc5JtUxfcA1POWPMsI
gJG1ZeJlUX7Ddy5UQMryhq5sBFnCVT6tYyJO1iRJFDAUDhsLgBgCo7kQ8V2ILEosbwSMFuGc4jmO
KhEbWHhfXYnzG8oeA2SoDB6aeNKSZRmMtkgasgFZJRp+gfxJF/k1K8S7yistkWWepgoKUcyMUnil
1o52wSXww8+0OLhw/Qt8SQlcBNezirShg+2cF05JF/QcKqMh804Rf8pWTgvA2CqKIk4D6aE+u8RL
xlSp0HoJhbzqXFEInnIJYBClfC0WNRWOahXgSS5HxbyXgOvZSCxFM4l/3rNpWKrVxCC9h5TAcHV9
T5olES1qU1NWoRzKHHvSIX9nsQcz/NT87igTGwTYAEdgH2FSjsoUU+yGtwUA2mA84VIhPZH94Ul7
DujE7rnYlNMMMKZaHV+9YQMudpmQA+Bo5VnjBV2fXSdXdWxv+uS9DpcKXfUNks0pThMFYAAIOFou
7kQMK49zueKzmdSucBWyAkyQizeh+myQiybOVZ/NkYdc2VcAxW2bU2/VESctliJp8hWgAfCd5E+2
atyjsfhTjAWbkzVspgDwguot1GExCx33AFqSdGh75yPGLUnsTbVpkh23Qnx1PotbIoRXXmDDtSEX
g4Bb4Pg1+IJB6TbTI+5u1meDiVWosYjcg/SIEZbpAcSvdWQy8ixyOt2pVAEaM3lfN4SIkedZLvTK
M05OKfKoWAGGAJTmfagAHcWOexRol3bd9HxWQOgBYvop95IkXrRsakhClu8RFQDqd+LL6qqcwnkf
Q+Bcrro31KlwqO6ruhCFiCruvtq6Axrq4vBbACmyhm3uIyaOj90gpDrDe+TqrpOQFpE2VjvRxDhM
LlfTgqxk6CVBwPiIKjmT35knuucIsy0GzKaTaxYiQGLj2/mAhcmb3lwz31fIrkZ2chsvFh59dTQ2
+YjdKwB2ioSbm8U3yR6dUhCgem9kT/Ox+rfP9RJcCQDGsbdq36e2zP5cvABSOnZ4r2uQgX/Hrs90
SSJEcDXTMQJ7eYlpxnCUKepK8AIEoUqCD/URpQoTpCdrGFBsJ7FHAVDSKbk1l6rDHEUwr5kOOTSi
K6kqSjyvtUDk8KZ5qDQTsPfHpPfOnHzkxO5UvUt6vxr6VU7Svp5+5knF9dTtL5/E+4j7OnJBw+Qm
r4uhKodnofSpdaUcWPEpYbmfEdrzu0s+v1jz2cVEA4YSNY7Xmi//8qEOUXOhPLoz+N+v+Woc0f7j
slyDO3AF7vCtFa85/yDy1q7wJxLozb9NaUSi4fD9WSG8mu8iPYVBQzGQCmOtnJj30fZxEulQ3+j1
fMcUNEc0g2yV661wVENE0NkGhaiut8L3wdI7vXj2pp4ryBEMPr14Dwv5RZ4nLILKXko4hqJgqMp8
Tf3F0W4nUCWHRmWIOL8L465R8+X4PUsIVLNRaMDspx5w/DFFH9l49OY8dbu/A/emj47SCpW71vHE
6KFtK/8HR8D/LJzPH74iyiF+75YnMJCmBtyIZ7jWt0MYHsFO4PjEMlD2N2Oc+ZNabxSnxSHevD4P
Na9BBupI6dk9yoz5iqjbXRGdMVzNSQ0Fh3bfIWnAsYEe481L6nczH4Mil0eYmY0gU5MwMAWZAuUm
IA/1YyCFoZChvEW0ouIcZSSLTUyBfNjFq0PaC5YbEW1MaXWC4xwIQOA8D4CVNwgfT9yd8jwKT7QQ
nhLaikDRFKeK1MlbK8halreoWQLMTxp9YgJP2slTFmx+C22/jYJteQpCAAfStpOpmovyEPiJKgNG
dqhltFysYuTArTeFBlcAkZtzk0uBF9DIWhkJBAF47pGpnw8FQNGYu/ecK0PoK00uHQpkwICTiKRQ
BWaWa/cOQJBZmzQTrEEZZdj6HKTfV0LEZnDM/X6oADSv8m8aV7JpXtZwtRgJVPdHTBpwhnotz+jm
aXXNBoJ4mD335lKNBW+lWY/9G3zxFf2+MgLgUQAA3tQ1MJjBn1wByvIbUmqCLEUYLJrLooqbd+ek
aA4uywu6UnVJ+Bq05oG6GnCCWrxIE1mLVIsX3hNmMjjjy6YCqF7loUFhJKADACDqKgzmELk0hpAW
eqcly05BH5mJys6AkSDekLipuhYANpxqXdmKwKlDuvPyDI+gZlIGPmAMeZ0ALlaANYziC93IVkdL
5lgBmHZhptVvbzAIxkZxoXstAGLToL1OQtnCT3F7WUpWsEp+BIAthLhRAIo1FUBaxKKup2NRf+C6
SKUDlRsTS5+PZ6xqXTWS4PhyD5eiRQPyXDYCGhKEsuEEkBVlVAI+KfqC5E7tvCmGjEbHygVinYvV
uwlAPmFoE22/ERWQKqCgpN3WyKLG94S4VTNkxskKIY5BJujSOGK7yhu5jr4PFf6+TmrYfWVSo0ON
qLQWRjG2Dwn4tyvNCRJPWiY1Wp6MTHGopCghFY2Ydn2QMrV/KZI7bkt5UmNq1Kqjmh6QhsMaBDr8
5yCGNX2wNDKr8fUZPKtd1OJRHw9rbHVb/Keeql0nALE0iLp6OviiFrLaHw9QMKwpwdLzBBltqNU1
emCogbF3D4iJW1kVa8Dh+Y6tOQIbwy2QTPrgxc5x/5x2bh15WKN6x0cTRN1njXscR9EDFBV7qT3Q
ileHtNzn594m8D8+mDrkPvoYHtZUNuV/HvphAgeSzOMGnwZWj4FE6P0E0wXn66KBp82ogFwxYAM2
rO8d3EBoS9ko9oBSxxhXY4LCeCaVCQUAmFBgkGkqAINMVUcDzGgBxApgFFPGIACgZcJ0tBe2lk9D
4Ykv3wcei3ENRbheXSxY3YDEe+Z8pen55ALKKVxhBwyrr1gbbRGJZCWklU3E0C64mjW9DGNok1Sf
3qyMa4rjeCvdcBykNx95XON78/OZxzXFcTwfN2JcU/lQgpLK3I6NXIaF0VQ38Dyucb3jZM8dr+od
x2a28ZCqryUj45q+cjEy1NzVNiHIuCb2xU4Z1/jq4c4PxjUcA7z4a6wAY2Vc0xc3QaY1faDhEVDs
SxnDsxWKEsU7na4z38q5hvAINKHWNjZJJOpLmeg4VpXsQABlOZrJbJXDp0Szoj/LZwp4w/f5Qf6H
C3RKlrIyrt9VZXz4mIqsg5j9/1aP5s4NCmVuZHN0cmVhbQ0KZW5kb2JqDQo1NiAwIG9iag0KPDwv
VHlwZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8PC9YT2JqZWN0PDwvSW1hZ2U1IDUgMCBS
L0ltYWdlNiA2IDAgUi9JbWFnZTcgNyAwIFIvSW1hZ2U4IDggMCBSPj4vRm9udDw8L0YxIDkgMCBS
L0YyIDEyIDAgUi9GNCA0NCAwIFIvRjUgNDkgMCBSPj4vRXh0R1N0YXRlPDwvR1MxMSAxMSAwIFI+
Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAg
MCA3MjAgNTQwXSAvQ29udGVudHMgNTcgMCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFy
ZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyA0Pj4NCmVuZG9iag0KNTcg
MCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTg3Mj4+DQpzdHJlYW0NCnicnVht
b9s2EP4eIP+BnwZ6qGW+kxoCA42bFC2aIWsDbEA7DKoru+5iy5PsdP33uyPlWLQt2TOQWLLM5+6e
493xTmRwT66uBnejN68IGw7J9asR+efyghGWMMa4EMwSKxjRipEyv7z4/WeygJ8TJrmCNdIa+DQ6
JeX0GcWY4UxFsMnPlxe/XV6Qm7sRIQ2VfE/lAXDQaXmaWE1gGdFyc5sIDQAynl9eDN7Ms2muyauC
HNIktpr6tSLGU1vzdJLzAzo126hUacKFJpInDp6kHtRQa9rUyn21WvO0W62ywCsw1cR4xQqZNjXa
No1qX6NxygSNQil+yLmcyWfnMk/RsBSNsF77Vq1rU6sH77LFlNBvWf/tfa+24foBcLecuAS29GEC
erwKDkpk4iQ8V1aQhzlGlEkdgRgavP4APplWm0evLy8+UtHrK8rwg+OH/zowA7hqant/koe3lxc3
DwesMg1DnnVrnQjR0P2Rki4Zto3ZRqCyPIE0cYnUG4G6S6A7KMMEh2xldBqVRh4WRNgkNZGLeSoS
LYlyJrG29vHhrN1//N57/Y98QZ7uRjek17c0Wy7LnqJFNkbnf4Vn3NFPVHzqNcyM3CxMolVT/xFK
nEWcFDBIXEQJsk+mgigI0ZQHkVeMOTuMLUB/8BiJ6atjJL3rSfrhfUXy+foROWWrWa8vabFoIcRT
lVgVy+gmxCNCmnCzQ8jYQEjKRNhnQtc3hwjp3Q12aZLqGEzv12UOtGB3HK0GPU2/w21K8zncAkvt
SZp2jkLpRLpYZjdHcSpHJJCey7EBpr9iGGL8Mbpo3yyooVBmI2C/ba1WYGK8NivHGOOC0xn4s6pA
5xo9W4WH2TSbtfowlYmOpXW7UO7Gvdotl1ie0ULG8NId+PtgwXfB9LYoSY8LOsmA2HyG4fKIWf6j
NfZ5AsU4ktHqzhSqmIrXzosvOSbXI+kJBy4FVVW1zuGbpmVRrMAYTidlMYcbFkzJp+Bpmo1/QNTC
OkuXZTH2QqqqKFt0K6sTG6vu9r3a9T1PdrwHvQbIks5ije9wPWBFjNT2AFJY6AAE/HNIAgNXO1Tw
mMlh38JVwSOlsEmAqzu0v7ESAUVSu0jJEcb6VMZWJfxYlT3MuIGkr7G0riFzwtatcDeXPdx1PLw/
b34gWKHGORlnS4jI7DN8zOD/sb6u6msQgslv6BNWsizcYy0fgSpD/8IVo5f3IO4FAMgCbgqMJBTh
T7IxakCLUOCXtkByHIM4otLtV3NqFksN/tVnZnET/JzFz9nVmpEi4TG0K3mhWYzWVksvfTybzMak
Jxv521oBGVTASEa37+ypMakMNCtnZWGMFOlQX2EiDvviKmQbk/6PCczAkU9KBT/Lq/BI2mEfIeI2
QNjtJm+5lxBSGVdswCjnZijr5OaY3XWyb9SiPqX8EhXEqduoGkB58gb4QmEigOYBZw9rCOWjb67q
chJMe64yL4MMF2S4oKXBYSvvJQob9tWWWK1ig/I26SbzRknzMrwBJjzAZdc6lD9fBrf224YEHJPk
0DQcs7GR4X2Nt37FtTlemTRkAKZzIwqOhKQ7NSShVWKd2dwakjGyIySl8UR9GIqwF3iMoNNMA6LS
rY8lG24iV40wklEKRjHOgOEqnZesomAOu7Bx9rXfhsgsE/wfIrE1bmUzbo9vDwyliXKRR6Ltibu1
4D0Bc8tpZ3x64lwhUmh+O8/4trmiiaT1yCSwjdFYKzV9gk7H+j5L0ymcPOWxWUOINDEmlttJUrAT
+3BhbWLlmX14E0xvSjzDFW3rxbhkOEREmNZjR1oYx+O12HgvJtjpQ5N49+E9nNbVL63+gnNaxfhu
f/FTj2th4PDsPHM6jusmmC4L32gvVo/YqOQwVECQwIFq6KognyFE0roVn0J85G2diYBStiO4m+mp
E5qf/c6OjAaYvlnMoOtawf79tESOGCeSIsM+V0e3ErLRxvK6+Z08PmFS2bN3sgGmVfYEBPNBWTe1
RRlGmTtki32ohj5U+Ta0j30oNrg4wkzqhm311e92lf2NYuARjOSTMJCtV9ialr5gQDPsH+b/rvJF
5UOjtWJoONowA5pmdvttb/Rp9Rv8AjPGmX5rgI/4beZneu+4h3c9R0VbhDgQGQtuPSyCETxNsas9
xSt741HLYcFhMpDHnHLwsGgiw+By4wvBDKvC4ls+xrNBdbyHspAgaSymm5M5sQJwbfAN13kVoAmm
12WRfUFW46zy45t/JyWkv6tf3mSPjzDA+VdVT+PlumrbbTBO7IjvpmtPpSu3UfH/6TbAdOQnzHKR
l55OIN02HXGnIXwjfDefvVa0LVG5kIkzZyZqExw2BFKT0SFZjn0RX1cvwnkFdcwPgJtQxdeJUKZS
WozHa6xvjmZ+2M78xL15n1Mspv5LgMzD1I+w7yHvF1+K723DeGqTHQO7PbbX8UHzLg6275zDqCqO
veVI2C46NKFNNH3w3RC+ZM3L8D4ZSnjuOYfjsCW+uUNakag9dv8BXj+mtg0KZW5kc3RyZWFtDQpl
bmRvYmoNCjU4IDAgb2JqDQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jlc291cmNlczw8L1hP
YmplY3Q8PC9JbWFnZTUgNSAwIFIvSW1hZ2U2IDYgMCBSL0ltYWdlNyA3IDAgUi9JbWFnZTggOCAw
IFI+Pi9Gb250PDwvRjEgOSAwIFIvRjIgMTIgMCBSPj4vRXh0R1N0YXRlPDwvR1MxMSAxMSAwIFI+
Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAg
MCA3MjAgNTQwXSAvQ29udGVudHMgNTkgMCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFy
ZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyA1Pj4NCmVuZG9iag0KNTkg
MCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNDIxPj4NCnN0cmVhbQ0KeJx9k09P
8zAMxu+V+h187JCW2knsJBLiwAYIBBIvVOKAOExoTCAG4s/3F263bt27dhe3dWP/Hj9JoLyF4+Py
ZnI5BTw5gdPpBL7yDAENIpK1GCBYBPYI3/M8eziCD/1t0JHXNS6IRuEE34tNFaIQ+p2yl6M8+5dn
cHYzAeggaQ/ZU7xiBkomMOgyYNe+GstaAM/LPCsvl7PFnGH6CX0kuyWN1yCkFNZzRkfUw2RskT4Z
sgyOTNRMaoo6WBnCun0sM6XDWB90rtWkDNKAfT1plxiGiH6fKNHLimi9pz5zCd3GXGxGFEy1iNDQ
t9g4hOXyevaxgOJtNr66Ha01nFZad04QjW5p9aKcBkEKcSY6zftgoVrWJ0pSBD1D5cW9erL4aVMX
efZY2NHYF1gHqkPzWUqpTy7C6Amqqzw7q3pUSUfIhs1srO2wHws41CMMTdY29IGMXpNoHLcN5VDD
2NtDVoZsexwUlXYctuBkx1+bdPeiZtVmvza4/8rup+8ay6fz39nr+8gVPx0Z7X7+R/PWGpEubVf9
gMjIJiYtIzFuaOY/qW/tbg0KZW5kc3RyZWFtDQplbmRvYmoNCjYwIDAgb2JqDQo8PC9UeXBlL1Bh
Z2UvUGFyZW50IDIgMCBSL1Jlc291cmNlczw8L1hPYmplY3Q8PC9JbWFnZTUgNSAwIFIvSW1hZ2U2
IDYgMCBSL0ltYWdlNyA3IDAgUi9JbWFnZTggOCAwIFI+Pi9Gb250PDwvRjEgOSAwIFIvRjIgMTIg
MCBSL0Y0IDQ0IDAgUi9GNSA0OSAwIFI+Pi9FeHRHU3RhdGU8PC9HUzExIDExIDAgUj4+L1Byb2NT
ZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFnZUMvSW1hZ2VJXSA+Pi9NZWRpYUJveFsgMCAwIDcyMCA1
NDBdIC9Db250ZW50cyA2MSAwIFIvR3JvdXA8PC9UeXBlL0dyb3VwL1MvVHJhbnNwYXJlbmN5L0NT
L0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1Y3RQYXJlbnRzIDY+Pg0KZW5kb2JqDQo2MSAwIG9iag0K
PDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA0MTEwPj4NCnN0cmVhbQ0KeJytG2tv20byuwH/
BwIFDlQR0fveZa5nIFactEVS+GIXVyA9GLIiO25tySfZTXO//mb2Qe5SXEry9UNkajWvnZ33MsXR
WfHdd0fvJz+8LsjxcXHyelL85/CAFKQihFDGiC40I4UUpFjNDw/+9W2xgJ8rwqkAGK4VfCpZF6ub
BosQRYlI0K6/PTz45+FBcfp+UhQRS7rBsgfZ8dS0rrQsAKyQPDxWTAJCMbs/PDj64X56M5fF62XR
x4m1nMaeEaG19vs0nNIenpIElqKuKJMFp5WBldoiRWxVji3fZCslrYfZCg37cjuVhbKMBe405qhz
HMUmR2WEchyZELRPuZTwRrnEblGRGoXQlnvL1uTYyqN308VNUf42Hf94NvIynFwA3htamAqO9OIa
+FgWFJjwynBYF5oVF/doUao2BdjQ0dtz0MnNOiy9PTz4WLLRWJQEPyh+2K9H6gj+ylKP/l1c/Hh4
cHrRI5WKBGl4S1kxFvH+WBZDNHRuZ4Gg0LQCNzEVl4HgoFCml4ZyCmlpDApVJxpmBdNVbVIdU6Uq
MHBUNQlK7nfbzeUPVu1ny9vFY0FfFu/PR6L8UIzGupzfP91NH2+XsLAoUP+/lvTXUSRqqmpWMRGL
sGVbNMQgUklj7YFr0IkpwGwrI+F3g3YKNiqauCIMGClvIDhHu00gFCMRDSM2SOCmQeZK1ww+jWFW
L541VzXai2ctZKWAfod5gHHMOzCevYdx7DsggRXjYJURK73JyYM0nPQmIwfSMNIbfJjWlWaDfALI
AB8PMsQH4mU9vJ8AMsTHgQzwoYZWUg9ZR4DIW4eH6LGOwITLygwrLYAMbMaDDGymBn/UcpBPABng
40H6+NDiS9bpwWl/KxqXggjCdXHf8DWmqmVxd3hwfnjQeFUD5BcSIK5tLvOuB0CaqGghhfIe0kL5
hQ6UM+8Iyi2kUN44Wyi/0IFyphVBuYUUyptGC+UXOlDuZCMot+CgGK58sdAmVZtfSNSmiUwPwC/0
6lZJ/BPp1i2kUN4eWii/4KA2AzHtJBjKkuQiIKTDJ5RFYD4Y2DF8giHZwBmeXRZ5P+Ll5O1orMrL
0RgeX52NZJIF4ozB67qCHYDmuPIJYzZ9AITpFWScW/h35/8++r9zJLrOkEMF0pTccP5hfQUDQ2eJ
N/uxfD1fz1bIGUV4gB0GcZajMSsXuXwIbgSOllAalof3yKOw/BVdea5vQYoF/LMK+QQPOR0rrro6
RskXfhcWf3U9nc1xK3kiEFPAjEE3tfBUrpdWJcUNnNdTkGT9mKNg6g0Kw8oQPcrgBjIpt3bDha9y
mMQCWwBxCEiE+SKnu+qsc7LEYvLJ6w73b8sc0KZy8qO9fcqZFxbLLGa+bQuyr/ZD9DqlMjn72Z4g
iHIFD9MFSPE7fKXSyony3l8FEVc5DROsJ/cRr69eVqyuOtIR5Nr5eDES0TfqnjJy1XBmah+59MDJ
S2hdqD/5WmHsqQmWcQxO2p18d7U/Ll1gNfsObd5+PxsUqLeGlwaKuligbduq+6INoZXSKRX0ZnTR
NURBaS3Snrs1j/w2cq4rGa2gx+IQRnjg8OXz3AUuT3V2B4wsk2nOuqRRVv8xmcHtMtJnXaA0cP9o
u9ipClNczMDOstFHO8eLsSzGsAB0wIyIbsNQR6env1w0z4NmwfrSh5DWzBMGw2L2BX1JsT1Jqdjz
+fMxhAE8vE9pAoCTXM1R9ptRPknKWmFVsYeAfYE4HGRMJRsAIC2jp+zOsS9u+pNjCmqrZ0T+ruMA
ox1OuC9CCoXddyTItt30hTPJgQhNiKBIuTODytjwPVj2BSx/ZDEROnxiu/PrC23hwKiqBO93tQvr
b+ejXbyN98UT9DZoGRIeg5LyvqCAJZ/RPZLeXkI9A0Hx0Zc462yQJXYoxAjD2tFRuPJhHKsMidtT
+PEyfONNTJ+i02KRTBk8zz7nIzlUchSykUa99kfy9TxXgElj80CCPayqvvAWjChW1TYr2v1w+EYb
UhGWzrm8VeG4izyvDpDWAnl5efoLqu7iEkvCyU8Xg5L1xUCc4kEgiETZtr++uCadzSRU7jEd2yrw
doQloICILsrrp5Eu72w7NWYKjh4rg0XXWnraNwntJNg3lVBr0F2SHnfGmBrT5nZ660fwBBxWxLyG
laK3H7orShMVETsgdp8vQCfN98EidI+zMsMtcbBDCB1M/f/5CEeupx8u8ftwFOyLtEKRippYli2b
E32xVBKCSSahsn7yDS/+s83u6hH7ElWuj0DpX+C59l3JCmOYA8kHMI0FHEVzDBxcwTJbjkz5B9qc
I/Y1R0HXmDYTCsM77Yv3PoglO90SxPbQLUsMB9hAwO3M6gnEcQbHxkNBtOes/jtCjD7u8XsJUS9h
xQzEvoTVx/KHBUYVTGx/e7DntUSdX83xYDHiQG1pJwN2KvAyoxcKZSRP6Q6rJY3tEt08FVUopxVh
Ku0owjZPTvu2mboiFEdEJ4h9U6jMNphtmmPc4W2I7jbgLNN9GOb2wRWWJoMbqbvHRQmaRoJbfsAd
zKFGmuYGE5RJO2iKscYbaUH0sOMQOGRXVMmOJf6hx2P8K94cg13gwoQQ8uYYHwk/Hhv8zRwr/AUv
Os3xWMfgQsCiPh6LFk7AV+7RGQkwyi0g8om05OUrvDi1j2ISuHtcTypIEKQMQkccrIBAXJwgI7fe
bOpVQg1lOFHH2mNy7tcsdxrjKYtTO8DeE+1ezPkjhTMKjvJlBYn8FryNl49zN4MycMK6vAazvbY9
HfTkWDrCL1x40LWFxGmQ7f6w65uDH1/bMhMBFs5QdHaAxRirUkmGbV3ubOuUB5J7m3qLWr6+tRFo
Pb26szkGjb74efIhZ/aKYv0VU+hafXw7KkUC+oT5aoEfKzv8UOWd5Q7F/ljY7598hc45TqUxOpKy
+LXMKVdoTMIti/3q0lzhwiRPJd/3Wjd7XcsgC6b6H7YGtdUaKDX2SKEE3NsauOqglu8nby8nF+/A
6i/P/oF5imDdi1PbMdYirgwm7pT6DAfwAehyYov8d7kbCEiZKmE7rAS9qxK4qZ+rhAjVKuEUdvPL
RVDCC2eRC1duyRA8VPnnozPRYM43dh7/woFwbtetsu7X+HiEjxCJhP/ugK6XED9WA1c2QUZtKtUM
8BhYKM7jqCHfZz2QV0QleBYl77HaDo0aeKSOnim/P7KvhRj7LceOMfvaR4ye48SYvZlIONVIW3+P
Cq3B+W3IXc9HtdfSW9Da2TdZkxIVS+kN25TZNcxyrEWfF2Yj1PJ05APf9Aq36cKedRk0pZ8nuNls
zMXS2STk8idoI1cMulekLdAKC6zhhoIuVD4RCxwma3shKTh8QoYIwbG77IJjrupn0L5Cg5EQ/qui
rqpEcpRbrKPutBObJ+wDjhSRcfS2B9mA06JuMQ4MRxenECLO7dTkDM+MdSPy9A98diHZnez9cuQf
29O39NYPWMLMEJbiLdwYOsBZzq8gExqTCDuoOUl21Zxgz9Zci7qD5s5th88yals/PSD2Q1hd2Sat
cYz10ZdiNXK5zbXLcx+qc80yl3UlWSLjsMLorgrj5NkKa1F3UJgdiUMsuLQak3F2shqb/j7iAQO+
o9aubcR4CLaGwA3W/dSXzmByLmtmFIfvEbBE1mHFdVv+rOKoebbiWlSruPsnHPd2A6nTAyuu0Mym
C1TF7+tQJHTszdYHtgpGzOzFPVPu+pbumM4k31RGtyUCF8bMQGBnJq+OBlyzHnB8F9i2j9CZMezM
To+xa4OWFjoz1wi6zo2FfpH7zhKxbJfKWzT/syUoXUvIfGNp2s7RgmjXI1LSEm+pacf9xNEQkYyy
R0bRkredpuXjUR0oNKWICG03H2g5Oxbj9MVq+85GuCdAW3AxOXY0Kssre+/rbIUWj0tMv8YDobXc
tCF8/ehjEZZCTfzxhidk43H4z4WwXGQCYzKphMNGJbZ6mLMpZnhDcncX8wqLcMv3t/b1ixv3xoX0
PnbbaMVGkeLLEnZsfeguSneLpS/Fr9wrJQFn9rvXVq5B96VjIsiwXuSuetH0+XqJcEuIx9QGWbCR
cPhT13W5jX4Fo1IQguxo8TOq5uu6KQdmFhRUNB+ZjqVIb0NWUbOg1rYzcQcAUuXKTS+sIlighu7p
FKz2mxf2aszJ8oADF6T6h5+qLL0kjgscKN880Jm36+n6M37/e+74bMJIJBg+vY2WOjMTxdkC2VL5
9w9FY8yBl0de2tkSY7l3T/z7BVSj2uDA3R3A1ndqePmP3FyDE4bVXCLfsLI2Wu+csjjDhPUcZUWY
4QJ40txT50YIlFG8wEuQh3eyc8PHmL3YGdhKn8e7jq+Dy5XLiTKeqdpp5qnLMLybGMMcF5IOw8Eo
FZiOcC7qRsBvfB40IW/WzRS2ZdCMY/2QmB3Hy2EsHLFyQ11kw+3vzdA1TGJF7b8w/0srRDMqdlIq
n71lPOfdJe5xQqtU+VsOtN51KsSIecaBugqwg8tpO2Lnye5ru91kFm9H99zN1u0xWFV0B+Z2JI+1
CQsKt6pjuOCKLA71DetcAcguf0/Rz/VVW1ZFNwENuzDxz47xB8dQtNb4NnXQSSsDbpJ37i+iywph
kGXrESfOpil1kiEY53Ep2Jn9ewtLRJbej2BVRzYekNuLBgQRbPvdxR63IHtcc+xYQ3r9GvgjvQ90
+oerdvBqf1kXkBnsk820Pl9j4zFdjaLGrplchuYWaDky9w9t4kXw+/niEVdyr7KxWuB/OEqEHHRU
RXZ1VKpFQ3Pf+W2MCyWIKySbObTXSa/2UkXZMmT9NG2LyLjC6vTCVuduplt8mkPuumraO1fA73Yf
6Dag7P8PbO4DuTcqH0u9pTfL3nqjm7E3sZG3PzeRumv4niBpDbh12r4QFjliN3w1DnKSBn7iYUKX
Z+l2k09fnqN0p5TBdKUSxW2xRLqzJUoaH8Z+lhjhJpV7t/dHG6LlbAW18PS/WNB9De8F42BuHkzT
efOiBehaMVTaUCP+5l6yR+v1lB9DG2VJhcgAZtvGi3Z80SW6l+kKgm+3Ngkhc7+85dL4L0oj1tbZ
K8eyW4ggVnzb/MqKE/tZyzGuoqhP38kYAqmhLNLVTRtZo3WYHc0Z/zepSrS5xZ7ZjtU5BUcJr0jm
zLm/Oo8x+6pzCK9s4C0PfPEopjC8nY23VXIlOqXPSRSuRI9xy/O59xU79KzLy9OfnMdBT+xczvWi
mc4Zr06wlW2vtaPZcetlwQfXn5d3dtqeHUWAiMKkIg6rbOc3Yyi0fsMqy3c1HVxbBLtaNyp7o1KM
p6VpKItep6+lRM6IPoLlbyiD2SS87OH9NC3rmpDxKs2RXTf3GZHTiHuTTzvse1i0L8tsabLEq6wM
EJyisnx3K60xh4TXipLBejsNiy7hZ+0AfjmSSeHiABauJslNcXTVYTlsdTu/o6Lrlua+jhrjlue2
ILPTz6M4ra0fl3a0NFYhl0nt56743Q0MMYHe39pJSme0mLuMYNzghWEiwoZK/geeLqEoDQplbmRz
dHJlYW0NCmVuZG9iag0KNjIgMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQgMiAwIFIvUmVzb3Vy
Y2VzPDwvWE9iamVjdDw8L0ltYWdlNSA1IDAgUi9JbWFnZTYgNiAwIFIvSW1hZ2U2NCA2NCAwIFIv
SW1hZ2U4IDggMCBSPj4vRm9udDw8L0YxIDkgMCBSL0YyIDEyIDAgUi9GNCA0NCAwIFIvRjUgNDkg
MCBSPj4vRXh0R1N0YXRlPDwvR1MxMSAxMSAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIv
SW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAgMCA3MjAgNTQwXSAvQ29udGVudHMgNjMgMCBS
L0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1Mv
U3RydWN0UGFyZW50cyA3Pj4NCmVuZG9iag0KNjMgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29k
ZS9MZW5ndGggMTQ1ND4+DQpzdHJlYW0NCnicxVhbT+NGFH5Hyn8YqS/jFZnMfcar7UoQWMSqqJSk
24fdqjLEsGmTeGsnIP59z7ET8DixifLSBxx7fC5zvvnOxZDBNfnwYXA1vDwj/ONHcno2JP/2jjjh
jHMupOSOOMmJ0Zzkae/oj3dkAa8ZV0KDjHIWrtbEJH940eLcCq4Dtft3vaPfekfk/GpISM2l2HK5
Q7ny6UTMnCEgRoza3DJpQIHczXtHg8t58pAacpaRXZ7kq6f+2hEXsVvH6ZUQO3wavnGpYyakIUow
DytxqVRza9vcqm23xoi42612EFcVqSG2dKwx0sCjbnOpt11ar23lUmotdqEruHpBl5cxWh7jLlzp
/tWvb3NrBr8kiwdC/076n6+j9R5Ox6D3SRDP4EzH9+CndCHAiWJewbp2koznSCkbewIkGlyMAJSH
YrN00Tv6SmXU15TjReClfBzYAfwa6qI/yfhz7+h8vGNXtraRF9/GMClrvr9S0mXDtUW2MaidYJAn
nimzMei7DPqdNmwFyKuNzk3FAcKSSMdiG0AsrGVAcO0tc26N8e603V6+KVG/zqaLJYn6ior35GoU
KXoDT56m89UsWU6zBUH8v1H5LaptNYRaMqnre3gjLMGDuDSRgsU+5E7MLNrUihld2fzAuXcfwy2U
oEBoNlQGnJQPtel5nmeRpXlLEM4xz32o0m+RhUBj2ZCdRoYu7jMSCVndL9Mcfu6Tu7TFihSexSa0
0g2bCGAzBAw0UNOmgg3KqHpB7fR8B2rCB4rWM4nhvyrSE7IEMuTJorhP8YbMor6lyXPaBqGEYgJZ
XbfRHY9s0ECYJr29YFZ7omI4HdlNg23lON5Spp8iDcej6Az+MLw0B3oLOK5s0RKVcIY5FVppI4bw
ksUN2dENuDn5dTCK+o7eYJ6d4ApmnKe3yeKfosWYUorphrFuPNXeeEIdcofC+apLx8iOGUCaLFMg
O8QkFf2eFcvqwdNkMskx5LQAoQLfixL2DG/pwwrWTblQnUIo3oKLlhKyO9hHNyx6b1igZxh/KC41
ZXoG+09nEBty7THN37cRxioGHT/Q7Q7GNINRTMmwJQgH5R3oY6EWvBGMbrZsoUxTmZ4/JhDODPm7
SjBvUqhyjiYLuJ+QKKaTFE+zFJji5RGzSni6/J7i6zkQonwuUniDomjAQu7lWfkIT5wuM/IIgN39
WPG2PgN7DTZG2lBdBwH1UeyXOXbfyipjGCsOqaw1RXoFwA0v/hqNT8a/j9piiBWzIlDrDsHty3Lp
YAo8tJjWlenpdJ29Fk9R4eW9ItUJYwan+WM6OcZU5/SpXJ6DcIElV0pafAeRbDWbYO5regukAO4U
yRyM4r1QNMGSAT17Mi+VQCoDToFa/oTWMLkKfKwKz8X1Ty1gWsWZCffexp1NnDDT2L1w93tTR8YH
UudVsaJOmWRv0Mdr7Fp11e4w4h30acSx4Q93+zSP5jwXN5XpEDtHmpSzBTaL22dSsWQK68uyUWsK
M3lJBV4cVwftgErTJUxyL2+BXaIgd2hohf0EuGdpxbGLaxBqY4XWcMY22FKTFZ25IGAO3K9qS74v
SbAhCH8IS+qadZqcnJ3hh9TN4AqgWa9dAUCXo2HbHGcNfCyEBrvDE/vWHqHFwYNHTZeeYyFZYYOt
Jg+sIVJv6kUye0qei6pgYI1A4R8zLBR4ly42sx9qKQffNgusRCjPq1ozgOdNweqvKxYIQoEhVZOD
NSxwKxyMv0XHJd8664mAocVsBmucDvAP58AvcC6aXqLZ0fALpsHP5ScweuTVfmHGehmuFhlJJrin
ST4oE+A+a2M3hwqgA8fdh7j3NC64wAHswFOsKUMFwENJ8gr62+dyGEDgq3PDQ8LfqgYY/N8AtI3j
zXC5KRYNQUBJlILkDpYSKAnrgfKtLrGuB8EOuyHbe+D2nEl1aM+tK/+vI3ewkS1k/gMc9TgFDQpl
bmRzdHJlYW0NCmVuZG9iag0KNjQgMCBvYmoNCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0ltYWdl
L1dpZHRoIDk5L0hlaWdodCAxMTUvQ29sb3JTcGFjZS9EZXZpY2VSR0IvQml0c1BlckNvbXBvbmVu
dCA4L0ZpbHRlci9EQ1REZWNvZGUvSW50ZXJwb2xhdGUgdHJ1ZS9MZW5ndGggNDQ5Nz4+DQpzdHJl
YW0NCv/Y/+AAEEpGSUYAAQEBAEgASAAA/9sAQwAIBgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0a
Hx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIy
MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAcwBj
AwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMF
BQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkq
NDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqi
o6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/E
AB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwABAgMR
BAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVG
R0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKz
tLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A
q2jaZpvhCzv7jRba/uLi7liLTSOu1VVSMbSPU1W/4SHSP+hR03/v/N/8VRef8k/0r/sIXH/oKVz1
fTQgpXbvu+rPmpzcbJW2XRdjov8AhIdI/wChR03/AL/zf/FUf8JDpH/Qo6b/AN/5v/iq52ir9lHz
+9/5ke1l5fcv8jov+Eh0j/oUdN/7/wA3/wAVR/wkOkf9Cjpv/f8Am/8Aiq5+OOSaRY4keSRuAiKS
T+Arp7L4eeI7uITTWsdjB/z0vZRGPy6/pUTVKHxO3zf+ZcJVZ/Cr/Jf5EH/CQ6R/0KOm/wDf+b/4
qj/hIdI/6FHTf+/83/xVaf8AwhOiWpxqPjTTY2HVbdfMx+OalHhrwL0PjNyfUWxx/Ks+el0v/wCT
GnJV62/8lMf/AISHSP8AoUdN/wC/83/xVH9v6K3EnhGw299lzMp/Pca208BaJqB26T4ysZZD0SZd
hP6/0rH1vwF4g0KNpp7Pz7ZRkz2x3qB6kdR+VOM6Ena7v5tr8xShWir2VvJJglj4d1s+Xp1xNpV6
33IL5w8Mh9BIACp/3h+NYd9Y3Wm3klpeQPDcRnDI45H+I96rdR7V1NnK3ifQpdOuDv1PToTNZSn7
0kS8vET3wPmH0IrV3p63uvyMlappaz/M5eiiitTI6C8/5J/pX/YQuP8A0FK56uhvP+Sf6V/2ELj/
ANBSufVSzBVBLE4AA5JrOls/V/maVd16L8hACSAASScACtKxtbKC7P8Abi3sECpuWOKLDynP3QW4
A9+a1dS0eHw//Ztk37zXpJY5pgW+S3B+7GfUnIJPatrx3aeItX8S6TY6rFYRXc6eXALd2KHLfxE9
OazdZNpLZ319OxaotJt7q2nr3MY+NZ7GJrfw9YW2kQkYLxr5k7D/AGpG5/LFc/eX95qEplvbue4c
nJaWQt/Ou0/4VF4m/vWH/f4//E1X8K+HJbD4jWmka3ZRscOWikAdHGwkEdiKmNWhFOUGm0r+Zcqd
dtRndJu3kcUAO1LXdfEPwhc6VrL31tbwJY3cyxW0EH3t20cbQO5BpIPhP4mmsxOy2sTkZELy/P8A
Q4GAfxq1iaXIpt2uQ8NV53FK9jjbSwutRn8iztZbibBbZEhY4HfArpfDnivxF4XupIgtxPaQHFza
TAkIO/X7prV+GFncaf8AEKS0u4WhuIreRXRhyDxWD4qvri28Wa/DFJtjmunEgx1GamUlUm6TSatc
qMXTgqqbTvY6Tx14d06+0SDxfoKBLWfBuIlGApJxux2IPBFch4UuTa+LNKlHT7SiMPVWO0j8ia77
wdmb4Q6/Hccwr52zP+4D/OvOdA/5GLS/+vuL/wBDFRRb5J03ra6+RdZLnhUWl7P5kOpQLaareW6/
dindB9AxFFTa7/yMOpf9fUv/AKGaK646xTOSWkmaN5/yT/Sv+whcf+gpV74a6bFf+Lo5rhd0NjE1
ywPcr0/U5/CqN5/yT/Sv+whcf+gpW78JJY/+Enu7SQ4+1Wbov4EE/pmuWq2qE2vP8zqpJOvBPy/I
5WS/l1TxSL6ZiZLi8WQ/i4wPyr1Lxx/yU7wp/vL/AOh15Nf2lxousz2soKT2sxHPqDkH+RrptW8e
DWPEWiaxNYlJNPx5qK/EhDZ+X0/GlVpOUoyhtZ/itApVFGMoz3uvwept+Prq5h+KOnrFcSxr/o/C
OQPvntXTa0B/wuPw+ccmzfP/AI/XmXiTxXFr3i221pLR4Uh8vMTOCTsbPWr+vfEB9R8Wabr1haNb
yWUezy5X3B+TkcdiDisfq9RxirfZaN/rEFKTv9pM6OELc/HaWKd2aONi8aMxIDCIYIFWtbuPDlr4
3k1C98Vahb31tKpNuEOxAAPl6dCP51yniHx/Bqt1Zajp2krYapbzCVrnIYvgY2ngEj61qP8AErQb
6SO81TwpFPqKAfvAVIJHTkjP55qXRq+7Lle1tLf1qUq1P3o8y3vrf+tDe0vV9K1z4sw32kzCZG05
llYKV+YN7+2K8/1nRr7XviJqtjp8DSyvePk4+VBnqx7CmQ+NJ7Txm/iO2sLaAvkPbJwrKRg5Pqeu
fWr9n8QrzSLrWrqzsFjuNVmEyNKciIc9Bj5uv0rWNGpTd4LolqzKVWnUVpvq3odH41ubTwf4HtvC
VlKHup1BnYdducsx/wB48D2rzbQP+Rj0z/r7i/8AQxVW7vLi/u5bq7mea4lbc8jnJJq1oH/Ix6Z/
19xf+hit6dL2VNpu7d2/UwqVfaVE0rJWS9A13/kYdS/6+pf/AEM0Ua7/AMjDqX/X1L/6GaK3h8KM
J/EzRvP+Sf6V/wBhC4/9BSsnS9RuNI1O31C1bbPA4dc9D6g+xHFa15/yT/Sv+whcf+gpXPVnTScW
n3f5mlRtSTXZfke0XWmaB8U9OS/s5xZ6vGgWQdWHs6/xD0Yf/Wrg9T+G/ifTXbGnm7jHSS2YPn8O
v6VzFrdXFlcJcWs8kE6HKyRsVYfiK7jS/i34hsUWO7S3vlH8Ui7H/Nf8K5/ZV6OlJ3XZnR7WhW1q
qz7o4+XRtVgJE2mXiEf3oGH9KbHpWpSnEenXbn/ZgY/0r1OH41QFR5+iTBu/lzgj9QKkb41WOPl0
a6J95VFL2+J/59/iHsMN/wA/PwPOrTwX4lvSBDot3g95E2D82xXTab8H9buSrX9zbWadwD5j/px+
taF18ablhi00WJD6zTlv0AFc5qPxO8UagCq3iWiHtbRhT/30cmi+MnslEdsJDq5Hodp4H8H+EYVv
NVmjmkXkSXrjGf8AZTv+teYeOtZstd8UTXmnbjaiNI0LLtztGOB6VgXFzcXkxmup5Z5T1eVyx/M1
FWlHDuEuecm2ZVsQpx5IRsgrQ0D/AJGPTP8Ar7i/9DFZ9aGgf8jHpn/X3F/6GK6J/CzCHxINd/5G
HUv+vqX/ANDNFGu/8jDqX/X1L/6GaKcPhQp/EzTu9W0PSvh/pba3b6hMkl/cCL7E6KQQqZzuH0rn
v+Ev8B/9A/xF/wB/4f8ACmeOP+ScaD/2Ebr/ANBjrzSvBr4mrCrKMZWVz3aGHpTpRlKN3Y9O/wCE
v8B/9A/xF/3/AIf8KP8AhL/Af/QP8Rf9/wCH/CvMaKy+uV/5jX6pQ/lPTv8AhL/Af/QP8Rf9/wCH
/Cj/AIS/wH/0D/EX/f8Ah/wrzGij65X/AJg+qUP5T07/AIS/wH/0D/EX/f8Ah/wo/wCEv8B/9A/x
F/3/AIf8K8xoo+uV/wCYPqlD+U9O/wCEv8B/9A/xF/3/AIf8KP8AhL/Af/QP8Rf9/wCH/CvMaKPr
lf8AmD6pQ/lPTv8AhL/Af/QP8Rf9/wCH/CtDQfFfgmbxFpkVvYa+Jnu4ljMk0JUMXGM4HTNeQ1r+
FP8AkcdE/wCv+D/0YtJ4uu18Q1hKCfwnouu/8jDqX/X1L/6GaKNe/wCRh1P/AK+pf/QzRX0kPhR8
7P4mZ3jj/knGg/8AYRuv/QY680r0vxx/yTjQf+wjdf8AoMdeaV83iv40vU+iwv8ABj6Hfa54c8I+
GZE0zU59dfUWtUm+1QJF9nZnQMNqnll5xnPY1zmleDvEWuWMl7pmj3d1bISDJGmQSOoH94+wzXov
hXRfE9xaxaH4v0V5vCwhZ1vrrH+gLtJEkU2eB0+XJB6Yqo2j63rum+Brnw1HPPaWUPlSSQNhbacT
MzM/9zIKtk9RXOdBj+E/h/LqvhvVNdvtN1G4htwq20NrIkZkYkhySwOAu3kY5qldfDTxHbeGrLWh
ZSPHdSFfKUAtGMqEJOedxbAx6V0WuXdrd6V8SrmwkVraXVbZo2jOFYGSTkexrLuYL9/hP4dvrGCa
WOw1C7eeSJSywnMRUvj7uccZoA4qbT7y3uLmCW2lWW1YrOpQ5jIOCG9OeKu2XhfXNRezSz0u5ma9
R5LfYn+sVThmHsDxmvabuS207V3RyiQeObrLdOYXtwAf+/03/jtc9daDDeeIodAuori4n8P+Ho8a
dbS+W91cHDvGDgnrISQBn5aAPPZvB3iO31qLR5dGuxqEy74oBHkuv94Y4I4PPtUw8CeKG1ZtLXRb
lr1YhM0agHahOASQcAZHc16tZxtbw+GI30qfSHTS9ZAtJ3dnQeXkHL/Ng8kVyfgWOLUfh7rmnR6X
dardm+gmksrS58qZ4grDdwpLqGPIA7g0Aee6lpl9o99JY6jay2t1GfnilXawq74U/wCRx0T/AK/4
P/Ri1tfEK6u5b3SrW80SfSXs7FYEiuLjzpWQMxUucAjrjBHQCsXwp/yOOif9f8H/AKMWgD0XXv8A
kYdT/wCvqX/0M0Ua9/yMOp/9fUv/AKGaK+sh8KPlJ/EzO8cf8k40H/sI3X/oMdeaV6j4xtLm7+HO
hC2tppiuo3WfLjLY+WPrivO/7G1T/oG3n/fhv8K+bxX8aXqfR4X+DH0K/wBpnMHkedJ5PXy952/l
SRzzRI6RyuiuMOqsQG+vrVn+xtU/6Bt5/wB+G/wo/sbVP+gbef8Afhv8K5zoKgdgpUMQrdRng05Z
5o4niSV1jf7yBiA31HerP9jap/0Dbz/vw3+FH9jap/0Dbz/vw3+FAFVppG2bpHOwYTLE7R7elKZ5
TN5xlfzc537juz65qz/Y2qf9A28/78N/hR/Y2qf9A28/78N/hQBXkuriWTzJJ5XkxjczknHpmmxS
yQyCSKR43HRkbBH41a/sbVP+gbef9+G/wo/sbVP+gbef9+G/woAqO7SOXdizHksxyTWr4U/5HHRP
+v8Ag/8ARi1V/sbVP+gbef8Afhv8K1/C2kakni7RXfTrtVW+gJJgYADzB7UAdxr3/Iw6n/19S/8A
oZoo17/kYdT/AOvqX/0M0V9ZD4UfKz+JiWfiHWNKhMFhqd1bQk7ikUhUZ9cCrH/CZ+Jv+g7f/wDf
9qKKPZwerSBVJrRMP+Ez8Tf9B2//AO/7Uf8ACZ+Jv+g7f/8Af9qKKXsqf8q+4ftZ92H/AAmfib/o
O3//AH/aj/hM/E3/AEHb/wD7/tRRR7Kn/KvuD2s+7D/hM/E3/Qdv/wDv+1H/AAmfib/oO3//AH/a
iij2VP8AlX3B7Wfdh/wmfib/AKDt/wD9/wBqP+Ez8Tf9B2//AO/7UUUeyp/yr7g9rPuw/wCEz8Tf
9B2//wC/7Uf8Jn4m/wCg7f8A/f8Aaiij2VP+VfcHtZ92ZbyPNI0sjF5HJZmJyST1NFFFUQf/2Q0K
ZW5kc3RyZWFtDQplbmRvYmoNCjY1IDAgb2JqDQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jl
c291cmNlczw8L1hPYmplY3Q8PC9JbWFnZTUgNSAwIFIvSW1hZ2U2IDYgMCBSL0ltYWdlNyA3IDAg
Ui9JbWFnZTggOCAwIFI+Pi9Gb250PDwvRjEgOSAwIFIvRjIgMTIgMCBSL0Y0IDQ0IDAgUi9GNSA0
OSAwIFI+Pi9FeHRHU3RhdGU8PC9HUzExIDExIDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdl
Qi9JbWFnZUMvSW1hZ2VJXSA+Pi9NZWRpYUJveFsgMCAwIDcyMCA1NDBdIC9Db250ZW50cyA2NiAw
IFIvR3JvdXA8PC9UeXBlL0dyb3VwL1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQj4+L1RhYnMv
Uy9TdHJ1Y3RQYXJlbnRzIDg+Pg0KZW5kb2JqDQo2NiAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVj
b2RlL0xlbmd0aCAxNzg5Pj4NCnN0cmVhbQ0KeJydWNtu4zYQfQ/gf+CjXNQ0h3cVqYHEuWAXmzbd
uOjDbrHwOk7qIo5TO1tg/74zpGSJtiS7ebBkUXPhHB4OZ8SGt+z0dHgzfnfBxGjEzi/G7J/eiWCC
CyFASuGYk4IZLdh63jv54wf2jK+5UKBRRjmLV2tytn7caglhQehE7eGH3slvvRN2eTNmrOYS9lw2
KEefDnLuDEMxZlT5l0uDCmy27J0M3y2nj3PDLlasyZOsPA0KRwJyV8TpFUCDTyNKlzrnIA1TwD2O
5EGp5ta2uVX7bo2BvNutdhhXjNQwGxxrirTu0bV51Pserdc2epRaQxO4INQWXBFCtCKnSbjgvXLr
29ya4Yfp8yPL/p4O3t/2izmcT1DvCpjnuKSTB/QTXAA6UdwrHNdOssmSGGVzz5BDw+s7xORxUw5d
904+ZbI/0JmgC9AlPA7tEO8mc/0/2eR97+Ry0jArW5vI1rcxXMqa708Z67Lh2iIrDWoHHLeJ58qU
BvMug77Rho2AVDY6J5UnCEsmHc9tAjFYy5Hf2lvuXIFx867dH/4YUL9dLZ5fWX+gMviJ3dz1VfYR
n3w2X357mr4uVs+M8P+cqc/92lRTqCWXuj6HA2GBSOLSTALPfcqdnFuyqRU3Oto8FcK7UTqFAAqG
ZlNlxEn5VDv7ZYWhsb7JnlfPLYHkuOO1T9UGLbIgPAeXyk7XaH72F+uDyxb4d7P5Nu/rbIMDPps+
4t/pou+zNvfSA5cqNdmNIyQ4Ggae78CoTcQR06rawnh+2QAj+ETRei6FrytmV6s1e5guF8SHJ7p8
b8PGeJ6rRLcVRuu4yBPR5eoeV2qOHiSGDzILDissBzZbr1ZIWZc9rFdLhoIumz/2bTadfWcva1rn
WZDdrNabNs5qyXEP1v12Qy13KAtmdyvi6llkj8od97KdsjWyNYhLN9J4MxJ/gCtl8e4wpavRwOG4
xmet6XTBu8fxq5E5ja+B/ugzfOfjO2PDO+NGqi5iSESOBjQYRKMJXXgBexpdhymEwWCqFCfPRhUz
GNMr8tbEpz2AVC6RjEnEB0BXR4OOidV1p4l93XIFKt3sOpLsFTdvSILEJjyFvs7xCXS2LKlFj7jV
py/Tr4snZN4CX7zij+7zTRRQIvt3MWXEzpvx9Zcxpdiz2x/jS8wCRGEk9uzl2wIt3LcRFYsRm8yx
GzLdcOyUIOGRaPxRVsyxiUUpycG/JbPUNUNqoX2vad+3JxUPqVp7VgmnYiK7eSHrM7yEfPKwoEQy
C+kkSTBtyTk3eIKmJrsxtEeTF/A89m9lb02ZSibKmTYQFeHEp3Y8reZKpfqteGLtY3ZkNy9z2g20
PYj1DwFEwlNZfCAon3D4vhVP5znWIInJbjzdLp6KK5kWQ+CwsMGlAu46MnDAU+8Wq6DMrnJ2QwiO
rymyLxjQePIBj+/hDQI8XuCGdhkOtIUnODYAibXu8PzR4TlF5dYbw6spF+HhwoEI8d1Nzia/37H+
rj3dYE9iXqIA08mcw1GTkVpQLZ1MZtdtJauxVWmY+N3414tQWWHimFNyDYUAjuSBmzgwW9DIwwJZ
qbBEWK9X67BBZqTQ7E27nHvbPrP9ddut0WFn0YwKuBsXQDhsUO4Wx615Qyo8FOwb80ZdObvCxSds
VDyatsfV5AOSXQeytzPdYx4xqb3uAOFopuPtUF5sJXqlG04XKiT3t3M8jaXL7hcU+Gb69YkOBDzu
pckCe/CQBsCDnJTwMJfQYOXLbd9FMz8z0UYs+ragk2l1o7RXcLahBHm9tv9/KNV0d1CqskLH0svw
PaFupDumvXquca+AVxzaU0r9UNqTVjbWz7GM1uN4oxr1siqDQyWtq9L3KkiVNTaWUKE4DrW3bUJT
7iUz6+rzOICCPg4F7IykPR6GVFxiaa7zImTqC2Iv4MMI1uux/A/dRdVBlB1GqO2py7gYDYLaOAjo
snswo0EN3RLrwui2VTHRVyJUvjRlmzMayDr0qrBRrkiQDB2JiR5ssXS1abtWL0HQxmeSPjf11mak
GgzQlzsVPBas2GIliq4KtnM6L0z7Q9GGeUA051IahvZpHBdnz3eBe9HaFVw+i60YxFsBYB2egNpZ
rUOLUDU3aSn1rM2JRHUuHeCyaWg3SgIb4Pqo2kceXSoDVR0dtc/OIbcjLvOquTYVW2n9FH02tREw
LSmP4M/Rp9R4Vz6OkbwSBZdIiQZJUcm4KYoGvuQGiLCyxWKF9Q8LpqvOu+rMbWytdbFLIzUCH/Ji
ZnbLqzAJXTbkJqUCCeTlZpaxuT+ySTd0qKTIHVi8o+tygKRXbDipmgrN8qRKlVXxYQQBijkhpPgQ
uYQqvcc8dRW3Ib6DPGaZuESRDXGl4kK5iFdMmfVPKWEbHVXaxr6mPt19/P4D8pwsBQ0KZW5kc3Ry
ZWFtDQplbmRvYmoNCjY3IDAgb2JqDQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jlc291cmNl
czw8L1hPYmplY3Q8PC9JbWFnZTUgNSAwIFIvSW1hZ2U2IDYgMCBSL0ltYWdlNyA3IDAgUi9JbWFn
ZTggOCAwIFI+Pi9Gb250PDwvRjEgOSAwIFIvRjIgMTIgMCBSL0Y0IDQ0IDAgUi9GNSA0OSAwIFI+
Pi9FeHRHU3RhdGU8PC9HUzExIDExIDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFn
ZUMvSW1hZ2VJXSA+Pi9NZWRpYUJveFsgMCAwIDcyMCA1NDBdIC9Db250ZW50cyA2OCAwIFIvR3Jv
dXA8PC9UeXBlL0dyb3VwL1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1
Y3RQYXJlbnRzIDk+Pg0KZW5kb2JqDQo2OCAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xl
bmd0aCAyMTczPj4NCnN0cmVhbQ0KeJydWVtv28YSfjfg/7BAgWJVVNTelwwCAbFiGy1iwKcx0Ie0
CGiZknUiiT6iHDf//szMkjIpkbSqB9Hk7s7t29mZ2TEb3bL370c3k98+MjEes4uPE/a/8zPBRCSE
kEoJz7wSzBrBNtn52Z+/sDVMR0JLA2u0d/B0NmGb+Y5KCCeFaZDNfjk/+8/5Gbu8mTBWEykPRLYQ
B5leJpG3DJYxq6vXSFkgYNPV+dnot1U6zyz7mLM2SepV0rAUJGTiSztjLWWLTCsqkSaJpLJMyyiG
kYSIamJdl1h9KNZamfSLNR7sCpZa5kiwQUvrEn2XRHMo0cXGBYnKGNkGrhR6B64gE51IUAlP0l/F
xl1i7ehTup4z/t90+PvtoNTh4g7oriSLI9jSuxnIIREShOgo1jBuvGJ3K/Qol8QMfGh0/RkwmRfV
0PX52ReuBkPDBT4kPuhz5Ebw13I/+Jvd/X5+dnnXopWrKbKTbW2kVE32F876ePguyyqGxssIjkkc
aRsYItZGO3Y3/cKl6OMdt7GLVQQHqs6OOPUqmTQQV0z5KHENyGWSRDH4sYoSWULefogPh/+gTbjN
F+stGww1V+/YcvE9Y6vBUPHFfJNuF/m6pl0DbakjYety37BEioYpBhQHvZuWgFOCKVZHzgeW74WI
/bipAcIgm5TaRXHcpORLdKIFPtAiepkPNEej0NZ8zQblfFE8ZwPD33VYqpTEfWsw77dUNiy1TLo9
S8FTyVLQW+idpReXbZba/Q33PnJxkxjs0HyGVhoO24bbt4WRDHZVST7b5HiwVjACAzH/QM+/ACHH
080cV+NKqfl9uv721wDePdHnSM8v4OlgeQF4IY90iYQ4VRF0AGeci6xrKtoPnNp3EbMfYBIZSTg+
RonI6Dd85IBYQuyTtkHMX8AFpEBv8eHBBsrz61u0+Sc2iHm6BVDZANYAEIa/PGboPmuWAhzTaYYI
FQUbaMtv8H0S+H2FpZO7Tx3IaCci2dSjHxh9NDDCRlp2A7MPRXO5+iiEMWMLr1aCQ7rw6iDD6LEU
+K5xBfz18BfGzUWY0/U5W85fjYdEP6E1Spa8rApzHr8TeI8Dj6TkQfS4xoZ1OI5rrBgPUU61FudL
3rLiTfITUhtJpArsTBxISbwP7MN4UA3Xa2CvEARYoz4E1Y0am2oIOGsdhsXVThPt3jekkuKTYJzx
tAR1VR8CNa4W7ihvxUwNibK+RW94iWnxEtfqJjoBB3wrxh5Sl15Tp+YXEBKeMVqwCwoLUvJpCt4P
8VUqCLNLjD0/KPbA1Gb0QuNFvspo4GZCyQZP3lc4UZOB53Bs8MRpiE7wMsPzl23oBGIYdxThDN9m
XWHHWAiQTSXZ4F/EB+0tprZjELdH5jQNdWZyUk6rU/L0CQx/wiyWp9PH/YSFFdkeE5AN5UaTSb9F
7sjcpbWK9Km5q07Mr8CmfINBlfJStsF0pfimY3uliaGQbbIYdq21Diu4xlpMlesZpTYI2Z//AOlF
V+bXNrKmSd6Pnj82TmvA1Z+awOrE/ClfIGzr7RLPRlYUCB6dnm3O7uGQJXRsYjw22+yhy9QYSkLX
5Lx/aPa1EDJyxwWm+EinUrGJYnmiU9WJ952KNn0B8QUD1c9P5F85zt5TjaTecgQjI6OaEvotTo4O
xcoBmvGpobhODUZDzbah+BrC6vVXGJl8uO0yC1JLkjR59JqlDmp4wGUv4HhSCzY0dm8YpZqUELb3
KPFCCBt4D/uWrmF7vhVgzq+UHIZQpK3RXPL2a3zewudPLERHLOvv4W2JuQOZrLDan6bP8CyyB6x2
PS34waqlQQLOWOL8DL/VPaQ0ou+KRlCDRMo0te6HUB4LoYGb1UkIvhLyz5go4YcXg2X5C8YX6fcK
mxG8bDKMHsUW8AnRl77ZyyNeI6jgDbcHj8HEVzep7FeCb5qviwUg9VAt3iwQzHkgAWGzZzp6hkAt
WSMvdE1briHCf7YV4CivWFTqdN5CjcE7f93kfvQPbhhd6CvImOYk+GuUgMxqBWaTbz1UCC7LDVlX
cNEo2YneW+1XaXg5va1G4OKhd3tJI1BRDROePsA3bc56h/srEYJuwv5uFtPtwL1yfWyoUWpcEw7R
pL5PRbZleFwaq+Y778DSbPrYauFTdV7psezYUhf7KE6aMPbv6dGXIwW545hQ2x5pa8T8qgqzLVe+
GMJWV7x1kZRNTv2mHVT0Xe4KufjEeFujpHABcUH/+7ggWwND6StVoJWhBfNc0RJbco0iZ9+yDEnQ
SVhROVhwHnTX4Ma4toPFfTU0C3l/Z0I6Kw9VCE2MNquu7KJi3xVlnNfYM21A1b9vB/eCLpeU4O09
1/Vej6zR7jnkNSJZ+uPoBsybwG9BA/By9wl2R0MwXtN1akZNMKgMCWCZ1DoeKV3eyrYIzDwtsZii
eUB51ZUToV52De36wXJHOrmEbfBvHd9WJ69TAkSaEHKAEDjE5A7N/xSsh0oQwzTGriLFumNXQHQW
znDFgMK5IaHf3IM7Qpe5TkSx6jPXdJnbpNRirMsmhplgTwPfQwND+/BXXYXeB7ZS1K5PEtooE2qB
ULPnclx2PULvxtOMVTva0PUw1LYh2itaUc1IE6RdIPfWJkjTHKy3m9Z030lKyw0kj+OyxrF3Eqlp
f066ktRo+STEzzW2MuAQTdMCXetdmVfR0zRdU75nNL8qP2vtXPzEtvVQS/7yuKAyQFet2+83k0tq
1+bT6TMG7s7uiMKmbF2zfpzabjLtoQxgODW51mh5ep9vIG2ATa/3VgpRnf+LUDLG/zrVmfTapA+u
MZ02CYG9pBONqhHzdb4N0fZHCK4JXM9zurIX8BVjBsSIu32k3ha1xqgpBq9K8Hm+ZThRQiMg72EZ
uH0uaPrn0FvL0qITIziVEXpzXacDkP4PSmk7Wg0KZW5kc3RyZWFtDQplbmRvYmoNCjY5IDAgb2Jq
DQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jlc291cmNlczw8L1hPYmplY3Q8PC9JbWFnZTUg
NSAwIFIvSW1hZ2U2IDYgMCBSL0ltYWdlNyA3IDAgUi9JbWFnZTggOCAwIFI+Pi9Gb250PDwvRjEg
OSAwIFIvRjIgMTIgMCBSL0Y0IDQ0IDAgUi9GNSA0OSAwIFI+Pi9FeHRHU3RhdGU8PC9HUzExIDEx
IDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFnZUMvSW1hZ2VJXSA+Pi9NZWRpYUJv
eFsgMCAwIDcyMCA1NDBdIC9Db250ZW50cyA3MCAwIFIvR3JvdXA8PC9UeXBlL0dyb3VwL1MvVHJh
bnNwYXJlbmN5L0NTL0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1Y3RQYXJlbnRzIDEwPj4NCmVuZG9i
ag0KNzAgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTE0NT4+DQpzdHJlYW0N
CnicnVbfT9tIEH6PlP9hHtdVs9nfu64QJwi0oioSd43UB3oPvmCSlGDn4gTKf3+zawfsJDYcL2t7
vTPffJ9nxgPDKzg6Gl6OLs6AHR/D6dkI/u33GDDKGONCMAtWMNCKwSrt9358gAxfUya5wjPSGlyN
jmE1fbZizHCmGma3H/q9P/s9OL8cAdQg+R7kAeMS0/KYWg14DLTc3lKh0QAm9/3e8OI+maYaznI4
hCRekAYVEOOxrXg6yfkBTM22kCqmXGiQnDrciYNRDda0wcp9WK153A2rLPIqmWowAVh5pnVE24ao
9hGNU6ZEFErxQ+JyJp/FZYGiYbEPwgb0F1jXBquH35JsCuRXMvh6FVUxnI7R7jMHR/GTjm8RJ0Bw
BJHUSdxXVsD43meUiR1gDg2/fEdNpsV260u/d01ENFCE+YX7JTwOzRCvmtjobxh/7ffOxweiMrVA
nrG1pkLUsK8JdPmwbcy2DpXlFMvEUalLh15rJQ2MJ9eE8y7f7pA7JygWVN1d8NQZZNxQXICwNDYN
yQVTlFv0bqi1leaHq3h/+6/wFa7yebaGaCCJ/ASXo3O8NWSe/UonkSTreZ7VAmwIzhWN68CvcOGs
QUaB4LtklKBcKVDYCIwrfR4x5uxxM4KgBNtLvpjGrGlMLpBGZMgE+XFGHi5HPsWQIVdknQO+SRaR
JYtIk8D6YbLcFC10JRNU8Kb7br68wVcDd9Q1Q7au5Ms1xcuW7+n5Ab7cNSw5wx7WMCQn2ZP/iIBk
VnNfQsWdv3+cpRkEYnAMy8kyUmRTfES6MUmyG3yCuafuv/d67uXJswLyyWSzgmQNCQR90FueTSPZ
YFxXp4xHxjJQDPGU3u5T8NaP+GBJdpOjj8c/WpwIgXR400u3xGInpVCPeEdjjmmKeS+toFJ159Qh
ayl2rclnFC1fBQWRliSZ++hljAZckzXepQUm1rrcsmSON9nN3Gdh4gvKH/BnY5LftaWaNFTJJmi3
DvKADuagDJr7LvmqDOagCjXjSoUy4wYOc0SSIMbmd6WGKDfWUXVikmTbW7+XL1JcV8m6TBC/NZtj
vhZeHImni61Skvwk4zx7CqbfNhPcv/sZtXUl/8vbCbVbO/Vm7SSj/L3SvdjuKvc9XySreYHUP5b6
SPZ24bhoKmd2hTvxjmd5u2C+geMcUQ+wWy/9Zr2Yw3p6r2A1YzLKMZ1I5r98uso+le0aq232tExX
D/6dF6wIRSkUKWZe4c3ixj9y8k8K003qVakkRctkmuXFusrZSWsucV+AjVC6tTFvbfnCaardO1p+
3ZCcLJc+FfJkMoPIkVsUIKhRdXls+D7L/Jlqp63h4OzEZN0394OC8auwLswPzZ1ydOgWw765OQuj
/Kj1junl/7fyGtY1thXft1IsJuzPVT3NQ6K0/KF8vLLpo1sEtyuCpFI048LR3MelNOWvtRe1O/Rw
43aNyY98VfgswKFHMN8PkBh3JPyBizAIhXJ4PnEXpoWFfx0WPBKXp9dFuvC/udu2vEF0nPcb6Hty
/AePjAe7DQplbmRzdHJlYW0NCmVuZG9iag0KNzEgMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQg
MiAwIFIvUmVzb3VyY2VzPDwvWE9iamVjdDw8L0ltYWdlNSA1IDAgUi9JbWFnZTYgNiAwIFIvSW1h
Z2U3IDcgMCBSL0ltYWdlOCA4IDAgUj4+L0ZvbnQ8PC9GMSA5IDAgUi9GMiAxMiAwIFI+Pi9FeHRH
U3RhdGU8PC9HUzExIDExIDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFnZUMvSW1h
Z2VJXSA+Pi9NZWRpYUJveFsgMCAwIDcyMCA1NDBdIC9Db250ZW50cyA3MiAwIFIvR3JvdXA8PC9U
eXBlL0dyb3VwL1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1Y3RQYXJl
bnRzIDExPj4NCmVuZG9iag0KNzIgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGgg
NDI4Pj4NCnN0cmVhbQ0KeJx9k01PwzAMhu+V+h987JCW2kmcDwlx2AYIBBIflThMHKZpmwQan+L/
43bryFi7S9q6sZ/XrxMo7+D0tLwdX00Az85gNBnDZ54hoEJE0ho9eI3AFuFrkWdPJ/AmvxUasrLH
eCer4whfq10WoiO0e2nLkzy7zzM4vx0DJEg6QHYkb5ieovIMsg3YtK9KsyTAfJ1n5dV6tlowTN6h
i6T/SMMtCCn6bZ/BEHUwGVukjYo0gyEVJBKbpATr+rDmEMtM8TjWeulr0ymDa8C27jQl+j6iPSS6
YN2GqK2lLnMJzc5cbFp0GGsRvqH/YUMflsub2dsKipfZ8PpusNUwqiTvgiAoGWm1FE6DIIEYFYzE
rddQresT5WIAOUPl5aN4svpuQ5d5Ni30YGgLrBeql+azdKU8ufCDZ6iu8+y86lDlEiE7NrPSOmFP
CzhWw/d11ha0npRck6AMbwrWXlvjoJpPC9LHaoeuckEruVBpuabSUZFxz3ENNT3xW0fpWYLiut36
3X2DD8MPzQRGs/nrz0eioB3tP5DVTgWXkvaF9+gLrEKUNHLK9M3kFyfA77oNCmVuZHN0cmVhbQ0K
ZW5kb2JqDQo3MyAwIG9iag0KPDwvVHlwZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8PC9Y
T2JqZWN0PDwvSW1hZ2U1IDUgMCBSL0ltYWdlNiA2IDAgUi9JbWFnZTcgNyAwIFIvSW1hZ2U4IDgg
MCBSPj4vRm9udDw8L0YxIDkgMCBSL0YyIDEyIDAgUj4+L0V4dEdTdGF0ZTw8L0dTMTEgMTEgMCBS
Pj4vUHJvY1NldFsvUERGL1RleHQvSW1hZ2VCL0ltYWdlQy9JbWFnZUldID4+L01lZGlhQm94WyAw
IDAgNzIwIDU0MF0gL0NvbnRlbnRzIDc0IDAgUi9Hcm91cDw8L1R5cGUvR3JvdXAvUy9UcmFuc3Bh
cmVuY3kvQ1MvRGV2aWNlUkdCPj4vVGFicy9TL1N0cnVjdFBhcmVudHMgMTI+Pg0KZW5kb2JqDQo3
NCAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAxMjA5Pj4NCnN0cmVhbQ0KeJyt
V9tuIzcMfTfgf+BTMRPAsiTqCiwWyNppkMUaSGMXfQgWCydNjGxzq9Oiv19yfNkZW5qpnT54PHFE
HfKQOqRgeAkfPgwno4sxyI8f4dN4BH/2exKkkFIqraUHryVYI2F51+/9dgLP9G8hURlag97R09kI
y8XWSkqnpGmY3Z/0e7/0e3A2GQHUINUeZMJ4helVFN4CLQOLm1ehLRnA7VO/N7x4mi/uLIxfIIWk
fyAN1kBSRb+OM6BSCUwrN5AmCqUtoBKBfomVUQ3W5WBxH9ZaFdthjae4VpFacBWw4UjriD6HaPYR
XTBuhaiNUSlylcQtubIK0cnITvgK/QdsyMHa4Zf58wKK7/PB58ty7cOnGdn9rCAISunsnnAqCAVo
gqDYgjBew+yJK8rFAFRDw/MpcbJ42/x03u9dF7ocmELyQ/Gj+nPohvRtC19+hdnnfu9slvDK1RzZ
YscooqlhXxfQtofPRbbdUFkRNG2IdrUhc23Qwez2ulDYtndIbae9QNPYrtqp1cnYYFwD7RFdg3Id
rIgKTHDC+zXn6VO8//NVlYXJ6AzKgSsm0xKLq7eaO3X3DaLAOkyH52ojO0yaV4xokJ7KqcodRaUS
AmgbQNHBcJoIqip0oysG/qmc3jVmp9utpyl31A6TiopXN6tX+cAZ0i4KxDWV0TF6lJpFyYc1k7u/
roksTTE6/1baYnR6maFROzp6vo7RxaPu4pEkDEFLIxxmqMyz2G6bJBL3iNwhMQrnQNPhifYoEpFJ
HM3o+0uWRMfs1TC6SNyoJyNihbvxgzng4K3MkNc02fKWtUmSZhOCQGkQYfV1ZLlVTE1npdPFaWl9
Mft1mmOMVIJafg2rizHXXnZI58dz41QcfsUC/tey67JNMuhTkmoC2WkR/bH0PZQDX2yKjTtQTvzo
1DawuugL2YLj6LFN+BIF12qTpGu3cSTkDtFy/36f3D1w5/hGb9syDAWzma1EQ2fH6AMEUMtWKl2H
9mXYbDNLEar3+8fO5GMqMt8le6tqPB2PeRC6yhJI1gdon9Yt/FX6f5D2tdokmcPkyfWCBvz3ad+K
rknpiovpKHtyaVCIBwifrg3amZGJtv0OcK3Ifw1fCQZ+hx7KCIY+hMCvCnm0h8eKk+TFxe6OdjvD
SCRYDdHRQK2PmusWjy835UAX88dsG9WCbhA1iC5u3J7PSVUJVB+SkrbZ9PVumXEB/aov1VcPcmt5
0o3NtTfz5z+y58Tw+N5Y3h5dqsVoa3ngNZoPQmc4OlI4qrk6G46kcLC59vb179xqGnjdjh/t0YT2
Bm69FJYSqOkmSNMx8qGu3epzvbvFLHn49/qQblSLJcLomPBAR3V7uA5cPFPreaDPX/T5iav9lZRh
+cI3yBt6uysH2OCpzqmjBuCpD1gKJq45ZWGZlqy+JMFv1b3oJGfOU6BqmremBPOdzBLXiu5WrKx7
uUiocHZ9KgmoEoVtg+RS1YryGY5g/my5ZG5fmPPccXCKLeoY+ePgqKG5nbWc2GdKyP0LJSLs5Saz
kcZKgEjW1GajbApRCauaa9tT2HEb49GCkoHO8oR72G2syzaZ2o7bGFoqDkMyS/Or+l+G5FybrVS2
hpMg8l+7eAi/DQplbmRzdHJlYW0NCmVuZG9iag0KNzUgMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJl
bnQgMiAwIFIvUmVzb3VyY2VzPDwvWE9iamVjdDw8L0ltYWdlNSA1IDAgUi9JbWFnZTYgNiAwIFIv
SW1hZ2U3IDcgMCBSL0ltYWdlOCA4IDAgUj4+L0ZvbnQ8PC9GMiAxMiAwIFIvRjEgOSAwIFI+Pi9F
eHRHU3RhdGU8PC9HUzExIDExIDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFnZUMv
SW1hZ2VJXSA+Pi9NZWRpYUJveFsgMCAwIDcyMCA1NDBdIC9Db250ZW50cyA3NiAwIFIvR3JvdXA8
PC9UeXBlL0dyb3VwL1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1Y3RQ
YXJlbnRzIDEzPj4NCmVuZG9iag0KNzYgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5n
dGggMTg5NT4+DQpzdHJlYW0NCnicrVlNb9s4EL0b8H/gUS4aWfyUhC0KpEm266Ipso2LFgj24NqK
m21sZ2Wn3f77nSEpm5RFJgL2UMUSR+89zgw5Q5WMr8irV+PLs8k5yV6/Jm/Oz8g/w0FGsjTLMspY
lpOcZUSKjNTVcPD5BVnDcJpxKsCG5wquSpakXu7fyjJFM+G9dvtiOPhzOCAXl2eEOJT0iLLjZcOZ
0zLNJQEzInnzM2USXiDz1XAwnqxmy0qS8w3pYmIHphNLlNEyt/MsOKUdnDJrKEWZUiYJp2kBT0r9
kkOrQrT8mFZKWsZpRQ7zMjOVRGligTN1GfMQozhmVIVQhpEJQbucSzO+d26mp6iyEkXkmv1AW4Ro
paV9MwXT3xlheVoqMr0FbA1LCQMf5gw8WUDCkOkqmEbjt9fgluW20+Dj2+HgJvlSrcnH02syOpHJ
djfbPW5Hf5Hpu+HgYtqhTTnaGjVCKUB11dwkJAaSWxCQUaAYqSWVimrNTKG3hAQ0mLtJVVZqTzb5
zyAI1oCCk4/GeanSPQTPuiDQBTCBNC8ZXIuCudyU4h/LDSnE29zGwHC3xi23sbDcbQjNwpV0WZTH
YActg2qh29EGXbWRaRlBNoMhZDMaQma51L60yDz1/WKHLbY7atDteIPuGsD+k2M8bFCUEw7GhTsd
2iY1w5aUHpOa8YbUe13j06JMD/AibQXbDFt4b9Tgm/EG3n/d4MPDQyrDTTuVrcGe4jiVrcWBpDhi
KU1+B6dhx8PzsAadE4F3ioLsIyKl3suCXHY8zGUNOrko+YkX2Jxgb/mbmAVXlGRlsdETktwPB9fD
QbPazLDFdg04gg2YTju7H4BhninngbGkrqVZvY6leWBJjZFdhAcj+8A3MuvJMTIPPCO7LA5G9oFv
ZNLYMTIPPCOTiwcbc++bmFRybMwDz8jmwsHIPmiMzDZpg2JSwgsLvnWwsHe+ifV0UXiCzb1nYnPl
YGMfGKOj4lK0qictvNLJeSokJJTK04zpYkUxr3W+3SSTXTUSySpWvMqOCpjD/EoP9IkKSLMOFCa5
dpqLcv1kRaa0AwqaoZTzPoJYV2HHVqbwUc42q1W13sUl8Q4w6C7TopePhBdJCg9SaGe7ggmbOo21
QcHm5/JsdMKSUzKiMrlb345UUs+2cN2NeFI/QirMd3itK0eoOyla0BQaiIOAp+YkI3F3QLbA//jw
sKnhL2qpFgEBHFzAyh4COhs4G2cH5HLzowKv5MktemIzksmKLEYnPNnA/Sojuw14iXz7Bc55qEYn
4KIfd1uwwuE6oFUJqbvWZ2vNuzLbhJyXILlJyQsMIhmVyWwNehZklCefzj6chmLGYbV6AHEVRThk
LkjfkD1fQNeOY0PmgnxCBVW9fZjNK+MQLrSSjf13jwbkHn8ulxjLu/WSjFjuuE3/mt3/wjVwtw3F
EUhVDw+yrs2uiSO0xqpsZrCeb/RqQylVXetkgr5gDslY/wqogWM1lAMfKC6na8NsAuqi9I7o8yVE
dlsP5VJHcrWpcaFhhqOmef349auJndy7KSBNYpBUH2lde3cjjcMW3qC8xwzisEdkSfXvw/3dXGcU
+gl0qeQn3tZwL5LQ5ikBDrW5qCdB2zwVLQVfZ/PvwFU85QNFoc3zX427QETyNaNwaN3XQkzVA792
BqQrxgwfRLKWFnnahouLilQOD6V31j5fQqR2eCjnsx2UghluNfBn4booFF4G7hV9tHTVBquFFXA+
alAmayxLTj2/Q1FrgrW+2s2/mQR+Qh1Ueap83Li6rpphM4jBoYPmTbfCuMTPSVxy/CPFvl85HjAd
y+kVLqyLiW5Z3lx8xLtpKMmoXjQO41O6u0qNTTIP5fPpJETKyhzT6vmkvKs8NKF0Uc6xOEDvgaHS
28v6JYQSd0V9N9ObDd5+x02nXlf34CTo6KrZIrQMFZe4BfUQ29lt28hSlaoGxYsThkkk1+E4Ka3C
fT+uoqt+NHFyUfpuBj0kROqEh9JE7dBkBLpGvRKhAQgVMplmLehQsVCwjbRMfza9a/092J3SVLI+
HoiUCZrDuYB2psLkw7tgGnBU4L0bVxCpCR5K3zToISFSEzyU48UbkIBfALJeXogcEyiD0ybvisMf
F9fTMX7zfgu/QgFRJZ7uPJC4lMhZwUP5MA6dTlgBO1LehzNyPPBQ/t+F6EHHF6Jn+uyF+HwPiMj5
omApy1nLA19wCayJrp34Px85nIR22A/UtzPsr0MNK2MKp+5hxpVFjhoeyufJVTAfwA1lH87I2cJD
WemOvbrfLF/qU+D8Ae8fIfpUB2h9f7eGlKj0KsEHt/YfPK90j7/YYCpVv+kFRbDyNpfA0jYqlIRe
r+mjXNZvG/vpZbZYvNRfH1YVjjbnH3ecwE+tcolBhdNQ5LBatjjj/uPj9zM4XCV/z07eXY1a36CK
o09QokglRDMV1rEZHLT0p3LzQzdtDJdYhheKF307VmOGns2jYjprTAnbknAon5qRDM3o8LlQpgUD
RC4NIvacgisynd8kVETBuwoAh7XLhYenoY5k/gdpUVQoDQplbmRzdHJlYW0NCmVuZG9iag0KNzcg
MCBvYmoNCjw8L1RpdGxlKFZlcmRhbmEgQm9sZCAzMCkgL0F1dGhvcihJbnRlbCBDb3Jwb3JhdGlv
bikgL0NyZWF0aW9uRGF0ZShEOjIwMTIwNjI3MTExODQ5KzA4JzAwJykgL01vZERhdGUoRDoyMDEy
MDYyNzExMTg0OSswOCcwMCcpIC9Qcm9kdWNlcij+/wBNAGkAYwByAG8AcwBvAGYAdACuACAAUABv
AHcAZQByAFAAbwBpAG4AdACuACAAMgAwADEAMCkgL0NyZWF0b3Io/v8ATQBpAGMAcgBvAHMAbwBm
AHQArgAgAFAAbwB3AGUAcgBQAG8AaQBuAHQArgAgADIAMAAxADApID4+DQplbmRvYmoNCjg0IDAg
b2JqDQo8PC9UeXBlL09ialN0bS9OIDUwMC9GaXJzdCA0ODA4L0ZpbHRlci9GbGF0ZURlY29kZS9M
ZW5ndGggNjA1MT4+DQpzdHJlYW0NCnicrV1djyy5bX0PkP9Qj87TLYmkPgDDQIIkSGA/LLz7ZgSL
Xe+FbWDjXWx2Yfvfh0dN9fT0lMia7nmYW7o9JZISeQ4pqaqn5W3fmmyStla2lGRrdUu1b61tmWnr
+0ZZ/9c3annreWPmraeNe906byJ967SVlLZetlK1Q91qlq23rVa9ReWhu/56ly3tu/7khH/0R+9O
u/4katrgLWX8D/flgk/UHhL0Uos4dW3oD1ftnlSOZO2hepOonpRUYCGI156l4Vf6U2uG+C21jMHp
T9MBYZSps/6T6pZ3SFXpea/opcNOucEWbeh4U85bzqIq1O5MUJhJGxVmis4Rq0A1JXPHCMqWRdBd
JRe9EbJ0NPqJGpcro7vqqjoxiVRg0wlMpCo6hkMquTd8whvtgk9kI1iXqGoDw6GiHsFwdNbUNapd
LSBSXyVSL1Efs7URF9Wln5JgJjhrA7Oq7qOiCpOOn8q4WSVXgRyV3OAHVskNN+un1OEvVskdQ9Y4
4V316PRvPJymVnLC/AhtnIdDijbGzbIxoifpjDBpnOA+DSC9uewby7i5a6PozWouF9xcVHLBZBaV
XMfNKrnterPex23crHJ6gqsLQhHO75vsOjfqfG1gWuquUY051IiRjDnU+yQjNtTTQoxPaBNG1NWi
jYLQVywIhqxRpZ6UAQYpCNGqkgtCoqnkKogmldxws2JDGgCk0qULPlFU7IhlFVF2tS4psAqiKel9
BQqThkXJiB81V4eOOO1bIQxZ1RTG/CjWCmPIgJlgfjR0imB+9KcU9VVSL5YKBAwM6pSkrnIa4KA4
1OhDmKscGKbxvtVdUaK31F1nBKCrRScrq7UKGA1BRV6tbUBiq029mPX+ikDIirwGxGT9abt6SNGi
8EZMq7UN488ab03hoA3a1AgVqJ5qVACtujUGSFRWU1dqA/SjQZlVcSs7GiqwlIE6JaMBPxVYddKz
oqo1RqNoo0MguEnDK6sFfde4zwq4vuvgsgZ5R3gpaJW4AHVFVc8VDeUpUmhlDZhOHQ2lLBYAe1fS
SmioHAELKvK6ukARrnLqjobeUzF2cGEb4FeBTYMg6329MxqD7nSyM4Pr9oIWWG1QA1y8IzSyDEpk
MAkYbkwXjVbBxBUwI5SDs5QR4AvIK+qILBcWBecwWnDZIMzhMwToPpwGdO4dUQC20Rvx2wb2BCmB
JxKiKhdwIyzKZdBywmeDQTV+M9ChhKKjRYQpJego62BTtSMjwtOwCrSeRkAN9q1gwDrIFrN5IVmM
aBB5x3wOAu/aLwMVGpAgRtDqrtGvXAnuRTw18CkiL7dBzGpRBkLV1WiBfwlzCrpV36AF3hbMKcCp
UwKCheSCuALTKjmrpcCemoYWJFeEVgdXN8QWyFr/qzoGx4MIlaZB6YghcCjtKoGQ3gg8mPtgdUVE
7mBqjDUrWSjBg7XhQYJ9BFIj2EegCoJ9BFKlon4jJD6FDVqQUsHvICuqiO8KCxQp+hm0dXA0sh/v
O5LPaGGGQB4MCiakTQasCDmRMbME2mAa2aWg1dFCDxbch4yrLKotyBP1EY18UAitkTR0ngiZjqug
BXlNLSLkKIU4WpCnyNMWsgsiUXMZ0gtSDtKTgEFGchWQWC74DFEIz+qMImuNREIdWQ+piTXqCBQn
orIIKU1E55lopCCMkpBxSh/pEblHEQHU61xk9IXkprFCSBsC1BKQVzB/8JO2ChIpEg8yO4GqC9if
gOkC1I68W2A5bNSWxrKmXiQv5F6wQEGtRMB+UbO2Qe+lJMiDtuFfZAytnlQe+KAAySSQrNyorZHf
1LejHCpACo3EtmNOge6qQEeCR7LDnALdFfFHMvIerAK6K+zN0KbBrjqA7loTWqNcUsQS4qU2xClw
XpVVtTWKQsU0jUy2I5oQYQ3VFQHJDemRwAcN9Ep1VF3wFligYQyYG4U+vDWynwYMCg6kSIwcONdy
iEalqUlS0ILkinEA563Cv8B5Q1VJwLk6EC1I7qhk+kin8CDQrfQCHciIqNYI6O5IrgR09zwKnJFc
E1pIqhjXKKI0INBCX2SqUb90GUUSWmWMHNm3dPwW2oZ9YIYO+xg477CPgfMO+3gHg8M+Rq7bYR8K
EM3PGa2RqXWEDF7ckTsYnLqDM3jkXfiRE/I2Z7SQ0lntYI0PTeGEFnoU1cQJOlB+MlKaVrhaLo2i
V3O3tqCjocwa9S9KUEYBrLlCtYEhNfmghcSP4p1R8aZRvOWR+vVuRsWQwEY8ambgipE5EkaIOllb
YJqKHoIoKZBXGPViRU2gMcWjggAuGTkJbtUW7usoMFEh63SoXuSfjCqfUSznURsiA2YkfgYfZ+QJ
JtQEQB2rPVpBqAcuhQejZBw1hGCekauVaFCXQl5VX/AoR4ZVyCEqTmeSIaVn/BZSOsaLnKR0jc9Q
J+i0oahFwQGrkEcJdcelrkDO0koXxYfaC3bVVkcZjL64W+kVhYjOGqNaUDhraxQwBfOs86At6C2X
BQjuyyhUMBsF8lC0MwoTDXRU0ZA3fFlG1QK9mHsNJG0hQzNqYkZ2Z1RQjHqQkRexzNKqBmOro9DB
vCBDM6xk1HIM3mWUUwzUcoWOgnFUyKsJLdyHUokb5KFW4jYqIYyjjqoHEYuyUfaE34KfdtU+qkPB
IolHnYRqiVFBCHiXRzWDPMsouwQ8x6gWBDHAHdURKhQVj5oIqxXUK1IQ931UR2PpAL0VcTVqJxSZ
jNyvhf9YWKBiUuQIECXgXUbmLQpH/QxVD1YaajiqKI0aHrlL8aifjdoJKwXgvAAVMvIyuEX2keM0
VgSYLlgJCfBbsBQa9UpBBuNRWVWVP0rS0jTGBdgvWGwI8KsrJbQEtRj0AskVhbkAyRULDixntIU1
Sh5VmUY/Vs9aqe1ooe5CxhDgo4IBBDiv8KiABaoQWpCnQ9dWRUsjSYBQTRpoQXLFWgm41PyBFvo2
jBe41DUvWozaTu0V4LKhFoV0rY5orMXQUp9pokeVhxkCQhsyrKC8b8hAY8HQwBkC1DZEA5hPyzXF
KVZJWu9h5OA6zR+QDB1Y3Y4aWqdPfwvUNiAFvbQFbwG/mvLQQjUITAuQ11FByajtUJULkNxRrwqQ
3FFhyKgVaWyLjFpRvTdq4w6fCdhCVxRqH9Ddi1y2T5RK8NtRmSL/okbQvIkIK6PORIQB05o/sACt
qDN3tFD57fqvoErZUaFgqa+ZYsQLPkM9KMhsO3iYR/0I7hNUZbtgGVxHdakeFeR+XajqXKG+UMfo
7FbIUzdoa9SZmElkbSUQlVxHTQm/ob5QUtbPUB0l1MByqS415sGz2sLYFN1ae2JsowYE/0kbNSDG
hkotAQeCnJ4wQkGu1lILrYTWWGBDXmW0IK8pEn/9609fYJtp337/6ctPX/74zV8/ffWPHz9/+vLn
n37548//8f3n//30xZ82Gr//7bb/5jf//E+vu/znX/70y0+fP/3r9z//Kv/L9qbzb/+wpf/ZrjLc
/nzcPz/Zn872/+HnP379189/+/rb73/5/PV3P/3w4//9+ZvvfvjbsVQ+lNpN6hdHXWQrrilfff77
z9/+8Pejruphveeod0+eSl33P6wyL1WS9f6vdNjxYY281CjeINP+QJ/DqAz6+JHojazgHuzxjktb
jbO2CcTv//Ld5yNJbXgFO8/jcpHbLnJbu1z6RUu6XOhykeXczphdgT/xG/Rf+5xG/0WIK8CH/+MC
6LSARwjghNjj/uL3D71Rrn1Q1XsccKgo6NQe6dQf6TTRu5oIB1Y42EBw41zjck12veGue2sSudYE
8epZk9jROpnlmDNTEOWu2rJUez4a0zFKcK7jzVYAAtfs/hFmH6MIZ06e2eVxs/M6tN5h9gKTmV2z
j0F5zmz5CLOPAX5eQA6wHpJeTjeT5RZb+QlE0f4Bk5XP552FgGczTA5STCwgwEnsrvriLiquu56I
baqxu2JT+42pbmTREwmLT0RWaCrdgICza+oTIGD6ABBQAIJ4rHwzVjeCKIh2d6wfEUF0U5GxH0HH
9H/KVPkIbqIAbfFYb9AibkHFT6BFnIJK3KUaP1HGybqewnMYntYn4CbN0epGEwcY87SWj4gmDhJV
GE0sL2MtfjQ9UbmVdTS9w9SbjFZcPuInMlpZ8xGe0/G0BiWaq/UjKnIJ8B4LOL9jsBBwjEI8s+RM
nDyBourwVHV5Sp5YQNUT674wnuUGetWNLHkCevVDIivImrGAAJGxgMUGR3MjqzyRAdtHcFa5qReb
y1nliQTWPqKGKnRjqpv1yhPI6eusl/z99PJEkdk/YuegHKMwdXfnoDxRcPb1zkHqfjQ9kQG7kwG7
y1MFz2c+oXhNVXgE1FFc01Yfxw8OH1eK42OBtNsO6J7tSnZlu4pdi12rXS9nBrYrOvcpxxPel6v9
Ppv8bDus2e7PJj+b3Gz98uxnO7Rk/cjsI+tP1p9ML5kcsv5k/dn6s/Vn68fWj60fWz+2fmL9xPqJ
6RXrJ2av2P3F7i92f7H7i91fTE8xPdXmpVq/av2q9avWr5qeav2a9WvWz851LJWMp58vV9PXZj+z
0053kh3vGP4nIidGZsguwnnuHaxo+TLpr05+XjqdPvq5SPEl+Gc/T0ig8xIeOf15I/fcAfDSHI8g
0o0r7wWkc6fAj+nNjt5TR8GPqWVH7VyG/+7ffvjuH96p0pueM2P97r+Ptba11ryHWhchn7qvNSdH
aw61LmASaiVHK4daF9AKtYqjtYRaF8ALtVYnmq5aj7teqNocMadmGrsYSAsHIo8FaO5rrZRCrQsC
ot3XSg4HEIVa64NaHQogCbUuSC/U6vg1CBWrcmxKppELM2IOW9BnFCLkcBiHHJYXzEkBwtjhMA5D
JC+Y83q+sdLqhAiHIZIXzBlqdULkZZ6Ou1posBMaHIZGXpBv6CQvNHqodUG+kVbxKhcfUWzka3W/
Tc00diFSXJG2tLGUMbl68sIE5hzVMxXMOkriFV22FVy2lVu2lVu2lVveZ4Vvw7BnX6wkm7NwbL5E
D3zK22e+XjqdrvyFF2pPV/5PSKDzEh6p/N/I9TdPZ+W/NMcLJLmJxHsBxd+TmJX/Q3pLcvROBLiV
/2NqyVEbV4j7oueVFY5J6vbM5U3fkBrTIuSvpzULrXVfa62nK/83PVOg1Znherryf7dWcWb4Ok/H
XY3+b09a3qg/vXh4t5Oc0KhxaMiiZ6C1OaHR4tBYEE4LnNSc0GhxaNQHtTqh0eJCeUFyLSiUW3O0
JjcgmxMSLQ6JBT1G09SdkOhhSOQFM/ZIqxcS/jTdnnm8URtGU16QajhNTjT1uLZekGoPoqk70dTj
2npBqoFWvIn2sHOskuxOeVF9XrZta2OGibgJgRla09dzNIeqaA93L/KCvwMmpX0dhbTHUXjM37RT
oHUdhbSHuSof83es1ctVrjNtKqZxj+Vp87sda5hPp9WLEYV7ZXmRVYK8TbtXN/uLxGIDsXMdKy7m
FE6jF6LZF22iyhkR7sOy9zOZ4hRwnHgo+YxKyfFfCrdZ6DjxUOJAq8MWKYwaOs4e9HJ4sNC6jhqK
jwDoOHuEWvN6rUXxEQAdZ49Yq+PXHPv1mI8pB37Nnl+vFh93dUg1ubiziJk+nLM6rY1wcSzysjdj
Rj/CBobZafwzq+Zpiw0vOYv38/s/JDdudbc46IkdDsoOU7/D2JeHM+l6FnJs7BPbIkROUXu0vbTY
n4q2SOLnbhf1/DskLCjSf1eDFwXyuclbQ4XIf7Q12tFz1Tqkzu4WGq82/M6o5TMgjN202EF4h4QI
nLGE4xqM2H8O/xmcsZMm2H8Q/4ntR2KnLjvPRfKyc07iBphEu+WeseKUDeK+GyTPoFicukHc2lWe
QbE42V9czpJnUCxOej+PIHkaxfI0iuUYxSeOo+wBuiy2krcH6LLYasYepLNzkHkuMc8JZhk0vpfu
crVqzE7dLF+P7567XO1+ezDQUtLMEZO0xzfKXa7Wzx4MNF6aRDG+M25cxfrZeCxaZ/iMb4C7XO3+
st5foRKyQTE22A86nT9GKwu154/RHpdA5yU8dIx2L/fkMdrKHA/Gt++33AuoJ4/RHtFbk6P33DHa
Q2rJUXv+GO2+p3+MRq/OSu77nj9Gu+8Z7PS8Oiu56/uyCxoeo71Xa3a0nj9Gu+8Z7PC9Oiu57xuf
lSyAF5yV0Kuzkvu+58/A3qm1e369ztOxwUb8zUF9j0NjQTiRk7oTGvHBx/UY7b5npNUJjR5DfkFy
oVYH8oGT7FyAXp0LLFF47GcTYUcP5tNpdURixxxmuX/uYjdHVA/3IdOCxCMm7evA5RNnJcf8je84
9bTyvg5cPnFWcszfHJxa8L4O3BuLj7uy0zU+Zjmm/nia1jHP+/nDvvuefsLhtKZDTnFIHFN/rNUL
icA5FyRx8kogF4wW6jOEpk+n1Yu5iJ83XSSkAJScnGhLcbQdZxNOkVYn2uKDkHycTWKtDgHlONqO
swnnAFnZibb4rYR8TLacAwLKDgFlP8azFxJ+bNvbdJwfzlUWdDMMprELUf5RhJ1x0jzjtHfIDOMT
VXNQz6xM1gLinQiyHQWaOwrz4MPOValY4Wev6NnSbi615iwsXD0hvFzRX+y7XdG/dDq/om8LtedX
9I9LoPMSHlrR38m9vh4SrOhX5jiBxLcviLzR625Mv6zoH9JbHL3uznR/Rmtbao1hw7bxxvZGLtvG
G9vGG19Otaa/5vzN8SzGGr3Yb08nv4LLtdNpuFyk+BJ8uDwhgc5LeAQu93L9L7m6wmVpjhdAt19z
9Uav/x2iEy6P6e1rvdezEXcD7CG1t2cjb9RG7z5fIzfdhK7/pVNpEa7XA5Gv/v3YzuLY6bJJWoR3
qLE5Gt1XmNMCDpHG2230pS+++v2xtcZEdsTA4oRTcc+80gJ0L1XLwnpyNLrHXXPj690axdHoUkRa
MESo0SGHyENWktlcTAsXdvjxVa/bUG86Nn8A1Qmx66sJx0oXLBNqzI5Gt+yZuzPv1shPOMkSvz3S
yNUJ6uqGGP4uxoJ5rquV1QCcKPO/fyovmCfU6LBFc0998oItIo3tTN5ZOMnWYDYX08KF9X6IyXW7
4U3HHAzAibLmpsC51fBujQ5hNDcF5gVbhBq9FBg4yb6kxeZiWngsq/sh1q8Px74ZQPcH0J0o624W
pEWdEmp0CMP//ilasEWo0cmCkZO6rW+65abuBHV3Qwx/lm1BBddDldUAnCjrbiLEX3ZbwDdQij+6
tFIqu5sIaQHfUKOTCEM/WVV3mY5p4cJ6P8ra9aHKNx0pGMA60GR3cyEfwzfWuOYM8f9gAh/DN9bo
rcJ8J9nEz7mYFkZrs2++/f54L8K+hctWDbM2neXPzLCTxCdPzDicQz2ehvglCD5mIwlegpDkaQ0f
lufj+kWClyAkrVOjxHv/fExcErwYIGkdLBK/BMHHq55Qa3awn8MzHT7mS3l5fWKhdZ0ZJH4Jgo85
M9bq+dV9CcKmYhq3UB8+CcLHlVPspDX2heLQWDD09a85LLSSExoUQl4WLB1qdSBP4WGULJg61Or4
9fpo/lrrgt5CrU5GovBIWxb0dn2mf6H19i8i3Pfl8JBRFvQWal0XLBJ/WZEs6C3U6hGN+7VB5oA5
JdPIh9jDNv4NNTOOZ2TNUUTJ6jjemxGTqbBXrIyM5iAX0x4yrSz4Pcqg7DBt/FVLsuD3UKszjRLS
pCzImQMQO3veInFgL8hZglwmTmBL6NeyIOdQq+NXCf1aFuQcanX8yj6Irey1KZlGPoQ0e4zdrF2M
JCTtsqqEg9h2dvOlhMm4LFJFCepvZxdeSpiMyyJVhFqdZBx/G1FZpIpQ6+OhYZvxNiXTyGjJc8zn
Fqj2lWnG0ZM1Z7zPSJujWqjafVVmdXK2ac6c+kla23DilNxeK2F7rYTttRK210rYZsCOaeex6TzG
nAvpOdqF769mrM4eLxC6PTV/6XT+1Dwv1J4/NX9cAp2X8NCp+Z3c4K9sXE/NV+Z4AXX7dzbe6HU3
Dl9OzR/S2xy9Ewn+qfkjal+dONwJaGEFMV8bedMzyKqvjhzu+8ZPri9CvvlPOMqrjfv7vvFLDQuY
tGAZ0J0ZPvFGwgJaodbsaI39ugBeqPXQr/8Pgj3xPA0KZW5kc3RyZWFtDQplbmRvYmoNCjU5OCAw
IG9iag0KPDwvVHlwZS9PYmpTdG0vTiAzNTQvRmlyc3QgMzM1OC9GaWx0ZXIvRmxhdGVEZWNvZGUv
TGVuZ3RoIDU2MDE+Pg0Kc3RyZWFtDQp4nK1c244kt5F9X2D/IR93nzp5JwHDgHdlw4bWgjAS4Adj
IbQ0vdLAo2lh1IKtv99zsg6rqmuSwepqvTSjs5IRwbgcXpOplWVdUstLqijS4hzKWhdXypLXdfGZ
P7cl4HlewxIKS7/EkFG6JTaWaUkpoYxLdgEl3iksy1KCQ5mX0lC6dalpxf9taXwH77bM0i9u9WDk
oMBaSURoEsmuLM5vfDOI7EG4xQXvoSVeDtA/VVRPjk/wUyptSWDq8la9sSUQ6fFT9dAJNV2tDURY
XKPWPi5+xe8ZGni38qcEIqO6r4v3nk8KiIonASYJkU/a4iMMkgOqR7YihMUntiLg5cRWwEZ+UyOi
VmErAmoVtiL6xVdPwoGo0DBAVosk0hJWmC4HD6KwOuzu8GKOBQS8lGNegk+QDnOGQJtDpxAK3sHT
EGn1hOqRLUUjQ6LOKS6BTsnJgcggYoVHA0XgnbpSBN6pbE6CiIZ254yXG0ybEQpoMfjANHFtJMIS
YXEQeYnekUggCjTMDTESSFQQDRpCuRipM/wRkyPDAoI6wyKRBsgJtQqbg3CMhWYB91gptOCd2hhZ
eNLQuFwQtStiKuO9tNLL9L3zfAdRDDeDQGh6mC3DjglG3AIzBUYnbJRiYETh5QQDZARSopoZnk4F
cZERYwgoimCGwCS5IuAaHUfLHqQzI9DuvIU4AiSzgqt8woBjxDfP0AHDRr/CNpl5A0stBUkGN+Bx
2zyU8CTQ1iQ8LRtAJLafBBsAXxR6sUYS1AlVC53XEjlXsoj4g6du5Tt44hL/80vxjgSeehgSj5Gi
gQQqBIQWrV9iIoGniY+RegXmQI11KYzKQhZs5aZTSSTwtFIOcqcwfmi+0pAOhY1slURe6or4ggpL
dSuJBgJOK/AZspNw4UG0A27UQDVgUDSURARRqGYAjFANVKhwBghwZiqgBUtFm0GAYaEaCMFaPQ2A
J5UNhNVgMPBBsrUVgVSgU3O0DRKtOQRSQX41H0gkEPBwQcI2pBMtujTqA2MvjfbJ4AXD0yEOeJbJ
py6tsBZ0apubkHGtEQ8hrzWEX0EmuJXpVBJRz9FMSFBQCEPYm5AY+QzAt4aVzxqpzGfAtxUJR3eQ
onUzQTTRvJk1CMYlk/OmUWbdzUvExpWpVRDpQNtIaiXFwCnk1xIp8IMymQ4mVUgRlh1jC1qAohUL
qS2W8AZ+DAyAlRSNDecCyNHWUsEZME2KnJn3jGTnmIgFCQuKIZUpg+0vmb9u+mXy28wXKa0xGAn/
fqXOlX0EWC80ufPEoYLsBAWZzF63QTaiEVRklCFTQTFy0ALnE6UhV9HBMAra1tWwRewQPSOwVL7H
/xHKoBraUVdyhsMXAicSn7ELP4HCOxVZ7AJ7kbqyo0LXwOgHBUwHVUgVPoO0QCSoyFdQjc8gA5Cd
mSag2OdVdpKB+Fq3HpA5WB1lULfKnjNURj27zlDJhV0mnADOiH0X141LIbVxgbRIuKrsG6MjFyS4
i55c2E1GNAlUJEUu7DFjJBckOSj4u3rySxuXTGrjQmnskGogv7JxoTR6tQZKI/8ayK/CZzVQWot8
Bs6JvV9FlIHKhIGy9e+QhjwHhehiSx2AHe1AfIBqlAYZKSDWmHEuRWY8MhoU7Rw5SmD/XCM5J8RA
jeSXNy6USwgujdIYhTVyFMEOmIMWl5mhFVEGqhGBwA/g3ohFoOBgUInjDsYGMxm9NH8FP3TK4MIo
Rse2gRYojgEqszYT6CujPTPHKzMg0z+V2Y0eBzoz49GdEOfAD2DPGpkU44/ZXTYLMbvLZiFmN0CY
1EqqUQPoB0QExUwG3PHXQIp+Y/4WIkhlxkMVYij5sTeuzPPCHqQSGQrxoTJ/C+3EEQyAnO1gniOF
SHGoRQSpzNVKBKlAKle3qGNG1S3qiBF1yw9mLYKB/CopcKjMVbiM1EoK2VmZqzA2KXLZBpbM7sqh
SSUe1K0noS8rs6kypyutzb7SVfbgxDtQ0KoxfxugFdRKqpEfdG6OAM6sRQX+yjGjr3wGfugPth6E
FPsAZm2LiVTh2BL/0yKg4JXGrG1562oog900UQRglkjxPeZ4YyY32rgxk1vb5DZSsF1DTPt1zfwV
o0ykNDuqlRTbgZjBUBbWZftANVIYYGI4QLkYjq4RrWkc4KLX4K8c/DI6OdQDxXZwHLxyaNg4yF05
fGgcCa/sY9AtgtryN/E9WrEhpzFyRtY1jo/duj3DewR3UNAFYMx+vJCq7CFAEErgewy1V2IoiLpB
AIhGL8ErqNU2XUFxVMYxL2AdcRLA2aOzwTiRugVOTiIH04EDsoSY99Fvo3pSxIJMzpFj6BI5eKev
MVQBz3XDfzxDd06kIBVhy9/97u7LbXK0Lm/uvrr7n/96fPvr3de//vRw99XTx1++e/rj+4cf7z7/
O/Dif5e7L7+HLL75+9//+7+pZuo1/7JXLW2Trzf7ddEI1d2vmo2qyawK4+HnhQB4KIPKNGbZ2tQG
eabMrg04xxxJ5TxzJrUMarqJ1HCr+aTUQGycKlxvNNPYOZzRzaS2Qc08kVpvN9M4tjn/nyjs19vM
5IxoctNo8m5QcxJNbhxNXMmYSfU3SjVCwk0xy4cbpVqYZYfEwQHdJF3JAStvseLqyoZZB5Ts+NTz
vidiD/Aecb11A5HOFimYrAZM5g7aXz/86+nbx3/tMxoDSOn1v3r/7u3Dbu0s9C5C7+JVSr0SVSaV
RaXq1bEFuBAi8T/df/hEOiscHPz5su5U+tO773/5+HD3h/dP/+H/c9mFIYlNA7FnHOI+B/9qDuF6
Do9P333z4eGf33z7/peHb95+fPzp5x/u3z7+c59v3Ofre0p8uevNJU/UMQKJ65UnV17KLZZcTEFe
I7cacju0/9nt1W2vEBvWsdgQpl3gOqh5BJp9vAvRkDofGQ5CPkz6sVAMqfOx2CBNQrWlRsPC0U2l
DlJrKtUbbbV7lCBYj85gYfYk8mHXcsDC7BkUfF3ZCYvdfHQD9IjXTz0ua04CLBoBFq8f7F/WnLg6
GQGWrh/sX9acDFlSMKReP2J/qVQjGqI5uZMpunIzB+/7V5mRjMyI0WahzIi3Z0a8PSMGPUVeZ/7y
A6BPzfZXNiyVp92LHwB9nnQv2XBxTlOpA6CfSjVGDscx7HzqcFmzTKS2sdQy9+sAI2dSi+VXu284
mKIrNwurfRbqGw7VurYDVjYqHEK/Kz1gUUwWyfDAJJXTNSiwm8p+0EWV+Rx10M2USedWDCOX+drD
oJspk86tGlFSbLQuVmbYKF2E0sXwTwk2i2tQelDVgK/rBvXq6qLyJGrintSsQ0Bvu/+HctyXzyfP
PA6ycfFaJvDi6iXdS7pXtnpJ96oXDCw5Lh8MJ8+H3Hw2eT5Wun7yXAZir588384hXM/hpsnzJd/u
0cnkeaSOFXj1POUuGLTVknuaPN8itzlDbu+O7MnzTWKDIXY+y1gHNSdA/GyD47LufJYxCPlmAzFP
1Iykliu2FPbTpEy2FMo6tnC5Yl9gP7XmUpMhde7X/cSbS7X8ao5i5IBukq7kLLz2o6uJxTilyjod
zR5n0C+L7bKOAaS4+WLJPnYVt9pSnTekzqOsDGqGiVQjyk4a71eNRtV5gO5D7dxM4wAtbg48+0hb
3AR4vAE8fr77tA+yxU+S0RvA4+e7T/sgO5dqhISfj+wHIDuVavnVBh6N9WSSruRAjevnwC8NEQM1
whQ1/ACvwyQdgoUattmCAa7zVXe/D65TMwUDNear7n4ArpNV9xKM6ArzkBiA61Sq1ZFMnHOYJZVn
i9cvxGd1opoSKfR7SHUf91bsi4jzxZsbcTwa0Rfn0TfA8Wgvj5VoRN9p3XUkNQxwfCrVAKSJEzV7
LnHspMlgSkOWPhTofXOPwO7j3oqBCHupomlO38RyVenG3eaVkxsjNueLAlWLAFWT/6rJv84Y8MT/
odRqYNM6XFO9ZkVLX48bLgocBiPniwKnStcvCrSB2OsXBW7nEK7ncNOiwAXf447NZFFgpI4RSOXZ
ns2l3GzJPS0K3CS3GHJ7BNuLAjeJbWOxeT5RXgc1J2O4HAypU3R1g5DPcSI1G1Lnk8RBmkw2H0o2
LDzf8nCD1JpJfbblcSl17tdB4k2lGn4t86lpulGqkbLZ7I/k9u6Ibpqu7KAh8ynrAIBmAVoMDJhv
Whxn9pc1JwPtZ5sWF3XrPFQGoFcnEFCtULGHvM9Oz73M3zoCV6qRHtnc7xA+9ajs4dCVHrC0x25Z
UZeNqLsKzbPRrOkoqEQlQ1IyJI0HdRahJI0Lk6bP2qBR99RbOZDe/TIaBR0A6/ko6Fjp6lHQgYvN
wR4FvYJDuJ7DLaOgS77N3HI9joKG6liB1M5S7BO5wZJ7HAXdJjcacs1zlO01UvNY6jxtNFkomiQU
TRKKPrIomizIX91+vT2Dts4mDdrPfZYu7cWThgMXm8MkXW7nEK7ncFO6POdb1+smDUN1jACq51sw
n8i9btJwm9xiyL1q0nCb2DYU+4LIdafQrc7EMjcLV0vZ8+2SVyjrz5Q1I8nN4tpUdhxIL1E2nilr
ngLvQ+7blK2/ibL5pKw3d937APcmZb37TZStZ8qa/aB7TYL5+Fso688SzJso5F+TYH4MQi9R9izB
jl8Q7Cv7mgQ7/4Lgmp5n0PkN+pjjQXPzFNxtioeh4jWYgORf07MFo2cLdky9JlvDbxNTZ9ka7Jh6
TbbGa2Jqqmw4y9ZoxlF4TbbGcRy9RNmzbI3muDy8JlvP90MuGcwH5tpk4CUdh9Kp9CqDyqgyq1Q9
p3raF6naF1H/v12ucSiLysOAX73YdoHGoVQ9HSkUFm+XZBxK1QuSowORSuueZ9uFF4dS70e9H/W+
Dk7WaOTsdDeifPp9X335bkRJA7HXTyxu5xCu53DTxOKC73E3Yn+gfZpZjPSxMuB8O+ITwflaX5az
SiYO1uO84FLW8STvZ7v1ztd+Lutme3C/nsb3LxXqDaH26MyfxukvFRqv8MjXb/a9qczNytzzfZBP
GmD2rm4QjMfdk5H2xZBonrU9ThVeKrGNJRZ7vD9InJnE872Pl3ooC2u1MVCLEdfFDrEyqOUn2hvx
Vcyuti/Fv1hiNiTa08cBWkwl1ts9pK/cZYuu4T6vasZXP233ifbN1r4a8VXtGcAA6KYSDZyo9uB/
0J1Oag2wcaqnfFKNiJr5t2r0pDMZ0nTQChOx/AAja5m0wkAs+7sAP8DImcRmRFSzI2qAkZNaA2ya
6qnca6/oA7U8Lkt2TQetsGeYA7xrk/6hGYjR7Iga4N1U4jiieAWVITEMMGoisa2v6AN1SEu26BoO
tDf7wLCPd221+4e2juOrrfZ0cx/v5hLHiNVWsw8M+1g5l3h7Hyird1t0Dff1cHZ87WNkW22kb24c
X83Zqxf7GDmXOO4Dm70iH/Yxci7xmrnXwENaO5AtuoYD7e342sfqdvxyYqT9OL6aMyeBYR9XpxK9
gRPenAOGfVydSzT6jqmHijxzmJM1b0S0N+Mr7mN0O24QjLQfx1ez1+vjAFenEg2c8GbPFwe4OpVo
jKVmHtJnGrJF13C2mHL/7fvd5cCq74g1we/TyD5Z6YPbPgjqXWwH8g4XPSh70/fNEkzQjbyn8vZF
oRaMULW3IGJa4iuWo1oYt3m+IFt1wKjqgFHVAaOqA0ZVB4y0otYDpFuzt21H+pmwrz8+PLx5fHy6
e/P4/uGv9z8tmrN8ef/x4cP266JZ4baFeWB88KyXp730ClqmiQrAqIXX1C+F0MF4nVDvZ7T6oZO+
xt1NS72PSnwBI3/+8Otpq/ZP0PnD49PD3Rf888cPb0//dId89fDd092fH+7fPnw80KzT6b98eP/u
w8NXP9zTEnzwhw/gcP/07vGD/v/49O7/7kFs//3t8eM/vn18/MfdZ4/f/fIjlNqe/PzDw8MTtXy6
++v9dx8fz/7/7x/w9+z/z97dv3/8/uzBwe2ndw9y8Nr3H+9/1Jqr2vrFLz/+/PeFVzhv9nHbPa+b
5bd7Xjfbb/e8blbf7nnd7L7d87pZfLvndbPxds/rZuXtntfNnds9rxvndbvodSPddtPrRvrtqteN
DNtdr5t3qBy3MxV7Aglhg6BBSPCs8M8KYZYiV32MgIv83bpKNa+yqxpVJpVS9jC245Xsaofqa1fC
aYThtCvhBE9O/ZtT/+ZkHKddCaddCaddCee7cVRPpnZKPqfdCafdCaevgpx2KVwQn6D62q1w+mrE
yWFOH6o47Va4qHpKHieQcAIJp2R0AgkncHACByc4d7obxSlpnQ5Vuqz3BfdO5zadblF0Ch+n2xSd
ugOnWxSdznc63aLo1E04rVM4Jb9T4Dglv1MEOcWOU/A4hY1TwDjNqZ26G6eYcT1Cj+DkzstDMHkF
j1fQeAWNV9B4bWV5Bc2p9BdlVKn39SmYV5B4BYlXcHhtWXkFg1cQeG1VeTnfy+lezva6UMrLyb7f
BrY1JnX41ctJQuVprw7caxX9WMrjp1JKy9NeHvZaOfRaOfTyqJcnvUDDy3NeHvPymJenvDzlNT8O
yuigjA5yRpATgjI3yPhB+4hBmRqUoUFGDzJ6UEYGGT3I6EEZGWT8oEwMckJQJgZlYlC3FeSMoP3C
oEwMck6Qc4KcE4ScoXeHAuQgvwT5IygDg/wR8plTg9IwKA2D0jBooT3ISSG356XS8VRKuJwW5LSg
tAtyWpDTgpwWlGZBTgtKr6C0inJalNOinBblrKgMicqQ6Prvqi84jX0wz0ZHeSzKY1Eei8LQKM9F
eexU5ovyrOOIAtIo90W5L8p9UUAaBaSnsj0v5c7Y+1elV5Qbo4A0Ko2iPBblqah0OpXSR4AZS7ko
JVdAGQWQp1Ly5bmoc7KnUnrIg7HVZ2VS+p1KXYcrj57KolKjOKVhUhomeTQpDZOmH0lpmNQhJjkx
Ke2S0i0p3ZL8lOSnJP8kpVdSeiX5IQnukvyQ5IckP6Q++pEfUt/CY1Bcfxdwvijr81LplOSUpF4r
KY2S0ihpfKN76/vd7f029X5Jeb82vN/G3e/H7jdWn+6QZiOuv5MpX5T1eak004Wt/QrVfqlpv2b0
7KYp/a6hhm6J7Pc2nm6gUseim/r63Xn9Nrt+v9zZDVX9c9EzILz+G9P2vFQanEopKQ/oqpt++Uy/
DqZf0NIvKenXhvSLPPr9GP3Gin6HRL/Vod+z0K8r6BcI9O/y+5fy/dv1/p12/3L69C0zG3/9pyXp
oiwXpYQpJ/RJX//Irn/21j9E65+G9S+r+rdOp6+PNuWuPsDvL8p4UZ63+OrDR+miLBelViWOh5FU
/3gYSfWOh5H64aV+GElyj4eRNLc+HkaSnH4YSTl0OowkOUI5ncw7HUZSbp0OI+n942GkM6NcvwCQ
LkoJFSSeSn9Rxouy15MxFB7aY+87330/uu/s9v3Wy/3MvjPY9+su98P6zlLf7+m7MH0/o+8y9LX/
vore17b7inNfu+0rqn2ds68Y9nW8vrrWF4TOynBe0vj/D0bVnZoNCmVuZHN0cmVhbQ0KZW5kb2Jq
DQo5MzQgMCBvYmoNClsgMzQyIDAgMCAwIDAgMCAwIDAgNTQzIDU0MyAwIDAgMzYxIDQ4MCAwIDY4
OSA3MTEgNzExIDcxMSA3MTEgNzExIDcxMSA3MTEgNzExIDcxMSA3MTEgMCA0MDIgMCAwIDAgMCAw
IDc3NiA3NjIgNzI0IDgzMCA2ODMgNjUwIDgxMSA4MzcgNTQ2IDU1NSAwIDYzNyA5NDggODQ3IDAg
NzMzIDAgNzgyIDcxMCA2ODIgODEyIDc2NCAxMTI4IDc2NCAwIDAgMCAwIDAgMCAwIDAgNjY4IDY5
OSA1ODggNjk5IDY2NCA0MjIgNjk5IDcxMiAzNDIgMCA2NzEgMzQyIDEwNTggNzEyIDY4NyA2OTkg
Njk5IDQ5NyA1OTMgNDU2IDcxMiA2NTAgOTc5IDY2OSA2NTFdIA0KZW5kb2JqDQo5MzUgMCBvYmoN
Cjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMjA0NzUvTGVuZ3RoMSA1NTQ5Mj4+DQpzdHJl
YW0NCnic7H0JeFTV3ff/3Dt3mf3OPpPJzJ3JTBKSSZjsO2RICBACEkiABAhJSJBFkCgosgYVRQLW
AmpRaKt9XbHVibgEixi7aKu1itZ9qftWUOveQma+/7mTBK18X5+vvj6+j+/8kvO755x7lnuW3/n/
78CTAQIANiQVNE5sqp8srF3YDHD/NAD3BZMn1k2CDPbXAIc7sJR3cuOMJqHUUIXpLZgum9w0u+bN
4LsZmB7A9JXTmpumdL2d9RSABsuz981oChesfunCFgDyHN7vmDNxesuav29cCWBIBeBe7VrZ2fP6
fb3nA6yciGV+0XX+Gt8c/5m5AGvvwvTHZ/YsWbm+7oMgwNnvYvkHlnSu7gEHqLG/RmxPWrJi3Zlv
VjdvBlh3C8DYFUu7V14Q3PXnCQCWkwCtU5Yu7ux+UXrvZ9jWAixfshQzTI2aeZi+EtPBpSvXXLDo
GfkgAFMGII5Zsaqr8271gR6AW6wAwtkrOy/o4YN8DZan4/Od3bly8bQPznkd4I6tALpf9qxavSZ+
AeB4D+fR+z3nLu55ZcPLRwHW4POwaqBzy3Hyxj0/ym43Vn0GbhEofrWi6Ut6/f3Yuq4T1w7t0d8i
7sGyamAgAawnamOzcJ7K8P45+luUlr6KhTSHvQcmAKukGZAgArMxwnEPJHJUO5jDwIHIXcsVYpPp
iSt7HTzFciIwWlHFcioVo7oe+HgEfPPpjNKK05t8PsAfdjPvjbXCI6KW3O4D8nN6T9XFHaUjBSIO
PxL2oQS2DB5VHYSb4TRQtcKDGG4aSTNvQoB9Fs6mcW4rbOCi0MNFiQavhzDsxNCM4QYMl2LYj6EL
w1JaHvuZfro++BJw8k44wj0CS/gb8LoWQxEc4Tdh+iAcUS2EDapzIFvp0wVHhKvw3kNwREm/nLji
Sh/h7oCV3BrI4nvhVj4VnGoBauj1dH1+FVwLzOH2wgHV3dCC13lcI7SwnRBS4gfhAM7RdUq5hUr8
gLgWDtB8brNS/gAtx/4T6z8A7eyNWO8gXI/r5RWegVxuHqRwxeD9d8+QRBJJJJFEEv9zwN5DiNWa
naUknGhIiQHIKSRMMmhJplE2jM0yESD5JjCAwZpmSA+mj7Si4yVep+WzrJBpzclS87yOaLJkSWf4
fgaVRBL/G0ASUgUdfCnGQQQxHsP3FA2yRmEtaJF1oEPWgz4+RJWLbAQjsqSwCUzIZjDHT4IFLMhW
sCHbFLaDHdkBjvgJ9LKdyC5IQU4BN7Jb4VRIjf8TPOBB9oIXWQYfsk9hP/jj/4A0SEMOQAA5COnI
6ZCBnIH8JWRCJvIYGIOcBVnI2RBCDiF/ATmQg5wLuchjYSxyGPKQ8yA//jnkK1wABciFUIhcBEXI
xVAS/wxKFC6FUuQyKEMuh3LkCqiMfwqVUIVcBeOQxyk8HsYjV0N1/BN8Y5uAPEHhGqhBroVa5Ikw
Mf4x1MEk5EkwGXmywlNgCnI91Mf/DlNhKnIDTEOeBtORpyt8BpwR/whmwAzkRpiJPBNmIc9C/hCa
oAm5GZqRZ8Ns5DkwF3kutMQ/gBaFW6EVeR7MQ54PC5AXQFv8GLQpvBAWIrdDO3IHdCB3wqL432CR
wl3QhdwN3ciLYTHymbAk/j4sgaXISxVeBsuQl8Ny5LPgrPh7sAJWIq9U+Gw4G3kVrELugZ74u3AO
nIt8rsKrYTXyGliDfB6cF38HzofzkdfCBcgXKLwO1iGvh/Xxt2EDbEDeCJuQNym8GTYj90Jv/C3Y
AluQL4SLkC+Ci5EvVngrbI2/CZfAJciXwqXI2+Ay5MsU3g7b429AH/Qh74AdyDvhcuTL4UfIP0J+
Ha6AK5B/DD9G3gW7kHfDHuQ9yK/BlXAl8lVwFfLVcDXyT2Av8l64Jv4qXKPwtbAPeZ/C+2E/8k/h
Z/G/ws8U/jlch3ydwtfD9ci/gP+KvwL/BTcg36DwjXAT8k0K3ww3x1+GW+BW5FsVPgC3Id+m8C/h
l/GX4FdwO/LtcAfyHRBFjircD/3xF+FOuBP5INyFfBfcjXw33IN8D/ILcC/cizwAh5APwX3I98Gv
kX+N/DwchsPI98P9yEfgAeQHYBB5EB6MPwcPKvwb+A3yb+F3yL+D3yP/HvlZeAgeQn4YHkb+A/wB
+Y/wCPIj8Gj8GXgU/oT8J4Ufg8eQ/wyPIz8OT8SfhicUPgpHkZ+EJ5GfgqeQ/wJPxzEo/Aw8i/ys
ws/Bc8jPwwvxp+AFeBH5RXgJ+SWFX4aXkV+BV+JPwl/hVeRXFX4NXkd+XeE34I34UXgT3kJ+C95G
fhveQX5H4Xfh3fgT8B68h/w+/A35bwofg2PIx+F4/HH4AD5A/hA+Qv4I/o78d/gY+WPkP8Mn8Any
p/Ap8mfwOfLn8AXyF8iPwZfwJfI/4B/I/4QTyCfgZPxPcBKGkIcghhxTOA5xZKCfa7ADaq0aWFbF
KSc+hxdWBfwpgEq5IQq8wPOCgAV4UQD8oSmtMGIqeJ5TflngWTWtp+IwhbHvxXAlkcQPHRqdhuo2
ITCqW5SwcArDulWLgloQRBGFyKtF6sMJvCjqxJFWBIGKWhBYEFgtrcfxmMIq38+gkkjiBw6tTgsq
lSohMGofUcLiKYzqVqS/1IAKGjXVLc04pVtRRFFzoqgCUaWj9XgBUxpRPH2nSSSRxLeCzqBD3XIJ
3VL7SHWrHgUkHGiMoQg1Gl4AUasBNWaIGrVBPdLK6XWrS+o2iSS+E+gNetQtf0q3KGH1N3SrQaB0
tVS3uhHdagyakVYwqVZzajXVrYHW40Verdap1afvNIkkkvhWMEgGfK3lE4aR2kfUreYUIPHiq0Vo
1FotFlDrtaABrUaj1UrakVbQGmvUvEajArXKQOsJIk/tcVK3SSTxXcAoGaluEwIb0a12FMO61Wm1
Oo1GRx1fDTrWWszQ6L6iW42GOtFUtxqVpOhWLVB7rDl9p0kkkcS3gmSWTumW2kc0vdpv6lan02s1
er2oBo1RDzrQa3V6nVk30opWi8ZY0GoV3dJ6olrQaiRtUrdJJPFdwGQxAc8LCYEN61Z3CpB48dXr
dQad1kAdXy061qhbnc6gt+hHWkFrrNMKOh0PWt5M64kaUac1abWn7zSJJJL4VjBbzVS3CYFRv1ZQ
g04/imHdGgx6o05nNGIBrckIejDodUaDdfQ/vqI11utEvZ4HHW/RY321VqT2WHf6TpNIIolvBYvN
AoIgfk23esMoIPGBldFgkFCpkgbfbNGxNmCG3mi0GUda0aNu9aLeIIBesBr0VLdqgw4V/P0MKokk
fuCwOqxUtwmBUb8WXWbDN3QrGQ0mg16ijq8eHWsjSChko+OUbg3oNosGRbc2Wk+jUxv0Vr3+9J0m
kUQS3wo2p+3ruhVRt8ZRjOhWMpoMBpNZi2+26FgbFSFLTmmkFYMR3Wa10SiAQbAbsb5GpzEaUMHf
y5iSSOKHDrvLDqKoThhG+j6KLrNRGgUkPmg2mSSz0WCmL6wGdKwlMElGs8llGmnFaES3WW2URDCK
Dgn1rtVrJAMq+PsZVBJJ/MDhSHFQ3SYERv1a1K30Dd2azSaLZLRYsIDRbgETmCXJYk4xj7RilNBt
1kiKbp20ntagoX608fSdJpFEEt8KTrcTdas5pVu1Dq3rKCDxD0QWs8mKSqUvrEZ8ITaDxYS6dY/q
VjKh26wxmUSQRJdJMpl0Bi31o6XvZUxJJPFDh9vrBrVaKykJah81erCcAiQ+aLbZrHaz2U4NqAkN
tBVsFrPd5rWNtGK2oIy1FosazGoPraeXdNQem0/bZxJJJPHt4PF7QKPRJd5UqX1E02u1jQISH1g5
7Dan1eKkBtTsdoENHDar0+63j7RisZqsFp3VpgGLRrZZrVaDSW+zpKLuk0giif9++II+0Gr1CYGh
Xww6I9gdo4DEB1Yup8Ntt6W4TWawooF2gMthT3EGR/8SqM1usdsMdocWbNo0h91ulyxGh0222U7f
aRJJJPGt4E/3n9It9Wt1Eji+odsUl9PtsLlTsYBNpn+5N8XhcLvSXSOt2B0Wh93gcGrBrg04sZ5k
NTptPntSt0kk8V0gPTsd9HpjwuO1WgH0Zkg5BUh8IuxJdcsup1e22sAZkMENnhSXNzU7daQVV4o9
xSWlpOjBpc9McaWkmO0mtMeuf/unuZNIIon/ANnhbDAYTAnLifYVjFbweEcBiRdfv88b8LjTAljA
PSYIMvi9njRf2DfSSqrH5Uk1e7wGSDXkeD0ej81l8bqzUt3fy5iSSOKHjrFFY0GSLAmBuVC+Jjv4
/KOAhAMdDPgzZG96pisFPDmZkAZBv5weKAqMtCL73D7Z4vNLIEv5fp/P53Db/N5cOfk1FEkk8V2g
oKwATCarR0m4Ub5mJ6QFRwFW5UZmRjA7zZ+V7U4FHxrodMgMpmVllGWMtOIPeAJ+WyBogjRTcTAt
EHB5HUF/Puo+iSSS+E7ADH8dlhVYGiMpGHgY/douwjAw+u1eI6Df4DX8R5e1Ovr/pcBssdrsDqcr
BbWdMLPB9IzMMVnZoZxcCOflQyEUl5SWlVdUjrQxsW7S5Cn1UxumwRkzGmfOamqePWduS+u8+Qv+
uwfI/mfVVHAZshckbMCAPkYW5EI5VMJUOAMaoQWWwTq4Dn7Fbo7HgX6v2BjIgTDenwDT8P4s6ISz
Ru7H3zjtT1e86+R13/h+tG8gUtFcVlpSXFRYkJ8XHpubE8rOGpOZkR4MpPl9steT6k5xOR12m9Vi
NklGg16n1ahFgedULEMgh0SdtS39LiHkRvepNXc4nfL1dJRNlz72R8H8tULuf6mU+i9pz7+kvaPp
M6JgjU4K1E6kDffDpLejYIkSaxRoL8QyHXsarlTXvTxQtyzqqu3u6MAaEwOSLzrpo/Dwoyht92s1
tYHaxZrcHOjXaDGqxRiW7eknk8YTJcJMqqvoZ0DU5+ZEzaEok15Hw/JoZEcHRgITsSW8Yzl1ZyA+
uPOrtwCrjcQsiRiJ8rVRQenXtywa6YzCDl9/zmDfzgEJFnWEdN2B7s4FOHOd+Iz9wKbXLW2m81hH
Q8dSX1SFjSvkxhxf3VJfX4BOR93SDuTARKx12nzMVte2bPMPuqNmvNZFTaHoZCwxef2bbravzrnM
R5N9fdt80etmtnz1rp9ya2urEx+4ry6ADWJjdctrcCjOcG5OYkzDE9DdsZz2ubyTPmfdcl/fjsXK
s+5UnkEpWrcUF6bz35Xq66vrDtR1d3bXJFqvjUaalQs0z2tRBohTN7F1OGu4AN5RKXc6Jrb6E5Pd
MKullj5YoHOiO7HsozkdwzmYUTdy00efoB4biPq6fFGY1RLAomWUFpdBX1eZsnn8rQRrNZ6qFeXS
pYCv7zOIko7A8WNfz+kczuHTpc+ARicFJnX09U0K+Cb1dfR1DsS3LAr4pEBff0NDX09dB/ba2IK1
BuL37XBHJ+1sjUodS0kFzj3dAZNmtVS7/abWkWTjSBJwS+HG0irDwVnA3/rhC84yNLf4fThRs1ta
3ThPLTTejPHElW4k3LhluMbD00bnaHHZ6PTUDkf9fro7dwxEYBEmoltmtiTSPljkvhMi4RCuRwe9
Mzhyxzab3tkycme0ekcAe7lLOaJsUTFj9Nco2S11SyuixP7/uL04cT9qqW1h3UxrIsa4WRrThFDp
VVFHCONjQn24CE8EolIoyrUMuqtafZIJTwC6ek2BhpnzWnx1faO7IJEzPFK6D3CrBzqX9g1LiW56
PApq+gPkspn9EXJZ07yWQxKez5c1t9zJEKa2o6a1P4j3Wg758GhVcpnRXJry0RQ00A14JyMqt9yH
IgBblLsqJUNJdw0QUPLEkTwCXQNMIk9S8hC5EFE3v/tOUH7nbZOMyxfpfkYnlUSeJ8/uNsmPYfgT
hkcxPILhjxgexHDrvqC8H8O1+3zyNfvGyPt2u+W/77XJN+91yT/Zmy1fvTddvgrjkb1kLxY3fkyu
3O2S9+wOybt2+2XYTWhHC3ZrpRLjYflw+DAb/jWBQ9IhxojPfDfxfdn7JSN94fsi8gXb+xmRPvV9
yvg+aPyACR+rPjbjGJv3dM/TzME7x8h3HjTJ4YPVBzuiPdGev3BvvRmU38AQfpN2cPA3OBDaUfwu
jDzZO1Y+iuGJXp/8eK9JHsTwAIYrjsSPMMb7Sfx+0n+HSe65g0i3+G5hdmzPk/u2h+XtvYXyZVud
8jYMl26tly/ZapIv3lohb8VmVh247kD0wEcHVJHribTAtyCygP0EW7yo1ylf2DtV3oLXzdjjJgyN
vR29Pb2sZPTLdlu2LPB+2eXMllWsX7aYs+WcXGN2yDAmy5iRaQimG9MCBp/f6JUN7lSPHn0WPbou
evRg9EbJpNPpDTq1RqvjBVGHTo4OPSCdZNxiZCL8Fp6JsFtYxgjVMAN6QWVEi18NEc8qTDwAj0Mc
RHelKBsrRJktF2UoE+XGQhI1N0BDc03UQvDaVBMtDDUMiDArWhBqiKob57f0E/KjVsyNMpfh8jRH
VZfhLmrG83/e/JYB4qK3L1HMAcYGyJZLLr/cPRprbQ15ot0NTS3RHk9rtIBGfuxphRBi9ZrVq1eH
/i/oV9Peu2fV9L+nosaiM/peYGL/++8phiP6fmAiGa761TYwio2OphK/XwGEzlPy13yjO6USHhO8
lf5XXu4oyCP8NZerC5TPcOKvKfzySDzWHf/sP3PivglxOPz/gBxlsr5tv+QKcinZQprJWrKSnEeW
kQjpIq3IF2NqFdyuFLoR3iM+4iIGQkiAmIgAJ0g68RALUYEG08ewzKdKyZ8q/CmpgE8YZbZgB4YH
4C/wJhyHGDHAEfxZgj8H4Hr67UjESzJJOZkCH2Dr9F+mroV+OIRl/oB1XoS34SMiknnkfNJHrmT0
zGRmHpZzklqynZnOnFAFQSBrGTNZwt5HPiU8sZEg3Ad/ghfYaPxdch28yuYyB+EC9H2fIkUkwt7I
ZrMyc5S5EXtiqIEQ6N/gYvFivZdnVEBD+LGXH1MoP89v8pvSkQiW+ucWDk7QK2yhrxgMPIq0EncL
rZ0RsbMswwh/5uBl1ZPsyzO4do7hZqhJW7jtzaE3ITxUEK7OzyOsnyXYHrNybOy+sWRfbAW5kjt6
4iVV8J9hImKbN7MPq3S8VWmzJBLgBWyUJfC4ke1ge1iE6nEQJGGV0CuohLA6omawg+OFGKC6MGwu
L6d9BJQfla7q9ap+DLx16CAznQb6hvRgrJs9iD3YoCqSM4M0MA38DKGdtAuryCpmFY8tk16ml+8V
DAIQt2ikZtQ4qLrbLn1K+ymEajqONuLPYEySudRvMxCBZ2xWs8NLHOzB2LbBQ4cGybqZe6qrGurH
V/2kMdb9GnmJuPHnpdc89Yc2ro29csNtsfc3nv/gZPo8N+Hz7B15nol4kEUsE62NbKOlg+lgOywd
1h6mh+2x9FgNZlC5MRCVSjsI9zikz7/2PBIj+IvHk9ISc3ERkzmWZBb77WZ276HB2LbGvZXj6xuq
qvfMJOsGDzFVsbdiwdc8kwfXbiT2224gaWs3Hqr3vBYL4tMEYj9ilpPtOP/5kaCRGBknyERGmYVJ
mCmHalLNaJkX2edVuDuZXjTRdOZxZugjqEnAwiyP7f3r78n2IY45QUd3NsOzy9gMbC81IpFnGQk6
6FsrE+ZmcLh0OAAI08q4J9hltBLDEx/W2xA7rHpY2QclESO+AJPfMqwVtwKtOxB/N2JQS6XgpET3
MT5FYRgPsupwft42bmxo26bfqYmfqB4++U7sMdbOW7+8RWjBfnvir3ER7kNw4HlWF8mvY+o0Uw1T
7WuYNZoNhg120b2vwjzVzJgF/75ivo5neJdzu/JWne7dDjqiw8GaEnut7Tj+5ue1ESsjGEggLSMz
gykuMpeOJ4UFdofdzEkZgTTeJNkLC0q4yMQpU989cPOx+qk1E6dOPXbDbe9Ora+JbVq+YcPyFevW
rWDeOxx7tr2zq3vRIhI4/Bvi7Vq0aHH3othrh4nhrbdiH8W+eP99fAqCJ7TqGPc0GKE4InO39vKE
53W8gd1PjLcYdIY+lmNuAbaaXYUyCbd9WiAdL5cU5VXTZ87PyyKoZn9xQQk+ZSnGVMdOeklF7KEp
W3OKilSkgRQSFWv5xGRzNVadCNNxH0JrMJX7ADywI5Jn2KiXShmT1eTXp5uK9EWmyaY5pkW2NTYN
MEaj9hqLwKReSzqgI7UHelJVqdQFsSsrlMqI27fYid2+U5akkeWSPseHMpfjurUpz4ibuba5JeI2
MlqnzLidYSbkrHROdc7n5jvP4s5y9jr0ba10xkNZpLgkiGMoLqJzLARMJcFCn8pm5XElBD839cSq
S4l+5rozL96w4NG5vsnEtgMPzIzLd80fyGR++nnnCzPOu332maumVZIGefzfnr08tq358lQ62p24
OwLcRxCBqyM9ymjDlLRatsCtNReEtGOltLGBggpthbFobFFB0bh67aSCunEzSat2pmtWVTdZru12
dZadT9Zr15S5x4/z7u9A7eTl5Vwjq4sEvd50jdqV0VcxQ26XGTnfsT1frhin0rFsTWJr4c4yO8qP
h8NtYdxgOB3V5nJknCV6quG4Q2grEqMMpAUzTYVe3GsliXlAvYeI6avJ0ZnB7ZioZvMS1UB+RdOc
5jd+cSj2RVPmnA+7Ki4Lp+dU5ef3Vc6afcYF2Tk5YwOZyzMWvrQkfRZJ2XX5X+pmNV67ufBc5r7s
nrZl90yorq0IkslF0yw+1+TaCZONEks0GrOlelxuqWTWTRhHav3j8rPydy7c+Fu3QchGxTXHT6Il
OIrehR7OjUzPEgivt+vDwlRhkr5VaNavEM7UrxfO02t1jfoOfY+e1fO8wKuJfh+1IL0cy3GswLMz
NO0aRiOodaodGkKMMh9GcSpTVoizU0BPEZwtZaoK8DTZJr3cphokbW0kQLe8CY+XQmSu/dHYrqEw
c4hse3ToodgMMjd2I5lPUtiOk1czKUNv4x64AfdANj5vCHoiZ2iV5RfdYq6Yqy9kK8VKXaFpAlsv
TjBNdbSITdnLxHWi5PWm7MtIuzaDl3mNxnAN7/Kl7ZAjWlOpbN3ukzVWPEFy0UvQKI+LOx6XOHQ8
PLrC1DIqy0sSS4sn978ubWItcSC2xPHiJVz23KYFH15z8Iszsuc/ubR6TygtEE4v2Tt+3o3jc1SB
oUlye3DDg5Pmn0m+XPPw5Gn1pDSN1JdM8WTIkdqiBoffJhvZKbE3PmHYcHbp3dSWX4rjnsIdh3QY
B8sjDXnqQk1eWURdq5lQ1pja7G0MzA52exflr9asMayRVrvPTV1davbw4f0+uz1ln483C5X7eZen
2G7XZeF4JXrGVxd/7czE5TGjATmOY8YR04lQjk/+a8dnYr+aAokxj4yWfHUirLzNSjPpwTqledrM
p6+49OUZ8zvmnbmIlD9Xf3tKhvvCWYPP2Kff1jX3qkhTd6xcTs9ODy4qyukYw+RnpU7L8TeSE6sf
qZt6Rn3DHCLd/zuSd17PRisXe1HvP3zL2PIxORW/i+1Ma2usb0tNtVmNmrGBDT/Plj1e3B378TwM
4e7gYXokD90SsgNNEn2/ZK/leIaw0MDMZ5hsppqZwbQzq5gNDM+gQ4WOLVrthMJxk7bhHsD9OlTQ
pmzV49sGCRorXF4uNLQw1swcHmJVV6huPTFXdRfxoAXsir/CTec+gVQYi2fTYGQ2m2XNKnSOy5/g
nJ7fTNo1raZ2d2vOwvzm8ubq5UKXdrFpsa3LfVbBRsMa2xrX+gInz4SL83IiOU057cWLcs7N6S0W
i3UpOSrWt9+CK8e6PH12elzLLnep3Q7Feim83ZUzvI41GdslqaxPVhO14mopy4m72FRejrEQPauq
j+PJ1UaPb7u7oLKgoYAtqCxW4VNW5mzNUmXl+Ezm8jYalAPcqvKn0dUsLiopLaaXoD9xfOMJRRJn
uoEkFtkxnliUlc9UchKi4KbH7oi9cOOx6dPqL77+ovVkChGIlZRvvWz/1bGu8zqDDbIno3Zaamfd
2DHylB7/5lCo7qoLfHPkYA657qGTE6sqfza/51cT+Kp7Luh//bHblt9UwVf+gRkzbZ7ZZCoNVNb4
dQF7yZyhzVOm5hlzpMxVdUs3WKyO8VQlS+Nv4OnwoaKSjkhteVpVsCpralp9sD5rnjTP3G5rT5nn
XlhxVsUaZh23ybh+zMYKs9VXtt+Rs9/B++jfmt7Hu6wZarUnA1VSXbDdo8zmiDaoj0xPhBFtMAKv
oto4dR6UJsRCJw38CUdjVBgjc0ZLFpVw2R2LlsceOjr1l+4x3lUdZ1xdUjlNP/eqVc3XVDd1kenE
sOPZM+YviF0YzvJMy86c7Jczs9MD7WW5yz0sW/Xr2JGz1641CyTd4MvMzt3WXlCcFap8cM+HJBdF
E/t82/qfhnypbr9v6ZRJ7aluu0OnzaLzMx29xyvxbZF675MihUbOyDtVMifzY1RhLsyXqaq5al5L
nmc4/kXheZH/ywxVu2qVqleFgCdm4NtVuA0nIeFSVh9P+Nkmv4U6lnNjfeT8cdS7ZF5A/zIj4WEy
9PsmeS9qUkAbc3tkFs/QL8thyIWYodawqos4ji/ly4QGfqIwn28WVvKLhM38OQI6LSLD7unBgxk0
aqISeG49OlQsRxhWxQuiWqPmNMBxDAzE/xoxa6RSzo8ERh0BnawjHJVzGzqdbbj1Uc30otgfqgL1
dJjObYJNnKqtlbRtk4YGBwcVFgfx9l3V6ulqBtpa/X58HULlaxneG1u9ZOi5JbFNTAa5L3TvvSQ3
9hR39ORKxj70Pn0/O4InzwCO0gZBKIR5kcoGawvTbFvGdNt6dD36cwOixZxzJXglL9PhvcPLeL2C
Z4/I5u4R7JvNOUajkL4JBoq9Ob3C3UXS50MFOL/KpjuO7nc1jbadM+xmJE5knPWvOg7k6y6G5etJ
bmDutJanfjF0PlNz182zZjedu3T3bTFrejh70znBqvlb0ot8C0trcn82pzn1Fzsrq3LJH1YcKKsp
4446s0K72lbcOFb03EMeT59qltjY73mTo37oycnTLXomdjnjcjVRz2wJ6u5s9EML4dJDEIpvPYh2
2TaQuJoG4r+JzFbrSsPjkUSP0xNgM1RZYlgd9gQCrUyraq6mNXVO8Dx2vdoYtlRbVll6LSqLJWWX
TuXLzcvtyO3JVeXmZuwCiyV3oBiKZxS3F7O+Tfy9RThJbdLnBYqpblMIJwjdsFCIQwfsqxbLTo1W
Blox5fTiFRNlV46rkpLSQhP1aXi2/abYO4sXr1q+uJPIBxb+JFK7MisndXZJ6Zb6mbvHV9bPqBp3
df2k7RX5ze4xZWeW1W/xLOrsJGlH+olvSdcKm8kStsZ+4qzx+XIKK8sPX7rzcElpODvoqXHG9rty
JJsdtYC7hB+Hu8SAHntVJLvVPNu9mFmuP59Zp+ftu0XWsVswbtLAeiw6IMtyRG6UWQduCS++S7ZJ
n7YldsOps4fuAtXoITO63vy4I7tWxk7eOfQJk3oPEedd2x9bfdaayg0bOzu3bxm3bBHzzhOxe1tq
irij48oWxh58es/RSo/t5AKXv+qPdDXxKVWf4FNqYXIkRb0rj4/wHXwPv4WP0u94JdwuhtXsIiI1
SEbJViqqRAA9r+4ld+vo1qVOH9qd0Y2Lz+v3m0Z/VJ+ceFRVPFTPXDK0gbmXOxp7NRbH8OORnt/D
ntVQE7Fyu/KYCNPB0I8tyC6RFVgWaJ8mtR7fWbRh7Qwtw3A4OxraKzXeocIwKn2kU3Kqy/eGmpgN
Q5fELlKFVP2xv8VeHdqKvdB9+xr3Bu7bIFx9CIyJ/aodiL8aCeJWDXAhIeQIuFvszalncv+HvS+B
iuLYGq7qZaZ7hlkZ9mVm2AQHmQFEQBQGBRUBFxB3IruMIowwiBgVRKImRk1ciVnckhg1RmMSjVGj
ZnvGaKJZ1KcvMYnZE41RY/IiNN+tngaJ+r73/f85///Od05sqbm1dNW9t27drZvBIZ/JzpPP0c8M
8AhZaQ2tCaVCCTLJEECFhvK0VZWmqlE1qRiVyrCSZ4JW0Z7W0JEwKBTJVCrzfIQi7BHYfx4r85KF
y2jZvnDtzcLLoscZb9URjEUzDSJMKhYxdgVBDodNNiGdFpF9vkOCoa1fIiGPvVQm7H1aaBXy8B7c
ugortlgCq+L6Pz6u4tlBaVlYhpF3grdwltpV0CsXP4mrwKXeljBS2OKVG2CKGZA6YH/jb8IfFIXD
sJ97D9hfxd0fZLfQj9o4O1fEOblmbjcn4zhWIacxq+epJrRXhVQkKKA5uol1b30hKVBafFr8PTae
/VVo7nhXaMbNVCL8PNLhZE93XKTMJJsAKvSSuGayPYRnVsloBb0Kc8pNiiYImjchGtO0ysOosqns
EIMwIo9IAN1xI06MTTvixOg5Xke88FBdPH2pve3GDbryxg3M0UcxJ/zenkbkq3fn9/Q7sI4virMH
TqCw1yofGoz+Spmnj4/Cq6mZpBL8m7piAdEndlv9y3/yhXv4/4Qw+p0hmVnvt03dmxlmqxztmOnr
IxN2UJ/gV0p2pKRlatQ4Rm9Mioutn0SNxnpJyq8CFiwKtRvAmj0KqxYhJ3ngLmfgFMngtOvcmZe0
rqwAc/XW+8C0PezpWyOlkyI7C3N4oFf2IxoEcRCILmMXw+EApUVJI95DoVFq+UCFURlBRzNWhVWZ
okhRjuSzFHOUrfxDytX8OsXjSkM/xQRFE9XEMgoiz4FqfSLb7KFNpEjBUgqatzJpTBHjBBeADPCF
ZkaJGFrO03IlzxJBUCM12JjOI/vgMLAt8ldUQIClkFAhOtLE8opmONZmAXsMYZ/FAlSBT00o47FZ
dlZoEX4SfoOftfh1PBKPwK/TX3c0UovbA0BGvKgfJYo5UTcctGeNpOxyagXVLAcH3puikEwrM8mG
4izZbLkMUX0wllFyDlMMLaPpUJkN23E+LsJO3ABHB1NyOyAqb0Z7lXDYj+wFpiElpiQCqGaGaBQg
wALSbAESCt00EMfBz0KFyVOovvJsCtwVCtwVqkTeRDnlHqLrDEN267LzxtuVckxRLSQYkskXi/mu
CeBooMKZtVFYpBoKGScs71gibMTvUUZcRAvtFDgUO+gCt51glwKtWmQEHeyXr63Q1DO030q5nPdd
CVuim9cfDSdGQlSHHqAOzUaz3Uz5yZv4V0zaG5I6JPZCVIe3xdciru6OUe9wEpYOSZ9wYcvPQjM1
e/mb2ROnCHUZfQbUThlUXdJkCTfTt8oOp4+fKMCGxMamvPpQ2iS9LysM8g0zTUCSZRsvWjYjarTn
eWj9tdHagdpc7WRtgd8o/ypthX+TVqnTLtAYNfHGwcY6I2304lal6UbqmnS0TmeQr/KiNQanETs1
GM0LNAYaNBqziRDF6ZsMQJSk4yE2s14uhC2JlxQ9RC1imNZxBJzRP5MEEhaq6+kpMTgmqVdl5tJZ
k+f2jgwHl9UiTHtRaKFaW1/PH1P62HKGTxrlo5ULNXqTMbu9HxXS8Rl7OjgubsPsZ05lggzO6Pya
rWB/Aj/n4H4U0tlsV4PscM1QsMG8OtH4aueX9iEAKH0DfPvh/gGZeHjA6PhyfhZf7znbpyHWQ0YB
r3T+FiaITgPH0hy+KogxyW1yp5yWy5VgNEyWef66eSZ/cWt5mAqhBOLpfEP2k6QmpMxEoWQrJLFk
LAZLf12CZbgu0zJRV2CZriu33K9zWUAsiUMLdsxCiRIqekcYbIeYofJmeqYxusIW0dKE/SnMA2mp
EJYKR/YLl2f3bsC9loTWhkUn548acyDv4DO4HoevwkZH1ETh1hLblOheSRPn5a0bt2ML/vgfwuX0
OFw+pcJDre+XEDvU0xAaMPD046ewPNkibBtWrNJrBvZKSfPXmQKTjhK9BmEKmy1GC9F2f8w8CucX
TcJN7KQmklfnOS1v55t42m0BxAcXovLvsvVstmAVmgUrG8K8eGsk86KYq94GVv4MzKlDSfZwnZz2
WJlAZ9L1NE17apuadY/oKJ3O0+6JuSYkXyHfAFthdZtmKZEcD/ODBTYhP1hGDHJB7bNnhN3Cfrhe
xC0tKx95ALdQAaC/zuMI7Enva5/yeNvKTfQmWJ3EP4yYk1hoVyLQV4ilaNodtmggYqHFsIVYHo62
kkUtFjFZJm6sMo4dxOaxRayTZcn+kbY+cma8jGIZVtYCd7HMApqie+FIajDOoWrxPEoWgkLoQWgQ
XYfqaFmhO76BHw4OyASSdgeVK2M6vhDyOr7Aq3AlrmRP/2EFw/ID4w0TDgJE3iaWBY+3BxF8aZbj
lSC5MpriNOo5qB7cF7NCkyhSoCYAUhvVdnWRmnan/EDHozRJY+5Hys7PXwK1Cu7i50S90iYowAxI
xExzcS4lRdt9ghLpMWpt4ggqncnicvlBiiHKKdQoZjw3mR+jqKGKGQc3jS9XVCgbuSbeqZilXEq1
Mkv5VsUS5eMQ0z7Or1bcwLdYk4qiGCOlZayUiUmlYplkbiAfp+in9GCIX8cHxyVSJigUXTWe1ETL
xgMOFEEE+s7YB3oFJfK9oWiiMKX0WACccYIIcvImGQtOMM/qcRAbgvuw8XgAC6xnx+IJbAmewcIW
sFopqJRK3PU4F/QWFGQTxH3whMKTe1uoEcYJvwrtUNbgR7/GetyE2atkU+jj7f1gYzoZTH5QD2lS
oo/tTiXFcAGUgWM0FOKAaC5RkUMN5iZT+VwFB1aJ82jE9XQ92yCfw89Rwv4BJUipYGUsJ+cYXs+H
8FQU35+n+GYFrcAQ9Ss5OQJvO0qeLJ8tvyZn5C1AKwexOCOjiYNwEXSSNlFmJo8NSM0HAIbUFMAV
hZJhIBK4nUsDu28VH2Bb04jxJ0q6cObiI0e07nAbYA4ibi0p2CPEPBaazURpu//LGCFDOAwnbDyl
7biFD+B+OA1v6/gd/yB4U1eoS4INn+qIBn06tvNLZh+zEGmQDVXYh2p82Wg/3yw2K3ACOyFwOuvQ
TA+cFV4b5eyjwr8YjRbvXnaVJrFXr9CtFq1qq7e3zYhtrdbX4qxxWBNpjKQiI+Wtfgdi3Y/vRI82
jphR4gdadF3GNEGNeyZ0fMQq+IYkZ9YvLPGORx/gI+ZlbY/ul+zh62PP6FfTO2hsREJtxsZz1eVl
OHJD2+oJx6PNyRgvwPFYJzyOw3+Qeal16Qmh0QaDZ/RD3ql6X5931t//BITBvKxwaJoOazRRh453
MED99s4f2FSZAXyFINBvYZk4M2icpkLTxDb5yQxr1VoeBbTR3pxuITpolPkoW7n9wSJNEDyLZLl9
Wy0ijq2cKFGS1dVLeT6dO4+bKly4cN9yu0bYiivzd8785BthWcXC+KrYXkNiVzxMpYPnticyIklm
6Dg/KE84Kfy4drMxqOOEWvEcSOx42J2ZTAvqhZbYQ210Gp/iFxtgpzOZHC6Hz/HLCMg2TjJON841
qSNM4Fsa4PCRMExNDqgXNGiJs2bTYq3WZ52HNi0Mh4mZUGgMCwtah7y1KEwb1hRGh1mjcFhUURT2
Xyg7EElSAyT/Q56/XiaukGgvLW4PlO1Ob7oz2CSf7U7SdecwE+N1akxdX3V94oQSx32TrjTXvTEm
3ivFElWS/sjjG1ZmzAgL6esdX7A/eEhW1mdrnvwqe+iguEjhpN7m4x2078nNzxm9DNFewslIK+zQ
xM4vmCuwQ57IhFLtkcMVw/1namlTbxXRhiCKeuS7Tq3FwWtZb52BakWvhQQs5A6YgQS38KVdJvtE
UC+MIoIXGkLpbuMOrmQP1JkrQlvh5mknb+YPy3ijuHxBBq4U2iLGhC5fXjs/tro+ZxgegD1WfDoy
O99ixp/dCqF6adUvPvnMmnDAk+xUO7MIeaFAVG3PD6MsinhqgGIwlcvmKgarc7QT2UmKggCHbDpf
ZCjycVGNvEvtMhjwL4GBHn5b9VrEabl8rpSrE//YdZuHN897t6KDwdZgHIhbNQeC3DEieU7f5cR0
nSezO6IiXJcCXijD3YlTpr39GLf/5dozqZFzzi0UXhDacAGOAjVpENbT05yVizj8c+vDeVbhYmw0
tmE/7I0zIchvL5hZW9UAEmiB6LJFFgy6024Pg9irzQsrOfVWnUZF/pKDv8bf6A+WjdN5tGqmQBBP
qUBqLoObKSqxZDGlkJycJj4Gwu4nH0HY7EWOSmhCPEgR2Qa6JcA3N3paNvYWbgpt69df+GxUSxzr
IdfnzOBvtD9K19wwvv++kifSIExgrsB5iAAvssCeNMJ7RJ8R8YXehfEO72nx87g5HvWhc+KVXmG+
lnVmbYQmdq0vRKjrZIE8HxDWywukIyFmYcCBvqCeiJ8f1xWiWslJFt+vKAy/R6A6EJMWdFtuEu+U
m4mjR3/9SP2l/OhBr2eXzTMbA9OfKv6pE40YOuho+aQ1A1W4UGgzTgxbvryxoV/lgqfODUxNDDRg
P39LeIipbIhXQirsccjS49lDRlgi4to7cYdKs2Xl5uYQYrW2g1enhxPgDRoqFHt5eg3QOb0YrFVx
azy1aqTCQJavzbfIl9IqW1X7faRcAlFQXUSZzbq+XdkP0dfrR/juxeqFtWqdITcztjwF5KKy6MWq
vSepPhmLTYBWaPtXoJM+yh718UckRtkIRaD07kqs3cw+5Q4baYgYNZh5ErWyTyKsxRQexRfxTnAy
uzzMtK6n8+SpPKUn6yiEVjyXKd2IdV305cHMSnTMPgYEiFcrjdjI98FWPg0nUWn8CJzNF+IpfDWe
wTfhefwi5TZqk/IwtUd5nPpV6UfeoVkMd2s4I0dxw3nM23Q+ifwSyqaEgBRT9Kud5+wBANMKpUKO
OAROmULDxisHK/OVdUp36B4MylJBKRW0+7mQVYWRmC6hOLqV3e8hBVBAlBiOu2Na0CposfaIhTti
YTssMxnwVSRPEeJUufRsFrN5QqHwdgmhG7fiDUIV/r5BWC4ztE/BV4VAN/2UXuRskF1PfjGiVWKk
6LkSRpKtdPPQzT8Y7L5PfgbOQiS6z57OeNOBXoGRvlu9nw3Y5703gItY46/V+RgpRs2vMWg1GnVw
q3G7D26ldKpW9XZEaSn41zsK9bb1HtXb2bsrLdRBXqy4IckOkCjqF50oPm590uNJrVh69ehkbghr
Ob0+a1BCWSTBs3D71JrttqoTJXsPCWvlet3wwX3G0oHtX1GxeXVhYWaLb/tXTOncrLzSokmV5092
hFOx+bXQbuyWeqDu3lKv+b+Req//mdQDSqLQE53+KRsBOl2JQpHZrvdq47VmcAc04A2EB4ChDBP1
iPsZYVeY49a+uF+/hL73yJizEcIh4R9wHcKZOATCnXQhMzQ0zGSa2Lfv6HBzrxCzaUJy7AQqFlTw
UfDYvLAPThWOdJy3NE4vXRQZFRLYu9eSqZMXR/UKM5NTuV0oY1OBS8Q6ptktGVSGJsOUp8nzLNeU
eYKzH8j7rNVpPTTB62TeygADIB6iDuBbPfab3W4M8Cut240xEFRFzdfFrG5Pxo18akHmsL2VRYuG
ELaBK/Ph98IyZyO4MmF5kcSVWfrV8BGjosKFaLazHnyZE8JPT68GX+Y9NbdV1N1lou4muKbYexFL
nmuaZJpucmrnmOTEius1xIzjgD8ZcklV98DTrLvDjN+ljoW28c853v9VNONTFgwT1W+3HRfKKMXQ
IbdNOSjcj25bclHy6HPMVKRHSfuwh9ODAqtHVIQPhJrMGo1GqeE5hAxWA/aQt/L7PbuSK4BhWofF
/b5D6F2HhT5n8qkIyZ2VQXjXsHu4p01Pe3CcwbdDy5Q+UzGY/MYTRlPA25kDPLKhFrs2zprlO9Ra
jxuVjQH1oXIjcerMEOaxJihSdKA9/SOZIHoUBEPEzTObw7cGaeUEVU+SopOrt9Le5siF/rqFZn+5
mBNRiDmROGcclruDTX2PrIjF7euRtEih6C9Jz7J18d6S9LpFGv6Tp9px7qdCbq77iEOYOcIx4Ze1
N4abA4amJy0fPa1iwJjIB5MeWw2euWL+t+nGUScd4xr6lSU22ZcvwWUvfJIUgiM9+/j7mK0xUeE6
3ksTuW3+5rPxQcJXiZm26MjeXkovbfgG4oV0/kDPZp9GAWi4PVrBBrCURgkRnFKrkm9VKjQBAT5A
q5q8rICCNEGYU2lbFVyNnJAZH08euurcbxOSdLTonpCHXeHuoIM4IuJGkfyE9Ig5np7dv+W+D0+u
Xg1ae7Swi9Koh2YETtIHKzS67e9TqhtwcA/fEGpTxoeGRvkqYN1NnV+wPFMK+irVHqWQ+ctyPCd5
Vnk2yed4yikvltfo1oBoi4LtVlskmPARH02RtL9VfHeEaC3JS40g2fFufHRmlhfayp6te+1dPE1p
8MzNjHH2xZVzc0aeOU1d6PioYGZ4eEiImSb2JBg0pxdgIkNV9rDdLDh0ftRQdjzLkKzHYjHrsYim
6DI8nXLh+ylGjEXNvCaRJgVJsGioOaievI3IWbmRHIVoLYyHcM6dV3fjCWF5z9wIKpSSI6yXMFKo
FPLwPMxgzJTeepIpbW+nGSLdfcBibQPMPNAe+0yekjF+lDcTRUUwyTiNsjEpfLwiC4+k7Ew2P1gx
iSpgJvP5iiqqjKniixXzKCczj69VBFLKRR7YgxDCcIzcIKduwD4vghB6NL6PLcfT2Jm4iZXVc3XK
29kXDcWJZPp1B+BITRwYrdokJl9kXckXd+6FJEULxSBbjLWhJC+AmpWExADyX75NeFpo+foLYR5E
dXOOXMVpXx0itFK/diiB3j9oGfkhNPvDbtiBZiW6bNdYKRM3lprAMdRwd1Znrz0CgEDWU9mfTVCO
wIPpwfIR/AQ8lh7PjpVP4Mcp1UqS82HJ2Y8mGaA70hDZ3e5OjyRENjDk1c5Tdh10yJd0JyE04laT
fJLCveUSL+7MQRDnh9EyFOPe8ntlIiw9MhGWP2ciSAJLDLaUYqImgLhAdmHy1ZtCGT4g5OCnf7qM
nxSy8ShhNxVLxQl78fCOs4RTwWDLfIBTcrTMnsaxw9nx9AS2gmahAahlduD94BQtJm/JPi3fK6fE
LVfSctaXDqctbBI9jb2fqqfnsC6ZkiL0hYI0y4hIU4h1v/CqYZkAiuKt/EhefOpB3rJza27yikMP
qS4UMyxHCEW4sCvbRD2DEa7teESYswfQn4OXUWf+wPhpZhJCyChdWWhOj+sNzItXLM6FazZ5Q5ha
TMfSD8JRbGM+YttkkXCV9Lg+kY+Rf8elcLO53Xx/3sU/x//I/6hQKRYp2hXtygK4jnk0emzx+FLV
X82rV915afSaEs0lCPu3aH/Qlem26j7Wfawfo3fqL3qaPWs9jxkCDRMN33gles31etd7sPc5n35/
XX9df11/XX9df13/Oy7x986G0CO6v8MgDnV9cQQGVyFOginEoKMSTCMr2iXBDHif+yWYBfgdCZYB
/JkEy9G87nl4cBR/kGAVzkG/S7Aa9aYyyLdXMDSspQa/3g0zKIyqFmEW2hXUZglmkD+1UoRl0C6j
Dkowg7yp50VYDu0c9aEEM8iXekOEyW+OeVBXJZhBIdR5ESZ/VqiMapdgjNR0kQTDPMx8CabRfcxE
CYY5mWoJZgFeIsEygF+VYDn6o3seHgUypyRYRbUxP0mwGo2Ru+lVENrl30kwg4Ll50RYCe16TibB
gLP8pgh7ENy4SAkGfDhfEVZDu5YbLsEMMnH9RVgrzhMpwTCPNN6T8JCbJsHAQ85No4HgwzVLMODD
OUXYC9oN3FMSDHvELRdhb3H8GxJMxu8RYT9x/OcSTMa7+RBA9pRnJBj2lLshwkHinn4owWRP3XMa
xfHBEgzjebUIh5E95ZMkmEGBvJvGPuL4MRJMxosyxvXgM9eDz1wP/Lke+Hv0GO/RY7xHD/57SPzf
Zoqz2ZJMuY7S2pq6mgqXaXBNrbOmttjlqKmOMaVXVZnyHFMrXXWmvPK68tpZ5WUxY8try4qri02O
OlO5w1VZXmsqNtWWT3XUucpry8tMrtrisvIZxbXTTTWkp0e14t6rmBzVJpjGVFDtcMH9+a5iV3md
qbi6zAoT1IgLlNbUV7tqHeV1Md0z9O9CY1BNVRmp1JGpEmJscabI7kFR0qA+ZFBusQsmazANLq4F
TCfU1JtmFDea6uvKYXWgpaKm2mUqrjM5y2tnOFwEk5JGEa/Mgpx06K0VK87amrL6UhfBuaHSUVrZ
4174dFSXVtWXESbUmMocdc4qWAAIgbscMKAURpVXu2JMXWvXVFc1miIdUabyGSXkpttTVXcNvidG
4vAyR/VU4Hsd8KWUsLHH6iJDpblSRAQiHbCKq3wG4XmtA1Ytq2morqop7rko4FzsxhQ43s36mnqX
s95lKiuf5SgtJ2Mqy6ucdxBU6XI5+1utDQ0NMTO6WB9TWjPD6mp01kytLXZWNlrJEnVWNBaVo1pU
hopRNfzEIhvqh0xoBLROhfZy5ILWP48xQVs9VgH8/V09FVAvu6t1iDiP695r0UvoQ/Rb9GEoX0Tb
YHQctNtQEkC5yIFK4Y4aVAc/FTCDCQ0GqBY5xbIYWhwAVaMY6ElHVXCZUB60TUWV0Fcn1srhk6w7
S8Qt5i7sHOK4cvh0wV2kzyS214o8IL0usZXcTWgn65ZBbQZ81qLp0FbTfc+9eyv+j2ghGFWLcxFs
TKgAag4RB7J+vrgjLpEqk0hDGVhTNwY1PSgohVo99BKMHOLomHvg0P8ubgyCniqod/XUdWOVADPY
YHfItxzdPVPUHTP16Z4pV8TXjVmDSDXhjJunE0QsTSK3GuGzXtwrN+3ufakQV3eJtJK6U7xvhsiR
Lp6UiPd28SsTOJYD0uC+t7ZHj1PEuAxWKRVndPO5QVyrFMp7r+uuk7GlQE+9uLtuSaiBskzsd0KP
mwL3jrjXckgzlEpzlYslkdU76Sb9VSIUCXdFifI4A+jqWuleWFXfNfP/nEe3Zy8TZ5oqyXudJC+l
3dJ4b9pvS+if8UrpwQFCiZsWl7hel5yT+d20lkFLg0h5jXhq7k2pm8/Ff+JpuSTvd0o94aoLxtWL
dxJsZ4nUlHfPQ0ZWwYj/focqRc454RRY4WoQrxiRo3+W+hjxzhkwxgUUEQqnijQ6YYZGaO2iog7d
qWlv61jHPXVsDrRXAjQLZiAj6u8aMVRcqU48MS6Rurv17vdA63R0E2b5Hnru7B8r3nln6zAoq+CO
inv2jpJorAf5cUtI439L2V1YMUYmlUlhBjP9mCTGzgxkspnku2YY8y8tTDbBDsdC7e4eIsFOoPdu
TuSI594BsPRFcJ316KN/8SUdNHkkjbQId3a6vw1P/ENI3kj6ljz6FZLp7hHjIKRAfcGS4apiVzXc
Cz5yzphhJuSdNzLXhAJhrU5xxR5l931JYJ/ufV9wjztw9ydGVFVNaRVSi6VBnAdLs4HHC5GAu6aV
PiOI34kY+kH6IXop/TAib+z+E/0BXUZsEmscwvQycRaXNJs0X0ApQtJXdqKASbaWgHEyvveiYYt+
U2E5tbElYBg0ZVAYxyptvIy1qGnKn0W2YpnCIsMMbkmkMLMx3zbaFt2jJXBzcHMgGiBeI0GA6kQT
US4evFRy2cw9JmMMHR9cb571yDfhfWK/y3hhZ1712l8yXt3Y4t3b1sLobS3UHxtJ+p3SQGC5dMCA
JbrTqTdLf7pot6m6MSWRns0Za7FFyegCRukZMrjG2VhL/GdTZGmUKTY5OfEOHzgmNtgW6B7sdU/v
ONZsM5J+2tP3dn9eTY3LlF7vqqypdbgabcE+quREW2yszZZog38TfVRxtti4+Fip+h/AqAWH9GQL
ZhHdgjUI2hVUC8ZoG3XoqPOblGsjAiI3rJt9n+2HzduWhU/5XViTs2Wf8ORmU+rc0Zsf37yiKG76
6UFljVeen/XumPPXfnxiUeCKDa0VL709fU5J6JmgAZ9p8Mrv1r51uE/F+vWVEY+d6h992OOV8RFH
h3yrSE1aG70tMvm5n7IWDrrUqjmwvqqg+PmWuZuK+jTkfP/Yy2Up60cFxnJhhg3bvn3U4vvNwLZS
Q9F4tnxDUGLe4t+2/ryaeifgo8MFmS892Hy4/09jVo94oWPrnBmuEbt8T6zlI81o3CNFjsQD2Xr5
gLGdk249XaHgnv1wwdhxP+9Nuc97QQNz/ubrLzSvEXafbDqz1b928oDjB69yW0JsL8keePclU4Pn
AxfJ977gLQuesy14xrZgM3AzCDML1tsWrGvWTjrl/NlR+1To6PmGPbnLO9/bVPv/f/9a/o2M02QP
13ynPLLs+jrfhMuv4rBzDbrrk4viNjylfC+VfXTJinf7f2O+dnXcquhXNg49VvJz+9kTKSkTt/Ub
4xDCZqS9e2L7Z+zcT2OXDdygdU47IOhH+jqOtJ8afEk30TTyh5L7d233O2ZJDO/zevkm/UPhmtIt
v40J/Kf53TNe1/Oerx4cJ+9o8fn966lVqtE3D/2S97dD375lazfF8kuC1kT5534SRD3zS/Pn9MuT
brz46bFxV8qz/pY3Zu/LdKS+85EzV7kV819d9/aOxOiv5nz1XMOlWRvRqWlpRz/s99Dn6frnEqYF
TLuQ8MXHgcxXz2UyxybGJ1XnBqpK9ik2P/zRJ2PShpwMLHjWeUHff/Gq+g1bP9wIWqHI1kLnuLWC
ImaH7h+jOic/+d6RLp0S9J9SBnDuk+LgH2iAOFAGsXFQTehSBo2iBoVJZJ5UQX6sp01HKpynYlxx
XSXElC5YRmtTk0a5pzyvvGxGTXVZF2KKf4VYqM3sRsy/Z39ZuSnfMbWaRKqjBqf/W62wr3HemcKX
MpOf6/t87Pl/hidkNRy5ZXzqb5kzfz495LuPH35zek5eyY3HqDdzz2VVWcNSyw+/H7pPOWxfU/2n
mYe2r1CPejvccm3jt6pQ4+n0sD9KHvvAL/OZVcONj518yRry5vA+c2v+7hWc8nCyNvnTQ1E3KlL6
4LhOodewZ1+pwoufuPXantKmln9O3rig9YHlu6+9unrLB0nPjnrAp9fiEZ/abqKBN97558AFry+6
XJW8NabvzZdjdinmlTw6u+KJtjrVol3X3rpu2j9Sv6z0vei/x2X6XTkwfG3KqHzf9ytGN27fufjY
2NQNLaOWVLMvJhy9P+xQXsXAx0acsMyPr24dKjv91Knhi6jqRejpI4sv5kta4Q/bgt9snkQphDMe
NoWMA4PGsnKa/t+hKjQER0+MOxnWRsOHLYg0qBlvxnAi6P1ZyDlp1y/n3xqxfnRGzJaM0qs2JenW
MOS7Yxf1ODqijrl/xwvzh0dce//gCNfm8b1cvetfWtSxI2f1bJT7/fEfff/heFu9ee51avA7xxef
+D3/xBsbDo2tuVqasS0DXVl7bP0nga8qN/ipVp89H7wzat7Pl5+te37FZ8nLB7ZNO5g048Mlu0I7
Ln5/xsE/uuSQ8AU60Pf6b3P/qdXHsD9GrV01aHrkzH1JKz6Xq94trDx5qDl9esVzB/YdWN73+DVa
O3fOrx9+Puji/cIXXzwv3Lz4ieol55mVl0buTdo8t8/HAy/0VZYkUhsWTAt98Obk0hW7Jx5IPlv0
cEGrf/yvKW0bWzw2T1n6UvS+Tc+8t+O8ae9hm98DJoOq98G8G+mf32e7tDLSsfio88vrW3e83zyo
dpYadMw00DF5ko4p1szOdTuNPc8RC3rmP3iquxROvM0GGiceFI4t2RZHqvGkanP9P0FN6qf/Rf+/
1TWbLyiWffDG0azHT27v33dn6ITpF6peN4fsW33shxcOv/NJxBtxuqUHzxdG3+o3NtjL8sIK1aeG
LdWROU3eaenPL7O/OGSJ6u8LVu9cJzs1LmPW5B9+aVd/2eTaEv+e6+ufLxVvmk/vy+z8JFX/ye7j
96lO3X9tn6eqvWha5AP1D+/befCB73xefuT1X733lhRe1l3sf8U8aemu5ro3My+tebCh6PFvdzYc
TVwWb7B6Xih59wX/bSPbpu782JRsm/n5sqlDvnwn8IZqlCvd+h0bNs08PWv3yrf2JP9t0DMzJvsO
37Hi7PKFqbMVQ889vac19M0vr91f8eJw16GI9Ownig1FI2zHWq6fUjrnXinIbfiQK5i1QNI1v9sW
/CryPkhDTiwcQtmRHgf2utm+fO7o38dkt33tc3bawr5sTMR391ZNRE8EhTK+Nu/mex/zDDLAyAy0
pdiSNyZuTFgUL6UNS2ur7kgbOqc7SKtVSrbWWQfng6DFQJNtWNeS4IcMsPW3JXXVbdSi6H+ZhxQn
LK/tMZPrjgMkahv7uJr8qU+ZFvbF6m98sgfs/PHcgqYrqkZXw8h1Q32vIy/H/Aslj2zumLrpia8i
o/4oOPuYMOrwffxL+5+93HK9Lbhmwh+//vKFx0dLuVRvH9PpI69kDuUiisbx2auvcidey62++uUw
fWTCUnPtxSl7dzn0YauvfN+XvzC/umalIu9475ys7XHRi77bdKIw4uDBAZ9P2rNQ+VpC4MjWzKGd
B1ZvmiDftvbT2YfGNT2zdcSJazufWJ/+5XuTw1L/0dR36IibHxy7/8kf9777RKkhf9fO9T+fPfzB
xk071hyfY1kc/V87cPzmnxzmW/st1n68GCMpzn/g+6mGZQIcUncnKD/fsNDH7tUGQbUKvoM6O5dk
H++3AZY2c4GlTSustPGseQuZKBu40iYkMze1uCQxtwC5tDEzsDQ0MzA0NTUCN28MwVwjAxDXoHEZ
TdymbqAKqSjl8pwzC0AD4y7BrgquwX5WhgYuFrqmFibmus5ObhYwhczCcjg8EZxaBBpKJ1hAvdrF
mnziZuW6Fhe7pZuPvPWZp3LfskyO85qRV0TFJe2bS9knvH9u+3uvWs3i309r64zO37TttjT/9OOG
tYnYlUlNv03eZLQWSfU/2OHzYEfrZ2MupoOLyopNfWI/bn/oVSu7Y0rF7f9yraJOboXn6tXDhS42
+1uf/3XvW/dbe4bHV+8l/hTv9V7SaPM10+HVw8797P67Sqpf8jx1f7U65+PV9EaOH2KnaoV3Fz/i
9PmV9PvtAstZVv9eC55IlEuKuMEV0nzV2tv7Uehe/QSpvkmszrdiXzdxKU/nXMBqmNo92U/OUXHR
pAl/XV1c8003upqvzVyZ+tPEeaP4IWvLhwI9n6TaH4cEyFvPNVyLXEAhCqS6og969mGaD1S/Z+xg
/OP9sO78YzuUsif/hZ/99J0mq73b+vfMebXG2tH52AWKyp6S4oLkRKqUPTCTSrCVoBwYpTCWAiqz
qomTR+zivfNunXr7L5pUNdarazhqfb6sOIlv+tr44DjNn28PhnitqP0ufIFb5KfvpzZRhrzHzbIa
rst1LI3u5s8yj3qnHNQfwtxrv3xOisU3sxMiztus7Gac5D1c2KjxOW254aOY2P6fQUEPY15PnjA3
k9On8+LFMh8T3qyHNS7LtaObQ+pdVSRVj3S5HVV9LNmQqSnyTfzYByWdRrc47S8/lx0rt1PO/7ks
pbVvURLvSl25FU8n2NX/39D3Z/qbj39Z1p/1PBdVsubXZ2F5actzi7dc2/Nly7sTaz+Fyf22+Xji
mpbLnv1z7GvTJM5uUkjmOuVgm2okWbNph+1BNQ8/JcmZeT0GBz9ORC2gBLK4Z/ofYFBdLXjbVT6i
Kn0RejE1MJ0vaOlkYGJiDiqdLIHcAeh8YRSchMqbO+Z5v9efcPIqlDhxzsMu+MCv1SK7dIx2C/kH
nWh+a2d809Nwksa2iSkP5ANadh3yvljP+uN96b7u4yuursssSKtQT3uxbfv71p1n3636K7SEO1JJ
U/+8w80wFumyrbkpuV4ht+9+vLd/fvPxhvv1PkzmU74emMcRJpfhfvbmgbIY/dptqixbwqKzZJL/
N9TYvLvKouprWV7CHnso5kabuU7pSb5XcpacNWX/5ubkVT14Y9c/fV4hX7yWv0RSgtG8S81+2kox
Ga7d9/RbBAI2/dwq1ZvzTnW28I/TAtdb+b40lRWbHZtatehMAtsb1g1txtt/TIlucWyJaJ2St0Fe
x+NM/hznB1kv6tX6siHlTROjBjBEVLDn0CHR/RJg44QOgIoygu/jQCo9sRaOknANIkwsPHJcDMHg
0XZnBkfUrhlGvw5LATXFV9DwUE3AbsG+hYnsjHw9Ba6974tD9tpzsur+3xEY3Crz1nLi9sVh3Pd6
tllLX/y9ZvnJ7RsDFaXzOTLrspkXKbm9zdmSW6O0w+1yy+de/n3sXWYHX9e9LIh1nT/p0plzd/sO
PNyvdbbmzcl1Rlfbd55OPmJ2UUJxf9k961mbpYvnKXbc2LJFKKTny5xDqV6zNNTmJHTxWx8XTq3w
2H1+bbOV/4akiHsGL19ayj7u/HTLsvGnsGJPSkMyG8u0T7OYnPWr3Tp2/We6mfrT694t5pLJm1nz
eM7MvaORWOPxUXyOoKIFk0z7Graj04x2PHU4Fmy7d2XnvRdp5r1flKbNObOhPCTQ6lqRyyblb4ZN
LPOBhdRsJkZGg8b2AeyVofQVEWPcCxpPGYjA41uD0ZCdmRU8RwFKBdDI5GQ25EEeVge6BsHjNuQz
QJYVNVBGaGQxBKaxX1++i0rZvClsN4/J0L04S6MpbvcMgxAkLTyGbgYuC6QaJHBNBi9Ua1AhYkmB
AlpxxtLEyNApdtvqRZdJ+ramx7rBXGsPH2GY0+dy/dKvV3zrl95rm7w30crKbE3FxELBszb8Pzwd
w27cKlspYh3nGGb36/qc01ztfEt3anr+/LLxZX5zQ9glpkOCrIFFb0qkQ3rlBRfzBmw5oda1himz
wLA95t9sXeE+TZNQ20plGZ4l86zfHeBg+2FYHjFf68BCrX9X/ppI+fuppHNMCSm+LWx+47vNaXHV
fzsultqnnyq/qn/Ydaba9M1feo488Mxl3WbO9OiUeszKHq8Or4DlSg1aW/tbimY5Rt1dn+maJTKB
K3Xek6cSznvyeVyWBsls1cqcKsz4VdoiO9b7YZN0DpPFsaJN/bJHOFwVX7EdZNuwsIlJ3qCJSRoR
J2yGTUw8QCEOuidJ9BoIpUPBDk2SC2INJJBTHjdi1ocRaCdchtWQH1i1WhgaGIMqUktQSx894dnO
XMiyfNXfo4v+q+V+TK4rz/TLtUAro0BJJNtG5vTB8unfHp3iT/G48lO4+4vDwgq/+0LiWyOyhLPc
+oRfekS3Tdf5/GRO+qzTIYbvFT6KNs15w8vgEa1eljLBdeW0ysM1daY9S+KFUnbP3l4iLbv/MFv7
7sV3U0VNhSwmVL+p89uuIzT9k3Vlnvnb7HNeiyJ15+kYpLf2qG158SBUSPn6dLOziSyFF62qU65M
O3Zn5blNr+9tOfpy7TyRsLlNZyXXzj51rGKO+uunnZaK6TEH//RbGtnJ7l0z9axthLtBpt+87qUb
zbamJtU2eNsd3z5v8Tx52U/NZhF9T1ef1P632Z+7c4vETb9X/wr/BdeLShy/KiV3Q5u7KnD764YW
A7nKk5s2Sx36xAAARFDsww0KZW5kc3RyZWFtDQplbmRvYmoNCjkzNiAwIG9iag0KPDwvRmlsdGVy
L0ZsYXRlRGVjb2RlL0xlbmd0aCAzNDM+Pg0Kc3RyZWFtDQp4nH1STW+DMAy98yty7A4VJAHWSgip
pavEYR9atx9AE9MhjRAFeuDfL9isWztpkSB6z8/2i+ywKHelaQYWvrhOHWBgdWO0g747OwXsCKfG
BDxhulHDjPCv2soGoU8+jP0AbWnqLsgyFr76YD+4kS02ujvCXRA+Ow2uMSe2eC8OHh/O1n5CC2Zg
UZDnTEPtCz1W9qlqgYWYtiy1jzfDuPQ5P4q30QITiDmZUZ2G3lYKXGVOEGSRPznL9v7kARh9E5eU
dazVR+VQLb06ikSUI0oJSUJ7QgVWmnPS7wqXhpyjjMekfsBcMaN7vGJO5JrIDZEpkQWROyLXRFJr
Se7iAklJ7uQKr0TOtsgIv31ZLEi2/+2e/3Efk9GE2qf8qqi4Lbqa3iMiIdDQliPi8v8W2wRrb1NS
r65aTDOaVumyAOrsnJ897hsOfRp3Y+CykrazU9b0fQFbEcp/DQplbmRzdHJlYW0NCmVuZG9iag0K
OTM3IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDI2OTI2L0xlbmd0aDEgNzE5
MjA+Pg0Kc3RyZWFtDQp4nOydeXgb1dX/z6ya0cxotIx2SxpJlmxLtuVNduw4lhLbSRwnOIuTOouJ
Eww4gSQOSdOQ0CYUQkKgIUBL2UqBUmihBWchJCwl7JQ9UGgp0DdQoPCWAG0ppUCk99xxwtIf7/Mq
f/Tp7wk69nxm5s6dq3uv7veecyVbAgoAXAgWBjpmdU2a7to2BHB4GMC/cVJH50SIM3cBfHou5gpO
mt4zy9RkacXzG/B8zKRZsye8XvpWHM9fxvPvT+2dNfnKic0/A5BKAZg7e2al6s6YedV4AOotvD4w
p2Na3+q/nLUMwHIQgDt40rJFw5+eO3QvwBYr5rn+pDWr9anXj6cBLjodzy8/ZfjUZTc8tWwGwPm7
Aeg7T120ahjcIOLjrcbyrKeefuYpf77wDy8BXMwCzNw6NLhs7bJewQOg7QdYNX3o5EWDz3/01CIs
C8uDxiFMUMsErB9F6l86tGz12isfqr4Vy54MILx82slnLK8/t7IH4M942dR2+oqTFlW/6TsH4I/b
8Xz5skVrh/kE8228/1HMoC9ftOzkd17MLgT4axbA7BhesWp1vgfWYv16yfXhM04eFobfw2sXYn/S
nwLpa44Ljbz64vyFauvfwS8AsZu/01FB9g9Vt+ifnHf4UulSAZ8DbCcNo4b3CVJuJoBciddXSpca
JX3R9pIUZg9MB8Y4p8EKKZiDB2Z8XCOFtVHbgQOBu5KrxyJjo3vmWlhL3yQALfEsw7EszV4HfD4L
+nzSw+TGabN0HTBBj/DB3Fx4TJCoW3Wgfkyusf3cAdJSoIQjVaKfGd2YOBVlfgE/4y+EB45WknsG
VpE9cz3cjtulnAtuMu55Gy7F8ytwf5i5Pv8app/PuSgX7q87mgf3d42mw5W4rcNtJXM9NQ/vexMf
I4fb3/kLKZnth2uxV0e4teDjzoJHuctgFZ/AvQqPslfAo3wDnjPwKHMinM/8BCqNVqzG9F9hnk9x
PxVWsc+N7rntmLYWzmPfxcd/CXaSMk1vwwJuPXSw7wAPX2GcK2/0N/sUDLGfwj42CUtwfzr7ICzF
fukgx5wV9tF1cBt9X/5+9m64D4/vMj0K+0g6+xIsNe7DfMxS4/7lTBm04bUdmHcctnMO7lvJMdsA
/V9Vh//fDJ+Tff/pOhRiOKau+OI5Hc8fouNw7X+oOkUrWtGKVrT/uDF7KKqkpMZiIbEYRVmAUilK
QgMCCVMsFkmus1i9UadFXW2GqlKLoiiWuspAXXWJzSiDAkxQlBJF2k1Zdtskq6IkbDbJbFXNtoIr
8q9x3/9uEsldePaiFe04NaJYNJDhIyEPAgj5HK6tzEizQRQxUgYZqYCSPwwWsCBVUJFWgzawIe1g
x+jeAQ6kBk6k06ALSNTvBnf+E/CAB+kFH9IHfqTfYAmU5D+GAASQQQgiQ6AjdYNhCOf/CRGIIKMQ
RZZCDBmDODKO/AjKoAxZDuXICqhAJiCJTCL/gSuZSmQVVCGroRqZghpkDdTmP4Rag3VQh6yHemQD
NCDT0Jj/OzQabIIm5BgYg2yGZmQLjM1/AGOhFdkK45DjDLZBGzIDmfzfcGU4Hjne4ASYgGyHdmQH
dOT/Cp0wETkRJiEnGZwMk5Fd0JX/C0yBKchumIqcCtOQ0wyeACfk34ce6EFOhxnIGTATORP5HsyC
Wche6EXOhtnIOfAN5DegL/8u9BmcC3OR82Aecj4sQC6A/vw7uF4iPBFORC6EhcgBGEAugsX5P8Ni
gyfBSchBGESeDCcjT4FT8/8Np8IQcsjgEliCXApLkafBafm34XRYhlxmcDksR66AFchhGM6/BSvh
DOQZBlfBKuRqWI38Jnwz/ydYA2uQ34K1yLUGz4QzketgXf5NWA/rkWfBt5HfNvgd+A5yA2zIvwEb
YSPybPgu8rtwDvIcg+fCufnXYRNsQp4H5yE3wxbkFoPnw/n5P8JW2Iq8AC5AXgjfQ34PtiG3IV+D
i+Ai5HbYjrwYLkZeApciL0W+Ct+H7yN/AD9AXgaXIX8IlyMvhyvyB3EdRXglXIW8yuDVcDXyR3BN
/r/gGoM/hmuR1xq8Dq5DXg8/yf8BfgI3IG8w+FO4EXmjwZvgpvwr8DP4OfLnBm+GW5C3GPwF/CL/
MvwSbkXeCrchb4MR5IjBHbAjjyt42IncBbuRu+F25O2wB7kH+Xu4A+5A7oV9yH1wJ/JOuAt5F/JF
uBvuRt4D9yB/Bfci74X9yP1wX/53cJ/B++F+5APwIPJBeAj5EPK38DA8jHwEHkE+Co8ifw2PIR+D
x/MvwOPwBPIJg0/Ck8in4Gnk0/BM/nl4xuABOIB8Fp5FPgfPIX8Dz+dxM/gC/Bb5W4O/g98hX4Tf
55+D38NLyJfgZeTLBl+BV5B/gD/kn4X/goPIgwZfhdeQrxn8I/wxfwBehzeQb8CbyDfhT8g/GXwL
3so/A2/D28j/hj8j/2zwHXgHeQgO5Z+Gd+Fd5HvwPvJ9+AvyL/BX5F+RT8Hf4G/ID+AD5N/hQ+SH
8A/kP5BPwkfwEfKf8E/kx/AJ8hP4NP8EfAqHkYchh8wZzEMeCTiPArNXNIvAMBxnAjABy5qA4RjW
hAYEJpYc82bBJAgmXhA4DnhREE0ipgq4NxmOggeeGIO/DM+I5JjFH97E81zB3qbwnORBafr/zFa0
oh2/ZpbMKFeWE4geiHxZjuU+1y3HCYLAm4lK+aO6RdWKAqaYpM90ixlR4yYTw5gYydA7z5p4VPxX
vkb7lXZsumWYY21o0Yp2HBl57YPoVgRcUX2VbkVRRH8riKIJPe1n/lYgHlgSRnVL8vKjumWP6JZD
3RKvXLhuC89Z1G3RvvYmKzLqluPN5P1l9K6GbtHHCkAgGLo1yUS3gkkUUbcms2gWUMioXeWIbkle
dMasIBi6Ne4zcYY/NhVckcJzkjfJi7ot2tfaFEVBuXKcoVueR+2ir/xct5iCulVEolvcOAyJJUO3
mCwqomiUcVTjX9ItFiKZhKJui1a0f4NZVAvqluclXOp+plsiSiAQ8YIkCRaz2SyJgmRG3SIl3NDr
mlXzqG5FMEJndM0MJzCKcZ+A8TTeIhRckcJzkgdl2WNtaNGKdhyZqqpEtyaZvJNuMpmJbk0oUzMQ
mE0mWZYFFWUriaIs4fpXUCRZlFG30me6NaPGiTMmuhUZVTSP6pb4Y7HgihSuWwwNirot2tfbrDYr
eRfHpOBS19Atb+K/pFsMpEUrOl3ZLMoyrldFRVbMCjpcWbJJklEGySuYzbwZ/bHIqeQ+XsR18DHp
tvCcRd0W7WtvNpsNdWsSLES3uCQF9JTC539hJwgWi0W0odNFqSoKxr2iRUHdyrJZlm2y2ShDAoyi
JTOG1Bxv5mwYSEsm0SSZMbz+d+iWTBZc4W8bFa1ox5/Z7XZDtyqAYujWJJi+pFsMpM12lK0FdWhB
3ZpVPLQosqTIdnnU35K8oiQZupU4u3Ef6lZSMbngipgLzlnUbdG+9uZwOMg7taIVwILLVIyVRRMG
xLIMBLIoWq1WswODZVWWVIsggmS1qJKqKLJFcSiyUYYMGEXLEi6FeZPE28l9gtkkSxheF67GwnOS
By3qtmhfa9M0DXUrEN2qqFvF0K1C3h0iUAzdShoGy6oiW1WiW5tqla0Wi6xaNMuobhUwwmaTrPAm
mUc1o97NAuaXjzjkQqzwnLgUL+q2aF9vczqdRLfkX71UMJsxVjYL5s91azbjAlhyomytqEOrYAbZ
brUpNtWiqBanRTHKIHklRTEphm41Q+8S6tb279PtMfwBZdGKdvyZy+XCZa1otpNPwzCbLYZu0b1a
gMBiNuMCWHbhItdmUWw2M+rWYehWtVhVl2oxyrCAseQVLBZeUHhUs8UiSqJFsStHAulCrPCc5EGL
ui3a19rcbjfRreQAsKFuVUO3KnlXl0A1m3EBrLgxWLarip3oVnHY7Ba71WqxWd3WUd2qqHHZYhEs
Ki9YeFQz6l0WVYvDYilcjUrBOVUo6rZoX3PzeDyGbjWiW0nCNa4kSp/rVpJwAax4rFabA3VoN0ug
aHaHxWGzqnarx6oaZaBuVQybBdXQrdvQuyKS9a+lcDUWdVu0ohVsfr8f3awkuwA0kGX0ubJZtpF3
dQlwhYqBtOq3OxxOm9WpSTKobs1pdTrsNs3ud4x+AIoNrDZ0v7gUNolWk89mxfssks3qsh5xyIWY
WnBO8qDH8A8LRSva8WeBQIDoVvEAOEFR7CApkmIn7+oS4AoVHbI1gE7XZbe5XIoCVo/LbXNrmt2p
BTS7UYYdbHYVg2i7XTTbxBJyn6xKdpvHZitcjdaCc5IHPYY/fC5a0Y4/03Udw2NF9eFSF0Nj9Lmq
rGrk3SECTVV9Pp9NR6fr1exej6KC3e/xOrwul+Z26S7NKEMDh2bTHBhS4zpZDGkOTbPYFM3hczgK
/0SywnOSBz2GP6AsWtGOPwuHwxgeK6ofl7qoW6ehWyd5d4jAqaoYSNvDbrfb63T4vES3JV6f5nO7
NY877B7VrRM0p82pyU4nrpNF3ak5nahbp+bXtMLVaC84pxOKui3a19xisRiGx6otiEtdXNJ6QLEp
Ng95tYoAI91gMKjFvF5fwO0MlFht4AyVBFwBn9ft98a8bqMMD7jcDrdLcbvNistc6na53VaH6nYF
XS5HwRXRCs6JIT2G9sfa0KIV7TiyRCKBbtbmiJDPiXM4/KA6VIefvFpF4Hc4IpGIO4GrYN3vCet2
B7ijobA3HAj4QoFEwGeU4Qevz+Xzqj6/bPHKFX6vz2d32fzeiNfrKrgi7oJzYmgAUuF/plG0oh1/
Vl1dDVar3RnHkBlD4wDYMOQNkFerCAJOZzwe91aHdD0a8JVG7U7wlUVKS0r1UEkkVKWXGGUEoCTg
CfitgYBs9ctVgZJAQPPYA/643+8puCLegnMGcJMLf2O4aEU7/qyurg7sds1dAVAKbrcOdrfdrZNX
qwh0t7uiosJfF4lEy/RAWdzphpJErCxYFo2EYpHaSMgoQ4dgyBcK2kM6xttqrR4MhZw+TQ9WBIO+
giviLzinDuTjdY6xnUUr2vFkjY2NGB47vZUAZeD1RkDzal6MjSNAgJFuZWVloDEWiycioUSF2wvB
6vJkOBmPhctj6VjYKCMCeqQkomNIrTp0NR0JY2hd4ozolfoRh1yIBQrOiSE9hvbH2tCiFe04spaW
FtA0tz+FS13w+WLg9Dl9MfJqFUHM50ulUnpLeXlFVSxcVenxgV6brI5Wl5eXJsqby0uNMmIQLQ2W
RrXSmKpF1DGxaGmpN+iORVKRSLDgiugF54zhZrUeWzOLVrTjytrb28Hj8YWaAGohGEyCJ+gJJtGA
IBkMNjU1xdqrq1MNibKGukAQYmPq0uXpVHVFbfWEauPrQiEJ5YlootyTSNjd5fbxiYpEIhD1Jcqb
ysujBVckVnDOJJB/9z/WhhataMeRdXd3o5sNRsYBNGFoXAP+iD9SgwYENZHIuHHjKrrr6xtaUsmW
MaEIJDJjxlaNbaivbqqfUl9tlFEDVamyVBW6Zqev0tmVqkYXXRZMVY6rrCwruCIVBeesAfJvw8fY
zqIV7XiyWbNmQSAQjncAtEI8noZgPBhPowFBOh7v6OiomtXc3JJtqMm2ReJQPbFtfN34lub6cc0z
m+uNMtJQ15BsqA00pD2BWs+MdF1DQzQZTtd21NZWFlyRqoJzpoH8++GxNrRoRTuObMGCBaDrpYlu
DJkhkWiBcCKcaCGrXoKWRAIdct2CTCY7qSU9qbMsAfUndE5umpzNNLdn5meajTJaoKm5prlJb27x
6I2euS1jmpvLakpbGrsbG2sKrkhdwTlbcPMW/rZR0Yp2/Nng4CBEo2XVMwG6oKoqC6VVpVVZNCDI
VlXNnDmzabCjc+K0TPMJ3YkqGNPb3dPaM7GjravjpM42o4wstLY1tLVG2zL+yFj/osy4trZkQ1lm
7MyxY9MFV6Sp4JxZIP/GdIztLFrRjjOjj3zLuAYMOaJ8uPGff/U4Rb6z8l+/thIvMizHk49PlWQF
VKvN7tCcLvB4ff6SQDCkhyPR0li8rLwikaysglRNbV19Q7qxaUxzy9hWo4QJgJPBpMldU7qnTjuh
Z/qMmbN6Z8/5Rt/cefMX9Bde982FZBr9TpIduN2+p/CigYUtyCBYsQALRCEOGG3AFJgLC2EdXAu/
ZL6jO3SvHsnngbweHodyqMQofipeX/TZdQ+5nv/jv/yclD/p02sPXnPwRwdP/r+/4z3rnN3b1FiX
qq6qjMdCmsNuU2SOpSv1ESbWGe2MLhraqncO6VujHQMdVZXdM/s6O/zh8NyqSh2TO/QRakDvHJm4
ZsiztZNkGLEnR+hYJ9mWjmQvGMCDaEc4HMYrjs+v7M3vv/ALl/QlI9lFI3CBvqNy/9YL91ph8UBS
HowOLlrQN8IswsfaAViZod4+UieyDQzpIyzebcCPKUeqSK4NDSCjHXjXV6Zjstjetzm83z9ix33n
iC05MglzTFr3up/Z2ulZopPTrVs36yPXzuj74tUw4dy5cz1f6oaJ0YkDW7dOjOoTtw5sXbQ3v3Fx
VLdGt+7o7t463Dmgj8D0vhEK0++8wD8y8cK5I9aBIaoFm0zaMXFmX8YftmEp4TBp7wV7s7AYT0Y2
zugbPddhsX8nZFPJuSP0ALmy/+gV52xyZePRK5/dPhA1+rq9j/HTWHD3rGj3jHl9eufWgSMVPpIy
ZvRsBw0TdkSpLTN2ZKkts+b17bPiaNvS27eTpuj2gQlzd5Titb59Og4UI5UmqSSRnOjkBLop7I6d
tGDk9+/LAmw0rrJGgnF+0l4KjDThaBoFJ+2lR9OsR9NoTGNH07JGGjFsDN3e2/fFWuNG6g6wD3rz
+7PBnRV1jdad+s7szuk7h3du3HntzpGdz+w8uNO8f+f7O2kca9nh292exlAHpc4JzaF7Zi+cTa/o
pX7ce1svPWOWm505y8XOmulkp3TNZCd2NbGTuurYybh1pZvZ1kwdOy4zjm3LhNn2TICdkJnJjsct
i1smXcfW1Q+y9ekGNt3Qyzakg+wzDQcb3m9g9ubf3bU7Nrlxb/7grt3WKO7fzSq7RbVxt28yu2bX
ebuwWu/v2mXk+Dib3yWWNu7SJrPnb3Gww6cPr6XVq//rGjr7I5e3MXu1y9+Y/aEbjy5z+xvP2+QI
qeeqm9Rt6kXq9tC5oW2hi1LbNm7auOWii7dv2r55+xY1+13R2qieETqDzq4U5UZ1GaU/SumPUJmH
33uY1h/KPkTDYgoWWxfT2UXXLqLV+VSVZmMrtRib1JrZhOZgKzQnG9KCbFhvZ3Wtlf21r5P1+Sex
fl8r69PqWCfmc2B17ZqPteE2rFFZbXx7o2pJhICnlAe6Q/L93SHz/u6QiBt3d3eIvac7xOzrDtF3
doeoPd0huKM79MD9idD+exOhe7Jz7g6H7twXDt2xJxy6/4EHlXv336fcfc+v5H133iXvuWOvbL17
4910dt/GfbS6J7OnZ8+GPay6J4WHK/Dw3j1P78nvEcxiEysrNM5dDE1TQE/nqL1Unhqxd0N374QR
B4X7WRN2iHXJ7pHBmRM2fe97gZHLcOSObAzM3StgHtTpCLVt7ojQPevI4ejbJ6tWr1qV/AobYTpH
+M6hRSN8tGMVObGQEwvOFpbOEZUcq9GOJDWidQ6NaHj0/xSy6qglVx25OPpABuCbX/WYpC6rkckk
H+Q17n3uAHsW28+8Qv7jNf+n/Ku5tbnB3Fzm++R7rOEyuBkl8jA89dlkfzfcb+zXwE7YD49/yRGc
Dd+HG+EJ+D2891na5XAN3AIjX8q33Ui9AX4Ot8IuuBMewLQtcDGm/hR+8YV8K9B/XgRXoa96jjr6
dxgP0Bo1WoO3QaYPUKuobeBDv9YBC2AVfAfOw3o9Sk3FtHGYNh1Tz4C1cAmm7oNHv8J5jYM50A9L
YTk64H1wn5GWwNReGMRUkjZqK9Gnng/XwU1wF9ZrHdbsYrjyK8o7mw7TYVgNb+Cdj1E/oB/GFt0E
m3iNfLIsd4D0Kttv9C3kXwXIDeb/jhHAYvoD+nr6YriNXor+mSYu10S+SpTBnXYHT7NAttSTrzxp
oLYmbAvbYggKc328kYNPyB42ko+1pKkogsHHIncvynoYHM2m2ZygihT0s7Is07PZJNPP7c2/sttq
pWfjwTu7VdU4+Hi3ohgHv9stSaOXsmZRpGerXIijuVS/MYZeP5x8vR8yh+pTmdoaiokyjmi6nmZ8
N5e88MQT3IFPfs02fZx6DmfjnzEHGJbXjJrEs06a5xkTpYpZkWYqgUzhbKUpdai+P3UIi2utT7WO
Fkd+GDZ5bvJnuPHa4XvodrKROA/HCvdrbJsf+3BHdmU2PEdczQ2L6x3rXevd632o4WDApTqpU52U
MyirVocmaSYhVOIGDzXkoTxBjqZ8vJdf7NUWD0uUxNgkm5dhFfBTfr/i9lEB1nq7I0hzIivfrppU
h4eVQKM0RpV6JFoSINOf6be7m1OHRjcqVZ8yzlOp/tdTr9fWbN6Pdrh/Jdnt32z94hnVT4WZsDPM
RB3Glg4bWz1jbBxe436d27WAasj9fOjsodxfCV6gpi3IPUF9Y8nZSygLQSKXzr17ImVnbsht2Zyb
T/2UbJuptZupG3PzyLYpdy7296r8q7yDex8k8EAnvJpdIapetVWucdYE0lVt43p8kwI9HWeWSEtj
A5n13BphvbomsC423DacETmBT/BNmuAKaAmtyZmpkBOBeFONUGPOCllzlzxe6ylpD0zUp4bHV41v
nSHMVebHlnCnCKepA4FgRnYF9KiXIT5zrN3dxNzsVSrFNi6apl2ZqDkoVCptTAq0MbyWysidDj2Q
GsP64hCkgsFOTfFRPp/DGV810fohjq5+stmwd232Zuzt1CE8hEzmUAb3h5IpTMTf2pr+fuzZhng0
wjs1l7ux0UHxvIknJ/V1jZRT401UtIzno5HSdENjU2NjUzw+elBf5yJXMTeFqY3xNONZ2bdgdc85
i0++PxcJtYVKSm/5Uf8d1Gl1rdS6D99Y9f6GZ3KHGqLRofTyRel03XWLfvmCJ6CvOZFaZbFQNMXe
tHDZ+rndq3uimw8D9axamyhb3nnJrvn0rQMD7y/LbT+4beXfHlpwXm1qVmjyJSvaz6yrab3tvMoV
lbXz9Nxl5QMNY7bWoCRuzw0yKmrGCXOy7SIlmryU11TOlHM91GRmMtdjWkgtNK2gVpg2UGvptfwG
k91EUfI6lhLI3aDK6MJmq7Ih2hC7xWX94FAyif3YihIjcu2nonHaZrU31TtJN9FOze52udyM+saO
Bx/c8caMSzOt3V1trVdOyw0+Th2kqvDn4OPmrns3rM/97oZbcq9vXP9IJ1lhXZobpA8Z9VyabeYZ
3uFknI44FWfijrhzEpVlso5JzunMdMcAM+A4E9bQw8ywY43mtFOs/E2g7BmWYllpb/6D3aTC5CCr
kkpLIZDJbASXuK0fJv+17lbaFE2TJ8uebqDL4vGydL3LTh/Cik+7amxb15RxmUtnYEPo1txzOf1x
c+cj6zdSJbfcQJWv33Bvl/nxnI41v4lew67Emttge1bscVC2rGhtEsiI7cOD+fR8rlfqtZxGn8YN
SoOW9fR6bpW0yiJTvGqWLIKNo3mZ72GnszRrVmVsDaU6Qg4abErWSlkFk9yDz5rVQuMKVOKVcnFY
puRUfz1OFnU4VeBAJsAG1fdjy+rJ3FGfqsdRTCWT/ZQp5og6uLIqqolj6pmYm2NXZnOX8WdzuR+O
p76dO2c8tZQ/20Sdls2dy3xr+fO5y6mhF5Y//fTy56lTc1f8ZvmTo8/MNjqDHpOBdDbuoxJUkk5D
M90Jk7FX59KD6J4eYmSaZuaw6I1oH4bkWJEUWD+oS5FOFqmog87k3rzkVipweCV9ESnzCrqWEek3
sUw9q1ETVAzuVa4HeriFsJB8mjJN5kFAxWIBOKkx4uHt9DBdezu59zDiHaM++h56DiVAFbU3/1bW
TJ7lFJVB5aBfOYT+BP1a1FZPvfPee5ibyr+We4ZZYHiPxmyMoYCjXFSMGgNd0EHNoU6lvkWdR5kp
O82ksDZk7JNKQCbVj3XYfKh/835sCMUsOFz/S/oxXvvoblMH8SDn519lL+Lew5kxCpuzkUaqWWqQ
x9rHehqCnVSX1CF327s9HUHZ2SXS4S7GrOLI3EOcphoGDLkNTwlktPqJhwQPuQTXxNRYKEb7De/q
D/OYMesgOXkrGdO8TPLyl5fiiE7imO4/ssc2k1aTYR3WiSjDuh2nonRDHIc2zmejsxjKEycy9qJP
ch/lPvjHx5RIyf/I/TPq9ZZGz1x44vrSiNdVGj5z8MSz6LdzK3LnU2dRW6nvUetzGz69fcZLV15+
8IRpJ5zQM+XdbVc/O+uEmSfgk0G58Hlv5V4AFbZk09xEnpcZCzOZElRbyEZzdEilVFW2GI2xKLLM
z7bodIZZwQwzDCOTmAHn94NZiTSQcZEGMqRDAqSRTJDcxfAkjmCsisIjSQlM6mgEilJIJokWUvWo
gsN1mfoUeeZx1NjC6Tpjgq63hdnWT39PNeYey2yPVafZq6iay5k3tzg177TxH9+Pz/V12IKL0b/p
6NtmTA8NhGiO4W0uxmkrtY3lxihpSyaQCTaHurnJSqelJ9AT7AotZPrZfm6+OMe20Huiv79kYWBh
cCkzyJ9sW+xcERymV9s2+DaUbAjGsDVv7SaVpsk4zZAjUK1qlZAqqVGzKq9mjfGQlbF1qipNcdB0
aAolhGgh7DLmLpcx/bpY0iEu0jVecoPLRUpyufRrImokFKGxI68IWz/EniAw+uaQvdnoEnR82FG1
NWRK6MeuITMeGRZkTJD5r54soQzPhb9h9uJPrUuem79/2xXnz//NyeZJh1a8QbHJRNmS7tNeP4kJ
H5i3e+6dL21YfU52wrPRllfumX3phLa1XUse6iVzIarhLOzHcbA3u02SuJRPcqYqpHiqorVVSmu1
kYbUFKlTa4+0p+ZQc7m50uzUUumU1NLWtdKa1Or0+lZfQ0tHCz22BfuXqrJV0VVVFVNCYi2tKiGF
VhTbFNEcDTcZQ6mJJYOiiSe90BSsdoWZ6mALLrkYnzFkZGOYXJtRM6EMLV/ZZn2z3/pmMmlzN1sP
YXhFeseIOfsz9maySx3GaZSIx3XEi0cjhjsgYmn6TEQYmdZ9QVCjnUckRe5xulyspaZtSnv342ee
9f40dfabp2W2VVZX1VdVbZwyb+Llt1dXJBe3LXxhIenTZTe2T55y27dqzqKfTH731FNuzkxsHxs9
MGZKoqJy6YzpS4Ih940b1jXO8Pm0jrYD0bHllTVb5p+1z2MR6rGf78J+3oRxawJ+mB1nFnxCUhgn
pG3jXN1Ch22e0FuxVFgnyIGAr4tMJDjdxcJTYnyQVs0hM202W6bwZj2i9wSoAAnJq8nACrhItwUs
pFMDhsYCWhj0gAjGBfhxpVoZqqTFq5KjPWlrJh1pKPBQ6vOeTPUfJtN+P/W/9yH2mw3jVtvRrmM3
TZ0w+ZFz1r12gmXmy0snbWqorEqnGn6woO8nY5mNh8cn54XP3DN1eh/14tCvxk/sri99rqGrvC65
tmfaUj0e8sh0/rbcapataGi69ch8fBN3CCLQBD/IjuEVl9Icq6+tb+qKTahtb1pIzVGm69PDJ4e/
WWvxMRVdAYfDPSXAqHQaJ2dfZcoeDYNdxBn53c+nZsmYmo1BB6S/VNJHcHWz2hxqplNhkUzpJLN4
+RgSYxjjDEca6R/0zWRWtjdjr2DA2Wz0DJBuidPpBntTYynpA2eUdAuYjvaI6Stn7Jtyz7+4fHfn
nP7Z/X2Ua9/Y6RXmkpVjf5sHZ+9PTlt48dS+uY83/Q/r3gIfRXX2PefMffa+2fsm2Ww2982yIdkl
BBJ2CIEkBEy4BBJgSQIJlwASINx5jVYFvFtsxUu9a6v2eytFVND8qhVL0dZW661qixWRKgpatZRC
dvKdc2ZmCWBbv/f9MLueTWZn5jzn/zzP//k/ZxKj+mpad02HcGLVqBWJ7/8YfPSR8mHdpFnA/stD
oHzjmgHJ9LzFr3z9cUU8FK959qbklkiOo6jEVRy495l4afHPEbZQHcr8EGGLo5rlchFIMA80gCbY
BjfTPEqbIAelelwSTmVpKFiEgLAV0jQFIWPBSZMhFUwVmjgmWSlbFeYAO6wnd+B6BSVQFJeZH6YW
vg1fHdpDn2O+Omdmc59AOXnL8BHmR+zXlJcqoiqBcIAqQFTOhIyav18b5OmDkD7IxYuzAY8i4Ziz
IjdWGKuoc07MrSucXNHinO+d558XmJ3bEW4v7Rg9u2J2ZaewyLzIvsjbGeos3GDeYN9aut2excHH
Cn4chQUuKcrQWfVWGG9AQMihMkBGBhWVTMVBylWQoznBPeqa5wRNBBd40U2m8iC3eyypMPDaH1M9
A73ZKqJrTpKcjFhZctLsNjm7vfS6UlhcWk7Ho8XRMaHJoTmh7tCdBZwvJ0QXZOHahBQoyXaEExLB
CVhIoRHHZUaeFqlRpKHTJYqLVCkEMoV6ncL8SHnj2FfKh7devWkdcLz1AZCu2HLjD04+cuUVD8yY
mX9D7eJpgRkbon3JeauevWXXE+C+Xw5TZw9ue3k8J9+x9tG/vP1Iz8FKrnoPbF4xsGlJw/Ji+7iM
2ptT6xasHusqyB39aO+OPbcjX1sz/BHhPtjXrpGrBMbLFDPV+dXh+Khp+dPCk0a1MR3upGemvw9s
zbfYssobHcWNDi5Li0Bxm4icTfQRHwsRb7Oq9Ee1cmnQR+iOj8G/9d2OnUvzLuJbVSS5RUnU0V0L
8hxzPujYK9UQhE1HEdeyp10r7VcoMDG3tM+br5w6EFuQJ2X1TvzzOUfy4a4FP2xqawelf1y5f3Lr
glfksdGViVt/MkaOrKy97P4pgKZrDyov9q3dZjAihwLip2PL8mI1g1cfA9mTJs1Szj1892AsUrjv
oY5NkYCzpMhZTEEwD7lNI5Mk+kW+7AJzIMvNYQWeinCAwjNFXAqT1+pUtUblACKwNvSCjV+gf7QM
ss49hMUrSB1HrHyXdq5pcqXESpyP9XElbJiLM1XcZKaBa2XauW6mn/kVbyGX4vg5AsclmGZUajBU
RL0YMqBO1skFk/iSGZiyo0s2YtaOrzr0gs7cFWo6eyXzGxQdOvatY0EpWryjcoHkqaSz8VuAiqLQ
gCOBLIAyQRYgw6KoIIMWwssrcEBMYmZfkUS5Y3RZ06w22cAys2lIc5hA7LCm0A/7QjtI5oM4cALA
XnnuCuZ7Q2vpm6dDsA2Cfcp6ZT22wN9BL7ub/hmxQFzOYWdzYDaHKwlZBGVYFEJXjlJYxUeXB+Ti
yfTVT0a10gKRxCC7+9xC5kH8os33pwbvx5zWiOZ5M5ln175tNCgFeJ5FaIosnicbAFEAWQs6rz5P
Gs8zCsqADOh/OVOamc2yHJwNLpgpQDNFP+zN566gbx5ay3wPXpYa3gduADfsSw2j+0c3RJ9EfpaJ
+OlyuR6zvTwHHfc0w2a6ma3zLGBne5Yzy63dnn5Pf6ZR6EMVI+fLdrnsMR8UAq3ZQk44EOACA+j3
FqfoxlUr5VYD9UkiixAqhJ0JSyNJkr+1DM47Q7ZL6aILICJEn5xSNXbXzCcn7i4bJ9+5eeUvx0pT
3ul855/K+t/+llm36M7xVd3RD8Ho/LZIbPWcNavrQr/1h18/exQreXuGs/nL0IxqqWbqbflBDloY
AyuJFr8505KwyC4YYDLZgD+Q6ch1FAYSgYn5sJQpZaP+aGZebk5hNBGdWC/XNcxpyJJYtrC98XKx
x7TctyzYU7gksWRiv2urv6+wv6p/vMXO2gR7/UyzQ3b6Kx0MM32WEImUzDALNaOzZ4yugZYIiLC2
SfaIY6o9YQAGy4ycGdBT7DBUWpCxB3A3Na+4ckWLKiAh45xMIoNFK1LlyG9Q0U0yPPpTFL1eDaN3
XJFr5oN8kOhEKPjYcfCJV9gqsB1hYUFeKJfRxRIGxyAnEZRGkAIGxSpg0yMVOoS/bEaT0uCfurPt
0ZdP/7Sxb+J9X5eE57e1KUOP3K/8o6Nz1bKOxUC6Z84zs7sebX9WeXHtuiu39/eDCU+9BGK9vWtS
tyS6q67a1b910na4+wZlaEV/tawc+wiYg8GyoaebPmx/GBg7O5f2L1qkfHHXI8oXXT1LXZ6bnZaB
tetA7cEDILF+/fZtfX3KrxQZclnefT9+6CcTsBf6KIpdiNgCT0nUS08i12P3D58h1Q6nD3iSpvFo
KjeZh6IoCXAH8hwH+pIo0TsYwDiQV2zj1vGQjkkyrgglGXOsMkmW+iRaEiWOBltYwAoWI+B4kWaN
VB5VheAzj+ql+tF5qMuN6E8SG2bHsNPZVraH3crybLcBcVVUDhFNFS1XsjqBBROURXCkQ+6XJKoq
/p+A+AnuciSDITpII56SgULPwjd2pbbtehlmA2Gbck45C+5TutjXhzbB91P5CBqH0dzDaO5OdDMV
wCTbWaPTWGhshXOcA17ObiuNZWMZyIFTW3Y2nxUT6EiMF1xOe6klzSstOaT62z/8lZyJ52wpwFUu
/i2uBvl8J0VKZBRnj+uMFFeTZPAV0dfR4Ng+/CX8J5lUhdSauCUux2F2qYM346+jNRgiGjwavKcS
F17AKYfHTBefDg1OkNOhwd/I6fDgabKAK2NEYSD/UuVJ/QNKumqdicKIynPQ55NYQ9WjRwjF15Hl
EdCqKPRbHFNU0kIOwh/Z8Oz62S/fnfoSHHjowakzp66ct/tnypN5RdHtiz8HVPLyaLRwYEx92XWL
lJcB970fx8fGwCurH6+sHcu+7ikI71jY+8OIEPgNZMZMdftNysyM7OyO1F3zevO9ltTb/rzCbpy/
1g1/zE5hP0eV02p5DgtMIudwAb/ocOY7xzgnOeYLbVKbeb51flEn3eXogxssfY4Ml8sXs8OSkoIY
J7moNagQArgWipYmSleXsjlOowNb1piJ7WlcFlZpCrJStdrUQC9skXxOrYjyvoX6X0D0KyvYKZXt
DTW3zHlQ+ceizpXLFnUA08Obvthl2frV9Wueqp88vXXSlOeW3XJ2lXmlp8Sd4Z/f1QHyX9wPcru7
loxr/GzpwsbpTR/ffs/R+qn1ixYhH8U43YtwaqayqEE5VGVvtC+Hy0yMCwHSjQC5gQIWJyURmHGk
1kHJLl3+7CPMBKNDQ903spegrT9gCUQDcqAzwLj//8As+zzMTp5HWVInQyq/U0HFnOdyiLCo8Nn7
89uWnHtV2Qn63wOg/Y7Hf79lc9uh65999pa32levhn/9jfL0/ATCSqKyQ3np7Se+nFxeeO7qkqr6
TzAukI2Ye5CNDNStz4hxirNykMPOm0dkNw6wcUhLcSAwlAAEap3JYgKc6ABk1kCfNUjPGpBZA33W
QJ81GnxKZo0HZNZgpfEi56pOVqe9aQ3Rski5TF7MPUNh+q2hv9EW/GJf36Ms25N6R7v/AXT/InX3
XnSv+Nad+EYg5EFcoHmBopsNuFDbP/ym7CPr122wGBCJAfgu2P/RAv5FX8DPtQWURkwljObyTZik
SS0yYMZFpoH8nxlIWeCO1OZD9DNsUFmwJ1WBbp7450fsg8g/86hX5PE84jGcOYvLMAfNcXMjmGie
Ye7hegyLzf3m/kxLblwOgVDISFut7pgRZsVoaYMIcq25ojW4f1iRM/CNB1dSDEG2VUP2aR3Zxy5B
9lk9jJ6TQySMri+wFMgF0OcU7fjbInFx0YiPEpflq7JrGqjhk2GU/qNRFa8VmEupCjZyfUbzeyuF
oYudnlQhlA3/YkwlYaEPblE+2PEz5ciSpX3gAbByAIh32gMbqiY/sfqs8mdELLnO5xuUNXDW5WNn
dXZ2gdBB0APuqWn8zHOZL1CsPK+cUj5Qni/IBqt+puKBHU/wfHQvHSftCBeZt2AVoCCwEqrlWUGE
DlTJvqCnkbP7tFTzzT7NWMdVDFCCbio5jxxrJxazEHNlEFNtQi4hm1pMtEA7EAf4g94MHtJbvxqc
WHIqVkcRq+OKDPD58IDAib3EM8LnP1GJ6kQ1MvCasKrzY1BVoPcKdvyhlPfQIfjXQ/DdVCH7emo/
bED2uA6RlbeIPXrkkMiUc7RElwPBtEoSDPMkB83CeZoWTcR1ev/wEYITWscJGijkRvFemqeJHr0q
fX/flFtT6HWcqK2pcgz0IKJ7oXjQiau3t1L7Dh6E0w4evIN54I47znWg+ykd/gyeINxhjezoBdsA
tFc4aZ43xGgxI8PuICFYW42zOmJP6Yg9pSP2PRyL8XqQlYBkJTa6LW7A9biwTpeGJm5lpNQaD+fm
i4Q5jD944ouXy+4fYyjelFiwyue3KL+CAFz90ps24wFzdklhUf80uudeLdJsQHfOUuufhjSDYiLh
HSoKKN7CIzr3v4qLJ7S4yI3MBraKKOlvkHCIBf0NQzMPwU/Y189+oKH9NLonI2iU58+RwFg4lh0j
rYad9Gq2UxqAffQA2ycZWsU50jwD3U330+sRiZQgLXKQggyhnIyMb40hxBOFDKaOmc2gf7xBpAGK
gZIBYQRvjjKRsOqgsnVfkaer+qCqYJAVksjy+MipPGRpjKqTmC3mgLnFjAgs8QKiKbIMQXsGb/1/
j8An9Ah8SovAphFGw9rsyI823O9W3QZz3Umz2/bFmF4GJtvRcG83A5LtiCfjgLWWSq5FTgVCAMdq
AILs6UPKog1KzwFgBjeBK0EGSw/tppefTSE6fJCu0TIoOxZnIBCWZSMf4GP8ZH4G38Wv4fkNHLAA
yAWAk4txddwsbgXo5AZAH2cwAoaD80ArhxOVgGg+I3AA8rh20Cb9jT7ps+oUM0h8ujhQHZUnjwhU
angqIPYn0RqvCLY/SnmyAUJyFCTWh6SBADMYYn1Gtz6Ttj5DDmZ06zO69RmVf3PkT+TWmJH57yLr
p4girNsfG3ntmmQSlxuqiVHgGvv31IQDoAJec4CNncUbX2TmBcTe1g1/yL7Hfkm5qRD1CzmXoRhk
NYPdTbk5r9FrnwvmsrP4DkObqc3WkTHLbXXibqEHT0YkU9ogbnZCf8wJgzFR8qD5kXv1OGl9qjQu
LbQQd1QPcV/KMRLj1uVb8gFuIiTy6WwC1GynhSRDC2nVWThSvpC/WJapHUnckkzqI5IMk1gBQfzN
ZXeqFO5CFpxhpdRcWFFOsdnzuxa3Lzj3wD3K8Lx5XZ0L2gB71/3D9crQhx8pKSAcOQJ4tqBbObJ/
v/Lnrp4lyxYvBjkHngbBpYuWLU91gVwwHhWpR5T3UZFQSansl7kd4dJKBag/yWXjHDVZTY6mrBbz
bEuPhffGKN7KQ54XPTGJFgVLMBCENmcOVUbJVB/FjMTYGdlA0KV3Ar7U8+YnOm84oZVfq4OWYCII
vbxDJJFQ1G0tpmElEliJOqxEHVaifjo0+Jgslbgy58I8+I3W+TypU6vkyRElVwjjaWQbQefHzO2T
J0z/w/2HDoEfbH+2oTX5uzGVZVsXvvSTTbejwoqxLH5swvTpKZQjI2VVj++YvjYv4E/9dzha1osx
qGxkzyAM5lOjqV/J9Rh/jIfJwvhzelxZCwztpnbbAoS+ud65Wf051tZAT2B9Vn+Eyc8PxmlDcSyb
EwkOnTCKUJidwVEV6wqQUWQznmGB00+JXBZt8etQ9OtQ9GMoFmHD+NdVWCqApSJQkaigSy8EoQa/
co2RqR0YFO7KrSfDx6NE3koQ9SahdaeSQFWGLy3IEEStkNcKMXokMM9Ur6/52RuiJ+K8EJrt87s+
GGS6ryle4/F/PhKmym0W0/N7GfoCiHZh6CpfKNc3rb3CK9H3XQRYtVq7Q8PrOXmWALJABIwDVVmT
LQ2Ohqx5YI6l3bEaLIedUo/hCrDeYIPgSXS0lffFIMle+J1rlSGAkPXECNHDsJaDtM2J6hYTRnIW
tpspE5vYRCKkyYNtaDJZsTpIkEww7aVF0kh1UKz5PzG6NJFLU7u/aUTuPIDLUV0QDSerqqJpCFer
GCZ6AmkWbUl5XsB9ahBMQxnrBxkXlXt3KMOKWfn0EHhgx76GGfMfvLkrEgtvaPn08MIbR0fCsCW1
h309FKm4e+MD71aCh+TFuVnu1O+CkZJVOFttH/6YhajOKEMrQ0W1hBLRM8sonNZ34ZGHzNpN3l3k
3UloooOUy4gbBKiQX3AEioUiT14gL1oljLGOzYgHxpRMFSZbGzMmB6YW1pW0Ifi2BlojK7xL/D2B
JeHO6FZXX6Avp7+kP7LdHhJls7VSwG+Ijth8RUwWFwzmx0ijJMZJwSKnj+Dch53BiG3rszmpoE+k
dH/B0Ui2kLjUX24p7yuHYu9oveWtdWq1Nq1amrircEPK2WabW7TMtrRos21D0XW27UW7bXcWSbj9
hNZGDzl6KzcPM0Ym3f8u1BtSuJzJO9+LcrlYOKOx5a3bH1CGrzWvAUXf2/9q1+KmJxYdeh5Uf30P
YqbmVuWz79/3y87N8uczf/woeGzu4+PlhurxZxYuuX7d4oU+h89R8puHnvuiuvREQ8c1y5K9meYi
Z+le7SEd5hRRG9fJXsDEOZoWLGJAbBZpaj6AhFs6UD4+LUskRc9vZrEgeUI2EOwKGnBP7NMQ+9Ul
iB0mkiWrbS9JfhNWN6dqpB7jMR5kTqU+P5T6HN1J8OwHbHAPvrO9KEsXozvLon4r+0P2kKeGrhGn
0dPEjRkb3UKmiXaihfQ7AiOqrTN6Xjkh2wh3IZxQ6zRiPTCLHCiN4C8bApZAICAHaIvDuH/4T+q0
jGRjiDFdrBnJeYy40sWnMuqJykj6puhkRnUPEhqs+FbFRd0akai+oI2PVhvx7hFNM/SRLa6fMf13
1934Wv2M+kPBwtLdvStujxQGD8E5D/6tZdqUqQ0zP3mM3jq0dfONVRNrJ9ZW3baKvh7ZSteMOepG
eUk9aEBhimF5bi63naM5B7ImyzNzme0MzThoSAugjrSf14FtkKNYuJ4GNA2FydRUvK+eZqg8apym
A3PU5YJFAOjHQIfpON1K99BbaY7u5rEOjOaXtJG9ciQXpCVg/CaQ9nQQVGDVN3VUOZM6+iZ4A7yB
6osoeh1ls9F9L0DlzU24yqBelh+vp5fSm2naBAyQYSDLCkaDG3hpD+sVvIZiulgoNoyHVXQ5ExOq
xQppnKEJ1jF1wjRxktRkaAXzEDrnsXP5drFV6gG9sIfpZXvFHlyrMOuEbeJaaZthlNGBrso7OBbh
HNCkPhHJO0VTIkRwRsGZgxyyxngqxjVRddwWaj3HUWtRkZEwd5gHzAy31GQ9hcIAnjUWwck+IKA2
nwDin7gnj37QvNEPf5PyXx8ov1Z+956y4TegCsRQRgKV2AbMm+dKESMtYd4+l80cRXdVp7F9A/Wi
vHs92MJDiWElH+OUSpmQVClOZ2qlNrqDaWPnii3SXMMyehWzjF0qdkpLDVuZdZLbgOcmOgReoB0o
U7EOjuNZhgeSgYMC3llgAhx0wQI4BtZDVhS8QrFQJTQILBR4icFVg4lyUQXUGKqeakErv8QkiJyX
K+aquAaug+O4Jag6T5bjlw1vqEbrr5pA24+g/yATJEVIjEBWf2xKgeBjpVfp/CPkFfYY+D64i309
lZOywJ7U3fAT+GnqIZik8FZ5ijmOLCBQb8oLSkEpU8THeRnIjMy38MuYPl5ycV6hkCsS5nDtQg/X
KwgCnjPnQGiHlInFmwwZiqcZVF4iBOE5SwGpWRqQGBTMUBmdDmeqEjCyBFGIJMBgrqhVJ1/qRclZ
vSg5K5OiEwfBAZTr0kEuisOaXqRUWY/p0FAdAttEBQYKdtgizPHUN4dSX70PdoO7UbU3mFoHN9Ht
qSXwLuSpw0PKm6xveBoCpO1p0AIRKmAU1eqU3l9lfdh5lDc3IWazbPhDJovZhBatAiyX240SE/JK
zhATtuP7LCXvEfLebp6RvaB0ubkza3Vkq7TF0Ze1tVSCQlFNmU22QZstR2jOBJmZnkQOM3qiIAHB
kgWybIVx4hxQF62hXjzigcrMoY/KMlAcqR7taY1LDb8e4lk+LToP6RIL2ZnIkZqSU+t9pyhyuvj1
/bglHogn4vQoHNDxdwl3MOGvjBLwV0b5DXgtKglfIOKSQcDHGYiYaCDp3ECqKIMLn9hAClIDCfuG
a0d0XrSS8nj6M94GkSKkSlNZE+oOd1wQkP0QOHmjCjOudR7Ufep5ld+6f422jdjmzmQ9520tim6Z
ufsPq3qWgOyHIyVFfTVTn+6SKl/r2fCEnKh9bs6ndTO6+zcufnijrcbuDhy+e+CeSCRHyJJne9zW
wvznLXmF0VG7VipZKIA4MtxdrZ1d0xEGDiAM3IqCfAaVA+xycQzGLeOdZTl1cLKlySnnzLUvtQ8I
WzONZpFz19oYI8iWOckgONSl5Fod+v5Zh3/k/tkv9Vz6jWwgC2jWd2vtI4ulfx0NvpaLycrdmhvI
TeRCs180qqouKcMEfLhIHEf0GbEKSFIsFhguTK6n9Jx6WjaQNMvhb5JkS1Lr/uEvnibJdmfwQhUA
rVa6hMNLShYOU+CqC/Itj/VMvDp2dacPb1N3gd3aPKn+8SUdN0827hls3rv60McvXnPbzEcbWtY1
/ujnsPLGv0xrbo4UxDhH6s2Js5TXlOOHf18/NnVlXibZy718+K/018xGKkg9JU+zhJpDMAxyzSWu
PM84EDePc8U9jaBZqjM3uyZ62kGreTnoMW8B68wZVqsjYWSCQV+CFi0hopeFyLbVdDF8RDf0EXkU
se9NITdBtdsvEryLAjEw8QCR0FmRmAzVuWeIpcRrc9M9n7A2GtlCS5IemsZFrNSI7pkKWrLVl/56
4WMdm19paGwBkX90HpguzXlm7v0Hnnq4akO0uMEpTYmU1zc0/Ok2YAdjxxS+PqnhnddeeTfb44za
EDZXImxO0rAJ5fxqX1nm2JxmX21mQ04bt4zrs4p2AG2sZ6KZAUJ2LSvZHP8i1pjUWJMra/A8LYdI
yCEElLKOYHslxHySFnROyRESayzqJmFix10qTrXN4GRnpt8vePCZBNzlCOOzCeRsAlEfBXKkQLbH
CgTJgoDPJFwbvECeGimoE2SWl1M6FBPI3CRwhHKhTX+6xW2roEduSWAmDc7Ys/TwZzMm1z3V1baz
aXBw2qb6e/fsvL3l4fVTLgMxYLv5yGXTWvILwbGzw/CqXN+fXvn17+uxJtM7fJzpZLZRHlTjHpYL
C5iwqYwZb6rOnsQ0mZqy55laXL2mTvcm05ZsM6gOBCyZNU78dMcneOszCosGPmFBThok8T5IgOjF
VjaRkY/KSbcq64gNbwniAjgRpAOAGAcQOg38dmJGOzGbneDTTsxmJ3+3Q/xl+7Xp6hUZSfVdHIkr
1HIqTKpXIqsHz3dw8X6OHFU4sDu1YMt0Dr08YUzsljlr/zpa6ji0SjmhHAbhb47+/Rlw2+27nzRC
/9I7R5eVzS99tWgMKvmdCKO1ypmvS37w4N5rVMZF27lsZLNfy0t9BFk+Uu4LjirHepZGdCThpAzm
CYKNNQkU3gElWkQzwpxRTTQkxRCXMxBUGABJMT6LjTLLJmul2YUxas7BZzaT75jT0c08Cl/JjBFK
sqHZjs9jxp0ybUc/Ppf5Ou9ITJWXl6fUQVTriyUqSH+E9MNRbtK816n2BEPxCpSgMM5ouxToLti8
CsxSnhwcGDj0XKKnhF0oZqy4seDeoYn08/fm//oto4A9VmlnJiEchVAdH5UjNRkTSspLx5XViU0Z
00pqS5vK5oMkO8/VC1ayva5tbF+OLZe1B51FcjbD65UYHsh+PCmeN8i0adREJ2/hABfMKydGtusu
btddHA9kFSE+ivMQ/57xHfzbd6lvlwfKE+UwTKAXJqsS9ntIp9KDfTsfn8lDgqWHrJ+HPAnhIUfi
MXq/dvTIbII3oH47PTipPgaQdu98KxW8sAt0sbtXXuzuiqJ80/7YTGnU4e7OK0Kh7Na7NyHvnzLx
2QVdVzeifNR0lXz33mvunPnIgHJMOe11v2CPjyouvLxuSd0kVFvxt74+rb65sKhs6G3YlZv12qHB
FxMI1wcQcDtQ1HWBCjmDdrqc65201STUZjBmAEzCt0bYMyTZQL2OhT7SxdV6AkOyjSwDM2IZMJ/T
BorGEHJ1frePLAvmaDGSwgigtbL7+56Ap9MDrRf4kDDCh3wmnSOY0g+xmMjBJp0jmPRK3ESUCHw1
EzmFCW+BIKobVsqICLfTPbLLSRbvgjBNIk8Ya2YJleIFQ7bzu+p1yuByMh2Ddo93YdP0R6cPDrYN
Ln7qF3Db9B0FJcXTxg/9ApGDVxtnvvcqjsRPIFpwNfs+2UX5kJwB6iAyTyWkOVTR4v2Cu4hBS4mt
OhkyMe2hXxJJGLXE8AFIunudA0RvOaI3fzWDaN0u3SCsbhBWXRbS8x1WpcKdQnq6yWOqBY6FSfWa
IBsIyMZD/FjX1W++aRwcZD0Hz+YzSTST4ReVdugkM/FSr8shic1kYXo6rgle1mCwyLyp2Q3cAxKQ
QKdLR5ZLF4Jc+v24dGS5fGT+6mNZnZK7zwu8RAX0Eh7jxXSHTNFLRFD0+ZjaJPBCLSmpe7S8+LmB
DHxqL4/P62Xxcnt3+UcubrK8XJ9yNBlNag1bMu8kmfelfdtQPAidyBKHHy26ulTK7Ig0tLlcpk/B
I9gw0kuHrcYnDZlFRUVrZtDX3IsZ4C+Rtz2BvM1AnZXriuAfwfsiLQKLKQCyYMAUAVFTmUE2zDYs
h1sAfqgP+NChgrgPGiRaEiArsTwqkgUD7JT68KMkJMkWEQ+iTDkm2YSKd7LaNEEJzeA5aw/j+EZC
4+hF0EgjIo2R46qvsIyGkH+o0hwaEF9hrzNe6iu4TYxqILXRllBVHvzY9Ja/e5gXsOyBhZ41wRBQ
nQXVt8wTZxR5y+AgDJxM/RN82q/cwDmGfDCaGsLP2SCTbSTPDP6XXAgBEDC+d2kxRWW+xJO19q5v
AACgzxGk4Q+M6aa31uvWsiogUwOYAJPBTuY8+MmEjmtPqpIHGTcODhJ1DEdM3o2yXhgclpvoPLo4
Iy+juC6nruCZEv7pfJAfyMoU3LVFuUwWC6yZghwBgUhZRI60RPoi7L+++QhOhG58wxHCqABpIgJB
6+CfILUWwOttI/MpIwdlalP6ioRRgHXoMJkMIU+gy5pvyNSeHybXtJBrWsg1LT4rsQW+jpVcB33+
g1qOWwvw0VaSOa044uPTW/XQjwbnCBzQYFgO4ktZAz5yGR+5jI9cxkcu4/Nl6ouSmVZJM8nBmTrw
MvXVyUxznEwJnyJTlQLUgWzGV8rsClhl65VW2hpNKyk6Aq0Xfsba+/lDtPCNlahqBM/qVDnZb31R
GEfFuO2iqO5UE7Ia23n3oMnpnjOj+d5mmlGH0+/GYf6JxWvvK1w7uGL/E3Bbw/aicGlzjbsmOxWH
26ZeWxQO49DPJLc1zuxs7Wz94DCl516EJBcovjj3sv/D3OsekXvVZryeaBVd+P4LXuGLEi3uSRUR
NJ5PuSTZqon3X6dcgsoLcq3qW+kk/L9Nuf8p4zq/Q8YlZkcJF1c+HzJrkMUNlBtFYN94c8wac4x3
NZnrrHWOJpdgSYiMM0FLRn0HhFE3vRG3BIjJjH6vrNl0SNc9/qJ6kfYA8f7h93RWc0qvy0/rAshZ
uUYVQLwWb8Cb8K72MnaiNdqJxe3EynY/5yJPGRNVjCMElSO1EYcplBefHT+NjN5J8xX/Db1f6/k3
+0/C4fM7OUc0VtNPMmGOuUb55LOTyqfAffIz4Hnx8d13Pvb4Hbf/FI5SvlBeAtXAhv6rUQ4qX7z7
xhvv/uHdd7CipHQztyKL4qo9V84vh1XO8pxJsNFZmzPHvtR+hbAtU9LVJDZb5kSD0aHbFA1OExRr
apJmzNd0OH+pbX+zX7zh+lKrnv63spLxu8pK6Z5NWl/SotF30pcuFZj+jcKUBu/FCtNl9bVPds+9
qXFwsOm53lc+fPH6W2Y83NSyrvGePbB654eXTZ1RUKSUsv9cn2hVfq98/srhKVWpHXm+N0k91k3q
MbwWvBweT9f4yjLH5Uyjm3xTMqfmYAWFhTbGI5sZYMyuZUWbQ9VIvnOk+a5Kylm5XVVp/6OSQjZv
CxxRTuyX6CdmfBZB+HcqykUp4GIZBYRs/6muGpz7f7p/fXJWXe3exfNuaECF1GWbpjz0+HW3zXxY
6Ya+pkZEU8y3/rmpsaWosGzoebgplPnnF196o16L4PRaRIDt1KDsoExWxMEQ/7KguD5JsrCiMPK5
AW0jBUU5ZEefAxp5YjieTJcn8OIJQnmfqCNUTJMYDc46QvHGFdlGdL08DE9R0rU8Ak80+Kcq6u3M
+HaWhlFZrT5xRIx0SbKj10olzWPmPtg0ONj30/bRpaX0rZI4vWbor0zykXlNLI9nf/nwx/Q7zCaq
AsyS53JQ9Duh118gluSVi9V5teK0vIVs0jUrOCc6u3w1u9LVmdMd7Sl3bGEHbP05m4v6w9eDnaZr
fTuKfgDu8hsos6eYyaavzEVhBGMiN7dggqoTyITs87xhAi0GzRhcYWyMYmK5YmKzYn+cxGQP0ZI8
ZAOgh6QcVMifforU62Yd22aiUxPdxE8FPTzJoHozOL21Tdtt5NBiTzrknNFDzhm5kOD6Zq0H0REf
iLM8Cds8aSXwPrKc22OkaXC+dUB2BITD0XRcTktZ6I08gao/ATai3ojHCtNtfx3Jaf3Vrbb+3S76
ndT7234/RWp/r3vbjQUFK4uuit+2tWrc2P9e0f1qndTwu8VLbw6XLIxdFb66vh7U3vnS+NAbk5pb
5tTm5npEj7lw9+WTt5RFK0eHXo43Nl82ORRyGT1SduNUtNYThk/AFHsv5af2yrVG1seGWdpg5SeY
DBLr97sTtNicNZAFzdSNWYLJStBqJQtkJSzbSpbJ6pMEHotdPK7cbGTDJRG8NF/Q4c2n4c1nEmmI
nAM/qqCmYN5N9l3uzLxQ71LxHbWeLteqt4oKdcORKlzjeq0C7151Bs930itg6v+29x1gUSXN2idN
IicViYMEQRCGzJAECUpQkKgIK2nAQWAQBhBFSYq6iDktZswBFQNm0TVhFnfNWddddY2orJG51c2A
o8vevf/z3+/uc5/7eeSd6u7qquo63dV9zukz4zzefuO2kpL95MS2Yq5u90FhtqndlZTUtHafpiKW
kr5tjUvb6KEp1pbm+jzU6+thDRELY747qe+jo8zuyRnLoSlWNx5Lsz9LieR2fVO6tYtg+tzHsD2Y
/mm1RsnD6JOOZUSrj6PCzRG19njavlL763sj3I5Hl9zOZbf8RnWHn7kdcyoXuRZPdFwsgtuxUAPi
LY4k3Mk9vnkW9tUd7HbX46nOU75Oc5Y7XWHbgqYjE7t/xGbx1qP7NfT0YyKC6kL2F4eEX7lAXfo8
MbrI2sYy1IPuDz72Qu9TgI/ZRLWPrwVjxXZhhOxAJojNtmIJWT6sIaxEFouthx7h6tEUbUn0pt0I
VzqYGEDnk2MprnyjAoviUiR66eKQjxlPw1WFMCAyiLEEQ1SjjQo0rU2L6HyaoQ3wRsxyDgzRBJhR
Etr3iiruU4D/6FG1/GE9U9LmeaCt3xkyjoSe8HElk/BpMl0E1sQQBJiaQKgQLXsILjhXvrGz5cve
Rfxq3hufyXgZTBvSNmQfyoo2ZyxYZlxrZSfSg+VPhrBiyaHMMFaschaVzKRyM3ipSqOUi8jxVC4j
5Y7j5SmNVTZSQc3n6LFZbIKnwaN4HRsUlNjRnXsTwAHqbGO2HZsm9HCEs8AdaLqahlo/NYkaTbDR
Gh6vNDv2MrHxLmu8tMR70tgV8k3NDjiCyR9Xf72RAf20FGndsZlBG1ykzXZpu7W57V7bg7q260fP
kj0WkUY/IlfRCZ+Qu5bRSegPjSdPONel4DNl4p7PNJ6yPqlD63D0eb3p3hxPwoN0op0YJ7YTx4Pn
pRRKhJD+tD/jz/bnhPAGKcWR0XQcK5oTx4tWlpCJtJiVyJHw0pRN1SmC248ScMMoH+54Kgc6tZ6S
shJ2Fr6lQusxLIakWDBg2MxYJh+5igGaZFOqJDhNmWGUcLfpBd2GDUZWo1eO0Neg+KiOUGXYFEMy
ONIz5eg2SIID3t5ijfY64FtH+GvlutjqYNK508GRZEqfwVL68A1yR1v4M9KD9LzZFkTWtUVSfSkB
+va3z9eRd7xgTYdGAoeY5uPL4P3b4exEdg6bzaM5rJ50D1YgGUQPJWLJIppHcVCfYOkxNBNEBDIU
QVMMi1KhRpIkSdE009kkNBKC8VhgEdU8dR5JM9pMACNi8sEv5VyNX9rbg5tDdNzJkY+DQ/KNK9rt
I+Gz9OSFNr8zZCwZxyR84JAXmd6fjtKeyPYEWB09ANt5RIyPezeuO+3MDaYDuPF0FDeRW0LncJU4
HNobOinF9Sa5DJemOByG4k1XNlbupzxCWaJcosyiJiqhjXS/wIhEL/vK36OQP8QwMXFGuxy6kSb0
g09jqarPFXT651xqWRXtvKTyU/s1NpStYpThnGvvomkI4OwpKugbegg7/F6gjvzBPEyn9KqbNTU3
btTU3KTm488bN/B3ZXky46mbBE3o+qiQUWiLBf76RMouQXGjBTP+kwH9C+WJ3l6XPaMfkpX4vpXt
TkoXpjv0FVnbeSqu+FUNVfA/iV7/p2AuodDuWEf0zjdpjR7JgE8rv2979YZ+SNmB9uXwKcSS7GCp
CZX1kDRdEEXpdoihQQxBkWCQoij8vV/Ctlffr2brfG4GYfifsfxIJapJE3y0kW1UBLWFNoYjiE6n
K+jNjICZxXJmPWY9ZhdwenAiuDbco9wnPAveKF4N765SkLKt8iaVSlVCdbZqi1qM2gf1cvVTGr3h
GA2x/o5WibaJ9hWd77uJum3rPrD7qh59emzUtVU4/HX9ewbqsfTm6gfpPzDIMgwzUjPKM2YbLzF+
ZKJqcryXxNTZ9LlZlnmK+SOLGovW3jMtjS3HWzb+C447/4LjffthZWQV8O/j38e/j38f/z7+Lx54
viUJguMOk7QDmyC4pA1ceTTIFhPqgLaEBmEmOwdoI7sP2BfyNQgX2VNAV1kGoBCXumP0kG0F9JRJ
Af0xzzDZVcA4TA/HPPE4JwFQk1CXTQDUkCUC1sumACKNZpBzDtBF1groCvlmhBumhbKjaCM3LvUE
XWZErAy9BT4Ulw7D+XFgpxloQXQ9xp0YG0COOWh8CqhBKAFqYtoVZJrD0kSJsMB6LXCt3sCJUBOj
K0Z34O8NbWwF9ATailBv+xlQE6MhyLEijDD2gqsFK/DbYkBXwgjQH9MDQY4VEQFoA7ruA9YD9sVW
9cX29IVarYQd9okdYQE5dkQfjH1hNWRHOGDaVRYDKJTNBnQHyXZgD+IfhnPiMdbjnAZAB5B/H1AT
I2qLA26FA26FI26FI26FIz7XjmC9DqA/pgdiRDY7YTlOWI4zWLgYEHnPGctxBv6rgIjfGfM7w3lB
+fGyk4D1mL9Btpdwwe11we11AY0IXWRPAIeBZBfcW1yg1n3wnXrbbUAN6GmuYCGiDWVuyKcYkZ9d
QcIUQAvQ7gq+QugA2l1B5htAV9DoCrZBfyUCZdCfwEKEwdDTXMFOREdjaTGyUMChmB6GMQ5jPMYE
8LkrtCKDcMP2u2H73fD5EmI7hbj/CLGdQrBzK6ARRjPwkhD3ASFoRxiBcSjOj5c1AqJe547luGM5
7iAfvbSA5LhjOe747LhjOe5YjjuW4w72HwUcihFJc8fSPEDOVkALsNADPIPQAaM/Lh0I/B4gAeFQ
8LYH1EX89YCe2BJPkCAF1MQ08rwn9rwnWIJ4UG/0BGmIZwCcBU+QOQEwGGM42OZJDMEYgXMiMR2F
6WhMx0Bf9QTtCIfhnHqQ5g/0S8A4sNYfrHpJBOC+F4B9HgA5H4lAsO0pIOqBgVDrKTEQaCkRBNeK
noAqMF6CCFXo5UE4zgRhrwaBhCmAvYhswHiQH4R9FUQ0AGcI6H0KiPSGQOlTYjDu54OhXYiOwIh6
cjjmDMec4ZhzCM4ZgnOG4JwIbHMEtjkCSl8BDsd0PNCRuDQSl0biFkVjn0fjdkVjn0eDb28C1uOc
BogksVB6FRBZHgv5iG6A0ToMpIUCotJhIBPR/pgeKHsOGIER8ccB515ApCUOOBHtj2mkZTj20nAY
KYgeAFqGg4RHgMGYjsA08lg8yOkPiDTGgxxE+2M6EHTF47rxWHs8rhuPbYiHs49oZEkCtiEB+FsB
B2AcCGM2AfMnAD+iozCNbKvH/b8ez0T1eCaqxzNRPZ6J6vFMVI9nh3o8E9Xjmaget64ez0T1OLbU
45moHs9E9Xgm2oljdQO0yBZQE2N7jiv0kwYYnamA7tCvGuAP5cSA3xrA95Z4/rSlbDt/s8iB6Pih
KJLgQKqdpoA+LKdpyN0ipxkFHhZ6Z0hOsxXyOcT4TppHqBH35LQqGUq8kNNqRB/KA/1aFUODLhVK
hGkW0BpUPqbZOH8Spjk4fxamuZhegWkeSEql6uU0SajR3eQ0RagxjnKaJlIZdTnNKPCwCF3GT06z
FfI5xIdOmkcYMHlyWpVayMyQ02pEFKc3ppUU7FdGtnHGYVpFIV8N0ZwqTGsg2ziLMK0NtBZnPaZ1
FPi74Ta2090V8nviuvswrY91tcs0VOAxVqDNMP9JTPfF9BVEcxVs5irIV1HIV5Hbv57vIBC48QeJ
U3IleZI0Kd9PkpsjyU2SiiXZtnzfzEx+hDh9pDSPHyHKE+UWiFJtY0S5qUnZSXxxHl8klo4U5fKT
+LmidHGeVJQrSuVLc5NSRVlJuaP4ElSikEzrWgtfnM0HMfzobLEU6kdKk6SiPH5SdqodCJBgBSmS
/GxprliUZ9spwb3DjAhRen5mUi5K5yFpzrYCB75lJ5/VoCQpyCjk+yXlgoHDJPn8rKQifn6eCJRC
E9Ik2VJ+Uh4/R5SbJZYiA5KLsDkB0aG+UJqLEzm5ktT8FCkytXCkOGWkQl34FGenZOanorZL+Kni
vJxMUAD2Qy0xMKQAlyhbasvv0C3JziziW4qt+KKsZFTpi6jsDuYuLcLsqeLsdHB3HrgjBXlPQTv2
o1yWBzbAUgxapKIs5OpcMWhNlRRmZ0qSFJWCzUntloKjOz0uyZfm5Ev5qaICcYoI8YwUZeZ806CR
UmmOu51dYWGhbVaHu21TJFl20qIcSXpuUs7IIjukIs8OJikJkUtkEUlEJoSrIkglE0WkKiHCPzvz
GP6+lEcSUvjMhhCXBHmpdA1dTx+gG+FvD72X3kSsJ/gQfgRwuAE1iBATKcAnIfLgLw3q8gk/LC0H
YxLkiIHKJmyhxBfkZ8JnBOSlEyOhLA+nRPApAu4CwFTgjMGpVGxHEvoCS8wngk8p1EJlfJyfC3Q6
LpXiXFSbDzTSmwqpLNyGUZAn6azTdWna/1NbkEXZWBayhg+TcTa2rV1/uweluFV8uS/t5BZIFFqQ
Aql8KEUWiTG3bRc2uP/JGxG41fngSWR/R3lep23OIEcA54gP09Gf5VlBHrKu3Y5C3EYkp92Dw7BN
fOybIvjMx2emvaXtZyENa5HilqF0Dq6Xhdvf4YFkXLfDOwHgn1A49+11cxVKcrBlqaAlBUts92oh
1pUC2LXe9jTiTQEf5ONz2X7eJYCpuDwHe6eo0//tusRyCSlyWSKMqGd+225UnokpS6hlhXtfFrSr
Q1NXVmX/SfJ/3UdfpKdiSeny3p0n7x0pnX2v67Z/6Y9f2+Wh4AHUkva2SLG+jl6N5Le3NRVyCnHL
JXiMdN3Sdj8nfeVTkbx3f9vHkVelwJePayJrC3BrRJ1yEGcmcPznZ2gk9lwO9HY7OArxYYs9+nXv
tsU1s4BHCi1CLUzHbcwBCUWQ29GKPEIxKqK4J+5M38NRUvRV1BR9FRdxZGSMGHsmhBnAeAEKgTsJ
2oa8hqKpL3Dkykd3UscPbBKwDh/TxS92ta8C8cqLIGWy9l8ZhdUfQXQn5L8+Su/EL/5+WUsShBJc
e7sQZGaSNBvqwronNGogn+geETaITxiALhnWqICd9dwghHRdz0ihBtn5SRJUpiQlk1DDqIPlkHJp
FFrbyVMa8k8LtBYiGHoq/T1dRU+DFEW8Jz5AkTHJxykuQdLVWIpULk0uT19MEFgD/NNPEpTrJ7B5
fSoHVv6hSnKo5eX6gyErmCJJe2UBj82yVqMpPRYhSGIrWbNJhix3pUhmeaRgiMBGIceg1qjUABbq
6AiDUYb6CjqjqHd5o0NgoiCM0Xkr1DkRuH7OjrQny0I9prrXe8x0m7W8vHsfQTmjJSinPiyn0bek
qMMCvsrTc4pms3drytM7PgLVTkvRSluQY28tsGLT0Yyydi8/SU5RLlrH8S1TrPj2QqHrN2sxW3sj
gUE7c7cuV2n2JgJjVE5r634pj5BIpHzffOlISa5YWiQw6qEqdBXY2wsErgL4F9dD1QH9qqy9PPkP
WFRO9lJ0C8ki6HJSnYB8JaqcJIn11IHDOb96tAzWt1y2YMx3gie166vNR7xrmxe6clfbklq+d/GQ
2kW1MxIdRjX3Ty16vqngZNT1lt8XVxrMWDYxbfuxUWOTTS8bet5WJ2c/mn+0sW9aTc1Iix8uuNs0
quwcanE48Dclb7f5NustheueBlX0fzBRfV9NZnTSpvLiFYl9C0Mf/7Aj1aMm3MCea6azbP1vs6x1
f/VamKKTOJQlWmboGjH5j7Uv5lLH9X9qjA7YPrW00f1p1NzBmz+vHZslHbxF98x8nqUJETszUey6
L0SL4xkjG/5xVZoSd83FspjYFw0e33UvK2Sutx7cXDqvbevZkstr9XLjPU/tf8ld2UuwnT3p5HZ+
ofakOxT6bYSVZesEZasFZbXgTUOSKasRlC0o1Rh+IeeFOHep6ZAJOtsGTZedXpH7P3/+yv+mj9Po
HM57pHyo+vUCXednu0mzq4War+MTHZYtVT7tzZo1ZcZJ919NWl7GzrHZuXxAU/KLT1fOeHjErXeJ
EreZZfU7eWbDbVbxLftqr2UaORn72rTCdMWHPl3we6AZxw97kjxuy4aeTdau5n0PilZofW+unrLy
jyiD9yYnL3d7HbEp28+B87m8x7uH6ZmqQ1oPvIo4ceC3o4JPfHveFMN5VnqDLhlSq1+V3qV3DH9T
f6sp9rko6EREVMMO2lJLNvPyS+6MCbsXHNvoavPL2F/WFT4oWE5cyOh3+KLL93d9tdY5Z+hn3HC+
97MB88u6AKYpztEte5CBavIupdppP12K6hd41iB6Tc4NLffJc/KXrb24HKJCoqCcDm2PCkq2GzVv
hsvil5w+1BFTDP+pYADj3s0B/kEEcIBgYO8ASeeOYFCEIygIYWtT0ZH22gJNlOBqK8Um5Y2Eixwp
qNEQqKFMjjYnQpSaJclO7TBM6a8MMxWYtBump1ieKuJHitOz0aVTuJ/v30aFXUXjLydsDxCuc9pk
f/29uXNQ4aGPxktPBIx+0Rz46OdpR0aFRiS/+YE6MuhqUKadmbeo8ZzpLuWBu0rybwUc2DBDLfyY
uXXL8t9UTY2bfc0+JP9wvmfA6jnBxj+c3W7X60hw32LJtW5GHtOEGsJbB6zepHn0JR1kbb0HrtmZ
SU5e/HHvtpSS8vfxy8smTpq+tWX33JXn3daET+rRe/LgW4JWwuvN8fdeZQcrn2UK19o6te6w3aI0
PnnWmLTFC/NUK7e0HH3N3xOmVZ1y2uaaQ0DP5/uC53uER+qeSxtStKFuclOM97Ly8CnZrHrnw+PM
DkSkef0w+Iz1BMfsiQPYzUsvBFdS2ZXEqkOT70TKo8IHQdkfAm0UFMwZFYESmwsTGovFoen/HaFC
HdmoTZIyhiWg4UNgiDLUmO6MzhnDcwVEzvAtr64fHVwzxN92pX/KS4EyKlZnGBhGlQpDB8eYcRs3
Twi2aDm3f7C0dmhvaZ/87ZWfN4bOHUMMenzqd92b4mNqtcWvKb/jpyafeRd55sdlB2IkL1P81/sT
z+c31Vwy2K28rKfq3CvXjeqsxr94tiZv04zbwuleCzP2u2VdnLLF9POdx5fFvFlTDrTdI/Y5vf6j
+L2Gli3rd6v5c/qPshy9y23GXY7qyYSRZw+U+o5KW7dv177pTqdaaI3isW8v3u1/Z1zbvXub2lrv
XFLdnnN59oOwBrfa4r4/e91wUk52pZaVZZhObY1PmbE1bp/wSuK06Il6jm89Fi4vV6kdUbXdZteK
1ac3Xuc3NAp6TuLrqPbZH/HG9+53ggezLcWTD+fcf71247nS/rkFahBjMiDGRMhjTJL6mEHti0bF
ccSCOPMPjuqOgOMoEEDEcYSAIxAKHFDSESUF0n+JafJy+i/K/zbW1N5Qqj7/4+GgRWc3uDvVmQ4b
dSPzoEmvXXObnmxuPH7J4kcHzar91xNsPrrEGHWz3jxD9ZbOymzL0JLu/Xw3VfvUB05RvVY2t24B
+0Ksf0H8k1ef1O6XSFc6npY+fPEgacUEeleA7JK31qWtp75TvTCuZZe26qfEDMtJ+dN21e2f9KjH
jpkH33ZvSE54pnnH/bnJ8KotpXlHAh7Mm1qYuOi3usLDrtWOOnbaN5JPbtZbH7Ywve5nvlAw+m51
euD94wZvVMOlvnaPWGYZJqOCts4+uk14ov/qrHjd4I0zrkyv8B6jNODqqm0TTY/cbxmXVh8sPWDh
G7I4SSdxsKCp/PUF5Zzi59GDCi9yowvK5LHmnaDsLfa9oToasTAI2YcUBuxrE5/pxUPeRYUsfNjj
SkaFE8vW4lHXoQnFCUNTRlfQvbTrYe6PGIwZL4GHQLjcdblzpaP8PlZKbuY397FyRolRrp387l+e
nV8kdDRbyBIM7FAJ6xBPgbvArSMtoCpt/vLGGBYoylWQJP1mAOFo4xMriUxfyq9wItV+7RHiWff7
1bKS56pF0sKwBQN0XxPdxBNuJM+s/Zy+YvEvllYfoq/80Bbe+B1v+541z8pfLzSSDPvw9tU9lZ+q
uN7de/CbD+0MGMC1SIzlhcx9yT2zd1D2y/sDtSydq0xy74xo2CLWMpv7/LET78aEbMlspYhTfUKD
NjjYVD5acSbBYv9+z7vDt1Uo73U2CJsYMEC2b+6KYZz182+NORBbsnrt4DMtdYtrfO+fjjfzvlni
NGBw6/mmcUt+bzi5OEUncktdzYsrjeeXr9g479RY68k2h05c+5RJX290q3vVHN+zh/qhP06VrtHg
6t2aafrb1hWh3k+2alqMUTtss2fVqBMzPCHaLIFoM6kj2gQVP2t/IPHPRZsocZYoT5qUlaMYbVwE
QnsXgb2zswNe3tjjpIMAJQVla/4ltvUWmLdPlEbZfuIcdKfWPzKAHxA52N1e4O/W19nNybWvX/9A
tw5GWtvoLxoRKcpF93b/NkA92ctKabpWtHmiv/fq7UefhS41uyMsMOJddggeOuai9bXVnJkvfvP6
eMCieOXHh+MnOJy/5lUldG15d9XDqfvPs8s/Oj0dOSlXb8bd3aF3d0967ahEHa4tyHMOTXi1617w
eMPdc8fckBlN6tY/cPS5kt6xWs0VYR7nP9xurXrWj3hw6XbS+x7VIavKPN+KfZ7cm9rICdsrHfdY
5eGAJxszX11KL+O+635qvPa+vPu80A/JH58tF9a4t/2u2ZRklDz0qlJUxSWPkJD70QfsEvWmz2b5
XU/4vVzJdAFvOcteVDVnsJGvSe3smZ8D/AMkzvUBrnXi9aL3Tn71PX70EN7TmNaiN/lBVLixxxL7
OsUA9SUgTch9adsvxuqu+R8jd5OfQu5NOP/A+6vYI3k0uN+CPU4bQypn7F/8ZJOHr9/xC/9fsUea
l5OS9N8SezokSbuKoNw/ReEuApR4bDlPpXvz7fOBU20bm53GlpX0tvTt8/onk9lqC+pGRH5n9f7Z
4ajgdeP/0L6grPN+UEtlNyL7QYWhZcBaG6HDLUmNa9xz04gZUXR1v7WLU91aXZp0/BrcvReeVD0y
uszyddpa+/vxCTPeR0Tci/99zswlYl7o1ObmglAn1Yx7xf5rrYdXRJUEmPU0P/p94DHzBz1LxVY6
rT2Ov+xlUxb4nfWb92uOF3qbSt6vSZ00vTZZdX1fo3UPZ3qXyLZO/7Tg6avPzJazQefipJs+vNY2
1heeW7nj8v43O5431bXEGH30fNV0uY///sbF/can6Z7dxk9ROuXjJXLoWbxtt9dhi4GDe/X8IXua
4PCrWV8HKI0M5R/CDhHmGzVvBBgPHZte+22Y+mcuvuTRSeDk5IqikxCS/8DF158C59/Fm5uu2R+3
NPUPHq3bdG6gd+ShDxt19to47NMKi2iqeObteC3IfrZlw6zUu8bhE/f+GNJcwnr3Iv9g1Yl1lzaL
c9LG9E571LDrxaQ9Z59v+Ky1SnlYLyu78z7XYhj9gp1ZqVnBUTduvbrduKziROmdklDKde7bQ0u5
MUYjB5y9dqgg3m58gzmzI2Z4hkGKrLTY8/klxnyQsFDKSfgx/mqlq03+SbUnRkJecUHbkszssXef
es9YsHS02og+YbrJiQ5LL1YMtu4VPzKg6rbdRI3wbe936lVnPjdfpP3utMaVSWpvygvyXI7PG1t7
JpH9lLW10nHXu7nDJ/pOHDppbvZWY5uBZySL/e5mPCqxmD6qPd6Uk5bgEbOuR+j/issvDTZPfgO0
G4muqQiF6NllcOzZWUGHYlSMlIhIIp9IJvwI368vzf50XddFgJo7SNP+x+LwfZrTVyRxSLVpOQHV
L/KiDvTjsfrKdg+JnGTwTDhr18oY5dvTGjz0mz9uWntyV/0QE30JVzxhFF3bK/BZ5o6s4l67A3+a
+Lpa/SDne5fDv094nJMQsGz2xTPnbk0/dK+xz9nipyc3O1yavOd0ylGXZl2TxoLbHjXb9fOWmky5
umOHVtS0N4t/FAXXWFosTvxe3eOEtmjMwH3n6yrcw7YmD70tePxYaPhgast1Ydl7bZNpqaUpbGZ+
Sw3lZzcucMpeGXVN9D749nVaOmc7K1vlzJKblknFA1/1WKxp4kYZTN7EPjbfYfdDn+ORXgfWT739
KM21+k2v+YvPbC2MGuJ+Odd/m2mrfTmzGoLUCookBWWT/8Grsq+uFb/c415edkGg03m+LUl7Ds3C
zyhQL5CfTB5tr6J4Wx2s+ZJStlcTKJZ2E5h+qcjYQx8rXdRUzu+de/DXA0WFd6Ke6WfnlXkI4hSq
qNiHCoKX80uN/vPnmyssSs3+C0+6+d8ENaacJHTzdM4V2XifOWEuHS3YWVXVbN2/rXufC5XeOx7Y
RrqteTv+lhvdf8SIBEt9/Vm93pYnL2lzqNhurb+s9khCwxbfg88+fZjHuNyKcalYp3a5u8flDN0U
6eTXGXveOHv1beMISkoWu3t9iP/5qX+i/6n40Pr0GbNWrF/es2lqqFbvj2Z9romLCh9PXzXssu5j
swU+Cyf0M8saLya8Qs9XLRrab9Tv22InaYzKe5DbsnBhIRUeT+3WsW0mHxYt1mH78LYzNk41u+M+
WExccK1tJ/FpLGu9SHdP6QSrXe5Ro+cbOac9jbmsP7e5cuW8D2HVqd4WWcETikz6V6WEFKQePhVx
/Y3+9ojRg94eWLSinDIWlFP6X84M276cUoEs7v94x/x2HvrqsoIj75jLEwS6iv1P+cuzHxJ0dpaw
7NVhgnWzFzii6VTo4Bz3p+63WisiX/zTuH5LaobfWa+daei4enTeN5EKdZEx1jNPM2YuA1ZEbV9b
8avB+5TmI7onPU0P2/D/uDLdZOmWCR/Ol1snzMm/pFxTHdc615D+fOO3yS5Kk/oVON6qWHQ/1ngt
19rHdCLn12Mtg+Zt2U2VW+atTZg7r3/l2hJLzXHNsqLSvhcZ6pcR5j/l+akEJ1hYutqPvHXl5jGZ
V/RSzyc2OoY/+/bdseH55iPmhybvSI6r1tzhUxU+QOfo61vWL5TDDj6Pmaed+VNPFZfj/DQR++1C
U8PG4UeaNlwwPpFu/u7nY8uIQzvm3xfKni/ZlNH7Ji+2xLLbs9bj8RuEi7qFzQxrZKbeVOcsOGpp
crublsqNmNWzfp06556yxbFe9IvyotkZdb10gsH9/wFpnva+DQplbmRzdHJlYW0NCmVuZG9iag0K
OTM4IDAgb2JqDQpbIDBbIDEwMDBdICAzWyAzNTJdICA2WyA4MThdICA5WyA3MjddICAxMVsgNDU0
IDQ1NCA2MzZdICAxNVsgMzY0IDQ1NCAzNjQgNDU0IDYzNiA2MzYgNjM2IDYzNl0gIDI0WyA2MzYg
NjM2IDYzNiA2MzYgNjM2IDQ1NCA0NTQgODE4IDgxOCA4MTggNTQ1IDEwMDAgNjg0IDY4NiA2OTgg
NzcxIDYzMiA1NzUgNzc1IDc1MSA0MjEgNDU1XSAgNDdbIDU1NyA4NDMgNzQ4IDc4NyA2MDMgNzg3
IDY5NSA2ODQgNjE2IDczMiA2ODQgOTg5IDY4NSA2MTVdICA2NlsgNjM2XSAgNjhbIDYwMSA2MjMg
NTIxIDYyMyA1OTYgMzUyIDYyMyA2MzMgMjc0IDM0NCA1OTIgMjc0IDk3MyA2MzMgNjA3IDYyMyA2
MjMgNDI3IDUyMSAzOTQgNjMzIDU5MiA4MTggNTkyIDU5MiA1MjVdICAxMzVbIDU0NV0gIDE3N1sg
NjM2XSAgMTgxWyAyNjkgMjY5XSBdIA0KZW5kb2JqDQo5MzkgMCBvYmoNClsgMzUyIDAgMCA4MTgg
MCAwIDcyNyAwIDQ1NCA0NTQgNjM2IDAgMzY0IDQ1NCAzNjQgNDU0IDYzNiA2MzYgNjM2IDYzNiAw
IDYzNiA2MzYgNjM2IDYzNiA2MzYgNDU0IDQ1NCA4MTggODE4IDgxOCA1NDUgMTAwMCA2ODQgNjg2
IDY5OCA3NzEgNjMyIDU3NSA3NzUgNzUxIDQyMSA0NTUgMCA1NTcgODQzIDc0OCA3ODcgNjAzIDc4
NyA2OTUgNjg0IDYxNiA3MzIgNjg0IDk4OSA2ODUgNjE1IDAgMCAwIDAgMCA2MzYgMCA2MDEgNjIz
IDUyMSA2MjMgNTk2IDM1MiA2MjMgNjMzIDI3NCAzNDQgNTkyIDI3NCA5NzMgNjMzIDYwNyA2MjMg
NjIzIDQyNyA1MjEgMzk0IDYzMyA1OTIgODE4IDU5MiA1OTIgNTI1XSANCmVuZG9iag0KOTQwIDAg
b2JqDQpbIDM1MiAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg
MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw
IDAgMCA5OTAgMCAwIDAgMCAwIDAgMCAwIDAgNjAxIDAgMCAwIDU5NiAwIDAgNjMzIDAgMCAwIDAg
MCAwIDAgMCAwIDQyN10gDQplbmRvYmoNCjk0MSAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2Rl
L0xlbmd0aCAxMTk5OS9MZW5ndGgxIDUyMTcyPj4NCnN0cmVhbQ0KeJzsfQl8E9X2/5mZ7GnSNEnX
tM2EtKWlpUlb6EaB0g2wLKULtECloQm00CW2KYuylAoUyyaLgLhQ4amoKEFQQLbiCogKuD1REJ6I
oFYRFZUtvzOTNA2ID/r+j/f+7/OZ73S+c+65955777nLzE3SBAgA8EXiQV5WweCBZ64tOQ1gzwPQ
zBiYlZ0DEdQugM1mTBU6MG94gTBJnobhuRhOHlhQlHEm7FwEhndjeOWQwoJBo2KMfweQFAJQrw0v
MMTX5T/gACBQB2Ujs4YW236aUQ0gVwDwT5VXm6ymkU9IAZrTMU1d+RQb3TdniApgGaYnzk6wTqxe
++rI+QALtmH67yaa6q3gD2IsD+2DYmLV9AlprR8cBVjRBiBsrDBXT6PCNzwOoLoAUJ9XYTGZjxtH
nEdbYzF9YgUqFDrRmxheieGwimrbtNQwfgsAmQwgCqqqLTc1p8/bA/AY1kdYU22aZhX0F2DbiR2Y
nq4xVVuEsn5PAqy3A3g1WWvrbY4MmIb16cXEW+ss1qCfHqoEWNKK7U8Exrd8vrb7mfLqcd5pv4JG
BAxe3L27hrm+FZtdfrXs2gqpXVQBJLaLBCcwn0h6PR/LiMD4c1I7yIACT4xi0lCvQqIrDwkKGABF
KOj43zk1PB/iYeCDiL+WnwAxRDh7HUK1wjTyWRGQUgGP4vOkJO8pEDjSgR7DeJTJOLSAptE6Da2C
0OslcEgkJV5CxTomjlfKP8q0FAgR2zgs5ojzpCJgE7WJiIP/EQj2Qs6dpBN+T+jvJB3vfejulq9C
Ee9NKO4I8xWQfCc2qEl3lo4DBw4cOHD4/xPUqwQRHGwk7jxHmFvycUuYnU8AdFrp8W+pHAcOHP4a
BBAMwAt+FzlABCLHddybSJAlLEtBiuwFXsgykDmugRzkyN7gjaxg2Qd8kJWgdFwFFaiQ1eCL7Muy
H/gh+4O/4woEQAByIAQhB4EGWcNyMAQ7LkMIhCCHQiiyFmhkmmUd6Bx/QDfohqwHPXIYhCOHQwRy
BPLv+DzeHTkSIpGjIAq5B0QjRyP/BjEQg9wTeiLHQiyyAYzIRohzXII4luMhHjkBEpB7QS/k3pDo
+BV3XQwnQRJyMiQjp0AKcir0cfwCfSANOQ36IvdluR/0Q+4P/R0/QzoMQB7AcgZkIGdCJnIWZDku
QjbkIOfAQOSBLA+CQciDYbDjJ7gH7kHOhSHIQ2Ao8lCWh8EwxwUYDsOR82AE8gjIR85H/hEKoAC5
EAqRi6AIeSSMQh4FxY4fcJfCcAmUII+G0chjYCzyWCh1fA+lLN8L9yKPg3HIZVCGbILxju9gPMvl
UI5sBjOyBSzIE2Ci41uYCBXIFSxXQiXyJJiEPBkmO85DFVQjV7NcAzXItVCLbAWr4xzcB3XIdSzX
Qz2yDWzIDdDg+AamwBTkqTANeRrL02E68v1wv+MsPAAPIM+AmcgzWZ4Fs5Bnw2zH19AIjchzoAm5
CR5EfpDluTDXcQbmwTzk+TAfuRkWIC9g+SF4yPEVtEAL8kJYiLwIFiMvhiXIS5D/AUthKfLD8DDy
MliGvBxWIK9APg0rYSXyI/AI8ipYhbwa1iCvgUcdp+BRltfCY8iPsfw4PI78BDzp+BKeZHkdtCK3
svwUPIW8HjY4TsIG+Bvy31h+Gp5BfoblZ+FZxwnYCM8hP8fy8/AC8gssb4JNji/gRXgJ+SXYjLwZ
7Mh2lrfAFsfn8DK8jLwVtiFvg1eQX4FXkV9FPg7bYTvyDtiJvBNeQ34NdiHvQv4MdsNu5D2wB3kv
7EPeB23IbbDf8XfYz/Lr8DryG/Am8pvwFvJbyJ/C2/A28jvwDvIBOIB8EA4hH4J3HZ/Au3AY+TDL
78F7yO/DB8gfwBHHx3CE5aNwFPkYHEP+ED5E/gg+duDJ8ifwKfKnLP8d/o78GRx3fAjH4XPkz+EL
5C9YPgEnkE/CSccx+BJOIZ9i+TT8A/kfLH8FXzmOwhn4GvlrOIt8Fr5B/oblc3DOcQTOw3nkb+E7
5O9Y/h6+R26HdscH8AP8gPwjXEC+AD8h/wQXkS8ivw8/w8/Iv8AvyL/CJeRL8Bvyb8jvwe/wO/If
8AfyZbiCfAWuOg7DVbiGfA2uI19n2QEOZMB1FKgdYrEYKIrHu/Pbgsgtid0SH0DAnG5FF+xx4MCh
q5BIJMDj8fh3nqNz3krcEk5YgYCbtxw4/IcglUpx3vK7MG8777JStyTEPyF7caEL9jhw4NBVeHl5
MfNWcPuUHei8y3q5Jde87bwVc/OWA4e7CJlMBnx+V+Zt5122c97ihBWJPOdtF+xx4MChq5DL5Thv
BV2YZ52zVe6WcMKKRZ6P0Ny85cDhLsLb25uZt8Lbp+yArDOvW8IJKxZz85YDh/8QFAoFCATC/8d5
K2FemL7pBWYOHDjcLfj4+DDzVnT7lB3ofDru/IQdTlip5KYXmDlw4HC3oFQquzhvO++ySrckZd5Q
8py3XbDHgQOHrkKlUoFQKBTfPmUHFJ153RJOWC/pTS8wc+DA4W5BrVbjvBV1Yd52Ph2r3ZIX80aw
59a3C/Y4cODQVfj6+jLzVnL7lB3ofDr2dUsy5o1gbt5y4PAfgp+fH4hE4i7M286nYz+3hBNWLvN8
yYqbtxw43EX4+/sz81Z6+5Qd6Jy3/m5JznyA46Y3hjhw4HC3EBAQ0MV527mrDXBLzJzl5i0HDv8p
aDQakEikXrdP2YHOu6zGLSkAfBSeL1l1wR4HDhy6ipCQEGbeym6fsgOdd9kQt4QTVunj+ZIVN285
cLiLoGkapFKZ9+1TdqDzLku7JdzzqlWej9By4MCBw12DTqcDL6+uzNvgzrxuCSesr9rzjSFu3nLg
cBcRHh4OMpm3z+1TdkDbmdct+eG2189z66v4d9SNAwcOt0aPHj3A29tHdfuUHej8evzOr+cNBAgK
9HyEVgIHDhzuGmJjY0GhUPrePmUH3D9XAbFuCZ+dQzSeL1SpgQMHDncN8fHxoFSq/W+fsgOdd9l4
txSKj8+hni9UdWEd4MCBQ1eRmJgIKpVv4J3n6LzL9nZLNEA35nQrurAOcODAoatITU0Ftdpfc/uU
Hej8SbsUt4R73jC95wtVXVgHOHDg0FVkZmZCQECQ9vYpO9D5U4oZbikSH58jPR+hQ4ADBw53Dbm5
uRAUFNrt9ik70N8t3eOWegIYmNOtoP8ddePAgcOtUVBQACEhuog7z9H5c8r5bikeoFec54b3jn5L
mQMHDv8axo4dCzQd1oVfSh3mlsa4pSTc7OKZ6lZ0Bw4cONw1mM1m0Ou7x94+ZQcK3VK5W0oD6Jfm
+Qgd/W+pHAcOHP4KpOsXytVAMRIRhKeg82fLCZJk0twIjKS68iN+RrfUeU/OAhg4CHfYbkVRFyt+
p6D+tWw8KAbmk18KNEBCNxgKo8AEFqiAOmh1OIDZxTt15g6d46sbjnK45S/Ip6cVpqYkJyX27pUQ
H2c0xPaMie4RFdk9IjxM301Ha0NDgjVBgQH+fr5qldJH4S2XeUklYpFQwOdRJAExhD0gs3hLoDBa
o9PpSnq6wkE3hu1UuOKizg7KGxJpbsoUfFM45KZwqDs8zA5qe44+M4sxvAVyztpBZSfUdmBKIVRD
sSRXpmzzJH12pT0w01xWhjmy9ArannPB4KoKa3uLVJKpz7RIesbAFokURSlKmNa6hcjpR7ACmZOd
uoUEkaxnjF0ZbSfDs5lzkj19YRkK+iy0hDGqzpgdjrZFnlGA2ToklVMi7IJMu5Atl660p5vssJDe
EtPWsmiHAsaXRXuZ9WbTWPScCeu4Bajw7IpCxo/ZzFlWQdt5aJwlDWro7Aq6Rc+4I7uiDFmfhblu
qUe1OLO4WdemsSvxmm33ibYPxBQD7z+joVqyAyppJtjS0kzbW0cUe8bqGC4pKQnACrdk69EgGsue
lIFNCTD0jHG2yeUAc9kkpsxJJqae2ZPoloUWtq6L2DqwSbMrsGNMt0vV0pJt1mebTeYMp/VMe3oh
e4HC0cVsA9F1WSUulSsBxvDYmLKsEp3T2bn5xZlMxfSmLI2z292aMpcGFdkdkTRTg8FowE6X03bI
L9Zj0mSGLMnQUp7MDh5dCYG58jpz2fnhCj3d8ivYiTJ9+/c3akwujSBc8SswYo4+p6ylJUdP57SU
tZh2OBrH62mFvmVLbm6LNbsMS80rxlw7HK8t1NhzFpXYFWUVRCr6nhkBOfnF/TU6n5KOYF5HEHBI
4cCSss1BL+DfYNcFvQyFxToaHVVUXKJBPxUzciHKziszkHDgJmMfu9zG+MiS7HZPpkvU6ZjRuXBH
OozHgL1xRLEzTMN4zcuQbojG/ihjYto6YnyLmJjGjhh39jI9lrKNXZh87aII95+3wk+VXZFqJ/z+
SbTFGW9XZRZTGrLEKZEaipEk0TjT0+z+0ShHRrdgJxzR2xXRdn5xmyathFb44ArA9F6BPnfE6GI6
u8U9CpwaV0uZcYBDXW+qaHFNJWbQ4/AgsIPSMwfpDZCGZmhGkWNP12cY2BjzKbBTpzACF42MLXpi
wYgt6cSCgtHFOxW4Ti8oLH6ZJMjMsoySLWEYV7yTxmWY1ZJuLROimRDkMkP1ZVLERml2pgM0srE8
VsGGy3cQwOpEHToCyneQTp2C1SF6Qrq48Nw3gdqz3wRpsaPTH3zHPzDxH99FaL//LkZLf5b+GTn8
8LjD5LuHlNraQ8S6Q5sPkQeXi7T7t4VpH1+bpH1sbbz2UTzXLovXrlll1K5eNUj7CJ6rlvfUrkTd
imWx2mXLc7Ta5Ybl5PJltHb4snHLyHXLiPRTp06RipP0SRJOKk4aT6afzDtpPSlI3y2WJjL1yNvl
pUhUvEak7xArEmG7Yju9nSp7xfoK+dXXeu2Zr2kttBvby9qpvI+J9I/yPrJ+RF2c46u9sC1e+yOe
67YRnx+P0R7/XKf94kSs9sReJdO4rR/KFaxxx4cSReKxvSLtUYzwPqI9YjhCfbA3UNuG576Zudo9
e7XavbNTtEsW5WoXL8zVLloYqW1ZmKl9CM+Fswdqn5gXpF0wL1bbPK+Hdv48s3buvDztg3imz0vr
mzgPM7Y2KbVNjbnaObNztemNA7ISG2dHamdiYPasbK11FpE+a0BmYpS5jznXXGIuM9vMAoW3Tuvn
20MrFOi0gQE9tDxKp1Upe2hjenr3iJZHRnlHdJeHhXt308tpnXeoVq4JDpEFBAbJfP38ZUqVWuat
8PHyksm9xBKpl0Ao8sKHHy98MvJSeDd6k+mCRgGZTjVSpDduXYZDesRs4HmDAQO1MBv2wQfgAJGm
j0jrnSrSUikiLSSLtHkJhF2ZC7mFGXYVgdeCDHtCdO4OEeTb46Nz7eK8McVbCGJJCWrt5AIcboV2
3gIcYYV4Fxk9pngHEchEz2NvKijtIBrnLV6scUslJdEhdnNuQbHdGlJij2eEh0NKIBpRb6uvr4/+
C2wRM6Wb8zO2nOcxtxyT/bw+a8u359nbj/1bfRZhN+PEzKq3z8qusM/SZ0X/panozihGYAvF08bW
AOpt0Q03JrZFd1QLQKBmvsOFf5T5txon3/BoVurUOE7fyNfNjl//tYe9P0MEXf96Y+IoGXWTZmKX
Cz4Kb8N+2Maeb8Bu2I7HS/Ak6t+BPahjTiscgI2wAbXLYBOshydgFTzDhuYSJOYC2AwP32D1IXyI
Pw31KI2EarDBHFgEK2Ad5hqIuvkQB8kwHUrweB52YFmXoBUehwUwDcdwIzTDEngUNa/Ah3CeUME1
QkkkEGlkMJlFriNCSAO5lKrH+ryMNdlMjiN1xHriGuZaiXXbBlPQwiLKDt2xTo+RdtKB9XwMhmAs
Voq51QiZH1yh8KLeLiB5wJyG9068x1KcUeej8wlHIjDV5UY+XGGu0MhsP0hsPZDHcYQwufumR5LU
PiCiiT7EUGIcUUvMJgRoX/iBQTybP1u8lM/jUxRJCg/zwXAt3tDfSBhK8ZpQ2nytLU5M6FWUPimB
PH69/fkTTYfjDvOPXjnIS7ps+BBrGUcdpdoFarYcQ7qGomWKJCFDAiFaxC3GMZLkHaMFhMBQ2p5g
aIf+CQZlSkqckYiOJii9So8n1f7q3LKNeArU1/aQmcyJt40cHO3vYwu8YHP6XDGJGyuxXBpEKii1
WCulKT0vShonTpFmUenigZJ7pON446RVvEpJrXQqzOZNFUyXzJZqxkumkzN5lBfMkZJCERCJRA5x
L7Z/JrafkIv5gkahSChLEWVECBOFOcJRwilCvlAml6UKX5HxSQklns0jeFLgUUIxhe3rr/RPMZQi
GQnF2WihovRMtAJd1Eb4JBhKm9va0FtQSpTq9OgzitATOhWh4085QERc2zDl2PVju4hiQnGQzCJU
vJ+uPkfNunyOf/TqG1RfnA6EHmfVaLa169JHdCcMVKw4EZKIVFwWc4jB1DDxKGqU2EJUiWeQ06kH
xD5SXHFb0UuEVNIkpkiKJxLOEvAFo/kz+CTFF4lxPSYFFN6GSYoSwA7Hl+nBEkWSBHdtNLPxk6fL
rXKSz6cFRkG6gMLOwRYwrYhWphgScIlmmoqdVNqswPYpmrFpbSiK2ohSZ9uoBBWBf6LR13p/HXNt
7xd9D0aSA/HM5R+9bOAdvWLAQRLD++gKzTuFo7G74zRvNG8atq43LEovAYPKEOMbbkhV9zIM9s0y
FPaY0GNKD2kweMl6h/YODZ0f10sdF9crMaVXRlxiUmJqVJRf3GtJggf90pWBSX6wpkdwQnBmMBUc
3FM1PIqIigpf3VPRS/yIyg/6txv6tzNNwWaUtuM4jm5XnPVJMWBnnYlulsdG82cq3myWp6Xx33wz
zoidJSeEcsJX7ZcQn5gkZAP6bhG9e2GpYUn9iN69IrrHokYg1GMoIR73njiu9dSktT8OG1E4fuKY
PflhmlJjwqz8ec801N9H9D8sEEXo9aXJRcezJOEpX1iOHBELNu8ihwr0Ot19hYOGjEh5XNHH11/7
2Mx521NTEgTBUX7GNKVSlqTZ7R3RtFjTV3NNgv4qcpzm98BZpQI9zEsfPThocLdJvNkiq88MjUCp
1ut1FIljZj6pUpOkKixFlRFB9iazyZFkA8knw8LDUhW4fuDzVi05m2wkHyYFJBkuEQeJyZAHxbvC
VOC/yltB0o8IXA7DCa+41M72/33OYd0cG42OkivSRGnoLBzV2OtJLt8ona7wV1FO17j9x+9xfc1u
zezHxjy50zyy6FxTyaoB1pWZcwZXbEjtnVI5pXDzPQL1H983jOp7YN9ThLZq8syICOLMtUa9zjxq
+MmK++cUxjMrV7HjLK+JNwPEuC6Wp8fzlAq5WlmgKdPM9rIqheI16f6Ev79EsEah0OlCVkv8csSF
YpuY0ulUMrF/EDVPxTxrScXeSSpVVNCDsl2Ril/asWXR7T4pKeywAGaE9G9H8b72OGMpwXYz0xCi
W1hvBeicvaxzNyvBOS6oNj6vYc6SL7oTgnPXfyfmEqF7D/morh4U8Dc9WXN+uDQqPq9fvzJyY0hk
wORp9oev9Tt+DO8F2/e8ENo0MiQ5YPFTIxPfVYZ6eytw1ibjvXo19m8grN6epMpRjVRRATscx9NH
i2VJgb5R6ijfSnmF7/3yab7WAGugmC8SzSd4aoLgeXvL1Go/lUKlUMz3Uap9fJQ8HyXxGnqHCEpR
ZkT49PbJ9hnp0+DD9wnSBKX67AzyesRfoQS+DxgS+vdv71y4ShWXmtuc3SwUYTfj5AhgZwd2djRR
SrADXeX2DaUnEii233mrxaKNu1d4yQqqhmwftX83MXF30+Rd5cs3UPcG5GuvRZMzeg/vXlhUmHp1
L67n7+XmrQBni6nz+HyihJr0oEBZojRHWiTleQmFfJFUis0TS9RisUTJ9F2UWJGkVKqtakKVIsmI
EPcWZ4tHihvEfLFKrUoV71Sh8x7x9pZ6i3FF7o/3KY9GMR3tbpQ8LQ4boneOUmxMgtA5cKm9ksjs
uHt3Fm3b69gbMW9nUVxMD2q1RFyUdvUbXunTpYP4zO8laV1HAd6l78bx258PYsItjuvMQc4gf2AO
auItjjbu4A7u4A7u4I7/xYPdiedQw9zvCzH/AumUCdxXxrtkEje4+10yhTvzzS6ZB3LY6ZL5uMc4
4JIFqD/lkoUw021HjPofXLKMGAJXXbIcepCDmHf7eMw7W3KyySXzIJSsY2U+q291yYz+YVYWoN6L
3OuSeRBMvsTKQlZ/3CUz+kOsLGL0FM8l86Ab+QMrM9+Hb6YULpkAOWVzyZiet9wlUzCeV+OS0Sav
ySXzIYDX6pIFqD/ikoVw2W1HjPrvXbKMXMMXuWQ5FAqdeSUebZd4tF2KerWrLbglhjBXW7xQrxDx
XDIPaOEvrCxHvUgU5pJ5ECBi30nlKRj7ojSXjPZFMaysYvWjXTKjv4eV1R4+VHv40JdNP80lM+kr
WNmP1a9yyYx+PisHMnZE21wy2hH9jZU1bPojLplJ38bKIR7lhniUq2Xt/OCSGTsnWTmMsSOWuGTG
zmVW7smkF0e6ZEwvDmBkkYefRR5+FnnUX+RRfy+P9F4e6b08/O/l8v9zdLzRmEwPrSyvq62vnWCj
M2vrrLV1JltlbU0sPaCqis6vnFhhq6fzLfWWuikWc+xIS53ZVGOiK+tpS6WtwlJHm+g6y8TKepul
zmKmbXUms6XaVDeZrmViPIITbl0KXVlDoxm6qKbShvkLbCabpZ421ZgNaKCWLaC8tqHGVldpqY91
W0jtqMZgm6mqspwJ1jPGesca4+lId7IoV7KezmRDTTY0OJXONNVhbUtqG+hq03S6od6CNcD2TKit
sdGmetpqqauutDG1GT+drVt20ZABGFvHBqx1teaGchtT76kVleUVHnnxWllTXtVgZhxRS5sr661V
WAA2BnNVYoJyTGWpscXSHWXX1lRNpyMro2hL9XgmU6epmo7Et6wRm9xcWTMRfV+PvilnXOlROutU
l60+bAUiK7EUm6Wa8XtdJZZqrp1aU1Vr8iwU62xy1hS97nZ/bYPN2mCjzZYpleUWJk2Fpcp6U4Mq
bDZrqsEwderU2OoO58eW11YbbNOttRPrTNaK6QamiHoDjAQL1IEZTFCDJw2Z0IDheqiEKRi+OXYy
G3s/tP+TWGfem+NyPeJqkW0YvjFNHBghEWiqldpFbaK2UjupLfAc5oxHvRH3ocynEyqhHHPUop1a
mIA2mPrWosbKsgk1lSjVQCzGDIAqPGjIR91EqMC4ejZkwStT7hRkM6a8uaaVbDoLW8cKNo5m9XUo
T2RjbayWyU2jXMd+YsIC1XitQx/QbF2ceW4dO6FLbWFqVMPaYmpDQxGGKtk6MOUXoGRiQ/VsmTWo
NbhqUOvRgnIMNWAsU6NKNnXsLeqQ+idvDGbtV7EpO2Lr3TXrjVaM2EM0RN7CWtRN1nreYG0oW29n
DaeyrWc85PRtCVtbmvXadLw2sH3m9IGzfyawNbCxbWbCVjZfNeuZDt+MZ/N2+C0bPTcER4Uzb51H
jJWttRlLKWctOv09lS2rHPnW5TrDTNpybFED28vOEVGLbGbjrRjjbIGzZ5xlVboslLtsWVhmxuzN
7Wbiq1gpEnNFseOyGtvVUdKtalXzJ8t37qNO62bW0kTXuK93jZty96i8dds7R+qN9erj4QGmJc62
2NjyOsY7Y9/ZVjNqprItr2Vnz61b6vSz6QafWlzj/ubRz3jVhuka2JxMbaewrbG47TApqzDFP++h
CtZzVpwJBjymskcs69EbR34sm7Ma09iwRUwLJ7JttKKF6ajtaEU9/HkF7pwj92F9LX+KzyJGYKzt
Fit3rccK+9frugVL/6vVeTq258/rOlOj065Z+yfLvCBeJi+dN4CXzIv/C7t/cb8gjO6WTv5Tzjyo
JUxsP9XcojXZmPN+V4j9QJzjZzyHwLS/eA+SAubJXQGEw+H8VCD7Dd9+4Pq0IPUKMs9j78L84kYv
vBsRVSZbDebFZ98hhYNo8MsfPpRmvpaJ/bzcDezOl4z3mFvnC/XIQbivBJBVteVVIGdZzdohXNZI
di/kDClc1wjmeRJ41ENUC7WQWoQhEv6AyxilJWg2JAKCWsxasbmsuexpmHdvXd8hpRlnbNKMEYh7
zB80/zcZISRbmzRDUDWIJIg4qVEs4EfLKTKID0aTQBItIHhEUxJJ8FoLjCOMMR6a4PWhjcGQxh7D
cfFgpkAVdhczafoxh1HnYYyn3ifRnnl9xm/J3sceDbpwJcEuMYV819rk18PYxFMam8jLrRRJkKQ3
bhgXpqUt8Dna71L591+mG2XumjI7OKM1LtoYJaCKeFJVt8xa6/Q65rmYjiyPouNSUpJueraNjQs1
BjsT+97yqTdOZ9Qy8ZQqoDM+v7bWRg9osFXU1lXaphtD/WUpSca4OKMxyYgY7S+LN8bFJ8S5gv+F
GjUR3TzdQvCBaiK8AfUSsokg4Dlyz37r2T4Xh2ki162edq/x2/XPLQ4f9/v1R4Zs2H79ifV0vxkj
1j+2fmlZ/OSjGebpP2yacrDw+MXvHp8fvHTd3Alb35p8/3j9JyFpJ72J5edWvbmv54S1aysiHj2S
GrPP65XiiP0530j6Ja+KeS4yZeP3gx/M+Gqu9661VUWmTU0znirrOXXI+Ue3mfuszQuOE4Wp1z33
zbLogLN915Sry4r5lnUhSfnNvz3740rybc2H+4qytz7UuC/1+8KVw1669uz91bZhmwMOrxJH6mDU
w2WVSbtylcK0kY4xV/42QSJ65tickaN+fLXPvX5zpvKOX9r7UuMj1+3vzf7k2aC6sWmHdl8Qbehm
3CqYd3ArPVU170uSwoG/Yc5G45ynjXPWozdDCN6ctcY5qxsVY45Yf6yse1I/Ypb65aFLHO8+Vfef
77+m24xxiunDR85J2xb/vDqgd/sOIuzvU31+HlsWv+5J6bv9+MsWLD2YelZ38cKoFTGvtA48MP7H
q58e7tNn9HOJhZXXw6r7Hzz8/En+jBNxi/uuU1gn7bquHB5Q2Xb1SOZXPqPp4d+Of2Dz84EHopPC
e+61PKVsCfcu3/BbYfAfuoOf+P6cv6kmM154rcn/968nVslGXNrzU/47e75503iVjhMvCHkkKmjo
xyHk0z81nqK2jflly4kDo36wDH4nv/DVbVSk0vHwJxdES2ftWP3WC0kxZ+4/s3HqV1Na4cik/vuP
JbacGqDc2HuSZtLnvU9/FMw7szGbd2B0QnLN0GDZ+O2S9Ys+/Liwf857wUXPWD9XpjavaFj37LFW
XBXKjE3UEOeqIIl9weeLPMfYJ95t61hTQv5biwHO++R4BK4A8bgYxMVjsHfHYjCdXUHRiEBFFhXE
qYw+TECkkowy1VfgPtGGxSiMckYpVAnzLebq2hpzR8Ukf1UxvVHnrFiQZ7zZQhdUTqxhdp95mQNu
uypsnz7zk9Kt2Skbe22KO/5HeO/BU9uuaJ98J/u+H4/mnPto0RuTh+SP/+VR8o2hfx9cZQjrZ9n3
vn67dND22Q0nsvc8v1Se91Z49MXWb2R67dEBYZfHP/pBYPbTK+7RPvreVkO3N+7pOaP2M9/QPotS
FCkn9kT9MqFPTyLecb37oGdeqSKaH7/y2svls5v+GNs6Z+68JfaLO1Zu+CD5mbx5/t2bh50wXoK+
v7z9R985e+e3V6U8G9vr0rbYzZKZ45dNm/D4mnrZ/M0X3/yZ3jlcubj83ZjP4rMDf9h1z6o+eQUB
708YMf35F5sPjOy3rilvQQ1/S+/9D4TtyZ/Q99Fhh6NnJdTMHSg4+uSRe+aTNfPhb23NXxa4VoXL
xjm/GVXMohDO8zJKBCK8ofH5Qor631gqvJk6qgjCweMbKbwYQxiFnOfHUx8OeX8KWMds/un4m8PW
jsiK3ZBVfsEoZaK9ecwn7ud7TB12jXnghZdm3RNx8f3dw2zri7vbejRsnX/thSErp8HQ84e+C/ii
8i35+hk/k5lvH2o+/HvB4dfX7RlZe6E867ks+GHVgbUfB++QrguUrfz0eOiLUTN/bH+mftPSkylL
+q6ZtDu5+tiCzfprX57/pFK8bMGe66dhV6+ff5vxh0IZy/8uatWKjMmR921PXnpKKDtYWvHensYB
kyds3LV915Jehy5Sihn3/3rsVMaXD1w/fXrT9Utffizbav1k+VfDX01eP6PnR30/7yUdn0SumzNJ
/9ClseVL7aN3pXxatqhoblDCr33WtDZ5rR+3cGvM9qeefveF4/Sr+4yB82i1rMfu/F8GnLrX+NXy
yMrm/dZ//PzsC+83ZtRNkeMaMwnXmHzXGmPynjbU+dDoOY/4uM78F2d1x4KTYDTiipOAC44xxRjP
BBOYoNF2V6rmiqf+Iv62a836zyWLP3h9/+DH3ns+tdeL+pLJn1ft1XXbvvLAty/te/vjiNfjfRbu
Pl4acyVxZKhv9EtLZSfUG2oih8z26z9g0+L0LTkLZJ/NWfniasGRUVlTxn7701X5/1Vv5vFQbn8c
N4xlbNmyG8aWasoMI8YyiLFnMJKK7IrsJmSfGaNkTZI0hBZ1M5Fki2u9tixNN9lKlutmCVmSpfgN
VzeV+7u/1+u39Pr9+T3Pc87zPOd8v+9zvp/znKEI3A3FJ7iR6WGH7HCGEvRaJ4qns6DlBMfTkNkS
Xo6P9u5ypDNxJZQK0qhAUdLP7/mLHW0nuV+rTkGOx+ZH+tehhy/HBNpfe0MJrFGOV+ST5+1zbL4v
fBeTdpLyXAIJ8x2IP6k31CA6z2GG05YfZZR2h5w2LEiuL0Q2HrzlaSNodC+xK4GICmLV775ZGCVV
NzQb4vrACFcpq21MduCzN4U1EeaesvmETh0+FPiM5XAAfpM1izD8+42+F9uxHrG0IGSq3hKwcxCt
hFDzRUvjtBGBLncignG/7Oj2aFrnhJgUUBDGH7l9mOuu3yAO1ICpwZBZyllK0YqbUqCTn8c3UqDP
abf1UvlNAdVfXgdLc7T9tCKYwedH0tYh6jBVmMpnG0YfDf1LbXGjQRe/LS3hvgmgDdpoHfHGnsyU
ICIAnL8LGKtTJrrxEVMcZ3GBmCv6gnN0O93C+xyTcj6dzCb/Jrd7+XDX1VWzqhOgh2W3JwlzaWDv
o8vvZwbZf41lQfELSFCrH6H1WWTtj4CMU96xtJYf8no3ZMAjpxQL8XttV5zvxiOdMjWGAPWFe3kn
s1q07DEx/EkBGj2a3WorW1GhPnC8kMhWriSKiULrrz1OyT7KfDf1VVDlkYhbuaatsxRyuvbQExtp
1MsIhL7pQkdTSMZEcTPZiQ+bT0mf7qrqyMq+d7kleO85aHVjz0cPht4qFcoM1UZIYEf1h5bI21ws
wq+SpN4UZJugxgu4ZYM4a6BlN083JqrTaJNBow3pM20MQyf/2AD7cbSxdPN08cc5ePpspc0BGBJ+
AAZXUlLYWN7AN0wF2LoJw9/+r7zbLpjMHxMl2EvHzWdd7NbFoiXQWFNVOExXZZ+SCkJ5n85BPZXP
NzLwgv/iI7Aufuvy+N8Caryc0amp5+z9KF3UrYf1kyaZ0q+RAWDQCwUj66Bne3tuMSdNv9FYqZQN
vbEyEhau0NGjEYtUnl3sVkPwP08mrCDeniL5CScOlJoMlJLmFFnpa3IC/JVMbGdKBo3CxEpTgvrW
wKSdB/V82yN2HeGhEjFqHcv9C7GTmnTDnf0OSwLxxjfx6u/dtMYHY6qYMeW4kDH2Ef3xex4znSfx
LIv8LWG8j/2HQCbLjiuTWch01dUJ7iYHsKN1N6slsVPN2HjocKW8vXBCMqNOr+0EgVXqCiiLEe4S
e8kUrA3JSU76hNZFeys9QCtT3O66LCF0HgjUqiEHueJmhc8NW5qJq2XAKVsB9QVI4X7v9mta7R6Q
+XCqFPDReDC8Yxj1FXu8R001r5Qh7hlHJ1aQx/PUtHUanv5b7MH5+zg5/EfY87kl3HYEZfmOwtsA
yi2YAGLnp/Z36MXsr6IigvERu+S098z9CknmvEKxw57YvTRZY2l0J+wD71M2vqVDs9E76byGiWJy
6FwoUuGVd7rysSkpi0RLhnjNXLKzysKBJj6dYlVUWjNHnS9ebs41Fz5kY5u4ZGExaDNxKSnDDWQS
Q6UGmCA43AdDdXP3HidaRqClhWTqL+j9IjMsFOm2m29BoOGdJBSvd2Lv/NLthkCUlPfSbWdSQo4j
x9194DsjSaiItYKEj1feznwC5rcZth/D5S3P8YqLINtvFL2omC+aaqLMWoFX1GeaXuzRragia4a5
CrYVSjixtmhpuCgIhRaWatTIGphKCl31ioPVzFz8GlBc7mxXMdV0Mve4+9Di1sEnc77F1I9Jvjbp
BEMglNfphKSZPyD5+g6cf8ebl8peK/lNB418BZvaDVDY6uV7fOVQhcc8GIsm4iRKsccQnixXfNF5
QNwsqrzWmBrBuDh95ufYxjud9918XIN2uY4Wl0yTytqmfvrEc5PtqORu+Q6tHiugSMAjT2dPI8u+
VzP9VdeJjZGvI0zolVPeV2eyWIFP6bf1VAfYyIcVywCLrI67izqtRYaqT3UCZQ4hA3HMtrU23dHK
0DPNnONgJCg0YDXDwyt44C0q8UqmL6fdHoygo71C5jOi6V5Jm1Po2H75KC6zwqVHwvEeUzLXeBef
cHWROOcJAf4HGi4H57TaM71lLIhWLFlMOR6lHWVNSvEqEIcatHqTdQbcRyNkE07/wRsCQI7WI9Lb
R+j/RfrFxQTaFEB3AjZOMW+h57ZwFPqzAh89kB3MSoelO0PnSKdDp/11avZdXrcNoFIOccNrQ80e
cydkOzADOON80PHT/paVmiDGfWul5liS6CTyYskNK7b+uGI1EepKXm5zyQNziIg3i1v4aYYcSb1J
jyLPUMlSvV+j5uJ3/Mx84UDNRPiYjy36evKz1vZXCdWDVXvaQt8231foPFf2xKn+AFUQUhXQr5b+
UMQ/E3K+u6iIxzJunlzrYpQuJ0u2v7BDrZHXJcjgcQeFqIopcLTuh42NIcWGY2Z7kfglXkicc6QT
EzB1Np1eRz5E73z5Gn2Py5JRfy8D7tJDRi/21oyXcg6hBjMCZG6ICr3ouTymX1IVSke0GrAalXdj
+kddlePnJVPJrQWBluaqL/x0C6UW4ATgDRqkrtMDADD8uR+YlX2VK37RuLPw7TC+P8dbDgBnZmDc
OLS/7gWbgwligLNvldVpb/PFYoNzwrZe3QmT+lIRCKf52EIJZmcpcHmafOP34CCimVQHzjwSZr2l
CjvcCGaQta7M/5MN3WzZSOl/4VcBiW+QBiQA6DLLlvtkyPpzcfWefg/q0YdrjzWIQM1V6Z5XB3S1
WRmSZJRPHz1jyLsU5aHhdov1vGLyKYPphXymzv2aMmNKZ2u5OisB/uHVT4VaJkpq+BymTOmPcVwY
m9cST8u/XpdRVFXFFQbPaqlP521n840Nql090sXKihWQpnpYTRkkHkGp72o00sBin0Mj1IINMbud
cyQCh6+N6EOApPiusFfSa5msbakHVXxn7C/Ig5o+WYtj0dhOltWQ5TVB7VF8yOXZshVuzuTGTEZb
AIVgP+LiIgZNIZsnVpiCLISlLg5LZ7pMp/kS3X4zmSpsNLd8s5SxavdsjR1Qh39LhdjBh/h4DYqy
CfTiMAK9yJdxYYIT6NlpRSz/c7f8dhb6Kqlg3nTLLFuY4FbvY/uy8wOgPfPPK4zwHbTpVQUOU1yf
TJEKSse+c76AEz15ZxmDKsCr1uBLTqZ5omT5gm84te4iTDJ93lqKGIIUSkLx2nC63lUGDP7J2tlb
551z26hsupdEX6ri69QCS7NuZqQVNDMM/Q5ywAzXtZY6mIsJ3IU+11K5ELqPvIKAHk9IeU3U7XrC
bwwMHjBSss4sVbofO2b3iVoblxSclhj/wgNNcphAcz/q7pXINrTb507p5YMzkWtYHzSkNonrOEBZ
vahNhxYspCILmsGPTzWnoNbC+3MLGSUd++8n9Nq+Cb1KJxKDA5j47IjBDULwAaZrkYiqYzx5SukH
PT4w77UhVEbHj6cBW+sVu/q9HlKFS8h3TEYmAKzh4b6HuUeUplILnkqZlmSSOrJnOLRue96cxr9/
3elqJ0L3Dw8XazsNCmVuZHN0cmVhbQ0KZW5kb2JqDQo5NDIgMCBvYmoNCjw8L0ZpbHRlci9GbGF0
ZURlY29kZS9MZW5ndGggMjI1Pj4NCnN0cmVhbQ0KeJxdkMFqwzAMhu9+Ch27Q3G6Uw8hsLUb5LB1
NNsDOLaSGRbZKM4hbz/ZDR1MYIP8/5/4LX1qzy35BPqDg+0wweDJMc5hYYvQ4+hJHSpw3qatK7ed
TFRa4G6dE04tDUHVNeiriHPiFXZPLvT4oPSFHbKnEXZfp076bonxByekBJVqGnA4yKA3E9/NhKAL
tm+d6D6te2H+HJ9rRHgs/eEWxgaHczQW2dCIqq6kGqhfpRqF5P7pG9UP9ttwdj+/ZHd1Phb39p65
/L17KLswS56ygxIkR/CE9zXFEDOVzy8cpG9rDQplbmRzdHJlYW0NCmVuZG9iag0KOTQzIDAgb2Jq
DQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDEzMTUzL0xlbmd0aDEgMjgyODg+Pg0Kc3Ry
ZWFtDQp4nNx8CXyTRfr/M++bq/d9QDjeNLQUeiRt6QUFCj04yl2OFlGaJm+b2DSJSdpSDxYQAQuu
7Iq6sKvgjSgawAPwRlHU9Vp1F0TFA491xcVdkfWg+T0z75s2pRQDH3/7/33+8zLfmXfmmWeea+ad
N00AAgDxCAoQKmunTZn4zl/iAWozAbR1M+bXTlXw3KcAykqk+nx2rSE/7/XjZgCyHe8XLqycWdf6
attCAFU20nxkbjW5GrL+WQ2g8yLNYnO7V3jIcP/9AKNXY//YJldz6wvfjfMBpL2JEy5tNnlcGj2E
43yJyC+x2d7Z9OqMK+IADM8izxesltZlj3ZfvRggMhIgyWoVTZYj5KUvkTfOB0W0IT4h3I73Frwf
YW31Lpu4S/EMAIe3fKXdaTYZp+Q+j6Q4P3mx1bTMxesVp7C+DgkEh6lVXFC/9HWAkhkAg+9zOT1e
/zhAXvO+o/0ut+ia/dLIpQAjjchvPlBbKVG68I9sS2PKTmm0GqDpnp03ddPyucl/twJ0zwk/ps7D
20hGTxOW6rzuOQARGwD8b4Qf6+kJpGdZyydwKWhAjeJzEAsGKMWhXyuWYh9e6mFkI86uUbyuQIn5
5EAJFl6IpGINkGbWCgKUnxROHlZlkbshT51HfCt6ehUA7EYl32smwPSwTNg0ILv/Y0nzKez8b82l
/t1/b67/K0mt+/9PZ9UlsJPmX5HlJ4TgEj17VZ8nnYf0Arj8SoNDF5wqSVWNhP9o/HSv8ndDGGgQ
wyHMfwYiIBzrkRCB9SiIRIxmGANRiLEQjRgHMf6fIR5iERMgDjER4hGTIAExGRL9P0EKJCGmMhwE
yYiDIQVRC6n+H2EIDEIcCoMRh4EWcTgM8f8AAgxF1DFMg2GIehiOOAIE/38gHXSIGZCGOBL0iJkw
AnEUpPtPw2iGWZCBmA0jEXMgEzEXRvm/x714NKIRshDzIBsxH3L8p6CA4RjIRSwEA2IRGBGLIc//
HZRAPmIpFCCOhTGI46AQsQyK/P+G8QwnQDHiRChBLIdS/79gEoxFnAzjECugDLESxiNWwQT/t1DN
cApMRJwK5YjTYBLidJjsPwk1UIE4AyoRZ0I14iyGsxH/CXNgCuJcmIo4D6Yh1sJ0/zcwH2oQF8AM
xIUwE3ERzEKsQzwB9TAbcTHMQbwE5iIugXmIl0Kt/2u4DOYjLoUFiA2wENHEsBEW+f8BZqhDtEA9
ogiLEZvgEv9X0AxLEK1wKaINLkO8HJYitiD+HezQgNgKJkQHNCI6wYzoAov/S7gCREQ3NCF6oBnR
y7ANrP4voB1siB1wOeIyaEHsBLv/c7gSWhGvAgfi1eBEvIbhcnD5P4PfwBWIK8CNuBI8iKvAi3gt
tPmPw2poR7wOOhDXMFwLyxDXQaf/U7gerkTsgqsQ18PViBvgGv8ncAMsR/wt/AbxRliBuJHh72Cl
/2P4PaxCvAmuRdwE1yHezPAWWOP/CG6FtYh/gHWImxlugesR/whd/mPwJ1iPeBtsQLwdbkDcCr/1
fwjb4EbEO2Aj4p0M74LfId4Nv/d/APfATYj3wibE++BmxO1wC+L9cKv/fdgBf0B8gOGDsBlxJ/wJ
8SHEo/Aw3Ibog9sRd8FWxN2wzf8e7IE7EB+BOxEfhbsQH4O7ER+He/xHYC/DfXAv4n64D/EJ2I74
JNzvPwxPwQ7Ep+EBxGfgQcRnYaf/b/AcPIR4gOHz8DDiC+BDPAi7/H+FF2E34kuwB/EQPIL4MjyK
+Ao85n8XXmX4Z3gc8TXYi/g67EN8A/b734E34QnEt+BJxL/AU4hvw9P+t+EdeAbxXYZ/hWcRUQrE
w3DA/xc4As8jvgcvIB6FFxHfZ/gBvOR/Cz6EQ4jHGH4ELyN+DK8gfgKv+t+ET+HPiMfhNcTP4HXE
z+EN/xvwBbyJ+CW8hfh3hl/BXxD/AW/7X4ev4R3EE/Au4jfwV8R/wt8QT8Jh/2vwLRxB/Be8h/hv
ht/BUcRT8L7/z/A9fIB4Gj5E/A8cQ/wBPvK/Cj/Cx4g/wSeIP8OniGcYdsNx/yvgh88QAXdcgOMR
USrc2iOiQn+ARA7cFR46l19pcFhYCESR0Sp8cEVGh872POaICJ3LrzQ4PBTLRMWo0YJRMaGzPY85
zuPiX04XNTgkHWPiMFIRQ2d7HtILiIb+6QKWS2+KDMUysfEatGBsfOhsz0N6AdHQP12UgaJCsUxc
QhhaMD4hdLbnIY0NnUv/dFEGig7FMgnJ4WjBxOTQ2SYN3HUB0dA/XcBy6U0xoVgmKTUCzZ+cGjrb
lIG7EkPn0j9dQCj1prhQLJOqjUTzD9KGzvY8pOdR/5fTeeJj4JQQimW0wzFSYcjw0NkOG7hrcOhc
+qcLCKXelBSKZYbqYvB1c5gudLbCwF0XEA3900UZKCWU0BHSY9GCuvTQ2Y4YuOs8Lv7lNPRiBg0a
FAKRLiMOBkFaRuhsz2OOC4j4/umidBwcivfTRyfAEMgYHTrbUQN36UPn0j9dwHLpTUNDscxoYxKu
sCxj6GwNA3dlhs6lf7qA5dKbdKFYJrcwBc1vKAydbcHAXdmhc+mfzhMfA6f0UCyTXzoIMmBMaehs
SwbuOo+LfznlXMygzFBCp2iCFi1YMiF0tmUDd53Hxb+cjBczKCsrBKKxk4diiJVNDp1t+cBdxaFz
6Z/GXMyg3NwQiCpmpkE+VM0Mne30gbsmhs6lfzpPfAycCkPZSGoWZuAKm7kwdLa1A3dNCZ1L/1Rx
MYPKQrFM7dLRMAEWLg2d7ZKBu2aHzqV/Ok98DJwmh7LIlthyoQqW2kJn2zRw16LQufRP8y5m0LRp
IRBZ3PlQA83u0Nk6B+66gGjon+ovZtDsEEOHk/9Qlwg8LQgeAYkKgr8w0P9PefReMfDf+fsl47mb
a/rcrQud38Wnp54OlVLBHiGRoEELKU6mnZx50nLSffKw3w9wUiff/c3vj/kUry9ik2M+P9tK5cUl
xWMK8vOMhtyc7KzRozJHZqSP0KfphOHDhg7RDh6UmpKclJgQHxcbEx0VGREeplGrlAqeI5Bdpa9u
EHwZDT5Fhn7q1Bx6rzdhgymoocEnYFN1Xxqf0MDIhL6U5UjZdBZluURZ3kNJYoUyKMvJFqr0gu+1
Sr2wlyyeW4f1Gyr19YLvBKvPZHVFBruJwhudDkcIVanWSsFHGoQqX3W7tauqoRL57YoIr9BXiOE5
2bArPAKrEVjzVetdu0j1BMIqXHXV2F0caKJQKt90fWWVb5q+korg49OrTBbfnLl1VZVana4+J9tH
Ksz6Rh/oJ/tishgJVLBpfKoKn5pNI9ioOrBe2JX9bNeGvbHQ2JAVadFbTEvqfLypns4Rl+Wboq/0
TbnyeGpO9l5y7/w6X1jFXgLz6/bBdP+KXdNWVFbW09niK+rWMvIUJE+58riW76pKtQn0tqtrreDb
NrcuuFdHsb4emeZk18yr06HU+qoNAlVjXh3TAJmSVAMKSduompLCor6KtjRcLvjC9JP11q7LG9BZ
g7t8MK9Tt3vw9PJ9/o9gepXQNb9Or/NN1OrrTZVDdiVC17zOPdPKhWl9e3Kyd8XGSZbeFR0jVyKj
gitiTx+rMXJaQ6kDpiZUIv00DBGfYBZQkjq9j0svoSCWQJe5BMkw1RO0qA3t19AVO5Y6Qpkeqxe6
TgEGgv7E131bTHKLKj32FNAqDZeekMP+QN2XleUbPZpGiroCXYuSTWD3hTnZ7b4avStW8NWgyWBO
HQ6qH2tAk+t01Mvr95ZDI974Vsytk+4FaNTuhnJDVr2Pa6A9zwZ6khbQnhWBnp7hDXoM50fYQk7y
aTJ6/sXEJidUWcf6SPJ5ukWpH5dPlbBLoUzvmlOXYepar81o6NpQj66pxqXY1VWtF6q7GrpMe/0r
GvVCrL5rV01Nl6uqIaDSXv+z67W+8g31VoJG9RVI1vAlVNTxWq5eqnFavj4HyiOhuhpFiY/TlE8V
9nJFu6fmY3EtK8iDUvGAVNwvFdul4j6puEsq7pCKrVIxTSqmSsUUqZgsFeVSMUEqyqSiVCpUUqGQ
Cl4qSPlsLN/HfBTze5j/ivl5zI9hfhTzw5h3Yn4Q83bM92Heivl2zLdh3oD5WsxmzEsZz4cl1jul
YodU3CsV90jF3VJxu1RUSsUkqRgvFSVSoZYKpVRwUgHl5Vgewfwu5kOYX8L8IuaDmB/H/AjmPZgf
wrwN8+8xd2K2TM1PDEsMK964l7SXT1NvvEO98Sb1xhvUG53qjXb1xib1RlG9cYl642L1xnr1xjr1
CE2aRtAM0wzRDNakapI1iZp4TawmWhOpCddoNCqNQsNp8AHkS+BruJrayaTG96wZahoF3/e1+r0k
fO5in1I/mfjia6Bm/uRUX0mWj1vHdrO9xL+LkN9ep6Ub2T4gxH/dDVq5rK+H5Kz+KbXPXc2czidh
OCkGNWLBHvXwF9S0tRZbN7LWjbR1I2tNJbvnQH6NaX3DUDgH495Eztvbh7LKRtWdU7dLA5PrK5ZI
5R4uIhz1adDq6icnx7omMOXG6VKXa/cr6BdBI3A9R+IDIgoz7cqZlDOJdimAdUXTZ4fclbp8nE67
n2yXu2KxOQ5N+esdNH6l9NaAPXl4mUkdt5JbjLU/QiPiFswWzJthE2zi9kg0+E5vBh/WpsMXykP4
iulm7QVwNWIl/AcNt4a1lEEj9jci9UEsJ2CfGUvCeGwiG1h5DaxG3t9ye7gD3AHWOxH5TqcU0sXt
UR7CdsrvWngIPiT0+6RXwU3Ytw/eoqOQ8ybYCadJJl7ryWfkBDcHWwmdH/m0IPUmlPdpOAL/Jolk
AukiTyJNPLeSySLNtgJpDuL1FuNCr5nETpzETa5Hnsc5nitErk5uHbeN83EH+HrFBOUhVbyqWG1n
32Hl8LQbhxpSbrPwJbMRryt6uErXm4Qjc8l8YiW3kG0ow0FyAq/vuBxuIlqdXjfzDYpIxZfKFuWd
eB1SLVDfplEhbyWoYDAIkA5jUKsqnGMuymyBy+FKdl2F19Voy1WwFbbBHXA/7IL98BydE47Ch3Aa
rRODF9WrmJSSRXjV4+Umy8lqtMf6oOsG8ieyh+xH+V4l73LDUWvpsqP2kpTXclu4R7hXuT9zx7jj
3FfctzzwYfxSvpH38PfwO/g3+DcUUxXbFHco3le8ryRKH7NUvCpRdalqPV4b1GHqFvVq9e/Ut6kf
C8+FFNQrG/Wajm9uZuhETa7Gw3sX89ouvB6BR/E6BF9RPfDyy5rQq5RUkmqyAK96shhPAK3EQ5b1
aHQ3uZdsJ4+gLu/idZgcJR+Tf5Bv2HWaU3HJXFaPfnO4Wm4R18Ldwm3m/sQ9gBG5h3uSO8x9iDoe
506hjhF8PJ/ED+Or+Gq85vOX8Mv4a/md/AH+KH8C/RapGK+YoFiguBR1f1FxXPElepJT8sp0ZaFy
LF5WpUO5XLleeTtG9AnlCVUks0q8KkE1TrVWtVW1R3VEdUadpE5Wp+GVq85T16rt6nb1DvVx9Rea
B8MmhdnC3OHZsAPffx4/a/U+Sr/Lw12qMsBgchSj4Qo+BqkEuva4SLU9zMbtodKpa0kmeuoDOM2H
QY3iRVjEXwJ2ZSMfof4athOPYiV5gK+GB+EedTt5km/gT/D3KNNV4yR7clv4HepOdYP6C5T0O/4m
pVWdSyYp15Pt3ERc0W4yF74np+AynNnLjYYX4XpYR9rxgbNJ8yCJwrV2kBtO1ivv5HcrtvFVyuVk
FHpQqzzEXweFkITvRpmQhrGuxHdH+jLI0e9v8ytw9fP4gNCXx6jfIYp3yF34LuUHpZ/fRz4DMHSf
iD0BE79BzDMWxOni0nVxuhU8nFnBQTcoD/1YskJxiH4JfLr/qPo75QnkHIH8B4MexsHd5ZkKlSYs
Ij4xdbBOH8FFxyWN40tTtGP4fKUwIj0jR5UF+asiSak1ei9XuDsri9tLrivPBi5okGJYRpIhlkSO
SB8zTlUEgjbTOywnLtZbpEzxGm4ctpcbs7uoSLGPCCjriVLDmTMnSmNPlLIcF5+CWSqlTmw8wVpT
SllfSmmeMYWQ5ATMKekZI0lRQX6SmmAlOYkhvvKx25T0osIxGfo0dd9iOpmuXPp10o+38a23phOi
/+NPcXERmYQfrxPO6HL5STHaM6qE+Ci+LDL6p5hSUlwZFT10SllScsqUiZFROQXp5CdFypTuH3/6
u6JlzkPP7634ebIiI5y7alD0mZIII7dcN/iMQOJio7VcZ5bw8ydTl5QNjYzQl2YkJKQVjYqIGEnt
vglAswl9mIJPiLEwBebDErizPLpkQiGpX1BUMpafNSZ1AVr38VrgBg2doKzfyxXv0RrWTMMTaLkw
a83oijXh2trwFaNh0aChYwrHLkIjXzKSjMhP5eZGX4JnyfLE/IRl0cvKRywbeePcanXNsvK5+XzR
PqKDHMOJlFI0qeHECfZPsjX7l1JqgInMDbFnvj9B6dD+pbI/DIY8I1GPzBg5MqNwDFqcvlir1aqk
xJTkFJ66IIWo6H1SSkqyWqVPQ6pian9lMcE7dEZyQT6zPw4hdBzeY7c+LT2fYlIi77uhJrHtzX90
Lrzq0iUKwrkTE6YoLh86uGvtT7NLkpIXcrx6y5YdCx0PkPFWUrGFf/sqV86YH7V5k0fN2VRfOJPM
+sxWXr66e2IGEfPyjHzzwpyygkua/zDXVVvr0BhSkiOmjgmP6D7NPacoPjNFp9EItWGD8tatWLmo
YlHLi5PGqPKWnHk9X6OA1OGueV3TCxb8/PWNk/MyM19vmfoPAyZcsTv9RzWbcbVkQhbk4sodA8Xo
vfFwW3mOdtTobKPCEA+R0dqRWbl5+QVjItJTCotKSseVqVQkonjseKWwKiV9VXx8ioGul2GqiKEG
I6UrKi4pHRtRmDNqdNa4svGqbD4iOozfT2bjQTK/PGLkjdG5Q7O9OTnRhfu4BRBmYK7DfOa748xt
0opA+aQe6rW4lN52dFqSIi4R9GlQGJteWFQsOY96o5ium0TqnJHolqRkUpyQUMCTFKJMURJ1eoKa
50cm8HbS1P3y+0e7XyZN+dPXmK7dV/hs56jxYTG5rdU3f1B6Z92qSVxC5vdlBalk6qjuL0mNpvs9
Upfa/XCBcfphw30K67rfd299v/sVUoTNt60bHJnUfMPW3HsEZfrIsv3GdfdGkxm67idJZfdRkj68
+z2VQdv9zaiPu/fHkSHd18QRL93xdsIm1XG24w2Hyx9VxCclK9STwsntuJC0iFFoKVqP4pTlYZDI
x6pwdYXvJ6UwjIzbrYyPnRSB9VQyDpKIiEyUFDkz3Xow0L/DrQeztASoEXHTpEbMMxYX6pJIkq5Q
h6EMBfmA8a7D26JAFO9UFf884cx6sm8ZGXTgABm0jOw9s/6OA9eteW7Tpk1cddemqzY/TeK7v3l6
81WbuqwPr37mmdUPM21A1ca0CYNx5eEaPCWtglUKJW6j08ujVCsUqAp/I3ejIgzoK6LmToWBbY9n
4kphIqvRNZtnTI/TJajjinVxauXMnw4Q80Elf9CsGP/TgUas/HjmoGQ5UD7M5lLBwt1KlWovt6Y8
iuMTOZWC41UKlVJBW1IJl0gIpyC8Atvps+RGjleqFLCP4HnQ8DluGDDxcxZNa5W5WZprYl9Yq8lN
zVJiRRfG6XRE+fCP3Uque/6ZSO4Jchk9HZwZwl3m9/dIMAWeUi2hP3wqp0/mDPn6hDz1v3FxnRd1
ffT/6uKT/2vXIjyR/ioXO2GlkwM9n8jmQ+AzbIKRXSTXOVArv5TrPGiVH8p1RRCNEiKVP8h1FcSp
lHJdDStUyXJdA4mqW+R6uPJBnE2qR0C+aodcjyIzVe/TT9gV9P0gUjOK1env62I1haxOvyps0VTJ
dQLxml1ynYPoxCS5zkNRIpHriiAaJaQmFst1FaQlzpbragKJV8h1DWQmBerhEXWa++V6BFiSNsv1
KG5L0hlWD6dypt7K6hFUztR7WD0yqD2WyibXE7Aen/ooqycG0WjZ2JdYfWhQ+wg29m+0rknubY+U
571fyDcai4SZNrPb6XE2eYUKp9vldJu8NqcjV5hktwvzbM1Wr0eYJ3pEd7toyZ1vFYVFNkezBbNH
aHI6sLNDdIuCRfTYmh2iRWjsFGrcNo8w1WlvFT2CyWERKqwmtx3rk23Not3ZIdgcQl5pqZH1YSUv
V4gKjwqnrIMYOt22ZpvDZLd3sh9uWoQZbWabxSRMMzsdnmxhktvt7MCS8qj1mtwewesUzM5Wl11s
FR1ewYvc5BFecZmXcRaaTK025Ici0m4Psg3I7fbkopJsomzBLTrdzSaH7Up6Qydwi3bR5EEZJMnz
BZMnyGg99shmbL1WtxjQxOV2ttssomAS0AStTofN2eZBAXqM5RG9grNJsFGdcBaXG+3s8CIvxgnV
wTFMK6dDpPyQ1oWyOtEurLnNK7oFT6fHK7ZKpqbDRMkEjLrZbXJZbWYkb0MPovw4oMlkFj09NkdT
mzBLIjQ53cKcimyBiup1urOFFrGz0WlyW2gTckAN3SZzSyO6JZuqZBEsbls7NltsnhbR66UEJhdK
bvJ4pFuXm82ZjbZfli2IXnNuNrVeh4jBhWXvtE02O7Wa3YL6IT+nuY0pgRObbHYJG53LRGzosDks
zPdmu80lS0d17zChHRpNVJBcYZpDMFksNhrJ2UERa3OY7W1ofnniDpvXKjQ6EVAviRpNRZn1Whc9
ZWtCEzrMqI6nzWxl8rttkpucTrtkeSuCh8aOic4kNNupCWQhXbTFY7Z5PE6qXKNIzdfobG3Ebqto
bhFkzYIM0+pEpwQLZWs1NaPcPQKIJvS1JB6b1o7LBV2E0dDaiDJRZl630+5sZt6XyUSH2eY22zHy
HGhet4nRYRTaRTOdhkaMqZVGGFWGqcW853Y2mlh8u+w4A1Lj6sDVhGsZSRkZ1ttw1VsDgTXHaZPi
WOJhQSGkW9SqyS1e0UbXaFObg01L3RIUqb1BivZ20r6AJ+kaN6HTcEX1kdkVmE12gvccuxTq6kTa
JrSZie0dlLEZ5Wlqs9PJLSZJFGTXIdJdj4lusdERVFiLzS3K0tIOj7fTTpWtxtBtN7ltordT0rXV
ZTJ7qYca2+x20Ss5QkTbtMi7ldNNtxkW2ouoZaiIvcJhXeLXszk0i85W0eu2mQXJd9QqV7Sh4NQf
TntnM9sPcQtslmZjwuGGmNtrgXlic5vd5B4rzKwdy7b8hTgRtV1hrtHYQ5YjkwWtFnS2jYWZCSOs
2UYVQcFoWIqtJncL6oI9QbdN536WUFNTnyzAXUVk+7VXejQYkIGTTWB2tjlQSWrSXhbzO11OFhed
Vq/XNdZg6OjoyG0NdOfiGjV43W1oepdoYF42dARkN9Q723DT6KT7Hs5tk8KA+gXDu9Xm9UqPKipV
1YIZk9gWRG9wx7a0oQNR4g4MR2vQWFvP9mGhgYhbnstukrzOdjnUASPXgZuPEJjc6cDdPtM2ShBb
G+moXl6OAPU5RWLkbB9BN1PfB5aJPD2zp8xrHJMg04az4GOAmtxNH3K4RTrsTlPwpGz1yBuy0GN5
Z5sXdzp8JrXbzCKlsYp211kagQOc4KY/0QQ71IIXSwdYEN2I94OAxzEjXkVYmwk2MGO7EzyYm5BW
gAo22sXQhC02rDnwFVqAScjPjuU8bGsGK/Z52J2IpYjU7YgWpJyPfSL2LEI6B1Ja5JJSNzFu0sgO
NopSWhgPytXBeAjQCJ2INdhvY7RTcZwddRLZnaQRldXK9LLL7ZMZDxHvnchdYPMK+PJfipcxaJzU
kse0iqK/w8IckPrcEjqZJM2Mo4nZgcpH662yxDOgDW1pY5YWYBrWKR8PZDPLuZmVO+T7gBySd9xs
Li/2C2xUK1qfakQ5O5hPvLJsfefwYtsy1h+QmdaoRDZZPsmKgdEeWdqz7U3nz5U92asRlZPqTjVv
ZhLb4MqenoAGbmZtEe89sh2CbZ7PKD0DRFr/+MgOkpaWlPvZPnExLu3MCiLjL8hR0MqoaLy2IaVk
gf6RReX0Mo82MWkDfpJ0cTH0yJaX5OqVSfKONE+vr5yMd0A+ia9LtqtTjpde6jbmNzeTpBOzl3k6
OKoDs4l9oqCXdzNbmS6kotJL3NvkNSjZX5qBxoKZadM/zt2y7aQy2ApNzOMCzMHVRf0RsKqXtdOW
FhzTibHllPeUAJUkg+RDN5u7Bamk1ZLd4yUL8wpdTe0ytYWt8RbmF28PBxOzocA09MheC/S62PiA
ntly3C9jNUpnRo2ze2Kvg1nS3nN/Lm2b2JoJxJqdxY1bjkgL/Yk7atfrCUljExsTXKc2WcYsns3m
tTGP9q57M9LYUPq+tgv4vYPJR3VqZDXJIrlsN3EwOguzVWBPzh5gj6U1OlObHP19Ne5gHKxsd3DK
NclfwbxNsr0kyc4Vu9KasjHLmRmlWfaOh+1S1iD7u2XOgdXkZDYOjnmrXPP07DumHp1oxNt7oqCv
JV09NB62M3rYmgt4rlH2fLasbSuiNJquARqfwlk+O3fEtDKe4nksZWMx0Czbu78FRPYstZ5lvV5t
7fLTRVpF0t7QymSzB0nmZXsffbo1B639vtxE5gkbUppZRFvYc0qKXjcbEeAn7YV2ZomANoE9xsT8
La2BgGd6vdW79qg8jaw9sH+7WOR5evYv6dkhPZuk57IoP/EC3KT2NvlZb+23Y83BXluf/ThYDots
ieBet7ySaXkFchZ7JGhj1gloG1gt595Tz7WTSvHt7Bl39poMPMdN8kqzyE/egezs6qdb35XgDfEs
JfnVKfNtkuPMFHTuCEhslu1DbWHv0dwSdNbrfdJQXwXOer1Wt7BV3yQ/RSTLWljEiWfZNjCCRm6n
fEqjnq2Wd912JouN7XOdffxKo8/EuAXWUCOT185og1eEKMdNy1lnKzpD4DTTu2sv6omZgBXPZTmP
7MFe+fqfHJrZ2aiVtblZ1Ah91l0gVmj8meRTRbbscXo2aQ46H0qnwOY+uvVaziSf0M4VA/PYCmtj
+6MbxgI9adWyMnDKXyhrFIi7QuREe/pzyzmL27mfLdLKtgXtZiZ5D2tmvV45LixBu6XIdkc322+d
PWPO3dsEF/JeEojqwDpZIJ9VxKDztReC3xoMsgTOIA3MbP9xyJ4MROm5pJiPnnOx/TewX3Sy1eHF
+ljkbcA1Q69cdgrvOzpXfo4a2DxtctTTXdYQtJYN8rkh2O4GqGcSSicNulKks5akt63PbhBYL9Lu
3cqsEbBH3/eBKvrfCuG7Se8pKNAjnbEt7Cnm7bFxh7w7WgeY13aO04elZ0eUTnkuFlvBa733LCfI
pxSvvGKpD4R+mlMK6WyfieNGsWhsZU96y4ByOfrxDt1Kvdx7zyPSag6s+7OfJn21743PvnKNC7IB
1UTSRXobCES5u+dNTjpFOtiT0jSgpr3Pnr4nZOEcMe9kpznpTCe9J7UzbcQePlb21HL9go9mQe+n
DWLQnYmdaYI/f5BOvAGKj7HfwUaY2D5rAfq5hfSbCwB/Cf2/Hs+ZFOwXCEOAaJCa/vqA/RWLsL8r
YdbS/w9T/t8JtGXGVdoSVdjoNVPXnI4iam7bKu0obErnCMmLMIaplFnRPDdYCUaTKjxLRRRkVTFH
FNtqjXON2UEtQ+4ctmIIlLFrNkaDh+3hIrPCBHoZdUHMFIkLdnQ+/tmtm8kDmY8bdzT98fq0q45o
tq1KOmZcxb+AOWcbzxGOi53yzKCbj90wr7ri9NHWqVF5dxujekQlShRq5XomJL9AoUrgFk/KSzIm
0BtNQuQikX685xAqTC4xL9EYT5vVCRGVbe5Gk6PdZreLeTHIDVvDE1TzraYOr5g31KilDREJiVKD
UCG6vezTcvqBVd5w41DazScky93zba04i6mVfSBeMck4LCXKWJCXbxxjZGlxSlQevS3ILygsLSxd
bKwNEnZBbV6KMUmaP3qh6LbV2pod2cI0hzk3L8s4SpooLdDBpqKfNEpz1Ypu+vGWh066iqQFW4Uo
gV9FYgDbw7lVhMD9r+y++8+vCQ+HX3P9g2vbTj4y69tjz8U802x66i7LkPee+OGVggdWG6+vW77h
aMsHRbfHPPPW18v+1XHvcmfZMzc9HLXf+p190ytPzct5YOr4U4+9e+lSLbf1R0PLsLtP37Xl3sGH
uI9/M2Pep9ENX5cPWb4v6sOJLz1ybO1TS6+8PC+X37wyYfsU4fU8T9SinNeWjSm4OX5z/L4PrYYd
n396oGvD6OfX69Y2PXVt3SJn2zNlOzLWXvpKbFLZ1tVfzX8u3PFC98HpH+xTx92advXRCSPfGrbs
6615L3/7edqgoy/smVKxZfDSbcM2Hr/s1DdXf3vNA43kxlMzIz58M23h9ptfe2hd+0Pf7I/69/GZ
R7b9ZN32UOK4PWufe4LjMfDvWnnUuPKwcYxKgxGrVKoJUWQaM4wjAvdGsiZV/lDWafa4ctvpR9xo
d/qhLIudoQmE+BUaowoLjoBxEm0brhhrLDEWbRuzLX+NUR5udtv7jDZIsRIcKhWTcpGKRerQdEWk
MTwgBa8xRtPGGDoX/V2PCiXE+zgFRubdg4wpgfjmEyLn107CQCvJycspLDhrVfArV8L0lh++qjtQ
OSTv+s7NWbc8s+pB8tchM17zddU5jmlG3XXZoVduSvhCMS/qn1NGGqDEd/zlm2ZteSetMen0xGLd
bFfeim/Xl6zd8+WXt0L3GwtumTXiL/ePnHXlQ4+bJv179OtfvHzksg+eyLpuwqO3PXrk40X+px85
uPzUG5G3n7y1O+vtcfO02pKRpydOxzXsN67ivpDXcdTfs06+c3jUutR8ZdhlW9rXnb2O/1dWRv/l
aCwJXo6LQpzUYMyRJs34pUlr2R9ff3FJ7p6TOfWDt61Xrk6tbGq7dPkLe7eaM/zjK/50dVxJbPoC
z5G2kbYzs/YJS94O/2GbdvSJBQt1psPDjh5/sqDlpX9+cFex+FvtTZGP1Q5bcnVT4VJlV1V3+6xj
tSvuXCnc9tC6JXdqTn9m/OGbtOIZk/+nevOOairZ43iA0GGRDlKkRqToDcWg0psiIr0j0oIUpXcU
SVSaCAKGqpAEA4QqIkUpEgUEDIqCKMiCLjVIkaqIwkuAVXbVt++8c97bs3/lzJ3cm5k7v99nvt+Z
CdOTodZdzb0WJIR6lWmebBFV+Dy26IrSWu7YCU/aXFWv4ftpTWtExxWNcXq0zjuEiTdOer46fofU
dNIAHTraOCviKAMrINSxI8frA8m6DIzXyLwtNZHEU6IybOZj0K10o8rHVagyTbZOdTzs3ZnwFZ4x
SGn5bKZZjYYsqjasaK3HtHhPYKTW1AFhrCfPmE2dhPsrUJT2jpgor62U7AAQj/7LlGT5mpLUZKWu
sJmMsoA0IIWGoCWixX6WjIEBAXIuThvpx7ORfpRH/JsMpGv6jzJQ8c8ZSBnlmFDf/uOmVCJ2b8La
kUDzl7v8aQ3JoIcNnZ2ti7+8Wl8xbFJwBthblgIFelIGT14X4aw4q9to3HlhPIr3QsHu1FOceqsd
tRmaNMRsEzvay+cLfRYEjAUk9s57XDkt9qGugwc1zRLY5B7S9y7TOYYQcPVjXGC4eHFeRkR6xYek
PX6Ge4MEjmj2v69iFTHvDUGnI108vjA+jX8fVMeY3bfCbgHJcpJvDKe+FRHdiH14WUw29JlScH1K
gP3K3bFj3EzixJHnPYp79TW4VdgcwyVacW6zaU9936mNL7JGDjw7mxfs50G4bnQYUBKtwJbvdFaR
6UsskqaPeMVXaR/x2w2cz5pKXCmABHOQEfBpEwFsIALosopKLPsztWWXqSGN7W8MTCaA7++5zcwp
pu3jG+a/sWkp5bKHckQB9qeNuL1QYUBw88vcP9yig4oCuzaHie9bvamPT6CIZlCgu4+/R2AYBQ8H
YAAUCgCwLTzIU04wQreKf0OL/nIqp24g+I4dmj8uIJWbHuoATGLxVyRPflxDHcurWbuBFVE7a4LN
xiY5yns903INmykJbjfvn393PVowKfeiW2WLV7izeK+QyiAbVcpEWvN9ObesLHdIZtdB2fssVdYQ
gt44k5pymixe6kDhlP4FreGLbHVZpy2cSpBnMY5yIcdImXdcD2UZC0IZJLhy8ePJMnxjqhkuXI7W
tPBcIZhpzIeC2WvUrQLd9y10K+Oi7h+cMr92vOxLQfiZwOPlfMQ0RilRkNVVRw9YnQEHvYrlut3q
TTcmhvznCEur2epDDjyIEHD/cmNZFGrtVuf53oKd/vYqHfXvGfLEgEq6S+2VIiGcl4a2uFEIIHAA
AkvJSyowIgtApEftsOvynfXwzxE3ieS6bZi4/hjj//8fP+RfxPgGFVATzE1XFtL5lKZrqSRehbAv
2DvK5+YwP1ajTY5Naj84Jjr/3ipVtgp9uM159vNL4qFDtvj95h5rEmfU24lFg7Rnf4VeUc3d4etZ
t8ZhxOfR9LlLe5jdVsRo0jmivIi/TQYmKdcIx3DES7K55H0wF1wRbe/lXjAt8daWp/+C5P04euo0
q8lyw5zpo4bxZuCzCJQxVgi1Z6fhCyFq3FzUG5o7dosVv7ZZzcD1H5maV9+hkeJYv9r7niEpsja9
pRgmOxI+UhgyHIwGdXmqE57vj3+jyVGo5Cng+VrpbY8geKRQF9xmq6DsbSjI6lzDhE3ofmGurtcp
aJHv+5rjYExqUG7BczSZCg/J4qB8Sxh4MmcaNYGEitn7m6kxbrvv/W4ShP4uJAD7yXpBEQpTVIQq
UgQ8GfHy+39HAiL/j5KBE2DftBtMVk4B7mQpEEj+nR0bUwjZbNCbwl3P+Hi7/t4ypp+17GfdlCf/
6HfdFAdEN7uxc3uNK3xDfFDUiPGGKRD5niSsFJIwbJDkIVHkSv3QuprxTPiDHgnJ5eAnouud0pbH
O67XIG8rhcmBmgsZXri01+CWSQRCb0VCGpb+E1s10jTrHbK1YUdLYdOM18VEM4E640+uVHEEnh6k
O0gjVGeJQ/n4qovJm0+qd0dhFUMu9OKH/DQUDy96lekt7Q4QFnusxS9sUm2a1Z3XxdnKr+5Hd2Ye
JapzUmu6qT3TVaSWoPgZqzMWcVtoX23+4CJmKFuUbc0aqmmhHFluPT4yZRMmWfxBeh+7unKomtb5
AveRSDF33rGjKc2hOqaHMUYX41Kzm05FTDKuRtOcW870U5EpcMsgDsn9JkO9k03xCHxJhaN8LkZQ
CGLqQyTHHk0ekkqa/D4gP9LhNP8MvHDQMW4ZcG4yX6hpaEDgDYsq9AuYB8wl+VHG4ESbv3np6DJa
mpdnlbBihgD4v97CRQ1mEWYCmYGCyHZdG6QJMG8Inw3foQewfRVYtAAN+WNbXm5gzGX4zQJt7a1J
ZmbFZ0ioWpyz7guGghUneNtemk/KRzSfVs3vvtA93GJpVljF/4Q4Nodesaw+cu2wxCh+10B4zzJP
OMfrhasCUwwnKi9dvZtgXSdIRHWjriksJg+ux2Y7GOgbH4AcFBEwh30+Z8+d+nBAMPG9k6nKKP20
22zYVNITKxc4ik8fHT4ErxmClK21cVS3YomtJy/7LnS8LkZ60w/A+e8WLkc/YNTKmIOUeIRXEGQK
brntwpXHMHilc9be2p8pTJvHqZzXVAKo3RN9CeR3OHMIlltdGZ0LZ7/noMICm0slpMQeB9vS2j96
2ovve3suOXT36h1vXBKdgnWFgzQ7G4CkVSCjTGATY0xOejmPKf8ZBcG/W6H4pyDjG/sOKCoo7qe4
JRhZG5GLSpQiEPg/6cdWPc1P6v9SEnUi0pTL7LHzhKHBrmLUlV6VG7suPzwRvffE+wr/peKSWM+q
/gqxCOa2NpxBsoMYJ2llSfxG1aJ3cNnszE2VR81NNvbqxZUBCpB8Z4RTGMZ50TsW1eX966Pc5zdN
2IOd7vnGwzFpPHEFJxBdOm6jry1zNDo+DwRL7NUBQKO95yJQ7C+shfImjJjbYwewvWaZpztcOjI9
s1IcjhmyT+zrtrNzOGmaFyCHq7uoy5rAzx38mKE/K9+Xe8JwyuPLidteSdN7TGDKl1v19LmvGWfc
WnS/+XKQ0e9UYE5IgtAlr/TJ8ZO6xDdjfqzPXECpEdCMROY7nA2VXTNzQ6IzeEenGZi26sNNSYSk
SiG/kcTvvMs3GMz0eeGDzDqNZgSO89MJ510vfnrty0/Ih6dcFQcjMAAiJ+qHFMEE3vw7+Pe9WDDY
NH46gBaggVZDq0Qf3Gb8/niyztfLg3J139aJuIB9lASgxD859uU3DKHRNieqDWgC6l+dKHW0wk9P
7G08F+7//QMDf+QJlftmUcrZ9hlcJ8y9PYao28YrV7sfGJbuKz5vztovX/3Rc4x1VXRniBrOPfwO
KjLefl67+UI2/FyssclZJNfShYCX2Eb7DmrfJ5DTvPWmXLi4ppoRDBETdCPZT1WgyRJkWfXxIqTf
QWG1VzLcIas/f3VxXnNniYVe6ZGBZGVOa0b9uQVozK56cKIdB5yGxGzShWGJz2zoIxR2MXBLilZV
W8UJPrOLVsJ1fCmKmcLD1Gu0vYZF5nTrI8tIcxa3MUfq4Y1min3tE3QuYLpQb+P1I3XZk9q2Ma9L
maKWbFpkR0bP2x0dlQ+bEbuUwiJXaWzX+kDD2rr4eefwPkLn1JlcWBgUCX5MxuYjaioqAFH1j4Hj
HwD/bRkbjZgAuL5OqFJUUHoa2o3leco0uzX0jDRQlu0r5+SmfysxQ38BttdyA+LfbgRDyXmriLrt
EXV+wQiT8bRdQwahWV+d3wT4b7uFBeoKOKOVo/b/cDNO7+vGx082OTGQKImfn0b9emD1z2oSjKQC
AcoHn7+2uapq7BGfbCVS7tTXSwJ1O3HdECd0algOOoQ6mz94pk0KtCpgWvvlPsnm1HW2mMaPftav
Wm8KFw6IOV0QeZRYgWe/uOuI7fIFosHNalmIbVayhGydz6eWXzHoIhquPD/2JT0R4i7NUWec3oup
dcbQ57wxZ1vmJ6ZjVyNb3Cp0lnOOyWbkxWeQhvlCPtytm87MqiyfNCwSNPIuF1G/9dIkie2+JJ9c
qU/9RGyRccp4ScIs8h7fyTBSevQdaFNktS58RasJT8dgV6Jnsc/bfJB/NLL8RQ6srQzAO6Zm+H0h
JazBqbAJT6wk1ns8R6JrZM492W9S7dn+sp/v7cOWZAySLIuQVKvfRowOiqSaIl+aoIT3qf/JouYP
llJZ6Bg2G0BNpgzaBuDbHnvM37Z2qMih97WGFspGme/JE7y8vII8VP6ALZm/20KPA7xjtBSHPsrJ
cND1Zmi1ve9bxR+EgJ/rJx7eTwujozSc5WrzOk9D5YYbcaK2k7+tTpjoKuC8qs8+GMi4eOejFLc+
fpokb7xYq5Gjb4CM4siruNyNM2A5lZBE4nNWH0EtjDRYTb5E8SphDjSswIQx/RPzJ23QryYJOdc5
WF0VgypCEmUr+5N6Fj3jJuATs3ifElsca6o75EX+cEXxOnJIVaiFaNQwIJogEAwx5b1ry8miZZMi
WRu0tnO5xIoteNWRlPyu/Ty7Az+2lbcv/r3KW5y+bsAINf6xnHtxub4oi0v107bEzkvXM6WnqHSc
j2b0BN3+rUc5MTHLAjLVyk9j/6q97SrdeVLVYn1Xc/rl0lVJTnxilnr2vwDOyM6hDQplbmRzdHJl
YW0NCmVuZG9iag0KOTQ0IDAgb2JqDQpbIDBbIDUwMF0gIDE5MFsgNzk0XSBdIA0KZW5kb2JqDQo5
NDUgMCBvYmoNCjw8L1R5cGUvWFJlZi9TaXplIDk0NS9XWyAxIDQgMl0gL1Jvb3QgMSAwIFIvSW5m
byA3NyAwIFIvSURbPDhDMTIzOTlGNzlGQkVCNDZCNzU4NUFERjNEOTQ1NjUzPjw4QzEyMzk5Rjc5
RkJFQjQ2Qjc1ODVBREYzRDk0NTY1Mz5dIC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDE5MTc+
Pg0Kc3RyZWFtDQp4nDXZBZgV5QLH4f0v2AWKXkzAQkQFBEWxECwMjIuJXhUxMBDEJMQEExHzYmOL
jYEoNohid6MgKoLdAXj43mGfffZ95uyc2T1nZr7ffHPq6mpf8+en9rNxXd0ChhRiqb5nYZF1Ct1/
KOx1aqH3hMLAzwuDRhYGD8fEwpCjCqcfUBg6r3DBuMKILReQTC8sc2+h0b6YVWjcGt8Xll8anQsr
3Fpo0hEDC723LRw9qtB3bOH4nXFRoV8fDEN5DTkhuBEzCgOuKJxYXlhO+qkwqFth0ooYjfGFyfvj
5sILnj5lNXTCJ4UXWxZespWpJxWm9Sh89lDh6z0Ks64tzPbPz5lTmLtDYd4dC6hvOKaw0sxC0+0L
zUYUmn9XaPVooXXTQpvyT9S3W7/QvkWhQ9/C5gMKnZ4udKkt1de+98me2Av/rVHXo245VKv0qD2h
64iyVHswqEcDNMSiWASLYzEsiSWwLJbC0lgGJ6GRv763pcZYHiugCVbESlgV/0FTrIxVsDpWQzOs
geZYEy2wFtbB2lgX66ElWmF9tMaG2AAboQ3aoh02Rge0xyboiE2xGTphc2yBLbE1tsI22Bad0QVd
sT22w47YAd2wE3bBztgVu2F3dMce2At7ogeqw63axftgX+yP/dATB+BA/A8H4WAcgkNxGHqhN47A
4TgSfXAUjsHROBZ9cRz64XicgP44EQNwK052QFcv8xScitMwEIMxCKdjCM7AUNyCm3EWzsSFOAdn
YxjOxXkYjgtwPi7GRbgcl2AELsVIXIZRuBJXYAyuxlW4DqPxf1yLa3ADrsdNuLGQaiy4zdtaHTa3
4w7cibtwN8biXtyD+3EfvscneBAP4GM8hHF4DI/gYYzHo3gcE/ABJuIJvIGn8CSewdN4Hs/hWUzG
JLyIKXgBU/ESXscreBmv4VW8hTfxPt7B23gP7+IjfIhP8R0+wzR8i+n4HHPwBWbgS8zE1/gKs/EN
ZuEH/IQf8TN+xS/4Db/jD/yFP/EP/sY8zMV8x6AoRhSjhtHGyGC0MdoYUYwoRhQjipHBiGIkMqIY
SU4jqGEMqlnBGWCojChGFCOKUcPIYEQxShlRjChGFGOgjtE7EhmJjCxFGyOYkcjoZnQsghnBjChG
KSOfEcyoaCQyuhlRjGBGRSOYkc9oYwQzchaljFJGIiOR0c1IZAQzohjBjGBGIqObEcUoZTQu2hjd
jDZGN6N/kcjIZyQyghkVjY6Vi6/abhS+SGR1+VNFoxrkFq5S7XBtjDZGDSORcRrmYJuuVpHISGS0
MUoZUYxSRhsjmJHISGQ0JxIZ4YtSRj4jmBHMCGYEM8IXiYx8xqVf5DMSmZOheJHICGaUMkoZpYxS
RuqihtHNyGCUMjIYiYziRRQjihHFiGLUMNIaUYwoRhQjihHFiGJEMaoWbYw2RhQjilHDqGF0M0oZ
bYwoRhQjiqmiKFkRqbjyiKuEGKEjkbkNShKljG5GIqOb0cYoZVQ0ShkVjURGIiNLkchIZLQx2hht
jDZGFKOiUbyIYnQzahjBjBpGKSN80cYoXkQxmhpRjChG/yKKEcWoYdQwahg1jBpGDaNxUcOoYdQw
ahh9z/vlxKvmHZlWlhaesKIY/YsaRviieFHDKF7UMFKXr216ZVRDuijmGw9Wo77eZo4Hq0i5xIlA
RykjnxHM/OQJ9QgWTB97jq7mhmWqV6MhFsdiWBRLYgksg6WxFJbDslgJjWEaWKdxZf5XY0U0wX5Y
1bt7oKXVsDrWQDO0QHOshTWxDtbGvmiLllgXbdAK62EjtMb62BAboB22wpZoj42xBTZBB3RCR2yK
zbEZtsZu2BW7oDO2wc7ogm2xHbqiG3bA9tgJO6I79sHe6IE9sDvErc59hjp3Hcolf4397biDLB2A
nqj2ZvU7HSsTvxqH4hAchl64GlfhcPTG8TgSR6Av+uAoHIOjcRyORX/0w5UYgBNgxlduaNQ4Eafi
FIzAQJyGMzEYg3A6huAMDMXZOAvDcC7OwXkYjotxAc7HRbgQI3EJrsAoXIrLcRkmYrS9We2ja3At
rsP1uBE3YAxuwi24GU/gcZjxlWl1jQm4A7fjAdyFO3E3xuJe3IP7cR/G4UE8hofxEMbjUTyCF/Gk
t6A6Wp/C03gGz+J5PIfJmIQpeAF/4SWbro75qXgZr+BVvI7X8CbewNt4C+/gPbyLqlwf4gN8hE/w
MT7FZ9C4MqurMQPT8QW+xEx8hVmoqlYFrErWbHyHb/EDvseP+BlVuX7Bb/gVv+NP/OH9rAarvy1V
A8s/mIt5mG8VNUx1i9QQG6WM1EUUy6SwhhpGMKOUUcpUtzrVMIIZpYxSRiIjkWU6V0MNo5RRw4Wz
QRWNUkb44mKhzP9qVMFcBRIZ3YxuRvEimBHMCGYEM2oYwYx8RgajjdHGiGJEMaIYUYzURWgjrVHD
CGZkMEoZ3YwaRg2jhlHDqGh0M6oWiYz6RhQjilHDqGEkMsIXbYzwRRQjkRHFyG5kN8KX7rVjpL9b
+APaFJ4rH1HUT2q1gAYblU9NGrTtVWg3tbBx+YyhwaGvF3rNLVw5oa7uX/K2AYQNCmVuZHN0cmVh
bQ0KZW5kb2JqDQp4cmVmDQowIDk0Ng0KMDAwMDAwMDA3OCA2NTUzNSBmDQowMDAwMDAwMDE3IDAw
MDAwIG4NCjAwMDAwMDAxMjUgMDAwMDAgbg0KMDAwMDAwMDI3MyAwMDAwMCBuDQowMDAwMDAwNjAz
IDAwMDAwIG4NCjAwMDAwMDEzMTcgMDAwMDAgbg0KMDAwMDAyMDIwOCAwMDAwMCBuDQowMDAwMDIx
MTEyIDAwMDAwIG4NCjAwMDAwMjU3ODYgMDAwMDAgbg0KMDAwMDAzMTQ1NyAwMDAwMCBuDQowMDAw
MDMxNjMyIDAwMDAwIG4NCjAwMDAwMzE4NzkgMDAwMDAgbg0KMDAwMDAzMTkzMyAwMDAwMCBuDQow
MDAwMDMyMTA0IDAwMDAwIG4NCjAwMDAwMzIzNDYgMDAwMDAgbg0KMDAwMDAzMjc2NiAwMDAwMCBu
DQowMDAwMDM1NTA3IDAwMDAwIG4NCjAwMDAwMzY0MTIgMDAwMDAgbg0KMDAwMDA2NjAxOCAwMDAw
MCBuDQowMDAwMDY5MDM4IDAwMDAwIG4NCjAwMDAwNjk3MTkgMDAwMDAgbg0KMDAwMDA2OTg2NSAw
MDAwMCBuDQowMDAwMDY5OTMxIDAwMDAwIG4NCjAwMDAwNzAxMjcgMDAwMDAgbg0KMDAwMDA3MDE1
NiAwMDAwMCBuDQowMDAwMDcwMjA4IDAwMDAwIG4NCjAwMDAwNzA1NjUgMDAwMDAgbg0KMDAwMDA3
MDcxMSAwMDAwMCBuDQowMDAwMDcwNzc4IDAwMDAwIG4NCjAwMDAwOTEyMDEgMDAwMDAgbg0KMDAw
MDA5MjgxOCAwMDAwMCBuDQowMDAwMDkzODY3IDAwMDAwIG4NCjAwMDAwOTQwMjYgMDAwMDAgbg0K
MDAwMDA5NDA5MiAwMDAwMCBuDQowMDAwMDk0MzEzIDAwMDAwIG4NCjAwMDAwOTQzNDIgMDAwMDAg
bg0KMDAwMDA5NDM5NCAwMDAwMCBuDQowMDAwMDk0NzIxIDAwMDAwIG4NCjAwMDAwOTQ4ODAgMDAw
MDAgbg0KMDAwMDA5NDk0NyAwMDAwMCBuDQowMDAwMDk1MTI1IDAwMDAwIG4NCjAwMDAwOTUzNzYg
MDAwMDAgbg0KMDAwMDA5NTczMCAwMDAwMCBuDQowMDAwMDk3MDk3IDAwMDAwIG4NCjAwMDAxMTU5
ODkgMDAwMDAgbg0KMDAwMDExNjEyMiAwMDAwMCBuDQowMDAwMTE2MTUyIDAwMDAwIG4NCjAwMDAx
MTYzMTMgMDAwMDAgbg0KMDAwMDExNjM4NyAwMDAwMCBuDQowMDAwMTE2NjI5IDAwMDAwIG4NCjAw
MDAxMTY3NjQgMDAwMDAgbg0KMDAwMDExNjc5NCAwMDAwMCBuDQowMDAwMTE2OTU3IDAwMDAwIG4N
CjAwMDAxMTcwMzEgMDAwMDAgbg0KMDAwMDExNzI2OSAwMDAwMCBuDQowMDAwMTE3NjIxIDAwMDAw
IG4NCjAwMDAxMjI3MDggMDAwMDAgbg0KMDAwMDEyMzA2MCAwMDAwMCBuDQowMDAwMTI1MDA4IDAw
MDAwIG4NCjAwMDAxMjUzNDAgMDAwMDAgbg0KMDAwMDEyNTgzNiAwMDAwMCBuDQowMDAwMTI2MTg4
IDAwMDAwIG4NCjAwMDAxMzAzNzQgMDAwMDAgbg0KMDAwMDEzMDcyOCAwMDAwMCBuDQowMDAwMTMy
MjU4IDAwMDAwIG4NCjAwMDAxMzY5MzMgMDAwMDAgbg0KMDAwMDEzNzI4NSAwMDAwMCBuDQowMDAw
MTM5MTUwIDAwMDAwIG4NCjAwMDAxMzk1MDIgMDAwMDAgbg0KMDAwMDE0MTc1MSAwMDAwMCBuDQow
MDAwMTQyMTA0IDAwMDAwIG4NCjAwMDAxNDMzMjUgMDAwMDAgbg0KMDAwMDE0MzY1OCAwMDAwMCBu
DQowMDAwMTQ0MTYxIDAwMDAwIG4NCjAwMDAxNDQ0OTQgMDAwMDAgbg0KMDAwMDE0NTc3OSAwMDAw
MCBuDQowMDAwMTQ2MTEyIDAwMDAwIG4NCjAwMDAxNDgwODMgMDAwMDAgbg0KMDAwMDAwMDA3OSA2
NTUzNSBmDQowMDAwMDAwMDgwIDY1NTM1IGYNCjAwMDAwMDAwODEgNjU1MzUgZg0KMDAwMDAwMDA4
MiA2NTUzNSBmDQowMDAwMDAwMDgzIDY1NTM1IGYNCjAwMDAwMDAwODQgNjU1MzUgZg0KMDAwMDAw
MDA4NSA2NTUzNSBmDQowMDAwMDAwMDg2IDY1NTM1IGYNCjAwMDAwMDAwODcgNjU1MzUgZg0KMDAw
MDAwMDA4OCA2NTUzNSBmDQowMDAwMDAwMDg5IDY1NTM1IGYNCjAwMDAwMDAwOTAgNjU1MzUgZg0K
MDAwMDAwMDA5MSA2NTUzNSBmDQowMDAwMDAwMDkyIDY1NTM1IGYNCjAwMDAwMDAwOTMgNjU1MzUg
Zg0KMDAwMDAwMDA5NCA2NTUzNSBmDQowMDAwMDAwMDk1IDY1NTM1IGYNCjAwMDAwMDAwOTYgNjU1
MzUgZg0KMDAwMDAwMDA5NyA2NTUzNSBmDQowMDAwMDAwMDk4IDY1NTM1IGYNCjAwMDAwMDAwOTkg
NjU1MzUgZg0KMDAwMDAwMDEwMCA2NTUzNSBmDQowMDAwMDAwMTAxIDY1NTM1IGYNCjAwMDAwMDAx
MDIgNjU1MzUgZg0KMDAwMDAwMDEwMyA2NTUzNSBmDQowMDAwMDAwMTA0IDY1NTM1IGYNCjAwMDAw
MDAxMDUgNjU1MzUgZg0KMDAwMDAwMDEwNiA2NTUzNSBmDQowMDAwMDAwMTA3IDY1NTM1IGYNCjAw
MDAwMDAxMDggNjU1MzUgZg0KMDAwMDAwMDEwOSA2NTUzNSBmDQowMDAwMDAwMTEwIDY1NTM1IGYN
CjAwMDAwMDAxMTEgNjU1MzUgZg0KMDAwMDAwMDExMiA2NTUzNSBmDQowMDAwMDAwMTEzIDY1NTM1
IGYNCjAwMDAwMDAxMTQgNjU1MzUgZg0KMDAwMDAwMDExNSA2NTUzNSBmDQowMDAwMDAwMTE2IDY1
NTM1IGYNCjAwMDAwMDAxMTcgNjU1MzUgZg0KMDAwMDAwMDExOCA2NTUzNSBmDQowMDAwMDAwMTE5
IDY1NTM1IGYNCjAwMDAwMDAxMjAgNjU1MzUgZg0KMDAwMDAwMDEyMSA2NTUzNSBmDQowMDAwMDAw
MTIyIDY1NTM1IGYNCjAwMDAwMDAxMjMgNjU1MzUgZg0KMDAwMDAwMDEyNCA2NTUzNSBmDQowMDAw
MDAwMTI1IDY1NTM1IGYNCjAwMDAwMDAxMjYgNjU1MzUgZg0KMDAwMDAwMDEyNyA2NTUzNSBmDQow
MDAwMDAwMTI4IDY1NTM1IGYNCjAwMDAwMDAxMjkgNjU1MzUgZg0KMDAwMDAwMDEzMCA2NTUzNSBm
DQowMDAwMDAwMTMxIDY1NTM1IGYNCjAwMDAwMDAxMzIgNjU1MzUgZg0KMDAwMDAwMDEzMyA2NTUz
NSBmDQowMDAwMDAwMTM0IDY1NTM1IGYNCjAwMDAwMDAxMzUgNjU1MzUgZg0KMDAwMDAwMDEzNiA2
NTUzNSBmDQowMDAwMDAwMTM3IDY1NTM1IGYNCjAwMDAwMDAxMzggNjU1MzUgZg0KMDAwMDAwMDEz
OSA2NTUzNSBmDQowMDAwMDAwMTQwIDY1NTM1IGYNCjAwMDAwMDAxNDEgNjU1MzUgZg0KMDAwMDAw
MDE0MiA2NTUzNSBmDQowMDAwMDAwMTQzIDY1NTM1IGYNCjAwMDAwMDAxNDQgNjU1MzUgZg0KMDAw
MDAwMDE0NSA2NTUzNSBmDQowMDAwMDAwMTQ2IDY1NTM1IGYNCjAwMDAwMDAxNDcgNjU1MzUgZg0K
MDAwMDAwMDE0OCA2NTUzNSBmDQowMDAwMDAwMTQ5IDY1NTM1IGYNCjAwMDAwMDAxNTAgNjU1MzUg
Zg0KMDAwMDAwMDE1MSA2NTUzNSBmDQowMDAwMDAwMTUyIDY1NTM1IGYNCjAwMDAwMDAxNTMgNjU1
MzUgZg0KMDAwMDAwMDE1NCA2NTUzNSBmDQowMDAwMDAwMTU1IDY1NTM1IGYNCjAwMDAwMDAxNTYg
NjU1MzUgZg0KMDAwMDAwMDE1NyA2NTUzNSBmDQowMDAwMDAwMTU4IDY1NTM1IGYNCjAwMDAwMDAx
NTkgNjU1MzUgZg0KMDAwMDAwMDE2MCA2NTUzNSBmDQowMDAwMDAwMTYxIDY1NTM1IGYNCjAwMDAw
MDAxNjIgNjU1MzUgZg0KMDAwMDAwMDE2MyA2NTUzNSBmDQowMDAwMDAwMTY0IDY1NTM1IGYNCjAw
MDAwMDAxNjUgNjU1MzUgZg0KMDAwMDAwMDE2NiA2NTUzNSBmDQowMDAwMDAwMTY3IDY1NTM1IGYN
CjAwMDAwMDAxNjggNjU1MzUgZg0KMDAwMDAwMDE2OSA2NTUzNSBmDQowMDAwMDAwMTcwIDY1NTM1
IGYNCjAwMDAwMDAxNzEgNjU1MzUgZg0KMDAwMDAwMDE3MiA2NTUzNSBmDQowMDAwMDAwMTczIDY1
NTM1IGYNCjAwMDAwMDAxNzQgNjU1MzUgZg0KMDAwMDAwMDE3NSA2NTUzNSBmDQowMDAwMDAwMTc2
IDY1NTM1IGYNCjAwMDAwMDAxNzcgNjU1MzUgZg0KMDAwMDAwMDE3OCA2NTUzNSBmDQowMDAwMDAw
MTc5IDY1NTM1IGYNCjAwMDAwMDAxODAgNjU1MzUgZg0KMDAwMDAwMDE4MSA2NTUzNSBmDQowMDAw
MDAwMTgyIDY1NTM1IGYNCjAwMDAwMDAxODMgNjU1MzUgZg0KMDAwMDAwMDE4NCA2NTUzNSBmDQow
MDAwMDAwMTg1IDY1NTM1IGYNCjAwMDAwMDAxODYgNjU1MzUgZg0KMDAwMDAwMDE4NyA2NTUzNSBm
DQowMDAwMDAwMTg4IDY1NTM1IGYNCjAwMDAwMDAxODkgNjU1MzUgZg0KMDAwMDAwMDE5MCA2NTUz
NSBmDQowMDAwMDAwMTkxIDY1NTM1IGYNCjAwMDAwMDAxOTIgNjU1MzUgZg0KMDAwMDAwMDE5MyA2
NTUzNSBmDQowMDAwMDAwMTk0IDY1NTM1IGYNCjAwMDAwMDAxOTUgNjU1MzUgZg0KMDAwMDAwMDE5
NiA2NTUzNSBmDQowMDAwMDAwMTk3IDY1NTM1IGYNCjAwMDAwMDAxOTggNjU1MzUgZg0KMDAwMDAw
MDE5OSA2NTUzNSBmDQowMDAwMDAwMjAwIDY1NTM1IGYNCjAwMDAwMDAyMDEgNjU1MzUgZg0KMDAw
MDAwMDIwMiA2NTUzNSBmDQowMDAwMDAwMjAzIDY1NTM1IGYNCjAwMDAwMDAyMDQgNjU1MzUgZg0K
MDAwMDAwMDIwNSA2NTUzNSBmDQowMDAwMDAwMjA2IDY1NTM1IGYNCjAwMDAwMDAyMDcgNjU1MzUg
Zg0KMDAwMDAwMDIwOCA2NTUzNSBmDQowMDAwMDAwMjA5IDY1NTM1IGYNCjAwMDAwMDAyMTAgNjU1
MzUgZg0KMDAwMDAwMDIxMSA2NTUzNSBmDQowMDAwMDAwMjEyIDY1NTM1IGYNCjAwMDAwMDAyMTMg
NjU1MzUgZg0KMDAwMDAwMDIxNCA2NTUzNSBmDQowMDAwMDAwMjE1IDY1NTM1IGYNCjAwMDAwMDAy
MTYgNjU1MzUgZg0KMDAwMDAwMDIxNyA2NTUzNSBmDQowMDAwMDAwMjE4IDY1NTM1IGYNCjAwMDAw
MDAyMTkgNjU1MzUgZg0KMDAwMDAwMDIyMCA2NTUzNSBmDQowMDAwMDAwMjIxIDY1NTM1IGYNCjAw
MDAwMDAyMjIgNjU1MzUgZg0KMDAwMDAwMDIyMyA2NTUzNSBmDQowMDAwMDAwMjI0IDY1NTM1IGYN
CjAwMDAwMDAyMjUgNjU1MzUgZg0KMDAwMDAwMDIyNiA2NTUzNSBmDQowMDAwMDAwMjI3IDY1NTM1
IGYNCjAwMDAwMDAyMjggNjU1MzUgZg0KMDAwMDAwMDIyOSA2NTUzNSBmDQowMDAwMDAwMjMwIDY1
NTM1IGYNCjAwMDAwMDAyMzEgNjU1MzUgZg0KMDAwMDAwMDIzMiA2NTUzNSBmDQowMDAwMDAwMjMz
IDY1NTM1IGYNCjAwMDAwMDAyMzQgNjU1MzUgZg0KMDAwMDAwMDIzNSA2NTUzNSBmDQowMDAwMDAw
MjM2IDY1NTM1IGYNCjAwMDAwMDAyMzcgNjU1MzUgZg0KMDAwMDAwMDIzOCA2NTUzNSBmDQowMDAw
MDAwMjM5IDY1NTM1IGYNCjAwMDAwMDAyNDAgNjU1MzUgZg0KMDAwMDAwMDI0MSA2NTUzNSBmDQow
MDAwMDAwMjQyIDY1NTM1IGYNCjAwMDAwMDAyNDMgNjU1MzUgZg0KMDAwMDAwMDI0NCA2NTUzNSBm
DQowMDAwMDAwMjQ1IDY1NTM1IGYNCjAwMDAwMDAyNDYgNjU1MzUgZg0KMDAwMDAwMDI0NyA2NTUz
NSBmDQowMDAwMDAwMjQ4IDY1NTM1IGYNCjAwMDAwMDAyNDkgNjU1MzUgZg0KMDAwMDAwMDI1MCA2
NTUzNSBmDQowMDAwMDAwMjUxIDY1NTM1IGYNCjAwMDAwMDAyNTIgNjU1MzUgZg0KMDAwMDAwMDI1
MyA2NTUzNSBmDQowMDAwMDAwMjU0IDY1NTM1IGYNCjAwMDAwMDAyNTUgNjU1MzUgZg0KMDAwMDAw
MDI1NiA2NTUzNSBmDQowMDAwMDAwMjU3IDY1NTM1IGYNCjAwMDAwMDAyNTggNjU1MzUgZg0KMDAw
MDAwMDI1OSA2NTUzNSBmDQowMDAwMDAwMjYwIDY1NTM1IGYNCjAwMDAwMDAyNjEgNjU1MzUgZg0K
MDAwMDAwMDI2MiA2NTUzNSBmDQowMDAwMDAwMjYzIDY1NTM1IGYNCjAwMDAwMDAyNjQgNjU1MzUg
Zg0KMDAwMDAwMDI2NSA2NTUzNSBmDQowMDAwMDAwMjY2IDY1NTM1IGYNCjAwMDAwMDAyNjcgNjU1
MzUgZg0KMDAwMDAwMDI2OCA2NTUzNSBmDQowMDAwMDAwMjY5IDY1NTM1IGYNCjAwMDAwMDAyNzAg
NjU1MzUgZg0KMDAwMDAwMDI3MSA2NTUzNSBmDQowMDAwMDAwMjcyIDY1NTM1IGYNCjAwMDAwMDAy
NzMgNjU1MzUgZg0KMDAwMDAwMDI3NCA2NTUzNSBmDQowMDAwMDAwMjc1IDY1NTM1IGYNCjAwMDAw
MDAyNzYgNjU1MzUgZg0KMDAwMDAwMDI3NyA2NTUzNSBmDQowMDAwMDAwMjc4IDY1NTM1IGYNCjAw
MDAwMDAyNzkgNjU1MzUgZg0KMDAwMDAwMDI4MCA2NTUzNSBmDQowMDAwMDAwMjgxIDY1NTM1IGYN
CjAwMDAwMDAyODIgNjU1MzUgZg0KMDAwMDAwMDI4MyA2NTUzNSBmDQowMDAwMDAwMjg0IDY1NTM1
IGYNCjAwMDAwMDAyODUgNjU1MzUgZg0KMDAwMDAwMDI4NiA2NTUzNSBmDQowMDAwMDAwMjg3IDY1
NTM1IGYNCjAwMDAwMDAyODggNjU1MzUgZg0KMDAwMDAwMDI4OSA2NTUzNSBmDQowMDAwMDAwMjkw
IDY1NTM1IGYNCjAwMDAwMDAyOTEgNjU1MzUgZg0KMDAwMDAwMDI5MiA2NTUzNSBmDQowMDAwMDAw
MjkzIDY1NTM1IGYNCjAwMDAwMDAyOTQgNjU1MzUgZg0KMDAwMDAwMDI5NSA2NTUzNSBmDQowMDAw
MDAwMjk2IDY1NTM1IGYNCjAwMDAwMDAyOTcgNjU1MzUgZg0KMDAwMDAwMDI5OCA2NTUzNSBmDQow
MDAwMDAwMjk5IDY1NTM1IGYNCjAwMDAwMDAzMDAgNjU1MzUgZg0KMDAwMDAwMDMwMSA2NTUzNSBm
DQowMDAwMDAwMzAyIDY1NTM1IGYNCjAwMDAwMDAzMDMgNjU1MzUgZg0KMDAwMDAwMDMwNCA2NTUz
NSBmDQowMDAwMDAwMzA1IDY1NTM1IGYNCjAwMDAwMDAzMDYgNjU1MzUgZg0KMDAwMDAwMDMwNyA2
NTUzNSBmDQowMDAwMDAwMzA4IDY1NTM1IGYNCjAwMDAwMDAzMDkgNjU1MzUgZg0KMDAwMDAwMDMx
MCA2NTUzNSBmDQowMDAwMDAwMzExIDY1NTM1IGYNCjAwMDAwMDAzMTIgNjU1MzUgZg0KMDAwMDAw
MDMxMyA2NTUzNSBmDQowMDAwMDAwMzE0IDY1NTM1IGYNCjAwMDAwMDAzMTUgNjU1MzUgZg0KMDAw
MDAwMDMxNiA2NTUzNSBmDQowMDAwMDAwMzE3IDY1NTM1IGYNCjAwMDAwMDAzMTggNjU1MzUgZg0K
MDAwMDAwMDMxOSA2NTUzNSBmDQowMDAwMDAwMzIwIDY1NTM1IGYNCjAwMDAwMDAzMjEgNjU1MzUg
Zg0KMDAwMDAwMDMyMiA2NTUzNSBmDQowMDAwMDAwMzIzIDY1NTM1IGYNCjAwMDAwMDAzMjQgNjU1
MzUgZg0KMDAwMDAwMDMyNSA2NTUzNSBmDQowMDAwMDAwMzI2IDY1NTM1IGYNCjAwMDAwMDAzMjcg
NjU1MzUgZg0KMDAwMDAwMDMyOCA2NTUzNSBmDQowMDAwMDAwMzI5IDY1NTM1IGYNCjAwMDAwMDAz
MzAgNjU1MzUgZg0KMDAwMDAwMDMzMSA2NTUzNSBmDQowMDAwMDAwMzMyIDY1NTM1IGYNCjAwMDAw
MDAzMzMgNjU1MzUgZg0KMDAwMDAwMDMzNCA2NTUzNSBmDQowMDAwMDAwMzM1IDY1NTM1IGYNCjAw
MDAwMDAzMzYgNjU1MzUgZg0KMDAwMDAwMDMzNyA2NTUzNSBmDQowMDAwMDAwMzM4IDY1NTM1IGYN
CjAwMDAwMDAzMzkgNjU1MzUgZg0KMDAwMDAwMDM0MCA2NTUzNSBmDQowMDAwMDAwMzQxIDY1NTM1
IGYNCjAwMDAwMDAzNDIgNjU1MzUgZg0KMDAwMDAwMDM0MyA2NTUzNSBmDQowMDAwMDAwMzQ0IDY1
NTM1IGYNCjAwMDAwMDAzNDUgNjU1MzUgZg0KMDAwMDAwMDM0NiA2NTUzNSBmDQowMDAwMDAwMzQ3
IDY1NTM1IGYNCjAwMDAwMDAzNDggNjU1MzUgZg0KMDAwMDAwMDM0OSA2NTUzNSBmDQowMDAwMDAw
MzUwIDY1NTM1IGYNCjAwMDAwMDAzNTEgNjU1MzUgZg0KMDAwMDAwMDM1MiA2NTUzNSBmDQowMDAw
MDAwMzUzIDY1NTM1IGYNCjAwMDAwMDAzNTQgNjU1MzUgZg0KMDAwMDAwMDM1NSA2NTUzNSBmDQow
MDAwMDAwMzU2IDY1NTM1IGYNCjAwMDAwMDAzNTcgNjU1MzUgZg0KMDAwMDAwMDM1OCA2NTUzNSBm
DQowMDAwMDAwMzU5IDY1NTM1IGYNCjAwMDAwMDAzNjAgNjU1MzUgZg0KMDAwMDAwMDM2MSA2NTUz
NSBmDQowMDAwMDAwMzYyIDY1NTM1IGYNCjAwMDAwMDAzNjMgNjU1MzUgZg0KMDAwMDAwMDM2NCA2
NTUzNSBmDQowMDAwMDAwMzY1IDY1NTM1IGYNCjAwMDAwMDAzNjYgNjU1MzUgZg0KMDAwMDAwMDM2
NyA2NTUzNSBmDQowMDAwMDAwMzY4IDY1NTM1IGYNCjAwMDAwMDAzNjkgNjU1MzUgZg0KMDAwMDAw
MDM3MCA2NTUzNSBmDQowMDAwMDAwMzcxIDY1NTM1IGYNCjAwMDAwMDAzNzIgNjU1MzUgZg0KMDAw
MDAwMDM3MyA2NTUzNSBmDQowMDAwMDAwMzc0IDY1NTM1IGYNCjAwMDAwMDAzNzUgNjU1MzUgZg0K
MDAwMDAwMDM3NiA2NTUzNSBmDQowMDAwMDAwMzc3IDY1NTM1IGYNCjAwMDAwMDAzNzggNjU1MzUg
Zg0KMDAwMDAwMDM3OSA2NTUzNSBmDQowMDAwMDAwMzgwIDY1NTM1IGYNCjAwMDAwMDAzODEgNjU1
MzUgZg0KMDAwMDAwMDM4MiA2NTUzNSBmDQowMDAwMDAwMzgzIDY1NTM1IGYNCjAwMDAwMDAzODQg
NjU1MzUgZg0KMDAwMDAwMDM4NSA2NTUzNSBmDQowMDAwMDAwMzg2IDY1NTM1IGYNCjAwMDAwMDAz
ODcgNjU1MzUgZg0KMDAwMDAwMDM4OCA2NTUzNSBmDQowMDAwMDAwMzg5IDY1NTM1IGYNCjAwMDAw
MDAzOTAgNjU1MzUgZg0KMDAwMDAwMDM5MSA2NTUzNSBmDQowMDAwMDAwMzkyIDY1NTM1IGYNCjAw
MDAwMDAzOTMgNjU1MzUgZg0KMDAwMDAwMDM5NCA2NTUzNSBmDQowMDAwMDAwMzk1IDY1NTM1IGYN
CjAwMDAwMDAzOTYgNjU1MzUgZg0KMDAwMDAwMDM5NyA2NTUzNSBmDQowMDAwMDAwMzk4IDY1NTM1
IGYNCjAwMDAwMDAzOTkgNjU1MzUgZg0KMDAwMDAwMDQwMCA2NTUzNSBmDQowMDAwMDAwNDAxIDY1
NTM1IGYNCjAwMDAwMDA0MDIgNjU1MzUgZg0KMDAwMDAwMDQwMyA2NTUzNSBmDQowMDAwMDAwNDA0
IDY1NTM1IGYNCjAwMDAwMDA0MDUgNjU1MzUgZg0KMDAwMDAwMDQwNiA2NTUzNSBmDQowMDAwMDAw
NDA3IDY1NTM1IGYNCjAwMDAwMDA0MDggNjU1MzUgZg0KMDAwMDAwMDQwOSA2NTUzNSBmDQowMDAw
MDAwNDEwIDY1NTM1IGYNCjAwMDAwMDA0MTEgNjU1MzUgZg0KMDAwMDAwMDQxMiA2NTUzNSBmDQow
MDAwMDAwNDEzIDY1NTM1IGYNCjAwMDAwMDA0MTQgNjU1MzUgZg0KMDAwMDAwMDQxNSA2NTUzNSBm
DQowMDAwMDAwNDE2IDY1NTM1IGYNCjAwMDAwMDA0MTcgNjU1MzUgZg0KMDAwMDAwMDQxOCA2NTUz
NSBmDQowMDAwMDAwNDE5IDY1NTM1IGYNCjAwMDAwMDA0MjAgNjU1MzUgZg0KMDAwMDAwMDQyMSA2
NTUzNSBmDQowMDAwMDAwNDIyIDY1NTM1IGYNCjAwMDAwMDA0MjMgNjU1MzUgZg0KMDAwMDAwMDQy
NCA2NTUzNSBmDQowMDAwMDAwNDI1IDY1NTM1IGYNCjAwMDAwMDA0MjYgNjU1MzUgZg0KMDAwMDAw
MDQyNyA2NTUzNSBmDQowMDAwMDAwNDI4IDY1NTM1IGYNCjAwMDAwMDA0MjkgNjU1MzUgZg0KMDAw
MDAwMDQzMCA2NTUzNSBmDQowMDAwMDAwNDMxIDY1NTM1IGYNCjAwMDAwMDA0MzIgNjU1MzUgZg0K
MDAwMDAwMDQzMyA2NTUzNSBmDQowMDAwMDAwNDM0IDY1NTM1IGYNCjAwMDAwMDA0MzUgNjU1MzUg
Zg0KMDAwMDAwMDQzNiA2NTUzNSBmDQowMDAwMDAwNDM3IDY1NTM1IGYNCjAwMDAwMDA0MzggNjU1
MzUgZg0KMDAwMDAwMDQzOSA2NTUzNSBmDQowMDAwMDAwNDQwIDY1NTM1IGYNCjAwMDAwMDA0NDEg
NjU1MzUgZg0KMDAwMDAwMDQ0MiA2NTUzNSBmDQowMDAwMDAwNDQzIDY1NTM1IGYNCjAwMDAwMDA0
NDQgNjU1MzUgZg0KMDAwMDAwMDQ0NSA2NTUzNSBmDQowMDAwMDAwNDQ2IDY1NTM1IGYNCjAwMDAw
MDA0NDcgNjU1MzUgZg0KMDAwMDAwMDQ0OCA2NTUzNSBmDQowMDAwMDAwNDQ5IDY1NTM1IGYNCjAw
MDAwMDA0NTAgNjU1MzUgZg0KMDAwMDAwMDQ1MSA2NTUzNSBmDQowMDAwMDAwNDUyIDY1NTM1IGYN
CjAwMDAwMDA0NTMgNjU1MzUgZg0KMDAwMDAwMDQ1NCA2NTUzNSBmDQowMDAwMDAwNDU1IDY1NTM1
IGYNCjAwMDAwMDA0NTYgNjU1MzUgZg0KMDAwMDAwMDQ1NyA2NTUzNSBmDQowMDAwMDAwNDU4IDY1
NTM1IGYNCjAwMDAwMDA0NTkgNjU1MzUgZg0KMDAwMDAwMDQ2MCA2NTUzNSBmDQowMDAwMDAwNDYx
IDY1NTM1IGYNCjAwMDAwMDA0NjIgNjU1MzUgZg0KMDAwMDAwMDQ2MyA2NTUzNSBmDQowMDAwMDAw
NDY0IDY1NTM1IGYNCjAwMDAwMDA0NjUgNjU1MzUgZg0KMDAwMDAwMDQ2NiA2NTUzNSBmDQowMDAw
MDAwNDY3IDY1NTM1IGYNCjAwMDAwMDA0NjggNjU1MzUgZg0KMDAwMDAwMDQ2OSA2NTUzNSBmDQow
MDAwMDAwNDcwIDY1NTM1IGYNCjAwMDAwMDA0NzEgNjU1MzUgZg0KMDAwMDAwMDQ3MiA2NTUzNSBm
DQowMDAwMDAwNDczIDY1NTM1IGYNCjAwMDAwMDA0NzQgNjU1MzUgZg0KMDAwMDAwMDQ3NSA2NTUz
NSBmDQowMDAwMDAwNDc2IDY1NTM1IGYNCjAwMDAwMDA0NzcgNjU1MzUgZg0KMDAwMDAwMDQ3OCA2
NTUzNSBmDQowMDAwMDAwNDc5IDY1NTM1IGYNCjAwMDAwMDA0ODAgNjU1MzUgZg0KMDAwMDAwMDQ4
MSA2NTUzNSBmDQowMDAwMDAwNDgyIDY1NTM1IGYNCjAwMDAwMDA0ODMgNjU1MzUgZg0KMDAwMDAw
MDQ4NCA2NTUzNSBmDQowMDAwMDAwNDg1IDY1NTM1IGYNCjAwMDAwMDA0ODYgNjU1MzUgZg0KMDAw
MDAwMDQ4NyA2NTUzNSBmDQowMDAwMDAwNDg4IDY1NTM1IGYNCjAwMDAwMDA0ODkgNjU1MzUgZg0K
MDAwMDAwMDQ5MCA2NTUzNSBmDQowMDAwMDAwNDkxIDY1NTM1IGYNCjAwMDAwMDA0OTIgNjU1MzUg
Zg0KMDAwMDAwMDQ5MyA2NTUzNSBmDQowMDAwMDAwNDk0IDY1NTM1IGYNCjAwMDAwMDA0OTUgNjU1
MzUgZg0KMDAwMDAwMDQ5NiA2NTUzNSBmDQowMDAwMDAwNDk3IDY1NTM1IGYNCjAwMDAwMDA0OTgg
NjU1MzUgZg0KMDAwMDAwMDQ5OSA2NTUzNSBmDQowMDAwMDAwNTAwIDY1NTM1IGYNCjAwMDAwMDA1
MDEgNjU1MzUgZg0KMDAwMDAwMDUwMiA2NTUzNSBmDQowMDAwMDAwNTAzIDY1NTM1IGYNCjAwMDAw
MDA1MDQgNjU1MzUgZg0KMDAwMDAwMDUwNSA2NTUzNSBmDQowMDAwMDAwNTA2IDY1NTM1IGYNCjAw
MDAwMDA1MDcgNjU1MzUgZg0KMDAwMDAwMDUwOCA2NTUzNSBmDQowMDAwMDAwNTA5IDY1NTM1IGYN
CjAwMDAwMDA1MTAgNjU1MzUgZg0KMDAwMDAwMDUxMSA2NTUzNSBmDQowMDAwMDAwNTEyIDY1NTM1
IGYNCjAwMDAwMDA1MTMgNjU1MzUgZg0KMDAwMDAwMDUxNCA2NTUzNSBmDQowMDAwMDAwNTE1IDY1
NTM1IGYNCjAwMDAwMDA1MTYgNjU1MzUgZg0KMDAwMDAwMDUxNyA2NTUzNSBmDQowMDAwMDAwNTE4
IDY1NTM1IGYNCjAwMDAwMDA1MTkgNjU1MzUgZg0KMDAwMDAwMDUyMCA2NTUzNSBmDQowMDAwMDAw
NTIxIDY1NTM1IGYNCjAwMDAwMDA1MjIgNjU1MzUgZg0KMDAwMDAwMDUyMyA2NTUzNSBmDQowMDAw
MDAwNTI0IDY1NTM1IGYNCjAwMDAwMDA1MjUgNjU1MzUgZg0KMDAwMDAwMDUyNiA2NTUzNSBmDQow
MDAwMDAwNTI3IDY1NTM1IGYNCjAwMDAwMDA1MjggNjU1MzUgZg0KMDAwMDAwMDUyOSA2NTUzNSBm
DQowMDAwMDAwNTMwIDY1NTM1IGYNCjAwMDAwMDA1MzEgNjU1MzUgZg0KMDAwMDAwMDUzMiA2NTUz
NSBmDQowMDAwMDAwNTMzIDY1NTM1IGYNCjAwMDAwMDA1MzQgNjU1MzUgZg0KMDAwMDAwMDUzNSA2
NTUzNSBmDQowMDAwMDAwNTM2IDY1NTM1IGYNCjAwMDAwMDA1MzcgNjU1MzUgZg0KMDAwMDAwMDUz
OCA2NTUzNSBmDQowMDAwMDAwNTM5IDY1NTM1IGYNCjAwMDAwMDA1NDAgNjU1MzUgZg0KMDAwMDAw
MDU0MSA2NTUzNSBmDQowMDAwMDAwNTQyIDY1NTM1IGYNCjAwMDAwMDA1NDMgNjU1MzUgZg0KMDAw
MDAwMDU0NCA2NTUzNSBmDQowMDAwMDAwNTQ1IDY1NTM1IGYNCjAwMDAwMDA1NDYgNjU1MzUgZg0K
MDAwMDAwMDU0NyA2NTUzNSBmDQowMDAwMDAwNTQ4IDY1NTM1IGYNCjAwMDAwMDA1NDkgNjU1MzUg
Zg0KMDAwMDAwMDU1MCA2NTUzNSBmDQowMDAwMDAwNTUxIDY1NTM1IGYNCjAwMDAwMDA1NTIgNjU1
MzUgZg0KMDAwMDAwMDU1MyA2NTUzNSBmDQowMDAwMDAwNTU0IDY1NTM1IGYNCjAwMDAwMDA1NTUg
NjU1MzUgZg0KMDAwMDAwMDU1NiA2NTUzNSBmDQowMDAwMDAwNTU3IDY1NTM1IGYNCjAwMDAwMDA1
NTggNjU1MzUgZg0KMDAwMDAwMDU1OSA2NTUzNSBmDQowMDAwMDAwNTYwIDY1NTM1IGYNCjAwMDAw
MDA1NjEgNjU1MzUgZg0KMDAwMDAwMDU2MiA2NTUzNSBmDQowMDAwMDAwNTYzIDY1NTM1IGYNCjAw
MDAwMDA1NjQgNjU1MzUgZg0KMDAwMDAwMDU2NSA2NTUzNSBmDQowMDAwMDAwNTY2IDY1NTM1IGYN
CjAwMDAwMDA1NjcgNjU1MzUgZg0KMDAwMDAwMDU2OCA2NTUzNSBmDQowMDAwMDAwNTY5IDY1NTM1
IGYNCjAwMDAwMDA1NzAgNjU1MzUgZg0KMDAwMDAwMDU3MSA2NTUzNSBmDQowMDAwMDAwNTcyIDY1
NTM1IGYNCjAwMDAwMDA1NzMgNjU1MzUgZg0KMDAwMDAwMDU3NCA2NTUzNSBmDQowMDAwMDAwNTc1
IDY1NTM1IGYNCjAwMDAwMDA1NzYgNjU1MzUgZg0KMDAwMDAwMDU3NyA2NTUzNSBmDQowMDAwMDAw
NTc4IDY1NTM1IGYNCjAwMDAwMDA1NzkgNjU1MzUgZg0KMDAwMDAwMDU4MCA2NTUzNSBmDQowMDAw
MDAwNTgxIDY1NTM1IGYNCjAwMDAwMDA1ODIgNjU1MzUgZg0KMDAwMDAwMDU4MyA2NTUzNSBmDQow
MDAwMDAwNTg0IDY1NTM1IGYNCjAwMDAwMDA1ODUgNjU1MzUgZg0KMDAwMDAwMDU4NiA2NTUzNSBm
DQowMDAwMDAwNTg3IDY1NTM1IGYNCjAwMDAwMDA1ODggNjU1MzUgZg0KMDAwMDAwMDU4OSA2NTUz
NSBmDQowMDAwMDAwNTkwIDY1NTM1IGYNCjAwMDAwMDA1OTEgNjU1MzUgZg0KMDAwMDAwMDU5MiA2
NTUzNSBmDQowMDAwMDAwNTkzIDY1NTM1IGYNCjAwMDAwMDA1OTQgNjU1MzUgZg0KMDAwMDAwMDU5
NSA2NTUzNSBmDQowMDAwMDAwNTk2IDY1NTM1IGYNCjAwMDAwMDA1OTcgNjU1MzUgZg0KMDAwMDAw
MDU5OCA2NTUzNSBmDQowMDAwMDAwNTk5IDY1NTM1IGYNCjAwMDAwMDA2MDAgNjU1MzUgZg0KMDAw
MDAwMDYwMSA2NTUzNSBmDQowMDAwMDAwNjAyIDY1NTM1IGYNCjAwMDAwMDA2MDMgNjU1MzUgZg0K
MDAwMDAwMDYwNCA2NTUzNSBmDQowMDAwMDAwNjA1IDY1NTM1IGYNCjAwMDAwMDA2MDYgNjU1MzUg
Zg0KMDAwMDAwMDYwNyA2NTUzNSBmDQowMDAwMDAwNjA4IDY1NTM1IGYNCjAwMDAwMDA2MDkgNjU1
MzUgZg0KMDAwMDAwMDYxMCA2NTUzNSBmDQowMDAwMDAwNjExIDY1NTM1IGYNCjAwMDAwMDA2MTIg
NjU1MzUgZg0KMDAwMDAwMDYxMyA2NTUzNSBmDQowMDAwMDAwNjE0IDY1NTM1IGYNCjAwMDAwMDA2
MTUgNjU1MzUgZg0KMDAwMDAwMDYxNiA2NTUzNSBmDQowMDAwMDAwNjE3IDY1NTM1IGYNCjAwMDAw
MDA2MTggNjU1MzUgZg0KMDAwMDAwMDYxOSA2NTUzNSBmDQowMDAwMDAwNjIwIDY1NTM1IGYNCjAw
MDAwMDA2MjEgNjU1MzUgZg0KMDAwMDAwMDYyMiA2NTUzNSBmDQowMDAwMDAwNjIzIDY1NTM1IGYN
CjAwMDAwMDA2MjQgNjU1MzUgZg0KMDAwMDAwMDYyNSA2NTUzNSBmDQowMDAwMDAwNjI2IDY1NTM1
IGYNCjAwMDAwMDA2MjcgNjU1MzUgZg0KMDAwMDAwMDYyOCA2NTUzNSBmDQowMDAwMDAwNjI5IDY1
NTM1IGYNCjAwMDAwMDA2MzAgNjU1MzUgZg0KMDAwMDAwMDYzMSA2NTUzNSBmDQowMDAwMDAwNjMy
IDY1NTM1IGYNCjAwMDAwMDA2MzMgNjU1MzUgZg0KMDAwMDAwMDYzNCA2NTUzNSBmDQowMDAwMDAw
NjM1IDY1NTM1IGYNCjAwMDAwMDA2MzYgNjU1MzUgZg0KMDAwMDAwMDYzNyA2NTUzNSBmDQowMDAw
MDAwNjM4IDY1NTM1IGYNCjAwMDAwMDA2MzkgNjU1MzUgZg0KMDAwMDAwMDY0MCA2NTUzNSBmDQow
MDAwMDAwNjQxIDY1NTM1IGYNCjAwMDAwMDA2NDIgNjU1MzUgZg0KMDAwMDAwMDY0MyA2NTUzNSBm
DQowMDAwMDAwNjQ0IDY1NTM1IGYNCjAwMDAwMDA2NDUgNjU1MzUgZg0KMDAwMDAwMDY0NiA2NTUz
NSBmDQowMDAwMDAwNjQ3IDY1NTM1IGYNCjAwMDAwMDA2NDggNjU1MzUgZg0KMDAwMDAwMDY0OSA2
NTUzNSBmDQowMDAwMDAwNjUwIDY1NTM1IGYNCjAwMDAwMDA2NTEgNjU1MzUgZg0KMDAwMDAwMDY1
MiA2NTUzNSBmDQowMDAwMDAwNjUzIDY1NTM1IGYNCjAwMDAwMDA2NTQgNjU1MzUgZg0KMDAwMDAw
MDY1NSA2NTUzNSBmDQowMDAwMDAwNjU2IDY1NTM1IGYNCjAwMDAwMDA2NTcgNjU1MzUgZg0KMDAw
MDAwMDY1OCA2NTUzNSBmDQowMDAwMDAwNjU5IDY1NTM1IGYNCjAwMDAwMDA2NjAgNjU1MzUgZg0K
MDAwMDAwMDY2MSA2NTUzNSBmDQowMDAwMDAwNjYyIDY1NTM1IGYNCjAwMDAwMDA2NjMgNjU1MzUg
Zg0KMDAwMDAwMDY2NCA2NTUzNSBmDQowMDAwMDAwNjY1IDY1NTM1IGYNCjAwMDAwMDA2NjYgNjU1
MzUgZg0KMDAwMDAwMDY2NyA2NTUzNSBmDQowMDAwMDAwNjY4IDY1NTM1IGYNCjAwMDAwMDA2Njkg
NjU1MzUgZg0KMDAwMDAwMDY3MCA2NTUzNSBmDQowMDAwMDAwNjcxIDY1NTM1IGYNCjAwMDAwMDA2
NzIgNjU1MzUgZg0KMDAwMDAwMDY3MyA2NTUzNSBmDQowMDAwMDAwNjc0IDY1NTM1IGYNCjAwMDAw
MDA2NzUgNjU1MzUgZg0KMDAwMDAwMDY3NiA2NTUzNSBmDQowMDAwMDAwNjc3IDY1NTM1IGYNCjAw
MDAwMDA2NzggNjU1MzUgZg0KMDAwMDAwMDY3OSA2NTUzNSBmDQowMDAwMDAwNjgwIDY1NTM1IGYN
CjAwMDAwMDA2ODEgNjU1MzUgZg0KMDAwMDAwMDY4MiA2NTUzNSBmDQowMDAwMDAwNjgzIDY1NTM1
IGYNCjAwMDAwMDA2ODQgNjU1MzUgZg0KMDAwMDAwMDY4NSA2NTUzNSBmDQowMDAwMDAwNjg2IDY1
NTM1IGYNCjAwMDAwMDA2ODcgNjU1MzUgZg0KMDAwMDAwMDY4OCA2NTUzNSBmDQowMDAwMDAwNjg5
IDY1NTM1IGYNCjAwMDAwMDA2OTAgNjU1MzUgZg0KMDAwMDAwMDY5MSA2NTUzNSBmDQowMDAwMDAw
NjkyIDY1NTM1IGYNCjAwMDAwMDA2OTMgNjU1MzUgZg0KMDAwMDAwMDY5NCA2NTUzNSBmDQowMDAw
MDAwNjk1IDY1NTM1IGYNCjAwMDAwMDA2OTYgNjU1MzUgZg0KMDAwMDAwMDY5NyA2NTUzNSBmDQow
MDAwMDAwNjk4IDY1NTM1IGYNCjAwMDAwMDA2OTkgNjU1MzUgZg0KMDAwMDAwMDcwMCA2NTUzNSBm
DQowMDAwMDAwNzAxIDY1NTM1IGYNCjAwMDAwMDA3MDIgNjU1MzUgZg0KMDAwMDAwMDcwMyA2NTUz
NSBmDQowMDAwMDAwNzA0IDY1NTM1IGYNCjAwMDAwMDA3MDUgNjU1MzUgZg0KMDAwMDAwMDcwNiA2
NTUzNSBmDQowMDAwMDAwNzA3IDY1NTM1IGYNCjAwMDAwMDA3MDggNjU1MzUgZg0KMDAwMDAwMDcw
OSA2NTUzNSBmDQowMDAwMDAwNzEwIDY1NTM1IGYNCjAwMDAwMDA3MTEgNjU1MzUgZg0KMDAwMDAw
MDcxMiA2NTUzNSBmDQowMDAwMDAwNzEzIDY1NTM1IGYNCjAwMDAwMDA3MTQgNjU1MzUgZg0KMDAw
MDAwMDcxNSA2NTUzNSBmDQowMDAwMDAwNzE2IDY1NTM1IGYNCjAwMDAwMDA3MTcgNjU1MzUgZg0K
MDAwMDAwMDcxOCA2NTUzNSBmDQowMDAwMDAwNzE5IDY1NTM1IGYNCjAwMDAwMDA3MjAgNjU1MzUg
Zg0KMDAwMDAwMDcyMSA2NTUzNSBmDQowMDAwMDAwNzIyIDY1NTM1IGYNCjAwMDAwMDA3MjMgNjU1
MzUgZg0KMDAwMDAwMDcyNCA2NTUzNSBmDQowMDAwMDAwNzI1IDY1NTM1IGYNCjAwMDAwMDA3MjYg
NjU1MzUgZg0KMDAwMDAwMDcyNyA2NTUzNSBmDQowMDAwMDAwNzI4IDY1NTM1IGYNCjAwMDAwMDA3
MjkgNjU1MzUgZg0KMDAwMDAwMDczMCA2NTUzNSBmDQowMDAwMDAwNzMxIDY1NTM1IGYNCjAwMDAw
MDA3MzIgNjU1MzUgZg0KMDAwMDAwMDczMyA2NTUzNSBmDQowMDAwMDAwNzM0IDY1NTM1IGYNCjAw
MDAwMDA3MzUgNjU1MzUgZg0KMDAwMDAwMDczNiA2NTUzNSBmDQowMDAwMDAwNzM3IDY1NTM1IGYN
CjAwMDAwMDA3MzggNjU1MzUgZg0KMDAwMDAwMDczOSA2NTUzNSBmDQowMDAwMDAwNzQwIDY1NTM1
IGYNCjAwMDAwMDA3NDEgNjU1MzUgZg0KMDAwMDAwMDc0MiA2NTUzNSBmDQowMDAwMDAwNzQzIDY1
NTM1IGYNCjAwMDAwMDA3NDQgNjU1MzUgZg0KMDAwMDAwMDc0NSA2NTUzNSBmDQowMDAwMDAwNzQ2
IDY1NTM1IGYNCjAwMDAwMDA3NDcgNjU1MzUgZg0KMDAwMDAwMDc0OCA2NTUzNSBmDQowMDAwMDAw
NzQ5IDY1NTM1IGYNCjAwMDAwMDA3NTAgNjU1MzUgZg0KMDAwMDAwMDc1MSA2NTUzNSBmDQowMDAw
MDAwNzUyIDY1NTM1IGYNCjAwMDAwMDA3NTMgNjU1MzUgZg0KMDAwMDAwMDc1NCA2NTUzNSBmDQow
MDAwMDAwNzU1IDY1NTM1IGYNCjAwMDAwMDA3NTYgNjU1MzUgZg0KMDAwMDAwMDc1NyA2NTUzNSBm
DQowMDAwMDAwNzU4IDY1NTM1IGYNCjAwMDAwMDA3NTkgNjU1MzUgZg0KMDAwMDAwMDc2MCA2NTUz
NSBmDQowMDAwMDAwNzYxIDY1NTM1IGYNCjAwMDAwMDA3NjIgNjU1MzUgZg0KMDAwMDAwMDc2MyA2
NTUzNSBmDQowMDAwMDAwNzY0IDY1NTM1IGYNCjAwMDAwMDA3NjUgNjU1MzUgZg0KMDAwMDAwMDc2
NiA2NTUzNSBmDQowMDAwMDAwNzY3IDY1NTM1IGYNCjAwMDAwMDA3NjggNjU1MzUgZg0KMDAwMDAw
MDc2OSA2NTUzNSBmDQowMDAwMDAwNzcwIDY1NTM1IGYNCjAwMDAwMDA3NzEgNjU1MzUgZg0KMDAw
MDAwMDc3MiA2NTUzNSBmDQowMDAwMDAwNzczIDY1NTM1IGYNCjAwMDAwMDA3NzQgNjU1MzUgZg0K
MDAwMDAwMDc3NSA2NTUzNSBmDQowMDAwMDAwNzc2IDY1NTM1IGYNCjAwMDAwMDA3NzcgNjU1MzUg
Zg0KMDAwMDAwMDc3OCA2NTUzNSBmDQowMDAwMDAwNzc5IDY1NTM1IGYNCjAwMDAwMDA3ODAgNjU1
MzUgZg0KMDAwMDAwMDc4MSA2NTUzNSBmDQowMDAwMDAwNzgyIDY1NTM1IGYNCjAwMDAwMDA3ODMg
NjU1MzUgZg0KMDAwMDAwMDc4NCA2NTUzNSBmDQowMDAwMDAwNzg1IDY1NTM1IGYNCjAwMDAwMDA3
ODYgNjU1MzUgZg0KMDAwMDAwMDc4NyA2NTUzNSBmDQowMDAwMDAwNzg4IDY1NTM1IGYNCjAwMDAw
MDA3ODkgNjU1MzUgZg0KMDAwMDAwMDc5MCA2NTUzNSBmDQowMDAwMDAwNzkxIDY1NTM1IGYNCjAw
MDAwMDA3OTIgNjU1MzUgZg0KMDAwMDAwMDc5MyA2NTUzNSBmDQowMDAwMDAwNzk0IDY1NTM1IGYN
CjAwMDAwMDA3OTUgNjU1MzUgZg0KMDAwMDAwMDc5NiA2NTUzNSBmDQowMDAwMDAwNzk3IDY1NTM1
IGYNCjAwMDAwMDA3OTggNjU1MzUgZg0KMDAwMDAwMDc5OSA2NTUzNSBmDQowMDAwMDAwODAwIDY1
NTM1IGYNCjAwMDAwMDA4MDEgNjU1MzUgZg0KMDAwMDAwMDgwMiA2NTUzNSBmDQowMDAwMDAwODAz
IDY1NTM1IGYNCjAwMDAwMDA4MDQgNjU1MzUgZg0KMDAwMDAwMDgwNSA2NTUzNSBmDQowMDAwMDAw
ODA2IDY1NTM1IGYNCjAwMDAwMDA4MDcgNjU1MzUgZg0KMDAwMDAwMDgwOCA2NTUzNSBmDQowMDAw
MDAwODA5IDY1NTM1IGYNCjAwMDAwMDA4MTAgNjU1MzUgZg0KMDAwMDAwMDgxMSA2NTUzNSBmDQow
MDAwMDAwODEyIDY1NTM1IGYNCjAwMDAwMDA4MTMgNjU1MzUgZg0KMDAwMDAwMDgxNCA2NTUzNSBm
DQowMDAwMDAwODE1IDY1NTM1IGYNCjAwMDAwMDA4MTYgNjU1MzUgZg0KMDAwMDAwMDgxNyA2NTUz
NSBmDQowMDAwMDAwODE4IDY1NTM1IGYNCjAwMDAwMDA4MTkgNjU1MzUgZg0KMDAwMDAwMDgyMCA2
NTUzNSBmDQowMDAwMDAwODIxIDY1NTM1IGYNCjAwMDAwMDA4MjIgNjU1MzUgZg0KMDAwMDAwMDgy
MyA2NTUzNSBmDQowMDAwMDAwODI0IDY1NTM1IGYNCjAwMDAwMDA4MjUgNjU1MzUgZg0KMDAwMDAw
MDgyNiA2NTUzNSBmDQowMDAwMDAwODI3IDY1NTM1IGYNCjAwMDAwMDA4MjggNjU1MzUgZg0KMDAw
MDAwMDgyOSA2NTUzNSBmDQowMDAwMDAwODMwIDY1NTM1IGYNCjAwMDAwMDA4MzEgNjU1MzUgZg0K
MDAwMDAwMDgzMiA2NTUzNSBmDQowMDAwMDAwODMzIDY1NTM1IGYNCjAwMDAwMDA4MzQgNjU1MzUg
Zg0KMDAwMDAwMDgzNSA2NTUzNSBmDQowMDAwMDAwODM2IDY1NTM1IGYNCjAwMDAwMDA4MzcgNjU1
MzUgZg0KMDAwMDAwMDgzOCA2NTUzNSBmDQowMDAwMDAwODM5IDY1NTM1IGYNCjAwMDAwMDA4NDAg
NjU1MzUgZg0KMDAwMDAwMDg0MSA2NTUzNSBmDQowMDAwMDAwODQyIDY1NTM1IGYNCjAwMDAwMDA4
NDMgNjU1MzUgZg0KMDAwMDAwMDg0NCA2NTUzNSBmDQowMDAwMDAwODQ1IDY1NTM1IGYNCjAwMDAw
MDA4NDYgNjU1MzUgZg0KMDAwMDAwMDg0NyA2NTUzNSBmDQowMDAwMDAwODQ4IDY1NTM1IGYNCjAw
MDAwMDA4NDkgNjU1MzUgZg0KMDAwMDAwMDg1MCA2NTUzNSBmDQowMDAwMDAwODUxIDY1NTM1IGYN
CjAwMDAwMDA4NTIgNjU1MzUgZg0KMDAwMDAwMDg1MyA2NTUzNSBmDQowMDAwMDAwODU0IDY1NTM1
IGYNCjAwMDAwMDA4NTUgNjU1MzUgZg0KMDAwMDAwMDg1NiA2NTUzNSBmDQowMDAwMDAwODU3IDY1
NTM1IGYNCjAwMDAwMDA4NTggNjU1MzUgZg0KMDAwMDAwMDg1OSA2NTUzNSBmDQowMDAwMDAwODYw
IDY1NTM1IGYNCjAwMDAwMDA4NjEgNjU1MzUgZg0KMDAwMDAwMDg2MiA2NTUzNSBmDQowMDAwMDAw
ODYzIDY1NTM1IGYNCjAwMDAwMDA4NjQgNjU1MzUgZg0KMDAwMDAwMDg2NSA2NTUzNSBmDQowMDAw
MDAwODY2IDY1NTM1IGYNCjAwMDAwMDA4NjcgNjU1MzUgZg0KMDAwMDAwMDg2OCA2NTUzNSBmDQow
MDAwMDAwODY5IDY1NTM1IGYNCjAwMDAwMDA4NzAgNjU1MzUgZg0KMDAwMDAwMDg3MSA2NTUzNSBm
DQowMDAwMDAwODcyIDY1NTM1IGYNCjAwMDAwMDA4NzMgNjU1MzUgZg0KMDAwMDAwMDg3NCA2NTUz
NSBmDQowMDAwMDAwODc1IDY1NTM1IGYNCjAwMDAwMDA4NzYgNjU1MzUgZg0KMDAwMDAwMDg3NyA2
NTUzNSBmDQowMDAwMDAwODc4IDY1NTM1IGYNCjAwMDAwMDA4NzkgNjU1MzUgZg0KMDAwMDAwMDg4
MCA2NTUzNSBmDQowMDAwMDAwODgxIDY1NTM1IGYNCjAwMDAwMDA4ODIgNjU1MzUgZg0KMDAwMDAw
MDg4MyA2NTUzNSBmDQowMDAwMDAwODg0IDY1NTM1IGYNCjAwMDAwMDA4ODUgNjU1MzUgZg0KMDAw
MDAwMDg4NiA2NTUzNSBmDQowMDAwMDAwODg3IDY1NTM1IGYNCjAwMDAwMDA4ODggNjU1MzUgZg0K
MDAwMDAwMDg4OSA2NTUzNSBmDQowMDAwMDAwODkwIDY1NTM1IGYNCjAwMDAwMDA4OTEgNjU1MzUg
Zg0KMDAwMDAwMDg5MiA2NTUzNSBmDQowMDAwMDAwODkzIDY1NTM1IGYNCjAwMDAwMDA4OTQgNjU1
MzUgZg0KMDAwMDAwMDg5NSA2NTUzNSBmDQowMDAwMDAwODk2IDY1NTM1IGYNCjAwMDAwMDA4OTcg
NjU1MzUgZg0KMDAwMDAwMDg5OCA2NTUzNSBmDQowMDAwMDAwODk5IDY1NTM1IGYNCjAwMDAwMDA5
MDAgNjU1MzUgZg0KMDAwMDAwMDkwMSA2NTUzNSBmDQowMDAwMDAwOTAyIDY1NTM1IGYNCjAwMDAw
MDA5MDMgNjU1MzUgZg0KMDAwMDAwMDkwNCA2NTUzNSBmDQowMDAwMDAwOTA1IDY1NTM1IGYNCjAw
MDAwMDA5MDYgNjU1MzUgZg0KMDAwMDAwMDkwNyA2NTUzNSBmDQowMDAwMDAwOTA4IDY1NTM1IGYN
CjAwMDAwMDA5MDkgNjU1MzUgZg0KMDAwMDAwMDkxMCA2NTUzNSBmDQowMDAwMDAwOTExIDY1NTM1
IGYNCjAwMDAwMDA5MTIgNjU1MzUgZg0KMDAwMDAwMDkxMyA2NTUzNSBmDQowMDAwMDAwOTE0IDY1
NTM1IGYNCjAwMDAwMDA5MTUgNjU1MzUgZg0KMDAwMDAwMDkxNiA2NTUzNSBmDQowMDAwMDAwOTE3
IDY1NTM1IGYNCjAwMDAwMDA5MTggNjU1MzUgZg0KMDAwMDAwMDkxOSA2NTUzNSBmDQowMDAwMDAw
OTIwIDY1NTM1IGYNCjAwMDAwMDA5MjEgNjU1MzUgZg0KMDAwMDAwMDkyMiA2NTUzNSBmDQowMDAw
MDAwOTIzIDY1NTM1IGYNCjAwMDAwMDA5MjQgNjU1MzUgZg0KMDAwMDAwMDkyNSA2NTUzNSBmDQow
MDAwMDAwOTI2IDY1NTM1IGYNCjAwMDAwMDA5MjcgNjU1MzUgZg0KMDAwMDAwMDkyOCA2NTUzNSBm
DQowMDAwMDAwOTI5IDY1NTM1IGYNCjAwMDAwMDA5MzAgNjU1MzUgZg0KMDAwMDAwMDkzMSA2NTUz
NSBmDQowMDAwMDAwOTMyIDY1NTM1IGYNCjAwMDAwMDA5MzMgNjU1MzUgZg0KMDAwMDAwMDAwMCA2
NTUzNSBmDQowMDAwMTYwMjI5IDAwMDAwIG4NCjAwMDAxNjA1NTkgMDAwMDAgbg0KMDAwMDE4MTEy
NiAwMDAwMCBuDQowMDAwMTgxNTQ1IDAwMDAwIG4NCjAwMDAyMDg1NjMgMDAwMDAgbg0KMDAwMDIw
ODk5NCAwMDAwMCBuDQowMDAwMjA5MzU1IDAwMDAwIG4NCjAwMDAyMDk1NTcgMDAwMDAgbg0KMDAw
MDIyMTY0OCAwMDAwMCBuDQowMDAwMjIxOTQ5IDAwMDAwIG4NCjAwMDAyMzUxOTQgMDAwMDAgbg0K
MDAwMDIzNTIzOCAwMDAwMCBuDQp0cmFpbGVyDQo8PC9TaXplIDk0Ni9Sb290IDEgMCBSL0luZm8g
NzcgMCBSL0lEWzw4QzEyMzk5Rjc5RkJFQjQ2Qjc1ODVBREYzRDk0NTY1Mz48OEMxMjM5OUY3OUZC
RUI0NkI3NTg1QURGM0Q5NDU2NTM+XSA+Pg0Kc3RhcnR4cmVmDQoyMzczNTkNCiUlRU9GDQp4cmVm
DQowIDANCnRyYWlsZXINCjw8L1NpemUgOTQ2L1Jvb3QgMSAwIFIvSW5mbyA3NyAwIFIvSURbPDhD
MTIzOTlGNzlGQkVCNDZCNzU4NUFERjNEOTQ1NjUzPjw4QzEyMzk5Rjc5RkJFQjQ2Qjc1ODVBREYz
RDk0NTY1Mz5dIC9QcmV2IDIzNzM1OS9YUmVmU3RtIDIzNTIzOD4+DQpzdGFydHhyZWYNCjI1NjQz
OQ0KJSVFT0Y=

--_002_DE8DF0795D48FD4CA783C40EC82923353610F0SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC82923353610F0SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Fri Oct 19 20:32:39 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 20:32:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPJEt-0007Ks-AF; Fri, 19 Oct 2012 20:32:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPJEr-0007Kn-PY
	for xen-devel@lists.xensource.com; Fri, 19 Oct 2012 20:32:13 +0000
Received: from [85.158.139.83:35794] by server-7.bemta-5.messagelabs.com id
	B1/8C-23102-DC8B1805; Fri, 19 Oct 2012 20:32:13 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1350678731!31786270!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzU3Mzcy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15406 invoked from network); 19 Oct 2012 20:32:12 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-6.tower-182.messagelabs.com with SMTP;
	19 Oct 2012 20:32:12 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 19 Oct 2012 13:31:46 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,615,1344236400"; d="scan'208";a="229861436"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by orsmga002.jf.intel.com with ESMTP; 19 Oct 2012 13:32:10 -0700
Received: from fmsmsx102.amr.corp.intel.com (10.19.9.53) by
	FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 19 Oct 2012 13:32:10 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX102.amr.corp.intel.com (10.19.9.53) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 19 Oct 2012 13:32:03 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.186]) with mapi id
	14.01.0355.002; Sat, 20 Oct 2012 04:32:02 +0800
From: "Liu, Jinsong" 
To: George Dunlap 
Thread-Topic: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration when
	vMCE occur
Thread-Index: AQHNrhoFaBRa8rOqkUOTeDJn2J5LNJfBERCg
Date: Fri, 19 Oct 2012 20:32:01 +0000
Message-ID: 
References: 
	
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	Ian Jackson , Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration when vMCE
 occur
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap wrote:
> On Wed, Oct 10, 2012 at 3:46 PM, Liu, Jinsong 
> wrote: 
>> Xen/MCE: Abort live migration when vMCE occur
>> 
>> This patch monitor the critical area of live migration (from vMCE
>> point of view, the copypages stage of migration is the critical area
>> while other areas are not). 
>> 
>> If a vMCE occur at the critical area of live migration, there is
>> risk that error data may be copied to the target. Currently we don't
>> have convenient way to handle this case, so for the sake of safe, we
>> abort it and try migration later (at that time broken page would not
>> be mapped and copied to the target). 
>> 
>> Signed-off-by: Liu, Jinsong 
> 
> I'm not sure exactly what this patch is meant to do -- it won't
> actually stop the broken page from being read, and it won't stop the
> migration in the middle; instead it will finish copying the memory
> before deciding to quit.
> 

Yes, because currently we don't have convenient way to make sure / handle whether error page copied to target or not.

> Wouldn't your patch 5 be sufficient to deal with this case?  It seems
> like the broken page would get marked as such, and then get marked
> broken on the receiving side, wouldn't it?
> 
>  -George

Seems no, patch 4 is to handle the case mce occur during migration --> under such case the broken page would mapped (at that time the page is a good page) and copy to target; While patch 5 is to handle the case mce occur beofre migration --> under such case the broken page would not mapped and so would not copy to target.

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 20:32:39 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 20:32:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPJEt-0007Ks-AF; Fri, 19 Oct 2012 20:32:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPJEr-0007Kn-PY
	for xen-devel@lists.xensource.com; Fri, 19 Oct 2012 20:32:13 +0000
Received: from [85.158.139.83:35794] by server-7.bemta-5.messagelabs.com id
	B1/8C-23102-DC8B1805; Fri, 19 Oct 2012 20:32:13 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1350678731!31786270!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzU3Mzcy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15406 invoked from network); 19 Oct 2012 20:32:12 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-6.tower-182.messagelabs.com with SMTP;
	19 Oct 2012 20:32:12 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 19 Oct 2012 13:31:46 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,615,1344236400"; d="scan'208";a="229861436"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by orsmga002.jf.intel.com with ESMTP; 19 Oct 2012 13:32:10 -0700
Received: from fmsmsx102.amr.corp.intel.com (10.19.9.53) by
	FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 19 Oct 2012 13:32:10 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX102.amr.corp.intel.com (10.19.9.53) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 19 Oct 2012 13:32:03 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.186]) with mapi id
	14.01.0355.002; Sat, 20 Oct 2012 04:32:02 +0800
From: "Liu, Jinsong" 
To: George Dunlap 
Thread-Topic: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration when
	vMCE occur
Thread-Index: AQHNrhoFaBRa8rOqkUOTeDJn2J5LNJfBERCg
Date: Fri, 19 Oct 2012 20:32:01 +0000
Message-ID: 
References: 
	
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	Ian Jackson , Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration when vMCE
 occur
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap wrote:
> On Wed, Oct 10, 2012 at 3:46 PM, Liu, Jinsong 
> wrote: 
>> Xen/MCE: Abort live migration when vMCE occur
>> 
>> This patch monitor the critical area of live migration (from vMCE
>> point of view, the copypages stage of migration is the critical area
>> while other areas are not). 
>> 
>> If a vMCE occur at the critical area of live migration, there is
>> risk that error data may be copied to the target. Currently we don't
>> have convenient way to handle this case, so for the sake of safe, we
>> abort it and try migration later (at that time broken page would not
>> be mapped and copied to the target). 
>> 
>> Signed-off-by: Liu, Jinsong 
> 
> I'm not sure exactly what this patch is meant to do -- it won't
> actually stop the broken page from being read, and it won't stop the
> migration in the middle; instead it will finish copying the memory
> before deciding to quit.
> 

Yes, because currently we don't have convenient way to make sure / handle whether error page copied to target or not.

> Wouldn't your patch 5 be sufficient to deal with this case?  It seems
> like the broken page would get marked as such, and then get marked
> broken on the receiving side, wouldn't it?
> 
>  -George

Seems no, patch 4 is to handle the case mce occur during migration --> under such case the broken page would mapped (at that time the page is a good page) and copy to target; While patch 5 is to handle the case mce occur beofre migration --> under such case the broken page would not mapped and so would not copy to target.

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 21:08:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 21:08:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPJnK-0007dA-TB; Fri, 19 Oct 2012 21:07:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPJnJ-0007d5-F3
	for xen-devel@lists.xensource.com; Fri, 19 Oct 2012 21:07:49 +0000
Received: from [85.158.143.99:65342] by server-2.bemta-4.messagelabs.com id
	6A/B9-22268-421C1805; Fri, 19 Oct 2012 21:07:48 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1350680866!26642419!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDM1MjgzMw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23902 invoked from network); 19 Oct 2012 21:07:47 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-2.tower-216.messagelabs.com with SMTP;
	19 Oct 2012 21:07:47 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 19 Oct 2012 14:07:45 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,617,1344236400"; d="scan'208";a="237685192"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by fmsmga002.fm.intel.com with ESMTP; 19 Oct 2012 14:07:45 -0700
Received: from FMSMSX110.amr.corp.intel.com (10.19.9.29) by
	FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 19 Oct 2012 14:07:45 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	fmsmsx110.amr.corp.intel.com (10.19.9.29) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 19 Oct 2012 14:07:44 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.186]) with mapi id
	14.01.0355.002; Sat, 20 Oct 2012 05:07:42 +0800
From: "Liu, Jinsong" 
To: George Dunlap , Ian Jackson
	
Thread-Topic: [Xen-devel] [PATCH 5/5] X86/vMCE: guest broken page handling
	when migration
Thread-Index: AQHNrhyIiNx+itmCjEmYmikvGoOzsJfBFYdQ
Date: Fri, 19 Oct 2012 21:07:41 +0000
Message-ID: 
References: 
	<20609.28264.158580.995717@mariner.uk.xensource.com>
	
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_003_DE8DF0795D48FD4CA783C40EC82923353611B9SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 5/5] X86/vMCE: guest broken page handling
 when migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_003_DE8DF0795D48FD4CA783C40EC82923353611B9SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

George Dunlap wrote:
> On Fri, Oct 19, 2012 at 4:14 PM, Ian Jackson
>  wrote:=20
>> Liu, Jinsong writes ("[Xen-devel] [PATCH 5/5] X86/vMCE: guest broken
>> page handling when migration"):=20
>>> X86/vMCE: guest broken page handling when migration
>>>=20
>>> This patch is used to handle guest broken page when migration.
>>=20
>> This looks plausible to me, as far as the tools go.  Can you explain
>> how you have tested this ?  Did you manage to do any tests of the
>> remus codepaths ?
>=20
> I'm pretty sure that this shouldn't cause any problems with Remus.  If
> it's difficult for Jinsong to test Remus, I think probably OK to
> commit it, and then revert it if the Remus guys have any problems.
>=20
>  -George

Attached are 2 test program, my test steps are,
1. at sender, inject a vmce to guest, scan & record the broken page (pfn1)
2. do live migration, success;
3. at target, scan the broken page (pfn2) and compare
4. pfn1 =3D pfn2

I tested live migration, but not remus.

Thanks,
Jinsong

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
test program 1:

diff -r ad02805c77b8 xen/arch/x86/cpu/mcheck/vmce.c
--- a/xen/arch/x86/cpu/mcheck/vmce.c	Sat Jul 28 06:35:47 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/vmce.c	Sat Aug 25 04:01:19 2012 +0800
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -449,3 +450,93 @@
     return rc;
 }
=20
+
+/***************************************************/
+
+unsigned long broken_pfn =3D 0;
+
+static void sender_broken_page(unsigned char key)
+{
+    domid_t sender_domid =3D 1;
+    struct domain *d;
+    struct p2m_domain *p2m;
+    unsigned long pfn;
+    p2m_type_t pt;
+
+    d =3D rcu_lock_domain_by_id(sender_domid);
+    p2m =3D p2m_get_hostp2m(d);
+
+    for ( pfn =3D 0; pfn < p2m->max_mapped_pfn; pfn++ )
+    {
+        get_gfn_query(d, pfn, &pt);
+        if ( unlikely(p2m_is_broken(pt)) )
+        {
+            printk("!!!!!! before migration, find broken page, "
+                   "dom =3D %d, pfn =3D %lx, pt =3D %d\n",
+                    (unsigned int)d->domain_id, pfn, (unsigned int)pt);
+            broken_pfn =3D pfn;
+        }
+        put_gfn(d, pfn);
+    }
+
+    rcu_unlock_domain(d);
+}
+
+static struct keyhandler sender_broken_page_keyhandler =3D {
+    .diagnostic =3D 1,
+    .u.fn =3D sender_broken_page,
+};
+
+static __init int sender_broken_page_init(void)
+{
+    register_keyhandler('6', &sender_broken_page_keyhandler);
+    return 0;
+}
+__initcall(sender_broken_page_init);
+
+/****************************************************/
+
+
+static void target_broken_page(unsigned char key)
+{
+    domid_t target_domid =3D 2;
+    struct domain *d;
+    struct p2m_domain *p2m;
+    unsigned long pfn;
+    p2m_type_t pt;
+
+    d =3D rcu_lock_domain_by_id(target_domid);
+    p2m =3D p2m_get_hostp2m(d);
+
+    for ( pfn =3D 0; pfn < p2m->max_mapped_pfn; pfn++ )
+    {
+        get_gfn_query(d, pfn, &pt);
+        if ( unlikely(p2m_is_broken(pt)) )
+            printk("@@@@@@ after migration, find broken page, "
+                   "dom =3D %d, pfn =3D %lx, pt =3D %d\n",
+                    (unsigned int)d->domain_id, pfn, (unsigned int)pt);
+        put_gfn(d, pfn);
+    }
+
+    get_gfn_query(d, broken_pfn, &pt);
+    printk("@@@@@@ after migration, broken_pfn type is, "
+           "dom =3D %d, broken_pfn =3D %lx, pt =3D %d\n",
+           (unsigned int)d->domain_id, broken_pfn, (unsigned int)pt);
+    put_gfn(d, broken_pfn);
+
+    rcu_unlock_domain(d);
+}
+
+static struct keyhandler target_broken_page_keyhandler =3D {
+    .diagnostic =3D 1,
+    .u.fn =3D target_broken_page,
+};
+
+static __init int target_broken_page_init(void)
+{
+    register_keyhandler('7', &target_broken_page_keyhandler);
+    return 0;
+}
+__initcall(target_broken_page_init);
+
+/*****************************************************/

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
test program 2:

diff -r de462f2f1db8 tools/libxc/xc_domain_restore.c
--- a/tools/libxc/xc_domain_restore.c	Mon Aug 27 21:38:11 2012 +0800
+++ b/tools/libxc/xc_domain_restore.c	Mon Aug 27 21:56:53 2012 +0800
@@ -1207,8 +1207,11 @@
=20
         if ( pagetype =3D=3D XEN_DOMCTL_PFINFO_BROKEN )
         {
+            fprintf(stderr, "@target, find broken page, "
+                      "dom=3D%d, pfn=3D0x%lx, pagetype=3D0x%lx\n", dom, pf=
n, pagetype);
             if ( xc_set_broken_page_p2m(xch, dom, pfn) )
             {
+                fprintf(stderr, "... ERROR WHEN SET P2M FOR BROKEN PAGE\n"=
);
                 ERROR("Set p2m for broken page fail, "
                       "dom=3D%d, pfn=3D%lx\n", dom, pfn);
                 goto err_mapped;
diff -r de462f2f1db8 tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Mon Aug 27 21:38:11 2012 +0800
+++ b/tools/libxc/xc_domain_save.c	Mon Aug 27 21:56:53 2012 +0800
@@ -1289,6 +1289,9 @@
                 {
                     pfn_type[j] |=3D pfn_batch[j];
                     ++run;
+                    fprintf(stderr, "@sender, find broken page, "
+                            "pfn_err[0x%x]=3D%d, pfn_type[0x%x] =3D%lx\n",
+                    (int)j, (int)pfn_err[j], (int)j, (unsigned long)pfn_ty=
pe[j]);
                     continue;
                 }
=20
diff -r de462f2f1db8 xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c	Mon Aug 27 21:38:11 2012 +0800
+++ b/xen/arch/x86/domctl.c	Mon Aug 27 21:56:53 2012 +0800
@@ -1566,13 +1566,19 @@
         struct domain *d;
         p2m_type_t pt;
         unsigned long pfn;
+        mfn_t r_mfn;
=20
         d =3D rcu_lock_domain_by_id(domctl->domain);
         if ( d !=3D NULL )
         {
             pfn =3D domctl->u.set_broken_page_p2m.pfn;
=20
-            get_gfn_query(d, pfn, &pt);
+            r_mfn =3D get_gfn_query(d, pfn, &pt);
+            printk("@XEN_DOMCTL_set_broken_page_p2m, before set p2m, "
+                   "pfn=3D%lx, pt=3D%d\n", pfn, (int)pt);
+            if (!mfn_valid(mfn_x(r_mfn)))
+                printk("r_mfn IS INVALID!!!\n");
+
             p2m_change_type(d, pfn, pt, p2m_ram_broken);
             put_gfn(d, pfn);
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

--_003_DE8DF0795D48FD4CA783C40EC82923353611B9SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="test1.patch"
Content-Description: test1.patch
Content-Disposition: attachment; filename="test1.patch"; size=2861;
	creation-date="Fri, 19 Oct 2012 20:58:52 GMT";
	modification-date="Thu, 20 Sep 2012 01:18:28 GMT"
Content-Transfer-Encoding: base64

ZGlmZiAtciBhZDAyODA1Yzc3YjggeGVuL2FyY2gveDg2L2NwdS9tY2hlY2svdm1jZS5jCi0tLSBh
L3hlbi9hcmNoL3g4Ni9jcHUvbWNoZWNrL3ZtY2UuYwlTYXQgSnVsIDI4IDA2OjM1OjQ3IDIwMTIg
KzA4MDAKKysrIGIveGVuL2FyY2gveDg2L2NwdS9tY2hlY2svdm1jZS5jCVNhdCBBdWcgMjUgMDQ6
MDE6MTkgMjAxMiArMDgwMApAQCAtMjgsNiArMjgsNyBAQAogI2luY2x1ZGUgPHhlbi9zbXAuaD4K
ICNpbmNsdWRlIDx4ZW4vbW0uaD4KICNpbmNsdWRlIDx4ZW4vaHZtL3NhdmUuaD4KKyNpbmNsdWRl
IDx4ZW4va2V5aGFuZGxlci5oPgogI2luY2x1ZGUgPGFzbS9wcm9jZXNzb3IuaD4KICNpbmNsdWRl
IDxwdWJsaWMvc3lzY3RsLmg+CiAjaW5jbHVkZSA8YXNtL3N5c3RlbS5oPgpAQCAtNDQ5LDMgKzQ1
MCw5MyBAQAogICAgIHJldHVybiByYzsKIH0KIAorCisvKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqLworCit1bnNpZ25lZCBsb25nIGJyb2tlbl9wZm4g
PSAwOworCitzdGF0aWMgdm9pZCBzZW5kZXJfYnJva2VuX3BhZ2UodW5zaWduZWQgY2hhciBrZXkp
Cit7CisgICAgZG9taWRfdCBzZW5kZXJfZG9taWQgPSAxOworICAgIHN0cnVjdCBkb21haW4gKmQ7
CisgICAgc3RydWN0IHAybV9kb21haW4gKnAybTsKKyAgICB1bnNpZ25lZCBsb25nIHBmbjsKKyAg
ICBwMm1fdHlwZV90IHB0OworCisgICAgZCA9IHJjdV9sb2NrX2RvbWFpbl9ieV9pZChzZW5kZXJf
ZG9taWQpOworICAgIHAybSA9IHAybV9nZXRfaG9zdHAybShkKTsKKworICAgIGZvciAoIHBmbiA9
IDA7IHBmbiA8IHAybS0+bWF4X21hcHBlZF9wZm47IHBmbisrICkKKyAgICB7CisgICAgICAgIGdl
dF9nZm5fcXVlcnkoZCwgcGZuLCAmcHQpOworICAgICAgICBpZiAoIHVubGlrZWx5KHAybV9pc19i
cm9rZW4ocHQpKSApCisgICAgICAgIHsKKyAgICAgICAgICAgIHByaW50aygiISEhISEhIGJlZm9y
ZSBtaWdyYXRpb24sIGZpbmQgYnJva2VuIHBhZ2UsICIKKyAgICAgICAgICAgICAgICAgICAiZG9t
ID0gJWQsIHBmbiA9ICVseCwgcHQgPSAlZFxuIiwKKyAgICAgICAgICAgICAgICAgICAgKHVuc2ln
bmVkIGludClkLT5kb21haW5faWQsIHBmbiwgKHVuc2lnbmVkIGludClwdCk7CisgICAgICAgICAg
ICBicm9rZW5fcGZuID0gcGZuOworICAgICAgICB9CisgICAgICAgIHB1dF9nZm4oZCwgcGZuKTsK
KyAgICB9CisKKyAgICByY3VfdW5sb2NrX2RvbWFpbihkKTsKK30KKworc3RhdGljIHN0cnVjdCBr
ZXloYW5kbGVyIHNlbmRlcl9icm9rZW5fcGFnZV9rZXloYW5kbGVyID0geworICAgIC5kaWFnbm9z
dGljID0gMSwKKyAgICAudS5mbiA9IHNlbmRlcl9icm9rZW5fcGFnZSwKK307CisKK3N0YXRpYyBf
X2luaXQgaW50IHNlbmRlcl9icm9rZW5fcGFnZV9pbml0KHZvaWQpCit7CisgICAgcmVnaXN0ZXJf
a2V5aGFuZGxlcignNicsICZzZW5kZXJfYnJva2VuX3BhZ2Vfa2V5aGFuZGxlcik7CisgICAgcmV0
dXJuIDA7Cit9CitfX2luaXRjYWxsKHNlbmRlcl9icm9rZW5fcGFnZV9pbml0KTsKKworLyoqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiovCisKKworc3Rh
dGljIHZvaWQgdGFyZ2V0X2Jyb2tlbl9wYWdlKHVuc2lnbmVkIGNoYXIga2V5KQoreworICAgIGRv
bWlkX3QgdGFyZ2V0X2RvbWlkID0gMjsKKyAgICBzdHJ1Y3QgZG9tYWluICpkOworICAgIHN0cnVj
dCBwMm1fZG9tYWluICpwMm07CisgICAgdW5zaWduZWQgbG9uZyBwZm47CisgICAgcDJtX3R5cGVf
dCBwdDsKKworICAgIGQgPSByY3VfbG9ja19kb21haW5fYnlfaWQodGFyZ2V0X2RvbWlkKTsKKyAg
ICBwMm0gPSBwMm1fZ2V0X2hvc3RwMm0oZCk7CisKKyAgICBmb3IgKCBwZm4gPSAwOyBwZm4gPCBw
Mm0tPm1heF9tYXBwZWRfcGZuOyBwZm4rKyApCisgICAgeworICAgICAgICBnZXRfZ2ZuX3F1ZXJ5
KGQsIHBmbiwgJnB0KTsKKyAgICAgICAgaWYgKCB1bmxpa2VseShwMm1faXNfYnJva2VuKHB0KSkg
KQorICAgICAgICAgICAgcHJpbnRrKCJAQEBAQEAgYWZ0ZXIgbWlncmF0aW9uLCBmaW5kIGJyb2tl
biBwYWdlLCAiCisgICAgICAgICAgICAgICAgICAgImRvbSA9ICVkLCBwZm4gPSAlbHgsIHB0ID0g
JWRcbiIsCisgICAgICAgICAgICAgICAgICAgICh1bnNpZ25lZCBpbnQpZC0+ZG9tYWluX2lkLCBw
Zm4sICh1bnNpZ25lZCBpbnQpcHQpOworICAgICAgICBwdXRfZ2ZuKGQsIHBmbik7CisgICAgfQor
CisgICAgZ2V0X2dmbl9xdWVyeShkLCBicm9rZW5fcGZuLCAmcHQpOworICAgIHByaW50aygiQEBA
QEBAIGFmdGVyIG1pZ3JhdGlvbiwgYnJva2VuX3BmbiB0eXBlIGlzLCAiCisgICAgICAgICAgICJk
b20gPSAlZCwgYnJva2VuX3BmbiA9ICVseCwgcHQgPSAlZFxuIiwKKyAgICAgICAgICAgKHVuc2ln
bmVkIGludClkLT5kb21haW5faWQsIGJyb2tlbl9wZm4sICh1bnNpZ25lZCBpbnQpcHQpOworICAg
IHB1dF9nZm4oZCwgYnJva2VuX3Bmbik7CisKKyAgICByY3VfdW5sb2NrX2RvbWFpbihkKTsKK30K
Kworc3RhdGljIHN0cnVjdCBrZXloYW5kbGVyIHRhcmdldF9icm9rZW5fcGFnZV9rZXloYW5kbGVy
ID0geworICAgIC5kaWFnbm9zdGljID0gMSwKKyAgICAudS5mbiA9IHRhcmdldF9icm9rZW5fcGFn
ZSwKK307CisKK3N0YXRpYyBfX2luaXQgaW50IHRhcmdldF9icm9rZW5fcGFnZV9pbml0KHZvaWQp
Cit7CisgICAgcmVnaXN0ZXJfa2V5aGFuZGxlcignNycsICZ0YXJnZXRfYnJva2VuX3BhZ2Vfa2V5
aGFuZGxlcik7CisgICAgcmV0dXJuIDA7Cit9CitfX2luaXRjYWxsKHRhcmdldF9icm9rZW5fcGFn
ZV9pbml0KTsKKworLyoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqLwo=

--_003_DE8DF0795D48FD4CA783C40EC82923353611B9SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="test2.patch"
Content-Description: test2.patch
Content-Disposition: attachment; filename="test2.patch"; size=2128;
	creation-date="Fri, 19 Oct 2012 20:58:52 GMT";
	modification-date="Thu, 20 Sep 2012 01:18:28 GMT"
Content-Transfer-Encoding: base64

ZGlmZiAtciBkZTQ2MmYyZjFkYjggdG9vbHMvbGlieGMveGNfZG9tYWluX3Jlc3RvcmUuYwotLS0g
YS90b29scy9saWJ4Yy94Y19kb21haW5fcmVzdG9yZS5jCU1vbiBBdWcgMjcgMjE6Mzg6MTEgMjAx
MiArMDgwMAorKysgYi90b29scy9saWJ4Yy94Y19kb21haW5fcmVzdG9yZS5jCU1vbiBBdWcgMjcg
MjE6NTY6NTMgMjAxMiArMDgwMApAQCAtMTIwNyw4ICsxMjA3LDExIEBACiAKICAgICAgICAgaWYg
KCBwYWdldHlwZSA9PSBYRU5fRE9NQ1RMX1BGSU5GT19CUk9LRU4gKQogICAgICAgICB7CisgICAg
ICAgICAgICBmcHJpbnRmKHN0ZGVyciwgIkB0YXJnZXQsIGZpbmQgYnJva2VuIHBhZ2UsICIKKyAg
ICAgICAgICAgICAgICAgICAgICAiZG9tPSVkLCBwZm49MHglbHgsIHBhZ2V0eXBlPTB4JWx4XG4i
LCBkb20sIHBmbiwgcGFnZXR5cGUpOwogICAgICAgICAgICAgaWYgKCB4Y19zZXRfYnJva2VuX3Bh
Z2VfcDJtKHhjaCwgZG9tLCBwZm4pICkKICAgICAgICAgICAgIHsKKyAgICAgICAgICAgICAgICBm
cHJpbnRmKHN0ZGVyciwgIi4uLiBFUlJPUiBXSEVOIFNFVCBQMk0gRk9SIEJST0tFTiBQQUdFXG4i
KTsKICAgICAgICAgICAgICAgICBFUlJPUigiU2V0IHAybSBmb3IgYnJva2VuIHBhZ2UgZmFpbCwg
IgogICAgICAgICAgICAgICAgICAgICAgICJkb209JWQsIHBmbj0lbHhcbiIsIGRvbSwgcGZuKTsK
ICAgICAgICAgICAgICAgICBnb3RvIGVycl9tYXBwZWQ7CmRpZmYgLXIgZGU0NjJmMmYxZGI4IHRv
b2xzL2xpYnhjL3hjX2RvbWFpbl9zYXZlLmMKLS0tIGEvdG9vbHMvbGlieGMveGNfZG9tYWluX3Nh
dmUuYwlNb24gQXVnIDI3IDIxOjM4OjExIDIwMTIgKzA4MDAKKysrIGIvdG9vbHMvbGlieGMveGNf
ZG9tYWluX3NhdmUuYwlNb24gQXVnIDI3IDIxOjU2OjUzIDIwMTIgKzA4MDAKQEAgLTEyODksNiAr
MTI4OSw5IEBACiAgICAgICAgICAgICAgICAgewogICAgICAgICAgICAgICAgICAgICBwZm5fdHlw
ZVtqXSB8PSBwZm5fYmF0Y2hbal07CiAgICAgICAgICAgICAgICAgICAgICsrcnVuOworICAgICAg
ICAgICAgICAgICAgICBmcHJpbnRmKHN0ZGVyciwgIkBzZW5kZXIsIGZpbmQgYnJva2VuIHBhZ2Us
ICIKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAicGZuX2VyclsweCV4XT0lZCwgcGZuX3R5
cGVbMHgleF0gPSVseFxuIiwKKyAgICAgICAgICAgICAgICAgICAgKGludClqLCAoaW50KXBmbl9l
cnJbal0sIChpbnQpaiwgKHVuc2lnbmVkIGxvbmcpcGZuX3R5cGVbal0pOwogICAgICAgICAgICAg
ICAgICAgICBjb250aW51ZTsKICAgICAgICAgICAgICAgICB9CiAKZGlmZiAtciBkZTQ2MmYyZjFk
YjggeGVuL2FyY2gveDg2L2RvbWN0bC5jCi0tLSBhL3hlbi9hcmNoL3g4Ni9kb21jdGwuYwlNb24g
QXVnIDI3IDIxOjM4OjExIDIwMTIgKzA4MDAKKysrIGIveGVuL2FyY2gveDg2L2RvbWN0bC5jCU1v
biBBdWcgMjcgMjE6NTY6NTMgMjAxMiArMDgwMApAQCAtMTU2NiwxMyArMTU2NiwxOSBAQAogICAg
ICAgICBzdHJ1Y3QgZG9tYWluICpkOwogICAgICAgICBwMm1fdHlwZV90IHB0OwogICAgICAgICB1
bnNpZ25lZCBsb25nIHBmbjsKKyAgICAgICAgbWZuX3Qgcl9tZm47CiAKICAgICAgICAgZCA9IHJj
dV9sb2NrX2RvbWFpbl9ieV9pZChkb21jdGwtPmRvbWFpbik7CiAgICAgICAgIGlmICggZCAhPSBO
VUxMICkKICAgICAgICAgewogICAgICAgICAgICAgcGZuID0gZG9tY3RsLT51LnNldF9icm9rZW5f
cGFnZV9wMm0ucGZuOwogCi0gICAgICAgICAgICBnZXRfZ2ZuX3F1ZXJ5KGQsIHBmbiwgJnB0KTsK
KyAgICAgICAgICAgIHJfbWZuID0gZ2V0X2dmbl9xdWVyeShkLCBwZm4sICZwdCk7CisgICAgICAg
ICAgICBwcmludGsoIkBYRU5fRE9NQ1RMX3NldF9icm9rZW5fcGFnZV9wMm0sIGJlZm9yZSBzZXQg
cDJtLCAiCisgICAgICAgICAgICAgICAgICAgInBmbj0lbHgsIHB0PSVkXG4iLCBwZm4sIChpbnQp
cHQpOworICAgICAgICAgICAgaWYgKCFtZm5fdmFsaWQobWZuX3gocl9tZm4pKSkKKyAgICAgICAg
ICAgICAgICBwcmludGsoInJfbWZuIElTIElOVkFMSUQhISFcbiIpOworCiAgICAgICAgICAgICBw
Mm1fY2hhbmdlX3R5cGUoZCwgcGZuLCBwdCwgcDJtX3JhbV9icm9rZW4pOwogICAgICAgICAgICAg
cHV0X2dmbihkLCBwZm4pOwogCg==

--_003_DE8DF0795D48FD4CA783C40EC82923353611B9SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_003_DE8DF0795D48FD4CA783C40EC82923353611B9SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Fri Oct 19 21:08:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 21:08:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPJnK-0007dA-TB; Fri, 19 Oct 2012 21:07:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPJnJ-0007d5-F3
	for xen-devel@lists.xensource.com; Fri, 19 Oct 2012 21:07:49 +0000
Received: from [85.158.143.99:65342] by server-2.bemta-4.messagelabs.com id
	6A/B9-22268-421C1805; Fri, 19 Oct 2012 21:07:48 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1350680866!26642419!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDM1MjgzMw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23902 invoked from network); 19 Oct 2012 21:07:47 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-2.tower-216.messagelabs.com with SMTP;
	19 Oct 2012 21:07:47 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 19 Oct 2012 14:07:45 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,617,1344236400"; d="scan'208";a="237685192"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by fmsmga002.fm.intel.com with ESMTP; 19 Oct 2012 14:07:45 -0700
Received: from FMSMSX110.amr.corp.intel.com (10.19.9.29) by
	FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 19 Oct 2012 14:07:45 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	fmsmsx110.amr.corp.intel.com (10.19.9.29) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 19 Oct 2012 14:07:44 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.186]) with mapi id
	14.01.0355.002; Sat, 20 Oct 2012 05:07:42 +0800
From: "Liu, Jinsong" 
To: George Dunlap , Ian Jackson
	
Thread-Topic: [Xen-devel] [PATCH 5/5] X86/vMCE: guest broken page handling
	when migration
Thread-Index: AQHNrhyIiNx+itmCjEmYmikvGoOzsJfBFYdQ
Date: Fri, 19 Oct 2012 21:07:41 +0000
Message-ID: 
References: 
	<20609.28264.158580.995717@mariner.uk.xensource.com>
	
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_003_DE8DF0795D48FD4CA783C40EC82923353611B9SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 5/5] X86/vMCE: guest broken page handling
 when migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_003_DE8DF0795D48FD4CA783C40EC82923353611B9SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

George Dunlap wrote:
> On Fri, Oct 19, 2012 at 4:14 PM, Ian Jackson
>  wrote:=20
>> Liu, Jinsong writes ("[Xen-devel] [PATCH 5/5] X86/vMCE: guest broken
>> page handling when migration"):=20
>>> X86/vMCE: guest broken page handling when migration
>>>=20
>>> This patch is used to handle guest broken page when migration.
>>=20
>> This looks plausible to me, as far as the tools go.  Can you explain
>> how you have tested this ?  Did you manage to do any tests of the
>> remus codepaths ?
>=20
> I'm pretty sure that this shouldn't cause any problems with Remus.  If
> it's difficult for Jinsong to test Remus, I think probably OK to
> commit it, and then revert it if the Remus guys have any problems.
>=20
>  -George

Attached are 2 test program, my test steps are,
1. at sender, inject a vmce to guest, scan & record the broken page (pfn1)
2. do live migration, success;
3. at target, scan the broken page (pfn2) and compare
4. pfn1 =3D pfn2

I tested live migration, but not remus.

Thanks,
Jinsong

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
test program 1:

diff -r ad02805c77b8 xen/arch/x86/cpu/mcheck/vmce.c
--- a/xen/arch/x86/cpu/mcheck/vmce.c	Sat Jul 28 06:35:47 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/vmce.c	Sat Aug 25 04:01:19 2012 +0800
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -449,3 +450,93 @@
     return rc;
 }
=20
+
+/***************************************************/
+
+unsigned long broken_pfn =3D 0;
+
+static void sender_broken_page(unsigned char key)
+{
+    domid_t sender_domid =3D 1;
+    struct domain *d;
+    struct p2m_domain *p2m;
+    unsigned long pfn;
+    p2m_type_t pt;
+
+    d =3D rcu_lock_domain_by_id(sender_domid);
+    p2m =3D p2m_get_hostp2m(d);
+
+    for ( pfn =3D 0; pfn < p2m->max_mapped_pfn; pfn++ )
+    {
+        get_gfn_query(d, pfn, &pt);
+        if ( unlikely(p2m_is_broken(pt)) )
+        {
+            printk("!!!!!! before migration, find broken page, "
+                   "dom =3D %d, pfn =3D %lx, pt =3D %d\n",
+                    (unsigned int)d->domain_id, pfn, (unsigned int)pt);
+            broken_pfn =3D pfn;
+        }
+        put_gfn(d, pfn);
+    }
+
+    rcu_unlock_domain(d);
+}
+
+static struct keyhandler sender_broken_page_keyhandler =3D {
+    .diagnostic =3D 1,
+    .u.fn =3D sender_broken_page,
+};
+
+static __init int sender_broken_page_init(void)
+{
+    register_keyhandler('6', &sender_broken_page_keyhandler);
+    return 0;
+}
+__initcall(sender_broken_page_init);
+
+/****************************************************/
+
+
+static void target_broken_page(unsigned char key)
+{
+    domid_t target_domid =3D 2;
+    struct domain *d;
+    struct p2m_domain *p2m;
+    unsigned long pfn;
+    p2m_type_t pt;
+
+    d =3D rcu_lock_domain_by_id(target_domid);
+    p2m =3D p2m_get_hostp2m(d);
+
+    for ( pfn =3D 0; pfn < p2m->max_mapped_pfn; pfn++ )
+    {
+        get_gfn_query(d, pfn, &pt);
+        if ( unlikely(p2m_is_broken(pt)) )
+            printk("@@@@@@ after migration, find broken page, "
+                   "dom =3D %d, pfn =3D %lx, pt =3D %d\n",
+                    (unsigned int)d->domain_id, pfn, (unsigned int)pt);
+        put_gfn(d, pfn);
+    }
+
+    get_gfn_query(d, broken_pfn, &pt);
+    printk("@@@@@@ after migration, broken_pfn type is, "
+           "dom =3D %d, broken_pfn =3D %lx, pt =3D %d\n",
+           (unsigned int)d->domain_id, broken_pfn, (unsigned int)pt);
+    put_gfn(d, broken_pfn);
+
+    rcu_unlock_domain(d);
+}
+
+static struct keyhandler target_broken_page_keyhandler =3D {
+    .diagnostic =3D 1,
+    .u.fn =3D target_broken_page,
+};
+
+static __init int target_broken_page_init(void)
+{
+    register_keyhandler('7', &target_broken_page_keyhandler);
+    return 0;
+}
+__initcall(target_broken_page_init);
+
+/*****************************************************/

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
test program 2:

diff -r de462f2f1db8 tools/libxc/xc_domain_restore.c
--- a/tools/libxc/xc_domain_restore.c	Mon Aug 27 21:38:11 2012 +0800
+++ b/tools/libxc/xc_domain_restore.c	Mon Aug 27 21:56:53 2012 +0800
@@ -1207,8 +1207,11 @@
=20
         if ( pagetype =3D=3D XEN_DOMCTL_PFINFO_BROKEN )
         {
+            fprintf(stderr, "@target, find broken page, "
+                      "dom=3D%d, pfn=3D0x%lx, pagetype=3D0x%lx\n", dom, pf=
n, pagetype);
             if ( xc_set_broken_page_p2m(xch, dom, pfn) )
             {
+                fprintf(stderr, "... ERROR WHEN SET P2M FOR BROKEN PAGE\n"=
);
                 ERROR("Set p2m for broken page fail, "
                       "dom=3D%d, pfn=3D%lx\n", dom, pfn);
                 goto err_mapped;
diff -r de462f2f1db8 tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Mon Aug 27 21:38:11 2012 +0800
+++ b/tools/libxc/xc_domain_save.c	Mon Aug 27 21:56:53 2012 +0800
@@ -1289,6 +1289,9 @@
                 {
                     pfn_type[j] |=3D pfn_batch[j];
                     ++run;
+                    fprintf(stderr, "@sender, find broken page, "
+                            "pfn_err[0x%x]=3D%d, pfn_type[0x%x] =3D%lx\n",
+                    (int)j, (int)pfn_err[j], (int)j, (unsigned long)pfn_ty=
pe[j]);
                     continue;
                 }
=20
diff -r de462f2f1db8 xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c	Mon Aug 27 21:38:11 2012 +0800
+++ b/xen/arch/x86/domctl.c	Mon Aug 27 21:56:53 2012 +0800
@@ -1566,13 +1566,19 @@
         struct domain *d;
         p2m_type_t pt;
         unsigned long pfn;
+        mfn_t r_mfn;
=20
         d =3D rcu_lock_domain_by_id(domctl->domain);
         if ( d !=3D NULL )
         {
             pfn =3D domctl->u.set_broken_page_p2m.pfn;
=20
-            get_gfn_query(d, pfn, &pt);
+            r_mfn =3D get_gfn_query(d, pfn, &pt);
+            printk("@XEN_DOMCTL_set_broken_page_p2m, before set p2m, "
+                   "pfn=3D%lx, pt=3D%d\n", pfn, (int)pt);
+            if (!mfn_valid(mfn_x(r_mfn)))
+                printk("r_mfn IS INVALID!!!\n");
+
             p2m_change_type(d, pfn, pt, p2m_ram_broken);
             put_gfn(d, pfn);
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

--_003_DE8DF0795D48FD4CA783C40EC82923353611B9SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="test1.patch"
Content-Description: test1.patch
Content-Disposition: attachment; filename="test1.patch"; size=2861;
	creation-date="Fri, 19 Oct 2012 20:58:52 GMT";
	modification-date="Thu, 20 Sep 2012 01:18:28 GMT"
Content-Transfer-Encoding: base64

ZGlmZiAtciBhZDAyODA1Yzc3YjggeGVuL2FyY2gveDg2L2NwdS9tY2hlY2svdm1jZS5jCi0tLSBh
L3hlbi9hcmNoL3g4Ni9jcHUvbWNoZWNrL3ZtY2UuYwlTYXQgSnVsIDI4IDA2OjM1OjQ3IDIwMTIg
KzA4MDAKKysrIGIveGVuL2FyY2gveDg2L2NwdS9tY2hlY2svdm1jZS5jCVNhdCBBdWcgMjUgMDQ6
MDE6MTkgMjAxMiArMDgwMApAQCAtMjgsNiArMjgsNyBAQAogI2luY2x1ZGUgPHhlbi9zbXAuaD4K
ICNpbmNsdWRlIDx4ZW4vbW0uaD4KICNpbmNsdWRlIDx4ZW4vaHZtL3NhdmUuaD4KKyNpbmNsdWRl
IDx4ZW4va2V5aGFuZGxlci5oPgogI2luY2x1ZGUgPGFzbS9wcm9jZXNzb3IuaD4KICNpbmNsdWRl
IDxwdWJsaWMvc3lzY3RsLmg+CiAjaW5jbHVkZSA8YXNtL3N5c3RlbS5oPgpAQCAtNDQ5LDMgKzQ1
MCw5MyBAQAogICAgIHJldHVybiByYzsKIH0KIAorCisvKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqLworCit1bnNpZ25lZCBsb25nIGJyb2tlbl9wZm4g
PSAwOworCitzdGF0aWMgdm9pZCBzZW5kZXJfYnJva2VuX3BhZ2UodW5zaWduZWQgY2hhciBrZXkp
Cit7CisgICAgZG9taWRfdCBzZW5kZXJfZG9taWQgPSAxOworICAgIHN0cnVjdCBkb21haW4gKmQ7
CisgICAgc3RydWN0IHAybV9kb21haW4gKnAybTsKKyAgICB1bnNpZ25lZCBsb25nIHBmbjsKKyAg
ICBwMm1fdHlwZV90IHB0OworCisgICAgZCA9IHJjdV9sb2NrX2RvbWFpbl9ieV9pZChzZW5kZXJf
ZG9taWQpOworICAgIHAybSA9IHAybV9nZXRfaG9zdHAybShkKTsKKworICAgIGZvciAoIHBmbiA9
IDA7IHBmbiA8IHAybS0+bWF4X21hcHBlZF9wZm47IHBmbisrICkKKyAgICB7CisgICAgICAgIGdl
dF9nZm5fcXVlcnkoZCwgcGZuLCAmcHQpOworICAgICAgICBpZiAoIHVubGlrZWx5KHAybV9pc19i
cm9rZW4ocHQpKSApCisgICAgICAgIHsKKyAgICAgICAgICAgIHByaW50aygiISEhISEhIGJlZm9y
ZSBtaWdyYXRpb24sIGZpbmQgYnJva2VuIHBhZ2UsICIKKyAgICAgICAgICAgICAgICAgICAiZG9t
ID0gJWQsIHBmbiA9ICVseCwgcHQgPSAlZFxuIiwKKyAgICAgICAgICAgICAgICAgICAgKHVuc2ln
bmVkIGludClkLT5kb21haW5faWQsIHBmbiwgKHVuc2lnbmVkIGludClwdCk7CisgICAgICAgICAg
ICBicm9rZW5fcGZuID0gcGZuOworICAgICAgICB9CisgICAgICAgIHB1dF9nZm4oZCwgcGZuKTsK
KyAgICB9CisKKyAgICByY3VfdW5sb2NrX2RvbWFpbihkKTsKK30KKworc3RhdGljIHN0cnVjdCBr
ZXloYW5kbGVyIHNlbmRlcl9icm9rZW5fcGFnZV9rZXloYW5kbGVyID0geworICAgIC5kaWFnbm9z
dGljID0gMSwKKyAgICAudS5mbiA9IHNlbmRlcl9icm9rZW5fcGFnZSwKK307CisKK3N0YXRpYyBf
X2luaXQgaW50IHNlbmRlcl9icm9rZW5fcGFnZV9pbml0KHZvaWQpCit7CisgICAgcmVnaXN0ZXJf
a2V5aGFuZGxlcignNicsICZzZW5kZXJfYnJva2VuX3BhZ2Vfa2V5aGFuZGxlcik7CisgICAgcmV0
dXJuIDA7Cit9CitfX2luaXRjYWxsKHNlbmRlcl9icm9rZW5fcGFnZV9pbml0KTsKKworLyoqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiovCisKKworc3Rh
dGljIHZvaWQgdGFyZ2V0X2Jyb2tlbl9wYWdlKHVuc2lnbmVkIGNoYXIga2V5KQoreworICAgIGRv
bWlkX3QgdGFyZ2V0X2RvbWlkID0gMjsKKyAgICBzdHJ1Y3QgZG9tYWluICpkOworICAgIHN0cnVj
dCBwMm1fZG9tYWluICpwMm07CisgICAgdW5zaWduZWQgbG9uZyBwZm47CisgICAgcDJtX3R5cGVf
dCBwdDsKKworICAgIGQgPSByY3VfbG9ja19kb21haW5fYnlfaWQodGFyZ2V0X2RvbWlkKTsKKyAg
ICBwMm0gPSBwMm1fZ2V0X2hvc3RwMm0oZCk7CisKKyAgICBmb3IgKCBwZm4gPSAwOyBwZm4gPCBw
Mm0tPm1heF9tYXBwZWRfcGZuOyBwZm4rKyApCisgICAgeworICAgICAgICBnZXRfZ2ZuX3F1ZXJ5
KGQsIHBmbiwgJnB0KTsKKyAgICAgICAgaWYgKCB1bmxpa2VseShwMm1faXNfYnJva2VuKHB0KSkg
KQorICAgICAgICAgICAgcHJpbnRrKCJAQEBAQEAgYWZ0ZXIgbWlncmF0aW9uLCBmaW5kIGJyb2tl
biBwYWdlLCAiCisgICAgICAgICAgICAgICAgICAgImRvbSA9ICVkLCBwZm4gPSAlbHgsIHB0ID0g
JWRcbiIsCisgICAgICAgICAgICAgICAgICAgICh1bnNpZ25lZCBpbnQpZC0+ZG9tYWluX2lkLCBw
Zm4sICh1bnNpZ25lZCBpbnQpcHQpOworICAgICAgICBwdXRfZ2ZuKGQsIHBmbik7CisgICAgfQor
CisgICAgZ2V0X2dmbl9xdWVyeShkLCBicm9rZW5fcGZuLCAmcHQpOworICAgIHByaW50aygiQEBA
QEBAIGFmdGVyIG1pZ3JhdGlvbiwgYnJva2VuX3BmbiB0eXBlIGlzLCAiCisgICAgICAgICAgICJk
b20gPSAlZCwgYnJva2VuX3BmbiA9ICVseCwgcHQgPSAlZFxuIiwKKyAgICAgICAgICAgKHVuc2ln
bmVkIGludClkLT5kb21haW5faWQsIGJyb2tlbl9wZm4sICh1bnNpZ25lZCBpbnQpcHQpOworICAg
IHB1dF9nZm4oZCwgYnJva2VuX3Bmbik7CisKKyAgICByY3VfdW5sb2NrX2RvbWFpbihkKTsKK30K
Kworc3RhdGljIHN0cnVjdCBrZXloYW5kbGVyIHRhcmdldF9icm9rZW5fcGFnZV9rZXloYW5kbGVy
ID0geworICAgIC5kaWFnbm9zdGljID0gMSwKKyAgICAudS5mbiA9IHRhcmdldF9icm9rZW5fcGFn
ZSwKK307CisKK3N0YXRpYyBfX2luaXQgaW50IHRhcmdldF9icm9rZW5fcGFnZV9pbml0KHZvaWQp
Cit7CisgICAgcmVnaXN0ZXJfa2V5aGFuZGxlcignNycsICZ0YXJnZXRfYnJva2VuX3BhZ2Vfa2V5
aGFuZGxlcik7CisgICAgcmV0dXJuIDA7Cit9CitfX2luaXRjYWxsKHRhcmdldF9icm9rZW5fcGFn
ZV9pbml0KTsKKworLyoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqLwo=

--_003_DE8DF0795D48FD4CA783C40EC82923353611B9SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="test2.patch"
Content-Description: test2.patch
Content-Disposition: attachment; filename="test2.patch"; size=2128;
	creation-date="Fri, 19 Oct 2012 20:58:52 GMT";
	modification-date="Thu, 20 Sep 2012 01:18:28 GMT"
Content-Transfer-Encoding: base64

ZGlmZiAtciBkZTQ2MmYyZjFkYjggdG9vbHMvbGlieGMveGNfZG9tYWluX3Jlc3RvcmUuYwotLS0g
YS90b29scy9saWJ4Yy94Y19kb21haW5fcmVzdG9yZS5jCU1vbiBBdWcgMjcgMjE6Mzg6MTEgMjAx
MiArMDgwMAorKysgYi90b29scy9saWJ4Yy94Y19kb21haW5fcmVzdG9yZS5jCU1vbiBBdWcgMjcg
MjE6NTY6NTMgMjAxMiArMDgwMApAQCAtMTIwNyw4ICsxMjA3LDExIEBACiAKICAgICAgICAgaWYg
KCBwYWdldHlwZSA9PSBYRU5fRE9NQ1RMX1BGSU5GT19CUk9LRU4gKQogICAgICAgICB7CisgICAg
ICAgICAgICBmcHJpbnRmKHN0ZGVyciwgIkB0YXJnZXQsIGZpbmQgYnJva2VuIHBhZ2UsICIKKyAg
ICAgICAgICAgICAgICAgICAgICAiZG9tPSVkLCBwZm49MHglbHgsIHBhZ2V0eXBlPTB4JWx4XG4i
LCBkb20sIHBmbiwgcGFnZXR5cGUpOwogICAgICAgICAgICAgaWYgKCB4Y19zZXRfYnJva2VuX3Bh
Z2VfcDJtKHhjaCwgZG9tLCBwZm4pICkKICAgICAgICAgICAgIHsKKyAgICAgICAgICAgICAgICBm
cHJpbnRmKHN0ZGVyciwgIi4uLiBFUlJPUiBXSEVOIFNFVCBQMk0gRk9SIEJST0tFTiBQQUdFXG4i
KTsKICAgICAgICAgICAgICAgICBFUlJPUigiU2V0IHAybSBmb3IgYnJva2VuIHBhZ2UgZmFpbCwg
IgogICAgICAgICAgICAgICAgICAgICAgICJkb209JWQsIHBmbj0lbHhcbiIsIGRvbSwgcGZuKTsK
ICAgICAgICAgICAgICAgICBnb3RvIGVycl9tYXBwZWQ7CmRpZmYgLXIgZGU0NjJmMmYxZGI4IHRv
b2xzL2xpYnhjL3hjX2RvbWFpbl9zYXZlLmMKLS0tIGEvdG9vbHMvbGlieGMveGNfZG9tYWluX3Nh
dmUuYwlNb24gQXVnIDI3IDIxOjM4OjExIDIwMTIgKzA4MDAKKysrIGIvdG9vbHMvbGlieGMveGNf
ZG9tYWluX3NhdmUuYwlNb24gQXVnIDI3IDIxOjU2OjUzIDIwMTIgKzA4MDAKQEAgLTEyODksNiAr
MTI4OSw5IEBACiAgICAgICAgICAgICAgICAgewogICAgICAgICAgICAgICAgICAgICBwZm5fdHlw
ZVtqXSB8PSBwZm5fYmF0Y2hbal07CiAgICAgICAgICAgICAgICAgICAgICsrcnVuOworICAgICAg
ICAgICAgICAgICAgICBmcHJpbnRmKHN0ZGVyciwgIkBzZW5kZXIsIGZpbmQgYnJva2VuIHBhZ2Us
ICIKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAicGZuX2VyclsweCV4XT0lZCwgcGZuX3R5
cGVbMHgleF0gPSVseFxuIiwKKyAgICAgICAgICAgICAgICAgICAgKGludClqLCAoaW50KXBmbl9l
cnJbal0sIChpbnQpaiwgKHVuc2lnbmVkIGxvbmcpcGZuX3R5cGVbal0pOwogICAgICAgICAgICAg
ICAgICAgICBjb250aW51ZTsKICAgICAgICAgICAgICAgICB9CiAKZGlmZiAtciBkZTQ2MmYyZjFk
YjggeGVuL2FyY2gveDg2L2RvbWN0bC5jCi0tLSBhL3hlbi9hcmNoL3g4Ni9kb21jdGwuYwlNb24g
QXVnIDI3IDIxOjM4OjExIDIwMTIgKzA4MDAKKysrIGIveGVuL2FyY2gveDg2L2RvbWN0bC5jCU1v
biBBdWcgMjcgMjE6NTY6NTMgMjAxMiArMDgwMApAQCAtMTU2NiwxMyArMTU2NiwxOSBAQAogICAg
ICAgICBzdHJ1Y3QgZG9tYWluICpkOwogICAgICAgICBwMm1fdHlwZV90IHB0OwogICAgICAgICB1
bnNpZ25lZCBsb25nIHBmbjsKKyAgICAgICAgbWZuX3Qgcl9tZm47CiAKICAgICAgICAgZCA9IHJj
dV9sb2NrX2RvbWFpbl9ieV9pZChkb21jdGwtPmRvbWFpbik7CiAgICAgICAgIGlmICggZCAhPSBO
VUxMICkKICAgICAgICAgewogICAgICAgICAgICAgcGZuID0gZG9tY3RsLT51LnNldF9icm9rZW5f
cGFnZV9wMm0ucGZuOwogCi0gICAgICAgICAgICBnZXRfZ2ZuX3F1ZXJ5KGQsIHBmbiwgJnB0KTsK
KyAgICAgICAgICAgIHJfbWZuID0gZ2V0X2dmbl9xdWVyeShkLCBwZm4sICZwdCk7CisgICAgICAg
ICAgICBwcmludGsoIkBYRU5fRE9NQ1RMX3NldF9icm9rZW5fcGFnZV9wMm0sIGJlZm9yZSBzZXQg
cDJtLCAiCisgICAgICAgICAgICAgICAgICAgInBmbj0lbHgsIHB0PSVkXG4iLCBwZm4sIChpbnQp
cHQpOworICAgICAgICAgICAgaWYgKCFtZm5fdmFsaWQobWZuX3gocl9tZm4pKSkKKyAgICAgICAg
ICAgICAgICBwcmludGsoInJfbWZuIElTIElOVkFMSUQhISFcbiIpOworCiAgICAgICAgICAgICBw
Mm1fY2hhbmdlX3R5cGUoZCwgcGZuLCBwdCwgcDJtX3JhbV9icm9rZW4pOwogICAgICAgICAgICAg
cHV0X2dmbihkLCBwZm4pOwogCg==

--_003_DE8DF0795D48FD4CA783C40EC82923353611B9SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_003_DE8DF0795D48FD4CA783C40EC82923353611B9SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Fri Oct 19 22:03:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 22:03:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPKep-00081z-4g; Fri, 19 Oct 2012 22:03:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPKen-00081u-Mh
	for xen-devel@lists.xensource.com; Fri, 19 Oct 2012 22:03:05 +0000
Received: from [85.158.139.211:28051] by server-7.bemta-5.messagelabs.com id
	64/A4-23102-81EC1805; Fri, 19 Oct 2012 22:03:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1350684183!23035510!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUwMDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25562 invoked from network); 19 Oct 2012 22:03:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 22:03:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,617,1344211200"; d="scan'208";a="15286426"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 22:03:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 19 Oct 2012 23:03:03 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TPKel-000395-8S;
	Fri, 19 Oct 2012 22:03:03 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TPKek-0001hz-UN;
	Fri, 19 Oct 2012 23:03:03 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Fri, 19 Oct 2012 23:03:02 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14064: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14064 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14064/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13967
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13967
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13967
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13967

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  478ba3f146df
baseline version:
 xen                  c1c549c4fe9e

------------------------------------------------------------
People who touched revisions under test:
  Chuang Cao 
  Daniel De Graaf 
  Huang Ying 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Joe Jin 
  Keir Fraser 
  Olaf Hering 
  Sander Eikelenboom 
  Stefano Stabellini 
  Tim Deegan 
  Wei Wang 
  Xiantao Zhang
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=478ba3f146df
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 478ba3f146df
+ branch=xen-unstable
+ revision=478ba3f146df
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 478ba3f146df ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 33 changesets with 141 changes to 116 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 22:03:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 22:03:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPKep-00081z-4g; Fri, 19 Oct 2012 22:03:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPKen-00081u-Mh
	for xen-devel@lists.xensource.com; Fri, 19 Oct 2012 22:03:05 +0000
Received: from [85.158.139.211:28051] by server-7.bemta-5.messagelabs.com id
	64/A4-23102-81EC1805; Fri, 19 Oct 2012 22:03:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1350684183!23035510!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUwMDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25562 invoked from network); 19 Oct 2012 22:03:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Oct 2012 22:03:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,617,1344211200"; d="scan'208";a="15286426"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Oct 2012 22:03:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 19 Oct 2012 23:03:03 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TPKel-000395-8S;
	Fri, 19 Oct 2012 22:03:03 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TPKek-0001hz-UN;
	Fri, 19 Oct 2012 23:03:03 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Fri, 19 Oct 2012 23:03:02 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14064: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14064 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14064/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13967
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13967
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13967
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13967

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  478ba3f146df
baseline version:
 xen                  c1c549c4fe9e

------------------------------------------------------------
People who touched revisions under test:
  Chuang Cao 
  Daniel De Graaf 
  Huang Ying 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Joe Jin 
  Keir Fraser 
  Olaf Hering 
  Sander Eikelenboom 
  Stefano Stabellini 
  Tim Deegan 
  Wei Wang 
  Xiantao Zhang
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=478ba3f146df
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 478ba3f146df
+ branch=xen-unstable
+ revision=478ba3f146df
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 478ba3f146df ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 33 changesets with 141 changes to 116 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 23:13:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 23:13:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPLke-000129-7c; Fri, 19 Oct 2012 23:13:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPLkd-00011w-4o
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 23:13:11 +0000
Received: from [85.158.139.83:49123] by server-3.bemta-5.messagelabs.com id
	F7/65-28618-68ED1805; Fri, 19 Oct 2012 23:13:10 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-15.tower-182.messagelabs.com!1350688389!33481991!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25974 invoked from network); 19 Oct 2012 23:13:09 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-15.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	19 Oct 2012 23:13:09 -0000
Received: from 50-66-ftth.onsneteindhoven.nl ([88.159.66.50]:35324
	helo=localhost.localdomain) by smtp.eikelenboom.it with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72)
	(envelope-from )
	id 1TPLmN-0005E8-Nl; Sat, 20 Oct 2012 01:14:59 +0200
From: linux@eikelenboom.it
To: xen-devel@lists.xen.org
Date: Sat, 20 Oct 2012 01:13:04 +0200
Message-Id: <1350688384-2482-2-git-send-email-linux@eikelenboom.it>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1350688384-2482-1-git-send-email-linux@eikelenboom.it>
References: <1350688384-2482-1-git-send-email-linux@eikelenboom.it>
Cc: Ian.Jackson@eu.citrix.com, ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH 1/1] xl: Fix accidently waiting for domains to
	shutdown without --wait option
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Sander Eikelenboom 

Introduced by changeset 26091: "xl: Add --wait and --all to xl reboot."

Signed-off-by: Sander Eikelenboom 
---
 tools/libxl/xl_cmdimpl.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index dc80595..0e65f2b 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3774,7 +3774,9 @@ static int main_shutdown_or_reboot(int reboot, int argc, char **argv)
                fallback_trigger);
         }
 
-        wait_for_domain_deaths(deathws, nb_domain - 1 /* not dom 0 */);
+        if (wait_for_it)
+            wait_for_domain_deaths(deathws, nb_domain - 1 /* not dom 0 */);
+
         libxl_dominfo_list_free(dominfo, nb_domain);
     } else {
         libxl_evgen_domain_death *deathw = NULL;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 23:13:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 23:13:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPLke-000129-7c; Fri, 19 Oct 2012 23:13:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPLkd-00011w-4o
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 23:13:11 +0000
Received: from [85.158.139.83:49123] by server-3.bemta-5.messagelabs.com id
	F7/65-28618-68ED1805; Fri, 19 Oct 2012 23:13:10 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-15.tower-182.messagelabs.com!1350688389!33481991!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25974 invoked from network); 19 Oct 2012 23:13:09 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-15.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	19 Oct 2012 23:13:09 -0000
Received: from 50-66-ftth.onsneteindhoven.nl ([88.159.66.50]:35324
	helo=localhost.localdomain) by smtp.eikelenboom.it with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72)
	(envelope-from )
	id 1TPLmN-0005E8-Nl; Sat, 20 Oct 2012 01:14:59 +0200
From: linux@eikelenboom.it
To: xen-devel@lists.xen.org
Date: Sat, 20 Oct 2012 01:13:04 +0200
Message-Id: <1350688384-2482-2-git-send-email-linux@eikelenboom.it>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1350688384-2482-1-git-send-email-linux@eikelenboom.it>
References: <1350688384-2482-1-git-send-email-linux@eikelenboom.it>
Cc: Ian.Jackson@eu.citrix.com, ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH 1/1] xl: Fix accidently waiting for domains to
	shutdown without --wait option
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Sander Eikelenboom 

Introduced by changeset 26091: "xl: Add --wait and --all to xl reboot."

Signed-off-by: Sander Eikelenboom 
---
 tools/libxl/xl_cmdimpl.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index dc80595..0e65f2b 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3774,7 +3774,9 @@ static int main_shutdown_or_reboot(int reboot, int argc, char **argv)
                fallback_trigger);
         }
 
-        wait_for_domain_deaths(deathws, nb_domain - 1 /* not dom 0 */);
+        if (wait_for_it)
+            wait_for_domain_deaths(deathws, nb_domain - 1 /* not dom 0 */);
+
         libxl_dominfo_list_free(dominfo, nb_domain);
     } else {
         libxl_evgen_domain_death *deathw = NULL;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 23:13:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 23:13:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPLke-00012G-Iy; Fri, 19 Oct 2012 23:13:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPLkd-00011x-57
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 23:13:11 +0000
Received: from [85.158.143.99:27713] by server-1.bemta-4.messagelabs.com id
	4D/79-19134-68ED1805; Fri, 19 Oct 2012 23:13:10 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-7.tower-216.messagelabs.com!1350688389!28713023!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30431 invoked from network); 19 Oct 2012 23:13:09 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-7.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	19 Oct 2012 23:13:09 -0000
Received: from 50-66-ftth.onsneteindhoven.nl ([88.159.66.50]:35324
	helo=localhost.localdomain) by smtp.eikelenboom.it with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72)
	(envelope-from )
	id 1TPLmN-0005E8-Hg; Sat, 20 Oct 2012 01:14:59 +0200
From: linux@eikelenboom.it
To: xen-devel@lists.xen.org
Date: Sat, 20 Oct 2012 01:13:03 +0200
Message-Id: <1350688384-2482-1-git-send-email-linux@eikelenboom.it>
X-Mailer: git-send-email 1.7.2.5
Cc: Ian.Jackson@eu.citrix.com, ian.campbell@citrix.com
Subject: [Xen-devel] xl: Fix accidently waiting for domains to shutdown
	without --wait option
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

xl: Fix accidently waiting for domains to shutdown without --wait option


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 19 23:13:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 19 Oct 2012 23:13:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPLke-00012G-Iy; Fri, 19 Oct 2012 23:13:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPLkd-00011x-57
	for xen-devel@lists.xen.org; Fri, 19 Oct 2012 23:13:11 +0000
Received: from [85.158.143.99:27713] by server-1.bemta-4.messagelabs.com id
	4D/79-19134-68ED1805; Fri, 19 Oct 2012 23:13:10 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-7.tower-216.messagelabs.com!1350688389!28713023!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30431 invoked from network); 19 Oct 2012 23:13:09 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-7.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	19 Oct 2012 23:13:09 -0000
Received: from 50-66-ftth.onsneteindhoven.nl ([88.159.66.50]:35324
	helo=localhost.localdomain) by smtp.eikelenboom.it with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72)
	(envelope-from )
	id 1TPLmN-0005E8-Hg; Sat, 20 Oct 2012 01:14:59 +0200
From: linux@eikelenboom.it
To: xen-devel@lists.xen.org
Date: Sat, 20 Oct 2012 01:13:03 +0200
Message-Id: <1350688384-2482-1-git-send-email-linux@eikelenboom.it>
X-Mailer: git-send-email 1.7.2.5
Cc: Ian.Jackson@eu.citrix.com, ian.campbell@citrix.com
Subject: [Xen-devel] xl: Fix accidently waiting for domains to shutdown
	without --wait option
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

xl: Fix accidently waiting for domains to shutdown without --wait option


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 20 01:24:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Oct 2012 01:24:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPNnE-0005t6-13; Sat, 20 Oct 2012 01:24:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPNnC-0005t1-DR
	for xen-devel@lists.xensource.com; Sat, 20 Oct 2012 01:23:58 +0000
Received: from [85.158.137.99:5868] by server-5.bemta-3.messagelabs.com id
	14/8A-12440-D2DF1805; Sat, 20 Oct 2012 01:23:57 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1350696235!17251366!1
X-Originating-IP: [209.85.223.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2219 invoked from network); 20 Oct 2012 01:23:56 -0000
Received: from mail-ie0-f171.google.com (HELO mail-ie0-f171.google.com)
	(209.85.223.171)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Oct 2012 01:23:56 -0000
Received: by mail-ie0-f171.google.com with SMTP id s9so1911139iec.30
	for ;
	Fri, 19 Oct 2012 18:23:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=dlu4zrbSXXuYfS4RWn1duUKXCcLk4RsFryblk8n1/tQ=;
	b=KbQpgQ8By+1q6swr0fwzNg2ewzLNINh3lI9OdNcH/MlogWR2z+noI3HBuvxiP3+AN8
	nU2L/Wzl269uejdquHI/Qjx9Ss8Eu51806ZL5csYyiJgWcsH2BrglwSF6RgTB0vw6qpe
	1LTguslNIgqdHnWph+Z7Twx7UxzpkKBcjk9uIrQYhk7GxwQEwzK5fVJ4S0VI/DoG+x/5
	kxP1Vn8YyEy7fBFiKzrymQXkCJXc91hgxEB0Ys9A97c5DfyKyMY06QpB67GJXgAvebH8
	CpRypnTH0GHUptP/pU7LMdjZT1cfWEQJhHcJJYUowObNhQSZWPdfGOv7INauQ+6j6uHi
	CQjw==
MIME-Version: 1.0
Received: by 10.50.94.198 with SMTP id de6mr3207135igb.49.1350696235284; Fri,
	19 Oct 2012 18:23:55 -0700 (PDT)
Received: by 10.231.193.227 with HTTP; Fri, 19 Oct 2012 18:23:55 -0700 (PDT)
In-Reply-To: <20121019184908.GA19834@phenom.dumpdata.com>
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	
	<20121017174317.GA25443@phenom.dumpdata.com>
	
	<20121019184908.GA19834@phenom.dumpdata.com>
Date: Fri, 19 Oct 2012 21:23:55 -0400
X-Google-Sender-Auth: 5OC3HEgsoZ9QHNUNUzWLzum3NVQ
Message-ID: 
From: Ben Guthro 
To: Konrad Rzeszutek Wilk 
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, hpa@zytor.com, lenb@kernel.org
Subject: Re: [Xen-devel] [RFC] ACPI S3 and Xen (suprisingly small\!).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

ack.
I'm happy to test a 2nd round, if you CC me on any fixed patches (just
in case I'm not monitoring lkml / xen-devel on that particular day)

On Fri, Oct 19, 2012 at 2:49 PM, Konrad Rzeszutek Wilk
 wrote:
> On Wed, Oct 17, 2012 at 02:00:29PM -0400, Ben Guthro wrote:
>> I'm not sure it matters, but I'm testing against a changeset about a week old:
>> http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=1c4a5b37b55c56e49135e65728137f54288d1fe6
>
> I was able to reproduce it with Xen 4.2 so found the culprit.
>
> .. And then another issue :-(
>
>>
>> Plus patches specific to XenClient Enterprise.
>>
>>
>> On Wed, Oct 17, 2012 at 1:43 PM, Konrad Rzeszutek Wilk
>>  wrote:
>> > On Wed, Oct 17, 2012 at 01:46:09PM -0400, Ben Guthro wrote:
>> >> On Wed, Oct 17, 2012 at 9:49 AM, Konrad Rzeszutek Wilk
>> >>  wrote:
>> >> [...]
>> >>
>> >> > The end result is this is a nice set of patches where there is only
>> >> > _one_ change in the x86 code (and it is just more of dealing with
>> >> > error case) - and the rest are all done in Xen side.
>> >>
>> >> I'm sorry to report that this series doesn't seem to work in my setup
>> >> against xen-unstable.
>> >>
>> >> To verify that it was, in fact this patch series, and not another Xen
>> >> regression - I swapped out the kernel with this patch series, with an
>> >> identical one, replacing only this series with your acpi-s3.v9 branch
>> >> - and everything worked fine.
>> >
>> > Thanks for testing it!
>> >
>> > I had tested it with Xen 4.1.3, which could be doing something different.
>> > Will see what is up.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 20 01:24:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Oct 2012 01:24:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPNnE-0005t6-13; Sat, 20 Oct 2012 01:24:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPNnC-0005t1-DR
	for xen-devel@lists.xensource.com; Sat, 20 Oct 2012 01:23:58 +0000
Received: from [85.158.137.99:5868] by server-5.bemta-3.messagelabs.com id
	14/8A-12440-D2DF1805; Sat, 20 Oct 2012 01:23:57 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1350696235!17251366!1
X-Originating-IP: [209.85.223.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2219 invoked from network); 20 Oct 2012 01:23:56 -0000
Received: from mail-ie0-f171.google.com (HELO mail-ie0-f171.google.com)
	(209.85.223.171)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Oct 2012 01:23:56 -0000
Received: by mail-ie0-f171.google.com with SMTP id s9so1911139iec.30
	for ;
	Fri, 19 Oct 2012 18:23:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=dlu4zrbSXXuYfS4RWn1duUKXCcLk4RsFryblk8n1/tQ=;
	b=KbQpgQ8By+1q6swr0fwzNg2ewzLNINh3lI9OdNcH/MlogWR2z+noI3HBuvxiP3+AN8
	nU2L/Wzl269uejdquHI/Qjx9Ss8Eu51806ZL5csYyiJgWcsH2BrglwSF6RgTB0vw6qpe
	1LTguslNIgqdHnWph+Z7Twx7UxzpkKBcjk9uIrQYhk7GxwQEwzK5fVJ4S0VI/DoG+x/5
	kxP1Vn8YyEy7fBFiKzrymQXkCJXc91hgxEB0Ys9A97c5DfyKyMY06QpB67GJXgAvebH8
	CpRypnTH0GHUptP/pU7LMdjZT1cfWEQJhHcJJYUowObNhQSZWPdfGOv7INauQ+6j6uHi
	CQjw==
MIME-Version: 1.0
Received: by 10.50.94.198 with SMTP id de6mr3207135igb.49.1350696235284; Fri,
	19 Oct 2012 18:23:55 -0700 (PDT)
Received: by 10.231.193.227 with HTTP; Fri, 19 Oct 2012 18:23:55 -0700 (PDT)
In-Reply-To: <20121019184908.GA19834@phenom.dumpdata.com>
References: <1350481786-4969-1-git-send-email-konrad.wilk@oracle.com>
	
	<20121017174317.GA25443@phenom.dumpdata.com>
	
	<20121019184908.GA19834@phenom.dumpdata.com>
Date: Fri, 19 Oct 2012 21:23:55 -0400
X-Google-Sender-Auth: 5OC3HEgsoZ9QHNUNUzWLzum3NVQ
Message-ID: 
From: Ben Guthro 
To: Konrad Rzeszutek Wilk 
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, hpa@zytor.com, lenb@kernel.org
Subject: Re: [Xen-devel] [RFC] ACPI S3 and Xen (suprisingly small\!).
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

ack.
I'm happy to test a 2nd round, if you CC me on any fixed patches (just
in case I'm not monitoring lkml / xen-devel on that particular day)

On Fri, Oct 19, 2012 at 2:49 PM, Konrad Rzeszutek Wilk
 wrote:
> On Wed, Oct 17, 2012 at 02:00:29PM -0400, Ben Guthro wrote:
>> I'm not sure it matters, but I'm testing against a changeset about a week old:
>> http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=1c4a5b37b55c56e49135e65728137f54288d1fe6
>
> I was able to reproduce it with Xen 4.2 so found the culprit.
>
> .. And then another issue :-(
>
>>
>> Plus patches specific to XenClient Enterprise.
>>
>>
>> On Wed, Oct 17, 2012 at 1:43 PM, Konrad Rzeszutek Wilk
>>  wrote:
>> > On Wed, Oct 17, 2012 at 01:46:09PM -0400, Ben Guthro wrote:
>> >> On Wed, Oct 17, 2012 at 9:49 AM, Konrad Rzeszutek Wilk
>> >>  wrote:
>> >> [...]
>> >>
>> >> > The end result is this is a nice set of patches where there is only
>> >> > _one_ change in the x86 code (and it is just more of dealing with
>> >> > error case) - and the rest are all done in Xen side.
>> >>
>> >> I'm sorry to report that this series doesn't seem to work in my setup
>> >> against xen-unstable.
>> >>
>> >> To verify that it was, in fact this patch series, and not another Xen
>> >> regression - I swapped out the kernel with this patch series, with an
>> >> identical one, replacing only this series with your acpi-s3.v9 branch
>> >> - and everything worked fine.
>> >
>> > Thanks for testing it!
>> >
>> > I had tested it with Xen 4.1.3, which could be doing something different.
>> > Will see what is up.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 20 01:30:45 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Oct 2012 01:30:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPNtP-00062g-Gs; Sat, 20 Oct 2012 01:30:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPNtM-00061l-Mw
	for xen-devel@lists.xensource.com; Sat, 20 Oct 2012 01:30:20 +0000
Received: from [85.158.143.35:26681] by server-3.bemta-4.messagelabs.com id
	68/23-03544-CAEF1805; Sat, 20 Oct 2012 01:30:20 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1350696617!14778164!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODE2OTk0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3498 invoked from network); 20 Oct 2012 01:30:19 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Oct 2012 01:30:19 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9K1UCrd012043
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 20 Oct 2012 01:30:12 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9K1UBZ3007022
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 20 Oct 2012 01:30:11 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9K1UBvZ011685; Fri, 19 Oct 2012 20:30:11 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Oct 2012 18:30:11 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B3F174042F; Fri, 19 Oct 2012 21:18:05 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	mukesh.rathor@oracle.com, Ian.Campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Date: Fri, 19 Oct 2012 21:18:02 -0400
Message-Id: <1350695882-12820-7-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 6/6] xen/pvh: /dev/xen/privcmd changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Mukesh Rathor 

PVH only supports the batch interface. To map a foreign page to a process,
the PFN must be allocated and PVH path uses ballooning for that purpose.

The returned PFN is then mapped to the foreign page.
xen_unmap_domain_mfn_range() is introduced to unmap these pages via the
privcmd close call.

Signed-off-by: Mukesh Rathor 
[v1: Fix up privcmd_close]
Signed-off-by: Konrad Rzeszutek Wilk 
---
 drivers/xen/privcmd.c |   69 +++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 67 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index b612267..b9d0898 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -33,11 +33,14 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "privcmd.h"
 
 MODULE_LICENSE("GPL");
 
+#define PRIV_VMA_LOCKED ((void *)1)
+
 #ifndef HAVE_ARCH_PRIVCMD_MMAP
 static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma);
 #endif
@@ -199,6 +202,10 @@ static long privcmd_ioctl_mmap(void __user *udata)
 	if (!xen_initial_domain())
 		return -EPERM;
 
+	/* We only support privcmd_ioctl_mmap_batch for auto translated. */
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return -ENOSYS;
+
 	if (copy_from_user(&mmapcmd, udata, sizeof(mmapcmd)))
 		return -EFAULT;
 
@@ -246,6 +253,7 @@ struct mmap_batch_state {
 	domid_t domain;
 	unsigned long va;
 	struct vm_area_struct *vma;
+	int index;
 	/* A tristate:
 	 *      0 for no errors
 	 *      1 if at least one error has happened (and no
@@ -260,15 +268,24 @@ struct mmap_batch_state {
 	xen_pfn_t __user *user_mfn;
 };
 
+/* auto translated dom0 note: if domU being created is PV, then mfn is
+ * mfn(addr on bus). If it's auto xlated, then mfn is pfn (input to HAP).
+ */
 static int mmap_batch_fn(void *data, void *state)
 {
 	xen_pfn_t *mfnp = data;
 	struct mmap_batch_state *st = state;
+	struct vm_area_struct *vma = st->vma;
+	struct page **pages = vma->vm_private_data;
+	struct page *cur_page = NULL;
 	int ret;
 
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		cur_page = pages[st->index++];
+
 	ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
 					 st->vma->vm_page_prot, st->domain,
-					 NULL);
+					 &cur_page);
 
 	/* Store error code for second pass. */
 	*(st->err++) = ret;
@@ -304,6 +321,32 @@ static int mmap_return_errors_v1(void *data, void *state)
 	return __put_user(*mfnp, st->user_mfn++);
 }
 
+/* Allocate pfns that are then mapped with gmfns from foreign domid. Update
+ * the vma with the page info to use later.
+ * Returns: 0 if success, otherwise -errno
+ */
+static int alloc_empty_pages(struct vm_area_struct *vma, int numpgs)
+{
+	int rc;
+	struct page **pages;
+
+	pages = kcalloc(numpgs, sizeof(pages[0]), GFP_KERNEL);
+	if (pages == NULL)
+		return -ENOMEM;
+
+	rc = alloc_xenballooned_pages(numpgs, pages, 0);
+	if (rc != 0) {
+		pr_warn("%s Could not alloc %d pfns rc:%d\n", __func__,
+			numpgs, rc);
+		kfree(pages);
+		return -ENOMEM;
+	}
+	BUG_ON(vma->vm_private_data != PRIV_VMA_LOCKED);
+	vma->vm_private_data = pages;
+
+	return 0;
+}
+
 static struct vm_operations_struct privcmd_vm_ops;
 
 static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
@@ -371,10 +414,18 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
 		up_write(&mm->mmap_sem);
 		goto out;
 	}
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		ret = alloc_empty_pages(vma, m.num);
+		if (ret < 0) {
+			up_write(&mm->mmap_sem);
+			goto out;
+		}
+	}
 
 	state.domain        = m.dom;
 	state.vma           = vma;
 	state.va            = m.addr;
+	state.index         = 0;
 	state.global_error  = 0;
 	state.err           = err_array;
 
@@ -439,6 +490,19 @@ static long privcmd_ioctl(struct file *file,
 	return ret;
 }
 
+static void privcmd_close(struct vm_area_struct *vma)
+{
+	struct page **pages = vma->vm_private_data;
+	int numpgs = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
+
+	if (!xen_feature(XENFEAT_auto_translated_physmap || !numpgs || !pages))
+		return;
+
+	xen_unmap_domain_mfn_range(vma, numpgs, pages);
+	free_xenballooned_pages(numpgs, pages);
+	kfree(pages);
+}
+
 static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
 {
 	printk(KERN_DEBUG "privcmd_fault: vma=%p %lx-%lx, pgoff=%lx, uv=%p\n",
@@ -449,6 +513,7 @@ static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
 }
 
 static struct vm_operations_struct privcmd_vm_ops = {
+	.close = privcmd_close,
 	.fault = privcmd_fault
 };
 
@@ -466,7 +531,7 @@ static int privcmd_mmap(struct file *file, struct vm_area_struct *vma)
 
 static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma)
 {
-	return (xchg(&vma->vm_private_data, (void *)1) == NULL);
+	return !cmpxchg(&vma->vm_private_data, NULL, PRIV_VMA_LOCKED);
 }
 
 const struct file_operations xen_privcmd_fops = {
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 20 01:30:45 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Oct 2012 01:30:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPNtP-00062g-Gs; Sat, 20 Oct 2012 01:30:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPNtM-00061l-Mw
	for xen-devel@lists.xensource.com; Sat, 20 Oct 2012 01:30:20 +0000
Received: from [85.158.143.35:26681] by server-3.bemta-4.messagelabs.com id
	68/23-03544-CAEF1805; Sat, 20 Oct 2012 01:30:20 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1350696617!14778164!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODE2OTk0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3498 invoked from network); 20 Oct 2012 01:30:19 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Oct 2012 01:30:19 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9K1UCrd012043
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 20 Oct 2012 01:30:12 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9K1UBZ3007022
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 20 Oct 2012 01:30:11 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9K1UBvZ011685; Fri, 19 Oct 2012 20:30:11 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Oct 2012 18:30:11 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B3F174042F; Fri, 19 Oct 2012 21:18:05 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	mukesh.rathor@oracle.com, Ian.Campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Date: Fri, 19 Oct 2012 21:18:02 -0400
Message-Id: <1350695882-12820-7-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 6/6] xen/pvh: /dev/xen/privcmd changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Mukesh Rathor 

PVH only supports the batch interface. To map a foreign page to a process,
the PFN must be allocated and PVH path uses ballooning for that purpose.

The returned PFN is then mapped to the foreign page.
xen_unmap_domain_mfn_range() is introduced to unmap these pages via the
privcmd close call.

Signed-off-by: Mukesh Rathor 
[v1: Fix up privcmd_close]
Signed-off-by: Konrad Rzeszutek Wilk 
---
 drivers/xen/privcmd.c |   69 +++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 67 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index b612267..b9d0898 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -33,11 +33,14 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "privcmd.h"
 
 MODULE_LICENSE("GPL");
 
+#define PRIV_VMA_LOCKED ((void *)1)
+
 #ifndef HAVE_ARCH_PRIVCMD_MMAP
 static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma);
 #endif
@@ -199,6 +202,10 @@ static long privcmd_ioctl_mmap(void __user *udata)
 	if (!xen_initial_domain())
 		return -EPERM;
 
+	/* We only support privcmd_ioctl_mmap_batch for auto translated. */
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return -ENOSYS;
+
 	if (copy_from_user(&mmapcmd, udata, sizeof(mmapcmd)))
 		return -EFAULT;
 
@@ -246,6 +253,7 @@ struct mmap_batch_state {
 	domid_t domain;
 	unsigned long va;
 	struct vm_area_struct *vma;
+	int index;
 	/* A tristate:
 	 *      0 for no errors
 	 *      1 if at least one error has happened (and no
@@ -260,15 +268,24 @@ struct mmap_batch_state {
 	xen_pfn_t __user *user_mfn;
 };
 
+/* auto translated dom0 note: if domU being created is PV, then mfn is
+ * mfn(addr on bus). If it's auto xlated, then mfn is pfn (input to HAP).
+ */
 static int mmap_batch_fn(void *data, void *state)
 {
 	xen_pfn_t *mfnp = data;
 	struct mmap_batch_state *st = state;
+	struct vm_area_struct *vma = st->vma;
+	struct page **pages = vma->vm_private_data;
+	struct page *cur_page = NULL;
 	int ret;
 
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		cur_page = pages[st->index++];
+
 	ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
 					 st->vma->vm_page_prot, st->domain,
-					 NULL);
+					 &cur_page);
 
 	/* Store error code for second pass. */
 	*(st->err++) = ret;
@@ -304,6 +321,32 @@ static int mmap_return_errors_v1(void *data, void *state)
 	return __put_user(*mfnp, st->user_mfn++);
 }
 
+/* Allocate pfns that are then mapped with gmfns from foreign domid. Update
+ * the vma with the page info to use later.
+ * Returns: 0 if success, otherwise -errno
+ */
+static int alloc_empty_pages(struct vm_area_struct *vma, int numpgs)
+{
+	int rc;
+	struct page **pages;
+
+	pages = kcalloc(numpgs, sizeof(pages[0]), GFP_KERNEL);
+	if (pages == NULL)
+		return -ENOMEM;
+
+	rc = alloc_xenballooned_pages(numpgs, pages, 0);
+	if (rc != 0) {
+		pr_warn("%s Could not alloc %d pfns rc:%d\n", __func__,
+			numpgs, rc);
+		kfree(pages);
+		return -ENOMEM;
+	}
+	BUG_ON(vma->vm_private_data != PRIV_VMA_LOCKED);
+	vma->vm_private_data = pages;
+
+	return 0;
+}
+
 static struct vm_operations_struct privcmd_vm_ops;
 
 static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
@@ -371,10 +414,18 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
 		up_write(&mm->mmap_sem);
 		goto out;
 	}
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		ret = alloc_empty_pages(vma, m.num);
+		if (ret < 0) {
+			up_write(&mm->mmap_sem);
+			goto out;
+		}
+	}
 
 	state.domain        = m.dom;
 	state.vma           = vma;
 	state.va            = m.addr;
+	state.index         = 0;
 	state.global_error  = 0;
 	state.err           = err_array;
 
@@ -439,6 +490,19 @@ static long privcmd_ioctl(struct file *file,
 	return ret;
 }
 
+static void privcmd_close(struct vm_area_struct *vma)
+{
+	struct page **pages = vma->vm_private_data;
+	int numpgs = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
+
+	if (!xen_feature(XENFEAT_auto_translated_physmap || !numpgs || !pages))
+		return;
+
+	xen_unmap_domain_mfn_range(vma, numpgs, pages);
+	free_xenballooned_pages(numpgs, pages);
+	kfree(pages);
+}
+
 static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
 {
 	printk(KERN_DEBUG "privcmd_fault: vma=%p %lx-%lx, pgoff=%lx, uv=%p\n",
@@ -449,6 +513,7 @@ static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
 }
 
 static struct vm_operations_struct privcmd_vm_ops = {
+	.close = privcmd_close,
 	.fault = privcmd_fault
 };
 
@@ -466,7 +531,7 @@ static int privcmd_mmap(struct file *file, struct vm_area_struct *vma)
 
 static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma)
 {
-	return (xchg(&vma->vm_private_data, (void *)1) == NULL);
+	return !cmpxchg(&vma->vm_private_data, NULL, PRIV_VMA_LOCKED);
 }
 
 const struct file_operations xen_privcmd_fops = {
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 20 01:30:46 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Oct 2012 01:30:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPNtQ-000633-2R; Sat, 20 Oct 2012 01:30:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPNtN-000628-Ie
	for xen-devel@lists.xensource.com; Sat, 20 Oct 2012 01:30:21 +0000
Received: from [85.158.139.211:6907] by server-5.bemta-5.messagelabs.com id
	75/D7-09732-CAEF1805; Sat, 20 Oct 2012 01:30:20 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1350696618!23046761!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODE2OTk0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2719 invoked from network); 20 Oct 2012 01:30:19 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-4.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Oct 2012 01:30:19 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9K1UAsG012027
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 20 Oct 2012 01:30:11 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9K1UAuN028411
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 20 Oct 2012 01:30:10 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9K1U9Uj011678; Fri, 19 Oct 2012 20:30:09 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Oct 2012 18:30:09 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id A269A4042D; Fri, 19 Oct 2012 21:18:05 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	mukesh.rathor@oracle.com, Ian.Campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Date: Fri, 19 Oct 2012 21:18:00 -0400
Message-Id: <1350695882-12820-5-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 4/6] xen/pvh: bootup and setup related changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Mukesh Rathor 

In enlighten.c for PVH we can trap cpuid via vmexit, so don't
need to use emulated prefix call. We also check for vector callback
early on, as it is a required feature. PVH also runs at default kernel
IOPL.

In setup.c, in xen_add_extra_mem() we can skip updating P2M as it's managed
by Xen. PVH maps the entire IO space, but only RAM pages need to be repopulated.

Finally, pure PV settings are moved to a separate function that is only called
for pure PV, ie, pv with pvmmu.

Signed-off-by: Mukesh Rathor 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/xen/enlighten.c |   77 ++++++++++++++++++++++++++++++++++-----------
 arch/x86/xen/setup.c     |   64 +++++++++++++++++++++++++++++++-------
 2 files changed, 110 insertions(+), 31 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index e3497f2..53db37f 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -45,6 +45,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -107,6 +108,9 @@ RESERVE_BRK(shared_info_page_brk, PAGE_SIZE);
 __read_mostly int xen_have_vector_callback;
 EXPORT_SYMBOL_GPL(xen_have_vector_callback);
 
+#define xen_pvh_domain() (xen_pv_domain() && \
+			  xen_feature(XENFEAT_auto_translated_physmap) && \
+			  xen_have_vector_callback)
 /*
  * Point at some empty memory to start with. We map the real shared_info
  * page as soon as fixmap is up and running.
@@ -219,8 +223,9 @@ static void __init xen_banner(void)
 	struct xen_extraversion extra;
 	HYPERVISOR_xen_version(XENVER_extraversion, &extra);
 
-	printk(KERN_INFO "Booting paravirtualized kernel on %s\n",
-	       pv_info.name);
+	pr_info("Booting paravirtualized kernel %son %s\n",
+		xen_feature(XENFEAT_auto_translated_physmap) ?
+			"with PVH extensions " : "", pv_info.name);
 	printk(KERN_INFO "Xen version: %d.%d%s%s\n",
 	       version >> 16, version & 0xffff, extra.extraversion,
 	       xen_feature(XENFEAT_mmu_pt_update_preserve_ad) ? " (preserve-AD)" : "");
@@ -273,12 +278,15 @@ static void xen_cpuid(unsigned int *ax, unsigned int *bx,
 		break;
 	}
 
-	asm(XEN_EMULATE_PREFIX "cpuid"
-		: "=a" (*ax),
-		  "=b" (*bx),
-		  "=c" (*cx),
-		  "=d" (*dx)
-		: "0" (*ax), "2" (*cx));
+	if (xen_pvh_domain())
+		native_cpuid(ax, bx, cx, dx);
+	else
+		asm(XEN_EMULATE_PREFIX "cpuid"
+			: "=a" (*ax),
+			"=b" (*bx),
+			"=c" (*cx),
+			"=d" (*dx)
+			: "0" (*ax), "2" (*cx));
 
 	*bx &= maskebx;
 	*cx &= maskecx;
@@ -1055,6 +1063,10 @@ void xen_setup_shared_info(void)
 		HYPERVISOR_shared_info =
 			(struct shared_info *)__va(xen_start_info->shared_info);
 
+	/* PVH TBD/FIXME: vcpu info placement in phase 2 */
+	if (xen_pvh_domain())
+		return;
+
 #ifndef CONFIG_SMP
 	/* In UP this is as good a place as any to set up shared info */
 	xen_setup_vcpu_info_placement();
@@ -1292,6 +1304,11 @@ static const struct machine_ops xen_machine_ops __initconst = {
  */
 static void __init xen_setup_stackprotector(void)
 {
+	/* PVH TBD/FIXME: investigate setup_stack_canary_segment */
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		switch_to_new_gdt(0);
+		return;
+	}
 	pv_cpu_ops.write_gdt_entry = xen_write_gdt_entry_boot;
 	pv_cpu_ops.load_gdt = xen_load_gdt_boot;
 
@@ -1302,6 +1319,19 @@ static void __init xen_setup_stackprotector(void)
 	pv_cpu_ops.load_gdt = xen_load_gdt;
 }
 
+static void __init xen_pvh_early_guest_init(void)
+{
+	if (xen_feature(XENFEAT_hvm_callback_vector))
+		xen_have_vector_callback = 1;
+
+#ifdef CONFIG_X86_32
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		xen_raw_printk("ERROR: 32bit PVH guests are not supported\n");
+		BUG();
+	}
+#endif
+}
+
 /* First C function to be called on Xen boot */
 asmlinkage void __init xen_start_kernel(void)
 {
@@ -1313,13 +1343,18 @@ asmlinkage void __init xen_start_kernel(void)
 
 	xen_domain_type = XEN_PV_DOMAIN;
 
+	xen_setup_features();
+	xen_pvh_early_guest_init();
 	xen_setup_machphys_mapping();
 
 	/* Install Xen paravirt ops */
 	pv_info = xen_info;
 	pv_init_ops = xen_init_ops;
-	pv_cpu_ops = xen_cpu_ops;
 	pv_apic_ops = xen_apic_ops;
+	if (xen_pvh_domain())
+		pv_cpu_ops.cpuid = xen_cpuid;
+	else
+		pv_cpu_ops = xen_cpu_ops;
 
 	x86_init.resources.memory_setup = xen_memory_setup;
 	x86_init.oem.arch_setup = xen_arch_setup;
@@ -1351,8 +1386,6 @@ asmlinkage void __init xen_start_kernel(void)
 	/* Work out if we support NX */
 	x86_configure_nx();
 
-	xen_setup_features();
-
 	/* Get mfn list */
 	if (!xen_feature(XENFEAT_auto_translated_physmap))
 		xen_build_dynamic_phys_to_machine();
@@ -1423,14 +1456,18 @@ asmlinkage void __init xen_start_kernel(void)
 	/* set the limit of our address space */
 	xen_reserve_top();
 
-	/* We used to do this in xen_arch_setup, but that is too late on AMD
-	 * were early_cpu_init (run before ->arch_setup()) calls early_amd_init
-	 * which pokes 0xcf8 port.
-	 */
-	set_iopl.iopl = 1;
-	rc = HYPERVISOR_physdev_op(PHYSDEVOP_set_iopl, &set_iopl);
-	if (rc != 0)
-		xen_raw_printk("physdev_op failed %d\n", rc);
+	/* PVH: runs at default kernel iopl of 0 */
+	if (!xen_pvh_domain()) {
+		/*
+		 * We used to do this in xen_arch_setup, but that is too late
+		 * on AMD were early_cpu_init (run before ->arch_setup()) calls
+		 * early_amd_init which pokes 0xcf8 port.
+		 */
+		set_iopl.iopl = 1;
+		rc = HYPERVISOR_physdev_op(PHYSDEVOP_set_iopl, &set_iopl);
+		if (rc != 0)
+			xen_raw_printk("physdev_op failed %d\n", rc);
+	}
 
 #ifdef CONFIG_X86_32
 	/* set up basic CPUID stuff */
@@ -1497,6 +1534,8 @@ asmlinkage void __init xen_start_kernel(void)
 #endif
 }
 
+/* Use a pfn in RAM, may move to MMIO before kexec.
+ * This function also called for PVH dom0 */
 void __ref xen_hvm_init_shared_info(void)
 {
 	int cpu;
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 8971a26..8cce47b 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include "mmu.h"
 #include "xen-ops.h"
 #include "vdso.h"
 
@@ -78,6 +79,9 @@ static void __init xen_add_extra_mem(u64 start, u64 size)
 
 	memblock_reserve(start, size);
 
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return;
+
 	xen_max_p2m_pfn = PFN_DOWN(start + size);
 	for (pfn = PFN_DOWN(start); pfn < xen_max_p2m_pfn; pfn++) {
 		unsigned long mfn = pfn_to_mfn(pfn);
@@ -100,6 +104,7 @@ static unsigned long __init xen_do_chunk(unsigned long start,
 		.domid        = DOMID_SELF
 	};
 	unsigned long len = 0;
+	int xlated_phys = xen_feature(XENFEAT_auto_translated_physmap);
 	unsigned long pfn;
 	int ret;
 
@@ -113,7 +118,7 @@ static unsigned long __init xen_do_chunk(unsigned long start,
 				continue;
 			frame = mfn;
 		} else {
-			if (mfn != INVALID_P2M_ENTRY)
+			if (!xlated_phys && mfn != INVALID_P2M_ENTRY)
 				continue;
 			frame = pfn;
 		}
@@ -230,6 +235,27 @@ static void __init xen_set_identity_and_release_chunk(
 	*identity += set_phys_range_identity(start_pfn, end_pfn);
 }
 
+/* For PVH, the pfns [0..MAX] are mapped to mfn's in the EPT/NPT. The mfns
+ * are released as part of this 1:1 mapping hypercall back to the dom heap.
+ * Also, we map the entire IO space, ie, beyond max_pfn_mapped.
+ */
+static void __init xen_pvh_identity_map_chunk(unsigned long start_pfn,
+		unsigned long end_pfn, unsigned long *released,
+		unsigned long *identity, unsigned long max_pfn)
+{
+	unsigned long pfn;
+	int numpfns = 1, add_mapping = 1;
+
+	for (pfn = start_pfn; pfn < end_pfn; pfn++)
+		xen_set_clr_mmio_pvh_pte(pfn, pfn, numpfns, add_mapping);
+
+	if (start_pfn <= max_pfn) {
+		unsigned long end = min(max_pfn_mapped, end_pfn);
+		*released += end - start_pfn;
+	}
+	*identity += end_pfn - start_pfn;
+}
+
 static unsigned long __init xen_set_identity_and_release(
 	const struct e820entry *list, size_t map_size, unsigned long nr_pages)
 {
@@ -238,6 +264,7 @@ static unsigned long __init xen_set_identity_and_release(
 	unsigned long identity = 0;
 	const struct e820entry *entry;
 	int i;
+	int xlated_phys = xen_feature(XENFEAT_auto_translated_physmap);
 
 	/*
 	 * Combine non-RAM regions and gaps until a RAM region (or the
@@ -259,11 +286,17 @@ static unsigned long __init xen_set_identity_and_release(
 			if (entry->type == E820_RAM)
 				end_pfn = PFN_UP(entry->addr);
 
-			if (start_pfn < end_pfn)
-				xen_set_identity_and_release_chunk(
-					start_pfn, end_pfn, nr_pages,
-					&released, &identity);
-
+			if (start_pfn < end_pfn) {
+				if (xlated_phys) {
+					xen_pvh_identity_map_chunk(start_pfn,
+						end_pfn, &released, &identity,
+						nr_pages);
+				} else {
+					xen_set_identity_and_release_chunk(
+						start_pfn, end_pfn, nr_pages,
+						&released, &identity);
+				}
+			}
 			start = end;
 		}
 	}
@@ -526,16 +559,14 @@ void __cpuinit xen_enable_syscall(void)
 #endif /* CONFIG_X86_64 */
 }
 
-void __init xen_arch_setup(void)
+/* Non auto translated PV domain, ie, it's not PVH. */
+static __init void xen_pvmmu_arch_setup(void)
 {
-	xen_panic_handler_init();
-
 	HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_4gb_segments);
 	HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_writable_pagetables);
 
-	if (!xen_feature(XENFEAT_auto_translated_physmap))
-		HYPERVISOR_vm_assist(VMASST_CMD_enable,
-				     VMASST_TYPE_pae_extended_cr3);
+	HYPERVISOR_vm_assist(VMASST_CMD_enable,
+			     VMASST_TYPE_pae_extended_cr3);
 
 	if (register_callback(CALLBACKTYPE_event, xen_hypervisor_callback) ||
 	    register_callback(CALLBACKTYPE_failsafe, xen_failsafe_callback))
@@ -543,6 +574,15 @@ void __init xen_arch_setup(void)
 
 	xen_enable_sysenter();
 	xen_enable_syscall();
+}
+
+/* This function not called for HVM domain */
+void __init xen_arch_setup(void)
+{
+	xen_panic_handler_init();
+
+	if (!xen_feature(XENFEAT_auto_translated_physmap))
+		xen_pvmmu_arch_setup();
 
 #ifdef CONFIG_ACPI
 	if (!(xen_start_info->flags & SIF_INITDOMAIN)) {
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 20 01:30:46 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Oct 2012 01:30:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPNtQ-000633-2R; Sat, 20 Oct 2012 01:30:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPNtN-000628-Ie
	for xen-devel@lists.xensource.com; Sat, 20 Oct 2012 01:30:21 +0000
Received: from [85.158.139.211:6907] by server-5.bemta-5.messagelabs.com id
	75/D7-09732-CAEF1805; Sat, 20 Oct 2012 01:30:20 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1350696618!23046761!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODE2OTk0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2719 invoked from network); 20 Oct 2012 01:30:19 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-4.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Oct 2012 01:30:19 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9K1UAsG012027
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 20 Oct 2012 01:30:11 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9K1UAuN028411
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 20 Oct 2012 01:30:10 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9K1U9Uj011678; Fri, 19 Oct 2012 20:30:09 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Oct 2012 18:30:09 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id A269A4042D; Fri, 19 Oct 2012 21:18:05 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	mukesh.rathor@oracle.com, Ian.Campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Date: Fri, 19 Oct 2012 21:18:00 -0400
Message-Id: <1350695882-12820-5-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 4/6] xen/pvh: bootup and setup related changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Mukesh Rathor 

In enlighten.c for PVH we can trap cpuid via vmexit, so don't
need to use emulated prefix call. We also check for vector callback
early on, as it is a required feature. PVH also runs at default kernel
IOPL.

In setup.c, in xen_add_extra_mem() we can skip updating P2M as it's managed
by Xen. PVH maps the entire IO space, but only RAM pages need to be repopulated.

Finally, pure PV settings are moved to a separate function that is only called
for pure PV, ie, pv with pvmmu.

Signed-off-by: Mukesh Rathor 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/xen/enlighten.c |   77 ++++++++++++++++++++++++++++++++++-----------
 arch/x86/xen/setup.c     |   64 +++++++++++++++++++++++++++++++-------
 2 files changed, 110 insertions(+), 31 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index e3497f2..53db37f 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -45,6 +45,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -107,6 +108,9 @@ RESERVE_BRK(shared_info_page_brk, PAGE_SIZE);
 __read_mostly int xen_have_vector_callback;
 EXPORT_SYMBOL_GPL(xen_have_vector_callback);
 
+#define xen_pvh_domain() (xen_pv_domain() && \
+			  xen_feature(XENFEAT_auto_translated_physmap) && \
+			  xen_have_vector_callback)
 /*
  * Point at some empty memory to start with. We map the real shared_info
  * page as soon as fixmap is up and running.
@@ -219,8 +223,9 @@ static void __init xen_banner(void)
 	struct xen_extraversion extra;
 	HYPERVISOR_xen_version(XENVER_extraversion, &extra);
 
-	printk(KERN_INFO "Booting paravirtualized kernel on %s\n",
-	       pv_info.name);
+	pr_info("Booting paravirtualized kernel %son %s\n",
+		xen_feature(XENFEAT_auto_translated_physmap) ?
+			"with PVH extensions " : "", pv_info.name);
 	printk(KERN_INFO "Xen version: %d.%d%s%s\n",
 	       version >> 16, version & 0xffff, extra.extraversion,
 	       xen_feature(XENFEAT_mmu_pt_update_preserve_ad) ? " (preserve-AD)" : "");
@@ -273,12 +278,15 @@ static void xen_cpuid(unsigned int *ax, unsigned int *bx,
 		break;
 	}
 
-	asm(XEN_EMULATE_PREFIX "cpuid"
-		: "=a" (*ax),
-		  "=b" (*bx),
-		  "=c" (*cx),
-		  "=d" (*dx)
-		: "0" (*ax), "2" (*cx));
+	if (xen_pvh_domain())
+		native_cpuid(ax, bx, cx, dx);
+	else
+		asm(XEN_EMULATE_PREFIX "cpuid"
+			: "=a" (*ax),
+			"=b" (*bx),
+			"=c" (*cx),
+			"=d" (*dx)
+			: "0" (*ax), "2" (*cx));
 
 	*bx &= maskebx;
 	*cx &= maskecx;
@@ -1055,6 +1063,10 @@ void xen_setup_shared_info(void)
 		HYPERVISOR_shared_info =
 			(struct shared_info *)__va(xen_start_info->shared_info);
 
+	/* PVH TBD/FIXME: vcpu info placement in phase 2 */
+	if (xen_pvh_domain())
+		return;
+
 #ifndef CONFIG_SMP
 	/* In UP this is as good a place as any to set up shared info */
 	xen_setup_vcpu_info_placement();
@@ -1292,6 +1304,11 @@ static const struct machine_ops xen_machine_ops __initconst = {
  */
 static void __init xen_setup_stackprotector(void)
 {
+	/* PVH TBD/FIXME: investigate setup_stack_canary_segment */
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		switch_to_new_gdt(0);
+		return;
+	}
 	pv_cpu_ops.write_gdt_entry = xen_write_gdt_entry_boot;
 	pv_cpu_ops.load_gdt = xen_load_gdt_boot;
 
@@ -1302,6 +1319,19 @@ static void __init xen_setup_stackprotector(void)
 	pv_cpu_ops.load_gdt = xen_load_gdt;
 }
 
+static void __init xen_pvh_early_guest_init(void)
+{
+	if (xen_feature(XENFEAT_hvm_callback_vector))
+		xen_have_vector_callback = 1;
+
+#ifdef CONFIG_X86_32
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		xen_raw_printk("ERROR: 32bit PVH guests are not supported\n");
+		BUG();
+	}
+#endif
+}
+
 /* First C function to be called on Xen boot */
 asmlinkage void __init xen_start_kernel(void)
 {
@@ -1313,13 +1343,18 @@ asmlinkage void __init xen_start_kernel(void)
 
 	xen_domain_type = XEN_PV_DOMAIN;
 
+	xen_setup_features();
+	xen_pvh_early_guest_init();
 	xen_setup_machphys_mapping();
 
 	/* Install Xen paravirt ops */
 	pv_info = xen_info;
 	pv_init_ops = xen_init_ops;
-	pv_cpu_ops = xen_cpu_ops;
 	pv_apic_ops = xen_apic_ops;
+	if (xen_pvh_domain())
+		pv_cpu_ops.cpuid = xen_cpuid;
+	else
+		pv_cpu_ops = xen_cpu_ops;
 
 	x86_init.resources.memory_setup = xen_memory_setup;
 	x86_init.oem.arch_setup = xen_arch_setup;
@@ -1351,8 +1386,6 @@ asmlinkage void __init xen_start_kernel(void)
 	/* Work out if we support NX */
 	x86_configure_nx();
 
-	xen_setup_features();
-
 	/* Get mfn list */
 	if (!xen_feature(XENFEAT_auto_translated_physmap))
 		xen_build_dynamic_phys_to_machine();
@@ -1423,14 +1456,18 @@ asmlinkage void __init xen_start_kernel(void)
 	/* set the limit of our address space */
 	xen_reserve_top();
 
-	/* We used to do this in xen_arch_setup, but that is too late on AMD
-	 * were early_cpu_init (run before ->arch_setup()) calls early_amd_init
-	 * which pokes 0xcf8 port.
-	 */
-	set_iopl.iopl = 1;
-	rc = HYPERVISOR_physdev_op(PHYSDEVOP_set_iopl, &set_iopl);
-	if (rc != 0)
-		xen_raw_printk("physdev_op failed %d\n", rc);
+	/* PVH: runs at default kernel iopl of 0 */
+	if (!xen_pvh_domain()) {
+		/*
+		 * We used to do this in xen_arch_setup, but that is too late
+		 * on AMD were early_cpu_init (run before ->arch_setup()) calls
+		 * early_amd_init which pokes 0xcf8 port.
+		 */
+		set_iopl.iopl = 1;
+		rc = HYPERVISOR_physdev_op(PHYSDEVOP_set_iopl, &set_iopl);
+		if (rc != 0)
+			xen_raw_printk("physdev_op failed %d\n", rc);
+	}
 
 #ifdef CONFIG_X86_32
 	/* set up basic CPUID stuff */
@@ -1497,6 +1534,8 @@ asmlinkage void __init xen_start_kernel(void)
 #endif
 }
 
+/* Use a pfn in RAM, may move to MMIO before kexec.
+ * This function also called for PVH dom0 */
 void __ref xen_hvm_init_shared_info(void)
 {
 	int cpu;
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 8971a26..8cce47b 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include "mmu.h"
 #include "xen-ops.h"
 #include "vdso.h"
 
@@ -78,6 +79,9 @@ static void __init xen_add_extra_mem(u64 start, u64 size)
 
 	memblock_reserve(start, size);
 
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return;
+
 	xen_max_p2m_pfn = PFN_DOWN(start + size);
 	for (pfn = PFN_DOWN(start); pfn < xen_max_p2m_pfn; pfn++) {
 		unsigned long mfn = pfn_to_mfn(pfn);
@@ -100,6 +104,7 @@ static unsigned long __init xen_do_chunk(unsigned long start,
 		.domid        = DOMID_SELF
 	};
 	unsigned long len = 0;
+	int xlated_phys = xen_feature(XENFEAT_auto_translated_physmap);
 	unsigned long pfn;
 	int ret;
 
@@ -113,7 +118,7 @@ static unsigned long __init xen_do_chunk(unsigned long start,
 				continue;
 			frame = mfn;
 		} else {
-			if (mfn != INVALID_P2M_ENTRY)
+			if (!xlated_phys && mfn != INVALID_P2M_ENTRY)
 				continue;
 			frame = pfn;
 		}
@@ -230,6 +235,27 @@ static void __init xen_set_identity_and_release_chunk(
 	*identity += set_phys_range_identity(start_pfn, end_pfn);
 }
 
+/* For PVH, the pfns [0..MAX] are mapped to mfn's in the EPT/NPT. The mfns
+ * are released as part of this 1:1 mapping hypercall back to the dom heap.
+ * Also, we map the entire IO space, ie, beyond max_pfn_mapped.
+ */
+static void __init xen_pvh_identity_map_chunk(unsigned long start_pfn,
+		unsigned long end_pfn, unsigned long *released,
+		unsigned long *identity, unsigned long max_pfn)
+{
+	unsigned long pfn;
+	int numpfns = 1, add_mapping = 1;
+
+	for (pfn = start_pfn; pfn < end_pfn; pfn++)
+		xen_set_clr_mmio_pvh_pte(pfn, pfn, numpfns, add_mapping);
+
+	if (start_pfn <= max_pfn) {
+		unsigned long end = min(max_pfn_mapped, end_pfn);
+		*released += end - start_pfn;
+	}
+	*identity += end_pfn - start_pfn;
+}
+
 static unsigned long __init xen_set_identity_and_release(
 	const struct e820entry *list, size_t map_size, unsigned long nr_pages)
 {
@@ -238,6 +264,7 @@ static unsigned long __init xen_set_identity_and_release(
 	unsigned long identity = 0;
 	const struct e820entry *entry;
 	int i;
+	int xlated_phys = xen_feature(XENFEAT_auto_translated_physmap);
 
 	/*
 	 * Combine non-RAM regions and gaps until a RAM region (or the
@@ -259,11 +286,17 @@ static unsigned long __init xen_set_identity_and_release(
 			if (entry->type == E820_RAM)
 				end_pfn = PFN_UP(entry->addr);
 
-			if (start_pfn < end_pfn)
-				xen_set_identity_and_release_chunk(
-					start_pfn, end_pfn, nr_pages,
-					&released, &identity);
-
+			if (start_pfn < end_pfn) {
+				if (xlated_phys) {
+					xen_pvh_identity_map_chunk(start_pfn,
+						end_pfn, &released, &identity,
+						nr_pages);
+				} else {
+					xen_set_identity_and_release_chunk(
+						start_pfn, end_pfn, nr_pages,
+						&released, &identity);
+				}
+			}
 			start = end;
 		}
 	}
@@ -526,16 +559,14 @@ void __cpuinit xen_enable_syscall(void)
 #endif /* CONFIG_X86_64 */
 }
 
-void __init xen_arch_setup(void)
+/* Non auto translated PV domain, ie, it's not PVH. */
+static __init void xen_pvmmu_arch_setup(void)
 {
-	xen_panic_handler_init();
-
 	HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_4gb_segments);
 	HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_writable_pagetables);
 
-	if (!xen_feature(XENFEAT_auto_translated_physmap))
-		HYPERVISOR_vm_assist(VMASST_CMD_enable,
-				     VMASST_TYPE_pae_extended_cr3);
+	HYPERVISOR_vm_assist(VMASST_CMD_enable,
+			     VMASST_TYPE_pae_extended_cr3);
 
 	if (register_callback(CALLBACKTYPE_event, xen_hypervisor_callback) ||
 	    register_callback(CALLBACKTYPE_failsafe, xen_failsafe_callback))
@@ -543,6 +574,15 @@ void __init xen_arch_setup(void)
 
 	xen_enable_sysenter();
 	xen_enable_syscall();
+}
+
+/* This function not called for HVM domain */
+void __init xen_arch_setup(void)
+{
+	xen_panic_handler_init();
+
+	if (!xen_feature(XENFEAT_auto_translated_physmap))
+		xen_pvmmu_arch_setup();
 
 #ifdef CONFIG_ACPI
 	if (!(xen_start_info->flags & SIF_INITDOMAIN)) {
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 20 01:30:46 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Oct 2012 01:30:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPNtP-00062Z-3k; Sat, 20 Oct 2012 01:30:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPNtM-00061m-CK
	for xen-devel@lists.xensource.com; Sat, 20 Oct 2012 01:30:20 +0000
Received: from [85.158.143.99:33770] by server-2.bemta-4.messagelabs.com id
	F8/D7-22268-BAEF1805; Sat, 20 Oct 2012 01:30:19 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1350696617!34501992!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODE2OTk0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16340 invoked from network); 20 Oct 2012 01:30:18 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Oct 2012 01:30:18 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9K1UB6p012028
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 20 Oct 2012 01:30:11 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9K1UAhm006991
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 20 Oct 2012 01:30:10 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9K1U9pJ011677; Fri, 19 Oct 2012 20:30:09 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Oct 2012 18:30:09 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 880FA402D4; Fri, 19 Oct 2012 21:18:05 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	mukesh.rathor@oracle.com, Ian.Campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Date: Fri, 19 Oct 2012 21:17:57 -0400
Message-Id: <1350695882-12820-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 1/6] xen/pvh: Support ParaVirtualized Hardware
	extensions.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Mukesh Rathor 

PVH allows PV linux guest to utilize hardware extended capabilities, such
as running MMU updates in a HVM container.

This patch allows it to be configured and enabled. Also, basic header file
changes to add new subcalls to physmap hypercall.

Lastly, mfn_to_local_pfn must return mfn for paging mode translate
(since we let the hypervisor - or CPU - do them for us).

Signed-off-by: Mukesh Rathor 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/include/asm/xen/page.h |    3 +++
 arch/x86/xen/Kconfig            |   10 ++++++++++
 arch/x86/xen/xen-head.S         |   11 ++++++++++-
 include/xen/interface/memory.h  |   24 +++++++++++++++++++++++-
 include/xen/interface/physdev.h |   10 ++++++++++
 5 files changed, 56 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index 472b9b7..6af440d 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -159,6 +159,9 @@ static inline xpaddr_t machine_to_phys(xmaddr_t machine)
 static inline unsigned long mfn_to_local_pfn(unsigned long mfn)
 {
 	unsigned long pfn = mfn_to_pfn(mfn);
+
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return mfn;
 	if (get_phys_to_machine(pfn) != mfn)
 		return -1; /* force !pfn_valid() */
 	return pfn;
diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index fdce49c..822c5a0 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -50,3 +50,13 @@ config XEN_DEBUG_FS
 	  Enable statistics output and various tuning options in debugfs.
 	  Enabling this option may incur a significant performance overhead.
 
+config XEN_X86_PVH
+	bool "Support for running as a PVH guest (EXPERIMENTAL)"
+	depends on X86_64 && XEN && EXPERIMENTAL
+	default n
+	help
+	   This option enables support for running as a PVH guest (PV guest
+	   using hardware extensions) under a suitably capable hypervisor.
+	   This option is EXPERIMENTAL because the hypervisor interfaces
+	   which it uses are not yet considered stable therefore backwards and
+	   forwards compatibility is not yet guaranteed.  If unsure, say N.
diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
index 7faed58..1a6bca1 100644
--- a/arch/x86/xen/xen-head.S
+++ b/arch/x86/xen/xen-head.S
@@ -13,6 +13,15 @@
 #include 
 #include 
 
+#ifdef CONFIG_XEN_X86_PVH
+#define FEATURES_PVH "|writable_descriptor_tables" \
+		     "|auto_translated_physmap" \
+		     "|supervisor_mode_kernel" \
+		     "|hvm_callback_vector"
+#else
+#define FEATURES_PVH /* Not supported */
+#endif
+
 	__INIT
 ENTRY(startup_xen)
 	cld
@@ -95,7 +104,7 @@ NEXT_HYPERCALL(arch_6)
 #endif
 	ELFNOTE(Xen, XEN_ELFNOTE_ENTRY,          _ASM_PTR startup_xen)
 	ELFNOTE(Xen, XEN_ELFNOTE_HYPERCALL_PAGE, _ASM_PTR hypercall_page)
-	ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,       .asciz "!writable_page_tables|pae_pgdir_above_4gb")
+	ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,       .asciz "!writable_page_tables|pae_pgdir_above_4gb"FEATURES_PVH)
 	ELFNOTE(Xen, XEN_ELFNOTE_PAE_MODE,       .asciz "yes")
 	ELFNOTE(Xen, XEN_ELFNOTE_LOADER,         .asciz "generic")
 	ELFNOTE(Xen, XEN_ELFNOTE_L1_MFN_VALID,
diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index b66d04c..8beebdb 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -169,7 +169,13 @@ struct xen_add_to_physmap {
     /* Source mapping space. */
 #define XENMAPSPACE_shared_info 0 /* shared info page */
 #define XENMAPSPACE_grant_table 1 /* grant table page */
-    unsigned int space;
+#define XENMAPSPACE_gmfn        2 /* GMFN */
+#define XENMAPSPACE_gmfn_range  3 /* GMFN range */
+#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */
+    uint16_t space;
+    domid_t foreign_domid;         /* IFF XENMAPSPACE_gmfn_foreign */
+
+#define XENMAPIDX_grant_table_status 0x80000000
 
     /* Index into source mapping space. */
     xen_ulong_t idx;
@@ -237,4 +243,20 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_memory_map);
  * during a driver critical region.
  */
 extern spinlock_t xen_reservation_lock;
+
+/*
+ * Unmaps the page appearing at a particular GPFN from the specified guest's
+ * pseudophysical address space.
+ * arg == addr of xen_remove_from_physmap_t.
+ */
+#define XENMEM_remove_from_physmap      15
+struct xen_remove_from_physmap {
+    /* Which domain to change the mapping for. */
+    domid_t domid;
+
+    /* GPFN of the current mapping of the page. */
+    xen_pfn_t gpfn;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_remove_from_physmap);
+
 #endif /* __XEN_PUBLIC_MEMORY_H__ */
diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
index 1844d31..83050d3 100644
--- a/include/xen/interface/physdev.h
+++ b/include/xen/interface/physdev.h
@@ -274,6 +274,16 @@ struct physdev_dbgp_op {
     } u;
 };
 
+#define PHYSDEVOP_map_iomem        30
+struct physdev_map_iomem {
+    /* IN */
+    uint64_t first_gfn;
+    uint64_t first_mfn;
+    uint32_t nr_mfns;
+    uint32_t add_mapping; /* 1 == add mapping;  0 == unmap */
+
+};
+
 /*
  * Notify that some PIRQ-bound event channels have been unmasked.
  * ** This command is obsolete since interface version 0x00030202 and is **
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 20 01:30:46 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Oct 2012 01:30:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPNtO-00062L-Am; Sat, 20 Oct 2012 01:30:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPNtM-00061l-3T
	for xen-devel@lists.xensource.com; Sat, 20 Oct 2012 01:30:20 +0000
Received: from [85.158.143.99:33765] by server-3.bemta-4.messagelabs.com id
	87/23-03544-BAEF1805; Sat, 20 Oct 2012 01:30:19 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1350696617!34809915!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgyNDExNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9195 invoked from network); 20 Oct 2012 01:30:18 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Oct 2012 01:30:18 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9K1UAvu022730
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 20 Oct 2012 01:30:11 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9K1UApu028409
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 20 Oct 2012 01:30:10 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9K1UAxm004872; Fri, 19 Oct 2012 20:30:10 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Oct 2012 18:30:09 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9063B40366; Fri, 19 Oct 2012 21:18:05 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	mukesh.rathor@oracle.com, Ian.Campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Date: Fri, 19 Oct 2012 21:17:58 -0400
Message-Id: <1350695882-12820-3-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 2/6] xen/pvh: Extend vcpu_guest_context, p2m,
	event, and xenbus to support PVH.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Mukesh Rathor 

make gdt_frames[]/gdt_ents into a union with {gdtaddr, gdtsz}, as PVH
only needs to send down gdtaddr and gdtsz.

For interrupts, PVH uses native_irq_ops.
vcpu hotplug is currently not available for PVH.

For events we follow what PVHVM does - to use callback vector.
Lastly, also use HVM path to setup XenBus.

Signed-off-by: Mukesh Rathor 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/include/asm/xen/interface.h |   11 +++++-
 arch/x86/xen/irq.c                   |    5 ++-
 arch/x86/xen/p2m.c                   |    2 +-
 arch/x86/xen/smp.c                   |   75 ++++++++++++++++++++++------------
 drivers/xen/cpu_hotplug.c            |    4 +-
 drivers/xen/events.c                 |    9 ++++-
 drivers/xen/xenbus/xenbus_client.c   |    3 +-
 7 files changed, 77 insertions(+), 32 deletions(-)

diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
index 6d2f75a..4c08f23 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -144,7 +144,16 @@ struct vcpu_guest_context {
     struct cpu_user_regs user_regs;         /* User-level CPU registers     */
     struct trap_info trap_ctxt[256];        /* Virtual IDT                  */
     unsigned long ldt_base, ldt_ents;       /* LDT (linear address, # ents) */
-    unsigned long gdt_frames[16], gdt_ents; /* GDT (machine frames, # ents) */
+    union {
+	struct {
+		/* PV: GDT (machine frames, # ents).*/
+		unsigned long gdt_frames[16], gdt_ents;
+	} pv;
+	struct {
+		/* PVH: GDTR addr and size */
+		unsigned long gdtaddr, gdtsz;
+	} pvh;
+    } u;
     unsigned long kernel_ss, kernel_sp;     /* Virtual TSS (only SS1/SP1)   */
     /* NB. User pagetable on x86/64 is placed in ctrlreg[1]. */
     unsigned long ctrlreg[8];               /* CR0-CR7 (control registers)  */
diff --git a/arch/x86/xen/irq.c b/arch/x86/xen/irq.c
index 01a4dc0..fcbe56a 100644
--- a/arch/x86/xen/irq.c
+++ b/arch/x86/xen/irq.c
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -129,6 +130,8 @@ static const struct pv_irq_ops xen_irq_ops __initconst = {
 
 void __init xen_init_irq_ops(void)
 {
-	pv_irq_ops = xen_irq_ops;
+	/* For PVH we use default pv_irq_ops settings */
+	if (!xen_feature(XENFEAT_hvm_callback_vector))
+		pv_irq_ops = xen_irq_ops;
 	x86_init.irqs.intr_init = xen_init_IRQ;
 }
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 95fb2aa..ea553c8 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -798,7 +798,7 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 {
 	unsigned topidx, mididx, idx;
 
-	if (unlikely(xen_feature(XENFEAT_auto_translated_physmap))) {
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
 		BUG_ON(pfn != mfn && mfn != INVALID_P2M_ENTRY);
 		return true;
 	}
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 353c50f..df400349 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -68,9 +68,11 @@ static void __cpuinit cpu_bringup(void)
 	touch_softlockup_watchdog();
 	preempt_disable();
 
-	xen_enable_sysenter();
-	xen_enable_syscall();
-
+	/* PVH runs in ring 0 and allows us to do native syscalls. Yay! */
+	if (!xen_feature(XENFEAT_supervisor_mode_kernel)) {
+		xen_enable_sysenter();
+		xen_enable_syscall();
+	}
 	cpu = smp_processor_id();
 	smp_store_cpu_info(cpu);
 	cpu_data(cpu).x86_max_cores = 1;
@@ -230,10 +232,11 @@ static void __init xen_smp_prepare_boot_cpu(void)
 	BUG_ON(smp_processor_id() != 0);
 	native_smp_prepare_boot_cpu();
 
-	/* We've switched to the "real" per-cpu gdt, so make sure the
-	   old memory can be recycled */
-	make_lowmem_page_readwrite(xen_initial_gdt);
-
+	if (!xen_feature(XENFEAT_writable_page_tables)) {
+		/* We've switched to the "real" per-cpu gdt, so make sure the
+		 * old memory can be recycled */
+		make_lowmem_page_readwrite(xen_initial_gdt);
+	}
 	xen_filter_cpu_maps();
 	xen_setup_vcpu_info_placement();
 }
@@ -300,8 +303,6 @@ cpu_initialize_context(unsigned int cpu, struct task_struct *idle)
 	gdt = get_cpu_gdt_table(cpu);
 
 	ctxt->flags = VGCF_IN_KERNEL;
-	ctxt->user_regs.ds = __USER_DS;
-	ctxt->user_regs.es = __USER_DS;
 	ctxt->user_regs.ss = __KERNEL_DS;
 #ifdef CONFIG_X86_32
 	ctxt->user_regs.fs = __KERNEL_PERCPU;
@@ -310,35 +311,57 @@ cpu_initialize_context(unsigned int cpu, struct task_struct *idle)
 	ctxt->gs_base_kernel = per_cpu_offset(cpu);
 #endif
 	ctxt->user_regs.eip = (unsigned long)cpu_bringup_and_idle;
-	ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
 
 	memset(&ctxt->fpu_ctxt, 0, sizeof(ctxt->fpu_ctxt));
 
-	xen_copy_trap_info(ctxt->trap_ctxt);
+	/* check for autoxlated to get it right for 32bit kernel */
+	if (xen_feature(XENFEAT_auto_translated_physmap) &&
+	    xen_feature(XENFEAT_supervisor_mode_kernel)) {
 
-	ctxt->ldt_ents = 0;
+		ctxt->user_regs.ds = __KERNEL_DS;
+		ctxt->user_regs.es = 0;
+		ctxt->user_regs.gs = 0;
 
-	BUG_ON((unsigned long)gdt & ~PAGE_MASK);
+		ctxt->u.pvh.gdtaddr = (unsigned long)gdt;
+		ctxt->u.pvh.gdtsz = (unsigned long)(GDT_SIZE - 1);
 
-	gdt_mfn = arbitrary_virt_to_mfn(gdt);
-	make_lowmem_page_readonly(gdt);
-	make_lowmem_page_readonly(mfn_to_virt(gdt_mfn));
+#ifdef CONFIG_X86_64
+		/* Note: PVH is not supported on x86_32. */
+		ctxt->gs_base_user = (unsigned long)
+					per_cpu(irq_stack_union.gs_base, cpu);
+#endif
+	} else {
+		ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
+		ctxt->user_regs.ds = __USER_DS;
+		ctxt->user_regs.es = __USER_DS;
 
-	ctxt->gdt_frames[0] = gdt_mfn;
-	ctxt->gdt_ents      = GDT_ENTRIES;
+		xen_copy_trap_info(ctxt->trap_ctxt);
 
-	ctxt->user_regs.cs = __KERNEL_CS;
-	ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct pt_regs);
+		ctxt->ldt_ents = 0;
 
-	ctxt->kernel_ss = __KERNEL_DS;
-	ctxt->kernel_sp = idle->thread.sp0;
+		BUG_ON((unsigned long)gdt & ~PAGE_MASK);
+
+		gdt_mfn = arbitrary_virt_to_mfn(gdt);
+		make_lowmem_page_readonly(gdt);
+		make_lowmem_page_readonly(mfn_to_virt(gdt_mfn));
+
+		ctxt->u.pv.gdt_frames[0] = gdt_mfn;
+		ctxt->u.pv.gdt_ents      = GDT_ENTRIES;
+
+		ctxt->kernel_ss = __KERNEL_DS;
+		ctxt->kernel_sp = idle->thread.sp0;
 
 #ifdef CONFIG_X86_32
-	ctxt->event_callback_cs     = __KERNEL_CS;
-	ctxt->failsafe_callback_cs  = __KERNEL_CS;
+		ctxt->event_callback_cs     = __KERNEL_CS;
+		ctxt->failsafe_callback_cs  = __KERNEL_CS;
 #endif
-	ctxt->event_callback_eip    = (unsigned long)xen_hypervisor_callback;
-	ctxt->failsafe_callback_eip = (unsigned long)xen_failsafe_callback;
+		ctxt->event_callback_eip    =
+					(unsigned long)xen_hypervisor_callback;
+		ctxt->failsafe_callback_eip =
+					(unsigned long)xen_failsafe_callback;
+	}
+	ctxt->user_regs.cs = __KERNEL_CS;
+	ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct pt_regs);
 
 	per_cpu(xen_cr3, cpu) = __pa(swapper_pg_dir);
 	ctxt->ctrlreg[3] = xen_pfn_to_cr3(virt_to_mfn(swapper_pg_dir));
diff --git a/drivers/xen/cpu_hotplug.c b/drivers/xen/cpu_hotplug.c
index 4dcfced..de6bcf9 100644
--- a/drivers/xen/cpu_hotplug.c
+++ b/drivers/xen/cpu_hotplug.c
@@ -2,6 +2,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -100,7 +101,8 @@ static int __init setup_vcpu_hotplug_event(void)
 	static struct notifier_block xsn_cpu = {
 		.notifier_call = setup_cpu_watcher };
 
-	if (!xen_pv_domain())
+	/* PVH TBD/FIXME: future work */
+	if (!xen_pv_domain() || xen_feature(XENFEAT_auto_translated_physmap))
 		return -ENODEV;
 
 	register_xenstore_notifier(&xsn_cpu);
diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 59e10a1..7131fdd 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -1774,7 +1774,7 @@ int xen_set_callback_via(uint64_t via)
 }
 EXPORT_SYMBOL_GPL(xen_set_callback_via);
 
-#ifdef CONFIG_XEN_PVHVM
+#ifdef CONFIG_X86
 /* Vector callbacks are better than PCI interrupts to receive event
  * channel notifications because we can receive vector callbacks on any
  * vcpu and we don't need PCI support or APIC interactions. */
@@ -1835,6 +1835,13 @@ void __init xen_init_IRQ(void)
 		if (xen_initial_domain())
 			pci_xen_initial_domain();
 
+		if (xen_feature(XENFEAT_hvm_callback_vector)) {
+			xen_callback_vector();
+			return;
+		}
+
+		/* PVH: TBD/FIXME: debug and fix eio map to work with pvh */
+
 		pirq_eoi_map = (void *)__get_free_page(GFP_KERNEL|__GFP_ZERO);
 		eoi_gmfn.gmfn = virt_to_mfn(pirq_eoi_map);
 		rc = HYPERVISOR_physdev_op(PHYSDEVOP_pirq_eoi_gmfn_v2, &eoi_gmfn);
diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
index bcf3ba4..356461e 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -44,6 +44,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "xenbus_probe.h"
 
@@ -741,7 +742,7 @@ static const struct xenbus_ring_ops ring_ops_hvm = {
 
 void __init xenbus_ring_ops_init(void)
 {
-	if (xen_pv_domain())
+	if (xen_pv_domain() && !xen_feature(XENFEAT_auto_translated_physmap))
 		ring_ops = &ring_ops_pv;
 	else
 		ring_ops = &ring_ops_hvm;
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 20 01:30:46 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Oct 2012 01:30:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPNtP-00062Z-3k; Sat, 20 Oct 2012 01:30:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPNtM-00061m-CK
	for xen-devel@lists.xensource.com; Sat, 20 Oct 2012 01:30:20 +0000
Received: from [85.158.143.99:33770] by server-2.bemta-4.messagelabs.com id
	F8/D7-22268-BAEF1805; Sat, 20 Oct 2012 01:30:19 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1350696617!34501992!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODE2OTk0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16340 invoked from network); 20 Oct 2012 01:30:18 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Oct 2012 01:30:18 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9K1UB6p012028
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 20 Oct 2012 01:30:11 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9K1UAhm006991
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 20 Oct 2012 01:30:10 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9K1U9pJ011677; Fri, 19 Oct 2012 20:30:09 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Oct 2012 18:30:09 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 880FA402D4; Fri, 19 Oct 2012 21:18:05 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	mukesh.rathor@oracle.com, Ian.Campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Date: Fri, 19 Oct 2012 21:17:57 -0400
Message-Id: <1350695882-12820-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 1/6] xen/pvh: Support ParaVirtualized Hardware
	extensions.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Mukesh Rathor 

PVH allows PV linux guest to utilize hardware extended capabilities, such
as running MMU updates in a HVM container.

This patch allows it to be configured and enabled. Also, basic header file
changes to add new subcalls to physmap hypercall.

Lastly, mfn_to_local_pfn must return mfn for paging mode translate
(since we let the hypervisor - or CPU - do them for us).

Signed-off-by: Mukesh Rathor 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/include/asm/xen/page.h |    3 +++
 arch/x86/xen/Kconfig            |   10 ++++++++++
 arch/x86/xen/xen-head.S         |   11 ++++++++++-
 include/xen/interface/memory.h  |   24 +++++++++++++++++++++++-
 include/xen/interface/physdev.h |   10 ++++++++++
 5 files changed, 56 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index 472b9b7..6af440d 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -159,6 +159,9 @@ static inline xpaddr_t machine_to_phys(xmaddr_t machine)
 static inline unsigned long mfn_to_local_pfn(unsigned long mfn)
 {
 	unsigned long pfn = mfn_to_pfn(mfn);
+
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return mfn;
 	if (get_phys_to_machine(pfn) != mfn)
 		return -1; /* force !pfn_valid() */
 	return pfn;
diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index fdce49c..822c5a0 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -50,3 +50,13 @@ config XEN_DEBUG_FS
 	  Enable statistics output and various tuning options in debugfs.
 	  Enabling this option may incur a significant performance overhead.
 
+config XEN_X86_PVH
+	bool "Support for running as a PVH guest (EXPERIMENTAL)"
+	depends on X86_64 && XEN && EXPERIMENTAL
+	default n
+	help
+	   This option enables support for running as a PVH guest (PV guest
+	   using hardware extensions) under a suitably capable hypervisor.
+	   This option is EXPERIMENTAL because the hypervisor interfaces
+	   which it uses are not yet considered stable therefore backwards and
+	   forwards compatibility is not yet guaranteed.  If unsure, say N.
diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
index 7faed58..1a6bca1 100644
--- a/arch/x86/xen/xen-head.S
+++ b/arch/x86/xen/xen-head.S
@@ -13,6 +13,15 @@
 #include 
 #include 
 
+#ifdef CONFIG_XEN_X86_PVH
+#define FEATURES_PVH "|writable_descriptor_tables" \
+		     "|auto_translated_physmap" \
+		     "|supervisor_mode_kernel" \
+		     "|hvm_callback_vector"
+#else
+#define FEATURES_PVH /* Not supported */
+#endif
+
 	__INIT
 ENTRY(startup_xen)
 	cld
@@ -95,7 +104,7 @@ NEXT_HYPERCALL(arch_6)
 #endif
 	ELFNOTE(Xen, XEN_ELFNOTE_ENTRY,          _ASM_PTR startup_xen)
 	ELFNOTE(Xen, XEN_ELFNOTE_HYPERCALL_PAGE, _ASM_PTR hypercall_page)
-	ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,       .asciz "!writable_page_tables|pae_pgdir_above_4gb")
+	ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,       .asciz "!writable_page_tables|pae_pgdir_above_4gb"FEATURES_PVH)
 	ELFNOTE(Xen, XEN_ELFNOTE_PAE_MODE,       .asciz "yes")
 	ELFNOTE(Xen, XEN_ELFNOTE_LOADER,         .asciz "generic")
 	ELFNOTE(Xen, XEN_ELFNOTE_L1_MFN_VALID,
diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index b66d04c..8beebdb 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -169,7 +169,13 @@ struct xen_add_to_physmap {
     /* Source mapping space. */
 #define XENMAPSPACE_shared_info 0 /* shared info page */
 #define XENMAPSPACE_grant_table 1 /* grant table page */
-    unsigned int space;
+#define XENMAPSPACE_gmfn        2 /* GMFN */
+#define XENMAPSPACE_gmfn_range  3 /* GMFN range */
+#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */
+    uint16_t space;
+    domid_t foreign_domid;         /* IFF XENMAPSPACE_gmfn_foreign */
+
+#define XENMAPIDX_grant_table_status 0x80000000
 
     /* Index into source mapping space. */
     xen_ulong_t idx;
@@ -237,4 +243,20 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_memory_map);
  * during a driver critical region.
  */
 extern spinlock_t xen_reservation_lock;
+
+/*
+ * Unmaps the page appearing at a particular GPFN from the specified guest's
+ * pseudophysical address space.
+ * arg == addr of xen_remove_from_physmap_t.
+ */
+#define XENMEM_remove_from_physmap      15
+struct xen_remove_from_physmap {
+    /* Which domain to change the mapping for. */
+    domid_t domid;
+
+    /* GPFN of the current mapping of the page. */
+    xen_pfn_t gpfn;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_remove_from_physmap);
+
 #endif /* __XEN_PUBLIC_MEMORY_H__ */
diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
index 1844d31..83050d3 100644
--- a/include/xen/interface/physdev.h
+++ b/include/xen/interface/physdev.h
@@ -274,6 +274,16 @@ struct physdev_dbgp_op {
     } u;
 };
 
+#define PHYSDEVOP_map_iomem        30
+struct physdev_map_iomem {
+    /* IN */
+    uint64_t first_gfn;
+    uint64_t first_mfn;
+    uint32_t nr_mfns;
+    uint32_t add_mapping; /* 1 == add mapping;  0 == unmap */
+
+};
+
 /*
  * Notify that some PIRQ-bound event channels have been unmasked.
  * ** This command is obsolete since interface version 0x00030202 and is **
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 20 01:30:46 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Oct 2012 01:30:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPNtO-00062L-Am; Sat, 20 Oct 2012 01:30:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPNtM-00061l-3T
	for xen-devel@lists.xensource.com; Sat, 20 Oct 2012 01:30:20 +0000
Received: from [85.158.143.99:33765] by server-3.bemta-4.messagelabs.com id
	87/23-03544-BAEF1805; Sat, 20 Oct 2012 01:30:19 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1350696617!34809915!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgyNDExNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9195 invoked from network); 20 Oct 2012 01:30:18 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Oct 2012 01:30:18 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9K1UAvu022730
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 20 Oct 2012 01:30:11 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9K1UApu028409
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 20 Oct 2012 01:30:10 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9K1UAxm004872; Fri, 19 Oct 2012 20:30:10 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Oct 2012 18:30:09 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9063B40366; Fri, 19 Oct 2012 21:18:05 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	mukesh.rathor@oracle.com, Ian.Campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Date: Fri, 19 Oct 2012 21:17:58 -0400
Message-Id: <1350695882-12820-3-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 2/6] xen/pvh: Extend vcpu_guest_context, p2m,
	event, and xenbus to support PVH.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Mukesh Rathor 

make gdt_frames[]/gdt_ents into a union with {gdtaddr, gdtsz}, as PVH
only needs to send down gdtaddr and gdtsz.

For interrupts, PVH uses native_irq_ops.
vcpu hotplug is currently not available for PVH.

For events we follow what PVHVM does - to use callback vector.
Lastly, also use HVM path to setup XenBus.

Signed-off-by: Mukesh Rathor 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/include/asm/xen/interface.h |   11 +++++-
 arch/x86/xen/irq.c                   |    5 ++-
 arch/x86/xen/p2m.c                   |    2 +-
 arch/x86/xen/smp.c                   |   75 ++++++++++++++++++++++------------
 drivers/xen/cpu_hotplug.c            |    4 +-
 drivers/xen/events.c                 |    9 ++++-
 drivers/xen/xenbus/xenbus_client.c   |    3 +-
 7 files changed, 77 insertions(+), 32 deletions(-)

diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
index 6d2f75a..4c08f23 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -144,7 +144,16 @@ struct vcpu_guest_context {
     struct cpu_user_regs user_regs;         /* User-level CPU registers     */
     struct trap_info trap_ctxt[256];        /* Virtual IDT                  */
     unsigned long ldt_base, ldt_ents;       /* LDT (linear address, # ents) */
-    unsigned long gdt_frames[16], gdt_ents; /* GDT (machine frames, # ents) */
+    union {
+	struct {
+		/* PV: GDT (machine frames, # ents).*/
+		unsigned long gdt_frames[16], gdt_ents;
+	} pv;
+	struct {
+		/* PVH: GDTR addr and size */
+		unsigned long gdtaddr, gdtsz;
+	} pvh;
+    } u;
     unsigned long kernel_ss, kernel_sp;     /* Virtual TSS (only SS1/SP1)   */
     /* NB. User pagetable on x86/64 is placed in ctrlreg[1]. */
     unsigned long ctrlreg[8];               /* CR0-CR7 (control registers)  */
diff --git a/arch/x86/xen/irq.c b/arch/x86/xen/irq.c
index 01a4dc0..fcbe56a 100644
--- a/arch/x86/xen/irq.c
+++ b/arch/x86/xen/irq.c
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -129,6 +130,8 @@ static const struct pv_irq_ops xen_irq_ops __initconst = {
 
 void __init xen_init_irq_ops(void)
 {
-	pv_irq_ops = xen_irq_ops;
+	/* For PVH we use default pv_irq_ops settings */
+	if (!xen_feature(XENFEAT_hvm_callback_vector))
+		pv_irq_ops = xen_irq_ops;
 	x86_init.irqs.intr_init = xen_init_IRQ;
 }
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 95fb2aa..ea553c8 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -798,7 +798,7 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 {
 	unsigned topidx, mididx, idx;
 
-	if (unlikely(xen_feature(XENFEAT_auto_translated_physmap))) {
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
 		BUG_ON(pfn != mfn && mfn != INVALID_P2M_ENTRY);
 		return true;
 	}
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 353c50f..df400349 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -68,9 +68,11 @@ static void __cpuinit cpu_bringup(void)
 	touch_softlockup_watchdog();
 	preempt_disable();
 
-	xen_enable_sysenter();
-	xen_enable_syscall();
-
+	/* PVH runs in ring 0 and allows us to do native syscalls. Yay! */
+	if (!xen_feature(XENFEAT_supervisor_mode_kernel)) {
+		xen_enable_sysenter();
+		xen_enable_syscall();
+	}
 	cpu = smp_processor_id();
 	smp_store_cpu_info(cpu);
 	cpu_data(cpu).x86_max_cores = 1;
@@ -230,10 +232,11 @@ static void __init xen_smp_prepare_boot_cpu(void)
 	BUG_ON(smp_processor_id() != 0);
 	native_smp_prepare_boot_cpu();
 
-	/* We've switched to the "real" per-cpu gdt, so make sure the
-	   old memory can be recycled */
-	make_lowmem_page_readwrite(xen_initial_gdt);
-
+	if (!xen_feature(XENFEAT_writable_page_tables)) {
+		/* We've switched to the "real" per-cpu gdt, so make sure the
+		 * old memory can be recycled */
+		make_lowmem_page_readwrite(xen_initial_gdt);
+	}
 	xen_filter_cpu_maps();
 	xen_setup_vcpu_info_placement();
 }
@@ -300,8 +303,6 @@ cpu_initialize_context(unsigned int cpu, struct task_struct *idle)
 	gdt = get_cpu_gdt_table(cpu);
 
 	ctxt->flags = VGCF_IN_KERNEL;
-	ctxt->user_regs.ds = __USER_DS;
-	ctxt->user_regs.es = __USER_DS;
 	ctxt->user_regs.ss = __KERNEL_DS;
 #ifdef CONFIG_X86_32
 	ctxt->user_regs.fs = __KERNEL_PERCPU;
@@ -310,35 +311,57 @@ cpu_initialize_context(unsigned int cpu, struct task_struct *idle)
 	ctxt->gs_base_kernel = per_cpu_offset(cpu);
 #endif
 	ctxt->user_regs.eip = (unsigned long)cpu_bringup_and_idle;
-	ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
 
 	memset(&ctxt->fpu_ctxt, 0, sizeof(ctxt->fpu_ctxt));
 
-	xen_copy_trap_info(ctxt->trap_ctxt);
+	/* check for autoxlated to get it right for 32bit kernel */
+	if (xen_feature(XENFEAT_auto_translated_physmap) &&
+	    xen_feature(XENFEAT_supervisor_mode_kernel)) {
 
-	ctxt->ldt_ents = 0;
+		ctxt->user_regs.ds = __KERNEL_DS;
+		ctxt->user_regs.es = 0;
+		ctxt->user_regs.gs = 0;
 
-	BUG_ON((unsigned long)gdt & ~PAGE_MASK);
+		ctxt->u.pvh.gdtaddr = (unsigned long)gdt;
+		ctxt->u.pvh.gdtsz = (unsigned long)(GDT_SIZE - 1);
 
-	gdt_mfn = arbitrary_virt_to_mfn(gdt);
-	make_lowmem_page_readonly(gdt);
-	make_lowmem_page_readonly(mfn_to_virt(gdt_mfn));
+#ifdef CONFIG_X86_64
+		/* Note: PVH is not supported on x86_32. */
+		ctxt->gs_base_user = (unsigned long)
+					per_cpu(irq_stack_union.gs_base, cpu);
+#endif
+	} else {
+		ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
+		ctxt->user_regs.ds = __USER_DS;
+		ctxt->user_regs.es = __USER_DS;
 
-	ctxt->gdt_frames[0] = gdt_mfn;
-	ctxt->gdt_ents      = GDT_ENTRIES;
+		xen_copy_trap_info(ctxt->trap_ctxt);
 
-	ctxt->user_regs.cs = __KERNEL_CS;
-	ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct pt_regs);
+		ctxt->ldt_ents = 0;
 
-	ctxt->kernel_ss = __KERNEL_DS;
-	ctxt->kernel_sp = idle->thread.sp0;
+		BUG_ON((unsigned long)gdt & ~PAGE_MASK);
+
+		gdt_mfn = arbitrary_virt_to_mfn(gdt);
+		make_lowmem_page_readonly(gdt);
+		make_lowmem_page_readonly(mfn_to_virt(gdt_mfn));
+
+		ctxt->u.pv.gdt_frames[0] = gdt_mfn;
+		ctxt->u.pv.gdt_ents      = GDT_ENTRIES;
+
+		ctxt->kernel_ss = __KERNEL_DS;
+		ctxt->kernel_sp = idle->thread.sp0;
 
 #ifdef CONFIG_X86_32
-	ctxt->event_callback_cs     = __KERNEL_CS;
-	ctxt->failsafe_callback_cs  = __KERNEL_CS;
+		ctxt->event_callback_cs     = __KERNEL_CS;
+		ctxt->failsafe_callback_cs  = __KERNEL_CS;
 #endif
-	ctxt->event_callback_eip    = (unsigned long)xen_hypervisor_callback;
-	ctxt->failsafe_callback_eip = (unsigned long)xen_failsafe_callback;
+		ctxt->event_callback_eip    =
+					(unsigned long)xen_hypervisor_callback;
+		ctxt->failsafe_callback_eip =
+					(unsigned long)xen_failsafe_callback;
+	}
+	ctxt->user_regs.cs = __KERNEL_CS;
+	ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct pt_regs);
 
 	per_cpu(xen_cr3, cpu) = __pa(swapper_pg_dir);
 	ctxt->ctrlreg[3] = xen_pfn_to_cr3(virt_to_mfn(swapper_pg_dir));
diff --git a/drivers/xen/cpu_hotplug.c b/drivers/xen/cpu_hotplug.c
index 4dcfced..de6bcf9 100644
--- a/drivers/xen/cpu_hotplug.c
+++ b/drivers/xen/cpu_hotplug.c
@@ -2,6 +2,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -100,7 +101,8 @@ static int __init setup_vcpu_hotplug_event(void)
 	static struct notifier_block xsn_cpu = {
 		.notifier_call = setup_cpu_watcher };
 
-	if (!xen_pv_domain())
+	/* PVH TBD/FIXME: future work */
+	if (!xen_pv_domain() || xen_feature(XENFEAT_auto_translated_physmap))
 		return -ENODEV;
 
 	register_xenstore_notifier(&xsn_cpu);
diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 59e10a1..7131fdd 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -1774,7 +1774,7 @@ int xen_set_callback_via(uint64_t via)
 }
 EXPORT_SYMBOL_GPL(xen_set_callback_via);
 
-#ifdef CONFIG_XEN_PVHVM
+#ifdef CONFIG_X86
 /* Vector callbacks are better than PCI interrupts to receive event
  * channel notifications because we can receive vector callbacks on any
  * vcpu and we don't need PCI support or APIC interactions. */
@@ -1835,6 +1835,13 @@ void __init xen_init_IRQ(void)
 		if (xen_initial_domain())
 			pci_xen_initial_domain();
 
+		if (xen_feature(XENFEAT_hvm_callback_vector)) {
+			xen_callback_vector();
+			return;
+		}
+
+		/* PVH: TBD/FIXME: debug and fix eio map to work with pvh */
+
 		pirq_eoi_map = (void *)__get_free_page(GFP_KERNEL|__GFP_ZERO);
 		eoi_gmfn.gmfn = virt_to_mfn(pirq_eoi_map);
 		rc = HYPERVISOR_physdev_op(PHYSDEVOP_pirq_eoi_gmfn_v2, &eoi_gmfn);
diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
index bcf3ba4..356461e 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -44,6 +44,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "xenbus_probe.h"
 
@@ -741,7 +742,7 @@ static const struct xenbus_ring_ops ring_ops_hvm = {
 
 void __init xenbus_ring_ops_init(void)
 {
-	if (xen_pv_domain())
+	if (xen_pv_domain() && !xen_feature(XENFEAT_auto_translated_physmap))
 		ring_ops = &ring_ops_pv;
 	else
 		ring_ops = &ring_ops_hvm;
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 20 01:30:46 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Oct 2012 01:30:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPNtO-00062S-MK; Sat, 20 Oct 2012 01:30:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPNtM-00061n-Ey
	for xen-devel@lists.xensource.com; Sat, 20 Oct 2012 01:30:20 +0000
Received: from [85.158.143.99:49973] by server-1.bemta-4.messagelabs.com id
	4F/38-19134-BAEF1805; Sat, 20 Oct 2012 01:30:19 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1350696617!23596045!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODE2OTk0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6734 invoked from network); 20 Oct 2012 01:30:18 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Oct 2012 01:30:18 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9K1UCn9012046
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 20 Oct 2012 01:30:12 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9K1UB1L007023
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 20 Oct 2012 01:30:12 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9K1UBXN004883; Fri, 19 Oct 2012 20:30:11 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Oct 2012 18:30:10 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id AA7B74042E; Fri, 19 Oct 2012 21:18:05 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	mukesh.rathor@oracle.com, Ian.Campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Date: Fri, 19 Oct 2012 21:18:01 -0400
Message-Id: <1350695882-12820-6-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 5/6] xen/pvh: balloon and grant changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Mukesh Rathor 

For balloon changes we skip setting of local P2M as it's updated
in Xen. For grant, the shared grant frame is the pfn and not mfn,
hence its mapped via the same code path as HVM.

Signed-off-by: Mukesh Rathor 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 drivers/xen/balloon.c     |   15 +++++++++------
 drivers/xen/gntdev.c      |    3 ++-
 drivers/xen/grant-table.c |   26 ++++++++++++++++++++++----
 3 files changed, 33 insertions(+), 11 deletions(-)

diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 31ab82f..c825b63 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -361,7 +361,9 @@ static enum bp_state increase_reservation(unsigned long nr_pages)
 		set_phys_to_machine(pfn, frame_list[i]);
 
 		/* Link back into the page tables if not highmem. */
-		if (xen_pv_domain() && !PageHighMem(page)) {
+		if (xen_pv_domain() && !PageHighMem(page) &&
+		    !xen_feature(XENFEAT_auto_translated_physmap)) {
+
 			int ret;
 			ret = HYPERVISOR_update_va_mapping(
 				(unsigned long)__va(pfn << PAGE_SHIFT),
@@ -418,12 +420,13 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
 		scrub_page(page);
 
 		if (xen_pv_domain() && !PageHighMem(page)) {
-			ret = HYPERVISOR_update_va_mapping(
-				(unsigned long)__va(pfn << PAGE_SHIFT),
-				__pte_ma(0), 0);
-			BUG_ON(ret);
+			if (!xen_feature(XENFEAT_auto_translated_physmap)) {
+				ret = HYPERVISOR_update_va_mapping(
+					(unsigned long)__va(pfn << PAGE_SHIFT),
+					__pte_ma(0), 0);
+				BUG_ON(ret);
+			}
 		}
-
 	}
 
 	/* Ensure that ballooned highmem pages don't have kmaps. */
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 610bfc6..d39d54e 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -803,7 +803,8 @@ static int __init gntdev_init(void)
 	if (!xen_domain())
 		return -ENODEV;
 
-	use_ptemod = xen_pv_domain();
+	use_ptemod = xen_pv_domain() &&
+		     !xen_feature(XENFEAT_auto_translated_physmap);
 
 	err = misc_register(&gntdev_miscdev);
 	if (err != 0) {
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index b2b0a37..9c0019d 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -1029,14 +1029,19 @@ static void gnttab_unmap_frames_v2(void)
 static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 {
 	struct gnttab_setup_table setup;
-	unsigned long *frames;
+	unsigned long *frames, start_gpfn;
 	unsigned int nr_gframes = end_idx + 1;
 	int rc;
 
-	if (xen_hvm_domain()) {
+	if (xen_hvm_domain() || xen_feature(XENFEAT_auto_translated_physmap)) {
 		struct xen_add_to_physmap xatp;
 		unsigned int i = end_idx;
 		rc = 0;
+
+		if (xen_hvm_domain())
+			start_gpfn = xen_hvm_resume_frames >> PAGE_SHIFT;
+		else
+			start_gpfn = virt_to_pfn(gnttab_shared.addr);
 		/*
 		 * Loop backwards, so that the first hypercall has the largest
 		 * index, ensuring that the table will grow only once.
@@ -1045,7 +1050,7 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 			xatp.domid = DOMID_SELF;
 			xatp.idx = i;
 			xatp.space = XENMAPSPACE_grant_table;
-			xatp.gpfn = (xen_hvm_resume_frames >> PAGE_SHIFT) + i;
+			xatp.gpfn = start_gpfn + i;
 			rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
 			if (rc != 0) {
 				printk(KERN_WARNING
@@ -1108,7 +1113,7 @@ static void gnttab_request_version(void)
 	int rc;
 	struct gnttab_set_version gsv;
 
-	if (xen_hvm_domain())
+	if (xen_hvm_domain() || xen_feature(XENFEAT_auto_translated_physmap))
 		gsv.version = 1;
 	else
 		gsv.version = 2;
@@ -1136,12 +1141,25 @@ static void gnttab_request_version(void)
 int gnttab_resume(void)
 {
 	unsigned int max_nr_gframes;
+	char *kmsg = "Failed to kmalloc pages for pv in hvm grant frames\n";
 
 	gnttab_request_version();
 	max_nr_gframes = gnttab_max_grant_frames();
 	if (max_nr_gframes < nr_grant_frames)
 		return -ENOSYS;
 
+	/* PVH note: xen will free existing kmalloc'd mfn in
+	 * XENMEM_add_to_physmap. TBD/FIXME: use xen ballooning instead of
+	 * kmalloc(). */
+	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap) &&
+	    !gnttab_shared.addr) {
+		gnttab_shared.addr =
+			kmalloc(max_nr_gframes * PAGE_SIZE, GFP_KERNEL);
+		if (!gnttab_shared.addr) {
+			pr_warn("%s", kmsg);
+			return -ENOMEM;
+		}
+	}
 	if (xen_pv_domain())
 		return gnttab_map(0, nr_grant_frames - 1);
 
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 20 01:30:46 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Oct 2012 01:30:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPNtO-00062S-MK; Sat, 20 Oct 2012 01:30:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPNtM-00061n-Ey
	for xen-devel@lists.xensource.com; Sat, 20 Oct 2012 01:30:20 +0000
Received: from [85.158.143.99:49973] by server-1.bemta-4.messagelabs.com id
	4F/38-19134-BAEF1805; Sat, 20 Oct 2012 01:30:19 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1350696617!23596045!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODE2OTk0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6734 invoked from network); 20 Oct 2012 01:30:18 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Oct 2012 01:30:18 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9K1UCn9012046
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 20 Oct 2012 01:30:12 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9K1UB1L007023
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 20 Oct 2012 01:30:12 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9K1UBXN004883; Fri, 19 Oct 2012 20:30:11 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Oct 2012 18:30:10 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id AA7B74042E; Fri, 19 Oct 2012 21:18:05 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	mukesh.rathor@oracle.com, Ian.Campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Date: Fri, 19 Oct 2012 21:18:01 -0400
Message-Id: <1350695882-12820-6-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 5/6] xen/pvh: balloon and grant changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Mukesh Rathor 

For balloon changes we skip setting of local P2M as it's updated
in Xen. For grant, the shared grant frame is the pfn and not mfn,
hence its mapped via the same code path as HVM.

Signed-off-by: Mukesh Rathor 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 drivers/xen/balloon.c     |   15 +++++++++------
 drivers/xen/gntdev.c      |    3 ++-
 drivers/xen/grant-table.c |   26 ++++++++++++++++++++++----
 3 files changed, 33 insertions(+), 11 deletions(-)

diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 31ab82f..c825b63 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -361,7 +361,9 @@ static enum bp_state increase_reservation(unsigned long nr_pages)
 		set_phys_to_machine(pfn, frame_list[i]);
 
 		/* Link back into the page tables if not highmem. */
-		if (xen_pv_domain() && !PageHighMem(page)) {
+		if (xen_pv_domain() && !PageHighMem(page) &&
+		    !xen_feature(XENFEAT_auto_translated_physmap)) {
+
 			int ret;
 			ret = HYPERVISOR_update_va_mapping(
 				(unsigned long)__va(pfn << PAGE_SHIFT),
@@ -418,12 +420,13 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
 		scrub_page(page);
 
 		if (xen_pv_domain() && !PageHighMem(page)) {
-			ret = HYPERVISOR_update_va_mapping(
-				(unsigned long)__va(pfn << PAGE_SHIFT),
-				__pte_ma(0), 0);
-			BUG_ON(ret);
+			if (!xen_feature(XENFEAT_auto_translated_physmap)) {
+				ret = HYPERVISOR_update_va_mapping(
+					(unsigned long)__va(pfn << PAGE_SHIFT),
+					__pte_ma(0), 0);
+				BUG_ON(ret);
+			}
 		}
-
 	}
 
 	/* Ensure that ballooned highmem pages don't have kmaps. */
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 610bfc6..d39d54e 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -803,7 +803,8 @@ static int __init gntdev_init(void)
 	if (!xen_domain())
 		return -ENODEV;
 
-	use_ptemod = xen_pv_domain();
+	use_ptemod = xen_pv_domain() &&
+		     !xen_feature(XENFEAT_auto_translated_physmap);
 
 	err = misc_register(&gntdev_miscdev);
 	if (err != 0) {
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index b2b0a37..9c0019d 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -1029,14 +1029,19 @@ static void gnttab_unmap_frames_v2(void)
 static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 {
 	struct gnttab_setup_table setup;
-	unsigned long *frames;
+	unsigned long *frames, start_gpfn;
 	unsigned int nr_gframes = end_idx + 1;
 	int rc;
 
-	if (xen_hvm_domain()) {
+	if (xen_hvm_domain() || xen_feature(XENFEAT_auto_translated_physmap)) {
 		struct xen_add_to_physmap xatp;
 		unsigned int i = end_idx;
 		rc = 0;
+
+		if (xen_hvm_domain())
+			start_gpfn = xen_hvm_resume_frames >> PAGE_SHIFT;
+		else
+			start_gpfn = virt_to_pfn(gnttab_shared.addr);
 		/*
 		 * Loop backwards, so that the first hypercall has the largest
 		 * index, ensuring that the table will grow only once.
@@ -1045,7 +1050,7 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 			xatp.domid = DOMID_SELF;
 			xatp.idx = i;
 			xatp.space = XENMAPSPACE_grant_table;
-			xatp.gpfn = (xen_hvm_resume_frames >> PAGE_SHIFT) + i;
+			xatp.gpfn = start_gpfn + i;
 			rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
 			if (rc != 0) {
 				printk(KERN_WARNING
@@ -1108,7 +1113,7 @@ static void gnttab_request_version(void)
 	int rc;
 	struct gnttab_set_version gsv;
 
-	if (xen_hvm_domain())
+	if (xen_hvm_domain() || xen_feature(XENFEAT_auto_translated_physmap))
 		gsv.version = 1;
 	else
 		gsv.version = 2;
@@ -1136,12 +1141,25 @@ static void gnttab_request_version(void)
 int gnttab_resume(void)
 {
 	unsigned int max_nr_gframes;
+	char *kmsg = "Failed to kmalloc pages for pv in hvm grant frames\n";
 
 	gnttab_request_version();
 	max_nr_gframes = gnttab_max_grant_frames();
 	if (max_nr_gframes < nr_grant_frames)
 		return -ENOSYS;
 
+	/* PVH note: xen will free existing kmalloc'd mfn in
+	 * XENMEM_add_to_physmap. TBD/FIXME: use xen ballooning instead of
+	 * kmalloc(). */
+	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap) &&
+	    !gnttab_shared.addr) {
+		gnttab_shared.addr =
+			kmalloc(max_nr_gframes * PAGE_SIZE, GFP_KERNEL);
+		if (!gnttab_shared.addr) {
+			pr_warn("%s", kmsg);
+			return -ENOMEM;
+		}
+	}
 	if (xen_pv_domain())
 		return gnttab_map(0, nr_grant_frames - 1);
 
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 20 01:30:46 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Oct 2012 01:30:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPNtN-00062A-TH; Sat, 20 Oct 2012 01:30:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPNtM-00061k-6F
	for xen-devel@lists.xensource.com; Sat, 20 Oct 2012 01:30:20 +0000
Received: from [85.158.137.99:15252] by server-13.bemta-3.messagelabs.com id
	D9/A2-26794-BAEF1805; Sat, 20 Oct 2012 01:30:19 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1350696617!22197060!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgyNDExNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11505 invoked from network); 20 Oct 2012 01:30:18 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Oct 2012 01:30:18 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9K1UBCw022733
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 20 Oct 2012 01:30:12 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9K1UAVt012903
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 20 Oct 2012 01:30:10 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9K1U92v024369; Fri, 19 Oct 2012 20:30:09 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Oct 2012 18:30:09 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 818D54035B; Fri, 19 Oct 2012 21:18:05 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	mukesh.rathor@oracle.com, Ian.Campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Date: Fri, 19 Oct 2012 21:17:56 -0400
Message-Id: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: [Xen-devel] (no subject)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Mukesh provided me with the git of his with some of the changes to his
patches and as well the modifications done per review. I've done a bit
of changes in the git description to flesh them out some more.

Sending them out and I've also stuck the redone patches in my tree:
 git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git devel/pvh.v4

Please review. I think the only changes are just in the git commit
descriptions - so please pull our your wordsmith hat and lupe!

 arch/x86/include/asm/xen/interface.h |   11 ++-
 arch/x86/include/asm/xen/page.h      |    3 +
 arch/x86/xen/Kconfig                 |   10 ++
 arch/x86/xen/enlighten.c             |   77 ++++++++++++----
 arch/x86/xen/irq.c                   |    5 +-
 arch/x86/xen/mmu.c                   |  162 ++++++++++++++++++++++++++++++++--
 arch/x86/xen/mmu.h                   |    2 +
 arch/x86/xen/p2m.c                   |    2 +-
 arch/x86/xen/setup.c                 |   64 +++++++++++---
 arch/x86/xen/smp.c                   |   75 ++++++++++------
 arch/x86/xen/xen-head.S              |   11 ++-
 drivers/xen/balloon.c                |   15 ++--
 drivers/xen/cpu_hotplug.c            |    4 +-
 drivers/xen/events.c                 |    9 ++-
 drivers/xen/gntdev.c                 |    3 +-
 drivers/xen/grant-table.c            |   26 +++++-
 drivers/xen/privcmd.c                |   72 ++++++++++++++-
 drivers/xen/xenbus/xenbus_client.c   |    3 +-
 include/xen/interface/memory.h       |   24 +++++-
 include/xen/interface/physdev.h      |   10 ++
 include/xen/xen-ops.h                |    5 +-
 21 files changed, 507 insertions(+), 86 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 20 01:30:46 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Oct 2012 01:30:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPNtN-00062A-TH; Sat, 20 Oct 2012 01:30:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPNtM-00061k-6F
	for xen-devel@lists.xensource.com; Sat, 20 Oct 2012 01:30:20 +0000
Received: from [85.158.137.99:15252] by server-13.bemta-3.messagelabs.com id
	D9/A2-26794-BAEF1805; Sat, 20 Oct 2012 01:30:19 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1350696617!22197060!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgyNDExNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11505 invoked from network); 20 Oct 2012 01:30:18 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Oct 2012 01:30:18 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9K1UBCw022733
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 20 Oct 2012 01:30:12 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9K1UAVt012903
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 20 Oct 2012 01:30:10 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9K1U92v024369; Fri, 19 Oct 2012 20:30:09 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Oct 2012 18:30:09 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 818D54035B; Fri, 19 Oct 2012 21:18:05 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	mukesh.rathor@oracle.com, Ian.Campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Date: Fri, 19 Oct 2012 21:17:56 -0400
Message-Id: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: [Xen-devel] (no subject)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Mukesh provided me with the git of his with some of the changes to his
patches and as well the modifications done per review. I've done a bit
of changes in the git description to flesh them out some more.

Sending them out and I've also stuck the redone patches in my tree:
 git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git devel/pvh.v4

Please review. I think the only changes are just in the git commit
descriptions - so please pull our your wordsmith hat and lupe!

 arch/x86/include/asm/xen/interface.h |   11 ++-
 arch/x86/include/asm/xen/page.h      |    3 +
 arch/x86/xen/Kconfig                 |   10 ++
 arch/x86/xen/enlighten.c             |   77 ++++++++++++----
 arch/x86/xen/irq.c                   |    5 +-
 arch/x86/xen/mmu.c                   |  162 ++++++++++++++++++++++++++++++++--
 arch/x86/xen/mmu.h                   |    2 +
 arch/x86/xen/p2m.c                   |    2 +-
 arch/x86/xen/setup.c                 |   64 +++++++++++---
 arch/x86/xen/smp.c                   |   75 ++++++++++------
 arch/x86/xen/xen-head.S              |   11 ++-
 drivers/xen/balloon.c                |   15 ++--
 drivers/xen/cpu_hotplug.c            |    4 +-
 drivers/xen/events.c                 |    9 ++-
 drivers/xen/gntdev.c                 |    3 +-
 drivers/xen/grant-table.c            |   26 +++++-
 drivers/xen/privcmd.c                |   72 ++++++++++++++-
 drivers/xen/xenbus/xenbus_client.c   |    3 +-
 include/xen/interface/memory.h       |   24 +++++-
 include/xen/interface/physdev.h      |   10 ++
 include/xen/xen-ops.h                |    5 +-
 21 files changed, 507 insertions(+), 86 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 20 01:31:48 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Oct 2012 01:31:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPNuc-0006Rp-IO; Sat, 20 Oct 2012 01:31:38 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPNua-0006R9-HM
	for xen-devel@lists.xensource.com; Sat, 20 Oct 2012 01:31:36 +0000
Received: from [193.109.254.147:18777] by server-12.bemta-14.messagelabs.com
	id F1/F5-13558-7FEF1805; Sat, 20 Oct 2012 01:31:35 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1350696616!11600105!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgyNDExNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18501 invoked from network); 20 Oct 2012 01:30:18 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Oct 2012 01:30:18 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9K1UB1H022734
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 20 Oct 2012 01:30:12 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9K1UAfb012902
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 20 Oct 2012 01:30:10 GMT
Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9K1UA2C024373; Fri, 19 Oct 2012 20:30:10 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Oct 2012 18:30:09 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 98D0840376; Fri, 19 Oct 2012 21:18:05 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	mukesh.rathor@oracle.com, Ian.Campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Date: Fri, 19 Oct 2012 21:17:59 -0400
Message-Id: <1350695882-12820-4-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 3/6] xen/pvh: Implements mmu changes for PVH.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Mukesh Rathor 

First the set/clear mmio pte function makes a hypercall to update the
P2M in Xen with 1:1 mapping. Since PVH uses mostly native mmu ops, we
leave the generic (native_*) for the rest.

Two local functions are introduced to add to xen physmap for xen remap
interface. Xen unmap interface is introduced so the privcmd pte entries
can be cleared in Xen p2m table.

Signed-off-by: Mukesh Rathor 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/xen/mmu.c    |  162 +++++++++++++++++++++++++++++++++++++++++++++++--
 arch/x86/xen/mmu.h    |    2 +
 drivers/xen/privcmd.c |    5 +-
 include/xen/xen-ops.h |    5 +-
 4 files changed, 165 insertions(+), 9 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 6226c99..5747a41 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -74,6 +74,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "multicalls.h"
 #include "mmu.h"
@@ -332,6 +333,20 @@ static void xen_set_pte(pte_t *ptep, pte_t pteval)
 	__xen_set_pte(ptep, pteval);
 }
 
+void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn,
+			      int nr_mfns, int add_mapping)
+{
+	struct physdev_map_iomem iomem;
+
+	iomem.first_gfn = pfn;
+	iomem.first_mfn = mfn;
+	iomem.nr_mfns = nr_mfns;
+	iomem.add_mapping = add_mapping;
+
+	if (HYPERVISOR_physdev_op(PHYSDEVOP_map_iomem, &iomem))
+		BUG();
+}
+
 static void xen_set_pte_at(struct mm_struct *mm, unsigned long addr,
 		    pte_t *ptep, pte_t pteval)
 {
@@ -1221,6 +1236,8 @@ static void __init xen_pagetable_init(void)
 #endif
 	paging_init();
 	xen_setup_shared_info();
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return;
 #ifdef CONFIG_X86_64
 	if (!xen_feature(XENFEAT_auto_translated_physmap)) {
 		unsigned long new_mfn_list;
@@ -1528,6 +1545,10 @@ static void __init xen_set_pte_init(pte_t *ptep, pte_t pte)
 static void pin_pagetable_pfn(unsigned cmd, unsigned long pfn)
 {
 	struct mmuext_op op;
+
+	if (xen_feature(XENFEAT_writable_page_tables))
+		return;
+
 	op.cmd = cmd;
 	op.arg1.mfn = pfn_to_mfn(pfn);
 	if (HYPERVISOR_mmuext_op(&op, 1, NULL, DOMID_SELF))
@@ -1725,6 +1746,10 @@ static void set_page_prot(void *addr, pgprot_t prot)
 	unsigned long pfn = __pa(addr) >> PAGE_SHIFT;
 	pte_t pte = pfn_pte(pfn, prot);
 
+	/* recall for PVH, page tables are native. */
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return;
+
 	if (HYPERVISOR_update_va_mapping((unsigned long)addr, pte, 0))
 		BUG();
 }
@@ -1802,6 +1827,9 @@ static void convert_pfn_mfn(void *v)
 	pte_t *pte = v;
 	int i;
 
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return;
+
 	/* All levels are converted the same way, so just treat them
 	   as ptes. */
 	for (i = 0; i < PTRS_PER_PTE; i++)
@@ -1821,6 +1849,7 @@ static void __init check_pt_base(unsigned long *pt_base, unsigned long *pt_end,
 		(*pt_end)--;
 	}
 }
+
 /*
  * Set up the initial kernel pagetable.
  *
@@ -1831,6 +1860,7 @@ static void __init check_pt_base(unsigned long *pt_base, unsigned long *pt_end,
  * but that's enough to get __va working.  We need to fill in the rest
  * of the physical mapping once some sort of allocator has been set
  * up.
+ * NOTE: for PVH, the page tables are native.
  */
 void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn)
 {
@@ -1908,10 +1938,13 @@ void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn)
 	 * structure to attach it to, so make sure we just set kernel
 	 * pgd.
 	 */
-	xen_mc_batch();
-	__xen_write_cr3(true, __pa(init_level4_pgt));
-	xen_mc_issue(PARAVIRT_LAZY_CPU);
-
+	if (xen_feature(XENFEAT_writable_page_tables)) {
+		native_write_cr3(__pa(init_level4_pgt));
+	} else {
+		xen_mc_batch();
+		__xen_write_cr3(true, __pa(init_level4_pgt));
+		xen_mc_issue(PARAVIRT_LAZY_CPU);
+	}
 	/* We can't that easily rip out L3 and L2, as the Xen pagetables are
 	 * set out this way: [L4], [L1], [L2], [L3], [L1], [L1] ...  for
 	 * the initial domain. For guests using the toolstack, they are in:
@@ -2178,8 +2211,13 @@ static const struct pv_mmu_ops xen_mmu_ops __initconst = {
 
 void __init xen_init_mmu_ops(void)
 {
-	x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
 	x86_init.paging.pagetable_init = xen_pagetable_init;
+
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		pv_mmu_ops.flush_tlb_others = xen_flush_tlb_others;
+		return;
+	}
+	x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
 	pv_mmu_ops = xen_mmu_ops;
 
 	memset(dummy_mapping, 0xff, PAGE_SIZE);
@@ -2455,6 +2493,89 @@ void __init xen_hvm_init_mmu_ops(void)
 }
 #endif
 
+/* Map foreign gmfn, fgmfn, to local pfn, lpfn. This for the user space
+ * creating new guest on PVH dom0 and needs to map domU pages.
+ */
+static int pvh_add_to_xen_p2m(unsigned long lpfn, unsigned long fgmfn,
+			      unsigned int domid)
+{
+	int rc;
+	struct xen_add_to_physmap xatp = { .foreign_domid = domid };
+
+	xatp.gpfn = lpfn;
+	xatp.idx = fgmfn;
+	xatp.domid = DOMID_SELF;
+	xatp.space = XENMAPSPACE_gmfn_foreign;
+	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
+	if (rc)
+		pr_warn("d0: Failed to map pfn (0x%lx) to mfn (0x%lx) rc:%d\n",
+			lpfn, fgmfn, rc);
+	return rc;
+}
+
+static int pvh_rem_xen_p2m(unsigned long spfn, int count)
+{
+	struct xen_remove_from_physmap xrp;
+	int i, rc;
+
+	for (i = 0; i < count; i++) {
+		xrp.domid = DOMID_SELF;
+		xrp.gpfn = spfn+i;
+		rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, &xrp);
+		if (rc) {
+			pr_warn("Failed to unmap pfn:%lx rc:%d done:%d\n",
+				spfn+i, rc, i);
+			return 1;
+		}
+	}
+	return 0;
+}
+
+struct pvh_remap_data {
+	unsigned long fgmfn;		/* foreign domain's gmfn */
+	pgprot_t prot;
+	domid_t  domid;
+	int	 index;
+	struct page **pages;
+};
+
+static int pvh_map_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr,
+			void *data)
+{
+	int rc;
+	struct pvh_remap_data *remap = data;
+	unsigned long pfn = page_to_pfn(remap->pages[remap->index++]);
+	pte_t pteval = pte_mkspecial(pfn_pte(pfn, remap->prot));
+
+	rc = pvh_add_to_xen_p2m(pfn, remap->fgmfn, remap->domid);
+	if (rc)
+		return rc;
+	native_set_pte(ptep, pteval);
+
+	return 0;
+}
+
+static int pvh_remap_gmfn_range(struct vm_area_struct *vma,
+				unsigned long addr, unsigned long mfn, int nr,
+				pgprot_t prot, unsigned domid,
+				struct page **pages)
+{
+	int err;
+	struct pvh_remap_data pvhdata;
+
+	BUG_ON(!pages);
+
+	pvhdata.fgmfn = mfn;
+	pvhdata.prot = prot;
+	pvhdata.domid = domid;
+	pvhdata.index = 0;
+	pvhdata.pages = pages;
+	err = apply_to_page_range(vma->vm_mm, addr, nr << PAGE_SHIFT,
+				  pvh_map_pte_fn, &pvhdata);
+	flush_tlb_all();
+	return err;
+}
+
 #define REMAP_BATCH_SIZE 16
 
 struct remap_data {
@@ -2479,7 +2600,9 @@ static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token,
 int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 			       unsigned long addr,
 			       unsigned long mfn, int nr,
-			       pgprot_t prot, unsigned domid)
+			       pgprot_t prot, unsigned domid,
+			       struct page **pages)
+
 {
 	struct remap_data rmd;
 	struct mmu_update mmu_update[REMAP_BATCH_SIZE];
@@ -2494,6 +2617,10 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 
 	BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_IO)) == (VM_PFNMAP | VM_IO)));
 
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		/* We need to update the local page tables and the xen HAP */
+		return pvh_remap_gmfn_range(vma, addr, mfn, nr, prot, domid, pages);
+	}
 	rmd.mfn = mfn;
 	rmd.prot = prot;
 
@@ -2523,3 +2650,26 @@ out:
 	return err;
 }
 EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
+
+/* Returns: 0 success */
+int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
+			       int numpgs, struct page **pages)
+{
+	if (!pages || !xen_feature(XENFEAT_auto_translated_physmap))
+		return 0;
+
+	while (numpgs--) {
+
+		/* the mmu has already cleaned up the process mmu resources at
+		 * this point (lookup_address will return NULL). */
+		unsigned long pfn = page_to_pfn(pages[numpgs]);
+
+		pvh_rem_xen_p2m(pfn, 1);
+	}
+	/* We don't need to flush tlbs because as part of pvh_rem_xen_p2m(),
+	 * the hypervisor will do tlb flushes after removing the p2m entries
+	 * from the EPT/NPT */
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range);
diff --git a/arch/x86/xen/mmu.h b/arch/x86/xen/mmu.h
index 73809bb..6d0bb56 100644
--- a/arch/x86/xen/mmu.h
+++ b/arch/x86/xen/mmu.h
@@ -23,4 +23,6 @@ unsigned long xen_read_cr2_direct(void);
 
 extern void xen_init_mmu_ops(void);
 extern void xen_hvm_init_mmu_ops(void);
+extern void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn,
+				     int nr_mfns, int add_mapping);
 #endif	/* _XEN_MMU_H */
diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 8adb9cc..b612267 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -178,7 +178,7 @@ static int mmap_mfn_range(void *data, void *state)
 					msg->va & PAGE_MASK,
 					msg->mfn, msg->npages,
 					vma->vm_page_prot,
-					st->domain);
+					st->domain, NULL);
 	if (rc < 0)
 		return rc;
 
@@ -267,7 +267,8 @@ static int mmap_batch_fn(void *data, void *state)
 	int ret;
 
 	ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
-					 st->vma->vm_page_prot, st->domain);
+					 st->vma->vm_page_prot, st->domain,
+					 NULL);
 
 	/* Store error code for second pass. */
 	*(st->err++) = ret;
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 6a198e4..990b43e 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -27,6 +27,9 @@ struct vm_area_struct;
 int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 			       unsigned long addr,
 			       unsigned long mfn, int nr,
-			       pgprot_t prot, unsigned domid);
+			       pgprot_t prot, unsigned domid,
+			       struct page **pages);
+int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
+			       int numpgs, struct page **pages);
 
 #endif /* INCLUDE_XEN_OPS_H */
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 20 01:31:48 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Oct 2012 01:31:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPNuc-0006Rp-IO; Sat, 20 Oct 2012 01:31:38 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPNua-0006R9-HM
	for xen-devel@lists.xensource.com; Sat, 20 Oct 2012 01:31:36 +0000
Received: from [193.109.254.147:18777] by server-12.bemta-14.messagelabs.com
	id F1/F5-13558-7FEF1805; Sat, 20 Oct 2012 01:31:35 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1350696616!11600105!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgyNDExNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18501 invoked from network); 20 Oct 2012 01:30:18 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Oct 2012 01:30:18 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9K1UB1H022734
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 20 Oct 2012 01:30:12 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9K1UAfb012902
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 20 Oct 2012 01:30:10 GMT
Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9K1UA2C024373; Fri, 19 Oct 2012 20:30:10 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 19 Oct 2012 18:30:09 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 98D0840376; Fri, 19 Oct 2012 21:18:05 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	mukesh.rathor@oracle.com, Ian.Campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Date: Fri, 19 Oct 2012 21:17:59 -0400
Message-Id: <1350695882-12820-4-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 3/6] xen/pvh: Implements mmu changes for PVH.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Mukesh Rathor 

First the set/clear mmio pte function makes a hypercall to update the
P2M in Xen with 1:1 mapping. Since PVH uses mostly native mmu ops, we
leave the generic (native_*) for the rest.

Two local functions are introduced to add to xen physmap for xen remap
interface. Xen unmap interface is introduced so the privcmd pte entries
can be cleared in Xen p2m table.

Signed-off-by: Mukesh Rathor 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/xen/mmu.c    |  162 +++++++++++++++++++++++++++++++++++++++++++++++--
 arch/x86/xen/mmu.h    |    2 +
 drivers/xen/privcmd.c |    5 +-
 include/xen/xen-ops.h |    5 +-
 4 files changed, 165 insertions(+), 9 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 6226c99..5747a41 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -74,6 +74,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "multicalls.h"
 #include "mmu.h"
@@ -332,6 +333,20 @@ static void xen_set_pte(pte_t *ptep, pte_t pteval)
 	__xen_set_pte(ptep, pteval);
 }
 
+void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn,
+			      int nr_mfns, int add_mapping)
+{
+	struct physdev_map_iomem iomem;
+
+	iomem.first_gfn = pfn;
+	iomem.first_mfn = mfn;
+	iomem.nr_mfns = nr_mfns;
+	iomem.add_mapping = add_mapping;
+
+	if (HYPERVISOR_physdev_op(PHYSDEVOP_map_iomem, &iomem))
+		BUG();
+}
+
 static void xen_set_pte_at(struct mm_struct *mm, unsigned long addr,
 		    pte_t *ptep, pte_t pteval)
 {
@@ -1221,6 +1236,8 @@ static void __init xen_pagetable_init(void)
 #endif
 	paging_init();
 	xen_setup_shared_info();
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return;
 #ifdef CONFIG_X86_64
 	if (!xen_feature(XENFEAT_auto_translated_physmap)) {
 		unsigned long new_mfn_list;
@@ -1528,6 +1545,10 @@ static void __init xen_set_pte_init(pte_t *ptep, pte_t pte)
 static void pin_pagetable_pfn(unsigned cmd, unsigned long pfn)
 {
 	struct mmuext_op op;
+
+	if (xen_feature(XENFEAT_writable_page_tables))
+		return;
+
 	op.cmd = cmd;
 	op.arg1.mfn = pfn_to_mfn(pfn);
 	if (HYPERVISOR_mmuext_op(&op, 1, NULL, DOMID_SELF))
@@ -1725,6 +1746,10 @@ static void set_page_prot(void *addr, pgprot_t prot)
 	unsigned long pfn = __pa(addr) >> PAGE_SHIFT;
 	pte_t pte = pfn_pte(pfn, prot);
 
+	/* recall for PVH, page tables are native. */
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return;
+
 	if (HYPERVISOR_update_va_mapping((unsigned long)addr, pte, 0))
 		BUG();
 }
@@ -1802,6 +1827,9 @@ static void convert_pfn_mfn(void *v)
 	pte_t *pte = v;
 	int i;
 
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return;
+
 	/* All levels are converted the same way, so just treat them
 	   as ptes. */
 	for (i = 0; i < PTRS_PER_PTE; i++)
@@ -1821,6 +1849,7 @@ static void __init check_pt_base(unsigned long *pt_base, unsigned long *pt_end,
 		(*pt_end)--;
 	}
 }
+
 /*
  * Set up the initial kernel pagetable.
  *
@@ -1831,6 +1860,7 @@ static void __init check_pt_base(unsigned long *pt_base, unsigned long *pt_end,
  * but that's enough to get __va working.  We need to fill in the rest
  * of the physical mapping once some sort of allocator has been set
  * up.
+ * NOTE: for PVH, the page tables are native.
  */
 void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn)
 {
@@ -1908,10 +1938,13 @@ void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn)
 	 * structure to attach it to, so make sure we just set kernel
 	 * pgd.
 	 */
-	xen_mc_batch();
-	__xen_write_cr3(true, __pa(init_level4_pgt));
-	xen_mc_issue(PARAVIRT_LAZY_CPU);
-
+	if (xen_feature(XENFEAT_writable_page_tables)) {
+		native_write_cr3(__pa(init_level4_pgt));
+	} else {
+		xen_mc_batch();
+		__xen_write_cr3(true, __pa(init_level4_pgt));
+		xen_mc_issue(PARAVIRT_LAZY_CPU);
+	}
 	/* We can't that easily rip out L3 and L2, as the Xen pagetables are
 	 * set out this way: [L4], [L1], [L2], [L3], [L1], [L1] ...  for
 	 * the initial domain. For guests using the toolstack, they are in:
@@ -2178,8 +2211,13 @@ static const struct pv_mmu_ops xen_mmu_ops __initconst = {
 
 void __init xen_init_mmu_ops(void)
 {
-	x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
 	x86_init.paging.pagetable_init = xen_pagetable_init;
+
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		pv_mmu_ops.flush_tlb_others = xen_flush_tlb_others;
+		return;
+	}
+	x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
 	pv_mmu_ops = xen_mmu_ops;
 
 	memset(dummy_mapping, 0xff, PAGE_SIZE);
@@ -2455,6 +2493,89 @@ void __init xen_hvm_init_mmu_ops(void)
 }
 #endif
 
+/* Map foreign gmfn, fgmfn, to local pfn, lpfn. This for the user space
+ * creating new guest on PVH dom0 and needs to map domU pages.
+ */
+static int pvh_add_to_xen_p2m(unsigned long lpfn, unsigned long fgmfn,
+			      unsigned int domid)
+{
+	int rc;
+	struct xen_add_to_physmap xatp = { .foreign_domid = domid };
+
+	xatp.gpfn = lpfn;
+	xatp.idx = fgmfn;
+	xatp.domid = DOMID_SELF;
+	xatp.space = XENMAPSPACE_gmfn_foreign;
+	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
+	if (rc)
+		pr_warn("d0: Failed to map pfn (0x%lx) to mfn (0x%lx) rc:%d\n",
+			lpfn, fgmfn, rc);
+	return rc;
+}
+
+static int pvh_rem_xen_p2m(unsigned long spfn, int count)
+{
+	struct xen_remove_from_physmap xrp;
+	int i, rc;
+
+	for (i = 0; i < count; i++) {
+		xrp.domid = DOMID_SELF;
+		xrp.gpfn = spfn+i;
+		rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, &xrp);
+		if (rc) {
+			pr_warn("Failed to unmap pfn:%lx rc:%d done:%d\n",
+				spfn+i, rc, i);
+			return 1;
+		}
+	}
+	return 0;
+}
+
+struct pvh_remap_data {
+	unsigned long fgmfn;		/* foreign domain's gmfn */
+	pgprot_t prot;
+	domid_t  domid;
+	int	 index;
+	struct page **pages;
+};
+
+static int pvh_map_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr,
+			void *data)
+{
+	int rc;
+	struct pvh_remap_data *remap = data;
+	unsigned long pfn = page_to_pfn(remap->pages[remap->index++]);
+	pte_t pteval = pte_mkspecial(pfn_pte(pfn, remap->prot));
+
+	rc = pvh_add_to_xen_p2m(pfn, remap->fgmfn, remap->domid);
+	if (rc)
+		return rc;
+	native_set_pte(ptep, pteval);
+
+	return 0;
+}
+
+static int pvh_remap_gmfn_range(struct vm_area_struct *vma,
+				unsigned long addr, unsigned long mfn, int nr,
+				pgprot_t prot, unsigned domid,
+				struct page **pages)
+{
+	int err;
+	struct pvh_remap_data pvhdata;
+
+	BUG_ON(!pages);
+
+	pvhdata.fgmfn = mfn;
+	pvhdata.prot = prot;
+	pvhdata.domid = domid;
+	pvhdata.index = 0;
+	pvhdata.pages = pages;
+	err = apply_to_page_range(vma->vm_mm, addr, nr << PAGE_SHIFT,
+				  pvh_map_pte_fn, &pvhdata);
+	flush_tlb_all();
+	return err;
+}
+
 #define REMAP_BATCH_SIZE 16
 
 struct remap_data {
@@ -2479,7 +2600,9 @@ static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token,
 int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 			       unsigned long addr,
 			       unsigned long mfn, int nr,
-			       pgprot_t prot, unsigned domid)
+			       pgprot_t prot, unsigned domid,
+			       struct page **pages)
+
 {
 	struct remap_data rmd;
 	struct mmu_update mmu_update[REMAP_BATCH_SIZE];
@@ -2494,6 +2617,10 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 
 	BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_IO)) == (VM_PFNMAP | VM_IO)));
 
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		/* We need to update the local page tables and the xen HAP */
+		return pvh_remap_gmfn_range(vma, addr, mfn, nr, prot, domid, pages);
+	}
 	rmd.mfn = mfn;
 	rmd.prot = prot;
 
@@ -2523,3 +2650,26 @@ out:
 	return err;
 }
 EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
+
+/* Returns: 0 success */
+int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
+			       int numpgs, struct page **pages)
+{
+	if (!pages || !xen_feature(XENFEAT_auto_translated_physmap))
+		return 0;
+
+	while (numpgs--) {
+
+		/* the mmu has already cleaned up the process mmu resources at
+		 * this point (lookup_address will return NULL). */
+		unsigned long pfn = page_to_pfn(pages[numpgs]);
+
+		pvh_rem_xen_p2m(pfn, 1);
+	}
+	/* We don't need to flush tlbs because as part of pvh_rem_xen_p2m(),
+	 * the hypervisor will do tlb flushes after removing the p2m entries
+	 * from the EPT/NPT */
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range);
diff --git a/arch/x86/xen/mmu.h b/arch/x86/xen/mmu.h
index 73809bb..6d0bb56 100644
--- a/arch/x86/xen/mmu.h
+++ b/arch/x86/xen/mmu.h
@@ -23,4 +23,6 @@ unsigned long xen_read_cr2_direct(void);
 
 extern void xen_init_mmu_ops(void);
 extern void xen_hvm_init_mmu_ops(void);
+extern void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn,
+				     int nr_mfns, int add_mapping);
 #endif	/* _XEN_MMU_H */
diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 8adb9cc..b612267 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -178,7 +178,7 @@ static int mmap_mfn_range(void *data, void *state)
 					msg->va & PAGE_MASK,
 					msg->mfn, msg->npages,
 					vma->vm_page_prot,
-					st->domain);
+					st->domain, NULL);
 	if (rc < 0)
 		return rc;
 
@@ -267,7 +267,8 @@ static int mmap_batch_fn(void *data, void *state)
 	int ret;
 
 	ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
-					 st->vma->vm_page_prot, st->domain);
+					 st->vma->vm_page_prot, st->domain,
+					 NULL);
 
 	/* Store error code for second pass. */
 	*(st->err++) = ret;
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 6a198e4..990b43e 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -27,6 +27,9 @@ struct vm_area_struct;
 int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 			       unsigned long addr,
 			       unsigned long mfn, int nr,
-			       pgprot_t prot, unsigned domid);
+			       pgprot_t prot, unsigned domid,
+			       struct page **pages);
+int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
+			       int numpgs, struct page **pages);
 
 #endif /* INCLUDE_XEN_OPS_H */
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 20 04:30:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Oct 2012 04:30:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPQhE-0007xF-Sr; Sat, 20 Oct 2012 04:30:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPQhD-0007xA-IA
	for xen-devel@lists.xensource.com; Sat, 20 Oct 2012 04:29:59 +0000
Received: from [85.158.138.51:12667] by server-13.bemta-3.messagelabs.com id
	8F/04-26794-6C822805; Sat, 20 Oct 2012 04:29:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1350707397!33309141!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUxMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3334 invoked from network); 20 Oct 2012 04:29:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Oct 2012 04:29:58 -0000
X-IronPort-AV: E=Sophos;i="4.80,619,1344211200"; d="scan'208";a="15288354"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Oct 2012 04:29:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sat, 20 Oct 2012 05:29:56 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TPQhA-0005F7-NY;
	Sat, 20 Oct 2012 04:29:56 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TPQhA-0004Lt-1T;
	Sat, 20 Oct 2012 05:29:56 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Sat, 20 Oct 2012 05:29:56 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14065: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14065 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14065/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 14064
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 14064
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 14064
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 14064

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  478ba3f146df
baseline version:
 xen                  478ba3f146df

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 20 04:30:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Oct 2012 04:30:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPQhE-0007xF-Sr; Sat, 20 Oct 2012 04:30:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPQhD-0007xA-IA
	for xen-devel@lists.xensource.com; Sat, 20 Oct 2012 04:29:59 +0000
Received: from [85.158.138.51:12667] by server-13.bemta-3.messagelabs.com id
	8F/04-26794-6C822805; Sat, 20 Oct 2012 04:29:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1350707397!33309141!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUxMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3334 invoked from network); 20 Oct 2012 04:29:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Oct 2012 04:29:58 -0000
X-IronPort-AV: E=Sophos;i="4.80,619,1344211200"; d="scan'208";a="15288354"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Oct 2012 04:29:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sat, 20 Oct 2012 05:29:56 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TPQhA-0005F7-NY;
	Sat, 20 Oct 2012 04:29:56 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TPQhA-0004Lt-1T;
	Sat, 20 Oct 2012 05:29:56 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Sat, 20 Oct 2012 05:29:56 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14065: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14065 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14065/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 14064
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 14064
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 14064
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 14064

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  478ba3f146df
baseline version:
 xen                  478ba3f146df

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 20 07:22:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Oct 2012 07:22:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPTNC-0000rn-Pb; Sat, 20 Oct 2012 07:21:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPTNB-0000ri-F9
	for xen-devel@lists.xen.org; Sat, 20 Oct 2012 07:21:29 +0000
Received: from [85.158.139.211:19817] by server-4.bemta-5.messagelabs.com id
	23/52-01455-8F052805; Sat, 20 Oct 2012 07:21:28 +0000
X-Env-Sender: abb@gremwell.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1350717686!23098779!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32027 invoked from network); 20 Oct 2012 07:21:27 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Oct 2012 07:21:27 -0000
Received: by mail-vc0-f173.google.com with SMTP id fl15so1587311vcb.32
	for ; Sat, 20 Oct 2012 00:21:26 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:x-gm-message-state;
	bh=uiGuYqXNCyGdUM0RIrJBGDvJYlep2Mv7PbgMFHH0gsM=;
	b=EKqd+wskqaNfodI3aGn88mWhSLnuuC/sTILsqshLP0KiWjFW2NeR/PAJsCOUdbUUt2
	D8uwLfnOWXl9CHvTqioGBqgfU7RZ125NABh1A05yqWSQicaOGlRXE1t/CdUVno/INf4N
	/VGs2lXnXbIc9cV4WYByoZ/xaF+j2WemvUJ5HWxTyaWLrTTzff51YQ2fSVpjK5rzybO1
	UNzrVUD5lPI7IU4NWGOrS7PTTC1N7OMaPrlsIZCh1LpA2ZOwNF3xKkivx009nfT26aXY
	e9dZw65hnQKNcg8YlxMBTA7n3b1P7zirC97+aKAwwiBH8mMnL6Z7RCEpicNIlOU4PsIf
	xI6w==
MIME-Version: 1.0
Received: by 10.220.223.13 with SMTP id ii13mr4573683vcb.2.1350717685872; Sat,
	20 Oct 2012 00:21:25 -0700 (PDT)
Received: by 10.58.155.226 with HTTP; Sat, 20 Oct 2012 00:21:25 -0700 (PDT)
In-Reply-To: 
References: 
	<20121017121115.GI8912@reaktio.net> <507EB52D.1040209@gremwell.com>
	<507EB7A1.1080907@gremwell.com>
	<20121017154109.GB7590@phenom.dumpdata.com>
	
Date: Sat, 20 Oct 2012 09:21:25 +0200
Message-ID: 
From: Alexandre Bezroutchko 
To: Konrad Rzeszutek Wilk 
X-Gm-Message-State: ALoCoQltTNLruXY6eZTCin481lffOwDzq6Nv6vjogIQZEU9KoGKvvj8TOQF1E1QPBMzYY9nyhWPm
Cc: "nathanael@polymorpheus.com" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] pvusb with kernel 3.4 / 3.6
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============6656472780114535475=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6656472780114535475==
Content-Type: multipart/alternative; boundary=14dae9cdc84fdbb77f04cc787781

--14dae9cdc84fdbb77f04cc787781
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 17, 2012 at 6:08 PM, Alexandre Bezroutchko wr=
ote:

> On 17 Oct 2012, at 17:41, Konrad Rzeszutek Wilk 
> wrote:
>
> On Wed, Oct 17, 2012 at 03:50:25PM +0200, Alexandre Bezroutchko wrote:
>
> On 10/17/2012 03:39 PM, Alexandre Bezroutchko wrote:
>
> Thanks for the hint, found it, here it is:
>
>
>
> http://wiki.xen.org/wiki/Xen_Development_Projects#Upstreaming_Xen_PVUSB_d=
rivers_to_mainline_Linux_kernel
>
>
> On 10/17/2012 02:11 PM, Pasi K=E4rkk=E4inen wrote:
>
> On Wed, Oct 17, 2012 at 01:21:53PM +0200, Alexandre Bezroutchko wrote:
>
>   Hi Nathanael,
>
>
>   Is it possible to use your patch [1] on newer kernels? I've tried to us=
e
>
>   it but most devices are not usable and some cause kernel crash. Detaile=
d
>
>   description of an attempt on kernel 3.4 is at [2] and (somewhat less
>
>   detailed) with 3.6 is at [3]. I'm motivated to make it work, any ideas
>
>   what can be done to fix this issue? Please tell me if you need any
>
>   additional info.
>
>
>   I've added xen-devel and Pasi K=E4rkk=E4inen into Cc, hope this is ok.
>
>
> I think Konrad has the pvusb drivers in his git tree..
>
> Konrad's repo seems to contain the same patch [1] as published by
>
> Nathanael. It does not work for me. I've put Konrad in Cc, hope he can
>
> comment...
>
>
> So how does it not work?
>
>
> Here is my original question, please tell me what additional info you nee=
d.
>

Have I failed to provide enough information, or there is some gross mistake
in my setup?

Could you please describe a setup for pvusb which linux 3.4 kernel and xen
4.1 having good chance to work?


> -----------
> *pvusb with kernel 3.4 / 3.6*
> ------------------------------
> Hi Nathanael,
>
> Is it possible to use your patch [1] on newer kernels? I've tried to use
> it
> but most devices are not usable and some cause kernel crash. Detailed
> description of an attempt on kernel 3.4 is at [2] and (somewhat less
> detailed) with 3.6 is at [3]. I'm motivated to make it work, any ideas
> what
> can be done to fix this issue? Please tell me if you need any additional
> info.
>
> I've added xen-devel and Pasi K=E4rkk=E4inen into Cc, hope this is ok.
>
> Regards,
> Alex
>
> [1] http://lists.xen.org/archives/html/xen-devel/2012-02/msg00571.html
> [2] https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/3IAf7f8lz2UJ
> [3] https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/rNmVAOXX4dYJ
> ------------
>
>
> [1]
>
>
> http://git.kernel.org/?p=3Dlinux/kernel/git/konrad/xen.git;a=3Dpatch;h=3D=
10b675fc21702ff5a9b94fc13e2b504ca09073fd
>
>
> Regards,
>
> Alex
>
>
>
>
> -- Pasi
>
>
>
>   Regards,
>
>   Alex
>
>
>   [1] [1]
> http://lists.xen.org/archives/html/xen-devel/2012-02/msg00571.html
>
>   [2]
>
>   [2]https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/3IAf7f8lz2UJ
>
>   [3]
>
>   [3]https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/rNmVAOXX4dYJ
>
>
> References
>
>
>   Visible links
>
>   1. http://lists.xen.org/archives/html/xen-devel/2012-02/msg00571.html
>
>   2. https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/3IAf7f8lz2UJ
>
>   3. https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/rNmVAOXX4dYJ
>
>

--14dae9cdc84fdbb77f04cc787781
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On Wed, Oct 17, 2012 at 6:08 PM, Alexand=
re Bezroutchko <abb@gremwell.com> wrote:


On 17=
 Oct 2012, at 17:41, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
=



On Wed, Oct 17, 2012 at 03:5=
0:25PM +0200, Alexandre Bezroutchko wrote:
On 10/17/2012 03:39 PM, Alexandre Bezroutchko wrote:


Thanks for the hi=
nt, found it, here it is:



http://wiki.xen.org/wiki/Xen_Dev=
elopment_Projects#Upstreaming_Xen_PVUSB_drivers_to_mainline_Linux_kernel



On 10/17/2012 02:11 PM, Pasi K=E4rkk=E4inen wr=
ote:


On Wed, Oct 17, 2012 at 01:21:53PM +0200=
, Alexandre Bezroutchko wrote:


 =A0=A0Hi Nathanael,



=
 =A0=A0Is it possible to use your patch [1] on newer kernels? I'v=
e tried to use


 =A0=A0it but most devices are not usable and some cause kernel=
 crash. Detailed


 =A0=A0description of an attempt on kernel 3.4 is at [2] and (s=
omewhat less


 =A0=A0detailed) with 3.6 is at [3]. I'm motivated to make =
it work, any ideas


 =A0=A0what can be done to fix this issue? Please tell me if yo=
u need any


 =A0=A0additional info.





 =A0=A0I've a=
dded xen-devel and Pasi K=E4rkk=E4inen into Cc, hope this is ok.
=




I think Konrad has t=
he pvusb drivers in his git tree..


Konr=
ad's repo seems to contain the same patch [1] as published by
Nathanael. It does not work f=
or me. I've put Konrad in Cc, hope he can


comment...

So how does it not work?




-----------
------------


[1]
http://git.kernel.org/?p=3Dlinux/kernel/git/konrad/xen.git;a=3Dpatch;=
h=3D10b675fc21702ff5a9b94fc13e2b504ca09073fd



Regards,
Alex




=



-- Pasi






 =A0=A0Regards,
<=
/blockquote>


 =A0=A0Alex
=



 =
=A0=A0[1] [1]http://lists.xen.org/archives/html/xen-d=
evel/2012-02/msg00571.html


 =A0=A0[2]


 =A0=A0[2]https:=
//groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/3IAf7f8lz2UJ

 =A0=A0[3]


 =A0=A0[3]https:=
//groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/rNmVAOXX4dYJ


=



References



 =A0=A0Visible links=



 =A0=A01. http://lists.xen.org/archives/h=
tml/xen-devel/2012-02/msg00571.html


 =A0=A02. https://groups.google.com/d/m=
sg/qubes-devel/4AKulABh2Jc/3IAf7f8lz2UJ


 =A0=A03. https://groups.google.com/d/m=
sg/qubes-devel/4AKulABh2Jc/rNmVAOXX4dYJ





--14dae9cdc84fdbb77f04cc787781--


--===============6656472780114535475==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6656472780114535475==--


From xen-devel-bounces@lists.xen.org Sat Oct 20 07:22:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Oct 2012 07:22:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPTNC-0000rn-Pb; Sat, 20 Oct 2012 07:21:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPTNB-0000ri-F9
	for xen-devel@lists.xen.org; Sat, 20 Oct 2012 07:21:29 +0000
Received: from [85.158.139.211:19817] by server-4.bemta-5.messagelabs.com id
	23/52-01455-8F052805; Sat, 20 Oct 2012 07:21:28 +0000
X-Env-Sender: abb@gremwell.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1350717686!23098779!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32027 invoked from network); 20 Oct 2012 07:21:27 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Oct 2012 07:21:27 -0000
Received: by mail-vc0-f173.google.com with SMTP id fl15so1587311vcb.32
	for ; Sat, 20 Oct 2012 00:21:26 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:x-gm-message-state;
	bh=uiGuYqXNCyGdUM0RIrJBGDvJYlep2Mv7PbgMFHH0gsM=;
	b=EKqd+wskqaNfodI3aGn88mWhSLnuuC/sTILsqshLP0KiWjFW2NeR/PAJsCOUdbUUt2
	D8uwLfnOWXl9CHvTqioGBqgfU7RZ125NABh1A05yqWSQicaOGlRXE1t/CdUVno/INf4N
	/VGs2lXnXbIc9cV4WYByoZ/xaF+j2WemvUJ5HWxTyaWLrTTzff51YQ2fSVpjK5rzybO1
	UNzrVUD5lPI7IU4NWGOrS7PTTC1N7OMaPrlsIZCh1LpA2ZOwNF3xKkivx009nfT26aXY
	e9dZw65hnQKNcg8YlxMBTA7n3b1P7zirC97+aKAwwiBH8mMnL6Z7RCEpicNIlOU4PsIf
	xI6w==
MIME-Version: 1.0
Received: by 10.220.223.13 with SMTP id ii13mr4573683vcb.2.1350717685872; Sat,
	20 Oct 2012 00:21:25 -0700 (PDT)
Received: by 10.58.155.226 with HTTP; Sat, 20 Oct 2012 00:21:25 -0700 (PDT)
In-Reply-To: 
References: 
	<20121017121115.GI8912@reaktio.net> <507EB52D.1040209@gremwell.com>
	<507EB7A1.1080907@gremwell.com>
	<20121017154109.GB7590@phenom.dumpdata.com>
	
Date: Sat, 20 Oct 2012 09:21:25 +0200
Message-ID: 
From: Alexandre Bezroutchko 
To: Konrad Rzeszutek Wilk 
X-Gm-Message-State: ALoCoQltTNLruXY6eZTCin481lffOwDzq6Nv6vjogIQZEU9KoGKvvj8TOQF1E1QPBMzYY9nyhWPm
Cc: "nathanael@polymorpheus.com" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] pvusb with kernel 3.4 / 3.6
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============6656472780114535475=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6656472780114535475==
Content-Type: multipart/alternative; boundary=14dae9cdc84fdbb77f04cc787781

--14dae9cdc84fdbb77f04cc787781
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 17, 2012 at 6:08 PM, Alexandre Bezroutchko wr=
ote:

> On 17 Oct 2012, at 17:41, Konrad Rzeszutek Wilk 
> wrote:
>
> On Wed, Oct 17, 2012 at 03:50:25PM +0200, Alexandre Bezroutchko wrote:
>
> On 10/17/2012 03:39 PM, Alexandre Bezroutchko wrote:
>
> Thanks for the hint, found it, here it is:
>
>
>
> http://wiki.xen.org/wiki/Xen_Development_Projects#Upstreaming_Xen_PVUSB_d=
rivers_to_mainline_Linux_kernel
>
>
> On 10/17/2012 02:11 PM, Pasi K=E4rkk=E4inen wrote:
>
> On Wed, Oct 17, 2012 at 01:21:53PM +0200, Alexandre Bezroutchko wrote:
>
>   Hi Nathanael,
>
>
>   Is it possible to use your patch [1] on newer kernels? I've tried to us=
e
>
>   it but most devices are not usable and some cause kernel crash. Detaile=
d
>
>   description of an attempt on kernel 3.4 is at [2] and (somewhat less
>
>   detailed) with 3.6 is at [3]. I'm motivated to make it work, any ideas
>
>   what can be done to fix this issue? Please tell me if you need any
>
>   additional info.
>
>
>   I've added xen-devel and Pasi K=E4rkk=E4inen into Cc, hope this is ok.
>
>
> I think Konrad has the pvusb drivers in his git tree..
>
> Konrad's repo seems to contain the same patch [1] as published by
>
> Nathanael. It does not work for me. I've put Konrad in Cc, hope he can
>
> comment...
>
>
> So how does it not work?
>
>
> Here is my original question, please tell me what additional info you nee=
d.
>

Have I failed to provide enough information, or there is some gross mistake
in my setup?

Could you please describe a setup for pvusb which linux 3.4 kernel and xen
4.1 having good chance to work?


> -----------
> *pvusb with kernel 3.4 / 3.6*
> ------------------------------
> Hi Nathanael,
>
> Is it possible to use your patch [1] on newer kernels? I've tried to use
> it
> but most devices are not usable and some cause kernel crash. Detailed
> description of an attempt on kernel 3.4 is at [2] and (somewhat less
> detailed) with 3.6 is at [3]. I'm motivated to make it work, any ideas
> what
> can be done to fix this issue? Please tell me if you need any additional
> info.
>
> I've added xen-devel and Pasi K=E4rkk=E4inen into Cc, hope this is ok.
>
> Regards,
> Alex
>
> [1] http://lists.xen.org/archives/html/xen-devel/2012-02/msg00571.html
> [2] https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/3IAf7f8lz2UJ
> [3] https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/rNmVAOXX4dYJ
> ------------
>
>
> [1]
>
>
> http://git.kernel.org/?p=3Dlinux/kernel/git/konrad/xen.git;a=3Dpatch;h=3D=
10b675fc21702ff5a9b94fc13e2b504ca09073fd
>
>
> Regards,
>
> Alex
>
>
>
>
> -- Pasi
>
>
>
>   Regards,
>
>   Alex
>
>
>   [1] [1]
> http://lists.xen.org/archives/html/xen-devel/2012-02/msg00571.html
>
>   [2]
>
>   [2]https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/3IAf7f8lz2UJ
>
>   [3]
>
>   [3]https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/rNmVAOXX4dYJ
>
>
> References
>
>
>   Visible links
>
>   1. http://lists.xen.org/archives/html/xen-devel/2012-02/msg00571.html
>
>   2. https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/3IAf7f8lz2UJ
>
>   3. https://groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/rNmVAOXX4dYJ
>
>

--14dae9cdc84fdbb77f04cc787781
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On Wed, Oct 17, 2012 at 6:08 PM, Alexand=
re Bezroutchko <abb@gremwell.com> wrote:


On 17=
 Oct 2012, at 17:41, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
=



On Wed, Oct 17, 2012 at 03:5=
0:25PM +0200, Alexandre Bezroutchko wrote:
On 10/17/2012 03:39 PM, Alexandre Bezroutchko wrote:


Thanks for the hi=
nt, found it, here it is:



http://wiki.xen.org/wiki/Xen_Dev=
elopment_Projects#Upstreaming_Xen_PVUSB_drivers_to_mainline_Linux_kernel



On 10/17/2012 02:11 PM, Pasi K=E4rkk=E4inen wr=
ote:


On Wed, Oct 17, 2012 at 01:21:53PM +0200=
, Alexandre Bezroutchko wrote:


 =A0=A0Hi Nathanael,



=
 =A0=A0Is it possible to use your patch [1] on newer kernels? I'v=
e tried to use


 =A0=A0it but most devices are not usable and some cause kernel=
 crash. Detailed


 =A0=A0description of an attempt on kernel 3.4 is at [2] and (s=
omewhat less


 =A0=A0detailed) with 3.6 is at [3]. I'm motivated to make =
it work, any ideas


 =A0=A0what can be done to fix this issue? Please tell me if yo=
u need any


 =A0=A0additional info.





 =A0=A0I've a=
dded xen-devel and Pasi K=E4rkk=E4inen into Cc, hope this is ok.
=




I think Konrad has t=
he pvusb drivers in his git tree..


Konr=
ad's repo seems to contain the same patch [1] as published by
Nathanael. It does not work f=
or me. I've put Konrad in Cc, hope he can


comment...

So how does it not work?




-----------
------------


[1]
http://git.kernel.org/?p=3Dlinux/kernel/git/konrad/xen.git;a=3Dpatch;=
h=3D10b675fc21702ff5a9b94fc13e2b504ca09073fd



Regards,
Alex




=



-- Pasi






 =A0=A0Regards,
<=
/blockquote>


 =A0=A0Alex
=



 =
=A0=A0[1] [1]http://lists.xen.org/archives/html/xen-d=
evel/2012-02/msg00571.html


 =A0=A0[2]


 =A0=A0[2]https:=
//groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/3IAf7f8lz2UJ

 =A0=A0[3]


 =A0=A0[3]https:=
//groups.google.com/d/msg/qubes-devel/4AKulABh2Jc/rNmVAOXX4dYJ


=



References



 =A0=A0Visible links=



 =A0=A01. http://lists.xen.org/archives/h=
tml/xen-devel/2012-02/msg00571.html


 =A0=A02. https://groups.google.com/d/m=
sg/qubes-devel/4AKulABh2Jc/3IAf7f8lz2UJ


 =A0=A03. https://groups.google.com/d/m=
sg/qubes-devel/4AKulABh2Jc/rNmVAOXX4dYJ





--14dae9cdc84fdbb77f04cc787781--


--===============6656472780114535475==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6656472780114535475==--


From xen-devel-bounces@lists.xen.org Sat Oct 20 08:48:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Oct 2012 08:48:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPUiZ-0001zh-2X; Sat, 20 Oct 2012 08:47:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPUiX-0001zc-0R
	for xen-devel@lists.xensource.com; Sat, 20 Oct 2012 08:47:37 +0000
Received: from [193.109.254.147:9162] by server-2.bemta-14.messagelabs.com id
	DF/7B-19917-82562805; Sat, 20 Oct 2012 08:47:36 +0000
X-Env-Sender: blauwirbel@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1350722850!13402384!1
X-Originating-IP: [209.85.223.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12701 invoked from network); 20 Oct 2012 08:47:31 -0000
Received: from mail-ie0-f171.google.com (HELO mail-ie0-f171.google.com)
	(209.85.223.171)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Oct 2012 08:47:31 -0000
Received: by mail-ie0-f171.google.com with SMTP id s9so2196200iec.30
	for ;
	Sat, 20 Oct 2012 01:47:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=e4XP3n8O0fPdB/JH2w/ruqiUDC5Hj4T7uOCTF5mi9rI=;
	b=ysbIdPk228vLs/F0iI1lPgYWV/VbWpSoyuaE1XcL5g8GhbRNQVVofxHKbFG807uVn6
	t9HFEjqHoBssNrUko8F0dLlTvwSzG5pfgCeSYWCCbxmPcSWoub1abACRTgdQlJ9ORMdY
	hQzXLrgYCRgJgn7LU2QFS4FG1sYnqCFtww/u6ZzOG6FWSbKhEKeZ+xW12CSKtxzd6t9M
	izyqUqWx92vuFJe+Pgl3cA2upmdWLb4ml24UwZClzwnK1juy5wn1qmVqyinugK4gxO1J
	SmwfkSVWIJed9kCCygtP5BAjz+J0THpctgnkK/d5SjQkh/7AenJjSdX4JRs//hCFdV9V
	KPqA==
Received: by 10.42.101.11 with SMTP id c11mr3220730ico.52.1350722850144; Sat,
	20 Oct 2012 01:47:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.53.130 with HTTP; Sat, 20 Oct 2012 01:47:09 -0700 (PDT)
In-Reply-To: <1350332522-26635-1-git-send-email-ehabkost@redhat.com>
References: <1350332522-26635-1-git-send-email-ehabkost@redhat.com>
From: Blue Swirl 
Date: Sat, 20 Oct 2012 08:47:09 +0000
Message-ID: 
To: Eduardo Habkost 
Cc: Peter Maydell ,
	Evgeny Voevodin , qemu-devel@nongnu.org,
	Peter Crosthwaite ,
	Max Filippov ,
	"Edgar E. Iglesias" ,
	Guan Xuetao , xen-devel@lists.xensource.com,
	Igor Mitsyanko ,
	Magnus Damm , Alexander Graf ,
	=?UTF-8?Q?Herv=C3=A9_Poussineau?= ,
	Maksim Kozlov ,
	Andrzej Zaborowski ,
	Fabien Chouteau , Jan Kiszka ,
	Paul Brook , Anthony Liguori ,
	Michael Walle , qemu-ppc@nongnu.org,
	Dmitry Solodkiy ,
	Aurelien Jarno 
Subject: Re: [Xen-devel] [QEMU PATCH v4] create struct for machine
	initialization arguments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thanks, applied.

On Mon, Oct 15, 2012 at 8:22 PM, Eduardo Habkost  wrote:
> This should help us to:
> - More easily add or remove machine initialization arguments without
>   having to change every single machine init function;
> - More easily make mechanical changes involving the machine init
>   functions in the future;
> - Let machine initialization forward the init arguments to other
>   functions more easily.
>
> This change was half-mechanical process: first the struct was added with
> the local ram_size, boot_device, kernel_*, initrd_*, and cpu_model local
> variable initialization to all functions. Then the compiler helped me
> locate the local variables that are unused, so they could be removed.
>
> ---
>
> Changes v3 -> v4:
>  - Rebase against latest qemu.git master, solved conflicts at
>    hw/xilinx_zynq.c
>
> Changes v2 -> v3:
>  - Fix typo (missing dot) on main()
>  - Fix another mistake on xen_init_pv()
>
> Changes v1 -> v2:
>  - Fix mistake on the conversion of pc_xen_hvm_init() and xen_init_pv()
>
>
>  hw/alpha_dp264.c              |  12 ++--
>  hw/an5206.c                   |   8 +--
>  hw/axis_dev88.c               |   9 +--
>  hw/boards.h                   |  16 +++--
>  hw/collie.c                   |   9 +--
>  hw/dummy_m68k.c               |   8 +--
>  hw/exynos4_boards.c           |  16 ++---
>  hw/gumstix.c                  |  11 +---
>  hw/highbank.c                 |  10 ++--
>  hw/integratorcp.c             |  10 ++--
>  hw/kzm.c                      |  10 ++--
>  hw/leon3.c                    |  10 ++--
>  hw/lm32_boards.c              |  18 +++---
>  hw/mainstone.c                |  10 ++--
>  hw/mcf5208.c                  |   8 +--
>  hw/milkymist.c                |  10 ++--
>  hw/mips_fulong2e.c            |   9 ++-
>  hw/mips_jazz.c                |  14 ++---
>  hw/mips_malta.c               |  10 ++--
>  hw/mips_mipssim.c             |  10 ++--
>  hw/mips_r4k.c                 |  10 ++--
>  hw/musicpal.c                 |   9 +--
>  hw/nseries.c                  |  22 ++++---
>  hw/null-machine.c             |   7 +--
>  hw/omap_sx1.c                 |  22 ++++---
>  hw/openrisc_sim.c             |  10 ++--
>  hw/palm.c                     |   9 +--
>  hw/pc_piix.c                  |  50 ++++++++--------
>  hw/petalogix_ml605_mmu.c      |   8 +--
>  hw/petalogix_s3adsp1800_mmu.c |   8 +--
>  hw/ppc/e500plat.c             |  13 +++--
>  hw/ppc/mpc8544ds.c            |  13 +++--
>  hw/ppc405_boards.c            |  25 ++++----
>  hw/ppc440_bamboo.c            |  12 ++--
>  hw/ppc_newworld.c             |  13 +++--
>  hw/ppc_oldworld.c             |  13 +++--
>  hw/ppc_prep.c                 |  13 +++--
>  hw/puv3.c                     |   8 ++-
>  hw/r2d.c                      |   9 +--
>  hw/realview.c                 |  44 +++++++++-----
>  hw/s390-virtio.c              |  13 +++--
>  hw/shix.c                     |   6 +-
>  hw/spapr.c                    |  13 +++--
>  hw/spitz.c                    |  40 ++++++++-----
>  hw/stellaris.c                |  14 ++---
>  hw/sun4m.c                    | 133 ++++++++++++++++++++++++++----------------
>  hw/sun4u.c                    |  39 ++++++++-----
>  hw/tosa.c                     |   9 +--
>  hw/versatilepb.c              |  22 ++++---
>  hw/vexpress.c                 |  26 +++++----
>  hw/virtex_ml507.c             |  10 ++--
>  hw/xen_machine_pv.c           |  11 ++--
>  hw/xilinx_zynq.c              |   9 ++-
>  hw/xtensa_lx60.c              |  22 ++++---
>  hw/xtensa_sim.c               |  11 ++--
>  hw/z2.c                       |   9 +--
>  vl.c                          |   9 ++-
>  57 files changed, 518 insertions(+), 414 deletions(-)
>
> diff --git a/hw/alpha_dp264.c b/hw/alpha_dp264.c
> index 5ea04c7..8f082a6 100644
> --- a/hw/alpha_dp264.c
> +++ b/hw/alpha_dp264.c
> @@ -42,13 +42,13 @@ static int clipper_pci_map_irq(PCIDevice *d, int irq_num)
>      return (slot + 1) * 4 + irq_num;
>  }
>
> -static void clipper_init(ram_addr_t ram_size,
> -                         const char *boot_device,
> -                         const char *kernel_filename,
> -                         const char *kernel_cmdline,
> -                         const char *initrd_filename,
> -                         const char *cpu_model)
> +static void clipper_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      CPUAlphaState *cpus[4];
>      PCIBus *pci_bus;
>      ISABus *isa_bus;
> diff --git a/hw/an5206.c b/hw/an5206.c
> index 25407c0..042c5fc 100644
> --- a/hw/an5206.c
> +++ b/hw/an5206.c
> @@ -19,11 +19,11 @@
>
>  /* Board init.  */
>
> -static void an5206_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void an5206_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
>      CPUM68KState *env;
>      int kernel_size;
>      uint64_t elf_entry;
> diff --git a/hw/axis_dev88.c b/hw/axis_dev88.c
> index eab6327..2fd7356 100644
> --- a/hw/axis_dev88.c
> +++ b/hw/axis_dev88.c
> @@ -242,11 +242,12 @@ static const MemoryRegionOps gpio_ops = {
>  static struct cris_load_info li;
>
>  static
> -void axisdev88_init (ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +void axisdev88_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
>      CRISCPU *cpu;
>      CPUCRISState *env;
>      DeviceState *dev;
> diff --git a/hw/boards.h b/hw/boards.h
> index a2e0a54..813d0e5 100644
> --- a/hw/boards.h
> +++ b/hw/boards.h
> @@ -5,12 +5,16 @@
>
>  #include "qdev.h"
>
> -typedef void QEMUMachineInitFunc(ram_addr_t ram_size,
> -                                 const char *boot_device,
> -                                 const char *kernel_filename,
> -                                 const char *kernel_cmdline,
> -                                 const char *initrd_filename,
> -                                 const char *cpu_model);
> +typedef struct QEMUMachineInitArgs {
> +    ram_addr_t ram_size;
> +    const char *boot_device;
> +    const char *kernel_filename;
> +    const char *kernel_cmdline;
> +    const char *initrd_filename;
> +    const char *cpu_model;
> +} QEMUMachineInitArgs;
> +
> +typedef void QEMUMachineInitFunc(QEMUMachineInitArgs *args);
>
>  typedef void QEMUMachineResetFunc(void);
>
> diff --git a/hw/collie.c b/hw/collie.c
> index 56f89a9..695982a 100644
> --- a/hw/collie.c
> +++ b/hw/collie.c
> @@ -23,11 +23,12 @@ static struct arm_boot_info collie_binfo = {
>      .ram_size = 0x20000000,
>  };
>
> -static void collie_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void collie_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      StrongARMState *s;
>      DriveInfo *dinfo;
>      MemoryRegion *sysmem = get_system_memory();
> diff --git a/hw/dummy_m68k.c b/hw/dummy_m68k.c
> index 7cc7a99..f436a0c 100644
> --- a/hw/dummy_m68k.c
> +++ b/hw/dummy_m68k.c
> @@ -16,11 +16,11 @@
>
>  /* Board init.  */
>
> -static void dummy_m68k_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void dummy_m68k_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
>      CPUM68KState *env;
>      MemoryRegion *address_space_mem =  get_system_memory();
>      MemoryRegion *ram = g_new(MemoryRegion, 1);
> diff --git a/hw/exynos4_boards.c b/hw/exynos4_boards.c
> index 4bb0a60..4951064 100644
> --- a/hw/exynos4_boards.c
> +++ b/hw/exynos4_boards.c
> @@ -130,22 +130,22 @@ static Exynos4210State *exynos4_boards_init_common(
>              exynos4_board_ram_size[board_type]);
>  }
>
> -static void nuri_init(ram_addr_t ram_size,
> -        const char *boot_device,
> -        const char *kernel_filename, const char *kernel_cmdline,
> -        const char *initrd_filename, const char *cpu_model)
> +static void nuri_init(QEMUMachineInitArgs *args)
>  {
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      exynos4_boards_init_common(kernel_filename, kernel_cmdline,
>                  initrd_filename, EXYNOS4_BOARD_NURI);
>
>      arm_load_kernel(arm_env_get_cpu(first_cpu), &exynos4_board_binfo);
>  }
>
> -static void smdkc210_init(ram_addr_t ram_size,
> -        const char *boot_device,
> -        const char *kernel_filename, const char *kernel_cmdline,
> -        const char *initrd_filename, const char *cpu_model)
> +static void smdkc210_init(QEMUMachineInitArgs *args)
>  {
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      Exynos4210State *s = exynos4_boards_init_common(kernel_filename,
>              kernel_cmdline, initrd_filename, EXYNOS4_BOARD_SMDKC210);
>
> diff --git a/hw/gumstix.c b/hw/gumstix.c
> index 13a36ea..4103a88 100644
> --- a/hw/gumstix.c
> +++ b/hw/gumstix.c
> @@ -45,10 +45,7 @@
>
>  static const int sector_len = 128 * 1024;
>
> -static void connex_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void connex_init(QEMUMachineInitArgs *args)
>  {
>      PXA2xxState *cpu;
>      DriveInfo *dinfo;
> @@ -84,11 +81,9 @@ static void connex_init(ram_addr_t ram_size,
>                      qdev_get_gpio_in(cpu->gpio, 36));
>  }
>
> -static void verdex_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void verdex_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
>      PXA2xxState *cpu;
>      DriveInfo *dinfo;
>      int be;
> diff --git a/hw/highbank.c b/hw/highbank.c
> index 11aa131..15036b6 100644
> --- a/hw/highbank.c
> +++ b/hw/highbank.c
> @@ -187,11 +187,13 @@ static struct arm_boot_info highbank_binfo;
>   * 32-bit host, set the reg value of memory to 0xf7ff00000 in the
>   * device tree and pass -m 2047 to QEMU.
>   */
> -static void highbank_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void highbank_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      DeviceState *dev;
>      SysBusDevice *busdev;
>      qemu_irq *irqp;
> diff --git a/hw/integratorcp.c b/hw/integratorcp.c
> index d0e2e90..ac0ea83 100644
> --- a/hw/integratorcp.c
> +++ b/hw/integratorcp.c
> @@ -438,11 +438,13 @@ static struct arm_boot_info integrator_binfo = {
>      .board_id = 0x113,
>  };
>
> -static void integratorcp_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void integratorcp_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      ARMCPU *cpu;
>      MemoryRegion *address_space_mem = get_system_memory();
>      MemoryRegion *ram = g_new(MemoryRegion, 1);
> diff --git a/hw/kzm.c b/hw/kzm.c
> index 68cd1b4..d1266d9 100644
> --- a/hw/kzm.c
> +++ b/hw/kzm.c
> @@ -70,11 +70,13 @@ static struct arm_boot_info kzm_binfo = {
>      .board_id = 1722,
>  };
>
> -static void kzm_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void kzm_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      ARMCPU *cpu;
>      MemoryRegion *address_space_mem = get_system_memory();
>      MemoryRegion *ram = g_new(MemoryRegion, 1);
> diff --git a/hw/leon3.c b/hw/leon3.c
> index 7a9729d..7742738 100644
> --- a/hw/leon3.c
> +++ b/hw/leon3.c
> @@ -94,13 +94,11 @@ static void leon3_set_pil_in(void *opaque, uint32_t pil_in)
>      }
>  }
>
> -static void leon3_generic_hw_init(ram_addr_t  ram_size,
> -                                  const char *boot_device,
> -                                  const char *kernel_filename,
> -                                  const char *kernel_cmdline,
> -                                  const char *initrd_filename,
> -                                  const char *cpu_model)
> +static void leon3_generic_hw_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
>      SPARCCPU *cpu;
>      CPUSPARCState   *env;
>      MemoryRegion *address_space_mem = get_system_memory();
> diff --git a/hw/lm32_boards.c b/hw/lm32_boards.c
> index b76d800..c5a62c8 100644
> --- a/hw/lm32_boards.c
> +++ b/hw/lm32_boards.c
> @@ -69,12 +69,10 @@ static void main_cpu_reset(void *opaque)
>      env->deba = reset_info->flash_base;
>  }
>
> -static void lm32_evr_init(ram_addr_t ram_size_not_used,
> -                          const char *boot_device,
> -                          const char *kernel_filename,
> -                          const char *kernel_cmdline,
> -                          const char *initrd_filename, const char *cpu_model)
> +static void lm32_evr_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
>      LM32CPU *cpu;
>      CPULM32State *env;
>      DriveInfo *dinfo;
> @@ -159,12 +157,12 @@ static void lm32_evr_init(ram_addr_t ram_size_not_used,
>      qemu_register_reset(main_cpu_reset, reset_info);
>  }
>
> -static void lm32_uclinux_init(ram_addr_t ram_size_not_used,
> -                          const char *boot_device,
> -                          const char *kernel_filename,
> -                          const char *kernel_cmdline,
> -                          const char *initrd_filename, const char *cpu_model)
> +static void lm32_uclinux_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      LM32CPU *cpu;
>      CPULM32State *env;
>      DriveInfo *dinfo;
> diff --git a/hw/mainstone.c b/hw/mainstone.c
> index 97687b6..c0d6034 100644
> --- a/hw/mainstone.c
> +++ b/hw/mainstone.c
> @@ -171,11 +171,13 @@ static void mainstone_common_init(MemoryRegion *address_space_mem,
>      arm_load_kernel(mpu->cpu, &mainstone_binfo);
>  }
>
> -static void mainstone_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void mainstone_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      mainstone_common_init(get_system_memory(), ram_size, kernel_filename,
>                  kernel_cmdline, initrd_filename, cpu_model, mainstone, 0x196);
>  }
> diff --git a/hw/mcf5208.c b/hw/mcf5208.c
> index ee25b1b..688bc3c 100644
> --- a/hw/mcf5208.c
> +++ b/hw/mcf5208.c
> @@ -187,11 +187,11 @@ static void mcf5208_sys_init(MemoryRegion *address_space, qemu_irq *pic)
>      }
>  }
>
> -static void mcf5208evb_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void mcf5208evb_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
>      CPUM68KState *env;
>      int kernel_size;
>      uint64_t elf_entry;
> diff --git a/hw/milkymist.c b/hw/milkymist.c
> index 2e7235b..ca9ed43 100644
> --- a/hw/milkymist.c
> +++ b/hw/milkymist.c
> @@ -73,12 +73,12 @@ static void main_cpu_reset(void *opaque)
>  }
>
>  static void
> -milkymist_init(ram_addr_t ram_size_not_used,
> -                          const char *boot_device,
> -                          const char *kernel_filename,
> -                          const char *kernel_cmdline,
> -                          const char *initrd_filename, const char *cpu_model)
> +milkymist_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      LM32CPU *cpu;
>      CPULM32State *env;
>      int kernel_size;
> diff --git a/hw/mips_fulong2e.c b/hw/mips_fulong2e.c
> index d4a8672..fb50a1f 100644
> --- a/hw/mips_fulong2e.c
> +++ b/hw/mips_fulong2e.c
> @@ -256,10 +256,13 @@ static void cpu_request_exit(void *opaque, int irq, int level)
>      }
>  }
>
> -static void mips_fulong2e_init(ram_addr_t ram_size, const char *boot_device,
> -                        const char *kernel_filename, const char *kernel_cmdline,
> -                        const char *initrd_filename, const char *cpu_model)
> +static void mips_fulong2e_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      char *filename;
>      MemoryRegion *address_space_mem = get_system_memory();
>      MemoryRegion *ram = g_new(MemoryRegion, 1);
> diff --git a/hw/mips_jazz.c b/hw/mips_jazz.c
> index db927f1..14df4d7 100644
> --- a/hw/mips_jazz.c
> +++ b/hw/mips_jazz.c
> @@ -302,21 +302,19 @@ static void mips_jazz_init(MemoryRegion *address_space,
>  }
>
>  static
> -void mips_magnum_init (ram_addr_t ram_size,
> -                       const char *boot_device,
> -                       const char *kernel_filename, const char *kernel_cmdline,
> -                       const char *initrd_filename, const char *cpu_model)
> +void mips_magnum_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
>          mips_jazz_init(get_system_memory(), get_system_io(),
>                         ram_size, cpu_model, JAZZ_MAGNUM);
>  }
>
>  static
> -void mips_pica61_init (ram_addr_t ram_size,
> -                       const char *boot_device,
> -                       const char *kernel_filename, const char *kernel_cmdline,
> -                       const char *initrd_filename, const char *cpu_model)
> +void mips_pica61_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
>      mips_jazz_init(get_system_memory(), get_system_io(),
>                     ram_size, cpu_model, JAZZ_PICA61);
>  }
> diff --git a/hw/mips_malta.c b/hw/mips_malta.c
> index 632b466..ad4910f 100644
> --- a/hw/mips_malta.c
> +++ b/hw/mips_malta.c
> @@ -775,11 +775,13 @@ static void cpu_request_exit(void *opaque, int irq, int level)
>  }
>
>  static
> -void mips_malta_init (ram_addr_t ram_size,
> -                      const char *boot_device,
> -                      const char *kernel_filename, const char *kernel_cmdline,
> -                      const char *initrd_filename, const char *cpu_model)
> +void mips_malta_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      char *filename;
>      pflash_t *fl;
>      MemoryRegion *system_memory = get_system_memory();
> diff --git a/hw/mips_mipssim.c b/hw/mips_mipssim.c
> index 830f635..a1d3945 100644
> --- a/hw/mips_mipssim.c
> +++ b/hw/mips_mipssim.c
> @@ -131,11 +131,13 @@ static void mipsnet_init(int base, qemu_irq irq, NICInfo *nd)
>  }
>
>  static void
> -mips_mipssim_init (ram_addr_t ram_size,
> -                   const char *boot_device,
> -                   const char *kernel_filename, const char *kernel_cmdline,
> -                   const char *initrd_filename, const char *cpu_model)
> +mips_mipssim_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      char *filename;
>      MemoryRegion *address_space_mem = get_system_memory();
>      MemoryRegion *ram = g_new(MemoryRegion, 1);
> diff --git a/hw/mips_r4k.c b/hw/mips_r4k.c
> index 967a76e..b73cdc3 100644
> --- a/hw/mips_r4k.c
> +++ b/hw/mips_r4k.c
> @@ -151,11 +151,13 @@ static void main_cpu_reset(void *opaque)
>
>  static const int sector_len = 32 * 1024;
>  static
> -void mips_r4k_init (ram_addr_t ram_size,
> -                    const char *boot_device,
> -                    const char *kernel_filename, const char *kernel_cmdline,
> -                    const char *initrd_filename, const char *cpu_model)
> +void mips_r4k_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      char *filename;
>      MemoryRegion *address_space_mem = get_system_memory();
>      MemoryRegion *ram = g_new(MemoryRegion, 1);
> diff --git a/hw/musicpal.c b/hw/musicpal.c
> index f305e21..f06814c 100644
> --- a/hw/musicpal.c
> +++ b/hw/musicpal.c
> @@ -1508,11 +1508,12 @@ static struct arm_boot_info musicpal_binfo = {
>      .board_id = 0x20e,
>  };
>
> -static void musicpal_init(ram_addr_t ram_size,
> -               const char *boot_device,
> -               const char *kernel_filename, const char *kernel_cmdline,
> -               const char *initrd_filename, const char *cpu_model)
> +static void musicpal_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      ARMCPU *cpu;
>      qemu_irq *cpu_pic;
>      qemu_irq pic[32];
> diff --git a/hw/nseries.c b/hw/nseries.c
> index 6df71eb..7ada90d 100644
> --- a/hw/nseries.c
> +++ b/hw/nseries.c
> @@ -1397,21 +1397,27 @@ static struct arm_boot_info n810_binfo = {
>      .atag_board = n810_atag_setup,
>  };
>
> -static void n800_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void n800_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      return n8x0_init(ram_size, boot_device,
>                      kernel_filename, kernel_cmdline, initrd_filename,
>                      cpu_model, &n800_binfo, 800);
>  }
>
> -static void n810_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void n810_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      return n8x0_init(ram_size, boot_device,
>                      kernel_filename, kernel_cmdline, initrd_filename,
>                      cpu_model, &n810_binfo, 810);
> diff --git a/hw/null-machine.c b/hw/null-machine.c
> index 69910d3..d813c08 100644
> --- a/hw/null-machine.c
> +++ b/hw/null-machine.c
> @@ -15,12 +15,7 @@
>  #include "hw/hw.h"
>  #include "hw/boards.h"
>
> -static void machine_none_init(ram_addr_t ram_size,
> -                              const char *boot_device,
> -                              const char *kernel_filename,
> -                              const char *kernel_cmdline,
> -                              const char *initrd_filename,
> -                              const char *cpu_model)
> +static void machine_none_init(QEMUMachineInitArgs *args)
>  {
>  }
>
> diff --git a/hw/omap_sx1.c b/hw/omap_sx1.c
> index abca341..ad17487 100644
> --- a/hw/omap_sx1.c
> +++ b/hw/omap_sx1.c
> @@ -209,20 +209,26 @@ static void sx1_init(ram_addr_t ram_size,
>      //~ qemu_console_resize(ds, 640, 480);
>  }
>
> -static void sx1_init_v1(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void sx1_init_v1(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sx1_init(ram_size, boot_device, kernel_filename,
>                  kernel_cmdline, initrd_filename, cpu_model, 1);
>  }
>
> -static void sx1_init_v2(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void sx1_init_v2(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sx1_init(ram_size, boot_device, kernel_filename,
>                  kernel_cmdline, initrd_filename, cpu_model, 2);
>  }
> diff --git a/hw/openrisc_sim.c b/hw/openrisc_sim.c
> index 55e97f0..e96a944 100644
> --- a/hw/openrisc_sim.c
> +++ b/hw/openrisc_sim.c
> @@ -90,13 +90,11 @@ static void cpu_openrisc_load_kernel(ram_addr_t ram_size,
>      cpu->env.pc = entry;
>  }
>
> -static void openrisc_sim_init(ram_addr_t ram_size,
> -                              const char *boot_device,
> -                              const char *kernel_filename,
> -                              const char *kernel_cmdline,
> -                              const char *initrd_filename,
> -                              const char *cpu_model)
> +static void openrisc_sim_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
>     OpenRISCCPU *cpu = NULL;
>      MemoryRegion *ram;
>      int n;
> diff --git a/hw/palm.c b/hw/palm.c
> index bacdc90..032b8d6 100644
> --- a/hw/palm.c
> +++ b/hw/palm.c
> @@ -190,11 +190,12 @@ static struct arm_boot_info palmte_binfo = {
>      .board_id = 0x331,
>  };
>
> -static void palmte_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void palmte_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      MemoryRegion *address_space_mem = get_system_memory();
>      struct omap_mpu_state_s *mpu;
>      int flash_size = 0x00800000;
> diff --git a/hw/pc_piix.c b/hw/pc_piix.c
> index 82364ab..36e165f 100644
> --- a/hw/pc_piix.c
> +++ b/hw/pc_piix.c
> @@ -287,13 +287,14 @@ static void pc_init1(MemoryRegion *system_memory,
>      }
>  }
>
> -static void pc_init_pci(ram_addr_t ram_size,
> -                        const char *boot_device,
> -                        const char *kernel_filename,
> -                        const char *kernel_cmdline,
> -                        const char *initrd_filename,
> -                        const char *cpu_model)
> +static void pc_init_pci(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      pc_init1(get_system_memory(),
>               get_system_io(),
>               ram_size, boot_device,
> @@ -301,13 +302,14 @@ static void pc_init_pci(ram_addr_t ram_size,
>               initrd_filename, cpu_model, 1, 1);
>  }
>
> -static void pc_init_pci_no_kvmclock(ram_addr_t ram_size,
> -                                    const char *boot_device,
> -                                    const char *kernel_filename,
> -                                    const char *kernel_cmdline,
> -                                    const char *initrd_filename,
> -                                    const char *cpu_model)
> +static void pc_init_pci_no_kvmclock(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      pc_init1(get_system_memory(),
>               get_system_io(),
>               ram_size, boot_device,
> @@ -315,13 +317,14 @@ static void pc_init_pci_no_kvmclock(ram_addr_t ram_size,
>               initrd_filename, cpu_model, 1, 0);
>  }
>
> -static void pc_init_isa(ram_addr_t ram_size,
> -                        const char *boot_device,
> -                        const char *kernel_filename,
> -                        const char *kernel_cmdline,
> -                        const char *initrd_filename,
> -                        const char *cpu_model)
> +static void pc_init_isa(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      if (cpu_model == NULL)
>          cpu_model = "486";
>      pc_init1(get_system_memory(),
> @@ -332,19 +335,12 @@ static void pc_init_isa(ram_addr_t ram_size,
>  }
>
>  #ifdef CONFIG_XEN
> -static void pc_xen_hvm_init(ram_addr_t ram_size,
> -                            const char *boot_device,
> -                            const char *kernel_filename,
> -                            const char *kernel_cmdline,
> -                            const char *initrd_filename,
> -                            const char *cpu_model)
> +static void pc_xen_hvm_init(QEMUMachineInitArgs *args)
>  {
>      if (xen_hvm_init() != 0) {
>          hw_error("xen hardware virtual machine initialisation failed");
>      }
> -    pc_init_pci_no_kvmclock(ram_size, boot_device,
> -                            kernel_filename, kernel_cmdline,
> -                            initrd_filename, cpu_model);
> +    pc_init_pci_no_kvmclock(args);
>      xen_vcpu_init();
>  }
>  #endif
> diff --git a/hw/petalogix_ml605_mmu.c b/hw/petalogix_ml605_mmu.c
> index b9bfbed..39df251 100644
> --- a/hw/petalogix_ml605_mmu.c
> +++ b/hw/petalogix_ml605_mmu.c
> @@ -73,12 +73,10 @@ static void machine_cpu_reset(MicroBlazeCPU *cpu)
>  }
>
>  static void
> -petalogix_ml605_init(ram_addr_t ram_size,
> -                          const char *boot_device,
> -                          const char *kernel_filename,
> -                          const char *kernel_cmdline,
> -                          const char *initrd_filename, const char *cpu_model)
> +petalogix_ml605_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
>      MemoryRegion *address_space_mem = get_system_memory();
>      DeviceState *dev, *dma, *eth0;
>      MicroBlazeCPU *cpu;
> diff --git a/hw/petalogix_s3adsp1800_mmu.c b/hw/petalogix_s3adsp1800_mmu.c
> index 2cf6882..71c32ce 100644
> --- a/hw/petalogix_s3adsp1800_mmu.c
> +++ b/hw/petalogix_s3adsp1800_mmu.c
> @@ -57,12 +57,10 @@ static void machine_cpu_reset(MicroBlazeCPU *cpu)
>  }
>
>  static void
> -petalogix_s3adsp1800_init(ram_addr_t ram_size,
> -                          const char *boot_device,
> -                          const char *kernel_filename,
> -                          const char *kernel_cmdline,
> -                          const char *initrd_filename, const char *cpu_model)
> +petalogix_s3adsp1800_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
>      DeviceState *dev;
>      MicroBlazeCPU *cpu;
>      CPUMBState *env;
> diff --git a/hw/ppc/e500plat.c b/hw/ppc/e500plat.c
> index 60a5cb3..4cfb940 100644
> --- a/hw/ppc/e500plat.c
> +++ b/hw/ppc/e500plat.c
> @@ -25,13 +25,14 @@ static void e500plat_fixup_devtree(PPCE500Params *params, void *fdt)
>                           sizeof(compatible));
>  }
>
> -static void e500plat_init(ram_addr_t ram_size,
> -                           const char *boot_device,
> -                           const char *kernel_filename,
> -                           const char *kernel_cmdline,
> -                           const char *initrd_filename,
> -                           const char *cpu_model)
> +static void e500plat_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *boot_device = args->boot_device;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      PPCE500Params params = {
>          .ram_size = ram_size,
>          .boot_device = boot_device,
> diff --git a/hw/ppc/mpc8544ds.c b/hw/ppc/mpc8544ds.c
> index 984d21c..e651661 100644
> --- a/hw/ppc/mpc8544ds.c
> +++ b/hw/ppc/mpc8544ds.c
> @@ -25,13 +25,14 @@ static void mpc8544ds_fixup_devtree(PPCE500Params *params, void *fdt)
>                           sizeof(compatible));
>  }
>
> -static void mpc8544ds_init(ram_addr_t ram_size,
> -                           const char *boot_device,
> -                           const char *kernel_filename,
> -                           const char *kernel_cmdline,
> -                           const char *initrd_filename,
> -                           const char *cpu_model)
> +static void mpc8544ds_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *boot_device = args->boot_device;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      PPCE500Params params = {
>          .ram_size = ram_size,
>          .boot_device = boot_device,
> diff --git a/hw/ppc405_boards.c b/hw/ppc405_boards.c
> index 476775d..e848cb0 100644
> --- a/hw/ppc405_boards.c
> +++ b/hw/ppc405_boards.c
> @@ -158,7 +158,7 @@ static void ref405ep_fpga_reset (void *opaque)
>      fpga->reg1 = 0x0F;
>  }
>
> -static void ref405ep_fpga_init (MemoryRegion *sysmem, uint32_t base)
> +static void ref405ep_fpga_init(MemoryRegion *sysmem, uint32_t base)
>  {
>      ref405ep_fpga_t *fpga;
>      MemoryRegion *fpga_memory = g_new(MemoryRegion, 1);
> @@ -170,13 +170,12 @@ static void ref405ep_fpga_init (MemoryRegion *sysmem, uint32_t base)
>      qemu_register_reset(&ref405ep_fpga_reset, fpga);
>  }
>
> -static void ref405ep_init (ram_addr_t ram_size,
> -                           const char *boot_device,
> -                           const char *kernel_filename,
> -                           const char *kernel_cmdline,
> -                           const char *initrd_filename,
> -                           const char *cpu_model)
> +static void ref405ep_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      char *filename;
>      ppc4xx_bd_info_t bd;
>      CPUPPCState *env;
> @@ -484,7 +483,7 @@ static void taihu_cpld_reset (void *opaque)
>      cpld->reg1 = 0x80;
>  }
>
> -static void taihu_cpld_init (MemoryRegion *sysmem, uint32_t base)
> +static void taihu_cpld_init(MemoryRegion *sysmem, uint32_t base)
>  {
>      taihu_cpld_t *cpld;
>      MemoryRegion *cpld_memory = g_new(MemoryRegion, 1);
> @@ -495,13 +494,11 @@ static void taihu_cpld_init (MemoryRegion *sysmem, uint32_t base)
>      qemu_register_reset(&taihu_cpld_reset, cpld);
>  }
>
> -static void taihu_405ep_init(ram_addr_t ram_size,
> -                             const char *boot_device,
> -                             const char *kernel_filename,
> -                             const char *kernel_cmdline,
> -                             const char *initrd_filename,
> -                             const char *cpu_model)
> +static void taihu_405ep_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *initrd_filename = args->initrd_filename;
>      char *filename;
>      qemu_irq *pic;
>      MemoryRegion *sysmem = get_system_memory();
> diff --git a/hw/ppc440_bamboo.c b/hw/ppc440_bamboo.c
> index c198071..78e7985 100644
> --- a/hw/ppc440_bamboo.c
> +++ b/hw/ppc440_bamboo.c
> @@ -157,13 +157,13 @@ static void main_cpu_reset(void *opaque)
>      mmubooke_create_initial_mapping(env, 0, 0);
>  }
>
> -static void bamboo_init(ram_addr_t ram_size,
> -                        const char *boot_device,
> -                        const char *kernel_filename,
> -                        const char *kernel_cmdline,
> -                        const char *initrd_filename,
> -                        const char *cpu_model)
> +static void bamboo_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      unsigned int pci_irq_nrs[4] = { 28, 27, 26, 25 };
>      MemoryRegion *address_space_mem = get_system_memory();
>      MemoryRegion *ram_memories
> diff --git a/hw/ppc_newworld.c b/hw/ppc_newworld.c
> index b8d3c9c..a265445 100644
> --- a/hw/ppc_newworld.c
> +++ b/hw/ppc_newworld.c
> @@ -128,13 +128,14 @@ static void ppc_core99_reset(void *opaque)
>  }
>
>  /* PowerPC Mac99 hardware initialisation */
> -static void ppc_core99_init (ram_addr_t ram_size,
> -                             const char *boot_device,
> -                             const char *kernel_filename,
> -                             const char *kernel_cmdline,
> -                             const char *initrd_filename,
> -                             const char *cpu_model)
> +static void ppc_core99_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      PowerPCCPU *cpu = NULL;
>      CPUPPCState *env = NULL;
>      char *filename;
> diff --git a/hw/ppc_oldworld.c b/hw/ppc_oldworld.c
> index 2c4a478..de33408 100644
> --- a/hw/ppc_oldworld.c
> +++ b/hw/ppc_oldworld.c
> @@ -71,13 +71,14 @@ static void ppc_heathrow_reset(void *opaque)
>      cpu_reset(CPU(cpu));
>  }
>
> -static void ppc_heathrow_init (ram_addr_t ram_size,
> -                               const char *boot_device,
> -                               const char *kernel_filename,
> -                               const char *kernel_cmdline,
> -                               const char *initrd_filename,
> -                               const char *cpu_model)
> +static void ppc_heathrow_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      MemoryRegion *sysmem = get_system_memory();
>      PowerPCCPU *cpu = NULL;
>      CPUPPCState *env = NULL;
> diff --git a/hw/ppc_prep.c b/hw/ppc_prep.c
> index 1544430..b426891 100644
> --- a/hw/ppc_prep.c
> +++ b/hw/ppc_prep.c
> @@ -447,13 +447,14 @@ static void ppc_prep_reset(void *opaque)
>  }
>
>  /* PowerPC PREP hardware initialisation */
> -static void ppc_prep_init (ram_addr_t ram_size,
> -                           const char *boot_device,
> -                           const char *kernel_filename,
> -                           const char *kernel_cmdline,
> -                           const char *initrd_filename,
> -                           const char *cpu_model)
> +static void ppc_prep_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      MemoryRegion *sysmem = get_system_memory();
>      PowerPCCPU *cpu = NULL;
>      CPUPPCState *env = NULL;
> diff --git a/hw/puv3.c b/hw/puv3.c
> index 43f7216..764799c 100644
> --- a/hw/puv3.c
> +++ b/hw/puv3.c
> @@ -91,10 +91,12 @@ static void puv3_load_kernel(const char *kernel_filename)
>      graphic_console_init(NULL, NULL, NULL, NULL, NULL);
>  }
>
> -static void puv3_init(ram_addr_t ram_size, const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void puv3_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *initrd_filename = args->initrd_filename;
>      CPUUniCore32State *env;
>
>      if (initrd_filename) {
> diff --git a/hw/r2d.c b/hw/r2d.c
> index 1bc191f..3cb6942 100644
> --- a/hw/r2d.c
> +++ b/hw/r2d.c
> @@ -219,11 +219,12 @@ static struct QEMU_PACKED
>      char kernel_cmdline[256];
>  } boot_params;
>
> -static void r2d_init(ram_addr_t ram_size,
> -              const char *boot_device,
> -             const char *kernel_filename, const char *kernel_cmdline,
> -             const char *initrd_filename, const char *cpu_model)
> +static void r2d_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      SuperHCPU *cpu;
>      CPUSH4State *env;
>      ResetData *reset_info;
> diff --git a/hw/realview.c b/hw/realview.c
> index 19db4d0..8dc4be6 100644
> --- a/hw/realview.c
> +++ b/hw/realview.c
> @@ -330,11 +330,14 @@ static void realview_init(ram_addr_t ram_size,
>      arm_load_kernel(arm_env_get_cpu(first_cpu), &realview_binfo);
>  }
>
> -static void realview_eb_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void realview_eb_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      if (!cpu_model) {
>          cpu_model = "arm926";
>      }
> @@ -342,11 +345,14 @@ static void realview_eb_init(ram_addr_t ram_size,
>                    initrd_filename, cpu_model, BOARD_EB);
>  }
>
> -static void realview_eb_mpcore_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void realview_eb_mpcore_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      if (!cpu_model) {
>          cpu_model = "arm11mpcore";
>      }
> @@ -354,11 +360,14 @@ static void realview_eb_mpcore_init(ram_addr_t ram_size,
>                    initrd_filename, cpu_model, BOARD_EB_MPCORE);
>  }
>
> -static void realview_pb_a8_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void realview_pb_a8_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      if (!cpu_model) {
>          cpu_model = "cortex-a8";
>      }
> @@ -366,11 +375,14 @@ static void realview_pb_a8_init(ram_addr_t ram_size,
>                    initrd_filename, cpu_model, BOARD_PB_A8);
>  }
>
> -static void realview_pbx_a9_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void realview_pbx_a9_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      if (!cpu_model) {
>          cpu_model = "cortex-a9";
>      }
> diff --git a/hw/s390-virtio.c b/hw/s390-virtio.c
> index 47eed35..39ff178 100644
> --- a/hw/s390-virtio.c
> +++ b/hw/s390-virtio.c
> @@ -151,13 +151,14 @@ unsigned s390_del_running_cpu(CPUS390XState *env)
>  }
>
>  /* PC hardware initialisation */
> -static void s390_init(ram_addr_t my_ram_size,
> -                      const char *boot_device,
> -                      const char *kernel_filename,
> -                      const char *kernel_cmdline,
> -                      const char *initrd_filename,
> -                      const char *cpu_model)
> +static void s390_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t my_ram_size = args->ram_size;
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      CPUS390XState *env = NULL;
>      MemoryRegion *sysmem = get_system_memory();
>      MemoryRegion *ram = g_new(MemoryRegion, 1);
> diff --git a/hw/shix.c b/hw/shix.c
> index dd9ce17..b56dd54 100644
> --- a/hw/shix.c
> +++ b/hw/shix.c
> @@ -37,11 +37,9 @@
>  #define BIOS_FILENAME "shix_bios.bin"
>  #define BIOS_ADDRESS 0xA0000000
>
> -static void shix_init(ram_addr_t ram_size,
> -               const char *boot_device,
> -              const char *kernel_filename, const char *kernel_cmdline,
> -              const char *initrd_filename, const char *cpu_model)
> +static void shix_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
>      int ret;
>      CPUSH4State *env;
>      struct SH7750State *s;
> diff --git a/hw/spapr.c b/hw/spapr.c
> index 09b8e99..637b3fb 100644
> --- a/hw/spapr.c
> +++ b/hw/spapr.c
> @@ -665,13 +665,14 @@ static int spapr_vga_init(PCIBus *pci_bus)
>  }
>
>  /* pSeries LPAR / sPAPR hardware init */
> -static void ppc_spapr_init(ram_addr_t ram_size,
> -                           const char *boot_device,
> -                           const char *kernel_filename,
> -                           const char *kernel_cmdline,
> -                           const char *initrd_filename,
> -                           const char *cpu_model)
> +static void ppc_spapr_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      PowerPCCPU *cpu;
>      CPUPPCState *env;
>      PCIHostState *phb;
> diff --git a/hw/spitz.c b/hw/spitz.c
> index 24346dc..2942626 100644
> --- a/hw/spitz.c
> +++ b/hw/spitz.c
> @@ -936,38 +936,46 @@ static void spitz_common_init(ram_addr_t ram_size,
>      sl_bootparam_write(SL_PXA_PARAM_BASE);
>  }
>
> -static void spitz_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void spitz_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      spitz_common_init(ram_size, kernel_filename,
>                  kernel_cmdline, initrd_filename, cpu_model, spitz, 0x2c9);
>  }
>
> -static void borzoi_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void borzoi_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      spitz_common_init(ram_size, kernel_filename,
>                  kernel_cmdline, initrd_filename, cpu_model, borzoi, 0x33f);
>  }
>
> -static void akita_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void akita_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      spitz_common_init(ram_size, kernel_filename,
>                  kernel_cmdline, initrd_filename, cpu_model, akita, 0x2e8);
>  }
>
> -static void terrier_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void terrier_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      spitz_common_init(ram_size, kernel_filename,
>                  kernel_cmdline, initrd_filename, cpu_model, terrier, 0x33f);
>  }
> diff --git a/hw/stellaris.c b/hw/stellaris.c
> index 353ca4c..bfb18b0 100644
> --- a/hw/stellaris.c
> +++ b/hw/stellaris.c
> @@ -1313,19 +1313,17 @@ static void stellaris_init(const char *kernel_filename, const char *cpu_model,
>  }
>
>  /* FIXME: Figure out how to generate these from stellaris_boards.  */
> -static void lm3s811evb_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void lm3s811evb_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
>      stellaris_init(kernel_filename, cpu_model, &stellaris_boards[0]);
>  }
>
> -static void lm3s6965evb_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void lm3s6965evb_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
>      stellaris_init(kernel_filename, cpu_model, &stellaris_boards[1]);
>  }
>
> diff --git a/hw/sun4m.c b/hw/sun4m.c
> index a04b485..dbe93f9 100644
> --- a/hw/sun4m.c
> +++ b/hw/sun4m.c
> @@ -1306,92 +1306,118 @@ static const struct sun4m_hwdef sun4m_hwdefs[] = {
>  };
>
>  /* SPARCstation 5 hardware initialisation */
> -static void ss5_init(ram_addr_t RAM_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void ss5_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sun4m_hw_init(&sun4m_hwdefs[0], RAM_size, boot_device, kernel_filename,
>                    kernel_cmdline, initrd_filename, cpu_model);
>  }
>
>  /* SPARCstation 10 hardware initialisation */
> -static void ss10_init(ram_addr_t RAM_size,
> -                      const char *boot_device,
> -                      const char *kernel_filename, const char *kernel_cmdline,
> -                      const char *initrd_filename, const char *cpu_model)
> +static void ss10_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sun4m_hw_init(&sun4m_hwdefs[1], RAM_size, boot_device, kernel_filename,
>                    kernel_cmdline, initrd_filename, cpu_model);
>  }
>
>  /* SPARCserver 600MP hardware initialisation */
> -static void ss600mp_init(ram_addr_t RAM_size,
> -                         const char *boot_device,
> -                         const char *kernel_filename,
> -                         const char *kernel_cmdline,
> -                         const char *initrd_filename, const char *cpu_model)
> +static void ss600mp_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sun4m_hw_init(&sun4m_hwdefs[2], RAM_size, boot_device, kernel_filename,
>                    kernel_cmdline, initrd_filename, cpu_model);
>  }
>
>  /* SPARCstation 20 hardware initialisation */
> -static void ss20_init(ram_addr_t RAM_size,
> -                      const char *boot_device,
> -                      const char *kernel_filename, const char *kernel_cmdline,
> -                      const char *initrd_filename, const char *cpu_model)
> +static void ss20_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sun4m_hw_init(&sun4m_hwdefs[3], RAM_size, boot_device, kernel_filename,
>                    kernel_cmdline, initrd_filename, cpu_model);
>  }
>
>  /* SPARCstation Voyager hardware initialisation */
> -static void vger_init(ram_addr_t RAM_size,
> -                      const char *boot_device,
> -                      const char *kernel_filename, const char *kernel_cmdline,
> -                      const char *initrd_filename, const char *cpu_model)
> +static void vger_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sun4m_hw_init(&sun4m_hwdefs[4], RAM_size, boot_device, kernel_filename,
>                    kernel_cmdline, initrd_filename, cpu_model);
>  }
>
>  /* SPARCstation LX hardware initialisation */
> -static void ss_lx_init(ram_addr_t RAM_size,
> -                       const char *boot_device,
> -                       const char *kernel_filename, const char *kernel_cmdline,
> -                       const char *initrd_filename, const char *cpu_model)
> +static void ss_lx_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sun4m_hw_init(&sun4m_hwdefs[5], RAM_size, boot_device, kernel_filename,
>                    kernel_cmdline, initrd_filename, cpu_model);
>  }
>
>  /* SPARCstation 4 hardware initialisation */
> -static void ss4_init(ram_addr_t RAM_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void ss4_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sun4m_hw_init(&sun4m_hwdefs[6], RAM_size, boot_device, kernel_filename,
>                    kernel_cmdline, initrd_filename, cpu_model);
>  }
>
>  /* SPARCClassic hardware initialisation */
> -static void scls_init(ram_addr_t RAM_size,
> -                      const char *boot_device,
> -                      const char *kernel_filename, const char *kernel_cmdline,
> -                      const char *initrd_filename, const char *cpu_model)
> +static void scls_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sun4m_hw_init(&sun4m_hwdefs[7], RAM_size, boot_device, kernel_filename,
>                    kernel_cmdline, initrd_filename, cpu_model);
>  }
>
>  /* SPARCbook hardware initialisation */
> -static void sbook_init(ram_addr_t RAM_size,
> -                       const char *boot_device,
> -                       const char *kernel_filename, const char *kernel_cmdline,
> -                       const char *initrd_filename, const char *cpu_model)
> +static void sbook_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sun4m_hw_init(&sun4m_hwdefs[8], RAM_size, boot_device, kernel_filename,
>                    kernel_cmdline, initrd_filename, cpu_model);
>  }
> @@ -1654,21 +1680,27 @@ static void sun4d_hw_init(const struct sun4d_hwdef *hwdef, ram_addr_t RAM_size,
>  }
>
>  /* SPARCserver 1000 hardware initialisation */
> -static void ss1000_init(ram_addr_t RAM_size,
> -                        const char *boot_device,
> -                        const char *kernel_filename, const char *kernel_cmdline,
> -                        const char *initrd_filename, const char *cpu_model)
> +static void ss1000_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sun4d_hw_init(&sun4d_hwdefs[0], RAM_size, boot_device, kernel_filename,
>                    kernel_cmdline, initrd_filename, cpu_model);
>  }
>
>  /* SPARCcenter 2000 hardware initialisation */
> -static void ss2000_init(ram_addr_t RAM_size,
> -                        const char *boot_device,
> -                        const char *kernel_filename, const char *kernel_cmdline,
> -                        const char *initrd_filename, const char *cpu_model)
> +static void ss2000_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sun4d_hw_init(&sun4d_hwdefs[1], RAM_size, boot_device, kernel_filename,
>                    kernel_cmdline, initrd_filename, cpu_model);
>  }
> @@ -1848,11 +1880,14 @@ static void sun4c_hw_init(const struct sun4c_hwdef *hwdef, ram_addr_t RAM_size,
>  }
>
>  /* SPARCstation 2 hardware initialisation */
> -static void ss2_init(ram_addr_t RAM_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void ss2_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sun4c_hw_init(&sun4c_hwdefs[0], RAM_size, boot_device, kernel_filename,
>                    kernel_cmdline, initrd_filename, cpu_model);
>  }
> diff --git a/hw/sun4u.c b/hw/sun4u.c
> index 940db33..abf68cf 100644
> --- a/hw/sun4u.c
> +++ b/hw/sun4u.c
> @@ -933,31 +933,40 @@ static const struct hwdef hwdefs[] = {
>  };
>
>  /* Sun4u hardware initialisation */
> -static void sun4u_init(ram_addr_t RAM_size,
> -                       const char *boot_devices,
> -                       const char *kernel_filename, const char *kernel_cmdline,
> -                       const char *initrd_filename, const char *cpu_model)
> -{
> +static void sun4u_init(QEMUMachineInitArgs *args)
> +{
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_devices = args->boot_device;
>      sun4uv_init(get_system_memory(), RAM_size, boot_devices, kernel_filename,
>                  kernel_cmdline, initrd_filename, cpu_model, &hwdefs[0]);
>  }
>
>  /* Sun4v hardware initialisation */
> -static void sun4v_init(ram_addr_t RAM_size,
> -                       const char *boot_devices,
> -                       const char *kernel_filename, const char *kernel_cmdline,
> -                       const char *initrd_filename, const char *cpu_model)
> -{
> +static void sun4v_init(QEMUMachineInitArgs *args)
> +{
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_devices = args->boot_device;
>      sun4uv_init(get_system_memory(), RAM_size, boot_devices, kernel_filename,
>                  kernel_cmdline, initrd_filename, cpu_model, &hwdefs[1]);
>  }
>
>  /* Niagara hardware initialisation */
> -static void niagara_init(ram_addr_t RAM_size,
> -                         const char *boot_devices,
> -                         const char *kernel_filename, const char *kernel_cmdline,
> -                         const char *initrd_filename, const char *cpu_model)
> -{
> +static void niagara_init(QEMUMachineInitArgs *args)
> +{
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_devices = args->boot_device;
>      sun4uv_init(get_system_memory(), RAM_size, boot_devices, kernel_filename,
>                  kernel_cmdline, initrd_filename, cpu_model, &hwdefs[2]);
>  }
> diff --git a/hw/tosa.c b/hw/tosa.c
> index 297a8c2..512278c 100644
> --- a/hw/tosa.c
> +++ b/hw/tosa.c
> @@ -205,11 +205,12 @@ static struct arm_boot_info tosa_binfo = {
>      .ram_size = 0x04000000,
>  };
>
> -static void tosa_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void tosa_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      MemoryRegion *address_space_mem = get_system_memory();
>      MemoryRegion *rom = g_new(MemoryRegion, 1);
>      PXA2xxState *mpu;
> diff --git a/hw/versatilepb.c b/hw/versatilepb.c
> index 7b1b025..756ec29 100644
> --- a/hw/versatilepb.c
> +++ b/hw/versatilepb.c
> @@ -348,22 +348,28 @@ static void versatile_init(ram_addr_t ram_size,
>      arm_load_kernel(cpu, &versatile_binfo);
>  }
>
> -static void vpb_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void vpb_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      versatile_init(ram_size,
>                     boot_device,
>                     kernel_filename, kernel_cmdline,
>                     initrd_filename, cpu_model, 0x183);
>  }
>
> -static void vab_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void vab_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      versatile_init(ram_size,
>                     boot_device,
>                     kernel_filename, kernel_cmdline,
> diff --git a/hw/vexpress.c b/hw/vexpress.c
> index 3596d1e..36503d6 100644
> --- a/hw/vexpress.c
> +++ b/hw/vexpress.c
> @@ -467,25 +467,27 @@ static void vexpress_common_init(const VEDBoardInfo *daughterboard,
>      arm_load_kernel(arm_env_get_cpu(first_cpu), &vexpress_binfo);
>  }
>
> -static void vexpress_a9_init(ram_addr_t ram_size,
> -                             const char *boot_device,
> -                             const char *kernel_filename,
> -                             const char *kernel_cmdline,
> -                             const char *initrd_filename,
> -                             const char *cpu_model)
> +static void vexpress_a9_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      vexpress_common_init(&a9_daughterboard,
>                           ram_size, boot_device, kernel_filename,
>                           kernel_cmdline, initrd_filename, cpu_model);
>  }
>
> -static void vexpress_a15_init(ram_addr_t ram_size,
> -                              const char *boot_device,
> -                              const char *kernel_filename,
> -                              const char *kernel_cmdline,
> -                              const char *initrd_filename,
> -                              const char *cpu_model)
> +static void vexpress_a15_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      vexpress_common_init(&a15_daughterboard,
>                           ram_size, boot_device, kernel_filename,
>                           kernel_cmdline, initrd_filename, cpu_model);
> diff --git a/hw/virtex_ml507.c b/hw/virtex_ml507.c
> index 79bc0d1..a09b27a 100644
> --- a/hw/virtex_ml507.c
> +++ b/hw/virtex_ml507.c
> @@ -183,12 +183,12 @@ static int xilinx_load_device_tree(target_phys_addr_t addr,
>      return fdt_size;
>  }
>
> -static void virtex_init(ram_addr_t ram_size,
> -                        const char *boot_device,
> -                        const char *kernel_filename,
> -                        const char *kernel_cmdline,
> -                        const char *initrd_filename, const char *cpu_model)
> +static void virtex_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
>      MemoryRegion *address_space_mem = get_system_memory();
>      DeviceState *dev;
>      PowerPCCPU *cpu;
> diff --git a/hw/xen_machine_pv.c b/hw/xen_machine_pv.c
> index 4b72aa7..4264703 100644
> --- a/hw/xen_machine_pv.c
> +++ b/hw/xen_machine_pv.c
> @@ -29,13 +29,12 @@
>  #include "xen_domainbuild.h"
>  #include "blockdev.h"
>
> -static void xen_init_pv(ram_addr_t ram_size,
> -                       const char *boot_device,
> -                       const char *kernel_filename,
> -                       const char *kernel_cmdline,
> -                       const char *initrd_filename,
> -                       const char *cpu_model)
> +static void xen_init_pv(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      X86CPU *cpu;
>      CPUX86State *env;
>      DriveInfo *dinfo;
> diff --git a/hw/xilinx_zynq.c b/hw/xilinx_zynq.c
> index fd46ba2..c55dafb 100644
> --- a/hw/xilinx_zynq.c
> +++ b/hw/xilinx_zynq.c
> @@ -77,10 +77,13 @@ static inline void zynq_init_spi_flashes(uint32_t base_addr, qemu_irq irq)
>
>  }
>
> -static void zynq_init(ram_addr_t ram_size, const char *boot_device,
> -                        const char *kernel_filename, const char *kernel_cmdline,
> -                        const char *initrd_filename, const char *cpu_model)
> +static void zynq_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      ARMCPU *cpu;
>      MemoryRegion *address_space_mem = get_system_memory();
>      MemoryRegion *ext_ram = g_new(MemoryRegion, 1);
> diff --git a/hw/xtensa_lx60.c b/hw/xtensa_lx60.c
> index 3653f65..1fd2c47 100644
> --- a/hw/xtensa_lx60.c
> +++ b/hw/xtensa_lx60.c
> @@ -268,11 +268,14 @@ static void lx_init(const LxBoardDesc *board,
>      }
>  }
>
> -static void xtensa_lx60_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void xtensa_lx60_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      static const LxBoardDesc lx60_board = {
>          .flash_size = 0x400000,
>          .flash_sector_size = 0x10000,
> @@ -283,11 +286,14 @@ static void xtensa_lx60_init(ram_addr_t ram_size,
>              initrd_filename, cpu_model);
>  }
>
> -static void xtensa_lx200_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void xtensa_lx200_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      static const LxBoardDesc lx200_board = {
>          .flash_size = 0x1000000,
>          .flash_sector_size = 0x20000,
> diff --git a/hw/xtensa_sim.c b/hw/xtensa_sim.c
> index 831460b..2e846d8 100644
> --- a/hw/xtensa_sim.c
> +++ b/hw/xtensa_sim.c
> @@ -96,11 +96,14 @@ static void sim_init(ram_addr_t ram_size,
>      }
>  }
>
> -static void xtensa_sim_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void xtensa_sim_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      if (!cpu_model) {
>          cpu_model = XTENSA_DEFAULT_CPU_MODEL;
>      }
> diff --git a/hw/z2.c b/hw/z2.c
> index 076fad2..f62b806 100644
> --- a/hw/z2.c
> +++ b/hw/z2.c
> @@ -295,11 +295,12 @@ static TypeInfo aer915_info = {
>      .class_init    = aer915_class_init,
>  };
>
> -static void z2_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void z2_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      MemoryRegion *address_space_mem = get_system_memory();
>      uint32_t sector_len = 0x10000;
>      PXA2xxState *mpu;
> diff --git a/vl.c b/vl.c
> index 5b357a3..ee3c43a 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -3638,8 +3638,13 @@ int main(int argc, char **argv, char **envp)
>
>      qdev_machine_init();
>
> -    machine->init(ram_size, boot_devices,
> -                  kernel_filename, kernel_cmdline, initrd_filename, cpu_model);
> +    QEMUMachineInitArgs args = { .ram_size = ram_size,
> +                                 .boot_device = boot_devices,
> +                                 .kernel_filename = kernel_filename,
> +                                 .kernel_cmdline = kernel_cmdline,
> +                                 .initrd_filename = initrd_filename,
> +                                 .cpu_model = cpu_model };
> +    machine->init(&args);
>
>      cpu_synchronize_all_post_init();
>
> --
> 1.7.11.4
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 20 08:48:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Oct 2012 08:48:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPUiZ-0001zh-2X; Sat, 20 Oct 2012 08:47:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPUiX-0001zc-0R
	for xen-devel@lists.xensource.com; Sat, 20 Oct 2012 08:47:37 +0000
Received: from [193.109.254.147:9162] by server-2.bemta-14.messagelabs.com id
	DF/7B-19917-82562805; Sat, 20 Oct 2012 08:47:36 +0000
X-Env-Sender: blauwirbel@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1350722850!13402384!1
X-Originating-IP: [209.85.223.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12701 invoked from network); 20 Oct 2012 08:47:31 -0000
Received: from mail-ie0-f171.google.com (HELO mail-ie0-f171.google.com)
	(209.85.223.171)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Oct 2012 08:47:31 -0000
Received: by mail-ie0-f171.google.com with SMTP id s9so2196200iec.30
	for ;
	Sat, 20 Oct 2012 01:47:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=e4XP3n8O0fPdB/JH2w/ruqiUDC5Hj4T7uOCTF5mi9rI=;
	b=ysbIdPk228vLs/F0iI1lPgYWV/VbWpSoyuaE1XcL5g8GhbRNQVVofxHKbFG807uVn6
	t9HFEjqHoBssNrUko8F0dLlTvwSzG5pfgCeSYWCCbxmPcSWoub1abACRTgdQlJ9ORMdY
	hQzXLrgYCRgJgn7LU2QFS4FG1sYnqCFtww/u6ZzOG6FWSbKhEKeZ+xW12CSKtxzd6t9M
	izyqUqWx92vuFJe+Pgl3cA2upmdWLb4ml24UwZClzwnK1juy5wn1qmVqyinugK4gxO1J
	SmwfkSVWIJed9kCCygtP5BAjz+J0THpctgnkK/d5SjQkh/7AenJjSdX4JRs//hCFdV9V
	KPqA==
Received: by 10.42.101.11 with SMTP id c11mr3220730ico.52.1350722850144; Sat,
	20 Oct 2012 01:47:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.53.130 with HTTP; Sat, 20 Oct 2012 01:47:09 -0700 (PDT)
In-Reply-To: <1350332522-26635-1-git-send-email-ehabkost@redhat.com>
References: <1350332522-26635-1-git-send-email-ehabkost@redhat.com>
From: Blue Swirl 
Date: Sat, 20 Oct 2012 08:47:09 +0000
Message-ID: 
To: Eduardo Habkost 
Cc: Peter Maydell ,
	Evgeny Voevodin , qemu-devel@nongnu.org,
	Peter Crosthwaite ,
	Max Filippov ,
	"Edgar E. Iglesias" ,
	Guan Xuetao , xen-devel@lists.xensource.com,
	Igor Mitsyanko ,
	Magnus Damm , Alexander Graf ,
	=?UTF-8?Q?Herv=C3=A9_Poussineau?= ,
	Maksim Kozlov ,
	Andrzej Zaborowski ,
	Fabien Chouteau , Jan Kiszka ,
	Paul Brook , Anthony Liguori ,
	Michael Walle , qemu-ppc@nongnu.org,
	Dmitry Solodkiy ,
	Aurelien Jarno 
Subject: Re: [Xen-devel] [QEMU PATCH v4] create struct for machine
	initialization arguments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thanks, applied.

On Mon, Oct 15, 2012 at 8:22 PM, Eduardo Habkost  wrote:
> This should help us to:
> - More easily add or remove machine initialization arguments without
>   having to change every single machine init function;
> - More easily make mechanical changes involving the machine init
>   functions in the future;
> - Let machine initialization forward the init arguments to other
>   functions more easily.
>
> This change was half-mechanical process: first the struct was added with
> the local ram_size, boot_device, kernel_*, initrd_*, and cpu_model local
> variable initialization to all functions. Then the compiler helped me
> locate the local variables that are unused, so they could be removed.
>
> ---
>
> Changes v3 -> v4:
>  - Rebase against latest qemu.git master, solved conflicts at
>    hw/xilinx_zynq.c
>
> Changes v2 -> v3:
>  - Fix typo (missing dot) on main()
>  - Fix another mistake on xen_init_pv()
>
> Changes v1 -> v2:
>  - Fix mistake on the conversion of pc_xen_hvm_init() and xen_init_pv()
>
>
>  hw/alpha_dp264.c              |  12 ++--
>  hw/an5206.c                   |   8 +--
>  hw/axis_dev88.c               |   9 +--
>  hw/boards.h                   |  16 +++--
>  hw/collie.c                   |   9 +--
>  hw/dummy_m68k.c               |   8 +--
>  hw/exynos4_boards.c           |  16 ++---
>  hw/gumstix.c                  |  11 +---
>  hw/highbank.c                 |  10 ++--
>  hw/integratorcp.c             |  10 ++--
>  hw/kzm.c                      |  10 ++--
>  hw/leon3.c                    |  10 ++--
>  hw/lm32_boards.c              |  18 +++---
>  hw/mainstone.c                |  10 ++--
>  hw/mcf5208.c                  |   8 +--
>  hw/milkymist.c                |  10 ++--
>  hw/mips_fulong2e.c            |   9 ++-
>  hw/mips_jazz.c                |  14 ++---
>  hw/mips_malta.c               |  10 ++--
>  hw/mips_mipssim.c             |  10 ++--
>  hw/mips_r4k.c                 |  10 ++--
>  hw/musicpal.c                 |   9 +--
>  hw/nseries.c                  |  22 ++++---
>  hw/null-machine.c             |   7 +--
>  hw/omap_sx1.c                 |  22 ++++---
>  hw/openrisc_sim.c             |  10 ++--
>  hw/palm.c                     |   9 +--
>  hw/pc_piix.c                  |  50 ++++++++--------
>  hw/petalogix_ml605_mmu.c      |   8 +--
>  hw/petalogix_s3adsp1800_mmu.c |   8 +--
>  hw/ppc/e500plat.c             |  13 +++--
>  hw/ppc/mpc8544ds.c            |  13 +++--
>  hw/ppc405_boards.c            |  25 ++++----
>  hw/ppc440_bamboo.c            |  12 ++--
>  hw/ppc_newworld.c             |  13 +++--
>  hw/ppc_oldworld.c             |  13 +++--
>  hw/ppc_prep.c                 |  13 +++--
>  hw/puv3.c                     |   8 ++-
>  hw/r2d.c                      |   9 +--
>  hw/realview.c                 |  44 +++++++++-----
>  hw/s390-virtio.c              |  13 +++--
>  hw/shix.c                     |   6 +-
>  hw/spapr.c                    |  13 +++--
>  hw/spitz.c                    |  40 ++++++++-----
>  hw/stellaris.c                |  14 ++---
>  hw/sun4m.c                    | 133 ++++++++++++++++++++++++++----------------
>  hw/sun4u.c                    |  39 ++++++++-----
>  hw/tosa.c                     |   9 +--
>  hw/versatilepb.c              |  22 ++++---
>  hw/vexpress.c                 |  26 +++++----
>  hw/virtex_ml507.c             |  10 ++--
>  hw/xen_machine_pv.c           |  11 ++--
>  hw/xilinx_zynq.c              |   9 ++-
>  hw/xtensa_lx60.c              |  22 ++++---
>  hw/xtensa_sim.c               |  11 ++--
>  hw/z2.c                       |   9 +--
>  vl.c                          |   9 ++-
>  57 files changed, 518 insertions(+), 414 deletions(-)
>
> diff --git a/hw/alpha_dp264.c b/hw/alpha_dp264.c
> index 5ea04c7..8f082a6 100644
> --- a/hw/alpha_dp264.c
> +++ b/hw/alpha_dp264.c
> @@ -42,13 +42,13 @@ static int clipper_pci_map_irq(PCIDevice *d, int irq_num)
>      return (slot + 1) * 4 + irq_num;
>  }
>
> -static void clipper_init(ram_addr_t ram_size,
> -                         const char *boot_device,
> -                         const char *kernel_filename,
> -                         const char *kernel_cmdline,
> -                         const char *initrd_filename,
> -                         const char *cpu_model)
> +static void clipper_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      CPUAlphaState *cpus[4];
>      PCIBus *pci_bus;
>      ISABus *isa_bus;
> diff --git a/hw/an5206.c b/hw/an5206.c
> index 25407c0..042c5fc 100644
> --- a/hw/an5206.c
> +++ b/hw/an5206.c
> @@ -19,11 +19,11 @@
>
>  /* Board init.  */
>
> -static void an5206_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void an5206_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
>      CPUM68KState *env;
>      int kernel_size;
>      uint64_t elf_entry;
> diff --git a/hw/axis_dev88.c b/hw/axis_dev88.c
> index eab6327..2fd7356 100644
> --- a/hw/axis_dev88.c
> +++ b/hw/axis_dev88.c
> @@ -242,11 +242,12 @@ static const MemoryRegionOps gpio_ops = {
>  static struct cris_load_info li;
>
>  static
> -void axisdev88_init (ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +void axisdev88_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
>      CRISCPU *cpu;
>      CPUCRISState *env;
>      DeviceState *dev;
> diff --git a/hw/boards.h b/hw/boards.h
> index a2e0a54..813d0e5 100644
> --- a/hw/boards.h
> +++ b/hw/boards.h
> @@ -5,12 +5,16 @@
>
>  #include "qdev.h"
>
> -typedef void QEMUMachineInitFunc(ram_addr_t ram_size,
> -                                 const char *boot_device,
> -                                 const char *kernel_filename,
> -                                 const char *kernel_cmdline,
> -                                 const char *initrd_filename,
> -                                 const char *cpu_model);
> +typedef struct QEMUMachineInitArgs {
> +    ram_addr_t ram_size;
> +    const char *boot_device;
> +    const char *kernel_filename;
> +    const char *kernel_cmdline;
> +    const char *initrd_filename;
> +    const char *cpu_model;
> +} QEMUMachineInitArgs;
> +
> +typedef void QEMUMachineInitFunc(QEMUMachineInitArgs *args);
>
>  typedef void QEMUMachineResetFunc(void);
>
> diff --git a/hw/collie.c b/hw/collie.c
> index 56f89a9..695982a 100644
> --- a/hw/collie.c
> +++ b/hw/collie.c
> @@ -23,11 +23,12 @@ static struct arm_boot_info collie_binfo = {
>      .ram_size = 0x20000000,
>  };
>
> -static void collie_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void collie_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      StrongARMState *s;
>      DriveInfo *dinfo;
>      MemoryRegion *sysmem = get_system_memory();
> diff --git a/hw/dummy_m68k.c b/hw/dummy_m68k.c
> index 7cc7a99..f436a0c 100644
> --- a/hw/dummy_m68k.c
> +++ b/hw/dummy_m68k.c
> @@ -16,11 +16,11 @@
>
>  /* Board init.  */
>
> -static void dummy_m68k_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void dummy_m68k_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
>      CPUM68KState *env;
>      MemoryRegion *address_space_mem =  get_system_memory();
>      MemoryRegion *ram = g_new(MemoryRegion, 1);
> diff --git a/hw/exynos4_boards.c b/hw/exynos4_boards.c
> index 4bb0a60..4951064 100644
> --- a/hw/exynos4_boards.c
> +++ b/hw/exynos4_boards.c
> @@ -130,22 +130,22 @@ static Exynos4210State *exynos4_boards_init_common(
>              exynos4_board_ram_size[board_type]);
>  }
>
> -static void nuri_init(ram_addr_t ram_size,
> -        const char *boot_device,
> -        const char *kernel_filename, const char *kernel_cmdline,
> -        const char *initrd_filename, const char *cpu_model)
> +static void nuri_init(QEMUMachineInitArgs *args)
>  {
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      exynos4_boards_init_common(kernel_filename, kernel_cmdline,
>                  initrd_filename, EXYNOS4_BOARD_NURI);
>
>      arm_load_kernel(arm_env_get_cpu(first_cpu), &exynos4_board_binfo);
>  }
>
> -static void smdkc210_init(ram_addr_t ram_size,
> -        const char *boot_device,
> -        const char *kernel_filename, const char *kernel_cmdline,
> -        const char *initrd_filename, const char *cpu_model)
> +static void smdkc210_init(QEMUMachineInitArgs *args)
>  {
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      Exynos4210State *s = exynos4_boards_init_common(kernel_filename,
>              kernel_cmdline, initrd_filename, EXYNOS4_BOARD_SMDKC210);
>
> diff --git a/hw/gumstix.c b/hw/gumstix.c
> index 13a36ea..4103a88 100644
> --- a/hw/gumstix.c
> +++ b/hw/gumstix.c
> @@ -45,10 +45,7 @@
>
>  static const int sector_len = 128 * 1024;
>
> -static void connex_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void connex_init(QEMUMachineInitArgs *args)
>  {
>      PXA2xxState *cpu;
>      DriveInfo *dinfo;
> @@ -84,11 +81,9 @@ static void connex_init(ram_addr_t ram_size,
>                      qdev_get_gpio_in(cpu->gpio, 36));
>  }
>
> -static void verdex_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void verdex_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
>      PXA2xxState *cpu;
>      DriveInfo *dinfo;
>      int be;
> diff --git a/hw/highbank.c b/hw/highbank.c
> index 11aa131..15036b6 100644
> --- a/hw/highbank.c
> +++ b/hw/highbank.c
> @@ -187,11 +187,13 @@ static struct arm_boot_info highbank_binfo;
>   * 32-bit host, set the reg value of memory to 0xf7ff00000 in the
>   * device tree and pass -m 2047 to QEMU.
>   */
> -static void highbank_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void highbank_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      DeviceState *dev;
>      SysBusDevice *busdev;
>      qemu_irq *irqp;
> diff --git a/hw/integratorcp.c b/hw/integratorcp.c
> index d0e2e90..ac0ea83 100644
> --- a/hw/integratorcp.c
> +++ b/hw/integratorcp.c
> @@ -438,11 +438,13 @@ static struct arm_boot_info integrator_binfo = {
>      .board_id = 0x113,
>  };
>
> -static void integratorcp_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void integratorcp_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      ARMCPU *cpu;
>      MemoryRegion *address_space_mem = get_system_memory();
>      MemoryRegion *ram = g_new(MemoryRegion, 1);
> diff --git a/hw/kzm.c b/hw/kzm.c
> index 68cd1b4..d1266d9 100644
> --- a/hw/kzm.c
> +++ b/hw/kzm.c
> @@ -70,11 +70,13 @@ static struct arm_boot_info kzm_binfo = {
>      .board_id = 1722,
>  };
>
> -static void kzm_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void kzm_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      ARMCPU *cpu;
>      MemoryRegion *address_space_mem = get_system_memory();
>      MemoryRegion *ram = g_new(MemoryRegion, 1);
> diff --git a/hw/leon3.c b/hw/leon3.c
> index 7a9729d..7742738 100644
> --- a/hw/leon3.c
> +++ b/hw/leon3.c
> @@ -94,13 +94,11 @@ static void leon3_set_pil_in(void *opaque, uint32_t pil_in)
>      }
>  }
>
> -static void leon3_generic_hw_init(ram_addr_t  ram_size,
> -                                  const char *boot_device,
> -                                  const char *kernel_filename,
> -                                  const char *kernel_cmdline,
> -                                  const char *initrd_filename,
> -                                  const char *cpu_model)
> +static void leon3_generic_hw_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
>      SPARCCPU *cpu;
>      CPUSPARCState   *env;
>      MemoryRegion *address_space_mem = get_system_memory();
> diff --git a/hw/lm32_boards.c b/hw/lm32_boards.c
> index b76d800..c5a62c8 100644
> --- a/hw/lm32_boards.c
> +++ b/hw/lm32_boards.c
> @@ -69,12 +69,10 @@ static void main_cpu_reset(void *opaque)
>      env->deba = reset_info->flash_base;
>  }
>
> -static void lm32_evr_init(ram_addr_t ram_size_not_used,
> -                          const char *boot_device,
> -                          const char *kernel_filename,
> -                          const char *kernel_cmdline,
> -                          const char *initrd_filename, const char *cpu_model)
> +static void lm32_evr_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
>      LM32CPU *cpu;
>      CPULM32State *env;
>      DriveInfo *dinfo;
> @@ -159,12 +157,12 @@ static void lm32_evr_init(ram_addr_t ram_size_not_used,
>      qemu_register_reset(main_cpu_reset, reset_info);
>  }
>
> -static void lm32_uclinux_init(ram_addr_t ram_size_not_used,
> -                          const char *boot_device,
> -                          const char *kernel_filename,
> -                          const char *kernel_cmdline,
> -                          const char *initrd_filename, const char *cpu_model)
> +static void lm32_uclinux_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      LM32CPU *cpu;
>      CPULM32State *env;
>      DriveInfo *dinfo;
> diff --git a/hw/mainstone.c b/hw/mainstone.c
> index 97687b6..c0d6034 100644
> --- a/hw/mainstone.c
> +++ b/hw/mainstone.c
> @@ -171,11 +171,13 @@ static void mainstone_common_init(MemoryRegion *address_space_mem,
>      arm_load_kernel(mpu->cpu, &mainstone_binfo);
>  }
>
> -static void mainstone_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void mainstone_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      mainstone_common_init(get_system_memory(), ram_size, kernel_filename,
>                  kernel_cmdline, initrd_filename, cpu_model, mainstone, 0x196);
>  }
> diff --git a/hw/mcf5208.c b/hw/mcf5208.c
> index ee25b1b..688bc3c 100644
> --- a/hw/mcf5208.c
> +++ b/hw/mcf5208.c
> @@ -187,11 +187,11 @@ static void mcf5208_sys_init(MemoryRegion *address_space, qemu_irq *pic)
>      }
>  }
>
> -static void mcf5208evb_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void mcf5208evb_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
>      CPUM68KState *env;
>      int kernel_size;
>      uint64_t elf_entry;
> diff --git a/hw/milkymist.c b/hw/milkymist.c
> index 2e7235b..ca9ed43 100644
> --- a/hw/milkymist.c
> +++ b/hw/milkymist.c
> @@ -73,12 +73,12 @@ static void main_cpu_reset(void *opaque)
>  }
>
>  static void
> -milkymist_init(ram_addr_t ram_size_not_used,
> -                          const char *boot_device,
> -                          const char *kernel_filename,
> -                          const char *kernel_cmdline,
> -                          const char *initrd_filename, const char *cpu_model)
> +milkymist_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      LM32CPU *cpu;
>      CPULM32State *env;
>      int kernel_size;
> diff --git a/hw/mips_fulong2e.c b/hw/mips_fulong2e.c
> index d4a8672..fb50a1f 100644
> --- a/hw/mips_fulong2e.c
> +++ b/hw/mips_fulong2e.c
> @@ -256,10 +256,13 @@ static void cpu_request_exit(void *opaque, int irq, int level)
>      }
>  }
>
> -static void mips_fulong2e_init(ram_addr_t ram_size, const char *boot_device,
> -                        const char *kernel_filename, const char *kernel_cmdline,
> -                        const char *initrd_filename, const char *cpu_model)
> +static void mips_fulong2e_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      char *filename;
>      MemoryRegion *address_space_mem = get_system_memory();
>      MemoryRegion *ram = g_new(MemoryRegion, 1);
> diff --git a/hw/mips_jazz.c b/hw/mips_jazz.c
> index db927f1..14df4d7 100644
> --- a/hw/mips_jazz.c
> +++ b/hw/mips_jazz.c
> @@ -302,21 +302,19 @@ static void mips_jazz_init(MemoryRegion *address_space,
>  }
>
>  static
> -void mips_magnum_init (ram_addr_t ram_size,
> -                       const char *boot_device,
> -                       const char *kernel_filename, const char *kernel_cmdline,
> -                       const char *initrd_filename, const char *cpu_model)
> +void mips_magnum_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
>          mips_jazz_init(get_system_memory(), get_system_io(),
>                         ram_size, cpu_model, JAZZ_MAGNUM);
>  }
>
>  static
> -void mips_pica61_init (ram_addr_t ram_size,
> -                       const char *boot_device,
> -                       const char *kernel_filename, const char *kernel_cmdline,
> -                       const char *initrd_filename, const char *cpu_model)
> +void mips_pica61_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
>      mips_jazz_init(get_system_memory(), get_system_io(),
>                     ram_size, cpu_model, JAZZ_PICA61);
>  }
> diff --git a/hw/mips_malta.c b/hw/mips_malta.c
> index 632b466..ad4910f 100644
> --- a/hw/mips_malta.c
> +++ b/hw/mips_malta.c
> @@ -775,11 +775,13 @@ static void cpu_request_exit(void *opaque, int irq, int level)
>  }
>
>  static
> -void mips_malta_init (ram_addr_t ram_size,
> -                      const char *boot_device,
> -                      const char *kernel_filename, const char *kernel_cmdline,
> -                      const char *initrd_filename, const char *cpu_model)
> +void mips_malta_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      char *filename;
>      pflash_t *fl;
>      MemoryRegion *system_memory = get_system_memory();
> diff --git a/hw/mips_mipssim.c b/hw/mips_mipssim.c
> index 830f635..a1d3945 100644
> --- a/hw/mips_mipssim.c
> +++ b/hw/mips_mipssim.c
> @@ -131,11 +131,13 @@ static void mipsnet_init(int base, qemu_irq irq, NICInfo *nd)
>  }
>
>  static void
> -mips_mipssim_init (ram_addr_t ram_size,
> -                   const char *boot_device,
> -                   const char *kernel_filename, const char *kernel_cmdline,
> -                   const char *initrd_filename, const char *cpu_model)
> +mips_mipssim_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      char *filename;
>      MemoryRegion *address_space_mem = get_system_memory();
>      MemoryRegion *ram = g_new(MemoryRegion, 1);
> diff --git a/hw/mips_r4k.c b/hw/mips_r4k.c
> index 967a76e..b73cdc3 100644
> --- a/hw/mips_r4k.c
> +++ b/hw/mips_r4k.c
> @@ -151,11 +151,13 @@ static void main_cpu_reset(void *opaque)
>
>  static const int sector_len = 32 * 1024;
>  static
> -void mips_r4k_init (ram_addr_t ram_size,
> -                    const char *boot_device,
> -                    const char *kernel_filename, const char *kernel_cmdline,
> -                    const char *initrd_filename, const char *cpu_model)
> +void mips_r4k_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      char *filename;
>      MemoryRegion *address_space_mem = get_system_memory();
>      MemoryRegion *ram = g_new(MemoryRegion, 1);
> diff --git a/hw/musicpal.c b/hw/musicpal.c
> index f305e21..f06814c 100644
> --- a/hw/musicpal.c
> +++ b/hw/musicpal.c
> @@ -1508,11 +1508,12 @@ static struct arm_boot_info musicpal_binfo = {
>      .board_id = 0x20e,
>  };
>
> -static void musicpal_init(ram_addr_t ram_size,
> -               const char *boot_device,
> -               const char *kernel_filename, const char *kernel_cmdline,
> -               const char *initrd_filename, const char *cpu_model)
> +static void musicpal_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      ARMCPU *cpu;
>      qemu_irq *cpu_pic;
>      qemu_irq pic[32];
> diff --git a/hw/nseries.c b/hw/nseries.c
> index 6df71eb..7ada90d 100644
> --- a/hw/nseries.c
> +++ b/hw/nseries.c
> @@ -1397,21 +1397,27 @@ static struct arm_boot_info n810_binfo = {
>      .atag_board = n810_atag_setup,
>  };
>
> -static void n800_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void n800_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      return n8x0_init(ram_size, boot_device,
>                      kernel_filename, kernel_cmdline, initrd_filename,
>                      cpu_model, &n800_binfo, 800);
>  }
>
> -static void n810_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void n810_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      return n8x0_init(ram_size, boot_device,
>                      kernel_filename, kernel_cmdline, initrd_filename,
>                      cpu_model, &n810_binfo, 810);
> diff --git a/hw/null-machine.c b/hw/null-machine.c
> index 69910d3..d813c08 100644
> --- a/hw/null-machine.c
> +++ b/hw/null-machine.c
> @@ -15,12 +15,7 @@
>  #include "hw/hw.h"
>  #include "hw/boards.h"
>
> -static void machine_none_init(ram_addr_t ram_size,
> -                              const char *boot_device,
> -                              const char *kernel_filename,
> -                              const char *kernel_cmdline,
> -                              const char *initrd_filename,
> -                              const char *cpu_model)
> +static void machine_none_init(QEMUMachineInitArgs *args)
>  {
>  }
>
> diff --git a/hw/omap_sx1.c b/hw/omap_sx1.c
> index abca341..ad17487 100644
> --- a/hw/omap_sx1.c
> +++ b/hw/omap_sx1.c
> @@ -209,20 +209,26 @@ static void sx1_init(ram_addr_t ram_size,
>      //~ qemu_console_resize(ds, 640, 480);
>  }
>
> -static void sx1_init_v1(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void sx1_init_v1(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sx1_init(ram_size, boot_device, kernel_filename,
>                  kernel_cmdline, initrd_filename, cpu_model, 1);
>  }
>
> -static void sx1_init_v2(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void sx1_init_v2(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sx1_init(ram_size, boot_device, kernel_filename,
>                  kernel_cmdline, initrd_filename, cpu_model, 2);
>  }
> diff --git a/hw/openrisc_sim.c b/hw/openrisc_sim.c
> index 55e97f0..e96a944 100644
> --- a/hw/openrisc_sim.c
> +++ b/hw/openrisc_sim.c
> @@ -90,13 +90,11 @@ static void cpu_openrisc_load_kernel(ram_addr_t ram_size,
>      cpu->env.pc = entry;
>  }
>
> -static void openrisc_sim_init(ram_addr_t ram_size,
> -                              const char *boot_device,
> -                              const char *kernel_filename,
> -                              const char *kernel_cmdline,
> -                              const char *initrd_filename,
> -                              const char *cpu_model)
> +static void openrisc_sim_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
>     OpenRISCCPU *cpu = NULL;
>      MemoryRegion *ram;
>      int n;
> diff --git a/hw/palm.c b/hw/palm.c
> index bacdc90..032b8d6 100644
> --- a/hw/palm.c
> +++ b/hw/palm.c
> @@ -190,11 +190,12 @@ static struct arm_boot_info palmte_binfo = {
>      .board_id = 0x331,
>  };
>
> -static void palmte_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void palmte_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      MemoryRegion *address_space_mem = get_system_memory();
>      struct omap_mpu_state_s *mpu;
>      int flash_size = 0x00800000;
> diff --git a/hw/pc_piix.c b/hw/pc_piix.c
> index 82364ab..36e165f 100644
> --- a/hw/pc_piix.c
> +++ b/hw/pc_piix.c
> @@ -287,13 +287,14 @@ static void pc_init1(MemoryRegion *system_memory,
>      }
>  }
>
> -static void pc_init_pci(ram_addr_t ram_size,
> -                        const char *boot_device,
> -                        const char *kernel_filename,
> -                        const char *kernel_cmdline,
> -                        const char *initrd_filename,
> -                        const char *cpu_model)
> +static void pc_init_pci(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      pc_init1(get_system_memory(),
>               get_system_io(),
>               ram_size, boot_device,
> @@ -301,13 +302,14 @@ static void pc_init_pci(ram_addr_t ram_size,
>               initrd_filename, cpu_model, 1, 1);
>  }
>
> -static void pc_init_pci_no_kvmclock(ram_addr_t ram_size,
> -                                    const char *boot_device,
> -                                    const char *kernel_filename,
> -                                    const char *kernel_cmdline,
> -                                    const char *initrd_filename,
> -                                    const char *cpu_model)
> +static void pc_init_pci_no_kvmclock(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      pc_init1(get_system_memory(),
>               get_system_io(),
>               ram_size, boot_device,
> @@ -315,13 +317,14 @@ static void pc_init_pci_no_kvmclock(ram_addr_t ram_size,
>               initrd_filename, cpu_model, 1, 0);
>  }
>
> -static void pc_init_isa(ram_addr_t ram_size,
> -                        const char *boot_device,
> -                        const char *kernel_filename,
> -                        const char *kernel_cmdline,
> -                        const char *initrd_filename,
> -                        const char *cpu_model)
> +static void pc_init_isa(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      if (cpu_model == NULL)
>          cpu_model = "486";
>      pc_init1(get_system_memory(),
> @@ -332,19 +335,12 @@ static void pc_init_isa(ram_addr_t ram_size,
>  }
>
>  #ifdef CONFIG_XEN
> -static void pc_xen_hvm_init(ram_addr_t ram_size,
> -                            const char *boot_device,
> -                            const char *kernel_filename,
> -                            const char *kernel_cmdline,
> -                            const char *initrd_filename,
> -                            const char *cpu_model)
> +static void pc_xen_hvm_init(QEMUMachineInitArgs *args)
>  {
>      if (xen_hvm_init() != 0) {
>          hw_error("xen hardware virtual machine initialisation failed");
>      }
> -    pc_init_pci_no_kvmclock(ram_size, boot_device,
> -                            kernel_filename, kernel_cmdline,
> -                            initrd_filename, cpu_model);
> +    pc_init_pci_no_kvmclock(args);
>      xen_vcpu_init();
>  }
>  #endif
> diff --git a/hw/petalogix_ml605_mmu.c b/hw/petalogix_ml605_mmu.c
> index b9bfbed..39df251 100644
> --- a/hw/petalogix_ml605_mmu.c
> +++ b/hw/petalogix_ml605_mmu.c
> @@ -73,12 +73,10 @@ static void machine_cpu_reset(MicroBlazeCPU *cpu)
>  }
>
>  static void
> -petalogix_ml605_init(ram_addr_t ram_size,
> -                          const char *boot_device,
> -                          const char *kernel_filename,
> -                          const char *kernel_cmdline,
> -                          const char *initrd_filename, const char *cpu_model)
> +petalogix_ml605_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
>      MemoryRegion *address_space_mem = get_system_memory();
>      DeviceState *dev, *dma, *eth0;
>      MicroBlazeCPU *cpu;
> diff --git a/hw/petalogix_s3adsp1800_mmu.c b/hw/petalogix_s3adsp1800_mmu.c
> index 2cf6882..71c32ce 100644
> --- a/hw/petalogix_s3adsp1800_mmu.c
> +++ b/hw/petalogix_s3adsp1800_mmu.c
> @@ -57,12 +57,10 @@ static void machine_cpu_reset(MicroBlazeCPU *cpu)
>  }
>
>  static void
> -petalogix_s3adsp1800_init(ram_addr_t ram_size,
> -                          const char *boot_device,
> -                          const char *kernel_filename,
> -                          const char *kernel_cmdline,
> -                          const char *initrd_filename, const char *cpu_model)
> +petalogix_s3adsp1800_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
>      DeviceState *dev;
>      MicroBlazeCPU *cpu;
>      CPUMBState *env;
> diff --git a/hw/ppc/e500plat.c b/hw/ppc/e500plat.c
> index 60a5cb3..4cfb940 100644
> --- a/hw/ppc/e500plat.c
> +++ b/hw/ppc/e500plat.c
> @@ -25,13 +25,14 @@ static void e500plat_fixup_devtree(PPCE500Params *params, void *fdt)
>                           sizeof(compatible));
>  }
>
> -static void e500plat_init(ram_addr_t ram_size,
> -                           const char *boot_device,
> -                           const char *kernel_filename,
> -                           const char *kernel_cmdline,
> -                           const char *initrd_filename,
> -                           const char *cpu_model)
> +static void e500plat_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *boot_device = args->boot_device;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      PPCE500Params params = {
>          .ram_size = ram_size,
>          .boot_device = boot_device,
> diff --git a/hw/ppc/mpc8544ds.c b/hw/ppc/mpc8544ds.c
> index 984d21c..e651661 100644
> --- a/hw/ppc/mpc8544ds.c
> +++ b/hw/ppc/mpc8544ds.c
> @@ -25,13 +25,14 @@ static void mpc8544ds_fixup_devtree(PPCE500Params *params, void *fdt)
>                           sizeof(compatible));
>  }
>
> -static void mpc8544ds_init(ram_addr_t ram_size,
> -                           const char *boot_device,
> -                           const char *kernel_filename,
> -                           const char *kernel_cmdline,
> -                           const char *initrd_filename,
> -                           const char *cpu_model)
> +static void mpc8544ds_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *boot_device = args->boot_device;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      PPCE500Params params = {
>          .ram_size = ram_size,
>          .boot_device = boot_device,
> diff --git a/hw/ppc405_boards.c b/hw/ppc405_boards.c
> index 476775d..e848cb0 100644
> --- a/hw/ppc405_boards.c
> +++ b/hw/ppc405_boards.c
> @@ -158,7 +158,7 @@ static void ref405ep_fpga_reset (void *opaque)
>      fpga->reg1 = 0x0F;
>  }
>
> -static void ref405ep_fpga_init (MemoryRegion *sysmem, uint32_t base)
> +static void ref405ep_fpga_init(MemoryRegion *sysmem, uint32_t base)
>  {
>      ref405ep_fpga_t *fpga;
>      MemoryRegion *fpga_memory = g_new(MemoryRegion, 1);
> @@ -170,13 +170,12 @@ static void ref405ep_fpga_init (MemoryRegion *sysmem, uint32_t base)
>      qemu_register_reset(&ref405ep_fpga_reset, fpga);
>  }
>
> -static void ref405ep_init (ram_addr_t ram_size,
> -                           const char *boot_device,
> -                           const char *kernel_filename,
> -                           const char *kernel_cmdline,
> -                           const char *initrd_filename,
> -                           const char *cpu_model)
> +static void ref405ep_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      char *filename;
>      ppc4xx_bd_info_t bd;
>      CPUPPCState *env;
> @@ -484,7 +483,7 @@ static void taihu_cpld_reset (void *opaque)
>      cpld->reg1 = 0x80;
>  }
>
> -static void taihu_cpld_init (MemoryRegion *sysmem, uint32_t base)
> +static void taihu_cpld_init(MemoryRegion *sysmem, uint32_t base)
>  {
>      taihu_cpld_t *cpld;
>      MemoryRegion *cpld_memory = g_new(MemoryRegion, 1);
> @@ -495,13 +494,11 @@ static void taihu_cpld_init (MemoryRegion *sysmem, uint32_t base)
>      qemu_register_reset(&taihu_cpld_reset, cpld);
>  }
>
> -static void taihu_405ep_init(ram_addr_t ram_size,
> -                             const char *boot_device,
> -                             const char *kernel_filename,
> -                             const char *kernel_cmdline,
> -                             const char *initrd_filename,
> -                             const char *cpu_model)
> +static void taihu_405ep_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *initrd_filename = args->initrd_filename;
>      char *filename;
>      qemu_irq *pic;
>      MemoryRegion *sysmem = get_system_memory();
> diff --git a/hw/ppc440_bamboo.c b/hw/ppc440_bamboo.c
> index c198071..78e7985 100644
> --- a/hw/ppc440_bamboo.c
> +++ b/hw/ppc440_bamboo.c
> @@ -157,13 +157,13 @@ static void main_cpu_reset(void *opaque)
>      mmubooke_create_initial_mapping(env, 0, 0);
>  }
>
> -static void bamboo_init(ram_addr_t ram_size,
> -                        const char *boot_device,
> -                        const char *kernel_filename,
> -                        const char *kernel_cmdline,
> -                        const char *initrd_filename,
> -                        const char *cpu_model)
> +static void bamboo_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      unsigned int pci_irq_nrs[4] = { 28, 27, 26, 25 };
>      MemoryRegion *address_space_mem = get_system_memory();
>      MemoryRegion *ram_memories
> diff --git a/hw/ppc_newworld.c b/hw/ppc_newworld.c
> index b8d3c9c..a265445 100644
> --- a/hw/ppc_newworld.c
> +++ b/hw/ppc_newworld.c
> @@ -128,13 +128,14 @@ static void ppc_core99_reset(void *opaque)
>  }
>
>  /* PowerPC Mac99 hardware initialisation */
> -static void ppc_core99_init (ram_addr_t ram_size,
> -                             const char *boot_device,
> -                             const char *kernel_filename,
> -                             const char *kernel_cmdline,
> -                             const char *initrd_filename,
> -                             const char *cpu_model)
> +static void ppc_core99_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      PowerPCCPU *cpu = NULL;
>      CPUPPCState *env = NULL;
>      char *filename;
> diff --git a/hw/ppc_oldworld.c b/hw/ppc_oldworld.c
> index 2c4a478..de33408 100644
> --- a/hw/ppc_oldworld.c
> +++ b/hw/ppc_oldworld.c
> @@ -71,13 +71,14 @@ static void ppc_heathrow_reset(void *opaque)
>      cpu_reset(CPU(cpu));
>  }
>
> -static void ppc_heathrow_init (ram_addr_t ram_size,
> -                               const char *boot_device,
> -                               const char *kernel_filename,
> -                               const char *kernel_cmdline,
> -                               const char *initrd_filename,
> -                               const char *cpu_model)
> +static void ppc_heathrow_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      MemoryRegion *sysmem = get_system_memory();
>      PowerPCCPU *cpu = NULL;
>      CPUPPCState *env = NULL;
> diff --git a/hw/ppc_prep.c b/hw/ppc_prep.c
> index 1544430..b426891 100644
> --- a/hw/ppc_prep.c
> +++ b/hw/ppc_prep.c
> @@ -447,13 +447,14 @@ static void ppc_prep_reset(void *opaque)
>  }
>
>  /* PowerPC PREP hardware initialisation */
> -static void ppc_prep_init (ram_addr_t ram_size,
> -                           const char *boot_device,
> -                           const char *kernel_filename,
> -                           const char *kernel_cmdline,
> -                           const char *initrd_filename,
> -                           const char *cpu_model)
> +static void ppc_prep_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      MemoryRegion *sysmem = get_system_memory();
>      PowerPCCPU *cpu = NULL;
>      CPUPPCState *env = NULL;
> diff --git a/hw/puv3.c b/hw/puv3.c
> index 43f7216..764799c 100644
> --- a/hw/puv3.c
> +++ b/hw/puv3.c
> @@ -91,10 +91,12 @@ static void puv3_load_kernel(const char *kernel_filename)
>      graphic_console_init(NULL, NULL, NULL, NULL, NULL);
>  }
>
> -static void puv3_init(ram_addr_t ram_size, const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void puv3_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *initrd_filename = args->initrd_filename;
>      CPUUniCore32State *env;
>
>      if (initrd_filename) {
> diff --git a/hw/r2d.c b/hw/r2d.c
> index 1bc191f..3cb6942 100644
> --- a/hw/r2d.c
> +++ b/hw/r2d.c
> @@ -219,11 +219,12 @@ static struct QEMU_PACKED
>      char kernel_cmdline[256];
>  } boot_params;
>
> -static void r2d_init(ram_addr_t ram_size,
> -              const char *boot_device,
> -             const char *kernel_filename, const char *kernel_cmdline,
> -             const char *initrd_filename, const char *cpu_model)
> +static void r2d_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      SuperHCPU *cpu;
>      CPUSH4State *env;
>      ResetData *reset_info;
> diff --git a/hw/realview.c b/hw/realview.c
> index 19db4d0..8dc4be6 100644
> --- a/hw/realview.c
> +++ b/hw/realview.c
> @@ -330,11 +330,14 @@ static void realview_init(ram_addr_t ram_size,
>      arm_load_kernel(arm_env_get_cpu(first_cpu), &realview_binfo);
>  }
>
> -static void realview_eb_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void realview_eb_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      if (!cpu_model) {
>          cpu_model = "arm926";
>      }
> @@ -342,11 +345,14 @@ static void realview_eb_init(ram_addr_t ram_size,
>                    initrd_filename, cpu_model, BOARD_EB);
>  }
>
> -static void realview_eb_mpcore_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void realview_eb_mpcore_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      if (!cpu_model) {
>          cpu_model = "arm11mpcore";
>      }
> @@ -354,11 +360,14 @@ static void realview_eb_mpcore_init(ram_addr_t ram_size,
>                    initrd_filename, cpu_model, BOARD_EB_MPCORE);
>  }
>
> -static void realview_pb_a8_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void realview_pb_a8_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      if (!cpu_model) {
>          cpu_model = "cortex-a8";
>      }
> @@ -366,11 +375,14 @@ static void realview_pb_a8_init(ram_addr_t ram_size,
>                    initrd_filename, cpu_model, BOARD_PB_A8);
>  }
>
> -static void realview_pbx_a9_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void realview_pbx_a9_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      if (!cpu_model) {
>          cpu_model = "cortex-a9";
>      }
> diff --git a/hw/s390-virtio.c b/hw/s390-virtio.c
> index 47eed35..39ff178 100644
> --- a/hw/s390-virtio.c
> +++ b/hw/s390-virtio.c
> @@ -151,13 +151,14 @@ unsigned s390_del_running_cpu(CPUS390XState *env)
>  }
>
>  /* PC hardware initialisation */
> -static void s390_init(ram_addr_t my_ram_size,
> -                      const char *boot_device,
> -                      const char *kernel_filename,
> -                      const char *kernel_cmdline,
> -                      const char *initrd_filename,
> -                      const char *cpu_model)
> +static void s390_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t my_ram_size = args->ram_size;
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      CPUS390XState *env = NULL;
>      MemoryRegion *sysmem = get_system_memory();
>      MemoryRegion *ram = g_new(MemoryRegion, 1);
> diff --git a/hw/shix.c b/hw/shix.c
> index dd9ce17..b56dd54 100644
> --- a/hw/shix.c
> +++ b/hw/shix.c
> @@ -37,11 +37,9 @@
>  #define BIOS_FILENAME "shix_bios.bin"
>  #define BIOS_ADDRESS 0xA0000000
>
> -static void shix_init(ram_addr_t ram_size,
> -               const char *boot_device,
> -              const char *kernel_filename, const char *kernel_cmdline,
> -              const char *initrd_filename, const char *cpu_model)
> +static void shix_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
>      int ret;
>      CPUSH4State *env;
>      struct SH7750State *s;
> diff --git a/hw/spapr.c b/hw/spapr.c
> index 09b8e99..637b3fb 100644
> --- a/hw/spapr.c
> +++ b/hw/spapr.c
> @@ -665,13 +665,14 @@ static int spapr_vga_init(PCIBus *pci_bus)
>  }
>
>  /* pSeries LPAR / sPAPR hardware init */
> -static void ppc_spapr_init(ram_addr_t ram_size,
> -                           const char *boot_device,
> -                           const char *kernel_filename,
> -                           const char *kernel_cmdline,
> -                           const char *initrd_filename,
> -                           const char *cpu_model)
> +static void ppc_spapr_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      PowerPCCPU *cpu;
>      CPUPPCState *env;
>      PCIHostState *phb;
> diff --git a/hw/spitz.c b/hw/spitz.c
> index 24346dc..2942626 100644
> --- a/hw/spitz.c
> +++ b/hw/spitz.c
> @@ -936,38 +936,46 @@ static void spitz_common_init(ram_addr_t ram_size,
>      sl_bootparam_write(SL_PXA_PARAM_BASE);
>  }
>
> -static void spitz_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void spitz_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      spitz_common_init(ram_size, kernel_filename,
>                  kernel_cmdline, initrd_filename, cpu_model, spitz, 0x2c9);
>  }
>
> -static void borzoi_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void borzoi_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      spitz_common_init(ram_size, kernel_filename,
>                  kernel_cmdline, initrd_filename, cpu_model, borzoi, 0x33f);
>  }
>
> -static void akita_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void akita_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      spitz_common_init(ram_size, kernel_filename,
>                  kernel_cmdline, initrd_filename, cpu_model, akita, 0x2e8);
>  }
>
> -static void terrier_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void terrier_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      spitz_common_init(ram_size, kernel_filename,
>                  kernel_cmdline, initrd_filename, cpu_model, terrier, 0x33f);
>  }
> diff --git a/hw/stellaris.c b/hw/stellaris.c
> index 353ca4c..bfb18b0 100644
> --- a/hw/stellaris.c
> +++ b/hw/stellaris.c
> @@ -1313,19 +1313,17 @@ static void stellaris_init(const char *kernel_filename, const char *cpu_model,
>  }
>
>  /* FIXME: Figure out how to generate these from stellaris_boards.  */
> -static void lm3s811evb_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void lm3s811evb_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
>      stellaris_init(kernel_filename, cpu_model, &stellaris_boards[0]);
>  }
>
> -static void lm3s6965evb_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void lm3s6965evb_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
>      stellaris_init(kernel_filename, cpu_model, &stellaris_boards[1]);
>  }
>
> diff --git a/hw/sun4m.c b/hw/sun4m.c
> index a04b485..dbe93f9 100644
> --- a/hw/sun4m.c
> +++ b/hw/sun4m.c
> @@ -1306,92 +1306,118 @@ static const struct sun4m_hwdef sun4m_hwdefs[] = {
>  };
>
>  /* SPARCstation 5 hardware initialisation */
> -static void ss5_init(ram_addr_t RAM_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void ss5_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sun4m_hw_init(&sun4m_hwdefs[0], RAM_size, boot_device, kernel_filename,
>                    kernel_cmdline, initrd_filename, cpu_model);
>  }
>
>  /* SPARCstation 10 hardware initialisation */
> -static void ss10_init(ram_addr_t RAM_size,
> -                      const char *boot_device,
> -                      const char *kernel_filename, const char *kernel_cmdline,
> -                      const char *initrd_filename, const char *cpu_model)
> +static void ss10_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sun4m_hw_init(&sun4m_hwdefs[1], RAM_size, boot_device, kernel_filename,
>                    kernel_cmdline, initrd_filename, cpu_model);
>  }
>
>  /* SPARCserver 600MP hardware initialisation */
> -static void ss600mp_init(ram_addr_t RAM_size,
> -                         const char *boot_device,
> -                         const char *kernel_filename,
> -                         const char *kernel_cmdline,
> -                         const char *initrd_filename, const char *cpu_model)
> +static void ss600mp_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sun4m_hw_init(&sun4m_hwdefs[2], RAM_size, boot_device, kernel_filename,
>                    kernel_cmdline, initrd_filename, cpu_model);
>  }
>
>  /* SPARCstation 20 hardware initialisation */
> -static void ss20_init(ram_addr_t RAM_size,
> -                      const char *boot_device,
> -                      const char *kernel_filename, const char *kernel_cmdline,
> -                      const char *initrd_filename, const char *cpu_model)
> +static void ss20_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sun4m_hw_init(&sun4m_hwdefs[3], RAM_size, boot_device, kernel_filename,
>                    kernel_cmdline, initrd_filename, cpu_model);
>  }
>
>  /* SPARCstation Voyager hardware initialisation */
> -static void vger_init(ram_addr_t RAM_size,
> -                      const char *boot_device,
> -                      const char *kernel_filename, const char *kernel_cmdline,
> -                      const char *initrd_filename, const char *cpu_model)
> +static void vger_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sun4m_hw_init(&sun4m_hwdefs[4], RAM_size, boot_device, kernel_filename,
>                    kernel_cmdline, initrd_filename, cpu_model);
>  }
>
>  /* SPARCstation LX hardware initialisation */
> -static void ss_lx_init(ram_addr_t RAM_size,
> -                       const char *boot_device,
> -                       const char *kernel_filename, const char *kernel_cmdline,
> -                       const char *initrd_filename, const char *cpu_model)
> +static void ss_lx_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sun4m_hw_init(&sun4m_hwdefs[5], RAM_size, boot_device, kernel_filename,
>                    kernel_cmdline, initrd_filename, cpu_model);
>  }
>
>  /* SPARCstation 4 hardware initialisation */
> -static void ss4_init(ram_addr_t RAM_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void ss4_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sun4m_hw_init(&sun4m_hwdefs[6], RAM_size, boot_device, kernel_filename,
>                    kernel_cmdline, initrd_filename, cpu_model);
>  }
>
>  /* SPARCClassic hardware initialisation */
> -static void scls_init(ram_addr_t RAM_size,
> -                      const char *boot_device,
> -                      const char *kernel_filename, const char *kernel_cmdline,
> -                      const char *initrd_filename, const char *cpu_model)
> +static void scls_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sun4m_hw_init(&sun4m_hwdefs[7], RAM_size, boot_device, kernel_filename,
>                    kernel_cmdline, initrd_filename, cpu_model);
>  }
>
>  /* SPARCbook hardware initialisation */
> -static void sbook_init(ram_addr_t RAM_size,
> -                       const char *boot_device,
> -                       const char *kernel_filename, const char *kernel_cmdline,
> -                       const char *initrd_filename, const char *cpu_model)
> +static void sbook_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sun4m_hw_init(&sun4m_hwdefs[8], RAM_size, boot_device, kernel_filename,
>                    kernel_cmdline, initrd_filename, cpu_model);
>  }
> @@ -1654,21 +1680,27 @@ static void sun4d_hw_init(const struct sun4d_hwdef *hwdef, ram_addr_t RAM_size,
>  }
>
>  /* SPARCserver 1000 hardware initialisation */
> -static void ss1000_init(ram_addr_t RAM_size,
> -                        const char *boot_device,
> -                        const char *kernel_filename, const char *kernel_cmdline,
> -                        const char *initrd_filename, const char *cpu_model)
> +static void ss1000_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sun4d_hw_init(&sun4d_hwdefs[0], RAM_size, boot_device, kernel_filename,
>                    kernel_cmdline, initrd_filename, cpu_model);
>  }
>
>  /* SPARCcenter 2000 hardware initialisation */
> -static void ss2000_init(ram_addr_t RAM_size,
> -                        const char *boot_device,
> -                        const char *kernel_filename, const char *kernel_cmdline,
> -                        const char *initrd_filename, const char *cpu_model)
> +static void ss2000_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sun4d_hw_init(&sun4d_hwdefs[1], RAM_size, boot_device, kernel_filename,
>                    kernel_cmdline, initrd_filename, cpu_model);
>  }
> @@ -1848,11 +1880,14 @@ static void sun4c_hw_init(const struct sun4c_hwdef *hwdef, ram_addr_t RAM_size,
>  }
>
>  /* SPARCstation 2 hardware initialisation */
> -static void ss2_init(ram_addr_t RAM_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void ss2_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      sun4c_hw_init(&sun4c_hwdefs[0], RAM_size, boot_device, kernel_filename,
>                    kernel_cmdline, initrd_filename, cpu_model);
>  }
> diff --git a/hw/sun4u.c b/hw/sun4u.c
> index 940db33..abf68cf 100644
> --- a/hw/sun4u.c
> +++ b/hw/sun4u.c
> @@ -933,31 +933,40 @@ static const struct hwdef hwdefs[] = {
>  };
>
>  /* Sun4u hardware initialisation */
> -static void sun4u_init(ram_addr_t RAM_size,
> -                       const char *boot_devices,
> -                       const char *kernel_filename, const char *kernel_cmdline,
> -                       const char *initrd_filename, const char *cpu_model)
> -{
> +static void sun4u_init(QEMUMachineInitArgs *args)
> +{
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_devices = args->boot_device;
>      sun4uv_init(get_system_memory(), RAM_size, boot_devices, kernel_filename,
>                  kernel_cmdline, initrd_filename, cpu_model, &hwdefs[0]);
>  }
>
>  /* Sun4v hardware initialisation */
> -static void sun4v_init(ram_addr_t RAM_size,
> -                       const char *boot_devices,
> -                       const char *kernel_filename, const char *kernel_cmdline,
> -                       const char *initrd_filename, const char *cpu_model)
> -{
> +static void sun4v_init(QEMUMachineInitArgs *args)
> +{
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_devices = args->boot_device;
>      sun4uv_init(get_system_memory(), RAM_size, boot_devices, kernel_filename,
>                  kernel_cmdline, initrd_filename, cpu_model, &hwdefs[1]);
>  }
>
>  /* Niagara hardware initialisation */
> -static void niagara_init(ram_addr_t RAM_size,
> -                         const char *boot_devices,
> -                         const char *kernel_filename, const char *kernel_cmdline,
> -                         const char *initrd_filename, const char *cpu_model)
> -{
> +static void niagara_init(QEMUMachineInitArgs *args)
> +{
> +    ram_addr_t RAM_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_devices = args->boot_device;
>      sun4uv_init(get_system_memory(), RAM_size, boot_devices, kernel_filename,
>                  kernel_cmdline, initrd_filename, cpu_model, &hwdefs[2]);
>  }
> diff --git a/hw/tosa.c b/hw/tosa.c
> index 297a8c2..512278c 100644
> --- a/hw/tosa.c
> +++ b/hw/tosa.c
> @@ -205,11 +205,12 @@ static struct arm_boot_info tosa_binfo = {
>      .ram_size = 0x04000000,
>  };
>
> -static void tosa_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void tosa_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      MemoryRegion *address_space_mem = get_system_memory();
>      MemoryRegion *rom = g_new(MemoryRegion, 1);
>      PXA2xxState *mpu;
> diff --git a/hw/versatilepb.c b/hw/versatilepb.c
> index 7b1b025..756ec29 100644
> --- a/hw/versatilepb.c
> +++ b/hw/versatilepb.c
> @@ -348,22 +348,28 @@ static void versatile_init(ram_addr_t ram_size,
>      arm_load_kernel(cpu, &versatile_binfo);
>  }
>
> -static void vpb_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void vpb_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      versatile_init(ram_size,
>                     boot_device,
>                     kernel_filename, kernel_cmdline,
>                     initrd_filename, cpu_model, 0x183);
>  }
>
> -static void vab_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void vab_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      versatile_init(ram_size,
>                     boot_device,
>                     kernel_filename, kernel_cmdline,
> diff --git a/hw/vexpress.c b/hw/vexpress.c
> index 3596d1e..36503d6 100644
> --- a/hw/vexpress.c
> +++ b/hw/vexpress.c
> @@ -467,25 +467,27 @@ static void vexpress_common_init(const VEDBoardInfo *daughterboard,
>      arm_load_kernel(arm_env_get_cpu(first_cpu), &vexpress_binfo);
>  }
>
> -static void vexpress_a9_init(ram_addr_t ram_size,
> -                             const char *boot_device,
> -                             const char *kernel_filename,
> -                             const char *kernel_cmdline,
> -                             const char *initrd_filename,
> -                             const char *cpu_model)
> +static void vexpress_a9_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      vexpress_common_init(&a9_daughterboard,
>                           ram_size, boot_device, kernel_filename,
>                           kernel_cmdline, initrd_filename, cpu_model);
>  }
>
> -static void vexpress_a15_init(ram_addr_t ram_size,
> -                              const char *boot_device,
> -                              const char *kernel_filename,
> -                              const char *kernel_cmdline,
> -                              const char *initrd_filename,
> -                              const char *cpu_model)
> +static void vexpress_a15_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      vexpress_common_init(&a15_daughterboard,
>                           ram_size, boot_device, kernel_filename,
>                           kernel_cmdline, initrd_filename, cpu_model);
> diff --git a/hw/virtex_ml507.c b/hw/virtex_ml507.c
> index 79bc0d1..a09b27a 100644
> --- a/hw/virtex_ml507.c
> +++ b/hw/virtex_ml507.c
> @@ -183,12 +183,12 @@ static int xilinx_load_device_tree(target_phys_addr_t addr,
>      return fdt_size;
>  }
>
> -static void virtex_init(ram_addr_t ram_size,
> -                        const char *boot_device,
> -                        const char *kernel_filename,
> -                        const char *kernel_cmdline,
> -                        const char *initrd_filename, const char *cpu_model)
> +static void virtex_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
>      MemoryRegion *address_space_mem = get_system_memory();
>      DeviceState *dev;
>      PowerPCCPU *cpu;
> diff --git a/hw/xen_machine_pv.c b/hw/xen_machine_pv.c
> index 4b72aa7..4264703 100644
> --- a/hw/xen_machine_pv.c
> +++ b/hw/xen_machine_pv.c
> @@ -29,13 +29,12 @@
>  #include "xen_domainbuild.h"
>  #include "blockdev.h"
>
> -static void xen_init_pv(ram_addr_t ram_size,
> -                       const char *boot_device,
> -                       const char *kernel_filename,
> -                       const char *kernel_cmdline,
> -                       const char *initrd_filename,
> -                       const char *cpu_model)
> +static void xen_init_pv(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      X86CPU *cpu;
>      CPUX86State *env;
>      DriveInfo *dinfo;
> diff --git a/hw/xilinx_zynq.c b/hw/xilinx_zynq.c
> index fd46ba2..c55dafb 100644
> --- a/hw/xilinx_zynq.c
> +++ b/hw/xilinx_zynq.c
> @@ -77,10 +77,13 @@ static inline void zynq_init_spi_flashes(uint32_t base_addr, qemu_irq irq)
>
>  }
>
> -static void zynq_init(ram_addr_t ram_size, const char *boot_device,
> -                        const char *kernel_filename, const char *kernel_cmdline,
> -                        const char *initrd_filename, const char *cpu_model)
> +static void zynq_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      ARMCPU *cpu;
>      MemoryRegion *address_space_mem = get_system_memory();
>      MemoryRegion *ext_ram = g_new(MemoryRegion, 1);
> diff --git a/hw/xtensa_lx60.c b/hw/xtensa_lx60.c
> index 3653f65..1fd2c47 100644
> --- a/hw/xtensa_lx60.c
> +++ b/hw/xtensa_lx60.c
> @@ -268,11 +268,14 @@ static void lx_init(const LxBoardDesc *board,
>      }
>  }
>
> -static void xtensa_lx60_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void xtensa_lx60_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      static const LxBoardDesc lx60_board = {
>          .flash_size = 0x400000,
>          .flash_sector_size = 0x10000,
> @@ -283,11 +286,14 @@ static void xtensa_lx60_init(ram_addr_t ram_size,
>              initrd_filename, cpu_model);
>  }
>
> -static void xtensa_lx200_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void xtensa_lx200_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      static const LxBoardDesc lx200_board = {
>          .flash_size = 0x1000000,
>          .flash_sector_size = 0x20000,
> diff --git a/hw/xtensa_sim.c b/hw/xtensa_sim.c
> index 831460b..2e846d8 100644
> --- a/hw/xtensa_sim.c
> +++ b/hw/xtensa_sim.c
> @@ -96,11 +96,14 @@ static void sim_init(ram_addr_t ram_size,
>      }
>  }
>
> -static void xtensa_sim_init(ram_addr_t ram_size,
> -                     const char *boot_device,
> -                     const char *kernel_filename, const char *kernel_cmdline,
> -                     const char *initrd_filename, const char *cpu_model)
> +static void xtensa_sim_init(QEMUMachineInitArgs *args)
>  {
> +    ram_addr_t ram_size = args->ram_size;
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
> +    const char *boot_device = args->boot_device;
>      if (!cpu_model) {
>          cpu_model = XTENSA_DEFAULT_CPU_MODEL;
>      }
> diff --git a/hw/z2.c b/hw/z2.c
> index 076fad2..f62b806 100644
> --- a/hw/z2.c
> +++ b/hw/z2.c
> @@ -295,11 +295,12 @@ static TypeInfo aer915_info = {
>      .class_init    = aer915_class_init,
>  };
>
> -static void z2_init(ram_addr_t ram_size,
> -                const char *boot_device,
> -                const char *kernel_filename, const char *kernel_cmdline,
> -                const char *initrd_filename, const char *cpu_model)
> +static void z2_init(QEMUMachineInitArgs *args)
>  {
> +    const char *cpu_model = args->cpu_model;
> +    const char *kernel_filename = args->kernel_filename;
> +    const char *kernel_cmdline = args->kernel_cmdline;
> +    const char *initrd_filename = args->initrd_filename;
>      MemoryRegion *address_space_mem = get_system_memory();
>      uint32_t sector_len = 0x10000;
>      PXA2xxState *mpu;
> diff --git a/vl.c b/vl.c
> index 5b357a3..ee3c43a 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -3638,8 +3638,13 @@ int main(int argc, char **argv, char **envp)
>
>      qdev_machine_init();
>
> -    machine->init(ram_size, boot_devices,
> -                  kernel_filename, kernel_cmdline, initrd_filename, cpu_model);
> +    QEMUMachineInitArgs args = { .ram_size = ram_size,
> +                                 .boot_device = boot_devices,
> +                                 .kernel_filename = kernel_filename,
> +                                 .kernel_cmdline = kernel_cmdline,
> +                                 .initrd_filename = initrd_filename,
> +                                 .cpu_model = cpu_model };
> +    machine->init(&args);
>
>      cpu_synchronize_all_post_init();
>
> --
> 1.7.11.4
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 20 17:22:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Oct 2012 17:22:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPcjp-0005ZO-Dx; Sat, 20 Oct 2012 17:21:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPcjn-0005ZJ-Mz
	for xen-devel@lists.xen.org; Sat, 20 Oct 2012 17:21:27 +0000
Received: from [85.158.139.211:10821] by server-14.bemta-5.messagelabs.com id
	ED/41-24068-69DD2805; Sat, 20 Oct 2012 17:21:26 +0000
X-Env-Sender: peter.maloney@brockmann-consult.de
X-Msg-Ref: server-8.tower-206.messagelabs.com!1350753685!23073816!1
X-Originating-IP: [212.227.126.187]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xODcgPT4gODg4MzI=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xODcgPT4gODg4MzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5006 invoked from network); 20 Oct 2012 17:21:25 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.126.187)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Oct 2012 17:21:25 -0000
Received: from [192.168.179.201] (hmbg-5f7652b2.pool.mediaWays.net
	[95.118.82.178])
	by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis)
	id 0McRqW-1Th9cT3UvI-00IFVR; Sat, 20 Oct 2012 19:21:18 +0200
Message-ID: <5082DD8C.2030608@brockmann-consult.de>
Date: Sat, 20 Oct 2012 19:21:16 +0200
From: Peter Maloney 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120825 Thunderbird/15.0
MIME-Version: 1.0
To: xen-devel@lists.xen.org
X-Provags-ID: V02:K0:J2PM0Ck6kEZPTk3ijVXyb8JkhhAXFj96a00C3U2u6fz
	LiOmkCPmWBW2lmFk261eMuO/BSaV421XmKlsv9BrRNQy6Zf6F/
	gV/QxceGeWY8jUirNRo8c8XTqX/JA4MsnQJJrO8Eb/ZZkj4v8+
	C7U4+HvLFHGwKoXSMBY5qle1R2MwZASStFJjSe4El+uV+96UPb
	QjZPPlisyLgH14IstBOScT5JYIPRRJh/eEwri9bGbVYf79ih66
	W5g4RPKHaPyVN0Mpr4iLlwmh6CyakTtO772t1wX334on0g/rzB
	LwWJ5u2fE0g8O3IZkUUXwz6wBFNCRgM28Ok8K8r+NPxZCbRsct
	ngmcwpA1wBJDFsowvcnekueQV+7SAq70bMgNDHe5Te9CnbBBgA
	LZiq+P52BKonw==
Cc: Andres Lagar-Cavilla 
Subject: [Xen-devel] xen-unstable,
 winxp32 very poor performance on AMD FX-8150,
 I bisected and changeset is 24770:7f79475d3de7
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I ran a bisect to find out when Windows XP 32 bit becomes unusably slow.
And I found the changeset that caused it.

==========
The problem:
==========

Windows 8 64 bit and 32 bit run fast and fine in the newest xen versions.

Windows XP 32 bit runs unusably slow in anything new that I built from
xen-unstable, but runs fast in 4.1.2 and 4.1.3 stable. While it is
running slow, "xm top" or "xl top" show cpu usage around 650% for the domu.

The bug might be AMD specific. I'm running an AMD FX-8150.

==========
The result:
==========

good: 24769:730f6ed72d70
bad: 24770:7f79475d3de7

The change was 8 months ago

changeset:   24770:7f79475d3de7
user:        Andres Lagar-Cavilla 
date:        Fri Feb 10 16:07:07 2012 +0000
summary:     x86/mm: Make p2m lookups fully synchronized wrt modifications

==========
My hardware:
==========

AMD FX-8150
990 FX chipset

Here's a dmidecode: http://pastebin.com/XUZjmiVz

==========
My kernel:
==========

I compiled the for-linus branch of cmason's linux-btrfs git repo, around
August 11th (
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git
for-linus )

peter:~/xen # uname -a
Linux peter 3.5.0-1-default+ #3 SMP Sat Aug 11 21:30:44 CEST 2012 x86_64
x86_64 x86_64 GNU/Linux

Here's the kernel config: http://pastebin.com/1GQbiFZE (only weird thing
I set was CONFIG_NR_CPUS=16 for no particular reason; default was 512 or
256)

==========
My Windows XP VM config:
==========

# grep -vE "^#|^$" windowsxp2
name="windowsxp2"
description="None"
uuid="292b0651-9913-2459-5cfa-fb828f9c4314"
memory=4096
maxmem=4096
vcpus=7
on_poweroff="destroy"
on_reboot="restart"
on_crash="destroy"
localtime=1
keymap="en-us"
builder="hvm"
device_model="/usr/lib/xen/bin/qemu-dm"
kernel="/usr/lib/xen/boot/hvmloader"
boot="c"
disk=[ 'phy:/dev/data/winxp1_disk1,hda,w',
'file:/var/lib/xen/winxp1_disk2.raw,hdb,w', ]
vif=[ 'mac=00:16:3e:4e:c5:0c,bridge=br0,model=e1000', ]
sdl=0
vnc=1
vncunused=1
audio=0
soundhw='es1370'
viridian=1
usb=1
acpi=1
apic=0
pae=1
usbdevice='tablet'
serial="pty"
stdvga=1
gfx_passthru=0
# this is an AMD Radeon HD 6770 and it's HDMI audio, and 2 USB ports
pci = [ '04:00.0' , '04:00.1' , '00:12.0' , '00:12.2' ]
xen_platform_pci=1
pci_msitranslate=1


The Windows 8 32 and 64 bit configs I used are the same except changed
mac address, and different disk.

Whether or not I use sound or PCI passthrough doesn't (significantly)
affect performance.


==========
my build process, including how to hack the build so it actually compiles:
==========

# Install older libyajl-devel
    
    On openSUSE, this would be:
        
        zypper install libyajl1-devel

# Delete everything (except .hg)... prevents unclean builds from
breaking things. make distclean is not enough for very many builds.
cd xen-unstable.hg
rm -rf *
# If you have permission denied errors (caused by running make install
as root earlier), make sure to use chown and run rm again, or builds
will fail.

# Check out the revision
hg update --clean "${build}"

# hack up a troublesome Makefile that prevents builds
vim tools/libxl/Makefile
    add "-lyajl":
        at the end of all 4 "$(CC) ..." lines
        to LIBXL_LIBS
        to LIBXLU_LIBS
        to LIBUUID_LIBS
    
    (don't know which ones are important... but it works with all of it)

make distclean >/tmp/xen.distclean.log 2>&1 ; status=$? ; echo $status

if [ -e configure ]; then
    ./configure
else
    touch .config
fi
            
make dist >/tmp/xen.dist.log 2>&1 ; status=$? ; echo $status


==========
my install process
==========

To install the build, it's important to clean out old lib files...
uninstall doesn't get them all. If you miss these, xm, xl, etc. may fail
due to shared library issues.

Also, "make uninstall" deletes important system files it should not
(kernel, kernel modules, vm disks).

As it says in the "make help":
  uninstall        - attempt to remove installed Xen tools
                     (use with extreme care!)

Here is my process to solve the uninstall issues:
http://pastebin.com/nXCavFTp

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 20 17:22:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Oct 2012 17:22:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPcjp-0005ZO-Dx; Sat, 20 Oct 2012 17:21:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPcjn-0005ZJ-Mz
	for xen-devel@lists.xen.org; Sat, 20 Oct 2012 17:21:27 +0000
Received: from [85.158.139.211:10821] by server-14.bemta-5.messagelabs.com id
	ED/41-24068-69DD2805; Sat, 20 Oct 2012 17:21:26 +0000
X-Env-Sender: peter.maloney@brockmann-consult.de
X-Msg-Ref: server-8.tower-206.messagelabs.com!1350753685!23073816!1
X-Originating-IP: [212.227.126.187]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xODcgPT4gODg4MzI=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xODcgPT4gODg4MzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5006 invoked from network); 20 Oct 2012 17:21:25 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.126.187)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Oct 2012 17:21:25 -0000
Received: from [192.168.179.201] (hmbg-5f7652b2.pool.mediaWays.net
	[95.118.82.178])
	by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis)
	id 0McRqW-1Th9cT3UvI-00IFVR; Sat, 20 Oct 2012 19:21:18 +0200
Message-ID: <5082DD8C.2030608@brockmann-consult.de>
Date: Sat, 20 Oct 2012 19:21:16 +0200
From: Peter Maloney 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120825 Thunderbird/15.0
MIME-Version: 1.0
To: xen-devel@lists.xen.org
X-Provags-ID: V02:K0:J2PM0Ck6kEZPTk3ijVXyb8JkhhAXFj96a00C3U2u6fz
	LiOmkCPmWBW2lmFk261eMuO/BSaV421XmKlsv9BrRNQy6Zf6F/
	gV/QxceGeWY8jUirNRo8c8XTqX/JA4MsnQJJrO8Eb/ZZkj4v8+
	C7U4+HvLFHGwKoXSMBY5qle1R2MwZASStFJjSe4El+uV+96UPb
	QjZPPlisyLgH14IstBOScT5JYIPRRJh/eEwri9bGbVYf79ih66
	W5g4RPKHaPyVN0Mpr4iLlwmh6CyakTtO772t1wX334on0g/rzB
	LwWJ5u2fE0g8O3IZkUUXwz6wBFNCRgM28Ok8K8r+NPxZCbRsct
	ngmcwpA1wBJDFsowvcnekueQV+7SAq70bMgNDHe5Te9CnbBBgA
	LZiq+P52BKonw==
Cc: Andres Lagar-Cavilla 
Subject: [Xen-devel] xen-unstable,
 winxp32 very poor performance on AMD FX-8150,
 I bisected and changeset is 24770:7f79475d3de7
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I ran a bisect to find out when Windows XP 32 bit becomes unusably slow.
And I found the changeset that caused it.

==========
The problem:
==========

Windows 8 64 bit and 32 bit run fast and fine in the newest xen versions.

Windows XP 32 bit runs unusably slow in anything new that I built from
xen-unstable, but runs fast in 4.1.2 and 4.1.3 stable. While it is
running slow, "xm top" or "xl top" show cpu usage around 650% for the domu.

The bug might be AMD specific. I'm running an AMD FX-8150.

==========
The result:
==========

good: 24769:730f6ed72d70
bad: 24770:7f79475d3de7

The change was 8 months ago

changeset:   24770:7f79475d3de7
user:        Andres Lagar-Cavilla 
date:        Fri Feb 10 16:07:07 2012 +0000
summary:     x86/mm: Make p2m lookups fully synchronized wrt modifications

==========
My hardware:
==========

AMD FX-8150
990 FX chipset

Here's a dmidecode: http://pastebin.com/XUZjmiVz

==========
My kernel:
==========

I compiled the for-linus branch of cmason's linux-btrfs git repo, around
August 11th (
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git
for-linus )

peter:~/xen # uname -a
Linux peter 3.5.0-1-default+ #3 SMP Sat Aug 11 21:30:44 CEST 2012 x86_64
x86_64 x86_64 GNU/Linux

Here's the kernel config: http://pastebin.com/1GQbiFZE (only weird thing
I set was CONFIG_NR_CPUS=16 for no particular reason; default was 512 or
256)

==========
My Windows XP VM config:
==========

# grep -vE "^#|^$" windowsxp2
name="windowsxp2"
description="None"
uuid="292b0651-9913-2459-5cfa-fb828f9c4314"
memory=4096
maxmem=4096
vcpus=7
on_poweroff="destroy"
on_reboot="restart"
on_crash="destroy"
localtime=1
keymap="en-us"
builder="hvm"
device_model="/usr/lib/xen/bin/qemu-dm"
kernel="/usr/lib/xen/boot/hvmloader"
boot="c"
disk=[ 'phy:/dev/data/winxp1_disk1,hda,w',
'file:/var/lib/xen/winxp1_disk2.raw,hdb,w', ]
vif=[ 'mac=00:16:3e:4e:c5:0c,bridge=br0,model=e1000', ]
sdl=0
vnc=1
vncunused=1
audio=0
soundhw='es1370'
viridian=1
usb=1
acpi=1
apic=0
pae=1
usbdevice='tablet'
serial="pty"
stdvga=1
gfx_passthru=0
# this is an AMD Radeon HD 6770 and it's HDMI audio, and 2 USB ports
pci = [ '04:00.0' , '04:00.1' , '00:12.0' , '00:12.2' ]
xen_platform_pci=1
pci_msitranslate=1


The Windows 8 32 and 64 bit configs I used are the same except changed
mac address, and different disk.

Whether or not I use sound or PCI passthrough doesn't (significantly)
affect performance.


==========
my build process, including how to hack the build so it actually compiles:
==========

# Install older libyajl-devel
    
    On openSUSE, this would be:
        
        zypper install libyajl1-devel

# Delete everything (except .hg)... prevents unclean builds from
breaking things. make distclean is not enough for very many builds.
cd xen-unstable.hg
rm -rf *
# If you have permission denied errors (caused by running make install
as root earlier), make sure to use chown and run rm again, or builds
will fail.

# Check out the revision
hg update --clean "${build}"

# hack up a troublesome Makefile that prevents builds
vim tools/libxl/Makefile
    add "-lyajl":
        at the end of all 4 "$(CC) ..." lines
        to LIBXL_LIBS
        to LIBXLU_LIBS
        to LIBUUID_LIBS
    
    (don't know which ones are important... but it works with all of it)

make distclean >/tmp/xen.distclean.log 2>&1 ; status=$? ; echo $status

if [ -e configure ]; then
    ./configure
else
    touch .config
fi
            
make dist >/tmp/xen.dist.log 2>&1 ; status=$? ; echo $status


==========
my install process
==========

To install the build, it's important to clean out old lib files...
uninstall doesn't get them all. If you miss these, xm, xl, etc. may fail
due to shared library issues.

Also, "make uninstall" deletes important system files it should not
(kernel, kernel modules, vm disks).

As it says in the "make help":
  uninstall        - attempt to remove installed Xen tools
                     (use with extreme care!)

Here is my process to solve the uninstall issues:
http://pastebin.com/nXCavFTp

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 20 18:41:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Oct 2012 18:41:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPdyR-0005zX-BS; Sat, 20 Oct 2012 18:40:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPdyP-0005zS-Fl
	for xen-devel@lists.xen.org; Sat, 20 Oct 2012 18:40:37 +0000
Received: from [193.109.254.147:45508] by server-7.bemta-14.messagelabs.com id
	1E/13-24122-420F2805; Sat, 20 Oct 2012 18:40:36 +0000
X-Env-Sender: peter.maloney@brockmann-consult.de
X-Msg-Ref: server-4.tower-27.messagelabs.com!1350758433!10572460!1
X-Originating-IP: [212.227.17.8]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjE3LjggPT4gODI4NTc=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjE3LjggPT4gODI4NTc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24851 invoked from network); 20 Oct 2012 18:40:33 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.17.8)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Oct 2012 18:40:33 -0000
Received: from [192.168.179.201] (hmbg-5f7652b2.pool.mediaWays.net
	[95.118.82.178])
	by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis)
	id 0MINbz-1TSgVq04Kd-004EK2; Sat, 20 Oct 2012 20:40:33 +0200
Message-ID: <5082F01F.3050704@brockmann-consult.de>
Date: Sat, 20 Oct 2012 20:40:31 +0200
From: Peter Maloney 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120825 Thunderbird/15.0
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <5082DD8C.2030608@brockmann-consult.de>
In-Reply-To: <5082DD8C.2030608@brockmann-consult.de>
X-Provags-ID: V02:K0:ZWxlpAgT+D/KszwBuSLuphNNehjLWIIoV48vVqofe9u
	9sULEMcY7cnyTdWaeDxf62tH2L/OcZNIHJ7i0b//vcjpd/ZtgG
	R3PrYmEYC6HxVj/yvquo/6ijOHAX2BjxFf/l2YcfQDozRRfVa0
	pGh1MotLwTWqCyNqOVacFyKv/Y4SDPILzlvGbXRc4FG5hfIDWO
	/0gQ3XWrduDNV33qPNjg5Ra7C+yRjDg3WZVUaHjUk35dXJxXpB
	qguXXYn5cSnZcjw0yLwvq+Nh5eGRmlR/+47mmJxiagE16+c9y0
	Rd6sYQ9jkIIZNNViDa76jS+vfW8QAZVujXt1whgQp9qu2wZ2IK
	sRYUfuAJa4u9jxmvl2pSgLfFOY/G7f9+epVjTllQzKzW3Mc+qG
	TTevePPdeFfrQ==
Subject: Re: [Xen-devel] xen-unstable,
 winxp32 very poor performance on AMD FX-8150,
 I bisected and changeset is 24770:7f79475d3de7
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

And so Pasi suggested on IRC that I try with 2 vcpus, and in this
situation it still runs slow, but it's usably slow.

When it first boots, "xl top" shows pretty high cpu usage, and then it
goes down eventually and it's harder to notice it is slower than usual. 
By comparison, with 4-8 vcpus, it is unbearably slow, and would take you
probably 10 minutes to even log in, but also the cpu would go down over
time.

And also with 2 vcpus, in task manager, you can see the processes using
CPU seem to be using much more than they should. So when the cpu usage
is lower later on, while the system is still idle, a bunch of processes
are using 2 or 3% each adding up to 20-50% (fluctuating). And with 2
vcpus, the mouse seems faster.

And then I tested minecraft, which runs only 5-20 fps. So it's
definitely still slow, but usable for non-3d stuff.


On 10/20/2012 07:21 PM, Peter Maloney wrote:
> I ran a bisect to find out when Windows XP 32 bit becomes unusably slow.
> And I found the changeset that caused it.
>
> ==========
> The problem:
> ==========
>
> Windows 8 64 bit and 32 bit run fast and fine in the newest xen versions.
>
> Windows XP 32 bit runs unusably slow in anything new that I built from
> xen-unstable, but runs fast in 4.1.2 and 4.1.3 stable. While it is
> running slow, "xm top" or "xl top" show cpu usage around 650% for the domu.
>
> The bug might be AMD specific. I'm running an AMD FX-8150.
>
> ==========
> The result:
> ==========
>
> good: 24769:730f6ed72d70
> bad: 24770:7f79475d3de7
>
> The change was 8 months ago
>
> changeset:   24770:7f79475d3de7
> user:        Andres Lagar-Cavilla 
> date:        Fri Feb 10 16:07:07 2012 +0000
> summary:     x86/mm: Make p2m lookups fully synchronized wrt modifications
>
> ==========
> My hardware:
> ==========
>
> AMD FX-8150
> 990 FX chipset
>
> Here's a dmidecode: http://pastebin.com/XUZjmiVz
>
> ==========
> My kernel:
> ==========
>
> I compiled the for-linus branch of cmason's linux-btrfs git repo, around
> August 11th (
> git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git
> for-linus )
>
> peter:~/xen # uname -a
> Linux peter 3.5.0-1-default+ #3 SMP Sat Aug 11 21:30:44 CEST 2012 x86_64
> x86_64 x86_64 GNU/Linux
>
> Here's the kernel config: http://pastebin.com/1GQbiFZE (only weird thing
> I set was CONFIG_NR_CPUS=16 for no particular reason; default was 512 or
> 256)
>
> ==========
> My Windows XP VM config:
> ==========
>
> # grep -vE "^#|^$" windowsxp2
> name="windowsxp2"
> description="None"
> uuid="292b0651-9913-2459-5cfa-fb828f9c4314"
> memory=4096
> maxmem=4096
> vcpus=7
> on_poweroff="destroy"
> on_reboot="restart"
> on_crash="destroy"
> localtime=1
> keymap="en-us"
> builder="hvm"
> device_model="/usr/lib/xen/bin/qemu-dm"
> kernel="/usr/lib/xen/boot/hvmloader"
> boot="c"
> disk=[ 'phy:/dev/data/winxp1_disk1,hda,w',
> 'file:/var/lib/xen/winxp1_disk2.raw,hdb,w', ]
> vif=[ 'mac=00:16:3e:4e:c5:0c,bridge=br0,model=e1000', ]
> sdl=0
> vnc=1
> vncunused=1
> audio=0
> soundhw='es1370'
> viridian=1
> usb=1
> acpi=1
> apic=0
> pae=1
> usbdevice='tablet'
> serial="pty"
> stdvga=1
> gfx_passthru=0
> # this is an AMD Radeon HD 6770 and it's HDMI audio, and 2 USB ports
> pci = [ '04:00.0' , '04:00.1' , '00:12.0' , '00:12.2' ]
> xen_platform_pci=1
> pci_msitranslate=1
>
>
> The Windows 8 32 and 64 bit configs I used are the same except changed
> mac address, and different disk.
>
> Whether or not I use sound or PCI passthrough doesn't (significantly)
> affect performance.
>
>
> ==========
> my build process, including how to hack the build so it actually compiles:
> ==========
>
> # Install older libyajl-devel
>     
>     On openSUSE, this would be:
>         
>         zypper install libyajl1-devel
>
> # Delete everything (except .hg)... prevents unclean builds from
> breaking things. make distclean is not enough for very many builds.
> cd xen-unstable.hg
> rm -rf *
> # If you have permission denied errors (caused by running make install
> as root earlier), make sure to use chown and run rm again, or builds
> will fail.
>
> # Check out the revision
> hg update --clean "${build}"
>
> # hack up a troublesome Makefile that prevents builds
> vim tools/libxl/Makefile
>     add "-lyajl":
>         at the end of all 4 "$(CC) ..." lines
>         to LIBXL_LIBS
>         to LIBXLU_LIBS
>         to LIBUUID_LIBS
>     
>     (don't know which ones are important... but it works with all of it)
>
> make distclean >/tmp/xen.distclean.log 2>&1 ; status=$? ; echo $status
>
> if [ -e configure ]; then
>     ./configure
> else
>     touch .config
> fi
>             
> make dist >/tmp/xen.dist.log 2>&1 ; status=$? ; echo $status
>
>
> ==========
> my install process
> ==========
>
> To install the build, it's important to clean out old lib files...
> uninstall doesn't get them all. If you miss these, xm, xl, etc. may fail
> due to shared library issues.
>
> Also, "make uninstall" deletes important system files it should not
> (kernel, kernel modules, vm disks).
>
> As it says in the "make help":
>   uninstall        - attempt to remove installed Xen tools
>                      (use with extreme care!)
>
> Here is my process to solve the uninstall issues:
> http://pastebin.com/nXCavFTp
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 20 18:41:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Oct 2012 18:41:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPdyR-0005zX-BS; Sat, 20 Oct 2012 18:40:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPdyP-0005zS-Fl
	for xen-devel@lists.xen.org; Sat, 20 Oct 2012 18:40:37 +0000
Received: from [193.109.254.147:45508] by server-7.bemta-14.messagelabs.com id
	1E/13-24122-420F2805; Sat, 20 Oct 2012 18:40:36 +0000
X-Env-Sender: peter.maloney@brockmann-consult.de
X-Msg-Ref: server-4.tower-27.messagelabs.com!1350758433!10572460!1
X-Originating-IP: [212.227.17.8]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjE3LjggPT4gODI4NTc=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjE3LjggPT4gODI4NTc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24851 invoked from network); 20 Oct 2012 18:40:33 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.17.8)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Oct 2012 18:40:33 -0000
Received: from [192.168.179.201] (hmbg-5f7652b2.pool.mediaWays.net
	[95.118.82.178])
	by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis)
	id 0MINbz-1TSgVq04Kd-004EK2; Sat, 20 Oct 2012 20:40:33 +0200
Message-ID: <5082F01F.3050704@brockmann-consult.de>
Date: Sat, 20 Oct 2012 20:40:31 +0200
From: Peter Maloney 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120825 Thunderbird/15.0
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <5082DD8C.2030608@brockmann-consult.de>
In-Reply-To: <5082DD8C.2030608@brockmann-consult.de>
X-Provags-ID: V02:K0:ZWxlpAgT+D/KszwBuSLuphNNehjLWIIoV48vVqofe9u
	9sULEMcY7cnyTdWaeDxf62tH2L/OcZNIHJ7i0b//vcjpd/ZtgG
	R3PrYmEYC6HxVj/yvquo/6ijOHAX2BjxFf/l2YcfQDozRRfVa0
	pGh1MotLwTWqCyNqOVacFyKv/Y4SDPILzlvGbXRc4FG5hfIDWO
	/0gQ3XWrduDNV33qPNjg5Ra7C+yRjDg3WZVUaHjUk35dXJxXpB
	qguXXYn5cSnZcjw0yLwvq+Nh5eGRmlR/+47mmJxiagE16+c9y0
	Rd6sYQ9jkIIZNNViDa76jS+vfW8QAZVujXt1whgQp9qu2wZ2IK
	sRYUfuAJa4u9jxmvl2pSgLfFOY/G7f9+epVjTllQzKzW3Mc+qG
	TTevePPdeFfrQ==
Subject: Re: [Xen-devel] xen-unstable,
 winxp32 very poor performance on AMD FX-8150,
 I bisected and changeset is 24770:7f79475d3de7
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

And so Pasi suggested on IRC that I try with 2 vcpus, and in this
situation it still runs slow, but it's usably slow.

When it first boots, "xl top" shows pretty high cpu usage, and then it
goes down eventually and it's harder to notice it is slower than usual. 
By comparison, with 4-8 vcpus, it is unbearably slow, and would take you
probably 10 minutes to even log in, but also the cpu would go down over
time.

And also with 2 vcpus, in task manager, you can see the processes using
CPU seem to be using much more than they should. So when the cpu usage
is lower later on, while the system is still idle, a bunch of processes
are using 2 or 3% each adding up to 20-50% (fluctuating). And with 2
vcpus, the mouse seems faster.

And then I tested minecraft, which runs only 5-20 fps. So it's
definitely still slow, but usable for non-3d stuff.


On 10/20/2012 07:21 PM, Peter Maloney wrote:
> I ran a bisect to find out when Windows XP 32 bit becomes unusably slow.
> And I found the changeset that caused it.
>
> ==========
> The problem:
> ==========
>
> Windows 8 64 bit and 32 bit run fast and fine in the newest xen versions.
>
> Windows XP 32 bit runs unusably slow in anything new that I built from
> xen-unstable, but runs fast in 4.1.2 and 4.1.3 stable. While it is
> running slow, "xm top" or "xl top" show cpu usage around 650% for the domu.
>
> The bug might be AMD specific. I'm running an AMD FX-8150.
>
> ==========
> The result:
> ==========
>
> good: 24769:730f6ed72d70
> bad: 24770:7f79475d3de7
>
> The change was 8 months ago
>
> changeset:   24770:7f79475d3de7
> user:        Andres Lagar-Cavilla 
> date:        Fri Feb 10 16:07:07 2012 +0000
> summary:     x86/mm: Make p2m lookups fully synchronized wrt modifications
>
> ==========
> My hardware:
> ==========
>
> AMD FX-8150
> 990 FX chipset
>
> Here's a dmidecode: http://pastebin.com/XUZjmiVz
>
> ==========
> My kernel:
> ==========
>
> I compiled the for-linus branch of cmason's linux-btrfs git repo, around
> August 11th (
> git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git
> for-linus )
>
> peter:~/xen # uname -a
> Linux peter 3.5.0-1-default+ #3 SMP Sat Aug 11 21:30:44 CEST 2012 x86_64
> x86_64 x86_64 GNU/Linux
>
> Here's the kernel config: http://pastebin.com/1GQbiFZE (only weird thing
> I set was CONFIG_NR_CPUS=16 for no particular reason; default was 512 or
> 256)
>
> ==========
> My Windows XP VM config:
> ==========
>
> # grep -vE "^#|^$" windowsxp2
> name="windowsxp2"
> description="None"
> uuid="292b0651-9913-2459-5cfa-fb828f9c4314"
> memory=4096
> maxmem=4096
> vcpus=7
> on_poweroff="destroy"
> on_reboot="restart"
> on_crash="destroy"
> localtime=1
> keymap="en-us"
> builder="hvm"
> device_model="/usr/lib/xen/bin/qemu-dm"
> kernel="/usr/lib/xen/boot/hvmloader"
> boot="c"
> disk=[ 'phy:/dev/data/winxp1_disk1,hda,w',
> 'file:/var/lib/xen/winxp1_disk2.raw,hdb,w', ]
> vif=[ 'mac=00:16:3e:4e:c5:0c,bridge=br0,model=e1000', ]
> sdl=0
> vnc=1
> vncunused=1
> audio=0
> soundhw='es1370'
> viridian=1
> usb=1
> acpi=1
> apic=0
> pae=1
> usbdevice='tablet'
> serial="pty"
> stdvga=1
> gfx_passthru=0
> # this is an AMD Radeon HD 6770 and it's HDMI audio, and 2 USB ports
> pci = [ '04:00.0' , '04:00.1' , '00:12.0' , '00:12.2' ]
> xen_platform_pci=1
> pci_msitranslate=1
>
>
> The Windows 8 32 and 64 bit configs I used are the same except changed
> mac address, and different disk.
>
> Whether or not I use sound or PCI passthrough doesn't (significantly)
> affect performance.
>
>
> ==========
> my build process, including how to hack the build so it actually compiles:
> ==========
>
> # Install older libyajl-devel
>     
>     On openSUSE, this would be:
>         
>         zypper install libyajl1-devel
>
> # Delete everything (except .hg)... prevents unclean builds from
> breaking things. make distclean is not enough for very many builds.
> cd xen-unstable.hg
> rm -rf *
> # If you have permission denied errors (caused by running make install
> as root earlier), make sure to use chown and run rm again, or builds
> will fail.
>
> # Check out the revision
> hg update --clean "${build}"
>
> # hack up a troublesome Makefile that prevents builds
> vim tools/libxl/Makefile
>     add "-lyajl":
>         at the end of all 4 "$(CC) ..." lines
>         to LIBXL_LIBS
>         to LIBXLU_LIBS
>         to LIBUUID_LIBS
>     
>     (don't know which ones are important... but it works with all of it)
>
> make distclean >/tmp/xen.distclean.log 2>&1 ; status=$? ; echo $status
>
> if [ -e configure ]; then
>     ./configure
> else
>     touch .config
> fi
>             
> make dist >/tmp/xen.dist.log 2>&1 ; status=$? ; echo $status
>
>
> ==========
> my install process
> ==========
>
> To install the build, it's important to clean out old lib files...
> uninstall doesn't get them all. If you miss these, xm, xl, etc. may fail
> due to shared library issues.
>
> Also, "make uninstall" deletes important system files it should not
> (kernel, kernel modules, vm disks).
>
> As it says in the "make help":
>   uninstall        - attempt to remove installed Xen tools
>                      (use with extreme care!)
>
> Here is my process to solve the uninstall issues:
> http://pastebin.com/nXCavFTp
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 20 19:52:50 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Oct 2012 19:52:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPf5m-0006K7-08; Sat, 20 Oct 2012 19:52:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPdrp-0005y5-Oh; Sat, 20 Oct 2012 18:33:50 +0000
Received: from [85.158.143.99:29169] by server-2.bemta-4.messagelabs.com id
	74/B8-22268-C8EE2805; Sat, 20 Oct 2012 18:33:48 +0000
X-Env-Sender: kks.kbase@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1350758027!34280861!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26045 invoked from network); 20 Oct 2012 18:33:47 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Oct 2012 18:33:47 -0000
Received: by mail-bk0-f45.google.com with SMTP id jf3so523169bkc.32
	for ; Sat, 20 Oct 2012 11:33:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=HsWuhbFkUIRLLMJtOazJtfaNSrfmalFkd/yjCbU99Uo=;
	b=i6r1RALjc+BnUouuAm7KyZ5FaB2Nw2YrUElZTejjEg3iQ5ThYwk/PLxrNbsNYDSfYG
	Ougn7FzzF2W1aZGeb7Ae7wiZXl2NEXlc9RXyXDvDgZzMSOseoXzvnDlx0Jyy7eU6Mif4
	KrmECq8f53Oqv03C0oTqAZlRZeLOVvFthZ79YjhBwBqJstgDLcaCwmOsd88TBC+g/kAw
	i8XP5GDNyx2ip6FGXIemojYqVgjBO1lqWQo2Llf3jldZLlbeykwGv27ML8sW2EXmfc/A
	5wcvHcky52zrBCTlZx26E8OOAszpMAV0RM29cjjNyrnZ3lxtP18KdLpBeIPcax42MNrR
	L9Gg==
MIME-Version: 1.0
Received: by 10.204.130.152 with SMTP id t24mr1391387bks.138.1350758027420;
	Sat, 20 Oct 2012 11:33:47 -0700 (PDT)
Received: by 10.204.50.144 with HTTP; Sat, 20 Oct 2012 11:33:47 -0700 (PDT)
In-Reply-To: <20121019142100.GN26830@phenom.dumpdata.com>
References: 
	<1350466992.2460.47.camel@zakaz.uk.xensource.com>
	
	<1350568154.2460.151.camel@zakaz.uk.xensource.com>
	
	<20121019142100.GN26830@phenom.dumpdata.com>
Date: Sun, 21 Oct 2012 00:03:47 +0530
Message-ID: 
From: kk s 
To: Konrad Rzeszutek Wilk 
X-Mailman-Approved-At: Sat, 20 Oct 2012 19:52:16 +0000
Cc: "xen-users@lists.xen.org" ,
	xen-devel ,
	Ian Campbell ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [Xen-users] Fedora 17 Dom-U booting issue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0837250929567156950=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0837250929567156950==
Content-Type: multipart/alternative; boundary=000e0ce0b1ae66e4c404cc81dcd2

--000e0ce0b1ae66e4c404cc81dcd2
Content-Type: text/plain; charset=ISO-8859-1

Hi,

Looks like the serial='pty' parameter already passed which doesn't work.
Though I can't add do 'loglevel=8 initcall_debug console=ttyS0,115200
debug' since its Xen HVM and without booted the VM we can't add anything in
grub.conf file.

The default kernel that comes from Fedora iso is booting fine and this
latest kernel only having issue. I'll try with serial=pty later today and
provide you the result.

Fyi. The fedora version designed to install as pv-on-hvm itself which means
it uses xen network and disk devices. So I already tried to pass netfront
type and tried pci passthrough none of it helped.

I guess its something issue with Fedora kernel.


On Fri, Oct 19, 2012 at 7:51 PM, Konrad Rzeszutek Wilk <
konrad.wilk@oracle.com> wrote:

> On Thu, Oct 18, 2012 at 05:21:06PM +0100, Stefano Stabellini wrote:
> > On Thu, 18 Oct 2012, Ian Campbell wrote:
> > > On Thu, 2012-10-18 at 14:42 +0100, Stefano Stabellini wrote:
> > > > On Wed, 17 Oct 2012, Ian Campbell wrote:
> > > > > Adding xen-devel and the relevant maintainers.
> > > > >
> > > > > On Tue, 2012-10-16 at 20:24 +0100, kk s wrote:
> > > > > > Hi Folks,
> > > > > >
> > > > > >
> > > > > > I have upgraded Fedora 16 to 17 on one of Xen HVM Dom-U and it
> refuses
> > > > > > to boot fine and getting the below error on console,
> > > > > >
> > > > > >
> > > > > > --------
> > > > > > Booting 'Fedora (3.6.1-1.fc17.x86_64)'
> > > > > >
> > > > > >
> > > > > > Loading Fedora (3.6.1-1.fc17.x86_64)
> > > > > > Loading initial ramdisk ...
> > > > > > [   0.000000] Cannot get hvm parameter 18: -22!
> > > > >
> > > > > HVM parameter 18 is HVM_PARAM_CONSOLE_EVTCHN.
> > > >
> > > > -22 is EINVAL, that Xen would return only if:
> > > >
> > > > - the requested parameter is out of range
> > > > this is not the case, 18 < 30
> > >
> > > The hypervisor here is 3.4.3 where the largest hvm param is:
> > > $ grep define.HVM_PARAM
> xen-3.4-testing.hg/xen/include/public/hvm/params.h | sort -k3 -n | tail -n 3
> > > #define HVM_PARAM_ACPI_S_STATE 14
> > > #define HVM_PARAM_VM86_TSS     15
> > > #define HVM_PARAM_VPT_ALIGN    16
> >
> > OK, we know that the console is not working because it is not provided
> > by the hypervisor.
> > However that shouldn't prevent the domain from booting, the emulated
> > serial should work fine.
>
> Maybe it does? Mr. KK can you boot your guest with this in guest config:
>
> serial='pty'
>
> and on your Linux line, do 'loglevel=8 initcall_debug console=ttyS0,115200
> debug' please?
>

--000e0ce0b1ae66e4c404cc81dcd2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

Looks like the=A0serial=3D'pty' parameter al=
ready passed which doesn't work. Though I can't add=A0do 'logle=
vel=3D8 initcall_debug console=3DttyS0,115200 debug' since its Xen HVM =
and without booted the VM we can't add anything in grub.conf file.


The default kernel that comes from Fedora iso is booting fine=
 and this latest kernel only having issue. I'll try with serial=3Dpty l=
ater today and provide you the result.

Fyi. The fe=
dora version designed to install as pv-on-hvm itself which means it uses xe=
n network and disk devices. So I already tried to pass netfront type and tr=
ied pci passthrough none of it helped.



I guess its something issue with Fedora kernel.


On Fri, Oct 19, 2012=
 at 7:51 PM, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:


On T=
hu, Oct 18, 2012 at 05:21:06PM +0100, Stefano Stabellini wrote:

> On Thu, 18 Oct 2012, Ian Campbell wrote:

> > On Thu, 2012-10-18 at 14:42 +0100, Stefano Stabellini wrote:

> > > On Wed, 17 Oct 2012, Ian Campbell wrote:

> > > > Adding xen-devel and the relevant maintainers.

> > > >

> > > > On Tue, 2012-10-16 at 20:24 +0100, kk s wrote:

> > > > > Hi Folks,

> > > > >

> > > > >

> > > > > I have upgraded Fedora 16 to 17 on one of Xen HVM =
Dom-U and it refuses

> > > > > to boot fine and getting the below error on consol=
e,

> > > > >

> > > > >

> > > > > --------

> > > > > Booting 'Fedora (3.6.1-1.fc17.x86_64)'

> > > > >

> > > > >

> > > > > Loading Fedora (3.6.1-1.fc17.x86_64)

> > > > > Loading initial ramdisk ...

> > > > > [ =A0 0.000000] Cannot get hvm parameter 18: -22!<=
br>
> > > >

> > > > HVM parameter 18 is HVM_PARAM_CONSOLE_EVTCHN.

> > >

> > > -22 is EINVAL, that Xen would return only if:

> > >

> > > - the requested parameter is out of range

> > > this is not the case, 18 < 30

> >

> > The hypervisor here is 3.4.3 where the largest hvm param is:

> > $ grep define.HVM_PARAM xen-3.4-testing.hg/xen/include/public/hvm=
/params.h | sort -k3 -n | tail -n 3

> > #define HVM_PARAM_ACPI_S_STATE 14

> > #define HVM_PARAM_VM86_TSS =A0 =A0 15

> > #define HVM_PARAM_VPT_ALIGN =A0 =A016

>

> OK, we know that the console is not working because it is not provided=


> by the hypervisor.

> However that shouldn't prevent the domain from booting, the emulat=
ed

> serial should work fine.




Maybe it does? Mr. KK can you boot your guest with this in gues=
t config:



serial=3D'pty'



and on your Linux line, do 'loglevel=3D8 initcall_debug console=3DttyS0=
,115200 debug' please?





--000e0ce0b1ae66e4c404cc81dcd2--


--===============0837250929567156950==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0837250929567156950==--


From xen-devel-bounces@lists.xen.org Sat Oct 20 19:52:50 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Oct 2012 19:52:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPf5m-0006K7-08; Sat, 20 Oct 2012 19:52:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPdrp-0005y5-Oh; Sat, 20 Oct 2012 18:33:50 +0000
Received: from [85.158.143.99:29169] by server-2.bemta-4.messagelabs.com id
	74/B8-22268-C8EE2805; Sat, 20 Oct 2012 18:33:48 +0000
X-Env-Sender: kks.kbase@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1350758027!34280861!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26045 invoked from network); 20 Oct 2012 18:33:47 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Oct 2012 18:33:47 -0000
Received: by mail-bk0-f45.google.com with SMTP id jf3so523169bkc.32
	for ; Sat, 20 Oct 2012 11:33:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=HsWuhbFkUIRLLMJtOazJtfaNSrfmalFkd/yjCbU99Uo=;
	b=i6r1RALjc+BnUouuAm7KyZ5FaB2Nw2YrUElZTejjEg3iQ5ThYwk/PLxrNbsNYDSfYG
	Ougn7FzzF2W1aZGeb7Ae7wiZXl2NEXlc9RXyXDvDgZzMSOseoXzvnDlx0Jyy7eU6Mif4
	KrmECq8f53Oqv03C0oTqAZlRZeLOVvFthZ79YjhBwBqJstgDLcaCwmOsd88TBC+g/kAw
	i8XP5GDNyx2ip6FGXIemojYqVgjBO1lqWQo2Llf3jldZLlbeykwGv27ML8sW2EXmfc/A
	5wcvHcky52zrBCTlZx26E8OOAszpMAV0RM29cjjNyrnZ3lxtP18KdLpBeIPcax42MNrR
	L9Gg==
MIME-Version: 1.0
Received: by 10.204.130.152 with SMTP id t24mr1391387bks.138.1350758027420;
	Sat, 20 Oct 2012 11:33:47 -0700 (PDT)
Received: by 10.204.50.144 with HTTP; Sat, 20 Oct 2012 11:33:47 -0700 (PDT)
In-Reply-To: <20121019142100.GN26830@phenom.dumpdata.com>
References: 
	<1350466992.2460.47.camel@zakaz.uk.xensource.com>
	
	<1350568154.2460.151.camel@zakaz.uk.xensource.com>
	
	<20121019142100.GN26830@phenom.dumpdata.com>
Date: Sun, 21 Oct 2012 00:03:47 +0530
Message-ID: 
From: kk s 
To: Konrad Rzeszutek Wilk 
X-Mailman-Approved-At: Sat, 20 Oct 2012 19:52:16 +0000
Cc: "xen-users@lists.xen.org" ,
	xen-devel ,
	Ian Campbell ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [Xen-users] Fedora 17 Dom-U booting issue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0837250929567156950=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0837250929567156950==
Content-Type: multipart/alternative; boundary=000e0ce0b1ae66e4c404cc81dcd2

--000e0ce0b1ae66e4c404cc81dcd2
Content-Type: text/plain; charset=ISO-8859-1

Hi,

Looks like the serial='pty' parameter already passed which doesn't work.
Though I can't add do 'loglevel=8 initcall_debug console=ttyS0,115200
debug' since its Xen HVM and without booted the VM we can't add anything in
grub.conf file.

The default kernel that comes from Fedora iso is booting fine and this
latest kernel only having issue. I'll try with serial=pty later today and
provide you the result.

Fyi. The fedora version designed to install as pv-on-hvm itself which means
it uses xen network and disk devices. So I already tried to pass netfront
type and tried pci passthrough none of it helped.

I guess its something issue with Fedora kernel.


On Fri, Oct 19, 2012 at 7:51 PM, Konrad Rzeszutek Wilk <
konrad.wilk@oracle.com> wrote:

> On Thu, Oct 18, 2012 at 05:21:06PM +0100, Stefano Stabellini wrote:
> > On Thu, 18 Oct 2012, Ian Campbell wrote:
> > > On Thu, 2012-10-18 at 14:42 +0100, Stefano Stabellini wrote:
> > > > On Wed, 17 Oct 2012, Ian Campbell wrote:
> > > > > Adding xen-devel and the relevant maintainers.
> > > > >
> > > > > On Tue, 2012-10-16 at 20:24 +0100, kk s wrote:
> > > > > > Hi Folks,
> > > > > >
> > > > > >
> > > > > > I have upgraded Fedora 16 to 17 on one of Xen HVM Dom-U and it
> refuses
> > > > > > to boot fine and getting the below error on console,
> > > > > >
> > > > > >
> > > > > > --------
> > > > > > Booting 'Fedora (3.6.1-1.fc17.x86_64)'
> > > > > >
> > > > > >
> > > > > > Loading Fedora (3.6.1-1.fc17.x86_64)
> > > > > > Loading initial ramdisk ...
> > > > > > [   0.000000] Cannot get hvm parameter 18: -22!
> > > > >
> > > > > HVM parameter 18 is HVM_PARAM_CONSOLE_EVTCHN.
> > > >
> > > > -22 is EINVAL, that Xen would return only if:
> > > >
> > > > - the requested parameter is out of range
> > > > this is not the case, 18 < 30
> > >
> > > The hypervisor here is 3.4.3 where the largest hvm param is:
> > > $ grep define.HVM_PARAM
> xen-3.4-testing.hg/xen/include/public/hvm/params.h | sort -k3 -n | tail -n 3
> > > #define HVM_PARAM_ACPI_S_STATE 14
> > > #define HVM_PARAM_VM86_TSS     15
> > > #define HVM_PARAM_VPT_ALIGN    16
> >
> > OK, we know that the console is not working because it is not provided
> > by the hypervisor.
> > However that shouldn't prevent the domain from booting, the emulated
> > serial should work fine.
>
> Maybe it does? Mr. KK can you boot your guest with this in guest config:
>
> serial='pty'
>
> and on your Linux line, do 'loglevel=8 initcall_debug console=ttyS0,115200
> debug' please?
>

--000e0ce0b1ae66e4c404cc81dcd2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

Looks like the=A0serial=3D'pty' parameter al=
ready passed which doesn't work. Though I can't add=A0do 'logle=
vel=3D8 initcall_debug console=3DttyS0,115200 debug' since its Xen HVM =
and without booted the VM we can't add anything in grub.conf file.


The default kernel that comes from Fedora iso is booting fine=
 and this latest kernel only having issue. I'll try with serial=3Dpty l=
ater today and provide you the result.

Fyi. The fe=
dora version designed to install as pv-on-hvm itself which means it uses xe=
n network and disk devices. So I already tried to pass netfront type and tr=
ied pci passthrough none of it helped.



I guess its something issue with Fedora kernel.


On Fri, Oct 19, 2012=
 at 7:51 PM, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:


On T=
hu, Oct 18, 2012 at 05:21:06PM +0100, Stefano Stabellini wrote:

> On Thu, 18 Oct 2012, Ian Campbell wrote:

> > On Thu, 2012-10-18 at 14:42 +0100, Stefano Stabellini wrote:

> > > On Wed, 17 Oct 2012, Ian Campbell wrote:

> > > > Adding xen-devel and the relevant maintainers.

> > > >

> > > > On Tue, 2012-10-16 at 20:24 +0100, kk s wrote:

> > > > > Hi Folks,

> > > > >

> > > > >

> > > > > I have upgraded Fedora 16 to 17 on one of Xen HVM =
Dom-U and it refuses

> > > > > to boot fine and getting the below error on consol=
e,

> > > > >

> > > > >

> > > > > --------

> > > > > Booting 'Fedora (3.6.1-1.fc17.x86_64)'

> > > > >

> > > > >

> > > > > Loading Fedora (3.6.1-1.fc17.x86_64)

> > > > > Loading initial ramdisk ...

> > > > > [ =A0 0.000000] Cannot get hvm parameter 18: -22!<=
br>
> > > >

> > > > HVM parameter 18 is HVM_PARAM_CONSOLE_EVTCHN.

> > >

> > > -22 is EINVAL, that Xen would return only if:

> > >

> > > - the requested parameter is out of range

> > > this is not the case, 18 < 30

> >

> > The hypervisor here is 3.4.3 where the largest hvm param is:

> > $ grep define.HVM_PARAM xen-3.4-testing.hg/xen/include/public/hvm=
/params.h | sort -k3 -n | tail -n 3

> > #define HVM_PARAM_ACPI_S_STATE 14

> > #define HVM_PARAM_VM86_TSS =A0 =A0 15

> > #define HVM_PARAM_VPT_ALIGN =A0 =A016

>

> OK, we know that the console is not working because it is not provided=


> by the hypervisor.

> However that shouldn't prevent the domain from booting, the emulat=
ed

> serial should work fine.




Maybe it does? Mr. KK can you boot your guest with this in gues=
t config:



serial=3D'pty'



and on your Linux line, do 'loglevel=3D8 initcall_debug console=3DttyS0=
,115200 debug' please?





--000e0ce0b1ae66e4c404cc81dcd2--


--===============0837250929567156950==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0837250929567156950==--


From xen-devel-bounces@lists.xen.org Sat Oct 20 22:14:34 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Oct 2012 22:14:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPhIv-0007Qk-4k; Sat, 20 Oct 2012 22:14:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPhIt-0007Qc-D5; Sat, 20 Oct 2012 22:13:59 +0000
Received: from [85.158.139.211:44352] by server-12.bemta-5.messagelabs.com id
	09/8D-26919-62223805; Sat, 20 Oct 2012 22:13:58 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-2.tower-206.messagelabs.com!1350771237!23082929!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MjE2NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18236 invoked from network); 20 Oct 2012 22:13:57 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Oct 2012 22:13:57 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id C9B2A1513;
	Sun, 21 Oct 2012 01:13:56 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 38E7720058; Sun, 21 Oct 2012 01:13:56 +0300 (EEST)
Date: Sun, 21 Oct 2012 01:13:56 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= 
To: kk s 
Message-ID: <20121020221355.GR8912@reaktio.net>
References: 
	<1350466992.2460.47.camel@zakaz.uk.xensource.com>
	
	<1350568154.2460.151.camel@zakaz.uk.xensource.com>
	
	<20121019142100.GN26830@phenom.dumpdata.com>
	
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "xen-users@lists.xen.org" ,
	xen-devel ,
	Ian Campbell ,
	Stefano Stabellini ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [Xen-users] Fedora 17 Dom-U booting issue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Oct 21, 2012 at 12:03:47AM +0530, kk s wrote:
>    Hi,
>    Looks like the serial='pty' parameter already passed which doesn't work.
>    Though I can't add do 'loglevel=8 initcall_debug console=ttyS0,115200
>    debug' since its Xen HVM and without booted the VM we can't add anything
>    in grub.conf file.
>

Open the VNC console for the HVM guest and edit grub settings / kernel parameters? 


>    The default kernel that comes from Fedora iso is booting fine and this
>    latest kernel only having issue. I'll try with serial=pty later today and
>    provide you the result.
>    Fyi. The fedora version designed to install as pv-on-hvm itself which
>    means it uses xen network and disk devices. So I already tried to pass
>    netfront type and tried pci passthrough none of it helped.
>    I guess its something issue with Fedora kernel.

You can control if pv-on-hvm is used from dom0, see:
http://wiki.xen.org/wiki/Xen_Linux_PV_on_HVM_drivers

-- Pasi

>    On Fri, Oct 19, 2012 at 7:51 PM, Konrad Rzeszutek Wilk
>    <[1]konrad.wilk@oracle.com> wrote:
> 
>      On Thu, Oct 18, 2012 at 05:21:06PM +0100, Stefano Stabellini wrote:
>      > On Thu, 18 Oct 2012, Ian Campbell wrote:
>      > > On Thu, 2012-10-18 at 14:42 +0100, Stefano Stabellini wrote:
>      > > > On Wed, 17 Oct 2012, Ian Campbell wrote:
>      > > > > Adding xen-devel and the relevant maintainers.
>      > > > >
>      > > > > On Tue, 2012-10-16 at 20:24 +0100, kk s wrote:
>      > > > > > Hi Folks,
>      > > > > >
>      > > > > >
>      > > > > > I have upgraded Fedora 16 to 17 on one of Xen HVM Dom-U and it
>      refuses
>      > > > > > to boot fine and getting the below error on console,
>      > > > > >
>      > > > > >
>      > > > > > --------
>      > > > > > Booting 'Fedora (3.6.1-1.fc17.x86_64)'
>      > > > > >
>      > > > > >
>      > > > > > Loading Fedora (3.6.1-1.fc17.x86_64)
>      > > > > > Loading initial ramdisk ...
>      > > > > > [   0.000000] Cannot get hvm parameter 18: -22!
>      > > > >
>      > > > > HVM parameter 18 is HVM_PARAM_CONSOLE_EVTCHN.
>      > > >
>      > > > -22 is EINVAL, that Xen would return only if:
>      > > >
>      > > > - the requested parameter is out of range
>      > > > this is not the case, 18 < 30
>      > >
>      > > The hypervisor here is 3.4.3 where the largest hvm param is:
>      > > $ grep define.HVM_PARAM
>      xen-3.4-testing.hg/xen/include/public/hvm/params.h | sort -k3 -n | tail
>      -n 3
>      > > #define HVM_PARAM_ACPI_S_STATE 14
>      > > #define HVM_PARAM_VM86_TSS     15
>      > > #define HVM_PARAM_VPT_ALIGN    16
>      >
>      > OK, we know that the console is not working because it is not provided
>      > by the hypervisor.
>      > However that shouldn't prevent the domain from booting, the emulated
>      > serial should work fine.
> 
>      Maybe it does? Mr. KK can you boot your guest with this in guest config:
> 
>      serial='pty'
> 
>      and on your Linux line, do 'loglevel=8 initcall_debug
>      console=ttyS0,115200 debug' please?
> 
> References
> 
>    Visible links
>    1. mailto:konrad.wilk@oracle.com

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 20 22:14:34 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 20 Oct 2012 22:14:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPhIv-0007Qk-4k; Sat, 20 Oct 2012 22:14:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPhIt-0007Qc-D5; Sat, 20 Oct 2012 22:13:59 +0000
Received: from [85.158.139.211:44352] by server-12.bemta-5.messagelabs.com id
	09/8D-26919-62223805; Sat, 20 Oct 2012 22:13:58 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-2.tower-206.messagelabs.com!1350771237!23082929!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MjE2NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18236 invoked from network); 20 Oct 2012 22:13:57 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Oct 2012 22:13:57 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id C9B2A1513;
	Sun, 21 Oct 2012 01:13:56 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 38E7720058; Sun, 21 Oct 2012 01:13:56 +0300 (EEST)
Date: Sun, 21 Oct 2012 01:13:56 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= 
To: kk s 
Message-ID: <20121020221355.GR8912@reaktio.net>
References: 
	<1350466992.2460.47.camel@zakaz.uk.xensource.com>
	
	<1350568154.2460.151.camel@zakaz.uk.xensource.com>
	
	<20121019142100.GN26830@phenom.dumpdata.com>
	
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "xen-users@lists.xen.org" ,
	xen-devel ,
	Ian Campbell ,
	Stefano Stabellini ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [Xen-users] Fedora 17 Dom-U booting issue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Oct 21, 2012 at 12:03:47AM +0530, kk s wrote:
>    Hi,
>    Looks like the serial='pty' parameter already passed which doesn't work.
>    Though I can't add do 'loglevel=8 initcall_debug console=ttyS0,115200
>    debug' since its Xen HVM and without booted the VM we can't add anything
>    in grub.conf file.
>

Open the VNC console for the HVM guest and edit grub settings / kernel parameters? 


>    The default kernel that comes from Fedora iso is booting fine and this
>    latest kernel only having issue. I'll try with serial=pty later today and
>    provide you the result.
>    Fyi. The fedora version designed to install as pv-on-hvm itself which
>    means it uses xen network and disk devices. So I already tried to pass
>    netfront type and tried pci passthrough none of it helped.
>    I guess its something issue with Fedora kernel.

You can control if pv-on-hvm is used from dom0, see:
http://wiki.xen.org/wiki/Xen_Linux_PV_on_HVM_drivers

-- Pasi

>    On Fri, Oct 19, 2012 at 7:51 PM, Konrad Rzeszutek Wilk
>    <[1]konrad.wilk@oracle.com> wrote:
> 
>      On Thu, Oct 18, 2012 at 05:21:06PM +0100, Stefano Stabellini wrote:
>      > On Thu, 18 Oct 2012, Ian Campbell wrote:
>      > > On Thu, 2012-10-18 at 14:42 +0100, Stefano Stabellini wrote:
>      > > > On Wed, 17 Oct 2012, Ian Campbell wrote:
>      > > > > Adding xen-devel and the relevant maintainers.
>      > > > >
>      > > > > On Tue, 2012-10-16 at 20:24 +0100, kk s wrote:
>      > > > > > Hi Folks,
>      > > > > >
>      > > > > >
>      > > > > > I have upgraded Fedora 16 to 17 on one of Xen HVM Dom-U and it
>      refuses
>      > > > > > to boot fine and getting the below error on console,
>      > > > > >
>      > > > > >
>      > > > > > --------
>      > > > > > Booting 'Fedora (3.6.1-1.fc17.x86_64)'
>      > > > > >
>      > > > > >
>      > > > > > Loading Fedora (3.6.1-1.fc17.x86_64)
>      > > > > > Loading initial ramdisk ...
>      > > > > > [   0.000000] Cannot get hvm parameter 18: -22!
>      > > > >
>      > > > > HVM parameter 18 is HVM_PARAM_CONSOLE_EVTCHN.
>      > > >
>      > > > -22 is EINVAL, that Xen would return only if:
>      > > >
>      > > > - the requested parameter is out of range
>      > > > this is not the case, 18 < 30
>      > >
>      > > The hypervisor here is 3.4.3 where the largest hvm param is:
>      > > $ grep define.HVM_PARAM
>      xen-3.4-testing.hg/xen/include/public/hvm/params.h | sort -k3 -n | tail
>      -n 3
>      > > #define HVM_PARAM_ACPI_S_STATE 14
>      > > #define HVM_PARAM_VM86_TSS     15
>      > > #define HVM_PARAM_VPT_ALIGN    16
>      >
>      > OK, we know that the console is not working because it is not provided
>      > by the hypervisor.
>      > However that shouldn't prevent the domain from booting, the emulated
>      > serial should work fine.
> 
>      Maybe it does? Mr. KK can you boot your guest with this in guest config:
> 
>      serial='pty'
> 
>      and on your Linux line, do 'loglevel=8 initcall_debug
>      console=ttyS0,115200 debug' please?
> 
> References
> 
>    Visible links
>    1. mailto:konrad.wilk@oracle.com

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 21 04:51:18 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 21 Oct 2012 04:51:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPnUk-0005Ay-1i; Sun, 21 Oct 2012 04:50:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPnUi-0005At-2L
	for xen-devel@lists.xensource.com; Sun, 21 Oct 2012 04:50:36 +0000
Received: from [85.158.143.99:41156] by server-2.bemta-4.messagelabs.com id
	51/9A-22268-B1F73805; Sun, 21 Oct 2012 04:50:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1350795032!34583448!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUyMTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27742 invoked from network); 21 Oct 2012 04:50:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Oct 2012 04:50:32 -0000
X-IronPort-AV: E=Sophos;i="4.80,624,1344211200"; d="scan'208";a="15293706"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Oct 2012 04:50:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sun, 21 Oct 2012 05:50:32 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TPnUd-0004bH-Dh;
	Sun, 21 Oct 2012 04:50:31 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TPnUc-0001sP-Sr;
	Sun, 21 Oct 2012 05:50:30 +0100
To: 
Message-ID: 
From: xen.org 
Date: Sun, 21 Oct 2012 05:50:30 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14066: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14066 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14066/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install     fail pass in 14065

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 14065
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 14065
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 14065
 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail in 14065 like 14064

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  478ba3f146df
baseline version:
 xen                  478ba3f146df

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 21 04:51:18 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 21 Oct 2012 04:51:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPnUk-0005Ay-1i; Sun, 21 Oct 2012 04:50:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPnUi-0005At-2L
	for xen-devel@lists.xensource.com; Sun, 21 Oct 2012 04:50:36 +0000
Received: from [85.158.143.99:41156] by server-2.bemta-4.messagelabs.com id
	51/9A-22268-B1F73805; Sun, 21 Oct 2012 04:50:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1350795032!34583448!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUyMTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27742 invoked from network); 21 Oct 2012 04:50:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Oct 2012 04:50:32 -0000
X-IronPort-AV: E=Sophos;i="4.80,624,1344211200"; d="scan'208";a="15293706"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Oct 2012 04:50:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sun, 21 Oct 2012 05:50:32 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TPnUd-0004bH-Dh;
	Sun, 21 Oct 2012 04:50:31 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TPnUc-0001sP-Sr;
	Sun, 21 Oct 2012 05:50:30 +0100
To: 
Message-ID: 
From: xen.org 
Date: Sun, 21 Oct 2012 05:50:30 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14066: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14066 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14066/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install     fail pass in 14065

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 14065
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 14065
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 14065
 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail in 14065 like 14064

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  478ba3f146df
baseline version:
 xen                  478ba3f146df

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 21 07:36:21 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 21 Oct 2012 07:36:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPq3u-0006Cr-Ku; Sun, 21 Oct 2012 07:35:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPq3s-0006Cm-Jr
	for xen-devel@lists.xen.org; Sun, 21 Oct 2012 07:35:04 +0000
Received: from [85.158.143.35:28892] by server-1.bemta-4.messagelabs.com id
	0D/A1-19134-7A5A3805; Sun, 21 Oct 2012 07:35:03 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1350804902!5785191!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUyMTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19599 invoked from network); 21 Oct 2012 07:35:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Oct 2012 07:35:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,624,1344211200"; 
	d="asc'?scan'208";a="15294444"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Oct 2012 07:35:01 +0000
Received: from [IPv6:::1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Sun, 21 Oct 2012 08:35:01 +0100
Message-ID: <1350804900.4072.11.camel@Abyss>
From: Dario Faggioli 
To: Ian Jackson 
Date: Sun, 21 Oct 2012 09:35:00 +0200
In-Reply-To: <1350669760.6053.97.camel@Solace>
References: 
	
	
	<1350602433.26152.106.camel@Solace>
	<20609.27239.778582.985508@mariner.uk.xensource.com>
	<1350669760.6053.97.camel@Solace>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
MIME-Version: 1.0
Cc: Andre Przywara ,
	Ian Campbell ,
	Stefano Stabellini ,
	George Dunlap ,
	Juergen Gross ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 1 of 3] libxl: take node distances into
 account during NUMA placement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1698698254710749356=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1698698254710749356==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-nhwKs+LQaCW0sna5im0U"

--=-nhwKs+LQaCW0sna5im0U
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-10-19 at 20:02 +0200, Dario Faggioli wrote:=20
> I am. In fact, I think they answer George's question which was "by how
> much we are increasing the complexity of each step?" and not "by how
> much we are increasing the overall complexity?".
>=20
> That of course doesn't mean I don't care about the overall complexity,
> just that I don't think this is making things worse than what we have
> (which is, btw, the result of the long discussion we had pre 4.2
> release).
>=20
> > It seems to me that=20
> > doing Nnodes^2 for each candidate multiplies the cost by the number of
> > candidates, rather than adding Nnodes^2.
> >=20
> That is definitely true. Again the key is the difference between talking
> about "each candidate", as we were, and total.
>=20
Which, BTW, make me thinking that you don't like the fact that, for each
candidate, we go through the list of domains to check what vcpus are
bound to such candidate.

That was requested during review of the automatic placement series,
reviewed itself, tested on an 8 nodes box with 50-60 domains and became
cs 4165d71479f9.

Anyway, if you want, I think I can change that too. :-)

Thanks and Regards,
Dario

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-nhwKs+LQaCW0sna5im0U
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlCDpaQACgkQk4XaBE3IOsTHhgCgltUTZ8TjLxQm46zAB92iqDbG
gTMAoIF0yC5cM2cwTO19dKCTuVJ1q6mV
=KW23
-----END PGP SIGNATURE-----

--=-nhwKs+LQaCW0sna5im0U--


--===============1698698254710749356==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1698698254710749356==--


From xen-devel-bounces@lists.xen.org Sun Oct 21 07:36:21 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 21 Oct 2012 07:36:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TPq3u-0006Cr-Ku; Sun, 21 Oct 2012 07:35:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TPq3s-0006Cm-Jr
	for xen-devel@lists.xen.org; Sun, 21 Oct 2012 07:35:04 +0000
Received: from [85.158.143.35:28892] by server-1.bemta-4.messagelabs.com id
	0D/A1-19134-7A5A3805; Sun, 21 Oct 2012 07:35:03 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1350804902!5785191!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUyMTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19599 invoked from network); 21 Oct 2012 07:35:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Oct 2012 07:35:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,624,1344211200"; 
	d="asc'?scan'208";a="15294444"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Oct 2012 07:35:01 +0000
Received: from [IPv6:::1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Sun, 21 Oct 2012 08:35:01 +0100
Message-ID: <1350804900.4072.11.camel@Abyss>
From: Dario Faggioli 
To: Ian Jackson 
Date: Sun, 21 Oct 2012 09:35:00 +0200
In-Reply-To: <1350669760.6053.97.camel@Solace>
References: 
	
	
	<1350602433.26152.106.camel@Solace>
	<20609.27239.778582.985508@mariner.uk.xensource.com>
	<1350669760.6053.97.camel@Solace>
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
MIME-Version: 1.0
Cc: Andre Przywara ,
	Ian Campbell ,
	Stefano Stabellini ,
	George Dunlap ,
	Juergen Gross ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 1 of 3] libxl: take node distances into
 account during NUMA placement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1698698254710749356=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1698698254710749356==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-nhwKs+LQaCW0sna5im0U"

--=-nhwKs+LQaCW0sna5im0U
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-10-19 at 20:02 +0200, Dario Faggioli wrote:=20
> I am. In fact, I think they answer George's question which was "by how
> much we are increasing the complexity of each step?" and not "by how
> much we are increasing the overall complexity?".
>=20
> That of course doesn't mean I don't care about the overall complexity,
> just that I don't think this is making things worse than what we have
> (which is, btw, the result of the long discussion we had pre 4.2
> release).
>=20
> > It seems to me that=20
> > doing Nnodes^2 for each candidate multiplies the cost by the number of
> > candidates, rather than adding Nnodes^2.
> >=20
> That is definitely true. Again the key is the difference between talking
> about "each candidate", as we were, and total.
>=20
Which, BTW, make me thinking that you don't like the fact that, for each
candidate, we go through the list of domains to check what vcpus are
bound to such candidate.

That was requested during review of the automatic placement series,
reviewed itself, tested on an 8 nodes box with 50-60 domains and became
cs 4165d71479f9.

Anyway, if you want, I think I can change that too. :-)

Thanks and Regards,
Dario

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-nhwKs+LQaCW0sna5im0U
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlCDpaQACgkQk4XaBE3IOsTHhgCgltUTZ8TjLxQm46zAB92iqDbG
gTMAoIF0yC5cM2cwTO19dKCTuVJ1q6mV
=KW23
-----END PGP SIGNATURE-----

--=-nhwKs+LQaCW0sna5im0U--


--===============1698698254710749356==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1698698254710749356==--


From xen-devel-bounces@lists.xen.org Sun Oct 21 21:17:34 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 21 Oct 2012 21:17:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQ2tE-0002yo-Dg; Sun, 21 Oct 2012 21:16:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQ2tD-0002yj-3P
	for xen-devel@lists.xen.org; Sun, 21 Oct 2012 21:16:55 +0000
Received: from [85.158.138.51:26059] by server-9.bemta-3.messagelabs.com id
	F6/A0-16841-64664805; Sun, 21 Oct 2012 21:16:54 +0000
X-Env-Sender: ronny.hegewald@online.de
X-Msg-Ref: server-6.tower-174.messagelabs.com!1350854213!27187005!1
X-Originating-IP: [212.227.126.187]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xODcgPT4gODE0MTQ=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xODcgPT4gODE0MTQ=\n,BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16942 invoked from network); 21 Oct 2012 21:16:53 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.126.187)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Oct 2012 21:16:53 -0000
Received: from server2-groupware.localnet (p4FEF8EF2.dip0.t-ipconnect.de
	[79.239.142.242])
	by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis)
	id 0Li23m-1T4iRc1XsY-00mWzJ; Sun, 21 Oct 2012 23:16:53 +0200
From: Ronny Hegewald 
To: xen-devel@lists.xen.org
Date: Sun, 21 Oct 2012 22:22:18 +0000
User-Agent: KMail/1.11.4 (Linux/3.0.3; KDE/4.2.4; i686; ; )
MIME-Version: 1.0
Content-Disposition: inline
Message-Id: <201210212222.18396.ronny.hegewald@online.de>
X-Provags-ID: V02:K0:cBcxPksGMrxPSUZCGLYREA2YGnvC5xZcRJTH6MqZr1X
	7mN/iG5BV5A1VOOwgVKCdZwaHxpHAMbHOVEHx4CgWKTFhBVGVK
	DJHumH8ANuhIU9TRd+W3U2K4Vyj5KpEmU9673Z28wVPE7qM426
	ma10Llx9q9cB4MmDhErx9S6k9ZeA5hYmH3U2XSLDcxHSLbbPQr
	Scb11wc94i36W09gEJh22y7MZlLDmK6pvzkeJGZ/R3QWDlLbPt
	DZkNQzriWK277syV+/wiAaGLquaqC9bTZtIrZ7Hz2L0of1sV3+
	gaxVGM2amKfUF7/rWvX/aOwSDh6vwPAOdUhU0ezdIROazEmGhK
	oqm34Jv4JZhq5dSzgxsvtj+CQROXRYmt4BZdX0pZnsAadUBm94
	bwme/t7wiLfEj+zYZ7SSulSBFNFFXytVy4=
Subject: [Xen-devel] [PATCH V2] keep iommu disabled until iommu_setup() is
	called
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The iommu is enabled by default when xen is booting and later disabled in 
iommu_setup() when no iommu is present.

But under some circumstances iommu-code can be called before iommu_setup() is 
processed. If there is no iommu available xen crashes.

This can happen for example when panic(...) is called that got introduced with
patch "x86-64: detect processors subject to AMD erratum #121 and refuse to 
boot." since xen 4.1.3 and results in the following stacktrace:

   find_iommu_for_device
   amd_iommu_ioapic_update_ire
   timer_interrupt
   enable_8259_A_irq
   do_IRQ
   printk_start_of_line
   acpi_os_printf
   io_apic_write
   __ioapic_write_entry
   ioapic_write_entry
   __clear_IO_APIC_pin
   clear_IO_APIC
   disable_IO_APIC
   __stop_this_cpu
   smp_send_stop
   machine_restart
   panic
   tasklet_schedule_on_cpu
   display_cacheinfo
   init_amd
   generic_identify
   identify_cpu
   _start_xen
   _high_start


This patch fixes this by keeping the iommu disabled until iommu_setup() is 
entered. 

Signed-off-by: Ronny Hegewald@online.de

---
Changed since V1:
   * simplify code as suggested by Jan Beulich

--- xen/drivers/passthrough/iommu.c.org	2012-10-05 03:38:33.000000000 +0000
+++ xen/drivers/passthrough/iommu.c	2012-10-21 21:07:37.000000000 +0000
@@ -38,7 +38,8 @@
  *   no-intremap                Disable VT-d Interrupt Remapping
  */
 custom_param("iommu", parse_iommu_param);
-bool_t __read_mostly iommu_enabled = 1;
+bool_t iommu_enable_default __initdata = 1;
+bool_t __read_mostly iommu_enabled;
 bool_t __read_mostly force_iommu;
 bool_t __initdata iommu_dom0_strict;
 bool_t __read_mostly iommu_verbose;
@@ -61,7 +62,7 @@
             *ss = '\0';
 
         if ( !parse_bool(s) )
-            iommu_enabled = 0;
+            iommu_enable_default = 0;
         else if ( !strcmp(s, "force") || !strcmp(s, "required") )
             force_iommu = 1;
         else if ( !strcmp(s, "workaround_bios_bug") )
@@ -316,7 +317,7 @@
     if ( iommu_dom0_strict )
         iommu_passthrough = 0;
 
-    if ( iommu_enabled )
+    if ( iommu_enable_default )
     {
         rc = iommu_hardware_setup();
         iommu_enabled = (rc == 0);




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 21 21:17:34 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 21 Oct 2012 21:17:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQ2tE-0002yo-Dg; Sun, 21 Oct 2012 21:16:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQ2tD-0002yj-3P
	for xen-devel@lists.xen.org; Sun, 21 Oct 2012 21:16:55 +0000
Received: from [85.158.138.51:26059] by server-9.bemta-3.messagelabs.com id
	F6/A0-16841-64664805; Sun, 21 Oct 2012 21:16:54 +0000
X-Env-Sender: ronny.hegewald@online.de
X-Msg-Ref: server-6.tower-174.messagelabs.com!1350854213!27187005!1
X-Originating-IP: [212.227.126.187]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xODcgPT4gODE0MTQ=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xODcgPT4gODE0MTQ=\n,BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16942 invoked from network); 21 Oct 2012 21:16:53 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.126.187)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Oct 2012 21:16:53 -0000
Received: from server2-groupware.localnet (p4FEF8EF2.dip0.t-ipconnect.de
	[79.239.142.242])
	by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis)
	id 0Li23m-1T4iRc1XsY-00mWzJ; Sun, 21 Oct 2012 23:16:53 +0200
From: Ronny Hegewald 
To: xen-devel@lists.xen.org
Date: Sun, 21 Oct 2012 22:22:18 +0000
User-Agent: KMail/1.11.4 (Linux/3.0.3; KDE/4.2.4; i686; ; )
MIME-Version: 1.0
Content-Disposition: inline
Message-Id: <201210212222.18396.ronny.hegewald@online.de>
X-Provags-ID: V02:K0:cBcxPksGMrxPSUZCGLYREA2YGnvC5xZcRJTH6MqZr1X
	7mN/iG5BV5A1VOOwgVKCdZwaHxpHAMbHOVEHx4CgWKTFhBVGVK
	DJHumH8ANuhIU9TRd+W3U2K4Vyj5KpEmU9673Z28wVPE7qM426
	ma10Llx9q9cB4MmDhErx9S6k9ZeA5hYmH3U2XSLDcxHSLbbPQr
	Scb11wc94i36W09gEJh22y7MZlLDmK6pvzkeJGZ/R3QWDlLbPt
	DZkNQzriWK277syV+/wiAaGLquaqC9bTZtIrZ7Hz2L0of1sV3+
	gaxVGM2amKfUF7/rWvX/aOwSDh6vwPAOdUhU0ezdIROazEmGhK
	oqm34Jv4JZhq5dSzgxsvtj+CQROXRYmt4BZdX0pZnsAadUBm94
	bwme/t7wiLfEj+zYZ7SSulSBFNFFXytVy4=
Subject: [Xen-devel] [PATCH V2] keep iommu disabled until iommu_setup() is
	called
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The iommu is enabled by default when xen is booting and later disabled in 
iommu_setup() when no iommu is present.

But under some circumstances iommu-code can be called before iommu_setup() is 
processed. If there is no iommu available xen crashes.

This can happen for example when panic(...) is called that got introduced with
patch "x86-64: detect processors subject to AMD erratum #121 and refuse to 
boot." since xen 4.1.3 and results in the following stacktrace:

   find_iommu_for_device
   amd_iommu_ioapic_update_ire
   timer_interrupt
   enable_8259_A_irq
   do_IRQ
   printk_start_of_line
   acpi_os_printf
   io_apic_write
   __ioapic_write_entry
   ioapic_write_entry
   __clear_IO_APIC_pin
   clear_IO_APIC
   disable_IO_APIC
   __stop_this_cpu
   smp_send_stop
   machine_restart
   panic
   tasklet_schedule_on_cpu
   display_cacheinfo
   init_amd
   generic_identify
   identify_cpu
   _start_xen
   _high_start


This patch fixes this by keeping the iommu disabled until iommu_setup() is 
entered. 

Signed-off-by: Ronny Hegewald@online.de

---
Changed since V1:
   * simplify code as suggested by Jan Beulich

--- xen/drivers/passthrough/iommu.c.org	2012-10-05 03:38:33.000000000 +0000
+++ xen/drivers/passthrough/iommu.c	2012-10-21 21:07:37.000000000 +0000
@@ -38,7 +38,8 @@
  *   no-intremap                Disable VT-d Interrupt Remapping
  */
 custom_param("iommu", parse_iommu_param);
-bool_t __read_mostly iommu_enabled = 1;
+bool_t iommu_enable_default __initdata = 1;
+bool_t __read_mostly iommu_enabled;
 bool_t __read_mostly force_iommu;
 bool_t __initdata iommu_dom0_strict;
 bool_t __read_mostly iommu_verbose;
@@ -61,7 +62,7 @@
             *ss = '\0';
 
         if ( !parse_bool(s) )
-            iommu_enabled = 0;
+            iommu_enable_default = 0;
         else if ( !strcmp(s, "force") || !strcmp(s, "required") )
             force_iommu = 1;
         else if ( !strcmp(s, "workaround_bios_bug") )
@@ -316,7 +317,7 @@
     if ( iommu_dom0_strict )
         iommu_passthrough = 0;
 
-    if ( iommu_enabled )
+    if ( iommu_enable_default )
     {
         rc = iommu_hardware_setup();
         iommu_enabled = (rc == 0);




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 01:52:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 01:52:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQ7B5-0008Mx-GR; Mon, 22 Oct 2012 01:51:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQ7B4-0008Ms-BL
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 01:51:38 +0000
Received: from [85.158.139.211:51768] by server-15.bemta-5.messagelabs.com id
	BA/4C-28599-9A6A4805; Mon, 22 Oct 2012 01:51:37 +0000
X-Env-Sender: davidxu06@gmail.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1350870695!23130945!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_50_60, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19842 invoked from network); 22 Oct 2012 01:51:36 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 01:51:36 -0000
Received: by mail-qc0-f173.google.com with SMTP id b12so1559953qca.32
	for ; Sun, 21 Oct 2012 18:51:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=1MzMLzwb2SQaY9KXQW3Gee3kHqDGNED2dkIF9erbx6E=;
	b=IDqTgbnR198MOGHNS04Xa7IEh3ujv7IHDs5gWJPkSLwObF5UtFESDc3oQxaeK2LxkZ
	AATnWeYRSpuQNFHfBtqyCxJQBpHJkMitP9XglWCL0SsCxaq3W9KgtSaDgbof9oJ7Ifqj
	8pKDMiyQ3MjyArL9dnwtcADNXO5xM+C0t/ftKNIVNzt9Adqp8ltEPcE5g+3bMGKy1EbB
	6IvgrsUW2f/woEZT6fr+UUIutBZJPtWPSodVmewl+/KlACFVsp0aXVsWxK25XhtWar6e
	i8uBIRlzVyREssThemaKZDyosnpiUKUB9C9O5iY6lJsQjQU7HKLX/wGoN1YJ4E4dSpyg
	Czkg==
MIME-Version: 1.0
Received: by 10.49.72.1 with SMTP id z1mr4228156qeu.2.1350870694995; Sun, 21
	Oct 2012 18:51:34 -0700 (PDT)
Received: by 10.49.1.116 with HTTP; Sun, 21 Oct 2012 18:51:34 -0700 (PDT)
Date: Sun, 21 Oct 2012 21:51:34 -0400
Message-ID: 
From: David Xu 
To: xen-devel@lists.xen.org
Subject: [Xen-devel] xen_evtchn_do_upcall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============4169225456190317963=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4169225456190317963==
Content-Type: multipart/alternative; boundary=047d7b6da0c4e9a59504cc9c1755

--047d7b6da0c4e9a59504cc9c1755
Content-Type: text/plain; charset=ISO-8859-1

Hi,

Is anybody know the purpose of this method (xen_evtchn_do_upcall)? When I
run a user level application involved in TCP receiving and the SoftIRQ for
eth0 on the same CPU core, everything is OK. But if I run them on 2
different cores, there will be xen_evtchn_do_upcall() existing (maybe when
the local_bh_disable()
or local_bh_enable()
is called) in __inet_lookup_established() routine which costs longer time
than the first scenario. Is it due to the synchronization issue between
process context and softirq context? Thanks for any reply.

 1)               |    __inet_lookup_established() {
 1)               |    xen_evtchn_do_upcall() {
 1)   0.054 us    |      exit_idle();
 1)               |      irq_enter() {
 1)               |        rcu_irq_enter() {
 1)   0.102 us    |          rcu_exit_nohz();
 1)   0.431 us    |        }
 1)   0.064 us    |        idle_cpu();
 1)   1.152 us    |      }
 1)               |      __xen_evtchn_do_upcall() {
 1)   0.119 us    |        irq_to_desc();
 1)               |        handle_edge_irq() {
 1)   0.107 us    |          _raw_spin_lock();
 1)               |          ack_dynirq() {
 1)               |            evtchn_from_irq() {
 1)               |              info_for_irq() {
 1)               |                irq_get_irq_data() {
 1)   0.052 us    |                  irq_to_desc();
 1)   0.418 us    |                }
 1)   0.782 us    |              }
 1)   1.135 us    |            }
 1)   0.049 us    |            irq_move_irq();
 1)   1.800 us    |          }
 1)               |          handle_irq_event() {
 1)   0.161 us    |            _raw_spin_unlock();
 1)               |            handle_irq_event_percpu() {
 1)               |              xennet_interrupt() {
 1)   0.125 us    |                _raw_spin_lock_irqsave();
 1)               |                xennet_tx_buf_gc() {
 1)   0.079 us    |                  gnttab_query_foreign_access();
 1)   0.050 us    |                  gnttab_end_foreign_access_ref();
 1)   0.069 us    |                  gnttab_release_grant_reference();
 1)               |                  dev_kfree_skb_irq() {
 1)   0.055 us    |                    raise_softirq_irqoff();
 1)   0.472 us    |                  }
 1)   0.049 us    |                  gnttab_query_foreign_access();
 1)   0.058 us    |                  gnttab_end_foreign_access_ref();
 1)   0.058 us    |                  gnttab_release_grant_reference();
 1)               |                  dev_kfree_skb_irq() {
 1)   0.050 us    |                    raise_softirq_irqoff();
 1)   0.456 us    |                  }
 1)   3.714 us    |                }
 1)   0.102 us    |                _raw_spin_unlock_irqrestore();
 1)   4.857 us    |              }
 1)   0.061 us    |              note_interrupt();
 1)   5.571 us    |            }
 1)   0.054 us    |            _raw_spin_lock();
 1)   6.707 us    |          }
 1)   0.083 us    |          _raw_spin_unlock();
 1) + 10.083 us   |        }
 1) + 10.985 us   |      }
 1)               |      irq_exit() {
 1)               |        rcu_irq_exit() {
 1)   0.087 us    |          rcu_enter_nohz();
 1)   0.429 us    |        }
 1)   0.049 us    |        idle_cpu();
 1)   1.088 us    |      }
 1) + 14.551 us   |    }
 1)   0.191 us    |    } /* __inet_lookup_established */

--047d7b6da0c4e9a59504cc9c1755
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,=A0

Is anybody know the purpose of this method (xen_e=
vtchn_do_upcall)? When I run a user level application involved in TCP recei=
ving and the SoftIRQ for eth0 on the same CPU core, everything is OK. But i=
f I run them on 2 different cores, there will be xen_evtchn_do_upcall() exi=
sting (maybe when the=A0lo=
cal_bh_disable() or=A0local_bh_enable() is cal=
led) in=A0__inet_lookup_established() routine which costs longer tim=
e than the first scenario. Is it due to the synchronization issue between p=
rocess context and softirq context? Thanks for any reply.=A0



=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0__inet_=
lookup_established() {
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =
=A0xen_evtchn_do_upcall() {
=A01) =A0 0.054 us =A0 =A0| =A0 =A0 =
=A0exit_idle();
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0ir=
q_enter() {


=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0rcu_irq_enter() {
=A01) =A0 0.102 us =A0 =A0| =A0 =A0 =A0 =A0 =A0rcu_exit_nohz();
=A01) =A0 0.431 us =A0 =A0| =A0 =A0 =A0 =A0}
=A01) =A0 0.=
064 us =A0 =A0| =A0 =A0 =A0 =A0idle_cpu();
=A01) =A0 1.152 us =A0=
 =A0| =A0 =A0 =A0}


=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0__xen_evtchn_do_upcall(=
) {
=A01) =A0 0.119 us =A0 =A0| =A0 =A0 =A0 =A0irq_to_desc();
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0handle_edge_irq()=
 {
=A01) =A0 0.107 us =A0 =A0| =A0 =A0 =A0 =A0 =A0_raw_spin_lock(=
);


=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0ack_dynirq() {<=
/div>
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0evtchn=
_from_irq() {
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0=
 =A0 =A0 =A0info_for_irq() {
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0irq_get_irq_data() {


=A01) =A0 0.052 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0irq_to_=
desc();
=A01) =A0 0.418 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0}
=A01) =A0 0.782 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0}
=A01) =A0 1.135 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0}
=A01)=
 =A0 0.049 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0irq_move_irq();


=A01) =A0 1.800 us =A0 =A0| =A0 =A0 =A0 =A0 =A0}
=A01) =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0handle_irq_event() {
=A01) =A0 0.161 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0_raw_spin_unlock();
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0handle_ir=
q_event_percpu() {


=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0xennet_=
interrupt() {
=A01) =A0 0.125 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0_raw_spin_lock_irqsave();
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0xennet_tx_buf_gc() {
=A01) =
=A0 0.079 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gnttab_query_forei=
gn_access();


=A01) =A0 0.050 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gnttab_=
end_foreign_access_ref();
=A01) =A0 0.069 us =A0 =A0| =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0gnttab_release_grant_reference();
=A01) =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dev_kfree_=
skb_irq() {


=A01) =A0 0.055 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0rai=
se_softirq_irqoff();
=A01) =A0 0.472 us =A0 =A0| =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0}
=A01) =A0 0.049 us =A0 =A0| =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0gnttab_query_foreign_access();
=A01) =A0 0.058=
 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gnttab_end_foreign_access_r=
ef();


=A01) =A0 0.058 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gnttab_=
release_grant_reference();
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dev_kfree_skb_irq() {
=A01) =
=A0 0.050 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0raise_softirq_=
irqoff();


=A01) =A0 0.456 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
=

=A01) =A0 3.714 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
=A01) =A0 0.102 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0_raw_spin_unloc=
k_irqrestore();
=A01) =A0 4.857 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =
=A0 =A0}

=A01) =A0 0.061 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0note_interrupt();
=A01) =A0 5.571 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0}
=A01=
) =A0 0.054 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0_raw_spin_lock();
=
=A01) =A0 6.707 us =A0 =A0| =A0 =A0 =A0 =A0 =A0}
=A01) =A0 0.083 =
us =A0 =A0| =A0 =A0 =A0 =A0 =A0_raw_spin_unlock();


=A01) + 10.083 us =A0 | =A0 =A0 =A0 =A0}
=A01) + 10.985 us =
=A0 | =A0 =A0 =A0}
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =
=A0irq_exit() {
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =
=A0rcu_irq_exit() {
=A01) =A0 0.087 us =A0 =A0| =A0 =A0 =A0 =A0 =
=A0rcu_enter_nohz();


=A01) =A0 0.429 us =A0 =A0| =A0 =A0 =A0 =A0}
=A01) =A0 0.049=
 us =A0 =A0| =A0 =A0 =A0 =A0idle_cpu();
=A01) =A0 1.088 us =A0 =
=A0| =A0 =A0 =A0}
=A01) + 14.551 us =A0 | =A0 =A0}
=A01=
) =A0 0.191 us =A0 =A0| =A0 =A0} /* __inet_lookup_established */




--047d7b6da0c4e9a59504cc9c1755--


--===============4169225456190317963==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4169225456190317963==--


From xen-devel-bounces@lists.xen.org Mon Oct 22 01:52:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 01:52:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQ7B5-0008Mx-GR; Mon, 22 Oct 2012 01:51:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQ7B4-0008Ms-BL
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 01:51:38 +0000
Received: from [85.158.139.211:51768] by server-15.bemta-5.messagelabs.com id
	BA/4C-28599-9A6A4805; Mon, 22 Oct 2012 01:51:37 +0000
X-Env-Sender: davidxu06@gmail.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1350870695!23130945!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_50_60, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19842 invoked from network); 22 Oct 2012 01:51:36 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 01:51:36 -0000
Received: by mail-qc0-f173.google.com with SMTP id b12so1559953qca.32
	for ; Sun, 21 Oct 2012 18:51:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=1MzMLzwb2SQaY9KXQW3Gee3kHqDGNED2dkIF9erbx6E=;
	b=IDqTgbnR198MOGHNS04Xa7IEh3ujv7IHDs5gWJPkSLwObF5UtFESDc3oQxaeK2LxkZ
	AATnWeYRSpuQNFHfBtqyCxJQBpHJkMitP9XglWCL0SsCxaq3W9KgtSaDgbof9oJ7Ifqj
	8pKDMiyQ3MjyArL9dnwtcADNXO5xM+C0t/ftKNIVNzt9Adqp8ltEPcE5g+3bMGKy1EbB
	6IvgrsUW2f/woEZT6fr+UUIutBZJPtWPSodVmewl+/KlACFVsp0aXVsWxK25XhtWar6e
	i8uBIRlzVyREssThemaKZDyosnpiUKUB9C9O5iY6lJsQjQU7HKLX/wGoN1YJ4E4dSpyg
	Czkg==
MIME-Version: 1.0
Received: by 10.49.72.1 with SMTP id z1mr4228156qeu.2.1350870694995; Sun, 21
	Oct 2012 18:51:34 -0700 (PDT)
Received: by 10.49.1.116 with HTTP; Sun, 21 Oct 2012 18:51:34 -0700 (PDT)
Date: Sun, 21 Oct 2012 21:51:34 -0400
Message-ID: 
From: David Xu 
To: xen-devel@lists.xen.org
Subject: [Xen-devel] xen_evtchn_do_upcall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============4169225456190317963=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4169225456190317963==
Content-Type: multipart/alternative; boundary=047d7b6da0c4e9a59504cc9c1755

--047d7b6da0c4e9a59504cc9c1755
Content-Type: text/plain; charset=ISO-8859-1

Hi,

Is anybody know the purpose of this method (xen_evtchn_do_upcall)? When I
run a user level application involved in TCP receiving and the SoftIRQ for
eth0 on the same CPU core, everything is OK. But if I run them on 2
different cores, there will be xen_evtchn_do_upcall() existing (maybe when
the local_bh_disable()
or local_bh_enable()
is called) in __inet_lookup_established() routine which costs longer time
than the first scenario. Is it due to the synchronization issue between
process context and softirq context? Thanks for any reply.

 1)               |    __inet_lookup_established() {
 1)               |    xen_evtchn_do_upcall() {
 1)   0.054 us    |      exit_idle();
 1)               |      irq_enter() {
 1)               |        rcu_irq_enter() {
 1)   0.102 us    |          rcu_exit_nohz();
 1)   0.431 us    |        }
 1)   0.064 us    |        idle_cpu();
 1)   1.152 us    |      }
 1)               |      __xen_evtchn_do_upcall() {
 1)   0.119 us    |        irq_to_desc();
 1)               |        handle_edge_irq() {
 1)   0.107 us    |          _raw_spin_lock();
 1)               |          ack_dynirq() {
 1)               |            evtchn_from_irq() {
 1)               |              info_for_irq() {
 1)               |                irq_get_irq_data() {
 1)   0.052 us    |                  irq_to_desc();
 1)   0.418 us    |                }
 1)   0.782 us    |              }
 1)   1.135 us    |            }
 1)   0.049 us    |            irq_move_irq();
 1)   1.800 us    |          }
 1)               |          handle_irq_event() {
 1)   0.161 us    |            _raw_spin_unlock();
 1)               |            handle_irq_event_percpu() {
 1)               |              xennet_interrupt() {
 1)   0.125 us    |                _raw_spin_lock_irqsave();
 1)               |                xennet_tx_buf_gc() {
 1)   0.079 us    |                  gnttab_query_foreign_access();
 1)   0.050 us    |                  gnttab_end_foreign_access_ref();
 1)   0.069 us    |                  gnttab_release_grant_reference();
 1)               |                  dev_kfree_skb_irq() {
 1)   0.055 us    |                    raise_softirq_irqoff();
 1)   0.472 us    |                  }
 1)   0.049 us    |                  gnttab_query_foreign_access();
 1)   0.058 us    |                  gnttab_end_foreign_access_ref();
 1)   0.058 us    |                  gnttab_release_grant_reference();
 1)               |                  dev_kfree_skb_irq() {
 1)   0.050 us    |                    raise_softirq_irqoff();
 1)   0.456 us    |                  }
 1)   3.714 us    |                }
 1)   0.102 us    |                _raw_spin_unlock_irqrestore();
 1)   4.857 us    |              }
 1)   0.061 us    |              note_interrupt();
 1)   5.571 us    |            }
 1)   0.054 us    |            _raw_spin_lock();
 1)   6.707 us    |          }
 1)   0.083 us    |          _raw_spin_unlock();
 1) + 10.083 us   |        }
 1) + 10.985 us   |      }
 1)               |      irq_exit() {
 1)               |        rcu_irq_exit() {
 1)   0.087 us    |          rcu_enter_nohz();
 1)   0.429 us    |        }
 1)   0.049 us    |        idle_cpu();
 1)   1.088 us    |      }
 1) + 14.551 us   |    }
 1)   0.191 us    |    } /* __inet_lookup_established */

--047d7b6da0c4e9a59504cc9c1755
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,=A0

Is anybody know the purpose of this method (xen_e=
vtchn_do_upcall)? When I run a user level application involved in TCP recei=
ving and the SoftIRQ for eth0 on the same CPU core, everything is OK. But i=
f I run them on 2 different cores, there will be xen_evtchn_do_upcall() exi=
sting (maybe when the=A0lo=
cal_bh_disable() or=A0local_bh_enable() is cal=
led) in=A0__inet_lookup_established() routine which costs longer tim=
e than the first scenario. Is it due to the synchronization issue between p=
rocess context and softirq context? Thanks for any reply.=A0



=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0__inet_=
lookup_established() {
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =
=A0xen_evtchn_do_upcall() {
=A01) =A0 0.054 us =A0 =A0| =A0 =A0 =
=A0exit_idle();
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0ir=
q_enter() {


=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0rcu_irq_enter() {
=A01) =A0 0.102 us =A0 =A0| =A0 =A0 =A0 =A0 =A0rcu_exit_nohz();
=A01) =A0 0.431 us =A0 =A0| =A0 =A0 =A0 =A0}
=A01) =A0 0.=
064 us =A0 =A0| =A0 =A0 =A0 =A0idle_cpu();
=A01) =A0 1.152 us =A0=
 =A0| =A0 =A0 =A0}


=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0__xen_evtchn_do_upcall(=
) {
=A01) =A0 0.119 us =A0 =A0| =A0 =A0 =A0 =A0irq_to_desc();
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0handle_edge_irq()=
 {
=A01) =A0 0.107 us =A0 =A0| =A0 =A0 =A0 =A0 =A0_raw_spin_lock(=
);


=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0ack_dynirq() {<=
/div>
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0evtchn=
_from_irq() {
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0=
 =A0 =A0 =A0info_for_irq() {
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0irq_get_irq_data() {


=A01) =A0 0.052 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0irq_to_=
desc();
=A01) =A0 0.418 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0}
=A01) =A0 0.782 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0}
=A01) =A0 1.135 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0}
=A01)=
 =A0 0.049 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0irq_move_irq();


=A01) =A0 1.800 us =A0 =A0| =A0 =A0 =A0 =A0 =A0}
=A01) =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0handle_irq_event() {
=A01) =A0 0.161 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0_raw_spin_unlock();
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0handle_ir=
q_event_percpu() {


=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0xennet_=
interrupt() {
=A01) =A0 0.125 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0_raw_spin_lock_irqsave();
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0xennet_tx_buf_gc() {
=A01) =
=A0 0.079 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gnttab_query_forei=
gn_access();


=A01) =A0 0.050 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gnttab_=
end_foreign_access_ref();
=A01) =A0 0.069 us =A0 =A0| =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0gnttab_release_grant_reference();
=A01) =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dev_kfree_=
skb_irq() {


=A01) =A0 0.055 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0rai=
se_softirq_irqoff();
=A01) =A0 0.472 us =A0 =A0| =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0}
=A01) =A0 0.049 us =A0 =A0| =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0gnttab_query_foreign_access();
=A01) =A0 0.058=
 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gnttab_end_foreign_access_r=
ef();


=A01) =A0 0.058 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gnttab_=
release_grant_reference();
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dev_kfree_skb_irq() {
=A01) =
=A0 0.050 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0raise_softirq_=
irqoff();


=A01) =A0 0.456 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
=

=A01) =A0 3.714 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
=A01) =A0 0.102 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0_raw_spin_unloc=
k_irqrestore();
=A01) =A0 4.857 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =
=A0 =A0}

=A01) =A0 0.061 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0note_interrupt();
=A01) =A0 5.571 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0}
=A01=
) =A0 0.054 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0_raw_spin_lock();
=
=A01) =A0 6.707 us =A0 =A0| =A0 =A0 =A0 =A0 =A0}
=A01) =A0 0.083 =
us =A0 =A0| =A0 =A0 =A0 =A0 =A0_raw_spin_unlock();


=A01) + 10.083 us =A0 | =A0 =A0 =A0 =A0}
=A01) + 10.985 us =
=A0 | =A0 =A0 =A0}
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =
=A0irq_exit() {
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =
=A0rcu_irq_exit() {
=A01) =A0 0.087 us =A0 =A0| =A0 =A0 =A0 =A0 =
=A0rcu_enter_nohz();


=A01) =A0 0.429 us =A0 =A0| =A0 =A0 =A0 =A0}
=A01) =A0 0.049=
 us =A0 =A0| =A0 =A0 =A0 =A0idle_cpu();
=A01) =A0 1.088 us =A0 =
=A0| =A0 =A0 =A0}
=A01) + 14.551 us =A0 | =A0 =A0}
=A01=
) =A0 0.191 us =A0 =A0| =A0 =A0} /* __inet_lookup_established */




--047d7b6da0c4e9a59504cc9c1755--


--===============4169225456190317963==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4169225456190317963==--


From xen-devel-bounces@lists.xen.org Mon Oct 22 04:37:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 04:37:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQ9l1-0001Zv-Fj; Mon, 22 Oct 2012 04:36:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQ9kz-0001Zq-O1
	for xen-devel@lists.xensource.com; Mon, 22 Oct 2012 04:36:53 +0000
Received: from [85.158.143.99:42930] by server-1.bemta-4.messagelabs.com id
	6F/47-19134-46DC4805; Mon, 22 Oct 2012 04:36:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1350880612!34965186!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUxNTc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11082 invoked from network); 22 Oct 2012 04:36:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 04:36:52 -0000
X-IronPort-AV: E=Sophos;i="4.80,628,1344211200"; d="scan'208";a="15297999"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Oct 2012 04:36:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Mon, 22 Oct 2012 05:36:51 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TQ9kw-0003jA-Oe;
	Mon, 22 Oct 2012 04:36:50 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TQ9kw-0000Xf-82;
	Mon, 22 Oct 2012 05:36:50 +0100
To: 
Message-ID: 
From: xen.org 
Date: Mon, 22 Oct 2012 05:36:50 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14067: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14067 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14067/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 14066
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 14066
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 14066
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 14065

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  478ba3f146df
baseline version:
 xen                  478ba3f146df

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 04:37:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 04:37:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQ9l1-0001Zv-Fj; Mon, 22 Oct 2012 04:36:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQ9kz-0001Zq-O1
	for xen-devel@lists.xensource.com; Mon, 22 Oct 2012 04:36:53 +0000
Received: from [85.158.143.99:42930] by server-1.bemta-4.messagelabs.com id
	6F/47-19134-46DC4805; Mon, 22 Oct 2012 04:36:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1350880612!34965186!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUxNTc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11082 invoked from network); 22 Oct 2012 04:36:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 04:36:52 -0000
X-IronPort-AV: E=Sophos;i="4.80,628,1344211200"; d="scan'208";a="15297999"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Oct 2012 04:36:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Mon, 22 Oct 2012 05:36:51 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TQ9kw-0003jA-Oe;
	Mon, 22 Oct 2012 04:36:50 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TQ9kw-0000Xf-82;
	Mon, 22 Oct 2012 05:36:50 +0100
To: 
Message-ID: 
From: xen.org 
Date: Mon, 22 Oct 2012 05:36:50 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14067: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14067 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14067/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 14066
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 14066
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 14066
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 14065

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  478ba3f146df
baseline version:
 xen                  478ba3f146df

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 06:32:33 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 06:32:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQBYI-0002Cm-C0; Mon, 22 Oct 2012 06:31:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQ2Vf-0002Zj-QL; Sun, 21 Oct 2012 20:52:36 +0000
Received: from [85.158.143.99:38000] by server-2.bemta-4.messagelabs.com id
	1D/DB-22268-29064805; Sun, 21 Oct 2012 20:52:34 +0000
X-Env-Sender: mrsanna1@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1350852752!34941474!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10239 invoked from network); 21 Oct 2012 20:52:34 -0000
Received: from mail-vc0-f171.google.com (HELO mail-vc0-f171.google.com)
	(209.85.220.171)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Oct 2012 20:52:34 -0000
Received: by mail-vc0-f171.google.com with SMTP id m18so2792023vcm.30
	for ; Sun, 21 Oct 2012 13:52:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=WX0VyY6xNnzWimpD6Iy9k9t/i1K7IKMtuzfLxudwQpI=;
	b=pLCj3oMs9+yDf1w9IoSXXezG4QeyQg/hJiZ6KSvjDeqdWNceODoMbCpJkB9FP/zme5
	X0aRo6XNNDuCbxgZV6/UvsOkc6NJYnEl3mSAP6bYlBaIMCDpBPDmVtEWwj5CAQGE9iO/
	Pq6tDsKht3jlBrFsHfRE5dSIvYmvZg6j/E+H8Lk4/XuQtCVTo0wjTh56phG6nbH6J/iw
	7ANgWKhtU20zz5KMJC75GWpEGT8J8wciCzpS3Ayn/nfqP8sXIATu2wesN7pU9f1yPyzE
	CHEvlERC8wRy3JTshlyGlyENxIEsqVD6BmzIsCTd7W/nfwWLpP3PP5nUhKQQ/54fQ4Ms
	TX8A==
MIME-Version: 1.0
Received: by 10.52.76.103 with SMTP id j7mr9258355vdw.22.1350852752418; Sun,
	21 Oct 2012 13:52:32 -0700 (PDT)
Received: by 10.58.207.75 with HTTP; Sun, 21 Oct 2012 13:52:32 -0700 (PDT)
In-Reply-To: <507C226A02000078000A1657@nat28.tlf.novell.com>
References: 
	
	
	
	<65395f62-74e5-4910-b701-8df629c2ce3b@default>
	
	
	
	
	
	<20120930151314.GU8912@reaktio.net>
	
	
	
	<507C024602000078000A155C@nat28.tlf.novell.com>
	
	<507C226A02000078000A1657@nat28.tlf.novell.com>
Date: Sun, 21 Oct 2012 22:52:32 +0200
Message-ID: 
From: Mauro 
To: Jan Beulich 
X-Mailman-Approved-At: Mon, 22 Oct 2012 06:31:53 +0000
Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com,
	Keir Fraser , Dan Magenheimer ,
	Olivier Hanesse ,
	Keir Fraser ,
	Xen Users ,
	Mark Adams 
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 15 October 2012 14:49, Jan Beulich  wrote:
>>>> On 15.10.12 at 13:24, Mauro  wrote:
>> I have the problem on this hardware type:
>>
>> Hp Proliant DL580 G5 with four Intel(R) Xeon(R) CPU E7330  @ 2.40GHz.
>> It seem that
>> GRUB_CMDLINE_XEN="clocksource=pit cpuidle=0"
>> put in in /etc/default/grup (I use linux debian)
>> solves the problem for me.
>
> Did you check whether either or both options on their own also
> make the problem go away?

It seems that with debian squeeze on my HP Proliant Dl 580 G5 servers
is sufficient to use
GRUB_CMDLINE_XEN="cpuidle=0".
Is from about 20 days that I have no clock jumps.
Before I had a clock jump every week.
Hope this is the final workaround for me.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 06:32:33 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 06:32:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQBYI-0002Cm-C0; Mon, 22 Oct 2012 06:31:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQ2Vf-0002Zj-QL; Sun, 21 Oct 2012 20:52:36 +0000
Received: from [85.158.143.99:38000] by server-2.bemta-4.messagelabs.com id
	1D/DB-22268-29064805; Sun, 21 Oct 2012 20:52:34 +0000
X-Env-Sender: mrsanna1@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1350852752!34941474!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10239 invoked from network); 21 Oct 2012 20:52:34 -0000
Received: from mail-vc0-f171.google.com (HELO mail-vc0-f171.google.com)
	(209.85.220.171)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Oct 2012 20:52:34 -0000
Received: by mail-vc0-f171.google.com with SMTP id m18so2792023vcm.30
	for ; Sun, 21 Oct 2012 13:52:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=WX0VyY6xNnzWimpD6Iy9k9t/i1K7IKMtuzfLxudwQpI=;
	b=pLCj3oMs9+yDf1w9IoSXXezG4QeyQg/hJiZ6KSvjDeqdWNceODoMbCpJkB9FP/zme5
	X0aRo6XNNDuCbxgZV6/UvsOkc6NJYnEl3mSAP6bYlBaIMCDpBPDmVtEWwj5CAQGE9iO/
	Pq6tDsKht3jlBrFsHfRE5dSIvYmvZg6j/E+H8Lk4/XuQtCVTo0wjTh56phG6nbH6J/iw
	7ANgWKhtU20zz5KMJC75GWpEGT8J8wciCzpS3Ayn/nfqP8sXIATu2wesN7pU9f1yPyzE
	CHEvlERC8wRy3JTshlyGlyENxIEsqVD6BmzIsCTd7W/nfwWLpP3PP5nUhKQQ/54fQ4Ms
	TX8A==
MIME-Version: 1.0
Received: by 10.52.76.103 with SMTP id j7mr9258355vdw.22.1350852752418; Sun,
	21 Oct 2012 13:52:32 -0700 (PDT)
Received: by 10.58.207.75 with HTTP; Sun, 21 Oct 2012 13:52:32 -0700 (PDT)
In-Reply-To: <507C226A02000078000A1657@nat28.tlf.novell.com>
References: 
	
	
	
	<65395f62-74e5-4910-b701-8df629c2ce3b@default>
	
	
	
	
	
	<20120930151314.GU8912@reaktio.net>
	
	
	
	<507C024602000078000A155C@nat28.tlf.novell.com>
	
	<507C226A02000078000A1657@nat28.tlf.novell.com>
Date: Sun, 21 Oct 2012 22:52:32 +0200
Message-ID: 
From: Mauro 
To: Jan Beulich 
X-Mailman-Approved-At: Mon, 22 Oct 2012 06:31:53 +0000
Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com,
	Keir Fraser , Dan Magenheimer ,
	Olivier Hanesse ,
	Keir Fraser ,
	Xen Users ,
	Mark Adams 
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 15 October 2012 14:49, Jan Beulich  wrote:
>>>> On 15.10.12 at 13:24, Mauro  wrote:
>> I have the problem on this hardware type:
>>
>> Hp Proliant DL580 G5 with four Intel(R) Xeon(R) CPU E7330  @ 2.40GHz.
>> It seem that
>> GRUB_CMDLINE_XEN="clocksource=pit cpuidle=0"
>> put in in /etc/default/grup (I use linux debian)
>> solves the problem for me.
>
> Did you check whether either or both options on their own also
> make the problem go away?

It seems that with debian squeeze on my HP Proliant Dl 580 G5 servers
is sufficient to use
GRUB_CMDLINE_XEN="cpuidle=0".
Is from about 20 days that I have no clock jumps.
Before I had a clock jump every week.
Hope this is the final workaround for me.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 06:47:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 06:47:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQBnO-0002NP-Re; Mon, 22 Oct 2012 06:47:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQBnN-0002NK-Cx
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 06:47:29 +0000
Received: from [85.158.137.99:53718] by server-11.bemta-3.messagelabs.com id
	20/91-24008-00CE4805; Mon, 22 Oct 2012 06:47:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1350888448!22446760!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21767 invoked from network); 22 Oct 2012 06:47:28 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-217.messagelabs.com with SMTP;
	22 Oct 2012 06:47:28 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 22 Oct 2012 07:47:27 +0100
Message-Id: <5085081C02000078000A2DCC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 22 Oct 2012 07:47:24 +0100
From: "Jan Beulich" 
To: "Konrad Rzeszutek Wilk" 
References: <507D6F3D02000078000A1B13@nat28.tlf.novell.com>
	<507D814D02000078000A1B51@nat28.tlf.novell.com>
	<20121019192300.GA20513@phenom.dumpdata.com>
In-Reply-To: <20121019192300.GA20513@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Campbell ,
	Dan Carpenter ,
	xen-devel 
Subject: Re: [Xen-devel] [PATCH,
 v2] linux-2.6.18: fix hypercall fallback code for very old
 hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 19.10.12 at 21:23, Konrad Rzeszutek Wilk  wrote:
> On Tue, Oct 16, 2012 at 02:46:21PM +0100, Jan Beulich wrote:
>> While copying the argument structures in HYPERVISOR_event_channel_op()
>> and HYPERVISOR_physdev_op() into the local variable is sufficiently
>> safe even if the actual structure is smaller than the container one,
>> copying back eventual output values the same way isn't: This may
>> collide with on-stack variables (particularly "rc") which may change
>> between the first and second memcpy() (i.e. the second memcpy() could
>> discard that change).
>> 
>> Move the fallback code into out-of-line functions, and handle all of
>> the operations known by this old a hypervisor individually: Some don't
>> require copying back anything at all, and for the rest use the
>> individual argument structures' sizes rather than the container's.
>> 
>> Reported-by: Dan Carpenter 
>> Signed-off-by: Jan Beulich 
>> ---
>> v2: Reduce #define/#undef usage in HYPERVISOR_physdev_op_compat().
>> 
>> --- a/drivers/xen/core/Makefile
>> +++ b/drivers/xen/core/Makefile
>> @@ -2,7 +2,7 @@
>>  # Makefile for the linux kernel.
>>  #
>>  
>> -obj-y := evtchn.o gnttab.o features.o reboot.o machine_reboot.o
>> +obj-y := evtchn.o gnttab.o features.o reboot.o machine_reboot.o fallback.o
>>  
>>  obj-$(CONFIG_PCI)		+= pci.o
>>  obj-$(CONFIG_XEN_PRIVILEGED_GUEST) += firmware.o
>> --- /dev/null
>> +++ b/drivers/xen/core/fallback.c
>> @@ -0,0 +1,84 @@
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#if 1//temp CONFIG_XEN_COMPAT <= 0x030002
> 
> Um?

Spotted this left-over (from build testing) before committing,
luckily. Thanks for noticing nevertheless!

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 06:47:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 06:47:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQBnO-0002NP-Re; Mon, 22 Oct 2012 06:47:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQBnN-0002NK-Cx
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 06:47:29 +0000
Received: from [85.158.137.99:53718] by server-11.bemta-3.messagelabs.com id
	20/91-24008-00CE4805; Mon, 22 Oct 2012 06:47:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1350888448!22446760!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21767 invoked from network); 22 Oct 2012 06:47:28 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-217.messagelabs.com with SMTP;
	22 Oct 2012 06:47:28 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 22 Oct 2012 07:47:27 +0100
Message-Id: <5085081C02000078000A2DCC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 22 Oct 2012 07:47:24 +0100
From: "Jan Beulich" 
To: "Konrad Rzeszutek Wilk" 
References: <507D6F3D02000078000A1B13@nat28.tlf.novell.com>
	<507D814D02000078000A1B51@nat28.tlf.novell.com>
	<20121019192300.GA20513@phenom.dumpdata.com>
In-Reply-To: <20121019192300.GA20513@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Campbell ,
	Dan Carpenter ,
	xen-devel 
Subject: Re: [Xen-devel] [PATCH,
 v2] linux-2.6.18: fix hypercall fallback code for very old
 hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 19.10.12 at 21:23, Konrad Rzeszutek Wilk  wrote:
> On Tue, Oct 16, 2012 at 02:46:21PM +0100, Jan Beulich wrote:
>> While copying the argument structures in HYPERVISOR_event_channel_op()
>> and HYPERVISOR_physdev_op() into the local variable is sufficiently
>> safe even if the actual structure is smaller than the container one,
>> copying back eventual output values the same way isn't: This may
>> collide with on-stack variables (particularly "rc") which may change
>> between the first and second memcpy() (i.e. the second memcpy() could
>> discard that change).
>> 
>> Move the fallback code into out-of-line functions, and handle all of
>> the operations known by this old a hypervisor individually: Some don't
>> require copying back anything at all, and for the rest use the
>> individual argument structures' sizes rather than the container's.
>> 
>> Reported-by: Dan Carpenter 
>> Signed-off-by: Jan Beulich 
>> ---
>> v2: Reduce #define/#undef usage in HYPERVISOR_physdev_op_compat().
>> 
>> --- a/drivers/xen/core/Makefile
>> +++ b/drivers/xen/core/Makefile
>> @@ -2,7 +2,7 @@
>>  # Makefile for the linux kernel.
>>  #
>>  
>> -obj-y := evtchn.o gnttab.o features.o reboot.o machine_reboot.o
>> +obj-y := evtchn.o gnttab.o features.o reboot.o machine_reboot.o fallback.o
>>  
>>  obj-$(CONFIG_PCI)		+= pci.o
>>  obj-$(CONFIG_XEN_PRIVILEGED_GUEST) += firmware.o
>> --- /dev/null
>> +++ b/drivers/xen/core/fallback.c
>> @@ -0,0 +1,84 @@
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#if 1//temp CONFIG_XEN_COMPAT <= 0x030002
> 
> Um?

Spotted this left-over (from build testing) before committing,
luckily. Thanks for noticing nevertheless!

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 06:55:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 06:55:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQBub-0002Y9-Tn; Mon, 22 Oct 2012 06:54:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQBua-0002Y1-3C; Mon, 22 Oct 2012 06:54:56 +0000
Received: from [85.158.137.99:30348] by server-5.bemta-3.messagelabs.com id
	1A/CA-12440-FBDE4805; Mon, 22 Oct 2012 06:54:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1350888894!19354884!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32698 invoked from network); 22 Oct 2012 06:54:54 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-217.messagelabs.com with SMTP;
	22 Oct 2012 06:54:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 22 Oct 2012 07:54:53 +0100
Message-Id: <508509D902000078000A2DDA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 22 Oct 2012 07:54:49 +0100
From: "Jan Beulich" 
To: "Mauro" 
References: 
	
	
	
	<65395f62-74e5-4910-b701-8df629c2ce3b@default>
	
	
	
	
	
	<20120930151314.GU8912@reaktio.net>
	
	
	
	<507C024602000078000A155C@nat28.tlf.novell.com>
	
	<507C226A02000078000A1657@nat28.tlf.novell.com>
	
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com,
	Keir Fraser , Dan Magenheimer ,
	Olivier Hanesse ,
	Keir Fraser ,
	Xen Users ,
	Mark Adams 
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 21.10.12 at 22:52, Mauro  wrote:
> On 15 October 2012 14:49, Jan Beulich  wrote:
>>>>> On 15.10.12 at 13:24, Mauro  wrote:
>>> I have the problem on this hardware type:
>>>
>>> Hp Proliant DL580 G5 with four Intel(R) Xeon(R) CPU E7330  @ 2.40GHz.
>>> It seem that
>>> GRUB_CMDLINE_XEN="clocksource=pit cpuidle=0"
>>> put in in /etc/default/grup (I use linux debian)
>>> solves the problem for me.
>>
>> Did you check whether either or both options on their own also
>> make the problem go away?
> 
> It seems that with debian squeeze on my HP Proliant Dl 580 G5 servers
> is sufficient to use
> GRUB_CMDLINE_XEN="cpuidle=0".
> Is from about 20 days that I have no clock jumps.
> Before I had a clock jump every week.
> Hope this is the final workaround for me.

So what's the contents of /proc/cpuinfo (any one CPU suffices)
under a native recent kernel on that system? The most likely
issue here is that we're mis-identifying the CPU as having an
always running APIC timer (ARAT)...

For a second, less intrusive try: Could you replace "cpuidle=0"
with "max_cstate=1" (assuming the former didn't meanwhile
turn out not to cure the problem)? If that works too (expected),
try "max_cstate=2" followed eventually by
"max_cstate=2 local_apic_timer_c2_ok".

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 06:55:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 06:55:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQBub-0002Y9-Tn; Mon, 22 Oct 2012 06:54:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQBua-0002Y1-3C; Mon, 22 Oct 2012 06:54:56 +0000
Received: from [85.158.137.99:30348] by server-5.bemta-3.messagelabs.com id
	1A/CA-12440-FBDE4805; Mon, 22 Oct 2012 06:54:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1350888894!19354884!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32698 invoked from network); 22 Oct 2012 06:54:54 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-217.messagelabs.com with SMTP;
	22 Oct 2012 06:54:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 22 Oct 2012 07:54:53 +0100
Message-Id: <508509D902000078000A2DDA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 22 Oct 2012 07:54:49 +0100
From: "Jan Beulich" 
To: "Mauro" 
References: 
	
	
	
	<65395f62-74e5-4910-b701-8df629c2ce3b@default>
	
	
	
	
	
	<20120930151314.GU8912@reaktio.net>
	
	
	
	<507C024602000078000A155C@nat28.tlf.novell.com>
	
	<507C226A02000078000A1657@nat28.tlf.novell.com>
	
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com,
	Keir Fraser , Dan Magenheimer ,
	Olivier Hanesse ,
	Keir Fraser ,
	Xen Users ,
	Mark Adams 
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 21.10.12 at 22:52, Mauro  wrote:
> On 15 October 2012 14:49, Jan Beulich  wrote:
>>>>> On 15.10.12 at 13:24, Mauro  wrote:
>>> I have the problem on this hardware type:
>>>
>>> Hp Proliant DL580 G5 with four Intel(R) Xeon(R) CPU E7330  @ 2.40GHz.
>>> It seem that
>>> GRUB_CMDLINE_XEN="clocksource=pit cpuidle=0"
>>> put in in /etc/default/grup (I use linux debian)
>>> solves the problem for me.
>>
>> Did you check whether either or both options on their own also
>> make the problem go away?
> 
> It seems that with debian squeeze on my HP Proliant Dl 580 G5 servers
> is sufficient to use
> GRUB_CMDLINE_XEN="cpuidle=0".
> Is from about 20 days that I have no clock jumps.
> Before I had a clock jump every week.
> Hope this is the final workaround for me.

So what's the contents of /proc/cpuinfo (any one CPU suffices)
under a native recent kernel on that system? The most likely
issue here is that we're mis-identifying the CPU as having an
always running APIC timer (ARAT)...

For a second, less intrusive try: Could you replace "cpuidle=0"
with "max_cstate=1" (assuming the former didn't meanwhile
turn out not to cure the problem)? If that works too (expected),
try "max_cstate=2" followed eventually by
"max_cstate=2 local_apic_timer_c2_ok".

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 09:04:50 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 09:04:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQDvo-00041f-7c; Mon, 22 Oct 2012 09:04:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQDvm-00041a-G0
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 09:04:18 +0000
Received: from [85.158.137.99:29887] by server-5.bemta-3.messagelabs.com id
	17/60-12440-11C05805; Mon, 22 Oct 2012 09:04:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1350896656!20128524!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16260 invoked from network); 22 Oct 2012 09:04:17 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-217.messagelabs.com with SMTP;
	22 Oct 2012 09:04:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 22 Oct 2012 10:04:15 +0100
Message-Id: <5085282C02000078000A2E28@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 22 Oct 2012 10:04:12 +0100
From: "Jan Beulich" 
To: "Chien-Hua Yen" 
References: <50819FC3.5050308@oracle.com>
In-Reply-To: <50819FC3.5050308@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Why guest is disallowed to change mask bit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 19.10.12 at 20:45, Chien-Hua Yen  wrote:
> I am curious to know why Xen disallows guest to change the mask bit of 
> MSI-X
> vector control as show in the comment out section in msixtbl_write().
> Our SR-IOV driver got driver reload failure because it cannot enable 
> interrupt.
> 
>       /* Do not allow the mask bit to be changed. */
> #if 0 /* XXX
>         * As the mask bit is the only defined bit in the word, and as the
>         * host MSI-X code doesn't preserve the other bits anyway, doing
>         * this is pointless. So for now just discard the write (also
>         * saving us from having to determine the matching irq_desc).
>         */
>      spin_lock_irqsave(&desc->lock, flags);
>      orig = readl(virt);
>      val &= ~PCI_MSIX_VECTOR_BITMASK;
>      val |= orig & PCI_MSIX_VECTOR_BITMASK;
>      writel(val, virt);
>      spin_unlock_irqrestore(&desc->lock, flags);
> #endif
> 
>      r = X86EMUL_OKAY;

Did you look for the conversation that happened before this
change got committed? As the XXX pretty clearly indicates, the
code ought to not be commented out, but the hypervisor
and/or qemu would have to emulate the mask bit - guests can't
be permitted write access to the bit because the hypervisor itself
makes use of it.

At the time when the change above was discussed, no drivers
were known that would play with that bit during normal
operation, and hence there was no immediate need to implement
the missing emulation. Unless caused by a bug elsewhere (which
seems possible given the context you provided in private mail),
the only chance for addressing your  problem would be to add
that implementation now. Simply uncommenting the code above
ought to not help (or if it does [on a hypervisor having -unstable
c/s 24805:618cbd27bac0], it would indicate that the security
problem intended to be fixed with this and the other associated
changes is actually still present).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 09:04:50 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 09:04:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQDvo-00041f-7c; Mon, 22 Oct 2012 09:04:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQDvm-00041a-G0
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 09:04:18 +0000
Received: from [85.158.137.99:29887] by server-5.bemta-3.messagelabs.com id
	17/60-12440-11C05805; Mon, 22 Oct 2012 09:04:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1350896656!20128524!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16260 invoked from network); 22 Oct 2012 09:04:17 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-217.messagelabs.com with SMTP;
	22 Oct 2012 09:04:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 22 Oct 2012 10:04:15 +0100
Message-Id: <5085282C02000078000A2E28@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 22 Oct 2012 10:04:12 +0100
From: "Jan Beulich" 
To: "Chien-Hua Yen" 
References: <50819FC3.5050308@oracle.com>
In-Reply-To: <50819FC3.5050308@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Why guest is disallowed to change mask bit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 19.10.12 at 20:45, Chien-Hua Yen  wrote:
> I am curious to know why Xen disallows guest to change the mask bit of 
> MSI-X
> vector control as show in the comment out section in msixtbl_write().
> Our SR-IOV driver got driver reload failure because it cannot enable 
> interrupt.
> 
>       /* Do not allow the mask bit to be changed. */
> #if 0 /* XXX
>         * As the mask bit is the only defined bit in the word, and as the
>         * host MSI-X code doesn't preserve the other bits anyway, doing
>         * this is pointless. So for now just discard the write (also
>         * saving us from having to determine the matching irq_desc).
>         */
>      spin_lock_irqsave(&desc->lock, flags);
>      orig = readl(virt);
>      val &= ~PCI_MSIX_VECTOR_BITMASK;
>      val |= orig & PCI_MSIX_VECTOR_BITMASK;
>      writel(val, virt);
>      spin_unlock_irqrestore(&desc->lock, flags);
> #endif
> 
>      r = X86EMUL_OKAY;

Did you look for the conversation that happened before this
change got committed? As the XXX pretty clearly indicates, the
code ought to not be commented out, but the hypervisor
and/or qemu would have to emulate the mask bit - guests can't
be permitted write access to the bit because the hypervisor itself
makes use of it.

At the time when the change above was discussed, no drivers
were known that would play with that bit during normal
operation, and hence there was no immediate need to implement
the missing emulation. Unless caused by a bug elsewhere (which
seems possible given the context you provided in private mail),
the only chance for addressing your  problem would be to add
that implementation now. Simply uncommenting the code above
ought to not help (or if it does [on a hypervisor having -unstable
c/s 24805:618cbd27bac0], it would indicate that the security
problem intended to be fixed with this and the other associated
changes is actually still present).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 09:27:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 09:27:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQEHz-0004Sb-1Z; Mon, 22 Oct 2012 09:27:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQEHy-0004ST-0G; Mon, 22 Oct 2012 09:27:14 +0000
Received: from [85.158.138.51:15903] by server-7.bemta-3.messagelabs.com id
	72/7E-06991-17115805; Mon, 22 Oct 2012 09:27:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1350898032!27667904!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31473 invoked from network); 22 Oct 2012 09:27:12 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-174.messagelabs.com with SMTP;
	22 Oct 2012 09:27:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 22 Oct 2012 10:27:11 +0100
Message-Id: <50852D8C02000078000A2E48@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 22 Oct 2012 10:27:08 +0100
From: "Jan Beulich" 
To: "Mauro" 
References: 
	
	
	
	<65395f62-74e5-4910-b701-8df629c2ce3b@default>
	
	
	
	
	
	<20120930151314.GU8912@reaktio.net>
	
	
	
	<507C024602000078000A155C@nat28.tlf.novell.com>
	
	<507C226A02000078000A1657@nat28.tlf.novell.com>
	
	<508509D902000078000A2DDA@nat28.tlf.novell.com>
	
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com,
	Keir Fraser , Dan Magenheimer ,
	Olivier Hanesse ,
	Keir Fraser ,
	Xen Users ,
	Mark Adams 
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 22.10.12 at 11:17, Mauro  wrote:
> On 22 October 2012 08:54, Jan Beulich  wrote:
>>>>> On 21.10.12 at 22:52, Mauro  wrote:
>>> On 15 October 2012 14:49, Jan Beulich  wrote:
>> So what's the contents of /proc/cpuinfo (any one CPU suffices)
>> under a native recent kernel on that system? The most likely
>> issue here is that we're mis-identifying the CPU as having an
>> always running APIC timer (ARAT)...
> 
> uname -a
> 
> Linux xen-p01 2.6.32-5-xen-amd64 #1 SMP Sun Sep 23 13:49:30 UTC 2012
> x86_64 GNU/Linux

I had specifically asked to do this under a _native_ kernel.

> cat /proc/cpuinfo
> 
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 15
> model name      : Intel(R) Xeon(R) CPU           E7330  @ 2.40GHz
> stepping        : 11
> cpu MHz         : 2400.176
> cache size      : 3072 KB
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 10
> wp              : yes
> flags           : fpu de tsc msr pae mce cx8 apic sep mtrr mca cmov
> pat clflush acpi mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc
> rep_good aperfmperf pni est ssse3 cx16 hypervisor lahf_lm
> bogomips        : 4800.35
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 40 bits physical, 48 bits virtual
> power management:
> 
>>
>> For a second, less intrusive try: Could you replace "cpuidle=0"
>> with "max_cstate=1" (assuming the former didn't meanwhile
>> turn out not to cure the problem)? If that works too (expected),
>> try "max_cstate=2" followed eventually by
>> "max_cstate=2 local_apic_timer_c2_ok".
> 
> I'll try but to say that it works I've to wait at least two weeks.

I understand that this takes quite a bit of time.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 09:27:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 09:27:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQEHz-0004Sb-1Z; Mon, 22 Oct 2012 09:27:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQEHy-0004ST-0G; Mon, 22 Oct 2012 09:27:14 +0000
Received: from [85.158.138.51:15903] by server-7.bemta-3.messagelabs.com id
	72/7E-06991-17115805; Mon, 22 Oct 2012 09:27:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1350898032!27667904!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31473 invoked from network); 22 Oct 2012 09:27:12 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-174.messagelabs.com with SMTP;
	22 Oct 2012 09:27:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 22 Oct 2012 10:27:11 +0100
Message-Id: <50852D8C02000078000A2E48@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 22 Oct 2012 10:27:08 +0100
From: "Jan Beulich" 
To: "Mauro" 
References: 
	
	
	
	<65395f62-74e5-4910-b701-8df629c2ce3b@default>
	
	
	
	
	
	<20120930151314.GU8912@reaktio.net>
	
	
	
	<507C024602000078000A155C@nat28.tlf.novell.com>
	
	<507C226A02000078000A1657@nat28.tlf.novell.com>
	
	<508509D902000078000A2DDA@nat28.tlf.novell.com>
	
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com,
	Keir Fraser , Dan Magenheimer ,
	Olivier Hanesse ,
	Keir Fraser ,
	Xen Users ,
	Mark Adams 
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 22.10.12 at 11:17, Mauro  wrote:
> On 22 October 2012 08:54, Jan Beulich  wrote:
>>>>> On 21.10.12 at 22:52, Mauro  wrote:
>>> On 15 October 2012 14:49, Jan Beulich  wrote:
>> So what's the contents of /proc/cpuinfo (any one CPU suffices)
>> under a native recent kernel on that system? The most likely
>> issue here is that we're mis-identifying the CPU as having an
>> always running APIC timer (ARAT)...
> 
> uname -a
> 
> Linux xen-p01 2.6.32-5-xen-amd64 #1 SMP Sun Sep 23 13:49:30 UTC 2012
> x86_64 GNU/Linux

I had specifically asked to do this under a _native_ kernel.

> cat /proc/cpuinfo
> 
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 15
> model name      : Intel(R) Xeon(R) CPU           E7330  @ 2.40GHz
> stepping        : 11
> cpu MHz         : 2400.176
> cache size      : 3072 KB
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 10
> wp              : yes
> flags           : fpu de tsc msr pae mce cx8 apic sep mtrr mca cmov
> pat clflush acpi mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc
> rep_good aperfmperf pni est ssse3 cx16 hypervisor lahf_lm
> bogomips        : 4800.35
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 40 bits physical, 48 bits virtual
> power management:
> 
>>
>> For a second, less intrusive try: Could you replace "cpuidle=0"
>> with "max_cstate=1" (assuming the former didn't meanwhile
>> turn out not to cure the problem)? If that works too (expected),
>> try "max_cstate=2" followed eventually by
>> "max_cstate=2 local_apic_timer_c2_ok".
> 
> I'll try but to say that it works I've to wait at least two weeks.

I understand that this takes quite a bit of time.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 10:12:18 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 10:12:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQEz4-00059C-Ds; Mon, 22 Oct 2012 10:11:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQEz2-000594-BD; Mon, 22 Oct 2012 10:11:44 +0000
Received: from [193.109.254.147:53348] by server-7.bemta-14.messagelabs.com id
	98/85-24122-FDB15805; Mon, 22 Oct 2012 10:11:43 +0000
X-Env-Sender: hufan@websense.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1350900699!6246879!1
X-Originating-IP: [208.87.233.190]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljg3LjIzMy4xOTAgPT4gMTc4NDY1Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23951 invoked from network); 22 Oct 2012 10:11:42 -0000
Received: from cluster-g.mailcontrol.com (HELO cluster-g.mailcontrol.com)
	(208.87.233.190)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Oct 2012 10:11:42 -0000
Received: from ssdwbsnapp.websense.com (static-204-15-65-158.websense.com
	[204.15.65.158] (may be forged))
	by rly24g.srv.mailcontrol.com (MailControl) with ESMTP id
	q9MAB66O019247
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 22 Oct 2012 11:11:22 +0100
Received: from SSDEXCH1A.websense.com (unknown [10.8.1.91])
	by Websense Email Security Gateway with ESMTP id 20CB41000014;
	Mon, 22 Oct 2012 03:11:04 -0700 (PDT)
Received: from ssdexch3b.websense.com (10.8.3.169) by SSDEXCH1A.websense.com
	(10.8.1.91) with Microsoft SMTP Server (TLS) id 14.2.283.3;
	Mon, 22 Oct 2012 03:11:06 -0700
Received: from SBJEXCH2B.websense.com (10.32.8.112) by ssdexch3b.websense.com
	(10.8.3.169) with Microsoft SMTP Server (TLS) id 14.2.283.3;
	Mon, 22 Oct 2012 03:11:05 -0700
Received: from SBJEXCH1B.websense.com ([169.254.2.203]) by
	SBJEXCH2B.websense.com ([::1]) with mapi id 14.02.0283.003;
	Mon, 22 Oct 2012 18:11:01 +0800
From: "Fan, Huaxiang" 
To: "xen-devel@lists.xen.org" 
Thread-Topic: e820_host problems
Thread-Index: Ac2wO6t52kDU66w/TymQ9bR6YOep8A==
Date: Mon, 22 Oct 2012 10:11:00 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.32.134.111]
Content-Type: multipart/mixed;
	boundary="_006_E71FC5D6F96C3C4B93FC8FF942D924C682F44808SBJEXCH1Bwebsen_"
MIME-Version: 1.0
X-Scanned-By: MailControl 10515.0 (www.mailcontrol.com) on 10.71.0.134
Cc: "xen-users@lists.xen.org" 
Subject: [Xen-devel] e820_host problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_006_E71FC5D6F96C3C4B93FC8FF942D924C682F44808SBJEXCH1Bwebsen_
Content-Type: multipart/alternative;
	boundary="_000_E71FC5D6F96C3C4B93FC8FF942D924C682F44808SBJEXCH1Bwebsen_"

--_000_E71FC5D6F96C3C4B93FC8FF942D924C682F44808SBJEXCH1Bwebsen_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

I've set up a PV guest using xen 4.2 and kernel 2.6.32.57. the hypervior is=
 64bits whereas the dom0 and domu are 32bits. It seems to me that the memor=
y allocation to domu is *limited to 3360M* when e820_host is enabled. I att=
ached the domu configuration file and output of the command xl -vvv create =
and xl list.

I am looking forward your reply.
Thanks,
HUAXIANG FAN
Software Engineer II

WEBSENSE NETWORK SECURITY TECHNOLOGY R&D (BEIJING) CO. LTD.
ph: +8610.5884.4327
fax: +8610.5884.4727
www.websense.cn

Websense TRITON(tm)
For Essential Information Protection(tm)
Web Security | Data Security | Email Security



 Protected by Websense Hosted Email Security -- www.websense.com=20

--_000_E71FC5D6F96C3C4B93FC8FF942D924C682F44808SBJEXCH1Bwebsen_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi,


 


I’ve set up a PV guest using xen 4.2 and kerne=
l 2.6.32.57. the hypervior is 64bits whereas the dom0 and domu are 32bits. =
It seems to me that the memory allocation to domu is *limited to 3360M* when e820_host is enabled. I attached
 the domu configuration file and output of the command xl -vvv create and x=
l list.


 


I am looking forward your reply.


Thanks,


HUAXIANG FAN

Software Engineer II



WEBSENSE NETWORK SECURITY TECHNOLOGY R&am=
p;D (BEIJING) CO. LTD.

ph: +8610.5884.4327

fax: +8610.5884.4727

www.websense.cn



Websense TRITON™

For Essential Information Protection™

Web Security |
=
Data Security=
 |
Email Security











Protected by Websense Hosted Email Security =
212; www.websense.com




--_000_E71FC5D6F96C3C4B93FC8FF942D924C682F44808SBJEXCH1Bwebsen_--

--_006_E71FC5D6F96C3C4B93FC8FF942D924C682F44808SBJEXCH1Bwebsen_
Content-Type: application/octet-stream; name="domainWCG.cfg"
Content-Description: domainWCG.cfg
Content-Disposition: attachment; creation-date="Mon, 22 Oct 2012 10:09:56 GMT"; filename="domainWCG.cfg"; modification-date="Mon, 22 Oct 2012 17:16:38 GMT"; size="370"
Content-Transfer-Encoding: base64

a2VybmVsID0gIi9yb290L2RvbWFpbldDRy5rZXJuZWwiDQpyYW1kaXNrID0g
Ii9yb290L2RvbWFpbldDRy5pbml0cmQuaW1nIg0KZTgyMF9ob3N0PTENCm1l
bW9yeT0xMDI0MA0KbmFtZSA9ICJ3Y2ciDQp2aWYgID0gWyAnaXA9MTY5LjI1
NC4yNTQuMyx2aWZuYW1lPXdjZy4wJyBdDQpkaXNrID0gWydwaHk6L2Rldi9s
dl9hcHBsaWFuY2Uvd2NnLHh2ZGExLHcnLA0KICAgICAgICAncGh5Oi9kZXYv
c2RiLHh2ZGIsdyddDQpyb290ICA9ICIvZGV2L3h2ZGExIHJvIg0KZXh0cmE9
ImlvbW11PXNvZnQgcHJpbnRrLnByaW50a190aW1lPTEgY29uc29sZT1odmMw
Ig0KcGNpPVsnMDE6MDAuMCcsJzAxOjAwLjEnXQ0KdmNwdXM9NA0KY3B1cz0i
NCw1LDYsNyINCg==

--_006_E71FC5D6F96C3C4B93FC8FF942D924C682F44808SBJEXCH1Bwebsen_
Content-Type: application/octet-stream; name="xl-create.output"
Content-Description: xl-create.output
Content-Disposition: attachment; creation-date="Mon, 22 Oct 2012 10:09:56 GMT"; filename="xl-create.output"; modification-date="Mon, 22 Oct 2012 18:05:00 GMT"; size="12138"
Content-Transfer-Encoding: base64

W3Jvb3RAbG9jYWxob3N0IH5dIyB4bCAtdnZ2IGNyZWF0ZSBkb21haW5XQ0cu
Y2ZnIApQYXJzaW5nIGNvbmZpZyBmcm9tIGRvbWFpbldDRy5jZmcKbGlieGw6
IGRlYnVnOiBsaWJ4bF9jcmVhdGUuYzoxMTczOmRvX2RvbWFpbl9jcmVhdGU6
IGFvIDB4ODA2YmVmODogY3JlYXRlOiBob3c9KG5pbCkgY2FsbGJhY2s9KG5p
bCkgcG9sbGVyPTB4ODA2YjY4OApsaWJ4bDogZGVidWc6IGxpYnhsX2Rldmlj
ZS5jOjIyOTpsaWJ4bF9fZGV2aWNlX2Rpc2tfc2V0X2JhY2tlbmQ6IERpc2sg
dmRldj14dmRhMSBzcGVjLmJhY2tlbmQ9dW5rbm93bgpsaWJ4bDogZGVidWc6
IGxpYnhsX2RldmljZS5jOjI2NTpsaWJ4bF9fZGV2aWNlX2Rpc2tfc2V0X2Jh
Y2tlbmQ6IERpc2sgdmRldj14dmRhMSwgdXNpbmcgYmFja2VuZCBwaHkKbGli
eGw6IGRlYnVnOiBsaWJ4bF9kZXZpY2UuYzoyMjk6bGlieGxfX2RldmljZV9k
aXNrX3NldF9iYWNrZW5kOiBEaXNrIHZkZXY9eHZkYiBzcGVjLmJhY2tlbmQ9
dW5rbm93bgpsaWJ4bDogZGVidWc6IGxpYnhsX2RldmljZS5jOjI2NTpsaWJ4
bF9fZGV2aWNlX2Rpc2tfc2V0X2JhY2tlbmQ6IERpc2sgdmRldj14dmRiLCB1
c2luZyBiYWNrZW5kIHBoeQpsaWJ4bDogZGVidWc6IGxpYnhsX2NyZWF0ZS5j
OjY3Nzppbml0aWF0ZV9kb21haW5fY3JlYXRlOiBydW5uaW5nIGJvb3Rsb2Fk
ZXIKbGlieGw6IGRlYnVnOiBsaWJ4bF9ib290bG9hZGVyLmM6MzI3OmxpYnhs
X19ib290bG9hZGVyX3J1bjogbm8gYm9vdGxvYWRlciBjb25maWd1cmVkLCB1
c2luZyB1c2VyIHN1cHBsaWVkIGtlcm5lbApsaWJ4bDogZGVidWc6IGxpYnhs
X2V2ZW50LmM6NTYxOmxpYnhsX19ldl94c3dhdGNoX2RlcmVnaXN0ZXI6IHdh
dGNoIHc9MHg4MDZjMGU0OiBkZXJlZ2lzdGVyIHVucmVnaXN0ZXJlZApkb21h
aW5idWlsZGVyOiBkZXRhaWw6IHhjX2RvbV9hbGxvY2F0ZTogY21kbGluZT0i
cm9vdD0vZGV2L3h2ZGExIHJvIGlvbW11PXNvZnQgcHJpbnRrLnByaW50a190
aW1lPTEgY29uc29sZT1odmMwIiwgZmVhdHVyZXM9IihudWxsKSIKbGlieGw6
IGRlYnVnOiBsaWJ4bF9kb20uYzozODA6bGlieGxfX2J1aWxkX3B2OiBwdiBr
ZXJuZWwgbWFwcGVkIDAgcGF0aCAvcm9vdC9kb21haW5XQ0cua2VybmVsCgpk
b21haW5idWlsZGVyOiBkZXRhaWw6IHhjX2RvbV9rZXJuZWxfZmlsZTogZmls
ZW5hbWU9Ii9yb290L2RvbWFpbldDRy5rZXJuZWwiCmRvbWFpbmJ1aWxkZXI6
IGRldGFpbDogeGNfZG9tX21hbGxvY19maWxlbWFwICAgIDogMTg2MSBrQgpk
b21haW5idWlsZGVyOiBkZXRhaWw6IHhjX2RvbV9yYW1kaXNrX2ZpbGU6IGZp
bGVuYW1lPSIvcm9vdC9kb21haW5XQ0cuaW5pdHJkLmltZyIKZG9tYWluYnVp
bGRlcjogZGV0YWlsOiB4Y19kb21fbWFsbG9jX2ZpbGVtYXAgICAgOiAxMDAx
MSBrQgpkb21haW5idWlsZGVyOiBkZXRhaWw6IHhjX2RvbV9ib290X3hlbl9p
bml0OiB2ZXIgNC4yLCBjYXBzIHhlbi0zLjAteDg2XzY0IHhlbi0zLjAteDg2
XzMycCBodm0tMy4wLXg4Nl8zMiBodm0tMy4wLXg4Nl8zMnAgaHZtLTMuMC14
ODZfNjQgCmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogeGNfZG9tX3BhcnNlX2lt
YWdlOiBjYWxsZWQKZG9tYWluYnVpbGRlcjogZGV0YWlsOiB4Y19kb21fZmlu
ZF9sb2FkZXI6IHRyeWluZyBFTEYtZ2VuZXJpYyBsb2FkZXIgLi4uIApkb21h
aW5idWlsZGVyOiBkZXRhaWw6IGxvYWRlciBwcm9iZSBmYWlsZWQKZG9tYWlu
YnVpbGRlcjogZGV0YWlsOiB4Y19kb21fZmluZF9sb2FkZXI6IHRyeWluZyBM
aW51eCBiekltYWdlIGxvYWRlciAuLi4gCmRvbWFpbmJ1aWxkZXI6IGRldGFp
bDogeGNfZG9tX21hbGxvYyAgICAgICAgICAgIDogMzc2MyBrQgpkb21haW5i
dWlsZGVyOiBkZXRhaWw6IHhjX2RvbV9kb19ndW56aXA6IHVuemlwIG9rLCAw
eDFjOWRhNiAtPiAweDNhY2U5Ywpkb21haW5idWlsZGVyOiBkZXRhaWw6IGxv
YWRlciBwcm9iZSBPSwp4YzogZGV0YWlsOiBlbGZfcGFyc2VfYmluYXJ5OiBw
aGRyOiBwYWRkcj0weDEwMDAwMDAgbWVtc3o9MHgyYjEwMDAKeGM6IGRldGFp
bDogZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgxMmIxMDAwIG1l
bXN6PTB4MjNmMDAwCnhjOiBkZXRhaWw6IGVsZl9wYXJzZV9iaW5hcnk6IG1l
bW9yeTogMHgxMDAwMDAwIC0+IDB4MTRmMDAwMAp4YzogZGV0YWlsOiBlbGZf
eGVuX3BhcnNlX25vdGU6IEdVRVNUX09TID0gImxpbnV4Igp4YzogZGV0YWls
OiBlbGZfeGVuX3BhcnNlX25vdGU6IEdVRVNUX1ZFUlNJT04gPSAiMi42Igp4
YzogZGV0YWlsOiBlbGZfeGVuX3BhcnNlX25vdGU6IFhFTl9WRVJTSU9OID0g
Inhlbi0zLjAiCnhjOiBkZXRhaWw6IGVsZl94ZW5fcGFyc2Vfbm90ZTogVklS
VF9CQVNFID0gMHhjMDAwMDAwMAp4YzogZGV0YWlsOiBlbGZfeGVuX3BhcnNl
X25vdGU6IEVOVFJZID0gMHhjMTJmNTAwMAp4YzogZGV0YWlsOiBlbGZfeGVu
X3BhcnNlX25vdGU6IEhZUEVSQ0FMTF9QQUdFID0gMHhjMTAwMjAwMAp4Yzog
ZGV0YWlsOiBlbGZfeGVuX3BhcnNlX25vdGU6IEZFQVRVUkVTID0gIiF3cml0
YWJsZV9wYWdlX3RhYmxlc3xwYWVfcGdkaXJfYWJvdmVfNGdiIgp4YzogZGV0
YWlsOiBlbGZfeGVuX3BhcnNlX25vdGU6IFBBRV9NT0RFID0gInllcyIKeGM6
IGRldGFpbDogZWxmX3hlbl9wYXJzZV9ub3RlOiBMT0FERVIgPSAiZ2VuZXJp
YyIKeGM6IGRldGFpbDogZWxmX3hlbl9wYXJzZV9ub3RlOiB1bmtub3duIHhl
biBlbGYgbm90ZSAoMHhkKQp4YzogZGV0YWlsOiBlbGZfeGVuX3BhcnNlX25v
dGU6IFNVU1BFTkRfQ0FOQ0VMID0gMHgxCnhjOiBkZXRhaWw6IGVsZl94ZW5f
cGFyc2Vfbm90ZTogSFZfU1RBUlRfTE9XID0gMHhmNTgwMDAwMAp4YzogZGV0
YWlsOiBlbGZfeGVuX3BhcnNlX25vdGU6IFBBRERSX09GRlNFVCA9IDB4MAp4
YzogZGV0YWlsOiBlbGZfeGVuX2FkZHJfY2FsY19jaGVjazogYWRkcmVzc2Vz
Ogp4YzogZGV0YWlsOiAgICAgdmlydF9iYXNlICAgICAgICA9IDB4YzAwMDAw
MDAKeGM6IGRldGFpbDogICAgIGVsZl9wYWRkcl9vZmZzZXQgPSAweDAKeGM6
IGRldGFpbDogICAgIHZpcnRfb2Zmc2V0ICAgICAgPSAweGMwMDAwMDAwCnhj
OiBkZXRhaWw6ICAgICB2aXJ0X2tzdGFydCAgICAgID0gMHhjMTAwMDAwMAp4
YzogZGV0YWlsOiAgICAgdmlydF9rZW5kICAgICAgICA9IDB4YzE0ZjAwMDAK
eGM6IGRldGFpbDogICAgIHZpcnRfZW50cnkgICAgICAgPSAweGMxMmY1MDAw
CnhjOiBkZXRhaWw6ICAgICBwMm1fYmFzZSAgICAgICAgID0gMHhmZmZmZmZm
ZmZmZmZmZmZmCmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogeGNfZG9tX3BhcnNl
X2VsZl9rZXJuZWw6IHhlbi0zLjAteDg2XzMycDogMHhjMTAwMDAwMCAtPiAw
eGMxNGYwMDAwCmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogeGNfZG9tX21lbV9p
bml0OiBtZW0gMTAyNDAgTUIsIHBhZ2VzIDB4MjgwMDAwIHBhZ2VzLCA0ayBl
YWNoCmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogeGNfZG9tX21lbV9pbml0OiAw
eDI4MDAwMCBwYWdlcwpkb21haW5idWlsZGVyOiBkZXRhaWw6IHhjX2RvbV9i
b290X21lbV9pbml0OiBjYWxsZWQKZG9tYWluYnVpbGRlcjogZGV0YWlsOiB4
ODZfY29tcGF0OiBndWVzdCB4ZW4tMy4wLXg4Nl8zMnAsIGFkZHJlc3Mgc2l6
ZSAzMgpkb21haW5idWlsZGVyOiBkZXRhaWw6IHhjX2RvbV9tYWxsb2MgICAg
ICAgICAgICA6IDEwMjQwIGtCCmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogeGNf
ZG9tX2J1aWxkX2ltYWdlOiBjYWxsZWQKZG9tYWluYnVpbGRlcjogZGV0YWls
OiB4Y19kb21fYWxsb2Nfc2VnbWVudDogICBrZXJuZWwgICAgICAgOiAweGMx
MDAwMDAwIC0+IDB4YzE0ZjAwMDAgIChwZm4gMHgxMDAwICsgMHg0ZjAgcGFn
ZXMpCmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogeGNfZG9tX3Bmbl90b19wdHI6
IGRvbVUgbWFwcGluZzogcGZuIDB4MTAwMCsweDRmMCBhdCAweGI1OGM1MDAw
CnhjOiBkZXRhaWw6IGVsZl9sb2FkX2JpbmFyeTogcGhkciAwIGF0IDB4MHhi
NThjNTAwMCAtPiAweDB4YjViNzYwMDAKeGM6IGRldGFpbDogZWxmX2xvYWRf
YmluYXJ5OiBwaGRyIDEgYXQgMHgweGI1Yjc2MDAwIC0+IDB4MHhiNWMxMzAw
MApkb21haW5idWlsZGVyOiBkZXRhaWw6IHhjX2RvbV9hbGxvY19zZWdtZW50
OiAgIHJhbWRpc2sgICAgICA6IDB4YzE0ZjAwMDAgLT4gMHhjMmMwZTAwMCAg
KHBmbiAweDE0ZjAgKyAweDE3MWUgcGFnZXMpCmRvbWFpbmJ1aWxkZXI6IGRl
dGFpbDogeGNfZG9tX21hbGxvYyAgICAgICAgICAgIDogMTM4IGtCCmRvbWFp
bmJ1aWxkZXI6IGRldGFpbDogeGNfZG9tX3Bmbl90b19wdHI6IGRvbVUgbWFw
cGluZzogcGZuIDB4MTRmMCsweDE3MWUgYXQgMHhiNDE4NDAwMApkb21haW5i
dWlsZGVyOiBkZXRhaWw6IHhjX2RvbV9kb19ndW56aXA6IHVuemlwIG9rLCAw
eDljNmYzNCAtPiAweDE3MWQ0MTAKZG9tYWluYnVpbGRlcjogZGV0YWlsOiB4
Y19kb21fYWxsb2Nfc2VnbWVudDogICBwaHlzMm1hY2ggICAgOiAweGMyYzBl
MDAwIC0+IDB4YzM2MGUwMDAgIChwZm4gMHgyYzBlICsgMHhhMDAgcGFnZXMp
CmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogeGNfZG9tX3Bmbl90b19wdHI6IGRv
bVUgbWFwcGluZzogcGZuIDB4MmMwZSsweGEwMCBhdCAweGIzNzg0MDAwCmRv
bWFpbmJ1aWxkZXI6IGRldGFpbDogeGNfZG9tX2FsbG9jX3BhZ2UgICA6ICAg
c3RhcnQgaW5mbyAgIDogMHhjMzYwZTAwMCAocGZuIDB4MzYwZSkKZG9tYWlu
YnVpbGRlcjogZGV0YWlsOiB4Y19kb21fYWxsb2NfcGFnZSAgIDogICB4ZW5z
dG9yZSAgICAgOiAweGMzNjBmMDAwIChwZm4gMHgzNjBmKQpkb21haW5idWls
ZGVyOiBkZXRhaWw6IHhjX2RvbV9hbGxvY19wYWdlICAgOiAgIGNvbnNvbGUg
ICAgICA6IDB4YzM2MTAwMDAgKHBmbiAweDM2MTApCmRvbWFpbmJ1aWxkZXI6
IGRldGFpbDogbnJfcGFnZV90YWJsZXM6IDB4MDAwMDAwMDBmZmZmZmZmZi8z
MjogMHgwMDAwMDAwMDAwMDAwMDAwIC0+IDB4ZmZmZmZmZmZmZmZmZmZmZiwg
MSB0YWJsZShzKQpkb21haW5idWlsZGVyOiBkZXRhaWw6IG5yX3BhZ2VfdGFi
bGVzOiAweDAwMDAwMDAwM2ZmZmZmZmYvMzA6IDB4MDAwMDAwMDBjMDAwMDAw
MCAtPiAweDAwMDAwMDAwZmZmZmZmZmYsIDEgdGFibGUocykKZG9tYWluYnVp
bGRlcjogZGV0YWlsOiBucl9wYWdlX3RhYmxlczogMHgwMDAwMDAwMDAwMWZm
ZmZmLzIxOiAweDAwMDAwMDAwYzAwMDAwMDAgLT4gMHgwMDAwMDAwMGMzN2Zm
ZmZmLCAyOCB0YWJsZShzKQpkb21haW5idWlsZGVyOiBkZXRhaWw6IHhjX2Rv
bV9hbGxvY19zZWdtZW50OiAgIHBhZ2UgdGFibGVzICA6IDB4YzM2MTEwMDAg
LT4gMHhjMzYyZjAwMCAgKHBmbiAweDM2MTEgKyAweDFlIHBhZ2VzKQpkb21h
aW5idWlsZGVyOiBkZXRhaWw6IHhjX2RvbV9wZm5fdG9fcHRyOiBkb21VIG1h
cHBpbmc6IHBmbiAweDM2MTErMHgxZSBhdCAweGIzNzY2MDAwCmRvbWFpbmJ1
aWxkZXI6IGRldGFpbDogeGNfZG9tX2FsbG9jX3BhZ2UgICA6ICAgYm9vdCBz
dGFjayAgIDogMHhjMzYyZjAwMCAocGZuIDB4MzYyZikKZG9tYWluYnVpbGRl
cjogZGV0YWlsOiB4Y19kb21fYnVpbGRfaW1hZ2UgIDogdmlydF9hbGxvY19l
bmQgOiAweGMzNjMwMDAwCmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogeGNfZG9t
X2J1aWxkX2ltYWdlICA6IHZpcnRfcGd0YWJfZW5kIDogMHhjMzgwMDAwMApk
b21haW5idWlsZGVyOiBkZXRhaWw6IHhjX2RvbV9ib290X2ltYWdlOiBjYWxs
ZWQKZG9tYWluYnVpbGRlcjogZGV0YWlsOiBhcmNoX3NldHVwX2Jvb3RlYXJs
eTogZG9pbmcgbm90aGluZwpkb21haW5idWlsZGVyOiBkZXRhaWw6IHhjX2Rv
bV9jb21wYXRfY2hlY2s6IHN1cHBvcnRlZCBndWVzdCB0eXBlOiB4ZW4tMy4w
LXg4Nl82NApkb21haW5idWlsZGVyOiBkZXRhaWw6IHhjX2RvbV9jb21wYXRf
Y2hlY2s6IHN1cHBvcnRlZCBndWVzdCB0eXBlOiB4ZW4tMy4wLXg4Nl8zMnAg
PD0gbWF0Y2hlcwpkb21haW5idWlsZGVyOiBkZXRhaWw6IHhjX2RvbV9jb21w
YXRfY2hlY2s6IHN1cHBvcnRlZCBndWVzdCB0eXBlOiBodm0tMy4wLXg4Nl8z
Mgpkb21haW5idWlsZGVyOiBkZXRhaWw6IHhjX2RvbV9jb21wYXRfY2hlY2s6
IHN1cHBvcnRlZCBndWVzdCB0eXBlOiBodm0tMy4wLXg4Nl8zMnAKZG9tYWlu
YnVpbGRlcjogZGV0YWlsOiB4Y19kb21fY29tcGF0X2NoZWNrOiBzdXBwb3J0
ZWQgZ3Vlc3QgdHlwZTogaHZtLTMuMC14ODZfNjQKZG9tYWluYnVpbGRlcjog
ZGV0YWlsOiB4Y19kb21fdXBkYXRlX2d1ZXN0X3AybTogZHN0IDMyYml0LCBw
YWdlcyAweDI4MDAwMApkb21haW5idWlsZGVyOiBkZXRhaWw6IGNsZWFyX3Bh
Z2U6IHBmbiAweDM2MTAsIG1mbiAweDQwNTMyYwpkb21haW5idWlsZGVyOiBk
ZXRhaWw6IGNsZWFyX3BhZ2U6IHBmbiAweDM2MGYsIG1mbiAweDQwNTMyZApk
b21haW5idWlsZGVyOiBkZXRhaWw6IHhjX2RvbV9wZm5fdG9fcHRyOiBkb21V
IG1hcHBpbmc6IHBmbiAweDM2MGUrMHgxIGF0IDB4YjM3NjMwMDAKZG9tYWlu
YnVpbGRlcjogZGV0YWlsOiBzdGFydF9pbmZvX3g4Nl8zMjogY2FsbGVkCmRv
bWFpbmJ1aWxkZXI6IGRldGFpbDogc2V0dXBfaHlwZXJjYWxsX3BhZ2U6IHZh
ZGRyPTB4YzEwMDIwMDAgcGZuPTB4MTAwMgpkb21haW5idWlsZGVyOiBkZXRh
aWw6IGRvbWFpbiBidWlsZGVyIG1lbW9yeSBmb290cHJpbnQKZG9tYWluYnVp
bGRlcjogZGV0YWlsOiAgICBhbGxvY2F0ZWQKZG9tYWluYnVpbGRlcjogZGV0
YWlsOiAgICAgICBtYWxsb2MgICAgICAgICAgICAgOiAxNDIzNCBrQgpkb21h
aW5idWlsZGVyOiBkZXRhaWw6ICAgICAgIGFub24gbW1hcCAgICAgICAgICA6
IDAgYnl0ZXMKZG9tYWluYnVpbGRlcjogZGV0YWlsOiAgICBtYXBwZWQKZG9t
YWluYnVpbGRlcjogZGV0YWlsOiAgICAgICBmaWxlIG1tYXAgICAgICAgICAg
OiAxMTg3MiBrQgpkb21haW5idWlsZGVyOiBkZXRhaWw6ICAgICAgIGRvbVUg
bW1hcCAgICAgICAgICA6IDM4IE1CCmRvbWFpbmJ1aWxkZXI6IGRldGFpbDog
YXJjaF9zZXR1cF9ib290bGF0ZTogc2hhcmVkX2luZm86IHBmbiAweDAsIG1m
biAweGJmMjJkCmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogc2hhcmVkX2luZm9f
eDg2XzMyOiBjYWxsZWQKZG9tYWluYnVpbGRlcjogZGV0YWlsOiB2Y3B1X3g4
Nl8zMjogY2FsbGVkCmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogdmNwdV94ODZf
MzI6IGNyMzogcGZuIDB4MzYxMSBtZm4gMHg0MDUzMmIKZG9tYWluYnVpbGRl
cjogZGV0YWlsOiBsYXVuY2hfdm06IGNhbGxlZCwgY3R4dD0weGJmODM4ODZj
CmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogeGNfZG9tX3JlbGVhc2U6IGNhbGxl
ZApsaWJ4bDogZGVidWc6IGxpYnhsX2RldmljZS5jOjIyOTpsaWJ4bF9fZGV2
aWNlX2Rpc2tfc2V0X2JhY2tlbmQ6IERpc2sgdmRldj14dmRhMSBzcGVjLmJh
Y2tlbmQ9cGh5CmxpYnhsOiBkZWJ1ZzogbGlieGxfZXZlbnQuYzo1MTI6bGli
eGxfX2V2X3hzd2F0Y2hfcmVnaXN0ZXI6IHdhdGNoIHc9MHg4MDZjYmQwIHdw
YXRoPS9sb2NhbC9kb21haW4vMC9iYWNrZW5kL3ZiZC83LzUxNzEzL3N0YXRl
IHRva2VuPTMvMDogcmVnaXN0ZXIgc2xvdG51bT0zCmxpYnhsOiBkZWJ1Zzog
bGlieGxfZGV2aWNlLmM6MjI5OmxpYnhsX19kZXZpY2VfZGlza19zZXRfYmFj
a2VuZDogRGlzayB2ZGV2PXh2ZGIgc3BlYy5iYWNrZW5kPXBoeQpsaWJ4bDog
ZGVidWc6IGxpYnhsX2RldmljZS5jOjIyOTpsaWJ4bF9fZGV2aWNlX2Rpc2tf
c2V0X2JhY2tlbmQ6IERpc2sgdmRldj14dmRiIHNwZWMuYmFja2VuZD1waHkK
bGlieGw6IGRlYnVnOiBsaWJ4bF9ldmVudC5jOjUxMjpsaWJ4bF9fZXZfeHN3
YXRjaF9yZWdpc3Rlcjogd2F0Y2ggdz0weDgwNmQ1NDAgd3BhdGg9L2xvY2Fs
L2RvbWFpbi8wL2JhY2tlbmQvdmJkLzcvNTE3Mjgvc3RhdGUgdG9rZW49Mi8x
OiByZWdpc3RlciBzbG90bnVtPTIKbGlieGw6IGRlYnVnOiBsaWJ4bF9jcmVh
dGUuYzoxMTg2OmRvX2RvbWFpbl9jcmVhdGU6IGFvIDB4ODA2YmVmODogaW5w
cm9ncmVzczogcG9sbGVyPTB4ODA2YjY4OCwgZmxhZ3M9aQpsaWJ4bDogZGVi
dWc6IGxpYnhsX2V2ZW50LmM6NDU3OndhdGNoZmRfY2FsbGJhY2s6IHdhdGNo
IHc9MHg4MDZjYmQwIHdwYXRoPS9sb2NhbC9kb21haW4vMC9iYWNrZW5kL3Zi
ZC83LzUxNzEzL3N0YXRlIHRva2VuPTMvMDogZXZlbnQgZXBhdGg9L2xvY2Fs
L2RvbWFpbi8wL2JhY2tlbmQvdmJkLzcvNTE3MTMvc3RhdGUKbGlieGw6IGRl
YnVnOiBsaWJ4bF9ldmVudC5jOjU5NjpkZXZzdGF0ZV93YXRjaF9jYWxsYmFj
azogYmFja2VuZCAvbG9jYWwvZG9tYWluLzAvYmFja2VuZC92YmQvNy81MTcx
My9zdGF0ZSB3YW50ZWQgc3RhdGUgMiBvawpsaWJ4bDogZGVidWc6IGxpYnhs
X2V2ZW50LmM6NTQ5OmxpYnhsX19ldl94c3dhdGNoX2RlcmVnaXN0ZXI6IHdh
dGNoIHc9MHg4MDZjYmQwIHdwYXRoPS9sb2NhbC9kb21haW4vMC9iYWNrZW5k
L3ZiZC83LzUxNzEzL3N0YXRlIHRva2VuPTMvMDogZGVyZWdpc3RlciBzbG90
bnVtPTMKbGlieGw6IGRlYnVnOiBsaWJ4bF9ldmVudC5jOjU2MTpsaWJ4bF9f
ZXZfeHN3YXRjaF9kZXJlZ2lzdGVyOiB3YXRjaCB3PTB4ODA2Y2JkMDogZGVy
ZWdpc3RlciB1bnJlZ2lzdGVyZWQKbGlieGw6IGRlYnVnOiBsaWJ4bF9kZXZp
Y2UuYzo5MTY6ZGV2aWNlX2hvdHBsdWc6IGNhbGxpbmcgaG90cGx1ZyBzY3Jp
cHQ6IC9ldGMveGVuL3NjcmlwdHMvYmxvY2sgYWRkCmxpYnhsOiBkZWJ1Zzog
bGlieGxfZXZlbnQuYzo0MjY6d2F0Y2hmZF9jYWxsYmFjazogd2F0Y2ggZXBh
dGg9L2xvY2FsL2RvbWFpbi8wL2JhY2tlbmQvdmJkLzcvNTE3MTMvc3RhdGUg
dG9rZW49My8wOiBlbXB0eSBzbG90CmxpYnhsOiBkZWJ1ZzogbGlieGxfZXZl
bnQuYzo0NTc6d2F0Y2hmZF9jYWxsYmFjazogd2F0Y2ggdz0weDgwNmQ1NDAg
d3BhdGg9L2xvY2FsL2RvbWFpbi8wL2JhY2tlbmQvdmJkLzcvNTE3Mjgvc3Rh
dGUgdG9rZW49Mi8xOiBldmVudCBlcGF0aD0vbG9jYWwvZG9tYWluLzAvYmFj
a2VuZC92YmQvNy81MTcyOC9zdGF0ZQpsaWJ4bDogZGVidWc6IGxpYnhsX2V2
ZW50LmM6NTk2OmRldnN0YXRlX3dhdGNoX2NhbGxiYWNrOiBiYWNrZW5kIC9s
b2NhbC9kb21haW4vMC9iYWNrZW5kL3ZiZC83LzUxNzI4L3N0YXRlIHdhbnRl
ZCBzdGF0ZSAyIG9rCmxpYnhsOiBkZWJ1ZzogbGlieGxfZXZlbnQuYzo1NDk6
bGlieGxfX2V2X3hzd2F0Y2hfZGVyZWdpc3Rlcjogd2F0Y2ggdz0weDgwNmQ1
NDAgd3BhdGg9L2xvY2FsL2RvbWFpbi8wL2JhY2tlbmQvdmJkLzcvNTE3Mjgv
c3RhdGUgdG9rZW49Mi8xOiBkZXJlZ2lzdGVyIHNsb3RudW09MgpsaWJ4bDog
ZGVidWc6IGxpYnhsX2V2ZW50LmM6NTYxOmxpYnhsX19ldl94c3dhdGNoX2Rl
cmVnaXN0ZXI6IHdhdGNoIHc9MHg4MDZkNTQwOiBkZXJlZ2lzdGVyIHVucmVn
aXN0ZXJlZApsaWJ4bDogZGVidWc6IGxpYnhsX2RldmljZS5jOjkxNjpkZXZp
Y2VfaG90cGx1ZzogY2FsbGluZyBob3RwbHVnIHNjcmlwdDogL2V0Yy94ZW4v
c2NyaXB0cy9ibG9jayBhZGQKbGlieGw6IGRlYnVnOiBsaWJ4bF9ldmVudC5j
OjQyNjp3YXRjaGZkX2NhbGxiYWNrOiB3YXRjaCBlcGF0aD0vbG9jYWwvZG9t
YWluLzAvYmFja2VuZC92YmQvNy81MTcyOC9zdGF0ZSB0b2tlbj0yLzE6IGVt
cHR5IHNsb3QKbGlieGw6IGRlYnVnOiBsaWJ4bF9ldmVudC5jOjUxMjpsaWJ4
bF9fZXZfeHN3YXRjaF9yZWdpc3Rlcjogd2F0Y2ggdz0weDgwNmViMjggd3Bh
dGg9L2xvY2FsL2RvbWFpbi8wL2JhY2tlbmQvdmlmLzcvMC9zdGF0ZSB0b2tl
bj0yLzI6IHJlZ2lzdGVyIHNsb3RudW09MgpsaWJ4bDogZGVidWc6IGxpYnhs
X2V2ZW50LmM6NDU3OndhdGNoZmRfY2FsbGJhY2s6IHdhdGNoIHc9MHg4MDZl
YjI4IHdwYXRoPS9sb2NhbC9kb21haW4vMC9iYWNrZW5kL3ZpZi83LzAvc3Rh
dGUgdG9rZW49Mi8yOiBldmVudCBlcGF0aD0vbG9jYWwvZG9tYWluLzAvYmFj
a2VuZC92aWYvNy8wL3N0YXRlCmxpYnhsOiBkZWJ1ZzogbGlieGxfZXZlbnQu
Yzo2MDA6ZGV2c3RhdGVfd2F0Y2hfY2FsbGJhY2s6IGJhY2tlbmQgL2xvY2Fs
L2RvbWFpbi8wL2JhY2tlbmQvdmlmLzcvMC9zdGF0ZSB3YW50ZWQgc3RhdGUg
MiBzdGlsbCB3YWl0aW5nIHN0YXRlIDEKbGlieGw6IGRlYnVnOiBsaWJ4bF9l
dmVudC5jOjQ1Nzp3YXRjaGZkX2NhbGxiYWNrOiB3YXRjaCB3PTB4ODA2ZWIy
OCB3cGF0aD0vbG9jYWwvZG9tYWluLzAvYmFja2VuZC92aWYvNy8wL3N0YXRl
IHRva2VuPTIvMjogZXZlbnQgZXBhdGg9L2xvY2FsL2RvbWFpbi8wL2JhY2tl
bmQvdmlmLzcvMC9zdGF0ZQpsaWJ4bDogZGVidWc6IGxpYnhsX2V2ZW50LmM6
NTk2OmRldnN0YXRlX3dhdGNoX2NhbGxiYWNrOiBiYWNrZW5kIC9sb2NhbC9k
b21haW4vMC9iYWNrZW5kL3ZpZi83LzAvc3RhdGUgd2FudGVkIHN0YXRlIDIg
b2sKbGlieGw6IGRlYnVnOiBsaWJ4bF9ldmVudC5jOjU0OTpsaWJ4bF9fZXZf
eHN3YXRjaF9kZXJlZ2lzdGVyOiB3YXRjaCB3PTB4ODA2ZWIyOCB3cGF0aD0v
bG9jYWwvZG9tYWluLzAvYmFja2VuZC92aWYvNy8wL3N0YXRlIHRva2VuPTIv
MjogZGVyZWdpc3RlciBzbG90bnVtPTIKbGlieGw6IGRlYnVnOiBsaWJ4bF9l
dmVudC5jOjU2MTpsaWJ4bF9fZXZfeHN3YXRjaF9kZXJlZ2lzdGVyOiB3YXRj
aCB3PTB4ODA2ZWIyODogZGVyZWdpc3RlciB1bnJlZ2lzdGVyZWQKbGlieGw6
IGRlYnVnOiBsaWJ4bF9kZXZpY2UuYzo5MTY6ZGV2aWNlX2hvdHBsdWc6IGNh
bGxpbmcgaG90cGx1ZyBzY3JpcHQ6IC9ldGMveGVuL3NjcmlwdHMvdmlmLWJy
aWRnZSBvbmxpbmUKbGlieGw6IGVycm9yOiBsaWJ4bF9wY2kuYzoxMDAxOmxp
YnhsX19kZXZpY2VfcGNpX3Jlc2V0OiBUaGUga2VybmVsIGRvZXNuJ3Qgc3Vw
cG9ydCByZXNldCBmcm9tIHN5c2ZzIGZvciBQQ0kgZGV2aWNlIDAwMDA6MDE6
MDAuMApsaWJ4bDogZXJyb3I6IGxpYnhsX3BjaS5jOjEwMDE6bGlieGxfX2Rl
dmljZV9wY2lfcmVzZXQ6IFRoZSBrZXJuZWwgZG9lc24ndCBzdXBwb3J0IHJl
c2V0IGZyb20gc3lzZnMgZm9yIFBDSSBkZXZpY2UgMDAwMDowMTowMC4xCmxp
YnhsOiBkZWJ1ZzogbGlieGxfcGNpLmM6ODU6bGlieGxfX2NyZWF0ZV9wY2lf
YmFja2VuZDogQ3JlYXRpbmcgcGNpIGJhY2tlbmQKbGlieGw6IGRlYnVnOiBs
aWJ4bF94ODYuYzo5MDplODIwX3Nhbml0aXplOiBNZW1vcnk6IDEwNDg1NzYw
a0IgRW5kIG9mIFJBTTogMHhiZjY5OSAoUEZOKSBEZWx0YTogNzM0OTY2MGtC
LCBQQ0kgc3RhcnQ6IDMxMzYxMDBrQiAoMHhiZjY5OSBQRk4pLCBCYWxsb29u
IDBrQgoKbGlieGw6IGRlYnVnOiBsaWJ4bF94ODYuYzoyMDk6ZTgyMF9zYW5p
dGl6ZTogOiAgWzAgLT4gYmY2OTldIFJBTQpsaWJ4bDogZGVidWc6IGxpYnhs
X3g4Ni5jOjIwOTplODIwX3Nhbml0aXplOiA6ICBbYmY2OTkgLT4gYmY2YWZd
IFJlc2VydmVkCmxpYnhsOiBkZWJ1ZzogbGlieGxfeDg2LmM6MjA5OmU4MjBf
c2FuaXRpemU6IDogIFtiZjZhZiAtPiBiZjZjZV0gQUNQSQpsaWJ4bDogZGVi
dWc6IGxpYnhsX3g4Ni5jOjIwOTplODIwX3Nhbml0aXplOiA6ICBbYmY2Y2Ug
LT4gYzAwMDBdIFJlc2VydmVkCmxpYnhsOiBkZWJ1ZzogbGlieGxfeDg2LmM6
MjA5OmU4MjBfc2FuaXRpemU6IDogIFtlMDAwMCAtPiBmMDAwMF0gUmVzZXJ2
ZWQKbGlieGw6IGRlYnVnOiBsaWJ4bF94ODYuYzoyMDk6ZTgyMF9zYW5pdGl6
ZTogOiAgW2ZlMDAwIC0+IDEwMDAwMF0gUmVzZXJ2ZWQKbGlieGw6IGRlYnVn
OiBsaWJ4bF9ldmVudC5jOjE2Njc6bGlieGxfX2FvX3Byb2dyZXNzX3JlcG9y
dDogYW8gMHg4MDZiZWY4OiBwcm9ncmVzcyByZXBvcnQ6IGlnbm9yZWQKbGli
eGw6IGRlYnVnOiBsaWJ4bF9ldmVudC5jOjE0OTc6bGlieGxfX2FvX2NvbXBs
ZXRlOiBhbyAweDgwNmJlZjg6IGNvbXBsZXRlLCByYz0wCmxpYnhsOiBkZWJ1
ZzogbGlieGxfZXZlbnQuYzoxNDY5OmxpYnhsX19hb19fZGVzdHJveTogYW8g
MHg4MDZiZWY4OiBkZXN0cm95CkRhZW1vbiBydW5uaW5nIHdpdGggUElEIDU5
MzAKeGM6IGRlYnVnOiBoeXBlcmNhbGwgYnVmZmVyOiB0b3RhbCBhbGxvY2F0
aW9uczoxOTkgdG90YWwgcmVsZWFzZXM6MTk5CnhjOiBkZWJ1ZzogaHlwZXJj
YWxsIGJ1ZmZlcjogY3VycmVudCBhbGxvY2F0aW9uczowIG1heGltdW0gYWxs
b2NhdGlvbnM6Mgp4YzogZGVidWc6IGh5cGVyY2FsbCBidWZmZXI6IGNhY2hl
IGN1cnJlbnQgc2l6ZToyCnhjOiBkZWJ1ZzogaHlwZXJjYWxsIGJ1ZmZlcjog
Y2FjaGUgaGl0czoxOTEgbWlzc2VzOjIgdG9vYmlnOjYK

--_006_E71FC5D6F96C3C4B93FC8FF942D924C682F44808SBJEXCH1Bwebsen_
Content-Type: application/octet-stream; name="xl-list.output"
Content-Description: xl-list.output
Content-Disposition: attachment; creation-date="Mon, 22 Oct 2012 10:09:56 GMT"; filename="xl-list.output"; modification-date="Mon, 22 Oct 2012 18:05:40 GMT"; size="268"
Content-Transfer-Encoding: base64

W3Jvb3RAbG9jYWxob3N0IH5dIyB4bCBsaXN0Ck5hbWUgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgSUQgICBNZW0gVkNQVXMgICAg
ICBTdGF0ZSAgIFRpbWUocykKRG9tYWluLTAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgMCAgMjA0OCAgICAgMiAgICAgci0tLS0tICAg
ICAyNDYuMQp3Y2cgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICA3ICAzMzYwICAgICA0ICAgICAtYi0tLS0gICAgICA1MC4zCg==

--_006_E71FC5D6F96C3C4B93FC8FF942D924C682F44808SBJEXCH1Bwebsen_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_006_E71FC5D6F96C3C4B93FC8FF942D924C682F44808SBJEXCH1Bwebsen_--


From xen-devel-bounces@lists.xen.org Mon Oct 22 10:12:18 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 10:12:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQEz4-00059C-Ds; Mon, 22 Oct 2012 10:11:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQEz2-000594-BD; Mon, 22 Oct 2012 10:11:44 +0000
Received: from [193.109.254.147:53348] by server-7.bemta-14.messagelabs.com id
	98/85-24122-FDB15805; Mon, 22 Oct 2012 10:11:43 +0000
X-Env-Sender: hufan@websense.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1350900699!6246879!1
X-Originating-IP: [208.87.233.190]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljg3LjIzMy4xOTAgPT4gMTc4NDY1Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23951 invoked from network); 22 Oct 2012 10:11:42 -0000
Received: from cluster-g.mailcontrol.com (HELO cluster-g.mailcontrol.com)
	(208.87.233.190)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Oct 2012 10:11:42 -0000
Received: from ssdwbsnapp.websense.com (static-204-15-65-158.websense.com
	[204.15.65.158] (may be forged))
	by rly24g.srv.mailcontrol.com (MailControl) with ESMTP id
	q9MAB66O019247
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 22 Oct 2012 11:11:22 +0100
Received: from SSDEXCH1A.websense.com (unknown [10.8.1.91])
	by Websense Email Security Gateway with ESMTP id 20CB41000014;
	Mon, 22 Oct 2012 03:11:04 -0700 (PDT)
Received: from ssdexch3b.websense.com (10.8.3.169) by SSDEXCH1A.websense.com
	(10.8.1.91) with Microsoft SMTP Server (TLS) id 14.2.283.3;
	Mon, 22 Oct 2012 03:11:06 -0700
Received: from SBJEXCH2B.websense.com (10.32.8.112) by ssdexch3b.websense.com
	(10.8.3.169) with Microsoft SMTP Server (TLS) id 14.2.283.3;
	Mon, 22 Oct 2012 03:11:05 -0700
Received: from SBJEXCH1B.websense.com ([169.254.2.203]) by
	SBJEXCH2B.websense.com ([::1]) with mapi id 14.02.0283.003;
	Mon, 22 Oct 2012 18:11:01 +0800
From: "Fan, Huaxiang" 
To: "xen-devel@lists.xen.org" 
Thread-Topic: e820_host problems
Thread-Index: Ac2wO6t52kDU66w/TymQ9bR6YOep8A==
Date: Mon, 22 Oct 2012 10:11:00 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.32.134.111]
Content-Type: multipart/mixed;
	boundary="_006_E71FC5D6F96C3C4B93FC8FF942D924C682F44808SBJEXCH1Bwebsen_"
MIME-Version: 1.0
X-Scanned-By: MailControl 10515.0 (www.mailcontrol.com) on 10.71.0.134
Cc: "xen-users@lists.xen.org" 
Subject: [Xen-devel] e820_host problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_006_E71FC5D6F96C3C4B93FC8FF942D924C682F44808SBJEXCH1Bwebsen_
Content-Type: multipart/alternative;
	boundary="_000_E71FC5D6F96C3C4B93FC8FF942D924C682F44808SBJEXCH1Bwebsen_"

--_000_E71FC5D6F96C3C4B93FC8FF942D924C682F44808SBJEXCH1Bwebsen_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

I've set up a PV guest using xen 4.2 and kernel 2.6.32.57. the hypervior is=
 64bits whereas the dom0 and domu are 32bits. It seems to me that the memor=
y allocation to domu is *limited to 3360M* when e820_host is enabled. I att=
ached the domu configuration file and output of the command xl -vvv create =
and xl list.

I am looking forward your reply.
Thanks,
HUAXIANG FAN
Software Engineer II

WEBSENSE NETWORK SECURITY TECHNOLOGY R&D (BEIJING) CO. LTD.
ph: +8610.5884.4327
fax: +8610.5884.4727
www.websense.cn

Websense TRITON(tm)
For Essential Information Protection(tm)
Web Security | Data Security | Email Security



 Protected by Websense Hosted Email Security -- www.websense.com=20

--_000_E71FC5D6F96C3C4B93FC8FF942D924C682F44808SBJEXCH1Bwebsen_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi,


 


I’ve set up a PV guest using xen 4.2 and kerne=
l 2.6.32.57. the hypervior is 64bits whereas the dom0 and domu are 32bits. =
It seems to me that the memory allocation to domu is *limited to 3360M* when e820_host is enabled. I attached
 the domu configuration file and output of the command xl -vvv create and x=
l list.


 


I am looking forward your reply.


Thanks,


HUAXIANG FAN

Software Engineer II



WEBSENSE NETWORK SECURITY TECHNOLOGY R&am=
p;D (BEIJING) CO. LTD.

ph: +8610.5884.4327

fax: +8610.5884.4727

www.websense.cn



Websense TRITON™

For Essential Information Protection™

Web Security |
=
Data Security=
 |
Email Security











Protected by Websense Hosted Email Security =
212; www.websense.com




--_000_E71FC5D6F96C3C4B93FC8FF942D924C682F44808SBJEXCH1Bwebsen_--

--_006_E71FC5D6F96C3C4B93FC8FF942D924C682F44808SBJEXCH1Bwebsen_
Content-Type: application/octet-stream; name="domainWCG.cfg"
Content-Description: domainWCG.cfg
Content-Disposition: attachment; creation-date="Mon, 22 Oct 2012 10:09:56 GMT"; filename="domainWCG.cfg"; modification-date="Mon, 22 Oct 2012 17:16:38 GMT"; size="370"
Content-Transfer-Encoding: base64

a2VybmVsID0gIi9yb290L2RvbWFpbldDRy5rZXJuZWwiDQpyYW1kaXNrID0g
Ii9yb290L2RvbWFpbldDRy5pbml0cmQuaW1nIg0KZTgyMF9ob3N0PTENCm1l
bW9yeT0xMDI0MA0KbmFtZSA9ICJ3Y2ciDQp2aWYgID0gWyAnaXA9MTY5LjI1
NC4yNTQuMyx2aWZuYW1lPXdjZy4wJyBdDQpkaXNrID0gWydwaHk6L2Rldi9s
dl9hcHBsaWFuY2Uvd2NnLHh2ZGExLHcnLA0KICAgICAgICAncGh5Oi9kZXYv
c2RiLHh2ZGIsdyddDQpyb290ICA9ICIvZGV2L3h2ZGExIHJvIg0KZXh0cmE9
ImlvbW11PXNvZnQgcHJpbnRrLnByaW50a190aW1lPTEgY29uc29sZT1odmMw
Ig0KcGNpPVsnMDE6MDAuMCcsJzAxOjAwLjEnXQ0KdmNwdXM9NA0KY3B1cz0i
NCw1LDYsNyINCg==

--_006_E71FC5D6F96C3C4B93FC8FF942D924C682F44808SBJEXCH1Bwebsen_
Content-Type: application/octet-stream; name="xl-create.output"
Content-Description: xl-create.output
Content-Disposition: attachment; creation-date="Mon, 22 Oct 2012 10:09:56 GMT"; filename="xl-create.output"; modification-date="Mon, 22 Oct 2012 18:05:00 GMT"; size="12138"
Content-Transfer-Encoding: base64

W3Jvb3RAbG9jYWxob3N0IH5dIyB4bCAtdnZ2IGNyZWF0ZSBkb21haW5XQ0cu
Y2ZnIApQYXJzaW5nIGNvbmZpZyBmcm9tIGRvbWFpbldDRy5jZmcKbGlieGw6
IGRlYnVnOiBsaWJ4bF9jcmVhdGUuYzoxMTczOmRvX2RvbWFpbl9jcmVhdGU6
IGFvIDB4ODA2YmVmODogY3JlYXRlOiBob3c9KG5pbCkgY2FsbGJhY2s9KG5p
bCkgcG9sbGVyPTB4ODA2YjY4OApsaWJ4bDogZGVidWc6IGxpYnhsX2Rldmlj
ZS5jOjIyOTpsaWJ4bF9fZGV2aWNlX2Rpc2tfc2V0X2JhY2tlbmQ6IERpc2sg
dmRldj14dmRhMSBzcGVjLmJhY2tlbmQ9dW5rbm93bgpsaWJ4bDogZGVidWc6
IGxpYnhsX2RldmljZS5jOjI2NTpsaWJ4bF9fZGV2aWNlX2Rpc2tfc2V0X2Jh
Y2tlbmQ6IERpc2sgdmRldj14dmRhMSwgdXNpbmcgYmFja2VuZCBwaHkKbGli
eGw6IGRlYnVnOiBsaWJ4bF9kZXZpY2UuYzoyMjk6bGlieGxfX2RldmljZV9k
aXNrX3NldF9iYWNrZW5kOiBEaXNrIHZkZXY9eHZkYiBzcGVjLmJhY2tlbmQ9
dW5rbm93bgpsaWJ4bDogZGVidWc6IGxpYnhsX2RldmljZS5jOjI2NTpsaWJ4
bF9fZGV2aWNlX2Rpc2tfc2V0X2JhY2tlbmQ6IERpc2sgdmRldj14dmRiLCB1
c2luZyBiYWNrZW5kIHBoeQpsaWJ4bDogZGVidWc6IGxpYnhsX2NyZWF0ZS5j
OjY3Nzppbml0aWF0ZV9kb21haW5fY3JlYXRlOiBydW5uaW5nIGJvb3Rsb2Fk
ZXIKbGlieGw6IGRlYnVnOiBsaWJ4bF9ib290bG9hZGVyLmM6MzI3OmxpYnhs
X19ib290bG9hZGVyX3J1bjogbm8gYm9vdGxvYWRlciBjb25maWd1cmVkLCB1
c2luZyB1c2VyIHN1cHBsaWVkIGtlcm5lbApsaWJ4bDogZGVidWc6IGxpYnhs
X2V2ZW50LmM6NTYxOmxpYnhsX19ldl94c3dhdGNoX2RlcmVnaXN0ZXI6IHdh
dGNoIHc9MHg4MDZjMGU0OiBkZXJlZ2lzdGVyIHVucmVnaXN0ZXJlZApkb21h
aW5idWlsZGVyOiBkZXRhaWw6IHhjX2RvbV9hbGxvY2F0ZTogY21kbGluZT0i
cm9vdD0vZGV2L3h2ZGExIHJvIGlvbW11PXNvZnQgcHJpbnRrLnByaW50a190
aW1lPTEgY29uc29sZT1odmMwIiwgZmVhdHVyZXM9IihudWxsKSIKbGlieGw6
IGRlYnVnOiBsaWJ4bF9kb20uYzozODA6bGlieGxfX2J1aWxkX3B2OiBwdiBr
ZXJuZWwgbWFwcGVkIDAgcGF0aCAvcm9vdC9kb21haW5XQ0cua2VybmVsCgpk
b21haW5idWlsZGVyOiBkZXRhaWw6IHhjX2RvbV9rZXJuZWxfZmlsZTogZmls
ZW5hbWU9Ii9yb290L2RvbWFpbldDRy5rZXJuZWwiCmRvbWFpbmJ1aWxkZXI6
IGRldGFpbDogeGNfZG9tX21hbGxvY19maWxlbWFwICAgIDogMTg2MSBrQgpk
b21haW5idWlsZGVyOiBkZXRhaWw6IHhjX2RvbV9yYW1kaXNrX2ZpbGU6IGZp
bGVuYW1lPSIvcm9vdC9kb21haW5XQ0cuaW5pdHJkLmltZyIKZG9tYWluYnVp
bGRlcjogZGV0YWlsOiB4Y19kb21fbWFsbG9jX2ZpbGVtYXAgICAgOiAxMDAx
MSBrQgpkb21haW5idWlsZGVyOiBkZXRhaWw6IHhjX2RvbV9ib290X3hlbl9p
bml0OiB2ZXIgNC4yLCBjYXBzIHhlbi0zLjAteDg2XzY0IHhlbi0zLjAteDg2
XzMycCBodm0tMy4wLXg4Nl8zMiBodm0tMy4wLXg4Nl8zMnAgaHZtLTMuMC14
ODZfNjQgCmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogeGNfZG9tX3BhcnNlX2lt
YWdlOiBjYWxsZWQKZG9tYWluYnVpbGRlcjogZGV0YWlsOiB4Y19kb21fZmlu
ZF9sb2FkZXI6IHRyeWluZyBFTEYtZ2VuZXJpYyBsb2FkZXIgLi4uIApkb21h
aW5idWlsZGVyOiBkZXRhaWw6IGxvYWRlciBwcm9iZSBmYWlsZWQKZG9tYWlu
YnVpbGRlcjogZGV0YWlsOiB4Y19kb21fZmluZF9sb2FkZXI6IHRyeWluZyBM
aW51eCBiekltYWdlIGxvYWRlciAuLi4gCmRvbWFpbmJ1aWxkZXI6IGRldGFp
bDogeGNfZG9tX21hbGxvYyAgICAgICAgICAgIDogMzc2MyBrQgpkb21haW5i
dWlsZGVyOiBkZXRhaWw6IHhjX2RvbV9kb19ndW56aXA6IHVuemlwIG9rLCAw
eDFjOWRhNiAtPiAweDNhY2U5Ywpkb21haW5idWlsZGVyOiBkZXRhaWw6IGxv
YWRlciBwcm9iZSBPSwp4YzogZGV0YWlsOiBlbGZfcGFyc2VfYmluYXJ5OiBw
aGRyOiBwYWRkcj0weDEwMDAwMDAgbWVtc3o9MHgyYjEwMDAKeGM6IGRldGFp
bDogZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgxMmIxMDAwIG1l
bXN6PTB4MjNmMDAwCnhjOiBkZXRhaWw6IGVsZl9wYXJzZV9iaW5hcnk6IG1l
bW9yeTogMHgxMDAwMDAwIC0+IDB4MTRmMDAwMAp4YzogZGV0YWlsOiBlbGZf
eGVuX3BhcnNlX25vdGU6IEdVRVNUX09TID0gImxpbnV4Igp4YzogZGV0YWls
OiBlbGZfeGVuX3BhcnNlX25vdGU6IEdVRVNUX1ZFUlNJT04gPSAiMi42Igp4
YzogZGV0YWlsOiBlbGZfeGVuX3BhcnNlX25vdGU6IFhFTl9WRVJTSU9OID0g
Inhlbi0zLjAiCnhjOiBkZXRhaWw6IGVsZl94ZW5fcGFyc2Vfbm90ZTogVklS
VF9CQVNFID0gMHhjMDAwMDAwMAp4YzogZGV0YWlsOiBlbGZfeGVuX3BhcnNl
X25vdGU6IEVOVFJZID0gMHhjMTJmNTAwMAp4YzogZGV0YWlsOiBlbGZfeGVu
X3BhcnNlX25vdGU6IEhZUEVSQ0FMTF9QQUdFID0gMHhjMTAwMjAwMAp4Yzog
ZGV0YWlsOiBlbGZfeGVuX3BhcnNlX25vdGU6IEZFQVRVUkVTID0gIiF3cml0
YWJsZV9wYWdlX3RhYmxlc3xwYWVfcGdkaXJfYWJvdmVfNGdiIgp4YzogZGV0
YWlsOiBlbGZfeGVuX3BhcnNlX25vdGU6IFBBRV9NT0RFID0gInllcyIKeGM6
IGRldGFpbDogZWxmX3hlbl9wYXJzZV9ub3RlOiBMT0FERVIgPSAiZ2VuZXJp
YyIKeGM6IGRldGFpbDogZWxmX3hlbl9wYXJzZV9ub3RlOiB1bmtub3duIHhl
biBlbGYgbm90ZSAoMHhkKQp4YzogZGV0YWlsOiBlbGZfeGVuX3BhcnNlX25v
dGU6IFNVU1BFTkRfQ0FOQ0VMID0gMHgxCnhjOiBkZXRhaWw6IGVsZl94ZW5f
cGFyc2Vfbm90ZTogSFZfU1RBUlRfTE9XID0gMHhmNTgwMDAwMAp4YzogZGV0
YWlsOiBlbGZfeGVuX3BhcnNlX25vdGU6IFBBRERSX09GRlNFVCA9IDB4MAp4
YzogZGV0YWlsOiBlbGZfeGVuX2FkZHJfY2FsY19jaGVjazogYWRkcmVzc2Vz
Ogp4YzogZGV0YWlsOiAgICAgdmlydF9iYXNlICAgICAgICA9IDB4YzAwMDAw
MDAKeGM6IGRldGFpbDogICAgIGVsZl9wYWRkcl9vZmZzZXQgPSAweDAKeGM6
IGRldGFpbDogICAgIHZpcnRfb2Zmc2V0ICAgICAgPSAweGMwMDAwMDAwCnhj
OiBkZXRhaWw6ICAgICB2aXJ0X2tzdGFydCAgICAgID0gMHhjMTAwMDAwMAp4
YzogZGV0YWlsOiAgICAgdmlydF9rZW5kICAgICAgICA9IDB4YzE0ZjAwMDAK
eGM6IGRldGFpbDogICAgIHZpcnRfZW50cnkgICAgICAgPSAweGMxMmY1MDAw
CnhjOiBkZXRhaWw6ICAgICBwMm1fYmFzZSAgICAgICAgID0gMHhmZmZmZmZm
ZmZmZmZmZmZmCmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogeGNfZG9tX3BhcnNl
X2VsZl9rZXJuZWw6IHhlbi0zLjAteDg2XzMycDogMHhjMTAwMDAwMCAtPiAw
eGMxNGYwMDAwCmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogeGNfZG9tX21lbV9p
bml0OiBtZW0gMTAyNDAgTUIsIHBhZ2VzIDB4MjgwMDAwIHBhZ2VzLCA0ayBl
YWNoCmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogeGNfZG9tX21lbV9pbml0OiAw
eDI4MDAwMCBwYWdlcwpkb21haW5idWlsZGVyOiBkZXRhaWw6IHhjX2RvbV9i
b290X21lbV9pbml0OiBjYWxsZWQKZG9tYWluYnVpbGRlcjogZGV0YWlsOiB4
ODZfY29tcGF0OiBndWVzdCB4ZW4tMy4wLXg4Nl8zMnAsIGFkZHJlc3Mgc2l6
ZSAzMgpkb21haW5idWlsZGVyOiBkZXRhaWw6IHhjX2RvbV9tYWxsb2MgICAg
ICAgICAgICA6IDEwMjQwIGtCCmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogeGNf
ZG9tX2J1aWxkX2ltYWdlOiBjYWxsZWQKZG9tYWluYnVpbGRlcjogZGV0YWls
OiB4Y19kb21fYWxsb2Nfc2VnbWVudDogICBrZXJuZWwgICAgICAgOiAweGMx
MDAwMDAwIC0+IDB4YzE0ZjAwMDAgIChwZm4gMHgxMDAwICsgMHg0ZjAgcGFn
ZXMpCmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogeGNfZG9tX3Bmbl90b19wdHI6
IGRvbVUgbWFwcGluZzogcGZuIDB4MTAwMCsweDRmMCBhdCAweGI1OGM1MDAw
CnhjOiBkZXRhaWw6IGVsZl9sb2FkX2JpbmFyeTogcGhkciAwIGF0IDB4MHhi
NThjNTAwMCAtPiAweDB4YjViNzYwMDAKeGM6IGRldGFpbDogZWxmX2xvYWRf
YmluYXJ5OiBwaGRyIDEgYXQgMHgweGI1Yjc2MDAwIC0+IDB4MHhiNWMxMzAw
MApkb21haW5idWlsZGVyOiBkZXRhaWw6IHhjX2RvbV9hbGxvY19zZWdtZW50
OiAgIHJhbWRpc2sgICAgICA6IDB4YzE0ZjAwMDAgLT4gMHhjMmMwZTAwMCAg
KHBmbiAweDE0ZjAgKyAweDE3MWUgcGFnZXMpCmRvbWFpbmJ1aWxkZXI6IGRl
dGFpbDogeGNfZG9tX21hbGxvYyAgICAgICAgICAgIDogMTM4IGtCCmRvbWFp
bmJ1aWxkZXI6IGRldGFpbDogeGNfZG9tX3Bmbl90b19wdHI6IGRvbVUgbWFw
cGluZzogcGZuIDB4MTRmMCsweDE3MWUgYXQgMHhiNDE4NDAwMApkb21haW5i
dWlsZGVyOiBkZXRhaWw6IHhjX2RvbV9kb19ndW56aXA6IHVuemlwIG9rLCAw
eDljNmYzNCAtPiAweDE3MWQ0MTAKZG9tYWluYnVpbGRlcjogZGV0YWlsOiB4
Y19kb21fYWxsb2Nfc2VnbWVudDogICBwaHlzMm1hY2ggICAgOiAweGMyYzBl
MDAwIC0+IDB4YzM2MGUwMDAgIChwZm4gMHgyYzBlICsgMHhhMDAgcGFnZXMp
CmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogeGNfZG9tX3Bmbl90b19wdHI6IGRv
bVUgbWFwcGluZzogcGZuIDB4MmMwZSsweGEwMCBhdCAweGIzNzg0MDAwCmRv
bWFpbmJ1aWxkZXI6IGRldGFpbDogeGNfZG9tX2FsbG9jX3BhZ2UgICA6ICAg
c3RhcnQgaW5mbyAgIDogMHhjMzYwZTAwMCAocGZuIDB4MzYwZSkKZG9tYWlu
YnVpbGRlcjogZGV0YWlsOiB4Y19kb21fYWxsb2NfcGFnZSAgIDogICB4ZW5z
dG9yZSAgICAgOiAweGMzNjBmMDAwIChwZm4gMHgzNjBmKQpkb21haW5idWls
ZGVyOiBkZXRhaWw6IHhjX2RvbV9hbGxvY19wYWdlICAgOiAgIGNvbnNvbGUg
ICAgICA6IDB4YzM2MTAwMDAgKHBmbiAweDM2MTApCmRvbWFpbmJ1aWxkZXI6
IGRldGFpbDogbnJfcGFnZV90YWJsZXM6IDB4MDAwMDAwMDBmZmZmZmZmZi8z
MjogMHgwMDAwMDAwMDAwMDAwMDAwIC0+IDB4ZmZmZmZmZmZmZmZmZmZmZiwg
MSB0YWJsZShzKQpkb21haW5idWlsZGVyOiBkZXRhaWw6IG5yX3BhZ2VfdGFi
bGVzOiAweDAwMDAwMDAwM2ZmZmZmZmYvMzA6IDB4MDAwMDAwMDBjMDAwMDAw
MCAtPiAweDAwMDAwMDAwZmZmZmZmZmYsIDEgdGFibGUocykKZG9tYWluYnVp
bGRlcjogZGV0YWlsOiBucl9wYWdlX3RhYmxlczogMHgwMDAwMDAwMDAwMWZm
ZmZmLzIxOiAweDAwMDAwMDAwYzAwMDAwMDAgLT4gMHgwMDAwMDAwMGMzN2Zm
ZmZmLCAyOCB0YWJsZShzKQpkb21haW5idWlsZGVyOiBkZXRhaWw6IHhjX2Rv
bV9hbGxvY19zZWdtZW50OiAgIHBhZ2UgdGFibGVzICA6IDB4YzM2MTEwMDAg
LT4gMHhjMzYyZjAwMCAgKHBmbiAweDM2MTEgKyAweDFlIHBhZ2VzKQpkb21h
aW5idWlsZGVyOiBkZXRhaWw6IHhjX2RvbV9wZm5fdG9fcHRyOiBkb21VIG1h
cHBpbmc6IHBmbiAweDM2MTErMHgxZSBhdCAweGIzNzY2MDAwCmRvbWFpbmJ1
aWxkZXI6IGRldGFpbDogeGNfZG9tX2FsbG9jX3BhZ2UgICA6ICAgYm9vdCBz
dGFjayAgIDogMHhjMzYyZjAwMCAocGZuIDB4MzYyZikKZG9tYWluYnVpbGRl
cjogZGV0YWlsOiB4Y19kb21fYnVpbGRfaW1hZ2UgIDogdmlydF9hbGxvY19l
bmQgOiAweGMzNjMwMDAwCmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogeGNfZG9t
X2J1aWxkX2ltYWdlICA6IHZpcnRfcGd0YWJfZW5kIDogMHhjMzgwMDAwMApk
b21haW5idWlsZGVyOiBkZXRhaWw6IHhjX2RvbV9ib290X2ltYWdlOiBjYWxs
ZWQKZG9tYWluYnVpbGRlcjogZGV0YWlsOiBhcmNoX3NldHVwX2Jvb3RlYXJs
eTogZG9pbmcgbm90aGluZwpkb21haW5idWlsZGVyOiBkZXRhaWw6IHhjX2Rv
bV9jb21wYXRfY2hlY2s6IHN1cHBvcnRlZCBndWVzdCB0eXBlOiB4ZW4tMy4w
LXg4Nl82NApkb21haW5idWlsZGVyOiBkZXRhaWw6IHhjX2RvbV9jb21wYXRf
Y2hlY2s6IHN1cHBvcnRlZCBndWVzdCB0eXBlOiB4ZW4tMy4wLXg4Nl8zMnAg
PD0gbWF0Y2hlcwpkb21haW5idWlsZGVyOiBkZXRhaWw6IHhjX2RvbV9jb21w
YXRfY2hlY2s6IHN1cHBvcnRlZCBndWVzdCB0eXBlOiBodm0tMy4wLXg4Nl8z
Mgpkb21haW5idWlsZGVyOiBkZXRhaWw6IHhjX2RvbV9jb21wYXRfY2hlY2s6
IHN1cHBvcnRlZCBndWVzdCB0eXBlOiBodm0tMy4wLXg4Nl8zMnAKZG9tYWlu
YnVpbGRlcjogZGV0YWlsOiB4Y19kb21fY29tcGF0X2NoZWNrOiBzdXBwb3J0
ZWQgZ3Vlc3QgdHlwZTogaHZtLTMuMC14ODZfNjQKZG9tYWluYnVpbGRlcjog
ZGV0YWlsOiB4Y19kb21fdXBkYXRlX2d1ZXN0X3AybTogZHN0IDMyYml0LCBw
YWdlcyAweDI4MDAwMApkb21haW5idWlsZGVyOiBkZXRhaWw6IGNsZWFyX3Bh
Z2U6IHBmbiAweDM2MTAsIG1mbiAweDQwNTMyYwpkb21haW5idWlsZGVyOiBk
ZXRhaWw6IGNsZWFyX3BhZ2U6IHBmbiAweDM2MGYsIG1mbiAweDQwNTMyZApk
b21haW5idWlsZGVyOiBkZXRhaWw6IHhjX2RvbV9wZm5fdG9fcHRyOiBkb21V
IG1hcHBpbmc6IHBmbiAweDM2MGUrMHgxIGF0IDB4YjM3NjMwMDAKZG9tYWlu
YnVpbGRlcjogZGV0YWlsOiBzdGFydF9pbmZvX3g4Nl8zMjogY2FsbGVkCmRv
bWFpbmJ1aWxkZXI6IGRldGFpbDogc2V0dXBfaHlwZXJjYWxsX3BhZ2U6IHZh
ZGRyPTB4YzEwMDIwMDAgcGZuPTB4MTAwMgpkb21haW5idWlsZGVyOiBkZXRh
aWw6IGRvbWFpbiBidWlsZGVyIG1lbW9yeSBmb290cHJpbnQKZG9tYWluYnVp
bGRlcjogZGV0YWlsOiAgICBhbGxvY2F0ZWQKZG9tYWluYnVpbGRlcjogZGV0
YWlsOiAgICAgICBtYWxsb2MgICAgICAgICAgICAgOiAxNDIzNCBrQgpkb21h
aW5idWlsZGVyOiBkZXRhaWw6ICAgICAgIGFub24gbW1hcCAgICAgICAgICA6
IDAgYnl0ZXMKZG9tYWluYnVpbGRlcjogZGV0YWlsOiAgICBtYXBwZWQKZG9t
YWluYnVpbGRlcjogZGV0YWlsOiAgICAgICBmaWxlIG1tYXAgICAgICAgICAg
OiAxMTg3MiBrQgpkb21haW5idWlsZGVyOiBkZXRhaWw6ICAgICAgIGRvbVUg
bW1hcCAgICAgICAgICA6IDM4IE1CCmRvbWFpbmJ1aWxkZXI6IGRldGFpbDog
YXJjaF9zZXR1cF9ib290bGF0ZTogc2hhcmVkX2luZm86IHBmbiAweDAsIG1m
biAweGJmMjJkCmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogc2hhcmVkX2luZm9f
eDg2XzMyOiBjYWxsZWQKZG9tYWluYnVpbGRlcjogZGV0YWlsOiB2Y3B1X3g4
Nl8zMjogY2FsbGVkCmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogdmNwdV94ODZf
MzI6IGNyMzogcGZuIDB4MzYxMSBtZm4gMHg0MDUzMmIKZG9tYWluYnVpbGRl
cjogZGV0YWlsOiBsYXVuY2hfdm06IGNhbGxlZCwgY3R4dD0weGJmODM4ODZj
CmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogeGNfZG9tX3JlbGVhc2U6IGNhbGxl
ZApsaWJ4bDogZGVidWc6IGxpYnhsX2RldmljZS5jOjIyOTpsaWJ4bF9fZGV2
aWNlX2Rpc2tfc2V0X2JhY2tlbmQ6IERpc2sgdmRldj14dmRhMSBzcGVjLmJh
Y2tlbmQ9cGh5CmxpYnhsOiBkZWJ1ZzogbGlieGxfZXZlbnQuYzo1MTI6bGli
eGxfX2V2X3hzd2F0Y2hfcmVnaXN0ZXI6IHdhdGNoIHc9MHg4MDZjYmQwIHdw
YXRoPS9sb2NhbC9kb21haW4vMC9iYWNrZW5kL3ZiZC83LzUxNzEzL3N0YXRl
IHRva2VuPTMvMDogcmVnaXN0ZXIgc2xvdG51bT0zCmxpYnhsOiBkZWJ1Zzog
bGlieGxfZGV2aWNlLmM6MjI5OmxpYnhsX19kZXZpY2VfZGlza19zZXRfYmFj
a2VuZDogRGlzayB2ZGV2PXh2ZGIgc3BlYy5iYWNrZW5kPXBoeQpsaWJ4bDog
ZGVidWc6IGxpYnhsX2RldmljZS5jOjIyOTpsaWJ4bF9fZGV2aWNlX2Rpc2tf
c2V0X2JhY2tlbmQ6IERpc2sgdmRldj14dmRiIHNwZWMuYmFja2VuZD1waHkK
bGlieGw6IGRlYnVnOiBsaWJ4bF9ldmVudC5jOjUxMjpsaWJ4bF9fZXZfeHN3
YXRjaF9yZWdpc3Rlcjogd2F0Y2ggdz0weDgwNmQ1NDAgd3BhdGg9L2xvY2Fs
L2RvbWFpbi8wL2JhY2tlbmQvdmJkLzcvNTE3Mjgvc3RhdGUgdG9rZW49Mi8x
OiByZWdpc3RlciBzbG90bnVtPTIKbGlieGw6IGRlYnVnOiBsaWJ4bF9jcmVh
dGUuYzoxMTg2OmRvX2RvbWFpbl9jcmVhdGU6IGFvIDB4ODA2YmVmODogaW5w
cm9ncmVzczogcG9sbGVyPTB4ODA2YjY4OCwgZmxhZ3M9aQpsaWJ4bDogZGVi
dWc6IGxpYnhsX2V2ZW50LmM6NDU3OndhdGNoZmRfY2FsbGJhY2s6IHdhdGNo
IHc9MHg4MDZjYmQwIHdwYXRoPS9sb2NhbC9kb21haW4vMC9iYWNrZW5kL3Zi
ZC83LzUxNzEzL3N0YXRlIHRva2VuPTMvMDogZXZlbnQgZXBhdGg9L2xvY2Fs
L2RvbWFpbi8wL2JhY2tlbmQvdmJkLzcvNTE3MTMvc3RhdGUKbGlieGw6IGRl
YnVnOiBsaWJ4bF9ldmVudC5jOjU5NjpkZXZzdGF0ZV93YXRjaF9jYWxsYmFj
azogYmFja2VuZCAvbG9jYWwvZG9tYWluLzAvYmFja2VuZC92YmQvNy81MTcx
My9zdGF0ZSB3YW50ZWQgc3RhdGUgMiBvawpsaWJ4bDogZGVidWc6IGxpYnhs
X2V2ZW50LmM6NTQ5OmxpYnhsX19ldl94c3dhdGNoX2RlcmVnaXN0ZXI6IHdh
dGNoIHc9MHg4MDZjYmQwIHdwYXRoPS9sb2NhbC9kb21haW4vMC9iYWNrZW5k
L3ZiZC83LzUxNzEzL3N0YXRlIHRva2VuPTMvMDogZGVyZWdpc3RlciBzbG90
bnVtPTMKbGlieGw6IGRlYnVnOiBsaWJ4bF9ldmVudC5jOjU2MTpsaWJ4bF9f
ZXZfeHN3YXRjaF9kZXJlZ2lzdGVyOiB3YXRjaCB3PTB4ODA2Y2JkMDogZGVy
ZWdpc3RlciB1bnJlZ2lzdGVyZWQKbGlieGw6IGRlYnVnOiBsaWJ4bF9kZXZp
Y2UuYzo5MTY6ZGV2aWNlX2hvdHBsdWc6IGNhbGxpbmcgaG90cGx1ZyBzY3Jp
cHQ6IC9ldGMveGVuL3NjcmlwdHMvYmxvY2sgYWRkCmxpYnhsOiBkZWJ1Zzog
bGlieGxfZXZlbnQuYzo0MjY6d2F0Y2hmZF9jYWxsYmFjazogd2F0Y2ggZXBh
dGg9L2xvY2FsL2RvbWFpbi8wL2JhY2tlbmQvdmJkLzcvNTE3MTMvc3RhdGUg
dG9rZW49My8wOiBlbXB0eSBzbG90CmxpYnhsOiBkZWJ1ZzogbGlieGxfZXZl
bnQuYzo0NTc6d2F0Y2hmZF9jYWxsYmFjazogd2F0Y2ggdz0weDgwNmQ1NDAg
d3BhdGg9L2xvY2FsL2RvbWFpbi8wL2JhY2tlbmQvdmJkLzcvNTE3Mjgvc3Rh
dGUgdG9rZW49Mi8xOiBldmVudCBlcGF0aD0vbG9jYWwvZG9tYWluLzAvYmFj
a2VuZC92YmQvNy81MTcyOC9zdGF0ZQpsaWJ4bDogZGVidWc6IGxpYnhsX2V2
ZW50LmM6NTk2OmRldnN0YXRlX3dhdGNoX2NhbGxiYWNrOiBiYWNrZW5kIC9s
b2NhbC9kb21haW4vMC9iYWNrZW5kL3ZiZC83LzUxNzI4L3N0YXRlIHdhbnRl
ZCBzdGF0ZSAyIG9rCmxpYnhsOiBkZWJ1ZzogbGlieGxfZXZlbnQuYzo1NDk6
bGlieGxfX2V2X3hzd2F0Y2hfZGVyZWdpc3Rlcjogd2F0Y2ggdz0weDgwNmQ1
NDAgd3BhdGg9L2xvY2FsL2RvbWFpbi8wL2JhY2tlbmQvdmJkLzcvNTE3Mjgv
c3RhdGUgdG9rZW49Mi8xOiBkZXJlZ2lzdGVyIHNsb3RudW09MgpsaWJ4bDog
ZGVidWc6IGxpYnhsX2V2ZW50LmM6NTYxOmxpYnhsX19ldl94c3dhdGNoX2Rl
cmVnaXN0ZXI6IHdhdGNoIHc9MHg4MDZkNTQwOiBkZXJlZ2lzdGVyIHVucmVn
aXN0ZXJlZApsaWJ4bDogZGVidWc6IGxpYnhsX2RldmljZS5jOjkxNjpkZXZp
Y2VfaG90cGx1ZzogY2FsbGluZyBob3RwbHVnIHNjcmlwdDogL2V0Yy94ZW4v
c2NyaXB0cy9ibG9jayBhZGQKbGlieGw6IGRlYnVnOiBsaWJ4bF9ldmVudC5j
OjQyNjp3YXRjaGZkX2NhbGxiYWNrOiB3YXRjaCBlcGF0aD0vbG9jYWwvZG9t
YWluLzAvYmFja2VuZC92YmQvNy81MTcyOC9zdGF0ZSB0b2tlbj0yLzE6IGVt
cHR5IHNsb3QKbGlieGw6IGRlYnVnOiBsaWJ4bF9ldmVudC5jOjUxMjpsaWJ4
bF9fZXZfeHN3YXRjaF9yZWdpc3Rlcjogd2F0Y2ggdz0weDgwNmViMjggd3Bh
dGg9L2xvY2FsL2RvbWFpbi8wL2JhY2tlbmQvdmlmLzcvMC9zdGF0ZSB0b2tl
bj0yLzI6IHJlZ2lzdGVyIHNsb3RudW09MgpsaWJ4bDogZGVidWc6IGxpYnhs
X2V2ZW50LmM6NDU3OndhdGNoZmRfY2FsbGJhY2s6IHdhdGNoIHc9MHg4MDZl
YjI4IHdwYXRoPS9sb2NhbC9kb21haW4vMC9iYWNrZW5kL3ZpZi83LzAvc3Rh
dGUgdG9rZW49Mi8yOiBldmVudCBlcGF0aD0vbG9jYWwvZG9tYWluLzAvYmFj
a2VuZC92aWYvNy8wL3N0YXRlCmxpYnhsOiBkZWJ1ZzogbGlieGxfZXZlbnQu
Yzo2MDA6ZGV2c3RhdGVfd2F0Y2hfY2FsbGJhY2s6IGJhY2tlbmQgL2xvY2Fs
L2RvbWFpbi8wL2JhY2tlbmQvdmlmLzcvMC9zdGF0ZSB3YW50ZWQgc3RhdGUg
MiBzdGlsbCB3YWl0aW5nIHN0YXRlIDEKbGlieGw6IGRlYnVnOiBsaWJ4bF9l
dmVudC5jOjQ1Nzp3YXRjaGZkX2NhbGxiYWNrOiB3YXRjaCB3PTB4ODA2ZWIy
OCB3cGF0aD0vbG9jYWwvZG9tYWluLzAvYmFja2VuZC92aWYvNy8wL3N0YXRl
IHRva2VuPTIvMjogZXZlbnQgZXBhdGg9L2xvY2FsL2RvbWFpbi8wL2JhY2tl
bmQvdmlmLzcvMC9zdGF0ZQpsaWJ4bDogZGVidWc6IGxpYnhsX2V2ZW50LmM6
NTk2OmRldnN0YXRlX3dhdGNoX2NhbGxiYWNrOiBiYWNrZW5kIC9sb2NhbC9k
b21haW4vMC9iYWNrZW5kL3ZpZi83LzAvc3RhdGUgd2FudGVkIHN0YXRlIDIg
b2sKbGlieGw6IGRlYnVnOiBsaWJ4bF9ldmVudC5jOjU0OTpsaWJ4bF9fZXZf
eHN3YXRjaF9kZXJlZ2lzdGVyOiB3YXRjaCB3PTB4ODA2ZWIyOCB3cGF0aD0v
bG9jYWwvZG9tYWluLzAvYmFja2VuZC92aWYvNy8wL3N0YXRlIHRva2VuPTIv
MjogZGVyZWdpc3RlciBzbG90bnVtPTIKbGlieGw6IGRlYnVnOiBsaWJ4bF9l
dmVudC5jOjU2MTpsaWJ4bF9fZXZfeHN3YXRjaF9kZXJlZ2lzdGVyOiB3YXRj
aCB3PTB4ODA2ZWIyODogZGVyZWdpc3RlciB1bnJlZ2lzdGVyZWQKbGlieGw6
IGRlYnVnOiBsaWJ4bF9kZXZpY2UuYzo5MTY6ZGV2aWNlX2hvdHBsdWc6IGNh
bGxpbmcgaG90cGx1ZyBzY3JpcHQ6IC9ldGMveGVuL3NjcmlwdHMvdmlmLWJy
aWRnZSBvbmxpbmUKbGlieGw6IGVycm9yOiBsaWJ4bF9wY2kuYzoxMDAxOmxp
YnhsX19kZXZpY2VfcGNpX3Jlc2V0OiBUaGUga2VybmVsIGRvZXNuJ3Qgc3Vw
cG9ydCByZXNldCBmcm9tIHN5c2ZzIGZvciBQQ0kgZGV2aWNlIDAwMDA6MDE6
MDAuMApsaWJ4bDogZXJyb3I6IGxpYnhsX3BjaS5jOjEwMDE6bGlieGxfX2Rl
dmljZV9wY2lfcmVzZXQ6IFRoZSBrZXJuZWwgZG9lc24ndCBzdXBwb3J0IHJl
c2V0IGZyb20gc3lzZnMgZm9yIFBDSSBkZXZpY2UgMDAwMDowMTowMC4xCmxp
YnhsOiBkZWJ1ZzogbGlieGxfcGNpLmM6ODU6bGlieGxfX2NyZWF0ZV9wY2lf
YmFja2VuZDogQ3JlYXRpbmcgcGNpIGJhY2tlbmQKbGlieGw6IGRlYnVnOiBs
aWJ4bF94ODYuYzo5MDplODIwX3Nhbml0aXplOiBNZW1vcnk6IDEwNDg1NzYw
a0IgRW5kIG9mIFJBTTogMHhiZjY5OSAoUEZOKSBEZWx0YTogNzM0OTY2MGtC
LCBQQ0kgc3RhcnQ6IDMxMzYxMDBrQiAoMHhiZjY5OSBQRk4pLCBCYWxsb29u
IDBrQgoKbGlieGw6IGRlYnVnOiBsaWJ4bF94ODYuYzoyMDk6ZTgyMF9zYW5p
dGl6ZTogOiAgWzAgLT4gYmY2OTldIFJBTQpsaWJ4bDogZGVidWc6IGxpYnhs
X3g4Ni5jOjIwOTplODIwX3Nhbml0aXplOiA6ICBbYmY2OTkgLT4gYmY2YWZd
IFJlc2VydmVkCmxpYnhsOiBkZWJ1ZzogbGlieGxfeDg2LmM6MjA5OmU4MjBf
c2FuaXRpemU6IDogIFtiZjZhZiAtPiBiZjZjZV0gQUNQSQpsaWJ4bDogZGVi
dWc6IGxpYnhsX3g4Ni5jOjIwOTplODIwX3Nhbml0aXplOiA6ICBbYmY2Y2Ug
LT4gYzAwMDBdIFJlc2VydmVkCmxpYnhsOiBkZWJ1ZzogbGlieGxfeDg2LmM6
MjA5OmU4MjBfc2FuaXRpemU6IDogIFtlMDAwMCAtPiBmMDAwMF0gUmVzZXJ2
ZWQKbGlieGw6IGRlYnVnOiBsaWJ4bF94ODYuYzoyMDk6ZTgyMF9zYW5pdGl6
ZTogOiAgW2ZlMDAwIC0+IDEwMDAwMF0gUmVzZXJ2ZWQKbGlieGw6IGRlYnVn
OiBsaWJ4bF9ldmVudC5jOjE2Njc6bGlieGxfX2FvX3Byb2dyZXNzX3JlcG9y
dDogYW8gMHg4MDZiZWY4OiBwcm9ncmVzcyByZXBvcnQ6IGlnbm9yZWQKbGli
eGw6IGRlYnVnOiBsaWJ4bF9ldmVudC5jOjE0OTc6bGlieGxfX2FvX2NvbXBs
ZXRlOiBhbyAweDgwNmJlZjg6IGNvbXBsZXRlLCByYz0wCmxpYnhsOiBkZWJ1
ZzogbGlieGxfZXZlbnQuYzoxNDY5OmxpYnhsX19hb19fZGVzdHJveTogYW8g
MHg4MDZiZWY4OiBkZXN0cm95CkRhZW1vbiBydW5uaW5nIHdpdGggUElEIDU5
MzAKeGM6IGRlYnVnOiBoeXBlcmNhbGwgYnVmZmVyOiB0b3RhbCBhbGxvY2F0
aW9uczoxOTkgdG90YWwgcmVsZWFzZXM6MTk5CnhjOiBkZWJ1ZzogaHlwZXJj
YWxsIGJ1ZmZlcjogY3VycmVudCBhbGxvY2F0aW9uczowIG1heGltdW0gYWxs
b2NhdGlvbnM6Mgp4YzogZGVidWc6IGh5cGVyY2FsbCBidWZmZXI6IGNhY2hl
IGN1cnJlbnQgc2l6ZToyCnhjOiBkZWJ1ZzogaHlwZXJjYWxsIGJ1ZmZlcjog
Y2FjaGUgaGl0czoxOTEgbWlzc2VzOjIgdG9vYmlnOjYK

--_006_E71FC5D6F96C3C4B93FC8FF942D924C682F44808SBJEXCH1Bwebsen_
Content-Type: application/octet-stream; name="xl-list.output"
Content-Description: xl-list.output
Content-Disposition: attachment; creation-date="Mon, 22 Oct 2012 10:09:56 GMT"; filename="xl-list.output"; modification-date="Mon, 22 Oct 2012 18:05:40 GMT"; size="268"
Content-Transfer-Encoding: base64

W3Jvb3RAbG9jYWxob3N0IH5dIyB4bCBsaXN0Ck5hbWUgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgSUQgICBNZW0gVkNQVXMgICAg
ICBTdGF0ZSAgIFRpbWUocykKRG9tYWluLTAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgMCAgMjA0OCAgICAgMiAgICAgci0tLS0tICAg
ICAyNDYuMQp3Y2cgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICA3ICAzMzYwICAgICA0ICAgICAtYi0tLS0gICAgICA1MC4zCg==

--_006_E71FC5D6F96C3C4B93FC8FF942D924C682F44808SBJEXCH1Bwebsen_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_006_E71FC5D6F96C3C4B93FC8FF942D924C682F44808SBJEXCH1Bwebsen_--


From xen-devel-bounces@lists.xen.org Mon Oct 22 10:34:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 10:34:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQFKu-0005kS-Le; Mon, 22 Oct 2012 10:34:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQFKt-0005kK-HP; Mon, 22 Oct 2012 10:34:19 +0000
Received: from [85.158.139.83:16806] by server-16.bemta-5.messagelabs.com id
	61/FD-09196-A2125805; Mon, 22 Oct 2012 10:34:18 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1350902058!21839853!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUxNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2631 invoked from network); 22 Oct 2012 10:34:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 10:34:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,629,1344211200"; d="scan'208";a="15304807"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Oct 2012 10:34:17 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Mon, 22 Oct 2012 11:34:18 +0100
Date: Mon, 22 Oct 2012 11:33:50 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: =?UTF-8?Q?Pasi_K=C3=A4rkk=C3=A4inen?= 
In-Reply-To: <20121020221355.GR8912@reaktio.net>
Message-ID: 
References: 
	<1350466992.2460.47.camel@zakaz.uk.xensource.com>
	
	<1350568154.2460.151.camel@zakaz.uk.xensource.com>
	
	<20121019142100.GN26830@phenom.dumpdata.com>
	
	<20121020221355.GR8912@reaktio.net>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="1342847746-428940461-1350902045=:2689"
Cc: Ian Campbell ,
	Stefano Stabellini ,
	Konrad Rzeszutek Wilk ,
	xen-devel , kk s ,
	"xen-users@lists.xen.org" 
Subject: Re: [Xen-devel] [Xen-users] Fedora 17 Dom-U booting issue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--1342847746-428940461-1350902045=:2689
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT

On Sat, 20 Oct 2012, Pasi Kärkkäinen wrote:
> On Sun, Oct 21, 2012 at 12:03:47AM +0530, kk s wrote:
> >    Hi,
> >    Looks like the serial='pty' parameter already passed which doesn't work.
> >    Though I can't add do 'loglevel=8 initcall_debug console=ttyS0,115200
> >    debug' since its Xen HVM and without booted the VM we can't add anything
> >    in grub.conf file.
> >
> 
> Open the VNC console for the HVM guest and edit grub settings / kernel parameters? 

If the disk image is in raw format you can also mount it in dom0, using
lomount if it is a file or kpartx if it is a physical device.

On the latest version of Xen you can even mount non-raw disks in dom0,
simply calling xl block-attach on them, specifying 0 as the target
domain.
--1342847746-428940461-1350902045=:2689
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--1342847746-428940461-1350902045=:2689--


From xen-devel-bounces@lists.xen.org Mon Oct 22 10:34:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 10:34:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQFKu-0005kS-Le; Mon, 22 Oct 2012 10:34:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQFKt-0005kK-HP; Mon, 22 Oct 2012 10:34:19 +0000
Received: from [85.158.139.83:16806] by server-16.bemta-5.messagelabs.com id
	61/FD-09196-A2125805; Mon, 22 Oct 2012 10:34:18 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1350902058!21839853!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUxNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2631 invoked from network); 22 Oct 2012 10:34:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 10:34:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,629,1344211200"; d="scan'208";a="15304807"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Oct 2012 10:34:17 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Mon, 22 Oct 2012 11:34:18 +0100
Date: Mon, 22 Oct 2012 11:33:50 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: =?UTF-8?Q?Pasi_K=C3=A4rkk=C3=A4inen?= 
In-Reply-To: <20121020221355.GR8912@reaktio.net>
Message-ID: 
References: 
	<1350466992.2460.47.camel@zakaz.uk.xensource.com>
	
	<1350568154.2460.151.camel@zakaz.uk.xensource.com>
	
	<20121019142100.GN26830@phenom.dumpdata.com>
	
	<20121020221355.GR8912@reaktio.net>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="1342847746-428940461-1350902045=:2689"
Cc: Ian Campbell ,
	Stefano Stabellini ,
	Konrad Rzeszutek Wilk ,
	xen-devel , kk s ,
	"xen-users@lists.xen.org" 
Subject: Re: [Xen-devel] [Xen-users] Fedora 17 Dom-U booting issue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--1342847746-428940461-1350902045=:2689
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT

On Sat, 20 Oct 2012, Pasi Kärkkäinen wrote:
> On Sun, Oct 21, 2012 at 12:03:47AM +0530, kk s wrote:
> >    Hi,
> >    Looks like the serial='pty' parameter already passed which doesn't work.
> >    Though I can't add do 'loglevel=8 initcall_debug console=ttyS0,115200
> >    debug' since its Xen HVM and without booted the VM we can't add anything
> >    in grub.conf file.
> >
> 
> Open the VNC console for the HVM guest and edit grub settings / kernel parameters? 

If the disk image is in raw format you can also mount it in dom0, using
lomount if it is a file or kpartx if it is a physical device.

On the latest version of Xen you can even mount non-raw disks in dom0,
simply calling xl block-attach on them, specifying 0 as the target
domain.
--1342847746-428940461-1350902045=:2689
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--1342847746-428940461-1350902045=:2689--


From xen-devel-bounces@lists.xen.org Mon Oct 22 10:54:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 10:54:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQFeO-0006W5-SG; Mon, 22 Oct 2012 10:54:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQFeN-0006Vz-Fk
	for xen-devel@lists.xensource.com; Mon, 22 Oct 2012 10:54:27 +0000
Received: from [85.158.138.51:55433] by server-13.bemta-3.messagelabs.com id
	BA/0A-26794-2E525805; Mon, 22 Oct 2012 10:54:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1350903265!35277982!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUxNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5631 invoked from network); 22 Oct 2012 10:54:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 10:54:25 -0000
X-IronPort-AV: E=Sophos;i="4.80,629,1344211200"; d="scan'208";a="15305350"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Oct 2012 10:54:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Mon, 22 Oct 2012 11:54:25 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TQFeL-0006Aa-4m; Mon, 22 Oct 2012 10:54:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TQFeK-0005Ib-WC;
	Mon, 22 Oct 2012 11:54:24 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20613.9696.715106.47187@mariner.uk.xensource.com>
Date: Mon, 22 Oct 2012 11:54:24 +0100
To: George Dunlap 
In-Reply-To: 
References: 
	<20609.28264.158580.995717@mariner.uk.xensource.com>
	
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "Liu, Jinsong" ,
	Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 5/5] X86/vMCE: guest broken page handling
 when migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("Re: [Xen-devel] [PATCH 5/5] X86/vMCE: guest broken page handling when migration"):
> On Fri, Oct 19, 2012 at 4:14 PM, Ian Jackson  wrote:
> > This looks plausible to me, as far as the tools go.  Can you explain
> > how you have tested this ?  Did you manage to do any tests of the
> > remus codepaths ?
> 
> I'm pretty sure that this shouldn't cause any problems with Remus.  If
> it's difficult for Jinsong to test Remus, I think probably OK to
> commit it, and then revert it if the Remus guys have any problems.

OK.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 10:54:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 10:54:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQFeO-0006W5-SG; Mon, 22 Oct 2012 10:54:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQFeN-0006Vz-Fk
	for xen-devel@lists.xensource.com; Mon, 22 Oct 2012 10:54:27 +0000
Received: from [85.158.138.51:55433] by server-13.bemta-3.messagelabs.com id
	BA/0A-26794-2E525805; Mon, 22 Oct 2012 10:54:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1350903265!35277982!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUxNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5631 invoked from network); 22 Oct 2012 10:54:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 10:54:25 -0000
X-IronPort-AV: E=Sophos;i="4.80,629,1344211200"; d="scan'208";a="15305350"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Oct 2012 10:54:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Mon, 22 Oct 2012 11:54:25 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TQFeL-0006Aa-4m; Mon, 22 Oct 2012 10:54:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TQFeK-0005Ib-WC;
	Mon, 22 Oct 2012 11:54:24 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20613.9696.715106.47187@mariner.uk.xensource.com>
Date: Mon, 22 Oct 2012 11:54:24 +0100
To: George Dunlap 
In-Reply-To: 
References: 
	<20609.28264.158580.995717@mariner.uk.xensource.com>
	
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "Liu, Jinsong" ,
	Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 5/5] X86/vMCE: guest broken page handling
 when migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("Re: [Xen-devel] [PATCH 5/5] X86/vMCE: guest broken page handling when migration"):
> On Fri, Oct 19, 2012 at 4:14 PM, Ian Jackson  wrote:
> > This looks plausible to me, as far as the tools go.  Can you explain
> > how you have tested this ?  Did you manage to do any tests of the
> > remus codepaths ?
> 
> I'm pretty sure that this shouldn't cause any problems with Remus.  If
> it's difficult for Jinsong to test Remus, I think probably OK to
> commit it, and then revert it if the Remus guys have any problems.

OK.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 11:33:40 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 11:33:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQGFt-0006pa-4F; Mon, 22 Oct 2012 11:33:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQGFr-0006pV-MP
	for xen-devel@lists.xensource.com; Mon, 22 Oct 2012 11:33:12 +0000
Received: from [85.158.143.35:11006] by server-2.bemta-4.messagelabs.com id
	86/63-22268-7FE25805; Mon, 22 Oct 2012 11:33:11 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1350905588!4218782!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjIxNjkw\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2068 invoked from network); 22 Oct 2012 11:33:09 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-5.tower-21.messagelabs.com with SMTP;
	22 Oct 2012 11:33:09 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 22 Oct 2012 04:32:33 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,629,1344236400"; d="scan'208";a="207430110"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by azsmga001.ch.intel.com with ESMTP; 22 Oct 2012 04:32:32 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 22 Oct 2012 04:32:32 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.123]) with mapi id
	14.01.0355.002; Mon, 22 Oct 2012 19:32:30 +0800
From: "Liu, Jinsong" 
To: Ian Jackson 
Thread-Topic: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration when
	vMCE	occur
Thread-Index: AQHNrglhufJylTqUQruxPOzNlQzaHZfA6fPQgARKyeA=
Date: Mon, 22 Oct 2012 11:32:27 +0000
Message-ID: 
References: 
	<20609.26910.2416.305293@mariner.uk.xensource.com>
	
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC8292335361F91SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "Liu, Jinsong" ,
	Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration
	when	vMCE	occur
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC8292335361F91SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Update patch 4/5 as attached.

Thanks,
Jinsong

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Xen/MCE: Abort live migration when vMCE occur

This patch monitor the critical area of live migration (from vMCE point of =
view,
the copypages stage of migration is the critical area while other areas are=
 not).

If a vMCE occur at the critical area of live migration, there is risk that =
error
data may be copied to the target. Currently we don't have convenient way to=
 handle
this case, so for the sake of safe, we abort it. User can retry migration l=
ater (at
that time broken page would not be mapped and copied to the target).

Signed-off-by: Liu, Jinsong 

diff -r e27a6d53ac15 tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c	Thu Oct 11 01:52:33 2012 +0800
+++ b/tools/libxc/xc_domain.c	Mon Oct 22 21:43:34 2012 +0800
@@ -283,6 +283,30 @@
     return ret;
 }
=20
+/* Start vmce monitor */
+int xc_domain_vmce_monitor_start(xc_interface *xch,
+                                 uint32_t domid)
+{
+    DECLARE_DOMCTL;
+
+    domctl.cmd =3D XEN_DOMCTL_vmce_monitor_start;
+    domctl.domain =3D (domid_t)domid;
+
+    return do_domctl(xch, &domctl);
+}
+
+/* End vmce monitor */
+int xc_domain_vmce_monitor_end(xc_interface *xch,
+                               uint32_t domid)
+{
+    DECLARE_DOMCTL;
+
+    domctl.cmd =3D XEN_DOMCTL_vmce_monitor_end;
+    domctl.domain =3D (domid_t)domid;
+
+    return do_domctl(xch, &domctl);
+}
+
 /* get info from hvm guest for save */
 int xc_domain_hvm_getcontext(xc_interface *xch,
                              uint32_t domid,
diff -r e27a6d53ac15 tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Thu Oct 11 01:52:33 2012 +0800
+++ b/tools/libxc/xc_domain_save.c	Mon Oct 22 21:43:34 2012 +0800
@@ -895,6 +895,8 @@
      */
     int compressing =3D 0;
=20
+    int vmce_while_monitor =3D 0;
+
     int completed =3D 0;
=20
     if ( hvm && !callbacks->switch_qemu_logdirty )
@@ -1109,6 +1111,12 @@
         goto out;
     }
=20
+    if ( xc_domain_vmce_monitor_start(xch, dom) )
+    {
+        PERROR("Error starting vmce monitor");
+        goto out;
+    }
+
   copypages:
 #define wrexact(fd, buf, len) write_buffer(xch, last_iter, ob, (fd), (buf)=
, (len))
 #define wruncached(fd, live, buf, len) write_uncached(xch, last_iter, ob, =
(fd), (buf), (len))
@@ -1571,6 +1579,18 @@
=20
     DPRINTF("All memory is saved\n");
=20
+    vmce_while_monitor =3D xc_domain_vmce_monitor_end(xch, dom);
+    if ( vmce_while_monitor < 0 )
+    {
+        PERROR("Error ending vmce monitor");
+        goto out;
+    }
+    else if ( vmce_while_monitor > 0 )
+    {
+        ERROR("vMCE occurred, abort this time. User can retry later.");
+        goto out;
+    }
+
     /* After last_iter, buffer the rest of pagebuf & tailbuf data into a
      * separate output buffer and flush it after the compressed page chunk=
s.
      */
diff -r e27a6d53ac15 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Thu Oct 11 01:52:33 2012 +0800
+++ b/tools/libxc/xenctrl.h	Mon Oct 22 21:43:34 2012 +0800
@@ -575,6 +575,26 @@
                           xc_domaininfo_t *info);
=20
 /**
+ * This function start monitor vmce event.
+ * @parm xch a handle to an open hypervisor interface
+ * @parm domid the domain id monitored
+ * @return <0 on failure, 0 on success
+ */
+int xc_domain_vmce_monitor_start(xc_interface *xch,
+                                 uint32_t domid);
+
+/**
+ * This function end monitor vmce event
+ * @parm xch a handle to an open hypervisor interface
+ * @parm domid the domain id monitored
+ * @return < 0 on failure, >=3D 0 on success while
+ *   =3D 0 on no vmce occurred
+ *   > 0 on vmce occurred
+ */
+int xc_domain_vmce_monitor_end(xc_interface *xch,
+                               uint32_t domid);
+
+/**
  * This function returns information about the context of a hvm domain
  * @parm xch a handle to an open hypervisor interface
  * @parm domid the domain to get information from
diff -r e27a6d53ac15 xen/arch/x86/cpu/mcheck/mce_intel.c
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c	Thu Oct 11 01:52:33 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c	Mon Oct 22 21:43:34 2012 +0800
@@ -359,6 +359,12 @@
                     goto vmce_failed;
                 }
=20
+                if ( unlikely(d->arch.vmce_monitor) )
+                {
+                    /* vMCE occur when guest migration */
+                    d->arch.vmce_monitor =3D 1;
+                }
+
                 /* We will inject vMCE to DOMU*/
                 if ( inject_vmce(d, VMCE_INJECT_BROADCAST) < 0 )
                 {
diff -r e27a6d53ac15 xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c	Thu Oct 11 01:52:33 2012 +0800
+++ b/xen/arch/x86/domctl.c	Mon Oct 22 21:43:34 2012 +0800
@@ -1568,6 +1568,47 @@
     }
     break;
=20
+    case XEN_DOMCTL_vmce_monitor_start:
+    {
+        struct domain *d;
+
+        d =3D rcu_lock_domain_by_id(domctl->domain);
+        if ( d !=3D NULL )
+        {
+            if ( d->arch.vmce_monitor )
+                ret =3D -EBUSY;
+            else
+                d->arch.vmce_monitor =3D -1;
+
+            rcu_unlock_domain(d);
+        }
+        else
+            ret =3D -ESRCH;
+    }
+    break;
+
+    case XEN_DOMCTL_vmce_monitor_end:
+    {
+        struct domain *d;
+
+        d =3D rcu_lock_domain_by_id(domctl->domain);
+        if ( d !=3D NULL)
+        {
+            if ( !d->arch.vmce_monitor )
+                ret =3D -EINVAL;
+            else
+            {
+                ret =3D d->arch.vmce_monitor > 0 ? 1 : 0;
+                d->arch.vmce_monitor =3D 0;
+            }
+
+            rcu_unlock_domain(d);
+        }
+        else
+            ret =3D -ESRCH;
+    }
+    break;
+
     default:
         ret =3D iommu_do_domctl(domctl, u_domctl);
         break;
diff -r e27a6d53ac15 xen/include/asm-x86/domain.h
--- a/xen/include/asm-x86/domain.h	Thu Oct 11 01:52:33 2012 +0800
+++ b/xen/include/asm-x86/domain.h	Mon Oct 22 21:43:34 2012 +0800
@@ -279,6 +279,11 @@
     bool_t has_32bit_shinfo;
     /* Domain cannot handle spurious page faults? */
     bool_t suppress_spurious_page_faults;
+    /* Monitoring guest memory copy of migration
+     * =3D 0 - not monitoring
+     * < 0 - monitoring
+     * > 0 - vMCE occurred while monitoring */
+    s8 vmce_monitor;
=20
     /* Continuable domain_relinquish_resources(). */
     enum {
diff -r e27a6d53ac15 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h	Thu Oct 11 01:52:33 2012 +0800
+++ b/xen/include/public/domctl.h	Mon Oct 22 21:43:34 2012 +0800
@@ -900,6 +900,8 @@
 #define XEN_DOMCTL_set_access_required           64
 #define XEN_DOMCTL_audit_p2m                     65
 #define XEN_DOMCTL_set_virq_handler              66
+#define XEN_DOMCTL_vmce_monitor_start            67
+#define XEN_DOMCTL_vmce_monitor_end              68
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002=

--_002_DE8DF0795D48FD4CA783C40EC8292335361F91SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="4_vmce_when_migrate.patch"
Content-Description: 4_vmce_when_migrate.patch
Content-Disposition: attachment; filename="4_vmce_when_migrate.patch";
	size=6845; creation-date="Mon, 22 Oct 2012 11:27:23 GMT";
	modification-date="Mon, 22 Oct 2012 13:43:52 GMT"
Content-Transfer-Encoding: base64

WGVuL01DRTogQWJvcnQgbGl2ZSBtaWdyYXRpb24gd2hlbiB2TUNFIG9jY3VyCgpUaGlzIHBhdGNo
IG1vbml0b3IgdGhlIGNyaXRpY2FsIGFyZWEgb2YgbGl2ZSBtaWdyYXRpb24gKGZyb20gdk1DRSBw
b2ludCBvZiB2aWV3LAp0aGUgY29weXBhZ2VzIHN0YWdlIG9mIG1pZ3JhdGlvbiBpcyB0aGUgY3Jp
dGljYWwgYXJlYSB3aGlsZSBvdGhlciBhcmVhcyBhcmUgbm90KS4KCklmIGEgdk1DRSBvY2N1ciBh
dCB0aGUgY3JpdGljYWwgYXJlYSBvZiBsaXZlIG1pZ3JhdGlvbiwgdGhlcmUgaXMgcmlzayB0aGF0
IGVycm9yCmRhdGEgbWF5IGJlIGNvcGllZCB0byB0aGUgdGFyZ2V0LiBDdXJyZW50bHkgd2UgZG9u
J3QgaGF2ZSBjb252ZW5pZW50IHdheSB0byBoYW5kbGUKdGhpcyBjYXNlLCBzbyBmb3IgdGhlIHNh
a2Ugb2Ygc2FmZSwgd2UgYWJvcnQgaXQuIFVzZXIgY2FuIHJldHJ5IG1pZ3JhdGlvbiBsYXRlciAo
YXQKdGhhdCB0aW1lIGJyb2tlbiBwYWdlIHdvdWxkIG5vdCBiZSBtYXBwZWQgYW5kIGNvcGllZCB0
byB0aGUgdGFyZ2V0KS4KClNpZ25lZC1vZmYtYnk6IExpdSwgSmluc29uZyA8amluc29uZy5saXVA
aW50ZWwuY29tPgoKZGlmZiAtciBlMjdhNmQ1M2FjMTUgdG9vbHMvbGlieGMveGNfZG9tYWluLmMK
LS0tIGEvdG9vbHMvbGlieGMveGNfZG9tYWluLmMJVGh1IE9jdCAxMSAwMTo1MjozMyAyMDEyICsw
ODAwCisrKyBiL3Rvb2xzL2xpYnhjL3hjX2RvbWFpbi5jCU1vbiBPY3QgMjIgMjE6NDM6MzQgMjAx
MiArMDgwMApAQCAtMjgzLDYgKzI4MywzMCBAQAogICAgIHJldHVybiByZXQ7CiB9CiAKKy8qIFN0
YXJ0IHZtY2UgbW9uaXRvciAqLworaW50IHhjX2RvbWFpbl92bWNlX21vbml0b3Jfc3RhcnQoeGNf
aW50ZXJmYWNlICp4Y2gsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJf
dCBkb21pZCkKK3sKKyAgICBERUNMQVJFX0RPTUNUTDsKKworICAgIGRvbWN0bC5jbWQgPSBYRU5f
RE9NQ1RMX3ZtY2VfbW9uaXRvcl9zdGFydDsKKyAgICBkb21jdGwuZG9tYWluID0gKGRvbWlkX3Qp
ZG9taWQ7CisKKyAgICByZXR1cm4gZG9fZG9tY3RsKHhjaCwgJmRvbWN0bCk7Cit9CisKKy8qIEVu
ZCB2bWNlIG1vbml0b3IgKi8KK2ludCB4Y19kb21haW5fdm1jZV9tb25pdG9yX2VuZCh4Y19pbnRl
cmZhY2UgKnhjaCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJfdCBkb21p
ZCkKK3sKKyAgICBERUNMQVJFX0RPTUNUTDsKKworICAgIGRvbWN0bC5jbWQgPSBYRU5fRE9NQ1RM
X3ZtY2VfbW9uaXRvcl9lbmQ7CisgICAgZG9tY3RsLmRvbWFpbiA9IChkb21pZF90KWRvbWlkOwor
CisgICAgcmV0dXJuIGRvX2RvbWN0bCh4Y2gsICZkb21jdGwpOworfQorCiAvKiBnZXQgaW5mbyBm
cm9tIGh2bSBndWVzdCBmb3Igc2F2ZSAqLwogaW50IHhjX2RvbWFpbl9odm1fZ2V0Y29udGV4dCh4
Y19pbnRlcmZhY2UgKnhjaCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3Qg
ZG9taWQsCmRpZmYgLXIgZTI3YTZkNTNhYzE1IHRvb2xzL2xpYnhjL3hjX2RvbWFpbl9zYXZlLmMK
LS0tIGEvdG9vbHMvbGlieGMveGNfZG9tYWluX3NhdmUuYwlUaHUgT2N0IDExIDAxOjUyOjMzIDIw
MTIgKzA4MDAKKysrIGIvdG9vbHMvbGlieGMveGNfZG9tYWluX3NhdmUuYwlNb24gT2N0IDIyIDIx
OjQzOjM0IDIwMTIgKzA4MDAKQEAgLTg5NSw2ICs4OTUsOCBAQAogICAgICAqLwogICAgIGludCBj
b21wcmVzc2luZyA9IDA7CiAKKyAgICBpbnQgdm1jZV93aGlsZV9tb25pdG9yID0gMDsKKwogICAg
IGludCBjb21wbGV0ZWQgPSAwOwogCiAgICAgaWYgKCBodm0gJiYgIWNhbGxiYWNrcy0+c3dpdGNo
X3FlbXVfbG9nZGlydHkgKQpAQCAtMTEwOSw2ICsxMTExLDEyIEBACiAgICAgICAgIGdvdG8gb3V0
OwogICAgIH0KIAorICAgIGlmICggeGNfZG9tYWluX3ZtY2VfbW9uaXRvcl9zdGFydCh4Y2gsIGRv
bSkgKQorICAgIHsKKyAgICAgICAgUEVSUk9SKCJFcnJvciBzdGFydGluZyB2bWNlIG1vbml0b3Ii
KTsKKyAgICAgICAgZ290byBvdXQ7CisgICAgfQorCiAgIGNvcHlwYWdlczoKICNkZWZpbmUgd3Jl
eGFjdChmZCwgYnVmLCBsZW4pIHdyaXRlX2J1ZmZlcih4Y2gsIGxhc3RfaXRlciwgb2IsIChmZCks
IChidWYpLCAobGVuKSkKICNkZWZpbmUgd3J1bmNhY2hlZChmZCwgbGl2ZSwgYnVmLCBsZW4pIHdy
aXRlX3VuY2FjaGVkKHhjaCwgbGFzdF9pdGVyLCBvYiwgKGZkKSwgKGJ1ZiksIChsZW4pKQpAQCAt
MTU3MSw2ICsxNTc5LDE4IEBACiAKICAgICBEUFJJTlRGKCJBbGwgbWVtb3J5IGlzIHNhdmVkXG4i
KTsKIAorICAgIHZtY2Vfd2hpbGVfbW9uaXRvciA9IHhjX2RvbWFpbl92bWNlX21vbml0b3JfZW5k
KHhjaCwgZG9tKTsKKyAgICBpZiAoIHZtY2Vfd2hpbGVfbW9uaXRvciA8IDAgKQorICAgIHsKKyAg
ICAgICAgUEVSUk9SKCJFcnJvciBlbmRpbmcgdm1jZSBtb25pdG9yIik7CisgICAgICAgIGdvdG8g
b3V0OworICAgIH0KKyAgICBlbHNlIGlmICggdm1jZV93aGlsZV9tb25pdG9yID4gMCApCisgICAg
eworICAgICAgICBFUlJPUigidk1DRSBvY2N1cnJlZCwgYWJvcnQgdGhpcyB0aW1lLiBVc2VyIGNh
biByZXRyeSBsYXRlci4iKTsKKyAgICAgICAgZ290byBvdXQ7CisgICAgfQorCiAgICAgLyogQWZ0
ZXIgbGFzdF9pdGVyLCBidWZmZXIgdGhlIHJlc3Qgb2YgcGFnZWJ1ZiAmIHRhaWxidWYgZGF0YSBp
bnRvIGEKICAgICAgKiBzZXBhcmF0ZSBvdXRwdXQgYnVmZmVyIGFuZCBmbHVzaCBpdCBhZnRlciB0
aGUgY29tcHJlc3NlZCBwYWdlIGNodW5rcy4KICAgICAgKi8KZGlmZiAtciBlMjdhNmQ1M2FjMTUg
dG9vbHMvbGlieGMveGVuY3RybC5oCi0tLSBhL3Rvb2xzL2xpYnhjL3hlbmN0cmwuaAlUaHUgT2N0
IDExIDAxOjUyOjMzIDIwMTIgKzA4MDAKKysrIGIvdG9vbHMvbGlieGMveGVuY3RybC5oCU1vbiBP
Y3QgMjIgMjE6NDM6MzQgMjAxMiArMDgwMApAQCAtNTc1LDYgKzU3NSwyNiBAQAogICAgICAgICAg
ICAgICAgICAgICAgICAgICB4Y19kb21haW5pbmZvX3QgKmluZm8pOwogCiAvKioKKyAqIFRoaXMg
ZnVuY3Rpb24gc3RhcnQgbW9uaXRvciB2bWNlIGV2ZW50LgorICogQHBhcm0geGNoIGEgaGFuZGxl
IHRvIGFuIG9wZW4gaHlwZXJ2aXNvciBpbnRlcmZhY2UKKyAqIEBwYXJtIGRvbWlkIHRoZSBkb21h
aW4gaWQgbW9uaXRvcmVkCisgKiBAcmV0dXJuIDwwIG9uIGZhaWx1cmUsIDAgb24gc3VjY2Vzcwor
ICovCitpbnQgeGNfZG9tYWluX3ZtY2VfbW9uaXRvcl9zdGFydCh4Y19pbnRlcmZhY2UgKnhjaCwK
KyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IGRvbWlkKTsKKworLyoq
CisgKiBUaGlzIGZ1bmN0aW9uIGVuZCBtb25pdG9yIHZtY2UgZXZlbnQKKyAqIEBwYXJtIHhjaCBh
IGhhbmRsZSB0byBhbiBvcGVuIGh5cGVydmlzb3IgaW50ZXJmYWNlCisgKiBAcGFybSBkb21pZCB0
aGUgZG9tYWluIGlkIG1vbml0b3JlZAorICogQHJldHVybiA8IDAgb24gZmFpbHVyZSwgPj0gMCBv
biBzdWNjZXNzIHdoaWxlCisgKiAgID0gMCBvbiBubyB2bWNlIG9jY3VycmVkCisgKiAgID4gMCBv
biB2bWNlIG9jY3VycmVkCisgKi8KK2ludCB4Y19kb21haW5fdm1jZV9tb25pdG9yX2VuZCh4Y19p
bnRlcmZhY2UgKnhjaCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJfdCBk
b21pZCk7CisKKy8qKgogICogVGhpcyBmdW5jdGlvbiByZXR1cm5zIGluZm9ybWF0aW9uIGFib3V0
IHRoZSBjb250ZXh0IG9mIGEgaHZtIGRvbWFpbgogICogQHBhcm0geGNoIGEgaGFuZGxlIHRvIGFu
IG9wZW4gaHlwZXJ2aXNvciBpbnRlcmZhY2UKICAqIEBwYXJtIGRvbWlkIHRoZSBkb21haW4gdG8g
Z2V0IGluZm9ybWF0aW9uIGZyb20KZGlmZiAtciBlMjdhNmQ1M2FjMTUgeGVuL2FyY2gveDg2L2Nw
dS9tY2hlY2svbWNlX2ludGVsLmMKLS0tIGEveGVuL2FyY2gveDg2L2NwdS9tY2hlY2svbWNlX2lu
dGVsLmMJVGh1IE9jdCAxMSAwMTo1MjozMyAyMDEyICswODAwCisrKyBiL3hlbi9hcmNoL3g4Ni9j
cHUvbWNoZWNrL21jZV9pbnRlbC5jCU1vbiBPY3QgMjIgMjE6NDM6MzQgMjAxMiArMDgwMApAQCAt
MzU5LDYgKzM1OSwxMiBAQAogICAgICAgICAgICAgICAgICAgICBnb3RvIHZtY2VfZmFpbGVkOwog
ICAgICAgICAgICAgICAgIH0KIAorICAgICAgICAgICAgICAgIGlmICggdW5saWtlbHkoZC0+YXJj
aC52bWNlX21vbml0b3IpICkKKyAgICAgICAgICAgICAgICB7CisgICAgICAgICAgICAgICAgICAg
IC8qIHZNQ0Ugb2NjdXIgd2hlbiBndWVzdCBtaWdyYXRpb24gKi8KKyAgICAgICAgICAgICAgICAg
ICAgZC0+YXJjaC52bWNlX21vbml0b3IgPSAxOworICAgICAgICAgICAgICAgIH0KKwogICAgICAg
ICAgICAgICAgIC8qIFdlIHdpbGwgaW5qZWN0IHZNQ0UgdG8gRE9NVSovCiAgICAgICAgICAgICAg
ICAgaWYgKCBpbmplY3Rfdm1jZShkLCBWTUNFX0lOSkVDVF9CUk9BRENBU1QpIDwgMCApCiAgICAg
ICAgICAgICAgICAgewpkaWZmIC1yIGUyN2E2ZDUzYWMxNSB4ZW4vYXJjaC94ODYvZG9tY3RsLmMK
LS0tIGEveGVuL2FyY2gveDg2L2RvbWN0bC5jCVRodSBPY3QgMTEgMDE6NTI6MzMgMjAxMiArMDgw
MAorKysgYi94ZW4vYXJjaC94ODYvZG9tY3RsLmMJTW9uIE9jdCAyMiAyMTo0MzozNCAyMDEyICsw
ODAwCkBAIC0xNTY4LDYgKzE1NjgsNDcgQEAKICAgICB9CiAgICAgYnJlYWs7CiAKKyAgICBjYXNl
IFhFTl9ET01DVExfdm1jZV9tb25pdG9yX3N0YXJ0OgorICAgIHsKKyAgICAgICAgc3RydWN0IGRv
bWFpbiAqZDsKKworICAgICAgICBkID0gcmN1X2xvY2tfZG9tYWluX2J5X2lkKGRvbWN0bC0+ZG9t
YWluKTsKKyAgICAgICAgaWYgKCBkICE9IE5VTEwgKQorICAgICAgICB7CisgICAgICAgICAgICBp
ZiAoIGQtPmFyY2gudm1jZV9tb25pdG9yICkKKyAgICAgICAgICAgICAgICByZXQgPSAtRUJVU1k7
CisgICAgICAgICAgICBlbHNlCisgICAgICAgICAgICAgICAgZC0+YXJjaC52bWNlX21vbml0b3Ig
PSAtMTsKKworICAgICAgICAgICAgcmN1X3VubG9ja19kb21haW4oZCk7CisgICAgICAgIH0KKyAg
ICAgICAgZWxzZQorICAgICAgICAgICAgcmV0ID0gLUVTUkNIOworICAgIH0KKyAgICBicmVhazsK
KworICAgIGNhc2UgWEVOX0RPTUNUTF92bWNlX21vbml0b3JfZW5kOgorICAgIHsKKyAgICAgICAg
c3RydWN0IGRvbWFpbiAqZDsKKworICAgICAgICBkID0gcmN1X2xvY2tfZG9tYWluX2J5X2lkKGRv
bWN0bC0+ZG9tYWluKTsKKyAgICAgICAgaWYgKCBkICE9IE5VTEwpCisgICAgICAgIHsKKyAgICAg
ICAgICAgIGlmICggIWQtPmFyY2gudm1jZV9tb25pdG9yICkKKyAgICAgICAgICAgICAgICByZXQg
PSAtRUlOVkFMOworICAgICAgICAgICAgZWxzZQorICAgICAgICAgICAgeworICAgICAgICAgICAg
ICAgIHJldCA9IGQtPmFyY2gudm1jZV9tb25pdG9yID4gMCA/IDEgOiAwOworICAgICAgICAgICAg
ICAgIGQtPmFyY2gudm1jZV9tb25pdG9yID0gMDsKKyAgICAgICAgICAgIH0KKworICAgICAgICAg
ICAgcmN1X3VubG9ja19kb21haW4oZCk7CisgICAgICAgIH0KKyAgICAgICAgZWxzZQorICAgICAg
ICAgICAgcmV0ID0gLUVTUkNIOworICAgIH0KKyAgICBicmVhazsKKwogICAgIGRlZmF1bHQ6CiAg
ICAgICAgIHJldCA9IGlvbW11X2RvX2RvbWN0bChkb21jdGwsIHVfZG9tY3RsKTsKICAgICAgICAg
YnJlYWs7CmRpZmYgLXIgZTI3YTZkNTNhYzE1IHhlbi9pbmNsdWRlL2FzbS14ODYvZG9tYWluLmgK
LS0tIGEveGVuL2luY2x1ZGUvYXNtLXg4Ni9kb21haW4uaAlUaHUgT2N0IDExIDAxOjUyOjMzIDIw
MTIgKzA4MDAKKysrIGIveGVuL2luY2x1ZGUvYXNtLXg4Ni9kb21haW4uaAlNb24gT2N0IDIyIDIx
OjQzOjM0IDIwMTIgKzA4MDAKQEAgLTI3OSw2ICsyNzksMTEgQEAKICAgICBib29sX3QgaGFzXzMy
Yml0X3NoaW5mbzsKICAgICAvKiBEb21haW4gY2Fubm90IGhhbmRsZSBzcHVyaW91cyBwYWdlIGZh
dWx0cz8gKi8KICAgICBib29sX3Qgc3VwcHJlc3Nfc3B1cmlvdXNfcGFnZV9mYXVsdHM7CisgICAg
LyogTW9uaXRvcmluZyBndWVzdCBtZW1vcnkgY29weSBvZiBtaWdyYXRpb24KKyAgICAgKiA9IDAg
LSBub3QgbW9uaXRvcmluZworICAgICAqIDwgMCAtIG1vbml0b3JpbmcKKyAgICAgKiA+IDAgLSB2
TUNFIG9jY3VycmVkIHdoaWxlIG1vbml0b3JpbmcgKi8KKyAgICBzOCB2bWNlX21vbml0b3I7CiAK
ICAgICAvKiBDb250aW51YWJsZSBkb21haW5fcmVsaW5xdWlzaF9yZXNvdXJjZXMoKS4gKi8KICAg
ICBlbnVtIHsKZGlmZiAtciBlMjdhNmQ1M2FjMTUgeGVuL2luY2x1ZGUvcHVibGljL2RvbWN0bC5o
Ci0tLSBhL3hlbi9pbmNsdWRlL3B1YmxpYy9kb21jdGwuaAlUaHUgT2N0IDExIDAxOjUyOjMzIDIw
MTIgKzA4MDAKKysrIGIveGVuL2luY2x1ZGUvcHVibGljL2RvbWN0bC5oCU1vbiBPY3QgMjIgMjE6
NDM6MzQgMjAxMiArMDgwMApAQCAtOTAwLDYgKzkwMCw4IEBACiAjZGVmaW5lIFhFTl9ET01DVExf
c2V0X2FjY2Vzc19yZXF1aXJlZCAgICAgICAgICAgNjQKICNkZWZpbmUgWEVOX0RPTUNUTF9hdWRp
dF9wMm0gICAgICAgICAgICAgICAgICAgICA2NQogI2RlZmluZSBYRU5fRE9NQ1RMX3NldF92aXJx
X2hhbmRsZXIgICAgICAgICAgICAgIDY2CisjZGVmaW5lIFhFTl9ET01DVExfdm1jZV9tb25pdG9y
X3N0YXJ0ICAgICAgICAgICAgNjcKKyNkZWZpbmUgWEVOX0RPTUNUTF92bWNlX21vbml0b3JfZW5k
ICAgICAgICAgICAgICA2OAogI2RlZmluZSBYRU5fRE9NQ1RMX2dkYnN4X2d1ZXN0bWVtaW8gICAg
ICAgICAgICAxMDAwCiAjZGVmaW5lIFhFTl9ET01DVExfZ2Ric3hfcGF1c2V2Y3B1ICAgICAgICAg
ICAgIDEwMDEKICNkZWZpbmUgWEVOX0RPTUNUTF9nZGJzeF91bnBhdXNldmNwdSAgICAgICAgICAg
MTAwMgo=

--_002_DE8DF0795D48FD4CA783C40EC8292335361F91SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC8292335361F91SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Mon Oct 22 11:33:40 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 11:33:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQGFt-0006pa-4F; Mon, 22 Oct 2012 11:33:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQGFr-0006pV-MP
	for xen-devel@lists.xensource.com; Mon, 22 Oct 2012 11:33:12 +0000
Received: from [85.158.143.35:11006] by server-2.bemta-4.messagelabs.com id
	86/63-22268-7FE25805; Mon, 22 Oct 2012 11:33:11 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1350905588!4218782!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjIxNjkw\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2068 invoked from network); 22 Oct 2012 11:33:09 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-5.tower-21.messagelabs.com with SMTP;
	22 Oct 2012 11:33:09 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 22 Oct 2012 04:32:33 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,629,1344236400"; d="scan'208";a="207430110"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by azsmga001.ch.intel.com with ESMTP; 22 Oct 2012 04:32:32 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 22 Oct 2012 04:32:32 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.123]) with mapi id
	14.01.0355.002; Mon, 22 Oct 2012 19:32:30 +0800
From: "Liu, Jinsong" 
To: Ian Jackson 
Thread-Topic: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration when
	vMCE	occur
Thread-Index: AQHNrglhufJylTqUQruxPOzNlQzaHZfA6fPQgARKyeA=
Date: Mon, 22 Oct 2012 11:32:27 +0000
Message-ID: 
References: 
	<20609.26910.2416.305293@mariner.uk.xensource.com>
	
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC8292335361F91SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "Liu, Jinsong" ,
	Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration
	when	vMCE	occur
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC8292335361F91SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Update patch 4/5 as attached.

Thanks,
Jinsong

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Xen/MCE: Abort live migration when vMCE occur

This patch monitor the critical area of live migration (from vMCE point of =
view,
the copypages stage of migration is the critical area while other areas are=
 not).

If a vMCE occur at the critical area of live migration, there is risk that =
error
data may be copied to the target. Currently we don't have convenient way to=
 handle
this case, so for the sake of safe, we abort it. User can retry migration l=
ater (at
that time broken page would not be mapped and copied to the target).

Signed-off-by: Liu, Jinsong 

diff -r e27a6d53ac15 tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c	Thu Oct 11 01:52:33 2012 +0800
+++ b/tools/libxc/xc_domain.c	Mon Oct 22 21:43:34 2012 +0800
@@ -283,6 +283,30 @@
     return ret;
 }
=20
+/* Start vmce monitor */
+int xc_domain_vmce_monitor_start(xc_interface *xch,
+                                 uint32_t domid)
+{
+    DECLARE_DOMCTL;
+
+    domctl.cmd =3D XEN_DOMCTL_vmce_monitor_start;
+    domctl.domain =3D (domid_t)domid;
+
+    return do_domctl(xch, &domctl);
+}
+
+/* End vmce monitor */
+int xc_domain_vmce_monitor_end(xc_interface *xch,
+                               uint32_t domid)
+{
+    DECLARE_DOMCTL;
+
+    domctl.cmd =3D XEN_DOMCTL_vmce_monitor_end;
+    domctl.domain =3D (domid_t)domid;
+
+    return do_domctl(xch, &domctl);
+}
+
 /* get info from hvm guest for save */
 int xc_domain_hvm_getcontext(xc_interface *xch,
                              uint32_t domid,
diff -r e27a6d53ac15 tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Thu Oct 11 01:52:33 2012 +0800
+++ b/tools/libxc/xc_domain_save.c	Mon Oct 22 21:43:34 2012 +0800
@@ -895,6 +895,8 @@
      */
     int compressing =3D 0;
=20
+    int vmce_while_monitor =3D 0;
+
     int completed =3D 0;
=20
     if ( hvm && !callbacks->switch_qemu_logdirty )
@@ -1109,6 +1111,12 @@
         goto out;
     }
=20
+    if ( xc_domain_vmce_monitor_start(xch, dom) )
+    {
+        PERROR("Error starting vmce monitor");
+        goto out;
+    }
+
   copypages:
 #define wrexact(fd, buf, len) write_buffer(xch, last_iter, ob, (fd), (buf)=
, (len))
 #define wruncached(fd, live, buf, len) write_uncached(xch, last_iter, ob, =
(fd), (buf), (len))
@@ -1571,6 +1579,18 @@
=20
     DPRINTF("All memory is saved\n");
=20
+    vmce_while_monitor =3D xc_domain_vmce_monitor_end(xch, dom);
+    if ( vmce_while_monitor < 0 )
+    {
+        PERROR("Error ending vmce monitor");
+        goto out;
+    }
+    else if ( vmce_while_monitor > 0 )
+    {
+        ERROR("vMCE occurred, abort this time. User can retry later.");
+        goto out;
+    }
+
     /* After last_iter, buffer the rest of pagebuf & tailbuf data into a
      * separate output buffer and flush it after the compressed page chunk=
s.
      */
diff -r e27a6d53ac15 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Thu Oct 11 01:52:33 2012 +0800
+++ b/tools/libxc/xenctrl.h	Mon Oct 22 21:43:34 2012 +0800
@@ -575,6 +575,26 @@
                           xc_domaininfo_t *info);
=20
 /**
+ * This function start monitor vmce event.
+ * @parm xch a handle to an open hypervisor interface
+ * @parm domid the domain id monitored
+ * @return <0 on failure, 0 on success
+ */
+int xc_domain_vmce_monitor_start(xc_interface *xch,
+                                 uint32_t domid);
+
+/**
+ * This function end monitor vmce event
+ * @parm xch a handle to an open hypervisor interface
+ * @parm domid the domain id monitored
+ * @return < 0 on failure, >=3D 0 on success while
+ *   =3D 0 on no vmce occurred
+ *   > 0 on vmce occurred
+ */
+int xc_domain_vmce_monitor_end(xc_interface *xch,
+                               uint32_t domid);
+
+/**
  * This function returns information about the context of a hvm domain
  * @parm xch a handle to an open hypervisor interface
  * @parm domid the domain to get information from
diff -r e27a6d53ac15 xen/arch/x86/cpu/mcheck/mce_intel.c
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c	Thu Oct 11 01:52:33 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c	Mon Oct 22 21:43:34 2012 +0800
@@ -359,6 +359,12 @@
                     goto vmce_failed;
                 }
=20
+                if ( unlikely(d->arch.vmce_monitor) )
+                {
+                    /* vMCE occur when guest migration */
+                    d->arch.vmce_monitor =3D 1;
+                }
+
                 /* We will inject vMCE to DOMU*/
                 if ( inject_vmce(d, VMCE_INJECT_BROADCAST) < 0 )
                 {
diff -r e27a6d53ac15 xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c	Thu Oct 11 01:52:33 2012 +0800
+++ b/xen/arch/x86/domctl.c	Mon Oct 22 21:43:34 2012 +0800
@@ -1568,6 +1568,47 @@
     }
     break;
=20
+    case XEN_DOMCTL_vmce_monitor_start:
+    {
+        struct domain *d;
+
+        d =3D rcu_lock_domain_by_id(domctl->domain);
+        if ( d !=3D NULL )
+        {
+            if ( d->arch.vmce_monitor )
+                ret =3D -EBUSY;
+            else
+                d->arch.vmce_monitor =3D -1;
+
+            rcu_unlock_domain(d);
+        }
+        else
+            ret =3D -ESRCH;
+    }
+    break;
+
+    case XEN_DOMCTL_vmce_monitor_end:
+    {
+        struct domain *d;
+
+        d =3D rcu_lock_domain_by_id(domctl->domain);
+        if ( d !=3D NULL)
+        {
+            if ( !d->arch.vmce_monitor )
+                ret =3D -EINVAL;
+            else
+            {
+                ret =3D d->arch.vmce_monitor > 0 ? 1 : 0;
+                d->arch.vmce_monitor =3D 0;
+            }
+
+            rcu_unlock_domain(d);
+        }
+        else
+            ret =3D -ESRCH;
+    }
+    break;
+
     default:
         ret =3D iommu_do_domctl(domctl, u_domctl);
         break;
diff -r e27a6d53ac15 xen/include/asm-x86/domain.h
--- a/xen/include/asm-x86/domain.h	Thu Oct 11 01:52:33 2012 +0800
+++ b/xen/include/asm-x86/domain.h	Mon Oct 22 21:43:34 2012 +0800
@@ -279,6 +279,11 @@
     bool_t has_32bit_shinfo;
     /* Domain cannot handle spurious page faults? */
     bool_t suppress_spurious_page_faults;
+    /* Monitoring guest memory copy of migration
+     * =3D 0 - not monitoring
+     * < 0 - monitoring
+     * > 0 - vMCE occurred while monitoring */
+    s8 vmce_monitor;
=20
     /* Continuable domain_relinquish_resources(). */
     enum {
diff -r e27a6d53ac15 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h	Thu Oct 11 01:52:33 2012 +0800
+++ b/xen/include/public/domctl.h	Mon Oct 22 21:43:34 2012 +0800
@@ -900,6 +900,8 @@
 #define XEN_DOMCTL_set_access_required           64
 #define XEN_DOMCTL_audit_p2m                     65
 #define XEN_DOMCTL_set_virq_handler              66
+#define XEN_DOMCTL_vmce_monitor_start            67
+#define XEN_DOMCTL_vmce_monitor_end              68
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002=

--_002_DE8DF0795D48FD4CA783C40EC8292335361F91SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="4_vmce_when_migrate.patch"
Content-Description: 4_vmce_when_migrate.patch
Content-Disposition: attachment; filename="4_vmce_when_migrate.patch";
	size=6845; creation-date="Mon, 22 Oct 2012 11:27:23 GMT";
	modification-date="Mon, 22 Oct 2012 13:43:52 GMT"
Content-Transfer-Encoding: base64

WGVuL01DRTogQWJvcnQgbGl2ZSBtaWdyYXRpb24gd2hlbiB2TUNFIG9jY3VyCgpUaGlzIHBhdGNo
IG1vbml0b3IgdGhlIGNyaXRpY2FsIGFyZWEgb2YgbGl2ZSBtaWdyYXRpb24gKGZyb20gdk1DRSBw
b2ludCBvZiB2aWV3LAp0aGUgY29weXBhZ2VzIHN0YWdlIG9mIG1pZ3JhdGlvbiBpcyB0aGUgY3Jp
dGljYWwgYXJlYSB3aGlsZSBvdGhlciBhcmVhcyBhcmUgbm90KS4KCklmIGEgdk1DRSBvY2N1ciBh
dCB0aGUgY3JpdGljYWwgYXJlYSBvZiBsaXZlIG1pZ3JhdGlvbiwgdGhlcmUgaXMgcmlzayB0aGF0
IGVycm9yCmRhdGEgbWF5IGJlIGNvcGllZCB0byB0aGUgdGFyZ2V0LiBDdXJyZW50bHkgd2UgZG9u
J3QgaGF2ZSBjb252ZW5pZW50IHdheSB0byBoYW5kbGUKdGhpcyBjYXNlLCBzbyBmb3IgdGhlIHNh
a2Ugb2Ygc2FmZSwgd2UgYWJvcnQgaXQuIFVzZXIgY2FuIHJldHJ5IG1pZ3JhdGlvbiBsYXRlciAo
YXQKdGhhdCB0aW1lIGJyb2tlbiBwYWdlIHdvdWxkIG5vdCBiZSBtYXBwZWQgYW5kIGNvcGllZCB0
byB0aGUgdGFyZ2V0KS4KClNpZ25lZC1vZmYtYnk6IExpdSwgSmluc29uZyA8amluc29uZy5saXVA
aW50ZWwuY29tPgoKZGlmZiAtciBlMjdhNmQ1M2FjMTUgdG9vbHMvbGlieGMveGNfZG9tYWluLmMK
LS0tIGEvdG9vbHMvbGlieGMveGNfZG9tYWluLmMJVGh1IE9jdCAxMSAwMTo1MjozMyAyMDEyICsw
ODAwCisrKyBiL3Rvb2xzL2xpYnhjL3hjX2RvbWFpbi5jCU1vbiBPY3QgMjIgMjE6NDM6MzQgMjAx
MiArMDgwMApAQCAtMjgzLDYgKzI4MywzMCBAQAogICAgIHJldHVybiByZXQ7CiB9CiAKKy8qIFN0
YXJ0IHZtY2UgbW9uaXRvciAqLworaW50IHhjX2RvbWFpbl92bWNlX21vbml0b3Jfc3RhcnQoeGNf
aW50ZXJmYWNlICp4Y2gsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJf
dCBkb21pZCkKK3sKKyAgICBERUNMQVJFX0RPTUNUTDsKKworICAgIGRvbWN0bC5jbWQgPSBYRU5f
RE9NQ1RMX3ZtY2VfbW9uaXRvcl9zdGFydDsKKyAgICBkb21jdGwuZG9tYWluID0gKGRvbWlkX3Qp
ZG9taWQ7CisKKyAgICByZXR1cm4gZG9fZG9tY3RsKHhjaCwgJmRvbWN0bCk7Cit9CisKKy8qIEVu
ZCB2bWNlIG1vbml0b3IgKi8KK2ludCB4Y19kb21haW5fdm1jZV9tb25pdG9yX2VuZCh4Y19pbnRl
cmZhY2UgKnhjaCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJfdCBkb21p
ZCkKK3sKKyAgICBERUNMQVJFX0RPTUNUTDsKKworICAgIGRvbWN0bC5jbWQgPSBYRU5fRE9NQ1RM
X3ZtY2VfbW9uaXRvcl9lbmQ7CisgICAgZG9tY3RsLmRvbWFpbiA9IChkb21pZF90KWRvbWlkOwor
CisgICAgcmV0dXJuIGRvX2RvbWN0bCh4Y2gsICZkb21jdGwpOworfQorCiAvKiBnZXQgaW5mbyBm
cm9tIGh2bSBndWVzdCBmb3Igc2F2ZSAqLwogaW50IHhjX2RvbWFpbl9odm1fZ2V0Y29udGV4dCh4
Y19pbnRlcmZhY2UgKnhjaCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3Qg
ZG9taWQsCmRpZmYgLXIgZTI3YTZkNTNhYzE1IHRvb2xzL2xpYnhjL3hjX2RvbWFpbl9zYXZlLmMK
LS0tIGEvdG9vbHMvbGlieGMveGNfZG9tYWluX3NhdmUuYwlUaHUgT2N0IDExIDAxOjUyOjMzIDIw
MTIgKzA4MDAKKysrIGIvdG9vbHMvbGlieGMveGNfZG9tYWluX3NhdmUuYwlNb24gT2N0IDIyIDIx
OjQzOjM0IDIwMTIgKzA4MDAKQEAgLTg5NSw2ICs4OTUsOCBAQAogICAgICAqLwogICAgIGludCBj
b21wcmVzc2luZyA9IDA7CiAKKyAgICBpbnQgdm1jZV93aGlsZV9tb25pdG9yID0gMDsKKwogICAg
IGludCBjb21wbGV0ZWQgPSAwOwogCiAgICAgaWYgKCBodm0gJiYgIWNhbGxiYWNrcy0+c3dpdGNo
X3FlbXVfbG9nZGlydHkgKQpAQCAtMTEwOSw2ICsxMTExLDEyIEBACiAgICAgICAgIGdvdG8gb3V0
OwogICAgIH0KIAorICAgIGlmICggeGNfZG9tYWluX3ZtY2VfbW9uaXRvcl9zdGFydCh4Y2gsIGRv
bSkgKQorICAgIHsKKyAgICAgICAgUEVSUk9SKCJFcnJvciBzdGFydGluZyB2bWNlIG1vbml0b3Ii
KTsKKyAgICAgICAgZ290byBvdXQ7CisgICAgfQorCiAgIGNvcHlwYWdlczoKICNkZWZpbmUgd3Jl
eGFjdChmZCwgYnVmLCBsZW4pIHdyaXRlX2J1ZmZlcih4Y2gsIGxhc3RfaXRlciwgb2IsIChmZCks
IChidWYpLCAobGVuKSkKICNkZWZpbmUgd3J1bmNhY2hlZChmZCwgbGl2ZSwgYnVmLCBsZW4pIHdy
aXRlX3VuY2FjaGVkKHhjaCwgbGFzdF9pdGVyLCBvYiwgKGZkKSwgKGJ1ZiksIChsZW4pKQpAQCAt
MTU3MSw2ICsxNTc5LDE4IEBACiAKICAgICBEUFJJTlRGKCJBbGwgbWVtb3J5IGlzIHNhdmVkXG4i
KTsKIAorICAgIHZtY2Vfd2hpbGVfbW9uaXRvciA9IHhjX2RvbWFpbl92bWNlX21vbml0b3JfZW5k
KHhjaCwgZG9tKTsKKyAgICBpZiAoIHZtY2Vfd2hpbGVfbW9uaXRvciA8IDAgKQorICAgIHsKKyAg
ICAgICAgUEVSUk9SKCJFcnJvciBlbmRpbmcgdm1jZSBtb25pdG9yIik7CisgICAgICAgIGdvdG8g
b3V0OworICAgIH0KKyAgICBlbHNlIGlmICggdm1jZV93aGlsZV9tb25pdG9yID4gMCApCisgICAg
eworICAgICAgICBFUlJPUigidk1DRSBvY2N1cnJlZCwgYWJvcnQgdGhpcyB0aW1lLiBVc2VyIGNh
biByZXRyeSBsYXRlci4iKTsKKyAgICAgICAgZ290byBvdXQ7CisgICAgfQorCiAgICAgLyogQWZ0
ZXIgbGFzdF9pdGVyLCBidWZmZXIgdGhlIHJlc3Qgb2YgcGFnZWJ1ZiAmIHRhaWxidWYgZGF0YSBp
bnRvIGEKICAgICAgKiBzZXBhcmF0ZSBvdXRwdXQgYnVmZmVyIGFuZCBmbHVzaCBpdCBhZnRlciB0
aGUgY29tcHJlc3NlZCBwYWdlIGNodW5rcy4KICAgICAgKi8KZGlmZiAtciBlMjdhNmQ1M2FjMTUg
dG9vbHMvbGlieGMveGVuY3RybC5oCi0tLSBhL3Rvb2xzL2xpYnhjL3hlbmN0cmwuaAlUaHUgT2N0
IDExIDAxOjUyOjMzIDIwMTIgKzA4MDAKKysrIGIvdG9vbHMvbGlieGMveGVuY3RybC5oCU1vbiBP
Y3QgMjIgMjE6NDM6MzQgMjAxMiArMDgwMApAQCAtNTc1LDYgKzU3NSwyNiBAQAogICAgICAgICAg
ICAgICAgICAgICAgICAgICB4Y19kb21haW5pbmZvX3QgKmluZm8pOwogCiAvKioKKyAqIFRoaXMg
ZnVuY3Rpb24gc3RhcnQgbW9uaXRvciB2bWNlIGV2ZW50LgorICogQHBhcm0geGNoIGEgaGFuZGxl
IHRvIGFuIG9wZW4gaHlwZXJ2aXNvciBpbnRlcmZhY2UKKyAqIEBwYXJtIGRvbWlkIHRoZSBkb21h
aW4gaWQgbW9uaXRvcmVkCisgKiBAcmV0dXJuIDwwIG9uIGZhaWx1cmUsIDAgb24gc3VjY2Vzcwor
ICovCitpbnQgeGNfZG9tYWluX3ZtY2VfbW9uaXRvcl9zdGFydCh4Y19pbnRlcmZhY2UgKnhjaCwK
KyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IGRvbWlkKTsKKworLyoq
CisgKiBUaGlzIGZ1bmN0aW9uIGVuZCBtb25pdG9yIHZtY2UgZXZlbnQKKyAqIEBwYXJtIHhjaCBh
IGhhbmRsZSB0byBhbiBvcGVuIGh5cGVydmlzb3IgaW50ZXJmYWNlCisgKiBAcGFybSBkb21pZCB0
aGUgZG9tYWluIGlkIG1vbml0b3JlZAorICogQHJldHVybiA8IDAgb24gZmFpbHVyZSwgPj0gMCBv
biBzdWNjZXNzIHdoaWxlCisgKiAgID0gMCBvbiBubyB2bWNlIG9jY3VycmVkCisgKiAgID4gMCBv
biB2bWNlIG9jY3VycmVkCisgKi8KK2ludCB4Y19kb21haW5fdm1jZV9tb25pdG9yX2VuZCh4Y19p
bnRlcmZhY2UgKnhjaCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJfdCBk
b21pZCk7CisKKy8qKgogICogVGhpcyBmdW5jdGlvbiByZXR1cm5zIGluZm9ybWF0aW9uIGFib3V0
IHRoZSBjb250ZXh0IG9mIGEgaHZtIGRvbWFpbgogICogQHBhcm0geGNoIGEgaGFuZGxlIHRvIGFu
IG9wZW4gaHlwZXJ2aXNvciBpbnRlcmZhY2UKICAqIEBwYXJtIGRvbWlkIHRoZSBkb21haW4gdG8g
Z2V0IGluZm9ybWF0aW9uIGZyb20KZGlmZiAtciBlMjdhNmQ1M2FjMTUgeGVuL2FyY2gveDg2L2Nw
dS9tY2hlY2svbWNlX2ludGVsLmMKLS0tIGEveGVuL2FyY2gveDg2L2NwdS9tY2hlY2svbWNlX2lu
dGVsLmMJVGh1IE9jdCAxMSAwMTo1MjozMyAyMDEyICswODAwCisrKyBiL3hlbi9hcmNoL3g4Ni9j
cHUvbWNoZWNrL21jZV9pbnRlbC5jCU1vbiBPY3QgMjIgMjE6NDM6MzQgMjAxMiArMDgwMApAQCAt
MzU5LDYgKzM1OSwxMiBAQAogICAgICAgICAgICAgICAgICAgICBnb3RvIHZtY2VfZmFpbGVkOwog
ICAgICAgICAgICAgICAgIH0KIAorICAgICAgICAgICAgICAgIGlmICggdW5saWtlbHkoZC0+YXJj
aC52bWNlX21vbml0b3IpICkKKyAgICAgICAgICAgICAgICB7CisgICAgICAgICAgICAgICAgICAg
IC8qIHZNQ0Ugb2NjdXIgd2hlbiBndWVzdCBtaWdyYXRpb24gKi8KKyAgICAgICAgICAgICAgICAg
ICAgZC0+YXJjaC52bWNlX21vbml0b3IgPSAxOworICAgICAgICAgICAgICAgIH0KKwogICAgICAg
ICAgICAgICAgIC8qIFdlIHdpbGwgaW5qZWN0IHZNQ0UgdG8gRE9NVSovCiAgICAgICAgICAgICAg
ICAgaWYgKCBpbmplY3Rfdm1jZShkLCBWTUNFX0lOSkVDVF9CUk9BRENBU1QpIDwgMCApCiAgICAg
ICAgICAgICAgICAgewpkaWZmIC1yIGUyN2E2ZDUzYWMxNSB4ZW4vYXJjaC94ODYvZG9tY3RsLmMK
LS0tIGEveGVuL2FyY2gveDg2L2RvbWN0bC5jCVRodSBPY3QgMTEgMDE6NTI6MzMgMjAxMiArMDgw
MAorKysgYi94ZW4vYXJjaC94ODYvZG9tY3RsLmMJTW9uIE9jdCAyMiAyMTo0MzozNCAyMDEyICsw
ODAwCkBAIC0xNTY4LDYgKzE1NjgsNDcgQEAKICAgICB9CiAgICAgYnJlYWs7CiAKKyAgICBjYXNl
IFhFTl9ET01DVExfdm1jZV9tb25pdG9yX3N0YXJ0OgorICAgIHsKKyAgICAgICAgc3RydWN0IGRv
bWFpbiAqZDsKKworICAgICAgICBkID0gcmN1X2xvY2tfZG9tYWluX2J5X2lkKGRvbWN0bC0+ZG9t
YWluKTsKKyAgICAgICAgaWYgKCBkICE9IE5VTEwgKQorICAgICAgICB7CisgICAgICAgICAgICBp
ZiAoIGQtPmFyY2gudm1jZV9tb25pdG9yICkKKyAgICAgICAgICAgICAgICByZXQgPSAtRUJVU1k7
CisgICAgICAgICAgICBlbHNlCisgICAgICAgICAgICAgICAgZC0+YXJjaC52bWNlX21vbml0b3Ig
PSAtMTsKKworICAgICAgICAgICAgcmN1X3VubG9ja19kb21haW4oZCk7CisgICAgICAgIH0KKyAg
ICAgICAgZWxzZQorICAgICAgICAgICAgcmV0ID0gLUVTUkNIOworICAgIH0KKyAgICBicmVhazsK
KworICAgIGNhc2UgWEVOX0RPTUNUTF92bWNlX21vbml0b3JfZW5kOgorICAgIHsKKyAgICAgICAg
c3RydWN0IGRvbWFpbiAqZDsKKworICAgICAgICBkID0gcmN1X2xvY2tfZG9tYWluX2J5X2lkKGRv
bWN0bC0+ZG9tYWluKTsKKyAgICAgICAgaWYgKCBkICE9IE5VTEwpCisgICAgICAgIHsKKyAgICAg
ICAgICAgIGlmICggIWQtPmFyY2gudm1jZV9tb25pdG9yICkKKyAgICAgICAgICAgICAgICByZXQg
PSAtRUlOVkFMOworICAgICAgICAgICAgZWxzZQorICAgICAgICAgICAgeworICAgICAgICAgICAg
ICAgIHJldCA9IGQtPmFyY2gudm1jZV9tb25pdG9yID4gMCA/IDEgOiAwOworICAgICAgICAgICAg
ICAgIGQtPmFyY2gudm1jZV9tb25pdG9yID0gMDsKKyAgICAgICAgICAgIH0KKworICAgICAgICAg
ICAgcmN1X3VubG9ja19kb21haW4oZCk7CisgICAgICAgIH0KKyAgICAgICAgZWxzZQorICAgICAg
ICAgICAgcmV0ID0gLUVTUkNIOworICAgIH0KKyAgICBicmVhazsKKwogICAgIGRlZmF1bHQ6CiAg
ICAgICAgIHJldCA9IGlvbW11X2RvX2RvbWN0bChkb21jdGwsIHVfZG9tY3RsKTsKICAgICAgICAg
YnJlYWs7CmRpZmYgLXIgZTI3YTZkNTNhYzE1IHhlbi9pbmNsdWRlL2FzbS14ODYvZG9tYWluLmgK
LS0tIGEveGVuL2luY2x1ZGUvYXNtLXg4Ni9kb21haW4uaAlUaHUgT2N0IDExIDAxOjUyOjMzIDIw
MTIgKzA4MDAKKysrIGIveGVuL2luY2x1ZGUvYXNtLXg4Ni9kb21haW4uaAlNb24gT2N0IDIyIDIx
OjQzOjM0IDIwMTIgKzA4MDAKQEAgLTI3OSw2ICsyNzksMTEgQEAKICAgICBib29sX3QgaGFzXzMy
Yml0X3NoaW5mbzsKICAgICAvKiBEb21haW4gY2Fubm90IGhhbmRsZSBzcHVyaW91cyBwYWdlIGZh
dWx0cz8gKi8KICAgICBib29sX3Qgc3VwcHJlc3Nfc3B1cmlvdXNfcGFnZV9mYXVsdHM7CisgICAg
LyogTW9uaXRvcmluZyBndWVzdCBtZW1vcnkgY29weSBvZiBtaWdyYXRpb24KKyAgICAgKiA9IDAg
LSBub3QgbW9uaXRvcmluZworICAgICAqIDwgMCAtIG1vbml0b3JpbmcKKyAgICAgKiA+IDAgLSB2
TUNFIG9jY3VycmVkIHdoaWxlIG1vbml0b3JpbmcgKi8KKyAgICBzOCB2bWNlX21vbml0b3I7CiAK
ICAgICAvKiBDb250aW51YWJsZSBkb21haW5fcmVsaW5xdWlzaF9yZXNvdXJjZXMoKS4gKi8KICAg
ICBlbnVtIHsKZGlmZiAtciBlMjdhNmQ1M2FjMTUgeGVuL2luY2x1ZGUvcHVibGljL2RvbWN0bC5o
Ci0tLSBhL3hlbi9pbmNsdWRlL3B1YmxpYy9kb21jdGwuaAlUaHUgT2N0IDExIDAxOjUyOjMzIDIw
MTIgKzA4MDAKKysrIGIveGVuL2luY2x1ZGUvcHVibGljL2RvbWN0bC5oCU1vbiBPY3QgMjIgMjE6
NDM6MzQgMjAxMiArMDgwMApAQCAtOTAwLDYgKzkwMCw4IEBACiAjZGVmaW5lIFhFTl9ET01DVExf
c2V0X2FjY2Vzc19yZXF1aXJlZCAgICAgICAgICAgNjQKICNkZWZpbmUgWEVOX0RPTUNUTF9hdWRp
dF9wMm0gICAgICAgICAgICAgICAgICAgICA2NQogI2RlZmluZSBYRU5fRE9NQ1RMX3NldF92aXJx
X2hhbmRsZXIgICAgICAgICAgICAgIDY2CisjZGVmaW5lIFhFTl9ET01DVExfdm1jZV9tb25pdG9y
X3N0YXJ0ICAgICAgICAgICAgNjcKKyNkZWZpbmUgWEVOX0RPTUNUTF92bWNlX21vbml0b3JfZW5k
ICAgICAgICAgICAgICA2OAogI2RlZmluZSBYRU5fRE9NQ1RMX2dkYnN4X2d1ZXN0bWVtaW8gICAg
ICAgICAgICAxMDAwCiAjZGVmaW5lIFhFTl9ET01DVExfZ2Ric3hfcGF1c2V2Y3B1ICAgICAgICAg
ICAgIDEwMDEKICNkZWZpbmUgWEVOX0RPTUNUTF9nZGJzeF91bnBhdXNldmNwdSAgICAgICAgICAg
MTAwMgo=

--_002_DE8DF0795D48FD4CA783C40EC8292335361F91SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC8292335361F91SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Mon Oct 22 11:37:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 11:37:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQGJo-0006xe-P2; Mon, 22 Oct 2012 11:37:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQGJm-0006xX-0G
	for xen-devel@lists.xensource.com; Mon, 22 Oct 2012 11:37:15 +0000
Received: from [85.158.138.51:8267] by server-5.bemta-3.messagelabs.com id
	59/8F-12440-9EF25805; Mon, 22 Oct 2012 11:37:13 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1350905831!35201313!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzgwOTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2483 invoked from network); 22 Oct 2012 11:37:12 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 11:37:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,629,1344211200"; d="scan'208";a="41995687"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Oct 2012 11:37:10 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 22 Oct 2012 07:37:10 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TQGJi-0002KN-2p;
	Mon, 22 Oct 2012 12:37:10 +0100
Message-ID: <50852EB6.4060705@eu.citrix.com>
Date: Mon, 22 Oct 2012 12:32:06 +0100
From: George Dunlap 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: "Liu, Jinsong" 
References: 
	
	
In-Reply-To: 
Cc: Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	Ian Jackson , Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration when vMCE
 occur
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 19/10/12 21:32, Liu, Jinsong wrote:
>> Wouldn't your patch 5 be sufficient to deal with this case?  It seems
>> like the broken page would get marked as such, and then get marked
>> broken on the receiving side, wouldn't it?
>>
>>   -George
> Seems no, patch 4 is to handle the case mce occur during migration --> under such case the broken page would mapped (at that time the page is a good page) and copy to target; While patch 5 is to handle the case mce occur beofre migration --> under such case the broken page would not mapped and so would not copy to target.

In the "during migration", there are actually two cases to consider:
1. The page breaks before the domain save code maps it.
2. The page breaks after the domain save code has mapped it once

Patch 5 will detect a broken page when it tries to map it, and send it 
as type "broken", without data.

So in the case of #1, it will be taken care of by patch 5 without any 
changes.

In the case of #2, it seems like we could probably modify patch 5 to 
handle it.  If we mark a page dirty, then the domain save code will try 
to send it again.  When it tries to map it, it will discover that the 
page has been marked "broken", and will send it as a "broken" page, 
without data.  As long as the domain restore code marks the 
already-received page as "broken" when it receives this message, then 
everything should work as normal.

What do you think?

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 11:37:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 11:37:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQGJo-0006xe-P2; Mon, 22 Oct 2012 11:37:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQGJm-0006xX-0G
	for xen-devel@lists.xensource.com; Mon, 22 Oct 2012 11:37:15 +0000
Received: from [85.158.138.51:8267] by server-5.bemta-3.messagelabs.com id
	59/8F-12440-9EF25805; Mon, 22 Oct 2012 11:37:13 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1350905831!35201313!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzgwOTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2483 invoked from network); 22 Oct 2012 11:37:12 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 11:37:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,629,1344211200"; d="scan'208";a="41995687"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Oct 2012 11:37:10 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 22 Oct 2012 07:37:10 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TQGJi-0002KN-2p;
	Mon, 22 Oct 2012 12:37:10 +0100
Message-ID: <50852EB6.4060705@eu.citrix.com>
Date: Mon, 22 Oct 2012 12:32:06 +0100
From: George Dunlap 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: "Liu, Jinsong" 
References: 
	
	
In-Reply-To: 
Cc: Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	Ian Jackson , Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration when vMCE
 occur
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 19/10/12 21:32, Liu, Jinsong wrote:
>> Wouldn't your patch 5 be sufficient to deal with this case?  It seems
>> like the broken page would get marked as such, and then get marked
>> broken on the receiving side, wouldn't it?
>>
>>   -George
> Seems no, patch 4 is to handle the case mce occur during migration --> under such case the broken page would mapped (at that time the page is a good page) and copy to target; While patch 5 is to handle the case mce occur beofre migration --> under such case the broken page would not mapped and so would not copy to target.

In the "during migration", there are actually two cases to consider:
1. The page breaks before the domain save code maps it.
2. The page breaks after the domain save code has mapped it once

Patch 5 will detect a broken page when it tries to map it, and send it 
as type "broken", without data.

So in the case of #1, it will be taken care of by patch 5 without any 
changes.

In the case of #2, it seems like we could probably modify patch 5 to 
handle it.  If we mark a page dirty, then the domain save code will try 
to send it again.  When it tries to map it, it will discover that the 
page has been marked "broken", and will send it as a "broken" page, 
without data.  As long as the domain restore code marks the 
already-received page as "broken" when it receives this message, then 
everything should work as normal.

What do you think?

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 12:07:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 12:07:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQGmf-0007RR-8a; Mon, 22 Oct 2012 12:07:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQGme-0007RM-Gb
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 12:07:04 +0000
Received: from [85.158.137.99:41666] by server-8.bemta-3.messagelabs.com id
	EB/91-10525-7E635805; Mon, 22 Oct 2012 12:07:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1350907623!19408060!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20555 invoked from network); 22 Oct 2012 12:07:03 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-217.messagelabs.com with SMTP;
	22 Oct 2012 12:07:03 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 22 Oct 2012 13:07:02 +0100
Message-Id: <5085530202000078000A2F12@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 22 Oct 2012 13:06:58 +0100
From: "Jan Beulich" 
To: "Mauro" 
References: 
	
	
	
	<65395f62-74e5-4910-b701-8df629c2ce3b@default>
	
	
	
	
	
	<20120930151314.GU8912@reaktio.net>
	
	
	
	<507C024602000078000A155C@nat28.tlf.novell.com>
	
	<507C226A02000078000A1657@nat28.tlf.novell.com>
	
	<508509D902000078000A2DDA@nat28.tlf.novell.com>
	
	<50852D8C02000078000A2E48@nat28.tlf.novell.com>
	
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeremy Fitzhardinge , Keir Fraser ,
	Dan Magenheimer ,
	xen-devel ,
	Olivier Hanesse ,
	Mark Adams 
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 22.10.12 at 12:40, Mauro  wrote:
> On 22 October 2012 11:27, Jan Beulich  wrote:
>>>>> On 22.10.12 at 11:17, Mauro  wrote:
>>> On 22 October 2012 08:54, Jan Beulich  wrote:
>>>>>>> On 21.10.12 at 22:52, Mauro  wrote:
>>>>> On 15 October 2012 14:49, Jan Beulich  wrote:
>>>> So what's the contents of /proc/cpuinfo (any one CPU suffices)
>>>> under a native recent kernel on that system? The most likely
>>>> issue here is that we're mis-identifying the CPU as having an
>>>> always running APIC timer (ARAT)...
>>>
>>> uname -a
>>>
>>> Linux xen-p01 2.6.32-5-xen-amd64 #1 SMP Sun Sep 23 13:49:30 UTC 2012
>>> x86_64 GNU/Linux
>>
>> I had specifically asked to do this under a _native_ kernel.
> 
> sorry for my ignorance, what does it mean native_kernel.

A kernel run with no Xen underneath it.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 12:07:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 12:07:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQGmf-0007RR-8a; Mon, 22 Oct 2012 12:07:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQGme-0007RM-Gb
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 12:07:04 +0000
Received: from [85.158.137.99:41666] by server-8.bemta-3.messagelabs.com id
	EB/91-10525-7E635805; Mon, 22 Oct 2012 12:07:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1350907623!19408060!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20555 invoked from network); 22 Oct 2012 12:07:03 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-217.messagelabs.com with SMTP;
	22 Oct 2012 12:07:03 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 22 Oct 2012 13:07:02 +0100
Message-Id: <5085530202000078000A2F12@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 22 Oct 2012 13:06:58 +0100
From: "Jan Beulich" 
To: "Mauro" 
References: 
	
	
	
	<65395f62-74e5-4910-b701-8df629c2ce3b@default>
	
	
	
	
	
	<20120930151314.GU8912@reaktio.net>
	
	
	
	<507C024602000078000A155C@nat28.tlf.novell.com>
	
	<507C226A02000078000A1657@nat28.tlf.novell.com>
	
	<508509D902000078000A2DDA@nat28.tlf.novell.com>
	
	<50852D8C02000078000A2E48@nat28.tlf.novell.com>
	
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeremy Fitzhardinge , Keir Fraser ,
	Dan Magenheimer ,
	xen-devel ,
	Olivier Hanesse ,
	Mark Adams 
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 22.10.12 at 12:40, Mauro  wrote:
> On 22 October 2012 11:27, Jan Beulich  wrote:
>>>>> On 22.10.12 at 11:17, Mauro  wrote:
>>> On 22 October 2012 08:54, Jan Beulich  wrote:
>>>>>>> On 21.10.12 at 22:52, Mauro  wrote:
>>>>> On 15 October 2012 14:49, Jan Beulich  wrote:
>>>> So what's the contents of /proc/cpuinfo (any one CPU suffices)
>>>> under a native recent kernel on that system? The most likely
>>>> issue here is that we're mis-identifying the CPU as having an
>>>> always running APIC timer (ARAT)...
>>>
>>> uname -a
>>>
>>> Linux xen-p01 2.6.32-5-xen-amd64 #1 SMP Sun Sep 23 13:49:30 UTC 2012
>>> x86_64 GNU/Linux
>>
>> I had specifically asked to do this under a _native_ kernel.
> 
> sorry for my ignorance, what does it mean native_kernel.

A kernel run with no Xen underneath it.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 13:23:33 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 13:23:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQHyI-0000SI-7e; Mon, 22 Oct 2012 13:23:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQHyH-0000S6-D0
	for xen-devel@lists.xensource.com; Mon, 22 Oct 2012 13:23:09 +0000
Received: from [85.158.143.35:29903] by server-2.bemta-4.messagelabs.com id
	C2/FA-22268-CB845805; Mon, 22 Oct 2012 13:23:08 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1350912187!13076423!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUxNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30536 invoked from network); 22 Oct 2012 13:23:08 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 13:23:08 -0000
X-IronPort-AV: E=Sophos;i="4.80,629,1344211200"; d="scan'208";a="15309801"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Oct 2012 13:23:04 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Mon, 22 Oct 2012 14:23:04 +0100
Date: Mon, 22 Oct 2012 14:22:36 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Konrad Rzeszutek Wilk 
In-Reply-To: <1350695882-12820-7-git-send-email-konrad.wilk@oracle.com>
Message-ID: 
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
	<1350695882-12820-7-git-send-email-konrad.wilk@oracle.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Stefano Stabellini ,
	Ian Campbell 
Subject: Re: [Xen-devel] [PATCH 6/6] xen/pvh: /dev/xen/privcmd changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 20 Oct 2012, Konrad Rzeszutek Wilk wrote:
> From: Mukesh Rathor 
> 
> PVH only supports the batch interface. To map a foreign page to a process,
> the PFN must be allocated and PVH path uses ballooning for that purpose.
> 
> The returned PFN is then mapped to the foreign page.
> xen_unmap_domain_mfn_range() is introduced to unmap these pages via the
> privcmd close call.
> 
> Signed-off-by: Mukesh Rathor 
> [v1: Fix up privcmd_close]
> Signed-off-by: Konrad Rzeszutek Wilk 


Acked-by: Stefano Stabellini 

>  drivers/xen/privcmd.c |   69 +++++++++++++++++++++++++++++++++++++++++++++++-
>  1 files changed, 67 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> index b612267..b9d0898 100644
> --- a/drivers/xen/privcmd.c
> +++ b/drivers/xen/privcmd.c
> @@ -33,11 +33,14 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "privcmd.h"
>  
>  MODULE_LICENSE("GPL");
>  
> +#define PRIV_VMA_LOCKED ((void *)1)
> +
>  #ifndef HAVE_ARCH_PRIVCMD_MMAP
>  static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma);
>  #endif
> @@ -199,6 +202,10 @@ static long privcmd_ioctl_mmap(void __user *udata)
>  	if (!xen_initial_domain())
>  		return -EPERM;
>  
> +	/* We only support privcmd_ioctl_mmap_batch for auto translated. */
> +	if (xen_feature(XENFEAT_auto_translated_physmap))
> +		return -ENOSYS;
> +
>  	if (copy_from_user(&mmapcmd, udata, sizeof(mmapcmd)))
>  		return -EFAULT;
>  
> @@ -246,6 +253,7 @@ struct mmap_batch_state {
>  	domid_t domain;
>  	unsigned long va;
>  	struct vm_area_struct *vma;
> +	int index;
>  	/* A tristate:
>  	 *      0 for no errors
>  	 *      1 if at least one error has happened (and no
> @@ -260,15 +268,24 @@ struct mmap_batch_state {
>  	xen_pfn_t __user *user_mfn;
>  };
>  
> +/* auto translated dom0 note: if domU being created is PV, then mfn is
> + * mfn(addr on bus). If it's auto xlated, then mfn is pfn (input to HAP).
> + */
>  static int mmap_batch_fn(void *data, void *state)
>  {
>  	xen_pfn_t *mfnp = data;
>  	struct mmap_batch_state *st = state;
> +	struct vm_area_struct *vma = st->vma;
> +	struct page **pages = vma->vm_private_data;
> +	struct page *cur_page = NULL;
>  	int ret;
>  
> +	if (xen_feature(XENFEAT_auto_translated_physmap))
> +		cur_page = pages[st->index++];
> +
>  	ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
>  					 st->vma->vm_page_prot, st->domain,
> -					 NULL);
> +					 &cur_page);
>  
>  	/* Store error code for second pass. */
>  	*(st->err++) = ret;
> @@ -304,6 +321,32 @@ static int mmap_return_errors_v1(void *data, void *state)
>  	return __put_user(*mfnp, st->user_mfn++);
>  }
>  
> +/* Allocate pfns that are then mapped with gmfns from foreign domid. Update
> + * the vma with the page info to use later.
> + * Returns: 0 if success, otherwise -errno
> + */
> +static int alloc_empty_pages(struct vm_area_struct *vma, int numpgs)
> +{
> +	int rc;
> +	struct page **pages;
> +
> +	pages = kcalloc(numpgs, sizeof(pages[0]), GFP_KERNEL);
> +	if (pages == NULL)
> +		return -ENOMEM;
> +
> +	rc = alloc_xenballooned_pages(numpgs, pages, 0);
> +	if (rc != 0) {
> +		pr_warn("%s Could not alloc %d pfns rc:%d\n", __func__,
> +			numpgs, rc);
> +		kfree(pages);
> +		return -ENOMEM;
> +	}
> +	BUG_ON(vma->vm_private_data != PRIV_VMA_LOCKED);
> +	vma->vm_private_data = pages;
> +
> +	return 0;
> +}
> +
>  static struct vm_operations_struct privcmd_vm_ops;
>  
>  static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
> @@ -371,10 +414,18 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
>  		up_write(&mm->mmap_sem);
>  		goto out;
>  	}
> +	if (xen_feature(XENFEAT_auto_translated_physmap)) {
> +		ret = alloc_empty_pages(vma, m.num);
> +		if (ret < 0) {
> +			up_write(&mm->mmap_sem);
> +			goto out;
> +		}
> +	}
>  
>  	state.domain        = m.dom;
>  	state.vma           = vma;
>  	state.va            = m.addr;
> +	state.index         = 0;
>  	state.global_error  = 0;
>  	state.err           = err_array;
>  
> @@ -439,6 +490,19 @@ static long privcmd_ioctl(struct file *file,
>  	return ret;
>  }
>  
> +static void privcmd_close(struct vm_area_struct *vma)
> +{
> +	struct page **pages = vma->vm_private_data;
> +	int numpgs = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
> +
> +	if (!xen_feature(XENFEAT_auto_translated_physmap || !numpgs || !pages))
> +		return;
> +
> +	xen_unmap_domain_mfn_range(vma, numpgs, pages);
> +	free_xenballooned_pages(numpgs, pages);
> +	kfree(pages);
> +}
> +
>  static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
>  {
>  	printk(KERN_DEBUG "privcmd_fault: vma=%p %lx-%lx, pgoff=%lx, uv=%p\n",
> @@ -449,6 +513,7 @@ static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
>  }
>  
>  static struct vm_operations_struct privcmd_vm_ops = {
> +	.close = privcmd_close,
>  	.fault = privcmd_fault
>  };
>  
> @@ -466,7 +531,7 @@ static int privcmd_mmap(struct file *file, struct vm_area_struct *vma)
>  
>  static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma)
>  {
> -	return (xchg(&vma->vm_private_data, (void *)1) == NULL);
> +	return !cmpxchg(&vma->vm_private_data, NULL, PRIV_VMA_LOCKED);
>  }
>  
>  const struct file_operations xen_privcmd_fops = {
> -- 
> 1.7.7.6
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 13:23:33 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 13:23:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQHyI-0000SI-7e; Mon, 22 Oct 2012 13:23:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQHyH-0000S6-D0
	for xen-devel@lists.xensource.com; Mon, 22 Oct 2012 13:23:09 +0000
Received: from [85.158.143.35:29903] by server-2.bemta-4.messagelabs.com id
	C2/FA-22268-CB845805; Mon, 22 Oct 2012 13:23:08 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1350912187!13076423!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUxNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30536 invoked from network); 22 Oct 2012 13:23:08 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 13:23:08 -0000
X-IronPort-AV: E=Sophos;i="4.80,629,1344211200"; d="scan'208";a="15309801"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Oct 2012 13:23:04 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Mon, 22 Oct 2012 14:23:04 +0100
Date: Mon, 22 Oct 2012 14:22:36 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Konrad Rzeszutek Wilk 
In-Reply-To: <1350695882-12820-7-git-send-email-konrad.wilk@oracle.com>
Message-ID: 
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
	<1350695882-12820-7-git-send-email-konrad.wilk@oracle.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Stefano Stabellini ,
	Ian Campbell 
Subject: Re: [Xen-devel] [PATCH 6/6] xen/pvh: /dev/xen/privcmd changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 20 Oct 2012, Konrad Rzeszutek Wilk wrote:
> From: Mukesh Rathor 
> 
> PVH only supports the batch interface. To map a foreign page to a process,
> the PFN must be allocated and PVH path uses ballooning for that purpose.
> 
> The returned PFN is then mapped to the foreign page.
> xen_unmap_domain_mfn_range() is introduced to unmap these pages via the
> privcmd close call.
> 
> Signed-off-by: Mukesh Rathor 
> [v1: Fix up privcmd_close]
> Signed-off-by: Konrad Rzeszutek Wilk 


Acked-by: Stefano Stabellini 

>  drivers/xen/privcmd.c |   69 +++++++++++++++++++++++++++++++++++++++++++++++-
>  1 files changed, 67 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> index b612267..b9d0898 100644
> --- a/drivers/xen/privcmd.c
> +++ b/drivers/xen/privcmd.c
> @@ -33,11 +33,14 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "privcmd.h"
>  
>  MODULE_LICENSE("GPL");
>  
> +#define PRIV_VMA_LOCKED ((void *)1)
> +
>  #ifndef HAVE_ARCH_PRIVCMD_MMAP
>  static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma);
>  #endif
> @@ -199,6 +202,10 @@ static long privcmd_ioctl_mmap(void __user *udata)
>  	if (!xen_initial_domain())
>  		return -EPERM;
>  
> +	/* We only support privcmd_ioctl_mmap_batch for auto translated. */
> +	if (xen_feature(XENFEAT_auto_translated_physmap))
> +		return -ENOSYS;
> +
>  	if (copy_from_user(&mmapcmd, udata, sizeof(mmapcmd)))
>  		return -EFAULT;
>  
> @@ -246,6 +253,7 @@ struct mmap_batch_state {
>  	domid_t domain;
>  	unsigned long va;
>  	struct vm_area_struct *vma;
> +	int index;
>  	/* A tristate:
>  	 *      0 for no errors
>  	 *      1 if at least one error has happened (and no
> @@ -260,15 +268,24 @@ struct mmap_batch_state {
>  	xen_pfn_t __user *user_mfn;
>  };
>  
> +/* auto translated dom0 note: if domU being created is PV, then mfn is
> + * mfn(addr on bus). If it's auto xlated, then mfn is pfn (input to HAP).
> + */
>  static int mmap_batch_fn(void *data, void *state)
>  {
>  	xen_pfn_t *mfnp = data;
>  	struct mmap_batch_state *st = state;
> +	struct vm_area_struct *vma = st->vma;
> +	struct page **pages = vma->vm_private_data;
> +	struct page *cur_page = NULL;
>  	int ret;
>  
> +	if (xen_feature(XENFEAT_auto_translated_physmap))
> +		cur_page = pages[st->index++];
> +
>  	ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
>  					 st->vma->vm_page_prot, st->domain,
> -					 NULL);
> +					 &cur_page);
>  
>  	/* Store error code for second pass. */
>  	*(st->err++) = ret;
> @@ -304,6 +321,32 @@ static int mmap_return_errors_v1(void *data, void *state)
>  	return __put_user(*mfnp, st->user_mfn++);
>  }
>  
> +/* Allocate pfns that are then mapped with gmfns from foreign domid. Update
> + * the vma with the page info to use later.
> + * Returns: 0 if success, otherwise -errno
> + */
> +static int alloc_empty_pages(struct vm_area_struct *vma, int numpgs)
> +{
> +	int rc;
> +	struct page **pages;
> +
> +	pages = kcalloc(numpgs, sizeof(pages[0]), GFP_KERNEL);
> +	if (pages == NULL)
> +		return -ENOMEM;
> +
> +	rc = alloc_xenballooned_pages(numpgs, pages, 0);
> +	if (rc != 0) {
> +		pr_warn("%s Could not alloc %d pfns rc:%d\n", __func__,
> +			numpgs, rc);
> +		kfree(pages);
> +		return -ENOMEM;
> +	}
> +	BUG_ON(vma->vm_private_data != PRIV_VMA_LOCKED);
> +	vma->vm_private_data = pages;
> +
> +	return 0;
> +}
> +
>  static struct vm_operations_struct privcmd_vm_ops;
>  
>  static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
> @@ -371,10 +414,18 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
>  		up_write(&mm->mmap_sem);
>  		goto out;
>  	}
> +	if (xen_feature(XENFEAT_auto_translated_physmap)) {
> +		ret = alloc_empty_pages(vma, m.num);
> +		if (ret < 0) {
> +			up_write(&mm->mmap_sem);
> +			goto out;
> +		}
> +	}
>  
>  	state.domain        = m.dom;
>  	state.vma           = vma;
>  	state.va            = m.addr;
> +	state.index         = 0;
>  	state.global_error  = 0;
>  	state.err           = err_array;
>  
> @@ -439,6 +490,19 @@ static long privcmd_ioctl(struct file *file,
>  	return ret;
>  }
>  
> +static void privcmd_close(struct vm_area_struct *vma)
> +{
> +	struct page **pages = vma->vm_private_data;
> +	int numpgs = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
> +
> +	if (!xen_feature(XENFEAT_auto_translated_physmap || !numpgs || !pages))
> +		return;
> +
> +	xen_unmap_domain_mfn_range(vma, numpgs, pages);
> +	free_xenballooned_pages(numpgs, pages);
> +	kfree(pages);
> +}
> +
>  static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
>  {
>  	printk(KERN_DEBUG "privcmd_fault: vma=%p %lx-%lx, pgoff=%lx, uv=%p\n",
> @@ -449,6 +513,7 @@ static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
>  }
>  
>  static struct vm_operations_struct privcmd_vm_ops = {
> +	.close = privcmd_close,
>  	.fault = privcmd_fault
>  };
>  
> @@ -466,7 +531,7 @@ static int privcmd_mmap(struct file *file, struct vm_area_struct *vma)
>  
>  static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma)
>  {
> -	return (xchg(&vma->vm_private_data, (void *)1) == NULL);
> +	return !cmpxchg(&vma->vm_private_data, NULL, PRIV_VMA_LOCKED);
>  }
>  
>  const struct file_operations xen_privcmd_fops = {
> -- 
> 1.7.7.6
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 13:26:46 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 13:26:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQI1O-0000lP-Qw; Mon, 22 Oct 2012 13:26:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQI1N-0000l8-C8
	for xen-devel@lists.xensource.com; Mon, 22 Oct 2012 13:26:21 +0000
Received: from [193.109.254.147:40006] by server-12.bemta-14.messagelabs.com
	id D0/8E-13558-C7945805; Mon, 22 Oct 2012 13:26:20 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1350912371!10866961!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUxNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5642 invoked from network); 22 Oct 2012 13:26:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 13:26:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,629,1344211200"; d="scan'208";a="15309956"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Oct 2012 13:26:11 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Mon, 22 Oct 2012 14:26:11 +0100
Date: Mon, 22 Oct 2012 14:25:43 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Konrad Rzeszutek Wilk 
In-Reply-To: <1350695882-12820-6-git-send-email-konrad.wilk@oracle.com>
Message-ID: 
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
	<1350695882-12820-6-git-send-email-konrad.wilk@oracle.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Stefano Stabellini ,
	Ian Campbell 
Subject: Re: [Xen-devel] [PATCH 5/6] xen/pvh: balloon and grant changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 20 Oct 2012, Konrad Rzeszutek Wilk wrote:
> From: Mukesh Rathor 
> 
> For balloon changes we skip setting of local P2M as it's updated
> in Xen. For grant, the shared grant frame is the pfn and not mfn,
> hence its mapped via the same code path as HVM.
> 
> Signed-off-by: Mukesh Rathor 
> Signed-off-by: Konrad Rzeszutek Wilk 
> ---
>  drivers/xen/balloon.c     |   15 +++++++++------
>  drivers/xen/gntdev.c      |    3 ++-
>  drivers/xen/grant-table.c |   26 ++++++++++++++++++++++----
>  3 files changed, 33 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> index 31ab82f..c825b63 100644
> --- a/drivers/xen/balloon.c
> +++ b/drivers/xen/balloon.c
> @@ -361,7 +361,9 @@ static enum bp_state increase_reservation(unsigned long nr_pages)
>  		set_phys_to_machine(pfn, frame_list[i]);
>  
>  		/* Link back into the page tables if not highmem. */
> -		if (xen_pv_domain() && !PageHighMem(page)) {
> +		if (xen_pv_domain() && !PageHighMem(page) &&
> +		    !xen_feature(XENFEAT_auto_translated_physmap)) {
> +
>  			int ret;
>  			ret = HYPERVISOR_update_va_mapping(
>  				(unsigned long)__va(pfn << PAGE_SHIFT),
> @@ -418,12 +420,13 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
>  		scrub_page(page);
>  
>  		if (xen_pv_domain() && !PageHighMem(page)) {
> -			ret = HYPERVISOR_update_va_mapping(
> -				(unsigned long)__va(pfn << PAGE_SHIFT),
> -				__pte_ma(0), 0);
> -			BUG_ON(ret);
> +			if (!xen_feature(XENFEAT_auto_translated_physmap)) {
> +				ret = HYPERVISOR_update_va_mapping(
> +					(unsigned long)__va(pfn << PAGE_SHIFT),
> +					__pte_ma(0), 0);
> +				BUG_ON(ret);
> +			}
>  		}

this change, unlike the one before, actually makes things different for
traditional pv domains in case PageHighMem(page).

The rest looks good.

>  	}
>  
>  	/* Ensure that ballooned highmem pages don't have kmaps. */
> diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
> index 610bfc6..d39d54e 100644
> --- a/drivers/xen/gntdev.c
> +++ b/drivers/xen/gntdev.c
> @@ -803,7 +803,8 @@ static int __init gntdev_init(void)
>  	if (!xen_domain())
>  		return -ENODEV;
>  
> -	use_ptemod = xen_pv_domain();
> +	use_ptemod = xen_pv_domain() &&
> +		     !xen_feature(XENFEAT_auto_translated_physmap);
>  
>  	err = misc_register(&gntdev_miscdev);
>  	if (err != 0) {
> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> index b2b0a37..9c0019d 100644
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -1029,14 +1029,19 @@ static void gnttab_unmap_frames_v2(void)
>  static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
>  {
>  	struct gnttab_setup_table setup;
> -	unsigned long *frames;
> +	unsigned long *frames, start_gpfn;
>  	unsigned int nr_gframes = end_idx + 1;
>  	int rc;
>  
> -	if (xen_hvm_domain()) {
> +	if (xen_hvm_domain() || xen_feature(XENFEAT_auto_translated_physmap)) {
>  		struct xen_add_to_physmap xatp;
>  		unsigned int i = end_idx;
>  		rc = 0;
> +
> +		if (xen_hvm_domain())
> +			start_gpfn = xen_hvm_resume_frames >> PAGE_SHIFT;
> +		else
> +			start_gpfn = virt_to_pfn(gnttab_shared.addr);
>  		/*
>  		 * Loop backwards, so that the first hypercall has the largest
>  		 * index, ensuring that the table will grow only once.
> @@ -1045,7 +1050,7 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
>  			xatp.domid = DOMID_SELF;
>  			xatp.idx = i;
>  			xatp.space = XENMAPSPACE_grant_table;
> -			xatp.gpfn = (xen_hvm_resume_frames >> PAGE_SHIFT) + i;
> +			xatp.gpfn = start_gpfn + i;
>  			rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
>  			if (rc != 0) {
>  				printk(KERN_WARNING
> @@ -1108,7 +1113,7 @@ static void gnttab_request_version(void)
>  	int rc;
>  	struct gnttab_set_version gsv;
>  
> -	if (xen_hvm_domain())
> +	if (xen_hvm_domain() || xen_feature(XENFEAT_auto_translated_physmap))
>  		gsv.version = 1;
>  	else
>  		gsv.version = 2;
> @@ -1136,12 +1141,25 @@ static void gnttab_request_version(void)
>  int gnttab_resume(void)
>  {
>  	unsigned int max_nr_gframes;
> +	char *kmsg = "Failed to kmalloc pages for pv in hvm grant frames\n";
>  
>  	gnttab_request_version();
>  	max_nr_gframes = gnttab_max_grant_frames();
>  	if (max_nr_gframes < nr_grant_frames)
>  		return -ENOSYS;
>  
> +	/* PVH note: xen will free existing kmalloc'd mfn in
> +	 * XENMEM_add_to_physmap. TBD/FIXME: use xen ballooning instead of
> +	 * kmalloc(). */
> +	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap) &&
> +	    !gnttab_shared.addr) {
> +		gnttab_shared.addr =
> +			kmalloc(max_nr_gframes * PAGE_SIZE, GFP_KERNEL);
> +		if (!gnttab_shared.addr) {
> +			pr_warn("%s", kmsg);
> +			return -ENOMEM;
> +		}
> +	}
>  	if (xen_pv_domain())
>  		return gnttab_map(0, nr_grant_frames - 1);
>  
> -- 
> 1.7.7.6
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 13:26:46 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 13:26:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQI1O-0000lP-Qw; Mon, 22 Oct 2012 13:26:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQI1N-0000l8-C8
	for xen-devel@lists.xensource.com; Mon, 22 Oct 2012 13:26:21 +0000
Received: from [193.109.254.147:40006] by server-12.bemta-14.messagelabs.com
	id D0/8E-13558-C7945805; Mon, 22 Oct 2012 13:26:20 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1350912371!10866961!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUxNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5642 invoked from network); 22 Oct 2012 13:26:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 13:26:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,629,1344211200"; d="scan'208";a="15309956"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Oct 2012 13:26:11 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Mon, 22 Oct 2012 14:26:11 +0100
Date: Mon, 22 Oct 2012 14:25:43 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Konrad Rzeszutek Wilk 
In-Reply-To: <1350695882-12820-6-git-send-email-konrad.wilk@oracle.com>
Message-ID: 
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
	<1350695882-12820-6-git-send-email-konrad.wilk@oracle.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Stefano Stabellini ,
	Ian Campbell 
Subject: Re: [Xen-devel] [PATCH 5/6] xen/pvh: balloon and grant changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 20 Oct 2012, Konrad Rzeszutek Wilk wrote:
> From: Mukesh Rathor 
> 
> For balloon changes we skip setting of local P2M as it's updated
> in Xen. For grant, the shared grant frame is the pfn and not mfn,
> hence its mapped via the same code path as HVM.
> 
> Signed-off-by: Mukesh Rathor 
> Signed-off-by: Konrad Rzeszutek Wilk 
> ---
>  drivers/xen/balloon.c     |   15 +++++++++------
>  drivers/xen/gntdev.c      |    3 ++-
>  drivers/xen/grant-table.c |   26 ++++++++++++++++++++++----
>  3 files changed, 33 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> index 31ab82f..c825b63 100644
> --- a/drivers/xen/balloon.c
> +++ b/drivers/xen/balloon.c
> @@ -361,7 +361,9 @@ static enum bp_state increase_reservation(unsigned long nr_pages)
>  		set_phys_to_machine(pfn, frame_list[i]);
>  
>  		/* Link back into the page tables if not highmem. */
> -		if (xen_pv_domain() && !PageHighMem(page)) {
> +		if (xen_pv_domain() && !PageHighMem(page) &&
> +		    !xen_feature(XENFEAT_auto_translated_physmap)) {
> +
>  			int ret;
>  			ret = HYPERVISOR_update_va_mapping(
>  				(unsigned long)__va(pfn << PAGE_SHIFT),
> @@ -418,12 +420,13 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
>  		scrub_page(page);
>  
>  		if (xen_pv_domain() && !PageHighMem(page)) {
> -			ret = HYPERVISOR_update_va_mapping(
> -				(unsigned long)__va(pfn << PAGE_SHIFT),
> -				__pte_ma(0), 0);
> -			BUG_ON(ret);
> +			if (!xen_feature(XENFEAT_auto_translated_physmap)) {
> +				ret = HYPERVISOR_update_va_mapping(
> +					(unsigned long)__va(pfn << PAGE_SHIFT),
> +					__pte_ma(0), 0);
> +				BUG_ON(ret);
> +			}
>  		}

this change, unlike the one before, actually makes things different for
traditional pv domains in case PageHighMem(page).

The rest looks good.

>  	}
>  
>  	/* Ensure that ballooned highmem pages don't have kmaps. */
> diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
> index 610bfc6..d39d54e 100644
> --- a/drivers/xen/gntdev.c
> +++ b/drivers/xen/gntdev.c
> @@ -803,7 +803,8 @@ static int __init gntdev_init(void)
>  	if (!xen_domain())
>  		return -ENODEV;
>  
> -	use_ptemod = xen_pv_domain();
> +	use_ptemod = xen_pv_domain() &&
> +		     !xen_feature(XENFEAT_auto_translated_physmap);
>  
>  	err = misc_register(&gntdev_miscdev);
>  	if (err != 0) {
> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> index b2b0a37..9c0019d 100644
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -1029,14 +1029,19 @@ static void gnttab_unmap_frames_v2(void)
>  static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
>  {
>  	struct gnttab_setup_table setup;
> -	unsigned long *frames;
> +	unsigned long *frames, start_gpfn;
>  	unsigned int nr_gframes = end_idx + 1;
>  	int rc;
>  
> -	if (xen_hvm_domain()) {
> +	if (xen_hvm_domain() || xen_feature(XENFEAT_auto_translated_physmap)) {
>  		struct xen_add_to_physmap xatp;
>  		unsigned int i = end_idx;
>  		rc = 0;
> +
> +		if (xen_hvm_domain())
> +			start_gpfn = xen_hvm_resume_frames >> PAGE_SHIFT;
> +		else
> +			start_gpfn = virt_to_pfn(gnttab_shared.addr);
>  		/*
>  		 * Loop backwards, so that the first hypercall has the largest
>  		 * index, ensuring that the table will grow only once.
> @@ -1045,7 +1050,7 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
>  			xatp.domid = DOMID_SELF;
>  			xatp.idx = i;
>  			xatp.space = XENMAPSPACE_grant_table;
> -			xatp.gpfn = (xen_hvm_resume_frames >> PAGE_SHIFT) + i;
> +			xatp.gpfn = start_gpfn + i;
>  			rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
>  			if (rc != 0) {
>  				printk(KERN_WARNING
> @@ -1108,7 +1113,7 @@ static void gnttab_request_version(void)
>  	int rc;
>  	struct gnttab_set_version gsv;
>  
> -	if (xen_hvm_domain())
> +	if (xen_hvm_domain() || xen_feature(XENFEAT_auto_translated_physmap))
>  		gsv.version = 1;
>  	else
>  		gsv.version = 2;
> @@ -1136,12 +1141,25 @@ static void gnttab_request_version(void)
>  int gnttab_resume(void)
>  {
>  	unsigned int max_nr_gframes;
> +	char *kmsg = "Failed to kmalloc pages for pv in hvm grant frames\n";
>  
>  	gnttab_request_version();
>  	max_nr_gframes = gnttab_max_grant_frames();
>  	if (max_nr_gframes < nr_grant_frames)
>  		return -ENOSYS;
>  
> +	/* PVH note: xen will free existing kmalloc'd mfn in
> +	 * XENMEM_add_to_physmap. TBD/FIXME: use xen ballooning instead of
> +	 * kmalloc(). */
> +	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap) &&
> +	    !gnttab_shared.addr) {
> +		gnttab_shared.addr =
> +			kmalloc(max_nr_gframes * PAGE_SIZE, GFP_KERNEL);
> +		if (!gnttab_shared.addr) {
> +			pr_warn("%s", kmsg);
> +			return -ENOMEM;
> +		}
> +	}
>  	if (xen_pv_domain())
>  		return gnttab_map(0, nr_grant_frames - 1);
>  
> -- 
> 1.7.7.6
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 13:35:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 13:35:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQIAF-0001IV-08; Mon, 22 Oct 2012 13:35:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQIAE-0001IQ-3m
	for xen-devel@lists.xensource.com; Mon, 22 Oct 2012 13:35:30 +0000
Received: from [193.109.254.147:24015] by server-14.bemta-14.messagelabs.com
	id 65/8D-20054-1AB45805; Mon, 22 Oct 2012 13:35:29 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1350912923!8549273!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUxNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18720 invoked from network); 22 Oct 2012 13:35:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 13:35:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,629,1344211200"; d="scan'208";a="15310344"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Oct 2012 13:35:12 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Mon, 22 Oct 2012 14:35:12 +0100
Date: Mon, 22 Oct 2012 14:34:44 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Konrad Rzeszutek Wilk 
In-Reply-To: <1350695882-12820-5-git-send-email-konrad.wilk@oracle.com>
Message-ID: 
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
	<1350695882-12820-5-git-send-email-konrad.wilk@oracle.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Stefano Stabellini ,
	Ian Campbell 
Subject: Re: [Xen-devel] [PATCH 4/6] xen/pvh: bootup and setup related
	changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 20 Oct 2012, Konrad Rzeszutek Wilk wrote:
> From: Mukesh Rathor 
> 
> In enlighten.c for PVH we can trap cpuid via vmexit, so don't
> need to use emulated prefix call. We also check for vector callback
> early on, as it is a required feature. PVH also runs at default kernel
> IOPL.
> 
> In setup.c, in xen_add_extra_mem() we can skip updating P2M as it's managed
> by Xen. PVH maps the entire IO space, but only RAM pages need to be repopulated.
> 
> Finally, pure PV settings are moved to a separate function that is only called
> for pure PV, ie, pv with pvmmu.
> 
> Signed-off-by: Mukesh Rathor 
> Signed-off-by: Konrad Rzeszutek Wilk 
>
> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> index 8971a26..8cce47b 100644
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  #include 
> +#include "mmu.h"
>  #include "xen-ops.h"
>  #include "vdso.h"
>  
> @@ -78,6 +79,9 @@ static void __init xen_add_extra_mem(u64 start, u64 size)
>  
>  	memblock_reserve(start, size);
>  
> +	if (xen_feature(XENFEAT_auto_translated_physmap))
> +		return;
> +
>  	xen_max_p2m_pfn = PFN_DOWN(start + size);
>  	for (pfn = PFN_DOWN(start); pfn < xen_max_p2m_pfn; pfn++) {
>  		unsigned long mfn = pfn_to_mfn(pfn);
> @@ -100,6 +104,7 @@ static unsigned long __init xen_do_chunk(unsigned long start,
>  		.domid        = DOMID_SELF
>  	};
>  	unsigned long len = 0;
> +	int xlated_phys = xen_feature(XENFEAT_auto_translated_physmap);
>  	unsigned long pfn;
>  	int ret;
>  
> @@ -113,7 +118,7 @@ static unsigned long __init xen_do_chunk(unsigned long start,
>  				continue;
>  			frame = mfn;
>  		} else {
> -			if (mfn != INVALID_P2M_ENTRY)
> +			if (!xlated_phys && mfn != INVALID_P2M_ENTRY)
>  				continue;
>  			frame = pfn;
>  		}

Shouldn't we add a "!xlated_phys &&" to the other case as well?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 13:35:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 13:35:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQIAF-0001IV-08; Mon, 22 Oct 2012 13:35:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQIAE-0001IQ-3m
	for xen-devel@lists.xensource.com; Mon, 22 Oct 2012 13:35:30 +0000
Received: from [193.109.254.147:24015] by server-14.bemta-14.messagelabs.com
	id 65/8D-20054-1AB45805; Mon, 22 Oct 2012 13:35:29 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1350912923!8549273!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUxNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18720 invoked from network); 22 Oct 2012 13:35:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 13:35:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,629,1344211200"; d="scan'208";a="15310344"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Oct 2012 13:35:12 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Mon, 22 Oct 2012 14:35:12 +0100
Date: Mon, 22 Oct 2012 14:34:44 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Konrad Rzeszutek Wilk 
In-Reply-To: <1350695882-12820-5-git-send-email-konrad.wilk@oracle.com>
Message-ID: 
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
	<1350695882-12820-5-git-send-email-konrad.wilk@oracle.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Stefano Stabellini ,
	Ian Campbell 
Subject: Re: [Xen-devel] [PATCH 4/6] xen/pvh: bootup and setup related
	changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 20 Oct 2012, Konrad Rzeszutek Wilk wrote:
> From: Mukesh Rathor 
> 
> In enlighten.c for PVH we can trap cpuid via vmexit, so don't
> need to use emulated prefix call. We also check for vector callback
> early on, as it is a required feature. PVH also runs at default kernel
> IOPL.
> 
> In setup.c, in xen_add_extra_mem() we can skip updating P2M as it's managed
> by Xen. PVH maps the entire IO space, but only RAM pages need to be repopulated.
> 
> Finally, pure PV settings are moved to a separate function that is only called
> for pure PV, ie, pv with pvmmu.
> 
> Signed-off-by: Mukesh Rathor 
> Signed-off-by: Konrad Rzeszutek Wilk 
>
> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> index 8971a26..8cce47b 100644
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  #include 
> +#include "mmu.h"
>  #include "xen-ops.h"
>  #include "vdso.h"
>  
> @@ -78,6 +79,9 @@ static void __init xen_add_extra_mem(u64 start, u64 size)
>  
>  	memblock_reserve(start, size);
>  
> +	if (xen_feature(XENFEAT_auto_translated_physmap))
> +		return;
> +
>  	xen_max_p2m_pfn = PFN_DOWN(start + size);
>  	for (pfn = PFN_DOWN(start); pfn < xen_max_p2m_pfn; pfn++) {
>  		unsigned long mfn = pfn_to_mfn(pfn);
> @@ -100,6 +104,7 @@ static unsigned long __init xen_do_chunk(unsigned long start,
>  		.domid        = DOMID_SELF
>  	};
>  	unsigned long len = 0;
> +	int xlated_phys = xen_feature(XENFEAT_auto_translated_physmap);
>  	unsigned long pfn;
>  	int ret;
>  
> @@ -113,7 +118,7 @@ static unsigned long __init xen_do_chunk(unsigned long start,
>  				continue;
>  			frame = mfn;
>  		} else {
> -			if (mfn != INVALID_P2M_ENTRY)
> +			if (!xlated_phys && mfn != INVALID_P2M_ENTRY)
>  				continue;
>  			frame = pfn;
>  		}

Shouldn't we add a "!xlated_phys &&" to the other case as well?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 13:38:50 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 13:38:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQID8-0001Qh-P9; Mon, 22 Oct 2012 13:38:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQID7-0001QX-FP
	for xen-devel@lists.xensource.com; Mon, 22 Oct 2012 13:38:29 +0000
Received: from [85.158.143.99:10752] by server-1.bemta-4.messagelabs.com id
	F9/BA-19134-45C45805; Mon, 22 Oct 2012 13:38:28 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1350913108!25287859!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUxNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32624 invoked from network); 22 Oct 2012 13:38:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 13:38:28 -0000
X-IronPort-AV: E=Sophos;i="4.80,629,1344211200"; d="scan'208";a="15310441"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Oct 2012 13:38:28 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Mon, 22 Oct 2012 14:38:27 +0100
Date: Mon, 22 Oct 2012 14:38:00 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Konrad Rzeszutek Wilk 
In-Reply-To: <1350695882-12820-2-git-send-email-konrad.wilk@oracle.com>
Message-ID: 
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
	<1350695882-12820-2-git-send-email-konrad.wilk@oracle.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Stefano Stabellini ,
	Ian Campbell 
Subject: Re: [Xen-devel] [PATCH 1/6] xen/pvh: Support ParaVirtualized
 Hardware extensions.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 20 Oct 2012, Konrad Rzeszutek Wilk wrote:
> From: Mukesh Rathor 
> 
> PVH allows PV linux guest to utilize hardware extended capabilities, such
> as running MMU updates in a HVM container.
> 
> This patch allows it to be configured and enabled. Also, basic header file
> changes to add new subcalls to physmap hypercall.
> 
> Lastly, mfn_to_local_pfn must return mfn for paging mode translate
> (since we let the hypervisor - or CPU - do them for us).
> 
> Signed-off-by: Mukesh Rathor 
> Signed-off-by: Konrad Rzeszutek Wilk 


Acked-by: Stefano Stabellini 

>  arch/x86/include/asm/xen/page.h |    3 +++
>  arch/x86/xen/Kconfig            |   10 ++++++++++
>  arch/x86/xen/xen-head.S         |   11 ++++++++++-
>  include/xen/interface/memory.h  |   24 +++++++++++++++++++++++-
>  include/xen/interface/physdev.h |   10 ++++++++++
>  5 files changed, 56 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
> index 472b9b7..6af440d 100644
> --- a/arch/x86/include/asm/xen/page.h
> +++ b/arch/x86/include/asm/xen/page.h
> @@ -159,6 +159,9 @@ static inline xpaddr_t machine_to_phys(xmaddr_t machine)
>  static inline unsigned long mfn_to_local_pfn(unsigned long mfn)
>  {
>  	unsigned long pfn = mfn_to_pfn(mfn);
> +
> +	if (xen_feature(XENFEAT_auto_translated_physmap))
> +		return mfn;
>  	if (get_phys_to_machine(pfn) != mfn)
>  		return -1; /* force !pfn_valid() */
>  	return pfn;
> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> index fdce49c..822c5a0 100644
> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@ -50,3 +50,13 @@ config XEN_DEBUG_FS
>  	  Enable statistics output and various tuning options in debugfs.
>  	  Enabling this option may incur a significant performance overhead.
>  
> +config XEN_X86_PVH
> +	bool "Support for running as a PVH guest (EXPERIMENTAL)"
> +	depends on X86_64 && XEN && EXPERIMENTAL
> +	default n
> +	help
> +	   This option enables support for running as a PVH guest (PV guest
> +	   using hardware extensions) under a suitably capable hypervisor.
> +	   This option is EXPERIMENTAL because the hypervisor interfaces
> +	   which it uses are not yet considered stable therefore backwards and
> +	   forwards compatibility is not yet guaranteed.  If unsure, say N.
> diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
> index 7faed58..1a6bca1 100644
> --- a/arch/x86/xen/xen-head.S
> +++ b/arch/x86/xen/xen-head.S
> @@ -13,6 +13,15 @@
>  #include 
>  #include 
>  
> +#ifdef CONFIG_XEN_X86_PVH
> +#define FEATURES_PVH "|writable_descriptor_tables" \
> +		     "|auto_translated_physmap" \
> +		     "|supervisor_mode_kernel" \
> +		     "|hvm_callback_vector"
> +#else
> +#define FEATURES_PVH /* Not supported */
> +#endif
> +
>  	__INIT
>  ENTRY(startup_xen)
>  	cld
> @@ -95,7 +104,7 @@ NEXT_HYPERCALL(arch_6)
>  #endif
>  	ELFNOTE(Xen, XEN_ELFNOTE_ENTRY,          _ASM_PTR startup_xen)
>  	ELFNOTE(Xen, XEN_ELFNOTE_HYPERCALL_PAGE, _ASM_PTR hypercall_page)
> -	ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,       .asciz "!writable_page_tables|pae_pgdir_above_4gb")
> +	ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,       .asciz "!writable_page_tables|pae_pgdir_above_4gb"FEATURES_PVH)
>  	ELFNOTE(Xen, XEN_ELFNOTE_PAE_MODE,       .asciz "yes")
>  	ELFNOTE(Xen, XEN_ELFNOTE_LOADER,         .asciz "generic")
>  	ELFNOTE(Xen, XEN_ELFNOTE_L1_MFN_VALID,
> diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
> index b66d04c..8beebdb 100644
> --- a/include/xen/interface/memory.h
> +++ b/include/xen/interface/memory.h
> @@ -169,7 +169,13 @@ struct xen_add_to_physmap {
>      /* Source mapping space. */
>  #define XENMAPSPACE_shared_info 0 /* shared info page */
>  #define XENMAPSPACE_grant_table 1 /* grant table page */
> -    unsigned int space;
> +#define XENMAPSPACE_gmfn        2 /* GMFN */
> +#define XENMAPSPACE_gmfn_range  3 /* GMFN range */
> +#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */
> +    uint16_t space;
> +    domid_t foreign_domid;         /* IFF XENMAPSPACE_gmfn_foreign */
> +
> +#define XENMAPIDX_grant_table_status 0x80000000
>  
>      /* Index into source mapping space. */
>      xen_ulong_t idx;
> @@ -237,4 +243,20 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_memory_map);
>   * during a driver critical region.
>   */
>  extern spinlock_t xen_reservation_lock;
> +
> +/*
> + * Unmaps the page appearing at a particular GPFN from the specified guest's
> + * pseudophysical address space.
> + * arg == addr of xen_remove_from_physmap_t.
> + */
> +#define XENMEM_remove_from_physmap      15
> +struct xen_remove_from_physmap {
> +    /* Which domain to change the mapping for. */
> +    domid_t domid;
> +
> +    /* GPFN of the current mapping of the page. */
> +    xen_pfn_t gpfn;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_remove_from_physmap);
> +
>  #endif /* __XEN_PUBLIC_MEMORY_H__ */
> diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
> index 1844d31..83050d3 100644
> --- a/include/xen/interface/physdev.h
> +++ b/include/xen/interface/physdev.h
> @@ -274,6 +274,16 @@ struct physdev_dbgp_op {
>      } u;
>  };
>  
> +#define PHYSDEVOP_map_iomem        30
> +struct physdev_map_iomem {
> +    /* IN */
> +    uint64_t first_gfn;
> +    uint64_t first_mfn;
> +    uint32_t nr_mfns;
> +    uint32_t add_mapping; /* 1 == add mapping;  0 == unmap */
> +
> +};
> +
>  /*
>   * Notify that some PIRQ-bound event channels have been unmasked.
>   * ** This command is obsolete since interface version 0x00030202 and is **
> -- 
> 1.7.7.6
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 13:38:50 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 13:38:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQID8-0001Qh-P9; Mon, 22 Oct 2012 13:38:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQID7-0001QX-FP
	for xen-devel@lists.xensource.com; Mon, 22 Oct 2012 13:38:29 +0000
Received: from [85.158.143.99:10752] by server-1.bemta-4.messagelabs.com id
	F9/BA-19134-45C45805; Mon, 22 Oct 2012 13:38:28 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1350913108!25287859!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUxNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32624 invoked from network); 22 Oct 2012 13:38:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 13:38:28 -0000
X-IronPort-AV: E=Sophos;i="4.80,629,1344211200"; d="scan'208";a="15310441"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Oct 2012 13:38:28 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Mon, 22 Oct 2012 14:38:27 +0100
Date: Mon, 22 Oct 2012 14:38:00 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Konrad Rzeszutek Wilk 
In-Reply-To: <1350695882-12820-2-git-send-email-konrad.wilk@oracle.com>
Message-ID: 
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
	<1350695882-12820-2-git-send-email-konrad.wilk@oracle.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Stefano Stabellini ,
	Ian Campbell 
Subject: Re: [Xen-devel] [PATCH 1/6] xen/pvh: Support ParaVirtualized
 Hardware extensions.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 20 Oct 2012, Konrad Rzeszutek Wilk wrote:
> From: Mukesh Rathor 
> 
> PVH allows PV linux guest to utilize hardware extended capabilities, such
> as running MMU updates in a HVM container.
> 
> This patch allows it to be configured and enabled. Also, basic header file
> changes to add new subcalls to physmap hypercall.
> 
> Lastly, mfn_to_local_pfn must return mfn for paging mode translate
> (since we let the hypervisor - or CPU - do them for us).
> 
> Signed-off-by: Mukesh Rathor 
> Signed-off-by: Konrad Rzeszutek Wilk 


Acked-by: Stefano Stabellini 

>  arch/x86/include/asm/xen/page.h |    3 +++
>  arch/x86/xen/Kconfig            |   10 ++++++++++
>  arch/x86/xen/xen-head.S         |   11 ++++++++++-
>  include/xen/interface/memory.h  |   24 +++++++++++++++++++++++-
>  include/xen/interface/physdev.h |   10 ++++++++++
>  5 files changed, 56 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
> index 472b9b7..6af440d 100644
> --- a/arch/x86/include/asm/xen/page.h
> +++ b/arch/x86/include/asm/xen/page.h
> @@ -159,6 +159,9 @@ static inline xpaddr_t machine_to_phys(xmaddr_t machine)
>  static inline unsigned long mfn_to_local_pfn(unsigned long mfn)
>  {
>  	unsigned long pfn = mfn_to_pfn(mfn);
> +
> +	if (xen_feature(XENFEAT_auto_translated_physmap))
> +		return mfn;
>  	if (get_phys_to_machine(pfn) != mfn)
>  		return -1; /* force !pfn_valid() */
>  	return pfn;
> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> index fdce49c..822c5a0 100644
> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@ -50,3 +50,13 @@ config XEN_DEBUG_FS
>  	  Enable statistics output and various tuning options in debugfs.
>  	  Enabling this option may incur a significant performance overhead.
>  
> +config XEN_X86_PVH
> +	bool "Support for running as a PVH guest (EXPERIMENTAL)"
> +	depends on X86_64 && XEN && EXPERIMENTAL
> +	default n
> +	help
> +	   This option enables support for running as a PVH guest (PV guest
> +	   using hardware extensions) under a suitably capable hypervisor.
> +	   This option is EXPERIMENTAL because the hypervisor interfaces
> +	   which it uses are not yet considered stable therefore backwards and
> +	   forwards compatibility is not yet guaranteed.  If unsure, say N.
> diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
> index 7faed58..1a6bca1 100644
> --- a/arch/x86/xen/xen-head.S
> +++ b/arch/x86/xen/xen-head.S
> @@ -13,6 +13,15 @@
>  #include 
>  #include 
>  
> +#ifdef CONFIG_XEN_X86_PVH
> +#define FEATURES_PVH "|writable_descriptor_tables" \
> +		     "|auto_translated_physmap" \
> +		     "|supervisor_mode_kernel" \
> +		     "|hvm_callback_vector"
> +#else
> +#define FEATURES_PVH /* Not supported */
> +#endif
> +
>  	__INIT
>  ENTRY(startup_xen)
>  	cld
> @@ -95,7 +104,7 @@ NEXT_HYPERCALL(arch_6)
>  #endif
>  	ELFNOTE(Xen, XEN_ELFNOTE_ENTRY,          _ASM_PTR startup_xen)
>  	ELFNOTE(Xen, XEN_ELFNOTE_HYPERCALL_PAGE, _ASM_PTR hypercall_page)
> -	ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,       .asciz "!writable_page_tables|pae_pgdir_above_4gb")
> +	ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,       .asciz "!writable_page_tables|pae_pgdir_above_4gb"FEATURES_PVH)
>  	ELFNOTE(Xen, XEN_ELFNOTE_PAE_MODE,       .asciz "yes")
>  	ELFNOTE(Xen, XEN_ELFNOTE_LOADER,         .asciz "generic")
>  	ELFNOTE(Xen, XEN_ELFNOTE_L1_MFN_VALID,
> diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
> index b66d04c..8beebdb 100644
> --- a/include/xen/interface/memory.h
> +++ b/include/xen/interface/memory.h
> @@ -169,7 +169,13 @@ struct xen_add_to_physmap {
>      /* Source mapping space. */
>  #define XENMAPSPACE_shared_info 0 /* shared info page */
>  #define XENMAPSPACE_grant_table 1 /* grant table page */
> -    unsigned int space;
> +#define XENMAPSPACE_gmfn        2 /* GMFN */
> +#define XENMAPSPACE_gmfn_range  3 /* GMFN range */
> +#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */
> +    uint16_t space;
> +    domid_t foreign_domid;         /* IFF XENMAPSPACE_gmfn_foreign */
> +
> +#define XENMAPIDX_grant_table_status 0x80000000
>  
>      /* Index into source mapping space. */
>      xen_ulong_t idx;
> @@ -237,4 +243,20 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_memory_map);
>   * during a driver critical region.
>   */
>  extern spinlock_t xen_reservation_lock;
> +
> +/*
> + * Unmaps the page appearing at a particular GPFN from the specified guest's
> + * pseudophysical address space.
> + * arg == addr of xen_remove_from_physmap_t.
> + */
> +#define XENMEM_remove_from_physmap      15
> +struct xen_remove_from_physmap {
> +    /* Which domain to change the mapping for. */
> +    domid_t domid;
> +
> +    /* GPFN of the current mapping of the page. */
> +    xen_pfn_t gpfn;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_remove_from_physmap);
> +
>  #endif /* __XEN_PUBLIC_MEMORY_H__ */
> diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
> index 1844d31..83050d3 100644
> --- a/include/xen/interface/physdev.h
> +++ b/include/xen/interface/physdev.h
> @@ -274,6 +274,16 @@ struct physdev_dbgp_op {
>      } u;
>  };
>  
> +#define PHYSDEVOP_map_iomem        30
> +struct physdev_map_iomem {
> +    /* IN */
> +    uint64_t first_gfn;
> +    uint64_t first_mfn;
> +    uint32_t nr_mfns;
> +    uint32_t add_mapping; /* 1 == add mapping;  0 == unmap */
> +
> +};
> +
>  /*
>   * Notify that some PIRQ-bound event channels have been unmasked.
>   * ** This command is obsolete since interface version 0x00030202 and is **
> -- 
> 1.7.7.6
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 13:45:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 13:45:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQIJr-0001js-0i; Mon, 22 Oct 2012 13:45:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQIJp-0001jn-UP
	for xen-devel@lists.xensource.com; Mon, 22 Oct 2012 13:45:26 +0000
Received: from [85.158.143.99:46813] by server-3.bemta-4.messagelabs.com id
	9D/10-03544-5FD45805; Mon, 22 Oct 2012 13:45:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1350913522!25289086!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUxNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25878 invoked from network); 22 Oct 2012 13:45:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 13:45:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,629,1344211200"; d="scan'208";a="15310615"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Oct 2012 13:45:07 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Mon, 22 Oct 2012 14:45:07 +0100
Date: Mon, 22 Oct 2012 14:44:40 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Konrad Rzeszutek Wilk 
In-Reply-To: <1350695882-12820-3-git-send-email-konrad.wilk@oracle.com>
Message-ID: 
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
	<1350695882-12820-3-git-send-email-konrad.wilk@oracle.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Stefano Stabellini ,
	Ian Campbell 
Subject: Re: [Xen-devel] [PATCH 2/6] xen/pvh: Extend vcpu_guest_context, p2m,
 event, and xenbus to support PVH.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 20 Oct 2012, Konrad Rzeszutek Wilk wrote:
> From: Mukesh Rathor 
> 
> make gdt_frames[]/gdt_ents into a union with {gdtaddr, gdtsz}, as PVH
> only needs to send down gdtaddr and gdtsz.
> 
> For interrupts, PVH uses native_irq_ops.
> vcpu hotplug is currently not available for PVH.
> 
> For events we follow what PVHVM does - to use callback vector.
> Lastly, also use HVM path to setup XenBus.
> 
> Signed-off-by: Mukesh Rathor 
> Signed-off-by: Konrad Rzeszutek Wilk 
> ---
>  arch/x86/include/asm/xen/interface.h |   11 +++++-
>  arch/x86/xen/irq.c                   |    5 ++-
>  arch/x86/xen/p2m.c                   |    2 +-
>  arch/x86/xen/smp.c                   |   75 ++++++++++++++++++++++------------
>  drivers/xen/cpu_hotplug.c            |    4 +-
>  drivers/xen/events.c                 |    9 ++++-
>  drivers/xen/xenbus/xenbus_client.c   |    3 +-
>  7 files changed, 77 insertions(+), 32 deletions(-)
> 
> diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
> index 6d2f75a..4c08f23 100644
> --- a/arch/x86/include/asm/xen/interface.h
> +++ b/arch/x86/include/asm/xen/interface.h
> @@ -144,7 +144,16 @@ struct vcpu_guest_context {
>      struct cpu_user_regs user_regs;         /* User-level CPU registers     */
>      struct trap_info trap_ctxt[256];        /* Virtual IDT                  */
>      unsigned long ldt_base, ldt_ents;       /* LDT (linear address, # ents) */
> -    unsigned long gdt_frames[16], gdt_ents; /* GDT (machine frames, # ents) */
> +    union {
> +	struct {
> +		/* PV: GDT (machine frames, # ents).*/
> +		unsigned long gdt_frames[16], gdt_ents;
> +	} pv;
> +	struct {
> +		/* PVH: GDTR addr and size */
> +		unsigned long gdtaddr, gdtsz;
> +	} pvh;
> +    } u;
>      unsigned long kernel_ss, kernel_sp;     /* Virtual TSS (only SS1/SP1)   */
>      /* NB. User pagetable on x86/64 is placed in ctrlreg[1]. */
>      unsigned long ctrlreg[8];               /* CR0-CR7 (control registers)  */
> diff --git a/arch/x86/xen/irq.c b/arch/x86/xen/irq.c
> index 01a4dc0..fcbe56a 100644
> --- a/arch/x86/xen/irq.c
> +++ b/arch/x86/xen/irq.c
> @@ -5,6 +5,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include 
> @@ -129,6 +130,8 @@ static const struct pv_irq_ops xen_irq_ops __initconst = {
>  
>  void __init xen_init_irq_ops(void)
>  {
> -	pv_irq_ops = xen_irq_ops;
> +	/* For PVH we use default pv_irq_ops settings */
> +	if (!xen_feature(XENFEAT_hvm_callback_vector))
> +		pv_irq_ops = xen_irq_ops;
>  	x86_init.irqs.intr_init = xen_init_IRQ;
>  }
> diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
> index 95fb2aa..ea553c8 100644
> --- a/arch/x86/xen/p2m.c
> +++ b/arch/x86/xen/p2m.c
> @@ -798,7 +798,7 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
>  {
>  	unsigned topidx, mididx, idx;
>  
> -	if (unlikely(xen_feature(XENFEAT_auto_translated_physmap))) {
> +	if (xen_feature(XENFEAT_auto_translated_physmap)) {
>  		BUG_ON(pfn != mfn && mfn != INVALID_P2M_ENTRY);
>  		return true;
>  	}
> diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
> index 353c50f..df400349 100644
> --- a/arch/x86/xen/smp.c
> +++ b/arch/x86/xen/smp.c
> @@ -68,9 +68,11 @@ static void __cpuinit cpu_bringup(void)
>  	touch_softlockup_watchdog();
>  	preempt_disable();
>  
> -	xen_enable_sysenter();
> -	xen_enable_syscall();
> -
> +	/* PVH runs in ring 0 and allows us to do native syscalls. Yay! */
> +	if (!xen_feature(XENFEAT_supervisor_mode_kernel)) {
> +		xen_enable_sysenter();
> +		xen_enable_syscall();
> +	}
>  	cpu = smp_processor_id();
>  	smp_store_cpu_info(cpu);
>  	cpu_data(cpu).x86_max_cores = 1;
> @@ -230,10 +232,11 @@ static void __init xen_smp_prepare_boot_cpu(void)
>  	BUG_ON(smp_processor_id() != 0);
>  	native_smp_prepare_boot_cpu();
>  
> -	/* We've switched to the "real" per-cpu gdt, so make sure the
> -	   old memory can be recycled */
> -	make_lowmem_page_readwrite(xen_initial_gdt);
> -
> +	if (!xen_feature(XENFEAT_writable_page_tables)) {
> +		/* We've switched to the "real" per-cpu gdt, so make sure the
> +		 * old memory can be recycled */
> +		make_lowmem_page_readwrite(xen_initial_gdt);
> +	}
>  	xen_filter_cpu_maps();
>  	xen_setup_vcpu_info_placement();
>  }
> @@ -300,8 +303,6 @@ cpu_initialize_context(unsigned int cpu, struct task_struct *idle)
>  	gdt = get_cpu_gdt_table(cpu);
>  
>  	ctxt->flags = VGCF_IN_KERNEL;
> -	ctxt->user_regs.ds = __USER_DS;
> -	ctxt->user_regs.es = __USER_DS;
>  	ctxt->user_regs.ss = __KERNEL_DS;
>  #ifdef CONFIG_X86_32
>  	ctxt->user_regs.fs = __KERNEL_PERCPU;
> @@ -310,35 +311,57 @@ cpu_initialize_context(unsigned int cpu, struct task_struct *idle)
>  	ctxt->gs_base_kernel = per_cpu_offset(cpu);
>  #endif
>  	ctxt->user_regs.eip = (unsigned long)cpu_bringup_and_idle;
> -	ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
>  
>  	memset(&ctxt->fpu_ctxt, 0, sizeof(ctxt->fpu_ctxt));
>  
> -	xen_copy_trap_info(ctxt->trap_ctxt);
> +	/* check for autoxlated to get it right for 32bit kernel */

I am not sure what this comment means, considering that in another
comment below you say that we don't support 32bit PVH kernels.


> +	if (xen_feature(XENFEAT_auto_translated_physmap) &&
> +	    xen_feature(XENFEAT_supervisor_mode_kernel)) {
>  
> -	ctxt->ldt_ents = 0;
> +		ctxt->user_regs.ds = __KERNEL_DS;
> +		ctxt->user_regs.es = 0;
> +		ctxt->user_regs.gs = 0;
>  
> -	BUG_ON((unsigned long)gdt & ~PAGE_MASK);
> +		ctxt->u.pvh.gdtaddr = (unsigned long)gdt;
> +		ctxt->u.pvh.gdtsz = (unsigned long)(GDT_SIZE - 1);
>  
> -	gdt_mfn = arbitrary_virt_to_mfn(gdt);
> -	make_lowmem_page_readonly(gdt);
> -	make_lowmem_page_readonly(mfn_to_virt(gdt_mfn));
> +#ifdef CONFIG_X86_64
> +		/* Note: PVH is not supported on x86_32. */
> +		ctxt->gs_base_user = (unsigned long)
> +					per_cpu(irq_stack_union.gs_base, cpu);
> +#endif
> +	} else {
> +		ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
> +		ctxt->user_regs.ds = __USER_DS;
> +		ctxt->user_regs.es = __USER_DS;
>  
> -	ctxt->gdt_frames[0] = gdt_mfn;
> -	ctxt->gdt_ents      = GDT_ENTRIES;
> +		xen_copy_trap_info(ctxt->trap_ctxt);
>  
> -	ctxt->user_regs.cs = __KERNEL_CS;
> -	ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct pt_regs);
> +		ctxt->ldt_ents = 0;
>  
> -	ctxt->kernel_ss = __KERNEL_DS;
> -	ctxt->kernel_sp = idle->thread.sp0;
> +		BUG_ON((unsigned long)gdt & ~PAGE_MASK);
> +
> +		gdt_mfn = arbitrary_virt_to_mfn(gdt);
> +		make_lowmem_page_readonly(gdt);
> +		make_lowmem_page_readonly(mfn_to_virt(gdt_mfn));
> +
> +		ctxt->u.pv.gdt_frames[0] = gdt_mfn;
> +		ctxt->u.pv.gdt_ents      = GDT_ENTRIES;
> +
> +		ctxt->kernel_ss = __KERNEL_DS;
> +		ctxt->kernel_sp = idle->thread.sp0;
>  
>  #ifdef CONFIG_X86_32
> -	ctxt->event_callback_cs     = __KERNEL_CS;
> -	ctxt->failsafe_callback_cs  = __KERNEL_CS;
> +		ctxt->event_callback_cs     = __KERNEL_CS;
> +		ctxt->failsafe_callback_cs  = __KERNEL_CS;
>  #endif
> -	ctxt->event_callback_eip    = (unsigned long)xen_hypervisor_callback;
> -	ctxt->failsafe_callback_eip = (unsigned long)xen_failsafe_callback;
> +		ctxt->event_callback_eip    =
> +					(unsigned long)xen_hypervisor_callback;
> +		ctxt->failsafe_callback_eip =
> +					(unsigned long)xen_failsafe_callback;
> +	}
> +	ctxt->user_regs.cs = __KERNEL_CS;
> +	ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct pt_regs);
>  
>  	per_cpu(xen_cr3, cpu) = __pa(swapper_pg_dir);
>  	ctxt->ctrlreg[3] = xen_pfn_to_cr3(virt_to_mfn(swapper_pg_dir));

The tradional path looks the same as before, however it is hard to tell
whether the PVH path is correct without the Xen side. For example, what
is gdtsz?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 13:45:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 13:45:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQIJr-0001js-0i; Mon, 22 Oct 2012 13:45:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQIJp-0001jn-UP
	for xen-devel@lists.xensource.com; Mon, 22 Oct 2012 13:45:26 +0000
Received: from [85.158.143.99:46813] by server-3.bemta-4.messagelabs.com id
	9D/10-03544-5FD45805; Mon, 22 Oct 2012 13:45:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1350913522!25289086!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUxNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25878 invoked from network); 22 Oct 2012 13:45:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 13:45:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,629,1344211200"; d="scan'208";a="15310615"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Oct 2012 13:45:07 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Mon, 22 Oct 2012 14:45:07 +0100
Date: Mon, 22 Oct 2012 14:44:40 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Konrad Rzeszutek Wilk 
In-Reply-To: <1350695882-12820-3-git-send-email-konrad.wilk@oracle.com>
Message-ID: 
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
	<1350695882-12820-3-git-send-email-konrad.wilk@oracle.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Stefano Stabellini ,
	Ian Campbell 
Subject: Re: [Xen-devel] [PATCH 2/6] xen/pvh: Extend vcpu_guest_context, p2m,
 event, and xenbus to support PVH.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 20 Oct 2012, Konrad Rzeszutek Wilk wrote:
> From: Mukesh Rathor 
> 
> make gdt_frames[]/gdt_ents into a union with {gdtaddr, gdtsz}, as PVH
> only needs to send down gdtaddr and gdtsz.
> 
> For interrupts, PVH uses native_irq_ops.
> vcpu hotplug is currently not available for PVH.
> 
> For events we follow what PVHVM does - to use callback vector.
> Lastly, also use HVM path to setup XenBus.
> 
> Signed-off-by: Mukesh Rathor 
> Signed-off-by: Konrad Rzeszutek Wilk 
> ---
>  arch/x86/include/asm/xen/interface.h |   11 +++++-
>  arch/x86/xen/irq.c                   |    5 ++-
>  arch/x86/xen/p2m.c                   |    2 +-
>  arch/x86/xen/smp.c                   |   75 ++++++++++++++++++++++------------
>  drivers/xen/cpu_hotplug.c            |    4 +-
>  drivers/xen/events.c                 |    9 ++++-
>  drivers/xen/xenbus/xenbus_client.c   |    3 +-
>  7 files changed, 77 insertions(+), 32 deletions(-)
> 
> diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
> index 6d2f75a..4c08f23 100644
> --- a/arch/x86/include/asm/xen/interface.h
> +++ b/arch/x86/include/asm/xen/interface.h
> @@ -144,7 +144,16 @@ struct vcpu_guest_context {
>      struct cpu_user_regs user_regs;         /* User-level CPU registers     */
>      struct trap_info trap_ctxt[256];        /* Virtual IDT                  */
>      unsigned long ldt_base, ldt_ents;       /* LDT (linear address, # ents) */
> -    unsigned long gdt_frames[16], gdt_ents; /* GDT (machine frames, # ents) */
> +    union {
> +	struct {
> +		/* PV: GDT (machine frames, # ents).*/
> +		unsigned long gdt_frames[16], gdt_ents;
> +	} pv;
> +	struct {
> +		/* PVH: GDTR addr and size */
> +		unsigned long gdtaddr, gdtsz;
> +	} pvh;
> +    } u;
>      unsigned long kernel_ss, kernel_sp;     /* Virtual TSS (only SS1/SP1)   */
>      /* NB. User pagetable on x86/64 is placed in ctrlreg[1]. */
>      unsigned long ctrlreg[8];               /* CR0-CR7 (control registers)  */
> diff --git a/arch/x86/xen/irq.c b/arch/x86/xen/irq.c
> index 01a4dc0..fcbe56a 100644
> --- a/arch/x86/xen/irq.c
> +++ b/arch/x86/xen/irq.c
> @@ -5,6 +5,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include 
> @@ -129,6 +130,8 @@ static const struct pv_irq_ops xen_irq_ops __initconst = {
>  
>  void __init xen_init_irq_ops(void)
>  {
> -	pv_irq_ops = xen_irq_ops;
> +	/* For PVH we use default pv_irq_ops settings */
> +	if (!xen_feature(XENFEAT_hvm_callback_vector))
> +		pv_irq_ops = xen_irq_ops;
>  	x86_init.irqs.intr_init = xen_init_IRQ;
>  }
> diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
> index 95fb2aa..ea553c8 100644
> --- a/arch/x86/xen/p2m.c
> +++ b/arch/x86/xen/p2m.c
> @@ -798,7 +798,7 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
>  {
>  	unsigned topidx, mididx, idx;
>  
> -	if (unlikely(xen_feature(XENFEAT_auto_translated_physmap))) {
> +	if (xen_feature(XENFEAT_auto_translated_physmap)) {
>  		BUG_ON(pfn != mfn && mfn != INVALID_P2M_ENTRY);
>  		return true;
>  	}
> diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
> index 353c50f..df400349 100644
> --- a/arch/x86/xen/smp.c
> +++ b/arch/x86/xen/smp.c
> @@ -68,9 +68,11 @@ static void __cpuinit cpu_bringup(void)
>  	touch_softlockup_watchdog();
>  	preempt_disable();
>  
> -	xen_enable_sysenter();
> -	xen_enable_syscall();
> -
> +	/* PVH runs in ring 0 and allows us to do native syscalls. Yay! */
> +	if (!xen_feature(XENFEAT_supervisor_mode_kernel)) {
> +		xen_enable_sysenter();
> +		xen_enable_syscall();
> +	}
>  	cpu = smp_processor_id();
>  	smp_store_cpu_info(cpu);
>  	cpu_data(cpu).x86_max_cores = 1;
> @@ -230,10 +232,11 @@ static void __init xen_smp_prepare_boot_cpu(void)
>  	BUG_ON(smp_processor_id() != 0);
>  	native_smp_prepare_boot_cpu();
>  
> -	/* We've switched to the "real" per-cpu gdt, so make sure the
> -	   old memory can be recycled */
> -	make_lowmem_page_readwrite(xen_initial_gdt);
> -
> +	if (!xen_feature(XENFEAT_writable_page_tables)) {
> +		/* We've switched to the "real" per-cpu gdt, so make sure the
> +		 * old memory can be recycled */
> +		make_lowmem_page_readwrite(xen_initial_gdt);
> +	}
>  	xen_filter_cpu_maps();
>  	xen_setup_vcpu_info_placement();
>  }
> @@ -300,8 +303,6 @@ cpu_initialize_context(unsigned int cpu, struct task_struct *idle)
>  	gdt = get_cpu_gdt_table(cpu);
>  
>  	ctxt->flags = VGCF_IN_KERNEL;
> -	ctxt->user_regs.ds = __USER_DS;
> -	ctxt->user_regs.es = __USER_DS;
>  	ctxt->user_regs.ss = __KERNEL_DS;
>  #ifdef CONFIG_X86_32
>  	ctxt->user_regs.fs = __KERNEL_PERCPU;
> @@ -310,35 +311,57 @@ cpu_initialize_context(unsigned int cpu, struct task_struct *idle)
>  	ctxt->gs_base_kernel = per_cpu_offset(cpu);
>  #endif
>  	ctxt->user_regs.eip = (unsigned long)cpu_bringup_and_idle;
> -	ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
>  
>  	memset(&ctxt->fpu_ctxt, 0, sizeof(ctxt->fpu_ctxt));
>  
> -	xen_copy_trap_info(ctxt->trap_ctxt);
> +	/* check for autoxlated to get it right for 32bit kernel */

I am not sure what this comment means, considering that in another
comment below you say that we don't support 32bit PVH kernels.


> +	if (xen_feature(XENFEAT_auto_translated_physmap) &&
> +	    xen_feature(XENFEAT_supervisor_mode_kernel)) {
>  
> -	ctxt->ldt_ents = 0;
> +		ctxt->user_regs.ds = __KERNEL_DS;
> +		ctxt->user_regs.es = 0;
> +		ctxt->user_regs.gs = 0;
>  
> -	BUG_ON((unsigned long)gdt & ~PAGE_MASK);
> +		ctxt->u.pvh.gdtaddr = (unsigned long)gdt;
> +		ctxt->u.pvh.gdtsz = (unsigned long)(GDT_SIZE - 1);
>  
> -	gdt_mfn = arbitrary_virt_to_mfn(gdt);
> -	make_lowmem_page_readonly(gdt);
> -	make_lowmem_page_readonly(mfn_to_virt(gdt_mfn));
> +#ifdef CONFIG_X86_64
> +		/* Note: PVH is not supported on x86_32. */
> +		ctxt->gs_base_user = (unsigned long)
> +					per_cpu(irq_stack_union.gs_base, cpu);
> +#endif
> +	} else {
> +		ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
> +		ctxt->user_regs.ds = __USER_DS;
> +		ctxt->user_regs.es = __USER_DS;
>  
> -	ctxt->gdt_frames[0] = gdt_mfn;
> -	ctxt->gdt_ents      = GDT_ENTRIES;
> +		xen_copy_trap_info(ctxt->trap_ctxt);
>  
> -	ctxt->user_regs.cs = __KERNEL_CS;
> -	ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct pt_regs);
> +		ctxt->ldt_ents = 0;
>  
> -	ctxt->kernel_ss = __KERNEL_DS;
> -	ctxt->kernel_sp = idle->thread.sp0;
> +		BUG_ON((unsigned long)gdt & ~PAGE_MASK);
> +
> +		gdt_mfn = arbitrary_virt_to_mfn(gdt);
> +		make_lowmem_page_readonly(gdt);
> +		make_lowmem_page_readonly(mfn_to_virt(gdt_mfn));
> +
> +		ctxt->u.pv.gdt_frames[0] = gdt_mfn;
> +		ctxt->u.pv.gdt_ents      = GDT_ENTRIES;
> +
> +		ctxt->kernel_ss = __KERNEL_DS;
> +		ctxt->kernel_sp = idle->thread.sp0;
>  
>  #ifdef CONFIG_X86_32
> -	ctxt->event_callback_cs     = __KERNEL_CS;
> -	ctxt->failsafe_callback_cs  = __KERNEL_CS;
> +		ctxt->event_callback_cs     = __KERNEL_CS;
> +		ctxt->failsafe_callback_cs  = __KERNEL_CS;
>  #endif
> -	ctxt->event_callback_eip    = (unsigned long)xen_hypervisor_callback;
> -	ctxt->failsafe_callback_eip = (unsigned long)xen_failsafe_callback;
> +		ctxt->event_callback_eip    =
> +					(unsigned long)xen_hypervisor_callback;
> +		ctxt->failsafe_callback_eip =
> +					(unsigned long)xen_failsafe_callback;
> +	}
> +	ctxt->user_regs.cs = __KERNEL_CS;
> +	ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct pt_regs);
>  
>  	per_cpu(xen_cr3, cpu) = __pa(swapper_pg_dir);
>  	ctxt->ctrlreg[3] = xen_pfn_to_cr3(virt_to_mfn(swapper_pg_dir));

The tradional path looks the same as before, however it is hard to tell
whether the PVH path is correct without the Xen side. For example, what
is gdtsz?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 13:46:57 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 13:46:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQIKw-0001nv-FI; Mon, 22 Oct 2012 13:46:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQIKv-0001nn-Dr
	for xen-devel@lists.xensource.com; Mon, 22 Oct 2012 13:46:33 +0000
Received: from [85.158.143.99:8368] by server-2.bemta-4.messagelabs.com id
	A8/DD-22268-83E45805; Mon, 22 Oct 2012 13:46:32 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1350913591!23828964!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUxNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30631 invoked from network); 22 Oct 2012 13:46:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 13:46:32 -0000
X-IronPort-AV: E=Sophos;i="4.80,629,1344211200"; d="scan'208";a="15310669"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Oct 2012 13:46:31 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Mon, 22 Oct 2012 14:46:31 +0100
Date: Mon, 22 Oct 2012 14:46:04 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Konrad Rzeszutek Wilk 
In-Reply-To: <1350695882-12820-4-git-send-email-konrad.wilk@oracle.com>
Message-ID: 
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
	<1350695882-12820-4-git-send-email-konrad.wilk@oracle.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Stefano Stabellini ,
	Ian Campbell 
Subject: Re: [Xen-devel] [PATCH 3/6] xen/pvh: Implements mmu changes for PVH.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 20 Oct 2012, Konrad Rzeszutek Wilk wrote:
> From: Mukesh Rathor 
> 
> First the set/clear mmio pte function makes a hypercall to update the
> P2M in Xen with 1:1 mapping. Since PVH uses mostly native mmu ops, we
> leave the generic (native_*) for the rest.
> 
> Two local functions are introduced to add to xen physmap for xen remap
> interface. Xen unmap interface is introduced so the privcmd pte entries
> can be cleared in Xen p2m table.
> 
> Signed-off-by: Mukesh Rathor 
> Signed-off-by: Konrad Rzeszutek Wilk 

this patch looks all right, but I would like to read Ian's feedback too


>  arch/x86/xen/mmu.c    |  162 +++++++++++++++++++++++++++++++++++++++++++++++--
>  arch/x86/xen/mmu.h    |    2 +
>  drivers/xen/privcmd.c |    5 +-
>  include/xen/xen-ops.h |    5 +-
>  4 files changed, 165 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index 6226c99..5747a41 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -74,6 +74,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "multicalls.h"
>  #include "mmu.h"
> @@ -332,6 +333,20 @@ static void xen_set_pte(pte_t *ptep, pte_t pteval)
>  	__xen_set_pte(ptep, pteval);
>  }
>  
> +void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn,
> +			      int nr_mfns, int add_mapping)
> +{
> +	struct physdev_map_iomem iomem;
> +
> +	iomem.first_gfn = pfn;
> +	iomem.first_mfn = mfn;
> +	iomem.nr_mfns = nr_mfns;
> +	iomem.add_mapping = add_mapping;
> +
> +	if (HYPERVISOR_physdev_op(PHYSDEVOP_map_iomem, &iomem))
> +		BUG();
> +}
> +
>  static void xen_set_pte_at(struct mm_struct *mm, unsigned long addr,
>  		    pte_t *ptep, pte_t pteval)
>  {
> @@ -1221,6 +1236,8 @@ static void __init xen_pagetable_init(void)
>  #endif
>  	paging_init();
>  	xen_setup_shared_info();
> +	if (xen_feature(XENFEAT_auto_translated_physmap))
> +		return;
>  #ifdef CONFIG_X86_64
>  	if (!xen_feature(XENFEAT_auto_translated_physmap)) {
>  		unsigned long new_mfn_list;
> @@ -1528,6 +1545,10 @@ static void __init xen_set_pte_init(pte_t *ptep, pte_t pte)
>  static void pin_pagetable_pfn(unsigned cmd, unsigned long pfn)
>  {
>  	struct mmuext_op op;
> +
> +	if (xen_feature(XENFEAT_writable_page_tables))
> +		return;
> +
>  	op.cmd = cmd;
>  	op.arg1.mfn = pfn_to_mfn(pfn);
>  	if (HYPERVISOR_mmuext_op(&op, 1, NULL, DOMID_SELF))
> @@ -1725,6 +1746,10 @@ static void set_page_prot(void *addr, pgprot_t prot)
>  	unsigned long pfn = __pa(addr) >> PAGE_SHIFT;
>  	pte_t pte = pfn_pte(pfn, prot);
>  
> +	/* recall for PVH, page tables are native. */
> +	if (xen_feature(XENFEAT_auto_translated_physmap))
> +		return;
> +
>  	if (HYPERVISOR_update_va_mapping((unsigned long)addr, pte, 0))
>  		BUG();
>  }
> @@ -1802,6 +1827,9 @@ static void convert_pfn_mfn(void *v)
>  	pte_t *pte = v;
>  	int i;
>  
> +	if (xen_feature(XENFEAT_auto_translated_physmap))
> +		return;
> +
>  	/* All levels are converted the same way, so just treat them
>  	   as ptes. */
>  	for (i = 0; i < PTRS_PER_PTE; i++)
> @@ -1821,6 +1849,7 @@ static void __init check_pt_base(unsigned long *pt_base, unsigned long *pt_end,
>  		(*pt_end)--;
>  	}
>  }
> +
>  /*
>   * Set up the initial kernel pagetable.
>   *
> @@ -1831,6 +1860,7 @@ static void __init check_pt_base(unsigned long *pt_base, unsigned long *pt_end,
>   * but that's enough to get __va working.  We need to fill in the rest
>   * of the physical mapping once some sort of allocator has been set
>   * up.
> + * NOTE: for PVH, the page tables are native.
>   */
>  void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn)
>  {
> @@ -1908,10 +1938,13 @@ void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn)
>  	 * structure to attach it to, so make sure we just set kernel
>  	 * pgd.
>  	 */
> -	xen_mc_batch();
> -	__xen_write_cr3(true, __pa(init_level4_pgt));
> -	xen_mc_issue(PARAVIRT_LAZY_CPU);
> -
> +	if (xen_feature(XENFEAT_writable_page_tables)) {
> +		native_write_cr3(__pa(init_level4_pgt));
> +	} else {
> +		xen_mc_batch();
> +		__xen_write_cr3(true, __pa(init_level4_pgt));
> +		xen_mc_issue(PARAVIRT_LAZY_CPU);
> +	}
>  	/* We can't that easily rip out L3 and L2, as the Xen pagetables are
>  	 * set out this way: [L4], [L1], [L2], [L3], [L1], [L1] ...  for
>  	 * the initial domain. For guests using the toolstack, they are in:
> @@ -2178,8 +2211,13 @@ static const struct pv_mmu_ops xen_mmu_ops __initconst = {
>  
>  void __init xen_init_mmu_ops(void)
>  {
> -	x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
>  	x86_init.paging.pagetable_init = xen_pagetable_init;
> +
> +	if (xen_feature(XENFEAT_auto_translated_physmap)) {
> +		pv_mmu_ops.flush_tlb_others = xen_flush_tlb_others;
> +		return;
> +	}
> +	x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
>  	pv_mmu_ops = xen_mmu_ops;
>  
>  	memset(dummy_mapping, 0xff, PAGE_SIZE);
> @@ -2455,6 +2493,89 @@ void __init xen_hvm_init_mmu_ops(void)
>  }
>  #endif
>  
> +/* Map foreign gmfn, fgmfn, to local pfn, lpfn. This for the user space
> + * creating new guest on PVH dom0 and needs to map domU pages.
> + */
> +static int pvh_add_to_xen_p2m(unsigned long lpfn, unsigned long fgmfn,
> +			      unsigned int domid)
> +{
> +	int rc;
> +	struct xen_add_to_physmap xatp = { .foreign_domid = domid };
> +
> +	xatp.gpfn = lpfn;
> +	xatp.idx = fgmfn;
> +	xatp.domid = DOMID_SELF;
> +	xatp.space = XENMAPSPACE_gmfn_foreign;
> +	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
> +	if (rc)
> +		pr_warn("d0: Failed to map pfn (0x%lx) to mfn (0x%lx) rc:%d\n",
> +			lpfn, fgmfn, rc);
> +	return rc;
> +}
> +
> +static int pvh_rem_xen_p2m(unsigned long spfn, int count)
> +{
> +	struct xen_remove_from_physmap xrp;
> +	int i, rc;
> +
> +	for (i = 0; i < count; i++) {
> +		xrp.domid = DOMID_SELF;
> +		xrp.gpfn = spfn+i;
> +		rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, &xrp);
> +		if (rc) {
> +			pr_warn("Failed to unmap pfn:%lx rc:%d done:%d\n",
> +				spfn+i, rc, i);
> +			return 1;
> +		}
> +	}
> +	return 0;
> +}
> +
> +struct pvh_remap_data {
> +	unsigned long fgmfn;		/* foreign domain's gmfn */
> +	pgprot_t prot;
> +	domid_t  domid;
> +	int	 index;
> +	struct page **pages;
> +};
> +
> +static int pvh_map_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr,
> +			void *data)
> +{
> +	int rc;
> +	struct pvh_remap_data *remap = data;
> +	unsigned long pfn = page_to_pfn(remap->pages[remap->index++]);
> +	pte_t pteval = pte_mkspecial(pfn_pte(pfn, remap->prot));
> +
> +	rc = pvh_add_to_xen_p2m(pfn, remap->fgmfn, remap->domid);
> +	if (rc)
> +		return rc;
> +	native_set_pte(ptep, pteval);
> +
> +	return 0;
> +}
> +
> +static int pvh_remap_gmfn_range(struct vm_area_struct *vma,
> +				unsigned long addr, unsigned long mfn, int nr,
> +				pgprot_t prot, unsigned domid,
> +				struct page **pages)
> +{
> +	int err;
> +	struct pvh_remap_data pvhdata;
> +
> +	BUG_ON(!pages);
> +
> +	pvhdata.fgmfn = mfn;
> +	pvhdata.prot = prot;
> +	pvhdata.domid = domid;
> +	pvhdata.index = 0;
> +	pvhdata.pages = pages;
> +	err = apply_to_page_range(vma->vm_mm, addr, nr << PAGE_SHIFT,
> +				  pvh_map_pte_fn, &pvhdata);
> +	flush_tlb_all();
> +	return err;
> +}
> +
>  #define REMAP_BATCH_SIZE 16
>  
>  struct remap_data {
> @@ -2479,7 +2600,9 @@ static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token,
>  int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
>  			       unsigned long addr,
>  			       unsigned long mfn, int nr,
> -			       pgprot_t prot, unsigned domid)
> +			       pgprot_t prot, unsigned domid,
> +			       struct page **pages)
> +
>  {
>  	struct remap_data rmd;
>  	struct mmu_update mmu_update[REMAP_BATCH_SIZE];
> @@ -2494,6 +2617,10 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
>  
>  	BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_IO)) == (VM_PFNMAP | VM_IO)));
>  
> +	if (xen_feature(XENFEAT_auto_translated_physmap)) {
> +		/* We need to update the local page tables and the xen HAP */
> +		return pvh_remap_gmfn_range(vma, addr, mfn, nr, prot, domid, pages);
> +	}
>  	rmd.mfn = mfn;
>  	rmd.prot = prot;
>  
> @@ -2523,3 +2650,26 @@ out:
>  	return err;
>  }
>  EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
> +
> +/* Returns: 0 success */
> +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
> +			       int numpgs, struct page **pages)
> +{
> +	if (!pages || !xen_feature(XENFEAT_auto_translated_physmap))
> +		return 0;
> +
> +	while (numpgs--) {
> +
> +		/* the mmu has already cleaned up the process mmu resources at
> +		 * this point (lookup_address will return NULL). */
> +		unsigned long pfn = page_to_pfn(pages[numpgs]);
> +
> +		pvh_rem_xen_p2m(pfn, 1);
> +	}
> +	/* We don't need to flush tlbs because as part of pvh_rem_xen_p2m(),
> +	 * the hypervisor will do tlb flushes after removing the p2m entries
> +	 * from the EPT/NPT */
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range);
> diff --git a/arch/x86/xen/mmu.h b/arch/x86/xen/mmu.h
> index 73809bb..6d0bb56 100644
> --- a/arch/x86/xen/mmu.h
> +++ b/arch/x86/xen/mmu.h
> @@ -23,4 +23,6 @@ unsigned long xen_read_cr2_direct(void);
>  
>  extern void xen_init_mmu_ops(void);
>  extern void xen_hvm_init_mmu_ops(void);
> +extern void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn,
> +				     int nr_mfns, int add_mapping);
>  #endif	/* _XEN_MMU_H */
> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> index 8adb9cc..b612267 100644
> --- a/drivers/xen/privcmd.c
> +++ b/drivers/xen/privcmd.c
> @@ -178,7 +178,7 @@ static int mmap_mfn_range(void *data, void *state)
>  					msg->va & PAGE_MASK,
>  					msg->mfn, msg->npages,
>  					vma->vm_page_prot,
> -					st->domain);
> +					st->domain, NULL);
>  	if (rc < 0)
>  		return rc;
>  
> @@ -267,7 +267,8 @@ static int mmap_batch_fn(void *data, void *state)
>  	int ret;
>  
>  	ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
> -					 st->vma->vm_page_prot, st->domain);
> +					 st->vma->vm_page_prot, st->domain,
> +					 NULL);
>  
>  	/* Store error code for second pass. */
>  	*(st->err++) = ret;
> diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
> index 6a198e4..990b43e 100644
> --- a/include/xen/xen-ops.h
> +++ b/include/xen/xen-ops.h
> @@ -27,6 +27,9 @@ struct vm_area_struct;
>  int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
>  			       unsigned long addr,
>  			       unsigned long mfn, int nr,
> -			       pgprot_t prot, unsigned domid);
> +			       pgprot_t prot, unsigned domid,
> +			       struct page **pages);
> +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
> +			       int numpgs, struct page **pages);
>  
>  #endif /* INCLUDE_XEN_OPS_H */
> -- 
> 1.7.7.6
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 13:46:57 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 13:46:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQIKw-0001nv-FI; Mon, 22 Oct 2012 13:46:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQIKv-0001nn-Dr
	for xen-devel@lists.xensource.com; Mon, 22 Oct 2012 13:46:33 +0000
Received: from [85.158.143.99:8368] by server-2.bemta-4.messagelabs.com id
	A8/DD-22268-83E45805; Mon, 22 Oct 2012 13:46:32 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1350913591!23828964!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUxNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30631 invoked from network); 22 Oct 2012 13:46:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 13:46:32 -0000
X-IronPort-AV: E=Sophos;i="4.80,629,1344211200"; d="scan'208";a="15310669"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Oct 2012 13:46:31 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Mon, 22 Oct 2012 14:46:31 +0100
Date: Mon, 22 Oct 2012 14:46:04 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Konrad Rzeszutek Wilk 
In-Reply-To: <1350695882-12820-4-git-send-email-konrad.wilk@oracle.com>
Message-ID: 
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
	<1350695882-12820-4-git-send-email-konrad.wilk@oracle.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Stefano Stabellini ,
	Ian Campbell 
Subject: Re: [Xen-devel] [PATCH 3/6] xen/pvh: Implements mmu changes for PVH.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 20 Oct 2012, Konrad Rzeszutek Wilk wrote:
> From: Mukesh Rathor 
> 
> First the set/clear mmio pte function makes a hypercall to update the
> P2M in Xen with 1:1 mapping. Since PVH uses mostly native mmu ops, we
> leave the generic (native_*) for the rest.
> 
> Two local functions are introduced to add to xen physmap for xen remap
> interface. Xen unmap interface is introduced so the privcmd pte entries
> can be cleared in Xen p2m table.
> 
> Signed-off-by: Mukesh Rathor 
> Signed-off-by: Konrad Rzeszutek Wilk 

this patch looks all right, but I would like to read Ian's feedback too


>  arch/x86/xen/mmu.c    |  162 +++++++++++++++++++++++++++++++++++++++++++++++--
>  arch/x86/xen/mmu.h    |    2 +
>  drivers/xen/privcmd.c |    5 +-
>  include/xen/xen-ops.h |    5 +-
>  4 files changed, 165 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index 6226c99..5747a41 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -74,6 +74,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "multicalls.h"
>  #include "mmu.h"
> @@ -332,6 +333,20 @@ static void xen_set_pte(pte_t *ptep, pte_t pteval)
>  	__xen_set_pte(ptep, pteval);
>  }
>  
> +void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn,
> +			      int nr_mfns, int add_mapping)
> +{
> +	struct physdev_map_iomem iomem;
> +
> +	iomem.first_gfn = pfn;
> +	iomem.first_mfn = mfn;
> +	iomem.nr_mfns = nr_mfns;
> +	iomem.add_mapping = add_mapping;
> +
> +	if (HYPERVISOR_physdev_op(PHYSDEVOP_map_iomem, &iomem))
> +		BUG();
> +}
> +
>  static void xen_set_pte_at(struct mm_struct *mm, unsigned long addr,
>  		    pte_t *ptep, pte_t pteval)
>  {
> @@ -1221,6 +1236,8 @@ static void __init xen_pagetable_init(void)
>  #endif
>  	paging_init();
>  	xen_setup_shared_info();
> +	if (xen_feature(XENFEAT_auto_translated_physmap))
> +		return;
>  #ifdef CONFIG_X86_64
>  	if (!xen_feature(XENFEAT_auto_translated_physmap)) {
>  		unsigned long new_mfn_list;
> @@ -1528,6 +1545,10 @@ static void __init xen_set_pte_init(pte_t *ptep, pte_t pte)
>  static void pin_pagetable_pfn(unsigned cmd, unsigned long pfn)
>  {
>  	struct mmuext_op op;
> +
> +	if (xen_feature(XENFEAT_writable_page_tables))
> +		return;
> +
>  	op.cmd = cmd;
>  	op.arg1.mfn = pfn_to_mfn(pfn);
>  	if (HYPERVISOR_mmuext_op(&op, 1, NULL, DOMID_SELF))
> @@ -1725,6 +1746,10 @@ static void set_page_prot(void *addr, pgprot_t prot)
>  	unsigned long pfn = __pa(addr) >> PAGE_SHIFT;
>  	pte_t pte = pfn_pte(pfn, prot);
>  
> +	/* recall for PVH, page tables are native. */
> +	if (xen_feature(XENFEAT_auto_translated_physmap))
> +		return;
> +
>  	if (HYPERVISOR_update_va_mapping((unsigned long)addr, pte, 0))
>  		BUG();
>  }
> @@ -1802,6 +1827,9 @@ static void convert_pfn_mfn(void *v)
>  	pte_t *pte = v;
>  	int i;
>  
> +	if (xen_feature(XENFEAT_auto_translated_physmap))
> +		return;
> +
>  	/* All levels are converted the same way, so just treat them
>  	   as ptes. */
>  	for (i = 0; i < PTRS_PER_PTE; i++)
> @@ -1821,6 +1849,7 @@ static void __init check_pt_base(unsigned long *pt_base, unsigned long *pt_end,
>  		(*pt_end)--;
>  	}
>  }
> +
>  /*
>   * Set up the initial kernel pagetable.
>   *
> @@ -1831,6 +1860,7 @@ static void __init check_pt_base(unsigned long *pt_base, unsigned long *pt_end,
>   * but that's enough to get __va working.  We need to fill in the rest
>   * of the physical mapping once some sort of allocator has been set
>   * up.
> + * NOTE: for PVH, the page tables are native.
>   */
>  void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn)
>  {
> @@ -1908,10 +1938,13 @@ void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn)
>  	 * structure to attach it to, so make sure we just set kernel
>  	 * pgd.
>  	 */
> -	xen_mc_batch();
> -	__xen_write_cr3(true, __pa(init_level4_pgt));
> -	xen_mc_issue(PARAVIRT_LAZY_CPU);
> -
> +	if (xen_feature(XENFEAT_writable_page_tables)) {
> +		native_write_cr3(__pa(init_level4_pgt));
> +	} else {
> +		xen_mc_batch();
> +		__xen_write_cr3(true, __pa(init_level4_pgt));
> +		xen_mc_issue(PARAVIRT_LAZY_CPU);
> +	}
>  	/* We can't that easily rip out L3 and L2, as the Xen pagetables are
>  	 * set out this way: [L4], [L1], [L2], [L3], [L1], [L1] ...  for
>  	 * the initial domain. For guests using the toolstack, they are in:
> @@ -2178,8 +2211,13 @@ static const struct pv_mmu_ops xen_mmu_ops __initconst = {
>  
>  void __init xen_init_mmu_ops(void)
>  {
> -	x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
>  	x86_init.paging.pagetable_init = xen_pagetable_init;
> +
> +	if (xen_feature(XENFEAT_auto_translated_physmap)) {
> +		pv_mmu_ops.flush_tlb_others = xen_flush_tlb_others;
> +		return;
> +	}
> +	x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
>  	pv_mmu_ops = xen_mmu_ops;
>  
>  	memset(dummy_mapping, 0xff, PAGE_SIZE);
> @@ -2455,6 +2493,89 @@ void __init xen_hvm_init_mmu_ops(void)
>  }
>  #endif
>  
> +/* Map foreign gmfn, fgmfn, to local pfn, lpfn. This for the user space
> + * creating new guest on PVH dom0 and needs to map domU pages.
> + */
> +static int pvh_add_to_xen_p2m(unsigned long lpfn, unsigned long fgmfn,
> +			      unsigned int domid)
> +{
> +	int rc;
> +	struct xen_add_to_physmap xatp = { .foreign_domid = domid };
> +
> +	xatp.gpfn = lpfn;
> +	xatp.idx = fgmfn;
> +	xatp.domid = DOMID_SELF;
> +	xatp.space = XENMAPSPACE_gmfn_foreign;
> +	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
> +	if (rc)
> +		pr_warn("d0: Failed to map pfn (0x%lx) to mfn (0x%lx) rc:%d\n",
> +			lpfn, fgmfn, rc);
> +	return rc;
> +}
> +
> +static int pvh_rem_xen_p2m(unsigned long spfn, int count)
> +{
> +	struct xen_remove_from_physmap xrp;
> +	int i, rc;
> +
> +	for (i = 0; i < count; i++) {
> +		xrp.domid = DOMID_SELF;
> +		xrp.gpfn = spfn+i;
> +		rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, &xrp);
> +		if (rc) {
> +			pr_warn("Failed to unmap pfn:%lx rc:%d done:%d\n",
> +				spfn+i, rc, i);
> +			return 1;
> +		}
> +	}
> +	return 0;
> +}
> +
> +struct pvh_remap_data {
> +	unsigned long fgmfn;		/* foreign domain's gmfn */
> +	pgprot_t prot;
> +	domid_t  domid;
> +	int	 index;
> +	struct page **pages;
> +};
> +
> +static int pvh_map_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr,
> +			void *data)
> +{
> +	int rc;
> +	struct pvh_remap_data *remap = data;
> +	unsigned long pfn = page_to_pfn(remap->pages[remap->index++]);
> +	pte_t pteval = pte_mkspecial(pfn_pte(pfn, remap->prot));
> +
> +	rc = pvh_add_to_xen_p2m(pfn, remap->fgmfn, remap->domid);
> +	if (rc)
> +		return rc;
> +	native_set_pte(ptep, pteval);
> +
> +	return 0;
> +}
> +
> +static int pvh_remap_gmfn_range(struct vm_area_struct *vma,
> +				unsigned long addr, unsigned long mfn, int nr,
> +				pgprot_t prot, unsigned domid,
> +				struct page **pages)
> +{
> +	int err;
> +	struct pvh_remap_data pvhdata;
> +
> +	BUG_ON(!pages);
> +
> +	pvhdata.fgmfn = mfn;
> +	pvhdata.prot = prot;
> +	pvhdata.domid = domid;
> +	pvhdata.index = 0;
> +	pvhdata.pages = pages;
> +	err = apply_to_page_range(vma->vm_mm, addr, nr << PAGE_SHIFT,
> +				  pvh_map_pte_fn, &pvhdata);
> +	flush_tlb_all();
> +	return err;
> +}
> +
>  #define REMAP_BATCH_SIZE 16
>  
>  struct remap_data {
> @@ -2479,7 +2600,9 @@ static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token,
>  int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
>  			       unsigned long addr,
>  			       unsigned long mfn, int nr,
> -			       pgprot_t prot, unsigned domid)
> +			       pgprot_t prot, unsigned domid,
> +			       struct page **pages)
> +
>  {
>  	struct remap_data rmd;
>  	struct mmu_update mmu_update[REMAP_BATCH_SIZE];
> @@ -2494,6 +2617,10 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
>  
>  	BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_IO)) == (VM_PFNMAP | VM_IO)));
>  
> +	if (xen_feature(XENFEAT_auto_translated_physmap)) {
> +		/* We need to update the local page tables and the xen HAP */
> +		return pvh_remap_gmfn_range(vma, addr, mfn, nr, prot, domid, pages);
> +	}
>  	rmd.mfn = mfn;
>  	rmd.prot = prot;
>  
> @@ -2523,3 +2650,26 @@ out:
>  	return err;
>  }
>  EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
> +
> +/* Returns: 0 success */
> +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
> +			       int numpgs, struct page **pages)
> +{
> +	if (!pages || !xen_feature(XENFEAT_auto_translated_physmap))
> +		return 0;
> +
> +	while (numpgs--) {
> +
> +		/* the mmu has already cleaned up the process mmu resources at
> +		 * this point (lookup_address will return NULL). */
> +		unsigned long pfn = page_to_pfn(pages[numpgs]);
> +
> +		pvh_rem_xen_p2m(pfn, 1);
> +	}
> +	/* We don't need to flush tlbs because as part of pvh_rem_xen_p2m(),
> +	 * the hypervisor will do tlb flushes after removing the p2m entries
> +	 * from the EPT/NPT */
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range);
> diff --git a/arch/x86/xen/mmu.h b/arch/x86/xen/mmu.h
> index 73809bb..6d0bb56 100644
> --- a/arch/x86/xen/mmu.h
> +++ b/arch/x86/xen/mmu.h
> @@ -23,4 +23,6 @@ unsigned long xen_read_cr2_direct(void);
>  
>  extern void xen_init_mmu_ops(void);
>  extern void xen_hvm_init_mmu_ops(void);
> +extern void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn,
> +				     int nr_mfns, int add_mapping);
>  #endif	/* _XEN_MMU_H */
> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> index 8adb9cc..b612267 100644
> --- a/drivers/xen/privcmd.c
> +++ b/drivers/xen/privcmd.c
> @@ -178,7 +178,7 @@ static int mmap_mfn_range(void *data, void *state)
>  					msg->va & PAGE_MASK,
>  					msg->mfn, msg->npages,
>  					vma->vm_page_prot,
> -					st->domain);
> +					st->domain, NULL);
>  	if (rc < 0)
>  		return rc;
>  
> @@ -267,7 +267,8 @@ static int mmap_batch_fn(void *data, void *state)
>  	int ret;
>  
>  	ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
> -					 st->vma->vm_page_prot, st->domain);
> +					 st->vma->vm_page_prot, st->domain,
> +					 NULL);
>  
>  	/* Store error code for second pass. */
>  	*(st->err++) = ret;
> diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
> index 6a198e4..990b43e 100644
> --- a/include/xen/xen-ops.h
> +++ b/include/xen/xen-ops.h
> @@ -27,6 +27,9 @@ struct vm_area_struct;
>  int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
>  			       unsigned long addr,
>  			       unsigned long mfn, int nr,
> -			       pgprot_t prot, unsigned domid);
> +			       pgprot_t prot, unsigned domid,
> +			       struct page **pages);
> +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
> +			       int numpgs, struct page **pages);
>  
>  #endif /* INCLUDE_XEN_OPS_H */
> -- 
> 1.7.7.6
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 13:47:45 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 13:47:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQILq-0001sm-UF; Mon, 22 Oct 2012 13:47:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQILo-0001sR-RV
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 13:47:29 +0000
Received: from [85.158.137.99:9274] by server-13.bemta-3.messagelabs.com id
	BA/18-26794-07E45805; Mon, 22 Oct 2012 13:47:28 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1350913644!22438386!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21432 invoked from network); 22 Oct 2012 13:47:25 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 13:47:25 -0000
Received: by mail-vc0-f173.google.com with SMTP id fl15so3568631vcb.32
	for ; Mon, 22 Oct 2012 06:47:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=HHUmMHKYmnBCnM1nJAJSJTROjb/8JgO4YREg3wmg7og=;
	b=mPb/jWklChmO3ewE4HzEpaAR4bm7++/lKLe0Ra5pyT6e/yueePqobc0GEOuOEjnKo/
	Dxt7QyqZTw9Qjs2JW/pigYJEVn15wlUpAOean9HzvHkP8xQQ2vP44ai/okZ5HPesXb2I
	ZR4iPsZC4lz8PH2UV4xyKm2IHF2dIkinL5NQGD9PDnqa9/WmW007BSWjZEcfnG3k/fbm
	/J8YoTwtZbrV45Z2JoeDdZZbw64M+rT8nGEpUQpAKhjXe22hhg5DON4TC0ZsbuKBWNAg
	Zsfb6vMiQ7PAGeD0zYhyOgm0YbmrJjez+cVf52Nqb5Mf6fRAlmGttvVr6P8FPo3NTulK
	fmCw==
Received: by 10.220.154.83 with SMTP id n19mr762153vcw.49.1350913643022;
	Mon, 22 Oct 2012 06:47:23 -0700 (PDT)
Received: from konrad-lan.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id k4sm10219943vdg.2.2012.10.22.06.47.19
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 22 Oct 2012 06:47:20 -0700 (PDT)
Date: Mon, 22 Oct 2012 09:47:09 -0400
From: Konrad Rzeszutek Wilk 
To: Roger Pau Monne 
Message-ID: <20121022134708.GA13832@konrad-lan.dumpdata.com>
References: <1350559321-19066-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1350559321-19066-1-git-send-email-roger.pau@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Oliver Chick , konrad.wilk@oracle.com,
	linux-kernel@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH RFC] Persistent grant maps for xen blk
	drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Oct 18, 2012 at 01:22:01PM +0200, Roger Pau Monne wrote:
> This patch implements persistent grants for the xen-blk{front,back}
> mechanism. The effect of this change is to reduce the number of unmap
> operations performed, since they cause a (costly) TLB shootdown. This
> allows the I/O performance to scale better when a large number of VMs
> are performing I/O.
> 
> Previously, the blkfront driver was supplied a bvec[] from the request
> queue. This was granted to dom0; dom0 performed the I/O and wrote
> directly into the grant-mapped memory and unmapped it; blkfront then
> removed foreign access for that grant. The cost of unmapping scales
> badly with the number of CPUs in Dom0. An experiment showed that when
> Dom0 has 24 VCPUs, and guests are performing parallel I/O to a
> ramdisk, the IPIs from performing unmap's is a bottleneck at 5 guests
> (at which point 650,000 IOPS are being performed in total). If more
> than 5 guests are used, the performance declines. By 10 guests, only
> 400,000 IOPS are being performed.
> 
> This patch improves performance by only unmapping when the connection
> between blkfront and back is broken.
> 
> On startup blkfront notifies blkback that it is using persistent
> grants, and blkback will do the same. If blkback is not capable of
> persistent mapping, blkfront will still use the same grants, since it
> is compatible with the previous protocol, and simplifies the code
> complexity in blkfront.
> 
> To perform a read, in persistent mode, blkfront uses a separate pool
> of pages that it maps to dom0. When a request comes in, blkfront
> transmutes the request so that blkback will write into one of these
> free pages. Blkback keeps note of which grefs it has already
> mapped. When a new ring request comes to blkback, it looks to see if
> it has already mapped that page. If so, it will not map it again. If
> the page hasn't been previously mapped, it is mapped now, and a record
> is kept of this mapping. Blkback proceeds as usual. When blkfront is
> notified that blkback has completed a request, it memcpy's from the
> shared memory, into the bvec supplied. A record that the {gref, page}
> tuple is mapped, and not inflight is kept.
> 
> Writes are similar, except that the memcpy is peformed from the
> supplied bvecs, into the shared pages, before the request is put onto
> the ring.
> 
> Blkback stores a mapping of grefs=>{page mapped to by gref} in
> a red-black tree. As the grefs are not known apriori, and provide no
> guarantees on their ordering, we have to perform a search
> through this tree to find the page, for every gref we receive. This
> operation takes O(log n) time in the worst case.

Might want to mention how blkfront stores it as well. It looks
to be using 'llist' instead of 'list'? Any particular reason?

> 
> The maximum number of grants that blkback will persistenly map is
> currently set to RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, to
> prevent a malicios guest from attempting a DoS, by supplying fresh
> grefs, causing the Dom0 kernel to map excessively. If a guest
> is using persistent grants and exceeds the maximum number of grants to
> map persistenly the newly passed grefs will be mapped and unmaped.
> Using this approach, we can have requests that mix persistent and
> non-persistent grants, and we need to handle them correctly.
> This allows us to set the maximum number of persistent grants to a
> lower value than RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, although
> setting it will lead to unpredictable performance.
> 
> In writing this patch, the question arrises as to if the additional
> cost of performing memcpys in the guest (to/from the pool of granted
> pages) outweigh the gains of not performing TLB shootdowns. The answer
> to that question is `no'. There appears to be very little, if any
> additional cost to the guest of using persistent grants. There is
> perhaps a small saving, from the reduced number of hypercalls
> performed in granting, and ending foreign access.
> 
> Signed-off-by: Oliver Chick 
> Signed-off-by: Roger Pau Monne 
> Cc: 
> Cc: 
> ---
> Benchmarks showing the impact of this patch in blk performance can be
> found at:
> 
> http://xenbits.xensource.com/people/royger/persistent_grants/
> ---
>  drivers/block/xen-blkback/blkback.c |  279 +++++++++++++++++++++++++++++++---
>  drivers/block/xen-blkback/common.h  |   17 ++
>  drivers/block/xen-blkback/xenbus.c  |   16 ++-
>  drivers/block/xen-blkfront.c        |  183 ++++++++++++++++++++----
>  4 files changed, 442 insertions(+), 53 deletions(-)
> 
> diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
> index c6decb9..2b982b2 100644
> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -78,6 +78,7 @@ struct pending_req {
>  	unsigned short		operation;
>  	int			status;
>  	struct list_head	free_list;
> +	unsigned int		unmap_seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
>  };
>  
>  #define BLKBACK_INVALID_HANDLE (~0)
> @@ -98,6 +99,30 @@ struct xen_blkbk {
>  static struct xen_blkbk *blkbk;
>  
>  /*
> + * Maximum number of grant pages that can be mapped in blkback.
> + * BLKIF_MAX_SEGMENTS_PER_REQUEST * RING_SIZE is the maximum number of
> + * pages that blkback will persistently map.
> + */
> +static inline unsigned int max_mapped_grant_pages(enum blkif_protocol protocol)
> +{
> +	switch (protocol) {
> +	case BLKIF_PROTOCOL_NATIVE:
> +		return __CONST_RING_SIZE(blkif, PAGE_SIZE) *
> +			   BLKIF_MAX_SEGMENTS_PER_REQUEST;
> +	case BLKIF_PROTOCOL_X86_32:
> +		return __CONST_RING_SIZE(blkif_x86_32, PAGE_SIZE) *
> +			   BLKIF_MAX_SEGMENTS_PER_REQUEST;
> +	case BLKIF_PROTOCOL_X86_64:
> +		return __CONST_RING_SIZE(blkif_x86_64, PAGE_SIZE) *
> +			   BLKIF_MAX_SEGMENTS_PER_REQUEST;

Could you include in the comments what the size (bytes) you expect it to be?
If that would require you re-doing some tests - then don't worry - but
I figured you have some notes scribbled away that have the exact values
down.

> +	default:
> +		BUG();
> +	}
> +	return 0;
> +}
> +
> +
> +/*
>   * Little helpful macro to figure out the index and virtual address of the
>   * pending_pages[..]. For each 'pending_req' we have have up to
>   * BLKIF_MAX_SEGMENTS_PER_REQUEST (11) pages. The seg would be from 0 through
> @@ -128,6 +153,57 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>  static void make_response(struct xen_blkif *blkif, u64 id,
>  			  unsigned short op, int st);
>  
> +#define foreach_grant(pos, rbtree, node) \
> +	for ((pos) = container_of(rb_first((rbtree)), typeof(*(pos)), node); \
> +	     &(pos)->node != NULL; \
> +	     (pos) = container_of(rb_next(&(pos)->node), typeof(*(pos)), node))
> +
> +
> +static void add_persistent_gnt(struct rb_root *root,
> +			       struct persistent_gnt *persistent_gnt)
> +{
> +	struct rb_node **new = &(root->rb_node), *parent = NULL;
> +	struct persistent_gnt *this;
> +
> +	/* Figure out where to put new node */
> +	while (*new) {
> +		this = container_of(*new, struct persistent_gnt, node);
> +
> +		parent = *new;
> +		if (persistent_gnt->gnt < this->gnt)
> +			new = &((*new)->rb_left);
> +		else if (persistent_gnt->gnt > this->gnt)
> +			new = &((*new)->rb_right);
> +		else {
> +			pr_alert(DRV_PFX " trying to add a gref that's already in the tree\n");
> +			BUG();
> +		}
> +	}
> +
> +	/* Add new node and rebalance tree. */
> +	rb_link_node(&(persistent_gnt->node), parent, new);
> +	rb_insert_color(&(persistent_gnt->node), root);
> +}
> +
> +static struct persistent_gnt *get_persistent_gnt(struct rb_root *root,
> +						 grant_ref_t gref)
> +{
> +	struct persistent_gnt *data;
> +	struct rb_node *node = root->rb_node;
> +
> +	while (node) {
> +		data = container_of(node, struct persistent_gnt, node);
> +
> +		if (gref < data->gnt)
> +			node = node->rb_left;
> +		else if (gref > data->gnt)
> +			node = node->rb_right;
> +		else
> +			return data;
> +	}
> +	return NULL;
> +}
> +
>  /*
>   * Retrieve from the 'pending_reqs' a free pending_req structure to be used.
>   */
> @@ -274,6 +350,11 @@ int xen_blkif_schedule(void *arg)
>  {
>  	struct xen_blkif *blkif = arg;
>  	struct xen_vbd *vbd = &blkif->vbd;
> +	struct gnttab_unmap_grant_ref unmap[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct persistent_gnt *persistent_gnt;
> +	int ret = 0;
> +	int segs_to_unmap = 0;
>  
>  	xen_blkif_get(blkif);
>  
> @@ -301,6 +382,32 @@ int xen_blkif_schedule(void *arg)
>  			print_stats(blkif);
>  	}
>  
> +	/* Free all persistent grant pages */
> +	foreach_grant(persistent_gnt, &blkif->persistent_gnts, node) {

Just for sanity - you did check this with blkfronts that did not have
persistent grants enabled, right?

> +		BUG_ON(persistent_gnt->handle == BLKBACK_INVALID_HANDLE);
> +		gnttab_set_unmap_op(&unmap[segs_to_unmap],
> +		    (unsigned long) pfn_to_kaddr(page_to_pfn(
> +			persistent_gnt->page)),
> +		    GNTMAP_host_map,
> +		    persistent_gnt->handle);
> +
> +		pages[segs_to_unmap] = persistent_gnt->page;
> +		rb_erase(&persistent_gnt->node, &blkif->persistent_gnts);
> +		kfree(persistent_gnt);
> +		blkif->persistent_gnt_c--;
> +
> +		if (++segs_to_unmap == BLKIF_MAX_SEGMENTS_PER_REQUEST ||
> +			!rb_next(&persistent_gnt->node)) {
> +			ret = gnttab_unmap_refs(unmap, NULL, pages,
> +						segs_to_unmap);
> +			BUG_ON(ret);
> +			segs_to_unmap = 0;
> +		}
> +	}
> +
> +	BUG_ON(blkif->persistent_gnt_c != 0);
> +	BUG_ON(!RB_EMPTY_ROOT(&blkif->persistent_gnts));
> +
>  	if (log_stats)
>  		print_stats(blkif);
>  
> @@ -327,6 +434,8 @@ static void xen_blkbk_unmap(struct pending_req *req)
>  	int ret;
>  
>  	for (i = 0; i < req->nr_pages; i++) {
> +		if (!req->unmap_seg[i])
> +			continue;

Perhaps there should be a #define for that array..
>  		handle = pending_handle(req, i);
>  		if (handle == BLKBACK_INVALID_HANDLE)
>  			continue;
> @@ -343,12 +452,26 @@ static void xen_blkbk_unmap(struct pending_req *req)
>  
>  static int xen_blkbk_map(struct blkif_request *req,
>  			 struct pending_req *pending_req,
> -			 struct seg_buf seg[])
> +			 struct seg_buf seg[],
> +			 struct page *pages[])
>  {
>  	struct gnttab_map_grant_ref map[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> -	int i;
> +	struct persistent_gnt *persistent_gnts[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct page *pages_to_gnt[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct persistent_gnt *persistent_gnt = NULL;
> +	struct xen_blkif *blkif = pending_req->blkif;
> +	phys_addr_t addr = 0;
> +	int i, j;
> +	int new_map;

Just use a bool for this.
>  	int nseg = req->u.rw.nr_segments;
> +	int segs_to_map = 0;
>  	int ret = 0;
> +	int use_persistent_gnts;
> +
> +	use_persistent_gnts = (blkif->vbd.feature_gnt_persistent);
> +
> +	BUG_ON(blkif->persistent_gnt_c >
> +		   max_mapped_grant_pages(pending_req->blkif->blk_protocol));
>  
>  	/*
>  	 * Fill out preq.nr_sects with proper amount of sectors, and setup
> @@ -358,36 +481,141 @@ static int xen_blkbk_map(struct blkif_request *req,
>  	for (i = 0; i < nseg; i++) {
>  		uint32_t flags;
>  
> -		flags = GNTMAP_host_map;
> -		if (pending_req->operation != BLKIF_OP_READ)
> -			flags |= GNTMAP_readonly;
> -		gnttab_set_map_op(&map[i], vaddr(pending_req, i), flags,
> -				  req->u.rw.seg[i].gref,
> -				  pending_req->blkif->domid);
> +		if (use_persistent_gnts)
> +			persistent_gnt = get_persistent_gnt(
> +				&blkif->persistent_gnts,
> +				req->u.rw.seg[i].gref);
> +
> +		if (persistent_gnt) {
> +			/*
> +			 * We are using persistent grants and
> +			 * the grant is already mapped
> +			 */
> +			new_map = 0;
> +		} else if (use_persistent_gnts &&
> +			   blkif->persistent_gnt_c <
> +			   max_mapped_grant_pages(blkif->blk_protocol)) {
> +			/*
> +			 * We are using persistent grants, the grant is
> +			 * not mapped but we have room for it
> +			 */
> +			new_map = 1;
> +			persistent_gnt = kzalloc(
> +				sizeof(struct persistent_gnt),
> +				GFP_KERNEL);
> +			if (!persistent_gnt)
> +				return -ENOMEM;
> +			persistent_gnt->page = alloc_page(GFP_KERNEL);
> +			if (!persistent_gnt->page) {
> +				kfree(persistent_gnt);
> +				return -ENOMEM;
> +			}
> +			persistent_gnt->gnt = req->u.rw.seg[i].gref;
> +
> +			pages_to_gnt[segs_to_map] =
> +				persistent_gnt->page;
> +			addr = (unsigned long) pfn_to_kaddr(
> +				page_to_pfn(persistent_gnt->page));
> +
> +			add_persistent_gnt(&blkif->persistent_gnts,
> +				persistent_gnt);
> +			blkif->persistent_gnt_c++;
> +			pr_debug(DRV_PFX " grant %u added to the tree of persistent grants, using %u/%u\n",
> +				 persistent_gnt->gnt, blkif->persistent_gnt_c,
> +				 max_mapped_grant_pages(blkif->blk_protocol));
> +		} else {
> +			/*
> +			 * We are either using persistent grants and
> +			 * hit the maximum limit of grants mapped,
> +			 * or we are not using persistent grants.
> +			 */
> +			if (use_persistent_gnts &&
> +				!blkif->vbd.overflow_max_grants) {
> +				blkif->vbd.overflow_max_grants = 1;
> +				pr_alert(DRV_PFX " domain %u, device %#x is using maximum number of persistent grants\n",
> +					 blkif->domid, blkif->vbd.handle);
> +			}
> +			new_map = 1;
> +			pages[i] = blkbk->pending_page(pending_req, i);
> +			addr = vaddr(pending_req, i);
> +			pages_to_gnt[segs_to_map] =
> +				blkbk->pending_page(pending_req, i);
> +		}
> +
> +		if (persistent_gnt) {
> +			pages[i] = persistent_gnt->page;
> +			persistent_gnts[i] = persistent_gnt;
> +		} else {
> +			persistent_gnts[i] = NULL;
> +		}
> +
> +		if (new_map) {
> +			flags = GNTMAP_host_map;
> +			if (!persistent_gnt &&
> +			    (pending_req->operation != BLKIF_OP_READ))
> +				flags |= GNTMAP_readonly;
> +			gnttab_set_map_op(&map[segs_to_map++], addr,
> +					  flags, req->u.rw.seg[i].gref,
> +					  blkif->domid);
> +		}
>  	}
>  
> -	ret = gnttab_map_refs(map, NULL, &blkbk->pending_page(pending_req, 0), nseg);
> -	BUG_ON(ret);
> +	if (segs_to_map) {
> +		ret = gnttab_map_refs(map, NULL, pages_to_gnt, segs_to_map);
> +		BUG_ON(ret);
> +	}
>  
>  	/*
>  	 * Now swizzle the MFN in our domain with the MFN from the other domain
>  	 * so that when we access vaddr(pending_req,i) it has the contents of
>  	 * the page from the other domain.
>  	 */
> -	for (i = 0; i < nseg; i++) {
> -		if (unlikely(map[i].status != 0)) {
> -			pr_debug(DRV_PFX "invalid buffer -- could not remap it\n");
> -			map[i].handle = BLKBACK_INVALID_HANDLE;
> -			ret |= 1;
> +	for (i = 0, j = 0; i < nseg; i++) {
> +		if (!persistent_gnts[i] || !persistent_gnts[i]->handle) {
> +			/* This is a newly mapped grant */
> +			BUG_ON(j >= segs_to_map);
> +			if (unlikely(map[j].status != 0)) {

I am not seeing j being incremented anywhere? Should it?

> +				pr_debug(DRV_PFX "invalid buffer -- could not remap it\n");
> +				map[j].handle = BLKBACK_INVALID_HANDLE;
> +				ret |= 1;
> +				if (persistent_gnts[i]) {
> +					rb_erase(&persistent_gnts[i]->node,
> +						 &blkif->persistent_gnts);
> +					blkif->persistent_gnt_c--;
> +					kfree(persistent_gnts[i]);
> +					persistent_gnts[i] = NULL;
> +				}
> +			}
> +		}
> +		if (persistent_gnts[i]) {
> +			if (!persistent_gnts[i]->handle) {
> +				/*
> +				 * If this is a new persistent grant
> +				 * save the handler
> +				 */
> +				persistent_gnts[i]->handle = map[j].handle;
> +				persistent_gnts[i]->dev_bus_addr =
> +					map[j++].dev_bus_addr;
> +			}
> +			pending_handle(pending_req, i) =
> +				persistent_gnts[i]->handle;
> +			pending_req->unmap_seg[i] = 0;

Could we have a #define for that?
> +
> +			if (ret)
> +				continue;
> +
> +			seg[i].buf = persistent_gnts[i]->dev_bus_addr |
> +				(req->u.rw.seg[i].first_sect << 9);
> +		} else {
> +			pending_handle(pending_req, i) = map[j].handle;
> +			pending_req->unmap_seg[i] = 1;

And here as well?
> +
> +			if (ret)
> +				continue;
> +
> +			seg[i].buf = map[j++].dev_bus_addr |
> +				(req->u.rw.seg[i].first_sect << 9);
>  		}
> -
> -		pending_handle(pending_req, i) = map[i].handle;
> -
> -		if (ret)
> -			continue;
> -
> -		seg[i].buf  = map[i].dev_bus_addr |
> -			(req->u.rw.seg[i].first_sect << 9);
>  	}
>  	return ret;
>  }
> @@ -590,6 +818,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>  	int operation;
>  	struct blk_plug plug;
>  	bool drain = false;
> +	struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
>  
>  	switch (req->operation) {
>  	case BLKIF_OP_READ:
> @@ -676,7 +905,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>  	 * the hypercall to unmap the grants - that is all done in
>  	 * xen_blkbk_unmap.
>  	 */
> -	if (xen_blkbk_map(req, pending_req, seg))
> +	if (xen_blkbk_map(req, pending_req, seg, pages))
>  		goto fail_flush;
>  
>  	/*
> @@ -688,7 +917,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>  	for (i = 0; i < nseg; i++) {
>  		while ((bio == NULL) ||
>  		       (bio_add_page(bio,
> -				     blkbk->pending_page(pending_req, i),
> +				     pages[i],
>  				     seg[i].nsec << 9,
>  				     seg[i].buf & ~PAGE_MASK) == 0)) {
>  
> diff --git a/drivers/block/xen-blkback/common.h b/drivers/block/xen-blkback/common.h
> index 9ad3b5e..6c08ee9 100644
> --- a/drivers/block/xen-blkback/common.h
> +++ b/drivers/block/xen-blkback/common.h
> @@ -34,6 +34,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -160,10 +161,22 @@ struct xen_vbd {
>  	sector_t		size;
>  	bool			flush_support;
>  	bool			discard_secure;
> +
> +	unsigned int		feature_gnt_persistent:1;
> +	unsigned int		overflow_max_grants:1;

I think the v3.7-rc1 has this structure changed just a tiny bit, so you
might want to rebase it on top of that.

>  };
>  
>  struct backend_info;
>  
> +
> +struct persistent_gnt {
> +	struct page *page;
> +	grant_ref_t gnt;
> +	grant_handle_t handle;
> +	uint64_t dev_bus_addr;
> +	struct rb_node node;
> +};
> +
>  struct xen_blkif {
>  	/* Unique identifier for this interface. */
>  	domid_t			domid;
> @@ -190,6 +203,10 @@ struct xen_blkif {
>  	struct task_struct	*xenblkd;
>  	unsigned int		waiting_reqs;
>  
> +	/* frontend feature information */

Huh?

> +	struct rb_root		persistent_gnts;
> +	unsigned int		persistent_gnt_c;
> +
>  	/* statistics */
>  	unsigned long		st_print;
>  	int			st_rd_req;
> diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c
> index 4f66171..9f88b4e 100644
> --- a/drivers/block/xen-blkback/xenbus.c
> +++ b/drivers/block/xen-blkback/xenbus.c
> @@ -118,6 +118,7 @@ static struct xen_blkif *xen_blkif_alloc(domid_t domid)
>  	atomic_set(&blkif->drain, 0);
>  	blkif->st_print = jiffies;
>  	init_waitqueue_head(&blkif->waiting_to_free);
> +	blkif->persistent_gnts.rb_node = NULL;
>  
>  	return blkif;
>  }
> @@ -721,6 +722,7 @@ static int connect_ring(struct backend_info *be)
>  	struct xenbus_device *dev = be->dev;
>  	unsigned long ring_ref;
>  	unsigned int evtchn;
> +	unsigned int pers_grants;
>  	char protocol[64] = "";
>  	int err;
>  
> @@ -750,8 +752,18 @@ static int connect_ring(struct backend_info *be)
>  		xenbus_dev_fatal(dev, err, "unknown fe protocol %s", protocol);
>  		return -1;
>  	}
> -	pr_info(DRV_PFX "ring-ref %ld, event-channel %d, protocol %d (%s)\n",
> -		ring_ref, evtchn, be->blkif->blk_protocol, protocol);
> +	err = xenbus_gather(XBT_NIL, dev->otherend,
> +			    "feature-persistent-grants", "%u",
> +			    &pers_grants, NULL);
> +	if (err)
> +		pers_grants = 0;
> +
> +	be->blkif->vbd.feature_gnt_persistent = pers_grants;
> +	be->blkif->vbd.overflow_max_grants = 0;
> +
> +	pr_info(DRV_PFX "ring-ref %ld, event-channel %d, protocol %d (%s) persistent %d\n",
> +		ring_ref, evtchn, be->blkif->blk_protocol, protocol,
> +		pers_grants);

Can you make that a string? So it is
 pers_grants ? "persistent grants" : ""

instead of a zero of one value pls?
>  
>  	/* Map the shared frame, irq etc. */
>  	err = xen_blkif_map(be->blkif, ring_ref, evtchn);
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 2c2d2e5..206d422 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -44,6 +44,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -64,10 +65,17 @@ enum blkif_state {
>  	BLKIF_STATE_SUSPENDED,
>  };
>  
> +struct grant {
> +	grant_ref_t gref;
> +	unsigned long pfn;
> +	struct llist_node node;
> +};
> +
>  struct blk_shadow {
>  	struct blkif_request req;
>  	struct request *request;
>  	unsigned long frame[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct grant *grants_used[BLKIF_MAX_SEGMENTS_PER_REQUEST];
>  };
>  
>  static DEFINE_MUTEX(blkfront_mutex);
> @@ -97,6 +105,8 @@ struct blkfront_info
>  	struct work_struct work;
>  	struct gnttab_free_callback callback;
>  	struct blk_shadow shadow[BLK_RING_SIZE];
> +	struct llist_head persistent_gnts;
> +	unsigned int persistent_gnts_c;
>  	unsigned long shadow_free;
>  	unsigned int feature_flush;
>  	unsigned int flush_op;
> @@ -287,21 +297,36 @@ static int blkif_queue_request(struct request *req)
>  	unsigned long id;
>  	unsigned int fsect, lsect;
>  	int i, ref;
> +
> +	/*
> +	 * Used to store if we are able to queue the request by just using
> +	 * existing persistent grants (0), or if we have to get new grants,

What does the zero mean?
> +	 * as there are not sufficiently many free.
> +	 */
> +	int new_persistent_gnts;

I think this can be a bool?
>  	grant_ref_t gref_head;
> +	struct page *granted_page;
> +	struct grant *gnt_list_entry = NULL;
>  	struct scatterlist *sg;
>  
>  	if (unlikely(info->connected != BLKIF_STATE_CONNECTED))
>  		return 1;
>  
> -	if (gnttab_alloc_grant_references(
> -		BLKIF_MAX_SEGMENTS_PER_REQUEST, &gref_head) < 0) {
> -		gnttab_request_free_callback(
> -			&info->callback,
> -			blkif_restart_queue_callback,
> -			info,
> -			BLKIF_MAX_SEGMENTS_PER_REQUEST);
> -		return 1;
> -	}
> +	/* Check if we have enought grants to allocate a requests */
> +	if (info->persistent_gnts_c < BLKIF_MAX_SEGMENTS_PER_REQUEST) {
> +		new_persistent_gnts = 1;
> +		if (gnttab_alloc_grant_references(
> +		    BLKIF_MAX_SEGMENTS_PER_REQUEST - info->persistent_gnts_c,
> +		    &gref_head) < 0) {
> +			gnttab_request_free_callback(
> +				&info->callback,
> +				blkif_restart_queue_callback,
> +				info,
> +				BLKIF_MAX_SEGMENTS_PER_REQUEST);
> +			return 1;
> +		}
> +	} else
> +		new_persistent_gnts = 0;
>  
>  	/* Fill out a communications ring structure. */
>  	ring_req = RING_GET_REQUEST(&info->ring, info->ring.req_prod_pvt);
> @@ -341,18 +366,73 @@ static int blkif_queue_request(struct request *req)
>  		       BLKIF_MAX_SEGMENTS_PER_REQUEST);
>  
>  		for_each_sg(info->sg, sg, ring_req->u.rw.nr_segments, i) {
> -			buffer_mfn = pfn_to_mfn(page_to_pfn(sg_page(sg)));
>  			fsect = sg->offset >> 9;
>  			lsect = fsect + (sg->length >> 9) - 1;
> -			/* install a grant reference. */
> -			ref = gnttab_claim_grant_reference(&gref_head);
> -			BUG_ON(ref == -ENOSPC);
>  
> -			gnttab_grant_foreign_access_ref(
> -					ref,
> +			if (info->persistent_gnts_c) {
> +				BUG_ON(llist_empty(&info->persistent_gnts));
> +				gnt_list_entry = llist_entry(
> +					llist_del_first(&info->persistent_gnts),
> +					struct grant, node);
> +
> +				ref = gnt_list_entry->gref;
> +				buffer_mfn = pfn_to_mfn(gnt_list_entry->pfn);
> +				info->persistent_gnts_c--;
> +			} else {
> +				ref = gnttab_claim_grant_reference(&gref_head);
> +				BUG_ON(ref == -ENOSPC);
> +
> +				gnt_list_entry =
> +					kmalloc(sizeof(struct grant),
> +							 GFP_ATOMIC);
> +				if (!gnt_list_entry)
> +					return -ENOMEM;
> +
> +				granted_page = alloc_page(GFP_ATOMIC);
> +				if (!granted_page) {
> +					kfree(gnt_list_entry);
> +					return -ENOMEM;
> +				}
> +
> +				gnt_list_entry->pfn =
> +					page_to_pfn(granted_page);
> +				gnt_list_entry->gref = ref;
> +
> +				buffer_mfn = pfn_to_mfn(page_to_pfn(
> +								granted_page));
> +				gnttab_grant_foreign_access_ref(ref,
>  					info->xbdev->otherend_id,
> -					buffer_mfn,
> -					rq_data_dir(req));
> +					buffer_mfn, 0);
> +			}
> +
> +			info->shadow[id].grants_used[i] = gnt_list_entry;
> +
> +			if (rq_data_dir(req)) {
> +				char *bvec_data;
> +				void *shared_data;
> +
> +				BUG_ON(sg->offset + sg->length > PAGE_SIZE);
> +
> +				shared_data = kmap_atomic(
> +					pfn_to_page(gnt_list_entry->pfn));
> +				bvec_data = kmap_atomic(sg_page(sg));
> +
> +				/*
> +				 * this does not wipe data stored outside the
> +				 * range sg->offset..sg->offset+sg->length.
> +				 * Therefore, blkback *could* see data from
> +				 * previous requests. This is OK as long as
> +				 * persistent grants are shared with just one
> +				 * domain. It may need refactoring if This
.. this (lowercase it pls)

> +				 * changes
> +				 */
> +				memcpy(shared_data + sg->offset,
> +				       bvec_data   + sg->offset,
> +				       sg->length);
> +
> +				kunmap_atomic(bvec_data);
> +				kunmap_atomic(shared_data);
> +			}
>  
>  			info->shadow[id].frame[i] = mfn_to_pfn(buffer_mfn);
>  			ring_req->u.rw.seg[i] =
> @@ -368,7 +448,8 @@ static int blkif_queue_request(struct request *req)
>  	/* Keep a private copy so we can reissue requests when recovering. */
>  	info->shadow[id].req = *ring_req;
>  
> -	gnttab_free_grant_references(gref_head);
> +	if (new_persistent_gnts)
> +		gnttab_free_grant_references(gref_head);
>  
>  	return 0;
>  }
> @@ -480,7 +561,7 @@ static int xlvbd_init_blk_queue(struct gendisk *gd, u16 sector_size)
>  static void xlvbd_flush(struct blkfront_info *info)
>  {
>  	blk_queue_flush(info->rq, info->feature_flush);
> -	printk(KERN_INFO "blkfront: %s: %s: %s\n",
> +	printk(KERN_INFO "blkfront: %s: %s: %s, using persistent grants\n",

HA! By default, eh?
>  	       info->gd->disk_name,
>  	       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
>  		"barrier" : (info->flush_op == BLKIF_OP_FLUSH_DISKCACHE ?
> @@ -707,6 +788,9 @@ static void blkif_restart_queue(struct work_struct *work)
>  
>  static void blkif_free(struct blkfront_info *info, int suspend)
>  {
> +	struct llist_node *all_gnts;
> +	struct grant *persistent_gnt;
> +
>  	/* Prevent new requests being issued until we fix things up. */
>  	spin_lock_irq(&info->io_lock);
>  	info->connected = suspend ?
> @@ -714,6 +798,17 @@ static void blkif_free(struct blkfront_info *info, int suspend)
>  	/* No more blkif_request(). */
>  	if (info->rq)
>  		blk_stop_queue(info->rq);
> +
> +	/* Remove all persistent grants */
> +	if (info->persistent_gnts_c) {
> +		all_gnts = llist_del_all(&info->persistent_gnts);
> +		llist_for_each_entry(persistent_gnt, all_gnts, node) {
> +			gnttab_end_foreign_access(persistent_gnt->gref, 0, 0UL);
> +			kfree(persistent_gnt);
> +		}
> +		info->persistent_gnts_c = 0;
> +	}
> +
>  	/* No more gnttab callback work. */
>  	gnttab_cancel_free_callback(&info->callback);
>  	spin_unlock_irq(&info->io_lock);
> @@ -734,13 +829,42 @@ static void blkif_free(struct blkfront_info *info, int suspend)
>  
>  }
>  
> -static void blkif_completion(struct blk_shadow *s)
> +static void blkif_completion(struct blk_shadow *s, struct blkfront_info *info,
> +			     struct blkif_response *bret)
>  {
>  	int i;
> -	/* Do not let BLKIF_OP_DISCARD as nr_segment is in the same place
> -	 * flag. */
> -	for (i = 0; i < s->req.u.rw.nr_segments; i++)
> -		gnttab_end_foreign_access(s->req.u.rw.seg[i].gref, 0, 0UL);
> +	struct bio_vec *bvec;
> +	struct req_iterator iter;
> +	unsigned long flags;
> +	char *bvec_data;
> +	void *shared_data;
> +	unsigned int offset = 0;
> +
> +	if (bret->operation == BLKIF_OP_READ) {
> +		/*
> +		 * Copy the data received from the backend into the bvec.
> +		 * Since bv_len can be different from PAGE_SIZE, we need to
> +		 * be sure we are actually copying the data from the right
> +		 * shared page.
> +		 */
> +		rq_for_each_segment(bvec, s->request, iter) {
> +			BUG_ON((bvec->bv_offset + bvec->bv_len) > PAGE_SIZE);
> +			i = offset >> PAGE_SHIFT;

Could you also include a comment about the bug you found here, pls?
> +			shared_data = kmap_atomic(
> +				pfn_to_page(s->grants_used[i]->pfn));
> +			bvec_data = bvec_kmap_irq(bvec, &flags);
> +			memcpy(bvec_data, shared_data + bvec->bv_offset,
> +				bvec->bv_len);
> +			bvec_kunmap_irq(bvec_data, &flags);
> +			kunmap_atomic(shared_data);
> +			offset += bvec->bv_len;
> +		}
> +	}
> +	/* Add the persistent grant into the list of free grants */
> +	for (i = 0; i < s->req.u.rw.nr_segments; i++) {
> +		llist_add(&s->grants_used[i]->node, &info->persistent_gnts);
> +		info->persistent_gnts_c++;
> +	}
>  }
>  
>  static irqreturn_t blkif_interrupt(int irq, void *dev_id)
> @@ -783,7 +907,7 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
>  		req  = info->shadow[id].request;
>  
>  		if (bret->operation != BLKIF_OP_DISCARD)
> -			blkif_completion(&info->shadow[id]);
> +			blkif_completion(&info->shadow[id], info, bret);
>  
>  		if (add_id_to_freelist(info, id)) {
>  			WARN(1, "%s: response to %s (id %ld) couldn't be recycled!\n",
> @@ -942,6 +1066,11 @@ again:
>  		message = "writing protocol";
>  		goto abort_transaction;
>  	}
> +	err = xenbus_printf(xbt, dev->nodename,
> +			    "feature-persistent-grants", "%d", 1);

So its %u in blkback, but %d in here? Which one should it be?

> +	if (err)
> +		dev_warn(&dev->dev,
> +			 "writing persistent grants feature to xenbus");
>  
>  	err = xenbus_transaction_end(xbt, 0);
>  	if (err) {
> @@ -1029,6 +1158,8 @@ static int blkfront_probe(struct xenbus_device *dev,
>  	spin_lock_init(&info->io_lock);
>  	info->xbdev = dev;
>  	info->vdevice = vdevice;
> +	init_llist_head(&info->persistent_gnts);
> +	info->persistent_gnts_c = 0;
>  	info->connected = BLKIF_STATE_DISCONNECTED;
>  	INIT_WORK(&info->work, blkif_restart_queue);
>  
> @@ -1093,7 +1224,7 @@ static int blkif_recover(struct blkfront_info *info)
>  					req->u.rw.seg[j].gref,
>  					info->xbdev->otherend_id,
>  					pfn_to_mfn(info->shadow[req->u.rw.id].frame[j]),
> -					rq_data_dir(info->shadow[req->u.rw.id].request));
> +					0);
>  		}
>  		info->shadow[req->u.rw.id].req = *req;
>  
> -- 
> 1.7.7.5 (Apple Git-26)
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 13:47:45 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 13:47:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQILq-0001sm-UF; Mon, 22 Oct 2012 13:47:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQILo-0001sR-RV
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 13:47:29 +0000
Received: from [85.158.137.99:9274] by server-13.bemta-3.messagelabs.com id
	BA/18-26794-07E45805; Mon, 22 Oct 2012 13:47:28 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1350913644!22438386!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21432 invoked from network); 22 Oct 2012 13:47:25 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 13:47:25 -0000
Received: by mail-vc0-f173.google.com with SMTP id fl15so3568631vcb.32
	for ; Mon, 22 Oct 2012 06:47:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=HHUmMHKYmnBCnM1nJAJSJTROjb/8JgO4YREg3wmg7og=;
	b=mPb/jWklChmO3ewE4HzEpaAR4bm7++/lKLe0Ra5pyT6e/yueePqobc0GEOuOEjnKo/
	Dxt7QyqZTw9Qjs2JW/pigYJEVn15wlUpAOean9HzvHkP8xQQ2vP44ai/okZ5HPesXb2I
	ZR4iPsZC4lz8PH2UV4xyKm2IHF2dIkinL5NQGD9PDnqa9/WmW007BSWjZEcfnG3k/fbm
	/J8YoTwtZbrV45Z2JoeDdZZbw64M+rT8nGEpUQpAKhjXe22hhg5DON4TC0ZsbuKBWNAg
	Zsfb6vMiQ7PAGeD0zYhyOgm0YbmrJjez+cVf52Nqb5Mf6fRAlmGttvVr6P8FPo3NTulK
	fmCw==
Received: by 10.220.154.83 with SMTP id n19mr762153vcw.49.1350913643022;
	Mon, 22 Oct 2012 06:47:23 -0700 (PDT)
Received: from konrad-lan.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id k4sm10219943vdg.2.2012.10.22.06.47.19
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 22 Oct 2012 06:47:20 -0700 (PDT)
Date: Mon, 22 Oct 2012 09:47:09 -0400
From: Konrad Rzeszutek Wilk 
To: Roger Pau Monne 
Message-ID: <20121022134708.GA13832@konrad-lan.dumpdata.com>
References: <1350559321-19066-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1350559321-19066-1-git-send-email-roger.pau@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Oliver Chick , konrad.wilk@oracle.com,
	linux-kernel@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH RFC] Persistent grant maps for xen blk
	drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Oct 18, 2012 at 01:22:01PM +0200, Roger Pau Monne wrote:
> This patch implements persistent grants for the xen-blk{front,back}
> mechanism. The effect of this change is to reduce the number of unmap
> operations performed, since they cause a (costly) TLB shootdown. This
> allows the I/O performance to scale better when a large number of VMs
> are performing I/O.
> 
> Previously, the blkfront driver was supplied a bvec[] from the request
> queue. This was granted to dom0; dom0 performed the I/O and wrote
> directly into the grant-mapped memory and unmapped it; blkfront then
> removed foreign access for that grant. The cost of unmapping scales
> badly with the number of CPUs in Dom0. An experiment showed that when
> Dom0 has 24 VCPUs, and guests are performing parallel I/O to a
> ramdisk, the IPIs from performing unmap's is a bottleneck at 5 guests
> (at which point 650,000 IOPS are being performed in total). If more
> than 5 guests are used, the performance declines. By 10 guests, only
> 400,000 IOPS are being performed.
> 
> This patch improves performance by only unmapping when the connection
> between blkfront and back is broken.
> 
> On startup blkfront notifies blkback that it is using persistent
> grants, and blkback will do the same. If blkback is not capable of
> persistent mapping, blkfront will still use the same grants, since it
> is compatible with the previous protocol, and simplifies the code
> complexity in blkfront.
> 
> To perform a read, in persistent mode, blkfront uses a separate pool
> of pages that it maps to dom0. When a request comes in, blkfront
> transmutes the request so that blkback will write into one of these
> free pages. Blkback keeps note of which grefs it has already
> mapped. When a new ring request comes to blkback, it looks to see if
> it has already mapped that page. If so, it will not map it again. If
> the page hasn't been previously mapped, it is mapped now, and a record
> is kept of this mapping. Blkback proceeds as usual. When blkfront is
> notified that blkback has completed a request, it memcpy's from the
> shared memory, into the bvec supplied. A record that the {gref, page}
> tuple is mapped, and not inflight is kept.
> 
> Writes are similar, except that the memcpy is peformed from the
> supplied bvecs, into the shared pages, before the request is put onto
> the ring.
> 
> Blkback stores a mapping of grefs=>{page mapped to by gref} in
> a red-black tree. As the grefs are not known apriori, and provide no
> guarantees on their ordering, we have to perform a search
> through this tree to find the page, for every gref we receive. This
> operation takes O(log n) time in the worst case.

Might want to mention how blkfront stores it as well. It looks
to be using 'llist' instead of 'list'? Any particular reason?

> 
> The maximum number of grants that blkback will persistenly map is
> currently set to RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, to
> prevent a malicios guest from attempting a DoS, by supplying fresh
> grefs, causing the Dom0 kernel to map excessively. If a guest
> is using persistent grants and exceeds the maximum number of grants to
> map persistenly the newly passed grefs will be mapped and unmaped.
> Using this approach, we can have requests that mix persistent and
> non-persistent grants, and we need to handle them correctly.
> This allows us to set the maximum number of persistent grants to a
> lower value than RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, although
> setting it will lead to unpredictable performance.
> 
> In writing this patch, the question arrises as to if the additional
> cost of performing memcpys in the guest (to/from the pool of granted
> pages) outweigh the gains of not performing TLB shootdowns. The answer
> to that question is `no'. There appears to be very little, if any
> additional cost to the guest of using persistent grants. There is
> perhaps a small saving, from the reduced number of hypercalls
> performed in granting, and ending foreign access.
> 
> Signed-off-by: Oliver Chick 
> Signed-off-by: Roger Pau Monne 
> Cc: 
> Cc: 
> ---
> Benchmarks showing the impact of this patch in blk performance can be
> found at:
> 
> http://xenbits.xensource.com/people/royger/persistent_grants/
> ---
>  drivers/block/xen-blkback/blkback.c |  279 +++++++++++++++++++++++++++++++---
>  drivers/block/xen-blkback/common.h  |   17 ++
>  drivers/block/xen-blkback/xenbus.c  |   16 ++-
>  drivers/block/xen-blkfront.c        |  183 ++++++++++++++++++++----
>  4 files changed, 442 insertions(+), 53 deletions(-)
> 
> diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
> index c6decb9..2b982b2 100644
> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -78,6 +78,7 @@ struct pending_req {
>  	unsigned short		operation;
>  	int			status;
>  	struct list_head	free_list;
> +	unsigned int		unmap_seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
>  };
>  
>  #define BLKBACK_INVALID_HANDLE (~0)
> @@ -98,6 +99,30 @@ struct xen_blkbk {
>  static struct xen_blkbk *blkbk;
>  
>  /*
> + * Maximum number of grant pages that can be mapped in blkback.
> + * BLKIF_MAX_SEGMENTS_PER_REQUEST * RING_SIZE is the maximum number of
> + * pages that blkback will persistently map.
> + */
> +static inline unsigned int max_mapped_grant_pages(enum blkif_protocol protocol)
> +{
> +	switch (protocol) {
> +	case BLKIF_PROTOCOL_NATIVE:
> +		return __CONST_RING_SIZE(blkif, PAGE_SIZE) *
> +			   BLKIF_MAX_SEGMENTS_PER_REQUEST;
> +	case BLKIF_PROTOCOL_X86_32:
> +		return __CONST_RING_SIZE(blkif_x86_32, PAGE_SIZE) *
> +			   BLKIF_MAX_SEGMENTS_PER_REQUEST;
> +	case BLKIF_PROTOCOL_X86_64:
> +		return __CONST_RING_SIZE(blkif_x86_64, PAGE_SIZE) *
> +			   BLKIF_MAX_SEGMENTS_PER_REQUEST;

Could you include in the comments what the size (bytes) you expect it to be?
If that would require you re-doing some tests - then don't worry - but
I figured you have some notes scribbled away that have the exact values
down.

> +	default:
> +		BUG();
> +	}
> +	return 0;
> +}
> +
> +
> +/*
>   * Little helpful macro to figure out the index and virtual address of the
>   * pending_pages[..]. For each 'pending_req' we have have up to
>   * BLKIF_MAX_SEGMENTS_PER_REQUEST (11) pages. The seg would be from 0 through
> @@ -128,6 +153,57 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>  static void make_response(struct xen_blkif *blkif, u64 id,
>  			  unsigned short op, int st);
>  
> +#define foreach_grant(pos, rbtree, node) \
> +	for ((pos) = container_of(rb_first((rbtree)), typeof(*(pos)), node); \
> +	     &(pos)->node != NULL; \
> +	     (pos) = container_of(rb_next(&(pos)->node), typeof(*(pos)), node))
> +
> +
> +static void add_persistent_gnt(struct rb_root *root,
> +			       struct persistent_gnt *persistent_gnt)
> +{
> +	struct rb_node **new = &(root->rb_node), *parent = NULL;
> +	struct persistent_gnt *this;
> +
> +	/* Figure out where to put new node */
> +	while (*new) {
> +		this = container_of(*new, struct persistent_gnt, node);
> +
> +		parent = *new;
> +		if (persistent_gnt->gnt < this->gnt)
> +			new = &((*new)->rb_left);
> +		else if (persistent_gnt->gnt > this->gnt)
> +			new = &((*new)->rb_right);
> +		else {
> +			pr_alert(DRV_PFX " trying to add a gref that's already in the tree\n");
> +			BUG();
> +		}
> +	}
> +
> +	/* Add new node and rebalance tree. */
> +	rb_link_node(&(persistent_gnt->node), parent, new);
> +	rb_insert_color(&(persistent_gnt->node), root);
> +}
> +
> +static struct persistent_gnt *get_persistent_gnt(struct rb_root *root,
> +						 grant_ref_t gref)
> +{
> +	struct persistent_gnt *data;
> +	struct rb_node *node = root->rb_node;
> +
> +	while (node) {
> +		data = container_of(node, struct persistent_gnt, node);
> +
> +		if (gref < data->gnt)
> +			node = node->rb_left;
> +		else if (gref > data->gnt)
> +			node = node->rb_right;
> +		else
> +			return data;
> +	}
> +	return NULL;
> +}
> +
>  /*
>   * Retrieve from the 'pending_reqs' a free pending_req structure to be used.
>   */
> @@ -274,6 +350,11 @@ int xen_blkif_schedule(void *arg)
>  {
>  	struct xen_blkif *blkif = arg;
>  	struct xen_vbd *vbd = &blkif->vbd;
> +	struct gnttab_unmap_grant_ref unmap[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct persistent_gnt *persistent_gnt;
> +	int ret = 0;
> +	int segs_to_unmap = 0;
>  
>  	xen_blkif_get(blkif);
>  
> @@ -301,6 +382,32 @@ int xen_blkif_schedule(void *arg)
>  			print_stats(blkif);
>  	}
>  
> +	/* Free all persistent grant pages */
> +	foreach_grant(persistent_gnt, &blkif->persistent_gnts, node) {

Just for sanity - you did check this with blkfronts that did not have
persistent grants enabled, right?

> +		BUG_ON(persistent_gnt->handle == BLKBACK_INVALID_HANDLE);
> +		gnttab_set_unmap_op(&unmap[segs_to_unmap],
> +		    (unsigned long) pfn_to_kaddr(page_to_pfn(
> +			persistent_gnt->page)),
> +		    GNTMAP_host_map,
> +		    persistent_gnt->handle);
> +
> +		pages[segs_to_unmap] = persistent_gnt->page;
> +		rb_erase(&persistent_gnt->node, &blkif->persistent_gnts);
> +		kfree(persistent_gnt);
> +		blkif->persistent_gnt_c--;
> +
> +		if (++segs_to_unmap == BLKIF_MAX_SEGMENTS_PER_REQUEST ||
> +			!rb_next(&persistent_gnt->node)) {
> +			ret = gnttab_unmap_refs(unmap, NULL, pages,
> +						segs_to_unmap);
> +			BUG_ON(ret);
> +			segs_to_unmap = 0;
> +		}
> +	}
> +
> +	BUG_ON(blkif->persistent_gnt_c != 0);
> +	BUG_ON(!RB_EMPTY_ROOT(&blkif->persistent_gnts));
> +
>  	if (log_stats)
>  		print_stats(blkif);
>  
> @@ -327,6 +434,8 @@ static void xen_blkbk_unmap(struct pending_req *req)
>  	int ret;
>  
>  	for (i = 0; i < req->nr_pages; i++) {
> +		if (!req->unmap_seg[i])
> +			continue;

Perhaps there should be a #define for that array..
>  		handle = pending_handle(req, i);
>  		if (handle == BLKBACK_INVALID_HANDLE)
>  			continue;
> @@ -343,12 +452,26 @@ static void xen_blkbk_unmap(struct pending_req *req)
>  
>  static int xen_blkbk_map(struct blkif_request *req,
>  			 struct pending_req *pending_req,
> -			 struct seg_buf seg[])
> +			 struct seg_buf seg[],
> +			 struct page *pages[])
>  {
>  	struct gnttab_map_grant_ref map[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> -	int i;
> +	struct persistent_gnt *persistent_gnts[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct page *pages_to_gnt[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct persistent_gnt *persistent_gnt = NULL;
> +	struct xen_blkif *blkif = pending_req->blkif;
> +	phys_addr_t addr = 0;
> +	int i, j;
> +	int new_map;

Just use a bool for this.
>  	int nseg = req->u.rw.nr_segments;
> +	int segs_to_map = 0;
>  	int ret = 0;
> +	int use_persistent_gnts;
> +
> +	use_persistent_gnts = (blkif->vbd.feature_gnt_persistent);
> +
> +	BUG_ON(blkif->persistent_gnt_c >
> +		   max_mapped_grant_pages(pending_req->blkif->blk_protocol));
>  
>  	/*
>  	 * Fill out preq.nr_sects with proper amount of sectors, and setup
> @@ -358,36 +481,141 @@ static int xen_blkbk_map(struct blkif_request *req,
>  	for (i = 0; i < nseg; i++) {
>  		uint32_t flags;
>  
> -		flags = GNTMAP_host_map;
> -		if (pending_req->operation != BLKIF_OP_READ)
> -			flags |= GNTMAP_readonly;
> -		gnttab_set_map_op(&map[i], vaddr(pending_req, i), flags,
> -				  req->u.rw.seg[i].gref,
> -				  pending_req->blkif->domid);
> +		if (use_persistent_gnts)
> +			persistent_gnt = get_persistent_gnt(
> +				&blkif->persistent_gnts,
> +				req->u.rw.seg[i].gref);
> +
> +		if (persistent_gnt) {
> +			/*
> +			 * We are using persistent grants and
> +			 * the grant is already mapped
> +			 */
> +			new_map = 0;
> +		} else if (use_persistent_gnts &&
> +			   blkif->persistent_gnt_c <
> +			   max_mapped_grant_pages(blkif->blk_protocol)) {
> +			/*
> +			 * We are using persistent grants, the grant is
> +			 * not mapped but we have room for it
> +			 */
> +			new_map = 1;
> +			persistent_gnt = kzalloc(
> +				sizeof(struct persistent_gnt),
> +				GFP_KERNEL);
> +			if (!persistent_gnt)
> +				return -ENOMEM;
> +			persistent_gnt->page = alloc_page(GFP_KERNEL);
> +			if (!persistent_gnt->page) {
> +				kfree(persistent_gnt);
> +				return -ENOMEM;
> +			}
> +			persistent_gnt->gnt = req->u.rw.seg[i].gref;
> +
> +			pages_to_gnt[segs_to_map] =
> +				persistent_gnt->page;
> +			addr = (unsigned long) pfn_to_kaddr(
> +				page_to_pfn(persistent_gnt->page));
> +
> +			add_persistent_gnt(&blkif->persistent_gnts,
> +				persistent_gnt);
> +			blkif->persistent_gnt_c++;
> +			pr_debug(DRV_PFX " grant %u added to the tree of persistent grants, using %u/%u\n",
> +				 persistent_gnt->gnt, blkif->persistent_gnt_c,
> +				 max_mapped_grant_pages(blkif->blk_protocol));
> +		} else {
> +			/*
> +			 * We are either using persistent grants and
> +			 * hit the maximum limit of grants mapped,
> +			 * or we are not using persistent grants.
> +			 */
> +			if (use_persistent_gnts &&
> +				!blkif->vbd.overflow_max_grants) {
> +				blkif->vbd.overflow_max_grants = 1;
> +				pr_alert(DRV_PFX " domain %u, device %#x is using maximum number of persistent grants\n",
> +					 blkif->domid, blkif->vbd.handle);
> +			}
> +			new_map = 1;
> +			pages[i] = blkbk->pending_page(pending_req, i);
> +			addr = vaddr(pending_req, i);
> +			pages_to_gnt[segs_to_map] =
> +				blkbk->pending_page(pending_req, i);
> +		}
> +
> +		if (persistent_gnt) {
> +			pages[i] = persistent_gnt->page;
> +			persistent_gnts[i] = persistent_gnt;
> +		} else {
> +			persistent_gnts[i] = NULL;
> +		}
> +
> +		if (new_map) {
> +			flags = GNTMAP_host_map;
> +			if (!persistent_gnt &&
> +			    (pending_req->operation != BLKIF_OP_READ))
> +				flags |= GNTMAP_readonly;
> +			gnttab_set_map_op(&map[segs_to_map++], addr,
> +					  flags, req->u.rw.seg[i].gref,
> +					  blkif->domid);
> +		}
>  	}
>  
> -	ret = gnttab_map_refs(map, NULL, &blkbk->pending_page(pending_req, 0), nseg);
> -	BUG_ON(ret);
> +	if (segs_to_map) {
> +		ret = gnttab_map_refs(map, NULL, pages_to_gnt, segs_to_map);
> +		BUG_ON(ret);
> +	}
>  
>  	/*
>  	 * Now swizzle the MFN in our domain with the MFN from the other domain
>  	 * so that when we access vaddr(pending_req,i) it has the contents of
>  	 * the page from the other domain.
>  	 */
> -	for (i = 0; i < nseg; i++) {
> -		if (unlikely(map[i].status != 0)) {
> -			pr_debug(DRV_PFX "invalid buffer -- could not remap it\n");
> -			map[i].handle = BLKBACK_INVALID_HANDLE;
> -			ret |= 1;
> +	for (i = 0, j = 0; i < nseg; i++) {
> +		if (!persistent_gnts[i] || !persistent_gnts[i]->handle) {
> +			/* This is a newly mapped grant */
> +			BUG_ON(j >= segs_to_map);
> +			if (unlikely(map[j].status != 0)) {

I am not seeing j being incremented anywhere? Should it?

> +				pr_debug(DRV_PFX "invalid buffer -- could not remap it\n");
> +				map[j].handle = BLKBACK_INVALID_HANDLE;
> +				ret |= 1;
> +				if (persistent_gnts[i]) {
> +					rb_erase(&persistent_gnts[i]->node,
> +						 &blkif->persistent_gnts);
> +					blkif->persistent_gnt_c--;
> +					kfree(persistent_gnts[i]);
> +					persistent_gnts[i] = NULL;
> +				}
> +			}
> +		}
> +		if (persistent_gnts[i]) {
> +			if (!persistent_gnts[i]->handle) {
> +				/*
> +				 * If this is a new persistent grant
> +				 * save the handler
> +				 */
> +				persistent_gnts[i]->handle = map[j].handle;
> +				persistent_gnts[i]->dev_bus_addr =
> +					map[j++].dev_bus_addr;
> +			}
> +			pending_handle(pending_req, i) =
> +				persistent_gnts[i]->handle;
> +			pending_req->unmap_seg[i] = 0;

Could we have a #define for that?
> +
> +			if (ret)
> +				continue;
> +
> +			seg[i].buf = persistent_gnts[i]->dev_bus_addr |
> +				(req->u.rw.seg[i].first_sect << 9);
> +		} else {
> +			pending_handle(pending_req, i) = map[j].handle;
> +			pending_req->unmap_seg[i] = 1;

And here as well?
> +
> +			if (ret)
> +				continue;
> +
> +			seg[i].buf = map[j++].dev_bus_addr |
> +				(req->u.rw.seg[i].first_sect << 9);
>  		}
> -
> -		pending_handle(pending_req, i) = map[i].handle;
> -
> -		if (ret)
> -			continue;
> -
> -		seg[i].buf  = map[i].dev_bus_addr |
> -			(req->u.rw.seg[i].first_sect << 9);
>  	}
>  	return ret;
>  }
> @@ -590,6 +818,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>  	int operation;
>  	struct blk_plug plug;
>  	bool drain = false;
> +	struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
>  
>  	switch (req->operation) {
>  	case BLKIF_OP_READ:
> @@ -676,7 +905,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>  	 * the hypercall to unmap the grants - that is all done in
>  	 * xen_blkbk_unmap.
>  	 */
> -	if (xen_blkbk_map(req, pending_req, seg))
> +	if (xen_blkbk_map(req, pending_req, seg, pages))
>  		goto fail_flush;
>  
>  	/*
> @@ -688,7 +917,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>  	for (i = 0; i < nseg; i++) {
>  		while ((bio == NULL) ||
>  		       (bio_add_page(bio,
> -				     blkbk->pending_page(pending_req, i),
> +				     pages[i],
>  				     seg[i].nsec << 9,
>  				     seg[i].buf & ~PAGE_MASK) == 0)) {
>  
> diff --git a/drivers/block/xen-blkback/common.h b/drivers/block/xen-blkback/common.h
> index 9ad3b5e..6c08ee9 100644
> --- a/drivers/block/xen-blkback/common.h
> +++ b/drivers/block/xen-blkback/common.h
> @@ -34,6 +34,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -160,10 +161,22 @@ struct xen_vbd {
>  	sector_t		size;
>  	bool			flush_support;
>  	bool			discard_secure;
> +
> +	unsigned int		feature_gnt_persistent:1;
> +	unsigned int		overflow_max_grants:1;

I think the v3.7-rc1 has this structure changed just a tiny bit, so you
might want to rebase it on top of that.

>  };
>  
>  struct backend_info;
>  
> +
> +struct persistent_gnt {
> +	struct page *page;
> +	grant_ref_t gnt;
> +	grant_handle_t handle;
> +	uint64_t dev_bus_addr;
> +	struct rb_node node;
> +};
> +
>  struct xen_blkif {
>  	/* Unique identifier for this interface. */
>  	domid_t			domid;
> @@ -190,6 +203,10 @@ struct xen_blkif {
>  	struct task_struct	*xenblkd;
>  	unsigned int		waiting_reqs;
>  
> +	/* frontend feature information */

Huh?

> +	struct rb_root		persistent_gnts;
> +	unsigned int		persistent_gnt_c;
> +
>  	/* statistics */
>  	unsigned long		st_print;
>  	int			st_rd_req;
> diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c
> index 4f66171..9f88b4e 100644
> --- a/drivers/block/xen-blkback/xenbus.c
> +++ b/drivers/block/xen-blkback/xenbus.c
> @@ -118,6 +118,7 @@ static struct xen_blkif *xen_blkif_alloc(domid_t domid)
>  	atomic_set(&blkif->drain, 0);
>  	blkif->st_print = jiffies;
>  	init_waitqueue_head(&blkif->waiting_to_free);
> +	blkif->persistent_gnts.rb_node = NULL;
>  
>  	return blkif;
>  }
> @@ -721,6 +722,7 @@ static int connect_ring(struct backend_info *be)
>  	struct xenbus_device *dev = be->dev;
>  	unsigned long ring_ref;
>  	unsigned int evtchn;
> +	unsigned int pers_grants;
>  	char protocol[64] = "";
>  	int err;
>  
> @@ -750,8 +752,18 @@ static int connect_ring(struct backend_info *be)
>  		xenbus_dev_fatal(dev, err, "unknown fe protocol %s", protocol);
>  		return -1;
>  	}
> -	pr_info(DRV_PFX "ring-ref %ld, event-channel %d, protocol %d (%s)\n",
> -		ring_ref, evtchn, be->blkif->blk_protocol, protocol);
> +	err = xenbus_gather(XBT_NIL, dev->otherend,
> +			    "feature-persistent-grants", "%u",
> +			    &pers_grants, NULL);
> +	if (err)
> +		pers_grants = 0;
> +
> +	be->blkif->vbd.feature_gnt_persistent = pers_grants;
> +	be->blkif->vbd.overflow_max_grants = 0;
> +
> +	pr_info(DRV_PFX "ring-ref %ld, event-channel %d, protocol %d (%s) persistent %d\n",
> +		ring_ref, evtchn, be->blkif->blk_protocol, protocol,
> +		pers_grants);

Can you make that a string? So it is
 pers_grants ? "persistent grants" : ""

instead of a zero of one value pls?
>  
>  	/* Map the shared frame, irq etc. */
>  	err = xen_blkif_map(be->blkif, ring_ref, evtchn);
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 2c2d2e5..206d422 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -44,6 +44,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -64,10 +65,17 @@ enum blkif_state {
>  	BLKIF_STATE_SUSPENDED,
>  };
>  
> +struct grant {
> +	grant_ref_t gref;
> +	unsigned long pfn;
> +	struct llist_node node;
> +};
> +
>  struct blk_shadow {
>  	struct blkif_request req;
>  	struct request *request;
>  	unsigned long frame[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct grant *grants_used[BLKIF_MAX_SEGMENTS_PER_REQUEST];
>  };
>  
>  static DEFINE_MUTEX(blkfront_mutex);
> @@ -97,6 +105,8 @@ struct blkfront_info
>  	struct work_struct work;
>  	struct gnttab_free_callback callback;
>  	struct blk_shadow shadow[BLK_RING_SIZE];
> +	struct llist_head persistent_gnts;
> +	unsigned int persistent_gnts_c;
>  	unsigned long shadow_free;
>  	unsigned int feature_flush;
>  	unsigned int flush_op;
> @@ -287,21 +297,36 @@ static int blkif_queue_request(struct request *req)
>  	unsigned long id;
>  	unsigned int fsect, lsect;
>  	int i, ref;
> +
> +	/*
> +	 * Used to store if we are able to queue the request by just using
> +	 * existing persistent grants (0), or if we have to get new grants,

What does the zero mean?
> +	 * as there are not sufficiently many free.
> +	 */
> +	int new_persistent_gnts;

I think this can be a bool?
>  	grant_ref_t gref_head;
> +	struct page *granted_page;
> +	struct grant *gnt_list_entry = NULL;
>  	struct scatterlist *sg;
>  
>  	if (unlikely(info->connected != BLKIF_STATE_CONNECTED))
>  		return 1;
>  
> -	if (gnttab_alloc_grant_references(
> -		BLKIF_MAX_SEGMENTS_PER_REQUEST, &gref_head) < 0) {
> -		gnttab_request_free_callback(
> -			&info->callback,
> -			blkif_restart_queue_callback,
> -			info,
> -			BLKIF_MAX_SEGMENTS_PER_REQUEST);
> -		return 1;
> -	}
> +	/* Check if we have enought grants to allocate a requests */
> +	if (info->persistent_gnts_c < BLKIF_MAX_SEGMENTS_PER_REQUEST) {
> +		new_persistent_gnts = 1;
> +		if (gnttab_alloc_grant_references(
> +		    BLKIF_MAX_SEGMENTS_PER_REQUEST - info->persistent_gnts_c,
> +		    &gref_head) < 0) {
> +			gnttab_request_free_callback(
> +				&info->callback,
> +				blkif_restart_queue_callback,
> +				info,
> +				BLKIF_MAX_SEGMENTS_PER_REQUEST);
> +			return 1;
> +		}
> +	} else
> +		new_persistent_gnts = 0;
>  
>  	/* Fill out a communications ring structure. */
>  	ring_req = RING_GET_REQUEST(&info->ring, info->ring.req_prod_pvt);
> @@ -341,18 +366,73 @@ static int blkif_queue_request(struct request *req)
>  		       BLKIF_MAX_SEGMENTS_PER_REQUEST);
>  
>  		for_each_sg(info->sg, sg, ring_req->u.rw.nr_segments, i) {
> -			buffer_mfn = pfn_to_mfn(page_to_pfn(sg_page(sg)));
>  			fsect = sg->offset >> 9;
>  			lsect = fsect + (sg->length >> 9) - 1;
> -			/* install a grant reference. */
> -			ref = gnttab_claim_grant_reference(&gref_head);
> -			BUG_ON(ref == -ENOSPC);
>  
> -			gnttab_grant_foreign_access_ref(
> -					ref,
> +			if (info->persistent_gnts_c) {
> +				BUG_ON(llist_empty(&info->persistent_gnts));
> +				gnt_list_entry = llist_entry(
> +					llist_del_first(&info->persistent_gnts),
> +					struct grant, node);
> +
> +				ref = gnt_list_entry->gref;
> +				buffer_mfn = pfn_to_mfn(gnt_list_entry->pfn);
> +				info->persistent_gnts_c--;
> +			} else {
> +				ref = gnttab_claim_grant_reference(&gref_head);
> +				BUG_ON(ref == -ENOSPC);
> +
> +				gnt_list_entry =
> +					kmalloc(sizeof(struct grant),
> +							 GFP_ATOMIC);
> +				if (!gnt_list_entry)
> +					return -ENOMEM;
> +
> +				granted_page = alloc_page(GFP_ATOMIC);
> +				if (!granted_page) {
> +					kfree(gnt_list_entry);
> +					return -ENOMEM;
> +				}
> +
> +				gnt_list_entry->pfn =
> +					page_to_pfn(granted_page);
> +				gnt_list_entry->gref = ref;
> +
> +				buffer_mfn = pfn_to_mfn(page_to_pfn(
> +								granted_page));
> +				gnttab_grant_foreign_access_ref(ref,
>  					info->xbdev->otherend_id,
> -					buffer_mfn,
> -					rq_data_dir(req));
> +					buffer_mfn, 0);
> +			}
> +
> +			info->shadow[id].grants_used[i] = gnt_list_entry;
> +
> +			if (rq_data_dir(req)) {
> +				char *bvec_data;
> +				void *shared_data;
> +
> +				BUG_ON(sg->offset + sg->length > PAGE_SIZE);
> +
> +				shared_data = kmap_atomic(
> +					pfn_to_page(gnt_list_entry->pfn));
> +				bvec_data = kmap_atomic(sg_page(sg));
> +
> +				/*
> +				 * this does not wipe data stored outside the
> +				 * range sg->offset..sg->offset+sg->length.
> +				 * Therefore, blkback *could* see data from
> +				 * previous requests. This is OK as long as
> +				 * persistent grants are shared with just one
> +				 * domain. It may need refactoring if This
.. this (lowercase it pls)

> +				 * changes
> +				 */
> +				memcpy(shared_data + sg->offset,
> +				       bvec_data   + sg->offset,
> +				       sg->length);
> +
> +				kunmap_atomic(bvec_data);
> +				kunmap_atomic(shared_data);
> +			}
>  
>  			info->shadow[id].frame[i] = mfn_to_pfn(buffer_mfn);
>  			ring_req->u.rw.seg[i] =
> @@ -368,7 +448,8 @@ static int blkif_queue_request(struct request *req)
>  	/* Keep a private copy so we can reissue requests when recovering. */
>  	info->shadow[id].req = *ring_req;
>  
> -	gnttab_free_grant_references(gref_head);
> +	if (new_persistent_gnts)
> +		gnttab_free_grant_references(gref_head);
>  
>  	return 0;
>  }
> @@ -480,7 +561,7 @@ static int xlvbd_init_blk_queue(struct gendisk *gd, u16 sector_size)
>  static void xlvbd_flush(struct blkfront_info *info)
>  {
>  	blk_queue_flush(info->rq, info->feature_flush);
> -	printk(KERN_INFO "blkfront: %s: %s: %s\n",
> +	printk(KERN_INFO "blkfront: %s: %s: %s, using persistent grants\n",

HA! By default, eh?
>  	       info->gd->disk_name,
>  	       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
>  		"barrier" : (info->flush_op == BLKIF_OP_FLUSH_DISKCACHE ?
> @@ -707,6 +788,9 @@ static void blkif_restart_queue(struct work_struct *work)
>  
>  static void blkif_free(struct blkfront_info *info, int suspend)
>  {
> +	struct llist_node *all_gnts;
> +	struct grant *persistent_gnt;
> +
>  	/* Prevent new requests being issued until we fix things up. */
>  	spin_lock_irq(&info->io_lock);
>  	info->connected = suspend ?
> @@ -714,6 +798,17 @@ static void blkif_free(struct blkfront_info *info, int suspend)
>  	/* No more blkif_request(). */
>  	if (info->rq)
>  		blk_stop_queue(info->rq);
> +
> +	/* Remove all persistent grants */
> +	if (info->persistent_gnts_c) {
> +		all_gnts = llist_del_all(&info->persistent_gnts);
> +		llist_for_each_entry(persistent_gnt, all_gnts, node) {
> +			gnttab_end_foreign_access(persistent_gnt->gref, 0, 0UL);
> +			kfree(persistent_gnt);
> +		}
> +		info->persistent_gnts_c = 0;
> +	}
> +
>  	/* No more gnttab callback work. */
>  	gnttab_cancel_free_callback(&info->callback);
>  	spin_unlock_irq(&info->io_lock);
> @@ -734,13 +829,42 @@ static void blkif_free(struct blkfront_info *info, int suspend)
>  
>  }
>  
> -static void blkif_completion(struct blk_shadow *s)
> +static void blkif_completion(struct blk_shadow *s, struct blkfront_info *info,
> +			     struct blkif_response *bret)
>  {
>  	int i;
> -	/* Do not let BLKIF_OP_DISCARD as nr_segment is in the same place
> -	 * flag. */
> -	for (i = 0; i < s->req.u.rw.nr_segments; i++)
> -		gnttab_end_foreign_access(s->req.u.rw.seg[i].gref, 0, 0UL);
> +	struct bio_vec *bvec;
> +	struct req_iterator iter;
> +	unsigned long flags;
> +	char *bvec_data;
> +	void *shared_data;
> +	unsigned int offset = 0;
> +
> +	if (bret->operation == BLKIF_OP_READ) {
> +		/*
> +		 * Copy the data received from the backend into the bvec.
> +		 * Since bv_len can be different from PAGE_SIZE, we need to
> +		 * be sure we are actually copying the data from the right
> +		 * shared page.
> +		 */
> +		rq_for_each_segment(bvec, s->request, iter) {
> +			BUG_ON((bvec->bv_offset + bvec->bv_len) > PAGE_SIZE);
> +			i = offset >> PAGE_SHIFT;

Could you also include a comment about the bug you found here, pls?
> +			shared_data = kmap_atomic(
> +				pfn_to_page(s->grants_used[i]->pfn));
> +			bvec_data = bvec_kmap_irq(bvec, &flags);
> +			memcpy(bvec_data, shared_data + bvec->bv_offset,
> +				bvec->bv_len);
> +			bvec_kunmap_irq(bvec_data, &flags);
> +			kunmap_atomic(shared_data);
> +			offset += bvec->bv_len;
> +		}
> +	}
> +	/* Add the persistent grant into the list of free grants */
> +	for (i = 0; i < s->req.u.rw.nr_segments; i++) {
> +		llist_add(&s->grants_used[i]->node, &info->persistent_gnts);
> +		info->persistent_gnts_c++;
> +	}
>  }
>  
>  static irqreturn_t blkif_interrupt(int irq, void *dev_id)
> @@ -783,7 +907,7 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
>  		req  = info->shadow[id].request;
>  
>  		if (bret->operation != BLKIF_OP_DISCARD)
> -			blkif_completion(&info->shadow[id]);
> +			blkif_completion(&info->shadow[id], info, bret);
>  
>  		if (add_id_to_freelist(info, id)) {
>  			WARN(1, "%s: response to %s (id %ld) couldn't be recycled!\n",
> @@ -942,6 +1066,11 @@ again:
>  		message = "writing protocol";
>  		goto abort_transaction;
>  	}
> +	err = xenbus_printf(xbt, dev->nodename,
> +			    "feature-persistent-grants", "%d", 1);

So its %u in blkback, but %d in here? Which one should it be?

> +	if (err)
> +		dev_warn(&dev->dev,
> +			 "writing persistent grants feature to xenbus");
>  
>  	err = xenbus_transaction_end(xbt, 0);
>  	if (err) {
> @@ -1029,6 +1158,8 @@ static int blkfront_probe(struct xenbus_device *dev,
>  	spin_lock_init(&info->io_lock);
>  	info->xbdev = dev;
>  	info->vdevice = vdevice;
> +	init_llist_head(&info->persistent_gnts);
> +	info->persistent_gnts_c = 0;
>  	info->connected = BLKIF_STATE_DISCONNECTED;
>  	INIT_WORK(&info->work, blkif_restart_queue);
>  
> @@ -1093,7 +1224,7 @@ static int blkif_recover(struct blkfront_info *info)
>  					req->u.rw.seg[j].gref,
>  					info->xbdev->otherend_id,
>  					pfn_to_mfn(info->shadow[req->u.rw.id].frame[j]),
> -					rq_data_dir(info->shadow[req->u.rw.id].request));
> +					0);
>  		}
>  		info->shadow[req->u.rw.id].req = *req;
>  
> -- 
> 1.7.7.5 (Apple Git-26)
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 13:50:50 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 13:50:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQIOl-00028A-Mr; Mon, 22 Oct 2012 13:50:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQIOl-00027x-55; Mon, 22 Oct 2012 13:50:31 +0000
Received: from [85.158.143.35:41007] by server-3.bemta-4.messagelabs.com id
	DC/B7-03544-62F45805; Mon, 22 Oct 2012 13:50:30 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-16.tower-21.messagelabs.com!1350913824!15031610!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MjIyNDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2869 invoked from network); 22 Oct 2012 13:50:28 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Oct 2012 13:50:28 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 56DC0125D;
	Mon, 22 Oct 2012 16:50:24 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id BFEC520058; Mon, 22 Oct 2012 16:50:23 +0300 (EEST)
Date: Mon, 22 Oct 2012 16:50:23 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= 
To: "Fan, Huaxiang" 
Message-ID: <20121022135023.GU8912@reaktio.net>
References: 
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "xen-users@lists.xen.org" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] e820_host problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 22, 2012 at 10:11:00AM +0000, Fan, Huaxiang wrote:
>    Hi,
> 
> 
> 
>    I've set up a PV guest using xen 4.2 and kernel 2.6.32.57. the hypervior
>    is 64bits whereas the dom0 and domu are 32bits. It seems to me that the
>    memory allocation to domu is *limited to 3360M* when e820_host is enabled.
>    I attached the domu configuration file and output of the command xl -vvv
>    create and xl list.
> 
>    I am looking forward your reply.
>

First of all try with a later kernel, say Linux 3.6.2.

-- Pasi
 
>    Thanks,
> 
>    HUAXIANG FAN
>    Software Engineer II
> 
>    WEBSENSE NETWORK SECURITY TECHNOLOGY R&D (BEIJING) CO. LTD.
>    ph: +8610.5884.4327
>    fax: +8610.5884.4727
>    [1]www.websense.cn
> 
>    Websense TRITON(TM)
>    For Essential Information Protection(TM)
>    [2]Web Security | [3]Data Security | [4]Email Security
> 
>         Protected by Websense Hosted Email Security -- www.websense.com
> 
> References
> 
>    Visible links
>    1. http://www.websense.cn/
>    2. http://www.websense.com/content/Regional/SCH/WebSecurityOverview.aspx
>    3. http://www.websense.com/content/Regional/SCH/DataSecurity.aspx
>    4. http://www.websense.com/content/Regional/SCH/MessagingSecurity.aspx




> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 13:50:50 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 13:50:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQIOl-00028A-Mr; Mon, 22 Oct 2012 13:50:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQIOl-00027x-55; Mon, 22 Oct 2012 13:50:31 +0000
Received: from [85.158.143.35:41007] by server-3.bemta-4.messagelabs.com id
	DC/B7-03544-62F45805; Mon, 22 Oct 2012 13:50:30 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-16.tower-21.messagelabs.com!1350913824!15031610!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MjIyNDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2869 invoked from network); 22 Oct 2012 13:50:28 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Oct 2012 13:50:28 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 56DC0125D;
	Mon, 22 Oct 2012 16:50:24 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id BFEC520058; Mon, 22 Oct 2012 16:50:23 +0300 (EEST)
Date: Mon, 22 Oct 2012 16:50:23 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= 
To: "Fan, Huaxiang" 
Message-ID: <20121022135023.GU8912@reaktio.net>
References: 
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "xen-users@lists.xen.org" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] e820_host problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 22, 2012 at 10:11:00AM +0000, Fan, Huaxiang wrote:
>    Hi,
> 
> 
> 
>    I've set up a PV guest using xen 4.2 and kernel 2.6.32.57. the hypervior
>    is 64bits whereas the dom0 and domu are 32bits. It seems to me that the
>    memory allocation to domu is *limited to 3360M* when e820_host is enabled.
>    I attached the domu configuration file and output of the command xl -vvv
>    create and xl list.
> 
>    I am looking forward your reply.
>

First of all try with a later kernel, say Linux 3.6.2.

-- Pasi
 
>    Thanks,
> 
>    HUAXIANG FAN
>    Software Engineer II
> 
>    WEBSENSE NETWORK SECURITY TECHNOLOGY R&D (BEIJING) CO. LTD.
>    ph: +8610.5884.4327
>    fax: +8610.5884.4727
>    [1]www.websense.cn
> 
>    Websense TRITON(TM)
>    For Essential Information Protection(TM)
>    [2]Web Security | [3]Data Security | [4]Email Security
> 
>         Protected by Websense Hosted Email Security -- www.websense.com
> 
> References
> 
>    Visible links
>    1. http://www.websense.cn/
>    2. http://www.websense.com/content/Regional/SCH/WebSecurityOverview.aspx
>    3. http://www.websense.com/content/Regional/SCH/DataSecurity.aspx
>    4. http://www.websense.com/content/Regional/SCH/MessagingSecurity.aspx




> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 13:56:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 13:56:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQIUK-0002d4-AH; Mon, 22 Oct 2012 13:56:16 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQIUJ-0002cz-Qg
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 13:56:16 +0000
Received: from [193.109.254.147:25246] by server-6.bemta-14.messagelabs.com id
	92/76-17826-F7055805; Mon, 22 Oct 2012 13:56:15 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-2.tower-27.messagelabs.com!1350914172!15550397!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28489 invoked from network); 22 Oct 2012 13:56:13 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 13:56:13 -0000
Received: by mail-ie0-f173.google.com with SMTP id 17so4546604iea.32
	for ; Mon, 22 Oct 2012 06:56:12 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=content-type:mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=+3cnVsKDfV9h24ICbvxmN0fm+bZ6ewN9W4sdGrO2oC8=;
	b=VkYTJBTxdWhu8mIHxx7/xSkf6AEZ9YSbXvK0ky8JxCj9EquVru48/nyIpvwKK1nfi/
	6M3ncBiYh7fp6ezte1qjzmzaBhFQSqqXJGJGCPQTmJSHUqhJalKumrwMg97X+HQbhSff
	wfw6ZrFS8fV7BmtXW8/1UlNbZKomAFP35FEjID0V44UlbDbUDDf6vadIHro2tKBTZNb4
	4seaLKh8ECAwtGbd3LQymcKc5NqhAyEhtP4Df2SQRZmlpSwNhRJcS/kzL6mKbEFahw0/
	q70EEDHMt4d6EYvGmHRC7E0GIE6g00t4jWWWGNQiLFLZU/K5wFMmRaRAzI+bJqnDCe+e
	L3Kg==
Received: by 10.50.57.194 with SMTP id k2mr9124023igq.17.1350914171904;
	Mon, 22 Oct 2012 06:56:11 -0700 (PDT)
Received: from andress-macbook.gridcentric.ca ([206.223.182.18])
	by mx.google.com with ESMTPS id d19sm22546236igp.6.2012.10.22.06.56.10
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 22 Oct 2012 06:56:11 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Andres Lagar-Cavilla 
In-Reply-To: <5082DD8C.2030608@brockmann-consult.de>
Date: Mon, 22 Oct 2012 09:56:16 -0400
Message-Id: <4557B62D-CBC2-4AB8-A419-99308B21385B@gridcentric.ca>
References: <5082DD8C.2030608@brockmann-consult.de>
To: Peter Maloney 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQlXGPeaiwiQX+QAh2W5mEuSreEtuylvOWxEmPFkxR1d7II1XX1Uo+aspeS8fbfJzk+tDgUV
Cc: Andres Lagar-Cavilla , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen-unstable,
	winxp32 very poor performance on AMD FX-8150,
	I bisected and changeset is 24770:7f79475d3de7
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Oct 20, 2012, at 1:21 PM, Peter Maloney  wrote:

> I ran a bisect to find out when Windows XP 32 bit becomes unusably slow.
> And I found the changeset that caused it.
> 
> ==========
> The problem:
> ==========
> 
> Windows 8 64 bit and 32 bit run fast and fine in the newest xen versions.
> 
> Windows XP 32 bit runs unusably slow in anything new that I built from
> xen-unstable, but runs fast in 4.1.2 and 4.1.3 stable. While it is
> running slow, "xm top" or "xl top" show cpu usage around 650% for the domu.
> 
> The bug might be AMD specific. I'm running an AMD FX-8150.
> 
> ==========
> The result:
> ==========
> 
> good: 24769:730f6ed72d70
> bad: 24770:7f79475d3de7
> 
> The change was 8 months ago
> 
> changeset:   24770:7f79475d3de7
> user:        Andres Lagar-Cavilla 
> date:        Fri Feb 10 16:07:07 2012 +0000
> summary:     x86/mm: Make p2m lookups fully synchronized wrt modifications

Peter,
thanks for the bug report and the bisection.

vcpus (and guest processes) look like they're chewing CPU because they're spending cycles within the hypervisor contending for spin locks. In the 4.2 time frame we had a similar report and we partially reverted the change set you mention to use read/write locks, ameliorating contention. It's obviously critical to figure which code path is win xp exercising wrt the p2m lock.

There are a number of profiling tools out there, so please go ahead with your favorite one to figure out what the vcpu's are doing in hypervisor context. 

If unsure, my advice, in terms of quick initial turnaround, would be to
xl dmesg -c
for i in a_number_of_times; do xl debug-keys d; xl dmesg -c; done;

This is gonna dump stack traces for all scheduled vcpus. We should be able to see the stack traces for your domU vcpus, and through sampling quickly infer where they are spending most of their time.

Let us know what you find.
Thanks
Andres

> 
> ==========
> My hardware:
> ==========
> 
> AMD FX-8150
> 990 FX chipset
> 
> Here's a dmidecode: http://pastebin.com/XUZjmiVz
> 
> ==========
> My kernel:
> ==========
> 
> I compiled the for-linus branch of cmason's linux-btrfs git repo, around
> August 11th (
> git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git
> for-linus )
> 
> peter:~/xen # uname -a
> Linux peter 3.5.0-1-default+ #3 SMP Sat Aug 11 21:30:44 CEST 2012 x86_64
> x86_64 x86_64 GNU/Linux
> 
> Here's the kernel config: http://pastebin.com/1GQbiFZE (only weird thing
> I set was CONFIG_NR_CPUS=16 for no particular reason; default was 512 or
> 256)
> 
> ==========
> My Windows XP VM config:
> ==========
> 
> # grep -vE "^#|^$" windowsxp2
> name="windowsxp2"
> description="None"
> uuid="292b0651-9913-2459-5cfa-fb828f9c4314"
> memory=4096
> maxmem=4096
> vcpus=7
> on_poweroff="destroy"
> on_reboot="restart"
> on_crash="destroy"
> localtime=1
> keymap="en-us"
> builder="hvm"
> device_model="/usr/lib/xen/bin/qemu-dm"
> kernel="/usr/lib/xen/boot/hvmloader"
> boot="c"
> disk=[ 'phy:/dev/data/winxp1_disk1,hda,w',
> 'file:/var/lib/xen/winxp1_disk2.raw,hdb,w', ]
> vif=[ 'mac=00:16:3e:4e:c5:0c,bridge=br0,model=e1000', ]
> sdl=0
> vnc=1
> vncunused=1
> audio=0
> soundhw='es1370'
> viridian=1
> usb=1
> acpi=1
> apic=0
> pae=1
> usbdevice='tablet'
> serial="pty"
> stdvga=1
> gfx_passthru=0
> # this is an AMD Radeon HD 6770 and it's HDMI audio, and 2 USB ports
> pci = [ '04:00.0' , '04:00.1' , '00:12.0' , '00:12.2' ]
> xen_platform_pci=1
> pci_msitranslate=1
> 
> 
> The Windows 8 32 and 64 bit configs I used are the same except changed
> mac address, and different disk.
> 
> Whether or not I use sound or PCI passthrough doesn't (significantly)
> affect performance.
> 
> 
> ==========
> my build process, including how to hack the build so it actually compiles:
> ==========
> 
> # Install older libyajl-devel
> 
>    On openSUSE, this would be:
> 
>        zypper install libyajl1-devel
> 
> # Delete everything (except .hg)... prevents unclean builds from
> breaking things. make distclean is not enough for very many builds.
> cd xen-unstable.hg
> rm -rf *
> # If you have permission denied errors (caused by running make install
> as root earlier), make sure to use chown and run rm again, or builds
> will fail.
> 
> # Check out the revision
> hg update --clean "${build}"
> 
> # hack up a troublesome Makefile that prevents builds
> vim tools/libxl/Makefile
>    add "-lyajl":
>        at the end of all 4 "$(CC) ..." lines
>        to LIBXL_LIBS
>        to LIBXLU_LIBS
>        to LIBUUID_LIBS
> 
>    (don't know which ones are important... but it works with all of it)
> 
> make distclean >/tmp/xen.distclean.log 2>&1 ; status=$? ; echo $status
> 
> if [ -e configure ]; then
>    ./configure
> else
>    touch .config
> fi
> 
> make dist >/tmp/xen.dist.log 2>&1 ; status=$? ; echo $status
> 
> 
> ==========
> my install process
> ==========
> 
> To install the build, it's important to clean out old lib files...
> uninstall doesn't get them all. If you miss these, xm, xl, etc. may fail
> due to shared library issues.
> 
> Also, "make uninstall" deletes important system files it should not
> (kernel, kernel modules, vm disks).
> 
> As it says in the "make help":
>  uninstall        - attempt to remove installed Xen tools
>                     (use with extreme care!)
> 
> Here is my process to solve the uninstall issues:
> http://pastebin.com/nXCavFTp


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 13:56:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 13:56:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQIUK-0002d4-AH; Mon, 22 Oct 2012 13:56:16 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQIUJ-0002cz-Qg
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 13:56:16 +0000
Received: from [193.109.254.147:25246] by server-6.bemta-14.messagelabs.com id
	92/76-17826-F7055805; Mon, 22 Oct 2012 13:56:15 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-2.tower-27.messagelabs.com!1350914172!15550397!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28489 invoked from network); 22 Oct 2012 13:56:13 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 13:56:13 -0000
Received: by mail-ie0-f173.google.com with SMTP id 17so4546604iea.32
	for ; Mon, 22 Oct 2012 06:56:12 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=content-type:mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=+3cnVsKDfV9h24ICbvxmN0fm+bZ6ewN9W4sdGrO2oC8=;
	b=VkYTJBTxdWhu8mIHxx7/xSkf6AEZ9YSbXvK0ky8JxCj9EquVru48/nyIpvwKK1nfi/
	6M3ncBiYh7fp6ezte1qjzmzaBhFQSqqXJGJGCPQTmJSHUqhJalKumrwMg97X+HQbhSff
	wfw6ZrFS8fV7BmtXW8/1UlNbZKomAFP35FEjID0V44UlbDbUDDf6vadIHro2tKBTZNb4
	4seaLKh8ECAwtGbd3LQymcKc5NqhAyEhtP4Df2SQRZmlpSwNhRJcS/kzL6mKbEFahw0/
	q70EEDHMt4d6EYvGmHRC7E0GIE6g00t4jWWWGNQiLFLZU/K5wFMmRaRAzI+bJqnDCe+e
	L3Kg==
Received: by 10.50.57.194 with SMTP id k2mr9124023igq.17.1350914171904;
	Mon, 22 Oct 2012 06:56:11 -0700 (PDT)
Received: from andress-macbook.gridcentric.ca ([206.223.182.18])
	by mx.google.com with ESMTPS id d19sm22546236igp.6.2012.10.22.06.56.10
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 22 Oct 2012 06:56:11 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Andres Lagar-Cavilla 
In-Reply-To: <5082DD8C.2030608@brockmann-consult.de>
Date: Mon, 22 Oct 2012 09:56:16 -0400
Message-Id: <4557B62D-CBC2-4AB8-A419-99308B21385B@gridcentric.ca>
References: <5082DD8C.2030608@brockmann-consult.de>
To: Peter Maloney 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQlXGPeaiwiQX+QAh2W5mEuSreEtuylvOWxEmPFkxR1d7II1XX1Uo+aspeS8fbfJzk+tDgUV
Cc: Andres Lagar-Cavilla , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen-unstable,
	winxp32 very poor performance on AMD FX-8150,
	I bisected and changeset is 24770:7f79475d3de7
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Oct 20, 2012, at 1:21 PM, Peter Maloney  wrote:

> I ran a bisect to find out when Windows XP 32 bit becomes unusably slow.
> And I found the changeset that caused it.
> 
> ==========
> The problem:
> ==========
> 
> Windows 8 64 bit and 32 bit run fast and fine in the newest xen versions.
> 
> Windows XP 32 bit runs unusably slow in anything new that I built from
> xen-unstable, but runs fast in 4.1.2 and 4.1.3 stable. While it is
> running slow, "xm top" or "xl top" show cpu usage around 650% for the domu.
> 
> The bug might be AMD specific. I'm running an AMD FX-8150.
> 
> ==========
> The result:
> ==========
> 
> good: 24769:730f6ed72d70
> bad: 24770:7f79475d3de7
> 
> The change was 8 months ago
> 
> changeset:   24770:7f79475d3de7
> user:        Andres Lagar-Cavilla 
> date:        Fri Feb 10 16:07:07 2012 +0000
> summary:     x86/mm: Make p2m lookups fully synchronized wrt modifications

Peter,
thanks for the bug report and the bisection.

vcpus (and guest processes) look like they're chewing CPU because they're spending cycles within the hypervisor contending for spin locks. In the 4.2 time frame we had a similar report and we partially reverted the change set you mention to use read/write locks, ameliorating contention. It's obviously critical to figure which code path is win xp exercising wrt the p2m lock.

There are a number of profiling tools out there, so please go ahead with your favorite one to figure out what the vcpu's are doing in hypervisor context. 

If unsure, my advice, in terms of quick initial turnaround, would be to
xl dmesg -c
for i in a_number_of_times; do xl debug-keys d; xl dmesg -c; done;

This is gonna dump stack traces for all scheduled vcpus. We should be able to see the stack traces for your domU vcpus, and through sampling quickly infer where they are spending most of their time.

Let us know what you find.
Thanks
Andres

> 
> ==========
> My hardware:
> ==========
> 
> AMD FX-8150
> 990 FX chipset
> 
> Here's a dmidecode: http://pastebin.com/XUZjmiVz
> 
> ==========
> My kernel:
> ==========
> 
> I compiled the for-linus branch of cmason's linux-btrfs git repo, around
> August 11th (
> git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git
> for-linus )
> 
> peter:~/xen # uname -a
> Linux peter 3.5.0-1-default+ #3 SMP Sat Aug 11 21:30:44 CEST 2012 x86_64
> x86_64 x86_64 GNU/Linux
> 
> Here's the kernel config: http://pastebin.com/1GQbiFZE (only weird thing
> I set was CONFIG_NR_CPUS=16 for no particular reason; default was 512 or
> 256)
> 
> ==========
> My Windows XP VM config:
> ==========
> 
> # grep -vE "^#|^$" windowsxp2
> name="windowsxp2"
> description="None"
> uuid="292b0651-9913-2459-5cfa-fb828f9c4314"
> memory=4096
> maxmem=4096
> vcpus=7
> on_poweroff="destroy"
> on_reboot="restart"
> on_crash="destroy"
> localtime=1
> keymap="en-us"
> builder="hvm"
> device_model="/usr/lib/xen/bin/qemu-dm"
> kernel="/usr/lib/xen/boot/hvmloader"
> boot="c"
> disk=[ 'phy:/dev/data/winxp1_disk1,hda,w',
> 'file:/var/lib/xen/winxp1_disk2.raw,hdb,w', ]
> vif=[ 'mac=00:16:3e:4e:c5:0c,bridge=br0,model=e1000', ]
> sdl=0
> vnc=1
> vncunused=1
> audio=0
> soundhw='es1370'
> viridian=1
> usb=1
> acpi=1
> apic=0
> pae=1
> usbdevice='tablet'
> serial="pty"
> stdvga=1
> gfx_passthru=0
> # this is an AMD Radeon HD 6770 and it's HDMI audio, and 2 USB ports
> pci = [ '04:00.0' , '04:00.1' , '00:12.0' , '00:12.2' ]
> xen_platform_pci=1
> pci_msitranslate=1
> 
> 
> The Windows 8 32 and 64 bit configs I used are the same except changed
> mac address, and different disk.
> 
> Whether or not I use sound or PCI passthrough doesn't (significantly)
> affect performance.
> 
> 
> ==========
> my build process, including how to hack the build so it actually compiles:
> ==========
> 
> # Install older libyajl-devel
> 
>    On openSUSE, this would be:
> 
>        zypper install libyajl1-devel
> 
> # Delete everything (except .hg)... prevents unclean builds from
> breaking things. make distclean is not enough for very many builds.
> cd xen-unstable.hg
> rm -rf *
> # If you have permission denied errors (caused by running make install
> as root earlier), make sure to use chown and run rm again, or builds
> will fail.
> 
> # Check out the revision
> hg update --clean "${build}"
> 
> # hack up a troublesome Makefile that prevents builds
> vim tools/libxl/Makefile
>    add "-lyajl":
>        at the end of all 4 "$(CC) ..." lines
>        to LIBXL_LIBS
>        to LIBXLU_LIBS
>        to LIBUUID_LIBS
> 
>    (don't know which ones are important... but it works with all of it)
> 
> make distclean >/tmp/xen.distclean.log 2>&1 ; status=$? ; echo $status
> 
> if [ -e configure ]; then
>    ./configure
> else
>    touch .config
> fi
> 
> make dist >/tmp/xen.dist.log 2>&1 ; status=$? ; echo $status
> 
> 
> ==========
> my install process
> ==========
> 
> To install the build, it's important to clean out old lib files...
> uninstall doesn't get them all. If you miss these, xm, xl, etc. may fail
> due to shared library issues.
> 
> Also, "make uninstall" deletes important system files it should not
> (kernel, kernel modules, vm disks).
> 
> As it says in the "make help":
>  uninstall        - attempt to remove installed Xen tools
>                     (use with extreme care!)
> 
> Here is my process to solve the uninstall issues:
> http://pastebin.com/nXCavFTp


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 14:00:18 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 14:00:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQIY2-0002qd-Vp; Mon, 22 Oct 2012 14:00:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TQIY1-0002qY-HL
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 14:00:05 +0000
Received: from [85.158.139.211:11041] by server-9.bemta-5.messagelabs.com id
	08/1E-23053-46155805; Mon, 22 Oct 2012 14:00:04 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-206.messagelabs.com!1350914403!23275976!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9472 invoked from network); 22 Oct 2012 14:00:03 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Oct 2012 14:00:03 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TQIXI-0003fb-3d; Mon, 22 Oct 2012 13:59:20 +0000
Date: Mon, 22 Oct 2012 14:59:20 +0100
From: Tim Deegan 
To: Peter Maloney 
Message-ID: <20121022135920.GE12577@ocelot.phlegethon.org>
References: <5082DD8C.2030608@brockmann-consult.de>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5082DD8C.2030608@brockmann-consult.de>
User-Agent: Mutt/1.4.2.1i
Cc: Andres Lagar-Cavilla , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen-unstable,
	winxp32 very poor performance on AMD FX-8150,
	I bisected and changeset is 24770:7f79475d3de7
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 19:21 +0200 on 20 Oct (1350760876), Peter Maloney wrote:
> I ran a bisect to find out when Windows XP 32 bit becomes unusably slow.
> And I found the changeset that caused it.
> 
> ==========
> The problem:
> ==========
> 
> Windows 8 64 bit and 32 bit run fast and fine in the newest xen versions.
> 
> Windows XP 32 bit runs unusably slow in anything new that I built from
> xen-unstable, but runs fast in 4.1.2 and 4.1.3 stable. While it is
> running slow, "xm top" or "xl top" show cpu usage around 650% for the domu.
> 
> The bug might be AMD specific. I'm running an AMD FX-8150.

The bug does seem to be AMD-specific, and NPT-specific; with
'hap=0' it goes much faster. 

> ==========
> The result:
> ==========
> 
> good: 24769:730f6ed72d70
> bad: 24770:7f79475d3de7
> 
> The change was 8 months ago
> 
> changeset:   24770:7f79475d3de7
> user:        Andres Lagar-Cavilla 
> date:        Fri Feb 10 16:07:07 2012 +0000
> summary:     x86/mm: Make p2m lookups fully synchronized wrt modifications

This change was bad for performnace across the board and most of it has
since been either reverted or amended, but clearly we missed something
here. 

It's interesting that Win8 isn't slowed down.  I wonder whether that's to
do with the way it drives the VGA card -- IIRC it uses a generic VESA
driver rather than a Cirrus one. 

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 14:00:18 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 14:00:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQIY2-0002qd-Vp; Mon, 22 Oct 2012 14:00:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TQIY1-0002qY-HL
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 14:00:05 +0000
Received: from [85.158.139.211:11041] by server-9.bemta-5.messagelabs.com id
	08/1E-23053-46155805; Mon, 22 Oct 2012 14:00:04 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-206.messagelabs.com!1350914403!23275976!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9472 invoked from network); 22 Oct 2012 14:00:03 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Oct 2012 14:00:03 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TQIXI-0003fb-3d; Mon, 22 Oct 2012 13:59:20 +0000
Date: Mon, 22 Oct 2012 14:59:20 +0100
From: Tim Deegan 
To: Peter Maloney 
Message-ID: <20121022135920.GE12577@ocelot.phlegethon.org>
References: <5082DD8C.2030608@brockmann-consult.de>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5082DD8C.2030608@brockmann-consult.de>
User-Agent: Mutt/1.4.2.1i
Cc: Andres Lagar-Cavilla , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen-unstable,
	winxp32 very poor performance on AMD FX-8150,
	I bisected and changeset is 24770:7f79475d3de7
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 19:21 +0200 on 20 Oct (1350760876), Peter Maloney wrote:
> I ran a bisect to find out when Windows XP 32 bit becomes unusably slow.
> And I found the changeset that caused it.
> 
> ==========
> The problem:
> ==========
> 
> Windows 8 64 bit and 32 bit run fast and fine in the newest xen versions.
> 
> Windows XP 32 bit runs unusably slow in anything new that I built from
> xen-unstable, but runs fast in 4.1.2 and 4.1.3 stable. While it is
> running slow, "xm top" or "xl top" show cpu usage around 650% for the domu.
> 
> The bug might be AMD specific. I'm running an AMD FX-8150.

The bug does seem to be AMD-specific, and NPT-specific; with
'hap=0' it goes much faster. 

> ==========
> The result:
> ==========
> 
> good: 24769:730f6ed72d70
> bad: 24770:7f79475d3de7
> 
> The change was 8 months ago
> 
> changeset:   24770:7f79475d3de7
> user:        Andres Lagar-Cavilla 
> date:        Fri Feb 10 16:07:07 2012 +0000
> summary:     x86/mm: Make p2m lookups fully synchronized wrt modifications

This change was bad for performnace across the board and most of it has
since been either reverted or amended, but clearly we missed something
here. 

It's interesting that Win8 isn't slowed down.  I wonder whether that's to
do with the way it drives the VGA card -- IIRC it uses a generic VESA
driver rather than a Cirrus one. 

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 14:42:35 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 14:42:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQJCA-0003Ng-1o; Mon, 22 Oct 2012 14:41:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQJC7-0003Nb-Tn
	for xen-devel@lists.xensource.com; Mon, 22 Oct 2012 14:41:32 +0000
Received: from [85.158.138.51:34030] by server-3.bemta-3.messagelabs.com id
	DA/D7-09368-B1B55805; Mon, 22 Oct 2012 14:41:31 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1350916889!27239382!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODQwNzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17761 invoked from network); 22 Oct 2012 14:41:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 14:41:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,630,1344211200"; d="scan'208";a="212049750"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Oct 2012 14:41:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 22 Oct 2012 10:41:28 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TQJC3-00057S-SL;
	Mon, 22 Oct 2012 15:41:27 +0100
Message-ID: <508559E8.10102@eu.citrix.com>
Date: Mon, 22 Oct 2012 15:36:24 +0100
From: George Dunlap 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: ZhouPeng 
References: 
	<1338987918.32319.84.camel@zakaz.uk.xensource.com>
	
	<1339049291.6557.11.camel@dagon.hellion.org.uk>
	
	<1341325462.21547.20.camel@zakaz.uk.xensource.com>
	
	
	
In-Reply-To: 
Cc: "Xen-Devel \(E-mail\)" ,
	Ian Jackson ,
	Ian Campbell ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 2/3] tools:libxl: Add qxl vga interface
 support v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 18/10/12 11:19, ZhouPeng wrote:
> v4
>
> test and fix conflict with the latest Xen
> -----
>
>
> tools:libxl: Add qxl vga interface support for upstream-qemu-xen.
>
> Usage:
>    qxl=1|0
>
> Signed-off-by: Zhou Peng 

Thanks, Zhou Peng.  Just a couple of comments below:

>
> diff -r c1c549c4fe9e docs/man/xl.cfg.pod.5
> --- a/docs/man/xl.cfg.pod.5	Mon Oct 15 16:51:44 2012 +0100
> +++ b/docs/man/xl.cfg.pod.5	Thu Oct 18 17:53:25 2012 +0800
> @@ -930,10 +930,13 @@ in the B for configurin
>
>   Sets the amount of RAM which the emulated video card will contain,
>   which in turn limits the resolutions and bit depths which will be
> -available. This option is only available when using the B
> -option (see below).
> +available. This option is only available when using the B and
> +B option (see below).
>   The default amount of video ram for stdvga is 8MB which is sufficient
>   for e.g. 1600x1200 at 32bpp.
> +For B option, the default is 128MB. If B is set greater
> +than 128MB, it will be trimmed to 128MB; if set less than 128MB, an
> +error will be triggered.

Is this a fixed value in qemu, or is this something that can be changed 
via the command-line?

> +
> +        if (b_info->device_model_version == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN
> +            && b_info->u.hvm.vga.kind == LIBXL_VGA_INTERFACE_TYPE_QXL) {
> +            /*
> +             * QXL needs 128 Mib video ram by default.
> +             */
> +            if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT) {
> +                b_info->video_memkb = 128 * 1024;
> +            }
> +            if (b_info->video_memkb < 128 * 1024) {
> +                LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
> +                    "128 Mib videoram is necessary for qxl default");
> +                return ERROR_INVAL;
> +            }
> +            if (b_info->video_memkb > 128 * 1024) {
> +                b_info->video_memkb = 128 * 1024;
> +                LIBXL__LOG(CTX, LIBXL__LOG_WARNING,
> +                            "trim videoram to qxl default: 128 Mib");
> +            }
> +        }

It would be better to have a single #define for the required QXL video 
mem size, rather than duplicating "128*1024" several times.

Other than that, looks pretty good to me.

Thanks,
  -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 14:42:35 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 14:42:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQJCA-0003Ng-1o; Mon, 22 Oct 2012 14:41:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQJC7-0003Nb-Tn
	for xen-devel@lists.xensource.com; Mon, 22 Oct 2012 14:41:32 +0000
Received: from [85.158.138.51:34030] by server-3.bemta-3.messagelabs.com id
	DA/D7-09368-B1B55805; Mon, 22 Oct 2012 14:41:31 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1350916889!27239382!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODQwNzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17761 invoked from network); 22 Oct 2012 14:41:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 14:41:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,630,1344211200"; d="scan'208";a="212049750"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Oct 2012 14:41:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 22 Oct 2012 10:41:28 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TQJC3-00057S-SL;
	Mon, 22 Oct 2012 15:41:27 +0100
Message-ID: <508559E8.10102@eu.citrix.com>
Date: Mon, 22 Oct 2012 15:36:24 +0100
From: George Dunlap 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: ZhouPeng 
References: 
	<1338987918.32319.84.camel@zakaz.uk.xensource.com>
	
	<1339049291.6557.11.camel@dagon.hellion.org.uk>
	
	<1341325462.21547.20.camel@zakaz.uk.xensource.com>
	
	
	
In-Reply-To: 
Cc: "Xen-Devel \(E-mail\)" ,
	Ian Jackson ,
	Ian Campbell ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 2/3] tools:libxl: Add qxl vga interface
 support v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 18/10/12 11:19, ZhouPeng wrote:
> v4
>
> test and fix conflict with the latest Xen
> -----
>
>
> tools:libxl: Add qxl vga interface support for upstream-qemu-xen.
>
> Usage:
>    qxl=1|0
>
> Signed-off-by: Zhou Peng 

Thanks, Zhou Peng.  Just a couple of comments below:

>
> diff -r c1c549c4fe9e docs/man/xl.cfg.pod.5
> --- a/docs/man/xl.cfg.pod.5	Mon Oct 15 16:51:44 2012 +0100
> +++ b/docs/man/xl.cfg.pod.5	Thu Oct 18 17:53:25 2012 +0800
> @@ -930,10 +930,13 @@ in the B for configurin
>
>   Sets the amount of RAM which the emulated video card will contain,
>   which in turn limits the resolutions and bit depths which will be
> -available. This option is only available when using the B
> -option (see below).
> +available. This option is only available when using the B and
> +B option (see below).
>   The default amount of video ram for stdvga is 8MB which is sufficient
>   for e.g. 1600x1200 at 32bpp.
> +For B option, the default is 128MB. If B is set greater
> +than 128MB, it will be trimmed to 128MB; if set less than 128MB, an
> +error will be triggered.

Is this a fixed value in qemu, or is this something that can be changed 
via the command-line?

> +
> +        if (b_info->device_model_version == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN
> +            && b_info->u.hvm.vga.kind == LIBXL_VGA_INTERFACE_TYPE_QXL) {
> +            /*
> +             * QXL needs 128 Mib video ram by default.
> +             */
> +            if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT) {
> +                b_info->video_memkb = 128 * 1024;
> +            }
> +            if (b_info->video_memkb < 128 * 1024) {
> +                LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
> +                    "128 Mib videoram is necessary for qxl default");
> +                return ERROR_INVAL;
> +            }
> +            if (b_info->video_memkb > 128 * 1024) {
> +                b_info->video_memkb = 128 * 1024;
> +                LIBXL__LOG(CTX, LIBXL__LOG_WARNING,
> +                            "trim videoram to qxl default: 128 Mib");
> +            }
> +        }

It would be better to have a single #define for the required QXL video 
mem size, rather than duplicating "128*1024" several times.

Other than that, looks pretty good to me.

Thanks,
  -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 14:49:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 14:49:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQJJ6-0003hX-Ic; Mon, 22 Oct 2012 14:48:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQJJ4-0003hS-UC
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 14:48:43 +0000
Received: from [85.158.138.51:18662] by server-12.bemta-3.messagelabs.com id
	32/EA-27853-ACC55805; Mon, 22 Oct 2012 14:48:42 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-174.messagelabs.com!1350917321!27240166!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDUwNzI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDUwNzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9395 invoked from network); 22 Oct 2012 14:48:41 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Oct 2012 14:48:41 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq0M7qF/64
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-079-154.pools.arcor-ip.net [84.57.79.154])
	by smtp.strato.de (joses mo7) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 6069f7o9MEEvdC ;
	Mon, 22 Oct 2012 16:48:41 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id A82F518642; Mon, 22 Oct 2012 16:48:40 +0200 (CEST)
Date: Mon, 22 Oct 2012 16:48:40 +0200
From: Olaf Hering 
To: Andres Lagar-Cavilla 
Message-ID: <20121022144840.GA22644@aepfle.de>
References: 
	<918914F5-6729-40C8-8D46-5EABB8FAB35B@gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <918914F5-6729-40C8-8D46-5EABB8FAB35B@gridcentric.ca>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] hvm: handle PoD and grant pages in
	HVMOP_get_mem_type
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 19, Andres Lagar-Cavilla wrote:

> > +            else if ( p2m_is_magic(t) )
> > +                a.mem_type =  HVMMEM_ram_rw;
> p2m_is_magic is this bizarre thing that should just be p2m_is_pod. Can
> you take advantage of this opportunity and fix it?

I will prepare a separate patch for that rename.

> > +            else if ( p2m_is_grant(t) )
> > +                a.mem_type =  HVMMEM_ram_rw;
> 
> Yes there can be p2m_is_grant pages in an HVM, if it is running a
> backend. Note that you need to discriminate whether the grant is
> mapped writable in order to return ram_rw or ram_ro.

I will put p2m_grant_map_rw into HVMMEM_ram_rw, and p2m_grant_map_ro
into HVMMEM_ram_ro.

> It might be a good idea to extend this interface to return
> HVMMEM_grant_rw/ro. These are, in essence, different types of ram from
> an HVM point of view. However, it might be overkill for the current
> users.

Would the guest really care about the info that a given page is a grant
page? What would it do with that info?


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 14:49:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 14:49:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQJJ6-0003hX-Ic; Mon, 22 Oct 2012 14:48:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQJJ4-0003hS-UC
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 14:48:43 +0000
Received: from [85.158.138.51:18662] by server-12.bemta-3.messagelabs.com id
	32/EA-27853-ACC55805; Mon, 22 Oct 2012 14:48:42 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-174.messagelabs.com!1350917321!27240166!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDUwNzI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDUwNzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9395 invoked from network); 22 Oct 2012 14:48:41 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Oct 2012 14:48:41 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq0M7qF/64
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-079-154.pools.arcor-ip.net [84.57.79.154])
	by smtp.strato.de (joses mo7) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 6069f7o9MEEvdC ;
	Mon, 22 Oct 2012 16:48:41 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id A82F518642; Mon, 22 Oct 2012 16:48:40 +0200 (CEST)
Date: Mon, 22 Oct 2012 16:48:40 +0200
From: Olaf Hering 
To: Andres Lagar-Cavilla 
Message-ID: <20121022144840.GA22644@aepfle.de>
References: 
	<918914F5-6729-40C8-8D46-5EABB8FAB35B@gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <918914F5-6729-40C8-8D46-5EABB8FAB35B@gridcentric.ca>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] hvm: handle PoD and grant pages in
	HVMOP_get_mem_type
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 19, Andres Lagar-Cavilla wrote:

> > +            else if ( p2m_is_magic(t) )
> > +                a.mem_type =  HVMMEM_ram_rw;
> p2m_is_magic is this bizarre thing that should just be p2m_is_pod. Can
> you take advantage of this opportunity and fix it?

I will prepare a separate patch for that rename.

> > +            else if ( p2m_is_grant(t) )
> > +                a.mem_type =  HVMMEM_ram_rw;
> 
> Yes there can be p2m_is_grant pages in an HVM, if it is running a
> backend. Note that you need to discriminate whether the grant is
> mapped writable in order to return ram_rw or ram_ro.

I will put p2m_grant_map_rw into HVMMEM_ram_rw, and p2m_grant_map_ro
into HVMMEM_ram_ro.

> It might be a good idea to extend this interface to return
> HVMMEM_grant_rw/ro. These are, in essence, different types of ram from
> an HVM point of view. However, it might be overkill for the current
> users.

Would the guest really care about the info that a given page is a grant
page? What would it do with that info?


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 14:49:40 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 14:49:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQJJj-0003kD-61; Mon, 22 Oct 2012 14:49:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQJJi-0003k6-0u
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 14:49:22 +0000
Received: from [85.158.139.211:48130] by server-12.bemta-5.messagelabs.com id
	9E/7F-26919-1FC55805; Mon, 22 Oct 2012 14:49:21 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1350917360!23278566!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUxNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7407 invoked from network); 22 Oct 2012 14:49:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 14:49:20 -0000
X-IronPort-AV: E=Sophos;i="4.80,630,1344211200"; d="scan'208";a="15312584"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Oct 2012 14:49:17 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Mon, 22 Oct 2012
	15:49:17 +0100
From: Frediano Ziglio 
To: Ian Campbell , David Vrabel
	,
	"konrad.wilk@oracle.com" 
Date: Mon, 22 Oct 2012 15:49:16 +0100
Thread-Topic: Trying to reproduce %eip corruption
Thread-Index: Ac2wZGkq/r5ZbLK9TPefYrXOmKB8jw==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC2E08D04090C@LONPMAILBOX01.citrite.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "stable@kernel.org" ,
	"xen-devel@lists.xen.org" 
Subject: [Xen-devel] Trying to reproduce %eip corruption
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,
  I was trying to reproduce the error of %eip corruption and I manage to
get a small test program (from my previous one).

----------
/*
 * This program try to cause an exception raising a Xen failsafe callback
 * The idea is:
 * - one thread execute an infinite loop with some int3 instructions before
 *   and a CS segment allocated in LDT while handling a timer signal
 * - another thread just make sure that first is in the infinite loop and
 *   set CS to cause an exception on the first one
 * The first thread does not core just after the LDT change cause CS is cached
 * to it crash when kernel try to return to it.
 * Actually the first one running in the infinite loop can be stopped only by
 * an hardware interrupt so you have a Xen callback which try to return and
 * get an exception while doing IRET
 */
#undef NDEBUG
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#define LDT_READ  0
#define LDT_WRITE 1

static void handler(int sig)
{
	static unsigned count = 0;
	if (++count == 60 * 1000)
		exit(0);
}

static void segv_handler(int sig)
{
	exit(0);
}

static int cs_ldt = -1;
static void
change_cs(void)
{
	struct user_desc desc;

	/* fills desc which represents the code segment */
	desc.entry_number = 0;
	desc.base_addr = 0;
	desc.limit = 0xffffffffu >> 12;
	desc.seg_32bit = 0x1;
	desc.contents = 0x2;
	desc.read_exec_only = 0x1;
	desc.limit_in_pages = 0x1;
	desc.seg_not_present = 0x0;
	desc.useable = 0x1;

	/* Writes a user_desc struct to the ldt */
	int err = syscall(SYS_modify_ldt, LDT_WRITE,
			  &desc, sizeof(desc));
	assert(!err);

	/* set cs to our selector to be able to make it core */
	asm(
"	pushl %eax\n"
"	movl $0x7, %eax\n" /* 0111: 0-Index 1-Using the LDT table 11-RPL of 3 */
"	pushl %eax\n"
"	pushl $1f\n"
"	retf\n"
"1:\n"
"	popl %eax\n"
	);

	cs_ldt = (desc.entry_number << 3) | 7;
}

static void *
corrupt_cs(void *arg)
{
	/* this assure that we set the selector while in the loop */
	sleep(2);
	assert(cs_ldt >= 0);

	struct user_desc desc;

	/* fills desc which represents the code segment */
	desc.entry_number = cs_ldt >> 3;
	desc.base_addr = 0;
	desc.limit = 1;
	desc.seg_32bit = 0x1;
	desc.contents = 0x2;
	desc.read_exec_only = 0x1;
	desc.limit_in_pages = 0x1;
	desc.seg_not_present = 0x1;
	desc.useable = 0x1;

	/* Writes a user_desc struct to the ldt */
	int err = syscall(SYS_modify_ldt, LDT_WRITE,
			  &desc, sizeof(desc));
	assert(!err);

	return NULL;
}

static void
faulty(void)
{
#if !defined(__x86_64__) && !defined(__i386__)
# error This code work only on Intel architecture!
#endif

	// wait for a core !!
	asm(
#ifdef __x86_64__
"	mov	$-513, %rax\n"
#else
"	mov	$-513, %eax\n"
#endif
"	jmp	1f\n"
"	int	$3\n"
"	int	$3\n"
"	int	$3\n"
"	int	$3\n"
"1:\n"
"	jmp	1b\n"
	);
}

int main(void)
{
	struct sigaction act;

	// set signal
	sigfillset(&act.sa_mask);
	act.sa_flags = 0;
	act.sa_handler = handler;

	int err = sigaction(SIGALRM, &act, NULL);
	assert(!err);

	act.sa_handler = segv_handler;
	err = sigaction(SIGSEGV, &act, NULL);
	assert(!err);

	// set timer
	struct itimerval ival = { { 0, 1000 }, { 0, 1000 } };
	err = setitimer(ITIMER_REAL, &ival, NULL);
	assert(!err);

	pthread_t thread_id;
	err = pthread_create(&thread_id, NULL, corrupt_cs, NULL);
	assert(!err);

	/* for some reasons pthread_create restre original cs */
	change_cs();

	/* faulting with SEGV is ok! */
	faulty();

	return 0;
}
----------

I run the program with this shell script

----------
#!/bin/bash

set -e
cd /
test -x xencore32
while true; do
	echo running test
	set +e
	su nobody -s /xencore32 && echo ok
	set -e
done
----------

The problems are now two:
- when program crash "normally" is cause an invalid instruction to be
executed while it should raise a SEGV
- sometimes it crashes very badly with an exception on the kernel and
after a couple of time you can be lucky and have your dom0 quite
useless.

When it crashes very badly I got this on screen (I couldn't use dmesg)

[ 242.372564] Process xencore32 (pid: 6645, ti=e797e000 task=e98957f0
task.ti=e797e000)
[ 242.372615] Stack:
[ 242.372665] Call Trace:
[ 242.372691]   
[ 242.373864] Process xencore32 (pid: 6645, ti=e797e000 task=e98957f0
task.ti=e797e000)
[ 242.373916] Stack:
[ 242.374243] Call Trace:
[ 242.374803] Code: 8b 4d 10 85 c9 74 13 3b 5d 10 73 32 8b 45 10 2d 00
20 00 00 39 c3 73 13 eb 24 3b 5d f0 76 1f 8b 45 f0 05 fc 1f 00 00 39 c3
[  242.375302] EIP: [] print_context_stack+0x94/0xc0 SS:ESP
0069:e797fe00

Anybody has some hint on how to resolve this problem?

Regards
  Frediano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 14:49:40 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 14:49:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQJJj-0003kD-61; Mon, 22 Oct 2012 14:49:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQJJi-0003k6-0u
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 14:49:22 +0000
Received: from [85.158.139.211:48130] by server-12.bemta-5.messagelabs.com id
	9E/7F-26919-1FC55805; Mon, 22 Oct 2012 14:49:21 +0000
X-Env-Sender: frediano.ziglio@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1350917360!23278566!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUxNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7407 invoked from network); 22 Oct 2012 14:49:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 14:49:20 -0000
X-IronPort-AV: E=Sophos;i="4.80,630,1344211200"; d="scan'208";a="15312584"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Oct 2012 14:49:17 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Mon, 22 Oct 2012
	15:49:17 +0100
From: Frediano Ziglio 
To: Ian Campbell , David Vrabel
	,
	"konrad.wilk@oracle.com" 
Date: Mon, 22 Oct 2012 15:49:16 +0100
Thread-Topic: Trying to reproduce %eip corruption
Thread-Index: Ac2wZGkq/r5ZbLK9TPefYrXOmKB8jw==
Message-ID: <7CE799CC0E4DE04B88D5FDF226E18AC2E08D04090C@LONPMAILBOX01.citrite.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "stable@kernel.org" ,
	"xen-devel@lists.xen.org" 
Subject: [Xen-devel] Trying to reproduce %eip corruption
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,
  I was trying to reproduce the error of %eip corruption and I manage to
get a small test program (from my previous one).

----------
/*
 * This program try to cause an exception raising a Xen failsafe callback
 * The idea is:
 * - one thread execute an infinite loop with some int3 instructions before
 *   and a CS segment allocated in LDT while handling a timer signal
 * - another thread just make sure that first is in the infinite loop and
 *   set CS to cause an exception on the first one
 * The first thread does not core just after the LDT change cause CS is cached
 * to it crash when kernel try to return to it.
 * Actually the first one running in the infinite loop can be stopped only by
 * an hardware interrupt so you have a Xen callback which try to return and
 * get an exception while doing IRET
 */
#undef NDEBUG
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#define LDT_READ  0
#define LDT_WRITE 1

static void handler(int sig)
{
	static unsigned count = 0;
	if (++count == 60 * 1000)
		exit(0);
}

static void segv_handler(int sig)
{
	exit(0);
}

static int cs_ldt = -1;
static void
change_cs(void)
{
	struct user_desc desc;

	/* fills desc which represents the code segment */
	desc.entry_number = 0;
	desc.base_addr = 0;
	desc.limit = 0xffffffffu >> 12;
	desc.seg_32bit = 0x1;
	desc.contents = 0x2;
	desc.read_exec_only = 0x1;
	desc.limit_in_pages = 0x1;
	desc.seg_not_present = 0x0;
	desc.useable = 0x1;

	/* Writes a user_desc struct to the ldt */
	int err = syscall(SYS_modify_ldt, LDT_WRITE,
			  &desc, sizeof(desc));
	assert(!err);

	/* set cs to our selector to be able to make it core */
	asm(
"	pushl %eax\n"
"	movl $0x7, %eax\n" /* 0111: 0-Index 1-Using the LDT table 11-RPL of 3 */
"	pushl %eax\n"
"	pushl $1f\n"
"	retf\n"
"1:\n"
"	popl %eax\n"
	);

	cs_ldt = (desc.entry_number << 3) | 7;
}

static void *
corrupt_cs(void *arg)
{
	/* this assure that we set the selector while in the loop */
	sleep(2);
	assert(cs_ldt >= 0);

	struct user_desc desc;

	/* fills desc which represents the code segment */
	desc.entry_number = cs_ldt >> 3;
	desc.base_addr = 0;
	desc.limit = 1;
	desc.seg_32bit = 0x1;
	desc.contents = 0x2;
	desc.read_exec_only = 0x1;
	desc.limit_in_pages = 0x1;
	desc.seg_not_present = 0x1;
	desc.useable = 0x1;

	/* Writes a user_desc struct to the ldt */
	int err = syscall(SYS_modify_ldt, LDT_WRITE,
			  &desc, sizeof(desc));
	assert(!err);

	return NULL;
}

static void
faulty(void)
{
#if !defined(__x86_64__) && !defined(__i386__)
# error This code work only on Intel architecture!
#endif

	// wait for a core !!
	asm(
#ifdef __x86_64__
"	mov	$-513, %rax\n"
#else
"	mov	$-513, %eax\n"
#endif
"	jmp	1f\n"
"	int	$3\n"
"	int	$3\n"
"	int	$3\n"
"	int	$3\n"
"1:\n"
"	jmp	1b\n"
	);
}

int main(void)
{
	struct sigaction act;

	// set signal
	sigfillset(&act.sa_mask);
	act.sa_flags = 0;
	act.sa_handler = handler;

	int err = sigaction(SIGALRM, &act, NULL);
	assert(!err);

	act.sa_handler = segv_handler;
	err = sigaction(SIGSEGV, &act, NULL);
	assert(!err);

	// set timer
	struct itimerval ival = { { 0, 1000 }, { 0, 1000 } };
	err = setitimer(ITIMER_REAL, &ival, NULL);
	assert(!err);

	pthread_t thread_id;
	err = pthread_create(&thread_id, NULL, corrupt_cs, NULL);
	assert(!err);

	/* for some reasons pthread_create restre original cs */
	change_cs();

	/* faulting with SEGV is ok! */
	faulty();

	return 0;
}
----------

I run the program with this shell script

----------
#!/bin/bash

set -e
cd /
test -x xencore32
while true; do
	echo running test
	set +e
	su nobody -s /xencore32 && echo ok
	set -e
done
----------

The problems are now two:
- when program crash "normally" is cause an invalid instruction to be
executed while it should raise a SEGV
- sometimes it crashes very badly with an exception on the kernel and
after a couple of time you can be lucky and have your dom0 quite
useless.

When it crashes very badly I got this on screen (I couldn't use dmesg)

[ 242.372564] Process xencore32 (pid: 6645, ti=e797e000 task=e98957f0
task.ti=e797e000)
[ 242.372615] Stack:
[ 242.372665] Call Trace:
[ 242.372691]   
[ 242.373864] Process xencore32 (pid: 6645, ti=e797e000 task=e98957f0
task.ti=e797e000)
[ 242.373916] Stack:
[ 242.374243] Call Trace:
[ 242.374803] Code: 8b 4d 10 85 c9 74 13 3b 5d 10 73 32 8b 45 10 2d 00
20 00 00 39 c3 73 13 eb 24 3b 5d f0 76 1f 8b 45 f0 05 fc 1f 00 00 39 c3
[  242.375302] EIP: [] print_context_stack+0x94/0xc0 SS:ESP
0069:e797fe00

Anybody has some hint on how to resolve this problem?

Regards
  Frediano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 14:52:15 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 14:52:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQJMF-00040K-9Z; Mon, 22 Oct 2012 14:51:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQJMD-0003zt-Qr
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 14:51:58 +0000
Received: from [193.109.254.147:29228] by server-1.bemta-14.messagelabs.com id
	B9/A6-20415-C8D55805; Mon, 22 Oct 2012 14:51:56 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1350917512!10968564!2
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16852 invoked from network); 22 Oct 2012 14:51:54 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 14:51:54 -0000
Received: by mail-wg0-f51.google.com with SMTP id ed3so1695350wgb.32
	for ; Mon, 22 Oct 2012 07:51:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=QeCqCKdnnKYtAdtGUuch92Qm1RNMgeJhaFGzRjQ44+o=;
	b=RnPIW03aZsGFV41Ibh/LgG9XVeJ8/Mw1e3csNw2hlnNSkkc/k4uatBzPwBGfv42jHq
	O3cFPItrSpfeOHK9qdt521R7jZUmqJWT9qkFEY6fmbtsWDaGPi0xSlZR9yL7q671qe4P
	2PZyUlD8QI5b61wfgquw0iy0JYdiQP6p5lDo586Hw66DUwUFJMbfXjJf5Mp56zor757L
	wJHjghA3h4bwAB5aMw5x04Sv+TlRSjTYeWQ6izxOhNLhn341judMJWdp0C0hFORuwlTW
	FMwa3tBKMevZ6a8HGBRYFFWXQAxGfHLwKlOESc5RMSJi1fkbGM9TjUsjSqe4MKBisOXe
	tbAg==
Received: by 10.181.13.239 with SMTP id fb15mr21789161wid.22.1350917514660;
	Mon, 22 Oct 2012 07:51:54 -0700 (PDT)
Received: from [127.0.1.1] (ip-180-234.sn1.eutelia.it. [62.94.180.234])
	by mx.google.com with ESMTPS id hv8sm14210969wib.0.2012.10.22.07.51.52
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 22 Oct 2012 07:51:53 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: f1b0058f9aedbd182e65509b710a4732678ad6cf
Message-Id: 
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.2.2
Date: Mon, 22 Oct 2012 16:40:34 +0200
From: Dario Faggioli 
To: xen-devel@lists.xen.org
Cc: George Dunlap ,
	Paul Durrant ,
	Keir Fraser , Jan Beulich 
Subject: [Xen-devel] [PATCH 1 of 6] xen: fix build when 'perfc=y'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

V2hpY2ggd2FzIGZhaWxpbmcgd2l0aCB0aGlzOgoKIHZpcmlkaWFuLmM6IEluIGZ1bmN0aW9uIOKA
mHdybXNyX3ZpcmlkaWFuX3JlZ3PigJk6CiB2aXJpZGlhbi5jOjI1NDoxOiBlcnJvcjog4oCYUEVS
RkNfbXNodl93cm1zcl9hcGljX21zcuKAmSB1bmRlY2xhcmVkIChmaXJzdCB1c2UgaW4gdGhpcyBm
dW5jdGlvbikKIHZpcmlkaWFuLmM6MjU0OjE6IG5vdGU6IGVhY2ggdW5kZWNsYXJlZCBpZGVudGlm
aWVyIGlzIHJlcG9ydGVkIG9ubHkgb25jZSBmb3IgZWFjaCBmdW5jdGlvbiBpdCBhcHBlYXJzIGlu
CiB2aXJpZGlhbi5jOiBJbiBmdW5jdGlvbiDigJhyZG1zcl92aXJpZGlhbl9yZWdz4oCZOgogdmly
aWRpYW4uYzozMDU6MTogZXJyb3I6IOKAmFBFUkZDX21zaHZfcmRtc3JfYXBpY19tc3LigJkgdW5k
ZWNsYXJlZCAoZmlyc3QgdXNlIGluIHRoaXMgZnVuY3Rpb24pCgphcyBhIGNvbnNlcXVlbmNlIG9m
IDE3Yjc1NGNhYjdiMCB1c2luZyBidXQgbm90IGRlZmluaW5nCnRoZSBjb3VudGVycy4KClNpZ25l
ZC1vZmYtYnk6IERhcmlvIEZhZ2dpb2xpIDxkYXJpby5mYWdnaW9saUBjaXRyaXguY29tPgoKZGlm
ZiAtLWdpdCBhL3hlbi9pbmNsdWRlL2FzbS14ODYvcGVyZmNfZGVmbi5oIGIveGVuL2luY2x1ZGUv
YXNtLXg4Ni9wZXJmY19kZWZuLmgKLS0tIGEveGVuL2luY2x1ZGUvYXNtLXg4Ni9wZXJmY19kZWZu
LmgKKysrIGIveGVuL2luY2x1ZGUvYXNtLXg4Ni9wZXJmY19kZWZuLmgKQEAgLTEyMSw2ICsxMjEs
NyBAQCBQRVJGQ09VTlRFUihtc2h2X3JkbXNyX3ZwX2luZGV4LCAgICAgICAgCiBQRVJGQ09VTlRF
Uihtc2h2X3JkbXNyX2ljciwgICAgICAgICAgICAgIk1TIEh2IHJkbXNyIGljciIpCiBQRVJGQ09V
TlRFUihtc2h2X3JkbXNyX3RwciwgICAgICAgICAgICAgIk1TIEh2IHJkbXNyIHRwciIpCiBQRVJG
Q09VTlRFUihtc2h2X3JkbXNyX2FwaWNfYXNzaXN0LCAgICAgIk1TIEh2IHJkbXNyIEFQSUMgYXNz
aXN0IikKK1BFUkZDT1VOVEVSKG1zaHZfcmRtc3JfYXBpY19tc3IsICAgICAgICAiTVMgSHYgcmRt
c3IgQVBJQyBtc3IiKQogUEVSRkNPVU5URVIobXNodl93cm1zcl9vc2lkLCAgICAgICAgICAgICJN
UyBIdiB3cm1zciBHdWVzdCBPUyBJRCIpCiBQRVJGQ09VTlRFUihtc2h2X3dybXNyX2hjX3BhZ2Us
ICAgICAgICAgIk1TIEh2IHdybXNyIGh5cGVyY2FsbCBwYWdlIikKIFBFUkZDT1VOVEVSKG1zaHZf
d3Jtc3JfdnBfaW5kZXgsICAgICAgICAiTVMgSHYgd3Jtc3IgdnAgaW5kZXgiKQpAQCAtMTI4LDYg
KzEyOSw3IEBAIFBFUkZDT1VOVEVSKG1zaHZfd3Jtc3JfaWNyLCAgICAgICAgICAgICAKIFBFUkZD
T1VOVEVSKG1zaHZfd3Jtc3JfdHByLCAgICAgICAgICAgICAiTVMgSHYgd3Jtc3IgdHByIikKIFBF
UkZDT1VOVEVSKG1zaHZfd3Jtc3JfZW9pLCAgICAgICAgICAgICAiTVMgSHYgd3Jtc3IgZW9pIikK
IFBFUkZDT1VOVEVSKG1zaHZfd3Jtc3JfYXBpY19hc3Npc3QsICAgICAiTVMgSHYgd3Jtc3IgQVBJ
QyBhc3Npc3QiKQorUEVSRkNPVU5URVIobXNodl93cm1zcl9hcGljX21zciwgICAgICAgICJNUyBI
diB3cm1zciBBUElDIG1zciIpCiAKIFBFUkZDT1VOVEVSKHJlYWxtb2RlX2VtdWxhdGlvbnMsICJy
ZWFsbW9kZSBpbnN0cnVjdGlvbnMgZW11bGF0ZWQiKQogUEVSRkNPVU5URVIocmVhbG1vZGVfZXhp
dHMsICAgICAgInZtZXhpdHMgZnJvbSByZWFsbW9kZSIpCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVs
QGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Mon Oct 22 14:52:15 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 14:52:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQJMM-00042w-5C; Mon, 22 Oct 2012 14:52:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQJMK-00040I-TX
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 14:52:05 +0000
Received: from [85.158.143.35:26136] by server-3.bemta-4.messagelabs.com id
	D8/E4-03544-49D55805; Mon, 22 Oct 2012 14:52:04 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1350917516!7433496!2
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.9 required=7.0 tests=DIET_1,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15252 invoked from network); 22 Oct 2012 14:52:03 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 14:52:03 -0000
Received: by mail-we0-f173.google.com with SMTP id t11so1878842wey.32
	for ; Mon, 22 Oct 2012 07:52:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=fq10DUSQhV27hVQGZabxaPoCTpRX6jKcQyjg/F6rgXw=;
	b=awQquyMBDNqDitD6tAUBM6JsMkR6Msg6XyU329d9o3hdfRyZ6Sg0fFWBD2izMc73J2
	Z9+9K26BFlP1m8BrjxI6MYOk4dZtChdsDWY3H5mEilqJAphui96cvxmUE3G+gVIULsvR
	jZbD+w2dtS2yqnimB0Z3UBQoUW2gndv38Foz7gaaLUOHbPG3BAk4WhXimZOi/X+4/mOD
	a5nlrxjUgi2HzhKsd6RFG9RvKBXTprmJTpSZ0iKD2UQ2CnSrxFGpyJNjLFkLzpvShPPw
	jc8vXkzgU3fU3c5AESvjA3ghAM0rlwrVOnP3auURRYOhKQz8nGtv9otwKM89cgYfKrZ5
	zfpg==
Received: by 10.180.75.161 with SMTP id d1mr694434wiw.1.1350917523021;
	Mon, 22 Oct 2012 07:52:03 -0700 (PDT)
Received: from [127.0.1.1] (ip-180-234.sn1.eutelia.it. [62.94.180.234])
	by mx.google.com with ESMTPS id hv8sm14210969wib.0.2012.10.22.07.52.00
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 22 Oct 2012 07:52:02 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 27c4c065efe366a5d7614930252a3c5905d5b24d
Message-Id: <27c4c065efe366a5d761.1350916838@Solace>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.2.2
Date: Mon, 22 Oct 2012 16:40:38 +0200
From: Dario Faggioli 
To: xen-devel@lists.xen.org
Cc: George Dunlap ,
	Paul Durrant ,
	Keir Fraser , Jan Beulich 
Subject: [Xen-devel] [PATCH 5 of 6] xen: sched_sedf: beautify statisics in
	SEDF
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

By gathering all the related fields in a struct (as it is being done
in credit) and using the macros we now have available. No functional
changes involved.

Signed-off-by: Dario Faggioli 

diff --git a/xen/common/sched_sedf.c b/xen/common/sched_sedf.c
--- a/xen/common/sched_sedf.c
+++ b/xen/common/sched_sedf.c
@@ -14,7 +14,6 @@
 #include 
 
 #ifndef NDEBUG
-#define SEDF_STATS
 #define CHECK(_p)                                           \
     do {                                                    \
         if ( !(_p) )                                        \
@@ -45,6 +44,37 @@
 #define IMPLY(a, b) (!(a) || (b))
 #define EQ(a, b) ((!!(a)) == (!!(b)))
 
+/*
+ * SEDF_STATS
+ *
+ * Some statistics about vCPU execution.
+ *
+ * Some of them are displayed with runq dumps
+ * ('r' on the Xen console).
+ */
+#ifdef SCHED_STATS
+
+#define SEDF_STATS
+
+#define SCHED_VCPU_STATS_RESET(_V)                      \
+    do                                                  \
+    {                                                   \
+        memset(&(_V)->stats, 0, sizeof((_V)->stats));   \
+    } while ( 0 )
+
+#define SCHED_VCPU_STAT_CRANK(_V, _X)       (((_V)->stats._X)++)
+
+/*#define SCHED_VCPU_STAT_SET(_V, _X, _Y)     (((_V)->stats._X) = (_Y))*/
+
+#else /* !SCHED_STATS */
+
+#undef SEDF_STATS
+
+#define SCHED_VCPU_STATS_RESET(_V)         do {} while ( 0 )
+#define SCHED_VCPU_STAT_CRANK(_V, _X)      do {} while ( 0 )
+/*#define SCHED_VCPU_STAT_SET(_V, _X, _Y)    do {} while ( 0 )*/
+
+#endif /* SCHED_STATS */
 
 struct sedf_dom_info {
     struct domain  *domain;
@@ -92,14 +122,16 @@ struct sedf_vcpu_info {
     s_time_t  extra_time_tot;
 
 #ifdef SEDF_STATS
-    s_time_t  block_time_tot;
-    s_time_t  penalty_time_tot;
-    int   block_tot;
-    int   short_block_tot;
-    int   long_block_tot;
-    int   short_cont;
-    int   pen_extra_blocks;
-    int   pen_extra_slices;
+    struct {
+        s_time_t block_time_tot;
+        s_time_t penalty_time_tot;
+        int block_tot;
+        int short_block_tot;
+        int long_block_tot;
+        int short_cont;
+        int pen_extra_blocks;
+        int pen_extra_slices;
+    } stats;
 #endif
 };
 
@@ -332,6 +364,7 @@ static void *sedf_alloc_vdata(const stru
     INIT_LIST_HEAD(&(inf->extralist[EXTRA_PEN_Q]));
     INIT_LIST_HEAD(&(inf->extralist[EXTRA_UTIL_Q]));
 
+    SCHED_VCPU_STATS_RESET(inf);
     SCHED_STAT_CRANK(vcpu_init);
 
     return inf;
@@ -688,9 +721,7 @@ static struct task_slice sedf_do_extra_s
         runinf->status |= EXTRA_RUN_PEN;
         ret.task = runinf->vcpu;
         ret.time = EXTRA_QUANTUM;
-#ifdef SEDF_STATS
-        runinf->pen_extra_slices++;
-#endif
+        SCHED_VCPU_STAT_CRANK(runinf, pen_extra_slices);
     }
     else
     {
@@ -989,9 +1020,7 @@ static void unblock_short_extra_support(
         {
             inf->score[0] = (inf->period << 10) /
                 inf->short_block_lost_tot;
-#ifdef SEDF_STATS
-            inf->pen_extra_blocks++;
-#endif
+            SCHED_VCPU_STAT_CRANK(inf, pen_extra_blocks);
             if ( extraq_on(inf->vcpu, EXTRA_PEN_Q) )
                 /* Remove domain for possible resorting! */
                 extraq_del(inf->vcpu, EXTRA_PEN_Q);
@@ -1108,9 +1137,7 @@ static void sedf_wake(const struct sched
         inf->deadl_abs = now + inf->slice;
     }
   
-#ifdef SEDF_STATS 
-    inf->block_tot++;
-#endif
+    SCHED_VCPU_STAT_CRANK(inf, block_tot);
 
     if ( unlikely(now < PERIOD_BEGIN(inf)) )
     {
@@ -1132,9 +1159,7 @@ static void sedf_wake(const struct sched
         if ( now < inf->deadl_abs )
         {
             /* Short blocking */
-#ifdef SEDF_STATS
-            inf->short_block_tot++;
-#endif
+            SCHED_VCPU_STAT_CRANK(inf, short_block_tot);
             unblock_short_extra_support(inf, now);
 
             extraq_check_add_unblocked(d, 1);
@@ -1142,9 +1167,7 @@ static void sedf_wake(const struct sched
         else
         {
             /* Long unblocking */
-#ifdef SEDF_STATS
-            inf->long_block_tot++;
-#endif
+            SCHED_VCPU_STAT_CRANK(inf, long_block_tot);
             unblock_long_cons_b(inf, now);
 
             extraq_check_add_unblocked(d, 1);
@@ -1160,8 +1183,8 @@ static void sedf_wake(const struct sched
     /* Do some statistics here... */
     if ( inf->block_abs != 0 )
     {
-        inf->block_time_tot += now - inf->block_abs;
-        inf->penalty_time_tot +=
+        inf->stats.block_time_tot += now - inf->block_abs;
+        inf->stats.penalty_time_tot +=
             PERIOD_BEGIN(inf) + inf->cputime - inf->block_abs;
     }
 #endif
@@ -1197,22 +1220,22 @@ static void sedf_dump_domain(struct vcpu
            EDOM_INFO(d)->extra_time_tot, EDOM_INFO(d)->extraweight);
     
 #ifdef SEDF_STATS
-    if ( EDOM_INFO(d)->block_time_tot != 0 )
-        printk(" pen=%"PRIu64"%%", (EDOM_INFO(d)->penalty_time_tot * 100) /
-               EDOM_INFO(d)->block_time_tot);
-    if ( EDOM_INFO(d)->block_tot != 0 )
+    if ( EDOM_INFO(d)->stats.block_time_tot != 0 )
+        printk(" pen=%"PRIu64"%%", (EDOM_INFO(d)->stats.penalty_time_tot * 100) /
+               EDOM_INFO(d)->stats.block_time_tot);
+    if ( EDOM_INFO(d)->stats.block_tot != 0 )
         printk("\n   blks=%u sh=%u (%u%%) (shc=%u (%u%%) shex=%i "\
                "shexsl=%i) l=%u (%u%%) avg: b=%"PRIu64" p=%"PRIu64"",
-               EDOM_INFO(d)->block_tot, EDOM_INFO(d)->short_block_tot,
-               (EDOM_INFO(d)->short_block_tot * 100) 
-               / EDOM_INFO(d)->block_tot, EDOM_INFO(d)->short_cont,
-               (EDOM_INFO(d)->short_cont * 100) / EDOM_INFO(d)->block_tot,
-               EDOM_INFO(d)->pen_extra_blocks,
-               EDOM_INFO(d)->pen_extra_slices,
-               EDOM_INFO(d)->long_block_tot,
-               (EDOM_INFO(d)->long_block_tot * 100) / EDOM_INFO(d)->block_tot,
-               (EDOM_INFO(d)->block_time_tot) / EDOM_INFO(d)->block_tot,
-               (EDOM_INFO(d)->penalty_time_tot) / EDOM_INFO(d)->block_tot);
+               EDOM_INFO(d)->stats.block_tot, EDOM_INFO(d)->stats.short_block_tot,
+               (EDOM_INFO(d)->stats.short_block_tot * 100) 
+               / EDOM_INFO(d)->stats.block_tot, EDOM_INFO(d)->stats.short_cont,
+               (EDOM_INFO(d)->stats.short_cont * 100) / EDOM_INFO(d)->stats.block_tot,
+               EDOM_INFO(d)->stats.pen_extra_blocks,
+               EDOM_INFO(d)->stats.pen_extra_slices,
+               EDOM_INFO(d)->stats.long_block_tot,
+               (EDOM_INFO(d)->stats.long_block_tot * 100) / EDOM_INFO(d)->stats.block_tot,
+               (EDOM_INFO(d)->stats.block_time_tot) / EDOM_INFO(d)->stats.block_tot,
+               (EDOM_INFO(d)->stats.penalty_time_tot) / EDOM_INFO(d)->stats.block_tot);
 #endif
     printk("\n");
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 14:52:15 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 14:52:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQJMF-00040K-9Z; Mon, 22 Oct 2012 14:51:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQJMD-0003zt-Qr
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 14:51:58 +0000
Received: from [193.109.254.147:29228] by server-1.bemta-14.messagelabs.com id
	B9/A6-20415-C8D55805; Mon, 22 Oct 2012 14:51:56 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1350917512!10968564!2
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16852 invoked from network); 22 Oct 2012 14:51:54 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 14:51:54 -0000
Received: by mail-wg0-f51.google.com with SMTP id ed3so1695350wgb.32
	for ; Mon, 22 Oct 2012 07:51:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=QeCqCKdnnKYtAdtGUuch92Qm1RNMgeJhaFGzRjQ44+o=;
	b=RnPIW03aZsGFV41Ibh/LgG9XVeJ8/Mw1e3csNw2hlnNSkkc/k4uatBzPwBGfv42jHq
	O3cFPItrSpfeOHK9qdt521R7jZUmqJWT9qkFEY6fmbtsWDaGPi0xSlZR9yL7q671qe4P
	2PZyUlD8QI5b61wfgquw0iy0JYdiQP6p5lDo586Hw66DUwUFJMbfXjJf5Mp56zor757L
	wJHjghA3h4bwAB5aMw5x04Sv+TlRSjTYeWQ6izxOhNLhn341judMJWdp0C0hFORuwlTW
	FMwa3tBKMevZ6a8HGBRYFFWXQAxGfHLwKlOESc5RMSJi1fkbGM9TjUsjSqe4MKBisOXe
	tbAg==
Received: by 10.181.13.239 with SMTP id fb15mr21789161wid.22.1350917514660;
	Mon, 22 Oct 2012 07:51:54 -0700 (PDT)
Received: from [127.0.1.1] (ip-180-234.sn1.eutelia.it. [62.94.180.234])
	by mx.google.com with ESMTPS id hv8sm14210969wib.0.2012.10.22.07.51.52
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 22 Oct 2012 07:51:53 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: f1b0058f9aedbd182e65509b710a4732678ad6cf
Message-Id: 
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.2.2
Date: Mon, 22 Oct 2012 16:40:34 +0200
From: Dario Faggioli 
To: xen-devel@lists.xen.org
Cc: George Dunlap ,
	Paul Durrant ,
	Keir Fraser , Jan Beulich 
Subject: [Xen-devel] [PATCH 1 of 6] xen: fix build when 'perfc=y'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

V2hpY2ggd2FzIGZhaWxpbmcgd2l0aCB0aGlzOgoKIHZpcmlkaWFuLmM6IEluIGZ1bmN0aW9uIOKA
mHdybXNyX3ZpcmlkaWFuX3JlZ3PigJk6CiB2aXJpZGlhbi5jOjI1NDoxOiBlcnJvcjog4oCYUEVS
RkNfbXNodl93cm1zcl9hcGljX21zcuKAmSB1bmRlY2xhcmVkIChmaXJzdCB1c2UgaW4gdGhpcyBm
dW5jdGlvbikKIHZpcmlkaWFuLmM6MjU0OjE6IG5vdGU6IGVhY2ggdW5kZWNsYXJlZCBpZGVudGlm
aWVyIGlzIHJlcG9ydGVkIG9ubHkgb25jZSBmb3IgZWFjaCBmdW5jdGlvbiBpdCBhcHBlYXJzIGlu
CiB2aXJpZGlhbi5jOiBJbiBmdW5jdGlvbiDigJhyZG1zcl92aXJpZGlhbl9yZWdz4oCZOgogdmly
aWRpYW4uYzozMDU6MTogZXJyb3I6IOKAmFBFUkZDX21zaHZfcmRtc3JfYXBpY19tc3LigJkgdW5k
ZWNsYXJlZCAoZmlyc3QgdXNlIGluIHRoaXMgZnVuY3Rpb24pCgphcyBhIGNvbnNlcXVlbmNlIG9m
IDE3Yjc1NGNhYjdiMCB1c2luZyBidXQgbm90IGRlZmluaW5nCnRoZSBjb3VudGVycy4KClNpZ25l
ZC1vZmYtYnk6IERhcmlvIEZhZ2dpb2xpIDxkYXJpby5mYWdnaW9saUBjaXRyaXguY29tPgoKZGlm
ZiAtLWdpdCBhL3hlbi9pbmNsdWRlL2FzbS14ODYvcGVyZmNfZGVmbi5oIGIveGVuL2luY2x1ZGUv
YXNtLXg4Ni9wZXJmY19kZWZuLmgKLS0tIGEveGVuL2luY2x1ZGUvYXNtLXg4Ni9wZXJmY19kZWZu
LmgKKysrIGIveGVuL2luY2x1ZGUvYXNtLXg4Ni9wZXJmY19kZWZuLmgKQEAgLTEyMSw2ICsxMjEs
NyBAQCBQRVJGQ09VTlRFUihtc2h2X3JkbXNyX3ZwX2luZGV4LCAgICAgICAgCiBQRVJGQ09VTlRF
Uihtc2h2X3JkbXNyX2ljciwgICAgICAgICAgICAgIk1TIEh2IHJkbXNyIGljciIpCiBQRVJGQ09V
TlRFUihtc2h2X3JkbXNyX3RwciwgICAgICAgICAgICAgIk1TIEh2IHJkbXNyIHRwciIpCiBQRVJG
Q09VTlRFUihtc2h2X3JkbXNyX2FwaWNfYXNzaXN0LCAgICAgIk1TIEh2IHJkbXNyIEFQSUMgYXNz
aXN0IikKK1BFUkZDT1VOVEVSKG1zaHZfcmRtc3JfYXBpY19tc3IsICAgICAgICAiTVMgSHYgcmRt
c3IgQVBJQyBtc3IiKQogUEVSRkNPVU5URVIobXNodl93cm1zcl9vc2lkLCAgICAgICAgICAgICJN
UyBIdiB3cm1zciBHdWVzdCBPUyBJRCIpCiBQRVJGQ09VTlRFUihtc2h2X3dybXNyX2hjX3BhZ2Us
ICAgICAgICAgIk1TIEh2IHdybXNyIGh5cGVyY2FsbCBwYWdlIikKIFBFUkZDT1VOVEVSKG1zaHZf
d3Jtc3JfdnBfaW5kZXgsICAgICAgICAiTVMgSHYgd3Jtc3IgdnAgaW5kZXgiKQpAQCAtMTI4LDYg
KzEyOSw3IEBAIFBFUkZDT1VOVEVSKG1zaHZfd3Jtc3JfaWNyLCAgICAgICAgICAgICAKIFBFUkZD
T1VOVEVSKG1zaHZfd3Jtc3JfdHByLCAgICAgICAgICAgICAiTVMgSHYgd3Jtc3IgdHByIikKIFBF
UkZDT1VOVEVSKG1zaHZfd3Jtc3JfZW9pLCAgICAgICAgICAgICAiTVMgSHYgd3Jtc3IgZW9pIikK
IFBFUkZDT1VOVEVSKG1zaHZfd3Jtc3JfYXBpY19hc3Npc3QsICAgICAiTVMgSHYgd3Jtc3IgQVBJ
QyBhc3Npc3QiKQorUEVSRkNPVU5URVIobXNodl93cm1zcl9hcGljX21zciwgICAgICAgICJNUyBI
diB3cm1zciBBUElDIG1zciIpCiAKIFBFUkZDT1VOVEVSKHJlYWxtb2RlX2VtdWxhdGlvbnMsICJy
ZWFsbW9kZSBpbnN0cnVjdGlvbnMgZW11bGF0ZWQiKQogUEVSRkNPVU5URVIocmVhbG1vZGVfZXhp
dHMsICAgICAgInZtZXhpdHMgZnJvbSByZWFsbW9kZSIpCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVs
QGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Mon Oct 22 14:52:15 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 14:52:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQJMM-00042w-5C; Mon, 22 Oct 2012 14:52:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQJMK-00040I-TX
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 14:52:05 +0000
Received: from [85.158.143.35:26136] by server-3.bemta-4.messagelabs.com id
	D8/E4-03544-49D55805; Mon, 22 Oct 2012 14:52:04 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1350917516!7433496!2
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.9 required=7.0 tests=DIET_1,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15252 invoked from network); 22 Oct 2012 14:52:03 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 14:52:03 -0000
Received: by mail-we0-f173.google.com with SMTP id t11so1878842wey.32
	for ; Mon, 22 Oct 2012 07:52:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=fq10DUSQhV27hVQGZabxaPoCTpRX6jKcQyjg/F6rgXw=;
	b=awQquyMBDNqDitD6tAUBM6JsMkR6Msg6XyU329d9o3hdfRyZ6Sg0fFWBD2izMc73J2
	Z9+9K26BFlP1m8BrjxI6MYOk4dZtChdsDWY3H5mEilqJAphui96cvxmUE3G+gVIULsvR
	jZbD+w2dtS2yqnimB0Z3UBQoUW2gndv38Foz7gaaLUOHbPG3BAk4WhXimZOi/X+4/mOD
	a5nlrxjUgi2HzhKsd6RFG9RvKBXTprmJTpSZ0iKD2UQ2CnSrxFGpyJNjLFkLzpvShPPw
	jc8vXkzgU3fU3c5AESvjA3ghAM0rlwrVOnP3auURRYOhKQz8nGtv9otwKM89cgYfKrZ5
	zfpg==
Received: by 10.180.75.161 with SMTP id d1mr694434wiw.1.1350917523021;
	Mon, 22 Oct 2012 07:52:03 -0700 (PDT)
Received: from [127.0.1.1] (ip-180-234.sn1.eutelia.it. [62.94.180.234])
	by mx.google.com with ESMTPS id hv8sm14210969wib.0.2012.10.22.07.52.00
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 22 Oct 2012 07:52:02 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 27c4c065efe366a5d7614930252a3c5905d5b24d
Message-Id: <27c4c065efe366a5d761.1350916838@Solace>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.2.2
Date: Mon, 22 Oct 2012 16:40:38 +0200
From: Dario Faggioli 
To: xen-devel@lists.xen.org
Cc: George Dunlap ,
	Paul Durrant ,
	Keir Fraser , Jan Beulich 
Subject: [Xen-devel] [PATCH 5 of 6] xen: sched_sedf: beautify statisics in
	SEDF
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

By gathering all the related fields in a struct (as it is being done
in credit) and using the macros we now have available. No functional
changes involved.

Signed-off-by: Dario Faggioli 

diff --git a/xen/common/sched_sedf.c b/xen/common/sched_sedf.c
--- a/xen/common/sched_sedf.c
+++ b/xen/common/sched_sedf.c
@@ -14,7 +14,6 @@
 #include 
 
 #ifndef NDEBUG
-#define SEDF_STATS
 #define CHECK(_p)                                           \
     do {                                                    \
         if ( !(_p) )                                        \
@@ -45,6 +44,37 @@
 #define IMPLY(a, b) (!(a) || (b))
 #define EQ(a, b) ((!!(a)) == (!!(b)))
 
+/*
+ * SEDF_STATS
+ *
+ * Some statistics about vCPU execution.
+ *
+ * Some of them are displayed with runq dumps
+ * ('r' on the Xen console).
+ */
+#ifdef SCHED_STATS
+
+#define SEDF_STATS
+
+#define SCHED_VCPU_STATS_RESET(_V)                      \
+    do                                                  \
+    {                                                   \
+        memset(&(_V)->stats, 0, sizeof((_V)->stats));   \
+    } while ( 0 )
+
+#define SCHED_VCPU_STAT_CRANK(_V, _X)       (((_V)->stats._X)++)
+
+/*#define SCHED_VCPU_STAT_SET(_V, _X, _Y)     (((_V)->stats._X) = (_Y))*/
+
+#else /* !SCHED_STATS */
+
+#undef SEDF_STATS
+
+#define SCHED_VCPU_STATS_RESET(_V)         do {} while ( 0 )
+#define SCHED_VCPU_STAT_CRANK(_V, _X)      do {} while ( 0 )
+/*#define SCHED_VCPU_STAT_SET(_V, _X, _Y)    do {} while ( 0 )*/
+
+#endif /* SCHED_STATS */
 
 struct sedf_dom_info {
     struct domain  *domain;
@@ -92,14 +122,16 @@ struct sedf_vcpu_info {
     s_time_t  extra_time_tot;
 
 #ifdef SEDF_STATS
-    s_time_t  block_time_tot;
-    s_time_t  penalty_time_tot;
-    int   block_tot;
-    int   short_block_tot;
-    int   long_block_tot;
-    int   short_cont;
-    int   pen_extra_blocks;
-    int   pen_extra_slices;
+    struct {
+        s_time_t block_time_tot;
+        s_time_t penalty_time_tot;
+        int block_tot;
+        int short_block_tot;
+        int long_block_tot;
+        int short_cont;
+        int pen_extra_blocks;
+        int pen_extra_slices;
+    } stats;
 #endif
 };
 
@@ -332,6 +364,7 @@ static void *sedf_alloc_vdata(const stru
     INIT_LIST_HEAD(&(inf->extralist[EXTRA_PEN_Q]));
     INIT_LIST_HEAD(&(inf->extralist[EXTRA_UTIL_Q]));
 
+    SCHED_VCPU_STATS_RESET(inf);
     SCHED_STAT_CRANK(vcpu_init);
 
     return inf;
@@ -688,9 +721,7 @@ static struct task_slice sedf_do_extra_s
         runinf->status |= EXTRA_RUN_PEN;
         ret.task = runinf->vcpu;
         ret.time = EXTRA_QUANTUM;
-#ifdef SEDF_STATS
-        runinf->pen_extra_slices++;
-#endif
+        SCHED_VCPU_STAT_CRANK(runinf, pen_extra_slices);
     }
     else
     {
@@ -989,9 +1020,7 @@ static void unblock_short_extra_support(
         {
             inf->score[0] = (inf->period << 10) /
                 inf->short_block_lost_tot;
-#ifdef SEDF_STATS
-            inf->pen_extra_blocks++;
-#endif
+            SCHED_VCPU_STAT_CRANK(inf, pen_extra_blocks);
             if ( extraq_on(inf->vcpu, EXTRA_PEN_Q) )
                 /* Remove domain for possible resorting! */
                 extraq_del(inf->vcpu, EXTRA_PEN_Q);
@@ -1108,9 +1137,7 @@ static void sedf_wake(const struct sched
         inf->deadl_abs = now + inf->slice;
     }
   
-#ifdef SEDF_STATS 
-    inf->block_tot++;
-#endif
+    SCHED_VCPU_STAT_CRANK(inf, block_tot);
 
     if ( unlikely(now < PERIOD_BEGIN(inf)) )
     {
@@ -1132,9 +1159,7 @@ static void sedf_wake(const struct sched
         if ( now < inf->deadl_abs )
         {
             /* Short blocking */
-#ifdef SEDF_STATS
-            inf->short_block_tot++;
-#endif
+            SCHED_VCPU_STAT_CRANK(inf, short_block_tot);
             unblock_short_extra_support(inf, now);
 
             extraq_check_add_unblocked(d, 1);
@@ -1142,9 +1167,7 @@ static void sedf_wake(const struct sched
         else
         {
             /* Long unblocking */
-#ifdef SEDF_STATS
-            inf->long_block_tot++;
-#endif
+            SCHED_VCPU_STAT_CRANK(inf, long_block_tot);
             unblock_long_cons_b(inf, now);
 
             extraq_check_add_unblocked(d, 1);
@@ -1160,8 +1183,8 @@ static void sedf_wake(const struct sched
     /* Do some statistics here... */
     if ( inf->block_abs != 0 )
     {
-        inf->block_time_tot += now - inf->block_abs;
-        inf->penalty_time_tot +=
+        inf->stats.block_time_tot += now - inf->block_abs;
+        inf->stats.penalty_time_tot +=
             PERIOD_BEGIN(inf) + inf->cputime - inf->block_abs;
     }
 #endif
@@ -1197,22 +1220,22 @@ static void sedf_dump_domain(struct vcpu
            EDOM_INFO(d)->extra_time_tot, EDOM_INFO(d)->extraweight);
     
 #ifdef SEDF_STATS
-    if ( EDOM_INFO(d)->block_time_tot != 0 )
-        printk(" pen=%"PRIu64"%%", (EDOM_INFO(d)->penalty_time_tot * 100) /
-               EDOM_INFO(d)->block_time_tot);
-    if ( EDOM_INFO(d)->block_tot != 0 )
+    if ( EDOM_INFO(d)->stats.block_time_tot != 0 )
+        printk(" pen=%"PRIu64"%%", (EDOM_INFO(d)->stats.penalty_time_tot * 100) /
+               EDOM_INFO(d)->stats.block_time_tot);
+    if ( EDOM_INFO(d)->stats.block_tot != 0 )
         printk("\n   blks=%u sh=%u (%u%%) (shc=%u (%u%%) shex=%i "\
                "shexsl=%i) l=%u (%u%%) avg: b=%"PRIu64" p=%"PRIu64"",
-               EDOM_INFO(d)->block_tot, EDOM_INFO(d)->short_block_tot,
-               (EDOM_INFO(d)->short_block_tot * 100) 
-               / EDOM_INFO(d)->block_tot, EDOM_INFO(d)->short_cont,
-               (EDOM_INFO(d)->short_cont * 100) / EDOM_INFO(d)->block_tot,
-               EDOM_INFO(d)->pen_extra_blocks,
-               EDOM_INFO(d)->pen_extra_slices,
-               EDOM_INFO(d)->long_block_tot,
-               (EDOM_INFO(d)->long_block_tot * 100) / EDOM_INFO(d)->block_tot,
-               (EDOM_INFO(d)->block_time_tot) / EDOM_INFO(d)->block_tot,
-               (EDOM_INFO(d)->penalty_time_tot) / EDOM_INFO(d)->block_tot);
+               EDOM_INFO(d)->stats.block_tot, EDOM_INFO(d)->stats.short_block_tot,
+               (EDOM_INFO(d)->stats.short_block_tot * 100) 
+               / EDOM_INFO(d)->stats.block_tot, EDOM_INFO(d)->stats.short_cont,
+               (EDOM_INFO(d)->stats.short_cont * 100) / EDOM_INFO(d)->stats.block_tot,
+               EDOM_INFO(d)->stats.pen_extra_blocks,
+               EDOM_INFO(d)->stats.pen_extra_slices,
+               EDOM_INFO(d)->stats.long_block_tot,
+               (EDOM_INFO(d)->stats.long_block_tot * 100) / EDOM_INFO(d)->stats.block_tot,
+               (EDOM_INFO(d)->stats.block_time_tot) / EDOM_INFO(d)->stats.block_tot,
+               (EDOM_INFO(d)->stats.penalty_time_tot) / EDOM_INFO(d)->stats.block_tot);
 #endif
     printk("\n");
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 14:52:15 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 14:52:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQJMG-00040k-MK; Mon, 22 Oct 2012 14:52:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQJMF-00040I-Ey
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 14:51:59 +0000
Received: from [85.158.143.35:42696] by server-3.bemta-4.messagelabs.com id
	1A/C4-03544-E8D55805; Mon, 22 Oct 2012 14:51:58 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1350917516!7433496!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14795 invoked from network); 22 Oct 2012 14:51:56 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 14:51:56 -0000
Received: by mail-we0-f173.google.com with SMTP id t11so1878842wey.32
	for ; Mon, 22 Oct 2012 07:51:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=3y/3Yolka/KRFrk8xeIwBZte8XzrStYQXXDU23HUtio=;
	b=s9Uupp/p5tw5QnXdUSg5fdeqzyD04SLFZWa2MVHWKi7eZ410XiDJaMdv3wEV6s+eO0
	DINZu3yoxR2+uX19s3GQNbpSDsOQj9bCfa/H6SH87+LKK0O2o4Z9YIvil+32VRKg6VaS
	HkGOsR5vx1OrZxNFtPkNJxMwX13EUT6TfXpUI2WMqK/M9k3QrL4Djwl0AOhWyBkOb/Fj
	xc8lRxz13v/3SdvuaeBK63PYJ67ZjYoF+1rP8mVJ4QXlW3ImmvWL9zx0tMoe53/rYcZd
	AD3Xf2ksfalzZca99EXgzFgxggSU+DeEI862kZDZ8gYYyAiaLWLq+mpceYg9RILqu9VY
	O0Xw==
Received: by 10.180.99.194 with SMTP id es2mr21809707wib.15.1350917516641;
	Mon, 22 Oct 2012 07:51:56 -0700 (PDT)
Received: from [127.0.1.1] (ip-180-234.sn1.eutelia.it. [62.94.180.234])
	by mx.google.com with ESMTPS id hv8sm14210969wib.0.2012.10.22.07.51.54
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 22 Oct 2012 07:51:55 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: a3fb7fec23ba76a8d5ecd7ff0333ecb953314db5
Message-Id: 
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.2.2
Date: Mon, 22 Oct 2012 16:40:35 +0200
From: Dario Faggioli 
To: xen-devel@lists.xen.org
Cc: George Dunlap ,
	Paul Durrant ,
	Keir Fraser , Jan Beulich 
Subject: [Xen-devel] [PATCH 2 of 6] xen: move `printk("Initializing
 domain")` from credit to generic scheduling code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

As, if it makes sense to let people know about it, it probably always does.

Signed-off-by: Dario Faggioli 

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -1454,8 +1454,6 @@ csched_dom_init(const struct scheduler *
 {
     struct csched_dom *sdom;
 
-    printk("%s: Initializing domain %d\n", __func__, dom->domain_id);
-
     if ( is_idle_domain(dom) )
         return 0;
 
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -312,6 +312,8 @@ void sched_destroy_vcpu(struct vcpu *v)
 
 int sched_init_domain(struct domain *d)
 {
+    printk("%s: Initializing domain %d\n", __func__, d->domain_id);
+
     return SCHED_OP(DOM2OP(d), init_domain, d);
 }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 14:52:15 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 14:52:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQJMG-00040k-MK; Mon, 22 Oct 2012 14:52:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQJMF-00040I-Ey
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 14:51:59 +0000
Received: from [85.158.143.35:42696] by server-3.bemta-4.messagelabs.com id
	1A/C4-03544-E8D55805; Mon, 22 Oct 2012 14:51:58 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1350917516!7433496!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14795 invoked from network); 22 Oct 2012 14:51:56 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 14:51:56 -0000
Received: by mail-we0-f173.google.com with SMTP id t11so1878842wey.32
	for ; Mon, 22 Oct 2012 07:51:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=3y/3Yolka/KRFrk8xeIwBZte8XzrStYQXXDU23HUtio=;
	b=s9Uupp/p5tw5QnXdUSg5fdeqzyD04SLFZWa2MVHWKi7eZ410XiDJaMdv3wEV6s+eO0
	DINZu3yoxR2+uX19s3GQNbpSDsOQj9bCfa/H6SH87+LKK0O2o4Z9YIvil+32VRKg6VaS
	HkGOsR5vx1OrZxNFtPkNJxMwX13EUT6TfXpUI2WMqK/M9k3QrL4Djwl0AOhWyBkOb/Fj
	xc8lRxz13v/3SdvuaeBK63PYJ67ZjYoF+1rP8mVJ4QXlW3ImmvWL9zx0tMoe53/rYcZd
	AD3Xf2ksfalzZca99EXgzFgxggSU+DeEI862kZDZ8gYYyAiaLWLq+mpceYg9RILqu9VY
	O0Xw==
Received: by 10.180.99.194 with SMTP id es2mr21809707wib.15.1350917516641;
	Mon, 22 Oct 2012 07:51:56 -0700 (PDT)
Received: from [127.0.1.1] (ip-180-234.sn1.eutelia.it. [62.94.180.234])
	by mx.google.com with ESMTPS id hv8sm14210969wib.0.2012.10.22.07.51.54
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 22 Oct 2012 07:51:55 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: a3fb7fec23ba76a8d5ecd7ff0333ecb953314db5
Message-Id: 
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.2.2
Date: Mon, 22 Oct 2012 16:40:35 +0200
From: Dario Faggioli 
To: xen-devel@lists.xen.org
Cc: George Dunlap ,
	Paul Durrant ,
	Keir Fraser , Jan Beulich 
Subject: [Xen-devel] [PATCH 2 of 6] xen: move `printk("Initializing
 domain")` from credit to generic scheduling code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

As, if it makes sense to let people know about it, it probably always does.

Signed-off-by: Dario Faggioli 

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -1454,8 +1454,6 @@ csched_dom_init(const struct scheduler *
 {
     struct csched_dom *sdom;
 
-    printk("%s: Initializing domain %d\n", __func__, dom->domain_id);
-
     if ( is_idle_domain(dom) )
         return 0;
 
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -312,6 +312,8 @@ void sched_destroy_vcpu(struct vcpu *v)
 
 int sched_init_domain(struct domain *d)
 {
+    printk("%s: Initializing domain %d\n", __func__, d->domain_id);
+
     return SCHED_OP(DOM2OP(d), init_domain, d);
 }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 14:52:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 14:52:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQJMK-00042H-OE; Mon, 22 Oct 2012 14:52:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQJMJ-00041W-Op
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 14:52:04 +0000
Received: from [193.109.254.147:62574] by server-14.bemta-14.messagelabs.com
	id 9C/9D-20054-39D55805; Mon, 22 Oct 2012 14:52:03 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1350917512!10968564!4
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17144 invoked from network); 22 Oct 2012 14:52:01 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 14:52:01 -0000
Received: by mail-wg0-f51.google.com with SMTP id ed3so1695350wgb.32
	for ; Mon, 22 Oct 2012 07:52:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=qD7utLPYi5cyzhC1huI21NMRvEnqzgI1cBcnNBw1DYQ=;
	b=AqEa7PVAppWfQEK1XxfwJ6JvD5BecMMXUqfHcGQIESaq1qckfoZsIH0BlN9Zktpsf5
	fk3RLQm/VTZ2kCc7WGGEOFS7al2fRaRgOCPqHbOUBctemQ+HuQnP747E7eaNbGPikbtO
	sutN9/MlD6vxzQvsZY7VuZMWvckQez0sIxmh12y89RQK/9b77v6bOYYftpgu4CBsCdsU
	L7DabhaCWiQZJTIOD/LfIKwNR1ZXyuSY9kf1pNd9+1U6fBN1qwZIqp4zK79Q4ww8xz7Z
	lPJQr19Ce+gpCgUht43xtINAuxgtv66K1ir1PaDyGiZXa0fCoU9Dblxvi+WNgG2CQQ4z
	Rnpw==
Received: by 10.180.106.2 with SMTP id gq2mr21809964wib.18.1350917520914;
	Mon, 22 Oct 2012 07:52:00 -0700 (PDT)
Received: from [127.0.1.1] (ip-180-234.sn1.eutelia.it. [62.94.180.234])
	by mx.google.com with ESMTPS id hv8sm14210969wib.0.2012.10.22.07.51.58
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 22 Oct 2012 07:51:59 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: a5f4940f0493ae358e6bfdabdd0cc0f0b8726f9b
Message-Id: 
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.2.2
Date: Mon, 22 Oct 2012 16:40:37 +0200
From: Dario Faggioli 
To: xen-devel@lists.xen.org
Cc: George Dunlap ,
	Paul Durrant ,
	Keir Fraser , Jan Beulich 
Subject: [Xen-devel] [PATCH 4 of 6] xen: sched: introduce a couple of
 counters in credit2 and SEDF
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Mainly for consistency with credit, at least for the events that are
general enough, like vCPU initialization/destruction and calls
to the specific scheduling function.

Signed-off-by: Dario Faggioli 

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -753,6 +753,8 @@ csched_alloc_vdata(const struct schedule
         svc->weight = 0;
     }
 
+    SCHED_STAT_CRANK(vcpu_init);
+
     return svc;
 }
 
@@ -870,6 +872,8 @@ csched_vcpu_remove(const struct schedule
 
     if ( ! is_idle_vcpu(vc) )
     {
+        SCHED_STAT_CRANK(vcpu_destroy);
+
         /* Remove from runqueue */
         vcpu_schedule_lock_irq(vc);
 
@@ -1585,6 +1589,7 @@ csched_schedule(
     struct csched_vcpu *snext = NULL;
     struct task_slice ret;
 
+    SCHED_STAT_CRANK(schedule);
     CSCHED_VCPU_CHECK(current);
 
     d2printk("sc p%d c d%dv%d now %"PRI_stime"\n",
diff --git a/xen/common/sched_sedf.c b/xen/common/sched_sedf.c
--- a/xen/common/sched_sedf.c
+++ b/xen/common/sched_sedf.c
@@ -332,6 +332,8 @@ static void *sedf_alloc_vdata(const stru
     INIT_LIST_HEAD(&(inf->extralist[EXTRA_PEN_Q]));
     INIT_LIST_HEAD(&(inf->extralist[EXTRA_UTIL_Q]));
 
+    SCHED_STAT_CRANK(vcpu_init);
+
     return inf;
 }
 
@@ -763,6 +765,8 @@ static struct task_slice sedf_do_schedul
     struct sedf_vcpu_info *runinf, *waitinf;
     struct task_slice      ret;
 
+    SCHED_STAT_CRANK(schedule);
+
     /* Idle tasks don't need any of the following stuf */
     if ( is_idle_vcpu(current) )
         goto check_waitq;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 14:52:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 14:52:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQJMK-00042H-OE; Mon, 22 Oct 2012 14:52:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQJMJ-00041W-Op
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 14:52:04 +0000
Received: from [193.109.254.147:62574] by server-14.bemta-14.messagelabs.com
	id 9C/9D-20054-39D55805; Mon, 22 Oct 2012 14:52:03 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1350917512!10968564!4
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17144 invoked from network); 22 Oct 2012 14:52:01 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 14:52:01 -0000
Received: by mail-wg0-f51.google.com with SMTP id ed3so1695350wgb.32
	for ; Mon, 22 Oct 2012 07:52:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=qD7utLPYi5cyzhC1huI21NMRvEnqzgI1cBcnNBw1DYQ=;
	b=AqEa7PVAppWfQEK1XxfwJ6JvD5BecMMXUqfHcGQIESaq1qckfoZsIH0BlN9Zktpsf5
	fk3RLQm/VTZ2kCc7WGGEOFS7al2fRaRgOCPqHbOUBctemQ+HuQnP747E7eaNbGPikbtO
	sutN9/MlD6vxzQvsZY7VuZMWvckQez0sIxmh12y89RQK/9b77v6bOYYftpgu4CBsCdsU
	L7DabhaCWiQZJTIOD/LfIKwNR1ZXyuSY9kf1pNd9+1U6fBN1qwZIqp4zK79Q4ww8xz7Z
	lPJQr19Ce+gpCgUht43xtINAuxgtv66K1ir1PaDyGiZXa0fCoU9Dblxvi+WNgG2CQQ4z
	Rnpw==
Received: by 10.180.106.2 with SMTP id gq2mr21809964wib.18.1350917520914;
	Mon, 22 Oct 2012 07:52:00 -0700 (PDT)
Received: from [127.0.1.1] (ip-180-234.sn1.eutelia.it. [62.94.180.234])
	by mx.google.com with ESMTPS id hv8sm14210969wib.0.2012.10.22.07.51.58
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 22 Oct 2012 07:51:59 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: a5f4940f0493ae358e6bfdabdd0cc0f0b8726f9b
Message-Id: 
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.2.2
Date: Mon, 22 Oct 2012 16:40:37 +0200
From: Dario Faggioli 
To: xen-devel@lists.xen.org
Cc: George Dunlap ,
	Paul Durrant ,
	Keir Fraser , Jan Beulich 
Subject: [Xen-devel] [PATCH 4 of 6] xen: sched: introduce a couple of
 counters in credit2 and SEDF
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Mainly for consistency with credit, at least for the events that are
general enough, like vCPU initialization/destruction and calls
to the specific scheduling function.

Signed-off-by: Dario Faggioli 

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -753,6 +753,8 @@ csched_alloc_vdata(const struct schedule
         svc->weight = 0;
     }
 
+    SCHED_STAT_CRANK(vcpu_init);
+
     return svc;
 }
 
@@ -870,6 +872,8 @@ csched_vcpu_remove(const struct schedule
 
     if ( ! is_idle_vcpu(vc) )
     {
+        SCHED_STAT_CRANK(vcpu_destroy);
+
         /* Remove from runqueue */
         vcpu_schedule_lock_irq(vc);
 
@@ -1585,6 +1589,7 @@ csched_schedule(
     struct csched_vcpu *snext = NULL;
     struct task_slice ret;
 
+    SCHED_STAT_CRANK(schedule);
     CSCHED_VCPU_CHECK(current);
 
     d2printk("sc p%d c d%dv%d now %"PRI_stime"\n",
diff --git a/xen/common/sched_sedf.c b/xen/common/sched_sedf.c
--- a/xen/common/sched_sedf.c
+++ b/xen/common/sched_sedf.c
@@ -332,6 +332,8 @@ static void *sedf_alloc_vdata(const stru
     INIT_LIST_HEAD(&(inf->extralist[EXTRA_PEN_Q]));
     INIT_LIST_HEAD(&(inf->extralist[EXTRA_UTIL_Q]));
 
+    SCHED_STAT_CRANK(vcpu_init);
+
     return inf;
 }
 
@@ -763,6 +765,8 @@ static struct task_slice sedf_do_schedul
     struct sedf_vcpu_info *runinf, *waitinf;
     struct task_slice      ret;
 
+    SCHED_STAT_CRANK(schedule);
+
     /* Idle tasks don't need any of the following stuf */
     if ( is_idle_vcpu(current) )
         goto check_waitq;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 14:52:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 14:52:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQJMC-0003zs-Sr; Mon, 22 Oct 2012 14:51:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQJMB-0003zf-6c
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 14:51:55 +0000
Received: from [193.109.254.147:11749] by server-7.bemta-14.messagelabs.com id
	00/02-24122-A8D55805; Mon, 22 Oct 2012 14:51:54 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1350917512!10968564!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16746 invoked from network); 22 Oct 2012 14:51:53 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 14:51:53 -0000
Received: by mail-wg0-f51.google.com with SMTP id ed3so1695350wgb.32
	for ; Mon, 22 Oct 2012 07:51:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to:cc;
	bh=4B9WTT07IefXPS2sVrIKoSEozyBa6wD/ziWA0f9/vQw=;
	b=CXNaV0JACL8+aJ+DB8EXZiLXBO2xiYLYCsDFzH5lJdmP0HyC3IofTQQZUlih5Smx60
	+XtYoWRF/T2alPoc2vrW4FX+NxqPupokQHpOcSRwHcfmD1ElLNmA2CBriCyaHZtqeaop
	AtcRFkEvZ9aHCsIv1KOVQKfuHMxnDfiP338WLItyTWBMypPtw+U48tiTjgA/P387goKk
	Tz2PWwAsm1stOqcRMiEHIPNXOiHmf/eQ9QDIt2eOHsqm/CEFH/cwXT+IjAF41zeLn3Iv
	69r88lXBr7QtyEgVXPsTce5LqBeoNkbO5LvZDfxW0jw0463J6iWdD2cUqJPSXxwx1oy3
	bAzA==
Received: by 10.180.87.74 with SMTP id v10mr21809935wiz.21.1350917512663;
	Mon, 22 Oct 2012 07:51:52 -0700 (PDT)
Received: from [127.0.1.1] (ip-180-234.sn1.eutelia.it. [62.94.180.234])
	by mx.google.com with ESMTPS id hv8sm14210969wib.0.2012.10.22.07.51.50
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 22 Oct 2012 07:51:51 -0700 (PDT)
MIME-Version: 1.0
Message-Id: 
User-Agent: Mercurial-patchbomb/2.2.2
Date: Mon, 22 Oct 2012 16:40:33 +0200
From: Dario Faggioli 
To: xen-devel@lists.xen.org
Cc: George Dunlap ,
	Paul Durrant ,
	Keir Fraser , Jan Beulich 
Subject: [Xen-devel] [PATCH 0 of 6] Xen: generalize and beautify scheduling
 related perfc and stats
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello Everyone,

The main idea behind this series was to cleanup a bit the stats management
within the SEDF code in sched_sedf.c.  While looking into it, I thought the
best idea to achieve that was to generalize a little bit the stat and
perfcounter macros we have in credit, so that they could be used within the
other schedulers too.

That is then what these patches ended up doing.

It's definitely nothing urgent or particularly important now, but will help
if/when we decide to make a broader use of performance counters in the
scheduler code (and I really plan to do that for SEDF at some point! :-D).

Very few functional changes are introduced and no hunk is effective if the
hypervisor is not compiled with 'perfc=y'.

While at it, as I found out build is broken with 'perfc=y', the very first
patch in the series tries to fix that. Paul, as it seems it was you that
introduced those two counters, could you double check? (As it happens in
viridian.c and, for me, it could be like the first time or so I even hear the
word 'Viridian' ;-P.)

Thanks and Regards, Dario

-- 
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 14:52:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 14:52:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQJMC-0003zs-Sr; Mon, 22 Oct 2012 14:51:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQJMB-0003zf-6c
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 14:51:55 +0000
Received: from [193.109.254.147:11749] by server-7.bemta-14.messagelabs.com id
	00/02-24122-A8D55805; Mon, 22 Oct 2012 14:51:54 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1350917512!10968564!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16746 invoked from network); 22 Oct 2012 14:51:53 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 14:51:53 -0000
Received: by mail-wg0-f51.google.com with SMTP id ed3so1695350wgb.32
	for ; Mon, 22 Oct 2012 07:51:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to:cc;
	bh=4B9WTT07IefXPS2sVrIKoSEozyBa6wD/ziWA0f9/vQw=;
	b=CXNaV0JACL8+aJ+DB8EXZiLXBO2xiYLYCsDFzH5lJdmP0HyC3IofTQQZUlih5Smx60
	+XtYoWRF/T2alPoc2vrW4FX+NxqPupokQHpOcSRwHcfmD1ElLNmA2CBriCyaHZtqeaop
	AtcRFkEvZ9aHCsIv1KOVQKfuHMxnDfiP338WLItyTWBMypPtw+U48tiTjgA/P387goKk
	Tz2PWwAsm1stOqcRMiEHIPNXOiHmf/eQ9QDIt2eOHsqm/CEFH/cwXT+IjAF41zeLn3Iv
	69r88lXBr7QtyEgVXPsTce5LqBeoNkbO5LvZDfxW0jw0463J6iWdD2cUqJPSXxwx1oy3
	bAzA==
Received: by 10.180.87.74 with SMTP id v10mr21809935wiz.21.1350917512663;
	Mon, 22 Oct 2012 07:51:52 -0700 (PDT)
Received: from [127.0.1.1] (ip-180-234.sn1.eutelia.it. [62.94.180.234])
	by mx.google.com with ESMTPS id hv8sm14210969wib.0.2012.10.22.07.51.50
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 22 Oct 2012 07:51:51 -0700 (PDT)
MIME-Version: 1.0
Message-Id: 
User-Agent: Mercurial-patchbomb/2.2.2
Date: Mon, 22 Oct 2012 16:40:33 +0200
From: Dario Faggioli 
To: xen-devel@lists.xen.org
Cc: George Dunlap ,
	Paul Durrant ,
	Keir Fraser , Jan Beulich 
Subject: [Xen-devel] [PATCH 0 of 6] Xen: generalize and beautify scheduling
 related perfc and stats
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello Everyone,

The main idea behind this series was to cleanup a bit the stats management
within the SEDF code in sched_sedf.c.  While looking into it, I thought the
best idea to achieve that was to generalize a little bit the stat and
perfcounter macros we have in credit, so that they could be used within the
other schedulers too.

That is then what these patches ended up doing.

It's definitely nothing urgent or particularly important now, but will help
if/when we decide to make a broader use of performance counters in the
scheduler code (and I really plan to do that for SEDF at some point! :-D).

Very few functional changes are introduced and no hunk is effective if the
hypervisor is not compiled with 'perfc=y'.

While at it, as I found out build is broken with 'perfc=y', the very first
patch in the series tries to fix that. Paul, as it seems it was you that
introduced those two counters, could you double check? (As it happens in
viridian.c and, for me, it could be like the first time or so I even hear the
word 'Viridian' ;-P.)

Thanks and Regards, Dario

-- 
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 14:52:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 14:52:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQJMJ-00041P-4t; Mon, 22 Oct 2012 14:52:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQJMH-0003zt-3S
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 14:52:01 +0000
Received: from [193.109.254.147:17981] by server-1.bemta-14.messagelabs.com id
	A0/C6-20415-09D55805; Mon, 22 Oct 2012 14:52:00 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1350917512!10968564!3
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	RCVD_BY_IP,UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17018 invoked from network); 22 Oct 2012 14:51:59 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 14:51:59 -0000
Received: by mail-wg0-f51.google.com with SMTP id ed3so1695350wgb.32
	for ; Mon, 22 Oct 2012 07:51:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=8p01Vj9NvD+Ssraklakur009kMis+V3SEPsgcGYYTOQ=;
	b=x7REfF+LjhuV4dY9N2buJb0XIouhRrKVEU4EeR9l/d1XmizLBg0tzb+kwtbddLcmGI
	vk+ixSdQiAtaMjBwt27vIGDvONmTgjvy+AkknJ2/NPn0p9/GAS/ZSWULay2vS8s2ucWo
	yBYFQVOTJHf4MG3VmWjSPs6WL/72udpoGqO3pceWKsujbq1jvo5JF2+GAgKztJztIraY
	WDUzZbjGH6AKXMCIFjT59ejQFbpQoEFCPC/S5a/793Lfj3CJsvK2/yxVsNX3+2mPsPuQ
	jbZhnXWmP9S6mXfeJQstQxWs4qsgQQcURaQOqd9nMTN4zksAJODRM4W7mhX8eRAH0TnI
	UFsg==
Received: by 10.180.87.34 with SMTP id u2mr37648853wiz.3.1350917518830;
	Mon, 22 Oct 2012 07:51:58 -0700 (PDT)
Received: from [127.0.1.1] (ip-180-234.sn1.eutelia.it. [62.94.180.234])
	by mx.google.com with ESMTPS id hv8sm14210969wib.0.2012.10.22.07.51.56
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 22 Oct 2012 07:51:58 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: a6e4517a5a24f7771cf64748ba4579afe8782f02
Message-Id: 
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.2.2
Date: Mon, 22 Oct 2012 16:40:36 +0200
From: Dario Faggioli 
To: xen-devel@lists.xen.org
Cc: George Dunlap ,
	Paul Durrant ,
	Keir Fraser , Jan Beulich 
Subject: [Xen-devel] [PATCH 3 of 6] xen: sched: generalize scheduling
 related perfcounter macros
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Moving some of them from sched_credit.c to generic scheduler code.
This also allows the other schedulers to use perf counters equally
easy.

This change is mainly preparatory work for what stated above. In fact,
it mostly does s/CSCHED_STAT/SCHED_STAT/, and, in general, it implies no
functional changes.

Signed-off-by: Dario Faggioli 

diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -16,25 +16,12 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 
-/*
- * CSCHED_STATS
- *
- * Manage very basic per-vCPU counters and stats.
- *
- * Useful for debugging live systems. The stats are displayed
- * with runq dumps ('r' on the Xen console).
- */
-#ifdef PERF_COUNTERS
-#define CSCHED_STATS
-#endif
-
 
 /*
  * Basic constants
@@ -75,29 +62,36 @@
 
 
 /*
- * Stats
+ * CSCHED_STATS
+ *
+ * Manage very basic per-vCPU counters and stats.
+ *
+ * Useful for debugging live systems. The stats are displayed
+ * with runq dumps ('r' on the Xen console).
  */
-#define CSCHED_STAT_CRANK(_X)               (perfc_incr(_X))
+#ifdef SCHED_STATS
 
-#ifdef CSCHED_STATS
+#define CSCHED_STATS
 
-#define CSCHED_VCPU_STATS_RESET(_V)                     \
+#define SCHED_VCPU_STATS_RESET(_V)                      \
     do                                                  \
     {                                                   \
         memset(&(_V)->stats, 0, sizeof((_V)->stats));   \
     } while ( 0 )
 
-#define CSCHED_VCPU_STAT_CRANK(_V, _X)      (((_V)->stats._X)++)
+#define SCHED_VCPU_STAT_CRANK(_V, _X)       (((_V)->stats._X)++)
 
-#define CSCHED_VCPU_STAT_SET(_V, _X, _Y)    (((_V)->stats._X) = (_Y))
+#define SCHED_VCPU_STAT_SET(_V, _X, _Y)     (((_V)->stats._X) = (_Y))
 
-#else /* CSCHED_STATS */
+#else /* !SCHED_STATS */
 
-#define CSCHED_VCPU_STATS_RESET(_V)         do {} while ( 0 )
-#define CSCHED_VCPU_STAT_CRANK(_V, _X)      do {} while ( 0 )
-#define CSCHED_VCPU_STAT_SET(_V, _X, _Y)    do {} while ( 0 )
+#undef CSCHED_STATS
 
-#endif /* CSCHED_STATS */
+#define SCHED_VCPU_STATS_RESET(_V)         do {} while ( 0 )
+#define SCHED_VCPU_STAT_CRANK(_V, _X)      do {} while ( 0 )
+#define SCHED_VCPU_STAT_SET(_V, _X, _Y)    do {} while ( 0 )
+
+#endif /* SCHED_STATS */
 
 
 /*
@@ -264,13 +258,13 @@ static inline void
     if ( new->pri > cur->pri )
     {
         if ( cur->pri == CSCHED_PRI_IDLE )
-            CSCHED_STAT_CRANK(tickle_local_idler);
+            SCHED_STAT_CRANK(tickle_local_idler);
         else if ( cur->pri == CSCHED_PRI_TS_OVER )
-            CSCHED_STAT_CRANK(tickle_local_over);
+            SCHED_STAT_CRANK(tickle_local_over);
         else if ( cur->pri == CSCHED_PRI_TS_UNDER )
-            CSCHED_STAT_CRANK(tickle_local_under);
+            SCHED_STAT_CRANK(tickle_local_under);
         else
-            CSCHED_STAT_CRANK(tickle_local_other);
+            SCHED_STAT_CRANK(tickle_local_other);
 
         cpumask_set_cpu(cpu, &mask);
     }
@@ -283,7 +277,7 @@ static inline void
     {
         if ( cpumask_empty(prv->idlers) )
         {
-            CSCHED_STAT_CRANK(tickle_idlers_none);
+            SCHED_STAT_CRANK(tickle_idlers_none);
         }
         else
         {
@@ -292,7 +286,7 @@ static inline void
             cpumask_and(&idle_mask, prv->idlers, new->vcpu->cpu_affinity);
             if ( !cpumask_empty(&idle_mask) )
             {
-                CSCHED_STAT_CRANK(tickle_idlers_some);
+                SCHED_STAT_CRANK(tickle_idlers_some);
                 if ( opt_tickle_one_idle )
                 {
                     this_cpu(last_tickle_cpu) = 
@@ -404,7 +398,7 @@ static inline void
         BUG_ON( !is_idle_vcpu(vc) );
     }
 
-    CSCHED_STAT_CRANK(vcpu_check);
+    SCHED_STAT_CRANK(vcpu_check);
 }
 #define CSCHED_VCPU_CHECK(_vc)  (__csched_vcpu_check(_vc))
 #else
@@ -437,7 +431,7 @@ static inline int
                ((uint64_t)vcpu_migration_delay * 1000u));
 
     if ( hot )
-        CSCHED_STAT_CRANK(vcpu_hot);
+        SCHED_STAT_CRANK(vcpu_hot);
 
     return hot;
 }
@@ -559,8 +553,8 @@ static inline void
 
     if ( list_empty(&svc->active_vcpu_elem) )
     {
-        CSCHED_VCPU_STAT_CRANK(svc, state_active);
-        CSCHED_STAT_CRANK(acct_vcpu_active);
+        SCHED_VCPU_STAT_CRANK(svc, state_active);
+        SCHED_STAT_CRANK(acct_vcpu_active);
 
         sdom->active_vcpu_count++;
         list_add(&svc->active_vcpu_elem, &sdom->active_vcpu);
@@ -583,8 +577,8 @@ static inline void
 
     BUG_ON( list_empty(&svc->active_vcpu_elem) );
 
-    CSCHED_VCPU_STAT_CRANK(svc, state_idle);
-    CSCHED_STAT_CRANK(acct_vcpu_idle);
+    SCHED_VCPU_STAT_CRANK(svc, state_idle);
+    SCHED_STAT_CRANK(acct_vcpu_idle);
 
     BUG_ON( prv->weight < sdom->weight );
     sdom->active_vcpu_count--;
@@ -633,8 +627,8 @@ csched_vcpu_acct(struct csched_private *
     }
     else if ( _csched_cpu_pick(ops, current, 0) != cpu )
     {
-        CSCHED_VCPU_STAT_CRANK(svc, migrate_r);
-        CSCHED_STAT_CRANK(migrate_running);
+        SCHED_VCPU_STAT_CRANK(svc, migrate_r);
+        SCHED_STAT_CRANK(migrate_running);
         set_bit(_VPF_migrating, ¤t->pause_flags);
         cpu_raise_softirq(cpu, SCHEDULE_SOFTIRQ);
     }
@@ -658,8 +652,8 @@ csched_alloc_vdata(const struct schedule
     svc->flags = 0U;
     svc->pri = is_idle_domain(vc->domain) ?
         CSCHED_PRI_IDLE : CSCHED_PRI_TS_UNDER;
-    CSCHED_VCPU_STATS_RESET(svc);
-    CSCHED_STAT_CRANK(vcpu_init);
+    SCHED_VCPU_STATS_RESET(svc);
+    SCHED_STAT_CRANK(vcpu_init);
     return svc;
 }
 
@@ -690,7 +684,7 @@ csched_vcpu_remove(const struct schedule
     struct csched_dom * const sdom = svc->sdom;
     unsigned long flags;
 
-    CSCHED_STAT_CRANK(vcpu_destroy);
+    SCHED_STAT_CRANK(vcpu_destroy);
 
     if ( __vcpu_on_runq(svc) )
         __runq_remove(svc);
@@ -711,7 +705,7 @@ csched_vcpu_sleep(const struct scheduler
 {
     struct csched_vcpu * const svc = CSCHED_VCPU(vc);
 
-    CSCHED_STAT_CRANK(vcpu_sleep);
+    SCHED_STAT_CRANK(vcpu_sleep);
 
     BUG_ON( is_idle_vcpu(vc) );
 
@@ -731,19 +725,19 @@ csched_vcpu_wake(const struct scheduler 
 
     if ( unlikely(per_cpu(schedule_data, cpu).curr == vc) )
     {
-        CSCHED_STAT_CRANK(vcpu_wake_running);
+        SCHED_STAT_CRANK(vcpu_wake_running);
         return;
     }
     if ( unlikely(__vcpu_on_runq(svc)) )
     {
-        CSCHED_STAT_CRANK(vcpu_wake_onrunq);
+        SCHED_STAT_CRANK(vcpu_wake_onrunq);
         return;
     }
 
     if ( likely(vcpu_runnable(vc)) )
-        CSCHED_STAT_CRANK(vcpu_wake_runnable);
+        SCHED_STAT_CRANK(vcpu_wake_runnable);
     else
-        CSCHED_STAT_CRANK(vcpu_wake_not_runnable);
+        SCHED_STAT_CRANK(vcpu_wake_not_runnable);
 
     /*
      * We temporarly boost the priority of awaking VCPUs!
@@ -883,8 +877,6 @@ csched_dom_init(const struct scheduler *
 {
     struct csched_dom *sdom;
 
-    CSCHED_STAT_CRANK(dom_init);
-
     if ( is_idle_domain(dom) )
         return 0;
 
@@ -906,7 +898,6 @@ csched_free_domdata(const struct schedul
 static void
 csched_dom_destroy(const struct scheduler *ops, struct domain *dom)
 {
-    CSCHED_STAT_CRANK(dom_destroy);
     csched_free_domdata(ops, CSCHED_DOM(dom));
 }
 
@@ -989,18 +980,18 @@ csched_acct(void* dummy)
     if ( prv->credit_balance < 0 )
     {
         credit_total -= prv->credit_balance;
-        CSCHED_STAT_CRANK(acct_balance);
+        SCHED_STAT_CRANK(acct_balance);
     }
 
     if ( unlikely(weight_total == 0) )
     {
         prv->credit_balance = 0;
         spin_unlock_irqrestore(&prv->lock, flags);
-        CSCHED_STAT_CRANK(acct_no_work);
+        SCHED_STAT_CRANK(acct_no_work);
         goto out;
     }
 
-    CSCHED_STAT_CRANK(acct_run);
+    SCHED_STAT_CRANK(acct_run);
 
     weight_left = weight_total;
     credit_balance = 0;
@@ -1075,7 +1066,7 @@ csched_acct(void* dummy)
                  * the queue to give others a chance at them in future
                  * accounting periods.
                  */
-                CSCHED_STAT_CRANK(acct_reorder);
+                SCHED_STAT_CRANK(acct_reorder);
                 list_del(&sdom->active_sdom_elem);
                 list_add(&sdom->active_sdom_elem, &prv->active_sdom);
             }
@@ -1110,7 +1101,7 @@ csched_acct(void* dummy)
                      credit < -credit_cap &&
                      !(svc->flags & CSCHED_FLAG_VCPU_PARKED) )
                 {
-                    CSCHED_STAT_CRANK(vcpu_park);
+                    SCHED_STAT_CRANK(vcpu_park);
                     vcpu_pause_nosync(svc->vcpu);
                     svc->flags |= CSCHED_FLAG_VCPU_PARKED;
                 }
@@ -1118,7 +1109,7 @@ csched_acct(void* dummy)
                 /* Lower bound on credits */
                 if ( credit < -prv->credits_per_tslice )
                 {
-                    CSCHED_STAT_CRANK(acct_min_credit);
+                    SCHED_STAT_CRANK(acct_min_credit);
                     credit = -prv->credits_per_tslice;
                     atomic_set(&svc->credit, credit);
                 }
@@ -1135,7 +1126,7 @@ csched_acct(void* dummy)
                      * call to make sure the VCPU's priority is not boosted
                      * if it is woken up here.
                      */
-                    CSCHED_STAT_CRANK(vcpu_unpark);
+                    SCHED_STAT_CRANK(vcpu_unpark);
                     vcpu_unpause(svc->vcpu);
                     svc->flags &= ~CSCHED_FLAG_VCPU_PARKED;
                 }
@@ -1151,8 +1142,8 @@ csched_acct(void* dummy)
                 }
             }
 
-            CSCHED_VCPU_STAT_SET(svc, credit_last, credit);
-            CSCHED_VCPU_STAT_SET(svc, credit_incr, credit_fair);
+            SCHED_VCPU_STAT_SET(svc, credit_last, credit);
+            SCHED_VCPU_STAT_SET(svc, credit_incr, credit_fair);
             credit_balance += credit;
         }
     }
@@ -1229,8 +1220,8 @@ csched_runq_steal(int peer_cpu, int cpu,
             if (__csched_vcpu_is_migrateable(vc, cpu))
             {
                 /* We got a candidate. Grab it! */
-                CSCHED_VCPU_STAT_CRANK(speer, migrate_q);
-                CSCHED_STAT_CRANK(migrate_queued);
+                SCHED_VCPU_STAT_CRANK(speer, migrate_q);
+                SCHED_STAT_CRANK(migrate_queued);
                 WARN_ON(vc->is_urgent);
                 __runq_remove(speer);
                 vc->processor = cpu;
@@ -1239,7 +1230,7 @@ csched_runq_steal(int peer_cpu, int cpu,
         }
     }
 
-    CSCHED_STAT_CRANK(steal_peer_idle);
+    SCHED_STAT_CRANK(steal_peer_idle);
     return NULL;
 }
 
@@ -1260,11 +1251,11 @@ csched_load_balance(struct csched_privat
         goto out;
 
     if ( snext->pri == CSCHED_PRI_IDLE )
-        CSCHED_STAT_CRANK(load_balance_idle);
+        SCHED_STAT_CRANK(load_balance_idle);
     else if ( snext->pri == CSCHED_PRI_TS_OVER )
-        CSCHED_STAT_CRANK(load_balance_over);
+        SCHED_STAT_CRANK(load_balance_over);
     else
-        CSCHED_STAT_CRANK(load_balance_other);
+        SCHED_STAT_CRANK(load_balance_other);
 
     /*
      * Peek at non-idling CPUs in the system, starting with our
@@ -1288,7 +1279,7 @@ csched_load_balance(struct csched_privat
          */
         if ( !pcpu_schedule_trylock(peer_cpu) )
         {
-            CSCHED_STAT_CRANK(steal_trylock_failed);
+            SCHED_STAT_CRANK(steal_trylock_failed);
             continue;
         }
 
@@ -1327,7 +1318,7 @@ csched_schedule(
     struct task_slice ret;
     s_time_t runtime, tslice;
 
-    CSCHED_STAT_CRANK(schedule);
+    SCHED_STAT_CRANK(schedule);
     CSCHED_VCPU_CHECK(current);
 
     runtime = now - current->runstate.state_entry_time;
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -314,11 +314,14 @@ int sched_init_domain(struct domain *d)
 {
     printk("%s: Initializing domain %d\n", __func__, d->domain_id);
 
+    SCHED_STAT_CRANK(dom_init);
+
     return SCHED_OP(DOM2OP(d), init_domain, d);
 }
 
 void sched_destroy_domain(struct domain *d)
 {
+    SCHED_STAT_CRANK(dom_destroy);
     SCHED_OP(DOM2OP(d), destroy_domain, d);
 }
 
@@ -1086,7 +1089,7 @@ static void schedule(void)
 
     ASSERT(!in_atomic());
 
-    perfc_incr(sched_run);
+    SCHED_STAT_CRANK(sched_run);
 
     sd = &this_cpu(schedule_data);
 
@@ -1164,7 +1167,7 @@ static void schedule(void)
 
     pcpu_schedule_unlock_irq(cpu);
 
-    perfc_incr(sched_ctx);
+    SCHED_STAT_CRANK(sched_ctx);
 
     stop_timer(&prev->periodic_timer);
 
@@ -1198,7 +1201,7 @@ void context_saved(struct vcpu *prev)
 static void s_timer_fn(void *unused)
 {
     raise_softirq(SCHEDULE_SOFTIRQ);
-    perfc_incr(sched_irq);
+    SCHED_STAT_CRANK(sched_irq);
 }
 
 /* Per-VCPU periodic timer function: sends a virtual timer interrupt. */
diff --git a/xen/include/xen/perfc_defn.h b/xen/include/xen/perfc_defn.h
--- a/xen/include/xen/perfc_defn.h
+++ b/xen/include/xen/perfc_defn.h
@@ -12,13 +12,19 @@ PERFCOUNTER(calls_from_multicall,       
 PERFCOUNTER(irqs,                   "#interrupts")
 PERFCOUNTER(ipis,                   "#IPIs")
 
+/* Generic scheduler counters (applicable to all schedulers) */
 PERFCOUNTER(sched_irq,              "sched: timer")
 PERFCOUNTER(sched_run,              "sched: runs through scheduler")
 PERFCOUNTER(sched_ctx,              "sched: context switches")
+PERFCOUNTER(schedule,               "sched: specific scheduler")
+PERFCOUNTER(dom_init,               "sched: dom_init")
+PERFCOUNTER(dom_destroy,            "sched: dom_destroy")
+PERFCOUNTER(vcpu_init,              "sched: vcpu_init")
+PERFCOUNTER(vcpu_destroy,           "sched: vcpu_destroy")
 
+/* credit specific counters */
 PERFCOUNTER(delay_ms,               "csched: delay")
 PERFCOUNTER(vcpu_check,             "csched: vcpu_check")
-PERFCOUNTER(schedule,               "csched: schedule")
 PERFCOUNTER(acct_run,               "csched: acct_run")
 PERFCOUNTER(acct_no_work,           "csched: acct_no_work")
 PERFCOUNTER(acct_balance,           "csched: acct_balance")
@@ -46,10 +52,6 @@ PERFCOUNTER(steal_trylock_failed,   "csc
 PERFCOUNTER(steal_peer_idle,        "csched: steal_peer_idle")
 PERFCOUNTER(migrate_queued,         "csched: migrate_queued")
 PERFCOUNTER(migrate_running,        "csched: migrate_running")
-PERFCOUNTER(dom_init,               "csched: dom_init")
-PERFCOUNTER(dom_destroy,            "csched: dom_destroy")
-PERFCOUNTER(vcpu_init,              "csched: vcpu_init")
-PERFCOUNTER(vcpu_destroy,           "csched: vcpu_destroy")
 PERFCOUNTER(vcpu_hot,               "csched: vcpu_hot")
 
 PERFCOUNTER(need_flush_tlb_flush,   "PG_need_flush tlb flushes")
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -29,6 +30,18 @@
 DEFINE_XEN_GUEST_HANDLE(vcpu_runstate_info_compat_t);
 #endif
 
+/*
+ * Stats
+ *
+ * Enable and ease the use of scheduling related performance counters.
+ *
+ */
+#ifdef PERF_COUNTERS
+#define SCHED_STATS
+#endif
+
+#define SCHED_STAT_CRANK(_X)                (perfc_incr(_X))
+
 /* A global pointer to the initial domain (DOM0). */
 extern struct domain *dom0;
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 14:52:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 14:52:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQJMJ-00041P-4t; Mon, 22 Oct 2012 14:52:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQJMH-0003zt-3S
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 14:52:01 +0000
Received: from [193.109.254.147:17981] by server-1.bemta-14.messagelabs.com id
	A0/C6-20415-09D55805; Mon, 22 Oct 2012 14:52:00 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1350917512!10968564!3
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	RCVD_BY_IP,UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17018 invoked from network); 22 Oct 2012 14:51:59 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 14:51:59 -0000
Received: by mail-wg0-f51.google.com with SMTP id ed3so1695350wgb.32
	for ; Mon, 22 Oct 2012 07:51:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=8p01Vj9NvD+Ssraklakur009kMis+V3SEPsgcGYYTOQ=;
	b=x7REfF+LjhuV4dY9N2buJb0XIouhRrKVEU4EeR9l/d1XmizLBg0tzb+kwtbddLcmGI
	vk+ixSdQiAtaMjBwt27vIGDvONmTgjvy+AkknJ2/NPn0p9/GAS/ZSWULay2vS8s2ucWo
	yBYFQVOTJHf4MG3VmWjSPs6WL/72udpoGqO3pceWKsujbq1jvo5JF2+GAgKztJztIraY
	WDUzZbjGH6AKXMCIFjT59ejQFbpQoEFCPC/S5a/793Lfj3CJsvK2/yxVsNX3+2mPsPuQ
	jbZhnXWmP9S6mXfeJQstQxWs4qsgQQcURaQOqd9nMTN4zksAJODRM4W7mhX8eRAH0TnI
	UFsg==
Received: by 10.180.87.34 with SMTP id u2mr37648853wiz.3.1350917518830;
	Mon, 22 Oct 2012 07:51:58 -0700 (PDT)
Received: from [127.0.1.1] (ip-180-234.sn1.eutelia.it. [62.94.180.234])
	by mx.google.com with ESMTPS id hv8sm14210969wib.0.2012.10.22.07.51.56
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 22 Oct 2012 07:51:58 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: a6e4517a5a24f7771cf64748ba4579afe8782f02
Message-Id: 
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.2.2
Date: Mon, 22 Oct 2012 16:40:36 +0200
From: Dario Faggioli 
To: xen-devel@lists.xen.org
Cc: George Dunlap ,
	Paul Durrant ,
	Keir Fraser , Jan Beulich 
Subject: [Xen-devel] [PATCH 3 of 6] xen: sched: generalize scheduling
 related perfcounter macros
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Moving some of them from sched_credit.c to generic scheduler code.
This also allows the other schedulers to use perf counters equally
easy.

This change is mainly preparatory work for what stated above. In fact,
it mostly does s/CSCHED_STAT/SCHED_STAT/, and, in general, it implies no
functional changes.

Signed-off-by: Dario Faggioli 

diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -16,25 +16,12 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 
-/*
- * CSCHED_STATS
- *
- * Manage very basic per-vCPU counters and stats.
- *
- * Useful for debugging live systems. The stats are displayed
- * with runq dumps ('r' on the Xen console).
- */
-#ifdef PERF_COUNTERS
-#define CSCHED_STATS
-#endif
-
 
 /*
  * Basic constants
@@ -75,29 +62,36 @@
 
 
 /*
- * Stats
+ * CSCHED_STATS
+ *
+ * Manage very basic per-vCPU counters and stats.
+ *
+ * Useful for debugging live systems. The stats are displayed
+ * with runq dumps ('r' on the Xen console).
  */
-#define CSCHED_STAT_CRANK(_X)               (perfc_incr(_X))
+#ifdef SCHED_STATS
 
-#ifdef CSCHED_STATS
+#define CSCHED_STATS
 
-#define CSCHED_VCPU_STATS_RESET(_V)                     \
+#define SCHED_VCPU_STATS_RESET(_V)                      \
     do                                                  \
     {                                                   \
         memset(&(_V)->stats, 0, sizeof((_V)->stats));   \
     } while ( 0 )
 
-#define CSCHED_VCPU_STAT_CRANK(_V, _X)      (((_V)->stats._X)++)
+#define SCHED_VCPU_STAT_CRANK(_V, _X)       (((_V)->stats._X)++)
 
-#define CSCHED_VCPU_STAT_SET(_V, _X, _Y)    (((_V)->stats._X) = (_Y))
+#define SCHED_VCPU_STAT_SET(_V, _X, _Y)     (((_V)->stats._X) = (_Y))
 
-#else /* CSCHED_STATS */
+#else /* !SCHED_STATS */
 
-#define CSCHED_VCPU_STATS_RESET(_V)         do {} while ( 0 )
-#define CSCHED_VCPU_STAT_CRANK(_V, _X)      do {} while ( 0 )
-#define CSCHED_VCPU_STAT_SET(_V, _X, _Y)    do {} while ( 0 )
+#undef CSCHED_STATS
 
-#endif /* CSCHED_STATS */
+#define SCHED_VCPU_STATS_RESET(_V)         do {} while ( 0 )
+#define SCHED_VCPU_STAT_CRANK(_V, _X)      do {} while ( 0 )
+#define SCHED_VCPU_STAT_SET(_V, _X, _Y)    do {} while ( 0 )
+
+#endif /* SCHED_STATS */
 
 
 /*
@@ -264,13 +258,13 @@ static inline void
     if ( new->pri > cur->pri )
     {
         if ( cur->pri == CSCHED_PRI_IDLE )
-            CSCHED_STAT_CRANK(tickle_local_idler);
+            SCHED_STAT_CRANK(tickle_local_idler);
         else if ( cur->pri == CSCHED_PRI_TS_OVER )
-            CSCHED_STAT_CRANK(tickle_local_over);
+            SCHED_STAT_CRANK(tickle_local_over);
         else if ( cur->pri == CSCHED_PRI_TS_UNDER )
-            CSCHED_STAT_CRANK(tickle_local_under);
+            SCHED_STAT_CRANK(tickle_local_under);
         else
-            CSCHED_STAT_CRANK(tickle_local_other);
+            SCHED_STAT_CRANK(tickle_local_other);
 
         cpumask_set_cpu(cpu, &mask);
     }
@@ -283,7 +277,7 @@ static inline void
     {
         if ( cpumask_empty(prv->idlers) )
         {
-            CSCHED_STAT_CRANK(tickle_idlers_none);
+            SCHED_STAT_CRANK(tickle_idlers_none);
         }
         else
         {
@@ -292,7 +286,7 @@ static inline void
             cpumask_and(&idle_mask, prv->idlers, new->vcpu->cpu_affinity);
             if ( !cpumask_empty(&idle_mask) )
             {
-                CSCHED_STAT_CRANK(tickle_idlers_some);
+                SCHED_STAT_CRANK(tickle_idlers_some);
                 if ( opt_tickle_one_idle )
                 {
                     this_cpu(last_tickle_cpu) = 
@@ -404,7 +398,7 @@ static inline void
         BUG_ON( !is_idle_vcpu(vc) );
     }
 
-    CSCHED_STAT_CRANK(vcpu_check);
+    SCHED_STAT_CRANK(vcpu_check);
 }
 #define CSCHED_VCPU_CHECK(_vc)  (__csched_vcpu_check(_vc))
 #else
@@ -437,7 +431,7 @@ static inline int
                ((uint64_t)vcpu_migration_delay * 1000u));
 
     if ( hot )
-        CSCHED_STAT_CRANK(vcpu_hot);
+        SCHED_STAT_CRANK(vcpu_hot);
 
     return hot;
 }
@@ -559,8 +553,8 @@ static inline void
 
     if ( list_empty(&svc->active_vcpu_elem) )
     {
-        CSCHED_VCPU_STAT_CRANK(svc, state_active);
-        CSCHED_STAT_CRANK(acct_vcpu_active);
+        SCHED_VCPU_STAT_CRANK(svc, state_active);
+        SCHED_STAT_CRANK(acct_vcpu_active);
 
         sdom->active_vcpu_count++;
         list_add(&svc->active_vcpu_elem, &sdom->active_vcpu);
@@ -583,8 +577,8 @@ static inline void
 
     BUG_ON( list_empty(&svc->active_vcpu_elem) );
 
-    CSCHED_VCPU_STAT_CRANK(svc, state_idle);
-    CSCHED_STAT_CRANK(acct_vcpu_idle);
+    SCHED_VCPU_STAT_CRANK(svc, state_idle);
+    SCHED_STAT_CRANK(acct_vcpu_idle);
 
     BUG_ON( prv->weight < sdom->weight );
     sdom->active_vcpu_count--;
@@ -633,8 +627,8 @@ csched_vcpu_acct(struct csched_private *
     }
     else if ( _csched_cpu_pick(ops, current, 0) != cpu )
     {
-        CSCHED_VCPU_STAT_CRANK(svc, migrate_r);
-        CSCHED_STAT_CRANK(migrate_running);
+        SCHED_VCPU_STAT_CRANK(svc, migrate_r);
+        SCHED_STAT_CRANK(migrate_running);
         set_bit(_VPF_migrating, ¤t->pause_flags);
         cpu_raise_softirq(cpu, SCHEDULE_SOFTIRQ);
     }
@@ -658,8 +652,8 @@ csched_alloc_vdata(const struct schedule
     svc->flags = 0U;
     svc->pri = is_idle_domain(vc->domain) ?
         CSCHED_PRI_IDLE : CSCHED_PRI_TS_UNDER;
-    CSCHED_VCPU_STATS_RESET(svc);
-    CSCHED_STAT_CRANK(vcpu_init);
+    SCHED_VCPU_STATS_RESET(svc);
+    SCHED_STAT_CRANK(vcpu_init);
     return svc;
 }
 
@@ -690,7 +684,7 @@ csched_vcpu_remove(const struct schedule
     struct csched_dom * const sdom = svc->sdom;
     unsigned long flags;
 
-    CSCHED_STAT_CRANK(vcpu_destroy);
+    SCHED_STAT_CRANK(vcpu_destroy);
 
     if ( __vcpu_on_runq(svc) )
         __runq_remove(svc);
@@ -711,7 +705,7 @@ csched_vcpu_sleep(const struct scheduler
 {
     struct csched_vcpu * const svc = CSCHED_VCPU(vc);
 
-    CSCHED_STAT_CRANK(vcpu_sleep);
+    SCHED_STAT_CRANK(vcpu_sleep);
 
     BUG_ON( is_idle_vcpu(vc) );
 
@@ -731,19 +725,19 @@ csched_vcpu_wake(const struct scheduler 
 
     if ( unlikely(per_cpu(schedule_data, cpu).curr == vc) )
     {
-        CSCHED_STAT_CRANK(vcpu_wake_running);
+        SCHED_STAT_CRANK(vcpu_wake_running);
         return;
     }
     if ( unlikely(__vcpu_on_runq(svc)) )
     {
-        CSCHED_STAT_CRANK(vcpu_wake_onrunq);
+        SCHED_STAT_CRANK(vcpu_wake_onrunq);
         return;
     }
 
     if ( likely(vcpu_runnable(vc)) )
-        CSCHED_STAT_CRANK(vcpu_wake_runnable);
+        SCHED_STAT_CRANK(vcpu_wake_runnable);
     else
-        CSCHED_STAT_CRANK(vcpu_wake_not_runnable);
+        SCHED_STAT_CRANK(vcpu_wake_not_runnable);
 
     /*
      * We temporarly boost the priority of awaking VCPUs!
@@ -883,8 +877,6 @@ csched_dom_init(const struct scheduler *
 {
     struct csched_dom *sdom;
 
-    CSCHED_STAT_CRANK(dom_init);
-
     if ( is_idle_domain(dom) )
         return 0;
 
@@ -906,7 +898,6 @@ csched_free_domdata(const struct schedul
 static void
 csched_dom_destroy(const struct scheduler *ops, struct domain *dom)
 {
-    CSCHED_STAT_CRANK(dom_destroy);
     csched_free_domdata(ops, CSCHED_DOM(dom));
 }
 
@@ -989,18 +980,18 @@ csched_acct(void* dummy)
     if ( prv->credit_balance < 0 )
     {
         credit_total -= prv->credit_balance;
-        CSCHED_STAT_CRANK(acct_balance);
+        SCHED_STAT_CRANK(acct_balance);
     }
 
     if ( unlikely(weight_total == 0) )
     {
         prv->credit_balance = 0;
         spin_unlock_irqrestore(&prv->lock, flags);
-        CSCHED_STAT_CRANK(acct_no_work);
+        SCHED_STAT_CRANK(acct_no_work);
         goto out;
     }
 
-    CSCHED_STAT_CRANK(acct_run);
+    SCHED_STAT_CRANK(acct_run);
 
     weight_left = weight_total;
     credit_balance = 0;
@@ -1075,7 +1066,7 @@ csched_acct(void* dummy)
                  * the queue to give others a chance at them in future
                  * accounting periods.
                  */
-                CSCHED_STAT_CRANK(acct_reorder);
+                SCHED_STAT_CRANK(acct_reorder);
                 list_del(&sdom->active_sdom_elem);
                 list_add(&sdom->active_sdom_elem, &prv->active_sdom);
             }
@@ -1110,7 +1101,7 @@ csched_acct(void* dummy)
                      credit < -credit_cap &&
                      !(svc->flags & CSCHED_FLAG_VCPU_PARKED) )
                 {
-                    CSCHED_STAT_CRANK(vcpu_park);
+                    SCHED_STAT_CRANK(vcpu_park);
                     vcpu_pause_nosync(svc->vcpu);
                     svc->flags |= CSCHED_FLAG_VCPU_PARKED;
                 }
@@ -1118,7 +1109,7 @@ csched_acct(void* dummy)
                 /* Lower bound on credits */
                 if ( credit < -prv->credits_per_tslice )
                 {
-                    CSCHED_STAT_CRANK(acct_min_credit);
+                    SCHED_STAT_CRANK(acct_min_credit);
                     credit = -prv->credits_per_tslice;
                     atomic_set(&svc->credit, credit);
                 }
@@ -1135,7 +1126,7 @@ csched_acct(void* dummy)
                      * call to make sure the VCPU's priority is not boosted
                      * if it is woken up here.
                      */
-                    CSCHED_STAT_CRANK(vcpu_unpark);
+                    SCHED_STAT_CRANK(vcpu_unpark);
                     vcpu_unpause(svc->vcpu);
                     svc->flags &= ~CSCHED_FLAG_VCPU_PARKED;
                 }
@@ -1151,8 +1142,8 @@ csched_acct(void* dummy)
                 }
             }
 
-            CSCHED_VCPU_STAT_SET(svc, credit_last, credit);
-            CSCHED_VCPU_STAT_SET(svc, credit_incr, credit_fair);
+            SCHED_VCPU_STAT_SET(svc, credit_last, credit);
+            SCHED_VCPU_STAT_SET(svc, credit_incr, credit_fair);
             credit_balance += credit;
         }
     }
@@ -1229,8 +1220,8 @@ csched_runq_steal(int peer_cpu, int cpu,
             if (__csched_vcpu_is_migrateable(vc, cpu))
             {
                 /* We got a candidate. Grab it! */
-                CSCHED_VCPU_STAT_CRANK(speer, migrate_q);
-                CSCHED_STAT_CRANK(migrate_queued);
+                SCHED_VCPU_STAT_CRANK(speer, migrate_q);
+                SCHED_STAT_CRANK(migrate_queued);
                 WARN_ON(vc->is_urgent);
                 __runq_remove(speer);
                 vc->processor = cpu;
@@ -1239,7 +1230,7 @@ csched_runq_steal(int peer_cpu, int cpu,
         }
     }
 
-    CSCHED_STAT_CRANK(steal_peer_idle);
+    SCHED_STAT_CRANK(steal_peer_idle);
     return NULL;
 }
 
@@ -1260,11 +1251,11 @@ csched_load_balance(struct csched_privat
         goto out;
 
     if ( snext->pri == CSCHED_PRI_IDLE )
-        CSCHED_STAT_CRANK(load_balance_idle);
+        SCHED_STAT_CRANK(load_balance_idle);
     else if ( snext->pri == CSCHED_PRI_TS_OVER )
-        CSCHED_STAT_CRANK(load_balance_over);
+        SCHED_STAT_CRANK(load_balance_over);
     else
-        CSCHED_STAT_CRANK(load_balance_other);
+        SCHED_STAT_CRANK(load_balance_other);
 
     /*
      * Peek at non-idling CPUs in the system, starting with our
@@ -1288,7 +1279,7 @@ csched_load_balance(struct csched_privat
          */
         if ( !pcpu_schedule_trylock(peer_cpu) )
         {
-            CSCHED_STAT_CRANK(steal_trylock_failed);
+            SCHED_STAT_CRANK(steal_trylock_failed);
             continue;
         }
 
@@ -1327,7 +1318,7 @@ csched_schedule(
     struct task_slice ret;
     s_time_t runtime, tslice;
 
-    CSCHED_STAT_CRANK(schedule);
+    SCHED_STAT_CRANK(schedule);
     CSCHED_VCPU_CHECK(current);
 
     runtime = now - current->runstate.state_entry_time;
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -314,11 +314,14 @@ int sched_init_domain(struct domain *d)
 {
     printk("%s: Initializing domain %d\n", __func__, d->domain_id);
 
+    SCHED_STAT_CRANK(dom_init);
+
     return SCHED_OP(DOM2OP(d), init_domain, d);
 }
 
 void sched_destroy_domain(struct domain *d)
 {
+    SCHED_STAT_CRANK(dom_destroy);
     SCHED_OP(DOM2OP(d), destroy_domain, d);
 }
 
@@ -1086,7 +1089,7 @@ static void schedule(void)
 
     ASSERT(!in_atomic());
 
-    perfc_incr(sched_run);
+    SCHED_STAT_CRANK(sched_run);
 
     sd = &this_cpu(schedule_data);
 
@@ -1164,7 +1167,7 @@ static void schedule(void)
 
     pcpu_schedule_unlock_irq(cpu);
 
-    perfc_incr(sched_ctx);
+    SCHED_STAT_CRANK(sched_ctx);
 
     stop_timer(&prev->periodic_timer);
 
@@ -1198,7 +1201,7 @@ void context_saved(struct vcpu *prev)
 static void s_timer_fn(void *unused)
 {
     raise_softirq(SCHEDULE_SOFTIRQ);
-    perfc_incr(sched_irq);
+    SCHED_STAT_CRANK(sched_irq);
 }
 
 /* Per-VCPU periodic timer function: sends a virtual timer interrupt. */
diff --git a/xen/include/xen/perfc_defn.h b/xen/include/xen/perfc_defn.h
--- a/xen/include/xen/perfc_defn.h
+++ b/xen/include/xen/perfc_defn.h
@@ -12,13 +12,19 @@ PERFCOUNTER(calls_from_multicall,       
 PERFCOUNTER(irqs,                   "#interrupts")
 PERFCOUNTER(ipis,                   "#IPIs")
 
+/* Generic scheduler counters (applicable to all schedulers) */
 PERFCOUNTER(sched_irq,              "sched: timer")
 PERFCOUNTER(sched_run,              "sched: runs through scheduler")
 PERFCOUNTER(sched_ctx,              "sched: context switches")
+PERFCOUNTER(schedule,               "sched: specific scheduler")
+PERFCOUNTER(dom_init,               "sched: dom_init")
+PERFCOUNTER(dom_destroy,            "sched: dom_destroy")
+PERFCOUNTER(vcpu_init,              "sched: vcpu_init")
+PERFCOUNTER(vcpu_destroy,           "sched: vcpu_destroy")
 
+/* credit specific counters */
 PERFCOUNTER(delay_ms,               "csched: delay")
 PERFCOUNTER(vcpu_check,             "csched: vcpu_check")
-PERFCOUNTER(schedule,               "csched: schedule")
 PERFCOUNTER(acct_run,               "csched: acct_run")
 PERFCOUNTER(acct_no_work,           "csched: acct_no_work")
 PERFCOUNTER(acct_balance,           "csched: acct_balance")
@@ -46,10 +52,6 @@ PERFCOUNTER(steal_trylock_failed,   "csc
 PERFCOUNTER(steal_peer_idle,        "csched: steal_peer_idle")
 PERFCOUNTER(migrate_queued,         "csched: migrate_queued")
 PERFCOUNTER(migrate_running,        "csched: migrate_running")
-PERFCOUNTER(dom_init,               "csched: dom_init")
-PERFCOUNTER(dom_destroy,            "csched: dom_destroy")
-PERFCOUNTER(vcpu_init,              "csched: vcpu_init")
-PERFCOUNTER(vcpu_destroy,           "csched: vcpu_destroy")
 PERFCOUNTER(vcpu_hot,               "csched: vcpu_hot")
 
 PERFCOUNTER(need_flush_tlb_flush,   "PG_need_flush tlb flushes")
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -29,6 +30,18 @@
 DEFINE_XEN_GUEST_HANDLE(vcpu_runstate_info_compat_t);
 #endif
 
+/*
+ * Stats
+ *
+ * Enable and ease the use of scheduling related performance counters.
+ *
+ */
+#ifdef PERF_COUNTERS
+#define SCHED_STATS
+#endif
+
+#define SCHED_STAT_CRANK(_X)                (perfc_incr(_X))
+
 /* A global pointer to the initial domain (DOM0). */
 extern struct domain *dom0;
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 14:52:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 14:52:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQJMO-00044L-JK; Mon, 22 Oct 2012 14:52:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQJMN-00043H-9j
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 14:52:07 +0000
Received: from [85.158.143.35:43080] by server-1.bemta-4.messagelabs.com id
	16/47-19134-69D55805; Mon, 22 Oct 2012 14:52:06 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1350917516!7433496!3
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15325 invoked from network); 22 Oct 2012 14:52:05 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 14:52:05 -0000
Received: by mail-we0-f173.google.com with SMTP id t11so1878842wey.32
	for ; Mon, 22 Oct 2012 07:52:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=UWJHcE4wKAPmS7+7ESqLq86cZzbpUADX6HeMNeDc+l8=;
	b=tONshyBJRnCiekzluXXUC1UUCK1ZXlip6/n2Sc2KEFOySAkwfmQI7witfJ7W3DBgyr
	O1cLBhKaiIT6umCodKBUEY0uQ/qZZUPizQamppUq+1U/9HzNUwXBhdISREka1TFHZu+I
	/N2m3BtjVHR+twNJBjYPGO/mrm8vr+N5oF+B+7KgWQ9R8qABLY7sFvdmoWRa6+aT7ZcR
	Zcfef+on1VaH8eoUZfh3i6sFYbh5yq9xUM9Tv9YSM2OIvmoxRAoakbe0/wlRLPxQuNos
	ywx/aLcRrawiM7EYSbY0uJE7ky/ILgQZ6EEnzz+Dn1bz2fqejGn8lDgD3QB1jFwXMRbT
	wBvg==
Received: by 10.216.212.225 with SMTP id y75mr5592520weo.39.1350917524861;
	Mon, 22 Oct 2012 07:52:04 -0700 (PDT)
Received: from [127.0.1.1] (ip-180-234.sn1.eutelia.it. [62.94.180.234])
	by mx.google.com with ESMTPS id hv8sm14210969wib.0.2012.10.22.07.52.03
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 22 Oct 2012 07:52:04 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: fcff31a9c036768e648827a99318c1f7485c9099
Message-Id: 
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.2.2
Date: Mon, 22 Oct 2012 16:40:39 +0200
From: Dario Faggioli 
To: xen-devel@lists.xen.org
Cc: George Dunlap ,
	Paul Durrant ,
	Keir Fraser , Jan Beulich 
Subject: [Xen-devel] [PATCH 6 of 6] xen: sched_sedf: remove an unused stat
	in SEDF
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Namely, `short_cont' which is not updated anywhere in the code.

Signed-off-by: Dario Faggioli 

diff --git a/xen/common/sched_sedf.c b/xen/common/sched_sedf.c
--- a/xen/common/sched_sedf.c
+++ b/xen/common/sched_sedf.c
@@ -128,7 +128,6 @@ struct sedf_vcpu_info {
         int block_tot;
         int short_block_tot;
         int long_block_tot;
-        int short_cont;
         int pen_extra_blocks;
         int pen_extra_slices;
     } stats;
@@ -1224,12 +1223,11 @@ static void sedf_dump_domain(struct vcpu
         printk(" pen=%"PRIu64"%%", (EDOM_INFO(d)->stats.penalty_time_tot * 100) /
                EDOM_INFO(d)->stats.block_time_tot);
     if ( EDOM_INFO(d)->stats.block_tot != 0 )
-        printk("\n   blks=%u sh=%u (%u%%) (shc=%u (%u%%) shex=%i "\
-               "shexsl=%i) l=%u (%u%%) avg: b=%"PRIu64" p=%"PRIu64"",
+        printk("\n   blks=%u sh=%u (%u%%) shex=%i (shexsl=%i) "\
+               "l=%u (%u%%) avg: b=%"PRIu64" p=%"PRIu64"",
                EDOM_INFO(d)->stats.block_tot, EDOM_INFO(d)->stats.short_block_tot,
                (EDOM_INFO(d)->stats.short_block_tot * 100) 
-               / EDOM_INFO(d)->stats.block_tot, EDOM_INFO(d)->stats.short_cont,
-               (EDOM_INFO(d)->stats.short_cont * 100) / EDOM_INFO(d)->stats.block_tot,
+               / EDOM_INFO(d)->stats.block_tot,
                EDOM_INFO(d)->stats.pen_extra_blocks,
                EDOM_INFO(d)->stats.pen_extra_slices,
                EDOM_INFO(d)->stats.long_block_tot,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 14:52:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 14:52:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQJMO-00044L-JK; Mon, 22 Oct 2012 14:52:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQJMN-00043H-9j
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 14:52:07 +0000
Received: from [85.158.143.35:43080] by server-1.bemta-4.messagelabs.com id
	16/47-19134-69D55805; Mon, 22 Oct 2012 14:52:06 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1350917516!7433496!3
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15325 invoked from network); 22 Oct 2012 14:52:05 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 14:52:05 -0000
Received: by mail-we0-f173.google.com with SMTP id t11so1878842wey.32
	for ; Mon, 22 Oct 2012 07:52:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=UWJHcE4wKAPmS7+7ESqLq86cZzbpUADX6HeMNeDc+l8=;
	b=tONshyBJRnCiekzluXXUC1UUCK1ZXlip6/n2Sc2KEFOySAkwfmQI7witfJ7W3DBgyr
	O1cLBhKaiIT6umCodKBUEY0uQ/qZZUPizQamppUq+1U/9HzNUwXBhdISREka1TFHZu+I
	/N2m3BtjVHR+twNJBjYPGO/mrm8vr+N5oF+B+7KgWQ9R8qABLY7sFvdmoWRa6+aT7ZcR
	Zcfef+on1VaH8eoUZfh3i6sFYbh5yq9xUM9Tv9YSM2OIvmoxRAoakbe0/wlRLPxQuNos
	ywx/aLcRrawiM7EYSbY0uJE7ky/ILgQZ6EEnzz+Dn1bz2fqejGn8lDgD3QB1jFwXMRbT
	wBvg==
Received: by 10.216.212.225 with SMTP id y75mr5592520weo.39.1350917524861;
	Mon, 22 Oct 2012 07:52:04 -0700 (PDT)
Received: from [127.0.1.1] (ip-180-234.sn1.eutelia.it. [62.94.180.234])
	by mx.google.com with ESMTPS id hv8sm14210969wib.0.2012.10.22.07.52.03
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 22 Oct 2012 07:52:04 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: fcff31a9c036768e648827a99318c1f7485c9099
Message-Id: 
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.2.2
Date: Mon, 22 Oct 2012 16:40:39 +0200
From: Dario Faggioli 
To: xen-devel@lists.xen.org
Cc: George Dunlap ,
	Paul Durrant ,
	Keir Fraser , Jan Beulich 
Subject: [Xen-devel] [PATCH 6 of 6] xen: sched_sedf: remove an unused stat
	in SEDF
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Namely, `short_cont' which is not updated anywhere in the code.

Signed-off-by: Dario Faggioli 

diff --git a/xen/common/sched_sedf.c b/xen/common/sched_sedf.c
--- a/xen/common/sched_sedf.c
+++ b/xen/common/sched_sedf.c
@@ -128,7 +128,6 @@ struct sedf_vcpu_info {
         int block_tot;
         int short_block_tot;
         int long_block_tot;
-        int short_cont;
         int pen_extra_blocks;
         int pen_extra_slices;
     } stats;
@@ -1224,12 +1223,11 @@ static void sedf_dump_domain(struct vcpu
         printk(" pen=%"PRIu64"%%", (EDOM_INFO(d)->stats.penalty_time_tot * 100) /
                EDOM_INFO(d)->stats.block_time_tot);
     if ( EDOM_INFO(d)->stats.block_tot != 0 )
-        printk("\n   blks=%u sh=%u (%u%%) (shc=%u (%u%%) shex=%i "\
-               "shexsl=%i) l=%u (%u%%) avg: b=%"PRIu64" p=%"PRIu64"",
+        printk("\n   blks=%u sh=%u (%u%%) shex=%i (shexsl=%i) "\
+               "l=%u (%u%%) avg: b=%"PRIu64" p=%"PRIu64"",
                EDOM_INFO(d)->stats.block_tot, EDOM_INFO(d)->stats.short_block_tot,
                (EDOM_INFO(d)->stats.short_block_tot * 100) 
-               / EDOM_INFO(d)->stats.block_tot, EDOM_INFO(d)->stats.short_cont,
-               (EDOM_INFO(d)->stats.short_cont * 100) / EDOM_INFO(d)->stats.block_tot,
+               / EDOM_INFO(d)->stats.block_tot,
                EDOM_INFO(d)->stats.pen_extra_blocks,
                EDOM_INFO(d)->stats.pen_extra_slices,
                EDOM_INFO(d)->stats.long_block_tot,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 14:59:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 14:59:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQJTQ-00053l-JV; Mon, 22 Oct 2012 14:59:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQJTP-00053d-Dd
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 14:59:23 +0000
Received: from [85.158.138.51:23616] by server-7.bemta-3.messagelabs.com id
	7F/5C-06991-A4F55805; Mon, 22 Oct 2012 14:59:22 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-174.messagelabs.com!1350917961!35232464!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDUwNzI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDUwNzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3431 invoked from network); 22 Oct 2012 14:59:22 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Oct 2012 14:59:22 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq0M7qF/64
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-079-154.pools.arcor-ip.net [84.57.79.154])
	by smtp.strato.de (jored mo50) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id z06e62o9MEsWwT ;
	Mon, 22 Oct 2012 16:59:21 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 439F818642; Mon, 22 Oct 2012 16:59:21 +0200 (CEST)
Date: Mon, 22 Oct 2012 16:59:21 +0200
From: Olaf Hering 
To: Andres Lagar-Cavilla 
Message-ID: <20121022145921.GB22644@aepfle.de>
References: 
	<918914F5-6729-40C8-8D46-5EABB8FAB35B@gridcentric.ca>
	<20121022144840.GA22644@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20121022144840.GA22644@aepfle.de>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] hvm: handle PoD and grant pages in
 HVMOP_get_mem_type
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 22, Olaf Hering wrote:

> On Fri, Oct 19, Andres Lagar-Cavilla wrote:
> > > +            else if ( p2m_is_grant(t) )
> > > +                a.mem_type =  HVMMEM_ram_rw;
> > 
> > Yes there can be p2m_is_grant pages in an HVM, if it is running a
> > backend. Note that you need to discriminate whether the grant is
> > mapped writable in order to return ram_rw or ram_ro.
> 
> I will put p2m_grant_map_rw into HVMMEM_ram_rw, and p2m_grant_map_ro
> into HVMMEM_ram_ro.

Reading through the p2m_is_* defines, p2m_grant_map_ro maps already to
HVMMEM_ram_ro. So the patch covers all cases already.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 14:59:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 14:59:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQJTQ-00053l-JV; Mon, 22 Oct 2012 14:59:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQJTP-00053d-Dd
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 14:59:23 +0000
Received: from [85.158.138.51:23616] by server-7.bemta-3.messagelabs.com id
	7F/5C-06991-A4F55805; Mon, 22 Oct 2012 14:59:22 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-174.messagelabs.com!1350917961!35232464!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDUwNzI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDUwNzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3431 invoked from network); 22 Oct 2012 14:59:22 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Oct 2012 14:59:22 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq0M7qF/64
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-079-154.pools.arcor-ip.net [84.57.79.154])
	by smtp.strato.de (jored mo50) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id z06e62o9MEsWwT ;
	Mon, 22 Oct 2012 16:59:21 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 439F818642; Mon, 22 Oct 2012 16:59:21 +0200 (CEST)
Date: Mon, 22 Oct 2012 16:59:21 +0200
From: Olaf Hering 
To: Andres Lagar-Cavilla 
Message-ID: <20121022145921.GB22644@aepfle.de>
References: 
	<918914F5-6729-40C8-8D46-5EABB8FAB35B@gridcentric.ca>
	<20121022144840.GA22644@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20121022144840.GA22644@aepfle.de>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] hvm: handle PoD and grant pages in
 HVMOP_get_mem_type
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 22, Olaf Hering wrote:

> On Fri, Oct 19, Andres Lagar-Cavilla wrote:
> > > +            else if ( p2m_is_grant(t) )
> > > +                a.mem_type =  HVMMEM_ram_rw;
> > 
> > Yes there can be p2m_is_grant pages in an HVM, if it is running a
> > backend. Note that you need to discriminate whether the grant is
> > mapped writable in order to return ram_rw or ram_ro.
> 
> I will put p2m_grant_map_rw into HVMMEM_ram_rw, and p2m_grant_map_ro
> into HVMMEM_ram_ro.

Reading through the p2m_is_* defines, p2m_grant_map_ro maps already to
HVMMEM_ram_ro. So the patch covers all cases already.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 15:09:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 15:09:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQJcW-0005GV-N7; Mon, 22 Oct 2012 15:08:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQJcV-0005GQ-9C
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 15:08:47 +0000
Received: from [85.158.137.99:35233] by server-6.bemta-3.messagelabs.com id
	B5/95-32375-E7165805; Mon, 22 Oct 2012 15:08:46 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-217.messagelabs.com!1350918525!19437646!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDUwNzI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDUwNzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25075 invoked from network); 22 Oct 2012 15:08:45 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-12.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Oct 2012 15:08:45 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq0M7qF/64
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-079-154.pools.arcor-ip.net [84.57.79.154])
	by smtp.strato.de (jorabe mo46) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id D05fbdo9ME79Ol
	for ; Mon, 22 Oct 2012 17:08:45 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id ECDB5183A7
	for ; Mon, 22 Oct 2012 17:08:44 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: de800ac188d5b43f0e8f3cd3b3719ba568fe79c7
Message-Id: 
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 22 Oct 2012 17:08:44 +0200
From: Olaf Hering 
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] p2m: rename p2m_is_magic to p2m_is_pod
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering 
# Date 1350918469 -7200
# Node ID de800ac188d5b43f0e8f3cd3b3719ba568fe79c7
# Parent  2d450b41b7e2cf74940776ab74d41c11206ca46c
p2m: rename p2m_is_magic to p2m_is_pod

Signed-off-by: Olaf Hering 

diff -r 2d450b41b7e2 -r de800ac188d5 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4086,7 +4086,7 @@ long do_hvm_op(unsigned long op, XEN_GUE
                 a.mem_type =  HVMMEM_ram_ro;
             else if ( p2m_is_ram(t) )
                 a.mem_type =  HVMMEM_ram_rw;
-            else if ( p2m_is_magic(t) )
+            else if ( p2m_is_pod(t) )
                 a.mem_type =  HVMMEM_ram_rw;
             else if ( p2m_is_grant(t) )
                 a.mem_type =  HVMMEM_ram_rw;
diff -r 2d450b41b7e2 -r de800ac188d5 xen/arch/x86/mm/p2m-pt.c
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -405,7 +405,7 @@ p2m_set_entry(struct p2m_domain *p2m, un
         }
         
         ASSERT(!mfn_valid(mfn) || p2mt != p2m_mmio_direct);
-        if ( mfn_valid(mfn) || p2m_is_magic(p2mt) )
+        if ( mfn_valid(mfn) || p2m_is_pod(p2mt) )
             l2e_content = l2e_from_pfn(mfn_x(mfn),
                                        p2m_type_to_flags(p2mt, mfn) |
                                        _PAGE_PSE);
diff -r 2d450b41b7e2 -r de800ac188d5 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -238,7 +238,7 @@ struct page_info *get_page_from_gfn_p2m(
             return page;
 
         /* Error path: not a suitable GFN at all */
-        if ( !p2m_is_ram(*t) && !p2m_is_paging(*t) && !p2m_is_magic(*t) )
+        if ( !p2m_is_ram(*t) && !p2m_is_paging(*t) && !p2m_is_pod(*t) )
             return NULL;
     }
 
diff -r 2d450b41b7e2 -r de800ac188d5 xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -139,7 +139,7 @@ typedef unsigned int p2m_query_t;
                       | p2m_to_mask(p2m_grant_map_ro)   \
                       | p2m_to_mask(p2m_ram_shared) )
 
-#define P2M_MAGIC_TYPES (p2m_to_mask(p2m_populate_on_demand))
+#define P2M_POD_TYPES (p2m_to_mask(p2m_populate_on_demand))
 
 /* Pageable types */
 #define P2M_PAGEABLE_TYPES (p2m_to_mask(p2m_ram_rw) \
@@ -167,7 +167,7 @@ typedef unsigned int p2m_query_t;
 #define p2m_is_hole(_t) (p2m_to_mask(_t) & P2M_HOLE_TYPES)
 #define p2m_is_mmio(_t) (p2m_to_mask(_t) & P2M_MMIO_TYPES)
 #define p2m_is_readonly(_t) (p2m_to_mask(_t) & P2M_RO_TYPES)
-#define p2m_is_magic(_t) (p2m_to_mask(_t) & P2M_MAGIC_TYPES)
+#define p2m_is_pod(_t) (p2m_to_mask(_t) & P2M_POD_TYPES)
 #define p2m_is_grant(_t) (p2m_to_mask(_t) & P2M_GRANT_TYPES)
 /* Grant types are *not* considered valid, because they can be
    unmapped at any time and, unless you happen to be the shadow or p2m

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 15:09:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 15:09:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQJcW-0005GV-N7; Mon, 22 Oct 2012 15:08:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQJcV-0005GQ-9C
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 15:08:47 +0000
Received: from [85.158.137.99:35233] by server-6.bemta-3.messagelabs.com id
	B5/95-32375-E7165805; Mon, 22 Oct 2012 15:08:46 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-217.messagelabs.com!1350918525!19437646!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDUwNzI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDUwNzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25075 invoked from network); 22 Oct 2012 15:08:45 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-12.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Oct 2012 15:08:45 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq0M7qF/64
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-079-154.pools.arcor-ip.net [84.57.79.154])
	by smtp.strato.de (jorabe mo46) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id D05fbdo9ME79Ol
	for ; Mon, 22 Oct 2012 17:08:45 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id ECDB5183A7
	for ; Mon, 22 Oct 2012 17:08:44 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: de800ac188d5b43f0e8f3cd3b3719ba568fe79c7
Message-Id: 
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 22 Oct 2012 17:08:44 +0200
From: Olaf Hering 
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] p2m: rename p2m_is_magic to p2m_is_pod
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering 
# Date 1350918469 -7200
# Node ID de800ac188d5b43f0e8f3cd3b3719ba568fe79c7
# Parent  2d450b41b7e2cf74940776ab74d41c11206ca46c
p2m: rename p2m_is_magic to p2m_is_pod

Signed-off-by: Olaf Hering 

diff -r 2d450b41b7e2 -r de800ac188d5 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4086,7 +4086,7 @@ long do_hvm_op(unsigned long op, XEN_GUE
                 a.mem_type =  HVMMEM_ram_ro;
             else if ( p2m_is_ram(t) )
                 a.mem_type =  HVMMEM_ram_rw;
-            else if ( p2m_is_magic(t) )
+            else if ( p2m_is_pod(t) )
                 a.mem_type =  HVMMEM_ram_rw;
             else if ( p2m_is_grant(t) )
                 a.mem_type =  HVMMEM_ram_rw;
diff -r 2d450b41b7e2 -r de800ac188d5 xen/arch/x86/mm/p2m-pt.c
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -405,7 +405,7 @@ p2m_set_entry(struct p2m_domain *p2m, un
         }
         
         ASSERT(!mfn_valid(mfn) || p2mt != p2m_mmio_direct);
-        if ( mfn_valid(mfn) || p2m_is_magic(p2mt) )
+        if ( mfn_valid(mfn) || p2m_is_pod(p2mt) )
             l2e_content = l2e_from_pfn(mfn_x(mfn),
                                        p2m_type_to_flags(p2mt, mfn) |
                                        _PAGE_PSE);
diff -r 2d450b41b7e2 -r de800ac188d5 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -238,7 +238,7 @@ struct page_info *get_page_from_gfn_p2m(
             return page;
 
         /* Error path: not a suitable GFN at all */
-        if ( !p2m_is_ram(*t) && !p2m_is_paging(*t) && !p2m_is_magic(*t) )
+        if ( !p2m_is_ram(*t) && !p2m_is_paging(*t) && !p2m_is_pod(*t) )
             return NULL;
     }
 
diff -r 2d450b41b7e2 -r de800ac188d5 xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -139,7 +139,7 @@ typedef unsigned int p2m_query_t;
                       | p2m_to_mask(p2m_grant_map_ro)   \
                       | p2m_to_mask(p2m_ram_shared) )
 
-#define P2M_MAGIC_TYPES (p2m_to_mask(p2m_populate_on_demand))
+#define P2M_POD_TYPES (p2m_to_mask(p2m_populate_on_demand))
 
 /* Pageable types */
 #define P2M_PAGEABLE_TYPES (p2m_to_mask(p2m_ram_rw) \
@@ -167,7 +167,7 @@ typedef unsigned int p2m_query_t;
 #define p2m_is_hole(_t) (p2m_to_mask(_t) & P2M_HOLE_TYPES)
 #define p2m_is_mmio(_t) (p2m_to_mask(_t) & P2M_MMIO_TYPES)
 #define p2m_is_readonly(_t) (p2m_to_mask(_t) & P2M_RO_TYPES)
-#define p2m_is_magic(_t) (p2m_to_mask(_t) & P2M_MAGIC_TYPES)
+#define p2m_is_pod(_t) (p2m_to_mask(_t) & P2M_POD_TYPES)
 #define p2m_is_grant(_t) (p2m_to_mask(_t) & P2M_GRANT_TYPES)
 /* Grant types are *not* considered valid, because they can be
    unmapped at any time and, unless you happen to be the shadow or p2m

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 15:11:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 15:11:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQJf1-0005Mk-K2; Mon, 22 Oct 2012 15:11:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQFQi-00067v-VK; Mon, 22 Oct 2012 10:40:21 +0000
Received: from [85.158.139.211:26937] by server-14.bemta-5.messagelabs.com id
	51/DD-24068-49225805; Mon, 22 Oct 2012 10:40:20 +0000
X-Env-Sender: mrsanna1@gmail.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1350902417!23239508!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3457 invoked from network); 22 Oct 2012 10:40:18 -0000
Received: from mail-vc0-f171.google.com (HELO mail-vc0-f171.google.com)
	(209.85.220.171)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 10:40:18 -0000
Received: by mail-vc0-f171.google.com with SMTP id m18so3387993vcm.30
	for ; Mon, 22 Oct 2012 03:40:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=llDPsUwAQDfn08jwWXng+p14TvdqFXsEBn0GBLBEst8=;
	b=04KZiamAhP3theygJ1AWzwDMV9yZK696mpsXQdVF/TAYFaH6kdOsIck2VCKx6yTfsx
	aQCbAzelGh6ufvTUSG0dZO6JDCLgm6o4HKBx1yZjRCJcJTa/6HgAY4yh0LgtOKiptPwY
	IbMM3XgaztyCnaDx5FcxA1huDmLeCnxB+2/C81WRDIoQbMcUSt/F1yiywbxNHCXB5LaX
	nFlynUiMb+B1uh+WdAlrZdK9jH1tvePK4mfc8lSFQjDcPZiln++63FMQlWJ+X7369Q8u
	f2DlCV9iO3ZzRnvsl5YK4/f+ihRwDunrpMEOXXysmzKnC/GjzjrFY6GymKtbCCIM0jjB
	L6Eg==
MIME-Version: 1.0
Received: by 10.52.65.51 with SMTP id u19mr11227826vds.3.1350902416610; Mon,
	22 Oct 2012 03:40:16 -0700 (PDT)
Received: by 10.58.207.75 with HTTP; Mon, 22 Oct 2012 03:40:16 -0700 (PDT)
In-Reply-To: <50852D8C02000078000A2E48@nat28.tlf.novell.com>
References: 
	
	
	
	<65395f62-74e5-4910-b701-8df629c2ce3b@default>
	
	
	
	
	
	<20120930151314.GU8912@reaktio.net>
	
	
	
	<507C024602000078000A155C@nat28.tlf.novell.com>
	
	<507C226A02000078000A1657@nat28.tlf.novell.com>
	
	<508509D902000078000A2DDA@nat28.tlf.novell.com>
	
	<50852D8C02000078000A2E48@nat28.tlf.novell.com>
Date: Mon, 22 Oct 2012 12:40:16 +0200
Message-ID: 
From: Mauro 
To: Jan Beulich 
X-Mailman-Approved-At: Mon, 22 Oct 2012 15:11:21 +0000
Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com,
	Keir Fraser , Dan Magenheimer ,
	Olivier Hanesse ,
	Keir Fraser ,
	Xen Users ,
	Mark Adams 
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 22 October 2012 11:27, Jan Beulich  wrote:
>>>> On 22.10.12 at 11:17, Mauro  wrote:
>> On 22 October 2012 08:54, Jan Beulich  wrote:
>>>>>> On 21.10.12 at 22:52, Mauro  wrote:
>>>> On 15 October 2012 14:49, Jan Beulich  wrote:
>>> So what's the contents of /proc/cpuinfo (any one CPU suffices)
>>> under a native recent kernel on that system? The most likely
>>> issue here is that we're mis-identifying the CPU as having an
>>> always running APIC timer (ARAT)...
>>
>> uname -a
>>
>> Linux xen-p01 2.6.32-5-xen-amd64 #1 SMP Sun Sep 23 13:49:30 UTC 2012
>> x86_64 GNU/Linux
>
> I had specifically asked to do this under a _native_ kernel.

sorry for my ignorance, what does it mean native_kernel.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 15:11:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 15:11:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQJf1-0005Mk-K2; Mon, 22 Oct 2012 15:11:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQFQi-00067v-VK; Mon, 22 Oct 2012 10:40:21 +0000
Received: from [85.158.139.211:26937] by server-14.bemta-5.messagelabs.com id
	51/DD-24068-49225805; Mon, 22 Oct 2012 10:40:20 +0000
X-Env-Sender: mrsanna1@gmail.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1350902417!23239508!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3457 invoked from network); 22 Oct 2012 10:40:18 -0000
Received: from mail-vc0-f171.google.com (HELO mail-vc0-f171.google.com)
	(209.85.220.171)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 10:40:18 -0000
Received: by mail-vc0-f171.google.com with SMTP id m18so3387993vcm.30
	for ; Mon, 22 Oct 2012 03:40:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=llDPsUwAQDfn08jwWXng+p14TvdqFXsEBn0GBLBEst8=;
	b=04KZiamAhP3theygJ1AWzwDMV9yZK696mpsXQdVF/TAYFaH6kdOsIck2VCKx6yTfsx
	aQCbAzelGh6ufvTUSG0dZO6JDCLgm6o4HKBx1yZjRCJcJTa/6HgAY4yh0LgtOKiptPwY
	IbMM3XgaztyCnaDx5FcxA1huDmLeCnxB+2/C81WRDIoQbMcUSt/F1yiywbxNHCXB5LaX
	nFlynUiMb+B1uh+WdAlrZdK9jH1tvePK4mfc8lSFQjDcPZiln++63FMQlWJ+X7369Q8u
	f2DlCV9iO3ZzRnvsl5YK4/f+ihRwDunrpMEOXXysmzKnC/GjzjrFY6GymKtbCCIM0jjB
	L6Eg==
MIME-Version: 1.0
Received: by 10.52.65.51 with SMTP id u19mr11227826vds.3.1350902416610; Mon,
	22 Oct 2012 03:40:16 -0700 (PDT)
Received: by 10.58.207.75 with HTTP; Mon, 22 Oct 2012 03:40:16 -0700 (PDT)
In-Reply-To: <50852D8C02000078000A2E48@nat28.tlf.novell.com>
References: 
	
	
	
	<65395f62-74e5-4910-b701-8df629c2ce3b@default>
	
	
	
	
	
	<20120930151314.GU8912@reaktio.net>
	
	
	
	<507C024602000078000A155C@nat28.tlf.novell.com>
	
	<507C226A02000078000A1657@nat28.tlf.novell.com>
	
	<508509D902000078000A2DDA@nat28.tlf.novell.com>
	
	<50852D8C02000078000A2E48@nat28.tlf.novell.com>
Date: Mon, 22 Oct 2012 12:40:16 +0200
Message-ID: 
From: Mauro 
To: Jan Beulich 
X-Mailman-Approved-At: Mon, 22 Oct 2012 15:11:21 +0000
Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com,
	Keir Fraser , Dan Magenheimer ,
	Olivier Hanesse ,
	Keir Fraser ,
	Xen Users ,
	Mark Adams 
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 22 October 2012 11:27, Jan Beulich  wrote:
>>>> On 22.10.12 at 11:17, Mauro  wrote:
>> On 22 October 2012 08:54, Jan Beulich  wrote:
>>>>>> On 21.10.12 at 22:52, Mauro  wrote:
>>>> On 15 October 2012 14:49, Jan Beulich  wrote:
>>> So what's the contents of /proc/cpuinfo (any one CPU suffices)
>>> under a native recent kernel on that system? The most likely
>>> issue here is that we're mis-identifying the CPU as having an
>>> always running APIC timer (ARAT)...
>>
>> uname -a
>>
>> Linux xen-p01 2.6.32-5-xen-amd64 #1 SMP Sun Sep 23 13:49:30 UTC 2012
>> x86_64 GNU/Linux
>
> I had specifically asked to do this under a _native_ kernel.

sorry for my ignorance, what does it mean native_kernel.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 15:11:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 15:11:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQJf1-0005Mc-90; Mon, 22 Oct 2012 15:11:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQE8s-0004BJ-1y; Mon, 22 Oct 2012 09:17:50 +0000
Received: from [85.158.139.83:10228] by server-15.bemta-5.messagelabs.com id
	03/BC-28599-D3F05805; Mon, 22 Oct 2012 09:17:49 +0000
X-Env-Sender: mrsanna1@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1350897467!35882572!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20329 invoked from network); 22 Oct 2012 09:17:48 -0000
Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com)
	(209.85.212.43)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 09:17:48 -0000
Received: by mail-vb0-f43.google.com with SMTP id fq11so3265453vbb.30
	for ; Mon, 22 Oct 2012 02:17:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=tY34Tx+WyFe79OQFecDxwuhMFlIwuj91Jx9fnBtzyF8=;
	b=Iy8ftAlZGS4gSqGRg+/jk7sVnhw3zAC53UH7iHeCC0t8lD5D/DBp7GEYtP2PzFuf9L
	swD5mIxQEFExC4w0HWMfUxr3QQ76VDZaQClLcHI2hsFawCjPUgPY9IQsma6awVG0nISP
	B02/Z+cEq80i+/2xihUzl0SQpW0t2/Q5+4/Xqjy359rhGtoVv5aM/M3Qy04GpTnfeC7M
	9w3tWhXa30x13Clgt63hynPFPY3O7NEIl7UuS9DA0kw8h+FnL3/gEHyCUfjMMwJK/4b6
	STwhExo3uOMYX/qcvM/FTRgwtoBCZzMEBW14Cg+TCLaOuyt9CEx40KKLDgkfpnY4M6W+
	pdUQ==
MIME-Version: 1.0
Received: by 10.58.173.41 with SMTP id bh9mr5000252vec.40.1350897467030; Mon,
	22 Oct 2012 02:17:47 -0700 (PDT)
Received: by 10.58.207.75 with HTTP; Mon, 22 Oct 2012 02:17:46 -0700 (PDT)
In-Reply-To: <508509D902000078000A2DDA@nat28.tlf.novell.com>
References: 
	
	
	
	<65395f62-74e5-4910-b701-8df629c2ce3b@default>
	
	
	
	
	
	<20120930151314.GU8912@reaktio.net>
	
	
	
	<507C024602000078000A155C@nat28.tlf.novell.com>
	
	<507C226A02000078000A1657@nat28.tlf.novell.com>
	
	<508509D902000078000A2DDA@nat28.tlf.novell.com>
Date: Mon, 22 Oct 2012 11:17:46 +0200
Message-ID: 
From: Mauro 
To: Jan Beulich 
X-Mailman-Approved-At: Mon, 22 Oct 2012 15:11:21 +0000
Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com,
	Keir Fraser , Dan Magenheimer ,
	Olivier Hanesse ,
	Keir Fraser ,
	Xen Users ,
	Mark Adams 
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 22 October 2012 08:54, Jan Beulich  wrote:
>>>> On 21.10.12 at 22:52, Mauro  wrote:
>> On 15 October 2012 14:49, Jan Beulich  wrote:
>>>>>> On 15.10.12 at 13:24, Mauro  wrote:
>>>> I have the problem on this hardware type:
>>>>
>>>> Hp Proliant DL580 G5 with four Intel(R) Xeon(R) CPU E7330  @ 2.40GHz.
>>>> It seem that
>>>> GRUB_CMDLINE_XEN="clocksource=pit cpuidle=0"
>>>> put in in /etc/default/grup (I use linux debian)
>>>> solves the problem for me.
>>>
>>> Did you check whether either or both options on their own also
>>> make the problem go away?
>>
>> It seems that with debian squeeze on my HP Proliant Dl 580 G5 servers
>> is sufficient to use
>> GRUB_CMDLINE_XEN="cpuidle=0".
>> Is from about 20 days that I have no clock jumps.
>> Before I had a clock jump every week.
>> Hope this is the final workaround for me.
>
> So what's the contents of /proc/cpuinfo (any one CPU suffices)
> under a native recent kernel on that system? The most likely
> issue here is that we're mis-identifying the CPU as having an
> always running APIC timer (ARAT)...

uname -a

Linux xen-p01 2.6.32-5-xen-amd64 #1 SMP Sun Sep 23 13:49:30 UTC 2012
x86_64 GNU/Linux

cat /proc/cpuinfo

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Xeon(R) CPU           E7330  @ 2.40GHz
stepping        : 11
cpu MHz         : 2400.176
cache size      : 3072 KB
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu de tsc msr pae mce cx8 apic sep mtrr mca cmov
pat clflush acpi mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc
rep_good aperfmperf pni est ssse3 cx16 hypervisor lahf_lm
bogomips        : 4800.35
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management:

>
> For a second, less intrusive try: Could you replace "cpuidle=0"
> with "max_cstate=1" (assuming the former didn't meanwhile
> turn out not to cure the problem)? If that works too (expected),
> try "max_cstate=2" followed eventually by
> "max_cstate=2 local_apic_timer_c2_ok".

I'll try but to say that it works I've to wait at least two weeks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 15:11:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 15:11:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQJf1-0005Mc-90; Mon, 22 Oct 2012 15:11:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQE8s-0004BJ-1y; Mon, 22 Oct 2012 09:17:50 +0000
Received: from [85.158.139.83:10228] by server-15.bemta-5.messagelabs.com id
	03/BC-28599-D3F05805; Mon, 22 Oct 2012 09:17:49 +0000
X-Env-Sender: mrsanna1@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1350897467!35882572!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20329 invoked from network); 22 Oct 2012 09:17:48 -0000
Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com)
	(209.85.212.43)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 09:17:48 -0000
Received: by mail-vb0-f43.google.com with SMTP id fq11so3265453vbb.30
	for ; Mon, 22 Oct 2012 02:17:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=tY34Tx+WyFe79OQFecDxwuhMFlIwuj91Jx9fnBtzyF8=;
	b=Iy8ftAlZGS4gSqGRg+/jk7sVnhw3zAC53UH7iHeCC0t8lD5D/DBp7GEYtP2PzFuf9L
	swD5mIxQEFExC4w0HWMfUxr3QQ76VDZaQClLcHI2hsFawCjPUgPY9IQsma6awVG0nISP
	B02/Z+cEq80i+/2xihUzl0SQpW0t2/Q5+4/Xqjy359rhGtoVv5aM/M3Qy04GpTnfeC7M
	9w3tWhXa30x13Clgt63hynPFPY3O7NEIl7UuS9DA0kw8h+FnL3/gEHyCUfjMMwJK/4b6
	STwhExo3uOMYX/qcvM/FTRgwtoBCZzMEBW14Cg+TCLaOuyt9CEx40KKLDgkfpnY4M6W+
	pdUQ==
MIME-Version: 1.0
Received: by 10.58.173.41 with SMTP id bh9mr5000252vec.40.1350897467030; Mon,
	22 Oct 2012 02:17:47 -0700 (PDT)
Received: by 10.58.207.75 with HTTP; Mon, 22 Oct 2012 02:17:46 -0700 (PDT)
In-Reply-To: <508509D902000078000A2DDA@nat28.tlf.novell.com>
References: 
	
	
	
	<65395f62-74e5-4910-b701-8df629c2ce3b@default>
	
	
	
	
	
	<20120930151314.GU8912@reaktio.net>
	
	
	
	<507C024602000078000A155C@nat28.tlf.novell.com>
	
	<507C226A02000078000A1657@nat28.tlf.novell.com>
	
	<508509D902000078000A2DDA@nat28.tlf.novell.com>
Date: Mon, 22 Oct 2012 11:17:46 +0200
Message-ID: 
From: Mauro 
To: Jan Beulich 
X-Mailman-Approved-At: Mon, 22 Oct 2012 15:11:21 +0000
Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com,
	Keir Fraser , Dan Magenheimer ,
	Olivier Hanesse ,
	Keir Fraser ,
	Xen Users ,
	Mark Adams 
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 22 October 2012 08:54, Jan Beulich  wrote:
>>>> On 21.10.12 at 22:52, Mauro  wrote:
>> On 15 October 2012 14:49, Jan Beulich  wrote:
>>>>>> On 15.10.12 at 13:24, Mauro  wrote:
>>>> I have the problem on this hardware type:
>>>>
>>>> Hp Proliant DL580 G5 with four Intel(R) Xeon(R) CPU E7330  @ 2.40GHz.
>>>> It seem that
>>>> GRUB_CMDLINE_XEN="clocksource=pit cpuidle=0"
>>>> put in in /etc/default/grup (I use linux debian)
>>>> solves the problem for me.
>>>
>>> Did you check whether either or both options on their own also
>>> make the problem go away?
>>
>> It seems that with debian squeeze on my HP Proliant Dl 580 G5 servers
>> is sufficient to use
>> GRUB_CMDLINE_XEN="cpuidle=0".
>> Is from about 20 days that I have no clock jumps.
>> Before I had a clock jump every week.
>> Hope this is the final workaround for me.
>
> So what's the contents of /proc/cpuinfo (any one CPU suffices)
> under a native recent kernel on that system? The most likely
> issue here is that we're mis-identifying the CPU as having an
> always running APIC timer (ARAT)...

uname -a

Linux xen-p01 2.6.32-5-xen-amd64 #1 SMP Sun Sep 23 13:49:30 UTC 2012
x86_64 GNU/Linux

cat /proc/cpuinfo

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Xeon(R) CPU           E7330  @ 2.40GHz
stepping        : 11
cpu MHz         : 2400.176
cache size      : 3072 KB
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu de tsc msr pae mce cx8 apic sep mtrr mca cmov
pat clflush acpi mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc
rep_good aperfmperf pni est ssse3 cx16 hypervisor lahf_lm
bogomips        : 4800.35
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management:

>
> For a second, less intrusive try: Could you replace "cpuidle=0"
> with "max_cstate=1" (assuming the former didn't meanwhile
> turn out not to cure the problem)? If that works too (expected),
> try "max_cstate=2" followed eventually by
> "max_cstate=2 local_apic_timer_c2_ok".

I'll try but to say that it works I've to wait at least two weeks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 15:22:53 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 15:22:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQJpt-0005p3-38; Mon, 22 Oct 2012 15:22:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TQJpr-0005oy-Sg
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 15:22:35 +0000
Received: from [85.158.143.99:34574] by server-3.bemta-4.messagelabs.com id
	BF/21-03544-BB465805; Mon, 22 Oct 2012 15:22:35 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-216.messagelabs.com!1350919354!34751226!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1746 invoked from network); 22 Oct 2012 15:22:34 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Oct 2012 15:22:34 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TQJpp-0003sn-TZ; Mon, 22 Oct 2012 15:22:33 +0000
Date: Mon, 22 Oct 2012 16:22:33 +0100
From: Tim Deegan 
To: Olaf Hering 
Message-ID: <20121022152233.GG12577@ocelot.phlegethon.org>
References: 
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] p2m: rename p2m_is_magic to p2m_is_pod
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 17:08 +0200 on 22 Oct (1350925724), Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering 
> # Date 1350918469 -7200
> # Node ID de800ac188d5b43f0e8f3cd3b3719ba568fe79c7
> # Parent  2d450b41b7e2cf74940776ab74d41c11206ca46c
> p2m: rename p2m_is_magic to p2m_is_pod
> 
> Signed-off-by: Olaf Hering 

Applied, thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 15:22:53 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 15:22:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQJpt-0005p3-38; Mon, 22 Oct 2012 15:22:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TQJpr-0005oy-Sg
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 15:22:35 +0000
Received: from [85.158.143.99:34574] by server-3.bemta-4.messagelabs.com id
	BF/21-03544-BB465805; Mon, 22 Oct 2012 15:22:35 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-216.messagelabs.com!1350919354!34751226!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1746 invoked from network); 22 Oct 2012 15:22:34 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Oct 2012 15:22:34 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TQJpp-0003sn-TZ; Mon, 22 Oct 2012 15:22:33 +0000
Date: Mon, 22 Oct 2012 16:22:33 +0100
From: Tim Deegan 
To: Olaf Hering 
Message-ID: <20121022152233.GG12577@ocelot.phlegethon.org>
References: 
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] p2m: rename p2m_is_magic to p2m_is_pod
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 17:08 +0200 on 22 Oct (1350925724), Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering 
> # Date 1350918469 -7200
> # Node ID de800ac188d5b43f0e8f3cd3b3719ba568fe79c7
> # Parent  2d450b41b7e2cf74940776ab74d41c11206ca46c
> p2m: rename p2m_is_magic to p2m_is_pod
> 
> Signed-off-by: Olaf Hering 

Applied, thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 15:23:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 15:23:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQJqK-0005qz-G3; Mon, 22 Oct 2012 15:23:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TQJqJ-0005qr-BQ
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 15:23:03 +0000
Received: from [193.109.254.147:4412] by server-1.bemta-14.messagelabs.com id
	F9/FD-20415-6D465805; Mon, 22 Oct 2012 15:23:02 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-27.messagelabs.com!1350919378!5789689!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15695 invoked from network); 22 Oct 2012 15:22:59 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Oct 2012 15:22:59 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TQJqC-0003t5-UD; Mon, 22 Oct 2012 15:22:56 +0000
Date: Mon, 22 Oct 2012 16:22:56 +0100
From: Tim Deegan 
To: Olaf Hering 
Message-ID: <20121022152256.GH12577@ocelot.phlegethon.org>
References: <8ebe7b80f02900d5a83e.1350655780@probook.site>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <8ebe7b80f02900d5a83e.1350655780@probook.site>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] hvm: handle PoD and grant pages in
	HVMOP_get_mem_type
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 16:09 +0200 on 19 Oct (1350662980), Olaf Hering wrote:
> hvm: handle PoD and grant pages in HVMOP_get_mem_type
> 
> During kexec in a ballooned PVonHVM guest the new kernel needs to check
> each pfn if its backed by a mfn to find ballooned pages. Currently all
> PoD and grant pages will appear as HVMMEM_mmio_dm, so the new kernel has
> to assume they are ballooned. This is wrong: PoD pages may turn into
> real RAM at runtime, grant pages are also RAM.
> 
> Signed-off-by: Olaf Hering 

Applied, thanks.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 15:23:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 15:23:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQJqK-0005qz-G3; Mon, 22 Oct 2012 15:23:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TQJqJ-0005qr-BQ
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 15:23:03 +0000
Received: from [193.109.254.147:4412] by server-1.bemta-14.messagelabs.com id
	F9/FD-20415-6D465805; Mon, 22 Oct 2012 15:23:02 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-27.messagelabs.com!1350919378!5789689!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15695 invoked from network); 22 Oct 2012 15:22:59 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Oct 2012 15:22:59 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TQJqC-0003t5-UD; Mon, 22 Oct 2012 15:22:56 +0000
Date: Mon, 22 Oct 2012 16:22:56 +0100
From: Tim Deegan 
To: Olaf Hering 
Message-ID: <20121022152256.GH12577@ocelot.phlegethon.org>
References: <8ebe7b80f02900d5a83e.1350655780@probook.site>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <8ebe7b80f02900d5a83e.1350655780@probook.site>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] hvm: handle PoD and grant pages in
	HVMOP_get_mem_type
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 16:09 +0200 on 19 Oct (1350662980), Olaf Hering wrote:
> hvm: handle PoD and grant pages in HVMOP_get_mem_type
> 
> During kexec in a ballooned PVonHVM guest the new kernel needs to check
> each pfn if its backed by a mfn to find ballooned pages. Currently all
> PoD and grant pages will appear as HVMMEM_mmio_dm, so the new kernel has
> to assume they are ballooned. This is wrong: PoD pages may turn into
> real RAM at runtime, grant pages are also RAM.
> 
> Signed-off-by: Olaf Hering 

Applied, thanks.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 15:24:57 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 15:24:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQJrx-0005ze-08; Mon, 22 Oct 2012 15:24:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TQJrv-0005zS-AH
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 15:24:43 +0000
Received: from [85.158.137.99:29580] by server-4.bemta-3.messagelabs.com id
	91/C4-01405-A3565805; Mon, 22 Oct 2012 15:24:42 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-217.messagelabs.com!1350919481!11916338!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5316 invoked from network); 22 Oct 2012 15:24:41 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Oct 2012 15:24:41 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TQJrs-0003tZ-R4; Mon, 22 Oct 2012 15:24:40 +0000
Date: Mon, 22 Oct 2012 16:24:40 +0100
From: Tim Deegan 
To: Christoph Egger 
Message-ID: <20121022152440.GI12577@ocelot.phlegethon.org>
References: <507E6DF1.7080506@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <507E6DF1.7080506@amd.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] nestedsvm: fix memory leak on shutdown/crash
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 10:36 +0200 on 17 Oct (1350470161), Christoph Egger wrote:
> 
> Fix memory leak of l1 vmcb page when destroying a vcpu while
> l2 guest is running.
> 
> Signed-off-by: Christoph Egger 

Acked-by: Tim Deegan 

Content-Description: xen_nh_shutdown.diff
> diff -r 6b73078a4403 xen/arch/x86/hvm/svm/nestedsvm.c
> --- a/xen/arch/x86/hvm/svm/nestedsvm.c	Fri Oct 12 14:38:20 2012 +0200
> +++ b/xen/arch/x86/hvm/svm/nestedsvm.c	Wed Oct 17 09:08:20 2012 +0200
> @@ -122,6 +122,15 @@ void nsvm_vcpu_destroy(struct vcpu *v)
>      struct nestedvcpu *nv = &vcpu_nestedhvm(v);
>      struct nestedsvm *svm = &vcpu_nestedsvm(v);
>  
> +    /*
> +     * When destroying the vcpu, it may be running on behalf of l2 guest.
> +     * Therefore we need to switch the VMCB pointer back to the l1 vmcb,
> +     * in order to avoid double free of l2 vmcb and the possible memory leak
> +     * of l1 vmcb page.
> +     */
> +    if (nv->nv_n1vmcx)
> +        v->arch.hvm_svm.vmcb = nv->nv_n1vmcx;
> +
>      if (svm->ns_cached_msrpm) {
>          free_xenheap_pages(svm->ns_cached_msrpm,
>                             get_order_from_bytes(MSRPM_SIZE));

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 15:24:57 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 15:24:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQJrx-0005ze-08; Mon, 22 Oct 2012 15:24:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TQJrv-0005zS-AH
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 15:24:43 +0000
Received: from [85.158.137.99:29580] by server-4.bemta-3.messagelabs.com id
	91/C4-01405-A3565805; Mon, 22 Oct 2012 15:24:42 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-217.messagelabs.com!1350919481!11916338!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5316 invoked from network); 22 Oct 2012 15:24:41 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Oct 2012 15:24:41 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TQJrs-0003tZ-R4; Mon, 22 Oct 2012 15:24:40 +0000
Date: Mon, 22 Oct 2012 16:24:40 +0100
From: Tim Deegan 
To: Christoph Egger 
Message-ID: <20121022152440.GI12577@ocelot.phlegethon.org>
References: <507E6DF1.7080506@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <507E6DF1.7080506@amd.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] nestedsvm: fix memory leak on shutdown/crash
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 10:36 +0200 on 17 Oct (1350470161), Christoph Egger wrote:
> 
> Fix memory leak of l1 vmcb page when destroying a vcpu while
> l2 guest is running.
> 
> Signed-off-by: Christoph Egger 

Acked-by: Tim Deegan 

Content-Description: xen_nh_shutdown.diff
> diff -r 6b73078a4403 xen/arch/x86/hvm/svm/nestedsvm.c
> --- a/xen/arch/x86/hvm/svm/nestedsvm.c	Fri Oct 12 14:38:20 2012 +0200
> +++ b/xen/arch/x86/hvm/svm/nestedsvm.c	Wed Oct 17 09:08:20 2012 +0200
> @@ -122,6 +122,15 @@ void nsvm_vcpu_destroy(struct vcpu *v)
>      struct nestedvcpu *nv = &vcpu_nestedhvm(v);
>      struct nestedsvm *svm = &vcpu_nestedsvm(v);
>  
> +    /*
> +     * When destroying the vcpu, it may be running on behalf of l2 guest.
> +     * Therefore we need to switch the VMCB pointer back to the l1 vmcb,
> +     * in order to avoid double free of l2 vmcb and the possible memory leak
> +     * of l1 vmcb page.
> +     */
> +    if (nv->nv_n1vmcx)
> +        v->arch.hvm_svm.vmcb = nv->nv_n1vmcx;
> +
>      if (svm->ns_cached_msrpm) {
>          free_xenheap_pages(svm->ns_cached_msrpm,
>                             get_order_from_bytes(MSRPM_SIZE));

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 15:25:01 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 15:25:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQJs5-00060r-CZ; Mon, 22 Oct 2012 15:24:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TQJs4-00060a-Hg
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 15:24:52 +0000
Received: from [85.158.138.51:7442] by server-2.bemta-3.messagelabs.com id
	34/86-00604-34565805; Mon, 22 Oct 2012 15:24:51 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-174.messagelabs.com!1350919490!27335063!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6760 invoked from network); 22 Oct 2012 15:24:51 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Oct 2012 15:24:51 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TQJs2-0003tq-FU; Mon, 22 Oct 2012 15:24:50 +0000
Date: Mon, 22 Oct 2012 16:24:50 +0100
From: Tim Deegan 
To: Christoph Egger 
Message-ID: <20121022152450.GJ12577@ocelot.phlegethon.org>
References: <507E7593.9080904@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <507E7593.9080904@amd.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] nestedsvm: fix VMEXIT emulation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 11:08 +0200 on 17 Oct (1350472115), Christoph Egger wrote:
> 
> Values in regs can be newer than those in the shadow
> vmcb (e.g. due to an instruction emulation right before).
> So use the values from regs.
> 
> Signed-off-by: Christoph Egger 

Acked-by: Tim Deegan 


Content-Description: xen_nh_vmexit.diff
> diff -r 6b73078a4403 xen/arch/x86/hvm/svm/nestedsvm.c
> --- a/xen/arch/x86/hvm/svm/nestedsvm.c	Fri Oct 12 14:38:20 2012 +0200
> +++ b/xen/arch/x86/hvm/svm/nestedsvm.c	Wed Oct 17 09:19:05 2012 +0200
> @@ -990,7 +999,7 @@ nsvm_vmcb_guest_intercepts_trap(struct v
>  }
>  
>  static int
> -nsvm_vmcb_prepare4vmexit(struct vcpu *v)
> +nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs)
>  {
>      struct nestedvcpu *nv = &vcpu_nestedhvm(v);
>      struct nestedsvm *svm = &vcpu_nestedsvm(v);
> @@ -1114,17 +1123,22 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v)
>      ns_vmcb->_dr7 = n2vmcb->_dr7;
>      ns_vmcb->_dr6 = n2vmcb->_dr6;
>  
> +    /* Restore registers from regs as those values
> +     * can be newer than in n2vmcb (e.g. due to an
> +     * instruction emulation right before).
> +     */
> +
>      /* RFLAGS */
> -    ns_vmcb->rflags = n2vmcb->rflags;
> +    ns_vmcb->rflags = n2vmcb->rflags = regs->rflags;
>  
>      /* RIP */
> -    ns_vmcb->rip = n2vmcb->rip;
> +    ns_vmcb->rip = n2vmcb->rip = regs->rip;
>  
>      /* RSP */
> -    ns_vmcb->rsp = n2vmcb->rsp;
> +    ns_vmcb->rsp = n2vmcb->rsp = regs->rsp;
>  
>      /* RAX */
> -    ns_vmcb->rax = n2vmcb->rax;
> +    ns_vmcb->rax = n2vmcb->rax = regs->rax;
>  
>      /* Keep the l2 guest values of the fs, gs, ldtr, tr, kerngsbase,
>       * star, lstar, cstar, sfmask, sysenter_cs, sysenter_esp,
> @@ -1358,7 +1372,7 @@ nestedsvm_vmexit_n2n1(struct vcpu *v, st
>      ASSERT(vcpu_nestedhvm(v).nv_vmswitch_in_progress);
>      ASSERT(nestedhvm_vcpu_in_guestmode(v));
>  
> -    rc = nsvm_vmcb_prepare4vmexit(v);
> +    rc = nsvm_vmcb_prepare4vmexit(v, regs);
>      if (rc)
>          ret = NESTEDHVM_VMEXIT_ERROR;
>  

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 15:25:01 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 15:25:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQJs5-00060r-CZ; Mon, 22 Oct 2012 15:24:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TQJs4-00060a-Hg
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 15:24:52 +0000
Received: from [85.158.138.51:7442] by server-2.bemta-3.messagelabs.com id
	34/86-00604-34565805; Mon, 22 Oct 2012 15:24:51 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-174.messagelabs.com!1350919490!27335063!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6760 invoked from network); 22 Oct 2012 15:24:51 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Oct 2012 15:24:51 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TQJs2-0003tq-FU; Mon, 22 Oct 2012 15:24:50 +0000
Date: Mon, 22 Oct 2012 16:24:50 +0100
From: Tim Deegan 
To: Christoph Egger 
Message-ID: <20121022152450.GJ12577@ocelot.phlegethon.org>
References: <507E7593.9080904@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <507E7593.9080904@amd.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] nestedsvm: fix VMEXIT emulation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 11:08 +0200 on 17 Oct (1350472115), Christoph Egger wrote:
> 
> Values in regs can be newer than those in the shadow
> vmcb (e.g. due to an instruction emulation right before).
> So use the values from regs.
> 
> Signed-off-by: Christoph Egger 

Acked-by: Tim Deegan 


Content-Description: xen_nh_vmexit.diff
> diff -r 6b73078a4403 xen/arch/x86/hvm/svm/nestedsvm.c
> --- a/xen/arch/x86/hvm/svm/nestedsvm.c	Fri Oct 12 14:38:20 2012 +0200
> +++ b/xen/arch/x86/hvm/svm/nestedsvm.c	Wed Oct 17 09:19:05 2012 +0200
> @@ -990,7 +999,7 @@ nsvm_vmcb_guest_intercepts_trap(struct v
>  }
>  
>  static int
> -nsvm_vmcb_prepare4vmexit(struct vcpu *v)
> +nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs)
>  {
>      struct nestedvcpu *nv = &vcpu_nestedhvm(v);
>      struct nestedsvm *svm = &vcpu_nestedsvm(v);
> @@ -1114,17 +1123,22 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v)
>      ns_vmcb->_dr7 = n2vmcb->_dr7;
>      ns_vmcb->_dr6 = n2vmcb->_dr6;
>  
> +    /* Restore registers from regs as those values
> +     * can be newer than in n2vmcb (e.g. due to an
> +     * instruction emulation right before).
> +     */
> +
>      /* RFLAGS */
> -    ns_vmcb->rflags = n2vmcb->rflags;
> +    ns_vmcb->rflags = n2vmcb->rflags = regs->rflags;
>  
>      /* RIP */
> -    ns_vmcb->rip = n2vmcb->rip;
> +    ns_vmcb->rip = n2vmcb->rip = regs->rip;
>  
>      /* RSP */
> -    ns_vmcb->rsp = n2vmcb->rsp;
> +    ns_vmcb->rsp = n2vmcb->rsp = regs->rsp;
>  
>      /* RAX */
> -    ns_vmcb->rax = n2vmcb->rax;
> +    ns_vmcb->rax = n2vmcb->rax = regs->rax;
>  
>      /* Keep the l2 guest values of the fs, gs, ldtr, tr, kerngsbase,
>       * star, lstar, cstar, sfmask, sysenter_cs, sysenter_esp,
> @@ -1358,7 +1372,7 @@ nestedsvm_vmexit_n2n1(struct vcpu *v, st
>      ASSERT(vcpu_nestedhvm(v).nv_vmswitch_in_progress);
>      ASSERT(nestedhvm_vcpu_in_guestmode(v));
>  
> -    rc = nsvm_vmcb_prepare4vmexit(v);
> +    rc = nsvm_vmcb_prepare4vmexit(v, regs);
>      if (rc)
>          ret = NESTEDHVM_VMEXIT_ERROR;
>  

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 15:33:48 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 15:33:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQK0X-0006Pd-EP; Mon, 22 Oct 2012 15:33:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQK0W-0006PY-6C
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 15:33:36 +0000
Received: from [85.158.137.99:52476] by server-11.bemta-3.messagelabs.com id
	9E/22-24008-F4765805; Mon, 22 Oct 2012 15:33:35 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-217.messagelabs.com!1350920014!17216875!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDUwNzI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDUwNzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12636 invoked from network); 22 Oct 2012 15:33:34 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-8.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Oct 2012 15:33:34 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq0M7qF/64
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-079-154.pools.arcor-ip.net [84.57.79.154])
	by smtp.strato.de (josoe mo30) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id n02effo9MFGwif ;
	Mon, 22 Oct 2012 17:33:33 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 5B1FC18642; Mon, 22 Oct 2012 17:33:33 +0200 (CEST)
Date: Mon, 22 Oct 2012 17:33:33 +0200
From: Olaf Hering 
To: Tim Deegan 
Message-ID: <20121022153333.GA27414@aepfle.de>
References: <8ebe7b80f02900d5a83e.1350655780@probook.site>
	<20121022152256.GH12577@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20121022152256.GH12577@ocelot.phlegethon.org>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] hvm: handle PoD and grant pages in
 HVMOP_get_mem_type
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 22, Tim Deegan wrote:

> At 16:09 +0200 on 19 Oct (1350662980), Olaf Hering wrote:
> > hvm: handle PoD and grant pages in HVMOP_get_mem_type
> > 
> > During kexec in a ballooned PVonHVM guest the new kernel needs to check
> > each pfn if its backed by a mfn to find ballooned pages. Currently all
> > PoD and grant pages will appear as HVMMEM_mmio_dm, so the new kernel has
> > to assume they are ballooned. This is wrong: PoD pages may turn into
> > real RAM at runtime, grant pages are also RAM.
> > 
> > Signed-off-by: Olaf Hering 
> 
> Applied, thanks.

Would you backport this to 4.2 and 4.1?
Without this change the guest will get a wrong picture.
Too bad I did not consider this initially in 23298:26413986e6e0.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 15:33:48 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 15:33:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQK0X-0006Pd-EP; Mon, 22 Oct 2012 15:33:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQK0W-0006PY-6C
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 15:33:36 +0000
Received: from [85.158.137.99:52476] by server-11.bemta-3.messagelabs.com id
	9E/22-24008-F4765805; Mon, 22 Oct 2012 15:33:35 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-217.messagelabs.com!1350920014!17216875!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDUwNzI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDUwNzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12636 invoked from network); 22 Oct 2012 15:33:34 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-8.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Oct 2012 15:33:34 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq0M7qF/64
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-079-154.pools.arcor-ip.net [84.57.79.154])
	by smtp.strato.de (josoe mo30) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id n02effo9MFGwif ;
	Mon, 22 Oct 2012 17:33:33 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 5B1FC18642; Mon, 22 Oct 2012 17:33:33 +0200 (CEST)
Date: Mon, 22 Oct 2012 17:33:33 +0200
From: Olaf Hering 
To: Tim Deegan 
Message-ID: <20121022153333.GA27414@aepfle.de>
References: <8ebe7b80f02900d5a83e.1350655780@probook.site>
	<20121022152256.GH12577@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20121022152256.GH12577@ocelot.phlegethon.org>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] hvm: handle PoD and grant pages in
 HVMOP_get_mem_type
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 22, Tim Deegan wrote:

> At 16:09 +0200 on 19 Oct (1350662980), Olaf Hering wrote:
> > hvm: handle PoD and grant pages in HVMOP_get_mem_type
> > 
> > During kexec in a ballooned PVonHVM guest the new kernel needs to check
> > each pfn if its backed by a mfn to find ballooned pages. Currently all
> > PoD and grant pages will appear as HVMMEM_mmio_dm, so the new kernel has
> > to assume they are ballooned. This is wrong: PoD pages may turn into
> > real RAM at runtime, grant pages are also RAM.
> > 
> > Signed-off-by: Olaf Hering 
> 
> Applied, thanks.

Would you backport this to 4.2 and 4.1?
Without this change the guest will get a wrong picture.
Too bad I did not consider this initially in 23298:26413986e6e0.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 15:53:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 15:53:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQKJS-0006da-7c; Mon, 22 Oct 2012 15:53:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQKJQ-0006dN-Qb
	for xen-devel@lists.xensource.com; Mon, 22 Oct 2012 15:53:09 +0000
Received: from [85.158.137.99:10325] by server-14.bemta-3.messagelabs.com id
	CA/AC-17276-4EB65805; Mon, 22 Oct 2012 15:53:08 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1350921185!11918996!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25279 invoked from network); 22 Oct 2012 15:53:06 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-6.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Oct 2012 15:53:06 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9MFqw2W016400
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 22 Oct 2012 15:52:59 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9MFqvOx015622
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 22 Oct 2012 15:52:58 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9MFqvkW032070; Mon, 22 Oct 2012 10:52:57 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 22 Oct 2012 08:52:57 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 4F3AA402BD; Mon, 22 Oct 2012 11:40:49 -0400 (EDT)
Date: Mon, 22 Oct 2012 11:40:49 -0400
From: Konrad Rzeszutek Wilk 
To: Stefano Stabellini 
Message-ID: <20121022154049.GA25200@phenom.dumpdata.com>
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
	<1350695882-12820-3-git-send-email-konrad.wilk@oracle.com>
	
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Ian Campbell 
Subject: Re: [Xen-devel] [PATCH 2/6] xen/pvh: Extend vcpu_guest_context, p2m,
 event, and xenbus to support PVH.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 22, 2012 at 02:44:40PM +0100, Stefano Stabellini wrote:
> On Sat, 20 Oct 2012, Konrad Rzeszutek Wilk wrote:
> > From: Mukesh Rathor 
> > 
> > make gdt_frames[]/gdt_ents into a union with {gdtaddr, gdtsz}, as PVH
> > only needs to send down gdtaddr and gdtsz.
> > 
> > For interrupts, PVH uses native_irq_ops.
> > vcpu hotplug is currently not available for PVH.
> > 
> > For events we follow what PVHVM does - to use callback vector.
> > Lastly, also use HVM path to setup XenBus.
> > 
> > Signed-off-by: Mukesh Rathor 
> > Signed-off-by: Konrad Rzeszutek Wilk 
> > ---
> >  arch/x86/include/asm/xen/interface.h |   11 +++++-
> >  arch/x86/xen/irq.c                   |    5 ++-
> >  arch/x86/xen/p2m.c                   |    2 +-
> >  arch/x86/xen/smp.c                   |   75 ++++++++++++++++++++++------------
> >  drivers/xen/cpu_hotplug.c            |    4 +-
> >  drivers/xen/events.c                 |    9 ++++-
> >  drivers/xen/xenbus/xenbus_client.c   |    3 +-
> >  7 files changed, 77 insertions(+), 32 deletions(-)
> > 
> > diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
> > index 6d2f75a..4c08f23 100644
> > --- a/arch/x86/include/asm/xen/interface.h
> > +++ b/arch/x86/include/asm/xen/interface.h
> > @@ -144,7 +144,16 @@ struct vcpu_guest_context {
> >      struct cpu_user_regs user_regs;         /* User-level CPU registers     */
> >      struct trap_info trap_ctxt[256];        /* Virtual IDT                  */
> >      unsigned long ldt_base, ldt_ents;       /* LDT (linear address, # ents) */
> > -    unsigned long gdt_frames[16], gdt_ents; /* GDT (machine frames, # ents) */
> > +    union {
> > +	struct {
> > +		/* PV: GDT (machine frames, # ents).*/
> > +		unsigned long gdt_frames[16], gdt_ents;
> > +	} pv;
> > +	struct {
> > +		/* PVH: GDTR addr and size */
> > +		unsigned long gdtaddr, gdtsz;
> > +	} pvh;
> > +    } u;
> >      unsigned long kernel_ss, kernel_sp;     /* Virtual TSS (only SS1/SP1)   */
> >      /* NB. User pagetable on x86/64 is placed in ctrlreg[1]. */
> >      unsigned long ctrlreg[8];               /* CR0-CR7 (control registers)  */
> > diff --git a/arch/x86/xen/irq.c b/arch/x86/xen/irq.c
> > index 01a4dc0..fcbe56a 100644
> > --- a/arch/x86/xen/irq.c
> > +++ b/arch/x86/xen/irq.c
> > @@ -5,6 +5,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  
> >  #include 
> > @@ -129,6 +130,8 @@ static const struct pv_irq_ops xen_irq_ops __initconst = {
> >  
> >  void __init xen_init_irq_ops(void)
> >  {
> > -	pv_irq_ops = xen_irq_ops;
> > +	/* For PVH we use default pv_irq_ops settings */
> > +	if (!xen_feature(XENFEAT_hvm_callback_vector))
> > +		pv_irq_ops = xen_irq_ops;
> >  	x86_init.irqs.intr_init = xen_init_IRQ;
> >  }
> > diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
> > index 95fb2aa..ea553c8 100644
> > --- a/arch/x86/xen/p2m.c
> > +++ b/arch/x86/xen/p2m.c
> > @@ -798,7 +798,7 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
> >  {
> >  	unsigned topidx, mididx, idx;
> >  
> > -	if (unlikely(xen_feature(XENFEAT_auto_translated_physmap))) {
> > +	if (xen_feature(XENFEAT_auto_translated_physmap)) {
> >  		BUG_ON(pfn != mfn && mfn != INVALID_P2M_ENTRY);
> >  		return true;
> >  	}
> > diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
> > index 353c50f..df400349 100644
> > --- a/arch/x86/xen/smp.c
> > +++ b/arch/x86/xen/smp.c
> > @@ -68,9 +68,11 @@ static void __cpuinit cpu_bringup(void)
> >  	touch_softlockup_watchdog();
> >  	preempt_disable();
> >  
> > -	xen_enable_sysenter();
> > -	xen_enable_syscall();
> > -
> > +	/* PVH runs in ring 0 and allows us to do native syscalls. Yay! */
> > +	if (!xen_feature(XENFEAT_supervisor_mode_kernel)) {
> > +		xen_enable_sysenter();
> > +		xen_enable_syscall();
> > +	}
> >  	cpu = smp_processor_id();
> >  	smp_store_cpu_info(cpu);
> >  	cpu_data(cpu).x86_max_cores = 1;
> > @@ -230,10 +232,11 @@ static void __init xen_smp_prepare_boot_cpu(void)
> >  	BUG_ON(smp_processor_id() != 0);
> >  	native_smp_prepare_boot_cpu();
> >  
> > -	/* We've switched to the "real" per-cpu gdt, so make sure the
> > -	   old memory can be recycled */
> > -	make_lowmem_page_readwrite(xen_initial_gdt);
> > -
> > +	if (!xen_feature(XENFEAT_writable_page_tables)) {
> > +		/* We've switched to the "real" per-cpu gdt, so make sure the
> > +		 * old memory can be recycled */
> > +		make_lowmem_page_readwrite(xen_initial_gdt);
> > +	}
> >  	xen_filter_cpu_maps();
> >  	xen_setup_vcpu_info_placement();
> >  }
> > @@ -300,8 +303,6 @@ cpu_initialize_context(unsigned int cpu, struct task_struct *idle)
> >  	gdt = get_cpu_gdt_table(cpu);
> >  
> >  	ctxt->flags = VGCF_IN_KERNEL;
> > -	ctxt->user_regs.ds = __USER_DS;
> > -	ctxt->user_regs.es = __USER_DS;
> >  	ctxt->user_regs.ss = __KERNEL_DS;
> >  #ifdef CONFIG_X86_32
> >  	ctxt->user_regs.fs = __KERNEL_PERCPU;
> > @@ -310,35 +311,57 @@ cpu_initialize_context(unsigned int cpu, struct task_struct *idle)
> >  	ctxt->gs_base_kernel = per_cpu_offset(cpu);
> >  #endif
> >  	ctxt->user_regs.eip = (unsigned long)cpu_bringup_and_idle;
> > -	ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
> >  
> >  	memset(&ctxt->fpu_ctxt, 0, sizeof(ctxt->fpu_ctxt));
> >  
> > -	xen_copy_trap_info(ctxt->trap_ctxt);
> > +	/* check for autoxlated to get it right for 32bit kernel */
> 
> I am not sure what this comment means, considering that in another
> comment below you say that we don't support 32bit PVH kernels.

Hm, even the V1 had this. I think he meant something else.

> 
> 
> > +	if (xen_feature(XENFEAT_auto_translated_physmap) &&
> > +	    xen_feature(XENFEAT_supervisor_mode_kernel)) {
> >  
> > -	ctxt->ldt_ents = 0;
> > +		ctxt->user_regs.ds = __KERNEL_DS;
> > +		ctxt->user_regs.es = 0;
> > +		ctxt->user_regs.gs = 0;
> >  
> > -	BUG_ON((unsigned long)gdt & ~PAGE_MASK);
> > +		ctxt->u.pvh.gdtaddr = (unsigned long)gdt;
> > +		ctxt->u.pvh.gdtsz = (unsigned long)(GDT_SIZE - 1);
> >  
> > -	gdt_mfn = arbitrary_virt_to_mfn(gdt);
> > -	make_lowmem_page_readonly(gdt);
> > -	make_lowmem_page_readonly(mfn_to_virt(gdt_mfn));
> > +#ifdef CONFIG_X86_64
> > +		/* Note: PVH is not supported on x86_32. */
> > +		ctxt->gs_base_user = (unsigned long)
> > +					per_cpu(irq_stack_union.gs_base, cpu);
> > +#endif
> > +	} else {
> > +		ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
> > +		ctxt->user_regs.ds = __USER_DS;
> > +		ctxt->user_regs.es = __USER_DS;
> >  
> > -	ctxt->gdt_frames[0] = gdt_mfn;
> > -	ctxt->gdt_ents      = GDT_ENTRIES;
> > +		xen_copy_trap_info(ctxt->trap_ctxt);
> >  
> > -	ctxt->user_regs.cs = __KERNEL_CS;
> > -	ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct pt_regs);
> > +		ctxt->ldt_ents = 0;
> >  
> > -	ctxt->kernel_ss = __KERNEL_DS;
> > -	ctxt->kernel_sp = idle->thread.sp0;
> > +		BUG_ON((unsigned long)gdt & ~PAGE_MASK);
> > +
> > +		gdt_mfn = arbitrary_virt_to_mfn(gdt);
> > +		make_lowmem_page_readonly(gdt);
> > +		make_lowmem_page_readonly(mfn_to_virt(gdt_mfn));
> > +
> > +		ctxt->u.pv.gdt_frames[0] = gdt_mfn;
> > +		ctxt->u.pv.gdt_ents      = GDT_ENTRIES;
> > +
> > +		ctxt->kernel_ss = __KERNEL_DS;
> > +		ctxt->kernel_sp = idle->thread.sp0;
> >  
> >  #ifdef CONFIG_X86_32
> > -	ctxt->event_callback_cs     = __KERNEL_CS;
> > -	ctxt->failsafe_callback_cs  = __KERNEL_CS;
> > +		ctxt->event_callback_cs     = __KERNEL_CS;
> > +		ctxt->failsafe_callback_cs  = __KERNEL_CS;
> >  #endif
> > -	ctxt->event_callback_eip    = (unsigned long)xen_hypervisor_callback;
> > -	ctxt->failsafe_callback_eip = (unsigned long)xen_failsafe_callback;
> > +		ctxt->event_callback_eip    =
> > +					(unsigned long)xen_hypervisor_callback;
> > +		ctxt->failsafe_callback_eip =
> > +					(unsigned long)xen_failsafe_callback;
> > +	}
> > +	ctxt->user_regs.cs = __KERNEL_CS;
> > +	ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct pt_regs);
> >  
> >  	per_cpu(xen_cr3, cpu) = __pa(swapper_pg_dir);
> >  	ctxt->ctrlreg[3] = xen_pfn_to_cr3(virt_to_mfn(swapper_pg_dir));
> 
> The tradional path looks the same as before, however it is hard to tell
> whether the PVH path is correct without the Xen side. For example, what
> is gdtsz?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 15:53:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 15:53:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQKJS-0006da-7c; Mon, 22 Oct 2012 15:53:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQKJQ-0006dN-Qb
	for xen-devel@lists.xensource.com; Mon, 22 Oct 2012 15:53:09 +0000
Received: from [85.158.137.99:10325] by server-14.bemta-3.messagelabs.com id
	CA/AC-17276-4EB65805; Mon, 22 Oct 2012 15:53:08 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1350921185!11918996!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25279 invoked from network); 22 Oct 2012 15:53:06 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-6.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Oct 2012 15:53:06 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9MFqw2W016400
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 22 Oct 2012 15:52:59 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9MFqvOx015622
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 22 Oct 2012 15:52:58 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9MFqvkW032070; Mon, 22 Oct 2012 10:52:57 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 22 Oct 2012 08:52:57 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 4F3AA402BD; Mon, 22 Oct 2012 11:40:49 -0400 (EDT)
Date: Mon, 22 Oct 2012 11:40:49 -0400
From: Konrad Rzeszutek Wilk 
To: Stefano Stabellini 
Message-ID: <20121022154049.GA25200@phenom.dumpdata.com>
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
	<1350695882-12820-3-git-send-email-konrad.wilk@oracle.com>
	
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Ian Campbell 
Subject: Re: [Xen-devel] [PATCH 2/6] xen/pvh: Extend vcpu_guest_context, p2m,
 event, and xenbus to support PVH.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 22, 2012 at 02:44:40PM +0100, Stefano Stabellini wrote:
> On Sat, 20 Oct 2012, Konrad Rzeszutek Wilk wrote:
> > From: Mukesh Rathor 
> > 
> > make gdt_frames[]/gdt_ents into a union with {gdtaddr, gdtsz}, as PVH
> > only needs to send down gdtaddr and gdtsz.
> > 
> > For interrupts, PVH uses native_irq_ops.
> > vcpu hotplug is currently not available for PVH.
> > 
> > For events we follow what PVHVM does - to use callback vector.
> > Lastly, also use HVM path to setup XenBus.
> > 
> > Signed-off-by: Mukesh Rathor 
> > Signed-off-by: Konrad Rzeszutek Wilk 
> > ---
> >  arch/x86/include/asm/xen/interface.h |   11 +++++-
> >  arch/x86/xen/irq.c                   |    5 ++-
> >  arch/x86/xen/p2m.c                   |    2 +-
> >  arch/x86/xen/smp.c                   |   75 ++++++++++++++++++++++------------
> >  drivers/xen/cpu_hotplug.c            |    4 +-
> >  drivers/xen/events.c                 |    9 ++++-
> >  drivers/xen/xenbus/xenbus_client.c   |    3 +-
> >  7 files changed, 77 insertions(+), 32 deletions(-)
> > 
> > diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
> > index 6d2f75a..4c08f23 100644
> > --- a/arch/x86/include/asm/xen/interface.h
> > +++ b/arch/x86/include/asm/xen/interface.h
> > @@ -144,7 +144,16 @@ struct vcpu_guest_context {
> >      struct cpu_user_regs user_regs;         /* User-level CPU registers     */
> >      struct trap_info trap_ctxt[256];        /* Virtual IDT                  */
> >      unsigned long ldt_base, ldt_ents;       /* LDT (linear address, # ents) */
> > -    unsigned long gdt_frames[16], gdt_ents; /* GDT (machine frames, # ents) */
> > +    union {
> > +	struct {
> > +		/* PV: GDT (machine frames, # ents).*/
> > +		unsigned long gdt_frames[16], gdt_ents;
> > +	} pv;
> > +	struct {
> > +		/* PVH: GDTR addr and size */
> > +		unsigned long gdtaddr, gdtsz;
> > +	} pvh;
> > +    } u;
> >      unsigned long kernel_ss, kernel_sp;     /* Virtual TSS (only SS1/SP1)   */
> >      /* NB. User pagetable on x86/64 is placed in ctrlreg[1]. */
> >      unsigned long ctrlreg[8];               /* CR0-CR7 (control registers)  */
> > diff --git a/arch/x86/xen/irq.c b/arch/x86/xen/irq.c
> > index 01a4dc0..fcbe56a 100644
> > --- a/arch/x86/xen/irq.c
> > +++ b/arch/x86/xen/irq.c
> > @@ -5,6 +5,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  
> >  #include 
> > @@ -129,6 +130,8 @@ static const struct pv_irq_ops xen_irq_ops __initconst = {
> >  
> >  void __init xen_init_irq_ops(void)
> >  {
> > -	pv_irq_ops = xen_irq_ops;
> > +	/* For PVH we use default pv_irq_ops settings */
> > +	if (!xen_feature(XENFEAT_hvm_callback_vector))
> > +		pv_irq_ops = xen_irq_ops;
> >  	x86_init.irqs.intr_init = xen_init_IRQ;
> >  }
> > diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
> > index 95fb2aa..ea553c8 100644
> > --- a/arch/x86/xen/p2m.c
> > +++ b/arch/x86/xen/p2m.c
> > @@ -798,7 +798,7 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
> >  {
> >  	unsigned topidx, mididx, idx;
> >  
> > -	if (unlikely(xen_feature(XENFEAT_auto_translated_physmap))) {
> > +	if (xen_feature(XENFEAT_auto_translated_physmap)) {
> >  		BUG_ON(pfn != mfn && mfn != INVALID_P2M_ENTRY);
> >  		return true;
> >  	}
> > diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
> > index 353c50f..df400349 100644
> > --- a/arch/x86/xen/smp.c
> > +++ b/arch/x86/xen/smp.c
> > @@ -68,9 +68,11 @@ static void __cpuinit cpu_bringup(void)
> >  	touch_softlockup_watchdog();
> >  	preempt_disable();
> >  
> > -	xen_enable_sysenter();
> > -	xen_enable_syscall();
> > -
> > +	/* PVH runs in ring 0 and allows us to do native syscalls. Yay! */
> > +	if (!xen_feature(XENFEAT_supervisor_mode_kernel)) {
> > +		xen_enable_sysenter();
> > +		xen_enable_syscall();
> > +	}
> >  	cpu = smp_processor_id();
> >  	smp_store_cpu_info(cpu);
> >  	cpu_data(cpu).x86_max_cores = 1;
> > @@ -230,10 +232,11 @@ static void __init xen_smp_prepare_boot_cpu(void)
> >  	BUG_ON(smp_processor_id() != 0);
> >  	native_smp_prepare_boot_cpu();
> >  
> > -	/* We've switched to the "real" per-cpu gdt, so make sure the
> > -	   old memory can be recycled */
> > -	make_lowmem_page_readwrite(xen_initial_gdt);
> > -
> > +	if (!xen_feature(XENFEAT_writable_page_tables)) {
> > +		/* We've switched to the "real" per-cpu gdt, so make sure the
> > +		 * old memory can be recycled */
> > +		make_lowmem_page_readwrite(xen_initial_gdt);
> > +	}
> >  	xen_filter_cpu_maps();
> >  	xen_setup_vcpu_info_placement();
> >  }
> > @@ -300,8 +303,6 @@ cpu_initialize_context(unsigned int cpu, struct task_struct *idle)
> >  	gdt = get_cpu_gdt_table(cpu);
> >  
> >  	ctxt->flags = VGCF_IN_KERNEL;
> > -	ctxt->user_regs.ds = __USER_DS;
> > -	ctxt->user_regs.es = __USER_DS;
> >  	ctxt->user_regs.ss = __KERNEL_DS;
> >  #ifdef CONFIG_X86_32
> >  	ctxt->user_regs.fs = __KERNEL_PERCPU;
> > @@ -310,35 +311,57 @@ cpu_initialize_context(unsigned int cpu, struct task_struct *idle)
> >  	ctxt->gs_base_kernel = per_cpu_offset(cpu);
> >  #endif
> >  	ctxt->user_regs.eip = (unsigned long)cpu_bringup_and_idle;
> > -	ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
> >  
> >  	memset(&ctxt->fpu_ctxt, 0, sizeof(ctxt->fpu_ctxt));
> >  
> > -	xen_copy_trap_info(ctxt->trap_ctxt);
> > +	/* check for autoxlated to get it right for 32bit kernel */
> 
> I am not sure what this comment means, considering that in another
> comment below you say that we don't support 32bit PVH kernels.

Hm, even the V1 had this. I think he meant something else.

> 
> 
> > +	if (xen_feature(XENFEAT_auto_translated_physmap) &&
> > +	    xen_feature(XENFEAT_supervisor_mode_kernel)) {
> >  
> > -	ctxt->ldt_ents = 0;
> > +		ctxt->user_regs.ds = __KERNEL_DS;
> > +		ctxt->user_regs.es = 0;
> > +		ctxt->user_regs.gs = 0;
> >  
> > -	BUG_ON((unsigned long)gdt & ~PAGE_MASK);
> > +		ctxt->u.pvh.gdtaddr = (unsigned long)gdt;
> > +		ctxt->u.pvh.gdtsz = (unsigned long)(GDT_SIZE - 1);
> >  
> > -	gdt_mfn = arbitrary_virt_to_mfn(gdt);
> > -	make_lowmem_page_readonly(gdt);
> > -	make_lowmem_page_readonly(mfn_to_virt(gdt_mfn));
> > +#ifdef CONFIG_X86_64
> > +		/* Note: PVH is not supported on x86_32. */
> > +		ctxt->gs_base_user = (unsigned long)
> > +					per_cpu(irq_stack_union.gs_base, cpu);
> > +#endif
> > +	} else {
> > +		ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
> > +		ctxt->user_regs.ds = __USER_DS;
> > +		ctxt->user_regs.es = __USER_DS;
> >  
> > -	ctxt->gdt_frames[0] = gdt_mfn;
> > -	ctxt->gdt_ents      = GDT_ENTRIES;
> > +		xen_copy_trap_info(ctxt->trap_ctxt);
> >  
> > -	ctxt->user_regs.cs = __KERNEL_CS;
> > -	ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct pt_regs);
> > +		ctxt->ldt_ents = 0;
> >  
> > -	ctxt->kernel_ss = __KERNEL_DS;
> > -	ctxt->kernel_sp = idle->thread.sp0;
> > +		BUG_ON((unsigned long)gdt & ~PAGE_MASK);
> > +
> > +		gdt_mfn = arbitrary_virt_to_mfn(gdt);
> > +		make_lowmem_page_readonly(gdt);
> > +		make_lowmem_page_readonly(mfn_to_virt(gdt_mfn));
> > +
> > +		ctxt->u.pv.gdt_frames[0] = gdt_mfn;
> > +		ctxt->u.pv.gdt_ents      = GDT_ENTRIES;
> > +
> > +		ctxt->kernel_ss = __KERNEL_DS;
> > +		ctxt->kernel_sp = idle->thread.sp0;
> >  
> >  #ifdef CONFIG_X86_32
> > -	ctxt->event_callback_cs     = __KERNEL_CS;
> > -	ctxt->failsafe_callback_cs  = __KERNEL_CS;
> > +		ctxt->event_callback_cs     = __KERNEL_CS;
> > +		ctxt->failsafe_callback_cs  = __KERNEL_CS;
> >  #endif
> > -	ctxt->event_callback_eip    = (unsigned long)xen_hypervisor_callback;
> > -	ctxt->failsafe_callback_eip = (unsigned long)xen_failsafe_callback;
> > +		ctxt->event_callback_eip    =
> > +					(unsigned long)xen_hypervisor_callback;
> > +		ctxt->failsafe_callback_eip =
> > +					(unsigned long)xen_failsafe_callback;
> > +	}
> > +	ctxt->user_regs.cs = __KERNEL_CS;
> > +	ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct pt_regs);
> >  
> >  	per_cpu(xen_cr3, cpu) = __pa(swapper_pg_dir);
> >  	ctxt->ctrlreg[3] = xen_pfn_to_cr3(virt_to_mfn(swapper_pg_dir));
> 
> The tradional path looks the same as before, however it is hard to tell
> whether the PVH path is correct without the Xen side. For example, what
> is gdtsz?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 16:10:01 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 16:10:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQKZM-0007TP-6b; Mon, 22 Oct 2012 16:09:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQKZL-0007TK-7Y
	for xen-devel@lists.xensource.com; Mon, 22 Oct 2012 16:09:35 +0000
Received: from [85.158.139.211:3169] by server-10.bemta-5.messagelabs.com id
	A1/19-01025-EBF65805; Mon, 22 Oct 2012 16:09:34 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1350922172!23332781!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgyNTg4Ng==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6345 invoked from network); 22 Oct 2012 16:09:33 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Oct 2012 16:09:33 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9MG9QBR027979
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 22 Oct 2012 16:09:26 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9MG9Ptj018714
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 22 Oct 2012 16:09:26 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9MG9PrI013663; Mon, 22 Oct 2012 11:09:25 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 22 Oct 2012 09:09:25 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 4911E402E8; Mon, 22 Oct 2012 11:57:17 -0400 (EDT)
Date: Mon, 22 Oct 2012 11:57:17 -0400
From: Konrad Rzeszutek Wilk 
To: Stefano Stabellini 
Message-ID: <20121022155717.GB25200@phenom.dumpdata.com>
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
	<1350695882-12820-5-git-send-email-konrad.wilk@oracle.com>
	
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Ian Campbell 
Subject: Re: [Xen-devel] [PATCH 4/6] xen/pvh: bootup and setup related
	changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 22, 2012 at 02:34:44PM +0100, Stefano Stabellini wrote:
> On Sat, 20 Oct 2012, Konrad Rzeszutek Wilk wrote:
> > From: Mukesh Rathor 
> > 
> > In enlighten.c for PVH we can trap cpuid via vmexit, so don't
> > need to use emulated prefix call. We also check for vector callback
> > early on, as it is a required feature. PVH also runs at default kernel
> > IOPL.
> > 
> > In setup.c, in xen_add_extra_mem() we can skip updating P2M as it's managed
> > by Xen. PVH maps the entire IO space, but only RAM pages need to be repopulated.
> > 
> > Finally, pure PV settings are moved to a separate function that is only called
> > for pure PV, ie, pv with pvmmu.
> > 
> > Signed-off-by: Mukesh Rathor 
> > Signed-off-by: Konrad Rzeszutek Wilk 
> >
> > diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> > index 8971a26..8cce47b 100644
> > --- a/arch/x86/xen/setup.c
> > +++ b/arch/x86/xen/setup.c
> > @@ -27,6 +27,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include "mmu.h"
> >  #include "xen-ops.h"
> >  #include "vdso.h"
> >  
> > @@ -78,6 +79,9 @@ static void __init xen_add_extra_mem(u64 start, u64 size)
> >  
> >  	memblock_reserve(start, size);
> >  
> > +	if (xen_feature(XENFEAT_auto_translated_physmap))
> > +		return;
> > +
> >  	xen_max_p2m_pfn = PFN_DOWN(start + size);
> >  	for (pfn = PFN_DOWN(start); pfn < xen_max_p2m_pfn; pfn++) {
> >  		unsigned long mfn = pfn_to_mfn(pfn);
> > @@ -100,6 +104,7 @@ static unsigned long __init xen_do_chunk(unsigned long start,
> >  		.domid        = DOMID_SELF
> >  	};
> >  	unsigned long len = 0;
> > +	int xlated_phys = xen_feature(XENFEAT_auto_translated_physmap);
> >  	unsigned long pfn;
> >  	int ret;
> >  
> > @@ -113,7 +118,7 @@ static unsigned long __init xen_do_chunk(unsigned long start,
> >  				continue;
> >  			frame = mfn;
> >  		} else {
> > -			if (mfn != INVALID_P2M_ENTRY)
> > +			if (!xlated_phys && mfn != INVALID_P2M_ENTRY)
> >  				continue;
> >  			frame = pfn;
> >  		}
> 
> Shouldn't we add a "!xlated_phys &&" to the other case as well?

No. That is handled in xen_pvh_identity_map_chunk which
just does a xen_set_clr_mmio_pvh_pte call for the "released"
pages. But that is a bit of ... well, extra logic. I think
if we did this it would work and look much nicer:


diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 8cce47b..b451a77 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -114,9 +114,15 @@ static unsigned long __init xen_do_chunk(unsigned long start,
 
 		if (release) {
 			/* Make sure pfn exists to start with */
-			if (mfn == INVALID_P2M_ENTRY || mfn_to_pfn(mfn) != pfn)
+			if (mfn == INVALID_P2M_ENTRY || (!xlated_phys && (mfn_to_pfn(mfn) != pfn)))
 				continue;
 			frame = mfn;
+			/* The hypercall PHYSDEVOP_map_iomem to release memory has already
+			 * happend, so we just do a nop here. */
+			if (xlated_phys) {
+				len++;
+				continue;
+			}
 		} else {
 			if (!xlated_phys && mfn != INVALID_P2M_ENTRY)
 				continue;
@@ -219,15 +225,24 @@ static void __init xen_set_identity_and_release_chunk(
 {
 	unsigned long pfn;
 
+	/* For PVH, the pfns [0..MAX] are mapped to mfn's in the EPT/NPT. The mfns
+	 * are released as part of this 1:1 mapping hypercall back to the dom heap.
+	 * Also, we map the entire IO space, ie, beyond max_pfn_mapped.
+	 */
+	int xlated_phys = xen_feature(XENFEAT_auto_translated_physmap);
+
 	/*
 	 * If the PFNs are currently mapped, the VA mapping also needs
 	 * to be updated to be 1:1.
 	 */
-	for (pfn = start_pfn; pfn <= max_pfn_mapped && pfn < end_pfn; pfn++)
-		(void)HYPERVISOR_update_va_mapping(
-			(unsigned long)__va(pfn << PAGE_SHIFT),
-			mfn_pte(pfn, PAGE_KERNEL_IO), 0);
-
+	for (pfn = start_pfn; pfn <= max_pfn_mapped && pfn < end_pfn; pfn++) {
+		if (xlated_phys)
+			xen_set_clr_mmio_pvh_pte(pfn, pfn, 1 /* one pfn */, 1 /* add mapping */);
+		else
+			(void)HYPERVISOR_update_va_mapping(
+				(unsigned long)__va(pfn << PAGE_SHIFT),
+				mfn_pte(pfn, PAGE_KERNEL_IO), 0);
+	}
 	if (start_pfn < nr_pages)
 		*released += xen_release_chunk(
 			start_pfn, min(end_pfn, nr_pages));
@@ -235,27 +250,6 @@ static void __init xen_set_identity_and_release_chunk(
 	*identity += set_phys_range_identity(start_pfn, end_pfn);
 }
 
-/* For PVH, the pfns [0..MAX] are mapped to mfn's in the EPT/NPT. The mfns
- * are released as part of this 1:1 mapping hypercall back to the dom heap.
- * Also, we map the entire IO space, ie, beyond max_pfn_mapped.
- */
-static void __init xen_pvh_identity_map_chunk(unsigned long start_pfn,
-		unsigned long end_pfn, unsigned long *released,
-		unsigned long *identity, unsigned long max_pfn)
-{
-	unsigned long pfn;
-	int numpfns = 1, add_mapping = 1;
-
-	for (pfn = start_pfn; pfn < end_pfn; pfn++)
-		xen_set_clr_mmio_pvh_pte(pfn, pfn, numpfns, add_mapping);
-
-	if (start_pfn <= max_pfn) {
-		unsigned long end = min(max_pfn_mapped, end_pfn);
-		*released += end - start_pfn;
-	}
-	*identity += end_pfn - start_pfn;
-}
-
 static unsigned long __init xen_set_identity_and_release(
 	const struct e820entry *list, size_t map_size, unsigned long nr_pages)
 {
@@ -286,17 +280,10 @@ static unsigned long __init xen_set_identity_and_release(
 			if (entry->type == E820_RAM)
 				end_pfn = PFN_UP(entry->addr);
 
-			if (start_pfn < end_pfn) {
-				if (xlated_phys) {
-					xen_pvh_identity_map_chunk(start_pfn,
-						end_pfn, &released, &identity,
-						nr_pages);
-				} else {
-					xen_set_identity_and_release_chunk(
+			if (start_pfn < end_pfn)
+				xen_set_identity_and_release_chunk(
 						start_pfn, end_pfn, nr_pages,
 						&released, &identity);
-				}
-			}
 			start = end;
 		}
 	}


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 16:10:01 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 16:10:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQKZM-0007TP-6b; Mon, 22 Oct 2012 16:09:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQKZL-0007TK-7Y
	for xen-devel@lists.xensource.com; Mon, 22 Oct 2012 16:09:35 +0000
Received: from [85.158.139.211:3169] by server-10.bemta-5.messagelabs.com id
	A1/19-01025-EBF65805; Mon, 22 Oct 2012 16:09:34 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1350922172!23332781!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgyNTg4Ng==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6345 invoked from network); 22 Oct 2012 16:09:33 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Oct 2012 16:09:33 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9MG9QBR027979
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 22 Oct 2012 16:09:26 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9MG9Ptj018714
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 22 Oct 2012 16:09:26 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9MG9PrI013663; Mon, 22 Oct 2012 11:09:25 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 22 Oct 2012 09:09:25 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 4911E402E8; Mon, 22 Oct 2012 11:57:17 -0400 (EDT)
Date: Mon, 22 Oct 2012 11:57:17 -0400
From: Konrad Rzeszutek Wilk 
To: Stefano Stabellini 
Message-ID: <20121022155717.GB25200@phenom.dumpdata.com>
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
	<1350695882-12820-5-git-send-email-konrad.wilk@oracle.com>
	
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Ian Campbell 
Subject: Re: [Xen-devel] [PATCH 4/6] xen/pvh: bootup and setup related
	changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 22, 2012 at 02:34:44PM +0100, Stefano Stabellini wrote:
> On Sat, 20 Oct 2012, Konrad Rzeszutek Wilk wrote:
> > From: Mukesh Rathor 
> > 
> > In enlighten.c for PVH we can trap cpuid via vmexit, so don't
> > need to use emulated prefix call. We also check for vector callback
> > early on, as it is a required feature. PVH also runs at default kernel
> > IOPL.
> > 
> > In setup.c, in xen_add_extra_mem() we can skip updating P2M as it's managed
> > by Xen. PVH maps the entire IO space, but only RAM pages need to be repopulated.
> > 
> > Finally, pure PV settings are moved to a separate function that is only called
> > for pure PV, ie, pv with pvmmu.
> > 
> > Signed-off-by: Mukesh Rathor 
> > Signed-off-by: Konrad Rzeszutek Wilk 
> >
> > diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> > index 8971a26..8cce47b 100644
> > --- a/arch/x86/xen/setup.c
> > +++ b/arch/x86/xen/setup.c
> > @@ -27,6 +27,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include "mmu.h"
> >  #include "xen-ops.h"
> >  #include "vdso.h"
> >  
> > @@ -78,6 +79,9 @@ static void __init xen_add_extra_mem(u64 start, u64 size)
> >  
> >  	memblock_reserve(start, size);
> >  
> > +	if (xen_feature(XENFEAT_auto_translated_physmap))
> > +		return;
> > +
> >  	xen_max_p2m_pfn = PFN_DOWN(start + size);
> >  	for (pfn = PFN_DOWN(start); pfn < xen_max_p2m_pfn; pfn++) {
> >  		unsigned long mfn = pfn_to_mfn(pfn);
> > @@ -100,6 +104,7 @@ static unsigned long __init xen_do_chunk(unsigned long start,
> >  		.domid        = DOMID_SELF
> >  	};
> >  	unsigned long len = 0;
> > +	int xlated_phys = xen_feature(XENFEAT_auto_translated_physmap);
> >  	unsigned long pfn;
> >  	int ret;
> >  
> > @@ -113,7 +118,7 @@ static unsigned long __init xen_do_chunk(unsigned long start,
> >  				continue;
> >  			frame = mfn;
> >  		} else {
> > -			if (mfn != INVALID_P2M_ENTRY)
> > +			if (!xlated_phys && mfn != INVALID_P2M_ENTRY)
> >  				continue;
> >  			frame = pfn;
> >  		}
> 
> Shouldn't we add a "!xlated_phys &&" to the other case as well?

No. That is handled in xen_pvh_identity_map_chunk which
just does a xen_set_clr_mmio_pvh_pte call for the "released"
pages. But that is a bit of ... well, extra logic. I think
if we did this it would work and look much nicer:


diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 8cce47b..b451a77 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -114,9 +114,15 @@ static unsigned long __init xen_do_chunk(unsigned long start,
 
 		if (release) {
 			/* Make sure pfn exists to start with */
-			if (mfn == INVALID_P2M_ENTRY || mfn_to_pfn(mfn) != pfn)
+			if (mfn == INVALID_P2M_ENTRY || (!xlated_phys && (mfn_to_pfn(mfn) != pfn)))
 				continue;
 			frame = mfn;
+			/* The hypercall PHYSDEVOP_map_iomem to release memory has already
+			 * happend, so we just do a nop here. */
+			if (xlated_phys) {
+				len++;
+				continue;
+			}
 		} else {
 			if (!xlated_phys && mfn != INVALID_P2M_ENTRY)
 				continue;
@@ -219,15 +225,24 @@ static void __init xen_set_identity_and_release_chunk(
 {
 	unsigned long pfn;
 
+	/* For PVH, the pfns [0..MAX] are mapped to mfn's in the EPT/NPT. The mfns
+	 * are released as part of this 1:1 mapping hypercall back to the dom heap.
+	 * Also, we map the entire IO space, ie, beyond max_pfn_mapped.
+	 */
+	int xlated_phys = xen_feature(XENFEAT_auto_translated_physmap);
+
 	/*
 	 * If the PFNs are currently mapped, the VA mapping also needs
 	 * to be updated to be 1:1.
 	 */
-	for (pfn = start_pfn; pfn <= max_pfn_mapped && pfn < end_pfn; pfn++)
-		(void)HYPERVISOR_update_va_mapping(
-			(unsigned long)__va(pfn << PAGE_SHIFT),
-			mfn_pte(pfn, PAGE_KERNEL_IO), 0);
-
+	for (pfn = start_pfn; pfn <= max_pfn_mapped && pfn < end_pfn; pfn++) {
+		if (xlated_phys)
+			xen_set_clr_mmio_pvh_pte(pfn, pfn, 1 /* one pfn */, 1 /* add mapping */);
+		else
+			(void)HYPERVISOR_update_va_mapping(
+				(unsigned long)__va(pfn << PAGE_SHIFT),
+				mfn_pte(pfn, PAGE_KERNEL_IO), 0);
+	}
 	if (start_pfn < nr_pages)
 		*released += xen_release_chunk(
 			start_pfn, min(end_pfn, nr_pages));
@@ -235,27 +250,6 @@ static void __init xen_set_identity_and_release_chunk(
 	*identity += set_phys_range_identity(start_pfn, end_pfn);
 }
 
-/* For PVH, the pfns [0..MAX] are mapped to mfn's in the EPT/NPT. The mfns
- * are released as part of this 1:1 mapping hypercall back to the dom heap.
- * Also, we map the entire IO space, ie, beyond max_pfn_mapped.
- */
-static void __init xen_pvh_identity_map_chunk(unsigned long start_pfn,
-		unsigned long end_pfn, unsigned long *released,
-		unsigned long *identity, unsigned long max_pfn)
-{
-	unsigned long pfn;
-	int numpfns = 1, add_mapping = 1;
-
-	for (pfn = start_pfn; pfn < end_pfn; pfn++)
-		xen_set_clr_mmio_pvh_pte(pfn, pfn, numpfns, add_mapping);
-
-	if (start_pfn <= max_pfn) {
-		unsigned long end = min(max_pfn_mapped, end_pfn);
-		*released += end - start_pfn;
-	}
-	*identity += end_pfn - start_pfn;
-}
-
 static unsigned long __init xen_set_identity_and_release(
 	const struct e820entry *list, size_t map_size, unsigned long nr_pages)
 {
@@ -286,17 +280,10 @@ static unsigned long __init xen_set_identity_and_release(
 			if (entry->type == E820_RAM)
 				end_pfn = PFN_UP(entry->addr);
 
-			if (start_pfn < end_pfn) {
-				if (xlated_phys) {
-					xen_pvh_identity_map_chunk(start_pfn,
-						end_pfn, &released, &identity,
-						nr_pages);
-				} else {
-					xen_set_identity_and_release_chunk(
+			if (start_pfn < end_pfn)
+				xen_set_identity_and_release_chunk(
 						start_pfn, end_pfn, nr_pages,
 						&released, &identity);
-				}
-			}
 			start = end;
 		}
 	}


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 16:10:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 16:10:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQKa7-0007W5-Kp; Mon, 22 Oct 2012 16:10:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TQKa5-0007Vy-SP
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 16:10:22 +0000
Received: from [85.158.143.99:48222] by server-3.bemta-4.messagelabs.com id
	96/C2-03544-DEF65805; Mon, 22 Oct 2012 16:10:21 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-216.messagelabs.com!1350922211!27563278!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28055 invoked from network); 22 Oct 2012 16:10:20 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Oct 2012 16:10:20 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TQKZt-00042N-CW; Mon, 22 Oct 2012 16:10:09 +0000
Date: Mon, 22 Oct 2012 17:10:09 +0100
From: Tim Deegan 
To: Robert Phillips 
Message-ID: <20121022161009.GK12577@ocelot.phlegethon.org>
References: <1350411302-5470-1-git-send-email-robert.phillips@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1350411302-5470-1-git-send-email-robert.phillips@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: Robert Phillips ,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] Provide support for multiple frame buffers
	in Xen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 14:15 -0400 on 16 Oct (1350396902), Robert Phillips wrote:
> From: Robert Phillips 
> 
> Support is provided for both shadow and hardware assisted paging (HAP) modes.
> This code bookkeeps the set of video frame buffers (vram),
> detects when the guest has modified any of those buffers and, upon request,
> returns a bitmap of the modified pages.
> 
> This lets other software components re-paint the portions of the monitor (or monitors) that have changed.
> Each monitor has a frame buffer of some size at some position in guest physical memory.
> The set of frame buffers being tracked can change over time as monitors are plugged and unplugged.
> 
> Signed-Off-By: Robert Phillips 
> ---
>  xen/arch/x86/hvm/Makefile            |    3 +-
>  xen/arch/x86/hvm/dirty_vram.c        |  878 ++++++++++++++++++++++++++++++++++
>  xen/arch/x86/hvm/hvm.c               |    4 +-
>  xen/arch/x86/mm/hap/hap.c            |  140 +-----
>  xen/arch/x86/mm/paging.c             |  232 ++++-----
>  xen/arch/x86/mm/shadow/common.c      |  335 +++++++------
>  xen/arch/x86/mm/shadow/multi.c       |  169 +++----
>  xen/arch/x86/mm/shadow/multi.h       |    7 +-
>  xen/arch/x86/mm/shadow/types.h       |    1 +
>  xen/include/asm-x86/hap.h            |    4 -
>  xen/include/asm-x86/hvm/dirty_vram.h |  157 ++++++
>  xen/include/asm-x86/hvm/domain.h     |    2 +-
>  xen/include/asm-x86/paging.h         |   22 +-
>  xen/include/asm-x86/shadow.h         |    6 -
>  14 files changed, 1403 insertions(+), 557 deletions(-)

Wow.  That's a bunch of code! :)  Thanks for sending it, and for the
document too.

You don't say why it's useful to have multiple framebuffers -- I take it
this is useful for laptop environments?  Also, I'm a bit surprised not
to see some hypercall API changes to go with it.

Reading the PDF you sent, it looks like you've implemented log-dirty in
two new ways: by scanning the shadow PTEs and by scanning EPT entries.
But you also leave the old ways (trap-on-access and populate a bitmap) 
despite saying "The eliminated code was complex, buggy and unnecessary".
If the bitmap-tracking code is really buggy we need to know about it, as
that's what we use for live migration!  What's the problem with it?

I've had a brief skim of the code, and it looks rather over-complex for
what it does.  I'm not sure what the purpose of all these linked lists
of ranges is -- couldn't this just be done with a struct rangeset
describing which areas are being tracked?  Then since we already
maintain a sparse bitmap to hold the dirty log we don't need any other
metadata, or other ways of checking dirtiness.

Style nits: you're not consistently following the Xen coding style, in
particular the spaces around parentheses in 'if's and 'for's.  Also
you've got some code in new files that's clearly at least derived from
old code but just got your own name and copyright at the head of the
file.  Please carry the copyright over from old code when you move it.

Cheers,

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 16:10:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 16:10:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQKa7-0007W5-Kp; Mon, 22 Oct 2012 16:10:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TQKa5-0007Vy-SP
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 16:10:22 +0000
Received: from [85.158.143.99:48222] by server-3.bemta-4.messagelabs.com id
	96/C2-03544-DEF65805; Mon, 22 Oct 2012 16:10:21 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-216.messagelabs.com!1350922211!27563278!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28055 invoked from network); 22 Oct 2012 16:10:20 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Oct 2012 16:10:20 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TQKZt-00042N-CW; Mon, 22 Oct 2012 16:10:09 +0000
Date: Mon, 22 Oct 2012 17:10:09 +0100
From: Tim Deegan 
To: Robert Phillips 
Message-ID: <20121022161009.GK12577@ocelot.phlegethon.org>
References: <1350411302-5470-1-git-send-email-robert.phillips@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1350411302-5470-1-git-send-email-robert.phillips@citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: Robert Phillips ,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] Provide support for multiple frame buffers
	in Xen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 14:15 -0400 on 16 Oct (1350396902), Robert Phillips wrote:
> From: Robert Phillips 
> 
> Support is provided for both shadow and hardware assisted paging (HAP) modes.
> This code bookkeeps the set of video frame buffers (vram),
> detects when the guest has modified any of those buffers and, upon request,
> returns a bitmap of the modified pages.
> 
> This lets other software components re-paint the portions of the monitor (or monitors) that have changed.
> Each monitor has a frame buffer of some size at some position in guest physical memory.
> The set of frame buffers being tracked can change over time as monitors are plugged and unplugged.
> 
> Signed-Off-By: Robert Phillips 
> ---
>  xen/arch/x86/hvm/Makefile            |    3 +-
>  xen/arch/x86/hvm/dirty_vram.c        |  878 ++++++++++++++++++++++++++++++++++
>  xen/arch/x86/hvm/hvm.c               |    4 +-
>  xen/arch/x86/mm/hap/hap.c            |  140 +-----
>  xen/arch/x86/mm/paging.c             |  232 ++++-----
>  xen/arch/x86/mm/shadow/common.c      |  335 +++++++------
>  xen/arch/x86/mm/shadow/multi.c       |  169 +++----
>  xen/arch/x86/mm/shadow/multi.h       |    7 +-
>  xen/arch/x86/mm/shadow/types.h       |    1 +
>  xen/include/asm-x86/hap.h            |    4 -
>  xen/include/asm-x86/hvm/dirty_vram.h |  157 ++++++
>  xen/include/asm-x86/hvm/domain.h     |    2 +-
>  xen/include/asm-x86/paging.h         |   22 +-
>  xen/include/asm-x86/shadow.h         |    6 -
>  14 files changed, 1403 insertions(+), 557 deletions(-)

Wow.  That's a bunch of code! :)  Thanks for sending it, and for the
document too.

You don't say why it's useful to have multiple framebuffers -- I take it
this is useful for laptop environments?  Also, I'm a bit surprised not
to see some hypercall API changes to go with it.

Reading the PDF you sent, it looks like you've implemented log-dirty in
two new ways: by scanning the shadow PTEs and by scanning EPT entries.
But you also leave the old ways (trap-on-access and populate a bitmap) 
despite saying "The eliminated code was complex, buggy and unnecessary".
If the bitmap-tracking code is really buggy we need to know about it, as
that's what we use for live migration!  What's the problem with it?

I've had a brief skim of the code, and it looks rather over-complex for
what it does.  I'm not sure what the purpose of all these linked lists
of ranges is -- couldn't this just be done with a struct rangeset
describing which areas are being tracked?  Then since we already
maintain a sparse bitmap to hold the dirty log we don't need any other
metadata, or other ways of checking dirtiness.

Style nits: you're not consistently following the Xen coding style, in
particular the spaces around parentheses in 'if's and 'for's.  Also
you've got some code in new files that's clearly at least derived from
old code but just got your own name and copyright at the head of the
file.  Please carry the copyright over from old code when you move it.

Cheers,

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 16:13:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 16:13:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQKdF-0007lN-Dd; Mon, 22 Oct 2012 16:13:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TQKdD-0007lG-SJ
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 16:13:35 +0000
Received: from [85.158.137.99:13848] by server-16.bemta-3.messagelabs.com id
	26/16-00625-EA075805; Mon, 22 Oct 2012 16:13:34 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-217.messagelabs.com!1350922414!19421160!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7132 invoked from network); 22 Oct 2012 16:13:34 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-9.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Oct 2012 16:13:34 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TQKdB-000438-5r; Mon, 22 Oct 2012 16:13:33 +0000
Date: Mon, 22 Oct 2012 17:13:33 +0100
From: Tim Deegan 
To: Olaf Hering 
Message-ID: <20121022161333.GL12577@ocelot.phlegethon.org>
References: <8ebe7b80f02900d5a83e.1350655780@probook.site>
	<20121022152256.GH12577@ocelot.phlegethon.org>
	<20121022153333.GA27414@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20121022153333.GA27414@aepfle.de>
User-Agent: Mutt/1.4.2.1i
Cc: keir@xen.org, JBeulich@suse.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] hvm: handle PoD and grant pages in
	HVMOP_get_mem_type
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 17:33 +0200 on 22 Oct (1350927213), Olaf Hering wrote:
> On Mon, Oct 22, Tim Deegan wrote:
> 
> > At 16:09 +0200 on 19 Oct (1350662980), Olaf Hering wrote:
> > > hvm: handle PoD and grant pages in HVMOP_get_mem_type
> > > 
> > > During kexec in a ballooned PVonHVM guest the new kernel needs to check
> > > each pfn if its backed by a mfn to find ballooned pages. Currently all
> > > PoD and grant pages will appear as HVMMEM_mmio_dm, so the new kernel has
> > > to assume they are ballooned. This is wrong: PoD pages may turn into
> > > real RAM at runtime, grant pages are also RAM.
> > > 
> > > Signed-off-by: Olaf Hering 
> > 
> > Applied, thanks.
> 
> Would you backport this to 4.2 and 4.1?

Actually, I don't handle backports.  IIRC Jan owns 4.2-testing and Keir
4.1-testing; I've CC'd them both.

Cheers,

Tim.

> Without this change the guest will get a wrong picture.
> Too bad I did not consider this initially in 23298:26413986e6e0.
> 
> Olaf
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 16:13:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 16:13:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQKdF-0007lN-Dd; Mon, 22 Oct 2012 16:13:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TQKdD-0007lG-SJ
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 16:13:35 +0000
Received: from [85.158.137.99:13848] by server-16.bemta-3.messagelabs.com id
	26/16-00625-EA075805; Mon, 22 Oct 2012 16:13:34 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-217.messagelabs.com!1350922414!19421160!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7132 invoked from network); 22 Oct 2012 16:13:34 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-9.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Oct 2012 16:13:34 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TQKdB-000438-5r; Mon, 22 Oct 2012 16:13:33 +0000
Date: Mon, 22 Oct 2012 17:13:33 +0100
From: Tim Deegan 
To: Olaf Hering 
Message-ID: <20121022161333.GL12577@ocelot.phlegethon.org>
References: <8ebe7b80f02900d5a83e.1350655780@probook.site>
	<20121022152256.GH12577@ocelot.phlegethon.org>
	<20121022153333.GA27414@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20121022153333.GA27414@aepfle.de>
User-Agent: Mutt/1.4.2.1i
Cc: keir@xen.org, JBeulich@suse.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] hvm: handle PoD and grant pages in
	HVMOP_get_mem_type
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 17:33 +0200 on 22 Oct (1350927213), Olaf Hering wrote:
> On Mon, Oct 22, Tim Deegan wrote:
> 
> > At 16:09 +0200 on 19 Oct (1350662980), Olaf Hering wrote:
> > > hvm: handle PoD and grant pages in HVMOP_get_mem_type
> > > 
> > > During kexec in a ballooned PVonHVM guest the new kernel needs to check
> > > each pfn if its backed by a mfn to find ballooned pages. Currently all
> > > PoD and grant pages will appear as HVMMEM_mmio_dm, so the new kernel has
> > > to assume they are ballooned. This is wrong: PoD pages may turn into
> > > real RAM at runtime, grant pages are also RAM.
> > > 
> > > Signed-off-by: Olaf Hering 
> > 
> > Applied, thanks.
> 
> Would you backport this to 4.2 and 4.1?

Actually, I don't handle backports.  IIRC Jan owns 4.2-testing and Keir
4.1-testing; I've CC'd them both.

Cheers,

Tim.

> Without this change the guest will get a wrong picture.
> Too bad I did not consider this initially in 23298:26413986e6e0.
> 
> Olaf
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 16:17:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 16:17:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQKgk-0007wc-2p; Mon, 22 Oct 2012 16:17:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQKgj-0007wV-6S
	for xen-devel@lists.xensource.com; Mon, 22 Oct 2012 16:17:13 +0000
Received: from [85.158.137.99:35912] by server-3.bemta-3.messagelabs.com id
	9A/53-09368-88175805; Mon, 22 Oct 2012 16:17:12 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1350922629!17776919!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODE4Nzcz\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23979 invoked from network); 22 Oct 2012 16:17:11 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Oct 2012 16:17:11 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9MGH4Z9005896
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 22 Oct 2012 16:17:05 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9MGH4oN004419
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 22 Oct 2012 16:17:04 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9MGH461008824; Mon, 22 Oct 2012 11:17:04 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 22 Oct 2012 09:17:03 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 0C951402E8; Mon, 22 Oct 2012 12:04:56 -0400 (EDT)
Date: Mon, 22 Oct 2012 12:04:56 -0400
From: Konrad Rzeszutek Wilk 
To: Stefano Stabellini 
Message-ID: <20121022160455.GC25200@phenom.dumpdata.com>
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
	<1350695882-12820-6-git-send-email-konrad.wilk@oracle.com>
	
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Ian Campbell 
Subject: Re: [Xen-devel] [PATCH 5/6] xen/pvh: balloon and grant changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 22, 2012 at 02:25:43PM +0100, Stefano Stabellini wrote:
> On Sat, 20 Oct 2012, Konrad Rzeszutek Wilk wrote:
> > From: Mukesh Rathor 
> > 
> > For balloon changes we skip setting of local P2M as it's updated
> > in Xen. For grant, the shared grant frame is the pfn and not mfn,
> > hence its mapped via the same code path as HVM.
> > 
> > Signed-off-by: Mukesh Rathor 
> > Signed-off-by: Konrad Rzeszutek Wilk 
> > ---
> >  drivers/xen/balloon.c     |   15 +++++++++------
> >  drivers/xen/gntdev.c      |    3 ++-
> >  drivers/xen/grant-table.c |   26 ++++++++++++++++++++++----
> >  3 files changed, 33 insertions(+), 11 deletions(-)
> > 
> > diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> > index 31ab82f..c825b63 100644
> > --- a/drivers/xen/balloon.c
> > +++ b/drivers/xen/balloon.c
> > @@ -361,7 +361,9 @@ static enum bp_state increase_reservation(unsigned long nr_pages)
> >  		set_phys_to_machine(pfn, frame_list[i]);
> >  
> >  		/* Link back into the page tables if not highmem. */
> > -		if (xen_pv_domain() && !PageHighMem(page)) {
> > +		if (xen_pv_domain() && !PageHighMem(page) &&
> > +		    !xen_feature(XENFEAT_auto_translated_physmap)) {

This could be done as:

	if ((xen_pv_domain() && !PageHighMem(page) && !xen_feature(XENFEAT_auto_translated_physmap))

Just to make it more easier to read.

> > +
> >  			int ret;
> >  			ret = HYPERVISOR_update_va_mapping(
> >  				(unsigned long)__va(pfn << PAGE_SHIFT),
> > @@ -418,12 +420,13 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
> >  		scrub_page(page);
> >  
> >  		if (xen_pv_domain() && !PageHighMem(page)) {
> > -			ret = HYPERVISOR_update_va_mapping(
> > -				(unsigned long)__va(pfn << PAGE_SHIFT),
> > -				__pte_ma(0), 0);
> > -			BUG_ON(ret);
> > +			if (!xen_feature(XENFEAT_auto_translated_physmap)) {
> > +				ret = HYPERVISOR_update_va_mapping(
> > +					(unsigned long)__va(pfn << PAGE_SHIFT),
> > +					__pte_ma(0), 0);
> > +				BUG_ON(ret);
> > +			}
> >  		}
> 
> this change, unlike the one before, actually makes things different for
> traditional pv domains in case PageHighMem(page).

How? He is not altering the !PageHighMem check. Just adding a check
before the hypercall to render it nop on PVH.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 16:17:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 16:17:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQKgk-0007wc-2p; Mon, 22 Oct 2012 16:17:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQKgj-0007wV-6S
	for xen-devel@lists.xensource.com; Mon, 22 Oct 2012 16:17:13 +0000
Received: from [85.158.137.99:35912] by server-3.bemta-3.messagelabs.com id
	9A/53-09368-88175805; Mon, 22 Oct 2012 16:17:12 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1350922629!17776919!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODE4Nzcz\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23979 invoked from network); 22 Oct 2012 16:17:11 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Oct 2012 16:17:11 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9MGH4Z9005896
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 22 Oct 2012 16:17:05 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9MGH4oN004419
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 22 Oct 2012 16:17:04 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9MGH461008824; Mon, 22 Oct 2012 11:17:04 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 22 Oct 2012 09:17:03 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 0C951402E8; Mon, 22 Oct 2012 12:04:56 -0400 (EDT)
Date: Mon, 22 Oct 2012 12:04:56 -0400
From: Konrad Rzeszutek Wilk 
To: Stefano Stabellini 
Message-ID: <20121022160455.GC25200@phenom.dumpdata.com>
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
	<1350695882-12820-6-git-send-email-konrad.wilk@oracle.com>
	
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Ian Campbell 
Subject: Re: [Xen-devel] [PATCH 5/6] xen/pvh: balloon and grant changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 22, 2012 at 02:25:43PM +0100, Stefano Stabellini wrote:
> On Sat, 20 Oct 2012, Konrad Rzeszutek Wilk wrote:
> > From: Mukesh Rathor 
> > 
> > For balloon changes we skip setting of local P2M as it's updated
> > in Xen. For grant, the shared grant frame is the pfn and not mfn,
> > hence its mapped via the same code path as HVM.
> > 
> > Signed-off-by: Mukesh Rathor 
> > Signed-off-by: Konrad Rzeszutek Wilk 
> > ---
> >  drivers/xen/balloon.c     |   15 +++++++++------
> >  drivers/xen/gntdev.c      |    3 ++-
> >  drivers/xen/grant-table.c |   26 ++++++++++++++++++++++----
> >  3 files changed, 33 insertions(+), 11 deletions(-)
> > 
> > diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> > index 31ab82f..c825b63 100644
> > --- a/drivers/xen/balloon.c
> > +++ b/drivers/xen/balloon.c
> > @@ -361,7 +361,9 @@ static enum bp_state increase_reservation(unsigned long nr_pages)
> >  		set_phys_to_machine(pfn, frame_list[i]);
> >  
> >  		/* Link back into the page tables if not highmem. */
> > -		if (xen_pv_domain() && !PageHighMem(page)) {
> > +		if (xen_pv_domain() && !PageHighMem(page) &&
> > +		    !xen_feature(XENFEAT_auto_translated_physmap)) {

This could be done as:

	if ((xen_pv_domain() && !PageHighMem(page) && !xen_feature(XENFEAT_auto_translated_physmap))

Just to make it more easier to read.

> > +
> >  			int ret;
> >  			ret = HYPERVISOR_update_va_mapping(
> >  				(unsigned long)__va(pfn << PAGE_SHIFT),
> > @@ -418,12 +420,13 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
> >  		scrub_page(page);
> >  
> >  		if (xen_pv_domain() && !PageHighMem(page)) {
> > -			ret = HYPERVISOR_update_va_mapping(
> > -				(unsigned long)__va(pfn << PAGE_SHIFT),
> > -				__pte_ma(0), 0);
> > -			BUG_ON(ret);
> > +			if (!xen_feature(XENFEAT_auto_translated_physmap)) {
> > +				ret = HYPERVISOR_update_va_mapping(
> > +					(unsigned long)__va(pfn << PAGE_SHIFT),
> > +					__pte_ma(0), 0);
> > +				BUG_ON(ret);
> > +			}
> >  		}
> 
> this change, unlike the one before, actually makes things different for
> traditional pv domains in case PageHighMem(page).

How? He is not altering the !PageHighMem check. Just adding a check
before the hypercall to render it nop on PVH.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 16:41:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 16:41:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQL3b-0008Cw-GM; Mon, 22 Oct 2012 16:40:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQL3a-0008Cg-L8
	for xen-devel@lists.xensource.com; Mon, 22 Oct 2012 16:40:50 +0000
Received: from [85.158.138.51:27263] by server-8.bemta-3.messagelabs.com id
	50/1B-10525-01775805; Mon, 22 Oct 2012 16:40:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1350924047!35328445!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUxNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14404 invoked from network); 22 Oct 2012 16:40:47 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 16:40:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,630,1344211200"; d="scan'208";a="15315856"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Oct 2012 16:40:46 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Mon, 22 Oct 2012 17:40:46 +0100
Date: Mon, 22 Oct 2012 17:40:19 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Konrad Rzeszutek Wilk 
In-Reply-To: <20121022160455.GC25200@phenom.dumpdata.com>
Message-ID: 
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
	<1350695882-12820-6-git-send-email-konrad.wilk@oracle.com>
	
	<20121022160455.GC25200@phenom.dumpdata.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Ian Campbell ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 5/6] xen/pvh: balloon and grant changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 22 Oct 2012, Konrad Rzeszutek Wilk wrote:
> > > +
> > >  			int ret;
> > >  			ret = HYPERVISOR_update_va_mapping(
> > >  				(unsigned long)__va(pfn << PAGE_SHIFT),
> > > @@ -418,12 +420,13 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
> > >  		scrub_page(page);
> > >  
> > >  		if (xen_pv_domain() && !PageHighMem(page)) {
> > > -			ret = HYPERVISOR_update_va_mapping(
> > > -				(unsigned long)__va(pfn << PAGE_SHIFT),
> > > -				__pte_ma(0), 0);
> > > -			BUG_ON(ret);
> > > +			if (!xen_feature(XENFEAT_auto_translated_physmap)) {
> > > +				ret = HYPERVISOR_update_va_mapping(
> > > +					(unsigned long)__va(pfn << PAGE_SHIFT),
> > > +					__pte_ma(0), 0);
> > > +				BUG_ON(ret);
> > > +			}
> > >  		}
> > 
> > this change, unlike the one before, actually makes things different for
> > traditional pv domains in case PageHighMem(page).
> 
> How? He is not altering the !PageHighMem check. Just adding a check
> before the hypercall to render it nop on PVH.

sorry, you are right, I need new glasses

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 16:41:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 16:41:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQL3b-0008Cw-GM; Mon, 22 Oct 2012 16:40:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQL3a-0008Cg-L8
	for xen-devel@lists.xensource.com; Mon, 22 Oct 2012 16:40:50 +0000
Received: from [85.158.138.51:27263] by server-8.bemta-3.messagelabs.com id
	50/1B-10525-01775805; Mon, 22 Oct 2012 16:40:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1350924047!35328445!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUxNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14404 invoked from network); 22 Oct 2012 16:40:47 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 16:40:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,630,1344211200"; d="scan'208";a="15315856"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Oct 2012 16:40:46 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Mon, 22 Oct 2012 17:40:46 +0100
Date: Mon, 22 Oct 2012 17:40:19 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Konrad Rzeszutek Wilk 
In-Reply-To: <20121022160455.GC25200@phenom.dumpdata.com>
Message-ID: 
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
	<1350695882-12820-6-git-send-email-konrad.wilk@oracle.com>
	
	<20121022160455.GC25200@phenom.dumpdata.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Ian Campbell ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 5/6] xen/pvh: balloon and grant changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 22 Oct 2012, Konrad Rzeszutek Wilk wrote:
> > > +
> > >  			int ret;
> > >  			ret = HYPERVISOR_update_va_mapping(
> > >  				(unsigned long)__va(pfn << PAGE_SHIFT),
> > > @@ -418,12 +420,13 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
> > >  		scrub_page(page);
> > >  
> > >  		if (xen_pv_domain() && !PageHighMem(page)) {
> > > -			ret = HYPERVISOR_update_va_mapping(
> > > -				(unsigned long)__va(pfn << PAGE_SHIFT),
> > > -				__pte_ma(0), 0);
> > > -			BUG_ON(ret);
> > > +			if (!xen_feature(XENFEAT_auto_translated_physmap)) {
> > > +				ret = HYPERVISOR_update_va_mapping(
> > > +					(unsigned long)__va(pfn << PAGE_SHIFT),
> > > +					__pte_ma(0), 0);
> > > +				BUG_ON(ret);
> > > +			}
> > >  		}
> > 
> > this change, unlike the one before, actually makes things different for
> > traditional pv domains in case PageHighMem(page).
> 
> How? He is not altering the !PageHighMem check. Just adding a check
> before the hypercall to render it nop on PVH.

sorry, you are right, I need new glasses

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 16:55:33 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 16:55:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQLHN-0008OQ-8r; Mon, 22 Oct 2012 16:55:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQLHL-0008OA-Am; Mon, 22 Oct 2012 16:55:03 +0000
Received: from [85.158.137.99:33662] by server-13.bemta-3.messagelabs.com id
	DF/C5-26794-66A75805; Mon, 22 Oct 2012 16:55:02 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1350924900!19451238!1
X-Originating-IP: [209.85.213.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7898 invoked from network); 22 Oct 2012 16:55:01 -0000
Received: from mail-ye0-f173.google.com (HELO mail-ye0-f173.google.com)
	(209.85.213.173)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 16:55:01 -0000
Received: by mail-ye0-f173.google.com with SMTP id l3so331419yen.32
	for ; Mon, 22 Oct 2012 09:55:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:to
	:subject:content-type:content-transfer-encoding;
	bh=Pjfkbhrb7HsZ6pKVMzvxPAsRa8y0gOdwRw07KHDIUVg=;
	b=pmHFB3UQfIUMP85wDtfli1QwNozmYbzyI1MKJ6hjWe4xA4bn93/WioBpNUy+qVqj64
	d9cVufj+xIVa8mDQPtYb8Lu9U17mXf4Vka0GX8Mbo5ivC1KygFXvnkCyYEErrlW0iA2p
	pPk4r4ZgZNGtPFMZ1zRIQllIn0peGshTNSyddO8oda0P3gocQj5OtyN9fFXS34V/iiNN
	r3/qDrF2dbzZibb12twiNSV2h0ytpnYIbPDaRJ3CuoF/7XeAWUx1wK63Un/esyJOkMEa
	etCKvBZLo0ZjOBdqecaqJ3OuISjhoDoSQBj7/nB1PKxAIB4ZL8XZCyPf8TzDOKVUwrtp
	Oq2g==
Received: by 10.236.92.6 with SMTP id i6mr9085807yhf.40.1350924900120;
	Mon, 22 Oct 2012 09:55:00 -0700 (PDT)
Received: from [172.16.25.10] (firewall.ctxuk.citrix.com. [62.200.22.2])
	by mx.google.com with ESMTPS id a7sm9406189yhe.14.2012.10.22.09.54.57
	(version=SSLv3 cipher=OTHER); Mon, 22 Oct 2012 09:54:59 -0700 (PDT)
Message-ID: <50857A5F.1090800@xen.org>
Date: Mon, 22 Oct 2012 17:54:55 +0100
From: Lars Kurth 
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" , 
	"xen-api@lists.xen.org" , xen-users@lists.xen.org
Subject: [Xen-devel] Docs Day next week - need somebody to facilitate or
	move/cancel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: lars.kurth@xen.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi everybody,

we have another Xen Docs day coming up next Monday. I will be at a 
conference next week (and likely won't be ab le to join in the morning) 
and am looking for somebody who can take up the role reminding people
a) on ##xen, #xentest, #xen-api that the docs day is happening
b) on the mailing lists that the docs day is happening
c) can point people to items on the TODO list

Any volunteers, please reply privately.

Best Regards
Lars

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 16:55:33 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 16:55:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQLHN-0008OQ-8r; Mon, 22 Oct 2012 16:55:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQLHL-0008OA-Am; Mon, 22 Oct 2012 16:55:03 +0000
Received: from [85.158.137.99:33662] by server-13.bemta-3.messagelabs.com id
	DF/C5-26794-66A75805; Mon, 22 Oct 2012 16:55:02 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1350924900!19451238!1
X-Originating-IP: [209.85.213.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7898 invoked from network); 22 Oct 2012 16:55:01 -0000
Received: from mail-ye0-f173.google.com (HELO mail-ye0-f173.google.com)
	(209.85.213.173)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 16:55:01 -0000
Received: by mail-ye0-f173.google.com with SMTP id l3so331419yen.32
	for ; Mon, 22 Oct 2012 09:55:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:to
	:subject:content-type:content-transfer-encoding;
	bh=Pjfkbhrb7HsZ6pKVMzvxPAsRa8y0gOdwRw07KHDIUVg=;
	b=pmHFB3UQfIUMP85wDtfli1QwNozmYbzyI1MKJ6hjWe4xA4bn93/WioBpNUy+qVqj64
	d9cVufj+xIVa8mDQPtYb8Lu9U17mXf4Vka0GX8Mbo5ivC1KygFXvnkCyYEErrlW0iA2p
	pPk4r4ZgZNGtPFMZ1zRIQllIn0peGshTNSyddO8oda0P3gocQj5OtyN9fFXS34V/iiNN
	r3/qDrF2dbzZibb12twiNSV2h0ytpnYIbPDaRJ3CuoF/7XeAWUx1wK63Un/esyJOkMEa
	etCKvBZLo0ZjOBdqecaqJ3OuISjhoDoSQBj7/nB1PKxAIB4ZL8XZCyPf8TzDOKVUwrtp
	Oq2g==
Received: by 10.236.92.6 with SMTP id i6mr9085807yhf.40.1350924900120;
	Mon, 22 Oct 2012 09:55:00 -0700 (PDT)
Received: from [172.16.25.10] (firewall.ctxuk.citrix.com. [62.200.22.2])
	by mx.google.com with ESMTPS id a7sm9406189yhe.14.2012.10.22.09.54.57
	(version=SSLv3 cipher=OTHER); Mon, 22 Oct 2012 09:54:59 -0700 (PDT)
Message-ID: <50857A5F.1090800@xen.org>
Date: Mon, 22 Oct 2012 17:54:55 +0100
From: Lars Kurth 
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" , 
	"xen-api@lists.xen.org" , xen-users@lists.xen.org
Subject: [Xen-devel] Docs Day next week - need somebody to facilitate or
	move/cancel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: lars.kurth@xen.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi everybody,

we have another Xen Docs day coming up next Monday. I will be at a 
conference next week (and likely won't be ab le to join in the morning) 
and am looking for somebody who can take up the role reminding people
a) on ##xen, #xentest, #xen-api that the docs day is happening
b) on the mailing lists that the docs day is happening
c) can point people to items on the TODO list

Any volunteers, please reply privately.

Best Regards
Lars

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 17:46:23 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 17:46:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQM4X-0000tV-LE; Mon, 22 Oct 2012 17:45:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQM4V-0000tQ-S5
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 17:45:52 +0000
Received: from [85.158.143.99:44057] by server-1.bemta-4.messagelabs.com id
	F2/1B-19134-F4685805; Mon, 22 Oct 2012 17:45:51 +0000
X-Env-Sender: robert.phillips@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1350927949!25318505!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzgwOTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12808 invoked from network); 22 Oct 2012 17:45:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 17:45:50 -0000
X-IronPort-AV: E=Sophos;i="4.80,631,1344211200"; d="scan'208";a="42049286"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Oct 2012 17:45:48 +0000
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.210]) by
	FTLPMAILMX02.citrite.net ([10.13.107.66]) with mapi; Mon, 22 Oct 2012
	13:45:48 -0400
From: Robert Phillips 
To: "Tim (Xen.org)" 
Date: Mon, 22 Oct 2012 13:45:47 -0400
Thread-Topic: [Xen-devel] [PATCH] Provide support for multiple frame buffers
	in Xen.
Thread-Index: Ac2wb7eDSb0IfdX+ReOhythmnejcygAAV/mA
Message-ID: <048EAD622912254A9DEA24C1734613C18C86D22EDE@FTLPMAILBOX02.citrite.net>
References: <1350411302-5470-1-git-send-email-robert.phillips@citrix.com>
	<20121022161009.GK12577@ocelot.phlegethon.org>
In-Reply-To: <20121022161009.GK12577@ocelot.phlegethon.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] Provide support for multiple frame buffers
 in Xen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Tim,

Thank you for taking the time (and I expect it was a considerable time) to review this patch.

And thanks for pointing out the coding style nits.  I'll re-submit the patch when the dust settles regarding its contents.


re " You don't say why it's useful to have multiple framebuffers ..." 
Yes, in a laptop environment there can be multiple monitors, each with its own frame buffer, and the monitors can be plugged/unplugged dynamically.
So the number of monitors and the location and size of their framebuffers is dynamic.


re: The " complex, buggy and unnecessary " code eliminated by this patch.
I was refering to the function paging_log_dirty_range().

I believe the bug was toward the end of the function where it used to call  clear_page(l1)
The function copies bits from l1 into a temporary bitmap, then copies them from there to the user-provided dirty_bitmap.
When it's done, it clears the page at l1.
But two framebuffers might cohabit that page, not overlapping but at distinction areas within it.
Reading the dirtiness for one frame buffer and then clearing the whole page wipes out information "owned" by the other frame buffer.
This bug would not show up if there is only one frame buffer so your live migration code is ok.

The old code wasn't really necessary because there is an easier way of telling if some page is dirty.
Yes, one can look at the dirty bit as the old code did.
Or one can check if the page's type was switched to p2m_ram_rw, which is what the new function hap_clean_vram_tracking_range() does.

In terms of complexity, the new hap_clean_vram_tracking_range() is much more simple than the old paging_log_dirty_range().  


re: " implemented log-dirty in two new ways"

The HAP code path scans EPT entries.  Obviously the shadow code does not.
The shadow code does substantial bookkeeping, which I'll get to in a minute, which the HAP path does not.
Although HAP does bookkeep the set of ranges, all the linked-list stuff isn't used or allocated.

In shadow mode the new code makes a clean separation between determining the interesting set of PTEs and examining those PTEs looking for dirty bits.

When a new range is detected, the code *does* scan all PTEs looking for ones that map into the new range but (unlike the old code) that is a one-time event.
>From then on the range's pages are kept by "dead reckoning", i.e. hooking all changes to PTEs to see if they pertain to the range.
Unfortunately when a process terminates it doesn't tear down its page tables;  it just abandons them.
So a range can get left pointing to a PTE that is no longer in a page table page.
But, in due time, the shadow code recognizes this and removes them.  The new code hooks that too, and updates its ranges accordingly.
When a no-longer-in-use range's pages have all been recycled, the range deletes itself.

So the overhead of  bookkeeping a range's set of interesting PTEs is low.

And when it's time to look for dirty bits, we know precisely which PTEs to look at.
The old code used to scan all page tables periodically and we would see a performance hit with precisely that periodicity.

One unfortunate bit of complexity relates to the fact that several PTEs can map to the same guest physical page.
We have to bookkeep them all, so each PTEs that maps to a guest physical page must be represented by its own dv_paddr_link, 
and, for the set that relate to the same guest page, they are all linked together.
The head of the linked list is the entry in the range's pl_tab array that corresponds to that guest physical page.


re: " since we already maintain a sparse bitmap to hold the dirty log"
I don't believe the dirty log is maintained except when page_mode is set for PG_log_dirty.
That mode exists for live migrate and the discipline for entering/leaving it is quite different than the finer granularity needed for dirty vram.

Thanks
-- rsp
Robert Phillips 
Principal Software Engineer,  XenClient - Citrix - Westford


-----Original Message-----
From: Tim Deegan [mailto:tim@xen.org] 
Sent: Monday, October 22, 2012 12:10 PM
To: Robert Phillips
Cc: xen-devel@lists.xen.org; Robert Phillips
Subject: Re: [Xen-devel] [PATCH] Provide support for multiple frame buffers in Xen.

At 14:15 -0400 on 16 Oct (1350396902), Robert Phillips wrote:
> From: Robert Phillips 
> 
> Support is provided for both shadow and hardware assisted paging (HAP) modes.
> This code bookkeeps the set of video frame buffers (vram),
> detects when the guest has modified any of those buffers and, upon request,
> returns a bitmap of the modified pages.
> 
> This lets other software components re-paint the portions of the monitor (or monitors) that have changed.
> Each monitor has a frame buffer of some size at some position in guest physical memory.
> The set of frame buffers being tracked can change over time as monitors are plugged and unplugged.
> 
> Signed-Off-By: Robert Phillips 
> ---
>  xen/arch/x86/hvm/Makefile            |    3 +-
>  xen/arch/x86/hvm/dirty_vram.c        |  878 ++++++++++++++++++++++++++++++++++
>  xen/arch/x86/hvm/hvm.c               |    4 +-
>  xen/arch/x86/mm/hap/hap.c            |  140 +-----
>  xen/arch/x86/mm/paging.c             |  232 ++++-----
>  xen/arch/x86/mm/shadow/common.c      |  335 +++++++------
>  xen/arch/x86/mm/shadow/multi.c       |  169 +++----
>  xen/arch/x86/mm/shadow/multi.h       |    7 +-
>  xen/arch/x86/mm/shadow/types.h       |    1 +
>  xen/include/asm-x86/hap.h            |    4 -
>  xen/include/asm-x86/hvm/dirty_vram.h |  157 ++++++
>  xen/include/asm-x86/hvm/domain.h     |    2 +-
>  xen/include/asm-x86/paging.h         |   22 +-
>  xen/include/asm-x86/shadow.h         |    6 -
>  14 files changed, 1403 insertions(+), 557 deletions(-)

Wow.  That's a bunch of code! :)  Thanks for sending it, and for the
document too.

You don't say why it's useful to have multiple framebuffers -- I take it
this is useful for laptop environments?  Also, I'm a bit surprised not
to see some hypercall API changes to go with it.

Reading the PDF you sent, it looks like you've implemented log-dirty in
two new ways: by scanning the shadow PTEs and by scanning EPT entries.
But you also leave the old ways (trap-on-access and populate a bitmap) 
despite saying "The eliminated code was complex, buggy and unnecessary".
If the bitmap-tracking code is really buggy we need to know about it, as
that's what we use for live migration!  What's the problem with it?

I've had a brief skim of the code, and it looks rather over-complex for
what it does.  I'm not sure what the purpose of all these linked lists
of ranges is -- couldn't this just be done with a struct rangeset
describing which areas are being tracked?  Then since we already
maintain a sparse bitmap to hold the dirty log we don't need any other
metadata, or other ways of checking dirtiness.

Style nits: you're not consistently following the Xen coding style, in
particular the spaces around parentheses in 'if's and 'for's.  Also
you've got some code in new files that's clearly at least derived from
old code but just got your own name and copyright at the head of the
file.  Please carry the copyright over from old code when you move it.

Cheers,

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 17:46:23 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 17:46:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQM4X-0000tV-LE; Mon, 22 Oct 2012 17:45:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQM4V-0000tQ-S5
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 17:45:52 +0000
Received: from [85.158.143.99:44057] by server-1.bemta-4.messagelabs.com id
	F2/1B-19134-F4685805; Mon, 22 Oct 2012 17:45:51 +0000
X-Env-Sender: robert.phillips@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1350927949!25318505!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzgwOTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12808 invoked from network); 22 Oct 2012 17:45:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 17:45:50 -0000
X-IronPort-AV: E=Sophos;i="4.80,631,1344211200"; d="scan'208";a="42049286"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Oct 2012 17:45:48 +0000
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.210]) by
	FTLPMAILMX02.citrite.net ([10.13.107.66]) with mapi; Mon, 22 Oct 2012
	13:45:48 -0400
From: Robert Phillips 
To: "Tim (Xen.org)" 
Date: Mon, 22 Oct 2012 13:45:47 -0400
Thread-Topic: [Xen-devel] [PATCH] Provide support for multiple frame buffers
	in Xen.
Thread-Index: Ac2wb7eDSb0IfdX+ReOhythmnejcygAAV/mA
Message-ID: <048EAD622912254A9DEA24C1734613C18C86D22EDE@FTLPMAILBOX02.citrite.net>
References: <1350411302-5470-1-git-send-email-robert.phillips@citrix.com>
	<20121022161009.GK12577@ocelot.phlegethon.org>
In-Reply-To: <20121022161009.GK12577@ocelot.phlegethon.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] Provide support for multiple frame buffers
 in Xen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Tim,

Thank you for taking the time (and I expect it was a considerable time) to review this patch.

And thanks for pointing out the coding style nits.  I'll re-submit the patch when the dust settles regarding its contents.


re " You don't say why it's useful to have multiple framebuffers ..." 
Yes, in a laptop environment there can be multiple monitors, each with its own frame buffer, and the monitors can be plugged/unplugged dynamically.
So the number of monitors and the location and size of their framebuffers is dynamic.


re: The " complex, buggy and unnecessary " code eliminated by this patch.
I was refering to the function paging_log_dirty_range().

I believe the bug was toward the end of the function where it used to call  clear_page(l1)
The function copies bits from l1 into a temporary bitmap, then copies them from there to the user-provided dirty_bitmap.
When it's done, it clears the page at l1.
But two framebuffers might cohabit that page, not overlapping but at distinction areas within it.
Reading the dirtiness for one frame buffer and then clearing the whole page wipes out information "owned" by the other frame buffer.
This bug would not show up if there is only one frame buffer so your live migration code is ok.

The old code wasn't really necessary because there is an easier way of telling if some page is dirty.
Yes, one can look at the dirty bit as the old code did.
Or one can check if the page's type was switched to p2m_ram_rw, which is what the new function hap_clean_vram_tracking_range() does.

In terms of complexity, the new hap_clean_vram_tracking_range() is much more simple than the old paging_log_dirty_range().  


re: " implemented log-dirty in two new ways"

The HAP code path scans EPT entries.  Obviously the shadow code does not.
The shadow code does substantial bookkeeping, which I'll get to in a minute, which the HAP path does not.
Although HAP does bookkeep the set of ranges, all the linked-list stuff isn't used or allocated.

In shadow mode the new code makes a clean separation between determining the interesting set of PTEs and examining those PTEs looking for dirty bits.

When a new range is detected, the code *does* scan all PTEs looking for ones that map into the new range but (unlike the old code) that is a one-time event.
>From then on the range's pages are kept by "dead reckoning", i.e. hooking all changes to PTEs to see if they pertain to the range.
Unfortunately when a process terminates it doesn't tear down its page tables;  it just abandons them.
So a range can get left pointing to a PTE that is no longer in a page table page.
But, in due time, the shadow code recognizes this and removes them.  The new code hooks that too, and updates its ranges accordingly.
When a no-longer-in-use range's pages have all been recycled, the range deletes itself.

So the overhead of  bookkeeping a range's set of interesting PTEs is low.

And when it's time to look for dirty bits, we know precisely which PTEs to look at.
The old code used to scan all page tables periodically and we would see a performance hit with precisely that periodicity.

One unfortunate bit of complexity relates to the fact that several PTEs can map to the same guest physical page.
We have to bookkeep them all, so each PTEs that maps to a guest physical page must be represented by its own dv_paddr_link, 
and, for the set that relate to the same guest page, they are all linked together.
The head of the linked list is the entry in the range's pl_tab array that corresponds to that guest physical page.


re: " since we already maintain a sparse bitmap to hold the dirty log"
I don't believe the dirty log is maintained except when page_mode is set for PG_log_dirty.
That mode exists for live migrate and the discipline for entering/leaving it is quite different than the finer granularity needed for dirty vram.

Thanks
-- rsp
Robert Phillips 
Principal Software Engineer,  XenClient - Citrix - Westford


-----Original Message-----
From: Tim Deegan [mailto:tim@xen.org] 
Sent: Monday, October 22, 2012 12:10 PM
To: Robert Phillips
Cc: xen-devel@lists.xen.org; Robert Phillips
Subject: Re: [Xen-devel] [PATCH] Provide support for multiple frame buffers in Xen.

At 14:15 -0400 on 16 Oct (1350396902), Robert Phillips wrote:
> From: Robert Phillips 
> 
> Support is provided for both shadow and hardware assisted paging (HAP) modes.
> This code bookkeeps the set of video frame buffers (vram),
> detects when the guest has modified any of those buffers and, upon request,
> returns a bitmap of the modified pages.
> 
> This lets other software components re-paint the portions of the monitor (or monitors) that have changed.
> Each monitor has a frame buffer of some size at some position in guest physical memory.
> The set of frame buffers being tracked can change over time as monitors are plugged and unplugged.
> 
> Signed-Off-By: Robert Phillips 
> ---
>  xen/arch/x86/hvm/Makefile            |    3 +-
>  xen/arch/x86/hvm/dirty_vram.c        |  878 ++++++++++++++++++++++++++++++++++
>  xen/arch/x86/hvm/hvm.c               |    4 +-
>  xen/arch/x86/mm/hap/hap.c            |  140 +-----
>  xen/arch/x86/mm/paging.c             |  232 ++++-----
>  xen/arch/x86/mm/shadow/common.c      |  335 +++++++------
>  xen/arch/x86/mm/shadow/multi.c       |  169 +++----
>  xen/arch/x86/mm/shadow/multi.h       |    7 +-
>  xen/arch/x86/mm/shadow/types.h       |    1 +
>  xen/include/asm-x86/hap.h            |    4 -
>  xen/include/asm-x86/hvm/dirty_vram.h |  157 ++++++
>  xen/include/asm-x86/hvm/domain.h     |    2 +-
>  xen/include/asm-x86/paging.h         |   22 +-
>  xen/include/asm-x86/shadow.h         |    6 -
>  14 files changed, 1403 insertions(+), 557 deletions(-)

Wow.  That's a bunch of code! :)  Thanks for sending it, and for the
document too.

You don't say why it's useful to have multiple framebuffers -- I take it
this is useful for laptop environments?  Also, I'm a bit surprised not
to see some hypercall API changes to go with it.

Reading the PDF you sent, it looks like you've implemented log-dirty in
two new ways: by scanning the shadow PTEs and by scanning EPT entries.
But you also leave the old ways (trap-on-access and populate a bitmap) 
despite saying "The eliminated code was complex, buggy and unnecessary".
If the bitmap-tracking code is really buggy we need to know about it, as
that's what we use for live migration!  What's the problem with it?

I've had a brief skim of the code, and it looks rather over-complex for
what it does.  I'm not sure what the purpose of all these linked lists
of ranges is -- couldn't this just be done with a struct rangeset
describing which areas are being tracked?  Then since we already
maintain a sparse bitmap to hold the dirty log we don't need any other
metadata, or other ways of checking dirtiness.

Style nits: you're not consistently following the Xen coding style, in
particular the spaces around parentheses in 'if's and 'for's.  Also
you've got some code in new files that's clearly at least derived from
old code but just got your own name and copyright at the head of the
file.  Please carry the copyright over from old code when you move it.

Cheers,

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 18:32:33 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 18:32:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQMnH-0001bP-AG; Mon, 22 Oct 2012 18:32:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQMnF-0001bK-38
	for xen-devel@lists.xensource.com; Mon, 22 Oct 2012 18:32:05 +0000
Received: from [85.158.139.83:29133] by server-14.bemta-5.messagelabs.com id
	E3/19-24068-42195805; Mon, 22 Oct 2012 18:32:04 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1350930722!35972899!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODE4Nzcz\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31805 invoked from network); 22 Oct 2012 18:32:03 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Oct 2012 18:32:03 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9MIVvBu022940
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 22 Oct 2012 18:31:57 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9MIVuTe015447
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 22 Oct 2012 18:31:56 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9MIVutk007418; Mon, 22 Oct 2012 13:31:56 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 22 Oct 2012 11:31:55 -0700
Date: Mon, 22 Oct 2012 11:31:54 -0700
From: Mukesh Rathor 
To: Stefano Stabellini 
Message-ID: <20121022113154.0e28ff1d@mantra.us.oracle.com>
In-Reply-To: 
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
	<1350695882-12820-3-git-send-email-konrad.wilk@oracle.com>
	
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Ian Campbell ,
	"xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 2/6] xen/pvh: Extend vcpu_guest_context, p2m,
 event, and xenbus to support PVH.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 22 Oct 2012 14:44:40 +0100
Stefano Stabellini  wrote:

> On Sat, 20 Oct 2012, Konrad Rzeszutek Wilk wrote:
> > From: Mukesh Rathor 
> > 
> > make gdt_frames[]/gdt_ents into a union with {gdtaddr, gdtsz}, as
> > PVH only needs to send down gdtaddr and gdtsz.
> > 
> > For interrupts, PVH uses native_irq_ops.
> > vcpu hotplug is currently not available for PVH.
> > 
> > For events we follow what PVHVM does - to use callback vector.
> > Lastly, also use HVM path to setup XenBus.
> > 
> > Signed-off-by: Mukesh Rathor 
> > Signed-off-by: Konrad Rzeszutek Wilk 
> > ---
> >  		return true;
> >  	}
> > -	xen_copy_trap_info(ctxt->trap_ctxt);
> > +	/* check for autoxlated to get it right for 32bit kernel */
> 
> I am not sure what this comment means, considering that in another
> comment below you say that we don't support 32bit PVH kernels.

Function is common to both 32bit and 64bit kernels. We need to check 
for auto xlated also in the if statement in addition to supervisor 
mode kernel, so 32 bit doesn't go down the wrong path.

PVH is not supported for 32bit kernels, and gs_base_user doesn't exist
in the structure for 32bit so it needs to be if'def'd 64bit which is
ok because PVH is not supprted on 32bit kernel.

> > +					(unsigned
> > long)xen_hypervisor_callback;
> > +		ctxt->failsafe_callback_eip =
> > +					(unsigned
> > long)xen_failsafe_callback;
> > +	}
> > +	ctxt->user_regs.cs = __KERNEL_CS;
> > +	ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct
> > pt_regs); 
> >  	per_cpu(xen_cr3, cpu) = __pa(swapper_pg_dir);
> >  	ctxt->ctrlreg[3] =
> > xen_pfn_to_cr3(virt_to_mfn(swapper_pg_dir));
> 
> The tradional path looks the same as before, however it is hard to
> tell whether the PVH path is correct without the Xen side. For
> example, what is gdtsz?

gdtsz is GUEST_GDTR_LIMIT and gdtaddr is GUEST_GDTR_BASE in the vmcs.

thanks,
Mukesh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 18:32:33 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 18:32:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQMnH-0001bP-AG; Mon, 22 Oct 2012 18:32:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQMnF-0001bK-38
	for xen-devel@lists.xensource.com; Mon, 22 Oct 2012 18:32:05 +0000
Received: from [85.158.139.83:29133] by server-14.bemta-5.messagelabs.com id
	E3/19-24068-42195805; Mon, 22 Oct 2012 18:32:04 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1350930722!35972899!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODE4Nzcz\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31805 invoked from network); 22 Oct 2012 18:32:03 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Oct 2012 18:32:03 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9MIVvBu022940
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 22 Oct 2012 18:31:57 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9MIVuTe015447
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 22 Oct 2012 18:31:56 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9MIVutk007418; Mon, 22 Oct 2012 13:31:56 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 22 Oct 2012 11:31:55 -0700
Date: Mon, 22 Oct 2012 11:31:54 -0700
From: Mukesh Rathor 
To: Stefano Stabellini 
Message-ID: <20121022113154.0e28ff1d@mantra.us.oracle.com>
In-Reply-To: 
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
	<1350695882-12820-3-git-send-email-konrad.wilk@oracle.com>
	
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Ian Campbell ,
	"xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 2/6] xen/pvh: Extend vcpu_guest_context, p2m,
 event, and xenbus to support PVH.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 22 Oct 2012 14:44:40 +0100
Stefano Stabellini  wrote:

> On Sat, 20 Oct 2012, Konrad Rzeszutek Wilk wrote:
> > From: Mukesh Rathor 
> > 
> > make gdt_frames[]/gdt_ents into a union with {gdtaddr, gdtsz}, as
> > PVH only needs to send down gdtaddr and gdtsz.
> > 
> > For interrupts, PVH uses native_irq_ops.
> > vcpu hotplug is currently not available for PVH.
> > 
> > For events we follow what PVHVM does - to use callback vector.
> > Lastly, also use HVM path to setup XenBus.
> > 
> > Signed-off-by: Mukesh Rathor 
> > Signed-off-by: Konrad Rzeszutek Wilk 
> > ---
> >  		return true;
> >  	}
> > -	xen_copy_trap_info(ctxt->trap_ctxt);
> > +	/* check for autoxlated to get it right for 32bit kernel */
> 
> I am not sure what this comment means, considering that in another
> comment below you say that we don't support 32bit PVH kernels.

Function is common to both 32bit and 64bit kernels. We need to check 
for auto xlated also in the if statement in addition to supervisor 
mode kernel, so 32 bit doesn't go down the wrong path.

PVH is not supported for 32bit kernels, and gs_base_user doesn't exist
in the structure for 32bit so it needs to be if'def'd 64bit which is
ok because PVH is not supprted on 32bit kernel.

> > +					(unsigned
> > long)xen_hypervisor_callback;
> > +		ctxt->failsafe_callback_eip =
> > +					(unsigned
> > long)xen_failsafe_callback;
> > +	}
> > +	ctxt->user_regs.cs = __KERNEL_CS;
> > +	ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct
> > pt_regs); 
> >  	per_cpu(xen_cr3, cpu) = __pa(swapper_pg_dir);
> >  	ctxt->ctrlreg[3] =
> > xen_pfn_to_cr3(virt_to_mfn(swapper_pg_dir));
> 
> The tradional path looks the same as before, however it is hard to
> tell whether the PVH path is correct without the Xen side. For
> example, what is gdtsz?

gdtsz is GUEST_GDTR_LIMIT and gdtaddr is GUEST_GDTR_BASE in the vmcs.

thanks,
Mukesh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 18:51:18 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 18:51:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQN5S-0001p6-Vq; Mon, 22 Oct 2012 18:50:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQN5R-0001p1-OE
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 18:50:53 +0000
Received: from [85.158.143.35:38535] by server-1.bemta-4.messagelabs.com id
	C7/CD-19134-D8595805; Mon, 22 Oct 2012 18:50:53 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-21.messagelabs.com!1350931837!16093867!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDUwNzI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDUwNzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24700 invoked from network); 22 Oct 2012 18:50:42 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Oct 2012 18:50:42 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq0M7qF/64
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-079-154.pools.arcor-ip.net [84.57.79.154])
	by smtp.strato.de (jorabe mo39) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id q05e7ao9MHrxc8 ;
	Mon, 22 Oct 2012 20:50:37 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 941A218642; Mon, 22 Oct 2012 20:50:36 +0200 (CEST)
Date: Mon, 22 Oct 2012 20:50:36 +0200
From: Olaf Hering 
To: Keir Fraser 
Message-ID: <20121022185036.GA15348@aepfle.de>
References: <20120828082302.GA27309@aepfle.de>
	
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] fixed location of share info page in HVM guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Aug 28, Keir Fraser wrote:

> On 28/08/2012 09:23, "Olaf Hering"  wrote:
> 
> > On Tue, Aug 28, Keir Fraser wrote:
> > 
> >> How about we guarantee that guests can use the 1MB in address range
> >> 0xFED00000-0xFEDFFFFF for whatever mappings they like, guaranteed unused (or
> >> at least, mapped with nothing useful) when guest kernel starts?
> >> 
> >> This is already, and has always been, the case. But we can etch it in stone
> >> quite easily. :)
> > 
> > 0xFED00000UL is appearently the hpet base adress. But if there is room
> > after that, then lets use that. However, I'm not familiar with these
> > things. Should the area appear in the E820 map as reserverd? If so,
> > where is the code which configures the guests E820 map?
> 
> Okay, that was a bit too clever, trying to hide between IOAPIC and LAPIC
> pages. How about a bit lower in memory -- FE700000-FE7FFFFF?
> 
> Everything in range FC000000-FFFFFFFF should already be marked
> E820_RESERVED. You can test that, and also see
> tools/firmware/hvmloader/e820.c:build_e820_table() (and note that
> RESERVED_MEMBASE == FC000000).
> 
> Can document in hvmloader/config.h and have mem_alloc() test against it
> rather than hvm_info->reserved_mem_pgstart.

I came up with this (perhaps whitespace damaged) change, the guest still boots ok.
The asl part is just copy&paste from the HPET part.

Olaf

---
 tools/firmware/hvmloader/acpi/dsdt.asl |   23 +++++++++++++++++++++++
 tools/firmware/hvmloader/config.h      |    2 ++
 tools/firmware/hvmloader/util.c        |    8 ++++++++
 xen/arch/x86/hvm/hvm.c                 |    4 ++++
 4 files changed, 37 insertions(+)

Index: xen-4.2.0-testing/tools/firmware/hvmloader/acpi/dsdt.asl
===================================================================
--- xen-4.2.0-testing.orig/tools/firmware/hvmloader/acpi/dsdt.asl
+++ xen-4.2.0-testing/tools/firmware/hvmloader/acpi/dsdt.asl
@@ -50,6 +50,7 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2,
            UAR1, 1,
            UAR2, 1,
            LTP1, 1,
+           XENR, 1,
            HPET, 1,
            Offset(4),
            PMIN, 32,
@@ -166,6 +167,28 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2,
                 Return (PRT0)
             }

+            Device(XENR) {
+                Name(_UID, 0)
+                Method (_STA, 0, NotSerialized) {
+                    If(LEqual(\_SB.XENR, 0)) {
+                        Return(0x00)
+                    } Else {
+                        Return(0x0F)
+                    }
+                }
+                Name(_CRS, ResourceTemplate() {
+                    DWordMemory(
+                        ResourceConsumer, PosDecode, MinFixed, MaxFixed,
+                        NonCacheable, ReadWrite,
+                        0x00000000,
+                        0xFE700000,
+                        0xFE7FFFFF,
+                        0x00000000,
+                        0x00100000 /* 1M memory: FE700000 - FE7FFFFF */
+                    )
+                })
+            }
+
             Device(HPET) {
                 Name(_HID,  EISAID("PNP0103"))
                 Name(_UID, 0)
Index: xen-4.2.0-testing/tools/firmware/hvmloader/config.h
===================================================================
--- xen-4.2.0-testing.orig/tools/firmware/hvmloader/config.h
+++ xen-4.2.0-testing/tools/firmware/hvmloader/config.h
@@ -66,6 +66,8 @@ extern unsigned long pci_mem_start, pci_
 /* NB. ACPI_INFO_PHYSICAL_ADDRESS *MUST* match definition in acpi/dsdt.asl! */
 #define ACPI_INFO_PHYSICAL_ADDRESS    0xFC000000
 #define RESERVED_MEMORY_DYNAMIC       0xFC001000
+#define HVM_SHARED_INFO_AREA          0xFE700000
+#define HVM_SHARED_INFO_SIZE          0x00100000

 extern unsigned long scratch_start;

Index: xen-4.2.0-testing/tools/firmware/hvmloader/util.c
===================================================================
--- xen-4.2.0-testing.orig/tools/firmware/hvmloader/util.c
+++ xen-4.2.0-testing/tools/firmware/hvmloader/util.c
@@ -433,11 +433,19 @@ void *mem_alloc(uint32_t size, uint32_t
     if ( align < 16 )
         align = 16;

+retry:
     s = (reserve + align) & ~(align - 1);
     e = s + size - 1;

     BUG_ON((e < s) || (e >> PAGE_SHIFT) >= hvm_info->reserved_mem_pgstart);

+    /* Skip the shared info region */
+    if (s <= HVM_SHARED_INFO_AREA && e >= HVM_SHARED_INFO_AREA) {
+           printf("%s: skipping HVM_SHARED_INFO_AREA: s %08x e %08x r %08x", __func__, s, e, reserve);
+           reserve = HVM_SHARED_INFO_AREA + HVM_SHARED_INFO_SIZE - 1;
+           goto retry;
+    }
+
     while ( (reserve >> PAGE_SHIFT) != (e >> PAGE_SHIFT) )
     {
         reserve += PAGE_SIZE;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 18:51:18 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 18:51:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQN5S-0001p6-Vq; Mon, 22 Oct 2012 18:50:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQN5R-0001p1-OE
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 18:50:53 +0000
Received: from [85.158.143.35:38535] by server-1.bemta-4.messagelabs.com id
	C7/CD-19134-D8595805; Mon, 22 Oct 2012 18:50:53 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-21.messagelabs.com!1350931837!16093867!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDUwNzI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDUwNzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24700 invoked from network); 22 Oct 2012 18:50:42 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Oct 2012 18:50:42 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq0M7qF/64
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-079-154.pools.arcor-ip.net [84.57.79.154])
	by smtp.strato.de (jorabe mo39) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id q05e7ao9MHrxc8 ;
	Mon, 22 Oct 2012 20:50:37 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 941A218642; Mon, 22 Oct 2012 20:50:36 +0200 (CEST)
Date: Mon, 22 Oct 2012 20:50:36 +0200
From: Olaf Hering 
To: Keir Fraser 
Message-ID: <20121022185036.GA15348@aepfle.de>
References: <20120828082302.GA27309@aepfle.de>
	
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] fixed location of share info page in HVM guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Aug 28, Keir Fraser wrote:

> On 28/08/2012 09:23, "Olaf Hering"  wrote:
> 
> > On Tue, Aug 28, Keir Fraser wrote:
> > 
> >> How about we guarantee that guests can use the 1MB in address range
> >> 0xFED00000-0xFEDFFFFF for whatever mappings they like, guaranteed unused (or
> >> at least, mapped with nothing useful) when guest kernel starts?
> >> 
> >> This is already, and has always been, the case. But we can etch it in stone
> >> quite easily. :)
> > 
> > 0xFED00000UL is appearently the hpet base adress. But if there is room
> > after that, then lets use that. However, I'm not familiar with these
> > things. Should the area appear in the E820 map as reserverd? If so,
> > where is the code which configures the guests E820 map?
> 
> Okay, that was a bit too clever, trying to hide between IOAPIC and LAPIC
> pages. How about a bit lower in memory -- FE700000-FE7FFFFF?
> 
> Everything in range FC000000-FFFFFFFF should already be marked
> E820_RESERVED. You can test that, and also see
> tools/firmware/hvmloader/e820.c:build_e820_table() (and note that
> RESERVED_MEMBASE == FC000000).
> 
> Can document in hvmloader/config.h and have mem_alloc() test against it
> rather than hvm_info->reserved_mem_pgstart.

I came up with this (perhaps whitespace damaged) change, the guest still boots ok.
The asl part is just copy&paste from the HPET part.

Olaf

---
 tools/firmware/hvmloader/acpi/dsdt.asl |   23 +++++++++++++++++++++++
 tools/firmware/hvmloader/config.h      |    2 ++
 tools/firmware/hvmloader/util.c        |    8 ++++++++
 xen/arch/x86/hvm/hvm.c                 |    4 ++++
 4 files changed, 37 insertions(+)

Index: xen-4.2.0-testing/tools/firmware/hvmloader/acpi/dsdt.asl
===================================================================
--- xen-4.2.0-testing.orig/tools/firmware/hvmloader/acpi/dsdt.asl
+++ xen-4.2.0-testing/tools/firmware/hvmloader/acpi/dsdt.asl
@@ -50,6 +50,7 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2,
            UAR1, 1,
            UAR2, 1,
            LTP1, 1,
+           XENR, 1,
            HPET, 1,
            Offset(4),
            PMIN, 32,
@@ -166,6 +167,28 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2,
                 Return (PRT0)
             }

+            Device(XENR) {
+                Name(_UID, 0)
+                Method (_STA, 0, NotSerialized) {
+                    If(LEqual(\_SB.XENR, 0)) {
+                        Return(0x00)
+                    } Else {
+                        Return(0x0F)
+                    }
+                }
+                Name(_CRS, ResourceTemplate() {
+                    DWordMemory(
+                        ResourceConsumer, PosDecode, MinFixed, MaxFixed,
+                        NonCacheable, ReadWrite,
+                        0x00000000,
+                        0xFE700000,
+                        0xFE7FFFFF,
+                        0x00000000,
+                        0x00100000 /* 1M memory: FE700000 - FE7FFFFF */
+                    )
+                })
+            }
+
             Device(HPET) {
                 Name(_HID,  EISAID("PNP0103"))
                 Name(_UID, 0)
Index: xen-4.2.0-testing/tools/firmware/hvmloader/config.h
===================================================================
--- xen-4.2.0-testing.orig/tools/firmware/hvmloader/config.h
+++ xen-4.2.0-testing/tools/firmware/hvmloader/config.h
@@ -66,6 +66,8 @@ extern unsigned long pci_mem_start, pci_
 /* NB. ACPI_INFO_PHYSICAL_ADDRESS *MUST* match definition in acpi/dsdt.asl! */
 #define ACPI_INFO_PHYSICAL_ADDRESS    0xFC000000
 #define RESERVED_MEMORY_DYNAMIC       0xFC001000
+#define HVM_SHARED_INFO_AREA          0xFE700000
+#define HVM_SHARED_INFO_SIZE          0x00100000

 extern unsigned long scratch_start;

Index: xen-4.2.0-testing/tools/firmware/hvmloader/util.c
===================================================================
--- xen-4.2.0-testing.orig/tools/firmware/hvmloader/util.c
+++ xen-4.2.0-testing/tools/firmware/hvmloader/util.c
@@ -433,11 +433,19 @@ void *mem_alloc(uint32_t size, uint32_t
     if ( align < 16 )
         align = 16;

+retry:
     s = (reserve + align) & ~(align - 1);
     e = s + size - 1;

     BUG_ON((e < s) || (e >> PAGE_SHIFT) >= hvm_info->reserved_mem_pgstart);

+    /* Skip the shared info region */
+    if (s <= HVM_SHARED_INFO_AREA && e >= HVM_SHARED_INFO_AREA) {
+           printf("%s: skipping HVM_SHARED_INFO_AREA: s %08x e %08x r %08x", __func__, s, e, reserve);
+           reserve = HVM_SHARED_INFO_AREA + HVM_SHARED_INFO_SIZE - 1;
+           goto retry;
+    }
+
     while ( (reserve >> PAGE_SHIFT) != (e >> PAGE_SHIFT) )
     {
         reserve += PAGE_SIZE;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 19:17:59 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 19:17:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQNVF-0002Hr-0l; Mon, 22 Oct 2012 19:17:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQNVD-0002Hj-GF
	for Xen-devel@lists.xen.org; Mon, 22 Oct 2012 19:17:31 +0000
Received: from [85.158.143.99:39386] by server-3.bemta-4.messagelabs.com id
	D2/A0-03544-ACB95805; Mon, 22 Oct 2012 19:17:30 +0000
X-Env-Sender: xinxinjin89@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1350933449!35077989!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24674 invoked from network); 22 Oct 2012 19:17:30 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 19:17:30 -0000
Received: by mail-qa0-f45.google.com with SMTP id s11so1587200qaa.11
	for ; Mon, 22 Oct 2012 12:17:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=vi4uTXAOepDvTBwSwlGzucN8d2oMDY36He6alSzcVRY=;
	b=dkQN/EZpoabA9hZWrHDshh+RbvtaDT7EDH60mYw9cgNvNeDuHymxebhF/PPNL2168v
	j3Z+2dICAWxu4laQCl4fVg9JdcU0OJAlbBY106vbSPRSlqTGcTyVQ8/B4VO44inoZ281
	X2SOuOQipl7Q75U3K9Lz6ubVnJ10PYhEq4HlRWyoLVPa2WIaPvUV+duUFG/MUkVkQRn0
	kJgqSnweW7yWihprEjjUkM9tmCe6+SUPmBdmhMXGKHtFCD1tJkBocjszTh+Ac2F9jD8r
	WsnkY5Z6sJluIwGZGwhYB6yQ0yT5IrD+Q3hoc93I5WAyk5XHXjedNngQX+whf5Uzg9aj
	fNvA==
MIME-Version: 1.0
Received: by 10.224.9.138 with SMTP id l10mr4673774qal.58.1350933448821; Mon,
	22 Oct 2012 12:17:28 -0700 (PDT)
Received: by 10.229.235.13 with HTTP; Mon, 22 Oct 2012 12:17:28 -0700 (PDT)
Date: Mon, 22 Oct 2012 12:17:28 -0700
Message-ID: 
From: Xinxin Jin 
To: Xen-devel@lists.xen.org
Subject: [Xen-devel] How does Xen emulate guest's write to its pte ?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1552381471273585810=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1552381471273585810==
Content-Type: multipart/alternative; boundary=bcaec517ab7a550cbd04ccaab46e

--bcaec517ab7a550cbd04ccaab46e
Content-Type: text/plain; charset=ISO-8859-1

Hi all,
I traced Xen's writable page table handler: PV guests' write operation to a
pte will trap to Xen's page fault handler ptwr_do_page_fault() which will
call x86_emulate() to emulate the write.
But  after I print out the pte (which maps faulting virtual address) value,
 I was very surprised to find that, the value does not change before/after
x86_emulation(). This result confuses me: so how does Xen emulate pte write
then ?
Thanks a lot !
-- 
Xinxin

--bcaec517ab7a550cbd04ccaab46e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi all,=A0
I traced Xen's writable page table han=
dler: PV guests' write operation to a pte will trap to Xen's page f=
ault handler=A0ptwr_do_page_fault() which will call x86_emulate() to emulat=
e the write.=A0


But =A0after I print out the pte (which maps faulting virtual address)=
 value, =A0I was very surprised to find that, the value does not change bef=
ore/after x86_emulation(). This result confuses me: so how does Xen emulate=
 pte write then ?


Thanks a lot !
-- 
Xinxin




--bcaec517ab7a550cbd04ccaab46e--


--===============1552381471273585810==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1552381471273585810==--


From xen-devel-bounces@lists.xen.org Mon Oct 22 19:17:59 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 19:17:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQNVF-0002Hr-0l; Mon, 22 Oct 2012 19:17:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQNVD-0002Hj-GF
	for Xen-devel@lists.xen.org; Mon, 22 Oct 2012 19:17:31 +0000
Received: from [85.158.143.99:39386] by server-3.bemta-4.messagelabs.com id
	D2/A0-03544-ACB95805; Mon, 22 Oct 2012 19:17:30 +0000
X-Env-Sender: xinxinjin89@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1350933449!35077989!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24674 invoked from network); 22 Oct 2012 19:17:30 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 19:17:30 -0000
Received: by mail-qa0-f45.google.com with SMTP id s11so1587200qaa.11
	for ; Mon, 22 Oct 2012 12:17:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=vi4uTXAOepDvTBwSwlGzucN8d2oMDY36He6alSzcVRY=;
	b=dkQN/EZpoabA9hZWrHDshh+RbvtaDT7EDH60mYw9cgNvNeDuHymxebhF/PPNL2168v
	j3Z+2dICAWxu4laQCl4fVg9JdcU0OJAlbBY106vbSPRSlqTGcTyVQ8/B4VO44inoZ281
	X2SOuOQipl7Q75U3K9Lz6ubVnJ10PYhEq4HlRWyoLVPa2WIaPvUV+duUFG/MUkVkQRn0
	kJgqSnweW7yWihprEjjUkM9tmCe6+SUPmBdmhMXGKHtFCD1tJkBocjszTh+Ac2F9jD8r
	WsnkY5Z6sJluIwGZGwhYB6yQ0yT5IrD+Q3hoc93I5WAyk5XHXjedNngQX+whf5Uzg9aj
	fNvA==
MIME-Version: 1.0
Received: by 10.224.9.138 with SMTP id l10mr4673774qal.58.1350933448821; Mon,
	22 Oct 2012 12:17:28 -0700 (PDT)
Received: by 10.229.235.13 with HTTP; Mon, 22 Oct 2012 12:17:28 -0700 (PDT)
Date: Mon, 22 Oct 2012 12:17:28 -0700
Message-ID: 
From: Xinxin Jin 
To: Xen-devel@lists.xen.org
Subject: [Xen-devel] How does Xen emulate guest's write to its pte ?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1552381471273585810=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1552381471273585810==
Content-Type: multipart/alternative; boundary=bcaec517ab7a550cbd04ccaab46e

--bcaec517ab7a550cbd04ccaab46e
Content-Type: text/plain; charset=ISO-8859-1

Hi all,
I traced Xen's writable page table handler: PV guests' write operation to a
pte will trap to Xen's page fault handler ptwr_do_page_fault() which will
call x86_emulate() to emulate the write.
But  after I print out the pte (which maps faulting virtual address) value,
 I was very surprised to find that, the value does not change before/after
x86_emulation(). This result confuses me: so how does Xen emulate pte write
then ?
Thanks a lot !
-- 
Xinxin

--bcaec517ab7a550cbd04ccaab46e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi all,=A0
I traced Xen's writable page table han=
dler: PV guests' write operation to a pte will trap to Xen's page f=
ault handler=A0ptwr_do_page_fault() which will call x86_emulate() to emulat=
e the write.=A0


But =A0after I print out the pte (which maps faulting virtual address)=
 value, =A0I was very surprised to find that, the value does not change bef=
ore/after x86_emulation(). This result confuses me: so how does Xen emulate=
 pte write then ?


Thanks a lot !
-- 
Xinxin




--bcaec517ab7a550cbd04ccaab46e--


--===============1552381471273585810==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1552381471273585810==--


From xen-devel-bounces@lists.xen.org Mon Oct 22 19:27:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 19:27:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQNel-0002Va-3v; Mon, 22 Oct 2012 19:27:23 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQNek-0002VT-1j
	for xen-devel@lists.xensource.com; Mon, 22 Oct 2012 19:27:22 +0000
Received: from [193.109.254.147:47026] by server-11.bemta-14.messagelabs.com
	id 49/DD-09558-71E95805; Mon, 22 Oct 2012 19:27:19 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-7.tower-27.messagelabs.com!1350934037!2232232!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4536 invoked from network); 22 Oct 2012 19:27:18 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Oct 2012 19:27:18 -0000
Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com
	[209.85.212.177]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q9MJREbI026885
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for ; Mon, 22 Oct 2012 12:27:15 -0700
Received: by mail-wi0-f177.google.com with SMTP id hj13so2497772wib.6
	for ;
	Mon, 22 Oct 2012 12:27:13 -0700 (PDT)
Received: by 10.216.193.227 with SMTP id k77mr5488160wen.178.1350934033031;
	Mon, 22 Oct 2012 12:27:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.33.6 with HTTP; Mon, 22 Oct 2012 12:26:32 -0700 (PDT)
In-Reply-To: <20613.9696.715106.47187@mariner.uk.xensource.com>
References: 
	<20609.28264.158580.995717@mariner.uk.xensource.com>
	
	<20613.9696.715106.47187@mariner.uk.xensource.com>
From: Shriram Rajagopalan 
Date: Mon, 22 Oct 2012 12:26:32 -0700
Message-ID: 
To: Ian Jackson ,
	"Liu, Jinsong" 
Cc: Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	George Dunlap ,
	Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 5/5] X86/vMCE: guest broken page handling
	when migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============5415581938582293538=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5415581938582293538==
Content-Type: multipart/alternative; boundary=0016e6d9a3e32760f104ccaad715

--0016e6d9a3e32760f104ccaad715
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Oct 22, 2012 at 3:54 AM, Ian Jackson wrote:

> George Dunlap writes ("Re: [Xen-devel] [PATCH 5/5] X86/vMCE: guest broken
> page handling when migration"):
> > On Fri, Oct 19, 2012 at 4:14 PM, Ian Jackson 
> wrote:
> > > This looks plausible to me, as far as the tools go.  Can you explain
> > > how you have tested this ?  Did you manage to do any tests of the
> > > remus codepaths ?
> >
> > I'm pretty sure that this shouldn't cause any problems with Remus.  If
> > it's difficult for Jinsong to test Remus, I think probably OK to
> > commit it, and then revert it if the Remus guys have any problems.
>
> OK.
>
>
You can easily test it with Remus. With xl, memory replication
functionality is already
in place. so xl remus command should work.

If you are running it with Xend, run Remus with --no-net option.

shriram


>  Ian.
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

--0016e6d9a3e32760f104ccaad715
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Mon, Oct 22, 2012 at 3:54 AM, Ian Jackson &l=
t;Ian.Jackso=
n@eu.citrix.com> wrote:



George Dunlap writes ("Re: [Xen-devel] =
[PATCH 5/5] X86/vMCE: guest broken page handling when migration"):




> On Fri, Oct 19, 2012 at 4:14 PM, Ian Jackson <Ian.Jackson@eu.citrix.com>=
 wrote:


> > This looks plausible to me, as far as the=
 tools go. =A0Can you explain

> > how you have tested this ? =A0Did you manage to do any tests of t=
he

> > remus codepaths ?

>

> I'm pretty sure that this shouldn't cause any problems with Re=
mus. =A0If

> it's difficult for Jinsong to test Remus, I think probably OK to
> commit it, and then revert it if the Remus guys have any problems.




OK.



You can easily test it with Remus. With xl, memory replic=
ation functionality is already
in place. so xl remus command should wor=
k.




If you are running it with Xend, run Remus=A0with --no-net op=
tion.

shriram
=A0



Ian.




_______________________________________________

Xen-devel mailing list

Xen-devel@lists.xen.org

http://lists.x=
en.org/xen-devel





--0016e6d9a3e32760f104ccaad715--


--===============5415581938582293538==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5415581938582293538==--


From xen-devel-bounces@lists.xen.org Mon Oct 22 19:27:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 19:27:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQNel-0002Va-3v; Mon, 22 Oct 2012 19:27:23 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQNek-0002VT-1j
	for xen-devel@lists.xensource.com; Mon, 22 Oct 2012 19:27:22 +0000
Received: from [193.109.254.147:47026] by server-11.bemta-14.messagelabs.com
	id 49/DD-09558-71E95805; Mon, 22 Oct 2012 19:27:19 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-7.tower-27.messagelabs.com!1350934037!2232232!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4536 invoked from network); 22 Oct 2012 19:27:18 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Oct 2012 19:27:18 -0000
Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com
	[209.85.212.177]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q9MJREbI026885
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for ; Mon, 22 Oct 2012 12:27:15 -0700
Received: by mail-wi0-f177.google.com with SMTP id hj13so2497772wib.6
	for ;
	Mon, 22 Oct 2012 12:27:13 -0700 (PDT)
Received: by 10.216.193.227 with SMTP id k77mr5488160wen.178.1350934033031;
	Mon, 22 Oct 2012 12:27:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.33.6 with HTTP; Mon, 22 Oct 2012 12:26:32 -0700 (PDT)
In-Reply-To: <20613.9696.715106.47187@mariner.uk.xensource.com>
References: 
	<20609.28264.158580.995717@mariner.uk.xensource.com>
	
	<20613.9696.715106.47187@mariner.uk.xensource.com>
From: Shriram Rajagopalan 
Date: Mon, 22 Oct 2012 12:26:32 -0700
Message-ID: 
To: Ian Jackson ,
	"Liu, Jinsong" 
Cc: Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	George Dunlap ,
	Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 5/5] X86/vMCE: guest broken page handling
	when migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============5415581938582293538=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5415581938582293538==
Content-Type: multipart/alternative; boundary=0016e6d9a3e32760f104ccaad715

--0016e6d9a3e32760f104ccaad715
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Oct 22, 2012 at 3:54 AM, Ian Jackson wrote:

> George Dunlap writes ("Re: [Xen-devel] [PATCH 5/5] X86/vMCE: guest broken
> page handling when migration"):
> > On Fri, Oct 19, 2012 at 4:14 PM, Ian Jackson 
> wrote:
> > > This looks plausible to me, as far as the tools go.  Can you explain
> > > how you have tested this ?  Did you manage to do any tests of the
> > > remus codepaths ?
> >
> > I'm pretty sure that this shouldn't cause any problems with Remus.  If
> > it's difficult for Jinsong to test Remus, I think probably OK to
> > commit it, and then revert it if the Remus guys have any problems.
>
> OK.
>
>
You can easily test it with Remus. With xl, memory replication
functionality is already
in place. so xl remus command should work.

If you are running it with Xend, run Remus with --no-net option.

shriram


>  Ian.
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

--0016e6d9a3e32760f104ccaad715
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Mon, Oct 22, 2012 at 3:54 AM, Ian Jackson &l=
t;Ian.Jackso=
n@eu.citrix.com> wrote:



George Dunlap writes ("Re: [Xen-devel] =
[PATCH 5/5] X86/vMCE: guest broken page handling when migration"):




> On Fri, Oct 19, 2012 at 4:14 PM, Ian Jackson <Ian.Jackson@eu.citrix.com>=
 wrote:


> > This looks plausible to me, as far as the=
 tools go. =A0Can you explain

> > how you have tested this ? =A0Did you manage to do any tests of t=
he

> > remus codepaths ?

>

> I'm pretty sure that this shouldn't cause any problems with Re=
mus. =A0If

> it's difficult for Jinsong to test Remus, I think probably OK to
> commit it, and then revert it if the Remus guys have any problems.




OK.



You can easily test it with Remus. With xl, memory replic=
ation functionality is already
in place. so xl remus command should wor=
k.




If you are running it with Xend, run Remus=A0with --no-net op=
tion.

shriram
=A0



Ian.




_______________________________________________

Xen-devel mailing list

Xen-devel@lists.xen.org

http://lists.x=
en.org/xen-devel





--0016e6d9a3e32760f104ccaad715--


--===============5415581938582293538==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5415581938582293538==--


From xen-devel-bounces@lists.xen.org Mon Oct 22 20:00:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 20:00:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQOAF-0002pe-1m; Mon, 22 Oct 2012 19:59:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQOAD-0002pZ-Kf
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 19:59:53 +0000
Received: from [85.158.138.51:36887] by server-13.bemta-3.messagelabs.com id
	B3/91-26794-8B5A5805; Mon, 22 Oct 2012 19:59:52 +0000
X-Env-Sender: davidxu06@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1350935991!27358882!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10271 invoked from network); 22 Oct 2012 19:59:52 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 19:59:52 -0000
Received: by mail-qc0-f173.google.com with SMTP id b12so2243692qca.32
	for ; Mon, 22 Oct 2012 12:59:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=id8khdt+kGArrjtlJhUM8KCoEdgBu1uHEWKOGZblwx0=;
	b=TWFsZ2AQ/eve+bG4QvIZkaTXcVN1aNlhuBDAMuU/DRVcBgGu6V5OOTHXGMPCbn8E+h
	RrQyOTpjoyNHPZSQyiF8vgKNWCxJaGibFZgPIw+JcbvgZ42wl+Z9JpcFSGLjonmqNWoN
	8BJlkf0MmIlns9Q77IoUf65HLPI9jC/FFh2+9dJcy5FYyJPVZxnPcZys01AnFjw+bqk8
	gpx9yi+Fl63D+fbXb9beRYGHuM+ZAOp69qurTly9ghCETI035wDtRfZ5yBBG9BTP7kIQ
	o+7yk4k5eTqoqZbeJCpAaBHsIU/7bJCuEnCWZobeZrphMwcDo1zYLmh0He4iHjA4gmL3
	Ww4w==
MIME-Version: 1.0
Received: by 10.224.27.3 with SMTP id g3mr4616557qac.44.1350935990862; Mon, 22
	Oct 2012 12:59:50 -0700 (PDT)
Received: by 10.49.1.116 with HTTP; Mon, 22 Oct 2012 12:59:50 -0700 (PDT)
Date: Mon, 22 Oct 2012 15:59:50 -0400
Message-ID: 
From: David Xu 
To: xen-devel@lists.xen.org
Subject: [Xen-devel] xen_evtchn_do_upcall() in guestOS kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============2255315269228529145=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2255315269228529145==
Content-Type: multipart/alternative; boundary=bcaec5196c6bd982bb04ccab4be9

--bcaec5196c6bd982bb04ccab4be9
Content-Type: text/plain; charset=ISO-8859-1

Hi,

Does anybody know the purpose of xen_evtchn_do_upcall() in guest kernel?
When will we use it? Thanks.

Regards,
Cong

--bcaec5196c6bd982bb04ccab4be9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

Does anybody know the purpose of=A0xen_evtchn_do_upc=
all() in guest kernel? When will we use it? Thanks.

Regards,
Cong


--bcaec5196c6bd982bb04ccab4be9--


--===============2255315269228529145==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2255315269228529145==--


From xen-devel-bounces@lists.xen.org Mon Oct 22 20:00:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 20:00:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQOAF-0002pe-1m; Mon, 22 Oct 2012 19:59:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQOAD-0002pZ-Kf
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 19:59:53 +0000
Received: from [85.158.138.51:36887] by server-13.bemta-3.messagelabs.com id
	B3/91-26794-8B5A5805; Mon, 22 Oct 2012 19:59:52 +0000
X-Env-Sender: davidxu06@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1350935991!27358882!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10271 invoked from network); 22 Oct 2012 19:59:52 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 19:59:52 -0000
Received: by mail-qc0-f173.google.com with SMTP id b12so2243692qca.32
	for ; Mon, 22 Oct 2012 12:59:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=id8khdt+kGArrjtlJhUM8KCoEdgBu1uHEWKOGZblwx0=;
	b=TWFsZ2AQ/eve+bG4QvIZkaTXcVN1aNlhuBDAMuU/DRVcBgGu6V5OOTHXGMPCbn8E+h
	RrQyOTpjoyNHPZSQyiF8vgKNWCxJaGibFZgPIw+JcbvgZ42wl+Z9JpcFSGLjonmqNWoN
	8BJlkf0MmIlns9Q77IoUf65HLPI9jC/FFh2+9dJcy5FYyJPVZxnPcZys01AnFjw+bqk8
	gpx9yi+Fl63D+fbXb9beRYGHuM+ZAOp69qurTly9ghCETI035wDtRfZ5yBBG9BTP7kIQ
	o+7yk4k5eTqoqZbeJCpAaBHsIU/7bJCuEnCWZobeZrphMwcDo1zYLmh0He4iHjA4gmL3
	Ww4w==
MIME-Version: 1.0
Received: by 10.224.27.3 with SMTP id g3mr4616557qac.44.1350935990862; Mon, 22
	Oct 2012 12:59:50 -0700 (PDT)
Received: by 10.49.1.116 with HTTP; Mon, 22 Oct 2012 12:59:50 -0700 (PDT)
Date: Mon, 22 Oct 2012 15:59:50 -0400
Message-ID: 
From: David Xu 
To: xen-devel@lists.xen.org
Subject: [Xen-devel] xen_evtchn_do_upcall() in guestOS kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============2255315269228529145=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2255315269228529145==
Content-Type: multipart/alternative; boundary=bcaec5196c6bd982bb04ccab4be9

--bcaec5196c6bd982bb04ccab4be9
Content-Type: text/plain; charset=ISO-8859-1

Hi,

Does anybody know the purpose of xen_evtchn_do_upcall() in guest kernel?
When will we use it? Thanks.

Regards,
Cong

--bcaec5196c6bd982bb04ccab4be9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

Does anybody know the purpose of=A0xen_evtchn_do_upc=
all() in guest kernel? When will we use it? Thanks.

Regards,
Cong


--bcaec5196c6bd982bb04ccab4be9--


--===============2255315269228529145==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2255315269228529145==--


From xen-devel-bounces@lists.xen.org Mon Oct 22 20:02:45 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 20:02:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQOCe-0002yk-JP; Mon, 22 Oct 2012 20:02:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQOCd-0002yf-GF
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 20:02:23 +0000
Received: from [85.158.139.211:55774] by server-16.bemta-5.messagelabs.com id
	65/B5-09196-E46A5805; Mon, 22 Oct 2012 20:02:22 +0000
X-Env-Sender: avs.009@gmail.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1350936140!19321838!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15332 invoked from network); 22 Oct 2012 20:02:22 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 20:02:22 -0000
Received: by mail-ob0-f173.google.com with SMTP id wc18so3660848obb.32
	for ; Mon, 22 Oct 2012 13:02:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=hQ9BYvgLMvamzQp2zk2MNuqc6vYVotw/cUTx2xIkx3I=;
	b=jtPLTYLVRW0oFF8fnqr1VgbNls6Lug7MrTu+kbcgdJWPjvY/+rhldHyQaRbKeYY2F9
	nPL0OwQeRU1rdIkTGb7gJ5qKRRD8SnjWp//t0OFzBwFMcO3pNCBaeEk1jcgJqcJcm/DS
	dZYyqBpzV4rlVJ85+Fl3hw9px1UVvW8ztB4mSEYeSPkl5RKUni3E9mDXK3dfG/mlUJDw
	xuwcxKsgmmzdKqN7c19/NXn0zWdQSuJLU5cEEpo6CkpzUnkTE5MWB2jOMUzt2ZzXPTLH
	FTTBR3QBcTrMjBP7rDFpUBt1mKQXc2SkvJmztTmi98Y3VcU6RFWOhne3xEcLCp88bEJ7
	LeCw==
MIME-Version: 1.0
Received: by 10.182.38.101 with SMTP id f5mr8143029obk.80.1350936140498; Mon,
	22 Oct 2012 13:02:20 -0700 (PDT)
Received: by 10.60.161.233 with HTTP; Mon, 22 Oct 2012 13:02:20 -0700 (PDT)
In-Reply-To: <20121019173307.GT26830@phenom.dumpdata.com>
References: 
	<507C075302000078000A1593@nat28.tlf.novell.com>
	
	
	<5081271C02000078000A2844@nat28.tlf.novell.com>
	<20121019173307.GT26830@phenom.dumpdata.com>
Date: Mon, 22 Oct 2012 18:02:20 -0200
Message-ID: 
From: Allan Scheid 
To: Konrad Rzeszutek Wilk 
Cc: Daniel Kiper , Jan Beulich ,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2 with EFI on IBM x3650 ACPI Bug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============6520817042250287676=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6520817042250287676==
Content-Type: multipart/alternative; boundary=f46d04463008c4c72a04ccab5414

--f46d04463008c4c72a04ccab5414
Content-Type: text/plain; charset=ISO-8859-1

Hello, i bring good news,

Thank's Jan and Daniel, i am using now the kernel 3.3.0 with the patches
recomended by Jan, here is the link in the xen lists:

http://lists.xen.org/archives/html/xen-devel/2012-02/msg02027.html

Now all things are working!! I just have a little bug in Xend start,
because don't find the python libary directory, but i just add export to
bashrc and work's fine.

For other things i used this wonderfull tutorial, just for record:
http://wiki.xen.org/wiki/Comprehensive_Xen_Debian_Wheezy_PCI_Passthrough_Tutorial

--f46d04463008c4c72a04ccab5414
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Hello, i bring good news,

Thank's Ja=
n and Daniel, i am using now the kernel 3.3.0 with the patches recomended b=
y Jan, here is the link in the xen lists:




Now all things are working!! I just have a little bug i=
n Xend start, because don't find the python libary directory, but i jus=
t add export to bashrc and work's fine.


For other things i used this wonderfull tutorial, just for record: http://wiki.xen.org/wiki/Comprehensive_Xen_Debian_Wheezy_PCI_Pa=
ssthrough_Tutorial






--f46d04463008c4c72a04ccab5414--


--===============6520817042250287676==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6520817042250287676==--


From xen-devel-bounces@lists.xen.org Mon Oct 22 20:02:45 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 20:02:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQOCe-0002yk-JP; Mon, 22 Oct 2012 20:02:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQOCd-0002yf-GF
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 20:02:23 +0000
Received: from [85.158.139.211:55774] by server-16.bemta-5.messagelabs.com id
	65/B5-09196-E46A5805; Mon, 22 Oct 2012 20:02:22 +0000
X-Env-Sender: avs.009@gmail.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1350936140!19321838!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15332 invoked from network); 22 Oct 2012 20:02:22 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 20:02:22 -0000
Received: by mail-ob0-f173.google.com with SMTP id wc18so3660848obb.32
	for ; Mon, 22 Oct 2012 13:02:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=hQ9BYvgLMvamzQp2zk2MNuqc6vYVotw/cUTx2xIkx3I=;
	b=jtPLTYLVRW0oFF8fnqr1VgbNls6Lug7MrTu+kbcgdJWPjvY/+rhldHyQaRbKeYY2F9
	nPL0OwQeRU1rdIkTGb7gJ5qKRRD8SnjWp//t0OFzBwFMcO3pNCBaeEk1jcgJqcJcm/DS
	dZYyqBpzV4rlVJ85+Fl3hw9px1UVvW8ztB4mSEYeSPkl5RKUni3E9mDXK3dfG/mlUJDw
	xuwcxKsgmmzdKqN7c19/NXn0zWdQSuJLU5cEEpo6CkpzUnkTE5MWB2jOMUzt2ZzXPTLH
	FTTBR3QBcTrMjBP7rDFpUBt1mKQXc2SkvJmztTmi98Y3VcU6RFWOhne3xEcLCp88bEJ7
	LeCw==
MIME-Version: 1.0
Received: by 10.182.38.101 with SMTP id f5mr8143029obk.80.1350936140498; Mon,
	22 Oct 2012 13:02:20 -0700 (PDT)
Received: by 10.60.161.233 with HTTP; Mon, 22 Oct 2012 13:02:20 -0700 (PDT)
In-Reply-To: <20121019173307.GT26830@phenom.dumpdata.com>
References: 
	<507C075302000078000A1593@nat28.tlf.novell.com>
	
	
	<5081271C02000078000A2844@nat28.tlf.novell.com>
	<20121019173307.GT26830@phenom.dumpdata.com>
Date: Mon, 22 Oct 2012 18:02:20 -0200
Message-ID: 
From: Allan Scheid 
To: Konrad Rzeszutek Wilk 
Cc: Daniel Kiper , Jan Beulich ,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2 with EFI on IBM x3650 ACPI Bug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============6520817042250287676=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6520817042250287676==
Content-Type: multipart/alternative; boundary=f46d04463008c4c72a04ccab5414

--f46d04463008c4c72a04ccab5414
Content-Type: text/plain; charset=ISO-8859-1

Hello, i bring good news,

Thank's Jan and Daniel, i am using now the kernel 3.3.0 with the patches
recomended by Jan, here is the link in the xen lists:

http://lists.xen.org/archives/html/xen-devel/2012-02/msg02027.html

Now all things are working!! I just have a little bug in Xend start,
because don't find the python libary directory, but i just add export to
bashrc and work's fine.

For other things i used this wonderfull tutorial, just for record:
http://wiki.xen.org/wiki/Comprehensive_Xen_Debian_Wheezy_PCI_Passthrough_Tutorial

--f46d04463008c4c72a04ccab5414
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Hello, i bring good news,

Thank's Ja=
n and Daniel, i am using now the kernel 3.3.0 with the patches recomended b=
y Jan, here is the link in the xen lists:




Now all things are working!! I just have a little bug i=
n Xend start, because don't find the python libary directory, but i jus=
t add export to bashrc and work's fine.


For other things i used this wonderfull tutorial, just for record: http://wiki.xen.org/wiki/Comprehensive_Xen_Debian_Wheezy_PCI_Pa=
ssthrough_Tutorial






--f46d04463008c4c72a04ccab5414--


--===============6520817042250287676==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6520817042250287676==--


From xen-devel-bounces@lists.xen.org Mon Oct 22 20:15:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 20:15:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQOP9-0003F2-Rf; Mon, 22 Oct 2012 20:15:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQOP8-0003Ex-0h
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 20:15:18 +0000
Received: from [85.158.138.51:21965] by server-9.bemta-3.messagelabs.com id
	69/41-16841-559A5805; Mon, 22 Oct 2012 20:15:17 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1350936913!29022433!1
X-Originating-IP: [209.85.220.45]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15035 invoked from network); 22 Oct 2012 20:15:15 -0000
Received: from mail-pa0-f45.google.com (HELO mail-pa0-f45.google.com)
	(209.85.220.45)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 20:15:15 -0000
Received: by mail-pa0-f45.google.com with SMTP id fb10so2238524pad.32
	for ; Mon, 22 Oct 2012 13:15:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=SRUdTlPgPY3jBzhlnzftmoW3Q1CoTpZbiD+5J1h4IDw=;
	b=bp/NhnwLvZZkAVh8BF81eZDgv1bATDRksS+pNfxWgzp7Q8nbIUzt8RocDCVsNZb0pV
	2rtTQC+pkLfl2H91vqfiXeMx5nxazYlsnDES1pyilHNSuuSgc913mm8aDcj6lU2IwsJC
	tV2QkohsdY2+rRUWmi6Kar4Ay5Hk7uC/ZHG76TfrgbqO+lfnUaKvPdqnPb2quNjCLkQV
	DPJDFOAGZcyoibwG82l6xdi4cJqY1BLcKfe8t7oOTBWvGRWaLzvT0k0Azdc3HJIk6c08
	r+Sh884A9XpZayaFBgjPqO9HeCjd3WCxebdbLdY4BTJpvIjMjw8OAw9W4uBwNw4Mc69Z
	1DRQ==
Received: by 10.68.218.39 with SMTP id pd7mr32994663pbc.121.1350936913188;
	Mon, 22 Oct 2012 13:15:13 -0700 (PDT)
Received: from [10.128.0.122] (S0106001c25a066a0.vc.shawcable.net.
	[24.85.255.130])
	by mx.google.com with ESMTPS id j10sm6405982pax.4.2012.10.22.13.15.10
	(version=SSLv3 cipher=OTHER); Mon, 22 Oct 2012 13:15:12 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Mon, 22 Oct 2012 13:15:04 +0100
From: Keir Fraser 
To: Olaf Hering 
Message-ID: 
Thread-Topic: [Xen-devel] fixed location of share info page in HVM guests
Thread-Index: Ac2wkewDsV+KOK3ofUykiE4CsSozdw==
In-Reply-To: <20121022185036.GA15348@aepfle.de>
Mime-version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] fixed location of share info page in HVM guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 22/10/2012 19:50, "Olaf Hering"  wrote:

>> Okay, that was a bit too clever, trying to hide between IOAPIC and LAPIC
>> pages. How about a bit lower in memory -- FE700000-FE7FFFFF?
>> 
>> Everything in range FC000000-FFFFFFFF should already be marked
>> E820_RESERVED. You can test that, and also see
>> tools/firmware/hvmloader/e820.c:build_e820_table() (and note that
>> RESERVED_MEMBASE == FC000000).
>> 
>> Can document in hvmloader/config.h and have mem_alloc() test against it
>> rather than hvm_info->reserved_mem_pgstart.
> 
> I came up with this (perhaps whitespace damaged) change, the guest still boots
> ok.
> The asl part is just copy&paste from the HPET part.

Is there any point encoding this in the DSDT? I thought the guest OS needs
to access the shared info area earlier than it is able to decode the DSDT?

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 20:15:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 20:15:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQOP9-0003F2-Rf; Mon, 22 Oct 2012 20:15:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQOP8-0003Ex-0h
	for xen-devel@lists.xen.org; Mon, 22 Oct 2012 20:15:18 +0000
Received: from [85.158.138.51:21965] by server-9.bemta-3.messagelabs.com id
	69/41-16841-559A5805; Mon, 22 Oct 2012 20:15:17 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1350936913!29022433!1
X-Originating-IP: [209.85.220.45]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15035 invoked from network); 22 Oct 2012 20:15:15 -0000
Received: from mail-pa0-f45.google.com (HELO mail-pa0-f45.google.com)
	(209.85.220.45)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 20:15:15 -0000
Received: by mail-pa0-f45.google.com with SMTP id fb10so2238524pad.32
	for ; Mon, 22 Oct 2012 13:15:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=SRUdTlPgPY3jBzhlnzftmoW3Q1CoTpZbiD+5J1h4IDw=;
	b=bp/NhnwLvZZkAVh8BF81eZDgv1bATDRksS+pNfxWgzp7Q8nbIUzt8RocDCVsNZb0pV
	2rtTQC+pkLfl2H91vqfiXeMx5nxazYlsnDES1pyilHNSuuSgc913mm8aDcj6lU2IwsJC
	tV2QkohsdY2+rRUWmi6Kar4Ay5Hk7uC/ZHG76TfrgbqO+lfnUaKvPdqnPb2quNjCLkQV
	DPJDFOAGZcyoibwG82l6xdi4cJqY1BLcKfe8t7oOTBWvGRWaLzvT0k0Azdc3HJIk6c08
	r+Sh884A9XpZayaFBgjPqO9HeCjd3WCxebdbLdY4BTJpvIjMjw8OAw9W4uBwNw4Mc69Z
	1DRQ==
Received: by 10.68.218.39 with SMTP id pd7mr32994663pbc.121.1350936913188;
	Mon, 22 Oct 2012 13:15:13 -0700 (PDT)
Received: from [10.128.0.122] (S0106001c25a066a0.vc.shawcable.net.
	[24.85.255.130])
	by mx.google.com with ESMTPS id j10sm6405982pax.4.2012.10.22.13.15.10
	(version=SSLv3 cipher=OTHER); Mon, 22 Oct 2012 13:15:12 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Mon, 22 Oct 2012 13:15:04 +0100
From: Keir Fraser 
To: Olaf Hering 
Message-ID: 
Thread-Topic: [Xen-devel] fixed location of share info page in HVM guests
Thread-Index: Ac2wkewDsV+KOK3ofUykiE4CsSozdw==
In-Reply-To: <20121022185036.GA15348@aepfle.de>
Mime-version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] fixed location of share info page in HVM guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 22/10/2012 19:50, "Olaf Hering"  wrote:

>> Okay, that was a bit too clever, trying to hide between IOAPIC and LAPIC
>> pages. How about a bit lower in memory -- FE700000-FE7FFFFF?
>> 
>> Everything in range FC000000-FFFFFFFF should already be marked
>> E820_RESERVED. You can test that, and also see
>> tools/firmware/hvmloader/e820.c:build_e820_table() (and note that
>> RESERVED_MEMBASE == FC000000).
>> 
>> Can document in hvmloader/config.h and have mem_alloc() test against it
>> rather than hvm_info->reserved_mem_pgstart.
> 
> I came up with this (perhaps whitespace damaged) change, the guest still boots
> ok.
> The asl part is just copy&paste from the HPET part.

Is there any point encoding this in the DSDT? I thought the guest OS needs
to access the shared info area earlier than it is able to decode the DSDT?

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 20:27:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 20:27:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQOaY-0003OZ-2V; Mon, 22 Oct 2012 20:27:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQOaV-0003OU-Mg
	for xen-devel@lists.xensource.com; Mon, 22 Oct 2012 20:27:04 +0000
Received: from [85.158.143.99:34099] by server-1.bemta-4.messagelabs.com id
	0B/68-19134-61CA5805; Mon, 22 Oct 2012 20:27:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1350937622!28108297!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUxNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9259 invoked from network); 22 Oct 2012 20:27:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 20:27:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,631,1344211200"; d="scan'208";a="15319273"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Oct 2012 20:27:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Mon, 22 Oct 2012 21:27:01 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TQOaT-0003Ol-Ls;
	Mon, 22 Oct 2012 20:27:01 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TQOaT-0008QZ-ED;
	Mon, 22 Oct 2012 21:27:01 +0100
To: 
Message-ID: 
From: xen.org 
Date: Mon, 22 Oct 2012 21:27:01 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14068: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14068 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14068/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 14067
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 14067
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 14067
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 14067

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  c69bcb248128
baseline version:
 xen                  478ba3f146df

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich 
  Olaf Hering 
  Tim Deegan 
  Wei Wang 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=c69bcb248128
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable c69bcb248128
+ branch=xen-unstable
+ revision=c69bcb248128
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r c69bcb248128 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 2 changesets with 5 changes to 4 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 20:27:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 20:27:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQOaY-0003OZ-2V; Mon, 22 Oct 2012 20:27:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQOaV-0003OU-Mg
	for xen-devel@lists.xensource.com; Mon, 22 Oct 2012 20:27:04 +0000
Received: from [85.158.143.99:34099] by server-1.bemta-4.messagelabs.com id
	0B/68-19134-61CA5805; Mon, 22 Oct 2012 20:27:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1350937622!28108297!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUxNjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9259 invoked from network); 22 Oct 2012 20:27:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Oct 2012 20:27:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,631,1344211200"; d="scan'208";a="15319273"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Oct 2012 20:27:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Mon, 22 Oct 2012 21:27:01 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TQOaT-0003Ol-Ls;
	Mon, 22 Oct 2012 20:27:01 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TQOaT-0008QZ-ED;
	Mon, 22 Oct 2012 21:27:01 +0100
To: 
Message-ID: 
From: xen.org 
Date: Mon, 22 Oct 2012 21:27:01 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14068: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14068 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14068/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 14067
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 14067
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 14067
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 14067

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  c69bcb248128
baseline version:
 xen                  478ba3f146df

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich 
  Olaf Hering 
  Tim Deegan 
  Wei Wang 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=c69bcb248128
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable c69bcb248128
+ branch=xen-unstable
+ revision=c69bcb248128
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r c69bcb248128 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 2 changesets with 5 changes to 4 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 20:27:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 20:27:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQOag-0003P9-EZ; Mon, 22 Oct 2012 20:27:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQOaf-0003P1-Bz
	for xen-devel@lists.xensource.com; Mon, 22 Oct 2012 20:27:13 +0000
Received: from [85.158.139.211:25949] by server-1.bemta-5.messagelabs.com id
	26/FC-21640-02CA5805; Mon, 22 Oct 2012 20:27:12 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1350937629!23232772!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7732 invoked from network); 22 Oct 2012 20:27:10 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Oct 2012 20:27:10 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9MKR0P3028304
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 22 Oct 2012 20:27:01 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9MKR08U011936
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 22 Oct 2012 20:27:00 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9MKQxf4023657; Mon, 22 Oct 2012 15:26:59 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 22 Oct 2012 13:26:59 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id BAB1B402E8; Mon, 22 Oct 2012 16:14:51 -0400 (EDT)
Date: Mon, 22 Oct 2012 16:14:51 -0400
From: Konrad Rzeszutek Wilk 
To: Mukesh Rathor 
Message-ID: <20121022201451.GJ25200@phenom.dumpdata.com>
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
	<1350695882-12820-3-git-send-email-konrad.wilk@oracle.com>
	
	<20121022113154.0e28ff1d@mantra.us.oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20121022113154.0e28ff1d@mantra.us.oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Ian Campbell ,
	"xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 2/6] xen/pvh: Extend vcpu_guest_context, p2m,
 event, and xenbus to support PVH.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 22, 2012 at 11:31:54AM -0700, Mukesh Rathor wrote:
> On Mon, 22 Oct 2012 14:44:40 +0100
> Stefano Stabellini  wrote:
> 
> > On Sat, 20 Oct 2012, Konrad Rzeszutek Wilk wrote:
> > > From: Mukesh Rathor 
> > > 
> > > make gdt_frames[]/gdt_ents into a union with {gdtaddr, gdtsz}, as
> > > PVH only needs to send down gdtaddr and gdtsz.
> > > 
> > > For interrupts, PVH uses native_irq_ops.
> > > vcpu hotplug is currently not available for PVH.
> > > 
> > > For events we follow what PVHVM does - to use callback vector.
> > > Lastly, also use HVM path to setup XenBus.
> > > 
> > > Signed-off-by: Mukesh Rathor 
> > > Signed-off-by: Konrad Rzeszutek Wilk 
> > > ---
> > >  		return true;
> > >  	}
> > > -	xen_copy_trap_info(ctxt->trap_ctxt);
> > > +	/* check for autoxlated to get it right for 32bit kernel */
> > 
> > I am not sure what this comment means, considering that in another
> > comment below you say that we don't support 32bit PVH kernels.
> 
> Function is common to both 32bit and 64bit kernels. We need to check 
> for auto xlated also in the if statement in addition to supervisor 
> mode kernel, so 32 bit doesn't go down the wrong path.

Can one just make it #ifdef CONFIG_X86_64 for the whole thing?
You are either way during bootup doing a 'BUG' when booting as 32-bit?


> 
> PVH is not supported for 32bit kernels, and gs_base_user doesn't exist
> in the structure for 32bit so it needs to be if'def'd 64bit which is
> ok because PVH is not supprted on 32bit kernel.
> 
> > > +					(unsigned
> > > long)xen_hypervisor_callback;
> > > +		ctxt->failsafe_callback_eip =
> > > +					(unsigned
> > > long)xen_failsafe_callback;
> > > +	}
> > > +	ctxt->user_regs.cs = __KERNEL_CS;
> > > +	ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct
> > > pt_regs); 
> > >  	per_cpu(xen_cr3, cpu) = __pa(swapper_pg_dir);
> > >  	ctxt->ctrlreg[3] =
> > > xen_pfn_to_cr3(virt_to_mfn(swapper_pg_dir));
> > 
> > The tradional path looks the same as before, however it is hard to
> > tell whether the PVH path is correct without the Xen side. For
> > example, what is gdtsz?
> 
> gdtsz is GUEST_GDTR_LIMIT and gdtaddr is GUEST_GDTR_BASE in the vmcs.

looking at this I figured it could be a bit neater. So I split it in
two patches which should make it easier to read the PVH one.


>From f9455e293169d73e5698df62801bcd5fd64a5259 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk 
Date: Mon, 22 Oct 2012 11:35:16 -0400
Subject: [PATCH 1/2] xen/smp: Move the common CPU init code a bit to prep for
 PVH patch.

The PV and PVH code CPU init code share some functionality. The
PVH code ("xen/pvh: Extend vcpu_guest_context, p2m, event, and XenBus")
sets some of these up, but not all. To make it easier to read, this
patch removes the PV specific out of the generic way.

No functional change, just code move.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/xen/smp.c |   42 +++++++++++++++++++++++-------------------
 1 files changed, 23 insertions(+), 19 deletions(-)

diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 353c50f..ba49a3a 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -300,8 +300,6 @@ cpu_initialize_context(unsigned int cpu, struct task_struct *idle)
 	gdt = get_cpu_gdt_table(cpu);
 
 	ctxt->flags = VGCF_IN_KERNEL;
-	ctxt->user_regs.ds = __USER_DS;
-	ctxt->user_regs.es = __USER_DS;
 	ctxt->user_regs.ss = __KERNEL_DS;
 #ifdef CONFIG_X86_32
 	ctxt->user_regs.fs = __KERNEL_PERCPU;
@@ -310,35 +308,41 @@ cpu_initialize_context(unsigned int cpu, struct task_struct *idle)
 	ctxt->gs_base_kernel = per_cpu_offset(cpu);
 #endif
 	ctxt->user_regs.eip = (unsigned long)cpu_bringup_and_idle;
-	ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
 
 	memset(&ctxt->fpu_ctxt, 0, sizeof(ctxt->fpu_ctxt));
 
-	xen_copy_trap_info(ctxt->trap_ctxt);
+	{
+		ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
+		ctxt->user_regs.ds = __USER_DS;
+		ctxt->user_regs.es = __USER_DS;
 
-	ctxt->ldt_ents = 0;
+		xen_copy_trap_info(ctxt->trap_ctxt);
 
-	BUG_ON((unsigned long)gdt & ~PAGE_MASK);
+		ctxt->ldt_ents = 0;
 
-	gdt_mfn = arbitrary_virt_to_mfn(gdt);
-	make_lowmem_page_readonly(gdt);
-	make_lowmem_page_readonly(mfn_to_virt(gdt_mfn));
+		BUG_ON((unsigned long)gdt & ~PAGE_MASK);
 
-	ctxt->gdt_frames[0] = gdt_mfn;
-	ctxt->gdt_ents      = GDT_ENTRIES;
+		gdt_mfn = arbitrary_virt_to_mfn(gdt);
+		make_lowmem_page_readonly(gdt);
+		make_lowmem_page_readonly(mfn_to_virt(gdt_mfn));
 
-	ctxt->user_regs.cs = __KERNEL_CS;
-	ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct pt_regs);
+		ctxt->u.pv.gdt_frames[0] = gdt_mfn;
+		ctxt->u.pv.gdt_ents      = GDT_ENTRIES;
 
-	ctxt->kernel_ss = __KERNEL_DS;
-	ctxt->kernel_sp = idle->thread.sp0;
+		ctxt->kernel_ss = __KERNEL_DS;
+		ctxt->kernel_sp = idle->thread.sp0;
 
 #ifdef CONFIG_X86_32
-	ctxt->event_callback_cs     = __KERNEL_CS;
-	ctxt->failsafe_callback_cs  = __KERNEL_CS;
+		ctxt->event_callback_cs     = __KERNEL_CS;
+		ctxt->failsafe_callback_cs  = __KERNEL_CS;
 #endif
-	ctxt->event_callback_eip    = (unsigned long)xen_hypervisor_callback;
-	ctxt->failsafe_callback_eip = (unsigned long)xen_failsafe_callback;
+		ctxt->event_callback_eip    =
+					(unsigned long)xen_hypervisor_callback;
+		ctxt->failsafe_callback_eip =
+					(unsigned long)xen_failsafe_callback;
+	}
+	ctxt->user_regs.cs = __KERNEL_CS;
+	ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct pt_regs);
 
 	per_cpu(xen_cr3, cpu) = __pa(swapper_pg_dir);
 	ctxt->ctrlreg[3] = xen_pfn_to_cr3(virt_to_mfn(swapper_pg_dir));
-- 
1.7.7.6




>From 2c4dd7f567b229451f3dc1ae00d784da8b4a5072 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk 
Date: Mon, 22 Oct 2012 11:37:57 -0400
Subject: [PATCH 2/2] xen/pvh: Extend vcpu_guest_context, p2m, event, and
 XenBus.

Make gdt_frames[]/gdt_ents into a union with {gdtaddr, gdtsz},
as PVH only needs to send down gdtaddr and gdtsz in the
vcpu_guest_context structure..

For interrupts, PVH uses native_irq_ops so we can skip most of the
PV ones. In the future we can support the pirq_eoi_map..
Also VCPU hotplug is currently not available for PVH.

For events (and IRQs) we follow what PVHVM does - so use callback
vector.  Lastly, for XenBus we use the same logic that is used in
the PVHVM case.

Signed-off-by: Mukesh Rathor 
[v2: Rebased it]
[v3: Move 64-bit ifdef and based on Stefan add extra comments.]
Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/include/asm/xen/interface.h |   11 +++++++++-
 arch/x86/xen/irq.c                   |    5 +++-
 arch/x86/xen/p2m.c                   |    2 +-
 arch/x86/xen/smp.c                   |   36 ++++++++++++++++++++++++++-------
 drivers/xen/cpu_hotplug.c            |    4 ++-
 drivers/xen/events.c                 |    9 +++++++-
 drivers/xen/xenbus/xenbus_client.c   |    3 +-
 7 files changed, 56 insertions(+), 14 deletions(-)

diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
index 6d2f75a..4c08f23 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -144,7 +144,16 @@ struct vcpu_guest_context {
     struct cpu_user_regs user_regs;         /* User-level CPU registers     */
     struct trap_info trap_ctxt[256];        /* Virtual IDT                  */
     unsigned long ldt_base, ldt_ents;       /* LDT (linear address, # ents) */
-    unsigned long gdt_frames[16], gdt_ents; /* GDT (machine frames, # ents) */
+    union {
+	struct {
+		/* PV: GDT (machine frames, # ents).*/
+		unsigned long gdt_frames[16], gdt_ents;
+	} pv;
+	struct {
+		/* PVH: GDTR addr and size */
+		unsigned long gdtaddr, gdtsz;
+	} pvh;
+    } u;
     unsigned long kernel_ss, kernel_sp;     /* Virtual TSS (only SS1/SP1)   */
     /* NB. User pagetable on x86/64 is placed in ctrlreg[1]. */
     unsigned long ctrlreg[8];               /* CR0-CR7 (control registers)  */
diff --git a/arch/x86/xen/irq.c b/arch/x86/xen/irq.c
index 01a4dc0..fcbe56a 100644
--- a/arch/x86/xen/irq.c
+++ b/arch/x86/xen/irq.c
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -129,6 +130,8 @@ static const struct pv_irq_ops xen_irq_ops __initconst = {
 
 void __init xen_init_irq_ops(void)
 {
-	pv_irq_ops = xen_irq_ops;
+	/* For PVH we use default pv_irq_ops settings */
+	if (!xen_feature(XENFEAT_hvm_callback_vector))
+		pv_irq_ops = xen_irq_ops;
 	x86_init.irqs.intr_init = xen_init_IRQ;
 }
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 95fb2aa..ea553c8 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -798,7 +798,7 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 {
 	unsigned topidx, mididx, idx;
 
-	if (unlikely(xen_feature(XENFEAT_auto_translated_physmap))) {
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
 		BUG_ON(pfn != mfn && mfn != INVALID_P2M_ENTRY);
 		return true;
 	}
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index ba49a3a..6f831a1 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -68,9 +68,11 @@ static void __cpuinit cpu_bringup(void)
 	touch_softlockup_watchdog();
 	preempt_disable();
 
-	xen_enable_sysenter();
-	xen_enable_syscall();
-
+	/* PVH runs in ring 0 and allows us to do native syscalls. Yay! */
+	if (!xen_feature(XENFEAT_supervisor_mode_kernel)) {
+		xen_enable_sysenter();
+		xen_enable_syscall();
+	}
 	cpu = smp_processor_id();
 	smp_store_cpu_info(cpu);
 	cpu_data(cpu).x86_max_cores = 1;
@@ -230,10 +232,11 @@ static void __init xen_smp_prepare_boot_cpu(void)
 	BUG_ON(smp_processor_id() != 0);
 	native_smp_prepare_boot_cpu();
 
-	/* We've switched to the "real" per-cpu gdt, so make sure the
-	   old memory can be recycled */
-	make_lowmem_page_readwrite(xen_initial_gdt);
-
+	if (!xen_feature(XENFEAT_writable_page_tables)) {
+		/* We've switched to the "real" per-cpu gdt, so make sure the
+		 * old memory can be recycled */
+		make_lowmem_page_readwrite(xen_initial_gdt);
+	}
 	xen_filter_cpu_maps();
 	xen_setup_vcpu_info_placement();
 }
@@ -311,7 +314,24 @@ cpu_initialize_context(unsigned int cpu, struct task_struct *idle)
 
 	memset(&ctxt->fpu_ctxt, 0, sizeof(ctxt->fpu_ctxt));
 
-	{
+	/* check for autoxlated to get it right for 32bit kernel */
+	if (xen_feature(XENFEAT_auto_translated_physmap) &&
+	    xen_feature(XENFEAT_supervisor_mode_kernel)) {
+#ifdef CONFIG_X86_64
+		ctxt->user_regs.ds = __KERNEL_DS;
+		ctxt->user_regs.es = 0;
+		ctxt->user_regs.gs = 0;
+
+		/* GUEST_GDTR_BASE and */
+		ctxt->u.pvh.gdtaddr = (unsigned long)gdt;
+		/* GUEST_GDTR_LIMIT in the VMCS. */
+		ctxt->u.pvh.gdtsz = (unsigned long)(GDT_SIZE - 1);
+
+		/* Note: PVH is not supported on x86_32. */
+		ctxt->gs_base_user = (unsigned long)
+					per_cpu(irq_stack_union.gs_base, cpu);
+#endif
+	} else {
 		ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
 		ctxt->user_regs.ds = __USER_DS;
 		ctxt->user_regs.es = __USER_DS;
diff --git a/drivers/xen/cpu_hotplug.c b/drivers/xen/cpu_hotplug.c
index 4dcfced..de6bcf9 100644
--- a/drivers/xen/cpu_hotplug.c
+++ b/drivers/xen/cpu_hotplug.c
@@ -2,6 +2,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -100,7 +101,8 @@ static int __init setup_vcpu_hotplug_event(void)
 	static struct notifier_block xsn_cpu = {
 		.notifier_call = setup_cpu_watcher };
 
-	if (!xen_pv_domain())
+	/* PVH TBD/FIXME: future work */
+	if (!xen_pv_domain() || xen_feature(XENFEAT_auto_translated_physmap))
 		return -ENODEV;
 
 	register_xenstore_notifier(&xsn_cpu);
diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 59e10a1..7131fdd 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -1774,7 +1774,7 @@ int xen_set_callback_via(uint64_t via)
 }
 EXPORT_SYMBOL_GPL(xen_set_callback_via);
 
-#ifdef CONFIG_XEN_PVHVM
+#ifdef CONFIG_X86
 /* Vector callbacks are better than PCI interrupts to receive event
  * channel notifications because we can receive vector callbacks on any
  * vcpu and we don't need PCI support or APIC interactions. */
@@ -1835,6 +1835,13 @@ void __init xen_init_IRQ(void)
 		if (xen_initial_domain())
 			pci_xen_initial_domain();
 
+		if (xen_feature(XENFEAT_hvm_callback_vector)) {
+			xen_callback_vector();
+			return;
+		}
+
+		/* PVH: TBD/FIXME: debug and fix eio map to work with pvh */
+
 		pirq_eoi_map = (void *)__get_free_page(GFP_KERNEL|__GFP_ZERO);
 		eoi_gmfn.gmfn = virt_to_mfn(pirq_eoi_map);
 		rc = HYPERVISOR_physdev_op(PHYSDEVOP_pirq_eoi_gmfn_v2, &eoi_gmfn);
diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
index bcf3ba4..356461e 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -44,6 +44,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "xenbus_probe.h"
 
@@ -741,7 +742,7 @@ static const struct xenbus_ring_ops ring_ops_hvm = {
 
 void __init xenbus_ring_ops_init(void)
 {
-	if (xen_pv_domain())
+	if (xen_pv_domain() && !xen_feature(XENFEAT_auto_translated_physmap))
 		ring_ops = &ring_ops_pv;
 	else
 		ring_ops = &ring_ops_hvm;
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 20:27:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 20:27:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQOag-0003P9-EZ; Mon, 22 Oct 2012 20:27:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQOaf-0003P1-Bz
	for xen-devel@lists.xensource.com; Mon, 22 Oct 2012 20:27:13 +0000
Received: from [85.158.139.211:25949] by server-1.bemta-5.messagelabs.com id
	26/FC-21640-02CA5805; Mon, 22 Oct 2012 20:27:12 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1350937629!23232772!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7732 invoked from network); 22 Oct 2012 20:27:10 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Oct 2012 20:27:10 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9MKR0P3028304
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 22 Oct 2012 20:27:01 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9MKR08U011936
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 22 Oct 2012 20:27:00 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9MKQxf4023657; Mon, 22 Oct 2012 15:26:59 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 22 Oct 2012 13:26:59 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id BAB1B402E8; Mon, 22 Oct 2012 16:14:51 -0400 (EDT)
Date: Mon, 22 Oct 2012 16:14:51 -0400
From: Konrad Rzeszutek Wilk 
To: Mukesh Rathor 
Message-ID: <20121022201451.GJ25200@phenom.dumpdata.com>
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
	<1350695882-12820-3-git-send-email-konrad.wilk@oracle.com>
	
	<20121022113154.0e28ff1d@mantra.us.oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20121022113154.0e28ff1d@mantra.us.oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Ian Campbell ,
	"xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 2/6] xen/pvh: Extend vcpu_guest_context, p2m,
 event, and xenbus to support PVH.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 22, 2012 at 11:31:54AM -0700, Mukesh Rathor wrote:
> On Mon, 22 Oct 2012 14:44:40 +0100
> Stefano Stabellini  wrote:
> 
> > On Sat, 20 Oct 2012, Konrad Rzeszutek Wilk wrote:
> > > From: Mukesh Rathor 
> > > 
> > > make gdt_frames[]/gdt_ents into a union with {gdtaddr, gdtsz}, as
> > > PVH only needs to send down gdtaddr and gdtsz.
> > > 
> > > For interrupts, PVH uses native_irq_ops.
> > > vcpu hotplug is currently not available for PVH.
> > > 
> > > For events we follow what PVHVM does - to use callback vector.
> > > Lastly, also use HVM path to setup XenBus.
> > > 
> > > Signed-off-by: Mukesh Rathor 
> > > Signed-off-by: Konrad Rzeszutek Wilk 
> > > ---
> > >  		return true;
> > >  	}
> > > -	xen_copy_trap_info(ctxt->trap_ctxt);
> > > +	/* check for autoxlated to get it right for 32bit kernel */
> > 
> > I am not sure what this comment means, considering that in another
> > comment below you say that we don't support 32bit PVH kernels.
> 
> Function is common to both 32bit and 64bit kernels. We need to check 
> for auto xlated also in the if statement in addition to supervisor 
> mode kernel, so 32 bit doesn't go down the wrong path.

Can one just make it #ifdef CONFIG_X86_64 for the whole thing?
You are either way during bootup doing a 'BUG' when booting as 32-bit?


> 
> PVH is not supported for 32bit kernels, and gs_base_user doesn't exist
> in the structure for 32bit so it needs to be if'def'd 64bit which is
> ok because PVH is not supprted on 32bit kernel.
> 
> > > +					(unsigned
> > > long)xen_hypervisor_callback;
> > > +		ctxt->failsafe_callback_eip =
> > > +					(unsigned
> > > long)xen_failsafe_callback;
> > > +	}
> > > +	ctxt->user_regs.cs = __KERNEL_CS;
> > > +	ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct
> > > pt_regs); 
> > >  	per_cpu(xen_cr3, cpu) = __pa(swapper_pg_dir);
> > >  	ctxt->ctrlreg[3] =
> > > xen_pfn_to_cr3(virt_to_mfn(swapper_pg_dir));
> > 
> > The tradional path looks the same as before, however it is hard to
> > tell whether the PVH path is correct without the Xen side. For
> > example, what is gdtsz?
> 
> gdtsz is GUEST_GDTR_LIMIT and gdtaddr is GUEST_GDTR_BASE in the vmcs.

looking at this I figured it could be a bit neater. So I split it in
two patches which should make it easier to read the PVH one.


>From f9455e293169d73e5698df62801bcd5fd64a5259 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk 
Date: Mon, 22 Oct 2012 11:35:16 -0400
Subject: [PATCH 1/2] xen/smp: Move the common CPU init code a bit to prep for
 PVH patch.

The PV and PVH code CPU init code share some functionality. The
PVH code ("xen/pvh: Extend vcpu_guest_context, p2m, event, and XenBus")
sets some of these up, but not all. To make it easier to read, this
patch removes the PV specific out of the generic way.

No functional change, just code move.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/xen/smp.c |   42 +++++++++++++++++++++++-------------------
 1 files changed, 23 insertions(+), 19 deletions(-)

diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 353c50f..ba49a3a 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -300,8 +300,6 @@ cpu_initialize_context(unsigned int cpu, struct task_struct *idle)
 	gdt = get_cpu_gdt_table(cpu);
 
 	ctxt->flags = VGCF_IN_KERNEL;
-	ctxt->user_regs.ds = __USER_DS;
-	ctxt->user_regs.es = __USER_DS;
 	ctxt->user_regs.ss = __KERNEL_DS;
 #ifdef CONFIG_X86_32
 	ctxt->user_regs.fs = __KERNEL_PERCPU;
@@ -310,35 +308,41 @@ cpu_initialize_context(unsigned int cpu, struct task_struct *idle)
 	ctxt->gs_base_kernel = per_cpu_offset(cpu);
 #endif
 	ctxt->user_regs.eip = (unsigned long)cpu_bringup_and_idle;
-	ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
 
 	memset(&ctxt->fpu_ctxt, 0, sizeof(ctxt->fpu_ctxt));
 
-	xen_copy_trap_info(ctxt->trap_ctxt);
+	{
+		ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
+		ctxt->user_regs.ds = __USER_DS;
+		ctxt->user_regs.es = __USER_DS;
 
-	ctxt->ldt_ents = 0;
+		xen_copy_trap_info(ctxt->trap_ctxt);
 
-	BUG_ON((unsigned long)gdt & ~PAGE_MASK);
+		ctxt->ldt_ents = 0;
 
-	gdt_mfn = arbitrary_virt_to_mfn(gdt);
-	make_lowmem_page_readonly(gdt);
-	make_lowmem_page_readonly(mfn_to_virt(gdt_mfn));
+		BUG_ON((unsigned long)gdt & ~PAGE_MASK);
 
-	ctxt->gdt_frames[0] = gdt_mfn;
-	ctxt->gdt_ents      = GDT_ENTRIES;
+		gdt_mfn = arbitrary_virt_to_mfn(gdt);
+		make_lowmem_page_readonly(gdt);
+		make_lowmem_page_readonly(mfn_to_virt(gdt_mfn));
 
-	ctxt->user_regs.cs = __KERNEL_CS;
-	ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct pt_regs);
+		ctxt->u.pv.gdt_frames[0] = gdt_mfn;
+		ctxt->u.pv.gdt_ents      = GDT_ENTRIES;
 
-	ctxt->kernel_ss = __KERNEL_DS;
-	ctxt->kernel_sp = idle->thread.sp0;
+		ctxt->kernel_ss = __KERNEL_DS;
+		ctxt->kernel_sp = idle->thread.sp0;
 
 #ifdef CONFIG_X86_32
-	ctxt->event_callback_cs     = __KERNEL_CS;
-	ctxt->failsafe_callback_cs  = __KERNEL_CS;
+		ctxt->event_callback_cs     = __KERNEL_CS;
+		ctxt->failsafe_callback_cs  = __KERNEL_CS;
 #endif
-	ctxt->event_callback_eip    = (unsigned long)xen_hypervisor_callback;
-	ctxt->failsafe_callback_eip = (unsigned long)xen_failsafe_callback;
+		ctxt->event_callback_eip    =
+					(unsigned long)xen_hypervisor_callback;
+		ctxt->failsafe_callback_eip =
+					(unsigned long)xen_failsafe_callback;
+	}
+	ctxt->user_regs.cs = __KERNEL_CS;
+	ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct pt_regs);
 
 	per_cpu(xen_cr3, cpu) = __pa(swapper_pg_dir);
 	ctxt->ctrlreg[3] = xen_pfn_to_cr3(virt_to_mfn(swapper_pg_dir));
-- 
1.7.7.6




>From 2c4dd7f567b229451f3dc1ae00d784da8b4a5072 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk 
Date: Mon, 22 Oct 2012 11:37:57 -0400
Subject: [PATCH 2/2] xen/pvh: Extend vcpu_guest_context, p2m, event, and
 XenBus.

Make gdt_frames[]/gdt_ents into a union with {gdtaddr, gdtsz},
as PVH only needs to send down gdtaddr and gdtsz in the
vcpu_guest_context structure..

For interrupts, PVH uses native_irq_ops so we can skip most of the
PV ones. In the future we can support the pirq_eoi_map..
Also VCPU hotplug is currently not available for PVH.

For events (and IRQs) we follow what PVHVM does - so use callback
vector.  Lastly, for XenBus we use the same logic that is used in
the PVHVM case.

Signed-off-by: Mukesh Rathor 
[v2: Rebased it]
[v3: Move 64-bit ifdef and based on Stefan add extra comments.]
Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/include/asm/xen/interface.h |   11 +++++++++-
 arch/x86/xen/irq.c                   |    5 +++-
 arch/x86/xen/p2m.c                   |    2 +-
 arch/x86/xen/smp.c                   |   36 ++++++++++++++++++++++++++-------
 drivers/xen/cpu_hotplug.c            |    4 ++-
 drivers/xen/events.c                 |    9 +++++++-
 drivers/xen/xenbus/xenbus_client.c   |    3 +-
 7 files changed, 56 insertions(+), 14 deletions(-)

diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
index 6d2f75a..4c08f23 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -144,7 +144,16 @@ struct vcpu_guest_context {
     struct cpu_user_regs user_regs;         /* User-level CPU registers     */
     struct trap_info trap_ctxt[256];        /* Virtual IDT                  */
     unsigned long ldt_base, ldt_ents;       /* LDT (linear address, # ents) */
-    unsigned long gdt_frames[16], gdt_ents; /* GDT (machine frames, # ents) */
+    union {
+	struct {
+		/* PV: GDT (machine frames, # ents).*/
+		unsigned long gdt_frames[16], gdt_ents;
+	} pv;
+	struct {
+		/* PVH: GDTR addr and size */
+		unsigned long gdtaddr, gdtsz;
+	} pvh;
+    } u;
     unsigned long kernel_ss, kernel_sp;     /* Virtual TSS (only SS1/SP1)   */
     /* NB. User pagetable on x86/64 is placed in ctrlreg[1]. */
     unsigned long ctrlreg[8];               /* CR0-CR7 (control registers)  */
diff --git a/arch/x86/xen/irq.c b/arch/x86/xen/irq.c
index 01a4dc0..fcbe56a 100644
--- a/arch/x86/xen/irq.c
+++ b/arch/x86/xen/irq.c
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -129,6 +130,8 @@ static const struct pv_irq_ops xen_irq_ops __initconst = {
 
 void __init xen_init_irq_ops(void)
 {
-	pv_irq_ops = xen_irq_ops;
+	/* For PVH we use default pv_irq_ops settings */
+	if (!xen_feature(XENFEAT_hvm_callback_vector))
+		pv_irq_ops = xen_irq_ops;
 	x86_init.irqs.intr_init = xen_init_IRQ;
 }
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 95fb2aa..ea553c8 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -798,7 +798,7 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 {
 	unsigned topidx, mididx, idx;
 
-	if (unlikely(xen_feature(XENFEAT_auto_translated_physmap))) {
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
 		BUG_ON(pfn != mfn && mfn != INVALID_P2M_ENTRY);
 		return true;
 	}
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index ba49a3a..6f831a1 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -68,9 +68,11 @@ static void __cpuinit cpu_bringup(void)
 	touch_softlockup_watchdog();
 	preempt_disable();
 
-	xen_enable_sysenter();
-	xen_enable_syscall();
-
+	/* PVH runs in ring 0 and allows us to do native syscalls. Yay! */
+	if (!xen_feature(XENFEAT_supervisor_mode_kernel)) {
+		xen_enable_sysenter();
+		xen_enable_syscall();
+	}
 	cpu = smp_processor_id();
 	smp_store_cpu_info(cpu);
 	cpu_data(cpu).x86_max_cores = 1;
@@ -230,10 +232,11 @@ static void __init xen_smp_prepare_boot_cpu(void)
 	BUG_ON(smp_processor_id() != 0);
 	native_smp_prepare_boot_cpu();
 
-	/* We've switched to the "real" per-cpu gdt, so make sure the
-	   old memory can be recycled */
-	make_lowmem_page_readwrite(xen_initial_gdt);
-
+	if (!xen_feature(XENFEAT_writable_page_tables)) {
+		/* We've switched to the "real" per-cpu gdt, so make sure the
+		 * old memory can be recycled */
+		make_lowmem_page_readwrite(xen_initial_gdt);
+	}
 	xen_filter_cpu_maps();
 	xen_setup_vcpu_info_placement();
 }
@@ -311,7 +314,24 @@ cpu_initialize_context(unsigned int cpu, struct task_struct *idle)
 
 	memset(&ctxt->fpu_ctxt, 0, sizeof(ctxt->fpu_ctxt));
 
-	{
+	/* check for autoxlated to get it right for 32bit kernel */
+	if (xen_feature(XENFEAT_auto_translated_physmap) &&
+	    xen_feature(XENFEAT_supervisor_mode_kernel)) {
+#ifdef CONFIG_X86_64
+		ctxt->user_regs.ds = __KERNEL_DS;
+		ctxt->user_regs.es = 0;
+		ctxt->user_regs.gs = 0;
+
+		/* GUEST_GDTR_BASE and */
+		ctxt->u.pvh.gdtaddr = (unsigned long)gdt;
+		/* GUEST_GDTR_LIMIT in the VMCS. */
+		ctxt->u.pvh.gdtsz = (unsigned long)(GDT_SIZE - 1);
+
+		/* Note: PVH is not supported on x86_32. */
+		ctxt->gs_base_user = (unsigned long)
+					per_cpu(irq_stack_union.gs_base, cpu);
+#endif
+	} else {
 		ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
 		ctxt->user_regs.ds = __USER_DS;
 		ctxt->user_regs.es = __USER_DS;
diff --git a/drivers/xen/cpu_hotplug.c b/drivers/xen/cpu_hotplug.c
index 4dcfced..de6bcf9 100644
--- a/drivers/xen/cpu_hotplug.c
+++ b/drivers/xen/cpu_hotplug.c
@@ -2,6 +2,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -100,7 +101,8 @@ static int __init setup_vcpu_hotplug_event(void)
 	static struct notifier_block xsn_cpu = {
 		.notifier_call = setup_cpu_watcher };
 
-	if (!xen_pv_domain())
+	/* PVH TBD/FIXME: future work */
+	if (!xen_pv_domain() || xen_feature(XENFEAT_auto_translated_physmap))
 		return -ENODEV;
 
 	register_xenstore_notifier(&xsn_cpu);
diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 59e10a1..7131fdd 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -1774,7 +1774,7 @@ int xen_set_callback_via(uint64_t via)
 }
 EXPORT_SYMBOL_GPL(xen_set_callback_via);
 
-#ifdef CONFIG_XEN_PVHVM
+#ifdef CONFIG_X86
 /* Vector callbacks are better than PCI interrupts to receive event
  * channel notifications because we can receive vector callbacks on any
  * vcpu and we don't need PCI support or APIC interactions. */
@@ -1835,6 +1835,13 @@ void __init xen_init_IRQ(void)
 		if (xen_initial_domain())
 			pci_xen_initial_domain();
 
+		if (xen_feature(XENFEAT_hvm_callback_vector)) {
+			xen_callback_vector();
+			return;
+		}
+
+		/* PVH: TBD/FIXME: debug and fix eio map to work with pvh */
+
 		pirq_eoi_map = (void *)__get_free_page(GFP_KERNEL|__GFP_ZERO);
 		eoi_gmfn.gmfn = virt_to_mfn(pirq_eoi_map);
 		rc = HYPERVISOR_physdev_op(PHYSDEVOP_pirq_eoi_gmfn_v2, &eoi_gmfn);
diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
index bcf3ba4..356461e 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -44,6 +44,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "xenbus_probe.h"
 
@@ -741,7 +742,7 @@ static const struct xenbus_ring_ops ring_ops_hvm = {
 
 void __init xenbus_ring_ops_init(void)
 {
-	if (xen_pv_domain())
+	if (xen_pv_domain() && !xen_feature(XENFEAT_auto_translated_physmap))
 		ring_ops = &ring_ops_pv;
 	else
 		ring_ops = &ring_ops_hvm;
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 20:40:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 20:40:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQOmn-0003oz-2E; Mon, 22 Oct 2012 20:39:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQOml-0003ou-1y
	for xen-devel@lists.xensource.com; Mon, 22 Oct 2012 20:39:43 +0000
Received: from [85.158.137.99:58085] by server-4.bemta-3.messagelabs.com id
	D6/A3-01405-D0FA5805; Mon, 22 Oct 2012 20:39:41 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1350938379!17536251!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODE4Nzcz\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16433 invoked from network); 22 Oct 2012 20:39:41 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Oct 2012 20:39:41 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9MKdYq4029398
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 22 Oct 2012 20:39:35 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9MKdXIv029046
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 22 Oct 2012 20:39:33 GMT
Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9MKdWKq006768; Mon, 22 Oct 2012 15:39:32 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 22 Oct 2012 13:39:32 -0700
Date: Mon, 22 Oct 2012 13:39:31 -0700
From: Mukesh Rathor 
To: Konrad Rzeszutek Wilk 
Message-ID: <20121022133931.1d4750a1@mantra.us.oracle.com>
In-Reply-To: <20121022201451.GJ25200@phenom.dumpdata.com>
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
	<1350695882-12820-3-git-send-email-konrad.wilk@oracle.com>
	
	<20121022113154.0e28ff1d@mantra.us.oracle.com>
	<20121022201451.GJ25200@phenom.dumpdata.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Ian Campbell ,
	"xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 2/6] xen/pvh: Extend vcpu_guest_context, p2m,
 event, and xenbus to support PVH.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 22 Oct 2012 16:14:51 -0400
Konrad Rzeszutek Wilk  wrote:

> On Mon, Oct 22, 2012 at 11:31:54AM -0700, Mukesh Rathor wrote:
> > On Mon, 22 Oct 2012 14:44:40 +0100
> > Stefano Stabellini  wrote:
> > 
> > > On Sat, 20 Oct 2012, Konrad Rzeszutek Wilk wrote:
> > > > From: Mukesh Rathor 
> > > > 
> > > > make gdt_frames[]/gdt_ents into a union with {gdtaddr, gdtsz},
> > > > as PVH only needs to send down gdtaddr and gdtsz.
> > > > 
> > > > For interrupts, PVH uses native_irq_ops.
> > > > vcpu hotplug is currently not available for PVH.
> > > > 
> > > > For events we follow what PVHVM does - to use callback vector.
> > > > Lastly, also use HVM path to setup XenBus.
> > > > 
> > > > Signed-off-by: Mukesh Rathor 
> > > > Signed-off-by: Konrad Rzeszutek Wilk 
> > > > ---
> > > >  		return true;
> > > >  	}
> > > > -	xen_copy_trap_info(ctxt->trap_ctxt);
> > > > +	/* check for autoxlated to get it right for 32bit
> > > > kernel */
> > > 
> > > I am not sure what this comment means, considering that in another
> > > comment below you say that we don't support 32bit PVH kernels.
> > 
> > Function is common to both 32bit and 64bit kernels. We need to
> > check for auto xlated also in the if statement in addition to
> > supervisor mode kernel, so 32 bit doesn't go down the wrong path.
> 
> Can one just make it #ifdef CONFIG_X86_64 for the whole thing?
> You are either way during bootup doing a 'BUG' when booting as 32-bit?

32bit pure pv, ie, pv mmu, path. BUG() is for 32bit PVH. 
Sure we could ifdef whole thing, but then we'd have to add more ifdef's
around else, closing else, etc.. I"m ok with whatever works for you.

thanks
mukesh




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 22 20:40:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 22 Oct 2012 20:40:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQOmn-0003oz-2E; Mon, 22 Oct 2012 20:39:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQOml-0003ou-1y
	for xen-devel@lists.xensource.com; Mon, 22 Oct 2012 20:39:43 +0000
Received: from [85.158.137.99:58085] by server-4.bemta-3.messagelabs.com id
	D6/A3-01405-D0FA5805; Mon, 22 Oct 2012 20:39:41 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1350938379!17536251!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODE4Nzcz\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16433 invoked from network); 22 Oct 2012 20:39:41 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Oct 2012 20:39:41 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9MKdYq4029398
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 22 Oct 2012 20:39:35 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9MKdXIv029046
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 22 Oct 2012 20:39:33 GMT
Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9MKdWKq006768; Mon, 22 Oct 2012 15:39:32 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 22 Oct 2012 13:39:32 -0700
Date: Mon, 22 Oct 2012 13:39:31 -0700
From: Mukesh Rathor 
To: Konrad Rzeszutek Wilk 
Message-ID: <20121022133931.1d4750a1@mantra.us.oracle.com>
In-Reply-To: <20121022201451.GJ25200@phenom.dumpdata.com>
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
	<1350695882-12820-3-git-send-email-konrad.wilk@oracle.com>
	
	<20121022113154.0e28ff1d@mantra.us.oracle.com>
	<20121022201451.GJ25200@phenom.dumpdata.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Ian Campbell ,
	"xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 2/6] xen/pvh: Extend vcpu_guest_context, p2m,
 event, and xenbus to support PVH.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 22 Oct 2012 16:14:51 -0400
Konrad Rzeszutek Wilk  wrote:

> On Mon, Oct 22, 2012 at 11:31:54AM -0700, Mukesh Rathor wrote:
> > On Mon, 22 Oct 2012 14:44:40 +0100
> > Stefano Stabellini  wrote:
> > 
> > > On Sat, 20 Oct 2012, Konrad Rzeszutek Wilk wrote:
> > > > From: Mukesh Rathor 
> > > > 
> > > > make gdt_frames[]/gdt_ents into a union with {gdtaddr, gdtsz},
> > > > as PVH only needs to send down gdtaddr and gdtsz.
> > > > 
> > > > For interrupts, PVH uses native_irq_ops.
> > > > vcpu hotplug is currently not available for PVH.
> > > > 
> > > > For events we follow what PVHVM does - to use callback vector.
> > > > Lastly, also use HVM path to setup XenBus.
> > > > 
> > > > Signed-off-by: Mukesh Rathor 
> > > > Signed-off-by: Konrad Rzeszutek Wilk 
> > > > ---
> > > >  		return true;
> > > >  	}
> > > > -	xen_copy_trap_info(ctxt->trap_ctxt);
> > > > +	/* check for autoxlated to get it right for 32bit
> > > > kernel */
> > > 
> > > I am not sure what this comment means, considering that in another
> > > comment below you say that we don't support 32bit PVH kernels.
> > 
> > Function is common to both 32bit and 64bit kernels. We need to
> > check for auto xlated also in the if statement in addition to
> > supervisor mode kernel, so 32 bit doesn't go down the wrong path.
> 
> Can one just make it #ifdef CONFIG_X86_64 for the whole thing?
> You are either way during bootup doing a 'BUG' when booting as 32-bit?

32bit pure pv, ie, pv mmu, path. BUG() is for 32bit PVH. 
Sure we could ifdef whole thing, but then we'd have to add more ifdef's
around else, closing else, etc.. I"m ok with whatever works for you.

thanks
mukesh




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 05:09:15 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 05:09:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQWjD-0002g0-4x; Tue, 23 Oct 2012 05:08:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQWjB-0002fv-Hv
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 05:08:33 +0000
Received: from [85.158.137.99:53240] by server-11.bemta-3.messagelabs.com id
	37/86-24008-05626805; Tue, 23 Oct 2012 05:08:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1350968912!20252433!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUxNDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27769 invoked from network); 23 Oct 2012 05:08:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 05:08:32 -0000
X-IronPort-AV: E=Sophos;i="4.80,633,1344211200"; d="scan'208";a="15322904"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Oct 2012 05:08:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 23 Oct 2012 06:08:30 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TQWj8-0006Mr-Ld;
	Tue, 23 Oct 2012 05:08:30 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TQWj8-0002bH-GW;
	Tue, 23 Oct 2012 06:08:30 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Tue, 23 Oct 2012 06:08:30 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14069: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14069 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14069/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 14068
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 14068
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 14068
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 14068

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  c69bcb248128
baseline version:
 xen                  c69bcb248128

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 05:09:15 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 05:09:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQWjD-0002g0-4x; Tue, 23 Oct 2012 05:08:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQWjB-0002fv-Hv
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 05:08:33 +0000
Received: from [85.158.137.99:53240] by server-11.bemta-3.messagelabs.com id
	37/86-24008-05626805; Tue, 23 Oct 2012 05:08:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1350968912!20252433!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUxNDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27769 invoked from network); 23 Oct 2012 05:08:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 05:08:32 -0000
X-IronPort-AV: E=Sophos;i="4.80,633,1344211200"; d="scan'208";a="15322904"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Oct 2012 05:08:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 23 Oct 2012 06:08:30 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TQWj8-0006Mr-Ld;
	Tue, 23 Oct 2012 05:08:30 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TQWj8-0002bH-GW;
	Tue, 23 Oct 2012 06:08:30 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Tue, 23 Oct 2012 06:08:30 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14069: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14069 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14069/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 14068
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 14068
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 14068
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 14068

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  c69bcb248128
baseline version:
 xen                  c69bcb248128

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 07:17:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 07:17:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQYit-0003SM-GN; Tue, 23 Oct 2012 07:16:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQYir-0003SH-DY
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 07:16:21 +0000
Received: from [85.158.139.211:49507] by server-8.bemta-5.messagelabs.com id
	78/DA-23193-44446805; Tue, 23 Oct 2012 07:16:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1350976580!21834695!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13183 invoked from network); 23 Oct 2012 07:16:20 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-206.messagelabs.com with SMTP;
	23 Oct 2012 07:16:20 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 23 Oct 2012 08:16:19 +0100
Message-Id: <5086606002000078000A3543@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 23 Oct 2012 08:16:16 +0100
From: "Jan Beulich" 
To: "Olaf Hering" ,"Tim Deegan" 
References: <8ebe7b80f02900d5a83e.1350655780@probook.site>
	<20121022152256.GH12577@ocelot.phlegethon.org>
	<20121022153333.GA27414@aepfle.de>
	<20121022161333.GL12577@ocelot.phlegethon.org>
In-Reply-To: <20121022161333.GL12577@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] hvm: handle PoD and grant pages in
 HVMOP_get_mem_type
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 22.10.12 at 18:13, Tim Deegan  wrote:
> At 17:33 +0200 on 22 Oct (1350927213), Olaf Hering wrote:
>> On Mon, Oct 22, Tim Deegan wrote:
>> 
>> > At 16:09 +0200 on 19 Oct (1350662980), Olaf Hering wrote:
>> > > hvm: handle PoD and grant pages in HVMOP_get_mem_type
>> > > 
>> > > During kexec in a ballooned PVonHVM guest the new kernel needs to check
>> > > each pfn if its backed by a mfn to find ballooned pages. Currently all
>> > > PoD and grant pages will appear as HVMMEM_mmio_dm, so the new kernel has
>> > > to assume they are ballooned. This is wrong: PoD pages may turn into
>> > > real RAM at runtime, grant pages are also RAM.
>> > > 
>> > > Signed-off-by: Olaf Hering 
>> > 
>> > Applied, thanks.
>> 
>> Would you backport this to 4.2 and 4.1?
> 
> Actually, I don't handle backports.  IIRC Jan owns 4.2-testing and Keir
> 4.1-testing; I've CC'd them both.

Actually, I handle both and will take care of it within the next few
days (hopefully before the end of the week).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 07:17:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 07:17:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQYit-0003SM-GN; Tue, 23 Oct 2012 07:16:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQYir-0003SH-DY
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 07:16:21 +0000
Received: from [85.158.139.211:49507] by server-8.bemta-5.messagelabs.com id
	78/DA-23193-44446805; Tue, 23 Oct 2012 07:16:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1350976580!21834695!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13183 invoked from network); 23 Oct 2012 07:16:20 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-206.messagelabs.com with SMTP;
	23 Oct 2012 07:16:20 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 23 Oct 2012 08:16:19 +0100
Message-Id: <5086606002000078000A3543@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 23 Oct 2012 08:16:16 +0100
From: "Jan Beulich" 
To: "Olaf Hering" ,"Tim Deegan" 
References: <8ebe7b80f02900d5a83e.1350655780@probook.site>
	<20121022152256.GH12577@ocelot.phlegethon.org>
	<20121022153333.GA27414@aepfle.de>
	<20121022161333.GL12577@ocelot.phlegethon.org>
In-Reply-To: <20121022161333.GL12577@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] hvm: handle PoD and grant pages in
 HVMOP_get_mem_type
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 22.10.12 at 18:13, Tim Deegan  wrote:
> At 17:33 +0200 on 22 Oct (1350927213), Olaf Hering wrote:
>> On Mon, Oct 22, Tim Deegan wrote:
>> 
>> > At 16:09 +0200 on 19 Oct (1350662980), Olaf Hering wrote:
>> > > hvm: handle PoD and grant pages in HVMOP_get_mem_type
>> > > 
>> > > During kexec in a ballooned PVonHVM guest the new kernel needs to check
>> > > each pfn if its backed by a mfn to find ballooned pages. Currently all
>> > > PoD and grant pages will appear as HVMMEM_mmio_dm, so the new kernel has
>> > > to assume they are ballooned. This is wrong: PoD pages may turn into
>> > > real RAM at runtime, grant pages are also RAM.
>> > > 
>> > > Signed-off-by: Olaf Hering 
>> > 
>> > Applied, thanks.
>> 
>> Would you backport this to 4.2 and 4.1?
> 
> Actually, I don't handle backports.  IIRC Jan owns 4.2-testing and Keir
> 4.1-testing; I've CC'd them both.

Actually, I handle both and will take care of it within the next few
days (hopefully before the end of the week).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 07:35:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 07:35:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQZ0f-0003g8-22; Tue, 23 Oct 2012 07:34:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQZ0c-0003g3-Sk
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 07:34:43 +0000
Received: from [85.158.143.99:10002] by server-3.bemta-4.messagelabs.com id
	C9/B7-03544-29846805; Tue, 23 Oct 2012 07:34:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1350977681!35191209!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11312 invoked from network); 23 Oct 2012 07:34:41 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-216.messagelabs.com with SMTP;
	23 Oct 2012 07:34:41 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 23 Oct 2012 08:34:40 +0100
Message-Id: <508664AE02000078000A3556@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 23 Oct 2012 08:34:38 +0100
From: "Jan Beulich" 
To: "Olaf Hering" 
References: <20120828082302.GA27309@aepfle.de>
	 <20121022185036.GA15348@aepfle.de>
In-Reply-To: <20121022185036.GA15348@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] fixed location of share info page in HVM guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 22.10.12 at 20:50, Olaf Hering  wrote:
> I came up with this (perhaps whitespace damaged) change, the guest still 
> boots ok.
> The asl part is just copy&paste from the HPET part.

... and, pending a response to Keir's question on its need in the
first place, need to be fixed:

> --- xen-4.2.0-testing.orig/tools/firmware/hvmloader/acpi/dsdt.asl
> +++ xen-4.2.0-testing/tools/firmware/hvmloader/acpi/dsdt.asl
> @@ -50,6 +50,7 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2,
>             UAR1, 1,
>             UAR2, 1,
>             LTP1, 1,
> +           XENR, 1,
>             HPET, 1,

This gets things out of sync with build.c's struct acpi_info. Which
raises the question whether, even if the below is needed, this
change is necessary.

>             Offset(4),
>             PMIN, 32,
> @@ -166,6 +167,28 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2,
>                  Return (PRT0)
>              }
> 
> +            Device(XENR) {
> +                Name(_UID, 0)
> +                Method (_STA, 0, NotSerialized) {
> +                    If(LEqual(\_SB.XENR, 0)) {
> +                        Return(0x00)
> +                    } Else {
> +                        Return(0x0F)
> +                    }

Especially with the missing build.c change, this ought to be
unconditionally returning 0x0F or get dropped (depending on
whether _STA is required, which I don't recall off the top of my
head, but looking at other device declarations it doesn't look
like so).

Jan

> +                }
> +                Name(_CRS, ResourceTemplate() {
> +                    DWordMemory(
> +                        ResourceConsumer, PosDecode, MinFixed, MaxFixed,
> +                        NonCacheable, ReadWrite,
> +                        0x00000000,
> +                        0xFE700000,
> +                        0xFE7FFFFF,
> +                        0x00000000,
> +                        0x00100000 /* 1M memory: FE700000 - FE7FFFFF */
> +                    )
> +                })
> +            }
> +
>              Device(HPET) {
>                  Name(_HID,  EISAID("PNP0103"))
>                  Name(_UID, 0)
> Index: xen-4.2.0-testing/tools/firmware/hvmloader/config.h
> ===================================================================
> --- xen-4.2.0-testing.orig/tools/firmware/hvmloader/config.h
> +++ xen-4.2.0-testing/tools/firmware/hvmloader/config.h
> @@ -66,6 +66,8 @@ extern unsigned long pci_mem_start, pci_
>  /* NB. ACPI_INFO_PHYSICAL_ADDRESS *MUST* match definition in acpi/dsdt.asl! 
> */
>  #define ACPI_INFO_PHYSICAL_ADDRESS    0xFC000000
>  #define RESERVED_MEMORY_DYNAMIC       0xFC001000
> +#define HVM_SHARED_INFO_AREA          0xFE700000
> +#define HVM_SHARED_INFO_SIZE          0x00100000
> 
>  extern unsigned long scratch_start;
> 
> Index: xen-4.2.0-testing/tools/firmware/hvmloader/util.c
> ===================================================================
> --- xen-4.2.0-testing.orig/tools/firmware/hvmloader/util.c
> +++ xen-4.2.0-testing/tools/firmware/hvmloader/util.c
> @@ -433,11 +433,19 @@ void *mem_alloc(uint32_t size, uint32_t
>      if ( align < 16 )
>          align = 16;
> 
> +retry:
>      s = (reserve + align) & ~(align - 1);
>      e = s + size - 1;
> 
>      BUG_ON((e < s) || (e >> PAGE_SHIFT) >= hvm_info->reserved_mem_pgstart);
> 
> +    /* Skip the shared info region */
> +    if (s <= HVM_SHARED_INFO_AREA && e >= HVM_SHARED_INFO_AREA) {
> +           printf("%s: skipping HVM_SHARED_INFO_AREA: s %08x e %08x r 
> %08x", __func__, s, e, reserve);
> +           reserve = HVM_SHARED_INFO_AREA + HVM_SHARED_INFO_SIZE - 1;
> +           goto retry;
> +    }
> +
>      while ( (reserve >> PAGE_SHIFT) != (e >> PAGE_SHIFT) )
>      {
>          reserve += PAGE_SIZE;
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 07:35:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 07:35:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQZ0f-0003g8-22; Tue, 23 Oct 2012 07:34:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQZ0c-0003g3-Sk
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 07:34:43 +0000
Received: from [85.158.143.99:10002] by server-3.bemta-4.messagelabs.com id
	C9/B7-03544-29846805; Tue, 23 Oct 2012 07:34:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1350977681!35191209!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11312 invoked from network); 23 Oct 2012 07:34:41 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-216.messagelabs.com with SMTP;
	23 Oct 2012 07:34:41 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 23 Oct 2012 08:34:40 +0100
Message-Id: <508664AE02000078000A3556@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 23 Oct 2012 08:34:38 +0100
From: "Jan Beulich" 
To: "Olaf Hering" 
References: <20120828082302.GA27309@aepfle.de>
	 <20121022185036.GA15348@aepfle.de>
In-Reply-To: <20121022185036.GA15348@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] fixed location of share info page in HVM guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 22.10.12 at 20:50, Olaf Hering  wrote:
> I came up with this (perhaps whitespace damaged) change, the guest still 
> boots ok.
> The asl part is just copy&paste from the HPET part.

... and, pending a response to Keir's question on its need in the
first place, need to be fixed:

> --- xen-4.2.0-testing.orig/tools/firmware/hvmloader/acpi/dsdt.asl
> +++ xen-4.2.0-testing/tools/firmware/hvmloader/acpi/dsdt.asl
> @@ -50,6 +50,7 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2,
>             UAR1, 1,
>             UAR2, 1,
>             LTP1, 1,
> +           XENR, 1,
>             HPET, 1,

This gets things out of sync with build.c's struct acpi_info. Which
raises the question whether, even if the below is needed, this
change is necessary.

>             Offset(4),
>             PMIN, 32,
> @@ -166,6 +167,28 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2,
>                  Return (PRT0)
>              }
> 
> +            Device(XENR) {
> +                Name(_UID, 0)
> +                Method (_STA, 0, NotSerialized) {
> +                    If(LEqual(\_SB.XENR, 0)) {
> +                        Return(0x00)
> +                    } Else {
> +                        Return(0x0F)
> +                    }

Especially with the missing build.c change, this ought to be
unconditionally returning 0x0F or get dropped (depending on
whether _STA is required, which I don't recall off the top of my
head, but looking at other device declarations it doesn't look
like so).

Jan

> +                }
> +                Name(_CRS, ResourceTemplate() {
> +                    DWordMemory(
> +                        ResourceConsumer, PosDecode, MinFixed, MaxFixed,
> +                        NonCacheable, ReadWrite,
> +                        0x00000000,
> +                        0xFE700000,
> +                        0xFE7FFFFF,
> +                        0x00000000,
> +                        0x00100000 /* 1M memory: FE700000 - FE7FFFFF */
> +                    )
> +                })
> +            }
> +
>              Device(HPET) {
>                  Name(_HID,  EISAID("PNP0103"))
>                  Name(_UID, 0)
> Index: xen-4.2.0-testing/tools/firmware/hvmloader/config.h
> ===================================================================
> --- xen-4.2.0-testing.orig/tools/firmware/hvmloader/config.h
> +++ xen-4.2.0-testing/tools/firmware/hvmloader/config.h
> @@ -66,6 +66,8 @@ extern unsigned long pci_mem_start, pci_
>  /* NB. ACPI_INFO_PHYSICAL_ADDRESS *MUST* match definition in acpi/dsdt.asl! 
> */
>  #define ACPI_INFO_PHYSICAL_ADDRESS    0xFC000000
>  #define RESERVED_MEMORY_DYNAMIC       0xFC001000
> +#define HVM_SHARED_INFO_AREA          0xFE700000
> +#define HVM_SHARED_INFO_SIZE          0x00100000
> 
>  extern unsigned long scratch_start;
> 
> Index: xen-4.2.0-testing/tools/firmware/hvmloader/util.c
> ===================================================================
> --- xen-4.2.0-testing.orig/tools/firmware/hvmloader/util.c
> +++ xen-4.2.0-testing/tools/firmware/hvmloader/util.c
> @@ -433,11 +433,19 @@ void *mem_alloc(uint32_t size, uint32_t
>      if ( align < 16 )
>          align = 16;
> 
> +retry:
>      s = (reserve + align) & ~(align - 1);
>      e = s + size - 1;
> 
>      BUG_ON((e < s) || (e >> PAGE_SHIFT) >= hvm_info->reserved_mem_pgstart);
> 
> +    /* Skip the shared info region */
> +    if (s <= HVM_SHARED_INFO_AREA && e >= HVM_SHARED_INFO_AREA) {
> +           printf("%s: skipping HVM_SHARED_INFO_AREA: s %08x e %08x r 
> %08x", __func__, s, e, reserve);
> +           reserve = HVM_SHARED_INFO_AREA + HVM_SHARED_INFO_SIZE - 1;
> +           goto retry;
> +    }
> +
>      while ( (reserve >> PAGE_SHIFT) != (e >> PAGE_SHIFT) )
>      {
>          reserve += PAGE_SIZE;
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 07:58:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 07:58:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQZNJ-0003qm-5N; Tue, 23 Oct 2012 07:58:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQZNI-0003qh-38
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 07:58:08 +0000
Received: from [85.158.139.211:20288] by server-14.bemta-5.messagelabs.com id
	1B/48-24068-F0E46805; Tue, 23 Oct 2012 07:58:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1350979086!23337090!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11547 invoked from network); 23 Oct 2012 07:58:06 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-206.messagelabs.com with SMTP;
	23 Oct 2012 07:58:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 23 Oct 2012 08:58:06 +0100
Message-Id: <50866A2C02000078000A356D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 23 Oct 2012 08:58:04 +0100
From: "Jan Beulich" 
To: "Mauro" 
References: 
	
	
	
	<65395f62-74e5-4910-b701-8df629c2ce3b@default>
	
	
	
	
	
	<20120930151314.GU8912@reaktio.net>
	
	
	
	<507C024602000078000A155C@nat28.tlf.novell.com>
	
	<507C226A02000078000A1657@nat28.tlf.novell.com>
	
	<508509D902000078000A2DDA@nat28.tlf.novell.com>
	
	<50852D8C02000078000A2E48@nat28.tlf.novell.com>
	
	<5085530202000078000A2F12@nat28.tlf.novell.com>
	
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel 
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 23.10.12 at 09:18, Mauro  wrote:
>>  A kernel run with no Xen underneath it.
> 
> Here is:
> 
> uname -a
> Linux xen-p02 2.6.32-5-amd64 #1 SMP Sun Sep 23 10:07:46 UTC 2012
> x86_64 GNU/Linux

I'm sorry to say that, but 2.6.32 is nowhere close to "recent" (as
I had asked for). The thing is that the (unfortunately incomplete)
hypervisor log you sent earlier leaves open whether we mis-detect
ARAT on that system (the relevant HPET message is info level, but
you had "loglvl=warning" in place), so we can't be certain of either
fact (ARAT actually being reported by the CPU as well as whether
HPET broadcast is getting set up).

Irrespective of that it would also be useful to know whether the
native kernel (and in particular its CPU idle management) work
on that system, and which C-states it actually makes use of. So
getting us the contents of the respective sysfs nodes would also
be helpful for reference.

Jan

> cat /proc/cpuinfo
> 
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 15
> model name      : Intel(R) Xeon(R) CPU           E7330  @ 2.40GHz
> stepping        : 11
> cpu MHz         : 2399.822
> cache size      : 3072 KB
> physical id     : 0
> siblings        : 4
> core id         : 0
> cpu cores       : 4
> apicid          : 0
> initial apicid  : 0
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 10
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
> syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf
> pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca lahf_lm
> tpr_shadow vnmi flexpriority
> bogomips        : 4799.64
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 40 bits physical, 48 bits virtual
> power management:




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 07:58:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 07:58:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQZNJ-0003qm-5N; Tue, 23 Oct 2012 07:58:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQZNI-0003qh-38
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 07:58:08 +0000
Received: from [85.158.139.211:20288] by server-14.bemta-5.messagelabs.com id
	1B/48-24068-F0E46805; Tue, 23 Oct 2012 07:58:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1350979086!23337090!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11547 invoked from network); 23 Oct 2012 07:58:06 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-206.messagelabs.com with SMTP;
	23 Oct 2012 07:58:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 23 Oct 2012 08:58:06 +0100
Message-Id: <50866A2C02000078000A356D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 23 Oct 2012 08:58:04 +0100
From: "Jan Beulich" 
To: "Mauro" 
References: 
	
	
	
	<65395f62-74e5-4910-b701-8df629c2ce3b@default>
	
	
	
	
	
	<20120930151314.GU8912@reaktio.net>
	
	
	
	<507C024602000078000A155C@nat28.tlf.novell.com>
	
	<507C226A02000078000A1657@nat28.tlf.novell.com>
	
	<508509D902000078000A2DDA@nat28.tlf.novell.com>
	
	<50852D8C02000078000A2E48@nat28.tlf.novell.com>
	
	<5085530202000078000A2F12@nat28.tlf.novell.com>
	
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel 
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 23.10.12 at 09:18, Mauro  wrote:
>>  A kernel run with no Xen underneath it.
> 
> Here is:
> 
> uname -a
> Linux xen-p02 2.6.32-5-amd64 #1 SMP Sun Sep 23 10:07:46 UTC 2012
> x86_64 GNU/Linux

I'm sorry to say that, but 2.6.32 is nowhere close to "recent" (as
I had asked for). The thing is that the (unfortunately incomplete)
hypervisor log you sent earlier leaves open whether we mis-detect
ARAT on that system (the relevant HPET message is info level, but
you had "loglvl=warning" in place), so we can't be certain of either
fact (ARAT actually being reported by the CPU as well as whether
HPET broadcast is getting set up).

Irrespective of that it would also be useful to know whether the
native kernel (and in particular its CPU idle management) work
on that system, and which C-states it actually makes use of. So
getting us the contents of the respective sysfs nodes would also
be helpful for reference.

Jan

> cat /proc/cpuinfo
> 
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 15
> model name      : Intel(R) Xeon(R) CPU           E7330  @ 2.40GHz
> stepping        : 11
> cpu MHz         : 2399.822
> cache size      : 3072 KB
> physical id     : 0
> siblings        : 4
> core id         : 0
> cpu cores       : 4
> apicid          : 0
> initial apicid  : 0
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 10
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
> syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf
> pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca lahf_lm
> tpr_shadow vnmi flexpriority
> bogomips        : 4799.64
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 40 bits physical, 48 bits virtual
> power management:




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 08:43:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 08:43:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQa4n-0004bF-Qj; Tue, 23 Oct 2012 08:43:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQa2g-0004aG-Cq
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 08:40:54 +0000
Received: from [85.158.143.99:50710] by server-1.bemta-4.messagelabs.com id
	6F/00-19134-51856805; Tue, 23 Oct 2012 08:40:53 +0000
X-Env-Sender: mrsanna1@gmail.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1350981651!23924986!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32205 invoked from network); 23 Oct 2012 08:40:52 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 08:40:52 -0000
Received: by mail-vc0-f173.google.com with SMTP id fl15so1089743vcb.32
	for ; Tue, 23 Oct 2012 01:40:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=yb57sf2ki3UA8edTZRjtpXGJXXRzMjBaA3K06iBOtFc=;
	b=CBqQLtuYjkjlA5zWt8jvamvRqt227PrBqVxKF9wrbHOt1vLkuP6pCw5qbfNpfMVIpq
	g0oIokdOkiar3TbbGdwI2t+MEBWN+wK7Hwb53JIbAzOz/5/rv1DgtqZ2j/VILS8Kydrq
	YKPVWbQoC9dL8bpEQvpvK4xb+k42dCsp7Ah6+S+imFbg9O+Ep7+a/5rgz/tK1W/b3saE
	jkm81doN7/xDz3UU/IlXS9qtthmmbdqUbR6UrxqoDW0W3v0H6l9PVL7ImitQNTEcYSFG
	nc9/npGVI9uizeUSP+iuVNBQBejdMjy2twOPQIlVqQEebh9uS22a/wv//GqHgSq7UbFC
	+jTQ==
MIME-Version: 1.0
Received: by 10.52.93.238 with SMTP id cx14mr15555932vdb.42.1350981650953;
	Tue, 23 Oct 2012 01:40:50 -0700 (PDT)
Received: by 10.58.207.75 with HTTP; Tue, 23 Oct 2012 01:40:50 -0700 (PDT)
In-Reply-To: <50866A2C02000078000A356D@nat28.tlf.novell.com>
References: 
	
	
	
	<65395f62-74e5-4910-b701-8df629c2ce3b@default>
	
	
	
	
	
	<20120930151314.GU8912@reaktio.net>
	
	
	
	<507C024602000078000A155C@nat28.tlf.novell.com>
	
	<507C226A02000078000A1657@nat28.tlf.novell.com>
	
	<508509D902000078000A2DDA@nat28.tlf.novell.com>
	
	<50852D8C02000078000A2E48@nat28.tlf.novell.com>
	
	<5085530202000078000A2F12@nat28.tlf.novell.com>
	
	<50866A2C02000078000A356D@nat28.tlf.novell.com>
Date: Tue, 23 Oct 2012 10:40:50 +0200
Message-ID: 
From: Mauro 
To: Jan Beulich 
X-Mailman-Approved-At: Tue, 23 Oct 2012 08:43:02 +0000
Cc: xen-devel 
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 23 October 2012 09:58, Jan Beulich  wrote:
>>>> On 23.10.12 at 09:18, Mauro  wrote:
>>>  A kernel run with no Xen underneath it.
>>
>> Here is:
>>
>> uname -a
>> Linux xen-p02 2.6.32-5-amd64 #1 SMP Sun Sep 23 10:07:46 UTC 2012
>> x86_64 GNU/Linux
>
> I'm sorry to say that, but 2.6.32 is nowhere close to "recent" (as
> I had asked for).

Sorry I'm using squeeze in production servers and I don't have a test
machine on which install wheezy.
There's nothing else I can do?
As reported before with the workaround cpuidle=0 I don't have any problem now.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 08:43:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 08:43:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQa4n-0004bF-Qj; Tue, 23 Oct 2012 08:43:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQa2g-0004aG-Cq
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 08:40:54 +0000
Received: from [85.158.143.99:50710] by server-1.bemta-4.messagelabs.com id
	6F/00-19134-51856805; Tue, 23 Oct 2012 08:40:53 +0000
X-Env-Sender: mrsanna1@gmail.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1350981651!23924986!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32205 invoked from network); 23 Oct 2012 08:40:52 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 08:40:52 -0000
Received: by mail-vc0-f173.google.com with SMTP id fl15so1089743vcb.32
	for ; Tue, 23 Oct 2012 01:40:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=yb57sf2ki3UA8edTZRjtpXGJXXRzMjBaA3K06iBOtFc=;
	b=CBqQLtuYjkjlA5zWt8jvamvRqt227PrBqVxKF9wrbHOt1vLkuP6pCw5qbfNpfMVIpq
	g0oIokdOkiar3TbbGdwI2t+MEBWN+wK7Hwb53JIbAzOz/5/rv1DgtqZ2j/VILS8Kydrq
	YKPVWbQoC9dL8bpEQvpvK4xb+k42dCsp7Ah6+S+imFbg9O+Ep7+a/5rgz/tK1W/b3saE
	jkm81doN7/xDz3UU/IlXS9qtthmmbdqUbR6UrxqoDW0W3v0H6l9PVL7ImitQNTEcYSFG
	nc9/npGVI9uizeUSP+iuVNBQBejdMjy2twOPQIlVqQEebh9uS22a/wv//GqHgSq7UbFC
	+jTQ==
MIME-Version: 1.0
Received: by 10.52.93.238 with SMTP id cx14mr15555932vdb.42.1350981650953;
	Tue, 23 Oct 2012 01:40:50 -0700 (PDT)
Received: by 10.58.207.75 with HTTP; Tue, 23 Oct 2012 01:40:50 -0700 (PDT)
In-Reply-To: <50866A2C02000078000A356D@nat28.tlf.novell.com>
References: 
	
	
	
	<65395f62-74e5-4910-b701-8df629c2ce3b@default>
	
	
	
	
	
	<20120930151314.GU8912@reaktio.net>
	
	
	
	<507C024602000078000A155C@nat28.tlf.novell.com>
	
	<507C226A02000078000A1657@nat28.tlf.novell.com>
	
	<508509D902000078000A2DDA@nat28.tlf.novell.com>
	
	<50852D8C02000078000A2E48@nat28.tlf.novell.com>
	
	<5085530202000078000A2F12@nat28.tlf.novell.com>
	
	<50866A2C02000078000A356D@nat28.tlf.novell.com>
Date: Tue, 23 Oct 2012 10:40:50 +0200
Message-ID: 
From: Mauro 
To: Jan Beulich 
X-Mailman-Approved-At: Tue, 23 Oct 2012 08:43:02 +0000
Cc: xen-devel 
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 23 October 2012 09:58, Jan Beulich  wrote:
>>>> On 23.10.12 at 09:18, Mauro  wrote:
>>>  A kernel run with no Xen underneath it.
>>
>> Here is:
>>
>> uname -a
>> Linux xen-p02 2.6.32-5-amd64 #1 SMP Sun Sep 23 10:07:46 UTC 2012
>> x86_64 GNU/Linux
>
> I'm sorry to say that, but 2.6.32 is nowhere close to "recent" (as
> I had asked for).

Sorry I'm using squeeze in production servers and I don't have a test
machine on which install wheezy.
There's nothing else I can do?
As reported before with the workaround cpuidle=0 I don't have any problem now.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 08:43:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 08:43:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQa4n-0004b8-EY; Tue, 23 Oct 2012 08:43:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQYmK-0003Xz-TO
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 07:19:57 +0000
Received: from [85.158.139.83:37299] by server-7.bemta-5.messagelabs.com id
	90/81-23102-B1546805; Tue, 23 Oct 2012 07:19:55 +0000
X-Env-Sender: mrsanna1@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1350976794!33202122!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22798 invoked from network); 23 Oct 2012 07:19:55 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 07:19:55 -0000
Received: by mail-vb0-f45.google.com with SMTP id p1so4696147vbi.32
	for ; Tue, 23 Oct 2012 00:19:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=RmfZfoo8FmiYk7r7SyEDGkkscGPN/BVQYtaAAjn6cAk=;
	b=tHxALodW/cE8VuYaCQxqVNtvTglIJyxKWKZaktzoFhHug3MQ71zGu5nTADPNV1vQpH
	cDIp7oJpHbvOsCjMaa6ctqgKldjgfydykTV8JVNQeGtOsFtJBseR1tDs8QBZ+xmOMtnb
	qJH3ZbNLduJNPSEjS55L93U1C3P7ecGY0sVQqmHn0dXVplAvP//OkE7jH+1C4uiRLnUQ
	rrO+cN41A3q7OBXC3DXp69arSnBdeDDFL14LTub2wO2xr1ddGWu1ELCtTOxVdW2Q5Wic
	XCxNwszmWTYJfYkrfpVDmF6UG+HvB3GB0icAjvgt3jKURmrEsMWlppYuF4JpykBry+SF
	6hOA==
MIME-Version: 1.0
Received: by 10.58.15.227 with SMTP id a3mr21097717ved.38.1350976793774; Tue,
	23 Oct 2012 00:19:53 -0700 (PDT)
Received: by 10.58.207.75 with HTTP; Tue, 23 Oct 2012 00:19:53 -0700 (PDT)
In-Reply-To: <5085530202000078000A2F12@nat28.tlf.novell.com>
References: 
	
	
	
	<65395f62-74e5-4910-b701-8df629c2ce3b@default>
	
	
	
	
	
	<20120930151314.GU8912@reaktio.net>
	
	
	
	<507C024602000078000A155C@nat28.tlf.novell.com>
	
	<507C226A02000078000A1657@nat28.tlf.novell.com>
	
	<508509D902000078000A2DDA@nat28.tlf.novell.com>
	
	<50852D8C02000078000A2E48@nat28.tlf.novell.com>
	
	<5085530202000078000A2F12@nat28.tlf.novell.com>
Date: Tue, 23 Oct 2012 09:19:53 +0200
Message-ID: 
From: Mauro 
To: Jan Beulich 
X-Mailman-Approved-At: Tue, 23 Oct 2012 08:43:02 +0000
Cc: Jeremy Fitzhardinge , Keir Fraser ,
	Dan Magenheimer ,
	xen-devel ,
	Olivier Hanesse ,
	Mark Adams 
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> A kernel run with no Xen underneath it.

Here is:

uname -a
Linux xen-p02 2.6.32-5-amd64 #1 SMP Sun Sep 23 10:07:46 UTC 2012
x86_64 GNU/Linux

cat /proc/cpuinfo

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Xeon(R) CPU           E7330  @ 2.40GHz
stepping        : 11
cpu MHz         : 2399.822
cache size      : 3072 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 4
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf
pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca lahf_lm
tpr_shadow vnmi flexpriority
bogomips        : 4799.64
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 08:43:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 08:43:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQa4n-0004b8-EY; Tue, 23 Oct 2012 08:43:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQYmK-0003Xz-TO
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 07:19:57 +0000
Received: from [85.158.139.83:37299] by server-7.bemta-5.messagelabs.com id
	90/81-23102-B1546805; Tue, 23 Oct 2012 07:19:55 +0000
X-Env-Sender: mrsanna1@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1350976794!33202122!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22798 invoked from network); 23 Oct 2012 07:19:55 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 07:19:55 -0000
Received: by mail-vb0-f45.google.com with SMTP id p1so4696147vbi.32
	for ; Tue, 23 Oct 2012 00:19:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=RmfZfoo8FmiYk7r7SyEDGkkscGPN/BVQYtaAAjn6cAk=;
	b=tHxALodW/cE8VuYaCQxqVNtvTglIJyxKWKZaktzoFhHug3MQ71zGu5nTADPNV1vQpH
	cDIp7oJpHbvOsCjMaa6ctqgKldjgfydykTV8JVNQeGtOsFtJBseR1tDs8QBZ+xmOMtnb
	qJH3ZbNLduJNPSEjS55L93U1C3P7ecGY0sVQqmHn0dXVplAvP//OkE7jH+1C4uiRLnUQ
	rrO+cN41A3q7OBXC3DXp69arSnBdeDDFL14LTub2wO2xr1ddGWu1ELCtTOxVdW2Q5Wic
	XCxNwszmWTYJfYkrfpVDmF6UG+HvB3GB0icAjvgt3jKURmrEsMWlppYuF4JpykBry+SF
	6hOA==
MIME-Version: 1.0
Received: by 10.58.15.227 with SMTP id a3mr21097717ved.38.1350976793774; Tue,
	23 Oct 2012 00:19:53 -0700 (PDT)
Received: by 10.58.207.75 with HTTP; Tue, 23 Oct 2012 00:19:53 -0700 (PDT)
In-Reply-To: <5085530202000078000A2F12@nat28.tlf.novell.com>
References: 
	
	
	
	<65395f62-74e5-4910-b701-8df629c2ce3b@default>
	
	
	
	
	
	<20120930151314.GU8912@reaktio.net>
	
	
	
	<507C024602000078000A155C@nat28.tlf.novell.com>
	
	<507C226A02000078000A1657@nat28.tlf.novell.com>
	
	<508509D902000078000A2DDA@nat28.tlf.novell.com>
	
	<50852D8C02000078000A2E48@nat28.tlf.novell.com>
	
	<5085530202000078000A2F12@nat28.tlf.novell.com>
Date: Tue, 23 Oct 2012 09:19:53 +0200
Message-ID: 
From: Mauro 
To: Jan Beulich 
X-Mailman-Approved-At: Tue, 23 Oct 2012 08:43:02 +0000
Cc: Jeremy Fitzhardinge , Keir Fraser ,
	Dan Magenheimer ,
	xen-devel ,
	Olivier Hanesse ,
	Mark Adams 
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> A kernel run with no Xen underneath it.

Here is:

uname -a
Linux xen-p02 2.6.32-5-amd64 #1 SMP Sun Sep 23 10:07:46 UTC 2012
x86_64 GNU/Linux

cat /proc/cpuinfo

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Xeon(R) CPU           E7330  @ 2.40GHz
stepping        : 11
cpu MHz         : 2399.822
cache size      : 3072 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 4
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf
pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca lahf_lm
tpr_shadow vnmi flexpriority
bogomips        : 4799.64
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 08:43:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 08:43:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQa4m-0004au-O4; Tue, 23 Oct 2012 08:43:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQTxL-0001p9-L9
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 02:10:59 +0000
Received: from [85.158.139.83:11492] by server-8.bemta-5.messagelabs.com id
	9D/42-23193-2BCF5805; Tue, 23 Oct 2012 02:10:58 +0000
X-Env-Sender: fengguang.wu@intel.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1350958257!28805461!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjIxOTM0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19831 invoked from network); 23 Oct 2012 02:10:58 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-11.tower-182.messagelabs.com with SMTP;
	23 Oct 2012 02:10:58 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 22 Oct 2012 19:10:56 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,633,1344236400"; d="scan'208";a="207750505"
Received: from unknown (HELO wfg-t420.sh.intel.com) ([10.255.21.82])
	by azsmga001.ch.intel.com with ESMTP; 22 Oct 2012 19:10:55 -0700
Received: from wfg by wfg-t420.sh.intel.com with local (Exim 4.77)
	(envelope-from )
	id 1TQTxG-00028J-SZ; Tue, 23 Oct 2012 10:10:54 +0800
Date: Tue, 23 Oct 2012 10:10:54 +0800
From: Fengguang Wu 
To: Konrad Rzeszutek Wilk 
Message-ID: <20121023021054.GD6830@localhost>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Heirloom mailx 12.5 6/20/10
X-Mailman-Approved-At: Tue, 23 Oct 2012 08:43:02 +0000
Cc: Yuanhan Liu , xen-devel@lists.xensource.com
Subject: [Xen-devel] [xen:devel/pvh.5 8/8] arch/x86/xen/setup.c:261:6:
 warning: unused variable 'xlated_phys'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Konrad,

FYI, there are new compile warnings show up in

tree:   git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git devel/pvh.5
head:   dfc557a5c9a519b45b79ad059821db15bad229fa
commit: dfc557a5c9a519b45b79ad059821db15bad229fa [8/8] xen/e820: Coalesce the PVH release/populate logic in the generic case.
config: x86_64-allyesconfig # make ARCH=x86_64 allyesconfig

All warnings:

arch/x86/xen/setup.c: In function 'xen_set_identity_and_release':
arch/x86/xen/setup.c:261:6: warning: unused variable 'xlated_phys' [-Wunused-variable]

vim +261 arch/x86/xen/setup.c

dfc557a5 Konrad Rzeszutek Wilk 2012-10-22  245  	}
83d51ab4 David Vrabel          2012-05-03  246  	if (start_pfn < nr_pages)
83d51ab4 David Vrabel          2012-05-03  247  		*released += xen_release_chunk(
83d51ab4 David Vrabel          2012-05-03  248  			start_pfn, min(end_pfn, nr_pages));
83d51ab4 David Vrabel          2012-05-03  249  
83d51ab4 David Vrabel          2012-05-03  250  	*identity += set_phys_range_identity(start_pfn, end_pfn);
83d51ab4 David Vrabel          2012-05-03  251  }
83d51ab4 David Vrabel          2012-05-03  252  
f3f436e3 David Vrabel          2011-09-28  253  static unsigned long __init xen_set_identity_and_release(
f3f436e3 David Vrabel          2011-09-28  254  	const struct e820entry *list, size_t map_size, unsigned long nr_pages)
093d7b46 Miroslav Rezanina     2009-09-16  255  {
f3f436e3 David Vrabel          2011-09-28  256  	phys_addr_t start = 0;
093d7b46 Miroslav Rezanina     2009-09-16  257  	unsigned long released = 0;
68df0da7 Konrad Rzeszutek Wilk 2011-02-01  258  	unsigned long identity = 0;
f3f436e3 David Vrabel          2011-09-28  259  	const struct e820entry *entry;
68df0da7 Konrad Rzeszutek Wilk 2011-02-01  260  	int i;
1a870012 Mukesh Rathor         2012-10-17 @261  	int xlated_phys = xen_feature(XENFEAT_auto_translated_physmap);
68df0da7 Konrad Rzeszutek Wilk 2011-02-01  262  
f3f436e3 David Vrabel          2011-09-28  263  	/*
f3f436e3 David Vrabel          2011-09-28  264  	 * Combine non-RAM regions and gaps until a RAM region (or the
f3f436e3 David Vrabel          2011-09-28  265  	 * end of the map) is reached, then set the 1:1 map and
f3f436e3 David Vrabel          2011-09-28  266  	 * release the pages (if available) in those non-RAM regions.
f3f436e3 David Vrabel          2011-09-28  267  	 *
f3f436e3 David Vrabel          2011-09-28  268  	 * The combined non-RAM regions are rounded to a whole number
f3f436e3 David Vrabel          2011-09-28  269  	 * of pages so any partial pages are accessible via the 1:1

The code at line 261 was first introduced by commit:
1a87001 xen/pvh: bootup and setup (E820) related changes.

---
0-DAY kernel build testing backend         Open Source Technology Center
Fengguang Wu, Yuanhan Liu                              Intel Corporation

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 08:43:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 08:43:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQa4m-0004au-O4; Tue, 23 Oct 2012 08:43:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQTxL-0001p9-L9
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 02:10:59 +0000
Received: from [85.158.139.83:11492] by server-8.bemta-5.messagelabs.com id
	9D/42-23193-2BCF5805; Tue, 23 Oct 2012 02:10:58 +0000
X-Env-Sender: fengguang.wu@intel.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1350958257!28805461!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjIxOTM0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19831 invoked from network); 23 Oct 2012 02:10:58 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-11.tower-182.messagelabs.com with SMTP;
	23 Oct 2012 02:10:58 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 22 Oct 2012 19:10:56 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,633,1344236400"; d="scan'208";a="207750505"
Received: from unknown (HELO wfg-t420.sh.intel.com) ([10.255.21.82])
	by azsmga001.ch.intel.com with ESMTP; 22 Oct 2012 19:10:55 -0700
Received: from wfg by wfg-t420.sh.intel.com with local (Exim 4.77)
	(envelope-from )
	id 1TQTxG-00028J-SZ; Tue, 23 Oct 2012 10:10:54 +0800
Date: Tue, 23 Oct 2012 10:10:54 +0800
From: Fengguang Wu 
To: Konrad Rzeszutek Wilk 
Message-ID: <20121023021054.GD6830@localhost>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Heirloom mailx 12.5 6/20/10
X-Mailman-Approved-At: Tue, 23 Oct 2012 08:43:02 +0000
Cc: Yuanhan Liu , xen-devel@lists.xensource.com
Subject: [Xen-devel] [xen:devel/pvh.5 8/8] arch/x86/xen/setup.c:261:6:
 warning: unused variable 'xlated_phys'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Konrad,

FYI, there are new compile warnings show up in

tree:   git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git devel/pvh.5
head:   dfc557a5c9a519b45b79ad059821db15bad229fa
commit: dfc557a5c9a519b45b79ad059821db15bad229fa [8/8] xen/e820: Coalesce the PVH release/populate logic in the generic case.
config: x86_64-allyesconfig # make ARCH=x86_64 allyesconfig

All warnings:

arch/x86/xen/setup.c: In function 'xen_set_identity_and_release':
arch/x86/xen/setup.c:261:6: warning: unused variable 'xlated_phys' [-Wunused-variable]

vim +261 arch/x86/xen/setup.c

dfc557a5 Konrad Rzeszutek Wilk 2012-10-22  245  	}
83d51ab4 David Vrabel          2012-05-03  246  	if (start_pfn < nr_pages)
83d51ab4 David Vrabel          2012-05-03  247  		*released += xen_release_chunk(
83d51ab4 David Vrabel          2012-05-03  248  			start_pfn, min(end_pfn, nr_pages));
83d51ab4 David Vrabel          2012-05-03  249  
83d51ab4 David Vrabel          2012-05-03  250  	*identity += set_phys_range_identity(start_pfn, end_pfn);
83d51ab4 David Vrabel          2012-05-03  251  }
83d51ab4 David Vrabel          2012-05-03  252  
f3f436e3 David Vrabel          2011-09-28  253  static unsigned long __init xen_set_identity_and_release(
f3f436e3 David Vrabel          2011-09-28  254  	const struct e820entry *list, size_t map_size, unsigned long nr_pages)
093d7b46 Miroslav Rezanina     2009-09-16  255  {
f3f436e3 David Vrabel          2011-09-28  256  	phys_addr_t start = 0;
093d7b46 Miroslav Rezanina     2009-09-16  257  	unsigned long released = 0;
68df0da7 Konrad Rzeszutek Wilk 2011-02-01  258  	unsigned long identity = 0;
f3f436e3 David Vrabel          2011-09-28  259  	const struct e820entry *entry;
68df0da7 Konrad Rzeszutek Wilk 2011-02-01  260  	int i;
1a870012 Mukesh Rathor         2012-10-17 @261  	int xlated_phys = xen_feature(XENFEAT_auto_translated_physmap);
68df0da7 Konrad Rzeszutek Wilk 2011-02-01  262  
f3f436e3 David Vrabel          2011-09-28  263  	/*
f3f436e3 David Vrabel          2011-09-28  264  	 * Combine non-RAM regions and gaps until a RAM region (or the
f3f436e3 David Vrabel          2011-09-28  265  	 * end of the map) is reached, then set the 1:1 map and
f3f436e3 David Vrabel          2011-09-28  266  	 * release the pages (if available) in those non-RAM regions.
f3f436e3 David Vrabel          2011-09-28  267  	 *
f3f436e3 David Vrabel          2011-09-28  268  	 * The combined non-RAM regions are rounded to a whole number
f3f436e3 David Vrabel          2011-09-28  269  	 * of pages so any partial pages are accessible via the 1:1

The code at line 261 was first introduced by commit:
1a87001 xen/pvh: bootup and setup (E820) related changes.

---
0-DAY kernel build testing backend         Open Source Technology Center
Fengguang Wu, Yuanhan Liu                              Intel Corporation

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 08:43:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 08:43:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQa4m-0004an-D6; Tue, 23 Oct 2012 08:43:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQTwH-0001og-LO
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 02:09:53 +0000
Received: from [193.109.254.147:11321] by server-13.bemta-14.messagelabs.com
	id 25/72-21440-07CF5805; Tue, 23 Oct 2012 02:09:52 +0000
X-Env-Sender: fengguang.wu@intel.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1350958191!2256677!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzU4MDAx\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3255 invoked from network); 23 Oct 2012 02:09:52 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-7.tower-27.messagelabs.com with SMTP;
	23 Oct 2012 02:09:52 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 22 Oct 2012 19:09:24 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,632,1344236400"; d="scan'208";a="230914755"
Received: from unknown (HELO wfg-t420.sh.intel.com) ([10.255.21.82])
	by orsmga002.jf.intel.com with ESMTP; 22 Oct 2012 19:09:49 -0700
Received: from wfg by wfg-t420.sh.intel.com with local (Exim 4.77)
	(envelope-from )
	id 1TQTwD-00026g-1k; Tue, 23 Oct 2012 10:09:49 +0800
Date: Tue, 23 Oct 2012 10:09:49 +0800
From: Fengguang Wu 
To: Konrad Rzeszutek Wilk 
Message-ID: <20121023020949.GC6830@localhost>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Heirloom mailx 12.5 6/20/10
X-Mailman-Approved-At: Tue, 23 Oct 2012 08:43:02 +0000
Cc: Yuanhan Liu , xen-devel@lists.xensource.com
Subject: [Xen-devel] [xen:devel/pvh.5 2/8] arch/x86/xen/smp.c:329:7: error:
 'struct vcpu_guest_context' has no member named 'u'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Konrad,

FYI, kernel build failed on

tree:   git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git devel/pvh.5
head:   dfc557a5c9a519b45b79ad059821db15bad229fa
commit: 4d80210f4948a962c9ecca2773da69c0b2affb62 [2/8] xen/smp: Move the common CPU init code a bit to prep for PVH patch.
config: x86_64-allyesconfig # make ARCH=x86_64 allyesconfig

All error/warnings:

arch/x86/xen/smp.c: In function 'cpu_initialize_context':
arch/x86/xen/smp.c:329:7: error: 'struct vcpu_guest_context' has no member named 'u'
arch/x86/xen/smp.c:330:7: error: 'struct vcpu_guest_context' has no member named 'u'

vim +329 arch/x86/xen/smp.c

4d80210f arch/x86/xen/smp.c  Konrad Rzeszutek Wilk 2012-10-22  323  		BUG_ON((unsigned long)gdt & ~PAGE_MASK);
f87e4cac arch/i386/xen/smp.c Jeremy Fitzhardinge   2007-07-17  324  
4d80210f arch/x86/xen/smp.c  Konrad Rzeszutek Wilk 2012-10-22  325  		gdt_mfn = arbitrary_virt_to_mfn(gdt);
4d80210f arch/x86/xen/smp.c  Konrad Rzeszutek Wilk 2012-10-22  326  		make_lowmem_page_readonly(gdt);
4d80210f arch/x86/xen/smp.c  Konrad Rzeszutek Wilk 2012-10-22  327  		make_lowmem_page_readonly(mfn_to_virt(gdt_mfn));
f87e4cac arch/i386/xen/smp.c Jeremy Fitzhardinge   2007-07-17  328  
4d80210f arch/x86/xen/smp.c  Konrad Rzeszutek Wilk 2012-10-22 @329  		ctxt->u.pv.gdt_frames[0] = gdt_mfn;
4d80210f arch/x86/xen/smp.c  Konrad Rzeszutek Wilk 2012-10-22  330  		ctxt->u.pv.gdt_ents      = GDT_ENTRIES;
f87e4cac arch/i386/xen/smp.c Jeremy Fitzhardinge   2007-07-17  331  
4d80210f arch/x86/xen/smp.c  Konrad Rzeszutek Wilk 2012-10-22  332  		ctxt->kernel_ss = __KERNEL_DS;

---
0-DAY kernel build testing backend         Open Source Technology Center
Fengguang Wu, Yuanhan Liu                              Intel Corporation

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 08:43:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 08:43:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQa4m-0004an-D6; Tue, 23 Oct 2012 08:43:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQTwH-0001og-LO
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 02:09:53 +0000
Received: from [193.109.254.147:11321] by server-13.bemta-14.messagelabs.com
	id 25/72-21440-07CF5805; Tue, 23 Oct 2012 02:09:52 +0000
X-Env-Sender: fengguang.wu@intel.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1350958191!2256677!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzU4MDAx\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3255 invoked from network); 23 Oct 2012 02:09:52 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-7.tower-27.messagelabs.com with SMTP;
	23 Oct 2012 02:09:52 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 22 Oct 2012 19:09:24 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,632,1344236400"; d="scan'208";a="230914755"
Received: from unknown (HELO wfg-t420.sh.intel.com) ([10.255.21.82])
	by orsmga002.jf.intel.com with ESMTP; 22 Oct 2012 19:09:49 -0700
Received: from wfg by wfg-t420.sh.intel.com with local (Exim 4.77)
	(envelope-from )
	id 1TQTwD-00026g-1k; Tue, 23 Oct 2012 10:09:49 +0800
Date: Tue, 23 Oct 2012 10:09:49 +0800
From: Fengguang Wu 
To: Konrad Rzeszutek Wilk 
Message-ID: <20121023020949.GC6830@localhost>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Heirloom mailx 12.5 6/20/10
X-Mailman-Approved-At: Tue, 23 Oct 2012 08:43:02 +0000
Cc: Yuanhan Liu , xen-devel@lists.xensource.com
Subject: [Xen-devel] [xen:devel/pvh.5 2/8] arch/x86/xen/smp.c:329:7: error:
 'struct vcpu_guest_context' has no member named 'u'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Konrad,

FYI, kernel build failed on

tree:   git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git devel/pvh.5
head:   dfc557a5c9a519b45b79ad059821db15bad229fa
commit: 4d80210f4948a962c9ecca2773da69c0b2affb62 [2/8] xen/smp: Move the common CPU init code a bit to prep for PVH patch.
config: x86_64-allyesconfig # make ARCH=x86_64 allyesconfig

All error/warnings:

arch/x86/xen/smp.c: In function 'cpu_initialize_context':
arch/x86/xen/smp.c:329:7: error: 'struct vcpu_guest_context' has no member named 'u'
arch/x86/xen/smp.c:330:7: error: 'struct vcpu_guest_context' has no member named 'u'

vim +329 arch/x86/xen/smp.c

4d80210f arch/x86/xen/smp.c  Konrad Rzeszutek Wilk 2012-10-22  323  		BUG_ON((unsigned long)gdt & ~PAGE_MASK);
f87e4cac arch/i386/xen/smp.c Jeremy Fitzhardinge   2007-07-17  324  
4d80210f arch/x86/xen/smp.c  Konrad Rzeszutek Wilk 2012-10-22  325  		gdt_mfn = arbitrary_virt_to_mfn(gdt);
4d80210f arch/x86/xen/smp.c  Konrad Rzeszutek Wilk 2012-10-22  326  		make_lowmem_page_readonly(gdt);
4d80210f arch/x86/xen/smp.c  Konrad Rzeszutek Wilk 2012-10-22  327  		make_lowmem_page_readonly(mfn_to_virt(gdt_mfn));
f87e4cac arch/i386/xen/smp.c Jeremy Fitzhardinge   2007-07-17  328  
4d80210f arch/x86/xen/smp.c  Konrad Rzeszutek Wilk 2012-10-22 @329  		ctxt->u.pv.gdt_frames[0] = gdt_mfn;
4d80210f arch/x86/xen/smp.c  Konrad Rzeszutek Wilk 2012-10-22  330  		ctxt->u.pv.gdt_ents      = GDT_ENTRIES;
f87e4cac arch/i386/xen/smp.c Jeremy Fitzhardinge   2007-07-17  331  
4d80210f arch/x86/xen/smp.c  Konrad Rzeszutek Wilk 2012-10-22  332  		ctxt->kernel_ss = __KERNEL_DS;

---
0-DAY kernel build testing backend         Open Source Technology Center
Fengguang Wu, Yuanhan Liu                              Intel Corporation

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 08:43:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 08:43:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQa4n-0004b1-2r; Tue, 23 Oct 2012 08:43:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQWSE-0002PR-5R
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 04:51:02 +0000
Received: from [85.158.143.99:7881] by server-2.bemta-4.messagelabs.com id
	7F/C4-22268-53226805; Tue, 23 Oct 2012 04:51:01 +0000
X-Env-Sender: FlorianSchandinat@gmx.de
X-Msg-Ref: server-10.tower-216.messagelabs.com!1350967860!28695811!1
X-Originating-IP: [213.165.64.23]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjEzLjE2NS42NC4yMyA9PiAyMDU0MzM=\n,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 522 invoked from network); 23 Oct 2012 04:51:00 -0000
Received: from mailout-de.gmx.net (HELO mailout-de.gmx.net) (213.165.64.23)
	by server-10.tower-216.messagelabs.com with SMTP;
	23 Oct 2012 04:51:00 -0000
Received: (qmail invoked by alias); 23 Oct 2012 04:51:00 -0000
Received: from dslb-092-074-255-099.pools.arcor-ip.net (EHLO [192.168.0.9])
	[92.74.255.99]
	by mail.gmx.net (mp001) with SMTP; 23 Oct 2012 06:51:00 +0200
X-Authenticated: #10250065
X-Provags-ID: V01U2FsdGVkX19cbgF8o4ZcypurEMbKmdhDjWfEoLtnWl2avSqtqb
	yCEobjIc8Pmf0S
Message-ID: <50862224.60908@gmx.de>
Date: Tue, 23 Oct 2012 04:50:44 +0000
From: Florian Tobias Schandinat 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120922 Icedove/3.0.11
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk 
References: <507FD39F.4060601@citrix.com>
	<1350554618-14582-4-git-send-email-david.vrabel@citrix.com>
	<20121019130011.GD26830@phenom.dumpdata.com>
In-Reply-To: <20121019130011.GD26830@phenom.dumpdata.com>
X-Y-GMX-Trusted: 0
X-Mailman-Approved-At: Tue, 23 Oct 2012 08:43:02 +0000
Cc: linux-kernel@vger.kernel.org, linux-fbdev@vger.kernel.org,
	David Vrabel , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 4/5] xen-fbfront: handle backend CLOSED
	without CLOSING
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Konrad,

On 10/19/2012 01:00 PM, Konrad Rzeszutek Wilk wrote:
> On Thu, Oct 18, 2012 at 11:03:37AM +0100, David Vrabel wrote:
>> From: David Vrabel 
>>
>> Backend drivers shouldn't transistion to CLOSED unless the frontend is
>> CLOSED.  If a backend does transition to CLOSED too soon then the
>> frontend may not see the CLOSING state and will not properly shutdown.
>>
>> So, treat an unexpected backend CLOSED state the same as CLOSING.
>>
>> Signed-off-by: David Vrabel 
>> Acked-by: Konrad Rzeszutek Wilk 
>> ---
>> Cc: linux-fbdev@vger.kernel.org
>> Cc: Florian Tobias Schandinat 
> 
> Hey Florian,
> 
> Should I prep a git pull for you with this or would it be OK
> if I just have your Ack to put this in my git pull for Linus?

Feel free to take it and add
Acked-by: Florian Tobias Schandinat 


Best regards,

Florian Tobias Schandinat

> 
> Thanks!
>> ---
>>  drivers/video/xen-fbfront.c |    5 ++++-
>>  1 files changed, 4 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/video/xen-fbfront.c b/drivers/video/xen-fbfront.c
>> index b7f5173..917bb56 100644
>> --- a/drivers/video/xen-fbfront.c
>> +++ b/drivers/video/xen-fbfront.c
>> @@ -641,7 +641,6 @@ static void xenfb_backend_changed(struct xenbus_device *dev,
>>  	case XenbusStateReconfiguring:
>>  	case XenbusStateReconfigured:
>>  	case XenbusStateUnknown:
>> -	case XenbusStateClosed:
>>  		break;
>>  
>>  	case XenbusStateInitWait:
>> @@ -670,6 +669,10 @@ InitWait:
>>  		info->feature_resize = val;
>>  		break;
>>  
>> +	case XenbusStateClosed:
>> +		if (dev->state == XenbusStateClosed)
>> +			break;
>> +		/* Missed the backend's CLOSING state -- fallthrough */
>>  	case XenbusStateClosing:
>>  		xenbus_frontend_closed(dev);
>>  		break;
>> -- 
>> 1.7.2.5
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 08:43:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 08:43:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQa4n-0004b1-2r; Tue, 23 Oct 2012 08:43:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQWSE-0002PR-5R
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 04:51:02 +0000
Received: from [85.158.143.99:7881] by server-2.bemta-4.messagelabs.com id
	7F/C4-22268-53226805; Tue, 23 Oct 2012 04:51:01 +0000
X-Env-Sender: FlorianSchandinat@gmx.de
X-Msg-Ref: server-10.tower-216.messagelabs.com!1350967860!28695811!1
X-Originating-IP: [213.165.64.23]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjEzLjE2NS42NC4yMyA9PiAyMDU0MzM=\n,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 522 invoked from network); 23 Oct 2012 04:51:00 -0000
Received: from mailout-de.gmx.net (HELO mailout-de.gmx.net) (213.165.64.23)
	by server-10.tower-216.messagelabs.com with SMTP;
	23 Oct 2012 04:51:00 -0000
Received: (qmail invoked by alias); 23 Oct 2012 04:51:00 -0000
Received: from dslb-092-074-255-099.pools.arcor-ip.net (EHLO [192.168.0.9])
	[92.74.255.99]
	by mail.gmx.net (mp001) with SMTP; 23 Oct 2012 06:51:00 +0200
X-Authenticated: #10250065
X-Provags-ID: V01U2FsdGVkX19cbgF8o4ZcypurEMbKmdhDjWfEoLtnWl2avSqtqb
	yCEobjIc8Pmf0S
Message-ID: <50862224.60908@gmx.de>
Date: Tue, 23 Oct 2012 04:50:44 +0000
From: Florian Tobias Schandinat 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120922 Icedove/3.0.11
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk 
References: <507FD39F.4060601@citrix.com>
	<1350554618-14582-4-git-send-email-david.vrabel@citrix.com>
	<20121019130011.GD26830@phenom.dumpdata.com>
In-Reply-To: <20121019130011.GD26830@phenom.dumpdata.com>
X-Y-GMX-Trusted: 0
X-Mailman-Approved-At: Tue, 23 Oct 2012 08:43:02 +0000
Cc: linux-kernel@vger.kernel.org, linux-fbdev@vger.kernel.org,
	David Vrabel , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 4/5] xen-fbfront: handle backend CLOSED
	without CLOSING
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Konrad,

On 10/19/2012 01:00 PM, Konrad Rzeszutek Wilk wrote:
> On Thu, Oct 18, 2012 at 11:03:37AM +0100, David Vrabel wrote:
>> From: David Vrabel 
>>
>> Backend drivers shouldn't transistion to CLOSED unless the frontend is
>> CLOSED.  If a backend does transition to CLOSED too soon then the
>> frontend may not see the CLOSING state and will not properly shutdown.
>>
>> So, treat an unexpected backend CLOSED state the same as CLOSING.
>>
>> Signed-off-by: David Vrabel 
>> Acked-by: Konrad Rzeszutek Wilk 
>> ---
>> Cc: linux-fbdev@vger.kernel.org
>> Cc: Florian Tobias Schandinat 
> 
> Hey Florian,
> 
> Should I prep a git pull for you with this or would it be OK
> if I just have your Ack to put this in my git pull for Linus?

Feel free to take it and add
Acked-by: Florian Tobias Schandinat 


Best regards,

Florian Tobias Schandinat

> 
> Thanks!
>> ---
>>  drivers/video/xen-fbfront.c |    5 ++++-
>>  1 files changed, 4 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/video/xen-fbfront.c b/drivers/video/xen-fbfront.c
>> index b7f5173..917bb56 100644
>> --- a/drivers/video/xen-fbfront.c
>> +++ b/drivers/video/xen-fbfront.c
>> @@ -641,7 +641,6 @@ static void xenfb_backend_changed(struct xenbus_device *dev,
>>  	case XenbusStateReconfiguring:
>>  	case XenbusStateReconfigured:
>>  	case XenbusStateUnknown:
>> -	case XenbusStateClosed:
>>  		break;
>>  
>>  	case XenbusStateInitWait:
>> @@ -670,6 +669,10 @@ InitWait:
>>  		info->feature_resize = val;
>>  		break;
>>  
>> +	case XenbusStateClosed:
>> +		if (dev->state == XenbusStateClosed)
>> +			break;
>> +		/* Missed the backend's CLOSING state -- fallthrough */
>>  	case XenbusStateClosing:
>>  		xenbus_frontend_closed(dev);
>>  		break;
>> -- 
>> 1.7.2.5
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 08:50:46 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 08:50:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQaBy-0005Ih-Tr; Tue, 23 Oct 2012 08:50:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQaBx-0005Ic-GV
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 08:50:29 +0000
Received: from [85.158.143.35:35611] by server-1.bemta-4.messagelabs.com id
	F6/E0-19134-45A56805; Tue, 23 Oct 2012 08:50:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1350982216!15064832!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11414 invoked from network); 23 Oct 2012 08:50:18 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-21.messagelabs.com with SMTP;
	23 Oct 2012 08:50:18 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 23 Oct 2012 09:50:15 +0100
Message-Id: <5086766502000078000A35D4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 23 Oct 2012 09:50:13 +0100
From: "Jan Beulich" 
To: "Mauro" 
References: 
	
	
	
	<65395f62-74e5-4910-b701-8df629c2ce3b@default>
	
	
	
	
	
	<20120930151314.GU8912@reaktio.net>
	
	
	
	<507C024602000078000A155C@nat28.tlf.novell.com>
	
	<507C226A02000078000A1657@nat28.tlf.novell.com>
	
	<508509D902000078000A2DDA@nat28.tlf.novell.com>
	
	<50852D8C02000078000A2E48@nat28.tlf.novell.com>
	
	<5085530202000078000A2F12@nat28.tlf.novell.com>
	
	<50866A2C02000078000A356D@nat28.tlf.novell.com>
	
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel 
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 23.10.12 at 10:40, Mauro  wrote:
> On 23 October 2012 09:58, Jan Beulich  wrote:
>>>>> On 23.10.12 at 09:18, Mauro  wrote:
>>>>  A kernel run with no Xen underneath it.
>>>
>>> Here is:
>>>
>>> uname -a
>>> Linux xen-p02 2.6.32-5-amd64 #1 SMP Sun Sep 23 10:07:46 UTC 2012
>>> x86_64 GNU/Linux
>>
>> I'm sorry to say that, but 2.6.32 is nowhere close to "recent" (as
>> I had asked for).
> 
> Sorry I'm using squeeze in production servers and I don't have a test
> machine on which install wheezy.

And can't/don't want to install a self-built kernel?

> There's nothing else I can do?

I told you yesterday what less invasive command line options you
could try. Plus in an earlier mail today I also asked for specific
information on which C-states the native kernel uses. If all you've
got is 2.6.32, obtaining the information there is better than nothing.

Jan

> As reported before with the workaround cpuidle=0 I don't have any problem 
> now.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 08:50:46 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 08:50:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQaBy-0005Ih-Tr; Tue, 23 Oct 2012 08:50:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQaBx-0005Ic-GV
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 08:50:29 +0000
Received: from [85.158.143.35:35611] by server-1.bemta-4.messagelabs.com id
	F6/E0-19134-45A56805; Tue, 23 Oct 2012 08:50:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1350982216!15064832!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11414 invoked from network); 23 Oct 2012 08:50:18 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-21.messagelabs.com with SMTP;
	23 Oct 2012 08:50:18 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 23 Oct 2012 09:50:15 +0100
Message-Id: <5086766502000078000A35D4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 23 Oct 2012 09:50:13 +0100
From: "Jan Beulich" 
To: "Mauro" 
References: 
	
	
	
	<65395f62-74e5-4910-b701-8df629c2ce3b@default>
	
	
	
	
	
	<20120930151314.GU8912@reaktio.net>
	
	
	
	<507C024602000078000A155C@nat28.tlf.novell.com>
	
	<507C226A02000078000A1657@nat28.tlf.novell.com>
	
	<508509D902000078000A2DDA@nat28.tlf.novell.com>
	
	<50852D8C02000078000A2E48@nat28.tlf.novell.com>
	
	<5085530202000078000A2F12@nat28.tlf.novell.com>
	
	<50866A2C02000078000A356D@nat28.tlf.novell.com>
	
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel 
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 23.10.12 at 10:40, Mauro  wrote:
> On 23 October 2012 09:58, Jan Beulich  wrote:
>>>>> On 23.10.12 at 09:18, Mauro  wrote:
>>>>  A kernel run with no Xen underneath it.
>>>
>>> Here is:
>>>
>>> uname -a
>>> Linux xen-p02 2.6.32-5-amd64 #1 SMP Sun Sep 23 10:07:46 UTC 2012
>>> x86_64 GNU/Linux
>>
>> I'm sorry to say that, but 2.6.32 is nowhere close to "recent" (as
>> I had asked for).
> 
> Sorry I'm using squeeze in production servers and I don't have a test
> machine on which install wheezy.

And can't/don't want to install a self-built kernel?

> There's nothing else I can do?

I told you yesterday what less invasive command line options you
could try. Plus in an earlier mail today I also asked for specific
information on which C-states the native kernel uses. If all you've
got is 2.6.32, obtaining the information there is better than nothing.

Jan

> As reported before with the workaround cpuidle=0 I don't have any problem 
> now.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 08:52:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 08:52:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQaDL-0005NN-DF; Tue, 23 Oct 2012 08:51:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQaDJ-0005NC-Ew
	for Xen-devel@lists.xensource.com; Tue, 23 Oct 2012 08:51:53 +0000
Received: from [85.158.138.51:26486] by server-15.bemta-3.messagelabs.com id
	66/17-10261-8AA56805; Tue, 23 Oct 2012 08:51:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1350982310!29083289!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUxNDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22950 invoked from network); 23 Oct 2012 08:51:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 08:51:50 -0000
X-IronPort-AV: E=Sophos;i="4.80,634,1344211200"; d="scan'208";a="15326913"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Oct 2012 08:51:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 23 Oct 2012 09:51:43 +0100
Message-ID: <1350982301.2237.6.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Tue, 23 Oct 2012 09:51:41 +0100
In-Reply-To: <20121019131707.GG26830@phenom.dumpdata.com>
References: <20121017172642.349b2aae@mantra.us.oracle.com>
	
	<20121019131707.GG26830@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH V3 1/6]: PVH: basic and header changes,
 elfnote changes, ...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-19 at 14:17 +0100, Konrad Rzeszutek Wilk wrote:
> > > +config XEN_X86_PVH
> > > +	bool "Support for running as a PVH guest (EXPERIMENTAL)"
> > > +	depends on X86_64 && XEN && EXPERIMENTAL
> > > +	default n
> > > +	help
> > > +	   This option enables support for running as a PVH guest (PV guest
> > > +	   using hardware extensions) under a suitably capable hypervisor.
> > > +	   This option is EXPERIMENTAL because the hypervisor interfaces
> > > +	   which it uses are not yet considered stable therefore backwards and
> > > +	   forwards compatibility is not yet guaranteed.  If unsure, say N.
> > 
> > Do we really need the kconfig symbol? Why can't we have it always
> 
> Yes for right now. That is to make sure that we can test for regressions
> PV guests on a hypervisor without PVH extensions - or vice-versa:
> PVH hypervisors with an normal PV guest.

Also the "depends on X86_64" bit is currently quite important...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 08:52:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 08:52:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQaDL-0005NN-DF; Tue, 23 Oct 2012 08:51:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQaDJ-0005NC-Ew
	for Xen-devel@lists.xensource.com; Tue, 23 Oct 2012 08:51:53 +0000
Received: from [85.158.138.51:26486] by server-15.bemta-3.messagelabs.com id
	66/17-10261-8AA56805; Tue, 23 Oct 2012 08:51:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1350982310!29083289!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUxNDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22950 invoked from network); 23 Oct 2012 08:51:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 08:51:50 -0000
X-IronPort-AV: E=Sophos;i="4.80,634,1344211200"; d="scan'208";a="15326913"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Oct 2012 08:51:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 23 Oct 2012 09:51:43 +0100
Message-ID: <1350982301.2237.6.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Tue, 23 Oct 2012 09:51:41 +0100
In-Reply-To: <20121019131707.GG26830@phenom.dumpdata.com>
References: <20121017172642.349b2aae@mantra.us.oracle.com>
	
	<20121019131707.GG26830@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH V3 1/6]: PVH: basic and header changes,
 elfnote changes, ...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-19 at 14:17 +0100, Konrad Rzeszutek Wilk wrote:
> > > +config XEN_X86_PVH
> > > +	bool "Support for running as a PVH guest (EXPERIMENTAL)"
> > > +	depends on X86_64 && XEN && EXPERIMENTAL
> > > +	default n
> > > +	help
> > > +	   This option enables support for running as a PVH guest (PV guest
> > > +	   using hardware extensions) under a suitably capable hypervisor.
> > > +	   This option is EXPERIMENTAL because the hypervisor interfaces
> > > +	   which it uses are not yet considered stable therefore backwards and
> > > +	   forwards compatibility is not yet guaranteed.  If unsure, say N.
> > 
> > Do we really need the kconfig symbol? Why can't we have it always
> 
> Yes for right now. That is to make sure that we can test for regressions
> PV guests on a hypervisor without PVH extensions - or vice-versa:
> PVH hypervisors with an normal PV guest.

Also the "depends on X86_64" bit is currently quite important...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 09:05:18 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 09:05:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQaQ1-0005fe-MW; Tue, 23 Oct 2012 09:05:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQaQ0-0005fZ-9t
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 09:05:00 +0000
Received: from [85.158.143.99:48657] by server-2.bemta-4.messagelabs.com id
	25/A3-22268-BBD56805; Tue, 23 Oct 2012 09:04:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1350983099!28921122!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUxNDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19885 invoked from network); 23 Oct 2012 09:04:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 09:04:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,634,1344211200"; d="scan'208";a="15327382"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Oct 2012 09:04:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 23 Oct 2012 10:04:59 +0100
Message-ID: <1350983097.2237.14.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Matt Wilson 
Date: Tue, 23 Oct 2012 10:04:57 +0100
In-Reply-To: <1350668075-5840-1-git-send-email-msw@amazon.com>
References: <1350668075-5840-1-git-send-email-msw@amazon.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Paul Harvey ,
	"xen-devel@lists.xen.org" ,
	Nikita Borzykh ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH] xen-netback: allow changing the MAC address
 of the interface
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-19 at 18:34 +0100, Matt Wilson wrote:
> Reported-by: Nikita Borzykh 
> Reported-by: Paul Harvey 
> Suggested-by: Ian Campbell 

I can't remember that but it seems reasonable:

Acked-by: Ian Campbell 

But, can you remind us of the usecase? Perhaps in the commit message?

Lastly, netback patches should be sent to netdev@vger.kernel.org as per
MAINTAINERS in order to be applied.

Thanks,
Ian.


> Signed-off-by: Matt Wilson 
> ---
>  drivers/net/xen-netback/interface.c |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
> index b7d41f8..f733cae 100644
> --- a/drivers/net/xen-netback/interface.c
> +++ b/drivers/net/xen-netback/interface.c
> @@ -238,6 +238,8 @@ static const struct net_device_ops xenvif_netdev_ops = {
>  	.ndo_stop	= xenvif_close,
>  	.ndo_change_mtu	= xenvif_change_mtu,
>  	.ndo_fix_features = xenvif_fix_features,
> +	.ndo_set_mac_address = eth_mac_addr,
> +	.ndo_validate_addr   = eth_validate_addr,
>  };
>  
>  struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 09:05:18 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 09:05:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQaQ1-0005fe-MW; Tue, 23 Oct 2012 09:05:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQaQ0-0005fZ-9t
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 09:05:00 +0000
Received: from [85.158.143.99:48657] by server-2.bemta-4.messagelabs.com id
	25/A3-22268-BBD56805; Tue, 23 Oct 2012 09:04:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1350983099!28921122!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUxNDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19885 invoked from network); 23 Oct 2012 09:04:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 09:04:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,634,1344211200"; d="scan'208";a="15327382"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Oct 2012 09:04:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 23 Oct 2012 10:04:59 +0100
Message-ID: <1350983097.2237.14.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Matt Wilson 
Date: Tue, 23 Oct 2012 10:04:57 +0100
In-Reply-To: <1350668075-5840-1-git-send-email-msw@amazon.com>
References: <1350668075-5840-1-git-send-email-msw@amazon.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Paul Harvey ,
	"xen-devel@lists.xen.org" ,
	Nikita Borzykh ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH] xen-netback: allow changing the MAC address
 of the interface
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-19 at 18:34 +0100, Matt Wilson wrote:
> Reported-by: Nikita Borzykh 
> Reported-by: Paul Harvey 
> Suggested-by: Ian Campbell 

I can't remember that but it seems reasonable:

Acked-by: Ian Campbell 

But, can you remind us of the usecase? Perhaps in the commit message?

Lastly, netback patches should be sent to netdev@vger.kernel.org as per
MAINTAINERS in order to be applied.

Thanks,
Ian.


> Signed-off-by: Matt Wilson 
> ---
>  drivers/net/xen-netback/interface.c |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
> index b7d41f8..f733cae 100644
> --- a/drivers/net/xen-netback/interface.c
> +++ b/drivers/net/xen-netback/interface.c
> @@ -238,6 +238,8 @@ static const struct net_device_ops xenvif_netdev_ops = {
>  	.ndo_stop	= xenvif_close,
>  	.ndo_change_mtu	= xenvif_change_mtu,
>  	.ndo_fix_features = xenvif_fix_features,
> +	.ndo_set_mac_address = eth_mac_addr,
> +	.ndo_validate_addr   = eth_validate_addr,
>  };
>  
>  struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 09:23:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 09:23:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQah6-0005sd-N1; Tue, 23 Oct 2012 09:22:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQah5-0005sY-I2
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 09:22:39 +0000
Received: from [85.158.139.83:47292] by server-9.bemta-5.messagelabs.com id
	ED/5C-23053-ED166805; Tue, 23 Oct 2012 09:22:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1350984157!31535068!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUxNDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22025 invoked from network); 23 Oct 2012 09:22:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 09:22:38 -0000
X-IronPort-AV: E=Sophos;i="4.80,634,1344211200"; d="scan'208";a="15327914"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Oct 2012 09:22:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 23 Oct 2012 10:22:19 +0100
Message-ID: <1350984138.2237.22.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Tue, 23 Oct 2012 10:22:18 +0100
In-Reply-To: <1350673381-20342-1-git-send-email-konrad.wilk@oracle.com>
References: <1350673381-20342-1-git-send-email-konrad.wilk@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" 
Subject: Re: [Xen-devel] [PATCH] xen/hvm: If we fail to fetch an HVM
 parameter print out which flag it is.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-19 at 20:03 +0100, Konrad Rzeszutek Wilk wrote:
> Makes it easier to troubleshoot in the field.
> 
> Signed-off-by: Konrad Rzeszutek Wilk 
> ---
>  include/xen/hvm.h |   31 +++++++++++++++++++++++++++++--
>  1 files changed, 29 insertions(+), 2 deletions(-)
> 
> diff --git a/include/xen/hvm.h b/include/xen/hvm.h
> index b193fa2..c2a4238 100644
> --- a/include/xen/hvm.h
> +++ b/include/xen/hvm.h
> @@ -5,6 +5,33 @@
>  #include 
>  #include 
>  
> +static const char *param_name(int op)
> +{
> +	static const char *const names[] = {

#define PARAM(x) [x] = STRINGIFY(x)
would save from typos due to doubling everything up.

Or even:
#define PARAM(x) [HVM_PARAM#_x] STRINGIFY(x)

> +		[HVM_PARAM_CALLBACK_IRQ] = "HVM_PARAM_CALLBACK_IRQ",
> +		[HVM_PARAM_STORE_PFN] = "HVM_PARAM_STORE_PFN",
> +		[HVM_PARAM_STORE_EVTCHN] = "HVM_PARAM_STORE_EVTCHN",
> +		[HVM_PARAM_PAE_ENABLED] = "HVM_PARAM_PAE_ENABLED",
> +		[HVM_PARAM_IOREQ_PFN] = "HVM_PARAM_IOREQ_PFN",
> +		[HVM_PARAM_BUFIOREQ_PFN] = "HVM_PARAM_BUFIOREQ_PFN",
> +		[HVM_PARAM_TIMER_MODE] = "HVM_PARAM_TIMER_MODE",
> +		[HVM_PARAM_HPET_ENABLED] = "HVM_PARAM_HPET_ENABLED",
> +		[HVM_PARAM_IDENT_PT] = "HVM_PARAM_IDENT_PT",
> +		[HVM_PARAM_DM_DOMAIN] = "HVM_PARAM_DM_DOMAIN",
> +		[HVM_PARAM_ACPI_S_STATE] = "HVM_PARAM_ACPI_S_STATE",
> +		[HVM_PARAM_VM86_TSS] = "HVM_PARAM_VM86_TSS",
> +		[HVM_PARAM_VPT_ALIGN] = "HVM_PARAM_VPT_ALIGN",
> +		[HVM_PARAM_CONSOLE_PFN] = "HVM_PARAM_CONSOLE_PFN",
> +		[HVM_PARAM_CONSOLE_EVTCHN] = "HVM_PARAM_CONSOLE_EVTCHN" };

You probably want a , and a newline before the }.

> +
> +	if (op >= ARRAY_SIZE(names))
> +		return "unknown";
> +
> +	if (!names[op])
> +		return "reserved";
> +
> +	return names[op];
> +}
>  static inline int hvm_get_parameter(int idx, uint64_t *value)
>  {
>  	struct xen_hvm_param xhv;
> @@ -14,8 +41,8 @@ static inline int hvm_get_parameter(int idx, uint64_t *value)
>  	xhv.index = idx;
>  	r = HYPERVISOR_hvm_op(HVMOP_get_param, &xhv);
>  	if (r < 0) {
> -		printk(KERN_ERR "Cannot get hvm parameter %d: %d!\n",
> -			idx, r);
> +		printk(KERN_ERR "Cannot get hvm parameter %s (%d): %d!\n",
> +			param_name(idx), idx, r);
>  		return r;
>  	}
>  	*value = xhv.value;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 09:23:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 09:23:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQah6-0005sd-N1; Tue, 23 Oct 2012 09:22:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQah5-0005sY-I2
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 09:22:39 +0000
Received: from [85.158.139.83:47292] by server-9.bemta-5.messagelabs.com id
	ED/5C-23053-ED166805; Tue, 23 Oct 2012 09:22:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1350984157!31535068!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUxNDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22025 invoked from network); 23 Oct 2012 09:22:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 09:22:38 -0000
X-IronPort-AV: E=Sophos;i="4.80,634,1344211200"; d="scan'208";a="15327914"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Oct 2012 09:22:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 23 Oct 2012 10:22:19 +0100
Message-ID: <1350984138.2237.22.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Tue, 23 Oct 2012 10:22:18 +0100
In-Reply-To: <1350673381-20342-1-git-send-email-konrad.wilk@oracle.com>
References: <1350673381-20342-1-git-send-email-konrad.wilk@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" 
Subject: Re: [Xen-devel] [PATCH] xen/hvm: If we fail to fetch an HVM
 parameter print out which flag it is.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-19 at 20:03 +0100, Konrad Rzeszutek Wilk wrote:
> Makes it easier to troubleshoot in the field.
> 
> Signed-off-by: Konrad Rzeszutek Wilk 
> ---
>  include/xen/hvm.h |   31 +++++++++++++++++++++++++++++--
>  1 files changed, 29 insertions(+), 2 deletions(-)
> 
> diff --git a/include/xen/hvm.h b/include/xen/hvm.h
> index b193fa2..c2a4238 100644
> --- a/include/xen/hvm.h
> +++ b/include/xen/hvm.h
> @@ -5,6 +5,33 @@
>  #include 
>  #include 
>  
> +static const char *param_name(int op)
> +{
> +	static const char *const names[] = {

#define PARAM(x) [x] = STRINGIFY(x)
would save from typos due to doubling everything up.

Or even:
#define PARAM(x) [HVM_PARAM#_x] STRINGIFY(x)

> +		[HVM_PARAM_CALLBACK_IRQ] = "HVM_PARAM_CALLBACK_IRQ",
> +		[HVM_PARAM_STORE_PFN] = "HVM_PARAM_STORE_PFN",
> +		[HVM_PARAM_STORE_EVTCHN] = "HVM_PARAM_STORE_EVTCHN",
> +		[HVM_PARAM_PAE_ENABLED] = "HVM_PARAM_PAE_ENABLED",
> +		[HVM_PARAM_IOREQ_PFN] = "HVM_PARAM_IOREQ_PFN",
> +		[HVM_PARAM_BUFIOREQ_PFN] = "HVM_PARAM_BUFIOREQ_PFN",
> +		[HVM_PARAM_TIMER_MODE] = "HVM_PARAM_TIMER_MODE",
> +		[HVM_PARAM_HPET_ENABLED] = "HVM_PARAM_HPET_ENABLED",
> +		[HVM_PARAM_IDENT_PT] = "HVM_PARAM_IDENT_PT",
> +		[HVM_PARAM_DM_DOMAIN] = "HVM_PARAM_DM_DOMAIN",
> +		[HVM_PARAM_ACPI_S_STATE] = "HVM_PARAM_ACPI_S_STATE",
> +		[HVM_PARAM_VM86_TSS] = "HVM_PARAM_VM86_TSS",
> +		[HVM_PARAM_VPT_ALIGN] = "HVM_PARAM_VPT_ALIGN",
> +		[HVM_PARAM_CONSOLE_PFN] = "HVM_PARAM_CONSOLE_PFN",
> +		[HVM_PARAM_CONSOLE_EVTCHN] = "HVM_PARAM_CONSOLE_EVTCHN" };

You probably want a , and a newline before the }.

> +
> +	if (op >= ARRAY_SIZE(names))
> +		return "unknown";
> +
> +	if (!names[op])
> +		return "reserved";
> +
> +	return names[op];
> +}
>  static inline int hvm_get_parameter(int idx, uint64_t *value)
>  {
>  	struct xen_hvm_param xhv;
> @@ -14,8 +41,8 @@ static inline int hvm_get_parameter(int idx, uint64_t *value)
>  	xhv.index = idx;
>  	r = HYPERVISOR_hvm_op(HVMOP_get_param, &xhv);
>  	if (r < 0) {
> -		printk(KERN_ERR "Cannot get hvm parameter %d: %d!\n",
> -			idx, r);
> +		printk(KERN_ERR "Cannot get hvm parameter %s (%d): %d!\n",
> +			param_name(idx), idx, r);
>  		return r;
>  	}
>  	*value = xhv.value;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 10:17:12 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 10:17:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQbXQ-0006QC-JH; Tue, 23 Oct 2012 10:16:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQbXP-0006Q7-Pg
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 10:16:43 +0000
Received: from [85.158.138.51:62106] by server-6.bemta-3.messagelabs.com id
	53/52-32375-A8E66805; Tue, 23 Oct 2012 10:16:42 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1350987380!35337625!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODIwNzA4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9366 invoked from network); 23 Oct 2012 10:16:22 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Oct 2012 10:16:22 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9NAGHXQ002488
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 23 Oct 2012 10:16:18 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9NAGH2x011980
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 23 Oct 2012 10:16:17 GMT
Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9NAGGlL031789; Tue, 23 Oct 2012 05:16:16 -0500
MIME-Version: 1.0
Message-ID: <383bffd3-c605-449a-8ff3-35eee4e75b48@default>
Date: Tue, 23 Oct 2012 03:16:16 -0700 (PDT)
From: Daniel Kiper 
To: 
X-Mailer: Zimbra on Oracle Beehive
Content-Disposition: inline
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xen.org, JBeulich@suse.com, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] Xen 4.2 with EFI on IBM x3650 ACPI Bug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

> Thank's Jan and Daniel, i am using now

I think that you meant Konrad because I did not help a lot.

[...]

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 10:17:12 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 10:17:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQbXQ-0006QC-JH; Tue, 23 Oct 2012 10:16:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQbXP-0006Q7-Pg
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 10:16:43 +0000
Received: from [85.158.138.51:62106] by server-6.bemta-3.messagelabs.com id
	53/52-32375-A8E66805; Tue, 23 Oct 2012 10:16:42 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1350987380!35337625!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODIwNzA4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9366 invoked from network); 23 Oct 2012 10:16:22 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Oct 2012 10:16:22 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9NAGHXQ002488
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 23 Oct 2012 10:16:18 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9NAGH2x011980
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 23 Oct 2012 10:16:17 GMT
Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9NAGGlL031789; Tue, 23 Oct 2012 05:16:16 -0500
MIME-Version: 1.0
Message-ID: <383bffd3-c605-449a-8ff3-35eee4e75b48@default>
Date: Tue, 23 Oct 2012 03:16:16 -0700 (PDT)
From: Daniel Kiper 
To: 
X-Mailer: Zimbra on Oracle Beehive
Content-Disposition: inline
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xen.org, JBeulich@suse.com, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] Xen 4.2 with EFI on IBM x3650 ACPI Bug
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

> Thank's Jan and Daniel, i am using now

I think that you meant Konrad because I did not help a lot.

[...]

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 11:51:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 11:51:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQczx-0006sQ-Tb; Tue, 23 Oct 2012 11:50:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQczw-0006sI-Vo
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 11:50:17 +0000
Received: from [85.158.137.99:3681] by server-12.bemta-3.messagelabs.com id
	E2/21-27853-37486805; Tue, 23 Oct 2012 11:50:11 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1350993009!19559631!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 861 invoked from network); 23 Oct 2012 11:50:11 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 11:50:11 -0000
Received: by mail-vc0-f173.google.com with SMTP id fl15so1295094vcb.32
	for ; Tue, 23 Oct 2012 04:50:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=AW8reUyRAMFm0M+ONF9Ls5Tu3+OswBx4PNQTpmDi7S4=;
	b=XuUuNZBwFac6gIvSO/qayXhDAifbAO32kmfrhogK14DAxBRZiJNE6Vn6DOcPowCZPb
	qx76EyGD3xe3rnndIGN9g44m0YEfF4/H5YSw9sqHgUD7CcL3C3t3p9DVUxnWjbScTSq/
	ZJXUSvZlxn0mbTeeuMlgzQt58lV9iEvQRlpBDn8S2lYHyeVnGEQ2EqjgM8YYBHZ2WmoY
	1uDXqY5w0xRLMQbFD7iftbgue1O1hrcP8ql2lM2WoJd2Pd5hyTm1TnZycjtRVjH5mVRl
	k0zX9Kt7SNCETzwi26sj5CzVnz/kPKjG5I2t5FQ1AdxG7rK0h5ow/fI82yWU7CKPsSiU
	o76Q==
Received: by 10.220.40.16 with SMTP id i16mr1604771vce.31.1350993009337;
	Tue, 23 Oct 2012 04:50:09 -0700 (PDT)
Received: from localhost.localdomain
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id w17sm12913680vdf.16.2012.10.23.04.50.08
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 23 Oct 2012 04:50:08 -0700 (PDT)
Date: Tue, 23 Oct 2012 07:50:02 -0400
From: Konrad Rzeszutek Wilk 
To: Jan Beulich 
Message-ID: <20121023115001.GA23471@localhost.localdomain>
References: 
	<508509D902000078000A2DDA@nat28.tlf.novell.com>
	
	<50852D8C02000078000A2E48@nat28.tlf.novell.com>
	
	<5085530202000078000A2F12@nat28.tlf.novell.com>
	
	<50866A2C02000078000A356D@nat28.tlf.novell.com>
	
	<5086766502000078000A35D4@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5086766502000078000A35D4@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Mauro , xen-devel 
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 23, 2012 at 09:50:13AM +0100, Jan Beulich wrote:
> >>> On 23.10.12 at 10:40, Mauro  wrote:
> > On 23 October 2012 09:58, Jan Beulich  wrote:
> >>>>> On 23.10.12 at 09:18, Mauro  wrote:
> >>>>  A kernel run with no Xen underneath it.
> >>>
> >>> Here is:
> >>>
> >>> uname -a
> >>> Linux xen-p02 2.6.32-5-amd64 #1 SMP Sun Sep 23 10:07:46 UTC 2012
> >>> x86_64 GNU/Linux
> >>
> >> I'm sorry to say that, but 2.6.32 is nowhere close to "recent" (as
> >> I had asked for).
> > 
> > Sorry I'm using squeeze in production servers and I don't have a test
> > machine on which install wheezy.
> 
> And can't/don't want to install a self-built kernel?

You could also boot one of those Live Image kernels. Like an Fedora or
Ubuntu and just capture this. That way you don't over-write anything.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 11:51:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 11:51:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQczx-0006sQ-Tb; Tue, 23 Oct 2012 11:50:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQczw-0006sI-Vo
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 11:50:17 +0000
Received: from [85.158.137.99:3681] by server-12.bemta-3.messagelabs.com id
	E2/21-27853-37486805; Tue, 23 Oct 2012 11:50:11 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1350993009!19559631!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 861 invoked from network); 23 Oct 2012 11:50:11 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 11:50:11 -0000
Received: by mail-vc0-f173.google.com with SMTP id fl15so1295094vcb.32
	for ; Tue, 23 Oct 2012 04:50:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=AW8reUyRAMFm0M+ONF9Ls5Tu3+OswBx4PNQTpmDi7S4=;
	b=XuUuNZBwFac6gIvSO/qayXhDAifbAO32kmfrhogK14DAxBRZiJNE6Vn6DOcPowCZPb
	qx76EyGD3xe3rnndIGN9g44m0YEfF4/H5YSw9sqHgUD7CcL3C3t3p9DVUxnWjbScTSq/
	ZJXUSvZlxn0mbTeeuMlgzQt58lV9iEvQRlpBDn8S2lYHyeVnGEQ2EqjgM8YYBHZ2WmoY
	1uDXqY5w0xRLMQbFD7iftbgue1O1hrcP8ql2lM2WoJd2Pd5hyTm1TnZycjtRVjH5mVRl
	k0zX9Kt7SNCETzwi26sj5CzVnz/kPKjG5I2t5FQ1AdxG7rK0h5ow/fI82yWU7CKPsSiU
	o76Q==
Received: by 10.220.40.16 with SMTP id i16mr1604771vce.31.1350993009337;
	Tue, 23 Oct 2012 04:50:09 -0700 (PDT)
Received: from localhost.localdomain
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id w17sm12913680vdf.16.2012.10.23.04.50.08
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 23 Oct 2012 04:50:08 -0700 (PDT)
Date: Tue, 23 Oct 2012 07:50:02 -0400
From: Konrad Rzeszutek Wilk 
To: Jan Beulich 
Message-ID: <20121023115001.GA23471@localhost.localdomain>
References: 
	<508509D902000078000A2DDA@nat28.tlf.novell.com>
	
	<50852D8C02000078000A2E48@nat28.tlf.novell.com>
	
	<5085530202000078000A2F12@nat28.tlf.novell.com>
	
	<50866A2C02000078000A356D@nat28.tlf.novell.com>
	
	<5086766502000078000A35D4@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5086766502000078000A35D4@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Mauro , xen-devel 
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 23, 2012 at 09:50:13AM +0100, Jan Beulich wrote:
> >>> On 23.10.12 at 10:40, Mauro  wrote:
> > On 23 October 2012 09:58, Jan Beulich  wrote:
> >>>>> On 23.10.12 at 09:18, Mauro  wrote:
> >>>>  A kernel run with no Xen underneath it.
> >>>
> >>> Here is:
> >>>
> >>> uname -a
> >>> Linux xen-p02 2.6.32-5-amd64 #1 SMP Sun Sep 23 10:07:46 UTC 2012
> >>> x86_64 GNU/Linux
> >>
> >> I'm sorry to say that, but 2.6.32 is nowhere close to "recent" (as
> >> I had asked for).
> > 
> > Sorry I'm using squeeze in production servers and I don't have a test
> > machine on which install wheezy.
> 
> And can't/don't want to install a self-built kernel?

You could also boot one of those Live Image kernels. Like an Fedora or
Ubuntu and just capture this. That way you don't over-write anything.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 12:27:23 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 12:27:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQdZG-0007J9-1q; Tue, 23 Oct 2012 12:26:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQdZD-0007J4-I6
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 12:26:43 +0000
Received: from [85.158.137.99:22984] by server-5.bemta-3.messagelabs.com id
	BE/BA-12440-20D86805; Tue, 23 Oct 2012 12:26:42 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1350995201!17966575!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUyMjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26407 invoked from network); 23 Oct 2012 12:26:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 12:26:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,634,1344211200"; d="scan'208";a="15333432"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Oct 2012 12:26:17 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 23 Oct 2012 13:26:17 +0100
Date: Tue, 23 Oct 2012 13:25:48 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Konrad Rzeszutek Wilk 
In-Reply-To: <20121022201451.GJ25200@phenom.dumpdata.com>
Message-ID: 
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
	<1350695882-12820-3-git-send-email-konrad.wilk@oracle.com>
	
	<20121022113154.0e28ff1d@mantra.us.oracle.com>
	<20121022201451.GJ25200@phenom.dumpdata.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Ian Campbell ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 2/6] xen/pvh: Extend vcpu_guest_context, p2m,
 event, and xenbus to support PVH.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 22 Oct 2012, Konrad Rzeszutek Wilk wrote:
> On Mon, Oct 22, 2012 at 11:31:54AM -0700, Mukesh Rathor wrote:
> > On Mon, 22 Oct 2012 14:44:40 +0100
> > Stefano Stabellini  wrote:
> >
> > > On Sat, 20 Oct 2012, Konrad Rzeszutek Wilk wrote:
> > > > From: Mukesh Rathor 
> > > >
> > > > make gdt_frames[]/gdt_ents into a union with {gdtaddr, gdtsz}, as
> > > > PVH only needs to send down gdtaddr and gdtsz.
> > > >
> > > > For interrupts, PVH uses native_irq_ops.
> > > > vcpu hotplug is currently not available for PVH.
> > > >
> > > > For events we follow what PVHVM does - to use callback vector.
> > > > Lastly, also use HVM path to setup XenBus.
> > > >
> > > > Signed-off-by: Mukesh Rathor 
> > > > Signed-off-by: Konrad Rzeszutek Wilk 
> > > > ---
> > > >           return true;
> > > >   }
> > > > - xen_copy_trap_info(ctxt->trap_ctxt);
> > > > + /* check for autoxlated to get it right for 32bit kernel */
> > >
> > > I am not sure what this comment means, considering that in another
> > > comment below you say that we don't support 32bit PVH kernels.
> >
> > Function is common to both 32bit and 64bit kernels. We need to check
> > for auto xlated also in the if statement in addition to supervisor
> > mode kernel, so 32 bit doesn't go down the wrong path.
> 
> Can one just make it #ifdef CONFIG_X86_64 for the whole thing?
> You are either way during bootup doing a 'BUG' when booting as 32-bit?
> 
> 
> >
> > PVH is not supported for 32bit kernels, and gs_base_user doesn't exist
> > in the structure for 32bit so it needs to be if'def'd 64bit which is
> > ok because PVH is not supprted on 32bit kernel.
> >
> > > > +                                 (unsigned
> > > > long)xen_hypervisor_callback;
> > > > +         ctxt->failsafe_callback_eip =
> > > > +                                 (unsigned
> > > > long)xen_failsafe_callback;
> > > > + }
> > > > + ctxt->user_regs.cs = __KERNEL_CS;
> > > > + ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct
> > > > pt_regs);
> > > >   per_cpu(xen_cr3, cpu) = __pa(swapper_pg_dir);
> > > >   ctxt->ctrlreg[3] =
> > > > xen_pfn_to_cr3(virt_to_mfn(swapper_pg_dir));
> > >
> > > The tradional path looks the same as before, however it is hard to
> > > tell whether the PVH path is correct without the Xen side. For
> > > example, what is gdtsz?
> >
> > gdtsz is GUEST_GDTR_LIMIT and gdtaddr is GUEST_GDTR_BASE in the vmcs.
> 
> looking at this I figured it could be a bit neater. So I split it in
> two patches which should make it easier to read the PVH one.

It is much more readable now, thanks!

You can have my ack on both of them.



> >From f9455e293169d73e5698df62801bcd5fd64a5259 Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk 
> Date: Mon, 22 Oct 2012 11:35:16 -0400
> Subject: [PATCH 1/2] xen/smp: Move the common CPU init code a bit to prep for
>  PVH patch.
> 
> The PV and PVH code CPU init code share some functionality. The
> PVH code ("xen/pvh: Extend vcpu_guest_context, p2m, event, and XenBus")
> sets some of these up, but not all. To make it easier to read, this
> patch removes the PV specific out of the generic way.
> 
> No functional change, just code move.
> 
> Signed-off-by: Konrad Rzeszutek Wilk 
> ---
>  arch/x86/xen/smp.c |   42 +++++++++++++++++++++++-------------------
>  1 files changed, 23 insertions(+), 19 deletions(-)
> 
> diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
> index 353c50f..ba49a3a 100644
> --- a/arch/x86/xen/smp.c
> +++ b/arch/x86/xen/smp.c
> @@ -300,8 +300,6 @@ cpu_initialize_context(unsigned int cpu, struct task_struct *idle)
>         gdt = get_cpu_gdt_table(cpu);
> 
>         ctxt->flags = VGCF_IN_KERNEL;
> -       ctxt->user_regs.ds = __USER_DS;
> -       ctxt->user_regs.es = __USER_DS;
>         ctxt->user_regs.ss = __KERNEL_DS;
>  #ifdef CONFIG_X86_32
>         ctxt->user_regs.fs = __KERNEL_PERCPU;
> @@ -310,35 +308,41 @@ cpu_initialize_context(unsigned int cpu, struct task_struct *idle)
>         ctxt->gs_base_kernel = per_cpu_offset(cpu);
>  #endif
>         ctxt->user_regs.eip = (unsigned long)cpu_bringup_and_idle;
> -       ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
> 
>         memset(&ctxt->fpu_ctxt, 0, sizeof(ctxt->fpu_ctxt));
> 
> -       xen_copy_trap_info(ctxt->trap_ctxt);
> +       {
> +               ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
> +               ctxt->user_regs.ds = __USER_DS;
> +               ctxt->user_regs.es = __USER_DS;
> 
> -       ctxt->ldt_ents = 0;
> +               xen_copy_trap_info(ctxt->trap_ctxt);
> 
> -       BUG_ON((unsigned long)gdt & ~PAGE_MASK);
> +               ctxt->ldt_ents = 0;
> 
> -       gdt_mfn = arbitrary_virt_to_mfn(gdt);
> -       make_lowmem_page_readonly(gdt);
> -       make_lowmem_page_readonly(mfn_to_virt(gdt_mfn));
> +               BUG_ON((unsigned long)gdt & ~PAGE_MASK);
> 
> -       ctxt->gdt_frames[0] = gdt_mfn;
> -       ctxt->gdt_ents      = GDT_ENTRIES;
> +               gdt_mfn = arbitrary_virt_to_mfn(gdt);
> +               make_lowmem_page_readonly(gdt);
> +               make_lowmem_page_readonly(mfn_to_virt(gdt_mfn));
> 
> -       ctxt->user_regs.cs = __KERNEL_CS;
> -       ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct pt_regs);
> +               ctxt->u.pv.gdt_frames[0] = gdt_mfn;
> +               ctxt->u.pv.gdt_ents      = GDT_ENTRIES;
> 
> -       ctxt->kernel_ss = __KERNEL_DS;
> -       ctxt->kernel_sp = idle->thread.sp0;
> +               ctxt->kernel_ss = __KERNEL_DS;
> +               ctxt->kernel_sp = idle->thread.sp0;
> 
>  #ifdef CONFIG_X86_32
> -       ctxt->event_callback_cs     = __KERNEL_CS;
> -       ctxt->failsafe_callback_cs  = __KERNEL_CS;
> +               ctxt->event_callback_cs     = __KERNEL_CS;
> +               ctxt->failsafe_callback_cs  = __KERNEL_CS;
>  #endif
> -       ctxt->event_callback_eip    = (unsigned long)xen_hypervisor_callback;
> -       ctxt->failsafe_callback_eip = (unsigned long)xen_failsafe_callback;
> +               ctxt->event_callback_eip    =
> +                                       (unsigned long)xen_hypervisor_callback;
> +               ctxt->failsafe_callback_eip =
> +                                       (unsigned long)xen_failsafe_callback;
> +       }
> +       ctxt->user_regs.cs = __KERNEL_CS;
> +       ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct pt_regs);
> 
>         per_cpu(xen_cr3, cpu) = __pa(swapper_pg_dir);
>         ctxt->ctrlreg[3] = xen_pfn_to_cr3(virt_to_mfn(swapper_pg_dir));
> --
> 1.7.7.6
> 
> 
> 
> 
> >From 2c4dd7f567b229451f3dc1ae00d784da8b4a5072 Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk 
> Date: Mon, 22 Oct 2012 11:37:57 -0400
> Subject: [PATCH 2/2] xen/pvh: Extend vcpu_guest_context, p2m, event, and
>  XenBus.
> 
> Make gdt_frames[]/gdt_ents into a union with {gdtaddr, gdtsz},
> as PVH only needs to send down gdtaddr and gdtsz in the
> vcpu_guest_context structure..
> 
> For interrupts, PVH uses native_irq_ops so we can skip most of the
> PV ones. In the future we can support the pirq_eoi_map..
> Also VCPU hotplug is currently not available for PVH.
> 
> For events (and IRQs) we follow what PVHVM does - so use callback
> vector.  Lastly, for XenBus we use the same logic that is used in
> the PVHVM case.
> 
> Signed-off-by: Mukesh Rathor 
> [v2: Rebased it]
> [v3: Move 64-bit ifdef and based on Stefan add extra comments.]
> Signed-off-by: Konrad Rzeszutek Wilk 
> ---
>  arch/x86/include/asm/xen/interface.h |   11 +++++++++-
>  arch/x86/xen/irq.c                   |    5 +++-
>  arch/x86/xen/p2m.c                   |    2 +-
>  arch/x86/xen/smp.c                   |   36 ++++++++++++++++++++++++++-------
>  drivers/xen/cpu_hotplug.c            |    4 ++-
>  drivers/xen/events.c                 |    9 +++++++-
>  drivers/xen/xenbus/xenbus_client.c   |    3 +-
>  7 files changed, 56 insertions(+), 14 deletions(-)
> 
> diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
> index 6d2f75a..4c08f23 100644
> --- a/arch/x86/include/asm/xen/interface.h
> +++ b/arch/x86/include/asm/xen/interface.h
> @@ -144,7 +144,16 @@ struct vcpu_guest_context {
>      struct cpu_user_regs user_regs;         /* User-level CPU registers     */
>      struct trap_info trap_ctxt[256];        /* Virtual IDT                  */
>      unsigned long ldt_base, ldt_ents;       /* LDT (linear address, # ents) */
> -    unsigned long gdt_frames[16], gdt_ents; /* GDT (machine frames, # ents) */
> +    union {
> +       struct {
> +               /* PV: GDT (machine frames, # ents).*/
> +               unsigned long gdt_frames[16], gdt_ents;
> +       } pv;
> +       struct {
> +               /* PVH: GDTR addr and size */
> +               unsigned long gdtaddr, gdtsz;
> +       } pvh;
> +    } u;
>      unsigned long kernel_ss, kernel_sp;     /* Virtual TSS (only SS1/SP1)   */
>      /* NB. User pagetable on x86/64 is placed in ctrlreg[1]. */
>      unsigned long ctrlreg[8];               /* CR0-CR7 (control registers)  */
> diff --git a/arch/x86/xen/irq.c b/arch/x86/xen/irq.c
> index 01a4dc0..fcbe56a 100644
> --- a/arch/x86/xen/irq.c
> +++ b/arch/x86/xen/irq.c
> @@ -5,6 +5,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
> 
>  #include 
> @@ -129,6 +130,8 @@ static const struct pv_irq_ops xen_irq_ops __initconst = {
> 
>  void __init xen_init_irq_ops(void)
>  {
> -       pv_irq_ops = xen_irq_ops;
> +       /* For PVH we use default pv_irq_ops settings */
> +       if (!xen_feature(XENFEAT_hvm_callback_vector))
> +               pv_irq_ops = xen_irq_ops;
>         x86_init.irqs.intr_init = xen_init_IRQ;
>  }
> diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
> index 95fb2aa..ea553c8 100644
> --- a/arch/x86/xen/p2m.c
> +++ b/arch/x86/xen/p2m.c
> @@ -798,7 +798,7 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
>  {
>         unsigned topidx, mididx, idx;
> 
> -       if (unlikely(xen_feature(XENFEAT_auto_translated_physmap))) {
> +       if (xen_feature(XENFEAT_auto_translated_physmap)) {
>                 BUG_ON(pfn != mfn && mfn != INVALID_P2M_ENTRY);
>                 return true;
>         }
> diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
> index ba49a3a..6f831a1 100644
> --- a/arch/x86/xen/smp.c
> +++ b/arch/x86/xen/smp.c
> @@ -68,9 +68,11 @@ static void __cpuinit cpu_bringup(void)
>         touch_softlockup_watchdog();
>         preempt_disable();
> 
> -       xen_enable_sysenter();
> -       xen_enable_syscall();
> -
> +       /* PVH runs in ring 0 and allows us to do native syscalls. Yay! */
> +       if (!xen_feature(XENFEAT_supervisor_mode_kernel)) {
> +               xen_enable_sysenter();
> +               xen_enable_syscall();
> +       }
>         cpu = smp_processor_id();
>         smp_store_cpu_info(cpu);
>         cpu_data(cpu).x86_max_cores = 1;
> @@ -230,10 +232,11 @@ static void __init xen_smp_prepare_boot_cpu(void)
>         BUG_ON(smp_processor_id() != 0);
>         native_smp_prepare_boot_cpu();
> 
> -       /* We've switched to the "real" per-cpu gdt, so make sure the
> -          old memory can be recycled */
> -       make_lowmem_page_readwrite(xen_initial_gdt);
> -
> +       if (!xen_feature(XENFEAT_writable_page_tables)) {
> +               /* We've switched to the "real" per-cpu gdt, so make sure the
> +                * old memory can be recycled */
> +               make_lowmem_page_readwrite(xen_initial_gdt);
> +       }
>         xen_filter_cpu_maps();
>         xen_setup_vcpu_info_placement();
>  }
> @@ -311,7 +314,24 @@ cpu_initialize_context(unsigned int cpu, struct task_struct *idle)
> 
>         memset(&ctxt->fpu_ctxt, 0, sizeof(ctxt->fpu_ctxt));
> 
> -       {
> +       /* check for autoxlated to get it right for 32bit kernel */
> +       if (xen_feature(XENFEAT_auto_translated_physmap) &&
> +           xen_feature(XENFEAT_supervisor_mode_kernel)) {
> +#ifdef CONFIG_X86_64
> +               ctxt->user_regs.ds = __KERNEL_DS;
> +               ctxt->user_regs.es = 0;
> +               ctxt->user_regs.gs = 0;
> +
> +               /* GUEST_GDTR_BASE and */
> +               ctxt->u.pvh.gdtaddr = (unsigned long)gdt;
> +               /* GUEST_GDTR_LIMIT in the VMCS. */
> +               ctxt->u.pvh.gdtsz = (unsigned long)(GDT_SIZE - 1);
> +
> +               /* Note: PVH is not supported on x86_32. */
> +               ctxt->gs_base_user = (unsigned long)
> +                                       per_cpu(irq_stack_union.gs_base, cpu);
> +#endif
> +       } else {
>                 ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
>                 ctxt->user_regs.ds = __USER_DS;
>                 ctxt->user_regs.es = __USER_DS;
> diff --git a/drivers/xen/cpu_hotplug.c b/drivers/xen/cpu_hotplug.c
> index 4dcfced..de6bcf9 100644
> --- a/drivers/xen/cpu_hotplug.c
> +++ b/drivers/xen/cpu_hotplug.c
> @@ -2,6 +2,7 @@
> 
>  #include 
>  #include 
> +#include 
> 
>  #include 
>  #include 
> @@ -100,7 +101,8 @@ static int __init setup_vcpu_hotplug_event(void)
>         static struct notifier_block xsn_cpu = {
>                 .notifier_call = setup_cpu_watcher };
> 
> -       if (!xen_pv_domain())
> +       /* PVH TBD/FIXME: future work */
> +       if (!xen_pv_domain() || xen_feature(XENFEAT_auto_translated_physmap))
>                 return -ENODEV;
> 
>         register_xenstore_notifier(&xsn_cpu);
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index 59e10a1..7131fdd 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
> @@ -1774,7 +1774,7 @@ int xen_set_callback_via(uint64_t via)
>  }
>  EXPORT_SYMBOL_GPL(xen_set_callback_via);
> 
> -#ifdef CONFIG_XEN_PVHVM
> +#ifdef CONFIG_X86
>  /* Vector callbacks are better than PCI interrupts to receive event
>   * channel notifications because we can receive vector callbacks on any
>   * vcpu and we don't need PCI support or APIC interactions. */
> @@ -1835,6 +1835,13 @@ void __init xen_init_IRQ(void)
>                 if (xen_initial_domain())
>                         pci_xen_initial_domain();
> 
> +               if (xen_feature(XENFEAT_hvm_callback_vector)) {
> +                       xen_callback_vector();
> +                       return;
> +               }
> +
> +               /* PVH: TBD/FIXME: debug and fix eio map to work with pvh */
> +
>                 pirq_eoi_map = (void *)__get_free_page(GFP_KERNEL|__GFP_ZERO);
>                 eoi_gmfn.gmfn = virt_to_mfn(pirq_eoi_map);
>                 rc = HYPERVISOR_physdev_op(PHYSDEVOP_pirq_eoi_gmfn_v2, &eoi_gmfn);
> diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
> index bcf3ba4..356461e 100644
> --- a/drivers/xen/xenbus/xenbus_client.c
> +++ b/drivers/xen/xenbus/xenbus_client.c
> @@ -44,6 +44,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #include "xenbus_probe.h"
> 
> @@ -741,7 +742,7 @@ static const struct xenbus_ring_ops ring_ops_hvm = {
> 
>  void __init xenbus_ring_ops_init(void)
>  {
> -       if (xen_pv_domain())
> +       if (xen_pv_domain() && !xen_feature(XENFEAT_auto_translated_physmap))
>                 ring_ops = &ring_ops_pv;
>         else
>                 ring_ops = &ring_ops_hvm;
> --
> 1.7.7.6
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 12:27:23 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 12:27:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQdZG-0007J9-1q; Tue, 23 Oct 2012 12:26:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQdZD-0007J4-I6
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 12:26:43 +0000
Received: from [85.158.137.99:22984] by server-5.bemta-3.messagelabs.com id
	BE/BA-12440-20D86805; Tue, 23 Oct 2012 12:26:42 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1350995201!17966575!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUyMjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26407 invoked from network); 23 Oct 2012 12:26:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 12:26:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,634,1344211200"; d="scan'208";a="15333432"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Oct 2012 12:26:17 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 23 Oct 2012 13:26:17 +0100
Date: Tue, 23 Oct 2012 13:25:48 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Konrad Rzeszutek Wilk 
In-Reply-To: <20121022201451.GJ25200@phenom.dumpdata.com>
Message-ID: 
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
	<1350695882-12820-3-git-send-email-konrad.wilk@oracle.com>
	
	<20121022113154.0e28ff1d@mantra.us.oracle.com>
	<20121022201451.GJ25200@phenom.dumpdata.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Ian Campbell ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 2/6] xen/pvh: Extend vcpu_guest_context, p2m,
 event, and xenbus to support PVH.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 22 Oct 2012, Konrad Rzeszutek Wilk wrote:
> On Mon, Oct 22, 2012 at 11:31:54AM -0700, Mukesh Rathor wrote:
> > On Mon, 22 Oct 2012 14:44:40 +0100
> > Stefano Stabellini  wrote:
> >
> > > On Sat, 20 Oct 2012, Konrad Rzeszutek Wilk wrote:
> > > > From: Mukesh Rathor 
> > > >
> > > > make gdt_frames[]/gdt_ents into a union with {gdtaddr, gdtsz}, as
> > > > PVH only needs to send down gdtaddr and gdtsz.
> > > >
> > > > For interrupts, PVH uses native_irq_ops.
> > > > vcpu hotplug is currently not available for PVH.
> > > >
> > > > For events we follow what PVHVM does - to use callback vector.
> > > > Lastly, also use HVM path to setup XenBus.
> > > >
> > > > Signed-off-by: Mukesh Rathor 
> > > > Signed-off-by: Konrad Rzeszutek Wilk 
> > > > ---
> > > >           return true;
> > > >   }
> > > > - xen_copy_trap_info(ctxt->trap_ctxt);
> > > > + /* check for autoxlated to get it right for 32bit kernel */
> > >
> > > I am not sure what this comment means, considering that in another
> > > comment below you say that we don't support 32bit PVH kernels.
> >
> > Function is common to both 32bit and 64bit kernels. We need to check
> > for auto xlated also in the if statement in addition to supervisor
> > mode kernel, so 32 bit doesn't go down the wrong path.
> 
> Can one just make it #ifdef CONFIG_X86_64 for the whole thing?
> You are either way during bootup doing a 'BUG' when booting as 32-bit?
> 
> 
> >
> > PVH is not supported for 32bit kernels, and gs_base_user doesn't exist
> > in the structure for 32bit so it needs to be if'def'd 64bit which is
> > ok because PVH is not supprted on 32bit kernel.
> >
> > > > +                                 (unsigned
> > > > long)xen_hypervisor_callback;
> > > > +         ctxt->failsafe_callback_eip =
> > > > +                                 (unsigned
> > > > long)xen_failsafe_callback;
> > > > + }
> > > > + ctxt->user_regs.cs = __KERNEL_CS;
> > > > + ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct
> > > > pt_regs);
> > > >   per_cpu(xen_cr3, cpu) = __pa(swapper_pg_dir);
> > > >   ctxt->ctrlreg[3] =
> > > > xen_pfn_to_cr3(virt_to_mfn(swapper_pg_dir));
> > >
> > > The tradional path looks the same as before, however it is hard to
> > > tell whether the PVH path is correct without the Xen side. For
> > > example, what is gdtsz?
> >
> > gdtsz is GUEST_GDTR_LIMIT and gdtaddr is GUEST_GDTR_BASE in the vmcs.
> 
> looking at this I figured it could be a bit neater. So I split it in
> two patches which should make it easier to read the PVH one.

It is much more readable now, thanks!

You can have my ack on both of them.



> >From f9455e293169d73e5698df62801bcd5fd64a5259 Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk 
> Date: Mon, 22 Oct 2012 11:35:16 -0400
> Subject: [PATCH 1/2] xen/smp: Move the common CPU init code a bit to prep for
>  PVH patch.
> 
> The PV and PVH code CPU init code share some functionality. The
> PVH code ("xen/pvh: Extend vcpu_guest_context, p2m, event, and XenBus")
> sets some of these up, but not all. To make it easier to read, this
> patch removes the PV specific out of the generic way.
> 
> No functional change, just code move.
> 
> Signed-off-by: Konrad Rzeszutek Wilk 
> ---
>  arch/x86/xen/smp.c |   42 +++++++++++++++++++++++-------------------
>  1 files changed, 23 insertions(+), 19 deletions(-)
> 
> diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
> index 353c50f..ba49a3a 100644
> --- a/arch/x86/xen/smp.c
> +++ b/arch/x86/xen/smp.c
> @@ -300,8 +300,6 @@ cpu_initialize_context(unsigned int cpu, struct task_struct *idle)
>         gdt = get_cpu_gdt_table(cpu);
> 
>         ctxt->flags = VGCF_IN_KERNEL;
> -       ctxt->user_regs.ds = __USER_DS;
> -       ctxt->user_regs.es = __USER_DS;
>         ctxt->user_regs.ss = __KERNEL_DS;
>  #ifdef CONFIG_X86_32
>         ctxt->user_regs.fs = __KERNEL_PERCPU;
> @@ -310,35 +308,41 @@ cpu_initialize_context(unsigned int cpu, struct task_struct *idle)
>         ctxt->gs_base_kernel = per_cpu_offset(cpu);
>  #endif
>         ctxt->user_regs.eip = (unsigned long)cpu_bringup_and_idle;
> -       ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
> 
>         memset(&ctxt->fpu_ctxt, 0, sizeof(ctxt->fpu_ctxt));
> 
> -       xen_copy_trap_info(ctxt->trap_ctxt);
> +       {
> +               ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
> +               ctxt->user_regs.ds = __USER_DS;
> +               ctxt->user_regs.es = __USER_DS;
> 
> -       ctxt->ldt_ents = 0;
> +               xen_copy_trap_info(ctxt->trap_ctxt);
> 
> -       BUG_ON((unsigned long)gdt & ~PAGE_MASK);
> +               ctxt->ldt_ents = 0;
> 
> -       gdt_mfn = arbitrary_virt_to_mfn(gdt);
> -       make_lowmem_page_readonly(gdt);
> -       make_lowmem_page_readonly(mfn_to_virt(gdt_mfn));
> +               BUG_ON((unsigned long)gdt & ~PAGE_MASK);
> 
> -       ctxt->gdt_frames[0] = gdt_mfn;
> -       ctxt->gdt_ents      = GDT_ENTRIES;
> +               gdt_mfn = arbitrary_virt_to_mfn(gdt);
> +               make_lowmem_page_readonly(gdt);
> +               make_lowmem_page_readonly(mfn_to_virt(gdt_mfn));
> 
> -       ctxt->user_regs.cs = __KERNEL_CS;
> -       ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct pt_regs);
> +               ctxt->u.pv.gdt_frames[0] = gdt_mfn;
> +               ctxt->u.pv.gdt_ents      = GDT_ENTRIES;
> 
> -       ctxt->kernel_ss = __KERNEL_DS;
> -       ctxt->kernel_sp = idle->thread.sp0;
> +               ctxt->kernel_ss = __KERNEL_DS;
> +               ctxt->kernel_sp = idle->thread.sp0;
> 
>  #ifdef CONFIG_X86_32
> -       ctxt->event_callback_cs     = __KERNEL_CS;
> -       ctxt->failsafe_callback_cs  = __KERNEL_CS;
> +               ctxt->event_callback_cs     = __KERNEL_CS;
> +               ctxt->failsafe_callback_cs  = __KERNEL_CS;
>  #endif
> -       ctxt->event_callback_eip    = (unsigned long)xen_hypervisor_callback;
> -       ctxt->failsafe_callback_eip = (unsigned long)xen_failsafe_callback;
> +               ctxt->event_callback_eip    =
> +                                       (unsigned long)xen_hypervisor_callback;
> +               ctxt->failsafe_callback_eip =
> +                                       (unsigned long)xen_failsafe_callback;
> +       }
> +       ctxt->user_regs.cs = __KERNEL_CS;
> +       ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct pt_regs);
> 
>         per_cpu(xen_cr3, cpu) = __pa(swapper_pg_dir);
>         ctxt->ctrlreg[3] = xen_pfn_to_cr3(virt_to_mfn(swapper_pg_dir));
> --
> 1.7.7.6
> 
> 
> 
> 
> >From 2c4dd7f567b229451f3dc1ae00d784da8b4a5072 Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk 
> Date: Mon, 22 Oct 2012 11:37:57 -0400
> Subject: [PATCH 2/2] xen/pvh: Extend vcpu_guest_context, p2m, event, and
>  XenBus.
> 
> Make gdt_frames[]/gdt_ents into a union with {gdtaddr, gdtsz},
> as PVH only needs to send down gdtaddr and gdtsz in the
> vcpu_guest_context structure..
> 
> For interrupts, PVH uses native_irq_ops so we can skip most of the
> PV ones. In the future we can support the pirq_eoi_map..
> Also VCPU hotplug is currently not available for PVH.
> 
> For events (and IRQs) we follow what PVHVM does - so use callback
> vector.  Lastly, for XenBus we use the same logic that is used in
> the PVHVM case.
> 
> Signed-off-by: Mukesh Rathor 
> [v2: Rebased it]
> [v3: Move 64-bit ifdef and based on Stefan add extra comments.]
> Signed-off-by: Konrad Rzeszutek Wilk 
> ---
>  arch/x86/include/asm/xen/interface.h |   11 +++++++++-
>  arch/x86/xen/irq.c                   |    5 +++-
>  arch/x86/xen/p2m.c                   |    2 +-
>  arch/x86/xen/smp.c                   |   36 ++++++++++++++++++++++++++-------
>  drivers/xen/cpu_hotplug.c            |    4 ++-
>  drivers/xen/events.c                 |    9 +++++++-
>  drivers/xen/xenbus/xenbus_client.c   |    3 +-
>  7 files changed, 56 insertions(+), 14 deletions(-)
> 
> diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
> index 6d2f75a..4c08f23 100644
> --- a/arch/x86/include/asm/xen/interface.h
> +++ b/arch/x86/include/asm/xen/interface.h
> @@ -144,7 +144,16 @@ struct vcpu_guest_context {
>      struct cpu_user_regs user_regs;         /* User-level CPU registers     */
>      struct trap_info trap_ctxt[256];        /* Virtual IDT                  */
>      unsigned long ldt_base, ldt_ents;       /* LDT (linear address, # ents) */
> -    unsigned long gdt_frames[16], gdt_ents; /* GDT (machine frames, # ents) */
> +    union {
> +       struct {
> +               /* PV: GDT (machine frames, # ents).*/
> +               unsigned long gdt_frames[16], gdt_ents;
> +       } pv;
> +       struct {
> +               /* PVH: GDTR addr and size */
> +               unsigned long gdtaddr, gdtsz;
> +       } pvh;
> +    } u;
>      unsigned long kernel_ss, kernel_sp;     /* Virtual TSS (only SS1/SP1)   */
>      /* NB. User pagetable on x86/64 is placed in ctrlreg[1]. */
>      unsigned long ctrlreg[8];               /* CR0-CR7 (control registers)  */
> diff --git a/arch/x86/xen/irq.c b/arch/x86/xen/irq.c
> index 01a4dc0..fcbe56a 100644
> --- a/arch/x86/xen/irq.c
> +++ b/arch/x86/xen/irq.c
> @@ -5,6 +5,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
> 
>  #include 
> @@ -129,6 +130,8 @@ static const struct pv_irq_ops xen_irq_ops __initconst = {
> 
>  void __init xen_init_irq_ops(void)
>  {
> -       pv_irq_ops = xen_irq_ops;
> +       /* For PVH we use default pv_irq_ops settings */
> +       if (!xen_feature(XENFEAT_hvm_callback_vector))
> +               pv_irq_ops = xen_irq_ops;
>         x86_init.irqs.intr_init = xen_init_IRQ;
>  }
> diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
> index 95fb2aa..ea553c8 100644
> --- a/arch/x86/xen/p2m.c
> +++ b/arch/x86/xen/p2m.c
> @@ -798,7 +798,7 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
>  {
>         unsigned topidx, mididx, idx;
> 
> -       if (unlikely(xen_feature(XENFEAT_auto_translated_physmap))) {
> +       if (xen_feature(XENFEAT_auto_translated_physmap)) {
>                 BUG_ON(pfn != mfn && mfn != INVALID_P2M_ENTRY);
>                 return true;
>         }
> diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
> index ba49a3a..6f831a1 100644
> --- a/arch/x86/xen/smp.c
> +++ b/arch/x86/xen/smp.c
> @@ -68,9 +68,11 @@ static void __cpuinit cpu_bringup(void)
>         touch_softlockup_watchdog();
>         preempt_disable();
> 
> -       xen_enable_sysenter();
> -       xen_enable_syscall();
> -
> +       /* PVH runs in ring 0 and allows us to do native syscalls. Yay! */
> +       if (!xen_feature(XENFEAT_supervisor_mode_kernel)) {
> +               xen_enable_sysenter();
> +               xen_enable_syscall();
> +       }
>         cpu = smp_processor_id();
>         smp_store_cpu_info(cpu);
>         cpu_data(cpu).x86_max_cores = 1;
> @@ -230,10 +232,11 @@ static void __init xen_smp_prepare_boot_cpu(void)
>         BUG_ON(smp_processor_id() != 0);
>         native_smp_prepare_boot_cpu();
> 
> -       /* We've switched to the "real" per-cpu gdt, so make sure the
> -          old memory can be recycled */
> -       make_lowmem_page_readwrite(xen_initial_gdt);
> -
> +       if (!xen_feature(XENFEAT_writable_page_tables)) {
> +               /* We've switched to the "real" per-cpu gdt, so make sure the
> +                * old memory can be recycled */
> +               make_lowmem_page_readwrite(xen_initial_gdt);
> +       }
>         xen_filter_cpu_maps();
>         xen_setup_vcpu_info_placement();
>  }
> @@ -311,7 +314,24 @@ cpu_initialize_context(unsigned int cpu, struct task_struct *idle)
> 
>         memset(&ctxt->fpu_ctxt, 0, sizeof(ctxt->fpu_ctxt));
> 
> -       {
> +       /* check for autoxlated to get it right for 32bit kernel */
> +       if (xen_feature(XENFEAT_auto_translated_physmap) &&
> +           xen_feature(XENFEAT_supervisor_mode_kernel)) {
> +#ifdef CONFIG_X86_64
> +               ctxt->user_regs.ds = __KERNEL_DS;
> +               ctxt->user_regs.es = 0;
> +               ctxt->user_regs.gs = 0;
> +
> +               /* GUEST_GDTR_BASE and */
> +               ctxt->u.pvh.gdtaddr = (unsigned long)gdt;
> +               /* GUEST_GDTR_LIMIT in the VMCS. */
> +               ctxt->u.pvh.gdtsz = (unsigned long)(GDT_SIZE - 1);
> +
> +               /* Note: PVH is not supported on x86_32. */
> +               ctxt->gs_base_user = (unsigned long)
> +                                       per_cpu(irq_stack_union.gs_base, cpu);
> +#endif
> +       } else {
>                 ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
>                 ctxt->user_regs.ds = __USER_DS;
>                 ctxt->user_regs.es = __USER_DS;
> diff --git a/drivers/xen/cpu_hotplug.c b/drivers/xen/cpu_hotplug.c
> index 4dcfced..de6bcf9 100644
> --- a/drivers/xen/cpu_hotplug.c
> +++ b/drivers/xen/cpu_hotplug.c
> @@ -2,6 +2,7 @@
> 
>  #include 
>  #include 
> +#include 
> 
>  #include 
>  #include 
> @@ -100,7 +101,8 @@ static int __init setup_vcpu_hotplug_event(void)
>         static struct notifier_block xsn_cpu = {
>                 .notifier_call = setup_cpu_watcher };
> 
> -       if (!xen_pv_domain())
> +       /* PVH TBD/FIXME: future work */
> +       if (!xen_pv_domain() || xen_feature(XENFEAT_auto_translated_physmap))
>                 return -ENODEV;
> 
>         register_xenstore_notifier(&xsn_cpu);
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index 59e10a1..7131fdd 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
> @@ -1774,7 +1774,7 @@ int xen_set_callback_via(uint64_t via)
>  }
>  EXPORT_SYMBOL_GPL(xen_set_callback_via);
> 
> -#ifdef CONFIG_XEN_PVHVM
> +#ifdef CONFIG_X86
>  /* Vector callbacks are better than PCI interrupts to receive event
>   * channel notifications because we can receive vector callbacks on any
>   * vcpu and we don't need PCI support or APIC interactions. */
> @@ -1835,6 +1835,13 @@ void __init xen_init_IRQ(void)
>                 if (xen_initial_domain())
>                         pci_xen_initial_domain();
> 
> +               if (xen_feature(XENFEAT_hvm_callback_vector)) {
> +                       xen_callback_vector();
> +                       return;
> +               }
> +
> +               /* PVH: TBD/FIXME: debug and fix eio map to work with pvh */
> +
>                 pirq_eoi_map = (void *)__get_free_page(GFP_KERNEL|__GFP_ZERO);
>                 eoi_gmfn.gmfn = virt_to_mfn(pirq_eoi_map);
>                 rc = HYPERVISOR_physdev_op(PHYSDEVOP_pirq_eoi_gmfn_v2, &eoi_gmfn);
> diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
> index bcf3ba4..356461e 100644
> --- a/drivers/xen/xenbus/xenbus_client.c
> +++ b/drivers/xen/xenbus/xenbus_client.c
> @@ -44,6 +44,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #include "xenbus_probe.h"
> 
> @@ -741,7 +742,7 @@ static const struct xenbus_ring_ops ring_ops_hvm = {
> 
>  void __init xenbus_ring_ops_init(void)
>  {
> -       if (xen_pv_domain())
> +       if (xen_pv_domain() && !xen_feature(XENFEAT_auto_translated_physmap))
>                 ring_ops = &ring_ops_pv;
>         else
>                 ring_ops = &ring_ops_hvm;
> --
> 1.7.7.6
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 13:08:06 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 13:08:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQeCo-0007vW-0o; Tue, 23 Oct 2012 13:07:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQeCm-0007vR-Tv
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 13:07:37 +0000
Received: from [85.158.143.35:38169] by server-1.bemta-4.messagelabs.com id
	A7/71-19134-89696805; Tue, 23 Oct 2012 13:07:36 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1350997655!15187509!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUyMjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23026 invoked from network); 23 Oct 2012 13:07:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 13:07:35 -0000
X-IronPort-AV: E=Sophos;i="4.80,634,1344211200"; d="scan'208";a="15334663"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Oct 2012 13:07:35 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 23 Oct 2012 14:07:35 +0100
Date: Tue, 23 Oct 2012 14:07:06 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Konrad Rzeszutek Wilk 
In-Reply-To: <20121022155717.GB25200@phenom.dumpdata.com>
Message-ID: 
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
	<1350695882-12820-5-git-send-email-konrad.wilk@oracle.com>
	
	<20121022155717.GB25200@phenom.dumpdata.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Ian Campbell ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 4/6] xen/pvh: bootup and setup related
	changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 22 Oct 2012, Konrad Rzeszutek Wilk wrote:
> On Mon, Oct 22, 2012 at 02:34:44PM +0100, Stefano Stabellini wrote:
> > On Sat, 20 Oct 2012, Konrad Rzeszutek Wilk wrote:
> > > From: Mukesh Rathor 
> > > 
> > > In enlighten.c for PVH we can trap cpuid via vmexit, so don't
> > > need to use emulated prefix call. We also check for vector callback
> > > early on, as it is a required feature. PVH also runs at default kernel
> > > IOPL.
> > > 
> > > In setup.c, in xen_add_extra_mem() we can skip updating P2M as it's managed
> > > by Xen. PVH maps the entire IO space, but only RAM pages need to be repopulated.
> > > 
> > > Finally, pure PV settings are moved to a separate function that is only called
> > > for pure PV, ie, pv with pvmmu.
> > > 
> > > Signed-off-by: Mukesh Rathor 
> > > Signed-off-by: Konrad Rzeszutek Wilk 
> > >
> > > diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> > > index 8971a26..8cce47b 100644
> > > --- a/arch/x86/xen/setup.c
> > > +++ b/arch/x86/xen/setup.c
> > > @@ -27,6 +27,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include "mmu.h"
> > >  #include "xen-ops.h"
> > >  #include "vdso.h"
> > >  
> > > @@ -78,6 +79,9 @@ static void __init xen_add_extra_mem(u64 start, u64 size)
> > >  
> > >  	memblock_reserve(start, size);
> > >  
> > > +	if (xen_feature(XENFEAT_auto_translated_physmap))
> > > +		return;
> > > +
> > >  	xen_max_p2m_pfn = PFN_DOWN(start + size);
> > >  	for (pfn = PFN_DOWN(start); pfn < xen_max_p2m_pfn; pfn++) {
> > >  		unsigned long mfn = pfn_to_mfn(pfn);
> > > @@ -100,6 +104,7 @@ static unsigned long __init xen_do_chunk(unsigned long start,
> > >  		.domid        = DOMID_SELF
> > >  	};
> > >  	unsigned long len = 0;
> > > +	int xlated_phys = xen_feature(XENFEAT_auto_translated_physmap);
> > >  	unsigned long pfn;
> > >  	int ret;
> > >  
> > > @@ -113,7 +118,7 @@ static unsigned long __init xen_do_chunk(unsigned long start,
> > >  				continue;
> > >  			frame = mfn;
> > >  		} else {
> > > -			if (mfn != INVALID_P2M_ENTRY)
> > > +			if (!xlated_phys && mfn != INVALID_P2M_ENTRY)
> > >  				continue;
> > >  			frame = pfn;
> > >  		}
> > 
> > Shouldn't we add a "!xlated_phys &&" to the other case as well?
> 
> No. That is handled in xen_pvh_identity_map_chunk which
> just does a xen_set_clr_mmio_pvh_pte call for the "released"
> pages. But that is a bit of ... well, extra logic. I think
> if we did this it would work and look much nicer:

Yes, I think that this version looks better

> 
> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> index 8cce47b..b451a77 100644
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -114,9 +114,15 @@ static unsigned long __init xen_do_chunk(unsigned long start,
>  
>  		if (release) {
>  			/* Make sure pfn exists to start with */
> -			if (mfn == INVALID_P2M_ENTRY || mfn_to_pfn(mfn) != pfn)
> +			if (mfn == INVALID_P2M_ENTRY || (!xlated_phys && (mfn_to_pfn(mfn) != pfn)))
>  				continue;
>  			frame = mfn;
> +			/* The hypercall PHYSDEVOP_map_iomem to release memory has already
> +			 * happend, so we just do a nop here. */
> +			if (xlated_phys) {
> +				len++;
> +				continue;
> +			}
>  		} else {
>  			if (!xlated_phys && mfn != INVALID_P2M_ENTRY)
>  				continue;
> @@ -219,15 +225,24 @@ static void __init xen_set_identity_and_release_chunk(
>  {
>  	unsigned long pfn;
>  
> +	/* For PVH, the pfns [0..MAX] are mapped to mfn's in the EPT/NPT. The mfns
> +	 * are released as part of this 1:1 mapping hypercall back to the dom heap.
> +	 * Also, we map the entire IO space, ie, beyond max_pfn_mapped.
> +	 */
> +	int xlated_phys = xen_feature(XENFEAT_auto_translated_physmap);
> +
>  	/*
>  	 * If the PFNs are currently mapped, the VA mapping also needs
>  	 * to be updated to be 1:1.
>  	 */
> -	for (pfn = start_pfn; pfn <= max_pfn_mapped && pfn < end_pfn; pfn++)
> -		(void)HYPERVISOR_update_va_mapping(
> -			(unsigned long)__va(pfn << PAGE_SHIFT),
> -			mfn_pte(pfn, PAGE_KERNEL_IO), 0);
> -
> +	for (pfn = start_pfn; pfn <= max_pfn_mapped && pfn < end_pfn; pfn++) {
> +		if (xlated_phys)
> +			xen_set_clr_mmio_pvh_pte(pfn, pfn, 1 /* one pfn */, 1 /* add mapping */);
> +		else
> +			(void)HYPERVISOR_update_va_mapping(
> +				(unsigned long)__va(pfn << PAGE_SHIFT),
> +				mfn_pte(pfn, PAGE_KERNEL_IO), 0);
> +	}
>  	if (start_pfn < nr_pages)
>  		*released += xen_release_chunk(
>  			start_pfn, min(end_pfn, nr_pages));
> @@ -235,27 +250,6 @@ static void __init xen_set_identity_and_release_chunk(
>  	*identity += set_phys_range_identity(start_pfn, end_pfn);
>  }
>  
> -/* For PVH, the pfns [0..MAX] are mapped to mfn's in the EPT/NPT. The mfns
> - * are released as part of this 1:1 mapping hypercall back to the dom heap.
> - * Also, we map the entire IO space, ie, beyond max_pfn_mapped.
> - */
> -static void __init xen_pvh_identity_map_chunk(unsigned long start_pfn,
> -		unsigned long end_pfn, unsigned long *released,
> -		unsigned long *identity, unsigned long max_pfn)
> -{
> -	unsigned long pfn;
> -	int numpfns = 1, add_mapping = 1;
> -
> -	for (pfn = start_pfn; pfn < end_pfn; pfn++)
> -		xen_set_clr_mmio_pvh_pte(pfn, pfn, numpfns, add_mapping);
> -
> -	if (start_pfn <= max_pfn) {
> -		unsigned long end = min(max_pfn_mapped, end_pfn);
> -		*released += end - start_pfn;
> -	}
> -	*identity += end_pfn - start_pfn;
> -}
> -
>  static unsigned long __init xen_set_identity_and_release(
>  	const struct e820entry *list, size_t map_size, unsigned long nr_pages)
>  {
> @@ -286,17 +280,10 @@ static unsigned long __init xen_set_identity_and_release(
>  			if (entry->type == E820_RAM)
>  				end_pfn = PFN_UP(entry->addr);
>  
> -			if (start_pfn < end_pfn) {
> -				if (xlated_phys) {
> -					xen_pvh_identity_map_chunk(start_pfn,
> -						end_pfn, &released, &identity,
> -						nr_pages);
> -				} else {
> -					xen_set_identity_and_release_chunk(
> +			if (start_pfn < end_pfn)
> +				xen_set_identity_and_release_chunk(
>  						start_pfn, end_pfn, nr_pages,
>  						&released, &identity);
> -				}
> -			}
>  			start = end;
>  		}
>  	}
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 13:08:06 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 13:08:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQeCo-0007vW-0o; Tue, 23 Oct 2012 13:07:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQeCm-0007vR-Tv
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 13:07:37 +0000
Received: from [85.158.143.35:38169] by server-1.bemta-4.messagelabs.com id
	A7/71-19134-89696805; Tue, 23 Oct 2012 13:07:36 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1350997655!15187509!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUyMjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23026 invoked from network); 23 Oct 2012 13:07:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 13:07:35 -0000
X-IronPort-AV: E=Sophos;i="4.80,634,1344211200"; d="scan'208";a="15334663"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Oct 2012 13:07:35 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 23 Oct 2012 14:07:35 +0100
Date: Tue, 23 Oct 2012 14:07:06 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Konrad Rzeszutek Wilk 
In-Reply-To: <20121022155717.GB25200@phenom.dumpdata.com>
Message-ID: 
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
	<1350695882-12820-5-git-send-email-konrad.wilk@oracle.com>
	
	<20121022155717.GB25200@phenom.dumpdata.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Ian Campbell ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 4/6] xen/pvh: bootup and setup related
	changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 22 Oct 2012, Konrad Rzeszutek Wilk wrote:
> On Mon, Oct 22, 2012 at 02:34:44PM +0100, Stefano Stabellini wrote:
> > On Sat, 20 Oct 2012, Konrad Rzeszutek Wilk wrote:
> > > From: Mukesh Rathor 
> > > 
> > > In enlighten.c for PVH we can trap cpuid via vmexit, so don't
> > > need to use emulated prefix call. We also check for vector callback
> > > early on, as it is a required feature. PVH also runs at default kernel
> > > IOPL.
> > > 
> > > In setup.c, in xen_add_extra_mem() we can skip updating P2M as it's managed
> > > by Xen. PVH maps the entire IO space, but only RAM pages need to be repopulated.
> > > 
> > > Finally, pure PV settings are moved to a separate function that is only called
> > > for pure PV, ie, pv with pvmmu.
> > > 
> > > Signed-off-by: Mukesh Rathor 
> > > Signed-off-by: Konrad Rzeszutek Wilk 
> > >
> > > diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> > > index 8971a26..8cce47b 100644
> > > --- a/arch/x86/xen/setup.c
> > > +++ b/arch/x86/xen/setup.c
> > > @@ -27,6 +27,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include "mmu.h"
> > >  #include "xen-ops.h"
> > >  #include "vdso.h"
> > >  
> > > @@ -78,6 +79,9 @@ static void __init xen_add_extra_mem(u64 start, u64 size)
> > >  
> > >  	memblock_reserve(start, size);
> > >  
> > > +	if (xen_feature(XENFEAT_auto_translated_physmap))
> > > +		return;
> > > +
> > >  	xen_max_p2m_pfn = PFN_DOWN(start + size);
> > >  	for (pfn = PFN_DOWN(start); pfn < xen_max_p2m_pfn; pfn++) {
> > >  		unsigned long mfn = pfn_to_mfn(pfn);
> > > @@ -100,6 +104,7 @@ static unsigned long __init xen_do_chunk(unsigned long start,
> > >  		.domid        = DOMID_SELF
> > >  	};
> > >  	unsigned long len = 0;
> > > +	int xlated_phys = xen_feature(XENFEAT_auto_translated_physmap);
> > >  	unsigned long pfn;
> > >  	int ret;
> > >  
> > > @@ -113,7 +118,7 @@ static unsigned long __init xen_do_chunk(unsigned long start,
> > >  				continue;
> > >  			frame = mfn;
> > >  		} else {
> > > -			if (mfn != INVALID_P2M_ENTRY)
> > > +			if (!xlated_phys && mfn != INVALID_P2M_ENTRY)
> > >  				continue;
> > >  			frame = pfn;
> > >  		}
> > 
> > Shouldn't we add a "!xlated_phys &&" to the other case as well?
> 
> No. That is handled in xen_pvh_identity_map_chunk which
> just does a xen_set_clr_mmio_pvh_pte call for the "released"
> pages. But that is a bit of ... well, extra logic. I think
> if we did this it would work and look much nicer:

Yes, I think that this version looks better

> 
> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> index 8cce47b..b451a77 100644
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -114,9 +114,15 @@ static unsigned long __init xen_do_chunk(unsigned long start,
>  
>  		if (release) {
>  			/* Make sure pfn exists to start with */
> -			if (mfn == INVALID_P2M_ENTRY || mfn_to_pfn(mfn) != pfn)
> +			if (mfn == INVALID_P2M_ENTRY || (!xlated_phys && (mfn_to_pfn(mfn) != pfn)))
>  				continue;
>  			frame = mfn;
> +			/* The hypercall PHYSDEVOP_map_iomem to release memory has already
> +			 * happend, so we just do a nop here. */
> +			if (xlated_phys) {
> +				len++;
> +				continue;
> +			}
>  		} else {
>  			if (!xlated_phys && mfn != INVALID_P2M_ENTRY)
>  				continue;
> @@ -219,15 +225,24 @@ static void __init xen_set_identity_and_release_chunk(
>  {
>  	unsigned long pfn;
>  
> +	/* For PVH, the pfns [0..MAX] are mapped to mfn's in the EPT/NPT. The mfns
> +	 * are released as part of this 1:1 mapping hypercall back to the dom heap.
> +	 * Also, we map the entire IO space, ie, beyond max_pfn_mapped.
> +	 */
> +	int xlated_phys = xen_feature(XENFEAT_auto_translated_physmap);
> +
>  	/*
>  	 * If the PFNs are currently mapped, the VA mapping also needs
>  	 * to be updated to be 1:1.
>  	 */
> -	for (pfn = start_pfn; pfn <= max_pfn_mapped && pfn < end_pfn; pfn++)
> -		(void)HYPERVISOR_update_va_mapping(
> -			(unsigned long)__va(pfn << PAGE_SHIFT),
> -			mfn_pte(pfn, PAGE_KERNEL_IO), 0);
> -
> +	for (pfn = start_pfn; pfn <= max_pfn_mapped && pfn < end_pfn; pfn++) {
> +		if (xlated_phys)
> +			xen_set_clr_mmio_pvh_pte(pfn, pfn, 1 /* one pfn */, 1 /* add mapping */);
> +		else
> +			(void)HYPERVISOR_update_va_mapping(
> +				(unsigned long)__va(pfn << PAGE_SHIFT),
> +				mfn_pte(pfn, PAGE_KERNEL_IO), 0);
> +	}
>  	if (start_pfn < nr_pages)
>  		*released += xen_release_chunk(
>  			start_pfn, min(end_pfn, nr_pages));
> @@ -235,27 +250,6 @@ static void __init xen_set_identity_and_release_chunk(
>  	*identity += set_phys_range_identity(start_pfn, end_pfn);
>  }
>  
> -/* For PVH, the pfns [0..MAX] are mapped to mfn's in the EPT/NPT. The mfns
> - * are released as part of this 1:1 mapping hypercall back to the dom heap.
> - * Also, we map the entire IO space, ie, beyond max_pfn_mapped.
> - */
> -static void __init xen_pvh_identity_map_chunk(unsigned long start_pfn,
> -		unsigned long end_pfn, unsigned long *released,
> -		unsigned long *identity, unsigned long max_pfn)
> -{
> -	unsigned long pfn;
> -	int numpfns = 1, add_mapping = 1;
> -
> -	for (pfn = start_pfn; pfn < end_pfn; pfn++)
> -		xen_set_clr_mmio_pvh_pte(pfn, pfn, numpfns, add_mapping);
> -
> -	if (start_pfn <= max_pfn) {
> -		unsigned long end = min(max_pfn_mapped, end_pfn);
> -		*released += end - start_pfn;
> -	}
> -	*identity += end_pfn - start_pfn;
> -}
> -
>  static unsigned long __init xen_set_identity_and_release(
>  	const struct e820entry *list, size_t map_size, unsigned long nr_pages)
>  {
> @@ -286,17 +280,10 @@ static unsigned long __init xen_set_identity_and_release(
>  			if (entry->type == E820_RAM)
>  				end_pfn = PFN_UP(entry->addr);
>  
> -			if (start_pfn < end_pfn) {
> -				if (xlated_phys) {
> -					xen_pvh_identity_map_chunk(start_pfn,
> -						end_pfn, &released, &identity,
> -						nr_pages);
> -				} else {
> -					xen_set_identity_and_release_chunk(
> +			if (start_pfn < end_pfn)
> +				xen_set_identity_and_release_chunk(
>  						start_pfn, end_pfn, nr_pages,
>  						&released, &identity);
> -				}
> -			}
>  			start = end;
>  		}
>  	}
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 13:31:59 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 13:31:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQeZa-0008M9-K9; Tue, 23 Oct 2012 13:31:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQeZY-0008M4-Ut
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 13:31:09 +0000
Received: from [85.158.137.99:16942] by server-16.bemta-3.messagelabs.com id
	8A/9B-00625-C1C96805; Tue, 23 Oct 2012 13:31:08 +0000
X-Env-Sender: adrian.l.shaw@gmail.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1350999067!17351767!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4109 invoked from network); 23 Oct 2012 13:31:07 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 13:31:07 -0000
Received: by mail-wi0-f173.google.com with SMTP id hm4so3117183wib.14
	for ; Tue, 23 Oct 2012 06:31:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:from:date:message-id:subject:to:content-type;
	bh=eSOYMPU02BImYHYQR5I+3JalFqRaRhrMQDZlAof+iHU=;
	b=HAvTD/FOC/RSUtvp/5oy2kjy+zoTvvQX6GMKGwu68/TC4r/us++XjEakxUBa7azkAB
	9mZTrWFATsc9hE7MPasUyaj/C5uUTWVVY43LjdYTpb+sUiaf3GrJGA/o8bF9mIlfBhgY
	LCZA+qKuFDbpe9Fx6W3kDmdTD4wm1VGY5At1BTK27GS1RthXY4AcGnQQhtZChQbEJVRv
	WOvBlz/LwajjILtHV4LH7D8q2EJRqI5xkCvt7tSu3Y+U9gPm0NtE0VxcdhegLGNJeUoS
	LTZ6OE0qQ70fJydHTJI0tn2bhVzjG84CPYmYxkkncFaNcGjCqwlfYP6SyTZ6EC6aFj9A
	qF4w==
Received: by 10.216.204.139 with SMTP id h11mr7594817weo.128.1350999067120;
	Tue, 23 Oct 2012 06:31:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.100.4 with HTTP; Tue, 23 Oct 2012 06:30:46 -0700 (PDT)
From: Adrian Shaw 
Date: Tue, 23 Oct 2012 14:30:46 +0100
Message-ID: 
To: Xen-devel 
Subject: [Xen-devel] Mini-OS transactions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1851107095098302402=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1851107095098302402==
Content-Type: multipart/alternative; boundary=0016e6d589e17cd48804ccb9fba9

--0016e6d589e17cd48804ccb9fba9
Content-Type: text/plain; charset=ISO-8859-1

Dear all,

I am struggling to understand how to initialise an xs_transaction_t for use
with the Mini-OS XenStore API.

Each function such as xs_read, xs_write take this type of variable in.
However neither xs_transaction_start nor xs_transaction_end are defined in
Mini-OS.

Are XenStore transactions not ready for primetime on Xen 4.1.2 Mini-OS?

Would appreciate any clarifications anyone can make :-)

Adrian

--0016e6d589e17cd48804ccb9fba9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Dear all,

I am struggling to understand how to initialis=
e an xs_transaction_t for use with the Mini-OS XenStore API.

=

Each function such as xs_read, xs_write take this type of variab=
le in.



However neither xs_transaction_start nor xs_transaction_end are define=
d in Mini-OS.

Are XenStore transactions not ready =
for primetime on Xen 4.1.2 Mini-OS?

Would apprecia=
te any clarifications anyone can make :-)




Adrian


--0016e6d589e17cd48804ccb9fba9--


--===============1851107095098302402==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1851107095098302402==--


From xen-devel-bounces@lists.xen.org Tue Oct 23 13:31:59 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 13:31:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQeZa-0008M9-K9; Tue, 23 Oct 2012 13:31:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQeZY-0008M4-Ut
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 13:31:09 +0000
Received: from [85.158.137.99:16942] by server-16.bemta-3.messagelabs.com id
	8A/9B-00625-C1C96805; Tue, 23 Oct 2012 13:31:08 +0000
X-Env-Sender: adrian.l.shaw@gmail.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1350999067!17351767!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4109 invoked from network); 23 Oct 2012 13:31:07 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 13:31:07 -0000
Received: by mail-wi0-f173.google.com with SMTP id hm4so3117183wib.14
	for ; Tue, 23 Oct 2012 06:31:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:from:date:message-id:subject:to:content-type;
	bh=eSOYMPU02BImYHYQR5I+3JalFqRaRhrMQDZlAof+iHU=;
	b=HAvTD/FOC/RSUtvp/5oy2kjy+zoTvvQX6GMKGwu68/TC4r/us++XjEakxUBa7azkAB
	9mZTrWFATsc9hE7MPasUyaj/C5uUTWVVY43LjdYTpb+sUiaf3GrJGA/o8bF9mIlfBhgY
	LCZA+qKuFDbpe9Fx6W3kDmdTD4wm1VGY5At1BTK27GS1RthXY4AcGnQQhtZChQbEJVRv
	WOvBlz/LwajjILtHV4LH7D8q2EJRqI5xkCvt7tSu3Y+U9gPm0NtE0VxcdhegLGNJeUoS
	LTZ6OE0qQ70fJydHTJI0tn2bhVzjG84CPYmYxkkncFaNcGjCqwlfYP6SyTZ6EC6aFj9A
	qF4w==
Received: by 10.216.204.139 with SMTP id h11mr7594817weo.128.1350999067120;
	Tue, 23 Oct 2012 06:31:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.100.4 with HTTP; Tue, 23 Oct 2012 06:30:46 -0700 (PDT)
From: Adrian Shaw 
Date: Tue, 23 Oct 2012 14:30:46 +0100
Message-ID: 
To: Xen-devel 
Subject: [Xen-devel] Mini-OS transactions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1851107095098302402=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1851107095098302402==
Content-Type: multipart/alternative; boundary=0016e6d589e17cd48804ccb9fba9

--0016e6d589e17cd48804ccb9fba9
Content-Type: text/plain; charset=ISO-8859-1

Dear all,

I am struggling to understand how to initialise an xs_transaction_t for use
with the Mini-OS XenStore API.

Each function such as xs_read, xs_write take this type of variable in.
However neither xs_transaction_start nor xs_transaction_end are defined in
Mini-OS.

Are XenStore transactions not ready for primetime on Xen 4.1.2 Mini-OS?

Would appreciate any clarifications anyone can make :-)

Adrian

--0016e6d589e17cd48804ccb9fba9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Dear all,

I am struggling to understand how to initialis=
e an xs_transaction_t for use with the Mini-OS XenStore API.

=

Each function such as xs_read, xs_write take this type of variab=
le in.



However neither xs_transaction_start nor xs_transaction_end are define=
d in Mini-OS.

Are XenStore transactions not ready =
for primetime on Xen 4.1.2 Mini-OS?

Would apprecia=
te any clarifications anyone can make :-)




Adrian


--0016e6d589e17cd48804ccb9fba9--


--===============1851107095098302402==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1851107095098302402==--


From xen-devel-bounces@lists.xen.org Tue Oct 23 13:35:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 13:35:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQecq-0008WM-EB; Tue, 23 Oct 2012 13:34:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQecp-0008W7-63
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 13:34:31 +0000
Received: from [85.158.143.35:19351] by server-3.bemta-4.messagelabs.com id
	36/FB-03544-6EC96805; Tue, 23 Oct 2012 13:34:30 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1350999269!5517728!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18894 invoked from network); 23 Oct 2012 13:34:29 -0000
Received: from mail-ea0-f173.google.com (HELO mail-ea0-f173.google.com)
	(209.85.215.173)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 13:34:29 -0000
Received: by mail-ea0-f173.google.com with SMTP id a1so1407512eaa.32
	for ; Tue, 23 Oct 2012 06:34:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:subject:from:to:cc:date:content-type:x-mailer
	:mime-version; bh=+DUNNYCwHc4d+D9o9L7mG05jFt8o061g41ewWsaGnIc=;
	b=JT+cmRZWSbfm43Y+XgLwiGwilkPIQ5ENPjh4U1asKpmjKbsKBhbAoNZc+yeE+pSt6a
	SUOFm4F7/pT7O3ov7VuFgsQAJtDHdkpf0i1+PMd+9fOiGgtN/0lole0GopW/kKnCfYNn
	uzBf/cvFzkaVDittru+lbJPztWLzpEWtMv5vfQEJdGgtqHpLCqELejL+534j0FzWa/Zf
	PGIBumRdHfI3IMnB4SzpGvTZkVpfD3c85DsNa64WpXO4yPwN3o2N0/0TZLuAbWNCiisA
	sdXopIcXjGQOzBj2BK/IGsDJ4ydPoij6Bt1Ez+wmJKmX9AumgeFX1YhXY3bixSYzUvtT
	Yxiw==
Received: by 10.14.178.195 with SMTP id f43mr16997232eem.44.1350999268849;
	Tue, 23 Oct 2012 06:34:28 -0700 (PDT)
Received: from [192.168.0.40] (ip-180-234.sn1.eutelia.it. [62.94.180.234])
	by mx.google.com with ESMTPS id o47sm20904438eem.11.2012.10.23.06.34.26
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 23 Oct 2012 06:34:27 -0700 (PDT)
Message-ID: <1350999260.5064.56.camel@Solace>
From: Dario Faggioli 
To: George Dunlap 
Date: Tue, 23 Oct 2012 15:34:20 +0200
X-Mailer: Evolution 3.4.3-1
Mime-Version: 1.0
Cc: Keir Fraser , Jan Beulich ,
	xen-devel 
Subject: [Xen-devel] About vcpu wakeup and runq tickling in credit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============8291746621744066086=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============8291746621744066086==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-opzFX2sQqICEJj5AJ5Tw"


--=-opzFX2sQqICEJj5AJ5Tw
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi George, Everyone,

While reworking a bit my NUMA aware scheduling patches I figured I'm not
sure I understand what __runq_tickle() (in xen/common/sched_credit.c, of
course) does.

Here's the thing. Upon every vcpu wakeup we put the new vcpu in a runq
and then call __runq_tickle(), passing the waking vcpu via 'new'. Let's
call the vcpu that just woke up v_W, and the vcpu that is currently
running on the cpu where that happens v_C. Let's also call the CPU where
all is happening P.

As far as I've understood, in  __runq_tickle(), we:


static inline void
__runq_tickle(unsigned int cpu, struct csched_vcpu *new)
{
    [...]
    cpumask_t mask;

    cpumask_clear(&mask);

    /* If strictly higher priority than current VCPU, signal the CPU */
    if ( new->pri > cur->pri )
    {
        [...]
        cpumask_set_cpu(cpu, &mask);
    }

--> Make sure we put the CPU we are on (P) in 'mask', in case the woken
--> vcpu (v_W) has higher priority that the currently running one (v_C).

    /*
     * If this CPU has at least two runnable VCPUs, we tickle any idlers to
     * let them know there is runnable work in the system...
     */
    if ( cur->pri > CSCHED_PRI_IDLE )
    {
        if ( cpumask_empty(prv->idlers) )
        [...]
        else
        {
            cpumask_t idle_mask;

            cpumask_and(&idle_mask, prv->idlers, new->vcpu->cpu_affinity);
            if ( !cpumask_empty(&idle_mask) )
            {
                [...]
                if ( opt_tickle_one_idle )
                {
                    [...]
                    cpumask_set_cpu(this_cpu(last_tickle_cpu), &mask);
                }
                else
                    cpumask_or(&mask, &mask, &idle_mask);
            }
            cpumask_and(&mask, &mask, new->vcpu->cpu_affinity);

--> Make sure we include one or more (depending on opt_tickle_one_idle)
--> CPUs that are both idle and part of v_W's CPU-affinity in 'mask'.

        }
    }

    /* Send scheduler interrupts to designated CPUs */
    if ( !cpumask_empty(&mask) )
        cpumask_raise_softirq(&mask, SCHEDULE_SOFTIRQ);

--> Ask all the CPUs in 'mask' to reschedule. That would mean all the
--> idlers from v_W's CPU-affinity and, possibly, "ourself" (P). The
--> effect will be that all/some of the CPUs v_W's has affinity with
--> _and_ (let's assume so) P will go through scheduling as quickly as
--> possible.

}

Is the above right?

If yes, here's my question. Is that right to always tickle v_W's affine
CPUs and only them?

I'm asking because a possible scenario, at least according to me, is
that P schedules very quickly after this and, as prio(v_W)>prio(v_C), it
selects v_W and leaves v_C in its runq. At that point, one of the
tickled CPU (say P') enters schedule, sees that P is not idle, and tries
to steal a vcpu from its runq. Now we know that P' has affinity with
v_W, but v_W is not there, while v_C is, and if P' is not in its
affinity, we've forced P' to reschedule for nothing.
Also, there now might be another (or even a number of) CPU where v_C
could run that stays idle, as it has not being tickled.

So, if that is true, it seems we leave some room for sub-optimal CPU
utilization, as well as some non-work conserving windows.
Of course, it is very hard to tell how frequent this actually happens.

As it comes to possible solution, I think that, for instance, tickling
all the CPUs in both v_W's and v_C's affinity masks could solve this,
but that would also potentially increase the overhead (by asking _a_lot_
of CPUs to reschedule), and again, it's hard to say if/when it's
worth...

Actually, going all the way round, i.e., tickling only CPUs with
affinity with v_C (in this case) looks more reasonable, under the
assumption that v_w is going to be scheduled on P soon enough. In
general, that would mean tickling the CPUs in the affinity mask of the
vcpu with smaller priority, but I've not checked how that would interact
with the rest of the scheduling logic yet.

If I got things wrong and/or there's something I missed or overlooked,
please, accept my apologies. :-)

Thanks and Regards,
Dario

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-opzFX2sQqICEJj5AJ5Tw
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlCGnNwACgkQk4XaBE3IOsRs0wCgjv3K02r/384UCg0ZqkcLm8DM
5xAAni6YBtmBM9mp5BkBOalLiPuchyS6
=kdSt
-----END PGP SIGNATURE-----

--=-opzFX2sQqICEJj5AJ5Tw--



--===============8291746621744066086==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8291746621744066086==--



From xen-devel-bounces@lists.xen.org Tue Oct 23 13:35:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 13:35:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQecq-0008WM-EB; Tue, 23 Oct 2012 13:34:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQecp-0008W7-63
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 13:34:31 +0000
Received: from [85.158.143.35:19351] by server-3.bemta-4.messagelabs.com id
	36/FB-03544-6EC96805; Tue, 23 Oct 2012 13:34:30 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1350999269!5517728!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18894 invoked from network); 23 Oct 2012 13:34:29 -0000
Received: from mail-ea0-f173.google.com (HELO mail-ea0-f173.google.com)
	(209.85.215.173)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 13:34:29 -0000
Received: by mail-ea0-f173.google.com with SMTP id a1so1407512eaa.32
	for ; Tue, 23 Oct 2012 06:34:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:subject:from:to:cc:date:content-type:x-mailer
	:mime-version; bh=+DUNNYCwHc4d+D9o9L7mG05jFt8o061g41ewWsaGnIc=;
	b=JT+cmRZWSbfm43Y+XgLwiGwilkPIQ5ENPjh4U1asKpmjKbsKBhbAoNZc+yeE+pSt6a
	SUOFm4F7/pT7O3ov7VuFgsQAJtDHdkpf0i1+PMd+9fOiGgtN/0lole0GopW/kKnCfYNn
	uzBf/cvFzkaVDittru+lbJPztWLzpEWtMv5vfQEJdGgtqHpLCqELejL+534j0FzWa/Zf
	PGIBumRdHfI3IMnB4SzpGvTZkVpfD3c85DsNa64WpXO4yPwN3o2N0/0TZLuAbWNCiisA
	sdXopIcXjGQOzBj2BK/IGsDJ4ydPoij6Bt1Ez+wmJKmX9AumgeFX1YhXY3bixSYzUvtT
	Yxiw==
Received: by 10.14.178.195 with SMTP id f43mr16997232eem.44.1350999268849;
	Tue, 23 Oct 2012 06:34:28 -0700 (PDT)
Received: from [192.168.0.40] (ip-180-234.sn1.eutelia.it. [62.94.180.234])
	by mx.google.com with ESMTPS id o47sm20904438eem.11.2012.10.23.06.34.26
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 23 Oct 2012 06:34:27 -0700 (PDT)
Message-ID: <1350999260.5064.56.camel@Solace>
From: Dario Faggioli 
To: George Dunlap 
Date: Tue, 23 Oct 2012 15:34:20 +0200
X-Mailer: Evolution 3.4.3-1
Mime-Version: 1.0
Cc: Keir Fraser , Jan Beulich ,
	xen-devel 
Subject: [Xen-devel] About vcpu wakeup and runq tickling in credit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============8291746621744066086=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============8291746621744066086==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-opzFX2sQqICEJj5AJ5Tw"


--=-opzFX2sQqICEJj5AJ5Tw
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi George, Everyone,

While reworking a bit my NUMA aware scheduling patches I figured I'm not
sure I understand what __runq_tickle() (in xen/common/sched_credit.c, of
course) does.

Here's the thing. Upon every vcpu wakeup we put the new vcpu in a runq
and then call __runq_tickle(), passing the waking vcpu via 'new'. Let's
call the vcpu that just woke up v_W, and the vcpu that is currently
running on the cpu where that happens v_C. Let's also call the CPU where
all is happening P.

As far as I've understood, in  __runq_tickle(), we:


static inline void
__runq_tickle(unsigned int cpu, struct csched_vcpu *new)
{
    [...]
    cpumask_t mask;

    cpumask_clear(&mask);

    /* If strictly higher priority than current VCPU, signal the CPU */
    if ( new->pri > cur->pri )
    {
        [...]
        cpumask_set_cpu(cpu, &mask);
    }

--> Make sure we put the CPU we are on (P) in 'mask', in case the woken
--> vcpu (v_W) has higher priority that the currently running one (v_C).

    /*
     * If this CPU has at least two runnable VCPUs, we tickle any idlers to
     * let them know there is runnable work in the system...
     */
    if ( cur->pri > CSCHED_PRI_IDLE )
    {
        if ( cpumask_empty(prv->idlers) )
        [...]
        else
        {
            cpumask_t idle_mask;

            cpumask_and(&idle_mask, prv->idlers, new->vcpu->cpu_affinity);
            if ( !cpumask_empty(&idle_mask) )
            {
                [...]
                if ( opt_tickle_one_idle )
                {
                    [...]
                    cpumask_set_cpu(this_cpu(last_tickle_cpu), &mask);
                }
                else
                    cpumask_or(&mask, &mask, &idle_mask);
            }
            cpumask_and(&mask, &mask, new->vcpu->cpu_affinity);

--> Make sure we include one or more (depending on opt_tickle_one_idle)
--> CPUs that are both idle and part of v_W's CPU-affinity in 'mask'.

        }
    }

    /* Send scheduler interrupts to designated CPUs */
    if ( !cpumask_empty(&mask) )
        cpumask_raise_softirq(&mask, SCHEDULE_SOFTIRQ);

--> Ask all the CPUs in 'mask' to reschedule. That would mean all the
--> idlers from v_W's CPU-affinity and, possibly, "ourself" (P). The
--> effect will be that all/some of the CPUs v_W's has affinity with
--> _and_ (let's assume so) P will go through scheduling as quickly as
--> possible.

}

Is the above right?

If yes, here's my question. Is that right to always tickle v_W's affine
CPUs and only them?

I'm asking because a possible scenario, at least according to me, is
that P schedules very quickly after this and, as prio(v_W)>prio(v_C), it
selects v_W and leaves v_C in its runq. At that point, one of the
tickled CPU (say P') enters schedule, sees that P is not idle, and tries
to steal a vcpu from its runq. Now we know that P' has affinity with
v_W, but v_W is not there, while v_C is, and if P' is not in its
affinity, we've forced P' to reschedule for nothing.
Also, there now might be another (or even a number of) CPU where v_C
could run that stays idle, as it has not being tickled.

So, if that is true, it seems we leave some room for sub-optimal CPU
utilization, as well as some non-work conserving windows.
Of course, it is very hard to tell how frequent this actually happens.

As it comes to possible solution, I think that, for instance, tickling
all the CPUs in both v_W's and v_C's affinity masks could solve this,
but that would also potentially increase the overhead (by asking _a_lot_
of CPUs to reschedule), and again, it's hard to say if/when it's
worth...

Actually, going all the way round, i.e., tickling only CPUs with
affinity with v_C (in this case) looks more reasonable, under the
assumption that v_w is going to be scheduled on P soon enough. In
general, that would mean tickling the CPUs in the affinity mask of the
vcpu with smaller priority, but I've not checked how that would interact
with the rest of the scheduling logic yet.

If I got things wrong and/or there's something I missed or overlooked,
please, accept my apologies. :-)

Thanks and Regards,
Dario

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-opzFX2sQqICEJj5AJ5Tw
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlCGnNwACgkQk4XaBE3IOsRs0wCgjv3K02r/384UCg0ZqkcLm8DM
5xAAni6YBtmBM9mp5BkBOalLiPuchyS6
=kdSt
-----END PGP SIGNATURE-----

--=-opzFX2sQqICEJj5AJ5Tw--



--===============8291746621744066086==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8291746621744066086==--



From xen-devel-bounces@lists.xen.org Tue Oct 23 13:48:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 13:48:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQeq2-0000SV-A6; Tue, 23 Oct 2012 13:48:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQeq0-0000SQ-JQ
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 13:48:08 +0000
Received: from [85.158.139.83:62625] by server-3.bemta-5.messagelabs.com id
	27/65-28618-710A6805; Tue, 23 Oct 2012 13:48:07 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-10.tower-182.messagelabs.com!1351000086!36408030!1
X-Originating-IP: [192.134.164.105]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13241 invoked from network); 23 Oct 2012 13:48:07 -0000
Received: from mail4-relais-sop.national.inria.fr (HELO
	mail4-relais-sop.national.inria.fr) (192.134.164.105)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 13:48:07 -0000
X-IronPort-AV: E=Sophos;i="4.80,635,1344204000"; d="scan'208";a="160092482"
Received: from unknown (HELO type.ipv6) ([193.50.110.240])
	by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA;
	23 Oct 2012 15:48:05 +0200
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from )
	id 1TQepx-0004y4-Gi; Tue, 23 Oct 2012 15:48:05 +0200
Date: Tue, 23 Oct 2012 15:48:05 +0200
From: Samuel Thibault 
To: Adrian Shaw 
Message-ID: <20121023134805.GP5914@type.bordeaux.inria.fr>
Mail-Followup-To: Samuel Thibault ,
	Adrian Shaw ,
	Xen-devel 
References: 
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: Xen-devel 
Subject: Re: [Xen-devel] Mini-OS transactions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello,

Adrian Shaw, le Tue 23 Oct 2012 14:30:46 +0100, a =E9crit :
> I am struggling to understand how to initialise an xs_transaction_t for u=
se
> with the Mini-OS XenStore API.
> =

> Each function such as xs_read, xs_write take this type of variable in.
> However neither xs_transaction_start nor xs_transaction_end are defined in
> Mini-OS.

They are called xenbus_transaction_start and xenbus_transaction_end. See
use in various frontends & such.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 13:48:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 13:48:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQeq2-0000SV-A6; Tue, 23 Oct 2012 13:48:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQeq0-0000SQ-JQ
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 13:48:08 +0000
Received: from [85.158.139.83:62625] by server-3.bemta-5.messagelabs.com id
	27/65-28618-710A6805; Tue, 23 Oct 2012 13:48:07 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-10.tower-182.messagelabs.com!1351000086!36408030!1
X-Originating-IP: [192.134.164.105]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13241 invoked from network); 23 Oct 2012 13:48:07 -0000
Received: from mail4-relais-sop.national.inria.fr (HELO
	mail4-relais-sop.national.inria.fr) (192.134.164.105)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 13:48:07 -0000
X-IronPort-AV: E=Sophos;i="4.80,635,1344204000"; d="scan'208";a="160092482"
Received: from unknown (HELO type.ipv6) ([193.50.110.240])
	by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA;
	23 Oct 2012 15:48:05 +0200
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from )
	id 1TQepx-0004y4-Gi; Tue, 23 Oct 2012 15:48:05 +0200
Date: Tue, 23 Oct 2012 15:48:05 +0200
From: Samuel Thibault 
To: Adrian Shaw 
Message-ID: <20121023134805.GP5914@type.bordeaux.inria.fr>
Mail-Followup-To: Samuel Thibault ,
	Adrian Shaw ,
	Xen-devel 
References: 
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: Xen-devel 
Subject: Re: [Xen-devel] Mini-OS transactions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello,

Adrian Shaw, le Tue 23 Oct 2012 14:30:46 +0100, a =E9crit :
> I am struggling to understand how to initialise an xs_transaction_t for u=
se
> with the Mini-OS XenStore API.
> =

> Each function such as xs_read, xs_write take this type of variable in.
> However neither xs_transaction_start nor xs_transaction_end are defined in
> Mini-OS.

They are called xenbus_transaction_start and xenbus_transaction_end. See
use in various frontends & such.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 13:54:51 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 13:54:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQew7-0000cT-Ab; Tue, 23 Oct 2012 13:54:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQew5-0000cB-1L
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 13:54:25 +0000
Received: from [85.158.138.51:20533] by server-5.bemta-3.messagelabs.com id
	C0/DC-12440-091A6805; Tue, 23 Oct 2012 13:54:24 +0000
X-Env-Sender: adrian.l.shaw@gmail.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1351000462!27439182!1
X-Originating-IP: [209.85.212.169]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1746 invoked from network); 23 Oct 2012 13:54:22 -0000
Received: from mail-wi0-f169.google.com (HELO mail-wi0-f169.google.com)
	(209.85.212.169)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 13:54:22 -0000
Received: by mail-wi0-f169.google.com with SMTP id hq4so3332768wib.2
	for ; Tue, 23 Oct 2012 06:54:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:content-type; bh=ewjKnrh0X0PWgp4qF9C33IIlP8Yn1uCbyHICl2z9CuU=;
	b=PkwxYWmH/mHQjOkQbcbp0b/97GG2qGrwU6eLgKCeItOZAuvLLzTtcqoxBTmuQ5V13F
	/a5sEMWslMGQemOiUaXb/X95yWNPVJk0A+6ulFzLs7Y8pQBMk986oZ4XzRF7NScKCK0t
	TzQwITCoKR6LLf8sowEVYXd8dqZlXnBeQlMX8bcBI/ZxtA75wfeRwJSisydsstATdy9h
	PPnoFJpTXwxSOmVvOpiMzKO5zGj61+ZIeUpy8chgxrahQY0Yyfth6No4l3BZQpu0Bq1O
	GN3Wn4GxPh9tu9ncojvzdZinZGxHicN09TR1nfj6+ZbgBPzOlcM/RDCg1XzQDTSZqfP2
	wdtA==
Received: by 10.180.82.35 with SMTP id f3mr29420008wiy.6.1351000462016; Tue,
	23 Oct 2012 06:54:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.100.4 with HTTP; Tue, 23 Oct 2012 06:54:01 -0700 (PDT)
In-Reply-To: <20121023134805.GP5914@type.bordeaux.inria.fr>
References: 
	<20121023134805.GP5914@type.bordeaux.inria.fr>
From: Adrian Shaw 
Date: Tue, 23 Oct 2012 14:54:01 +0100
Message-ID: 
To: Samuel Thibault ,
	Adrian Shaw , Xen-devel 
Subject: Re: [Xen-devel] Mini-OS transactions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============7075662348214710263=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7075662348214710263==
Content-Type: multipart/alternative; boundary=f46d04430482a141ae04ccba4e9d

--f46d04430482a141ae04ccba4e9d
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Thanks for your reply Samuel.

Since you are the author of minios/lib/xs I have just one follow up
question :-)
Is it not yet possible to do change the permission of a XenStore entry from
Mini-OS?
I've been able to do it on a Linux DomU using xenstore.h

Best regards,
Adrian

On Tue, Oct 23, 2012 at 2:48 PM, Samuel Thibault <
samuel.thibault@ens-lyon.org> wrote:

> Hello,
>
> Adrian Shaw, le Tue 23 Oct 2012 14:30:46 +0100, a =E9crit :
> > I am struggling to understand how to initialise an xs_transaction_t for
> use
> > with the Mini-OS XenStore API.
> >
> > Each function such as xs_read, xs_write take this type of variable in.
> > However neither xs_transaction_start nor xs_transaction_end are defined
> in
> > Mini-OS.
>
> They are called xenbus_transaction_start and xenbus_transaction_end. See
> use in various frontends & such.
>
> Samuel
>

--f46d04430482a141ae04ccba4e9d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Thanks for your reply Samuel.

Since you are the author of mini=
os/lib/xs I have just one follow up question :-)
Is it not yet po=
ssible to do change the permission of a XenStore entry from Mini-OS?



I've been able to do it on a Linux DomU using xenstore.h

Best regards,
Adrian

On Tue, Oct 23, 2012 at 2:48 PM, Samuel Thibault <=
samuel.thibault@ens-lyon.org> wrote:



Hello,



Adrian Shaw, le Tue 23 Oct 2012 14:30:46 +0100, a =E9crit :


> I am struggling to understand how to initialise an x=
s_transaction_t for use

> with the Mini-OS XenStore API.

>

> Each function such as xs_read, xs_write take this type of variable in.=


> However neither xs_transaction_start nor xs_transaction_end are define=
d in

> Mini-OS.




They are called xenbus_transaction_start and xenbus_transaction_end. =
See

use in various frontends & such.



Samuel





--f46d04430482a141ae04ccba4e9d--


--===============7075662348214710263==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7075662348214710263==--


From xen-devel-bounces@lists.xen.org Tue Oct 23 13:54:51 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 13:54:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQew7-0000cT-Ab; Tue, 23 Oct 2012 13:54:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQew5-0000cB-1L
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 13:54:25 +0000
Received: from [85.158.138.51:20533] by server-5.bemta-3.messagelabs.com id
	C0/DC-12440-091A6805; Tue, 23 Oct 2012 13:54:24 +0000
X-Env-Sender: adrian.l.shaw@gmail.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1351000462!27439182!1
X-Originating-IP: [209.85.212.169]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1746 invoked from network); 23 Oct 2012 13:54:22 -0000
Received: from mail-wi0-f169.google.com (HELO mail-wi0-f169.google.com)
	(209.85.212.169)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 13:54:22 -0000
Received: by mail-wi0-f169.google.com with SMTP id hq4so3332768wib.2
	for ; Tue, 23 Oct 2012 06:54:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:content-type; bh=ewjKnrh0X0PWgp4qF9C33IIlP8Yn1uCbyHICl2z9CuU=;
	b=PkwxYWmH/mHQjOkQbcbp0b/97GG2qGrwU6eLgKCeItOZAuvLLzTtcqoxBTmuQ5V13F
	/a5sEMWslMGQemOiUaXb/X95yWNPVJk0A+6ulFzLs7Y8pQBMk986oZ4XzRF7NScKCK0t
	TzQwITCoKR6LLf8sowEVYXd8dqZlXnBeQlMX8bcBI/ZxtA75wfeRwJSisydsstATdy9h
	PPnoFJpTXwxSOmVvOpiMzKO5zGj61+ZIeUpy8chgxrahQY0Yyfth6No4l3BZQpu0Bq1O
	GN3Wn4GxPh9tu9ncojvzdZinZGxHicN09TR1nfj6+ZbgBPzOlcM/RDCg1XzQDTSZqfP2
	wdtA==
Received: by 10.180.82.35 with SMTP id f3mr29420008wiy.6.1351000462016; Tue,
	23 Oct 2012 06:54:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.100.4 with HTTP; Tue, 23 Oct 2012 06:54:01 -0700 (PDT)
In-Reply-To: <20121023134805.GP5914@type.bordeaux.inria.fr>
References: 
	<20121023134805.GP5914@type.bordeaux.inria.fr>
From: Adrian Shaw 
Date: Tue, 23 Oct 2012 14:54:01 +0100
Message-ID: 
To: Samuel Thibault ,
	Adrian Shaw , Xen-devel 
Subject: Re: [Xen-devel] Mini-OS transactions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============7075662348214710263=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7075662348214710263==
Content-Type: multipart/alternative; boundary=f46d04430482a141ae04ccba4e9d

--f46d04430482a141ae04ccba4e9d
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Thanks for your reply Samuel.

Since you are the author of minios/lib/xs I have just one follow up
question :-)
Is it not yet possible to do change the permission of a XenStore entry from
Mini-OS?
I've been able to do it on a Linux DomU using xenstore.h

Best regards,
Adrian

On Tue, Oct 23, 2012 at 2:48 PM, Samuel Thibault <
samuel.thibault@ens-lyon.org> wrote:

> Hello,
>
> Adrian Shaw, le Tue 23 Oct 2012 14:30:46 +0100, a =E9crit :
> > I am struggling to understand how to initialise an xs_transaction_t for
> use
> > with the Mini-OS XenStore API.
> >
> > Each function such as xs_read, xs_write take this type of variable in.
> > However neither xs_transaction_start nor xs_transaction_end are defined
> in
> > Mini-OS.
>
> They are called xenbus_transaction_start and xenbus_transaction_end. See
> use in various frontends & such.
>
> Samuel
>

--f46d04430482a141ae04ccba4e9d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Thanks for your reply Samuel.

Since you are the author of mini=
os/lib/xs I have just one follow up question :-)
Is it not yet po=
ssible to do change the permission of a XenStore entry from Mini-OS?



I've been able to do it on a Linux DomU using xenstore.h

Best regards,
Adrian

On Tue, Oct 23, 2012 at 2:48 PM, Samuel Thibault <=
samuel.thibault@ens-lyon.org> wrote:



Hello,



Adrian Shaw, le Tue 23 Oct 2012 14:30:46 +0100, a =E9crit :


> I am struggling to understand how to initialise an x=
s_transaction_t for use

> with the Mini-OS XenStore API.

>

> Each function such as xs_read, xs_write take this type of variable in.=


> However neither xs_transaction_start nor xs_transaction_end are define=
d in

> Mini-OS.




They are called xenbus_transaction_start and xenbus_transaction_end. =
See

use in various frontends & such.



Samuel





--f46d04430482a141ae04ccba4e9d--


--===============7075662348214710263==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7075662348214710263==--


From xen-devel-bounces@lists.xen.org Tue Oct 23 13:56:53 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 13:56:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQey5-0000kh-Rh; Tue, 23 Oct 2012 13:56:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQey4-0000kb-Qa
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 13:56:29 +0000
Received: from [85.158.143.99:13459] by server-1.bemta-4.messagelabs.com id
	BA/D1-19134-C02A6805; Tue, 23 Oct 2012 13:56:28 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1351000583!28217909!1
X-Originating-IP: [213.199.154.139]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6659 invoked from network); 23 Oct 2012 13:56:23 -0000
Received: from db3ehsobe001.messaging.microsoft.com (HELO
	db3outboundpool.messaging.microsoft.com) (213.199.154.139)
	by server-6.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	23 Oct 2012 13:56:23 -0000
Received: from mail6-db3-R.bigfish.com (10.3.81.227) by
	DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id
	14.1.225.23; Tue, 23 Oct 2012 13:56:22 +0000
Received: from mail6-db3 (localhost [127.0.0.1])	by mail6-db3-R.bigfish.com
	(Postfix) with ESMTP id 8E910480058;
	Tue, 23 Oct 2012 13:56:22 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: -1
X-BigFish: VPS-1(zzc85dhc857h4015Izz1202h1d1ah1d2ahzzz2dh668h839hd25he5bhf0ah107ah1288h12a5h12bdh137ah1441h1504h34h1155h)
Received: from mail6-db3 (localhost.localdomain [127.0.0.1]) by mail6-db3
	(MessageSwitch) id 1351000580290140_8533;
	Tue, 23 Oct 2012 13:56:20 +0000 (UTC)
Received: from DB3EHSMHS008.bigfish.com (unknown [10.3.81.242])	by
	mail6-db3.bigfish.com (Postfix) with ESMTP id 44D642E004E;
	Tue, 23 Oct 2012 13:56:20 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS008.bigfish.com (10.3.87.108) with Microsoft SMTP Server id
	14.1.225.23; Tue, 23 Oct 2012 13:56:17 +0000
X-WSS-ID: 0MCCMPP-01-EEW-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2414A1028041;	Tue, 23 Oct 2012 08:56:13 -0500 (CDT)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 23 Oct 2012 08:56:22 -0500
Received: from STOREXDAG04.amd.com (10.1.13.13) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Tue, 23 Oct 2012 08:56:13 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexdag04.amd.com
	(10.1.13.13) with Microsoft SMTP Server id 14.2.318.4; Tue, 23 Oct 2012
	09:56:12 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 93B5049C1E6; Tue, 23 Oct 2012
	14:56:11 +0100 (BST)
Message-ID: <5086A224.2070801@amd.com>
Date: Tue, 23 Oct 2012 15:56:52 +0200
From: Wei Wang 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120421 Thunderbird/12.0
MIME-Version: 1.0
To: Jan Beulich 
Content-Type: multipart/mixed; boundary="------------090607010605010201020305"
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" 
Subject: [Xen-devel] [PATCH] AMD IOMMU: Enable HPET broadcast msi remapping
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------090607010605010201020305
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

Hi Jan,

This patch enables hpet msi remapping for amd iommu. Please review
Thanks,
Wei


--------------090607010605010201020305
Content-Type: text/plain; charset="UTF-8";
	name="0001-AMD-IOMMU-Enable-HPET-broadcast-msi-remapping.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="0001-AMD-IOMMU-Enable-HPET-broadcast-msi-remapping.patch"
Content-Description: 0001-AMD-IOMMU-Enable-HPET-broadcast-msi-remapping.patch

>From 79dc3ed42e64c66fb261a5bad2834718330fe767 Mon Sep 17 00:00:00 2001
From: Wei Wang 
Date: Tue, 23 Oct 2012 15:52:34 +0200
Subject: [PATCH] AMD IOMMU: Enable HPET broadcast msi remapping

This patch enables hpet msi remapping for amd iommu.

Signed-off-by: Wei Wang 
---
 xen/drivers/passthrough/amd/iommu_acpi.c      |   20 +++++++++++++-
 xen/drivers/passthrough/amd/iommu_intr.c      |   34 +++++++++++++++++++------
 xen/drivers/passthrough/amd/pci_amd_iommu.c   |    1 +
 xen/include/asm-x86/hvm/svm/amd-iommu-proto.h |    6 ++++
 4 files changed, 51 insertions(+), 10 deletions(-)

diff --git a/xen/drivers/passthrough/amd/iommu_acpi.c b/xen/drivers/passthrough/amd/iommu_acpi.c
index e217d45..6606014 100644
--- a/xen/drivers/passthrough/amd/iommu_acpi.c
+++ b/xen/drivers/passthrough/amd/iommu_acpi.c
@@ -653,9 +653,25 @@ static u16 __init parse_ivhd_device_special(
     }
 
     add_ivrs_mapping_entry(bdf, bdf, special->header.data_setting, iommu);
+    
+    switch ( special->variety )
+    {
+    case 1:
     /* set device id of ioapic */
-    ioapic_sbdf[special->handle].bdf = bdf;
-    ioapic_sbdf[special->handle].seg = seg;
+        ioapic_sbdf[special->handle].bdf = bdf;
+        ioapic_sbdf[special->handle].seg = seg;
+        break;
+    case 2:
+        /* set device id of hpet */
+        hpet_sbdf.id = special->handle;
+        hpet_sbdf.bdf = bdf;
+        hpet_sbdf.seg = seg;
+        hpet_sbdf.iommu = iommu;
+        break;            
+    default:
+        return 0;
+    }
+        
     return dev_length;
 }
 
diff --git a/xen/drivers/passthrough/amd/iommu_intr.c b/xen/drivers/passthrough/amd/iommu_intr.c
index 23cb1ea..26b3465 100644
--- a/xen/drivers/passthrough/amd/iommu_intr.c
+++ b/xen/drivers/passthrough/amd/iommu_intr.c
@@ -28,6 +28,7 @@
 #define INTREMAP_ENTRIES (1 << INTREMAP_LENGTH)
 
 struct ioapic_sbdf ioapic_sbdf[MAX_IO_APICS];
+struct hpet_sbdf hpet_sbdf;
 void *shared_intremap_table;
 static DEFINE_SPINLOCK(shared_intremap_lock);
 
@@ -267,14 +268,16 @@ static void update_intremap_entry_from_msi_msg(
 {
     unsigned long flags;
     u32* entry;
-    u16 bdf, req_id, alias_id;
+    u16 seg, bdf, req_id, alias_id;
     u8 delivery_mode, dest, vector, dest_mode;
     spinlock_t *lock;
     int offset;
 
-    bdf = PCI_BDF2(pdev->bus, pdev->devfn);
-    req_id = get_dma_requestor_id(pdev->seg, bdf);
-    alias_id = get_intremap_requestor_id(pdev->seg, bdf);
+    bdf = pdev ? PCI_BDF2(pdev->bus, pdev->devfn) : hpet_sbdf.bdf;
+    seg = pdev ? pdev->seg : hpet_sbdf.seg;
+    
+    req_id = get_dma_requestor_id(seg, bdf);
+    alias_id = get_intremap_requestor_id(seg, bdf);
 
     if ( msg == NULL )
     {
@@ -284,7 +287,7 @@ static void update_intremap_entry_from_msi_msg(
         spin_unlock_irqrestore(lock, flags);
 
         if ( ( req_id != alias_id ) &&
-             get_ivrs_mappings(pdev->seg)[alias_id].intremap_table != NULL )
+             get_ivrs_mappings(seg)[alias_id].intremap_table != NULL )
         {
             lock = get_intremap_lock(iommu->seg, alias_id);
             spin_lock_irqsave(lock, flags);
@@ -317,7 +320,7 @@ static void update_intremap_entry_from_msi_msg(
 
     lock = get_intremap_lock(iommu->seg, alias_id);
     if ( ( req_id != alias_id ) &&
-         get_ivrs_mappings(pdev->seg)[alias_id].intremap_table != NULL )
+         get_ivrs_mappings(seg)[alias_id].intremap_table != NULL )
     {
         spin_lock_irqsave(lock, flags);
         entry = (u32*)get_intremap_entry(iommu->seg, alias_id, offset);
@@ -340,13 +343,16 @@ void amd_iommu_msi_msg_update_ire(
     struct msi_desc *msi_desc, struct msi_msg *msg)
 {
     struct pci_dev *pdev = msi_desc->dev;
-    int bdf = PCI_BDF2(pdev->bus, pdev->devfn);
+    int bdf, seg; 
     struct amd_iommu *iommu;
 
     if ( !iommu_intremap )
         return;
 
-    iommu = find_iommu_for_device(pdev->seg, bdf);
+    bdf = pdev ? PCI_BDF2(pdev->bus, pdev->devfn) : hpet_sbdf.bdf;
+    seg = pdev ? pdev->seg : hpet_sbdf.seg;
+    
+    iommu = find_iommu_for_device(seg, bdf);
     if ( !iommu )
     {
         AMD_IOMMU_DEBUG("Fail to find iommu for MSI device id = %#x\n", bdf);
@@ -383,3 +389,15 @@ void* __init amd_iommu_alloc_intremap_table(void)
     memset(tb, 0, PAGE_SIZE * (1UL << INTREMAP_TABLE_ORDER));
     return tb;
 }
+
+int __init amd_setup_hpet_msi(struct msi_desc *msi_desc)
+{
+    if ( (!msi_desc->hpet_id != hpet_sbdf.id) || 
+         (hpet_sbdf.iommu == NULL) )
+    {
+        AMD_IOMMU_DEBUG("Fail to setup HPET MSI remapping\n");
+        return 1;        
+    }
+
+    return 0;
+}
diff --git a/xen/drivers/passthrough/amd/pci_amd_iommu.c b/xen/drivers/passthrough/amd/pci_amd_iommu.c
index b633f1c..7e37348 100644
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -595,6 +595,7 @@ const struct iommu_ops amd_iommu_ops = {
     .update_ire_from_msi = amd_iommu_msi_msg_update_ire,
     .read_apic_from_ire = __io_apic_read,
     .read_msi_from_ire = amd_iommu_read_msi_from_ire,
+    .setup_hpet_msi = amd_setup_hpet_msi,
     .suspend = amd_iommu_suspend,
     .resume = amd_iommu_resume,
     .share_p2m = amd_iommu_share_p2m,
diff --git a/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h b/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
index 8c425a3..7bef915 100644
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
@@ -97,12 +97,18 @@ void amd_iommu_msi_msg_update_ire(
     struct msi_desc *msi_desc, struct msi_msg *msg);
 void amd_iommu_read_msi_from_ire(
     struct msi_desc *msi_desc, struct msi_msg *msg);
+int __init amd_setup_hpet_msi(struct msi_desc *msi_desc);
 
 extern struct ioapic_sbdf {
     u16 bdf, seg;
 } ioapic_sbdf[MAX_IO_APICS];
 extern void *shared_intremap_table;
 
+extern struct hpet_sbdf {
+    u16 bdf, seg, id;
+    struct amd_iommu *iommu;
+} hpet_sbdf;
+
 /* power management support */
 void amd_iommu_resume(void);
 void amd_iommu_suspend(void);
-- 
1.7.4


--------------090607010605010201020305
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------090607010605010201020305--


From xen-devel-bounces@lists.xen.org Tue Oct 23 13:56:53 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 13:56:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQey5-0000kh-Rh; Tue, 23 Oct 2012 13:56:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQey4-0000kb-Qa
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 13:56:29 +0000
Received: from [85.158.143.99:13459] by server-1.bemta-4.messagelabs.com id
	BA/D1-19134-C02A6805; Tue, 23 Oct 2012 13:56:28 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1351000583!28217909!1
X-Originating-IP: [213.199.154.139]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6659 invoked from network); 23 Oct 2012 13:56:23 -0000
Received: from db3ehsobe001.messaging.microsoft.com (HELO
	db3outboundpool.messaging.microsoft.com) (213.199.154.139)
	by server-6.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	23 Oct 2012 13:56:23 -0000
Received: from mail6-db3-R.bigfish.com (10.3.81.227) by
	DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id
	14.1.225.23; Tue, 23 Oct 2012 13:56:22 +0000
Received: from mail6-db3 (localhost [127.0.0.1])	by mail6-db3-R.bigfish.com
	(Postfix) with ESMTP id 8E910480058;
	Tue, 23 Oct 2012 13:56:22 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: -1
X-BigFish: VPS-1(zzc85dhc857h4015Izz1202h1d1ah1d2ahzzz2dh668h839hd25he5bhf0ah107ah1288h12a5h12bdh137ah1441h1504h34h1155h)
Received: from mail6-db3 (localhost.localdomain [127.0.0.1]) by mail6-db3
	(MessageSwitch) id 1351000580290140_8533;
	Tue, 23 Oct 2012 13:56:20 +0000 (UTC)
Received: from DB3EHSMHS008.bigfish.com (unknown [10.3.81.242])	by
	mail6-db3.bigfish.com (Postfix) with ESMTP id 44D642E004E;
	Tue, 23 Oct 2012 13:56:20 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS008.bigfish.com (10.3.87.108) with Microsoft SMTP Server id
	14.1.225.23; Tue, 23 Oct 2012 13:56:17 +0000
X-WSS-ID: 0MCCMPP-01-EEW-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2414A1028041;	Tue, 23 Oct 2012 08:56:13 -0500 (CDT)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 23 Oct 2012 08:56:22 -0500
Received: from STOREXDAG04.amd.com (10.1.13.13) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Tue, 23 Oct 2012 08:56:13 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexdag04.amd.com
	(10.1.13.13) with Microsoft SMTP Server id 14.2.318.4; Tue, 23 Oct 2012
	09:56:12 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 93B5049C1E6; Tue, 23 Oct 2012
	14:56:11 +0100 (BST)
Message-ID: <5086A224.2070801@amd.com>
Date: Tue, 23 Oct 2012 15:56:52 +0200
From: Wei Wang 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:12.0) Gecko/20120421 Thunderbird/12.0
MIME-Version: 1.0
To: Jan Beulich 
Content-Type: multipart/mixed; boundary="------------090607010605010201020305"
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" 
Subject: [Xen-devel] [PATCH] AMD IOMMU: Enable HPET broadcast msi remapping
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------090607010605010201020305
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

Hi Jan,

This patch enables hpet msi remapping for amd iommu. Please review
Thanks,
Wei


--------------090607010605010201020305
Content-Type: text/plain; charset="UTF-8";
	name="0001-AMD-IOMMU-Enable-HPET-broadcast-msi-remapping.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="0001-AMD-IOMMU-Enable-HPET-broadcast-msi-remapping.patch"
Content-Description: 0001-AMD-IOMMU-Enable-HPET-broadcast-msi-remapping.patch

>From 79dc3ed42e64c66fb261a5bad2834718330fe767 Mon Sep 17 00:00:00 2001
From: Wei Wang 
Date: Tue, 23 Oct 2012 15:52:34 +0200
Subject: [PATCH] AMD IOMMU: Enable HPET broadcast msi remapping

This patch enables hpet msi remapping for amd iommu.

Signed-off-by: Wei Wang 
---
 xen/drivers/passthrough/amd/iommu_acpi.c      |   20 +++++++++++++-
 xen/drivers/passthrough/amd/iommu_intr.c      |   34 +++++++++++++++++++------
 xen/drivers/passthrough/amd/pci_amd_iommu.c   |    1 +
 xen/include/asm-x86/hvm/svm/amd-iommu-proto.h |    6 ++++
 4 files changed, 51 insertions(+), 10 deletions(-)

diff --git a/xen/drivers/passthrough/amd/iommu_acpi.c b/xen/drivers/passthrough/amd/iommu_acpi.c
index e217d45..6606014 100644
--- a/xen/drivers/passthrough/amd/iommu_acpi.c
+++ b/xen/drivers/passthrough/amd/iommu_acpi.c
@@ -653,9 +653,25 @@ static u16 __init parse_ivhd_device_special(
     }
 
     add_ivrs_mapping_entry(bdf, bdf, special->header.data_setting, iommu);
+    
+    switch ( special->variety )
+    {
+    case 1:
     /* set device id of ioapic */
-    ioapic_sbdf[special->handle].bdf = bdf;
-    ioapic_sbdf[special->handle].seg = seg;
+        ioapic_sbdf[special->handle].bdf = bdf;
+        ioapic_sbdf[special->handle].seg = seg;
+        break;
+    case 2:
+        /* set device id of hpet */
+        hpet_sbdf.id = special->handle;
+        hpet_sbdf.bdf = bdf;
+        hpet_sbdf.seg = seg;
+        hpet_sbdf.iommu = iommu;
+        break;            
+    default:
+        return 0;
+    }
+        
     return dev_length;
 }
 
diff --git a/xen/drivers/passthrough/amd/iommu_intr.c b/xen/drivers/passthrough/amd/iommu_intr.c
index 23cb1ea..26b3465 100644
--- a/xen/drivers/passthrough/amd/iommu_intr.c
+++ b/xen/drivers/passthrough/amd/iommu_intr.c
@@ -28,6 +28,7 @@
 #define INTREMAP_ENTRIES (1 << INTREMAP_LENGTH)
 
 struct ioapic_sbdf ioapic_sbdf[MAX_IO_APICS];
+struct hpet_sbdf hpet_sbdf;
 void *shared_intremap_table;
 static DEFINE_SPINLOCK(shared_intremap_lock);
 
@@ -267,14 +268,16 @@ static void update_intremap_entry_from_msi_msg(
 {
     unsigned long flags;
     u32* entry;
-    u16 bdf, req_id, alias_id;
+    u16 seg, bdf, req_id, alias_id;
     u8 delivery_mode, dest, vector, dest_mode;
     spinlock_t *lock;
     int offset;
 
-    bdf = PCI_BDF2(pdev->bus, pdev->devfn);
-    req_id = get_dma_requestor_id(pdev->seg, bdf);
-    alias_id = get_intremap_requestor_id(pdev->seg, bdf);
+    bdf = pdev ? PCI_BDF2(pdev->bus, pdev->devfn) : hpet_sbdf.bdf;
+    seg = pdev ? pdev->seg : hpet_sbdf.seg;
+    
+    req_id = get_dma_requestor_id(seg, bdf);
+    alias_id = get_intremap_requestor_id(seg, bdf);
 
     if ( msg == NULL )
     {
@@ -284,7 +287,7 @@ static void update_intremap_entry_from_msi_msg(
         spin_unlock_irqrestore(lock, flags);
 
         if ( ( req_id != alias_id ) &&
-             get_ivrs_mappings(pdev->seg)[alias_id].intremap_table != NULL )
+             get_ivrs_mappings(seg)[alias_id].intremap_table != NULL )
         {
             lock = get_intremap_lock(iommu->seg, alias_id);
             spin_lock_irqsave(lock, flags);
@@ -317,7 +320,7 @@ static void update_intremap_entry_from_msi_msg(
 
     lock = get_intremap_lock(iommu->seg, alias_id);
     if ( ( req_id != alias_id ) &&
-         get_ivrs_mappings(pdev->seg)[alias_id].intremap_table != NULL )
+         get_ivrs_mappings(seg)[alias_id].intremap_table != NULL )
     {
         spin_lock_irqsave(lock, flags);
         entry = (u32*)get_intremap_entry(iommu->seg, alias_id, offset);
@@ -340,13 +343,16 @@ void amd_iommu_msi_msg_update_ire(
     struct msi_desc *msi_desc, struct msi_msg *msg)
 {
     struct pci_dev *pdev = msi_desc->dev;
-    int bdf = PCI_BDF2(pdev->bus, pdev->devfn);
+    int bdf, seg; 
     struct amd_iommu *iommu;
 
     if ( !iommu_intremap )
         return;
 
-    iommu = find_iommu_for_device(pdev->seg, bdf);
+    bdf = pdev ? PCI_BDF2(pdev->bus, pdev->devfn) : hpet_sbdf.bdf;
+    seg = pdev ? pdev->seg : hpet_sbdf.seg;
+    
+    iommu = find_iommu_for_device(seg, bdf);
     if ( !iommu )
     {
         AMD_IOMMU_DEBUG("Fail to find iommu for MSI device id = %#x\n", bdf);
@@ -383,3 +389,15 @@ void* __init amd_iommu_alloc_intremap_table(void)
     memset(tb, 0, PAGE_SIZE * (1UL << INTREMAP_TABLE_ORDER));
     return tb;
 }
+
+int __init amd_setup_hpet_msi(struct msi_desc *msi_desc)
+{
+    if ( (!msi_desc->hpet_id != hpet_sbdf.id) || 
+         (hpet_sbdf.iommu == NULL) )
+    {
+        AMD_IOMMU_DEBUG("Fail to setup HPET MSI remapping\n");
+        return 1;        
+    }
+
+    return 0;
+}
diff --git a/xen/drivers/passthrough/amd/pci_amd_iommu.c b/xen/drivers/passthrough/amd/pci_amd_iommu.c
index b633f1c..7e37348 100644
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -595,6 +595,7 @@ const struct iommu_ops amd_iommu_ops = {
     .update_ire_from_msi = amd_iommu_msi_msg_update_ire,
     .read_apic_from_ire = __io_apic_read,
     .read_msi_from_ire = amd_iommu_read_msi_from_ire,
+    .setup_hpet_msi = amd_setup_hpet_msi,
     .suspend = amd_iommu_suspend,
     .resume = amd_iommu_resume,
     .share_p2m = amd_iommu_share_p2m,
diff --git a/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h b/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
index 8c425a3..7bef915 100644
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
@@ -97,12 +97,18 @@ void amd_iommu_msi_msg_update_ire(
     struct msi_desc *msi_desc, struct msi_msg *msg);
 void amd_iommu_read_msi_from_ire(
     struct msi_desc *msi_desc, struct msi_msg *msg);
+int __init amd_setup_hpet_msi(struct msi_desc *msi_desc);
 
 extern struct ioapic_sbdf {
     u16 bdf, seg;
 } ioapic_sbdf[MAX_IO_APICS];
 extern void *shared_intremap_table;
 
+extern struct hpet_sbdf {
+    u16 bdf, seg, id;
+    struct amd_iommu *iommu;
+} hpet_sbdf;
+
 /* power management support */
 void amd_iommu_resume(void);
 void amd_iommu_suspend(void);
-- 
1.7.4


--------------090607010605010201020305
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------090607010605010201020305--


From xen-devel-bounces@lists.xen.org Tue Oct 23 14:01:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 14:01:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQf20-0000zs-Gr; Tue, 23 Oct 2012 14:00:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQf1y-0000zk-QT
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 14:00:30 +0000
Received: from [85.158.138.51:16721] by server-12.bemta-3.messagelabs.com id
	7B/AC-27853-DF2A6805; Tue, 23 Oct 2012 14:00:29 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-12.tower-174.messagelabs.com!1351000828!27537461!1
X-Originating-IP: [192.134.164.82]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25897 invoked from network); 23 Oct 2012 14:00:28 -0000
Received: from mail1-relais-roc.national.inria.fr (HELO
	mail1-relais-roc.national.inria.fr) (192.134.164.82)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 14:00:28 -0000
X-IronPort-AV: E=Sophos;i="4.80,635,1344204000"; d="scan'208";a="178550216"
Received: from unknown (HELO type.ipv6) ([193.50.110.240])
	by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA;
	23 Oct 2012 16:00:21 +0200
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from )
	id 1TQf1p-0005NK-H7; Tue, 23 Oct 2012 16:00:21 +0200
Date: Tue, 23 Oct 2012 16:00:21 +0200
From: Samuel Thibault 
To: Adrian Shaw 
Message-ID: <20121023140021.GR5914@type.bordeaux.inria.fr>
Mail-Followup-To: Samuel Thibault ,
	Adrian Shaw ,
	Xen-devel 
References: 
	<20121023134805.GP5914@type.bordeaux.inria.fr>
	
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: Xen-devel 
Subject: Re: [Xen-devel] Mini-OS transactions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Adrian Shaw, le Tue 23 Oct 2012 14:54:01 +0100, a =E9crit :
> Since you are the author of minios/lib/xs

Err, I'm not :)
I'm just the current de-facto maintainer.

> Is it not yet possible to do change the permission of a XenStore entry fr=
om
> Mini-OS?

Apparently there is a xenbus_set_perms function.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 14:01:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 14:01:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQf20-0000zs-Gr; Tue, 23 Oct 2012 14:00:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQf1y-0000zk-QT
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 14:00:30 +0000
Received: from [85.158.138.51:16721] by server-12.bemta-3.messagelabs.com id
	7B/AC-27853-DF2A6805; Tue, 23 Oct 2012 14:00:29 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-12.tower-174.messagelabs.com!1351000828!27537461!1
X-Originating-IP: [192.134.164.82]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25897 invoked from network); 23 Oct 2012 14:00:28 -0000
Received: from mail1-relais-roc.national.inria.fr (HELO
	mail1-relais-roc.national.inria.fr) (192.134.164.82)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 14:00:28 -0000
X-IronPort-AV: E=Sophos;i="4.80,635,1344204000"; d="scan'208";a="178550216"
Received: from unknown (HELO type.ipv6) ([193.50.110.240])
	by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA;
	23 Oct 2012 16:00:21 +0200
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from )
	id 1TQf1p-0005NK-H7; Tue, 23 Oct 2012 16:00:21 +0200
Date: Tue, 23 Oct 2012 16:00:21 +0200
From: Samuel Thibault 
To: Adrian Shaw 
Message-ID: <20121023140021.GR5914@type.bordeaux.inria.fr>
Mail-Followup-To: Samuel Thibault ,
	Adrian Shaw ,
	Xen-devel 
References: 
	<20121023134805.GP5914@type.bordeaux.inria.fr>
	
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: Xen-devel 
Subject: Re: [Xen-devel] Mini-OS transactions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Adrian Shaw, le Tue 23 Oct 2012 14:54:01 +0100, a =E9crit :
> Since you are the author of minios/lib/xs

Err, I'm not :)
I'm just the current de-facto maintainer.

> Is it not yet possible to do change the permission of a XenStore entry fr=
om
> Mini-OS?

Apparently there is a xenbus_set_perms function.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 14:08:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 14:08:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQf9E-0001Dm-HI; Tue, 23 Oct 2012 14:08:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQf9D-0001Dh-9H
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 14:07:59 +0000
Received: from [85.158.139.211:50681] by server-11.bemta-5.messagelabs.com id
	AD/0F-14870-EB4A6805; Tue, 23 Oct 2012 14:07:58 +0000
X-Env-Sender: adrian.l.shaw@gmail.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1351001277!19434394!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6478 invoked from network); 23 Oct 2012 14:07:57 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 14:07:57 -0000
Received: by mail-we0-f173.google.com with SMTP id t11so2600753wey.32
	for ; Tue, 23 Oct 2012 07:07:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:content-type; bh=ml1FgbfMkd3MzVjdnxPpjpxHaKr3YuptJsagL5aCdVw=;
	b=ABuL1haXO2TNXVNDf4ezT5kxvxhiQKGw3QPHX9jiXzXOU1J3RfSDPn2iYMHDi9PrVG
	z8X1Tol/Zqok44ipAJ7DI/IFiiD9QeAoS0Nsbe7JiFzeej2OzM3IchOnoOB4X6BGNXBO
	AnWfdl4pxYNfuDZ+8Yon7X5Lcwbiw5XVe/3mdfcvSzHPzllscqKv7ZIGnDVQtp9c9CNV
	TaECRD1lsapCLVuTenD0g4p5dXUnJTQKcA/uDcZ9VFZqyfYJKTEL+InoiqQyjAFXcZZq
	Pt99nNWiywUI7gRrDOIsng6b6Y6E+95b44Q492j87ZIZgujC9DjuwuH323yGQlsvnFNU
	8sQQ==
Received: by 10.216.56.82 with SMTP id l60mr7140744wec.18.1351001277642; Tue,
	23 Oct 2012 07:07:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.100.4 with HTTP; Tue, 23 Oct 2012 07:07:37 -0700 (PDT)
In-Reply-To: <20121023140021.GR5914@type.bordeaux.inria.fr>
References: 
	<20121023134805.GP5914@type.bordeaux.inria.fr>
	
	<20121023140021.GR5914@type.bordeaux.inria.fr>
From: Adrian Shaw 
Date: Tue, 23 Oct 2012 15:07:37 +0100
Message-ID: 
To: Samuel Thibault ,
	Adrian Shaw , Xen-devel 
Subject: Re: [Xen-devel] Mini-OS transactions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============4505367713525666948=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4505367713525666948==
Content-Type: multipart/alternative; boundary=0016e6d9a1533eb9fa04ccba7fd5

--0016e6d9a1533eb9fa04ccba7fd5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Oops, bad assumption to make, sorry!
Many thanks for the pointer.
It's a bit confusing this mix of function naming when it comes to XenStore
and XenBus.

Again, grateful for your help.

Best,
Adrian

On Tue, Oct 23, 2012 at 3:00 PM, Samuel Thibault <
samuel.thibault@ens-lyon.org> wrote:

> Adrian Shaw, le Tue 23 Oct 2012 14:54:01 +0100, a =E9crit :
> > Since you are the author of minios/lib/xs
>
> Err, I'm not :)
> I'm just the current de-facto maintainer.
>
> > Is it not yet possible to do change the permission of a XenStore entry
> from
> > Mini-OS?
>
> Apparently there is a xenbus_set_perms function.
>
> Samuel
>

--0016e6d9a1533eb9fa04ccba7fd5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Oops, bad assumption to make, sorry!
Many thanks for the pointer.
=

It's a bit confusing this mix of function naming when it comes to =
XenStore and XenBus.

Again, grateful for your h=
elp.




Best,
Adrian

On Tue, Oct 23, 2012 at 3:00 PM, Samuel Thibault <samu=
el.thibault@ens-lyon.org> wrote:



Adrian Shaw, le Tue 23 Oct 2012 14:54:01 +01=
00, a =E9crit :


> Since you are the author of minios/lib/xs




Err, I'm not :)

I'm just the current de-facto maintainer.




> Is it not yet possible to do change the permission of a XenStore entry=
 from

> Mini-OS?




Apparently there is a xenbus_set_perms function.



Samuel





--0016e6d9a1533eb9fa04ccba7fd5--


--===============4505367713525666948==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4505367713525666948==--


From xen-devel-bounces@lists.xen.org Tue Oct 23 14:08:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 14:08:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQf9E-0001Dm-HI; Tue, 23 Oct 2012 14:08:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQf9D-0001Dh-9H
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 14:07:59 +0000
Received: from [85.158.139.211:50681] by server-11.bemta-5.messagelabs.com id
	AD/0F-14870-EB4A6805; Tue, 23 Oct 2012 14:07:58 +0000
X-Env-Sender: adrian.l.shaw@gmail.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1351001277!19434394!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6478 invoked from network); 23 Oct 2012 14:07:57 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 14:07:57 -0000
Received: by mail-we0-f173.google.com with SMTP id t11so2600753wey.32
	for ; Tue, 23 Oct 2012 07:07:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:content-type; bh=ml1FgbfMkd3MzVjdnxPpjpxHaKr3YuptJsagL5aCdVw=;
	b=ABuL1haXO2TNXVNDf4ezT5kxvxhiQKGw3QPHX9jiXzXOU1J3RfSDPn2iYMHDi9PrVG
	z8X1Tol/Zqok44ipAJ7DI/IFiiD9QeAoS0Nsbe7JiFzeej2OzM3IchOnoOB4X6BGNXBO
	AnWfdl4pxYNfuDZ+8Yon7X5Lcwbiw5XVe/3mdfcvSzHPzllscqKv7ZIGnDVQtp9c9CNV
	TaECRD1lsapCLVuTenD0g4p5dXUnJTQKcA/uDcZ9VFZqyfYJKTEL+InoiqQyjAFXcZZq
	Pt99nNWiywUI7gRrDOIsng6b6Y6E+95b44Q492j87ZIZgujC9DjuwuH323yGQlsvnFNU
	8sQQ==
Received: by 10.216.56.82 with SMTP id l60mr7140744wec.18.1351001277642; Tue,
	23 Oct 2012 07:07:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.100.4 with HTTP; Tue, 23 Oct 2012 07:07:37 -0700 (PDT)
In-Reply-To: <20121023140021.GR5914@type.bordeaux.inria.fr>
References: 
	<20121023134805.GP5914@type.bordeaux.inria.fr>
	
	<20121023140021.GR5914@type.bordeaux.inria.fr>
From: Adrian Shaw 
Date: Tue, 23 Oct 2012 15:07:37 +0100
Message-ID: 
To: Samuel Thibault ,
	Adrian Shaw , Xen-devel 
Subject: Re: [Xen-devel] Mini-OS transactions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============4505367713525666948=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4505367713525666948==
Content-Type: multipart/alternative; boundary=0016e6d9a1533eb9fa04ccba7fd5

--0016e6d9a1533eb9fa04ccba7fd5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Oops, bad assumption to make, sorry!
Many thanks for the pointer.
It's a bit confusing this mix of function naming when it comes to XenStore
and XenBus.

Again, grateful for your help.

Best,
Adrian

On Tue, Oct 23, 2012 at 3:00 PM, Samuel Thibault <
samuel.thibault@ens-lyon.org> wrote:

> Adrian Shaw, le Tue 23 Oct 2012 14:54:01 +0100, a =E9crit :
> > Since you are the author of minios/lib/xs
>
> Err, I'm not :)
> I'm just the current de-facto maintainer.
>
> > Is it not yet possible to do change the permission of a XenStore entry
> from
> > Mini-OS?
>
> Apparently there is a xenbus_set_perms function.
>
> Samuel
>

--0016e6d9a1533eb9fa04ccba7fd5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Oops, bad assumption to make, sorry!
Many thanks for the pointer.
=

It's a bit confusing this mix of function naming when it comes to =
XenStore and XenBus.

Again, grateful for your h=
elp.




Best,
Adrian

On Tue, Oct 23, 2012 at 3:00 PM, Samuel Thibault <samu=
el.thibault@ens-lyon.org> wrote:



Adrian Shaw, le Tue 23 Oct 2012 14:54:01 +01=
00, a =E9crit :


> Since you are the author of minios/lib/xs




Err, I'm not :)

I'm just the current de-facto maintainer.




> Is it not yet possible to do change the permission of a XenStore entry=
 from

> Mini-OS?




Apparently there is a xenbus_set_perms function.



Samuel





--0016e6d9a1533eb9fa04ccba7fd5--


--===============4505367713525666948==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4505367713525666948==--


From xen-devel-bounces@lists.xen.org Tue Oct 23 14:20:35 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 14:20:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQfL2-0001P0-V5; Tue, 23 Oct 2012 14:20:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQfL2-0001Ov-AO
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 14:20:12 +0000
Received: from [85.158.139.211:51077] by server-16.bemta-5.messagelabs.com id
	77/37-09196-B97A6805; Tue, 23 Oct 2012 14:20:11 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1351002009!21903823!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgyNzg1OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16095 invoked from network); 23 Oct 2012 14:20:10 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Oct 2012 14:20:10 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9NEK4r4019829
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 23 Oct 2012 14:20:05 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9NEK3m1025219
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 23 Oct 2012 14:20:04 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9NEK385014261; Tue, 23 Oct 2012 09:20:03 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 23 Oct 2012 07:20:02 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id ED46A403C7; Tue, 23 Oct 2012 10:07:53 -0400 (EDT)
Date: Tue, 23 Oct 2012 10:07:53 -0400
From: Konrad Rzeszutek Wilk 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	mukesh.rathor@oracle.com, Ian.Campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Message-ID: <20121023140753.GB14100@phenom.dumpdata.com>
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
	<1350695882-12820-2-git-send-email-konrad.wilk@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1350695882-12820-2-git-send-email-konrad.wilk@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: Re: [Xen-devel] [PATCH 1/6] xen/pvh: Support ParaVirtualized
	Hardware extensions.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> +/*
> + * Unmaps the page appearing at a particular GPFN from the specified guest's
> + * pseudophysical address space.
> + * arg == addr of xen_remove_from_physmap_t.
> + */
> +#define XENMEM_remove_from_physmap      15
> +struct xen_remove_from_physmap {
> +    /* Which domain to change the mapping for. */
> +    domid_t domid;
> +
> +    /* GPFN of the current mapping of the page. */
> +    xen_pfn_t gpfn;
> +};

I just realized that this a bit of unfortunate. We end up
with on 64-bit with this layout:

{
  0->1 [domid]
  2->7 [nothing]
  8->16 [gpfn]

}

which if one were to do a 32-bit build you would get:
{
 0->1 [domid]
 2->3 [nothing]
 4->7 [gpfn]
}
which means another compat layer in Xen.

So I think it makes sense to modify this to be 32 and 64-bit
clean, something like this:

{
	domid_t	domid;
	u8	pad[6];
	xen_pfn_t gpfn;
	/* xen_pfn_t under 32-bit x86 is 4 bytes, so extend it */
#ifdef CONFIG_X86_32
	__u8	pad1[4];
#endif
}

that way the structure is exactly the same size and the offsets
align.

Mukesh, you OK with that?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 14:20:35 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 14:20:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQfL2-0001P0-V5; Tue, 23 Oct 2012 14:20:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQfL2-0001Ov-AO
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 14:20:12 +0000
Received: from [85.158.139.211:51077] by server-16.bemta-5.messagelabs.com id
	77/37-09196-B97A6805; Tue, 23 Oct 2012 14:20:11 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1351002009!21903823!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgyNzg1OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16095 invoked from network); 23 Oct 2012 14:20:10 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Oct 2012 14:20:10 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9NEK4r4019829
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 23 Oct 2012 14:20:05 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9NEK3m1025219
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 23 Oct 2012 14:20:04 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9NEK385014261; Tue, 23 Oct 2012 09:20:03 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 23 Oct 2012 07:20:02 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id ED46A403C7; Tue, 23 Oct 2012 10:07:53 -0400 (EDT)
Date: Tue, 23 Oct 2012 10:07:53 -0400
From: Konrad Rzeszutek Wilk 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	mukesh.rathor@oracle.com, Ian.Campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Message-ID: <20121023140753.GB14100@phenom.dumpdata.com>
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
	<1350695882-12820-2-git-send-email-konrad.wilk@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1350695882-12820-2-git-send-email-konrad.wilk@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: Re: [Xen-devel] [PATCH 1/6] xen/pvh: Support ParaVirtualized
	Hardware extensions.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> +/*
> + * Unmaps the page appearing at a particular GPFN from the specified guest's
> + * pseudophysical address space.
> + * arg == addr of xen_remove_from_physmap_t.
> + */
> +#define XENMEM_remove_from_physmap      15
> +struct xen_remove_from_physmap {
> +    /* Which domain to change the mapping for. */
> +    domid_t domid;
> +
> +    /* GPFN of the current mapping of the page. */
> +    xen_pfn_t gpfn;
> +};

I just realized that this a bit of unfortunate. We end up
with on 64-bit with this layout:

{
  0->1 [domid]
  2->7 [nothing]
  8->16 [gpfn]

}

which if one were to do a 32-bit build you would get:
{
 0->1 [domid]
 2->3 [nothing]
 4->7 [gpfn]
}
which means another compat layer in Xen.

So I think it makes sense to modify this to be 32 and 64-bit
clean, something like this:

{
	domid_t	domid;
	u8	pad[6];
	xen_pfn_t gpfn;
	/* xen_pfn_t under 32-bit x86 is 4 bytes, so extend it */
#ifdef CONFIG_X86_32
	__u8	pad1[4];
#endif
}

that way the structure is exactly the same size and the offsets
align.

Mukesh, you OK with that?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 14:27:40 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 14:27:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQfRi-0001Xz-RO; Tue, 23 Oct 2012 14:27:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQf8r-0001DM-F6
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 14:07:37 +0000
Received: from [85.158.139.83:24077] by server-9.bemta-5.messagelabs.com id
	51/8F-23053-8A4A6805; Tue, 23 Oct 2012 14:07:36 +0000
X-Env-Sender: mrsanna1@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1351001254!33283636!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31726 invoked from network); 23 Oct 2012 14:07:35 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 14:07:35 -0000
Received: by mail-vb0-f45.google.com with SMTP id p1so5173142vbi.32
	for ; Tue, 23 Oct 2012 07:07:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=AFAhJWGMtfImzX28nFrmlP4M8RzwdDIv2xa3d1rUob8=;
	b=eDnDr0DBduhy8sl680Y4sRXe97IDaNRDCcCUB/h2oZCbpzLWGJAAtQtG5BOagClGvG
	c8wwFCT2rLLRCiBLiNR8iNhR9cutAh6jsOOr7zZhG5bJNnNt+oFNCrvDjhnyz6CY4eZ5
	Ok1why0dEconSfQKGzKmR+HK29rCK5dsnluITkuzozA51RtKiR11ljl0JIaS1p5IMrpU
	7qkSxT20ylYR3FP0qkBexD+Ag/wF9DMTmnCDl1Riom1cTgOl5GRs8Xf+cRBGzQbA/2E7
	iQks4Zwk5EWiOrxRpXIr+FQkalBhItD7SMnHpuX/o1dypKyCXnPo6G/R46Q1OBRi7gSS
	srag==
MIME-Version: 1.0
Received: by 10.52.65.51 with SMTP id u19mr16897444vds.3.1351001254007; Tue,
	23 Oct 2012 07:07:34 -0700 (PDT)
Received: by 10.58.207.75 with HTTP; Tue, 23 Oct 2012 07:07:32 -0700 (PDT)
In-Reply-To: <20121023115001.GA23471@localhost.localdomain>
References: 
	<508509D902000078000A2DDA@nat28.tlf.novell.com>
	
	<50852D8C02000078000A2E48@nat28.tlf.novell.com>
	
	<5085530202000078000A2F12@nat28.tlf.novell.com>
	
	<50866A2C02000078000A356D@nat28.tlf.novell.com>
	
	<5086766502000078000A35D4@nat28.tlf.novell.com>
	<20121023115001.GA23471@localhost.localdomain>
Date: Tue, 23 Oct 2012 16:07:32 +0200
Message-ID: 
From: Mauro 
To: Konrad Rzeszutek Wilk 
X-Mailman-Approved-At: Tue, 23 Oct 2012 14:27:06 +0000
Cc: xen-devel 
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 23 October 2012 13:50, Konrad Rzeszutek Wilk  wrote:
> On Tue, Oct 23, 2012 at 09:50:13AM +0100, Jan Beulich wrote:
>> >>> On 23.10.12 at 10:40, Mauro  wrote:
>> > On 23 October 2012 09:58, Jan Beulich  wrote:
>> >>>>> On 23.10.12 at 09:18, Mauro  wrote:
>> >>>>  A kernel run with no Xen underneath it.
>> >>>
>> >>> Here is:
>> >>>
>> >>> uname -a
>> >>> Linux xen-p02 2.6.32-5-amd64 #1 SMP Sun Sep 23 10:07:46 UTC 2012
>> >>> x86_64 GNU/Linux
>> >>
>> >> I'm sorry to say that, but 2.6.32 is nowhere close to "recent" (as
>> >> I had asked for).
>> >
>> > Sorry I'm using squeeze in production servers and I don't have a test
>> > machine on which install wheezy.
>>
>> And can't/don't want to install a self-built kernel?
>
> You could also boot one of those Live Image kernels. Like an Fedora or
> Ubuntu and just capture this. That way you don't over-write anything.

Ok, I'll try the live image.
Today I had another clock jump so cpuidle=0 doesn't work.
I'll stay using clocksource= pit and cpuidle =0 for a while to see if
they together work.
But...how to know what C states the kernel uses?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 14:27:40 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 14:27:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQfRi-0001Xz-RO; Tue, 23 Oct 2012 14:27:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQf8r-0001DM-F6
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 14:07:37 +0000
Received: from [85.158.139.83:24077] by server-9.bemta-5.messagelabs.com id
	51/8F-23053-8A4A6805; Tue, 23 Oct 2012 14:07:36 +0000
X-Env-Sender: mrsanna1@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1351001254!33283636!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31726 invoked from network); 23 Oct 2012 14:07:35 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 14:07:35 -0000
Received: by mail-vb0-f45.google.com with SMTP id p1so5173142vbi.32
	for ; Tue, 23 Oct 2012 07:07:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=AFAhJWGMtfImzX28nFrmlP4M8RzwdDIv2xa3d1rUob8=;
	b=eDnDr0DBduhy8sl680Y4sRXe97IDaNRDCcCUB/h2oZCbpzLWGJAAtQtG5BOagClGvG
	c8wwFCT2rLLRCiBLiNR8iNhR9cutAh6jsOOr7zZhG5bJNnNt+oFNCrvDjhnyz6CY4eZ5
	Ok1why0dEconSfQKGzKmR+HK29rCK5dsnluITkuzozA51RtKiR11ljl0JIaS1p5IMrpU
	7qkSxT20ylYR3FP0qkBexD+Ag/wF9DMTmnCDl1Riom1cTgOl5GRs8Xf+cRBGzQbA/2E7
	iQks4Zwk5EWiOrxRpXIr+FQkalBhItD7SMnHpuX/o1dypKyCXnPo6G/R46Q1OBRi7gSS
	srag==
MIME-Version: 1.0
Received: by 10.52.65.51 with SMTP id u19mr16897444vds.3.1351001254007; Tue,
	23 Oct 2012 07:07:34 -0700 (PDT)
Received: by 10.58.207.75 with HTTP; Tue, 23 Oct 2012 07:07:32 -0700 (PDT)
In-Reply-To: <20121023115001.GA23471@localhost.localdomain>
References: 
	<508509D902000078000A2DDA@nat28.tlf.novell.com>
	
	<50852D8C02000078000A2E48@nat28.tlf.novell.com>
	
	<5085530202000078000A2F12@nat28.tlf.novell.com>
	
	<50866A2C02000078000A356D@nat28.tlf.novell.com>
	
	<5086766502000078000A35D4@nat28.tlf.novell.com>
	<20121023115001.GA23471@localhost.localdomain>
Date: Tue, 23 Oct 2012 16:07:32 +0200
Message-ID: 
From: Mauro 
To: Konrad Rzeszutek Wilk 
X-Mailman-Approved-At: Tue, 23 Oct 2012 14:27:06 +0000
Cc: xen-devel 
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 23 October 2012 13:50, Konrad Rzeszutek Wilk  wrote:
> On Tue, Oct 23, 2012 at 09:50:13AM +0100, Jan Beulich wrote:
>> >>> On 23.10.12 at 10:40, Mauro  wrote:
>> > On 23 October 2012 09:58, Jan Beulich  wrote:
>> >>>>> On 23.10.12 at 09:18, Mauro  wrote:
>> >>>>  A kernel run with no Xen underneath it.
>> >>>
>> >>> Here is:
>> >>>
>> >>> uname -a
>> >>> Linux xen-p02 2.6.32-5-amd64 #1 SMP Sun Sep 23 10:07:46 UTC 2012
>> >>> x86_64 GNU/Linux
>> >>
>> >> I'm sorry to say that, but 2.6.32 is nowhere close to "recent" (as
>> >> I had asked for).
>> >
>> > Sorry I'm using squeeze in production servers and I don't have a test
>> > machine on which install wheezy.
>>
>> And can't/don't want to install a self-built kernel?
>
> You could also boot one of those Live Image kernels. Like an Fedora or
> Ubuntu and just capture this. That way you don't over-write anything.

Ok, I'll try the live image.
Today I had another clock jump so cpuidle=0 doesn't work.
I'll stay using clocksource= pit and cpuidle =0 for a while to see if
they together work.
But...how to know what C states the kernel uses?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 14:43:49 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 14:43:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQfhW-0001pP-Hd; Tue, 23 Oct 2012 14:43:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQfhU-0001pK-FI
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 14:43:24 +0000
Received: from [85.158.139.211:8090] by server-9.bemta-5.messagelabs.com id
	C1/8D-23053-B0DA6805; Tue, 23 Oct 2012 14:43:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1351003403!23450931!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 686 invoked from network); 23 Oct 2012 14:43:23 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-206.messagelabs.com with SMTP;
	23 Oct 2012 14:43:23 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 23 Oct 2012 15:43:23 +0100
Message-Id: <5086C92802000078000A3829@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 23 Oct 2012 15:43:20 +0100
From: "Jan Beulich" 
To: "Mauro" 
References: 
	<508509D902000078000A2DDA@nat28.tlf.novell.com>
	
	<50852D8C02000078000A2E48@nat28.tlf.novell.com>
	
	<5085530202000078000A2F12@nat28.tlf.novell.com>
	
	<50866A2C02000078000A356D@nat28.tlf.novell.com>
	
	<5086766502000078000A35D4@nat28.tlf.novell.com>
	<20121023115001.GA23471@localhost.localdomain>
	
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk ,
	xen-devel 
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 23.10.12 at 16:07, Mauro  wrote:
> On 23 October 2012 13:50, Konrad Rzeszutek Wilk  wrote:
>> On Tue, Oct 23, 2012 at 09:50:13AM +0100, Jan Beulich wrote:
>>> >>> On 23.10.12 at 10:40, Mauro  wrote:
>>> > On 23 October 2012 09:58, Jan Beulich  wrote:
>>> >>>>> On 23.10.12 at 09:18, Mauro  wrote:
>>> >>>>  A kernel run with no Xen underneath it.
>>> >>>
>>> >>> Here is:
>>> >>>
>>> >>> uname -a
>>> >>> Linux xen-p02 2.6.32-5-amd64 #1 SMP Sun Sep 23 10:07:46 UTC 2012
>>> >>> x86_64 GNU/Linux
>>> >>
>>> >> I'm sorry to say that, but 2.6.32 is nowhere close to "recent" (as
>>> >> I had asked for).
>>> >
>>> > Sorry I'm using squeeze in production servers and I don't have a test
>>> > machine on which install wheezy.
>>>
>>> And can't/don't want to install a self-built kernel?
>>
>> You could also boot one of those Live Image kernels. Like an Fedora or
>> Ubuntu and just capture this. That way you don't over-write anything.
> 
> Ok, I'll try the live image.
> Today I had another clock jump so cpuidle=0 doesn't work.
> I'll stay using clocksource= pit and cpuidle =0 for a while to see if
> they together work.
> But...how to know what C states the kernel uses?

If "cpuidle=0" alone doesn't work, your problem is not C-state
related, and you don't need to look up how much of it the native
kernel uses.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 14:43:49 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 14:43:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQfhW-0001pP-Hd; Tue, 23 Oct 2012 14:43:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQfhU-0001pK-FI
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 14:43:24 +0000
Received: from [85.158.139.211:8090] by server-9.bemta-5.messagelabs.com id
	C1/8D-23053-B0DA6805; Tue, 23 Oct 2012 14:43:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1351003403!23450931!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 686 invoked from network); 23 Oct 2012 14:43:23 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-206.messagelabs.com with SMTP;
	23 Oct 2012 14:43:23 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 23 Oct 2012 15:43:23 +0100
Message-Id: <5086C92802000078000A3829@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 23 Oct 2012 15:43:20 +0100
From: "Jan Beulich" 
To: "Mauro" 
References: 
	<508509D902000078000A2DDA@nat28.tlf.novell.com>
	
	<50852D8C02000078000A2E48@nat28.tlf.novell.com>
	
	<5085530202000078000A2F12@nat28.tlf.novell.com>
	
	<50866A2C02000078000A356D@nat28.tlf.novell.com>
	
	<5086766502000078000A35D4@nat28.tlf.novell.com>
	<20121023115001.GA23471@localhost.localdomain>
	
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk ,
	xen-devel 
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 23.10.12 at 16:07, Mauro  wrote:
> On 23 October 2012 13:50, Konrad Rzeszutek Wilk  wrote:
>> On Tue, Oct 23, 2012 at 09:50:13AM +0100, Jan Beulich wrote:
>>> >>> On 23.10.12 at 10:40, Mauro  wrote:
>>> > On 23 October 2012 09:58, Jan Beulich  wrote:
>>> >>>>> On 23.10.12 at 09:18, Mauro  wrote:
>>> >>>>  A kernel run with no Xen underneath it.
>>> >>>
>>> >>> Here is:
>>> >>>
>>> >>> uname -a
>>> >>> Linux xen-p02 2.6.32-5-amd64 #1 SMP Sun Sep 23 10:07:46 UTC 2012
>>> >>> x86_64 GNU/Linux
>>> >>
>>> >> I'm sorry to say that, but 2.6.32 is nowhere close to "recent" (as
>>> >> I had asked for).
>>> >
>>> > Sorry I'm using squeeze in production servers and I don't have a test
>>> > machine on which install wheezy.
>>>
>>> And can't/don't want to install a self-built kernel?
>>
>> You could also boot one of those Live Image kernels. Like an Fedora or
>> Ubuntu and just capture this. That way you don't over-write anything.
> 
> Ok, I'll try the live image.
> Today I had another clock jump so cpuidle=0 doesn't work.
> I'll stay using clocksource= pit and cpuidle =0 for a while to see if
> they together work.
> But...how to know what C states the kernel uses?

If "cpuidle=0" alone doesn't work, your problem is not C-state
related, and you don't need to look up how much of it the native
kernel uses.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 14:46:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 14:46:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQfjm-0001uW-2m; Tue, 23 Oct 2012 14:45:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQfjk-0001uO-Gf
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 14:45:44 +0000
Received: from [85.158.137.99:64426] by server-12.bemta-3.messagelabs.com id
	9E/BC-27853-79DA6805; Tue, 23 Oct 2012 14:45:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1351003542!19565167!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUyMjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32477 invoked from network); 23 Oct 2012 14:45:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 14:45:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,635,1344211200"; d="scan'208";a="15337632"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Oct 2012 14:45:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 23 Oct 2012 15:45:42 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TQfjh-0003od-VG;
	Tue, 23 Oct 2012 14:45:41 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TQfjh-0003lk-La;
	Tue, 23 Oct 2012 15:45:41 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Tue, 23 Oct 2012 15:45:41 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 14071: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14071 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14071/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops              4 kernel-build              fail REGR. vs. 13961
 build-amd64-pvops             4 kernel-build              fail REGR. vs. 13961

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 linux                9fc71703e9baa5b5174a72c053ae1ca736df2d42
baseline version:
 linux                40e6f9362555294cf1ce8abb1981b11d622e04d6

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             fail    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 9fc71703e9baa5b5174a72c053ae1ca736df2d42
Author: Greg Kroah-Hartman 
Date:   Mon Oct 22 08:36:19 2012 -0700

    Linux 3.0.48

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 14:46:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 14:46:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQfjm-0001uW-2m; Tue, 23 Oct 2012 14:45:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQfjk-0001uO-Gf
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 14:45:44 +0000
Received: from [85.158.137.99:64426] by server-12.bemta-3.messagelabs.com id
	9E/BC-27853-79DA6805; Tue, 23 Oct 2012 14:45:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1351003542!19565167!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUyMjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32477 invoked from network); 23 Oct 2012 14:45:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 14:45:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,635,1344211200"; d="scan'208";a="15337632"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Oct 2012 14:45:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 23 Oct 2012 15:45:42 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TQfjh-0003od-VG;
	Tue, 23 Oct 2012 14:45:41 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TQfjh-0003lk-La;
	Tue, 23 Oct 2012 15:45:41 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Tue, 23 Oct 2012 15:45:41 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 14071: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14071 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14071/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops              4 kernel-build              fail REGR. vs. 13961
 build-amd64-pvops             4 kernel-build              fail REGR. vs. 13961

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 linux                9fc71703e9baa5b5174a72c053ae1ca736df2d42
baseline version:
 linux                40e6f9362555294cf1ce8abb1981b11d622e04d6

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             fail    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 9fc71703e9baa5b5174a72c053ae1ca736df2d42
Author: Greg Kroah-Hartman 
Date:   Mon Oct 22 08:36:19 2012 -0700

    Linux 3.0.48

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 14:46:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 14:46:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQfkO-0001xS-Gf; Tue, 23 Oct 2012 14:46:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQfkN-0001xG-AM
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 14:46:23 +0000
Received: from [85.158.138.51:57800] by server-1.bemta-3.messagelabs.com id
	3D/75-31728-EBDA6805; Tue, 23 Oct 2012 14:46:22 +0000
X-Env-Sender: mrsanna1@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1351003578!16782015!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25042 invoked from network); 23 Oct 2012 14:46:21 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 14:46:21 -0000
Received: by mail-vc0-f173.google.com with SMTP id fl15so1543973vcb.32
	for ; Tue, 23 Oct 2012 07:46:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=Afb3n3YRHSrc8k6aSdEXgEWzT0EsXLDflGwilKr1PGQ=;
	b=D6BEyGMWmB2+tn0o9LhjBar6Be8gseGJLLDLulPuaHq9U6HrYTBo5hvRFcgjIc4JR1
	jYi+dBlctDr1xE72jbduzmreVhjoH5sdzZGO+o1xJlr2tsI3ku7MJx7zc5HlE1oLYj+P
	el4HLKkYd8LuXDxOUpsvMaeaez+rNShW0KD7KgPNOShUQfT2a4I/486jBhDrj1AxM0Zo
	Xi3HW7so260JI18Wg3ppavUokWT8DwuXTsSY3SdODNl5lOcBletSxB9PPM3gfZNvOmM+
	npyI2rej03OrxOhKC1OLTlYA24af+kvRJWvqcneyQUuHabuWxpicqF636BSWx3dcmmbh
	geVQ==
MIME-Version: 1.0
Received: by 10.52.65.51 with SMTP id u19mr17068682vds.3.1351003573437; Tue,
	23 Oct 2012 07:46:13 -0700 (PDT)
Received: by 10.58.207.75 with HTTP; Tue, 23 Oct 2012 07:46:13 -0700 (PDT)
In-Reply-To: <5086C92802000078000A3829@nat28.tlf.novell.com>
References: 
	<508509D902000078000A2DDA@nat28.tlf.novell.com>
	
	<50852D8C02000078000A2E48@nat28.tlf.novell.com>
	
	<5085530202000078000A2F12@nat28.tlf.novell.com>
	
	<50866A2C02000078000A356D@nat28.tlf.novell.com>
	
	<5086766502000078000A35D4@nat28.tlf.novell.com>
	<20121023115001.GA23471@localhost.localdomain>
	
	<5086C92802000078000A3829@nat28.tlf.novell.com>
Date: Tue, 23 Oct 2012 16:46:13 +0200
Message-ID: 
From: Mauro 
To: Jan Beulich 
Cc: xen-devel 
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 23 October 2012 16:43, Jan Beulich  wrote:
>>>> On 23.10.12 at 16:07, Mauro  wrote:
>> On 23 October 2012 13:50, Konrad Rzeszutek Wilk  wrote:
>>> On Tue, Oct 23, 2012 at 09:50:13AM +0100, Jan Beulich wrote:
>>>> >>> On 23.10.12 at 10:40, Mauro  wrote:
>>>> > On 23 October 2012 09:58, Jan Beulich  wrote:
>>>> >>>>> On 23.10.12 at 09:18, Mauro  wrote:
>>>> >>>>  A kernel run with no Xen underneath it.
>>>> >>>
>>>> >>> Here is:
>>>> >>>
>>>> >>> uname -a
>>>> >>> Linux xen-p02 2.6.32-5-amd64 #1 SMP Sun Sep 23 10:07:46 UTC 2012
>>>> >>> x86_64 GNU/Linux
>>>> >>
>>>> >> I'm sorry to say that, but 2.6.32 is nowhere close to "recent" (as
>>>> >> I had asked for).
>>>> >
>>>> > Sorry I'm using squeeze in production servers and I don't have a test
>>>> > machine on which install wheezy.
>>>>
>>>> And can't/don't want to install a self-built kernel?
>>>
>>> You could also boot one of those Live Image kernels. Like an Fedora or
>>> Ubuntu and just capture this. That way you don't over-write anything.
>>
>> Ok, I'll try the live image.
>> Today I had another clock jump so cpuidle=0 doesn't work.
>> I'll stay using clocksource= pit and cpuidle =0 for a while to see if
>> they together work.
>> But...how to know what C states the kernel uses?
>
> If "cpuidle=0" alone doesn't work, your problem is not C-state
> related, and you don't need to look up how much of it the native
> kernel uses.

Ok, cpuidle=0 however is to be used because also clocksource=pit alone
doesn't work.
Now I'll use both params and see what happens.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 14:46:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 14:46:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQfkO-0001xS-Gf; Tue, 23 Oct 2012 14:46:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQfkN-0001xG-AM
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 14:46:23 +0000
Received: from [85.158.138.51:57800] by server-1.bemta-3.messagelabs.com id
	3D/75-31728-EBDA6805; Tue, 23 Oct 2012 14:46:22 +0000
X-Env-Sender: mrsanna1@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1351003578!16782015!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25042 invoked from network); 23 Oct 2012 14:46:21 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 14:46:21 -0000
Received: by mail-vc0-f173.google.com with SMTP id fl15so1543973vcb.32
	for ; Tue, 23 Oct 2012 07:46:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=Afb3n3YRHSrc8k6aSdEXgEWzT0EsXLDflGwilKr1PGQ=;
	b=D6BEyGMWmB2+tn0o9LhjBar6Be8gseGJLLDLulPuaHq9U6HrYTBo5hvRFcgjIc4JR1
	jYi+dBlctDr1xE72jbduzmreVhjoH5sdzZGO+o1xJlr2tsI3ku7MJx7zc5HlE1oLYj+P
	el4HLKkYd8LuXDxOUpsvMaeaez+rNShW0KD7KgPNOShUQfT2a4I/486jBhDrj1AxM0Zo
	Xi3HW7so260JI18Wg3ppavUokWT8DwuXTsSY3SdODNl5lOcBletSxB9PPM3gfZNvOmM+
	npyI2rej03OrxOhKC1OLTlYA24af+kvRJWvqcneyQUuHabuWxpicqF636BSWx3dcmmbh
	geVQ==
MIME-Version: 1.0
Received: by 10.52.65.51 with SMTP id u19mr17068682vds.3.1351003573437; Tue,
	23 Oct 2012 07:46:13 -0700 (PDT)
Received: by 10.58.207.75 with HTTP; Tue, 23 Oct 2012 07:46:13 -0700 (PDT)
In-Reply-To: <5086C92802000078000A3829@nat28.tlf.novell.com>
References: 
	<508509D902000078000A2DDA@nat28.tlf.novell.com>
	
	<50852D8C02000078000A2E48@nat28.tlf.novell.com>
	
	<5085530202000078000A2F12@nat28.tlf.novell.com>
	
	<50866A2C02000078000A356D@nat28.tlf.novell.com>
	
	<5086766502000078000A35D4@nat28.tlf.novell.com>
	<20121023115001.GA23471@localhost.localdomain>
	
	<5086C92802000078000A3829@nat28.tlf.novell.com>
Date: Tue, 23 Oct 2012 16:46:13 +0200
Message-ID: 
From: Mauro 
To: Jan Beulich 
Cc: xen-devel 
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 23 October 2012 16:43, Jan Beulich  wrote:
>>>> On 23.10.12 at 16:07, Mauro  wrote:
>> On 23 October 2012 13:50, Konrad Rzeszutek Wilk  wrote:
>>> On Tue, Oct 23, 2012 at 09:50:13AM +0100, Jan Beulich wrote:
>>>> >>> On 23.10.12 at 10:40, Mauro  wrote:
>>>> > On 23 October 2012 09:58, Jan Beulich  wrote:
>>>> >>>>> On 23.10.12 at 09:18, Mauro  wrote:
>>>> >>>>  A kernel run with no Xen underneath it.
>>>> >>>
>>>> >>> Here is:
>>>> >>>
>>>> >>> uname -a
>>>> >>> Linux xen-p02 2.6.32-5-amd64 #1 SMP Sun Sep 23 10:07:46 UTC 2012
>>>> >>> x86_64 GNU/Linux
>>>> >>
>>>> >> I'm sorry to say that, but 2.6.32 is nowhere close to "recent" (as
>>>> >> I had asked for).
>>>> >
>>>> > Sorry I'm using squeeze in production servers and I don't have a test
>>>> > machine on which install wheezy.
>>>>
>>>> And can't/don't want to install a self-built kernel?
>>>
>>> You could also boot one of those Live Image kernels. Like an Fedora or
>>> Ubuntu and just capture this. That way you don't over-write anything.
>>
>> Ok, I'll try the live image.
>> Today I had another clock jump so cpuidle=0 doesn't work.
>> I'll stay using clocksource= pit and cpuidle =0 for a while to see if
>> they together work.
>> But...how to know what C states the kernel uses?
>
> If "cpuidle=0" alone doesn't work, your problem is not C-state
> related, and you don't need to look up how much of it the native
> kernel uses.

Ok, cpuidle=0 however is to be used because also clocksource=pit alone
doesn't work.
Now I'll use both params and see what happens.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 14:59:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 14:59:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQfw9-0002LT-6K; Tue, 23 Oct 2012 14:58:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQfw8-0002LO-2I
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 14:58:32 +0000
Received: from [85.158.138.51:16540] by server-4.bemta-3.messagelabs.com id
	B3/72-01405-790B6805; Tue, 23 Oct 2012 14:58:31 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1351004309!35465644!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgyNzg1OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3580 invoked from network); 23 Oct 2012 14:58:30 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Oct 2012 14:58:30 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9NEwONF026724
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 23 Oct 2012 14:58:25 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9NEwOu9001180
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 23 Oct 2012 14:58:24 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9NEwOfW023229; Tue, 23 Oct 2012 09:58:24 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 23 Oct 2012 07:58:23 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id EFAD8403C7; Tue, 23 Oct 2012 10:46:14 -0400 (EDT)
Date: Tue, 23 Oct 2012 10:46:14 -0400
From: Konrad Rzeszutek Wilk 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	mukesh.rathor@oracle.com, Ian.Campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Message-ID: <20121023144614.GC1052@phenom.dumpdata.com>
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
	<1350695882-12820-2-git-send-email-konrad.wilk@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1350695882-12820-2-git-send-email-konrad.wilk@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Subject: Re: [Xen-devel] [PATCH 1/6] xen/pvh: Support ParaVirtualized
	Hardware extensions.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
> index b66d04c..8beebdb 100644
> --- a/include/xen/interface/memory.h
> +++ b/include/xen/interface/memory.h
> @@ -169,7 +169,13 @@ struct xen_add_to_physmap {
>      /* Source mapping space. */
>  #define XENMAPSPACE_shared_info 0 /* shared info page */
>  #define XENMAPSPACE_grant_table 1 /* grant table page */
> -    unsigned int space;
> +#define XENMAPSPACE_gmfn        2 /* GMFN */
> +#define XENMAPSPACE_gmfn_range  3 /* GMFN range */
> +#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */
> +    uint16_t space;
> +    domid_t foreign_domid;         /* IFF XENMAPSPACE_gmfn_foreign */
> +
> +#define XENMAPIDX_grant_table_status 0x80000000
>  
>      /* Index into source mapping space. */
>      xen_ulong_t idx;

And this breaks 32-bit PVHVM :-(

The reason being that in xen_hvm_init_shared_info we allocate the
structure on the stack, and do not clear the foreign_domid to zero.

This means we can (and do get) for the argument space, something
like this:
	xatp.space == 0xffff0001;
instead of
	xatp.space = 0x1;

This fixes it:

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index e3497f2..b679f86 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1509,6 +1509,7 @@ void __ref xen_hvm_init_shared_info(void)
 	xatp.domid = DOMID_SELF;
 	xatp.idx = 0;
 	xatp.space = XENMAPSPACE_shared_info;
+	xatp.foreign_domid = 0;
 	xatp.gpfn = __pa(shared_info_page) >> PAGE_SHIFT;
 	if (HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp))
 		BUG();
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index b2b0a37..cbfd929 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -1044,6 +1044,7 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 		do {
 			xatp.domid = DOMID_SELF;
 			xatp.idx = i;
+			xatp.foreign_domid = 0;
 			xatp.space = XENMAPSPACE_grant_table;
 			xatp.gpfn = (xen_hvm_resume_frames >> PAGE_SHIFT) + i;
 			rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 14:59:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 14:59:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQfw9-0002LT-6K; Tue, 23 Oct 2012 14:58:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQfw8-0002LO-2I
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 14:58:32 +0000
Received: from [85.158.138.51:16540] by server-4.bemta-3.messagelabs.com id
	B3/72-01405-790B6805; Tue, 23 Oct 2012 14:58:31 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1351004309!35465644!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgyNzg1OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3580 invoked from network); 23 Oct 2012 14:58:30 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Oct 2012 14:58:30 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9NEwONF026724
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 23 Oct 2012 14:58:25 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9NEwOu9001180
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 23 Oct 2012 14:58:24 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9NEwOfW023229; Tue, 23 Oct 2012 09:58:24 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 23 Oct 2012 07:58:23 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id EFAD8403C7; Tue, 23 Oct 2012 10:46:14 -0400 (EDT)
Date: Tue, 23 Oct 2012 10:46:14 -0400
From: Konrad Rzeszutek Wilk 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	mukesh.rathor@oracle.com, Ian.Campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Message-ID: <20121023144614.GC1052@phenom.dumpdata.com>
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
	<1350695882-12820-2-git-send-email-konrad.wilk@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1350695882-12820-2-git-send-email-konrad.wilk@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Subject: Re: [Xen-devel] [PATCH 1/6] xen/pvh: Support ParaVirtualized
	Hardware extensions.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
> index b66d04c..8beebdb 100644
> --- a/include/xen/interface/memory.h
> +++ b/include/xen/interface/memory.h
> @@ -169,7 +169,13 @@ struct xen_add_to_physmap {
>      /* Source mapping space. */
>  #define XENMAPSPACE_shared_info 0 /* shared info page */
>  #define XENMAPSPACE_grant_table 1 /* grant table page */
> -    unsigned int space;
> +#define XENMAPSPACE_gmfn        2 /* GMFN */
> +#define XENMAPSPACE_gmfn_range  3 /* GMFN range */
> +#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */
> +    uint16_t space;
> +    domid_t foreign_domid;         /* IFF XENMAPSPACE_gmfn_foreign */
> +
> +#define XENMAPIDX_grant_table_status 0x80000000
>  
>      /* Index into source mapping space. */
>      xen_ulong_t idx;

And this breaks 32-bit PVHVM :-(

The reason being that in xen_hvm_init_shared_info we allocate the
structure on the stack, and do not clear the foreign_domid to zero.

This means we can (and do get) for the argument space, something
like this:
	xatp.space == 0xffff0001;
instead of
	xatp.space = 0x1;

This fixes it:

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index e3497f2..b679f86 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1509,6 +1509,7 @@ void __ref xen_hvm_init_shared_info(void)
 	xatp.domid = DOMID_SELF;
 	xatp.idx = 0;
 	xatp.space = XENMAPSPACE_shared_info;
+	xatp.foreign_domid = 0;
 	xatp.gpfn = __pa(shared_info_page) >> PAGE_SHIFT;
 	if (HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp))
 		BUG();
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index b2b0a37..cbfd929 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -1044,6 +1044,7 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 		do {
 			xatp.domid = DOMID_SELF;
 			xatp.idx = i;
+			xatp.foreign_domid = 0;
 			xatp.space = XENMAPSPACE_grant_table;
 			xatp.gpfn = (xen_hvm_resume_frames >> PAGE_SHIFT) + i;
 			rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 15:17:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 15:17:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQgDw-0002dC-28; Tue, 23 Oct 2012 15:16:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQgDv-0002d7-4q
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 15:16:55 +0000
Received: from [85.158.138.51:31121] by server-6.bemta-3.messagelabs.com id
	FB/45-32375-6E4B6805; Tue, 23 Oct 2012 15:16:54 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1351005410!35558815!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzg0MDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10779 invoked from network); 23 Oct 2012 15:16:52 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 15:16:52 -0000
X-IronPort-AV: E=Sophos;i="4.80,635,1344211200"; d="scan'208";a="42161244"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Oct 2012 15:16:49 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 23 Oct 2012 11:16:49 -0400
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[0.0.0.0])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TQgDo-0002Xj-TK;
	Tue, 23 Oct 2012 16:16:49 +0100
Message-ID: <5086B4DF.6060701@eu.citrix.com>
Date: Tue, 23 Oct 2012 16:16:47 +0100
From: George Dunlap 
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Dario Faggioli 
References: <1350999260.5064.56.camel@Solace>
In-Reply-To: <1350999260.5064.56.camel@Solace>
Cc: Keir Fraser , Jan Beulich ,
	xen-devel 
Subject: Re: [Xen-devel] About vcpu wakeup and runq tickling in credit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 23/10/12 14:34, Dario Faggioli wrote:
> Hi George, Everyone,
>
> While reworking a bit my NUMA aware scheduling patches I figured I'm not
> sure I understand what __runq_tickle() (in xen/common/sched_credit.c, of
> course) does.
>
> Here's the thing. Upon every vcpu wakeup we put the new vcpu in a runq
> and then call __runq_tickle(), passing the waking vcpu via 'new'. Let's
> call the vcpu that just woke up v_W, and the vcpu that is currently
> running on the cpu where that happens v_C. Let's also call the CPU where
> all is happening P.
>
> As far as I've understood, in  __runq_tickle(), we:
>
>
> static inline void
> __runq_tickle(unsigned int cpu, struct csched_vcpu *new)
> {
>      [...]
>      cpumask_t mask;
>
>      cpumask_clear(&mask);
>
>      /* If strictly higher priority than current VCPU, signal the CPU */
>      if ( new->pri > cur->pri )
>      {
>          [...]
>          cpumask_set_cpu(cpu, &mask);
>      }
>
> --> Make sure we put the CPU we are on (P) in 'mask', in case the woken
> --> vcpu (v_W) has higher priority that the currently running one (v_C).
>
>      /*
>       * If this CPU has at least two runnable VCPUs, we tickle any idlers to
>       * let them know there is runnable work in the system...
>       */
>      if ( cur->pri > CSCHED_PRI_IDLE )
>      {
>          if ( cpumask_empty(prv->idlers) )
>          [...]
>          else
>          {
>              cpumask_t idle_mask;
>
>              cpumask_and(&idle_mask, prv->idlers, new->vcpu->cpu_affinity);
>              if ( !cpumask_empty(&idle_mask) )
>              {
>                  [...]
>                  if ( opt_tickle_one_idle )
>                  {
>                      [...]
>                      cpumask_set_cpu(this_cpu(last_tickle_cpu), &mask);
>                  }
>                  else
>                      cpumask_or(&mask, &mask, &idle_mask);
>              }
>              cpumask_and(&mask, &mask, new->vcpu->cpu_affinity);
>
> --> Make sure we include one or more (depending on opt_tickle_one_idle)
> --> CPUs that are both idle and part of v_W's CPU-affinity in 'mask'.
>
>          }
>      }
>
>      /* Send scheduler interrupts to designated CPUs */
>      if ( !cpumask_empty(&mask) )
>          cpumask_raise_softirq(&mask, SCHEDULE_SOFTIRQ);
>
> --> Ask all the CPUs in 'mask' to reschedule. That would mean all the
> --> idlers from v_W's CPU-affinity and, possibly, "ourself" (P). The
> --> effect will be that all/some of the CPUs v_W's has affinity with
> --> _and_ (let's assume so) P will go through scheduling as quickly as
> --> possible.
>
> }
>
> Is the above right?

It looks right to me.

> If yes, here's my question. Is that right to always tickle v_W's affine
> CPUs and only them?
>
> I'm asking because a possible scenario, at least according to me, is
> that P schedules very quickly after this and, as prio(v_W)>prio(v_C), it
> selects v_W and leaves v_C in its runq. At that point, one of the
> tickled CPU (say P') enters schedule, sees that P is not idle, and tries
> to steal a vcpu from its runq. Now we know that P' has affinity with
> v_W, but v_W is not there, while v_C is, and if P' is not in its
> affinity, we've forced P' to reschedule for nothing.
> Also, there now might be another (or even a number of) CPU where v_C
> could run that stays idle, as it has not being tickled.

Yes -- the two clauses look a bit like they were conceived 
independently, and maybe no one thought about how they might interact.

> So, if that is true, it seems we leave some room for sub-optimal CPU
> utilization, as well as some non-work conserving windows.
> Of course, it is very hard to tell how frequent this actually happens.
>
> As it comes to possible solution, I think that, for instance, tickling
> all the CPUs in both v_W's and v_C's affinity masks could solve this,
> but that would also potentially increase the overhead (by asking _a_lot_
> of CPUs to reschedule), and again, it's hard to say if/when it's
> worth...

Well in my code, opt_tickle_idle_one is on by default, which means only 
one other cpu will be woken up.  If there were an easy way to make it 
wake up a CPU in v_C's affinity as well (supposing that there was no 
overlap), that would probably be a win.

Of course, that's only necessary if:
* v_C is lower priority than v_W
* There are no idlers that intersect both v_C and v_W's affinity mask.

It's probably a good idea though to try to set up a scenario where this 
might be an issue and see how often it actually happens.

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 15:17:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 15:17:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQgDw-0002dC-28; Tue, 23 Oct 2012 15:16:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQgDv-0002d7-4q
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 15:16:55 +0000
Received: from [85.158.138.51:31121] by server-6.bemta-3.messagelabs.com id
	FB/45-32375-6E4B6805; Tue, 23 Oct 2012 15:16:54 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1351005410!35558815!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzg0MDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10779 invoked from network); 23 Oct 2012 15:16:52 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 15:16:52 -0000
X-IronPort-AV: E=Sophos;i="4.80,635,1344211200"; d="scan'208";a="42161244"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Oct 2012 15:16:49 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 23 Oct 2012 11:16:49 -0400
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[0.0.0.0])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TQgDo-0002Xj-TK;
	Tue, 23 Oct 2012 16:16:49 +0100
Message-ID: <5086B4DF.6060701@eu.citrix.com>
Date: Tue, 23 Oct 2012 16:16:47 +0100
From: George Dunlap 
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Dario Faggioli 
References: <1350999260.5064.56.camel@Solace>
In-Reply-To: <1350999260.5064.56.camel@Solace>
Cc: Keir Fraser , Jan Beulich ,
	xen-devel 
Subject: Re: [Xen-devel] About vcpu wakeup and runq tickling in credit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 23/10/12 14:34, Dario Faggioli wrote:
> Hi George, Everyone,
>
> While reworking a bit my NUMA aware scheduling patches I figured I'm not
> sure I understand what __runq_tickle() (in xen/common/sched_credit.c, of
> course) does.
>
> Here's the thing. Upon every vcpu wakeup we put the new vcpu in a runq
> and then call __runq_tickle(), passing the waking vcpu via 'new'. Let's
> call the vcpu that just woke up v_W, and the vcpu that is currently
> running on the cpu where that happens v_C. Let's also call the CPU where
> all is happening P.
>
> As far as I've understood, in  __runq_tickle(), we:
>
>
> static inline void
> __runq_tickle(unsigned int cpu, struct csched_vcpu *new)
> {
>      [...]
>      cpumask_t mask;
>
>      cpumask_clear(&mask);
>
>      /* If strictly higher priority than current VCPU, signal the CPU */
>      if ( new->pri > cur->pri )
>      {
>          [...]
>          cpumask_set_cpu(cpu, &mask);
>      }
>
> --> Make sure we put the CPU we are on (P) in 'mask', in case the woken
> --> vcpu (v_W) has higher priority that the currently running one (v_C).
>
>      /*
>       * If this CPU has at least two runnable VCPUs, we tickle any idlers to
>       * let them know there is runnable work in the system...
>       */
>      if ( cur->pri > CSCHED_PRI_IDLE )
>      {
>          if ( cpumask_empty(prv->idlers) )
>          [...]
>          else
>          {
>              cpumask_t idle_mask;
>
>              cpumask_and(&idle_mask, prv->idlers, new->vcpu->cpu_affinity);
>              if ( !cpumask_empty(&idle_mask) )
>              {
>                  [...]
>                  if ( opt_tickle_one_idle )
>                  {
>                      [...]
>                      cpumask_set_cpu(this_cpu(last_tickle_cpu), &mask);
>                  }
>                  else
>                      cpumask_or(&mask, &mask, &idle_mask);
>              }
>              cpumask_and(&mask, &mask, new->vcpu->cpu_affinity);
>
> --> Make sure we include one or more (depending on opt_tickle_one_idle)
> --> CPUs that are both idle and part of v_W's CPU-affinity in 'mask'.
>
>          }
>      }
>
>      /* Send scheduler interrupts to designated CPUs */
>      if ( !cpumask_empty(&mask) )
>          cpumask_raise_softirq(&mask, SCHEDULE_SOFTIRQ);
>
> --> Ask all the CPUs in 'mask' to reschedule. That would mean all the
> --> idlers from v_W's CPU-affinity and, possibly, "ourself" (P). The
> --> effect will be that all/some of the CPUs v_W's has affinity with
> --> _and_ (let's assume so) P will go through scheduling as quickly as
> --> possible.
>
> }
>
> Is the above right?

It looks right to me.

> If yes, here's my question. Is that right to always tickle v_W's affine
> CPUs and only them?
>
> I'm asking because a possible scenario, at least according to me, is
> that P schedules very quickly after this and, as prio(v_W)>prio(v_C), it
> selects v_W and leaves v_C in its runq. At that point, one of the
> tickled CPU (say P') enters schedule, sees that P is not idle, and tries
> to steal a vcpu from its runq. Now we know that P' has affinity with
> v_W, but v_W is not there, while v_C is, and if P' is not in its
> affinity, we've forced P' to reschedule for nothing.
> Also, there now might be another (or even a number of) CPU where v_C
> could run that stays idle, as it has not being tickled.

Yes -- the two clauses look a bit like they were conceived 
independently, and maybe no one thought about how they might interact.

> So, if that is true, it seems we leave some room for sub-optimal CPU
> utilization, as well as some non-work conserving windows.
> Of course, it is very hard to tell how frequent this actually happens.
>
> As it comes to possible solution, I think that, for instance, tickling
> all the CPUs in both v_W's and v_C's affinity masks could solve this,
> but that would also potentially increase the overhead (by asking _a_lot_
> of CPUs to reschedule), and again, it's hard to say if/when it's
> worth...

Well in my code, opt_tickle_idle_one is on by default, which means only 
one other cpu will be woken up.  If there were an easy way to make it 
wake up a CPU in v_C's affinity as well (supposing that there was no 
overlap), that would probably be a win.

Of course, that's only necessary if:
* v_C is lower priority than v_W
* There are no idlers that intersect both v_C and v_W's affinity mask.

It's probably a good idea though to try to set up a scenario where this 
might be an issue and see how often it actually happens.

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 15:34:35 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 15:34:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQgUf-0002p8-NJ; Tue, 23 Oct 2012 15:34:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQgUe-0002p3-5d
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 15:34:12 +0000
Received: from [85.158.138.51:18097] by server-5.bemta-3.messagelabs.com id
	BC/35-12440-2F8B6805; Tue, 23 Oct 2012 15:34:10 +0000
X-Env-Sender: mrsanna1@gmail.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1351006446!35391887!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1142 invoked from network); 23 Oct 2012 15:34:08 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 15:34:08 -0000
Received: by mail-vb0-f45.google.com with SMTP id p1so5301372vbi.32
	for ; Tue, 23 Oct 2012 08:34:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=BrXtew5n8uST06ZeYLc/4GgwwqiZkFnywFaVMdC/jrg=;
	b=p/FMHPKSYP1EI568avF5Er8gGUQ05cm46OeuFT2C+e8kWhlei2qyQ3VCQfxCALqQ2L
	zobYaYpoG11TIQjX0klbFod52hPW4N2ygxpgrfK11nDcG4+UzcvZDm0lj7z5afSFRyYd
	EZc5EI2VsI41Z6lzUrQFOsxAmpqaeaVs5USK6K6cvVflnJdAby7bghg1WL9xcI4tmynb
	riceAPJjp1jU3HxJiDD85Ng2YtgNu/t7xR9gZhU5OAQVS+lnpSGfjL//polubQg7nEEm
	ueVmxhuKQKTkCyHkwQafrB474H2WczQ7NC19fojSLet/KkSxqSnjFkL1sznfo2yjx+qC
	oKzA==
MIME-Version: 1.0
Received: by 10.52.65.51 with SMTP id u19mr17294704vds.3.1351006444691; Tue,
	23 Oct 2012 08:34:04 -0700 (PDT)
Received: by 10.58.207.75 with HTTP; Tue, 23 Oct 2012 08:34:04 -0700 (PDT)
In-Reply-To: 
References: 
	<508509D902000078000A2DDA@nat28.tlf.novell.com>
	
	<50852D8C02000078000A2E48@nat28.tlf.novell.com>
	
	<5085530202000078000A2F12@nat28.tlf.novell.com>
	
	<50866A2C02000078000A356D@nat28.tlf.novell.com>
	
	<5086766502000078000A35D4@nat28.tlf.novell.com>
	<20121023115001.GA23471@localhost.localdomain>
	
	<5086C92802000078000A3829@nat28.tlf.novell.com>
	
Date: Tue, 23 Oct 2012 17:34:04 +0200
Message-ID: 
From: Mauro 
To: Jan Beulich 
Cc: xen-devel 
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 23 October 2012 16:46, Mauro  wrote:
> On 23 October 2012 16:43, Jan Beulich  wrote:
>>>>> On 23.10.12 at 16:07, Mauro  wrote:
>>> On 23 October 2012 13:50, Konrad Rzeszutek Wilk  wrote:
>>>> On Tue, Oct 23, 2012 at 09:50:13AM +0100, Jan Beulich wrote:
>>>>> >>> On 23.10.12 at 10:40, Mauro  wrote:
>>>>> > On 23 October 2012 09:58, Jan Beulich  wrote:
>>>>> >>>>> On 23.10.12 at 09:18, Mauro  wrote:
>>>>> >>>>  A kernel run with no Xen underneath it.
>>>>> >>>
>>>>> >>> Here is:
>>>>> >>>
>>>>> >>> uname -a
>>>>> >>> Linux xen-p02 2.6.32-5-amd64 #1 SMP Sun Sep 23 10:07:46 UTC 2012
>>>>> >>> x86_64 GNU/Linux
>>>>> >>
>>>>> >> I'm sorry to say that, but 2.6.32 is nowhere close to "recent" (as
>>>>> >> I had asked for).
>>>>> >
>>>>> > Sorry I'm using squeeze in production servers and I don't have a test
>>>>> > machine on which install wheezy.
>>>>>
>>>>> And can't/don't want to install a self-built kernel?
>>>>
>>>> You could also boot one of those Live Image kernels. Like an Fedora or
>>>> Ubuntu and just capture this. That way you don't over-write anything.
>>>
>>> Ok, I'll try the live image.
>>> Today I had another clock jump so cpuidle=0 doesn't work.
>>> I'll stay using clocksource= pit and cpuidle =0 for a while to see if
>>> they together work.
>>> But...how to know what C states the kernel uses?
>>
>> If "cpuidle=0" alone doesn't work, your problem is not C-state
>> related, and you don't need to look up how much of it the native
>> kernel uses.
>
> Ok, cpuidle=0 however is to be used because also clocksource=pit alone
> doesn't work.
> Now I'll use both params and see what happens.

Sorry for the noise, I'm not sure if it has been really a clock jump.
Retry using only cpuidle=0 and then what Jan has suggested.
If you want to see the C states tell me how to do.

p.s. sorry for bad english

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 15:34:35 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 15:34:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQgUf-0002p8-NJ; Tue, 23 Oct 2012 15:34:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQgUe-0002p3-5d
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 15:34:12 +0000
Received: from [85.158.138.51:18097] by server-5.bemta-3.messagelabs.com id
	BC/35-12440-2F8B6805; Tue, 23 Oct 2012 15:34:10 +0000
X-Env-Sender: mrsanna1@gmail.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1351006446!35391887!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1142 invoked from network); 23 Oct 2012 15:34:08 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 15:34:08 -0000
Received: by mail-vb0-f45.google.com with SMTP id p1so5301372vbi.32
	for ; Tue, 23 Oct 2012 08:34:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=BrXtew5n8uST06ZeYLc/4GgwwqiZkFnywFaVMdC/jrg=;
	b=p/FMHPKSYP1EI568avF5Er8gGUQ05cm46OeuFT2C+e8kWhlei2qyQ3VCQfxCALqQ2L
	zobYaYpoG11TIQjX0klbFod52hPW4N2ygxpgrfK11nDcG4+UzcvZDm0lj7z5afSFRyYd
	EZc5EI2VsI41Z6lzUrQFOsxAmpqaeaVs5USK6K6cvVflnJdAby7bghg1WL9xcI4tmynb
	riceAPJjp1jU3HxJiDD85Ng2YtgNu/t7xR9gZhU5OAQVS+lnpSGfjL//polubQg7nEEm
	ueVmxhuKQKTkCyHkwQafrB474H2WczQ7NC19fojSLet/KkSxqSnjFkL1sznfo2yjx+qC
	oKzA==
MIME-Version: 1.0
Received: by 10.52.65.51 with SMTP id u19mr17294704vds.3.1351006444691; Tue,
	23 Oct 2012 08:34:04 -0700 (PDT)
Received: by 10.58.207.75 with HTTP; Tue, 23 Oct 2012 08:34:04 -0700 (PDT)
In-Reply-To: 
References: 
	<508509D902000078000A2DDA@nat28.tlf.novell.com>
	
	<50852D8C02000078000A2E48@nat28.tlf.novell.com>
	
	<5085530202000078000A2F12@nat28.tlf.novell.com>
	
	<50866A2C02000078000A356D@nat28.tlf.novell.com>
	
	<5086766502000078000A35D4@nat28.tlf.novell.com>
	<20121023115001.GA23471@localhost.localdomain>
	
	<5086C92802000078000A3829@nat28.tlf.novell.com>
	
Date: Tue, 23 Oct 2012 17:34:04 +0200
Message-ID: 
From: Mauro 
To: Jan Beulich 
Cc: xen-devel 
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 23 October 2012 16:46, Mauro  wrote:
> On 23 October 2012 16:43, Jan Beulich  wrote:
>>>>> On 23.10.12 at 16:07, Mauro  wrote:
>>> On 23 October 2012 13:50, Konrad Rzeszutek Wilk  wrote:
>>>> On Tue, Oct 23, 2012 at 09:50:13AM +0100, Jan Beulich wrote:
>>>>> >>> On 23.10.12 at 10:40, Mauro  wrote:
>>>>> > On 23 October 2012 09:58, Jan Beulich  wrote:
>>>>> >>>>> On 23.10.12 at 09:18, Mauro  wrote:
>>>>> >>>>  A kernel run with no Xen underneath it.
>>>>> >>>
>>>>> >>> Here is:
>>>>> >>>
>>>>> >>> uname -a
>>>>> >>> Linux xen-p02 2.6.32-5-amd64 #1 SMP Sun Sep 23 10:07:46 UTC 2012
>>>>> >>> x86_64 GNU/Linux
>>>>> >>
>>>>> >> I'm sorry to say that, but 2.6.32 is nowhere close to "recent" (as
>>>>> >> I had asked for).
>>>>> >
>>>>> > Sorry I'm using squeeze in production servers and I don't have a test
>>>>> > machine on which install wheezy.
>>>>>
>>>>> And can't/don't want to install a self-built kernel?
>>>>
>>>> You could also boot one of those Live Image kernels. Like an Fedora or
>>>> Ubuntu and just capture this. That way you don't over-write anything.
>>>
>>> Ok, I'll try the live image.
>>> Today I had another clock jump so cpuidle=0 doesn't work.
>>> I'll stay using clocksource= pit and cpuidle =0 for a while to see if
>>> they together work.
>>> But...how to know what C states the kernel uses?
>>
>> If "cpuidle=0" alone doesn't work, your problem is not C-state
>> related, and you don't need to look up how much of it the native
>> kernel uses.
>
> Ok, cpuidle=0 however is to be used because also clocksource=pit alone
> doesn't work.
> Now I'll use both params and see what happens.

Sorry for the noise, I'm not sure if it has been really a clock jump.
Retry using only cpuidle=0 and then what Jan has suggested.
If you want to see the C states tell me how to do.

p.s. sorry for bad english

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 15:50:01 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 15:50:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQgjV-00031U-5z; Tue, 23 Oct 2012 15:49:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQgjT-00031P-91
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 15:49:31 +0000
Received: from [85.158.138.51:47611] by server-5.bemta-3.messagelabs.com id
	A5/7C-12440-A8CB6805; Tue, 23 Oct 2012 15:49:30 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1351007369!33704540!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7577 invoked from network); 23 Oct 2012 15:49:29 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-174.messagelabs.com with SMTP;
	23 Oct 2012 15:49:29 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 23 Oct 2012 16:49:30 +0100
Message-Id: <5086D8A402000078000A38B7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 23 Oct 2012 16:49:24 +0100
From: "Jan Beulich" 
To: "Mauro" 
References: 
	<508509D902000078000A2DDA@nat28.tlf.novell.com>
	
	<50852D8C02000078000A2E48@nat28.tlf.novell.com>
	
	<5085530202000078000A2F12@nat28.tlf.novell.com>
	
	<50866A2C02000078000A356D@nat28.tlf.novell.com>
	
	<5086766502000078000A35D4@nat28.tlf.novell.com>
	<20121023115001.GA23471@localhost.localdomain>
	
	<5086C92802000078000A3829@nat28.tlf.novell.com>
	
	
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel 
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 23.10.12 at 17:34, Mauro  wrote:
> On 23 October 2012 16:46, Mauro  wrote:
>> On 23 October 2012 16:43, Jan Beulich  wrote:
>>>>>> On 23.10.12 at 16:07, Mauro  wrote:
>>>> Today I had another clock jump so cpuidle=0 doesn't work.
>>>> I'll stay using clocksource= pit and cpuidle =0 for a while to see if
>>>> they together work.
>>>> But...how to know what C states the kernel uses?
>>>
>>> If "cpuidle=0" alone doesn't work, your problem is not C-state
>>> related, and you don't need to look up how much of it the native
>>> kernel uses.
>>
>> Ok, cpuidle=0 however is to be used because also clocksource=pit alone
>> doesn't work.
>> Now I'll use both params and see what happens.
> 
> Sorry for the noise, I'm not sure if it has been really a clock jump.
> Retry using only cpuidle=0 and then what Jan has suggested.
> If you want to see the C states tell me how to do.

Let's wait with that until you're settled on whether "cpuidle=0"
alone works.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 15:50:01 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 15:50:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQgjV-00031U-5z; Tue, 23 Oct 2012 15:49:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQgjT-00031P-91
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 15:49:31 +0000
Received: from [85.158.138.51:47611] by server-5.bemta-3.messagelabs.com id
	A5/7C-12440-A8CB6805; Tue, 23 Oct 2012 15:49:30 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1351007369!33704540!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7577 invoked from network); 23 Oct 2012 15:49:29 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-174.messagelabs.com with SMTP;
	23 Oct 2012 15:49:29 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 23 Oct 2012 16:49:30 +0100
Message-Id: <5086D8A402000078000A38B7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 23 Oct 2012 16:49:24 +0100
From: "Jan Beulich" 
To: "Mauro" 
References: 
	<508509D902000078000A2DDA@nat28.tlf.novell.com>
	
	<50852D8C02000078000A2E48@nat28.tlf.novell.com>
	
	<5085530202000078000A2F12@nat28.tlf.novell.com>
	
	<50866A2C02000078000A356D@nat28.tlf.novell.com>
	
	<5086766502000078000A35D4@nat28.tlf.novell.com>
	<20121023115001.GA23471@localhost.localdomain>
	
	<5086C92802000078000A3829@nat28.tlf.novell.com>
	
	
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel 
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 23.10.12 at 17:34, Mauro  wrote:
> On 23 October 2012 16:46, Mauro  wrote:
>> On 23 October 2012 16:43, Jan Beulich  wrote:
>>>>>> On 23.10.12 at 16:07, Mauro  wrote:
>>>> Today I had another clock jump so cpuidle=0 doesn't work.
>>>> I'll stay using clocksource= pit and cpuidle =0 for a while to see if
>>>> they together work.
>>>> But...how to know what C states the kernel uses?
>>>
>>> If "cpuidle=0" alone doesn't work, your problem is not C-state
>>> related, and you don't need to look up how much of it the native
>>> kernel uses.
>>
>> Ok, cpuidle=0 however is to be used because also clocksource=pit alone
>> doesn't work.
>> Now I'll use both params and see what happens.
> 
> Sorry for the noise, I'm not sure if it has been really a clock jump.
> Retry using only cpuidle=0 and then what Jan has suggested.
> If you want to see the C states tell me how to do.

Let's wait with that until you're settled on whether "cpuidle=0"
alone works.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 16:02:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 16:02:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQgva-0003a6-EK; Tue, 23 Oct 2012 16:02:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQgvY-0003a1-OM
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 16:02:00 +0000
Received: from [85.158.143.99:63904] by server-3.bemta-4.messagelabs.com id
	86/6D-03544-77FB6805; Tue, 23 Oct 2012 16:01:59 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1351008113!34907303!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODQzOTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28734 invoked from network); 23 Oct 2012 16:01:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 16:01:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,635,1344211200"; d="scan'208";a="212193175"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Oct 2012 16:01:25 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 23 Oct 2012 12:01:24 -0400
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[0.0.0.0])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TQguy-0003AR-7D;
	Tue, 23 Oct 2012 17:01:24 +0100
Message-ID: <5086BF52.30501@eu.citrix.com>
Date: Tue, 23 Oct 2012 17:01:22 +0100
From: George Dunlap 
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Dario Faggioli 
References: 
	
In-Reply-To: 
Cc: Paul Durrant , "Keir \(Xen.org\)" ,
	Jan Beulich ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 1 of 6] xen: fix build when 'perfc=y'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMjIvMTAvMTIgMTU6NDAsIERhcmlvIEZhZ2dpb2xpIHdyb3RlOgo+IFdoaWNoIHdhcyBmYWls
aW5nIHdpdGggdGhpczoKPgo+ICAgdmlyaWRpYW4uYzogSW4gZnVuY3Rpb24g4oCYd3Jtc3Jfdmly
aWRpYW5fcmVnc+KAmToKPiAgIHZpcmlkaWFuLmM6MjU0OjE6IGVycm9yOiDigJhQRVJGQ19tc2h2
X3dybXNyX2FwaWNfbXNy4oCZIHVuZGVjbGFyZWQgKGZpcnN0IHVzZSBpbiB0aGlzIGZ1bmN0aW9u
KQo+ICAgdmlyaWRpYW4uYzoyNTQ6MTogbm90ZTogZWFjaCB1bmRlY2xhcmVkIGlkZW50aWZpZXIg
aXMgcmVwb3J0ZWQgb25seSBvbmNlIGZvciBlYWNoIGZ1bmN0aW9uIGl0IGFwcGVhcnMgaW4KPiAg
IHZpcmlkaWFuLmM6IEluIGZ1bmN0aW9uIOKAmHJkbXNyX3ZpcmlkaWFuX3JlZ3PigJk6Cj4gICB2
aXJpZGlhbi5jOjMwNToxOiBlcnJvcjog4oCYUEVSRkNfbXNodl9yZG1zcl9hcGljX21zcuKAmSB1
bmRlY2xhcmVkIChmaXJzdCB1c2UgaW4gdGhpcyBmdW5jdGlvbikKPgo+IGFzIGEgY29uc2VxdWVu
Y2Ugb2YgMTdiNzU0Y2FiN2IwIHVzaW5nIGJ1dCBub3QgZGVmaW5pbmcKPiB0aGUgY291bnRlcnMu
Cj4KPiBTaWduZWQtb2ZmLWJ5OiBEYXJpbyBGYWdnaW9saSA8ZGFyaW8uZmFnZ2lvbGlAY2l0cml4
LmNvbT4KCkFja2VkLWJ5OiBHZW9yZ2UgRHVubGFwIDxnZW9yZ2UuZHVubGFwQGV1LmNpdHJpeC5j
b20+CgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVu
LWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMu
eGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Oct 23 16:02:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 16:02:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQgva-0003a6-EK; Tue, 23 Oct 2012 16:02:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQgvY-0003a1-OM
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 16:02:00 +0000
Received: from [85.158.143.99:63904] by server-3.bemta-4.messagelabs.com id
	86/6D-03544-77FB6805; Tue, 23 Oct 2012 16:01:59 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1351008113!34907303!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODQzOTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28734 invoked from network); 23 Oct 2012 16:01:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 16:01:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,635,1344211200"; d="scan'208";a="212193175"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Oct 2012 16:01:25 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 23 Oct 2012 12:01:24 -0400
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[0.0.0.0])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TQguy-0003AR-7D;
	Tue, 23 Oct 2012 17:01:24 +0100
Message-ID: <5086BF52.30501@eu.citrix.com>
Date: Tue, 23 Oct 2012 17:01:22 +0100
From: George Dunlap 
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Dario Faggioli 
References: 
	
In-Reply-To: 
Cc: Paul Durrant , "Keir \(Xen.org\)" ,
	Jan Beulich ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 1 of 6] xen: fix build when 'perfc=y'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMjIvMTAvMTIgMTU6NDAsIERhcmlvIEZhZ2dpb2xpIHdyb3RlOgo+IFdoaWNoIHdhcyBmYWls
aW5nIHdpdGggdGhpczoKPgo+ICAgdmlyaWRpYW4uYzogSW4gZnVuY3Rpb24g4oCYd3Jtc3Jfdmly
aWRpYW5fcmVnc+KAmToKPiAgIHZpcmlkaWFuLmM6MjU0OjE6IGVycm9yOiDigJhQRVJGQ19tc2h2
X3dybXNyX2FwaWNfbXNy4oCZIHVuZGVjbGFyZWQgKGZpcnN0IHVzZSBpbiB0aGlzIGZ1bmN0aW9u
KQo+ICAgdmlyaWRpYW4uYzoyNTQ6MTogbm90ZTogZWFjaCB1bmRlY2xhcmVkIGlkZW50aWZpZXIg
aXMgcmVwb3J0ZWQgb25seSBvbmNlIGZvciBlYWNoIGZ1bmN0aW9uIGl0IGFwcGVhcnMgaW4KPiAg
IHZpcmlkaWFuLmM6IEluIGZ1bmN0aW9uIOKAmHJkbXNyX3ZpcmlkaWFuX3JlZ3PigJk6Cj4gICB2
aXJpZGlhbi5jOjMwNToxOiBlcnJvcjog4oCYUEVSRkNfbXNodl9yZG1zcl9hcGljX21zcuKAmSB1
bmRlY2xhcmVkIChmaXJzdCB1c2UgaW4gdGhpcyBmdW5jdGlvbikKPgo+IGFzIGEgY29uc2VxdWVu
Y2Ugb2YgMTdiNzU0Y2FiN2IwIHVzaW5nIGJ1dCBub3QgZGVmaW5pbmcKPiB0aGUgY291bnRlcnMu
Cj4KPiBTaWduZWQtb2ZmLWJ5OiBEYXJpbyBGYWdnaW9saSA8ZGFyaW8uZmFnZ2lvbGlAY2l0cml4
LmNvbT4KCkFja2VkLWJ5OiBHZW9yZ2UgRHVubGFwIDxnZW9yZ2UuZHVubGFwQGV1LmNpdHJpeC5j
b20+CgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVu
LWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMu
eGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Oct 23 16:05:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 16:05:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQgyO-0003k8-5K; Tue, 23 Oct 2012 16:04:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQgyM-0003jx-IP
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 16:04:54 +0000
Received: from [193.109.254.147:20928] by server-13.bemta-14.messagelabs.com
	id 38/E2-21440-520C6805; Tue, 23 Oct 2012 16:04:53 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1351008292!4605661!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODQzOTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9343 invoked from network); 23 Oct 2012 16:04:53 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 16:04:53 -0000
X-IronPort-AV: E=Sophos;i="4.80,635,1344211200"; d="scan'208";a="212193778"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Oct 2012 16:04:51 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 23 Oct 2012 12:04:51 -0400
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[0.0.0.0])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TQgyI-0003DN-WD;
	Tue, 23 Oct 2012 17:04:51 +0100
Message-ID: <5086C022.3070702@eu.citrix.com>
Date: Tue, 23 Oct 2012 17:04:50 +0100
From: George Dunlap 
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Dario Faggioli 
References: 
	
In-Reply-To: 
Cc: Paul Durrant , "Keir \(Xen.org\)" ,
	Jan Beulich ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 2 of 6] xen: move `printk("Initializing
 domain")` from credit to generic scheduling code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 22/10/12 15:40, Dario Faggioli wrote:
> As, if it makes sense to let people know about it, it probably always does.
>
> Signed-off-by: Dario Faggioli 

The difference is, credit2 is explicity "experimental"; it's not 
unexpected to have a bunch of chatty debug messages when random things 
happen.  I don't think we want to print this on production systems 
running credit1.

Maybe change it to "KERN_DEBUG"?

  -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 16:05:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 16:05:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQgyO-0003k8-5K; Tue, 23 Oct 2012 16:04:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQgyM-0003jx-IP
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 16:04:54 +0000
Received: from [193.109.254.147:20928] by server-13.bemta-14.messagelabs.com
	id 38/E2-21440-520C6805; Tue, 23 Oct 2012 16:04:53 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1351008292!4605661!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODQzOTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9343 invoked from network); 23 Oct 2012 16:04:53 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 16:04:53 -0000
X-IronPort-AV: E=Sophos;i="4.80,635,1344211200"; d="scan'208";a="212193778"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Oct 2012 16:04:51 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 23 Oct 2012 12:04:51 -0400
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[0.0.0.0])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TQgyI-0003DN-WD;
	Tue, 23 Oct 2012 17:04:51 +0100
Message-ID: <5086C022.3070702@eu.citrix.com>
Date: Tue, 23 Oct 2012 17:04:50 +0100
From: George Dunlap 
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Dario Faggioli 
References: 
	
In-Reply-To: 
Cc: Paul Durrant , "Keir \(Xen.org\)" ,
	Jan Beulich ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 2 of 6] xen: move `printk("Initializing
 domain")` from credit to generic scheduling code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 22/10/12 15:40, Dario Faggioli wrote:
> As, if it makes sense to let people know about it, it probably always does.
>
> Signed-off-by: Dario Faggioli 

The difference is, credit2 is explicity "experimental"; it's not 
unexpected to have a bunch of chatty debug messages when random things 
happen.  I don't think we want to print this on production systems 
running credit1.

Maybe change it to "KERN_DEBUG"?

  -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 16:08:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 16:08:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQh14-0003v6-PP; Tue, 23 Oct 2012 16:07:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQh12-0003uv-Ej
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 16:07:40 +0000
Received: from [85.158.139.211:63278] by server-8.bemta-5.messagelabs.com id
	DE/14-23193-BC0C6805; Tue, 23 Oct 2012 16:07:39 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1351008458!19452231!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUyMjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24754 invoked from network); 23 Oct 2012 16:07:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 16:07:38 -0000
X-IronPort-AV: E=Sophos;i="4.80,635,1344211200"; d="scan'208";a="15339822"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Oct 2012 16:07:38 +0000
Received: from [192.168.1.30] (10.31.3.234) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 23 Oct 2012 17:07:37 +0100
Message-ID: <5086C0C8.5000306@citrix.com>
Date: Tue, 23 Oct 2012 18:07:36 +0200
From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk 
References: <1350559321-19066-1-git-send-email-roger.pau@citrix.com>
	<20121022134708.GA13832@konrad-lan.dumpdata.com>
In-Reply-To: <20121022134708.GA13832@konrad-lan.dumpdata.com>
Cc: "konrad.wilk@oracle.com" ,
	"linux-kernel@vger.kernel.org" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH RFC] Persistent grant maps for xen blk
	drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 22/10/12 15:47, Konrad Rzeszutek Wilk wrote:
> On Thu, Oct 18, 2012 at 01:22:01PM +0200, Roger Pau Monne wrote:
>> This patch implements persistent grants for the xen-blk{front,back}
>> mechanism. The effect of this change is to reduce the number of unmap
>> operations performed, since they cause a (costly) TLB shootdown. This
>> allows the I/O performance to scale better when a large number of VMs
>> are performing I/O.
>>
>> Previously, the blkfront driver was supplied a bvec[] from the request
>> queue. This was granted to dom0; dom0 performed the I/O and wrote
>> directly into the grant-mapped memory and unmapped it; blkfront then
>> removed foreign access for that grant. The cost of unmapping scales
>> badly with the number of CPUs in Dom0. An experiment showed that when
>> Dom0 has 24 VCPUs, and guests are performing parallel I/O to a
>> ramdisk, the IPIs from performing unmap's is a bottleneck at 5 guests
>> (at which point 650,000 IOPS are being performed in total). If more
>> than 5 guests are used, the performance declines. By 10 guests, only
>> 400,000 IOPS are being performed.
>>
>> This patch improves performance by only unmapping when the connection
>> between blkfront and back is broken.
>>
>> On startup blkfront notifies blkback that it is using persistent
>> grants, and blkback will do the same. If blkback is not capable of
>> persistent mapping, blkfront will still use the same grants, since it
>> is compatible with the previous protocol, and simplifies the code
>> complexity in blkfront.
>>
>> To perform a read, in persistent mode, blkfront uses a separate pool
>> of pages that it maps to dom0. When a request comes in, blkfront
>> transmutes the request so that blkback will write into one of these
>> free pages. Blkback keeps note of which grefs it has already
>> mapped. When a new ring request comes to blkback, it looks to see if
>> it has already mapped that page. If so, it will not map it again. If
>> the page hasn't been previously mapped, it is mapped now, and a record
>> is kept of this mapping. Blkback proceeds as usual. When blkfront is
>> notified that blkback has completed a request, it memcpy's from the
>> shared memory, into the bvec supplied. A record that the {gref, page}
>> tuple is mapped, and not inflight is kept.
>>
>> Writes are similar, except that the memcpy is peformed from the
>> supplied bvecs, into the shared pages, before the request is put onto
>> the ring.
>>
>> Blkback stores a mapping of grefs=>{page mapped to by gref} in
>> a red-black tree. As the grefs are not known apriori, and provide no
>> guarantees on their ordering, we have to perform a search
>> through this tree to find the page, for every gref we receive. This
>> operation takes O(log n) time in the worst case.
> 
> Might want to mention how blkfront stores it as well. It looks
> to be using 'llist' instead of 'list'? Any particular reason?

Since we are just pushing and poping grant references, I went for what I
think is the simplest one, a single linked list (list is a doubly linked
list). Oliver in the previous version was using something similar, but
custom made. I think it's best to use the data structures provided by
the kernel itself.

> 
>>
>> The maximum number of grants that blkback will persistenly map is
>> currently set to RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, to
>> prevent a malicios guest from attempting a DoS, by supplying fresh
>> grefs, causing the Dom0 kernel to map excessively. If a guest
>> is using persistent grants and exceeds the maximum number of grants to
>> map persistenly the newly passed grefs will be mapped and unmaped.
>> Using this approach, we can have requests that mix persistent and
>> non-persistent grants, and we need to handle them correctly.
>> This allows us to set the maximum number of persistent grants to a
>> lower value than RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, although
>> setting it will lead to unpredictable performance.
>>
>> In writing this patch, the question arrises as to if the additional
>> cost of performing memcpys in the guest (to/from the pool of granted
>> pages) outweigh the gains of not performing TLB shootdowns. The answer
>> to that question is `no'. There appears to be very little, if any
>> additional cost to the guest of using persistent grants. There is
>> perhaps a small saving, from the reduced number of hypercalls
>> performed in granting, and ending foreign access.
>>
>> Signed-off-by: Oliver Chick 
>> Signed-off-by: Roger Pau Monne 
>> Cc: 
>> Cc: 
>> ---
>> Benchmarks showing the impact of this patch in blk performance can be
>> found at:
>>
>> http://xenbits.xensource.com/people/royger/persistent_grants/
>> ---
>>  drivers/block/xen-blkback/blkback.c |  279 +++++++++++++++++++++++++++++++---
>>  drivers/block/xen-blkback/common.h  |   17 ++
>>  drivers/block/xen-blkback/xenbus.c  |   16 ++-
>>  drivers/block/xen-blkfront.c        |  183 ++++++++++++++++++++----
>>  4 files changed, 442 insertions(+), 53 deletions(-)
>>
>> diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
>> index c6decb9..2b982b2 100644
>> --- a/drivers/block/xen-blkback/blkback.c
>> +++ b/drivers/block/xen-blkback/blkback.c
>> @@ -78,6 +78,7 @@ struct pending_req {
>>       unsigned short          operation;
>>       int                     status;
>>       struct list_head        free_list;
>> +     unsigned int            unmap_seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
>>  };
>>
>>  #define BLKBACK_INVALID_HANDLE (~0)
>> @@ -98,6 +99,30 @@ struct xen_blkbk {
>>  static struct xen_blkbk *blkbk;
>>
>>  /*
>> + * Maximum number of grant pages that can be mapped in blkback.
>> + * BLKIF_MAX_SEGMENTS_PER_REQUEST * RING_SIZE is the maximum number of
>> + * pages that blkback will persistently map.
>> + */
>> +static inline unsigned int max_mapped_grant_pages(enum blkif_protocol protocol)
>> +{
>> +     switch (protocol) {
>> +     case BLKIF_PROTOCOL_NATIVE:
>> +             return __CONST_RING_SIZE(blkif, PAGE_SIZE) *
>> +                        BLKIF_MAX_SEGMENTS_PER_REQUEST;
>> +     case BLKIF_PROTOCOL_X86_32:
>> +             return __CONST_RING_SIZE(blkif_x86_32, PAGE_SIZE) *
>> +                        BLKIF_MAX_SEGMENTS_PER_REQUEST;
>> +     case BLKIF_PROTOCOL_X86_64:
>> +             return __CONST_RING_SIZE(blkif_x86_64, PAGE_SIZE) *
>> +                        BLKIF_MAX_SEGMENTS_PER_REQUEST;
> 
> Could you include in the comments what the size (bytes) you expect it to be?
> If that would require you re-doing some tests - then don't worry - but
> I figured you have some notes scribbled away that have the exact values
> down.

As far as I know and remember (I've checked the ring size in the past),
all ring types have a size of 32, BLKIF_MAX_SEGMENTS_PER_REQUEST is
always 11, and sizeof(struct persistent_gnt) is 48, so that's 32 * 11 *
48 = 16896 bytes. I will add a comment with this calculation.

> 
>> +     default:
>> +             BUG();
>> +     }
>> +     return 0;
>> +}
>> +
>> +
>> +/*
>>   * Little helpful macro to figure out the index and virtual address of the
>>   * pending_pages[..]. For each 'pending_req' we have have up to
>>   * BLKIF_MAX_SEGMENTS_PER_REQUEST (11) pages. The seg would be from 0 through
>> @@ -128,6 +153,57 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>>  static void make_response(struct xen_blkif *blkif, u64 id,
>>                         unsigned short op, int st);
>>
>> +#define foreach_grant(pos, rbtree, node) \
>> +     for ((pos) = container_of(rb_first((rbtree)), typeof(*(pos)), node); \
>> +          &(pos)->node != NULL; \
>> +          (pos) = container_of(rb_next(&(pos)->node), typeof(*(pos)), node))
>> +
>> +
>> +static void add_persistent_gnt(struct rb_root *root,
>> +                            struct persistent_gnt *persistent_gnt)
>> +{
>> +     struct rb_node **new = &(root->rb_node), *parent = NULL;
>> +     struct persistent_gnt *this;
>> +
>> +     /* Figure out where to put new node */
>> +     while (*new) {
>> +             this = container_of(*new, struct persistent_gnt, node);
>> +
>> +             parent = *new;
>> +             if (persistent_gnt->gnt < this->gnt)
>> +                     new = &((*new)->rb_left);
>> +             else if (persistent_gnt->gnt > this->gnt)
>> +                     new = &((*new)->rb_right);
>> +             else {
>> +                     pr_alert(DRV_PFX " trying to add a gref that's already in the tree\n");
>> +                     BUG();
>> +             }
>> +     }
>> +
>> +     /* Add new node and rebalance tree. */
>> +     rb_link_node(&(persistent_gnt->node), parent, new);
>> +     rb_insert_color(&(persistent_gnt->node), root);
>> +}
>> +
>> +static struct persistent_gnt *get_persistent_gnt(struct rb_root *root,
>> +                                              grant_ref_t gref)
>> +{
>> +     struct persistent_gnt *data;
>> +     struct rb_node *node = root->rb_node;
>> +
>> +     while (node) {
>> +             data = container_of(node, struct persistent_gnt, node);
>> +
>> +             if (gref < data->gnt)
>> +                     node = node->rb_left;
>> +             else if (gref > data->gnt)
>> +                     node = node->rb_right;
>> +             else
>> +                     return data;
>> +     }
>> +     return NULL;
>> +}
>> +
>>  /*
>>   * Retrieve from the 'pending_reqs' a free pending_req structure to be used.
>>   */
>> @@ -274,6 +350,11 @@ int xen_blkif_schedule(void *arg)
>>  {
>>       struct xen_blkif *blkif = arg;
>>       struct xen_vbd *vbd = &blkif->vbd;
>> +     struct gnttab_unmap_grant_ref unmap[BLKIF_MAX_SEGMENTS_PER_REQUEST];
>> +     struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
>> +     struct persistent_gnt *persistent_gnt;
>> +     int ret = 0;
>> +     int segs_to_unmap = 0;
>>
>>       xen_blkif_get(blkif);
>>
>> @@ -301,6 +382,32 @@ int xen_blkif_schedule(void *arg)
>>                       print_stats(blkif);
>>       }
>>
>> +     /* Free all persistent grant pages */
>> +     foreach_grant(persistent_gnt, &blkif->persistent_gnts, node) {
> 
> Just for sanity - you did check this with blkfronts that did not have
> persistent grants enabled, right?

Yes, it doesn't crash, but looking at foreach_grant it seems like it
should. I've added a check before trying to iterate over the tree.

> 
>> +             BUG_ON(persistent_gnt->handle == BLKBACK_INVALID_HANDLE);
>> +             gnttab_set_unmap_op(&unmap[segs_to_unmap],
>> +                 (unsigned long) pfn_to_kaddr(page_to_pfn(
>> +                     persistent_gnt->page)),
>> +                 GNTMAP_host_map,
>> +                 persistent_gnt->handle);
>> +
>> +             pages[segs_to_unmap] = persistent_gnt->page;
>> +             rb_erase(&persistent_gnt->node, &blkif->persistent_gnts);
>> +             kfree(persistent_gnt);
>> +             blkif->persistent_gnt_c--;
>> +
>> +             if (++segs_to_unmap == BLKIF_MAX_SEGMENTS_PER_REQUEST ||
>> +                     !rb_next(&persistent_gnt->node)) {
>> +                     ret = gnttab_unmap_refs(unmap, NULL, pages,
>> +                                             segs_to_unmap);
>> +                     BUG_ON(ret);
>> +                     segs_to_unmap = 0;
>> +             }
>> +     }
>> +
>> +     BUG_ON(blkif->persistent_gnt_c != 0);
>> +     BUG_ON(!RB_EMPTY_ROOT(&blkif->persistent_gnts));
>> +
>>       if (log_stats)
>>               print_stats(blkif);
>>
>> @@ -327,6 +434,8 @@ static void xen_blkbk_unmap(struct pending_req *req)
>>       int ret;
>>
>>       for (i = 0; i < req->nr_pages; i++) {
>> +             if (!req->unmap_seg[i])
>> +                     continue;
> 
> Perhaps there should be a #define for that array..

Do you mean something like:

#define unmap(req, i) req->unmap_seg[i]

>>               handle = pending_handle(req, i);
>>               if (handle == BLKBACK_INVALID_HANDLE)
>>                       continue;
>> @@ -343,12 +452,26 @@ static void xen_blkbk_unmap(struct pending_req *req)
>>
>>  static int xen_blkbk_map(struct blkif_request *req,
>>                        struct pending_req *pending_req,
>> -                      struct seg_buf seg[])
>> +                      struct seg_buf seg[],
>> +                      struct page *pages[])
>>  {
>>       struct gnttab_map_grant_ref map[BLKIF_MAX_SEGMENTS_PER_REQUEST];
>> -     int i;
>> +     struct persistent_gnt *persistent_gnts[BLKIF_MAX_SEGMENTS_PER_REQUEST];
>> +     struct page *pages_to_gnt[BLKIF_MAX_SEGMENTS_PER_REQUEST];
>> +     struct persistent_gnt *persistent_gnt = NULL;
>> +     struct xen_blkif *blkif = pending_req->blkif;
>> +     phys_addr_t addr = 0;
>> +     int i, j;
>> +     int new_map;
> 
> Just use a bool for this.

Done

>>       int nseg = req->u.rw.nr_segments;
>> +     int segs_to_map = 0;
>>       int ret = 0;
>> +     int use_persistent_gnts;
>> +
>> +     use_persistent_gnts = (blkif->vbd.feature_gnt_persistent);
>> +
>> +     BUG_ON(blkif->persistent_gnt_c >
>> +                max_mapped_grant_pages(pending_req->blkif->blk_protocol));
>>
>>       /*
>>        * Fill out preq.nr_sects with proper amount of sectors, and setup
>> @@ -358,36 +481,141 @@ static int xen_blkbk_map(struct blkif_request *req,
>>       for (i = 0; i < nseg; i++) {
>>               uint32_t flags;
>>
>> -             flags = GNTMAP_host_map;
>> -             if (pending_req->operation != BLKIF_OP_READ)
>> -                     flags |= GNTMAP_readonly;
>> -             gnttab_set_map_op(&map[i], vaddr(pending_req, i), flags,
>> -                               req->u.rw.seg[i].gref,
>> -                               pending_req->blkif->domid);
>> +             if (use_persistent_gnts)
>> +                     persistent_gnt = get_persistent_gnt(
>> +                             &blkif->persistent_gnts,
>> +                             req->u.rw.seg[i].gref);
>> +
>> +             if (persistent_gnt) {
>> +                     /*
>> +                      * We are using persistent grants and
>> +                      * the grant is already mapped
>> +                      */
>> +                     new_map = 0;
>> +             } else if (use_persistent_gnts &&
>> +                        blkif->persistent_gnt_c <
>> +                        max_mapped_grant_pages(blkif->blk_protocol)) {
>> +                     /*
>> +                      * We are using persistent grants, the grant is
>> +                      * not mapped but we have room for it
>> +                      */
>> +                     new_map = 1;
>> +                     persistent_gnt = kzalloc(
>> +                             sizeof(struct persistent_gnt),
>> +                             GFP_KERNEL);
>> +                     if (!persistent_gnt)
>> +                             return -ENOMEM;
>> +                     persistent_gnt->page = alloc_page(GFP_KERNEL);
>> +                     if (!persistent_gnt->page) {
>> +                             kfree(persistent_gnt);
>> +                             return -ENOMEM;
>> +                     }
>> +                     persistent_gnt->gnt = req->u.rw.seg[i].gref;
>> +
>> +                     pages_to_gnt[segs_to_map] =
>> +                             persistent_gnt->page;
>> +                     addr = (unsigned long) pfn_to_kaddr(
>> +                             page_to_pfn(persistent_gnt->page));
>> +
>> +                     add_persistent_gnt(&blkif->persistent_gnts,
>> +                             persistent_gnt);
>> +                     blkif->persistent_gnt_c++;
>> +                     pr_debug(DRV_PFX " grant %u added to the tree of persistent grants, using %u/%u\n",
>> +                              persistent_gnt->gnt, blkif->persistent_gnt_c,
>> +                              max_mapped_grant_pages(blkif->blk_protocol));
>> +             } else {
>> +                     /*
>> +                      * We are either using persistent grants and
>> +                      * hit the maximum limit of grants mapped,
>> +                      * or we are not using persistent grants.
>> +                      */
>> +                     if (use_persistent_gnts &&
>> +                             !blkif->vbd.overflow_max_grants) {
>> +                             blkif->vbd.overflow_max_grants = 1;
>> +                             pr_alert(DRV_PFX " domain %u, device %#x is using maximum number of persistent grants\n",
>> +                                      blkif->domid, blkif->vbd.handle);
>> +                     }
>> +                     new_map = 1;
>> +                     pages[i] = blkbk->pending_page(pending_req, i);
>> +                     addr = vaddr(pending_req, i);
>> +                     pages_to_gnt[segs_to_map] =
>> +                             blkbk->pending_page(pending_req, i);
>> +             }
>> +
>> +             if (persistent_gnt) {
>> +                     pages[i] = persistent_gnt->page;
>> +                     persistent_gnts[i] = persistent_gnt;
>> +             } else {
>> +                     persistent_gnts[i] = NULL;
>> +             }
>> +
>> +             if (new_map) {
>> +                     flags = GNTMAP_host_map;
>> +                     if (!persistent_gnt &&
>> +                         (pending_req->operation != BLKIF_OP_READ))
>> +                             flags |= GNTMAP_readonly;
>> +                     gnttab_set_map_op(&map[segs_to_map++], addr,
>> +                                       flags, req->u.rw.seg[i].gref,
>> +                                       blkif->domid);
>> +             }
>>       }
>>
>> -     ret = gnttab_map_refs(map, NULL, &blkbk->pending_page(pending_req, 0), nseg);
>> -     BUG_ON(ret);
>> +     if (segs_to_map) {
>> +             ret = gnttab_map_refs(map, NULL, pages_to_gnt, segs_to_map);
>> +             BUG_ON(ret);
>> +     }
>>
>>       /*
>>        * Now swizzle the MFN in our domain with the MFN from the other domain
>>        * so that when we access vaddr(pending_req,i) it has the contents of
>>        * the page from the other domain.
>>        */
>> -     for (i = 0; i < nseg; i++) {
>> -             if (unlikely(map[i].status != 0)) {
>> -                     pr_debug(DRV_PFX "invalid buffer -- could not remap it\n");
>> -                     map[i].handle = BLKBACK_INVALID_HANDLE;
>> -                     ret |= 1;
>> +     for (i = 0, j = 0; i < nseg; i++) {
>> +             if (!persistent_gnts[i] || !persistent_gnts[i]->handle) {
>> +                     /* This is a newly mapped grant */
>> +                     BUG_ON(j >= segs_to_map);
>> +                     if (unlikely(map[j].status != 0)) {
> 
> I am not seeing j being incremented anywhere? Should it?

Yes, it should be incremented, but not here. See the comment below to
see what I've changed.

> 
>> +                             pr_debug(DRV_PFX "invalid buffer -- could not remap it\n");
>> +                             map[j].handle = BLKBACK_INVALID_HANDLE;
>> +                             ret |= 1;
>> +                             if (persistent_gnts[i]) {
>> +                                     rb_erase(&persistent_gnts[i]->node,
>> +                                              &blkif->persistent_gnts);
>> +                                     blkif->persistent_gnt_c--;
>> +                                     kfree(persistent_gnts[i]);
>> +                                     persistent_gnts[i] = NULL;
>> +                             }
>> +                     }
>> +             }
>> +             if (persistent_gnts[i]) {
>> +                     if (!persistent_gnts[i]->handle) {
>> +                             /*
>> +                              * If this is a new persistent grant
>> +                              * save the handler
>> +                              */
>> +                             persistent_gnts[i]->handle = map[j].handle;
>> +                             persistent_gnts[i]->dev_bus_addr =
>> +                                     map[j++].dev_bus_addr;
>> +                     }
>> +                     pending_handle(pending_req, i) =
>> +                             persistent_gnts[i]->handle;
>> +                     pending_req->unmap_seg[i] = 0;
> 
> Could we have a #define for that?

Sure.

>> +
>> +                     if (ret)
>> +                             continue;

This should be

if (ret) {
	j++;
	continue;
}

>> +
>> +                     seg[i].buf = persistent_gnts[i]->dev_bus_addr |
>> +                             (req->u.rw.seg[i].first_sect << 9);
>> +             } else {
>> +                     pending_handle(pending_req, i) = map[j].handle;
>> +                     pending_req->unmap_seg[i] = 1;
> 
> And here as well?

Done.

>> +
>> +                     if (ret)
>> +                             continue;
>> +
>> +                     seg[i].buf = map[j++].dev_bus_addr |
>> +                             (req->u.rw.seg[i].first_sect << 9);
>>               }
>> -
>> -             pending_handle(pending_req, i) = map[i].handle;
>> -
>> -             if (ret)
>> -                     continue;
>> -
>> -             seg[i].buf  = map[i].dev_bus_addr |
>> -                     (req->u.rw.seg[i].first_sect << 9);
>>       }
>>       return ret;
>>  }
>> @@ -590,6 +818,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>>       int operation;
>>       struct blk_plug plug;
>>       bool drain = false;
>> +     struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
>>
>>       switch (req->operation) {
>>       case BLKIF_OP_READ:
>> @@ -676,7 +905,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>>        * the hypercall to unmap the grants - that is all done in
>>        * xen_blkbk_unmap.
>>        */
>> -     if (xen_blkbk_map(req, pending_req, seg))
>> +     if (xen_blkbk_map(req, pending_req, seg, pages))
>>               goto fail_flush;
>>
>>       /*
>> @@ -688,7 +917,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>>       for (i = 0; i < nseg; i++) {
>>               while ((bio == NULL) ||
>>                      (bio_add_page(bio,
>> -                                  blkbk->pending_page(pending_req, i),
>> +                                  pages[i],
>>                                    seg[i].nsec << 9,
>>                                    seg[i].buf & ~PAGE_MASK) == 0)) {
>>
>> diff --git a/drivers/block/xen-blkback/common.h b/drivers/block/xen-blkback/common.h
>> index 9ad3b5e..6c08ee9 100644
>> --- a/drivers/block/xen-blkback/common.h
>> +++ b/drivers/block/xen-blkback/common.h
>> @@ -34,6 +34,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -160,10 +161,22 @@ struct xen_vbd {
>>       sector_t                size;
>>       bool                    flush_support;
>>       bool                    discard_secure;
>> +
>> +     unsigned int            feature_gnt_persistent:1;
>> +     unsigned int            overflow_max_grants:1;
> 
> I think the v3.7-rc1 has this structure changed just a tiny bit, so you
> might want to rebase it on top of that.

I've done the rebase on top of your linux-next branch, commit
ad502612c173fff239250c9fe9bdfaaef70b9901.

> 
>>  };
>>
>>  struct backend_info;
>>
>> +
>> +struct persistent_gnt {
>> +     struct page *page;
>> +     grant_ref_t gnt;
>> +     grant_handle_t handle;
>> +     uint64_t dev_bus_addr;
>> +     struct rb_node node;
>> +};
>> +
>>  struct xen_blkif {
>>       /* Unique identifier for this interface. */
>>       domid_t                 domid;
>> @@ -190,6 +203,10 @@ struct xen_blkif {
>>       struct task_struct      *xenblkd;
>>       unsigned int            waiting_reqs;
>>
>> +     /* frontend feature information */
> 
> Huh?

Changed it to:

/* tree to store persistent grants */

>> +     struct rb_root          persistent_gnts;
>> +     unsigned int            persistent_gnt_c;
>> +
>>       /* statistics */
>>       unsigned long           st_print;
>>       int                     st_rd_req;
>> diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c
>> index 4f66171..9f88b4e 100644
>> --- a/drivers/block/xen-blkback/xenbus.c
>> +++ b/drivers/block/xen-blkback/xenbus.c
>> @@ -118,6 +118,7 @@ static struct xen_blkif *xen_blkif_alloc(domid_t domid)
>>       atomic_set(&blkif->drain, 0);
>>       blkif->st_print = jiffies;
>>       init_waitqueue_head(&blkif->waiting_to_free);
>> +     blkif->persistent_gnts.rb_node = NULL;
>>
>>       return blkif;
>>  }
>> @@ -721,6 +722,7 @@ static int connect_ring(struct backend_info *be)
>>       struct xenbus_device *dev = be->dev;
>>       unsigned long ring_ref;
>>       unsigned int evtchn;
>> +     unsigned int pers_grants;
>>       char protocol[64] = "";
>>       int err;
>>
>> @@ -750,8 +752,18 @@ static int connect_ring(struct backend_info *be)
>>               xenbus_dev_fatal(dev, err, "unknown fe protocol %s", protocol);
>>               return -1;
>>       }
>> -     pr_info(DRV_PFX "ring-ref %ld, event-channel %d, protocol %d (%s)\n",
>> -             ring_ref, evtchn, be->blkif->blk_protocol, protocol);
>> +     err = xenbus_gather(XBT_NIL, dev->otherend,
>> +                         "feature-persistent-grants", "%u",
>> +                         &pers_grants, NULL);
>> +     if (err)
>> +             pers_grants = 0;
>> +
>> +     be->blkif->vbd.feature_gnt_persistent = pers_grants;
>> +     be->blkif->vbd.overflow_max_grants = 0;
>> +
>> +     pr_info(DRV_PFX "ring-ref %ld, event-channel %d, protocol %d (%s) persistent %d\n",
>> +             ring_ref, evtchn, be->blkif->blk_protocol, protocol,
>> +             pers_grants);
> 
> Can you make that a string? So it is
>  pers_grants ? "persistent grants" : ""
> 
> instead of a zero of one value pls?

Yes, done.

>>
>>       /* Map the shared frame, irq etc. */
>>       err = xen_blkif_map(be->blkif, ring_ref, evtchn);
>> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
>> index 2c2d2e5..206d422 100644
>> --- a/drivers/block/xen-blkfront.c
>> +++ b/drivers/block/xen-blkfront.c
>> @@ -44,6 +44,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>
>>  #include 
>>  #include 
>> @@ -64,10 +65,17 @@ enum blkif_state {
>>       BLKIF_STATE_SUSPENDED,
>>  };
>>
>> +struct grant {
>> +     grant_ref_t gref;
>> +     unsigned long pfn;
>> +     struct llist_node node;
>> +};
>> +
>>  struct blk_shadow {
>>       struct blkif_request req;
>>       struct request *request;
>>       unsigned long frame[BLKIF_MAX_SEGMENTS_PER_REQUEST];
>> +     struct grant *grants_used[BLKIF_MAX_SEGMENTS_PER_REQUEST];
>>  };
>>
>>  static DEFINE_MUTEX(blkfront_mutex);
>> @@ -97,6 +105,8 @@ struct blkfront_info
>>       struct work_struct work;
>>       struct gnttab_free_callback callback;
>>       struct blk_shadow shadow[BLK_RING_SIZE];
>> +     struct llist_head persistent_gnts;
>> +     unsigned int persistent_gnts_c;
>>       unsigned long shadow_free;
>>       unsigned int feature_flush;
>>       unsigned int flush_op;
>> @@ -287,21 +297,36 @@ static int blkif_queue_request(struct request *req)
>>       unsigned long id;
>>       unsigned int fsect, lsect;
>>       int i, ref;
>> +
>> +     /*
>> +      * Used to store if we are able to queue the request by just using
>> +      * existing persistent grants (0), or if we have to get new grants,
> 
> What does the zero mean?

Frankly, no idea, I guess it was in Oliver's patch and I missed to spot it.

>> +      * as there are not sufficiently many free.
>> +      */
>> +     int new_persistent_gnts;
> 
> I think this can be a bool?

I agree.

>>       grant_ref_t gref_head;
>> +     struct page *granted_page;
>> +     struct grant *gnt_list_entry = NULL;
>>       struct scatterlist *sg;
>>
>>       if (unlikely(info->connected != BLKIF_STATE_CONNECTED))
>>               return 1;
>>
>> -     if (gnttab_alloc_grant_references(
>> -             BLKIF_MAX_SEGMENTS_PER_REQUEST, &gref_head) < 0) {
>> -             gnttab_request_free_callback(
>> -                     &info->callback,
>> -                     blkif_restart_queue_callback,
>> -                     info,
>> -                     BLKIF_MAX_SEGMENTS_PER_REQUEST);
>> -             return 1;
>> -     }
>> +     /* Check if we have enought grants to allocate a requests */
>> +     if (info->persistent_gnts_c < BLKIF_MAX_SEGMENTS_PER_REQUEST) {
>> +             new_persistent_gnts = 1;
>> +             if (gnttab_alloc_grant_references(
>> +                 BLKIF_MAX_SEGMENTS_PER_REQUEST - info->persistent_gnts_c,
>> +                 &gref_head) < 0) {
>> +                     gnttab_request_free_callback(
>> +                             &info->callback,
>> +                             blkif_restart_queue_callback,
>> +                             info,
>> +                             BLKIF_MAX_SEGMENTS_PER_REQUEST);
>> +                     return 1;
>> +             }
>> +     } else
>> +             new_persistent_gnts = 0;
>>
>>       /* Fill out a communications ring structure. */
>>       ring_req = RING_GET_REQUEST(&info->ring, info->ring.req_prod_pvt);
>> @@ -341,18 +366,73 @@ static int blkif_queue_request(struct request *req)
>>                      BLKIF_MAX_SEGMENTS_PER_REQUEST);
>>
>>               for_each_sg(info->sg, sg, ring_req->u.rw.nr_segments, i) {
>> -                     buffer_mfn = pfn_to_mfn(page_to_pfn(sg_page(sg)));
>>                       fsect = sg->offset >> 9;
>>                       lsect = fsect + (sg->length >> 9) - 1;
>> -                     /* install a grant reference. */
>> -                     ref = gnttab_claim_grant_reference(&gref_head);
>> -                     BUG_ON(ref == -ENOSPC);
>>
>> -                     gnttab_grant_foreign_access_ref(
>> -                                     ref,
>> +                     if (info->persistent_gnts_c) {
>> +                             BUG_ON(llist_empty(&info->persistent_gnts));
>> +                             gnt_list_entry = llist_entry(
>> +                                     llist_del_first(&info->persistent_gnts),
>> +                                     struct grant, node);
>> +
>> +                             ref = gnt_list_entry->gref;
>> +                             buffer_mfn = pfn_to_mfn(gnt_list_entry->pfn);
>> +                             info->persistent_gnts_c--;
>> +                     } else {
>> +                             ref = gnttab_claim_grant_reference(&gref_head);
>> +                             BUG_ON(ref == -ENOSPC);
>> +
>> +                             gnt_list_entry =
>> +                                     kmalloc(sizeof(struct grant),
>> +                                                      GFP_ATOMIC);
>> +                             if (!gnt_list_entry)
>> +                                     return -ENOMEM;
>> +
>> +                             granted_page = alloc_page(GFP_ATOMIC);
>> +                             if (!granted_page) {
>> +                                     kfree(gnt_list_entry);
>> +                                     return -ENOMEM;
>> +                             }
>> +
>> +                             gnt_list_entry->pfn =
>> +                                     page_to_pfn(granted_page);
>> +                             gnt_list_entry->gref = ref;
>> +
>> +                             buffer_mfn = pfn_to_mfn(page_to_pfn(
>> +                                                             granted_page));
>> +                             gnttab_grant_foreign_access_ref(ref,
>>                                       info->xbdev->otherend_id,
>> -                                     buffer_mfn,
>> -                                     rq_data_dir(req));
>> +                                     buffer_mfn, 0);
>> +                     }
>> +
>> +                     info->shadow[id].grants_used[i] = gnt_list_entry;
>> +
>> +                     if (rq_data_dir(req)) {
>> +                             char *bvec_data;
>> +                             void *shared_data;
>> +
>> +                             BUG_ON(sg->offset + sg->length > PAGE_SIZE);
>> +
>> +                             shared_data = kmap_atomic(
>> +                                     pfn_to_page(gnt_list_entry->pfn));
>> +                             bvec_data = kmap_atomic(sg_page(sg));
>> +
>> +                             /*
>> +                              * this does not wipe data stored outside the
>> +                              * range sg->offset..sg->offset+sg->length.
>> +                              * Therefore, blkback *could* see data from
>> +                              * previous requests. This is OK as long as
>> +                              * persistent grants are shared with just one
>> +                              * domain. It may need refactoring if This
> .. this (lowercase it pls)

Done.

> 
>> +                              * changes
>> +                              */
>> +                             memcpy(shared_data + sg->offset,
>> +                                    bvec_data   + sg->offset,
>> +                                    sg->length);
>> +
>> +                             kunmap_atomic(bvec_data);
>> +                             kunmap_atomic(shared_data);
>> +                     }
>>
>>                       info->shadow[id].frame[i] = mfn_to_pfn(buffer_mfn);
>>                       ring_req->u.rw.seg[i] =
>> @@ -368,7 +448,8 @@ static int blkif_queue_request(struct request *req)
>>       /* Keep a private copy so we can reissue requests when recovering. */
>>       info->shadow[id].req = *ring_req;
>>
>> -     gnttab_free_grant_references(gref_head);
>> +     if (new_persistent_gnts)
>> +             gnttab_free_grant_references(gref_head);
>>
>>       return 0;
>>  }
>> @@ -480,7 +561,7 @@ static int xlvbd_init_blk_queue(struct gendisk *gd, u16 sector_size)
>>  static void xlvbd_flush(struct blkfront_info *info)
>>  {
>>       blk_queue_flush(info->rq, info->feature_flush);
>> -     printk(KERN_INFO "blkfront: %s: %s: %s\n",
>> +     printk(KERN_INFO "blkfront: %s: %s: %s, using persistent grants\n",
> 
> HA! By default, eh?

Yes, you caught me, there's a paragraph in the commit message that
explains that we are using persistent grants in the frontend
unconditionally, since the protocol is compatible (you can have a
persistent blkfront and a non-persistent blkback). It simplifies the
logic in blkfront. Are you OK with it?

>>              info->gd->disk_name,
>>              info->flush_op == BLKIF_OP_WRITE_BARRIER ?
>>               "barrier" : (info->flush_op == BLKIF_OP_FLUSH_DISKCACHE ?
>> @@ -707,6 +788,9 @@ static void blkif_restart_queue(struct work_struct *work)
>>
>>  static void blkif_free(struct blkfront_info *info, int suspend)
>>  {
>> +     struct llist_node *all_gnts;
>> +     struct grant *persistent_gnt;
>> +
>>       /* Prevent new requests being issued until we fix things up. */
>>       spin_lock_irq(&info->io_lock);
>>       info->connected = suspend ?
>> @@ -714,6 +798,17 @@ static void blkif_free(struct blkfront_info *info, int suspend)
>>       /* No more blkif_request(). */
>>       if (info->rq)
>>               blk_stop_queue(info->rq);
>> +
>> +     /* Remove all persistent grants */
>> +     if (info->persistent_gnts_c) {
>> +             all_gnts = llist_del_all(&info->persistent_gnts);
>> +             llist_for_each_entry(persistent_gnt, all_gnts, node) {
>> +                     gnttab_end_foreign_access(persistent_gnt->gref, 0, 0UL);
>> +                     kfree(persistent_gnt);
>> +             }
>> +             info->persistent_gnts_c = 0;
>> +     }
>> +
>>       /* No more gnttab callback work. */
>>       gnttab_cancel_free_callback(&info->callback);
>>       spin_unlock_irq(&info->io_lock);
>> @@ -734,13 +829,42 @@ static void blkif_free(struct blkfront_info *info, int suspend)
>>
>>  }
>>
>> -static void blkif_completion(struct blk_shadow *s)
>> +static void blkif_completion(struct blk_shadow *s, struct blkfront_info *info,
>> +                          struct blkif_response *bret)
>>  {
>>       int i;
>> -     /* Do not let BLKIF_OP_DISCARD as nr_segment is in the same place
>> -      * flag. */
>> -     for (i = 0; i < s->req.u.rw.nr_segments; i++)
>> -             gnttab_end_foreign_access(s->req.u.rw.seg[i].gref, 0, 0UL);
>> +     struct bio_vec *bvec;
>> +     struct req_iterator iter;
>> +     unsigned long flags;
>> +     char *bvec_data;
>> +     void *shared_data;
>> +     unsigned int offset = 0;
>> +
>> +     if (bret->operation == BLKIF_OP_READ) {
>> +             /*
>> +              * Copy the data received from the backend into the bvec.
>> +              * Since bv_len can be different from PAGE_SIZE, we need to
>> +              * be sure we are actually copying the data from the right
>> +              * shared page.
>> +              */
>> +             rq_for_each_segment(bvec, s->request, iter) {
>> +                     BUG_ON((bvec->bv_offset + bvec->bv_len) > PAGE_SIZE);
>> +                     i = offset >> PAGE_SHIFT;
> 
> Could you also include a comment about the bug you found here, pls?

There's a comment before the rq_for_each_segment loop, that tries to
explain that, do you think the following is better?

/*
 * Copy the data received from the backend into the bvec.
 * Since bv_offset can be different than 0, and bv_len different
 * than PAGE_SIZE, we have to keep track of the current offset,
 * to be sure we are copying the data from the right shared page.
 */

>> +                     shared_data = kmap_atomic(
>> +                             pfn_to_page(s->grants_used[i]->pfn));
>> +                     bvec_data = bvec_kmap_irq(bvec, &flags);
>> +                     memcpy(bvec_data, shared_data + bvec->bv_offset,
>> +                             bvec->bv_len);
>> +                     bvec_kunmap_irq(bvec_data, &flags);
>> +                     kunmap_atomic(shared_data);
>> +                     offset += bvec->bv_len;
>> +             }
>> +     }
>> +     /* Add the persistent grant into the list of free grants */
>> +     for (i = 0; i < s->req.u.rw.nr_segments; i++) {
>> +             llist_add(&s->grants_used[i]->node, &info->persistent_gnts);
>> +             info->persistent_gnts_c++;
>> +     }
>>  }
>>
>>  static irqreturn_t blkif_interrupt(int irq, void *dev_id)
>> @@ -783,7 +907,7 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
>>               req  = info->shadow[id].request;
>>
>>               if (bret->operation != BLKIF_OP_DISCARD)
>> -                     blkif_completion(&info->shadow[id]);
>> +                     blkif_completion(&info->shadow[id], info, bret);
>>
>>               if (add_id_to_freelist(info, id)) {
>>                       WARN(1, "%s: response to %s (id %ld) couldn't be recycled!\n",
>> @@ -942,6 +1066,11 @@ again:
>>               message = "writing protocol";
>>               goto abort_transaction;
>>       }
>> +     err = xenbus_printf(xbt, dev->nodename,
>> +                         "feature-persistent-grants", "%d", 1);
> 
> So its %u in blkback, but %d in here? Which one should it be?

%u in both places.

>> +     if (err)
>> +             dev_warn(&dev->dev,
>> +                      "writing persistent grants feature to xenbus");
>>
>>       err = xenbus_transaction_end(xbt, 0);
>>       if (err) {
>> @@ -1029,6 +1158,8 @@ static int blkfront_probe(struct xenbus_device *dev,
>>       spin_lock_init(&info->io_lock);
>>       info->xbdev = dev;
>>       info->vdevice = vdevice;
>> +     init_llist_head(&info->persistent_gnts);
>> +     info->persistent_gnts_c = 0;
>>       info->connected = BLKIF_STATE_DISCONNECTED;
>>       INIT_WORK(&info->work, blkif_restart_queue);
>>
>> @@ -1093,7 +1224,7 @@ static int blkif_recover(struct blkfront_info *info)
>>                                       req->u.rw.seg[j].gref,
>>                                       info->xbdev->otherend_id,
>>                                       pfn_to_mfn(info->shadow[req->u.rw.id].frame[j]),
>> -                                     rq_data_dir(info->shadow[req->u.rw.id].request));
>> +                                     0);
>>               }
>>               info->shadow[req->u.rw.id].req = *req;
>>
>> --
>> 1.7.7.5 (Apple Git-26)
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
>>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 16:08:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 16:08:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQh14-0003v6-PP; Tue, 23 Oct 2012 16:07:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQh12-0003uv-Ej
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 16:07:40 +0000
Received: from [85.158.139.211:63278] by server-8.bemta-5.messagelabs.com id
	DE/14-23193-BC0C6805; Tue, 23 Oct 2012 16:07:39 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1351008458!19452231!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUyMjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24754 invoked from network); 23 Oct 2012 16:07:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 16:07:38 -0000
X-IronPort-AV: E=Sophos;i="4.80,635,1344211200"; d="scan'208";a="15339822"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Oct 2012 16:07:38 +0000
Received: from [192.168.1.30] (10.31.3.234) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 23 Oct 2012 17:07:37 +0100
Message-ID: <5086C0C8.5000306@citrix.com>
Date: Tue, 23 Oct 2012 18:07:36 +0200
From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk 
References: <1350559321-19066-1-git-send-email-roger.pau@citrix.com>
	<20121022134708.GA13832@konrad-lan.dumpdata.com>
In-Reply-To: <20121022134708.GA13832@konrad-lan.dumpdata.com>
Cc: "konrad.wilk@oracle.com" ,
	"linux-kernel@vger.kernel.org" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH RFC] Persistent grant maps for xen blk
	drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 22/10/12 15:47, Konrad Rzeszutek Wilk wrote:
> On Thu, Oct 18, 2012 at 01:22:01PM +0200, Roger Pau Monne wrote:
>> This patch implements persistent grants for the xen-blk{front,back}
>> mechanism. The effect of this change is to reduce the number of unmap
>> operations performed, since they cause a (costly) TLB shootdown. This
>> allows the I/O performance to scale better when a large number of VMs
>> are performing I/O.
>>
>> Previously, the blkfront driver was supplied a bvec[] from the request
>> queue. This was granted to dom0; dom0 performed the I/O and wrote
>> directly into the grant-mapped memory and unmapped it; blkfront then
>> removed foreign access for that grant. The cost of unmapping scales
>> badly with the number of CPUs in Dom0. An experiment showed that when
>> Dom0 has 24 VCPUs, and guests are performing parallel I/O to a
>> ramdisk, the IPIs from performing unmap's is a bottleneck at 5 guests
>> (at which point 650,000 IOPS are being performed in total). If more
>> than 5 guests are used, the performance declines. By 10 guests, only
>> 400,000 IOPS are being performed.
>>
>> This patch improves performance by only unmapping when the connection
>> between blkfront and back is broken.
>>
>> On startup blkfront notifies blkback that it is using persistent
>> grants, and blkback will do the same. If blkback is not capable of
>> persistent mapping, blkfront will still use the same grants, since it
>> is compatible with the previous protocol, and simplifies the code
>> complexity in blkfront.
>>
>> To perform a read, in persistent mode, blkfront uses a separate pool
>> of pages that it maps to dom0. When a request comes in, blkfront
>> transmutes the request so that blkback will write into one of these
>> free pages. Blkback keeps note of which grefs it has already
>> mapped. When a new ring request comes to blkback, it looks to see if
>> it has already mapped that page. If so, it will not map it again. If
>> the page hasn't been previously mapped, it is mapped now, and a record
>> is kept of this mapping. Blkback proceeds as usual. When blkfront is
>> notified that blkback has completed a request, it memcpy's from the
>> shared memory, into the bvec supplied. A record that the {gref, page}
>> tuple is mapped, and not inflight is kept.
>>
>> Writes are similar, except that the memcpy is peformed from the
>> supplied bvecs, into the shared pages, before the request is put onto
>> the ring.
>>
>> Blkback stores a mapping of grefs=>{page mapped to by gref} in
>> a red-black tree. As the grefs are not known apriori, and provide no
>> guarantees on their ordering, we have to perform a search
>> through this tree to find the page, for every gref we receive. This
>> operation takes O(log n) time in the worst case.
> 
> Might want to mention how blkfront stores it as well. It looks
> to be using 'llist' instead of 'list'? Any particular reason?

Since we are just pushing and poping grant references, I went for what I
think is the simplest one, a single linked list (list is a doubly linked
list). Oliver in the previous version was using something similar, but
custom made. I think it's best to use the data structures provided by
the kernel itself.

> 
>>
>> The maximum number of grants that blkback will persistenly map is
>> currently set to RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, to
>> prevent a malicios guest from attempting a DoS, by supplying fresh
>> grefs, causing the Dom0 kernel to map excessively. If a guest
>> is using persistent grants and exceeds the maximum number of grants to
>> map persistenly the newly passed grefs will be mapped and unmaped.
>> Using this approach, we can have requests that mix persistent and
>> non-persistent grants, and we need to handle them correctly.
>> This allows us to set the maximum number of persistent grants to a
>> lower value than RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, although
>> setting it will lead to unpredictable performance.
>>
>> In writing this patch, the question arrises as to if the additional
>> cost of performing memcpys in the guest (to/from the pool of granted
>> pages) outweigh the gains of not performing TLB shootdowns. The answer
>> to that question is `no'. There appears to be very little, if any
>> additional cost to the guest of using persistent grants. There is
>> perhaps a small saving, from the reduced number of hypercalls
>> performed in granting, and ending foreign access.
>>
>> Signed-off-by: Oliver Chick 
>> Signed-off-by: Roger Pau Monne 
>> Cc: 
>> Cc: 
>> ---
>> Benchmarks showing the impact of this patch in blk performance can be
>> found at:
>>
>> http://xenbits.xensource.com/people/royger/persistent_grants/
>> ---
>>  drivers/block/xen-blkback/blkback.c |  279 +++++++++++++++++++++++++++++++---
>>  drivers/block/xen-blkback/common.h  |   17 ++
>>  drivers/block/xen-blkback/xenbus.c  |   16 ++-
>>  drivers/block/xen-blkfront.c        |  183 ++++++++++++++++++++----
>>  4 files changed, 442 insertions(+), 53 deletions(-)
>>
>> diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
>> index c6decb9..2b982b2 100644
>> --- a/drivers/block/xen-blkback/blkback.c
>> +++ b/drivers/block/xen-blkback/blkback.c
>> @@ -78,6 +78,7 @@ struct pending_req {
>>       unsigned short          operation;
>>       int                     status;
>>       struct list_head        free_list;
>> +     unsigned int            unmap_seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
>>  };
>>
>>  #define BLKBACK_INVALID_HANDLE (~0)
>> @@ -98,6 +99,30 @@ struct xen_blkbk {
>>  static struct xen_blkbk *blkbk;
>>
>>  /*
>> + * Maximum number of grant pages that can be mapped in blkback.
>> + * BLKIF_MAX_SEGMENTS_PER_REQUEST * RING_SIZE is the maximum number of
>> + * pages that blkback will persistently map.
>> + */
>> +static inline unsigned int max_mapped_grant_pages(enum blkif_protocol protocol)
>> +{
>> +     switch (protocol) {
>> +     case BLKIF_PROTOCOL_NATIVE:
>> +             return __CONST_RING_SIZE(blkif, PAGE_SIZE) *
>> +                        BLKIF_MAX_SEGMENTS_PER_REQUEST;
>> +     case BLKIF_PROTOCOL_X86_32:
>> +             return __CONST_RING_SIZE(blkif_x86_32, PAGE_SIZE) *
>> +                        BLKIF_MAX_SEGMENTS_PER_REQUEST;
>> +     case BLKIF_PROTOCOL_X86_64:
>> +             return __CONST_RING_SIZE(blkif_x86_64, PAGE_SIZE) *
>> +                        BLKIF_MAX_SEGMENTS_PER_REQUEST;
> 
> Could you include in the comments what the size (bytes) you expect it to be?
> If that would require you re-doing some tests - then don't worry - but
> I figured you have some notes scribbled away that have the exact values
> down.

As far as I know and remember (I've checked the ring size in the past),
all ring types have a size of 32, BLKIF_MAX_SEGMENTS_PER_REQUEST is
always 11, and sizeof(struct persistent_gnt) is 48, so that's 32 * 11 *
48 = 16896 bytes. I will add a comment with this calculation.

> 
>> +     default:
>> +             BUG();
>> +     }
>> +     return 0;
>> +}
>> +
>> +
>> +/*
>>   * Little helpful macro to figure out the index and virtual address of the
>>   * pending_pages[..]. For each 'pending_req' we have have up to
>>   * BLKIF_MAX_SEGMENTS_PER_REQUEST (11) pages. The seg would be from 0 through
>> @@ -128,6 +153,57 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>>  static void make_response(struct xen_blkif *blkif, u64 id,
>>                         unsigned short op, int st);
>>
>> +#define foreach_grant(pos, rbtree, node) \
>> +     for ((pos) = container_of(rb_first((rbtree)), typeof(*(pos)), node); \
>> +          &(pos)->node != NULL; \
>> +          (pos) = container_of(rb_next(&(pos)->node), typeof(*(pos)), node))
>> +
>> +
>> +static void add_persistent_gnt(struct rb_root *root,
>> +                            struct persistent_gnt *persistent_gnt)
>> +{
>> +     struct rb_node **new = &(root->rb_node), *parent = NULL;
>> +     struct persistent_gnt *this;
>> +
>> +     /* Figure out where to put new node */
>> +     while (*new) {
>> +             this = container_of(*new, struct persistent_gnt, node);
>> +
>> +             parent = *new;
>> +             if (persistent_gnt->gnt < this->gnt)
>> +                     new = &((*new)->rb_left);
>> +             else if (persistent_gnt->gnt > this->gnt)
>> +                     new = &((*new)->rb_right);
>> +             else {
>> +                     pr_alert(DRV_PFX " trying to add a gref that's already in the tree\n");
>> +                     BUG();
>> +             }
>> +     }
>> +
>> +     /* Add new node and rebalance tree. */
>> +     rb_link_node(&(persistent_gnt->node), parent, new);
>> +     rb_insert_color(&(persistent_gnt->node), root);
>> +}
>> +
>> +static struct persistent_gnt *get_persistent_gnt(struct rb_root *root,
>> +                                              grant_ref_t gref)
>> +{
>> +     struct persistent_gnt *data;
>> +     struct rb_node *node = root->rb_node;
>> +
>> +     while (node) {
>> +             data = container_of(node, struct persistent_gnt, node);
>> +
>> +             if (gref < data->gnt)
>> +                     node = node->rb_left;
>> +             else if (gref > data->gnt)
>> +                     node = node->rb_right;
>> +             else
>> +                     return data;
>> +     }
>> +     return NULL;
>> +}
>> +
>>  /*
>>   * Retrieve from the 'pending_reqs' a free pending_req structure to be used.
>>   */
>> @@ -274,6 +350,11 @@ int xen_blkif_schedule(void *arg)
>>  {
>>       struct xen_blkif *blkif = arg;
>>       struct xen_vbd *vbd = &blkif->vbd;
>> +     struct gnttab_unmap_grant_ref unmap[BLKIF_MAX_SEGMENTS_PER_REQUEST];
>> +     struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
>> +     struct persistent_gnt *persistent_gnt;
>> +     int ret = 0;
>> +     int segs_to_unmap = 0;
>>
>>       xen_blkif_get(blkif);
>>
>> @@ -301,6 +382,32 @@ int xen_blkif_schedule(void *arg)
>>                       print_stats(blkif);
>>       }
>>
>> +     /* Free all persistent grant pages */
>> +     foreach_grant(persistent_gnt, &blkif->persistent_gnts, node) {
> 
> Just for sanity - you did check this with blkfronts that did not have
> persistent grants enabled, right?

Yes, it doesn't crash, but looking at foreach_grant it seems like it
should. I've added a check before trying to iterate over the tree.

> 
>> +             BUG_ON(persistent_gnt->handle == BLKBACK_INVALID_HANDLE);
>> +             gnttab_set_unmap_op(&unmap[segs_to_unmap],
>> +                 (unsigned long) pfn_to_kaddr(page_to_pfn(
>> +                     persistent_gnt->page)),
>> +                 GNTMAP_host_map,
>> +                 persistent_gnt->handle);
>> +
>> +             pages[segs_to_unmap] = persistent_gnt->page;
>> +             rb_erase(&persistent_gnt->node, &blkif->persistent_gnts);
>> +             kfree(persistent_gnt);
>> +             blkif->persistent_gnt_c--;
>> +
>> +             if (++segs_to_unmap == BLKIF_MAX_SEGMENTS_PER_REQUEST ||
>> +                     !rb_next(&persistent_gnt->node)) {
>> +                     ret = gnttab_unmap_refs(unmap, NULL, pages,
>> +                                             segs_to_unmap);
>> +                     BUG_ON(ret);
>> +                     segs_to_unmap = 0;
>> +             }
>> +     }
>> +
>> +     BUG_ON(blkif->persistent_gnt_c != 0);
>> +     BUG_ON(!RB_EMPTY_ROOT(&blkif->persistent_gnts));
>> +
>>       if (log_stats)
>>               print_stats(blkif);
>>
>> @@ -327,6 +434,8 @@ static void xen_blkbk_unmap(struct pending_req *req)
>>       int ret;
>>
>>       for (i = 0; i < req->nr_pages; i++) {
>> +             if (!req->unmap_seg[i])
>> +                     continue;
> 
> Perhaps there should be a #define for that array..

Do you mean something like:

#define unmap(req, i) req->unmap_seg[i]

>>               handle = pending_handle(req, i);
>>               if (handle == BLKBACK_INVALID_HANDLE)
>>                       continue;
>> @@ -343,12 +452,26 @@ static void xen_blkbk_unmap(struct pending_req *req)
>>
>>  static int xen_blkbk_map(struct blkif_request *req,
>>                        struct pending_req *pending_req,
>> -                      struct seg_buf seg[])
>> +                      struct seg_buf seg[],
>> +                      struct page *pages[])
>>  {
>>       struct gnttab_map_grant_ref map[BLKIF_MAX_SEGMENTS_PER_REQUEST];
>> -     int i;
>> +     struct persistent_gnt *persistent_gnts[BLKIF_MAX_SEGMENTS_PER_REQUEST];
>> +     struct page *pages_to_gnt[BLKIF_MAX_SEGMENTS_PER_REQUEST];
>> +     struct persistent_gnt *persistent_gnt = NULL;
>> +     struct xen_blkif *blkif = pending_req->blkif;
>> +     phys_addr_t addr = 0;
>> +     int i, j;
>> +     int new_map;
> 
> Just use a bool for this.

Done

>>       int nseg = req->u.rw.nr_segments;
>> +     int segs_to_map = 0;
>>       int ret = 0;
>> +     int use_persistent_gnts;
>> +
>> +     use_persistent_gnts = (blkif->vbd.feature_gnt_persistent);
>> +
>> +     BUG_ON(blkif->persistent_gnt_c >
>> +                max_mapped_grant_pages(pending_req->blkif->blk_protocol));
>>
>>       /*
>>        * Fill out preq.nr_sects with proper amount of sectors, and setup
>> @@ -358,36 +481,141 @@ static int xen_blkbk_map(struct blkif_request *req,
>>       for (i = 0; i < nseg; i++) {
>>               uint32_t flags;
>>
>> -             flags = GNTMAP_host_map;
>> -             if (pending_req->operation != BLKIF_OP_READ)
>> -                     flags |= GNTMAP_readonly;
>> -             gnttab_set_map_op(&map[i], vaddr(pending_req, i), flags,
>> -                               req->u.rw.seg[i].gref,
>> -                               pending_req->blkif->domid);
>> +             if (use_persistent_gnts)
>> +                     persistent_gnt = get_persistent_gnt(
>> +                             &blkif->persistent_gnts,
>> +                             req->u.rw.seg[i].gref);
>> +
>> +             if (persistent_gnt) {
>> +                     /*
>> +                      * We are using persistent grants and
>> +                      * the grant is already mapped
>> +                      */
>> +                     new_map = 0;
>> +             } else if (use_persistent_gnts &&
>> +                        blkif->persistent_gnt_c <
>> +                        max_mapped_grant_pages(blkif->blk_protocol)) {
>> +                     /*
>> +                      * We are using persistent grants, the grant is
>> +                      * not mapped but we have room for it
>> +                      */
>> +                     new_map = 1;
>> +                     persistent_gnt = kzalloc(
>> +                             sizeof(struct persistent_gnt),
>> +                             GFP_KERNEL);
>> +                     if (!persistent_gnt)
>> +                             return -ENOMEM;
>> +                     persistent_gnt->page = alloc_page(GFP_KERNEL);
>> +                     if (!persistent_gnt->page) {
>> +                             kfree(persistent_gnt);
>> +                             return -ENOMEM;
>> +                     }
>> +                     persistent_gnt->gnt = req->u.rw.seg[i].gref;
>> +
>> +                     pages_to_gnt[segs_to_map] =
>> +                             persistent_gnt->page;
>> +                     addr = (unsigned long) pfn_to_kaddr(
>> +                             page_to_pfn(persistent_gnt->page));
>> +
>> +                     add_persistent_gnt(&blkif->persistent_gnts,
>> +                             persistent_gnt);
>> +                     blkif->persistent_gnt_c++;
>> +                     pr_debug(DRV_PFX " grant %u added to the tree of persistent grants, using %u/%u\n",
>> +                              persistent_gnt->gnt, blkif->persistent_gnt_c,
>> +                              max_mapped_grant_pages(blkif->blk_protocol));
>> +             } else {
>> +                     /*
>> +                      * We are either using persistent grants and
>> +                      * hit the maximum limit of grants mapped,
>> +                      * or we are not using persistent grants.
>> +                      */
>> +                     if (use_persistent_gnts &&
>> +                             !blkif->vbd.overflow_max_grants) {
>> +                             blkif->vbd.overflow_max_grants = 1;
>> +                             pr_alert(DRV_PFX " domain %u, device %#x is using maximum number of persistent grants\n",
>> +                                      blkif->domid, blkif->vbd.handle);
>> +                     }
>> +                     new_map = 1;
>> +                     pages[i] = blkbk->pending_page(pending_req, i);
>> +                     addr = vaddr(pending_req, i);
>> +                     pages_to_gnt[segs_to_map] =
>> +                             blkbk->pending_page(pending_req, i);
>> +             }
>> +
>> +             if (persistent_gnt) {
>> +                     pages[i] = persistent_gnt->page;
>> +                     persistent_gnts[i] = persistent_gnt;
>> +             } else {
>> +                     persistent_gnts[i] = NULL;
>> +             }
>> +
>> +             if (new_map) {
>> +                     flags = GNTMAP_host_map;
>> +                     if (!persistent_gnt &&
>> +                         (pending_req->operation != BLKIF_OP_READ))
>> +                             flags |= GNTMAP_readonly;
>> +                     gnttab_set_map_op(&map[segs_to_map++], addr,
>> +                                       flags, req->u.rw.seg[i].gref,
>> +                                       blkif->domid);
>> +             }
>>       }
>>
>> -     ret = gnttab_map_refs(map, NULL, &blkbk->pending_page(pending_req, 0), nseg);
>> -     BUG_ON(ret);
>> +     if (segs_to_map) {
>> +             ret = gnttab_map_refs(map, NULL, pages_to_gnt, segs_to_map);
>> +             BUG_ON(ret);
>> +     }
>>
>>       /*
>>        * Now swizzle the MFN in our domain with the MFN from the other domain
>>        * so that when we access vaddr(pending_req,i) it has the contents of
>>        * the page from the other domain.
>>        */
>> -     for (i = 0; i < nseg; i++) {
>> -             if (unlikely(map[i].status != 0)) {
>> -                     pr_debug(DRV_PFX "invalid buffer -- could not remap it\n");
>> -                     map[i].handle = BLKBACK_INVALID_HANDLE;
>> -                     ret |= 1;
>> +     for (i = 0, j = 0; i < nseg; i++) {
>> +             if (!persistent_gnts[i] || !persistent_gnts[i]->handle) {
>> +                     /* This is a newly mapped grant */
>> +                     BUG_ON(j >= segs_to_map);
>> +                     if (unlikely(map[j].status != 0)) {
> 
> I am not seeing j being incremented anywhere? Should it?

Yes, it should be incremented, but not here. See the comment below to
see what I've changed.

> 
>> +                             pr_debug(DRV_PFX "invalid buffer -- could not remap it\n");
>> +                             map[j].handle = BLKBACK_INVALID_HANDLE;
>> +                             ret |= 1;
>> +                             if (persistent_gnts[i]) {
>> +                                     rb_erase(&persistent_gnts[i]->node,
>> +                                              &blkif->persistent_gnts);
>> +                                     blkif->persistent_gnt_c--;
>> +                                     kfree(persistent_gnts[i]);
>> +                                     persistent_gnts[i] = NULL;
>> +                             }
>> +                     }
>> +             }
>> +             if (persistent_gnts[i]) {
>> +                     if (!persistent_gnts[i]->handle) {
>> +                             /*
>> +                              * If this is a new persistent grant
>> +                              * save the handler
>> +                              */
>> +                             persistent_gnts[i]->handle = map[j].handle;
>> +                             persistent_gnts[i]->dev_bus_addr =
>> +                                     map[j++].dev_bus_addr;
>> +                     }
>> +                     pending_handle(pending_req, i) =
>> +                             persistent_gnts[i]->handle;
>> +                     pending_req->unmap_seg[i] = 0;
> 
> Could we have a #define for that?

Sure.

>> +
>> +                     if (ret)
>> +                             continue;

This should be

if (ret) {
	j++;
	continue;
}

>> +
>> +                     seg[i].buf = persistent_gnts[i]->dev_bus_addr |
>> +                             (req->u.rw.seg[i].first_sect << 9);
>> +             } else {
>> +                     pending_handle(pending_req, i) = map[j].handle;
>> +                     pending_req->unmap_seg[i] = 1;
> 
> And here as well?

Done.

>> +
>> +                     if (ret)
>> +                             continue;
>> +
>> +                     seg[i].buf = map[j++].dev_bus_addr |
>> +                             (req->u.rw.seg[i].first_sect << 9);
>>               }
>> -
>> -             pending_handle(pending_req, i) = map[i].handle;
>> -
>> -             if (ret)
>> -                     continue;
>> -
>> -             seg[i].buf  = map[i].dev_bus_addr |
>> -                     (req->u.rw.seg[i].first_sect << 9);
>>       }
>>       return ret;
>>  }
>> @@ -590,6 +818,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>>       int operation;
>>       struct blk_plug plug;
>>       bool drain = false;
>> +     struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
>>
>>       switch (req->operation) {
>>       case BLKIF_OP_READ:
>> @@ -676,7 +905,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>>        * the hypercall to unmap the grants - that is all done in
>>        * xen_blkbk_unmap.
>>        */
>> -     if (xen_blkbk_map(req, pending_req, seg))
>> +     if (xen_blkbk_map(req, pending_req, seg, pages))
>>               goto fail_flush;
>>
>>       /*
>> @@ -688,7 +917,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>>       for (i = 0; i < nseg; i++) {
>>               while ((bio == NULL) ||
>>                      (bio_add_page(bio,
>> -                                  blkbk->pending_page(pending_req, i),
>> +                                  pages[i],
>>                                    seg[i].nsec << 9,
>>                                    seg[i].buf & ~PAGE_MASK) == 0)) {
>>
>> diff --git a/drivers/block/xen-blkback/common.h b/drivers/block/xen-blkback/common.h
>> index 9ad3b5e..6c08ee9 100644
>> --- a/drivers/block/xen-blkback/common.h
>> +++ b/drivers/block/xen-blkback/common.h
>> @@ -34,6 +34,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -160,10 +161,22 @@ struct xen_vbd {
>>       sector_t                size;
>>       bool                    flush_support;
>>       bool                    discard_secure;
>> +
>> +     unsigned int            feature_gnt_persistent:1;
>> +     unsigned int            overflow_max_grants:1;
> 
> I think the v3.7-rc1 has this structure changed just a tiny bit, so you
> might want to rebase it on top of that.

I've done the rebase on top of your linux-next branch, commit
ad502612c173fff239250c9fe9bdfaaef70b9901.

> 
>>  };
>>
>>  struct backend_info;
>>
>> +
>> +struct persistent_gnt {
>> +     struct page *page;
>> +     grant_ref_t gnt;
>> +     grant_handle_t handle;
>> +     uint64_t dev_bus_addr;
>> +     struct rb_node node;
>> +};
>> +
>>  struct xen_blkif {
>>       /* Unique identifier for this interface. */
>>       domid_t                 domid;
>> @@ -190,6 +203,10 @@ struct xen_blkif {
>>       struct task_struct      *xenblkd;
>>       unsigned int            waiting_reqs;
>>
>> +     /* frontend feature information */
> 
> Huh?

Changed it to:

/* tree to store persistent grants */

>> +     struct rb_root          persistent_gnts;
>> +     unsigned int            persistent_gnt_c;
>> +
>>       /* statistics */
>>       unsigned long           st_print;
>>       int                     st_rd_req;
>> diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c
>> index 4f66171..9f88b4e 100644
>> --- a/drivers/block/xen-blkback/xenbus.c
>> +++ b/drivers/block/xen-blkback/xenbus.c
>> @@ -118,6 +118,7 @@ static struct xen_blkif *xen_blkif_alloc(domid_t domid)
>>       atomic_set(&blkif->drain, 0);
>>       blkif->st_print = jiffies;
>>       init_waitqueue_head(&blkif->waiting_to_free);
>> +     blkif->persistent_gnts.rb_node = NULL;
>>
>>       return blkif;
>>  }
>> @@ -721,6 +722,7 @@ static int connect_ring(struct backend_info *be)
>>       struct xenbus_device *dev = be->dev;
>>       unsigned long ring_ref;
>>       unsigned int evtchn;
>> +     unsigned int pers_grants;
>>       char protocol[64] = "";
>>       int err;
>>
>> @@ -750,8 +752,18 @@ static int connect_ring(struct backend_info *be)
>>               xenbus_dev_fatal(dev, err, "unknown fe protocol %s", protocol);
>>               return -1;
>>       }
>> -     pr_info(DRV_PFX "ring-ref %ld, event-channel %d, protocol %d (%s)\n",
>> -             ring_ref, evtchn, be->blkif->blk_protocol, protocol);
>> +     err = xenbus_gather(XBT_NIL, dev->otherend,
>> +                         "feature-persistent-grants", "%u",
>> +                         &pers_grants, NULL);
>> +     if (err)
>> +             pers_grants = 0;
>> +
>> +     be->blkif->vbd.feature_gnt_persistent = pers_grants;
>> +     be->blkif->vbd.overflow_max_grants = 0;
>> +
>> +     pr_info(DRV_PFX "ring-ref %ld, event-channel %d, protocol %d (%s) persistent %d\n",
>> +             ring_ref, evtchn, be->blkif->blk_protocol, protocol,
>> +             pers_grants);
> 
> Can you make that a string? So it is
>  pers_grants ? "persistent grants" : ""
> 
> instead of a zero of one value pls?

Yes, done.

>>
>>       /* Map the shared frame, irq etc. */
>>       err = xen_blkif_map(be->blkif, ring_ref, evtchn);
>> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
>> index 2c2d2e5..206d422 100644
>> --- a/drivers/block/xen-blkfront.c
>> +++ b/drivers/block/xen-blkfront.c
>> @@ -44,6 +44,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>
>>  #include 
>>  #include 
>> @@ -64,10 +65,17 @@ enum blkif_state {
>>       BLKIF_STATE_SUSPENDED,
>>  };
>>
>> +struct grant {
>> +     grant_ref_t gref;
>> +     unsigned long pfn;
>> +     struct llist_node node;
>> +};
>> +
>>  struct blk_shadow {
>>       struct blkif_request req;
>>       struct request *request;
>>       unsigned long frame[BLKIF_MAX_SEGMENTS_PER_REQUEST];
>> +     struct grant *grants_used[BLKIF_MAX_SEGMENTS_PER_REQUEST];
>>  };
>>
>>  static DEFINE_MUTEX(blkfront_mutex);
>> @@ -97,6 +105,8 @@ struct blkfront_info
>>       struct work_struct work;
>>       struct gnttab_free_callback callback;
>>       struct blk_shadow shadow[BLK_RING_SIZE];
>> +     struct llist_head persistent_gnts;
>> +     unsigned int persistent_gnts_c;
>>       unsigned long shadow_free;
>>       unsigned int feature_flush;
>>       unsigned int flush_op;
>> @@ -287,21 +297,36 @@ static int blkif_queue_request(struct request *req)
>>       unsigned long id;
>>       unsigned int fsect, lsect;
>>       int i, ref;
>> +
>> +     /*
>> +      * Used to store if we are able to queue the request by just using
>> +      * existing persistent grants (0), or if we have to get new grants,
> 
> What does the zero mean?

Frankly, no idea, I guess it was in Oliver's patch and I missed to spot it.

>> +      * as there are not sufficiently many free.
>> +      */
>> +     int new_persistent_gnts;
> 
> I think this can be a bool?

I agree.

>>       grant_ref_t gref_head;
>> +     struct page *granted_page;
>> +     struct grant *gnt_list_entry = NULL;
>>       struct scatterlist *sg;
>>
>>       if (unlikely(info->connected != BLKIF_STATE_CONNECTED))
>>               return 1;
>>
>> -     if (gnttab_alloc_grant_references(
>> -             BLKIF_MAX_SEGMENTS_PER_REQUEST, &gref_head) < 0) {
>> -             gnttab_request_free_callback(
>> -                     &info->callback,
>> -                     blkif_restart_queue_callback,
>> -                     info,
>> -                     BLKIF_MAX_SEGMENTS_PER_REQUEST);
>> -             return 1;
>> -     }
>> +     /* Check if we have enought grants to allocate a requests */
>> +     if (info->persistent_gnts_c < BLKIF_MAX_SEGMENTS_PER_REQUEST) {
>> +             new_persistent_gnts = 1;
>> +             if (gnttab_alloc_grant_references(
>> +                 BLKIF_MAX_SEGMENTS_PER_REQUEST - info->persistent_gnts_c,
>> +                 &gref_head) < 0) {
>> +                     gnttab_request_free_callback(
>> +                             &info->callback,
>> +                             blkif_restart_queue_callback,
>> +                             info,
>> +                             BLKIF_MAX_SEGMENTS_PER_REQUEST);
>> +                     return 1;
>> +             }
>> +     } else
>> +             new_persistent_gnts = 0;
>>
>>       /* Fill out a communications ring structure. */
>>       ring_req = RING_GET_REQUEST(&info->ring, info->ring.req_prod_pvt);
>> @@ -341,18 +366,73 @@ static int blkif_queue_request(struct request *req)
>>                      BLKIF_MAX_SEGMENTS_PER_REQUEST);
>>
>>               for_each_sg(info->sg, sg, ring_req->u.rw.nr_segments, i) {
>> -                     buffer_mfn = pfn_to_mfn(page_to_pfn(sg_page(sg)));
>>                       fsect = sg->offset >> 9;
>>                       lsect = fsect + (sg->length >> 9) - 1;
>> -                     /* install a grant reference. */
>> -                     ref = gnttab_claim_grant_reference(&gref_head);
>> -                     BUG_ON(ref == -ENOSPC);
>>
>> -                     gnttab_grant_foreign_access_ref(
>> -                                     ref,
>> +                     if (info->persistent_gnts_c) {
>> +                             BUG_ON(llist_empty(&info->persistent_gnts));
>> +                             gnt_list_entry = llist_entry(
>> +                                     llist_del_first(&info->persistent_gnts),
>> +                                     struct grant, node);
>> +
>> +                             ref = gnt_list_entry->gref;
>> +                             buffer_mfn = pfn_to_mfn(gnt_list_entry->pfn);
>> +                             info->persistent_gnts_c--;
>> +                     } else {
>> +                             ref = gnttab_claim_grant_reference(&gref_head);
>> +                             BUG_ON(ref == -ENOSPC);
>> +
>> +                             gnt_list_entry =
>> +                                     kmalloc(sizeof(struct grant),
>> +                                                      GFP_ATOMIC);
>> +                             if (!gnt_list_entry)
>> +                                     return -ENOMEM;
>> +
>> +                             granted_page = alloc_page(GFP_ATOMIC);
>> +                             if (!granted_page) {
>> +                                     kfree(gnt_list_entry);
>> +                                     return -ENOMEM;
>> +                             }
>> +
>> +                             gnt_list_entry->pfn =
>> +                                     page_to_pfn(granted_page);
>> +                             gnt_list_entry->gref = ref;
>> +
>> +                             buffer_mfn = pfn_to_mfn(page_to_pfn(
>> +                                                             granted_page));
>> +                             gnttab_grant_foreign_access_ref(ref,
>>                                       info->xbdev->otherend_id,
>> -                                     buffer_mfn,
>> -                                     rq_data_dir(req));
>> +                                     buffer_mfn, 0);
>> +                     }
>> +
>> +                     info->shadow[id].grants_used[i] = gnt_list_entry;
>> +
>> +                     if (rq_data_dir(req)) {
>> +                             char *bvec_data;
>> +                             void *shared_data;
>> +
>> +                             BUG_ON(sg->offset + sg->length > PAGE_SIZE);
>> +
>> +                             shared_data = kmap_atomic(
>> +                                     pfn_to_page(gnt_list_entry->pfn));
>> +                             bvec_data = kmap_atomic(sg_page(sg));
>> +
>> +                             /*
>> +                              * this does not wipe data stored outside the
>> +                              * range sg->offset..sg->offset+sg->length.
>> +                              * Therefore, blkback *could* see data from
>> +                              * previous requests. This is OK as long as
>> +                              * persistent grants are shared with just one
>> +                              * domain. It may need refactoring if This
> .. this (lowercase it pls)

Done.

> 
>> +                              * changes
>> +                              */
>> +                             memcpy(shared_data + sg->offset,
>> +                                    bvec_data   + sg->offset,
>> +                                    sg->length);
>> +
>> +                             kunmap_atomic(bvec_data);
>> +                             kunmap_atomic(shared_data);
>> +                     }
>>
>>                       info->shadow[id].frame[i] = mfn_to_pfn(buffer_mfn);
>>                       ring_req->u.rw.seg[i] =
>> @@ -368,7 +448,8 @@ static int blkif_queue_request(struct request *req)
>>       /* Keep a private copy so we can reissue requests when recovering. */
>>       info->shadow[id].req = *ring_req;
>>
>> -     gnttab_free_grant_references(gref_head);
>> +     if (new_persistent_gnts)
>> +             gnttab_free_grant_references(gref_head);
>>
>>       return 0;
>>  }
>> @@ -480,7 +561,7 @@ static int xlvbd_init_blk_queue(struct gendisk *gd, u16 sector_size)
>>  static void xlvbd_flush(struct blkfront_info *info)
>>  {
>>       blk_queue_flush(info->rq, info->feature_flush);
>> -     printk(KERN_INFO "blkfront: %s: %s: %s\n",
>> +     printk(KERN_INFO "blkfront: %s: %s: %s, using persistent grants\n",
> 
> HA! By default, eh?

Yes, you caught me, there's a paragraph in the commit message that
explains that we are using persistent grants in the frontend
unconditionally, since the protocol is compatible (you can have a
persistent blkfront and a non-persistent blkback). It simplifies the
logic in blkfront. Are you OK with it?

>>              info->gd->disk_name,
>>              info->flush_op == BLKIF_OP_WRITE_BARRIER ?
>>               "barrier" : (info->flush_op == BLKIF_OP_FLUSH_DISKCACHE ?
>> @@ -707,6 +788,9 @@ static void blkif_restart_queue(struct work_struct *work)
>>
>>  static void blkif_free(struct blkfront_info *info, int suspend)
>>  {
>> +     struct llist_node *all_gnts;
>> +     struct grant *persistent_gnt;
>> +
>>       /* Prevent new requests being issued until we fix things up. */
>>       spin_lock_irq(&info->io_lock);
>>       info->connected = suspend ?
>> @@ -714,6 +798,17 @@ static void blkif_free(struct blkfront_info *info, int suspend)
>>       /* No more blkif_request(). */
>>       if (info->rq)
>>               blk_stop_queue(info->rq);
>> +
>> +     /* Remove all persistent grants */
>> +     if (info->persistent_gnts_c) {
>> +             all_gnts = llist_del_all(&info->persistent_gnts);
>> +             llist_for_each_entry(persistent_gnt, all_gnts, node) {
>> +                     gnttab_end_foreign_access(persistent_gnt->gref, 0, 0UL);
>> +                     kfree(persistent_gnt);
>> +             }
>> +             info->persistent_gnts_c = 0;
>> +     }
>> +
>>       /* No more gnttab callback work. */
>>       gnttab_cancel_free_callback(&info->callback);
>>       spin_unlock_irq(&info->io_lock);
>> @@ -734,13 +829,42 @@ static void blkif_free(struct blkfront_info *info, int suspend)
>>
>>  }
>>
>> -static void blkif_completion(struct blk_shadow *s)
>> +static void blkif_completion(struct blk_shadow *s, struct blkfront_info *info,
>> +                          struct blkif_response *bret)
>>  {
>>       int i;
>> -     /* Do not let BLKIF_OP_DISCARD as nr_segment is in the same place
>> -      * flag. */
>> -     for (i = 0; i < s->req.u.rw.nr_segments; i++)
>> -             gnttab_end_foreign_access(s->req.u.rw.seg[i].gref, 0, 0UL);
>> +     struct bio_vec *bvec;
>> +     struct req_iterator iter;
>> +     unsigned long flags;
>> +     char *bvec_data;
>> +     void *shared_data;
>> +     unsigned int offset = 0;
>> +
>> +     if (bret->operation == BLKIF_OP_READ) {
>> +             /*
>> +              * Copy the data received from the backend into the bvec.
>> +              * Since bv_len can be different from PAGE_SIZE, we need to
>> +              * be sure we are actually copying the data from the right
>> +              * shared page.
>> +              */
>> +             rq_for_each_segment(bvec, s->request, iter) {
>> +                     BUG_ON((bvec->bv_offset + bvec->bv_len) > PAGE_SIZE);
>> +                     i = offset >> PAGE_SHIFT;
> 
> Could you also include a comment about the bug you found here, pls?

There's a comment before the rq_for_each_segment loop, that tries to
explain that, do you think the following is better?

/*
 * Copy the data received from the backend into the bvec.
 * Since bv_offset can be different than 0, and bv_len different
 * than PAGE_SIZE, we have to keep track of the current offset,
 * to be sure we are copying the data from the right shared page.
 */

>> +                     shared_data = kmap_atomic(
>> +                             pfn_to_page(s->grants_used[i]->pfn));
>> +                     bvec_data = bvec_kmap_irq(bvec, &flags);
>> +                     memcpy(bvec_data, shared_data + bvec->bv_offset,
>> +                             bvec->bv_len);
>> +                     bvec_kunmap_irq(bvec_data, &flags);
>> +                     kunmap_atomic(shared_data);
>> +                     offset += bvec->bv_len;
>> +             }
>> +     }
>> +     /* Add the persistent grant into the list of free grants */
>> +     for (i = 0; i < s->req.u.rw.nr_segments; i++) {
>> +             llist_add(&s->grants_used[i]->node, &info->persistent_gnts);
>> +             info->persistent_gnts_c++;
>> +     }
>>  }
>>
>>  static irqreturn_t blkif_interrupt(int irq, void *dev_id)
>> @@ -783,7 +907,7 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
>>               req  = info->shadow[id].request;
>>
>>               if (bret->operation != BLKIF_OP_DISCARD)
>> -                     blkif_completion(&info->shadow[id]);
>> +                     blkif_completion(&info->shadow[id], info, bret);
>>
>>               if (add_id_to_freelist(info, id)) {
>>                       WARN(1, "%s: response to %s (id %ld) couldn't be recycled!\n",
>> @@ -942,6 +1066,11 @@ again:
>>               message = "writing protocol";
>>               goto abort_transaction;
>>       }
>> +     err = xenbus_printf(xbt, dev->nodename,
>> +                         "feature-persistent-grants", "%d", 1);
> 
> So its %u in blkback, but %d in here? Which one should it be?

%u in both places.

>> +     if (err)
>> +             dev_warn(&dev->dev,
>> +                      "writing persistent grants feature to xenbus");
>>
>>       err = xenbus_transaction_end(xbt, 0);
>>       if (err) {
>> @@ -1029,6 +1158,8 @@ static int blkfront_probe(struct xenbus_device *dev,
>>       spin_lock_init(&info->io_lock);
>>       info->xbdev = dev;
>>       info->vdevice = vdevice;
>> +     init_llist_head(&info->persistent_gnts);
>> +     info->persistent_gnts_c = 0;
>>       info->connected = BLKIF_STATE_DISCONNECTED;
>>       INIT_WORK(&info->work, blkif_restart_queue);
>>
>> @@ -1093,7 +1224,7 @@ static int blkif_recover(struct blkfront_info *info)
>>                                       req->u.rw.seg[j].gref,
>>                                       info->xbdev->otherend_id,
>>                                       pfn_to_mfn(info->shadow[req->u.rw.id].frame[j]),
>> -                                     rq_data_dir(info->shadow[req->u.rw.id].request));
>> +                                     0);
>>               }
>>               info->shadow[req->u.rw.id].req = *req;
>>
>> --
>> 1.7.7.5 (Apple Git-26)
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
>>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 16:13:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 16:13:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQh6J-00048F-OF; Tue, 23 Oct 2012 16:13:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQh6I-00048A-C3
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 16:13:06 +0000
Received: from [85.158.143.35:64616] by server-3.bemta-4.messagelabs.com id
	79/EA-03544-112C6805; Tue, 23 Oct 2012 16:13:05 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1351008785!19987766!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUyMjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27094 invoked from network); 23 Oct 2012 16:13:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 16:13:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,635,1344211200"; 
	d="asc'?scan'208";a="15339920"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Oct 2012 16:13:04 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 23 Oct 2012 17:13:04 +0100
Message-ID: <1351008783.5064.59.camel@Solace>
From: Dario Faggioli 
To: George Dunlap 
Date: Tue, 23 Oct 2012 18:13:03 +0200
In-Reply-To: <5086C022.3070702@eu.citrix.com>
References: 
	
	<5086C022.3070702@eu.citrix.com>
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Paul Durrant , "Keir \(Xen.org\)" ,
	Jan Beulich ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 2 of 6] xen: move `printk("Initializing
 domain")` from credit to generic scheduling code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============8555232287043183457=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8555232287043183457==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-PteI+tzPA17LZrvaMW01"

--=-PteI+tzPA17LZrvaMW01
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2012-10-23 at 17:04 +0100, George Dunlap wrote:
> On 22/10/12 15:40, Dario Faggioli wrote:
> > As, if it makes sense to let people know about it, it probably always d=
oes.
> >
> > Signed-off-by: Dario Faggioli 
>=20
> The difference is, credit2 is explicity "experimental"; it's not=20
> unexpected to have a bunch of chatty debug messages when random things=
=20
> happen. =20
>
I see.

> I don't think we want to print this on production systems=20
> running credit1.
>=20
Ok, I think I agree.

> Maybe change it to "KERN_DEBUG"?
>=20
Well, that, or maybe just forget this patch (for now). I'm fine with
both. :-)

Thanks for looking at this,
Dario

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-PteI+tzPA17LZrvaMW01
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlCGwg8ACgkQk4XaBE3IOsQeOwCfb1zNqeCedIGXLYXJqJtw/Cl7
2jAAn2xPCQpXUHBATPtapjO2JmnmHEws
=ib7d
-----END PGP SIGNATURE-----

--=-PteI+tzPA17LZrvaMW01--


--===============8555232287043183457==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8555232287043183457==--


From xen-devel-bounces@lists.xen.org Tue Oct 23 16:13:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 16:13:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQh6J-00048F-OF; Tue, 23 Oct 2012 16:13:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQh6I-00048A-C3
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 16:13:06 +0000
Received: from [85.158.143.35:64616] by server-3.bemta-4.messagelabs.com id
	79/EA-03544-112C6805; Tue, 23 Oct 2012 16:13:05 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1351008785!19987766!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUyMjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27094 invoked from network); 23 Oct 2012 16:13:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 16:13:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,635,1344211200"; 
	d="asc'?scan'208";a="15339920"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Oct 2012 16:13:04 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 23 Oct 2012 17:13:04 +0100
Message-ID: <1351008783.5064.59.camel@Solace>
From: Dario Faggioli 
To: George Dunlap 
Date: Tue, 23 Oct 2012 18:13:03 +0200
In-Reply-To: <5086C022.3070702@eu.citrix.com>
References: 
	
	<5086C022.3070702@eu.citrix.com>
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Paul Durrant , "Keir \(Xen.org\)" ,
	Jan Beulich ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 2 of 6] xen: move `printk("Initializing
 domain")` from credit to generic scheduling code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============8555232287043183457=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8555232287043183457==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-PteI+tzPA17LZrvaMW01"

--=-PteI+tzPA17LZrvaMW01
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2012-10-23 at 17:04 +0100, George Dunlap wrote:
> On 22/10/12 15:40, Dario Faggioli wrote:
> > As, if it makes sense to let people know about it, it probably always d=
oes.
> >
> > Signed-off-by: Dario Faggioli 
>=20
> The difference is, credit2 is explicity "experimental"; it's not=20
> unexpected to have a bunch of chatty debug messages when random things=
=20
> happen. =20
>
I see.

> I don't think we want to print this on production systems=20
> running credit1.
>=20
Ok, I think I agree.

> Maybe change it to "KERN_DEBUG"?
>=20
Well, that, or maybe just forget this patch (for now). I'm fine with
both. :-)

Thanks for looking at this,
Dario

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-PteI+tzPA17LZrvaMW01
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlCGwg8ACgkQk4XaBE3IOsQeOwCfb1zNqeCedIGXLYXJqJtw/Cl7
2jAAn2xPCQpXUHBATPtapjO2JmnmHEws
=ib7d
-----END PGP SIGNATURE-----

--=-PteI+tzPA17LZrvaMW01--


--===============8555232287043183457==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8555232287043183457==--


From xen-devel-bounces@lists.xen.org Tue Oct 23 16:20:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 16:20:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQhDI-0004Ib-O4; Tue, 23 Oct 2012 16:20:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQhDH-0004IW-Gc
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 16:20:19 +0000
Received: from [85.158.139.83:7941] by server-4.bemta-5.messagelabs.com id
	AE/93-01455-2C3C6805; Tue, 23 Oct 2012 16:20:18 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1351009216!31863041!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODQzOTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12671 invoked from network); 23 Oct 2012 16:20:18 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 16:20:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,635,1344211200"; d="scan'208";a="212196302"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Oct 2012 16:20:15 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 23 Oct 2012 12:20:15 -0400
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[0.0.0.0])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TQhDD-0003R1-A4;
	Tue, 23 Oct 2012 17:20:15 +0100
Message-ID: <5086C3BE.9070105@eu.citrix.com>
Date: Tue, 23 Oct 2012 17:20:14 +0100
From: George Dunlap 
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Dario Faggioli 
References: 
	
	<5086C022.3070702@eu.citrix.com> <1351008783.5064.59.camel@Solace>
In-Reply-To: <1351008783.5064.59.camel@Solace>
Cc: Paul Durrant , "Keir \(Xen.org\)" ,
	Jan Beulich ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 2 of 6] xen: move `printk("Initializing
 domain")` from credit to generic scheduling code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 23/10/12 17:13, Dario Faggioli wrote:
>> Maybe change it to "KERN_DEBUG"?
>>
> Well, that, or maybe just forget this patch (for now). I'm fine with
> both. :-)

OK -- for now why don't we drop it. :-)

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 16:20:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 16:20:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQhDI-0004Ib-O4; Tue, 23 Oct 2012 16:20:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQhDH-0004IW-Gc
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 16:20:19 +0000
Received: from [85.158.139.83:7941] by server-4.bemta-5.messagelabs.com id
	AE/93-01455-2C3C6805; Tue, 23 Oct 2012 16:20:18 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1351009216!31863041!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODQzOTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12671 invoked from network); 23 Oct 2012 16:20:18 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 16:20:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,635,1344211200"; d="scan'208";a="212196302"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Oct 2012 16:20:15 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 23 Oct 2012 12:20:15 -0400
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[0.0.0.0])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TQhDD-0003R1-A4;
	Tue, 23 Oct 2012 17:20:15 +0100
Message-ID: <5086C3BE.9070105@eu.citrix.com>
Date: Tue, 23 Oct 2012 17:20:14 +0100
From: George Dunlap 
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Dario Faggioli 
References: 
	
	<5086C022.3070702@eu.citrix.com> <1351008783.5064.59.camel@Solace>
In-Reply-To: <1351008783.5064.59.camel@Solace>
Cc: Paul Durrant , "Keir \(Xen.org\)" ,
	Jan Beulich ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 2 of 6] xen: move `printk("Initializing
 domain")` from credit to generic scheduling code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 23/10/12 17:13, Dario Faggioli wrote:
>> Maybe change it to "KERN_DEBUG"?
>>
> Well, that, or maybe just forget this patch (for now). I'm fine with
> both. :-)

OK -- for now why don't we drop it. :-)

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 16:27:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 16:27:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQhJa-0004RZ-Id; Tue, 23 Oct 2012 16:26:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQhJY-0004RR-U3
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 16:26:49 +0000
Received: from [85.158.139.83:45970] by server-16.bemta-5.messagelabs.com id
	29/9C-09196-845C6805; Tue, 23 Oct 2012 16:26:48 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1351009605!28821037!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzg0MDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24232 invoked from network); 23 Oct 2012 16:26:47 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 16:26:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,635,1344211200"; d="scan'208";a="42173467"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Oct 2012 16:26:45 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 23 Oct 2012 12:26:45 -0400
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[0.0.0.0])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TQhJV-0003WO-1r;
	Tue, 23 Oct 2012 17:26:45 +0100
Message-ID: <5086C544.4070607@eu.citrix.com>
Date: Tue, 23 Oct 2012 17:26:44 +0100
From: George Dunlap 
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Dario Faggioli 
References: 
	<27c4c065efe366a5d761.1350916838@Solace>
In-Reply-To: <27c4c065efe366a5d761.1350916838@Solace>
Cc: Paul Durrant , "Keir \(Xen.org\)" ,
	Jan Beulich ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 5 of 6] xen: sched_sedf: beautify statisics
	in SEDF
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 22/10/12 15:40, Dario Faggioli wrote:
> By gathering all the related fields in a struct (as it is being done
> in credit) and using the macros we now have available. No functional
> changes involved.
>
> Signed-off-by: Dario Faggioli 

I'm OK with this as it is, but...

>   #ifdef SEDF_STATS
> -    if ( EDOM_INFO(d)->block_time_tot != 0 )
> -        printk(" pen=%"PRIu64"%%", (EDOM_INFO(d)->penalty_time_tot * 100) /
> -               EDOM_INFO(d)->block_time_tot);
> -    if ( EDOM_INFO(d)->block_tot != 0 )
> +    if ( EDOM_INFO(d)->stats.block_time_tot != 0 )
> +        printk(" pen=%"PRIu64"%%", (EDOM_INFO(d)->stats.penalty_time_tot * 100) /
> +               EDOM_INFO(d)->stats.block_time_tot);
> +    if ( EDOM_INFO(d)->stats.block_tot != 0 )
>           printk("\n   blks=%u sh=%u (%u%%) (shc=%u (%u%%) shex=%i "\
>                  "shexsl=%i) l=%u (%u%%) avg: b=%"PRIu64" p=%"PRIu64"",
> -               EDOM_INFO(d)->block_tot, EDOM_INFO(d)->short_block_tot,
> -               (EDOM_INFO(d)->short_block_tot * 100)
> -               / EDOM_INFO(d)->block_tot, EDOM_INFO(d)->short_cont,
> -               (EDOM_INFO(d)->short_cont * 100) / EDOM_INFO(d)->block_tot,
> -               EDOM_INFO(d)->pen_extra_blocks,
> -               EDOM_INFO(d)->pen_extra_slices,
> -               EDOM_INFO(d)->long_block_tot,
> -               (EDOM_INFO(d)->long_block_tot * 100) / EDOM_INFO(d)->block_tot,
> -               (EDOM_INFO(d)->block_time_tot) / EDOM_INFO(d)->block_tot,
> -               (EDOM_INFO(d)->penalty_time_tot) / EDOM_INFO(d)->block_tot);
> +               EDOM_INFO(d)->stats.block_tot, EDOM_INFO(d)->stats.short_block_tot,
> +               (EDOM_INFO(d)->stats.short_block_tot * 100)
> +               / EDOM_INFO(d)->stats.block_tot, EDOM_INFO(d)->stats.short_cont,
> +               (EDOM_INFO(d)->stats.short_cont * 100) / EDOM_INFO(d)->stats.block_tot,
> +               EDOM_INFO(d)->stats.pen_extra_blocks,
> +               EDOM_INFO(d)->stats.pen_extra_slices,
> +               EDOM_INFO(d)->stats.long_block_tot,
> +               (EDOM_INFO(d)->stats.long_block_tot * 100) / EDOM_INFO(d)->stats.block_tot,
> +               (EDOM_INFO(d)->stats.block_time_tot) / EDOM_INFO(d)->stats.block_tot,
> +               (EDOM_INFO(d)->stats.penalty_time_tot) / EDOM_INFO(d)->stats.block_tot);

...wouldn't it be even more beautiful to have a macro for reading stats 
as well?

Like I said, it's fine as it is, but since you're looking for beauty, I 
figured I'd point it out. :-)

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 16:27:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 16:27:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQhJa-0004RZ-Id; Tue, 23 Oct 2012 16:26:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQhJY-0004RR-U3
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 16:26:49 +0000
Received: from [85.158.139.83:45970] by server-16.bemta-5.messagelabs.com id
	29/9C-09196-845C6805; Tue, 23 Oct 2012 16:26:48 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1351009605!28821037!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzg0MDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24232 invoked from network); 23 Oct 2012 16:26:47 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 16:26:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,635,1344211200"; d="scan'208";a="42173467"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Oct 2012 16:26:45 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 23 Oct 2012 12:26:45 -0400
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[0.0.0.0])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TQhJV-0003WO-1r;
	Tue, 23 Oct 2012 17:26:45 +0100
Message-ID: <5086C544.4070607@eu.citrix.com>
Date: Tue, 23 Oct 2012 17:26:44 +0100
From: George Dunlap 
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Dario Faggioli 
References: 
	<27c4c065efe366a5d761.1350916838@Solace>
In-Reply-To: <27c4c065efe366a5d761.1350916838@Solace>
Cc: Paul Durrant , "Keir \(Xen.org\)" ,
	Jan Beulich ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 5 of 6] xen: sched_sedf: beautify statisics
	in SEDF
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 22/10/12 15:40, Dario Faggioli wrote:
> By gathering all the related fields in a struct (as it is being done
> in credit) and using the macros we now have available. No functional
> changes involved.
>
> Signed-off-by: Dario Faggioli 

I'm OK with this as it is, but...

>   #ifdef SEDF_STATS
> -    if ( EDOM_INFO(d)->block_time_tot != 0 )
> -        printk(" pen=%"PRIu64"%%", (EDOM_INFO(d)->penalty_time_tot * 100) /
> -               EDOM_INFO(d)->block_time_tot);
> -    if ( EDOM_INFO(d)->block_tot != 0 )
> +    if ( EDOM_INFO(d)->stats.block_time_tot != 0 )
> +        printk(" pen=%"PRIu64"%%", (EDOM_INFO(d)->stats.penalty_time_tot * 100) /
> +               EDOM_INFO(d)->stats.block_time_tot);
> +    if ( EDOM_INFO(d)->stats.block_tot != 0 )
>           printk("\n   blks=%u sh=%u (%u%%) (shc=%u (%u%%) shex=%i "\
>                  "shexsl=%i) l=%u (%u%%) avg: b=%"PRIu64" p=%"PRIu64"",
> -               EDOM_INFO(d)->block_tot, EDOM_INFO(d)->short_block_tot,
> -               (EDOM_INFO(d)->short_block_tot * 100)
> -               / EDOM_INFO(d)->block_tot, EDOM_INFO(d)->short_cont,
> -               (EDOM_INFO(d)->short_cont * 100) / EDOM_INFO(d)->block_tot,
> -               EDOM_INFO(d)->pen_extra_blocks,
> -               EDOM_INFO(d)->pen_extra_slices,
> -               EDOM_INFO(d)->long_block_tot,
> -               (EDOM_INFO(d)->long_block_tot * 100) / EDOM_INFO(d)->block_tot,
> -               (EDOM_INFO(d)->block_time_tot) / EDOM_INFO(d)->block_tot,
> -               (EDOM_INFO(d)->penalty_time_tot) / EDOM_INFO(d)->block_tot);
> +               EDOM_INFO(d)->stats.block_tot, EDOM_INFO(d)->stats.short_block_tot,
> +               (EDOM_INFO(d)->stats.short_block_tot * 100)
> +               / EDOM_INFO(d)->stats.block_tot, EDOM_INFO(d)->stats.short_cont,
> +               (EDOM_INFO(d)->stats.short_cont * 100) / EDOM_INFO(d)->stats.block_tot,
> +               EDOM_INFO(d)->stats.pen_extra_blocks,
> +               EDOM_INFO(d)->stats.pen_extra_slices,
> +               EDOM_INFO(d)->stats.long_block_tot,
> +               (EDOM_INFO(d)->stats.long_block_tot * 100) / EDOM_INFO(d)->stats.block_tot,
> +               (EDOM_INFO(d)->stats.block_time_tot) / EDOM_INFO(d)->stats.block_tot,
> +               (EDOM_INFO(d)->stats.penalty_time_tot) / EDOM_INFO(d)->stats.block_tot);

...wouldn't it be even more beautiful to have a macro for reading stats 
as well?

Like I said, it's fine as it is, but since you're looking for beauty, I 
figured I'd point it out. :-)

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 16:28:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 16:28:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQhKb-0004VM-1A; Tue, 23 Oct 2012 16:27:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQhKZ-0004V5-PD
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 16:27:52 +0000
Received: from [85.158.143.35:53504] by server-1.bemta-4.messagelabs.com id
	25/B2-19134-685C6805; Tue, 23 Oct 2012 16:27:50 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1351009668!5544450!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzg0MDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15790 invoked from network); 23 Oct 2012 16:27:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 16:27:50 -0000
X-IronPort-AV: E=Sophos;i="4.80,635,1344211200"; d="scan'208";a="42173567"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Oct 2012 16:27:48 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 23 Oct 2012 12:27:48 -0400
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[0.0.0.0])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TQhKV-0003XF-Fz;
	Tue, 23 Oct 2012 17:27:47 +0100
Message-ID: <5086C582.8080804@eu.citrix.com>
Date: Tue, 23 Oct 2012 17:27:46 +0100
From: George Dunlap 
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Dario Faggioli 
References: 
	
In-Reply-To: 
Cc: Paul Durrant , "Keir \(Xen.org\)" ,
	Jan Beulich ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 3 of 6] xen: sched: generalize scheduling
 related perfcounter macros
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 22/10/12 15:40, Dario Faggioli wrote:
> Moving some of them from sched_credit.c to generic scheduler code.
> This also allows the other schedulers to use perf counters equally
> easy.
>
> This change is mainly preparatory work for what stated above. In fact,
> it mostly does s/CSCHED_STAT/SCHED_STAT/, and, in general, it implies no
> functional changes.
>
> Signed-off-by: Dario Faggioli 
Acked-by: George Dunlap 
>
> diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
> --- a/xen/common/sched_credit.c
> +++ b/xen/common/sched_credit.c
> @@ -16,25 +16,12 @@
>   #include 
>   #include 
>   #include 
> -#include 
>   #include 
>   #include 
>   #include 
>   #include 
>   #include 
>
> -/*
> - * CSCHED_STATS
> - *
> - * Manage very basic per-vCPU counters and stats.
> - *
> - * Useful for debugging live systems. The stats are displayed
> - * with runq dumps ('r' on the Xen console).
> - */
> -#ifdef PERF_COUNTERS
> -#define CSCHED_STATS
> -#endif
> -
>
>   /*
>    * Basic constants
> @@ -75,29 +62,36 @@
>
>
>   /*
> - * Stats
> + * CSCHED_STATS
> + *
> + * Manage very basic per-vCPU counters and stats.
> + *
> + * Useful for debugging live systems. The stats are displayed
> + * with runq dumps ('r' on the Xen console).
>    */
> -#define CSCHED_STAT_CRANK(_X)               (perfc_incr(_X))
> +#ifdef SCHED_STATS
>
> -#ifdef CSCHED_STATS
> +#define CSCHED_STATS
>
> -#define CSCHED_VCPU_STATS_RESET(_V)                     \
> +#define SCHED_VCPU_STATS_RESET(_V)                      \
>       do                                                  \
>       {                                                   \
>           memset(&(_V)->stats, 0, sizeof((_V)->stats));   \
>       } while ( 0 )
>
> -#define CSCHED_VCPU_STAT_CRANK(_V, _X)      (((_V)->stats._X)++)
> +#define SCHED_VCPU_STAT_CRANK(_V, _X)       (((_V)->stats._X)++)
>
> -#define CSCHED_VCPU_STAT_SET(_V, _X, _Y)    (((_V)->stats._X) = (_Y))
> +#define SCHED_VCPU_STAT_SET(_V, _X, _Y)     (((_V)->stats._X) = (_Y))
>
> -#else /* CSCHED_STATS */
> +#else /* !SCHED_STATS */
>
> -#define CSCHED_VCPU_STATS_RESET(_V)         do {} while ( 0 )
> -#define CSCHED_VCPU_STAT_CRANK(_V, _X)      do {} while ( 0 )
> -#define CSCHED_VCPU_STAT_SET(_V, _X, _Y)    do {} while ( 0 )
> +#undef CSCHED_STATS
>
> -#endif /* CSCHED_STATS */
> +#define SCHED_VCPU_STATS_RESET(_V)         do {} while ( 0 )
> +#define SCHED_VCPU_STAT_CRANK(_V, _X)      do {} while ( 0 )
> +#define SCHED_VCPU_STAT_SET(_V, _X, _Y)    do {} while ( 0 )
> +
> +#endif /* SCHED_STATS */
>
>
>   /*
> @@ -264,13 +258,13 @@ static inline void
>       if ( new->pri > cur->pri )
>       {
>           if ( cur->pri == CSCHED_PRI_IDLE )
> -            CSCHED_STAT_CRANK(tickle_local_idler);
> +            SCHED_STAT_CRANK(tickle_local_idler);
>           else if ( cur->pri == CSCHED_PRI_TS_OVER )
> -            CSCHED_STAT_CRANK(tickle_local_over);
> +            SCHED_STAT_CRANK(tickle_local_over);
>           else if ( cur->pri == CSCHED_PRI_TS_UNDER )
> -            CSCHED_STAT_CRANK(tickle_local_under);
> +            SCHED_STAT_CRANK(tickle_local_under);
>           else
> -            CSCHED_STAT_CRANK(tickle_local_other);
> +            SCHED_STAT_CRANK(tickle_local_other);
>
>           cpumask_set_cpu(cpu, &mask);
>       }
> @@ -283,7 +277,7 @@ static inline void
>       {
>           if ( cpumask_empty(prv->idlers) )
>           {
> -            CSCHED_STAT_CRANK(tickle_idlers_none);
> +            SCHED_STAT_CRANK(tickle_idlers_none);
>           }
>           else
>           {
> @@ -292,7 +286,7 @@ static inline void
>               cpumask_and(&idle_mask, prv->idlers, new->vcpu->cpu_affinity);
>               if ( !cpumask_empty(&idle_mask) )
>               {
> -                CSCHED_STAT_CRANK(tickle_idlers_some);
> +                SCHED_STAT_CRANK(tickle_idlers_some);
>                   if ( opt_tickle_one_idle )
>                   {
>                       this_cpu(last_tickle_cpu) =
> @@ -404,7 +398,7 @@ static inline void
>           BUG_ON( !is_idle_vcpu(vc) );
>       }
>
> -    CSCHED_STAT_CRANK(vcpu_check);
> +    SCHED_STAT_CRANK(vcpu_check);
>   }
>   #define CSCHED_VCPU_CHECK(_vc)  (__csched_vcpu_check(_vc))
>   #else
> @@ -437,7 +431,7 @@ static inline int
>                  ((uint64_t)vcpu_migration_delay * 1000u));
>
>       if ( hot )
> -        CSCHED_STAT_CRANK(vcpu_hot);
> +        SCHED_STAT_CRANK(vcpu_hot);
>
>       return hot;
>   }
> @@ -559,8 +553,8 @@ static inline void
>
>       if ( list_empty(&svc->active_vcpu_elem) )
>       {
> -        CSCHED_VCPU_STAT_CRANK(svc, state_active);
> -        CSCHED_STAT_CRANK(acct_vcpu_active);
> +        SCHED_VCPU_STAT_CRANK(svc, state_active);
> +        SCHED_STAT_CRANK(acct_vcpu_active);
>
>           sdom->active_vcpu_count++;
>           list_add(&svc->active_vcpu_elem, &sdom->active_vcpu);
> @@ -583,8 +577,8 @@ static inline void
>
>       BUG_ON( list_empty(&svc->active_vcpu_elem) );
>
> -    CSCHED_VCPU_STAT_CRANK(svc, state_idle);
> -    CSCHED_STAT_CRANK(acct_vcpu_idle);
> +    SCHED_VCPU_STAT_CRANK(svc, state_idle);
> +    SCHED_STAT_CRANK(acct_vcpu_idle);
>
>       BUG_ON( prv->weight < sdom->weight );
>       sdom->active_vcpu_count--;
> @@ -633,8 +627,8 @@ csched_vcpu_acct(struct csched_private *
>       }
>       else if ( _csched_cpu_pick(ops, current, 0) != cpu )
>       {
> -        CSCHED_VCPU_STAT_CRANK(svc, migrate_r);
> -        CSCHED_STAT_CRANK(migrate_running);
> +        SCHED_VCPU_STAT_CRANK(svc, migrate_r);
> +        SCHED_STAT_CRANK(migrate_running);
>           set_bit(_VPF_migrating, ¤t->pause_flags);
>           cpu_raise_softirq(cpu, SCHEDULE_SOFTIRQ);
>       }
> @@ -658,8 +652,8 @@ csched_alloc_vdata(const struct schedule
>       svc->flags = 0U;
>       svc->pri = is_idle_domain(vc->domain) ?
>           CSCHED_PRI_IDLE : CSCHED_PRI_TS_UNDER;
> -    CSCHED_VCPU_STATS_RESET(svc);
> -    CSCHED_STAT_CRANK(vcpu_init);
> +    SCHED_VCPU_STATS_RESET(svc);
> +    SCHED_STAT_CRANK(vcpu_init);
>       return svc;
>   }
>
> @@ -690,7 +684,7 @@ csched_vcpu_remove(const struct schedule
>       struct csched_dom * const sdom = svc->sdom;
>       unsigned long flags;
>
> -    CSCHED_STAT_CRANK(vcpu_destroy);
> +    SCHED_STAT_CRANK(vcpu_destroy);
>
>       if ( __vcpu_on_runq(svc) )
>           __runq_remove(svc);
> @@ -711,7 +705,7 @@ csched_vcpu_sleep(const struct scheduler
>   {
>       struct csched_vcpu * const svc = CSCHED_VCPU(vc);
>
> -    CSCHED_STAT_CRANK(vcpu_sleep);
> +    SCHED_STAT_CRANK(vcpu_sleep);
>
>       BUG_ON( is_idle_vcpu(vc) );
>
> @@ -731,19 +725,19 @@ csched_vcpu_wake(const struct scheduler
>
>       if ( unlikely(per_cpu(schedule_data, cpu).curr == vc) )
>       {
> -        CSCHED_STAT_CRANK(vcpu_wake_running);
> +        SCHED_STAT_CRANK(vcpu_wake_running);
>           return;
>       }
>       if ( unlikely(__vcpu_on_runq(svc)) )
>       {
> -        CSCHED_STAT_CRANK(vcpu_wake_onrunq);
> +        SCHED_STAT_CRANK(vcpu_wake_onrunq);
>           return;
>       }
>
>       if ( likely(vcpu_runnable(vc)) )
> -        CSCHED_STAT_CRANK(vcpu_wake_runnable);
> +        SCHED_STAT_CRANK(vcpu_wake_runnable);
>       else
> -        CSCHED_STAT_CRANK(vcpu_wake_not_runnable);
> +        SCHED_STAT_CRANK(vcpu_wake_not_runnable);
>
>       /*
>        * We temporarly boost the priority of awaking VCPUs!
> @@ -883,8 +877,6 @@ csched_dom_init(const struct scheduler *
>   {
>       struct csched_dom *sdom;
>
> -    CSCHED_STAT_CRANK(dom_init);
> -
>       if ( is_idle_domain(dom) )
>           return 0;
>
> @@ -906,7 +898,6 @@ csched_free_domdata(const struct schedul
>   static void
>   csched_dom_destroy(const struct scheduler *ops, struct domain *dom)
>   {
> -    CSCHED_STAT_CRANK(dom_destroy);
>       csched_free_domdata(ops, CSCHED_DOM(dom));
>   }
>
> @@ -989,18 +980,18 @@ csched_acct(void* dummy)
>       if ( prv->credit_balance < 0 )
>       {
>           credit_total -= prv->credit_balance;
> -        CSCHED_STAT_CRANK(acct_balance);
> +        SCHED_STAT_CRANK(acct_balance);
>       }
>
>       if ( unlikely(weight_total == 0) )
>       {
>           prv->credit_balance = 0;
>           spin_unlock_irqrestore(&prv->lock, flags);
> -        CSCHED_STAT_CRANK(acct_no_work);
> +        SCHED_STAT_CRANK(acct_no_work);
>           goto out;
>       }
>
> -    CSCHED_STAT_CRANK(acct_run);
> +    SCHED_STAT_CRANK(acct_run);
>
>       weight_left = weight_total;
>       credit_balance = 0;
> @@ -1075,7 +1066,7 @@ csched_acct(void* dummy)
>                    * the queue to give others a chance at them in future
>                    * accounting periods.
>                    */
> -                CSCHED_STAT_CRANK(acct_reorder);
> +                SCHED_STAT_CRANK(acct_reorder);
>                   list_del(&sdom->active_sdom_elem);
>                   list_add(&sdom->active_sdom_elem, &prv->active_sdom);
>               }
> @@ -1110,7 +1101,7 @@ csched_acct(void* dummy)
>                        credit < -credit_cap &&
>                        !(svc->flags & CSCHED_FLAG_VCPU_PARKED) )
>                   {
> -                    CSCHED_STAT_CRANK(vcpu_park);
> +                    SCHED_STAT_CRANK(vcpu_park);
>                       vcpu_pause_nosync(svc->vcpu);
>                       svc->flags |= CSCHED_FLAG_VCPU_PARKED;
>                   }
> @@ -1118,7 +1109,7 @@ csched_acct(void* dummy)
>                   /* Lower bound on credits */
>                   if ( credit < -prv->credits_per_tslice )
>                   {
> -                    CSCHED_STAT_CRANK(acct_min_credit);
> +                    SCHED_STAT_CRANK(acct_min_credit);
>                       credit = -prv->credits_per_tslice;
>                       atomic_set(&svc->credit, credit);
>                   }
> @@ -1135,7 +1126,7 @@ csched_acct(void* dummy)
>                        * call to make sure the VCPU's priority is not boosted
>                        * if it is woken up here.
>                        */
> -                    CSCHED_STAT_CRANK(vcpu_unpark);
> +                    SCHED_STAT_CRANK(vcpu_unpark);
>                       vcpu_unpause(svc->vcpu);
>                       svc->flags &= ~CSCHED_FLAG_VCPU_PARKED;
>                   }
> @@ -1151,8 +1142,8 @@ csched_acct(void* dummy)
>                   }
>               }
>
> -            CSCHED_VCPU_STAT_SET(svc, credit_last, credit);
> -            CSCHED_VCPU_STAT_SET(svc, credit_incr, credit_fair);
> +            SCHED_VCPU_STAT_SET(svc, credit_last, credit);
> +            SCHED_VCPU_STAT_SET(svc, credit_incr, credit_fair);
>               credit_balance += credit;
>           }
>       }
> @@ -1229,8 +1220,8 @@ csched_runq_steal(int peer_cpu, int cpu,
>               if (__csched_vcpu_is_migrateable(vc, cpu))
>               {
>                   /* We got a candidate. Grab it! */
> -                CSCHED_VCPU_STAT_CRANK(speer, migrate_q);
> -                CSCHED_STAT_CRANK(migrate_queued);
> +                SCHED_VCPU_STAT_CRANK(speer, migrate_q);
> +                SCHED_STAT_CRANK(migrate_queued);
>                   WARN_ON(vc->is_urgent);
>                   __runq_remove(speer);
>                   vc->processor = cpu;
> @@ -1239,7 +1230,7 @@ csched_runq_steal(int peer_cpu, int cpu,
>           }
>       }
>
> -    CSCHED_STAT_CRANK(steal_peer_idle);
> +    SCHED_STAT_CRANK(steal_peer_idle);
>       return NULL;
>   }
>
> @@ -1260,11 +1251,11 @@ csched_load_balance(struct csched_privat
>           goto out;
>
>       if ( snext->pri == CSCHED_PRI_IDLE )
> -        CSCHED_STAT_CRANK(load_balance_idle);
> +        SCHED_STAT_CRANK(load_balance_idle);
>       else if ( snext->pri == CSCHED_PRI_TS_OVER )
> -        CSCHED_STAT_CRANK(load_balance_over);
> +        SCHED_STAT_CRANK(load_balance_over);
>       else
> -        CSCHED_STAT_CRANK(load_balance_other);
> +        SCHED_STAT_CRANK(load_balance_other);
>
>       /*
>        * Peek at non-idling CPUs in the system, starting with our
> @@ -1288,7 +1279,7 @@ csched_load_balance(struct csched_privat
>            */
>           if ( !pcpu_schedule_trylock(peer_cpu) )
>           {
> -            CSCHED_STAT_CRANK(steal_trylock_failed);
> +            SCHED_STAT_CRANK(steal_trylock_failed);
>               continue;
>           }
>
> @@ -1327,7 +1318,7 @@ csched_schedule(
>       struct task_slice ret;
>       s_time_t runtime, tslice;
>
> -    CSCHED_STAT_CRANK(schedule);
> +    SCHED_STAT_CRANK(schedule);
>       CSCHED_VCPU_CHECK(current);
>
>       runtime = now - current->runstate.state_entry_time;
> diff --git a/xen/common/schedule.c b/xen/common/schedule.c
> --- a/xen/common/schedule.c
> +++ b/xen/common/schedule.c
> @@ -314,11 +314,14 @@ int sched_init_domain(struct domain *d)
>   {
>       printk("%s: Initializing domain %d\n", __func__, d->domain_id);
>
> +    SCHED_STAT_CRANK(dom_init);
> +
>       return SCHED_OP(DOM2OP(d), init_domain, d);
>   }
>
>   void sched_destroy_domain(struct domain *d)
>   {
> +    SCHED_STAT_CRANK(dom_destroy);
>       SCHED_OP(DOM2OP(d), destroy_domain, d);
>   }
>
> @@ -1086,7 +1089,7 @@ static void schedule(void)
>
>       ASSERT(!in_atomic());
>
> -    perfc_incr(sched_run);
> +    SCHED_STAT_CRANK(sched_run);
>
>       sd = &this_cpu(schedule_data);
>
> @@ -1164,7 +1167,7 @@ static void schedule(void)
>
>       pcpu_schedule_unlock_irq(cpu);
>
> -    perfc_incr(sched_ctx);
> +    SCHED_STAT_CRANK(sched_ctx);
>
>       stop_timer(&prev->periodic_timer);
>
> @@ -1198,7 +1201,7 @@ void context_saved(struct vcpu *prev)
>   static void s_timer_fn(void *unused)
>   {
>       raise_softirq(SCHEDULE_SOFTIRQ);
> -    perfc_incr(sched_irq);
> +    SCHED_STAT_CRANK(sched_irq);
>   }
>
>   /* Per-VCPU periodic timer function: sends a virtual timer interrupt. */
> diff --git a/xen/include/xen/perfc_defn.h b/xen/include/xen/perfc_defn.h
> --- a/xen/include/xen/perfc_defn.h
> +++ b/xen/include/xen/perfc_defn.h
> @@ -12,13 +12,19 @@ PERFCOUNTER(calls_from_multicall,
>   PERFCOUNTER(irqs,                   "#interrupts")
>   PERFCOUNTER(ipis,                   "#IPIs")
>
> +/* Generic scheduler counters (applicable to all schedulers) */
>   PERFCOUNTER(sched_irq,              "sched: timer")
>   PERFCOUNTER(sched_run,              "sched: runs through scheduler")
>   PERFCOUNTER(sched_ctx,              "sched: context switches")
> +PERFCOUNTER(schedule,               "sched: specific scheduler")
> +PERFCOUNTER(dom_init,               "sched: dom_init")
> +PERFCOUNTER(dom_destroy,            "sched: dom_destroy")
> +PERFCOUNTER(vcpu_init,              "sched: vcpu_init")
> +PERFCOUNTER(vcpu_destroy,           "sched: vcpu_destroy")
>
> +/* credit specific counters */
>   PERFCOUNTER(delay_ms,               "csched: delay")
>   PERFCOUNTER(vcpu_check,             "csched: vcpu_check")
> -PERFCOUNTER(schedule,               "csched: schedule")
>   PERFCOUNTER(acct_run,               "csched: acct_run")
>   PERFCOUNTER(acct_no_work,           "csched: acct_no_work")
>   PERFCOUNTER(acct_balance,           "csched: acct_balance")
> @@ -46,10 +52,6 @@ PERFCOUNTER(steal_trylock_failed,   "csc
>   PERFCOUNTER(steal_peer_idle,        "csched: steal_peer_idle")
>   PERFCOUNTER(migrate_queued,         "csched: migrate_queued")
>   PERFCOUNTER(migrate_running,        "csched: migrate_running")
> -PERFCOUNTER(dom_init,               "csched: dom_init")
> -PERFCOUNTER(dom_destroy,            "csched: dom_destroy")
> -PERFCOUNTER(vcpu_init,              "csched: vcpu_init")
> -PERFCOUNTER(vcpu_destroy,           "csched: vcpu_destroy")
>   PERFCOUNTER(vcpu_hot,               "csched: vcpu_hot")
>
>   PERFCOUNTER(need_flush_tlb_flush,   "PG_need_flush tlb flushes")
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -16,6 +16,7 @@
>   #include 
>   #include 
>   #include 
> +#include 
>   #include 
>   #include 
>   #include 
> @@ -29,6 +30,18 @@
>   DEFINE_XEN_GUEST_HANDLE(vcpu_runstate_info_compat_t);
>   #endif
>
> +/*
> + * Stats
> + *
> + * Enable and ease the use of scheduling related performance counters.
> + *
> + */
> +#ifdef PERF_COUNTERS
> +#define SCHED_STATS
> +#endif
> +
> +#define SCHED_STAT_CRANK(_X)                (perfc_incr(_X))
> +
>   /* A global pointer to the initial domain (DOM0). */
>   extern struct domain *dom0;
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 16:28:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 16:28:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQhKb-0004VM-1A; Tue, 23 Oct 2012 16:27:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQhKZ-0004V5-PD
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 16:27:52 +0000
Received: from [85.158.143.35:53504] by server-1.bemta-4.messagelabs.com id
	25/B2-19134-685C6805; Tue, 23 Oct 2012 16:27:50 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1351009668!5544450!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzg0MDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15790 invoked from network); 23 Oct 2012 16:27:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 16:27:50 -0000
X-IronPort-AV: E=Sophos;i="4.80,635,1344211200"; d="scan'208";a="42173567"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Oct 2012 16:27:48 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 23 Oct 2012 12:27:48 -0400
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[0.0.0.0])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TQhKV-0003XF-Fz;
	Tue, 23 Oct 2012 17:27:47 +0100
Message-ID: <5086C582.8080804@eu.citrix.com>
Date: Tue, 23 Oct 2012 17:27:46 +0100
From: George Dunlap 
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Dario Faggioli 
References: 
	
In-Reply-To: 
Cc: Paul Durrant , "Keir \(Xen.org\)" ,
	Jan Beulich ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 3 of 6] xen: sched: generalize scheduling
 related perfcounter macros
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 22/10/12 15:40, Dario Faggioli wrote:
> Moving some of them from sched_credit.c to generic scheduler code.
> This also allows the other schedulers to use perf counters equally
> easy.
>
> This change is mainly preparatory work for what stated above. In fact,
> it mostly does s/CSCHED_STAT/SCHED_STAT/, and, in general, it implies no
> functional changes.
>
> Signed-off-by: Dario Faggioli 
Acked-by: George Dunlap 
>
> diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
> --- a/xen/common/sched_credit.c
> +++ b/xen/common/sched_credit.c
> @@ -16,25 +16,12 @@
>   #include 
>   #include 
>   #include 
> -#include 
>   #include 
>   #include 
>   #include 
>   #include 
>   #include 
>
> -/*
> - * CSCHED_STATS
> - *
> - * Manage very basic per-vCPU counters and stats.
> - *
> - * Useful for debugging live systems. The stats are displayed
> - * with runq dumps ('r' on the Xen console).
> - */
> -#ifdef PERF_COUNTERS
> -#define CSCHED_STATS
> -#endif
> -
>
>   /*
>    * Basic constants
> @@ -75,29 +62,36 @@
>
>
>   /*
> - * Stats
> + * CSCHED_STATS
> + *
> + * Manage very basic per-vCPU counters and stats.
> + *
> + * Useful for debugging live systems. The stats are displayed
> + * with runq dumps ('r' on the Xen console).
>    */
> -#define CSCHED_STAT_CRANK(_X)               (perfc_incr(_X))
> +#ifdef SCHED_STATS
>
> -#ifdef CSCHED_STATS
> +#define CSCHED_STATS
>
> -#define CSCHED_VCPU_STATS_RESET(_V)                     \
> +#define SCHED_VCPU_STATS_RESET(_V)                      \
>       do                                                  \
>       {                                                   \
>           memset(&(_V)->stats, 0, sizeof((_V)->stats));   \
>       } while ( 0 )
>
> -#define CSCHED_VCPU_STAT_CRANK(_V, _X)      (((_V)->stats._X)++)
> +#define SCHED_VCPU_STAT_CRANK(_V, _X)       (((_V)->stats._X)++)
>
> -#define CSCHED_VCPU_STAT_SET(_V, _X, _Y)    (((_V)->stats._X) = (_Y))
> +#define SCHED_VCPU_STAT_SET(_V, _X, _Y)     (((_V)->stats._X) = (_Y))
>
> -#else /* CSCHED_STATS */
> +#else /* !SCHED_STATS */
>
> -#define CSCHED_VCPU_STATS_RESET(_V)         do {} while ( 0 )
> -#define CSCHED_VCPU_STAT_CRANK(_V, _X)      do {} while ( 0 )
> -#define CSCHED_VCPU_STAT_SET(_V, _X, _Y)    do {} while ( 0 )
> +#undef CSCHED_STATS
>
> -#endif /* CSCHED_STATS */
> +#define SCHED_VCPU_STATS_RESET(_V)         do {} while ( 0 )
> +#define SCHED_VCPU_STAT_CRANK(_V, _X)      do {} while ( 0 )
> +#define SCHED_VCPU_STAT_SET(_V, _X, _Y)    do {} while ( 0 )
> +
> +#endif /* SCHED_STATS */
>
>
>   /*
> @@ -264,13 +258,13 @@ static inline void
>       if ( new->pri > cur->pri )
>       {
>           if ( cur->pri == CSCHED_PRI_IDLE )
> -            CSCHED_STAT_CRANK(tickle_local_idler);
> +            SCHED_STAT_CRANK(tickle_local_idler);
>           else if ( cur->pri == CSCHED_PRI_TS_OVER )
> -            CSCHED_STAT_CRANK(tickle_local_over);
> +            SCHED_STAT_CRANK(tickle_local_over);
>           else if ( cur->pri == CSCHED_PRI_TS_UNDER )
> -            CSCHED_STAT_CRANK(tickle_local_under);
> +            SCHED_STAT_CRANK(tickle_local_under);
>           else
> -            CSCHED_STAT_CRANK(tickle_local_other);
> +            SCHED_STAT_CRANK(tickle_local_other);
>
>           cpumask_set_cpu(cpu, &mask);
>       }
> @@ -283,7 +277,7 @@ static inline void
>       {
>           if ( cpumask_empty(prv->idlers) )
>           {
> -            CSCHED_STAT_CRANK(tickle_idlers_none);
> +            SCHED_STAT_CRANK(tickle_idlers_none);
>           }
>           else
>           {
> @@ -292,7 +286,7 @@ static inline void
>               cpumask_and(&idle_mask, prv->idlers, new->vcpu->cpu_affinity);
>               if ( !cpumask_empty(&idle_mask) )
>               {
> -                CSCHED_STAT_CRANK(tickle_idlers_some);
> +                SCHED_STAT_CRANK(tickle_idlers_some);
>                   if ( opt_tickle_one_idle )
>                   {
>                       this_cpu(last_tickle_cpu) =
> @@ -404,7 +398,7 @@ static inline void
>           BUG_ON( !is_idle_vcpu(vc) );
>       }
>
> -    CSCHED_STAT_CRANK(vcpu_check);
> +    SCHED_STAT_CRANK(vcpu_check);
>   }
>   #define CSCHED_VCPU_CHECK(_vc)  (__csched_vcpu_check(_vc))
>   #else
> @@ -437,7 +431,7 @@ static inline int
>                  ((uint64_t)vcpu_migration_delay * 1000u));
>
>       if ( hot )
> -        CSCHED_STAT_CRANK(vcpu_hot);
> +        SCHED_STAT_CRANK(vcpu_hot);
>
>       return hot;
>   }
> @@ -559,8 +553,8 @@ static inline void
>
>       if ( list_empty(&svc->active_vcpu_elem) )
>       {
> -        CSCHED_VCPU_STAT_CRANK(svc, state_active);
> -        CSCHED_STAT_CRANK(acct_vcpu_active);
> +        SCHED_VCPU_STAT_CRANK(svc, state_active);
> +        SCHED_STAT_CRANK(acct_vcpu_active);
>
>           sdom->active_vcpu_count++;
>           list_add(&svc->active_vcpu_elem, &sdom->active_vcpu);
> @@ -583,8 +577,8 @@ static inline void
>
>       BUG_ON( list_empty(&svc->active_vcpu_elem) );
>
> -    CSCHED_VCPU_STAT_CRANK(svc, state_idle);
> -    CSCHED_STAT_CRANK(acct_vcpu_idle);
> +    SCHED_VCPU_STAT_CRANK(svc, state_idle);
> +    SCHED_STAT_CRANK(acct_vcpu_idle);
>
>       BUG_ON( prv->weight < sdom->weight );
>       sdom->active_vcpu_count--;
> @@ -633,8 +627,8 @@ csched_vcpu_acct(struct csched_private *
>       }
>       else if ( _csched_cpu_pick(ops, current, 0) != cpu )
>       {
> -        CSCHED_VCPU_STAT_CRANK(svc, migrate_r);
> -        CSCHED_STAT_CRANK(migrate_running);
> +        SCHED_VCPU_STAT_CRANK(svc, migrate_r);
> +        SCHED_STAT_CRANK(migrate_running);
>           set_bit(_VPF_migrating, ¤t->pause_flags);
>           cpu_raise_softirq(cpu, SCHEDULE_SOFTIRQ);
>       }
> @@ -658,8 +652,8 @@ csched_alloc_vdata(const struct schedule
>       svc->flags = 0U;
>       svc->pri = is_idle_domain(vc->domain) ?
>           CSCHED_PRI_IDLE : CSCHED_PRI_TS_UNDER;
> -    CSCHED_VCPU_STATS_RESET(svc);
> -    CSCHED_STAT_CRANK(vcpu_init);
> +    SCHED_VCPU_STATS_RESET(svc);
> +    SCHED_STAT_CRANK(vcpu_init);
>       return svc;
>   }
>
> @@ -690,7 +684,7 @@ csched_vcpu_remove(const struct schedule
>       struct csched_dom * const sdom = svc->sdom;
>       unsigned long flags;
>
> -    CSCHED_STAT_CRANK(vcpu_destroy);
> +    SCHED_STAT_CRANK(vcpu_destroy);
>
>       if ( __vcpu_on_runq(svc) )
>           __runq_remove(svc);
> @@ -711,7 +705,7 @@ csched_vcpu_sleep(const struct scheduler
>   {
>       struct csched_vcpu * const svc = CSCHED_VCPU(vc);
>
> -    CSCHED_STAT_CRANK(vcpu_sleep);
> +    SCHED_STAT_CRANK(vcpu_sleep);
>
>       BUG_ON( is_idle_vcpu(vc) );
>
> @@ -731,19 +725,19 @@ csched_vcpu_wake(const struct scheduler
>
>       if ( unlikely(per_cpu(schedule_data, cpu).curr == vc) )
>       {
> -        CSCHED_STAT_CRANK(vcpu_wake_running);
> +        SCHED_STAT_CRANK(vcpu_wake_running);
>           return;
>       }
>       if ( unlikely(__vcpu_on_runq(svc)) )
>       {
> -        CSCHED_STAT_CRANK(vcpu_wake_onrunq);
> +        SCHED_STAT_CRANK(vcpu_wake_onrunq);
>           return;
>       }
>
>       if ( likely(vcpu_runnable(vc)) )
> -        CSCHED_STAT_CRANK(vcpu_wake_runnable);
> +        SCHED_STAT_CRANK(vcpu_wake_runnable);
>       else
> -        CSCHED_STAT_CRANK(vcpu_wake_not_runnable);
> +        SCHED_STAT_CRANK(vcpu_wake_not_runnable);
>
>       /*
>        * We temporarly boost the priority of awaking VCPUs!
> @@ -883,8 +877,6 @@ csched_dom_init(const struct scheduler *
>   {
>       struct csched_dom *sdom;
>
> -    CSCHED_STAT_CRANK(dom_init);
> -
>       if ( is_idle_domain(dom) )
>           return 0;
>
> @@ -906,7 +898,6 @@ csched_free_domdata(const struct schedul
>   static void
>   csched_dom_destroy(const struct scheduler *ops, struct domain *dom)
>   {
> -    CSCHED_STAT_CRANK(dom_destroy);
>       csched_free_domdata(ops, CSCHED_DOM(dom));
>   }
>
> @@ -989,18 +980,18 @@ csched_acct(void* dummy)
>       if ( prv->credit_balance < 0 )
>       {
>           credit_total -= prv->credit_balance;
> -        CSCHED_STAT_CRANK(acct_balance);
> +        SCHED_STAT_CRANK(acct_balance);
>       }
>
>       if ( unlikely(weight_total == 0) )
>       {
>           prv->credit_balance = 0;
>           spin_unlock_irqrestore(&prv->lock, flags);
> -        CSCHED_STAT_CRANK(acct_no_work);
> +        SCHED_STAT_CRANK(acct_no_work);
>           goto out;
>       }
>
> -    CSCHED_STAT_CRANK(acct_run);
> +    SCHED_STAT_CRANK(acct_run);
>
>       weight_left = weight_total;
>       credit_balance = 0;
> @@ -1075,7 +1066,7 @@ csched_acct(void* dummy)
>                    * the queue to give others a chance at them in future
>                    * accounting periods.
>                    */
> -                CSCHED_STAT_CRANK(acct_reorder);
> +                SCHED_STAT_CRANK(acct_reorder);
>                   list_del(&sdom->active_sdom_elem);
>                   list_add(&sdom->active_sdom_elem, &prv->active_sdom);
>               }
> @@ -1110,7 +1101,7 @@ csched_acct(void* dummy)
>                        credit < -credit_cap &&
>                        !(svc->flags & CSCHED_FLAG_VCPU_PARKED) )
>                   {
> -                    CSCHED_STAT_CRANK(vcpu_park);
> +                    SCHED_STAT_CRANK(vcpu_park);
>                       vcpu_pause_nosync(svc->vcpu);
>                       svc->flags |= CSCHED_FLAG_VCPU_PARKED;
>                   }
> @@ -1118,7 +1109,7 @@ csched_acct(void* dummy)
>                   /* Lower bound on credits */
>                   if ( credit < -prv->credits_per_tslice )
>                   {
> -                    CSCHED_STAT_CRANK(acct_min_credit);
> +                    SCHED_STAT_CRANK(acct_min_credit);
>                       credit = -prv->credits_per_tslice;
>                       atomic_set(&svc->credit, credit);
>                   }
> @@ -1135,7 +1126,7 @@ csched_acct(void* dummy)
>                        * call to make sure the VCPU's priority is not boosted
>                        * if it is woken up here.
>                        */
> -                    CSCHED_STAT_CRANK(vcpu_unpark);
> +                    SCHED_STAT_CRANK(vcpu_unpark);
>                       vcpu_unpause(svc->vcpu);
>                       svc->flags &= ~CSCHED_FLAG_VCPU_PARKED;
>                   }
> @@ -1151,8 +1142,8 @@ csched_acct(void* dummy)
>                   }
>               }
>
> -            CSCHED_VCPU_STAT_SET(svc, credit_last, credit);
> -            CSCHED_VCPU_STAT_SET(svc, credit_incr, credit_fair);
> +            SCHED_VCPU_STAT_SET(svc, credit_last, credit);
> +            SCHED_VCPU_STAT_SET(svc, credit_incr, credit_fair);
>               credit_balance += credit;
>           }
>       }
> @@ -1229,8 +1220,8 @@ csched_runq_steal(int peer_cpu, int cpu,
>               if (__csched_vcpu_is_migrateable(vc, cpu))
>               {
>                   /* We got a candidate. Grab it! */
> -                CSCHED_VCPU_STAT_CRANK(speer, migrate_q);
> -                CSCHED_STAT_CRANK(migrate_queued);
> +                SCHED_VCPU_STAT_CRANK(speer, migrate_q);
> +                SCHED_STAT_CRANK(migrate_queued);
>                   WARN_ON(vc->is_urgent);
>                   __runq_remove(speer);
>                   vc->processor = cpu;
> @@ -1239,7 +1230,7 @@ csched_runq_steal(int peer_cpu, int cpu,
>           }
>       }
>
> -    CSCHED_STAT_CRANK(steal_peer_idle);
> +    SCHED_STAT_CRANK(steal_peer_idle);
>       return NULL;
>   }
>
> @@ -1260,11 +1251,11 @@ csched_load_balance(struct csched_privat
>           goto out;
>
>       if ( snext->pri == CSCHED_PRI_IDLE )
> -        CSCHED_STAT_CRANK(load_balance_idle);
> +        SCHED_STAT_CRANK(load_balance_idle);
>       else if ( snext->pri == CSCHED_PRI_TS_OVER )
> -        CSCHED_STAT_CRANK(load_balance_over);
> +        SCHED_STAT_CRANK(load_balance_over);
>       else
> -        CSCHED_STAT_CRANK(load_balance_other);
> +        SCHED_STAT_CRANK(load_balance_other);
>
>       /*
>        * Peek at non-idling CPUs in the system, starting with our
> @@ -1288,7 +1279,7 @@ csched_load_balance(struct csched_privat
>            */
>           if ( !pcpu_schedule_trylock(peer_cpu) )
>           {
> -            CSCHED_STAT_CRANK(steal_trylock_failed);
> +            SCHED_STAT_CRANK(steal_trylock_failed);
>               continue;
>           }
>
> @@ -1327,7 +1318,7 @@ csched_schedule(
>       struct task_slice ret;
>       s_time_t runtime, tslice;
>
> -    CSCHED_STAT_CRANK(schedule);
> +    SCHED_STAT_CRANK(schedule);
>       CSCHED_VCPU_CHECK(current);
>
>       runtime = now - current->runstate.state_entry_time;
> diff --git a/xen/common/schedule.c b/xen/common/schedule.c
> --- a/xen/common/schedule.c
> +++ b/xen/common/schedule.c
> @@ -314,11 +314,14 @@ int sched_init_domain(struct domain *d)
>   {
>       printk("%s: Initializing domain %d\n", __func__, d->domain_id);
>
> +    SCHED_STAT_CRANK(dom_init);
> +
>       return SCHED_OP(DOM2OP(d), init_domain, d);
>   }
>
>   void sched_destroy_domain(struct domain *d)
>   {
> +    SCHED_STAT_CRANK(dom_destroy);
>       SCHED_OP(DOM2OP(d), destroy_domain, d);
>   }
>
> @@ -1086,7 +1089,7 @@ static void schedule(void)
>
>       ASSERT(!in_atomic());
>
> -    perfc_incr(sched_run);
> +    SCHED_STAT_CRANK(sched_run);
>
>       sd = &this_cpu(schedule_data);
>
> @@ -1164,7 +1167,7 @@ static void schedule(void)
>
>       pcpu_schedule_unlock_irq(cpu);
>
> -    perfc_incr(sched_ctx);
> +    SCHED_STAT_CRANK(sched_ctx);
>
>       stop_timer(&prev->periodic_timer);
>
> @@ -1198,7 +1201,7 @@ void context_saved(struct vcpu *prev)
>   static void s_timer_fn(void *unused)
>   {
>       raise_softirq(SCHEDULE_SOFTIRQ);
> -    perfc_incr(sched_irq);
> +    SCHED_STAT_CRANK(sched_irq);
>   }
>
>   /* Per-VCPU periodic timer function: sends a virtual timer interrupt. */
> diff --git a/xen/include/xen/perfc_defn.h b/xen/include/xen/perfc_defn.h
> --- a/xen/include/xen/perfc_defn.h
> +++ b/xen/include/xen/perfc_defn.h
> @@ -12,13 +12,19 @@ PERFCOUNTER(calls_from_multicall,
>   PERFCOUNTER(irqs,                   "#interrupts")
>   PERFCOUNTER(ipis,                   "#IPIs")
>
> +/* Generic scheduler counters (applicable to all schedulers) */
>   PERFCOUNTER(sched_irq,              "sched: timer")
>   PERFCOUNTER(sched_run,              "sched: runs through scheduler")
>   PERFCOUNTER(sched_ctx,              "sched: context switches")
> +PERFCOUNTER(schedule,               "sched: specific scheduler")
> +PERFCOUNTER(dom_init,               "sched: dom_init")
> +PERFCOUNTER(dom_destroy,            "sched: dom_destroy")
> +PERFCOUNTER(vcpu_init,              "sched: vcpu_init")
> +PERFCOUNTER(vcpu_destroy,           "sched: vcpu_destroy")
>
> +/* credit specific counters */
>   PERFCOUNTER(delay_ms,               "csched: delay")
>   PERFCOUNTER(vcpu_check,             "csched: vcpu_check")
> -PERFCOUNTER(schedule,               "csched: schedule")
>   PERFCOUNTER(acct_run,               "csched: acct_run")
>   PERFCOUNTER(acct_no_work,           "csched: acct_no_work")
>   PERFCOUNTER(acct_balance,           "csched: acct_balance")
> @@ -46,10 +52,6 @@ PERFCOUNTER(steal_trylock_failed,   "csc
>   PERFCOUNTER(steal_peer_idle,        "csched: steal_peer_idle")
>   PERFCOUNTER(migrate_queued,         "csched: migrate_queued")
>   PERFCOUNTER(migrate_running,        "csched: migrate_running")
> -PERFCOUNTER(dom_init,               "csched: dom_init")
> -PERFCOUNTER(dom_destroy,            "csched: dom_destroy")
> -PERFCOUNTER(vcpu_init,              "csched: vcpu_init")
> -PERFCOUNTER(vcpu_destroy,           "csched: vcpu_destroy")
>   PERFCOUNTER(vcpu_hot,               "csched: vcpu_hot")
>
>   PERFCOUNTER(need_flush_tlb_flush,   "PG_need_flush tlb flushes")
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -16,6 +16,7 @@
>   #include 
>   #include 
>   #include 
> +#include 
>   #include 
>   #include 
>   #include 
> @@ -29,6 +30,18 @@
>   DEFINE_XEN_GUEST_HANDLE(vcpu_runstate_info_compat_t);
>   #endif
>
> +/*
> + * Stats
> + *
> + * Enable and ease the use of scheduling related performance counters.
> + *
> + */
> +#ifdef PERF_COUNTERS
> +#define SCHED_STATS
> +#endif
> +
> +#define SCHED_STAT_CRANK(_X)                (perfc_incr(_X))
> +
>   /* A global pointer to the initial domain (DOM0). */
>   extern struct domain *dom0;
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 16:28:48 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 16:28:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQhL5-0004Yp-Kt; Tue, 23 Oct 2012 16:28:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQhL3-0004Ya-QV
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 16:28:21 +0000
Received: from [85.158.143.99:32524] by server-1.bemta-4.messagelabs.com id
	74/63-19134-4A5C6805; Tue, 23 Oct 2012 16:28:20 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1351009699!29951494!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODQzOTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8177 invoked from network); 23 Oct 2012 16:28:20 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 16:28:20 -0000
X-IronPort-AV: E=Sophos;i="4.80,635,1344211200"; d="scan'208";a="212197351"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Oct 2012 16:28:18 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 23 Oct 2012 12:28:18 -0400
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[0.0.0.0])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TQhL0-0003YH-49;
	Tue, 23 Oct 2012 17:28:18 +0100
Message-ID: <5086C5A1.9040003@eu.citrix.com>
Date: Tue, 23 Oct 2012 17:28:17 +0100
From: George Dunlap 
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Dario Faggioli 
References: 
	
In-Reply-To: 
Cc: Paul Durrant , "Keir \(Xen.org\)" ,
	Jan Beulich ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 4 of 6] xen: sched: introduce a couple of
 counters in credit2 and SEDF
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 22/10/12 15:40, Dario Faggioli wrote:
> Mainly for consistency with credit, at least for the events that are
> general enough, like vCPU initialization/destruction and calls
> to the specific scheduling function.
>
> Signed-off-by: Dario Faggioli 
Acked-by: George Dunlap 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 16:28:48 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 16:28:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQhL5-0004Yp-Kt; Tue, 23 Oct 2012 16:28:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQhL3-0004Ya-QV
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 16:28:21 +0000
Received: from [85.158.143.99:32524] by server-1.bemta-4.messagelabs.com id
	74/63-19134-4A5C6805; Tue, 23 Oct 2012 16:28:20 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1351009699!29951494!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODQzOTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8177 invoked from network); 23 Oct 2012 16:28:20 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 16:28:20 -0000
X-IronPort-AV: E=Sophos;i="4.80,635,1344211200"; d="scan'208";a="212197351"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Oct 2012 16:28:18 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 23 Oct 2012 12:28:18 -0400
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[0.0.0.0])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TQhL0-0003YH-49;
	Tue, 23 Oct 2012 17:28:18 +0100
Message-ID: <5086C5A1.9040003@eu.citrix.com>
Date: Tue, 23 Oct 2012 17:28:17 +0100
From: George Dunlap 
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Dario Faggioli 
References: 
	
In-Reply-To: 
Cc: Paul Durrant , "Keir \(Xen.org\)" ,
	Jan Beulich ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 4 of 6] xen: sched: introduce a couple of
 counters in credit2 and SEDF
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 22/10/12 15:40, Dario Faggioli wrote:
> Mainly for consistency with credit, at least for the events that are
> general enough, like vCPU initialization/destruction and calls
> to the specific scheduling function.
>
> Signed-off-by: Dario Faggioli 
Acked-by: George Dunlap 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 16:31:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 16:31:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQhNx-0004oE-7n; Tue, 23 Oct 2012 16:31:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQhNv-0004o5-JU
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 16:31:19 +0000
Received: from [85.158.143.35:56186] by server-1.bemta-4.messagelabs.com id
	FE/57-19134-656C6805; Tue, 23 Oct 2012 16:31:18 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1351009877!5545140!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODQzOTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29620 invoked from network); 23 Oct 2012 16:31:18 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 16:31:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,635,1344211200"; d="scan'208";a="212197599"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Oct 2012 16:30:16 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 23 Oct 2012 12:30:16 -0400
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[0.0.0.0])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TQhMt-0003Zv-ND;
	Tue, 23 Oct 2012 17:30:15 +0100
Message-ID: <5086C617.9070304@eu.citrix.com>
Date: Tue, 23 Oct 2012 17:30:15 +0100
From: George Dunlap 
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Dario Faggioli 
References: 
	
In-Reply-To: 
Cc: Paul Durrant , "Keir \(Xen.org\)" ,
	Jan Beulich ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 6 of 6] xen: sched_sedf: remove an unused
	stat in SEDF
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 22/10/12 15:40, Dario Faggioli wrote:
> Namely, `short_cont' which is not updated anywhere in the code.
>
> Signed-off-by: Dario Faggioli 
Acked-by: George Dunlap 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 16:31:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 16:31:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQhNx-0004oE-7n; Tue, 23 Oct 2012 16:31:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQhNv-0004o5-JU
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 16:31:19 +0000
Received: from [85.158.143.35:56186] by server-1.bemta-4.messagelabs.com id
	FE/57-19134-656C6805; Tue, 23 Oct 2012 16:31:18 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1351009877!5545140!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODQzOTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29620 invoked from network); 23 Oct 2012 16:31:18 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 16:31:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,635,1344211200"; d="scan'208";a="212197599"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Oct 2012 16:30:16 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 23 Oct 2012 12:30:16 -0400
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[0.0.0.0])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TQhMt-0003Zv-ND;
	Tue, 23 Oct 2012 17:30:15 +0100
Message-ID: <5086C617.9070304@eu.citrix.com>
Date: Tue, 23 Oct 2012 17:30:15 +0100
From: George Dunlap 
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Dario Faggioli 
References: 
	
In-Reply-To: 
Cc: Paul Durrant , "Keir \(Xen.org\)" ,
	Jan Beulich ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 6 of 6] xen: sched_sedf: remove an unused
	stat in SEDF
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 22/10/12 15:40, Dario Faggioli wrote:
> Namely, `short_cont' which is not updated anywhere in the code.
>
> Signed-off-by: Dario Faggioli 
Acked-by: George Dunlap 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 16:33:59 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 16:33:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQhQJ-00053h-VI; Tue, 23 Oct 2012 16:33:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQhQI-00053U-PB
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 16:33:46 +0000
Received: from [85.158.143.35:18323] by server-1.bemta-4.messagelabs.com id
	B7/AA-19134-AE6C6805; Tue, 23 Oct 2012 16:33:46 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1351010025!16444412!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUyMjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7476 invoked from network); 23 Oct 2012 16:33:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 16:33:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,635,1344211200"; 
	d="asc'?scan'208";a="15340412"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Oct 2012 16:33:45 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 23 Oct 2012 17:33:45 +0100
Message-ID: <1351010023.5064.63.camel@Solace>
From: Dario Faggioli 
To: George Dunlap 
Date: Tue, 23 Oct 2012 18:33:43 +0200
In-Reply-To: <5086C544.4070607@eu.citrix.com>
References: 
	<27c4c065efe366a5d761.1350916838@Solace>
	<5086C544.4070607@eu.citrix.com>
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Paul Durrant , "Keir \(Xen.org\)" ,
	Jan Beulich ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 5 of 6] xen: sched_sedf: beautify statisics
	in SEDF
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============6115728464639850279=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6115728464639850279==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-pP/uXTKgcwDsWIH0GN5b"

--=-pP/uXTKgcwDsWIH0GN5b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2012-10-23 at 17:26 +0100, George Dunlap wrote:
> On 22/10/12 15:40, Dario Faggioli wrote:
> > By gathering all the related fields in a struct (as it is being done
> > in credit) and using the macros we now have available. No functional
> > changes involved.
> >
> > Signed-off-by: Dario Faggioli 
>=20
> I'm OK with this as it is, but...
>=20
Ok.

> >   #ifdef SEDF_STATS
> > -    if ( EDOM_INFO(d)->block_time_tot !=3D 0 )
> > -        printk(" pen=3D%"PRIu64"%%", (EDOM_INFO(d)->penalty_time_tot *=
 100) /
> > -               EDOM_INFO(d)->block_time_tot);
> > -    if ( EDOM_INFO(d)->block_tot !=3D 0 )
> > +    if ( EDOM_INFO(d)->stats.block_time_tot !=3D 0 )
> > +        printk(" pen=3D%"PRIu64"%%", (EDOM_INFO(d)->stats.penalty_time=
_tot * 100) /
> > +               EDOM_INFO(d)->stats.block_time_tot);
> > +    if ( EDOM_INFO(d)->stats.block_tot !=3D 0 )
> >           printk("\n   blks=3D%u sh=3D%u (%u%%) (shc=3D%u (%u%%) shex=
=3D%i "\
> >                  "shexsl=3D%i) l=3D%u (%u%%) avg: b=3D%"PRIu64" p=3D%"P=
RIu64"",
> > -               EDOM_INFO(d)->block_tot, EDOM_INFO(d)->short_block_tot,
> > -               (EDOM_INFO(d)->short_block_tot * 100)
> > -               / EDOM_INFO(d)->block_tot, EDOM_INFO(d)->short_cont,
> > -               (EDOM_INFO(d)->short_cont * 100) / EDOM_INFO(d)->block_=
tot,
> > -               EDOM_INFO(d)->pen_extra_blocks,
> > -               EDOM_INFO(d)->pen_extra_slices,
> > -               EDOM_INFO(d)->long_block_tot,
> > -               (EDOM_INFO(d)->long_block_tot * 100) / EDOM_INFO(d)->bl=
ock_tot,
> > -               (EDOM_INFO(d)->block_time_tot) / EDOM_INFO(d)->block_to=
t,
> > -               (EDOM_INFO(d)->penalty_time_tot) / EDOM_INFO(d)->block_=
tot);
> > +               EDOM_INFO(d)->stats.block_tot, EDOM_INFO(d)->stats.shor=
t_block_tot,
> > +               (EDOM_INFO(d)->stats.short_block_tot * 100)
> > +               / EDOM_INFO(d)->stats.block_tot, EDOM_INFO(d)->stats.sh=
ort_cont,
> > +               (EDOM_INFO(d)->stats.short_cont * 100) / EDOM_INFO(d)->=
stats.block_tot,
> > +               EDOM_INFO(d)->stats.pen_extra_blocks,
> > +               EDOM_INFO(d)->stats.pen_extra_slices,
> > +               EDOM_INFO(d)->stats.long_block_tot,
> > +               (EDOM_INFO(d)->stats.long_block_tot * 100) / EDOM_INFO(=
d)->stats.block_tot,
> > +               (EDOM_INFO(d)->stats.block_time_tot) / EDOM_INFO(d)->st=
ats.block_tot,
> > +               (EDOM_INFO(d)->stats.penalty_time_tot) / EDOM_INFO(d)->=
stats.block_tot);
>=20
> ...wouldn't it be even more beautiful to have a macro for reading stats=
=20
> as well?
>=20
> Like I said, it's fine as it is, but since you're looking for beauty, I=
=20
> figured I'd point it out. :-)
>=20
I see what you mean. Again, as you wish.

This code will need some (and quite a bit actually) of attention as soon
as I or someone else get the time to work on it. If you're fine about
taking this as is, I'll make a note to self about the macro (as I agree
it would be nice).

OTOH, if you prefer me to repost the patch, I think I can find 5 mins to
hack it up...

Thanks and Regards,
Dario

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-pP/uXTKgcwDsWIH0GN5b
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlCGxucACgkQk4XaBE3IOsQM6wCfVlCKXgH2+U6Lxwbt8/f+vrBL
SrcAoKkiiqsV7YsUWDp+js6dQfhZuhlm
=ZrA9
-----END PGP SIGNATURE-----

--=-pP/uXTKgcwDsWIH0GN5b--


--===============6115728464639850279==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6115728464639850279==--


From xen-devel-bounces@lists.xen.org Tue Oct 23 16:33:59 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 16:33:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQhQJ-00053h-VI; Tue, 23 Oct 2012 16:33:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQhQI-00053U-PB
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 16:33:46 +0000
Received: from [85.158.143.35:18323] by server-1.bemta-4.messagelabs.com id
	B7/AA-19134-AE6C6805; Tue, 23 Oct 2012 16:33:46 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1351010025!16444412!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUyMjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7476 invoked from network); 23 Oct 2012 16:33:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 16:33:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,635,1344211200"; 
	d="asc'?scan'208";a="15340412"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Oct 2012 16:33:45 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 23 Oct 2012 17:33:45 +0100
Message-ID: <1351010023.5064.63.camel@Solace>
From: Dario Faggioli 
To: George Dunlap 
Date: Tue, 23 Oct 2012 18:33:43 +0200
In-Reply-To: <5086C544.4070607@eu.citrix.com>
References: 
	<27c4c065efe366a5d761.1350916838@Solace>
	<5086C544.4070607@eu.citrix.com>
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Paul Durrant , "Keir \(Xen.org\)" ,
	Jan Beulich ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 5 of 6] xen: sched_sedf: beautify statisics
	in SEDF
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============6115728464639850279=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6115728464639850279==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-pP/uXTKgcwDsWIH0GN5b"

--=-pP/uXTKgcwDsWIH0GN5b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2012-10-23 at 17:26 +0100, George Dunlap wrote:
> On 22/10/12 15:40, Dario Faggioli wrote:
> > By gathering all the related fields in a struct (as it is being done
> > in credit) and using the macros we now have available. No functional
> > changes involved.
> >
> > Signed-off-by: Dario Faggioli 
>=20
> I'm OK with this as it is, but...
>=20
Ok.

> >   #ifdef SEDF_STATS
> > -    if ( EDOM_INFO(d)->block_time_tot !=3D 0 )
> > -        printk(" pen=3D%"PRIu64"%%", (EDOM_INFO(d)->penalty_time_tot *=
 100) /
> > -               EDOM_INFO(d)->block_time_tot);
> > -    if ( EDOM_INFO(d)->block_tot !=3D 0 )
> > +    if ( EDOM_INFO(d)->stats.block_time_tot !=3D 0 )
> > +        printk(" pen=3D%"PRIu64"%%", (EDOM_INFO(d)->stats.penalty_time=
_tot * 100) /
> > +               EDOM_INFO(d)->stats.block_time_tot);
> > +    if ( EDOM_INFO(d)->stats.block_tot !=3D 0 )
> >           printk("\n   blks=3D%u sh=3D%u (%u%%) (shc=3D%u (%u%%) shex=
=3D%i "\
> >                  "shexsl=3D%i) l=3D%u (%u%%) avg: b=3D%"PRIu64" p=3D%"P=
RIu64"",
> > -               EDOM_INFO(d)->block_tot, EDOM_INFO(d)->short_block_tot,
> > -               (EDOM_INFO(d)->short_block_tot * 100)
> > -               / EDOM_INFO(d)->block_tot, EDOM_INFO(d)->short_cont,
> > -               (EDOM_INFO(d)->short_cont * 100) / EDOM_INFO(d)->block_=
tot,
> > -               EDOM_INFO(d)->pen_extra_blocks,
> > -               EDOM_INFO(d)->pen_extra_slices,
> > -               EDOM_INFO(d)->long_block_tot,
> > -               (EDOM_INFO(d)->long_block_tot * 100) / EDOM_INFO(d)->bl=
ock_tot,
> > -               (EDOM_INFO(d)->block_time_tot) / EDOM_INFO(d)->block_to=
t,
> > -               (EDOM_INFO(d)->penalty_time_tot) / EDOM_INFO(d)->block_=
tot);
> > +               EDOM_INFO(d)->stats.block_tot, EDOM_INFO(d)->stats.shor=
t_block_tot,
> > +               (EDOM_INFO(d)->stats.short_block_tot * 100)
> > +               / EDOM_INFO(d)->stats.block_tot, EDOM_INFO(d)->stats.sh=
ort_cont,
> > +               (EDOM_INFO(d)->stats.short_cont * 100) / EDOM_INFO(d)->=
stats.block_tot,
> > +               EDOM_INFO(d)->stats.pen_extra_blocks,
> > +               EDOM_INFO(d)->stats.pen_extra_slices,
> > +               EDOM_INFO(d)->stats.long_block_tot,
> > +               (EDOM_INFO(d)->stats.long_block_tot * 100) / EDOM_INFO(=
d)->stats.block_tot,
> > +               (EDOM_INFO(d)->stats.block_time_tot) / EDOM_INFO(d)->st=
ats.block_tot,
> > +               (EDOM_INFO(d)->stats.penalty_time_tot) / EDOM_INFO(d)->=
stats.block_tot);
>=20
> ...wouldn't it be even more beautiful to have a macro for reading stats=
=20
> as well?
>=20
> Like I said, it's fine as it is, but since you're looking for beauty, I=
=20
> figured I'd point it out. :-)
>=20
I see what you mean. Again, as you wish.

This code will need some (and quite a bit actually) of attention as soon
as I or someone else get the time to work on it. If you're fine about
taking this as is, I'll make a note to self about the macro (as I agree
it would be nice).

OTOH, if you prefer me to repost the patch, I think I can find 5 mins to
hack it up...

Thanks and Regards,
Dario

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-pP/uXTKgcwDsWIH0GN5b
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlCGxucACgkQk4XaBE3IOsQM6wCfVlCKXgH2+U6Lxwbt8/f+vrBL
SrcAoKkiiqsV7YsUWDp+js6dQfhZuhlm
=ZrA9
-----END PGP SIGNATURE-----

--=-pP/uXTKgcwDsWIH0GN5b--


--===============6115728464639850279==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6115728464639850279==--


From xen-devel-bounces@lists.xen.org Tue Oct 23 16:34:51 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 16:34:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQhR8-00059k-DT; Tue, 23 Oct 2012 16:34:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQhR6-00059V-S2
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 16:34:37 +0000
Received: from [85.158.139.211:48846] by server-14.bemta-5.messagelabs.com id
	10/A2-24068-C17C6805; Tue, 23 Oct 2012 16:34:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1351010075!19455611!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUyMjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17329 invoked from network); 23 Oct 2012 16:34:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 16:34:35 -0000
X-IronPort-AV: E=Sophos;i="4.80,635,1344211200"; d="scan'208";a="15340425"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Oct 2012 16:34:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 23 Oct 2012 17:34:35 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TQhR4-0004bA-RI;
	Tue, 23 Oct 2012 16:34:34 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TQhR4-0003Ow-LE;
	Tue, 23 Oct 2012 17:34:34 +0100
To: 
Message-ID: 
From: xen.org 
Date: Tue, 23 Oct 2012 17:34:34 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14070: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14070 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14070/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 14069
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 14069
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 14069
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 14069

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  d642720e1ea9
baseline version:
 xen                  c69bcb248128

------------------------------------------------------------
People who touched revisions under test:
  Christoph Egger 
  Jan Beulich 
  Olaf Hering 
  Tim Deegan 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=d642720e1ea9
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable d642720e1ea9
+ branch=xen-unstable
+ revision=d642720e1ea9
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r d642720e1ea9 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 2 changesets with 2 changes to 1 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 16:34:51 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 16:34:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQhR8-00059k-DT; Tue, 23 Oct 2012 16:34:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQhR6-00059V-S2
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 16:34:37 +0000
Received: from [85.158.139.211:48846] by server-14.bemta-5.messagelabs.com id
	10/A2-24068-C17C6805; Tue, 23 Oct 2012 16:34:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1351010075!19455611!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUyMjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17329 invoked from network); 23 Oct 2012 16:34:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 16:34:35 -0000
X-IronPort-AV: E=Sophos;i="4.80,635,1344211200"; d="scan'208";a="15340425"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Oct 2012 16:34:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 23 Oct 2012 17:34:35 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TQhR4-0004bA-RI;
	Tue, 23 Oct 2012 16:34:34 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TQhR4-0003Ow-LE;
	Tue, 23 Oct 2012 17:34:34 +0100
To: 
Message-ID: 
From: xen.org 
Date: Tue, 23 Oct 2012 17:34:34 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14070: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14070 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14070/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 14069
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 14069
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 14069
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 14069

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  d642720e1ea9
baseline version:
 xen                  c69bcb248128

------------------------------------------------------------
People who touched revisions under test:
  Christoph Egger 
  Jan Beulich 
  Olaf Hering 
  Tim Deegan 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=d642720e1ea9
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable d642720e1ea9
+ branch=xen-unstable
+ revision=d642720e1ea9
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r d642720e1ea9 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 2 changesets with 2 changes to 1 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 16:36:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 16:36:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQhSu-0005K4-Tw; Tue, 23 Oct 2012 16:36:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQhSs-0005Jv-TV
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 16:36:27 +0000
Received: from [85.158.143.99:61116] by server-3.bemta-4.messagelabs.com id
	54/85-03544-A87C6805; Tue, 23 Oct 2012 16:36:26 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1351010183!25635894!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzg0MDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30174 invoked from network); 23 Oct 2012 16:36:24 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 16:36:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,635,1344211200"; d="scan'208";a="42174898"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Oct 2012 16:35:22 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 23 Oct 2012 12:35:22 -0400
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[0.0.0.0])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TQhRq-0003dy-65;
	Tue, 23 Oct 2012 17:35:22 +0100
Message-ID: <5086C747.1090704@eu.citrix.com>
Date: Tue, 23 Oct 2012 17:35:19 +0100
From: George Dunlap 
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Dario Faggioli 
References: 
	<27c4c065efe366a5d761.1350916838@Solace>
	<5086C544.4070607@eu.citrix.com> <1351010023.5064.63.camel@Solace>
In-Reply-To: <1351010023.5064.63.camel@Solace>
Cc: Paul Durrant , "Keir \(Xen.org\)" ,
	Jan Beulich ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 5 of 6] xen: sched_sedf: beautify statisics
	in SEDF
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 23/10/12 17:33, Dario Faggioli wrote:
>>>    #ifdef SEDF_STATS
>>> -    if ( EDOM_INFO(d)->block_time_tot != 0 )
>>> -        printk(" pen=%"PRIu64"%%", (EDOM_INFO(d)->penalty_time_tot * 100) /
>>> -               EDOM_INFO(d)->block_time_tot);
>>> -    if ( EDOM_INFO(d)->block_tot != 0 )
>>> +    if ( EDOM_INFO(d)->stats.block_time_tot != 0 )
>>> +        printk(" pen=%"PRIu64"%%", (EDOM_INFO(d)->stats.penalty_time_tot * 100) /
>>> +               EDOM_INFO(d)->stats.block_time_tot);
>>> +    if ( EDOM_INFO(d)->stats.block_tot != 0 )
>>>            printk("\n   blks=%u sh=%u (%u%%) (shc=%u (%u%%) shex=%i "\
>>>                   "shexsl=%i) l=%u (%u%%) avg: b=%"PRIu64" p=%"PRIu64"",
>>> -               EDOM_INFO(d)->block_tot, EDOM_INFO(d)->short_block_tot,
>>> -               (EDOM_INFO(d)->short_block_tot * 100)
>>> -               / EDOM_INFO(d)->block_tot, EDOM_INFO(d)->short_cont,
>>> -               (EDOM_INFO(d)->short_cont * 100) / EDOM_INFO(d)->block_tot,
>>> -               EDOM_INFO(d)->pen_extra_blocks,
>>> -               EDOM_INFO(d)->pen_extra_slices,
>>> -               EDOM_INFO(d)->long_block_tot,
>>> -               (EDOM_INFO(d)->long_block_tot * 100) / EDOM_INFO(d)->block_tot,
>>> -               (EDOM_INFO(d)->block_time_tot) / EDOM_INFO(d)->block_tot,
>>> -               (EDOM_INFO(d)->penalty_time_tot) / EDOM_INFO(d)->block_tot);
>>> +               EDOM_INFO(d)->stats.block_tot, EDOM_INFO(d)->stats.short_block_tot,
>>> +               (EDOM_INFO(d)->stats.short_block_tot * 100)
>>> +               / EDOM_INFO(d)->stats.block_tot, EDOM_INFO(d)->stats.short_cont,
>>> +               (EDOM_INFO(d)->stats.short_cont * 100) / EDOM_INFO(d)->stats.block_tot,
>>> +               EDOM_INFO(d)->stats.pen_extra_blocks,
>>> +               EDOM_INFO(d)->stats.pen_extra_slices,
>>> +               EDOM_INFO(d)->stats.long_block_tot,
>>> +               (EDOM_INFO(d)->stats.long_block_tot * 100) / EDOM_INFO(d)->stats.block_tot,
>>> +               (EDOM_INFO(d)->stats.block_time_tot) / EDOM_INFO(d)->stats.block_tot,
>>> +               (EDOM_INFO(d)->stats.penalty_time_tot) / EDOM_INFO(d)->stats.block_tot);
>> ...wouldn't it be even more beautiful to have a macro for reading stats
>> as well?
>>
>> Like I said, it's fine as it is, but since you're looking for beauty, I
>> figured I'd point it out. :-)
>>
> I see what you mean. Again, as you wish.
>
> This code will need some (and quite a bit actually) of attention as soon
> as I or someone else get the time to work on it. If you're fine about
> taking this as is, I'll make a note to self about the macro (as I agree
> it would be nice).

OK -- in that case:

Acked-by: George Dunlap 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 16:36:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 16:36:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQhSu-0005K4-Tw; Tue, 23 Oct 2012 16:36:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQhSs-0005Jv-TV
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 16:36:27 +0000
Received: from [85.158.143.99:61116] by server-3.bemta-4.messagelabs.com id
	54/85-03544-A87C6805; Tue, 23 Oct 2012 16:36:26 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1351010183!25635894!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzg0MDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30174 invoked from network); 23 Oct 2012 16:36:24 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 16:36:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,635,1344211200"; d="scan'208";a="42174898"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Oct 2012 16:35:22 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 23 Oct 2012 12:35:22 -0400
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[0.0.0.0])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TQhRq-0003dy-65;
	Tue, 23 Oct 2012 17:35:22 +0100
Message-ID: <5086C747.1090704@eu.citrix.com>
Date: Tue, 23 Oct 2012 17:35:19 +0100
From: George Dunlap 
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Dario Faggioli 
References: 
	<27c4c065efe366a5d761.1350916838@Solace>
	<5086C544.4070607@eu.citrix.com> <1351010023.5064.63.camel@Solace>
In-Reply-To: <1351010023.5064.63.camel@Solace>
Cc: Paul Durrant , "Keir \(Xen.org\)" ,
	Jan Beulich ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 5 of 6] xen: sched_sedf: beautify statisics
	in SEDF
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 23/10/12 17:33, Dario Faggioli wrote:
>>>    #ifdef SEDF_STATS
>>> -    if ( EDOM_INFO(d)->block_time_tot != 0 )
>>> -        printk(" pen=%"PRIu64"%%", (EDOM_INFO(d)->penalty_time_tot * 100) /
>>> -               EDOM_INFO(d)->block_time_tot);
>>> -    if ( EDOM_INFO(d)->block_tot != 0 )
>>> +    if ( EDOM_INFO(d)->stats.block_time_tot != 0 )
>>> +        printk(" pen=%"PRIu64"%%", (EDOM_INFO(d)->stats.penalty_time_tot * 100) /
>>> +               EDOM_INFO(d)->stats.block_time_tot);
>>> +    if ( EDOM_INFO(d)->stats.block_tot != 0 )
>>>            printk("\n   blks=%u sh=%u (%u%%) (shc=%u (%u%%) shex=%i "\
>>>                   "shexsl=%i) l=%u (%u%%) avg: b=%"PRIu64" p=%"PRIu64"",
>>> -               EDOM_INFO(d)->block_tot, EDOM_INFO(d)->short_block_tot,
>>> -               (EDOM_INFO(d)->short_block_tot * 100)
>>> -               / EDOM_INFO(d)->block_tot, EDOM_INFO(d)->short_cont,
>>> -               (EDOM_INFO(d)->short_cont * 100) / EDOM_INFO(d)->block_tot,
>>> -               EDOM_INFO(d)->pen_extra_blocks,
>>> -               EDOM_INFO(d)->pen_extra_slices,
>>> -               EDOM_INFO(d)->long_block_tot,
>>> -               (EDOM_INFO(d)->long_block_tot * 100) / EDOM_INFO(d)->block_tot,
>>> -               (EDOM_INFO(d)->block_time_tot) / EDOM_INFO(d)->block_tot,
>>> -               (EDOM_INFO(d)->penalty_time_tot) / EDOM_INFO(d)->block_tot);
>>> +               EDOM_INFO(d)->stats.block_tot, EDOM_INFO(d)->stats.short_block_tot,
>>> +               (EDOM_INFO(d)->stats.short_block_tot * 100)
>>> +               / EDOM_INFO(d)->stats.block_tot, EDOM_INFO(d)->stats.short_cont,
>>> +               (EDOM_INFO(d)->stats.short_cont * 100) / EDOM_INFO(d)->stats.block_tot,
>>> +               EDOM_INFO(d)->stats.pen_extra_blocks,
>>> +               EDOM_INFO(d)->stats.pen_extra_slices,
>>> +               EDOM_INFO(d)->stats.long_block_tot,
>>> +               (EDOM_INFO(d)->stats.long_block_tot * 100) / EDOM_INFO(d)->stats.block_tot,
>>> +               (EDOM_INFO(d)->stats.block_time_tot) / EDOM_INFO(d)->stats.block_tot,
>>> +               (EDOM_INFO(d)->stats.penalty_time_tot) / EDOM_INFO(d)->stats.block_tot);
>> ...wouldn't it be even more beautiful to have a macro for reading stats
>> as well?
>>
>> Like I said, it's fine as it is, but since you're looking for beauty, I
>> figured I'd point it out. :-)
>>
> I see what you mean. Again, as you wish.
>
> This code will need some (and quite a bit actually) of attention as soon
> as I or someone else get the time to work on it. If you're fine about
> taking this as is, I'll make a note to self about the macro (as I agree
> it would be nice).

OK -- in that case:

Acked-by: George Dunlap 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 16:39:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 16:39:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQhVl-0005XE-H3; Tue, 23 Oct 2012 16:39:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQhVk-0005X6-4o
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 16:39:24 +0000
Received: from [85.158.138.51:64675] by server-12.bemta-3.messagelabs.com id
	C3/B1-27853-B38C6805; Tue, 23 Oct 2012 16:39:23 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1351010361!27884191!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgyNzg1OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6433 invoked from network); 23 Oct 2012 16:39:22 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Oct 2012 16:39:22 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9NGdIfg026531
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 23 Oct 2012 16:39:19 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9NGdHhm008176
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 23 Oct 2012 16:39:17 GMT
Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9NGdGjS024188; Tue, 23 Oct 2012 11:39:17 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 23 Oct 2012 09:39:16 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 0E6E8403C7; Tue, 23 Oct 2012 12:27:08 -0400 (EDT)
Date: Tue, 23 Oct 2012 12:27:07 -0400
From: Konrad Rzeszutek Wilk 
To: Linus Torvalds ,
	linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Message-ID: <20121023162707.GA16634@phenom.dumpdata.com>
MIME-Version: 1.0
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: [Xen-devel] [GIT PULL] (xen) stable/for-linus-3.7-rc2-tag for
	v3.7-rc2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============2577343713765615251=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============2577343713765615251==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="17pEHd4RhPHOinZp"
Content-Disposition: inline


--17pEHd4RhPHOinZp
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hey Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-linus-3.7-rc2-tag

which has bug-fixes. Most of them are just code cleanup to make x86 and ARM code
work in unison. There is one serious bug-fix which manifested itself in some
applications mysteriously getting SIGKILL. Besides that nothing earth-shattering.

:
 * Fix mysterious SIGSEGV or SIGKILL in applications due to corrupting
   of the %eip when returning from a signal handler.
 * Fix various ARM compile issues after the merge fallout.
 * Continue on making more of the Xen generic code usable by ARM platform.
 * Fix SR-IOV passthrough to mirror multifunction PCI devices.
 * Fix various compile warnings.
 * Remove hypercalls that don't exist anymore.


 arch/arm/include/asm/xen/interface.h |   12 +++++++++---
 arch/arm/include/asm/xen/page.h      |   13 ++++++++++---
 arch/arm/xen/grant-table.c           |    2 +-
 arch/x86/include/asm/xen/interface.h |    4 ++--
 arch/x86/kernel/entry_32.S           |    8 +++++---
 arch/x86/kernel/entry_64.S           |    2 +-
 arch/x86/xen/enlighten.c             |    2 --
 drivers/xen/balloon.c                |    3 +--
 drivers/xen/dbgp.c                   |    2 ++
 drivers/xen/events.c                 |    4 ++++
 drivers/xen/grant-table.c            |    8 ++++----
 drivers/xen/sys-hypervisor.c         |    4 +++-
 drivers/xen/xen-pciback/vpci.c       |   14 ++++++++++----
 drivers/xen/xenbus/xenbus_xs.c       |    2 ++
 include/xen/grant_table.h            |    2 +-
 include/xen/interface/grant_table.h  |    2 +-
 include/xen/interface/memory.h       |   24 ++----------------------
 17 files changed, 58 insertions(+), 50 deletions(-)

David Vrabel (1):
      xen/x86: don't corrupt %eip when returning from a signal handler

Ian Campbell (11):
      xen: xenbus: quirk uses x86 specific cpuid
      xen: sysfs: include err.h for PTR_ERR etc
      xen: sysfs: fix build warning.
      xen: XENMEM_translate_gpfn_list was remove ages ago and is unused.
      xen: events: pirq_check_eoi_map is X86 specific
      xen: grant: use xen_pfn_t type for frame_list.
      xen: balloon: don't include e820.h
      xen: arm: make p2m operations NOPs
      xen: balloon: use correct type for frame_list
      xen: arm: comment on why 64-bit xen_pfn_t is safe even on 32 bit
      xen: dbgp: Fix warning when CONFIG_PCI is not enabled.

Konrad Rzeszutek Wilk (1):
      xen/xenbus: Fix compile warning.

Laszlo Ersek (1):
      xen PV passthru: assign SR-IOV virtual functions to separate virtual slots

Wei Yongjun (1):
      xen/x86: remove duplicated include from enlighten.c


--17pEHd4RhPHOinZp
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEbBAEBAgAGBQJQhsVXAAoJEFjIrFwIi8fJenkH+NWtUEoU2oSEeR1iR9cVQgRa
gZiPxQUW4qJUYxJPC7k+sXXDHj/b3xA+eodkRRakzOot7uLREm7/801XcKxIQCbh
7fxx0MLwCNCGa4OzdmzlzjcTtIE0rscPVi1939tPIvM+T/6+5zIsvtjwcudElAjH
a5U+Qv8cHDLD4OupT2V9tt6bPxcFmhra7p73XHe9mUvchV4mXMtBBXnOoCJn/IEZ
pxjhIaZEKBdePZCcauIKlnskdVjr7LwfNmIgAXsqrwguNqLkCT9+ycApfd8UonK8
iRMEohDuqZPwPWoOEkUBjhziUWYOGVQ7JtGpXtfoUZvKZa46frcxL5Lix+FNOA==
=UE8b
-----END PGP SIGNATURE-----

--17pEHd4RhPHOinZp--


--===============2577343713765615251==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2577343713765615251==--


From xen-devel-bounces@lists.xen.org Tue Oct 23 16:39:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 16:39:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQhVl-0005XE-H3; Tue, 23 Oct 2012 16:39:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQhVk-0005X6-4o
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 16:39:24 +0000
Received: from [85.158.138.51:64675] by server-12.bemta-3.messagelabs.com id
	C3/B1-27853-B38C6805; Tue, 23 Oct 2012 16:39:23 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1351010361!27884191!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgyNzg1OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6433 invoked from network); 23 Oct 2012 16:39:22 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Oct 2012 16:39:22 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9NGdIfg026531
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 23 Oct 2012 16:39:19 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9NGdHhm008176
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 23 Oct 2012 16:39:17 GMT
Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9NGdGjS024188; Tue, 23 Oct 2012 11:39:17 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 23 Oct 2012 09:39:16 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 0E6E8403C7; Tue, 23 Oct 2012 12:27:08 -0400 (EDT)
Date: Tue, 23 Oct 2012 12:27:07 -0400
From: Konrad Rzeszutek Wilk 
To: Linus Torvalds ,
	linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Message-ID: <20121023162707.GA16634@phenom.dumpdata.com>
MIME-Version: 1.0
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: [Xen-devel] [GIT PULL] (xen) stable/for-linus-3.7-rc2-tag for
	v3.7-rc2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============2577343713765615251=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============2577343713765615251==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="17pEHd4RhPHOinZp"
Content-Disposition: inline


--17pEHd4RhPHOinZp
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hey Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-linus-3.7-rc2-tag

which has bug-fixes. Most of them are just code cleanup to make x86 and ARM code
work in unison. There is one serious bug-fix which manifested itself in some
applications mysteriously getting SIGKILL. Besides that nothing earth-shattering.

:
 * Fix mysterious SIGSEGV or SIGKILL in applications due to corrupting
   of the %eip when returning from a signal handler.
 * Fix various ARM compile issues after the merge fallout.
 * Continue on making more of the Xen generic code usable by ARM platform.
 * Fix SR-IOV passthrough to mirror multifunction PCI devices.
 * Fix various compile warnings.
 * Remove hypercalls that don't exist anymore.


 arch/arm/include/asm/xen/interface.h |   12 +++++++++---
 arch/arm/include/asm/xen/page.h      |   13 ++++++++++---
 arch/arm/xen/grant-table.c           |    2 +-
 arch/x86/include/asm/xen/interface.h |    4 ++--
 arch/x86/kernel/entry_32.S           |    8 +++++---
 arch/x86/kernel/entry_64.S           |    2 +-
 arch/x86/xen/enlighten.c             |    2 --
 drivers/xen/balloon.c                |    3 +--
 drivers/xen/dbgp.c                   |    2 ++
 drivers/xen/events.c                 |    4 ++++
 drivers/xen/grant-table.c            |    8 ++++----
 drivers/xen/sys-hypervisor.c         |    4 +++-
 drivers/xen/xen-pciback/vpci.c       |   14 ++++++++++----
 drivers/xen/xenbus/xenbus_xs.c       |    2 ++
 include/xen/grant_table.h            |    2 +-
 include/xen/interface/grant_table.h  |    2 +-
 include/xen/interface/memory.h       |   24 ++----------------------
 17 files changed, 58 insertions(+), 50 deletions(-)

David Vrabel (1):
      xen/x86: don't corrupt %eip when returning from a signal handler

Ian Campbell (11):
      xen: xenbus: quirk uses x86 specific cpuid
      xen: sysfs: include err.h for PTR_ERR etc
      xen: sysfs: fix build warning.
      xen: XENMEM_translate_gpfn_list was remove ages ago and is unused.
      xen: events: pirq_check_eoi_map is X86 specific
      xen: grant: use xen_pfn_t type for frame_list.
      xen: balloon: don't include e820.h
      xen: arm: make p2m operations NOPs
      xen: balloon: use correct type for frame_list
      xen: arm: comment on why 64-bit xen_pfn_t is safe even on 32 bit
      xen: dbgp: Fix warning when CONFIG_PCI is not enabled.

Konrad Rzeszutek Wilk (1):
      xen/xenbus: Fix compile warning.

Laszlo Ersek (1):
      xen PV passthru: assign SR-IOV virtual functions to separate virtual slots

Wei Yongjun (1):
      xen/x86: remove duplicated include from enlighten.c


--17pEHd4RhPHOinZp
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEbBAEBAgAGBQJQhsVXAAoJEFjIrFwIi8fJenkH+NWtUEoU2oSEeR1iR9cVQgRa
gZiPxQUW4qJUYxJPC7k+sXXDHj/b3xA+eodkRRakzOot7uLREm7/801XcKxIQCbh
7fxx0MLwCNCGa4OzdmzlzjcTtIE0rscPVi1939tPIvM+T/6+5zIsvtjwcudElAjH
a5U+Qv8cHDLD4OupT2V9tt6bPxcFmhra7p73XHe9mUvchV4mXMtBBXnOoCJn/IEZ
pxjhIaZEKBdePZCcauIKlnskdVjr7LwfNmIgAXsqrwguNqLkCT9+ycApfd8UonK8
iRMEohDuqZPwPWoOEkUBjhziUWYOGVQ7JtGpXtfoUZvKZa46frcxL5Lix+FNOA==
=UE8b
-----END PGP SIGNATURE-----

--17pEHd4RhPHOinZp--


--===============2577343713765615251==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2577343713765615251==--


From xen-devel-bounces@lists.xen.org Tue Oct 23 17:33:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 17:33:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQiL7-0005wr-EL; Tue, 23 Oct 2012 17:32:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQiL6-0005wm-GG
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 17:32:29 +0000
Received: from [85.158.139.211:56235] by server-15.bemta-5.messagelabs.com id
	44/22-28599-BA4D6805; Tue, 23 Oct 2012 17:32:27 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1351013545!23451389!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODIwNzA4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24279 invoked from network); 23 Oct 2012 17:32:26 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Oct 2012 17:32:26 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9NHWIw8002547
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 23 Oct 2012 17:32:19 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9NHWHDd020221
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 23 Oct 2012 17:32:18 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9NHWHFw032226; Tue, 23 Oct 2012 12:32:17 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 23 Oct 2012 10:32:17 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 94F14403C7; Tue, 23 Oct 2012 13:20:08 -0400 (EDT)
Date: Tue, 23 Oct 2012 13:20:08 -0400
From: Konrad Rzeszutek Wilk 
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= 
Message-ID: <20121023172008.GB11787@phenom.dumpdata.com>
References: <1350559321-19066-1-git-send-email-roger.pau@citrix.com>
	<20121022134708.GA13832@konrad-lan.dumpdata.com>
	<5086C0C8.5000306@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5086C0C8.5000306@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Konrad Rzeszutek Wilk ,
	"linux-kernel@vger.kernel.org" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH RFC] Persistent grant maps for xen blk
	drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 23, 2012 at 06:07:36PM +0200, Roger Pau Monn=E9 wrote:
> On 22/10/12 15:47, Konrad Rzeszutek Wilk wrote:
> > On Thu, Oct 18, 2012 at 01:22:01PM +0200, Roger Pau Monne wrote:
> >> This patch implements persistent grants for the xen-blk{front,back}
> >> mechanism. The effect of this change is to reduce the number of unmap
> >> operations performed, since they cause a (costly) TLB shootdown. This
> >> allows the I/O performance to scale better when a large number of VMs
> >> are performing I/O.
> >>
> >> Previously, the blkfront driver was supplied a bvec[] from the request
> >> queue. This was granted to dom0; dom0 performed the I/O and wrote
> >> directly into the grant-mapped memory and unmapped it; blkfront then
> >> removed foreign access for that grant. The cost of unmapping scales
> >> badly with the number of CPUs in Dom0. An experiment showed that when
> >> Dom0 has 24 VCPUs, and guests are performing parallel I/O to a
> >> ramdisk, the IPIs from performing unmap's is a bottleneck at 5 guests
> >> (at which point 650,000 IOPS are being performed in total). If more
> >> than 5 guests are used, the performance declines. By 10 guests, only
> >> 400,000 IOPS are being performed.
> >>
> >> This patch improves performance by only unmapping when the connection
> >> between blkfront and back is broken.
> >>
> >> On startup blkfront notifies blkback that it is using persistent
> >> grants, and blkback will do the same. If blkback is not capable of
> >> persistent mapping, blkfront will still use the same grants, since it
> >> is compatible with the previous protocol, and simplifies the code
> >> complexity in blkfront.
> >>
> >> To perform a read, in persistent mode, blkfront uses a separate pool
> >> of pages that it maps to dom0. When a request comes in, blkfront
> >> transmutes the request so that blkback will write into one of these
> >> free pages. Blkback keeps note of which grefs it has already
> >> mapped. When a new ring request comes to blkback, it looks to see if
> >> it has already mapped that page. If so, it will not map it again. If
> >> the page hasn't been previously mapped, it is mapped now, and a record
> >> is kept of this mapping. Blkback proceeds as usual. When blkfront is
> >> notified that blkback has completed a request, it memcpy's from the
> >> shared memory, into the bvec supplied. A record that the {gref, page}
> >> tuple is mapped, and not inflight is kept.
> >>
> >> Writes are similar, except that the memcpy is peformed from the
> >> supplied bvecs, into the shared pages, before the request is put onto
> >> the ring.
> >>
> >> Blkback stores a mapping of grefs=3D>{page mapped to by gref} in
> >> a red-black tree. As the grefs are not known apriori, and provide no
> >> guarantees on their ordering, we have to perform a search
> >> through this tree to find the page, for every gref we receive. This
> >> operation takes O(log n) time in the worst case.
> > =

> > Might want to mention how blkfront stores it as well. It looks
> > to be using 'llist' instead of 'list'? Any particular reason?
> =

> Since we are just pushing and poping grant references, I went for what I
> think is the simplest one, a single linked list (list is a doubly linked
> list). Oliver in the previous version was using something similar, but
> custom made. I think it's best to use the data structures provided by
> the kernel itself.
> =

> > =

> >>
> >> The maximum number of grants that blkback will persistenly map is
> >> currently set to RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, to
> >> prevent a malicios guest from attempting a DoS, by supplying fresh
> >> grefs, causing the Dom0 kernel to map excessively. If a guest
> >> is using persistent grants and exceeds the maximum number of grants to
> >> map persistenly the newly passed grefs will be mapped and unmaped.
> >> Using this approach, we can have requests that mix persistent and
> >> non-persistent grants, and we need to handle them correctly.
> >> This allows us to set the maximum number of persistent grants to a
> >> lower value than RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, although
> >> setting it will lead to unpredictable performance.
> >>
> >> In writing this patch, the question arrises as to if the additional
> >> cost of performing memcpys in the guest (to/from the pool of granted
> >> pages) outweigh the gains of not performing TLB shootdowns. The answer
> >> to that question is `no'. There appears to be very little, if any
> >> additional cost to the guest of using persistent grants. There is
> >> perhaps a small saving, from the reduced number of hypercalls
> >> performed in granting, and ending foreign access.
> >>
> >> Signed-off-by: Oliver Chick 
> >> Signed-off-by: Roger Pau Monne 
> >> Cc: 
> >> Cc: 
> >> ---
> >> Benchmarks showing the impact of this patch in blk performance can be
> >> found at:
> >>
> >> http://xenbits.xensource.com/people/royger/persistent_grants/
> >> ---
> >>  drivers/block/xen-blkback/blkback.c |  279 ++++++++++++++++++++++++++=
+++++---
> >>  drivers/block/xen-blkback/common.h  |   17 ++
> >>  drivers/block/xen-blkback/xenbus.c  |   16 ++-
> >>  drivers/block/xen-blkfront.c        |  183 ++++++++++++++++++++----
> >>  4 files changed, 442 insertions(+), 53 deletions(-)
> >>
> >> diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-b=
lkback/blkback.c
> >> index c6decb9..2b982b2 100644
> >> --- a/drivers/block/xen-blkback/blkback.c
> >> +++ b/drivers/block/xen-blkback/blkback.c
> >> @@ -78,6 +78,7 @@ struct pending_req {
> >>       unsigned short          operation;
> >>       int                     status;
> >>       struct list_head        free_list;
> >> +     unsigned int            unmap_seg[BLKIF_MAX_SEGMENTS_PER_REQUEST=
];
> >>  };
> >>
> >>  #define BLKBACK_INVALID_HANDLE (~0)
> >> @@ -98,6 +99,30 @@ struct xen_blkbk {
> >>  static struct xen_blkbk *blkbk;
> >>
> >>  /*
> >> + * Maximum number of grant pages that can be mapped in blkback.
> >> + * BLKIF_MAX_SEGMENTS_PER_REQUEST * RING_SIZE is the maximum number of
> >> + * pages that blkback will persistently map.
> >> + */
> >> +static inline unsigned int max_mapped_grant_pages(enum blkif_protocol=
 protocol)
> >> +{
> >> +     switch (protocol) {
> >> +     case BLKIF_PROTOCOL_NATIVE:
> >> +             return __CONST_RING_SIZE(blkif, PAGE_SIZE) *
> >> +                        BLKIF_MAX_SEGMENTS_PER_REQUEST;
> >> +     case BLKIF_PROTOCOL_X86_32:
> >> +             return __CONST_RING_SIZE(blkif_x86_32, PAGE_SIZE) *
> >> +                        BLKIF_MAX_SEGMENTS_PER_REQUEST;
> >> +     case BLKIF_PROTOCOL_X86_64:
> >> +             return __CONST_RING_SIZE(blkif_x86_64, PAGE_SIZE) *
> >> +                        BLKIF_MAX_SEGMENTS_PER_REQUEST;
> > =

> > Could you include in the comments what the size (bytes) you expect it t=
o be?
> > If that would require you re-doing some tests - then don't worry - but
> > I figured you have some notes scribbled away that have the exact values
> > down.
> =

> As far as I know and remember (I've checked the ring size in the past),
> all ring types have a size of 32, BLKIF_MAX_SEGMENTS_PER_REQUEST is
> always 11, and sizeof(struct persistent_gnt) is 48, so that's 32 * 11 *
> 48 =3D 16896 bytes. I will add a comment with this calculation.
> =

> > =

> >> +     default:
> >> +             BUG();
> >> +     }
> >> +     return 0;
> >> +}
> >> +
> >> +
> >> +/*
> >>   * Little helpful macro to figure out the index and virtual address o=
f the
> >>   * pending_pages[..]. For each 'pending_req' we have have up to
> >>   * BLKIF_MAX_SEGMENTS_PER_REQUEST (11) pages. The seg would be from 0=
 through
> >> @@ -128,6 +153,57 @@ static int dispatch_rw_block_io(struct xen_blkif =
*blkif,
> >>  static void make_response(struct xen_blkif *blkif, u64 id,
> >>                         unsigned short op, int st);
> >>
> >> +#define foreach_grant(pos, rbtree, node) \
> >> +     for ((pos) =3D container_of(rb_first((rbtree)), typeof(*(pos)), =
node); \
> >> +          &(pos)->node !=3D NULL; \
> >> +          (pos) =3D container_of(rb_next(&(pos)->node), typeof(*(pos)=
), node))
> >> +
> >> +
> >> +static void add_persistent_gnt(struct rb_root *root,
> >> +                            struct persistent_gnt *persistent_gnt)
> >> +{
> >> +     struct rb_node **new =3D &(root->rb_node), *parent =3D NULL;
> >> +     struct persistent_gnt *this;
> >> +
> >> +     /* Figure out where to put new node */
> >> +     while (*new) {
> >> +             this =3D container_of(*new, struct persistent_gnt, node);
> >> +
> >> +             parent =3D *new;
> >> +             if (persistent_gnt->gnt < this->gnt)
> >> +                     new =3D &((*new)->rb_left);
> >> +             else if (persistent_gnt->gnt > this->gnt)
> >> +                     new =3D &((*new)->rb_right);
> >> +             else {
> >> +                     pr_alert(DRV_PFX " trying to add a gref that's a=
lready in the tree\n");
> >> +                     BUG();
> >> +             }
> >> +     }
> >> +
> >> +     /* Add new node and rebalance tree. */
> >> +     rb_link_node(&(persistent_gnt->node), parent, new);
> >> +     rb_insert_color(&(persistent_gnt->node), root);
> >> +}
> >> +
> >> +static struct persistent_gnt *get_persistent_gnt(struct rb_root *root,
> >> +                                              grant_ref_t gref)
> >> +{
> >> +     struct persistent_gnt *data;
> >> +     struct rb_node *node =3D root->rb_node;
> >> +
> >> +     while (node) {
> >> +             data =3D container_of(node, struct persistent_gnt, node);
> >> +
> >> +             if (gref < data->gnt)
> >> +                     node =3D node->rb_left;
> >> +             else if (gref > data->gnt)
> >> +                     node =3D node->rb_right;
> >> +             else
> >> +                     return data;
> >> +     }
> >> +     return NULL;
> >> +}
> >> +
> >>  /*
> >>   * Retrieve from the 'pending_reqs' a free pending_req structure to b=
e used.
> >>   */
> >> @@ -274,6 +350,11 @@ int xen_blkif_schedule(void *arg)
> >>  {
> >>       struct xen_blkif *blkif =3D arg;
> >>       struct xen_vbd *vbd =3D &blkif->vbd;
> >> +     struct gnttab_unmap_grant_ref unmap[BLKIF_MAX_SEGMENTS_PER_REQUE=
ST];
> >> +     struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> >> +     struct persistent_gnt *persistent_gnt;
> >> +     int ret =3D 0;
> >> +     int segs_to_unmap =3D 0;
> >>
> >>       xen_blkif_get(blkif);
> >>
> >> @@ -301,6 +382,32 @@ int xen_blkif_schedule(void *arg)
> >>                       print_stats(blkif);
> >>       }
> >>
> >> +     /* Free all persistent grant pages */
> >> +     foreach_grant(persistent_gnt, &blkif->persistent_gnts, node) {
> > =

> > Just for sanity - you did check this with blkfronts that did not have
> > persistent grants enabled, right?
> =

> Yes, it doesn't crash, but looking at foreach_grant it seems like it
> should. I've added a check before trying to iterate over the tree.
> =

> > =

> >> +             BUG_ON(persistent_gnt->handle =3D=3D BLKBACK_INVALID_HAN=
DLE);
> >> +             gnttab_set_unmap_op(&unmap[segs_to_unmap],
> >> +                 (unsigned long) pfn_to_kaddr(page_to_pfn(
> >> +                     persistent_gnt->page)),
> >> +                 GNTMAP_host_map,
> >> +                 persistent_gnt->handle);
> >> +
> >> +             pages[segs_to_unmap] =3D persistent_gnt->page;
> >> +             rb_erase(&persistent_gnt->node, &blkif->persistent_gnts);
> >> +             kfree(persistent_gnt);
> >> +             blkif->persistent_gnt_c--;
> >> +
> >> +             if (++segs_to_unmap =3D=3D BLKIF_MAX_SEGMENTS_PER_REQUES=
T ||
> >> +                     !rb_next(&persistent_gnt->node)) {
> >> +                     ret =3D gnttab_unmap_refs(unmap, NULL, pages,
> >> +                                             segs_to_unmap);
> >> +                     BUG_ON(ret);
> >> +                     segs_to_unmap =3D 0;
> >> +             }
> >> +     }
> >> +
> >> +     BUG_ON(blkif->persistent_gnt_c !=3D 0);
> >> +     BUG_ON(!RB_EMPTY_ROOT(&blkif->persistent_gnts));
> >> +
> >>       if (log_stats)
> >>               print_stats(blkif);
> >>
> >> @@ -327,6 +434,8 @@ static void xen_blkbk_unmap(struct pending_req *re=
q)
> >>       int ret;
> >>
> >>       for (i =3D 0; i < req->nr_pages; i++) {
> >> +             if (!req->unmap_seg[i])
> >> +                     continue;
> > =

> > Perhaps there should be a #define for that array..
> =

> Do you mean something like:
> =

> #define unmap(req, i) req->unmap_seg[i]

I was thinking that you just check for req->unamp_seg[i] to
have an non-zero value. But since that array is just used as an check
to see whether the functionality is enabled (or not), you might want
to declerare the right values so:
#define UNMAP_SG_ON 1
#define UNMAP_SG_OFF 0

or so.

> =

> >>               handle =3D pending_handle(req, i);
> >>               if (handle =3D=3D BLKBACK_INVALID_HANDLE)
> >>                       continue;
> >> @@ -343,12 +452,26 @@ static void xen_blkbk_unmap(struct pending_req *=
req)
> >>
> >>  static int xen_blkbk_map(struct blkif_request *req,
> >>                        struct pending_req *pending_req,
> >> -                      struct seg_buf seg[])
> >> +                      struct seg_buf seg[],
> >> +                      struct page *pages[])
> >>  {
> >>       struct gnttab_map_grant_ref map[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> >> -     int i;
> >> +     struct persistent_gnt *persistent_gnts[BLKIF_MAX_SEGMENTS_PER_RE=
QUEST];
> >> +     struct page *pages_to_gnt[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> >> +     struct persistent_gnt *persistent_gnt =3D NULL;
> >> +     struct xen_blkif *blkif =3D pending_req->blkif;
> >> +     phys_addr_t addr =3D 0;
> >> +     int i, j;
> >> +     int new_map;
> > =

> > Just use a bool for this.
> =

> Done
> =

> >>       int nseg =3D req->u.rw.nr_segments;
> >> +     int segs_to_map =3D 0;
> >>       int ret =3D 0;
> >> +     int use_persistent_gnts;
> >> +
> >> +     use_persistent_gnts =3D (blkif->vbd.feature_gnt_persistent);
> >> +
> >> +     BUG_ON(blkif->persistent_gnt_c >
> >> +                max_mapped_grant_pages(pending_req->blkif->blk_protoc=
ol));
> >>
> >>       /*
> >>        * Fill out preq.nr_sects with proper amount of sectors, and set=
up
> >> @@ -358,36 +481,141 @@ static int xen_blkbk_map(struct blkif_request *=
req,
> >>       for (i =3D 0; i < nseg; i++) {
> >>               uint32_t flags;
> >>
> >> -             flags =3D GNTMAP_host_map;
> >> -             if (pending_req->operation !=3D BLKIF_OP_READ)
> >> -                     flags |=3D GNTMAP_readonly;
> >> -             gnttab_set_map_op(&map[i], vaddr(pending_req, i), flags,
> >> -                               req->u.rw.seg[i].gref,
> >> -                               pending_req->blkif->domid);
> >> +             if (use_persistent_gnts)
> >> +                     persistent_gnt =3D get_persistent_gnt(
> >> +                             &blkif->persistent_gnts,
> >> +                             req->u.rw.seg[i].gref);
> >> +
> >> +             if (persistent_gnt) {
> >> +                     /*
> >> +                      * We are using persistent grants and
> >> +                      * the grant is already mapped
> >> +                      */
> >> +                     new_map =3D 0;
> >> +             } else if (use_persistent_gnts &&
> >> +                        blkif->persistent_gnt_c <
> >> +                        max_mapped_grant_pages(blkif->blk_protocol)) {
> >> +                     /*
> >> +                      * We are using persistent grants, the grant is
> >> +                      * not mapped but we have room for it
> >> +                      */
> >> +                     new_map =3D 1;
> >> +                     persistent_gnt =3D kzalloc(
> >> +                             sizeof(struct persistent_gnt),
> >> +                             GFP_KERNEL);
> >> +                     if (!persistent_gnt)
> >> +                             return -ENOMEM;
> >> +                     persistent_gnt->page =3D alloc_page(GFP_KERNEL);
> >> +                     if (!persistent_gnt->page) {
> >> +                             kfree(persistent_gnt);
> >> +                             return -ENOMEM;
> >> +                     }
> >> +                     persistent_gnt->gnt =3D req->u.rw.seg[i].gref;
> >> +
> >> +                     pages_to_gnt[segs_to_map] =3D
> >> +                             persistent_gnt->page;
> >> +                     addr =3D (unsigned long) pfn_to_kaddr(
> >> +                             page_to_pfn(persistent_gnt->page));
> >> +
> >> +                     add_persistent_gnt(&blkif->persistent_gnts,
> >> +                             persistent_gnt);
> >> +                     blkif->persistent_gnt_c++;
> >> +                     pr_debug(DRV_PFX " grant %u added to the tree of=
 persistent grants, using %u/%u\n",
> >> +                              persistent_gnt->gnt, blkif->persistent_=
gnt_c,
> >> +                              max_mapped_grant_pages(blkif->blk_proto=
col));
> >> +             } else {
> >> +                     /*
> >> +                      * We are either using persistent grants and
> >> +                      * hit the maximum limit of grants mapped,
> >> +                      * or we are not using persistent grants.
> >> +                      */
> >> +                     if (use_persistent_gnts &&
> >> +                             !blkif->vbd.overflow_max_grants) {
> >> +                             blkif->vbd.overflow_max_grants =3D 1;
> >> +                             pr_alert(DRV_PFX " domain %u, device %#x=
 is using maximum number of persistent grants\n",
> >> +                                      blkif->domid, blkif->vbd.handle=
);
> >> +                     }
> >> +                     new_map =3D 1;
> >> +                     pages[i] =3D blkbk->pending_page(pending_req, i);
> >> +                     addr =3D vaddr(pending_req, i);
> >> +                     pages_to_gnt[segs_to_map] =3D
> >> +                             blkbk->pending_page(pending_req, i);
> >> +             }
> >> +
> >> +             if (persistent_gnt) {
> >> +                     pages[i] =3D persistent_gnt->page;
> >> +                     persistent_gnts[i] =3D persistent_gnt;
> >> +             } else {
> >> +                     persistent_gnts[i] =3D NULL;
> >> +             }
> >> +
> >> +             if (new_map) {
> >> +                     flags =3D GNTMAP_host_map;
> >> +                     if (!persistent_gnt &&
> >> +                         (pending_req->operation !=3D BLKIF_OP_READ))
> >> +                             flags |=3D GNTMAP_readonly;
> >> +                     gnttab_set_map_op(&map[segs_to_map++], addr,
> >> +                                       flags, req->u.rw.seg[i].gref,
> >> +                                       blkif->domid);
> >> +             }
> >>       }
> >>
> >> -     ret =3D gnttab_map_refs(map, NULL, &blkbk->pending_page(pending_=
req, 0), nseg);
> >> -     BUG_ON(ret);
> >> +     if (segs_to_map) {
> >> +             ret =3D gnttab_map_refs(map, NULL, pages_to_gnt, segs_to=
_map);
> >> +             BUG_ON(ret);
> >> +     }
> >>
> >>       /*
> >>        * Now swizzle the MFN in our domain with the MFN from the other=
 domain
> >>        * so that when we access vaddr(pending_req,i) it has the conten=
ts of
> >>        * the page from the other domain.
> >>        */
> >> -     for (i =3D 0; i < nseg; i++) {
> >> -             if (unlikely(map[i].status !=3D 0)) {
> >> -                     pr_debug(DRV_PFX "invalid buffer -- could not re=
map it\n");
> >> -                     map[i].handle =3D BLKBACK_INVALID_HANDLE;
> >> -                     ret |=3D 1;
> >> +     for (i =3D 0, j =3D 0; i < nseg; i++) {
> >> +             if (!persistent_gnts[i] || !persistent_gnts[i]->handle) {
> >> +                     /* This is a newly mapped grant */
> >> +                     BUG_ON(j >=3D segs_to_map);
> >> +                     if (unlikely(map[j].status !=3D 0)) {
> > =

> > I am not seeing j being incremented anywhere? Should it?
> =

> Yes, it should be incremented, but not here. See the comment below to
> see what I've changed.
> =

> > =

> >> +                             pr_debug(DRV_PFX "invalid buffer -- coul=
d not remap it\n");
> >> +                             map[j].handle =3D BLKBACK_INVALID_HANDLE;
> >> +                             ret |=3D 1;
> >> +                             if (persistent_gnts[i]) {
> >> +                                     rb_erase(&persistent_gnts[i]->no=
de,
> >> +                                              &blkif->persistent_gnts=
);
> >> +                                     blkif->persistent_gnt_c--;
> >> +                                     kfree(persistent_gnts[i]);
> >> +                                     persistent_gnts[i] =3D NULL;
> >> +                             }
> >> +                     }
> >> +             }
> >> +             if (persistent_gnts[i]) {
> >> +                     if (!persistent_gnts[i]->handle) {
> >> +                             /*
> >> +                              * If this is a new persistent grant
> >> +                              * save the handler
> >> +                              */
> >> +                             persistent_gnts[i]->handle =3D map[j].ha=
ndle;
> >> +                             persistent_gnts[i]->dev_bus_addr =3D
> >> +                                     map[j++].dev_bus_addr;
> >> +                     }
> >> +                     pending_handle(pending_req, i) =3D
> >> +                             persistent_gnts[i]->handle;
> >> +                     pending_req->unmap_seg[i] =3D 0;
> > =

> > Could we have a #define for that?
> =

> Sure.
> =

> >> +
> >> +                     if (ret)
> >> +                             continue;
> =

> This should be
> =

> if (ret) {
> 	j++;
> 	continue;
> }


> =

> >> +
> >> +                     seg[i].buf =3D persistent_gnts[i]->dev_bus_addr |
> >> +                             (req->u.rw.seg[i].first_sect << 9);
> >> +             } else {
> >> +                     pending_handle(pending_req, i) =3D map[j].handle;
> >> +                     pending_req->unmap_seg[i] =3D 1;
> > =

> > And here as well?
> =

> Done.
> =

> >> +
> >> +                     if (ret)
> >> +                             continue;
> >> +
> >> +                     seg[i].buf =3D map[j++].dev_bus_addr |
> >> +                             (req->u.rw.seg[i].first_sect << 9);
> >>               }
> >> -
> >> -             pending_handle(pending_req, i) =3D map[i].handle;
> >> -
> >> -             if (ret)
> >> -                     continue;
> >> -
> >> -             seg[i].buf  =3D map[i].dev_bus_addr |
> >> -                     (req->u.rw.seg[i].first_sect << 9);
> >>       }
> >>       return ret;
> >>  }
> >> @@ -590,6 +818,7 @@ static int dispatch_rw_block_io(struct xen_blkif *=
blkif,
> >>       int operation;
> >>       struct blk_plug plug;
> >>       bool drain =3D false;
> >> +     struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> >>
> >>       switch (req->operation) {
> >>       case BLKIF_OP_READ:
> >> @@ -676,7 +905,7 @@ static int dispatch_rw_block_io(struct xen_blkif *=
blkif,
> >>        * the hypercall to unmap the grants - that is all done in
> >>        * xen_blkbk_unmap.
> >>        */
> >> -     if (xen_blkbk_map(req, pending_req, seg))
> >> +     if (xen_blkbk_map(req, pending_req, seg, pages))
> >>               goto fail_flush;
> >>
> >>       /*
> >> @@ -688,7 +917,7 @@ static int dispatch_rw_block_io(struct xen_blkif *=
blkif,
> >>       for (i =3D 0; i < nseg; i++) {
> >>               while ((bio =3D=3D NULL) ||
> >>                      (bio_add_page(bio,
> >> -                                  blkbk->pending_page(pending_req, i),
> >> +                                  pages[i],
> >>                                    seg[i].nsec << 9,
> >>                                    seg[i].buf & ~PAGE_MASK) =3D=3D 0))=
 {
> >>
> >> diff --git a/drivers/block/xen-blkback/common.h b/drivers/block/xen-bl=
kback/common.h
> >> index 9ad3b5e..6c08ee9 100644
> >> --- a/drivers/block/xen-blkback/common.h
> >> +++ b/drivers/block/xen-blkback/common.h
> >> @@ -34,6 +34,7 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >>  #include 
> >>  #include 
> >>  #include 
> >> @@ -160,10 +161,22 @@ struct xen_vbd {
> >>       sector_t                size;
> >>       bool                    flush_support;
> >>       bool                    discard_secure;
> >> +
> >> +     unsigned int            feature_gnt_persistent:1;
> >> +     unsigned int            overflow_max_grants:1;
> > =

> > I think the v3.7-rc1 has this structure changed just a tiny bit, so you
> > might want to rebase it on top of that.
> =

> I've done the rebase on top of your linux-next branch, commit
> ad502612c173fff239250c9fe9bdfaaef70b9901.

Thx
> =

> > =

> >>  };
> >>
> >>  struct backend_info;
> >>
> >> +
> >> +struct persistent_gnt {
> >> +     struct page *page;
> >> +     grant_ref_t gnt;
> >> +     grant_handle_t handle;
> >> +     uint64_t dev_bus_addr;
> >> +     struct rb_node node;
> >> +};
> >> +
> >>  struct xen_blkif {
> >>       /* Unique identifier for this interface. */
> >>       domid_t                 domid;
> >> @@ -190,6 +203,10 @@ struct xen_blkif {
> >>       struct task_struct      *xenblkd;
> >>       unsigned int            waiting_reqs;
> >>
> >> +     /* frontend feature information */
> > =

> > Huh?
> =

> Changed it to:
> =

> /* tree to store persistent grants */
> =

> >> +     struct rb_root          persistent_gnts;
> >> +     unsigned int            persistent_gnt_c;
> >> +
> >>       /* statistics */
> >>       unsigned long           st_print;
> >>       int                     st_rd_req;
> >> diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-bl=
kback/xenbus.c
> >> index 4f66171..9f88b4e 100644
> >> --- a/drivers/block/xen-blkback/xenbus.c
> >> +++ b/drivers/block/xen-blkback/xenbus.c
> >> @@ -118,6 +118,7 @@ static struct xen_blkif *xen_blkif_alloc(domid_t d=
omid)
> >>       atomic_set(&blkif->drain, 0);
> >>       blkif->st_print =3D jiffies;
> >>       init_waitqueue_head(&blkif->waiting_to_free);
> >> +     blkif->persistent_gnts.rb_node =3D NULL;
> >>
> >>       return blkif;
> >>  }
> >> @@ -721,6 +722,7 @@ static int connect_ring(struct backend_info *be)
> >>       struct xenbus_device *dev =3D be->dev;
> >>       unsigned long ring_ref;
> >>       unsigned int evtchn;
> >> +     unsigned int pers_grants;
> >>       char protocol[64] =3D "";
> >>       int err;
> >>
> >> @@ -750,8 +752,18 @@ static int connect_ring(struct backend_info *be)
> >>               xenbus_dev_fatal(dev, err, "unknown fe protocol %s", pro=
tocol);
> >>               return -1;
> >>       }
> >> -     pr_info(DRV_PFX "ring-ref %ld, event-channel %d, protocol %d (%s=
)\n",
> >> -             ring_ref, evtchn, be->blkif->blk_protocol, protocol);
> >> +     err =3D xenbus_gather(XBT_NIL, dev->otherend,
> >> +                         "feature-persistent-grants", "%u",
> >> +                         &pers_grants, NULL);
> >> +     if (err)
> >> +             pers_grants =3D 0;
> >> +
> >> +     be->blkif->vbd.feature_gnt_persistent =3D pers_grants;
> >> +     be->blkif->vbd.overflow_max_grants =3D 0;
> >> +
> >> +     pr_info(DRV_PFX "ring-ref %ld, event-channel %d, protocol %d (%s=
) persistent %d\n",
> >> +             ring_ref, evtchn, be->blkif->blk_protocol, protocol,
> >> +             pers_grants);
> > =

> > Can you make that a string? So it is
> >  pers_grants ? "persistent grants" : ""
> > =

> > instead of a zero of one value pls?
> =

> Yes, done.
> =

> >>
> >>       /* Map the shared frame, irq etc. */
> >>       err =3D xen_blkif_map(be->blkif, ring_ref, evtchn);
> >> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront=
.c
> >> index 2c2d2e5..206d422 100644
> >> --- a/drivers/block/xen-blkfront.c
> >> +++ b/drivers/block/xen-blkfront.c
> >> @@ -44,6 +44,7 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >>
> >>  #include 
> >>  #include 
> >> @@ -64,10 +65,17 @@ enum blkif_state {
> >>       BLKIF_STATE_SUSPENDED,
> >>  };
> >>
> >> +struct grant {
> >> +     grant_ref_t gref;
> >> +     unsigned long pfn;
> >> +     struct llist_node node;
> >> +};
> >> +
> >>  struct blk_shadow {
> >>       struct blkif_request req;
> >>       struct request *request;
> >>       unsigned long frame[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> >> +     struct grant *grants_used[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> >>  };
> >>
> >>  static DEFINE_MUTEX(blkfront_mutex);
> >> @@ -97,6 +105,8 @@ struct blkfront_info
> >>       struct work_struct work;
> >>       struct gnttab_free_callback callback;
> >>       struct blk_shadow shadow[BLK_RING_SIZE];
> >> +     struct llist_head persistent_gnts;
> >> +     unsigned int persistent_gnts_c;
> >>       unsigned long shadow_free;
> >>       unsigned int feature_flush;
> >>       unsigned int flush_op;
> >> @@ -287,21 +297,36 @@ static int blkif_queue_request(struct request *r=
eq)
> >>       unsigned long id;
> >>       unsigned int fsect, lsect;
> >>       int i, ref;
> >> +
> >> +     /*
> >> +      * Used to store if we are able to queue the request by just usi=
ng
> >> +      * existing persistent grants (0), or if we have to get new gran=
ts,
> > =

> > What does the zero mean?
> =

> Frankly, no idea, I guess it was in Oliver's patch and I missed to spot i=
t.
> =

> >> +      * as there are not sufficiently many free.
> >> +      */
> >> +     int new_persistent_gnts;
> > =

> > I think this can be a bool?
> =

> I agree.
> =

> >>       grant_ref_t gref_head;
> >> +     struct page *granted_page;
> >> +     struct grant *gnt_list_entry =3D NULL;
> >>       struct scatterlist *sg;
> >>
> >>       if (unlikely(info->connected !=3D BLKIF_STATE_CONNECTED))
> >>               return 1;
> >>
> >> -     if (gnttab_alloc_grant_references(
> >> -             BLKIF_MAX_SEGMENTS_PER_REQUEST, &gref_head) < 0) {
> >> -             gnttab_request_free_callback(
> >> -                     &info->callback,
> >> -                     blkif_restart_queue_callback,
> >> -                     info,
> >> -                     BLKIF_MAX_SEGMENTS_PER_REQUEST);
> >> -             return 1;
> >> -     }
> >> +     /* Check if we have enought grants to allocate a requests */
> >> +     if (info->persistent_gnts_c < BLKIF_MAX_SEGMENTS_PER_REQUEST) {
> >> +             new_persistent_gnts =3D 1;
> >> +             if (gnttab_alloc_grant_references(
> >> +                 BLKIF_MAX_SEGMENTS_PER_REQUEST - info->persistent_gn=
ts_c,
> >> +                 &gref_head) < 0) {
> >> +                     gnttab_request_free_callback(
> >> +                             &info->callback,
> >> +                             blkif_restart_queue_callback,
> >> +                             info,
> >> +                             BLKIF_MAX_SEGMENTS_PER_REQUEST);
> >> +                     return 1;
> >> +             }
> >> +     } else
> >> +             new_persistent_gnts =3D 0;
> >>
> >>       /* Fill out a communications ring structure. */
> >>       ring_req =3D RING_GET_REQUEST(&info->ring, info->ring.req_prod_p=
vt);
> >> @@ -341,18 +366,73 @@ static int blkif_queue_request(struct request *r=
eq)
> >>                      BLKIF_MAX_SEGMENTS_PER_REQUEST);
> >>
> >>               for_each_sg(info->sg, sg, ring_req->u.rw.nr_segments, i)=
 {
> >> -                     buffer_mfn =3D pfn_to_mfn(page_to_pfn(sg_page(sg=
)));
> >>                       fsect =3D sg->offset >> 9;
> >>                       lsect =3D fsect + (sg->length >> 9) - 1;
> >> -                     /* install a grant reference. */
> >> -                     ref =3D gnttab_claim_grant_reference(&gref_head);
> >> -                     BUG_ON(ref =3D=3D -ENOSPC);
> >>
> >> -                     gnttab_grant_foreign_access_ref(
> >> -                                     ref,
> >> +                     if (info->persistent_gnts_c) {
> >> +                             BUG_ON(llist_empty(&info->persistent_gnt=
s));
> >> +                             gnt_list_entry =3D llist_entry(
> >> +                                     llist_del_first(&info->persisten=
t_gnts),
> >> +                                     struct grant, node);
> >> +
> >> +                             ref =3D gnt_list_entry->gref;
> >> +                             buffer_mfn =3D pfn_to_mfn(gnt_list_entry=
->pfn);
> >> +                             info->persistent_gnts_c--;
> >> +                     } else {
> >> +                             ref =3D gnttab_claim_grant_reference(&gr=
ef_head);
> >> +                             BUG_ON(ref =3D=3D -ENOSPC);
> >> +
> >> +                             gnt_list_entry =3D
> >> +                                     kmalloc(sizeof(struct grant),
> >> +                                                      GFP_ATOMIC);
> >> +                             if (!gnt_list_entry)
> >> +                                     return -ENOMEM;
> >> +
> >> +                             granted_page =3D alloc_page(GFP_ATOMIC);
> >> +                             if (!granted_page) {
> >> +                                     kfree(gnt_list_entry);
> >> +                                     return -ENOMEM;
> >> +                             }
> >> +
> >> +                             gnt_list_entry->pfn =3D
> >> +                                     page_to_pfn(granted_page);
> >> +                             gnt_list_entry->gref =3D ref;
> >> +
> >> +                             buffer_mfn =3D pfn_to_mfn(page_to_pfn(
> >> +                                                             granted_=
page));
> >> +                             gnttab_grant_foreign_access_ref(ref,
> >>                                       info->xbdev->otherend_id,
> >> -                                     buffer_mfn,
> >> -                                     rq_data_dir(req));
> >> +                                     buffer_mfn, 0);
> >> +                     }
> >> +
> >> +                     info->shadow[id].grants_used[i] =3D gnt_list_ent=
ry;
> >> +
> >> +                     if (rq_data_dir(req)) {
> >> +                             char *bvec_data;
> >> +                             void *shared_data;
> >> +
> >> +                             BUG_ON(sg->offset + sg->length > PAGE_SI=
ZE);
> >> +
> >> +                             shared_data =3D kmap_atomic(
> >> +                                     pfn_to_page(gnt_list_entry->pfn)=
);
> >> +                             bvec_data =3D kmap_atomic(sg_page(sg));
> >> +
> >> +                             /*
> >> +                              * this does not wipe data stored outsid=
e the
> >> +                              * range sg->offset..sg->offset+sg->leng=
th.
> >> +                              * Therefore, blkback *could* see data f=
rom
> >> +                              * previous requests. This is OK as long=
 as
> >> +                              * persistent grants are shared with jus=
t one
> >> +                              * domain. It may need refactoring if Th=
is
> > .. this (lowercase it pls)
> =

> Done.
> =

> > =

> >> +                              * changes
> >> +                              */
> >> +                             memcpy(shared_data + sg->offset,
> >> +                                    bvec_data   + sg->offset,
> >> +                                    sg->length);
> >> +
> >> +                             kunmap_atomic(bvec_data);
> >> +                             kunmap_atomic(shared_data);
> >> +                     }
> >>
> >>                       info->shadow[id].frame[i] =3D mfn_to_pfn(buffer_=
mfn);
> >>                       ring_req->u.rw.seg[i] =3D
> >> @@ -368,7 +448,8 @@ static int blkif_queue_request(struct request *req)
> >>       /* Keep a private copy so we can reissue requests when recoverin=
g. */
> >>       info->shadow[id].req =3D *ring_req;
> >>
> >> -     gnttab_free_grant_references(gref_head);
> >> +     if (new_persistent_gnts)
> >> +             gnttab_free_grant_references(gref_head);
> >>
> >>       return 0;
> >>  }
> >> @@ -480,7 +561,7 @@ static int xlvbd_init_blk_queue(struct gendisk *gd=
, u16 sector_size)
> >>  static void xlvbd_flush(struct blkfront_info *info)
> >>  {
> >>       blk_queue_flush(info->rq, info->feature_flush);
> >> -     printk(KERN_INFO "blkfront: %s: %s: %s\n",
> >> +     printk(KERN_INFO "blkfront: %s: %s: %s, using persistent grants\=
n",
> > =

> > HA! By default, eh?
> =

> Yes, you caught me, there's a paragraph in the commit message that
> explains that we are using persistent grants in the frontend
> unconditionally, since the protocol is compatible (you can have a
> persistent blkfront and a non-persistent blkback). It simplifies the
> logic in blkfront. Are you OK with it?

It is OK, but you should be checking whether the backend supports it.
I don't see it checking the info->feature_persistent_grant to print
that.

> =

> >>              info->gd->disk_name,
> >>              info->flush_op =3D=3D BLKIF_OP_WRITE_BARRIER ?
> >>               "barrier" : (info->flush_op =3D=3D BLKIF_OP_FLUSH_DISKCA=
CHE ?
> >> @@ -707,6 +788,9 @@ static void blkif_restart_queue(struct work_struct=
 *work)
> >>
> >>  static void blkif_free(struct blkfront_info *info, int suspend)
> >>  {
> >> +     struct llist_node *all_gnts;
> >> +     struct grant *persistent_gnt;
> >> +
> >>       /* Prevent new requests being issued until we fix things up. */
> >>       spin_lock_irq(&info->io_lock);
> >>       info->connected =3D suspend ?
> >> @@ -714,6 +798,17 @@ static void blkif_free(struct blkfront_info *info=
, int suspend)
> >>       /* No more blkif_request(). */
> >>       if (info->rq)
> >>               blk_stop_queue(info->rq);
> >> +
> >> +     /* Remove all persistent grants */
> >> +     if (info->persistent_gnts_c) {
> >> +             all_gnts =3D llist_del_all(&info->persistent_gnts);
> >> +             llist_for_each_entry(persistent_gnt, all_gnts, node) {
> >> +                     gnttab_end_foreign_access(persistent_gnt->gref, =
0, 0UL);
> >> +                     kfree(persistent_gnt);
> >> +             }
> >> +             info->persistent_gnts_c =3D 0;
> >> +     }
> >> +
> >>       /* No more gnttab callback work. */
> >>       gnttab_cancel_free_callback(&info->callback);
> >>       spin_unlock_irq(&info->io_lock);
> >> @@ -734,13 +829,42 @@ static void blkif_free(struct blkfront_info *inf=
o, int suspend)
> >>
> >>  }
> >>
> >> -static void blkif_completion(struct blk_shadow *s)
> >> +static void blkif_completion(struct blk_shadow *s, struct blkfront_in=
fo *info,
> >> +                          struct blkif_response *bret)
> >>  {
> >>       int i;
> >> -     /* Do not let BLKIF_OP_DISCARD as nr_segment is in the same place
> >> -      * flag. */
> >> -     for (i =3D 0; i < s->req.u.rw.nr_segments; i++)
> >> -             gnttab_end_foreign_access(s->req.u.rw.seg[i].gref, 0, 0U=
L);
> >> +     struct bio_vec *bvec;
> >> +     struct req_iterator iter;
> >> +     unsigned long flags;
> >> +     char *bvec_data;
> >> +     void *shared_data;
> >> +     unsigned int offset =3D 0;
> >> +
> >> +     if (bret->operation =3D=3D BLKIF_OP_READ) {
> >> +             /*
> >> +              * Copy the data received from the backend into the bvec.
> >> +              * Since bv_len can be different from PAGE_SIZE, we need=
 to
> >> +              * be sure we are actually copying the data from the rig=
ht
> >> +              * shared page.
> >> +              */
> >> +             rq_for_each_segment(bvec, s->request, iter) {
> >> +                     BUG_ON((bvec->bv_offset + bvec->bv_len) > PAGE_S=
IZE);
> >> +                     i =3D offset >> PAGE_SHIFT;
> > =

> > Could you also include a comment about the bug you found here, pls?
> =

> There's a comment before the rq_for_each_segment loop, that tries to
> explain that, do you think the following is better?
> =

> /*
>  * Copy the data received from the backend into the bvec.
>  * Since bv_offset can be different than 0, and bv_len different
>  * than PAGE_SIZE, we have to keep track of the current offset,
>  * to be sure we are copying the data from the right shared page.

Yes. That is good.
>  */
> =

> >> +                     shared_data =3D kmap_atomic(
> >> +                             pfn_to_page(s->grants_used[i]->pfn));
> >> +                     bvec_data =3D bvec_kmap_irq(bvec, &flags);
> >> +                     memcpy(bvec_data, shared_data + bvec->bv_offset,
> >> +                             bvec->bv_len);
> >> +                     bvec_kunmap_irq(bvec_data, &flags);
> >> +                     kunmap_atomic(shared_data);
> >> +                     offset +=3D bvec->bv_len;
> >> +             }
> >> +     }
> >> +     /* Add the persistent grant into the list of free grants */
> >> +     for (i =3D 0; i < s->req.u.rw.nr_segments; i++) {
> >> +             llist_add(&s->grants_used[i]->node, &info->persistent_gn=
ts);
> >> +             info->persistent_gnts_c++;
> >> +     }
> >>  }
> >>
> >>  static irqreturn_t blkif_interrupt(int irq, void *dev_id)
> >> @@ -783,7 +907,7 @@ static irqreturn_t blkif_interrupt(int irq, void *=
dev_id)
> >>               req  =3D info->shadow[id].request;
> >>
> >>               if (bret->operation !=3D BLKIF_OP_DISCARD)
> >> -                     blkif_completion(&info->shadow[id]);
> >> +                     blkif_completion(&info->shadow[id], info, bret);
> >>
> >>               if (add_id_to_freelist(info, id)) {
> >>                       WARN(1, "%s: response to %s (id %ld) couldn't be=
 recycled!\n",
> >> @@ -942,6 +1066,11 @@ again:
> >>               message =3D "writing protocol";
> >>               goto abort_transaction;
> >>       }
> >> +     err =3D xenbus_printf(xbt, dev->nodename,
> >> +                         "feature-persistent-grants", "%d", 1);
> > =

> > So its %u in blkback, but %d in here? Which one should it be?
> =

> %u in both places.
> =

> >> +     if (err)
> >> +             dev_warn(&dev->dev,
> >> +                      "writing persistent grants feature to xenbus");
> >>
> >>       err =3D xenbus_transaction_end(xbt, 0);
> >>       if (err) {
> >> @@ -1029,6 +1158,8 @@ static int blkfront_probe(struct xenbus_device *=
dev,
> >>       spin_lock_init(&info->io_lock);
> >>       info->xbdev =3D dev;
> >>       info->vdevice =3D vdevice;
> >> +     init_llist_head(&info->persistent_gnts);
> >> +     info->persistent_gnts_c =3D 0;
> >>       info->connected =3D BLKIF_STATE_DISCONNECTED;
> >>       INIT_WORK(&info->work, blkif_restart_queue);
> >>
> >> @@ -1093,7 +1224,7 @@ static int blkif_recover(struct blkfront_info *i=
nfo)
> >>                                       req->u.rw.seg[j].gref,
> >>                                       info->xbdev->otherend_id,
> >>                                       pfn_to_mfn(info->shadow[req->u.r=
w.id].frame[j]),
> >> -                                     rq_data_dir(info->shadow[req->u.=
rw.id].request));
> >> +                                     0);
> >>               }
> >>               info->shadow[req->u.rw.id].req =3D *req;
> >>
> >> --
> >> 1.7.7.5 (Apple Git-26)
> >>
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-kernel=
" in
> >> the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >> Please read the FAQ at  http://www.tux.org/lkml/
> >>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 17:33:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 17:33:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQiL7-0005wr-EL; Tue, 23 Oct 2012 17:32:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQiL6-0005wm-GG
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 17:32:29 +0000
Received: from [85.158.139.211:56235] by server-15.bemta-5.messagelabs.com id
	44/22-28599-BA4D6805; Tue, 23 Oct 2012 17:32:27 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1351013545!23451389!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODIwNzA4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24279 invoked from network); 23 Oct 2012 17:32:26 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Oct 2012 17:32:26 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9NHWIw8002547
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 23 Oct 2012 17:32:19 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9NHWHDd020221
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 23 Oct 2012 17:32:18 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9NHWHFw032226; Tue, 23 Oct 2012 12:32:17 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 23 Oct 2012 10:32:17 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 94F14403C7; Tue, 23 Oct 2012 13:20:08 -0400 (EDT)
Date: Tue, 23 Oct 2012 13:20:08 -0400
From: Konrad Rzeszutek Wilk 
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= 
Message-ID: <20121023172008.GB11787@phenom.dumpdata.com>
References: <1350559321-19066-1-git-send-email-roger.pau@citrix.com>
	<20121022134708.GA13832@konrad-lan.dumpdata.com>
	<5086C0C8.5000306@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5086C0C8.5000306@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Konrad Rzeszutek Wilk ,
	"linux-kernel@vger.kernel.org" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH RFC] Persistent grant maps for xen blk
	drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 23, 2012 at 06:07:36PM +0200, Roger Pau Monn=E9 wrote:
> On 22/10/12 15:47, Konrad Rzeszutek Wilk wrote:
> > On Thu, Oct 18, 2012 at 01:22:01PM +0200, Roger Pau Monne wrote:
> >> This patch implements persistent grants for the xen-blk{front,back}
> >> mechanism. The effect of this change is to reduce the number of unmap
> >> operations performed, since they cause a (costly) TLB shootdown. This
> >> allows the I/O performance to scale better when a large number of VMs
> >> are performing I/O.
> >>
> >> Previously, the blkfront driver was supplied a bvec[] from the request
> >> queue. This was granted to dom0; dom0 performed the I/O and wrote
> >> directly into the grant-mapped memory and unmapped it; blkfront then
> >> removed foreign access for that grant. The cost of unmapping scales
> >> badly with the number of CPUs in Dom0. An experiment showed that when
> >> Dom0 has 24 VCPUs, and guests are performing parallel I/O to a
> >> ramdisk, the IPIs from performing unmap's is a bottleneck at 5 guests
> >> (at which point 650,000 IOPS are being performed in total). If more
> >> than 5 guests are used, the performance declines. By 10 guests, only
> >> 400,000 IOPS are being performed.
> >>
> >> This patch improves performance by only unmapping when the connection
> >> between blkfront and back is broken.
> >>
> >> On startup blkfront notifies blkback that it is using persistent
> >> grants, and blkback will do the same. If blkback is not capable of
> >> persistent mapping, blkfront will still use the same grants, since it
> >> is compatible with the previous protocol, and simplifies the code
> >> complexity in blkfront.
> >>
> >> To perform a read, in persistent mode, blkfront uses a separate pool
> >> of pages that it maps to dom0. When a request comes in, blkfront
> >> transmutes the request so that blkback will write into one of these
> >> free pages. Blkback keeps note of which grefs it has already
> >> mapped. When a new ring request comes to blkback, it looks to see if
> >> it has already mapped that page. If so, it will not map it again. If
> >> the page hasn't been previously mapped, it is mapped now, and a record
> >> is kept of this mapping. Blkback proceeds as usual. When blkfront is
> >> notified that blkback has completed a request, it memcpy's from the
> >> shared memory, into the bvec supplied. A record that the {gref, page}
> >> tuple is mapped, and not inflight is kept.
> >>
> >> Writes are similar, except that the memcpy is peformed from the
> >> supplied bvecs, into the shared pages, before the request is put onto
> >> the ring.
> >>
> >> Blkback stores a mapping of grefs=3D>{page mapped to by gref} in
> >> a red-black tree. As the grefs are not known apriori, and provide no
> >> guarantees on their ordering, we have to perform a search
> >> through this tree to find the page, for every gref we receive. This
> >> operation takes O(log n) time in the worst case.
> > =

> > Might want to mention how blkfront stores it as well. It looks
> > to be using 'llist' instead of 'list'? Any particular reason?
> =

> Since we are just pushing and poping grant references, I went for what I
> think is the simplest one, a single linked list (list is a doubly linked
> list). Oliver in the previous version was using something similar, but
> custom made. I think it's best to use the data structures provided by
> the kernel itself.
> =

> > =

> >>
> >> The maximum number of grants that blkback will persistenly map is
> >> currently set to RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, to
> >> prevent a malicios guest from attempting a DoS, by supplying fresh
> >> grefs, causing the Dom0 kernel to map excessively. If a guest
> >> is using persistent grants and exceeds the maximum number of grants to
> >> map persistenly the newly passed grefs will be mapped and unmaped.
> >> Using this approach, we can have requests that mix persistent and
> >> non-persistent grants, and we need to handle them correctly.
> >> This allows us to set the maximum number of persistent grants to a
> >> lower value than RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, although
> >> setting it will lead to unpredictable performance.
> >>
> >> In writing this patch, the question arrises as to if the additional
> >> cost of performing memcpys in the guest (to/from the pool of granted
> >> pages) outweigh the gains of not performing TLB shootdowns. The answer
> >> to that question is `no'. There appears to be very little, if any
> >> additional cost to the guest of using persistent grants. There is
> >> perhaps a small saving, from the reduced number of hypercalls
> >> performed in granting, and ending foreign access.
> >>
> >> Signed-off-by: Oliver Chick 
> >> Signed-off-by: Roger Pau Monne 
> >> Cc: 
> >> Cc: 
> >> ---
> >> Benchmarks showing the impact of this patch in blk performance can be
> >> found at:
> >>
> >> http://xenbits.xensource.com/people/royger/persistent_grants/
> >> ---
> >>  drivers/block/xen-blkback/blkback.c |  279 ++++++++++++++++++++++++++=
+++++---
> >>  drivers/block/xen-blkback/common.h  |   17 ++
> >>  drivers/block/xen-blkback/xenbus.c  |   16 ++-
> >>  drivers/block/xen-blkfront.c        |  183 ++++++++++++++++++++----
> >>  4 files changed, 442 insertions(+), 53 deletions(-)
> >>
> >> diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-b=
lkback/blkback.c
> >> index c6decb9..2b982b2 100644
> >> --- a/drivers/block/xen-blkback/blkback.c
> >> +++ b/drivers/block/xen-blkback/blkback.c
> >> @@ -78,6 +78,7 @@ struct pending_req {
> >>       unsigned short          operation;
> >>       int                     status;
> >>       struct list_head        free_list;
> >> +     unsigned int            unmap_seg[BLKIF_MAX_SEGMENTS_PER_REQUEST=
];
> >>  };
> >>
> >>  #define BLKBACK_INVALID_HANDLE (~0)
> >> @@ -98,6 +99,30 @@ struct xen_blkbk {
> >>  static struct xen_blkbk *blkbk;
> >>
> >>  /*
> >> + * Maximum number of grant pages that can be mapped in blkback.
> >> + * BLKIF_MAX_SEGMENTS_PER_REQUEST * RING_SIZE is the maximum number of
> >> + * pages that blkback will persistently map.
> >> + */
> >> +static inline unsigned int max_mapped_grant_pages(enum blkif_protocol=
 protocol)
> >> +{
> >> +     switch (protocol) {
> >> +     case BLKIF_PROTOCOL_NATIVE:
> >> +             return __CONST_RING_SIZE(blkif, PAGE_SIZE) *
> >> +                        BLKIF_MAX_SEGMENTS_PER_REQUEST;
> >> +     case BLKIF_PROTOCOL_X86_32:
> >> +             return __CONST_RING_SIZE(blkif_x86_32, PAGE_SIZE) *
> >> +                        BLKIF_MAX_SEGMENTS_PER_REQUEST;
> >> +     case BLKIF_PROTOCOL_X86_64:
> >> +             return __CONST_RING_SIZE(blkif_x86_64, PAGE_SIZE) *
> >> +                        BLKIF_MAX_SEGMENTS_PER_REQUEST;
> > =

> > Could you include in the comments what the size (bytes) you expect it t=
o be?
> > If that would require you re-doing some tests - then don't worry - but
> > I figured you have some notes scribbled away that have the exact values
> > down.
> =

> As far as I know and remember (I've checked the ring size in the past),
> all ring types have a size of 32, BLKIF_MAX_SEGMENTS_PER_REQUEST is
> always 11, and sizeof(struct persistent_gnt) is 48, so that's 32 * 11 *
> 48 =3D 16896 bytes. I will add a comment with this calculation.
> =

> > =

> >> +     default:
> >> +             BUG();
> >> +     }
> >> +     return 0;
> >> +}
> >> +
> >> +
> >> +/*
> >>   * Little helpful macro to figure out the index and virtual address o=
f the
> >>   * pending_pages[..]. For each 'pending_req' we have have up to
> >>   * BLKIF_MAX_SEGMENTS_PER_REQUEST (11) pages. The seg would be from 0=
 through
> >> @@ -128,6 +153,57 @@ static int dispatch_rw_block_io(struct xen_blkif =
*blkif,
> >>  static void make_response(struct xen_blkif *blkif, u64 id,
> >>                         unsigned short op, int st);
> >>
> >> +#define foreach_grant(pos, rbtree, node) \
> >> +     for ((pos) =3D container_of(rb_first((rbtree)), typeof(*(pos)), =
node); \
> >> +          &(pos)->node !=3D NULL; \
> >> +          (pos) =3D container_of(rb_next(&(pos)->node), typeof(*(pos)=
), node))
> >> +
> >> +
> >> +static void add_persistent_gnt(struct rb_root *root,
> >> +                            struct persistent_gnt *persistent_gnt)
> >> +{
> >> +     struct rb_node **new =3D &(root->rb_node), *parent =3D NULL;
> >> +     struct persistent_gnt *this;
> >> +
> >> +     /* Figure out where to put new node */
> >> +     while (*new) {
> >> +             this =3D container_of(*new, struct persistent_gnt, node);
> >> +
> >> +             parent =3D *new;
> >> +             if (persistent_gnt->gnt < this->gnt)
> >> +                     new =3D &((*new)->rb_left);
> >> +             else if (persistent_gnt->gnt > this->gnt)
> >> +                     new =3D &((*new)->rb_right);
> >> +             else {
> >> +                     pr_alert(DRV_PFX " trying to add a gref that's a=
lready in the tree\n");
> >> +                     BUG();
> >> +             }
> >> +     }
> >> +
> >> +     /* Add new node and rebalance tree. */
> >> +     rb_link_node(&(persistent_gnt->node), parent, new);
> >> +     rb_insert_color(&(persistent_gnt->node), root);
> >> +}
> >> +
> >> +static struct persistent_gnt *get_persistent_gnt(struct rb_root *root,
> >> +                                              grant_ref_t gref)
> >> +{
> >> +     struct persistent_gnt *data;
> >> +     struct rb_node *node =3D root->rb_node;
> >> +
> >> +     while (node) {
> >> +             data =3D container_of(node, struct persistent_gnt, node);
> >> +
> >> +             if (gref < data->gnt)
> >> +                     node =3D node->rb_left;
> >> +             else if (gref > data->gnt)
> >> +                     node =3D node->rb_right;
> >> +             else
> >> +                     return data;
> >> +     }
> >> +     return NULL;
> >> +}
> >> +
> >>  /*
> >>   * Retrieve from the 'pending_reqs' a free pending_req structure to b=
e used.
> >>   */
> >> @@ -274,6 +350,11 @@ int xen_blkif_schedule(void *arg)
> >>  {
> >>       struct xen_blkif *blkif =3D arg;
> >>       struct xen_vbd *vbd =3D &blkif->vbd;
> >> +     struct gnttab_unmap_grant_ref unmap[BLKIF_MAX_SEGMENTS_PER_REQUE=
ST];
> >> +     struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> >> +     struct persistent_gnt *persistent_gnt;
> >> +     int ret =3D 0;
> >> +     int segs_to_unmap =3D 0;
> >>
> >>       xen_blkif_get(blkif);
> >>
> >> @@ -301,6 +382,32 @@ int xen_blkif_schedule(void *arg)
> >>                       print_stats(blkif);
> >>       }
> >>
> >> +     /* Free all persistent grant pages */
> >> +     foreach_grant(persistent_gnt, &blkif->persistent_gnts, node) {
> > =

> > Just for sanity - you did check this with blkfronts that did not have
> > persistent grants enabled, right?
> =

> Yes, it doesn't crash, but looking at foreach_grant it seems like it
> should. I've added a check before trying to iterate over the tree.
> =

> > =

> >> +             BUG_ON(persistent_gnt->handle =3D=3D BLKBACK_INVALID_HAN=
DLE);
> >> +             gnttab_set_unmap_op(&unmap[segs_to_unmap],
> >> +                 (unsigned long) pfn_to_kaddr(page_to_pfn(
> >> +                     persistent_gnt->page)),
> >> +                 GNTMAP_host_map,
> >> +                 persistent_gnt->handle);
> >> +
> >> +             pages[segs_to_unmap] =3D persistent_gnt->page;
> >> +             rb_erase(&persistent_gnt->node, &blkif->persistent_gnts);
> >> +             kfree(persistent_gnt);
> >> +             blkif->persistent_gnt_c--;
> >> +
> >> +             if (++segs_to_unmap =3D=3D BLKIF_MAX_SEGMENTS_PER_REQUES=
T ||
> >> +                     !rb_next(&persistent_gnt->node)) {
> >> +                     ret =3D gnttab_unmap_refs(unmap, NULL, pages,
> >> +                                             segs_to_unmap);
> >> +                     BUG_ON(ret);
> >> +                     segs_to_unmap =3D 0;
> >> +             }
> >> +     }
> >> +
> >> +     BUG_ON(blkif->persistent_gnt_c !=3D 0);
> >> +     BUG_ON(!RB_EMPTY_ROOT(&blkif->persistent_gnts));
> >> +
> >>       if (log_stats)
> >>               print_stats(blkif);
> >>
> >> @@ -327,6 +434,8 @@ static void xen_blkbk_unmap(struct pending_req *re=
q)
> >>       int ret;
> >>
> >>       for (i =3D 0; i < req->nr_pages; i++) {
> >> +             if (!req->unmap_seg[i])
> >> +                     continue;
> > =

> > Perhaps there should be a #define for that array..
> =

> Do you mean something like:
> =

> #define unmap(req, i) req->unmap_seg[i]

I was thinking that you just check for req->unamp_seg[i] to
have an non-zero value. But since that array is just used as an check
to see whether the functionality is enabled (or not), you might want
to declerare the right values so:
#define UNMAP_SG_ON 1
#define UNMAP_SG_OFF 0

or so.

> =

> >>               handle =3D pending_handle(req, i);
> >>               if (handle =3D=3D BLKBACK_INVALID_HANDLE)
> >>                       continue;
> >> @@ -343,12 +452,26 @@ static void xen_blkbk_unmap(struct pending_req *=
req)
> >>
> >>  static int xen_blkbk_map(struct blkif_request *req,
> >>                        struct pending_req *pending_req,
> >> -                      struct seg_buf seg[])
> >> +                      struct seg_buf seg[],
> >> +                      struct page *pages[])
> >>  {
> >>       struct gnttab_map_grant_ref map[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> >> -     int i;
> >> +     struct persistent_gnt *persistent_gnts[BLKIF_MAX_SEGMENTS_PER_RE=
QUEST];
> >> +     struct page *pages_to_gnt[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> >> +     struct persistent_gnt *persistent_gnt =3D NULL;
> >> +     struct xen_blkif *blkif =3D pending_req->blkif;
> >> +     phys_addr_t addr =3D 0;
> >> +     int i, j;
> >> +     int new_map;
> > =

> > Just use a bool for this.
> =

> Done
> =

> >>       int nseg =3D req->u.rw.nr_segments;
> >> +     int segs_to_map =3D 0;
> >>       int ret =3D 0;
> >> +     int use_persistent_gnts;
> >> +
> >> +     use_persistent_gnts =3D (blkif->vbd.feature_gnt_persistent);
> >> +
> >> +     BUG_ON(blkif->persistent_gnt_c >
> >> +                max_mapped_grant_pages(pending_req->blkif->blk_protoc=
ol));
> >>
> >>       /*
> >>        * Fill out preq.nr_sects with proper amount of sectors, and set=
up
> >> @@ -358,36 +481,141 @@ static int xen_blkbk_map(struct blkif_request *=
req,
> >>       for (i =3D 0; i < nseg; i++) {
> >>               uint32_t flags;
> >>
> >> -             flags =3D GNTMAP_host_map;
> >> -             if (pending_req->operation !=3D BLKIF_OP_READ)
> >> -                     flags |=3D GNTMAP_readonly;
> >> -             gnttab_set_map_op(&map[i], vaddr(pending_req, i), flags,
> >> -                               req->u.rw.seg[i].gref,
> >> -                               pending_req->blkif->domid);
> >> +             if (use_persistent_gnts)
> >> +                     persistent_gnt =3D get_persistent_gnt(
> >> +                             &blkif->persistent_gnts,
> >> +                             req->u.rw.seg[i].gref);
> >> +
> >> +             if (persistent_gnt) {
> >> +                     /*
> >> +                      * We are using persistent grants and
> >> +                      * the grant is already mapped
> >> +                      */
> >> +                     new_map =3D 0;
> >> +             } else if (use_persistent_gnts &&
> >> +                        blkif->persistent_gnt_c <
> >> +                        max_mapped_grant_pages(blkif->blk_protocol)) {
> >> +                     /*
> >> +                      * We are using persistent grants, the grant is
> >> +                      * not mapped but we have room for it
> >> +                      */
> >> +                     new_map =3D 1;
> >> +                     persistent_gnt =3D kzalloc(
> >> +                             sizeof(struct persistent_gnt),
> >> +                             GFP_KERNEL);
> >> +                     if (!persistent_gnt)
> >> +                             return -ENOMEM;
> >> +                     persistent_gnt->page =3D alloc_page(GFP_KERNEL);
> >> +                     if (!persistent_gnt->page) {
> >> +                             kfree(persistent_gnt);
> >> +                             return -ENOMEM;
> >> +                     }
> >> +                     persistent_gnt->gnt =3D req->u.rw.seg[i].gref;
> >> +
> >> +                     pages_to_gnt[segs_to_map] =3D
> >> +                             persistent_gnt->page;
> >> +                     addr =3D (unsigned long) pfn_to_kaddr(
> >> +                             page_to_pfn(persistent_gnt->page));
> >> +
> >> +                     add_persistent_gnt(&blkif->persistent_gnts,
> >> +                             persistent_gnt);
> >> +                     blkif->persistent_gnt_c++;
> >> +                     pr_debug(DRV_PFX " grant %u added to the tree of=
 persistent grants, using %u/%u\n",
> >> +                              persistent_gnt->gnt, blkif->persistent_=
gnt_c,
> >> +                              max_mapped_grant_pages(blkif->blk_proto=
col));
> >> +             } else {
> >> +                     /*
> >> +                      * We are either using persistent grants and
> >> +                      * hit the maximum limit of grants mapped,
> >> +                      * or we are not using persistent grants.
> >> +                      */
> >> +                     if (use_persistent_gnts &&
> >> +                             !blkif->vbd.overflow_max_grants) {
> >> +                             blkif->vbd.overflow_max_grants =3D 1;
> >> +                             pr_alert(DRV_PFX " domain %u, device %#x=
 is using maximum number of persistent grants\n",
> >> +                                      blkif->domid, blkif->vbd.handle=
);
> >> +                     }
> >> +                     new_map =3D 1;
> >> +                     pages[i] =3D blkbk->pending_page(pending_req, i);
> >> +                     addr =3D vaddr(pending_req, i);
> >> +                     pages_to_gnt[segs_to_map] =3D
> >> +                             blkbk->pending_page(pending_req, i);
> >> +             }
> >> +
> >> +             if (persistent_gnt) {
> >> +                     pages[i] =3D persistent_gnt->page;
> >> +                     persistent_gnts[i] =3D persistent_gnt;
> >> +             } else {
> >> +                     persistent_gnts[i] =3D NULL;
> >> +             }
> >> +
> >> +             if (new_map) {
> >> +                     flags =3D GNTMAP_host_map;
> >> +                     if (!persistent_gnt &&
> >> +                         (pending_req->operation !=3D BLKIF_OP_READ))
> >> +                             flags |=3D GNTMAP_readonly;
> >> +                     gnttab_set_map_op(&map[segs_to_map++], addr,
> >> +                                       flags, req->u.rw.seg[i].gref,
> >> +                                       blkif->domid);
> >> +             }
> >>       }
> >>
> >> -     ret =3D gnttab_map_refs(map, NULL, &blkbk->pending_page(pending_=
req, 0), nseg);
> >> -     BUG_ON(ret);
> >> +     if (segs_to_map) {
> >> +             ret =3D gnttab_map_refs(map, NULL, pages_to_gnt, segs_to=
_map);
> >> +             BUG_ON(ret);
> >> +     }
> >>
> >>       /*
> >>        * Now swizzle the MFN in our domain with the MFN from the other=
 domain
> >>        * so that when we access vaddr(pending_req,i) it has the conten=
ts of
> >>        * the page from the other domain.
> >>        */
> >> -     for (i =3D 0; i < nseg; i++) {
> >> -             if (unlikely(map[i].status !=3D 0)) {
> >> -                     pr_debug(DRV_PFX "invalid buffer -- could not re=
map it\n");
> >> -                     map[i].handle =3D BLKBACK_INVALID_HANDLE;
> >> -                     ret |=3D 1;
> >> +     for (i =3D 0, j =3D 0; i < nseg; i++) {
> >> +             if (!persistent_gnts[i] || !persistent_gnts[i]->handle) {
> >> +                     /* This is a newly mapped grant */
> >> +                     BUG_ON(j >=3D segs_to_map);
> >> +                     if (unlikely(map[j].status !=3D 0)) {
> > =

> > I am not seeing j being incremented anywhere? Should it?
> =

> Yes, it should be incremented, but not here. See the comment below to
> see what I've changed.
> =

> > =

> >> +                             pr_debug(DRV_PFX "invalid buffer -- coul=
d not remap it\n");
> >> +                             map[j].handle =3D BLKBACK_INVALID_HANDLE;
> >> +                             ret |=3D 1;
> >> +                             if (persistent_gnts[i]) {
> >> +                                     rb_erase(&persistent_gnts[i]->no=
de,
> >> +                                              &blkif->persistent_gnts=
);
> >> +                                     blkif->persistent_gnt_c--;
> >> +                                     kfree(persistent_gnts[i]);
> >> +                                     persistent_gnts[i] =3D NULL;
> >> +                             }
> >> +                     }
> >> +             }
> >> +             if (persistent_gnts[i]) {
> >> +                     if (!persistent_gnts[i]->handle) {
> >> +                             /*
> >> +                              * If this is a new persistent grant
> >> +                              * save the handler
> >> +                              */
> >> +                             persistent_gnts[i]->handle =3D map[j].ha=
ndle;
> >> +                             persistent_gnts[i]->dev_bus_addr =3D
> >> +                                     map[j++].dev_bus_addr;
> >> +                     }
> >> +                     pending_handle(pending_req, i) =3D
> >> +                             persistent_gnts[i]->handle;
> >> +                     pending_req->unmap_seg[i] =3D 0;
> > =

> > Could we have a #define for that?
> =

> Sure.
> =

> >> +
> >> +                     if (ret)
> >> +                             continue;
> =

> This should be
> =

> if (ret) {
> 	j++;
> 	continue;
> }


> =

> >> +
> >> +                     seg[i].buf =3D persistent_gnts[i]->dev_bus_addr |
> >> +                             (req->u.rw.seg[i].first_sect << 9);
> >> +             } else {
> >> +                     pending_handle(pending_req, i) =3D map[j].handle;
> >> +                     pending_req->unmap_seg[i] =3D 1;
> > =

> > And here as well?
> =

> Done.
> =

> >> +
> >> +                     if (ret)
> >> +                             continue;
> >> +
> >> +                     seg[i].buf =3D map[j++].dev_bus_addr |
> >> +                             (req->u.rw.seg[i].first_sect << 9);
> >>               }
> >> -
> >> -             pending_handle(pending_req, i) =3D map[i].handle;
> >> -
> >> -             if (ret)
> >> -                     continue;
> >> -
> >> -             seg[i].buf  =3D map[i].dev_bus_addr |
> >> -                     (req->u.rw.seg[i].first_sect << 9);
> >>       }
> >>       return ret;
> >>  }
> >> @@ -590,6 +818,7 @@ static int dispatch_rw_block_io(struct xen_blkif *=
blkif,
> >>       int operation;
> >>       struct blk_plug plug;
> >>       bool drain =3D false;
> >> +     struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> >>
> >>       switch (req->operation) {
> >>       case BLKIF_OP_READ:
> >> @@ -676,7 +905,7 @@ static int dispatch_rw_block_io(struct xen_blkif *=
blkif,
> >>        * the hypercall to unmap the grants - that is all done in
> >>        * xen_blkbk_unmap.
> >>        */
> >> -     if (xen_blkbk_map(req, pending_req, seg))
> >> +     if (xen_blkbk_map(req, pending_req, seg, pages))
> >>               goto fail_flush;
> >>
> >>       /*
> >> @@ -688,7 +917,7 @@ static int dispatch_rw_block_io(struct xen_blkif *=
blkif,
> >>       for (i =3D 0; i < nseg; i++) {
> >>               while ((bio =3D=3D NULL) ||
> >>                      (bio_add_page(bio,
> >> -                                  blkbk->pending_page(pending_req, i),
> >> +                                  pages[i],
> >>                                    seg[i].nsec << 9,
> >>                                    seg[i].buf & ~PAGE_MASK) =3D=3D 0))=
 {
> >>
> >> diff --git a/drivers/block/xen-blkback/common.h b/drivers/block/xen-bl=
kback/common.h
> >> index 9ad3b5e..6c08ee9 100644
> >> --- a/drivers/block/xen-blkback/common.h
> >> +++ b/drivers/block/xen-blkback/common.h
> >> @@ -34,6 +34,7 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >>  #include 
> >>  #include 
> >>  #include 
> >> @@ -160,10 +161,22 @@ struct xen_vbd {
> >>       sector_t                size;
> >>       bool                    flush_support;
> >>       bool                    discard_secure;
> >> +
> >> +     unsigned int            feature_gnt_persistent:1;
> >> +     unsigned int            overflow_max_grants:1;
> > =

> > I think the v3.7-rc1 has this structure changed just a tiny bit, so you
> > might want to rebase it on top of that.
> =

> I've done the rebase on top of your linux-next branch, commit
> ad502612c173fff239250c9fe9bdfaaef70b9901.

Thx
> =

> > =

> >>  };
> >>
> >>  struct backend_info;
> >>
> >> +
> >> +struct persistent_gnt {
> >> +     struct page *page;
> >> +     grant_ref_t gnt;
> >> +     grant_handle_t handle;
> >> +     uint64_t dev_bus_addr;
> >> +     struct rb_node node;
> >> +};
> >> +
> >>  struct xen_blkif {
> >>       /* Unique identifier for this interface. */
> >>       domid_t                 domid;
> >> @@ -190,6 +203,10 @@ struct xen_blkif {
> >>       struct task_struct      *xenblkd;
> >>       unsigned int            waiting_reqs;
> >>
> >> +     /* frontend feature information */
> > =

> > Huh?
> =

> Changed it to:
> =

> /* tree to store persistent grants */
> =

> >> +     struct rb_root          persistent_gnts;
> >> +     unsigned int            persistent_gnt_c;
> >> +
> >>       /* statistics */
> >>       unsigned long           st_print;
> >>       int                     st_rd_req;
> >> diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-bl=
kback/xenbus.c
> >> index 4f66171..9f88b4e 100644
> >> --- a/drivers/block/xen-blkback/xenbus.c
> >> +++ b/drivers/block/xen-blkback/xenbus.c
> >> @@ -118,6 +118,7 @@ static struct xen_blkif *xen_blkif_alloc(domid_t d=
omid)
> >>       atomic_set(&blkif->drain, 0);
> >>       blkif->st_print =3D jiffies;
> >>       init_waitqueue_head(&blkif->waiting_to_free);
> >> +     blkif->persistent_gnts.rb_node =3D NULL;
> >>
> >>       return blkif;
> >>  }
> >> @@ -721,6 +722,7 @@ static int connect_ring(struct backend_info *be)
> >>       struct xenbus_device *dev =3D be->dev;
> >>       unsigned long ring_ref;
> >>       unsigned int evtchn;
> >> +     unsigned int pers_grants;
> >>       char protocol[64] =3D "";
> >>       int err;
> >>
> >> @@ -750,8 +752,18 @@ static int connect_ring(struct backend_info *be)
> >>               xenbus_dev_fatal(dev, err, "unknown fe protocol %s", pro=
tocol);
> >>               return -1;
> >>       }
> >> -     pr_info(DRV_PFX "ring-ref %ld, event-channel %d, protocol %d (%s=
)\n",
> >> -             ring_ref, evtchn, be->blkif->blk_protocol, protocol);
> >> +     err =3D xenbus_gather(XBT_NIL, dev->otherend,
> >> +                         "feature-persistent-grants", "%u",
> >> +                         &pers_grants, NULL);
> >> +     if (err)
> >> +             pers_grants =3D 0;
> >> +
> >> +     be->blkif->vbd.feature_gnt_persistent =3D pers_grants;
> >> +     be->blkif->vbd.overflow_max_grants =3D 0;
> >> +
> >> +     pr_info(DRV_PFX "ring-ref %ld, event-channel %d, protocol %d (%s=
) persistent %d\n",
> >> +             ring_ref, evtchn, be->blkif->blk_protocol, protocol,
> >> +             pers_grants);
> > =

> > Can you make that a string? So it is
> >  pers_grants ? "persistent grants" : ""
> > =

> > instead of a zero of one value pls?
> =

> Yes, done.
> =

> >>
> >>       /* Map the shared frame, irq etc. */
> >>       err =3D xen_blkif_map(be->blkif, ring_ref, evtchn);
> >> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront=
.c
> >> index 2c2d2e5..206d422 100644
> >> --- a/drivers/block/xen-blkfront.c
> >> +++ b/drivers/block/xen-blkfront.c
> >> @@ -44,6 +44,7 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >>
> >>  #include 
> >>  #include 
> >> @@ -64,10 +65,17 @@ enum blkif_state {
> >>       BLKIF_STATE_SUSPENDED,
> >>  };
> >>
> >> +struct grant {
> >> +     grant_ref_t gref;
> >> +     unsigned long pfn;
> >> +     struct llist_node node;
> >> +};
> >> +
> >>  struct blk_shadow {
> >>       struct blkif_request req;
> >>       struct request *request;
> >>       unsigned long frame[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> >> +     struct grant *grants_used[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> >>  };
> >>
> >>  static DEFINE_MUTEX(blkfront_mutex);
> >> @@ -97,6 +105,8 @@ struct blkfront_info
> >>       struct work_struct work;
> >>       struct gnttab_free_callback callback;
> >>       struct blk_shadow shadow[BLK_RING_SIZE];
> >> +     struct llist_head persistent_gnts;
> >> +     unsigned int persistent_gnts_c;
> >>       unsigned long shadow_free;
> >>       unsigned int feature_flush;
> >>       unsigned int flush_op;
> >> @@ -287,21 +297,36 @@ static int blkif_queue_request(struct request *r=
eq)
> >>       unsigned long id;
> >>       unsigned int fsect, lsect;
> >>       int i, ref;
> >> +
> >> +     /*
> >> +      * Used to store if we are able to queue the request by just usi=
ng
> >> +      * existing persistent grants (0), or if we have to get new gran=
ts,
> > =

> > What does the zero mean?
> =

> Frankly, no idea, I guess it was in Oliver's patch and I missed to spot i=
t.
> =

> >> +      * as there are not sufficiently many free.
> >> +      */
> >> +     int new_persistent_gnts;
> > =

> > I think this can be a bool?
> =

> I agree.
> =

> >>       grant_ref_t gref_head;
> >> +     struct page *granted_page;
> >> +     struct grant *gnt_list_entry =3D NULL;
> >>       struct scatterlist *sg;
> >>
> >>       if (unlikely(info->connected !=3D BLKIF_STATE_CONNECTED))
> >>               return 1;
> >>
> >> -     if (gnttab_alloc_grant_references(
> >> -             BLKIF_MAX_SEGMENTS_PER_REQUEST, &gref_head) < 0) {
> >> -             gnttab_request_free_callback(
> >> -                     &info->callback,
> >> -                     blkif_restart_queue_callback,
> >> -                     info,
> >> -                     BLKIF_MAX_SEGMENTS_PER_REQUEST);
> >> -             return 1;
> >> -     }
> >> +     /* Check if we have enought grants to allocate a requests */
> >> +     if (info->persistent_gnts_c < BLKIF_MAX_SEGMENTS_PER_REQUEST) {
> >> +             new_persistent_gnts =3D 1;
> >> +             if (gnttab_alloc_grant_references(
> >> +                 BLKIF_MAX_SEGMENTS_PER_REQUEST - info->persistent_gn=
ts_c,
> >> +                 &gref_head) < 0) {
> >> +                     gnttab_request_free_callback(
> >> +                             &info->callback,
> >> +                             blkif_restart_queue_callback,
> >> +                             info,
> >> +                             BLKIF_MAX_SEGMENTS_PER_REQUEST);
> >> +                     return 1;
> >> +             }
> >> +     } else
> >> +             new_persistent_gnts =3D 0;
> >>
> >>       /* Fill out a communications ring structure. */
> >>       ring_req =3D RING_GET_REQUEST(&info->ring, info->ring.req_prod_p=
vt);
> >> @@ -341,18 +366,73 @@ static int blkif_queue_request(struct request *r=
eq)
> >>                      BLKIF_MAX_SEGMENTS_PER_REQUEST);
> >>
> >>               for_each_sg(info->sg, sg, ring_req->u.rw.nr_segments, i)=
 {
> >> -                     buffer_mfn =3D pfn_to_mfn(page_to_pfn(sg_page(sg=
)));
> >>                       fsect =3D sg->offset >> 9;
> >>                       lsect =3D fsect + (sg->length >> 9) - 1;
> >> -                     /* install a grant reference. */
> >> -                     ref =3D gnttab_claim_grant_reference(&gref_head);
> >> -                     BUG_ON(ref =3D=3D -ENOSPC);
> >>
> >> -                     gnttab_grant_foreign_access_ref(
> >> -                                     ref,
> >> +                     if (info->persistent_gnts_c) {
> >> +                             BUG_ON(llist_empty(&info->persistent_gnt=
s));
> >> +                             gnt_list_entry =3D llist_entry(
> >> +                                     llist_del_first(&info->persisten=
t_gnts),
> >> +                                     struct grant, node);
> >> +
> >> +                             ref =3D gnt_list_entry->gref;
> >> +                             buffer_mfn =3D pfn_to_mfn(gnt_list_entry=
->pfn);
> >> +                             info->persistent_gnts_c--;
> >> +                     } else {
> >> +                             ref =3D gnttab_claim_grant_reference(&gr=
ef_head);
> >> +                             BUG_ON(ref =3D=3D -ENOSPC);
> >> +
> >> +                             gnt_list_entry =3D
> >> +                                     kmalloc(sizeof(struct grant),
> >> +                                                      GFP_ATOMIC);
> >> +                             if (!gnt_list_entry)
> >> +                                     return -ENOMEM;
> >> +
> >> +                             granted_page =3D alloc_page(GFP_ATOMIC);
> >> +                             if (!granted_page) {
> >> +                                     kfree(gnt_list_entry);
> >> +                                     return -ENOMEM;
> >> +                             }
> >> +
> >> +                             gnt_list_entry->pfn =3D
> >> +                                     page_to_pfn(granted_page);
> >> +                             gnt_list_entry->gref =3D ref;
> >> +
> >> +                             buffer_mfn =3D pfn_to_mfn(page_to_pfn(
> >> +                                                             granted_=
page));
> >> +                             gnttab_grant_foreign_access_ref(ref,
> >>                                       info->xbdev->otherend_id,
> >> -                                     buffer_mfn,
> >> -                                     rq_data_dir(req));
> >> +                                     buffer_mfn, 0);
> >> +                     }
> >> +
> >> +                     info->shadow[id].grants_used[i] =3D gnt_list_ent=
ry;
> >> +
> >> +                     if (rq_data_dir(req)) {
> >> +                             char *bvec_data;
> >> +                             void *shared_data;
> >> +
> >> +                             BUG_ON(sg->offset + sg->length > PAGE_SI=
ZE);
> >> +
> >> +                             shared_data =3D kmap_atomic(
> >> +                                     pfn_to_page(gnt_list_entry->pfn)=
);
> >> +                             bvec_data =3D kmap_atomic(sg_page(sg));
> >> +
> >> +                             /*
> >> +                              * this does not wipe data stored outsid=
e the
> >> +                              * range sg->offset..sg->offset+sg->leng=
th.
> >> +                              * Therefore, blkback *could* see data f=
rom
> >> +                              * previous requests. This is OK as long=
 as
> >> +                              * persistent grants are shared with jus=
t one
> >> +                              * domain. It may need refactoring if Th=
is
> > .. this (lowercase it pls)
> =

> Done.
> =

> > =

> >> +                              * changes
> >> +                              */
> >> +                             memcpy(shared_data + sg->offset,
> >> +                                    bvec_data   + sg->offset,
> >> +                                    sg->length);
> >> +
> >> +                             kunmap_atomic(bvec_data);
> >> +                             kunmap_atomic(shared_data);
> >> +                     }
> >>
> >>                       info->shadow[id].frame[i] =3D mfn_to_pfn(buffer_=
mfn);
> >>                       ring_req->u.rw.seg[i] =3D
> >> @@ -368,7 +448,8 @@ static int blkif_queue_request(struct request *req)
> >>       /* Keep a private copy so we can reissue requests when recoverin=
g. */
> >>       info->shadow[id].req =3D *ring_req;
> >>
> >> -     gnttab_free_grant_references(gref_head);
> >> +     if (new_persistent_gnts)
> >> +             gnttab_free_grant_references(gref_head);
> >>
> >>       return 0;
> >>  }
> >> @@ -480,7 +561,7 @@ static int xlvbd_init_blk_queue(struct gendisk *gd=
, u16 sector_size)
> >>  static void xlvbd_flush(struct blkfront_info *info)
> >>  {
> >>       blk_queue_flush(info->rq, info->feature_flush);
> >> -     printk(KERN_INFO "blkfront: %s: %s: %s\n",
> >> +     printk(KERN_INFO "blkfront: %s: %s: %s, using persistent grants\=
n",
> > =

> > HA! By default, eh?
> =

> Yes, you caught me, there's a paragraph in the commit message that
> explains that we are using persistent grants in the frontend
> unconditionally, since the protocol is compatible (you can have a
> persistent blkfront and a non-persistent blkback). It simplifies the
> logic in blkfront. Are you OK with it?

It is OK, but you should be checking whether the backend supports it.
I don't see it checking the info->feature_persistent_grant to print
that.

> =

> >>              info->gd->disk_name,
> >>              info->flush_op =3D=3D BLKIF_OP_WRITE_BARRIER ?
> >>               "barrier" : (info->flush_op =3D=3D BLKIF_OP_FLUSH_DISKCA=
CHE ?
> >> @@ -707,6 +788,9 @@ static void blkif_restart_queue(struct work_struct=
 *work)
> >>
> >>  static void blkif_free(struct blkfront_info *info, int suspend)
> >>  {
> >> +     struct llist_node *all_gnts;
> >> +     struct grant *persistent_gnt;
> >> +
> >>       /* Prevent new requests being issued until we fix things up. */
> >>       spin_lock_irq(&info->io_lock);
> >>       info->connected =3D suspend ?
> >> @@ -714,6 +798,17 @@ static void blkif_free(struct blkfront_info *info=
, int suspend)
> >>       /* No more blkif_request(). */
> >>       if (info->rq)
> >>               blk_stop_queue(info->rq);
> >> +
> >> +     /* Remove all persistent grants */
> >> +     if (info->persistent_gnts_c) {
> >> +             all_gnts =3D llist_del_all(&info->persistent_gnts);
> >> +             llist_for_each_entry(persistent_gnt, all_gnts, node) {
> >> +                     gnttab_end_foreign_access(persistent_gnt->gref, =
0, 0UL);
> >> +                     kfree(persistent_gnt);
> >> +             }
> >> +             info->persistent_gnts_c =3D 0;
> >> +     }
> >> +
> >>       /* No more gnttab callback work. */
> >>       gnttab_cancel_free_callback(&info->callback);
> >>       spin_unlock_irq(&info->io_lock);
> >> @@ -734,13 +829,42 @@ static void blkif_free(struct blkfront_info *inf=
o, int suspend)
> >>
> >>  }
> >>
> >> -static void blkif_completion(struct blk_shadow *s)
> >> +static void blkif_completion(struct blk_shadow *s, struct blkfront_in=
fo *info,
> >> +                          struct blkif_response *bret)
> >>  {
> >>       int i;
> >> -     /* Do not let BLKIF_OP_DISCARD as nr_segment is in the same place
> >> -      * flag. */
> >> -     for (i =3D 0; i < s->req.u.rw.nr_segments; i++)
> >> -             gnttab_end_foreign_access(s->req.u.rw.seg[i].gref, 0, 0U=
L);
> >> +     struct bio_vec *bvec;
> >> +     struct req_iterator iter;
> >> +     unsigned long flags;
> >> +     char *bvec_data;
> >> +     void *shared_data;
> >> +     unsigned int offset =3D 0;
> >> +
> >> +     if (bret->operation =3D=3D BLKIF_OP_READ) {
> >> +             /*
> >> +              * Copy the data received from the backend into the bvec.
> >> +              * Since bv_len can be different from PAGE_SIZE, we need=
 to
> >> +              * be sure we are actually copying the data from the rig=
ht
> >> +              * shared page.
> >> +              */
> >> +             rq_for_each_segment(bvec, s->request, iter) {
> >> +                     BUG_ON((bvec->bv_offset + bvec->bv_len) > PAGE_S=
IZE);
> >> +                     i =3D offset >> PAGE_SHIFT;
> > =

> > Could you also include a comment about the bug you found here, pls?
> =

> There's a comment before the rq_for_each_segment loop, that tries to
> explain that, do you think the following is better?
> =

> /*
>  * Copy the data received from the backend into the bvec.
>  * Since bv_offset can be different than 0, and bv_len different
>  * than PAGE_SIZE, we have to keep track of the current offset,
>  * to be sure we are copying the data from the right shared page.

Yes. That is good.
>  */
> =

> >> +                     shared_data =3D kmap_atomic(
> >> +                             pfn_to_page(s->grants_used[i]->pfn));
> >> +                     bvec_data =3D bvec_kmap_irq(bvec, &flags);
> >> +                     memcpy(bvec_data, shared_data + bvec->bv_offset,
> >> +                             bvec->bv_len);
> >> +                     bvec_kunmap_irq(bvec_data, &flags);
> >> +                     kunmap_atomic(shared_data);
> >> +                     offset +=3D bvec->bv_len;
> >> +             }
> >> +     }
> >> +     /* Add the persistent grant into the list of free grants */
> >> +     for (i =3D 0; i < s->req.u.rw.nr_segments; i++) {
> >> +             llist_add(&s->grants_used[i]->node, &info->persistent_gn=
ts);
> >> +             info->persistent_gnts_c++;
> >> +     }
> >>  }
> >>
> >>  static irqreturn_t blkif_interrupt(int irq, void *dev_id)
> >> @@ -783,7 +907,7 @@ static irqreturn_t blkif_interrupt(int irq, void *=
dev_id)
> >>               req  =3D info->shadow[id].request;
> >>
> >>               if (bret->operation !=3D BLKIF_OP_DISCARD)
> >> -                     blkif_completion(&info->shadow[id]);
> >> +                     blkif_completion(&info->shadow[id], info, bret);
> >>
> >>               if (add_id_to_freelist(info, id)) {
> >>                       WARN(1, "%s: response to %s (id %ld) couldn't be=
 recycled!\n",
> >> @@ -942,6 +1066,11 @@ again:
> >>               message =3D "writing protocol";
> >>               goto abort_transaction;
> >>       }
> >> +     err =3D xenbus_printf(xbt, dev->nodename,
> >> +                         "feature-persistent-grants", "%d", 1);
> > =

> > So its %u in blkback, but %d in here? Which one should it be?
> =

> %u in both places.
> =

> >> +     if (err)
> >> +             dev_warn(&dev->dev,
> >> +                      "writing persistent grants feature to xenbus");
> >>
> >>       err =3D xenbus_transaction_end(xbt, 0);
> >>       if (err) {
> >> @@ -1029,6 +1158,8 @@ static int blkfront_probe(struct xenbus_device *=
dev,
> >>       spin_lock_init(&info->io_lock);
> >>       info->xbdev =3D dev;
> >>       info->vdevice =3D vdevice;
> >> +     init_llist_head(&info->persistent_gnts);
> >> +     info->persistent_gnts_c =3D 0;
> >>       info->connected =3D BLKIF_STATE_DISCONNECTED;
> >>       INIT_WORK(&info->work, blkif_restart_queue);
> >>
> >> @@ -1093,7 +1224,7 @@ static int blkif_recover(struct blkfront_info *i=
nfo)
> >>                                       req->u.rw.seg[j].gref,
> >>                                       info->xbdev->otherend_id,
> >>                                       pfn_to_mfn(info->shadow[req->u.r=
w.id].frame[j]),
> >> -                                     rq_data_dir(info->shadow[req->u.=
rw.id].request));
> >> +                                     0);
> >>               }
> >>               info->shadow[req->u.rw.id].req =3D *req;
> >>
> >> --
> >> 1.7.7.5 (Apple Git-26)
> >>
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-kernel=
" in
> >> the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >> Please read the FAQ at  http://www.tux.org/lkml/
> >>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 17:38:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 17:38:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQiQV-0006A0-Dy; Tue, 23 Oct 2012 17:38:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQiQT-00069u-Ir
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 17:38:01 +0000
Received: from [85.158.143.99:17851] by server-2.bemta-4.messagelabs.com id
	9C/B1-22268-8F5D6805; Tue, 23 Oct 2012 17:38:00 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-7.tower-216.messagelabs.com!1351013879!29133181!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7926 invoked from network); 23 Oct 2012 17:38:00 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-7.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	23 Oct 2012 17:38:00 -0000
Received: from 255-64-ftth.onsneteindhoven.nl ([88.159.64.255]:55097
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TQiSK-0003Fn-Lp; Tue, 23 Oct 2012 19:39:56 +0200
Date: Tue, 23 Oct 2012 19:37:53 +0200
From: Sander Eikelenboom 
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <468189240.20121023193753@eikelenboom.it>
To: Konrad Rzeszutek Wilk 
In-Reply-To: <20121023162707.GA16634@phenom.dumpdata.com>
References: <20121023162707.GA16634@phenom.dumpdata.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com,
	Linus Torvalds ,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [GIT PULL] (xen) stable/for-linus-3.7-rc2-tag for
	v3.7-rc2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Konrad,

Did you push the tag ?
It doesn't seem to be in your git repo.

--
Sander

Tuesday, October 23, 2012, 6:27:07 PM, you wrote:

> Hey Linus,

> Please git pull the following tag:

>  git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-linus-3.7-rc2-tag

> which has bug-fixes. Most of them are just code cleanup to make x86 and ARM code
> work in unison. There is one serious bug-fix which manifested itself in some
> applications mysteriously getting SIGKILL. Besides that nothing earth-shattering.

> :
>  * Fix mysterious SIGSEGV or SIGKILL in applications due to corrupting
>    of the %eip when returning from a signal handler.
>  * Fix various ARM compile issues after the merge fallout.
>  * Continue on making more of the Xen generic code usable by ARM platform.
>  * Fix SR-IOV passthrough to mirror multifunction PCI devices.
>  * Fix various compile warnings.
>  * Remove hypercalls that don't exist anymore.
> 

>  arch/arm/include/asm/xen/interface.h |   12 +++++++++---
>  arch/arm/include/asm/xen/page.h      |   13 ++++++++++---
>  arch/arm/xen/grant-table.c           |    2 +-
>  arch/x86/include/asm/xen/interface.h |    4 ++--
>  arch/x86/kernel/entry_32.S           |    8 +++++---
>  arch/x86/kernel/entry_64.S           |    2 +-
>  arch/x86/xen/enlighten.c             |    2 --
>  drivers/xen/balloon.c                |    3 +--
>  drivers/xen/dbgp.c                   |    2 ++
>  drivers/xen/events.c                 |    4 ++++
>  drivers/xen/grant-table.c            |    8 ++++----
>  drivers/xen/sys-hypervisor.c         |    4 +++-
>  drivers/xen/xen-pciback/vpci.c       |   14 ++++++++++----
>  drivers/xen/xenbus/xenbus_xs.c       |    2 ++
>  include/xen/grant_table.h            |    2 +-
>  include/xen/interface/grant_table.h  |    2 +-
>  include/xen/interface/memory.h       |   24 ++----------------------
>  17 files changed, 58 insertions(+), 50 deletions(-)

> David Vrabel (1):
>       xen/x86: don't corrupt %eip when returning from a signal handler

> Ian Campbell (11):
>       xen: xenbus: quirk uses x86 specific cpuid
>       xen: sysfs: include err.h for PTR_ERR etc
>       xen: sysfs: fix build warning.
>       xen: XENMEM_translate_gpfn_list was remove ages ago and is unused.
>       xen: events: pirq_check_eoi_map is X86 specific
>       xen: grant: use xen_pfn_t type for frame_list.
>       xen: balloon: don't include e820.h
>       xen: arm: make p2m operations NOPs
>       xen: balloon: use correct type for frame_list
>       xen: arm: comment on why 64-bit xen_pfn_t is safe even on 32 bit
>       xen: dbgp: Fix warning when CONFIG_PCI is not enabled.

> Konrad Rzeszutek Wilk (1):
>       xen/xenbus: Fix compile warning.

> Laszlo Ersek (1):
>       xen PV passthru: assign SR-IOV virtual functions to separate virtual slots

> Wei Yongjun (1):
>       xen/x86: remove duplicated include from enlighten.c



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 17:38:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 17:38:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQiQV-0006A0-Dy; Tue, 23 Oct 2012 17:38:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQiQT-00069u-Ir
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 17:38:01 +0000
Received: from [85.158.143.99:17851] by server-2.bemta-4.messagelabs.com id
	9C/B1-22268-8F5D6805; Tue, 23 Oct 2012 17:38:00 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-7.tower-216.messagelabs.com!1351013879!29133181!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7926 invoked from network); 23 Oct 2012 17:38:00 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-7.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	23 Oct 2012 17:38:00 -0000
Received: from 255-64-ftth.onsneteindhoven.nl ([88.159.64.255]:55097
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TQiSK-0003Fn-Lp; Tue, 23 Oct 2012 19:39:56 +0200
Date: Tue, 23 Oct 2012 19:37:53 +0200
From: Sander Eikelenboom 
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <468189240.20121023193753@eikelenboom.it>
To: Konrad Rzeszutek Wilk 
In-Reply-To: <20121023162707.GA16634@phenom.dumpdata.com>
References: <20121023162707.GA16634@phenom.dumpdata.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com,
	Linus Torvalds ,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [GIT PULL] (xen) stable/for-linus-3.7-rc2-tag for
	v3.7-rc2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Konrad,

Did you push the tag ?
It doesn't seem to be in your git repo.

--
Sander

Tuesday, October 23, 2012, 6:27:07 PM, you wrote:

> Hey Linus,

> Please git pull the following tag:

>  git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-linus-3.7-rc2-tag

> which has bug-fixes. Most of them are just code cleanup to make x86 and ARM code
> work in unison. There is one serious bug-fix which manifested itself in some
> applications mysteriously getting SIGKILL. Besides that nothing earth-shattering.

> :
>  * Fix mysterious SIGSEGV or SIGKILL in applications due to corrupting
>    of the %eip when returning from a signal handler.
>  * Fix various ARM compile issues after the merge fallout.
>  * Continue on making more of the Xen generic code usable by ARM platform.
>  * Fix SR-IOV passthrough to mirror multifunction PCI devices.
>  * Fix various compile warnings.
>  * Remove hypercalls that don't exist anymore.
> 

>  arch/arm/include/asm/xen/interface.h |   12 +++++++++---
>  arch/arm/include/asm/xen/page.h      |   13 ++++++++++---
>  arch/arm/xen/grant-table.c           |    2 +-
>  arch/x86/include/asm/xen/interface.h |    4 ++--
>  arch/x86/kernel/entry_32.S           |    8 +++++---
>  arch/x86/kernel/entry_64.S           |    2 +-
>  arch/x86/xen/enlighten.c             |    2 --
>  drivers/xen/balloon.c                |    3 +--
>  drivers/xen/dbgp.c                   |    2 ++
>  drivers/xen/events.c                 |    4 ++++
>  drivers/xen/grant-table.c            |    8 ++++----
>  drivers/xen/sys-hypervisor.c         |    4 +++-
>  drivers/xen/xen-pciback/vpci.c       |   14 ++++++++++----
>  drivers/xen/xenbus/xenbus_xs.c       |    2 ++
>  include/xen/grant_table.h            |    2 +-
>  include/xen/interface/grant_table.h  |    2 +-
>  include/xen/interface/memory.h       |   24 ++----------------------
>  17 files changed, 58 insertions(+), 50 deletions(-)

> David Vrabel (1):
>       xen/x86: don't corrupt %eip when returning from a signal handler

> Ian Campbell (11):
>       xen: xenbus: quirk uses x86 specific cpuid
>       xen: sysfs: include err.h for PTR_ERR etc
>       xen: sysfs: fix build warning.
>       xen: XENMEM_translate_gpfn_list was remove ages ago and is unused.
>       xen: events: pirq_check_eoi_map is X86 specific
>       xen: grant: use xen_pfn_t type for frame_list.
>       xen: balloon: don't include e820.h
>       xen: arm: make p2m operations NOPs
>       xen: balloon: use correct type for frame_list
>       xen: arm: comment on why 64-bit xen_pfn_t is safe even on 32 bit
>       xen: dbgp: Fix warning when CONFIG_PCI is not enabled.

> Konrad Rzeszutek Wilk (1):
>       xen/xenbus: Fix compile warning.

> Laszlo Ersek (1):
>       xen PV passthru: assign SR-IOV virtual functions to separate virtual slots

> Wei Yongjun (1):
>       xen/x86: remove duplicated include from enlighten.c



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 18:10:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 18:10:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQiuz-0006TF-3l; Tue, 23 Oct 2012 18:09:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQiuw-0006TA-WF
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 18:09:31 +0000
Received: from [85.158.139.211:51699] by server-15.bemta-5.messagelabs.com id
	B4/91-28599-A5DD6805; Tue, 23 Oct 2012 18:09:30 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1351015769!23394663!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUyMjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2910 invoked from network); 23 Oct 2012 18:09:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 18:09:29 -0000
X-IronPort-AV: E=Sophos;i="4.80,637,1344211200"; d="scan'208";a="15342057"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Oct 2012 18:09:28 +0000
Received: from [192.168.1.30] (10.31.3.234) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 23 Oct 2012 19:09:28 +0100
Message-ID: <5086DD57.4000206@citrix.com>
Date: Tue, 23 Oct 2012 20:09:27 +0200
From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk 
References: <1350559321-19066-1-git-send-email-roger.pau@citrix.com>
	<20121022134708.GA13832@konrad-lan.dumpdata.com>
	<5086C0C8.5000306@citrix.com>
	<20121023172008.GB11787@phenom.dumpdata.com>
In-Reply-To: <20121023172008.GB11787@phenom.dumpdata.com>
Cc: Konrad Rzeszutek Wilk ,
	"linux-kernel@vger.kernel.org" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH RFC] Persistent grant maps for xen blk
	drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 23/10/12 19:20, Konrad Rzeszutek Wilk wrote:
>>>> diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
>>>> index c6decb9..2b982b2 100644
>>>> --- a/drivers/block/xen-blkback/blkback.c
>>>> +++ b/drivers/block/xen-blkback/blkback.c
>>>> @@ -78,6 +78,7 @@ struct pending_req {
>>>>       unsigned short          operation;
>>>>       int                     status;
>>>>       struct list_head        free_list;
>>>> +     unsigned int            unmap_seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];

Should I change this to a bool? Since we are only setting it to 0 or 1.

>>> Perhaps there should be a #define for that array..
>>
>> Do you mean something like:
>>
>> #define unmap(req, i) req->unmap_seg[i]
> 
> I was thinking that you just check for req->unamp_seg[i] to
> have an non-zero value. But since that array is just used as an check
> to see whether the functionality is enabled (or not), you might want
> to declerare the right values so:
> #define UNMAP_SG_ON 1
> #define UNMAP_SG_OFF 0
> 
> or so.

Agreed, will add the defines.

>>>> +             if (persistent_gnts[i]) {
>>>> +                     if (!persistent_gnts[i]->handle) {
>>>> +                             /*
>>>> +                              * If this is a new persistent grant
>>>> +                              * save the handler
>>>> +                              */
>>>> +                             persistent_gnts[i]->handle = map[j].handle;
>>>> +                             persistent_gnts[i]->dev_bus_addr =
>>>> +                                     map[j++].dev_bus_addr;
>>>> +                     }
>>>> +                     pending_handle(pending_req, i) =
>>>> +                             persistent_gnts[i]->handle;
>>>> +                     pending_req->unmap_seg[i] = 0;
>>>
>>> Could we have a #define for that?
>>
>> Sure.

I've used the previous macro, so it looks like:

unmap(req, i) = UNMAP_SG_OFF;

I'm not sure if this is what you meant, or if you where interested in
defining a set of macros like:

#define check_unmap(req, i) req->unmap_seg[i]
#define unset_unmap(req, i) req->unmap_seg[i] = UNMAP_SG_OFF
#define set_unmap(req, i) req->unmap_seg[i] = UNMAP_SG_ON

I would go for the first option (the unmap macro that can be used here
and in xen_blkbk_unmap).

>>> HA! By default, eh?
>>
>> Yes, you caught me, there's a paragraph in the commit message that
>> explains that we are using persistent grants in the frontend
>> unconditionally, since the protocol is compatible (you can have a
>> persistent blkfront and a non-persistent blkback). It simplifies the
>> logic in blkfront. Are you OK with it?
> 
> It is OK, but you should be checking whether the backend supports it.
> I don't see it checking the info->feature_persistent_grant to print
> that.

I don't understand why blkfront needs to check if the backend supports
persisten grants, blkfront is going to use persistent grants anyway.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 18:10:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 18:10:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQiuz-0006TF-3l; Tue, 23 Oct 2012 18:09:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQiuw-0006TA-WF
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 18:09:31 +0000
Received: from [85.158.139.211:51699] by server-15.bemta-5.messagelabs.com id
	B4/91-28599-A5DD6805; Tue, 23 Oct 2012 18:09:30 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1351015769!23394663!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUyMjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2910 invoked from network); 23 Oct 2012 18:09:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 18:09:29 -0000
X-IronPort-AV: E=Sophos;i="4.80,637,1344211200"; d="scan'208";a="15342057"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Oct 2012 18:09:28 +0000
Received: from [192.168.1.30] (10.31.3.234) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 23 Oct 2012 19:09:28 +0100
Message-ID: <5086DD57.4000206@citrix.com>
Date: Tue, 23 Oct 2012 20:09:27 +0200
From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk 
References: <1350559321-19066-1-git-send-email-roger.pau@citrix.com>
	<20121022134708.GA13832@konrad-lan.dumpdata.com>
	<5086C0C8.5000306@citrix.com>
	<20121023172008.GB11787@phenom.dumpdata.com>
In-Reply-To: <20121023172008.GB11787@phenom.dumpdata.com>
Cc: Konrad Rzeszutek Wilk ,
	"linux-kernel@vger.kernel.org" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH RFC] Persistent grant maps for xen blk
	drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 23/10/12 19:20, Konrad Rzeszutek Wilk wrote:
>>>> diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
>>>> index c6decb9..2b982b2 100644
>>>> --- a/drivers/block/xen-blkback/blkback.c
>>>> +++ b/drivers/block/xen-blkback/blkback.c
>>>> @@ -78,6 +78,7 @@ struct pending_req {
>>>>       unsigned short          operation;
>>>>       int                     status;
>>>>       struct list_head        free_list;
>>>> +     unsigned int            unmap_seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];

Should I change this to a bool? Since we are only setting it to 0 or 1.

>>> Perhaps there should be a #define for that array..
>>
>> Do you mean something like:
>>
>> #define unmap(req, i) req->unmap_seg[i]
> 
> I was thinking that you just check for req->unamp_seg[i] to
> have an non-zero value. But since that array is just used as an check
> to see whether the functionality is enabled (or not), you might want
> to declerare the right values so:
> #define UNMAP_SG_ON 1
> #define UNMAP_SG_OFF 0
> 
> or so.

Agreed, will add the defines.

>>>> +             if (persistent_gnts[i]) {
>>>> +                     if (!persistent_gnts[i]->handle) {
>>>> +                             /*
>>>> +                              * If this is a new persistent grant
>>>> +                              * save the handler
>>>> +                              */
>>>> +                             persistent_gnts[i]->handle = map[j].handle;
>>>> +                             persistent_gnts[i]->dev_bus_addr =
>>>> +                                     map[j++].dev_bus_addr;
>>>> +                     }
>>>> +                     pending_handle(pending_req, i) =
>>>> +                             persistent_gnts[i]->handle;
>>>> +                     pending_req->unmap_seg[i] = 0;
>>>
>>> Could we have a #define for that?
>>
>> Sure.

I've used the previous macro, so it looks like:

unmap(req, i) = UNMAP_SG_OFF;

I'm not sure if this is what you meant, or if you where interested in
defining a set of macros like:

#define check_unmap(req, i) req->unmap_seg[i]
#define unset_unmap(req, i) req->unmap_seg[i] = UNMAP_SG_OFF
#define set_unmap(req, i) req->unmap_seg[i] = UNMAP_SG_ON

I would go for the first option (the unmap macro that can be used here
and in xen_blkbk_unmap).

>>> HA! By default, eh?
>>
>> Yes, you caught me, there's a paragraph in the commit message that
>> explains that we are using persistent grants in the frontend
>> unconditionally, since the protocol is compatible (you can have a
>> persistent blkfront and a non-persistent blkback). It simplifies the
>> logic in blkfront. Are you OK with it?
> 
> It is OK, but you should be checking whether the backend supports it.
> I don't see it checking the info->feature_persistent_grant to print
> that.

I don't understand why blkfront needs to check if the backend supports
persisten grants, blkfront is going to use persistent grants anyway.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 18:24:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 18:24:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQj9W-0006dy-BK; Tue, 23 Oct 2012 18:24:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQj9U-0006d6-LQ
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 18:24:32 +0000
Received: from [85.158.137.99:43225] by server-8.bemta-3.messagelabs.com id
	23/34-10525-FD0E6805; Tue, 23 Oct 2012 18:24:31 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1351016669!22778902!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODIwNzA4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11928 invoked from network); 23 Oct 2012 18:24:30 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-13.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Oct 2012 18:24:30 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9NIONZX014504
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 23 Oct 2012 18:24:23 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9NIOMVT023606
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 23 Oct 2012 18:24:22 GMT
Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9NIOMDH023742; Tue, 23 Oct 2012 13:24:22 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 23 Oct 2012 11:24:21 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id DF8AA402BD; Tue, 23 Oct 2012 14:12:12 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	stefano.stabellini@eu.citrix.com, Ian.Campbell@citrix.com,
	mukesh.rathor@oracle.com
Date: Tue, 23 Oct 2012 14:12:02 -0400
Message-Id: <1351015931-16991-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
References: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 01/10] xen/pvh: Support ParaVirtualized Hardware
	extensions.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Mukesh Rathor 

PVH allows PV linux guest to utilize hardware extended capabilities, such
as running MMU updates in a HVM container.

This patch allows it to be configured and enabled. Also, basic header file
changes to add new subcalls to physmap hypercall.

Lastly, mfn_to_local_pfn must return mfn for paging mode translate
(since we let the hypervisor - or CPU - do them for us).

Acked-by: Stefano Stabellini 
Signed-off-by: Mukesh Rathor 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/include/asm/xen/page.h |    3 +++
 arch/x86/xen/Kconfig            |   10 ++++++++++
 arch/x86/xen/xen-head.S         |   11 ++++++++++-
 include/xen/interface/memory.h  |   24 +++++++++++++++++++++++-
 include/xen/interface/physdev.h |   10 ++++++++++
 5 files changed, 56 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index 472b9b7..6af440d 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -159,6 +159,9 @@ static inline xpaddr_t machine_to_phys(xmaddr_t machine)
 static inline unsigned long mfn_to_local_pfn(unsigned long mfn)
 {
 	unsigned long pfn = mfn_to_pfn(mfn);
+
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return mfn;
 	if (get_phys_to_machine(pfn) != mfn)
 		return -1; /* force !pfn_valid() */
 	return pfn;
diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index fdce49c..c9660bf 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -50,3 +50,13 @@ config XEN_DEBUG_FS
 	  Enable statistics output and various tuning options in debugfs.
 	  Enabling this option may incur a significant performance overhead.
 
+config XEN_X86_PVH
+	bool "Support for running as a PVH guest (EXPERIMENTAL)"
+	depends on X86_64 && XEN && EXPERIMENTAL
+	default n
+	help
+	   This option enables support for running as a PVH guest (PV guest
+	   using hardware extensions) under a suitably capable hypervisor.
+	   This option is EXPERIMENTAL because the hypervisor interfaces
+	   which it uses is not yet considered stable therefore backwards and
+	   forwards compatibility is not yet guaranteed.  If unsure, say N.
diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
index 7faed58..1a6bca1 100644
--- a/arch/x86/xen/xen-head.S
+++ b/arch/x86/xen/xen-head.S
@@ -13,6 +13,15 @@
 #include 
 #include 
 
+#ifdef CONFIG_XEN_X86_PVH
+#define FEATURES_PVH "|writable_descriptor_tables" \
+		     "|auto_translated_physmap" \
+		     "|supervisor_mode_kernel" \
+		     "|hvm_callback_vector"
+#else
+#define FEATURES_PVH /* Not supported */
+#endif
+
 	__INIT
 ENTRY(startup_xen)
 	cld
@@ -95,7 +104,7 @@ NEXT_HYPERCALL(arch_6)
 #endif
 	ELFNOTE(Xen, XEN_ELFNOTE_ENTRY,          _ASM_PTR startup_xen)
 	ELFNOTE(Xen, XEN_ELFNOTE_HYPERCALL_PAGE, _ASM_PTR hypercall_page)
-	ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,       .asciz "!writable_page_tables|pae_pgdir_above_4gb")
+	ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,       .asciz "!writable_page_tables|pae_pgdir_above_4gb"FEATURES_PVH)
 	ELFNOTE(Xen, XEN_ELFNOTE_PAE_MODE,       .asciz "yes")
 	ELFNOTE(Xen, XEN_ELFNOTE_LOADER,         .asciz "generic")
 	ELFNOTE(Xen, XEN_ELFNOTE_L1_MFN_VALID,
diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index b66d04c..8beebdb 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -169,7 +169,13 @@ struct xen_add_to_physmap {
     /* Source mapping space. */
 #define XENMAPSPACE_shared_info 0 /* shared info page */
 #define XENMAPSPACE_grant_table 1 /* grant table page */
-    unsigned int space;
+#define XENMAPSPACE_gmfn        2 /* GMFN */
+#define XENMAPSPACE_gmfn_range  3 /* GMFN range */
+#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */
+    uint16_t space;
+    domid_t foreign_domid;         /* IFF XENMAPSPACE_gmfn_foreign */
+
+#define XENMAPIDX_grant_table_status 0x80000000
 
     /* Index into source mapping space. */
     xen_ulong_t idx;
@@ -237,4 +243,20 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_memory_map);
  * during a driver critical region.
  */
 extern spinlock_t xen_reservation_lock;
+
+/*
+ * Unmaps the page appearing at a particular GPFN from the specified guest's
+ * pseudophysical address space.
+ * arg == addr of xen_remove_from_physmap_t.
+ */
+#define XENMEM_remove_from_physmap      15
+struct xen_remove_from_physmap {
+    /* Which domain to change the mapping for. */
+    domid_t domid;
+
+    /* GPFN of the current mapping of the page. */
+    xen_pfn_t gpfn;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_remove_from_physmap);
+
 #endif /* __XEN_PUBLIC_MEMORY_H__ */
diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
index 1844d31..83050d3 100644
--- a/include/xen/interface/physdev.h
+++ b/include/xen/interface/physdev.h
@@ -274,6 +274,16 @@ struct physdev_dbgp_op {
     } u;
 };
 
+#define PHYSDEVOP_map_iomem        30
+struct physdev_map_iomem {
+    /* IN */
+    uint64_t first_gfn;
+    uint64_t first_mfn;
+    uint32_t nr_mfns;
+    uint32_t add_mapping; /* 1 == add mapping;  0 == unmap */
+
+};
+
 /*
  * Notify that some PIRQ-bound event channels have been unmasked.
  * ** This command is obsolete since interface version 0x00030202 and is **
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 18:24:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 18:24:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQj9W-0006e9-O5; Tue, 23 Oct 2012 18:24:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQj9U-0006d7-QK
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 18:24:33 +0000
Received: from [85.158.143.35:65265] by server-3.bemta-4.messagelabs.com id
	00/E7-03544-FD0E6805; Tue, 23 Oct 2012 18:24:31 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1351016669!12680113!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODIwNzA4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14429 invoked from network); 23 Oct 2012 18:24:30 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Oct 2012 18:24:30 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9NIOO9F014524
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 23 Oct 2012 18:24:24 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9NIONKa012284
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 23 Oct 2012 18:24:23 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9NIONxo023773; Tue, 23 Oct 2012 13:24:23 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 23 Oct 2012 11:24:23 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1C9744084A; Tue, 23 Oct 2012 14:12:13 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	stefano.stabellini@eu.citrix.com, Ian.Campbell@citrix.com,
	mukesh.rathor@oracle.com
Date: Tue, 23 Oct 2012 14:12:08 -0400
Message-Id: <1351015931-16991-8-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
References: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 07/10] xen/pvh: bootup and setup (E820) related
	changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Mukesh Rathor 

In the bootup code for PVH we can trap cpuid via vmexit, so don't
need to use emulated prefix call. We also check for vector callback
early on, as it is a required feature. PVH also runs at default kernel
IOPL.

In setup.c which deals with E820, in xen_add_extra_mem() we can skip
updating P2M as it's managed by Xen. PVH maps the entire IO space,
but only RAM pages need to be repopulated.

Finally, pure PV settings are moved to a separate function that are
only called for pure PV, ie, pv with pvmmu.

Signed-off-by: Mukesh Rathor 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/xen/enlighten.c |   77 ++++++++++++++++++++++++++++++++++-----------
 arch/x86/xen/setup.c     |   64 +++++++++++++++++++++++++++++++-------
 2 files changed, 110 insertions(+), 31 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index b679f86..bd8f718 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -45,6 +45,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -107,6 +108,9 @@ RESERVE_BRK(shared_info_page_brk, PAGE_SIZE);
 __read_mostly int xen_have_vector_callback;
 EXPORT_SYMBOL_GPL(xen_have_vector_callback);
 
+#define xen_pvh_domain() (xen_pv_domain() && \
+			  xen_feature(XENFEAT_auto_translated_physmap) && \
+			  xen_have_vector_callback)
 /*
  * Point at some empty memory to start with. We map the real shared_info
  * page as soon as fixmap is up and running.
@@ -219,8 +223,9 @@ static void __init xen_banner(void)
 	struct xen_extraversion extra;
 	HYPERVISOR_xen_version(XENVER_extraversion, &extra);
 
-	printk(KERN_INFO "Booting paravirtualized kernel on %s\n",
-	       pv_info.name);
+	pr_info("Booting paravirtualized kernel %son %s\n",
+		xen_feature(XENFEAT_auto_translated_physmap) ?
+			"with PVH extensions " : "", pv_info.name);
 	printk(KERN_INFO "Xen version: %d.%d%s%s\n",
 	       version >> 16, version & 0xffff, extra.extraversion,
 	       xen_feature(XENFEAT_mmu_pt_update_preserve_ad) ? " (preserve-AD)" : "");
@@ -273,12 +278,15 @@ static void xen_cpuid(unsigned int *ax, unsigned int *bx,
 		break;
 	}
 
-	asm(XEN_EMULATE_PREFIX "cpuid"
-		: "=a" (*ax),
-		  "=b" (*bx),
-		  "=c" (*cx),
-		  "=d" (*dx)
-		: "0" (*ax), "2" (*cx));
+	if (xen_pvh_domain())
+		native_cpuid(ax, bx, cx, dx);
+	else
+		asm(XEN_EMULATE_PREFIX "cpuid"
+			: "=a" (*ax),
+			"=b" (*bx),
+			"=c" (*cx),
+			"=d" (*dx)
+			: "0" (*ax), "2" (*cx));
 
 	*bx &= maskebx;
 	*cx &= maskecx;
@@ -1055,6 +1063,10 @@ void xen_setup_shared_info(void)
 		HYPERVISOR_shared_info =
 			(struct shared_info *)__va(xen_start_info->shared_info);
 
+	/* PVH TBD/FIXME: vcpu info placement in phase 2 */
+	if (xen_pvh_domain())
+		return;
+
 #ifndef CONFIG_SMP
 	/* In UP this is as good a place as any to set up shared info */
 	xen_setup_vcpu_info_placement();
@@ -1292,6 +1304,11 @@ static const struct machine_ops xen_machine_ops __initconst = {
  */
 static void __init xen_setup_stackprotector(void)
 {
+	/* PVH TBD/FIXME: investigate setup_stack_canary_segment */
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		switch_to_new_gdt(0);
+		return;
+	}
 	pv_cpu_ops.write_gdt_entry = xen_write_gdt_entry_boot;
 	pv_cpu_ops.load_gdt = xen_load_gdt_boot;
 
@@ -1302,6 +1319,19 @@ static void __init xen_setup_stackprotector(void)
 	pv_cpu_ops.load_gdt = xen_load_gdt;
 }
 
+static void __init xen_pvh_early_guest_init(void)
+{
+	if (xen_feature(XENFEAT_hvm_callback_vector))
+		xen_have_vector_callback = 1;
+
+#ifdef CONFIG_X86_32
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		xen_raw_printk("ERROR: 32bit PVH guests are not supported\n");
+		BUG();
+	}
+#endif
+}
+
 /* First C function to be called on Xen boot */
 asmlinkage void __init xen_start_kernel(void)
 {
@@ -1313,13 +1343,18 @@ asmlinkage void __init xen_start_kernel(void)
 
 	xen_domain_type = XEN_PV_DOMAIN;
 
+	xen_setup_features();
+	xen_pvh_early_guest_init();
 	xen_setup_machphys_mapping();
 
 	/* Install Xen paravirt ops */
 	pv_info = xen_info;
 	pv_init_ops = xen_init_ops;
-	pv_cpu_ops = xen_cpu_ops;
 	pv_apic_ops = xen_apic_ops;
+	if (xen_pvh_domain())
+		pv_cpu_ops.cpuid = xen_cpuid;
+	else
+		pv_cpu_ops = xen_cpu_ops;
 
 	x86_init.resources.memory_setup = xen_memory_setup;
 	x86_init.oem.arch_setup = xen_arch_setup;
@@ -1351,8 +1386,6 @@ asmlinkage void __init xen_start_kernel(void)
 	/* Work out if we support NX */
 	x86_configure_nx();
 
-	xen_setup_features();
-
 	/* Get mfn list */
 	if (!xen_feature(XENFEAT_auto_translated_physmap))
 		xen_build_dynamic_phys_to_machine();
@@ -1423,14 +1456,18 @@ asmlinkage void __init xen_start_kernel(void)
 	/* set the limit of our address space */
 	xen_reserve_top();
 
-	/* We used to do this in xen_arch_setup, but that is too late on AMD
-	 * were early_cpu_init (run before ->arch_setup()) calls early_amd_init
-	 * which pokes 0xcf8 port.
-	 */
-	set_iopl.iopl = 1;
-	rc = HYPERVISOR_physdev_op(PHYSDEVOP_set_iopl, &set_iopl);
-	if (rc != 0)
-		xen_raw_printk("physdev_op failed %d\n", rc);
+	/* PVH: runs at default kernel iopl of 0 */
+	if (!xen_pvh_domain()) {
+		/*
+		 * We used to do this in xen_arch_setup, but that is too late
+		 * on AMD were early_cpu_init (run before ->arch_setup()) calls
+		 * early_amd_init which pokes 0xcf8 port.
+		 */
+		set_iopl.iopl = 1;
+		rc = HYPERVISOR_physdev_op(PHYSDEVOP_set_iopl, &set_iopl);
+		if (rc != 0)
+			xen_raw_printk("physdev_op failed %d\n", rc);
+	}
 
 #ifdef CONFIG_X86_32
 	/* set up basic CPUID stuff */
@@ -1497,6 +1534,8 @@ asmlinkage void __init xen_start_kernel(void)
 #endif
 }
 
+/* Use a pfn in RAM, may move to MMIO before kexec.
+ * This function also called for PVH dom0 */
 void __ref xen_hvm_init_shared_info(void)
 {
 	int cpu;
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 8971a26..8cce47b 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include "mmu.h"
 #include "xen-ops.h"
 #include "vdso.h"
 
@@ -78,6 +79,9 @@ static void __init xen_add_extra_mem(u64 start, u64 size)
 
 	memblock_reserve(start, size);
 
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return;
+
 	xen_max_p2m_pfn = PFN_DOWN(start + size);
 	for (pfn = PFN_DOWN(start); pfn < xen_max_p2m_pfn; pfn++) {
 		unsigned long mfn = pfn_to_mfn(pfn);
@@ -100,6 +104,7 @@ static unsigned long __init xen_do_chunk(unsigned long start,
 		.domid        = DOMID_SELF
 	};
 	unsigned long len = 0;
+	int xlated_phys = xen_feature(XENFEAT_auto_translated_physmap);
 	unsigned long pfn;
 	int ret;
 
@@ -113,7 +118,7 @@ static unsigned long __init xen_do_chunk(unsigned long start,
 				continue;
 			frame = mfn;
 		} else {
-			if (mfn != INVALID_P2M_ENTRY)
+			if (!xlated_phys && mfn != INVALID_P2M_ENTRY)
 				continue;
 			frame = pfn;
 		}
@@ -230,6 +235,27 @@ static void __init xen_set_identity_and_release_chunk(
 	*identity += set_phys_range_identity(start_pfn, end_pfn);
 }
 
+/* For PVH, the pfns [0..MAX] are mapped to mfn's in the EPT/NPT. The mfns
+ * are released as part of this 1:1 mapping hypercall back to the dom heap.
+ * Also, we map the entire IO space, ie, beyond max_pfn_mapped.
+ */
+static void __init xen_pvh_identity_map_chunk(unsigned long start_pfn,
+		unsigned long end_pfn, unsigned long *released,
+		unsigned long *identity, unsigned long max_pfn)
+{
+	unsigned long pfn;
+	int numpfns = 1, add_mapping = 1;
+
+	for (pfn = start_pfn; pfn < end_pfn; pfn++)
+		xen_set_clr_mmio_pvh_pte(pfn, pfn, numpfns, add_mapping);
+
+	if (start_pfn <= max_pfn) {
+		unsigned long end = min(max_pfn_mapped, end_pfn);
+		*released += end - start_pfn;
+	}
+	*identity += end_pfn - start_pfn;
+}
+
 static unsigned long __init xen_set_identity_and_release(
 	const struct e820entry *list, size_t map_size, unsigned long nr_pages)
 {
@@ -238,6 +264,7 @@ static unsigned long __init xen_set_identity_and_release(
 	unsigned long identity = 0;
 	const struct e820entry *entry;
 	int i;
+	int xlated_phys = xen_feature(XENFEAT_auto_translated_physmap);
 
 	/*
 	 * Combine non-RAM regions and gaps until a RAM region (or the
@@ -259,11 +286,17 @@ static unsigned long __init xen_set_identity_and_release(
 			if (entry->type == E820_RAM)
 				end_pfn = PFN_UP(entry->addr);
 
-			if (start_pfn < end_pfn)
-				xen_set_identity_and_release_chunk(
-					start_pfn, end_pfn, nr_pages,
-					&released, &identity);
-
+			if (start_pfn < end_pfn) {
+				if (xlated_phys) {
+					xen_pvh_identity_map_chunk(start_pfn,
+						end_pfn, &released, &identity,
+						nr_pages);
+				} else {
+					xen_set_identity_and_release_chunk(
+						start_pfn, end_pfn, nr_pages,
+						&released, &identity);
+				}
+			}
 			start = end;
 		}
 	}
@@ -526,16 +559,14 @@ void __cpuinit xen_enable_syscall(void)
 #endif /* CONFIG_X86_64 */
 }
 
-void __init xen_arch_setup(void)
+/* Non auto translated PV domain, ie, it's not PVH. */
+static __init void xen_pvmmu_arch_setup(void)
 {
-	xen_panic_handler_init();
-
 	HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_4gb_segments);
 	HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_writable_pagetables);
 
-	if (!xen_feature(XENFEAT_auto_translated_physmap))
-		HYPERVISOR_vm_assist(VMASST_CMD_enable,
-				     VMASST_TYPE_pae_extended_cr3);
+	HYPERVISOR_vm_assist(VMASST_CMD_enable,
+			     VMASST_TYPE_pae_extended_cr3);
 
 	if (register_callback(CALLBACKTYPE_event, xen_hypervisor_callback) ||
 	    register_callback(CALLBACKTYPE_failsafe, xen_failsafe_callback))
@@ -543,6 +574,15 @@ void __init xen_arch_setup(void)
 
 	xen_enable_sysenter();
 	xen_enable_syscall();
+}
+
+/* This function not called for HVM domain */
+void __init xen_arch_setup(void)
+{
+	xen_panic_handler_init();
+
+	if (!xen_feature(XENFEAT_auto_translated_physmap))
+		xen_pvmmu_arch_setup();
 
 #ifdef CONFIG_ACPI
 	if (!(xen_start_info->flags & SIF_INITDOMAIN)) {
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 18:24:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 18:24:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQj9X-0006ej-Kv; Tue, 23 Oct 2012 18:24:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQj9V-0006dH-Cb
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 18:24:33 +0000
Received: from [85.158.138.51:39307] by server-5.bemta-3.messagelabs.com id
	60/A6-12440-0E0E6805; Tue, 23 Oct 2012 18:24:32 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1351016669!35411673!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODIwNzA4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16538 invoked from network); 23 Oct 2012 18:24:30 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Oct 2012 18:24:30 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9NIONi5014503
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 23 Oct 2012 18:24:23 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9NIOMnI023608
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 23 Oct 2012 18:24:22 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9NIOLWN006251; Tue, 23 Oct 2012 13:24:21 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 23 Oct 2012 11:24:21 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D91134042D; Tue, 23 Oct 2012 14:12:12 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	stefano.stabellini@eu.citrix.com, Ian.Campbell@citrix.com,
	mukesh.rathor@oracle.com
Date: Tue, 23 Oct 2012 14:12:01 -0400
Message-Id: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Subject: [Xen-devel] [PATCH V5] PVH patches for v3.8.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Changelog [since v4]
 - Mukesh addressed the reviewer's concerns.
 - Took Mukesh's patches and redid the changelogs.
 - Added Ack-ed as appropiate.
 - Fixed PVHVM 32-bit bootup issues.
 - Did some various cleanups, split some patches up.

The big change is that I've made the xen_remove_from_physmap structure
be of the same size and offset on 32 and 64 bit builds. Currently PVH 
only runs with 64-bit guests, but in the future it could run with 32-bit.
This change will eliminate having to add a compat layer to deal with
32-bit hypercalls.

Besides that the patches boot on an normal hypervisor - in
dom0 (32 or 64bit), PV domU (32 or 64) and PVHVM domU (32 or 64).
I don't have the PVH hypervisor patches so I could not address the
change to xen_remove_from_physmap but I hope Mukesh can do that.

The patches are also located at:
 git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/pvh.v5


 arch/x86/include/asm/xen/interface.h |   11 ++-
 arch/x86/include/asm/xen/page.h      |    3 +
 arch/x86/xen/Kconfig                 |   10 ++
 arch/x86/xen/enlighten.c             |   78 ++++++++++++----
 arch/x86/xen/irq.c                   |    5 +-
 arch/x86/xen/mmu.c                   |  162 ++++++++++++++++++++++++++++++++--
 arch/x86/xen/mmu.h                   |    2 +
 arch/x86/xen/p2m.c                   |    2 +-
 arch/x86/xen/setup.c                 |   58 +++++++++----
 arch/x86/xen/smp.c                   |   75 ++++++++++------
 arch/x86/xen/xen-head.S              |   11 ++-
 drivers/xen/balloon.c                |   15 ++--
 drivers/xen/cpu_hotplug.c            |    4 +-
 drivers/xen/events.c                 |    9 ++-
 drivers/xen/gntdev.c                 |    3 +-
 drivers/xen/grant-table.c            |   27 +++++-
 drivers/xen/privcmd.c                |   72 ++++++++++++++-
 drivers/xen/xenbus/xenbus_client.c   |    3 +-
 include/xen/interface/memory.h       |   29 ++++++-
 include/xen/interface/physdev.h      |   10 ++
 include/xen/xen-ops.h                |    5 +-
 21 files changed, 504 insertions(+), 90 deletions(-)

Konrad Rzeszutek Wilk (4):
      xen/pvh: Fix PVHVM 32-bit bootup problems.
      xen/hypercall: Make xen_remove_from_physmap the same on 64/32 builds.
      xen/smp: Move the common CPU init code a bit to prep for PVH patch.
      xen/e820: Coalesce the PVH release/populate logic in the generic case.

Mukesh Rathor (6):
      xen/pvh: Support ParaVirtualized Hardware extensions.
      xen/pvh: Extend vcpu_guest_context, p2m, event, and XenBus.
      xen/pvh: Implement MMU changes for PVH.
      xen/pvh: bootup and setup (E820) related changes.
      xen/pvh: balloon and grant changes.
      xen/pvh: /dev/xen/privcmd changes.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 18:24:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 18:24:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQj9Z-0006gO-O2; Tue, 23 Oct 2012 18:24:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQj9W-0006dq-Ja
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 18:24:34 +0000
Received: from [85.158.138.51:37124] by server-4.bemta-3.messagelabs.com id
	65/9D-01405-1E0E6805; Tue, 23 Oct 2012 18:24:33 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1351016670!35439934!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgyNzg1OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1581 invoked from network); 23 Oct 2012 18:24:32 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Oct 2012 18:24:32 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9NIONcu019710
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 23 Oct 2012 18:24:24 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9NIOMJj018426
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 23 Oct 2012 18:24:23 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9NIOM8e023744; Tue, 23 Oct 2012 13:24:22 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 23 Oct 2012 11:24:22 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 011A040431; Tue, 23 Oct 2012 14:12:12 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	stefano.stabellini@eu.citrix.com, Ian.Campbell@citrix.com,
	mukesh.rathor@oracle.com
Date: Tue, 23 Oct 2012 14:12:05 -0400
Message-Id: <1351015931-16991-5-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
References: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 04/10] xen/smp: Move the common CPU init code a
	bit to prep for PVH patch.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The PV and PVH code CPU init code share some functionality. The
PVH code ("xen/pvh: Extend vcpu_guest_context, p2m, event, and XenBus")
sets some of these up, but not all. To make it easier to read, this
patch removes the PV specific out of the generic way.

No functional change - just code movement.

Acked-by: Stefano Stabellini 
[v2: Fixed compile errors noticed by Fengguang Wu build system]
Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/xen/smp.c |   42 +++++++++++++++++++++++-------------------
 1 files changed, 23 insertions(+), 19 deletions(-)

diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 353c50f..6947c4e 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -300,8 +300,6 @@ cpu_initialize_context(unsigned int cpu, struct task_struct *idle)
 	gdt = get_cpu_gdt_table(cpu);
 
 	ctxt->flags = VGCF_IN_KERNEL;
-	ctxt->user_regs.ds = __USER_DS;
-	ctxt->user_regs.es = __USER_DS;
 	ctxt->user_regs.ss = __KERNEL_DS;
 #ifdef CONFIG_X86_32
 	ctxt->user_regs.fs = __KERNEL_PERCPU;
@@ -310,35 +308,41 @@ cpu_initialize_context(unsigned int cpu, struct task_struct *idle)
 	ctxt->gs_base_kernel = per_cpu_offset(cpu);
 #endif
 	ctxt->user_regs.eip = (unsigned long)cpu_bringup_and_idle;
-	ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
 
 	memset(&ctxt->fpu_ctxt, 0, sizeof(ctxt->fpu_ctxt));
 
-	xen_copy_trap_info(ctxt->trap_ctxt);
+	{
+		ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
+		ctxt->user_regs.ds = __USER_DS;
+		ctxt->user_regs.es = __USER_DS;
 
-	ctxt->ldt_ents = 0;
+		xen_copy_trap_info(ctxt->trap_ctxt);
 
-	BUG_ON((unsigned long)gdt & ~PAGE_MASK);
+		ctxt->ldt_ents = 0;
 
-	gdt_mfn = arbitrary_virt_to_mfn(gdt);
-	make_lowmem_page_readonly(gdt);
-	make_lowmem_page_readonly(mfn_to_virt(gdt_mfn));
+		BUG_ON((unsigned long)gdt & ~PAGE_MASK);
 
-	ctxt->gdt_frames[0] = gdt_mfn;
-	ctxt->gdt_ents      = GDT_ENTRIES;
+		gdt_mfn = arbitrary_virt_to_mfn(gdt);
+		make_lowmem_page_readonly(gdt);
+		make_lowmem_page_readonly(mfn_to_virt(gdt_mfn));
 
-	ctxt->user_regs.cs = __KERNEL_CS;
-	ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct pt_regs);
+		ctxt->gdt_frames[0] = gdt_mfn;
+		ctxt->gdt_ents      = GDT_ENTRIES;
 
-	ctxt->kernel_ss = __KERNEL_DS;
-	ctxt->kernel_sp = idle->thread.sp0;
+		ctxt->kernel_ss = __KERNEL_DS;
+		ctxt->kernel_sp = idle->thread.sp0;
 
 #ifdef CONFIG_X86_32
-	ctxt->event_callback_cs     = __KERNEL_CS;
-	ctxt->failsafe_callback_cs  = __KERNEL_CS;
+		ctxt->event_callback_cs     = __KERNEL_CS;
+		ctxt->failsafe_callback_cs  = __KERNEL_CS;
 #endif
-	ctxt->event_callback_eip    = (unsigned long)xen_hypervisor_callback;
-	ctxt->failsafe_callback_eip = (unsigned long)xen_failsafe_callback;
+		ctxt->event_callback_eip    =
+					(unsigned long)xen_hypervisor_callback;
+		ctxt->failsafe_callback_eip =
+					(unsigned long)xen_failsafe_callback;
+	}
+	ctxt->user_regs.cs = __KERNEL_CS;
+	ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct pt_regs);
 
 	per_cpu(xen_cr3, cpu) = __pa(swapper_pg_dir);
 	ctxt->ctrlreg[3] = xen_pfn_to_cr3(virt_to_mfn(swapper_pg_dir));
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 18:24:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 18:24:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQj9Y-0006fS-PE; Tue, 23 Oct 2012 18:24:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQj9W-0006dH-8X
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 18:24:34 +0000
Received: from [85.158.138.51:39330] by server-5.bemta-3.messagelabs.com id
	83/A6-12440-1E0E6805; Tue, 23 Oct 2012 18:24:33 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1351016670!27506011!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiA3NjEy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1701 invoked from network); 23 Oct 2012 18:24:32 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Oct 2012 18:24:32 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9NIOO8Q031018
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 23 Oct 2012 18:24:25 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9NIONRS020503
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 23 Oct 2012 18:24:24 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9NIONQF015451; Tue, 23 Oct 2012 13:24:23 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 23 Oct 2012 11:24:23 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2E2A640A75; Tue, 23 Oct 2012 14:12:13 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	stefano.stabellini@eu.citrix.com, Ian.Campbell@citrix.com,
	mukesh.rathor@oracle.com
Date: Tue, 23 Oct 2012 14:12:10 -0400
Message-Id: <1351015931-16991-10-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
References: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 09/10] xen/pvh: balloon and grant changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Mukesh Rathor 

For balloon changes we skip setting of local P2M as it's updated
in Xen. For grant, the shared grant frame is the PFN and not MFN,
hence its mapped via the same code path as HVM.

Signed-off-by: Mukesh Rathor 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 drivers/xen/balloon.c     |   15 +++++++++------
 drivers/xen/gntdev.c      |    3 ++-
 drivers/xen/grant-table.c |   26 ++++++++++++++++++++++----
 3 files changed, 33 insertions(+), 11 deletions(-)

diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 31ab82f..c825b63 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -361,7 +361,9 @@ static enum bp_state increase_reservation(unsigned long nr_pages)
 		set_phys_to_machine(pfn, frame_list[i]);
 
 		/* Link back into the page tables if not highmem. */
-		if (xen_pv_domain() && !PageHighMem(page)) {
+		if (xen_pv_domain() && !PageHighMem(page) &&
+		    !xen_feature(XENFEAT_auto_translated_physmap)) {
+
 			int ret;
 			ret = HYPERVISOR_update_va_mapping(
 				(unsigned long)__va(pfn << PAGE_SHIFT),
@@ -418,12 +420,13 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
 		scrub_page(page);
 
 		if (xen_pv_domain() && !PageHighMem(page)) {
-			ret = HYPERVISOR_update_va_mapping(
-				(unsigned long)__va(pfn << PAGE_SHIFT),
-				__pte_ma(0), 0);
-			BUG_ON(ret);
+			if (!xen_feature(XENFEAT_auto_translated_physmap)) {
+				ret = HYPERVISOR_update_va_mapping(
+					(unsigned long)__va(pfn << PAGE_SHIFT),
+					__pte_ma(0), 0);
+				BUG_ON(ret);
+			}
 		}
-
 	}
 
 	/* Ensure that ballooned highmem pages don't have kmaps. */
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 610bfc6..d39d54e 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -803,7 +803,8 @@ static int __init gntdev_init(void)
 	if (!xen_domain())
 		return -ENODEV;
 
-	use_ptemod = xen_pv_domain();
+	use_ptemod = xen_pv_domain() &&
+		     !xen_feature(XENFEAT_auto_translated_physmap);
 
 	err = misc_register(&gntdev_miscdev);
 	if (err != 0) {
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index cbfd929..d8eb56c 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -1029,14 +1029,19 @@ static void gnttab_unmap_frames_v2(void)
 static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 {
 	struct gnttab_setup_table setup;
-	unsigned long *frames;
+	unsigned long *frames, start_gpfn;
 	unsigned int nr_gframes = end_idx + 1;
 	int rc;
 
-	if (xen_hvm_domain()) {
+	if (xen_hvm_domain() || xen_feature(XENFEAT_auto_translated_physmap)) {
 		struct xen_add_to_physmap xatp;
 		unsigned int i = end_idx;
 		rc = 0;
+
+		if (xen_hvm_domain())
+			start_gpfn = xen_hvm_resume_frames >> PAGE_SHIFT;
+		else
+			start_gpfn = virt_to_pfn(gnttab_shared.addr);
 		/*
 		 * Loop backwards, so that the first hypercall has the largest
 		 * index, ensuring that the table will grow only once.
@@ -1046,7 +1051,7 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 			xatp.idx = i;
 			xatp.foreign_domid = 0;
 			xatp.space = XENMAPSPACE_grant_table;
-			xatp.gpfn = (xen_hvm_resume_frames >> PAGE_SHIFT) + i;
+			xatp.gpfn = start_gpfn + i;
 			rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
 			if (rc != 0) {
 				printk(KERN_WARNING
@@ -1109,7 +1114,7 @@ static void gnttab_request_version(void)
 	int rc;
 	struct gnttab_set_version gsv;
 
-	if (xen_hvm_domain())
+	if (xen_hvm_domain() || xen_feature(XENFEAT_auto_translated_physmap))
 		gsv.version = 1;
 	else
 		gsv.version = 2;
@@ -1137,12 +1142,25 @@ static void gnttab_request_version(void)
 int gnttab_resume(void)
 {
 	unsigned int max_nr_gframes;
+	char *kmsg = "Failed to kmalloc pages for pv in hvm grant frames\n";
 
 	gnttab_request_version();
 	max_nr_gframes = gnttab_max_grant_frames();
 	if (max_nr_gframes < nr_grant_frames)
 		return -ENOSYS;
 
+	/* PVH note: xen will free existing kmalloc'd mfn in
+	 * XENMEM_add_to_physmap. TBD/FIXME: use xen ballooning instead of
+	 * kmalloc(). */
+	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap) &&
+	    !gnttab_shared.addr) {
+		gnttab_shared.addr =
+			kmalloc(max_nr_gframes * PAGE_SIZE, GFP_KERNEL);
+		if (!gnttab_shared.addr) {
+			pr_warn("%s", kmsg);
+			return -ENOMEM;
+		}
+	}
 	if (xen_pv_domain())
 		return gnttab_map(0, nr_grant_frames - 1);
 
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 18:24:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 18:24:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQj9X-0006eS-4P; Tue, 23 Oct 2012 18:24:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQj9V-0006dC-47
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 18:24:33 +0000
Received: from [85.158.139.211:14220] by server-10.bemta-5.messagelabs.com id
	F2/61-01025-0E0E6805; Tue, 23 Oct 2012 18:24:32 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1351016670!22974531!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODIwNzA4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20247 invoked from network); 23 Oct 2012 18:24:31 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Oct 2012 18:24:31 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9NIONAF014507
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 23 Oct 2012 18:24:24 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9NIOMb0020461
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 23 Oct 2012 18:24:23 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9NIOM6f015426; Tue, 23 Oct 2012 13:24:22 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 23 Oct 2012 11:24:21 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id EC3874042F; Tue, 23 Oct 2012 14:12:12 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	stefano.stabellini@eu.citrix.com, Ian.Campbell@citrix.com,
	mukesh.rathor@oracle.com
Date: Tue, 23 Oct 2012 14:12:04 -0400
Message-Id: <1351015931-16991-4-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
References: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 03/10] xen/hypercall: Make
	xen_remove_from_physmap the same on 64/32 builds.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

By making the structure exactly the same size and with the same
offsets on 64 and 32-bit builds we are future-proofing ourselves.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 include/xen/interface/memory.h |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index 8beebdb..6b07b54 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -253,9 +253,14 @@ extern spinlock_t xen_reservation_lock;
 struct xen_remove_from_physmap {
     /* Which domain to change the mapping for. */
     domid_t domid;
-
+   /* To be used in the future if need to. */
+    uint8_t reserved[6];
     /* GPFN of the current mapping of the page. */
     xen_pfn_t gpfn;
+#ifdef CONFIG_X86_32
+    /* No need to do that on ARM as xen_pfn_t is always 8 bytes. */
+    uint8_t __pad[4];
+#endif
 };
 DEFINE_GUEST_HANDLE_STRUCT(xen_remove_from_physmap);
 
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 18:24:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 18:24:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQj9Y-0006fS-PE; Tue, 23 Oct 2012 18:24:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQj9W-0006dH-8X
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 18:24:34 +0000
Received: from [85.158.138.51:39330] by server-5.bemta-3.messagelabs.com id
	83/A6-12440-1E0E6805; Tue, 23 Oct 2012 18:24:33 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1351016670!27506011!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiA3NjEy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1701 invoked from network); 23 Oct 2012 18:24:32 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Oct 2012 18:24:32 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9NIOO8Q031018
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 23 Oct 2012 18:24:25 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9NIONRS020503
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 23 Oct 2012 18:24:24 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9NIONQF015451; Tue, 23 Oct 2012 13:24:23 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 23 Oct 2012 11:24:23 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2E2A640A75; Tue, 23 Oct 2012 14:12:13 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	stefano.stabellini@eu.citrix.com, Ian.Campbell@citrix.com,
	mukesh.rathor@oracle.com
Date: Tue, 23 Oct 2012 14:12:10 -0400
Message-Id: <1351015931-16991-10-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
References: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 09/10] xen/pvh: balloon and grant changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Mukesh Rathor 

For balloon changes we skip setting of local P2M as it's updated
in Xen. For grant, the shared grant frame is the PFN and not MFN,
hence its mapped via the same code path as HVM.

Signed-off-by: Mukesh Rathor 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 drivers/xen/balloon.c     |   15 +++++++++------
 drivers/xen/gntdev.c      |    3 ++-
 drivers/xen/grant-table.c |   26 ++++++++++++++++++++++----
 3 files changed, 33 insertions(+), 11 deletions(-)

diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 31ab82f..c825b63 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -361,7 +361,9 @@ static enum bp_state increase_reservation(unsigned long nr_pages)
 		set_phys_to_machine(pfn, frame_list[i]);
 
 		/* Link back into the page tables if not highmem. */
-		if (xen_pv_domain() && !PageHighMem(page)) {
+		if (xen_pv_domain() && !PageHighMem(page) &&
+		    !xen_feature(XENFEAT_auto_translated_physmap)) {
+
 			int ret;
 			ret = HYPERVISOR_update_va_mapping(
 				(unsigned long)__va(pfn << PAGE_SHIFT),
@@ -418,12 +420,13 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
 		scrub_page(page);
 
 		if (xen_pv_domain() && !PageHighMem(page)) {
-			ret = HYPERVISOR_update_va_mapping(
-				(unsigned long)__va(pfn << PAGE_SHIFT),
-				__pte_ma(0), 0);
-			BUG_ON(ret);
+			if (!xen_feature(XENFEAT_auto_translated_physmap)) {
+				ret = HYPERVISOR_update_va_mapping(
+					(unsigned long)__va(pfn << PAGE_SHIFT),
+					__pte_ma(0), 0);
+				BUG_ON(ret);
+			}
 		}
-
 	}
 
 	/* Ensure that ballooned highmem pages don't have kmaps. */
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 610bfc6..d39d54e 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -803,7 +803,8 @@ static int __init gntdev_init(void)
 	if (!xen_domain())
 		return -ENODEV;
 
-	use_ptemod = xen_pv_domain();
+	use_ptemod = xen_pv_domain() &&
+		     !xen_feature(XENFEAT_auto_translated_physmap);
 
 	err = misc_register(&gntdev_miscdev);
 	if (err != 0) {
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index cbfd929..d8eb56c 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -1029,14 +1029,19 @@ static void gnttab_unmap_frames_v2(void)
 static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 {
 	struct gnttab_setup_table setup;
-	unsigned long *frames;
+	unsigned long *frames, start_gpfn;
 	unsigned int nr_gframes = end_idx + 1;
 	int rc;
 
-	if (xen_hvm_domain()) {
+	if (xen_hvm_domain() || xen_feature(XENFEAT_auto_translated_physmap)) {
 		struct xen_add_to_physmap xatp;
 		unsigned int i = end_idx;
 		rc = 0;
+
+		if (xen_hvm_domain())
+			start_gpfn = xen_hvm_resume_frames >> PAGE_SHIFT;
+		else
+			start_gpfn = virt_to_pfn(gnttab_shared.addr);
 		/*
 		 * Loop backwards, so that the first hypercall has the largest
 		 * index, ensuring that the table will grow only once.
@@ -1046,7 +1051,7 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 			xatp.idx = i;
 			xatp.foreign_domid = 0;
 			xatp.space = XENMAPSPACE_grant_table;
-			xatp.gpfn = (xen_hvm_resume_frames >> PAGE_SHIFT) + i;
+			xatp.gpfn = start_gpfn + i;
 			rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
 			if (rc != 0) {
 				printk(KERN_WARNING
@@ -1109,7 +1114,7 @@ static void gnttab_request_version(void)
 	int rc;
 	struct gnttab_set_version gsv;
 
-	if (xen_hvm_domain())
+	if (xen_hvm_domain() || xen_feature(XENFEAT_auto_translated_physmap))
 		gsv.version = 1;
 	else
 		gsv.version = 2;
@@ -1137,12 +1142,25 @@ static void gnttab_request_version(void)
 int gnttab_resume(void)
 {
 	unsigned int max_nr_gframes;
+	char *kmsg = "Failed to kmalloc pages for pv in hvm grant frames\n";
 
 	gnttab_request_version();
 	max_nr_gframes = gnttab_max_grant_frames();
 	if (max_nr_gframes < nr_grant_frames)
 		return -ENOSYS;
 
+	/* PVH note: xen will free existing kmalloc'd mfn in
+	 * XENMEM_add_to_physmap. TBD/FIXME: use xen ballooning instead of
+	 * kmalloc(). */
+	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap) &&
+	    !gnttab_shared.addr) {
+		gnttab_shared.addr =
+			kmalloc(max_nr_gframes * PAGE_SIZE, GFP_KERNEL);
+		if (!gnttab_shared.addr) {
+			pr_warn("%s", kmsg);
+			return -ENOMEM;
+		}
+	}
 	if (xen_pv_domain())
 		return gnttab_map(0, nr_grant_frames - 1);
 
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 18:24:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 18:24:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQj9Y-0006ey-0l; Tue, 23 Oct 2012 18:24:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQj9V-0006dM-GP
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 18:24:33 +0000
Received: from [85.158.139.83:60928] by server-16.bemta-5.messagelabs.com id
	48/42-09196-0E0E6805; Tue, 23 Oct 2012 18:24:32 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1351016670!31628104!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiA3NjEy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6465 invoked from network); 23 Oct 2012 18:24:32 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Oct 2012 18:24:32 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9NIOO5O031020
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 23 Oct 2012 18:24:25 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9NIONo8020505
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 23 Oct 2012 18:24:24 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9NIONS7006284; Tue, 23 Oct 2012 13:24:23 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 23 Oct 2012 11:24:23 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 25BA44084B; Tue, 23 Oct 2012 14:12:13 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	stefano.stabellini@eu.citrix.com, Ian.Campbell@citrix.com,
	mukesh.rathor@oracle.com
Date: Tue, 23 Oct 2012 14:12:09 -0400
Message-Id: <1351015931-16991-9-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
References: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 08/10] xen/e820: Coalesce the PVH
	release/populate logic in the generic case.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Squash the PVH specific case in xen_set_identity_and_release_chunk
and make the 'if (PVH..)' case within xen_do_chunk and
xen_set_identity_and_release_chunk function.

Signed-off-by: Konrad Rzeszutek Wilk 
[v2: Remove the extra xlated_phys since it is no longer in use]
---
 arch/x86/xen/setup.c |   60 +++++++++++++++++++------------------------------
 1 files changed, 23 insertions(+), 37 deletions(-)

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 8cce47b..78c5622 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -114,9 +114,15 @@ static unsigned long __init xen_do_chunk(unsigned long start,
 
 		if (release) {
 			/* Make sure pfn exists to start with */
-			if (mfn == INVALID_P2M_ENTRY || mfn_to_pfn(mfn) != pfn)
+			if (mfn == INVALID_P2M_ENTRY || (!xlated_phys && (mfn_to_pfn(mfn) != pfn)))
 				continue;
 			frame = mfn;
+			/* The hypercall PHYSDEVOP_map_iomem to release memory has already
+			 * happend, so we just do a nop here. */
+			if (xlated_phys) {
+				len++;
+				continue;
+			}
 		} else {
 			if (!xlated_phys && mfn != INVALID_P2M_ENTRY)
 				continue;
@@ -219,15 +225,24 @@ static void __init xen_set_identity_and_release_chunk(
 {
 	unsigned long pfn;
 
+	/* For PVH, the pfns [0..MAX] are mapped to mfn's in the EPT/NPT. The mfns
+	 * are released as part of this 1:1 mapping hypercall back to the dom heap.
+	 * Also, we map the entire IO space, ie, beyond max_pfn_mapped.
+	 */
+	int xlated_phys = xen_feature(XENFEAT_auto_translated_physmap);
+
 	/*
 	 * If the PFNs are currently mapped, the VA mapping also needs
 	 * to be updated to be 1:1.
 	 */
-	for (pfn = start_pfn; pfn <= max_pfn_mapped && pfn < end_pfn; pfn++)
-		(void)HYPERVISOR_update_va_mapping(
-			(unsigned long)__va(pfn << PAGE_SHIFT),
-			mfn_pte(pfn, PAGE_KERNEL_IO), 0);
-
+	for (pfn = start_pfn; pfn <= max_pfn_mapped && pfn < end_pfn; pfn++) {
+		if (xlated_phys)
+			xen_set_clr_mmio_pvh_pte(pfn, pfn, 1 /* one pfn */, 1 /* add mapping */);
+		else
+			(void)HYPERVISOR_update_va_mapping(
+				(unsigned long)__va(pfn << PAGE_SHIFT),
+				mfn_pte(pfn, PAGE_KERNEL_IO), 0);
+	}
 	if (start_pfn < nr_pages)
 		*released += xen_release_chunk(
 			start_pfn, min(end_pfn, nr_pages));
@@ -235,27 +250,6 @@ static void __init xen_set_identity_and_release_chunk(
 	*identity += set_phys_range_identity(start_pfn, end_pfn);
 }
 
-/* For PVH, the pfns [0..MAX] are mapped to mfn's in the EPT/NPT. The mfns
- * are released as part of this 1:1 mapping hypercall back to the dom heap.
- * Also, we map the entire IO space, ie, beyond max_pfn_mapped.
- */
-static void __init xen_pvh_identity_map_chunk(unsigned long start_pfn,
-		unsigned long end_pfn, unsigned long *released,
-		unsigned long *identity, unsigned long max_pfn)
-{
-	unsigned long pfn;
-	int numpfns = 1, add_mapping = 1;
-
-	for (pfn = start_pfn; pfn < end_pfn; pfn++)
-		xen_set_clr_mmio_pvh_pte(pfn, pfn, numpfns, add_mapping);
-
-	if (start_pfn <= max_pfn) {
-		unsigned long end = min(max_pfn_mapped, end_pfn);
-		*released += end - start_pfn;
-	}
-	*identity += end_pfn - start_pfn;
-}
-
 static unsigned long __init xen_set_identity_and_release(
 	const struct e820entry *list, size_t map_size, unsigned long nr_pages)
 {
@@ -264,7 +258,6 @@ static unsigned long __init xen_set_identity_and_release(
 	unsigned long identity = 0;
 	const struct e820entry *entry;
 	int i;
-	int xlated_phys = xen_feature(XENFEAT_auto_translated_physmap);
 
 	/*
 	 * Combine non-RAM regions and gaps until a RAM region (or the
@@ -286,17 +279,10 @@ static unsigned long __init xen_set_identity_and_release(
 			if (entry->type == E820_RAM)
 				end_pfn = PFN_UP(entry->addr);
 
-			if (start_pfn < end_pfn) {
-				if (xlated_phys) {
-					xen_pvh_identity_map_chunk(start_pfn,
-						end_pfn, &released, &identity,
-						nr_pages);
-				} else {
-					xen_set_identity_and_release_chunk(
+			if (start_pfn < end_pfn)
+				xen_set_identity_and_release_chunk(
 						start_pfn, end_pfn, nr_pages,
 						&released, &identity);
-				}
-			}
 			start = end;
 		}
 	}
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 18:24:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 18:24:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQj9V-0006dW-Ik; Tue, 23 Oct 2012 18:24:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQj9U-0006d4-8D
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 18:24:32 +0000
Received: from [85.158.139.83:9057] by server-15.bemta-5.messagelabs.com id
	65/03-28599-FD0E6805; Tue, 23 Oct 2012 18:24:31 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1351016669!32280386!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODIwNzA4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24210 invoked from network); 23 Oct 2012 18:24:30 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Oct 2012 18:24:30 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9NIOMFU014502
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 23 Oct 2012 18:24:23 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9NIOMbd012223
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 23 Oct 2012 18:24:22 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9NIOMot023743; Tue, 23 Oct 2012 13:24:22 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 23 Oct 2012 11:24:21 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E2C3C403C7; Tue, 23 Oct 2012 14:12:12 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	stefano.stabellini@eu.citrix.com, Ian.Campbell@citrix.com,
	mukesh.rathor@oracle.com
Date: Tue, 23 Oct 2012 14:12:03 -0400
Message-Id: <1351015931-16991-3-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
References: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 02/10] xen/pvh: Fix PVHVM 32-bit bootup problems.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

With the split of the 'unsigned int space' in a 'u16 space'
and 'u16 foreign_domid' in xen_add_to_physmap the compiler
won't write the full 32-bit value in 'space'. Instead
it will write a 16-bit value - which is OK. The problem
is that we allocate the xen_add_to_physmap structure from
the stack which can (and it has) various garbage on it.

The end result is that without this patch we end up
providing this to the hypervisor:

   xatp.space = 0xc1310001;
instead of:
   xatp.space = 0x1;

Forcing the foreign_domid to 0, will over-write the garbage
that was on the stack.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/xen/enlighten.c  |    1 +
 drivers/xen/grant-table.c |    1 +
 2 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index e3497f2..b679f86 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1509,6 +1509,7 @@ void __ref xen_hvm_init_shared_info(void)
 	xatp.domid = DOMID_SELF;
 	xatp.idx = 0;
 	xatp.space = XENMAPSPACE_shared_info;
+	xatp.foreign_domid = 0;
 	xatp.gpfn = __pa(shared_info_page) >> PAGE_SHIFT;
 	if (HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp))
 		BUG();
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index b2b0a37..cbfd929 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -1044,6 +1044,7 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 		do {
 			xatp.domid = DOMID_SELF;
 			xatp.idx = i;
+			xatp.foreign_domid = 0;
 			xatp.space = XENMAPSPACE_grant_table;
 			xatp.gpfn = (xen_hvm_resume_frames >> PAGE_SHIFT) + i;
 			rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 18:24:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 18:24:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQj9V-0006dm-Up; Tue, 23 Oct 2012 18:24:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQj9U-0006d5-Ch
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 18:24:32 +0000
Received: from [85.158.143.99:24771] by server-2.bemta-4.messagelabs.com id
	A8/46-22268-FD0E6805; Tue, 23 Oct 2012 18:24:31 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1351016669!27728095!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODIwNzA4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7654 invoked from network); 23 Oct 2012 18:24:30 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Oct 2012 18:24:30 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9NIOOLv014525
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 23 Oct 2012 18:24:24 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9NION6t012288
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 23 Oct 2012 18:24:23 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9NION4U015452; Tue, 23 Oct 2012 13:24:23 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 23 Oct 2012 11:24:23 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 375B540E12; Tue, 23 Oct 2012 14:12:13 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	stefano.stabellini@eu.citrix.com, Ian.Campbell@citrix.com,
	mukesh.rathor@oracle.com
Date: Tue, 23 Oct 2012 14:12:11 -0400
Message-Id: <1351015931-16991-11-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
References: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 10/10] xen/pvh: /dev/xen/privcmd changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Mukesh Rathor 

PVH only supports the batch interface. To map a foreign page to a process,
the PFN must be allocated and PVH path uses ballooning for that purpose.

The returned PFN is then mapped to the foreign page.
xen_unmap_domain_mfn_range() is introduced to unmap these pages via the
privcmd close call.

Acked-by: Stefano Stabellini 
Signed-off-by: Mukesh Rathor 
[v1: Fix up privcmd_close]
Signed-off-by: Konrad Rzeszutek Wilk 
---
 drivers/xen/privcmd.c |   69 +++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 67 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index b612267..b9d0898 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -33,11 +33,14 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "privcmd.h"
 
 MODULE_LICENSE("GPL");
 
+#define PRIV_VMA_LOCKED ((void *)1)
+
 #ifndef HAVE_ARCH_PRIVCMD_MMAP
 static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma);
 #endif
@@ -199,6 +202,10 @@ static long privcmd_ioctl_mmap(void __user *udata)
 	if (!xen_initial_domain())
 		return -EPERM;
 
+	/* We only support privcmd_ioctl_mmap_batch for auto translated. */
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return -ENOSYS;
+
 	if (copy_from_user(&mmapcmd, udata, sizeof(mmapcmd)))
 		return -EFAULT;
 
@@ -246,6 +253,7 @@ struct mmap_batch_state {
 	domid_t domain;
 	unsigned long va;
 	struct vm_area_struct *vma;
+	int index;
 	/* A tristate:
 	 *      0 for no errors
 	 *      1 if at least one error has happened (and no
@@ -260,15 +268,24 @@ struct mmap_batch_state {
 	xen_pfn_t __user *user_mfn;
 };
 
+/* auto translated dom0 note: if domU being created is PV, then mfn is
+ * mfn(addr on bus). If it's auto xlated, then mfn is pfn (input to HAP).
+ */
 static int mmap_batch_fn(void *data, void *state)
 {
 	xen_pfn_t *mfnp = data;
 	struct mmap_batch_state *st = state;
+	struct vm_area_struct *vma = st->vma;
+	struct page **pages = vma->vm_private_data;
+	struct page *cur_page = NULL;
 	int ret;
 
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		cur_page = pages[st->index++];
+
 	ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
 					 st->vma->vm_page_prot, st->domain,
-					 NULL);
+					 &cur_page);
 
 	/* Store error code for second pass. */
 	*(st->err++) = ret;
@@ -304,6 +321,32 @@ static int mmap_return_errors_v1(void *data, void *state)
 	return __put_user(*mfnp, st->user_mfn++);
 }
 
+/* Allocate pfns that are then mapped with gmfns from foreign domid. Update
+ * the vma with the page info to use later.
+ * Returns: 0 if success, otherwise -errno
+ */
+static int alloc_empty_pages(struct vm_area_struct *vma, int numpgs)
+{
+	int rc;
+	struct page **pages;
+
+	pages = kcalloc(numpgs, sizeof(pages[0]), GFP_KERNEL);
+	if (pages == NULL)
+		return -ENOMEM;
+
+	rc = alloc_xenballooned_pages(numpgs, pages, 0);
+	if (rc != 0) {
+		pr_warn("%s Could not alloc %d pfns rc:%d\n", __func__,
+			numpgs, rc);
+		kfree(pages);
+		return -ENOMEM;
+	}
+	BUG_ON(vma->vm_private_data != PRIV_VMA_LOCKED);
+	vma->vm_private_data = pages;
+
+	return 0;
+}
+
 static struct vm_operations_struct privcmd_vm_ops;
 
 static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
@@ -371,10 +414,18 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
 		up_write(&mm->mmap_sem);
 		goto out;
 	}
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		ret = alloc_empty_pages(vma, m.num);
+		if (ret < 0) {
+			up_write(&mm->mmap_sem);
+			goto out;
+		}
+	}
 
 	state.domain        = m.dom;
 	state.vma           = vma;
 	state.va            = m.addr;
+	state.index         = 0;
 	state.global_error  = 0;
 	state.err           = err_array;
 
@@ -439,6 +490,19 @@ static long privcmd_ioctl(struct file *file,
 	return ret;
 }
 
+static void privcmd_close(struct vm_area_struct *vma)
+{
+	struct page **pages = vma->vm_private_data;
+	int numpgs = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
+
+	if (!xen_feature(XENFEAT_auto_translated_physmap || !numpgs || !pages))
+		return;
+
+	xen_unmap_domain_mfn_range(vma, numpgs, pages);
+	free_xenballooned_pages(numpgs, pages);
+	kfree(pages);
+}
+
 static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
 {
 	printk(KERN_DEBUG "privcmd_fault: vma=%p %lx-%lx, pgoff=%lx, uv=%p\n",
@@ -449,6 +513,7 @@ static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
 }
 
 static struct vm_operations_struct privcmd_vm_ops = {
+	.close = privcmd_close,
 	.fault = privcmd_fault
 };
 
@@ -466,7 +531,7 @@ static int privcmd_mmap(struct file *file, struct vm_area_struct *vma)
 
 static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma)
 {
-	return (xchg(&vma->vm_private_data, (void *)1) == NULL);
+	return !cmpxchg(&vma->vm_private_data, NULL, PRIV_VMA_LOCKED);
 }
 
 const struct file_operations xen_privcmd_fops = {
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 18:24:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 18:24:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQj9Z-0006fi-5m; Tue, 23 Oct 2012 18:24:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQj9W-0006de-C8
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 18:24:34 +0000
Received: from [85.158.137.99:43771] by server-14.bemta-3.messagelabs.com id
	63/D7-17276-1E0E6805; Tue, 23 Oct 2012 18:24:33 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1351016670!22632899!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgyNzg1OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3746 invoked from network); 23 Oct 2012 18:24:32 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Oct 2012 18:24:32 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9NIOOlr019718
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 23 Oct 2012 18:24:24 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9NIONg4012285
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 23 Oct 2012 18:24:23 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9NIONdD006287; Tue, 23 Oct 2012 13:24:23 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 23 Oct 2012 11:24:23 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1359840849; Tue, 23 Oct 2012 14:12:13 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	stefano.stabellini@eu.citrix.com, Ian.Campbell@citrix.com,
	mukesh.rathor@oracle.com
Date: Tue, 23 Oct 2012 14:12:07 -0400
Message-Id: <1351015931-16991-7-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
References: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 06/10] xen/pvh: Implement MMU changes for PVH.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Mukesh Rathor 

.. which are surprinsingly small compared to the amount for PV.
First the set/clear mmio pte function make a hypercall to update the
P2M in Xen with 1:1 mapping. Since PVH uses mostly native mmu ops, we
leave the generic (native_*) for the majority and just overwrite the
baremetal with the ones we need.

Two local functions are introduced to add to Xen physmap for Xen remap
interface. Xen unmap interface is introduced so that the privcmd PTe entries
can be cleared in Xen P2M table.

Signed-off-by: Mukesh Rathor 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/xen/mmu.c    |  162 +++++++++++++++++++++++++++++++++++++++++++++++--
 arch/x86/xen/mmu.h    |    2 +
 drivers/xen/privcmd.c |    5 +-
 include/xen/xen-ops.h |    5 +-
 4 files changed, 165 insertions(+), 9 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 6226c99..5747a41 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -74,6 +74,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "multicalls.h"
 #include "mmu.h"
@@ -332,6 +333,20 @@ static void xen_set_pte(pte_t *ptep, pte_t pteval)
 	__xen_set_pte(ptep, pteval);
 }
 
+void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn,
+			      int nr_mfns, int add_mapping)
+{
+	struct physdev_map_iomem iomem;
+
+	iomem.first_gfn = pfn;
+	iomem.first_mfn = mfn;
+	iomem.nr_mfns = nr_mfns;
+	iomem.add_mapping = add_mapping;
+
+	if (HYPERVISOR_physdev_op(PHYSDEVOP_map_iomem, &iomem))
+		BUG();
+}
+
 static void xen_set_pte_at(struct mm_struct *mm, unsigned long addr,
 		    pte_t *ptep, pte_t pteval)
 {
@@ -1221,6 +1236,8 @@ static void __init xen_pagetable_init(void)
 #endif
 	paging_init();
 	xen_setup_shared_info();
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return;
 #ifdef CONFIG_X86_64
 	if (!xen_feature(XENFEAT_auto_translated_physmap)) {
 		unsigned long new_mfn_list;
@@ -1528,6 +1545,10 @@ static void __init xen_set_pte_init(pte_t *ptep, pte_t pte)
 static void pin_pagetable_pfn(unsigned cmd, unsigned long pfn)
 {
 	struct mmuext_op op;
+
+	if (xen_feature(XENFEAT_writable_page_tables))
+		return;
+
 	op.cmd = cmd;
 	op.arg1.mfn = pfn_to_mfn(pfn);
 	if (HYPERVISOR_mmuext_op(&op, 1, NULL, DOMID_SELF))
@@ -1725,6 +1746,10 @@ static void set_page_prot(void *addr, pgprot_t prot)
 	unsigned long pfn = __pa(addr) >> PAGE_SHIFT;
 	pte_t pte = pfn_pte(pfn, prot);
 
+	/* recall for PVH, page tables are native. */
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return;
+
 	if (HYPERVISOR_update_va_mapping((unsigned long)addr, pte, 0))
 		BUG();
 }
@@ -1802,6 +1827,9 @@ static void convert_pfn_mfn(void *v)
 	pte_t *pte = v;
 	int i;
 
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return;
+
 	/* All levels are converted the same way, so just treat them
 	   as ptes. */
 	for (i = 0; i < PTRS_PER_PTE; i++)
@@ -1821,6 +1849,7 @@ static void __init check_pt_base(unsigned long *pt_base, unsigned long *pt_end,
 		(*pt_end)--;
 	}
 }
+
 /*
  * Set up the initial kernel pagetable.
  *
@@ -1831,6 +1860,7 @@ static void __init check_pt_base(unsigned long *pt_base, unsigned long *pt_end,
  * but that's enough to get __va working.  We need to fill in the rest
  * of the physical mapping once some sort of allocator has been set
  * up.
+ * NOTE: for PVH, the page tables are native.
  */
 void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn)
 {
@@ -1908,10 +1938,13 @@ void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn)
 	 * structure to attach it to, so make sure we just set kernel
 	 * pgd.
 	 */
-	xen_mc_batch();
-	__xen_write_cr3(true, __pa(init_level4_pgt));
-	xen_mc_issue(PARAVIRT_LAZY_CPU);
-
+	if (xen_feature(XENFEAT_writable_page_tables)) {
+		native_write_cr3(__pa(init_level4_pgt));
+	} else {
+		xen_mc_batch();
+		__xen_write_cr3(true, __pa(init_level4_pgt));
+		xen_mc_issue(PARAVIRT_LAZY_CPU);
+	}
 	/* We can't that easily rip out L3 and L2, as the Xen pagetables are
 	 * set out this way: [L4], [L1], [L2], [L3], [L1], [L1] ...  for
 	 * the initial domain. For guests using the toolstack, they are in:
@@ -2178,8 +2211,13 @@ static const struct pv_mmu_ops xen_mmu_ops __initconst = {
 
 void __init xen_init_mmu_ops(void)
 {
-	x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
 	x86_init.paging.pagetable_init = xen_pagetable_init;
+
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		pv_mmu_ops.flush_tlb_others = xen_flush_tlb_others;
+		return;
+	}
+	x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
 	pv_mmu_ops = xen_mmu_ops;
 
 	memset(dummy_mapping, 0xff, PAGE_SIZE);
@@ -2455,6 +2493,89 @@ void __init xen_hvm_init_mmu_ops(void)
 }
 #endif
 
+/* Map foreign gmfn, fgmfn, to local pfn, lpfn. This for the user space
+ * creating new guest on PVH dom0 and needs to map domU pages.
+ */
+static int pvh_add_to_xen_p2m(unsigned long lpfn, unsigned long fgmfn,
+			      unsigned int domid)
+{
+	int rc;
+	struct xen_add_to_physmap xatp = { .foreign_domid = domid };
+
+	xatp.gpfn = lpfn;
+	xatp.idx = fgmfn;
+	xatp.domid = DOMID_SELF;
+	xatp.space = XENMAPSPACE_gmfn_foreign;
+	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
+	if (rc)
+		pr_warn("d0: Failed to map pfn (0x%lx) to mfn (0x%lx) rc:%d\n",
+			lpfn, fgmfn, rc);
+	return rc;
+}
+
+static int pvh_rem_xen_p2m(unsigned long spfn, int count)
+{
+	struct xen_remove_from_physmap xrp;
+	int i, rc;
+
+	for (i = 0; i < count; i++) {
+		xrp.domid = DOMID_SELF;
+		xrp.gpfn = spfn+i;
+		rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, &xrp);
+		if (rc) {
+			pr_warn("Failed to unmap pfn:%lx rc:%d done:%d\n",
+				spfn+i, rc, i);
+			return 1;
+		}
+	}
+	return 0;
+}
+
+struct pvh_remap_data {
+	unsigned long fgmfn;		/* foreign domain's gmfn */
+	pgprot_t prot;
+	domid_t  domid;
+	int	 index;
+	struct page **pages;
+};
+
+static int pvh_map_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr,
+			void *data)
+{
+	int rc;
+	struct pvh_remap_data *remap = data;
+	unsigned long pfn = page_to_pfn(remap->pages[remap->index++]);
+	pte_t pteval = pte_mkspecial(pfn_pte(pfn, remap->prot));
+
+	rc = pvh_add_to_xen_p2m(pfn, remap->fgmfn, remap->domid);
+	if (rc)
+		return rc;
+	native_set_pte(ptep, pteval);
+
+	return 0;
+}
+
+static int pvh_remap_gmfn_range(struct vm_area_struct *vma,
+				unsigned long addr, unsigned long mfn, int nr,
+				pgprot_t prot, unsigned domid,
+				struct page **pages)
+{
+	int err;
+	struct pvh_remap_data pvhdata;
+
+	BUG_ON(!pages);
+
+	pvhdata.fgmfn = mfn;
+	pvhdata.prot = prot;
+	pvhdata.domid = domid;
+	pvhdata.index = 0;
+	pvhdata.pages = pages;
+	err = apply_to_page_range(vma->vm_mm, addr, nr << PAGE_SHIFT,
+				  pvh_map_pte_fn, &pvhdata);
+	flush_tlb_all();
+	return err;
+}
+
 #define REMAP_BATCH_SIZE 16
 
 struct remap_data {
@@ -2479,7 +2600,9 @@ static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token,
 int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 			       unsigned long addr,
 			       unsigned long mfn, int nr,
-			       pgprot_t prot, unsigned domid)
+			       pgprot_t prot, unsigned domid,
+			       struct page **pages)
+
 {
 	struct remap_data rmd;
 	struct mmu_update mmu_update[REMAP_BATCH_SIZE];
@@ -2494,6 +2617,10 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 
 	BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_IO)) == (VM_PFNMAP | VM_IO)));
 
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		/* We need to update the local page tables and the xen HAP */
+		return pvh_remap_gmfn_range(vma, addr, mfn, nr, prot, domid, pages);
+	}
 	rmd.mfn = mfn;
 	rmd.prot = prot;
 
@@ -2523,3 +2650,26 @@ out:
 	return err;
 }
 EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
+
+/* Returns: 0 success */
+int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
+			       int numpgs, struct page **pages)
+{
+	if (!pages || !xen_feature(XENFEAT_auto_translated_physmap))
+		return 0;
+
+	while (numpgs--) {
+
+		/* the mmu has already cleaned up the process mmu resources at
+		 * this point (lookup_address will return NULL). */
+		unsigned long pfn = page_to_pfn(pages[numpgs]);
+
+		pvh_rem_xen_p2m(pfn, 1);
+	}
+	/* We don't need to flush tlbs because as part of pvh_rem_xen_p2m(),
+	 * the hypervisor will do tlb flushes after removing the p2m entries
+	 * from the EPT/NPT */
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range);
diff --git a/arch/x86/xen/mmu.h b/arch/x86/xen/mmu.h
index 73809bb..6d0bb56 100644
--- a/arch/x86/xen/mmu.h
+++ b/arch/x86/xen/mmu.h
@@ -23,4 +23,6 @@ unsigned long xen_read_cr2_direct(void);
 
 extern void xen_init_mmu_ops(void);
 extern void xen_hvm_init_mmu_ops(void);
+extern void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn,
+				     int nr_mfns, int add_mapping);
 #endif	/* _XEN_MMU_H */
diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 8adb9cc..b612267 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -178,7 +178,7 @@ static int mmap_mfn_range(void *data, void *state)
 					msg->va & PAGE_MASK,
 					msg->mfn, msg->npages,
 					vma->vm_page_prot,
-					st->domain);
+					st->domain, NULL);
 	if (rc < 0)
 		return rc;
 
@@ -267,7 +267,8 @@ static int mmap_batch_fn(void *data, void *state)
 	int ret;
 
 	ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
-					 st->vma->vm_page_prot, st->domain);
+					 st->vma->vm_page_prot, st->domain,
+					 NULL);
 
 	/* Store error code for second pass. */
 	*(st->err++) = ret;
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 6a198e4..990b43e 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -27,6 +27,9 @@ struct vm_area_struct;
 int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 			       unsigned long addr,
 			       unsigned long mfn, int nr,
-			       pgprot_t prot, unsigned domid);
+			       pgprot_t prot, unsigned domid,
+			       struct page **pages);
+int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
+			       int numpgs, struct page **pages);
 
 #endif /* INCLUDE_XEN_OPS_H */
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 18:24:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 18:24:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQj9V-0006dm-Up; Tue, 23 Oct 2012 18:24:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQj9U-0006d5-Ch
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 18:24:32 +0000
Received: from [85.158.143.99:24771] by server-2.bemta-4.messagelabs.com id
	A8/46-22268-FD0E6805; Tue, 23 Oct 2012 18:24:31 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1351016669!27728095!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODIwNzA4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7654 invoked from network); 23 Oct 2012 18:24:30 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Oct 2012 18:24:30 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9NIOOLv014525
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 23 Oct 2012 18:24:24 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9NION6t012288
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 23 Oct 2012 18:24:23 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9NION4U015452; Tue, 23 Oct 2012 13:24:23 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 23 Oct 2012 11:24:23 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 375B540E12; Tue, 23 Oct 2012 14:12:13 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	stefano.stabellini@eu.citrix.com, Ian.Campbell@citrix.com,
	mukesh.rathor@oracle.com
Date: Tue, 23 Oct 2012 14:12:11 -0400
Message-Id: <1351015931-16991-11-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
References: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 10/10] xen/pvh: /dev/xen/privcmd changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Mukesh Rathor 

PVH only supports the batch interface. To map a foreign page to a process,
the PFN must be allocated and PVH path uses ballooning for that purpose.

The returned PFN is then mapped to the foreign page.
xen_unmap_domain_mfn_range() is introduced to unmap these pages via the
privcmd close call.

Acked-by: Stefano Stabellini 
Signed-off-by: Mukesh Rathor 
[v1: Fix up privcmd_close]
Signed-off-by: Konrad Rzeszutek Wilk 
---
 drivers/xen/privcmd.c |   69 +++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 67 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index b612267..b9d0898 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -33,11 +33,14 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "privcmd.h"
 
 MODULE_LICENSE("GPL");
 
+#define PRIV_VMA_LOCKED ((void *)1)
+
 #ifndef HAVE_ARCH_PRIVCMD_MMAP
 static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma);
 #endif
@@ -199,6 +202,10 @@ static long privcmd_ioctl_mmap(void __user *udata)
 	if (!xen_initial_domain())
 		return -EPERM;
 
+	/* We only support privcmd_ioctl_mmap_batch for auto translated. */
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return -ENOSYS;
+
 	if (copy_from_user(&mmapcmd, udata, sizeof(mmapcmd)))
 		return -EFAULT;
 
@@ -246,6 +253,7 @@ struct mmap_batch_state {
 	domid_t domain;
 	unsigned long va;
 	struct vm_area_struct *vma;
+	int index;
 	/* A tristate:
 	 *      0 for no errors
 	 *      1 if at least one error has happened (and no
@@ -260,15 +268,24 @@ struct mmap_batch_state {
 	xen_pfn_t __user *user_mfn;
 };
 
+/* auto translated dom0 note: if domU being created is PV, then mfn is
+ * mfn(addr on bus). If it's auto xlated, then mfn is pfn (input to HAP).
+ */
 static int mmap_batch_fn(void *data, void *state)
 {
 	xen_pfn_t *mfnp = data;
 	struct mmap_batch_state *st = state;
+	struct vm_area_struct *vma = st->vma;
+	struct page **pages = vma->vm_private_data;
+	struct page *cur_page = NULL;
 	int ret;
 
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		cur_page = pages[st->index++];
+
 	ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
 					 st->vma->vm_page_prot, st->domain,
-					 NULL);
+					 &cur_page);
 
 	/* Store error code for second pass. */
 	*(st->err++) = ret;
@@ -304,6 +321,32 @@ static int mmap_return_errors_v1(void *data, void *state)
 	return __put_user(*mfnp, st->user_mfn++);
 }
 
+/* Allocate pfns that are then mapped with gmfns from foreign domid. Update
+ * the vma with the page info to use later.
+ * Returns: 0 if success, otherwise -errno
+ */
+static int alloc_empty_pages(struct vm_area_struct *vma, int numpgs)
+{
+	int rc;
+	struct page **pages;
+
+	pages = kcalloc(numpgs, sizeof(pages[0]), GFP_KERNEL);
+	if (pages == NULL)
+		return -ENOMEM;
+
+	rc = alloc_xenballooned_pages(numpgs, pages, 0);
+	if (rc != 0) {
+		pr_warn("%s Could not alloc %d pfns rc:%d\n", __func__,
+			numpgs, rc);
+		kfree(pages);
+		return -ENOMEM;
+	}
+	BUG_ON(vma->vm_private_data != PRIV_VMA_LOCKED);
+	vma->vm_private_data = pages;
+
+	return 0;
+}
+
 static struct vm_operations_struct privcmd_vm_ops;
 
 static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
@@ -371,10 +414,18 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
 		up_write(&mm->mmap_sem);
 		goto out;
 	}
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		ret = alloc_empty_pages(vma, m.num);
+		if (ret < 0) {
+			up_write(&mm->mmap_sem);
+			goto out;
+		}
+	}
 
 	state.domain        = m.dom;
 	state.vma           = vma;
 	state.va            = m.addr;
+	state.index         = 0;
 	state.global_error  = 0;
 	state.err           = err_array;
 
@@ -439,6 +490,19 @@ static long privcmd_ioctl(struct file *file,
 	return ret;
 }
 
+static void privcmd_close(struct vm_area_struct *vma)
+{
+	struct page **pages = vma->vm_private_data;
+	int numpgs = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
+
+	if (!xen_feature(XENFEAT_auto_translated_physmap || !numpgs || !pages))
+		return;
+
+	xen_unmap_domain_mfn_range(vma, numpgs, pages);
+	free_xenballooned_pages(numpgs, pages);
+	kfree(pages);
+}
+
 static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
 {
 	printk(KERN_DEBUG "privcmd_fault: vma=%p %lx-%lx, pgoff=%lx, uv=%p\n",
@@ -449,6 +513,7 @@ static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
 }
 
 static struct vm_operations_struct privcmd_vm_ops = {
+	.close = privcmd_close,
 	.fault = privcmd_fault
 };
 
@@ -466,7 +531,7 @@ static int privcmd_mmap(struct file *file, struct vm_area_struct *vma)
 
 static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma)
 {
-	return (xchg(&vma->vm_private_data, (void *)1) == NULL);
+	return !cmpxchg(&vma->vm_private_data, NULL, PRIV_VMA_LOCKED);
 }
 
 const struct file_operations xen_privcmd_fops = {
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 18:24:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 18:24:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQj9Z-0006gO-O2; Tue, 23 Oct 2012 18:24:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQj9W-0006dq-Ja
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 18:24:34 +0000
Received: from [85.158.138.51:37124] by server-4.bemta-3.messagelabs.com id
	65/9D-01405-1E0E6805; Tue, 23 Oct 2012 18:24:33 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1351016670!35439934!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgyNzg1OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1581 invoked from network); 23 Oct 2012 18:24:32 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Oct 2012 18:24:32 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9NIONcu019710
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 23 Oct 2012 18:24:24 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9NIOMJj018426
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 23 Oct 2012 18:24:23 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9NIOM8e023744; Tue, 23 Oct 2012 13:24:22 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 23 Oct 2012 11:24:22 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 011A040431; Tue, 23 Oct 2012 14:12:12 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	stefano.stabellini@eu.citrix.com, Ian.Campbell@citrix.com,
	mukesh.rathor@oracle.com
Date: Tue, 23 Oct 2012 14:12:05 -0400
Message-Id: <1351015931-16991-5-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
References: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 04/10] xen/smp: Move the common CPU init code a
	bit to prep for PVH patch.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The PV and PVH code CPU init code share some functionality. The
PVH code ("xen/pvh: Extend vcpu_guest_context, p2m, event, and XenBus")
sets some of these up, but not all. To make it easier to read, this
patch removes the PV specific out of the generic way.

No functional change - just code movement.

Acked-by: Stefano Stabellini 
[v2: Fixed compile errors noticed by Fengguang Wu build system]
Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/xen/smp.c |   42 +++++++++++++++++++++++-------------------
 1 files changed, 23 insertions(+), 19 deletions(-)

diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 353c50f..6947c4e 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -300,8 +300,6 @@ cpu_initialize_context(unsigned int cpu, struct task_struct *idle)
 	gdt = get_cpu_gdt_table(cpu);
 
 	ctxt->flags = VGCF_IN_KERNEL;
-	ctxt->user_regs.ds = __USER_DS;
-	ctxt->user_regs.es = __USER_DS;
 	ctxt->user_regs.ss = __KERNEL_DS;
 #ifdef CONFIG_X86_32
 	ctxt->user_regs.fs = __KERNEL_PERCPU;
@@ -310,35 +308,41 @@ cpu_initialize_context(unsigned int cpu, struct task_struct *idle)
 	ctxt->gs_base_kernel = per_cpu_offset(cpu);
 #endif
 	ctxt->user_regs.eip = (unsigned long)cpu_bringup_and_idle;
-	ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
 
 	memset(&ctxt->fpu_ctxt, 0, sizeof(ctxt->fpu_ctxt));
 
-	xen_copy_trap_info(ctxt->trap_ctxt);
+	{
+		ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
+		ctxt->user_regs.ds = __USER_DS;
+		ctxt->user_regs.es = __USER_DS;
 
-	ctxt->ldt_ents = 0;
+		xen_copy_trap_info(ctxt->trap_ctxt);
 
-	BUG_ON((unsigned long)gdt & ~PAGE_MASK);
+		ctxt->ldt_ents = 0;
 
-	gdt_mfn = arbitrary_virt_to_mfn(gdt);
-	make_lowmem_page_readonly(gdt);
-	make_lowmem_page_readonly(mfn_to_virt(gdt_mfn));
+		BUG_ON((unsigned long)gdt & ~PAGE_MASK);
 
-	ctxt->gdt_frames[0] = gdt_mfn;
-	ctxt->gdt_ents      = GDT_ENTRIES;
+		gdt_mfn = arbitrary_virt_to_mfn(gdt);
+		make_lowmem_page_readonly(gdt);
+		make_lowmem_page_readonly(mfn_to_virt(gdt_mfn));
 
-	ctxt->user_regs.cs = __KERNEL_CS;
-	ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct pt_regs);
+		ctxt->gdt_frames[0] = gdt_mfn;
+		ctxt->gdt_ents      = GDT_ENTRIES;
 
-	ctxt->kernel_ss = __KERNEL_DS;
-	ctxt->kernel_sp = idle->thread.sp0;
+		ctxt->kernel_ss = __KERNEL_DS;
+		ctxt->kernel_sp = idle->thread.sp0;
 
 #ifdef CONFIG_X86_32
-	ctxt->event_callback_cs     = __KERNEL_CS;
-	ctxt->failsafe_callback_cs  = __KERNEL_CS;
+		ctxt->event_callback_cs     = __KERNEL_CS;
+		ctxt->failsafe_callback_cs  = __KERNEL_CS;
 #endif
-	ctxt->event_callback_eip    = (unsigned long)xen_hypervisor_callback;
-	ctxt->failsafe_callback_eip = (unsigned long)xen_failsafe_callback;
+		ctxt->event_callback_eip    =
+					(unsigned long)xen_hypervisor_callback;
+		ctxt->failsafe_callback_eip =
+					(unsigned long)xen_failsafe_callback;
+	}
+	ctxt->user_regs.cs = __KERNEL_CS;
+	ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct pt_regs);
 
 	per_cpu(xen_cr3, cpu) = __pa(swapper_pg_dir);
 	ctxt->ctrlreg[3] = xen_pfn_to_cr3(virt_to_mfn(swapper_pg_dir));
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 18:24:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 18:24:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQj9Y-0006fB-D6; Tue, 23 Oct 2012 18:24:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQj9V-0006dV-Sw
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 18:24:34 +0000
Received: from [85.158.137.99:25354] by server-15.bemta-3.messagelabs.com id
	81/28-10261-1E0E6805; Tue, 23 Oct 2012 18:24:33 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1351016670!17689042!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiA3NjEy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29694 invoked from network); 23 Oct 2012 18:24:32 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-3.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Oct 2012 18:24:32 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9NIOOmS031017
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 23 Oct 2012 18:24:25 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9NION5C020495
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 23 Oct 2012 18:24:24 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9NIONaA023766; Tue, 23 Oct 2012 13:24:23 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 23 Oct 2012 11:24:23 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 0AD3B40848; Tue, 23 Oct 2012 14:12:13 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	stefano.stabellini@eu.citrix.com, Ian.Campbell@citrix.com,
	mukesh.rathor@oracle.com
Date: Tue, 23 Oct 2012 14:12:06 -0400
Message-Id: <1351015931-16991-6-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
References: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 05/10] xen/pvh: Extend vcpu_guest_context, p2m,
	event, and XenBus.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Mukesh Rathor 

Make gdt_frames[]/gdt_ents into a union with {gdtaddr, gdtsz},
as PVH only needs to send down gdtaddr and gdtsz in the
vcpu_guest_context structure..

For interrupts, PVH uses native_irq_ops so we can skip most of the
PV ones. In the future we can support the pirq_eoi_map..
Also VCPU hotplug is currently not available for PVH.

For events (and IRQs) we follow what PVHVM does - so use callback
vector.  Lastly, for XenBus we use the same logic that is used in
the PVHVM case.

Acked-by: Stefano Stabellini 
Signed-off-by: Mukesh Rathor 
[v2: Rebased it]
[v3: Move 64-bit ifdef and based on Stefan add extra comments.]
[v4: Rebased it once more]
Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/include/asm/xen/interface.h |   11 ++++++++-
 arch/x86/xen/irq.c                   |    5 +++-
 arch/x86/xen/p2m.c                   |    2 +-
 arch/x86/xen/smp.c                   |   39 +++++++++++++++++++++++++--------
 drivers/xen/cpu_hotplug.c            |    4 ++-
 drivers/xen/events.c                 |    9 +++++++-
 drivers/xen/xenbus/xenbus_client.c   |    3 +-
 7 files changed, 57 insertions(+), 16 deletions(-)

diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
index 6d2f75a..4c08f23 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -144,7 +144,16 @@ struct vcpu_guest_context {
     struct cpu_user_regs user_regs;         /* User-level CPU registers     */
     struct trap_info trap_ctxt[256];        /* Virtual IDT                  */
     unsigned long ldt_base, ldt_ents;       /* LDT (linear address, # ents) */
-    unsigned long gdt_frames[16], gdt_ents; /* GDT (machine frames, # ents) */
+    union {
+	struct {
+		/* PV: GDT (machine frames, # ents).*/
+		unsigned long gdt_frames[16], gdt_ents;
+	} pv;
+	struct {
+		/* PVH: GDTR addr and size */
+		unsigned long gdtaddr, gdtsz;
+	} pvh;
+    } u;
     unsigned long kernel_ss, kernel_sp;     /* Virtual TSS (only SS1/SP1)   */
     /* NB. User pagetable on x86/64 is placed in ctrlreg[1]. */
     unsigned long ctrlreg[8];               /* CR0-CR7 (control registers)  */
diff --git a/arch/x86/xen/irq.c b/arch/x86/xen/irq.c
index 01a4dc0..fcbe56a 100644
--- a/arch/x86/xen/irq.c
+++ b/arch/x86/xen/irq.c
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -129,6 +130,8 @@ static const struct pv_irq_ops xen_irq_ops __initconst = {
 
 void __init xen_init_irq_ops(void)
 {
-	pv_irq_ops = xen_irq_ops;
+	/* For PVH we use default pv_irq_ops settings */
+	if (!xen_feature(XENFEAT_hvm_callback_vector))
+		pv_irq_ops = xen_irq_ops;
 	x86_init.irqs.intr_init = xen_init_IRQ;
 }
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 95fb2aa..ea553c8 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -798,7 +798,7 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 {
 	unsigned topidx, mididx, idx;
 
-	if (unlikely(xen_feature(XENFEAT_auto_translated_physmap))) {
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
 		BUG_ON(pfn != mfn && mfn != INVALID_P2M_ENTRY);
 		return true;
 	}
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 6947c4e..448f737 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -68,9 +68,11 @@ static void __cpuinit cpu_bringup(void)
 	touch_softlockup_watchdog();
 	preempt_disable();
 
-	xen_enable_sysenter();
-	xen_enable_syscall();
-
+	/* PVH runs in ring 0 and allows us to do native syscalls. Yay! */
+	if (!xen_feature(XENFEAT_supervisor_mode_kernel)) {
+		xen_enable_sysenter();
+		xen_enable_syscall();
+	}
 	cpu = smp_processor_id();
 	smp_store_cpu_info(cpu);
 	cpu_data(cpu).x86_max_cores = 1;
@@ -230,10 +232,11 @@ static void __init xen_smp_prepare_boot_cpu(void)
 	BUG_ON(smp_processor_id() != 0);
 	native_smp_prepare_boot_cpu();
 
-	/* We've switched to the "real" per-cpu gdt, so make sure the
-	   old memory can be recycled */
-	make_lowmem_page_readwrite(xen_initial_gdt);
-
+	if (!xen_feature(XENFEAT_writable_page_tables)) {
+		/* We've switched to the "real" per-cpu gdt, so make sure the
+		 * old memory can be recycled */
+		make_lowmem_page_readwrite(xen_initial_gdt);
+	}
 	xen_filter_cpu_maps();
 	xen_setup_vcpu_info_placement();
 }
@@ -311,7 +314,23 @@ cpu_initialize_context(unsigned int cpu, struct task_struct *idle)
 
 	memset(&ctxt->fpu_ctxt, 0, sizeof(ctxt->fpu_ctxt));
 
-	{
+	if (xen_feature(XENFEAT_auto_translated_physmap) &&
+	    xen_feature(XENFEAT_supervisor_mode_kernel)) {
+		/* Note: PVH is not supported on x86_32. */
+#ifdef CONFIG_X86_64
+		ctxt->user_regs.ds = __KERNEL_DS;
+		ctxt->user_regs.es = 0;
+		ctxt->user_regs.gs = 0;
+
+		/* GUEST_GDTR_BASE and */
+		ctxt->u.pvh.gdtaddr = (unsigned long)gdt;
+		/* GUEST_GDTR_LIMIT in the VMCS. */
+		ctxt->u.pvh.gdtsz = (unsigned long)(GDT_SIZE - 1);
+
+		ctxt->gs_base_user = (unsigned long)
+					per_cpu(irq_stack_union.gs_base, cpu);
+#endif
+	} else {
 		ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
 		ctxt->user_regs.ds = __USER_DS;
 		ctxt->user_regs.es = __USER_DS;
@@ -326,8 +345,8 @@ cpu_initialize_context(unsigned int cpu, struct task_struct *idle)
 		make_lowmem_page_readonly(gdt);
 		make_lowmem_page_readonly(mfn_to_virt(gdt_mfn));
 
-		ctxt->gdt_frames[0] = gdt_mfn;
-		ctxt->gdt_ents      = GDT_ENTRIES;
+		ctxt->u.pv.gdt_frames[0] = gdt_mfn;
+		ctxt->u.pv.gdt_ents      = GDT_ENTRIES;
 
 		ctxt->kernel_ss = __KERNEL_DS;
 		ctxt->kernel_sp = idle->thread.sp0;
diff --git a/drivers/xen/cpu_hotplug.c b/drivers/xen/cpu_hotplug.c
index 4dcfced..de6bcf9 100644
--- a/drivers/xen/cpu_hotplug.c
+++ b/drivers/xen/cpu_hotplug.c
@@ -2,6 +2,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -100,7 +101,8 @@ static int __init setup_vcpu_hotplug_event(void)
 	static struct notifier_block xsn_cpu = {
 		.notifier_call = setup_cpu_watcher };
 
-	if (!xen_pv_domain())
+	/* PVH TBD/FIXME: future work */
+	if (!xen_pv_domain() || xen_feature(XENFEAT_auto_translated_physmap))
 		return -ENODEV;
 
 	register_xenstore_notifier(&xsn_cpu);
diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 59e10a1..7131fdd 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -1774,7 +1774,7 @@ int xen_set_callback_via(uint64_t via)
 }
 EXPORT_SYMBOL_GPL(xen_set_callback_via);
 
-#ifdef CONFIG_XEN_PVHVM
+#ifdef CONFIG_X86
 /* Vector callbacks are better than PCI interrupts to receive event
  * channel notifications because we can receive vector callbacks on any
  * vcpu and we don't need PCI support or APIC interactions. */
@@ -1835,6 +1835,13 @@ void __init xen_init_IRQ(void)
 		if (xen_initial_domain())
 			pci_xen_initial_domain();
 
+		if (xen_feature(XENFEAT_hvm_callback_vector)) {
+			xen_callback_vector();
+			return;
+		}
+
+		/* PVH: TBD/FIXME: debug and fix eio map to work with pvh */
+
 		pirq_eoi_map = (void *)__get_free_page(GFP_KERNEL|__GFP_ZERO);
 		eoi_gmfn.gmfn = virt_to_mfn(pirq_eoi_map);
 		rc = HYPERVISOR_physdev_op(PHYSDEVOP_pirq_eoi_gmfn_v2, &eoi_gmfn);
diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
index bcf3ba4..356461e 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -44,6 +44,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "xenbus_probe.h"
 
@@ -741,7 +742,7 @@ static const struct xenbus_ring_ops ring_ops_hvm = {
 
 void __init xenbus_ring_ops_init(void)
 {
-	if (xen_pv_domain())
+	if (xen_pv_domain() && !xen_feature(XENFEAT_auto_translated_physmap))
 		ring_ops = &ring_ops_pv;
 	else
 		ring_ops = &ring_ops_hvm;
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 18:24:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 18:24:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQj9Z-0006fi-5m; Tue, 23 Oct 2012 18:24:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQj9W-0006de-C8
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 18:24:34 +0000
Received: from [85.158.137.99:43771] by server-14.bemta-3.messagelabs.com id
	63/D7-17276-1E0E6805; Tue, 23 Oct 2012 18:24:33 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1351016670!22632899!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgyNzg1OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3746 invoked from network); 23 Oct 2012 18:24:32 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Oct 2012 18:24:32 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9NIOOlr019718
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 23 Oct 2012 18:24:24 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9NIONg4012285
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 23 Oct 2012 18:24:23 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9NIONdD006287; Tue, 23 Oct 2012 13:24:23 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 23 Oct 2012 11:24:23 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1359840849; Tue, 23 Oct 2012 14:12:13 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	stefano.stabellini@eu.citrix.com, Ian.Campbell@citrix.com,
	mukesh.rathor@oracle.com
Date: Tue, 23 Oct 2012 14:12:07 -0400
Message-Id: <1351015931-16991-7-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
References: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 06/10] xen/pvh: Implement MMU changes for PVH.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Mukesh Rathor 

.. which are surprinsingly small compared to the amount for PV.
First the set/clear mmio pte function make a hypercall to update the
P2M in Xen with 1:1 mapping. Since PVH uses mostly native mmu ops, we
leave the generic (native_*) for the majority and just overwrite the
baremetal with the ones we need.

Two local functions are introduced to add to Xen physmap for Xen remap
interface. Xen unmap interface is introduced so that the privcmd PTe entries
can be cleared in Xen P2M table.

Signed-off-by: Mukesh Rathor 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/xen/mmu.c    |  162 +++++++++++++++++++++++++++++++++++++++++++++++--
 arch/x86/xen/mmu.h    |    2 +
 drivers/xen/privcmd.c |    5 +-
 include/xen/xen-ops.h |    5 +-
 4 files changed, 165 insertions(+), 9 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 6226c99..5747a41 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -74,6 +74,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "multicalls.h"
 #include "mmu.h"
@@ -332,6 +333,20 @@ static void xen_set_pte(pte_t *ptep, pte_t pteval)
 	__xen_set_pte(ptep, pteval);
 }
 
+void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn,
+			      int nr_mfns, int add_mapping)
+{
+	struct physdev_map_iomem iomem;
+
+	iomem.first_gfn = pfn;
+	iomem.first_mfn = mfn;
+	iomem.nr_mfns = nr_mfns;
+	iomem.add_mapping = add_mapping;
+
+	if (HYPERVISOR_physdev_op(PHYSDEVOP_map_iomem, &iomem))
+		BUG();
+}
+
 static void xen_set_pte_at(struct mm_struct *mm, unsigned long addr,
 		    pte_t *ptep, pte_t pteval)
 {
@@ -1221,6 +1236,8 @@ static void __init xen_pagetable_init(void)
 #endif
 	paging_init();
 	xen_setup_shared_info();
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return;
 #ifdef CONFIG_X86_64
 	if (!xen_feature(XENFEAT_auto_translated_physmap)) {
 		unsigned long new_mfn_list;
@@ -1528,6 +1545,10 @@ static void __init xen_set_pte_init(pte_t *ptep, pte_t pte)
 static void pin_pagetable_pfn(unsigned cmd, unsigned long pfn)
 {
 	struct mmuext_op op;
+
+	if (xen_feature(XENFEAT_writable_page_tables))
+		return;
+
 	op.cmd = cmd;
 	op.arg1.mfn = pfn_to_mfn(pfn);
 	if (HYPERVISOR_mmuext_op(&op, 1, NULL, DOMID_SELF))
@@ -1725,6 +1746,10 @@ static void set_page_prot(void *addr, pgprot_t prot)
 	unsigned long pfn = __pa(addr) >> PAGE_SHIFT;
 	pte_t pte = pfn_pte(pfn, prot);
 
+	/* recall for PVH, page tables are native. */
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return;
+
 	if (HYPERVISOR_update_va_mapping((unsigned long)addr, pte, 0))
 		BUG();
 }
@@ -1802,6 +1827,9 @@ static void convert_pfn_mfn(void *v)
 	pte_t *pte = v;
 	int i;
 
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return;
+
 	/* All levels are converted the same way, so just treat them
 	   as ptes. */
 	for (i = 0; i < PTRS_PER_PTE; i++)
@@ -1821,6 +1849,7 @@ static void __init check_pt_base(unsigned long *pt_base, unsigned long *pt_end,
 		(*pt_end)--;
 	}
 }
+
 /*
  * Set up the initial kernel pagetable.
  *
@@ -1831,6 +1860,7 @@ static void __init check_pt_base(unsigned long *pt_base, unsigned long *pt_end,
  * but that's enough to get __va working.  We need to fill in the rest
  * of the physical mapping once some sort of allocator has been set
  * up.
+ * NOTE: for PVH, the page tables are native.
  */
 void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn)
 {
@@ -1908,10 +1938,13 @@ void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn)
 	 * structure to attach it to, so make sure we just set kernel
 	 * pgd.
 	 */
-	xen_mc_batch();
-	__xen_write_cr3(true, __pa(init_level4_pgt));
-	xen_mc_issue(PARAVIRT_LAZY_CPU);
-
+	if (xen_feature(XENFEAT_writable_page_tables)) {
+		native_write_cr3(__pa(init_level4_pgt));
+	} else {
+		xen_mc_batch();
+		__xen_write_cr3(true, __pa(init_level4_pgt));
+		xen_mc_issue(PARAVIRT_LAZY_CPU);
+	}
 	/* We can't that easily rip out L3 and L2, as the Xen pagetables are
 	 * set out this way: [L4], [L1], [L2], [L3], [L1], [L1] ...  for
 	 * the initial domain. For guests using the toolstack, they are in:
@@ -2178,8 +2211,13 @@ static const struct pv_mmu_ops xen_mmu_ops __initconst = {
 
 void __init xen_init_mmu_ops(void)
 {
-	x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
 	x86_init.paging.pagetable_init = xen_pagetable_init;
+
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		pv_mmu_ops.flush_tlb_others = xen_flush_tlb_others;
+		return;
+	}
+	x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
 	pv_mmu_ops = xen_mmu_ops;
 
 	memset(dummy_mapping, 0xff, PAGE_SIZE);
@@ -2455,6 +2493,89 @@ void __init xen_hvm_init_mmu_ops(void)
 }
 #endif
 
+/* Map foreign gmfn, fgmfn, to local pfn, lpfn. This for the user space
+ * creating new guest on PVH dom0 and needs to map domU pages.
+ */
+static int pvh_add_to_xen_p2m(unsigned long lpfn, unsigned long fgmfn,
+			      unsigned int domid)
+{
+	int rc;
+	struct xen_add_to_physmap xatp = { .foreign_domid = domid };
+
+	xatp.gpfn = lpfn;
+	xatp.idx = fgmfn;
+	xatp.domid = DOMID_SELF;
+	xatp.space = XENMAPSPACE_gmfn_foreign;
+	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
+	if (rc)
+		pr_warn("d0: Failed to map pfn (0x%lx) to mfn (0x%lx) rc:%d\n",
+			lpfn, fgmfn, rc);
+	return rc;
+}
+
+static int pvh_rem_xen_p2m(unsigned long spfn, int count)
+{
+	struct xen_remove_from_physmap xrp;
+	int i, rc;
+
+	for (i = 0; i < count; i++) {
+		xrp.domid = DOMID_SELF;
+		xrp.gpfn = spfn+i;
+		rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, &xrp);
+		if (rc) {
+			pr_warn("Failed to unmap pfn:%lx rc:%d done:%d\n",
+				spfn+i, rc, i);
+			return 1;
+		}
+	}
+	return 0;
+}
+
+struct pvh_remap_data {
+	unsigned long fgmfn;		/* foreign domain's gmfn */
+	pgprot_t prot;
+	domid_t  domid;
+	int	 index;
+	struct page **pages;
+};
+
+static int pvh_map_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr,
+			void *data)
+{
+	int rc;
+	struct pvh_remap_data *remap = data;
+	unsigned long pfn = page_to_pfn(remap->pages[remap->index++]);
+	pte_t pteval = pte_mkspecial(pfn_pte(pfn, remap->prot));
+
+	rc = pvh_add_to_xen_p2m(pfn, remap->fgmfn, remap->domid);
+	if (rc)
+		return rc;
+	native_set_pte(ptep, pteval);
+
+	return 0;
+}
+
+static int pvh_remap_gmfn_range(struct vm_area_struct *vma,
+				unsigned long addr, unsigned long mfn, int nr,
+				pgprot_t prot, unsigned domid,
+				struct page **pages)
+{
+	int err;
+	struct pvh_remap_data pvhdata;
+
+	BUG_ON(!pages);
+
+	pvhdata.fgmfn = mfn;
+	pvhdata.prot = prot;
+	pvhdata.domid = domid;
+	pvhdata.index = 0;
+	pvhdata.pages = pages;
+	err = apply_to_page_range(vma->vm_mm, addr, nr << PAGE_SHIFT,
+				  pvh_map_pte_fn, &pvhdata);
+	flush_tlb_all();
+	return err;
+}
+
 #define REMAP_BATCH_SIZE 16
 
 struct remap_data {
@@ -2479,7 +2600,9 @@ static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token,
 int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 			       unsigned long addr,
 			       unsigned long mfn, int nr,
-			       pgprot_t prot, unsigned domid)
+			       pgprot_t prot, unsigned domid,
+			       struct page **pages)
+
 {
 	struct remap_data rmd;
 	struct mmu_update mmu_update[REMAP_BATCH_SIZE];
@@ -2494,6 +2617,10 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 
 	BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_IO)) == (VM_PFNMAP | VM_IO)));
 
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		/* We need to update the local page tables and the xen HAP */
+		return pvh_remap_gmfn_range(vma, addr, mfn, nr, prot, domid, pages);
+	}
 	rmd.mfn = mfn;
 	rmd.prot = prot;
 
@@ -2523,3 +2650,26 @@ out:
 	return err;
 }
 EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
+
+/* Returns: 0 success */
+int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
+			       int numpgs, struct page **pages)
+{
+	if (!pages || !xen_feature(XENFEAT_auto_translated_physmap))
+		return 0;
+
+	while (numpgs--) {
+
+		/* the mmu has already cleaned up the process mmu resources at
+		 * this point (lookup_address will return NULL). */
+		unsigned long pfn = page_to_pfn(pages[numpgs]);
+
+		pvh_rem_xen_p2m(pfn, 1);
+	}
+	/* We don't need to flush tlbs because as part of pvh_rem_xen_p2m(),
+	 * the hypervisor will do tlb flushes after removing the p2m entries
+	 * from the EPT/NPT */
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range);
diff --git a/arch/x86/xen/mmu.h b/arch/x86/xen/mmu.h
index 73809bb..6d0bb56 100644
--- a/arch/x86/xen/mmu.h
+++ b/arch/x86/xen/mmu.h
@@ -23,4 +23,6 @@ unsigned long xen_read_cr2_direct(void);
 
 extern void xen_init_mmu_ops(void);
 extern void xen_hvm_init_mmu_ops(void);
+extern void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn,
+				     int nr_mfns, int add_mapping);
 #endif	/* _XEN_MMU_H */
diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 8adb9cc..b612267 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -178,7 +178,7 @@ static int mmap_mfn_range(void *data, void *state)
 					msg->va & PAGE_MASK,
 					msg->mfn, msg->npages,
 					vma->vm_page_prot,
-					st->domain);
+					st->domain, NULL);
 	if (rc < 0)
 		return rc;
 
@@ -267,7 +267,8 @@ static int mmap_batch_fn(void *data, void *state)
 	int ret;
 
 	ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
-					 st->vma->vm_page_prot, st->domain);
+					 st->vma->vm_page_prot, st->domain,
+					 NULL);
 
 	/* Store error code for second pass. */
 	*(st->err++) = ret;
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 6a198e4..990b43e 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -27,6 +27,9 @@ struct vm_area_struct;
 int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 			       unsigned long addr,
 			       unsigned long mfn, int nr,
-			       pgprot_t prot, unsigned domid);
+			       pgprot_t prot, unsigned domid,
+			       struct page **pages);
+int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
+			       int numpgs, struct page **pages);
 
 #endif /* INCLUDE_XEN_OPS_H */
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 18:24:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 18:24:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQj9Y-0006ey-0l; Tue, 23 Oct 2012 18:24:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQj9V-0006dM-GP
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 18:24:33 +0000
Received: from [85.158.139.83:60928] by server-16.bemta-5.messagelabs.com id
	48/42-09196-0E0E6805; Tue, 23 Oct 2012 18:24:32 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1351016670!31628104!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiA3NjEy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6465 invoked from network); 23 Oct 2012 18:24:32 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Oct 2012 18:24:32 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9NIOO5O031020
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 23 Oct 2012 18:24:25 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9NIONo8020505
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 23 Oct 2012 18:24:24 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9NIONS7006284; Tue, 23 Oct 2012 13:24:23 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 23 Oct 2012 11:24:23 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 25BA44084B; Tue, 23 Oct 2012 14:12:13 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	stefano.stabellini@eu.citrix.com, Ian.Campbell@citrix.com,
	mukesh.rathor@oracle.com
Date: Tue, 23 Oct 2012 14:12:09 -0400
Message-Id: <1351015931-16991-9-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
References: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 08/10] xen/e820: Coalesce the PVH
	release/populate logic in the generic case.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Squash the PVH specific case in xen_set_identity_and_release_chunk
and make the 'if (PVH..)' case within xen_do_chunk and
xen_set_identity_and_release_chunk function.

Signed-off-by: Konrad Rzeszutek Wilk 
[v2: Remove the extra xlated_phys since it is no longer in use]
---
 arch/x86/xen/setup.c |   60 +++++++++++++++++++------------------------------
 1 files changed, 23 insertions(+), 37 deletions(-)

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 8cce47b..78c5622 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -114,9 +114,15 @@ static unsigned long __init xen_do_chunk(unsigned long start,
 
 		if (release) {
 			/* Make sure pfn exists to start with */
-			if (mfn == INVALID_P2M_ENTRY || mfn_to_pfn(mfn) != pfn)
+			if (mfn == INVALID_P2M_ENTRY || (!xlated_phys && (mfn_to_pfn(mfn) != pfn)))
 				continue;
 			frame = mfn;
+			/* The hypercall PHYSDEVOP_map_iomem to release memory has already
+			 * happend, so we just do a nop here. */
+			if (xlated_phys) {
+				len++;
+				continue;
+			}
 		} else {
 			if (!xlated_phys && mfn != INVALID_P2M_ENTRY)
 				continue;
@@ -219,15 +225,24 @@ static void __init xen_set_identity_and_release_chunk(
 {
 	unsigned long pfn;
 
+	/* For PVH, the pfns [0..MAX] are mapped to mfn's in the EPT/NPT. The mfns
+	 * are released as part of this 1:1 mapping hypercall back to the dom heap.
+	 * Also, we map the entire IO space, ie, beyond max_pfn_mapped.
+	 */
+	int xlated_phys = xen_feature(XENFEAT_auto_translated_physmap);
+
 	/*
 	 * If the PFNs are currently mapped, the VA mapping also needs
 	 * to be updated to be 1:1.
 	 */
-	for (pfn = start_pfn; pfn <= max_pfn_mapped && pfn < end_pfn; pfn++)
-		(void)HYPERVISOR_update_va_mapping(
-			(unsigned long)__va(pfn << PAGE_SHIFT),
-			mfn_pte(pfn, PAGE_KERNEL_IO), 0);
-
+	for (pfn = start_pfn; pfn <= max_pfn_mapped && pfn < end_pfn; pfn++) {
+		if (xlated_phys)
+			xen_set_clr_mmio_pvh_pte(pfn, pfn, 1 /* one pfn */, 1 /* add mapping */);
+		else
+			(void)HYPERVISOR_update_va_mapping(
+				(unsigned long)__va(pfn << PAGE_SHIFT),
+				mfn_pte(pfn, PAGE_KERNEL_IO), 0);
+	}
 	if (start_pfn < nr_pages)
 		*released += xen_release_chunk(
 			start_pfn, min(end_pfn, nr_pages));
@@ -235,27 +250,6 @@ static void __init xen_set_identity_and_release_chunk(
 	*identity += set_phys_range_identity(start_pfn, end_pfn);
 }
 
-/* For PVH, the pfns [0..MAX] are mapped to mfn's in the EPT/NPT. The mfns
- * are released as part of this 1:1 mapping hypercall back to the dom heap.
- * Also, we map the entire IO space, ie, beyond max_pfn_mapped.
- */
-static void __init xen_pvh_identity_map_chunk(unsigned long start_pfn,
-		unsigned long end_pfn, unsigned long *released,
-		unsigned long *identity, unsigned long max_pfn)
-{
-	unsigned long pfn;
-	int numpfns = 1, add_mapping = 1;
-
-	for (pfn = start_pfn; pfn < end_pfn; pfn++)
-		xen_set_clr_mmio_pvh_pte(pfn, pfn, numpfns, add_mapping);
-
-	if (start_pfn <= max_pfn) {
-		unsigned long end = min(max_pfn_mapped, end_pfn);
-		*released += end - start_pfn;
-	}
-	*identity += end_pfn - start_pfn;
-}
-
 static unsigned long __init xen_set_identity_and_release(
 	const struct e820entry *list, size_t map_size, unsigned long nr_pages)
 {
@@ -264,7 +258,6 @@ static unsigned long __init xen_set_identity_and_release(
 	unsigned long identity = 0;
 	const struct e820entry *entry;
 	int i;
-	int xlated_phys = xen_feature(XENFEAT_auto_translated_physmap);
 
 	/*
 	 * Combine non-RAM regions and gaps until a RAM region (or the
@@ -286,17 +279,10 @@ static unsigned long __init xen_set_identity_and_release(
 			if (entry->type == E820_RAM)
 				end_pfn = PFN_UP(entry->addr);
 
-			if (start_pfn < end_pfn) {
-				if (xlated_phys) {
-					xen_pvh_identity_map_chunk(start_pfn,
-						end_pfn, &released, &identity,
-						nr_pages);
-				} else {
-					xen_set_identity_and_release_chunk(
+			if (start_pfn < end_pfn)
+				xen_set_identity_and_release_chunk(
 						start_pfn, end_pfn, nr_pages,
 						&released, &identity);
-				}
-			}
 			start = end;
 		}
 	}
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 18:24:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 18:24:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQj9Y-0006fB-D6; Tue, 23 Oct 2012 18:24:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQj9V-0006dV-Sw
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 18:24:34 +0000
Received: from [85.158.137.99:25354] by server-15.bemta-3.messagelabs.com id
	81/28-10261-1E0E6805; Tue, 23 Oct 2012 18:24:33 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1351016670!17689042!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiA3NjEy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29694 invoked from network); 23 Oct 2012 18:24:32 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-3.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Oct 2012 18:24:32 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9NIOOmS031017
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 23 Oct 2012 18:24:25 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9NION5C020495
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 23 Oct 2012 18:24:24 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9NIONaA023766; Tue, 23 Oct 2012 13:24:23 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 23 Oct 2012 11:24:23 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 0AD3B40848; Tue, 23 Oct 2012 14:12:13 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	stefano.stabellini@eu.citrix.com, Ian.Campbell@citrix.com,
	mukesh.rathor@oracle.com
Date: Tue, 23 Oct 2012 14:12:06 -0400
Message-Id: <1351015931-16991-6-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
References: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 05/10] xen/pvh: Extend vcpu_guest_context, p2m,
	event, and XenBus.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Mukesh Rathor 

Make gdt_frames[]/gdt_ents into a union with {gdtaddr, gdtsz},
as PVH only needs to send down gdtaddr and gdtsz in the
vcpu_guest_context structure..

For interrupts, PVH uses native_irq_ops so we can skip most of the
PV ones. In the future we can support the pirq_eoi_map..
Also VCPU hotplug is currently not available for PVH.

For events (and IRQs) we follow what PVHVM does - so use callback
vector.  Lastly, for XenBus we use the same logic that is used in
the PVHVM case.

Acked-by: Stefano Stabellini 
Signed-off-by: Mukesh Rathor 
[v2: Rebased it]
[v3: Move 64-bit ifdef and based on Stefan add extra comments.]
[v4: Rebased it once more]
Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/include/asm/xen/interface.h |   11 ++++++++-
 arch/x86/xen/irq.c                   |    5 +++-
 arch/x86/xen/p2m.c                   |    2 +-
 arch/x86/xen/smp.c                   |   39 +++++++++++++++++++++++++--------
 drivers/xen/cpu_hotplug.c            |    4 ++-
 drivers/xen/events.c                 |    9 +++++++-
 drivers/xen/xenbus/xenbus_client.c   |    3 +-
 7 files changed, 57 insertions(+), 16 deletions(-)

diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
index 6d2f75a..4c08f23 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -144,7 +144,16 @@ struct vcpu_guest_context {
     struct cpu_user_regs user_regs;         /* User-level CPU registers     */
     struct trap_info trap_ctxt[256];        /* Virtual IDT                  */
     unsigned long ldt_base, ldt_ents;       /* LDT (linear address, # ents) */
-    unsigned long gdt_frames[16], gdt_ents; /* GDT (machine frames, # ents) */
+    union {
+	struct {
+		/* PV: GDT (machine frames, # ents).*/
+		unsigned long gdt_frames[16], gdt_ents;
+	} pv;
+	struct {
+		/* PVH: GDTR addr and size */
+		unsigned long gdtaddr, gdtsz;
+	} pvh;
+    } u;
     unsigned long kernel_ss, kernel_sp;     /* Virtual TSS (only SS1/SP1)   */
     /* NB. User pagetable on x86/64 is placed in ctrlreg[1]. */
     unsigned long ctrlreg[8];               /* CR0-CR7 (control registers)  */
diff --git a/arch/x86/xen/irq.c b/arch/x86/xen/irq.c
index 01a4dc0..fcbe56a 100644
--- a/arch/x86/xen/irq.c
+++ b/arch/x86/xen/irq.c
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -129,6 +130,8 @@ static const struct pv_irq_ops xen_irq_ops __initconst = {
 
 void __init xen_init_irq_ops(void)
 {
-	pv_irq_ops = xen_irq_ops;
+	/* For PVH we use default pv_irq_ops settings */
+	if (!xen_feature(XENFEAT_hvm_callback_vector))
+		pv_irq_ops = xen_irq_ops;
 	x86_init.irqs.intr_init = xen_init_IRQ;
 }
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 95fb2aa..ea553c8 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -798,7 +798,7 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 {
 	unsigned topidx, mididx, idx;
 
-	if (unlikely(xen_feature(XENFEAT_auto_translated_physmap))) {
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
 		BUG_ON(pfn != mfn && mfn != INVALID_P2M_ENTRY);
 		return true;
 	}
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 6947c4e..448f737 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -68,9 +68,11 @@ static void __cpuinit cpu_bringup(void)
 	touch_softlockup_watchdog();
 	preempt_disable();
 
-	xen_enable_sysenter();
-	xen_enable_syscall();
-
+	/* PVH runs in ring 0 and allows us to do native syscalls. Yay! */
+	if (!xen_feature(XENFEAT_supervisor_mode_kernel)) {
+		xen_enable_sysenter();
+		xen_enable_syscall();
+	}
 	cpu = smp_processor_id();
 	smp_store_cpu_info(cpu);
 	cpu_data(cpu).x86_max_cores = 1;
@@ -230,10 +232,11 @@ static void __init xen_smp_prepare_boot_cpu(void)
 	BUG_ON(smp_processor_id() != 0);
 	native_smp_prepare_boot_cpu();
 
-	/* We've switched to the "real" per-cpu gdt, so make sure the
-	   old memory can be recycled */
-	make_lowmem_page_readwrite(xen_initial_gdt);
-
+	if (!xen_feature(XENFEAT_writable_page_tables)) {
+		/* We've switched to the "real" per-cpu gdt, so make sure the
+		 * old memory can be recycled */
+		make_lowmem_page_readwrite(xen_initial_gdt);
+	}
 	xen_filter_cpu_maps();
 	xen_setup_vcpu_info_placement();
 }
@@ -311,7 +314,23 @@ cpu_initialize_context(unsigned int cpu, struct task_struct *idle)
 
 	memset(&ctxt->fpu_ctxt, 0, sizeof(ctxt->fpu_ctxt));
 
-	{
+	if (xen_feature(XENFEAT_auto_translated_physmap) &&
+	    xen_feature(XENFEAT_supervisor_mode_kernel)) {
+		/* Note: PVH is not supported on x86_32. */
+#ifdef CONFIG_X86_64
+		ctxt->user_regs.ds = __KERNEL_DS;
+		ctxt->user_regs.es = 0;
+		ctxt->user_regs.gs = 0;
+
+		/* GUEST_GDTR_BASE and */
+		ctxt->u.pvh.gdtaddr = (unsigned long)gdt;
+		/* GUEST_GDTR_LIMIT in the VMCS. */
+		ctxt->u.pvh.gdtsz = (unsigned long)(GDT_SIZE - 1);
+
+		ctxt->gs_base_user = (unsigned long)
+					per_cpu(irq_stack_union.gs_base, cpu);
+#endif
+	} else {
 		ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
 		ctxt->user_regs.ds = __USER_DS;
 		ctxt->user_regs.es = __USER_DS;
@@ -326,8 +345,8 @@ cpu_initialize_context(unsigned int cpu, struct task_struct *idle)
 		make_lowmem_page_readonly(gdt);
 		make_lowmem_page_readonly(mfn_to_virt(gdt_mfn));
 
-		ctxt->gdt_frames[0] = gdt_mfn;
-		ctxt->gdt_ents      = GDT_ENTRIES;
+		ctxt->u.pv.gdt_frames[0] = gdt_mfn;
+		ctxt->u.pv.gdt_ents      = GDT_ENTRIES;
 
 		ctxt->kernel_ss = __KERNEL_DS;
 		ctxt->kernel_sp = idle->thread.sp0;
diff --git a/drivers/xen/cpu_hotplug.c b/drivers/xen/cpu_hotplug.c
index 4dcfced..de6bcf9 100644
--- a/drivers/xen/cpu_hotplug.c
+++ b/drivers/xen/cpu_hotplug.c
@@ -2,6 +2,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -100,7 +101,8 @@ static int __init setup_vcpu_hotplug_event(void)
 	static struct notifier_block xsn_cpu = {
 		.notifier_call = setup_cpu_watcher };
 
-	if (!xen_pv_domain())
+	/* PVH TBD/FIXME: future work */
+	if (!xen_pv_domain() || xen_feature(XENFEAT_auto_translated_physmap))
 		return -ENODEV;
 
 	register_xenstore_notifier(&xsn_cpu);
diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 59e10a1..7131fdd 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -1774,7 +1774,7 @@ int xen_set_callback_via(uint64_t via)
 }
 EXPORT_SYMBOL_GPL(xen_set_callback_via);
 
-#ifdef CONFIG_XEN_PVHVM
+#ifdef CONFIG_X86
 /* Vector callbacks are better than PCI interrupts to receive event
  * channel notifications because we can receive vector callbacks on any
  * vcpu and we don't need PCI support or APIC interactions. */
@@ -1835,6 +1835,13 @@ void __init xen_init_IRQ(void)
 		if (xen_initial_domain())
 			pci_xen_initial_domain();
 
+		if (xen_feature(XENFEAT_hvm_callback_vector)) {
+			xen_callback_vector();
+			return;
+		}
+
+		/* PVH: TBD/FIXME: debug and fix eio map to work with pvh */
+
 		pirq_eoi_map = (void *)__get_free_page(GFP_KERNEL|__GFP_ZERO);
 		eoi_gmfn.gmfn = virt_to_mfn(pirq_eoi_map);
 		rc = HYPERVISOR_physdev_op(PHYSDEVOP_pirq_eoi_gmfn_v2, &eoi_gmfn);
diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
index bcf3ba4..356461e 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -44,6 +44,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "xenbus_probe.h"
 
@@ -741,7 +742,7 @@ static const struct xenbus_ring_ops ring_ops_hvm = {
 
 void __init xenbus_ring_ops_init(void)
 {
-	if (xen_pv_domain())
+	if (xen_pv_domain() && !xen_feature(XENFEAT_auto_translated_physmap))
 		ring_ops = &ring_ops_pv;
 	else
 		ring_ops = &ring_ops_hvm;
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 18:24:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 18:24:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQj9V-0006dW-Ik; Tue, 23 Oct 2012 18:24:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQj9U-0006d4-8D
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 18:24:32 +0000
Received: from [85.158.139.83:9057] by server-15.bemta-5.messagelabs.com id
	65/03-28599-FD0E6805; Tue, 23 Oct 2012 18:24:31 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1351016669!32280386!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODIwNzA4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24210 invoked from network); 23 Oct 2012 18:24:30 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Oct 2012 18:24:30 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9NIOMFU014502
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 23 Oct 2012 18:24:23 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9NIOMbd012223
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 23 Oct 2012 18:24:22 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9NIOMot023743; Tue, 23 Oct 2012 13:24:22 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 23 Oct 2012 11:24:21 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E2C3C403C7; Tue, 23 Oct 2012 14:12:12 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	stefano.stabellini@eu.citrix.com, Ian.Campbell@citrix.com,
	mukesh.rathor@oracle.com
Date: Tue, 23 Oct 2012 14:12:03 -0400
Message-Id: <1351015931-16991-3-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
References: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 02/10] xen/pvh: Fix PVHVM 32-bit bootup problems.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

With the split of the 'unsigned int space' in a 'u16 space'
and 'u16 foreign_domid' in xen_add_to_physmap the compiler
won't write the full 32-bit value in 'space'. Instead
it will write a 16-bit value - which is OK. The problem
is that we allocate the xen_add_to_physmap structure from
the stack which can (and it has) various garbage on it.

The end result is that without this patch we end up
providing this to the hypervisor:

   xatp.space = 0xc1310001;
instead of:
   xatp.space = 0x1;

Forcing the foreign_domid to 0, will over-write the garbage
that was on the stack.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/xen/enlighten.c  |    1 +
 drivers/xen/grant-table.c |    1 +
 2 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index e3497f2..b679f86 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1509,6 +1509,7 @@ void __ref xen_hvm_init_shared_info(void)
 	xatp.domid = DOMID_SELF;
 	xatp.idx = 0;
 	xatp.space = XENMAPSPACE_shared_info;
+	xatp.foreign_domid = 0;
 	xatp.gpfn = __pa(shared_info_page) >> PAGE_SHIFT;
 	if (HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp))
 		BUG();
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index b2b0a37..cbfd929 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -1044,6 +1044,7 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 		do {
 			xatp.domid = DOMID_SELF;
 			xatp.idx = i;
+			xatp.foreign_domid = 0;
 			xatp.space = XENMAPSPACE_grant_table;
 			xatp.gpfn = (xen_hvm_resume_frames >> PAGE_SHIFT) + i;
 			rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 18:24:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 18:24:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQj9X-0006eS-4P; Tue, 23 Oct 2012 18:24:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQj9V-0006dC-47
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 18:24:33 +0000
Received: from [85.158.139.211:14220] by server-10.bemta-5.messagelabs.com id
	F2/61-01025-0E0E6805; Tue, 23 Oct 2012 18:24:32 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1351016670!22974531!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODIwNzA4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20247 invoked from network); 23 Oct 2012 18:24:31 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Oct 2012 18:24:31 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9NIONAF014507
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 23 Oct 2012 18:24:24 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9NIOMb0020461
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 23 Oct 2012 18:24:23 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9NIOM6f015426; Tue, 23 Oct 2012 13:24:22 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 23 Oct 2012 11:24:21 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id EC3874042F; Tue, 23 Oct 2012 14:12:12 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	stefano.stabellini@eu.citrix.com, Ian.Campbell@citrix.com,
	mukesh.rathor@oracle.com
Date: Tue, 23 Oct 2012 14:12:04 -0400
Message-Id: <1351015931-16991-4-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
References: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 03/10] xen/hypercall: Make
	xen_remove_from_physmap the same on 64/32 builds.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

By making the structure exactly the same size and with the same
offsets on 64 and 32-bit builds we are future-proofing ourselves.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 include/xen/interface/memory.h |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index 8beebdb..6b07b54 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -253,9 +253,14 @@ extern spinlock_t xen_reservation_lock;
 struct xen_remove_from_physmap {
     /* Which domain to change the mapping for. */
     domid_t domid;
-
+   /* To be used in the future if need to. */
+    uint8_t reserved[6];
     /* GPFN of the current mapping of the page. */
     xen_pfn_t gpfn;
+#ifdef CONFIG_X86_32
+    /* No need to do that on ARM as xen_pfn_t is always 8 bytes. */
+    uint8_t __pad[4];
+#endif
 };
 DEFINE_GUEST_HANDLE_STRUCT(xen_remove_from_physmap);
 
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 18:24:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 18:24:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQj9W-0006e9-O5; Tue, 23 Oct 2012 18:24:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQj9U-0006d7-QK
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 18:24:33 +0000
Received: from [85.158.143.35:65265] by server-3.bemta-4.messagelabs.com id
	00/E7-03544-FD0E6805; Tue, 23 Oct 2012 18:24:31 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1351016669!12680113!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODIwNzA4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14429 invoked from network); 23 Oct 2012 18:24:30 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Oct 2012 18:24:30 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9NIOO9F014524
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 23 Oct 2012 18:24:24 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9NIONKa012284
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 23 Oct 2012 18:24:23 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9NIONxo023773; Tue, 23 Oct 2012 13:24:23 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 23 Oct 2012 11:24:23 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1C9744084A; Tue, 23 Oct 2012 14:12:13 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	stefano.stabellini@eu.citrix.com, Ian.Campbell@citrix.com,
	mukesh.rathor@oracle.com
Date: Tue, 23 Oct 2012 14:12:08 -0400
Message-Id: <1351015931-16991-8-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
References: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 07/10] xen/pvh: bootup and setup (E820) related
	changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Mukesh Rathor 

In the bootup code for PVH we can trap cpuid via vmexit, so don't
need to use emulated prefix call. We also check for vector callback
early on, as it is a required feature. PVH also runs at default kernel
IOPL.

In setup.c which deals with E820, in xen_add_extra_mem() we can skip
updating P2M as it's managed by Xen. PVH maps the entire IO space,
but only RAM pages need to be repopulated.

Finally, pure PV settings are moved to a separate function that are
only called for pure PV, ie, pv with pvmmu.

Signed-off-by: Mukesh Rathor 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/xen/enlighten.c |   77 ++++++++++++++++++++++++++++++++++-----------
 arch/x86/xen/setup.c     |   64 +++++++++++++++++++++++++++++++-------
 2 files changed, 110 insertions(+), 31 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index b679f86..bd8f718 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -45,6 +45,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -107,6 +108,9 @@ RESERVE_BRK(shared_info_page_brk, PAGE_SIZE);
 __read_mostly int xen_have_vector_callback;
 EXPORT_SYMBOL_GPL(xen_have_vector_callback);
 
+#define xen_pvh_domain() (xen_pv_domain() && \
+			  xen_feature(XENFEAT_auto_translated_physmap) && \
+			  xen_have_vector_callback)
 /*
  * Point at some empty memory to start with. We map the real shared_info
  * page as soon as fixmap is up and running.
@@ -219,8 +223,9 @@ static void __init xen_banner(void)
 	struct xen_extraversion extra;
 	HYPERVISOR_xen_version(XENVER_extraversion, &extra);
 
-	printk(KERN_INFO "Booting paravirtualized kernel on %s\n",
-	       pv_info.name);
+	pr_info("Booting paravirtualized kernel %son %s\n",
+		xen_feature(XENFEAT_auto_translated_physmap) ?
+			"with PVH extensions " : "", pv_info.name);
 	printk(KERN_INFO "Xen version: %d.%d%s%s\n",
 	       version >> 16, version & 0xffff, extra.extraversion,
 	       xen_feature(XENFEAT_mmu_pt_update_preserve_ad) ? " (preserve-AD)" : "");
@@ -273,12 +278,15 @@ static void xen_cpuid(unsigned int *ax, unsigned int *bx,
 		break;
 	}
 
-	asm(XEN_EMULATE_PREFIX "cpuid"
-		: "=a" (*ax),
-		  "=b" (*bx),
-		  "=c" (*cx),
-		  "=d" (*dx)
-		: "0" (*ax), "2" (*cx));
+	if (xen_pvh_domain())
+		native_cpuid(ax, bx, cx, dx);
+	else
+		asm(XEN_EMULATE_PREFIX "cpuid"
+			: "=a" (*ax),
+			"=b" (*bx),
+			"=c" (*cx),
+			"=d" (*dx)
+			: "0" (*ax), "2" (*cx));
 
 	*bx &= maskebx;
 	*cx &= maskecx;
@@ -1055,6 +1063,10 @@ void xen_setup_shared_info(void)
 		HYPERVISOR_shared_info =
 			(struct shared_info *)__va(xen_start_info->shared_info);
 
+	/* PVH TBD/FIXME: vcpu info placement in phase 2 */
+	if (xen_pvh_domain())
+		return;
+
 #ifndef CONFIG_SMP
 	/* In UP this is as good a place as any to set up shared info */
 	xen_setup_vcpu_info_placement();
@@ -1292,6 +1304,11 @@ static const struct machine_ops xen_machine_ops __initconst = {
  */
 static void __init xen_setup_stackprotector(void)
 {
+	/* PVH TBD/FIXME: investigate setup_stack_canary_segment */
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		switch_to_new_gdt(0);
+		return;
+	}
 	pv_cpu_ops.write_gdt_entry = xen_write_gdt_entry_boot;
 	pv_cpu_ops.load_gdt = xen_load_gdt_boot;
 
@@ -1302,6 +1319,19 @@ static void __init xen_setup_stackprotector(void)
 	pv_cpu_ops.load_gdt = xen_load_gdt;
 }
 
+static void __init xen_pvh_early_guest_init(void)
+{
+	if (xen_feature(XENFEAT_hvm_callback_vector))
+		xen_have_vector_callback = 1;
+
+#ifdef CONFIG_X86_32
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		xen_raw_printk("ERROR: 32bit PVH guests are not supported\n");
+		BUG();
+	}
+#endif
+}
+
 /* First C function to be called on Xen boot */
 asmlinkage void __init xen_start_kernel(void)
 {
@@ -1313,13 +1343,18 @@ asmlinkage void __init xen_start_kernel(void)
 
 	xen_domain_type = XEN_PV_DOMAIN;
 
+	xen_setup_features();
+	xen_pvh_early_guest_init();
 	xen_setup_machphys_mapping();
 
 	/* Install Xen paravirt ops */
 	pv_info = xen_info;
 	pv_init_ops = xen_init_ops;
-	pv_cpu_ops = xen_cpu_ops;
 	pv_apic_ops = xen_apic_ops;
+	if (xen_pvh_domain())
+		pv_cpu_ops.cpuid = xen_cpuid;
+	else
+		pv_cpu_ops = xen_cpu_ops;
 
 	x86_init.resources.memory_setup = xen_memory_setup;
 	x86_init.oem.arch_setup = xen_arch_setup;
@@ -1351,8 +1386,6 @@ asmlinkage void __init xen_start_kernel(void)
 	/* Work out if we support NX */
 	x86_configure_nx();
 
-	xen_setup_features();
-
 	/* Get mfn list */
 	if (!xen_feature(XENFEAT_auto_translated_physmap))
 		xen_build_dynamic_phys_to_machine();
@@ -1423,14 +1456,18 @@ asmlinkage void __init xen_start_kernel(void)
 	/* set the limit of our address space */
 	xen_reserve_top();
 
-	/* We used to do this in xen_arch_setup, but that is too late on AMD
-	 * were early_cpu_init (run before ->arch_setup()) calls early_amd_init
-	 * which pokes 0xcf8 port.
-	 */
-	set_iopl.iopl = 1;
-	rc = HYPERVISOR_physdev_op(PHYSDEVOP_set_iopl, &set_iopl);
-	if (rc != 0)
-		xen_raw_printk("physdev_op failed %d\n", rc);
+	/* PVH: runs at default kernel iopl of 0 */
+	if (!xen_pvh_domain()) {
+		/*
+		 * We used to do this in xen_arch_setup, but that is too late
+		 * on AMD were early_cpu_init (run before ->arch_setup()) calls
+		 * early_amd_init which pokes 0xcf8 port.
+		 */
+		set_iopl.iopl = 1;
+		rc = HYPERVISOR_physdev_op(PHYSDEVOP_set_iopl, &set_iopl);
+		if (rc != 0)
+			xen_raw_printk("physdev_op failed %d\n", rc);
+	}
 
 #ifdef CONFIG_X86_32
 	/* set up basic CPUID stuff */
@@ -1497,6 +1534,8 @@ asmlinkage void __init xen_start_kernel(void)
 #endif
 }
 
+/* Use a pfn in RAM, may move to MMIO before kexec.
+ * This function also called for PVH dom0 */
 void __ref xen_hvm_init_shared_info(void)
 {
 	int cpu;
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 8971a26..8cce47b 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include "mmu.h"
 #include "xen-ops.h"
 #include "vdso.h"
 
@@ -78,6 +79,9 @@ static void __init xen_add_extra_mem(u64 start, u64 size)
 
 	memblock_reserve(start, size);
 
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return;
+
 	xen_max_p2m_pfn = PFN_DOWN(start + size);
 	for (pfn = PFN_DOWN(start); pfn < xen_max_p2m_pfn; pfn++) {
 		unsigned long mfn = pfn_to_mfn(pfn);
@@ -100,6 +104,7 @@ static unsigned long __init xen_do_chunk(unsigned long start,
 		.domid        = DOMID_SELF
 	};
 	unsigned long len = 0;
+	int xlated_phys = xen_feature(XENFEAT_auto_translated_physmap);
 	unsigned long pfn;
 	int ret;
 
@@ -113,7 +118,7 @@ static unsigned long __init xen_do_chunk(unsigned long start,
 				continue;
 			frame = mfn;
 		} else {
-			if (mfn != INVALID_P2M_ENTRY)
+			if (!xlated_phys && mfn != INVALID_P2M_ENTRY)
 				continue;
 			frame = pfn;
 		}
@@ -230,6 +235,27 @@ static void __init xen_set_identity_and_release_chunk(
 	*identity += set_phys_range_identity(start_pfn, end_pfn);
 }
 
+/* For PVH, the pfns [0..MAX] are mapped to mfn's in the EPT/NPT. The mfns
+ * are released as part of this 1:1 mapping hypercall back to the dom heap.
+ * Also, we map the entire IO space, ie, beyond max_pfn_mapped.
+ */
+static void __init xen_pvh_identity_map_chunk(unsigned long start_pfn,
+		unsigned long end_pfn, unsigned long *released,
+		unsigned long *identity, unsigned long max_pfn)
+{
+	unsigned long pfn;
+	int numpfns = 1, add_mapping = 1;
+
+	for (pfn = start_pfn; pfn < end_pfn; pfn++)
+		xen_set_clr_mmio_pvh_pte(pfn, pfn, numpfns, add_mapping);
+
+	if (start_pfn <= max_pfn) {
+		unsigned long end = min(max_pfn_mapped, end_pfn);
+		*released += end - start_pfn;
+	}
+	*identity += end_pfn - start_pfn;
+}
+
 static unsigned long __init xen_set_identity_and_release(
 	const struct e820entry *list, size_t map_size, unsigned long nr_pages)
 {
@@ -238,6 +264,7 @@ static unsigned long __init xen_set_identity_and_release(
 	unsigned long identity = 0;
 	const struct e820entry *entry;
 	int i;
+	int xlated_phys = xen_feature(XENFEAT_auto_translated_physmap);
 
 	/*
 	 * Combine non-RAM regions and gaps until a RAM region (or the
@@ -259,11 +286,17 @@ static unsigned long __init xen_set_identity_and_release(
 			if (entry->type == E820_RAM)
 				end_pfn = PFN_UP(entry->addr);
 
-			if (start_pfn < end_pfn)
-				xen_set_identity_and_release_chunk(
-					start_pfn, end_pfn, nr_pages,
-					&released, &identity);
-
+			if (start_pfn < end_pfn) {
+				if (xlated_phys) {
+					xen_pvh_identity_map_chunk(start_pfn,
+						end_pfn, &released, &identity,
+						nr_pages);
+				} else {
+					xen_set_identity_and_release_chunk(
+						start_pfn, end_pfn, nr_pages,
+						&released, &identity);
+				}
+			}
 			start = end;
 		}
 	}
@@ -526,16 +559,14 @@ void __cpuinit xen_enable_syscall(void)
 #endif /* CONFIG_X86_64 */
 }
 
-void __init xen_arch_setup(void)
+/* Non auto translated PV domain, ie, it's not PVH. */
+static __init void xen_pvmmu_arch_setup(void)
 {
-	xen_panic_handler_init();
-
 	HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_4gb_segments);
 	HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_writable_pagetables);
 
-	if (!xen_feature(XENFEAT_auto_translated_physmap))
-		HYPERVISOR_vm_assist(VMASST_CMD_enable,
-				     VMASST_TYPE_pae_extended_cr3);
+	HYPERVISOR_vm_assist(VMASST_CMD_enable,
+			     VMASST_TYPE_pae_extended_cr3);
 
 	if (register_callback(CALLBACKTYPE_event, xen_hypervisor_callback) ||
 	    register_callback(CALLBACKTYPE_failsafe, xen_failsafe_callback))
@@ -543,6 +574,15 @@ void __init xen_arch_setup(void)
 
 	xen_enable_sysenter();
 	xen_enable_syscall();
+}
+
+/* This function not called for HVM domain */
+void __init xen_arch_setup(void)
+{
+	xen_panic_handler_init();
+
+	if (!xen_feature(XENFEAT_auto_translated_physmap))
+		xen_pvmmu_arch_setup();
 
 #ifdef CONFIG_ACPI
 	if (!(xen_start_info->flags & SIF_INITDOMAIN)) {
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 18:24:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 18:24:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQj9X-0006ej-Kv; Tue, 23 Oct 2012 18:24:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQj9V-0006dH-Cb
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 18:24:33 +0000
Received: from [85.158.138.51:39307] by server-5.bemta-3.messagelabs.com id
	60/A6-12440-0E0E6805; Tue, 23 Oct 2012 18:24:32 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1351016669!35411673!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODIwNzA4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16538 invoked from network); 23 Oct 2012 18:24:30 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Oct 2012 18:24:30 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9NIONi5014503
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 23 Oct 2012 18:24:23 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9NIOMnI023608
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 23 Oct 2012 18:24:22 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9NIOLWN006251; Tue, 23 Oct 2012 13:24:21 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 23 Oct 2012 11:24:21 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D91134042D; Tue, 23 Oct 2012 14:12:12 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	stefano.stabellini@eu.citrix.com, Ian.Campbell@citrix.com,
	mukesh.rathor@oracle.com
Date: Tue, 23 Oct 2012 14:12:01 -0400
Message-Id: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Subject: [Xen-devel] [PATCH V5] PVH patches for v3.8.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Changelog [since v4]
 - Mukesh addressed the reviewer's concerns.
 - Took Mukesh's patches and redid the changelogs.
 - Added Ack-ed as appropiate.
 - Fixed PVHVM 32-bit bootup issues.
 - Did some various cleanups, split some patches up.

The big change is that I've made the xen_remove_from_physmap structure
be of the same size and offset on 32 and 64 bit builds. Currently PVH 
only runs with 64-bit guests, but in the future it could run with 32-bit.
This change will eliminate having to add a compat layer to deal with
32-bit hypercalls.

Besides that the patches boot on an normal hypervisor - in
dom0 (32 or 64bit), PV domU (32 or 64) and PVHVM domU (32 or 64).
I don't have the PVH hypervisor patches so I could not address the
change to xen_remove_from_physmap but I hope Mukesh can do that.

The patches are also located at:
 git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/pvh.v5


 arch/x86/include/asm/xen/interface.h |   11 ++-
 arch/x86/include/asm/xen/page.h      |    3 +
 arch/x86/xen/Kconfig                 |   10 ++
 arch/x86/xen/enlighten.c             |   78 ++++++++++++----
 arch/x86/xen/irq.c                   |    5 +-
 arch/x86/xen/mmu.c                   |  162 ++++++++++++++++++++++++++++++++--
 arch/x86/xen/mmu.h                   |    2 +
 arch/x86/xen/p2m.c                   |    2 +-
 arch/x86/xen/setup.c                 |   58 +++++++++----
 arch/x86/xen/smp.c                   |   75 ++++++++++------
 arch/x86/xen/xen-head.S              |   11 ++-
 drivers/xen/balloon.c                |   15 ++--
 drivers/xen/cpu_hotplug.c            |    4 +-
 drivers/xen/events.c                 |    9 ++-
 drivers/xen/gntdev.c                 |    3 +-
 drivers/xen/grant-table.c            |   27 +++++-
 drivers/xen/privcmd.c                |   72 ++++++++++++++-
 drivers/xen/xenbus/xenbus_client.c   |    3 +-
 include/xen/interface/memory.h       |   29 ++++++-
 include/xen/interface/physdev.h      |   10 ++
 include/xen/xen-ops.h                |    5 +-
 21 files changed, 504 insertions(+), 90 deletions(-)

Konrad Rzeszutek Wilk (4):
      xen/pvh: Fix PVHVM 32-bit bootup problems.
      xen/hypercall: Make xen_remove_from_physmap the same on 64/32 builds.
      xen/smp: Move the common CPU init code a bit to prep for PVH patch.
      xen/e820: Coalesce the PVH release/populate logic in the generic case.

Mukesh Rathor (6):
      xen/pvh: Support ParaVirtualized Hardware extensions.
      xen/pvh: Extend vcpu_guest_context, p2m, event, and XenBus.
      xen/pvh: Implement MMU changes for PVH.
      xen/pvh: bootup and setup (E820) related changes.
      xen/pvh: balloon and grant changes.
      xen/pvh: /dev/xen/privcmd changes.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 18:24:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 18:24:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQj9W-0006dy-BK; Tue, 23 Oct 2012 18:24:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQj9U-0006d6-LQ
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 18:24:32 +0000
Received: from [85.158.137.99:43225] by server-8.bemta-3.messagelabs.com id
	23/34-10525-FD0E6805; Tue, 23 Oct 2012 18:24:31 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1351016669!22778902!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODIwNzA4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11928 invoked from network); 23 Oct 2012 18:24:30 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-13.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Oct 2012 18:24:30 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9NIONZX014504
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 23 Oct 2012 18:24:23 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9NIOMVT023606
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 23 Oct 2012 18:24:22 GMT
Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9NIOMDH023742; Tue, 23 Oct 2012 13:24:22 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 23 Oct 2012 11:24:21 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id DF8AA402BD; Tue, 23 Oct 2012 14:12:12 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	stefano.stabellini@eu.citrix.com, Ian.Campbell@citrix.com,
	mukesh.rathor@oracle.com
Date: Tue, 23 Oct 2012 14:12:02 -0400
Message-Id: <1351015931-16991-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
References: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 01/10] xen/pvh: Support ParaVirtualized Hardware
	extensions.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Mukesh Rathor 

PVH allows PV linux guest to utilize hardware extended capabilities, such
as running MMU updates in a HVM container.

This patch allows it to be configured and enabled. Also, basic header file
changes to add new subcalls to physmap hypercall.

Lastly, mfn_to_local_pfn must return mfn for paging mode translate
(since we let the hypervisor - or CPU - do them for us).

Acked-by: Stefano Stabellini 
Signed-off-by: Mukesh Rathor 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/include/asm/xen/page.h |    3 +++
 arch/x86/xen/Kconfig            |   10 ++++++++++
 arch/x86/xen/xen-head.S         |   11 ++++++++++-
 include/xen/interface/memory.h  |   24 +++++++++++++++++++++++-
 include/xen/interface/physdev.h |   10 ++++++++++
 5 files changed, 56 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index 472b9b7..6af440d 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -159,6 +159,9 @@ static inline xpaddr_t machine_to_phys(xmaddr_t machine)
 static inline unsigned long mfn_to_local_pfn(unsigned long mfn)
 {
 	unsigned long pfn = mfn_to_pfn(mfn);
+
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return mfn;
 	if (get_phys_to_machine(pfn) != mfn)
 		return -1; /* force !pfn_valid() */
 	return pfn;
diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index fdce49c..c9660bf 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -50,3 +50,13 @@ config XEN_DEBUG_FS
 	  Enable statistics output and various tuning options in debugfs.
 	  Enabling this option may incur a significant performance overhead.
 
+config XEN_X86_PVH
+	bool "Support for running as a PVH guest (EXPERIMENTAL)"
+	depends on X86_64 && XEN && EXPERIMENTAL
+	default n
+	help
+	   This option enables support for running as a PVH guest (PV guest
+	   using hardware extensions) under a suitably capable hypervisor.
+	   This option is EXPERIMENTAL because the hypervisor interfaces
+	   which it uses is not yet considered stable therefore backwards and
+	   forwards compatibility is not yet guaranteed.  If unsure, say N.
diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
index 7faed58..1a6bca1 100644
--- a/arch/x86/xen/xen-head.S
+++ b/arch/x86/xen/xen-head.S
@@ -13,6 +13,15 @@
 #include 
 #include 
 
+#ifdef CONFIG_XEN_X86_PVH
+#define FEATURES_PVH "|writable_descriptor_tables" \
+		     "|auto_translated_physmap" \
+		     "|supervisor_mode_kernel" \
+		     "|hvm_callback_vector"
+#else
+#define FEATURES_PVH /* Not supported */
+#endif
+
 	__INIT
 ENTRY(startup_xen)
 	cld
@@ -95,7 +104,7 @@ NEXT_HYPERCALL(arch_6)
 #endif
 	ELFNOTE(Xen, XEN_ELFNOTE_ENTRY,          _ASM_PTR startup_xen)
 	ELFNOTE(Xen, XEN_ELFNOTE_HYPERCALL_PAGE, _ASM_PTR hypercall_page)
-	ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,       .asciz "!writable_page_tables|pae_pgdir_above_4gb")
+	ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,       .asciz "!writable_page_tables|pae_pgdir_above_4gb"FEATURES_PVH)
 	ELFNOTE(Xen, XEN_ELFNOTE_PAE_MODE,       .asciz "yes")
 	ELFNOTE(Xen, XEN_ELFNOTE_LOADER,         .asciz "generic")
 	ELFNOTE(Xen, XEN_ELFNOTE_L1_MFN_VALID,
diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index b66d04c..8beebdb 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -169,7 +169,13 @@ struct xen_add_to_physmap {
     /* Source mapping space. */
 #define XENMAPSPACE_shared_info 0 /* shared info page */
 #define XENMAPSPACE_grant_table 1 /* grant table page */
-    unsigned int space;
+#define XENMAPSPACE_gmfn        2 /* GMFN */
+#define XENMAPSPACE_gmfn_range  3 /* GMFN range */
+#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */
+    uint16_t space;
+    domid_t foreign_domid;         /* IFF XENMAPSPACE_gmfn_foreign */
+
+#define XENMAPIDX_grant_table_status 0x80000000
 
     /* Index into source mapping space. */
     xen_ulong_t idx;
@@ -237,4 +243,20 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_memory_map);
  * during a driver critical region.
  */
 extern spinlock_t xen_reservation_lock;
+
+/*
+ * Unmaps the page appearing at a particular GPFN from the specified guest's
+ * pseudophysical address space.
+ * arg == addr of xen_remove_from_physmap_t.
+ */
+#define XENMEM_remove_from_physmap      15
+struct xen_remove_from_physmap {
+    /* Which domain to change the mapping for. */
+    domid_t domid;
+
+    /* GPFN of the current mapping of the page. */
+    xen_pfn_t gpfn;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_remove_from_physmap);
+
 #endif /* __XEN_PUBLIC_MEMORY_H__ */
diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
index 1844d31..83050d3 100644
--- a/include/xen/interface/physdev.h
+++ b/include/xen/interface/physdev.h
@@ -274,6 +274,16 @@ struct physdev_dbgp_op {
     } u;
 };
 
+#define PHYSDEVOP_map_iomem        30
+struct physdev_map_iomem {
+    /* IN */
+    uint64_t first_gfn;
+    uint64_t first_mfn;
+    uint32_t nr_mfns;
+    uint32_t add_mapping; /* 1 == add mapping;  0 == unmap */
+
+};
+
 /*
  * Notify that some PIRQ-bound event channels have been unmasked.
  * ** This command is obsolete since interface version 0x00030202 and is **
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 19:03:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 19:03:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQjkr-0008LB-1O; Tue, 23 Oct 2012 19:03:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQjkp-0008L4-QT
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 19:03:08 +0000
Received: from [85.158.139.83:46628] by server-16.bemta-5.messagelabs.com id
	EC/18-04786-BE9E6805; Tue, 23 Oct 2012 19:03:07 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1351018982!30556246!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24706 invoked from network); 23 Oct 2012 19:03:05 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 19:03:05 -0000
Received: by mail-vc0-f173.google.com with SMTP id fl15so192936vcb.32
	for ; Tue, 23 Oct 2012 12:03:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:content-transfer-encoding
	:in-reply-to:user-agent;
	bh=M0DAep7ey/50NI8mONtWNRCvIFYPKPoNTrPU4EC3jeI=;
	b=wSAGUIxNMVJn4VB9/vEA/QIT3YPflUutIi9gskLDL4jmLD6UfeT090Ma/aj5LGx7Te
	xwk4qcOX0HmQupAQ8MyWDGcuYB4WoUP7Y8Iu6s6ECRrTMBG/MOGiUmpKVUyOGqpeESlW
	Opq+56ZfSorkKGtKSPoGfglQZyztP3V9MXSRMIHFJW0gY6HrDAya9LeRo3CwhkuaoT8g
	dYEh7YClA6Cti+dQyai5+JcRZOA5W7332TGhnn7M1fQx2izpxZgLZA8TQWhvtJaJ9XNb
	nvEC9J97jGXw2ODUgNXQlPH4lzxitWtHU4yJYWP+hLkDDaagpcihbGPczRF9W/IY4Tj/
	aQWA==
Received: by 10.220.8.138 with SMTP id h10mr3890694vch.35.1351018981979;
	Tue, 23 Oct 2012 12:03:01 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id xf2sm13143919vec.12.2012.10.23.12.03.00
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 23 Oct 2012 12:03:01 -0700 (PDT)
Date: Tue, 23 Oct 2012 14:50:50 -0400
From: Konrad Rzeszutek Wilk 
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= 
Message-ID: <20121023185049.GB20350@phenom.dumpdata.com>
References: <1350559321-19066-1-git-send-email-roger.pau@citrix.com>
	<20121022134708.GA13832@konrad-lan.dumpdata.com>
	<5086C0C8.5000306@citrix.com>
	<20121023172008.GB11787@phenom.dumpdata.com>
	<5086DD57.4000206@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5086DD57.4000206@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xen.org" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH RFC] Persistent grant maps for xen blk
	drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 23, 2012 at 08:09:27PM +0200, Roger Pau Monn=E9 wrote:
> On 23/10/12 19:20, Konrad Rzeszutek Wilk wrote:
> >>>> diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen=
-blkback/blkback.c
> >>>> index c6decb9..2b982b2 100644
> >>>> --- a/drivers/block/xen-blkback/blkback.c
> >>>> +++ b/drivers/block/xen-blkback/blkback.c
> >>>> @@ -78,6 +78,7 @@ struct pending_req {
> >>>>       unsigned short          operation;
> >>>>       int                     status;
> >>>>       struct list_head        free_list;
> >>>> +     unsigned int            unmap_seg[BLKIF_MAX_SEGMENTS_PER_REQUE=
ST];
> =

> Should I change this to a bool? Since we are only setting it to 0 or 1.

I would just keep it as 'int'. Eventually we can replace this with a
bit-map, but that can be done later.

> =

> >>> Perhaps there should be a #define for that array..
> >>
> >> Do you mean something like:
> >>
> >> #define unmap(req, i) req->unmap_seg[i]
> > =

> > I was thinking that you just check for req->unamp_seg[i] to
> > have an non-zero value. But since that array is just used as an check
> > to see whether the functionality is enabled (or not), you might want
> > to declerare the right values so:
> > #define UNMAP_SG_ON 1
> > #define UNMAP_SG_OFF 0
> > =

> > or so.
> =

> Agreed, will add the defines.
> =

> >>>> +             if (persistent_gnts[i]) {
> >>>> +                     if (!persistent_gnts[i]->handle) {
> >>>> +                             /*
> >>>> +                              * If this is a new persistent grant
> >>>> +                              * save the handler
> >>>> +                              */
> >>>> +                             persistent_gnts[i]->handle =3D map[j].=
handle;
> >>>> +                             persistent_gnts[i]->dev_bus_addr =3D
> >>>> +                                     map[j++].dev_bus_addr;
> >>>> +                     }
> >>>> +                     pending_handle(pending_req, i) =3D
> >>>> +                             persistent_gnts[i]->handle;
> >>>> +                     pending_req->unmap_seg[i] =3D 0;
> >>>
> >>> Could we have a #define for that?
> >>
> >> Sure.
> =

> I've used the previous macro, so it looks like:
> =

> unmap(req, i) =3D UNMAP_SG_OFF;
> =

> I'm not sure if this is what you meant, or if you where interested in
> defining a set of macros like:
> =

> #define check_unmap(req, i) req->unmap_seg[i]
> #define unset_unmap(req, i) req->unmap_seg[i] =3D UNMAP_SG_OFF
> #define set_unmap(req, i) req->unmap_seg[i] =3D UNMAP_SG_ON
> =

> I would go for the first option (the unmap macro that can be used here
> and in xen_blkbk_unmap).

I was just thinking something as simple as

	if (reg->unmap_seg[i] =3D=3D UNMAP_SG_OFF)
		continue;

And the #defines are just for the hard-coded values of 0 or 1.

> =

> >>> HA! By default, eh?
> >>
> >> Yes, you caught me, there's a paragraph in the commit message that
> >> explains that we are using persistent grants in the frontend
> >> unconditionally, since the protocol is compatible (you can have a
> >> persistent blkfront and a non-persistent blkback). It simplifies the
> >> logic in blkfront. Are you OK with it?
> > =

> > It is OK, but you should be checking whether the backend supports it.
> > I don't see it checking the info->feature_persistent_grant to print
> > that.
> =

> I don't understand why blkfront needs to check if the backend supports
> persisten grants, blkfront is going to use persistent grants anyway.

What if it does not (say this guest runs on an older xen-blkback?)?
Then you would be still printing 'persistent grants' in the blkfront.
> =

> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> =


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 19:03:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 19:03:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQjkr-0008LB-1O; Tue, 23 Oct 2012 19:03:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQjkp-0008L4-QT
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 19:03:08 +0000
Received: from [85.158.139.83:46628] by server-16.bemta-5.messagelabs.com id
	EC/18-04786-BE9E6805; Tue, 23 Oct 2012 19:03:07 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1351018982!30556246!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24706 invoked from network); 23 Oct 2012 19:03:05 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 19:03:05 -0000
Received: by mail-vc0-f173.google.com with SMTP id fl15so192936vcb.32
	for ; Tue, 23 Oct 2012 12:03:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:content-transfer-encoding
	:in-reply-to:user-agent;
	bh=M0DAep7ey/50NI8mONtWNRCvIFYPKPoNTrPU4EC3jeI=;
	b=wSAGUIxNMVJn4VB9/vEA/QIT3YPflUutIi9gskLDL4jmLD6UfeT090Ma/aj5LGx7Te
	xwk4qcOX0HmQupAQ8MyWDGcuYB4WoUP7Y8Iu6s6ECRrTMBG/MOGiUmpKVUyOGqpeESlW
	Opq+56ZfSorkKGtKSPoGfglQZyztP3V9MXSRMIHFJW0gY6HrDAya9LeRo3CwhkuaoT8g
	dYEh7YClA6Cti+dQyai5+JcRZOA5W7332TGhnn7M1fQx2izpxZgLZA8TQWhvtJaJ9XNb
	nvEC9J97jGXw2ODUgNXQlPH4lzxitWtHU4yJYWP+hLkDDaagpcihbGPczRF9W/IY4Tj/
	aQWA==
Received: by 10.220.8.138 with SMTP id h10mr3890694vch.35.1351018981979;
	Tue, 23 Oct 2012 12:03:01 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id xf2sm13143919vec.12.2012.10.23.12.03.00
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 23 Oct 2012 12:03:01 -0700 (PDT)
Date: Tue, 23 Oct 2012 14:50:50 -0400
From: Konrad Rzeszutek Wilk 
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= 
Message-ID: <20121023185049.GB20350@phenom.dumpdata.com>
References: <1350559321-19066-1-git-send-email-roger.pau@citrix.com>
	<20121022134708.GA13832@konrad-lan.dumpdata.com>
	<5086C0C8.5000306@citrix.com>
	<20121023172008.GB11787@phenom.dumpdata.com>
	<5086DD57.4000206@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5086DD57.4000206@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xen.org" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH RFC] Persistent grant maps for xen blk
	drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 23, 2012 at 08:09:27PM +0200, Roger Pau Monn=E9 wrote:
> On 23/10/12 19:20, Konrad Rzeszutek Wilk wrote:
> >>>> diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen=
-blkback/blkback.c
> >>>> index c6decb9..2b982b2 100644
> >>>> --- a/drivers/block/xen-blkback/blkback.c
> >>>> +++ b/drivers/block/xen-blkback/blkback.c
> >>>> @@ -78,6 +78,7 @@ struct pending_req {
> >>>>       unsigned short          operation;
> >>>>       int                     status;
> >>>>       struct list_head        free_list;
> >>>> +     unsigned int            unmap_seg[BLKIF_MAX_SEGMENTS_PER_REQUE=
ST];
> =

> Should I change this to a bool? Since we are only setting it to 0 or 1.

I would just keep it as 'int'. Eventually we can replace this with a
bit-map, but that can be done later.

> =

> >>> Perhaps there should be a #define for that array..
> >>
> >> Do you mean something like:
> >>
> >> #define unmap(req, i) req->unmap_seg[i]
> > =

> > I was thinking that you just check for req->unamp_seg[i] to
> > have an non-zero value. But since that array is just used as an check
> > to see whether the functionality is enabled (or not), you might want
> > to declerare the right values so:
> > #define UNMAP_SG_ON 1
> > #define UNMAP_SG_OFF 0
> > =

> > or so.
> =

> Agreed, will add the defines.
> =

> >>>> +             if (persistent_gnts[i]) {
> >>>> +                     if (!persistent_gnts[i]->handle) {
> >>>> +                             /*
> >>>> +                              * If this is a new persistent grant
> >>>> +                              * save the handler
> >>>> +                              */
> >>>> +                             persistent_gnts[i]->handle =3D map[j].=
handle;
> >>>> +                             persistent_gnts[i]->dev_bus_addr =3D
> >>>> +                                     map[j++].dev_bus_addr;
> >>>> +                     }
> >>>> +                     pending_handle(pending_req, i) =3D
> >>>> +                             persistent_gnts[i]->handle;
> >>>> +                     pending_req->unmap_seg[i] =3D 0;
> >>>
> >>> Could we have a #define for that?
> >>
> >> Sure.
> =

> I've used the previous macro, so it looks like:
> =

> unmap(req, i) =3D UNMAP_SG_OFF;
> =

> I'm not sure if this is what you meant, or if you where interested in
> defining a set of macros like:
> =

> #define check_unmap(req, i) req->unmap_seg[i]
> #define unset_unmap(req, i) req->unmap_seg[i] =3D UNMAP_SG_OFF
> #define set_unmap(req, i) req->unmap_seg[i] =3D UNMAP_SG_ON
> =

> I would go for the first option (the unmap macro that can be used here
> and in xen_blkbk_unmap).

I was just thinking something as simple as

	if (reg->unmap_seg[i] =3D=3D UNMAP_SG_OFF)
		continue;

And the #defines are just for the hard-coded values of 0 or 1.

> =

> >>> HA! By default, eh?
> >>
> >> Yes, you caught me, there's a paragraph in the commit message that
> >> explains that we are using persistent grants in the frontend
> >> unconditionally, since the protocol is compatible (you can have a
> >> persistent blkfront and a non-persistent blkback). It simplifies the
> >> logic in blkfront. Are you OK with it?
> > =

> > It is OK, but you should be checking whether the backend supports it.
> > I don't see it checking the info->feature_persistent_grant to print
> > that.
> =

> I don't understand why blkfront needs to check if the backend supports
> persisten grants, blkfront is going to use persistent grants anyway.

What if it does not (say this guest runs on an older xen-blkback?)?
Then you would be still printing 'persistent grants' in the blkfront.
> =

> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> =


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 19:05:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 19:05:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQjn3-0008SV-NN; Tue, 23 Oct 2012 19:05:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQjn2-0008SP-R9
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 19:05:25 +0000
Received: from [85.158.139.211:54266] by server-10.bemta-5.messagelabs.com id
	EC/16-01025-47AE6805; Tue, 23 Oct 2012 19:05:24 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1351019120!23378361!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6930 invoked from network); 23 Oct 2012 19:05:22 -0000
Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com)
	(209.85.212.43)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 19:05:22 -0000
Received: by mail-vb0-f43.google.com with SMTP id fq11so5648075vbb.30
	for ;
	Tue, 23 Oct 2012 12:05:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=c9933k7TKLjbFStpyINHdXN2w5UxEDgBqbpoFb/QYIA=;
	b=gWCFNoqH89yXPUEZKK9ZCPtimZ8s4uDfErEthAOgp4y9LpHtQvOE4H4gsMM+JBR+7i
	3QPYg4ApMBYWVisFVxiX1LavTcpvLPCyc36FWSol/pk/uy9deA3tmCDWw5KnaayMzUir
	H6eELaCgWfFlLzMDesW1mtGE8bsFU+fUvbVSSW+U5KFGrVs+Q7yjRX5pZb9WUGjVschd
	rMNwpYHr/ss5QTpJ1WjZ31zUXU5XnLZb5qFzD2z59QOKF/LxpFus4q9arxu4eDJ25vip
	xgt9+a/PvWgsQJB2/6OMBOg1qlDXDjYMHSUlvTEyVLMq/LfsPexONXCT8CXnNWJKcdNv
	KSDw==
Received: by 10.52.37.196 with SMTP id a4mr18160434vdk.104.1351019120250;
	Tue, 23 Oct 2012 12:05:20 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id k4sm13922682vdg.2.2012.10.23.12.05.19
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 23 Oct 2012 12:05:19 -0700 (PDT)
Date: Tue, 23 Oct 2012 14:53:09 -0400
From: Konrad Rzeszutek Wilk 
To: Sander Eikelenboom 
Message-ID: <20121023185308.GC20350@phenom.dumpdata.com>
References: <20121023162707.GA16634@phenom.dumpdata.com>
	<468189240.20121023193753@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <468189240.20121023193753@eikelenboom.it>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xensource.com,
	Linus Torvalds ,
	linux-kernel@vger.kernel.org,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [GIT PULL] (xen) stable/for-linus-3.7-rc2-tag for
 v3.7-rc2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 23, 2012 at 07:37:53PM +0200, Sander Eikelenboom wrote:
> Hi Konrad,
> 
> Did you push the tag ?
> It doesn't seem to be in your git repo.

http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=tag;h=bfc3f7b8b971ce4969e637c3c0f8019a4bc20c85

looks to be there?
> 
> --
> Sander
> 
> Tuesday, October 23, 2012, 6:27:07 PM, you wrote:
> 
> > Hey Linus,
> 
> > Please git pull the following tag:
> 
> >  git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-linus-3.7-rc2-tag
> 
> > which has bug-fixes. Most of them are just code cleanup to make x86 and ARM code
> > work in unison. There is one serious bug-fix which manifested itself in some
> > applications mysteriously getting SIGKILL. Besides that nothing earth-shattering.
> 
> > :
> >  * Fix mysterious SIGSEGV or SIGKILL in applications due to corrupting
> >    of the %eip when returning from a signal handler.
> >  * Fix various ARM compile issues after the merge fallout.
> >  * Continue on making more of the Xen generic code usable by ARM platform.
> >  * Fix SR-IOV passthrough to mirror multifunction PCI devices.
> >  * Fix various compile warnings.
> >  * Remove hypercalls that don't exist anymore.
> > 
> 
> >  arch/arm/include/asm/xen/interface.h |   12 +++++++++---
> >  arch/arm/include/asm/xen/page.h      |   13 ++++++++++---
> >  arch/arm/xen/grant-table.c           |    2 +-
> >  arch/x86/include/asm/xen/interface.h |    4 ++--
> >  arch/x86/kernel/entry_32.S           |    8 +++++---
> >  arch/x86/kernel/entry_64.S           |    2 +-
> >  arch/x86/xen/enlighten.c             |    2 --
> >  drivers/xen/balloon.c                |    3 +--
> >  drivers/xen/dbgp.c                   |    2 ++
> >  drivers/xen/events.c                 |    4 ++++
> >  drivers/xen/grant-table.c            |    8 ++++----
> >  drivers/xen/sys-hypervisor.c         |    4 +++-
> >  drivers/xen/xen-pciback/vpci.c       |   14 ++++++++++----
> >  drivers/xen/xenbus/xenbus_xs.c       |    2 ++
> >  include/xen/grant_table.h            |    2 +-
> >  include/xen/interface/grant_table.h  |    2 +-
> >  include/xen/interface/memory.h       |   24 ++----------------------
> >  17 files changed, 58 insertions(+), 50 deletions(-)
> 
> > David Vrabel (1):
> >       xen/x86: don't corrupt %eip when returning from a signal handler
> 
> > Ian Campbell (11):
> >       xen: xenbus: quirk uses x86 specific cpuid
> >       xen: sysfs: include err.h for PTR_ERR etc
> >       xen: sysfs: fix build warning.
> >       xen: XENMEM_translate_gpfn_list was remove ages ago and is unused.
> >       xen: events: pirq_check_eoi_map is X86 specific
> >       xen: grant: use xen_pfn_t type for frame_list.
> >       xen: balloon: don't include e820.h
> >       xen: arm: make p2m operations NOPs
> >       xen: balloon: use correct type for frame_list
> >       xen: arm: comment on why 64-bit xen_pfn_t is safe even on 32 bit
> >       xen: dbgp: Fix warning when CONFIG_PCI is not enabled.
> 
> > Konrad Rzeszutek Wilk (1):
> >       xen/xenbus: Fix compile warning.
> 
> > Laszlo Ersek (1):
> >       xen PV passthru: assign SR-IOV virtual functions to separate virtual slots
> 
> > Wei Yongjun (1):
> >       xen/x86: remove duplicated include from enlighten.c
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 19:05:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 19:05:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQjn3-0008SV-NN; Tue, 23 Oct 2012 19:05:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQjn2-0008SP-R9
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 19:05:25 +0000
Received: from [85.158.139.211:54266] by server-10.bemta-5.messagelabs.com id
	EC/16-01025-47AE6805; Tue, 23 Oct 2012 19:05:24 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1351019120!23378361!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6930 invoked from network); 23 Oct 2012 19:05:22 -0000
Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com)
	(209.85.212.43)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 19:05:22 -0000
Received: by mail-vb0-f43.google.com with SMTP id fq11so5648075vbb.30
	for ;
	Tue, 23 Oct 2012 12:05:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=c9933k7TKLjbFStpyINHdXN2w5UxEDgBqbpoFb/QYIA=;
	b=gWCFNoqH89yXPUEZKK9ZCPtimZ8s4uDfErEthAOgp4y9LpHtQvOE4H4gsMM+JBR+7i
	3QPYg4ApMBYWVisFVxiX1LavTcpvLPCyc36FWSol/pk/uy9deA3tmCDWw5KnaayMzUir
	H6eELaCgWfFlLzMDesW1mtGE8bsFU+fUvbVSSW+U5KFGrVs+Q7yjRX5pZb9WUGjVschd
	rMNwpYHr/ss5QTpJ1WjZ31zUXU5XnLZb5qFzD2z59QOKF/LxpFus4q9arxu4eDJ25vip
	xgt9+a/PvWgsQJB2/6OMBOg1qlDXDjYMHSUlvTEyVLMq/LfsPexONXCT8CXnNWJKcdNv
	KSDw==
Received: by 10.52.37.196 with SMTP id a4mr18160434vdk.104.1351019120250;
	Tue, 23 Oct 2012 12:05:20 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id k4sm13922682vdg.2.2012.10.23.12.05.19
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 23 Oct 2012 12:05:19 -0700 (PDT)
Date: Tue, 23 Oct 2012 14:53:09 -0400
From: Konrad Rzeszutek Wilk 
To: Sander Eikelenboom 
Message-ID: <20121023185308.GC20350@phenom.dumpdata.com>
References: <20121023162707.GA16634@phenom.dumpdata.com>
	<468189240.20121023193753@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <468189240.20121023193753@eikelenboom.it>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xensource.com,
	Linus Torvalds ,
	linux-kernel@vger.kernel.org,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [GIT PULL] (xen) stable/for-linus-3.7-rc2-tag for
 v3.7-rc2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 23, 2012 at 07:37:53PM +0200, Sander Eikelenboom wrote:
> Hi Konrad,
> 
> Did you push the tag ?
> It doesn't seem to be in your git repo.

http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=tag;h=bfc3f7b8b971ce4969e637c3c0f8019a4bc20c85

looks to be there?
> 
> --
> Sander
> 
> Tuesday, October 23, 2012, 6:27:07 PM, you wrote:
> 
> > Hey Linus,
> 
> > Please git pull the following tag:
> 
> >  git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-linus-3.7-rc2-tag
> 
> > which has bug-fixes. Most of them are just code cleanup to make x86 and ARM code
> > work in unison. There is one serious bug-fix which manifested itself in some
> > applications mysteriously getting SIGKILL. Besides that nothing earth-shattering.
> 
> > :
> >  * Fix mysterious SIGSEGV or SIGKILL in applications due to corrupting
> >    of the %eip when returning from a signal handler.
> >  * Fix various ARM compile issues after the merge fallout.
> >  * Continue on making more of the Xen generic code usable by ARM platform.
> >  * Fix SR-IOV passthrough to mirror multifunction PCI devices.
> >  * Fix various compile warnings.
> >  * Remove hypercalls that don't exist anymore.
> > 
> 
> >  arch/arm/include/asm/xen/interface.h |   12 +++++++++---
> >  arch/arm/include/asm/xen/page.h      |   13 ++++++++++---
> >  arch/arm/xen/grant-table.c           |    2 +-
> >  arch/x86/include/asm/xen/interface.h |    4 ++--
> >  arch/x86/kernel/entry_32.S           |    8 +++++---
> >  arch/x86/kernel/entry_64.S           |    2 +-
> >  arch/x86/xen/enlighten.c             |    2 --
> >  drivers/xen/balloon.c                |    3 +--
> >  drivers/xen/dbgp.c                   |    2 ++
> >  drivers/xen/events.c                 |    4 ++++
> >  drivers/xen/grant-table.c            |    8 ++++----
> >  drivers/xen/sys-hypervisor.c         |    4 +++-
> >  drivers/xen/xen-pciback/vpci.c       |   14 ++++++++++----
> >  drivers/xen/xenbus/xenbus_xs.c       |    2 ++
> >  include/xen/grant_table.h            |    2 +-
> >  include/xen/interface/grant_table.h  |    2 +-
> >  include/xen/interface/memory.h       |   24 ++----------------------
> >  17 files changed, 58 insertions(+), 50 deletions(-)
> 
> > David Vrabel (1):
> >       xen/x86: don't corrupt %eip when returning from a signal handler
> 
> > Ian Campbell (11):
> >       xen: xenbus: quirk uses x86 specific cpuid
> >       xen: sysfs: include err.h for PTR_ERR etc
> >       xen: sysfs: fix build warning.
> >       xen: XENMEM_translate_gpfn_list was remove ages ago and is unused.
> >       xen: events: pirq_check_eoi_map is X86 specific
> >       xen: grant: use xen_pfn_t type for frame_list.
> >       xen: balloon: don't include e820.h
> >       xen: arm: make p2m operations NOPs
> >       xen: balloon: use correct type for frame_list
> >       xen: arm: comment on why 64-bit xen_pfn_t is safe even on 32 bit
> >       xen: dbgp: Fix warning when CONFIG_PCI is not enabled.
> 
> > Konrad Rzeszutek Wilk (1):
> >       xen/xenbus: Fix compile warning.
> 
> > Laszlo Ersek (1):
> >       xen PV passthru: assign SR-IOV virtual functions to separate virtual slots
> 
> > Wei Yongjun (1):
> >       xen/x86: remove duplicated include from enlighten.c
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 19:05:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 19:05:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQjnL-0008U2-4e; Tue, 23 Oct 2012 19:05:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQjnJ-0008TV-JR
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 19:05:41 +0000
Received: from [85.158.143.99:30577] by server-3.bemta-4.messagelabs.com id
	88/46-03544-38AE6805; Tue, 23 Oct 2012 19:05:39 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-15.tower-216.messagelabs.com!1351019138!35230904!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9355 invoked from network); 23 Oct 2012 19:05:38 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-15.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	23 Oct 2012 19:05:38 -0000
Received: from 255-64-ftth.onsneteindhoven.nl ([88.159.64.255]:56523
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TQjpB-0003do-0i; Tue, 23 Oct 2012 21:07:37 +0200
Date: Tue, 23 Oct 2012 21:05:34 +0200
From: Sander Eikelenboom 
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1216253974.20121023210534@eikelenboom.it>
To: Sander Eikelenboom 
In-Reply-To: <468189240.20121023193753@eikelenboom.it>
References: <20121023162707.GA16634@phenom.dumpdata.com>
	<468189240.20121023193753@eikelenboom.it>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com,
	Linus Torvalds ,
	linux-kernel@vger.kernel.org,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [GIT PULL] (xen) stable/for-linus-3.7-rc2-tag for
	v3.7-rc2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Tuesday, October 23, 2012, 7:37:53 PM, you wrote:

> Hi Konrad,

> Did you push the tag ?
> It doesn't seem to be in your git repo.

Ah nevermind, it's there now. Sorry for the noise.


> --
> Sander

> Tuesday, October 23, 2012, 6:27:07 PM, you wrote:

>> Hey Linus,

>> Please git pull the following tag:

>>  git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-linus-3.7-rc2-tag

>> which has bug-fixes. Most of them are just code cleanup to make x86 and ARM code
>> work in unison. There is one serious bug-fix which manifested itself in some
>> applications mysteriously getting SIGKILL. Besides that nothing earth-shattering.

>> :
>>  * Fix mysterious SIGSEGV or SIGKILL in applications due to corrupting
>>    of the %eip when returning from a signal handler.
>>  * Fix various ARM compile issues after the merge fallout.
>>  * Continue on making more of the Xen generic code usable by ARM platform.
>>  * Fix SR-IOV passthrough to mirror multifunction PCI devices.
>>  * Fix various compile warnings.
>>  * Remove hypercalls that don't exist anymore.
>> 

>>  arch/arm/include/asm/xen/interface.h |   12 +++++++++---
>>  arch/arm/include/asm/xen/page.h      |   13 ++++++++++---
>>  arch/arm/xen/grant-table.c           |    2 +-
>>  arch/x86/include/asm/xen/interface.h |    4 ++--
>>  arch/x86/kernel/entry_32.S           |    8 +++++---
>>  arch/x86/kernel/entry_64.S           |    2 +-
>>  arch/x86/xen/enlighten.c             |    2 --
>>  drivers/xen/balloon.c                |    3 +--
>>  drivers/xen/dbgp.c                   |    2 ++
>>  drivers/xen/events.c                 |    4 ++++
>>  drivers/xen/grant-table.c            |    8 ++++----
>>  drivers/xen/sys-hypervisor.c         |    4 +++-
>>  drivers/xen/xen-pciback/vpci.c       |   14 ++++++++++----
>>  drivers/xen/xenbus/xenbus_xs.c       |    2 ++
>>  include/xen/grant_table.h            |    2 +-
>>  include/xen/interface/grant_table.h  |    2 +-
>>  include/xen/interface/memory.h       |   24 ++----------------------
>>  17 files changed, 58 insertions(+), 50 deletions(-)

>> David Vrabel (1):
>>       xen/x86: don't corrupt %eip when returning from a signal handler

>> Ian Campbell (11):
>>       xen: xenbus: quirk uses x86 specific cpuid
>>       xen: sysfs: include err.h for PTR_ERR etc
>>       xen: sysfs: fix build warning.
>>       xen: XENMEM_translate_gpfn_list was remove ages ago and is unused.
>>       xen: events: pirq_check_eoi_map is X86 specific
>>       xen: grant: use xen_pfn_t type for frame_list.
>>       xen: balloon: don't include e820.h
>>       xen: arm: make p2m operations NOPs
>>       xen: balloon: use correct type for frame_list
>>       xen: arm: comment on why 64-bit xen_pfn_t is safe even on 32 bit
>>       xen: dbgp: Fix warning when CONFIG_PCI is not enabled.

>> Konrad Rzeszutek Wilk (1):
>>       xen/xenbus: Fix compile warning.

>> Laszlo Ersek (1):
>>       xen PV passthru: assign SR-IOV virtual functions to separate virtual slots

>> Wei Yongjun (1):
>>       xen/x86: remove duplicated include from enlighten.c






_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 19:05:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 19:05:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQjnL-0008U2-4e; Tue, 23 Oct 2012 19:05:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQjnJ-0008TV-JR
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 19:05:41 +0000
Received: from [85.158.143.99:30577] by server-3.bemta-4.messagelabs.com id
	88/46-03544-38AE6805; Tue, 23 Oct 2012 19:05:39 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-15.tower-216.messagelabs.com!1351019138!35230904!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9355 invoked from network); 23 Oct 2012 19:05:38 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-15.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	23 Oct 2012 19:05:38 -0000
Received: from 255-64-ftth.onsneteindhoven.nl ([88.159.64.255]:56523
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TQjpB-0003do-0i; Tue, 23 Oct 2012 21:07:37 +0200
Date: Tue, 23 Oct 2012 21:05:34 +0200
From: Sander Eikelenboom 
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1216253974.20121023210534@eikelenboom.it>
To: Sander Eikelenboom 
In-Reply-To: <468189240.20121023193753@eikelenboom.it>
References: <20121023162707.GA16634@phenom.dumpdata.com>
	<468189240.20121023193753@eikelenboom.it>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com,
	Linus Torvalds ,
	linux-kernel@vger.kernel.org,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [GIT PULL] (xen) stable/for-linus-3.7-rc2-tag for
	v3.7-rc2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Tuesday, October 23, 2012, 7:37:53 PM, you wrote:

> Hi Konrad,

> Did you push the tag ?
> It doesn't seem to be in your git repo.

Ah nevermind, it's there now. Sorry for the noise.


> --
> Sander

> Tuesday, October 23, 2012, 6:27:07 PM, you wrote:

>> Hey Linus,

>> Please git pull the following tag:

>>  git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-linus-3.7-rc2-tag

>> which has bug-fixes. Most of them are just code cleanup to make x86 and ARM code
>> work in unison. There is one serious bug-fix which manifested itself in some
>> applications mysteriously getting SIGKILL. Besides that nothing earth-shattering.

>> :
>>  * Fix mysterious SIGSEGV or SIGKILL in applications due to corrupting
>>    of the %eip when returning from a signal handler.
>>  * Fix various ARM compile issues after the merge fallout.
>>  * Continue on making more of the Xen generic code usable by ARM platform.
>>  * Fix SR-IOV passthrough to mirror multifunction PCI devices.
>>  * Fix various compile warnings.
>>  * Remove hypercalls that don't exist anymore.
>> 

>>  arch/arm/include/asm/xen/interface.h |   12 +++++++++---
>>  arch/arm/include/asm/xen/page.h      |   13 ++++++++++---
>>  arch/arm/xen/grant-table.c           |    2 +-
>>  arch/x86/include/asm/xen/interface.h |    4 ++--
>>  arch/x86/kernel/entry_32.S           |    8 +++++---
>>  arch/x86/kernel/entry_64.S           |    2 +-
>>  arch/x86/xen/enlighten.c             |    2 --
>>  drivers/xen/balloon.c                |    3 +--
>>  drivers/xen/dbgp.c                   |    2 ++
>>  drivers/xen/events.c                 |    4 ++++
>>  drivers/xen/grant-table.c            |    8 ++++----
>>  drivers/xen/sys-hypervisor.c         |    4 +++-
>>  drivers/xen/xen-pciback/vpci.c       |   14 ++++++++++----
>>  drivers/xen/xenbus/xenbus_xs.c       |    2 ++
>>  include/xen/grant_table.h            |    2 +-
>>  include/xen/interface/grant_table.h  |    2 +-
>>  include/xen/interface/memory.h       |   24 ++----------------------
>>  17 files changed, 58 insertions(+), 50 deletions(-)

>> David Vrabel (1):
>>       xen/x86: don't corrupt %eip when returning from a signal handler

>> Ian Campbell (11):
>>       xen: xenbus: quirk uses x86 specific cpuid
>>       xen: sysfs: include err.h for PTR_ERR etc
>>       xen: sysfs: fix build warning.
>>       xen: XENMEM_translate_gpfn_list was remove ages ago and is unused.
>>       xen: events: pirq_check_eoi_map is X86 specific
>>       xen: grant: use xen_pfn_t type for frame_list.
>>       xen: balloon: don't include e820.h
>>       xen: arm: make p2m operations NOPs
>>       xen: balloon: use correct type for frame_list
>>       xen: arm: comment on why 64-bit xen_pfn_t is safe even on 32 bit
>>       xen: dbgp: Fix warning when CONFIG_PCI is not enabled.

>> Konrad Rzeszutek Wilk (1):
>>       xen/xenbus: Fix compile warning.

>> Laszlo Ersek (1):
>>       xen PV passthru: assign SR-IOV virtual functions to separate virtual slots

>> Wei Yongjun (1):
>>       xen/x86: remove duplicated include from enlighten.c






_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 19:50:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 19:50:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQkTr-0000ZQ-Pc; Tue, 23 Oct 2012 19:49:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQkTq-0000ZL-5u
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 19:49:38 +0000
Received: from [85.158.143.35:64412] by server-1.bemta-4.messagelabs.com id
	37/88-19134-1D4F6805; Tue, 23 Oct 2012 19:49:37 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-21.messagelabs.com!1351021776!15240432!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDE3MzY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDE3MzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 565 invoked from network); 23 Oct 2012 19:49:36 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Oct 2012 19:49:36 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0M7jF20=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-069-085.pools.arcor-ip.net [84.57.69.85])
	by smtp.strato.de (jorabe mo6) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id z0575fo9NIAZ2A ;
	Tue, 23 Oct 2012 21:49:34 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 2EAFF18642; Tue, 23 Oct 2012 21:49:29 +0200 (CEST)
Date: Tue, 23 Oct 2012 21:49:29 +0200
From: Olaf Hering 
To: Konrad Rzeszutek Wilk 
Message-ID: <20121023194928.GA24083@aepfle.de>
References: <20120828124255.GA32452@aepfle.de>
	
	<20120831234222.GA22460@localhost.localdomain>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120831234222.GA22460@localhost.localdomain>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: Keir Fraser , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] fixed location of share info page in HVM guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Aug 31, Konrad Rzeszutek Wilk wrote:

> On Tue, Aug 28, 2012 at 02:35:19PM +0100, Keir Fraser wrote:
> > On 28/08/2012 13:42, "Olaf Hering"  wrote:
> > 
> > > On Tue, Aug 28, Keir Fraser wrote:
> > > 
> > >> Okay, that was a bit too clever, trying to hide between IOAPIC and LAPIC
> > >> pages. How about a bit lower in memory -- FE700000-FE7FFFFF?
> > >> 
> > >> Everything in range FC000000-FFFFFFFF should already be marked
> > >> E820_RESERVED. You can test that, and also see
> > >> tools/firmware/hvmloader/e820.c:build_e820_table() (and note that
> > >> RESERVED_MEMBASE == FC000000).
> > > 
> > > Yes, FC000000-FFFFFFFF has already an E820_RESERVED entry. Within that
> > > range the kernel finds the IOAPIC, LAPIC and the HPET, perhaps because
> > > they are listed in the ACPI table or because they are found by other
> > > ways.
> > 
> > Yes they are all listed in various ACPI tables.
> > 
> > > To make the location of the of the shared pages configurable from the
> > > tools, does tools/firmware/hvmloader/acpi/dsdt.asl have a way to
> > > describe such special region? Maybe the kernel parses that table early
> 
> Isn't there also a magic string of said structure? If so we should also
> check for the magic string to make sure we are mapping the proper
> "thing." It can be done similary to how iBFT or EBDA is found.

I will have a look if ACPI can be used that early, for the time being a
hardcoded address is used. This is the proposed kernel change, against
3.7-rc2. The open question is when to switch from early_ioremap to
ioremap. Then the change to drivers/xen/platform-pci.c can be removed.

Olaf

 xen PVonHVM: move shared_info to reserved memory area

---
 arch/x86/include/asm/xen/hypervisor.h |  2 ++
 arch/x86/xen/enlighten.c              | 53 ++++++++++++++++++++++++++---------
 arch/x86/xen/suspend.c                |  2 +-
 arch/x86/xen/xen-ops.h                |  2 +-
 drivers/xen/platform-pci.c            |  2 ++
 include/xen/events.h                  |  2 ++
 6 files changed, 48 insertions(+), 15 deletions(-)

diff --git a/arch/x86/include/asm/xen/hypervisor.h b/arch/x86/include/asm/xen/hypervisor.h
index 66d0fff..e29a02b 100644
--- a/arch/x86/include/asm/xen/hypervisor.h
+++ b/arch/x86/include/asm/xen/hypervisor.h
@@ -34,6 +34,8 @@
 #define _ASM_X86_XEN_HYPERVISOR_H
 
 /* arch/i386/kernel/setup.c */
+#define HVM_SHARED_INFO_ADDR 0xFE700000UL
+
 extern struct shared_info *HYPERVISOR_shared_info;
 extern struct start_info *xen_start_info;
 
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index e3497f2..b051c3f 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -103,7 +103,6 @@ struct shared_info xen_dummy_shared_info;
 
 void *xen_initial_gdt;
 
-RESERVE_BRK(shared_info_page_brk, PAGE_SIZE);
 __read_mostly int xen_have_vector_callback;
 EXPORT_SYMBOL_GPL(xen_have_vector_callback);
 
@@ -1497,38 +1496,66 @@ asmlinkage void __init xen_start_kernel(void)
 #endif
 }
 
-void __ref xen_hvm_init_shared_info(void)
+#ifdef CONFIG_XEN_PVHVM
+static struct shared_info *xen_hvm_shared_info;
+
+static void xen_hvm_connect_shared_info(unsigned long pfn)
 {
-	int cpu;
 	struct xen_add_to_physmap xatp;
-	static struct shared_info *shared_info_page = 0;
 
-	if (!shared_info_page)
-		shared_info_page = (struct shared_info *)
-			extend_brk(PAGE_SIZE, PAGE_SIZE);
 	xatp.domid = DOMID_SELF;
 	xatp.idx = 0;
 	xatp.space = XENMAPSPACE_shared_info;
-	xatp.gpfn = __pa(shared_info_page) >> PAGE_SHIFT;
+	xatp.gpfn = pfn;
 	if (HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp))
 		BUG();
 
-	HYPERVISOR_shared_info = (struct shared_info *)shared_info_page;
+}
+static void xen_hvm_set_shared_info(struct shared_info *sip)
+{
+	int cpu;
+
+	HYPERVISOR_shared_info = sip;
 
 	/* xen_vcpu is a pointer to the vcpu_info struct in the shared_info
 	 * page, we use it in the event channel upcall and in some pvclock
 	 * related functions. We don't need the vcpu_info placement
 	 * optimizations because we don't use any pv_mmu or pv_irq op on
 	 * HVM.
-	 * When xen_hvm_init_shared_info is run at boot time only vcpu 0 is
-	 * online but xen_hvm_init_shared_info is run at resume time too and
+	 * When xen_hvm_set_shared_info is run at boot time only vcpu 0 is
+	 * online but xen_hvm_set_shared_info is run at resume time too and
 	 * in that case multiple vcpus might be online. */
 	for_each_online_cpu(cpu) {
 		per_cpu(xen_vcpu, cpu) = &HYPERVISOR_shared_info->vcpu_info[cpu];
 	}
 }
 
-#ifdef CONFIG_XEN_PVHVM
+/* Reconnect the shared_info pfn to a (new) mfn */
+void xen_hvm_resume_shared_info(void)
+{
+	xen_hvm_connect_shared_info(HVM_SHARED_INFO_ADDR >> PAGE_SHIFT);
+}
+
+/* Update shared_info address */
+void __devinit xen_hvm_init_shared_info(void)
+{
+	struct shared_info *early;
+
+	early = xen_hvm_shared_info;
+	xen_hvm_shared_info = ioremap(HVM_SHARED_INFO_ADDR, PAGE_SIZE);
+	xen_hvm_set_shared_info(xen_hvm_shared_info);
+	wmb();
+	early_iounmap(early, PAGE_SIZE);
+}
+
+/* Obtain an address to the pfn in reserved area */
+static void __init xen_hvm_early_init_shared_info(void)
+{
+	xen_hvm_shared_info = early_ioremap(HVM_SHARED_INFO_ADDR, PAGE_SIZE);
+	xen_hvm_connect_shared_info(HVM_SHARED_INFO_ADDR >> PAGE_SHIFT);
+	xen_hvm_set_shared_info(xen_hvm_shared_info);
+}
+
 static void __init init_hvm_pv_info(void)
 {
 	int major, minor;
@@ -1578,7 +1605,7 @@ static void __init xen_hvm_guest_init(void)
 {
 	init_hvm_pv_info();
 
-	xen_hvm_init_shared_info();
+	xen_hvm_early_init_shared_info();
 
 	if (xen_feature(XENFEAT_hvm_callback_vector))
 		xen_have_vector_callback = 1;
diff --git a/arch/x86/xen/suspend.c b/arch/x86/xen/suspend.c
index 45329c8..ae8a00c 100644
--- a/arch/x86/xen/suspend.c
+++ b/arch/x86/xen/suspend.c
@@ -30,7 +30,7 @@ void xen_arch_hvm_post_suspend(int suspend_cancelled)
 {
 #ifdef CONFIG_XEN_PVHVM
 	int cpu;
-	xen_hvm_init_shared_info();
+	xen_hvm_resume_shared_info();
 	xen_callback_vector();
 	xen_unplug_emulated_devices();
 	if (xen_feature(XENFEAT_hvm_safe_pvclock)) {
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index a95b417..d2e73d1 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -40,7 +40,7 @@ void xen_enable_syscall(void);
 void xen_vcpu_restore(void);
 
 void xen_callback_vector(void);
-void xen_hvm_init_shared_info(void);
+void xen_hvm_resume_shared_info(void);
 void xen_unplug_emulated_devices(void);
 
 void __init xen_build_dynamic_phys_to_machine(void);
diff --git a/drivers/xen/platform-pci.c b/drivers/xen/platform-pci.c
index 97ca359..989365f 100644
--- a/drivers/xen/platform-pci.c
+++ b/drivers/xen/platform-pci.c
@@ -138,6 +138,8 @@ static int __devinit platform_pci_init(struct pci_dev *pdev,
 	platform_mmio = mmio_addr;
 	platform_mmiolen = mmio_len;
 
+	xen_hvm_init_shared_info();
+
 	if (!xen_have_vector_callback) {
 		ret = xen_allocate_irq(pdev);
 		if (ret) {
diff --git a/include/xen/events.h b/include/xen/events.h
index c6bfe01..58c8431 100644
--- a/include/xen/events.h
+++ b/include/xen/events.h
@@ -58,6 +58,8 @@ void notify_remote_via_irq(int irq);
 
 void xen_irq_resume(void);
 
+void xen_hvm_init_shared_info(void);
+
 /* Clear an irq's pending state, in preparation for polling on it */
 void xen_clear_irq_pending(int irq);
 void xen_set_irq_pending(int irq);
-- 
1.7.12.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 19:50:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 19:50:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQkTr-0000ZQ-Pc; Tue, 23 Oct 2012 19:49:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQkTq-0000ZL-5u
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 19:49:38 +0000
Received: from [85.158.143.35:64412] by server-1.bemta-4.messagelabs.com id
	37/88-19134-1D4F6805; Tue, 23 Oct 2012 19:49:37 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-21.messagelabs.com!1351021776!15240432!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDE3MzY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDE3MzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 565 invoked from network); 23 Oct 2012 19:49:36 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Oct 2012 19:49:36 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0M7jF20=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-069-085.pools.arcor-ip.net [84.57.69.85])
	by smtp.strato.de (jorabe mo6) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id z0575fo9NIAZ2A ;
	Tue, 23 Oct 2012 21:49:34 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 2EAFF18642; Tue, 23 Oct 2012 21:49:29 +0200 (CEST)
Date: Tue, 23 Oct 2012 21:49:29 +0200
From: Olaf Hering 
To: Konrad Rzeszutek Wilk 
Message-ID: <20121023194928.GA24083@aepfle.de>
References: <20120828124255.GA32452@aepfle.de>
	
	<20120831234222.GA22460@localhost.localdomain>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120831234222.GA22460@localhost.localdomain>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: Keir Fraser , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] fixed location of share info page in HVM guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Aug 31, Konrad Rzeszutek Wilk wrote:

> On Tue, Aug 28, 2012 at 02:35:19PM +0100, Keir Fraser wrote:
> > On 28/08/2012 13:42, "Olaf Hering"  wrote:
> > 
> > > On Tue, Aug 28, Keir Fraser wrote:
> > > 
> > >> Okay, that was a bit too clever, trying to hide between IOAPIC and LAPIC
> > >> pages. How about a bit lower in memory -- FE700000-FE7FFFFF?
> > >> 
> > >> Everything in range FC000000-FFFFFFFF should already be marked
> > >> E820_RESERVED. You can test that, and also see
> > >> tools/firmware/hvmloader/e820.c:build_e820_table() (and note that
> > >> RESERVED_MEMBASE == FC000000).
> > > 
> > > Yes, FC000000-FFFFFFFF has already an E820_RESERVED entry. Within that
> > > range the kernel finds the IOAPIC, LAPIC and the HPET, perhaps because
> > > they are listed in the ACPI table or because they are found by other
> > > ways.
> > 
> > Yes they are all listed in various ACPI tables.
> > 
> > > To make the location of the of the shared pages configurable from the
> > > tools, does tools/firmware/hvmloader/acpi/dsdt.asl have a way to
> > > describe such special region? Maybe the kernel parses that table early
> 
> Isn't there also a magic string of said structure? If so we should also
> check for the magic string to make sure we are mapping the proper
> "thing." It can be done similary to how iBFT or EBDA is found.

I will have a look if ACPI can be used that early, for the time being a
hardcoded address is used. This is the proposed kernel change, against
3.7-rc2. The open question is when to switch from early_ioremap to
ioremap. Then the change to drivers/xen/platform-pci.c can be removed.

Olaf

 xen PVonHVM: move shared_info to reserved memory area

---
 arch/x86/include/asm/xen/hypervisor.h |  2 ++
 arch/x86/xen/enlighten.c              | 53 ++++++++++++++++++++++++++---------
 arch/x86/xen/suspend.c                |  2 +-
 arch/x86/xen/xen-ops.h                |  2 +-
 drivers/xen/platform-pci.c            |  2 ++
 include/xen/events.h                  |  2 ++
 6 files changed, 48 insertions(+), 15 deletions(-)

diff --git a/arch/x86/include/asm/xen/hypervisor.h b/arch/x86/include/asm/xen/hypervisor.h
index 66d0fff..e29a02b 100644
--- a/arch/x86/include/asm/xen/hypervisor.h
+++ b/arch/x86/include/asm/xen/hypervisor.h
@@ -34,6 +34,8 @@
 #define _ASM_X86_XEN_HYPERVISOR_H
 
 /* arch/i386/kernel/setup.c */
+#define HVM_SHARED_INFO_ADDR 0xFE700000UL
+
 extern struct shared_info *HYPERVISOR_shared_info;
 extern struct start_info *xen_start_info;
 
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index e3497f2..b051c3f 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -103,7 +103,6 @@ struct shared_info xen_dummy_shared_info;
 
 void *xen_initial_gdt;
 
-RESERVE_BRK(shared_info_page_brk, PAGE_SIZE);
 __read_mostly int xen_have_vector_callback;
 EXPORT_SYMBOL_GPL(xen_have_vector_callback);
 
@@ -1497,38 +1496,66 @@ asmlinkage void __init xen_start_kernel(void)
 #endif
 }
 
-void __ref xen_hvm_init_shared_info(void)
+#ifdef CONFIG_XEN_PVHVM
+static struct shared_info *xen_hvm_shared_info;
+
+static void xen_hvm_connect_shared_info(unsigned long pfn)
 {
-	int cpu;
 	struct xen_add_to_physmap xatp;
-	static struct shared_info *shared_info_page = 0;
 
-	if (!shared_info_page)
-		shared_info_page = (struct shared_info *)
-			extend_brk(PAGE_SIZE, PAGE_SIZE);
 	xatp.domid = DOMID_SELF;
 	xatp.idx = 0;
 	xatp.space = XENMAPSPACE_shared_info;
-	xatp.gpfn = __pa(shared_info_page) >> PAGE_SHIFT;
+	xatp.gpfn = pfn;
 	if (HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp))
 		BUG();
 
-	HYPERVISOR_shared_info = (struct shared_info *)shared_info_page;
+}
+static void xen_hvm_set_shared_info(struct shared_info *sip)
+{
+	int cpu;
+
+	HYPERVISOR_shared_info = sip;
 
 	/* xen_vcpu is a pointer to the vcpu_info struct in the shared_info
 	 * page, we use it in the event channel upcall and in some pvclock
 	 * related functions. We don't need the vcpu_info placement
 	 * optimizations because we don't use any pv_mmu or pv_irq op on
 	 * HVM.
-	 * When xen_hvm_init_shared_info is run at boot time only vcpu 0 is
-	 * online but xen_hvm_init_shared_info is run at resume time too and
+	 * When xen_hvm_set_shared_info is run at boot time only vcpu 0 is
+	 * online but xen_hvm_set_shared_info is run at resume time too and
 	 * in that case multiple vcpus might be online. */
 	for_each_online_cpu(cpu) {
 		per_cpu(xen_vcpu, cpu) = &HYPERVISOR_shared_info->vcpu_info[cpu];
 	}
 }
 
-#ifdef CONFIG_XEN_PVHVM
+/* Reconnect the shared_info pfn to a (new) mfn */
+void xen_hvm_resume_shared_info(void)
+{
+	xen_hvm_connect_shared_info(HVM_SHARED_INFO_ADDR >> PAGE_SHIFT);
+}
+
+/* Update shared_info address */
+void __devinit xen_hvm_init_shared_info(void)
+{
+	struct shared_info *early;
+
+	early = xen_hvm_shared_info;
+	xen_hvm_shared_info = ioremap(HVM_SHARED_INFO_ADDR, PAGE_SIZE);
+	xen_hvm_set_shared_info(xen_hvm_shared_info);
+	wmb();
+	early_iounmap(early, PAGE_SIZE);
+}
+
+/* Obtain an address to the pfn in reserved area */
+static void __init xen_hvm_early_init_shared_info(void)
+{
+	xen_hvm_shared_info = early_ioremap(HVM_SHARED_INFO_ADDR, PAGE_SIZE);
+	xen_hvm_connect_shared_info(HVM_SHARED_INFO_ADDR >> PAGE_SHIFT);
+	xen_hvm_set_shared_info(xen_hvm_shared_info);
+}
+
 static void __init init_hvm_pv_info(void)
 {
 	int major, minor;
@@ -1578,7 +1605,7 @@ static void __init xen_hvm_guest_init(void)
 {
 	init_hvm_pv_info();
 
-	xen_hvm_init_shared_info();
+	xen_hvm_early_init_shared_info();
 
 	if (xen_feature(XENFEAT_hvm_callback_vector))
 		xen_have_vector_callback = 1;
diff --git a/arch/x86/xen/suspend.c b/arch/x86/xen/suspend.c
index 45329c8..ae8a00c 100644
--- a/arch/x86/xen/suspend.c
+++ b/arch/x86/xen/suspend.c
@@ -30,7 +30,7 @@ void xen_arch_hvm_post_suspend(int suspend_cancelled)
 {
 #ifdef CONFIG_XEN_PVHVM
 	int cpu;
-	xen_hvm_init_shared_info();
+	xen_hvm_resume_shared_info();
 	xen_callback_vector();
 	xen_unplug_emulated_devices();
 	if (xen_feature(XENFEAT_hvm_safe_pvclock)) {
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index a95b417..d2e73d1 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -40,7 +40,7 @@ void xen_enable_syscall(void);
 void xen_vcpu_restore(void);
 
 void xen_callback_vector(void);
-void xen_hvm_init_shared_info(void);
+void xen_hvm_resume_shared_info(void);
 void xen_unplug_emulated_devices(void);
 
 void __init xen_build_dynamic_phys_to_machine(void);
diff --git a/drivers/xen/platform-pci.c b/drivers/xen/platform-pci.c
index 97ca359..989365f 100644
--- a/drivers/xen/platform-pci.c
+++ b/drivers/xen/platform-pci.c
@@ -138,6 +138,8 @@ static int __devinit platform_pci_init(struct pci_dev *pdev,
 	platform_mmio = mmio_addr;
 	platform_mmiolen = mmio_len;
 
+	xen_hvm_init_shared_info();
+
 	if (!xen_have_vector_callback) {
 		ret = xen_allocate_irq(pdev);
 		if (ret) {
diff --git a/include/xen/events.h b/include/xen/events.h
index c6bfe01..58c8431 100644
--- a/include/xen/events.h
+++ b/include/xen/events.h
@@ -58,6 +58,8 @@ void notify_remote_via_irq(int irq);
 
 void xen_irq_resume(void);
 
+void xen_hvm_init_shared_info(void);
+
 /* Clear an irq's pending state, in preparation for polling on it */
 void xen_clear_irq_pending(int irq);
 void xen_set_irq_pending(int irq);
-- 
1.7.12.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 20:28:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 20:28:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQl51-0000ta-AD; Tue, 23 Oct 2012 20:28:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQl4z-0000tV-4V
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 20:28:01 +0000
Received: from [85.158.143.35:14928] by server-3.bemta-4.messagelabs.com id
	5C/3B-24279-0DDF6805; Tue, 23 Oct 2012 20:28:00 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-21.messagelabs.com!1351024079!4110043!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDE3MzY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDE3MzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23987 invoked from network); 23 Oct 2012 20:28:00 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Oct 2012 20:28:00 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0M7jF20=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-069-085.pools.arcor-ip.net [84.57.69.85])
	by smtp.strato.de (joses mo30) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id n0201fo9NJpfcf ;
	Tue, 23 Oct 2012 22:27:54 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id F133E18642; Tue, 23 Oct 2012 22:27:46 +0200 (CEST)
Date: Tue, 23 Oct 2012 22:27:46 +0200
From: Olaf Hering 
To: Jan Beulich 
Message-ID: <20121023202746.GA30376@aepfle.de>
References: <20120828082302.GA27309@aepfle.de>
	
	<20121022185036.GA15348@aepfle.de>
	<508664AE02000078000A3556@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <508664AE02000078000A3556@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: Keir Fraser , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] fixed location of share info page in HVM guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 23, Jan Beulich wrote:

> >>> On 22.10.12 at 20:50, Olaf Hering  wrote:
> > I came up with this (perhaps whitespace damaged) change, the guest still 
> > boots ok.
> > The asl part is just copy&paste from the HPET part.
> 
> ... and, pending a response to Keir's question on its need in the
> first place, need to be fixed:

Until the kernel can really use such an ACPI entry I will remove this
part of the patch.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 20:28:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 20:28:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQl51-0000ta-AD; Tue, 23 Oct 2012 20:28:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQl4z-0000tV-4V
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 20:28:01 +0000
Received: from [85.158.143.35:14928] by server-3.bemta-4.messagelabs.com id
	5C/3B-24279-0DDF6805; Tue, 23 Oct 2012 20:28:00 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-21.messagelabs.com!1351024079!4110043!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDE3MzY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDE3MzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23987 invoked from network); 23 Oct 2012 20:28:00 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Oct 2012 20:28:00 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0M7jF20=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-069-085.pools.arcor-ip.net [84.57.69.85])
	by smtp.strato.de (joses mo30) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id n0201fo9NJpfcf ;
	Tue, 23 Oct 2012 22:27:54 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id F133E18642; Tue, 23 Oct 2012 22:27:46 +0200 (CEST)
Date: Tue, 23 Oct 2012 22:27:46 +0200
From: Olaf Hering 
To: Jan Beulich 
Message-ID: <20121023202746.GA30376@aepfle.de>
References: <20120828082302.GA27309@aepfle.de>
	
	<20121022185036.GA15348@aepfle.de>
	<508664AE02000078000A3556@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <508664AE02000078000A3556@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: Keir Fraser , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] fixed location of share info page in HVM guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 23, Jan Beulich wrote:

> >>> On 22.10.12 at 20:50, Olaf Hering  wrote:
> > I came up with this (perhaps whitespace damaged) change, the guest still 
> > boots ok.
> > The asl part is just copy&paste from the HPET part.
> 
> ... and, pending a response to Keir's question on its need in the
> first place, need to be fixed:

Until the kernel can really use such an ACPI entry I will remove this
part of the patch.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 22:16:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 22:16:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQml5-0001VW-8c; Tue, 23 Oct 2012 22:15:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQml3-0001VR-ET
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 22:15:33 +0000
Received: from [193.109.254.147:8970] by server-8.bemta-14.messagelabs.com id
	1D/50-16549-40717805; Tue, 23 Oct 2012 22:15:32 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1351030526!11137168!1
X-Originating-IP: [72.21.196.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk2LjI1ID0+IDE0NDEyNg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23312 invoked from network); 23 Oct 2012 22:15:30 -0000
Received: from smtp-fw-2101.amazon.com (HELO smtp-fw-2101.amazon.com)
	(72.21.196.25)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 22:15:30 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt;
	s=amazon201209; t=1351030530; x=1382566530;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=765ZJbOCds96hEsILG7CQ4+bcPlUaC1qBQaNrSBG0FY=;
	b=S56eJFagbrAtd9x40FveqDTZSn8TtRJqAy5VcUXTLrmQG0bhjOqWdfvn
	CI6egMv7axX+AOGjAVxO1r19hcGUFgfq5JpDwCIl9+0zqizok7WtasEsW
	Fz2ZpkH1/ccO9AbM+FtXTy9UTGnX9IcEW3Rf3vRR8KlEtK8Ou0ddcTiMi 8=;
X-IronPort-AV: E=Sophos;i="4.80,637,1344211200"; d="scan'208";a="459269513"
Received: from smtp-in-1105.vdc.amazon.com ([10.140.9.24])
	by smtp-border-fw-out-2101.iad2.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Oct 2012 22:14:35 +0000
Received: from ex10-hub-31005.ant.amazon.com (ex10-hub-31005.sea31.amazon.com
	[10.185.176.12])
	by smtp-in-1105.vdc.amazon.com (8.13.8/8.13.8) with ESMTP id
	q9NMES13027372
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Tue, 23 Oct 2012 22:14:28 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.38) by
	ex10-hub-31005.ant.amazon.com (10.185.176.12) with Microsoft SMTP
	Server id 14.2.247.3; Tue, 23 Oct 2012 15:14:27 -0700
Received: by u002268147cd4502c336d.ant.amazon.com (sSMTP sendmail emulation); 
	Tue, 23 Oct 2012 15:14:27 -0700
Date: Tue, 23 Oct 2012 15:14:26 -0700
From: Matt Wilson 
To: Ian Campbell 
Message-ID: <20121023221419.GA27793@u002268147cd4502c336d.ant.amazon.com>
References: <1350668075-5840-1-git-send-email-msw@amazon.com>
	<1350983097.2237.14.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1350983097.2237.14.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Paul Harvey ,
	"xen-devel@lists.xen.org" ,
	Nikita Borzykh ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH] xen-netback: allow changing the MAC address
 of the interface
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 23, 2012 at 10:04:57AM +0100, Ian Campbell wrote:
> On Fri, 2012-10-19 at 18:34 +0100, Matt Wilson wrote:
> > Reported-by: Nikita Borzykh 
> > Reported-by: Paul Harvey 
> > Suggested-by: Ian Campbell 
> 
> I can't remember that but it seems reasonable:

http://lists.xen.org/archives/html/xen-devel/2011-01/msg01427.html

> Acked-by: Ian Campbell 
> 
> But, can you remind us of the usecase? Perhaps in the commit message?

It could be useful for some ebtables configurations, I think.

> Lastly, netback patches should be sent to netdev@vger.kernel.org as per
> MAINTAINERS in order to be applied.

Indeed. I wrongly assumed that Konrad would take care of bringing it
into his tree and that it'd get pulled from there. I'll expand the
commit message, add your Acked-by:, and send it on.

Matt

> > Signed-off-by: Matt Wilson 
> > ---
> >  drivers/net/xen-netback/interface.c |    2 ++
> >  1 files changed, 2 insertions(+), 0 deletions(-)
> > 
> > diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
> > index b7d41f8..f733cae 100644
> > --- a/drivers/net/xen-netback/interface.c
> > +++ b/drivers/net/xen-netback/interface.c
> > @@ -238,6 +238,8 @@ static const struct net_device_ops xenvif_netdev_ops = {
> >  	.ndo_stop	= xenvif_close,
> >  	.ndo_change_mtu	= xenvif_change_mtu,
> >  	.ndo_fix_features = xenvif_fix_features,
> > +	.ndo_set_mac_address = eth_mac_addr,
> > +	.ndo_validate_addr   = eth_validate_addr,
> >  };
> >  
> >  struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 22:16:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 22:16:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQml5-0001VW-8c; Tue, 23 Oct 2012 22:15:35 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQml3-0001VR-ET
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 22:15:33 +0000
Received: from [193.109.254.147:8970] by server-8.bemta-14.messagelabs.com id
	1D/50-16549-40717805; Tue, 23 Oct 2012 22:15:32 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1351030526!11137168!1
X-Originating-IP: [72.21.196.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk2LjI1ID0+IDE0NDEyNg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23312 invoked from network); 23 Oct 2012 22:15:30 -0000
Received: from smtp-fw-2101.amazon.com (HELO smtp-fw-2101.amazon.com)
	(72.21.196.25)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 22:15:30 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt;
	s=amazon201209; t=1351030530; x=1382566530;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=765ZJbOCds96hEsILG7CQ4+bcPlUaC1qBQaNrSBG0FY=;
	b=S56eJFagbrAtd9x40FveqDTZSn8TtRJqAy5VcUXTLrmQG0bhjOqWdfvn
	CI6egMv7axX+AOGjAVxO1r19hcGUFgfq5JpDwCIl9+0zqizok7WtasEsW
	Fz2ZpkH1/ccO9AbM+FtXTy9UTGnX9IcEW3Rf3vRR8KlEtK8Ou0ddcTiMi 8=;
X-IronPort-AV: E=Sophos;i="4.80,637,1344211200"; d="scan'208";a="459269513"
Received: from smtp-in-1105.vdc.amazon.com ([10.140.9.24])
	by smtp-border-fw-out-2101.iad2.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Oct 2012 22:14:35 +0000
Received: from ex10-hub-31005.ant.amazon.com (ex10-hub-31005.sea31.amazon.com
	[10.185.176.12])
	by smtp-in-1105.vdc.amazon.com (8.13.8/8.13.8) with ESMTP id
	q9NMES13027372
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Tue, 23 Oct 2012 22:14:28 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.38) by
	ex10-hub-31005.ant.amazon.com (10.185.176.12) with Microsoft SMTP
	Server id 14.2.247.3; Tue, 23 Oct 2012 15:14:27 -0700
Received: by u002268147cd4502c336d.ant.amazon.com (sSMTP sendmail emulation); 
	Tue, 23 Oct 2012 15:14:27 -0700
Date: Tue, 23 Oct 2012 15:14:26 -0700
From: Matt Wilson 
To: Ian Campbell 
Message-ID: <20121023221419.GA27793@u002268147cd4502c336d.ant.amazon.com>
References: <1350668075-5840-1-git-send-email-msw@amazon.com>
	<1350983097.2237.14.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1350983097.2237.14.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Paul Harvey ,
	"xen-devel@lists.xen.org" ,
	Nikita Borzykh ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH] xen-netback: allow changing the MAC address
 of the interface
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 23, 2012 at 10:04:57AM +0100, Ian Campbell wrote:
> On Fri, 2012-10-19 at 18:34 +0100, Matt Wilson wrote:
> > Reported-by: Nikita Borzykh 
> > Reported-by: Paul Harvey 
> > Suggested-by: Ian Campbell 
> 
> I can't remember that but it seems reasonable:

http://lists.xen.org/archives/html/xen-devel/2011-01/msg01427.html

> Acked-by: Ian Campbell 
> 
> But, can you remind us of the usecase? Perhaps in the commit message?

It could be useful for some ebtables configurations, I think.

> Lastly, netback patches should be sent to netdev@vger.kernel.org as per
> MAINTAINERS in order to be applied.

Indeed. I wrongly assumed that Konrad would take care of bringing it
into his tree and that it'd get pulled from there. I'll expand the
commit message, add your Acked-by:, and send it on.

Matt

> > Signed-off-by: Matt Wilson 
> > ---
> >  drivers/net/xen-netback/interface.c |    2 ++
> >  1 files changed, 2 insertions(+), 0 deletions(-)
> > 
> > diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
> > index b7d41f8..f733cae 100644
> > --- a/drivers/net/xen-netback/interface.c
> > +++ b/drivers/net/xen-netback/interface.c
> > @@ -238,6 +238,8 @@ static const struct net_device_ops xenvif_netdev_ops = {
> >  	.ndo_stop	= xenvif_close,
> >  	.ndo_change_mtu	= xenvif_change_mtu,
> >  	.ndo_fix_features = xenvif_fix_features,
> > +	.ndo_set_mac_address = eth_mac_addr,
> > +	.ndo_validate_addr   = eth_validate_addr,
> >  };
> >  
> >  struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 22:18:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 22:18:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQmnK-0001cJ-VU; Tue, 23 Oct 2012 22:17:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQmnJ-0001cD-Nt
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 22:17:54 +0000
Received: from [85.158.139.83:32487] by server-13.bemta-5.messagelabs.com id
	F6/5D-27809-19717805; Tue, 23 Oct 2012 22:17:53 +0000
X-Env-Sender: peter.maloney@brockmann-consult.de
X-Msg-Ref: server-16.tower-182.messagelabs.com!1351030672!28852908!1
X-Originating-IP: [212.227.17.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjEyLjIyNy4xNy4xMCA9PiA4OTM2MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31168 invoked from network); 23 Oct 2012 22:17:52 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.17.10)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 22:17:52 -0000
Received: from [192.168.179.201] (hmbg-5f7666d9.pool.mediaWays.net
	[95.118.102.217])
	by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis)
	id 0M9eBT-1TZtbu1ghb-00CeD3; Wed, 24 Oct 2012 00:17:49 +0200
Message-ID: <5087178B.900@brockmann-consult.de>
Date: Wed, 24 Oct 2012 00:17:47 +0200
From: Peter Maloney 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120825 Thunderbird/15.0
MIME-Version: 1.0
To: Tim Deegan 
References: <5082DD8C.2030608@brockmann-consult.de>
	<20121022135920.GE12577@ocelot.phlegethon.org>
In-Reply-To: <20121022135920.GE12577@ocelot.phlegethon.org>
X-Provags-ID: V02:K0:0rt/YI5y0IAoi5BOQzTFOYYqaWtRxqmkOat+77Sh4j+
	A75e5oOF621XJzNYY300Ay0Y1bbEnjZ9syGLv6q7voCNxxN9Yw
	LuqHIES3VlreDKWo05F/fx+/CXidY3u6RJY34KUG92HCxRLWGi
	HYiSQES3V+YBk9ufKZvuTvK47HpI03QVJaISShd72YZ5O2cU1C
	PQCcTDCImtDTNf0WKaP04yyATeP0Vostbyl/6cXt8FOMteXgjJ
	qNeJebjOm/XqaodxP3J1VYFTzrPe1PThSXxXNWmv0q6bjZyvKb
	IcNVMSjNis21XbvPQ4jmYX6EVKBA3dKR+GlNZNfdkyS4TS4iHk
	fx7TSb7BaFUJrKC4J6XVDr4kscg9pJEyZo5IeBUrJ7C/nV9llg
	2fzCnt3Vz7NZA==
Cc: Andres Lagar-Cavilla , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen-unstable,
 winxp32 very poor performance on AMD FX-8150,
 I bisected and changeset is 24770:7f79475d3de7
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/22/2012 03:59 PM, Tim Deegan wrote:
> At 19:21 +0200 on 20 Oct (1350760876), Peter Maloney wrote:
>> I ran a bisect to find out when Windows XP 32 bit becomes unusably slow.
>> And I found the changeset that caused it.
>>
>> ==========
>> The problem:
>> ==========
>>
>> Windows 8 64 bit and 32 bit run fast and fine in the newest xen versions.
>>
>> Windows XP 32 bit runs unusably slow in anything new that I built from
>> xen-unstable, but runs fast in 4.1.2 and 4.1.3 stable. While it is
>> running slow, "xm top" or "xl top" show cpu usage around 650% for the domu.
>>
>> The bug might be AMD specific. I'm running an AMD FX-8150.
> The bug does seem to be AMD-specific, and NPT-specific; with
> 'hap=0' it goes much faster. 
K. glad to hear it  ;) I just guessed it was AMD specific since not so
many of us seem to run AMDs and it seemed to be only me with the problem.
>> ==========
>> The result:
>> ==========
>>
>> good: 24769:730f6ed72d70
>> bad: 24770:7f79475d3de7
>>
>> The change was 8 months ago
>>
>> changeset:   24770:7f79475d3de7
>> user:        Andres Lagar-Cavilla 
>> date:        Fri Feb 10 16:07:07 2012 +0000
>> summary:     x86/mm: Make p2m lookups fully synchronized wrt modifications
> This change was bad for performnace across the board and most of it has
> since been either reverted or amended, but clearly we missed something
> here. 
>
> It's interesting that Win8 isn't slowed down.  I wonder whether that's to
> do with the way it drives the VGA card -- IIRC it uses a generic VESA
> driver rather than a Cirrus one. 
My tests included
- passthrough and "stdvga=1" which replaces the cirrus one with some
other card.
- no passthrougn, and did not set stdvga (used vnc and cirrus)
Both were slow.
>
> Tim.
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 22:18:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 22:18:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQmnK-0001cJ-VU; Tue, 23 Oct 2012 22:17:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQmnJ-0001cD-Nt
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 22:17:54 +0000
Received: from [85.158.139.83:32487] by server-13.bemta-5.messagelabs.com id
	F6/5D-27809-19717805; Tue, 23 Oct 2012 22:17:53 +0000
X-Env-Sender: peter.maloney@brockmann-consult.de
X-Msg-Ref: server-16.tower-182.messagelabs.com!1351030672!28852908!1
X-Originating-IP: [212.227.17.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjEyLjIyNy4xNy4xMCA9PiA4OTM2MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31168 invoked from network); 23 Oct 2012 22:17:52 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.17.10)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 22:17:52 -0000
Received: from [192.168.179.201] (hmbg-5f7666d9.pool.mediaWays.net
	[95.118.102.217])
	by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis)
	id 0M9eBT-1TZtbu1ghb-00CeD3; Wed, 24 Oct 2012 00:17:49 +0200
Message-ID: <5087178B.900@brockmann-consult.de>
Date: Wed, 24 Oct 2012 00:17:47 +0200
From: Peter Maloney 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120825 Thunderbird/15.0
MIME-Version: 1.0
To: Tim Deegan 
References: <5082DD8C.2030608@brockmann-consult.de>
	<20121022135920.GE12577@ocelot.phlegethon.org>
In-Reply-To: <20121022135920.GE12577@ocelot.phlegethon.org>
X-Provags-ID: V02:K0:0rt/YI5y0IAoi5BOQzTFOYYqaWtRxqmkOat+77Sh4j+
	A75e5oOF621XJzNYY300Ay0Y1bbEnjZ9syGLv6q7voCNxxN9Yw
	LuqHIES3VlreDKWo05F/fx+/CXidY3u6RJY34KUG92HCxRLWGi
	HYiSQES3V+YBk9ufKZvuTvK47HpI03QVJaISShd72YZ5O2cU1C
	PQCcTDCImtDTNf0WKaP04yyATeP0Vostbyl/6cXt8FOMteXgjJ
	qNeJebjOm/XqaodxP3J1VYFTzrPe1PThSXxXNWmv0q6bjZyvKb
	IcNVMSjNis21XbvPQ4jmYX6EVKBA3dKR+GlNZNfdkyS4TS4iHk
	fx7TSb7BaFUJrKC4J6XVDr4kscg9pJEyZo5IeBUrJ7C/nV9llg
	2fzCnt3Vz7NZA==
Cc: Andres Lagar-Cavilla , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen-unstable,
 winxp32 very poor performance on AMD FX-8150,
 I bisected and changeset is 24770:7f79475d3de7
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/22/2012 03:59 PM, Tim Deegan wrote:
> At 19:21 +0200 on 20 Oct (1350760876), Peter Maloney wrote:
>> I ran a bisect to find out when Windows XP 32 bit becomes unusably slow.
>> And I found the changeset that caused it.
>>
>> ==========
>> The problem:
>> ==========
>>
>> Windows 8 64 bit and 32 bit run fast and fine in the newest xen versions.
>>
>> Windows XP 32 bit runs unusably slow in anything new that I built from
>> xen-unstable, but runs fast in 4.1.2 and 4.1.3 stable. While it is
>> running slow, "xm top" or "xl top" show cpu usage around 650% for the domu.
>>
>> The bug might be AMD specific. I'm running an AMD FX-8150.
> The bug does seem to be AMD-specific, and NPT-specific; with
> 'hap=0' it goes much faster. 
K. glad to hear it  ;) I just guessed it was AMD specific since not so
many of us seem to run AMDs and it seemed to be only me with the problem.
>> ==========
>> The result:
>> ==========
>>
>> good: 24769:730f6ed72d70
>> bad: 24770:7f79475d3de7
>>
>> The change was 8 months ago
>>
>> changeset:   24770:7f79475d3de7
>> user:        Andres Lagar-Cavilla 
>> date:        Fri Feb 10 16:07:07 2012 +0000
>> summary:     x86/mm: Make p2m lookups fully synchronized wrt modifications
> This change was bad for performnace across the board and most of it has
> since been either reverted or amended, but clearly we missed something
> here. 
>
> It's interesting that Win8 isn't slowed down.  I wonder whether that's to
> do with the way it drives the VGA card -- IIRC it uses a generic VESA
> driver rather than a Cirrus one. 
My tests included
- passthrough and "stdvga=1" which replaces the cirrus one with some
other card.
- no passthrougn, and did not set stdvga (used vnc and cirrus)
Both were slow.
>
> Tim.
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 23:48:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 23:48:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQoCH-0002XB-5g; Tue, 23 Oct 2012 23:47:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQoCF-0002X6-Kd
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 23:47:43 +0000
Received: from [85.158.139.211:34385] by server-10.bemta-5.messagelabs.com id
	A2/86-01025-E9C27805; Tue, 23 Oct 2012 23:47:42 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1351036060!23456316!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAxMDM4Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14879 invoked from network); 23 Oct 2012 23:47:42 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Oct 2012 23:47:42 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9NNlWkK011827
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 23 Oct 2012 23:47:33 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9NNlVlv028739
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 23 Oct 2012 23:47:32 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9NNlVxK022270; Tue, 23 Oct 2012 18:47:31 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 23 Oct 2012 16:47:30 -0700
Date: Tue, 23 Oct 2012 16:47:29 -0700
From: Mukesh Rathor 
To: Stefano Stabellini 
Message-ID: <20121023164729.0ed51a1d@mantra.us.oracle.com>
In-Reply-To: 
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
	<1350695882-12820-5-git-send-email-konrad.wilk@oracle.com>
	
	<20121022155717.GB25200@phenom.dumpdata.com>
	
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Ian Campbell ,
	"xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 4/6] xen/pvh: bootup and setup related
	changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 23 Oct 2012 14:07:06 +0100
Stefano Stabellini  wrote:

> On Mon, 22 Oct 2012, Konrad Rzeszutek Wilk wrote:
> > On Mon, Oct 22, 2012 at 02:34:44PM +0100, Stefano Stabellini wrote:
> > > On Sat, 20 Oct 2012, Konrad Rzeszutek Wilk wrote:
> > > > From: Mukesh Rathor 
> > > > 
> > > >  	for (pfn = PFN_DOWN(start); pfn < xen_max_p2m_pfn;
> > > > pfn++) { unsigned long mfn = pfn_to_mfn(pfn);
> > > > @@ -100,6 +104,7 @@ static unsigned long __init
> > > > xen_do_chunk(unsigned long start, .domid        = DOMID_SELF
> > > >  	};
> > > >  	unsigned long len = 0;
> > > > +	int xlated_phys =
> > > > xen_feature(XENFEAT_auto_translated_physmap); unsigned long pfn;
> > > >  	int ret;
> > > >  
> > > > @@ -113,7 +118,7 @@ static unsigned long __init
> > > > xen_do_chunk(unsigned long start, continue;
> > > >  			frame = mfn;
> > > >  		} else {
> > > > -			if (mfn != INVALID_P2M_ENTRY)
> > > > +			if (!xlated_phys && mfn !=
> > > > INVALID_P2M_ENTRY) continue;
> > > >  			frame = pfn;
> > > >  		}
> > > 
> > > Shouldn't we add a "!xlated_phys &&" to the other case as well?
> > 
> > No. That is handled in xen_pvh_identity_map_chunk which
> > just does a xen_set_clr_mmio_pvh_pte call for the "released"
> > pages. But that is a bit of ... well, extra logic. I think
> > if we did this it would work and look much nicer:
> 
> Yes, I think that this version looks better

But doesn't boot:

(XEN) vmx_hybrid.c:710:d0 Dom:0 EPT violation 0x181 (r--/---), gpa 0x000000bf421e1c, mfn 0xffffffffffffffff, type 4.
(XEN) p2m-ept.c:642:d0 Walking EPT tables for domain 0 gfn bf421
(XEN) p2m-ept.c:648:d0  gfn exceeds max_mapped_pfn 4b062
(XEN) vmx_hybrid.c:717:d0  --- GLA 0xffffffffff477e1c


I'll have to debug it, or we can go back to the prev version, which
I don't think is that un-pretty :).

Mukesh



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 23 23:48:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 23 Oct 2012 23:48:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQoCH-0002XB-5g; Tue, 23 Oct 2012 23:47:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQoCF-0002X6-Kd
	for xen-devel@lists.xensource.com; Tue, 23 Oct 2012 23:47:43 +0000
Received: from [85.158.139.211:34385] by server-10.bemta-5.messagelabs.com id
	A2/86-01025-E9C27805; Tue, 23 Oct 2012 23:47:42 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1351036060!23456316!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAxMDM4Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14879 invoked from network); 23 Oct 2012 23:47:42 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Oct 2012 23:47:42 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9NNlWkK011827
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 23 Oct 2012 23:47:33 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9NNlVlv028739
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 23 Oct 2012 23:47:32 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9NNlVxK022270; Tue, 23 Oct 2012 18:47:31 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 23 Oct 2012 16:47:30 -0700
Date: Tue, 23 Oct 2012 16:47:29 -0700
From: Mukesh Rathor 
To: Stefano Stabellini 
Message-ID: <20121023164729.0ed51a1d@mantra.us.oracle.com>
In-Reply-To: 
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
	<1350695882-12820-5-git-send-email-konrad.wilk@oracle.com>
	
	<20121022155717.GB25200@phenom.dumpdata.com>
	
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Ian Campbell ,
	"xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 4/6] xen/pvh: bootup and setup related
	changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 23 Oct 2012 14:07:06 +0100
Stefano Stabellini  wrote:

> On Mon, 22 Oct 2012, Konrad Rzeszutek Wilk wrote:
> > On Mon, Oct 22, 2012 at 02:34:44PM +0100, Stefano Stabellini wrote:
> > > On Sat, 20 Oct 2012, Konrad Rzeszutek Wilk wrote:
> > > > From: Mukesh Rathor 
> > > > 
> > > >  	for (pfn = PFN_DOWN(start); pfn < xen_max_p2m_pfn;
> > > > pfn++) { unsigned long mfn = pfn_to_mfn(pfn);
> > > > @@ -100,6 +104,7 @@ static unsigned long __init
> > > > xen_do_chunk(unsigned long start, .domid        = DOMID_SELF
> > > >  	};
> > > >  	unsigned long len = 0;
> > > > +	int xlated_phys =
> > > > xen_feature(XENFEAT_auto_translated_physmap); unsigned long pfn;
> > > >  	int ret;
> > > >  
> > > > @@ -113,7 +118,7 @@ static unsigned long __init
> > > > xen_do_chunk(unsigned long start, continue;
> > > >  			frame = mfn;
> > > >  		} else {
> > > > -			if (mfn != INVALID_P2M_ENTRY)
> > > > +			if (!xlated_phys && mfn !=
> > > > INVALID_P2M_ENTRY) continue;
> > > >  			frame = pfn;
> > > >  		}
> > > 
> > > Shouldn't we add a "!xlated_phys &&" to the other case as well?
> > 
> > No. That is handled in xen_pvh_identity_map_chunk which
> > just does a xen_set_clr_mmio_pvh_pte call for the "released"
> > pages. But that is a bit of ... well, extra logic. I think
> > if we did this it would work and look much nicer:
> 
> Yes, I think that this version looks better

But doesn't boot:

(XEN) vmx_hybrid.c:710:d0 Dom:0 EPT violation 0x181 (r--/---), gpa 0x000000bf421e1c, mfn 0xffffffffffffffff, type 4.
(XEN) p2m-ept.c:642:d0 Walking EPT tables for domain 0 gfn bf421
(XEN) p2m-ept.c:648:d0  gfn exceeds max_mapped_pfn 4b062
(XEN) vmx_hybrid.c:717:d0  --- GLA 0xffffffffff477e1c


I'll have to debug it, or we can go back to the prev version, which
I don't think is that un-pretty :).

Mukesh



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 00:03:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 00:03:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQoRP-00039c-Ow; Wed, 24 Oct 2012 00:03:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQoRN-00039X-KX
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 00:03:21 +0000
Received: from [85.158.139.83:4706] by server-15.bemta-5.messagelabs.com id
	AE/28-26920-84037805; Wed, 24 Oct 2012 00:03:20 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1351036998!35626740!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAxMDM4Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25214 invoked from network); 24 Oct 2012 00:03:20 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Oct 2012 00:03:20 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9O03DKp020452
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 24 Oct 2012 00:03:14 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9O03Ci9013988
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 24 Oct 2012 00:03:13 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9O03COO007727; Tue, 23 Oct 2012 19:03:12 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 23 Oct 2012 17:03:12 -0700
Date: Tue, 23 Oct 2012 17:03:10 -0700
From: Mukesh Rathor 
To: Mukesh Rathor 
Message-ID: <20121023170310.3b2a7e20@mantra.us.oracle.com>
In-Reply-To: <20121023164729.0ed51a1d@mantra.us.oracle.com>
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
	<1350695882-12820-5-git-send-email-konrad.wilk@oracle.com>
	
	<20121022155717.GB25200@phenom.dumpdata.com>
	
	<20121023164729.0ed51a1d@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "linux-kernel@vger.kernel.org" ,
	"xen-devel@lists.xensource.com" ,
	Ian Campbell ,
	Konrad Rzeszutek Wilk ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 4/6] xen/pvh: bootup and setup related
 changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 23 Oct 2012 16:47:29 -0700
Mukesh Rathor  wrote:

> On Tue, 23 Oct 2012 14:07:06 +0100
> Stefano Stabellini  wrote:
> 
> > On Mon, 22 Oct 2012, Konrad Rzeszutek Wilk wrote:
> > > On Mon, Oct 22, 2012 at 02:34:44PM +0100, Stefano Stabellini
> > > wrote:
> > > > On Sat, 20 Oct 2012, Konrad Rzeszutek Wilk wrote:
> > > > > From: Mukesh Rathor 
> > > > > 
> > > > >  	for (pfn = PFN_DOWN(start); pfn < xen_max_p2m_pfn;
> > > > > pfn++) { unsigned long mfn = pfn_to_mfn(pfn);
> > > > > @@ -100,6 +104,7 @@ static unsigned long __init
> > > > > xen_do_chunk(unsigned long start, .domid        = DOMID_SELF
> > > > >  	};
> > > > >  	unsigned long len = 0;
> > > > > +	int xlated_phys =
> > > > > xen_feature(XENFEAT_auto_translated_physmap); unsigned long
> > > > > pfn; int ret;
> > > > >  
> > > > > @@ -113,7 +118,7 @@ static unsigned long __init
> > > > > xen_do_chunk(unsigned long start, continue;
> > > > >  			frame = mfn;
> > > > >  		} else {
> > > > > -			if (mfn != INVALID_P2M_ENTRY)
> > > > > +			if (!xlated_phys && mfn !=
> > > > > INVALID_P2M_ENTRY) continue;
> > > > >  			frame = pfn;
> > > > >  		}
> > > > 
> > > > Shouldn't we add a "!xlated_phys &&" to the other case as well?
> > > 
> > > No. That is handled in xen_pvh_identity_map_chunk which
> > > just does a xen_set_clr_mmio_pvh_pte call for the "released"
> > > pages. But that is a bit of ... well, extra logic. I think
> > > if we did this it would work and look much nicer:
> > 
> > Yes, I think that this version looks better
> 
> But doesn't boot:
> 
> (XEN) vmx_hybrid.c:710:d0 Dom:0 EPT violation 0x181 (r--/---), gpa
> 0x000000bf421e1c, mfn 0xffffffffffffffff, type 4. (XEN)
> p2m-ept.c:642:d0 Walking EPT tables for domain 0 gfn bf421 (XEN)
> p2m-ept.c:648:d0  gfn exceeds max_mapped_pfn 4b062 (XEN)
> vmx_hybrid.c:717:d0  --- GLA 0xffffffffff477e1c
> 
> 
> I'll have to debug it, or we can go back to the prev version, which
> I don't think is that un-pretty :).
> 

The reason being:
xen_set_identity_and_release_chunk():
NEW : > for (pfn = start_pfn; pfn <= max_pfn_mapped && pfn < end_pfn; pfn++) {

xen_pvh_identity_map_chunk():
OLD: for (pfn = start_pfn; pfn < end_pfn; pfn++)

IOW, for PVH we need to avoid testing for max_pfn_mapped, as we are
mapping the entire IO space. 

thanks
mukesh


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 00:03:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 00:03:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQoRP-00039c-Ow; Wed, 24 Oct 2012 00:03:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQoRN-00039X-KX
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 00:03:21 +0000
Received: from [85.158.139.83:4706] by server-15.bemta-5.messagelabs.com id
	AE/28-26920-84037805; Wed, 24 Oct 2012 00:03:20 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1351036998!35626740!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAxMDM4Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25214 invoked from network); 24 Oct 2012 00:03:20 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Oct 2012 00:03:20 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9O03DKp020452
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 24 Oct 2012 00:03:14 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9O03Ci9013988
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 24 Oct 2012 00:03:13 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9O03COO007727; Tue, 23 Oct 2012 19:03:12 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 23 Oct 2012 17:03:12 -0700
Date: Tue, 23 Oct 2012 17:03:10 -0700
From: Mukesh Rathor 
To: Mukesh Rathor 
Message-ID: <20121023170310.3b2a7e20@mantra.us.oracle.com>
In-Reply-To: <20121023164729.0ed51a1d@mantra.us.oracle.com>
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
	<1350695882-12820-5-git-send-email-konrad.wilk@oracle.com>
	
	<20121022155717.GB25200@phenom.dumpdata.com>
	
	<20121023164729.0ed51a1d@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "linux-kernel@vger.kernel.org" ,
	"xen-devel@lists.xensource.com" ,
	Ian Campbell ,
	Konrad Rzeszutek Wilk ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 4/6] xen/pvh: bootup and setup related
 changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 23 Oct 2012 16:47:29 -0700
Mukesh Rathor  wrote:

> On Tue, 23 Oct 2012 14:07:06 +0100
> Stefano Stabellini  wrote:
> 
> > On Mon, 22 Oct 2012, Konrad Rzeszutek Wilk wrote:
> > > On Mon, Oct 22, 2012 at 02:34:44PM +0100, Stefano Stabellini
> > > wrote:
> > > > On Sat, 20 Oct 2012, Konrad Rzeszutek Wilk wrote:
> > > > > From: Mukesh Rathor 
> > > > > 
> > > > >  	for (pfn = PFN_DOWN(start); pfn < xen_max_p2m_pfn;
> > > > > pfn++) { unsigned long mfn = pfn_to_mfn(pfn);
> > > > > @@ -100,6 +104,7 @@ static unsigned long __init
> > > > > xen_do_chunk(unsigned long start, .domid        = DOMID_SELF
> > > > >  	};
> > > > >  	unsigned long len = 0;
> > > > > +	int xlated_phys =
> > > > > xen_feature(XENFEAT_auto_translated_physmap); unsigned long
> > > > > pfn; int ret;
> > > > >  
> > > > > @@ -113,7 +118,7 @@ static unsigned long __init
> > > > > xen_do_chunk(unsigned long start, continue;
> > > > >  			frame = mfn;
> > > > >  		} else {
> > > > > -			if (mfn != INVALID_P2M_ENTRY)
> > > > > +			if (!xlated_phys && mfn !=
> > > > > INVALID_P2M_ENTRY) continue;
> > > > >  			frame = pfn;
> > > > >  		}
> > > > 
> > > > Shouldn't we add a "!xlated_phys &&" to the other case as well?
> > > 
> > > No. That is handled in xen_pvh_identity_map_chunk which
> > > just does a xen_set_clr_mmio_pvh_pte call for the "released"
> > > pages. But that is a bit of ... well, extra logic. I think
> > > if we did this it would work and look much nicer:
> > 
> > Yes, I think that this version looks better
> 
> But doesn't boot:
> 
> (XEN) vmx_hybrid.c:710:d0 Dom:0 EPT violation 0x181 (r--/---), gpa
> 0x000000bf421e1c, mfn 0xffffffffffffffff, type 4. (XEN)
> p2m-ept.c:642:d0 Walking EPT tables for domain 0 gfn bf421 (XEN)
> p2m-ept.c:648:d0  gfn exceeds max_mapped_pfn 4b062 (XEN)
> vmx_hybrid.c:717:d0  --- GLA 0xffffffffff477e1c
> 
> 
> I'll have to debug it, or we can go back to the prev version, which
> I don't think is that un-pretty :).
> 

The reason being:
xen_set_identity_and_release_chunk():
NEW : > for (pfn = start_pfn; pfn <= max_pfn_mapped && pfn < end_pfn; pfn++) {

xen_pvh_identity_map_chunk():
OLD: for (pfn = start_pfn; pfn < end_pfn; pfn++)

IOW, for PVH we need to avoid testing for max_pfn_mapped, as we are
mapping the entire IO space. 

thanks
mukesh


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 00:11:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 00:11:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQoYq-0003LK-0Y; Wed, 24 Oct 2012 00:11:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQoYo-0003LF-UN
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 00:11:03 +0000
Received: from [85.158.139.211:29680] by server-13.bemta-5.messagelabs.com id
	AB/6C-27809-61237805; Wed, 24 Oct 2012 00:11:02 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1351037460!19490482!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODIxNTg1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20659 invoked from network); 24 Oct 2012 00:11:01 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Oct 2012 00:11:01 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9O0Asbg003097
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 24 Oct 2012 00:10:55 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9O0AsVD000094
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 24 Oct 2012 00:10:54 GMT
Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9O0Arp5011812; Tue, 23 Oct 2012 19:10:53 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 23 Oct 2012 17:10:53 -0700
Date: Tue, 23 Oct 2012 17:10:51 -0700
From: Mukesh Rathor 
To: Mukesh Rathor 
Message-ID: <20121023171051.2ed9af3c@mantra.us.oracle.com>
In-Reply-To: <20121023170310.3b2a7e20@mantra.us.oracle.com>
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
	<1350695882-12820-5-git-send-email-konrad.wilk@oracle.com>
	
	<20121022155717.GB25200@phenom.dumpdata.com>
	
	<20121023164729.0ed51a1d@mantra.us.oracle.com>
	<20121023170310.3b2a7e20@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "linux-kernel@vger.kernel.org" ,
	"xen-devel@lists.xensource.com" ,
	Ian Campbell ,
	Konrad Rzeszutek Wilk ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 4/6] xen/pvh: bootup and setup related
 changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 23 Oct 2012 17:03:10 -0700
Mukesh Rathor  wrote:

> On Tue, 23 Oct 2012 16:47:29 -0700
> Mukesh Rathor  wrote:
> 
> > On Tue, 23 Oct 2012 14:07:06 +0100
> > Stefano Stabellini  wrote:
> > 
> > > On Mon, 22 Oct 2012, Konrad Rzeszutek Wilk wrote:
> > > > On Mon, Oct 22, 2012 at 02:34:44PM +0100, Stefano Stabellini
> > > > wrote:
> > > > > On Sat, 20 Oct 2012, Konrad Rzeszutek Wilk wrote:
> > > > > > From: Mukesh Rathor 
> > > > > > 
> > > > > >  	for (pfn = PFN_DOWN(start); pfn < xen_max_p2m_pfn;
> > > > > > pfn++) { unsigned long mfn = pfn_to_mfn(pfn);
> > > > > > @@ -100,6 +104,7 @@ static unsigned long __init
> > > > > > xen_do_chunk(unsigned long start, .domid        = DOMID_SELF
> > > > > >  	};
> > > > > >  	unsigned long len = 0;
> > > > > > +	int xlated_phys =
> > > > > > xen_feature(XENFEAT_auto_translated_physmap); unsigned long
> > > > > > pfn; int ret;
> > > > > >  
> > > > > > @@ -113,7 +118,7 @@ static unsigned long __init
> > > > > > xen_do_chunk(unsigned long start, continue;
> > > > > >  			frame = mfn;
> > > > > >  		} else {
> > > > > > -			if (mfn != INVALID_P2M_ENTRY)
> > > > > > +			if (!xlated_phys && mfn !=
> > > > > > INVALID_P2M_ENTRY) continue;
> > > > > >  			frame = pfn;
> > > > > >  		}
> > > > > 
> > > > > Shouldn't we add a "!xlated_phys &&" to the other case as
> > > > > well?
> > > > 
> > > > No. That is handled in xen_pvh_identity_map_chunk which
> > > > just does a xen_set_clr_mmio_pvh_pte call for the "released"
> > > > pages. But that is a bit of ... well, extra logic. I think
> > > > if we did this it would work and look much nicer:
> > > 
> > > Yes, I think that this version looks better
> > 
> > But doesn't boot:
> > 
> > (XEN) vmx_hybrid.c:710:d0 Dom:0 EPT violation 0x181 (r--/---), gpa
> > 0x000000bf421e1c, mfn 0xffffffffffffffff, type 4. (XEN)
> > p2m-ept.c:642:d0 Walking EPT tables for domain 0 gfn bf421 (XEN)
> > p2m-ept.c:648:d0  gfn exceeds max_mapped_pfn 4b062 (XEN)
> > vmx_hybrid.c:717:d0  --- GLA 0xffffffffff477e1c
> > 
> > 
> > I'll have to debug it, or we can go back to the prev version, which
> > I don't think is that un-pretty :).
> > 
> 
> The reason being:
> xen_set_identity_and_release_chunk():
> NEW : > for (pfn = start_pfn; pfn <= max_pfn_mapped && pfn < end_pfn;
> pfn++) {
> 
> xen_pvh_identity_map_chunk():
> OLD: for (pfn = start_pfn; pfn < end_pfn; pfn++)
> 
> IOW, for PVH we need to avoid testing for max_pfn_mapped, as we are
> mapping the entire IO space. 

Also, now your counts for released and identity are off. Can we please
go back to the way it was? 

thanks
Mukesh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 00:11:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 00:11:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQoYq-0003LK-0Y; Wed, 24 Oct 2012 00:11:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQoYo-0003LF-UN
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 00:11:03 +0000
Received: from [85.158.139.211:29680] by server-13.bemta-5.messagelabs.com id
	AB/6C-27809-61237805; Wed, 24 Oct 2012 00:11:02 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1351037460!19490482!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODIxNTg1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20659 invoked from network); 24 Oct 2012 00:11:01 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Oct 2012 00:11:01 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9O0Asbg003097
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 24 Oct 2012 00:10:55 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9O0AsVD000094
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 24 Oct 2012 00:10:54 GMT
Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9O0Arp5011812; Tue, 23 Oct 2012 19:10:53 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 23 Oct 2012 17:10:53 -0700
Date: Tue, 23 Oct 2012 17:10:51 -0700
From: Mukesh Rathor 
To: Mukesh Rathor 
Message-ID: <20121023171051.2ed9af3c@mantra.us.oracle.com>
In-Reply-To: <20121023170310.3b2a7e20@mantra.us.oracle.com>
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
	<1350695882-12820-5-git-send-email-konrad.wilk@oracle.com>
	
	<20121022155717.GB25200@phenom.dumpdata.com>
	
	<20121023164729.0ed51a1d@mantra.us.oracle.com>
	<20121023170310.3b2a7e20@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "linux-kernel@vger.kernel.org" ,
	"xen-devel@lists.xensource.com" ,
	Ian Campbell ,
	Konrad Rzeszutek Wilk ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 4/6] xen/pvh: bootup and setup related
 changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 23 Oct 2012 17:03:10 -0700
Mukesh Rathor  wrote:

> On Tue, 23 Oct 2012 16:47:29 -0700
> Mukesh Rathor  wrote:
> 
> > On Tue, 23 Oct 2012 14:07:06 +0100
> > Stefano Stabellini  wrote:
> > 
> > > On Mon, 22 Oct 2012, Konrad Rzeszutek Wilk wrote:
> > > > On Mon, Oct 22, 2012 at 02:34:44PM +0100, Stefano Stabellini
> > > > wrote:
> > > > > On Sat, 20 Oct 2012, Konrad Rzeszutek Wilk wrote:
> > > > > > From: Mukesh Rathor 
> > > > > > 
> > > > > >  	for (pfn = PFN_DOWN(start); pfn < xen_max_p2m_pfn;
> > > > > > pfn++) { unsigned long mfn = pfn_to_mfn(pfn);
> > > > > > @@ -100,6 +104,7 @@ static unsigned long __init
> > > > > > xen_do_chunk(unsigned long start, .domid        = DOMID_SELF
> > > > > >  	};
> > > > > >  	unsigned long len = 0;
> > > > > > +	int xlated_phys =
> > > > > > xen_feature(XENFEAT_auto_translated_physmap); unsigned long
> > > > > > pfn; int ret;
> > > > > >  
> > > > > > @@ -113,7 +118,7 @@ static unsigned long __init
> > > > > > xen_do_chunk(unsigned long start, continue;
> > > > > >  			frame = mfn;
> > > > > >  		} else {
> > > > > > -			if (mfn != INVALID_P2M_ENTRY)
> > > > > > +			if (!xlated_phys && mfn !=
> > > > > > INVALID_P2M_ENTRY) continue;
> > > > > >  			frame = pfn;
> > > > > >  		}
> > > > > 
> > > > > Shouldn't we add a "!xlated_phys &&" to the other case as
> > > > > well?
> > > > 
> > > > No. That is handled in xen_pvh_identity_map_chunk which
> > > > just does a xen_set_clr_mmio_pvh_pte call for the "released"
> > > > pages. But that is a bit of ... well, extra logic. I think
> > > > if we did this it would work and look much nicer:
> > > 
> > > Yes, I think that this version looks better
> > 
> > But doesn't boot:
> > 
> > (XEN) vmx_hybrid.c:710:d0 Dom:0 EPT violation 0x181 (r--/---), gpa
> > 0x000000bf421e1c, mfn 0xffffffffffffffff, type 4. (XEN)
> > p2m-ept.c:642:d0 Walking EPT tables for domain 0 gfn bf421 (XEN)
> > p2m-ept.c:648:d0  gfn exceeds max_mapped_pfn 4b062 (XEN)
> > vmx_hybrid.c:717:d0  --- GLA 0xffffffffff477e1c
> > 
> > 
> > I'll have to debug it, or we can go back to the prev version, which
> > I don't think is that un-pretty :).
> > 
> 
> The reason being:
> xen_set_identity_and_release_chunk():
> NEW : > for (pfn = start_pfn; pfn <= max_pfn_mapped && pfn < end_pfn;
> pfn++) {
> 
> xen_pvh_identity_map_chunk():
> OLD: for (pfn = start_pfn; pfn < end_pfn; pfn++)
> 
> IOW, for PVH we need to avoid testing for max_pfn_mapped, as we are
> mapping the entire IO space. 

Also, now your counts for released and identity are off. Can we please
go back to the way it was? 

thanks
Mukesh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 04:59:23 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 04:59:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQt3F-0001WH-VP; Wed, 24 Oct 2012 04:58:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQt3E-0001WC-08
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 04:58:44 +0000
Received: from [85.158.139.211:53524] by server-5.bemta-5.messagelabs.com id
	22/28-09732-38577805; Wed, 24 Oct 2012 04:58:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1351054722!23490637!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUzNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17880 invoked from network); 24 Oct 2012 04:58:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 04:58:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,638,1344211200"; d="scan'208";a="15347321"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 04:58:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 24 Oct 2012 05:58:40 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TQt39-0000P3-Ra;
	Wed, 24 Oct 2012 04:58:39 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TQt38-0008C5-RO;
	Wed, 24 Oct 2012 05:58:39 +0100
To: 
Message-ID: 
From: xen.org 
Date: Wed, 24 Oct 2012 05:58:39 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14072: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14072 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14072/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 14070
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 14070
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 14070
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 14070

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  07cf00a917cd
baseline version:
 xen                  d642720e1ea9

------------------------------------------------------------
People who touched revisions under test:
  Christoph Egger 
  Dario Faggioli 
  George Dunlap 
  Jan Beulich 
  Keir Fraser 
  Tim Deegan 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=07cf00a917cd
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 07cf00a917cd
+ branch=xen-unstable
+ revision=07cf00a917cd
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 07cf00a917cd ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 5 changesets with 9 changes to 8 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 04:59:23 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 04:59:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQt3F-0001WH-VP; Wed, 24 Oct 2012 04:58:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQt3E-0001WC-08
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 04:58:44 +0000
Received: from [85.158.139.211:53524] by server-5.bemta-5.messagelabs.com id
	22/28-09732-38577805; Wed, 24 Oct 2012 04:58:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1351054722!23490637!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUzNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17880 invoked from network); 24 Oct 2012 04:58:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 04:58:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,638,1344211200"; d="scan'208";a="15347321"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 04:58:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 24 Oct 2012 05:58:40 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TQt39-0000P3-Ra;
	Wed, 24 Oct 2012 04:58:39 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TQt38-0008C5-RO;
	Wed, 24 Oct 2012 05:58:39 +0100
To: 
Message-ID: 
From: xen.org 
Date: Wed, 24 Oct 2012 05:58:39 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14072: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14072 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14072/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 14070
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 14070
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 14070
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 14070

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  07cf00a917cd
baseline version:
 xen                  d642720e1ea9

------------------------------------------------------------
People who touched revisions under test:
  Christoph Egger 
  Dario Faggioli 
  George Dunlap 
  Jan Beulich 
  Keir Fraser 
  Tim Deegan 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=07cf00a917cd
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 07cf00a917cd
+ branch=xen-unstable
+ revision=07cf00a917cd
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 07cf00a917cd ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 5 changesets with 9 changes to 8 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 06:03:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 06:03:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQu31-0002JX-QF; Wed, 24 Oct 2012 06:02:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQu2z-0002JP-Lx; Wed, 24 Oct 2012 06:02:34 +0000
Received: from [85.158.137.99:23103] by server-9.bemta-3.messagelabs.com id
	61/6F-16841-87487805; Wed, 24 Oct 2012 06:02:32 +0000
X-Env-Sender: hufan@websense.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1351058552!19639828!1
X-Originating-IP: [85.115.56.190]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODUuMTE1LjU2LjE5MCA9PiA4ODcwNzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1482 invoked from network); 24 Oct 2012 06:02:32 -0000
Received: from cluster-b.mailcontrol.com (HELO cluster-b.mailcontrol.com)
	(85.115.56.190)
	by server-9.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Oct 2012 06:02:32 -0000
Received: from ssdwbsnapp.websense.com (static-204-15-65-158.websense.com
	[204.15.65.158] (may be forged))
	by rly41b.srv.mailcontrol.com (MailControl) with ESMTP id
	q9O62HnH018704
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 24 Oct 2012 07:02:21 +0100
Received: from SSDEXCH1B.websense.com (unknown [10.8.2.91])
	by Websense Email Security Gateway with ESMTP id BE1C61000015;
	Tue, 23 Oct 2012 23:01:59 -0700 (PDT)
Received: from SBJEXCH1A.websense.com (10.32.8.101) by SSDEXCH1B.websense.com
	(10.8.2.91) with Microsoft SMTP Server (TLS) id 14.2.283.3;
	Tue, 23 Oct 2012 23:02:17 -0700
Received: from SBJEXCH1B.websense.com ([169.254.2.203]) by
	SBJEXCH1A.websense.com ([169.254.1.146]) with mapi id 14.02.0283.003;
	Wed, 24 Oct 2012 14:02:13 +0800
From: "Fan, Huaxiang" 
To: =?iso-8859-1?Q?Pasi_K=E4rkk=E4inen?= 
Thread-Topic: [Xen-devel] e820_host problems
Thread-Index: Ac2wO6t52kDU66w/TymQ9bR6YOep8P//uuqA//zbyEA=
Date: Wed, 24 Oct 2012 06:02:11 +0000
Message-ID: 
References: 
	<20121022135023.GU8912@reaktio.net>
In-Reply-To: <20121022135023.GU8912@reaktio.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.32.134.111]
Content-Type: multipart/mixed;
	boundary="_005_E71FC5D6F96C3C4B93FC8FF942D924C682F45DE3SBJEXCH1Bwebsen_"
MIME-Version: 1.0
X-Scanned-By: MailControl 10515.0 (www.mailcontrol.com) on 10.66.0.151
Cc: "xen-users@lists.xen.org" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] e820_host problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_005_E71FC5D6F96C3C4B93FC8FF942D924C682F45DE3SBJEXCH1Bwebsen_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Pasi,

Thanks for your reply. I've tried the latest table kernel 3.6.3. The situat=
ion is better, but still not perfect. =20
When I assign 6144M to domu wcg ,the output of 'xl list' only indicates 511=
0M allocated for domu wcg.
When I logon domu wcg, the totol memory is *limited within 3G*. I suspect t=
he e820-map was wrong.

I attached domu config file, output of command 'xl -vvv create domainWCG.cf=
g', output of command 'xl list' and output of command 'dmesg' on domu wcg.

Thanks in advance.
Huaxiang
-----Original Message-----
From: Pasi K=E4rkk=E4inen [mailto:pasik@iki.fi]=20
Sent: Monday, October 22, 2012 9:50 PM
To: Fan, Huaxiang
Cc: xen-devel@lists.xen.org; xen-users@lists.xen.org
Subject: Re: [Xen-devel] e820_host problems

On Mon, Oct 22, 2012 at 10:11:00AM +0000, Fan, Huaxiang wrote:
>    Hi,
>=20
>=20
>=20
>    I've set up a PV guest using xen 4.2 and kernel 2.6.32.57. the hypervi=
or
>    is 64bits whereas the dom0 and domu are 32bits. It seems to me that th=
e
>    memory allocation to domu is *limited to 3360M* when e820_host is enab=
led.
>    I attached the domu configuration file and output of the command xl -v=
vv
>    create and xl list.
>=20
>    I am looking forward your reply.
>

First of all try with a later kernel, say Linux 3.6.2.

-- Pasi
=20
>    Thanks,
>=20
>    HUAXIANG FAN
>    Software Engineer II
>=20
>    WEBSENSE NETWORK SECURITY TECHNOLOGY R&D (BEIJING) CO. LTD.
>    ph: +8610.5884.4327
>    fax: +8610.5884.4727
>    [1]www.websense.cn
>=20
>    Websense TRITON(TM)
>    For Essential Information Protection(TM)
>    [2]Web Security | [3]Data Security | [4]Email Security
>=20
>         Protected by Websense Hosted Email Security -- www.websense.com
>=20
> References
>=20
>    Visible links
>    1. http://webdefence.global.blackspider.com/urlwrap/?q=3DAXicY2RmuMjNw=
HBHhYGhKKfSyCxFr7ioTC83MTMnOT-vpCg_Ry85P5eh0NLXJd_fMdXA2NDIwpAhozQtMc-hPDWp=
ODWvOBWsIqOkpMBKX7-8vFwPIZ6nzwAAo00fKg&Z
>    2. http://www.websense.com/content/Regional/SCH/WebSecurityOverview.as=
px
>    3. http://www.websense.com/content/Regional/SCH/DataSecurity.aspx
>    4. http://www.websense.com/content/Regional/SCH/MessagingSecurity.aspx




> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



 To report this as spam, please forward to spam@websense.com.  Thank you.

--_005_E71FC5D6F96C3C4B93FC8FF942D924C682F45DE3SBJEXCH1Bwebsen_
Content-Type: application/octet-stream; name="dmesg.output.domu"
Content-Description: dmesg.output.domu
Content-Disposition: attachment; filename="dmesg.output.domu"; size=11224;
	creation-date="Wed, 24 Oct 2012 06:00:07 GMT";
	modification-date="Wed, 24 Oct 2012 13:58:42 GMT"
Content-Transfer-Encoding: base64

WyAgICAwLjAwMDAwMF0gUmVzZXJ2aW5nIHZpcnR1YWwgYWRkcmVzcyBzcGFjZSBhYm92ZSAweGY1
ODAwMDAwClsgICAgMC4wMDAwMDBdIExpbnV4IHZlcnNpb24gMy42LjMgKHJvb3RAY2VudG9zNi4y
LTMyYml0KSAoZ2NjIHZlcnNpb24gNC40LjYgMjAxMTA3MzEgKFJlZCBIYXQgNC40LjYtMykgKEdD
QykgKSAjMSBTTVAgVHVlIE9jdCAyMyAxNjo1NTowMyBDU1QgMjAxMgpbICAgIDAuMDAwMDAwXSBB
Q1BJIGluIHVucHJpdmlsZWdlZCBkb21haW4gZGlzYWJsZWQKWyAgICAwLjAwMDAwMF0gRnJlZWlu
ZyBiZjY5OS0xMDAwMDAgcGZuIHJhbmdlOiAyNjQ1NTEgcGFnZXMgZnJlZWQKWyAgICAwLjAwMDAw
MF0gMS0xIG1hcHBpbmcgb24gYmY2OTktPjEwMDAwMApbICAgIDAuMDAwMDAwXSBSZWxlYXNlZCAy
NjQ1NTEgcGFnZXMgb2YgdW51c2VkIG1lbW9yeQpbICAgIDAuMDAwMDAwXSBTZXQgMjY0NTUxIHBh
Z2UocykgdG8gMS0xIG1hcHBpbmcKWyAgICAwLjAwMDAwMF0gZTgyMDogQklPUy1wcm92aWRlZCBw
aHlzaWNhbCBSQU0gbWFwOgpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMDAwMDAw
MDAwLTB4MDAwMDAwMDAwMDA5ZmZmZl0gdXNhYmxlClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAw
eDAwMDAwMDAwMDAwYTAwMDAtMHgwMDAwMDAwMDAwMGZmZmZmXSByZXNlcnZlZApbICAgIDAuMDAw
MDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMDAwMTAwMDAwLTB4MDAwMDAwMDBiZjY5OGZmZl0gdXNh
YmxlClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwYmY2OTkwMDAtMHgwMDAwMDAw
MGJmNmFlZmZmXSByZXNlcnZlZApbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMGJm
NmFmMDAwLTB4MDAwMDAwMDBiZjZjZGZmZl0gQUNQSSBkYXRhClsgICAgMC4wMDAwMDBdIFhlbjog
W21lbSAweDAwMDAwMDAwYmY2Y2UwMDAtMHgwMDAwMDAwMGJmZmZmZmZmXSByZXNlcnZlZApbICAg
IDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMGUwMDAwMDAwLTB4MDAwMDAwMDBlZmZmZmZm
Zl0gcmVzZXJ2ZWQKWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDBmZTAwMDAwMC0w
eDAwMDAwMDAwZmZmZmZmZmZdIHJlc2VydmVkClsgICAgMC4wMDAwMDBdIE5YIChFeGVjdXRlIERp
c2FibGUpIHByb3RlY3Rpb246IGFjdGl2ZQpbICAgIDAuMDAwMDAwXSBETUkgbm90IHByZXNlbnQg
b3IgaW52YWxpZC4KWyAgICAwLjAwMDAwMF0gZTgyMDogdXBkYXRlIFttZW0gMHgwMDAwMDAwMC0w
eDAwMDBmZmZmXSB1c2FibGUgPT0+IHJlc2VydmVkClsgICAgMC4wMDAwMDBdIGU4MjA6IHJlbW92
ZSBbbWVtIDB4MDAwYTAwMDAtMHgwMDBmZmZmZl0gdXNhYmxlClsgICAgMC4wMDAwMDBdIGU4MjA6
IGxhc3RfcGZuID0gMHhiZjY5OSBtYXhfYXJjaF9wZm4gPSAweDEwMDAwMDAKWyAgICAwLjAwMDAw
MF0gaW5pdGlhbCBtZW1vcnkgbWFwcGVkOiBbbWVtIDB4MDAwMDAwMDAtMHgwM2ZmZWZmZl0KWyAg
ICAwLjAwMDAwMF0gQmFzZSBtZW1vcnkgdHJhbXBvbGluZSBhdCBbYzAwOWMwMDBdIDljMDAwIHNp
emUgMTYzODQKWyAgICAwLjAwMDAwMF0gaW5pdF9tZW1vcnlfbWFwcGluZzogW21lbSAweDAwMDAw
MDAwLTB4MmQzZmRmZmZdClsgICAgMC4wMDAwMDBdICBbbWVtIDB4MDAwMDAwMDAtMHgyZDNmZGZm
Zl0gcGFnZSA0awpbICAgIDAuMDAwMDAwXSBrZXJuZWwgZGlyZWN0IG1hcHBpbmcgdGFibGVzIHVw
IHRvIDB4MmQzZmRmZmYgQCBbbWVtIDB4MDNlOTIwMDAtMHgwM2ZmZWZmZl0KWyAgICAwLjAwMDAw
MF0geGVuOiBzZXR0aW5nIFJXIHRoZSByYW5nZSAzZmRjMDAwIC0gM2ZmZjAwMApbICAgIDAuMDAw
MDAwXSBSQU1ESVNLOiBbbWVtIDB4MDE2MTcwMDAtMHgwMmU3ZmZmZl0KWyAgICAwLjAwMDAwMF0g
MjMzOE1CIEhJR0hNRU0gYXZhaWxhYmxlLgpbICAgIDAuMDAwMDAwXSA3MjNNQiBMT1dNRU0gYXZh
aWxhYmxlLgpbICAgIDAuMDAwMDAwXSAgIG1hcHBlZCBsb3cgcmFtOiAwIC0gMmQzZmUwMDAKWyAg
ICAwLjAwMDAwMF0gICBsb3cgcmFtOiAwIC0gMmQzZmUwMDAKWyAgICAwLjAwMDAwMF0gWm9uZSBy
YW5nZXM6ClsgICAgMC4wMDAwMDBdICAgRE1BICAgICAgW21lbSAweDAwMDEwMDAwLTB4MDBmZmZm
ZmZdClsgICAgMC4wMDAwMDBdICAgTm9ybWFsICAgW21lbSAweDAxMDAwMDAwLTB4MmQzZmRmZmZd
ClsgICAgMC4wMDAwMDBdICAgSGlnaE1lbSAgW21lbSAweDJkM2ZlMDAwLTB4YmY2OThmZmZdClsg
ICAgMC4wMDAwMDBdIE1vdmFibGUgem9uZSBzdGFydCBmb3IgZWFjaCBub2RlClsgICAgMC4wMDAw
MDBdIEVhcmx5IG1lbW9yeSBub2RlIHJhbmdlcwpbICAgIDAuMDAwMDAwXSAgIG5vZGUgICAwOiBb
bWVtIDB4MDAwMTAwMDAtMHgwMDA5ZmZmZl0KWyAgICAwLjAwMDAwMF0gICBub2RlICAgMDogW21l
bSAweDAwMTAwMDAwLTB4YmY2OThmZmZdClsgICAgMC4wMDAwMDBdIE9uIG5vZGUgMCB0b3RhbHBh
Z2VzOiA3ODM5MTMKWyAgICAwLjAwMDAwMF0gICBETUEgem9uZTogMzIgcGFnZXMgdXNlZCBmb3Ig
bWVtbWFwClsgICAgMC4wMDAwMDBdICAgRE1BIHpvbmU6IDAgcGFnZXMgcmVzZXJ2ZWQKWyAgICAw
LjAwMDAwMF0gICBETUEgem9uZTogMzk1MiBwYWdlcywgTElGTyBiYXRjaDowClsgICAgMC4wMDAw
MDBdICAgTm9ybWFsIHpvbmU6IDE0MTYgcGFnZXMgdXNlZCBmb3IgbWVtbWFwClsgICAgMC4wMDAw
MDBdICAgTm9ybWFsIHpvbmU6IDE3OTgzMCBwYWdlcywgTElGTyBiYXRjaDozMQpbICAgIDAuMDAw
MDAwXSAgIEhpZ2hNZW0gem9uZTogNDY3OCBwYWdlcyB1c2VkIGZvciBtZW1tYXAKWyAgICAwLjAw
MDAwMF0gICBIaWdoTWVtIHpvbmU6IDU5NDAwNSBwYWdlcywgTElGTyBiYXRjaDozMQpbICAgIDAu
MDAwMDAwXSBVc2luZyBBUElDIGRyaXZlciBkZWZhdWx0ClsgICAgMC4wMDAwMDBdIHNtcGJvb3Q6
IEFsbG93aW5nIDQgQ1BVcywgMCBob3RwbHVnIENQVXMKWyAgICAwLjAwMDAwMF0gTG9jYWwgQVBJ
QyBkaXNhYmxlZCBieSBCSU9TIC0tIHlvdSBjYW4gZW5hYmxlIGl0IHdpdGggImxhcGljIgpbICAg
IDAuMDAwMDAwXSBBUElDOiBkaXNhYmxlIGFwaWMgZmFjaWxpdHkKWyAgICAwLjAwMDAwMF0gQVBJ
Qzogc3dpdGNoZWQgdG8gYXBpYyBOT09QClsgICAgMC4wMDAwMDBdIG5yX2lycXNfZ3NpOiAxNgpb
ICAgIDAuMDAwMDAwXSBlODIwOiBbbWVtIDB4YzAwMDAwMDAtMHhkZmZmZmZmZl0gYXZhaWxhYmxl
IGZvciBQQ0kgZGV2aWNlcwpbICAgIDAuMDAwMDAwXSBCb290aW5nIHBhcmF2aXJ0dWFsaXplZCBr
ZXJuZWwgb24gWGVuClsgICAgMC4wMDAwMDBdIFhlbiB2ZXJzaW9uOiA0LjIuMCAocHJlc2VydmUt
QUQpClsgICAgMC4wMDAwMDBdIHNldHVwX3BlcmNwdTogTlJfQ1BVUzo4IG5yX2NwdW1hc2tfYml0
czo4IG5yX2NwdV9pZHM6NCBucl9ub2RlX2lkczoxClsgICAgMC4wMDAwMDBdIFBFUkNQVTogRW1i
ZWRkZWQgMTIgcGFnZXMvY3B1IEBlYmJiYjAwMCBzMjY0MzIgcjAgZDIyNzIwIHU0OTE1MgpbICAg
IDAuMDAwMDAwXSBwY3B1LWFsbG9jOiBzMjY0MzIgcjAgZDIyNzIwIHU0OTE1MiBhbGxvYz0xMio0
MDk2ClsgICAgMC4wMDAwMDBdIHBjcHUtYWxsb2M6IFswXSAwIFswXSAxIFswXSAyIFswXSAzIApb
ICAgIDAuMDAwMDAwXSBCdWlsdCAxIHpvbmVsaXN0cyBpbiBab25lIG9yZGVyLCBtb2JpbGl0eSBn
cm91cGluZyBvbi4gIFRvdGFsIHBhZ2VzOiA3Nzc3ODcKWyAgICAwLjAwMDAwMF0gS2VybmVsIGNv
bW1hbmQgbGluZTogcm9vdD0vZGV2L3h2ZGExIHJvIGlvbW11PXNvZnQgcHJpbnRrLnByaW50a190
aW1lPTEgY29uc29sZT1odmMwClsgICAgMC4wMDAwMDBdIFBJRCBoYXNoIHRhYmxlIGVudHJpZXM6
IDQwOTYgKG9yZGVyOiAyLCAxNjM4NCBieXRlcykKWyAgICAwLjAwMDAwMF0gRGVudHJ5IGNhY2hl
IGhhc2ggdGFibGUgZW50cmllczogMTMxMDcyIChvcmRlcjogNywgNTI0Mjg4IGJ5dGVzKQpbICAg
IDAuMDAwMDAwXSBJbm9kZS1jYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDY1NTM2IChvcmRlcjog
NiwgMjYyMTQ0IGJ5dGVzKQpbICAgIDAuMDAwMDAwXSBfX2V4X3RhYmxlIGFscmVhZHkgc29ydGVk
LCBza2lwcGluZyBzb3J0ClsgICAgMC4wMDAwMDBdIEluaXRpYWxpemluZyBDUFUjMApbICAgIDAu
MDAwMDAwXSBzb2Z0d2FyZSBJTyBUTEIgW21lbSAweDI3YWY3MDAwLTB4MmJhZjZmZmZdICg2NE1C
KSBtYXBwZWQgYXQgW2U3YWY3MDAwLWViYWY2ZmZmXQpbICAgIDAuMDAwMDAwXSBJbml0aWFsaXpp
bmcgSGlnaE1lbSBmb3Igbm9kZSAwICgwMDAyZDNmZTowMDBiZjY5OSkKWyAgICAwLjAwMDAwMF0g
TWVtb3J5OiAzMDA3NTgway8zMTM2MTAwayBhdmFpbGFibGUgKDIzMDBrIGtlcm5lbCBjb2RlLCAx
MjgwNzJrIHJlc2VydmVkLCA5NDZrIGRhdGEsIDQwOGsgaW5pdCwgMjM5NDczMmsgaGlnaG1lbSkK
WyAgICAwLjAwMDAwMF0gdmlydHVhbCBrZXJuZWwgbWVtb3J5IGxheW91dDoKWyAgICAwLjAwMDAw
MF0gICAgIGZpeG1hcCAgOiAweGY1NzE2MDAwIC0gMHhmNTdmZjAwMCAgICggOTMyIGtCKQpbICAg
IDAuMDAwMDAwXSAgICAgcGttYXAgICA6IDB4ZjU0MDAwMDAgLSAweGY1NjAwMDAwICAgKDIwNDgg
a0IpClsgICAgMC4wMDAwMDBdICAgICB2bWFsbG9jIDogMHhlZGJmZTAwMCAtIDB4ZjUzZmUwMDAg
ICAoIDEyMCBNQikKWyAgICAwLjAwMDAwMF0gICAgIGxvd21lbSAgOiAweGMwMDAwMDAwIC0gMHhl
ZDNmZTAwMCAgICggNzIzIE1CKQpbICAgIDAuMDAwMDAwXSAgICAgICAuaW5pdCA6IDB4YzEzMmMw
MDAgLSAweGMxMzkyMDAwICAgKCA0MDgga0IpClsgICAgMC4wMDAwMDBdICAgICAgIC5kYXRhIDog
MHhjMTIzZjIxNiAtIDB4YzEzMmJkYzAgICAoIDk0NiBrQikKWyAgICAwLjAwMDAwMF0gICAgICAg
LnRleHQgOiAweGMxMDAwMDAwIC0gMHhjMTIzZjIxNiAgICgyMzAwIGtCKQpbICAgIDAuMDAwMDAw
XSBIaWVyYXJjaGljYWwgUkNVIGltcGxlbWVudGF0aW9uLgpbICAgIDAuMDAwMDAwXSAJUkNVIHJl
c3RyaWN0aW5nIENQVXMgZnJvbSBOUl9DUFVTPTggdG8gbnJfY3B1X2lkcz00LgpbICAgIDAuMDAw
MDAwXSBOUl9JUlFTOjIzMDQgbnJfaXJxczozMDQgMTYKWyAgICAwLjAwMDAwMF0gQ1BVIDAgaXJx
c3RhY2tzLCBoYXJkPWU3NDA4MDAwIHNvZnQ9ZTc0MGEwMDAKWyAgICAwLjAwMDAwMF0gQ29uc29s
ZTogY29sb3VyIGR1bW15IGRldmljZSA4MHgyNQpbICAgIDAuMDAwMDAwXSBjb25zb2xlIFt0dHkw
XSBlbmFibGVkClsgICAgMC4wMDAwMDBdIGNvbnNvbGUgW2h2YzBdIGVuYWJsZWQKWyAgICAwLjAw
MDAwMF0gWGVuOiB1c2luZyB2Y3B1b3AgdGltZXIgaW50ZXJmYWNlClsgICAgMC4wMDAwMDBdIGlu
c3RhbGxpbmcgWGVuIHRpbWVyIGZvciBDUFUgMApbICAgIDAuMDAwMDAwXSB0c2M6IERldGVjdGVk
IDIyNjEuMDgyIE1IeiBwcm9jZXNzb3IKWyAgICAwLjAwMDk5OV0gQ2FsaWJyYXRpbmcgZGVsYXkg
bG9vcCAoc2tpcHBlZCksIHZhbHVlIGNhbGN1bGF0ZWQgdXNpbmcgdGltZXIgZnJlcXVlbmN5Li4g
NDUyMi4xNiBCb2dvTUlQUyAobHBqPTIyNjEwODIpClsgICAgMC4wMDA5OTldIHBpZF9tYXg6IGRl
ZmF1bHQ6IDMyNzY4IG1pbmltdW06IDMwMQpbICAgIDAuMDAwOTk5XSBTZWN1cml0eSBGcmFtZXdv
cmsgaW5pdGlhbGl6ZWQKWyAgICAwLjAwMDk5OV0gTW91bnQtY2FjaGUgaGFzaCB0YWJsZSBlbnRy
aWVzOiA1MTIKWyAgICAwLjAwMDk5OV0gQ1BVOiBQaHlzaWNhbCBQcm9jZXNzb3IgSUQ6IDAKWyAg
ICAwLjAwMDk5OV0gQ1BVOiBQcm9jZXNzb3IgQ29yZSBJRDogMApbICAgIDAuMDAwOTk5XSBMYXN0
IGxldmVsIGlUTEIgZW50cmllczogNEtCIDUxMiwgMk1CIDcsIDRNQiA3ClsgICAgMC4wMDA5OTld
IExhc3QgbGV2ZWwgZFRMQiBlbnRyaWVzOiA0S0IgNTEyLCAyTUIgMzIsIDRNQiAzMgpbICAgIDAu
MDAwOTk5XSB0bGJfZmx1c2hhbGxfc2hpZnQgaXMgMHg2ClsgICAgMC4wMDA5OTldIFNNUCBhbHRl
cm5hdGl2ZXM6IHN3aXRjaGluZyB0byBVUCBjb2RlClsgICAgMC4wMjQ2ODNdIFBlcmZvcm1hbmNl
IEV2ZW50czogdW5zdXBwb3J0ZWQgcDYgQ1BVIG1vZGVsIDI2IG5vIFBNVSBkcml2ZXIsIHNvZnR3
YXJlIGV2ZW50cyBvbmx5LgpbICAgIDAuMDI0ODQzXSBDUFUgMSBpcnFzdGFja3MsIGhhcmQ9ZTc0
N2EwMDAgc29mdD1lNzQ3YzAwMApbICAgIDAuMDI0ODQ2XSBpbnN0YWxsaW5nIFhlbiB0aW1lciBm
b3IgQ1BVIDEKWyAgICAwLjAyNDg4MV0gU01QIGFsdGVybmF0aXZlczogc3dpdGNoaW5nIHRvIFNN
UCBjb2RlClsgICAgMC4wMDA5OTldIEluaXRpYWxpemluZyBDUFUjMQpbICAgIDAuMDQ5MjYwXSBD
UFUgMiBpcnFzdGFja3MsIGhhcmQ9ZTc0YTYwMDAgc29mdD1lNzRhODAwMApbICAgIDAuMDQ5MjY4
XSBpbnN0YWxsaW5nIFhlbiB0aW1lciBmb3IgQ1BVIDIKWyAgICAwLjAwMDk5OV0gSW5pdGlhbGl6
aW5nIENQVSMyClsgICAgMC4wNTAyODddIENQVSAzIGlycXN0YWNrcywgaGFyZD1lNzRiNDAwMCBz
b2Z0PWU3NGI2MDAwClsgICAgMC4wNTAyOTVdIGluc3RhbGxpbmcgWGVuIHRpbWVyIGZvciBDUFUg
MwpbICAgIDAuMDAwOTk5XSBJbml0aWFsaXppbmcgQ1BVIzMKWyAgICAwLjA1MDQzMl0gQnJvdWdo
dCB1cCA0IENQVXMKWyAgICAwLjA1MDc1MV0gR3JhbnQgdGFibGVzIHVzaW5nIHZlcnNpb24gMiBs
YXlvdXQuClsgICAgMC4wNTA3ODZdIEdyYW50IHRhYmxlIGluaXRpYWxpemVkClsgICAgMC4wNTA4
NDddIE5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMTYKWyAgICAwLjA1MTg1NF0gUENJ
OiBzZXR0aW5nIHVwIFhlbiBQQ0kgZnJvbnRlbmQgc3R1YgpbICAgIDAuMDUxODYxXSBQQ0k6IHBj
aV9jYWNoZV9saW5lX3NpemUgc2V0IHRvIDY0IGJ5dGVzClsgICAgMC4wNTQxNDhdIGJpbzogY3Jl
YXRlIHNsYWIgPGJpby0wPiBhdCAwClsgICAgMC4wNTQzMTNdIEFDUEk6IEludGVycHJldGVyIGRp
c2FibGVkLgpbICAgIDAuMDU0NjQwXSB4ZW4vYmFsbG9vbjogSW5pdGlhbGlzaW5nIGJhbGxvb24g
ZHJpdmVyLgpbICAgIDAuMDU2MjMxXSB4ZW4tYmFsbG9vbjogSW5pdGlhbGlzaW5nIGJhbGxvb24g
ZHJpdmVyLgpbICAgIDAuMDU2NDczXSB2Z2FhcmI6IGxvYWRlZApbICAgIDAuMDU2NjUyXSBQQ0k6
IFN5c3RlbSBkb2VzIG5vdCBzdXBwb3J0IFBDSQpbICAgIDAuMDU2NjUyXSBQQ0k6IFN5c3RlbSBk
b2VzIG5vdCBzdXBwb3J0IFBDSQpbICAgIDAuMDU2ODUyXSBTd2l0Y2hpbmcgdG8gY2xvY2tzb3Vy
Y2UgeGVuClsgICAgMC4wNTY5OTFdIHBucDogUG5QIEFDUEk6IGRpc2FibGVkClsgICAgMC4wNTk3
MDhdIE5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMgpbICAgIDAuMDU5ODc0XSBUQ1Ag
ZXN0YWJsaXNoZWQgaGFzaCB0YWJsZSBlbnRyaWVzOiAxMzEwNzIgKG9yZGVyOiA4LCAxMDQ4NTc2
IGJ5dGVzKQpbICAgIDAuMDYwMTQ3XSBUQ1AgYmluZCBoYXNoIHRhYmxlIGVudHJpZXM6IDY1NTM2
IChvcmRlcjogNywgNTI0Mjg4IGJ5dGVzKQpbICAgIDAuMDYwMjYwXSBUQ1A6IEhhc2ggdGFibGVz
IGNvbmZpZ3VyZWQgKGVzdGFibGlzaGVkIDEzMTA3MiBiaW5kIDY1NTM2KQpbICAgIDAuMDYwMjc3
XSBUQ1A6IHJlbm8gcmVnaXN0ZXJlZApbICAgIDAuMDYwMjgzXSBVRFAgaGFzaCB0YWJsZSBlbnRy
aWVzOiA1MTIgKG9yZGVyOiAyLCAxNjM4NCBieXRlcykKWyAgICAwLjA2MDI5MV0gVURQLUxpdGUg
aGFzaCB0YWJsZSBlbnRyaWVzOiA1MTIgKG9yZGVyOiAyLCAxNjM4NCBieXRlcykKWyAgICAwLjA2
MDM1OV0gTkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAxClsgICAgMC4wNjAzNjldIFBD
STogQ0xTIDAgYnl0ZXMsIGRlZmF1bHQgNjQKWyAgICAwLjA2MDM5OV0gVHJ5aW5nIHRvIHVucGFj
ayByb290ZnMgaW1hZ2UgYXMgaW5pdHJhbWZzLi4uClsgICAgMC4xMTIyMDldIEZyZWVpbmcgaW5p
dHJkIG1lbW9yeTogMjQ5OTZrIGZyZWVkClsgICAgMC4xMTcxMjNdIHBsYXRmb3JtIHJ0Y19jbW9z
OiByZWdpc3RlcmVkIHBsYXRmb3JtIFJUQyBkZXZpY2UgKG5vIFBOUCBkZXZpY2UgZm91bmQpClsg
ICAgMC4xMTc1OTldIG1pY3JvY29kZTogQ1BVMCBzaWc9MHgxMDZhNSwgcGY9MHgxLCByZXZpc2lv
bj0weDExClsgICAgMC4xMTc2MTFdIG1pY3JvY29kZTogQ1BVMSBzaWc9MHgxMDZhNSwgcGY9MHgx
LCByZXZpc2lvbj0weDExClsgICAgMC4xMTc2MjddIG1pY3JvY29kZTogQ1BVMiBzaWc9MHgxMDZh
NSwgcGY9MHgxLCByZXZpc2lvbj0weDExClsgICAgMC4xMTc2NDRdIG1pY3JvY29kZTogQ1BVMyBz
aWc9MHgxMDZhNSwgcGY9MHgxLCByZXZpc2lvbj0weDExClsgICAgMC4xMTc3MDJdIG1pY3JvY29k
ZTogTWljcm9jb2RlIFVwZGF0ZSBEcml2ZXI6IHYyLjAwIDx0aWdyYW5AYWl2YXppYW4uZnNuZXQu
Y28udWs+LCBQZXRlciBPcnViYQpbICAgIDAuMTE3OTIyXSBhdWRpdDogaW5pdGlhbGl6aW5nIG5l
dGxpbmsgc29ja2V0IChkaXNhYmxlZCkKWyAgICAwLjExNzkzNl0gdHlwZT0yMDAwIGF1ZGl0KDEz
NTEwODY0MTAuMzI1OjEpOiBpbml0aWFsaXplZApbICAgIDAuMTE4MzM0XSBib3VuY2UgcG9vbCBz
aXplOiA2NCBwYWdlcwpbICAgIDAuMTE4NDM5XSBWRlM6IERpc2sgcXVvdGFzIGRxdW90XzYuNS4y
ClsgICAgMC4xOTcxNjRdIERxdW90LWNhY2hlIGhhc2ggdGFibGUgZW50cmllczogMTAyNCAob3Jk
ZXIgMCwgNDA5NiBieXRlcykKWyAgICAwLjE5NzIyN10gbXNnbW5pIGhhcyBiZWVuIHNldCB0byAx
MjQ1ClsgICAgMC4xOTc0MDFdIEJsb2NrIGxheWVyIFNDU0kgZ2VuZXJpYyAoYnNnKSBkcml2ZXIg
dmVyc2lvbiAwLjQgbG9hZGVkIChtYWpvciAyNTMpClsgICAgMC4xOTc0MTBdIGlvIHNjaGVkdWxl
ciBub29wIHJlZ2lzdGVyZWQKWyAgICAwLjE5NzQxNV0gaW8gc2NoZWR1bGVyIGRlYWRsaW5lIHJl
Z2lzdGVyZWQKWyAgICAwLjE5NzQzNl0gaW8gc2NoZWR1bGVyIGNmcSByZWdpc3RlcmVkIChkZWZh
dWx0KQpbICAgIDAuMjAwNjkyXSBwY2lmcm9udCBwY2ktMDogYmFja2VuZCBnb2luZyBhd2F5IQpb
ICAgIDAuMjAwNzg2XSBFdmVudC1jaGFubmVsIGRldmljZSBpbnN0YWxsZWQuClsgICAgMC4yMjQy
NTldIEZsb3BweSBkcml2ZShzKTogZmQwIGlzIHVua25vd24gdHlwZSAxNSAodXNiPyksIGZkMSBp
cyB1bmtub3duIHR5cGUgMTUgKHVzYj8pClsgICAgMC4yMjQyNzRdIGZsb3BweTA6IFVuYWJsZSB0
byBncmFiIElSUTYgZm9yIHRoZSBmbG9wcHkgZHJpdmVyClsgICAgMC4yMjU5NDNdIGJyZDogbW9k
dWxlIGxvYWRlZApbICAgIDAuMjI2OTI5XSBsb29wOiBtb2R1bGUgbG9hZGVkClsgICAgMC4yMzk2
MTFdIFVuaWZvcm0gTXVsdGktUGxhdGZvcm0gRS1JREUgZHJpdmVyClsgICAgMC4yMzk4MzJdIGlk
ZS1nZCBkcml2ZXIgMS4xOApbICAgIDAuMjM5ODgxXSBJbml0aWFsaXNpbmcgWGVuIHZpcnR1YWwg
ZXRoZXJuZXQgZHJpdmVyLgpbICAgIDAuMjQxODczXSBibGtmcm9udDogeHZkYTE6IGJhcnJpZXIg
b3IgZmx1c2g6IGRpc2FibGVkClsgICAgMC4yNDU4NTVdIGJsa2Zyb250OiB4dmRiOiBiYXJyaWVy
IG9yIGZsdXNoOiBkaXNhYmxlZApbICAgIDAuMjQ2MTc5XSBpODA0MjogUE5QOiBObyBQUy8yIGNv
bnRyb2xsZXIgZm91bmQuIFByb2JpbmcgcG9ydHMgZGlyZWN0bHkuClsgICAgMC4yNDcwMDZdIGk4
MDQyOiBObyBjb250cm9sbGVyIGZvdW5kClsgICAgMC4yNDcwMDhdICB4dmRiOgpbICAgIDAuMjQ3
MTM4XSBtb3VzZWRldjogUFMvMiBtb3VzZSBkZXZpY2UgY29tbW9uIGZvciBhbGwgbWljZQpbICAg
IDAuMjQ3MzM5XSBTZXR0aW5nIGNhcGFjaXR5IHRvIDI4NTQ3NDgxNgpbICAgIDAuMjQ3MzUwXSB4
dmRiOiBkZXRlY3RlZCBjYXBhY2l0eSBjaGFuZ2UgZnJvbSAwIHRvIDE0NjE2MzEwNTc5MgpbICAg
IDAuMjQ3NTQxXSBORVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDE3ClsgICAgMC4yNDc1
NzddIFVzaW5nIElQSSBOby1TaG9ydGN1dCBtb2RlClsgICAgMC4yNDc3MjhdIHJlZ2lzdGVyZWQg
dGFza3N0YXRzIHZlcnNpb24gMQpbICAgIDAuMzQ3MTI2XSBCSU9TIEVERCBmYWNpbGl0eSB2MC4x
NiAyMDA0LUp1bi0yNSwgMCBkZXZpY2VzIGZvdW5kClsgICAgMC4zNDcxMzZdIEVERCBpbmZvcm1h
dGlvbiBub3QgYXZhaWxhYmxlLgpbICAgIDAuMzQ3MzcyXSBGcmVlaW5nIHVudXNlZCBrZXJuZWwg
bWVtb3J5OiA0MDhrIGZyZWVkClsgICAgMC4zNzM1ODJdIGRyYWN1dDogZHJhY3V0LTAwNC0yNTYu
ZWw2ClsgICAgMC4zOTAzMThdIGRldmljZS1tYXBwZXI6IGlvY3RsOiA0LjIzLjAtaW9jdGwgKDIw
MTItMDctMjUpIGluaXRpYWxpc2VkOiBkbS1kZXZlbEByZWRoYXQuY29tClsgICAgMC4zOTU1MTld
IHVkZXY6IHN0YXJ0aW5nIHZlcnNpb24gMTQ3ClsgICAgMC4zOTU1NjhdIHVkZXZkICg4ODUpOiAv
cHJvYy84ODUvb29tX2FkaiBpcyBkZXByZWNhdGVkLCBwbGVhc2UgdXNlIC9wcm9jLzg4NS9vb21f
c2NvcmVfYWRqIGluc3RlYWQuClsgICAgMC40OTAxODddIGRyYWN1dDogU3RhcnRpbmcgcGx5bW91
dGggZGFlbW9uClsgICAgMC42MzI4NzRdIEVYVDQtZnMgKHh2ZGExKTogbW91bnRlZCBmaWxlc3lz
dGVtIHdpdGggb3JkZXJlZCBkYXRhIG1vZGUuIE9wdHM6IChudWxsKQpbICAgIDAuNjcyNjU1XSBk
cmFjdXQ6IE1vdW50ZWQgcm9vdCBmaWxlc3lzdGVtIC9kZXYveHZkYTEKWyAgICAwLjg3NTgzMV0g
ZHJhY3V0OiAvc2Jpbi9sb2FkX3BvbGljeTogQ2FuJ3QgbG9hZCBwb2xpY3k6IE5vIHN1Y2ggZGV2
aWNlClsgICAgMC45MDQyNjldIGRyYWN1dDogU3dpdGNoaW5nIHJvb3QKWyAgICAxLjIzNDY5Nl0g
dXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciB1c2JmcwpbICAgIDEuMjM0
NzQ4XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIGh1YgpbICAgIDEu
MjM0ODQ1XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBkZXZpY2UgZHJpdmVyIHVzYgpbICAgIDEu
NzQ0NTkyXSB1ZGV2OiBzdGFydGluZyB2ZXJzaW9uIDE0NwpbICAgIDEuODk2MDg0XSBpbnB1dDog
UEMgU3BlYWtlciBhcyAvZGV2aWNlcy9wbGF0Zm9ybS9wY3Nwa3IvaW5wdXQvaW5wdXQwClsgICAg
Mi40NTU1NzZdIEVYVDQtZnMgKHh2ZGExKTogcmUtbW91bnRlZC4gT3B0czogKG51bGwpClsgICAg
Mi44MjExODRdIE5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMTAKWyAgICAyLjgzNzM2
MV0gaXA2X3RhYmxlczogKEMpIDIwMDAtMjAwNiBOZXRmaWx0ZXIgQ29yZSBUZWFtClsgICAgMi45
NTUyNzRdIGlwX3RhYmxlczogKEMpIDIwMDAtMjAwNiBOZXRmaWx0ZXIgQ29yZSBUZWFtCg==

--_005_E71FC5D6F96C3C4B93FC8FF942D924C682F45DE3SBJEXCH1Bwebsen_
Content-Type: application/octet-stream; name="domainWCG.cfg"
Content-Description: domainWCG.cfg
Content-Disposition: attachment; filename="domainWCG.cfg"; size=369;
	creation-date="Mon, 22 Oct 2012 10:09:56 GMT";
	modification-date="Wed, 24 Oct 2012 13:45:52 GMT"
Content-Transfer-Encoding: base64

a2VybmVsID0gIi9yb290L2RvbWFpbldDRy5rZXJuZWwiDQpyYW1kaXNrID0gIi9yb290L2RvbWFp
bldDRy5pbml0cmQuaW1nIg0KZTgyMF9ob3N0PTENCm1lbW9yeT02MTQ0DQpuYW1lID0gIndjZyIN
CnZpZiAgPSBbICdpcD0xNjkuMjU0LjI1NC4zLHZpZm5hbWU9d2NnLjAnIF0NCmRpc2sgPSBbJ3Bo
eTovZGV2L2x2X2FwcGxpYW5jZS93Y2cseHZkYTEsdycsDQogICAgICAgICdwaHk6L2Rldi9zZGIs
eHZkYix3J10NCnJvb3QgID0gIi9kZXYveHZkYTEgcm8iDQpleHRyYT0iaW9tbXU9c29mdCBwcmlu
dGsucHJpbnRrX3RpbWU9MSBjb25zb2xlPWh2YzAiDQpwY2k9WycwMTowMC4wJywnMDE6MDAuMSdd
DQp2Y3B1cz00DQpjcHVzPSI0LDUsNiw3Ig0K

--_005_E71FC5D6F96C3C4B93FC8FF942D924C682F45DE3SBJEXCH1Bwebsen_
Content-Type: application/octet-stream; name="xl-create.output"
Content-Description: xl-create.output
Content-Disposition: attachment; filename="xl-create.output"; size=12062;
	creation-date="Mon, 22 Oct 2012 10:09:56 GMT";
	modification-date="Wed, 24 Oct 2012 13:56:50 GMT"
Content-Transfer-Encoding: base64

W3Jvb3RAbG9jYWxob3N0IH5dIyB4bCAtdnZ2IGNyZWF0ZSBkb21haW5XQ0cuY2ZnIApQYXJzaW5n
IGNvbmZpZyBmcm9tIGRvbWFpbldDRy5jZmcKbGlieGw6IGRlYnVnOiBsaWJ4bF9jcmVhdGUuYzox
MTczOmRvX2RvbWFpbl9jcmVhdGU6IGFvIDB4ODA2YmVmMDogY3JlYXRlOiBob3c9KG5pbCkgY2Fs
bGJhY2s9KG5pbCkgcG9sbGVyPTB4ODA2YjY4OApsaWJ4bDogZGVidWc6IGxpYnhsX2RldmljZS5j
OjIyOTpsaWJ4bF9fZGV2aWNlX2Rpc2tfc2V0X2JhY2tlbmQ6IERpc2sgdmRldj14dmRhMSBzcGVj
LmJhY2tlbmQ9dW5rbm93bgpsaWJ4bDogZGVidWc6IGxpYnhsX2RldmljZS5jOjI2NTpsaWJ4bF9f
ZGV2aWNlX2Rpc2tfc2V0X2JhY2tlbmQ6IERpc2sgdmRldj14dmRhMSwgdXNpbmcgYmFja2VuZCBw
aHkKbGlieGw6IGRlYnVnOiBsaWJ4bF9kZXZpY2UuYzoyMjk6bGlieGxfX2RldmljZV9kaXNrX3Nl
dF9iYWNrZW5kOiBEaXNrIHZkZXY9eHZkYiBzcGVjLmJhY2tlbmQ9dW5rbm93bgpsaWJ4bDogZGVi
dWc6IGxpYnhsX2RldmljZS5jOjI2NTpsaWJ4bF9fZGV2aWNlX2Rpc2tfc2V0X2JhY2tlbmQ6IERp
c2sgdmRldj14dmRiLCB1c2luZyBiYWNrZW5kIHBoeQpsaWJ4bDogZGVidWc6IGxpYnhsX2NyZWF0
ZS5jOjY3Nzppbml0aWF0ZV9kb21haW5fY3JlYXRlOiBydW5uaW5nIGJvb3Rsb2FkZXIKbGlieGw6
IGRlYnVnOiBsaWJ4bF9ib290bG9hZGVyLmM6MzI3OmxpYnhsX19ib290bG9hZGVyX3J1bjogbm8g
Ym9vdGxvYWRlciBjb25maWd1cmVkLCB1c2luZyB1c2VyIHN1cHBsaWVkIGtlcm5lbApsaWJ4bDog
ZGVidWc6IGxpYnhsX2V2ZW50LmM6NTYxOmxpYnhsX19ldl94c3dhdGNoX2RlcmVnaXN0ZXI6IHdh
dGNoIHc9MHg4MDZjMGRjOiBkZXJlZ2lzdGVyIHVucmVnaXN0ZXJlZApkb21haW5idWlsZGVyOiBk
ZXRhaWw6IHhjX2RvbV9hbGxvY2F0ZTogY21kbGluZT0icm9vdD0vZGV2L3h2ZGExIHJvIGlvbW11
PXNvZnQgcHJpbnRrLnByaW50a190aW1lPTEgY29uc29sZT1odmMwIiwgZmVhdHVyZXM9IihudWxs
KSIKbGlieGw6IGRlYnVnOiBsaWJ4bF9kb20uYzozODA6bGlieGxfX2J1aWxkX3B2OiBwdiBrZXJu
ZWwgbWFwcGVkIDAgcGF0aCAvcm9vdC9kb21haW5XQ0cua2VybmVsCgpkb21haW5idWlsZGVyOiBk
ZXRhaWw6IHhjX2RvbV9rZXJuZWxfZmlsZTogZmlsZW5hbWU9Ii9yb290L2RvbWFpbldDRy5rZXJu
ZWwiCmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogeGNfZG9tX21hbGxvY19maWxlbWFwICAgIDogMjA5
NyBrQgpkb21haW5idWlsZGVyOiBkZXRhaWw6IHhjX2RvbV9yYW1kaXNrX2ZpbGU6IGZpbGVuYW1l
PSIvcm9vdC9kb21haW5XQ0cuaW5pdHJkLmltZyIKZG9tYWluYnVpbGRlcjogZGV0YWlsOiB4Y19k
b21fbWFsbG9jX2ZpbGVtYXAgICAgOiAxMDUzMyBrQgpkb21haW5idWlsZGVyOiBkZXRhaWw6IHhj
X2RvbV9ib290X3hlbl9pbml0OiB2ZXIgNC4yLCBjYXBzIHhlbi0zLjAteDg2XzY0IHhlbi0zLjAt
eDg2XzMycCBodm0tMy4wLXg4Nl8zMiBodm0tMy4wLXg4Nl8zMnAgaHZtLTMuMC14ODZfNjQgCmRv
bWFpbmJ1aWxkZXI6IGRldGFpbDogeGNfZG9tX3BhcnNlX2ltYWdlOiBjYWxsZWQKZG9tYWluYnVp
bGRlcjogZGV0YWlsOiB4Y19kb21fZmluZF9sb2FkZXI6IHRyeWluZyBFTEYtZ2VuZXJpYyBsb2Fk
ZXIgLi4uIApkb21haW5idWlsZGVyOiBkZXRhaWw6IGxvYWRlciBwcm9iZSBmYWlsZWQKZG9tYWlu
YnVpbGRlcjogZGV0YWlsOiB4Y19kb21fZmluZF9sb2FkZXI6IHRyeWluZyBMaW51eCBiekltYWdl
IGxvYWRlciAuLi4gCmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogeGNfZG9tX21hbGxvYyAgICAgICAg
ICAgIDogNDA3MyBrQgpkb21haW5idWlsZGVyOiBkZXRhaWw6IHhjX2RvbV9kb19ndW56aXA6IHVu
emlwIG9rLCAweDIwNDQ4ZiAtPiAweDNmYTViYwpkb21haW5idWlsZGVyOiBkZXRhaWw6IGxvYWRl
ciBwcm9iZSBPSwp4YzogZGV0YWlsOiBlbGZfcGFyc2VfYmluYXJ5OiBwaGRyOiBwYWRkcj0weDEw
MDAwMDAgbWVtc3o9MHgzMDQwMDAKeGM6IGRldGFpbDogZWxmX3BhcnNlX2JpbmFyeTogcGhkcjog
cGFkZHI9MHgxMzA0MDAwIG1lbXN6PTB4MzEzMDAwCnhjOiBkZXRhaWw6IGVsZl9wYXJzZV9iaW5h
cnk6IG1lbW9yeTogMHgxMDAwMDAwIC0+IDB4MTYxNzAwMAp4YzogZGV0YWlsOiBlbGZfeGVuX3Bh
cnNlX25vdGU6IEdVRVNUX09TID0gImxpbnV4Igp4YzogZGV0YWlsOiBlbGZfeGVuX3BhcnNlX25v
dGU6IEdVRVNUX1ZFUlNJT04gPSAiMi42Igp4YzogZGV0YWlsOiBlbGZfeGVuX3BhcnNlX25vdGU6
IFhFTl9WRVJTSU9OID0gInhlbi0zLjAiCnhjOiBkZXRhaWw6IGVsZl94ZW5fcGFyc2Vfbm90ZTog
VklSVF9CQVNFID0gMHhjMDAwMDAwMAp4YzogZGV0YWlsOiBlbGZfeGVuX3BhcnNlX25vdGU6IEVO
VFJZID0gMHhjMTMyYzIyYwp4YzogZGV0YWlsOiBlbGZfeGVuX3BhcnNlX25vdGU6IEhZUEVSQ0FM
TF9QQUdFID0gMHhjMTAwMjAwMAp4YzogZGV0YWlsOiBlbGZfeGVuX3BhcnNlX25vdGU6IEZFQVRV
UkVTID0gIiF3cml0YWJsZV9wYWdlX3RhYmxlc3xwYWVfcGdkaXJfYWJvdmVfNGdiIgp4YzogZGV0
YWlsOiBlbGZfeGVuX3BhcnNlX25vdGU6IFBBRV9NT0RFID0gInllcyIKeGM6IGRldGFpbDogZWxm
X3hlbl9wYXJzZV9ub3RlOiBMT0FERVIgPSAiZ2VuZXJpYyIKeGM6IGRldGFpbDogZWxmX3hlbl9w
YXJzZV9ub3RlOiB1bmtub3duIHhlbiBlbGYgbm90ZSAoMHhkKQp4YzogZGV0YWlsOiBlbGZfeGVu
X3BhcnNlX25vdGU6IFNVU1BFTkRfQ0FOQ0VMID0gMHgxCnhjOiBkZXRhaWw6IGVsZl94ZW5fcGFy
c2Vfbm90ZTogSFZfU1RBUlRfTE9XID0gMHhmNTgwMDAwMAp4YzogZGV0YWlsOiBlbGZfeGVuX3Bh
cnNlX25vdGU6IFBBRERSX09GRlNFVCA9IDB4MAp4YzogZGV0YWlsOiBlbGZfeGVuX2FkZHJfY2Fs
Y19jaGVjazogYWRkcmVzc2VzOgp4YzogZGV0YWlsOiAgICAgdmlydF9iYXNlICAgICAgICA9IDB4
YzAwMDAwMDAKeGM6IGRldGFpbDogICAgIGVsZl9wYWRkcl9vZmZzZXQgPSAweDAKeGM6IGRldGFp
bDogICAgIHZpcnRfb2Zmc2V0ICAgICAgPSAweGMwMDAwMDAwCnhjOiBkZXRhaWw6ICAgICB2aXJ0
X2tzdGFydCAgICAgID0gMHhjMTAwMDAwMAp4YzogZGV0YWlsOiAgICAgdmlydF9rZW5kICAgICAg
ICA9IDB4YzE2MTcwMDAKeGM6IGRldGFpbDogICAgIHZpcnRfZW50cnkgICAgICAgPSAweGMxMzJj
MjJjCnhjOiBkZXRhaWw6ICAgICBwMm1fYmFzZSAgICAgICAgID0gMHhmZmZmZmZmZmZmZmZmZmZm
CmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogeGNfZG9tX3BhcnNlX2VsZl9rZXJuZWw6IHhlbi0zLjAt
eDg2XzMycDogMHhjMTAwMDAwMCAtPiAweGMxNjE3MDAwCmRvbWFpbmJ1aWxkZXI6IGRldGFpbDog
eGNfZG9tX21lbV9pbml0OiBtZW0gNjE0NCBNQiwgcGFnZXMgMHgxODAwMDAgcGFnZXMsIDRrIGVh
Y2gKZG9tYWluYnVpbGRlcjogZGV0YWlsOiB4Y19kb21fbWVtX2luaXQ6IDB4MTgwMDAwIHBhZ2Vz
CmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogeGNfZG9tX2Jvb3RfbWVtX2luaXQ6IGNhbGxlZApkb21h
aW5idWlsZGVyOiBkZXRhaWw6IHg4Nl9jb21wYXQ6IGd1ZXN0IHhlbi0zLjAteDg2XzMycCwgYWRk
cmVzcyBzaXplIDMyCmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogeGNfZG9tX21hbGxvYyAgICAgICAg
ICAgIDogNjE0NCBrQgpkb21haW5idWlsZGVyOiBkZXRhaWw6IHhjX2RvbV9idWlsZF9pbWFnZTog
Y2FsbGVkCmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogeGNfZG9tX2FsbG9jX3NlZ21lbnQ6ICAga2Vy
bmVsICAgICAgIDogMHhjMTAwMDAwMCAtPiAweGMxNjE3MDAwICAocGZuIDB4MTAwMCArIDB4NjE3
IHBhZ2VzKQpkb21haW5idWlsZGVyOiBkZXRhaWw6IHhjX2RvbV9wZm5fdG9fcHRyOiBkb21VIG1h
cHBpbmc6IHBmbiAweDEwMDArMHg2MTcgYXQgMHhiNWI4MTAwMAp4YzogZGV0YWlsOiBlbGZfbG9h
ZF9iaW5hcnk6IHBoZHIgMCBhdCAweDB4YjViODEwMDAgLT4gMHgweGI1ZTg1MDAwCnhjOiBkZXRh
aWw6IGVsZl9sb2FkX2JpbmFyeTogcGhkciAxIGF0IDB4MHhiNWU4NTAwMCAtPiAweDB4YjVmMTcw
MDAKZG9tYWluYnVpbGRlcjogZGV0YWlsOiB4Y19kb21fYWxsb2Nfc2VnbWVudDogICByYW1kaXNr
ICAgICAgOiAweGMxNjE3MDAwIC0+IDB4YzJlODAwMDAgIChwZm4gMHgxNjE3ICsgMHgxODY5IHBh
Z2VzKQpkb21haW5idWlsZGVyOiBkZXRhaWw6IHhjX2RvbV9tYWxsb2MgICAgICAgICAgICA6IDE0
NiBrQgpkb21haW5idWlsZGVyOiBkZXRhaWw6IHhjX2RvbV9wZm5fdG9fcHRyOiBkb21VIG1hcHBp
bmc6IHBmbiAweDE2MTcrMHgxODY5IGF0IDB4YjQyZjMwMDAKZG9tYWluYnVpbGRlcjogZGV0YWls
OiB4Y19kb21fZG9fZ3VuemlwOiB1bnppcCBvaywgMHhhNDk1NTMgLT4gMHgxODY4NDEwCmRvbWFp
bmJ1aWxkZXI6IGRldGFpbDogeGNfZG9tX2FsbG9jX3NlZ21lbnQ6ICAgcGh5czJtYWNoICAgIDog
MHhjMmU4MDAwMCAtPiAweGMzNDgwMDAwICAocGZuIDB4MmU4MCArIDB4NjAwIHBhZ2VzKQpkb21h
aW5idWlsZGVyOiBkZXRhaWw6IHhjX2RvbV9wZm5fdG9fcHRyOiBkb21VIG1hcHBpbmc6IHBmbiAw
eDJlODArMHg2MDAgYXQgMHhiM2NmMzAwMApkb21haW5idWlsZGVyOiBkZXRhaWw6IHhjX2RvbV9h
bGxvY19wYWdlICAgOiAgIHN0YXJ0IGluZm8gICA6IDB4YzM0ODAwMDAgKHBmbiAweDM0ODApCmRv
bWFpbmJ1aWxkZXI6IGRldGFpbDogeGNfZG9tX2FsbG9jX3BhZ2UgICA6ICAgeGVuc3RvcmUgICAg
IDogMHhjMzQ4MTAwMCAocGZuIDB4MzQ4MSkKZG9tYWluYnVpbGRlcjogZGV0YWlsOiB4Y19kb21f
YWxsb2NfcGFnZSAgIDogICBjb25zb2xlICAgICAgOiAweGMzNDgyMDAwIChwZm4gMHgzNDgyKQpk
b21haW5idWlsZGVyOiBkZXRhaWw6IG5yX3BhZ2VfdGFibGVzOiAweDAwMDAwMDAwZmZmZmZmZmYv
MzI6IDB4MDAwMDAwMDAwMDAwMDAwMCAtPiAweGZmZmZmZmZmZmZmZmZmZmYsIDEgdGFibGUocykK
ZG9tYWluYnVpbGRlcjogZGV0YWlsOiBucl9wYWdlX3RhYmxlczogMHgwMDAwMDAwMDNmZmZmZmZm
LzMwOiAweDAwMDAwMDAwYzAwMDAwMDAgLT4gMHgwMDAwMDAwMGZmZmZmZmZmLCAxIHRhYmxlKHMp
CmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogbnJfcGFnZV90YWJsZXM6IDB4MDAwMDAwMDAwMDFmZmZm
Zi8yMTogMHgwMDAwMDAwMGMwMDAwMDAwIC0+IDB4MDAwMDAwMDBjMzdmZmZmZiwgMjggdGFibGUo
cykKZG9tYWluYnVpbGRlcjogZGV0YWlsOiB4Y19kb21fYWxsb2Nfc2VnbWVudDogICBwYWdlIHRh
YmxlcyAgOiAweGMzNDgzMDAwIC0+IDB4YzM0YTEwMDAgIChwZm4gMHgzNDgzICsgMHgxZSBwYWdl
cykKZG9tYWluYnVpbGRlcjogZGV0YWlsOiB4Y19kb21fcGZuX3RvX3B0cjogZG9tVSBtYXBwaW5n
OiBwZm4gMHgzNDgzKzB4MWUgYXQgMHhiM2NkNTAwMApkb21haW5idWlsZGVyOiBkZXRhaWw6IHhj
X2RvbV9hbGxvY19wYWdlICAgOiAgIGJvb3Qgc3RhY2sgICA6IDB4YzM0YTEwMDAgKHBmbiAweDM0
YTEpCmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogeGNfZG9tX2J1aWxkX2ltYWdlICA6IHZpcnRfYWxs
b2NfZW5kIDogMHhjMzRhMjAwMApkb21haW5idWlsZGVyOiBkZXRhaWw6IHhjX2RvbV9idWlsZF9p
bWFnZSAgOiB2aXJ0X3BndGFiX2VuZCA6IDB4YzM4MDAwMDAKZG9tYWluYnVpbGRlcjogZGV0YWls
OiB4Y19kb21fYm9vdF9pbWFnZTogY2FsbGVkCmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogYXJjaF9z
ZXR1cF9ib290ZWFybHk6IGRvaW5nIG5vdGhpbmcKZG9tYWluYnVpbGRlcjogZGV0YWlsOiB4Y19k
b21fY29tcGF0X2NoZWNrOiBzdXBwb3J0ZWQgZ3Vlc3QgdHlwZTogeGVuLTMuMC14ODZfNjQKZG9t
YWluYnVpbGRlcjogZGV0YWlsOiB4Y19kb21fY29tcGF0X2NoZWNrOiBzdXBwb3J0ZWQgZ3Vlc3Qg
dHlwZTogeGVuLTMuMC14ODZfMzJwIDw9IG1hdGNoZXMKZG9tYWluYnVpbGRlcjogZGV0YWlsOiB4
Y19kb21fY29tcGF0X2NoZWNrOiBzdXBwb3J0ZWQgZ3Vlc3QgdHlwZTogaHZtLTMuMC14ODZfMzIK
ZG9tYWluYnVpbGRlcjogZGV0YWlsOiB4Y19kb21fY29tcGF0X2NoZWNrOiBzdXBwb3J0ZWQgZ3Vl
c3QgdHlwZTogaHZtLTMuMC14ODZfMzJwCmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogeGNfZG9tX2Nv
bXBhdF9jaGVjazogc3VwcG9ydGVkIGd1ZXN0IHR5cGU6IGh2bS0zLjAteDg2XzY0CmRvbWFpbmJ1
aWxkZXI6IGRldGFpbDogeGNfZG9tX3VwZGF0ZV9ndWVzdF9wMm06IGRzdCAzMmJpdCwgcGFnZXMg
MHgxODAwMDAKZG9tYWluYnVpbGRlcjogZGV0YWlsOiBjbGVhcl9wYWdlOiBwZm4gMHgzNDgyLCBt
Zm4gMHg0MmM0YjAKZG9tYWluYnVpbGRlcjogZGV0YWlsOiBjbGVhcl9wYWdlOiBwZm4gMHgzNDgx
LCBtZm4gMHg0MmM0YjEKZG9tYWluYnVpbGRlcjogZGV0YWlsOiB4Y19kb21fcGZuX3RvX3B0cjog
ZG9tVSBtYXBwaW5nOiBwZm4gMHgzNDgwKzB4MSBhdCAweGIzY2QyMDAwCmRvbWFpbmJ1aWxkZXI6
IGRldGFpbDogc3RhcnRfaW5mb194ODZfMzI6IGNhbGxlZApkb21haW5idWlsZGVyOiBkZXRhaWw6
IHNldHVwX2h5cGVyY2FsbF9wYWdlOiB2YWRkcj0weGMxMDAyMDAwIHBmbj0weDEwMDIKZG9tYWlu
YnVpbGRlcjogZGV0YWlsOiBkb21haW4gYnVpbGRlciBtZW1vcnkgZm9vdHByaW50CmRvbWFpbmJ1
aWxkZXI6IGRldGFpbDogICAgYWxsb2NhdGVkCmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogICAgICAg
bWFsbG9jICAgICAgICAgICAgIDogMTA0Mzkga0IKZG9tYWluYnVpbGRlcjogZGV0YWlsOiAgICAg
ICBhbm9uIG1tYXAgICAgICAgICAgOiAwIGJ5dGVzCmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogICAg
bWFwcGVkCmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogICAgICAgZmlsZSBtbWFwICAgICAgICAgIDog
MTI2MzAga0IKZG9tYWluYnVpbGRlcjogZGV0YWlsOiAgICAgICBkb21VIG1tYXAgICAgICAgICAg
OiAzNiBNQgpkb21haW5idWlsZGVyOiBkZXRhaWw6IGFyY2hfc2V0dXBfYm9vdGxhdGU6IHNoYXJl
ZF9pbmZvOiBwZm4gMHgwLCBtZm4gMHhiZjIyZgpkb21haW5idWlsZGVyOiBkZXRhaWw6IHNoYXJl
ZF9pbmZvX3g4Nl8zMjogY2FsbGVkCmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogdmNwdV94ODZfMzI6
IGNhbGxlZApkb21haW5idWlsZGVyOiBkZXRhaWw6IHZjcHVfeDg2XzMyOiBjcjM6IHBmbiAweDM0
ODMgbWZuIDB4NDJjNGFmCmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogbGF1bmNoX3ZtOiBjYWxsZWQs
IGN0eHQ9MHhiZmRmM2M1Ywpkb21haW5idWlsZGVyOiBkZXRhaWw6IHhjX2RvbV9yZWxlYXNlOiBj
YWxsZWQKbGlieGw6IGRlYnVnOiBsaWJ4bF9kZXZpY2UuYzoyMjk6bGlieGxfX2RldmljZV9kaXNr
X3NldF9iYWNrZW5kOiBEaXNrIHZkZXY9eHZkYTEgc3BlYy5iYWNrZW5kPXBoeQpsaWJ4bDogZGVi
dWc6IGxpYnhsX2V2ZW50LmM6NTEyOmxpYnhsX19ldl94c3dhdGNoX3JlZ2lzdGVyOiB3YXRjaCB3
PTB4ODA2Y2JjOCB3cGF0aD0vbG9jYWwvZG9tYWluLzAvYmFja2VuZC92YmQvMi81MTcxMy9zdGF0
ZSB0b2tlbj0zLzA6IHJlZ2lzdGVyIHNsb3RudW09MwpsaWJ4bDogZGVidWc6IGxpYnhsX2Rldmlj
ZS5jOjIyOTpsaWJ4bF9fZGV2aWNlX2Rpc2tfc2V0X2JhY2tlbmQ6IERpc2sgdmRldj14dmRiIHNw
ZWMuYmFja2VuZD1waHkKbGlieGw6IGRlYnVnOiBsaWJ4bF9kZXZpY2UuYzoyMjk6bGlieGxfX2Rl
dmljZV9kaXNrX3NldF9iYWNrZW5kOiBEaXNrIHZkZXY9eHZkYiBzcGVjLmJhY2tlbmQ9cGh5Cmxp
YnhsOiBkZWJ1ZzogbGlieGxfZXZlbnQuYzo1MTI6bGlieGxfX2V2X3hzd2F0Y2hfcmVnaXN0ZXI6
IHdhdGNoIHc9MHg4MDZkNTM4IHdwYXRoPS9sb2NhbC9kb21haW4vMC9iYWNrZW5kL3ZiZC8yLzUx
NzI4L3N0YXRlIHRva2VuPTIvMTogcmVnaXN0ZXIgc2xvdG51bT0yCmxpYnhsOiBkZWJ1ZzogbGli
eGxfY3JlYXRlLmM6MTE4Njpkb19kb21haW5fY3JlYXRlOiBhbyAweDgwNmJlZjA6IGlucHJvZ3Jl
c3M6IHBvbGxlcj0weDgwNmI2ODgsIGZsYWdzPWkKbGlieGw6IGRlYnVnOiBsaWJ4bF9ldmVudC5j
OjQ1Nzp3YXRjaGZkX2NhbGxiYWNrOiB3YXRjaCB3PTB4ODA2Y2JjOCB3cGF0aD0vbG9jYWwvZG9t
YWluLzAvYmFja2VuZC92YmQvMi81MTcxMy9zdGF0ZSB0b2tlbj0zLzA6IGV2ZW50IGVwYXRoPS9s
b2NhbC9kb21haW4vMC9iYWNrZW5kL3ZiZC8yLzUxNzEzL3N0YXRlCmxpYnhsOiBkZWJ1ZzogbGli
eGxfZXZlbnQuYzo1OTY6ZGV2c3RhdGVfd2F0Y2hfY2FsbGJhY2s6IGJhY2tlbmQgL2xvY2FsL2Rv
bWFpbi8wL2JhY2tlbmQvdmJkLzIvNTE3MTMvc3RhdGUgd2FudGVkIHN0YXRlIDIgb2sKbGlieGw6
IGRlYnVnOiBsaWJ4bF9ldmVudC5jOjU0OTpsaWJ4bF9fZXZfeHN3YXRjaF9kZXJlZ2lzdGVyOiB3
YXRjaCB3PTB4ODA2Y2JjOCB3cGF0aD0vbG9jYWwvZG9tYWluLzAvYmFja2VuZC92YmQvMi81MTcx
My9zdGF0ZSB0b2tlbj0zLzA6IGRlcmVnaXN0ZXIgc2xvdG51bT0zCmxpYnhsOiBkZWJ1ZzogbGli
eGxfZXZlbnQuYzo1NjE6bGlieGxfX2V2X3hzd2F0Y2hfZGVyZWdpc3Rlcjogd2F0Y2ggdz0weDgw
NmNiYzg6IGRlcmVnaXN0ZXIgdW5yZWdpc3RlcmVkCmxpYnhsOiBkZWJ1ZzogbGlieGxfZGV2aWNl
LmM6OTE2OmRldmljZV9ob3RwbHVnOiBjYWxsaW5nIGhvdHBsdWcgc2NyaXB0OiAvZXRjL3hlbi9z
Y3JpcHRzL2Jsb2NrIGFkZApsaWJ4bDogZGVidWc6IGxpYnhsX2V2ZW50LmM6NDI2OndhdGNoZmRf
Y2FsbGJhY2s6IHdhdGNoIGVwYXRoPS9sb2NhbC9kb21haW4vMC9iYWNrZW5kL3ZiZC8yLzUxNzEz
L3N0YXRlIHRva2VuPTMvMDogZW1wdHkgc2xvdApsaWJ4bDogZGVidWc6IGxpYnhsX2V2ZW50LmM6
NDU3OndhdGNoZmRfY2FsbGJhY2s6IHdhdGNoIHc9MHg4MDZkNTM4IHdwYXRoPS9sb2NhbC9kb21h
aW4vMC9iYWNrZW5kL3ZiZC8yLzUxNzI4L3N0YXRlIHRva2VuPTIvMTogZXZlbnQgZXBhdGg9L2xv
Y2FsL2RvbWFpbi8wL2JhY2tlbmQvdmJkLzIvNTE3Mjgvc3RhdGUKbGlieGw6IGRlYnVnOiBsaWJ4
bF9ldmVudC5jOjU5NjpkZXZzdGF0ZV93YXRjaF9jYWxsYmFjazogYmFja2VuZCAvbG9jYWwvZG9t
YWluLzAvYmFja2VuZC92YmQvMi81MTcyOC9zdGF0ZSB3YW50ZWQgc3RhdGUgMiBvawpsaWJ4bDog
ZGVidWc6IGxpYnhsX2V2ZW50LmM6NTQ5OmxpYnhsX19ldl94c3dhdGNoX2RlcmVnaXN0ZXI6IHdh
dGNoIHc9MHg4MDZkNTM4IHdwYXRoPS9sb2NhbC9kb21haW4vMC9iYWNrZW5kL3ZiZC8yLzUxNzI4
L3N0YXRlIHRva2VuPTIvMTogZGVyZWdpc3RlciBzbG90bnVtPTIKbGlieGw6IGRlYnVnOiBsaWJ4
bF9ldmVudC5jOjU2MTpsaWJ4bF9fZXZfeHN3YXRjaF9kZXJlZ2lzdGVyOiB3YXRjaCB3PTB4ODA2
ZDUzODogZGVyZWdpc3RlciB1bnJlZ2lzdGVyZWQKbGlieGw6IGRlYnVnOiBsaWJ4bF9kZXZpY2Uu
Yzo5MTY6ZGV2aWNlX2hvdHBsdWc6IGNhbGxpbmcgaG90cGx1ZyBzY3JpcHQ6IC9ldGMveGVuL3Nj
cmlwdHMvYmxvY2sgYWRkCmxpYnhsOiBkZWJ1ZzogbGlieGxfZXZlbnQuYzo0MjY6d2F0Y2hmZF9j
YWxsYmFjazogd2F0Y2ggZXBhdGg9L2xvY2FsL2RvbWFpbi8wL2JhY2tlbmQvdmJkLzIvNTE3Mjgv
c3RhdGUgdG9rZW49Mi8xOiBlbXB0eSBzbG90CmxpYnhsOiBkZWJ1ZzogbGlieGxfZXZlbnQuYzo1
MTI6bGlieGxfX2V2X3hzd2F0Y2hfcmVnaXN0ZXI6IHdhdGNoIHc9MHg4MDZlYjIwIHdwYXRoPS9s
b2NhbC9kb21haW4vMC9iYWNrZW5kL3ZpZi8yLzAvc3RhdGUgdG9rZW49Mi8yOiByZWdpc3RlciBz
bG90bnVtPTIKbGlieGw6IGRlYnVnOiBsaWJ4bF9ldmVudC5jOjQ1Nzp3YXRjaGZkX2NhbGxiYWNr
OiB3YXRjaCB3PTB4ODA2ZWIyMCB3cGF0aD0vbG9jYWwvZG9tYWluLzAvYmFja2VuZC92aWYvMi8w
L3N0YXRlIHRva2VuPTIvMjogZXZlbnQgZXBhdGg9L2xvY2FsL2RvbWFpbi8wL2JhY2tlbmQvdmlm
LzIvMC9zdGF0ZQpsaWJ4bDogZGVidWc6IGxpYnhsX2V2ZW50LmM6NjAwOmRldnN0YXRlX3dhdGNo
X2NhbGxiYWNrOiBiYWNrZW5kIC9sb2NhbC9kb21haW4vMC9iYWNrZW5kL3ZpZi8yLzAvc3RhdGUg
d2FudGVkIHN0YXRlIDIgc3RpbGwgd2FpdGluZyBzdGF0ZSAxCmxpYnhsOiBkZWJ1ZzogbGlieGxf
ZXZlbnQuYzo0NTc6d2F0Y2hmZF9jYWxsYmFjazogd2F0Y2ggdz0weDgwNmViMjAgd3BhdGg9L2xv
Y2FsL2RvbWFpbi8wL2JhY2tlbmQvdmlmLzIvMC9zdGF0ZSB0b2tlbj0yLzI6IGV2ZW50IGVwYXRo
PS9sb2NhbC9kb21haW4vMC9iYWNrZW5kL3ZpZi8yLzAvc3RhdGUKbGlieGw6IGRlYnVnOiBsaWJ4
bF9ldmVudC5jOjU5NjpkZXZzdGF0ZV93YXRjaF9jYWxsYmFjazogYmFja2VuZCAvbG9jYWwvZG9t
YWluLzAvYmFja2VuZC92aWYvMi8wL3N0YXRlIHdhbnRlZCBzdGF0ZSAyIG9rCmxpYnhsOiBkZWJ1
ZzogbGlieGxfZXZlbnQuYzo1NDk6bGlieGxfX2V2X3hzd2F0Y2hfZGVyZWdpc3Rlcjogd2F0Y2gg
dz0weDgwNmViMjAgd3BhdGg9L2xvY2FsL2RvbWFpbi8wL2JhY2tlbmQvdmlmLzIvMC9zdGF0ZSB0
b2tlbj0yLzI6IGRlcmVnaXN0ZXIgc2xvdG51bT0yCmxpYnhsOiBkZWJ1ZzogbGlieGxfZXZlbnQu
Yzo1NjE6bGlieGxfX2V2X3hzd2F0Y2hfZGVyZWdpc3Rlcjogd2F0Y2ggdz0weDgwNmViMjA6IGRl
cmVnaXN0ZXIgdW5yZWdpc3RlcmVkCmxpYnhsOiBkZWJ1ZzogbGlieGxfZGV2aWNlLmM6OTE2OmRl
dmljZV9ob3RwbHVnOiBjYWxsaW5nIGhvdHBsdWcgc2NyaXB0OiAvZXRjL3hlbi9zY3JpcHRzL3Zp
Zi1icmlkZ2Ugb25saW5lCmxpYnhsOiBlcnJvcjogbGlieGxfcGNpLmM6MTA1NTpsaWJ4bF9fZGV2
aWNlX3BjaV9hZGQ6IFBDSSBkZXZpY2UgMDoxOjAuMCBpcyBub3QgYXNzaWduYWJsZQpsaWJ4bDog
ZXJyb3I6IGxpYnhsX3BjaS5jOjEwNTU6bGlieGxfX2RldmljZV9wY2lfYWRkOiBQQ0kgZGV2aWNl
IDA6MTowLjEgaXMgbm90IGFzc2lnbmFibGUKbGlieGw6IGRlYnVnOiBsaWJ4bF9wY2kuYzo4NTps
aWJ4bF9fY3JlYXRlX3BjaV9iYWNrZW5kOiBDcmVhdGluZyBwY2kgYmFja2VuZApsaWJ4bDogZGVi
dWc6IGxpYnhsX3g4Ni5jOjkwOmU4MjBfc2FuaXRpemU6IE1lbW9yeTogNjI5MTQ1NmtCIEVuZCBv
ZiBSQU06IDB4YmY2OTkgKFBGTikgRGVsdGE6IDMxNTUzNTZrQiwgUENJIHN0YXJ0OiAzMTM2MTAw
a0IgKDB4YmY2OTkgUEZOKSwgQmFsbG9vbiAwa0IKCmxpYnhsOiBkZWJ1ZzogbGlieGxfeDg2LmM6
MjEwOmU4MjBfc2FuaXRpemU6IDogIFswIC0+IGJmNjk5XSBSQU0KbGlieGw6IGRlYnVnOiBsaWJ4
bF94ODYuYzoyMTA6ZTgyMF9zYW5pdGl6ZTogOiAgW2JmNjk5IC0+IGJmNmFmXSBSZXNlcnZlZAps
aWJ4bDogZGVidWc6IGxpYnhsX3g4Ni5jOjIxMDplODIwX3Nhbml0aXplOiA6ICBbYmY2YWYgLT4g
YmY2Y2VdIEFDUEkKbGlieGw6IGRlYnVnOiBsaWJ4bF94ODYuYzoyMTA6ZTgyMF9zYW5pdGl6ZTog
OiAgW2JmNmNlIC0+IGMwMDAwXSBSZXNlcnZlZApsaWJ4bDogZGVidWc6IGxpYnhsX3g4Ni5jOjIx
MDplODIwX3Nhbml0aXplOiA6ICBbZTAwMDAgLT4gZjAwMDBdIFJlc2VydmVkCmxpYnhsOiBkZWJ1
ZzogbGlieGxfeDg2LmM6MjEwOmU4MjBfc2FuaXRpemU6IDogIFtmZTAwMCAtPiAxMDAwMDBdIFJl
c2VydmVkCmxpYnhsOiBkZWJ1ZzogbGlieGxfZXZlbnQuYzoxNjY3OmxpYnhsX19hb19wcm9ncmVz
c19yZXBvcnQ6IGFvIDB4ODA2YmVmMDogcHJvZ3Jlc3MgcmVwb3J0OiBpZ25vcmVkCmxpYnhsOiBk
ZWJ1ZzogbGlieGxfZXZlbnQuYzoxNDk3OmxpYnhsX19hb19jb21wbGV0ZTogYW8gMHg4MDZiZWYw
OiBjb21wbGV0ZSwgcmM9MApsaWJ4bDogZGVidWc6IGxpYnhsX2V2ZW50LmM6MTQ2OTpsaWJ4bF9f
YW9fX2Rlc3Ryb3k6IGFvIDB4ODA2YmVmMDogZGVzdHJveQpEYWVtb24gcnVubmluZyB3aXRoIFBJ
RCA0NjYzCnhjOiBkZWJ1ZzogaHlwZXJjYWxsIGJ1ZmZlcjogdG90YWwgYWxsb2NhdGlvbnM6MTg1
IHRvdGFsIHJlbGVhc2VzOjE4NQp4YzogZGVidWc6IGh5cGVyY2FsbCBidWZmZXI6IGN1cnJlbnQg
YWxsb2NhdGlvbnM6MCBtYXhpbXVtIGFsbG9jYXRpb25zOjIKeGM6IGRlYnVnOiBoeXBlcmNhbGwg
YnVmZmVyOiBjYWNoZSBjdXJyZW50IHNpemU6Mgp4YzogZGVidWc6IGh5cGVyY2FsbCBidWZmZXI6
IGNhY2hlIGhpdHM6MTc4IG1pc3NlczoyIHRvb2JpZzo1Cgo=

--_005_E71FC5D6F96C3C4B93FC8FF942D924C682F45DE3SBJEXCH1Bwebsen_
Content-Type: application/octet-stream; name="xl-list.output"
Content-Description: xl-list.output
Content-Disposition: attachment; filename="xl-list.output"; size=268;
	creation-date="Mon, 22 Oct 2012 10:09:56 GMT";
	modification-date="Wed, 24 Oct 2012 13:57:17 GMT"
Content-Transfer-Encoding: base64

W3Jvb3RAbG9jYWxob3N0IH5dIyB4bCBsaXN0Ck5hbWUgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgSUQgICBNZW0gVkNQVXMgICAgICBTdGF0ZSAgIFRpbWUocykKRG9tYWlu
LTAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMCAgMjA0NyAgICAgMiAgICAg
ci0tLS0tICAgICAgNDAuMwp3Y2cgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAyICA1MTEwICAgICA0ICAgICAtYi0tLS0gICAgICAyNy4wCg==

--_005_E71FC5D6F96C3C4B93FC8FF942D924C682F45DE3SBJEXCH1Bwebsen_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_005_E71FC5D6F96C3C4B93FC8FF942D924C682F45DE3SBJEXCH1Bwebsen_--


From xen-devel-bounces@lists.xen.org Wed Oct 24 06:03:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 06:03:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQu31-0002JX-QF; Wed, 24 Oct 2012 06:02:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQu2z-0002JP-Lx; Wed, 24 Oct 2012 06:02:34 +0000
Received: from [85.158.137.99:23103] by server-9.bemta-3.messagelabs.com id
	61/6F-16841-87487805; Wed, 24 Oct 2012 06:02:32 +0000
X-Env-Sender: hufan@websense.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1351058552!19639828!1
X-Originating-IP: [85.115.56.190]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODUuMTE1LjU2LjE5MCA9PiA4ODcwNzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1482 invoked from network); 24 Oct 2012 06:02:32 -0000
Received: from cluster-b.mailcontrol.com (HELO cluster-b.mailcontrol.com)
	(85.115.56.190)
	by server-9.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Oct 2012 06:02:32 -0000
Received: from ssdwbsnapp.websense.com (static-204-15-65-158.websense.com
	[204.15.65.158] (may be forged))
	by rly41b.srv.mailcontrol.com (MailControl) with ESMTP id
	q9O62HnH018704
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 24 Oct 2012 07:02:21 +0100
Received: from SSDEXCH1B.websense.com (unknown [10.8.2.91])
	by Websense Email Security Gateway with ESMTP id BE1C61000015;
	Tue, 23 Oct 2012 23:01:59 -0700 (PDT)
Received: from SBJEXCH1A.websense.com (10.32.8.101) by SSDEXCH1B.websense.com
	(10.8.2.91) with Microsoft SMTP Server (TLS) id 14.2.283.3;
	Tue, 23 Oct 2012 23:02:17 -0700
Received: from SBJEXCH1B.websense.com ([169.254.2.203]) by
	SBJEXCH1A.websense.com ([169.254.1.146]) with mapi id 14.02.0283.003;
	Wed, 24 Oct 2012 14:02:13 +0800
From: "Fan, Huaxiang" 
To: =?iso-8859-1?Q?Pasi_K=E4rkk=E4inen?= 
Thread-Topic: [Xen-devel] e820_host problems
Thread-Index: Ac2wO6t52kDU66w/TymQ9bR6YOep8P//uuqA//zbyEA=
Date: Wed, 24 Oct 2012 06:02:11 +0000
Message-ID: 
References: 
	<20121022135023.GU8912@reaktio.net>
In-Reply-To: <20121022135023.GU8912@reaktio.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.32.134.111]
Content-Type: multipart/mixed;
	boundary="_005_E71FC5D6F96C3C4B93FC8FF942D924C682F45DE3SBJEXCH1Bwebsen_"
MIME-Version: 1.0
X-Scanned-By: MailControl 10515.0 (www.mailcontrol.com) on 10.66.0.151
Cc: "xen-users@lists.xen.org" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] e820_host problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_005_E71FC5D6F96C3C4B93FC8FF942D924C682F45DE3SBJEXCH1Bwebsen_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Pasi,

Thanks for your reply. I've tried the latest table kernel 3.6.3. The situat=
ion is better, but still not perfect. =20
When I assign 6144M to domu wcg ,the output of 'xl list' only indicates 511=
0M allocated for domu wcg.
When I logon domu wcg, the totol memory is *limited within 3G*. I suspect t=
he e820-map was wrong.

I attached domu config file, output of command 'xl -vvv create domainWCG.cf=
g', output of command 'xl list' and output of command 'dmesg' on domu wcg.

Thanks in advance.
Huaxiang
-----Original Message-----
From: Pasi K=E4rkk=E4inen [mailto:pasik@iki.fi]=20
Sent: Monday, October 22, 2012 9:50 PM
To: Fan, Huaxiang
Cc: xen-devel@lists.xen.org; xen-users@lists.xen.org
Subject: Re: [Xen-devel] e820_host problems

On Mon, Oct 22, 2012 at 10:11:00AM +0000, Fan, Huaxiang wrote:
>    Hi,
>=20
>=20
>=20
>    I've set up a PV guest using xen 4.2 and kernel 2.6.32.57. the hypervi=
or
>    is 64bits whereas the dom0 and domu are 32bits. It seems to me that th=
e
>    memory allocation to domu is *limited to 3360M* when e820_host is enab=
led.
>    I attached the domu configuration file and output of the command xl -v=
vv
>    create and xl list.
>=20
>    I am looking forward your reply.
>

First of all try with a later kernel, say Linux 3.6.2.

-- Pasi
=20
>    Thanks,
>=20
>    HUAXIANG FAN
>    Software Engineer II
>=20
>    WEBSENSE NETWORK SECURITY TECHNOLOGY R&D (BEIJING) CO. LTD.
>    ph: +8610.5884.4327
>    fax: +8610.5884.4727
>    [1]www.websense.cn
>=20
>    Websense TRITON(TM)
>    For Essential Information Protection(TM)
>    [2]Web Security | [3]Data Security | [4]Email Security
>=20
>         Protected by Websense Hosted Email Security -- www.websense.com
>=20
> References
>=20
>    Visible links
>    1. http://webdefence.global.blackspider.com/urlwrap/?q=3DAXicY2RmuMjNw=
HBHhYGhKKfSyCxFr7ioTC83MTMnOT-vpCg_Ry85P5eh0NLXJd_fMdXA2NDIwpAhozQtMc-hPDWp=
ODWvOBWsIqOkpMBKX7-8vFwPIZ6nzwAAo00fKg&Z
>    2. http://www.websense.com/content/Regional/SCH/WebSecurityOverview.as=
px
>    3. http://www.websense.com/content/Regional/SCH/DataSecurity.aspx
>    4. http://www.websense.com/content/Regional/SCH/MessagingSecurity.aspx




> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



 To report this as spam, please forward to spam@websense.com.  Thank you.

--_005_E71FC5D6F96C3C4B93FC8FF942D924C682F45DE3SBJEXCH1Bwebsen_
Content-Type: application/octet-stream; name="dmesg.output.domu"
Content-Description: dmesg.output.domu
Content-Disposition: attachment; filename="dmesg.output.domu"; size=11224;
	creation-date="Wed, 24 Oct 2012 06:00:07 GMT";
	modification-date="Wed, 24 Oct 2012 13:58:42 GMT"
Content-Transfer-Encoding: base64

WyAgICAwLjAwMDAwMF0gUmVzZXJ2aW5nIHZpcnR1YWwgYWRkcmVzcyBzcGFjZSBhYm92ZSAweGY1
ODAwMDAwClsgICAgMC4wMDAwMDBdIExpbnV4IHZlcnNpb24gMy42LjMgKHJvb3RAY2VudG9zNi4y
LTMyYml0KSAoZ2NjIHZlcnNpb24gNC40LjYgMjAxMTA3MzEgKFJlZCBIYXQgNC40LjYtMykgKEdD
QykgKSAjMSBTTVAgVHVlIE9jdCAyMyAxNjo1NTowMyBDU1QgMjAxMgpbICAgIDAuMDAwMDAwXSBB
Q1BJIGluIHVucHJpdmlsZWdlZCBkb21haW4gZGlzYWJsZWQKWyAgICAwLjAwMDAwMF0gRnJlZWlu
ZyBiZjY5OS0xMDAwMDAgcGZuIHJhbmdlOiAyNjQ1NTEgcGFnZXMgZnJlZWQKWyAgICAwLjAwMDAw
MF0gMS0xIG1hcHBpbmcgb24gYmY2OTktPjEwMDAwMApbICAgIDAuMDAwMDAwXSBSZWxlYXNlZCAy
NjQ1NTEgcGFnZXMgb2YgdW51c2VkIG1lbW9yeQpbICAgIDAuMDAwMDAwXSBTZXQgMjY0NTUxIHBh
Z2UocykgdG8gMS0xIG1hcHBpbmcKWyAgICAwLjAwMDAwMF0gZTgyMDogQklPUy1wcm92aWRlZCBw
aHlzaWNhbCBSQU0gbWFwOgpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMDAwMDAw
MDAwLTB4MDAwMDAwMDAwMDA5ZmZmZl0gdXNhYmxlClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAw
eDAwMDAwMDAwMDAwYTAwMDAtMHgwMDAwMDAwMDAwMGZmZmZmXSByZXNlcnZlZApbICAgIDAuMDAw
MDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMDAwMTAwMDAwLTB4MDAwMDAwMDBiZjY5OGZmZl0gdXNh
YmxlClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwYmY2OTkwMDAtMHgwMDAwMDAw
MGJmNmFlZmZmXSByZXNlcnZlZApbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMGJm
NmFmMDAwLTB4MDAwMDAwMDBiZjZjZGZmZl0gQUNQSSBkYXRhClsgICAgMC4wMDAwMDBdIFhlbjog
W21lbSAweDAwMDAwMDAwYmY2Y2UwMDAtMHgwMDAwMDAwMGJmZmZmZmZmXSByZXNlcnZlZApbICAg
IDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMGUwMDAwMDAwLTB4MDAwMDAwMDBlZmZmZmZm
Zl0gcmVzZXJ2ZWQKWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDBmZTAwMDAwMC0w
eDAwMDAwMDAwZmZmZmZmZmZdIHJlc2VydmVkClsgICAgMC4wMDAwMDBdIE5YIChFeGVjdXRlIERp
c2FibGUpIHByb3RlY3Rpb246IGFjdGl2ZQpbICAgIDAuMDAwMDAwXSBETUkgbm90IHByZXNlbnQg
b3IgaW52YWxpZC4KWyAgICAwLjAwMDAwMF0gZTgyMDogdXBkYXRlIFttZW0gMHgwMDAwMDAwMC0w
eDAwMDBmZmZmXSB1c2FibGUgPT0+IHJlc2VydmVkClsgICAgMC4wMDAwMDBdIGU4MjA6IHJlbW92
ZSBbbWVtIDB4MDAwYTAwMDAtMHgwMDBmZmZmZl0gdXNhYmxlClsgICAgMC4wMDAwMDBdIGU4MjA6
IGxhc3RfcGZuID0gMHhiZjY5OSBtYXhfYXJjaF9wZm4gPSAweDEwMDAwMDAKWyAgICAwLjAwMDAw
MF0gaW5pdGlhbCBtZW1vcnkgbWFwcGVkOiBbbWVtIDB4MDAwMDAwMDAtMHgwM2ZmZWZmZl0KWyAg
ICAwLjAwMDAwMF0gQmFzZSBtZW1vcnkgdHJhbXBvbGluZSBhdCBbYzAwOWMwMDBdIDljMDAwIHNp
emUgMTYzODQKWyAgICAwLjAwMDAwMF0gaW5pdF9tZW1vcnlfbWFwcGluZzogW21lbSAweDAwMDAw
MDAwLTB4MmQzZmRmZmZdClsgICAgMC4wMDAwMDBdICBbbWVtIDB4MDAwMDAwMDAtMHgyZDNmZGZm
Zl0gcGFnZSA0awpbICAgIDAuMDAwMDAwXSBrZXJuZWwgZGlyZWN0IG1hcHBpbmcgdGFibGVzIHVw
IHRvIDB4MmQzZmRmZmYgQCBbbWVtIDB4MDNlOTIwMDAtMHgwM2ZmZWZmZl0KWyAgICAwLjAwMDAw
MF0geGVuOiBzZXR0aW5nIFJXIHRoZSByYW5nZSAzZmRjMDAwIC0gM2ZmZjAwMApbICAgIDAuMDAw
MDAwXSBSQU1ESVNLOiBbbWVtIDB4MDE2MTcwMDAtMHgwMmU3ZmZmZl0KWyAgICAwLjAwMDAwMF0g
MjMzOE1CIEhJR0hNRU0gYXZhaWxhYmxlLgpbICAgIDAuMDAwMDAwXSA3MjNNQiBMT1dNRU0gYXZh
aWxhYmxlLgpbICAgIDAuMDAwMDAwXSAgIG1hcHBlZCBsb3cgcmFtOiAwIC0gMmQzZmUwMDAKWyAg
ICAwLjAwMDAwMF0gICBsb3cgcmFtOiAwIC0gMmQzZmUwMDAKWyAgICAwLjAwMDAwMF0gWm9uZSBy
YW5nZXM6ClsgICAgMC4wMDAwMDBdICAgRE1BICAgICAgW21lbSAweDAwMDEwMDAwLTB4MDBmZmZm
ZmZdClsgICAgMC4wMDAwMDBdICAgTm9ybWFsICAgW21lbSAweDAxMDAwMDAwLTB4MmQzZmRmZmZd
ClsgICAgMC4wMDAwMDBdICAgSGlnaE1lbSAgW21lbSAweDJkM2ZlMDAwLTB4YmY2OThmZmZdClsg
ICAgMC4wMDAwMDBdIE1vdmFibGUgem9uZSBzdGFydCBmb3IgZWFjaCBub2RlClsgICAgMC4wMDAw
MDBdIEVhcmx5IG1lbW9yeSBub2RlIHJhbmdlcwpbICAgIDAuMDAwMDAwXSAgIG5vZGUgICAwOiBb
bWVtIDB4MDAwMTAwMDAtMHgwMDA5ZmZmZl0KWyAgICAwLjAwMDAwMF0gICBub2RlICAgMDogW21l
bSAweDAwMTAwMDAwLTB4YmY2OThmZmZdClsgICAgMC4wMDAwMDBdIE9uIG5vZGUgMCB0b3RhbHBh
Z2VzOiA3ODM5MTMKWyAgICAwLjAwMDAwMF0gICBETUEgem9uZTogMzIgcGFnZXMgdXNlZCBmb3Ig
bWVtbWFwClsgICAgMC4wMDAwMDBdICAgRE1BIHpvbmU6IDAgcGFnZXMgcmVzZXJ2ZWQKWyAgICAw
LjAwMDAwMF0gICBETUEgem9uZTogMzk1MiBwYWdlcywgTElGTyBiYXRjaDowClsgICAgMC4wMDAw
MDBdICAgTm9ybWFsIHpvbmU6IDE0MTYgcGFnZXMgdXNlZCBmb3IgbWVtbWFwClsgICAgMC4wMDAw
MDBdICAgTm9ybWFsIHpvbmU6IDE3OTgzMCBwYWdlcywgTElGTyBiYXRjaDozMQpbICAgIDAuMDAw
MDAwXSAgIEhpZ2hNZW0gem9uZTogNDY3OCBwYWdlcyB1c2VkIGZvciBtZW1tYXAKWyAgICAwLjAw
MDAwMF0gICBIaWdoTWVtIHpvbmU6IDU5NDAwNSBwYWdlcywgTElGTyBiYXRjaDozMQpbICAgIDAu
MDAwMDAwXSBVc2luZyBBUElDIGRyaXZlciBkZWZhdWx0ClsgICAgMC4wMDAwMDBdIHNtcGJvb3Q6
IEFsbG93aW5nIDQgQ1BVcywgMCBob3RwbHVnIENQVXMKWyAgICAwLjAwMDAwMF0gTG9jYWwgQVBJ
QyBkaXNhYmxlZCBieSBCSU9TIC0tIHlvdSBjYW4gZW5hYmxlIGl0IHdpdGggImxhcGljIgpbICAg
IDAuMDAwMDAwXSBBUElDOiBkaXNhYmxlIGFwaWMgZmFjaWxpdHkKWyAgICAwLjAwMDAwMF0gQVBJ
Qzogc3dpdGNoZWQgdG8gYXBpYyBOT09QClsgICAgMC4wMDAwMDBdIG5yX2lycXNfZ3NpOiAxNgpb
ICAgIDAuMDAwMDAwXSBlODIwOiBbbWVtIDB4YzAwMDAwMDAtMHhkZmZmZmZmZl0gYXZhaWxhYmxl
IGZvciBQQ0kgZGV2aWNlcwpbICAgIDAuMDAwMDAwXSBCb290aW5nIHBhcmF2aXJ0dWFsaXplZCBr
ZXJuZWwgb24gWGVuClsgICAgMC4wMDAwMDBdIFhlbiB2ZXJzaW9uOiA0LjIuMCAocHJlc2VydmUt
QUQpClsgICAgMC4wMDAwMDBdIHNldHVwX3BlcmNwdTogTlJfQ1BVUzo4IG5yX2NwdW1hc2tfYml0
czo4IG5yX2NwdV9pZHM6NCBucl9ub2RlX2lkczoxClsgICAgMC4wMDAwMDBdIFBFUkNQVTogRW1i
ZWRkZWQgMTIgcGFnZXMvY3B1IEBlYmJiYjAwMCBzMjY0MzIgcjAgZDIyNzIwIHU0OTE1MgpbICAg
IDAuMDAwMDAwXSBwY3B1LWFsbG9jOiBzMjY0MzIgcjAgZDIyNzIwIHU0OTE1MiBhbGxvYz0xMio0
MDk2ClsgICAgMC4wMDAwMDBdIHBjcHUtYWxsb2M6IFswXSAwIFswXSAxIFswXSAyIFswXSAzIApb
ICAgIDAuMDAwMDAwXSBCdWlsdCAxIHpvbmVsaXN0cyBpbiBab25lIG9yZGVyLCBtb2JpbGl0eSBn
cm91cGluZyBvbi4gIFRvdGFsIHBhZ2VzOiA3Nzc3ODcKWyAgICAwLjAwMDAwMF0gS2VybmVsIGNv
bW1hbmQgbGluZTogcm9vdD0vZGV2L3h2ZGExIHJvIGlvbW11PXNvZnQgcHJpbnRrLnByaW50a190
aW1lPTEgY29uc29sZT1odmMwClsgICAgMC4wMDAwMDBdIFBJRCBoYXNoIHRhYmxlIGVudHJpZXM6
IDQwOTYgKG9yZGVyOiAyLCAxNjM4NCBieXRlcykKWyAgICAwLjAwMDAwMF0gRGVudHJ5IGNhY2hl
IGhhc2ggdGFibGUgZW50cmllczogMTMxMDcyIChvcmRlcjogNywgNTI0Mjg4IGJ5dGVzKQpbICAg
IDAuMDAwMDAwXSBJbm9kZS1jYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDY1NTM2IChvcmRlcjog
NiwgMjYyMTQ0IGJ5dGVzKQpbICAgIDAuMDAwMDAwXSBfX2V4X3RhYmxlIGFscmVhZHkgc29ydGVk
LCBza2lwcGluZyBzb3J0ClsgICAgMC4wMDAwMDBdIEluaXRpYWxpemluZyBDUFUjMApbICAgIDAu
MDAwMDAwXSBzb2Z0d2FyZSBJTyBUTEIgW21lbSAweDI3YWY3MDAwLTB4MmJhZjZmZmZdICg2NE1C
KSBtYXBwZWQgYXQgW2U3YWY3MDAwLWViYWY2ZmZmXQpbICAgIDAuMDAwMDAwXSBJbml0aWFsaXpp
bmcgSGlnaE1lbSBmb3Igbm9kZSAwICgwMDAyZDNmZTowMDBiZjY5OSkKWyAgICAwLjAwMDAwMF0g
TWVtb3J5OiAzMDA3NTgway8zMTM2MTAwayBhdmFpbGFibGUgKDIzMDBrIGtlcm5lbCBjb2RlLCAx
MjgwNzJrIHJlc2VydmVkLCA5NDZrIGRhdGEsIDQwOGsgaW5pdCwgMjM5NDczMmsgaGlnaG1lbSkK
WyAgICAwLjAwMDAwMF0gdmlydHVhbCBrZXJuZWwgbWVtb3J5IGxheW91dDoKWyAgICAwLjAwMDAw
MF0gICAgIGZpeG1hcCAgOiAweGY1NzE2MDAwIC0gMHhmNTdmZjAwMCAgICggOTMyIGtCKQpbICAg
IDAuMDAwMDAwXSAgICAgcGttYXAgICA6IDB4ZjU0MDAwMDAgLSAweGY1NjAwMDAwICAgKDIwNDgg
a0IpClsgICAgMC4wMDAwMDBdICAgICB2bWFsbG9jIDogMHhlZGJmZTAwMCAtIDB4ZjUzZmUwMDAg
ICAoIDEyMCBNQikKWyAgICAwLjAwMDAwMF0gICAgIGxvd21lbSAgOiAweGMwMDAwMDAwIC0gMHhl
ZDNmZTAwMCAgICggNzIzIE1CKQpbICAgIDAuMDAwMDAwXSAgICAgICAuaW5pdCA6IDB4YzEzMmMw
MDAgLSAweGMxMzkyMDAwICAgKCA0MDgga0IpClsgICAgMC4wMDAwMDBdICAgICAgIC5kYXRhIDog
MHhjMTIzZjIxNiAtIDB4YzEzMmJkYzAgICAoIDk0NiBrQikKWyAgICAwLjAwMDAwMF0gICAgICAg
LnRleHQgOiAweGMxMDAwMDAwIC0gMHhjMTIzZjIxNiAgICgyMzAwIGtCKQpbICAgIDAuMDAwMDAw
XSBIaWVyYXJjaGljYWwgUkNVIGltcGxlbWVudGF0aW9uLgpbICAgIDAuMDAwMDAwXSAJUkNVIHJl
c3RyaWN0aW5nIENQVXMgZnJvbSBOUl9DUFVTPTggdG8gbnJfY3B1X2lkcz00LgpbICAgIDAuMDAw
MDAwXSBOUl9JUlFTOjIzMDQgbnJfaXJxczozMDQgMTYKWyAgICAwLjAwMDAwMF0gQ1BVIDAgaXJx
c3RhY2tzLCBoYXJkPWU3NDA4MDAwIHNvZnQ9ZTc0MGEwMDAKWyAgICAwLjAwMDAwMF0gQ29uc29s
ZTogY29sb3VyIGR1bW15IGRldmljZSA4MHgyNQpbICAgIDAuMDAwMDAwXSBjb25zb2xlIFt0dHkw
XSBlbmFibGVkClsgICAgMC4wMDAwMDBdIGNvbnNvbGUgW2h2YzBdIGVuYWJsZWQKWyAgICAwLjAw
MDAwMF0gWGVuOiB1c2luZyB2Y3B1b3AgdGltZXIgaW50ZXJmYWNlClsgICAgMC4wMDAwMDBdIGlu
c3RhbGxpbmcgWGVuIHRpbWVyIGZvciBDUFUgMApbICAgIDAuMDAwMDAwXSB0c2M6IERldGVjdGVk
IDIyNjEuMDgyIE1IeiBwcm9jZXNzb3IKWyAgICAwLjAwMDk5OV0gQ2FsaWJyYXRpbmcgZGVsYXkg
bG9vcCAoc2tpcHBlZCksIHZhbHVlIGNhbGN1bGF0ZWQgdXNpbmcgdGltZXIgZnJlcXVlbmN5Li4g
NDUyMi4xNiBCb2dvTUlQUyAobHBqPTIyNjEwODIpClsgICAgMC4wMDA5OTldIHBpZF9tYXg6IGRl
ZmF1bHQ6IDMyNzY4IG1pbmltdW06IDMwMQpbICAgIDAuMDAwOTk5XSBTZWN1cml0eSBGcmFtZXdv
cmsgaW5pdGlhbGl6ZWQKWyAgICAwLjAwMDk5OV0gTW91bnQtY2FjaGUgaGFzaCB0YWJsZSBlbnRy
aWVzOiA1MTIKWyAgICAwLjAwMDk5OV0gQ1BVOiBQaHlzaWNhbCBQcm9jZXNzb3IgSUQ6IDAKWyAg
ICAwLjAwMDk5OV0gQ1BVOiBQcm9jZXNzb3IgQ29yZSBJRDogMApbICAgIDAuMDAwOTk5XSBMYXN0
IGxldmVsIGlUTEIgZW50cmllczogNEtCIDUxMiwgMk1CIDcsIDRNQiA3ClsgICAgMC4wMDA5OTld
IExhc3QgbGV2ZWwgZFRMQiBlbnRyaWVzOiA0S0IgNTEyLCAyTUIgMzIsIDRNQiAzMgpbICAgIDAu
MDAwOTk5XSB0bGJfZmx1c2hhbGxfc2hpZnQgaXMgMHg2ClsgICAgMC4wMDA5OTldIFNNUCBhbHRl
cm5hdGl2ZXM6IHN3aXRjaGluZyB0byBVUCBjb2RlClsgICAgMC4wMjQ2ODNdIFBlcmZvcm1hbmNl
IEV2ZW50czogdW5zdXBwb3J0ZWQgcDYgQ1BVIG1vZGVsIDI2IG5vIFBNVSBkcml2ZXIsIHNvZnR3
YXJlIGV2ZW50cyBvbmx5LgpbICAgIDAuMDI0ODQzXSBDUFUgMSBpcnFzdGFja3MsIGhhcmQ9ZTc0
N2EwMDAgc29mdD1lNzQ3YzAwMApbICAgIDAuMDI0ODQ2XSBpbnN0YWxsaW5nIFhlbiB0aW1lciBm
b3IgQ1BVIDEKWyAgICAwLjAyNDg4MV0gU01QIGFsdGVybmF0aXZlczogc3dpdGNoaW5nIHRvIFNN
UCBjb2RlClsgICAgMC4wMDA5OTldIEluaXRpYWxpemluZyBDUFUjMQpbICAgIDAuMDQ5MjYwXSBD
UFUgMiBpcnFzdGFja3MsIGhhcmQ9ZTc0YTYwMDAgc29mdD1lNzRhODAwMApbICAgIDAuMDQ5MjY4
XSBpbnN0YWxsaW5nIFhlbiB0aW1lciBmb3IgQ1BVIDIKWyAgICAwLjAwMDk5OV0gSW5pdGlhbGl6
aW5nIENQVSMyClsgICAgMC4wNTAyODddIENQVSAzIGlycXN0YWNrcywgaGFyZD1lNzRiNDAwMCBz
b2Z0PWU3NGI2MDAwClsgICAgMC4wNTAyOTVdIGluc3RhbGxpbmcgWGVuIHRpbWVyIGZvciBDUFUg
MwpbICAgIDAuMDAwOTk5XSBJbml0aWFsaXppbmcgQ1BVIzMKWyAgICAwLjA1MDQzMl0gQnJvdWdo
dCB1cCA0IENQVXMKWyAgICAwLjA1MDc1MV0gR3JhbnQgdGFibGVzIHVzaW5nIHZlcnNpb24gMiBs
YXlvdXQuClsgICAgMC4wNTA3ODZdIEdyYW50IHRhYmxlIGluaXRpYWxpemVkClsgICAgMC4wNTA4
NDddIE5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMTYKWyAgICAwLjA1MTg1NF0gUENJ
OiBzZXR0aW5nIHVwIFhlbiBQQ0kgZnJvbnRlbmQgc3R1YgpbICAgIDAuMDUxODYxXSBQQ0k6IHBj
aV9jYWNoZV9saW5lX3NpemUgc2V0IHRvIDY0IGJ5dGVzClsgICAgMC4wNTQxNDhdIGJpbzogY3Jl
YXRlIHNsYWIgPGJpby0wPiBhdCAwClsgICAgMC4wNTQzMTNdIEFDUEk6IEludGVycHJldGVyIGRp
c2FibGVkLgpbICAgIDAuMDU0NjQwXSB4ZW4vYmFsbG9vbjogSW5pdGlhbGlzaW5nIGJhbGxvb24g
ZHJpdmVyLgpbICAgIDAuMDU2MjMxXSB4ZW4tYmFsbG9vbjogSW5pdGlhbGlzaW5nIGJhbGxvb24g
ZHJpdmVyLgpbICAgIDAuMDU2NDczXSB2Z2FhcmI6IGxvYWRlZApbICAgIDAuMDU2NjUyXSBQQ0k6
IFN5c3RlbSBkb2VzIG5vdCBzdXBwb3J0IFBDSQpbICAgIDAuMDU2NjUyXSBQQ0k6IFN5c3RlbSBk
b2VzIG5vdCBzdXBwb3J0IFBDSQpbICAgIDAuMDU2ODUyXSBTd2l0Y2hpbmcgdG8gY2xvY2tzb3Vy
Y2UgeGVuClsgICAgMC4wNTY5OTFdIHBucDogUG5QIEFDUEk6IGRpc2FibGVkClsgICAgMC4wNTk3
MDhdIE5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMgpbICAgIDAuMDU5ODc0XSBUQ1Ag
ZXN0YWJsaXNoZWQgaGFzaCB0YWJsZSBlbnRyaWVzOiAxMzEwNzIgKG9yZGVyOiA4LCAxMDQ4NTc2
IGJ5dGVzKQpbICAgIDAuMDYwMTQ3XSBUQ1AgYmluZCBoYXNoIHRhYmxlIGVudHJpZXM6IDY1NTM2
IChvcmRlcjogNywgNTI0Mjg4IGJ5dGVzKQpbICAgIDAuMDYwMjYwXSBUQ1A6IEhhc2ggdGFibGVz
IGNvbmZpZ3VyZWQgKGVzdGFibGlzaGVkIDEzMTA3MiBiaW5kIDY1NTM2KQpbICAgIDAuMDYwMjc3
XSBUQ1A6IHJlbm8gcmVnaXN0ZXJlZApbICAgIDAuMDYwMjgzXSBVRFAgaGFzaCB0YWJsZSBlbnRy
aWVzOiA1MTIgKG9yZGVyOiAyLCAxNjM4NCBieXRlcykKWyAgICAwLjA2MDI5MV0gVURQLUxpdGUg
aGFzaCB0YWJsZSBlbnRyaWVzOiA1MTIgKG9yZGVyOiAyLCAxNjM4NCBieXRlcykKWyAgICAwLjA2
MDM1OV0gTkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAxClsgICAgMC4wNjAzNjldIFBD
STogQ0xTIDAgYnl0ZXMsIGRlZmF1bHQgNjQKWyAgICAwLjA2MDM5OV0gVHJ5aW5nIHRvIHVucGFj
ayByb290ZnMgaW1hZ2UgYXMgaW5pdHJhbWZzLi4uClsgICAgMC4xMTIyMDldIEZyZWVpbmcgaW5p
dHJkIG1lbW9yeTogMjQ5OTZrIGZyZWVkClsgICAgMC4xMTcxMjNdIHBsYXRmb3JtIHJ0Y19jbW9z
OiByZWdpc3RlcmVkIHBsYXRmb3JtIFJUQyBkZXZpY2UgKG5vIFBOUCBkZXZpY2UgZm91bmQpClsg
ICAgMC4xMTc1OTldIG1pY3JvY29kZTogQ1BVMCBzaWc9MHgxMDZhNSwgcGY9MHgxLCByZXZpc2lv
bj0weDExClsgICAgMC4xMTc2MTFdIG1pY3JvY29kZTogQ1BVMSBzaWc9MHgxMDZhNSwgcGY9MHgx
LCByZXZpc2lvbj0weDExClsgICAgMC4xMTc2MjddIG1pY3JvY29kZTogQ1BVMiBzaWc9MHgxMDZh
NSwgcGY9MHgxLCByZXZpc2lvbj0weDExClsgICAgMC4xMTc2NDRdIG1pY3JvY29kZTogQ1BVMyBz
aWc9MHgxMDZhNSwgcGY9MHgxLCByZXZpc2lvbj0weDExClsgICAgMC4xMTc3MDJdIG1pY3JvY29k
ZTogTWljcm9jb2RlIFVwZGF0ZSBEcml2ZXI6IHYyLjAwIDx0aWdyYW5AYWl2YXppYW4uZnNuZXQu
Y28udWs+LCBQZXRlciBPcnViYQpbICAgIDAuMTE3OTIyXSBhdWRpdDogaW5pdGlhbGl6aW5nIG5l
dGxpbmsgc29ja2V0IChkaXNhYmxlZCkKWyAgICAwLjExNzkzNl0gdHlwZT0yMDAwIGF1ZGl0KDEz
NTEwODY0MTAuMzI1OjEpOiBpbml0aWFsaXplZApbICAgIDAuMTE4MzM0XSBib3VuY2UgcG9vbCBz
aXplOiA2NCBwYWdlcwpbICAgIDAuMTE4NDM5XSBWRlM6IERpc2sgcXVvdGFzIGRxdW90XzYuNS4y
ClsgICAgMC4xOTcxNjRdIERxdW90LWNhY2hlIGhhc2ggdGFibGUgZW50cmllczogMTAyNCAob3Jk
ZXIgMCwgNDA5NiBieXRlcykKWyAgICAwLjE5NzIyN10gbXNnbW5pIGhhcyBiZWVuIHNldCB0byAx
MjQ1ClsgICAgMC4xOTc0MDFdIEJsb2NrIGxheWVyIFNDU0kgZ2VuZXJpYyAoYnNnKSBkcml2ZXIg
dmVyc2lvbiAwLjQgbG9hZGVkIChtYWpvciAyNTMpClsgICAgMC4xOTc0MTBdIGlvIHNjaGVkdWxl
ciBub29wIHJlZ2lzdGVyZWQKWyAgICAwLjE5NzQxNV0gaW8gc2NoZWR1bGVyIGRlYWRsaW5lIHJl
Z2lzdGVyZWQKWyAgICAwLjE5NzQzNl0gaW8gc2NoZWR1bGVyIGNmcSByZWdpc3RlcmVkIChkZWZh
dWx0KQpbICAgIDAuMjAwNjkyXSBwY2lmcm9udCBwY2ktMDogYmFja2VuZCBnb2luZyBhd2F5IQpb
ICAgIDAuMjAwNzg2XSBFdmVudC1jaGFubmVsIGRldmljZSBpbnN0YWxsZWQuClsgICAgMC4yMjQy
NTldIEZsb3BweSBkcml2ZShzKTogZmQwIGlzIHVua25vd24gdHlwZSAxNSAodXNiPyksIGZkMSBp
cyB1bmtub3duIHR5cGUgMTUgKHVzYj8pClsgICAgMC4yMjQyNzRdIGZsb3BweTA6IFVuYWJsZSB0
byBncmFiIElSUTYgZm9yIHRoZSBmbG9wcHkgZHJpdmVyClsgICAgMC4yMjU5NDNdIGJyZDogbW9k
dWxlIGxvYWRlZApbICAgIDAuMjI2OTI5XSBsb29wOiBtb2R1bGUgbG9hZGVkClsgICAgMC4yMzk2
MTFdIFVuaWZvcm0gTXVsdGktUGxhdGZvcm0gRS1JREUgZHJpdmVyClsgICAgMC4yMzk4MzJdIGlk
ZS1nZCBkcml2ZXIgMS4xOApbICAgIDAuMjM5ODgxXSBJbml0aWFsaXNpbmcgWGVuIHZpcnR1YWwg
ZXRoZXJuZXQgZHJpdmVyLgpbICAgIDAuMjQxODczXSBibGtmcm9udDogeHZkYTE6IGJhcnJpZXIg
b3IgZmx1c2g6IGRpc2FibGVkClsgICAgMC4yNDU4NTVdIGJsa2Zyb250OiB4dmRiOiBiYXJyaWVy
IG9yIGZsdXNoOiBkaXNhYmxlZApbICAgIDAuMjQ2MTc5XSBpODA0MjogUE5QOiBObyBQUy8yIGNv
bnRyb2xsZXIgZm91bmQuIFByb2JpbmcgcG9ydHMgZGlyZWN0bHkuClsgICAgMC4yNDcwMDZdIGk4
MDQyOiBObyBjb250cm9sbGVyIGZvdW5kClsgICAgMC4yNDcwMDhdICB4dmRiOgpbICAgIDAuMjQ3
MTM4XSBtb3VzZWRldjogUFMvMiBtb3VzZSBkZXZpY2UgY29tbW9uIGZvciBhbGwgbWljZQpbICAg
IDAuMjQ3MzM5XSBTZXR0aW5nIGNhcGFjaXR5IHRvIDI4NTQ3NDgxNgpbICAgIDAuMjQ3MzUwXSB4
dmRiOiBkZXRlY3RlZCBjYXBhY2l0eSBjaGFuZ2UgZnJvbSAwIHRvIDE0NjE2MzEwNTc5MgpbICAg
IDAuMjQ3NTQxXSBORVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDE3ClsgICAgMC4yNDc1
NzddIFVzaW5nIElQSSBOby1TaG9ydGN1dCBtb2RlClsgICAgMC4yNDc3MjhdIHJlZ2lzdGVyZWQg
dGFza3N0YXRzIHZlcnNpb24gMQpbICAgIDAuMzQ3MTI2XSBCSU9TIEVERCBmYWNpbGl0eSB2MC4x
NiAyMDA0LUp1bi0yNSwgMCBkZXZpY2VzIGZvdW5kClsgICAgMC4zNDcxMzZdIEVERCBpbmZvcm1h
dGlvbiBub3QgYXZhaWxhYmxlLgpbICAgIDAuMzQ3MzcyXSBGcmVlaW5nIHVudXNlZCBrZXJuZWwg
bWVtb3J5OiA0MDhrIGZyZWVkClsgICAgMC4zNzM1ODJdIGRyYWN1dDogZHJhY3V0LTAwNC0yNTYu
ZWw2ClsgICAgMC4zOTAzMThdIGRldmljZS1tYXBwZXI6IGlvY3RsOiA0LjIzLjAtaW9jdGwgKDIw
MTItMDctMjUpIGluaXRpYWxpc2VkOiBkbS1kZXZlbEByZWRoYXQuY29tClsgICAgMC4zOTU1MTld
IHVkZXY6IHN0YXJ0aW5nIHZlcnNpb24gMTQ3ClsgICAgMC4zOTU1NjhdIHVkZXZkICg4ODUpOiAv
cHJvYy84ODUvb29tX2FkaiBpcyBkZXByZWNhdGVkLCBwbGVhc2UgdXNlIC9wcm9jLzg4NS9vb21f
c2NvcmVfYWRqIGluc3RlYWQuClsgICAgMC40OTAxODddIGRyYWN1dDogU3RhcnRpbmcgcGx5bW91
dGggZGFlbW9uClsgICAgMC42MzI4NzRdIEVYVDQtZnMgKHh2ZGExKTogbW91bnRlZCBmaWxlc3lz
dGVtIHdpdGggb3JkZXJlZCBkYXRhIG1vZGUuIE9wdHM6IChudWxsKQpbICAgIDAuNjcyNjU1XSBk
cmFjdXQ6IE1vdW50ZWQgcm9vdCBmaWxlc3lzdGVtIC9kZXYveHZkYTEKWyAgICAwLjg3NTgzMV0g
ZHJhY3V0OiAvc2Jpbi9sb2FkX3BvbGljeTogQ2FuJ3QgbG9hZCBwb2xpY3k6IE5vIHN1Y2ggZGV2
aWNlClsgICAgMC45MDQyNjldIGRyYWN1dDogU3dpdGNoaW5nIHJvb3QKWyAgICAxLjIzNDY5Nl0g
dXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciB1c2JmcwpbICAgIDEuMjM0
NzQ4XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIGh1YgpbICAgIDEu
MjM0ODQ1XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBkZXZpY2UgZHJpdmVyIHVzYgpbICAgIDEu
NzQ0NTkyXSB1ZGV2OiBzdGFydGluZyB2ZXJzaW9uIDE0NwpbICAgIDEuODk2MDg0XSBpbnB1dDog
UEMgU3BlYWtlciBhcyAvZGV2aWNlcy9wbGF0Zm9ybS9wY3Nwa3IvaW5wdXQvaW5wdXQwClsgICAg
Mi40NTU1NzZdIEVYVDQtZnMgKHh2ZGExKTogcmUtbW91bnRlZC4gT3B0czogKG51bGwpClsgICAg
Mi44MjExODRdIE5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMTAKWyAgICAyLjgzNzM2
MV0gaXA2X3RhYmxlczogKEMpIDIwMDAtMjAwNiBOZXRmaWx0ZXIgQ29yZSBUZWFtClsgICAgMi45
NTUyNzRdIGlwX3RhYmxlczogKEMpIDIwMDAtMjAwNiBOZXRmaWx0ZXIgQ29yZSBUZWFtCg==

--_005_E71FC5D6F96C3C4B93FC8FF942D924C682F45DE3SBJEXCH1Bwebsen_
Content-Type: application/octet-stream; name="domainWCG.cfg"
Content-Description: domainWCG.cfg
Content-Disposition: attachment; filename="domainWCG.cfg"; size=369;
	creation-date="Mon, 22 Oct 2012 10:09:56 GMT";
	modification-date="Wed, 24 Oct 2012 13:45:52 GMT"
Content-Transfer-Encoding: base64

a2VybmVsID0gIi9yb290L2RvbWFpbldDRy5rZXJuZWwiDQpyYW1kaXNrID0gIi9yb290L2RvbWFp
bldDRy5pbml0cmQuaW1nIg0KZTgyMF9ob3N0PTENCm1lbW9yeT02MTQ0DQpuYW1lID0gIndjZyIN
CnZpZiAgPSBbICdpcD0xNjkuMjU0LjI1NC4zLHZpZm5hbWU9d2NnLjAnIF0NCmRpc2sgPSBbJ3Bo
eTovZGV2L2x2X2FwcGxpYW5jZS93Y2cseHZkYTEsdycsDQogICAgICAgICdwaHk6L2Rldi9zZGIs
eHZkYix3J10NCnJvb3QgID0gIi9kZXYveHZkYTEgcm8iDQpleHRyYT0iaW9tbXU9c29mdCBwcmlu
dGsucHJpbnRrX3RpbWU9MSBjb25zb2xlPWh2YzAiDQpwY2k9WycwMTowMC4wJywnMDE6MDAuMSdd
DQp2Y3B1cz00DQpjcHVzPSI0LDUsNiw3Ig0K

--_005_E71FC5D6F96C3C4B93FC8FF942D924C682F45DE3SBJEXCH1Bwebsen_
Content-Type: application/octet-stream; name="xl-create.output"
Content-Description: xl-create.output
Content-Disposition: attachment; filename="xl-create.output"; size=12062;
	creation-date="Mon, 22 Oct 2012 10:09:56 GMT";
	modification-date="Wed, 24 Oct 2012 13:56:50 GMT"
Content-Transfer-Encoding: base64

W3Jvb3RAbG9jYWxob3N0IH5dIyB4bCAtdnZ2IGNyZWF0ZSBkb21haW5XQ0cuY2ZnIApQYXJzaW5n
IGNvbmZpZyBmcm9tIGRvbWFpbldDRy5jZmcKbGlieGw6IGRlYnVnOiBsaWJ4bF9jcmVhdGUuYzox
MTczOmRvX2RvbWFpbl9jcmVhdGU6IGFvIDB4ODA2YmVmMDogY3JlYXRlOiBob3c9KG5pbCkgY2Fs
bGJhY2s9KG5pbCkgcG9sbGVyPTB4ODA2YjY4OApsaWJ4bDogZGVidWc6IGxpYnhsX2RldmljZS5j
OjIyOTpsaWJ4bF9fZGV2aWNlX2Rpc2tfc2V0X2JhY2tlbmQ6IERpc2sgdmRldj14dmRhMSBzcGVj
LmJhY2tlbmQ9dW5rbm93bgpsaWJ4bDogZGVidWc6IGxpYnhsX2RldmljZS5jOjI2NTpsaWJ4bF9f
ZGV2aWNlX2Rpc2tfc2V0X2JhY2tlbmQ6IERpc2sgdmRldj14dmRhMSwgdXNpbmcgYmFja2VuZCBw
aHkKbGlieGw6IGRlYnVnOiBsaWJ4bF9kZXZpY2UuYzoyMjk6bGlieGxfX2RldmljZV9kaXNrX3Nl
dF9iYWNrZW5kOiBEaXNrIHZkZXY9eHZkYiBzcGVjLmJhY2tlbmQ9dW5rbm93bgpsaWJ4bDogZGVi
dWc6IGxpYnhsX2RldmljZS5jOjI2NTpsaWJ4bF9fZGV2aWNlX2Rpc2tfc2V0X2JhY2tlbmQ6IERp
c2sgdmRldj14dmRiLCB1c2luZyBiYWNrZW5kIHBoeQpsaWJ4bDogZGVidWc6IGxpYnhsX2NyZWF0
ZS5jOjY3Nzppbml0aWF0ZV9kb21haW5fY3JlYXRlOiBydW5uaW5nIGJvb3Rsb2FkZXIKbGlieGw6
IGRlYnVnOiBsaWJ4bF9ib290bG9hZGVyLmM6MzI3OmxpYnhsX19ib290bG9hZGVyX3J1bjogbm8g
Ym9vdGxvYWRlciBjb25maWd1cmVkLCB1c2luZyB1c2VyIHN1cHBsaWVkIGtlcm5lbApsaWJ4bDog
ZGVidWc6IGxpYnhsX2V2ZW50LmM6NTYxOmxpYnhsX19ldl94c3dhdGNoX2RlcmVnaXN0ZXI6IHdh
dGNoIHc9MHg4MDZjMGRjOiBkZXJlZ2lzdGVyIHVucmVnaXN0ZXJlZApkb21haW5idWlsZGVyOiBk
ZXRhaWw6IHhjX2RvbV9hbGxvY2F0ZTogY21kbGluZT0icm9vdD0vZGV2L3h2ZGExIHJvIGlvbW11
PXNvZnQgcHJpbnRrLnByaW50a190aW1lPTEgY29uc29sZT1odmMwIiwgZmVhdHVyZXM9IihudWxs
KSIKbGlieGw6IGRlYnVnOiBsaWJ4bF9kb20uYzozODA6bGlieGxfX2J1aWxkX3B2OiBwdiBrZXJu
ZWwgbWFwcGVkIDAgcGF0aCAvcm9vdC9kb21haW5XQ0cua2VybmVsCgpkb21haW5idWlsZGVyOiBk
ZXRhaWw6IHhjX2RvbV9rZXJuZWxfZmlsZTogZmlsZW5hbWU9Ii9yb290L2RvbWFpbldDRy5rZXJu
ZWwiCmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogeGNfZG9tX21hbGxvY19maWxlbWFwICAgIDogMjA5
NyBrQgpkb21haW5idWlsZGVyOiBkZXRhaWw6IHhjX2RvbV9yYW1kaXNrX2ZpbGU6IGZpbGVuYW1l
PSIvcm9vdC9kb21haW5XQ0cuaW5pdHJkLmltZyIKZG9tYWluYnVpbGRlcjogZGV0YWlsOiB4Y19k
b21fbWFsbG9jX2ZpbGVtYXAgICAgOiAxMDUzMyBrQgpkb21haW5idWlsZGVyOiBkZXRhaWw6IHhj
X2RvbV9ib290X3hlbl9pbml0OiB2ZXIgNC4yLCBjYXBzIHhlbi0zLjAteDg2XzY0IHhlbi0zLjAt
eDg2XzMycCBodm0tMy4wLXg4Nl8zMiBodm0tMy4wLXg4Nl8zMnAgaHZtLTMuMC14ODZfNjQgCmRv
bWFpbmJ1aWxkZXI6IGRldGFpbDogeGNfZG9tX3BhcnNlX2ltYWdlOiBjYWxsZWQKZG9tYWluYnVp
bGRlcjogZGV0YWlsOiB4Y19kb21fZmluZF9sb2FkZXI6IHRyeWluZyBFTEYtZ2VuZXJpYyBsb2Fk
ZXIgLi4uIApkb21haW5idWlsZGVyOiBkZXRhaWw6IGxvYWRlciBwcm9iZSBmYWlsZWQKZG9tYWlu
YnVpbGRlcjogZGV0YWlsOiB4Y19kb21fZmluZF9sb2FkZXI6IHRyeWluZyBMaW51eCBiekltYWdl
IGxvYWRlciAuLi4gCmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogeGNfZG9tX21hbGxvYyAgICAgICAg
ICAgIDogNDA3MyBrQgpkb21haW5idWlsZGVyOiBkZXRhaWw6IHhjX2RvbV9kb19ndW56aXA6IHVu
emlwIG9rLCAweDIwNDQ4ZiAtPiAweDNmYTViYwpkb21haW5idWlsZGVyOiBkZXRhaWw6IGxvYWRl
ciBwcm9iZSBPSwp4YzogZGV0YWlsOiBlbGZfcGFyc2VfYmluYXJ5OiBwaGRyOiBwYWRkcj0weDEw
MDAwMDAgbWVtc3o9MHgzMDQwMDAKeGM6IGRldGFpbDogZWxmX3BhcnNlX2JpbmFyeTogcGhkcjog
cGFkZHI9MHgxMzA0MDAwIG1lbXN6PTB4MzEzMDAwCnhjOiBkZXRhaWw6IGVsZl9wYXJzZV9iaW5h
cnk6IG1lbW9yeTogMHgxMDAwMDAwIC0+IDB4MTYxNzAwMAp4YzogZGV0YWlsOiBlbGZfeGVuX3Bh
cnNlX25vdGU6IEdVRVNUX09TID0gImxpbnV4Igp4YzogZGV0YWlsOiBlbGZfeGVuX3BhcnNlX25v
dGU6IEdVRVNUX1ZFUlNJT04gPSAiMi42Igp4YzogZGV0YWlsOiBlbGZfeGVuX3BhcnNlX25vdGU6
IFhFTl9WRVJTSU9OID0gInhlbi0zLjAiCnhjOiBkZXRhaWw6IGVsZl94ZW5fcGFyc2Vfbm90ZTog
VklSVF9CQVNFID0gMHhjMDAwMDAwMAp4YzogZGV0YWlsOiBlbGZfeGVuX3BhcnNlX25vdGU6IEVO
VFJZID0gMHhjMTMyYzIyYwp4YzogZGV0YWlsOiBlbGZfeGVuX3BhcnNlX25vdGU6IEhZUEVSQ0FM
TF9QQUdFID0gMHhjMTAwMjAwMAp4YzogZGV0YWlsOiBlbGZfeGVuX3BhcnNlX25vdGU6IEZFQVRV
UkVTID0gIiF3cml0YWJsZV9wYWdlX3RhYmxlc3xwYWVfcGdkaXJfYWJvdmVfNGdiIgp4YzogZGV0
YWlsOiBlbGZfeGVuX3BhcnNlX25vdGU6IFBBRV9NT0RFID0gInllcyIKeGM6IGRldGFpbDogZWxm
X3hlbl9wYXJzZV9ub3RlOiBMT0FERVIgPSAiZ2VuZXJpYyIKeGM6IGRldGFpbDogZWxmX3hlbl9w
YXJzZV9ub3RlOiB1bmtub3duIHhlbiBlbGYgbm90ZSAoMHhkKQp4YzogZGV0YWlsOiBlbGZfeGVu
X3BhcnNlX25vdGU6IFNVU1BFTkRfQ0FOQ0VMID0gMHgxCnhjOiBkZXRhaWw6IGVsZl94ZW5fcGFy
c2Vfbm90ZTogSFZfU1RBUlRfTE9XID0gMHhmNTgwMDAwMAp4YzogZGV0YWlsOiBlbGZfeGVuX3Bh
cnNlX25vdGU6IFBBRERSX09GRlNFVCA9IDB4MAp4YzogZGV0YWlsOiBlbGZfeGVuX2FkZHJfY2Fs
Y19jaGVjazogYWRkcmVzc2VzOgp4YzogZGV0YWlsOiAgICAgdmlydF9iYXNlICAgICAgICA9IDB4
YzAwMDAwMDAKeGM6IGRldGFpbDogICAgIGVsZl9wYWRkcl9vZmZzZXQgPSAweDAKeGM6IGRldGFp
bDogICAgIHZpcnRfb2Zmc2V0ICAgICAgPSAweGMwMDAwMDAwCnhjOiBkZXRhaWw6ICAgICB2aXJ0
X2tzdGFydCAgICAgID0gMHhjMTAwMDAwMAp4YzogZGV0YWlsOiAgICAgdmlydF9rZW5kICAgICAg
ICA9IDB4YzE2MTcwMDAKeGM6IGRldGFpbDogICAgIHZpcnRfZW50cnkgICAgICAgPSAweGMxMzJj
MjJjCnhjOiBkZXRhaWw6ICAgICBwMm1fYmFzZSAgICAgICAgID0gMHhmZmZmZmZmZmZmZmZmZmZm
CmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogeGNfZG9tX3BhcnNlX2VsZl9rZXJuZWw6IHhlbi0zLjAt
eDg2XzMycDogMHhjMTAwMDAwMCAtPiAweGMxNjE3MDAwCmRvbWFpbmJ1aWxkZXI6IGRldGFpbDog
eGNfZG9tX21lbV9pbml0OiBtZW0gNjE0NCBNQiwgcGFnZXMgMHgxODAwMDAgcGFnZXMsIDRrIGVh
Y2gKZG9tYWluYnVpbGRlcjogZGV0YWlsOiB4Y19kb21fbWVtX2luaXQ6IDB4MTgwMDAwIHBhZ2Vz
CmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogeGNfZG9tX2Jvb3RfbWVtX2luaXQ6IGNhbGxlZApkb21h
aW5idWlsZGVyOiBkZXRhaWw6IHg4Nl9jb21wYXQ6IGd1ZXN0IHhlbi0zLjAteDg2XzMycCwgYWRk
cmVzcyBzaXplIDMyCmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogeGNfZG9tX21hbGxvYyAgICAgICAg
ICAgIDogNjE0NCBrQgpkb21haW5idWlsZGVyOiBkZXRhaWw6IHhjX2RvbV9idWlsZF9pbWFnZTog
Y2FsbGVkCmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogeGNfZG9tX2FsbG9jX3NlZ21lbnQ6ICAga2Vy
bmVsICAgICAgIDogMHhjMTAwMDAwMCAtPiAweGMxNjE3MDAwICAocGZuIDB4MTAwMCArIDB4NjE3
IHBhZ2VzKQpkb21haW5idWlsZGVyOiBkZXRhaWw6IHhjX2RvbV9wZm5fdG9fcHRyOiBkb21VIG1h
cHBpbmc6IHBmbiAweDEwMDArMHg2MTcgYXQgMHhiNWI4MTAwMAp4YzogZGV0YWlsOiBlbGZfbG9h
ZF9iaW5hcnk6IHBoZHIgMCBhdCAweDB4YjViODEwMDAgLT4gMHgweGI1ZTg1MDAwCnhjOiBkZXRh
aWw6IGVsZl9sb2FkX2JpbmFyeTogcGhkciAxIGF0IDB4MHhiNWU4NTAwMCAtPiAweDB4YjVmMTcw
MDAKZG9tYWluYnVpbGRlcjogZGV0YWlsOiB4Y19kb21fYWxsb2Nfc2VnbWVudDogICByYW1kaXNr
ICAgICAgOiAweGMxNjE3MDAwIC0+IDB4YzJlODAwMDAgIChwZm4gMHgxNjE3ICsgMHgxODY5IHBh
Z2VzKQpkb21haW5idWlsZGVyOiBkZXRhaWw6IHhjX2RvbV9tYWxsb2MgICAgICAgICAgICA6IDE0
NiBrQgpkb21haW5idWlsZGVyOiBkZXRhaWw6IHhjX2RvbV9wZm5fdG9fcHRyOiBkb21VIG1hcHBp
bmc6IHBmbiAweDE2MTcrMHgxODY5IGF0IDB4YjQyZjMwMDAKZG9tYWluYnVpbGRlcjogZGV0YWls
OiB4Y19kb21fZG9fZ3VuemlwOiB1bnppcCBvaywgMHhhNDk1NTMgLT4gMHgxODY4NDEwCmRvbWFp
bmJ1aWxkZXI6IGRldGFpbDogeGNfZG9tX2FsbG9jX3NlZ21lbnQ6ICAgcGh5czJtYWNoICAgIDog
MHhjMmU4MDAwMCAtPiAweGMzNDgwMDAwICAocGZuIDB4MmU4MCArIDB4NjAwIHBhZ2VzKQpkb21h
aW5idWlsZGVyOiBkZXRhaWw6IHhjX2RvbV9wZm5fdG9fcHRyOiBkb21VIG1hcHBpbmc6IHBmbiAw
eDJlODArMHg2MDAgYXQgMHhiM2NmMzAwMApkb21haW5idWlsZGVyOiBkZXRhaWw6IHhjX2RvbV9h
bGxvY19wYWdlICAgOiAgIHN0YXJ0IGluZm8gICA6IDB4YzM0ODAwMDAgKHBmbiAweDM0ODApCmRv
bWFpbmJ1aWxkZXI6IGRldGFpbDogeGNfZG9tX2FsbG9jX3BhZ2UgICA6ICAgeGVuc3RvcmUgICAg
IDogMHhjMzQ4MTAwMCAocGZuIDB4MzQ4MSkKZG9tYWluYnVpbGRlcjogZGV0YWlsOiB4Y19kb21f
YWxsb2NfcGFnZSAgIDogICBjb25zb2xlICAgICAgOiAweGMzNDgyMDAwIChwZm4gMHgzNDgyKQpk
b21haW5idWlsZGVyOiBkZXRhaWw6IG5yX3BhZ2VfdGFibGVzOiAweDAwMDAwMDAwZmZmZmZmZmYv
MzI6IDB4MDAwMDAwMDAwMDAwMDAwMCAtPiAweGZmZmZmZmZmZmZmZmZmZmYsIDEgdGFibGUocykK
ZG9tYWluYnVpbGRlcjogZGV0YWlsOiBucl9wYWdlX3RhYmxlczogMHgwMDAwMDAwMDNmZmZmZmZm
LzMwOiAweDAwMDAwMDAwYzAwMDAwMDAgLT4gMHgwMDAwMDAwMGZmZmZmZmZmLCAxIHRhYmxlKHMp
CmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogbnJfcGFnZV90YWJsZXM6IDB4MDAwMDAwMDAwMDFmZmZm
Zi8yMTogMHgwMDAwMDAwMGMwMDAwMDAwIC0+IDB4MDAwMDAwMDBjMzdmZmZmZiwgMjggdGFibGUo
cykKZG9tYWluYnVpbGRlcjogZGV0YWlsOiB4Y19kb21fYWxsb2Nfc2VnbWVudDogICBwYWdlIHRh
YmxlcyAgOiAweGMzNDgzMDAwIC0+IDB4YzM0YTEwMDAgIChwZm4gMHgzNDgzICsgMHgxZSBwYWdl
cykKZG9tYWluYnVpbGRlcjogZGV0YWlsOiB4Y19kb21fcGZuX3RvX3B0cjogZG9tVSBtYXBwaW5n
OiBwZm4gMHgzNDgzKzB4MWUgYXQgMHhiM2NkNTAwMApkb21haW5idWlsZGVyOiBkZXRhaWw6IHhj
X2RvbV9hbGxvY19wYWdlICAgOiAgIGJvb3Qgc3RhY2sgICA6IDB4YzM0YTEwMDAgKHBmbiAweDM0
YTEpCmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogeGNfZG9tX2J1aWxkX2ltYWdlICA6IHZpcnRfYWxs
b2NfZW5kIDogMHhjMzRhMjAwMApkb21haW5idWlsZGVyOiBkZXRhaWw6IHhjX2RvbV9idWlsZF9p
bWFnZSAgOiB2aXJ0X3BndGFiX2VuZCA6IDB4YzM4MDAwMDAKZG9tYWluYnVpbGRlcjogZGV0YWls
OiB4Y19kb21fYm9vdF9pbWFnZTogY2FsbGVkCmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogYXJjaF9z
ZXR1cF9ib290ZWFybHk6IGRvaW5nIG5vdGhpbmcKZG9tYWluYnVpbGRlcjogZGV0YWlsOiB4Y19k
b21fY29tcGF0X2NoZWNrOiBzdXBwb3J0ZWQgZ3Vlc3QgdHlwZTogeGVuLTMuMC14ODZfNjQKZG9t
YWluYnVpbGRlcjogZGV0YWlsOiB4Y19kb21fY29tcGF0X2NoZWNrOiBzdXBwb3J0ZWQgZ3Vlc3Qg
dHlwZTogeGVuLTMuMC14ODZfMzJwIDw9IG1hdGNoZXMKZG9tYWluYnVpbGRlcjogZGV0YWlsOiB4
Y19kb21fY29tcGF0X2NoZWNrOiBzdXBwb3J0ZWQgZ3Vlc3QgdHlwZTogaHZtLTMuMC14ODZfMzIK
ZG9tYWluYnVpbGRlcjogZGV0YWlsOiB4Y19kb21fY29tcGF0X2NoZWNrOiBzdXBwb3J0ZWQgZ3Vl
c3QgdHlwZTogaHZtLTMuMC14ODZfMzJwCmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogeGNfZG9tX2Nv
bXBhdF9jaGVjazogc3VwcG9ydGVkIGd1ZXN0IHR5cGU6IGh2bS0zLjAteDg2XzY0CmRvbWFpbmJ1
aWxkZXI6IGRldGFpbDogeGNfZG9tX3VwZGF0ZV9ndWVzdF9wMm06IGRzdCAzMmJpdCwgcGFnZXMg
MHgxODAwMDAKZG9tYWluYnVpbGRlcjogZGV0YWlsOiBjbGVhcl9wYWdlOiBwZm4gMHgzNDgyLCBt
Zm4gMHg0MmM0YjAKZG9tYWluYnVpbGRlcjogZGV0YWlsOiBjbGVhcl9wYWdlOiBwZm4gMHgzNDgx
LCBtZm4gMHg0MmM0YjEKZG9tYWluYnVpbGRlcjogZGV0YWlsOiB4Y19kb21fcGZuX3RvX3B0cjog
ZG9tVSBtYXBwaW5nOiBwZm4gMHgzNDgwKzB4MSBhdCAweGIzY2QyMDAwCmRvbWFpbmJ1aWxkZXI6
IGRldGFpbDogc3RhcnRfaW5mb194ODZfMzI6IGNhbGxlZApkb21haW5idWlsZGVyOiBkZXRhaWw6
IHNldHVwX2h5cGVyY2FsbF9wYWdlOiB2YWRkcj0weGMxMDAyMDAwIHBmbj0weDEwMDIKZG9tYWlu
YnVpbGRlcjogZGV0YWlsOiBkb21haW4gYnVpbGRlciBtZW1vcnkgZm9vdHByaW50CmRvbWFpbmJ1
aWxkZXI6IGRldGFpbDogICAgYWxsb2NhdGVkCmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogICAgICAg
bWFsbG9jICAgICAgICAgICAgIDogMTA0Mzkga0IKZG9tYWluYnVpbGRlcjogZGV0YWlsOiAgICAg
ICBhbm9uIG1tYXAgICAgICAgICAgOiAwIGJ5dGVzCmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogICAg
bWFwcGVkCmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogICAgICAgZmlsZSBtbWFwICAgICAgICAgIDog
MTI2MzAga0IKZG9tYWluYnVpbGRlcjogZGV0YWlsOiAgICAgICBkb21VIG1tYXAgICAgICAgICAg
OiAzNiBNQgpkb21haW5idWlsZGVyOiBkZXRhaWw6IGFyY2hfc2V0dXBfYm9vdGxhdGU6IHNoYXJl
ZF9pbmZvOiBwZm4gMHgwLCBtZm4gMHhiZjIyZgpkb21haW5idWlsZGVyOiBkZXRhaWw6IHNoYXJl
ZF9pbmZvX3g4Nl8zMjogY2FsbGVkCmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogdmNwdV94ODZfMzI6
IGNhbGxlZApkb21haW5idWlsZGVyOiBkZXRhaWw6IHZjcHVfeDg2XzMyOiBjcjM6IHBmbiAweDM0
ODMgbWZuIDB4NDJjNGFmCmRvbWFpbmJ1aWxkZXI6IGRldGFpbDogbGF1bmNoX3ZtOiBjYWxsZWQs
IGN0eHQ9MHhiZmRmM2M1Ywpkb21haW5idWlsZGVyOiBkZXRhaWw6IHhjX2RvbV9yZWxlYXNlOiBj
YWxsZWQKbGlieGw6IGRlYnVnOiBsaWJ4bF9kZXZpY2UuYzoyMjk6bGlieGxfX2RldmljZV9kaXNr
X3NldF9iYWNrZW5kOiBEaXNrIHZkZXY9eHZkYTEgc3BlYy5iYWNrZW5kPXBoeQpsaWJ4bDogZGVi
dWc6IGxpYnhsX2V2ZW50LmM6NTEyOmxpYnhsX19ldl94c3dhdGNoX3JlZ2lzdGVyOiB3YXRjaCB3
PTB4ODA2Y2JjOCB3cGF0aD0vbG9jYWwvZG9tYWluLzAvYmFja2VuZC92YmQvMi81MTcxMy9zdGF0
ZSB0b2tlbj0zLzA6IHJlZ2lzdGVyIHNsb3RudW09MwpsaWJ4bDogZGVidWc6IGxpYnhsX2Rldmlj
ZS5jOjIyOTpsaWJ4bF9fZGV2aWNlX2Rpc2tfc2V0X2JhY2tlbmQ6IERpc2sgdmRldj14dmRiIHNw
ZWMuYmFja2VuZD1waHkKbGlieGw6IGRlYnVnOiBsaWJ4bF9kZXZpY2UuYzoyMjk6bGlieGxfX2Rl
dmljZV9kaXNrX3NldF9iYWNrZW5kOiBEaXNrIHZkZXY9eHZkYiBzcGVjLmJhY2tlbmQ9cGh5Cmxp
YnhsOiBkZWJ1ZzogbGlieGxfZXZlbnQuYzo1MTI6bGlieGxfX2V2X3hzd2F0Y2hfcmVnaXN0ZXI6
IHdhdGNoIHc9MHg4MDZkNTM4IHdwYXRoPS9sb2NhbC9kb21haW4vMC9iYWNrZW5kL3ZiZC8yLzUx
NzI4L3N0YXRlIHRva2VuPTIvMTogcmVnaXN0ZXIgc2xvdG51bT0yCmxpYnhsOiBkZWJ1ZzogbGli
eGxfY3JlYXRlLmM6MTE4Njpkb19kb21haW5fY3JlYXRlOiBhbyAweDgwNmJlZjA6IGlucHJvZ3Jl
c3M6IHBvbGxlcj0weDgwNmI2ODgsIGZsYWdzPWkKbGlieGw6IGRlYnVnOiBsaWJ4bF9ldmVudC5j
OjQ1Nzp3YXRjaGZkX2NhbGxiYWNrOiB3YXRjaCB3PTB4ODA2Y2JjOCB3cGF0aD0vbG9jYWwvZG9t
YWluLzAvYmFja2VuZC92YmQvMi81MTcxMy9zdGF0ZSB0b2tlbj0zLzA6IGV2ZW50IGVwYXRoPS9s
b2NhbC9kb21haW4vMC9iYWNrZW5kL3ZiZC8yLzUxNzEzL3N0YXRlCmxpYnhsOiBkZWJ1ZzogbGli
eGxfZXZlbnQuYzo1OTY6ZGV2c3RhdGVfd2F0Y2hfY2FsbGJhY2s6IGJhY2tlbmQgL2xvY2FsL2Rv
bWFpbi8wL2JhY2tlbmQvdmJkLzIvNTE3MTMvc3RhdGUgd2FudGVkIHN0YXRlIDIgb2sKbGlieGw6
IGRlYnVnOiBsaWJ4bF9ldmVudC5jOjU0OTpsaWJ4bF9fZXZfeHN3YXRjaF9kZXJlZ2lzdGVyOiB3
YXRjaCB3PTB4ODA2Y2JjOCB3cGF0aD0vbG9jYWwvZG9tYWluLzAvYmFja2VuZC92YmQvMi81MTcx
My9zdGF0ZSB0b2tlbj0zLzA6IGRlcmVnaXN0ZXIgc2xvdG51bT0zCmxpYnhsOiBkZWJ1ZzogbGli
eGxfZXZlbnQuYzo1NjE6bGlieGxfX2V2X3hzd2F0Y2hfZGVyZWdpc3Rlcjogd2F0Y2ggdz0weDgw
NmNiYzg6IGRlcmVnaXN0ZXIgdW5yZWdpc3RlcmVkCmxpYnhsOiBkZWJ1ZzogbGlieGxfZGV2aWNl
LmM6OTE2OmRldmljZV9ob3RwbHVnOiBjYWxsaW5nIGhvdHBsdWcgc2NyaXB0OiAvZXRjL3hlbi9z
Y3JpcHRzL2Jsb2NrIGFkZApsaWJ4bDogZGVidWc6IGxpYnhsX2V2ZW50LmM6NDI2OndhdGNoZmRf
Y2FsbGJhY2s6IHdhdGNoIGVwYXRoPS9sb2NhbC9kb21haW4vMC9iYWNrZW5kL3ZiZC8yLzUxNzEz
L3N0YXRlIHRva2VuPTMvMDogZW1wdHkgc2xvdApsaWJ4bDogZGVidWc6IGxpYnhsX2V2ZW50LmM6
NDU3OndhdGNoZmRfY2FsbGJhY2s6IHdhdGNoIHc9MHg4MDZkNTM4IHdwYXRoPS9sb2NhbC9kb21h
aW4vMC9iYWNrZW5kL3ZiZC8yLzUxNzI4L3N0YXRlIHRva2VuPTIvMTogZXZlbnQgZXBhdGg9L2xv
Y2FsL2RvbWFpbi8wL2JhY2tlbmQvdmJkLzIvNTE3Mjgvc3RhdGUKbGlieGw6IGRlYnVnOiBsaWJ4
bF9ldmVudC5jOjU5NjpkZXZzdGF0ZV93YXRjaF9jYWxsYmFjazogYmFja2VuZCAvbG9jYWwvZG9t
YWluLzAvYmFja2VuZC92YmQvMi81MTcyOC9zdGF0ZSB3YW50ZWQgc3RhdGUgMiBvawpsaWJ4bDog
ZGVidWc6IGxpYnhsX2V2ZW50LmM6NTQ5OmxpYnhsX19ldl94c3dhdGNoX2RlcmVnaXN0ZXI6IHdh
dGNoIHc9MHg4MDZkNTM4IHdwYXRoPS9sb2NhbC9kb21haW4vMC9iYWNrZW5kL3ZiZC8yLzUxNzI4
L3N0YXRlIHRva2VuPTIvMTogZGVyZWdpc3RlciBzbG90bnVtPTIKbGlieGw6IGRlYnVnOiBsaWJ4
bF9ldmVudC5jOjU2MTpsaWJ4bF9fZXZfeHN3YXRjaF9kZXJlZ2lzdGVyOiB3YXRjaCB3PTB4ODA2
ZDUzODogZGVyZWdpc3RlciB1bnJlZ2lzdGVyZWQKbGlieGw6IGRlYnVnOiBsaWJ4bF9kZXZpY2Uu
Yzo5MTY6ZGV2aWNlX2hvdHBsdWc6IGNhbGxpbmcgaG90cGx1ZyBzY3JpcHQ6IC9ldGMveGVuL3Nj
cmlwdHMvYmxvY2sgYWRkCmxpYnhsOiBkZWJ1ZzogbGlieGxfZXZlbnQuYzo0MjY6d2F0Y2hmZF9j
YWxsYmFjazogd2F0Y2ggZXBhdGg9L2xvY2FsL2RvbWFpbi8wL2JhY2tlbmQvdmJkLzIvNTE3Mjgv
c3RhdGUgdG9rZW49Mi8xOiBlbXB0eSBzbG90CmxpYnhsOiBkZWJ1ZzogbGlieGxfZXZlbnQuYzo1
MTI6bGlieGxfX2V2X3hzd2F0Y2hfcmVnaXN0ZXI6IHdhdGNoIHc9MHg4MDZlYjIwIHdwYXRoPS9s
b2NhbC9kb21haW4vMC9iYWNrZW5kL3ZpZi8yLzAvc3RhdGUgdG9rZW49Mi8yOiByZWdpc3RlciBz
bG90bnVtPTIKbGlieGw6IGRlYnVnOiBsaWJ4bF9ldmVudC5jOjQ1Nzp3YXRjaGZkX2NhbGxiYWNr
OiB3YXRjaCB3PTB4ODA2ZWIyMCB3cGF0aD0vbG9jYWwvZG9tYWluLzAvYmFja2VuZC92aWYvMi8w
L3N0YXRlIHRva2VuPTIvMjogZXZlbnQgZXBhdGg9L2xvY2FsL2RvbWFpbi8wL2JhY2tlbmQvdmlm
LzIvMC9zdGF0ZQpsaWJ4bDogZGVidWc6IGxpYnhsX2V2ZW50LmM6NjAwOmRldnN0YXRlX3dhdGNo
X2NhbGxiYWNrOiBiYWNrZW5kIC9sb2NhbC9kb21haW4vMC9iYWNrZW5kL3ZpZi8yLzAvc3RhdGUg
d2FudGVkIHN0YXRlIDIgc3RpbGwgd2FpdGluZyBzdGF0ZSAxCmxpYnhsOiBkZWJ1ZzogbGlieGxf
ZXZlbnQuYzo0NTc6d2F0Y2hmZF9jYWxsYmFjazogd2F0Y2ggdz0weDgwNmViMjAgd3BhdGg9L2xv
Y2FsL2RvbWFpbi8wL2JhY2tlbmQvdmlmLzIvMC9zdGF0ZSB0b2tlbj0yLzI6IGV2ZW50IGVwYXRo
PS9sb2NhbC9kb21haW4vMC9iYWNrZW5kL3ZpZi8yLzAvc3RhdGUKbGlieGw6IGRlYnVnOiBsaWJ4
bF9ldmVudC5jOjU5NjpkZXZzdGF0ZV93YXRjaF9jYWxsYmFjazogYmFja2VuZCAvbG9jYWwvZG9t
YWluLzAvYmFja2VuZC92aWYvMi8wL3N0YXRlIHdhbnRlZCBzdGF0ZSAyIG9rCmxpYnhsOiBkZWJ1
ZzogbGlieGxfZXZlbnQuYzo1NDk6bGlieGxfX2V2X3hzd2F0Y2hfZGVyZWdpc3Rlcjogd2F0Y2gg
dz0weDgwNmViMjAgd3BhdGg9L2xvY2FsL2RvbWFpbi8wL2JhY2tlbmQvdmlmLzIvMC9zdGF0ZSB0
b2tlbj0yLzI6IGRlcmVnaXN0ZXIgc2xvdG51bT0yCmxpYnhsOiBkZWJ1ZzogbGlieGxfZXZlbnQu
Yzo1NjE6bGlieGxfX2V2X3hzd2F0Y2hfZGVyZWdpc3Rlcjogd2F0Y2ggdz0weDgwNmViMjA6IGRl
cmVnaXN0ZXIgdW5yZWdpc3RlcmVkCmxpYnhsOiBkZWJ1ZzogbGlieGxfZGV2aWNlLmM6OTE2OmRl
dmljZV9ob3RwbHVnOiBjYWxsaW5nIGhvdHBsdWcgc2NyaXB0OiAvZXRjL3hlbi9zY3JpcHRzL3Zp
Zi1icmlkZ2Ugb25saW5lCmxpYnhsOiBlcnJvcjogbGlieGxfcGNpLmM6MTA1NTpsaWJ4bF9fZGV2
aWNlX3BjaV9hZGQ6IFBDSSBkZXZpY2UgMDoxOjAuMCBpcyBub3QgYXNzaWduYWJsZQpsaWJ4bDog
ZXJyb3I6IGxpYnhsX3BjaS5jOjEwNTU6bGlieGxfX2RldmljZV9wY2lfYWRkOiBQQ0kgZGV2aWNl
IDA6MTowLjEgaXMgbm90IGFzc2lnbmFibGUKbGlieGw6IGRlYnVnOiBsaWJ4bF9wY2kuYzo4NTps
aWJ4bF9fY3JlYXRlX3BjaV9iYWNrZW5kOiBDcmVhdGluZyBwY2kgYmFja2VuZApsaWJ4bDogZGVi
dWc6IGxpYnhsX3g4Ni5jOjkwOmU4MjBfc2FuaXRpemU6IE1lbW9yeTogNjI5MTQ1NmtCIEVuZCBv
ZiBSQU06IDB4YmY2OTkgKFBGTikgRGVsdGE6IDMxNTUzNTZrQiwgUENJIHN0YXJ0OiAzMTM2MTAw
a0IgKDB4YmY2OTkgUEZOKSwgQmFsbG9vbiAwa0IKCmxpYnhsOiBkZWJ1ZzogbGlieGxfeDg2LmM6
MjEwOmU4MjBfc2FuaXRpemU6IDogIFswIC0+IGJmNjk5XSBSQU0KbGlieGw6IGRlYnVnOiBsaWJ4
bF94ODYuYzoyMTA6ZTgyMF9zYW5pdGl6ZTogOiAgW2JmNjk5IC0+IGJmNmFmXSBSZXNlcnZlZAps
aWJ4bDogZGVidWc6IGxpYnhsX3g4Ni5jOjIxMDplODIwX3Nhbml0aXplOiA6ICBbYmY2YWYgLT4g
YmY2Y2VdIEFDUEkKbGlieGw6IGRlYnVnOiBsaWJ4bF94ODYuYzoyMTA6ZTgyMF9zYW5pdGl6ZTog
OiAgW2JmNmNlIC0+IGMwMDAwXSBSZXNlcnZlZApsaWJ4bDogZGVidWc6IGxpYnhsX3g4Ni5jOjIx
MDplODIwX3Nhbml0aXplOiA6ICBbZTAwMDAgLT4gZjAwMDBdIFJlc2VydmVkCmxpYnhsOiBkZWJ1
ZzogbGlieGxfeDg2LmM6MjEwOmU4MjBfc2FuaXRpemU6IDogIFtmZTAwMCAtPiAxMDAwMDBdIFJl
c2VydmVkCmxpYnhsOiBkZWJ1ZzogbGlieGxfZXZlbnQuYzoxNjY3OmxpYnhsX19hb19wcm9ncmVz
c19yZXBvcnQ6IGFvIDB4ODA2YmVmMDogcHJvZ3Jlc3MgcmVwb3J0OiBpZ25vcmVkCmxpYnhsOiBk
ZWJ1ZzogbGlieGxfZXZlbnQuYzoxNDk3OmxpYnhsX19hb19jb21wbGV0ZTogYW8gMHg4MDZiZWYw
OiBjb21wbGV0ZSwgcmM9MApsaWJ4bDogZGVidWc6IGxpYnhsX2V2ZW50LmM6MTQ2OTpsaWJ4bF9f
YW9fX2Rlc3Ryb3k6IGFvIDB4ODA2YmVmMDogZGVzdHJveQpEYWVtb24gcnVubmluZyB3aXRoIFBJ
RCA0NjYzCnhjOiBkZWJ1ZzogaHlwZXJjYWxsIGJ1ZmZlcjogdG90YWwgYWxsb2NhdGlvbnM6MTg1
IHRvdGFsIHJlbGVhc2VzOjE4NQp4YzogZGVidWc6IGh5cGVyY2FsbCBidWZmZXI6IGN1cnJlbnQg
YWxsb2NhdGlvbnM6MCBtYXhpbXVtIGFsbG9jYXRpb25zOjIKeGM6IGRlYnVnOiBoeXBlcmNhbGwg
YnVmZmVyOiBjYWNoZSBjdXJyZW50IHNpemU6Mgp4YzogZGVidWc6IGh5cGVyY2FsbCBidWZmZXI6
IGNhY2hlIGhpdHM6MTc4IG1pc3NlczoyIHRvb2JpZzo1Cgo=

--_005_E71FC5D6F96C3C4B93FC8FF942D924C682F45DE3SBJEXCH1Bwebsen_
Content-Type: application/octet-stream; name="xl-list.output"
Content-Description: xl-list.output
Content-Disposition: attachment; filename="xl-list.output"; size=268;
	creation-date="Mon, 22 Oct 2012 10:09:56 GMT";
	modification-date="Wed, 24 Oct 2012 13:57:17 GMT"
Content-Transfer-Encoding: base64

W3Jvb3RAbG9jYWxob3N0IH5dIyB4bCBsaXN0Ck5hbWUgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgSUQgICBNZW0gVkNQVXMgICAgICBTdGF0ZSAgIFRpbWUocykKRG9tYWlu
LTAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMCAgMjA0NyAgICAgMiAgICAg
ci0tLS0tICAgICAgNDAuMwp3Y2cgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAyICA1MTEwICAgICA0ICAgICAtYi0tLS0gICAgICAyNy4wCg==

--_005_E71FC5D6F96C3C4B93FC8FF942D924C682F45DE3SBJEXCH1Bwebsen_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_005_E71FC5D6F96C3C4B93FC8FF942D924C682F45DE3SBJEXCH1Bwebsen_--


From xen-devel-bounces@lists.xen.org Wed Oct 24 06:06:18 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 06:06:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQu6B-0002cy-9M; Wed, 24 Oct 2012 06:05:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQu69-0002cg-EN; Wed, 24 Oct 2012 06:05:49 +0000
Received: from [85.158.139.83:26389] by server-16.bemta-5.messagelabs.com id
	AB/0F-04786-C3587805; Wed, 24 Oct 2012 06:05:48 +0000
X-Env-Sender: hufan@websense.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1351058744!32331105!1
X-Originating-IP: [208.87.233.190]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljg3LjIzMy4xOTAgPT4gMTc5MDcxOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27596 invoked from network); 24 Oct 2012 06:05:46 -0000
Received: from cluster-g.mailcontrol.com (HELO cluster-g.mailcontrol.com)
	(208.87.233.190)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Oct 2012 06:05:46 -0000
Received: from ssdwbsnapp.websense.com (static-204-15-65-158.websense.com
	[204.15.65.158] (may be forged))
	by rly33g.srv.mailcontrol.com (MailControl) with ESMTP id
	q9O65frx006790
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 24 Oct 2012 07:05:41 +0100
Received: from SSDEXCH1A.websense.com (unknown [10.8.1.91])
	by Websense Email Security Gateway with ESMTP id BE4FB1000002;
	Tue, 23 Oct 2012 23:05:23 -0700 (PDT)
Received: from SBJEXCH2A.websense.com (10.32.8.111) by SSDEXCH1A.websense.com
	(10.8.1.91) with Microsoft SMTP Server (TLS) id 14.2.283.3;
	Tue, 23 Oct 2012 23:05:41 -0700
Received: from SBJEXCH1B.websense.com ([169.254.2.203]) by
	SBJEXCH2A.websense.com ([::1]) with mapi id 14.02.0283.003;
	Wed, 24 Oct 2012 14:05:36 +0800
From: "Fan, Huaxiang" 
To: "Fan, Huaxiang" , "xen-devel@lists.xen.org"
	
Thread-Topic: e820_host and 3G limit
Thread-Index: Ac2tqU9Lub39PN+YQ/+qrymARk/PPgEBAOfQ
Date: Wed, 24 Oct 2012 06:05:35 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.32.134.111]
MIME-Version: 1.0
X-Scanned-By: MailControl 10515.0 (www.mailcontrol.com) on 10.71.0.143
Cc: "xen-users@lists.xen.org" 
Subject: Re: [Xen-devel] e820_host and 3G limit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0710728833721381800=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0710728833721381800==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_E71FC5D6F96C3C4B93FC8FF942D924C682F45E06SBJEXCH1Bwebsen_"

--_000_E71FC5D6F96C3C4B93FC8FF942D924C682F45E06SBJEXCH1Bwebsen_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,
I've tried latest stable kernel 3.6.3 without any luck ):
Thanks for your attention in advance.
Huaxiang

From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-bounces@lists.xen.o=
rg] On Behalf Of Fan, Huaxiang
Sent: Friday, October 19, 2012 11:40 AM
To: xen-devel@lists.xen.org
Cc: xen-users@lists.xen.org
Subject: [Xen-devel] e820_host and 3G limit

Hi,

I was told e820_host is used to solve 3G limit on domu problem when PCI pas=
sthru happens. But I failed to tackle this problem using xen 4.2 and kernel=
 3.4.4

Here is my environment:
Xen hypervisor and tools: 4.2
Dom0 kernel 2.6.32.57
Domu kernel 3.4.4
All above is 64bit

Here is my domu cfg:
kernel =3D "/root/domainWCG.kernel"
ramdisk =3D "/root/domainWCG.initrd.img"
e820_host=3D1
memory=3D5120
name =3D "wcg"
vif  =3D [ 'ip=3D169.254.254.1,vifname=3Dwcg.0' ]
disk =3D ['phy:/dev/lv_appliance/wcg,xvda1,w',
        'phy:/dev/sdb,xvdb,w']
root  =3D "/dev/xvda1 ro"
extra=3D"iommu=3Dsoft printk.printk_time=3D1 console=3Dhvc0"
#pci=3D['01:00.0','01:00.1']
vcpus=3D4
cpus=3D"4,5,6,7"

Here is the output on dom0:
# xl list
Name                                        ID   Mem VCPUs      State   Tim=
e(s)
Domain-0                                     0  1677     2     r-----    22=
37.9
wcg                                         72  4086     4     -b----      =
34.9

My question#1:
Dom0 memory has been shrink from 2048 to 1677. Wcg domu only allocated with=
 4086 even I assigned 5120. Why?

Here is the output on wcg domu:
# cat /proc/meminfo | head -10
MemTotal:        2999156 kB
MemFree:         2919760 kB
Buffers:            4000 kB
Cached:            40656 kB
SwapCached:            0 kB
Active:            22852 kB
Inactive:          31776 kB
Active(anon):      10080 kB
Inactive(anon):       12 kB
Active(file):      12772 kB

My question#2:
Why the domu kernel only recognizes 3G memory even I actually allocate 5G t=
o it?

Appendix
E820 memory map on wcg domu

[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  Xen: 0000000000000000 - 00000000000a0000 (usable)
[    0.000000]  Xen: 00000000000a0000 - 0000000000100000 (reserved)
[    0.000000]  Xen: 0000000000100000 - 00000000bf699000 (usable)
[    0.000000]  Xen: 00000000bf699000 - 00000000bf6af000 (reserved)
[    0.000000]  Xen: 00000000bf6af000 - 00000000bf6ce000 (ACPI data)
[    0.000000]  Xen: 00000000bf6ce000 - 00000000c0000000 (reserved)
[    0.000000]  Xen: 00000000e0000000 - 00000000f0000000 (reserved)
[    0.000000]  Xen: 00000000fe000000 - 0000000100000000 (reserved)

E820 memory map on dom0
BIOS-provided physical RAM map:
Oct 18 05:26:34 localhost kernel: BIOS-e820: 0000000000000000 - 00000000000=
9d000 (usable)
Oct 18 05:26:34 localhost kernel: BIOS-e820: 0000000000100000 - 00000000bf6=
99000 (usable)
Oct 18 05:26:34 localhost kernel: BIOS-e820: 00000000bf699000 - 00000000bf6=
af000 (reserved)
Oct 18 05:26:34 localhost kernel: BIOS-e820: 00000000bf6af000 - 00000000bf6=
ce000 (ACPI data)
Oct 18 05:26:34 localhost kernel: BIOS-e820: 00000000bf6ce000 - 00000000c00=
00000 (reserved)
Oct 18 05:26:34 localhost kernel: BIOS-e820: 00000000e0000000 - 00000000f00=
00000 (reserved)
Oct 18 05:26:34 localhost kernel: BIOS-e820: 00000000fe000000 - 00000001000=
00000 (reserved)
Oct 18 05:26:34 localhost kernel: BIOS-e820: 0000000100000000 - 00000002400=
00000 (usable)

I am looking forward your reply. Thanks in advance.
HUAXIANG FAN
Software Engineer II

WEBSENSE NETWORK SECURITY TECHNOLOGY R&D (BEIJING) CO. LTD.
ph: +8610.5884.4327
fax: +8610.5884.4727
www.websense.cn

Websense TRITON(tm)
For Essential Information Protection(tm)
Web Security | Data Security | Email Security


Protected by Websense Hosted Email Security - www.websense.com


Click here to report this=
 email as spam.

--_000_E71FC5D6F96C3C4B93FC8FF942D924C682F45E06SBJEXCH1Bwebsen_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi,<=
/p>

I’ve tried lates=
t stable kernel 3.6.3 without any luck ):


Thanks for your attent=
ion in advance.


Huaxiang


 






From: xen-deve=
l-bounces@lists.xen.org [mailto:xen-devel-bounces@lists.xen.org]
On Behalf Of Fan, Huaxiang

Sent: Friday, October 19, 2012 11:40 AM

To: xen-devel@lists.xen.org

Cc: xen-users@lists.xen.org

Subject: [Xen-devel] e820_host and 3G limit






 


Hi,


 


I was told e820_host is used to solve 3G limit on do=
mu problem when PCI passthru happens. But I failed to tackle this problem u=
sing xen 4.2 and kernel 3.4.4


 


Here is my environment:


Xen hypervisor and tools: 4.2


Dom0 kernel 2.6.32.57


Domu kernel 3.4.4


All above is 64bit


 


Here is my domu cfg:


kernel =3D "/root/domainWCG.kernel"


ramdisk =3D "/root/domainWCG.initrd.img"


e820_host=3D1


memory=3D5120


name =3D "wcg"


vif  =3D [ 'ip=3D169.254.254.1,vifname=3Dwcg.0'=
 ]


disk =3D ['phy:/dev/lv_appliance/wcg,xvda1,w',<=
/o:p>


        'phy:/dev=
/sdb,xvdb,w']


root  =3D "/dev/xvda1 ro"<=
/p>

extra=3D"iommu=3Dsoft printk.printk_time=3D1 co=
nsole=3Dhvc0"


#pci=3D['01:00.0','01:00.1']


vcpus=3D4


cpus=3D"4,5,6,7"


 


Here is the output on dom0:


# xl list


Name        =
            &nb=
sp;            =
       ID   Mem VCPUs  &n=
bsp;   State   Time(s)


Domain-0       &n=
bsp;            =
;            &n=
bsp;    0  1677     2  &n=
bsp;  r-----    2237.9


wcg        &=
nbsp;           &nbs=
p;            &=
nbsp;       72  4086   &n=
bsp; 4     -b----      34.9


 


My question#1:


Dom0 memory has been shrink from 2048 to 1677. Wcg d=
omu only allocated with 4086 even I assigned 5120. Why?


 


Here is the output on wcg domu:


# cat /proc/meminfo | head -10


MemTotal:        =
2999156 kB


MemFree:       &n=
bsp; 2919760 kB


Buffers:       &n=
bsp;    4000 kB


Cached:       &nb=
sp;    40656 kB


SwapCached:       =
;     0 kB


Active:       &nb=
sp;    22852 kB


Inactive:       &=
nbsp;  31776 kB


Active(anon):      10080 kB=



Inactive(anon):       =
12 kB


Active(file):      12772 kB=



 


My question#2:


Why the domu kernel only recognizes 3G memory even I=
 actually allocate 5G to it?


 


Appendix


E820 memory map on wcg domu


 


[    0.000000] BIOS-provided physical=
 RAM map:


[    0.000000]  Xen: 00000000000=
00000 - 00000000000a0000 (usable)


[    0.000000]  Xen: 00000000000=
a0000 - 0000000000100000 (reserved)


[    0.000000]  Xen: 00000000001=
00000 - 00000000bf699000 (usable)


[    0.000000]  Xen: 00000000bf6=
99000 - 00000000bf6af000 (reserved)


[    0.000000]  Xen: 00000000bf6=
af000 - 00000000bf6ce000 (ACPI data)


[    0.000000]  Xen: 00000000bf6=
ce000 - 00000000c0000000 (reserved)


[    0.000000]  Xen: 00000000e00=
00000 - 00000000f0000000 (reserved)


[    0.000000]  Xen: 00000000fe0=
00000 - 0000000100000000 (reserved)


 


E820 memory map on dom0


BIOS-provided physical RAM map:


Oct 18 05:26:34 localhost kernel: BIOS-e820: 0000000=
000000000 - 000000000009d000 (usable)


Oct 18 05:26:34 localhost kernel: BIOS-e820: 0000000=
000100000 - 00000000bf699000 (usable)


Oct 18 05:26:34 localhost kernel: BIOS-e820: 0000000=
0bf699000 - 00000000bf6af000 (reserved)


Oct 18 05:26:34 localhost kernel: BIOS-e820: 0000000=
0bf6af000 - 00000000bf6ce000 (ACPI data)


Oct 18 05:26:34 localhost kernel: BIOS-e820: 0000000=
0bf6ce000 - 00000000c0000000 (reserved)


Oct 18 05:26:34 localhost kernel: BIOS-e820: 0000000=
0e0000000 - 00000000f0000000 (reserved)


Oct 18 05:26:34 localhost kernel: BIOS-e820: 0000000=
0fe000000 - 0000000100000000 (reserved)


Oct 18 05:26:34 localhost kernel: BIOS-e820: 0000000=
100000000 - 0000000240000000 (usable)


 


I am looking forward your reply. Thanks in advance.<=
o:p>


HUAXIANG FAN

Software Engineer II



WEBSENSE NETWORK SECURITY TECHNOLOGY R&am=
p;D (BEIJING) CO. LTD.

ph: +8610.5884.4327

fax: +8610.5884.4727

www.websense.cn



Websense TRITON™

For Essential Information Protection™

Web Security |
=
Data Security=
 |
Email Security


=
 


Protected by Websense =
Hosted Email Security —
www.websense.com


 


Click 
here to report this email as spam.






--_000_E71FC5D6F96C3C4B93FC8FF942D924C682F45E06SBJEXCH1Bwebsen_--


--===============0710728833721381800==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0710728833721381800==--


From xen-devel-bounces@lists.xen.org Wed Oct 24 06:06:18 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 06:06:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQu6B-0002cy-9M; Wed, 24 Oct 2012 06:05:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQu69-0002cg-EN; Wed, 24 Oct 2012 06:05:49 +0000
Received: from [85.158.139.83:26389] by server-16.bemta-5.messagelabs.com id
	AB/0F-04786-C3587805; Wed, 24 Oct 2012 06:05:48 +0000
X-Env-Sender: hufan@websense.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1351058744!32331105!1
X-Originating-IP: [208.87.233.190]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljg3LjIzMy4xOTAgPT4gMTc5MDcxOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27596 invoked from network); 24 Oct 2012 06:05:46 -0000
Received: from cluster-g.mailcontrol.com (HELO cluster-g.mailcontrol.com)
	(208.87.233.190)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Oct 2012 06:05:46 -0000
Received: from ssdwbsnapp.websense.com (static-204-15-65-158.websense.com
	[204.15.65.158] (may be forged))
	by rly33g.srv.mailcontrol.com (MailControl) with ESMTP id
	q9O65frx006790
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 24 Oct 2012 07:05:41 +0100
Received: from SSDEXCH1A.websense.com (unknown [10.8.1.91])
	by Websense Email Security Gateway with ESMTP id BE4FB1000002;
	Tue, 23 Oct 2012 23:05:23 -0700 (PDT)
Received: from SBJEXCH2A.websense.com (10.32.8.111) by SSDEXCH1A.websense.com
	(10.8.1.91) with Microsoft SMTP Server (TLS) id 14.2.283.3;
	Tue, 23 Oct 2012 23:05:41 -0700
Received: from SBJEXCH1B.websense.com ([169.254.2.203]) by
	SBJEXCH2A.websense.com ([::1]) with mapi id 14.02.0283.003;
	Wed, 24 Oct 2012 14:05:36 +0800
From: "Fan, Huaxiang" 
To: "Fan, Huaxiang" , "xen-devel@lists.xen.org"
	
Thread-Topic: e820_host and 3G limit
Thread-Index: Ac2tqU9Lub39PN+YQ/+qrymARk/PPgEBAOfQ
Date: Wed, 24 Oct 2012 06:05:35 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.32.134.111]
MIME-Version: 1.0
X-Scanned-By: MailControl 10515.0 (www.mailcontrol.com) on 10.71.0.143
Cc: "xen-users@lists.xen.org" 
Subject: Re: [Xen-devel] e820_host and 3G limit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0710728833721381800=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0710728833721381800==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_E71FC5D6F96C3C4B93FC8FF942D924C682F45E06SBJEXCH1Bwebsen_"

--_000_E71FC5D6F96C3C4B93FC8FF942D924C682F45E06SBJEXCH1Bwebsen_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,
I've tried latest stable kernel 3.6.3 without any luck ):
Thanks for your attention in advance.
Huaxiang

From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-bounces@lists.xen.o=
rg] On Behalf Of Fan, Huaxiang
Sent: Friday, October 19, 2012 11:40 AM
To: xen-devel@lists.xen.org
Cc: xen-users@lists.xen.org
Subject: [Xen-devel] e820_host and 3G limit

Hi,

I was told e820_host is used to solve 3G limit on domu problem when PCI pas=
sthru happens. But I failed to tackle this problem using xen 4.2 and kernel=
 3.4.4

Here is my environment:
Xen hypervisor and tools: 4.2
Dom0 kernel 2.6.32.57
Domu kernel 3.4.4
All above is 64bit

Here is my domu cfg:
kernel =3D "/root/domainWCG.kernel"
ramdisk =3D "/root/domainWCG.initrd.img"
e820_host=3D1
memory=3D5120
name =3D "wcg"
vif  =3D [ 'ip=3D169.254.254.1,vifname=3Dwcg.0' ]
disk =3D ['phy:/dev/lv_appliance/wcg,xvda1,w',
        'phy:/dev/sdb,xvdb,w']
root  =3D "/dev/xvda1 ro"
extra=3D"iommu=3Dsoft printk.printk_time=3D1 console=3Dhvc0"
#pci=3D['01:00.0','01:00.1']
vcpus=3D4
cpus=3D"4,5,6,7"

Here is the output on dom0:
# xl list
Name                                        ID   Mem VCPUs      State   Tim=
e(s)
Domain-0                                     0  1677     2     r-----    22=
37.9
wcg                                         72  4086     4     -b----      =
34.9

My question#1:
Dom0 memory has been shrink from 2048 to 1677. Wcg domu only allocated with=
 4086 even I assigned 5120. Why?

Here is the output on wcg domu:
# cat /proc/meminfo | head -10
MemTotal:        2999156 kB
MemFree:         2919760 kB
Buffers:            4000 kB
Cached:            40656 kB
SwapCached:            0 kB
Active:            22852 kB
Inactive:          31776 kB
Active(anon):      10080 kB
Inactive(anon):       12 kB
Active(file):      12772 kB

My question#2:
Why the domu kernel only recognizes 3G memory even I actually allocate 5G t=
o it?

Appendix
E820 memory map on wcg domu

[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  Xen: 0000000000000000 - 00000000000a0000 (usable)
[    0.000000]  Xen: 00000000000a0000 - 0000000000100000 (reserved)
[    0.000000]  Xen: 0000000000100000 - 00000000bf699000 (usable)
[    0.000000]  Xen: 00000000bf699000 - 00000000bf6af000 (reserved)
[    0.000000]  Xen: 00000000bf6af000 - 00000000bf6ce000 (ACPI data)
[    0.000000]  Xen: 00000000bf6ce000 - 00000000c0000000 (reserved)
[    0.000000]  Xen: 00000000e0000000 - 00000000f0000000 (reserved)
[    0.000000]  Xen: 00000000fe000000 - 0000000100000000 (reserved)

E820 memory map on dom0
BIOS-provided physical RAM map:
Oct 18 05:26:34 localhost kernel: BIOS-e820: 0000000000000000 - 00000000000=
9d000 (usable)
Oct 18 05:26:34 localhost kernel: BIOS-e820: 0000000000100000 - 00000000bf6=
99000 (usable)
Oct 18 05:26:34 localhost kernel: BIOS-e820: 00000000bf699000 - 00000000bf6=
af000 (reserved)
Oct 18 05:26:34 localhost kernel: BIOS-e820: 00000000bf6af000 - 00000000bf6=
ce000 (ACPI data)
Oct 18 05:26:34 localhost kernel: BIOS-e820: 00000000bf6ce000 - 00000000c00=
00000 (reserved)
Oct 18 05:26:34 localhost kernel: BIOS-e820: 00000000e0000000 - 00000000f00=
00000 (reserved)
Oct 18 05:26:34 localhost kernel: BIOS-e820: 00000000fe000000 - 00000001000=
00000 (reserved)
Oct 18 05:26:34 localhost kernel: BIOS-e820: 0000000100000000 - 00000002400=
00000 (usable)

I am looking forward your reply. Thanks in advance.
HUAXIANG FAN
Software Engineer II

WEBSENSE NETWORK SECURITY TECHNOLOGY R&D (BEIJING) CO. LTD.
ph: +8610.5884.4327
fax: +8610.5884.4727
www.websense.cn

Websense TRITON(tm)
For Essential Information Protection(tm)
Web Security | Data Security | Email Security


Protected by Websense Hosted Email Security - www.websense.com


Click here to report this=
 email as spam.

--_000_E71FC5D6F96C3C4B93FC8FF942D924C682F45E06SBJEXCH1Bwebsen_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi,<=
/p>

I’ve tried lates=
t stable kernel 3.6.3 without any luck ):


Thanks for your attent=
ion in advance.


Huaxiang


 






From: xen-deve=
l-bounces@lists.xen.org [mailto:xen-devel-bounces@lists.xen.org]
On Behalf Of Fan, Huaxiang

Sent: Friday, October 19, 2012 11:40 AM

To: xen-devel@lists.xen.org

Cc: xen-users@lists.xen.org

Subject: [Xen-devel] e820_host and 3G limit






 


Hi,


 


I was told e820_host is used to solve 3G limit on do=
mu problem when PCI passthru happens. But I failed to tackle this problem u=
sing xen 4.2 and kernel 3.4.4


 


Here is my environment:


Xen hypervisor and tools: 4.2


Dom0 kernel 2.6.32.57


Domu kernel 3.4.4


All above is 64bit


 


Here is my domu cfg:


kernel =3D "/root/domainWCG.kernel"


ramdisk =3D "/root/domainWCG.initrd.img"


e820_host=3D1


memory=3D5120


name =3D "wcg"


vif  =3D [ 'ip=3D169.254.254.1,vifname=3Dwcg.0'=
 ]


disk =3D ['phy:/dev/lv_appliance/wcg,xvda1,w',<=
/o:p>


        'phy:/dev=
/sdb,xvdb,w']


root  =3D "/dev/xvda1 ro"<=
/p>

extra=3D"iommu=3Dsoft printk.printk_time=3D1 co=
nsole=3Dhvc0"


#pci=3D['01:00.0','01:00.1']


vcpus=3D4


cpus=3D"4,5,6,7"


 


Here is the output on dom0:


# xl list


Name        =
            &nb=
sp;            =
       ID   Mem VCPUs  &n=
bsp;   State   Time(s)


Domain-0       &n=
bsp;            =
;            &n=
bsp;    0  1677     2  &n=
bsp;  r-----    2237.9


wcg        &=
nbsp;           &nbs=
p;            &=
nbsp;       72  4086   &n=
bsp; 4     -b----      34.9


 


My question#1:


Dom0 memory has been shrink from 2048 to 1677. Wcg d=
omu only allocated with 4086 even I assigned 5120. Why?


 


Here is the output on wcg domu:


# cat /proc/meminfo | head -10


MemTotal:        =
2999156 kB


MemFree:       &n=
bsp; 2919760 kB


Buffers:       &n=
bsp;    4000 kB


Cached:       &nb=
sp;    40656 kB


SwapCached:       =
;     0 kB


Active:       &nb=
sp;    22852 kB


Inactive:       &=
nbsp;  31776 kB


Active(anon):      10080 kB=



Inactive(anon):       =
12 kB


Active(file):      12772 kB=



 


My question#2:


Why the domu kernel only recognizes 3G memory even I=
 actually allocate 5G to it?


 


Appendix


E820 memory map on wcg domu


 


[    0.000000] BIOS-provided physical=
 RAM map:


[    0.000000]  Xen: 00000000000=
00000 - 00000000000a0000 (usable)


[    0.000000]  Xen: 00000000000=
a0000 - 0000000000100000 (reserved)


[    0.000000]  Xen: 00000000001=
00000 - 00000000bf699000 (usable)


[    0.000000]  Xen: 00000000bf6=
99000 - 00000000bf6af000 (reserved)


[    0.000000]  Xen: 00000000bf6=
af000 - 00000000bf6ce000 (ACPI data)


[    0.000000]  Xen: 00000000bf6=
ce000 - 00000000c0000000 (reserved)


[    0.000000]  Xen: 00000000e00=
00000 - 00000000f0000000 (reserved)


[    0.000000]  Xen: 00000000fe0=
00000 - 0000000100000000 (reserved)


 


E820 memory map on dom0


BIOS-provided physical RAM map:


Oct 18 05:26:34 localhost kernel: BIOS-e820: 0000000=
000000000 - 000000000009d000 (usable)


Oct 18 05:26:34 localhost kernel: BIOS-e820: 0000000=
000100000 - 00000000bf699000 (usable)


Oct 18 05:26:34 localhost kernel: BIOS-e820: 0000000=
0bf699000 - 00000000bf6af000 (reserved)


Oct 18 05:26:34 localhost kernel: BIOS-e820: 0000000=
0bf6af000 - 00000000bf6ce000 (ACPI data)


Oct 18 05:26:34 localhost kernel: BIOS-e820: 0000000=
0bf6ce000 - 00000000c0000000 (reserved)


Oct 18 05:26:34 localhost kernel: BIOS-e820: 0000000=
0e0000000 - 00000000f0000000 (reserved)


Oct 18 05:26:34 localhost kernel: BIOS-e820: 0000000=
0fe000000 - 0000000100000000 (reserved)


Oct 18 05:26:34 localhost kernel: BIOS-e820: 0000000=
100000000 - 0000000240000000 (usable)


 


I am looking forward your reply. Thanks in advance.<=
o:p>


HUAXIANG FAN

Software Engineer II



WEBSENSE NETWORK SECURITY TECHNOLOGY R&am=
p;D (BEIJING) CO. LTD.

ph: +8610.5884.4327

fax: +8610.5884.4727

www.websense.cn



Websense TRITON™

For Essential Information Protection™

Web Security |
=
Data Security=
 |
Email Security


=
 


Protected by Websense =
Hosted Email Security —
www.websense.com


 


Click 
here to report this email as spam.






--_000_E71FC5D6F96C3C4B93FC8FF942D924C682F45E06SBJEXCH1Bwebsen_--


--===============0710728833721381800==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0710728833721381800==--


From xen-devel-bounces@lists.xen.org Wed Oct 24 07:14:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 07:14:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQvA3-00040L-08; Wed, 24 Oct 2012 07:13:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQvA0-00040G-OP
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 07:13:52 +0000
Received: from [193.109.254.147:16574] by server-4.bemta-14.messagelabs.com id
	E4/90-04248-F2597805; Wed, 24 Oct 2012 07:13:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1351062808!9716025!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17329 invoked from network); 24 Oct 2012 07:13:28 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-27.messagelabs.com with SMTP;
	24 Oct 2012 07:13:28 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 24 Oct 2012 08:13:27 +0100
Message-Id: <5087B13402000078000A3CBB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 24 Oct 2012 08:13:24 +0100
From: "Jan Beulich" 
To: "Konrad Rzeszutek Wilk" ,
	
References: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
In-Reply-To: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: linux-kernel@vger.kernel.org, xen-devel ,
	Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH V5] PVH patches for v3.8.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 23.10.12 at 20:12, Konrad Rzeszutek Wilk  wrote:

Do you really want to target 3.8 for these, without any hypervisor
side review having happened? In particular,

> Changelog [since v4]
>  - Mukesh addressed the reviewer's concerns.
>  - Took Mukesh's patches and redid the changelogs.
>  - Added Ack-ed as appropiate.
>  - Fixed PVHVM 32-bit bootup issues.
>  - Did some various cleanups, split some patches up.
> 
> The big change is that I've made the xen_remove_from_physmap structure
> be of the same size and offset on 32 and 64 bit builds. Currently PVH 
> only runs with 64-bit guests, but in the future it could run with 32-bit.
> This change will eliminate having to add a compat layer to deal with
> 32-bit hypercalls.
> 
> Besides that the patches boot on an normal hypervisor - in
> dom0 (32 or 64bit), PV domU (32 or 64) and PVHVM domU (32 or 64).
> I don't have the PVH hypervisor patches so I could not address the
> change to xen_remove_from_physmap but I hope Mukesh can do that.
> 
> The patches are also located at:
>  git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/pvh.v5
> 
> 
>  arch/x86/include/asm/xen/interface.h |   11 ++-
>  arch/x86/include/asm/xen/page.h      |    3 +
>  arch/x86/xen/Kconfig                 |   10 ++
>  arch/x86/xen/enlighten.c             |   78 ++++++++++++----
>  arch/x86/xen/irq.c                   |    5 +-
>  arch/x86/xen/mmu.c                   |  162 ++++++++++++++++++++++++++++++++--
>  arch/x86/xen/mmu.h                   |    2 +
>  arch/x86/xen/p2m.c                   |    2 +-
>  arch/x86/xen/setup.c                 |   58 +++++++++----
>  arch/x86/xen/smp.c                   |   75 ++++++++++------
>  arch/x86/xen/xen-head.S              |   11 ++-
>  drivers/xen/balloon.c                |   15 ++--
>  drivers/xen/cpu_hotplug.c            |    4 +-
>  drivers/xen/events.c                 |    9 ++-
>  drivers/xen/gntdev.c                 |    3 +-
>  drivers/xen/grant-table.c            |   27 +++++-
>  drivers/xen/privcmd.c                |   72 ++++++++++++++-
>  drivers/xen/xenbus/xenbus_client.c   |    3 +-
>  include/xen/interface/memory.h       |   29 ++++++-
>  include/xen/interface/physdev.h      |   10 ++

... any changes to the hypervisor interface (didn't look in detail
what is being changed in these two headers) should first be in
at least -unstable before being consumed in any official release
imo.

Jan

>  include/xen/xen-ops.h                |    5 +-
>  21 files changed, 504 insertions(+), 90 deletions(-)
> 
> Konrad Rzeszutek Wilk (4):
>       xen/pvh: Fix PVHVM 32-bit bootup problems.
>       xen/hypercall: Make xen_remove_from_physmap the same on 64/32 builds.
>       xen/smp: Move the common CPU init code a bit to prep for PVH patch.
>       xen/e820: Coalesce the PVH release/populate logic in the generic case.
> 
> Mukesh Rathor (6):
>       xen/pvh: Support ParaVirtualized Hardware extensions.
>       xen/pvh: Extend vcpu_guest_context, p2m, event, and XenBus.
>       xen/pvh: Implement MMU changes for PVH.
>       xen/pvh: bootup and setup (E820) related changes.
>       xen/pvh: balloon and grant changes.
>       xen/pvh: /dev/xen/privcmd changes.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 07:14:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 07:14:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQvA3-00040L-08; Wed, 24 Oct 2012 07:13:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQvA0-00040G-OP
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 07:13:52 +0000
Received: from [193.109.254.147:16574] by server-4.bemta-14.messagelabs.com id
	E4/90-04248-F2597805; Wed, 24 Oct 2012 07:13:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1351062808!9716025!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17329 invoked from network); 24 Oct 2012 07:13:28 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-27.messagelabs.com with SMTP;
	24 Oct 2012 07:13:28 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 24 Oct 2012 08:13:27 +0100
Message-Id: <5087B13402000078000A3CBB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 24 Oct 2012 08:13:24 +0100
From: "Jan Beulich" 
To: "Konrad Rzeszutek Wilk" ,
	
References: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
In-Reply-To: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: linux-kernel@vger.kernel.org, xen-devel ,
	Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH V5] PVH patches for v3.8.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 23.10.12 at 20:12, Konrad Rzeszutek Wilk  wrote:

Do you really want to target 3.8 for these, without any hypervisor
side review having happened? In particular,

> Changelog [since v4]
>  - Mukesh addressed the reviewer's concerns.
>  - Took Mukesh's patches and redid the changelogs.
>  - Added Ack-ed as appropiate.
>  - Fixed PVHVM 32-bit bootup issues.
>  - Did some various cleanups, split some patches up.
> 
> The big change is that I've made the xen_remove_from_physmap structure
> be of the same size and offset on 32 and 64 bit builds. Currently PVH 
> only runs with 64-bit guests, but in the future it could run with 32-bit.
> This change will eliminate having to add a compat layer to deal with
> 32-bit hypercalls.
> 
> Besides that the patches boot on an normal hypervisor - in
> dom0 (32 or 64bit), PV domU (32 or 64) and PVHVM domU (32 or 64).
> I don't have the PVH hypervisor patches so I could not address the
> change to xen_remove_from_physmap but I hope Mukesh can do that.
> 
> The patches are also located at:
>  git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/pvh.v5
> 
> 
>  arch/x86/include/asm/xen/interface.h |   11 ++-
>  arch/x86/include/asm/xen/page.h      |    3 +
>  arch/x86/xen/Kconfig                 |   10 ++
>  arch/x86/xen/enlighten.c             |   78 ++++++++++++----
>  arch/x86/xen/irq.c                   |    5 +-
>  arch/x86/xen/mmu.c                   |  162 ++++++++++++++++++++++++++++++++--
>  arch/x86/xen/mmu.h                   |    2 +
>  arch/x86/xen/p2m.c                   |    2 +-
>  arch/x86/xen/setup.c                 |   58 +++++++++----
>  arch/x86/xen/smp.c                   |   75 ++++++++++------
>  arch/x86/xen/xen-head.S              |   11 ++-
>  drivers/xen/balloon.c                |   15 ++--
>  drivers/xen/cpu_hotplug.c            |    4 +-
>  drivers/xen/events.c                 |    9 ++-
>  drivers/xen/gntdev.c                 |    3 +-
>  drivers/xen/grant-table.c            |   27 +++++-
>  drivers/xen/privcmd.c                |   72 ++++++++++++++-
>  drivers/xen/xenbus/xenbus_client.c   |    3 +-
>  include/xen/interface/memory.h       |   29 ++++++-
>  include/xen/interface/physdev.h      |   10 ++

... any changes to the hypervisor interface (didn't look in detail
what is being changed in these two headers) should first be in
at least -unstable before being consumed in any official release
imo.

Jan

>  include/xen/xen-ops.h                |    5 +-
>  21 files changed, 504 insertions(+), 90 deletions(-)
> 
> Konrad Rzeszutek Wilk (4):
>       xen/pvh: Fix PVHVM 32-bit bootup problems.
>       xen/hypercall: Make xen_remove_from_physmap the same on 64/32 builds.
>       xen/smp: Move the common CPU init code a bit to prep for PVH patch.
>       xen/e820: Coalesce the PVH release/populate logic in the generic case.
> 
> Mukesh Rathor (6):
>       xen/pvh: Support ParaVirtualized Hardware extensions.
>       xen/pvh: Extend vcpu_guest_context, p2m, event, and XenBus.
>       xen/pvh: Implement MMU changes for PVH.
>       xen/pvh: bootup and setup (E820) related changes.
>       xen/pvh: balloon and grant changes.
>       xen/pvh: /dev/xen/privcmd changes.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 07:32:07 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 07:32:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQvRA-0004FP-D9; Wed, 24 Oct 2012 07:31:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQvR9-0004FK-7o
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 07:31:35 +0000
Received: from [85.158.137.99:21208] by server-9.bemta-3.messagelabs.com id
	EE/AE-16841-65997805; Wed, 24 Oct 2012 07:31:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1351063893!20428741!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29402 invoked from network); 24 Oct 2012 07:31:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-217.messagelabs.com with SMTP;
	24 Oct 2012 07:31:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 24 Oct 2012 08:31:33 +0100
Message-Id: <5087B57302000078000A3CE3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 24 Oct 2012 08:31:31 +0100
From: "Jan Beulich" 
To: "Olaf Hering" 
References: <20120828124255.GA32452@aepfle.de>
	
	<20120831234222.GA22460@localhost.localdomain>
	<20121023194928.GA24083@aepfle.de>
In-Reply-To: <20121023194928.GA24083@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk , Keir Fraser ,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] fixed location of share info page in HVM guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 23.10.12 at 21:49, Olaf Hering  wrote:
> The open question is when to switch from early_ioremap to
> ioremap. Then the change to drivers/xen/platform-pci.c can be removed.

Wouldn't you be better of using
early_set_fixmap(FIX_PARAVIRT_BOOTMAP, ...) anyway? If not,
mm_init() (due to its calling of vmalloc_init()) would be the apparent
boundary between using early and normal ioremaps.

>  xen PVonHVM: move shared_info to reserved memory area
> 
> ---
>  arch/x86/include/asm/xen/hypervisor.h |  2 ++
>  arch/x86/xen/enlighten.c              | 53 ++++++++++++++++++++++++++---------
>  arch/x86/xen/suspend.c                |  2 +-
>  arch/x86/xen/xen-ops.h                |  2 +-
>  drivers/xen/platform-pci.c            |  2 ++
>  include/xen/events.h                  |  2 ++
>  6 files changed, 48 insertions(+), 15 deletions(-)
> 
> diff --git a/arch/x86/include/asm/xen/hypervisor.h 
> b/arch/x86/include/asm/xen/hypervisor.h
> index 66d0fff..e29a02b 100644
> --- a/arch/x86/include/asm/xen/hypervisor.h
> +++ b/arch/x86/include/asm/xen/hypervisor.h
> @@ -34,6 +34,8 @@
>  #define _ASM_X86_XEN_HYPERVISOR_H
>  
>  /* arch/i386/kernel/setup.c */
> +#define HVM_SHARED_INFO_ADDR 0xFE700000UL
> +
>  extern struct shared_info *HYPERVISOR_shared_info;
>  extern struct start_info *xen_start_info;
>  
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index e3497f2..b051c3f 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -103,7 +103,6 @@ struct shared_info xen_dummy_shared_info;
>  
>  void *xen_initial_gdt;
>  
> -RESERVE_BRK(shared_info_page_brk, PAGE_SIZE);
>  __read_mostly int xen_have_vector_callback;
>  EXPORT_SYMBOL_GPL(xen_have_vector_callback);
>  
> @@ -1497,38 +1496,66 @@ asmlinkage void __init xen_start_kernel(void)
>  #endif
>  }
>  
> -void __ref xen_hvm_init_shared_info(void)
> +#ifdef CONFIG_XEN_PVHVM
> +static struct shared_info *xen_hvm_shared_info;
> +
> +static void xen_hvm_connect_shared_info(unsigned long pfn)
>  {
> -	int cpu;
>  	struct xen_add_to_physmap xatp;
> -	static struct shared_info *shared_info_page = 0;
>  
> -	if (!shared_info_page)
> -		shared_info_page = (struct shared_info *)
> -			extend_brk(PAGE_SIZE, PAGE_SIZE);
>  	xatp.domid = DOMID_SELF;
>  	xatp.idx = 0;
>  	xatp.space = XENMAPSPACE_shared_info;
> -	xatp.gpfn = __pa(shared_info_page) >> PAGE_SHIFT;
> +	xatp.gpfn = pfn;
>  	if (HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp))
>  		BUG();
>  
> -	HYPERVISOR_shared_info = (struct shared_info *)shared_info_page;
> +}
> +static void xen_hvm_set_shared_info(struct shared_info *sip)
> +{
> +	int cpu;
> +
> +	HYPERVISOR_shared_info = sip;
>  
>  	/* xen_vcpu is a pointer to the vcpu_info struct in the shared_info
>  	 * page, we use it in the event channel upcall and in some pvclock
>  	 * related functions. We don't need the vcpu_info placement
>  	 * optimizations because we don't use any pv_mmu or pv_irq op on
>  	 * HVM.
> -	 * When xen_hvm_init_shared_info is run at boot time only vcpu 0 is
> -	 * online but xen_hvm_init_shared_info is run at resume time too and
> +	 * When xen_hvm_set_shared_info is run at boot time only vcpu 0 is
> +	 * online but xen_hvm_set_shared_info is run at resume time too and
>  	 * in that case multiple vcpus might be online. */
>  	for_each_online_cpu(cpu) {
>  		per_cpu(xen_vcpu, cpu) = &HYPERVISOR_shared_info->vcpu_info[cpu];
>  	}
>  }
>  
> -#ifdef CONFIG_XEN_PVHVM
> +/* Reconnect the shared_info pfn to a (new) mfn */
> +void xen_hvm_resume_shared_info(void)
> +{
> +	xen_hvm_connect_shared_info(HVM_SHARED_INFO_ADDR >> PAGE_SHIFT);
> +}
> +
> +/* Update shared_info address */
> +void __devinit xen_hvm_init_shared_info(void)
> +{
> +	struct shared_info *early;
> +
> +	early = xen_hvm_shared_info;
> +	xen_hvm_shared_info = ioremap(HVM_SHARED_INFO_ADDR, PAGE_SIZE);
> +	xen_hvm_set_shared_info(xen_hvm_shared_info);
> +	wmb();
> +	early_iounmap(early, PAGE_SIZE);

This is a call from __devinit to __init, which isn't allowed. And I'm
pretty sure it's too late to do this here anyway.

Jan

> +}
> +
> +/* Obtain an address to the pfn in reserved area */
> +static void __init xen_hvm_early_init_shared_info(void)
> +{
> +	xen_hvm_shared_info = early_ioremap(HVM_SHARED_INFO_ADDR, PAGE_SIZE);
> +	xen_hvm_connect_shared_info(HVM_SHARED_INFO_ADDR >> PAGE_SHIFT);
> +	xen_hvm_set_shared_info(xen_hvm_shared_info);
> +}
> +
>  static void __init init_hvm_pv_info(void)
>  {
>  	int major, minor;
> @@ -1578,7 +1605,7 @@ static void __init xen_hvm_guest_init(void)
>  {
>  	init_hvm_pv_info();
>  
> -	xen_hvm_init_shared_info();
> +	xen_hvm_early_init_shared_info();
>  
>  	if (xen_feature(XENFEAT_hvm_callback_vector))
>  		xen_have_vector_callback = 1;
> diff --git a/arch/x86/xen/suspend.c b/arch/x86/xen/suspend.c
> index 45329c8..ae8a00c 100644
> --- a/arch/x86/xen/suspend.c
> +++ b/arch/x86/xen/suspend.c
> @@ -30,7 +30,7 @@ void xen_arch_hvm_post_suspend(int suspend_cancelled)
>  {
>  #ifdef CONFIG_XEN_PVHVM
>  	int cpu;
> -	xen_hvm_init_shared_info();
> +	xen_hvm_resume_shared_info();
>  	xen_callback_vector();
>  	xen_unplug_emulated_devices();
>  	if (xen_feature(XENFEAT_hvm_safe_pvclock)) {
> diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
> index a95b417..d2e73d1 100644
> --- a/arch/x86/xen/xen-ops.h
> +++ b/arch/x86/xen/xen-ops.h
> @@ -40,7 +40,7 @@ void xen_enable_syscall(void);
>  void xen_vcpu_restore(void);
>  
>  void xen_callback_vector(void);
> -void xen_hvm_init_shared_info(void);
> +void xen_hvm_resume_shared_info(void);
>  void xen_unplug_emulated_devices(void);
>  
>  void __init xen_build_dynamic_phys_to_machine(void);
> diff --git a/drivers/xen/platform-pci.c b/drivers/xen/platform-pci.c
> index 97ca359..989365f 100644
> --- a/drivers/xen/platform-pci.c
> +++ b/drivers/xen/platform-pci.c
> @@ -138,6 +138,8 @@ static int __devinit platform_pci_init(struct pci_dev 
> *pdev,
>  	platform_mmio = mmio_addr;
>  	platform_mmiolen = mmio_len;
>  
> +	xen_hvm_init_shared_info();
> +
>  	if (!xen_have_vector_callback) {
>  		ret = xen_allocate_irq(pdev);
>  		if (ret) {
> diff --git a/include/xen/events.h b/include/xen/events.h
> index c6bfe01..58c8431 100644
> --- a/include/xen/events.h
> +++ b/include/xen/events.h
> @@ -58,6 +58,8 @@ void notify_remote_via_irq(int irq);
>  
>  void xen_irq_resume(void);
>  
> +void xen_hvm_init_shared_info(void);
> +
>  /* Clear an irq's pending state, in preparation for polling on it */
>  void xen_clear_irq_pending(int irq);
>  void xen_set_irq_pending(int irq);
> -- 
> 1.7.12.4
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 07:32:07 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 07:32:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQvRA-0004FP-D9; Wed, 24 Oct 2012 07:31:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQvR9-0004FK-7o
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 07:31:35 +0000
Received: from [85.158.137.99:21208] by server-9.bemta-3.messagelabs.com id
	EE/AE-16841-65997805; Wed, 24 Oct 2012 07:31:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1351063893!20428741!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29402 invoked from network); 24 Oct 2012 07:31:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-217.messagelabs.com with SMTP;
	24 Oct 2012 07:31:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 24 Oct 2012 08:31:33 +0100
Message-Id: <5087B57302000078000A3CE3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 24 Oct 2012 08:31:31 +0100
From: "Jan Beulich" 
To: "Olaf Hering" 
References: <20120828124255.GA32452@aepfle.de>
	
	<20120831234222.GA22460@localhost.localdomain>
	<20121023194928.GA24083@aepfle.de>
In-Reply-To: <20121023194928.GA24083@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk , Keir Fraser ,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] fixed location of share info page in HVM guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 23.10.12 at 21:49, Olaf Hering  wrote:
> The open question is when to switch from early_ioremap to
> ioremap. Then the change to drivers/xen/platform-pci.c can be removed.

Wouldn't you be better of using
early_set_fixmap(FIX_PARAVIRT_BOOTMAP, ...) anyway? If not,
mm_init() (due to its calling of vmalloc_init()) would be the apparent
boundary between using early and normal ioremaps.

>  xen PVonHVM: move shared_info to reserved memory area
> 
> ---
>  arch/x86/include/asm/xen/hypervisor.h |  2 ++
>  arch/x86/xen/enlighten.c              | 53 ++++++++++++++++++++++++++---------
>  arch/x86/xen/suspend.c                |  2 +-
>  arch/x86/xen/xen-ops.h                |  2 +-
>  drivers/xen/platform-pci.c            |  2 ++
>  include/xen/events.h                  |  2 ++
>  6 files changed, 48 insertions(+), 15 deletions(-)
> 
> diff --git a/arch/x86/include/asm/xen/hypervisor.h 
> b/arch/x86/include/asm/xen/hypervisor.h
> index 66d0fff..e29a02b 100644
> --- a/arch/x86/include/asm/xen/hypervisor.h
> +++ b/arch/x86/include/asm/xen/hypervisor.h
> @@ -34,6 +34,8 @@
>  #define _ASM_X86_XEN_HYPERVISOR_H
>  
>  /* arch/i386/kernel/setup.c */
> +#define HVM_SHARED_INFO_ADDR 0xFE700000UL
> +
>  extern struct shared_info *HYPERVISOR_shared_info;
>  extern struct start_info *xen_start_info;
>  
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index e3497f2..b051c3f 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -103,7 +103,6 @@ struct shared_info xen_dummy_shared_info;
>  
>  void *xen_initial_gdt;
>  
> -RESERVE_BRK(shared_info_page_brk, PAGE_SIZE);
>  __read_mostly int xen_have_vector_callback;
>  EXPORT_SYMBOL_GPL(xen_have_vector_callback);
>  
> @@ -1497,38 +1496,66 @@ asmlinkage void __init xen_start_kernel(void)
>  #endif
>  }
>  
> -void __ref xen_hvm_init_shared_info(void)
> +#ifdef CONFIG_XEN_PVHVM
> +static struct shared_info *xen_hvm_shared_info;
> +
> +static void xen_hvm_connect_shared_info(unsigned long pfn)
>  {
> -	int cpu;
>  	struct xen_add_to_physmap xatp;
> -	static struct shared_info *shared_info_page = 0;
>  
> -	if (!shared_info_page)
> -		shared_info_page = (struct shared_info *)
> -			extend_brk(PAGE_SIZE, PAGE_SIZE);
>  	xatp.domid = DOMID_SELF;
>  	xatp.idx = 0;
>  	xatp.space = XENMAPSPACE_shared_info;
> -	xatp.gpfn = __pa(shared_info_page) >> PAGE_SHIFT;
> +	xatp.gpfn = pfn;
>  	if (HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp))
>  		BUG();
>  
> -	HYPERVISOR_shared_info = (struct shared_info *)shared_info_page;
> +}
> +static void xen_hvm_set_shared_info(struct shared_info *sip)
> +{
> +	int cpu;
> +
> +	HYPERVISOR_shared_info = sip;
>  
>  	/* xen_vcpu is a pointer to the vcpu_info struct in the shared_info
>  	 * page, we use it in the event channel upcall and in some pvclock
>  	 * related functions. We don't need the vcpu_info placement
>  	 * optimizations because we don't use any pv_mmu or pv_irq op on
>  	 * HVM.
> -	 * When xen_hvm_init_shared_info is run at boot time only vcpu 0 is
> -	 * online but xen_hvm_init_shared_info is run at resume time too and
> +	 * When xen_hvm_set_shared_info is run at boot time only vcpu 0 is
> +	 * online but xen_hvm_set_shared_info is run at resume time too and
>  	 * in that case multiple vcpus might be online. */
>  	for_each_online_cpu(cpu) {
>  		per_cpu(xen_vcpu, cpu) = &HYPERVISOR_shared_info->vcpu_info[cpu];
>  	}
>  }
>  
> -#ifdef CONFIG_XEN_PVHVM
> +/* Reconnect the shared_info pfn to a (new) mfn */
> +void xen_hvm_resume_shared_info(void)
> +{
> +	xen_hvm_connect_shared_info(HVM_SHARED_INFO_ADDR >> PAGE_SHIFT);
> +}
> +
> +/* Update shared_info address */
> +void __devinit xen_hvm_init_shared_info(void)
> +{
> +	struct shared_info *early;
> +
> +	early = xen_hvm_shared_info;
> +	xen_hvm_shared_info = ioremap(HVM_SHARED_INFO_ADDR, PAGE_SIZE);
> +	xen_hvm_set_shared_info(xen_hvm_shared_info);
> +	wmb();
> +	early_iounmap(early, PAGE_SIZE);

This is a call from __devinit to __init, which isn't allowed. And I'm
pretty sure it's too late to do this here anyway.

Jan

> +}
> +
> +/* Obtain an address to the pfn in reserved area */
> +static void __init xen_hvm_early_init_shared_info(void)
> +{
> +	xen_hvm_shared_info = early_ioremap(HVM_SHARED_INFO_ADDR, PAGE_SIZE);
> +	xen_hvm_connect_shared_info(HVM_SHARED_INFO_ADDR >> PAGE_SHIFT);
> +	xen_hvm_set_shared_info(xen_hvm_shared_info);
> +}
> +
>  static void __init init_hvm_pv_info(void)
>  {
>  	int major, minor;
> @@ -1578,7 +1605,7 @@ static void __init xen_hvm_guest_init(void)
>  {
>  	init_hvm_pv_info();
>  
> -	xen_hvm_init_shared_info();
> +	xen_hvm_early_init_shared_info();
>  
>  	if (xen_feature(XENFEAT_hvm_callback_vector))
>  		xen_have_vector_callback = 1;
> diff --git a/arch/x86/xen/suspend.c b/arch/x86/xen/suspend.c
> index 45329c8..ae8a00c 100644
> --- a/arch/x86/xen/suspend.c
> +++ b/arch/x86/xen/suspend.c
> @@ -30,7 +30,7 @@ void xen_arch_hvm_post_suspend(int suspend_cancelled)
>  {
>  #ifdef CONFIG_XEN_PVHVM
>  	int cpu;
> -	xen_hvm_init_shared_info();
> +	xen_hvm_resume_shared_info();
>  	xen_callback_vector();
>  	xen_unplug_emulated_devices();
>  	if (xen_feature(XENFEAT_hvm_safe_pvclock)) {
> diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
> index a95b417..d2e73d1 100644
> --- a/arch/x86/xen/xen-ops.h
> +++ b/arch/x86/xen/xen-ops.h
> @@ -40,7 +40,7 @@ void xen_enable_syscall(void);
>  void xen_vcpu_restore(void);
>  
>  void xen_callback_vector(void);
> -void xen_hvm_init_shared_info(void);
> +void xen_hvm_resume_shared_info(void);
>  void xen_unplug_emulated_devices(void);
>  
>  void __init xen_build_dynamic_phys_to_machine(void);
> diff --git a/drivers/xen/platform-pci.c b/drivers/xen/platform-pci.c
> index 97ca359..989365f 100644
> --- a/drivers/xen/platform-pci.c
> +++ b/drivers/xen/platform-pci.c
> @@ -138,6 +138,8 @@ static int __devinit platform_pci_init(struct pci_dev 
> *pdev,
>  	platform_mmio = mmio_addr;
>  	platform_mmiolen = mmio_len;
>  
> +	xen_hvm_init_shared_info();
> +
>  	if (!xen_have_vector_callback) {
>  		ret = xen_allocate_irq(pdev);
>  		if (ret) {
> diff --git a/include/xen/events.h b/include/xen/events.h
> index c6bfe01..58c8431 100644
> --- a/include/xen/events.h
> +++ b/include/xen/events.h
> @@ -58,6 +58,8 @@ void notify_remote_via_irq(int irq);
>  
>  void xen_irq_resume(void);
>  
> +void xen_hvm_init_shared_info(void);
> +
>  /* Clear an irq's pending state, in preparation for polling on it */
>  void xen_clear_irq_pending(int irq);
>  void xen_set_irq_pending(int irq);
> -- 
> 1.7.12.4
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 07:40:45 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 07:40:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQvZb-0004QF-UB; Wed, 24 Oct 2012 07:40:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQvZb-0004QA-5M
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 07:40:19 +0000
Received: from [85.158.138.51:60244] by server-15.bemta-3.messagelabs.com id
	38/F1-09445-26B97805; Wed, 24 Oct 2012 07:40:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1351064415!35547450!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4935 invoked from network); 24 Oct 2012 07:40:15 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-174.messagelabs.com with SMTP;
	24 Oct 2012 07:40:15 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 24 Oct 2012 08:40:14 +0100
Message-Id: <5087B77A02000078000A3D00@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 24 Oct 2012 08:40:10 +0100
From: "Jan Beulich" 
To: ,"Konrad Rzeszutek Wilk" 
References: <1350559321-19066-1-git-send-email-roger.pau@citrix.com>
	<20121022134708.GA13832@konrad-lan.dumpdata.com>
	<5086C0C8.5000306@citrix.com>
	<20121023172008.GB11787@phenom.dumpdata.com>
	<5086DD57.4000206@citrix.com>
	<20121023185049.GB20350@phenom.dumpdata.com>
In-Reply-To: <20121023185049.GB20350@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk ,
	"linux-kernel@vger.kernel.org" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH RFC] Persistent grant maps for xen blk
 drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Pj4+IE9uIDIzLjEwLjEyIGF0IDIwOjUwLCBLb25yYWQgUnplc3p1dGVrIFdpbGsgPGtvbnJhZEBr
ZXJuZWwub3JnPiB3cm90ZToKPiBPbiBUdWUsIE9jdCAyMywgMjAxMiBhdCAwODowOToyN1BNICsw
MjAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOgo+PiBPbiAyMy8xMC8xMiAxOToyMCwgS29ucmFk
IFJ6ZXN6dXRlayBXaWxrIHdyb3RlOgo+PiA+Pj4+IGRpZmYgLS1naXQgYS9kcml2ZXJzL2Jsb2Nr
L3hlbi1ibGtiYWNrL2Jsa2JhY2suYyAKPiBiL2RyaXZlcnMvYmxvY2sveGVuLWJsa2JhY2svYmxr
YmFjay5jCj4+ID4+Pj4gaW5kZXggYzZkZWNiOS4uMmI5ODJiMiAxMDA2NDQKPj4gPj4+PiAtLS0g
YS9kcml2ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL2Jsa2JhY2suYwo+PiA+Pj4+ICsrKyBiL2RyaXZl
cnMvYmxvY2sveGVuLWJsa2JhY2svYmxrYmFjay5jCj4+ID4+Pj4gQEAgLTc4LDYgKzc4LDcgQEAg
c3RydWN0IHBlbmRpbmdfcmVxIHsKPj4gPj4+PiAgICAgICB1bnNpZ25lZCBzaG9ydCAgICAgICAg
ICBvcGVyYXRpb247Cj4+ID4+Pj4gICAgICAgaW50ICAgICAgICAgICAgICAgICAgICAgc3RhdHVz
Owo+PiA+Pj4+ICAgICAgIHN0cnVjdCBsaXN0X2hlYWQgICAgICAgIGZyZWVfbGlzdDsKPj4gPj4+
PiArICAgICB1bnNpZ25lZCBpbnQgICAgICAgICAgICB1bm1hcF9zZWdbQkxLSUZfTUFYX1NFR01F
TlRTX1BFUl9SRVFVRVNUXTsKPj4gCj4+IFNob3VsZCBJIGNoYW5nZSB0aGlzIHRvIGEgYm9vbD8g
U2luY2Ugd2UgYXJlIG9ubHkgc2V0dGluZyBpdCB0byAwIG9yIDEuCj4gCj4gSSB3b3VsZCBqdXN0
IGtlZXAgaXQgYXMgJ2ludCcuIEV2ZW50dWFsbHkgd2UgY2FuIHJlcGxhY2UgdGhpcyB3aXRoIGEK
PiBiaXQtbWFwLCBidXQgdGhhdCBjYW4gYmUgZG9uZSBsYXRlci4KCkkgdGhpbmsgdGhpcyBzaG91
bGQgYmUgYSBiaXRtYXAgZnJvbSB0aGUgYmVnaW5uaW5nIC0gd2h5IHdvdWxkCnlvdSB3YW50IHRv
IHdhc3RlIDQ0IGJ5dGVzIHBlciByZXF1ZXN0IGZvciBzb21ldGhpbmcgdGhhdCBmaXRzCmluIGEg
c2luZ2xlIHVuc2lnbmVkIGxvbmcgKGFuZCB0aGUgcGljdHVyZSB3b3VsZCBnZXQgd29yc2Ugd2l0
aAp0aGUgbnVtYmVyLW9mLXNlZ21lbnRzIGV4dGVuc2lvbik/CgpBbHNvIC0gYW0gSSB0YWtpbmcg
dGhpcyB3b3JrIGJlaW5nIGRvbmUgaGVyZSBhcyBhIHNpbGVudCBhZ3JlZW1lbnQKdG8gbm90IGlu
dmVzdCBpbnRvIGJsa2lmMiB0byBzdHJlYW1saW5lIHRoZSB2YXJpb3VzIGV4dGVuc2lvbnMKZmxv
YXRpbmcgYXJvdW5kPwoKSmFuCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3Jn
Cmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Oct 24 07:40:45 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 07:40:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQvZb-0004QF-UB; Wed, 24 Oct 2012 07:40:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQvZb-0004QA-5M
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 07:40:19 +0000
Received: from [85.158.138.51:60244] by server-15.bemta-3.messagelabs.com id
	38/F1-09445-26B97805; Wed, 24 Oct 2012 07:40:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1351064415!35547450!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4935 invoked from network); 24 Oct 2012 07:40:15 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-174.messagelabs.com with SMTP;
	24 Oct 2012 07:40:15 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 24 Oct 2012 08:40:14 +0100
Message-Id: <5087B77A02000078000A3D00@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 24 Oct 2012 08:40:10 +0100
From: "Jan Beulich" 
To: ,"Konrad Rzeszutek Wilk" 
References: <1350559321-19066-1-git-send-email-roger.pau@citrix.com>
	<20121022134708.GA13832@konrad-lan.dumpdata.com>
	<5086C0C8.5000306@citrix.com>
	<20121023172008.GB11787@phenom.dumpdata.com>
	<5086DD57.4000206@citrix.com>
	<20121023185049.GB20350@phenom.dumpdata.com>
In-Reply-To: <20121023185049.GB20350@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk ,
	"linux-kernel@vger.kernel.org" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH RFC] Persistent grant maps for xen blk
 drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Pj4+IE9uIDIzLjEwLjEyIGF0IDIwOjUwLCBLb25yYWQgUnplc3p1dGVrIFdpbGsgPGtvbnJhZEBr
ZXJuZWwub3JnPiB3cm90ZToKPiBPbiBUdWUsIE9jdCAyMywgMjAxMiBhdCAwODowOToyN1BNICsw
MjAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOgo+PiBPbiAyMy8xMC8xMiAxOToyMCwgS29ucmFk
IFJ6ZXN6dXRlayBXaWxrIHdyb3RlOgo+PiA+Pj4+IGRpZmYgLS1naXQgYS9kcml2ZXJzL2Jsb2Nr
L3hlbi1ibGtiYWNrL2Jsa2JhY2suYyAKPiBiL2RyaXZlcnMvYmxvY2sveGVuLWJsa2JhY2svYmxr
YmFjay5jCj4+ID4+Pj4gaW5kZXggYzZkZWNiOS4uMmI5ODJiMiAxMDA2NDQKPj4gPj4+PiAtLS0g
YS9kcml2ZXJzL2Jsb2NrL3hlbi1ibGtiYWNrL2Jsa2JhY2suYwo+PiA+Pj4+ICsrKyBiL2RyaXZl
cnMvYmxvY2sveGVuLWJsa2JhY2svYmxrYmFjay5jCj4+ID4+Pj4gQEAgLTc4LDYgKzc4LDcgQEAg
c3RydWN0IHBlbmRpbmdfcmVxIHsKPj4gPj4+PiAgICAgICB1bnNpZ25lZCBzaG9ydCAgICAgICAg
ICBvcGVyYXRpb247Cj4+ID4+Pj4gICAgICAgaW50ICAgICAgICAgICAgICAgICAgICAgc3RhdHVz
Owo+PiA+Pj4+ICAgICAgIHN0cnVjdCBsaXN0X2hlYWQgICAgICAgIGZyZWVfbGlzdDsKPj4gPj4+
PiArICAgICB1bnNpZ25lZCBpbnQgICAgICAgICAgICB1bm1hcF9zZWdbQkxLSUZfTUFYX1NFR01F
TlRTX1BFUl9SRVFVRVNUXTsKPj4gCj4+IFNob3VsZCBJIGNoYW5nZSB0aGlzIHRvIGEgYm9vbD8g
U2luY2Ugd2UgYXJlIG9ubHkgc2V0dGluZyBpdCB0byAwIG9yIDEuCj4gCj4gSSB3b3VsZCBqdXN0
IGtlZXAgaXQgYXMgJ2ludCcuIEV2ZW50dWFsbHkgd2UgY2FuIHJlcGxhY2UgdGhpcyB3aXRoIGEK
PiBiaXQtbWFwLCBidXQgdGhhdCBjYW4gYmUgZG9uZSBsYXRlci4KCkkgdGhpbmsgdGhpcyBzaG91
bGQgYmUgYSBiaXRtYXAgZnJvbSB0aGUgYmVnaW5uaW5nIC0gd2h5IHdvdWxkCnlvdSB3YW50IHRv
IHdhc3RlIDQ0IGJ5dGVzIHBlciByZXF1ZXN0IGZvciBzb21ldGhpbmcgdGhhdCBmaXRzCmluIGEg
c2luZ2xlIHVuc2lnbmVkIGxvbmcgKGFuZCB0aGUgcGljdHVyZSB3b3VsZCBnZXQgd29yc2Ugd2l0
aAp0aGUgbnVtYmVyLW9mLXNlZ21lbnRzIGV4dGVuc2lvbik/CgpBbHNvIC0gYW0gSSB0YWtpbmcg
dGhpcyB3b3JrIGJlaW5nIGRvbmUgaGVyZSBhcyBhIHNpbGVudCBhZ3JlZW1lbnQKdG8gbm90IGlu
dmVzdCBpbnRvIGJsa2lmMiB0byBzdHJlYW1saW5lIHRoZSB2YXJpb3VzIGV4dGVuc2lvbnMKZmxv
YXRpbmcgYXJvdW5kPwoKSmFuCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3Jn
Cmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Oct 24 07:55:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 07:55:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQvnq-0004qR-Hd; Wed, 24 Oct 2012 07:55:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQvno-0004qM-FC
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 07:55:00 +0000
Received: from [193.109.254.147:61538] by server-8.bemta-14.messagelabs.com id
	DF/75-16549-3DE97805; Wed, 24 Oct 2012 07:54:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1351065233!14385144!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7588 invoked from network); 24 Oct 2012 07:53:54 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-27.messagelabs.com with SMTP;
	24 Oct 2012 07:53:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 24 Oct 2012 08:53:53 +0100
Message-Id: <5087BAAF02000078000A3D15@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 24 Oct 2012 08:53:51 +0100
From: "Jan Beulich" 
To: "xen-devel" 
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartBE8F649F.0__="
Subject: [Xen-devel] [PATCH] x86: don't special case first IO-APIC
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartBE8F649F.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

It has always been puzzling me why the first IO-APIC gets special cased
in two places, and finally Xen got run on a system where this breaks:

(XEN) ACPI: IOAPIC (id[0x10] address[0xfecff000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 16, version 17, address 0xfecff000, GSI 0-2
(XEN) ACPI: IOAPIC (id[0x0f] address[0xfec00000] gsi_base[3])
(XEN) IOAPIC[1]: apic_id 15, version 17, address 0xfec00000, GSI 3-38
(XEN) ACPI: IOAPIC (id[0x0e] address[0xfec01000] gsi_base[39])
(XEN) IOAPIC[2]: apic_id 14, version 17, address 0xfec01000, GSI 39-74
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 1 global_irq 4 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 5 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 3 global_irq 6 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 4 global_irq 7 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 6 global_irq 9 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 7 global_irq 10 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 8 global_irq 11 low edge)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 12 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 12 global_irq 15 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 13 global_irq 16 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 17 low edge)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 18 dfl dfl)

i.e. all legacy IRQs (apart from the timer one, but the firmware passed
data doesn't look right for that case anyway, as both Xen and native
Linux are falling back to use the virtual wire setup for IRQ0,
apparently rather using pin 2 of the first IO-APIC) are being handled
by the second IO-APIC.

This at once eliminates the possibility of an unmasked RTE getting
written without having got a vector put in place (in
setup_IO_APIC_irqs()).

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -990,18 +990,17 @@ static void __init setup_IO_APIC_irqs(vo
             else
                 add_pin_to_irq(irq, apic, pin);
=20
-            if (!apic && !IO_APIC_IRQ(irq))
+            if (!IO_APIC_IRQ(irq))
                 continue;
=20
-            if (IO_APIC_IRQ(irq)) {
-                vector =3D assign_irq_vector(irq, NULL);
-                BUG_ON(vector < 0);
-                entry.vector =3D vector;
-                ioapic_register_intr(irq, IOAPIC_AUTO);
+            vector =3D assign_irq_vector(irq, NULL);
+            BUG_ON(vector < 0);
+            entry.vector =3D vector;
+            ioapic_register_intr(irq, IOAPIC_AUTO);
+
+            if (platform_legacy_irq(irq))
+                disable_8259A_irq(irq_to_desc(irq));
=20
-                if (!apic && platform_legacy_irq(irq))
-                    disable_8259A_irq(irq_to_desc(irq));
-            }
             desc =3D irq_to_desc(irq);
             SET_DEST(entry.dest.dest32, entry.dest.logical.logical_dest,
                      cpu_mask_to_apicid(desc->arch.cpu_mask));
@@ -2245,18 +2244,15 @@ unsigned apic_gsi_base(int apic);
=20
 static int apic_pin_2_gsi_irq(int apic, int pin)
 {
-    int idx, irq;
+    int idx;
=20
     if (apic < 0)
        return -EINVAL;
=20
-    irq =3D apic_gsi_base(apic) + pin;
-    if (apic =3D=3D 0) {
-        idx =3D find_irq_entry(apic, pin, mp_INT);
-        if (idx >=3D 0)
-            irq =3D pin_2_irq(idx, apic, pin);
-    }
-    return irq;
+    idx =3D find_irq_entry(apic, pin, mp_INT);
+
+    return idx >=3D 0 ? pin_2_irq(idx, apic, pin)
+                    : apic_gsi_base(apic) + pin;
 }
=20
 int ioapic_guest_read(unsigned long physbase, unsigned int reg, u32 =
*pval)




--=__PartBE8F649F.0__=
Content-Type: text/plain; name="x86-IOAPIC-legacy-not-first.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-IOAPIC-legacy-not-first.patch"

x86: don't special case first IO-APIC=0A=0AIt has always been puzzling me =
why the first IO-APIC gets special cased=0Ain two places, and finally Xen =
got run on a system where this breaks:=0A=0A(XEN) ACPI: IOAPIC (id[0x10] =
address[0xfecff000] gsi_base[0])=0A(XEN) IOAPIC[0]: apic_id 16, version =
17, address 0xfecff000, GSI 0-2=0A(XEN) ACPI: IOAPIC (id[0x0f] address[0xfe=
c00000] gsi_base[3])=0A(XEN) IOAPIC[1]: apic_id 15, version 17, address =
0xfec00000, GSI 3-38=0A(XEN) ACPI: IOAPIC (id[0x0e] address[0xfec01000] =
gsi_base[39])=0A(XEN) IOAPIC[2]: apic_id 14, version 17, address 0xfec01000=
, GSI 39-74=0A(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 1 global_irq 4 dfl =
dfl)=0A(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 5 dfl dfl)=0A(XE=
N) ACPI: INT_SRC_OVR (bus 0 bus_irq 3 global_irq 6 dfl dfl)=0A(XEN) ACPI: =
INT_SRC_OVR (bus 0 bus_irq 4 global_irq 7 dfl dfl)=0A(XEN) ACPI: INT_SRC_OV=
R (bus 0 bus_irq 6 global_irq 9 dfl dfl)=0A(XEN) ACPI: INT_SRC_OVR (bus 0 =
bus_irq 7 global_irq 10 dfl dfl)=0A(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq =
8 global_irq 11 low edge)=0A(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 =
global_irq 12 dfl dfl)=0A(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 12 =
global_irq 15 dfl dfl)=0A(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 13 =
global_irq 16 dfl dfl)=0A(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 14 =
global_irq 17 low edge)=0A(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 15 =
global_irq 18 dfl dfl)=0A=0Ai.e. all legacy IRQs (apart from the timer =
one, but the firmware passed=0Adata doesn't look right for that case =
anyway, as both Xen and native=0ALinux are falling back to use the virtual =
wire setup for IRQ0,=0Aapparently rather using pin 2 of the first IO-APIC) =
are being handled=0Aby the second IO-APIC.=0A=0AThis at once eliminates =
the possibility of an unmasked RTE getting=0Awritten without having got a =
vector put in place (in=0Asetup_IO_APIC_irqs()).=0A=0ASigned-off-by: Jan =
Beulich =0A=0A--- a/xen/arch/x86/io_apic.c=0A+++ =
b/xen/arch/x86/io_apic.c=0A@@ -990,18 +990,17 @@ static void __init =
setup_IO_APIC_irqs(vo=0A             else=0A                 add_pin_to_irq=
(irq, apic, pin);=0A =0A-            if (!apic && !IO_APIC_IRQ(irq))=0A+   =
         if (!IO_APIC_IRQ(irq))=0A                 continue;=0A =0A-       =
     if (IO_APIC_IRQ(irq)) {=0A-                vector =3D assign_irq_vecto=
r(irq, NULL);=0A-                BUG_ON(vector < 0);=0A-                =
entry.vector =3D vector;=0A-                ioapic_register_intr(irq, =
IOAPIC_AUTO);=0A+            vector =3D assign_irq_vector(irq, NULL);=0A+  =
          BUG_ON(vector < 0);=0A+            entry.vector =3D vector;=0A+  =
          ioapic_register_intr(irq, IOAPIC_AUTO);=0A+=0A+            if =
(platform_legacy_irq(irq))=0A+                disable_8259A_irq(irq_to_desc=
(irq));=0A =0A-                if (!apic && platform_legacy_irq(irq))=0A-  =
                  disable_8259A_irq(irq_to_desc(irq));=0A-            }=0A =
            desc =3D irq_to_desc(irq);=0A             SET_DEST(entry.dest.d=
est32, entry.dest.logical.logical_dest,=0A                      cpu_mask_to=
_apicid(desc->arch.cpu_mask));=0A@@ -2245,18 +2244,15 @@ unsigned =
apic_gsi_base(int apic);=0A =0A static int apic_pin_2_gsi_irq(int apic, =
int pin)=0A {=0A-    int idx, irq;=0A+    int idx;=0A =0A     if (apic < =
0)=0A        return -EINVAL;=0A =0A-    irq =3D apic_gsi_base(apic) + =
pin;=0A-    if (apic =3D=3D 0) {=0A-        idx =3D find_irq_entry(apic, =
pin, mp_INT);=0A-        if (idx >=3D 0)=0A-            irq =3D pin_2_irq(i=
dx, apic, pin);=0A-    }=0A-    return irq;=0A+    idx =3D find_irq_entry(a=
pic, pin, mp_INT);=0A+=0A+    return idx >=3D 0 ? pin_2_irq(idx, apic, =
pin)=0A+                    : apic_gsi_base(apic) + pin;=0A }=0A =0A int =
ioapic_guest_read(unsigned long physbase, unsigned int reg, u32 *pval)=0A
--=__PartBE8F649F.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__PartBE8F649F.0__=--


From xen-devel-bounces@lists.xen.org Wed Oct 24 07:55:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 07:55:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQvnq-0004qR-Hd; Wed, 24 Oct 2012 07:55:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQvno-0004qM-FC
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 07:55:00 +0000
Received: from [193.109.254.147:61538] by server-8.bemta-14.messagelabs.com id
	DF/75-16549-3DE97805; Wed, 24 Oct 2012 07:54:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1351065233!14385144!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7588 invoked from network); 24 Oct 2012 07:53:54 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-27.messagelabs.com with SMTP;
	24 Oct 2012 07:53:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 24 Oct 2012 08:53:53 +0100
Message-Id: <5087BAAF02000078000A3D15@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 24 Oct 2012 08:53:51 +0100
From: "Jan Beulich" 
To: "xen-devel" 
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartBE8F649F.0__="
Subject: [Xen-devel] [PATCH] x86: don't special case first IO-APIC
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartBE8F649F.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

It has always been puzzling me why the first IO-APIC gets special cased
in two places, and finally Xen got run on a system where this breaks:

(XEN) ACPI: IOAPIC (id[0x10] address[0xfecff000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 16, version 17, address 0xfecff000, GSI 0-2
(XEN) ACPI: IOAPIC (id[0x0f] address[0xfec00000] gsi_base[3])
(XEN) IOAPIC[1]: apic_id 15, version 17, address 0xfec00000, GSI 3-38
(XEN) ACPI: IOAPIC (id[0x0e] address[0xfec01000] gsi_base[39])
(XEN) IOAPIC[2]: apic_id 14, version 17, address 0xfec01000, GSI 39-74
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 1 global_irq 4 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 5 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 3 global_irq 6 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 4 global_irq 7 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 6 global_irq 9 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 7 global_irq 10 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 8 global_irq 11 low edge)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 12 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 12 global_irq 15 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 13 global_irq 16 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 17 low edge)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 18 dfl dfl)

i.e. all legacy IRQs (apart from the timer one, but the firmware passed
data doesn't look right for that case anyway, as both Xen and native
Linux are falling back to use the virtual wire setup for IRQ0,
apparently rather using pin 2 of the first IO-APIC) are being handled
by the second IO-APIC.

This at once eliminates the possibility of an unmasked RTE getting
written without having got a vector put in place (in
setup_IO_APIC_irqs()).

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -990,18 +990,17 @@ static void __init setup_IO_APIC_irqs(vo
             else
                 add_pin_to_irq(irq, apic, pin);
=20
-            if (!apic && !IO_APIC_IRQ(irq))
+            if (!IO_APIC_IRQ(irq))
                 continue;
=20
-            if (IO_APIC_IRQ(irq)) {
-                vector =3D assign_irq_vector(irq, NULL);
-                BUG_ON(vector < 0);
-                entry.vector =3D vector;
-                ioapic_register_intr(irq, IOAPIC_AUTO);
+            vector =3D assign_irq_vector(irq, NULL);
+            BUG_ON(vector < 0);
+            entry.vector =3D vector;
+            ioapic_register_intr(irq, IOAPIC_AUTO);
+
+            if (platform_legacy_irq(irq))
+                disable_8259A_irq(irq_to_desc(irq));
=20
-                if (!apic && platform_legacy_irq(irq))
-                    disable_8259A_irq(irq_to_desc(irq));
-            }
             desc =3D irq_to_desc(irq);
             SET_DEST(entry.dest.dest32, entry.dest.logical.logical_dest,
                      cpu_mask_to_apicid(desc->arch.cpu_mask));
@@ -2245,18 +2244,15 @@ unsigned apic_gsi_base(int apic);
=20
 static int apic_pin_2_gsi_irq(int apic, int pin)
 {
-    int idx, irq;
+    int idx;
=20
     if (apic < 0)
        return -EINVAL;
=20
-    irq =3D apic_gsi_base(apic) + pin;
-    if (apic =3D=3D 0) {
-        idx =3D find_irq_entry(apic, pin, mp_INT);
-        if (idx >=3D 0)
-            irq =3D pin_2_irq(idx, apic, pin);
-    }
-    return irq;
+    idx =3D find_irq_entry(apic, pin, mp_INT);
+
+    return idx >=3D 0 ? pin_2_irq(idx, apic, pin)
+                    : apic_gsi_base(apic) + pin;
 }
=20
 int ioapic_guest_read(unsigned long physbase, unsigned int reg, u32 =
*pval)




--=__PartBE8F649F.0__=
Content-Type: text/plain; name="x86-IOAPIC-legacy-not-first.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-IOAPIC-legacy-not-first.patch"

x86: don't special case first IO-APIC=0A=0AIt has always been puzzling me =
why the first IO-APIC gets special cased=0Ain two places, and finally Xen =
got run on a system where this breaks:=0A=0A(XEN) ACPI: IOAPIC (id[0x10] =
address[0xfecff000] gsi_base[0])=0A(XEN) IOAPIC[0]: apic_id 16, version =
17, address 0xfecff000, GSI 0-2=0A(XEN) ACPI: IOAPIC (id[0x0f] address[0xfe=
c00000] gsi_base[3])=0A(XEN) IOAPIC[1]: apic_id 15, version 17, address =
0xfec00000, GSI 3-38=0A(XEN) ACPI: IOAPIC (id[0x0e] address[0xfec01000] =
gsi_base[39])=0A(XEN) IOAPIC[2]: apic_id 14, version 17, address 0xfec01000=
, GSI 39-74=0A(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 1 global_irq 4 dfl =
dfl)=0A(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 5 dfl dfl)=0A(XE=
N) ACPI: INT_SRC_OVR (bus 0 bus_irq 3 global_irq 6 dfl dfl)=0A(XEN) ACPI: =
INT_SRC_OVR (bus 0 bus_irq 4 global_irq 7 dfl dfl)=0A(XEN) ACPI: INT_SRC_OV=
R (bus 0 bus_irq 6 global_irq 9 dfl dfl)=0A(XEN) ACPI: INT_SRC_OVR (bus 0 =
bus_irq 7 global_irq 10 dfl dfl)=0A(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq =
8 global_irq 11 low edge)=0A(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 =
global_irq 12 dfl dfl)=0A(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 12 =
global_irq 15 dfl dfl)=0A(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 13 =
global_irq 16 dfl dfl)=0A(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 14 =
global_irq 17 low edge)=0A(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 15 =
global_irq 18 dfl dfl)=0A=0Ai.e. all legacy IRQs (apart from the timer =
one, but the firmware passed=0Adata doesn't look right for that case =
anyway, as both Xen and native=0ALinux are falling back to use the virtual =
wire setup for IRQ0,=0Aapparently rather using pin 2 of the first IO-APIC) =
are being handled=0Aby the second IO-APIC.=0A=0AThis at once eliminates =
the possibility of an unmasked RTE getting=0Awritten without having got a =
vector put in place (in=0Asetup_IO_APIC_irqs()).=0A=0ASigned-off-by: Jan =
Beulich =0A=0A--- a/xen/arch/x86/io_apic.c=0A+++ =
b/xen/arch/x86/io_apic.c=0A@@ -990,18 +990,17 @@ static void __init =
setup_IO_APIC_irqs(vo=0A             else=0A                 add_pin_to_irq=
(irq, apic, pin);=0A =0A-            if (!apic && !IO_APIC_IRQ(irq))=0A+   =
         if (!IO_APIC_IRQ(irq))=0A                 continue;=0A =0A-       =
     if (IO_APIC_IRQ(irq)) {=0A-                vector =3D assign_irq_vecto=
r(irq, NULL);=0A-                BUG_ON(vector < 0);=0A-                =
entry.vector =3D vector;=0A-                ioapic_register_intr(irq, =
IOAPIC_AUTO);=0A+            vector =3D assign_irq_vector(irq, NULL);=0A+  =
          BUG_ON(vector < 0);=0A+            entry.vector =3D vector;=0A+  =
          ioapic_register_intr(irq, IOAPIC_AUTO);=0A+=0A+            if =
(platform_legacy_irq(irq))=0A+                disable_8259A_irq(irq_to_desc=
(irq));=0A =0A-                if (!apic && platform_legacy_irq(irq))=0A-  =
                  disable_8259A_irq(irq_to_desc(irq));=0A-            }=0A =
            desc =3D irq_to_desc(irq);=0A             SET_DEST(entry.dest.d=
est32, entry.dest.logical.logical_dest,=0A                      cpu_mask_to=
_apicid(desc->arch.cpu_mask));=0A@@ -2245,18 +2244,15 @@ unsigned =
apic_gsi_base(int apic);=0A =0A static int apic_pin_2_gsi_irq(int apic, =
int pin)=0A {=0A-    int idx, irq;=0A+    int idx;=0A =0A     if (apic < =
0)=0A        return -EINVAL;=0A =0A-    irq =3D apic_gsi_base(apic) + =
pin;=0A-    if (apic =3D=3D 0) {=0A-        idx =3D find_irq_entry(apic, =
pin, mp_INT);=0A-        if (idx >=3D 0)=0A-            irq =3D pin_2_irq(i=
dx, apic, pin);=0A-    }=0A-    return irq;=0A+    idx =3D find_irq_entry(a=
pic, pin, mp_INT);=0A+=0A+    return idx >=3D 0 ? pin_2_irq(idx, apic, =
pin)=0A+                    : apic_gsi_base(apic) + pin;=0A }=0A =0A int =
ioapic_guest_read(unsigned long physbase, unsigned int reg, u32 *pval)=0A
--=__PartBE8F649F.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__PartBE8F649F.0__=--


From xen-devel-bounces@lists.xen.org Wed Oct 24 08:07:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 08:07:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQvzR-0005VA-Qf; Wed, 24 Oct 2012 08:07:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQvzP-0005V5-KC
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 08:07:00 +0000
Received: from [85.158.138.51:18953] by server-6.bemta-3.messagelabs.com id
	8F/C0-32375-2A1A7805; Wed, 24 Oct 2012 08:06:58 +0000
X-Env-Sender: zpengxen@gmail.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1351066008!35472809!1
X-Originating-IP: [209.85.223.171]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2663 invoked from network); 24 Oct 2012 08:06:50 -0000
Received: from mail-ie0-f171.google.com (HELO mail-ie0-f171.google.com)
	(209.85.223.171)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 08:06:50 -0000
Received: by mail-ie0-f171.google.com with SMTP id s9so352603iec.30
	for ;
	Wed, 24 Oct 2012 01:06:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=teDWIXVFoxfsZHbpAgtr44zHNhQ1QTGUYieIJrgwHTA=;
	b=H4lbE0JaBx2von8RULyvdr189Z/WUi09qR96xUN7DfbykpL1J3TtFatSO2MZXhWBs7
	oJoUorCdwxzzvslcD6JVnYzCXjtfM3TB6FhfPKUWm0UkQRNsUWa+yo4jtBn4SM9PTfMB
	BQ69+osl9WnRToM2hHuh1rm5AYvR87J2zt6pu0DQAxxk3cXXdvBmGwnrl33IaSDx9elN
	Cl8fh8OR4Ihks/0x144hj6zFVz7m41Egwm/t5ZvNPFrhBcctW4wutT9ERBUpQEj3TruS
	QfZaOUYk26pELfIT0AG55Up+u9vRT8xO1cBNWAsg6YuPEh5XIZ+kdIQlsmgi1NM0YbOE
	949Q==
MIME-Version: 1.0
Received: by 10.50.236.99 with SMTP id ut3mr1551122igc.73.1351066008563; Wed,
	24 Oct 2012 01:06:48 -0700 (PDT)
Received: by 10.50.128.137 with HTTP; Wed, 24 Oct 2012 01:06:48 -0700 (PDT)
In-Reply-To: <508559E8.10102@eu.citrix.com>
References: 
	<1338987918.32319.84.camel@zakaz.uk.xensource.com>
	
	<1339049291.6557.11.camel@dagon.hellion.org.uk>
	
	<1341325462.21547.20.camel@zakaz.uk.xensource.com>
	
	
	
	<508559E8.10102@eu.citrix.com>
Date: Wed, 24 Oct 2012 16:06:48 +0800
Message-ID: 
From: ZhouPeng 
To: George Dunlap 
Content-Type: multipart/mixed; boundary=bcaec545479a822f7204ccc991cc
Cc: "Xen-Devel \(E-mail\)" ,
	Ian Jackson ,
	Ian Campbell ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 2/3] tools:libxl: Add qxl vga interface
 support v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--bcaec545479a822f7204ccc991cc
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Oct 22, 2012 at 10:36 PM, George Dunlap
 wrote:
> On 18/10/12 11:19, ZhouPeng wrote:
>>
>> v4
>>
>> test and fix conflict with the latest Xen
>> -----
>>
>>
>> tools:libxl: Add qxl vga interface support for upstream-qemu-xen.
>>
>> Usage:
>>    qxl=1|0
>>
>> Signed-off-by: Zhou Peng 
>
>
> Thanks, Zhou Peng.  Just a couple of comments below:
>
>
>>
>> diff -r c1c549c4fe9e docs/man/xl.cfg.pod.5
>> --- a/docs/man/xl.cfg.pod.5     Mon Oct 15 16:51:44 2012 +0100
>> +++ b/docs/man/xl.cfg.pod.5     Thu Oct 18 17:53:25 2012 +0800
>> @@ -930,10 +930,13 @@ in the B for configurin
>>
>>   Sets the amount of RAM which the emulated video card will contain,
>>   which in turn limits the resolutions and bit depths which will be
>> -available. This option is only available when using the B
>> -option (see below).
>> +available. This option is only available when using the B and
>> +B option (see below).
>>   The default amount of video ram for stdvga is 8MB which is sufficient
>>   for e.g. 1600x1200 at 32bpp.
>> +For B option, the default is 128MB. If B is set greater
>> +than 128MB, it will be trimmed to 128MB; if set less than 128MB, an
>> +error will be triggered.
>
>
> Is this a fixed value in qemu, or is this something that can be changed via
> the command-line?
Can be changed.

But Ian Campbell and me have talked on sth related with this
closely before. And we both agree to just support the default is
enough in most time. You can get it from the url below quickly, pls
read from bottom up, which can save time.

http://lists.xen.org/archives/html/xen-devel/2012-07/msg00098.html

Thanks,
-Zhou Peng
>
>
>> +
>> +        if (b_info->device_model_version ==
>> LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN
>> +            && b_info->u.hvm.vga.kind == LIBXL_VGA_INTERFACE_TYPE_QXL) {
>> +            /*
>> +             * QXL needs 128 Mib video ram by default.
>> +             */
>> +            if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT) {
>> +                b_info->video_memkb = 128 * 1024;
>> +            }
>> +            if (b_info->video_memkb < 128 * 1024) {
>> +                LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
>> +                    "128 Mib videoram is necessary for qxl default");
>> +                return ERROR_INVAL;
>> +            }
>> +            if (b_info->video_memkb > 128 * 1024) {
>> +                b_info->video_memkb = 128 * 1024;
>> +                LIBXL__LOG(CTX, LIBXL__LOG_WARNING,
>> +                            "trim videoram to qxl default: 128 Mib");
>> +            }
>> +        }
>
>
> It would be better to have a single #define for the required QXL video mem
> size, rather than duplicating "128*1024" several times.
>
> Other than that, looks pretty good to me.

Fixed in v5
> Thanks,
>  -George
>

Patch v5 is appended and attached below .
------------------

tools:libxl: Add qxl vga interface support for upstream-qemu-xen.

Usage:
  qxl=1|0

Signed-off-by: Zhou Peng 

diff -r c1c549c4fe9e docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5	Mon Oct 15 16:51:44 2012 +0100
+++ b/docs/man/xl.cfg.pod.5	Wed Oct 24 15:39:43 2012 +0800
@@ -930,10 +930,13 @@ in the B for configurin

 Sets the amount of RAM which the emulated video card will contain,
 which in turn limits the resolutions and bit depths which will be
-available. This option is only available when using the B
-option (see below).
+available. This option is only available when using the B and
+B option (see below).
 The default amount of video ram for stdvga is 8MB which is sufficient
 for e.g. 1600x1200 at 32bpp.
+For B option, the default is 128MB. If B is set greater
+than 128MB, it will be trimmed to 128MB; if set less than 128MB, an
+error will be triggered.

 When using the emulated Cirrus graphics card (B)
 the amount of video ram is fixed at 4MB which is sufficient
@@ -951,6 +954,14 @@ a Cirrus Logic GD5446 VGA card. If your
 a Cirrus Logic GD5446 VGA card. If your guest supports VBE 2.0 or
 later (e.g. Windows XP onwards) then you should enable this.
 stdvga supports more video ram and bigger resolutions than Cirrus.
+
+=item B
+
+Select a QXL VGA card as the emulated graphics device.
+In general, QXL should work with the Spice remote display protocol
+for acceleration, and QXL driver is necessary in guest in this case.
+QXL can also work with the VNC protocol, but it will be like a standard
+VGA without acceleration.

 =item B

diff -r c1c549c4fe9e tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Oct 15 16:51:44 2012 +0100
+++ b/tools/libxl/libxl_create.c	Wed Oct 24 15:39:43 2012 +0800
@@ -232,8 +232,31 @@ int libxl__domain_build_info_setdefault(
     case LIBXL_DOMAIN_TYPE_HVM:
         if (b_info->shadow_memkb == LIBXL_MEMKB_DEFAULT)
             b_info->shadow_memkb = 0;
+
+        if (b_info->device_model_version == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN
+            && b_info->u.hvm.vga.kind == LIBXL_VGA_INTERFACE_TYPE_QXL) {
+            /*
+             * QXL needs 128 Mib video ram by default.
+             */
+#define QXL_VIDEO_RAM_DEFAULT (128 * 1024)
+            if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT) {
+                b_info->video_memkb = QXL_VIDEO_RAM_DEFAULT;
+            }
+            if (b_info->video_memkb < QXL_VIDEO_RAM_DEFAULT) {
+                LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
+                    "128 Mib videoram is necessary for qxl default");
+                return ERROR_INVAL;
+            }
+            if (b_info->video_memkb > QXL_VIDEO_RAM_DEFAULT) {
+                b_info->video_memkb = QXL_VIDEO_RAM_DEFAULT;
+                LIBXL__LOG(CTX, LIBXL__LOG_WARNING,
+                            "trim videoram to qxl default: 128 Mib");
+            }
+#undef QXL_VIDEO_RAM_DEFAULT
+        }
         if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
             b_info->video_memkb = 8 * 1024;
+
         if (b_info->u.hvm.timer_mode == LIBXL_TIMER_MODE_DEFAULT)
             b_info->u.hvm.timer_mode =
                 LIBXL_TIMER_MODE_NO_DELAY_FOR_MISSED_TICKS;
diff -r c1c549c4fe9e tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Oct 15 16:51:44 2012 +0100
+++ b/tools/libxl/libxl_dm.c	Wed Oct 24 15:39:43 2012 +0800
@@ -181,6 +181,8 @@ static char ** libxl__build_device_model
             break;
         case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
             break;
+        case LIBXL_VGA_INTERFACE_TYPE_QXL:
+             break;
         }

         if (b_info->u.hvm.boot) {
@@ -430,6 +432,9 @@ static char ** libxl__build_device_model
             break;
         case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
             flexarray_vappend(dm_args, "-vga", "cirrus", NULL);
+            break;
+        case LIBXL_VGA_INTERFACE_TYPE_QXL:
+            flexarray_vappend(dm_args, "-vga", "qxl", NULL);
             break;
         }

diff -r c1c549c4fe9e tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Oct 15 16:51:44 2012 +0100
+++ b/tools/libxl/libxl_types.idl	Wed Oct 24 15:39:43 2012 +0800
@@ -130,6 +130,7 @@ libxl_vga_interface_type = Enumeration("
 libxl_vga_interface_type = Enumeration("vga_interface_type", [
     (1, "CIRRUS"),
     (2, "STD"),
+    (3, "QXL"),
     ], init_val = 0)

 #
diff -r c1c549c4fe9e tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Oct 15 16:51:44 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Wed Oct 24 15:39:43 2012 +0800
@@ -1402,6 +1402,14 @@ skip_vfb:
             b_info->u.hvm.vga.kind = l ? LIBXL_VGA_INTERFACE_TYPE_STD :
                                          LIBXL_VGA_INTERFACE_TYPE_CIRRUS;

+        if (!xlu_cfg_get_long(config, "qxl", &l, 0)) {
+            if (l) {
+                b_info->u.hvm.vga.kind = LIBXL_VGA_INTERFACE_TYPE_QXL;
+            } else if (!b_info->u.hvm.vga.kind) {
+                b_info->u.hvm.vga.kind = LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
+            }
+        }
+
         xlu_cfg_get_defbool(config, "vnc", &b_info->u.hvm.vnc.enable, 0);
         xlu_cfg_replace_string (config, "vnclisten",
                                 &b_info->u.hvm.vnc.listen, 0);


--
Zhou Peng

--bcaec545479a822f7204ccc991cc
Content-Type: application/octet-stream; 
	name="spice.tools.libxl.qxl.support+docs.v5.diff"
Content-Disposition: attachment; 
	filename="spice.tools.libxl.qxl.support+docs.v5.diff"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h8o5sips0

dG9vbHM6bGlieGw6IEFkZCBxeGwgdmdhIGludGVyZmFjZSBzdXBwb3J0IGZvciB1cHN0cmVhbS1x
ZW11LXhlbi4KClVzYWdlOgogIHF4bD0xfDAKClNpZ25lZC1vZmYtYnk6IFpob3UgUGVuZyA8YWls
dnBlbmcyNUBnbWFpbC5jb20+CgpkaWZmIC1yIGMxYzU0OWM0ZmU5ZSBkb2NzL21hbi94bC5jZmcu
cG9kLjUKLS0tIGEvZG9jcy9tYW4veGwuY2ZnLnBvZC41CU1vbiBPY3QgMTUgMTY6NTE6NDQgMjAx
MiArMDEwMAorKysgYi9kb2NzL21hbi94bC5jZmcucG9kLjUJV2VkIE9jdCAyNCAxNTozOTo0MyAy
MDEyICswODAwCkBAIC05MzAsMTAgKzkzMCwxMyBAQCBpbiB0aGUgQjxWRkJfU1BFQ19TVFJJTkc+
IGZvciBjb25maWd1cmluCiAKIFNldHMgdGhlIGFtb3VudCBvZiBSQU0gd2hpY2ggdGhlIGVtdWxh
dGVkIHZpZGVvIGNhcmQgd2lsbCBjb250YWluLAogd2hpY2ggaW4gdHVybiBsaW1pdHMgdGhlIHJl
c29sdXRpb25zIGFuZCBiaXQgZGVwdGhzIHdoaWNoIHdpbGwgYmUKLWF2YWlsYWJsZS4gVGhpcyBv
cHRpb24gaXMgb25seSBhdmFpbGFibGUgd2hlbiB1c2luZyB0aGUgQjxzdGR2Z2E+Ci1vcHRpb24g
KHNlZSBiZWxvdykuCithdmFpbGFibGUuIFRoaXMgb3B0aW9uIGlzIG9ubHkgYXZhaWxhYmxlIHdo
ZW4gdXNpbmcgdGhlIEI8c3RkdmdhPiBhbmQKK0I8cXhsPiBvcHRpb24gKHNlZSBiZWxvdykuCiBU
aGUgZGVmYXVsdCBhbW91bnQgb2YgdmlkZW8gcmFtIGZvciBzdGR2Z2EgaXMgOE1CIHdoaWNoIGlz
IHN1ZmZpY2llbnQKIGZvciBlLmcuIDE2MDB4MTIwMCBhdCAzMmJwcC4KK0ZvciBCPHF4bD4gb3B0
aW9uLCB0aGUgZGVmYXVsdCBpcyAxMjhNQi4gSWYgQjx2aWRlb3JhbT4gaXMgc2V0IGdyZWF0ZXIK
K3RoYW4gMTI4TUIsIGl0IHdpbGwgYmUgdHJpbW1lZCB0byAxMjhNQjsgaWYgc2V0IGxlc3MgdGhh
biAxMjhNQiwgYW4KK2Vycm9yIHdpbGwgYmUgdHJpZ2dlcmVkLgogCiBXaGVuIHVzaW5nIHRoZSBl
bXVsYXRlZCBDaXJydXMgZ3JhcGhpY3MgY2FyZCAoQjxzdGR2Z2E9MD4pCiB0aGUgYW1vdW50IG9m
IHZpZGVvIHJhbSBpcyBmaXhlZCBhdCA0TUIgd2hpY2ggaXMgc3VmZmljaWVudApAQCAtOTUxLDYg
Kzk1NCwxNCBAQCBhIENpcnJ1cyBMb2dpYyBHRDU0NDYgVkdBIGNhcmQuIElmIHlvdXIgCiBhIENp
cnJ1cyBMb2dpYyBHRDU0NDYgVkdBIGNhcmQuIElmIHlvdXIgZ3Vlc3Qgc3VwcG9ydHMgVkJFIDIu
MCBvcgogbGF0ZXIgKGUuZy4gV2luZG93cyBYUCBvbndhcmRzKSB0aGVuIHlvdSBzaG91bGQgZW5h
YmxlIHRoaXMuCiBzdGR2Z2Egc3VwcG9ydHMgbW9yZSB2aWRlbyByYW0gYW5kIGJpZ2dlciByZXNv
bHV0aW9ucyB0aGFuIENpcnJ1cy4KKworPWl0ZW0gQjxxeGw9Qk9PTEVBTj4KKworU2VsZWN0IGEg
UVhMIFZHQSBjYXJkIGFzIHRoZSBlbXVsYXRlZCBncmFwaGljcyBkZXZpY2UuCitJbiBnZW5lcmFs
LCBRWEwgc2hvdWxkIHdvcmsgd2l0aCB0aGUgU3BpY2UgcmVtb3RlIGRpc3BsYXkgcHJvdG9jb2wK
K2ZvciBhY2NlbGVyYXRpb24sIGFuZCBRWEwgZHJpdmVyIGlzIG5lY2Vzc2FyeSBpbiBndWVzdCBp
biB0aGlzIGNhc2UuCitRWEwgY2FuIGFsc28gd29yayB3aXRoIHRoZSBWTkMgcHJvdG9jb2wsIGJ1
dCBpdCB3aWxsIGJlIGxpa2UgYSBzdGFuZGFyZAorVkdBIHdpdGhvdXQgYWNjZWxlcmF0aW9uLgog
CiA9aXRlbSBCPHZuYz1CT09MRUFOPgogCmRpZmYgLXIgYzFjNTQ5YzRmZTllIHRvb2xzL2xpYnhs
L2xpYnhsX2NyZWF0ZS5jCi0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsX2NyZWF0ZS5jCU1vbiBPY3Qg
MTUgMTY6NTE6NDQgMjAxMiArMDEwMAorKysgYi90b29scy9saWJ4bC9saWJ4bF9jcmVhdGUuYwlX
ZWQgT2N0IDI0IDE1OjM5OjQzIDIwMTIgKzA4MDAKQEAgLTIzMiw4ICsyMzIsMzEgQEAgaW50IGxp
YnhsX19kb21haW5fYnVpbGRfaW5mb19zZXRkZWZhdWx0KAogICAgIGNhc2UgTElCWExfRE9NQUlO
X1RZUEVfSFZNOgogICAgICAgICBpZiAoYl9pbmZvLT5zaGFkb3dfbWVta2IgPT0gTElCWExfTUVN
S0JfREVGQVVMVCkKICAgICAgICAgICAgIGJfaW5mby0+c2hhZG93X21lbWtiID0gMDsKKworICAg
ICAgICBpZiAoYl9pbmZvLT5kZXZpY2VfbW9kZWxfdmVyc2lvbiA9PSBMSUJYTF9ERVZJQ0VfTU9E
RUxfVkVSU0lPTl9RRU1VX1hFTgorICAgICAgICAgICAgJiYgYl9pbmZvLT51Lmh2bS52Z2Eua2lu
ZCA9PSBMSUJYTF9WR0FfSU5URVJGQUNFX1RZUEVfUVhMKSB7CisgICAgICAgICAgICAvKgorICAg
ICAgICAgICAgICogUVhMIG5lZWRzIDEyOCBNaWIgdmlkZW8gcmFtIGJ5IGRlZmF1bHQuCisgICAg
ICAgICAgICAgKi8KKyNkZWZpbmUgUVhMX1ZJREVPX1JBTV9ERUZBVUxUICgxMjggKiAxMDI0KQor
ICAgICAgICAgICAgaWYgKGJfaW5mby0+dmlkZW9fbWVta2IgPT0gTElCWExfTUVNS0JfREVGQVVM
VCkgeworICAgICAgICAgICAgICAgIGJfaW5mby0+dmlkZW9fbWVta2IgPSBRWExfVklERU9fUkFN
X0RFRkFVTFQ7CisgICAgICAgICAgICB9CisgICAgICAgICAgICBpZiAoYl9pbmZvLT52aWRlb19t
ZW1rYiA8IFFYTF9WSURFT19SQU1fREVGQVVMVCkgeworICAgICAgICAgICAgICAgIExJQlhMX19M
T0coQ1RYLCBMSUJYTF9fTE9HX0VSUk9SLAorICAgICAgICAgICAgICAgICAgICAiMTI4IE1pYiB2
aWRlb3JhbSBpcyBuZWNlc3NhcnkgZm9yIHF4bCBkZWZhdWx0Iik7CisgICAgICAgICAgICAgICAg
cmV0dXJuIEVSUk9SX0lOVkFMOworICAgICAgICAgICAgfQorICAgICAgICAgICAgaWYgKGJfaW5m
by0+dmlkZW9fbWVta2IgPiBRWExfVklERU9fUkFNX0RFRkFVTFQpIHsKKyAgICAgICAgICAgICAg
ICBiX2luZm8tPnZpZGVvX21lbWtiID0gUVhMX1ZJREVPX1JBTV9ERUZBVUxUOworICAgICAgICAg
ICAgICAgIExJQlhMX19MT0coQ1RYLCBMSUJYTF9fTE9HX1dBUk5JTkcsCisgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgInRyaW0gdmlkZW9yYW0gdG8gcXhsIGRlZmF1bHQ6IDEyOCBNaWIiKTsK
KyAgICAgICAgICAgIH0KKyN1bmRlZiBRWExfVklERU9fUkFNX0RFRkFVTFQKKyAgICAgICAgfQog
ICAgICAgICBpZiAoYl9pbmZvLT52aWRlb19tZW1rYiA9PSBMSUJYTF9NRU1LQl9ERUZBVUxUKQog
ICAgICAgICAgICAgYl9pbmZvLT52aWRlb19tZW1rYiA9IDggKiAxMDI0OworCiAgICAgICAgIGlm
IChiX2luZm8tPnUuaHZtLnRpbWVyX21vZGUgPT0gTElCWExfVElNRVJfTU9ERV9ERUZBVUxUKQog
ICAgICAgICAgICAgYl9pbmZvLT51Lmh2bS50aW1lcl9tb2RlID0KICAgICAgICAgICAgICAgICBM
SUJYTF9USU1FUl9NT0RFX05PX0RFTEFZX0ZPUl9NSVNTRURfVElDS1M7CmRpZmYgLXIgYzFjNTQ5
YzRmZTllIHRvb2xzL2xpYnhsL2xpYnhsX2RtLmMKLS0tIGEvdG9vbHMvbGlieGwvbGlieGxfZG0u
YwlNb24gT2N0IDE1IDE2OjUxOjQ0IDIwMTIgKzAxMDAKKysrIGIvdG9vbHMvbGlieGwvbGlieGxf
ZG0uYwlXZWQgT2N0IDI0IDE1OjM5OjQzIDIwMTIgKzA4MDAKQEAgLTE4MSw2ICsxODEsOCBAQCBz
dGF0aWMgY2hhciAqKiBsaWJ4bF9fYnVpbGRfZGV2aWNlX21vZGVsCiAgICAgICAgICAgICBicmVh
azsKICAgICAgICAgY2FzZSBMSUJYTF9WR0FfSU5URVJGQUNFX1RZUEVfQ0lSUlVTOgogICAgICAg
ICAgICAgYnJlYWs7CisgICAgICAgIGNhc2UgTElCWExfVkdBX0lOVEVSRkFDRV9UWVBFX1FYTDoK
KyAgICAgICAgICAgICBicmVhazsKICAgICAgICAgfQogCiAgICAgICAgIGlmIChiX2luZm8tPnUu
aHZtLmJvb3QpIHsKQEAgLTQzMCw2ICs0MzIsOSBAQCBzdGF0aWMgY2hhciAqKiBsaWJ4bF9fYnVp
bGRfZGV2aWNlX21vZGVsCiAgICAgICAgICAgICBicmVhazsKICAgICAgICAgY2FzZSBMSUJYTF9W
R0FfSU5URVJGQUNFX1RZUEVfQ0lSUlVTOgogICAgICAgICAgICAgZmxleGFycmF5X3ZhcHBlbmQo
ZG1fYXJncywgIi12Z2EiLCAiY2lycnVzIiwgTlVMTCk7CisgICAgICAgICAgICBicmVhazsKKyAg
ICAgICAgY2FzZSBMSUJYTF9WR0FfSU5URVJGQUNFX1RZUEVfUVhMOgorICAgICAgICAgICAgZmxl
eGFycmF5X3ZhcHBlbmQoZG1fYXJncywgIi12Z2EiLCAicXhsIiwgTlVMTCk7CiAgICAgICAgICAg
ICBicmVhazsKICAgICAgICAgfQogCmRpZmYgLXIgYzFjNTQ5YzRmZTllIHRvb2xzL2xpYnhsL2xp
YnhsX3R5cGVzLmlkbAotLS0gYS90b29scy9saWJ4bC9saWJ4bF90eXBlcy5pZGwJTW9uIE9jdCAx
NSAxNjo1MTo0NCAyMDEyICswMTAwCisrKyBiL3Rvb2xzL2xpYnhsL2xpYnhsX3R5cGVzLmlkbAlX
ZWQgT2N0IDI0IDE1OjM5OjQzIDIwMTIgKzA4MDAKQEAgLTEzMCw2ICsxMzAsNyBAQCBsaWJ4bF92
Z2FfaW50ZXJmYWNlX3R5cGUgPSBFbnVtZXJhdGlvbigiCiBsaWJ4bF92Z2FfaW50ZXJmYWNlX3R5
cGUgPSBFbnVtZXJhdGlvbigidmdhX2ludGVyZmFjZV90eXBlIiwgWwogICAgICgxLCAiQ0lSUlVT
IiksCiAgICAgKDIsICJTVEQiKSwKKyAgICAoMywgIlFYTCIpLAogICAgIF0sIGluaXRfdmFsID0g
MCkKIAogIwpkaWZmIC1yIGMxYzU0OWM0ZmU5ZSB0b29scy9saWJ4bC94bF9jbWRpbXBsLmMKLS0t
IGEvdG9vbHMvbGlieGwveGxfY21kaW1wbC5jCU1vbiBPY3QgMTUgMTY6NTE6NDQgMjAxMiArMDEw
MAorKysgYi90b29scy9saWJ4bC94bF9jbWRpbXBsLmMJV2VkIE9jdCAyNCAxNTozOTo0MyAyMDEy
ICswODAwCkBAIC0xNDAyLDYgKzE0MDIsMTQgQEAgc2tpcF92ZmI6CiAgICAgICAgICAgICBiX2lu
Zm8tPnUuaHZtLnZnYS5raW5kID0gbCA/IExJQlhMX1ZHQV9JTlRFUkZBQ0VfVFlQRV9TVEQgOgog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBMSUJYTF9WR0FfSU5URVJG
QUNFX1RZUEVfQ0lSUlVTOwogCisgICAgICAgIGlmICgheGx1X2NmZ19nZXRfbG9uZyhjb25maWcs
ICJxeGwiLCAmbCwgMCkpIHsKKyAgICAgICAgICAgIGlmIChsKSB7CisgICAgICAgICAgICAgICAg
Yl9pbmZvLT51Lmh2bS52Z2Eua2luZCA9IExJQlhMX1ZHQV9JTlRFUkZBQ0VfVFlQRV9RWEw7Cisg
ICAgICAgICAgICB9IGVsc2UgaWYgKCFiX2luZm8tPnUuaHZtLnZnYS5raW5kKSB7CisgICAgICAg
ICAgICAgICAgYl9pbmZvLT51Lmh2bS52Z2Eua2luZCA9IExJQlhMX1ZHQV9JTlRFUkZBQ0VfVFlQ
RV9DSVJSVVM7CisgICAgICAgICAgICB9CisgICAgICAgIH0KKwogICAgICAgICB4bHVfY2ZnX2dl
dF9kZWZib29sKGNvbmZpZywgInZuYyIsICZiX2luZm8tPnUuaHZtLnZuYy5lbmFibGUsIDApOwog
ICAgICAgICB4bHVfY2ZnX3JlcGxhY2Vfc3RyaW5nIChjb25maWcsICJ2bmNsaXN0ZW4iLAogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmYl9pbmZvLT51Lmh2bS52bmMubGlzdGVuLCAw
KTsK
--bcaec545479a822f7204ccc991cc
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--bcaec545479a822f7204ccc991cc--


From xen-devel-bounces@lists.xen.org Wed Oct 24 08:07:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 08:07:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQvzR-0005VA-Qf; Wed, 24 Oct 2012 08:07:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQvzP-0005V5-KC
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 08:07:00 +0000
Received: from [85.158.138.51:18953] by server-6.bemta-3.messagelabs.com id
	8F/C0-32375-2A1A7805; Wed, 24 Oct 2012 08:06:58 +0000
X-Env-Sender: zpengxen@gmail.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1351066008!35472809!1
X-Originating-IP: [209.85.223.171]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2663 invoked from network); 24 Oct 2012 08:06:50 -0000
Received: from mail-ie0-f171.google.com (HELO mail-ie0-f171.google.com)
	(209.85.223.171)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 08:06:50 -0000
Received: by mail-ie0-f171.google.com with SMTP id s9so352603iec.30
	for ;
	Wed, 24 Oct 2012 01:06:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=teDWIXVFoxfsZHbpAgtr44zHNhQ1QTGUYieIJrgwHTA=;
	b=H4lbE0JaBx2von8RULyvdr189Z/WUi09qR96xUN7DfbykpL1J3TtFatSO2MZXhWBs7
	oJoUorCdwxzzvslcD6JVnYzCXjtfM3TB6FhfPKUWm0UkQRNsUWa+yo4jtBn4SM9PTfMB
	BQ69+osl9WnRToM2hHuh1rm5AYvR87J2zt6pu0DQAxxk3cXXdvBmGwnrl33IaSDx9elN
	Cl8fh8OR4Ihks/0x144hj6zFVz7m41Egwm/t5ZvNPFrhBcctW4wutT9ERBUpQEj3TruS
	QfZaOUYk26pELfIT0AG55Up+u9vRT8xO1cBNWAsg6YuPEh5XIZ+kdIQlsmgi1NM0YbOE
	949Q==
MIME-Version: 1.0
Received: by 10.50.236.99 with SMTP id ut3mr1551122igc.73.1351066008563; Wed,
	24 Oct 2012 01:06:48 -0700 (PDT)
Received: by 10.50.128.137 with HTTP; Wed, 24 Oct 2012 01:06:48 -0700 (PDT)
In-Reply-To: <508559E8.10102@eu.citrix.com>
References: 
	<1338987918.32319.84.camel@zakaz.uk.xensource.com>
	
	<1339049291.6557.11.camel@dagon.hellion.org.uk>
	
	<1341325462.21547.20.camel@zakaz.uk.xensource.com>
	
	
	
	<508559E8.10102@eu.citrix.com>
Date: Wed, 24 Oct 2012 16:06:48 +0800
Message-ID: 
From: ZhouPeng 
To: George Dunlap 
Content-Type: multipart/mixed; boundary=bcaec545479a822f7204ccc991cc
Cc: "Xen-Devel \(E-mail\)" ,
	Ian Jackson ,
	Ian Campbell ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 2/3] tools:libxl: Add qxl vga interface
 support v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--bcaec545479a822f7204ccc991cc
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Oct 22, 2012 at 10:36 PM, George Dunlap
 wrote:
> On 18/10/12 11:19, ZhouPeng wrote:
>>
>> v4
>>
>> test and fix conflict with the latest Xen
>> -----
>>
>>
>> tools:libxl: Add qxl vga interface support for upstream-qemu-xen.
>>
>> Usage:
>>    qxl=1|0
>>
>> Signed-off-by: Zhou Peng 
>
>
> Thanks, Zhou Peng.  Just a couple of comments below:
>
>
>>
>> diff -r c1c549c4fe9e docs/man/xl.cfg.pod.5
>> --- a/docs/man/xl.cfg.pod.5     Mon Oct 15 16:51:44 2012 +0100
>> +++ b/docs/man/xl.cfg.pod.5     Thu Oct 18 17:53:25 2012 +0800
>> @@ -930,10 +930,13 @@ in the B for configurin
>>
>>   Sets the amount of RAM which the emulated video card will contain,
>>   which in turn limits the resolutions and bit depths which will be
>> -available. This option is only available when using the B
>> -option (see below).
>> +available. This option is only available when using the B and
>> +B option (see below).
>>   The default amount of video ram for stdvga is 8MB which is sufficient
>>   for e.g. 1600x1200 at 32bpp.
>> +For B option, the default is 128MB. If B is set greater
>> +than 128MB, it will be trimmed to 128MB; if set less than 128MB, an
>> +error will be triggered.
>
>
> Is this a fixed value in qemu, or is this something that can be changed via
> the command-line?
Can be changed.

But Ian Campbell and me have talked on sth related with this
closely before. And we both agree to just support the default is
enough in most time. You can get it from the url below quickly, pls
read from bottom up, which can save time.

http://lists.xen.org/archives/html/xen-devel/2012-07/msg00098.html

Thanks,
-Zhou Peng
>
>
>> +
>> +        if (b_info->device_model_version ==
>> LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN
>> +            && b_info->u.hvm.vga.kind == LIBXL_VGA_INTERFACE_TYPE_QXL) {
>> +            /*
>> +             * QXL needs 128 Mib video ram by default.
>> +             */
>> +            if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT) {
>> +                b_info->video_memkb = 128 * 1024;
>> +            }
>> +            if (b_info->video_memkb < 128 * 1024) {
>> +                LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
>> +                    "128 Mib videoram is necessary for qxl default");
>> +                return ERROR_INVAL;
>> +            }
>> +            if (b_info->video_memkb > 128 * 1024) {
>> +                b_info->video_memkb = 128 * 1024;
>> +                LIBXL__LOG(CTX, LIBXL__LOG_WARNING,
>> +                            "trim videoram to qxl default: 128 Mib");
>> +            }
>> +        }
>
>
> It would be better to have a single #define for the required QXL video mem
> size, rather than duplicating "128*1024" several times.
>
> Other than that, looks pretty good to me.

Fixed in v5
> Thanks,
>  -George
>

Patch v5 is appended and attached below .
------------------

tools:libxl: Add qxl vga interface support for upstream-qemu-xen.

Usage:
  qxl=1|0

Signed-off-by: Zhou Peng 

diff -r c1c549c4fe9e docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5	Mon Oct 15 16:51:44 2012 +0100
+++ b/docs/man/xl.cfg.pod.5	Wed Oct 24 15:39:43 2012 +0800
@@ -930,10 +930,13 @@ in the B for configurin

 Sets the amount of RAM which the emulated video card will contain,
 which in turn limits the resolutions and bit depths which will be
-available. This option is only available when using the B
-option (see below).
+available. This option is only available when using the B and
+B option (see below).
 The default amount of video ram for stdvga is 8MB which is sufficient
 for e.g. 1600x1200 at 32bpp.
+For B option, the default is 128MB. If B is set greater
+than 128MB, it will be trimmed to 128MB; if set less than 128MB, an
+error will be triggered.

 When using the emulated Cirrus graphics card (B)
 the amount of video ram is fixed at 4MB which is sufficient
@@ -951,6 +954,14 @@ a Cirrus Logic GD5446 VGA card. If your
 a Cirrus Logic GD5446 VGA card. If your guest supports VBE 2.0 or
 later (e.g. Windows XP onwards) then you should enable this.
 stdvga supports more video ram and bigger resolutions than Cirrus.
+
+=item B
+
+Select a QXL VGA card as the emulated graphics device.
+In general, QXL should work with the Spice remote display protocol
+for acceleration, and QXL driver is necessary in guest in this case.
+QXL can also work with the VNC protocol, but it will be like a standard
+VGA without acceleration.

 =item B

diff -r c1c549c4fe9e tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Oct 15 16:51:44 2012 +0100
+++ b/tools/libxl/libxl_create.c	Wed Oct 24 15:39:43 2012 +0800
@@ -232,8 +232,31 @@ int libxl__domain_build_info_setdefault(
     case LIBXL_DOMAIN_TYPE_HVM:
         if (b_info->shadow_memkb == LIBXL_MEMKB_DEFAULT)
             b_info->shadow_memkb = 0;
+
+        if (b_info->device_model_version == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN
+            && b_info->u.hvm.vga.kind == LIBXL_VGA_INTERFACE_TYPE_QXL) {
+            /*
+             * QXL needs 128 Mib video ram by default.
+             */
+#define QXL_VIDEO_RAM_DEFAULT (128 * 1024)
+            if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT) {
+                b_info->video_memkb = QXL_VIDEO_RAM_DEFAULT;
+            }
+            if (b_info->video_memkb < QXL_VIDEO_RAM_DEFAULT) {
+                LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
+                    "128 Mib videoram is necessary for qxl default");
+                return ERROR_INVAL;
+            }
+            if (b_info->video_memkb > QXL_VIDEO_RAM_DEFAULT) {
+                b_info->video_memkb = QXL_VIDEO_RAM_DEFAULT;
+                LIBXL__LOG(CTX, LIBXL__LOG_WARNING,
+                            "trim videoram to qxl default: 128 Mib");
+            }
+#undef QXL_VIDEO_RAM_DEFAULT
+        }
         if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT)
             b_info->video_memkb = 8 * 1024;
+
         if (b_info->u.hvm.timer_mode == LIBXL_TIMER_MODE_DEFAULT)
             b_info->u.hvm.timer_mode =
                 LIBXL_TIMER_MODE_NO_DELAY_FOR_MISSED_TICKS;
diff -r c1c549c4fe9e tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Oct 15 16:51:44 2012 +0100
+++ b/tools/libxl/libxl_dm.c	Wed Oct 24 15:39:43 2012 +0800
@@ -181,6 +181,8 @@ static char ** libxl__build_device_model
             break;
         case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
             break;
+        case LIBXL_VGA_INTERFACE_TYPE_QXL:
+             break;
         }

         if (b_info->u.hvm.boot) {
@@ -430,6 +432,9 @@ static char ** libxl__build_device_model
             break;
         case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
             flexarray_vappend(dm_args, "-vga", "cirrus", NULL);
+            break;
+        case LIBXL_VGA_INTERFACE_TYPE_QXL:
+            flexarray_vappend(dm_args, "-vga", "qxl", NULL);
             break;
         }

diff -r c1c549c4fe9e tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Oct 15 16:51:44 2012 +0100
+++ b/tools/libxl/libxl_types.idl	Wed Oct 24 15:39:43 2012 +0800
@@ -130,6 +130,7 @@ libxl_vga_interface_type = Enumeration("
 libxl_vga_interface_type = Enumeration("vga_interface_type", [
     (1, "CIRRUS"),
     (2, "STD"),
+    (3, "QXL"),
     ], init_val = 0)

 #
diff -r c1c549c4fe9e tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Oct 15 16:51:44 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Wed Oct 24 15:39:43 2012 +0800
@@ -1402,6 +1402,14 @@ skip_vfb:
             b_info->u.hvm.vga.kind = l ? LIBXL_VGA_INTERFACE_TYPE_STD :
                                          LIBXL_VGA_INTERFACE_TYPE_CIRRUS;

+        if (!xlu_cfg_get_long(config, "qxl", &l, 0)) {
+            if (l) {
+                b_info->u.hvm.vga.kind = LIBXL_VGA_INTERFACE_TYPE_QXL;
+            } else if (!b_info->u.hvm.vga.kind) {
+                b_info->u.hvm.vga.kind = LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
+            }
+        }
+
         xlu_cfg_get_defbool(config, "vnc", &b_info->u.hvm.vnc.enable, 0);
         xlu_cfg_replace_string (config, "vnclisten",
                                 &b_info->u.hvm.vnc.listen, 0);


--
Zhou Peng

--bcaec545479a822f7204ccc991cc
Content-Type: application/octet-stream; 
	name="spice.tools.libxl.qxl.support+docs.v5.diff"
Content-Disposition: attachment; 
	filename="spice.tools.libxl.qxl.support+docs.v5.diff"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h8o5sips0

dG9vbHM6bGlieGw6IEFkZCBxeGwgdmdhIGludGVyZmFjZSBzdXBwb3J0IGZvciB1cHN0cmVhbS1x
ZW11LXhlbi4KClVzYWdlOgogIHF4bD0xfDAKClNpZ25lZC1vZmYtYnk6IFpob3UgUGVuZyA8YWls
dnBlbmcyNUBnbWFpbC5jb20+CgpkaWZmIC1yIGMxYzU0OWM0ZmU5ZSBkb2NzL21hbi94bC5jZmcu
cG9kLjUKLS0tIGEvZG9jcy9tYW4veGwuY2ZnLnBvZC41CU1vbiBPY3QgMTUgMTY6NTE6NDQgMjAx
MiArMDEwMAorKysgYi9kb2NzL21hbi94bC5jZmcucG9kLjUJV2VkIE9jdCAyNCAxNTozOTo0MyAy
MDEyICswODAwCkBAIC05MzAsMTAgKzkzMCwxMyBAQCBpbiB0aGUgQjxWRkJfU1BFQ19TVFJJTkc+
IGZvciBjb25maWd1cmluCiAKIFNldHMgdGhlIGFtb3VudCBvZiBSQU0gd2hpY2ggdGhlIGVtdWxh
dGVkIHZpZGVvIGNhcmQgd2lsbCBjb250YWluLAogd2hpY2ggaW4gdHVybiBsaW1pdHMgdGhlIHJl
c29sdXRpb25zIGFuZCBiaXQgZGVwdGhzIHdoaWNoIHdpbGwgYmUKLWF2YWlsYWJsZS4gVGhpcyBv
cHRpb24gaXMgb25seSBhdmFpbGFibGUgd2hlbiB1c2luZyB0aGUgQjxzdGR2Z2E+Ci1vcHRpb24g
KHNlZSBiZWxvdykuCithdmFpbGFibGUuIFRoaXMgb3B0aW9uIGlzIG9ubHkgYXZhaWxhYmxlIHdo
ZW4gdXNpbmcgdGhlIEI8c3RkdmdhPiBhbmQKK0I8cXhsPiBvcHRpb24gKHNlZSBiZWxvdykuCiBU
aGUgZGVmYXVsdCBhbW91bnQgb2YgdmlkZW8gcmFtIGZvciBzdGR2Z2EgaXMgOE1CIHdoaWNoIGlz
IHN1ZmZpY2llbnQKIGZvciBlLmcuIDE2MDB4MTIwMCBhdCAzMmJwcC4KK0ZvciBCPHF4bD4gb3B0
aW9uLCB0aGUgZGVmYXVsdCBpcyAxMjhNQi4gSWYgQjx2aWRlb3JhbT4gaXMgc2V0IGdyZWF0ZXIK
K3RoYW4gMTI4TUIsIGl0IHdpbGwgYmUgdHJpbW1lZCB0byAxMjhNQjsgaWYgc2V0IGxlc3MgdGhh
biAxMjhNQiwgYW4KK2Vycm9yIHdpbGwgYmUgdHJpZ2dlcmVkLgogCiBXaGVuIHVzaW5nIHRoZSBl
bXVsYXRlZCBDaXJydXMgZ3JhcGhpY3MgY2FyZCAoQjxzdGR2Z2E9MD4pCiB0aGUgYW1vdW50IG9m
IHZpZGVvIHJhbSBpcyBmaXhlZCBhdCA0TUIgd2hpY2ggaXMgc3VmZmljaWVudApAQCAtOTUxLDYg
Kzk1NCwxNCBAQCBhIENpcnJ1cyBMb2dpYyBHRDU0NDYgVkdBIGNhcmQuIElmIHlvdXIgCiBhIENp
cnJ1cyBMb2dpYyBHRDU0NDYgVkdBIGNhcmQuIElmIHlvdXIgZ3Vlc3Qgc3VwcG9ydHMgVkJFIDIu
MCBvcgogbGF0ZXIgKGUuZy4gV2luZG93cyBYUCBvbndhcmRzKSB0aGVuIHlvdSBzaG91bGQgZW5h
YmxlIHRoaXMuCiBzdGR2Z2Egc3VwcG9ydHMgbW9yZSB2aWRlbyByYW0gYW5kIGJpZ2dlciByZXNv
bHV0aW9ucyB0aGFuIENpcnJ1cy4KKworPWl0ZW0gQjxxeGw9Qk9PTEVBTj4KKworU2VsZWN0IGEg
UVhMIFZHQSBjYXJkIGFzIHRoZSBlbXVsYXRlZCBncmFwaGljcyBkZXZpY2UuCitJbiBnZW5lcmFs
LCBRWEwgc2hvdWxkIHdvcmsgd2l0aCB0aGUgU3BpY2UgcmVtb3RlIGRpc3BsYXkgcHJvdG9jb2wK
K2ZvciBhY2NlbGVyYXRpb24sIGFuZCBRWEwgZHJpdmVyIGlzIG5lY2Vzc2FyeSBpbiBndWVzdCBp
biB0aGlzIGNhc2UuCitRWEwgY2FuIGFsc28gd29yayB3aXRoIHRoZSBWTkMgcHJvdG9jb2wsIGJ1
dCBpdCB3aWxsIGJlIGxpa2UgYSBzdGFuZGFyZAorVkdBIHdpdGhvdXQgYWNjZWxlcmF0aW9uLgog
CiA9aXRlbSBCPHZuYz1CT09MRUFOPgogCmRpZmYgLXIgYzFjNTQ5YzRmZTllIHRvb2xzL2xpYnhs
L2xpYnhsX2NyZWF0ZS5jCi0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsX2NyZWF0ZS5jCU1vbiBPY3Qg
MTUgMTY6NTE6NDQgMjAxMiArMDEwMAorKysgYi90b29scy9saWJ4bC9saWJ4bF9jcmVhdGUuYwlX
ZWQgT2N0IDI0IDE1OjM5OjQzIDIwMTIgKzA4MDAKQEAgLTIzMiw4ICsyMzIsMzEgQEAgaW50IGxp
YnhsX19kb21haW5fYnVpbGRfaW5mb19zZXRkZWZhdWx0KAogICAgIGNhc2UgTElCWExfRE9NQUlO
X1RZUEVfSFZNOgogICAgICAgICBpZiAoYl9pbmZvLT5zaGFkb3dfbWVta2IgPT0gTElCWExfTUVN
S0JfREVGQVVMVCkKICAgICAgICAgICAgIGJfaW5mby0+c2hhZG93X21lbWtiID0gMDsKKworICAg
ICAgICBpZiAoYl9pbmZvLT5kZXZpY2VfbW9kZWxfdmVyc2lvbiA9PSBMSUJYTF9ERVZJQ0VfTU9E
RUxfVkVSU0lPTl9RRU1VX1hFTgorICAgICAgICAgICAgJiYgYl9pbmZvLT51Lmh2bS52Z2Eua2lu
ZCA9PSBMSUJYTF9WR0FfSU5URVJGQUNFX1RZUEVfUVhMKSB7CisgICAgICAgICAgICAvKgorICAg
ICAgICAgICAgICogUVhMIG5lZWRzIDEyOCBNaWIgdmlkZW8gcmFtIGJ5IGRlZmF1bHQuCisgICAg
ICAgICAgICAgKi8KKyNkZWZpbmUgUVhMX1ZJREVPX1JBTV9ERUZBVUxUICgxMjggKiAxMDI0KQor
ICAgICAgICAgICAgaWYgKGJfaW5mby0+dmlkZW9fbWVta2IgPT0gTElCWExfTUVNS0JfREVGQVVM
VCkgeworICAgICAgICAgICAgICAgIGJfaW5mby0+dmlkZW9fbWVta2IgPSBRWExfVklERU9fUkFN
X0RFRkFVTFQ7CisgICAgICAgICAgICB9CisgICAgICAgICAgICBpZiAoYl9pbmZvLT52aWRlb19t
ZW1rYiA8IFFYTF9WSURFT19SQU1fREVGQVVMVCkgeworICAgICAgICAgICAgICAgIExJQlhMX19M
T0coQ1RYLCBMSUJYTF9fTE9HX0VSUk9SLAorICAgICAgICAgICAgICAgICAgICAiMTI4IE1pYiB2
aWRlb3JhbSBpcyBuZWNlc3NhcnkgZm9yIHF4bCBkZWZhdWx0Iik7CisgICAgICAgICAgICAgICAg
cmV0dXJuIEVSUk9SX0lOVkFMOworICAgICAgICAgICAgfQorICAgICAgICAgICAgaWYgKGJfaW5m
by0+dmlkZW9fbWVta2IgPiBRWExfVklERU9fUkFNX0RFRkFVTFQpIHsKKyAgICAgICAgICAgICAg
ICBiX2luZm8tPnZpZGVvX21lbWtiID0gUVhMX1ZJREVPX1JBTV9ERUZBVUxUOworICAgICAgICAg
ICAgICAgIExJQlhMX19MT0coQ1RYLCBMSUJYTF9fTE9HX1dBUk5JTkcsCisgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgInRyaW0gdmlkZW9yYW0gdG8gcXhsIGRlZmF1bHQ6IDEyOCBNaWIiKTsK
KyAgICAgICAgICAgIH0KKyN1bmRlZiBRWExfVklERU9fUkFNX0RFRkFVTFQKKyAgICAgICAgfQog
ICAgICAgICBpZiAoYl9pbmZvLT52aWRlb19tZW1rYiA9PSBMSUJYTF9NRU1LQl9ERUZBVUxUKQog
ICAgICAgICAgICAgYl9pbmZvLT52aWRlb19tZW1rYiA9IDggKiAxMDI0OworCiAgICAgICAgIGlm
IChiX2luZm8tPnUuaHZtLnRpbWVyX21vZGUgPT0gTElCWExfVElNRVJfTU9ERV9ERUZBVUxUKQog
ICAgICAgICAgICAgYl9pbmZvLT51Lmh2bS50aW1lcl9tb2RlID0KICAgICAgICAgICAgICAgICBM
SUJYTF9USU1FUl9NT0RFX05PX0RFTEFZX0ZPUl9NSVNTRURfVElDS1M7CmRpZmYgLXIgYzFjNTQ5
YzRmZTllIHRvb2xzL2xpYnhsL2xpYnhsX2RtLmMKLS0tIGEvdG9vbHMvbGlieGwvbGlieGxfZG0u
YwlNb24gT2N0IDE1IDE2OjUxOjQ0IDIwMTIgKzAxMDAKKysrIGIvdG9vbHMvbGlieGwvbGlieGxf
ZG0uYwlXZWQgT2N0IDI0IDE1OjM5OjQzIDIwMTIgKzA4MDAKQEAgLTE4MSw2ICsxODEsOCBAQCBz
dGF0aWMgY2hhciAqKiBsaWJ4bF9fYnVpbGRfZGV2aWNlX21vZGVsCiAgICAgICAgICAgICBicmVh
azsKICAgICAgICAgY2FzZSBMSUJYTF9WR0FfSU5URVJGQUNFX1RZUEVfQ0lSUlVTOgogICAgICAg
ICAgICAgYnJlYWs7CisgICAgICAgIGNhc2UgTElCWExfVkdBX0lOVEVSRkFDRV9UWVBFX1FYTDoK
KyAgICAgICAgICAgICBicmVhazsKICAgICAgICAgfQogCiAgICAgICAgIGlmIChiX2luZm8tPnUu
aHZtLmJvb3QpIHsKQEAgLTQzMCw2ICs0MzIsOSBAQCBzdGF0aWMgY2hhciAqKiBsaWJ4bF9fYnVp
bGRfZGV2aWNlX21vZGVsCiAgICAgICAgICAgICBicmVhazsKICAgICAgICAgY2FzZSBMSUJYTF9W
R0FfSU5URVJGQUNFX1RZUEVfQ0lSUlVTOgogICAgICAgICAgICAgZmxleGFycmF5X3ZhcHBlbmQo
ZG1fYXJncywgIi12Z2EiLCAiY2lycnVzIiwgTlVMTCk7CisgICAgICAgICAgICBicmVhazsKKyAg
ICAgICAgY2FzZSBMSUJYTF9WR0FfSU5URVJGQUNFX1RZUEVfUVhMOgorICAgICAgICAgICAgZmxl
eGFycmF5X3ZhcHBlbmQoZG1fYXJncywgIi12Z2EiLCAicXhsIiwgTlVMTCk7CiAgICAgICAgICAg
ICBicmVhazsKICAgICAgICAgfQogCmRpZmYgLXIgYzFjNTQ5YzRmZTllIHRvb2xzL2xpYnhsL2xp
YnhsX3R5cGVzLmlkbAotLS0gYS90b29scy9saWJ4bC9saWJ4bF90eXBlcy5pZGwJTW9uIE9jdCAx
NSAxNjo1MTo0NCAyMDEyICswMTAwCisrKyBiL3Rvb2xzL2xpYnhsL2xpYnhsX3R5cGVzLmlkbAlX
ZWQgT2N0IDI0IDE1OjM5OjQzIDIwMTIgKzA4MDAKQEAgLTEzMCw2ICsxMzAsNyBAQCBsaWJ4bF92
Z2FfaW50ZXJmYWNlX3R5cGUgPSBFbnVtZXJhdGlvbigiCiBsaWJ4bF92Z2FfaW50ZXJmYWNlX3R5
cGUgPSBFbnVtZXJhdGlvbigidmdhX2ludGVyZmFjZV90eXBlIiwgWwogICAgICgxLCAiQ0lSUlVT
IiksCiAgICAgKDIsICJTVEQiKSwKKyAgICAoMywgIlFYTCIpLAogICAgIF0sIGluaXRfdmFsID0g
MCkKIAogIwpkaWZmIC1yIGMxYzU0OWM0ZmU5ZSB0b29scy9saWJ4bC94bF9jbWRpbXBsLmMKLS0t
IGEvdG9vbHMvbGlieGwveGxfY21kaW1wbC5jCU1vbiBPY3QgMTUgMTY6NTE6NDQgMjAxMiArMDEw
MAorKysgYi90b29scy9saWJ4bC94bF9jbWRpbXBsLmMJV2VkIE9jdCAyNCAxNTozOTo0MyAyMDEy
ICswODAwCkBAIC0xNDAyLDYgKzE0MDIsMTQgQEAgc2tpcF92ZmI6CiAgICAgICAgICAgICBiX2lu
Zm8tPnUuaHZtLnZnYS5raW5kID0gbCA/IExJQlhMX1ZHQV9JTlRFUkZBQ0VfVFlQRV9TVEQgOgog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBMSUJYTF9WR0FfSU5URVJG
QUNFX1RZUEVfQ0lSUlVTOwogCisgICAgICAgIGlmICgheGx1X2NmZ19nZXRfbG9uZyhjb25maWcs
ICJxeGwiLCAmbCwgMCkpIHsKKyAgICAgICAgICAgIGlmIChsKSB7CisgICAgICAgICAgICAgICAg
Yl9pbmZvLT51Lmh2bS52Z2Eua2luZCA9IExJQlhMX1ZHQV9JTlRFUkZBQ0VfVFlQRV9RWEw7Cisg
ICAgICAgICAgICB9IGVsc2UgaWYgKCFiX2luZm8tPnUuaHZtLnZnYS5raW5kKSB7CisgICAgICAg
ICAgICAgICAgYl9pbmZvLT51Lmh2bS52Z2Eua2luZCA9IExJQlhMX1ZHQV9JTlRFUkZBQ0VfVFlQ
RV9DSVJSVVM7CisgICAgICAgICAgICB9CisgICAgICAgIH0KKwogICAgICAgICB4bHVfY2ZnX2dl
dF9kZWZib29sKGNvbmZpZywgInZuYyIsICZiX2luZm8tPnUuaHZtLnZuYy5lbmFibGUsIDApOwog
ICAgICAgICB4bHVfY2ZnX3JlcGxhY2Vfc3RyaW5nIChjb25maWcsICJ2bmNsaXN0ZW4iLAogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmYl9pbmZvLT51Lmh2bS52bmMubGlzdGVuLCAw
KTsK
--bcaec545479a822f7204ccc991cc
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--bcaec545479a822f7204ccc991cc--


From xen-devel-bounces@lists.xen.org Wed Oct 24 08:30:13 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 08:30:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQwLW-0005n0-7s; Wed, 24 Oct 2012 08:29:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQjST-0008Gd-Ge
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 18:44:09 +0000
Received: from [85.158.137.99:35895] by server-4.bemta-3.messagelabs.com id
	D7/FE-01405-875E6805; Tue, 23 Oct 2012 18:44:08 +0000
X-Env-Sender: slawek.k_xl@wp.pl
X-Msg-Ref: server-16.tower-217.messagelabs.com!1351017846!22740257!1
X-Originating-IP: [212.77.101.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuNzcuMTAxLjcgPT4gOTAzOTM=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuNzcuMTAxLjcgPT4gOTAzOTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25226 invoked from network); 23 Oct 2012 18:44:07 -0000
Received: from mx3.wp.pl (HELO mx3.wp.pl) (212.77.101.7)
	by server-16.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Oct 2012 18:44:07 -0000
Received: (wp-smtpd smtp.wp.pl 20603 invoked from network);
	23 Oct 2012 20:44:04 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wp.pl; s=1024a;
	t=1351017844; bh=LGqRJxo4Y98YUHoyNo6Ydiww9GfFO2ATFiVljvoDYXk=;
	h=From:To:Subject;
	b=l/Qj0Fc4T5qoFfdeVxtUdzrDkVa3scJ3CMq0AvOrZwXZp0Ipuu2//yPEkjmNL70Ba
	uIjyjTIz+VTUVV9RM4gBzfv+DbtKSSCUK+f6qw2AWfSN4qnh8hdnEaXL6DpW4Bzmrd
	OUGEyr87717jJbOwULnAvzyjGsUwm5S6TwNzbxiw=
Received: from out.poczta.wp.pl (HELO localhost) ([212.77.101.240])
	(envelope-sender )
	by smtp.wp.pl (WP-SMTPD) with SMTP
	for ; 23 Oct 2012 20:44:04 +0200
Date: Tue, 23 Oct 2012 20:44:04 +0200
From: =?ISO-8859-2?Q?S=B3awek_Kosowski?= 
To: xen-devel@lists.xen.org
Message-ID: <5086e5740096e2.94910907@wp.pl>
MIME-Version: 1.0
Content-Disposition: inline
X-Mailer: Interfejs WWW nowej poczty Wirtualnej Polski
X-User-Agent: Mozilla/5.0 (Windows NT 6.1;
	WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.94
	Safari/537.4
Organization: Poznaj Poczte WP http://poczta.wp.pl/info-start.html
X-WP-IP: 92.105.5.90
X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A.
X-WP-SPAM: NO 0000000 [gbMU]                               
X-Mailman-Approved-At: Wed, 24 Oct 2012 08:29:49 +0000
Subject: [Xen-devel] Kernel paging request error
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Reposting from xen-users (no response)
I'm having a problem with: http://pastebin.com/CuGHqwhy
It occurs on the reboot, but sometimes, when I try to start manually one of
my machines. Sometime, one of the machines does not want to start
permanently and I have to reinstall/restore it.
This problem comes for me randomly, but maybe there is a trigger. 
I've tried to follow:
http://xen.1045712.n5.nabble.com/2-6-32-27-dom0-BUG-unable-to-handle-kernel-paging-request-td3323011.html
and raise /proc/sys/vm/min_free_kbytes, but it did not help.

System info:
Debian, Linux dom0 3.2.0-0.bpo.3-amd64
i libxenstore3.0 4.0.1-5.4 
Xenstore communications library for Xen
ii xen-hypervisor-4.0-amd64 4.0.1-5.4 The
Xen Hypervisor on AMD64
ii xen-linux-system-3.2.0-0.bpo.3-amd64 3.2.23-1~bpo60+2 Xen
system with Linux 3.2 on 64-bit PCs (meta-package)
ii xen-linux-system-amd64 3.2+45~bpo60+1 Xen
system with Linux for 64-bit PCs (meta-package)
ii xen-tools 4.2-1 Tools
to manage Xen virtual servers
ii xen-utils-4.0 4.0.1-5.4 XEN
administrative tools
ii xen-utils-common 4.0.0-1 XEN
administrative tools - common files
ii xenstore-utils 4.0.1-5.4 
Xenstore utilities for Xen
ii xenwatch 0.5.4-2 
Virtualization utilities, mostly for Xen


Any advices how to solve ?
Can it be a hardware problem with RAM ?

Regards
Slawek



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 08:30:13 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 08:30:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQwLW-0005n0-7s; Wed, 24 Oct 2012 08:29:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQjST-0008Gd-Ge
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 18:44:09 +0000
Received: from [85.158.137.99:35895] by server-4.bemta-3.messagelabs.com id
	D7/FE-01405-875E6805; Tue, 23 Oct 2012 18:44:08 +0000
X-Env-Sender: slawek.k_xl@wp.pl
X-Msg-Ref: server-16.tower-217.messagelabs.com!1351017846!22740257!1
X-Originating-IP: [212.77.101.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuNzcuMTAxLjcgPT4gOTAzOTM=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuNzcuMTAxLjcgPT4gOTAzOTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25226 invoked from network); 23 Oct 2012 18:44:07 -0000
Received: from mx3.wp.pl (HELO mx3.wp.pl) (212.77.101.7)
	by server-16.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Oct 2012 18:44:07 -0000
Received: (wp-smtpd smtp.wp.pl 20603 invoked from network);
	23 Oct 2012 20:44:04 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wp.pl; s=1024a;
	t=1351017844; bh=LGqRJxo4Y98YUHoyNo6Ydiww9GfFO2ATFiVljvoDYXk=;
	h=From:To:Subject;
	b=l/Qj0Fc4T5qoFfdeVxtUdzrDkVa3scJ3CMq0AvOrZwXZp0Ipuu2//yPEkjmNL70Ba
	uIjyjTIz+VTUVV9RM4gBzfv+DbtKSSCUK+f6qw2AWfSN4qnh8hdnEaXL6DpW4Bzmrd
	OUGEyr87717jJbOwULnAvzyjGsUwm5S6TwNzbxiw=
Received: from out.poczta.wp.pl (HELO localhost) ([212.77.101.240])
	(envelope-sender )
	by smtp.wp.pl (WP-SMTPD) with SMTP
	for ; 23 Oct 2012 20:44:04 +0200
Date: Tue, 23 Oct 2012 20:44:04 +0200
From: =?ISO-8859-2?Q?S=B3awek_Kosowski?= 
To: xen-devel@lists.xen.org
Message-ID: <5086e5740096e2.94910907@wp.pl>
MIME-Version: 1.0
Content-Disposition: inline
X-Mailer: Interfejs WWW nowej poczty Wirtualnej Polski
X-User-Agent: Mozilla/5.0 (Windows NT 6.1;
	WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.94
	Safari/537.4
Organization: Poznaj Poczte WP http://poczta.wp.pl/info-start.html
X-WP-IP: 92.105.5.90
X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A.
X-WP-SPAM: NO 0000000 [gbMU]                               
X-Mailman-Approved-At: Wed, 24 Oct 2012 08:29:49 +0000
Subject: [Xen-devel] Kernel paging request error
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Reposting from xen-users (no response)
I'm having a problem with: http://pastebin.com/CuGHqwhy
It occurs on the reboot, but sometimes, when I try to start manually one of
my machines. Sometime, one of the machines does not want to start
permanently and I have to reinstall/restore it.
This problem comes for me randomly, but maybe there is a trigger. 
I've tried to follow:
http://xen.1045712.n5.nabble.com/2-6-32-27-dom0-BUG-unable-to-handle-kernel-paging-request-td3323011.html
and raise /proc/sys/vm/min_free_kbytes, but it did not help.

System info:
Debian, Linux dom0 3.2.0-0.bpo.3-amd64
i libxenstore3.0 4.0.1-5.4 
Xenstore communications library for Xen
ii xen-hypervisor-4.0-amd64 4.0.1-5.4 The
Xen Hypervisor on AMD64
ii xen-linux-system-3.2.0-0.bpo.3-amd64 3.2.23-1~bpo60+2 Xen
system with Linux 3.2 on 64-bit PCs (meta-package)
ii xen-linux-system-amd64 3.2+45~bpo60+1 Xen
system with Linux for 64-bit PCs (meta-package)
ii xen-tools 4.2-1 Tools
to manage Xen virtual servers
ii xen-utils-4.0 4.0.1-5.4 XEN
administrative tools
ii xen-utils-common 4.0.0-1 XEN
administrative tools - common files
ii xenstore-utils 4.0.1-5.4 
Xenstore utilities for Xen
ii xenwatch 0.5.4-2 
Virtualization utilities, mostly for Xen


Any advices how to solve ?
Can it be a hardware problem with RAM ?

Regards
Slawek



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 08:30:13 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 08:30:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQwLW-0005n7-JU; Wed, 24 Oct 2012 08:29:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQnCA-0001z5-R4
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 22:43:35 +0000
Received: from [85.158.143.35:58147] by server-1.bemta-4.messagelabs.com id
	F3/90-19134-59D17805; Tue, 23 Oct 2012 22:43:33 +0000
X-Env-Sender: zhxwhu@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1351032211!6151594!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19016 invoked from network); 23 Oct 2012 22:43:32 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 22:43:32 -0000
Received: by mail-ie0-f173.google.com with SMTP id 17so7638305iea.32
	for ; Tue, 23 Oct 2012 15:43:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:subject
	:content-type:content-transfer-encoding;
	bh=e6Bvt7z50+lMO2bkb0z/jAwFg8r0l+dfSn2crFskrK8=;
	b=plRNAthepZ+W7NTcY18LnmA7bCj796oBp9iOEUlcGkGE1qZAUz5iGIBIJRL3Z8Imti
	VzdXLAstICiA910m7oSC1Jn7rO3ndTPHIfMg9mGiQVIxZYGUivH+Ud3AjId9UQMn4Uc3
	j5ikDuKBo3AJ7MIfN06gou8fnTd75nYXaOafK42x3ZB7c9KSL5cskaSY9DEyfj4tiBex
	2+3i/26fQO6lrNQ4ug3+Senpiy0Fg8Xuns+VCFHSIzQWP8+0fgIthPybUDIWgw07+OfX
	7C9hY6Ddd6xsF4WhA7zITAhzk1/xKbYNWBx/lW426GNDltNnsqp96alof2N8ETWV0amv
	JLQg==
Received: by 10.43.106.69 with SMTP id dt5mr12340930icc.49.1351032210901;
	Tue, 23 Oct 2012 15:43:30 -0700 (PDT)
Received: from [131.193.36.91] (dhcp21.rites.uic.edu. [131.193.36.91])
	by mx.google.com with ESMTPS id wh5sm479219igb.17.2012.10.23.15.43.29
	(version=SSLv3 cipher=OTHER); Tue, 23 Oct 2012 15:43:30 -0700 (PDT)
Message-ID: <50871D90.50606@gmail.com>
Date: Tue, 23 Oct 2012 17:43:28 -0500
From: Xu Zhang 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120911 Thunderbird/15.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" 
X-Mailman-Approved-At: Wed, 24 Oct 2012 08:29:49 +0000
Subject: [Xen-devel] Nested events in 64bit mini-OS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dear all,

I don't understand why 64-bit mini-OS doesn't check against nested Xen 
events (in entry.S). In 32-bit code, a critical section is defined and 
re-entrant is checked. A fix-up routine is executed to coalesce the 
stack frames if that's the case, because there is a window for nested 
events to happen after re-enabling event delivery and before a direct iret.

In 64-bit mini-OS, however, a critical section is defined but not used. 
My understanding is that ideally, one could
a) unmask event and do an direct iret, but check against nested events, 
try to fix stack frames if that happens; or
b) do not re-enable event and use hypercall iret to return (no need to 
fix-up stack frames).

64-bit mini-OS seems to adopt a mixed use of both (in HYPERVISOR_IRET). 
mini-OS doesn't have an userspace, so unless an NMI happened, it always 
perform interrupt/exception return with machine instruction iret, 
without checking against nested events. This is wrong to me. Am I 
missing something here?

Please advise.

Thank you,
Xu

-- 
xu

:q!


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 08:30:13 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 08:30:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQwLW-0005n7-JU; Wed, 24 Oct 2012 08:29:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQnCA-0001z5-R4
	for xen-devel@lists.xen.org; Tue, 23 Oct 2012 22:43:35 +0000
Received: from [85.158.143.35:58147] by server-1.bemta-4.messagelabs.com id
	F3/90-19134-59D17805; Tue, 23 Oct 2012 22:43:33 +0000
X-Env-Sender: zhxwhu@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1351032211!6151594!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19016 invoked from network); 23 Oct 2012 22:43:32 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Oct 2012 22:43:32 -0000
Received: by mail-ie0-f173.google.com with SMTP id 17so7638305iea.32
	for ; Tue, 23 Oct 2012 15:43:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:subject
	:content-type:content-transfer-encoding;
	bh=e6Bvt7z50+lMO2bkb0z/jAwFg8r0l+dfSn2crFskrK8=;
	b=plRNAthepZ+W7NTcY18LnmA7bCj796oBp9iOEUlcGkGE1qZAUz5iGIBIJRL3Z8Imti
	VzdXLAstICiA910m7oSC1Jn7rO3ndTPHIfMg9mGiQVIxZYGUivH+Ud3AjId9UQMn4Uc3
	j5ikDuKBo3AJ7MIfN06gou8fnTd75nYXaOafK42x3ZB7c9KSL5cskaSY9DEyfj4tiBex
	2+3i/26fQO6lrNQ4ug3+Senpiy0Fg8Xuns+VCFHSIzQWP8+0fgIthPybUDIWgw07+OfX
	7C9hY6Ddd6xsF4WhA7zITAhzk1/xKbYNWBx/lW426GNDltNnsqp96alof2N8ETWV0amv
	JLQg==
Received: by 10.43.106.69 with SMTP id dt5mr12340930icc.49.1351032210901;
	Tue, 23 Oct 2012 15:43:30 -0700 (PDT)
Received: from [131.193.36.91] (dhcp21.rites.uic.edu. [131.193.36.91])
	by mx.google.com with ESMTPS id wh5sm479219igb.17.2012.10.23.15.43.29
	(version=SSLv3 cipher=OTHER); Tue, 23 Oct 2012 15:43:30 -0700 (PDT)
Message-ID: <50871D90.50606@gmail.com>
Date: Tue, 23 Oct 2012 17:43:28 -0500
From: Xu Zhang 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120911 Thunderbird/15.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" 
X-Mailman-Approved-At: Wed, 24 Oct 2012 08:29:49 +0000
Subject: [Xen-devel] Nested events in 64bit mini-OS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dear all,

I don't understand why 64-bit mini-OS doesn't check against nested Xen 
events (in entry.S). In 32-bit code, a critical section is defined and 
re-entrant is checked. A fix-up routine is executed to coalesce the 
stack frames if that's the case, because there is a window for nested 
events to happen after re-enabling event delivery and before a direct iret.

In 64-bit mini-OS, however, a critical section is defined but not used. 
My understanding is that ideally, one could
a) unmask event and do an direct iret, but check against nested events, 
try to fix stack frames if that happens; or
b) do not re-enable event and use hypercall iret to return (no need to 
fix-up stack frames).

64-bit mini-OS seems to adopt a mixed use of both (in HYPERVISOR_IRET). 
mini-OS doesn't have an userspace, so unless an NMI happened, it always 
perform interrupt/exception return with machine instruction iret, 
without checking against nested events. This is wrong to me. Am I 
missing something here?

Please advise.

Thank you,
Xu

-- 
xu

:q!


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 08:39:51 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 08:39:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQwUq-00063I-LU; Wed, 24 Oct 2012 08:39:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQwUo-00063B-KY
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 08:39:26 +0000
Received: from [85.158.137.99:39786] by server-2.bemta-3.messagelabs.com id
	FA/01-00604-D39A7805; Wed, 24 Oct 2012 08:39:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1351067965!20438927!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12946 invoked from network); 24 Oct 2012 08:39:25 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-217.messagelabs.com with SMTP;
	24 Oct 2012 08:39:25 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 24 Oct 2012 09:39:24 +0100
Message-Id: <5087C55802000078000A3D5E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 24 Oct 2012 09:39:20 +0100
From: "Jan Beulich" 
To: "=?UTF-8?Q?S=C5=82awek=20Kosowski?=" 
References: <5086e5740096e2.94910907@wp.pl>
In-Reply-To: <5086e5740096e2.94910907@wp.pl>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Kernel paging request error
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Pj4+IE9uIDIzLjEwLjEyIGF0IDIwOjQ0LCBTxYJhd2VrIEtvc293c2tpPHNsYXdlay5rX3hsQHdw
LnBsPiB3cm90ZToKPiBSZXBvc3RpbmcgZnJvbSB4ZW4tdXNlcnMgKG5vIHJlc3BvbnNlKQo+IEkn
bSBoYXZpbmcgYSBwcm9ibGVtIHdpdGg6IGh0dHA6Ly9wYXN0ZWJpbi5jb20vQ3VHSHF3aHkgCj4g
SXQgb2NjdXJzIG9uIHRoZSByZWJvb3QsIGJ1dCBzb21ldGltZXMsIHdoZW4gSSB0cnkgdG8gc3Rh
cnQgbWFudWFsbHkgb25lIG9mCj4gbXkgbWFjaGluZXMuIFNvbWV0aW1lLCBvbmUgb2YgdGhlIG1h
Y2hpbmVzIGRvZXMgbm90IHdhbnQgdG8gc3RhcnQKPiBwZXJtYW5lbnRseSBhbmQgSSBoYXZlIHRv
IHJlaW5zdGFsbC9yZXN0b3JlIGl0Lgo+IFRoaXMgcHJvYmxlbSBjb21lcyBmb3IgbWUgcmFuZG9t
bHksIGJ1dCBtYXliZSB0aGVyZSBpcyBhIHRyaWdnZXIuIAoKUGxlYXNlIGxvb2sgZm9yIGVhcmxp
ZXIgcG9zdHMgb2Ygc2ltaWxhciBwcm9ibGVtcyAoYW5kIHRoZWlyIHJlc29sdXRpb24pCmJlZm9y
ZSBwb3N0aW5nIGhlcmUuCgo+IEkndmUgdHJpZWQgdG8gZm9sbG93Ogo+IGh0dHA6Ly94ZW4uMTA0
NTcxMi5uNS5uYWJibGUuY29tLzItNi0zMi0yNy1kb20wLUJVRy11bmFibGUtdG8taGFuZGxlLWtl
cm5lbC1wYWdpbmctcmVxdSAKPiBlc3QtdGQzMzIzMDExLmh0bWwKPiBhbmQgcmFpc2UgL3Byb2Mv
c3lzL3ZtL21pbl9mcmVlX2tieXRlcywgYnV0IGl0IGRpZCBub3QgaGVscC4KCkp1c3QgcGlja2lu
ZyBzb21lIHJhbmRvbSAidW5hYmxlIHRvIGhhbmRsZSBrZXJuZWwgcGFnaW5nIHJlcXVlc3QiCnJl
cG9ydCBkb2Vzbid0IGhlbHA7IHhzYXZlLXJlbGF0ZWQgaXNzdWVzIChjYXVzZWQgYnkgYSBib2d1
cwprZXJuZWwgc2lkZSBwYXRjaCBpbiBjZXJ0YWluIGRpc3Ryb3MpIGhhdmUgYmVlbiBkaXNjdXNz
ZWQgcXVpdGUKcmVjZW50bHkgaGVyZS4KCkphbgoKX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlz
dHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Oct 24 08:39:51 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 08:39:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQwUq-00063I-LU; Wed, 24 Oct 2012 08:39:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQwUo-00063B-KY
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 08:39:26 +0000
Received: from [85.158.137.99:39786] by server-2.bemta-3.messagelabs.com id
	FA/01-00604-D39A7805; Wed, 24 Oct 2012 08:39:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1351067965!20438927!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12946 invoked from network); 24 Oct 2012 08:39:25 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-217.messagelabs.com with SMTP;
	24 Oct 2012 08:39:25 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 24 Oct 2012 09:39:24 +0100
Message-Id: <5087C55802000078000A3D5E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 24 Oct 2012 09:39:20 +0100
From: "Jan Beulich" 
To: "=?UTF-8?Q?S=C5=82awek=20Kosowski?=" 
References: <5086e5740096e2.94910907@wp.pl>
In-Reply-To: <5086e5740096e2.94910907@wp.pl>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Kernel paging request error
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Pj4+IE9uIDIzLjEwLjEyIGF0IDIwOjQ0LCBTxYJhd2VrIEtvc293c2tpPHNsYXdlay5rX3hsQHdw
LnBsPiB3cm90ZToKPiBSZXBvc3RpbmcgZnJvbSB4ZW4tdXNlcnMgKG5vIHJlc3BvbnNlKQo+IEkn
bSBoYXZpbmcgYSBwcm9ibGVtIHdpdGg6IGh0dHA6Ly9wYXN0ZWJpbi5jb20vQ3VHSHF3aHkgCj4g
SXQgb2NjdXJzIG9uIHRoZSByZWJvb3QsIGJ1dCBzb21ldGltZXMsIHdoZW4gSSB0cnkgdG8gc3Rh
cnQgbWFudWFsbHkgb25lIG9mCj4gbXkgbWFjaGluZXMuIFNvbWV0aW1lLCBvbmUgb2YgdGhlIG1h
Y2hpbmVzIGRvZXMgbm90IHdhbnQgdG8gc3RhcnQKPiBwZXJtYW5lbnRseSBhbmQgSSBoYXZlIHRv
IHJlaW5zdGFsbC9yZXN0b3JlIGl0Lgo+IFRoaXMgcHJvYmxlbSBjb21lcyBmb3IgbWUgcmFuZG9t
bHksIGJ1dCBtYXliZSB0aGVyZSBpcyBhIHRyaWdnZXIuIAoKUGxlYXNlIGxvb2sgZm9yIGVhcmxp
ZXIgcG9zdHMgb2Ygc2ltaWxhciBwcm9ibGVtcyAoYW5kIHRoZWlyIHJlc29sdXRpb24pCmJlZm9y
ZSBwb3N0aW5nIGhlcmUuCgo+IEkndmUgdHJpZWQgdG8gZm9sbG93Ogo+IGh0dHA6Ly94ZW4uMTA0
NTcxMi5uNS5uYWJibGUuY29tLzItNi0zMi0yNy1kb20wLUJVRy11bmFibGUtdG8taGFuZGxlLWtl
cm5lbC1wYWdpbmctcmVxdSAKPiBlc3QtdGQzMzIzMDExLmh0bWwKPiBhbmQgcmFpc2UgL3Byb2Mv
c3lzL3ZtL21pbl9mcmVlX2tieXRlcywgYnV0IGl0IGRpZCBub3QgaGVscC4KCkp1c3QgcGlja2lu
ZyBzb21lIHJhbmRvbSAidW5hYmxlIHRvIGhhbmRsZSBrZXJuZWwgcGFnaW5nIHJlcXVlc3QiCnJl
cG9ydCBkb2Vzbid0IGhlbHA7IHhzYXZlLXJlbGF0ZWQgaXNzdWVzIChjYXVzZWQgYnkgYSBib2d1
cwprZXJuZWwgc2lkZSBwYXRjaCBpbiBjZXJ0YWluIGRpc3Ryb3MpIGhhdmUgYmVlbiBkaXNjdXNz
ZWQgcXVpdGUKcmVjZW50bHkgaGVyZS4KCkphbgoKX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlz
dHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Oct 24 08:46:15 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 08:46:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQwb1-0006F8-GH; Wed, 24 Oct 2012 08:45:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQwb0-0006F3-9a
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 08:45:50 +0000
Received: from [85.158.139.83:5626] by server-11.bemta-5.messagelabs.com id
	6A/41-14870-DBAA7805; Wed, 24 Oct 2012 08:45:49 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1351068347!35674781!1
X-Originating-IP: [216.32.180.188]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29758 invoked from network); 24 Oct 2012 08:45:48 -0000
Received: from co1ehsobe005.messaging.microsoft.com (HELO
	co1outboundpool.messaging.microsoft.com) (216.32.180.188)
	by server-13.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	24 Oct 2012 08:45:48 -0000
Received: from mail55-co1-R.bigfish.com (10.243.78.241) by
	CO1EHSOBE006.bigfish.com (10.243.66.69) with Microsoft SMTP Server id
	14.1.225.23; Wed, 24 Oct 2012 08:45:46 +0000
Received: from mail55-co1 (localhost [127.0.0.1])	by mail55-co1-R.bigfish.com
	(Postfix) with ESMTP id A02D1CC015F	for ;
	Wed, 24 Oct 2012 08:45:46 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202h1d1ah1d2ahzzz2dh668h839hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h)
Received: from mail55-co1 (localhost.localdomain [127.0.0.1]) by mail55-co1
	(MessageSwitch) id 1351068343776252_25672;
	Wed, 24 Oct 2012 08:45:43 +0000 (UTC)
Received: from CO1EHSMHS001.bigfish.com (unknown [10.243.78.234])	by
	mail55-co1.bigfish.com (Postfix) with ESMTP id B1AEE8A00B9	for
	; Wed, 24 Oct 2012 08:45:43 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CO1EHSMHS001.bigfish.com (10.243.66.11) with Microsoft SMTP Server id
	14.1.225.23; Wed, 24 Oct 2012 08:45:39 +0000
X-WSS-ID: 0MCE2ZX-02-0N6-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2B5BDC8050	for ; Wed, 24 Oct 2012
	03:45:33 -0500 (CDT)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 24 Oct 2012 03:45:49 -0500
Received: from STOREXDAG02.amd.com (10.1.13.11) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Wed, 24 Oct 2012 03:45:36 -0500
Received: from donner.osrc.amd.com (165.204.15.15) by storexdag02.amd.com
	(10.1.13.11) with Microsoft SMTP Server id 14.2.318.4; Wed, 24 Oct 2012
	04:45:34 -0400
Message-ID: <5087AB31.6070601@amd.com>
Date: Wed, 24 Oct 2012 10:47:45 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" 
X-OriginatorOrg: amd.com
Subject: [Xen-devel] Backport requests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Hi,

please apply the following changesets to Xen-4.2-testing:

26095:a7503ce27d46
26096:d642720e1ea9

Christoph

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 08:46:15 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 08:46:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQwb1-0006F8-GH; Wed, 24 Oct 2012 08:45:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQwb0-0006F3-9a
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 08:45:50 +0000
Received: from [85.158.139.83:5626] by server-11.bemta-5.messagelabs.com id
	6A/41-14870-DBAA7805; Wed, 24 Oct 2012 08:45:49 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1351068347!35674781!1
X-Originating-IP: [216.32.180.188]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29758 invoked from network); 24 Oct 2012 08:45:48 -0000
Received: from co1ehsobe005.messaging.microsoft.com (HELO
	co1outboundpool.messaging.microsoft.com) (216.32.180.188)
	by server-13.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	24 Oct 2012 08:45:48 -0000
Received: from mail55-co1-R.bigfish.com (10.243.78.241) by
	CO1EHSOBE006.bigfish.com (10.243.66.69) with Microsoft SMTP Server id
	14.1.225.23; Wed, 24 Oct 2012 08:45:46 +0000
Received: from mail55-co1 (localhost [127.0.0.1])	by mail55-co1-R.bigfish.com
	(Postfix) with ESMTP id A02D1CC015F	for ;
	Wed, 24 Oct 2012 08:45:46 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202h1d1ah1d2ahzzz2dh668h839hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h)
Received: from mail55-co1 (localhost.localdomain [127.0.0.1]) by mail55-co1
	(MessageSwitch) id 1351068343776252_25672;
	Wed, 24 Oct 2012 08:45:43 +0000 (UTC)
Received: from CO1EHSMHS001.bigfish.com (unknown [10.243.78.234])	by
	mail55-co1.bigfish.com (Postfix) with ESMTP id B1AEE8A00B9	for
	; Wed, 24 Oct 2012 08:45:43 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CO1EHSMHS001.bigfish.com (10.243.66.11) with Microsoft SMTP Server id
	14.1.225.23; Wed, 24 Oct 2012 08:45:39 +0000
X-WSS-ID: 0MCE2ZX-02-0N6-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2B5BDC8050	for ; Wed, 24 Oct 2012
	03:45:33 -0500 (CDT)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 24 Oct 2012 03:45:49 -0500
Received: from STOREXDAG02.amd.com (10.1.13.11) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Wed, 24 Oct 2012 03:45:36 -0500
Received: from donner.osrc.amd.com (165.204.15.15) by storexdag02.amd.com
	(10.1.13.11) with Microsoft SMTP Server id 14.2.318.4; Wed, 24 Oct 2012
	04:45:34 -0400
Message-ID: <5087AB31.6070601@amd.com>
Date: Wed, 24 Oct 2012 10:47:45 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" 
X-OriginatorOrg: amd.com
Subject: [Xen-devel] Backport requests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Hi,

please apply the following changesets to Xen-4.2-testing:

26095:a7503ce27d46
26096:d642720e1ea9

Christoph

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 08:50:20 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 08:50:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQwf0-0006Mz-5k; Wed, 24 Oct 2012 08:49:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQwey-0006Mu-An
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 08:49:56 +0000
Received: from [85.158.138.51:34861] by server-8.bemta-3.messagelabs.com id
	DB/0D-10525-3BBA7805; Wed, 24 Oct 2012 08:49:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1351068594!27574708!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUzNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32500 invoked from network); 24 Oct 2012 08:49:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 08:49:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="15351034"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 08:49:54 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 09:49:54 +0100
Message-ID: <1351068592.2237.104.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: =?UTF-8?Q?S=C5=82awek?= Kosowski 
Date: Wed, 24 Oct 2012 09:49:52 +0100
In-Reply-To: <5086e5740096e2.94910907@wp.pl>
References: <5086e5740096e2.94910907@wp.pl>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Kernel paging request error
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCAyMDEyLTEwLTIzIGF0IDE5OjQ0ICswMTAwLCBTxYJhd2VrIEtvc293c2tpIHdyb3Rl
Ogo+IFJlcG9zdGluZyBmcm9tIHhlbi11c2VycyAobm8gcmVzcG9uc2UpCj4gSSdtIGhhdmluZyBh
IHByb2JsZW0gd2l0aDogaHR0cDovL3Bhc3RlYmluLmNvbS9DdUdIcXdoeQo+IEl0IG9jY3VycyBv
biB0aGUgcmVib290LCBidXQgc29tZXRpbWVzLCB3aGVuIEkgdHJ5IHRvIHN0YXJ0IG1hbnVhbGx5
IG9uZSBvZgo+IG15IG1hY2hpbmVzLiBTb21ldGltZSwgb25lIG9mIHRoZSBtYWNoaW5lcyBkb2Vz
IG5vdCB3YW50IHRvIHN0YXJ0Cj4gcGVybWFuZW50bHkgYW5kIEkgaGF2ZSB0byByZWluc3RhbGwv
cmVzdG9yZSBpdC4KCk9uZSBleHBlcmltZW50IHRvIHRyeSwgYmFzZWQgb24gRGViaWFuIGJ1ZyAj
NjQyMTU0IHdvdWxkIGJlIHRvIHRyeQoibm94c2F2ZSIgYW5kL29yICJub3hzYXZlb3B0IiBvbiB5
b3VyIGtlcm5lbCBjb21tYW5kIGxpbmUuIFBsZWFzZSB0cnkKZWFjaCBpbmRlcGVuZGVudGx5IGFu
ZCBib3RoIHRvZ2V0aGVyLgoKSSB0aG91Z2h0IHRoaXMgc29ydCBvZiB0aGluZyB3YXMgaXJvbmVk
IG91dCBiZWZvcmUgMy4yLiBTaW5jZSB5b3UgYXJlCnJ1bm5pbmcgYSBicG8ga2VybmVsIHlvdSBj
b3VsZCBhbHNvIGNvbnNpZGVyIHJ1bm5pbmcgYSBiYWNrcG9ydCBvZiBYZW4KNC4xIGZyb20gV2hl
ZXp5IGFzIHdlbGwuCgo+IFRoaXMgcHJvYmxlbSBjb21lcyBmb3IgbWUgcmFuZG9tbHksIGJ1dCBt
YXliZSB0aGVyZSBpcyBhIHRyaWdnZXIuIAo+IEkndmUgdHJpZWQgdG8gZm9sbG93Ogo+IGh0dHA6
Ly94ZW4uMTA0NTcxMi5uNS5uYWJibGUuY29tLzItNi0zMi0yNy1kb20wLUJVRy11bmFibGUtdG8t
aGFuZGxlLWtlcm5lbC1wYWdpbmctcmVxdWVzdC10ZDMzMjMwMTEuaHRtbAo+IGFuZCByYWlzZSAv
cHJvYy9zeXMvdm0vbWluX2ZyZWVfa2J5dGVzLCBidXQgaXQgZGlkIG5vdCBoZWxwLgoKVGhhdCBp
cyBhIGNvbXBsZXRlbHkgdW5yZWxhdGVkIHByb2JsZW0sICJCVUcgdW5hYmxlIHRvIGhhbmRsZSBr
ZXJuZWwKcGFnaW5nIHJlcXVlc3QiIGlzIGEgdmVyeSBnZW5lcmljIGVycm9yIG1lc3NhZ2Ugd2hp
Y2ggaXMgY29tbW9uIHRvIGxvYWRzCm9mIGRpZmZlcmVudCBwb3RlbnRpYWwgaXNzdWVzLgoKWy4u
Ll0KCklhbi4KCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
XwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9s
aXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Oct 24 08:50:20 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 08:50:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQwf0-0006Mz-5k; Wed, 24 Oct 2012 08:49:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQwey-0006Mu-An
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 08:49:56 +0000
Received: from [85.158.138.51:34861] by server-8.bemta-3.messagelabs.com id
	DB/0D-10525-3BBA7805; Wed, 24 Oct 2012 08:49:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1351068594!27574708!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUzNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32500 invoked from network); 24 Oct 2012 08:49:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 08:49:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="15351034"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 08:49:54 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 09:49:54 +0100
Message-ID: <1351068592.2237.104.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: =?UTF-8?Q?S=C5=82awek?= Kosowski 
Date: Wed, 24 Oct 2012 09:49:52 +0100
In-Reply-To: <5086e5740096e2.94910907@wp.pl>
References: <5086e5740096e2.94910907@wp.pl>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Kernel paging request error
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCAyMDEyLTEwLTIzIGF0IDE5OjQ0ICswMTAwLCBTxYJhd2VrIEtvc293c2tpIHdyb3Rl
Ogo+IFJlcG9zdGluZyBmcm9tIHhlbi11c2VycyAobm8gcmVzcG9uc2UpCj4gSSdtIGhhdmluZyBh
IHByb2JsZW0gd2l0aDogaHR0cDovL3Bhc3RlYmluLmNvbS9DdUdIcXdoeQo+IEl0IG9jY3VycyBv
biB0aGUgcmVib290LCBidXQgc29tZXRpbWVzLCB3aGVuIEkgdHJ5IHRvIHN0YXJ0IG1hbnVhbGx5
IG9uZSBvZgo+IG15IG1hY2hpbmVzLiBTb21ldGltZSwgb25lIG9mIHRoZSBtYWNoaW5lcyBkb2Vz
IG5vdCB3YW50IHRvIHN0YXJ0Cj4gcGVybWFuZW50bHkgYW5kIEkgaGF2ZSB0byByZWluc3RhbGwv
cmVzdG9yZSBpdC4KCk9uZSBleHBlcmltZW50IHRvIHRyeSwgYmFzZWQgb24gRGViaWFuIGJ1ZyAj
NjQyMTU0IHdvdWxkIGJlIHRvIHRyeQoibm94c2F2ZSIgYW5kL29yICJub3hzYXZlb3B0IiBvbiB5
b3VyIGtlcm5lbCBjb21tYW5kIGxpbmUuIFBsZWFzZSB0cnkKZWFjaCBpbmRlcGVuZGVudGx5IGFu
ZCBib3RoIHRvZ2V0aGVyLgoKSSB0aG91Z2h0IHRoaXMgc29ydCBvZiB0aGluZyB3YXMgaXJvbmVk
IG91dCBiZWZvcmUgMy4yLiBTaW5jZSB5b3UgYXJlCnJ1bm5pbmcgYSBicG8ga2VybmVsIHlvdSBj
b3VsZCBhbHNvIGNvbnNpZGVyIHJ1bm5pbmcgYSBiYWNrcG9ydCBvZiBYZW4KNC4xIGZyb20gV2hl
ZXp5IGFzIHdlbGwuCgo+IFRoaXMgcHJvYmxlbSBjb21lcyBmb3IgbWUgcmFuZG9tbHksIGJ1dCBt
YXliZSB0aGVyZSBpcyBhIHRyaWdnZXIuIAo+IEkndmUgdHJpZWQgdG8gZm9sbG93Ogo+IGh0dHA6
Ly94ZW4uMTA0NTcxMi5uNS5uYWJibGUuY29tLzItNi0zMi0yNy1kb20wLUJVRy11bmFibGUtdG8t
aGFuZGxlLWtlcm5lbC1wYWdpbmctcmVxdWVzdC10ZDMzMjMwMTEuaHRtbAo+IGFuZCByYWlzZSAv
cHJvYy9zeXMvdm0vbWluX2ZyZWVfa2J5dGVzLCBidXQgaXQgZGlkIG5vdCBoZWxwLgoKVGhhdCBp
cyBhIGNvbXBsZXRlbHkgdW5yZWxhdGVkIHByb2JsZW0sICJCVUcgdW5hYmxlIHRvIGhhbmRsZSBr
ZXJuZWwKcGFnaW5nIHJlcXVlc3QiIGlzIGEgdmVyeSBnZW5lcmljIGVycm9yIG1lc3NhZ2Ugd2hp
Y2ggaXMgY29tbW9uIHRvIGxvYWRzCm9mIGRpZmZlcmVudCBwb3RlbnRpYWwgaXNzdWVzLgoKWy4u
Ll0KCklhbi4KCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
XwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9s
aXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Oct 24 09:21:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 09:21:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQx8f-0006i2-VT; Wed, 24 Oct 2012 09:20:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQx8d-0006hu-Nw; Wed, 24 Oct 2012 09:20:35 +0000
Received: from [193.109.254.147:65418] by server-5.bemta-14.messagelabs.com id
	23/E0-18309-2E2B7805; Wed, 24 Oct 2012 09:20:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1351070431!3968324!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28780 invoked from network); 24 Oct 2012 09:20:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 09:20:33 -0000
X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="15352017"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 09:20:31 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 10:20:31 +0100
Message-ID: <1351070429.2237.117.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Maik Brauer 
Date: Wed, 24 Oct 2012 10:20:29 +0100
In-Reply-To: <5BCCD750-18E4-4541-BE76-CA2156609E23@mbs-systems.net>
References: 
	<5BCCD750-18E4-4541-BE76-CA2156609E23@mbs-systems.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-users@lists.xen.org" ,
	xen-devel 
Subject: Re: [Xen-devel] Fwd: [Xen-users] XEN 4.2 - DomU Restore after Dom0
 reboot not working
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Adding xen-devel.

On Sun, 2012-10-21 at 22:43 +0100, Maik Brauer wrote:
> Hi Ian,
> 
> 
> may you want to check the Line 258 in the xendomains init script.
> It quits with "Restoring Xen domains:/etc/init.d/xendomains: line 258:
> [: too many arguments"
> 
> 
> The current line is: if [ $HEADER = "LinuxGuestRecord" ]; then
> I put the $HEADER in brackets like: "$HEADER" and I modified it with
> the header what XL-Toolkit is using: "Xen saved domain"
> So basically the new line 258 looks like this: if [ "$HEADER" =
> "LinuxGuestRecord" ] || [ "$HEADER" = "Xen saved domain" ]; then

I guess "LinuxGuestRecord" is a xend-ism (its very badly chosen, there
is nothing at all specific to Linux there) while xl uses "Xen saved
domain, xl format\n \0 \r".

We could expand the check, but we would probably want to correlate the
header we look for against the toolstack which is being used (since
restoring on the other one wont work). The original check came from
15448:356bd2f3b9d8,
http://lists.xen.org/archives/html/xen-devel/2007-06/msg01011.html and
http://lists.xen.org/archives/html/xen-devel/2007-07/msg00061.html

We could also consider just removing it and try and restore any file we
find in $XENDOMAINS_SAVE i.e. rely on the toolstack's own error
handling.

Any thoughts?

> Now the Save and Restore is working perfect. Can you confirm that
> there is still a bug in the xendomains script?
> Thanks a lot.
> 
> 
> Cheers,
> Maik
> 
> Begin forwarded message:
> 
> > From: Maik Brauer 
> > 
> > Subject: Re: [Xen-users] XEN 4.2 - DomU Restore after Dom0 reboot
> > not working
> > 
> > Date: October 21, 2012 5:34:25 PM GMT+02:00
> > 
> > To: Zary Matej 
> > 
> > Cc: "xen-users@lists.xen.org" 
> > 
> > 
> > Yes that is true. It can be configured via that file. But default it
> > is already configured to work with save and restore. But in my case
> > it is not working. The domain will be save properly. But after Dom0
> > reboot it will not restore. What can be the issue here?
> > 
> > On 20.10.2012, at 23:06, Zary Matej  wrote:
> > 
> > > 
> > > > 
> > > > From: xen-users-bounces@lists.xen.org
> > > > [xen-users-bounces@lists.xen.org] On Behalf Of Maik Brauer
> > > > [maik.brauer@mbs-systems.net]
> > > > Sent: 20 October 2012 17:51
> > > > To: xen-users@lists.xen.org
> > > > Subject: [Xen-users] XEN 4.2 - DomU Restore after Dom0 reboot
> > > > not working
> > > > 
> > > > Hi,
> > > > 
> > > > after a reboot of my Dom0 the DomU will not restore after the
> > > > Dom0 is available again.
> > > > The image file has been saved under /var/lib/xen/save
> > > > 
> > > > But it will not restore automatically after reboot. If you just
> > > > try to bring it up manually with
> > > > xl restore /var/lib/xen/save/mydomain
> > > > it is working and the DomU starts up.
> > > > 
> > > > What is the issue that the Domain will not start during reboot.
> > > > Thanks.
> > > > 
> > > > Cheers,
> > > > Maik
> > > 
> > > 
> > > Hi, if I recall correctly, this behavior used to be controlled via
> > > setting in config file (e.g. /etc/sysconfig/xendomains - it
> > > depends on your distro).
> > > 
> > > Matej
> > > 
> > > 
> > > _______________________________________________
> > > Xen-users mailing list
> > > Xen-users@lists.xen.org
> > > http://lists.xen.org/xen-users
> > > 
> > > _______________________________________________
> > > Xen-users mailing list
> > > Xen-users@lists.xen.org
> > > http://lists.xen.org/xen-users
> > 
> > _______________________________________________
> > Xen-users mailing list
> > Xen-users@lists.xen.org
> > http://lists.xen.org/xen-users
> > 
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 09:21:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 09:21:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQx8f-0006i2-VT; Wed, 24 Oct 2012 09:20:37 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQx8d-0006hu-Nw; Wed, 24 Oct 2012 09:20:35 +0000
Received: from [193.109.254.147:65418] by server-5.bemta-14.messagelabs.com id
	23/E0-18309-2E2B7805; Wed, 24 Oct 2012 09:20:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1351070431!3968324!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28780 invoked from network); 24 Oct 2012 09:20:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 09:20:33 -0000
X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="15352017"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 09:20:31 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 10:20:31 +0100
Message-ID: <1351070429.2237.117.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Maik Brauer 
Date: Wed, 24 Oct 2012 10:20:29 +0100
In-Reply-To: <5BCCD750-18E4-4541-BE76-CA2156609E23@mbs-systems.net>
References: 
	<5BCCD750-18E4-4541-BE76-CA2156609E23@mbs-systems.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-users@lists.xen.org" ,
	xen-devel 
Subject: Re: [Xen-devel] Fwd: [Xen-users] XEN 4.2 - DomU Restore after Dom0
 reboot not working
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Adding xen-devel.

On Sun, 2012-10-21 at 22:43 +0100, Maik Brauer wrote:
> Hi Ian,
> 
> 
> may you want to check the Line 258 in the xendomains init script.
> It quits with "Restoring Xen domains:/etc/init.d/xendomains: line 258:
> [: too many arguments"
> 
> 
> The current line is: if [ $HEADER = "LinuxGuestRecord" ]; then
> I put the $HEADER in brackets like: "$HEADER" and I modified it with
> the header what XL-Toolkit is using: "Xen saved domain"
> So basically the new line 258 looks like this: if [ "$HEADER" =
> "LinuxGuestRecord" ] || [ "$HEADER" = "Xen saved domain" ]; then

I guess "LinuxGuestRecord" is a xend-ism (its very badly chosen, there
is nothing at all specific to Linux there) while xl uses "Xen saved
domain, xl format\n \0 \r".

We could expand the check, but we would probably want to correlate the
header we look for against the toolstack which is being used (since
restoring on the other one wont work). The original check came from
15448:356bd2f3b9d8,
http://lists.xen.org/archives/html/xen-devel/2007-06/msg01011.html and
http://lists.xen.org/archives/html/xen-devel/2007-07/msg00061.html

We could also consider just removing it and try and restore any file we
find in $XENDOMAINS_SAVE i.e. rely on the toolstack's own error
handling.

Any thoughts?

> Now the Save and Restore is working perfect. Can you confirm that
> there is still a bug in the xendomains script?
> Thanks a lot.
> 
> 
> Cheers,
> Maik
> 
> Begin forwarded message:
> 
> > From: Maik Brauer 
> > 
> > Subject: Re: [Xen-users] XEN 4.2 - DomU Restore after Dom0 reboot
> > not working
> > 
> > Date: October 21, 2012 5:34:25 PM GMT+02:00
> > 
> > To: Zary Matej 
> > 
> > Cc: "xen-users@lists.xen.org" 
> > 
> > 
> > Yes that is true. It can be configured via that file. But default it
> > is already configured to work with save and restore. But in my case
> > it is not working. The domain will be save properly. But after Dom0
> > reboot it will not restore. What can be the issue here?
> > 
> > On 20.10.2012, at 23:06, Zary Matej  wrote:
> > 
> > > 
> > > > 
> > > > From: xen-users-bounces@lists.xen.org
> > > > [xen-users-bounces@lists.xen.org] On Behalf Of Maik Brauer
> > > > [maik.brauer@mbs-systems.net]
> > > > Sent: 20 October 2012 17:51
> > > > To: xen-users@lists.xen.org
> > > > Subject: [Xen-users] XEN 4.2 - DomU Restore after Dom0 reboot
> > > > not working
> > > > 
> > > > Hi,
> > > > 
> > > > after a reboot of my Dom0 the DomU will not restore after the
> > > > Dom0 is available again.
> > > > The image file has been saved under /var/lib/xen/save
> > > > 
> > > > But it will not restore automatically after reboot. If you just
> > > > try to bring it up manually with
> > > > xl restore /var/lib/xen/save/mydomain
> > > > it is working and the DomU starts up.
> > > > 
> > > > What is the issue that the Domain will not start during reboot.
> > > > Thanks.
> > > > 
> > > > Cheers,
> > > > Maik
> > > 
> > > 
> > > Hi, if I recall correctly, this behavior used to be controlled via
> > > setting in config file (e.g. /etc/sysconfig/xendomains - it
> > > depends on your distro).
> > > 
> > > Matej
> > > 
> > > 
> > > _______________________________________________
> > > Xen-users mailing list
> > > Xen-users@lists.xen.org
> > > http://lists.xen.org/xen-users
> > > 
> > > _______________________________________________
> > > Xen-users mailing list
> > > Xen-users@lists.xen.org
> > > http://lists.xen.org/xen-users
> > 
> > _______________________________________________
> > Xen-users mailing list
> > Xen-users@lists.xen.org
> > http://lists.xen.org/xen-users
> > 
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 09:24:51 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 09:24:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQxCK-0006yj-7y; Wed, 24 Oct 2012 09:24:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQxCI-0006ya-8p
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 09:24:22 +0000
Received: from [85.158.139.211:19549] by server-5.bemta-5.messagelabs.com id
	36/7C-09732-5C3B7805; Wed, 24 Oct 2012 09:24:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1351070659!23508075!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4745 invoked from network); 24 Oct 2012 09:24:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 09:24:20 -0000
X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="15352143"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 09:23:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 10:23:44 +0100
Message-ID: <1351070623.2237.120.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: David Xu 
Date: Wed, 24 Oct 2012 10:23:43 +0100
In-Reply-To: 
References: 
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] xen_evtchn_do_upcall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-10-22 at 02:51 +0100, David Xu wrote:
> Hi, 
> 
> 
> Is anybody know the purpose of this method (xen_evtchn_do_upcall)?

It is the callback used to inject event channels events (i.e. IRQs) into
the guest. You would expect to see it at the base of any stack trace
taken from interrupt context.

>  When I run a user level application involved in TCP receiving and the
> SoftIRQ for eth0 on the same CPU core, everything is OK. But if I run
> them on 2 different cores, there will be xen_evtchn_do_upcall()
> existing (maybe when the local_bh_disable() or local_bh_enable() is
> called)

it would not be unusual to get an interrupt immediately after
re-enabling interrupts.

>  in __inet_lookup_established() routine which costs longer time than
> the first scenario. Is it due to the synchronization issue between
> process context and softirq context? Thanks for any reply. 
> 
> 
>  1)               |    __inet_lookup_established() {
>  1)               |    xen_evtchn_do_upcall() {
>  1)   0.054 us    |      exit_idle();
>  1)               |      irq_enter() {
>  1)               |        rcu_irq_enter() {
>  1)   0.102 us    |          rcu_exit_nohz();
>  1)   0.431 us    |        }
>  1)   0.064 us    |        idle_cpu();
>  1)   1.152 us    |      }
>  1)               |      __xen_evtchn_do_upcall() {
>  1)   0.119 us    |        irq_to_desc();
>  1)               |        handle_edge_irq() {
>  1)   0.107 us    |          _raw_spin_lock();
>  1)               |          ack_dynirq() {
>  1)               |            evtchn_from_irq() {
>  1)               |              info_for_irq() {
>  1)               |                irq_get_irq_data() {
>  1)   0.052 us    |                  irq_to_desc();
>  1)   0.418 us    |                }
>  1)   0.782 us    |              }
>  1)   1.135 us    |            }
>  1)   0.049 us    |            irq_move_irq();
>  1)   1.800 us    |          }
>  1)               |          handle_irq_event() {
>  1)   0.161 us    |            _raw_spin_unlock();
>  1)               |            handle_irq_event_percpu() {
>  1)               |              xennet_interrupt() {
>  1)   0.125 us    |                _raw_spin_lock_irqsave();
>  1)               |                xennet_tx_buf_gc() {
>  1)   0.079 us    |                  gnttab_query_foreign_access();
>  1)   0.050 us    |                  gnttab_end_foreign_access_ref();
>  1)   0.069 us    |                  gnttab_release_grant_reference();
>  1)               |                  dev_kfree_skb_irq() {
>  1)   0.055 us    |                    raise_softirq_irqoff();
>  1)   0.472 us    |                  }
>  1)   0.049 us    |                  gnttab_query_foreign_access();
>  1)   0.058 us    |                  gnttab_end_foreign_access_ref();
>  1)   0.058 us    |                  gnttab_release_grant_reference();
>  1)               |                  dev_kfree_skb_irq() {
>  1)   0.050 us    |                    raise_softirq_irqoff();
>  1)   0.456 us    |                  }
>  1)   3.714 us    |                }
>  1)   0.102 us    |                _raw_spin_unlock_irqrestore();
>  1)   4.857 us    |              }
>  1)   0.061 us    |              note_interrupt();
>  1)   5.571 us    |            }
>  1)   0.054 us    |            _raw_spin_lock();
>  1)   6.707 us    |          }
>  1)   0.083 us    |          _raw_spin_unlock();
>  1) + 10.083 us   |        }
>  1) + 10.985 us   |      }
>  1)               |      irq_exit() {
>  1)               |        rcu_irq_exit() {
>  1)   0.087 us    |          rcu_enter_nohz();
>  1)   0.429 us    |        }
>  1)   0.049 us    |        idle_cpu();
>  1)   1.088 us    |      }
>  1) + 14.551 us   |    }
>  1)   0.191 us    |    } /* __inet_lookup_established */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 09:24:51 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 09:24:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQxCK-0006yj-7y; Wed, 24 Oct 2012 09:24:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQxCI-0006ya-8p
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 09:24:22 +0000
Received: from [85.158.139.211:19549] by server-5.bemta-5.messagelabs.com id
	36/7C-09732-5C3B7805; Wed, 24 Oct 2012 09:24:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1351070659!23508075!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4745 invoked from network); 24 Oct 2012 09:24:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 09:24:20 -0000
X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="15352143"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 09:23:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 10:23:44 +0100
Message-ID: <1351070623.2237.120.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: David Xu 
Date: Wed, 24 Oct 2012 10:23:43 +0100
In-Reply-To: 
References: 
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] xen_evtchn_do_upcall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-10-22 at 02:51 +0100, David Xu wrote:
> Hi, 
> 
> 
> Is anybody know the purpose of this method (xen_evtchn_do_upcall)?

It is the callback used to inject event channels events (i.e. IRQs) into
the guest. You would expect to see it at the base of any stack trace
taken from interrupt context.

>  When I run a user level application involved in TCP receiving and the
> SoftIRQ for eth0 on the same CPU core, everything is OK. But if I run
> them on 2 different cores, there will be xen_evtchn_do_upcall()
> existing (maybe when the local_bh_disable() or local_bh_enable() is
> called)

it would not be unusual to get an interrupt immediately after
re-enabling interrupts.

>  in __inet_lookup_established() routine which costs longer time than
> the first scenario. Is it due to the synchronization issue between
> process context and softirq context? Thanks for any reply. 
> 
> 
>  1)               |    __inet_lookup_established() {
>  1)               |    xen_evtchn_do_upcall() {
>  1)   0.054 us    |      exit_idle();
>  1)               |      irq_enter() {
>  1)               |        rcu_irq_enter() {
>  1)   0.102 us    |          rcu_exit_nohz();
>  1)   0.431 us    |        }
>  1)   0.064 us    |        idle_cpu();
>  1)   1.152 us    |      }
>  1)               |      __xen_evtchn_do_upcall() {
>  1)   0.119 us    |        irq_to_desc();
>  1)               |        handle_edge_irq() {
>  1)   0.107 us    |          _raw_spin_lock();
>  1)               |          ack_dynirq() {
>  1)               |            evtchn_from_irq() {
>  1)               |              info_for_irq() {
>  1)               |                irq_get_irq_data() {
>  1)   0.052 us    |                  irq_to_desc();
>  1)   0.418 us    |                }
>  1)   0.782 us    |              }
>  1)   1.135 us    |            }
>  1)   0.049 us    |            irq_move_irq();
>  1)   1.800 us    |          }
>  1)               |          handle_irq_event() {
>  1)   0.161 us    |            _raw_spin_unlock();
>  1)               |            handle_irq_event_percpu() {
>  1)               |              xennet_interrupt() {
>  1)   0.125 us    |                _raw_spin_lock_irqsave();
>  1)               |                xennet_tx_buf_gc() {
>  1)   0.079 us    |                  gnttab_query_foreign_access();
>  1)   0.050 us    |                  gnttab_end_foreign_access_ref();
>  1)   0.069 us    |                  gnttab_release_grant_reference();
>  1)               |                  dev_kfree_skb_irq() {
>  1)   0.055 us    |                    raise_softirq_irqoff();
>  1)   0.472 us    |                  }
>  1)   0.049 us    |                  gnttab_query_foreign_access();
>  1)   0.058 us    |                  gnttab_end_foreign_access_ref();
>  1)   0.058 us    |                  gnttab_release_grant_reference();
>  1)               |                  dev_kfree_skb_irq() {
>  1)   0.050 us    |                    raise_softirq_irqoff();
>  1)   0.456 us    |                  }
>  1)   3.714 us    |                }
>  1)   0.102 us    |                _raw_spin_unlock_irqrestore();
>  1)   4.857 us    |              }
>  1)   0.061 us    |              note_interrupt();
>  1)   5.571 us    |            }
>  1)   0.054 us    |            _raw_spin_lock();
>  1)   6.707 us    |          }
>  1)   0.083 us    |          _raw_spin_unlock();
>  1) + 10.083 us   |        }
>  1) + 10.985 us   |      }
>  1)               |      irq_exit() {
>  1)               |        rcu_irq_exit() {
>  1)   0.087 us    |          rcu_enter_nohz();
>  1)   0.429 us    |        }
>  1)   0.049 us    |        idle_cpu();
>  1)   1.088 us    |      }
>  1) + 14.551 us   |    }
>  1)   0.191 us    |    } /* __inet_lookup_established */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 09:28:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 09:28:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQxFl-0007Ct-1u; Wed, 24 Oct 2012 09:27:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQxFk-0007Cm-EK
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 09:27:56 +0000
Received: from [85.158.138.51:40091] by server-1.bemta-3.messagelabs.com id
	DF/C8-31728-B94B7805; Wed, 24 Oct 2012 09:27:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1351070874!35516277!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUzNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17406 invoked from network); 24 Oct 2012 09:27:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 09:27:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="15352279"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 09:27:54 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 10:27:54 +0100
Message-ID: <1351070872.2237.122.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 24 Oct 2012 10:27:52 +0100
In-Reply-To: <20121023144614.GC1052@phenom.dumpdata.com>
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
	<1350695882-12820-2-git-send-email-konrad.wilk@oracle.com>
	<20121023144614.GC1052@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 1/6] xen/pvh: Support ParaVirtualized
 Hardware extensions.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-23 at 15:46 +0100, Konrad Rzeszutek Wilk wrote:
> > diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
> > index b66d04c..8beebdb 100644
> > --- a/include/xen/interface/memory.h
> > +++ b/include/xen/interface/memory.h
> > @@ -169,7 +169,13 @@ struct xen_add_to_physmap {
> >      /* Source mapping space. */
> >  #define XENMAPSPACE_shared_info 0 /* shared info page */
> >  #define XENMAPSPACE_grant_table 1 /* grant table page */
> > -    unsigned int space;
> > +#define XENMAPSPACE_gmfn        2 /* GMFN */
> > +#define XENMAPSPACE_gmfn_range  3 /* GMFN range */
> > +#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */
> > +    uint16_t space;
> > +    domid_t foreign_domid;         /* IFF XENMAPSPACE_gmfn_foreign */
> > +
> > +#define XENMAPIDX_grant_table_status 0x80000000
> >  
> >      /* Index into source mapping space. */
> >      xen_ulong_t idx;
> 
> And this breaks 32-bit PVHVM :-(
> 
> The reason being that in xen_hvm_init_shared_info we allocate the
> structure on the stack, and do not clear the foreign_domid to zero.
> 
> This means we can (and do get) for the argument space, something
> like this:
> 	xatp.space == 0xffff0001;
> instead of
> 	xatp.space = 0x1;

We should be reverting this patch and using XENMEM_add_to_physmap range
instead, see my "xen: x86 pvh: use XENMEM_add_to_physmap_range for
foreign gmfn mappings" from last week.

Mukesh wanted to go with this original version in the interim so
probably fixing it as you have makes sense anyhow.

> 
> This fixes it:
> 
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index e3497f2..b679f86 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -1509,6 +1509,7 @@ void __ref xen_hvm_init_shared_info(void)
>  	xatp.domid = DOMID_SELF;
>  	xatp.idx = 0;
>  	xatp.space = XENMAPSPACE_shared_info;
> +	xatp.foreign_domid = 0;
>  	xatp.gpfn = __pa(shared_info_page) >> PAGE_SHIFT;
>  	if (HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp))
>  		BUG();
> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> index b2b0a37..cbfd929 100644
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -1044,6 +1044,7 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
>  		do {
>  			xatp.domid = DOMID_SELF;
>  			xatp.idx = i;
> +			xatp.foreign_domid = 0;
>  			xatp.space = XENMAPSPACE_grant_table;
>  			xatp.gpfn = (xen_hvm_resume_frames >> PAGE_SHIFT) + i;
>  			rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 09:28:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 09:28:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQxFl-0007Ct-1u; Wed, 24 Oct 2012 09:27:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQxFk-0007Cm-EK
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 09:27:56 +0000
Received: from [85.158.138.51:40091] by server-1.bemta-3.messagelabs.com id
	DF/C8-31728-B94B7805; Wed, 24 Oct 2012 09:27:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1351070874!35516277!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUzNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17406 invoked from network); 24 Oct 2012 09:27:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 09:27:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="15352279"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 09:27:54 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 10:27:54 +0100
Message-ID: <1351070872.2237.122.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 24 Oct 2012 10:27:52 +0100
In-Reply-To: <20121023144614.GC1052@phenom.dumpdata.com>
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
	<1350695882-12820-2-git-send-email-konrad.wilk@oracle.com>
	<20121023144614.GC1052@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 1/6] xen/pvh: Support ParaVirtualized
 Hardware extensions.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-23 at 15:46 +0100, Konrad Rzeszutek Wilk wrote:
> > diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
> > index b66d04c..8beebdb 100644
> > --- a/include/xen/interface/memory.h
> > +++ b/include/xen/interface/memory.h
> > @@ -169,7 +169,13 @@ struct xen_add_to_physmap {
> >      /* Source mapping space. */
> >  #define XENMAPSPACE_shared_info 0 /* shared info page */
> >  #define XENMAPSPACE_grant_table 1 /* grant table page */
> > -    unsigned int space;
> > +#define XENMAPSPACE_gmfn        2 /* GMFN */
> > +#define XENMAPSPACE_gmfn_range  3 /* GMFN range */
> > +#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */
> > +    uint16_t space;
> > +    domid_t foreign_domid;         /* IFF XENMAPSPACE_gmfn_foreign */
> > +
> > +#define XENMAPIDX_grant_table_status 0x80000000
> >  
> >      /* Index into source mapping space. */
> >      xen_ulong_t idx;
> 
> And this breaks 32-bit PVHVM :-(
> 
> The reason being that in xen_hvm_init_shared_info we allocate the
> structure on the stack, and do not clear the foreign_domid to zero.
> 
> This means we can (and do get) for the argument space, something
> like this:
> 	xatp.space == 0xffff0001;
> instead of
> 	xatp.space = 0x1;

We should be reverting this patch and using XENMEM_add_to_physmap range
instead, see my "xen: x86 pvh: use XENMEM_add_to_physmap_range for
foreign gmfn mappings" from last week.

Mukesh wanted to go with this original version in the interim so
probably fixing it as you have makes sense anyhow.

> 
> This fixes it:
> 
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index e3497f2..b679f86 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -1509,6 +1509,7 @@ void __ref xen_hvm_init_shared_info(void)
>  	xatp.domid = DOMID_SELF;
>  	xatp.idx = 0;
>  	xatp.space = XENMAPSPACE_shared_info;
> +	xatp.foreign_domid = 0;
>  	xatp.gpfn = __pa(shared_info_page) >> PAGE_SHIFT;
>  	if (HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp))
>  		BUG();
> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> index b2b0a37..cbfd929 100644
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -1044,6 +1044,7 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
>  		do {
>  			xatp.domid = DOMID_SELF;
>  			xatp.idx = i;
> +			xatp.foreign_domid = 0;
>  			xatp.space = XENMAPSPACE_grant_table;
>  			xatp.gpfn = (xen_hvm_resume_frames >> PAGE_SHIFT) + i;
>  			rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 09:30:15 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 09:30:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQxHc-0007LK-JC; Wed, 24 Oct 2012 09:29:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQxHb-0007L8-57
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 09:29:51 +0000
Received: from [85.158.143.35:12942] by server-3.bemta-4.messagelabs.com id
	09/27-24279-E05B7805; Wed, 24 Oct 2012 09:29:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1351070981!12485127!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUzNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2690 invoked from network); 24 Oct 2012 09:29:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 09:29:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="15352331"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 09:29:41 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 10:29:41 +0100
Message-ID: <1351070980.2237.124.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 24 Oct 2012 10:29:40 +0100
In-Reply-To: <20121023140753.GB14100@phenom.dumpdata.com>
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
	<1350695882-12820-2-git-send-email-konrad.wilk@oracle.com>
	<20121023140753.GB14100@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 1/6] xen/pvh: Support ParaVirtualized
 Hardware extensions.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-23 at 15:07 +0100, Konrad Rzeszutek Wilk wrote:
> > +/*
> > + * Unmaps the page appearing at a particular GPFN from the specified guest's
> > + * pseudophysical address space.
> > + * arg == addr of xen_remove_from_physmap_t.
> > + */
> > +#define XENMEM_remove_from_physmap      15
> > +struct xen_remove_from_physmap {
> > +    /* Which domain to change the mapping for. */
> > +    domid_t domid;
> > +
> > +    /* GPFN of the current mapping of the page. */
> > +    xen_pfn_t gpfn;
> > +};
> 
> I just realized that this a bit of unfortunate. We end up
> with on 64-bit with this layout:
> 
> {
>   0->1 [domid]
>   2->7 [nothing]
>   8->16 [gpfn]
> 
> }
> 
> which if one were to do a 32-bit build you would get:
> {
>  0->1 [domid]
>  2->3 [nothing]
>  4->7 [gpfn]
> }
> which means another compat layer in Xen.

A relatively simple one, but yes.

> So I think it makes sense to modify this to be 32 and 64-bit
> clean, something like this:

That works.
We could just swap the domid and gpfn members around, although that
ordering reads a bit unnaturally.

> 
> {
> 	domid_t	domid;
> 	u8	pad[6];
> 	xen_pfn_t gpfn;
> 	/* xen_pfn_t under 32-bit x86 is 4 bytes, so extend it */
> #ifdef CONFIG_X86_32
> 	__u8	pad1[4];
> #endif
> }
> 
> that way the structure is exactly the same size and the offsets
> align.
> 
> Mukesh, you OK with that?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 09:30:15 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 09:30:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQxHc-0007LK-JC; Wed, 24 Oct 2012 09:29:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQxHb-0007L8-57
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 09:29:51 +0000
Received: from [85.158.143.35:12942] by server-3.bemta-4.messagelabs.com id
	09/27-24279-E05B7805; Wed, 24 Oct 2012 09:29:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1351070981!12485127!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUzNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2690 invoked from network); 24 Oct 2012 09:29:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 09:29:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="15352331"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 09:29:41 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 10:29:41 +0100
Message-ID: <1351070980.2237.124.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 24 Oct 2012 10:29:40 +0100
In-Reply-To: <20121023140753.GB14100@phenom.dumpdata.com>
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
	<1350695882-12820-2-git-send-email-konrad.wilk@oracle.com>
	<20121023140753.GB14100@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 1/6] xen/pvh: Support ParaVirtualized
 Hardware extensions.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-23 at 15:07 +0100, Konrad Rzeszutek Wilk wrote:
> > +/*
> > + * Unmaps the page appearing at a particular GPFN from the specified guest's
> > + * pseudophysical address space.
> > + * arg == addr of xen_remove_from_physmap_t.
> > + */
> > +#define XENMEM_remove_from_physmap      15
> > +struct xen_remove_from_physmap {
> > +    /* Which domain to change the mapping for. */
> > +    domid_t domid;
> > +
> > +    /* GPFN of the current mapping of the page. */
> > +    xen_pfn_t gpfn;
> > +};
> 
> I just realized that this a bit of unfortunate. We end up
> with on 64-bit with this layout:
> 
> {
>   0->1 [domid]
>   2->7 [nothing]
>   8->16 [gpfn]
> 
> }
> 
> which if one were to do a 32-bit build you would get:
> {
>  0->1 [domid]
>  2->3 [nothing]
>  4->7 [gpfn]
> }
> which means another compat layer in Xen.

A relatively simple one, but yes.

> So I think it makes sense to modify this to be 32 and 64-bit
> clean, something like this:

That works.
We could just swap the domid and gpfn members around, although that
ordering reads a bit unnaturally.

> 
> {
> 	domid_t	domid;
> 	u8	pad[6];
> 	xen_pfn_t gpfn;
> 	/* xen_pfn_t under 32-bit x86 is 4 bytes, so extend it */
> #ifdef CONFIG_X86_32
> 	__u8	pad1[4];
> #endif
> }
> 
> that way the structure is exactly the same size and the offsets
> align.
> 
> Mukesh, you OK with that?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 09:34:22 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 09:34:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQxLf-0007ao-8l; Wed, 24 Oct 2012 09:34:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQxLd-0007aV-Lu
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 09:34:01 +0000
Received: from [85.158.137.99:11169] by server-6.bemta-3.messagelabs.com id
	BF/80-32375-806B7805; Wed, 24 Oct 2012 09:34:00 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1351071240!22785646!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8094 invoked from network); 24 Oct 2012 09:34:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-217.messagelabs.com with SMTP;
	24 Oct 2012 09:34:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 24 Oct 2012 10:33:59 +0100
Message-Id: <5087D22502000078000A3DD9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 24 Oct 2012 10:33:57 +0100
From: "Jan Beulich" 
To: "Christoph Egger" 
References: <5087AB31.6070601@amd.com>
In-Reply-To: <5087AB31.6070601@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Backport requests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 24.10.12 at 10:47, Christoph Egger  wrote:
> please apply the following changesets to Xen-4.2-testing:
> 
> 26095:a7503ce27d46
> 26096:d642720e1ea9

I have already queued them for that branch; please allow a little
time for them to appear there (they barely came out of unstable's
staging tree).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 09:34:22 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 09:34:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQxLf-0007ao-8l; Wed, 24 Oct 2012 09:34:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQxLd-0007aV-Lu
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 09:34:01 +0000
Received: from [85.158.137.99:11169] by server-6.bemta-3.messagelabs.com id
	BF/80-32375-806B7805; Wed, 24 Oct 2012 09:34:00 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1351071240!22785646!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxNTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8094 invoked from network); 24 Oct 2012 09:34:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-217.messagelabs.com with SMTP;
	24 Oct 2012 09:34:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 24 Oct 2012 10:33:59 +0100
Message-Id: <5087D22502000078000A3DD9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 24 Oct 2012 10:33:57 +0100
From: "Jan Beulich" 
To: "Christoph Egger" 
References: <5087AB31.6070601@amd.com>
In-Reply-To: <5087AB31.6070601@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Backport requests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 24.10.12 at 10:47, Christoph Egger  wrote:
> please apply the following changesets to Xen-4.2-testing:
> 
> 26095:a7503ce27d46
> 26096:d642720e1ea9

I have already queued them for that branch; please allow a little
time for them to appear there (they barely came out of unstable's
staging tree).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 09:35:12 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 09:35:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQxMU-0007ez-MC; Wed, 24 Oct 2012 09:34:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQxMT-0007eq-Nj
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 09:34:53 +0000
Received: from [85.158.143.35:39692] by server-2.bemta-4.messagelabs.com id
	B5/88-22268-D36B7805; Wed, 24 Oct 2012 09:34:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1351071281!14523024!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28325 invoked from network); 24 Oct 2012 09:34:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 09:34:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="15352515"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 09:34:41 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 10:34:41 +0100
Message-ID: <1351071279.2237.126.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Jan Beulich 
Date: Wed, 24 Oct 2012 10:34:39 +0100
In-Reply-To: <5087B13402000078000A3CBB@nat28.tlf.novell.com>
References: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
	<5087B13402000078000A3CBB@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	xen-devel ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V5] PVH patches for v3.8.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 08:13 +0100, Jan Beulich wrote:

> >  include/xen/interface/memory.h       |   29 ++++++-
> >  include/xen/interface/physdev.h      |   10 ++
> 
> ... any changes to the hypervisor interface (didn't look in detail
> what is being changed in these two headers) should first be in
> at least -unstable before being consumed in any official release
> imo.

I'd also like to see at least the interface definitions in the h/v tree
if not the implementation right away.

The flip side is that we have agreed that the interfaces are not
considered set in stone / stable until we've had a chance to review the
implementation, so perhaps it is better not to commit them to
xen-unstable.hg right away.

I don't know what the right answer is. Perhaps we should at a minimum
reserve the subop numbers even if we don't yet define what they mean in
the Xen tree.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 09:35:12 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 09:35:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQxMU-0007ez-MC; Wed, 24 Oct 2012 09:34:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQxMT-0007eq-Nj
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 09:34:53 +0000
Received: from [85.158.143.35:39692] by server-2.bemta-4.messagelabs.com id
	B5/88-22268-D36B7805; Wed, 24 Oct 2012 09:34:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1351071281!14523024!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28325 invoked from network); 24 Oct 2012 09:34:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 09:34:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="15352515"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 09:34:41 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 10:34:41 +0100
Message-ID: <1351071279.2237.126.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Jan Beulich 
Date: Wed, 24 Oct 2012 10:34:39 +0100
In-Reply-To: <5087B13402000078000A3CBB@nat28.tlf.novell.com>
References: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
	<5087B13402000078000A3CBB@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	xen-devel ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH V5] PVH patches for v3.8.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 08:13 +0100, Jan Beulich wrote:

> >  include/xen/interface/memory.h       |   29 ++++++-
> >  include/xen/interface/physdev.h      |   10 ++
> 
> ... any changes to the hypervisor interface (didn't look in detail
> what is being changed in these two headers) should first be in
> at least -unstable before being consumed in any official release
> imo.

I'd also like to see at least the interface definitions in the h/v tree
if not the implementation right away.

The flip side is that we have agreed that the interfaces are not
considered set in stone / stable until we've had a chance to review the
implementation, so perhaps it is better not to commit them to
xen-unstable.hg right away.

I don't know what the right answer is. Perhaps we should at a minimum
reserve the subop numbers even if we don't yet define what they mean in
the Xen tree.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 09:37:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 09:37:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQxOM-0007or-6Y; Wed, 24 Oct 2012 09:36:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQxOK-0007oh-ON
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 09:36:48 +0000
Received: from [85.158.143.99:25553] by server-3.bemta-4.messagelabs.com id
	81/74-24279-0B6B7805; Wed, 24 Oct 2012 09:36:48 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1351071404!25723927!1
X-Originating-IP: [216.32.181.182]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18046 invoked from network); 24 Oct 2012 09:36:46 -0000
Received: from ch1ehsobe002.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.182)
	by server-14.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	24 Oct 2012 09:36:46 -0000
Received: from mail97-ch1-R.bigfish.com (10.43.68.242) by
	CH1EHSOBE016.bigfish.com (10.43.70.66) with Microsoft SMTP Server id
	14.1.225.23; Wed, 24 Oct 2012 09:36:44 +0000
Received: from mail97-ch1 (localhost [127.0.0.1])	by mail97-ch1-R.bigfish.com
	(Postfix) with ESMTP id 314D02E0246	for ;
	Wed, 24 Oct 2012 09:36:44 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202h1d1ah1d2ahzzz2dh668h839hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h)
Received: from mail97-ch1 (localhost.localdomain [127.0.0.1]) by mail97-ch1
	(MessageSwitch) id 1351071401733498_28465;
	Wed, 24 Oct 2012 09:36:41 +0000 (UTC)
Received: from CH1EHSMHS036.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.246])	by mail97-ch1.bigfish.com (Postfix) with ESMTP id
	AF55046023C
	for ; Wed, 24 Oct 2012 09:36:41 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS036.bigfish.com (10.43.69.245) with Microsoft SMTP Server id
	14.1.225.23; Wed, 24 Oct 2012 09:36:41 +0000
X-WSS-ID: 0MCE5D3-01-1ZU-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1) with ESMTP id 21DE9102803B	for ;
	Wed, 24 Oct 2012 04:36:39 -0500 (CDT)
Received: from SAUSEXDAG05.amd.com (163.181.55.6) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 24 Oct 2012 04:36:51 -0500
Received: from STOREXDAG03.amd.com (10.1.13.12) by sausexdag05.amd.com
	(163.181.55.6) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Wed, 24 Oct 2012 04:36:38 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag03.amd.com
	(10.1.13.12) with Microsoft SMTP Server id 14.2.318.4; Wed, 24 Oct 2012
	05:36:37 -0400
Message-ID: <5087B6A4.6030203@amd.com>
Date: Wed, 24 Oct 2012 11:36:36 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" 
X-OriginatorOrg: amd.com
Subject: [Xen-devel] libxl: build error
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Hi,

I have this build error:

xl_cmdimpl.c:3724:40: error: declaration of 'reboot' shadows a global
declaration

Renaming it to '_reboot' fixes this for me.

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 09:37:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 09:37:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQxOM-0007or-6Y; Wed, 24 Oct 2012 09:36:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQxOK-0007oh-ON
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 09:36:48 +0000
Received: from [85.158.143.99:25553] by server-3.bemta-4.messagelabs.com id
	81/74-24279-0B6B7805; Wed, 24 Oct 2012 09:36:48 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1351071404!25723927!1
X-Originating-IP: [216.32.181.182]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18046 invoked from network); 24 Oct 2012 09:36:46 -0000
Received: from ch1ehsobe002.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.182)
	by server-14.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	24 Oct 2012 09:36:46 -0000
Received: from mail97-ch1-R.bigfish.com (10.43.68.242) by
	CH1EHSOBE016.bigfish.com (10.43.70.66) with Microsoft SMTP Server id
	14.1.225.23; Wed, 24 Oct 2012 09:36:44 +0000
Received: from mail97-ch1 (localhost [127.0.0.1])	by mail97-ch1-R.bigfish.com
	(Postfix) with ESMTP id 314D02E0246	for ;
	Wed, 24 Oct 2012 09:36:44 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202h1d1ah1d2ahzzz2dh668h839hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h)
Received: from mail97-ch1 (localhost.localdomain [127.0.0.1]) by mail97-ch1
	(MessageSwitch) id 1351071401733498_28465;
	Wed, 24 Oct 2012 09:36:41 +0000 (UTC)
Received: from CH1EHSMHS036.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.246])	by mail97-ch1.bigfish.com (Postfix) with ESMTP id
	AF55046023C
	for ; Wed, 24 Oct 2012 09:36:41 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS036.bigfish.com (10.43.69.245) with Microsoft SMTP Server id
	14.1.225.23; Wed, 24 Oct 2012 09:36:41 +0000
X-WSS-ID: 0MCE5D3-01-1ZU-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1) with ESMTP id 21DE9102803B	for ;
	Wed, 24 Oct 2012 04:36:39 -0500 (CDT)
Received: from SAUSEXDAG05.amd.com (163.181.55.6) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 24 Oct 2012 04:36:51 -0500
Received: from STOREXDAG03.amd.com (10.1.13.12) by sausexdag05.amd.com
	(163.181.55.6) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Wed, 24 Oct 2012 04:36:38 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag03.amd.com
	(10.1.13.12) with Microsoft SMTP Server id 14.2.318.4; Wed, 24 Oct 2012
	05:36:37 -0400
Message-ID: <5087B6A4.6030203@amd.com>
Date: Wed, 24 Oct 2012 11:36:36 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" 
X-OriginatorOrg: amd.com
Subject: [Xen-devel] libxl: build error
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Hi,

I have this build error:

xl_cmdimpl.c:3724:40: error: declaration of 'reboot' shadows a global
declaration

Renaming it to '_reboot' fixes this for me.

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 09:38:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 09:38:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQxPL-0007wF-Ko; Wed, 24 Oct 2012 09:37:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQxPK-0007vy-F4
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 09:37:50 +0000
Received: from [85.158.139.83:33205] by server-5.bemta-5.messagelabs.com id
	BC/17-09732-DE6B7805; Wed, 24 Oct 2012 09:37:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1351071469!22176790!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14150 invoked from network); 24 Oct 2012 09:37:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 09:37:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="15352638"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 09:37:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 10:37:46 +0100
Message-ID: <1351071465.2237.128.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 24 Oct 2012 10:37:45 +0100
In-Reply-To: <1351015931-16991-2-git-send-email-konrad.wilk@oracle.com>
References: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
	<1351015931-16991-2-git-send-email-konrad.wilk@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 01/10] xen/pvh: Support ParaVirtualized
 Hardware extensions.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-23 at 19:12 +0100, Konrad Rzeszutek Wilk wrote:
> diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
> index 1844d31..83050d3 100644
> --- a/include/xen/interface/physdev.h
> +++ b/include/xen/interface/physdev.h
> @@ -274,6 +274,16 @@ struct physdev_dbgp_op {
>      } u;
>  };
>  
> +#define PHYSDEVOP_map_iomem        30
> +struct physdev_map_iomem {
> +    /* IN */
> +    uint64_t first_gfn;
> +    uint64_t first_mfn;
> +    uint32_t nr_mfns;
> +    uint32_t add_mapping; /* 1 == add mapping;  0 == unmap */

I think we would usually have map and unmap as separate ops.

> +
> +};
> +
>  /*
>   * Notify that some PIRQ-bound event channels have been unmasked.
>   * ** This command is obsolete since interface version 0x00030202 and is **



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 09:38:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 09:38:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQxPL-0007wF-Ko; Wed, 24 Oct 2012 09:37:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQxPK-0007vy-F4
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 09:37:50 +0000
Received: from [85.158.139.83:33205] by server-5.bemta-5.messagelabs.com id
	BC/17-09732-DE6B7805; Wed, 24 Oct 2012 09:37:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1351071469!22176790!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14150 invoked from network); 24 Oct 2012 09:37:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 09:37:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="15352638"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 09:37:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 10:37:46 +0100
Message-ID: <1351071465.2237.128.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 24 Oct 2012 10:37:45 +0100
In-Reply-To: <1351015931-16991-2-git-send-email-konrad.wilk@oracle.com>
References: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
	<1351015931-16991-2-git-send-email-konrad.wilk@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 01/10] xen/pvh: Support ParaVirtualized
 Hardware extensions.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-23 at 19:12 +0100, Konrad Rzeszutek Wilk wrote:
> diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
> index 1844d31..83050d3 100644
> --- a/include/xen/interface/physdev.h
> +++ b/include/xen/interface/physdev.h
> @@ -274,6 +274,16 @@ struct physdev_dbgp_op {
>      } u;
>  };
>  
> +#define PHYSDEVOP_map_iomem        30
> +struct physdev_map_iomem {
> +    /* IN */
> +    uint64_t first_gfn;
> +    uint64_t first_mfn;
> +    uint32_t nr_mfns;
> +    uint32_t add_mapping; /* 1 == add mapping;  0 == unmap */

I think we would usually have map and unmap as separate ops.

> +
> +};
> +
>  /*
>   * Notify that some PIRQ-bound event channels have been unmasked.
>   * ** This command is obsolete since interface version 0x00030202 and is **



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 09:40:45 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 09:40:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQxRt-000893-74; Wed, 24 Oct 2012 09:40:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQxRr-00088p-BC
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 09:40:27 +0000
Received: from [85.158.143.99:39413] by server-1.bemta-4.messagelabs.com id
	64/BC-19134-A87B7805; Wed, 24 Oct 2012 09:40:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1351071623!28329574!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUzNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21510 invoked from network); 24 Oct 2012 09:40:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 09:40:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="15352714"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 09:40:23 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 10:40:23 +0100
Message-ID: <1351071622.2237.130.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 24 Oct 2012 10:40:22 +0100
In-Reply-To: <1351015931-16991-4-git-send-email-konrad.wilk@oracle.com>
References: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
	<1351015931-16991-4-git-send-email-konrad.wilk@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 03/10] xen/hypercall: Make
 xen_remove_from_physmap the same on 64/32 builds.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-23 at 19:12 +0100, Konrad Rzeszutek Wilk wrote:
> By making the structure exactly the same size and with the same
> offsets on 64 and 32-bit builds we are future-proofing ourselves.
> 
> Signed-off-by: Konrad Rzeszutek Wilk 
> ---
>  include/xen/interface/memory.h |    7 ++++++-
>  1 files changed, 6 insertions(+), 1 deletions(-)
> 
> diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
> index 8beebdb..6b07b54 100644
> --- a/include/xen/interface/memory.h
> +++ b/include/xen/interface/memory.h
> @@ -253,9 +253,14 @@ extern spinlock_t xen_reservation_lock;
>  struct xen_remove_from_physmap {
>      /* Which domain to change the mapping for. */
>      domid_t domid;
> -
> +   /* To be used in the future if need to. */
> +    uint8_t reserved[6];
>      /* GPFN of the current mapping of the page. */
>      xen_pfn_t gpfn;
> +#ifdef CONFIG_X86_32
> +    /* No need to do that on ARM as xen_pfn_t is always 8 bytes. */
> +    uint8_t __pad[4];
> +#endif

I'm not sure if this last one is necessary since this isn't a struct
which would get used in an array. I guess it doesn't hurt though.

>  };
>  DEFINE_GUEST_HANDLE_STRUCT(xen_remove_from_physmap);
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 09:40:45 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 09:40:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQxRt-000893-74; Wed, 24 Oct 2012 09:40:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQxRr-00088p-BC
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 09:40:27 +0000
Received: from [85.158.143.99:39413] by server-1.bemta-4.messagelabs.com id
	64/BC-19134-A87B7805; Wed, 24 Oct 2012 09:40:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1351071623!28329574!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTUzNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21510 invoked from network); 24 Oct 2012 09:40:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 09:40:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="15352714"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 09:40:23 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 10:40:23 +0100
Message-ID: <1351071622.2237.130.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 24 Oct 2012 10:40:22 +0100
In-Reply-To: <1351015931-16991-4-git-send-email-konrad.wilk@oracle.com>
References: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
	<1351015931-16991-4-git-send-email-konrad.wilk@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 03/10] xen/hypercall: Make
 xen_remove_from_physmap the same on 64/32 builds.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-23 at 19:12 +0100, Konrad Rzeszutek Wilk wrote:
> By making the structure exactly the same size and with the same
> offsets on 64 and 32-bit builds we are future-proofing ourselves.
> 
> Signed-off-by: Konrad Rzeszutek Wilk 
> ---
>  include/xen/interface/memory.h |    7 ++++++-
>  1 files changed, 6 insertions(+), 1 deletions(-)
> 
> diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
> index 8beebdb..6b07b54 100644
> --- a/include/xen/interface/memory.h
> +++ b/include/xen/interface/memory.h
> @@ -253,9 +253,14 @@ extern spinlock_t xen_reservation_lock;
>  struct xen_remove_from_physmap {
>      /* Which domain to change the mapping for. */
>      domid_t domid;
> -
> +   /* To be used in the future if need to. */
> +    uint8_t reserved[6];
>      /* GPFN of the current mapping of the page. */
>      xen_pfn_t gpfn;
> +#ifdef CONFIG_X86_32
> +    /* No need to do that on ARM as xen_pfn_t is always 8 bytes. */
> +    uint8_t __pad[4];
> +#endif

I'm not sure if this last one is necessary since this isn't a struct
which would get used in an array. I guess it doesn't hurt though.

>  };
>  DEFINE_GUEST_HANDLE_STRUCT(xen_remove_from_physmap);
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 09:44:53 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 09:44:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQxVv-0008Ks-TE; Wed, 24 Oct 2012 09:44:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQxVu-0008Km-Jm
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 09:44:38 +0000
Received: from [193.109.254.147:53252] by server-6.bemta-14.messagelabs.com id
	0D/0E-17826-588B7805; Wed, 24 Oct 2012 09:44:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1351071875!1765833!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26792 invoked from network); 24 Oct 2012 09:44:36 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-27.messagelabs.com with SMTP;
	24 Oct 2012 09:44:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 24 Oct 2012 10:44:35 +0100
Message-Id: <5087D4A102000078000A3E23@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 24 Oct 2012 10:44:33 +0100
From: "Jan Beulich" 
To: "Ian Campbell" 
References: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
	<5087B13402000078000A3CBB@nat28.tlf.novell.com>
	<1351071279.2237.126.camel@zakaz.uk.xensource.com>
In-Reply-To: <1351071279.2237.126.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH V5] PVH patches for v3.8.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 24.10.12 at 11:34, Ian Campbell  wrote:
> On Wed, 2012-10-24 at 08:13 +0100, Jan Beulich wrote:
> 
>> >  include/xen/interface/memory.h       |   29 ++++++-
>> >  include/xen/interface/physdev.h      |   10 ++
>> 
>> ... any changes to the hypervisor interface (didn't look in detail
>> what is being changed in these two headers) should first be in
>> at least -unstable before being consumed in any official release
>> imo.
> 
> I'd also like to see at least the interface definitions in the h/v tree
> if not the implementation right away.
> 
> The flip side is that we have agreed that the interfaces are not
> considered set in stone / stable until we've had a chance to review the
> implementation, so perhaps it is better not to commit them to
> xen-unstable.hg right away.
> 
> I don't know what the right answer is. Perhaps we should at a minimum
> reserve the subop numbers even if we don't yet define what they mean in
> the Xen tree.

But even then - what use is it to have 3.8 possibly only work on
some intermediate (perhaps even just privately built) hypervisors?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 09:44:53 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 09:44:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQxVv-0008Ks-TE; Wed, 24 Oct 2012 09:44:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQxVu-0008Km-Jm
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 09:44:38 +0000
Received: from [193.109.254.147:53252] by server-6.bemta-14.messagelabs.com id
	0D/0E-17826-588B7805; Wed, 24 Oct 2012 09:44:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1351071875!1765833!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26792 invoked from network); 24 Oct 2012 09:44:36 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-27.messagelabs.com with SMTP;
	24 Oct 2012 09:44:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 24 Oct 2012 10:44:35 +0100
Message-Id: <5087D4A102000078000A3E23@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 24 Oct 2012 10:44:33 +0100
From: "Jan Beulich" 
To: "Ian Campbell" 
References: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
	<5087B13402000078000A3CBB@nat28.tlf.novell.com>
	<1351071279.2237.126.camel@zakaz.uk.xensource.com>
In-Reply-To: <1351071279.2237.126.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH V5] PVH patches for v3.8.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 24.10.12 at 11:34, Ian Campbell  wrote:
> On Wed, 2012-10-24 at 08:13 +0100, Jan Beulich wrote:
> 
>> >  include/xen/interface/memory.h       |   29 ++++++-
>> >  include/xen/interface/physdev.h      |   10 ++
>> 
>> ... any changes to the hypervisor interface (didn't look in detail
>> what is being changed in these two headers) should first be in
>> at least -unstable before being consumed in any official release
>> imo.
> 
> I'd also like to see at least the interface definitions in the h/v tree
> if not the implementation right away.
> 
> The flip side is that we have agreed that the interfaces are not
> considered set in stone / stable until we've had a chance to review the
> implementation, so perhaps it is better not to commit them to
> xen-unstable.hg right away.
> 
> I don't know what the right answer is. Perhaps we should at a minimum
> reserve the subop numbers even if we don't yet define what they mean in
> the Xen tree.

But even then - what use is it to have 3.8 possibly only work on
some intermediate (perhaps even just privately built) hypervisors?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 09:49:18 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 09:49:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQxaB-0008VY-Nw; Wed, 24 Oct 2012 09:49:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQxaA-0008VQ-Lq
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 09:49:02 +0000
Received: from [193.109.254.147:55486] by server-14.bemta-14.messagelabs.com
	id 59/2E-14517-E89B7805; Wed, 24 Oct 2012 09:49:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1351072141!3972819!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3132 invoked from network); 24 Oct 2012 09:49:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 09:49:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="15353004"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 09:49:01 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 10:49:01 +0100
Message-ID: <1351072140.2237.135.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 24 Oct 2012 10:49:00 +0100
In-Reply-To: <1351015931-16991-6-git-send-email-konrad.wilk@oracle.com>
References: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
	<1351015931-16991-6-git-send-email-konrad.wilk@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 05/10] xen/pvh: Extend vcpu_guest_context,
 p2m, event, and XenBus.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-23 at 19:12 +0100, Konrad Rzeszutek Wilk wrote:
[...]
> +		/* GUEST_GDTR_BASE and */
> +		ctxt->u.pvh.gdtaddr = (unsigned long)gdt;
> +		/* GUEST_GDTR_LIMIT in the VMCS. */
> +		ctxt->u.pvh.gdtsz = (unsigned long)(GDT_SIZE - 1);
> +
> [...]
> -		ctxt->gdt_frames[0] = gdt_mfn;
> -		ctxt->gdt_ents      = GDT_ENTRIES;
> +		ctxt->u.pv.gdt_frames[0] = gdt_mfn;
> +		ctxt->u.pv.gdt_ents      = GDT_ENTRIES;

I guess I've been told and forgotten but why does this need to differ
between PV and PVH? Can the hypervisor not take the gfn in gdt_frames[0]
= gdt_mfn and figure out the gdtaddr from it? Is this because n the PV
case the H/V loads the GDT with the address of its own mapping of the
gdt_frames but in the PVH case we have no such mapping because the
pagetables don't have a Xen region in them?

It's worthy of a comment in any case.

[...]
> +	/* PVH TBD/FIXME: future work */
[...]
> +		/* PVH: TBD/FIXME: debug and fix eio map to work with pvh */

Do we really need these TODOs inline in the code? Especially in generic
code.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 09:49:18 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 09:49:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQxaB-0008VY-Nw; Wed, 24 Oct 2012 09:49:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQxaA-0008VQ-Lq
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 09:49:02 +0000
Received: from [193.109.254.147:55486] by server-14.bemta-14.messagelabs.com
	id 59/2E-14517-E89B7805; Wed, 24 Oct 2012 09:49:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1351072141!3972819!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3132 invoked from network); 24 Oct 2012 09:49:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 09:49:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="15353004"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 09:49:01 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 10:49:01 +0100
Message-ID: <1351072140.2237.135.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 24 Oct 2012 10:49:00 +0100
In-Reply-To: <1351015931-16991-6-git-send-email-konrad.wilk@oracle.com>
References: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
	<1351015931-16991-6-git-send-email-konrad.wilk@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 05/10] xen/pvh: Extend vcpu_guest_context,
 p2m, event, and XenBus.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-23 at 19:12 +0100, Konrad Rzeszutek Wilk wrote:
[...]
> +		/* GUEST_GDTR_BASE and */
> +		ctxt->u.pvh.gdtaddr = (unsigned long)gdt;
> +		/* GUEST_GDTR_LIMIT in the VMCS. */
> +		ctxt->u.pvh.gdtsz = (unsigned long)(GDT_SIZE - 1);
> +
> [...]
> -		ctxt->gdt_frames[0] = gdt_mfn;
> -		ctxt->gdt_ents      = GDT_ENTRIES;
> +		ctxt->u.pv.gdt_frames[0] = gdt_mfn;
> +		ctxt->u.pv.gdt_ents      = GDT_ENTRIES;

I guess I've been told and forgotten but why does this need to differ
between PV and PVH? Can the hypervisor not take the gfn in gdt_frames[0]
= gdt_mfn and figure out the gdtaddr from it? Is this because n the PV
case the H/V loads the GDT with the address of its own mapping of the
gdt_frames but in the PVH case we have no such mapping because the
pagetables don't have a Xen region in them?

It's worthy of a comment in any case.

[...]
> +	/* PVH TBD/FIXME: future work */
[...]
> +		/* PVH: TBD/FIXME: debug and fix eio map to work with pvh */

Do we really need these TODOs inline in the code? Especially in generic
code.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 09:53:53 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 09:53:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQxee-0000CH-Dj; Wed, 24 Oct 2012 09:53:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQxed-0000C9-04
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 09:53:39 +0000
Received: from [85.158.139.211:34249] by server-12.bemta-5.messagelabs.com id
	BF/4A-26919-1AAB7805; Wed, 24 Oct 2012 09:53:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1351072417!23496807!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3602 invoked from network); 24 Oct 2012 09:53:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 09:53:37 -0000
X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="15353140"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 09:53:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 10:53:36 +0100
Message-ID: <1351072415.2237.137.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Jan Beulich 
Date: Wed, 24 Oct 2012 10:53:35 +0100
In-Reply-To: <5087D4A102000078000A3E23@nat28.tlf.novell.com>
References: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
	<5087B13402000078000A3CBB@nat28.tlf.novell.com>
	<1351071279.2237.126.camel@zakaz.uk.xensource.com>
	<5087D4A102000078000A3E23@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH V5] PVH patches for v3.8.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 10:44 +0100, Jan Beulich wrote:
> >>> On 24.10.12 at 11:34, Ian Campbell  wrote:
> > On Wed, 2012-10-24 at 08:13 +0100, Jan Beulich wrote:
> > 
> >> >  include/xen/interface/memory.h       |   29 ++++++-
> >> >  include/xen/interface/physdev.h      |   10 ++
> >> 
> >> ... any changes to the hypervisor interface (didn't look in detail
> >> what is being changed in these two headers) should first be in
> >> at least -unstable before being consumed in any official release
> >> imo.
> > 
> > I'd also like to see at least the interface definitions in the h/v tree
> > if not the implementation right away.
> > 
> > The flip side is that we have agreed that the interfaces are not
> > considered set in stone / stable until we've had a chance to review the
> > implementation, so perhaps it is better not to commit them to
> > xen-unstable.hg right away.
> > 
> > I don't know what the right answer is. Perhaps we should at a minimum
> > reserve the subop numbers even if we don't yet define what they mean in
> > the Xen tree.
> 
> But even then - what use is it to have 3.8 possibly only work on
> some intermediate (perhaps even just privately built) hypervisors?

Mukesh was having trouble keeping up with rebasing both the Linux and
Xen sides simultaneously to keep up with development, so he decided to
concentrate on getting the Linux side in first.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 09:53:53 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 09:53:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQxee-0000CH-Dj; Wed, 24 Oct 2012 09:53:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQxed-0000C9-04
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 09:53:39 +0000
Received: from [85.158.139.211:34249] by server-12.bemta-5.messagelabs.com id
	BF/4A-26919-1AAB7805; Wed, 24 Oct 2012 09:53:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1351072417!23496807!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3602 invoked from network); 24 Oct 2012 09:53:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 09:53:37 -0000
X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="15353140"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 09:53:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 10:53:36 +0100
Message-ID: <1351072415.2237.137.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Jan Beulich 
Date: Wed, 24 Oct 2012 10:53:35 +0100
In-Reply-To: <5087D4A102000078000A3E23@nat28.tlf.novell.com>
References: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
	<5087B13402000078000A3CBB@nat28.tlf.novell.com>
	<1351071279.2237.126.camel@zakaz.uk.xensource.com>
	<5087D4A102000078000A3E23@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH V5] PVH patches for v3.8.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 10:44 +0100, Jan Beulich wrote:
> >>> On 24.10.12 at 11:34, Ian Campbell  wrote:
> > On Wed, 2012-10-24 at 08:13 +0100, Jan Beulich wrote:
> > 
> >> >  include/xen/interface/memory.h       |   29 ++++++-
> >> >  include/xen/interface/physdev.h      |   10 ++
> >> 
> >> ... any changes to the hypervisor interface (didn't look in detail
> >> what is being changed in these two headers) should first be in
> >> at least -unstable before being consumed in any official release
> >> imo.
> > 
> > I'd also like to see at least the interface definitions in the h/v tree
> > if not the implementation right away.
> > 
> > The flip side is that we have agreed that the interfaces are not
> > considered set in stone / stable until we've had a chance to review the
> > implementation, so perhaps it is better not to commit them to
> > xen-unstable.hg right away.
> > 
> > I don't know what the right answer is. Perhaps we should at a minimum
> > reserve the subop numbers even if we don't yet define what they mean in
> > the Xen tree.
> 
> But even then - what use is it to have 3.8 possibly only work on
> some intermediate (perhaps even just privately built) hypervisors?

Mukesh was having trouble keeping up with rebasing both the Linux and
Xen sides simultaneously to keep up with development, so he decided to
concentrate on getting the Linux side in first.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 09:59:01 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 09:59:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQxjc-0000Mx-50; Wed, 24 Oct 2012 09:58:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQxjb-0000Mp-7O
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 09:58:47 +0000
Received: from [85.158.143.35:20405] by server-2.bemta-4.messagelabs.com id
	BD/CF-22268-6DBB7805; Wed, 24 Oct 2012 09:58:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1351072713!16333813!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19749 invoked from network); 24 Oct 2012 09:58:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 09:58:33 -0000
X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="15353317"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 09:58:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 10:58:32 +0100
Message-ID: <1351072711.2237.139.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Christoph Egger 
Date: Wed, 24 Oct 2012 10:58:31 +0100
In-Reply-To: <5087B6A4.6030203@amd.com>
References: <5087B6A4.6030203@amd.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] libxl: build error
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 10:36 +0100, Christoph Egger wrote:
> Hi,
> 
> I have this build error:
> 
> xl_cmdimpl.c:3724:40: error: declaration of 'reboot' shadows a global
> declaration

Did gcc tell you where the other global definition was from? reboot(2) I
suppose?

> Renaming it to '_reboot' fixes this for me.

Can you send a patch?

I don't think _reboot is a legal identifier (reserved for the
implementation or POSIX or some such). do_reboot would be ok. So would
changing main_shutdown_or_reboot to take the function pointer directly I
think.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 09:59:01 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 09:59:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQxjc-0000Mx-50; Wed, 24 Oct 2012 09:58:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQxjb-0000Mp-7O
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 09:58:47 +0000
Received: from [85.158.143.35:20405] by server-2.bemta-4.messagelabs.com id
	BD/CF-22268-6DBB7805; Wed, 24 Oct 2012 09:58:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1351072713!16333813!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19749 invoked from network); 24 Oct 2012 09:58:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 09:58:33 -0000
X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="15353317"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 09:58:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 10:58:32 +0100
Message-ID: <1351072711.2237.139.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Christoph Egger 
Date: Wed, 24 Oct 2012 10:58:31 +0100
In-Reply-To: <5087B6A4.6030203@amd.com>
References: <5087B6A4.6030203@amd.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] libxl: build error
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 10:36 +0100, Christoph Egger wrote:
> Hi,
> 
> I have this build error:
> 
> xl_cmdimpl.c:3724:40: error: declaration of 'reboot' shadows a global
> declaration

Did gcc tell you where the other global definition was from? reboot(2) I
suppose?

> Renaming it to '_reboot' fixes this for me.

Can you send a patch?

I don't think _reboot is a legal identifier (reserved for the
implementation or POSIX or some such). do_reboot would be ok. So would
changing main_shutdown_or_reboot to take the function pointer directly I
think.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 10:45:56 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 10:45:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQySf-0000qA-3m; Wed, 24 Oct 2012 10:45:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQySd-0000q5-W9
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 10:45:20 +0000
Received: from [85.158.143.35:14721] by server-3.bemta-4.messagelabs.com id
	41/AB-24279-FB6C7805; Wed, 24 Oct 2012 10:45:19 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1351075517!16548318!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31253 invoked from network); 24 Oct 2012 10:45:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 10:45:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="15355111"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 10:45:17 +0000
Received: from [192.168.1.30] (10.31.3.235) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 11:45:17 +0100
Message-ID: <5087C6BC.7070109@citrix.com>
Date: Wed, 24 Oct 2012 12:45:16 +0200
From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk 
References: <1350559321-19066-1-git-send-email-roger.pau@citrix.com>
	<20121022134708.GA13832@konrad-lan.dumpdata.com>
	<5086C0C8.5000306@citrix.com>
	<20121023172008.GB11787@phenom.dumpdata.com>
	<5086DD57.4000206@citrix.com>
	<20121023185049.GB20350@phenom.dumpdata.com>
In-Reply-To: <20121023185049.GB20350@phenom.dumpdata.com>
Cc: "xen-devel@lists.xen.org" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH RFC] Persistent grant maps for xen blk
	drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 23/10/12 20:50, Konrad Rzeszutek Wilk wrote:
> On Tue, Oct 23, 2012 at 08:09:27PM +0200, Roger Pau Monn=E9 wrote:
>> On 23/10/12 19:20, Konrad Rzeszutek Wilk wrote:
>>>>>> diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen=
-blkback/blkback.c
>>>>>> index c6decb9..2b982b2 100644
>>>>>> --- a/drivers/block/xen-blkback/blkback.c
>>>>>> +++ b/drivers/block/xen-blkback/blkback.c
>>>>>> @@ -78,6 +78,7 @@ struct pending_req {
>>>>>>       unsigned short          operation;
>>>>>>       int                     status;
>>>>>>       struct list_head        free_list;
>>>>>> +     unsigned int            unmap_seg[BLKIF_MAX_SEGMENTS_PER_REQUE=
ST];
>>
>> Should I change this to a bool? Since we are only setting it to 0 or 1.
> =

> I would just keep it as 'int'. Eventually we can replace this with a
> bit-map, but that can be done later.

I've already changed it to a bitmap.

>>>>> Perhaps there should be a #define for that array..
>>>>
>>>> Do you mean something like:
>>>>
>>>> #define unmap(req, i) req->unmap_seg[i]
>>>
>>> I was thinking that you just check for req->unamp_seg[i] to
>>> have an non-zero value. But since that array is just used as an check
>>> to see whether the functionality is enabled (or not), you might want
>>> to declerare the right values so:
>>> #define UNMAP_SG_ON 1
>>> #define UNMAP_SG_OFF 0
>>>
>>> or so.
>>
>> Agreed, will add the defines.
>>
>>>>>> +             if (persistent_gnts[i]) {
>>>>>> +                     if (!persistent_gnts[i]->handle) {
>>>>>> +                             /*
>>>>>> +                              * If this is a new persistent grant
>>>>>> +                              * save the handler
>>>>>> +                              */
>>>>>> +                             persistent_gnts[i]->handle =3D map[j].=
handle;
>>>>>> +                             persistent_gnts[i]->dev_bus_addr =3D
>>>>>> +                                     map[j++].dev_bus_addr;
>>>>>> +                     }
>>>>>> +                     pending_handle(pending_req, i) =3D
>>>>>> +                             persistent_gnts[i]->handle;
>>>>>> +                     pending_req->unmap_seg[i] =3D 0;
>>>>>
>>>>> Could we have a #define for that?
>>>>
>>>> Sure.
>>
>> I've used the previous macro, so it looks like:
>>
>> unmap(req, i) =3D UNMAP_SG_OFF;
>>
>> I'm not sure if this is what you meant, or if you where interested in
>> defining a set of macros like:
>>
>> #define check_unmap(req, i) req->unmap_seg[i]
>> #define unset_unmap(req, i) req->unmap_seg[i] =3D UNMAP_SG_OFF
>> #define set_unmap(req, i) req->unmap_seg[i] =3D UNMAP_SG_ON
>>
>> I would go for the first option (the unmap macro that can be used here
>> and in xen_blkbk_unmap).
> =

> I was just thinking something as simple as
> =

> 	if (reg->unmap_seg[i] =3D=3D UNMAP_SG_OFF)
> 		continue;
> =

> And the #defines are just for the hard-coded values of 0 or 1.
> =

>>
>>>>> HA! By default, eh?
>>>>
>>>> Yes, you caught me, there's a paragraph in the commit message that
>>>> explains that we are using persistent grants in the frontend
>>>> unconditionally, since the protocol is compatible (you can have a
>>>> persistent blkfront and a non-persistent blkback). It simplifies the
>>>> logic in blkfront. Are you OK with it?
>>>
>>> It is OK, but you should be checking whether the backend supports it.
>>> I don't see it checking the info->feature_persistent_grant to print
>>> that.
>>
>> I don't understand why blkfront needs to check if the backend supports
>> persisten grants, blkfront is going to use persistent grants anyway.
> =

> What if it does not (say this guest runs on an older xen-blkback?)?
> Then you would be still printing 'persistent grants' in the blkfront.

Ok, I get your point. Now blkfront will only report the use of
persistent grants if the backend supports it.

If there are no further comments I will send v2 after doing some tests,
thanks for the reviews.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 10:45:56 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 10:45:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQySf-0000qA-3m; Wed, 24 Oct 2012 10:45:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQySd-0000q5-W9
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 10:45:20 +0000
Received: from [85.158.143.35:14721] by server-3.bemta-4.messagelabs.com id
	41/AB-24279-FB6C7805; Wed, 24 Oct 2012 10:45:19 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1351075517!16548318!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31253 invoked from network); 24 Oct 2012 10:45:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 10:45:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="15355111"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 10:45:17 +0000
Received: from [192.168.1.30] (10.31.3.235) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 11:45:17 +0100
Message-ID: <5087C6BC.7070109@citrix.com>
Date: Wed, 24 Oct 2012 12:45:16 +0200
From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk 
References: <1350559321-19066-1-git-send-email-roger.pau@citrix.com>
	<20121022134708.GA13832@konrad-lan.dumpdata.com>
	<5086C0C8.5000306@citrix.com>
	<20121023172008.GB11787@phenom.dumpdata.com>
	<5086DD57.4000206@citrix.com>
	<20121023185049.GB20350@phenom.dumpdata.com>
In-Reply-To: <20121023185049.GB20350@phenom.dumpdata.com>
Cc: "xen-devel@lists.xen.org" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH RFC] Persistent grant maps for xen blk
	drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 23/10/12 20:50, Konrad Rzeszutek Wilk wrote:
> On Tue, Oct 23, 2012 at 08:09:27PM +0200, Roger Pau Monn=E9 wrote:
>> On 23/10/12 19:20, Konrad Rzeszutek Wilk wrote:
>>>>>> diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen=
-blkback/blkback.c
>>>>>> index c6decb9..2b982b2 100644
>>>>>> --- a/drivers/block/xen-blkback/blkback.c
>>>>>> +++ b/drivers/block/xen-blkback/blkback.c
>>>>>> @@ -78,6 +78,7 @@ struct pending_req {
>>>>>>       unsigned short          operation;
>>>>>>       int                     status;
>>>>>>       struct list_head        free_list;
>>>>>> +     unsigned int            unmap_seg[BLKIF_MAX_SEGMENTS_PER_REQUE=
ST];
>>
>> Should I change this to a bool? Since we are only setting it to 0 or 1.
> =

> I would just keep it as 'int'. Eventually we can replace this with a
> bit-map, but that can be done later.

I've already changed it to a bitmap.

>>>>> Perhaps there should be a #define for that array..
>>>>
>>>> Do you mean something like:
>>>>
>>>> #define unmap(req, i) req->unmap_seg[i]
>>>
>>> I was thinking that you just check for req->unamp_seg[i] to
>>> have an non-zero value. But since that array is just used as an check
>>> to see whether the functionality is enabled (or not), you might want
>>> to declerare the right values so:
>>> #define UNMAP_SG_ON 1
>>> #define UNMAP_SG_OFF 0
>>>
>>> or so.
>>
>> Agreed, will add the defines.
>>
>>>>>> +             if (persistent_gnts[i]) {
>>>>>> +                     if (!persistent_gnts[i]->handle) {
>>>>>> +                             /*
>>>>>> +                              * If this is a new persistent grant
>>>>>> +                              * save the handler
>>>>>> +                              */
>>>>>> +                             persistent_gnts[i]->handle =3D map[j].=
handle;
>>>>>> +                             persistent_gnts[i]->dev_bus_addr =3D
>>>>>> +                                     map[j++].dev_bus_addr;
>>>>>> +                     }
>>>>>> +                     pending_handle(pending_req, i) =3D
>>>>>> +                             persistent_gnts[i]->handle;
>>>>>> +                     pending_req->unmap_seg[i] =3D 0;
>>>>>
>>>>> Could we have a #define for that?
>>>>
>>>> Sure.
>>
>> I've used the previous macro, so it looks like:
>>
>> unmap(req, i) =3D UNMAP_SG_OFF;
>>
>> I'm not sure if this is what you meant, or if you where interested in
>> defining a set of macros like:
>>
>> #define check_unmap(req, i) req->unmap_seg[i]
>> #define unset_unmap(req, i) req->unmap_seg[i] =3D UNMAP_SG_OFF
>> #define set_unmap(req, i) req->unmap_seg[i] =3D UNMAP_SG_ON
>>
>> I would go for the first option (the unmap macro that can be used here
>> and in xen_blkbk_unmap).
> =

> I was just thinking something as simple as
> =

> 	if (reg->unmap_seg[i] =3D=3D UNMAP_SG_OFF)
> 		continue;
> =

> And the #defines are just for the hard-coded values of 0 or 1.
> =

>>
>>>>> HA! By default, eh?
>>>>
>>>> Yes, you caught me, there's a paragraph in the commit message that
>>>> explains that we are using persistent grants in the frontend
>>>> unconditionally, since the protocol is compatible (you can have a
>>>> persistent blkfront and a non-persistent blkback). It simplifies the
>>>> logic in blkfront. Are you OK with it?
>>>
>>> It is OK, but you should be checking whether the backend supports it.
>>> I don't see it checking the info->feature_persistent_grant to print
>>> that.
>>
>> I don't understand why blkfront needs to check if the backend supports
>> persisten grants, blkfront is going to use persistent grants anyway.
> =

> What if it does not (say this guest runs on an older xen-blkback?)?
> Then you would be still printing 'persistent grants' in the blkfront.

Ok, I get your point. Now blkfront will only report the use of
persistent grants if the backend supports it.

If there are no further comments I will send v2 after doing some tests,
thanks for the reviews.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 10:52:34 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 10:52:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQyYL-0000yd-TM; Wed, 24 Oct 2012 10:51:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQyYJ-0000yW-Cw
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 10:51:11 +0000
Received: from [85.158.137.99:34157] by server-7.bemta-3.messagelabs.com id
	01/A2-06991-E18C7805; Wed, 24 Oct 2012 10:51:10 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1351075867!20462988!1
X-Originating-IP: [65.55.88.11]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3455 invoked from network); 24 Oct 2012 10:51:09 -0000
Received: from tx2ehsobe001.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.11)
	by server-15.tower-217.messagelabs.com with AES128-SHA encrypted SMTP;
	24 Oct 2012 10:51:09 -0000
Received: from mail253-tx2-R.bigfish.com (10.9.14.243) by
	TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id
	14.1.225.23; Wed, 24 Oct 2012 10:51:07 +0000
Received: from mail253-tx2 (localhost [127.0.0.1])	by
	mail253-tx2-R.bigfish.com (Postfix) with ESMTP id BEC32168017D;
	Wed, 24 Oct 2012 10:51:06 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: -4
X-BigFish: VPS-4(zzbb2dI98dI936eIc85fh1432Ic857hzz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh34h1155h)
Received: from mail253-tx2 (localhost.localdomain [127.0.0.1]) by mail253-tx2
	(MessageSwitch) id 1351075865311379_30688;
	Wed, 24 Oct 2012 10:51:05 +0000 (UTC)
Received: from TX2EHSMHS041.bigfish.com (unknown [10.9.14.251])	by
	mail253-tx2.bigfish.com (Postfix) with ESMTP id 3F657D40043;
	Wed, 24 Oct 2012 10:51:05 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS041.bigfish.com (10.9.99.141) with Microsoft SMTP Server id
	14.1.225.23; Wed, 24 Oct 2012 10:51:04 +0000
X-WSS-ID: 0MCE8SZ-02-3L4-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2F209C8050;	Wed, 24 Oct 2012 05:50:58 -0500 (CDT)
Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 24 Oct 2012 05:51:15 -0500
Received: from STOREXDAG02.amd.com (10.1.13.11) by sausexdag03.amd.com
	(163.181.55.3) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Wed, 24 Oct 2012 05:51:02 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag02.amd.com
	(10.1.13.11) with Microsoft SMTP Server id 14.2.318.4; Wed, 24 Oct 2012
	06:51:01 -0400
Message-ID: <5087C813.8090609@amd.com>
Date: Wed, 24 Oct 2012 12:50:59 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell 
References: <5087B6A4.6030203@amd.com>
	<1351072711.2237.139.camel@zakaz.uk.xensource.com>
In-Reply-To: <1351072711.2237.139.camel@zakaz.uk.xensource.com>
Content-Type: multipart/mixed; boundary="------------010607020908010407060506"
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] libxl: build error
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------010607020908010407060506
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

On 10/24/12 11:58, Ian Campbell wrote:
> On Wed, 2012-10-24 at 10:36 +0100, Christoph Egger wrote:
>> Hi,
>>
>> I have this build error:
>>
>> xl_cmdimpl.c:3724:40: error: declaration of 'reboot' shadows a global
>> declaration
> 
> Did gcc tell you where the other global definition was from?

No.

> reboot(2) I suppose?

Yes.  has the prototype.

>> Renaming it to '_reboot' fixes this for me.
> 
> Can you send a patch?
> 
> I don't think _reboot is a legal identifier (reserved for the
> implementation or POSIX or some such). do_reboot would be ok. So would
> changing main_shutdown_or_reboot to take the function pointer directly I
> think.

patch attached.

Signed-off-by: Christoph Egger 

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------010607020908010407060506
Content-Type: text/plain; charset="us-ascii"; name="xen_tools_libxl.diff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="xen_tools_libxl.diff"
Content-Description: xen_tools_libxl.diff

ZGlmZiAtciBhYzg3MGRmNGYxNjUgdG9vbHMvbGlieGwveGxfY21kaW1wbC5jCi0tLSBhL3Rv
b2xzL2xpYnhsL3hsX2NtZGltcGwuYwlXZWQgT2N0IDI0IDA5OjUwOjUyIDIwMTIgKzAyMDAK
KysrIGIvdG9vbHMvbGlieGwveGxfY21kaW1wbC5jCVdlZCBPY3QgMjQgMTE6MTk6NTkgMjAx
MiArMDIwMApAQCAtMzcyMSwxMSArMzcyMSwxMSBAQCBpbnQgbWFpbl9kZXN0cm95KGludCBh
cmdjLCBjaGFyICoqYXJndikKICAgICByZXR1cm4gMDsKIH0KIAotc3RhdGljIGludCBtYWlu
X3NodXRkb3duX29yX3JlYm9vdChpbnQgcmVib290LCBpbnQgYXJnYywgY2hhciAqKmFyZ3Yp
CitzdGF0aWMgaW50IG1haW5fc2h1dGRvd25fb3JfcmVib290KGludCBkb19yZWJvb3QsIGlu
dCBhcmdjLCBjaGFyICoqYXJndikKIHsKICAgICB2b2lkICgqZm4pKHVpbnQzMl90IGRvbWlk
LAogICAgICAgICAgICAgICAgbGlieGxfZXZnZW5fZG9tYWluX2RlYXRoICoqLCBsaWJ4bF9l
dl91c2VyLCBpbnQpID0KLSAgICAgICAgcmVib290ID8gJnJlYm9vdF9kb21haW4gOiAmc2h1
dGRvd25fZG9tYWluOworICAgICAgICBkb19yZWJvb3QgPyAmcmVib290X2RvbWFpbiA6ICZz
aHV0ZG93bl9kb21haW47CiAgICAgaW50IG9wdCwgaSwgbmJfZG9tYWluOwogICAgIGludCB3
YWl0X2Zvcl9pdCA9IDAsIGFsbCA9MDsKICAgICBpbnQgZmFsbGJhY2tfdHJpZ2dlciA9IDA7
Cg==
--------------010607020908010407060506
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------010607020908010407060506--


From xen-devel-bounces@lists.xen.org Wed Oct 24 10:52:34 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 10:52:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQyYL-0000yd-TM; Wed, 24 Oct 2012 10:51:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQyYJ-0000yW-Cw
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 10:51:11 +0000
Received: from [85.158.137.99:34157] by server-7.bemta-3.messagelabs.com id
	01/A2-06991-E18C7805; Wed, 24 Oct 2012 10:51:10 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1351075867!20462988!1
X-Originating-IP: [65.55.88.11]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3455 invoked from network); 24 Oct 2012 10:51:09 -0000
Received: from tx2ehsobe001.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.11)
	by server-15.tower-217.messagelabs.com with AES128-SHA encrypted SMTP;
	24 Oct 2012 10:51:09 -0000
Received: from mail253-tx2-R.bigfish.com (10.9.14.243) by
	TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id
	14.1.225.23; Wed, 24 Oct 2012 10:51:07 +0000
Received: from mail253-tx2 (localhost [127.0.0.1])	by
	mail253-tx2-R.bigfish.com (Postfix) with ESMTP id BEC32168017D;
	Wed, 24 Oct 2012 10:51:06 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: -4
X-BigFish: VPS-4(zzbb2dI98dI936eIc85fh1432Ic857hzz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh34h1155h)
Received: from mail253-tx2 (localhost.localdomain [127.0.0.1]) by mail253-tx2
	(MessageSwitch) id 1351075865311379_30688;
	Wed, 24 Oct 2012 10:51:05 +0000 (UTC)
Received: from TX2EHSMHS041.bigfish.com (unknown [10.9.14.251])	by
	mail253-tx2.bigfish.com (Postfix) with ESMTP id 3F657D40043;
	Wed, 24 Oct 2012 10:51:05 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS041.bigfish.com (10.9.99.141) with Microsoft SMTP Server id
	14.1.225.23; Wed, 24 Oct 2012 10:51:04 +0000
X-WSS-ID: 0MCE8SZ-02-3L4-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2F209C8050;	Wed, 24 Oct 2012 05:50:58 -0500 (CDT)
Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 24 Oct 2012 05:51:15 -0500
Received: from STOREXDAG02.amd.com (10.1.13.11) by sausexdag03.amd.com
	(163.181.55.3) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Wed, 24 Oct 2012 05:51:02 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag02.amd.com
	(10.1.13.11) with Microsoft SMTP Server id 14.2.318.4; Wed, 24 Oct 2012
	06:51:01 -0400
Message-ID: <5087C813.8090609@amd.com>
Date: Wed, 24 Oct 2012 12:50:59 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell 
References: <5087B6A4.6030203@amd.com>
	<1351072711.2237.139.camel@zakaz.uk.xensource.com>
In-Reply-To: <1351072711.2237.139.camel@zakaz.uk.xensource.com>
Content-Type: multipart/mixed; boundary="------------010607020908010407060506"
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] libxl: build error
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------010607020908010407060506
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

On 10/24/12 11:58, Ian Campbell wrote:
> On Wed, 2012-10-24 at 10:36 +0100, Christoph Egger wrote:
>> Hi,
>>
>> I have this build error:
>>
>> xl_cmdimpl.c:3724:40: error: declaration of 'reboot' shadows a global
>> declaration
> 
> Did gcc tell you where the other global definition was from?

No.

> reboot(2) I suppose?

Yes.  has the prototype.

>> Renaming it to '_reboot' fixes this for me.
> 
> Can you send a patch?
> 
> I don't think _reboot is a legal identifier (reserved for the
> implementation or POSIX or some such). do_reboot would be ok. So would
> changing main_shutdown_or_reboot to take the function pointer directly I
> think.

patch attached.

Signed-off-by: Christoph Egger 

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------010607020908010407060506
Content-Type: text/plain; charset="us-ascii"; name="xen_tools_libxl.diff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="xen_tools_libxl.diff"
Content-Description: xen_tools_libxl.diff

ZGlmZiAtciBhYzg3MGRmNGYxNjUgdG9vbHMvbGlieGwveGxfY21kaW1wbC5jCi0tLSBhL3Rv
b2xzL2xpYnhsL3hsX2NtZGltcGwuYwlXZWQgT2N0IDI0IDA5OjUwOjUyIDIwMTIgKzAyMDAK
KysrIGIvdG9vbHMvbGlieGwveGxfY21kaW1wbC5jCVdlZCBPY3QgMjQgMTE6MTk6NTkgMjAx
MiArMDIwMApAQCAtMzcyMSwxMSArMzcyMSwxMSBAQCBpbnQgbWFpbl9kZXN0cm95KGludCBh
cmdjLCBjaGFyICoqYXJndikKICAgICByZXR1cm4gMDsKIH0KIAotc3RhdGljIGludCBtYWlu
X3NodXRkb3duX29yX3JlYm9vdChpbnQgcmVib290LCBpbnQgYXJnYywgY2hhciAqKmFyZ3Yp
CitzdGF0aWMgaW50IG1haW5fc2h1dGRvd25fb3JfcmVib290KGludCBkb19yZWJvb3QsIGlu
dCBhcmdjLCBjaGFyICoqYXJndikKIHsKICAgICB2b2lkICgqZm4pKHVpbnQzMl90IGRvbWlk
LAogICAgICAgICAgICAgICAgbGlieGxfZXZnZW5fZG9tYWluX2RlYXRoICoqLCBsaWJ4bF9l
dl91c2VyLCBpbnQpID0KLSAgICAgICAgcmVib290ID8gJnJlYm9vdF9kb21haW4gOiAmc2h1
dGRvd25fZG9tYWluOworICAgICAgICBkb19yZWJvb3QgPyAmcmVib290X2RvbWFpbiA6ICZz
aHV0ZG93bl9kb21haW47CiAgICAgaW50IG9wdCwgaSwgbmJfZG9tYWluOwogICAgIGludCB3
YWl0X2Zvcl9pdCA9IDAsIGFsbCA9MDsKICAgICBpbnQgZmFsbGJhY2tfdHJpZ2dlciA9IDA7
Cg==
--------------010607020908010407060506
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------010607020908010407060506--


From xen-devel-bounces@lists.xen.org Wed Oct 24 11:02:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 11:02:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQyiT-0001AP-0Y; Wed, 24 Oct 2012 11:01:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQyiS-0001AK-8p
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 11:01:40 +0000
Received: from [85.158.139.211:50193] by server-14.bemta-5.messagelabs.com id
	D9/AE-21768-39AC7805; Wed, 24 Oct 2012 11:01:39 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1351076498!23545889!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24342 invoked from network); 24 Oct 2012 11:01:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 11:01:39 -0000
X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="15355518"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 11:01:38 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 24 Oct 2012 12:01:38 +0100
Date: Wed, 24 Oct 2012 12:01:09 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Konrad Rzeszutek Wilk 
In-Reply-To: <1351015931-16991-3-git-send-email-konrad.wilk@oracle.com>
Message-ID: 
References: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
	<1351015931-16991-3-git-send-email-konrad.wilk@oracle.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Ian Campbell ,
	"xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 02/10] xen/pvh: Fix PVHVM 32-bit bootup
	problems.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 23 Oct 2012, Konrad Rzeszutek Wilk wrote:
> With the split of the 'unsigned int space' in a 'u16 space'
> and 'u16 foreign_domid' in xen_add_to_physmap the compiler
> won't write the full 32-bit value in 'space'. Instead
> it will write a 16-bit value - which is OK. The problem
> is that we allocate the xen_add_to_physmap structure from
> the stack which can (and it has) various garbage on it.
> 
> The end result is that without this patch we end up
> providing this to the hypervisor:
> 
>    xatp.space = 0xc1310001;
> instead of:
>    xatp.space = 0x1;
> 
> Forcing the foreign_domid to 0, will over-write the garbage
> that was on the stack.
> 
> Signed-off-by: Konrad Rzeszutek Wilk 

Good fix.


>  arch/x86/xen/enlighten.c  |    1 +
>  drivers/xen/grant-table.c |    1 +
>  2 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index e3497f2..b679f86 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -1509,6 +1509,7 @@ void __ref xen_hvm_init_shared_info(void)
>  	xatp.domid = DOMID_SELF;
>  	xatp.idx = 0;
>  	xatp.space = XENMAPSPACE_shared_info;
> +	xatp.foreign_domid = 0;
>  	xatp.gpfn = __pa(shared_info_page) >> PAGE_SHIFT;
>  	if (HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp))
>  		BUG();
> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> index b2b0a37..cbfd929 100644
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -1044,6 +1044,7 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
>  		do {
>  			xatp.domid = DOMID_SELF;
>  			xatp.idx = i;
> +			xatp.foreign_domid = 0;
>  			xatp.space = XENMAPSPACE_grant_table;
>  			xatp.gpfn = (xen_hvm_resume_frames >> PAGE_SHIFT) + i;
>  			rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
> -- 
> 1.7.7.6
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 11:02:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 11:02:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQyiT-0001AP-0Y; Wed, 24 Oct 2012 11:01:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQyiS-0001AK-8p
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 11:01:40 +0000
Received: from [85.158.139.211:50193] by server-14.bemta-5.messagelabs.com id
	D9/AE-21768-39AC7805; Wed, 24 Oct 2012 11:01:39 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1351076498!23545889!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24342 invoked from network); 24 Oct 2012 11:01:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 11:01:39 -0000
X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="15355518"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 11:01:38 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 24 Oct 2012 12:01:38 +0100
Date: Wed, 24 Oct 2012 12:01:09 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Konrad Rzeszutek Wilk 
In-Reply-To: <1351015931-16991-3-git-send-email-konrad.wilk@oracle.com>
Message-ID: 
References: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
	<1351015931-16991-3-git-send-email-konrad.wilk@oracle.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Ian Campbell ,
	"xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 02/10] xen/pvh: Fix PVHVM 32-bit bootup
	problems.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 23 Oct 2012, Konrad Rzeszutek Wilk wrote:
> With the split of the 'unsigned int space' in a 'u16 space'
> and 'u16 foreign_domid' in xen_add_to_physmap the compiler
> won't write the full 32-bit value in 'space'. Instead
> it will write a 16-bit value - which is OK. The problem
> is that we allocate the xen_add_to_physmap structure from
> the stack which can (and it has) various garbage on it.
> 
> The end result is that without this patch we end up
> providing this to the hypervisor:
> 
>    xatp.space = 0xc1310001;
> instead of:
>    xatp.space = 0x1;
> 
> Forcing the foreign_domid to 0, will over-write the garbage
> that was on the stack.
> 
> Signed-off-by: Konrad Rzeszutek Wilk 

Good fix.


>  arch/x86/xen/enlighten.c  |    1 +
>  drivers/xen/grant-table.c |    1 +
>  2 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index e3497f2..b679f86 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -1509,6 +1509,7 @@ void __ref xen_hvm_init_shared_info(void)
>  	xatp.domid = DOMID_SELF;
>  	xatp.idx = 0;
>  	xatp.space = XENMAPSPACE_shared_info;
> +	xatp.foreign_domid = 0;
>  	xatp.gpfn = __pa(shared_info_page) >> PAGE_SHIFT;
>  	if (HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp))
>  		BUG();
> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> index b2b0a37..cbfd929 100644
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -1044,6 +1044,7 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
>  		do {
>  			xatp.domid = DOMID_SELF;
>  			xatp.idx = i;
> +			xatp.foreign_domid = 0;
>  			xatp.space = XENMAPSPACE_grant_table;
>  			xatp.gpfn = (xen_hvm_resume_frames >> PAGE_SHIFT) + i;
>  			rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
> -- 
> 1.7.7.6
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 11:04:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 11:04:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQyjz-0001H0-Fy; Wed, 24 Oct 2012 11:03:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQyjy-0001Gs-CV
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 11:03:14 +0000
Received: from [85.158.139.211:16182] by server-3.bemta-5.messagelabs.com id
	59/5C-28618-1FAC7805; Wed, 24 Oct 2012 11:03:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1351076593!23546199!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30414 invoked from network); 24 Oct 2012 11:03:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 11:03:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="15355559"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 11:03:13 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 24 Oct 2012 12:03:12 +0100
Date: Wed, 24 Oct 2012 12:02:43 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1351071622.2237.130.camel@zakaz.uk.xensource.com>
Message-ID: 
References: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
	<1351015931-16991-4-git-send-email-konrad.wilk@oracle.com>
	<1351071622.2237.130.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Stefano Stabellini ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 03/10] xen/hypercall: Make
 xen_remove_from_physmap the same on 64/32 builds.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 24 Oct 2012, Ian Campbell wrote:
> On Tue, 2012-10-23 at 19:12 +0100, Konrad Rzeszutek Wilk wrote:
> > By making the structure exactly the same size and with the same
> > offsets on 64 and 32-bit builds we are future-proofing ourselves.
> > 
> > Signed-off-by: Konrad Rzeszutek Wilk 
> > ---
> >  include/xen/interface/memory.h |    7 ++++++-
> >  1 files changed, 6 insertions(+), 1 deletions(-)
> > 
> > diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
> > index 8beebdb..6b07b54 100644
> > --- a/include/xen/interface/memory.h
> > +++ b/include/xen/interface/memory.h
> > @@ -253,9 +253,14 @@ extern spinlock_t xen_reservation_lock;
> >  struct xen_remove_from_physmap {
> >      /* Which domain to change the mapping for. */
> >      domid_t domid;
> > -
> > +   /* To be used in the future if need to. */
> > +    uint8_t reserved[6];
> >      /* GPFN of the current mapping of the page. */
> >      xen_pfn_t gpfn;
> > +#ifdef CONFIG_X86_32
> > +    /* No need to do that on ARM as xen_pfn_t is always 8 bytes. */
> > +    uint8_t __pad[4];
> > +#endif
> 
> I'm not sure if this last one is necessary since this isn't a struct
> which would get used in an array. I guess it doesn't hurt though.

That's right, I don't think that the last padding is actually necessary.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 11:04:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 11:04:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQyjz-0001H0-Fy; Wed, 24 Oct 2012 11:03:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQyjy-0001Gs-CV
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 11:03:14 +0000
Received: from [85.158.139.211:16182] by server-3.bemta-5.messagelabs.com id
	59/5C-28618-1FAC7805; Wed, 24 Oct 2012 11:03:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1351076593!23546199!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30414 invoked from network); 24 Oct 2012 11:03:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 11:03:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="15355559"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 11:03:13 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 24 Oct 2012 12:03:12 +0100
Date: Wed, 24 Oct 2012 12:02:43 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1351071622.2237.130.camel@zakaz.uk.xensource.com>
Message-ID: 
References: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
	<1351015931-16991-4-git-send-email-konrad.wilk@oracle.com>
	<1351071622.2237.130.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Stefano Stabellini ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 03/10] xen/hypercall: Make
 xen_remove_from_physmap the same on 64/32 builds.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 24 Oct 2012, Ian Campbell wrote:
> On Tue, 2012-10-23 at 19:12 +0100, Konrad Rzeszutek Wilk wrote:
> > By making the structure exactly the same size and with the same
> > offsets on 64 and 32-bit builds we are future-proofing ourselves.
> > 
> > Signed-off-by: Konrad Rzeszutek Wilk 
> > ---
> >  include/xen/interface/memory.h |    7 ++++++-
> >  1 files changed, 6 insertions(+), 1 deletions(-)
> > 
> > diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
> > index 8beebdb..6b07b54 100644
> > --- a/include/xen/interface/memory.h
> > +++ b/include/xen/interface/memory.h
> > @@ -253,9 +253,14 @@ extern spinlock_t xen_reservation_lock;
> >  struct xen_remove_from_physmap {
> >      /* Which domain to change the mapping for. */
> >      domid_t domid;
> > -
> > +   /* To be used in the future if need to. */
> > +    uint8_t reserved[6];
> >      /* GPFN of the current mapping of the page. */
> >      xen_pfn_t gpfn;
> > +#ifdef CONFIG_X86_32
> > +    /* No need to do that on ARM as xen_pfn_t is always 8 bytes. */
> > +    uint8_t __pad[4];
> > +#endif
> 
> I'm not sure if this last one is necessary since this isn't a struct
> which would get used in an array. I guess it doesn't hurt though.

That's right, I don't think that the last padding is actually necessary.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 11:17:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 11:17:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQywe-0001XA-VR; Wed, 24 Oct 2012 11:16:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQywe-0001X5-CU
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 11:16:20 +0000
Received: from [85.158.137.99:40971] by server-4.bemta-3.messagelabs.com id
	EF/84-01405-30EC7805; Wed, 24 Oct 2012 11:16:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1351077378!19713753!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1711 invoked from network); 24 Oct 2012 11:16:18 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-217.messagelabs.com with SMTP;
	24 Oct 2012 11:16:18 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 24 Oct 2012 12:16:18 +0100
Message-Id: <5087EA1F02000078000A3EAE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 24 Oct 2012 12:16:15 +0100
From: "Jan Beulich" 
To: "Christoph Egger" 
References: <5087B6A4.6030203@amd.com>
	<1351072711.2237.139.camel@zakaz.uk.xensource.com>
	<5087C813.8090609@amd.com>
In-Reply-To: <5087C813.8090609@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] libxl: build error
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 24.10.12 at 12:50, Christoph Egger  wrote:
> On 10/24/12 11:58, Ian Campbell wrote:
>> On Wed, 2012-10-24 at 10:36 +0100, Christoph Egger wrote:
>>> Hi,
>>>
>>> I have this build error:
>>>
>>> xl_cmdimpl.c:3724:40: error: declaration of 'reboot' shadows a global
>>> declaration
>> 
>> Did gcc tell you where the other global definition was from?
> 
> No.
> 
>> reboot(2) I suppose?
> 
> Yes.  has the prototype.

Afaict that's a mistake of whatever provides this header on your
system - there's no unconditionally visible "reboot" in the specs
I have available.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 11:17:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 11:17:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQywe-0001XA-VR; Wed, 24 Oct 2012 11:16:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQywe-0001X5-CU
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 11:16:20 +0000
Received: from [85.158.137.99:40971] by server-4.bemta-3.messagelabs.com id
	EF/84-01405-30EC7805; Wed, 24 Oct 2012 11:16:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1351077378!19713753!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1711 invoked from network); 24 Oct 2012 11:16:18 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-217.messagelabs.com with SMTP;
	24 Oct 2012 11:16:18 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 24 Oct 2012 12:16:18 +0100
Message-Id: <5087EA1F02000078000A3EAE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 24 Oct 2012 12:16:15 +0100
From: "Jan Beulich" 
To: "Christoph Egger" 
References: <5087B6A4.6030203@amd.com>
	<1351072711.2237.139.camel@zakaz.uk.xensource.com>
	<5087C813.8090609@amd.com>
In-Reply-To: <5087C813.8090609@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] libxl: build error
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 24.10.12 at 12:50, Christoph Egger  wrote:
> On 10/24/12 11:58, Ian Campbell wrote:
>> On Wed, 2012-10-24 at 10:36 +0100, Christoph Egger wrote:
>>> Hi,
>>>
>>> I have this build error:
>>>
>>> xl_cmdimpl.c:3724:40: error: declaration of 'reboot' shadows a global
>>> declaration
>> 
>> Did gcc tell you where the other global definition was from?
> 
> No.
> 
>> reboot(2) I suppose?
> 
> Yes.  has the prototype.

Afaict that's a mistake of whatever provides this header on your
system - there's no unconditionally visible "reboot" in the specs
I have available.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 11:29:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 11:29:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQz8I-0001hV-7x; Wed, 24 Oct 2012 11:28:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQz8G-0001hQ-W2
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 11:28:21 +0000
Received: from [85.158.138.51:54107] by server-8.bemta-3.messagelabs.com id
	CC/41-10525-FC0D7805; Wed, 24 Oct 2012 11:28:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1351078094!33911080!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23476 invoked from network); 24 Oct 2012 11:28:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 11:28:15 -0000
X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="15356151"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 11:28:11 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 12:28:11 +0100
Message-ID: <1351078090.18035.4.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Jan Beulich 
Date: Wed, 24 Oct 2012 12:28:10 +0100
In-Reply-To: <5087EA1F02000078000A3EAE@nat28.tlf.novell.com>
References: <5087B6A4.6030203@amd.com>
	<1351072711.2237.139.camel@zakaz.uk.xensource.com>
	<5087C813.8090609@amd.com>
	<5087EA1F02000078000A3EAE@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Christoph Egger ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] libxl: build error
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 12:16 +0100, Jan Beulich wrote:
> >>> On 24.10.12 at 12:50, Christoph Egger  wrote:
> > On 10/24/12 11:58, Ian Campbell wrote:
> >> On Wed, 2012-10-24 at 10:36 +0100, Christoph Egger wrote:
> >>> Hi,
> >>>
> >>> I have this build error:
> >>>
> >>> xl_cmdimpl.c:3724:40: error: declaration of 'reboot' shadows a global
> >>> declaration
> >> 
> >> Did gcc tell you where the other global definition was from?
> > 
> > No.
> > 
> >> reboot(2) I suppose?
> > 
> > Yes.  has the prototype.
> 
> Afaict that's a mistake of whatever provides this header on your
> system - there's no unconditionally visible "reboot" in the specs
> I have available.

Indeed, on Linux it is documented as requiring:
     #include 
     #include 

(or sometimes linux/reboot.h).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 11:29:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 11:29:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQz8I-0001hV-7x; Wed, 24 Oct 2012 11:28:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQz8G-0001hQ-W2
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 11:28:21 +0000
Received: from [85.158.138.51:54107] by server-8.bemta-3.messagelabs.com id
	CC/41-10525-FC0D7805; Wed, 24 Oct 2012 11:28:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1351078094!33911080!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23476 invoked from network); 24 Oct 2012 11:28:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 11:28:15 -0000
X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="15356151"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 11:28:11 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 12:28:11 +0100
Message-ID: <1351078090.18035.4.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Jan Beulich 
Date: Wed, 24 Oct 2012 12:28:10 +0100
In-Reply-To: <5087EA1F02000078000A3EAE@nat28.tlf.novell.com>
References: <5087B6A4.6030203@amd.com>
	<1351072711.2237.139.camel@zakaz.uk.xensource.com>
	<5087C813.8090609@amd.com>
	<5087EA1F02000078000A3EAE@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Christoph Egger ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] libxl: build error
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 12:16 +0100, Jan Beulich wrote:
> >>> On 24.10.12 at 12:50, Christoph Egger  wrote:
> > On 10/24/12 11:58, Ian Campbell wrote:
> >> On Wed, 2012-10-24 at 10:36 +0100, Christoph Egger wrote:
> >>> Hi,
> >>>
> >>> I have this build error:
> >>>
> >>> xl_cmdimpl.c:3724:40: error: declaration of 'reboot' shadows a global
> >>> declaration
> >> 
> >> Did gcc tell you where the other global definition was from?
> > 
> > No.
> > 
> >> reboot(2) I suppose?
> > 
> > Yes.  has the prototype.
> 
> Afaict that's a mistake of whatever provides this header on your
> system - there's no unconditionally visible "reboot" in the specs
> I have available.

Indeed, on Linux it is documented as requiring:
     #include 
     #include 

(or sometimes linux/reboot.h).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 11:39:56 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 11:39:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQzJ7-0001ti-Eg; Wed, 24 Oct 2012 11:39:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQzJ5-0001td-T8
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 11:39:32 +0000
Received: from [85.158.138.51:23424] by server-1.bemta-3.messagelabs.com id
	BD/62-31728-373D7805; Wed, 24 Oct 2012 11:39:31 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1351078768!26725348!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzg3MDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12911 invoked from network); 24 Oct 2012 11:39:30 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 11:39:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="42260276"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 11:39:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 07:39:28 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TQzJ1-0003A5-KP;
	Wed, 24 Oct 2012 12:39:27 +0100
From: David Vrabel 
To: xen-devel@lists.xen.org
Date: Wed, 24 Oct 2012 12:39:02 +0100
Message-ID: <1351078742-27994-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: David Vrabel , stable@vger.kernel.org,
	Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH] xen/gntdev: don't leak memory from
	IOCTL_GNTDEV_MAP_GRANT_REF
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel 

map->kmap_ops allocated in gntdev_alloc_map() wasn't freed by
gntdev_put_map().

Add a gntdev_free_map() helper function to free everything allocated
by gntdev_alloc_map().

Signed-off-by: David Vrabel 
Cc: stable@vger.kernel.org
---
 drivers/xen/gntdev.c |   36 +++++++++++++++++++-----------------
 1 files changed, 19 insertions(+), 17 deletions(-)

diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 610bfc6..2e22df2 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -105,6 +105,21 @@ static void gntdev_print_maps(struct gntdev_priv *priv,
 #endif
 }
 
+static void gntdev_free_map(struct grant_map *map)
+{
+	if (map == NULL)
+		return;
+
+	if (map->pages)
+		free_xenballooned_pages(map->count, map->pages);
+	kfree(map->pages);
+	kfree(map->grants);
+	kfree(map->map_ops);
+	kfree(map->unmap_ops);
+	kfree(map->kmap_ops);
+	kfree(map);
+}
+
 static struct grant_map *gntdev_alloc_map(struct gntdev_priv *priv, int count)
 {
 	struct grant_map *add;
@@ -142,12 +157,7 @@ static struct grant_map *gntdev_alloc_map(struct gntdev_priv *priv, int count)
 	return add;
 
 err:
-	kfree(add->pages);
-	kfree(add->grants);
-	kfree(add->map_ops);
-	kfree(add->unmap_ops);
-	kfree(add->kmap_ops);
-	kfree(add);
+	gntdev_free_map(add);
 	return NULL;
 }
 
@@ -198,17 +208,9 @@ static void gntdev_put_map(struct grant_map *map)
 		evtchn_put(map->notify.event);
 	}
 
-	if (map->pages) {
-		if (!use_ptemod)
-			unmap_grant_pages(map, 0, map->count);
-
-		free_xenballooned_pages(map->count, map->pages);
-	}
-	kfree(map->pages);
-	kfree(map->grants);
-	kfree(map->map_ops);
-	kfree(map->unmap_ops);
-	kfree(map);
+	if (map->pages && !use_ptemod)
+		unmap_grant_pages(map, 0, map->count);
+	gntdev_free_map(map);
 }
 
 /* ------------------------------------------------------------------ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 11:39:56 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 11:39:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQzJ7-0001ti-Eg; Wed, 24 Oct 2012 11:39:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQzJ5-0001td-T8
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 11:39:32 +0000
Received: from [85.158.138.51:23424] by server-1.bemta-3.messagelabs.com id
	BD/62-31728-373D7805; Wed, 24 Oct 2012 11:39:31 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1351078768!26725348!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzg3MDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12911 invoked from network); 24 Oct 2012 11:39:30 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 11:39:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="42260276"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 11:39:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 07:39:28 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TQzJ1-0003A5-KP;
	Wed, 24 Oct 2012 12:39:27 +0100
From: David Vrabel 
To: xen-devel@lists.xen.org
Date: Wed, 24 Oct 2012 12:39:02 +0100
Message-ID: <1351078742-27994-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: David Vrabel , stable@vger.kernel.org,
	Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH] xen/gntdev: don't leak memory from
	IOCTL_GNTDEV_MAP_GRANT_REF
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel 

map->kmap_ops allocated in gntdev_alloc_map() wasn't freed by
gntdev_put_map().

Add a gntdev_free_map() helper function to free everything allocated
by gntdev_alloc_map().

Signed-off-by: David Vrabel 
Cc: stable@vger.kernel.org
---
 drivers/xen/gntdev.c |   36 +++++++++++++++++++-----------------
 1 files changed, 19 insertions(+), 17 deletions(-)

diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 610bfc6..2e22df2 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -105,6 +105,21 @@ static void gntdev_print_maps(struct gntdev_priv *priv,
 #endif
 }
 
+static void gntdev_free_map(struct grant_map *map)
+{
+	if (map == NULL)
+		return;
+
+	if (map->pages)
+		free_xenballooned_pages(map->count, map->pages);
+	kfree(map->pages);
+	kfree(map->grants);
+	kfree(map->map_ops);
+	kfree(map->unmap_ops);
+	kfree(map->kmap_ops);
+	kfree(map);
+}
+
 static struct grant_map *gntdev_alloc_map(struct gntdev_priv *priv, int count)
 {
 	struct grant_map *add;
@@ -142,12 +157,7 @@ static struct grant_map *gntdev_alloc_map(struct gntdev_priv *priv, int count)
 	return add;
 
 err:
-	kfree(add->pages);
-	kfree(add->grants);
-	kfree(add->map_ops);
-	kfree(add->unmap_ops);
-	kfree(add->kmap_ops);
-	kfree(add);
+	gntdev_free_map(add);
 	return NULL;
 }
 
@@ -198,17 +208,9 @@ static void gntdev_put_map(struct grant_map *map)
 		evtchn_put(map->notify.event);
 	}
 
-	if (map->pages) {
-		if (!use_ptemod)
-			unmap_grant_pages(map, 0, map->count);
-
-		free_xenballooned_pages(map->count, map->pages);
-	}
-	kfree(map->pages);
-	kfree(map->grants);
-	kfree(map->map_ops);
-	kfree(map->unmap_ops);
-	kfree(map);
+	if (map->pages && !use_ptemod)
+		unmap_grant_pages(map, 0, map->count);
+	gntdev_free_map(map);
 }
 
 /* ------------------------------------------------------------------ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 11:43:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 11:43:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQzLq-0001zb-0i; Wed, 24 Oct 2012 11:42:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQzLo-0001zR-6E
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 11:42:20 +0000
Received: from [85.158.139.211:38478] by server-14.bemta-5.messagelabs.com id
	C3/E2-21768-B14D7805; Wed, 24 Oct 2012 11:42:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1351078937!23526771!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODQ2NzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14230 invoked from network); 24 Oct 2012 11:42:18 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 11:42:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="212282651"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 11:42:17 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 07:42:16 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TQzLk-0003Df-Bt;
	Wed, 24 Oct 2012 12:42:16 +0100
From: Ian Campbell 
To: netdev@vger.kernel.org
Date: Wed, 24 Oct 2012 12:42:16 +0100
Message-ID: <1351078936-14159-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Eric Dumazet , xen-devel@lists.xen.org,
	Ian Campbell ,
	Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH] net: allow configuration of the size of page in
	__netdev_alloc_frag
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The commit 69b08f62e174 "net: use bigger pages in __netdev_alloc_frag"
lead to 70%+ packet loss under Xen when transmitting from physical (as
opposed to virtual) network devices.

This is because under Xen pages which are contiguous in the physical
address space may not be contiguous in the DMA space, in fact it is
very likely that they are not. I think there are other architectures
where this is true, although perhaps non quite so aggressive as to
have this property at a per-order-0-page granularity.

The real underlying bug here most likely lies in the swiotlb not
correctly handling compound pages, and Konrad is investigating this.
However even with the swiotlb issue fixed the current arrangement
seems likely to result in a lot of bounce buffering which seems likely
to more than offset any benefit from the use of larger pages.

Therefore make NETDEV_FRAG_PAGE_MAX_ORDER configurable at runtime and
use this to request order-0 frags under Xen. Also expose this setting
via sysctl.

Signed-off-by: Ian Campbell 
Cc: Eric Dumazet 
Cc: Konrad Rzeszutek Wilk 
Cc: netdev@vger.kernel.org
Cc: xen-devel@lists.xen.org
---
 arch/x86/xen/setup.c       |    7 +++++++
 include/linux/skbuff.h     |    2 ++
 net/core/skbuff.c          |    7 ++++---
 net/core/sysctl_net_core.c |    7 +++++++
 4 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 8971a26..ad14d46 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -555,6 +556,12 @@ void __init xen_arch_setup(void)
 	       MAX_GUEST_CMDLINE > COMMAND_LINE_SIZE ?
 	       COMMAND_LINE_SIZE : MAX_GUEST_CMDLINE);
 
+	/*
+	 * Xen cannot handle DMA to/from compound pages so avoid
+	 * bounce buffering by not allocating large network frags.
+	 */
+	netdev_frag_page_max_order = 0;
+
 	/* Set up idle, making sure it calls safe_halt() pvop */
 #ifdef CONFIG_X86_32
 	boot_cpu_data.hlt_works_ok = 1;
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 6a2c34e..a3a748f 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -1719,6 +1719,8 @@ static inline void __skb_queue_purge(struct sk_buff_head *list)
 		kfree_skb(skb);
 }
 
+extern int netdev_frag_page_max_order;
+
 extern void *netdev_alloc_frag(unsigned int fragsz);
 
 extern struct sk_buff *__netdev_alloc_skb(struct net_device *dev,
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 6e04b1f..88cbe5f 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -348,8 +348,9 @@ struct netdev_alloc_cache {
 };
 static DEFINE_PER_CPU(struct netdev_alloc_cache, netdev_alloc_cache);
 
-#define NETDEV_FRAG_PAGE_MAX_ORDER get_order(32768)
-#define NETDEV_FRAG_PAGE_MAX_SIZE  (PAGE_SIZE << NETDEV_FRAG_PAGE_MAX_ORDER)
+int netdev_frag_page_max_order __read_mostly = get_order(32768);
+
+#define NETDEV_FRAG_PAGE_MAX_SIZE  (PAGE_SIZE << netdev_frag_page_max_order)
 #define NETDEV_PAGECNT_MAX_BIAS	   NETDEV_FRAG_PAGE_MAX_SIZE
 
 static void *__netdev_alloc_frag(unsigned int fragsz, gfp_t gfp_mask)
@@ -363,7 +364,7 @@ static void *__netdev_alloc_frag(unsigned int fragsz, gfp_t gfp_mask)
 	nc = &__get_cpu_var(netdev_alloc_cache);
 	if (unlikely(!nc->frag.page)) {
 refill:
-		for (order = NETDEV_FRAG_PAGE_MAX_ORDER; ;) {
+		for (order = netdev_frag_page_max_order; ;) {
 			gfp_t gfp = gfp_mask;
 
 			if (order)
diff --git a/net/core/sysctl_net_core.c b/net/core/sysctl_net_core.c
index a7c3684..e5ab6df 100644
--- a/net/core/sysctl_net_core.c
+++ b/net/core/sysctl_net_core.c
@@ -129,6 +129,13 @@ static struct ctl_table net_core_table[] = {
 		.mode		= 0644,
 		.proc_handler	= proc_dointvec
 	},
+	{
+		.procname	= "netdev_frag_page_max_order",
+		.data		= &netdev_frag_page_max_order,
+		.maxlen		= sizeof(int),
+		.mode		= 0644,
+		.proc_handler	= proc_dointvec
+	},
 #ifdef CONFIG_BPF_JIT
 	{
 		.procname	= "bpf_jit_enable",
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 11:43:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 11:43:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQzLq-0001zb-0i; Wed, 24 Oct 2012 11:42:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQzLo-0001zR-6E
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 11:42:20 +0000
Received: from [85.158.139.211:38478] by server-14.bemta-5.messagelabs.com id
	C3/E2-21768-B14D7805; Wed, 24 Oct 2012 11:42:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1351078937!23526771!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODQ2NzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14230 invoked from network); 24 Oct 2012 11:42:18 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 11:42:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="212282651"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 11:42:17 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 07:42:16 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TQzLk-0003Df-Bt;
	Wed, 24 Oct 2012 12:42:16 +0100
From: Ian Campbell 
To: netdev@vger.kernel.org
Date: Wed, 24 Oct 2012 12:42:16 +0100
Message-ID: <1351078936-14159-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Eric Dumazet , xen-devel@lists.xen.org,
	Ian Campbell ,
	Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH] net: allow configuration of the size of page in
	__netdev_alloc_frag
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The commit 69b08f62e174 "net: use bigger pages in __netdev_alloc_frag"
lead to 70%+ packet loss under Xen when transmitting from physical (as
opposed to virtual) network devices.

This is because under Xen pages which are contiguous in the physical
address space may not be contiguous in the DMA space, in fact it is
very likely that they are not. I think there are other architectures
where this is true, although perhaps non quite so aggressive as to
have this property at a per-order-0-page granularity.

The real underlying bug here most likely lies in the swiotlb not
correctly handling compound pages, and Konrad is investigating this.
However even with the swiotlb issue fixed the current arrangement
seems likely to result in a lot of bounce buffering which seems likely
to more than offset any benefit from the use of larger pages.

Therefore make NETDEV_FRAG_PAGE_MAX_ORDER configurable at runtime and
use this to request order-0 frags under Xen. Also expose this setting
via sysctl.

Signed-off-by: Ian Campbell 
Cc: Eric Dumazet 
Cc: Konrad Rzeszutek Wilk 
Cc: netdev@vger.kernel.org
Cc: xen-devel@lists.xen.org
---
 arch/x86/xen/setup.c       |    7 +++++++
 include/linux/skbuff.h     |    2 ++
 net/core/skbuff.c          |    7 ++++---
 net/core/sysctl_net_core.c |    7 +++++++
 4 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 8971a26..ad14d46 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -555,6 +556,12 @@ void __init xen_arch_setup(void)
 	       MAX_GUEST_CMDLINE > COMMAND_LINE_SIZE ?
 	       COMMAND_LINE_SIZE : MAX_GUEST_CMDLINE);
 
+	/*
+	 * Xen cannot handle DMA to/from compound pages so avoid
+	 * bounce buffering by not allocating large network frags.
+	 */
+	netdev_frag_page_max_order = 0;
+
 	/* Set up idle, making sure it calls safe_halt() pvop */
 #ifdef CONFIG_X86_32
 	boot_cpu_data.hlt_works_ok = 1;
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 6a2c34e..a3a748f 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -1719,6 +1719,8 @@ static inline void __skb_queue_purge(struct sk_buff_head *list)
 		kfree_skb(skb);
 }
 
+extern int netdev_frag_page_max_order;
+
 extern void *netdev_alloc_frag(unsigned int fragsz);
 
 extern struct sk_buff *__netdev_alloc_skb(struct net_device *dev,
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 6e04b1f..88cbe5f 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -348,8 +348,9 @@ struct netdev_alloc_cache {
 };
 static DEFINE_PER_CPU(struct netdev_alloc_cache, netdev_alloc_cache);
 
-#define NETDEV_FRAG_PAGE_MAX_ORDER get_order(32768)
-#define NETDEV_FRAG_PAGE_MAX_SIZE  (PAGE_SIZE << NETDEV_FRAG_PAGE_MAX_ORDER)
+int netdev_frag_page_max_order __read_mostly = get_order(32768);
+
+#define NETDEV_FRAG_PAGE_MAX_SIZE  (PAGE_SIZE << netdev_frag_page_max_order)
 #define NETDEV_PAGECNT_MAX_BIAS	   NETDEV_FRAG_PAGE_MAX_SIZE
 
 static void *__netdev_alloc_frag(unsigned int fragsz, gfp_t gfp_mask)
@@ -363,7 +364,7 @@ static void *__netdev_alloc_frag(unsigned int fragsz, gfp_t gfp_mask)
 	nc = &__get_cpu_var(netdev_alloc_cache);
 	if (unlikely(!nc->frag.page)) {
 refill:
-		for (order = NETDEV_FRAG_PAGE_MAX_ORDER; ;) {
+		for (order = netdev_frag_page_max_order; ;) {
 			gfp_t gfp = gfp_mask;
 
 			if (order)
diff --git a/net/core/sysctl_net_core.c b/net/core/sysctl_net_core.c
index a7c3684..e5ab6df 100644
--- a/net/core/sysctl_net_core.c
+++ b/net/core/sysctl_net_core.c
@@ -129,6 +129,13 @@ static struct ctl_table net_core_table[] = {
 		.mode		= 0644,
 		.proc_handler	= proc_dointvec
 	},
+	{
+		.procname	= "netdev_frag_page_max_order",
+		.data		= &netdev_frag_page_max_order,
+		.maxlen		= sizeof(int),
+		.mode		= 0644,
+		.proc_handler	= proc_dointvec
+	},
 #ifdef CONFIG_BPF_JIT
 	{
 		.procname	= "bpf_jit_enable",
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 11:57:49 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 11:57:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQza8-0002Cg-Jb; Wed, 24 Oct 2012 11:57:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQza7-0002Cb-2r
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 11:57:07 +0000
Received: from [85.158.139.83:65115] by server-9.bemta-5.messagelabs.com id
	28/3B-23053-297D7805; Wed, 24 Oct 2012 11:57:06 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1351079823!34077448!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31330 invoked from network); 24 Oct 2012 11:57:05 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 11:57:05 -0000
Received: by mail-pb0-f45.google.com with SMTP id rp2so1212874pbb.32
	for ; Wed, 24 Oct 2012 04:57:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=WUD/f7Qen39Cv2BigOp8WmI6XLRcXtf6SSDZ3r4iKwA=;
	b=CfgzWlwr/BucxfYUuCLiUKqIlJxLICY+IzbNkZn4f5IYJpbqZtrNpcbe8PUIqst0Zf
	z6vDQJsLSKqhI6tcWL3oqKkBl4zEuXFf8nwv6j/xJXd8GscTnAGd+Dvv89qkJr2hXa3a
	7oDIapLAzc1FsmKzGcnQU0uFNLsRS0hr5OSN7YTeIV/T9uPfPjj2S4lhywXrsjJXLokZ
	FHEgPn+R2LepO/2PwMG+gJJkRGNH5qRQfBKlYNbPyoiviqstTzluAd2QDOFFJUjGV3Ic
	PXB76JeXHw6iAqkDlKbjjU8u5wWxiOGpE48etuGf9ritDRs4YboYrU/Qmq3pCXZzfAj8
	n3uw==
Received: by 10.68.225.3 with SMTP id rg3mr49621584pbc.27.1351079823334;
	Wed, 24 Oct 2012 04:57:03 -0700 (PDT)
Received: from [101.2.20.16] ([96.49.152.177])
	by mx.google.com with ESMTPS id gl9sm9352877pbc.51.2012.10.24.04.57.01
	(version=SSLv3 cipher=OTHER); Wed, 24 Oct 2012 04:57:02 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Wed, 24 Oct 2012 04:56:58 -0700
From: Keir Fraser 
To: Jan Beulich ,
	xen-devel 
Message-ID: 
Thread-Topic: [Xen-devel] [PATCH] x86: don't special case first IO-APIC
Thread-Index: Ac2x3qtlSikiVlQicEatkdq0+JpREg==
In-Reply-To: <5087BAAF02000078000A3D15@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: don't special case first IO-APIC
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 24/10/2012 00:53, "Jan Beulich"  wrote:

> It has always been puzzling me why the first IO-APIC gets special cased
> in two places, and finally Xen got run on a system where this breaks:
> 
> (XEN) ACPI: IOAPIC (id[0x10] address[0xfecff000] gsi_base[0])
> (XEN) IOAPIC[0]: apic_id 16, version 17, address 0xfecff000, GSI 0-2
> (XEN) ACPI: IOAPIC (id[0x0f] address[0xfec00000] gsi_base[3])
> (XEN) IOAPIC[1]: apic_id 15, version 17, address 0xfec00000, GSI 3-38
> (XEN) ACPI: IOAPIC (id[0x0e] address[0xfec01000] gsi_base[39])
> (XEN) IOAPIC[2]: apic_id 14, version 17, address 0xfec01000, GSI 39-74
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 1 global_irq 4 dfl dfl)
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 5 dfl dfl)
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 3 global_irq 6 dfl dfl)
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 4 global_irq 7 dfl dfl)
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 6 global_irq 9 dfl dfl)
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 7 global_irq 10 dfl dfl)
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 8 global_irq 11 low edge)
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 12 dfl dfl)
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 12 global_irq 15 dfl dfl)
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 13 global_irq 16 dfl dfl)
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 17 low edge)
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 18 dfl dfl)
> 
> i.e. all legacy IRQs (apart from the timer one, but the firmware passed
> data doesn't look right for that case anyway, as both Xen and native
> Linux are falling back to use the virtual wire setup for IRQ0,
> apparently rather using pin 2 of the first IO-APIC) are being handled
> by the second IO-APIC.
> 
> This at once eliminates the possibility of an unmasked RTE getting
> written without having got a vector put in place (in
> setup_IO_APIC_irqs()).
> 
> Signed-off-by: Jan Beulich 

Acked-by: Keir Fraser 

> --- a/xen/arch/x86/io_apic.c
> +++ b/xen/arch/x86/io_apic.c
> @@ -990,18 +990,17 @@ static void __init setup_IO_APIC_irqs(vo
>              else
>                  add_pin_to_irq(irq, apic, pin);
>  
> -            if (!apic && !IO_APIC_IRQ(irq))
> +            if (!IO_APIC_IRQ(irq))
>                  continue;
>  
> -            if (IO_APIC_IRQ(irq)) {
> -                vector = assign_irq_vector(irq, NULL);
> -                BUG_ON(vector < 0);
> -                entry.vector = vector;
> -                ioapic_register_intr(irq, IOAPIC_AUTO);
> +            vector = assign_irq_vector(irq, NULL);
> +            BUG_ON(vector < 0);
> +            entry.vector = vector;
> +            ioapic_register_intr(irq, IOAPIC_AUTO);
> +
> +            if (platform_legacy_irq(irq))
> +                disable_8259A_irq(irq_to_desc(irq));
>  
> -                if (!apic && platform_legacy_irq(irq))
> -                    disable_8259A_irq(irq_to_desc(irq));
> -            }
>              desc = irq_to_desc(irq);
>              SET_DEST(entry.dest.dest32, entry.dest.logical.logical_dest,
>                       cpu_mask_to_apicid(desc->arch.cpu_mask));
> @@ -2245,18 +2244,15 @@ unsigned apic_gsi_base(int apic);
>  
>  static int apic_pin_2_gsi_irq(int apic, int pin)
>  {
> -    int idx, irq;
> +    int idx;
>  
>      if (apic < 0)
>         return -EINVAL;
>  
> -    irq = apic_gsi_base(apic) + pin;
> -    if (apic == 0) {
> -        idx = find_irq_entry(apic, pin, mp_INT);
> -        if (idx >= 0)
> -            irq = pin_2_irq(idx, apic, pin);
> -    }
> -    return irq;
> +    idx = find_irq_entry(apic, pin, mp_INT);
> +
> +    return idx >= 0 ? pin_2_irq(idx, apic, pin)
> +                    : apic_gsi_base(apic) + pin;
>  }
>  
>  int ioapic_guest_read(unsigned long physbase, unsigned int reg, u32 *pval)
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 11:57:49 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 11:57:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQza8-0002Cg-Jb; Wed, 24 Oct 2012 11:57:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQza7-0002Cb-2r
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 11:57:07 +0000
Received: from [85.158.139.83:65115] by server-9.bemta-5.messagelabs.com id
	28/3B-23053-297D7805; Wed, 24 Oct 2012 11:57:06 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1351079823!34077448!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31330 invoked from network); 24 Oct 2012 11:57:05 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 11:57:05 -0000
Received: by mail-pb0-f45.google.com with SMTP id rp2so1212874pbb.32
	for ; Wed, 24 Oct 2012 04:57:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=WUD/f7Qen39Cv2BigOp8WmI6XLRcXtf6SSDZ3r4iKwA=;
	b=CfgzWlwr/BucxfYUuCLiUKqIlJxLICY+IzbNkZn4f5IYJpbqZtrNpcbe8PUIqst0Zf
	z6vDQJsLSKqhI6tcWL3oqKkBl4zEuXFf8nwv6j/xJXd8GscTnAGd+Dvv89qkJr2hXa3a
	7oDIapLAzc1FsmKzGcnQU0uFNLsRS0hr5OSN7YTeIV/T9uPfPjj2S4lhywXrsjJXLokZ
	FHEgPn+R2LepO/2PwMG+gJJkRGNH5qRQfBKlYNbPyoiviqstTzluAd2QDOFFJUjGV3Ic
	PXB76JeXHw6iAqkDlKbjjU8u5wWxiOGpE48etuGf9ritDRs4YboYrU/Qmq3pCXZzfAj8
	n3uw==
Received: by 10.68.225.3 with SMTP id rg3mr49621584pbc.27.1351079823334;
	Wed, 24 Oct 2012 04:57:03 -0700 (PDT)
Received: from [101.2.20.16] ([96.49.152.177])
	by mx.google.com with ESMTPS id gl9sm9352877pbc.51.2012.10.24.04.57.01
	(version=SSLv3 cipher=OTHER); Wed, 24 Oct 2012 04:57:02 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Wed, 24 Oct 2012 04:56:58 -0700
From: Keir Fraser 
To: Jan Beulich ,
	xen-devel 
Message-ID: 
Thread-Topic: [Xen-devel] [PATCH] x86: don't special case first IO-APIC
Thread-Index: Ac2x3qtlSikiVlQicEatkdq0+JpREg==
In-Reply-To: <5087BAAF02000078000A3D15@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: don't special case first IO-APIC
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 24/10/2012 00:53, "Jan Beulich"  wrote:

> It has always been puzzling me why the first IO-APIC gets special cased
> in two places, and finally Xen got run on a system where this breaks:
> 
> (XEN) ACPI: IOAPIC (id[0x10] address[0xfecff000] gsi_base[0])
> (XEN) IOAPIC[0]: apic_id 16, version 17, address 0xfecff000, GSI 0-2
> (XEN) ACPI: IOAPIC (id[0x0f] address[0xfec00000] gsi_base[3])
> (XEN) IOAPIC[1]: apic_id 15, version 17, address 0xfec00000, GSI 3-38
> (XEN) ACPI: IOAPIC (id[0x0e] address[0xfec01000] gsi_base[39])
> (XEN) IOAPIC[2]: apic_id 14, version 17, address 0xfec01000, GSI 39-74
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 1 global_irq 4 dfl dfl)
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 5 dfl dfl)
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 3 global_irq 6 dfl dfl)
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 4 global_irq 7 dfl dfl)
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 6 global_irq 9 dfl dfl)
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 7 global_irq 10 dfl dfl)
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 8 global_irq 11 low edge)
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 12 dfl dfl)
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 12 global_irq 15 dfl dfl)
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 13 global_irq 16 dfl dfl)
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 17 low edge)
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 18 dfl dfl)
> 
> i.e. all legacy IRQs (apart from the timer one, but the firmware passed
> data doesn't look right for that case anyway, as both Xen and native
> Linux are falling back to use the virtual wire setup for IRQ0,
> apparently rather using pin 2 of the first IO-APIC) are being handled
> by the second IO-APIC.
> 
> This at once eliminates the possibility of an unmasked RTE getting
> written without having got a vector put in place (in
> setup_IO_APIC_irqs()).
> 
> Signed-off-by: Jan Beulich 

Acked-by: Keir Fraser 

> --- a/xen/arch/x86/io_apic.c
> +++ b/xen/arch/x86/io_apic.c
> @@ -990,18 +990,17 @@ static void __init setup_IO_APIC_irqs(vo
>              else
>                  add_pin_to_irq(irq, apic, pin);
>  
> -            if (!apic && !IO_APIC_IRQ(irq))
> +            if (!IO_APIC_IRQ(irq))
>                  continue;
>  
> -            if (IO_APIC_IRQ(irq)) {
> -                vector = assign_irq_vector(irq, NULL);
> -                BUG_ON(vector < 0);
> -                entry.vector = vector;
> -                ioapic_register_intr(irq, IOAPIC_AUTO);
> +            vector = assign_irq_vector(irq, NULL);
> +            BUG_ON(vector < 0);
> +            entry.vector = vector;
> +            ioapic_register_intr(irq, IOAPIC_AUTO);
> +
> +            if (platform_legacy_irq(irq))
> +                disable_8259A_irq(irq_to_desc(irq));
>  
> -                if (!apic && platform_legacy_irq(irq))
> -                    disable_8259A_irq(irq_to_desc(irq));
> -            }
>              desc = irq_to_desc(irq);
>              SET_DEST(entry.dest.dest32, entry.dest.logical.logical_dest,
>                       cpu_mask_to_apicid(desc->arch.cpu_mask));
> @@ -2245,18 +2244,15 @@ unsigned apic_gsi_base(int apic);
>  
>  static int apic_pin_2_gsi_irq(int apic, int pin)
>  {
> -    int idx, irq;
> +    int idx;
>  
>      if (apic < 0)
>         return -EINVAL;
>  
> -    irq = apic_gsi_base(apic) + pin;
> -    if (apic == 0) {
> -        idx = find_irq_entry(apic, pin, mp_INT);
> -        if (idx >= 0)
> -            irq = pin_2_irq(idx, apic, pin);
> -    }
> -    return irq;
> +    idx = find_irq_entry(apic, pin, mp_INT);
> +
> +    return idx >= 0 ? pin_2_irq(idx, apic, pin)
> +                    : apic_gsi_base(apic) + pin;
>  }
>  
>  int ioapic_guest_read(unsigned long physbase, unsigned int reg, u32 *pval)
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 12:19:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 12:19:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQzvc-0002f8-IU; Wed, 24 Oct 2012 12:19:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQzva-0002f3-SV
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 12:19:18 +0000
Received: from [85.158.143.35:34093] by server-3.bemta-4.messagelabs.com id
	3D/BE-24279-5CCD7805; Wed, 24 Oct 2012 12:19:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1351081115!14548015!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11470 invoked from network); 24 Oct 2012 12:18:36 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-21.messagelabs.com with SMTP;
	24 Oct 2012 12:18:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 24 Oct 2012 13:18:34 +0100
Message-Id: <5087F8B902000078000A3F38@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 24 Oct 2012 13:18:33 +0100
From: "Jan Beulich" 
To: "Christoph Egger" 
References: <50782D4B.50607@amd.com>
In-Reply-To: <50782D4B.50607@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] x86/MCE: Implement clearbank callback for
 AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.10.12 at 16:46, Christoph Egger  wrote:
>+static int k8_need_clearbank_scan(enum mca_source who, uint64_t status)
>+{
>+	switch (who) {
>+	case MCA_MCE_SCAN:
>+	case MCA_MCE_HANDLER:
>+		break;
>+	default:
>+		return 1;
>+	}
>+
>+	/* For fatal error, it shouldn't be cleared so that sticky bank
>+	 * have chance to be handled after reboot by polling.
>+	 */
>+	if ( (status & MCi_STATUS_UC) && (status & MCi_STATUS_PCC) )
>+		return 0;
>+	/* Spurious need clear bank */
>+	if ( !(status & MCi_STATUS_OVER)
>+	    && (status & MCi_STATUS_UC) && !(status & MCi_STATUS_EN))
>+		return 1;
>+
>+	return 1;
> }

So what's the purpose of first conditionally returning 1, and then
also doing so unconditionally? Do anticipate to insert code between
the two parts within the very near future? Otherwise I'd drop the
whole if() construct.

(No need to re-submit, just let me know.)

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 12:19:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 12:19:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TQzvc-0002f8-IU; Wed, 24 Oct 2012 12:19:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TQzva-0002f3-SV
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 12:19:18 +0000
Received: from [85.158.143.35:34093] by server-3.bemta-4.messagelabs.com id
	3D/BE-24279-5CCD7805; Wed, 24 Oct 2012 12:19:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1351081115!14548015!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11470 invoked from network); 24 Oct 2012 12:18:36 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-21.messagelabs.com with SMTP;
	24 Oct 2012 12:18:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 24 Oct 2012 13:18:34 +0100
Message-Id: <5087F8B902000078000A3F38@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 24 Oct 2012 13:18:33 +0100
From: "Jan Beulich" 
To: "Christoph Egger" 
References: <50782D4B.50607@amd.com>
In-Reply-To: <50782D4B.50607@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] x86/MCE: Implement clearbank callback for
 AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.10.12 at 16:46, Christoph Egger  wrote:
>+static int k8_need_clearbank_scan(enum mca_source who, uint64_t status)
>+{
>+	switch (who) {
>+	case MCA_MCE_SCAN:
>+	case MCA_MCE_HANDLER:
>+		break;
>+	default:
>+		return 1;
>+	}
>+
>+	/* For fatal error, it shouldn't be cleared so that sticky bank
>+	 * have chance to be handled after reboot by polling.
>+	 */
>+	if ( (status & MCi_STATUS_UC) && (status & MCi_STATUS_PCC) )
>+		return 0;
>+	/* Spurious need clear bank */
>+	if ( !(status & MCi_STATUS_OVER)
>+	    && (status & MCi_STATUS_UC) && !(status & MCi_STATUS_EN))
>+		return 1;
>+
>+	return 1;
> }

So what's the purpose of first conditionally returning 1, and then
also doing so unconditionally? Do anticipate to insert code between
the two parts within the very near future? Otherwise I'd drop the
whole if() construct.

(No need to re-submit, just let me know.)

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 12:28:56 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 12:28:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR04W-0002oW-K6; Wed, 24 Oct 2012 12:28:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR04V-0002oR-4z
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 12:28:31 +0000
Received: from [85.158.143.99:13006] by server-1.bemta-4.messagelabs.com id
	53/85-19134-EEED7805; Wed, 24 Oct 2012 12:28:30 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1351081708!25577752!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27750 invoked from network); 24 Oct 2012 12:28:28 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 12:28:28 -0000
Received: by mail-bk0-f45.google.com with SMTP id jf3so213226bkc.32
	for ; Wed, 24 Oct 2012 05:28:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:from:to:cc:in-reply-to:references:content-type:date
	:message-id:mime-version:x-mailer:content-transfer-encoding;
	bh=FHgdDD63plXGvvgIk+2w+XSoNTHmaG5wfmkcKXi2b40=;
	b=ZIqam16JKqaKag/djda5yA36b+qK3hnyX9tS1Vx/SBT5DNL23GOiOh4q9ygdyP1aFZ
	2pFmXp7VYFB6ZNSJ4u4cH9OfmOJDJPv5QSdt7KtHfF5OJY5YpX4ccfPFLcPyo/OKH1Rr
	3gYSK7jM7ket6PBVDnasobQu2o+KNA5E7LjPcXMd1kyH/YEtL2CBkERswRP6cjovvXnO
	JMteIyBn96EXN5af9mzbl3gXRTNaJpxwj/ar6Z3EEB6IBZ2IPmEm1DO4NVUkV/jWUY6/
	tgrcKTyVD01lxbJezpTyPcX5DM31hxZDrLD/SITAszzW1K3MIvyfg+xpFcyQxMi5c1Zw
	KGAA==
Received: by 10.204.3.220 with SMTP id 28mr4670903bko.87.1351081708281;
	Wed, 24 Oct 2012 05:28:28 -0700 (PDT)
Received: from [172.28.90.62] ([172.28.90.62])
	by mx.google.com with ESMTPS id ia2sm7962225bkc.11.2012.10.24.05.28.25
	(version=SSLv3 cipher=OTHER); Wed, 24 Oct 2012 05:28:26 -0700 (PDT)
From: Eric Dumazet 
To: Ian Campbell 
In-Reply-To: <1351078936-14159-1-git-send-email-ian.campbell@citrix.com>
References: <1351078936-14159-1-git-send-email-ian.campbell@citrix.com>
Date: Wed, 24 Oct 2012 14:28:23 +0200
Message-ID: <1351081703.6537.99.camel@edumazet-glaptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: netdev@vger.kernel.org, Eric Dumazet ,
	xen-devel@lists.xen.org, Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH] net: allow configuration of the size of
 page in __netdev_alloc_frag
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 12:42 +0100, Ian Campbell wrote:
> The commit 69b08f62e174 "net: use bigger pages in __netdev_alloc_frag"
> lead to 70%+ packet loss under Xen when transmitting from physical (as
> opposed to virtual) network devices.
> 
> This is because under Xen pages which are contiguous in the physical
> address space may not be contiguous in the DMA space, in fact it is
> very likely that they are not. I think there are other architectures
> where this is true, although perhaps non quite so aggressive as to
> have this property at a per-order-0-page granularity.
> 
> The real underlying bug here most likely lies in the swiotlb not
> correctly handling compound pages, and Konrad is investigating this.
> However even with the swiotlb issue fixed the current arrangement
> seems likely to result in a lot of bounce buffering which seems likely
> to more than offset any benefit from the use of larger pages.
> 
> Therefore make NETDEV_FRAG_PAGE_MAX_ORDER configurable at runtime and
> use this to request order-0 frags under Xen. Also expose this setting
> via sysctl.
> 
> Signed-off-by: Ian Campbell 
> Cc: Eric Dumazet 
> Cc: Konrad Rzeszutek Wilk 
> Cc: netdev@vger.kernel.org
> Cc: xen-devel@lists.xen.org
> ---

I understand your concern, but this seems a quick/dirty hack at this
moment. After setting the sysctl to 0, some tasks may still have some
order-3 pages in their cache.

Your driver must already cope with skb->head being split on several
pages.

So what fundamental difference exists with frags ?




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 12:28:56 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 12:28:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR04W-0002oW-K6; Wed, 24 Oct 2012 12:28:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR04V-0002oR-4z
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 12:28:31 +0000
Received: from [85.158.143.99:13006] by server-1.bemta-4.messagelabs.com id
	53/85-19134-EEED7805; Wed, 24 Oct 2012 12:28:30 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1351081708!25577752!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27750 invoked from network); 24 Oct 2012 12:28:28 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 12:28:28 -0000
Received: by mail-bk0-f45.google.com with SMTP id jf3so213226bkc.32
	for ; Wed, 24 Oct 2012 05:28:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:from:to:cc:in-reply-to:references:content-type:date
	:message-id:mime-version:x-mailer:content-transfer-encoding;
	bh=FHgdDD63plXGvvgIk+2w+XSoNTHmaG5wfmkcKXi2b40=;
	b=ZIqam16JKqaKag/djda5yA36b+qK3hnyX9tS1Vx/SBT5DNL23GOiOh4q9ygdyP1aFZ
	2pFmXp7VYFB6ZNSJ4u4cH9OfmOJDJPv5QSdt7KtHfF5OJY5YpX4ccfPFLcPyo/OKH1Rr
	3gYSK7jM7ket6PBVDnasobQu2o+KNA5E7LjPcXMd1kyH/YEtL2CBkERswRP6cjovvXnO
	JMteIyBn96EXN5af9mzbl3gXRTNaJpxwj/ar6Z3EEB6IBZ2IPmEm1DO4NVUkV/jWUY6/
	tgrcKTyVD01lxbJezpTyPcX5DM31hxZDrLD/SITAszzW1K3MIvyfg+xpFcyQxMi5c1Zw
	KGAA==
Received: by 10.204.3.220 with SMTP id 28mr4670903bko.87.1351081708281;
	Wed, 24 Oct 2012 05:28:28 -0700 (PDT)
Received: from [172.28.90.62] ([172.28.90.62])
	by mx.google.com with ESMTPS id ia2sm7962225bkc.11.2012.10.24.05.28.25
	(version=SSLv3 cipher=OTHER); Wed, 24 Oct 2012 05:28:26 -0700 (PDT)
From: Eric Dumazet 
To: Ian Campbell 
In-Reply-To: <1351078936-14159-1-git-send-email-ian.campbell@citrix.com>
References: <1351078936-14159-1-git-send-email-ian.campbell@citrix.com>
Date: Wed, 24 Oct 2012 14:28:23 +0200
Message-ID: <1351081703.6537.99.camel@edumazet-glaptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: netdev@vger.kernel.org, Eric Dumazet ,
	xen-devel@lists.xen.org, Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH] net: allow configuration of the size of
 page in __netdev_alloc_frag
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 12:42 +0100, Ian Campbell wrote:
> The commit 69b08f62e174 "net: use bigger pages in __netdev_alloc_frag"
> lead to 70%+ packet loss under Xen when transmitting from physical (as
> opposed to virtual) network devices.
> 
> This is because under Xen pages which are contiguous in the physical
> address space may not be contiguous in the DMA space, in fact it is
> very likely that they are not. I think there are other architectures
> where this is true, although perhaps non quite so aggressive as to
> have this property at a per-order-0-page granularity.
> 
> The real underlying bug here most likely lies in the swiotlb not
> correctly handling compound pages, and Konrad is investigating this.
> However even with the swiotlb issue fixed the current arrangement
> seems likely to result in a lot of bounce buffering which seems likely
> to more than offset any benefit from the use of larger pages.
> 
> Therefore make NETDEV_FRAG_PAGE_MAX_ORDER configurable at runtime and
> use this to request order-0 frags under Xen. Also expose this setting
> via sysctl.
> 
> Signed-off-by: Ian Campbell 
> Cc: Eric Dumazet 
> Cc: Konrad Rzeszutek Wilk 
> Cc: netdev@vger.kernel.org
> Cc: xen-devel@lists.xen.org
> ---

I understand your concern, but this seems a quick/dirty hack at this
moment. After setting the sysctl to 0, some tasks may still have some
order-3 pages in their cache.

Your driver must already cope with skb->head being split on several
pages.

So what fundamental difference exists with frags ?




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 12:51:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 12:51:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR0QV-00032B-P7; Wed, 24 Oct 2012 12:51:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR0QU-000326-Bp
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 12:51:14 +0000
Received: from [85.158.143.99:10743] by server-3.bemta-4.messagelabs.com id
	CF/CF-24279-144E7805; Wed, 24 Oct 2012 12:51:13 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-13.tower-216.messagelabs.com!1351083072!29111550!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2205 invoked from network); 24 Oct 2012 12:51:12 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Oct 2012 12:51:12 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id 02BD1400F79
	for ;
	Wed, 24 Oct 2012 14:51:12 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 8PmtIpXfD3OZ for ;
	Wed, 24 Oct 2012 14:51:10 +0200 (CEST)
Received: from [192.168.178.50]
	(host51-78-dynamic.2-87-r.retail.telecomitalia.it [87.2.78.51])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id 766F0400A8E
	for ;
	Wed, 24 Oct 2012 14:51:10 +0200 (CEST)
Message-ID: <5087E43B.70001@tiscali.it>
Date: Wed, 24 Oct 2012 14:51:07 +0200
From: Fabio Fantoni 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: xen-devel 
Subject: [Xen-devel] Test report for xen-unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: fantonifabio@tiscali.it
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============8669900398892955905=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============8669900398892955905==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030002060503030509010802"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms030002060503030509010802
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

Dom0:
Wheezy 64 bit with kernel from package linux-image-3.2.0-3-amd64 version =

3.2.23-1, package blktap-dkms and all dependency packages for xen
hg clone http://xenbits.xen.org/hg/xen-unstable.hg (in this build=20
changeset is 26094:c69bcb248128)
-------------------------
vi Config.mk
------------
PYTHON_PREFIX_ARG =3D
QEMU_UPSTREAM_URL ?=3D git://git.qemu.org/qemu.git
SEABIOS_UPSTREAM_URL ?=3D git://code.coreboot.org/seabios.git
SEABIOS_UPSTREAM_TAG ?=3D master
-------------------------
Added some patches:
- tools: Improve make deb
- Add qxl vga interface support v3
- tools: Compile qemu-xen with spice
-------------------------
=2E/configure
-------------------------
make deb

-------------------------
Issues solved:
-------------
- save/restore with qemu-xen is now working
- xl cd-eject with qemu-xen is now working
-------------------------

-------------------------
Old issues not solved:
-------------
- IMPORTANT - On restore the network is up but is not working, I tried=20
it with W7 pro 64 bit with gplpv last build (357) on qemu-xen
- xl-cd-insert is not working, tried with W7 pro 64 bit with gplpv last=20
build (357) on qemu-xen and also ubuntu 12.10
xl cd-insert QUANTALHVM hdb raw:/mnt/vm/iso/QUANTAL.iso
Errore di segmentazione (segmentation fault)
- HVM domUs with spice and qxl don't work, qemu crashes but it works=20
without qxl
-------------------------


--------------ms030002060503030509010802
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Firma crittografica S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa
Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG
EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi
aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV
10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU
Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR
MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl
Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A
jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2
YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh
bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC
AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw
gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC
AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz
cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks
IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug
b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh
cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv
bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI
KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j
YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN
BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8
h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1
kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8
oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+
qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEyMTAyNDEyNTEwN1owIwYJKoZIhvcNAQkEMRYEFNjqeUfNOVe1daEwgzgfkE6E
X8k8MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAkqGfwdeRZjMSCDwN+QOL6c3O
RiFFX3AVCSgXfH2xu+Pb1VaAGaSMS4Tvslu96zO/uF/hNq4iZ+dYfmZXI8K9BWhbSwJtJ/Eh
ls4WSZslgmeyD8ertWV/FtISS//tuvC0rovNMPt05R4dK5QgKoZBCunhF/LvxfppA3shjuo7
Z/h/uLBa3J/0iUb9JJXX5yuD+47jBK6vYyGst417K7XLEJu4ZeNH2D21JeFVR5FsjIeftTPz
PXb2nY4mTIqZcEq9VEivKYz0sjlR/hr/CgrqqaNHW3Pbh0VtuzS7RjHYjp9b4UDrxX/+diHL
AlNjXufBrWTp6gzGyplKVCWGlKNnRgAAAAAAAA==
--------------ms030002060503030509010802--


--===============8669900398892955905==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8669900398892955905==--


From xen-devel-bounces@lists.xen.org Wed Oct 24 12:51:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 12:51:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR0QV-00032B-P7; Wed, 24 Oct 2012 12:51:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR0QU-000326-Bp
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 12:51:14 +0000
Received: from [85.158.143.99:10743] by server-3.bemta-4.messagelabs.com id
	CF/CF-24279-144E7805; Wed, 24 Oct 2012 12:51:13 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-13.tower-216.messagelabs.com!1351083072!29111550!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2205 invoked from network); 24 Oct 2012 12:51:12 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Oct 2012 12:51:12 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id 02BD1400F79
	for ;
	Wed, 24 Oct 2012 14:51:12 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 8PmtIpXfD3OZ for ;
	Wed, 24 Oct 2012 14:51:10 +0200 (CEST)
Received: from [192.168.178.50]
	(host51-78-dynamic.2-87-r.retail.telecomitalia.it [87.2.78.51])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id 766F0400A8E
	for ;
	Wed, 24 Oct 2012 14:51:10 +0200 (CEST)
Message-ID: <5087E43B.70001@tiscali.it>
Date: Wed, 24 Oct 2012 14:51:07 +0200
From: Fabio Fantoni 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: xen-devel 
Subject: [Xen-devel] Test report for xen-unstable
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: fantonifabio@tiscali.it
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============8669900398892955905=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============8669900398892955905==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030002060503030509010802"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms030002060503030509010802
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

Dom0:
Wheezy 64 bit with kernel from package linux-image-3.2.0-3-amd64 version =

3.2.23-1, package blktap-dkms and all dependency packages for xen
hg clone http://xenbits.xen.org/hg/xen-unstable.hg (in this build=20
changeset is 26094:c69bcb248128)
-------------------------
vi Config.mk
------------
PYTHON_PREFIX_ARG =3D
QEMU_UPSTREAM_URL ?=3D git://git.qemu.org/qemu.git
SEABIOS_UPSTREAM_URL ?=3D git://code.coreboot.org/seabios.git
SEABIOS_UPSTREAM_TAG ?=3D master
-------------------------
Added some patches:
- tools: Improve make deb
- Add qxl vga interface support v3
- tools: Compile qemu-xen with spice
-------------------------
=2E/configure
-------------------------
make deb

-------------------------
Issues solved:
-------------
- save/restore with qemu-xen is now working
- xl cd-eject with qemu-xen is now working
-------------------------

-------------------------
Old issues not solved:
-------------
- IMPORTANT - On restore the network is up but is not working, I tried=20
it with W7 pro 64 bit with gplpv last build (357) on qemu-xen
- xl-cd-insert is not working, tried with W7 pro 64 bit with gplpv last=20
build (357) on qemu-xen and also ubuntu 12.10
xl cd-insert QUANTALHVM hdb raw:/mnt/vm/iso/QUANTAL.iso
Errore di segmentazione (segmentation fault)
- HVM domUs with spice and qxl don't work, qemu crashes but it works=20
without qxl
-------------------------


--------------ms030002060503030509010802
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Firma crittografica S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa
Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG
EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi
aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV
10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU
Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR
MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl
Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A
jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2
YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh
bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC
AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw
gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC
AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz
cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks
IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug
b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh
cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv
bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI
KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j
YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN
BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8
h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1
kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8
oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+
qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEyMTAyNDEyNTEwN1owIwYJKoZIhvcNAQkEMRYEFNjqeUfNOVe1daEwgzgfkE6E
X8k8MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAkqGfwdeRZjMSCDwN+QOL6c3O
RiFFX3AVCSgXfH2xu+Pb1VaAGaSMS4Tvslu96zO/uF/hNq4iZ+dYfmZXI8K9BWhbSwJtJ/Eh
ls4WSZslgmeyD8ertWV/FtISS//tuvC0rovNMPt05R4dK5QgKoZBCunhF/LvxfppA3shjuo7
Z/h/uLBa3J/0iUb9JJXX5yuD+47jBK6vYyGst417K7XLEJu4ZeNH2D21JeFVR5FsjIeftTPz
PXb2nY4mTIqZcEq9VEivKYz0sjlR/hr/CgrqqaNHW3Pbh0VtuzS7RjHYjp9b4UDrxX/+diHL
AlNjXufBrWTp6gzGyplKVCWGlKNnRgAAAAAAAA==
--------------ms030002060503030509010802--


--===============8669900398892955905==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8669900398892955905==--


From xen-devel-bounces@lists.xen.org Wed Oct 24 12:52:18 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 12:52:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR0RC-00034I-79; Wed, 24 Oct 2012 12:51:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR0RA-000349-D2
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 12:51:56 +0000
Received: from [85.158.143.35:22556] by server-1.bemta-4.messagelabs.com id
	CC/67-19134-B64E7805; Wed, 24 Oct 2012 12:51:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1351083114!13393442!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25795 invoked from network); 24 Oct 2012 12:51:54 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-21.messagelabs.com with SMTP;
	24 Oct 2012 12:51:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 24 Oct 2012 13:51:56 +0100
Message-Id: <5088008702000078000A3F6F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 24 Oct 2012 13:51:51 +0100
From: "Jan Beulich" 
To: "Ronny Hegewald" 
References: <201210212222.18396.ronny.hegewald@online.de>
In-Reply-To: <201210212222.18396.ronny.hegewald@online.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH V2] keep iommu disabled until iommu_setup()
 is called
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 22.10.12 at 00:22, Ronny Hegewald  wrote:
> The iommu is enabled by default when xen is booting and later disabled in 
> iommu_setup() when no iommu is present.
> 
> But under some circumstances iommu-code can be called before iommu_setup() is 
> 
> processed. If there is no iommu available xen crashes.
> 
> This can happen for example when panic(...) is called that got introduced 
> with
> patch "x86-64: detect processors subject to AMD erratum #121 and refuse to 
> boot." since xen 4.1.3 and results in the following stacktrace:
> 
>    find_iommu_for_device
>    amd_iommu_ioapic_update_ire
>    timer_interrupt
>    enable_8259_A_irq
>    do_IRQ
>    printk_start_of_line
>    acpi_os_printf
>    io_apic_write
>    __ioapic_write_entry
>    ioapic_write_entry
>    __clear_IO_APIC_pin
>    clear_IO_APIC
>    disable_IO_APIC
>    __stop_this_cpu
>    smp_send_stop
>    machine_restart
>    panic
>    tasklet_schedule_on_cpu
>    display_cacheinfo
>    init_amd
>    generic_identify
>    identify_cpu
>    _start_xen
>    _high_start
> 
> 
> This patch fixes this by keeping the iommu disabled until iommu_setup() is 
> entered. 
> 
> Signed-off-by: Ronny Hegewald@online.de 
> 
> ---
> Changed since V1:
>    * simplify code as suggested by Jan Beulich

I'm completing that adjustment as originally requested. Plus, in
case you happen to send patches again in the future, please
prepare them against the -unstable tree, not some older version.

Jan

> --- xen/drivers/passthrough/iommu.c.org	2012-10-05 03:38:33.000000000 +0000
> +++ xen/drivers/passthrough/iommu.c	2012-10-21 21:07:37.000000000 +0000
> @@ -38,7 +38,8 @@
>   *   no-intremap                Disable VT-d Interrupt Remapping
>   */
>  custom_param("iommu", parse_iommu_param);
> -bool_t __read_mostly iommu_enabled = 1;
> +bool_t iommu_enable_default __initdata = 1;
> +bool_t __read_mostly iommu_enabled;
>  bool_t __read_mostly force_iommu;
>  bool_t __initdata iommu_dom0_strict;
>  bool_t __read_mostly iommu_verbose;
> @@ -61,7 +62,7 @@
>              *ss = '\0';
>  
>          if ( !parse_bool(s) )
> -            iommu_enabled = 0;
> +            iommu_enable_default = 0;
>          else if ( !strcmp(s, "force") || !strcmp(s, "required") )
>              force_iommu = 1;
>          else if ( !strcmp(s, "workaround_bios_bug") )
> @@ -316,7 +317,7 @@
>      if ( iommu_dom0_strict )
>          iommu_passthrough = 0;
>  
> -    if ( iommu_enabled )
> +    if ( iommu_enable_default )
>      {
>          rc = iommu_hardware_setup();
>          iommu_enabled = (rc == 0);
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 12:52:18 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 12:52:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR0RC-00034I-79; Wed, 24 Oct 2012 12:51:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR0RA-000349-D2
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 12:51:56 +0000
Received: from [85.158.143.35:22556] by server-1.bemta-4.messagelabs.com id
	CC/67-19134-B64E7805; Wed, 24 Oct 2012 12:51:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1351083114!13393442!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25795 invoked from network); 24 Oct 2012 12:51:54 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-21.messagelabs.com with SMTP;
	24 Oct 2012 12:51:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 24 Oct 2012 13:51:56 +0100
Message-Id: <5088008702000078000A3F6F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 24 Oct 2012 13:51:51 +0100
From: "Jan Beulich" 
To: "Ronny Hegewald" 
References: <201210212222.18396.ronny.hegewald@online.de>
In-Reply-To: <201210212222.18396.ronny.hegewald@online.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH V2] keep iommu disabled until iommu_setup()
 is called
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 22.10.12 at 00:22, Ronny Hegewald  wrote:
> The iommu is enabled by default when xen is booting and later disabled in 
> iommu_setup() when no iommu is present.
> 
> But under some circumstances iommu-code can be called before iommu_setup() is 
> 
> processed. If there is no iommu available xen crashes.
> 
> This can happen for example when panic(...) is called that got introduced 
> with
> patch "x86-64: detect processors subject to AMD erratum #121 and refuse to 
> boot." since xen 4.1.3 and results in the following stacktrace:
> 
>    find_iommu_for_device
>    amd_iommu_ioapic_update_ire
>    timer_interrupt
>    enable_8259_A_irq
>    do_IRQ
>    printk_start_of_line
>    acpi_os_printf
>    io_apic_write
>    __ioapic_write_entry
>    ioapic_write_entry
>    __clear_IO_APIC_pin
>    clear_IO_APIC
>    disable_IO_APIC
>    __stop_this_cpu
>    smp_send_stop
>    machine_restart
>    panic
>    tasklet_schedule_on_cpu
>    display_cacheinfo
>    init_amd
>    generic_identify
>    identify_cpu
>    _start_xen
>    _high_start
> 
> 
> This patch fixes this by keeping the iommu disabled until iommu_setup() is 
> entered. 
> 
> Signed-off-by: Ronny Hegewald@online.de 
> 
> ---
> Changed since V1:
>    * simplify code as suggested by Jan Beulich

I'm completing that adjustment as originally requested. Plus, in
case you happen to send patches again in the future, please
prepare them against the -unstable tree, not some older version.

Jan

> --- xen/drivers/passthrough/iommu.c.org	2012-10-05 03:38:33.000000000 +0000
> +++ xen/drivers/passthrough/iommu.c	2012-10-21 21:07:37.000000000 +0000
> @@ -38,7 +38,8 @@
>   *   no-intremap                Disable VT-d Interrupt Remapping
>   */
>  custom_param("iommu", parse_iommu_param);
> -bool_t __read_mostly iommu_enabled = 1;
> +bool_t iommu_enable_default __initdata = 1;
> +bool_t __read_mostly iommu_enabled;
>  bool_t __read_mostly force_iommu;
>  bool_t __initdata iommu_dom0_strict;
>  bool_t __read_mostly iommu_verbose;
> @@ -61,7 +62,7 @@
>              *ss = '\0';
>  
>          if ( !parse_bool(s) )
> -            iommu_enabled = 0;
> +            iommu_enable_default = 0;
>          else if ( !strcmp(s, "force") || !strcmp(s, "required") )
>              force_iommu = 1;
>          else if ( !strcmp(s, "workaround_bios_bug") )
> @@ -316,7 +317,7 @@
>      if ( iommu_dom0_strict )
>          iommu_passthrough = 0;
>  
> -    if ( iommu_enabled )
> +    if ( iommu_enable_default )
>      {
>          rc = iommu_hardware_setup();
>          iommu_enabled = (rc == 0);
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 13:11:50 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 13:11:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR0jw-0003Q5-35; Wed, 24 Oct 2012 13:11:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR0ju-0003Q0-QQ
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 13:11:19 +0000
Received: from [85.158.139.211:12656] by server-5.bemta-5.messagelabs.com id
	03/C4-09732-6F8E7805; Wed, 24 Oct 2012 13:11:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1351084277!23528601!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15631 invoked from network); 24 Oct 2012 13:11:17 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-206.messagelabs.com with SMTP;
	24 Oct 2012 13:11:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 24 Oct 2012 14:11:18 +0100
Message-Id: <5088051102000078000A3F8B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 24 Oct 2012 14:11:13 +0100
From: "Jan Beulich" 
To: "Wei Wang" 
References: <5086A224.2070801@amd.com>
In-Reply-To: <5086A224.2070801@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH] AMD IOMMU: Enable HPET broadcast msi
	remapping
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 23.10.12 at 15:56, Wei Wang  wrote:
>--- a/xen/drivers/passthrough/amd/iommu_acpi.c
>+++ b/xen/drivers/passthrough/amd/iommu_acpi.c
>@@ -653,9 +653,25 @@ static u16 __init parse_ivhd_device_special(
>     }
> 
>     add_ivrs_mapping_entry(bdf, bdf, special->header.data_setting, iommu);
>+    
>+    switch ( special->variety )
>+    {
>+    case 1:

Please use the existing #define-s for this and the HPET one below.

>     /* set device id of ioapic */
>-    ioapic_sbdf[special->handle].bdf = bdf;
>-    ioapic_sbdf[special->handle].seg = seg;
>+        ioapic_sbdf[special->handle].bdf = bdf;
>+        ioapic_sbdf[special->handle].seg = seg;
>+        break;
>+    case 2:
>+        /* set device id of hpet */
>+        hpet_sbdf.id = special->handle;
>+        hpet_sbdf.bdf = bdf;
>+        hpet_sbdf.seg = seg;
>+        hpet_sbdf.iommu = iommu;

So there can only ever be a single HPET? Is that written down in
the spec somewhere? Otherwise I would at least want a warning
to be issued if we unexpectedly find a second one (and probably
avoid clobbering the already saved data).

>@@ -267,14 +268,16 @@ static void update_intremap_entry_from_msi_msg(
> {
>     unsigned long flags;
>     u32* entry;
>-    u16 bdf, req_id, alias_id;
>+    u16 seg, bdf, req_id, alias_id;
>     u8 delivery_mode, dest, vector, dest_mode;
>     spinlock_t *lock;
>     int offset;
> 
>-    bdf = PCI_BDF2(pdev->bus, pdev->devfn);
>-    req_id = get_dma_requestor_id(pdev->seg, bdf);
>-    alias_id = get_intremap_requestor_id(pdev->seg, bdf);
>+    bdf = pdev ? PCI_BDF2(pdev->bus, pdev->devfn) : hpet_sbdf.bdf;
>+    seg = pdev ? pdev->seg : hpet_sbdf.seg;
>+    
>+    req_id = get_dma_requestor_id(seg, bdf);
>+    alias_id = get_intremap_requestor_id(seg, bdf);
> 
>     if ( msg == NULL )
>     {

As you're replacing all further uses of pdev in this function anyway,
and the single caller already determines seg and bdf, please replace
the passing of "struct pci_dev *" by passing "bdf" and using
"iommu->seg". That'll also make obvious that no left over unchecked
use of "pdev" exists here (and avoids any getting re-added later).

>--- a/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
>+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
>@@ -97,12 +97,18 @@ void amd_iommu_msi_msg_update_ire(
>     struct msi_desc *msi_desc, struct msi_msg *msg);
> void amd_iommu_read_msi_from_ire(
>     struct msi_desc *msi_desc, struct msi_msg *msg);
>+int __init amd_setup_hpet_msi(struct msi_desc *msi_desc);

No __init on a declaration please.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 13:11:50 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 13:11:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR0jw-0003Q5-35; Wed, 24 Oct 2012 13:11:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR0ju-0003Q0-QQ
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 13:11:19 +0000
Received: from [85.158.139.211:12656] by server-5.bemta-5.messagelabs.com id
	03/C4-09732-6F8E7805; Wed, 24 Oct 2012 13:11:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1351084277!23528601!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15631 invoked from network); 24 Oct 2012 13:11:17 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-206.messagelabs.com with SMTP;
	24 Oct 2012 13:11:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 24 Oct 2012 14:11:18 +0100
Message-Id: <5088051102000078000A3F8B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 24 Oct 2012 14:11:13 +0100
From: "Jan Beulich" 
To: "Wei Wang" 
References: <5086A224.2070801@amd.com>
In-Reply-To: <5086A224.2070801@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH] AMD IOMMU: Enable HPET broadcast msi
	remapping
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 23.10.12 at 15:56, Wei Wang  wrote:
>--- a/xen/drivers/passthrough/amd/iommu_acpi.c
>+++ b/xen/drivers/passthrough/amd/iommu_acpi.c
>@@ -653,9 +653,25 @@ static u16 __init parse_ivhd_device_special(
>     }
> 
>     add_ivrs_mapping_entry(bdf, bdf, special->header.data_setting, iommu);
>+    
>+    switch ( special->variety )
>+    {
>+    case 1:

Please use the existing #define-s for this and the HPET one below.

>     /* set device id of ioapic */
>-    ioapic_sbdf[special->handle].bdf = bdf;
>-    ioapic_sbdf[special->handle].seg = seg;
>+        ioapic_sbdf[special->handle].bdf = bdf;
>+        ioapic_sbdf[special->handle].seg = seg;
>+        break;
>+    case 2:
>+        /* set device id of hpet */
>+        hpet_sbdf.id = special->handle;
>+        hpet_sbdf.bdf = bdf;
>+        hpet_sbdf.seg = seg;
>+        hpet_sbdf.iommu = iommu;

So there can only ever be a single HPET? Is that written down in
the spec somewhere? Otherwise I would at least want a warning
to be issued if we unexpectedly find a second one (and probably
avoid clobbering the already saved data).

>@@ -267,14 +268,16 @@ static void update_intremap_entry_from_msi_msg(
> {
>     unsigned long flags;
>     u32* entry;
>-    u16 bdf, req_id, alias_id;
>+    u16 seg, bdf, req_id, alias_id;
>     u8 delivery_mode, dest, vector, dest_mode;
>     spinlock_t *lock;
>     int offset;
> 
>-    bdf = PCI_BDF2(pdev->bus, pdev->devfn);
>-    req_id = get_dma_requestor_id(pdev->seg, bdf);
>-    alias_id = get_intremap_requestor_id(pdev->seg, bdf);
>+    bdf = pdev ? PCI_BDF2(pdev->bus, pdev->devfn) : hpet_sbdf.bdf;
>+    seg = pdev ? pdev->seg : hpet_sbdf.seg;
>+    
>+    req_id = get_dma_requestor_id(seg, bdf);
>+    alias_id = get_intremap_requestor_id(seg, bdf);
> 
>     if ( msg == NULL )
>     {

As you're replacing all further uses of pdev in this function anyway,
and the single caller already determines seg and bdf, please replace
the passing of "struct pci_dev *" by passing "bdf" and using
"iommu->seg". That'll also make obvious that no left over unchecked
use of "pdev" exists here (and avoids any getting re-added later).

>--- a/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
>+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
>@@ -97,12 +97,18 @@ void amd_iommu_msi_msg_update_ire(
>     struct msi_desc *msi_desc, struct msi_msg *msg);
> void amd_iommu_read_msi_from_ire(
>     struct msi_desc *msi_desc, struct msi_msg *msg);
>+int __init amd_setup_hpet_msi(struct msi_desc *msi_desc);

No __init on a declaration please.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 13:17:28 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 13:17:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR0pU-0003YU-FZ; Wed, 24 Oct 2012 13:17:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR0pT-0003Xq-6j
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 13:17:03 +0000
Received: from [85.158.138.51:2475] by server-6.bemta-3.messagelabs.com id
	F3/89-32375-84AE7805; Wed, 24 Oct 2012 13:16:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1351084613!27619636!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7516 invoked from network); 24 Oct 2012 13:16:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 13:16:53 -0000
X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="15358892"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 13:16:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 14:16:53 +0100
Message-ID: <1351084611.18035.26.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: xen-devel 
Date: Wed, 24 Oct 2012 14:16:51 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Subject: [Xen-devel] Valgrind support for Xen committed to trunk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thanks to Bart Van Assche the valgrind patches to support Xen privcmd
ioctls which I posted previously have now been committed to the Valgrind
trunk branch (which will eventually become 3.9.0).

Unlike the previous iteration of the patches posted to the list what is
no in tree do not require building against a specific set of Xen
headers. The code currently supports Xen 4.1, 4.2 and unstable versions
of the interfaces used by xl domain create and select other toolstack
operations. I will fault in additional hypercalls and versions on demand
so please report them here if you see messages such as "WARNING:
unhandled hypercall" or "WARNING: unhandled XXX subop".

You can find the code in svn://svn.valgrind.org/valgrind/trunk revision
1308 onwards.

Cheers,
Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 13:17:28 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 13:17:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR0pU-0003YU-FZ; Wed, 24 Oct 2012 13:17:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR0pT-0003Xq-6j
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 13:17:03 +0000
Received: from [85.158.138.51:2475] by server-6.bemta-3.messagelabs.com id
	F3/89-32375-84AE7805; Wed, 24 Oct 2012 13:16:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1351084613!27619636!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7516 invoked from network); 24 Oct 2012 13:16:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 13:16:53 -0000
X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="15358892"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 13:16:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 14:16:53 +0100
Message-ID: <1351084611.18035.26.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: xen-devel 
Date: Wed, 24 Oct 2012 14:16:51 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Subject: [Xen-devel] Valgrind support for Xen committed to trunk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thanks to Bart Van Assche the valgrind patches to support Xen privcmd
ioctls which I posted previously have now been committed to the Valgrind
trunk branch (which will eventually become 3.9.0).

Unlike the previous iteration of the patches posted to the list what is
no in tree do not require building against a specific set of Xen
headers. The code currently supports Xen 4.1, 4.2 and unstable versions
of the interfaces used by xl domain create and select other toolstack
operations. I will fault in additional hypercalls and versions on demand
so please report them here if you see messages such as "WARNING:
unhandled hypercall" or "WARNING: unhandled XXX subop".

You can find the code in svn://svn.valgrind.org/valgrind/trunk revision
1308 onwards.

Cheers,
Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 13:17:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 13:17:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR0pT-0003YC-TG; Wed, 24 Oct 2012 13:17:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR0pS-0003Xr-4Q
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 13:17:02 +0000
Received: from [85.158.143.99:22237] by server-2.bemta-4.messagelabs.com id
	82/87-22268-D4AE7805; Wed, 24 Oct 2012 13:17:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1351084620!27184148!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7831 invoked from network); 24 Oct 2012 13:17:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 13:17:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="15358897"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 13:17:00 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 14:17:00 +0100
Message-ID: <1351084618.18035.27.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Eric Dumazet 
Date: Wed, 24 Oct 2012 14:16:58 +0100
In-Reply-To: <1351081703.6537.99.camel@edumazet-glaptop>
References: <1351078936-14159-1-git-send-email-ian.campbell@citrix.com>
	<1351081703.6537.99.camel@edumazet-glaptop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" ,
	Eric Dumazet ,
	"xen-devel@lists.xen.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH] net: allow configuration of the size of
 page in __netdev_alloc_frag
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 13:28 +0100, Eric Dumazet wrote:
> On Wed, 2012-10-24 at 12:42 +0100, Ian Campbell wrote:
> > The commit 69b08f62e174 "net: use bigger pages in __netdev_alloc_frag"
> > lead to 70%+ packet loss under Xen when transmitting from physical (as
> > opposed to virtual) network devices.
> > 
> > This is because under Xen pages which are contiguous in the physical
> > address space may not be contiguous in the DMA space, in fact it is
> > very likely that they are not. I think there are other architectures
> > where this is true, although perhaps non quite so aggressive as to
> > have this property at a per-order-0-page granularity.
> > 
> > The real underlying bug here most likely lies in the swiotlb not
> > correctly handling compound pages, and Konrad is investigating this.
> > However even with the swiotlb issue fixed the current arrangement
> > seems likely to result in a lot of bounce buffering which seems likely
> > to more than offset any benefit from the use of larger pages.
> > 
> > Therefore make NETDEV_FRAG_PAGE_MAX_ORDER configurable at runtime and
> > use this to request order-0 frags under Xen. Also expose this setting
> > via sysctl.
> > 
> > Signed-off-by: Ian Campbell 
> > Cc: Eric Dumazet 
> > Cc: Konrad Rzeszutek Wilk 
> > Cc: netdev@vger.kernel.org
> > Cc: xen-devel@lists.xen.org
> > ---
> 
> I understand your concern, but this seems a quick/dirty hack at this
> moment. After setting the sysctl to 0, some tasks may still have some
> order-3 pages in their cache.

Right, the sysctl thing might be overkill, I just figured it was useful
for debugging. When booting in a Xen VM the patch sets it to zero very
early on, during setup_arch(), which is before any tasks even exist.

> Your driver must already cope with skb->head being split on several
> pages.
> 
> So what fundamental difference exists with frags ?

The issue here is with drivers for physical network devices when running
under Xen not with the Xen paravirtualised network drivers (AKA
netback/netfront).

The problem is that pages which are contiguous in the physical address
space may not be contiguous in the DMA address space. With order>0 pages
this becomes a problem when you poke down the DMA address and length of
a compound page into the hardware registers. The DMA address will be
right for the head of the page but once the hardware steps off the end
of that it'll get the wrong page.

I don't think this non-contiguousness between physical and DMA addresses
is specific to Xen, although it is more frequent under Xen than any real
hardware platform. (Xen has often been a good canary for these sorts of
issues which turn out later on to impact other arches too.)

In theory this could be fixed in all the drivers for physical network
devices, but that would be a lot of effort (and probably a fair bit of
ugliness in the drivers) for a gain which was only relevant to Xen. 

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 13:17:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 13:17:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR0pT-0003YC-TG; Wed, 24 Oct 2012 13:17:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR0pS-0003Xr-4Q
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 13:17:02 +0000
Received: from [85.158.143.99:22237] by server-2.bemta-4.messagelabs.com id
	82/87-22268-D4AE7805; Wed, 24 Oct 2012 13:17:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1351084620!27184148!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7831 invoked from network); 24 Oct 2012 13:17:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 13:17:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="15358897"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 13:17:00 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 14:17:00 +0100
Message-ID: <1351084618.18035.27.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Eric Dumazet 
Date: Wed, 24 Oct 2012 14:16:58 +0100
In-Reply-To: <1351081703.6537.99.camel@edumazet-glaptop>
References: <1351078936-14159-1-git-send-email-ian.campbell@citrix.com>
	<1351081703.6537.99.camel@edumazet-glaptop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" ,
	Eric Dumazet ,
	"xen-devel@lists.xen.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH] net: allow configuration of the size of
 page in __netdev_alloc_frag
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 13:28 +0100, Eric Dumazet wrote:
> On Wed, 2012-10-24 at 12:42 +0100, Ian Campbell wrote:
> > The commit 69b08f62e174 "net: use bigger pages in __netdev_alloc_frag"
> > lead to 70%+ packet loss under Xen when transmitting from physical (as
> > opposed to virtual) network devices.
> > 
> > This is because under Xen pages which are contiguous in the physical
> > address space may not be contiguous in the DMA space, in fact it is
> > very likely that they are not. I think there are other architectures
> > where this is true, although perhaps non quite so aggressive as to
> > have this property at a per-order-0-page granularity.
> > 
> > The real underlying bug here most likely lies in the swiotlb not
> > correctly handling compound pages, and Konrad is investigating this.
> > However even with the swiotlb issue fixed the current arrangement
> > seems likely to result in a lot of bounce buffering which seems likely
> > to more than offset any benefit from the use of larger pages.
> > 
> > Therefore make NETDEV_FRAG_PAGE_MAX_ORDER configurable at runtime and
> > use this to request order-0 frags under Xen. Also expose this setting
> > via sysctl.
> > 
> > Signed-off-by: Ian Campbell 
> > Cc: Eric Dumazet 
> > Cc: Konrad Rzeszutek Wilk 
> > Cc: netdev@vger.kernel.org
> > Cc: xen-devel@lists.xen.org
> > ---
> 
> I understand your concern, but this seems a quick/dirty hack at this
> moment. After setting the sysctl to 0, some tasks may still have some
> order-3 pages in their cache.

Right, the sysctl thing might be overkill, I just figured it was useful
for debugging. When booting in a Xen VM the patch sets it to zero very
early on, during setup_arch(), which is before any tasks even exist.

> Your driver must already cope with skb->head being split on several
> pages.
> 
> So what fundamental difference exists with frags ?

The issue here is with drivers for physical network devices when running
under Xen not with the Xen paravirtualised network drivers (AKA
netback/netfront).

The problem is that pages which are contiguous in the physical address
space may not be contiguous in the DMA address space. With order>0 pages
this becomes a problem when you poke down the DMA address and length of
a compound page into the hardware registers. The DMA address will be
right for the head of the page but once the hardware steps off the end
of that it'll get the wrong page.

I don't think this non-contiguousness between physical and DMA addresses
is specific to Xen, although it is more frequent under Xen than any real
hardware platform. (Xen has often been a good canary for these sorts of
issues which turn out later on to impact other arches too.)

In theory this could be fixed in all the drivers for physical network
devices, but that would be a lot of effort (and probably a fair bit of
ugliness in the drivers) for a gain which was only relevant to Xen. 

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 13:19:34 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 13:19:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR0rh-0003lw-5R; Wed, 24 Oct 2012 13:19:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR0rf-0003lm-Lu
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 13:19:19 +0000
Received: from [85.158.143.99:31493] by server-1.bemta-4.messagelabs.com id
	32/54-19134-6DAE7805; Wed, 24 Oct 2012 13:19:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1351084758!27184533!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15688 invoked from network); 24 Oct 2012 13:19:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 13:19:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="15358978"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 13:19:18 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 14:19:18 +0100
Message-ID: <1351084756.18035.28.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 24 Oct 2012 14:19:16 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	linux-kernel ,
	xen-devel 
Subject: [Xen-devel] [PATCH+GIT V3 0/5] arm: implement ballooning and
 privcmd foreign mappings based on x86 PVH
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is rebased onto 0e9e3e306c7e (AKA current Linus, which now includes
the previously prerequisite series "xen: build fixes and interface
tweaks") and Konrad's stable/pvh.v5 branch.

For convenience I've also pushed to 
        git://xenbits.xen.org/people/ianc/linux.git
        arm-privcmd-on-x86-pvh5
Note that this contains my merge of Konrad's branch into Linus' tree at
the base. You might want to cherry pick it rather than merge it.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 13:19:34 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 13:19:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR0rh-0003lw-5R; Wed, 24 Oct 2012 13:19:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR0rf-0003lm-Lu
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 13:19:19 +0000
Received: from [85.158.143.99:31493] by server-1.bemta-4.messagelabs.com id
	32/54-19134-6DAE7805; Wed, 24 Oct 2012 13:19:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1351084758!27184533!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15688 invoked from network); 24 Oct 2012 13:19:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 13:19:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="15358978"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 13:19:18 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 14:19:18 +0100
Message-ID: <1351084756.18035.28.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 24 Oct 2012 14:19:16 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	linux-kernel ,
	xen-devel 
Subject: [Xen-devel] [PATCH+GIT V3 0/5] arm: implement ballooning and
 privcmd foreign mappings based on x86 PVH
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is rebased onto 0e9e3e306c7e (AKA current Linus, which now includes
the previously prerequisite series "xen: build fixes and interface
tweaks") and Konrad's stable/pvh.v5 branch.

For convenience I've also pushed to 
        git://xenbits.xen.org/people/ianc/linux.git
        arm-privcmd-on-x86-pvh5
Note that this contains my merge of Konrad's branch into Linus' tree at
the base. You might want to cherry pick it rather than merge it.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 13:19:57 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 13:19:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR0s2-0003ok-Va; Wed, 24 Oct 2012 13:19:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR0s2-0003oM-2n
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 13:19:42 +0000
Received: from [85.158.139.211:10157] by server-3.bemta-5.messagelabs.com id
	17/F3-28618-DEAE7805; Wed, 24 Oct 2012 13:19:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1351084778!22044937!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzg3MDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11270 invoked from network); 24 Oct 2012 13:19:40 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 13:19:40 -0000
X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="42269817"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 13:19:38 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 09:19:38 -0400
Received: from drall.uk.xensource.com ([10.80.227.107])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TR0rx-0004kX-M2;
	Wed, 24 Oct 2012 14:19:37 +0100
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 24 Oct 2012 14:19:33 +0100
Message-ID: <1351084777-28898-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1351084756.18035.28.camel@zakaz.uk.xensource.com>
References: <1351084756.18035.28.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell ,
	Stefano Stabellini ,
	linux-kernel ,
	xen-devel 
Subject: [Xen-devel] [PATCH 1/5] xen: balloon: allow PVMMU interfaces to be
	compiled out
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The ARM platform has no concept of PVMMU and therefor no
HYPERVISOR_update_va_mapping et al. Allow this code to be compiled out
when not required.

In some similar situations (e.g. P2M) we have defined dummy functions
to avoid this, however I think we can/should draw the line at dummying
out actual hypercalls.

Signed-off-by: Ian Campbell 
---
 arch/x86/xen/Kconfig  |    1 +
 drivers/xen/Kconfig   |    3 +++
 drivers/xen/balloon.c |    4 ++++
 3 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index c9660bf..7e938ba 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -6,6 +6,7 @@ config XEN
 	bool "Xen guest support"
 	select PARAVIRT
 	select PARAVIRT_CLOCK
+	select XEN_HAVE_PVMMU
 	depends on X86_64 || (X86_32 && X86_PAE && !X86_VISWS)
 	depends on X86_CMPXCHG && X86_TSC
 	help
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index d4dffcd..9c00652 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -204,4 +204,7 @@ config XEN_MCE_LOG
 	  Allow kernel fetching MCE error from Xen platform and
 	  converting it into Linux mcelog format for mcelog tools
 
+config XEN_HAVE_PVMMU
+       bool
+
 endmenu
diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 66fad33..d42da3b 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -359,6 +359,7 @@ static enum bp_state increase_reservation(unsigned long nr_pages)
 
 		set_phys_to_machine(pfn, frame_list[i]);
 
+#ifdef CONFIG_XEN_HAVE_PVMMU
 		/* Link back into the page tables if not highmem. */
 		if (xen_pv_domain() && !PageHighMem(page) &&
 		    !xen_feature(XENFEAT_auto_translated_physmap)) {
@@ -370,6 +371,7 @@ static enum bp_state increase_reservation(unsigned long nr_pages)
 				0);
 			BUG_ON(ret);
 		}
+#endif
 
 		/* Relinquish the page back to the allocator. */
 		ClearPageReserved(page);
@@ -418,6 +420,7 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
 
 		scrub_page(page);
 
+#ifdef CONFIG_XEN_HAVE_PVMMU
 		if (xen_pv_domain() && !PageHighMem(page)) {
 			if (!xen_feature(XENFEAT_auto_translated_physmap)) {
 				ret = HYPERVISOR_update_va_mapping(
@@ -426,6 +429,7 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
 				BUG_ON(ret);
 			}
 		}
+#endif
 	}
 
 	/* Ensure that ballooned highmem pages don't have kmaps. */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 13:19:57 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 13:19:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR0s2-0003ok-Va; Wed, 24 Oct 2012 13:19:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR0s2-0003oM-2n
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 13:19:42 +0000
Received: from [85.158.139.211:10157] by server-3.bemta-5.messagelabs.com id
	17/F3-28618-DEAE7805; Wed, 24 Oct 2012 13:19:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1351084778!22044937!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzg3MDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11270 invoked from network); 24 Oct 2012 13:19:40 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 13:19:40 -0000
X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="42269817"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 13:19:38 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 09:19:38 -0400
Received: from drall.uk.xensource.com ([10.80.227.107])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TR0rx-0004kX-M2;
	Wed, 24 Oct 2012 14:19:37 +0100
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 24 Oct 2012 14:19:33 +0100
Message-ID: <1351084777-28898-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1351084756.18035.28.camel@zakaz.uk.xensource.com>
References: <1351084756.18035.28.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell ,
	Stefano Stabellini ,
	linux-kernel ,
	xen-devel 
Subject: [Xen-devel] [PATCH 1/5] xen: balloon: allow PVMMU interfaces to be
	compiled out
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The ARM platform has no concept of PVMMU and therefor no
HYPERVISOR_update_va_mapping et al. Allow this code to be compiled out
when not required.

In some similar situations (e.g. P2M) we have defined dummy functions
to avoid this, however I think we can/should draw the line at dummying
out actual hypercalls.

Signed-off-by: Ian Campbell 
---
 arch/x86/xen/Kconfig  |    1 +
 drivers/xen/Kconfig   |    3 +++
 drivers/xen/balloon.c |    4 ++++
 3 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index c9660bf..7e938ba 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -6,6 +6,7 @@ config XEN
 	bool "Xen guest support"
 	select PARAVIRT
 	select PARAVIRT_CLOCK
+	select XEN_HAVE_PVMMU
 	depends on X86_64 || (X86_32 && X86_PAE && !X86_VISWS)
 	depends on X86_CMPXCHG && X86_TSC
 	help
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index d4dffcd..9c00652 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -204,4 +204,7 @@ config XEN_MCE_LOG
 	  Allow kernel fetching MCE error from Xen platform and
 	  converting it into Linux mcelog format for mcelog tools
 
+config XEN_HAVE_PVMMU
+       bool
+
 endmenu
diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 66fad33..d42da3b 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -359,6 +359,7 @@ static enum bp_state increase_reservation(unsigned long nr_pages)
 
 		set_phys_to_machine(pfn, frame_list[i]);
 
+#ifdef CONFIG_XEN_HAVE_PVMMU
 		/* Link back into the page tables if not highmem. */
 		if (xen_pv_domain() && !PageHighMem(page) &&
 		    !xen_feature(XENFEAT_auto_translated_physmap)) {
@@ -370,6 +371,7 @@ static enum bp_state increase_reservation(unsigned long nr_pages)
 				0);
 			BUG_ON(ret);
 		}
+#endif
 
 		/* Relinquish the page back to the allocator. */
 		ClearPageReserved(page);
@@ -418,6 +420,7 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
 
 		scrub_page(page);
 
+#ifdef CONFIG_XEN_HAVE_PVMMU
 		if (xen_pv_domain() && !PageHighMem(page)) {
 			if (!xen_feature(XENFEAT_auto_translated_physmap)) {
 				ret = HYPERVISOR_update_va_mapping(
@@ -426,6 +429,7 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
 				BUG_ON(ret);
 			}
 		}
+#endif
 	}
 
 	/* Ensure that ballooned highmem pages don't have kmaps. */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 13:19:57 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 13:19:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR0s4-0003pP-PO; Wed, 24 Oct 2012 13:19:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR0s3-0003oi-D0
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 13:19:43 +0000
Received: from [85.158.139.211:30079] by server-4.bemta-5.messagelabs.com id
	46/88-01455-EEAE7805; Wed, 24 Oct 2012 13:19:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1351084778!22044937!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzg3MDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11369 invoked from network); 24 Oct 2012 13:19:41 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 13:19:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="42269820"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 13:19:38 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 09:19:38 -0400
Received: from drall.uk.xensource.com ([10.80.227.107])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TR0rx-0004kX-RS;
	Wed, 24 Oct 2012 14:19:37 +0100
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 24 Oct 2012 14:19:37 +0100
Message-ID: <1351084777-28898-5-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1351084756.18035.28.camel@zakaz.uk.xensource.com>
References: <1351084756.18035.28.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell ,
	Stefano Stabellini ,
	linux-kernel ,
	xen-devel 
Subject: [Xen-devel] [PATCH 5/5] xen: x86 pvh: use
	XENMEM_add_to_physmap_range for foreign gmfn mappings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Squeezing the necessary fields into the existing XENMEM_add_to_physmap
interface was proving to be a bit tricky so we have decided to go with
a new interface upstream (the XENMAPSPACE_gmfn_foreign interface using
XENMEM_add_to_physmap was never committed anywhere). This interface
also allows for batching which was impossible to support at the same
time as foreign mfns in the old interface.

This reverts the relevant parts of "PVH: basic and header changes,
elfnote changes, ..." and followups and trivially converts
pvh_add_to_xen_p2m over.

Signed-off-by: Ian Campbell 
Acked-by: Stefano Stabellini 
---
 arch/x86/xen/enlighten.c       |    1 -
 arch/x86/xen/mmu.c             |   18 ++++++++++++------
 drivers/xen/grant-table.c      |    1 -
 include/xen/interface/memory.h |   18 +++++++++---------
 4 files changed, 21 insertions(+), 17 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index bf6313b..eb9a567 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1546,7 +1546,6 @@ void __ref xen_hvm_init_shared_info(void)
 	xatp.domid = DOMID_SELF;
 	xatp.idx = 0;
 	xatp.space = XENMAPSPACE_shared_info;
-	xatp.foreign_domid = 0;
 	xatp.gpfn = __pa(shared_info_page) >> PAGE_SHIFT;
 	if (HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp))
 		BUG();
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 58f2084..fee34fe 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -2500,13 +2500,19 @@ static int pvh_add_to_xen_p2m(unsigned long lpfn, unsigned long fgmfn,
 			      unsigned int domid)
 {
 	int rc;
-	struct xen_add_to_physmap xatp = { .foreign_domid = domid };
+	struct xen_add_to_physmap_range xatp = {
+		.domid = DOMID_SELF,
+		.foreign_domid = domid,
+		.size = 1,
+		.space = XENMAPSPACE_gmfn_foreign,
+	};
+	xen_ulong_t idx = fgmfn;
+	xen_pfn_t gpfn = lpfn;
+
+	set_xen_guest_handle(xatp.idxs, &idx);
+	set_xen_guest_handle(xatp.gpfns, &gpfn);
 
-	xatp.gpfn = lpfn;
-	xatp.idx = fgmfn;
-	xatp.domid = DOMID_SELF;
-	xatp.space = XENMAPSPACE_gmfn_foreign;
-	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
+	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap_range, &xatp);
 	if (rc)
 		pr_warn("d0: Failed to map pfn (0x%lx) to mfn (0x%lx) rc:%d\n",
 			lpfn, fgmfn, rc);
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index adaa4c2..1ab8630 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -1049,7 +1049,6 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 		do {
 			xatp.domid = DOMID_SELF;
 			xatp.idx = i;
-			xatp.foreign_domid = 0;
 			xatp.space = XENMAPSPACE_grant_table;
 			xatp.gpfn = start_gpfn + i;
 			rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index 5de2b36..9dad393 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -153,6 +153,14 @@ struct xen_machphys_mapping {
 };
 DEFINE_GUEST_HANDLE_STRUCT(xen_machphys_mapping_t);
 
+#define XENMAPSPACE_shared_info  0 /* shared info page */
+#define XENMAPSPACE_grant_table  1 /* grant table page */
+#define XENMAPSPACE_gmfn         2 /* GMFN */
+#define XENMAPSPACE_gmfn_range   3 /* GMFN range, XENMEM_add_to_physmap only. */
+#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another dom,
+				    * XENMEM_add_to_physmap_range only.
+				    */
+
 /*
  * Sets the GPFN at which a particular page appears in the specified guest's
  * pseudophysical address space.
@@ -167,15 +175,7 @@ struct xen_add_to_physmap {
     uint16_t    size;
 
     /* Source mapping space. */
-#define XENMAPSPACE_shared_info 0 /* shared info page */
-#define XENMAPSPACE_grant_table 1 /* grant table page */
-#define XENMAPSPACE_gmfn        2 /* GMFN */
-#define XENMAPSPACE_gmfn_range  3 /* GMFN range */
-#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */
-    uint16_t space;
-    domid_t foreign_domid;         /* IFF XENMAPSPACE_gmfn_foreign */
-
-#define XENMAPIDX_grant_table_status 0x80000000
+    unsigned int space;
 
     /* Index into source mapping space. */
     xen_ulong_t idx;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 13:19:57 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 13:19:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR0s4-0003pP-PO; Wed, 24 Oct 2012 13:19:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR0s3-0003oi-D0
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 13:19:43 +0000
Received: from [85.158.139.211:30079] by server-4.bemta-5.messagelabs.com id
	46/88-01455-EEAE7805; Wed, 24 Oct 2012 13:19:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1351084778!22044937!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzg3MDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11369 invoked from network); 24 Oct 2012 13:19:41 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 13:19:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="42269820"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 13:19:38 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 09:19:38 -0400
Received: from drall.uk.xensource.com ([10.80.227.107])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TR0rx-0004kX-RS;
	Wed, 24 Oct 2012 14:19:37 +0100
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 24 Oct 2012 14:19:37 +0100
Message-ID: <1351084777-28898-5-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1351084756.18035.28.camel@zakaz.uk.xensource.com>
References: <1351084756.18035.28.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell ,
	Stefano Stabellini ,
	linux-kernel ,
	xen-devel 
Subject: [Xen-devel] [PATCH 5/5] xen: x86 pvh: use
	XENMEM_add_to_physmap_range for foreign gmfn mappings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Squeezing the necessary fields into the existing XENMEM_add_to_physmap
interface was proving to be a bit tricky so we have decided to go with
a new interface upstream (the XENMAPSPACE_gmfn_foreign interface using
XENMEM_add_to_physmap was never committed anywhere). This interface
also allows for batching which was impossible to support at the same
time as foreign mfns in the old interface.

This reverts the relevant parts of "PVH: basic and header changes,
elfnote changes, ..." and followups and trivially converts
pvh_add_to_xen_p2m over.

Signed-off-by: Ian Campbell 
Acked-by: Stefano Stabellini 
---
 arch/x86/xen/enlighten.c       |    1 -
 arch/x86/xen/mmu.c             |   18 ++++++++++++------
 drivers/xen/grant-table.c      |    1 -
 include/xen/interface/memory.h |   18 +++++++++---------
 4 files changed, 21 insertions(+), 17 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index bf6313b..eb9a567 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1546,7 +1546,6 @@ void __ref xen_hvm_init_shared_info(void)
 	xatp.domid = DOMID_SELF;
 	xatp.idx = 0;
 	xatp.space = XENMAPSPACE_shared_info;
-	xatp.foreign_domid = 0;
 	xatp.gpfn = __pa(shared_info_page) >> PAGE_SHIFT;
 	if (HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp))
 		BUG();
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 58f2084..fee34fe 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -2500,13 +2500,19 @@ static int pvh_add_to_xen_p2m(unsigned long lpfn, unsigned long fgmfn,
 			      unsigned int domid)
 {
 	int rc;
-	struct xen_add_to_physmap xatp = { .foreign_domid = domid };
+	struct xen_add_to_physmap_range xatp = {
+		.domid = DOMID_SELF,
+		.foreign_domid = domid,
+		.size = 1,
+		.space = XENMAPSPACE_gmfn_foreign,
+	};
+	xen_ulong_t idx = fgmfn;
+	xen_pfn_t gpfn = lpfn;
+
+	set_xen_guest_handle(xatp.idxs, &idx);
+	set_xen_guest_handle(xatp.gpfns, &gpfn);
 
-	xatp.gpfn = lpfn;
-	xatp.idx = fgmfn;
-	xatp.domid = DOMID_SELF;
-	xatp.space = XENMAPSPACE_gmfn_foreign;
-	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
+	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap_range, &xatp);
 	if (rc)
 		pr_warn("d0: Failed to map pfn (0x%lx) to mfn (0x%lx) rc:%d\n",
 			lpfn, fgmfn, rc);
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index adaa4c2..1ab8630 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -1049,7 +1049,6 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 		do {
 			xatp.domid = DOMID_SELF;
 			xatp.idx = i;
-			xatp.foreign_domid = 0;
 			xatp.space = XENMAPSPACE_grant_table;
 			xatp.gpfn = start_gpfn + i;
 			rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index 5de2b36..9dad393 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -153,6 +153,14 @@ struct xen_machphys_mapping {
 };
 DEFINE_GUEST_HANDLE_STRUCT(xen_machphys_mapping_t);
 
+#define XENMAPSPACE_shared_info  0 /* shared info page */
+#define XENMAPSPACE_grant_table  1 /* grant table page */
+#define XENMAPSPACE_gmfn         2 /* GMFN */
+#define XENMAPSPACE_gmfn_range   3 /* GMFN range, XENMEM_add_to_physmap only. */
+#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another dom,
+				    * XENMEM_add_to_physmap_range only.
+				    */
+
 /*
  * Sets the GPFN at which a particular page appears in the specified guest's
  * pseudophysical address space.
@@ -167,15 +175,7 @@ struct xen_add_to_physmap {
     uint16_t    size;
 
     /* Source mapping space. */
-#define XENMAPSPACE_shared_info 0 /* shared info page */
-#define XENMAPSPACE_grant_table 1 /* grant table page */
-#define XENMAPSPACE_gmfn        2 /* GMFN */
-#define XENMAPSPACE_gmfn_range  3 /* GMFN range */
-#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */
-    uint16_t space;
-    domid_t foreign_domid;         /* IFF XENMAPSPACE_gmfn_foreign */
-
-#define XENMAPIDX_grant_table_status 0x80000000
+    unsigned int space;
 
     /* Index into source mapping space. */
     xen_ulong_t idx;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 13:19:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 13:19:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR0s2-0003oU-Ju; Wed, 24 Oct 2012 13:19:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR0s1-0003oE-7w
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 13:19:41 +0000
Received: from [85.158.139.211:10113] by server-16.bemta-5.messagelabs.com id
	11/2F-04786-CEAE7805; Wed, 24 Oct 2012 13:19:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1351084778!22044937!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzg3MDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11222 invoked from network); 24 Oct 2012 13:19:39 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 13:19:39 -0000
X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="42269816"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 13:19:38 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 09:19:38 -0400
Received: from drall.uk.xensource.com ([10.80.227.107])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TR0rx-0004kX-Nl;
	Wed, 24 Oct 2012 14:19:37 +0100
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 24 Oct 2012 14:19:34 +0100
Message-ID: <1351084777-28898-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1351084756.18035.28.camel@zakaz.uk.xensource.com>
References: <1351084756.18035.28.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell ,
	Stefano Stabellini ,
	linux-kernel ,
	xen-devel 
Subject: [Xen-devel] [PATCH 2/5] xen: arm: enable balloon driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The code is no in a state where can just enable it.

Drop the *_xenballloned_pages duplicates since these are now supplied
by the balloon code.

Signed-off-by: Ian Campbell 
Acked-by: Stefano Stabellini 
---
 arch/arm/xen/enlighten.c |   23 +++++------------------
 drivers/xen/Makefile     |    4 ++--
 2 files changed, 7 insertions(+), 20 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 59bcb96..ba5cc13 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -29,6 +30,10 @@ struct shared_info *HYPERVISOR_shared_info = (void *)&xen_dummy_shared_info;
 
 DEFINE_PER_CPU(struct vcpu_info *, xen_vcpu);
 
+/* These are unused until we support booting "pre-ballooned" */
+unsigned long xen_released_pages;
+struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata;
+
 /* TODO: to be removed */
 __read_mostly int xen_have_vector_callback;
 EXPORT_SYMBOL_GPL(xen_have_vector_callback);
@@ -148,21 +153,3 @@ static int __init xen_init_events(void)
 	return 0;
 }
 postcore_initcall(xen_init_events);
-
-/* XXX: only until balloon is properly working */
-int alloc_xenballooned_pages(int nr_pages, struct page **pages, bool highmem)
-{
-	*pages = alloc_pages(highmem ? GFP_HIGHUSER : GFP_KERNEL,
-			get_order(nr_pages));
-	if (*pages == NULL)
-		return -ENOMEM;
-	return 0;
-}
-EXPORT_SYMBOL_GPL(alloc_xenballooned_pages);
-
-void free_xenballooned_pages(int nr_pages, struct page **pages)
-{
-	kfree(*pages);
-	*pages = NULL;
-}
-EXPORT_SYMBOL_GPL(free_xenballooned_pages);
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 0e863703..909bb56 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -1,8 +1,8 @@
 ifneq ($(CONFIG_ARM),y)
-obj-y	+= manage.o balloon.o
+obj-y	+= manage.o
 obj-$(CONFIG_HOTPLUG_CPU)		+= cpu_hotplug.o
 endif
-obj-y	+= grant-table.o features.o events.o
+obj-y	+= grant-table.o features.o events.o balloon.o
 obj-y	+= xenbus/
 
 nostackp := $(call cc-option, -fno-stack-protector)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 13:19:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 13:19:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR0s2-0003oU-Ju; Wed, 24 Oct 2012 13:19:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR0s1-0003oE-7w
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 13:19:41 +0000
Received: from [85.158.139.211:10113] by server-16.bemta-5.messagelabs.com id
	11/2F-04786-CEAE7805; Wed, 24 Oct 2012 13:19:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1351084778!22044937!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzg3MDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11222 invoked from network); 24 Oct 2012 13:19:39 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 13:19:39 -0000
X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="42269816"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 13:19:38 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 09:19:38 -0400
Received: from drall.uk.xensource.com ([10.80.227.107])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TR0rx-0004kX-Nl;
	Wed, 24 Oct 2012 14:19:37 +0100
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 24 Oct 2012 14:19:34 +0100
Message-ID: <1351084777-28898-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1351084756.18035.28.camel@zakaz.uk.xensource.com>
References: <1351084756.18035.28.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell ,
	Stefano Stabellini ,
	linux-kernel ,
	xen-devel 
Subject: [Xen-devel] [PATCH 2/5] xen: arm: enable balloon driver
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The code is no in a state where can just enable it.

Drop the *_xenballloned_pages duplicates since these are now supplied
by the balloon code.

Signed-off-by: Ian Campbell 
Acked-by: Stefano Stabellini 
---
 arch/arm/xen/enlighten.c |   23 +++++------------------
 drivers/xen/Makefile     |    4 ++--
 2 files changed, 7 insertions(+), 20 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 59bcb96..ba5cc13 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -29,6 +30,10 @@ struct shared_info *HYPERVISOR_shared_info = (void *)&xen_dummy_shared_info;
 
 DEFINE_PER_CPU(struct vcpu_info *, xen_vcpu);
 
+/* These are unused until we support booting "pre-ballooned" */
+unsigned long xen_released_pages;
+struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata;
+
 /* TODO: to be removed */
 __read_mostly int xen_have_vector_callback;
 EXPORT_SYMBOL_GPL(xen_have_vector_callback);
@@ -148,21 +153,3 @@ static int __init xen_init_events(void)
 	return 0;
 }
 postcore_initcall(xen_init_events);
-
-/* XXX: only until balloon is properly working */
-int alloc_xenballooned_pages(int nr_pages, struct page **pages, bool highmem)
-{
-	*pages = alloc_pages(highmem ? GFP_HIGHUSER : GFP_KERNEL,
-			get_order(nr_pages));
-	if (*pages == NULL)
-		return -ENOMEM;
-	return 0;
-}
-EXPORT_SYMBOL_GPL(alloc_xenballooned_pages);
-
-void free_xenballooned_pages(int nr_pages, struct page **pages)
-{
-	kfree(*pages);
-	*pages = NULL;
-}
-EXPORT_SYMBOL_GPL(free_xenballooned_pages);
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 0e863703..909bb56 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -1,8 +1,8 @@
 ifneq ($(CONFIG_ARM),y)
-obj-y	+= manage.o balloon.o
+obj-y	+= manage.o
 obj-$(CONFIG_HOTPLUG_CPU)		+= cpu_hotplug.o
 endif
-obj-y	+= grant-table.o features.o events.o
+obj-y	+= grant-table.o features.o events.o balloon.o
 obj-y	+= xenbus/
 
 nostackp := $(call cc-option, -fno-stack-protector)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 13:19:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 13:19:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR0s4-0003p9-Ce; Wed, 24 Oct 2012 13:19:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR0s2-0003oO-IV
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 13:19:42 +0000
Received: from [85.158.139.211:30036] by server-14.bemta-5.messagelabs.com id
	99/97-21768-DEAE7805; Wed, 24 Oct 2012 13:19:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1351084778!22044937!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzg3MDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11318 invoked from network); 24 Oct 2012 13:19:41 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 13:19:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="42269818"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 13:19:38 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 09:19:38 -0400
Received: from drall.uk.xensource.com ([10.80.227.107])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TR0rx-0004kX-PO;
	Wed, 24 Oct 2012 14:19:37 +0100
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 24 Oct 2012 14:19:35 +0100
Message-ID: <1351084777-28898-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1351084756.18035.28.camel@zakaz.uk.xensource.com>
References: <1351084756.18035.28.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell ,
	Stefano Stabellini ,
	linux-kernel ,
	xen-devel 
Subject: [Xen-devel] [PATCH 3/5] xen: correctly use xen_pfn_t in
	remap_domain_mfn_range.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

For Xen on ARM a PFN is 64 bits so we need to use the appropriate
type here.

Signed-off-by: Ian Campbell 
Acked-by: Stefano Stabellini 
---
 arch/x86/xen/mmu.c    |    2 +-
 include/xen/xen-ops.h |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 5747a41..58f2084 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -2599,7 +2599,7 @@ static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token,
 
 int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 			       unsigned long addr,
-			       unsigned long mfn, int nr,
+			       xen_pfn_t mfn, int nr,
 			       pgprot_t prot, unsigned domid,
 			       struct page **pages)
 
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 990b43e..ee188eb 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -26,7 +26,7 @@ void xen_destroy_contiguous_region(unsigned long vstart, unsigned int order);
 struct vm_area_struct;
 int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 			       unsigned long addr,
-			       unsigned long mfn, int nr,
+			       xen_pfn_t mfn, int nr,
 			       pgprot_t prot, unsigned domid,
 			       struct page **pages);
 int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 13:19:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 13:19:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR0s4-0003p9-Ce; Wed, 24 Oct 2012 13:19:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR0s2-0003oO-IV
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 13:19:42 +0000
Received: from [85.158.139.211:30036] by server-14.bemta-5.messagelabs.com id
	99/97-21768-DEAE7805; Wed, 24 Oct 2012 13:19:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1351084778!22044937!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzg3MDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11318 invoked from network); 24 Oct 2012 13:19:41 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 13:19:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="42269818"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 13:19:38 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 09:19:38 -0400
Received: from drall.uk.xensource.com ([10.80.227.107])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TR0rx-0004kX-PO;
	Wed, 24 Oct 2012 14:19:37 +0100
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 24 Oct 2012 14:19:35 +0100
Message-ID: <1351084777-28898-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1351084756.18035.28.camel@zakaz.uk.xensource.com>
References: <1351084756.18035.28.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell ,
	Stefano Stabellini ,
	linux-kernel ,
	xen-devel 
Subject: [Xen-devel] [PATCH 3/5] xen: correctly use xen_pfn_t in
	remap_domain_mfn_range.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

For Xen on ARM a PFN is 64 bits so we need to use the appropriate
type here.

Signed-off-by: Ian Campbell 
Acked-by: Stefano Stabellini 
---
 arch/x86/xen/mmu.c    |    2 +-
 include/xen/xen-ops.h |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 5747a41..58f2084 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -2599,7 +2599,7 @@ static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token,
 
 int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 			       unsigned long addr,
-			       unsigned long mfn, int nr,
+			       xen_pfn_t mfn, int nr,
 			       pgprot_t prot, unsigned domid,
 			       struct page **pages)
 
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 990b43e..ee188eb 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -26,7 +26,7 @@ void xen_destroy_contiguous_region(unsigned long vstart, unsigned int order);
 struct vm_area_struct;
 int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 			       unsigned long addr,
-			       unsigned long mfn, int nr,
+			       xen_pfn_t mfn, int nr,
 			       pgprot_t prot, unsigned domid,
 			       struct page **pages);
 int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 13:20:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 13:20:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR0sI-0003uh-6G; Wed, 24 Oct 2012 13:19:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR0sG-0003tb-Ss
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 13:19:57 +0000
Received: from [85.158.143.99:35635] by server-1.bemta-4.messagelabs.com id
	92/55-19134-CFAE7805; Wed, 24 Oct 2012 13:19:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1351084780!35404902!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzg3MDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8753 invoked from network); 24 Oct 2012 13:19:41 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 13:19:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="42269819"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 13:19:38 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 09:19:38 -0400
Received: from drall.uk.xensource.com ([10.80.227.107])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TR0rx-0004kX-Pq;
	Wed, 24 Oct 2012 14:19:37 +0100
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 24 Oct 2012 14:19:36 +0100
Message-ID: <1351084777-28898-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1351084756.18035.28.camel@zakaz.uk.xensource.com>
References: <1351084756.18035.28.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell ,
	Stefano Stabellini ,
	linux-kernel ,
	xen-devel 
Subject: [Xen-devel] [PATCH 4/5] xen: arm: implement remap interfaces needed
	for privcmd mappings.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We use XENMEM_add_to_physmap_range which is the preferred interface
for foreign mappings.

Signed-off-by: Ian Campbell 
---
 arch/arm/include/asm/xen/interface.h |    1 +
 arch/arm/xen/enlighten.c             |  100 +++++++++++++++++++++++++++++++++-
 arch/x86/include/asm/xen/interface.h |    1 +
 include/xen/interface/memory.h       |   18 ++++++
 4 files changed, 117 insertions(+), 3 deletions(-)

diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
index 5000397..1151188 100644
--- a/arch/arm/include/asm/xen/interface.h
+++ b/arch/arm/include/asm/xen/interface.h
@@ -49,6 +49,7 @@ DEFINE_GUEST_HANDLE(void);
 DEFINE_GUEST_HANDLE(uint64_t);
 DEFINE_GUEST_HANDLE(uint32_t);
 DEFINE_GUEST_HANDLE(xen_pfn_t);
+DEFINE_GUEST_HANDLE(xen_ulong_t);
 
 /* Maximum number of virtual CPUs in multi-processor guests. */
 #define MAX_VIRT_CPUS 1
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index ba5cc13..f28fc1a 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -18,6 +19,8 @@
 #include 
 #include 
 
+#include 
+
 struct start_info _xen_start_info;
 struct start_info *xen_start_info = &_xen_start_info;
 EXPORT_SYMBOL_GPL(xen_start_info);
@@ -43,15 +46,106 @@ EXPORT_SYMBOL_GPL(xen_platform_pci_unplug);
 
 static __read_mostly int xen_events_irq = -1;
 
+/* map fgmfn of domid to lpfn in the current domain */
+static int map_foreign_page(unsigned long lpfn, unsigned long fgmfn,
+			    unsigned int domid)
+{
+	int rc;
+	struct xen_add_to_physmap_range xatp = {
+		.domid = DOMID_SELF,
+		.foreign_domid = domid,
+		.size = 1,
+		.space = XENMAPSPACE_gmfn_foreign,
+	};
+	xen_ulong_t idx = fgmfn;
+	xen_pfn_t gpfn = lpfn;
+
+	set_xen_guest_handle(xatp.idxs, &idx);
+	set_xen_guest_handle(xatp.gpfns, &gpfn);
+
+	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap_range, &xatp);
+	if (rc) {
+		pr_warn("Failed to map pfn to mfn rc:%d pfn:%lx mfn:%lx\n",
+			rc, lpfn, fgmfn);
+		return 1;
+	}
+	return 0;
+}
+
+struct remap_data {
+	xen_pfn_t fgmfn; /* foreign domain's gmfn */
+	pgprot_t prot;
+	domid_t  domid;
+	struct vm_area_struct *vma;
+	int index;
+	struct page **pages;
+	struct xen_remap_mfn_info *info;
+};
+
+static int remap_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr,
+			void *data)
+{
+	struct remap_data *info = data;
+	struct page *page = info->pages[info->index++];
+	unsigned long pfn = page_to_pfn(page);
+	pte_t pte = pfn_pte(pfn, info->prot);
+
+	if (map_foreign_page(pfn, info->fgmfn, info->domid))
+		return -EFAULT;
+	set_pte_at(info->vma->vm_mm, addr, ptep, pte);
+
+	return 0;
+}
+
 int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 			       unsigned long addr,
-			       unsigned long mfn, int nr,
-			       pgprot_t prot, unsigned domid)
+			       xen_pfn_t mfn, int nr,
+			       pgprot_t prot, unsigned domid,
+			       struct page **pages)
 {
-	return -ENOSYS;
+	int err;
+	struct remap_data data;
+
+	/* TBD: Batching, current sole caller only does page at a time */
+	if (nr > 1)
+		return -EINVAL;
+
+	data.fgmfn = mfn;
+	data.prot = prot;
+	data.domid = domid;
+	data.vma = vma;
+	data.index = 0;
+	data.pages = pages;
+	err = apply_to_page_range(vma->vm_mm, addr, nr << PAGE_SHIFT,
+				  remap_pte_fn, &data);
+	return err;
 }
 EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
 
+int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
+			       int nr, struct page **pages)
+{
+	int i;
+
+	for (i = 0; i < nr; i++) {
+		struct xen_remove_from_physmap xrp;
+		unsigned long rc, pfn;
+
+		pfn = page_to_pfn(pages[i]);
+
+		xrp.domid = DOMID_SELF;
+		xrp.gpfn = pfn;
+		rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, &xrp);
+		if (rc) {
+			pr_warn("Failed to unmap pfn:%lx rc:%ld\n",
+				pfn, rc);
+			return rc;
+		}
+	}
+	return 0;
+}
+EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range);
+
 /*
  * see Documentation/devicetree/bindings/arm/xen.txt for the
  * documentation of the Xen Device Tree format.
diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
index b459d2e..20e738a 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -63,6 +63,7 @@ DEFINE_GUEST_HANDLE(void);
 DEFINE_GUEST_HANDLE(uint64_t);
 DEFINE_GUEST_HANDLE(uint32_t);
 DEFINE_GUEST_HANDLE(xen_pfn_t);
+DEFINE_GUEST_HANDLE(xen_ulong_t);
 #endif
 
 #ifndef HYPERVISOR_VIRT_START
diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index ad0dff5..5de2b36 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -188,6 +188,24 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_physmap);
 /*** REMOVED ***/
 /*#define XENMEM_translate_gpfn_list  8*/
 
+#define XENMEM_add_to_physmap_range 23
+struct xen_add_to_physmap_range {
+    /* Which domain to change the mapping for. */
+    domid_t domid;
+    uint16_t space; /* => enum phys_map_space */
+
+    /* Number of pages to go through */
+    uint16_t size;
+    domid_t foreign_domid; /* IFF gmfn_foreign */
+
+    /* Indexes into space being mapped. */
+    GUEST_HANDLE(xen_ulong_t) idxs;
+
+    /* GPFN in domid where the source mapping page should appear. */
+    GUEST_HANDLE(xen_pfn_t) gpfns;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_physmap_range);
+
 /*
  * Returns the pseudo-physical memory map as it was when the domain
  * was started (specified by XENMEM_set_memory_map).
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 13:20:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 13:20:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR0sI-0003uh-6G; Wed, 24 Oct 2012 13:19:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR0sG-0003tb-Ss
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 13:19:57 +0000
Received: from [85.158.143.99:35635] by server-1.bemta-4.messagelabs.com id
	92/55-19134-CFAE7805; Wed, 24 Oct 2012 13:19:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1351084780!35404902!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzg3MDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8753 invoked from network); 24 Oct 2012 13:19:41 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 13:19:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="42269819"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 13:19:38 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 09:19:38 -0400
Received: from drall.uk.xensource.com ([10.80.227.107])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TR0rx-0004kX-Pq;
	Wed, 24 Oct 2012 14:19:37 +0100
From: Ian Campbell 
To: Konrad Rzeszutek Wilk 
Date: Wed, 24 Oct 2012 14:19:36 +0100
Message-ID: <1351084777-28898-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1351084756.18035.28.camel@zakaz.uk.xensource.com>
References: <1351084756.18035.28.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell ,
	Stefano Stabellini ,
	linux-kernel ,
	xen-devel 
Subject: [Xen-devel] [PATCH 4/5] xen: arm: implement remap interfaces needed
	for privcmd mappings.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

We use XENMEM_add_to_physmap_range which is the preferred interface
for foreign mappings.

Signed-off-by: Ian Campbell 
---
 arch/arm/include/asm/xen/interface.h |    1 +
 arch/arm/xen/enlighten.c             |  100 +++++++++++++++++++++++++++++++++-
 arch/x86/include/asm/xen/interface.h |    1 +
 include/xen/interface/memory.h       |   18 ++++++
 4 files changed, 117 insertions(+), 3 deletions(-)

diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
index 5000397..1151188 100644
--- a/arch/arm/include/asm/xen/interface.h
+++ b/arch/arm/include/asm/xen/interface.h
@@ -49,6 +49,7 @@ DEFINE_GUEST_HANDLE(void);
 DEFINE_GUEST_HANDLE(uint64_t);
 DEFINE_GUEST_HANDLE(uint32_t);
 DEFINE_GUEST_HANDLE(xen_pfn_t);
+DEFINE_GUEST_HANDLE(xen_ulong_t);
 
 /* Maximum number of virtual CPUs in multi-processor guests. */
 #define MAX_VIRT_CPUS 1
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index ba5cc13..f28fc1a 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -18,6 +19,8 @@
 #include 
 #include 
 
+#include 
+
 struct start_info _xen_start_info;
 struct start_info *xen_start_info = &_xen_start_info;
 EXPORT_SYMBOL_GPL(xen_start_info);
@@ -43,15 +46,106 @@ EXPORT_SYMBOL_GPL(xen_platform_pci_unplug);
 
 static __read_mostly int xen_events_irq = -1;
 
+/* map fgmfn of domid to lpfn in the current domain */
+static int map_foreign_page(unsigned long lpfn, unsigned long fgmfn,
+			    unsigned int domid)
+{
+	int rc;
+	struct xen_add_to_physmap_range xatp = {
+		.domid = DOMID_SELF,
+		.foreign_domid = domid,
+		.size = 1,
+		.space = XENMAPSPACE_gmfn_foreign,
+	};
+	xen_ulong_t idx = fgmfn;
+	xen_pfn_t gpfn = lpfn;
+
+	set_xen_guest_handle(xatp.idxs, &idx);
+	set_xen_guest_handle(xatp.gpfns, &gpfn);
+
+	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap_range, &xatp);
+	if (rc) {
+		pr_warn("Failed to map pfn to mfn rc:%d pfn:%lx mfn:%lx\n",
+			rc, lpfn, fgmfn);
+		return 1;
+	}
+	return 0;
+}
+
+struct remap_data {
+	xen_pfn_t fgmfn; /* foreign domain's gmfn */
+	pgprot_t prot;
+	domid_t  domid;
+	struct vm_area_struct *vma;
+	int index;
+	struct page **pages;
+	struct xen_remap_mfn_info *info;
+};
+
+static int remap_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr,
+			void *data)
+{
+	struct remap_data *info = data;
+	struct page *page = info->pages[info->index++];
+	unsigned long pfn = page_to_pfn(page);
+	pte_t pte = pfn_pte(pfn, info->prot);
+
+	if (map_foreign_page(pfn, info->fgmfn, info->domid))
+		return -EFAULT;
+	set_pte_at(info->vma->vm_mm, addr, ptep, pte);
+
+	return 0;
+}
+
 int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 			       unsigned long addr,
-			       unsigned long mfn, int nr,
-			       pgprot_t prot, unsigned domid)
+			       xen_pfn_t mfn, int nr,
+			       pgprot_t prot, unsigned domid,
+			       struct page **pages)
 {
-	return -ENOSYS;
+	int err;
+	struct remap_data data;
+
+	/* TBD: Batching, current sole caller only does page at a time */
+	if (nr > 1)
+		return -EINVAL;
+
+	data.fgmfn = mfn;
+	data.prot = prot;
+	data.domid = domid;
+	data.vma = vma;
+	data.index = 0;
+	data.pages = pages;
+	err = apply_to_page_range(vma->vm_mm, addr, nr << PAGE_SHIFT,
+				  remap_pte_fn, &data);
+	return err;
 }
 EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
 
+int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
+			       int nr, struct page **pages)
+{
+	int i;
+
+	for (i = 0; i < nr; i++) {
+		struct xen_remove_from_physmap xrp;
+		unsigned long rc, pfn;
+
+		pfn = page_to_pfn(pages[i]);
+
+		xrp.domid = DOMID_SELF;
+		xrp.gpfn = pfn;
+		rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, &xrp);
+		if (rc) {
+			pr_warn("Failed to unmap pfn:%lx rc:%ld\n",
+				pfn, rc);
+			return rc;
+		}
+	}
+	return 0;
+}
+EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range);
+
 /*
  * see Documentation/devicetree/bindings/arm/xen.txt for the
  * documentation of the Xen Device Tree format.
diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
index b459d2e..20e738a 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -63,6 +63,7 @@ DEFINE_GUEST_HANDLE(void);
 DEFINE_GUEST_HANDLE(uint64_t);
 DEFINE_GUEST_HANDLE(uint32_t);
 DEFINE_GUEST_HANDLE(xen_pfn_t);
+DEFINE_GUEST_HANDLE(xen_ulong_t);
 #endif
 
 #ifndef HYPERVISOR_VIRT_START
diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index ad0dff5..5de2b36 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -188,6 +188,24 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_physmap);
 /*** REMOVED ***/
 /*#define XENMEM_translate_gpfn_list  8*/
 
+#define XENMEM_add_to_physmap_range 23
+struct xen_add_to_physmap_range {
+    /* Which domain to change the mapping for. */
+    domid_t domid;
+    uint16_t space; /* => enum phys_map_space */
+
+    /* Number of pages to go through */
+    uint16_t size;
+    domid_t foreign_domid; /* IFF gmfn_foreign */
+
+    /* Indexes into space being mapped. */
+    GUEST_HANDLE(xen_ulong_t) idxs;
+
+    /* GPFN in domid where the source mapping page should appear. */
+    GUEST_HANDLE(xen_pfn_t) gpfns;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_physmap_range);
+
 /*
  * Returns the pseudo-physical memory map as it was when the domain
  * was started (specified by XENMEM_set_memory_map).
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 13:30:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 13:30:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR12C-0004kq-Jq; Wed, 24 Oct 2012 13:30:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR12A-0004kl-LQ
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 13:30:10 +0000
Received: from [85.158.137.99:22988] by server-16.bemta-3.messagelabs.com id
	9F/3E-07461-16DE7805; Wed, 24 Oct 2012 13:30:09 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1351085408!19736031!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5143 invoked from network); 24 Oct 2012 13:30:08 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 13:30:08 -0000
Received: by mail-bk0-f45.google.com with SMTP id jf3so248846bkc.32
	for ; Wed, 24 Oct 2012 06:30:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:from:to:cc:in-reply-to:references:content-type:date
	:message-id:mime-version:x-mailer:content-transfer-encoding;
	bh=P7QeaVfernCt7hzBwDpBqommY9XGyhH5dLxkB9xZvmE=;
	b=SciGjZ53dySwAEYE+jnDNEjcqKKXcrHaATzTcl4iKaCP4DOGPvlMQmrUAfNZaVtJh+
	iQBpQApfSJjyfv4DYVGBGStH3CvNWbfUXCZO9ieoC9c3iIvatEED1zNsQS11JPcfxWWj
	pwGFIAs3lyyyByUJXITjQ7qIB1qLLzW6iySS+ew39vI+PKeylax5tAk96JZ4p0F9LcGM
	jPffzDxO7dzBp0yUHbSeNX84seQd55uowU+c2NlqSHfXlRmxVrZDTS8vg4yQRDk4YqAA
	ftyyoMCVWrSAVfRqI17YU7KC/oIO+Nfgmq2oYfWpBJQBQfo+Urs/meRCutECOSV4GzM+
	ID2Q==
Received: by 10.204.8.141 with SMTP id h13mr4716123bkh.54.1351085407759;
	Wed, 24 Oct 2012 06:30:07 -0700 (PDT)
Received: from [172.28.90.62] ([172.28.90.62])
	by mx.google.com with ESMTPS id e3sm8130973bks.7.2012.10.24.06.30.04
	(version=SSLv3 cipher=OTHER); Wed, 24 Oct 2012 06:30:05 -0700 (PDT)
From: Eric Dumazet 
To: Ian Campbell 
In-Reply-To: <1351084618.18035.27.camel@zakaz.uk.xensource.com>
References: <1351078936-14159-1-git-send-email-ian.campbell@citrix.com>
	<1351081703.6537.99.camel@edumazet-glaptop>
	<1351084618.18035.27.camel@zakaz.uk.xensource.com>
Date: Wed, 24 Oct 2012 15:30:03 +0200
Message-ID: <1351085403.6537.102.camel@edumazet-glaptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: "netdev@vger.kernel.org" ,
	Eric Dumazet ,
	"xen-devel@lists.xen.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH] net: allow configuration of the size of
 page in __netdev_alloc_frag
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 14:16 +0100, Ian Campbell wrote:
> On Wed, 2012-10-24 at 13:28 +0100, Eric Dumazet wrote:
> > On Wed, 2012-10-24 at 12:42 +0100, Ian Campbell wrote:
> > > The commit 69b08f62e174 "net: use bigger pages in __netdev_alloc_frag"
> > > lead to 70%+ packet loss under Xen when transmitting from physical (as
> > > opposed to virtual) network devices.
> > > 
> > > This is because under Xen pages which are contiguous in the physical
> > > address space may not be contiguous in the DMA space, in fact it is
> > > very likely that they are not. I think there are other architectures
> > > where this is true, although perhaps non quite so aggressive as to
> > > have this property at a per-order-0-page granularity.
> > > 
> > > The real underlying bug here most likely lies in the swiotlb not
> > > correctly handling compound pages, and Konrad is investigating this.
> > > However even with the swiotlb issue fixed the current arrangement
> > > seems likely to result in a lot of bounce buffering which seems likely
> > > to more than offset any benefit from the use of larger pages.
> > > 
> > > Therefore make NETDEV_FRAG_PAGE_MAX_ORDER configurable at runtime and
> > > use this to request order-0 frags under Xen. Also expose this setting
> > > via sysctl.
> > > 
> > > Signed-off-by: Ian Campbell 
> > > Cc: Eric Dumazet 
> > > Cc: Konrad Rzeszutek Wilk 
> > > Cc: netdev@vger.kernel.org
> > > Cc: xen-devel@lists.xen.org
> > > ---
> > 
> > I understand your concern, but this seems a quick/dirty hack at this
> > moment. After setting the sysctl to 0, some tasks may still have some
> > order-3 pages in their cache.
> 
> Right, the sysctl thing might be overkill, I just figured it was useful
> for debugging. When booting in a Xen VM the patch sets it to zero very
> early on, during setup_arch(), which is before any tasks even exist.
> 
> > Your driver must already cope with skb->head being split on several
> > pages.
> > 
> > So what fundamental difference exists with frags ?
> 
> The issue here is with drivers for physical network devices when running
> under Xen not with the Xen paravirtualised network drivers (AKA
> netback/netfront).
> 
> The problem is that pages which are contiguous in the physical address
> space may not be contiguous in the DMA address space. With order>0 pages
> this becomes a problem when you poke down the DMA address and length of
> a compound page into the hardware registers. The DMA address will be
> right for the head of the page but once the hardware steps off the end
> of that it'll get the wrong page.
> 
> I don't think this non-contiguousness between physical and DMA addresses
> is specific to Xen, although it is more frequent under Xen than any real
> hardware platform. (Xen has often been a good canary for these sorts of
> issues which turn out later on to impact other arches too.)
> 
> In theory this could be fixed in all the drivers for physical network
> devices, but that would be a lot of effort (and probably a fair bit of
> ugliness in the drivers) for a gain which was only relevant to Xen. 

I still have concerns about skb->head that you dint really answered.

Why skb->head can be on order-1 or order-2 pages and this is working ?

It seems to me its a driver issue, for example
drivers/net/xen-netfront.c has assumptions that can be easily fixed.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 13:30:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 13:30:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR12C-0004kq-Jq; Wed, 24 Oct 2012 13:30:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR12A-0004kl-LQ
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 13:30:10 +0000
Received: from [85.158.137.99:22988] by server-16.bemta-3.messagelabs.com id
	9F/3E-07461-16DE7805; Wed, 24 Oct 2012 13:30:09 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1351085408!19736031!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5143 invoked from network); 24 Oct 2012 13:30:08 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 13:30:08 -0000
Received: by mail-bk0-f45.google.com with SMTP id jf3so248846bkc.32
	for ; Wed, 24 Oct 2012 06:30:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:from:to:cc:in-reply-to:references:content-type:date
	:message-id:mime-version:x-mailer:content-transfer-encoding;
	bh=P7QeaVfernCt7hzBwDpBqommY9XGyhH5dLxkB9xZvmE=;
	b=SciGjZ53dySwAEYE+jnDNEjcqKKXcrHaATzTcl4iKaCP4DOGPvlMQmrUAfNZaVtJh+
	iQBpQApfSJjyfv4DYVGBGStH3CvNWbfUXCZO9ieoC9c3iIvatEED1zNsQS11JPcfxWWj
	pwGFIAs3lyyyByUJXITjQ7qIB1qLLzW6iySS+ew39vI+PKeylax5tAk96JZ4p0F9LcGM
	jPffzDxO7dzBp0yUHbSeNX84seQd55uowU+c2NlqSHfXlRmxVrZDTS8vg4yQRDk4YqAA
	ftyyoMCVWrSAVfRqI17YU7KC/oIO+Nfgmq2oYfWpBJQBQfo+Urs/meRCutECOSV4GzM+
	ID2Q==
Received: by 10.204.8.141 with SMTP id h13mr4716123bkh.54.1351085407759;
	Wed, 24 Oct 2012 06:30:07 -0700 (PDT)
Received: from [172.28.90.62] ([172.28.90.62])
	by mx.google.com with ESMTPS id e3sm8130973bks.7.2012.10.24.06.30.04
	(version=SSLv3 cipher=OTHER); Wed, 24 Oct 2012 06:30:05 -0700 (PDT)
From: Eric Dumazet 
To: Ian Campbell 
In-Reply-To: <1351084618.18035.27.camel@zakaz.uk.xensource.com>
References: <1351078936-14159-1-git-send-email-ian.campbell@citrix.com>
	<1351081703.6537.99.camel@edumazet-glaptop>
	<1351084618.18035.27.camel@zakaz.uk.xensource.com>
Date: Wed, 24 Oct 2012 15:30:03 +0200
Message-ID: <1351085403.6537.102.camel@edumazet-glaptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: "netdev@vger.kernel.org" ,
	Eric Dumazet ,
	"xen-devel@lists.xen.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH] net: allow configuration of the size of
 page in __netdev_alloc_frag
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 14:16 +0100, Ian Campbell wrote:
> On Wed, 2012-10-24 at 13:28 +0100, Eric Dumazet wrote:
> > On Wed, 2012-10-24 at 12:42 +0100, Ian Campbell wrote:
> > > The commit 69b08f62e174 "net: use bigger pages in __netdev_alloc_frag"
> > > lead to 70%+ packet loss under Xen when transmitting from physical (as
> > > opposed to virtual) network devices.
> > > 
> > > This is because under Xen pages which are contiguous in the physical
> > > address space may not be contiguous in the DMA space, in fact it is
> > > very likely that they are not. I think there are other architectures
> > > where this is true, although perhaps non quite so aggressive as to
> > > have this property at a per-order-0-page granularity.
> > > 
> > > The real underlying bug here most likely lies in the swiotlb not
> > > correctly handling compound pages, and Konrad is investigating this.
> > > However even with the swiotlb issue fixed the current arrangement
> > > seems likely to result in a lot of bounce buffering which seems likely
> > > to more than offset any benefit from the use of larger pages.
> > > 
> > > Therefore make NETDEV_FRAG_PAGE_MAX_ORDER configurable at runtime and
> > > use this to request order-0 frags under Xen. Also expose this setting
> > > via sysctl.
> > > 
> > > Signed-off-by: Ian Campbell 
> > > Cc: Eric Dumazet 
> > > Cc: Konrad Rzeszutek Wilk 
> > > Cc: netdev@vger.kernel.org
> > > Cc: xen-devel@lists.xen.org
> > > ---
> > 
> > I understand your concern, but this seems a quick/dirty hack at this
> > moment. After setting the sysctl to 0, some tasks may still have some
> > order-3 pages in their cache.
> 
> Right, the sysctl thing might be overkill, I just figured it was useful
> for debugging. When booting in a Xen VM the patch sets it to zero very
> early on, during setup_arch(), which is before any tasks even exist.
> 
> > Your driver must already cope with skb->head being split on several
> > pages.
> > 
> > So what fundamental difference exists with frags ?
> 
> The issue here is with drivers for physical network devices when running
> under Xen not with the Xen paravirtualised network drivers (AKA
> netback/netfront).
> 
> The problem is that pages which are contiguous in the physical address
> space may not be contiguous in the DMA address space. With order>0 pages
> this becomes a problem when you poke down the DMA address and length of
> a compound page into the hardware registers. The DMA address will be
> right for the head of the page but once the hardware steps off the end
> of that it'll get the wrong page.
> 
> I don't think this non-contiguousness between physical and DMA addresses
> is specific to Xen, although it is more frequent under Xen than any real
> hardware platform. (Xen has often been a good canary for these sorts of
> issues which turn out later on to impact other arches too.)
> 
> In theory this could be fixed in all the drivers for physical network
> devices, but that would be a lot of effort (and probably a fair bit of
> ugliness in the drivers) for a gain which was only relevant to Xen. 

I still have concerns about skb->head that you dint really answered.

Why skb->head can be on order-1 or order-2 pages and this is working ?

It seems to me its a driver issue, for example
drivers/net/xen-netfront.c has assumptions that can be easily fixed.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 13:33:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 13:33:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR14q-0004s4-8c; Wed, 24 Oct 2012 13:32:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR14o-0004rv-UQ
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 13:32:55 +0000
Received: from [85.158.138.51:9247] by server-6.bemta-3.messagelabs.com id
	6C/52-32375-60EE7805; Wed, 24 Oct 2012 13:32:54 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1351085498!35556934!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzg3MDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2260 invoked from network); 24 Oct 2012 13:31:40 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 13:31:40 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="42271401"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 13:30:51 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 09:30:51 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TR12o-0004v0-O0;
	Wed, 24 Oct 2012 14:30:50 +0100
Message-ID: <5087EC58.8040904@eu.citrix.com>
Date: Wed, 24 Oct 2012 14:25:44 +0100
From: George Dunlap 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: ZhouPeng 
References: 
	<1338987918.32319.84.camel@zakaz.uk.xensource.com>
	
	<1339049291.6557.11.camel@dagon.hellion.org.uk>
	
	<1341325462.21547.20.camel@zakaz.uk.xensource.com>
	
	
	
	<508559E8.10102@eu.citrix.com>
	
In-Reply-To: 
Cc: "Xen-Devel \(E-mail\)" ,
	Ian Jackson ,
	Ian Campbell ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 2/3] tools:libxl: Add qxl vga interface
 support v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMjQvMTAvMTIgMDk6MDYsIFpob3VQZW5nIHdyb3RlOgo+IENhbiBiZSBjaGFuZ2VkLkJ1dCBJ
YW4gQ2FtcGJlbGwgYW5kIG1lIGhhdmUgdGFsa2VkIG9uIHN0aCByZWxhdGVkIHdpdGggdGhpcwo+
IGNsb3NlbHkgYmVmb3JlLiBBbmQgd2UgYm90aCBhZ3JlZSB0byBqdXN0IHN1cHBvcnQgdGhlIGRl
ZmF1bHQgaXMKPiBlbm91Z2ggaW4gbW9zdCB0aW1lLiBZb3UgY2FuIGdldCBpdCBmcm9tIHRoZSB1
cmwgYmVsb3cgcXVpY2tseSwgcGxzCj4gcmVhZCBmcm9tIGJvdHRvbSB1cCwgd2hpY2ggY2FuIHNh
dmUgdGltZS4KCk9LIC0tIGluIHRoYXQgY2FzZSwgdjUgbG9va3MgT0sgdG8gbWU6CgpBY2tlZC1i
eTogR2VvcmdlIER1bmxhcCA8Z2VvcmdlLmR1bmxhcEBldS5jaXRyaXguY29tPgoK6LCi6LCi77yM
Ci1HZW9yZ2UKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Clhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xp
c3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Oct 24 13:33:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 13:33:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR14q-0004s4-8c; Wed, 24 Oct 2012 13:32:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR14o-0004rv-UQ
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 13:32:55 +0000
Received: from [85.158.138.51:9247] by server-6.bemta-3.messagelabs.com id
	6C/52-32375-60EE7805; Wed, 24 Oct 2012 13:32:54 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1351085498!35556934!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzg3MDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2260 invoked from network); 24 Oct 2012 13:31:40 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 13:31:40 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="42271401"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 13:30:51 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 09:30:51 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TR12o-0004v0-O0;
	Wed, 24 Oct 2012 14:30:50 +0100
Message-ID: <5087EC58.8040904@eu.citrix.com>
Date: Wed, 24 Oct 2012 14:25:44 +0100
From: George Dunlap 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: ZhouPeng 
References: 
	<1338987918.32319.84.camel@zakaz.uk.xensource.com>
	
	<1339049291.6557.11.camel@dagon.hellion.org.uk>
	
	<1341325462.21547.20.camel@zakaz.uk.xensource.com>
	
	
	
	<508559E8.10102@eu.citrix.com>
	
In-Reply-To: 
Cc: "Xen-Devel \(E-mail\)" ,
	Ian Jackson ,
	Ian Campbell ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 2/3] tools:libxl: Add qxl vga interface
 support v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMjQvMTAvMTIgMDk6MDYsIFpob3VQZW5nIHdyb3RlOgo+IENhbiBiZSBjaGFuZ2VkLkJ1dCBJ
YW4gQ2FtcGJlbGwgYW5kIG1lIGhhdmUgdGFsa2VkIG9uIHN0aCByZWxhdGVkIHdpdGggdGhpcwo+
IGNsb3NlbHkgYmVmb3JlLiBBbmQgd2UgYm90aCBhZ3JlZSB0byBqdXN0IHN1cHBvcnQgdGhlIGRl
ZmF1bHQgaXMKPiBlbm91Z2ggaW4gbW9zdCB0aW1lLiBZb3UgY2FuIGdldCBpdCBmcm9tIHRoZSB1
cmwgYmVsb3cgcXVpY2tseSwgcGxzCj4gcmVhZCBmcm9tIGJvdHRvbSB1cCwgd2hpY2ggY2FuIHNh
dmUgdGltZS4KCk9LIC0tIGluIHRoYXQgY2FzZSwgdjUgbG9va3MgT0sgdG8gbWU6CgpBY2tlZC1i
eTogR2VvcmdlIER1bmxhcCA8Z2VvcmdlLmR1bmxhcEBldS5jaXRyaXguY29tPgoK6LCi6LCi77yM
Ci1HZW9yZ2UKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Clhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xp
c3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Oct 24 13:39:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 13:39:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR1BM-00056f-43; Wed, 24 Oct 2012 13:39:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR1BL-00056a-4a
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 13:39:39 +0000
Received: from [85.158.143.35:41266] by server-2.bemta-4.messagelabs.com id
	88/AA-22268-A9FE7805; Wed, 24 Oct 2012 13:39:38 +0000
X-Env-Sender: davidxu06@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1351085975!12528094!1
X-Originating-IP: [209.85.216.52]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19675 invoked from network); 24 Oct 2012 13:39:36 -0000
Received: from mail-qa0-f52.google.com (HELO mail-qa0-f52.google.com)
	(209.85.216.52)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 13:39:36 -0000
Received: by mail-qa0-f52.google.com with SMTP id g24so1057278qab.11
	for ; Wed, 24 Oct 2012 06:39:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=IT0NblAhoPM8GquFgm1SXDDhhdaSakgc7+wNRUH3cW4=;
	b=nRVRWtZO7aFXueE1jQ9LFHBzE5foj502aY5Pl3yZNha0B8GTHgo2C3xuE8Y3r4l5GM
	eT4Sdv0/A/qk87d2SsnIW9bjUzy1DxRUCRPvLptVHwxI9JplrIyHPU/1HAxInwiJGvD5
	UeDUelfH7EXkBh9Vzq51gABvut5kwzSJKW9QtWyysrSPBGNZ4gS1he7j82Z2X1jJHwAg
	F4trEfiby/zbmH9Jjx38Kxc1SgCRyTqA159CaTBI5hf5siKSa+A1mnOwxhnP0/jZ+SJJ
	SMf9i8JIzYpBiH/tgaQUM6h0Rkff8AsXk0BYs6nm3dRl8pjoT74m1U3BK4TQrTmEffsS
	BCzQ==
MIME-Version: 1.0
Received: by 10.224.31.204 with SMTP id z12mr7294338qac.32.1351085975512; Wed,
	24 Oct 2012 06:39:35 -0700 (PDT)
Received: by 10.49.1.116 with HTTP; Wed, 24 Oct 2012 06:39:35 -0700 (PDT)
In-Reply-To: <1351070623.2237.120.camel@zakaz.uk.xensource.com>
References: 
	<1351070623.2237.120.camel@zakaz.uk.xensource.com>
Date: Wed, 24 Oct 2012 09:39:35 -0400
Message-ID: 
From: David Xu 
To: Ian Campbell 
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] xen_evtchn_do_upcall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============3206735932390025830=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3206735932390025830==
Content-Type: multipart/alternative; boundary=20cf3074b0a4a1a52f04ccce3736

--20cf3074b0a4a1a52f04ccce3736
Content-Type: text/plain; charset=ISO-8859-1

Hi Lan,

Thanks for your reply. I did a experiment as follows,
I assigned 2 vCPU to a VM, one vCPU (vCPU0) was pinned to a physical CPU
shared with several other VMs and the other vCPU (vCPU1) was pinned to an
idle physical CPU occupied by this VM only. Then in Guest OS I run iperf
server to measure its TCP receiving throughput. In order to shrink the
receiving delay caused by vCPU scheduling, I pin the IRQ context of NIC to
vCPU1 and run iperf server on the vCPU0. This method works well for UDP,
but does not work for TCP. I track the involved function by ftrace and get
the following results which contains lots of xen_evtchn_do_upcall routine.
What's the meaning of this process (xen_evtchn_do_upcall
=> handle_irq_event => xennet_tx_buf_gc =>  gnttab_query_foreign_access)?

 1)               |  tcp_v4_rcv() {
 1)   0.087 us    |    __inet_lookup_established();
 1)               |    sk_filter() {
 1)               |      security_sock_rcv_skb() {
 1)   0.049 us    |        cap_socket_sock_rcv_skb();
 1)   0.374 us    |      }
 1)   0.708 us    |    }
 1)               |    _raw_spin_lock() {
 1)               |    xen_evtchn_do_upcall() {
 1)   0.051 us    |      exit_idle();
 1)               |      irq_enter() {
 1)               |        rcu_irq_enter() {
 1)   0.094 us    |          rcu_exit_nohz();
 1)   0.432 us    |        }
 1)   0.055 us    |        idle_cpu();
 1)   1.166 us    |      }
 1)               |      __xen_evtchn_do_upcall() {
 1)   0.120 us    |        irq_to_desc();
 1)               |        handle_edge_irq() {
 1)   0.103 us    |          _raw_spin_lock();
 1)               |          ack_dynirq() {
 1)               |            evtchn_from_irq() {
 1)               |              info_for_irq() {
 1)               |                irq_get_irq_data() {
 1)   0.051 us    |                  irq_to_desc();
 1)   0.400 us    |                }
 1)   0.746 us    |              }
 1)   1.074 us    |            }
 1)   0.050 us    |            irq_move_irq();
 1)   1.767 us    |          }
 1)               |          handle_irq_event() {
 1)   0.164 us    |            _raw_spin_unlock();
 1)               |            handle_irq_event_percpu() {
 1)               |              xennet_interrupt() {
 1)   0.125 us    |                _raw_spin_lock_irqsave();
 1)               |                xennet_tx_buf_gc() {
 1)   0.082 us    |                  gnttab_query_foreign_access();
 1)   0.050 us    |                  gnttab_end_foreign_access_ref();
 1)   0.070 us    |                  gnttab_release_grant_reference();
 1)               |                  dev_kfree_skb_irq() {
 1)   0.061 us    |                    raise_softirq_irqoff();
 1)   0.460 us    |                  }
 1)   0.058 us    |                  gnttab_query_foreign_access();
 1)   0.050 us    |                  gnttab_end_foreign_access_ref();
 1)   0.050 us    |                  gnttab_release_grant_reference();
 1)               |                  dev_kfree_skb_irq() {
 1)   0.059 us    |                    raise_softirq_irqoff();
 1)   0.440 us    |                  }
 1)   3.710 us    |                }
 1)   0.092 us    |                _raw_spin_unlock_irqrestore();
 1)   4.845 us    |              }
 1)   0.075 us    |              note_interrupt();
 1)   5.567 us    |            }
 1)   0.055 us    |            _raw_spin_lock();
 1)   6.889 us    |          }
 1)   0.080 us    |          _raw_spin_unlock();
 1) + 10.081 us   |        }
 1) + 10.965 us   |      }
 1)               |      irq_exit() {
 1)               |        rcu_irq_exit() {
 1)   0.086 us    |          rcu_enter_nohz();
 1)   0.424 us    |        }
 1)   0.049 us    |        idle_cpu();
 1)   1.094 us    |      }
 1) + 14.555 us   |    }
 1)   0.120 us    |    } /* _raw_spin_lock */
 1)               |    __wake_up_sync_key() {
 1)   0.099 us    |      _raw_spin_lock_irqsave();
 1)               |      __wake_up_common() {
 1)               |        autoremove_wake_function() {
 1)               |          default_wake_function() {
 1)               |            try_to_wake_up() {
 1)   0.103 us    |              _raw_spin_lock_irqsave();
 1)   0.078 us    |              task_waking_fair();
 1)   0.102 us    |              select_task_rq_fair();
 1)               |              xen_smp_send_reschedule() {
 1)               |                xen_send_IPI_one() {
 1)               |                  notify_remote_via_irq() {
 1)               |                    evtchn_from_irq() {
 1)               |                      info_for_irq() {
 1)               |                        irq_get_irq_data() {
 1)   0.067 us    |                          irq_to_desc();
 1)   0.396 us    |                        }
 1)   0.727 us    |                      }
 1)   1.055 us    |                    }
 1)   1.699 us    |                  }
 1)   2.048 us    |                }
 1)   2.407 us    |              }
 1)   0.066 us    |              ttwu_stat();
 1)   0.114 us    |              _raw_spin_unlock_irqrestore();
 1)   4.941 us    |            }
 1)   5.294 us    |          }
 1)   5.645 us    |        }
 1)   6.023 us    |      }
 1)   0.094 us    |      _raw_spin_unlock_irqrestore();
 1)   7.156 us    |    }
 1)   0.058 us    |    dst_metric();
 1)               |    inet_csk_reset_xmit_timer.constprop.34() {
 1)               |      sk_reset_timer() {
 1)               |        mod_timer() {
 1)               |          lock_timer_base.isra.30() {
 1)   0.099 us    |            _raw_spin_lock_irqsave();
 1)   0.436 us    |          }
 1)   0.049 us    |          idle_cpu();
 1)   0.116 us    |          _raw_spin_unlock();
 1)   0.074 us    |          _raw_spin_lock();
 1)   0.072 us    |          internal_add_timer();
 1)   0.103 us    |          _raw_spin_unlock_irqrestore();
 1)   2.673 us    |        }
 1)   3.039 us    |      }
 1)   3.397 us    |    }
 1)   0.082 us    |    _raw_spin_unlock();
 1)   0.061 us    |    sock_put();
 1) + 48.704 us   |  }

When I run both process context of application ( e.g. iperf server ) and
IRQ context on vCPU1 which is the ''fast" core, no any xen_evtchn_do_upcall
routine found.

 1)               |  tcp_v4_rcv() {
 1)   0.081 us    |    __inet_lookup_established();
 1)               |    sk_filter() {
 1)               |      security_sock_rcv_skb() {
 1)   0.059 us    |        cap_socket_sock_rcv_skb();
 1)   0.542 us    |      }
 1)   0.875 us    |    }
 1)   0.060 us    |    _raw_spin_lock();
 1)   0.117 us    |    _raw_spin_unlock();
 1)   0.053 us    |    sock_put();
 1)   2.703 us    |  }

Do you think these  xen_evtchn_do_upcall routines are due to the
synchronization between process context and softirq context? Thanks.

Regards,
Cong


2012/10/24 Ian Campbell 

> On Mon, 2012-10-22 at 02:51 +0100, David Xu wrote:
> > Hi,
> >
> >
> > Is anybody know the purpose of this method (xen_evtchn_do_upcall)?
>
> It is the callback used to inject event channels events (i.e. IRQs) into
> the guest. You would expect to see it at the base of any stack trace
> taken from interrupt context.
>
> >  When I run a user level application involved in TCP receiving and the
> > SoftIRQ for eth0 on the same CPU core, everything is OK. But if I run
> > them on 2 different cores, there will be xen_evtchn_do_upcall()
> > existing (maybe when the local_bh_disable() or local_bh_enable() is
> > called)
>
> it would not be unusual to get an interrupt immediately after
> re-enabling interrupts.
>
> >  in __inet_lookup_established() routine which costs longer time than
> > the first scenario. Is it due to the synchronization issue between
> > process context and softirq context? Thanks for any reply.
> >
> >
> >  1)               |    __inet_lookup_established() {
> >  1)               |    xen_evtchn_do_upcall() {
> >  1)   0.054 us    |      exit_idle();
> >  1)               |      irq_enter() {
> >  1)               |        rcu_irq_enter() {
> >  1)   0.102 us    |          rcu_exit_nohz();
> >  1)   0.431 us    |        }
> >  1)   0.064 us    |        idle_cpu();
> >  1)   1.152 us    |      }
> >  1)               |      __xen_evtchn_do_upcall() {
> >  1)   0.119 us    |        irq_to_desc();
> >  1)               |        handle_edge_irq() {
> >  1)   0.107 us    |          _raw_spin_lock();
> >  1)               |          ack_dynirq() {
> >  1)               |            evtchn_from_irq() {
> >  1)               |              info_for_irq() {
> >  1)               |                irq_get_irq_data() {
> >  1)   0.052 us    |                  irq_to_desc();
> >  1)   0.418 us    |                }
> >  1)   0.782 us    |              }
> >  1)   1.135 us    |            }
> >  1)   0.049 us    |            irq_move_irq();
> >  1)   1.800 us    |          }
> >  1)               |          handle_irq_event() {
> >  1)   0.161 us    |            _raw_spin_unlock();
> >  1)               |            handle_irq_event_percpu() {
> >  1)               |              xennet_interrupt() {
> >  1)   0.125 us    |                _raw_spin_lock_irqsave();
> >  1)               |                xennet_tx_buf_gc() {
> >  1)   0.079 us    |                  gnttab_query_foreign_access();
> >  1)   0.050 us    |                  gnttab_end_foreign_access_ref();
> >  1)   0.069 us    |                  gnttab_release_grant_reference();
> >  1)               |                  dev_kfree_skb_irq() {
> >  1)   0.055 us    |                    raise_softirq_irqoff();
> >  1)   0.472 us    |                  }
> >  1)   0.049 us    |                  gnttab_query_foreign_access();
> >  1)   0.058 us    |                  gnttab_end_foreign_access_ref();
> >  1)   0.058 us    |                  gnttab_release_grant_reference();
> >  1)               |                  dev_kfree_skb_irq() {
> >  1)   0.050 us    |                    raise_softirq_irqoff();
> >  1)   0.456 us    |                  }
> >  1)   3.714 us    |                }
> >  1)   0.102 us    |                _raw_spin_unlock_irqrestore();
> >  1)   4.857 us    |              }
> >  1)   0.061 us    |              note_interrupt();
> >  1)   5.571 us    |            }
> >  1)   0.054 us    |            _raw_spin_lock();
> >  1)   6.707 us    |          }
> >  1)   0.083 us    |          _raw_spin_unlock();
> >  1) + 10.083 us   |        }
> >  1) + 10.985 us   |      }
> >  1)               |      irq_exit() {
> >  1)               |        rcu_irq_exit() {
> >  1)   0.087 us    |          rcu_enter_nohz();
> >  1)   0.429 us    |        }
> >  1)   0.049 us    |        idle_cpu();
> >  1)   1.088 us    |      }
> >  1) + 14.551 us   |    }
> >  1)   0.191 us    |    } /* __inet_lookup_established */
>
>
>

--20cf3074b0a4a1a52f04ccce3736
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Lan,

Thanks for your reply. I did a experiment as fol=
lows,=A0
I assigned 2 vCPU to a VM, one vCPU (vCPU0) was pinned t=
o a physical CPU shared with several other VMs and the other vCPU (vCPU1) w=
as pinned to an idle physical CPU occupied by this VM only. Then in Guest O=
S I run iperf server to measure its TCP receiving throughput. In order to s=
hrink the receiving delay caused by vCPU scheduling, I pin the IRQ context =
of NIC to vCPU1 and run iperf server on the vCPU0. This method works well f=
or UDP, but does not work for TCP. I track the involved function by ftrace =
and get the following results which contains lots of xen_evtchn_do_upcall r=
outine. What's the meaning of this process (xen_evtchn_do_upcall =3D>=
;=A0handle_irq_event =3D>=A0xennet_tx_buf_gc =3D>=A0=A0gnttab_query_f=
oreign_access)?



=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0tcp_v4_rcv(=
) {
=A01) =A0 0.087 us =A0 =A0| =A0 =A0__inet_lookup_established(=
);
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0sk_filter() {
=

=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0security_sock_rcv_skb()=
 {


=A01) =A0 0.049 us =A0 =A0| =A0 =A0 =A0 =A0cap_socket_sock_rcv_skb();<=
/div>
=A01) =A0 0.374 us =A0 =A0| =A0 =A0 =A0}
=A01) =A0 0.70=
8 us =A0 =A0| =A0 =A0}
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =
=A0_raw_spin_lock() {
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0=
xen_evtchn_do_upcall() {


=A01) =A0 0.051 us =A0 =A0| =A0 =A0 =A0exit_idle();
=A01) =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0irq_enter() {
=A01) =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0rcu_irq_enter() {
=A01) =
=A0 0.094 us =A0 =A0| =A0 =A0 =A0 =A0 =A0rcu_exit_nohz();
=A01) =
=A0 0.432 us =A0 =A0| =A0 =A0 =A0 =A0}


=A01) =A0 0.055 us =A0 =A0| =A0 =A0 =A0 =A0idle_cpu();
=A01)=
 =A0 1.166 us =A0 =A0| =A0 =A0 =A0}
=A01) =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 | =A0 =A0 =A0__xen_evtchn_do_upcall() {
=A01) =A0 0.120 us =
=A0 =A0| =A0 =A0 =A0 =A0irq_to_desc();
=A01) =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 | =A0 =A0 =A0 =A0handle_edge_irq() {


=A01) =A0 0.103 us =A0 =A0| =A0 =A0 =A0 =A0 =A0_raw_spin_lock();
=

=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0ack_dynirq() {<=
/div>
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0evtchn=
_from_irq() {
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0=
 =A0 =A0 =A0info_for_irq() {


=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0irq=
_get_irq_data() {
=A01) =A0 0.051 us =A0 =A0| =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0irq_to_desc();
=A01) =A0 0.400 us =A0 =A0| =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0}
=A01) =A0 0.746 us =A0 =A0| =A0 =A0 =
=A0 =A0 =A0 =A0 =A0}

=A01) =A0 1.074 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0}
=A01) =A0 0.=
050 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0irq_move_irq();
=A01) =A0 =
1.767 us =A0 =A0| =A0 =A0 =A0 =A0 =A0}
=A01) =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 | =A0 =A0 =A0 =A0 =A0handle_irq_event() {
=A01) =A0 0.164=
 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0_raw_spin_unlock();


=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0handle_irq_=
event_percpu() {
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =
=A0 =A0 =A0 =A0xennet_interrupt() {
=A01) =A0 0.125 us =A0 =A0| =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0_raw_spin_lock_irqsave();
=A01) =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0xennet_tx_buf_=
gc() {


=A01) =A0 0.082 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gnttab_=
query_foreign_access();
=A01) =A0 0.050 us =A0 =A0| =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0gnttab_end_foreign_access_ref();
=A01) =A0=
 0.070 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gnttab_release_grant_=
reference();


=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0dev_kfree_skb_irq() {
=A01) =A0 0.061 us =A0 =A0| =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0raise_softirq_irqoff();
=A01) =A0 0.46=
0 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
=A01) =A0 0.05=
8 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gnttab_query_foreign_acces=
s();


=A01) =A0 0.050 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gnttab_=
end_foreign_access_ref();
=A01) =A0 0.050 us =A0 =A0| =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0gnttab_release_grant_reference();
=A01) =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dev_kfree_=
skb_irq() {


=A01) =A0 0.059 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0rai=
se_softirq_irqoff();
=A01) =A0 0.440 us =A0 =A0| =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0}
=A01) =A0 3.710 us =A0 =A0| =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0}
=A01) =A0 0.092 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0_raw_spin_unlock_irqrestore();


=A01) =A0 4.845 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0}
=A0=
1) =A0 0.075 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0note_interrupt();
=

=A01) =A0 5.567 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0}
=A01) =
=A0 0.055 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0_raw_spin_lock();
=
=A01) =A0 6.889 us =A0 =A0| =A0 =A0 =A0 =A0 =A0}


=A01) =A0 0.080 us =A0 =A0| =A0 =A0 =A0 =A0 =A0_raw_spin_unlock();
=A01) + 10.081 us =A0 | =A0 =A0 =A0 =A0}
=A01) + 10.965 us=
 =A0 | =A0 =A0 =A0}
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =
=A0irq_exit() {
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =
=A0rcu_irq_exit() {


=A01) =A0 0.086 us =A0 =A0| =A0 =A0 =A0 =A0 =A0rcu_enter_nohz();
=

=A01) =A0 0.424 us =A0 =A0| =A0 =A0 =A0 =A0}
=A01) =A0 0.049=
 us =A0 =A0| =A0 =A0 =A0 =A0idle_cpu();
=A01) =A0 1.094 us =A0 =
=A0| =A0 =A0 =A0}
=A01) + 14.555 us =A0 | =A0 =A0}

=A01) =A0 0.120 us =A0 =A0| =A0 =A0} /* _raw_spin_lock */
=A01) =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0__wake_up_sync_key() {
=A01)=
 =A0 0.099 us =A0 =A0| =A0 =A0 =A0_raw_spin_lock_irqsave();
=A01)=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0__wake_up_common() {


=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0autoremove_wake_fun=
ction() {
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0=
default_wake_function() {
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0=
 =A0 =A0 =A0 =A0 =A0try_to_wake_up() {
=A01) =A0 0.103 us =A0 =A0=
| =A0 =A0 =A0 =A0 =A0 =A0 =A0_raw_spin_lock_irqsave();


=A01) =A0 0.078 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0task_waking_fai=
r();
=A01) =A0 0.102 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0selec=
t_task_rq_fair();
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0=
 =A0 =A0 =A0 =A0xen_smp_send_reschedule() {
=A01) =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0xen_send_IPI_one() {


=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0notify_remote_via_irq() {
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0evtchn_from_irq() {
=A01) =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0in=
fo_for_irq() {
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0irq_get_irq_data() {


=A01) =A0 0.067 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0irq_to_desc();
=A01) =A0 0.396 us =A0 =A0| =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
=A01) =A0 0.727 us =A0 =A0|=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
=A01) =A0 1.055 us =
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}


=A01) =A0 1.699 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
=

=A01) =A0 2.048 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
=A01) =A0 2.407 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0}
=A01) =
=A0 0.066 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0ttwu_stat();
=A0=
1) =A0 0.114 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0_raw_spin_unlock_irqres=
tore();


=A01) =A0 4.941 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0}
=A01) =
=A0 5.294 us =A0 =A0| =A0 =A0 =A0 =A0 =A0}
=A01) =A0 5.645 us =A0=
 =A0| =A0 =A0 =A0 =A0}
=A01) =A0 6.023 us =A0 =A0| =A0 =A0 =A0}
=A01) =A0 0.094 us =A0 =A0| =A0 =A0 =A0_raw_spin_unlock_irqrestore=
();


=A01) =A0 7.156 us =A0 =A0| =A0 =A0}
=A01) =A0 0.058 us =A0 =
=A0| =A0 =A0dst_metric();
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0=
 =A0inet_csk_reset_xmit_timer.constprop.34() {
=A01) =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 | =A0 =A0 =A0sk_reset_timer() {
=A01) =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0mod_timer() {


=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0lock_timer_base=
.isra.30() {
=A01) =A0 0.099 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0_=
raw_spin_lock_irqsave();
=A01) =A0 0.436 us =A0 =A0| =A0 =A0 =A0 =
=A0 =A0}
=A01) =A0 0.049 us =A0 =A0| =A0 =A0 =A0 =A0 =A0idle_cpu(=
);


=A01) =A0 0.116 us =A0 =A0| =A0 =A0 =A0 =A0 =A0_raw_spin_unlock();
=A01) =A0 0.074 us =A0 =A0| =A0 =A0 =A0 =A0 =A0_raw_spin_lock();
=A01) =A0 0.072 us =A0 =A0| =A0 =A0 =A0 =A0 =A0internal_add_timer();=

=A01) =A0 0.103 us =A0 =A0| =A0 =A0 =A0 =A0 =A0_raw_spin_unlock_=
irqrestore();


=A01) =A0 2.673 us =A0 =A0| =A0 =A0 =A0 =A0}
=A01) =A0 3.039=
 us =A0 =A0| =A0 =A0 =A0}
=A01) =A0 3.397 us =A0 =A0| =A0 =A0}
=A01) =A0 0.082 us =A0 =A0| =A0 =A0_raw_spin_unlock();
=
=A01) =A0 0.061 us =A0 =A0| =A0 =A0sock_put();
=A01) + 48.704 us =
=A0 | =A0}



When I run both process context of application ( =
e.g. iperf server ) and IRQ context on vCPU1 which is the ''fast&qu=
ot; core, no any=A0xen_evtchn_do_upcall routine found.=A0



=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0tcp_v4_rcv() {
=
=A01) =A0 0.081 us =A0 =A0| =A0 =A0__inet_lookup_established();
=
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0sk_filter() {
=A01) =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0security_sock_rcv_skb() {


=A01) =A0 0.059 us =A0 =A0| =A0 =A0 =A0 =A0cap_socket_sock_rcv_skb();<=
/div>
=A01) =A0 0.542 us =A0 =A0| =A0 =A0 =A0}
=A01) =A0 0.87=
5 us =A0 =A0| =A0 =A0}
=A01) =A0 0.060 us =A0 =A0| =A0 =A0_raw_sp=
in_lock();
=A01) =A0 0.117 us =A0 =A0| =A0 =A0_raw_spin_unlock();=



=A01) =A0 0.053 us =A0 =A0| =A0 =A0sock_put();
=A01) =A0 2.7=
03 us =A0 =A0| =A0}

Do you think these=A0=A0=
xen_evtchn_do_upcall routines are due to the synchronization between proces=
s context and softirq context? Thanks.



Regards,
Cong


2012/10/24 Ian Campbell <Ian.Campbell@citri=
x.com>


On Mon, 2012-10-22 at 02:5=
1 +0100, David Xu wrote:

> Hi,

>

>

> Is anybody know the purpose of this method (xen_evtchn_do_upcall)?




It is the callback used to inject event channels events (i.e. IRQs) i=
nto

the guest. You would expect to see it at the base of any stack trace

taken from interrupt context.




> =A0When I run a user level application involved in TCP receiving and t=
he

> SoftIRQ for eth0 on the same CPU core, everything is OK. But if I run<=
br>
> them on 2 different cores, there will be xen_evtchn_do_upcall()

> existing (maybe when the local_bh_disable() or local_bh_enable() is
> called)




it would not be unusual to get an interrupt immediately after

re-enabling interrupts.




> =A0in __inet_lookup_established() routine which costs longer time than=


> the first scenario. Is it due to the synchronization issue between

> process context and softirq context? Thanks for any reply.

>

>

> =A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0__inet_lookup_established()=
 {

> =A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0xen_evtchn_do_upcall() {
> =A01) =A0 0.054 us =A0 =A0| =A0 =A0 =A0exit_idle();

> =A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0irq_enter() {

> =A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0rcu_irq_enter() {
> =A01) =A0 0.102 us =A0 =A0| =A0 =A0 =A0 =A0 =A0rcu_exit_nohz();

> =A01) =A0 0.431 us =A0 =A0| =A0 =A0 =A0 =A0}

> =A01) =A0 0.064 us =A0 =A0| =A0 =A0 =A0 =A0idle_cpu();

> =A01) =A0 1.152 us =A0 =A0| =A0 =A0 =A0}

> =A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0__xen_evtchn_do_upcall(=
) {

> =A01) =A0 0.119 us =A0 =A0| =A0 =A0 =A0 =A0irq_to_desc();

> =A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0handle_edge_irq() {=


> =A01) =A0 0.107 us =A0 =A0| =A0 =A0 =A0 =A0 =A0_raw_spin_lock();

> =A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0ack_dynirq() {<=
br>
> =A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0evtchn_from=
_irq() {

> =A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0info_fo=
r_irq() {

> =A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0irq=
_get_irq_data() {

> =A01) =A0 0.052 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0irq_to_=
desc();

> =A01) =A0 0.418 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}

> =A01) =A0 0.782 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0}

> =A01) =A0 1.135 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0}

> =A01) =A0 0.049 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0irq_move_irq();

> =A01) =A0 1.800 us =A0 =A0| =A0 =A0 =A0 =A0 =A0}

> =A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0handle_irq_even=
t() {

> =A01) =A0 0.161 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0_raw_spin_unlock();=


> =A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0handle_irq_=
event_percpu() {

> =A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0xennet_=
interrupt() {

> =A01) =A0 0.125 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0_raw_spin_l=
ock_irqsave();

> =A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0xen=
net_tx_buf_gc() {

> =A01) =A0 0.079 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gnttab_=
query_foreign_access();

> =A01) =A0 0.050 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gnttab_=
end_foreign_access_ref();

> =A01) =A0 0.069 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gnttab_=
release_grant_reference();

> =A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0dev_kfree_skb_irq() {

> =A01) =A0 0.055 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0rai=
se_softirq_irqoff();

> =A01) =A0 0.472 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}

> =A01) =A0 0.049 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gnttab_=
query_foreign_access();

> =A01) =A0 0.058 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gnttab_=
end_foreign_access_ref();

> =A01) =A0 0.058 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gnttab_=
release_grant_reference();

> =A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0dev_kfree_skb_irq() {

> =A01) =A0 0.050 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0rai=
se_softirq_irqoff();

> =A01) =A0 0.456 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}

> =A01) =A0 3.714 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}

> =A01) =A0 0.102 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0_raw_spin_u=
nlock_irqrestore();

> =A01) =A0 4.857 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0}

> =A01) =A0 0.061 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0note_interrupt(=
);

> =A01) =A0 5.571 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0}

> =A01) =A0 0.054 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0_raw_spin_lock();
> =A01) =A0 6.707 us =A0 =A0| =A0 =A0 =A0 =A0 =A0}

> =A01) =A0 0.083 us =A0 =A0| =A0 =A0 =A0 =A0 =A0_raw_spin_unlock();

> =A01) + 10.083 us =A0 | =A0 =A0 =A0 =A0}

> =A01) + 10.985 us =A0 | =A0 =A0 =A0}

> =A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0irq_exit() {

> =A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0rcu_irq_exit() {
> =A01) =A0 0.087 us =A0 =A0| =A0 =A0 =A0 =A0 =A0rcu_enter_nohz();

> =A01) =A0 0.429 us =A0 =A0| =A0 =A0 =A0 =A0}

> =A01) =A0 0.049 us =A0 =A0| =A0 =A0 =A0 =A0idle_cpu();

> =A01) =A0 1.088 us =A0 =A0| =A0 =A0 =A0}

> =A01) + 14.551 us =A0 | =A0 =A0}

> =A01) =A0 0.191 us =A0 =A0| =A0 =A0} /* __inet_lookup_established */








--20cf3074b0a4a1a52f04ccce3736--


--===============3206735932390025830==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3206735932390025830==--


From xen-devel-bounces@lists.xen.org Wed Oct 24 13:39:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 13:39:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR1BM-00056f-43; Wed, 24 Oct 2012 13:39:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR1BL-00056a-4a
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 13:39:39 +0000
Received: from [85.158.143.35:41266] by server-2.bemta-4.messagelabs.com id
	88/AA-22268-A9FE7805; Wed, 24 Oct 2012 13:39:38 +0000
X-Env-Sender: davidxu06@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1351085975!12528094!1
X-Originating-IP: [209.85.216.52]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19675 invoked from network); 24 Oct 2012 13:39:36 -0000
Received: from mail-qa0-f52.google.com (HELO mail-qa0-f52.google.com)
	(209.85.216.52)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 13:39:36 -0000
Received: by mail-qa0-f52.google.com with SMTP id g24so1057278qab.11
	for ; Wed, 24 Oct 2012 06:39:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=IT0NblAhoPM8GquFgm1SXDDhhdaSakgc7+wNRUH3cW4=;
	b=nRVRWtZO7aFXueE1jQ9LFHBzE5foj502aY5Pl3yZNha0B8GTHgo2C3xuE8Y3r4l5GM
	eT4Sdv0/A/qk87d2SsnIW9bjUzy1DxRUCRPvLptVHwxI9JplrIyHPU/1HAxInwiJGvD5
	UeDUelfH7EXkBh9Vzq51gABvut5kwzSJKW9QtWyysrSPBGNZ4gS1he7j82Z2X1jJHwAg
	F4trEfiby/zbmH9Jjx38Kxc1SgCRyTqA159CaTBI5hf5siKSa+A1mnOwxhnP0/jZ+SJJ
	SMf9i8JIzYpBiH/tgaQUM6h0Rkff8AsXk0BYs6nm3dRl8pjoT74m1U3BK4TQrTmEffsS
	BCzQ==
MIME-Version: 1.0
Received: by 10.224.31.204 with SMTP id z12mr7294338qac.32.1351085975512; Wed,
	24 Oct 2012 06:39:35 -0700 (PDT)
Received: by 10.49.1.116 with HTTP; Wed, 24 Oct 2012 06:39:35 -0700 (PDT)
In-Reply-To: <1351070623.2237.120.camel@zakaz.uk.xensource.com>
References: 
	<1351070623.2237.120.camel@zakaz.uk.xensource.com>
Date: Wed, 24 Oct 2012 09:39:35 -0400
Message-ID: 
From: David Xu 
To: Ian Campbell 
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] xen_evtchn_do_upcall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============3206735932390025830=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3206735932390025830==
Content-Type: multipart/alternative; boundary=20cf3074b0a4a1a52f04ccce3736

--20cf3074b0a4a1a52f04ccce3736
Content-Type: text/plain; charset=ISO-8859-1

Hi Lan,

Thanks for your reply. I did a experiment as follows,
I assigned 2 vCPU to a VM, one vCPU (vCPU0) was pinned to a physical CPU
shared with several other VMs and the other vCPU (vCPU1) was pinned to an
idle physical CPU occupied by this VM only. Then in Guest OS I run iperf
server to measure its TCP receiving throughput. In order to shrink the
receiving delay caused by vCPU scheduling, I pin the IRQ context of NIC to
vCPU1 and run iperf server on the vCPU0. This method works well for UDP,
but does not work for TCP. I track the involved function by ftrace and get
the following results which contains lots of xen_evtchn_do_upcall routine.
What's the meaning of this process (xen_evtchn_do_upcall
=> handle_irq_event => xennet_tx_buf_gc =>  gnttab_query_foreign_access)?

 1)               |  tcp_v4_rcv() {
 1)   0.087 us    |    __inet_lookup_established();
 1)               |    sk_filter() {
 1)               |      security_sock_rcv_skb() {
 1)   0.049 us    |        cap_socket_sock_rcv_skb();
 1)   0.374 us    |      }
 1)   0.708 us    |    }
 1)               |    _raw_spin_lock() {
 1)               |    xen_evtchn_do_upcall() {
 1)   0.051 us    |      exit_idle();
 1)               |      irq_enter() {
 1)               |        rcu_irq_enter() {
 1)   0.094 us    |          rcu_exit_nohz();
 1)   0.432 us    |        }
 1)   0.055 us    |        idle_cpu();
 1)   1.166 us    |      }
 1)               |      __xen_evtchn_do_upcall() {
 1)   0.120 us    |        irq_to_desc();
 1)               |        handle_edge_irq() {
 1)   0.103 us    |          _raw_spin_lock();
 1)               |          ack_dynirq() {
 1)               |            evtchn_from_irq() {
 1)               |              info_for_irq() {
 1)               |                irq_get_irq_data() {
 1)   0.051 us    |                  irq_to_desc();
 1)   0.400 us    |                }
 1)   0.746 us    |              }
 1)   1.074 us    |            }
 1)   0.050 us    |            irq_move_irq();
 1)   1.767 us    |          }
 1)               |          handle_irq_event() {
 1)   0.164 us    |            _raw_spin_unlock();
 1)               |            handle_irq_event_percpu() {
 1)               |              xennet_interrupt() {
 1)   0.125 us    |                _raw_spin_lock_irqsave();
 1)               |                xennet_tx_buf_gc() {
 1)   0.082 us    |                  gnttab_query_foreign_access();
 1)   0.050 us    |                  gnttab_end_foreign_access_ref();
 1)   0.070 us    |                  gnttab_release_grant_reference();
 1)               |                  dev_kfree_skb_irq() {
 1)   0.061 us    |                    raise_softirq_irqoff();
 1)   0.460 us    |                  }
 1)   0.058 us    |                  gnttab_query_foreign_access();
 1)   0.050 us    |                  gnttab_end_foreign_access_ref();
 1)   0.050 us    |                  gnttab_release_grant_reference();
 1)               |                  dev_kfree_skb_irq() {
 1)   0.059 us    |                    raise_softirq_irqoff();
 1)   0.440 us    |                  }
 1)   3.710 us    |                }
 1)   0.092 us    |                _raw_spin_unlock_irqrestore();
 1)   4.845 us    |              }
 1)   0.075 us    |              note_interrupt();
 1)   5.567 us    |            }
 1)   0.055 us    |            _raw_spin_lock();
 1)   6.889 us    |          }
 1)   0.080 us    |          _raw_spin_unlock();
 1) + 10.081 us   |        }
 1) + 10.965 us   |      }
 1)               |      irq_exit() {
 1)               |        rcu_irq_exit() {
 1)   0.086 us    |          rcu_enter_nohz();
 1)   0.424 us    |        }
 1)   0.049 us    |        idle_cpu();
 1)   1.094 us    |      }
 1) + 14.555 us   |    }
 1)   0.120 us    |    } /* _raw_spin_lock */
 1)               |    __wake_up_sync_key() {
 1)   0.099 us    |      _raw_spin_lock_irqsave();
 1)               |      __wake_up_common() {
 1)               |        autoremove_wake_function() {
 1)               |          default_wake_function() {
 1)               |            try_to_wake_up() {
 1)   0.103 us    |              _raw_spin_lock_irqsave();
 1)   0.078 us    |              task_waking_fair();
 1)   0.102 us    |              select_task_rq_fair();
 1)               |              xen_smp_send_reschedule() {
 1)               |                xen_send_IPI_one() {
 1)               |                  notify_remote_via_irq() {
 1)               |                    evtchn_from_irq() {
 1)               |                      info_for_irq() {
 1)               |                        irq_get_irq_data() {
 1)   0.067 us    |                          irq_to_desc();
 1)   0.396 us    |                        }
 1)   0.727 us    |                      }
 1)   1.055 us    |                    }
 1)   1.699 us    |                  }
 1)   2.048 us    |                }
 1)   2.407 us    |              }
 1)   0.066 us    |              ttwu_stat();
 1)   0.114 us    |              _raw_spin_unlock_irqrestore();
 1)   4.941 us    |            }
 1)   5.294 us    |          }
 1)   5.645 us    |        }
 1)   6.023 us    |      }
 1)   0.094 us    |      _raw_spin_unlock_irqrestore();
 1)   7.156 us    |    }
 1)   0.058 us    |    dst_metric();
 1)               |    inet_csk_reset_xmit_timer.constprop.34() {
 1)               |      sk_reset_timer() {
 1)               |        mod_timer() {
 1)               |          lock_timer_base.isra.30() {
 1)   0.099 us    |            _raw_spin_lock_irqsave();
 1)   0.436 us    |          }
 1)   0.049 us    |          idle_cpu();
 1)   0.116 us    |          _raw_spin_unlock();
 1)   0.074 us    |          _raw_spin_lock();
 1)   0.072 us    |          internal_add_timer();
 1)   0.103 us    |          _raw_spin_unlock_irqrestore();
 1)   2.673 us    |        }
 1)   3.039 us    |      }
 1)   3.397 us    |    }
 1)   0.082 us    |    _raw_spin_unlock();
 1)   0.061 us    |    sock_put();
 1) + 48.704 us   |  }

When I run both process context of application ( e.g. iperf server ) and
IRQ context on vCPU1 which is the ''fast" core, no any xen_evtchn_do_upcall
routine found.

 1)               |  tcp_v4_rcv() {
 1)   0.081 us    |    __inet_lookup_established();
 1)               |    sk_filter() {
 1)               |      security_sock_rcv_skb() {
 1)   0.059 us    |        cap_socket_sock_rcv_skb();
 1)   0.542 us    |      }
 1)   0.875 us    |    }
 1)   0.060 us    |    _raw_spin_lock();
 1)   0.117 us    |    _raw_spin_unlock();
 1)   0.053 us    |    sock_put();
 1)   2.703 us    |  }

Do you think these  xen_evtchn_do_upcall routines are due to the
synchronization between process context and softirq context? Thanks.

Regards,
Cong


2012/10/24 Ian Campbell 

> On Mon, 2012-10-22 at 02:51 +0100, David Xu wrote:
> > Hi,
> >
> >
> > Is anybody know the purpose of this method (xen_evtchn_do_upcall)?
>
> It is the callback used to inject event channels events (i.e. IRQs) into
> the guest. You would expect to see it at the base of any stack trace
> taken from interrupt context.
>
> >  When I run a user level application involved in TCP receiving and the
> > SoftIRQ for eth0 on the same CPU core, everything is OK. But if I run
> > them on 2 different cores, there will be xen_evtchn_do_upcall()
> > existing (maybe when the local_bh_disable() or local_bh_enable() is
> > called)
>
> it would not be unusual to get an interrupt immediately after
> re-enabling interrupts.
>
> >  in __inet_lookup_established() routine which costs longer time than
> > the first scenario. Is it due to the synchronization issue between
> > process context and softirq context? Thanks for any reply.
> >
> >
> >  1)               |    __inet_lookup_established() {
> >  1)               |    xen_evtchn_do_upcall() {
> >  1)   0.054 us    |      exit_idle();
> >  1)               |      irq_enter() {
> >  1)               |        rcu_irq_enter() {
> >  1)   0.102 us    |          rcu_exit_nohz();
> >  1)   0.431 us    |        }
> >  1)   0.064 us    |        idle_cpu();
> >  1)   1.152 us    |      }
> >  1)               |      __xen_evtchn_do_upcall() {
> >  1)   0.119 us    |        irq_to_desc();
> >  1)               |        handle_edge_irq() {
> >  1)   0.107 us    |          _raw_spin_lock();
> >  1)               |          ack_dynirq() {
> >  1)               |            evtchn_from_irq() {
> >  1)               |              info_for_irq() {
> >  1)               |                irq_get_irq_data() {
> >  1)   0.052 us    |                  irq_to_desc();
> >  1)   0.418 us    |                }
> >  1)   0.782 us    |              }
> >  1)   1.135 us    |            }
> >  1)   0.049 us    |            irq_move_irq();
> >  1)   1.800 us    |          }
> >  1)               |          handle_irq_event() {
> >  1)   0.161 us    |            _raw_spin_unlock();
> >  1)               |            handle_irq_event_percpu() {
> >  1)               |              xennet_interrupt() {
> >  1)   0.125 us    |                _raw_spin_lock_irqsave();
> >  1)               |                xennet_tx_buf_gc() {
> >  1)   0.079 us    |                  gnttab_query_foreign_access();
> >  1)   0.050 us    |                  gnttab_end_foreign_access_ref();
> >  1)   0.069 us    |                  gnttab_release_grant_reference();
> >  1)               |                  dev_kfree_skb_irq() {
> >  1)   0.055 us    |                    raise_softirq_irqoff();
> >  1)   0.472 us    |                  }
> >  1)   0.049 us    |                  gnttab_query_foreign_access();
> >  1)   0.058 us    |                  gnttab_end_foreign_access_ref();
> >  1)   0.058 us    |                  gnttab_release_grant_reference();
> >  1)               |                  dev_kfree_skb_irq() {
> >  1)   0.050 us    |                    raise_softirq_irqoff();
> >  1)   0.456 us    |                  }
> >  1)   3.714 us    |                }
> >  1)   0.102 us    |                _raw_spin_unlock_irqrestore();
> >  1)   4.857 us    |              }
> >  1)   0.061 us    |              note_interrupt();
> >  1)   5.571 us    |            }
> >  1)   0.054 us    |            _raw_spin_lock();
> >  1)   6.707 us    |          }
> >  1)   0.083 us    |          _raw_spin_unlock();
> >  1) + 10.083 us   |        }
> >  1) + 10.985 us   |      }
> >  1)               |      irq_exit() {
> >  1)               |        rcu_irq_exit() {
> >  1)   0.087 us    |          rcu_enter_nohz();
> >  1)   0.429 us    |        }
> >  1)   0.049 us    |        idle_cpu();
> >  1)   1.088 us    |      }
> >  1) + 14.551 us   |    }
> >  1)   0.191 us    |    } /* __inet_lookup_established */
>
>
>

--20cf3074b0a4a1a52f04ccce3736
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Lan,

Thanks for your reply. I did a experiment as fol=
lows,=A0
I assigned 2 vCPU to a VM, one vCPU (vCPU0) was pinned t=
o a physical CPU shared with several other VMs and the other vCPU (vCPU1) w=
as pinned to an idle physical CPU occupied by this VM only. Then in Guest O=
S I run iperf server to measure its TCP receiving throughput. In order to s=
hrink the receiving delay caused by vCPU scheduling, I pin the IRQ context =
of NIC to vCPU1 and run iperf server on the vCPU0. This method works well f=
or UDP, but does not work for TCP. I track the involved function by ftrace =
and get the following results which contains lots of xen_evtchn_do_upcall r=
outine. What's the meaning of this process (xen_evtchn_do_upcall =3D>=
;=A0handle_irq_event =3D>=A0xennet_tx_buf_gc =3D>=A0=A0gnttab_query_f=
oreign_access)?



=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0tcp_v4_rcv(=
) {
=A01) =A0 0.087 us =A0 =A0| =A0 =A0__inet_lookup_established(=
);
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0sk_filter() {
=

=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0security_sock_rcv_skb()=
 {


=A01) =A0 0.049 us =A0 =A0| =A0 =A0 =A0 =A0cap_socket_sock_rcv_skb();<=
/div>
=A01) =A0 0.374 us =A0 =A0| =A0 =A0 =A0}
=A01) =A0 0.70=
8 us =A0 =A0| =A0 =A0}
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =
=A0_raw_spin_lock() {
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0=
xen_evtchn_do_upcall() {


=A01) =A0 0.051 us =A0 =A0| =A0 =A0 =A0exit_idle();
=A01) =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0irq_enter() {
=A01) =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0rcu_irq_enter() {
=A01) =
=A0 0.094 us =A0 =A0| =A0 =A0 =A0 =A0 =A0rcu_exit_nohz();
=A01) =
=A0 0.432 us =A0 =A0| =A0 =A0 =A0 =A0}


=A01) =A0 0.055 us =A0 =A0| =A0 =A0 =A0 =A0idle_cpu();
=A01)=
 =A0 1.166 us =A0 =A0| =A0 =A0 =A0}
=A01) =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 | =A0 =A0 =A0__xen_evtchn_do_upcall() {
=A01) =A0 0.120 us =
=A0 =A0| =A0 =A0 =A0 =A0irq_to_desc();
=A01) =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 | =A0 =A0 =A0 =A0handle_edge_irq() {


=A01) =A0 0.103 us =A0 =A0| =A0 =A0 =A0 =A0 =A0_raw_spin_lock();
=

=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0ack_dynirq() {<=
/div>
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0evtchn=
_from_irq() {
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0=
 =A0 =A0 =A0info_for_irq() {


=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0irq=
_get_irq_data() {
=A01) =A0 0.051 us =A0 =A0| =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0irq_to_desc();
=A01) =A0 0.400 us =A0 =A0| =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0}
=A01) =A0 0.746 us =A0 =A0| =A0 =A0 =
=A0 =A0 =A0 =A0 =A0}

=A01) =A0 1.074 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0}
=A01) =A0 0.=
050 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0irq_move_irq();
=A01) =A0 =
1.767 us =A0 =A0| =A0 =A0 =A0 =A0 =A0}
=A01) =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 | =A0 =A0 =A0 =A0 =A0handle_irq_event() {
=A01) =A0 0.164=
 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0_raw_spin_unlock();


=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0handle_irq_=
event_percpu() {
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =
=A0 =A0 =A0 =A0xennet_interrupt() {
=A01) =A0 0.125 us =A0 =A0| =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0_raw_spin_lock_irqsave();
=A01) =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0xennet_tx_buf_=
gc() {


=A01) =A0 0.082 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gnttab_=
query_foreign_access();
=A01) =A0 0.050 us =A0 =A0| =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0gnttab_end_foreign_access_ref();
=A01) =A0=
 0.070 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gnttab_release_grant_=
reference();


=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0dev_kfree_skb_irq() {
=A01) =A0 0.061 us =A0 =A0| =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0raise_softirq_irqoff();
=A01) =A0 0.46=
0 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
=A01) =A0 0.05=
8 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gnttab_query_foreign_acces=
s();


=A01) =A0 0.050 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gnttab_=
end_foreign_access_ref();
=A01) =A0 0.050 us =A0 =A0| =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0gnttab_release_grant_reference();
=A01) =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dev_kfree_=
skb_irq() {


=A01) =A0 0.059 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0rai=
se_softirq_irqoff();
=A01) =A0 0.440 us =A0 =A0| =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0}
=A01) =A0 3.710 us =A0 =A0| =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0}
=A01) =A0 0.092 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0_raw_spin_unlock_irqrestore();


=A01) =A0 4.845 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0}
=A0=
1) =A0 0.075 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0note_interrupt();
=

=A01) =A0 5.567 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0}
=A01) =
=A0 0.055 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0_raw_spin_lock();
=
=A01) =A0 6.889 us =A0 =A0| =A0 =A0 =A0 =A0 =A0}


=A01) =A0 0.080 us =A0 =A0| =A0 =A0 =A0 =A0 =A0_raw_spin_unlock();
=A01) + 10.081 us =A0 | =A0 =A0 =A0 =A0}
=A01) + 10.965 us=
 =A0 | =A0 =A0 =A0}
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =
=A0irq_exit() {
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =
=A0rcu_irq_exit() {


=A01) =A0 0.086 us =A0 =A0| =A0 =A0 =A0 =A0 =A0rcu_enter_nohz();
=

=A01) =A0 0.424 us =A0 =A0| =A0 =A0 =A0 =A0}
=A01) =A0 0.049=
 us =A0 =A0| =A0 =A0 =A0 =A0idle_cpu();
=A01) =A0 1.094 us =A0 =
=A0| =A0 =A0 =A0}
=A01) + 14.555 us =A0 | =A0 =A0}

=A01) =A0 0.120 us =A0 =A0| =A0 =A0} /* _raw_spin_lock */
=A01) =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0__wake_up_sync_key() {
=A01)=
 =A0 0.099 us =A0 =A0| =A0 =A0 =A0_raw_spin_lock_irqsave();
=A01)=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0__wake_up_common() {


=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0autoremove_wake_fun=
ction() {
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0=
default_wake_function() {
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0=
 =A0 =A0 =A0 =A0 =A0try_to_wake_up() {
=A01) =A0 0.103 us =A0 =A0=
| =A0 =A0 =A0 =A0 =A0 =A0 =A0_raw_spin_lock_irqsave();


=A01) =A0 0.078 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0task_waking_fai=
r();
=A01) =A0 0.102 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0selec=
t_task_rq_fair();
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0=
 =A0 =A0 =A0 =A0xen_smp_send_reschedule() {
=A01) =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0xen_send_IPI_one() {


=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0notify_remote_via_irq() {
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0evtchn_from_irq() {
=A01) =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0in=
fo_for_irq() {
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0irq_get_irq_data() {


=A01) =A0 0.067 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0irq_to_desc();
=A01) =A0 0.396 us =A0 =A0| =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
=A01) =A0 0.727 us =A0 =A0|=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
=A01) =A0 1.055 us =
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}


=A01) =A0 1.699 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
=

=A01) =A0 2.048 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
=A01) =A0 2.407 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0}
=A01) =
=A0 0.066 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0ttwu_stat();
=A0=
1) =A0 0.114 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0_raw_spin_unlock_irqres=
tore();


=A01) =A0 4.941 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0}
=A01) =
=A0 5.294 us =A0 =A0| =A0 =A0 =A0 =A0 =A0}
=A01) =A0 5.645 us =A0=
 =A0| =A0 =A0 =A0 =A0}
=A01) =A0 6.023 us =A0 =A0| =A0 =A0 =A0}
=A01) =A0 0.094 us =A0 =A0| =A0 =A0 =A0_raw_spin_unlock_irqrestore=
();


=A01) =A0 7.156 us =A0 =A0| =A0 =A0}
=A01) =A0 0.058 us =A0 =
=A0| =A0 =A0dst_metric();
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0=
 =A0inet_csk_reset_xmit_timer.constprop.34() {
=A01) =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 | =A0 =A0 =A0sk_reset_timer() {
=A01) =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0mod_timer() {


=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0lock_timer_base=
.isra.30() {
=A01) =A0 0.099 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0_=
raw_spin_lock_irqsave();
=A01) =A0 0.436 us =A0 =A0| =A0 =A0 =A0 =
=A0 =A0}
=A01) =A0 0.049 us =A0 =A0| =A0 =A0 =A0 =A0 =A0idle_cpu(=
);


=A01) =A0 0.116 us =A0 =A0| =A0 =A0 =A0 =A0 =A0_raw_spin_unlock();
=A01) =A0 0.074 us =A0 =A0| =A0 =A0 =A0 =A0 =A0_raw_spin_lock();
=A01) =A0 0.072 us =A0 =A0| =A0 =A0 =A0 =A0 =A0internal_add_timer();=

=A01) =A0 0.103 us =A0 =A0| =A0 =A0 =A0 =A0 =A0_raw_spin_unlock_=
irqrestore();


=A01) =A0 2.673 us =A0 =A0| =A0 =A0 =A0 =A0}
=A01) =A0 3.039=
 us =A0 =A0| =A0 =A0 =A0}
=A01) =A0 3.397 us =A0 =A0| =A0 =A0}
=A01) =A0 0.082 us =A0 =A0| =A0 =A0_raw_spin_unlock();
=
=A01) =A0 0.061 us =A0 =A0| =A0 =A0sock_put();
=A01) + 48.704 us =
=A0 | =A0}



When I run both process context of application ( =
e.g. iperf server ) and IRQ context on vCPU1 which is the ''fast&qu=
ot; core, no any=A0xen_evtchn_do_upcall routine found.=A0



=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0tcp_v4_rcv() {
=
=A01) =A0 0.081 us =A0 =A0| =A0 =A0__inet_lookup_established();
=
=A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0sk_filter() {
=A01) =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0security_sock_rcv_skb() {


=A01) =A0 0.059 us =A0 =A0| =A0 =A0 =A0 =A0cap_socket_sock_rcv_skb();<=
/div>
=A01) =A0 0.542 us =A0 =A0| =A0 =A0 =A0}
=A01) =A0 0.87=
5 us =A0 =A0| =A0 =A0}
=A01) =A0 0.060 us =A0 =A0| =A0 =A0_raw_sp=
in_lock();
=A01) =A0 0.117 us =A0 =A0| =A0 =A0_raw_spin_unlock();=



=A01) =A0 0.053 us =A0 =A0| =A0 =A0sock_put();
=A01) =A0 2.7=
03 us =A0 =A0| =A0}

Do you think these=A0=A0=
xen_evtchn_do_upcall routines are due to the synchronization between proces=
s context and softirq context? Thanks.



Regards,
Cong


2012/10/24 Ian Campbell <Ian.Campbell@citri=
x.com>


On Mon, 2012-10-22 at 02:5=
1 +0100, David Xu wrote:

> Hi,

>

>

> Is anybody know the purpose of this method (xen_evtchn_do_upcall)?




It is the callback used to inject event channels events (i.e. IRQs) i=
nto

the guest. You would expect to see it at the base of any stack trace

taken from interrupt context.




> =A0When I run a user level application involved in TCP receiving and t=
he

> SoftIRQ for eth0 on the same CPU core, everything is OK. But if I run<=
br>
> them on 2 different cores, there will be xen_evtchn_do_upcall()

> existing (maybe when the local_bh_disable() or local_bh_enable() is
> called)




it would not be unusual to get an interrupt immediately after

re-enabling interrupts.




> =A0in __inet_lookup_established() routine which costs longer time than=


> the first scenario. Is it due to the synchronization issue between

> process context and softirq context? Thanks for any reply.

>

>

> =A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0__inet_lookup_established()=
 {

> =A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0xen_evtchn_do_upcall() {
> =A01) =A0 0.054 us =A0 =A0| =A0 =A0 =A0exit_idle();

> =A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0irq_enter() {

> =A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0rcu_irq_enter() {
> =A01) =A0 0.102 us =A0 =A0| =A0 =A0 =A0 =A0 =A0rcu_exit_nohz();

> =A01) =A0 0.431 us =A0 =A0| =A0 =A0 =A0 =A0}

> =A01) =A0 0.064 us =A0 =A0| =A0 =A0 =A0 =A0idle_cpu();

> =A01) =A0 1.152 us =A0 =A0| =A0 =A0 =A0}

> =A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0__xen_evtchn_do_upcall(=
) {

> =A01) =A0 0.119 us =A0 =A0| =A0 =A0 =A0 =A0irq_to_desc();

> =A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0handle_edge_irq() {=


> =A01) =A0 0.107 us =A0 =A0| =A0 =A0 =A0 =A0 =A0_raw_spin_lock();

> =A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0ack_dynirq() {<=
br>
> =A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0evtchn_from=
_irq() {

> =A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0info_fo=
r_irq() {

> =A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0irq=
_get_irq_data() {

> =A01) =A0 0.052 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0irq_to_=
desc();

> =A01) =A0 0.418 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}

> =A01) =A0 0.782 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0}

> =A01) =A0 1.135 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0}

> =A01) =A0 0.049 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0irq_move_irq();

> =A01) =A0 1.800 us =A0 =A0| =A0 =A0 =A0 =A0 =A0}

> =A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0handle_irq_even=
t() {

> =A01) =A0 0.161 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0_raw_spin_unlock();=


> =A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0handle_irq_=
event_percpu() {

> =A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0xennet_=
interrupt() {

> =A01) =A0 0.125 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0_raw_spin_l=
ock_irqsave();

> =A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0xen=
net_tx_buf_gc() {

> =A01) =A0 0.079 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gnttab_=
query_foreign_access();

> =A01) =A0 0.050 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gnttab_=
end_foreign_access_ref();

> =A01) =A0 0.069 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gnttab_=
release_grant_reference();

> =A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0dev_kfree_skb_irq() {

> =A01) =A0 0.055 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0rai=
se_softirq_irqoff();

> =A01) =A0 0.472 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}

> =A01) =A0 0.049 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gnttab_=
query_foreign_access();

> =A01) =A0 0.058 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gnttab_=
end_foreign_access_ref();

> =A01) =A0 0.058 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gnttab_=
release_grant_reference();

> =A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0dev_kfree_skb_irq() {

> =A01) =A0 0.050 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0rai=
se_softirq_irqoff();

> =A01) =A0 0.456 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}

> =A01) =A0 3.714 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}

> =A01) =A0 0.102 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0_raw_spin_u=
nlock_irqrestore();

> =A01) =A0 4.857 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0}

> =A01) =A0 0.061 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0note_interrupt(=
);

> =A01) =A0 5.571 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0}

> =A01) =A0 0.054 us =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0_raw_spin_lock();
> =A01) =A0 6.707 us =A0 =A0| =A0 =A0 =A0 =A0 =A0}

> =A01) =A0 0.083 us =A0 =A0| =A0 =A0 =A0 =A0 =A0_raw_spin_unlock();

> =A01) + 10.083 us =A0 | =A0 =A0 =A0 =A0}

> =A01) + 10.985 us =A0 | =A0 =A0 =A0}

> =A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0irq_exit() {

> =A01) =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0rcu_irq_exit() {
> =A01) =A0 0.087 us =A0 =A0| =A0 =A0 =A0 =A0 =A0rcu_enter_nohz();

> =A01) =A0 0.429 us =A0 =A0| =A0 =A0 =A0 =A0}

> =A01) =A0 0.049 us =A0 =A0| =A0 =A0 =A0 =A0idle_cpu();

> =A01) =A0 1.088 us =A0 =A0| =A0 =A0 =A0}

> =A01) + 14.551 us =A0 | =A0 =A0}

> =A01) =A0 0.191 us =A0 =A0| =A0 =A0} /* __inet_lookup_established */








--20cf3074b0a4a1a52f04ccce3736--


--===============3206735932390025830==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3206735932390025830==--


From xen-devel-bounces@lists.xen.org Wed Oct 24 13:44:22 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 13:44:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR1Ff-0005GI-Vq; Wed, 24 Oct 2012 13:44:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR1Fe-0005GB-F4
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 13:44:06 +0000
Received: from [85.158.139.83:49690] by server-15.bemta-5.messagelabs.com id
	8A/59-26920-5A0F7805; Wed, 24 Oct 2012 13:44:05 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1351086243!24558873!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3283 invoked from network); 24 Oct 2012 13:44:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 13:44:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15359719"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 13:44:02 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 24 Oct 2012 14:44:02 +0100
Date: Wed, 24 Oct 2012 14:43:33 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1351084777-28898-4-git-send-email-ian.campbell@citrix.com>
Message-ID: 
References: <1351084756.18035.28.camel@zakaz.uk.xensource.com>
	<1351084777-28898-4-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	xen-devel ,
	linux-kernel ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 4/5] xen: arm: implement remap interfaces
 needed for privcmd mappings.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 24 Oct 2012, Ian Campbell wrote:
> We use XENMEM_add_to_physmap_range which is the preferred interface
> for foreign mappings.
> 
> Signed-off-by: Ian Campbell 

Acked-by: Stefano Stabellini 


>  arch/arm/include/asm/xen/interface.h |    1 +
>  arch/arm/xen/enlighten.c             |  100 +++++++++++++++++++++++++++++++++-
>  arch/x86/include/asm/xen/interface.h |    1 +
>  include/xen/interface/memory.h       |   18 ++++++
>  4 files changed, 117 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
> index 5000397..1151188 100644
> --- a/arch/arm/include/asm/xen/interface.h
> +++ b/arch/arm/include/asm/xen/interface.h
> @@ -49,6 +49,7 @@ DEFINE_GUEST_HANDLE(void);
>  DEFINE_GUEST_HANDLE(uint64_t);
>  DEFINE_GUEST_HANDLE(uint32_t);
>  DEFINE_GUEST_HANDLE(xen_pfn_t);
> +DEFINE_GUEST_HANDLE(xen_ulong_t);
>  
>  /* Maximum number of virtual CPUs in multi-processor guests. */
>  #define MAX_VIRT_CPUS 1
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index ba5cc13..f28fc1a 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -9,6 +9,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -18,6 +19,8 @@
>  #include 
>  #include 
>  
> +#include 
> +
>  struct start_info _xen_start_info;
>  struct start_info *xen_start_info = &_xen_start_info;
>  EXPORT_SYMBOL_GPL(xen_start_info);
> @@ -43,15 +46,106 @@ EXPORT_SYMBOL_GPL(xen_platform_pci_unplug);
>  
>  static __read_mostly int xen_events_irq = -1;
>  
> +/* map fgmfn of domid to lpfn in the current domain */
> +static int map_foreign_page(unsigned long lpfn, unsigned long fgmfn,
> +			    unsigned int domid)
> +{
> +	int rc;
> +	struct xen_add_to_physmap_range xatp = {
> +		.domid = DOMID_SELF,
> +		.foreign_domid = domid,
> +		.size = 1,
> +		.space = XENMAPSPACE_gmfn_foreign,
> +	};
> +	xen_ulong_t idx = fgmfn;
> +	xen_pfn_t gpfn = lpfn;
> +
> +	set_xen_guest_handle(xatp.idxs, &idx);
> +	set_xen_guest_handle(xatp.gpfns, &gpfn);
> +
> +	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap_range, &xatp);
> +	if (rc) {
> +		pr_warn("Failed to map pfn to mfn rc:%d pfn:%lx mfn:%lx\n",
> +			rc, lpfn, fgmfn);
> +		return 1;
> +	}
> +	return 0;
> +}
> +
> +struct remap_data {
> +	xen_pfn_t fgmfn; /* foreign domain's gmfn */
> +	pgprot_t prot;
> +	domid_t  domid;
> +	struct vm_area_struct *vma;
> +	int index;
> +	struct page **pages;
> +	struct xen_remap_mfn_info *info;
> +};
> +
> +static int remap_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr,
> +			void *data)
> +{
> +	struct remap_data *info = data;
> +	struct page *page = info->pages[info->index++];
> +	unsigned long pfn = page_to_pfn(page);
> +	pte_t pte = pfn_pte(pfn, info->prot);
> +
> +	if (map_foreign_page(pfn, info->fgmfn, info->domid))
> +		return -EFAULT;
> +	set_pte_at(info->vma->vm_mm, addr, ptep, pte);
> +
> +	return 0;
> +}
> +
>  int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
>  			       unsigned long addr,
> -			       unsigned long mfn, int nr,
> -			       pgprot_t prot, unsigned domid)
> +			       xen_pfn_t mfn, int nr,
> +			       pgprot_t prot, unsigned domid,
> +			       struct page **pages)
>  {
> -	return -ENOSYS;
> +	int err;
> +	struct remap_data data;
> +
> +	/* TBD: Batching, current sole caller only does page at a time */
> +	if (nr > 1)
> +		return -EINVAL;
> +
> +	data.fgmfn = mfn;
> +	data.prot = prot;
> +	data.domid = domid;
> +	data.vma = vma;
> +	data.index = 0;
> +	data.pages = pages;
> +	err = apply_to_page_range(vma->vm_mm, addr, nr << PAGE_SHIFT,
> +				  remap_pte_fn, &data);
> +	return err;
>  }
>  EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
>  
> +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
> +			       int nr, struct page **pages)
> +{
> +	int i;
> +
> +	for (i = 0; i < nr; i++) {
> +		struct xen_remove_from_physmap xrp;
> +		unsigned long rc, pfn;
> +
> +		pfn = page_to_pfn(pages[i]);
> +
> +		xrp.domid = DOMID_SELF;
> +		xrp.gpfn = pfn;
> +		rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, &xrp);
> +		if (rc) {
> +			pr_warn("Failed to unmap pfn:%lx rc:%ld\n",
> +				pfn, rc);
> +			return rc;
> +		}
> +	}
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range);
> +
>  /*
>   * see Documentation/devicetree/bindings/arm/xen.txt for the
>   * documentation of the Xen Device Tree format.
> diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
> index b459d2e..20e738a 100644
> --- a/arch/x86/include/asm/xen/interface.h
> +++ b/arch/x86/include/asm/xen/interface.h
> @@ -63,6 +63,7 @@ DEFINE_GUEST_HANDLE(void);
>  DEFINE_GUEST_HANDLE(uint64_t);
>  DEFINE_GUEST_HANDLE(uint32_t);
>  DEFINE_GUEST_HANDLE(xen_pfn_t);
> +DEFINE_GUEST_HANDLE(xen_ulong_t);
>  #endif
>  
>  #ifndef HYPERVISOR_VIRT_START
> diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
> index ad0dff5..5de2b36 100644
> --- a/include/xen/interface/memory.h
> +++ b/include/xen/interface/memory.h
> @@ -188,6 +188,24 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_physmap);
>  /*** REMOVED ***/
>  /*#define XENMEM_translate_gpfn_list  8*/
>  
> +#define XENMEM_add_to_physmap_range 23
> +struct xen_add_to_physmap_range {
> +    /* Which domain to change the mapping for. */
> +    domid_t domid;
> +    uint16_t space; /* => enum phys_map_space */
> +
> +    /* Number of pages to go through */
> +    uint16_t size;
> +    domid_t foreign_domid; /* IFF gmfn_foreign */
> +
> +    /* Indexes into space being mapped. */
> +    GUEST_HANDLE(xen_ulong_t) idxs;
> +
> +    /* GPFN in domid where the source mapping page should appear. */
> +    GUEST_HANDLE(xen_pfn_t) gpfns;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_physmap_range);
> +
>  /*
>   * Returns the pseudo-physical memory map as it was when the domain
>   * was started (specified by XENMEM_set_memory_map).
> -- 
> 1.7.2.5
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 13:44:22 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 13:44:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR1Ff-0005GI-Vq; Wed, 24 Oct 2012 13:44:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR1Fe-0005GB-F4
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 13:44:06 +0000
Received: from [85.158.139.83:49690] by server-15.bemta-5.messagelabs.com id
	8A/59-26920-5A0F7805; Wed, 24 Oct 2012 13:44:05 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1351086243!24558873!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3283 invoked from network); 24 Oct 2012 13:44:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 13:44:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15359719"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 13:44:02 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 24 Oct 2012 14:44:02 +0100
Date: Wed, 24 Oct 2012 14:43:33 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1351084777-28898-4-git-send-email-ian.campbell@citrix.com>
Message-ID: 
References: <1351084756.18035.28.camel@zakaz.uk.xensource.com>
	<1351084777-28898-4-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	xen-devel ,
	linux-kernel ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 4/5] xen: arm: implement remap interfaces
 needed for privcmd mappings.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 24 Oct 2012, Ian Campbell wrote:
> We use XENMEM_add_to_physmap_range which is the preferred interface
> for foreign mappings.
> 
> Signed-off-by: Ian Campbell 

Acked-by: Stefano Stabellini 


>  arch/arm/include/asm/xen/interface.h |    1 +
>  arch/arm/xen/enlighten.c             |  100 +++++++++++++++++++++++++++++++++-
>  arch/x86/include/asm/xen/interface.h |    1 +
>  include/xen/interface/memory.h       |   18 ++++++
>  4 files changed, 117 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
> index 5000397..1151188 100644
> --- a/arch/arm/include/asm/xen/interface.h
> +++ b/arch/arm/include/asm/xen/interface.h
> @@ -49,6 +49,7 @@ DEFINE_GUEST_HANDLE(void);
>  DEFINE_GUEST_HANDLE(uint64_t);
>  DEFINE_GUEST_HANDLE(uint32_t);
>  DEFINE_GUEST_HANDLE(xen_pfn_t);
> +DEFINE_GUEST_HANDLE(xen_ulong_t);
>  
>  /* Maximum number of virtual CPUs in multi-processor guests. */
>  #define MAX_VIRT_CPUS 1
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index ba5cc13..f28fc1a 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -9,6 +9,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -18,6 +19,8 @@
>  #include 
>  #include 
>  
> +#include 
> +
>  struct start_info _xen_start_info;
>  struct start_info *xen_start_info = &_xen_start_info;
>  EXPORT_SYMBOL_GPL(xen_start_info);
> @@ -43,15 +46,106 @@ EXPORT_SYMBOL_GPL(xen_platform_pci_unplug);
>  
>  static __read_mostly int xen_events_irq = -1;
>  
> +/* map fgmfn of domid to lpfn in the current domain */
> +static int map_foreign_page(unsigned long lpfn, unsigned long fgmfn,
> +			    unsigned int domid)
> +{
> +	int rc;
> +	struct xen_add_to_physmap_range xatp = {
> +		.domid = DOMID_SELF,
> +		.foreign_domid = domid,
> +		.size = 1,
> +		.space = XENMAPSPACE_gmfn_foreign,
> +	};
> +	xen_ulong_t idx = fgmfn;
> +	xen_pfn_t gpfn = lpfn;
> +
> +	set_xen_guest_handle(xatp.idxs, &idx);
> +	set_xen_guest_handle(xatp.gpfns, &gpfn);
> +
> +	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap_range, &xatp);
> +	if (rc) {
> +		pr_warn("Failed to map pfn to mfn rc:%d pfn:%lx mfn:%lx\n",
> +			rc, lpfn, fgmfn);
> +		return 1;
> +	}
> +	return 0;
> +}
> +
> +struct remap_data {
> +	xen_pfn_t fgmfn; /* foreign domain's gmfn */
> +	pgprot_t prot;
> +	domid_t  domid;
> +	struct vm_area_struct *vma;
> +	int index;
> +	struct page **pages;
> +	struct xen_remap_mfn_info *info;
> +};
> +
> +static int remap_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr,
> +			void *data)
> +{
> +	struct remap_data *info = data;
> +	struct page *page = info->pages[info->index++];
> +	unsigned long pfn = page_to_pfn(page);
> +	pte_t pte = pfn_pte(pfn, info->prot);
> +
> +	if (map_foreign_page(pfn, info->fgmfn, info->domid))
> +		return -EFAULT;
> +	set_pte_at(info->vma->vm_mm, addr, ptep, pte);
> +
> +	return 0;
> +}
> +
>  int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
>  			       unsigned long addr,
> -			       unsigned long mfn, int nr,
> -			       pgprot_t prot, unsigned domid)
> +			       xen_pfn_t mfn, int nr,
> +			       pgprot_t prot, unsigned domid,
> +			       struct page **pages)
>  {
> -	return -ENOSYS;
> +	int err;
> +	struct remap_data data;
> +
> +	/* TBD: Batching, current sole caller only does page at a time */
> +	if (nr > 1)
> +		return -EINVAL;
> +
> +	data.fgmfn = mfn;
> +	data.prot = prot;
> +	data.domid = domid;
> +	data.vma = vma;
> +	data.index = 0;
> +	data.pages = pages;
> +	err = apply_to_page_range(vma->vm_mm, addr, nr << PAGE_SHIFT,
> +				  remap_pte_fn, &data);
> +	return err;
>  }
>  EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
>  
> +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
> +			       int nr, struct page **pages)
> +{
> +	int i;
> +
> +	for (i = 0; i < nr; i++) {
> +		struct xen_remove_from_physmap xrp;
> +		unsigned long rc, pfn;
> +
> +		pfn = page_to_pfn(pages[i]);
> +
> +		xrp.domid = DOMID_SELF;
> +		xrp.gpfn = pfn;
> +		rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, &xrp);
> +		if (rc) {
> +			pr_warn("Failed to unmap pfn:%lx rc:%ld\n",
> +				pfn, rc);
> +			return rc;
> +		}
> +	}
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range);
> +
>  /*
>   * see Documentation/devicetree/bindings/arm/xen.txt for the
>   * documentation of the Xen Device Tree format.
> diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
> index b459d2e..20e738a 100644
> --- a/arch/x86/include/asm/xen/interface.h
> +++ b/arch/x86/include/asm/xen/interface.h
> @@ -63,6 +63,7 @@ DEFINE_GUEST_HANDLE(void);
>  DEFINE_GUEST_HANDLE(uint64_t);
>  DEFINE_GUEST_HANDLE(uint32_t);
>  DEFINE_GUEST_HANDLE(xen_pfn_t);
> +DEFINE_GUEST_HANDLE(xen_ulong_t);
>  #endif
>  
>  #ifndef HYPERVISOR_VIRT_START
> diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
> index ad0dff5..5de2b36 100644
> --- a/include/xen/interface/memory.h
> +++ b/include/xen/interface/memory.h
> @@ -188,6 +188,24 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_physmap);
>  /*** REMOVED ***/
>  /*#define XENMEM_translate_gpfn_list  8*/
>  
> +#define XENMEM_add_to_physmap_range 23
> +struct xen_add_to_physmap_range {
> +    /* Which domain to change the mapping for. */
> +    domid_t domid;
> +    uint16_t space; /* => enum phys_map_space */
> +
> +    /* Number of pages to go through */
> +    uint16_t size;
> +    domid_t foreign_domid; /* IFF gmfn_foreign */
> +
> +    /* Indexes into space being mapped. */
> +    GUEST_HANDLE(xen_ulong_t) idxs;
> +
> +    /* GPFN in domid where the source mapping page should appear. */
> +    GUEST_HANDLE(xen_pfn_t) gpfns;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_physmap_range);
> +
>  /*
>   * Returns the pseudo-physical memory map as it was when the domain
>   * was started (specified by XENMEM_set_memory_map).
> -- 
> 1.7.2.5
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 13:55:56 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 13:55:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR1Qk-0005RC-5j; Wed, 24 Oct 2012 13:55:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR1Qi-0005R7-JP
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 13:55:32 +0000
Received: from [85.158.138.51:58513] by server-9.bemta-3.messagelabs.com id
	20/48-16841-353F7805; Wed, 24 Oct 2012 13:55:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1351086929!26747357!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22805 invoked from network); 24 Oct 2012 13:55:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 13:55:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15360147"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 13:54:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 14:54:44 +0100
Message-ID: <1351086882.18035.45.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: David Xu 
Date: Wed, 24 Oct 2012 14:54:42 +0100
In-Reply-To: 
References: 
	<1351070623.2237.120.camel@zakaz.uk.xensource.com>
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] xen_evtchn_do_upcall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 14:39 +0100, David Xu wrote:
> Hi Lan,
> 
> 
> Thanks for your reply. I did a experiment as follows, 
> I assigned 2 vCPU to a VM, one vCPU (vCPU0) was pinned to a physical
> CPU shared with several other VMs and the other vCPU (vCPU1) was
> pinned to an idle physical CPU occupied by this VM only. Then in Guest
> OS I run iperf server to measure its TCP receiving throughput. In
> order to shrink the receiving delay caused by vCPU scheduling, I pin
> the IRQ context of NIC to vCPU1 and run iperf server on the vCPU0.
> This method works well for UDP, but does not work for TCP. I track the
> involved function by ftrace and get the following results which
> contains lots of xen_evtchn_do_upcall routine. What's the meaning of
> this process (xen_evtchn_do_upcall => handle_irq_event =>
> xennet_tx_buf_gc =>  gnttab_query_foreign_access)?

Have you looked at the code for any of those functions?

If you had done you'd find it is pretty obviously an interrupt being
delivered to the network device and the associated work to satisfy that
interrupt.

It doesn't seem that surprising that an iperf test should involve lots
of network interrupts.

It's not entirely clear to me what you are expecting to find and/or what
you are trying to prove.

> When I run both process context of application ( e.g. iperf server )
> and IRQ context on vCPU1 which is the ''fast" core, no
> any xen_evtchn_do_upcall routine found. 

Perhaps on the fast core NAPI is able to kick in and therefore the NIC
becomes polled instead of interrupt driven?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 13:55:56 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 13:55:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR1Qk-0005RC-5j; Wed, 24 Oct 2012 13:55:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR1Qi-0005R7-JP
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 13:55:32 +0000
Received: from [85.158.138.51:58513] by server-9.bemta-3.messagelabs.com id
	20/48-16841-353F7805; Wed, 24 Oct 2012 13:55:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1351086929!26747357!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22805 invoked from network); 24 Oct 2012 13:55:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 13:55:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15360147"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 13:54:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 14:54:44 +0100
Message-ID: <1351086882.18035.45.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: David Xu 
Date: Wed, 24 Oct 2012 14:54:42 +0100
In-Reply-To: 
References: 
	<1351070623.2237.120.camel@zakaz.uk.xensource.com>
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] xen_evtchn_do_upcall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 14:39 +0100, David Xu wrote:
> Hi Lan,
> 
> 
> Thanks for your reply. I did a experiment as follows, 
> I assigned 2 vCPU to a VM, one vCPU (vCPU0) was pinned to a physical
> CPU shared with several other VMs and the other vCPU (vCPU1) was
> pinned to an idle physical CPU occupied by this VM only. Then in Guest
> OS I run iperf server to measure its TCP receiving throughput. In
> order to shrink the receiving delay caused by vCPU scheduling, I pin
> the IRQ context of NIC to vCPU1 and run iperf server on the vCPU0.
> This method works well for UDP, but does not work for TCP. I track the
> involved function by ftrace and get the following results which
> contains lots of xen_evtchn_do_upcall routine. What's the meaning of
> this process (xen_evtchn_do_upcall => handle_irq_event =>
> xennet_tx_buf_gc =>  gnttab_query_foreign_access)?

Have you looked at the code for any of those functions?

If you had done you'd find it is pretty obviously an interrupt being
delivered to the network device and the associated work to satisfy that
interrupt.

It doesn't seem that surprising that an iperf test should involve lots
of network interrupts.

It's not entirely clear to me what you are expecting to find and/or what
you are trying to prove.

> When I run both process context of application ( e.g. iperf server )
> and IRQ context on vCPU1 which is the ''fast" core, no
> any xen_evtchn_do_upcall routine found. 

Perhaps on the fast core NAPI is able to kick in and therefore the NIC
becomes polled instead of interrupt driven?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 14:02:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 14:02:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR1XQ-0005en-5A; Wed, 24 Oct 2012 14:02:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR1XP-0005ei-1B
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 14:02:27 +0000
Received: from [85.158.139.211:5587] by server-10.bemta-5.messagelabs.com id
	1A/BD-01025-1F4F7805; Wed, 24 Oct 2012 14:02:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1351087327!23549160!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11416 invoked from network); 24 Oct 2012 14:02:08 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 14:02:08 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15360397"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 14:02:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 15:02:07 +0100
Message-ID: <1351087326.18035.50.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Eric Dumazet 
Date: Wed, 24 Oct 2012 15:02:06 +0100
In-Reply-To: <1351085403.6537.102.camel@edumazet-glaptop>
References: <1351078936-14159-1-git-send-email-ian.campbell@citrix.com>
	<1351081703.6537.99.camel@edumazet-glaptop>
	<1351084618.18035.27.camel@zakaz.uk.xensource.com>
	<1351085403.6537.102.camel@edumazet-glaptop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" ,
	Eric Dumazet ,
	"xen-devel@lists.xen.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH] net: allow configuration of the size of
 page in __netdev_alloc_frag
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 14:30 +0100, Eric Dumazet wrote:
> It seems to me its a driver issue, for example
> drivers/net/xen-netfront.c has assumptions that can be easily fixed.

The netfront ->head thing is a separate (although perhaps related)
issue, I intended to fix along the same lines as the previous netback
except for some unfathomable reason I haven't been able to reproduce the
problem with netfront -- I've no idea why though since it seems like it
should be a no brainer!

> Why skb->head can be on order-1 or order-2 pages and this is working ?

skb->head being order 1 or 2 isn't working for me. The driver I'm having
issues with which caused me to create this particular patch is the tg3
driver (although I don't think this is by any means specific to tg3).

For the ->head the tg3 driver does:
        mapping = pci_map_single(tp->pdev, skb->data, len, PCI_DMA_TODEVICE);
while for the frags it does:
        mapping = skb_frag_dma_map(&tp->pdev->dev, frag, 0, len, DMA_TO_DEVICE);

This ought to do the Right Thing but doesn't seem to be working. Konrad
suspected an issue with the swiotlb's handling of order>0 pages in some
cases. As I said in the commit message he is looking into this issue.

My concern however was that even once the swiotlb is fixed to work right
the effect of pci_map_single on a order>0 page is going to be that the
data gets bounced into contiguous memory -- that is a memcpy which would
undo the benefit of having allocating large pages to start with. So I
figured that in such cases we'd be better off just using order 0
allocations to start with.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 14:02:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 14:02:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR1XQ-0005en-5A; Wed, 24 Oct 2012 14:02:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR1XP-0005ei-1B
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 14:02:27 +0000
Received: from [85.158.139.211:5587] by server-10.bemta-5.messagelabs.com id
	1A/BD-01025-1F4F7805; Wed, 24 Oct 2012 14:02:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1351087327!23549160!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11416 invoked from network); 24 Oct 2012 14:02:08 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 14:02:08 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15360397"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 14:02:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 15:02:07 +0100
Message-ID: <1351087326.18035.50.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Eric Dumazet 
Date: Wed, 24 Oct 2012 15:02:06 +0100
In-Reply-To: <1351085403.6537.102.camel@edumazet-glaptop>
References: <1351078936-14159-1-git-send-email-ian.campbell@citrix.com>
	<1351081703.6537.99.camel@edumazet-glaptop>
	<1351084618.18035.27.camel@zakaz.uk.xensource.com>
	<1351085403.6537.102.camel@edumazet-glaptop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" ,
	Eric Dumazet ,
	"xen-devel@lists.xen.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH] net: allow configuration of the size of
 page in __netdev_alloc_frag
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 14:30 +0100, Eric Dumazet wrote:
> It seems to me its a driver issue, for example
> drivers/net/xen-netfront.c has assumptions that can be easily fixed.

The netfront ->head thing is a separate (although perhaps related)
issue, I intended to fix along the same lines as the previous netback
except for some unfathomable reason I haven't been able to reproduce the
problem with netfront -- I've no idea why though since it seems like it
should be a no brainer!

> Why skb->head can be on order-1 or order-2 pages and this is working ?

skb->head being order 1 or 2 isn't working for me. The driver I'm having
issues with which caused me to create this particular patch is the tg3
driver (although I don't think this is by any means specific to tg3).

For the ->head the tg3 driver does:
        mapping = pci_map_single(tp->pdev, skb->data, len, PCI_DMA_TODEVICE);
while for the frags it does:
        mapping = skb_frag_dma_map(&tp->pdev->dev, frag, 0, len, DMA_TO_DEVICE);

This ought to do the Right Thing but doesn't seem to be working. Konrad
suspected an issue with the swiotlb's handling of order>0 pages in some
cases. As I said in the commit message he is looking into this issue.

My concern however was that even once the swiotlb is fixed to work right
the effect of pci_map_single on a order>0 page is going to be that the
data gets bounced into contiguous memory -- that is a memcpy which would
undo the benefit of having allocating large pages to start with. So I
figured that in such cases we'd be better off just using order 0
allocations to start with.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 14:09:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 14:09:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR1dt-0005q1-0A; Wed, 24 Oct 2012 14:09:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR1dr-0005pw-Kh
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 14:09:07 +0000
Received: from [85.158.143.35:24529] by server-1.bemta-4.messagelabs.com id
	05/55-19134-286F7805; Wed, 24 Oct 2012 14:09:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1351087746!7744040!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5703 invoked from network); 24 Oct 2012 14:09:06 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-21.messagelabs.com with SMTP;
	24 Oct 2012 14:09:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 24 Oct 2012 15:09:21 +0100
Message-Id: <5088129F02000078000A406D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 24 Oct 2012 15:09:03 +0100
From: "Jan Beulich" 
To: "Ronny Hegewald" 
References: <201210212222.18396.ronny.hegewald@online.de>
In-Reply-To: <201210212222.18396.ronny.hegewald@online.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH V2] keep iommu disabled until iommu_setup()
 is called
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 22.10.12 at 00:22, Ronny Hegewald  wrote:
> The iommu is enabled by default when xen is booting and later disabled in 
> iommu_setup() when no iommu is present.
> 
> But under some circumstances iommu-code can be called before iommu_setup() is 
> 
> processed. If there is no iommu available xen crashes.
> 
> This can happen for example when panic(...) is called that got introduced 
> with
> patch "x86-64: detect processors subject to AMD erratum #121 and refuse to 
> boot." since xen 4.1.3 and results in the following stacktrace:
> 
>    find_iommu_for_device
>    amd_iommu_ioapic_update_ire
>    timer_interrupt
>    enable_8259_A_irq
>    do_IRQ
>    printk_start_of_line
>    acpi_os_printf
>    io_apic_write
>    __ioapic_write_entry
>    ioapic_write_entry
>    __clear_IO_APIC_pin
>    clear_IO_APIC
>    disable_IO_APIC
>    __stop_this_cpu
>    smp_send_stop
>    machine_restart
>    panic
>    tasklet_schedule_on_cpu
>    display_cacheinfo
>    init_amd
>    generic_identify
>    identify_cpu
>    _start_xen
>    _high_start
> 
> 
> This patch fixes this by keeping the iommu disabled until iommu_setup() is 
> entered. 
> 
> Signed-off-by: Ronny Hegewald@online.de 

As suspected, this breaks on Intel systems: When x2APIC is pre-
enabled by the BIOS, iommu_supports_eim() now fails, causing a
panic(). I'm checking whether this can be fixed, but the interactions
are rather subtle (and there appears to be more breakage there).

Jan

> --- xen/drivers/passthrough/iommu.c.org	2012-10-05 03:38:33.000000000 +0000
> +++ xen/drivers/passthrough/iommu.c	2012-10-21 21:07:37.000000000 +0000
> @@ -38,7 +38,8 @@
>   *   no-intremap                Disable VT-d Interrupt Remapping
>   */
>  custom_param("iommu", parse_iommu_param);
> -bool_t __read_mostly iommu_enabled = 1;
> +bool_t iommu_enable_default __initdata = 1;
> +bool_t __read_mostly iommu_enabled;
>  bool_t __read_mostly force_iommu;
>  bool_t __initdata iommu_dom0_strict;
>  bool_t __read_mostly iommu_verbose;
> @@ -61,7 +62,7 @@
>              *ss = '\0';
>  
>          if ( !parse_bool(s) )
> -            iommu_enabled = 0;
> +            iommu_enable_default = 0;
>          else if ( !strcmp(s, "force") || !strcmp(s, "required") )
>              force_iommu = 1;
>          else if ( !strcmp(s, "workaround_bios_bug") )
> @@ -316,7 +317,7 @@
>      if ( iommu_dom0_strict )
>          iommu_passthrough = 0;
>  
> -    if ( iommu_enabled )
> +    if ( iommu_enable_default )
>      {
>          rc = iommu_hardware_setup();
>          iommu_enabled = (rc == 0);
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 14:09:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 14:09:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR1dt-0005q1-0A; Wed, 24 Oct 2012 14:09:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR1dr-0005pw-Kh
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 14:09:07 +0000
Received: from [85.158.143.35:24529] by server-1.bemta-4.messagelabs.com id
	05/55-19134-286F7805; Wed, 24 Oct 2012 14:09:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1351087746!7744040!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5703 invoked from network); 24 Oct 2012 14:09:06 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-21.messagelabs.com with SMTP;
	24 Oct 2012 14:09:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 24 Oct 2012 15:09:21 +0100
Message-Id: <5088129F02000078000A406D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 24 Oct 2012 15:09:03 +0100
From: "Jan Beulich" 
To: "Ronny Hegewald" 
References: <201210212222.18396.ronny.hegewald@online.de>
In-Reply-To: <201210212222.18396.ronny.hegewald@online.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH V2] keep iommu disabled until iommu_setup()
 is called
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 22.10.12 at 00:22, Ronny Hegewald  wrote:
> The iommu is enabled by default when xen is booting and later disabled in 
> iommu_setup() when no iommu is present.
> 
> But under some circumstances iommu-code can be called before iommu_setup() is 
> 
> processed. If there is no iommu available xen crashes.
> 
> This can happen for example when panic(...) is called that got introduced 
> with
> patch "x86-64: detect processors subject to AMD erratum #121 and refuse to 
> boot." since xen 4.1.3 and results in the following stacktrace:
> 
>    find_iommu_for_device
>    amd_iommu_ioapic_update_ire
>    timer_interrupt
>    enable_8259_A_irq
>    do_IRQ
>    printk_start_of_line
>    acpi_os_printf
>    io_apic_write
>    __ioapic_write_entry
>    ioapic_write_entry
>    __clear_IO_APIC_pin
>    clear_IO_APIC
>    disable_IO_APIC
>    __stop_this_cpu
>    smp_send_stop
>    machine_restart
>    panic
>    tasklet_schedule_on_cpu
>    display_cacheinfo
>    init_amd
>    generic_identify
>    identify_cpu
>    _start_xen
>    _high_start
> 
> 
> This patch fixes this by keeping the iommu disabled until iommu_setup() is 
> entered. 
> 
> Signed-off-by: Ronny Hegewald@online.de 

As suspected, this breaks on Intel systems: When x2APIC is pre-
enabled by the BIOS, iommu_supports_eim() now fails, causing a
panic(). I'm checking whether this can be fixed, but the interactions
are rather subtle (and there appears to be more breakage there).

Jan

> --- xen/drivers/passthrough/iommu.c.org	2012-10-05 03:38:33.000000000 +0000
> +++ xen/drivers/passthrough/iommu.c	2012-10-21 21:07:37.000000000 +0000
> @@ -38,7 +38,8 @@
>   *   no-intremap                Disable VT-d Interrupt Remapping
>   */
>  custom_param("iommu", parse_iommu_param);
> -bool_t __read_mostly iommu_enabled = 1;
> +bool_t iommu_enable_default __initdata = 1;
> +bool_t __read_mostly iommu_enabled;
>  bool_t __read_mostly force_iommu;
>  bool_t __initdata iommu_dom0_strict;
>  bool_t __read_mostly iommu_verbose;
> @@ -61,7 +62,7 @@
>              *ss = '\0';
>  
>          if ( !parse_bool(s) )
> -            iommu_enabled = 0;
> +            iommu_enable_default = 0;
>          else if ( !strcmp(s, "force") || !strcmp(s, "required") )
>              force_iommu = 1;
>          else if ( !strcmp(s, "workaround_bios_bug") )
> @@ -316,7 +317,7 @@
>      if ( iommu_dom0_strict )
>          iommu_passthrough = 0;
>  
> -    if ( iommu_enabled )
> +    if ( iommu_enable_default )
>      {
>          rc = iommu_hardware_setup();
>          iommu_enabled = (rc == 0);
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 14:23:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 14:23:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR1rP-00061s-Gg; Wed, 24 Oct 2012 14:23:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR1rN-00061n-Ft
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 14:23:05 +0000
Received: from [85.158.139.211:44684] by server-9.bemta-5.messagelabs.com id
	6A/66-23053-8C9F7805; Wed, 24 Oct 2012 14:23:04 +0000
X-Env-Sender: davidxu06@gmail.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1351088582!23496030!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_10_20, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15267 invoked from network); 24 Oct 2012 14:23:03 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 14:23:03 -0000
Received: by mail-qa0-f45.google.com with SMTP id s11so2818901qaa.11
	for ; Wed, 24 Oct 2012 07:23:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=04coVZ/bsH5fs8Tkyj0NC9IIVhO4qjrp3U3Zw/oJtkY=;
	b=Ko1a4qxJL9pHR0cCl6iDT1+woW6eeYD+hESfKcZGJUVz/HfZIEXj9SXzOIAZ00oy2W
	qYnzs5uBUeLCqKL18lZvADXleFihtwNRmYHHl1g1cLLLak2A7+Ir5kpb8Za2TmF0dxC3
	eE8NgmvG8ZGrWJvot81lG9v28xD5GvdumHhHfY9A5yRuLc7CXfg03z9KDdUu+UJ7+6mf
	jFx05OV9AR8D62QR2ICnReyUWRL5tJYPQZoNVstO3sq3Cg5FdwqLRh9Lj0mS0n1B4FSt
	ERb20odbo15/IBOQYQ8OI3g4yzXmb/fp+BJtp/BT4hNcBc7s7lBzbh8yGm3tgCoK2c00
	NLHA==
MIME-Version: 1.0
Received: by 10.224.27.3 with SMTP id g3mr7246742qac.44.1351088582036; Wed, 24
	Oct 2012 07:23:02 -0700 (PDT)
Received: by 10.49.1.116 with HTTP; Wed, 24 Oct 2012 07:23:01 -0700 (PDT)
In-Reply-To: <1351086882.18035.45.camel@zakaz.uk.xensource.com>
References: 
	<1351070623.2237.120.camel@zakaz.uk.xensource.com>
	
	<1351086882.18035.45.camel@zakaz.uk.xensource.com>
Date: Wed, 24 Oct 2012 10:23:01 -0400
Message-ID: 
From: David Xu 
To: Ian Campbell 
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] xen_evtchn_do_upcall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============5049861882181544601=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5049861882181544601==
Content-Type: multipart/alternative; boundary=bcaec5196c6bfe0b7204ccced2c2

--bcaec5196c6bfe0b7204ccced2c2
Content-Type: text/plain; charset=ISO-8859-1

Hi Lan,

I am trying to improve the TCP/UDP performance in VM. Due the the vCPU
scheduling on a pCPU sharing platform, the TCP receiving delay will be
significant which hurt the TCP/UDP throughput. So I want to offload the
softIRQ context to another Idle pCPU which I call fast-tick CPU. The packet
receiving process is like this: IRQ routine can continue picking packet
from ring buffer and put it to TCP receive buffer ( receive_queue,
prequeue, backlog_queue ) in kernel no matter whether the user process on
another CPU shared with other VMs is running or not. Once the vCPU holding
the user process gets scheduled, user process will fetch all packets from
receive buffer in kernel, which can improve the throughput. This works well
for UDP unfortunately does not work for TCP currently.

I found those  xen_evtchn_do_upcall routines existing when irq context try
to get the spinlock on the socket (Of course, they may happen in other
paths). If this spinlock is held by process context, irq context has to
spin on it and can not put any packet to receive buffer in time. So I doubt
these   xen_evtchn_do_upcall routine are due to the synchronization between
process context and irq context. Since I run process context and irq
context on 2 different vCPU, when they try to get the spinlock on the same
socket there will be interrupts between 2 vCPU which are implemented by
event in Xen.

If there is any error in my description, please correct me. Thanks.

Regards,
Cong

2012/10/24 Ian Campbell 

> On Wed, 2012-10-24 at 14:39 +0100, David Xu wrote:
> > Hi Lan,
> >
> >
> > Thanks for your reply. I did a experiment as follows,
> > I assigned 2 vCPU to a VM, one vCPU (vCPU0) was pinned to a physical
> > CPU shared with several other VMs and the other vCPU (vCPU1) was
> > pinned to an idle physical CPU occupied by this VM only. Then in Guest
> > OS I run iperf server to measure its TCP receiving throughput. In
> > order to shrink the receiving delay caused by vCPU scheduling, I pin
> > the IRQ context of NIC to vCPU1 and run iperf server on the vCPU0.
> > This method works well for UDP, but does not work for TCP. I track the
> > involved function by ftrace and get the following results which
> > contains lots of xen_evtchn_do_upcall routine. What's the meaning of
> > this process (xen_evtchn_do_upcall => handle_irq_event =>
> > xennet_tx_buf_gc =>  gnttab_query_foreign_access)?
>
> Have you looked at the code for any of those functions?
>
> If you had done you'd find it is pretty obviously an interrupt being
> delivered to the network device and the associated work to satisfy that
> interrupt.
>
> It doesn't seem that surprising that an iperf test should involve lots
> of network interrupts.
>
> It's not entirely clear to me what you are expecting to find and/or what
> you are trying to prove.
>
> > When I run both process context of application ( e.g. iperf server )
> > and IRQ context on vCPU1 which is the ''fast" core, no
> > any xen_evtchn_do_upcall routine found.
>
> Perhaps on the fast core NAPI is able to kick in and therefore the NIC
> becomes polled instead of interrupt driven?
>
> Ian.
>
>

--bcaec5196c6bfe0b7204ccced2c2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Lan,

I am trying to improve the TCP/UDP performance i=
n VM. Due the the vCPU scheduling on a pCPU sharing platform, the TCP recei=
ving delay will be significant which hurt the TCP/UDP throughput. So I want=
 to offload the softIRQ context to another Idle pCPU which I call fast-tick=
 CPU. The packet receiving process is like this: IRQ routine can continue p=
icking packet from ring buffer and put it to TCP receive buffer ( receive_q=
ueue, prequeue, backlog_queue ) in kernel no matter whether the user proces=
s on another CPU shared with other VMs is running or not. Once the vCPU hol=
ding the user process gets scheduled, user process will fetch all packets f=
rom receive buffer in kernel, which can improve the throughput. This works =
well for UDP unfortunately does not work for TCP currently.



I found those=A0=A0xen_evtchn_do_upcall routines=A0exis=
ting when irq context try to get the spinlock on the socket (Of course, the=
y may happen in other paths). If this spinlock is held by process context, =
irq context has to spin on it and can not put any packet to receive buffer =
in time. So I doubt these=A0
=A0xen_evtchn_do_upcall routine=A0are due to the synchronization between pr=
ocess context and irq context. Since I run process context and irq context =
on 2 different vCPU, when they try to get the spinlock on the same socket t=
here will be interrupts between 2 vCPU which are implemented by event in Xe=
n.=A0



If there is any error in my description, please correct=
 me. Thanks.

Regards,
Cong

2012/10/24 Ian Campbell <Ian.Campbell@citrix.c=
om>


On Wed, 2012-10-24 at 14:3=
9 +0100, David Xu wrote:

> Hi Lan,

>

>

> Thanks for your reply. I did a experiment as follows,

> I assigned 2 vCPU to a VM, one vCPU (vCPU0) was pinned to a physical
> CPU shared with several other VMs and the other vCPU (vCPU1) was

> pinned to an idle physical CPU occupied by this VM only. Then in Guest=


> OS I run iperf server to measure its TCP receiving throughput. In

> order to shrink the receiving delay caused by vCPU scheduling, I pin
> the IRQ context of NIC to vCPU1 and run iperf server on the vCPU0.

> This method works well for UDP, but does not work for TCP. I track the=


> involved function by ftrace and get the following results which

> contains lots of xen_evtchn_do_upcall routine. What's the meaning =
of

> this process (xen_evtchn_do_upcall =3D> handle_irq_event =3D>
> xennet_tx_buf_gc =3D> =A0gnttab_query_foreign_access)?




Have you looked at the code for any of those functions?



If you had done you'd find it is pretty obviously an interrupt being
delivered to the network device and the associated work to satisfy that

interrupt.



It doesn't seem that surprising that an iperf test should involve lots<=
br>
of network interrupts.



It's not entirely clear to me what you are expecting to find and/or wha=
t

you are trying to prove.




> When I run both process context of application ( e.g. iperf server )
> and IRQ context on vCPU1 which is the ''fast" core, no
> any xen_evtchn_do_upcall routine found.




Perhaps on the fast core NAPI is able to kick in and therefore the NI=
C

becomes polled instead of interrupt driven?



Ian.







--bcaec5196c6bfe0b7204ccced2c2--


--===============5049861882181544601==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5049861882181544601==--


From xen-devel-bounces@lists.xen.org Wed Oct 24 14:23:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 14:23:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR1rP-00061s-Gg; Wed, 24 Oct 2012 14:23:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR1rN-00061n-Ft
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 14:23:05 +0000
Received: from [85.158.139.211:44684] by server-9.bemta-5.messagelabs.com id
	6A/66-23053-8C9F7805; Wed, 24 Oct 2012 14:23:04 +0000
X-Env-Sender: davidxu06@gmail.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1351088582!23496030!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_10_20, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15267 invoked from network); 24 Oct 2012 14:23:03 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 14:23:03 -0000
Received: by mail-qa0-f45.google.com with SMTP id s11so2818901qaa.11
	for ; Wed, 24 Oct 2012 07:23:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=04coVZ/bsH5fs8Tkyj0NC9IIVhO4qjrp3U3Zw/oJtkY=;
	b=Ko1a4qxJL9pHR0cCl6iDT1+woW6eeYD+hESfKcZGJUVz/HfZIEXj9SXzOIAZ00oy2W
	qYnzs5uBUeLCqKL18lZvADXleFihtwNRmYHHl1g1cLLLak2A7+Ir5kpb8Za2TmF0dxC3
	eE8NgmvG8ZGrWJvot81lG9v28xD5GvdumHhHfY9A5yRuLc7CXfg03z9KDdUu+UJ7+6mf
	jFx05OV9AR8D62QR2ICnReyUWRL5tJYPQZoNVstO3sq3Cg5FdwqLRh9Lj0mS0n1B4FSt
	ERb20odbo15/IBOQYQ8OI3g4yzXmb/fp+BJtp/BT4hNcBc7s7lBzbh8yGm3tgCoK2c00
	NLHA==
MIME-Version: 1.0
Received: by 10.224.27.3 with SMTP id g3mr7246742qac.44.1351088582036; Wed, 24
	Oct 2012 07:23:02 -0700 (PDT)
Received: by 10.49.1.116 with HTTP; Wed, 24 Oct 2012 07:23:01 -0700 (PDT)
In-Reply-To: <1351086882.18035.45.camel@zakaz.uk.xensource.com>
References: 
	<1351070623.2237.120.camel@zakaz.uk.xensource.com>
	
	<1351086882.18035.45.camel@zakaz.uk.xensource.com>
Date: Wed, 24 Oct 2012 10:23:01 -0400
Message-ID: 
From: David Xu 
To: Ian Campbell 
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] xen_evtchn_do_upcall
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============5049861882181544601=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5049861882181544601==
Content-Type: multipart/alternative; boundary=bcaec5196c6bfe0b7204ccced2c2

--bcaec5196c6bfe0b7204ccced2c2
Content-Type: text/plain; charset=ISO-8859-1

Hi Lan,

I am trying to improve the TCP/UDP performance in VM. Due the the vCPU
scheduling on a pCPU sharing platform, the TCP receiving delay will be
significant which hurt the TCP/UDP throughput. So I want to offload the
softIRQ context to another Idle pCPU which I call fast-tick CPU. The packet
receiving process is like this: IRQ routine can continue picking packet
from ring buffer and put it to TCP receive buffer ( receive_queue,
prequeue, backlog_queue ) in kernel no matter whether the user process on
another CPU shared with other VMs is running or not. Once the vCPU holding
the user process gets scheduled, user process will fetch all packets from
receive buffer in kernel, which can improve the throughput. This works well
for UDP unfortunately does not work for TCP currently.

I found those  xen_evtchn_do_upcall routines existing when irq context try
to get the spinlock on the socket (Of course, they may happen in other
paths). If this spinlock is held by process context, irq context has to
spin on it and can not put any packet to receive buffer in time. So I doubt
these   xen_evtchn_do_upcall routine are due to the synchronization between
process context and irq context. Since I run process context and irq
context on 2 different vCPU, when they try to get the spinlock on the same
socket there will be interrupts between 2 vCPU which are implemented by
event in Xen.

If there is any error in my description, please correct me. Thanks.

Regards,
Cong

2012/10/24 Ian Campbell 

> On Wed, 2012-10-24 at 14:39 +0100, David Xu wrote:
> > Hi Lan,
> >
> >
> > Thanks for your reply. I did a experiment as follows,
> > I assigned 2 vCPU to a VM, one vCPU (vCPU0) was pinned to a physical
> > CPU shared with several other VMs and the other vCPU (vCPU1) was
> > pinned to an idle physical CPU occupied by this VM only. Then in Guest
> > OS I run iperf server to measure its TCP receiving throughput. In
> > order to shrink the receiving delay caused by vCPU scheduling, I pin
> > the IRQ context of NIC to vCPU1 and run iperf server on the vCPU0.
> > This method works well for UDP, but does not work for TCP. I track the
> > involved function by ftrace and get the following results which
> > contains lots of xen_evtchn_do_upcall routine. What's the meaning of
> > this process (xen_evtchn_do_upcall => handle_irq_event =>
> > xennet_tx_buf_gc =>  gnttab_query_foreign_access)?
>
> Have you looked at the code for any of those functions?
>
> If you had done you'd find it is pretty obviously an interrupt being
> delivered to the network device and the associated work to satisfy that
> interrupt.
>
> It doesn't seem that surprising that an iperf test should involve lots
> of network interrupts.
>
> It's not entirely clear to me what you are expecting to find and/or what
> you are trying to prove.
>
> > When I run both process context of application ( e.g. iperf server )
> > and IRQ context on vCPU1 which is the ''fast" core, no
> > any xen_evtchn_do_upcall routine found.
>
> Perhaps on the fast core NAPI is able to kick in and therefore the NIC
> becomes polled instead of interrupt driven?
>
> Ian.
>
>

--bcaec5196c6bfe0b7204ccced2c2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Lan,

I am trying to improve the TCP/UDP performance i=
n VM. Due the the vCPU scheduling on a pCPU sharing platform, the TCP recei=
ving delay will be significant which hurt the TCP/UDP throughput. So I want=
 to offload the softIRQ context to another Idle pCPU which I call fast-tick=
 CPU. The packet receiving process is like this: IRQ routine can continue p=
icking packet from ring buffer and put it to TCP receive buffer ( receive_q=
ueue, prequeue, backlog_queue ) in kernel no matter whether the user proces=
s on another CPU shared with other VMs is running or not. Once the vCPU hol=
ding the user process gets scheduled, user process will fetch all packets f=
rom receive buffer in kernel, which can improve the throughput. This works =
well for UDP unfortunately does not work for TCP currently.



I found those=A0=A0xen_evtchn_do_upcall routines=A0exis=
ting when irq context try to get the spinlock on the socket (Of course, the=
y may happen in other paths). If this spinlock is held by process context, =
irq context has to spin on it and can not put any packet to receive buffer =
in time. So I doubt these=A0
=A0xen_evtchn_do_upcall routine=A0are due to the synchronization between pr=
ocess context and irq context. Since I run process context and irq context =
on 2 different vCPU, when they try to get the spinlock on the same socket t=
here will be interrupts between 2 vCPU which are implemented by event in Xe=
n.=A0



If there is any error in my description, please correct=
 me. Thanks.

Regards,
Cong

2012/10/24 Ian Campbell <Ian.Campbell@citrix.c=
om>


On Wed, 2012-10-24 at 14:3=
9 +0100, David Xu wrote:

> Hi Lan,

>

>

> Thanks for your reply. I did a experiment as follows,

> I assigned 2 vCPU to a VM, one vCPU (vCPU0) was pinned to a physical
> CPU shared with several other VMs and the other vCPU (vCPU1) was

> pinned to an idle physical CPU occupied by this VM only. Then in Guest=


> OS I run iperf server to measure its TCP receiving throughput. In

> order to shrink the receiving delay caused by vCPU scheduling, I pin
> the IRQ context of NIC to vCPU1 and run iperf server on the vCPU0.

> This method works well for UDP, but does not work for TCP. I track the=


> involved function by ftrace and get the following results which

> contains lots of xen_evtchn_do_upcall routine. What's the meaning =
of

> this process (xen_evtchn_do_upcall =3D> handle_irq_event =3D>
> xennet_tx_buf_gc =3D> =A0gnttab_query_foreign_access)?




Have you looked at the code for any of those functions?



If you had done you'd find it is pretty obviously an interrupt being
delivered to the network device and the associated work to satisfy that

interrupt.



It doesn't seem that surprising that an iperf test should involve lots<=
br>
of network interrupts.



It's not entirely clear to me what you are expecting to find and/or wha=
t

you are trying to prove.




> When I run both process context of application ( e.g. iperf server )
> and IRQ context on vCPU1 which is the ''fast" core, no
> any xen_evtchn_do_upcall routine found.




Perhaps on the fast core NAPI is able to kick in and therefore the NI=
C

becomes polled instead of interrupt driven?



Ian.







--bcaec5196c6bfe0b7204ccced2c2--


--===============5049861882181544601==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5049861882181544601==--


From xen-devel-bounces@lists.xen.org Wed Oct 24 14:30:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 14:30:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR1yJ-0006E7-I6; Wed, 24 Oct 2012 14:30:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR1yI-0006E2-Te
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 14:30:15 +0000
Received: from [85.158.137.99:60012] by server-5.bemta-3.messagelabs.com id
	B5/17-12440-67BF7805; Wed, 24 Oct 2012 14:30:14 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1351089012!12221593!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjIyNzc1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23709 invoked from network); 24 Oct 2012 14:30:13 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-6.tower-217.messagelabs.com with SMTP;
	24 Oct 2012 14:30:13 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 24 Oct 2012 07:30:11 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,640,1344236400"; d="scan'208";a="208478335"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by azsmga001.ch.intel.com with ESMTP; 24 Oct 2012 07:30:11 -0700
Received: from fmsmsx102.amr.corp.intel.com (10.19.9.53) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 24 Oct 2012 07:30:11 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX102.amr.corp.intel.com (10.19.9.53) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 24 Oct 2012 07:30:10 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.123]) with mapi id
	14.01.0355.002; Wed, 24 Oct 2012 22:30:09 +0800
From: "Liu, Jinsong" 
To: George Dunlap 
Thread-Topic: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration when
	vMCE occur
Thread-Index: AQHNsEjdaBRa8rOqkUOTeDJn2J5LNJfIhtkg
Date: Wed, 24 Oct 2012 14:30:09 +0000
Message-ID: 
References: 
	
	
	<50852EB6.4060705@eu.citrix.com>
In-Reply-To: <50852EB6.4060705@eu.citrix.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	Ian Jackson , Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration when vMCE
 occur
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap wrote:
> On 19/10/12 21:32, Liu, Jinsong wrote:
>>> Wouldn't your patch 5 be sufficient to deal with this case?  It
>>> seems like the broken page would get marked as such, and then get
>>> marked broken on the receiving side, wouldn't it?
>>> 
>>>   -George
>> Seems no, patch 4 is to handle the case mce occur during migration
>> --> under such case the broken page would mapped (at that time the
>> page is a good page) and copy to target; While patch 5 is to handle
>> the case mce occur beofre migration --> under such case the broken
>> page would not mapped and so would not copy to target.    
> 
> In the "during migration", there are actually two cases to consider:
> 1. The page breaks before the domain save code maps it.
> 2. The page breaks after the domain save code has mapped it once
> 
> Patch 5 will detect a broken page when it tries to map it, and send it
> as type "broken", without data.
> 
> So in the case of #1, it will be taken care of by patch 5 without any
> changes.

Yes, exactly.

> 
> In the case of #2, it seems like we could probably modify patch 5 to
> handle it.  If we mark a page dirty, then the domain save code will
> try to send it again.  When it tries to map it, it will discover that
> the page has been marked "broken", and will send it as a "broken"
> page, without data.  As long as the domain restore code marks the
> already-received page as "broken" when it receives this message, then
> everything should work as normal.
> 
> What do you think?
> 
>   -George

Yep, sounds perfect! will update & test later.

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 14:30:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 14:30:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR1yJ-0006E7-I6; Wed, 24 Oct 2012 14:30:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR1yI-0006E2-Te
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 14:30:15 +0000
Received: from [85.158.137.99:60012] by server-5.bemta-3.messagelabs.com id
	B5/17-12440-67BF7805; Wed, 24 Oct 2012 14:30:14 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1351089012!12221593!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjIyNzc1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23709 invoked from network); 24 Oct 2012 14:30:13 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-6.tower-217.messagelabs.com with SMTP;
	24 Oct 2012 14:30:13 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 24 Oct 2012 07:30:11 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,640,1344236400"; d="scan'208";a="208478335"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by azsmga001.ch.intel.com with ESMTP; 24 Oct 2012 07:30:11 -0700
Received: from fmsmsx102.amr.corp.intel.com (10.19.9.53) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 24 Oct 2012 07:30:11 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX102.amr.corp.intel.com (10.19.9.53) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 24 Oct 2012 07:30:10 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.123]) with mapi id
	14.01.0355.002; Wed, 24 Oct 2012 22:30:09 +0800
From: "Liu, Jinsong" 
To: George Dunlap 
Thread-Topic: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration when
	vMCE occur
Thread-Index: AQHNsEjdaBRa8rOqkUOTeDJn2J5LNJfIhtkg
Date: Wed, 24 Oct 2012 14:30:09 +0000
Message-ID: 
References: 
	
	
	<50852EB6.4060705@eu.citrix.com>
In-Reply-To: <50852EB6.4060705@eu.citrix.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	Ian Jackson , Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration when vMCE
 occur
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap wrote:
> On 19/10/12 21:32, Liu, Jinsong wrote:
>>> Wouldn't your patch 5 be sufficient to deal with this case?  It
>>> seems like the broken page would get marked as such, and then get
>>> marked broken on the receiving side, wouldn't it?
>>> 
>>>   -George
>> Seems no, patch 4 is to handle the case mce occur during migration
>> --> under such case the broken page would mapped (at that time the
>> page is a good page) and copy to target; While patch 5 is to handle
>> the case mce occur beofre migration --> under such case the broken
>> page would not mapped and so would not copy to target.    
> 
> In the "during migration", there are actually two cases to consider:
> 1. The page breaks before the domain save code maps it.
> 2. The page breaks after the domain save code has mapped it once
> 
> Patch 5 will detect a broken page when it tries to map it, and send it
> as type "broken", without data.
> 
> So in the case of #1, it will be taken care of by patch 5 without any
> changes.

Yes, exactly.

> 
> In the case of #2, it seems like we could probably modify patch 5 to
> handle it.  If we mark a page dirty, then the domain save code will
> try to send it again.  When it tries to map it, it will discover that
> the page has been marked "broken", and will send it as a "broken"
> page, without data.  As long as the domain restore code marks the
> already-received page as "broken" when it receives this message, then
> everything should work as normal.
> 
> What do you think?
> 
>   -George

Yep, sounds perfect! will update & test later.

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 14:34:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 14:34:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR22Y-0006O5-8o; Wed, 24 Oct 2012 14:34:38 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR22X-0006Nz-09
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 14:34:37 +0000
Received: from [193.109.254.147:40566] by server-8.bemta-14.messagelabs.com id
	DB/45-16549-C7CF7805; Wed, 24 Oct 2012 14:34:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1351089275!13890679!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22306 invoked from network); 24 Oct 2012 14:34:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 14:34:35 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15361276"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 14:34:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 24 Oct 2012 15:34:35 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TR22U-0004C9-VV;
	Wed, 24 Oct 2012 14:34:35 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TR22U-0008CZ-Ia;
	Wed, 24 Oct 2012 15:34:34 +0100
To: 
Message-ID: 
From: xen.org 
Date: Wed, 24 Oct 2012 15:34:34 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 14073: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14073 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14073/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13961
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13961
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13961
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13961

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 linux                9fc71703e9baa5b5174a72c053ae1ca736df2d42
baseline version:
 linux                40e6f9362555294cf1ce8abb1981b11d622e04d6

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=linux-3.0
+ revision=9fc71703e9baa5b5174a72c053ae1ca736df2d42
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push linux-3.0 9fc71703e9baa5b5174a72c053ae1ca736df2d42
+ branch=linux-3.0
+ revision=9fc71703e9baa5b5174a72c053ae1ca736df2d42
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=linux
+ xenbranch=xen-unstable
+ '[' xlinux = xlinux ']'
+ linuxbranch=linux-3.0
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.linux-3.0
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux-3.0
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree linux-3.0
+ case $1 in
+ : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
+ : linux-3.0.y
+ : linux-3.0.y
+ : git
+ : git
+ : git://xenbits.xen.org/linux-pvops.git
+ : xen@xenbits.xensource.com:git/linux-pvops.git
+ : tested/linux-3.0
+ : tested/linux-3.0
+ return 0
+ cd /export/home/osstest/repos/linux
+ git push xen@xenbits.xensource.com:git/linux-pvops.git 9fc71703e9baa5b5174a72c053ae1ca736df2d42:tested/linux-3.0
Counting objects: 1   
Counting objects: 338, done.
Compressing objects:   2% (1/43)   
Compressing objects:   4% (2/43)   
Compressing objects:   6% (3/43)   
Compressing objects:   9% (4/43)   
Compressing objects:  11% (5/43)   
Compressing objects:  13% (6/43)   
Compressing objects:  16% (7/43)   
Compressing objects:  18% (8/43)   
Compressing objects:  20% (9/43)   
Compressing objects:  23% (10/43)   
Compressing objects:  25% (11/43)   
Compressing objects:  27% (12/43)   
Compressing objects:  30% (13/43)   
Compressing objects:  32% (14/43)   
Compressing objects:  34% (15/43)   
Compressing objects:  37% (16/43)   
Compressing objects:  39% (17/43)   
Compressing objects:  41% (18/43)   
Compressing objects:  44% (19/43)   
Compressing objects:  46% (20/43)   
Compressing objects:  48% (21/43)   
Compressing objects:  51% (22/43)   
Compressing objects:  53% (23/43)   
Compressing objects:  55% (24/43)   
Compressing objects:  58% (25/43)   
Compressing objects:  60% (26/43)   
Compressing objects:  62% (27/43)   
Compressing objects:  65% (28/43)   
Compressing objects:  67% (29/43)   
Compressing objects:  69% (30/43)   
Compressing objects:  72% (31/43)   
Compressing objects:  74% (32/43)   
Compressing objects:  76% (33/43)   
Compressing objects:  79% (34/43)   
Compressing objects:  81% (35/43)   
Compressing objects:  83% (36/43)   
Compressing objects:  86% (37/43)   
Compressing objects:  88% (38/43)   
Compressing objects:  90% (39/43)   
Compressing objects:  93% (40/43)   
Compressing objects:  95% (41/43)   
Compressing objects:  97% (42/43)   
Compressing objects: 100% (43/43)   
Compressing objects: 100% (43/43), done.
Writing objects:   0% (1/237)   
Writing objects:   1% (3/237)   
Writing objects:   2% (5/237)   
Writing objects:   3% (8/237)   
Writing objects:   4% (10/237)   
Writing objects:   5% (12/237)   
Writing objects:   6% (15/237)   
Writing objects:   7% (17/237)   
Writing objects:   8% (19/237)   
Writing objects:   9% (22/237)   
Writing objects:  10% (24/237)   
Writing objects:  11% (27/237)   
Writing objects:  12% (29/237)   
Writing objects:  13% (31/237)   
Writing objects:  14% (34/237)   
Writing objects:  15% (36/237)   
Writing objects:  16% (38/237)   
Writing objects:  17% (41/237)   
Writing objects:  18% (43/237)   
Writing objects:  19% (46/237)   
Writing objects:  20% (48/237)   
Writing objects:  21% (50/237)   
Writing objects:  22% (53/237)   
Writing objects:  23% (55/237)   
Writing objects:  24% (57/237)   
Writing objects:  25% (60/237)   
Writing objects:  26% (62/237)   
Writing objects:  27% (64/237)   
Writing objects:  28% (67/237)   
Writing objects:  29% (69/237)   
Writing objects:  30% (72/237)   
Writing objects:  31% (74/237)   
Writing objects:  32% (76/237)   
Writing objects:  33% (79/237)   
Writing objects:  34% (81/237)   
Writing objects:  35% (83/237)   
Writing objects:  36% (86/237)   
Writing objects:  37% (88/237)   
Writing objects:  38% (91/237)   
Writing objects:  39% (93/237)   
Writing objects:  40% (95/237)   
Writing objects:  41% (98/237)   
Writing objects:  42% (100/237)   
Writing objects:  43% (102/237)   
Writing objects:  44% (105/237)   
Writing objects:  45% (107/237)   
Writing objects:  46% (110/237)   
Writing objects:  47% (112/237)   
Writing objects:  48% (114/237)   
Writing objects:  49% (117/237)   
Writing objects:  50% (119/237)   
Writing objects:  51% (121/237)   
Writing objects:  52% (124/237)   
Writing objects:  53% (126/237)   
Writing objects:  54% (128/237)   
Writing objects:  55% (131/237)   
Writing objects:  56% (134/237)   
Writing objects:  57% (136/237)   
Writing objects:  58% (138/237)   
Writing objects:  59% (140/237)   
Writing objects:  60% (143/237)   
Writing objects:  61% (145/237)   
Writing objects:  62% (147/237)   
Writing objects:  63% (150/237)   
Writing objects:  64% (152/237)   
Writing objects:  65% (155/237)   
Writing objects:  66% (157/237)   
Writing objects:  67% (159/237)   
Writing objects:  68% (162/237)   
Writing objects:  69% (164/237)   
Writing objects:  70% (166/237)   
Writing objects:  71% (169/237)   
Writing objects:  72% (171/237)   
Writing objects:  73% (174/237)   
Writing objects:  74% (176/237)   
Writing objects:  75% (178/237)   
Writing objects:  76% (181/237)   
Writing objects:  77% (183/237)   
Writing objects:  78% (185/237)   
Writing objects:  79% (188/237)   
Writing objects:  80% (190/237)   
Writing objects:  81% (192/237)   
Writing objects:  82% (195/237)   
Writing objects:  83% (197/237)   
Writing objects:  84% (200/237)   
Writing objects:  85% (202/237)   
Writing objects:  86% (204/237)   
Writing objects:  87% (207/237)   
Writing objects:  88% (209/237)   
Writing objects:  89% (211/237)   
Writing objects:  90% (214/237)   
Writing objects:  91% (216/237)   
Writing objects:  92% (219/237)   
Writing objects:  93% (221/237)   
Writing objects:  94% (223/237)   
Writing objects:  95% (226/237)   
Writing objects:  96% (228/237)   
Writing objects:  97% (230/237)   
Writing objects:  98% (233/237)   
Writing objects:  99% (235/237)   
Writing objects: 100% (237/237)   
Writing objects: 100% (237/237), 45.07 KiB, done.
Total 237 (delta 191), reused 237 (delta 191)
To xen@xenbits.xensource.com:git/linux-pvops.git
   40e6f93..9fc7170  9fc71703e9baa5b5174a72c053ae1ca736df2d42 -> tested/linux-3.0
+ exit 0

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 14:34:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 14:34:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR22Y-0006O5-8o; Wed, 24 Oct 2012 14:34:38 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR22X-0006Nz-09
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 14:34:37 +0000
Received: from [193.109.254.147:40566] by server-8.bemta-14.messagelabs.com id
	DB/45-16549-C7CF7805; Wed, 24 Oct 2012 14:34:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1351089275!13890679!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22306 invoked from network); 24 Oct 2012 14:34:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 14:34:35 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15361276"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 14:34:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 24 Oct 2012 15:34:35 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TR22U-0004C9-VV;
	Wed, 24 Oct 2012 14:34:35 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TR22U-0008CZ-Ia;
	Wed, 24 Oct 2012 15:34:34 +0100
To: 
Message-ID: 
From: xen.org 
Date: Wed, 24 Oct 2012 15:34:34 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 14073: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14073 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14073/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13961
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13961
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13961
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13961

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 linux                9fc71703e9baa5b5174a72c053ae1ca736df2d42
baseline version:
 linux                40e6f9362555294cf1ce8abb1981b11d622e04d6

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=linux-3.0
+ revision=9fc71703e9baa5b5174a72c053ae1ca736df2d42
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push linux-3.0 9fc71703e9baa5b5174a72c053ae1ca736df2d42
+ branch=linux-3.0
+ revision=9fc71703e9baa5b5174a72c053ae1ca736df2d42
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=linux
+ xenbranch=xen-unstable
+ '[' xlinux = xlinux ']'
+ linuxbranch=linux-3.0
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.linux-3.0
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux-3.0
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree linux-3.0
+ case $1 in
+ : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
+ : linux-3.0.y
+ : linux-3.0.y
+ : git
+ : git
+ : git://xenbits.xen.org/linux-pvops.git
+ : xen@xenbits.xensource.com:git/linux-pvops.git
+ : tested/linux-3.0
+ : tested/linux-3.0
+ return 0
+ cd /export/home/osstest/repos/linux
+ git push xen@xenbits.xensource.com:git/linux-pvops.git 9fc71703e9baa5b5174a72c053ae1ca736df2d42:tested/linux-3.0
Counting objects: 1   
Counting objects: 338, done.
Compressing objects:   2% (1/43)   
Compressing objects:   4% (2/43)   
Compressing objects:   6% (3/43)   
Compressing objects:   9% (4/43)   
Compressing objects:  11% (5/43)   
Compressing objects:  13% (6/43)   
Compressing objects:  16% (7/43)   
Compressing objects:  18% (8/43)   
Compressing objects:  20% (9/43)   
Compressing objects:  23% (10/43)   
Compressing objects:  25% (11/43)   
Compressing objects:  27% (12/43)   
Compressing objects:  30% (13/43)   
Compressing objects:  32% (14/43)   
Compressing objects:  34% (15/43)   
Compressing objects:  37% (16/43)   
Compressing objects:  39% (17/43)   
Compressing objects:  41% (18/43)   
Compressing objects:  44% (19/43)   
Compressing objects:  46% (20/43)   
Compressing objects:  48% (21/43)   
Compressing objects:  51% (22/43)   
Compressing objects:  53% (23/43)   
Compressing objects:  55% (24/43)   
Compressing objects:  58% (25/43)   
Compressing objects:  60% (26/43)   
Compressing objects:  62% (27/43)   
Compressing objects:  65% (28/43)   
Compressing objects:  67% (29/43)   
Compressing objects:  69% (30/43)   
Compressing objects:  72% (31/43)   
Compressing objects:  74% (32/43)   
Compressing objects:  76% (33/43)   
Compressing objects:  79% (34/43)   
Compressing objects:  81% (35/43)   
Compressing objects:  83% (36/43)   
Compressing objects:  86% (37/43)   
Compressing objects:  88% (38/43)   
Compressing objects:  90% (39/43)   
Compressing objects:  93% (40/43)   
Compressing objects:  95% (41/43)   
Compressing objects:  97% (42/43)   
Compressing objects: 100% (43/43)   
Compressing objects: 100% (43/43), done.
Writing objects:   0% (1/237)   
Writing objects:   1% (3/237)   
Writing objects:   2% (5/237)   
Writing objects:   3% (8/237)   
Writing objects:   4% (10/237)   
Writing objects:   5% (12/237)   
Writing objects:   6% (15/237)   
Writing objects:   7% (17/237)   
Writing objects:   8% (19/237)   
Writing objects:   9% (22/237)   
Writing objects:  10% (24/237)   
Writing objects:  11% (27/237)   
Writing objects:  12% (29/237)   
Writing objects:  13% (31/237)   
Writing objects:  14% (34/237)   
Writing objects:  15% (36/237)   
Writing objects:  16% (38/237)   
Writing objects:  17% (41/237)   
Writing objects:  18% (43/237)   
Writing objects:  19% (46/237)   
Writing objects:  20% (48/237)   
Writing objects:  21% (50/237)   
Writing objects:  22% (53/237)   
Writing objects:  23% (55/237)   
Writing objects:  24% (57/237)   
Writing objects:  25% (60/237)   
Writing objects:  26% (62/237)   
Writing objects:  27% (64/237)   
Writing objects:  28% (67/237)   
Writing objects:  29% (69/237)   
Writing objects:  30% (72/237)   
Writing objects:  31% (74/237)   
Writing objects:  32% (76/237)   
Writing objects:  33% (79/237)   
Writing objects:  34% (81/237)   
Writing objects:  35% (83/237)   
Writing objects:  36% (86/237)   
Writing objects:  37% (88/237)   
Writing objects:  38% (91/237)   
Writing objects:  39% (93/237)   
Writing objects:  40% (95/237)   
Writing objects:  41% (98/237)   
Writing objects:  42% (100/237)   
Writing objects:  43% (102/237)   
Writing objects:  44% (105/237)   
Writing objects:  45% (107/237)   
Writing objects:  46% (110/237)   
Writing objects:  47% (112/237)   
Writing objects:  48% (114/237)   
Writing objects:  49% (117/237)   
Writing objects:  50% (119/237)   
Writing objects:  51% (121/237)   
Writing objects:  52% (124/237)   
Writing objects:  53% (126/237)   
Writing objects:  54% (128/237)   
Writing objects:  55% (131/237)   
Writing objects:  56% (134/237)   
Writing objects:  57% (136/237)   
Writing objects:  58% (138/237)   
Writing objects:  59% (140/237)   
Writing objects:  60% (143/237)   
Writing objects:  61% (145/237)   
Writing objects:  62% (147/237)   
Writing objects:  63% (150/237)   
Writing objects:  64% (152/237)   
Writing objects:  65% (155/237)   
Writing objects:  66% (157/237)   
Writing objects:  67% (159/237)   
Writing objects:  68% (162/237)   
Writing objects:  69% (164/237)   
Writing objects:  70% (166/237)   
Writing objects:  71% (169/237)   
Writing objects:  72% (171/237)   
Writing objects:  73% (174/237)   
Writing objects:  74% (176/237)   
Writing objects:  75% (178/237)   
Writing objects:  76% (181/237)   
Writing objects:  77% (183/237)   
Writing objects:  78% (185/237)   
Writing objects:  79% (188/237)   
Writing objects:  80% (190/237)   
Writing objects:  81% (192/237)   
Writing objects:  82% (195/237)   
Writing objects:  83% (197/237)   
Writing objects:  84% (200/237)   
Writing objects:  85% (202/237)   
Writing objects:  86% (204/237)   
Writing objects:  87% (207/237)   
Writing objects:  88% (209/237)   
Writing objects:  89% (211/237)   
Writing objects:  90% (214/237)   
Writing objects:  91% (216/237)   
Writing objects:  92% (219/237)   
Writing objects:  93% (221/237)   
Writing objects:  94% (223/237)   
Writing objects:  95% (226/237)   
Writing objects:  96% (228/237)   
Writing objects:  97% (230/237)   
Writing objects:  98% (233/237)   
Writing objects:  99% (235/237)   
Writing objects: 100% (237/237)   
Writing objects: 100% (237/237), 45.07 KiB, done.
Total 237 (delta 191), reused 237 (delta 191)
To xen@xenbits.xensource.com:git/linux-pvops.git
   40e6f93..9fc7170  9fc71703e9baa5b5174a72c053ae1ca736df2d42 -> tested/linux-3.0
+ exit 0

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 14:54:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 14:54:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR2Lp-0007UP-3Z; Wed, 24 Oct 2012 14:54:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR2Ln-0007UH-Oe
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 14:54:31 +0000
Received: from [85.158.137.99:4952] by server-12.bemta-3.messagelabs.com id
	B9/1A-27853-62108805; Wed, 24 Oct 2012 14:54:30 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-217.messagelabs.com!1351090470!18084165!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDM4NDA=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDM4NDA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10094 invoked from network); 24 Oct 2012 14:54:30 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-7.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Oct 2012 14:54:30 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll387qFkE=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-086-014.pools.arcor-ip.net [84.57.86.14])
	by smtp.strato.de (joses mo19) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id C01e84o9OER4Hn ;
	Wed, 24 Oct 2012 16:54:23 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 1DAF618642; Wed, 24 Oct 2012 16:54:22 +0200 (CEST)
Date: Wed, 24 Oct 2012 16:54:21 +0200
From: Olaf Hering 
To: Jan Beulich 
Message-ID: <20121024145421.GA25635@aepfle.de>
References: <20120828124255.GA32452@aepfle.de>
	
	<20120831234222.GA22460@localhost.localdomain>
	<20121023194928.GA24083@aepfle.de>
	<5087B57302000078000A3CE3@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5087B57302000078000A3CE3@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: Konrad Rzeszutek Wilk , Keir Fraser ,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] fixed location of share info page in HVM guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 24, Jan Beulich wrote:

> >>> On 23.10.12 at 21:49, Olaf Hering  wrote:
> > The open question is when to switch from early_ioremap to
> > ioremap. Then the change to drivers/xen/platform-pci.c can be removed.
> 
> Wouldn't you be better of using
> early_set_fixmap(FIX_PARAVIRT_BOOTMAP, ...) anyway? If not,
> mm_init() (due to its calling of vmalloc_init()) would be the apparent
> boundary between using early and normal ioremaps.

set_fixmap seems to work. This patch works for me, with kexec and
save/restore.


Olaf

---
 arch/x86/include/asm/xen/hypervisor.h |  2 ++
 arch/x86/xen/enlighten.c              | 41 +++++++++++++++++++++++++----------
 arch/x86/xen/suspend.c                |  2 +-
 arch/x86/xen/xen-ops.h                |  2 +-
 4 files changed, 33 insertions(+), 14 deletions(-)

diff --git a/arch/x86/include/asm/xen/hypervisor.h b/arch/x86/include/asm/xen/hypervisor.h
index 66d0fff..e29a02b 100644
--- a/arch/x86/include/asm/xen/hypervisor.h
+++ b/arch/x86/include/asm/xen/hypervisor.h
@@ -34,6 +34,8 @@
 #define _ASM_X86_XEN_HYPERVISOR_H
 
 /* arch/i386/kernel/setup.c */
+#define HVM_SHARED_INFO_ADDR 0xFE700000UL
+
 extern struct shared_info *HYPERVISOR_shared_info;
 extern struct start_info *xen_start_info;
 
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index e3497f2..2cf40c9 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -103,7 +103,6 @@ struct shared_info xen_dummy_shared_info;
 
 void *xen_initial_gdt;
 
-RESERVE_BRK(shared_info_page_brk, PAGE_SIZE);
 __read_mostly int xen_have_vector_callback;
 EXPORT_SYMBOL_GPL(xen_have_vector_callback);
 
@@ -1497,38 +1496,56 @@ asmlinkage void __init xen_start_kernel(void)
 #endif
 }
 
-void __ref xen_hvm_init_shared_info(void)
+#ifdef CONFIG_XEN_PVHVM
+static struct shared_info *xen_hvm_shared_info;
+
+static void xen_hvm_connect_shared_info(unsigned long pfn)
 {
-	int cpu;
 	struct xen_add_to_physmap xatp;
-	static struct shared_info *shared_info_page = 0;
 
-	if (!shared_info_page)
-		shared_info_page = (struct shared_info *)
-			extend_brk(PAGE_SIZE, PAGE_SIZE);
 	xatp.domid = DOMID_SELF;
 	xatp.idx = 0;
 	xatp.space = XENMAPSPACE_shared_info;
-	xatp.gpfn = __pa(shared_info_page) >> PAGE_SHIFT;
+	xatp.gpfn = pfn;
 	if (HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp))
 		BUG();
 
-	HYPERVISOR_shared_info = (struct shared_info *)shared_info_page;
+}
+static void xen_hvm_set_shared_info(struct shared_info *sip)
+{
+	int cpu;
+
+	HYPERVISOR_shared_info = sip;
 
 	/* xen_vcpu is a pointer to the vcpu_info struct in the shared_info
 	 * page, we use it in the event channel upcall and in some pvclock
 	 * related functions. We don't need the vcpu_info placement
 	 * optimizations because we don't use any pv_mmu or pv_irq op on
 	 * HVM.
-	 * When xen_hvm_init_shared_info is run at boot time only vcpu 0 is
-	 * online but xen_hvm_init_shared_info is run at resume time too and
+	 * When xen_hvm_set_shared_info is run at boot time only vcpu 0 is
+	 * online but xen_hvm_set_shared_info is run at resume time too and
 	 * in that case multiple vcpus might be online. */
 	for_each_online_cpu(cpu) {
 		per_cpu(xen_vcpu, cpu) = &HYPERVISOR_shared_info->vcpu_info[cpu];
 	}
 }
 
-#ifdef CONFIG_XEN_PVHVM
+/* Reconnect the shared_info pfn to a (new) mfn */
+void xen_hvm_resume_shared_info(void)
+{
+	xen_hvm_connect_shared_info(HVM_SHARED_INFO_ADDR >> PAGE_SHIFT);
+}
+
+/* Obtain an address to the pfn in reserved area */
+static void __init xen_hvm_init_shared_info(void)
+{
+	set_fixmap(FIX_PARAVIRT_BOOTMAP, HVM_SHARED_INFO_ADDR);
+	xen_hvm_shared_info =
+		(struct shared_info *)fix_to_virt(FIX_PARAVIRT_BOOTMAP);
+	xen_hvm_connect_shared_info(HVM_SHARED_INFO_ADDR >> PAGE_SHIFT);
+	xen_hvm_set_shared_info(xen_hvm_shared_info);
+}
+
 static void __init init_hvm_pv_info(void)
 {
 	int major, minor;
diff --git a/arch/x86/xen/suspend.c b/arch/x86/xen/suspend.c
index 45329c8..ae8a00c 100644
--- a/arch/x86/xen/suspend.c
+++ b/arch/x86/xen/suspend.c
@@ -30,7 +30,7 @@ void xen_arch_hvm_post_suspend(int suspend_cancelled)
 {
 #ifdef CONFIG_XEN_PVHVM
 	int cpu;
-	xen_hvm_init_shared_info();
+	xen_hvm_resume_shared_info();
 	xen_callback_vector();
 	xen_unplug_emulated_devices();
 	if (xen_feature(XENFEAT_hvm_safe_pvclock)) {
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index a95b417..d2e73d1 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -40,7 +40,7 @@ void xen_enable_syscall(void);
 void xen_vcpu_restore(void);
 
 void xen_callback_vector(void);
-void xen_hvm_init_shared_info(void);
+void xen_hvm_resume_shared_info(void);
 void xen_unplug_emulated_devices(void);
 
 void __init xen_build_dynamic_phys_to_machine(void);
-- 
1.7.12.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 14:54:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 14:54:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR2Lp-0007UP-3Z; Wed, 24 Oct 2012 14:54:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR2Ln-0007UH-Oe
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 14:54:31 +0000
Received: from [85.158.137.99:4952] by server-12.bemta-3.messagelabs.com id
	B9/1A-27853-62108805; Wed, 24 Oct 2012 14:54:30 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-217.messagelabs.com!1351090470!18084165!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDM4NDA=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDM4NDA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10094 invoked from network); 24 Oct 2012 14:54:30 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-7.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Oct 2012 14:54:30 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll387qFkE=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-086-014.pools.arcor-ip.net [84.57.86.14])
	by smtp.strato.de (joses mo19) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id C01e84o9OER4Hn ;
	Wed, 24 Oct 2012 16:54:23 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 1DAF618642; Wed, 24 Oct 2012 16:54:22 +0200 (CEST)
Date: Wed, 24 Oct 2012 16:54:21 +0200
From: Olaf Hering 
To: Jan Beulich 
Message-ID: <20121024145421.GA25635@aepfle.de>
References: <20120828124255.GA32452@aepfle.de>
	
	<20120831234222.GA22460@localhost.localdomain>
	<20121023194928.GA24083@aepfle.de>
	<5087B57302000078000A3CE3@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5087B57302000078000A3CE3@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: Konrad Rzeszutek Wilk , Keir Fraser ,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] fixed location of share info page in HVM guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 24, Jan Beulich wrote:

> >>> On 23.10.12 at 21:49, Olaf Hering  wrote:
> > The open question is when to switch from early_ioremap to
> > ioremap. Then the change to drivers/xen/platform-pci.c can be removed.
> 
> Wouldn't you be better of using
> early_set_fixmap(FIX_PARAVIRT_BOOTMAP, ...) anyway? If not,
> mm_init() (due to its calling of vmalloc_init()) would be the apparent
> boundary between using early and normal ioremaps.

set_fixmap seems to work. This patch works for me, with kexec and
save/restore.


Olaf

---
 arch/x86/include/asm/xen/hypervisor.h |  2 ++
 arch/x86/xen/enlighten.c              | 41 +++++++++++++++++++++++++----------
 arch/x86/xen/suspend.c                |  2 +-
 arch/x86/xen/xen-ops.h                |  2 +-
 4 files changed, 33 insertions(+), 14 deletions(-)

diff --git a/arch/x86/include/asm/xen/hypervisor.h b/arch/x86/include/asm/xen/hypervisor.h
index 66d0fff..e29a02b 100644
--- a/arch/x86/include/asm/xen/hypervisor.h
+++ b/arch/x86/include/asm/xen/hypervisor.h
@@ -34,6 +34,8 @@
 #define _ASM_X86_XEN_HYPERVISOR_H
 
 /* arch/i386/kernel/setup.c */
+#define HVM_SHARED_INFO_ADDR 0xFE700000UL
+
 extern struct shared_info *HYPERVISOR_shared_info;
 extern struct start_info *xen_start_info;
 
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index e3497f2..2cf40c9 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -103,7 +103,6 @@ struct shared_info xen_dummy_shared_info;
 
 void *xen_initial_gdt;
 
-RESERVE_BRK(shared_info_page_brk, PAGE_SIZE);
 __read_mostly int xen_have_vector_callback;
 EXPORT_SYMBOL_GPL(xen_have_vector_callback);
 
@@ -1497,38 +1496,56 @@ asmlinkage void __init xen_start_kernel(void)
 #endif
 }
 
-void __ref xen_hvm_init_shared_info(void)
+#ifdef CONFIG_XEN_PVHVM
+static struct shared_info *xen_hvm_shared_info;
+
+static void xen_hvm_connect_shared_info(unsigned long pfn)
 {
-	int cpu;
 	struct xen_add_to_physmap xatp;
-	static struct shared_info *shared_info_page = 0;
 
-	if (!shared_info_page)
-		shared_info_page = (struct shared_info *)
-			extend_brk(PAGE_SIZE, PAGE_SIZE);
 	xatp.domid = DOMID_SELF;
 	xatp.idx = 0;
 	xatp.space = XENMAPSPACE_shared_info;
-	xatp.gpfn = __pa(shared_info_page) >> PAGE_SHIFT;
+	xatp.gpfn = pfn;
 	if (HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp))
 		BUG();
 
-	HYPERVISOR_shared_info = (struct shared_info *)shared_info_page;
+}
+static void xen_hvm_set_shared_info(struct shared_info *sip)
+{
+	int cpu;
+
+	HYPERVISOR_shared_info = sip;
 
 	/* xen_vcpu is a pointer to the vcpu_info struct in the shared_info
 	 * page, we use it in the event channel upcall and in some pvclock
 	 * related functions. We don't need the vcpu_info placement
 	 * optimizations because we don't use any pv_mmu or pv_irq op on
 	 * HVM.
-	 * When xen_hvm_init_shared_info is run at boot time only vcpu 0 is
-	 * online but xen_hvm_init_shared_info is run at resume time too and
+	 * When xen_hvm_set_shared_info is run at boot time only vcpu 0 is
+	 * online but xen_hvm_set_shared_info is run at resume time too and
 	 * in that case multiple vcpus might be online. */
 	for_each_online_cpu(cpu) {
 		per_cpu(xen_vcpu, cpu) = &HYPERVISOR_shared_info->vcpu_info[cpu];
 	}
 }
 
-#ifdef CONFIG_XEN_PVHVM
+/* Reconnect the shared_info pfn to a (new) mfn */
+void xen_hvm_resume_shared_info(void)
+{
+	xen_hvm_connect_shared_info(HVM_SHARED_INFO_ADDR >> PAGE_SHIFT);
+}
+
+/* Obtain an address to the pfn in reserved area */
+static void __init xen_hvm_init_shared_info(void)
+{
+	set_fixmap(FIX_PARAVIRT_BOOTMAP, HVM_SHARED_INFO_ADDR);
+	xen_hvm_shared_info =
+		(struct shared_info *)fix_to_virt(FIX_PARAVIRT_BOOTMAP);
+	xen_hvm_connect_shared_info(HVM_SHARED_INFO_ADDR >> PAGE_SHIFT);
+	xen_hvm_set_shared_info(xen_hvm_shared_info);
+}
+
 static void __init init_hvm_pv_info(void)
 {
 	int major, minor;
diff --git a/arch/x86/xen/suspend.c b/arch/x86/xen/suspend.c
index 45329c8..ae8a00c 100644
--- a/arch/x86/xen/suspend.c
+++ b/arch/x86/xen/suspend.c
@@ -30,7 +30,7 @@ void xen_arch_hvm_post_suspend(int suspend_cancelled)
 {
 #ifdef CONFIG_XEN_PVHVM
 	int cpu;
-	xen_hvm_init_shared_info();
+	xen_hvm_resume_shared_info();
 	xen_callback_vector();
 	xen_unplug_emulated_devices();
 	if (xen_feature(XENFEAT_hvm_safe_pvclock)) {
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index a95b417..d2e73d1 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -40,7 +40,7 @@ void xen_enable_syscall(void);
 void xen_vcpu_restore(void);
 
 void xen_callback_vector(void);
-void xen_hvm_init_shared_info(void);
+void xen_hvm_resume_shared_info(void);
 void xen_unplug_emulated_devices(void);
 
 void __init xen_build_dynamic_phys_to_machine(void);
-- 
1.7.12.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 15:04:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 15:04:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR2Up-0007ko-Av; Wed, 24 Oct 2012 15:03:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR2Un-0007kj-A2
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 15:03:49 +0000
Received: from [85.158.139.211:39902] by server-12.bemta-5.messagelabs.com id
	C2/65-26919-45308805; Wed, 24 Oct 2012 15:03:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1351091027!23559517!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19067 invoked from network); 24 Oct 2012 15:03:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 15:03:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15362075"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 15:03:46 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 24 Oct 2012 16:03:46 +0100
Date: Wed, 24 Oct 2012 16:03:17 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: 
Message-ID: 
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Tim Deegan , Ian Campbell ,
	Stefano Stabellini 
Subject: [Xen-devel] [PATCH 0/7] xen/arm: run on real hardware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,
this is a collection of fixes that I wrote trying to run Xen on a real
Versatile Express Cortex A15 machine.


Stefano Stabellini (7):
      xen/arm: fix rank calculation in vgic_vcpu_inject_irq
      xen/arm: setup the fixmap in head.S
      pl011: set baud and clock_hz to the right defaults for Versatile Express
      xen/arm: set the SMP bit in the ACTLR register
      xen/arm: wake up secondary cpus
      xen/arm: flush D-cache and I-cache when appropriate
      xen/arm: get the number of cpus from device tree

 xen/arch/arm/early_printk.c     |    5 +--
 xen/arch/arm/gic.c              |    4 +--
 xen/arch/arm/gic.h              |    2 +-
 xen/arch/arm/head.S             |   55 ++++++++++++++++++++++++++++----------
 xen/arch/arm/mm.c               |   16 ++++++++++-
 xen/arch/arm/mode_switch.S      |   31 ++++++++++++++++++++++
 xen/arch/arm/setup.c            |    5 +--
 xen/arch/arm/smpboot.c          |    2 +
 xen/arch/arm/vgic.c             |    2 +-
 xen/common/device_tree.c        |   20 ++++++++++++++
 xen/drivers/char/pl011.c        |    4 +-
 xen/include/asm-arm/page.h      |   14 ++++++++++
 xen/include/asm-arm/processor.h |   30 +++++++++++++++++++++
 xen/include/xen/device_tree.h   |    1 +
 14 files changed, 161 insertions(+), 30 deletions(-)

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 15:04:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 15:04:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR2Up-0007ko-Av; Wed, 24 Oct 2012 15:03:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR2Un-0007kj-A2
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 15:03:49 +0000
Received: from [85.158.139.211:39902] by server-12.bemta-5.messagelabs.com id
	C2/65-26919-45308805; Wed, 24 Oct 2012 15:03:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1351091027!23559517!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19067 invoked from network); 24 Oct 2012 15:03:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 15:03:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15362075"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 15:03:46 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 24 Oct 2012 16:03:46 +0100
Date: Wed, 24 Oct 2012 16:03:17 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: 
Message-ID: 
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Tim Deegan , Ian Campbell ,
	Stefano Stabellini 
Subject: [Xen-devel] [PATCH 0/7] xen/arm: run on real hardware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,
this is a collection of fixes that I wrote trying to run Xen on a real
Versatile Express Cortex A15 machine.


Stefano Stabellini (7):
      xen/arm: fix rank calculation in vgic_vcpu_inject_irq
      xen/arm: setup the fixmap in head.S
      pl011: set baud and clock_hz to the right defaults for Versatile Express
      xen/arm: set the SMP bit in the ACTLR register
      xen/arm: wake up secondary cpus
      xen/arm: flush D-cache and I-cache when appropriate
      xen/arm: get the number of cpus from device tree

 xen/arch/arm/early_printk.c     |    5 +--
 xen/arch/arm/gic.c              |    4 +--
 xen/arch/arm/gic.h              |    2 +-
 xen/arch/arm/head.S             |   55 ++++++++++++++++++++++++++++----------
 xen/arch/arm/mm.c               |   16 ++++++++++-
 xen/arch/arm/mode_switch.S      |   31 ++++++++++++++++++++++
 xen/arch/arm/setup.c            |    5 +--
 xen/arch/arm/smpboot.c          |    2 +
 xen/arch/arm/vgic.c             |    2 +-
 xen/common/device_tree.c        |   20 ++++++++++++++
 xen/drivers/char/pl011.c        |    4 +-
 xen/include/asm-arm/page.h      |   14 ++++++++++
 xen/include/asm-arm/processor.h |   30 +++++++++++++++++++++
 xen/include/xen/device_tree.h   |    1 +
 14 files changed, 161 insertions(+), 30 deletions(-)

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 15:04:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 15:04:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR2VC-0007nK-MD; Wed, 24 Oct 2012 15:04:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR2VB-0007mc-9A
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 15:04:13 +0000
Received: from [85.158.137.99:25909] by server-12.bemta-3.messagelabs.com id
	40/8B-27853-C6308805; Wed, 24 Oct 2012 15:04:12 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1351091049!18085833!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODQ2NzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12973 invoked from network); 24 Oct 2012 15:04:11 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 15:04:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; 
	d="scan'208,223";a="212308115"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 15:04:08 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 11:04:08 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TR2V0-0006G9-Tu;
	Wed, 24 Oct 2012 16:04:02 +0100
From: Stefano Stabellini 
To: 
Date: Wed, 24 Oct 2012 16:03:44 +0100
Message-ID: <1351091027-20740-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: 
References: 
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini 
Subject: [Xen-devel] [PATCH 4/7] xen/arm: set the SMP bit in the ACTLR
	register
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>From the Cortex A15 manual:

"Enables the processor to receive instruction cache, BTB, and TLB maintenance
operations from other processors"

...

"You must set this bit before enabling the caches and MMU, or
performing any cache and TLB maintenance operations. The only time
you must clear this bit is during a processor power-down sequence"

Signed-off-by: Stefano Stabellini 
---
 xen/arch/arm/head.S             |    6 ++++++
 xen/include/asm-arm/processor.h |   30 ++++++++++++++++++++++++++++++
 2 files changed, 36 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
index 3d01be0..c784f4d 100644
--- a/xen/arch/arm/head.S
+++ b/xen/arch/arm/head.S
@@ -148,6 +148,12 @@ skip_bss:
 
 	PRINT("- Setting up control registers -\r\n")
 	
+	/* XXX: Cortex A15 specific */
+	/* Set up the SMP bit in ACTLR */
+	mrc   CP32(r0, ACTLR)
+	orr   r0, r0, #(ACTLR_SMP) /* enable SMP bit*/
+	mcr   CP32(r0, ACTLR)
+
 	/* Set up memory attribute type tables */
 	ldr   r0, =MAIR0VAL
 	ldr   r1, =MAIR1VAL
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 3849b23..91a5836 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -34,6 +34,36 @@
 #define SCTLR_A         (1<<1)
 #define SCTLR_M         (1<<0)
 
+/* ACTLR Auxiliary Control Register */
+#define ACTLR_SNOOP_DELAYED      (1<<31)
+#define ACTLR_MAIN_CLOCK         (1<<30)
+#define ACTLR_NEON_CLOCK         (1<<29)
+#define ACTLR_NONCACHE           (1<<24)
+#define ACTLR_INORDER_REQ        (1<<23)
+#define ACTLR_INORDER_LOAD       (1<<22)
+#define ACTLR_L2_TLB_PREFETCH    (1<<21)
+#define ACTLR_L2_IPA_PA_CACHE    (1<<20)
+#define ACTLR_L2_CACHE           (1<<19)
+#define ACTLR_L2_PA_CACHE        (1<<18)
+#define ACTLR_TLB                (1<<17)
+#define ACTLR_STRONGY_ORDERED    (1<<16)
+#define ACTLR_INORDER            (1<<15)
+#define ACTLR_FORCE_LIM          (1<<14)
+#define ACTLR_CP_FLUSH           (1<<13)
+#define ACTLR_CP_PUSH            (1<<12)
+#define ACTLR_LIM                (1<<11)
+#define ACTLR_SER                (1<<10)
+#define ACTLR_OPT                (1<<9)
+#define ACTLR_WFI                (1<<8)
+#define ACTLR_WFE                (1<<7)
+#define ACTLR_SMP                (1<<6)
+#define ACTLR_PLD                (1<<5)
+#define ACTLR_IP                 (1<<4)
+#define ACTLR_MICRO_BTB          (1<<3)
+#define ACTLR_LOOP_ONE           (1<<2)
+#define ACTLR_LOOP_DISABLE       (1<<1)
+#define ACTLR_BTB                (1<<0)
+
 #define SCTLR_BASE        0x00c50078
 #define HSCTLR_BASE       0x30c51878
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 15:04:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 15:04:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR2VC-0007nK-MD; Wed, 24 Oct 2012 15:04:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR2VB-0007mc-9A
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 15:04:13 +0000
Received: from [85.158.137.99:25909] by server-12.bemta-3.messagelabs.com id
	40/8B-27853-C6308805; Wed, 24 Oct 2012 15:04:12 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1351091049!18085833!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODQ2NzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12973 invoked from network); 24 Oct 2012 15:04:11 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 15:04:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; 
	d="scan'208,223";a="212308115"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 15:04:08 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 11:04:08 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TR2V0-0006G9-Tu;
	Wed, 24 Oct 2012 16:04:02 +0100
From: Stefano Stabellini 
To: 
Date: Wed, 24 Oct 2012 16:03:44 +0100
Message-ID: <1351091027-20740-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: 
References: 
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini 
Subject: [Xen-devel] [PATCH 4/7] xen/arm: set the SMP bit in the ACTLR
	register
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>From the Cortex A15 manual:

"Enables the processor to receive instruction cache, BTB, and TLB maintenance
operations from other processors"

...

"You must set this bit before enabling the caches and MMU, or
performing any cache and TLB maintenance operations. The only time
you must clear this bit is during a processor power-down sequence"

Signed-off-by: Stefano Stabellini 
---
 xen/arch/arm/head.S             |    6 ++++++
 xen/include/asm-arm/processor.h |   30 ++++++++++++++++++++++++++++++
 2 files changed, 36 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
index 3d01be0..c784f4d 100644
--- a/xen/arch/arm/head.S
+++ b/xen/arch/arm/head.S
@@ -148,6 +148,12 @@ skip_bss:
 
 	PRINT("- Setting up control registers -\r\n")
 	
+	/* XXX: Cortex A15 specific */
+	/* Set up the SMP bit in ACTLR */
+	mrc   CP32(r0, ACTLR)
+	orr   r0, r0, #(ACTLR_SMP) /* enable SMP bit*/
+	mcr   CP32(r0, ACTLR)
+
 	/* Set up memory attribute type tables */
 	ldr   r0, =MAIR0VAL
 	ldr   r1, =MAIR1VAL
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 3849b23..91a5836 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -34,6 +34,36 @@
 #define SCTLR_A         (1<<1)
 #define SCTLR_M         (1<<0)
 
+/* ACTLR Auxiliary Control Register */
+#define ACTLR_SNOOP_DELAYED      (1<<31)
+#define ACTLR_MAIN_CLOCK         (1<<30)
+#define ACTLR_NEON_CLOCK         (1<<29)
+#define ACTLR_NONCACHE           (1<<24)
+#define ACTLR_INORDER_REQ        (1<<23)
+#define ACTLR_INORDER_LOAD       (1<<22)
+#define ACTLR_L2_TLB_PREFETCH    (1<<21)
+#define ACTLR_L2_IPA_PA_CACHE    (1<<20)
+#define ACTLR_L2_CACHE           (1<<19)
+#define ACTLR_L2_PA_CACHE        (1<<18)
+#define ACTLR_TLB                (1<<17)
+#define ACTLR_STRONGY_ORDERED    (1<<16)
+#define ACTLR_INORDER            (1<<15)
+#define ACTLR_FORCE_LIM          (1<<14)
+#define ACTLR_CP_FLUSH           (1<<13)
+#define ACTLR_CP_PUSH            (1<<12)
+#define ACTLR_LIM                (1<<11)
+#define ACTLR_SER                (1<<10)
+#define ACTLR_OPT                (1<<9)
+#define ACTLR_WFI                (1<<8)
+#define ACTLR_WFE                (1<<7)
+#define ACTLR_SMP                (1<<6)
+#define ACTLR_PLD                (1<<5)
+#define ACTLR_IP                 (1<<4)
+#define ACTLR_MICRO_BTB          (1<<3)
+#define ACTLR_LOOP_ONE           (1<<2)
+#define ACTLR_LOOP_DISABLE       (1<<1)
+#define ACTLR_BTB                (1<<0)
+
 #define SCTLR_BASE        0x00c50078
 #define HSCTLR_BASE       0x30c51878
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 15:04:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 15:04:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR2VA-0007mh-U2; Wed, 24 Oct 2012 15:04:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR2VA-0007mO-Aj
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 15:04:12 +0000
Received: from [85.158.137.99:19857] by server-4.bemta-3.messagelabs.com id
	C2/56-01405-B6308805; Wed, 24 Oct 2012 15:04:11 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1351091049!18085833!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODQ2NzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12920 invoked from network); 24 Oct 2012 15:04:10 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 15:04:10 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="212308113"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 15:04:08 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 11:04:08 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TR2V0-0006G9-Q5;
	Wed, 24 Oct 2012 16:04:02 +0100
From: Stefano Stabellini 
To: 
Date: Wed, 24 Oct 2012 16:03:41 +0100
Message-ID: <1351091027-20740-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: 
References: 
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini 
Subject: [Xen-devel] [PATCH 1/7] xen/arm: fix rank calculation in
	vgic_vcpu_inject_irq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Each rank holds 32 irqs, so we should divide by 32 rather than by 4.

Signed-off-by: Stefano Stabellini 
---
 xen/arch/arm/vgic.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 3c3983f..5eae61c 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -577,7 +577,7 @@ struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq)
 
 void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
 {
-    int idx = irq >> 2, byte = irq & 0x3;
+    int idx = irq / 32, byte = irq & 0x3;
     uint8_t priority;
     struct vgic_irq_rank *rank = vgic_irq_rank(v, 8, idx);
     struct pending_irq *iter, *n = irq_to_pending(v, irq);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 15:04:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 15:04:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR2VA-0007mh-U2; Wed, 24 Oct 2012 15:04:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR2VA-0007mO-Aj
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 15:04:12 +0000
Received: from [85.158.137.99:19857] by server-4.bemta-3.messagelabs.com id
	C2/56-01405-B6308805; Wed, 24 Oct 2012 15:04:11 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1351091049!18085833!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODQ2NzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12920 invoked from network); 24 Oct 2012 15:04:10 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 15:04:10 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="212308113"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 15:04:08 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 11:04:08 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TR2V0-0006G9-Q5;
	Wed, 24 Oct 2012 16:04:02 +0100
From: Stefano Stabellini 
To: 
Date: Wed, 24 Oct 2012 16:03:41 +0100
Message-ID: <1351091027-20740-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: 
References: 
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini 
Subject: [Xen-devel] [PATCH 1/7] xen/arm: fix rank calculation in
	vgic_vcpu_inject_irq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Each rank holds 32 irqs, so we should divide by 32 rather than by 4.

Signed-off-by: Stefano Stabellini 
---
 xen/arch/arm/vgic.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 3c3983f..5eae61c 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -577,7 +577,7 @@ struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq)
 
 void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
 {
-    int idx = irq >> 2, byte = irq & 0x3;
+    int idx = irq / 32, byte = irq & 0x3;
     uint8_t priority;
     struct vgic_irq_rank *rank = vgic_irq_rank(v, 8, idx);
     struct pending_irq *iter, *n = irq_to_pending(v, irq);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 15:04:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 15:04:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR2VC-0007nB-Aj; Wed, 24 Oct 2012 15:04:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR2VA-0007mT-Hr
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 15:04:12 +0000
Received: from [85.158.137.99:29568] by server-7.bemta-3.messagelabs.com id
	AC/78-06991-B6308805; Wed, 24 Oct 2012 15:04:11 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1351091049!18085833!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODQ2NzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12953 invoked from network); 24 Oct 2012 15:04:11 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 15:04:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="212308114"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 15:04:08 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 11:04:08 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TR2V0-0006G9-SG;
	Wed, 24 Oct 2012 16:04:02 +0100
From: Stefano Stabellini 
To: 
Date: Wed, 24 Oct 2012 16:03:43 +0100
Message-ID: <1351091027-20740-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: 
References: 
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini 
Subject: [Xen-devel] [PATCH 3/7] pl011: set baud and clock_hz to the right
	defaults for Versatile Express
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Stefano Stabellini 
---
 xen/drivers/char/pl011.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c
index 6af45aa..6ccb73a 100644
--- a/xen/drivers/char/pl011.c
+++ b/xen/drivers/char/pl011.c
@@ -241,8 +241,8 @@ void __init pl011_init(int index, unsigned long register_base_address)
 
     uart = &pl011_com[index];
 
-    uart->clock_hz  = 7372800;
-    uart->baud      = 115200;
+    uart->clock_hz  = 0x16e3600;
+    uart->baud      = 38400;
     uart->data_bits = 8;
     uart->parity    = PARITY_NONE;
     uart->stop_bits = 1;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 15:04:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 15:04:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR2VC-0007nB-Aj; Wed, 24 Oct 2012 15:04:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR2VA-0007mT-Hr
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 15:04:12 +0000
Received: from [85.158.137.99:29568] by server-7.bemta-3.messagelabs.com id
	AC/78-06991-B6308805; Wed, 24 Oct 2012 15:04:11 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1351091049!18085833!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODQ2NzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12953 invoked from network); 24 Oct 2012 15:04:11 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 15:04:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="212308114"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 15:04:08 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 11:04:08 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TR2V0-0006G9-SG;
	Wed, 24 Oct 2012 16:04:02 +0100
From: Stefano Stabellini 
To: 
Date: Wed, 24 Oct 2012 16:03:43 +0100
Message-ID: <1351091027-20740-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: 
References: 
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini 
Subject: [Xen-devel] [PATCH 3/7] pl011: set baud and clock_hz to the right
	defaults for Versatile Express
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Stefano Stabellini 
---
 xen/drivers/char/pl011.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c
index 6af45aa..6ccb73a 100644
--- a/xen/drivers/char/pl011.c
+++ b/xen/drivers/char/pl011.c
@@ -241,8 +241,8 @@ void __init pl011_init(int index, unsigned long register_base_address)
 
     uart = &pl011_com[index];
 
-    uart->clock_hz  = 7372800;
-    uart->baud      = 115200;
+    uart->clock_hz  = 0x16e3600;
+    uart->baud      = 38400;
     uart->data_bits = 8;
     uart->parity    = PARITY_NONE;
     uart->stop_bits = 1;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 15:04:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 15:04:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR2VE-0007ng-2L; Wed, 24 Oct 2012 15:04:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR2VB-0007mq-MR
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 15:04:13 +0000
Received: from [85.158.143.99:56248] by server-1.bemta-4.messagelabs.com id
	C1/27-19134-D6308805; Wed, 24 Oct 2012 15:04:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1351091051!34768275!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODQ2NzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14386 invoked from network); 24 Oct 2012 15:04:12 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 15:04:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="212308121"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 15:04:08 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 11:04:08 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TR2V1-0006G9-12;
	Wed, 24 Oct 2012 16:04:03 +0100
From: Stefano Stabellini 
To: 
Date: Wed, 24 Oct 2012 16:03:46 +0100
Message-ID: <1351091027-20740-6-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: 
References: 
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini 
Subject: [Xen-devel] [PATCH 6/7] xen/arm: flush D-cache and I-cache when
	appropriate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

- invalidate tlb after setting WXN;
- flush D-cache and I-cache after relocation;
- flush D-cache after writing to smp_up_cpu;
- flush TLB before changing HTTBR;
- flush I-cache after changing HTTBR;
- flush I-cache and branch predictor after writing Xen text ptes.

Signed-off-by: Stefano Stabellini 
---
 xen/arch/arm/head.S        |    9 +++++++++
 xen/arch/arm/mm.c          |   14 +++++++++++++-
 xen/arch/arm/smpboot.c     |    2 ++
 xen/include/asm-arm/page.h |   14 ++++++++++++++
 4 files changed, 38 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
index 39c4774..4c420ac 100644
--- a/xen/arch/arm/head.S
+++ b/xen/arch/arm/head.S
@@ -274,8 +274,15 @@ paging:
 	ldr   r4, =boot_httbr        /* VA of HTTBR value stashed by CPU 0 */
 	add   r4, r4, r10            /* PA of it */
 	ldrd  r4, r5, [r4]           /* Actual value */
+	dsb
+	mcr   CP32(r0, TLBIALLH)     /* Flush hypervisor TLB */
+	dsb
+	isb
 	mcrr  CP64(r4, r5, HTTBR)
+	dsb
+	isb
 	mcr   CP32(r0, TLBIALLH)     /* Flush hypervisor TLB */
+	mcr   CP32(r0, ICIALLU)      /* Flush I-cache */
 	mcr   CP32(r0, BPIALL)       /* Flush branch predictor */
 	dsb                          /* Ensure completion of TLB+BP flush */
 	isb
@@ -288,6 +295,8 @@ paging:
 	teq   r2, #0
 	bne   1b
 	dsb
+	mcr   CP32(r0, DCCMVAC)      /* flush D-Cache */
+	isb
 
 	/* Here, the non-boot CPUs must wait again -- they're now running on
 	 * the boot CPU's pagetables so it's safe for the boot CPU to
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index d0cd2c9..37e49c8 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -211,6 +211,7 @@ void __init setup_pagetables(unsigned long boot_phys_offset, paddr_t xen_paddr)
     unsigned long dest_va;
     lpae_t pte, *p;
     int i;
+    unsigned long cacheline_size = READ_CP32(CCSIDR);
 
     /* Map the destination in the boot misc area. */
     dest_va = BOOT_MISC_VIRT_START;
@@ -244,10 +245,18 @@ void __init setup_pagetables(unsigned long boot_phys_offset, paddr_t xen_paddr)
 
     /* Change pagetables to the copy in the relocated Xen */
     boot_httbr = (unsigned long) xen_pgtable + phys_offset;
+    flush_xen_dcache_va((unsigned long)&boot_httbr);
+    for ( i = 0; i < _end - _start; i += cacheline_size )
+        flush_xen_dcache_va(dest_va + i);
+    flush_xen_text_tlb();
+
     asm volatile (
+        "dsb;"                        /* Ensure visibility of HTTBR update */
         STORE_CP64(0, HTTBR)          /* Change translation base */
         "dsb;"                        /* Ensure visibility of HTTBR update */
+        "isb;"
         STORE_CP32(0, TLBIALLH)       /* Flush hypervisor TLB */
+        STORE_CP32(0, ICIALLU)        /* Flush I-cache */
         STORE_CP32(0, BPIALL)         /* Flush branch predictor */
         "dsb;"                        /* Ensure completion of TLB+BP flush */
         "isb;"
@@ -292,10 +301,11 @@ void __init setup_pagetables(unsigned long boot_phys_offset, paddr_t xen_paddr)
     pte.pt.table = 1;
     write_pte(xen_second + second_linear_offset(XEN_VIRT_START), pte);
     /* Have changed a mapping used for .text. Flush everything for safety. */
-    flush_xen_text_tlb();
 
     /* From now on, no mapping may be both writable and executable. */
     WRITE_CP32(READ_CP32(HSCTLR) | SCTLR_WXN, HSCTLR);
+    isb();
+    flush_xen_text_tlb();
 }
 
 /* MMU setup for secondary CPUS (which already have paging enabled) */
@@ -303,6 +313,8 @@ void __cpuinit mmu_init_secondary_cpu(void)
 {
     /* From now on, no mapping may be both writable and executable. */
     WRITE_CP32(READ_CP32(HSCTLR) | SCTLR_WXN, HSCTLR);
+    isb();
+    flush_xen_text_tlb();
 }
 
 /* Create Xen's mappings of memory.
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index c0750c0..767e553 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -105,6 +105,7 @@ make_cpus_ready(unsigned int max_cpus, unsigned long boot_phys_offset)
         /* Tell the next CPU to get ready */
         /* TODO: handle boards where CPUIDs are not contiguous */
         *gate = i;
+        flush_xen_dcache_va((unsigned long)gate);
         asm volatile("dsb; isb; sev");
         /* And wait for it to respond */
         while ( ready_cpus < i )
@@ -201,6 +202,7 @@ int __cpu_up(unsigned int cpu)
     /* Unblock the CPU.  It should be waiting in the loop in head.S
      * for an event to arrive when smp_up_cpu matches its cpuid. */
     smp_up_cpu = cpu;
+    flush_xen_dcache_va((unsigned long)&smp_up_cpu);
     asm volatile("dsb; isb; sev");
 
     while ( !cpu_online(cpu) )
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 9511c45..7d70d8c 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -232,13 +232,26 @@ static inline lpae_t mfn_to_p2m_entry(unsigned long mfn, unsigned int mattr)
 static inline void write_pte(lpae_t *p, lpae_t pte)
 {
     asm volatile (
+        "dsb;"
         /* Safely write the entry (STRD is atomic on CPUs that support LPAE) */
         "strd %0, %H0, [%1];"
+        "dsb;"
         /* Push this cacheline to the PoC so the rest of the system sees it. */
         STORE_CP32(1, DCCMVAC)
+        "isb;"
         : : "r" (pte.bits), "r" (p) : "memory");
 }
 
+static inline void flush_xen_dcache_va(unsigned long va)
+{
+    register unsigned long r0 asm ("r0") = va;
+    asm volatile (
+        "dsb;"
+        STORE_CP32(0, DCCMVAC)
+        "isb;"
+        : : "r" (r0) : "memory");
+}
+
 /*
  * Flush all hypervisor mappings from the TLB and branch predictor.
  * This is needed after changing Xen code mappings. 
@@ -249,6 +262,7 @@ static inline void flush_xen_text_tlb(void)
     asm volatile (
         "dsb;"                        /* Ensure visibility of PTE writes */
         STORE_CP32(0, TLBIALLH)       /* Flush hypervisor TLB */
+        STORE_CP32(0, ICIALLU)        /* Flush I-cache */
         STORE_CP32(0, BPIALL)         /* Flush branch predictor */
         "dsb;"                        /* Ensure completion of TLB+BP flush */
         "isb;"
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 15:04:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 15:04:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR2VE-0007ng-2L; Wed, 24 Oct 2012 15:04:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR2VB-0007mq-MR
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 15:04:13 +0000
Received: from [85.158.143.99:56248] by server-1.bemta-4.messagelabs.com id
	C1/27-19134-D6308805; Wed, 24 Oct 2012 15:04:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1351091051!34768275!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODQ2NzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14386 invoked from network); 24 Oct 2012 15:04:12 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 15:04:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="212308121"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 15:04:08 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 11:04:08 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TR2V1-0006G9-12;
	Wed, 24 Oct 2012 16:04:03 +0100
From: Stefano Stabellini 
To: 
Date: Wed, 24 Oct 2012 16:03:46 +0100
Message-ID: <1351091027-20740-6-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: 
References: 
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini 
Subject: [Xen-devel] [PATCH 6/7] xen/arm: flush D-cache and I-cache when
	appropriate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

- invalidate tlb after setting WXN;
- flush D-cache and I-cache after relocation;
- flush D-cache after writing to smp_up_cpu;
- flush TLB before changing HTTBR;
- flush I-cache after changing HTTBR;
- flush I-cache and branch predictor after writing Xen text ptes.

Signed-off-by: Stefano Stabellini 
---
 xen/arch/arm/head.S        |    9 +++++++++
 xen/arch/arm/mm.c          |   14 +++++++++++++-
 xen/arch/arm/smpboot.c     |    2 ++
 xen/include/asm-arm/page.h |   14 ++++++++++++++
 4 files changed, 38 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
index 39c4774..4c420ac 100644
--- a/xen/arch/arm/head.S
+++ b/xen/arch/arm/head.S
@@ -274,8 +274,15 @@ paging:
 	ldr   r4, =boot_httbr        /* VA of HTTBR value stashed by CPU 0 */
 	add   r4, r4, r10            /* PA of it */
 	ldrd  r4, r5, [r4]           /* Actual value */
+	dsb
+	mcr   CP32(r0, TLBIALLH)     /* Flush hypervisor TLB */
+	dsb
+	isb
 	mcrr  CP64(r4, r5, HTTBR)
+	dsb
+	isb
 	mcr   CP32(r0, TLBIALLH)     /* Flush hypervisor TLB */
+	mcr   CP32(r0, ICIALLU)      /* Flush I-cache */
 	mcr   CP32(r0, BPIALL)       /* Flush branch predictor */
 	dsb                          /* Ensure completion of TLB+BP flush */
 	isb
@@ -288,6 +295,8 @@ paging:
 	teq   r2, #0
 	bne   1b
 	dsb
+	mcr   CP32(r0, DCCMVAC)      /* flush D-Cache */
+	isb
 
 	/* Here, the non-boot CPUs must wait again -- they're now running on
 	 * the boot CPU's pagetables so it's safe for the boot CPU to
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index d0cd2c9..37e49c8 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -211,6 +211,7 @@ void __init setup_pagetables(unsigned long boot_phys_offset, paddr_t xen_paddr)
     unsigned long dest_va;
     lpae_t pte, *p;
     int i;
+    unsigned long cacheline_size = READ_CP32(CCSIDR);
 
     /* Map the destination in the boot misc area. */
     dest_va = BOOT_MISC_VIRT_START;
@@ -244,10 +245,18 @@ void __init setup_pagetables(unsigned long boot_phys_offset, paddr_t xen_paddr)
 
     /* Change pagetables to the copy in the relocated Xen */
     boot_httbr = (unsigned long) xen_pgtable + phys_offset;
+    flush_xen_dcache_va((unsigned long)&boot_httbr);
+    for ( i = 0; i < _end - _start; i += cacheline_size )
+        flush_xen_dcache_va(dest_va + i);
+    flush_xen_text_tlb();
+
     asm volatile (
+        "dsb;"                        /* Ensure visibility of HTTBR update */
         STORE_CP64(0, HTTBR)          /* Change translation base */
         "dsb;"                        /* Ensure visibility of HTTBR update */
+        "isb;"
         STORE_CP32(0, TLBIALLH)       /* Flush hypervisor TLB */
+        STORE_CP32(0, ICIALLU)        /* Flush I-cache */
         STORE_CP32(0, BPIALL)         /* Flush branch predictor */
         "dsb;"                        /* Ensure completion of TLB+BP flush */
         "isb;"
@@ -292,10 +301,11 @@ void __init setup_pagetables(unsigned long boot_phys_offset, paddr_t xen_paddr)
     pte.pt.table = 1;
     write_pte(xen_second + second_linear_offset(XEN_VIRT_START), pte);
     /* Have changed a mapping used for .text. Flush everything for safety. */
-    flush_xen_text_tlb();
 
     /* From now on, no mapping may be both writable and executable. */
     WRITE_CP32(READ_CP32(HSCTLR) | SCTLR_WXN, HSCTLR);
+    isb();
+    flush_xen_text_tlb();
 }
 
 /* MMU setup for secondary CPUS (which already have paging enabled) */
@@ -303,6 +313,8 @@ void __cpuinit mmu_init_secondary_cpu(void)
 {
     /* From now on, no mapping may be both writable and executable. */
     WRITE_CP32(READ_CP32(HSCTLR) | SCTLR_WXN, HSCTLR);
+    isb();
+    flush_xen_text_tlb();
 }
 
 /* Create Xen's mappings of memory.
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index c0750c0..767e553 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -105,6 +105,7 @@ make_cpus_ready(unsigned int max_cpus, unsigned long boot_phys_offset)
         /* Tell the next CPU to get ready */
         /* TODO: handle boards where CPUIDs are not contiguous */
         *gate = i;
+        flush_xen_dcache_va((unsigned long)gate);
         asm volatile("dsb; isb; sev");
         /* And wait for it to respond */
         while ( ready_cpus < i )
@@ -201,6 +202,7 @@ int __cpu_up(unsigned int cpu)
     /* Unblock the CPU.  It should be waiting in the loop in head.S
      * for an event to arrive when smp_up_cpu matches its cpuid. */
     smp_up_cpu = cpu;
+    flush_xen_dcache_va((unsigned long)&smp_up_cpu);
     asm volatile("dsb; isb; sev");
 
     while ( !cpu_online(cpu) )
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 9511c45..7d70d8c 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -232,13 +232,26 @@ static inline lpae_t mfn_to_p2m_entry(unsigned long mfn, unsigned int mattr)
 static inline void write_pte(lpae_t *p, lpae_t pte)
 {
     asm volatile (
+        "dsb;"
         /* Safely write the entry (STRD is atomic on CPUs that support LPAE) */
         "strd %0, %H0, [%1];"
+        "dsb;"
         /* Push this cacheline to the PoC so the rest of the system sees it. */
         STORE_CP32(1, DCCMVAC)
+        "isb;"
         : : "r" (pte.bits), "r" (p) : "memory");
 }
 
+static inline void flush_xen_dcache_va(unsigned long va)
+{
+    register unsigned long r0 asm ("r0") = va;
+    asm volatile (
+        "dsb;"
+        STORE_CP32(0, DCCMVAC)
+        "isb;"
+        : : "r" (r0) : "memory");
+}
+
 /*
  * Flush all hypervisor mappings from the TLB and branch predictor.
  * This is needed after changing Xen code mappings. 
@@ -249,6 +262,7 @@ static inline void flush_xen_text_tlb(void)
     asm volatile (
         "dsb;"                        /* Ensure visibility of PTE writes */
         STORE_CP32(0, TLBIALLH)       /* Flush hypervisor TLB */
+        STORE_CP32(0, ICIALLU)        /* Flush I-cache */
         STORE_CP32(0, BPIALL)         /* Flush branch predictor */
         "dsb;"                        /* Ensure completion of TLB+BP flush */
         "isb;"
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 15:04:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 15:04:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR2VR-0007ru-TT; Wed, 24 Oct 2012 15:04:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR2VQ-0007qq-5J
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 15:04:28 +0000
Received: from [85.158.139.83:55357] by server-6.bemta-5.messagelabs.com id
	C6/F3-32589-B7308805; Wed, 24 Oct 2012 15:04:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1351091064!32027678!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzg3MDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13955 invoked from network); 24 Oct 2012 15:04:26 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 15:04:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="42287025"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 15:04:08 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 11:04:08 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TR2V0-0006G9-Ro;
	Wed, 24 Oct 2012 16:04:02 +0100
From: Stefano Stabellini 
To: 
Date: Wed, 24 Oct 2012 16:03:42 +0100
Message-ID: <1351091027-20740-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: 
References: 
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini 
Subject: [Xen-devel] [PATCH 2/7] xen/arm: setup the fixmap in head.S
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Setup the fixmap mapping directly in head.S rather than having a
temporary mapping only to re-do it later in C.

Signed-off-by: Stefano Stabellini 
---
 xen/arch/arm/early_printk.c |    5 ++---
 xen/arch/arm/head.S         |   32 +++++++++++++++++++-------------
 xen/arch/arm/mm.c           |    2 +-
 xen/arch/arm/setup.c        |    2 --
 4 files changed, 22 insertions(+), 19 deletions(-)

diff --git a/xen/arch/arm/early_printk.c b/xen/arch/arm/early_printk.c
index 3e51252..bdf4c0e 100644
--- a/xen/arch/arm/early_printk.c
+++ b/xen/arch/arm/early_printk.c
@@ -17,12 +17,11 @@
 
 #ifdef EARLY_UART_ADDRESS
 
-static void __init early_putch(char c)
+void __init early_putch(char c)
 {
     volatile uint32_t *r;
 
-    r = (uint32_t *)((EARLY_UART_ADDRESS & 0x001fffff)
-                     + XEN_VIRT_START + (1 << 21));
+    r = (uint32_t *)(XEN_VIRT_START + (1 << 21));
 
     /* XXX: assuming a PL011 UART. */
     while(*(r + 0x6) & 0x8)
diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
index 9fdeda7..3d01be0 100644
--- a/xen/arch/arm/head.S
+++ b/xen/arch/arm/head.S
@@ -24,6 +24,7 @@
 #define PT_PT  0xe7f /* nG=1, AF=1, SH=10, AP=01, NS=1, ATTR=111, T=1, P=1 */
 #define PT_MEM 0xe7d /* nG=1, AF=1, SH=10, AP=01, NS=1, ATTR=111, T=0, P=1 */
 #define PT_DEV 0xe71 /* nG=1, AF=1, SH=10, AP=01, NS=1, ATTR=100, T=0, P=1 */
+#define PT_DEV_L3 0xe73 /* lev3: nG=1, AF=1, SH=10, AP=01, NS=1, ATTR=100, T=1, P=1 */
 
 #define PT_UPPER(x) (PT_##x & 0xf00)
 #define PT_LOWER(x) (PT_##x & 0x0ff)
@@ -183,6 +184,16 @@ skip_bss:
 	teq   r12, #0
 	bne   pt_ready
 	
+	/* console fixmap */
+	ldr   r1, =xen_fixmap
+	add   r1, r1, r10            /* r1 := paddr (xen_fixmap) */
+	mov   r3, #0
+	lsr   r2, r11, #12
+	lsl   r2, r2, #12            /* 4K aligned paddr of UART */
+	orr   r2, r2, #PT_UPPER(DEV_L3)
+	orr   r2, r2, #PT_LOWER(DEV_L3) /* r2:r3 := 4K dev map including UART */
+	strd  r2, r3, [r1, #0]       /* Map it in the first fixmap's slot */
+	
 	/* Build the baseline idle pagetable's first-level entries */
 	ldr   r1, =xen_second
 	add   r1, r1, r10            /* r1 := paddr (xen_second) */
@@ -205,12 +216,13 @@ skip_bss:
 	ldr   r4, =start
 	lsr   r4, #18                /* Slot for vaddr(start) */
 	strd  r2, r3, [r1, r4]       /* Map Xen there too */
+
 #ifdef EARLY_UART_ADDRESS
-	ldr   r3, =(1<<(54-32))      /* NS for device mapping */
-	lsr   r2, r11, #21
-	lsl   r2, r2, #21            /* 2MB-aligned paddr of UART */
-	orr   r2, r2, #PT_UPPER(DEV)
-	orr   r2, r2, #PT_LOWER(DEV) /* r2:r3 := 2MB dev map including UART */
+	/* xen_fixmap pagetable */
+	ldr r2, =xen_fixmap
+	add r2, r2, r10
+	orr   r2, r2, #PT_UPPER(PT)
+	orr   r2, r2, #PT_LOWER(PT) /* r2:r3 := paddr (xen_fixmap) */
 	add   r4, r4, #8
 	strd  r2, r3, [r1, r4]       /* Map it in the fixmap's slot */
 #else
@@ -236,13 +248,9 @@ pt_ready:
 	mov   pc, r1                 /* Get a proper vaddr into PC */
 paging:
 
+	
 #ifdef EARLY_UART_ADDRESS
-	/* Recover the UART address in the new address space. */
-	lsl   r11, #11
-	lsr   r11, #11               /* UART base's offset from 2MB base */
-	adr   r0, start
-	add   r0, r0, #0x200000      /* vaddr of the fixmap's 2MB slot */
-	add   r11, r11, r0           /* r11 := vaddr (UART base address) */
+	ldr r11, =FIXMAP_ADDR(FIXMAP_CONSOLE)
 #endif
 
 	PRINT("- Ready -\r\n")
@@ -261,8 +269,6 @@ paging:
 	mcr   CP32(r0, BPIALL)       /* Flush branch predictor */
 	dsb                          /* Ensure completion of TLB+BP flush */
 	isb
- 	/* Now, the UART is in its proper fixmap address */
-	ldrne r11, =FIXMAP_ADDR(FIXMAP_CONSOLE)
 
 	/* Non-boot CPUs report that they've got this far */
 	ldr   r0, =ready_cpus
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index b0068d2..d0cd2c9 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -37,7 +37,7 @@ struct domain *dom_xen, *dom_io;
 /* Static start-of-day pagetables that we use before the allocators are up */
 lpae_t xen_pgtable[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
 lpae_t xen_second[LPAE_ENTRIES*4] __attribute__((__aligned__(4096*4)));
-static lpae_t xen_fixmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
+lpae_t xen_fixmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
 static lpae_t xen_xenmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
 
 /* Non-boot CPUs use this to find the correct pagetables. */
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 7568968..6fbcb81 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -194,9 +194,7 @@ void __init start_xen(unsigned long boot_phys_offset,
     setup_pagetables(boot_phys_offset, get_xen_paddr());
 
 #ifdef EARLY_UART_ADDRESS
-    /* Map the UART */
     /* TODO Need to get device tree or command line for UART address */
-    set_fixmap(FIXMAP_CONSOLE, EARLY_UART_ADDRESS >> PAGE_SHIFT, DEV_SHARED);
     pl011_init(0, FIXMAP_ADDR(FIXMAP_CONSOLE));
     console_init_preirq();
 #endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 15:04:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 15:04:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR2VR-0007ru-TT; Wed, 24 Oct 2012 15:04:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR2VQ-0007qq-5J
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 15:04:28 +0000
Received: from [85.158.139.83:55357] by server-6.bemta-5.messagelabs.com id
	C6/F3-32589-B7308805; Wed, 24 Oct 2012 15:04:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1351091064!32027678!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzg3MDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13955 invoked from network); 24 Oct 2012 15:04:26 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 15:04:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="42287025"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 15:04:08 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 11:04:08 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TR2V0-0006G9-Ro;
	Wed, 24 Oct 2012 16:04:02 +0100
From: Stefano Stabellini 
To: 
Date: Wed, 24 Oct 2012 16:03:42 +0100
Message-ID: <1351091027-20740-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: 
References: 
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini 
Subject: [Xen-devel] [PATCH 2/7] xen/arm: setup the fixmap in head.S
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Setup the fixmap mapping directly in head.S rather than having a
temporary mapping only to re-do it later in C.

Signed-off-by: Stefano Stabellini 
---
 xen/arch/arm/early_printk.c |    5 ++---
 xen/arch/arm/head.S         |   32 +++++++++++++++++++-------------
 xen/arch/arm/mm.c           |    2 +-
 xen/arch/arm/setup.c        |    2 --
 4 files changed, 22 insertions(+), 19 deletions(-)

diff --git a/xen/arch/arm/early_printk.c b/xen/arch/arm/early_printk.c
index 3e51252..bdf4c0e 100644
--- a/xen/arch/arm/early_printk.c
+++ b/xen/arch/arm/early_printk.c
@@ -17,12 +17,11 @@
 
 #ifdef EARLY_UART_ADDRESS
 
-static void __init early_putch(char c)
+void __init early_putch(char c)
 {
     volatile uint32_t *r;
 
-    r = (uint32_t *)((EARLY_UART_ADDRESS & 0x001fffff)
-                     + XEN_VIRT_START + (1 << 21));
+    r = (uint32_t *)(XEN_VIRT_START + (1 << 21));
 
     /* XXX: assuming a PL011 UART. */
     while(*(r + 0x6) & 0x8)
diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
index 9fdeda7..3d01be0 100644
--- a/xen/arch/arm/head.S
+++ b/xen/arch/arm/head.S
@@ -24,6 +24,7 @@
 #define PT_PT  0xe7f /* nG=1, AF=1, SH=10, AP=01, NS=1, ATTR=111, T=1, P=1 */
 #define PT_MEM 0xe7d /* nG=1, AF=1, SH=10, AP=01, NS=1, ATTR=111, T=0, P=1 */
 #define PT_DEV 0xe71 /* nG=1, AF=1, SH=10, AP=01, NS=1, ATTR=100, T=0, P=1 */
+#define PT_DEV_L3 0xe73 /* lev3: nG=1, AF=1, SH=10, AP=01, NS=1, ATTR=100, T=1, P=1 */
 
 #define PT_UPPER(x) (PT_##x & 0xf00)
 #define PT_LOWER(x) (PT_##x & 0x0ff)
@@ -183,6 +184,16 @@ skip_bss:
 	teq   r12, #0
 	bne   pt_ready
 	
+	/* console fixmap */
+	ldr   r1, =xen_fixmap
+	add   r1, r1, r10            /* r1 := paddr (xen_fixmap) */
+	mov   r3, #0
+	lsr   r2, r11, #12
+	lsl   r2, r2, #12            /* 4K aligned paddr of UART */
+	orr   r2, r2, #PT_UPPER(DEV_L3)
+	orr   r2, r2, #PT_LOWER(DEV_L3) /* r2:r3 := 4K dev map including UART */
+	strd  r2, r3, [r1, #0]       /* Map it in the first fixmap's slot */
+	
 	/* Build the baseline idle pagetable's first-level entries */
 	ldr   r1, =xen_second
 	add   r1, r1, r10            /* r1 := paddr (xen_second) */
@@ -205,12 +216,13 @@ skip_bss:
 	ldr   r4, =start
 	lsr   r4, #18                /* Slot for vaddr(start) */
 	strd  r2, r3, [r1, r4]       /* Map Xen there too */
+
 #ifdef EARLY_UART_ADDRESS
-	ldr   r3, =(1<<(54-32))      /* NS for device mapping */
-	lsr   r2, r11, #21
-	lsl   r2, r2, #21            /* 2MB-aligned paddr of UART */
-	orr   r2, r2, #PT_UPPER(DEV)
-	orr   r2, r2, #PT_LOWER(DEV) /* r2:r3 := 2MB dev map including UART */
+	/* xen_fixmap pagetable */
+	ldr r2, =xen_fixmap
+	add r2, r2, r10
+	orr   r2, r2, #PT_UPPER(PT)
+	orr   r2, r2, #PT_LOWER(PT) /* r2:r3 := paddr (xen_fixmap) */
 	add   r4, r4, #8
 	strd  r2, r3, [r1, r4]       /* Map it in the fixmap's slot */
 #else
@@ -236,13 +248,9 @@ pt_ready:
 	mov   pc, r1                 /* Get a proper vaddr into PC */
 paging:
 
+	
 #ifdef EARLY_UART_ADDRESS
-	/* Recover the UART address in the new address space. */
-	lsl   r11, #11
-	lsr   r11, #11               /* UART base's offset from 2MB base */
-	adr   r0, start
-	add   r0, r0, #0x200000      /* vaddr of the fixmap's 2MB slot */
-	add   r11, r11, r0           /* r11 := vaddr (UART base address) */
+	ldr r11, =FIXMAP_ADDR(FIXMAP_CONSOLE)
 #endif
 
 	PRINT("- Ready -\r\n")
@@ -261,8 +269,6 @@ paging:
 	mcr   CP32(r0, BPIALL)       /* Flush branch predictor */
 	dsb                          /* Ensure completion of TLB+BP flush */
 	isb
- 	/* Now, the UART is in its proper fixmap address */
-	ldrne r11, =FIXMAP_ADDR(FIXMAP_CONSOLE)
 
 	/* Non-boot CPUs report that they've got this far */
 	ldr   r0, =ready_cpus
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index b0068d2..d0cd2c9 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -37,7 +37,7 @@ struct domain *dom_xen, *dom_io;
 /* Static start-of-day pagetables that we use before the allocators are up */
 lpae_t xen_pgtable[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
 lpae_t xen_second[LPAE_ENTRIES*4] __attribute__((__aligned__(4096*4)));
-static lpae_t xen_fixmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
+lpae_t xen_fixmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
 static lpae_t xen_xenmap[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
 
 /* Non-boot CPUs use this to find the correct pagetables. */
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 7568968..6fbcb81 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -194,9 +194,7 @@ void __init start_xen(unsigned long boot_phys_offset,
     setup_pagetables(boot_phys_offset, get_xen_paddr());
 
 #ifdef EARLY_UART_ADDRESS
-    /* Map the UART */
     /* TODO Need to get device tree or command line for UART address */
-    set_fixmap(FIXMAP_CONSOLE, EARLY_UART_ADDRESS >> PAGE_SHIFT, DEV_SHARED);
     pl011_init(0, FIXMAP_ADDR(FIXMAP_CONSOLE));
     console_init_preirq();
 #endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 15:04:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 15:04:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR2VQ-0007r7-GU; Wed, 24 Oct 2012 15:04:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR2VP-0007qa-C2
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 15:04:27 +0000
Received: from [85.158.139.83:55283] by server-13.bemta-5.messagelabs.com id
	61/55-27809-A7308805; Wed, 24 Oct 2012 15:04:26 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1351091064!32027678!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzg3MDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13942 invoked from network); 24 Oct 2012 15:04:26 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 15:04:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="42287026"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 15:04:08 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 11:04:08 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TR2V0-0006G9-Vb;
	Wed, 24 Oct 2012 16:04:03 +0100
From: Stefano Stabellini 
To: 
Date: Wed, 24 Oct 2012 16:03:45 +0100
Message-ID: <1351091027-20740-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: 
References: 
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini 
Subject: [Xen-devel] [PATCH 5/7] xen/arm: wake up secondary cpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Secondary cpus are held by the firmware until we send an IPI to them.

Signed-off-by: Stefano Stabellini 
---
 xen/arch/arm/head.S        |    8 ++++++--
 xen/arch/arm/mode_switch.S |   31 +++++++++++++++++++++++++++++++
 2 files changed, 37 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
index c784f4d..39c4774 100644
--- a/xen/arch/arm/head.S
+++ b/xen/arch/arm/head.S
@@ -79,12 +79,12 @@ start:
 	beq   boot_cpu               /* If we're CPU 0, boot now */
 
 	/* Non-boot CPUs wait here to be woken up one at a time. */
-1:	wfe
-	dsb
+1:	dsb
 	ldr   r0, =smp_up_cpu        /* VA of gate */
 	add   r0, r0, r10            /* PA of gate */
 	ldr   r1, [r0]               /* Which CPU is being booted? */
 	teq   r1, r12                /* Is it us? */
+	wfene
 	bne   1b
 
 boot_cpu:
@@ -98,6 +98,10 @@ boot_cpu:
 	PRINT(" booting -\r\n")
 #endif
 
+	/* Wake up secondary cpus */
+	teq   r12, #0
+	bleq  kick_cpus
+
 	/* Check that this CPU has Hyp mode */
 	mrc   CP32(r0, ID_PFR1)
 	and   r0, r0, #0xf000        /* Bits 12-15 define virt extensions */
diff --git a/xen/arch/arm/mode_switch.S b/xen/arch/arm/mode_switch.S
index 83a682b..39d80e8 100644
--- a/xen/arch/arm/mode_switch.S
+++ b/xen/arch/arm/mode_switch.S
@@ -21,6 +21,37 @@
 #include 
 #include 
 
+/* XXX: Versatile Express specific code */
+/* wake up secondary cpus */
+.globl kick_cpus
+kick_cpus:
+    /* write start paddr to v2m sysreg FLAGSSET register */
+	ldr   r0, =0x1c010000 /* base V2M sysreg MMIO address */
+	add   r1, r0, #0x34   /* SYS_FLAGSCLR register */
+	dsb
+	mov   r2, #0xffffffff
+	str   r2, [r1]
+	dsb
+	add   r1, r0, #0x30   /* SYS_FLAGSSET register */
+	ldr   r2, =start
+	add   r2, r2, r10
+	str   r2, [r1]
+	dsb
+	/* send an interrupt */
+	ldr   r0, =0x2c001000 /* base GICD MMIO address */
+	mov   r1, r0
+	mov   r2, #0x1        /* GICD_CTLR */
+	str   r2, [r1]        /* enable distributor */
+	add   r1, r0, #0xf00  /* GICD_SGIR */
+	mov   r2, #0xfe0000
+	str   r2, [r1]        /* send IPI to everybody */
+	dsb
+	mov   r1, r0
+	mov   r2, #0x0        /* GICD_CTLR */
+	str   r2, [r1]        /* disable distributor */
+	mov   pc, lr
+
+
 /* Get up a CPU into Hyp mode.  Clobbers r0-r3.
  *
  * Expects r12 == CPU number
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 15:04:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 15:04:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR2VQ-0007r7-GU; Wed, 24 Oct 2012 15:04:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR2VP-0007qa-C2
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 15:04:27 +0000
Received: from [85.158.139.83:55283] by server-13.bemta-5.messagelabs.com id
	61/55-27809-A7308805; Wed, 24 Oct 2012 15:04:26 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1351091064!32027678!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzg3MDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13942 invoked from network); 24 Oct 2012 15:04:26 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 15:04:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="42287026"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 15:04:08 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 11:04:08 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TR2V0-0006G9-Vb;
	Wed, 24 Oct 2012 16:04:03 +0100
From: Stefano Stabellini 
To: 
Date: Wed, 24 Oct 2012 16:03:45 +0100
Message-ID: <1351091027-20740-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: 
References: 
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini 
Subject: [Xen-devel] [PATCH 5/7] xen/arm: wake up secondary cpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Secondary cpus are held by the firmware until we send an IPI to them.

Signed-off-by: Stefano Stabellini 
---
 xen/arch/arm/head.S        |    8 ++++++--
 xen/arch/arm/mode_switch.S |   31 +++++++++++++++++++++++++++++++
 2 files changed, 37 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
index c784f4d..39c4774 100644
--- a/xen/arch/arm/head.S
+++ b/xen/arch/arm/head.S
@@ -79,12 +79,12 @@ start:
 	beq   boot_cpu               /* If we're CPU 0, boot now */
 
 	/* Non-boot CPUs wait here to be woken up one at a time. */
-1:	wfe
-	dsb
+1:	dsb
 	ldr   r0, =smp_up_cpu        /* VA of gate */
 	add   r0, r0, r10            /* PA of gate */
 	ldr   r1, [r0]               /* Which CPU is being booted? */
 	teq   r1, r12                /* Is it us? */
+	wfene
 	bne   1b
 
 boot_cpu:
@@ -98,6 +98,10 @@ boot_cpu:
 	PRINT(" booting -\r\n")
 #endif
 
+	/* Wake up secondary cpus */
+	teq   r12, #0
+	bleq  kick_cpus
+
 	/* Check that this CPU has Hyp mode */
 	mrc   CP32(r0, ID_PFR1)
 	and   r0, r0, #0xf000        /* Bits 12-15 define virt extensions */
diff --git a/xen/arch/arm/mode_switch.S b/xen/arch/arm/mode_switch.S
index 83a682b..39d80e8 100644
--- a/xen/arch/arm/mode_switch.S
+++ b/xen/arch/arm/mode_switch.S
@@ -21,6 +21,37 @@
 #include 
 #include 
 
+/* XXX: Versatile Express specific code */
+/* wake up secondary cpus */
+.globl kick_cpus
+kick_cpus:
+    /* write start paddr to v2m sysreg FLAGSSET register */
+	ldr   r0, =0x1c010000 /* base V2M sysreg MMIO address */
+	add   r1, r0, #0x34   /* SYS_FLAGSCLR register */
+	dsb
+	mov   r2, #0xffffffff
+	str   r2, [r1]
+	dsb
+	add   r1, r0, #0x30   /* SYS_FLAGSSET register */
+	ldr   r2, =start
+	add   r2, r2, r10
+	str   r2, [r1]
+	dsb
+	/* send an interrupt */
+	ldr   r0, =0x2c001000 /* base GICD MMIO address */
+	mov   r1, r0
+	mov   r2, #0x1        /* GICD_CTLR */
+	str   r2, [r1]        /* enable distributor */
+	add   r1, r0, #0xf00  /* GICD_SGIR */
+	mov   r2, #0xfe0000
+	str   r2, [r1]        /* send IPI to everybody */
+	dsb
+	mov   r1, r0
+	mov   r2, #0x0        /* GICD_CTLR */
+	str   r2, [r1]        /* disable distributor */
+	mov   pc, lr
+
+
 /* Get up a CPU into Hyp mode.  Clobbers r0-r3.
  *
  * Expects r12 == CPU number
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 15:04:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 15:04:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR2VY-0007wD-IS; Wed, 24 Oct 2012 15:04:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR2VX-0007vH-27
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 15:04:35 +0000
Received: from [85.158.143.99:19294] by server-2.bemta-4.messagelabs.com id
	96/5C-22268-28308805; Wed, 24 Oct 2012 15:04:34 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1351091072!28936267!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzg3MDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21138 invoked from network); 24 Oct 2012 15:04:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 15:04:33 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="42287076"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 15:04:14 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 11:04:13 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TR2V1-0006G9-2h;
	Wed, 24 Oct 2012 16:04:03 +0100
From: Stefano Stabellini 
To: 
Date: Wed, 24 Oct 2012 16:03:47 +0100
Message-ID: <1351091027-20740-7-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: 
References: 
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini 
Subject: [Xen-devel] [PATCH 7/7] xen/arm: get the number of cpus from device
	tree
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The system might have fewer cpus than the GIC supports.

Signed-off-by: Stefano Stabellini 
---
 xen/arch/arm/gic.c            |    4 +---
 xen/arch/arm/gic.h            |    2 +-
 xen/arch/arm/setup.c          |    3 ++-
 xen/common/device_tree.c      |   20 ++++++++++++++++++++
 xen/include/xen/device_tree.h |    1 +
 5 files changed, 25 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 5f06e08..0c6fab9 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -304,7 +304,7 @@ static void __cpuinit gic_hyp_disable(void)
 }
 
 /* Set up the GIC */
-int __init gic_init(void)
+void __init gic_init(void)
 {
     /* XXX FIXME get this from devicetree */
     gic.dbase = GIC_BASE_ADDRESS + GIC_DR_OFFSET;
@@ -328,8 +328,6 @@ int __init gic_init(void)
     gic.lr_mask = 0ULL;
 
     spin_unlock(&gic.lock);
-
-    return gic.cpus;
 }
 
 /* Set up the per-CPU parts of the GIC for a secondary CPU */
diff --git a/xen/arch/arm/gic.h b/xen/arch/arm/gic.h
index b8f9f201..beeaa46 100644
--- a/xen/arch/arm/gic.h
+++ b/xen/arch/arm/gic.h
@@ -146,7 +146,7 @@ extern int gic_route_irq_to_guest(struct domain *d, unsigned int irq,
 /* Accept an interrupt from the GIC and dispatch its handler */
 extern void gic_interrupt(struct cpu_user_regs *regs, int is_fiq);
 /* Bring up the interrupt controller, and report # cpus attached */
-extern int gic_init(void);
+extern void gic_init(void);
 /* Bring up a secondary CPU's per-CPU GIC interface */
 extern void gic_init_secondary_cpu(void);
 /* Take down a CPU's per-CPU GIC interface */
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 6fbcb81..26df902 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -189,6 +189,7 @@ void __init start_xen(unsigned long boot_phys_offset,
         + (atag_paddr & ((1 << SECOND_SHIFT) - 1));
     fdt_size = device_tree_early_init(fdt);
 
+    cpus = device_tree_cpus(fdt);
     cmdline_parse(device_tree_bootargs(fdt));
 
     setup_pagetables(boot_phys_offset, get_xen_paddr());
@@ -199,7 +200,7 @@ void __init start_xen(unsigned long boot_phys_offset,
     console_init_preirq();
 #endif
 
-    cpus = gic_init();
+    gic_init();
     make_cpus_ready(cpus, boot_phys_offset);
 
     percpu_init_areas();
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 3d1f0f4..3ae0f4d 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -153,6 +153,26 @@ const char *device_tree_bootargs(const void *fdt)
     return prop->data;
 }
 
+int device_tree_cpus(const void *fdt)
+{
+    int node, depth;
+    int cpus = 0;
+
+    node = fdt_path_offset(fdt, "/cpus");
+    if ( node < 0 )
+        return -1;
+    do {
+        node = fdt_next_node(fdt, node, &depth);
+        if ( node < 0 )
+            break;
+        if ( strncmp(fdt_get_name(fdt, node, NULL), "cpu", 3) )
+            break;
+        cpus++;
+    } while ( depth > 0 );
+
+    return cpus;
+}
+
 static int dump_node(const void *fdt, int node, const char *name, int depth,
                      u32 address_cells, u32 size_cells, void *data)
 {
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 4d010c0..46bc0f8 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -49,6 +49,7 @@ bool_t device_tree_node_matches(const void *fdt, int node, const char *match);
 int device_tree_for_each_node(const void *fdt,
                               device_tree_node_func func, void *data);
 const char *device_tree_bootargs(const void *fdt);
+int device_tree_cpus(const void *fdt);
 void device_tree_dump(const void *fdt);
 
 #endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 15:04:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 15:04:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR2VY-0007wD-IS; Wed, 24 Oct 2012 15:04:36 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR2VX-0007vH-27
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 15:04:35 +0000
Received: from [85.158.143.99:19294] by server-2.bemta-4.messagelabs.com id
	96/5C-22268-28308805; Wed, 24 Oct 2012 15:04:34 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1351091072!28936267!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzg3MDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21138 invoked from network); 24 Oct 2012 15:04:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 15:04:33 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="42287076"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 15:04:14 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 11:04:13 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TR2V1-0006G9-2h;
	Wed, 24 Oct 2012 16:04:03 +0100
From: Stefano Stabellini 
To: 
Date: Wed, 24 Oct 2012 16:03:47 +0100
Message-ID: <1351091027-20740-7-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: 
References: 
MIME-Version: 1.0
Cc: tim@xen.org, Ian.Campbell@citrix.com,
	Stefano Stabellini 
Subject: [Xen-devel] [PATCH 7/7] xen/arm: get the number of cpus from device
	tree
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The system might have fewer cpus than the GIC supports.

Signed-off-by: Stefano Stabellini 
---
 xen/arch/arm/gic.c            |    4 +---
 xen/arch/arm/gic.h            |    2 +-
 xen/arch/arm/setup.c          |    3 ++-
 xen/common/device_tree.c      |   20 ++++++++++++++++++++
 xen/include/xen/device_tree.h |    1 +
 5 files changed, 25 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 5f06e08..0c6fab9 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -304,7 +304,7 @@ static void __cpuinit gic_hyp_disable(void)
 }
 
 /* Set up the GIC */
-int __init gic_init(void)
+void __init gic_init(void)
 {
     /* XXX FIXME get this from devicetree */
     gic.dbase = GIC_BASE_ADDRESS + GIC_DR_OFFSET;
@@ -328,8 +328,6 @@ int __init gic_init(void)
     gic.lr_mask = 0ULL;
 
     spin_unlock(&gic.lock);
-
-    return gic.cpus;
 }
 
 /* Set up the per-CPU parts of the GIC for a secondary CPU */
diff --git a/xen/arch/arm/gic.h b/xen/arch/arm/gic.h
index b8f9f201..beeaa46 100644
--- a/xen/arch/arm/gic.h
+++ b/xen/arch/arm/gic.h
@@ -146,7 +146,7 @@ extern int gic_route_irq_to_guest(struct domain *d, unsigned int irq,
 /* Accept an interrupt from the GIC and dispatch its handler */
 extern void gic_interrupt(struct cpu_user_regs *regs, int is_fiq);
 /* Bring up the interrupt controller, and report # cpus attached */
-extern int gic_init(void);
+extern void gic_init(void);
 /* Bring up a secondary CPU's per-CPU GIC interface */
 extern void gic_init_secondary_cpu(void);
 /* Take down a CPU's per-CPU GIC interface */
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 6fbcb81..26df902 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -189,6 +189,7 @@ void __init start_xen(unsigned long boot_phys_offset,
         + (atag_paddr & ((1 << SECOND_SHIFT) - 1));
     fdt_size = device_tree_early_init(fdt);
 
+    cpus = device_tree_cpus(fdt);
     cmdline_parse(device_tree_bootargs(fdt));
 
     setup_pagetables(boot_phys_offset, get_xen_paddr());
@@ -199,7 +200,7 @@ void __init start_xen(unsigned long boot_phys_offset,
     console_init_preirq();
 #endif
 
-    cpus = gic_init();
+    gic_init();
     make_cpus_ready(cpus, boot_phys_offset);
 
     percpu_init_areas();
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 3d1f0f4..3ae0f4d 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -153,6 +153,26 @@ const char *device_tree_bootargs(const void *fdt)
     return prop->data;
 }
 
+int device_tree_cpus(const void *fdt)
+{
+    int node, depth;
+    int cpus = 0;
+
+    node = fdt_path_offset(fdt, "/cpus");
+    if ( node < 0 )
+        return -1;
+    do {
+        node = fdt_next_node(fdt, node, &depth);
+        if ( node < 0 )
+            break;
+        if ( strncmp(fdt_get_name(fdt, node, NULL), "cpu", 3) )
+            break;
+        cpus++;
+    } while ( depth > 0 );
+
+    return cpus;
+}
+
 static int dump_node(const void *fdt, int node, const char *name, int depth,
                      u32 address_cells, u32 size_cells, void *data)
 {
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 4d010c0..46bc0f8 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -49,6 +49,7 @@ bool_t device_tree_node_matches(const void *fdt, int node, const char *match);
 int device_tree_for_each_node(const void *fdt,
                               device_tree_node_func func, void *data);
 const char *device_tree_bootargs(const void *fdt);
+int device_tree_cpus(const void *fdt);
 void device_tree_dump(const void *fdt);
 
 #endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 15:21:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 15:21:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR2lf-0000Vw-CA; Wed, 24 Oct 2012 15:21:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR2le-0000Vr-6v
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 15:21:14 +0000
Received: from [85.158.137.99:57913] by server-13.bemta-3.messagelabs.com id
	FC/BB-24887-96708805; Wed, 24 Oct 2012 15:21:13 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1351092072!17528095!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24806 invoked from network); 24 Oct 2012 15:21:12 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 15:21:12 -0000
Received: by mail-bk0-f45.google.com with SMTP id jf3so318265bkc.32
	for ; Wed, 24 Oct 2012 08:21:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:from:to:cc:in-reply-to:references:content-type:date
	:message-id:mime-version:x-mailer:content-transfer-encoding;
	bh=fASTpsp76A0d5wwtMYFxWJSpS3uKRjD5+xutDTZJGhg=;
	b=F6aEVaDHF/BN4tLA7HOieQKPChFlQWiSYuZs3Wcw7AkeNAXaJcFpN/raczE+7brAjk
	VdzlpnJtUpBue3ws23QJlTJa3V5U/jLPr7y64X5umUQKPdTIWyRHN8MvJLtN07YLFulN
	6H0L9/p2fbaYbUxIvHBkWC5dUd3KoaaG/BX8EkDtkjoSel+qiQVLSjfejfzQPzGRvZuN
	GvW9kE+PayCaYSIqDD/wwEclLrn25h8GFN4YgDPDt8fO6IELRXria8JSFDuByEaY8Qnh
	jzK64SleaBHBUI460vN+qNEh50+IgKY4fAziTTxgaTZW0KVJFd4gc2M5hKiT9cnxKfFZ
	zVww==
Received: by 10.204.150.201 with SMTP id z9mr4862733bkv.104.1351092072303;
	Wed, 24 Oct 2012 08:21:12 -0700 (PDT)
Received: from [172.28.90.62] ([172.28.90.62])
	by mx.google.com with ESMTPS id ht18sm8518144bkc.14.2012.10.24.08.21.09
	(version=SSLv3 cipher=OTHER); Wed, 24 Oct 2012 08:21:11 -0700 (PDT)
From: Eric Dumazet 
To: Ian Campbell 
In-Reply-To: <1351087326.18035.50.camel@zakaz.uk.xensource.com>
References: <1351078936-14159-1-git-send-email-ian.campbell@citrix.com>
	<1351081703.6537.99.camel@edumazet-glaptop>
	<1351084618.18035.27.camel@zakaz.uk.xensource.com>
	<1351085403.6537.102.camel@edumazet-glaptop>
	<1351087326.18035.50.camel@zakaz.uk.xensource.com>
Date: Wed, 24 Oct 2012 17:21:08 +0200
Message-ID: <1351092068.6537.107.camel@edumazet-glaptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: "netdev@vger.kernel.org" ,
	Eric Dumazet ,
	"xen-devel@lists.xen.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH] net: allow configuration of the size of
 page in __netdev_alloc_frag
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 15:02 +0100, Ian Campbell wrote:
> On Wed, 2012-10-24 at 14:30 +0100, Eric Dumazet wrote:
> > It seems to me its a driver issue, for example
> > drivers/net/xen-netfront.c has assumptions that can be easily fixed.
> 
> The netfront ->head thing is a separate (although perhaps related)
> issue, I intended to fix along the same lines as the previous netback
> except for some unfathomable reason I haven't been able to reproduce the
> problem with netfront -- I've no idea why though since it seems like it
> should be a no brainer!
> 
> > Why skb->head can be on order-1 or order-2 pages and this is working ?
> 
> skb->head being order 1 or 2 isn't working for me. The driver I'm having
> issues with which caused me to create this particular patch is the tg3
> driver (although I don't think this is by any means specific to tg3).
> 
> For the ->head the tg3 driver does:
>         mapping = pci_map_single(tp->pdev, skb->data, len, PCI_DMA_TODEVICE);
> while for the frags it does:
>         mapping = skb_frag_dma_map(&tp->pdev->dev, frag, 0, len, DMA_TO_DEVICE);
> 
> This ought to do the Right Thing but doesn't seem to be working. Konrad
> suspected an issue with the swiotlb's handling of order>0 pages in some
> cases. As I said in the commit message he is looking into this issue.
> 
> My concern however was that even once the swiotlb is fixed to work right
> the effect of pci_map_single on a order>0 page is going to be that the
> data gets bounced into contiguous memory -- that is a memcpy which would
> undo the benefit of having allocating large pages to start with. So I
> figured that in such cases we'd be better off just using order 0
> allocations to start with.

I am really confused.

If you really have such problems, why locally generated TCP traffic
doesnt also have it ?

Your patch doesnt touch sk_page_frag_refill(), does it ?




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 15:21:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 15:21:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR2lf-0000Vw-CA; Wed, 24 Oct 2012 15:21:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR2le-0000Vr-6v
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 15:21:14 +0000
Received: from [85.158.137.99:57913] by server-13.bemta-3.messagelabs.com id
	FC/BB-24887-96708805; Wed, 24 Oct 2012 15:21:13 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1351092072!17528095!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24806 invoked from network); 24 Oct 2012 15:21:12 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 15:21:12 -0000
Received: by mail-bk0-f45.google.com with SMTP id jf3so318265bkc.32
	for ; Wed, 24 Oct 2012 08:21:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:from:to:cc:in-reply-to:references:content-type:date
	:message-id:mime-version:x-mailer:content-transfer-encoding;
	bh=fASTpsp76A0d5wwtMYFxWJSpS3uKRjD5+xutDTZJGhg=;
	b=F6aEVaDHF/BN4tLA7HOieQKPChFlQWiSYuZs3Wcw7AkeNAXaJcFpN/raczE+7brAjk
	VdzlpnJtUpBue3ws23QJlTJa3V5U/jLPr7y64X5umUQKPdTIWyRHN8MvJLtN07YLFulN
	6H0L9/p2fbaYbUxIvHBkWC5dUd3KoaaG/BX8EkDtkjoSel+qiQVLSjfejfzQPzGRvZuN
	GvW9kE+PayCaYSIqDD/wwEclLrn25h8GFN4YgDPDt8fO6IELRXria8JSFDuByEaY8Qnh
	jzK64SleaBHBUI460vN+qNEh50+IgKY4fAziTTxgaTZW0KVJFd4gc2M5hKiT9cnxKfFZ
	zVww==
Received: by 10.204.150.201 with SMTP id z9mr4862733bkv.104.1351092072303;
	Wed, 24 Oct 2012 08:21:12 -0700 (PDT)
Received: from [172.28.90.62] ([172.28.90.62])
	by mx.google.com with ESMTPS id ht18sm8518144bkc.14.2012.10.24.08.21.09
	(version=SSLv3 cipher=OTHER); Wed, 24 Oct 2012 08:21:11 -0700 (PDT)
From: Eric Dumazet 
To: Ian Campbell 
In-Reply-To: <1351087326.18035.50.camel@zakaz.uk.xensource.com>
References: <1351078936-14159-1-git-send-email-ian.campbell@citrix.com>
	<1351081703.6537.99.camel@edumazet-glaptop>
	<1351084618.18035.27.camel@zakaz.uk.xensource.com>
	<1351085403.6537.102.camel@edumazet-glaptop>
	<1351087326.18035.50.camel@zakaz.uk.xensource.com>
Date: Wed, 24 Oct 2012 17:21:08 +0200
Message-ID: <1351092068.6537.107.camel@edumazet-glaptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: "netdev@vger.kernel.org" ,
	Eric Dumazet ,
	"xen-devel@lists.xen.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH] net: allow configuration of the size of
 page in __netdev_alloc_frag
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 15:02 +0100, Ian Campbell wrote:
> On Wed, 2012-10-24 at 14:30 +0100, Eric Dumazet wrote:
> > It seems to me its a driver issue, for example
> > drivers/net/xen-netfront.c has assumptions that can be easily fixed.
> 
> The netfront ->head thing is a separate (although perhaps related)
> issue, I intended to fix along the same lines as the previous netback
> except for some unfathomable reason I haven't been able to reproduce the
> problem with netfront -- I've no idea why though since it seems like it
> should be a no brainer!
> 
> > Why skb->head can be on order-1 or order-2 pages and this is working ?
> 
> skb->head being order 1 or 2 isn't working for me. The driver I'm having
> issues with which caused me to create this particular patch is the tg3
> driver (although I don't think this is by any means specific to tg3).
> 
> For the ->head the tg3 driver does:
>         mapping = pci_map_single(tp->pdev, skb->data, len, PCI_DMA_TODEVICE);
> while for the frags it does:
>         mapping = skb_frag_dma_map(&tp->pdev->dev, frag, 0, len, DMA_TO_DEVICE);
> 
> This ought to do the Right Thing but doesn't seem to be working. Konrad
> suspected an issue with the swiotlb's handling of order>0 pages in some
> cases. As I said in the commit message he is looking into this issue.
> 
> My concern however was that even once the swiotlb is fixed to work right
> the effect of pci_map_single on a order>0 page is going to be that the
> data gets bounced into contiguous memory -- that is a memcpy which would
> undo the benefit of having allocating large pages to start with. So I
> figured that in such cases we'd be better off just using order 0
> allocations to start with.

I am really confused.

If you really have such problems, why locally generated TCP traffic
doesnt also have it ?

Your patch doesnt touch sk_page_frag_refill(), does it ?




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 15:26:54 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 15:26:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR2qv-0000eD-5d; Wed, 24 Oct 2012 15:26:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR2qt-0000e8-9L
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 15:26:39 +0000
Received: from [85.158.143.99:18756] by server-3.bemta-4.messagelabs.com id
	EA/15-24279-EA808805; Wed, 24 Oct 2012 15:26:38 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1351092397!29269132!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1295 invoked from network); 24 Oct 2012 15:26:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 15:26:38 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15362659"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 15:26:37 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 24 Oct 2012 16:26:38 +0100
Date: Wed, 24 Oct 2012 16:26:08 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: "linux-kernel@vger.kernel.org" 
In-Reply-To: 
Message-ID: 
References: 
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Dave Martin ,
	"xen-devel@lists.xensource.com" ,
	"linaro-dev@lists.linaro.org" ,
	Ian Campbell , "arnd@arndb.de" ,
	"konrad.wilk@oracle.com" ,
	Stefano Stabellini ,
	"Tim \(Xen.org\)" , "linux-arm-kernel@lists.infradead.org"
	
Subject: [Xen-devel] [PATCH RESEND] xen/arm: use the __HVC macro
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Use the new __HVC macro in hypercall.S.

Signed-off-by: Stefano Stabellini 

---
 arch/arm/xen/hypercall.S |   14 +++++---------
 1 files changed, 5 insertions(+), 9 deletions(-)

diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
index 074f5ed..71f7239 100644
--- a/arch/arm/xen/hypercall.S
+++ b/arch/arm/xen/hypercall.S
@@ -48,20 +48,16 @@
 
 #include 
 #include 
+#include 
 #include 
 
 
-/* HVC 0xEA1 */
-#ifdef CONFIG_THUMB2_KERNEL
-#define xen_hvc .word 0xf7e08ea1
-#else
-#define xen_hvc .word 0xe140ea71
-#endif
+#define XEN_IMM 0xEA1
 
 #define HYPERCALL_SIMPLE(hypercall)		\
 ENTRY(HYPERVISOR_##hypercall)			\
 	mov r12, #__HYPERVISOR_##hypercall;	\
-	xen_hvc;							\
+	__HVC(XEN_IMM);						\
 	mov pc, lr;							\
 ENDPROC(HYPERVISOR_##hypercall)
 
@@ -76,7 +72,7 @@ ENTRY(HYPERVISOR_##hypercall)			\
 	stmdb sp!, {r4}						\
 	ldr r4, [sp, #4]					\
 	mov r12, #__HYPERVISOR_##hypercall;	\
-	xen_hvc								\
+	__HVC(XEN_IMM);						\
 	ldm sp!, {r4}						\
 	mov pc, lr							\
 ENDPROC(HYPERVISOR_##hypercall)
@@ -100,7 +96,7 @@ ENTRY(privcmd_call)
 	mov r2, r3
 	ldr r3, [sp, #8]
 	ldr r4, [sp, #4]
-	xen_hvc
+	__HVC(XEN_IMM)
 	ldm sp!, {r4}
 	mov pc, lr
 ENDPROC(privcmd_call);
-- 
1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 15:26:54 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 15:26:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR2qv-0000eD-5d; Wed, 24 Oct 2012 15:26:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR2qt-0000e8-9L
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 15:26:39 +0000
Received: from [85.158.143.99:18756] by server-3.bemta-4.messagelabs.com id
	EA/15-24279-EA808805; Wed, 24 Oct 2012 15:26:38 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1351092397!29269132!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1295 invoked from network); 24 Oct 2012 15:26:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 15:26:38 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15362659"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 15:26:37 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 24 Oct 2012 16:26:38 +0100
Date: Wed, 24 Oct 2012 16:26:08 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: "linux-kernel@vger.kernel.org" 
In-Reply-To: 
Message-ID: 
References: 
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Dave Martin ,
	"xen-devel@lists.xensource.com" ,
	"linaro-dev@lists.linaro.org" ,
	Ian Campbell , "arnd@arndb.de" ,
	"konrad.wilk@oracle.com" ,
	Stefano Stabellini ,
	"Tim \(Xen.org\)" , "linux-arm-kernel@lists.infradead.org"
	
Subject: [Xen-devel] [PATCH RESEND] xen/arm: use the __HVC macro
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Use the new __HVC macro in hypercall.S.

Signed-off-by: Stefano Stabellini 

---
 arch/arm/xen/hypercall.S |   14 +++++---------
 1 files changed, 5 insertions(+), 9 deletions(-)

diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
index 074f5ed..71f7239 100644
--- a/arch/arm/xen/hypercall.S
+++ b/arch/arm/xen/hypercall.S
@@ -48,20 +48,16 @@
 
 #include 
 #include 
+#include 
 #include 
 
 
-/* HVC 0xEA1 */
-#ifdef CONFIG_THUMB2_KERNEL
-#define xen_hvc .word 0xf7e08ea1
-#else
-#define xen_hvc .word 0xe140ea71
-#endif
+#define XEN_IMM 0xEA1
 
 #define HYPERCALL_SIMPLE(hypercall)		\
 ENTRY(HYPERVISOR_##hypercall)			\
 	mov r12, #__HYPERVISOR_##hypercall;	\
-	xen_hvc;							\
+	__HVC(XEN_IMM);						\
 	mov pc, lr;							\
 ENDPROC(HYPERVISOR_##hypercall)
 
@@ -76,7 +72,7 @@ ENTRY(HYPERVISOR_##hypercall)			\
 	stmdb sp!, {r4}						\
 	ldr r4, [sp, #4]					\
 	mov r12, #__HYPERVISOR_##hypercall;	\
-	xen_hvc								\
+	__HVC(XEN_IMM);						\
 	ldm sp!, {r4}						\
 	mov pc, lr							\
 ENDPROC(HYPERVISOR_##hypercall)
@@ -100,7 +96,7 @@ ENTRY(privcmd_call)
 	mov r2, r3
 	ldr r3, [sp, #8]
 	ldr r4, [sp, #4]
-	xen_hvc
+	__HVC(XEN_IMM)
 	ldm sp!, {r4}
 	mov pc, lr
 ENDPROC(privcmd_call);
-- 
1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 15:32:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 15:32:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR2wA-0000nb-Tn; Wed, 24 Oct 2012 15:32:06 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TR2w9-0000nV-BO
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 15:32:05 +0000
Received: from [193.109.254.147:18321] by server-5.bemta-14.messagelabs.com id
	8E/6C-18309-4F908805; Wed, 24 Oct 2012 15:32:04 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1351092443!8660837!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20020 invoked from network); 24 Oct 2012 15:27:25 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Oct 2012 15:27:25 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TR2rN-000C79-3s; Wed, 24 Oct 2012 15:27:09 +0000
Date: Wed, 24 Oct 2012 16:27:09 +0100
From: Tim Deegan 
To: Stefano Stabellini 
Message-ID: <20121024152709.GB39126@ocelot.phlegethon.org>
References: 
	<1351091027-20740-2-git-send-email-stefano.stabellini@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1351091027-20740-2-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 2/7] xen/arm: setup the fixmap in head.S
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 16:03 +0100 on 24 Oct (1351094622), Stefano Stabellini wrote:
> Setup the fixmap mapping directly in head.S rather than having a
> temporary mapping only to re-do it later in C.
> 
> Signed-off-by: Stefano Stabellini 

I'm generally against doing anything in asm that could be in C, as
you know, but this actually looks OK.  Nits below.

> @@ -183,6 +184,16 @@ skip_bss:
>  	teq   r12, #0
>  	bne   pt_ready
>  	
> +	/* console fixmap */
> +	ldr   r1, =xen_fixmap
> +	add   r1, r1, r10            /* r1 := paddr (xen_fixmap) */
> +	mov   r3, #0
> +	lsr   r2, r11, #12
> +	lsl   r2, r2, #12            /* 4K aligned paddr of UART */
> +	orr   r2, r2, #PT_UPPER(DEV_L3)
> +	orr   r2, r2, #PT_LOWER(DEV_L3) /* r2:r3 := 4K dev map including UART */
> +	strd  r2, r3, [r1, #0]       /* Map it in the first fixmap's slot */

Can you use #(FIXMAP_CONSOLE*8) here rather than hard-coding the 0?

> +	
>  	/* Build the baseline idle pagetable's first-level entries */
>  	ldr   r1, =xen_second
>  	add   r1, r1, r10            /* r1 := paddr (xen_second) */
> @@ -205,12 +216,13 @@ skip_bss:
>  	ldr   r4, =start
>  	lsr   r4, #18                /* Slot for vaddr(start) */
>  	strd  r2, r3, [r1, r4]       /* Map Xen there too */
> +
>  #ifdef EARLY_UART_ADDRESS
> -	ldr   r3, =(1<<(54-32))      /* NS for device mapping */
> -	lsr   r2, r11, #21
> -	lsl   r2, r2, #21            /* 2MB-aligned paddr of UART */
> -	orr   r2, r2, #PT_UPPER(DEV)
> -	orr   r2, r2, #PT_LOWER(DEV) /* r2:r3 := 2MB dev map including UART */
> +	/* xen_fixmap pagetable */
> +	ldr r2, =xen_fixmap
> +	add r2, r2, r10

Please keep the operands aligned with the code above and below, and maybe
add a comment that r2 := paddr (xen_fixmap).

> +	orr   r2, r2, #PT_UPPER(PT)
> +	orr   r2, r2, #PT_LOWER(PT) /* r2:r3 := paddr (xen_fixmap) */

r2:r3 is a pagetable mapping here, not a paddr.  Also the comment's not
aligned with the ones above and below.

>  	add   r4, r4, #8
>  	strd  r2, r3, [r1, r4]       /* Map it in the fixmap's slot */
>  #else
> @@ -236,13 +248,9 @@ pt_ready:
>  	mov   pc, r1                 /* Get a proper vaddr into PC */
>  paging:
>  
> +	
>  #ifdef EARLY_UART_ADDRESS
> -	/* Recover the UART address in the new address space. */
> -	lsl   r11, #11
> -	lsr   r11, #11               /* UART base's offset from 2MB base */
> -	adr   r0, start
> -	add   r0, r0, #0x200000      /* vaddr of the fixmap's 2MB slot */
> -	add   r11, r11, r0           /* r11 := vaddr (UART base address) */
> +	ldr r11, =FIXMAP_ADDR(FIXMAP_CONSOLE)

Please leave a comment in to say what this is doing.  Also, the
alignment is wrong again.  Sorry to be picky about this but I want to
keep head.S readable.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 15:32:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 15:32:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR2wA-0000nb-Tn; Wed, 24 Oct 2012 15:32:06 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TR2w9-0000nV-BO
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 15:32:05 +0000
Received: from [193.109.254.147:18321] by server-5.bemta-14.messagelabs.com id
	8E/6C-18309-4F908805; Wed, 24 Oct 2012 15:32:04 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1351092443!8660837!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20020 invoked from network); 24 Oct 2012 15:27:25 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Oct 2012 15:27:25 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TR2rN-000C79-3s; Wed, 24 Oct 2012 15:27:09 +0000
Date: Wed, 24 Oct 2012 16:27:09 +0100
From: Tim Deegan 
To: Stefano Stabellini 
Message-ID: <20121024152709.GB39126@ocelot.phlegethon.org>
References: 
	<1351091027-20740-2-git-send-email-stefano.stabellini@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1351091027-20740-2-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 2/7] xen/arm: setup the fixmap in head.S
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 16:03 +0100 on 24 Oct (1351094622), Stefano Stabellini wrote:
> Setup the fixmap mapping directly in head.S rather than having a
> temporary mapping only to re-do it later in C.
> 
> Signed-off-by: Stefano Stabellini 

I'm generally against doing anything in asm that could be in C, as
you know, but this actually looks OK.  Nits below.

> @@ -183,6 +184,16 @@ skip_bss:
>  	teq   r12, #0
>  	bne   pt_ready
>  	
> +	/* console fixmap */
> +	ldr   r1, =xen_fixmap
> +	add   r1, r1, r10            /* r1 := paddr (xen_fixmap) */
> +	mov   r3, #0
> +	lsr   r2, r11, #12
> +	lsl   r2, r2, #12            /* 4K aligned paddr of UART */
> +	orr   r2, r2, #PT_UPPER(DEV_L3)
> +	orr   r2, r2, #PT_LOWER(DEV_L3) /* r2:r3 := 4K dev map including UART */
> +	strd  r2, r3, [r1, #0]       /* Map it in the first fixmap's slot */

Can you use #(FIXMAP_CONSOLE*8) here rather than hard-coding the 0?

> +	
>  	/* Build the baseline idle pagetable's first-level entries */
>  	ldr   r1, =xen_second
>  	add   r1, r1, r10            /* r1 := paddr (xen_second) */
> @@ -205,12 +216,13 @@ skip_bss:
>  	ldr   r4, =start
>  	lsr   r4, #18                /* Slot for vaddr(start) */
>  	strd  r2, r3, [r1, r4]       /* Map Xen there too */
> +
>  #ifdef EARLY_UART_ADDRESS
> -	ldr   r3, =(1<<(54-32))      /* NS for device mapping */
> -	lsr   r2, r11, #21
> -	lsl   r2, r2, #21            /* 2MB-aligned paddr of UART */
> -	orr   r2, r2, #PT_UPPER(DEV)
> -	orr   r2, r2, #PT_LOWER(DEV) /* r2:r3 := 2MB dev map including UART */
> +	/* xen_fixmap pagetable */
> +	ldr r2, =xen_fixmap
> +	add r2, r2, r10

Please keep the operands aligned with the code above and below, and maybe
add a comment that r2 := paddr (xen_fixmap).

> +	orr   r2, r2, #PT_UPPER(PT)
> +	orr   r2, r2, #PT_LOWER(PT) /* r2:r3 := paddr (xen_fixmap) */

r2:r3 is a pagetable mapping here, not a paddr.  Also the comment's not
aligned with the ones above and below.

>  	add   r4, r4, #8
>  	strd  r2, r3, [r1, r4]       /* Map it in the fixmap's slot */
>  #else
> @@ -236,13 +248,9 @@ pt_ready:
>  	mov   pc, r1                 /* Get a proper vaddr into PC */
>  paging:
>  
> +	
>  #ifdef EARLY_UART_ADDRESS
> -	/* Recover the UART address in the new address space. */
> -	lsl   r11, #11
> -	lsr   r11, #11               /* UART base's offset from 2MB base */
> -	adr   r0, start
> -	add   r0, r0, #0x200000      /* vaddr of the fixmap's 2MB slot */
> -	add   r11, r11, r0           /* r11 := vaddr (UART base address) */
> +	ldr r11, =FIXMAP_ADDR(FIXMAP_CONSOLE)

Please leave a comment in to say what this is doing.  Also, the
alignment is wrong again.  Sorry to be picky about this but I want to
keep head.S readable.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 15:33:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 15:33:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR2xO-0000sG-CE; Wed, 24 Oct 2012 15:33:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR2xN-0000sB-KH
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 15:33:21 +0000
Received: from [85.158.137.99:5344] by server-9.bemta-3.messagelabs.com id
	7C/A6-16841-04A08805; Wed, 24 Oct 2012 15:33:20 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1351092797!20507779!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16183 invoked from network); 24 Oct 2012 15:33:20 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 15:33:20 -0000
Received: by mail-vc0-f173.google.com with SMTP id fl15so796997vcb.32
	for ; Wed, 24 Oct 2012 08:33:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:date:x-google-sender-auth:message-id:subject
	:from:to:cc:content-type;
	bh=HRr5kr6QefShU8sMRQRkeYUqjBY/Tx9rSmW/x2eRROA=;
	b=d6nHqQWYP32dK0BaeMSPybzcB8jRPIqlHOHEqV52axpah2yZ5Wi+8ZM3QDzqrNZYqY
	FZqLzy2WUT2E9sir6U/1R2dzp/nkz6cvV7J/SXrnTfhD+ct0SRzdpYerSCdqSlxK78Ed
	fzmQiqAiri3gLO4EJTSawm6EqTe3kK/FbP9YtAfL41FyzmeB+oel3/U3POM4PrkYgYOr
	WUUDJyFDECJ/SskstQ8HqysJKwr4Q0DmtCDkYyvLVYRfau+8uvDXUJm9VPwhwl7Rn55e
	jG2aDFJYzj5uQJbmeoDQBPojBtyIi3WfX3w1X/eQK8tEqrq+6eAxhQFwT07E4hW7YxKc
	Y1VA==
MIME-Version: 1.0
Received: by 10.52.16.110 with SMTP id f14mr21747919vdd.8.1351092795297; Wed,
	24 Oct 2012 08:33:15 -0700 (PDT)
Received: by 10.58.231.138 with HTTP; Wed, 24 Oct 2012 08:33:15 -0700 (PDT)
Date: Wed, 24 Oct 2012 16:33:15 +0100
X-Google-Sender-Auth: P-eCkm2YbCfQ7o7qB4q1oOXvusA
Message-ID: 
From: George Dunlap 
To: Jim Fehlig 
Cc: Dario Faggioli , xen-devel@lists.xen.org
Subject: [Xen-devel] libxl drivers for libvirt?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hey Jim,

I was wondering if you or someone on your team could give me an idea
what the status of libxl support is in libvirt, particularly wrt
various releases?

I'm asking because I'm going to UDS next week to talk about the 13.04
release, and it would be good to get Xen 4.2 in; but that in part
depends on whether there will be libvirt support for 4.2 in whatever
version of libvirt they ship as well.  I know Dario has been facing
the same kind of questions for Fedora 18.

It appears that libvirt 0.10.2 has limited support for the 4.1 libxl
driver; but:
* This doesn't include some core features, like live migration
* It won't compile against 4.2's libxl

Is that right?

So I guess it would be nice to know:
* What kind of Xen support is available in the most recent release
(0.10.2, I believe), both xend and libxl
* What kind of Xen support for libxl is in the libvirt development
branch, and do you have an idea when full support for 4.2 (at least,
including migration, suspend/resume, &c) might be available?
* Whether it would be easy for distros to backport 4.2 libxl support
to whatever their release is?

That would help us better advise distros whether to:
* Stick with Xen 4.1 for the next release
* Go with Xen 4.2 but suggest continuing to use xend if libvirt
support is wanted
* Go with Xen 4.2 and backport patches to make libvirt work with libxl
* Go with Xen 4.2 and expect that libxl support will show up without
too much effort

Obviously change is the only constant, so you can't predict with
perfect certainty; but if we have an idea what's most likely, we can
plan on that and then adjust based on what actually happens.

Thanks!
 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 15:33:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 15:33:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR2xO-0000sG-CE; Wed, 24 Oct 2012 15:33:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR2xN-0000sB-KH
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 15:33:21 +0000
Received: from [85.158.137.99:5344] by server-9.bemta-3.messagelabs.com id
	7C/A6-16841-04A08805; Wed, 24 Oct 2012 15:33:20 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1351092797!20507779!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16183 invoked from network); 24 Oct 2012 15:33:20 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 15:33:20 -0000
Received: by mail-vc0-f173.google.com with SMTP id fl15so796997vcb.32
	for ; Wed, 24 Oct 2012 08:33:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:date:x-google-sender-auth:message-id:subject
	:from:to:cc:content-type;
	bh=HRr5kr6QefShU8sMRQRkeYUqjBY/Tx9rSmW/x2eRROA=;
	b=d6nHqQWYP32dK0BaeMSPybzcB8jRPIqlHOHEqV52axpah2yZ5Wi+8ZM3QDzqrNZYqY
	FZqLzy2WUT2E9sir6U/1R2dzp/nkz6cvV7J/SXrnTfhD+ct0SRzdpYerSCdqSlxK78Ed
	fzmQiqAiri3gLO4EJTSawm6EqTe3kK/FbP9YtAfL41FyzmeB+oel3/U3POM4PrkYgYOr
	WUUDJyFDECJ/SskstQ8HqysJKwr4Q0DmtCDkYyvLVYRfau+8uvDXUJm9VPwhwl7Rn55e
	jG2aDFJYzj5uQJbmeoDQBPojBtyIi3WfX3w1X/eQK8tEqrq+6eAxhQFwT07E4hW7YxKc
	Y1VA==
MIME-Version: 1.0
Received: by 10.52.16.110 with SMTP id f14mr21747919vdd.8.1351092795297; Wed,
	24 Oct 2012 08:33:15 -0700 (PDT)
Received: by 10.58.231.138 with HTTP; Wed, 24 Oct 2012 08:33:15 -0700 (PDT)
Date: Wed, 24 Oct 2012 16:33:15 +0100
X-Google-Sender-Auth: P-eCkm2YbCfQ7o7qB4q1oOXvusA
Message-ID: 
From: George Dunlap 
To: Jim Fehlig 
Cc: Dario Faggioli , xen-devel@lists.xen.org
Subject: [Xen-devel] libxl drivers for libvirt?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hey Jim,

I was wondering if you or someone on your team could give me an idea
what the status of libxl support is in libvirt, particularly wrt
various releases?

I'm asking because I'm going to UDS next week to talk about the 13.04
release, and it would be good to get Xen 4.2 in; but that in part
depends on whether there will be libvirt support for 4.2 in whatever
version of libvirt they ship as well.  I know Dario has been facing
the same kind of questions for Fedora 18.

It appears that libvirt 0.10.2 has limited support for the 4.1 libxl
driver; but:
* This doesn't include some core features, like live migration
* It won't compile against 4.2's libxl

Is that right?

So I guess it would be nice to know:
* What kind of Xen support is available in the most recent release
(0.10.2, I believe), both xend and libxl
* What kind of Xen support for libxl is in the libvirt development
branch, and do you have an idea when full support for 4.2 (at least,
including migration, suspend/resume, &c) might be available?
* Whether it would be easy for distros to backport 4.2 libxl support
to whatever their release is?

That would help us better advise distros whether to:
* Stick with Xen 4.1 for the next release
* Go with Xen 4.2 but suggest continuing to use xend if libvirt
support is wanted
* Go with Xen 4.2 and backport patches to make libvirt work with libxl
* Go with Xen 4.2 and expect that libxl support will show up without
too much effort

Obviously change is the only constant, so you can't predict with
perfect certainty; but if we have an idea what's most likely, we can
plan on that and then adjust based on what actually happens.

Thanks!
 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 15:38:13 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 15:38:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR31p-00018D-5j; Wed, 24 Oct 2012 15:37:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR31n-000186-KD
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 15:37:55 +0000
Received: from [85.158.139.83:21040] by server-15.bemta-5.messagelabs.com id
	E1/F2-26920-25B08805; Wed, 24 Oct 2012 15:37:54 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1351093073!34117011!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20169 invoked from network); 24 Oct 2012 15:37:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 15:37:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15362970"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 15:37:53 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 24 Oct 2012 16:37:53 +0100
Date: Wed, 24 Oct 2012 16:37:24 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Tim Deegan 
In-Reply-To: <20121024152709.GB39126@ocelot.phlegethon.org>
Message-ID: 
References: 
	<1351091027-20740-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<20121024152709.GB39126@ocelot.phlegethon.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	Ian Campbell ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 2/7] xen/arm: setup the fixmap in head.S
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 24 Oct 2012, Tim Deegan wrote:
> At 16:03 +0100 on 24 Oct (1351094622), Stefano Stabellini wrote:
> > Setup the fixmap mapping directly in head.S rather than having a
> > temporary mapping only to re-do it later in C.
> > 
> > Signed-off-by: Stefano Stabellini 
> 
> I'm generally against doing anything in asm that could be in C, as
> you know, but this actually looks OK.  Nits below.

Thanks for the quick review!


> > @@ -183,6 +184,16 @@ skip_bss:
> >  	teq   r12, #0
> >  	bne   pt_ready
> >  	
> > +	/* console fixmap */
> > +	ldr   r1, =xen_fixmap
> > +	add   r1, r1, r10            /* r1 := paddr (xen_fixmap) */
> > +	mov   r3, #0
> > +	lsr   r2, r11, #12
> > +	lsl   r2, r2, #12            /* 4K aligned paddr of UART */
> > +	orr   r2, r2, #PT_UPPER(DEV_L3)
> > +	orr   r2, r2, #PT_LOWER(DEV_L3) /* r2:r3 := 4K dev map including UART */
> > +	strd  r2, r3, [r1, #0]       /* Map it in the first fixmap's slot */
> 
> Can you use #(FIXMAP_CONSOLE*8) here rather than hard-coding the 0?

Yep


> > +	
> >  	/* Build the baseline idle pagetable's first-level entries */
> >  	ldr   r1, =xen_second
> >  	add   r1, r1, r10            /* r1 := paddr (xen_second) */
> > @@ -205,12 +216,13 @@ skip_bss:
> >  	ldr   r4, =start
> >  	lsr   r4, #18                /* Slot for vaddr(start) */
> >  	strd  r2, r3, [r1, r4]       /* Map Xen there too */
> > +
> >  #ifdef EARLY_UART_ADDRESS
> > -	ldr   r3, =(1<<(54-32))      /* NS for device mapping */
> > -	lsr   r2, r11, #21
> > -	lsl   r2, r2, #21            /* 2MB-aligned paddr of UART */
> > -	orr   r2, r2, #PT_UPPER(DEV)
> > -	orr   r2, r2, #PT_LOWER(DEV) /* r2:r3 := 2MB dev map including UART */
> > +	/* xen_fixmap pagetable */
> > +	ldr r2, =xen_fixmap
> > +	add r2, r2, r10
> 
> Please keep the operands aligned with the code above and below, and maybe
> add a comment that r2 := paddr (xen_fixmap).

good point


> > +	orr   r2, r2, #PT_UPPER(PT)
> > +	orr   r2, r2, #PT_LOWER(PT) /* r2:r3 := paddr (xen_fixmap) */
> 
> r2:r3 is a pagetable mapping here, not a paddr.  Also the comment's not
> aligned with the ones above and below.

I'll fix


> >  	add   r4, r4, #8
> >  	strd  r2, r3, [r1, r4]       /* Map it in the fixmap's slot */
> >  #else
> > @@ -236,13 +248,9 @@ pt_ready:
> >  	mov   pc, r1                 /* Get a proper vaddr into PC */
> >  paging:
> >  
> > +	
> >  #ifdef EARLY_UART_ADDRESS
> > -	/* Recover the UART address in the new address space. */
> > -	lsl   r11, #11
> > -	lsr   r11, #11               /* UART base's offset from 2MB base */
> > -	adr   r0, start
> > -	add   r0, r0, #0x200000      /* vaddr of the fixmap's 2MB slot */
> > -	add   r11, r11, r0           /* r11 := vaddr (UART base address) */
> > +	ldr r11, =FIXMAP_ADDR(FIXMAP_CONSOLE)
> 
> Please leave a comment in to say what this is doing.  Also, the
> alignment is wrong again.  Sorry to be picky about this but I want to
> keep head.S readable.

You have my complete support on code style issues and comments in
assembly code!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 15:38:13 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 15:38:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR31p-00018D-5j; Wed, 24 Oct 2012 15:37:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR31n-000186-KD
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 15:37:55 +0000
Received: from [85.158.139.83:21040] by server-15.bemta-5.messagelabs.com id
	E1/F2-26920-25B08805; Wed, 24 Oct 2012 15:37:54 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1351093073!34117011!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20169 invoked from network); 24 Oct 2012 15:37:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 15:37:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15362970"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 15:37:53 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 24 Oct 2012 16:37:53 +0100
Date: Wed, 24 Oct 2012 16:37:24 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Tim Deegan 
In-Reply-To: <20121024152709.GB39126@ocelot.phlegethon.org>
Message-ID: 
References: 
	<1351091027-20740-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<20121024152709.GB39126@ocelot.phlegethon.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	Ian Campbell ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 2/7] xen/arm: setup the fixmap in head.S
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 24 Oct 2012, Tim Deegan wrote:
> At 16:03 +0100 on 24 Oct (1351094622), Stefano Stabellini wrote:
> > Setup the fixmap mapping directly in head.S rather than having a
> > temporary mapping only to re-do it later in C.
> > 
> > Signed-off-by: Stefano Stabellini 
> 
> I'm generally against doing anything in asm that could be in C, as
> you know, but this actually looks OK.  Nits below.

Thanks for the quick review!


> > @@ -183,6 +184,16 @@ skip_bss:
> >  	teq   r12, #0
> >  	bne   pt_ready
> >  	
> > +	/* console fixmap */
> > +	ldr   r1, =xen_fixmap
> > +	add   r1, r1, r10            /* r1 := paddr (xen_fixmap) */
> > +	mov   r3, #0
> > +	lsr   r2, r11, #12
> > +	lsl   r2, r2, #12            /* 4K aligned paddr of UART */
> > +	orr   r2, r2, #PT_UPPER(DEV_L3)
> > +	orr   r2, r2, #PT_LOWER(DEV_L3) /* r2:r3 := 4K dev map including UART */
> > +	strd  r2, r3, [r1, #0]       /* Map it in the first fixmap's slot */
> 
> Can you use #(FIXMAP_CONSOLE*8) here rather than hard-coding the 0?

Yep


> > +	
> >  	/* Build the baseline idle pagetable's first-level entries */
> >  	ldr   r1, =xen_second
> >  	add   r1, r1, r10            /* r1 := paddr (xen_second) */
> > @@ -205,12 +216,13 @@ skip_bss:
> >  	ldr   r4, =start
> >  	lsr   r4, #18                /* Slot for vaddr(start) */
> >  	strd  r2, r3, [r1, r4]       /* Map Xen there too */
> > +
> >  #ifdef EARLY_UART_ADDRESS
> > -	ldr   r3, =(1<<(54-32))      /* NS for device mapping */
> > -	lsr   r2, r11, #21
> > -	lsl   r2, r2, #21            /* 2MB-aligned paddr of UART */
> > -	orr   r2, r2, #PT_UPPER(DEV)
> > -	orr   r2, r2, #PT_LOWER(DEV) /* r2:r3 := 2MB dev map including UART */
> > +	/* xen_fixmap pagetable */
> > +	ldr r2, =xen_fixmap
> > +	add r2, r2, r10
> 
> Please keep the operands aligned with the code above and below, and maybe
> add a comment that r2 := paddr (xen_fixmap).

good point


> > +	orr   r2, r2, #PT_UPPER(PT)
> > +	orr   r2, r2, #PT_LOWER(PT) /* r2:r3 := paddr (xen_fixmap) */
> 
> r2:r3 is a pagetable mapping here, not a paddr.  Also the comment's not
> aligned with the ones above and below.

I'll fix


> >  	add   r4, r4, #8
> >  	strd  r2, r3, [r1, r4]       /* Map it in the fixmap's slot */
> >  #else
> > @@ -236,13 +248,9 @@ pt_ready:
> >  	mov   pc, r1                 /* Get a proper vaddr into PC */
> >  paging:
> >  
> > +	
> >  #ifdef EARLY_UART_ADDRESS
> > -	/* Recover the UART address in the new address space. */
> > -	lsl   r11, #11
> > -	lsr   r11, #11               /* UART base's offset from 2MB base */
> > -	adr   r0, start
> > -	add   r0, r0, #0x200000      /* vaddr of the fixmap's 2MB slot */
> > -	add   r11, r11, r0           /* r11 := vaddr (UART base address) */
> > +	ldr r11, =FIXMAP_ADDR(FIXMAP_CONSOLE)
> 
> Please leave a comment in to say what this is doing.  Also, the
> alignment is wrong again.  Sorry to be picky about this but I want to
> keep head.S readable.

You have my complete support on code style issues and comments in
assembly code!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 15:40:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 15:40:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR33d-0001F9-SG; Wed, 24 Oct 2012 15:39:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TR33b-0001Ex-UJ
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 15:39:48 +0000
Received: from [85.158.143.35:21969] by server-2.bemta-4.messagelabs.com id
	CD/79-22268-2CB08805; Wed, 24 Oct 2012 15:39:46 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-21.messagelabs.com!1351093089!12255452!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4062 invoked from network); 24 Oct 2012 15:38:12 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Oct 2012 15:38:12 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TR321-000C9G-Ep; Wed, 24 Oct 2012 15:38:09 +0000
Date: Wed, 24 Oct 2012 16:38:09 +0100
From: Tim Deegan 
To: Stefano Stabellini 
Message-ID: <20121024153809.GC39126@ocelot.phlegethon.org>
References: 
	<1351091027-20740-5-git-send-email-stefano.stabellini@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1351091027-20740-5-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 5/7] xen/arm: wake up secondary cpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 16:03 +0100 on 24 Oct (1351094625), Stefano Stabellini wrote:
> Secondary cpus are held by the firmware until we send an IPI to them.
> 
> Signed-off-by: Stefano Stabellini 
> ---
>  xen/arch/arm/head.S        |    8 ++++++--
>  xen/arch/arm/mode_switch.S |   31 +++++++++++++++++++++++++++++++
>  2 files changed, 37 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
> index c784f4d..39c4774 100644
> --- a/xen/arch/arm/head.S
> +++ b/xen/arch/arm/head.S
> @@ -79,12 +79,12 @@ start:
>  	beq   boot_cpu               /* If we're CPU 0, boot now */
>  
>  	/* Non-boot CPUs wait here to be woken up one at a time. */
> -1:	wfe
> -	dsb
> +1:	dsb
>  	ldr   r0, =smp_up_cpu        /* VA of gate */
>  	add   r0, r0, r10            /* PA of gate */
>  	ldr   r1, [r0]               /* Which CPU is being booted? */
>  	teq   r1, r12                /* Is it us? */
> +	wfene

Shouldn't that be wf_i_ne?

>  	bne   1b
>  
>  boot_cpu:
> @@ -98,6 +98,10 @@ boot_cpu:
>  	PRINT(" booting -\r\n")
>  #endif
>  
> +	/* Wake up secondary cpus */
> +	teq   r12, #0
> +	bleq  kick_cpus
> +
>  	/* Check that this CPU has Hyp mode */
>  	mrc   CP32(r0, ID_PFR1)
>  	and   r0, r0, #0xf000        /* Bits 12-15 define virt extensions */
> diff --git a/xen/arch/arm/mode_switch.S b/xen/arch/arm/mode_switch.S
> index 83a682b..39d80e8 100644
> --- a/xen/arch/arm/mode_switch.S
> +++ b/xen/arch/arm/mode_switch.S
> @@ -21,6 +21,37 @@
>  #include 
>  #include 
>  
> +/* XXX: Versatile Express specific code */
> +/* wake up secondary cpus */
> +.globl kick_cpus
> +kick_cpus:
> +    /* write start paddr to v2m sysreg FLAGSSET register */
> +	ldr   r0, =0x1c010000 /* base V2M sysreg MMIO address */
> +	add   r1, r0, #0x34   /* SYS_FLAGSCLR register */
> +	dsb
> +	mov   r2, #0xffffffff
> +	str   r2, [r1]

Why not str r2, [r0, #0x34] and save the explicit add (and similarly below)?

> +	dsb
> +	add   r1, r0, #0x30   /* SYS_FLAGSSET register */
> +	ldr   r2, =start
> +	add   r2, r2, r10
> +	str   r2, [r1]
> +	dsb
> +	/* send an interrupt */
> +	ldr   r0, =0x2c001000 /* base GICD MMIO address */
> +	mov   r1, r0
> +	mov   r2, #0x1        /* GICD_CTLR */
> +	str   r2, [r1]        /* enable distributor */
> +	add   r1, r0, #0xf00  /* GICD_SGIR */

These GIGD_* addresses and constants are already defined in config.h and
gic.h; can you reuse those definitions?

Tim.

> +	mov   r2, #0xfe0000
> +	str   r2, [r1]        /* send IPI to everybody */
> +	dsb
> +	mov   r1, r0
> +	mov   r2, #0x0        /* GICD_CTLR */
> +	str   r2, [r1]        /* disable distributor */
> +	mov   pc, lr
> +
> +
>  /* Get up a CPU into Hyp mode.  Clobbers r0-r3.
>   *
>   * Expects r12 == CPU number
> -- 
> 1.7.2.5
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 15:40:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 15:40:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR33d-0001F9-SG; Wed, 24 Oct 2012 15:39:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TR33b-0001Ex-UJ
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 15:39:48 +0000
Received: from [85.158.143.35:21969] by server-2.bemta-4.messagelabs.com id
	CD/79-22268-2CB08805; Wed, 24 Oct 2012 15:39:46 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-21.messagelabs.com!1351093089!12255452!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4062 invoked from network); 24 Oct 2012 15:38:12 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Oct 2012 15:38:12 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TR321-000C9G-Ep; Wed, 24 Oct 2012 15:38:09 +0000
Date: Wed, 24 Oct 2012 16:38:09 +0100
From: Tim Deegan 
To: Stefano Stabellini 
Message-ID: <20121024153809.GC39126@ocelot.phlegethon.org>
References: 
	<1351091027-20740-5-git-send-email-stefano.stabellini@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1351091027-20740-5-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 5/7] xen/arm: wake up secondary cpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 16:03 +0100 on 24 Oct (1351094625), Stefano Stabellini wrote:
> Secondary cpus are held by the firmware until we send an IPI to them.
> 
> Signed-off-by: Stefano Stabellini 
> ---
>  xen/arch/arm/head.S        |    8 ++++++--
>  xen/arch/arm/mode_switch.S |   31 +++++++++++++++++++++++++++++++
>  2 files changed, 37 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
> index c784f4d..39c4774 100644
> --- a/xen/arch/arm/head.S
> +++ b/xen/arch/arm/head.S
> @@ -79,12 +79,12 @@ start:
>  	beq   boot_cpu               /* If we're CPU 0, boot now */
>  
>  	/* Non-boot CPUs wait here to be woken up one at a time. */
> -1:	wfe
> -	dsb
> +1:	dsb
>  	ldr   r0, =smp_up_cpu        /* VA of gate */
>  	add   r0, r0, r10            /* PA of gate */
>  	ldr   r1, [r0]               /* Which CPU is being booted? */
>  	teq   r1, r12                /* Is it us? */
> +	wfene

Shouldn't that be wf_i_ne?

>  	bne   1b
>  
>  boot_cpu:
> @@ -98,6 +98,10 @@ boot_cpu:
>  	PRINT(" booting -\r\n")
>  #endif
>  
> +	/* Wake up secondary cpus */
> +	teq   r12, #0
> +	bleq  kick_cpus
> +
>  	/* Check that this CPU has Hyp mode */
>  	mrc   CP32(r0, ID_PFR1)
>  	and   r0, r0, #0xf000        /* Bits 12-15 define virt extensions */
> diff --git a/xen/arch/arm/mode_switch.S b/xen/arch/arm/mode_switch.S
> index 83a682b..39d80e8 100644
> --- a/xen/arch/arm/mode_switch.S
> +++ b/xen/arch/arm/mode_switch.S
> @@ -21,6 +21,37 @@
>  #include 
>  #include 
>  
> +/* XXX: Versatile Express specific code */
> +/* wake up secondary cpus */
> +.globl kick_cpus
> +kick_cpus:
> +    /* write start paddr to v2m sysreg FLAGSSET register */
> +	ldr   r0, =0x1c010000 /* base V2M sysreg MMIO address */
> +	add   r1, r0, #0x34   /* SYS_FLAGSCLR register */
> +	dsb
> +	mov   r2, #0xffffffff
> +	str   r2, [r1]

Why not str r2, [r0, #0x34] and save the explicit add (and similarly below)?

> +	dsb
> +	add   r1, r0, #0x30   /* SYS_FLAGSSET register */
> +	ldr   r2, =start
> +	add   r2, r2, r10
> +	str   r2, [r1]
> +	dsb
> +	/* send an interrupt */
> +	ldr   r0, =0x2c001000 /* base GICD MMIO address */
> +	mov   r1, r0
> +	mov   r2, #0x1        /* GICD_CTLR */
> +	str   r2, [r1]        /* enable distributor */
> +	add   r1, r0, #0xf00  /* GICD_SGIR */

These GIGD_* addresses and constants are already defined in config.h and
gic.h; can you reuse those definitions?

Tim.

> +	mov   r2, #0xfe0000
> +	str   r2, [r1]        /* send IPI to everybody */
> +	dsb
> +	mov   r1, r0
> +	mov   r2, #0x0        /* GICD_CTLR */
> +	str   r2, [r1]        /* disable distributor */
> +	mov   pc, lr
> +
> +
>  /* Get up a CPU into Hyp mode.  Clobbers r0-r3.
>   *
>   * Expects r12 == CPU number
> -- 
> 1.7.2.5
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 15:50:15 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 15:50:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR3DQ-0001Sc-VE; Wed, 24 Oct 2012 15:49:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR3DP-0001SX-Vv
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 15:49:56 +0000
Received: from [85.158.137.99:23184] by server-6.bemta-3.messagelabs.com id
	32/D9-32375-32E08805; Wed, 24 Oct 2012 15:49:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1351093794!22918326!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30422 invoked from network); 24 Oct 2012 15:49:54 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-217.messagelabs.com with SMTP;
	24 Oct 2012 15:49:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 24 Oct 2012 16:52:15 +0100
Message-Id: <50882A4002000078000A4131@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 24 Oct 2012 16:49:52 +0100
From: "Jan Beulich" 
To: "xen-devel" 
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part8EBF5B30.2__="
Cc: Wei Wang , Ronny Hegewald ,
	xiantao.zhang@intel.com
Subject: [Xen-devel] [PATCH v3] IOMMU: keep disabled until iommu_setup() is
	called
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part8EBF5B30.2__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

The iommu is enabled by default when xen is booting and later disabled
in iommu_setup() when no iommu is present.

But under some circumstances iommu code can be called before
iommu_setup() is processed. If there is no iommu available xen crashes.

This can happen for example when panic(...) is called as introduced
with the patch "x86-64: detect processors subject to AMD erratum #121
and refuse to boot" since xen 4.1.3, resulting in
find_iommu_for_device() to be called in the context of
disable_IO_APIC() / __stop_this_cpu().

This patch fixes this by keeping the iommu disabled until iommu_setup()
is entered.

Originally-by: Ronny Hegewald 

In order for iommu_enable to be off initially, iommu_supports_eim()
must not depend on it anymore, nor must acpi_parse_dmar(). The former
in turn requires that iommu_intremap gets uncoupled from iommu_enabled
(in particular, failure during IOMMU setup should no longer result in
iommu_intremap getting cleared by generic code; IOMMU specific code
can still do so provided in can live with the consequences).

This could have the nice side effect of allowing to use "iommu=3Doff"
even when x2APIC was pre-enabled by the BIOS (in which case interrupt
remapping is a requirement, but DMA translation [obviously] isn't), but
that doesn't currently work (and hence x2apic_bsp_setup() forces the
IOMMU on rather than just interrupt remapping).

For consistency with VT-d, make the AMD IOMMU code also skip all ACPI
table parsing when neither iommu_enable nor iommu_intremap are set.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -975,6 +975,8 @@ void __init x2apic_bsp_setup(void)
         goto restore_out;
     }
=20
+    force_iommu =3D 1;
+
     genapic =3D apic_x2apic_probe();
     printk("Switched to APIC driver %s.\n", genapic->name);
=20
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -164,9 +164,13 @@ int __init amd_iov_detect(void)
 {
     INIT_LIST_HEAD(&amd_iommu_head);
=20
+    if ( !iommu_enable && !iommu_intremap )
+        return 0;
+
     if ( (amd_iommu_detect_acpi() !=3D0) || (iommu_found() =3D=3D 0) )
     {
         printk("AMD-Vi: IOMMU not found!\n");
+        iommu_intremap =3D 0;
         return -ENODEV;
     }
=20
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -41,7 +41,8 @@ static void iommu_dump_p2m_table(unsigne
  *   no-intremap                Disable VT-d Interrupt Remapping
  */
 custom_param("iommu", parse_iommu_param);
-bool_t __read_mostly iommu_enabled =3D 1;
+bool_t __initdata iommu_enable =3D 1;
+bool_t __read_mostly iommu_enabled;
 bool_t __read_mostly force_iommu;
 bool_t __initdata iommu_dom0_strict;
 bool_t __read_mostly iommu_verbose;
@@ -77,7 +78,7 @@ static void __init parse_iommu_param(cha
             *ss =3D '\0';
=20
         if ( !parse_bool(s) )
-            iommu_enabled =3D 0;
+            iommu_enable =3D 0;
         else if ( !strcmp(s, "force") || !strcmp(s, "required") )
             force_iommu =3D val;
         else if ( !strcmp(s, "workaround_bios_bug") )
@@ -395,7 +396,7 @@ int __init iommu_setup(void)
     if ( iommu_dom0_strict )
         iommu_passthrough =3D 0;
=20
-    if ( iommu_enabled )
+    if ( iommu_enable )
     {
         rc =3D iommu_hardware_setup();
         iommu_enabled =3D (rc =3D=3D 0);
@@ -409,8 +410,6 @@ int __init iommu_setup(void)
     if ( !iommu_enabled )
     {
         iommu_snoop =3D 0;
-        iommu_qinval =3D 0;
-        iommu_intremap =3D 0;
         iommu_passthrough =3D 0;
         iommu_dom0_strict =3D 0;
     }
@@ -419,6 +418,8 @@ int __init iommu_setup(void)
         printk(" - Dom0 mode: %s\n",
                iommu_passthrough ? "Passthrough" :
                iommu_dom0_strict ? "Strict" : "Relaxed");
+    else if ( iommu_intremap )
+        printk("Interrupt remapping enabled\n");
=20
     return rc;
 }
--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -744,7 +744,7 @@ static int __init acpi_parse_dmar(struct
     dmar =3D (struct acpi_table_dmar *)table;
     dmar_flags =3D dmar->flags;
=20
-    if ( !iommu_enabled )
+    if ( !iommu_enable && !iommu_intremap )
     {
         ret =3D -EINVAL;
         goto out;
--- a/xen/drivers/passthrough/vtd/intremap.c
+++ b/xen/drivers/passthrough/vtd/intremap.c
@@ -149,8 +149,7 @@ int iommu_supports_eim(void)
     struct acpi_drhd_unit *drhd;
     int apic;
=20
-    if ( !iommu_enabled || !iommu_qinval || !iommu_intremap ||
-         list_empty(&acpi_drhd_units) )
+    if ( !iommu_qinval || !iommu_intremap || list_empty(&acpi_drhd_units) =
)
         return 0;
=20
     /* We MUST have a DRHD unit for each IOAPIC. */
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -2086,7 +2086,10 @@ int __init intel_vtd_setup(void)
     int ret;
=20
     if ( list_empty(&acpi_drhd_units) )
-        return -ENODEV;
+    {
+        ret =3D -ENODEV;
+        goto error;
+    }
=20
     platform_quirks_init();
=20
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -26,7 +26,7 @@
 #include 
 #include 
=20
-extern bool_t iommu_enabled;
+extern bool_t iommu_enable, iommu_enabled;
 extern bool_t force_iommu, iommu_verbose;
 extern bool_t iommu_workaround_bios_bug, iommu_passthrough;
 extern bool_t iommu_snoop, iommu_qinval, iommu_intremap;



--=__Part8EBF5B30.2__=
Content-Type: text/plain; name="IOMMU-defer-marking-enabled.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="IOMMU-defer-marking-enabled.patch"

IOMMU: keep disabled until iommu_setup() is called=0A=0AThe iommu is =
enabled by default when xen is booting and later disabled=0Ain iommu_setup(=
) when no iommu is present.=0A=0ABut under some circumstances iommu code =
can be called before=0Aiommu_setup() is processed. If there is no iommu =
available xen crashes.=0A=0AThis can happen for example when panic(...) is =
called as introduced=0Awith the patch "x86-64: detect processors subject =
to AMD erratum #121=0Aand refuse to boot" since xen 4.1.3, resulting =
in=0Afind_iommu_for_device() to be called in the context of=0Adisable_IO_AP=
IC() / __stop_this_cpu().=0A=0AThis patch fixes this by keeping the iommu =
disabled until iommu_setup()=0Ais entered.=0A=0AOriginally-by: Ronny =
Hegewald =0A=0AIn order for iommu_enable to be =
off initially, iommu_supports_eim()=0Amust not depend on it anymore, nor =
must acpi_parse_dmar(). The former=0Ain turn requires that iommu_intremap =
gets uncoupled from iommu_enabled=0A(in particular, failure during IOMMU =
setup should no longer result in=0Aiommu_intremap getting cleared by =
generic code; IOMMU specific code=0Acan still do so provided in can live =
with the consequences).=0A=0AThis could have the nice side effect of =
allowing to use "iommu=3Doff"=0Aeven when x2APIC was pre-enabled by the =
BIOS (in which case interrupt=0Aremapping is a requirement, but DMA =
translation [obviously] isn't), but=0Athat doesn't currently work (and =
hence x2apic_bsp_setup() forces the=0AIOMMU on rather than just interrupt =
remapping).=0A=0AFor consistency with VT-d, make the AMD IOMMU code also =
skip all ACPI=0Atable parsing when neither iommu_enable nor iommu_intremap =
are set.=0A=0ASigned-off-by: Jan Beulich =0A=0A--- =
a/xen/arch/x86/apic.c=0A+++ b/xen/arch/x86/apic.c=0A@@ -975,6 +975,8 @@ =
void __init x2apic_bsp_setup(void)=0A         goto restore_out;=0A     =
}=0A =0A+    force_iommu =3D 1;=0A+=0A     genapic =3D apic_x2apic_probe();=
=0A     printk("Switched to APIC driver %s.\n", genapic->name);=0A =0A--- =
a/xen/drivers/passthrough/amd/pci_amd_iommu.c=0A+++ b/xen/drivers/passthrou=
gh/amd/pci_amd_iommu.c=0A@@ -164,9 +164,13 @@ int __init amd_iov_detect(voi=
d)=0A {=0A     INIT_LIST_HEAD(&amd_iommu_head);=0A =0A+    if ( !iommu_enab=
le && !iommu_intremap )=0A+        return 0;=0A+=0A     if ( (amd_iommu_det=
ect_acpi() !=3D0) || (iommu_found() =3D=3D 0) )=0A     {=0A         =
printk("AMD-Vi: IOMMU not found!\n");=0A+        iommu_intremap =3D 0;=0A  =
       return -ENODEV;=0A     }=0A =0A--- a/xen/drivers/passthrough/iommu.c=
=0A+++ b/xen/drivers/passthrough/iommu.c=0A@@ -41,7 +41,8 @@ static void =
iommu_dump_p2m_table(unsigne=0A  *   no-intremap                Disable =
VT-d Interrupt Remapping=0A  */=0A custom_param("iommu", parse_iommu_param)=
;=0A-bool_t __read_mostly iommu_enabled =3D 1;=0A+bool_t __initdata =
iommu_enable =3D 1;=0A+bool_t __read_mostly iommu_enabled;=0A bool_t =
__read_mostly force_iommu;=0A bool_t __initdata iommu_dom0_strict;=0A =
bool_t __read_mostly iommu_verbose;=0A@@ -77,7 +78,7 @@ static void __init =
parse_iommu_param(cha=0A             *ss =3D '\0';=0A =0A         if ( =
!parse_bool(s) )=0A-            iommu_enabled =3D 0;=0A+            =
iommu_enable =3D 0;=0A         else if ( !strcmp(s, "force") || !strcmp(s, =
"required") )=0A             force_iommu =3D val;=0A         else if ( =
!strcmp(s, "workaround_bios_bug") )=0A@@ -395,7 +396,7 @@ int __init =
iommu_setup(void)=0A     if ( iommu_dom0_strict )=0A         iommu_passthro=
ugh =3D 0;=0A =0A-    if ( iommu_enabled )=0A+    if ( iommu_enable )=0A   =
  {=0A         rc =3D iommu_hardware_setup();=0A         iommu_enabled =3D =
(rc =3D=3D 0);=0A@@ -409,8 +410,6 @@ int __init iommu_setup(void)=0A     =
if ( !iommu_enabled )=0A     {=0A         iommu_snoop =3D 0;=0A-        =
iommu_qinval =3D 0;=0A-        iommu_intremap =3D 0;=0A         iommu_passt=
hrough =3D 0;=0A         iommu_dom0_strict =3D 0;=0A     }=0A@@ -419,6 =
+418,8 @@ int __init iommu_setup(void)=0A         printk(" - Dom0 mode: =
%s\n",=0A                iommu_passthrough ? "Passthrough" :=0A            =
    iommu_dom0_strict ? "Strict" : "Relaxed");=0A+    else if ( iommu_intre=
map )=0A+        printk("Interrupt remapping enabled\n");=0A =0A     =
return rc;=0A }=0A--- a/xen/drivers/passthrough/vtd/dmar.c=0A+++ b/xen/driv=
ers/passthrough/vtd/dmar.c=0A@@ -744,7 +744,7 @@ static int __init =
acpi_parse_dmar(struct=0A     dmar =3D (struct acpi_table_dmar *)table;=0A =
    dmar_flags =3D dmar->flags;=0A =0A-    if ( !iommu_enabled )=0A+    if =
( !iommu_enable && !iommu_intremap )=0A     {=0A         ret =3D =
-EINVAL;=0A         goto out;=0A--- a/xen/drivers/passthrough/vtd/intremap.=
c=0A+++ b/xen/drivers/passthrough/vtd/intremap.c=0A@@ -149,8 +149,7 @@ int =
iommu_supports_eim(void)=0A     struct acpi_drhd_unit *drhd;=0A     int =
apic;=0A =0A-    if ( !iommu_enabled || !iommu_qinval || !iommu_intremap =
||=0A-         list_empty(&acpi_drhd_units) )=0A+    if ( !iommu_qinval || =
!iommu_intremap || list_empty(&acpi_drhd_units) )=0A         return 0;=0A =
=0A     /* We MUST have a DRHD unit for each IOAPIC. */=0A--- a/xen/drivers=
/passthrough/vtd/iommu.c=0A+++ b/xen/drivers/passthrough/vtd/iommu.c=0A@@ =
-2086,7 +2086,10 @@ int __init intel_vtd_setup(void)=0A     int ret;=0A =
=0A     if ( list_empty(&acpi_drhd_units) )=0A-        return -ENODEV;=0A+ =
   {=0A+        ret =3D -ENODEV;=0A+        goto error;=0A+    }=0A =0A    =
 platform_quirks_init();=0A =0A--- a/xen/include/xen/iommu.h=0A+++ =
b/xen/include/xen/iommu.h=0A@@ -26,7 +26,7 @@=0A #include =0A #include =0A =0A-extern bool_t iommu_enabled;=0A+ex=
tern bool_t iommu_enable, iommu_enabled;=0A extern bool_t force_iommu, =
iommu_verbose;=0A extern bool_t iommu_workaround_bios_bug, iommu_passthroug=
h;=0A extern bool_t iommu_snoop, iommu_qinval, iommu_intremap;=0A
--=__Part8EBF5B30.2__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__Part8EBF5B30.2__=--


From xen-devel-bounces@lists.xen.org Wed Oct 24 15:50:15 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 15:50:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR3DQ-0001Sc-VE; Wed, 24 Oct 2012 15:49:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR3DP-0001SX-Vv
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 15:49:56 +0000
Received: from [85.158.137.99:23184] by server-6.bemta-3.messagelabs.com id
	32/D9-32375-32E08805; Wed, 24 Oct 2012 15:49:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1351093794!22918326!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30422 invoked from network); 24 Oct 2012 15:49:54 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-217.messagelabs.com with SMTP;
	24 Oct 2012 15:49:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 24 Oct 2012 16:52:15 +0100
Message-Id: <50882A4002000078000A4131@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 24 Oct 2012 16:49:52 +0100
From: "Jan Beulich" 
To: "xen-devel" 
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part8EBF5B30.2__="
Cc: Wei Wang , Ronny Hegewald ,
	xiantao.zhang@intel.com
Subject: [Xen-devel] [PATCH v3] IOMMU: keep disabled until iommu_setup() is
	called
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part8EBF5B30.2__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

The iommu is enabled by default when xen is booting and later disabled
in iommu_setup() when no iommu is present.

But under some circumstances iommu code can be called before
iommu_setup() is processed. If there is no iommu available xen crashes.

This can happen for example when panic(...) is called as introduced
with the patch "x86-64: detect processors subject to AMD erratum #121
and refuse to boot" since xen 4.1.3, resulting in
find_iommu_for_device() to be called in the context of
disable_IO_APIC() / __stop_this_cpu().

This patch fixes this by keeping the iommu disabled until iommu_setup()
is entered.

Originally-by: Ronny Hegewald 

In order for iommu_enable to be off initially, iommu_supports_eim()
must not depend on it anymore, nor must acpi_parse_dmar(). The former
in turn requires that iommu_intremap gets uncoupled from iommu_enabled
(in particular, failure during IOMMU setup should no longer result in
iommu_intremap getting cleared by generic code; IOMMU specific code
can still do so provided in can live with the consequences).

This could have the nice side effect of allowing to use "iommu=3Doff"
even when x2APIC was pre-enabled by the BIOS (in which case interrupt
remapping is a requirement, but DMA translation [obviously] isn't), but
that doesn't currently work (and hence x2apic_bsp_setup() forces the
IOMMU on rather than just interrupt remapping).

For consistency with VT-d, make the AMD IOMMU code also skip all ACPI
table parsing when neither iommu_enable nor iommu_intremap are set.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -975,6 +975,8 @@ void __init x2apic_bsp_setup(void)
         goto restore_out;
     }
=20
+    force_iommu =3D 1;
+
     genapic =3D apic_x2apic_probe();
     printk("Switched to APIC driver %s.\n", genapic->name);
=20
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -164,9 +164,13 @@ int __init amd_iov_detect(void)
 {
     INIT_LIST_HEAD(&amd_iommu_head);
=20
+    if ( !iommu_enable && !iommu_intremap )
+        return 0;
+
     if ( (amd_iommu_detect_acpi() !=3D0) || (iommu_found() =3D=3D 0) )
     {
         printk("AMD-Vi: IOMMU not found!\n");
+        iommu_intremap =3D 0;
         return -ENODEV;
     }
=20
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -41,7 +41,8 @@ static void iommu_dump_p2m_table(unsigne
  *   no-intremap                Disable VT-d Interrupt Remapping
  */
 custom_param("iommu", parse_iommu_param);
-bool_t __read_mostly iommu_enabled =3D 1;
+bool_t __initdata iommu_enable =3D 1;
+bool_t __read_mostly iommu_enabled;
 bool_t __read_mostly force_iommu;
 bool_t __initdata iommu_dom0_strict;
 bool_t __read_mostly iommu_verbose;
@@ -77,7 +78,7 @@ static void __init parse_iommu_param(cha
             *ss =3D '\0';
=20
         if ( !parse_bool(s) )
-            iommu_enabled =3D 0;
+            iommu_enable =3D 0;
         else if ( !strcmp(s, "force") || !strcmp(s, "required") )
             force_iommu =3D val;
         else if ( !strcmp(s, "workaround_bios_bug") )
@@ -395,7 +396,7 @@ int __init iommu_setup(void)
     if ( iommu_dom0_strict )
         iommu_passthrough =3D 0;
=20
-    if ( iommu_enabled )
+    if ( iommu_enable )
     {
         rc =3D iommu_hardware_setup();
         iommu_enabled =3D (rc =3D=3D 0);
@@ -409,8 +410,6 @@ int __init iommu_setup(void)
     if ( !iommu_enabled )
     {
         iommu_snoop =3D 0;
-        iommu_qinval =3D 0;
-        iommu_intremap =3D 0;
         iommu_passthrough =3D 0;
         iommu_dom0_strict =3D 0;
     }
@@ -419,6 +418,8 @@ int __init iommu_setup(void)
         printk(" - Dom0 mode: %s\n",
                iommu_passthrough ? "Passthrough" :
                iommu_dom0_strict ? "Strict" : "Relaxed");
+    else if ( iommu_intremap )
+        printk("Interrupt remapping enabled\n");
=20
     return rc;
 }
--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -744,7 +744,7 @@ static int __init acpi_parse_dmar(struct
     dmar =3D (struct acpi_table_dmar *)table;
     dmar_flags =3D dmar->flags;
=20
-    if ( !iommu_enabled )
+    if ( !iommu_enable && !iommu_intremap )
     {
         ret =3D -EINVAL;
         goto out;
--- a/xen/drivers/passthrough/vtd/intremap.c
+++ b/xen/drivers/passthrough/vtd/intremap.c
@@ -149,8 +149,7 @@ int iommu_supports_eim(void)
     struct acpi_drhd_unit *drhd;
     int apic;
=20
-    if ( !iommu_enabled || !iommu_qinval || !iommu_intremap ||
-         list_empty(&acpi_drhd_units) )
+    if ( !iommu_qinval || !iommu_intremap || list_empty(&acpi_drhd_units) =
)
         return 0;
=20
     /* We MUST have a DRHD unit for each IOAPIC. */
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -2086,7 +2086,10 @@ int __init intel_vtd_setup(void)
     int ret;
=20
     if ( list_empty(&acpi_drhd_units) )
-        return -ENODEV;
+    {
+        ret =3D -ENODEV;
+        goto error;
+    }
=20
     platform_quirks_init();
=20
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -26,7 +26,7 @@
 #include 
 #include 
=20
-extern bool_t iommu_enabled;
+extern bool_t iommu_enable, iommu_enabled;
 extern bool_t force_iommu, iommu_verbose;
 extern bool_t iommu_workaround_bios_bug, iommu_passthrough;
 extern bool_t iommu_snoop, iommu_qinval, iommu_intremap;



--=__Part8EBF5B30.2__=
Content-Type: text/plain; name="IOMMU-defer-marking-enabled.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="IOMMU-defer-marking-enabled.patch"

IOMMU: keep disabled until iommu_setup() is called=0A=0AThe iommu is =
enabled by default when xen is booting and later disabled=0Ain iommu_setup(=
) when no iommu is present.=0A=0ABut under some circumstances iommu code =
can be called before=0Aiommu_setup() is processed. If there is no iommu =
available xen crashes.=0A=0AThis can happen for example when panic(...) is =
called as introduced=0Awith the patch "x86-64: detect processors subject =
to AMD erratum #121=0Aand refuse to boot" since xen 4.1.3, resulting =
in=0Afind_iommu_for_device() to be called in the context of=0Adisable_IO_AP=
IC() / __stop_this_cpu().=0A=0AThis patch fixes this by keeping the iommu =
disabled until iommu_setup()=0Ais entered.=0A=0AOriginally-by: Ronny =
Hegewald =0A=0AIn order for iommu_enable to be =
off initially, iommu_supports_eim()=0Amust not depend on it anymore, nor =
must acpi_parse_dmar(). The former=0Ain turn requires that iommu_intremap =
gets uncoupled from iommu_enabled=0A(in particular, failure during IOMMU =
setup should no longer result in=0Aiommu_intremap getting cleared by =
generic code; IOMMU specific code=0Acan still do so provided in can live =
with the consequences).=0A=0AThis could have the nice side effect of =
allowing to use "iommu=3Doff"=0Aeven when x2APIC was pre-enabled by the =
BIOS (in which case interrupt=0Aremapping is a requirement, but DMA =
translation [obviously] isn't), but=0Athat doesn't currently work (and =
hence x2apic_bsp_setup() forces the=0AIOMMU on rather than just interrupt =
remapping).=0A=0AFor consistency with VT-d, make the AMD IOMMU code also =
skip all ACPI=0Atable parsing when neither iommu_enable nor iommu_intremap =
are set.=0A=0ASigned-off-by: Jan Beulich =0A=0A--- =
a/xen/arch/x86/apic.c=0A+++ b/xen/arch/x86/apic.c=0A@@ -975,6 +975,8 @@ =
void __init x2apic_bsp_setup(void)=0A         goto restore_out;=0A     =
}=0A =0A+    force_iommu =3D 1;=0A+=0A     genapic =3D apic_x2apic_probe();=
=0A     printk("Switched to APIC driver %s.\n", genapic->name);=0A =0A--- =
a/xen/drivers/passthrough/amd/pci_amd_iommu.c=0A+++ b/xen/drivers/passthrou=
gh/amd/pci_amd_iommu.c=0A@@ -164,9 +164,13 @@ int __init amd_iov_detect(voi=
d)=0A {=0A     INIT_LIST_HEAD(&amd_iommu_head);=0A =0A+    if ( !iommu_enab=
le && !iommu_intremap )=0A+        return 0;=0A+=0A     if ( (amd_iommu_det=
ect_acpi() !=3D0) || (iommu_found() =3D=3D 0) )=0A     {=0A         =
printk("AMD-Vi: IOMMU not found!\n");=0A+        iommu_intremap =3D 0;=0A  =
       return -ENODEV;=0A     }=0A =0A--- a/xen/drivers/passthrough/iommu.c=
=0A+++ b/xen/drivers/passthrough/iommu.c=0A@@ -41,7 +41,8 @@ static void =
iommu_dump_p2m_table(unsigne=0A  *   no-intremap                Disable =
VT-d Interrupt Remapping=0A  */=0A custom_param("iommu", parse_iommu_param)=
;=0A-bool_t __read_mostly iommu_enabled =3D 1;=0A+bool_t __initdata =
iommu_enable =3D 1;=0A+bool_t __read_mostly iommu_enabled;=0A bool_t =
__read_mostly force_iommu;=0A bool_t __initdata iommu_dom0_strict;=0A =
bool_t __read_mostly iommu_verbose;=0A@@ -77,7 +78,7 @@ static void __init =
parse_iommu_param(cha=0A             *ss =3D '\0';=0A =0A         if ( =
!parse_bool(s) )=0A-            iommu_enabled =3D 0;=0A+            =
iommu_enable =3D 0;=0A         else if ( !strcmp(s, "force") || !strcmp(s, =
"required") )=0A             force_iommu =3D val;=0A         else if ( =
!strcmp(s, "workaround_bios_bug") )=0A@@ -395,7 +396,7 @@ int __init =
iommu_setup(void)=0A     if ( iommu_dom0_strict )=0A         iommu_passthro=
ugh =3D 0;=0A =0A-    if ( iommu_enabled )=0A+    if ( iommu_enable )=0A   =
  {=0A         rc =3D iommu_hardware_setup();=0A         iommu_enabled =3D =
(rc =3D=3D 0);=0A@@ -409,8 +410,6 @@ int __init iommu_setup(void)=0A     =
if ( !iommu_enabled )=0A     {=0A         iommu_snoop =3D 0;=0A-        =
iommu_qinval =3D 0;=0A-        iommu_intremap =3D 0;=0A         iommu_passt=
hrough =3D 0;=0A         iommu_dom0_strict =3D 0;=0A     }=0A@@ -419,6 =
+418,8 @@ int __init iommu_setup(void)=0A         printk(" - Dom0 mode: =
%s\n",=0A                iommu_passthrough ? "Passthrough" :=0A            =
    iommu_dom0_strict ? "Strict" : "Relaxed");=0A+    else if ( iommu_intre=
map )=0A+        printk("Interrupt remapping enabled\n");=0A =0A     =
return rc;=0A }=0A--- a/xen/drivers/passthrough/vtd/dmar.c=0A+++ b/xen/driv=
ers/passthrough/vtd/dmar.c=0A@@ -744,7 +744,7 @@ static int __init =
acpi_parse_dmar(struct=0A     dmar =3D (struct acpi_table_dmar *)table;=0A =
    dmar_flags =3D dmar->flags;=0A =0A-    if ( !iommu_enabled )=0A+    if =
( !iommu_enable && !iommu_intremap )=0A     {=0A         ret =3D =
-EINVAL;=0A         goto out;=0A--- a/xen/drivers/passthrough/vtd/intremap.=
c=0A+++ b/xen/drivers/passthrough/vtd/intremap.c=0A@@ -149,8 +149,7 @@ int =
iommu_supports_eim(void)=0A     struct acpi_drhd_unit *drhd;=0A     int =
apic;=0A =0A-    if ( !iommu_enabled || !iommu_qinval || !iommu_intremap =
||=0A-         list_empty(&acpi_drhd_units) )=0A+    if ( !iommu_qinval || =
!iommu_intremap || list_empty(&acpi_drhd_units) )=0A         return 0;=0A =
=0A     /* We MUST have a DRHD unit for each IOAPIC. */=0A--- a/xen/drivers=
/passthrough/vtd/iommu.c=0A+++ b/xen/drivers/passthrough/vtd/iommu.c=0A@@ =
-2086,7 +2086,10 @@ int __init intel_vtd_setup(void)=0A     int ret;=0A =
=0A     if ( list_empty(&acpi_drhd_units) )=0A-        return -ENODEV;=0A+ =
   {=0A+        ret =3D -ENODEV;=0A+        goto error;=0A+    }=0A =0A    =
 platform_quirks_init();=0A =0A--- a/xen/include/xen/iommu.h=0A+++ =
b/xen/include/xen/iommu.h=0A@@ -26,7 +26,7 @@=0A #include =0A #include =0A =0A-extern bool_t iommu_enabled;=0A+ex=
tern bool_t iommu_enable, iommu_enabled;=0A extern bool_t force_iommu, =
iommu_verbose;=0A extern bool_t iommu_workaround_bios_bug, iommu_passthroug=
h;=0A extern bool_t iommu_snoop, iommu_qinval, iommu_intremap;=0A
--=__Part8EBF5B30.2__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__Part8EBF5B30.2__=--


From xen-devel-bounces@lists.xen.org Wed Oct 24 15:57:26 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 15:57:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR3KP-0001ca-Sw; Wed, 24 Oct 2012 15:57:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR3KO-0001cV-EH
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 15:57:08 +0000
Received: from [85.158.139.211:52968] by server-7.bemta-5.messagelabs.com id
	03/E5-23102-3DF08805; Wed, 24 Oct 2012 15:57:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1351094226!23111614!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28155 invoked from network); 24 Oct 2012 15:57:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-206.messagelabs.com with SMTP;
	24 Oct 2012 15:57:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 24 Oct 2012 16:59:28 +0100
Message-Id: <50882BF002000078000A4153@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 24 Oct 2012 16:57:04 +0100
From: "Jan Beulich" 
To: "Wei Wang" ,,
	"xen-devel" 
References: <50882A4002000078000A4131@nat28.tlf.novell.com>
In-Reply-To: <50882A4002000078000A4131@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ronny Hegewald 
Subject: Re: [Xen-devel] [PATCH v3] IOMMU: keep disabled until iommu_setup()
 is called
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 24.10.12 at 17:49, "Jan Beulich"  wrote:
> The iommu is enabled by default when xen is booting and later disabled
> in iommu_setup() when no iommu is present.
> 
> But under some circumstances iommu code can be called before
> iommu_setup() is processed. If there is no iommu available xen crashes.
> 
> This can happen for example when panic(...) is called as introduced
> with the patch "x86-64: detect processors subject to AMD erratum #121
> and refuse to boot" since xen 4.1.3, resulting in
> find_iommu_for_device() to be called in the context of
> disable_IO_APIC() / __stop_this_cpu().
> 
> This patch fixes this by keeping the iommu disabled until iommu_setup()
> is entered.
> 
> Originally-by: Ronny Hegewald 
> 
> In order for iommu_enable to be off initially, iommu_supports_eim()
> must not depend on it anymore, nor must acpi_parse_dmar(). The former
> in turn requires that iommu_intremap gets uncoupled from iommu_enabled
> (in particular, failure during IOMMU setup should no longer result in
> iommu_intremap getting cleared by generic code; IOMMU specific code
> can still do so provided in can live with the consequences).
> 
> This could have the nice side effect of allowing to use "iommu=off"
> even when x2APIC was pre-enabled by the BIOS (in which case interrupt
> remapping is a requirement, but DMA translation [obviously] isn't), but
> that doesn't currently work (and hence x2apic_bsp_setup() forces the
> IOMMU on rather than just interrupt remapping).
> 
> For consistency with VT-d, make the AMD IOMMU code also skip all ACPI
> table parsing when neither iommu_enable nor iommu_intremap are set.
> 
> Signed-off-by: Jan Beulich 
> 
> --- a/xen/arch/x86/apic.c
> +++ b/xen/arch/x86/apic.c
> @@ -975,6 +975,8 @@ void __init x2apic_bsp_setup(void)
>          goto restore_out;
>      }
>  
> +    force_iommu = 1;
> +
>      genapic = apic_x2apic_probe();
>      printk("Switched to APIC driver %s.\n", genapic->name);
>  
> --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
> +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
> @@ -164,9 +164,13 @@ int __init amd_iov_detect(void)
>  {
>      INIT_LIST_HEAD(&amd_iommu_head);
>  
> +    if ( !iommu_enable && !iommu_intremap )
> +        return 0;
> +
>      if ( (amd_iommu_detect_acpi() !=0) || (iommu_found() == 0) )
>      {
>          printk("AMD-Vi: IOMMU not found!\n");
> +        iommu_intremap = 0;
>          return -ENODEV;
>      }
>  
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -41,7 +41,8 @@ static void iommu_dump_p2m_table(unsigne
>   *   no-intremap                Disable VT-d Interrupt Remapping
>   */
>  custom_param("iommu", parse_iommu_param);
> -bool_t __read_mostly iommu_enabled = 1;
> +bool_t __initdata iommu_enable = 1;
> +bool_t __read_mostly iommu_enabled;
>  bool_t __read_mostly force_iommu;
>  bool_t __initdata iommu_dom0_strict;
>  bool_t __read_mostly iommu_verbose;
> @@ -77,7 +78,7 @@ static void __init parse_iommu_param(cha
>              *ss = '\0';
>  
>          if ( !parse_bool(s) )
> -            iommu_enabled = 0;
> +            iommu_enable = 0;
>          else if ( !strcmp(s, "force") || !strcmp(s, "required") )
>              force_iommu = val;
>          else if ( !strcmp(s, "workaround_bios_bug") )
> @@ -395,7 +396,7 @@ int __init iommu_setup(void)
>      if ( iommu_dom0_strict )
>          iommu_passthrough = 0;
>  
> -    if ( iommu_enabled )
> +    if ( iommu_enable )
>      {
>          rc = iommu_hardware_setup();
>          iommu_enabled = (rc == 0);
> @@ -409,8 +410,6 @@ int __init iommu_setup(void)
>      if ( !iommu_enabled )
>      {
>          iommu_snoop = 0;
> -        iommu_qinval = 0;
> -        iommu_intremap = 0;
>          iommu_passthrough = 0;
>          iommu_dom0_strict = 0;
>      }
> @@ -419,6 +418,8 @@ int __init iommu_setup(void)
>          printk(" - Dom0 mode: %s\n",
>                 iommu_passthrough ? "Passthrough" :
>                 iommu_dom0_strict ? "Strict" : "Relaxed");
> +    else if ( iommu_intremap )
> +        printk("Interrupt remapping enabled\n");
>  
>      return rc;
>  }

Please consider this one hunk absent for the purposes of reviewing
(it's a leftover from the previous failed attempt to make interrupt
remapping work without the full IOMMU enabling and without much
more intrusive changes), I already dropped it from what I hope to
commit eventually.

Jan

> --- a/xen/drivers/passthrough/vtd/dmar.c
> +++ b/xen/drivers/passthrough/vtd/dmar.c
> @@ -744,7 +744,7 @@ static int __init acpi_parse_dmar(struct
>      dmar = (struct acpi_table_dmar *)table;
>      dmar_flags = dmar->flags;
>  
> -    if ( !iommu_enabled )
> +    if ( !iommu_enable && !iommu_intremap )
>      {
>          ret = -EINVAL;
>          goto out;
> --- a/xen/drivers/passthrough/vtd/intremap.c
> +++ b/xen/drivers/passthrough/vtd/intremap.c
> @@ -149,8 +149,7 @@ int iommu_supports_eim(void)
>      struct acpi_drhd_unit *drhd;
>      int apic;
>  
> -    if ( !iommu_enabled || !iommu_qinval || !iommu_intremap ||
> -         list_empty(&acpi_drhd_units) )
> +    if ( !iommu_qinval || !iommu_intremap || list_empty(&acpi_drhd_units) )
>          return 0;
>  
>      /* We MUST have a DRHD unit for each IOAPIC. */
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -2086,7 +2086,10 @@ int __init intel_vtd_setup(void)
>      int ret;
>  
>      if ( list_empty(&acpi_drhd_units) )
> -        return -ENODEV;
> +    {
> +        ret = -ENODEV;
> +        goto error;
> +    }
>  
>      platform_quirks_init();
>  
> --- a/xen/include/xen/iommu.h
> +++ b/xen/include/xen/iommu.h
> @@ -26,7 +26,7 @@
>  #include 
>  #include 
>  
> -extern bool_t iommu_enabled;
> +extern bool_t iommu_enable, iommu_enabled;
>  extern bool_t force_iommu, iommu_verbose;
>  extern bool_t iommu_workaround_bios_bug, iommu_passthrough;
>  extern bool_t iommu_snoop, iommu_qinval, iommu_intremap;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 15:57:26 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 15:57:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR3KP-0001ca-Sw; Wed, 24 Oct 2012 15:57:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR3KO-0001cV-EH
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 15:57:08 +0000
Received: from [85.158.139.211:52968] by server-7.bemta-5.messagelabs.com id
	03/E5-23102-3DF08805; Wed, 24 Oct 2012 15:57:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1351094226!23111614!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28155 invoked from network); 24 Oct 2012 15:57:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-206.messagelabs.com with SMTP;
	24 Oct 2012 15:57:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 24 Oct 2012 16:59:28 +0100
Message-Id: <50882BF002000078000A4153@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 24 Oct 2012 16:57:04 +0100
From: "Jan Beulich" 
To: "Wei Wang" ,,
	"xen-devel" 
References: <50882A4002000078000A4131@nat28.tlf.novell.com>
In-Reply-To: <50882A4002000078000A4131@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ronny Hegewald 
Subject: Re: [Xen-devel] [PATCH v3] IOMMU: keep disabled until iommu_setup()
 is called
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 24.10.12 at 17:49, "Jan Beulich"  wrote:
> The iommu is enabled by default when xen is booting and later disabled
> in iommu_setup() when no iommu is present.
> 
> But under some circumstances iommu code can be called before
> iommu_setup() is processed. If there is no iommu available xen crashes.
> 
> This can happen for example when panic(...) is called as introduced
> with the patch "x86-64: detect processors subject to AMD erratum #121
> and refuse to boot" since xen 4.1.3, resulting in
> find_iommu_for_device() to be called in the context of
> disable_IO_APIC() / __stop_this_cpu().
> 
> This patch fixes this by keeping the iommu disabled until iommu_setup()
> is entered.
> 
> Originally-by: Ronny Hegewald 
> 
> In order for iommu_enable to be off initially, iommu_supports_eim()
> must not depend on it anymore, nor must acpi_parse_dmar(). The former
> in turn requires that iommu_intremap gets uncoupled from iommu_enabled
> (in particular, failure during IOMMU setup should no longer result in
> iommu_intremap getting cleared by generic code; IOMMU specific code
> can still do so provided in can live with the consequences).
> 
> This could have the nice side effect of allowing to use "iommu=off"
> even when x2APIC was pre-enabled by the BIOS (in which case interrupt
> remapping is a requirement, but DMA translation [obviously] isn't), but
> that doesn't currently work (and hence x2apic_bsp_setup() forces the
> IOMMU on rather than just interrupt remapping).
> 
> For consistency with VT-d, make the AMD IOMMU code also skip all ACPI
> table parsing when neither iommu_enable nor iommu_intremap are set.
> 
> Signed-off-by: Jan Beulich 
> 
> --- a/xen/arch/x86/apic.c
> +++ b/xen/arch/x86/apic.c
> @@ -975,6 +975,8 @@ void __init x2apic_bsp_setup(void)
>          goto restore_out;
>      }
>  
> +    force_iommu = 1;
> +
>      genapic = apic_x2apic_probe();
>      printk("Switched to APIC driver %s.\n", genapic->name);
>  
> --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
> +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
> @@ -164,9 +164,13 @@ int __init amd_iov_detect(void)
>  {
>      INIT_LIST_HEAD(&amd_iommu_head);
>  
> +    if ( !iommu_enable && !iommu_intremap )
> +        return 0;
> +
>      if ( (amd_iommu_detect_acpi() !=0) || (iommu_found() == 0) )
>      {
>          printk("AMD-Vi: IOMMU not found!\n");
> +        iommu_intremap = 0;
>          return -ENODEV;
>      }
>  
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -41,7 +41,8 @@ static void iommu_dump_p2m_table(unsigne
>   *   no-intremap                Disable VT-d Interrupt Remapping
>   */
>  custom_param("iommu", parse_iommu_param);
> -bool_t __read_mostly iommu_enabled = 1;
> +bool_t __initdata iommu_enable = 1;
> +bool_t __read_mostly iommu_enabled;
>  bool_t __read_mostly force_iommu;
>  bool_t __initdata iommu_dom0_strict;
>  bool_t __read_mostly iommu_verbose;
> @@ -77,7 +78,7 @@ static void __init parse_iommu_param(cha
>              *ss = '\0';
>  
>          if ( !parse_bool(s) )
> -            iommu_enabled = 0;
> +            iommu_enable = 0;
>          else if ( !strcmp(s, "force") || !strcmp(s, "required") )
>              force_iommu = val;
>          else if ( !strcmp(s, "workaround_bios_bug") )
> @@ -395,7 +396,7 @@ int __init iommu_setup(void)
>      if ( iommu_dom0_strict )
>          iommu_passthrough = 0;
>  
> -    if ( iommu_enabled )
> +    if ( iommu_enable )
>      {
>          rc = iommu_hardware_setup();
>          iommu_enabled = (rc == 0);
> @@ -409,8 +410,6 @@ int __init iommu_setup(void)
>      if ( !iommu_enabled )
>      {
>          iommu_snoop = 0;
> -        iommu_qinval = 0;
> -        iommu_intremap = 0;
>          iommu_passthrough = 0;
>          iommu_dom0_strict = 0;
>      }
> @@ -419,6 +418,8 @@ int __init iommu_setup(void)
>          printk(" - Dom0 mode: %s\n",
>                 iommu_passthrough ? "Passthrough" :
>                 iommu_dom0_strict ? "Strict" : "Relaxed");
> +    else if ( iommu_intremap )
> +        printk("Interrupt remapping enabled\n");
>  
>      return rc;
>  }

Please consider this one hunk absent for the purposes of reviewing
(it's a leftover from the previous failed attempt to make interrupt
remapping work without the full IOMMU enabling and without much
more intrusive changes), I already dropped it from what I hope to
commit eventually.

Jan

> --- a/xen/drivers/passthrough/vtd/dmar.c
> +++ b/xen/drivers/passthrough/vtd/dmar.c
> @@ -744,7 +744,7 @@ static int __init acpi_parse_dmar(struct
>      dmar = (struct acpi_table_dmar *)table;
>      dmar_flags = dmar->flags;
>  
> -    if ( !iommu_enabled )
> +    if ( !iommu_enable && !iommu_intremap )
>      {
>          ret = -EINVAL;
>          goto out;
> --- a/xen/drivers/passthrough/vtd/intremap.c
> +++ b/xen/drivers/passthrough/vtd/intremap.c
> @@ -149,8 +149,7 @@ int iommu_supports_eim(void)
>      struct acpi_drhd_unit *drhd;
>      int apic;
>  
> -    if ( !iommu_enabled || !iommu_qinval || !iommu_intremap ||
> -         list_empty(&acpi_drhd_units) )
> +    if ( !iommu_qinval || !iommu_intremap || list_empty(&acpi_drhd_units) )
>          return 0;
>  
>      /* We MUST have a DRHD unit for each IOAPIC. */
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -2086,7 +2086,10 @@ int __init intel_vtd_setup(void)
>      int ret;
>  
>      if ( list_empty(&acpi_drhd_units) )
> -        return -ENODEV;
> +    {
> +        ret = -ENODEV;
> +        goto error;
> +    }
>  
>      platform_quirks_init();
>  
> --- a/xen/include/xen/iommu.h
> +++ b/xen/include/xen/iommu.h
> @@ -26,7 +26,7 @@
>  #include 
>  #include 
>  
> -extern bool_t iommu_enabled;
> +extern bool_t iommu_enable, iommu_enabled;
>  extern bool_t force_iommu, iommu_verbose;
>  extern bool_t iommu_workaround_bios_bug, iommu_passthrough;
>  extern bool_t iommu_snoop, iommu_qinval, iommu_intremap;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 16:00:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 16:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR3Mz-0001j9-F4; Wed, 24 Oct 2012 15:59:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TR3My-0001j2-08
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 15:59:48 +0000
Received: from [85.158.139.83:52659] by server-14.bemta-5.messagelabs.com id
	51/EA-21768-37018805; Wed, 24 Oct 2012 15:59:47 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-182.messagelabs.com!1351094386!36606038!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 878 invoked from network); 24 Oct 2012 15:59:46 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Oct 2012 15:59:46 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TR3Mv-000CCi-JI; Wed, 24 Oct 2012 15:59:45 +0000
Date: Wed, 24 Oct 2012 16:59:45 +0100
From: Tim Deegan 
To: Stefano Stabellini 
Message-ID: <20121024155945.GD39126@ocelot.phlegethon.org>
References: 
	<1351091027-20740-6-git-send-email-stefano.stabellini@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1351091027-20740-6-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 6/7] xen/arm: flush D-cache and I-cache when
	appropriate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 16:03 +0100 on 24 Oct (1351094626), Stefano Stabellini wrote:
> - invalidate tlb after setting WXN;
> - flush D-cache and I-cache after relocation;
> - flush D-cache after writing to smp_up_cpu;
> - flush TLB before changing HTTBR;
> - flush I-cache after changing HTTBR;
> - flush I-cache and branch predictor after writing Xen text ptes.
> 
> Signed-off-by: Stefano Stabellini 

> @@ -244,10 +245,18 @@ void __init setup_pagetables(unsigned long boot_phys_offset, paddr_t xen_paddr)
>  
>      /* Change pagetables to the copy in the relocated Xen */
>      boot_httbr = (unsigned long) xen_pgtable + phys_offset;
> +    flush_xen_dcache_va((unsigned long)&boot_httbr);
> +    for ( i = 0; i < _end - _start; i += cacheline_size )
> +        flush_xen_dcache_va(dest_va + i);
> +    flush_xen_text_tlb();
> +
>      asm volatile (
> +        "dsb;"                        /* Ensure visibility of HTTBR update */

That comment should be changed -- this dsb is to make sure all the PT
changes are completed, right?

>          STORE_CP64(0, HTTBR)          /* Change translation base */
>          "dsb;"                        /* Ensure visibility of HTTBR update */
> +        "isb;"
>          STORE_CP32(0, TLBIALLH)       /* Flush hypervisor TLB */
> +        STORE_CP32(0, ICIALLU)        /* Flush I-cache */
>          STORE_CP32(0, BPIALL)         /* Flush branch predictor */
>          "dsb;"                        /* Ensure completion of TLB+BP flush */
>          "isb;"

> diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
> index 9511c45..7d70d8c 100644
> --- a/xen/include/asm-arm/page.h
> +++ b/xen/include/asm-arm/page.h
> @@ -232,13 +232,26 @@ static inline lpae_t mfn_to_p2m_entry(unsigned long mfn, unsigned int mattr)
>  static inline void write_pte(lpae_t *p, lpae_t pte)
>  {
>      asm volatile (
> +        "dsb;"

I guess this is to make sure all writes that used the old mapping have
completed?  Can you add a comment?

>          /* Safely write the entry (STRD is atomic on CPUs that support LPAE) */
>          "strd %0, %H0, [%1];"
> +        "dsb;"
>          /* Push this cacheline to the PoC so the rest of the system sees it. */
>          STORE_CP32(1, DCCMVAC)
> +        "isb;"

This is for code modifications, right?  I think we can drop it, and have
all the paths that modify text mappings do explicit isb()s there -- the
vast majority of PTE writes don't need it. 

>          : : "r" (pte.bits), "r" (p) : "memory");
>  }
>  
> +static inline void flush_xen_dcache_va(unsigned long va)

Three of the four users of this function cast their arguments from
pointer types - maybe it should take a void * instead?.

> +{
> +    register unsigned long r0 asm ("r0") = va;

I don't think this is necessary - why not just pass va directly to the
inline asm?  We don't care what register it's in (and if we did I'm not
convinced this would guarantee it was r0).

> +    asm volatile (
> +        "dsb;"
> +        STORE_CP32(0, DCCMVAC)
> +        "isb;"
> +        : : "r" (r0) : "memory");

Does this need a 'memory' clobber?  Can we get away with just saying it
consumes *va as an input?  All we need to be sure of is that the
particular thing we're flushing has been written out; no need to stop
any other optimizations.

I guess it might need to be re-cast as a macro so the compiler knows how
big *va is?

Tim.

> +}
> +
>  /*
>   * Flush all hypervisor mappings from the TLB and branch predictor.
>   * This is needed after changing Xen code mappings. 
> @@ -249,6 +262,7 @@ static inline void flush_xen_text_tlb(void)
>      asm volatile (
>          "dsb;"                        /* Ensure visibility of PTE writes */
>          STORE_CP32(0, TLBIALLH)       /* Flush hypervisor TLB */
> +        STORE_CP32(0, ICIALLU)        /* Flush I-cache */
>          STORE_CP32(0, BPIALL)         /* Flush branch predictor */
>          "dsb;"                        /* Ensure completion of TLB+BP flush */
>          "isb;"
> -- 
> 1.7.2.5
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 16:00:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 16:00:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR3Mz-0001j9-F4; Wed, 24 Oct 2012 15:59:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TR3My-0001j2-08
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 15:59:48 +0000
Received: from [85.158.139.83:52659] by server-14.bemta-5.messagelabs.com id
	51/EA-21768-37018805; Wed, 24 Oct 2012 15:59:47 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-182.messagelabs.com!1351094386!36606038!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 878 invoked from network); 24 Oct 2012 15:59:46 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Oct 2012 15:59:46 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TR3Mv-000CCi-JI; Wed, 24 Oct 2012 15:59:45 +0000
Date: Wed, 24 Oct 2012 16:59:45 +0100
From: Tim Deegan 
To: Stefano Stabellini 
Message-ID: <20121024155945.GD39126@ocelot.phlegethon.org>
References: 
	<1351091027-20740-6-git-send-email-stefano.stabellini@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1351091027-20740-6-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 6/7] xen/arm: flush D-cache and I-cache when
	appropriate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 16:03 +0100 on 24 Oct (1351094626), Stefano Stabellini wrote:
> - invalidate tlb after setting WXN;
> - flush D-cache and I-cache after relocation;
> - flush D-cache after writing to smp_up_cpu;
> - flush TLB before changing HTTBR;
> - flush I-cache after changing HTTBR;
> - flush I-cache and branch predictor after writing Xen text ptes.
> 
> Signed-off-by: Stefano Stabellini 

> @@ -244,10 +245,18 @@ void __init setup_pagetables(unsigned long boot_phys_offset, paddr_t xen_paddr)
>  
>      /* Change pagetables to the copy in the relocated Xen */
>      boot_httbr = (unsigned long) xen_pgtable + phys_offset;
> +    flush_xen_dcache_va((unsigned long)&boot_httbr);
> +    for ( i = 0; i < _end - _start; i += cacheline_size )
> +        flush_xen_dcache_va(dest_va + i);
> +    flush_xen_text_tlb();
> +
>      asm volatile (
> +        "dsb;"                        /* Ensure visibility of HTTBR update */

That comment should be changed -- this dsb is to make sure all the PT
changes are completed, right?

>          STORE_CP64(0, HTTBR)          /* Change translation base */
>          "dsb;"                        /* Ensure visibility of HTTBR update */
> +        "isb;"
>          STORE_CP32(0, TLBIALLH)       /* Flush hypervisor TLB */
> +        STORE_CP32(0, ICIALLU)        /* Flush I-cache */
>          STORE_CP32(0, BPIALL)         /* Flush branch predictor */
>          "dsb;"                        /* Ensure completion of TLB+BP flush */
>          "isb;"

> diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
> index 9511c45..7d70d8c 100644
> --- a/xen/include/asm-arm/page.h
> +++ b/xen/include/asm-arm/page.h
> @@ -232,13 +232,26 @@ static inline lpae_t mfn_to_p2m_entry(unsigned long mfn, unsigned int mattr)
>  static inline void write_pte(lpae_t *p, lpae_t pte)
>  {
>      asm volatile (
> +        "dsb;"

I guess this is to make sure all writes that used the old mapping have
completed?  Can you add a comment?

>          /* Safely write the entry (STRD is atomic on CPUs that support LPAE) */
>          "strd %0, %H0, [%1];"
> +        "dsb;"
>          /* Push this cacheline to the PoC so the rest of the system sees it. */
>          STORE_CP32(1, DCCMVAC)
> +        "isb;"

This is for code modifications, right?  I think we can drop it, and have
all the paths that modify text mappings do explicit isb()s there -- the
vast majority of PTE writes don't need it. 

>          : : "r" (pte.bits), "r" (p) : "memory");
>  }
>  
> +static inline void flush_xen_dcache_va(unsigned long va)

Three of the four users of this function cast their arguments from
pointer types - maybe it should take a void * instead?.

> +{
> +    register unsigned long r0 asm ("r0") = va;

I don't think this is necessary - why not just pass va directly to the
inline asm?  We don't care what register it's in (and if we did I'm not
convinced this would guarantee it was r0).

> +    asm volatile (
> +        "dsb;"
> +        STORE_CP32(0, DCCMVAC)
> +        "isb;"
> +        : : "r" (r0) : "memory");

Does this need a 'memory' clobber?  Can we get away with just saying it
consumes *va as an input?  All we need to be sure of is that the
particular thing we're flushing has been written out; no need to stop
any other optimizations.

I guess it might need to be re-cast as a macro so the compiler knows how
big *va is?

Tim.

> +}
> +
>  /*
>   * Flush all hypervisor mappings from the TLB and branch predictor.
>   * This is needed after changing Xen code mappings. 
> @@ -249,6 +262,7 @@ static inline void flush_xen_text_tlb(void)
>      asm volatile (
>          "dsb;"                        /* Ensure visibility of PTE writes */
>          STORE_CP32(0, TLBIALLH)       /* Flush hypervisor TLB */
> +        STORE_CP32(0, ICIALLU)        /* Flush I-cache */
>          STORE_CP32(0, BPIALL)         /* Flush branch predictor */
>          "dsb;"                        /* Ensure completion of TLB+BP flush */
>          "isb;"
> -- 
> 1.7.2.5
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 16:01:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 16:01:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR3O3-0002F2-3D; Wed, 24 Oct 2012 16:00:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR3O1-0002Eq-R1
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 16:00:54 +0000
Received: from [85.158.143.35:4479] by server-2.bemta-4.messagelabs.com id
	53/A2-22268-4B018805; Wed, 24 Oct 2012 16:00:52 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1351094451!12824605!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18115 invoked from network); 24 Oct 2012 16:00:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 16:00:52 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15363516"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 16:00:16 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 24 Oct 2012 17:00:16 +0100
Date: Wed, 24 Oct 2012 16:59:46 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Tim Deegan 
In-Reply-To: <20121024153809.GC39126@ocelot.phlegethon.org>
Message-ID: 
References: 
	<1351091027-20740-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<20121024153809.GC39126@ocelot.phlegethon.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	Ian Campbell ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 5/7] xen/arm: wake up secondary cpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 24 Oct 2012, Tim Deegan wrote:
> At 16:03 +0100 on 24 Oct (1351094625), Stefano Stabellini wrote:
> > Secondary cpus are held by the firmware until we send an IPI to them.
> > 
> > Signed-off-by: Stefano Stabellini 
> > ---
> >  xen/arch/arm/head.S        |    8 ++++++--
> >  xen/arch/arm/mode_switch.S |   31 +++++++++++++++++++++++++++++++
> >  2 files changed, 37 insertions(+), 2 deletions(-)
> > 
> > diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
> > index c784f4d..39c4774 100644
> > --- a/xen/arch/arm/head.S
> > +++ b/xen/arch/arm/head.S
> > @@ -79,12 +79,12 @@ start:
> >  	beq   boot_cpu               /* If we're CPU 0, boot now */
> >  
> >  	/* Non-boot CPUs wait here to be woken up one at a time. */
> > -1:	wfe
> > -	dsb
> > +1:	dsb
> >  	ldr   r0, =smp_up_cpu        /* VA of gate */
> >  	add   r0, r0, r10            /* PA of gate */
> >  	ldr   r1, [r0]               /* Which CPU is being booted? */
> >  	teq   r1, r12                /* Is it us? */
> > +	wfene
> 
> Shouldn't that be wf_i_ne?

Nope. We need wfe here, in fact the corresponding code is
xen/arch/arm/smpboot.c:make_cpus_ready that uses sev to wake the other
cpus up. The code running wfi on secondary cpus is actually in the
firmware.


> >  	bne   1b
> >  
> >  boot_cpu:
> > @@ -98,6 +98,10 @@ boot_cpu:
> >  	PRINT(" booting -\r\n")
> >  #endif
> >  
> > +	/* Wake up secondary cpus */
> > +	teq   r12, #0
> > +	bleq  kick_cpus
> > +
> >  	/* Check that this CPU has Hyp mode */
> >  	mrc   CP32(r0, ID_PFR1)
> >  	and   r0, r0, #0xf000        /* Bits 12-15 define virt extensions */
> > diff --git a/xen/arch/arm/mode_switch.S b/xen/arch/arm/mode_switch.S
> > index 83a682b..39d80e8 100644
> > --- a/xen/arch/arm/mode_switch.S
> > +++ b/xen/arch/arm/mode_switch.S
> > @@ -21,6 +21,37 @@
> >  #include 
> >  #include 
> >  
> > +/* XXX: Versatile Express specific code */
> > +/* wake up secondary cpus */
> > +.globl kick_cpus
> > +kick_cpus:
> > +    /* write start paddr to v2m sysreg FLAGSSET register */
> > +	ldr   r0, =0x1c010000 /* base V2M sysreg MMIO address */
> > +	add   r1, r0, #0x34   /* SYS_FLAGSCLR register */
> > +	dsb
> > +	mov   r2, #0xffffffff
> > +	str   r2, [r1]
> 
> Why not str r2, [r0, #0x34] and save the explicit add (and similarly below)?

Good idea


> > +	dsb
> > +	add   r1, r0, #0x30   /* SYS_FLAGSSET register */
> > +	ldr   r2, =start
> > +	add   r2, r2, r10
> > +	str   r2, [r1]
> > +	dsb
> > +	/* send an interrupt */
> > +	ldr   r0, =0x2c001000 /* base GICD MMIO address */
> > +	mov   r1, r0
> > +	mov   r2, #0x1        /* GICD_CTLR */
> > +	str   r2, [r1]        /* enable distributor */
> > +	add   r1, r0, #0xf00  /* GICD_SGIR */
> 
> These GIGD_* addresses and constants are already defined in config.h and
> gic.h; can you reuse those definitions?

Yep

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 16:01:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 16:01:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR3O3-0002F2-3D; Wed, 24 Oct 2012 16:00:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR3O1-0002Eq-R1
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 16:00:54 +0000
Received: from [85.158.143.35:4479] by server-2.bemta-4.messagelabs.com id
	53/A2-22268-4B018805; Wed, 24 Oct 2012 16:00:52 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1351094451!12824605!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18115 invoked from network); 24 Oct 2012 16:00:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 16:00:52 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15363516"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 16:00:16 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 24 Oct 2012 17:00:16 +0100
Date: Wed, 24 Oct 2012 16:59:46 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Tim Deegan 
In-Reply-To: <20121024153809.GC39126@ocelot.phlegethon.org>
Message-ID: 
References: 
	<1351091027-20740-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<20121024153809.GC39126@ocelot.phlegethon.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	Ian Campbell ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 5/7] xen/arm: wake up secondary cpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 24 Oct 2012, Tim Deegan wrote:
> At 16:03 +0100 on 24 Oct (1351094625), Stefano Stabellini wrote:
> > Secondary cpus are held by the firmware until we send an IPI to them.
> > 
> > Signed-off-by: Stefano Stabellini 
> > ---
> >  xen/arch/arm/head.S        |    8 ++++++--
> >  xen/arch/arm/mode_switch.S |   31 +++++++++++++++++++++++++++++++
> >  2 files changed, 37 insertions(+), 2 deletions(-)
> > 
> > diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
> > index c784f4d..39c4774 100644
> > --- a/xen/arch/arm/head.S
> > +++ b/xen/arch/arm/head.S
> > @@ -79,12 +79,12 @@ start:
> >  	beq   boot_cpu               /* If we're CPU 0, boot now */
> >  
> >  	/* Non-boot CPUs wait here to be woken up one at a time. */
> > -1:	wfe
> > -	dsb
> > +1:	dsb
> >  	ldr   r0, =smp_up_cpu        /* VA of gate */
> >  	add   r0, r0, r10            /* PA of gate */
> >  	ldr   r1, [r0]               /* Which CPU is being booted? */
> >  	teq   r1, r12                /* Is it us? */
> > +	wfene
> 
> Shouldn't that be wf_i_ne?

Nope. We need wfe here, in fact the corresponding code is
xen/arch/arm/smpboot.c:make_cpus_ready that uses sev to wake the other
cpus up. The code running wfi on secondary cpus is actually in the
firmware.


> >  	bne   1b
> >  
> >  boot_cpu:
> > @@ -98,6 +98,10 @@ boot_cpu:
> >  	PRINT(" booting -\r\n")
> >  #endif
> >  
> > +	/* Wake up secondary cpus */
> > +	teq   r12, #0
> > +	bleq  kick_cpus
> > +
> >  	/* Check that this CPU has Hyp mode */
> >  	mrc   CP32(r0, ID_PFR1)
> >  	and   r0, r0, #0xf000        /* Bits 12-15 define virt extensions */
> > diff --git a/xen/arch/arm/mode_switch.S b/xen/arch/arm/mode_switch.S
> > index 83a682b..39d80e8 100644
> > --- a/xen/arch/arm/mode_switch.S
> > +++ b/xen/arch/arm/mode_switch.S
> > @@ -21,6 +21,37 @@
> >  #include 
> >  #include 
> >  
> > +/* XXX: Versatile Express specific code */
> > +/* wake up secondary cpus */
> > +.globl kick_cpus
> > +kick_cpus:
> > +    /* write start paddr to v2m sysreg FLAGSSET register */
> > +	ldr   r0, =0x1c010000 /* base V2M sysreg MMIO address */
> > +	add   r1, r0, #0x34   /* SYS_FLAGSCLR register */
> > +	dsb
> > +	mov   r2, #0xffffffff
> > +	str   r2, [r1]
> 
> Why not str r2, [r0, #0x34] and save the explicit add (and similarly below)?

Good idea


> > +	dsb
> > +	add   r1, r0, #0x30   /* SYS_FLAGSSET register */
> > +	ldr   r2, =start
> > +	add   r2, r2, r10
> > +	str   r2, [r1]
> > +	dsb
> > +	/* send an interrupt */
> > +	ldr   r0, =0x2c001000 /* base GICD MMIO address */
> > +	mov   r1, r0
> > +	mov   r2, #0x1        /* GICD_CTLR */
> > +	str   r2, [r1]        /* enable distributor */
> > +	add   r1, r0, #0xf00  /* GICD_SGIR */
> 
> These GIGD_* addresses and constants are already defined in config.h and
> gic.h; can you reuse those definitions?

Yep

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 16:02:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 16:02:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR3PC-0002M7-Hx; Wed, 24 Oct 2012 16:02:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TR3PA-0002Lv-SI
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 16:02:04 +0000
Received: from [85.158.139.211:18561] by server-16.bemta-5.messagelabs.com id
	35/58-04786-CF018805; Wed, 24 Oct 2012 16:02:04 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-206.messagelabs.com!1351094523!22069688!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17614 invoked from network); 24 Oct 2012 16:02:03 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Oct 2012 16:02:03 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TR3P8-000CDs-Sl; Wed, 24 Oct 2012 16:02:02 +0000
Date: Wed, 24 Oct 2012 17:02:02 +0100
From: Tim Deegan 
To: Stefano Stabellini 
Message-ID: <20121024160202.GE39126@ocelot.phlegethon.org>
References: 
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, Ian Campbell 
Subject: Re: [Xen-devel] [PATCH 0/7] xen/arm: run on real hardware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 16:03 +0100 on 24 Oct (1351094597), Stefano Stabellini wrote:
> Hi all,
> this is a collection of fixes that I wrote trying to run Xen on a real
> Versatile Express Cortex A15 machine.

Congratulations on getting it running on real hardware!  That's great
progress.

I've replied to 2, 5 and 6.  For 1, 3, 4 and 7,
Acked-by: Tim Deegan 

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 16:02:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 16:02:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR3PC-0002M7-Hx; Wed, 24 Oct 2012 16:02:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TR3PA-0002Lv-SI
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 16:02:04 +0000
Received: from [85.158.139.211:18561] by server-16.bemta-5.messagelabs.com id
	35/58-04786-CF018805; Wed, 24 Oct 2012 16:02:04 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-206.messagelabs.com!1351094523!22069688!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17614 invoked from network); 24 Oct 2012 16:02:03 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Oct 2012 16:02:03 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TR3P8-000CDs-Sl; Wed, 24 Oct 2012 16:02:02 +0000
Date: Wed, 24 Oct 2012 17:02:02 +0100
From: Tim Deegan 
To: Stefano Stabellini 
Message-ID: <20121024160202.GE39126@ocelot.phlegethon.org>
References: 
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, Ian Campbell 
Subject: Re: [Xen-devel] [PATCH 0/7] xen/arm: run on real hardware
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 16:03 +0100 on 24 Oct (1351094597), Stefano Stabellini wrote:
> Hi all,
> this is a collection of fixes that I wrote trying to run Xen on a real
> Versatile Express Cortex A15 machine.

Congratulations on getting it running on real hardware!  That's great
progress.

I've replied to 2, 5 and 6.  For 1, 3, 4 and 7,
Acked-by: Tim Deegan 

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 16:05:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 16:05:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR3SN-0002eY-5i; Wed, 24 Oct 2012 16:05:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TR3SL-0002eT-C3
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 16:05:21 +0000
Received: from [85.158.137.99:49953] by server-1.bemta-3.messagelabs.com id
	67/D3-31728-0C118805; Wed, 24 Oct 2012 16:05:20 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-217.messagelabs.com!1351094719!22783615!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20689 invoked from network); 24 Oct 2012 16:05:19 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-10.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Oct 2012 16:05:19 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TR3SJ-000CEs-9O; Wed, 24 Oct 2012 16:05:19 +0000
Date: Wed, 24 Oct 2012 17:05:19 +0100
From: Tim Deegan 
To: Stefano Stabellini 
Message-ID: <20121024160519.GF39126@ocelot.phlegethon.org>
References: 
	<1351091027-20740-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<20121024153809.GC39126@ocelot.phlegethon.org>
	
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" ,
	Ian Campbell 
Subject: Re: [Xen-devel] [PATCH 5/7] xen/arm: wake up secondary cpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 16:59 +0100 on 24 Oct (1351097986), Stefano Stabellini wrote:
> On Wed, 24 Oct 2012, Tim Deegan wrote:
> > At 16:03 +0100 on 24 Oct (1351094625), Stefano Stabellini wrote:
> > > Secondary cpus are held by the firmware until we send an IPI to them.
> > > 
> > > Signed-off-by: Stefano Stabellini 
> > > ---
> > >  xen/arch/arm/head.S        |    8 ++++++--
> > >  xen/arch/arm/mode_switch.S |   31 +++++++++++++++++++++++++++++++
> > >  2 files changed, 37 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
> > > index c784f4d..39c4774 100644
> > > --- a/xen/arch/arm/head.S
> > > +++ b/xen/arch/arm/head.S
> > > @@ -79,12 +79,12 @@ start:
> > >  	beq   boot_cpu               /* If we're CPU 0, boot now */
> > >  
> > >  	/* Non-boot CPUs wait here to be woken up one at a time. */
> > > -1:	wfe
> > > -	dsb
> > > +1:	dsb
> > >  	ldr   r0, =smp_up_cpu        /* VA of gate */
> > >  	add   r0, r0, r10            /* PA of gate */
> > >  	ldr   r1, [r0]               /* Which CPU is being booted? */
> > >  	teq   r1, r12                /* Is it us? */
> > > +	wfene
> > 
> > Shouldn't that be wf_i_ne?
> 
> Nope. We need wfe here, in fact the corresponding code is
> xen/arch/arm/smpboot.c:make_cpus_ready that uses sev to wake the other
> cpus up. The code running wfi on secondary cpus is actually in the
> firmware.

Ah, I see - thanks.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 16:05:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 16:05:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR3SN-0002eY-5i; Wed, 24 Oct 2012 16:05:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TR3SL-0002eT-C3
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 16:05:21 +0000
Received: from [85.158.137.99:49953] by server-1.bemta-3.messagelabs.com id
	67/D3-31728-0C118805; Wed, 24 Oct 2012 16:05:20 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-217.messagelabs.com!1351094719!22783615!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20689 invoked from network); 24 Oct 2012 16:05:19 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-10.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Oct 2012 16:05:19 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TR3SJ-000CEs-9O; Wed, 24 Oct 2012 16:05:19 +0000
Date: Wed, 24 Oct 2012 17:05:19 +0100
From: Tim Deegan 
To: Stefano Stabellini 
Message-ID: <20121024160519.GF39126@ocelot.phlegethon.org>
References: 
	<1351091027-20740-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<20121024153809.GC39126@ocelot.phlegethon.org>
	
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" ,
	Ian Campbell 
Subject: Re: [Xen-devel] [PATCH 5/7] xen/arm: wake up secondary cpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 16:59 +0100 on 24 Oct (1351097986), Stefano Stabellini wrote:
> On Wed, 24 Oct 2012, Tim Deegan wrote:
> > At 16:03 +0100 on 24 Oct (1351094625), Stefano Stabellini wrote:
> > > Secondary cpus are held by the firmware until we send an IPI to them.
> > > 
> > > Signed-off-by: Stefano Stabellini 
> > > ---
> > >  xen/arch/arm/head.S        |    8 ++++++--
> > >  xen/arch/arm/mode_switch.S |   31 +++++++++++++++++++++++++++++++
> > >  2 files changed, 37 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
> > > index c784f4d..39c4774 100644
> > > --- a/xen/arch/arm/head.S
> > > +++ b/xen/arch/arm/head.S
> > > @@ -79,12 +79,12 @@ start:
> > >  	beq   boot_cpu               /* If we're CPU 0, boot now */
> > >  
> > >  	/* Non-boot CPUs wait here to be woken up one at a time. */
> > > -1:	wfe
> > > -	dsb
> > > +1:	dsb
> > >  	ldr   r0, =smp_up_cpu        /* VA of gate */
> > >  	add   r0, r0, r10            /* PA of gate */
> > >  	ldr   r1, [r0]               /* Which CPU is being booted? */
> > >  	teq   r1, r12                /* Is it us? */
> > > +	wfene
> > 
> > Shouldn't that be wf_i_ne?
> 
> Nope. We need wfe here, in fact the corresponding code is
> xen/arch/arm/smpboot.c:make_cpus_ready that uses sev to wake the other
> cpus up. The code running wfi on secondary cpus is actually in the
> firmware.

Ah, I see - thanks.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 16:07:03 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 16:07:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR3Tm-0002jc-LU; Wed, 24 Oct 2012 16:06:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR3Tk-0002jU-Su
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 16:06:48 +0000
Received: from [85.158.143.35:51125] by server-2.bemta-4.messagelabs.com id
	21/99-22268-81218805; Wed, 24 Oct 2012 16:06:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1351094775!16602692!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13464 invoked from network); 24 Oct 2012 16:06:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 16:06:15 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15363775"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 16:05:50 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 17:05:51 +0100
Message-ID: <1351094749.18035.70.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Tim Deegan 
Date: Wed, 24 Oct 2012 17:05:49 +0100
In-Reply-To: <20121024155945.GD39126@ocelot.phlegethon.org>
References: 
	<1351091027-20740-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20121024155945.GD39126@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 6/7] xen/arm: flush D-cache and I-cache when
	appropriate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 16:59 +0100, Tim Deegan wrote:
> > +    asm volatile (
> > +        "dsb;"
> > +        STORE_CP32(0, DCCMVAC)
> > +        "isb;"
> > +        : : "r" (r0) : "memory");
> 
> Does this need a 'memory' clobber?  Can we get away with just saying it
> consumes *va as an input?  All we need to be sure of is that the
> particular thing we're flushing has been written out; no need to stop
> any other optimizations.
> 
> I guess it might need to be re-cast as a macro so the compiler knows how
> big *va is?

Does it matter that this flushes the cache line containing va, which
might be larger than whatever type va is?




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 16:07:03 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 16:07:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR3Tm-0002jc-LU; Wed, 24 Oct 2012 16:06:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR3Tk-0002jU-Su
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 16:06:48 +0000
Received: from [85.158.143.35:51125] by server-2.bemta-4.messagelabs.com id
	21/99-22268-81218805; Wed, 24 Oct 2012 16:06:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1351094775!16602692!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13464 invoked from network); 24 Oct 2012 16:06:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 16:06:15 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15363775"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 16:05:50 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 17:05:51 +0100
Message-ID: <1351094749.18035.70.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Tim Deegan 
Date: Wed, 24 Oct 2012 17:05:49 +0100
In-Reply-To: <20121024155945.GD39126@ocelot.phlegethon.org>
References: 
	<1351091027-20740-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20121024155945.GD39126@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 6/7] xen/arm: flush D-cache and I-cache when
	appropriate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 16:59 +0100, Tim Deegan wrote:
> > +    asm volatile (
> > +        "dsb;"
> > +        STORE_CP32(0, DCCMVAC)
> > +        "isb;"
> > +        : : "r" (r0) : "memory");
> 
> Does this need a 'memory' clobber?  Can we get away with just saying it
> consumes *va as an input?  All we need to be sure of is that the
> particular thing we're flushing has been written out; no need to stop
> any other optimizations.
> 
> I guess it might need to be re-cast as a macro so the compiler knows how
> big *va is?

Does it matter that this flushes the cache line containing va, which
might be larger than whatever type va is?




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 16:18:07 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 16:18:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR3eQ-0002zB-Qp; Wed, 24 Oct 2012 16:17:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TR3eP-0002z6-KV
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 16:17:49 +0000
Received: from [85.158.139.83:26529] by server-4.bemta-5.messagelabs.com id
	81/E0-01455-CA418805; Wed, 24 Oct 2012 16:17:48 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-182.messagelabs.com!1351095467!24583921!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10037 invoked from network); 24 Oct 2012 16:17:48 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Oct 2012 16:17:48 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TR3eL-000CHJ-AO; Wed, 24 Oct 2012 16:17:45 +0000
Date: Wed, 24 Oct 2012 17:17:45 +0100
From: Tim Deegan 
To: Ian Campbell 
Message-ID: <20121024161745.GG39126@ocelot.phlegethon.org>
References: 
	<1351091027-20740-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20121024155945.GD39126@ocelot.phlegethon.org>
	<1351094749.18035.70.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1351094749.18035.70.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 6/7] xen/arm: flush D-cache and I-cache when
	appropriate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 17:05 +0100 on 24 Oct (1351098349), Ian Campbell wrote:
> On Wed, 2012-10-24 at 16:59 +0100, Tim Deegan wrote:
> > > +    asm volatile (
> > > +        "dsb;"
> > > +        STORE_CP32(0, DCCMVAC)
> > > +        "isb;"
> > > +        : : "r" (r0) : "memory");
> > 
> > Does this need a 'memory' clobber?  Can we get away with just saying it
> > consumes *va as an input?  All we need to be sure of is that the
> > particular thing we're flushing has been written out; no need to stop
> > any other optimizations.
> > 
> > I guess it might need to be re-cast as a macro so the compiler knows how
> > big *va is?
> 
> Does it matter that this flushes the cache line containing va, which
> might be larger than whatever type va is?

That depends why you're flushing. :)  From this CPU's PoV the flush
should have no effect at all, so the things to worry about are:

 - the write of the thing we're trying to flush gets moved by the
   compiler so it's after the flush.   That case is handled by using an 
   input memory operand of the right size.
 - something else on the cacheline that's written after the flush gets
   hoisted and written before.  It seems like anything that's relying on
   that (?!) is on very thin ice already and ought to be using (at least)
   explicit memory barriers of its own.

Another interesting case is where we're flushing a large area by
cachelines (like the new loop after relocation), so effectively we don't
know the size of the input operand (a.k.a. 1 cacheline) at compile time.
But there I think a single explicit barrier before the loop isn't too much
to ask.  We could break that and the loop out into a separate function.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 16:18:07 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 16:18:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR3eQ-0002zB-Qp; Wed, 24 Oct 2012 16:17:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TR3eP-0002z6-KV
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 16:17:49 +0000
Received: from [85.158.139.83:26529] by server-4.bemta-5.messagelabs.com id
	81/E0-01455-CA418805; Wed, 24 Oct 2012 16:17:48 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-182.messagelabs.com!1351095467!24583921!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10037 invoked from network); 24 Oct 2012 16:17:48 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Oct 2012 16:17:48 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TR3eL-000CHJ-AO; Wed, 24 Oct 2012 16:17:45 +0000
Date: Wed, 24 Oct 2012 17:17:45 +0100
From: Tim Deegan 
To: Ian Campbell 
Message-ID: <20121024161745.GG39126@ocelot.phlegethon.org>
References: 
	<1351091027-20740-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20121024155945.GD39126@ocelot.phlegethon.org>
	<1351094749.18035.70.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1351094749.18035.70.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 6/7] xen/arm: flush D-cache and I-cache when
	appropriate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 17:05 +0100 on 24 Oct (1351098349), Ian Campbell wrote:
> On Wed, 2012-10-24 at 16:59 +0100, Tim Deegan wrote:
> > > +    asm volatile (
> > > +        "dsb;"
> > > +        STORE_CP32(0, DCCMVAC)
> > > +        "isb;"
> > > +        : : "r" (r0) : "memory");
> > 
> > Does this need a 'memory' clobber?  Can we get away with just saying it
> > consumes *va as an input?  All we need to be sure of is that the
> > particular thing we're flushing has been written out; no need to stop
> > any other optimizations.
> > 
> > I guess it might need to be re-cast as a macro so the compiler knows how
> > big *va is?
> 
> Does it matter that this flushes the cache line containing va, which
> might be larger than whatever type va is?

That depends why you're flushing. :)  From this CPU's PoV the flush
should have no effect at all, so the things to worry about are:

 - the write of the thing we're trying to flush gets moved by the
   compiler so it's after the flush.   That case is handled by using an 
   input memory operand of the right size.
 - something else on the cacheline that's written after the flush gets
   hoisted and written before.  It seems like anything that's relying on
   that (?!) is on very thin ice already and ought to be using (at least)
   explicit memory barriers of its own.

Another interesting case is where we're flushing a large area by
cachelines (like the new loop after relocation), so effectively we don't
know the size of the input operand (a.k.a. 1 cacheline) at compile time.
But there I think a single explicit barrier before the loop isn't too much
to ask.  We could break that and the loop out into a separate function.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 16:22:44 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 16:22:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR3iq-000376-HD; Wed, 24 Oct 2012 16:22:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR3io-00036y-LG
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 16:22:22 +0000
Received: from [85.158.139.211:42073] by server-6.bemta-5.messagelabs.com id
	81/D8-32589-DB518805; Wed, 24 Oct 2012 16:22:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1351095741!23572596!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4136 invoked from network); 24 Oct 2012 16:22:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 16:22:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15364346"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 16:22:20 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 17:22:21 +0100
Message-ID: <1351095739.18035.83.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Eric Dumazet 
Date: Wed, 24 Oct 2012 17:22:19 +0100
In-Reply-To: <1351092068.6537.107.camel@edumazet-glaptop>
References: <1351078936-14159-1-git-send-email-ian.campbell@citrix.com>
	<1351081703.6537.99.camel@edumazet-glaptop>
	<1351084618.18035.27.camel@zakaz.uk.xensource.com>
	<1351085403.6537.102.camel@edumazet-glaptop>
	<1351087326.18035.50.camel@zakaz.uk.xensource.com>
	<1351092068.6537.107.camel@edumazet-glaptop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" ,
	Eric Dumazet ,
	"xen-devel@lists.xen.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH] net: allow configuration of the size of
 page in __netdev_alloc_frag
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 16:21 +0100, Eric Dumazet wrote:
> On Wed, 2012-10-24 at 15:02 +0100, Ian Campbell wrote:
> > On Wed, 2012-10-24 at 14:30 +0100, Eric Dumazet wrote:
> > > It seems to me its a driver issue, for example
> > > drivers/net/xen-netfront.c has assumptions that can be easily fixed.
> > 
> > The netfront ->head thing is a separate (although perhaps related)
> > issue, I intended to fix along the same lines as the previous netback
> > except for some unfathomable reason I haven't been able to reproduce the
> > problem with netfront -- I've no idea why though since it seems like it
> > should be a no brainer!
> > 
> > > Why skb->head can be on order-1 or order-2 pages and this is working ?
> > 
> > skb->head being order 1 or 2 isn't working for me. The driver I'm having
> > issues with which caused me to create this particular patch is the tg3
> > driver (although I don't think this is by any means specific to tg3).
> > 
> > For the ->head the tg3 driver does:
> >         mapping = pci_map_single(tp->pdev, skb->data, len, PCI_DMA_TODEVICE);
> > while for the frags it does:
> >         mapping = skb_frag_dma_map(&tp->pdev->dev, frag, 0, len, DMA_TO_DEVICE);
> > 
> > This ought to do the Right Thing but doesn't seem to be working. Konrad
> > suspected an issue with the swiotlb's handling of order>0 pages in some
> > cases. As I said in the commit message he is looking into this issue.
> > 
> > My concern however was that even once the swiotlb is fixed to work right
> > the effect of pci_map_single on a order>0 page is going to be that the
> > data gets bounced into contiguous memory -- that is a memcpy which would
> > undo the benefit of having allocating large pages to start with. So I
> > figured that in such cases we'd be better off just using order 0
> > allocations to start with.
> 
> I am really confused.
> 
> If you really have such problems, why locally generated TCP traffic
> doesnt also have it ?

I think it does. The reason I noticed the original problem was that ssh
to the machine was virtually (no pun intended) unusable.

> Your patch doesnt touch sk_page_frag_refill(), does it ?

That's right. It doesn't. When is (sk->sk_allocation & __GFP_WAIT) true?
Is it possible I'm just not hitting that case?

Is it possible that this only affects certain traffic patterns (I only
really tried ssh/scp and ping)? Or perhaps its just that the swiotlb is
only broken in one corner case and not the other.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 16:22:44 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 16:22:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR3iq-000376-HD; Wed, 24 Oct 2012 16:22:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR3io-00036y-LG
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 16:22:22 +0000
Received: from [85.158.139.211:42073] by server-6.bemta-5.messagelabs.com id
	81/D8-32589-DB518805; Wed, 24 Oct 2012 16:22:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1351095741!23572596!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4136 invoked from network); 24 Oct 2012 16:22:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 16:22:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15364346"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 16:22:20 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 17:22:21 +0100
Message-ID: <1351095739.18035.83.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Eric Dumazet 
Date: Wed, 24 Oct 2012 17:22:19 +0100
In-Reply-To: <1351092068.6537.107.camel@edumazet-glaptop>
References: <1351078936-14159-1-git-send-email-ian.campbell@citrix.com>
	<1351081703.6537.99.camel@edumazet-glaptop>
	<1351084618.18035.27.camel@zakaz.uk.xensource.com>
	<1351085403.6537.102.camel@edumazet-glaptop>
	<1351087326.18035.50.camel@zakaz.uk.xensource.com>
	<1351092068.6537.107.camel@edumazet-glaptop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" ,
	Eric Dumazet ,
	"xen-devel@lists.xen.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH] net: allow configuration of the size of
 page in __netdev_alloc_frag
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 16:21 +0100, Eric Dumazet wrote:
> On Wed, 2012-10-24 at 15:02 +0100, Ian Campbell wrote:
> > On Wed, 2012-10-24 at 14:30 +0100, Eric Dumazet wrote:
> > > It seems to me its a driver issue, for example
> > > drivers/net/xen-netfront.c has assumptions that can be easily fixed.
> > 
> > The netfront ->head thing is a separate (although perhaps related)
> > issue, I intended to fix along the same lines as the previous netback
> > except for some unfathomable reason I haven't been able to reproduce the
> > problem with netfront -- I've no idea why though since it seems like it
> > should be a no brainer!
> > 
> > > Why skb->head can be on order-1 or order-2 pages and this is working ?
> > 
> > skb->head being order 1 or 2 isn't working for me. The driver I'm having
> > issues with which caused me to create this particular patch is the tg3
> > driver (although I don't think this is by any means specific to tg3).
> > 
> > For the ->head the tg3 driver does:
> >         mapping = pci_map_single(tp->pdev, skb->data, len, PCI_DMA_TODEVICE);
> > while for the frags it does:
> >         mapping = skb_frag_dma_map(&tp->pdev->dev, frag, 0, len, DMA_TO_DEVICE);
> > 
> > This ought to do the Right Thing but doesn't seem to be working. Konrad
> > suspected an issue with the swiotlb's handling of order>0 pages in some
> > cases. As I said in the commit message he is looking into this issue.
> > 
> > My concern however was that even once the swiotlb is fixed to work right
> > the effect of pci_map_single on a order>0 page is going to be that the
> > data gets bounced into contiguous memory -- that is a memcpy which would
> > undo the benefit of having allocating large pages to start with. So I
> > figured that in such cases we'd be better off just using order 0
> > allocations to start with.
> 
> I am really confused.
> 
> If you really have such problems, why locally generated TCP traffic
> doesnt also have it ?

I think it does. The reason I noticed the original problem was that ssh
to the machine was virtually (no pun intended) unusable.

> Your patch doesnt touch sk_page_frag_refill(), does it ?

That's right. It doesn't. When is (sk->sk_allocation & __GFP_WAIT) true?
Is it possible I'm just not hitting that case?

Is it possible that this only affects certain traffic patterns (I only
really tried ssh/scp and ping)? Or perhaps its just that the swiotlb is
only broken in one corner case and not the other.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 16:43:47 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 16:43:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR43E-0003RG-7D; Wed, 24 Oct 2012 16:43:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR43C-0003R8-Bs
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 16:43:26 +0000
Received: from [85.158.137.99:56958] by server-2.bemta-3.messagelabs.com id
	C6/1D-00604-DAA18805; Wed, 24 Oct 2012 16:43:25 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1351097004!18164223!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15953 invoked from network); 24 Oct 2012 16:43:25 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 16:43:25 -0000
Received: by mail-bk0-f45.google.com with SMTP id jf3so363075bkc.32
	for ; Wed, 24 Oct 2012 09:43:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:from:to:cc:in-reply-to:references:content-type:date
	:message-id:mime-version:x-mailer:content-transfer-encoding;
	bh=EThzyF28lr3FRGh0gLKLFZ/5MuLk3eWKRsWzXjPmKQo=;
	b=fw5MZNR92n7KLbVHlGPGb1nCo46kfcXO2O4yS1G0Qt3zzVenGHY6RV/8Mc3FwlTWHF
	7JyI+3PnBjrFx1KcWEqvVo6BC3PSY3UkWs1K7Fm9H17JqSb7bv5MqRJucw69tYivhttP
	FehefxXNoCRTyrH5FuFC9VBRATzmMt4QKtXXfIIR87B4v0vKaS2+sxI0BvJQAF2uP008
	CIRI68/abK7FRVNAusvWGw7FKorBxFTOgfZAAwgzl1gnX+XbqV08xIffDW5tUxTbG3ev
	UEvMmeKmhB203eAU5b8oDsNSkye20c4NbKpFNteuIgjF4wRK93G7I60WNh5PoB2AiaEe
	CbCw==
Received: by 10.205.132.72 with SMTP id ht8mr4904819bkc.72.1351097004639;
	Wed, 24 Oct 2012 09:43:24 -0700 (PDT)
Received: from [172.28.90.62] ([172.28.90.62])
	by mx.google.com with ESMTPS id fm5sm8692518bkc.5.2012.10.24.09.43.22
	(version=SSLv3 cipher=OTHER); Wed, 24 Oct 2012 09:43:23 -0700 (PDT)
From: Eric Dumazet 
To: Ian Campbell 
In-Reply-To: <1351095739.18035.83.camel@zakaz.uk.xensource.com>
References: <1351078936-14159-1-git-send-email-ian.campbell@citrix.com>
	<1351081703.6537.99.camel@edumazet-glaptop>
	<1351084618.18035.27.camel@zakaz.uk.xensource.com>
	<1351085403.6537.102.camel@edumazet-glaptop>
	<1351087326.18035.50.camel@zakaz.uk.xensource.com>
	<1351092068.6537.107.camel@edumazet-glaptop>
	<1351095739.18035.83.camel@zakaz.uk.xensource.com>
Date: Wed, 24 Oct 2012 18:43:20 +0200
Message-ID: <1351097000.6537.109.camel@edumazet-glaptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: "netdev@vger.kernel.org" ,
	Eric Dumazet ,
	"xen-devel@lists.xen.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH] net: allow configuration of the size of
 page in __netdev_alloc_frag
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 17:22 +0100, Ian Campbell wrote:
> On Wed, 2012-10-24 at 16:21 +0100, Eric Dumazet wrote:

> > If you really have such problems, why locally generated TCP traffic
> > doesnt also have it ?
> 
> I think it does. The reason I noticed the original problem was that ssh
> to the machine was virtually (no pun intended) unusable.
> 
> > Your patch doesnt touch sk_page_frag_refill(), does it ?
> 
> That's right. It doesn't. When is (sk->sk_allocation & __GFP_WAIT) true?
> Is it possible I'm just not hitting that case?
> 

I hope not. GFP_KERNEL has __GFP_WAIT.

> Is it possible that this only affects certain traffic patterns (I only
> really tried ssh/scp and ping)? Or perhaps its just that the swiotlb is
> only broken in one corner case and not the other.

Could you try a netperf -t TCP_STREAM ?

Because ssh use small packets, and small TCP packets dont use frags but
skb->head.

You mentioned a 70% drop of performance, but what test have you used
exactly ?




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 16:43:47 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 16:43:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR43E-0003RG-7D; Wed, 24 Oct 2012 16:43:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR43C-0003R8-Bs
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 16:43:26 +0000
Received: from [85.158.137.99:56958] by server-2.bemta-3.messagelabs.com id
	C6/1D-00604-DAA18805; Wed, 24 Oct 2012 16:43:25 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1351097004!18164223!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15953 invoked from network); 24 Oct 2012 16:43:25 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 16:43:25 -0000
Received: by mail-bk0-f45.google.com with SMTP id jf3so363075bkc.32
	for ; Wed, 24 Oct 2012 09:43:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:from:to:cc:in-reply-to:references:content-type:date
	:message-id:mime-version:x-mailer:content-transfer-encoding;
	bh=EThzyF28lr3FRGh0gLKLFZ/5MuLk3eWKRsWzXjPmKQo=;
	b=fw5MZNR92n7KLbVHlGPGb1nCo46kfcXO2O4yS1G0Qt3zzVenGHY6RV/8Mc3FwlTWHF
	7JyI+3PnBjrFx1KcWEqvVo6BC3PSY3UkWs1K7Fm9H17JqSb7bv5MqRJucw69tYivhttP
	FehefxXNoCRTyrH5FuFC9VBRATzmMt4QKtXXfIIR87B4v0vKaS2+sxI0BvJQAF2uP008
	CIRI68/abK7FRVNAusvWGw7FKorBxFTOgfZAAwgzl1gnX+XbqV08xIffDW5tUxTbG3ev
	UEvMmeKmhB203eAU5b8oDsNSkye20c4NbKpFNteuIgjF4wRK93G7I60WNh5PoB2AiaEe
	CbCw==
Received: by 10.205.132.72 with SMTP id ht8mr4904819bkc.72.1351097004639;
	Wed, 24 Oct 2012 09:43:24 -0700 (PDT)
Received: from [172.28.90.62] ([172.28.90.62])
	by mx.google.com with ESMTPS id fm5sm8692518bkc.5.2012.10.24.09.43.22
	(version=SSLv3 cipher=OTHER); Wed, 24 Oct 2012 09:43:23 -0700 (PDT)
From: Eric Dumazet 
To: Ian Campbell 
In-Reply-To: <1351095739.18035.83.camel@zakaz.uk.xensource.com>
References: <1351078936-14159-1-git-send-email-ian.campbell@citrix.com>
	<1351081703.6537.99.camel@edumazet-glaptop>
	<1351084618.18035.27.camel@zakaz.uk.xensource.com>
	<1351085403.6537.102.camel@edumazet-glaptop>
	<1351087326.18035.50.camel@zakaz.uk.xensource.com>
	<1351092068.6537.107.camel@edumazet-glaptop>
	<1351095739.18035.83.camel@zakaz.uk.xensource.com>
Date: Wed, 24 Oct 2012 18:43:20 +0200
Message-ID: <1351097000.6537.109.camel@edumazet-glaptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: "netdev@vger.kernel.org" ,
	Eric Dumazet ,
	"xen-devel@lists.xen.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH] net: allow configuration of the size of
 page in __netdev_alloc_frag
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 17:22 +0100, Ian Campbell wrote:
> On Wed, 2012-10-24 at 16:21 +0100, Eric Dumazet wrote:

> > If you really have such problems, why locally generated TCP traffic
> > doesnt also have it ?
> 
> I think it does. The reason I noticed the original problem was that ssh
> to the machine was virtually (no pun intended) unusable.
> 
> > Your patch doesnt touch sk_page_frag_refill(), does it ?
> 
> That's right. It doesn't. When is (sk->sk_allocation & __GFP_WAIT) true?
> Is it possible I'm just not hitting that case?
> 

I hope not. GFP_KERNEL has __GFP_WAIT.

> Is it possible that this only affects certain traffic patterns (I only
> really tried ssh/scp and ping)? Or perhaps its just that the swiotlb is
> only broken in one corner case and not the other.

Could you try a netperf -t TCP_STREAM ?

Because ssh use small packets, and small TCP packets dont use frags but
skb->head.

You mentioned a 70% drop of performance, but what test have you used
exactly ?




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 16:49:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 16:49:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR48p-0003iA-01; Wed, 24 Oct 2012 16:49:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR48m-0003i3-VF
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 16:49:13 +0000
Received: from [85.158.139.211:46630] by server-13.bemta-5.messagelabs.com id
	52/7C-27809-80C18805; Wed, 24 Oct 2012 16:49:12 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1351097351!23602071!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17067 invoked from network); 24 Oct 2012 16:49:11 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 16:49:11 -0000
Received: by mail-we0-f173.google.com with SMTP id t11so465003wey.32
	for ; Wed, 24 Oct 2012 09:49:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:subject:from:to:cc:date:in-reply-to:references
	:content-type:x-mailer:mime-version;
	bh=Hvk7pw4YWIECe4MsTovfdMSNHLqCqKz9572ZE4q9Xho=;
	b=rJJvsiMmZgsNMMNE/NNwDpJuynTy/8BzCxc5OT7uz/iUaapxlFqF2eUdXlBVgN7M1k
	GQEVTRqdfdSR4zex5b3PzgPYsXzOPiqsFtyW+33u9z1HUEUZ4Q+ppiQ88Um0Vf4HXc0B
	O3DYdXUsvZo0iemQ0yuwL9oQlat39U1wgMxdQEbLCSquKzEnWUF3Efec+1Y3v0D9SChd
	NisQ5Q4E3pCd5u/RWIDVz6hxj9REmJzwZn0ja6bFlH3Q1FuPC3dQMsT4eQ9eWBv91exD
	bbwK0iifyhjPrsfskCl9q7Bl7OTWsP8bHK6pWFrfn1SisVXgybtSCrd0C1H04sI9LSS5
	BTjg==
Received: by 10.180.87.230 with SMTP id bb6mr3853876wib.6.1351097351279;
	Wed, 24 Oct 2012 09:49:11 -0700 (PDT)
Received: from [192.168.0.40] (ip-180-234.sn1.eutelia.it. [62.94.180.234])
	by mx.google.com with ESMTPS id di7sm5858904wib.11.2012.10.24.09.49.08
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 24 Oct 2012 09:49:09 -0700 (PDT)
Message-ID: <1351097333.18330.15.camel@Solace>
From: Dario Faggioli 
To: George Dunlap 
Date: Wed, 24 Oct 2012 18:48:53 +0200
In-Reply-To: <5086B4DF.6060701@eu.citrix.com>
References: <1350999260.5064.56.camel@Solace> <5086B4DF.6060701@eu.citrix.com>
X-Mailer: Evolution 3.4.4-1
Mime-Version: 1.0
Cc: Keir Fraser , Jan Beulich ,
	xen-devel 
Subject: Re: [Xen-devel] About vcpu wakeup and runq tickling in credit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1651033115773789615=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============1651033115773789615==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-svvlkOFhygR0X8Od8Q4Z"


--=-svvlkOFhygR0X8Od8Q4Z
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2012-10-23 at 16:16 +0100, George Dunlap wrote:
> > If yes, here's my question. Is that right to always tickle v_W's affine
> > CPUs and only them?
> >
> > I'm asking because a possible scenario, at least according to me, is
> > that P schedules very quickly after this and, as prio(v_W)>prio(v_C), i=
t
> > selects v_W and leaves v_C in its runq. At that point, one of the
> > tickled CPU (say P') enters schedule, sees that P is not idle, and trie=
s
> > to steal a vcpu from its runq. Now we know that P' has affinity with
> > v_W, but v_W is not there, while v_C is, and if P' is not in its
> > affinity, we've forced P' to reschedule for nothing.
> > Also, there now might be another (or even a number of) CPU where v_C
> > could run that stays idle, as it has not being tickled.
>=20
> Yes -- the two clauses look a bit like they were conceived=20
> independently, and maybe no one thought about how they might interact.
>=20
Yep, it looked the same to me.

> > As it comes to possible solution, I think that, for instance, tickling
> > all the CPUs in both v_W's and v_C's affinity masks could solve this,
> > but that would also potentially increase the overhead (by asking _a_lot=
_
> > of CPUs to reschedule), and again, it's hard to say if/when it's
> > worth...
>=20
> Well in my code, opt_tickle_idle_one is on by default, which means only=
=20
> one other cpu will be woken up.  If there were an easy way to make it=20
> wake up a CPU in v_C's affinity as well (supposing that there was no=20
> overlap), that would probably be a win.
>=20
Yes, default is to tickle only 1 idler. However, as we offer that as a
command line option, I think we should consider what could happen if one
disables it.

I double checked this on Linux and, mutatis mutandis, they sort of go
the way I was suggesting, i.e., "pinging" the CPUs with affinity to the
task that will likely stay in the runq rather than being picked up
locally. However, there are of course big difference between the two
schedulers and different assumptions being made, thus I'm not really
sure of that being the best thing to do for us.

So, yes, it probably make sense to think about something clever to try
to involve CPUs from both the masks without causing too much overhead.
I'll put that in my TODO List. :-)

> Of course, that's only necessary if:
> * v_C is lower priority than v_W
> * There are no idlers that intersect both v_C and v_W's affinity mask.
>=20
Sure, I said that in the first place, and I don't think checking for
that is too hard... Just a couple of more bitmap ops. But again, I'll
give it some thinking.

> It's probably a good idea though to try to set up a scenario where this=
=20
> might be an issue and see how often it actually happens.
>=20
Definitely, before trying to "fix" it, I'm interested in finding out
what I'd be actually fixing. Will do that.

Thanks for taking time to check and answer this! :-)
Dario

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-svvlkOFhygR0X8Od8Q4Z
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlCIG/UACgkQk4XaBE3IOsQ9NwCfVUC/m2bq0P3eUGiJ9nPfmVp+
LmYAnRlw7XBotD+2F3VGsFkzPcHBI4sI
=Bvht
-----END PGP SIGNATURE-----

--=-svvlkOFhygR0X8Od8Q4Z--



--===============1651033115773789615==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1651033115773789615==--



From xen-devel-bounces@lists.xen.org Wed Oct 24 16:49:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 16:49:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR48p-0003iA-01; Wed, 24 Oct 2012 16:49:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR48m-0003i3-VF
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 16:49:13 +0000
Received: from [85.158.139.211:46630] by server-13.bemta-5.messagelabs.com id
	52/7C-27809-80C18805; Wed, 24 Oct 2012 16:49:12 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1351097351!23602071!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17067 invoked from network); 24 Oct 2012 16:49:11 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 16:49:11 -0000
Received: by mail-we0-f173.google.com with SMTP id t11so465003wey.32
	for ; Wed, 24 Oct 2012 09:49:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:subject:from:to:cc:date:in-reply-to:references
	:content-type:x-mailer:mime-version;
	bh=Hvk7pw4YWIECe4MsTovfdMSNHLqCqKz9572ZE4q9Xho=;
	b=rJJvsiMmZgsNMMNE/NNwDpJuynTy/8BzCxc5OT7uz/iUaapxlFqF2eUdXlBVgN7M1k
	GQEVTRqdfdSR4zex5b3PzgPYsXzOPiqsFtyW+33u9z1HUEUZ4Q+ppiQ88Um0Vf4HXc0B
	O3DYdXUsvZo0iemQ0yuwL9oQlat39U1wgMxdQEbLCSquKzEnWUF3Efec+1Y3v0D9SChd
	NisQ5Q4E3pCd5u/RWIDVz6hxj9REmJzwZn0ja6bFlH3Q1FuPC3dQMsT4eQ9eWBv91exD
	bbwK0iifyhjPrsfskCl9q7Bl7OTWsP8bHK6pWFrfn1SisVXgybtSCrd0C1H04sI9LSS5
	BTjg==
Received: by 10.180.87.230 with SMTP id bb6mr3853876wib.6.1351097351279;
	Wed, 24 Oct 2012 09:49:11 -0700 (PDT)
Received: from [192.168.0.40] (ip-180-234.sn1.eutelia.it. [62.94.180.234])
	by mx.google.com with ESMTPS id di7sm5858904wib.11.2012.10.24.09.49.08
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 24 Oct 2012 09:49:09 -0700 (PDT)
Message-ID: <1351097333.18330.15.camel@Solace>
From: Dario Faggioli 
To: George Dunlap 
Date: Wed, 24 Oct 2012 18:48:53 +0200
In-Reply-To: <5086B4DF.6060701@eu.citrix.com>
References: <1350999260.5064.56.camel@Solace> <5086B4DF.6060701@eu.citrix.com>
X-Mailer: Evolution 3.4.4-1
Mime-Version: 1.0
Cc: Keir Fraser , Jan Beulich ,
	xen-devel 
Subject: Re: [Xen-devel] About vcpu wakeup and runq tickling in credit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1651033115773789615=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============1651033115773789615==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-svvlkOFhygR0X8Od8Q4Z"


--=-svvlkOFhygR0X8Od8Q4Z
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2012-10-23 at 16:16 +0100, George Dunlap wrote:
> > If yes, here's my question. Is that right to always tickle v_W's affine
> > CPUs and only them?
> >
> > I'm asking because a possible scenario, at least according to me, is
> > that P schedules very quickly after this and, as prio(v_W)>prio(v_C), i=
t
> > selects v_W and leaves v_C in its runq. At that point, one of the
> > tickled CPU (say P') enters schedule, sees that P is not idle, and trie=
s
> > to steal a vcpu from its runq. Now we know that P' has affinity with
> > v_W, but v_W is not there, while v_C is, and if P' is not in its
> > affinity, we've forced P' to reschedule for nothing.
> > Also, there now might be another (or even a number of) CPU where v_C
> > could run that stays idle, as it has not being tickled.
>=20
> Yes -- the two clauses look a bit like they were conceived=20
> independently, and maybe no one thought about how they might interact.
>=20
Yep, it looked the same to me.

> > As it comes to possible solution, I think that, for instance, tickling
> > all the CPUs in both v_W's and v_C's affinity masks could solve this,
> > but that would also potentially increase the overhead (by asking _a_lot=
_
> > of CPUs to reschedule), and again, it's hard to say if/when it's
> > worth...
>=20
> Well in my code, opt_tickle_idle_one is on by default, which means only=
=20
> one other cpu will be woken up.  If there were an easy way to make it=20
> wake up a CPU in v_C's affinity as well (supposing that there was no=20
> overlap), that would probably be a win.
>=20
Yes, default is to tickle only 1 idler. However, as we offer that as a
command line option, I think we should consider what could happen if one
disables it.

I double checked this on Linux and, mutatis mutandis, they sort of go
the way I was suggesting, i.e., "pinging" the CPUs with affinity to the
task that will likely stay in the runq rather than being picked up
locally. However, there are of course big difference between the two
schedulers and different assumptions being made, thus I'm not really
sure of that being the best thing to do for us.

So, yes, it probably make sense to think about something clever to try
to involve CPUs from both the masks without causing too much overhead.
I'll put that in my TODO List. :-)

> Of course, that's only necessary if:
> * v_C is lower priority than v_W
> * There are no idlers that intersect both v_C and v_W's affinity mask.
>=20
Sure, I said that in the first place, and I don't think checking for
that is too hard... Just a couple of more bitmap ops. But again, I'll
give it some thinking.

> It's probably a good idea though to try to set up a scenario where this=
=20
> might be an issue and see how often it actually happens.
>=20
Definitely, before trying to "fix" it, I'm interested in finding out
what I'd be actually fixing. Will do that.

Thanks for taking time to check and answer this! :-)
Dario

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-svvlkOFhygR0X8Od8Q4Z
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlCIG/UACgkQk4XaBE3IOsQ9NwCfVUC/m2bq0P3eUGiJ9nPfmVp+
LmYAnRlw7XBotD+2F3VGsFkzPcHBI4sI
=Bvht
-----END PGP SIGNATURE-----

--=-svvlkOFhygR0X8Od8Q4Z--



--===============1651033115773789615==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1651033115773789615==--



From xen-devel-bounces@lists.xen.org Wed Oct 24 16:59:18 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 16:59:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR4IG-0003zD-7w; Wed, 24 Oct 2012 16:59:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR4IF-0003z6-8V
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 16:58:59 +0000
Received: from [85.158.143.35:48060] by server-1.bemta-4.messagelabs.com id
	00/D5-19134-25E18805; Wed, 24 Oct 2012 16:58:58 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1351097936!12556181!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2089 invoked from network); 24 Oct 2012 16:58:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 16:58:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15365979"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 16:58:56 +0000
Received: from mac.citrite.net (10.31.3.235) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 17:58:56 +0100
From: Roger Pau Monne 
To: 
Date: Wed, 24 Oct 2012 18:58:45 +0200
Message-ID: <1351097925-26221-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
MIME-Version: 1.0
Cc: Oliver Chick , konrad.wilk@oracle.com,
	linux-kernel@vger.kernel.org, Roger Pau Monne 
Subject: [Xen-devel] [PATCH v2] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch implements persistent grants for the xen-blk{front,back}
mechanism. The effect of this change is to reduce the number of unmap
operations performed, since they cause a (costly) TLB shootdown. This
allows the I/O performance to scale better when a large number of VMs
are performing I/O.

Previously, the blkfront driver was supplied a bvec[] from the request
queue. This was granted to dom0; dom0 performed the I/O and wrote
directly into the grant-mapped memory and unmapped it; blkfront then
removed foreign access for that grant. The cost of unmapping scales
badly with the number of CPUs in Dom0. An experiment showed that when
Dom0 has 24 VCPUs, and guests are performing parallel I/O to a
ramdisk, the IPIs from performing unmap's is a bottleneck at 5 guests
(at which point 650,000 IOPS are being performed in total). If more
than 5 guests are used, the performance declines. By 10 guests, only
400,000 IOPS are being performed.

This patch improves performance by only unmapping when the connection
between blkfront and back is broken.

On startup blkfront notifies blkback that it is using persistent
grants, and blkback will do the same. If blkback is not capable of
persistent mapping, blkfront will still use the same grants, since it
is compatible with the previous protocol, and simplifies the code
complexity in blkfront.

To perform a read, in persistent mode, blkfront uses a separate pool
of pages that it maps to dom0. When a request comes in, blkfront
transmutes the request so that blkback will write into one of these
free pages. Blkback keeps note of which grefs it has already
mapped. When a new ring request comes to blkback, it looks to see if
it has already mapped that page. If so, it will not map it again. If
the page hasn't been previously mapped, it is mapped now, and a record
is kept of this mapping. Blkback proceeds as usual. When blkfront is
notified that blkback has completed a request, it memcpy's from the
shared memory, into the bvec supplied. A record that the {gref, page}
tuple is mapped, and not inflight is kept.

Writes are similar, except that the memcpy is peformed from the
supplied bvecs, into the shared pages, before the request is put onto
the ring.

Blkback stores a mapping of grefs=>{page mapped to by gref} in
a red-black tree. As the grefs are not known apriori, and provide no
guarantees on their ordering, we have to perform a search
through this tree to find the page, for every gref we receive. This
operation takes O(log n) time in the worst case. In blkfront grants
are stored using a single linked list.

The maximum number of grants that blkback will persistenly map is
currently set to RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, to
prevent a malicios guest from attempting a DoS, by supplying fresh
grefs, causing the Dom0 kernel to map excessively. If a guest
is using persistent grants and exceeds the maximum number of grants to
map persistenly the newly passed grefs will be mapped and unmaped.
Using this approach, we can have requests that mix persistent and
non-persistent grants, and we need to handle them correctly.
This allows us to set the maximum number of persistent grants to a
lower value than RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, although
setting it will lead to unpredictable performance.

In writing this patch, the question arrises as to if the additional
cost of performing memcpys in the guest (to/from the pool of granted
pages) outweigh the gains of not performing TLB shootdowns. The answer
to that question is `no'. There appears to be very little, if any
additional cost to the guest of using persistent grants. There is
perhaps a small saving, from the reduced number of hypercalls
performed in granting, and ending foreign access.

Signed-off-by: Oliver Chick 
Signed-off-by: Roger Pau Monne 
Cc: 
Cc: 
---
Changes since v1:
 * Changed the unmap_seg array to a bitmap.
 * Only report using persistent grants in blkfront if blkback supports
   it.
 * Reword some comments.
 * Fix a bug when setting the handler, index j was not incremented
   correctly.
 * Check that the tree of grants in blkback is not empty before
   iterating over it when doing the cleanup.
 * Rebase on top of linux-net.
---
Benchmarks showing the impact of this patch in blk performance can be
found at:

http://xenbits.xensource.com/people/royger/persistent_grants/
---
 drivers/block/xen-blkback/blkback.c |  292 ++++++++++++++++++++++++++++++++---
 drivers/block/xen-blkback/common.h  |   17 ++
 drivers/block/xen-blkback/xenbus.c  |   23 +++-
 drivers/block/xen-blkfront.c        |  197 ++++++++++++++++++++----
 4 files changed, 474 insertions(+), 55 deletions(-)

diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
index 280a138..663d42d 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -79,6 +80,7 @@ struct pending_req {
 	unsigned short		operation;
 	int			status;
 	struct list_head	free_list;
+	DECLARE_BITMAP(unmap_seg, BLKIF_MAX_SEGMENTS_PER_REQUEST);
 };
 
 #define BLKBACK_INVALID_HANDLE (~0)
@@ -99,6 +101,36 @@ struct xen_blkbk {
 static struct xen_blkbk *blkbk;
 
 /*
+ * Maximum number of grant pages that can be mapped in blkback.
+ * BLKIF_MAX_SEGMENTS_PER_REQUEST * RING_SIZE is the maximum number of
+ * pages that blkback will persistently map.
+ * Currently, this is:
+ * RING_SIZE = 32 (for all known ring types)
+ * BLKIF_MAX_SEGMENTS_PER_REQUEST = 11
+ * sizeof(struct persistent_gnt) = 48
+ * So the maximum memory used to store the grants is:
+ * 32 * 11 * 48 = 16896 bytes
+ */
+static inline unsigned int max_mapped_grant_pages(enum blkif_protocol protocol)
+{
+	switch (protocol) {
+	case BLKIF_PROTOCOL_NATIVE:
+		return __CONST_RING_SIZE(blkif, PAGE_SIZE) *
+			   BLKIF_MAX_SEGMENTS_PER_REQUEST;
+	case BLKIF_PROTOCOL_X86_32:
+		return __CONST_RING_SIZE(blkif_x86_32, PAGE_SIZE) *
+			   BLKIF_MAX_SEGMENTS_PER_REQUEST;
+	case BLKIF_PROTOCOL_X86_64:
+		return __CONST_RING_SIZE(blkif_x86_64, PAGE_SIZE) *
+			   BLKIF_MAX_SEGMENTS_PER_REQUEST;
+	default:
+		BUG();
+	}
+	return 0;
+}
+
+
+/*
  * Little helpful macro to figure out the index and virtual address of the
  * pending_pages[..]. For each 'pending_req' we have have up to
  * BLKIF_MAX_SEGMENTS_PER_REQUEST (11) pages. The seg would be from 0 through
@@ -129,6 +161,57 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 static void make_response(struct xen_blkif *blkif, u64 id,
 			  unsigned short op, int st);
 
+#define foreach_grant(pos, rbtree, node) \
+	for ((pos) = container_of(rb_first((rbtree)), typeof(*(pos)), node); \
+	     &(pos)->node != NULL; \
+	     (pos) = container_of(rb_next(&(pos)->node), typeof(*(pos)), node))
+
+
+static void add_persistent_gnt(struct rb_root *root,
+			       struct persistent_gnt *persistent_gnt)
+{
+	struct rb_node **new = &(root->rb_node), *parent = NULL;
+	struct persistent_gnt *this;
+
+	/* Figure out where to put new node */
+	while (*new) {
+		this = container_of(*new, struct persistent_gnt, node);
+
+		parent = *new;
+		if (persistent_gnt->gnt < this->gnt)
+			new = &((*new)->rb_left);
+		else if (persistent_gnt->gnt > this->gnt)
+			new = &((*new)->rb_right);
+		else {
+			pr_alert(DRV_PFX " trying to add a gref that's already in the tree\n");
+			BUG();
+		}
+	}
+
+	/* Add new node and rebalance tree. */
+	rb_link_node(&(persistent_gnt->node), parent, new);
+	rb_insert_color(&(persistent_gnt->node), root);
+}
+
+static struct persistent_gnt *get_persistent_gnt(struct rb_root *root,
+						 grant_ref_t gref)
+{
+	struct persistent_gnt *data;
+	struct rb_node *node = root->rb_node;
+
+	while (node) {
+		data = container_of(node, struct persistent_gnt, node);
+
+		if (gref < data->gnt)
+			node = node->rb_left;
+		else if (gref > data->gnt)
+			node = node->rb_right;
+		else
+			return data;
+	}
+	return NULL;
+}
+
 /*
  * Retrieve from the 'pending_reqs' a free pending_req structure to be used.
  */
@@ -275,6 +358,11 @@ int xen_blkif_schedule(void *arg)
 {
 	struct xen_blkif *blkif = arg;
 	struct xen_vbd *vbd = &blkif->vbd;
+	struct gnttab_unmap_grant_ref unmap[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct persistent_gnt *persistent_gnt;
+	int ret = 0;
+	int segs_to_unmap = 0;
 
 	xen_blkif_get(blkif);
 
@@ -302,6 +390,36 @@ int xen_blkif_schedule(void *arg)
 			print_stats(blkif);
 	}
 
+	/* Free all persistent grant pages */
+	if (!RB_EMPTY_ROOT(&blkif->persistent_gnts)) {
+		foreach_grant(persistent_gnt, &blkif->persistent_gnts, node) {
+			BUG_ON(persistent_gnt->handle ==
+				BLKBACK_INVALID_HANDLE);
+			gnttab_set_unmap_op(&unmap[segs_to_unmap],
+			    (unsigned long) pfn_to_kaddr(page_to_pfn(
+				persistent_gnt->page)),
+			    GNTMAP_host_map,
+			    persistent_gnt->handle);
+
+			pages[segs_to_unmap] = persistent_gnt->page;
+			rb_erase(&persistent_gnt->node,
+				&blkif->persistent_gnts);
+			kfree(persistent_gnt);
+			blkif->persistent_gnt_c--;
+
+			if (++segs_to_unmap == BLKIF_MAX_SEGMENTS_PER_REQUEST ||
+				!rb_next(&persistent_gnt->node)) {
+				ret = gnttab_unmap_refs(unmap, NULL, pages,
+							segs_to_unmap);
+				BUG_ON(ret);
+				segs_to_unmap = 0;
+			}
+		}
+	}
+
+	BUG_ON(blkif->persistent_gnt_c != 0);
+	BUG_ON(!RB_EMPTY_ROOT(&blkif->persistent_gnts));
+
 	if (log_stats)
 		print_stats(blkif);
 
@@ -328,6 +446,8 @@ static void xen_blkbk_unmap(struct pending_req *req)
 	int ret;
 
 	for (i = 0; i < req->nr_pages; i++) {
+		if (!test_bit(i, req->unmap_seg))
+			continue;
 		handle = pending_handle(req, i);
 		if (handle == BLKBACK_INVALID_HANDLE)
 			continue;
@@ -344,12 +464,26 @@ static void xen_blkbk_unmap(struct pending_req *req)
 
 static int xen_blkbk_map(struct blkif_request *req,
 			 struct pending_req *pending_req,
-			 struct seg_buf seg[])
+			 struct seg_buf seg[],
+			 struct page *pages[])
 {
 	struct gnttab_map_grant_ref map[BLKIF_MAX_SEGMENTS_PER_REQUEST];
-	int i;
+	struct persistent_gnt *persistent_gnts[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct page *pages_to_gnt[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct persistent_gnt *persistent_gnt = NULL;
+	struct xen_blkif *blkif = pending_req->blkif;
+	phys_addr_t addr = 0;
+	int i, j;
+	bool new_map;
 	int nseg = req->u.rw.nr_segments;
+	int segs_to_map = 0;
 	int ret = 0;
+	int use_persistent_gnts;
+
+	use_persistent_gnts = (blkif->vbd.feature_gnt_persistent);
+
+	BUG_ON(blkif->persistent_gnt_c >
+		   max_mapped_grant_pages(pending_req->blkif->blk_protocol));
 
 	/*
 	 * Fill out preq.nr_sects with proper amount of sectors, and setup
@@ -359,36 +493,143 @@ static int xen_blkbk_map(struct blkif_request *req,
 	for (i = 0; i < nseg; i++) {
 		uint32_t flags;
 
-		flags = GNTMAP_host_map;
-		if (pending_req->operation != BLKIF_OP_READ)
-			flags |= GNTMAP_readonly;
-		gnttab_set_map_op(&map[i], vaddr(pending_req, i), flags,
-				  req->u.rw.seg[i].gref,
-				  pending_req->blkif->domid);
+		if (use_persistent_gnts)
+			persistent_gnt = get_persistent_gnt(
+				&blkif->persistent_gnts,
+				req->u.rw.seg[i].gref);
+
+		if (persistent_gnt) {
+			/*
+			 * We are using persistent grants and
+			 * the grant is already mapped
+			 */
+			new_map = 0;
+		} else if (use_persistent_gnts &&
+			   blkif->persistent_gnt_c <
+			   max_mapped_grant_pages(blkif->blk_protocol)) {
+			/*
+			 * We are using persistent grants, the grant is
+			 * not mapped but we have room for it
+			 */
+			new_map = 1;
+			persistent_gnt = kzalloc(
+				sizeof(struct persistent_gnt),
+				GFP_KERNEL);
+			if (!persistent_gnt)
+				return -ENOMEM;
+			persistent_gnt->page = alloc_page(GFP_KERNEL);
+			if (!persistent_gnt->page) {
+				kfree(persistent_gnt);
+				return -ENOMEM;
+			}
+			persistent_gnt->gnt = req->u.rw.seg[i].gref;
+
+			pages_to_gnt[segs_to_map] =
+				persistent_gnt->page;
+			addr = (unsigned long) pfn_to_kaddr(
+				page_to_pfn(persistent_gnt->page));
+
+			add_persistent_gnt(&blkif->persistent_gnts,
+				persistent_gnt);
+			blkif->persistent_gnt_c++;
+			pr_debug(DRV_PFX " grant %u added to the tree of persistent grants, using %u/%u\n",
+				 persistent_gnt->gnt, blkif->persistent_gnt_c,
+				 max_mapped_grant_pages(blkif->blk_protocol));
+		} else {
+			/*
+			 * We are either using persistent grants and
+			 * hit the maximum limit of grants mapped,
+			 * or we are not using persistent grants.
+			 */
+			if (use_persistent_gnts &&
+				!blkif->vbd.overflow_max_grants) {
+				blkif->vbd.overflow_max_grants = 1;
+				pr_alert(DRV_PFX " domain %u, device %#x is using maximum number of persistent grants\n",
+					 blkif->domid, blkif->vbd.handle);
+			}
+			new_map = 1;
+			pages[i] = blkbk->pending_page(pending_req, i);
+			addr = vaddr(pending_req, i);
+			pages_to_gnt[segs_to_map] =
+				blkbk->pending_page(pending_req, i);
+		}
+
+		if (persistent_gnt) {
+			pages[i] = persistent_gnt->page;
+			persistent_gnts[i] = persistent_gnt;
+		} else {
+			persistent_gnts[i] = NULL;
+		}
+
+		if (new_map) {
+			flags = GNTMAP_host_map;
+			if (!persistent_gnt &&
+			    (pending_req->operation != BLKIF_OP_READ))
+				flags |= GNTMAP_readonly;
+			gnttab_set_map_op(&map[segs_to_map++], addr,
+					  flags, req->u.rw.seg[i].gref,
+					  blkif->domid);
+		}
 	}
 
-	ret = gnttab_map_refs(map, NULL, &blkbk->pending_page(pending_req, 0), nseg);
-	BUG_ON(ret);
+	if (segs_to_map) {
+		ret = gnttab_map_refs(map, NULL, pages_to_gnt, segs_to_map);
+		BUG_ON(ret);
+	}
 
 	/*
 	 * Now swizzle the MFN in our domain with the MFN from the other domain
 	 * so that when we access vaddr(pending_req,i) it has the contents of
 	 * the page from the other domain.
 	 */
-	for (i = 0; i < nseg; i++) {
-		if (unlikely(map[i].status != 0)) {
-			pr_debug(DRV_PFX "invalid buffer -- could not remap it\n");
-			map[i].handle = BLKBACK_INVALID_HANDLE;
-			ret |= 1;
+	bitmap_zero(pending_req->unmap_seg, BLKIF_MAX_SEGMENTS_PER_REQUEST);
+	for (i = 0, j = 0; i < nseg; i++) {
+		if (!persistent_gnts[i] || !persistent_gnts[i]->handle) {
+			/* This is a newly mapped grant */
+			BUG_ON(j >= segs_to_map);
+			if (unlikely(map[j].status != 0)) {
+				pr_debug(DRV_PFX "invalid buffer -- could not remap it\n");
+				map[j].handle = BLKBACK_INVALID_HANDLE;
+				ret |= 1;
+				if (persistent_gnts[i]) {
+					rb_erase(&persistent_gnts[i]->node,
+						 &blkif->persistent_gnts);
+					blkif->persistent_gnt_c--;
+					kfree(persistent_gnts[i]);
+					persistent_gnts[i] = NULL;
+				}
+			}
+		}
+		if (persistent_gnts[i]) {
+			if (!persistent_gnts[i]->handle) {
+				/*
+				 * If this is a new persistent grant
+				 * save the handler
+				 */
+				persistent_gnts[i]->handle = map[j].handle;
+				persistent_gnts[i]->dev_bus_addr =
+					map[j++].dev_bus_addr;
+			}
+			pending_handle(pending_req, i) =
+				persistent_gnts[i]->handle;
+
+			if (ret)
+				continue;
+
+			seg[i].buf = persistent_gnts[i]->dev_bus_addr |
+				(req->u.rw.seg[i].first_sect << 9);
+		} else {
+			pending_handle(pending_req, i) = map[j].handle;
+			bitmap_set(pending_req->unmap_seg, i, 1);
+
+			if (ret) {
+				j++;
+				continue;
+			}
+
+			seg[i].buf = map[j++].dev_bus_addr |
+				(req->u.rw.seg[i].first_sect << 9);
 		}
-
-		pending_handle(pending_req, i) = map[i].handle;
-
-		if (ret)
-			continue;
-
-		seg[i].buf  = map[i].dev_bus_addr |
-			(req->u.rw.seg[i].first_sect << 9);
 	}
 	return ret;
 }
@@ -591,6 +832,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 	int operation;
 	struct blk_plug plug;
 	bool drain = false;
+	struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 
 	switch (req->operation) {
 	case BLKIF_OP_READ:
@@ -677,7 +919,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 	 * the hypercall to unmap the grants - that is all done in
 	 * xen_blkbk_unmap.
 	 */
-	if (xen_blkbk_map(req, pending_req, seg))
+	if (xen_blkbk_map(req, pending_req, seg, pages))
 		goto fail_flush;
 
 	/*
@@ -689,7 +931,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 	for (i = 0; i < nseg; i++) {
 		while ((bio == NULL) ||
 		       (bio_add_page(bio,
-				     blkbk->pending_page(pending_req, i),
+				     pages[i],
 				     seg[i].nsec << 9,
 				     seg[i].buf & ~PAGE_MASK) == 0)) {
 
diff --git a/drivers/block/xen-blkback/common.h b/drivers/block/xen-blkback/common.h
index 9ad3b5e..ae7951f 100644
--- a/drivers/block/xen-blkback/common.h
+++ b/drivers/block/xen-blkback/common.h
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -160,10 +161,22 @@ struct xen_vbd {
 	sector_t		size;
 	bool			flush_support;
 	bool			discard_secure;
+
+	unsigned int		feature_gnt_persistent:1;
+	unsigned int		overflow_max_grants:1;
 };
 
 struct backend_info;
 
+
+struct persistent_gnt {
+	struct page *page;
+	grant_ref_t gnt;
+	grant_handle_t handle;
+	uint64_t dev_bus_addr;
+	struct rb_node node;
+};
+
 struct xen_blkif {
 	/* Unique identifier for this interface. */
 	domid_t			domid;
@@ -190,6 +203,10 @@ struct xen_blkif {
 	struct task_struct	*xenblkd;
 	unsigned int		waiting_reqs;
 
+	/* tree to store persistent grants */
+	struct rb_root		persistent_gnts;
+	unsigned int		persistent_gnt_c;
+
 	/* statistics */
 	unsigned long		st_print;
 	int			st_rd_req;
diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c
index 4f66171..b225026 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -118,6 +118,7 @@ static struct xen_blkif *xen_blkif_alloc(domid_t domid)
 	atomic_set(&blkif->drain, 0);
 	blkif->st_print = jiffies;
 	init_waitqueue_head(&blkif->waiting_to_free);
+	blkif->persistent_gnts.rb_node = NULL;
 
 	return blkif;
 }
@@ -673,6 +674,13 @@ again:
 
 	xen_blkbk_barrier(xbt, be, be->blkif->vbd.flush_support);
 
+	err = xenbus_printf(xbt, dev->nodename, "feature-persistent", "%u", 1);
+	if (err) {
+		xenbus_dev_fatal(dev, err, "writing %s/feature-persistent",
+				 dev->nodename);
+		goto abort;
+	}
+
 	err = xenbus_printf(xbt, dev->nodename, "sectors", "%llu",
 			    (unsigned long long)vbd_sz(&be->blkif->vbd));
 	if (err) {
@@ -721,6 +729,7 @@ static int connect_ring(struct backend_info *be)
 	struct xenbus_device *dev = be->dev;
 	unsigned long ring_ref;
 	unsigned int evtchn;
+	unsigned int pers_grants;
 	char protocol[64] = "";
 	int err;
 
@@ -750,8 +759,18 @@ static int connect_ring(struct backend_info *be)
 		xenbus_dev_fatal(dev, err, "unknown fe protocol %s", protocol);
 		return -1;
 	}
-	pr_info(DRV_PFX "ring-ref %ld, event-channel %d, protocol %d (%s)\n",
-		ring_ref, evtchn, be->blkif->blk_protocol, protocol);
+	err = xenbus_gather(XBT_NIL, dev->otherend,
+			    "feature-persistent-grants", "%u",
+			    &pers_grants, NULL);
+	if (err)
+		pers_grants = 0;
+
+	be->blkif->vbd.feature_gnt_persistent = pers_grants;
+	be->blkif->vbd.overflow_max_grants = 0;
+
+	pr_info(DRV_PFX "ring-ref %ld, event-channel %d, protocol %d (%s) %s\n",
+		ring_ref, evtchn, be->blkif->blk_protocol, protocol,
+		pers_grants ? "persistent grants" : "");
 
 	/* Map the shared frame, irq etc. */
 	err = xen_blkif_map(be->blkif, ring_ref, evtchn);
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 007db89..911d733 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -44,6 +44,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -64,10 +65,17 @@ enum blkif_state {
 	BLKIF_STATE_SUSPENDED,
 };
 
+struct grant {
+	grant_ref_t gref;
+	unsigned long pfn;
+	struct llist_node node;
+};
+
 struct blk_shadow {
 	struct blkif_request req;
 	struct request *request;
 	unsigned long frame[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct grant *grants_used[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 };
 
 static DEFINE_MUTEX(blkfront_mutex);
@@ -97,6 +105,8 @@ struct blkfront_info
 	struct work_struct work;
 	struct gnttab_free_callback callback;
 	struct blk_shadow shadow[BLK_RING_SIZE];
+	struct llist_head persistent_gnts;
+	unsigned int persistent_gnts_c;
 	unsigned long shadow_free;
 	unsigned int feature_flush;
 	unsigned int flush_op;
@@ -104,6 +114,7 @@ struct blkfront_info
 	unsigned int feature_secdiscard:1;
 	unsigned int discard_granularity;
 	unsigned int discard_alignment;
+	unsigned int feature_persistent:1;
 	int is_ready;
 };
 
@@ -287,21 +298,36 @@ static int blkif_queue_request(struct request *req)
 	unsigned long id;
 	unsigned int fsect, lsect;
 	int i, ref;
+
+	/*
+	 * Used to store if we are able to queue the request by just using
+	 * existing persistent grants, or if we have to get new grants,
+	 * as there are not sufficiently many free.
+	 */
+	bool new_persistent_gnts;
 	grant_ref_t gref_head;
+	struct page *granted_page;
+	struct grant *gnt_list_entry = NULL;
 	struct scatterlist *sg;
 
 	if (unlikely(info->connected != BLKIF_STATE_CONNECTED))
 		return 1;
 
-	if (gnttab_alloc_grant_references(
-		BLKIF_MAX_SEGMENTS_PER_REQUEST, &gref_head) < 0) {
-		gnttab_request_free_callback(
-			&info->callback,
-			blkif_restart_queue_callback,
-			info,
-			BLKIF_MAX_SEGMENTS_PER_REQUEST);
-		return 1;
-	}
+	/* Check if we have enought grants to allocate a requests */
+	if (info->persistent_gnts_c < BLKIF_MAX_SEGMENTS_PER_REQUEST) {
+		new_persistent_gnts = 1;
+		if (gnttab_alloc_grant_references(
+		    BLKIF_MAX_SEGMENTS_PER_REQUEST - info->persistent_gnts_c,
+		    &gref_head) < 0) {
+			gnttab_request_free_callback(
+				&info->callback,
+				blkif_restart_queue_callback,
+				info,
+				BLKIF_MAX_SEGMENTS_PER_REQUEST);
+			return 1;
+		}
+	} else
+		new_persistent_gnts = 0;
 
 	/* Fill out a communications ring structure. */
 	ring_req = RING_GET_REQUEST(&info->ring, info->ring.req_prod_pvt);
@@ -341,18 +367,73 @@ static int blkif_queue_request(struct request *req)
 		       BLKIF_MAX_SEGMENTS_PER_REQUEST);
 
 		for_each_sg(info->sg, sg, ring_req->u.rw.nr_segments, i) {
-			buffer_mfn = pfn_to_mfn(page_to_pfn(sg_page(sg)));
 			fsect = sg->offset >> 9;
 			lsect = fsect + (sg->length >> 9) - 1;
-			/* install a grant reference. */
-			ref = gnttab_claim_grant_reference(&gref_head);
-			BUG_ON(ref == -ENOSPC);
 
-			gnttab_grant_foreign_access_ref(
-					ref,
+			if (info->persistent_gnts_c) {
+				BUG_ON(llist_empty(&info->persistent_gnts));
+				gnt_list_entry = llist_entry(
+					llist_del_first(&info->persistent_gnts),
+					struct grant, node);
+
+				ref = gnt_list_entry->gref;
+				buffer_mfn = pfn_to_mfn(gnt_list_entry->pfn);
+				info->persistent_gnts_c--;
+			} else {
+				ref = gnttab_claim_grant_reference(&gref_head);
+				BUG_ON(ref == -ENOSPC);
+
+				gnt_list_entry =
+					kmalloc(sizeof(struct grant),
+							 GFP_ATOMIC);
+				if (!gnt_list_entry)
+					return -ENOMEM;
+
+				granted_page = alloc_page(GFP_ATOMIC);
+				if (!granted_page) {
+					kfree(gnt_list_entry);
+					return -ENOMEM;
+				}
+
+				gnt_list_entry->pfn =
+					page_to_pfn(granted_page);
+				gnt_list_entry->gref = ref;
+
+				buffer_mfn = pfn_to_mfn(page_to_pfn(
+								granted_page));
+				gnttab_grant_foreign_access_ref(ref,
 					info->xbdev->otherend_id,
-					buffer_mfn,
-					rq_data_dir(req));
+					buffer_mfn, 0);
+			}
+
+			info->shadow[id].grants_used[i] = gnt_list_entry;
+
+			if (rq_data_dir(req)) {
+				char *bvec_data;
+				void *shared_data;
+
+				BUG_ON(sg->offset + sg->length > PAGE_SIZE);
+
+				shared_data = kmap_atomic(
+					pfn_to_page(gnt_list_entry->pfn));
+				bvec_data = kmap_atomic(sg_page(sg));
+
+				/*
+				 * this does not wipe data stored outside the
+				 * range sg->offset..sg->offset+sg->length.
+				 * Therefore, blkback *could* see data from
+				 * previous requests. This is OK as long as
+				 * persistent grants are shared with just one
+				 * domain. It may need refactoring if this
+				 * changes
+				 */
+				memcpy(shared_data + sg->offset,
+				       bvec_data   + sg->offset,
+				       sg->length);
+
+				kunmap_atomic(bvec_data);
+				kunmap_atomic(shared_data);
+			}
 
 			info->shadow[id].frame[i] = mfn_to_pfn(buffer_mfn);
 			ring_req->u.rw.seg[i] =
@@ -368,7 +449,8 @@ static int blkif_queue_request(struct request *req)
 	/* Keep a private copy so we can reissue requests when recovering. */
 	info->shadow[id].req = *ring_req;
 
-	gnttab_free_grant_references(gref_head);
+	if (new_persistent_gnts)
+		gnttab_free_grant_references(gref_head);
 
 	return 0;
 }
@@ -480,12 +562,13 @@ static int xlvbd_init_blk_queue(struct gendisk *gd, u16 sector_size)
 static void xlvbd_flush(struct blkfront_info *info)
 {
 	blk_queue_flush(info->rq, info->feature_flush);
-	printk(KERN_INFO "blkfront: %s: %s: %s\n",
+	printk(KERN_INFO "blkfront: %s: %s: %s %s\n",
 	       info->gd->disk_name,
 	       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
 		"barrier" : (info->flush_op == BLKIF_OP_FLUSH_DISKCACHE ?
 		"flush diskcache" : "barrier or flush"),
-	       info->feature_flush ? "enabled" : "disabled");
+	       info->feature_flush ? "enabled" : "disabled",
+	       info->feature_persistent ? "using persistent grants" : "");
 }
 
 static int xen_translate_vdev(int vdevice, int *minor, unsigned int *offset)
@@ -707,6 +790,9 @@ static void blkif_restart_queue(struct work_struct *work)
 
 static void blkif_free(struct blkfront_info *info, int suspend)
 {
+	struct llist_node *all_gnts;
+	struct grant *persistent_gnt;
+
 	/* Prevent new requests being issued until we fix things up. */
 	spin_lock_irq(&info->io_lock);
 	info->connected = suspend ?
@@ -714,6 +800,17 @@ static void blkif_free(struct blkfront_info *info, int suspend)
 	/* No more blkif_request(). */
 	if (info->rq)
 		blk_stop_queue(info->rq);
+
+	/* Remove all persistent grants */
+	if (info->persistent_gnts_c) {
+		all_gnts = llist_del_all(&info->persistent_gnts);
+		llist_for_each_entry(persistent_gnt, all_gnts, node) {
+			gnttab_end_foreign_access(persistent_gnt->gref, 0, 0UL);
+			kfree(persistent_gnt);
+		}
+		info->persistent_gnts_c = 0;
+	}
+
 	/* No more gnttab callback work. */
 	gnttab_cancel_free_callback(&info->callback);
 	spin_unlock_irq(&info->io_lock);
@@ -734,13 +831,42 @@ static void blkif_free(struct blkfront_info *info, int suspend)
 
 }
 
-static void blkif_completion(struct blk_shadow *s)
+static void blkif_completion(struct blk_shadow *s, struct blkfront_info *info,
+			     struct blkif_response *bret)
 {
 	int i;
-	/* Do not let BLKIF_OP_DISCARD as nr_segment is in the same place
-	 * flag. */
-	for (i = 0; i < s->req.u.rw.nr_segments; i++)
-		gnttab_end_foreign_access(s->req.u.rw.seg[i].gref, 0, 0UL);
+	struct bio_vec *bvec;
+	struct req_iterator iter;
+	unsigned long flags;
+	char *bvec_data;
+	void *shared_data;
+	unsigned int offset = 0;
+
+	if (bret->operation == BLKIF_OP_READ) {
+		/*
+		 * Copy the data received from the backend into the bvec.
+		 * Since bv_offset can be different than 0, and bv_len different
+		 * than PAGE_SIZE, we have to keep track of the current offset,
+		 * to be sure we are copying the data from the right shared page.
+		 */
+		rq_for_each_segment(bvec, s->request, iter) {
+			BUG_ON((bvec->bv_offset + bvec->bv_len) > PAGE_SIZE);
+			i = offset >> PAGE_SHIFT;
+			shared_data = kmap_atomic(
+				pfn_to_page(s->grants_used[i]->pfn));
+			bvec_data = bvec_kmap_irq(bvec, &flags);
+			memcpy(bvec_data, shared_data + bvec->bv_offset,
+				bvec->bv_len);
+			bvec_kunmap_irq(bvec_data, &flags);
+			kunmap_atomic(shared_data);
+			offset += bvec->bv_len;
+		}
+	}
+	/* Add the persistent grant into the list of free grants */
+	for (i = 0; i < s->req.u.rw.nr_segments; i++) {
+		llist_add(&s->grants_used[i]->node, &info->persistent_gnts);
+		info->persistent_gnts_c++;
+	}
 }
 
 static irqreturn_t blkif_interrupt(int irq, void *dev_id)
@@ -783,7 +909,7 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
 		req  = info->shadow[id].request;
 
 		if (bret->operation != BLKIF_OP_DISCARD)
-			blkif_completion(&info->shadow[id]);
+			blkif_completion(&info->shadow[id], info, bret);
 
 		if (add_id_to_freelist(info, id)) {
 			WARN(1, "%s: response to %s (id %ld) couldn't be recycled!\n",
@@ -942,6 +1068,11 @@ again:
 		message = "writing protocol";
 		goto abort_transaction;
 	}
+	err = xenbus_printf(xbt, dev->nodename,
+			    "feature-persistent-grants", "%u", 1);
+	if (err)
+		dev_warn(&dev->dev,
+			 "writing persistent grants feature to xenbus");
 
 	err = xenbus_transaction_end(xbt, 0);
 	if (err) {
@@ -1029,6 +1160,8 @@ static int blkfront_probe(struct xenbus_device *dev,
 	spin_lock_init(&info->io_lock);
 	info->xbdev = dev;
 	info->vdevice = vdevice;
+	init_llist_head(&info->persistent_gnts);
+	info->persistent_gnts_c = 0;
 	info->connected = BLKIF_STATE_DISCONNECTED;
 	INIT_WORK(&info->work, blkif_restart_queue);
 
@@ -1093,7 +1226,7 @@ static int blkif_recover(struct blkfront_info *info)
 					req->u.rw.seg[j].gref,
 					info->xbdev->otherend_id,
 					pfn_to_mfn(info->shadow[req->u.rw.id].frame[j]),
-					rq_data_dir(info->shadow[req->u.rw.id].request));
+					0);
 		}
 		info->shadow[req->u.rw.id].req = *req;
 
@@ -1225,7 +1358,7 @@ static void blkfront_connect(struct blkfront_info *info)
 	unsigned long sector_size;
 	unsigned int binfo;
 	int err;
-	int barrier, flush, discard;
+	int barrier, flush, discard, persistent;
 
 	switch (info->connected) {
 	case BLKIF_STATE_CONNECTED:
@@ -1303,6 +1436,14 @@ static void blkfront_connect(struct blkfront_info *info)
 	if (!err && discard)
 		blkfront_setup_discard(info);
 
+	err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
+			    "feature-persistent", "%u", &persistent,
+			    NULL);
+	if (err)
+		info->feature_persistent = 0;
+	else
+		info->feature_persistent = persistent;
+
 	err = xlvbd_alloc_gendisk(sectors, info, binfo, sector_size);
 	if (err) {
 		xenbus_dev_fatal(info->xbdev, err, "xlvbd_add at %s",
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 16:59:18 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 16:59:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR4IG-0003zD-7w; Wed, 24 Oct 2012 16:59:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR4IF-0003z6-8V
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 16:58:59 +0000
Received: from [85.158.143.35:48060] by server-1.bemta-4.messagelabs.com id
	00/D5-19134-25E18805; Wed, 24 Oct 2012 16:58:58 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1351097936!12556181!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2089 invoked from network); 24 Oct 2012 16:58:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 16:58:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15365979"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 16:58:56 +0000
Received: from mac.citrite.net (10.31.3.235) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 17:58:56 +0100
From: Roger Pau Monne 
To: 
Date: Wed, 24 Oct 2012 18:58:45 +0200
Message-ID: <1351097925-26221-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
MIME-Version: 1.0
Cc: Oliver Chick , konrad.wilk@oracle.com,
	linux-kernel@vger.kernel.org, Roger Pau Monne 
Subject: [Xen-devel] [PATCH v2] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch implements persistent grants for the xen-blk{front,back}
mechanism. The effect of this change is to reduce the number of unmap
operations performed, since they cause a (costly) TLB shootdown. This
allows the I/O performance to scale better when a large number of VMs
are performing I/O.

Previously, the blkfront driver was supplied a bvec[] from the request
queue. This was granted to dom0; dom0 performed the I/O and wrote
directly into the grant-mapped memory and unmapped it; blkfront then
removed foreign access for that grant. The cost of unmapping scales
badly with the number of CPUs in Dom0. An experiment showed that when
Dom0 has 24 VCPUs, and guests are performing parallel I/O to a
ramdisk, the IPIs from performing unmap's is a bottleneck at 5 guests
(at which point 650,000 IOPS are being performed in total). If more
than 5 guests are used, the performance declines. By 10 guests, only
400,000 IOPS are being performed.

This patch improves performance by only unmapping when the connection
between blkfront and back is broken.

On startup blkfront notifies blkback that it is using persistent
grants, and blkback will do the same. If blkback is not capable of
persistent mapping, blkfront will still use the same grants, since it
is compatible with the previous protocol, and simplifies the code
complexity in blkfront.

To perform a read, in persistent mode, blkfront uses a separate pool
of pages that it maps to dom0. When a request comes in, blkfront
transmutes the request so that blkback will write into one of these
free pages. Blkback keeps note of which grefs it has already
mapped. When a new ring request comes to blkback, it looks to see if
it has already mapped that page. If so, it will not map it again. If
the page hasn't been previously mapped, it is mapped now, and a record
is kept of this mapping. Blkback proceeds as usual. When blkfront is
notified that blkback has completed a request, it memcpy's from the
shared memory, into the bvec supplied. A record that the {gref, page}
tuple is mapped, and not inflight is kept.

Writes are similar, except that the memcpy is peformed from the
supplied bvecs, into the shared pages, before the request is put onto
the ring.

Blkback stores a mapping of grefs=>{page mapped to by gref} in
a red-black tree. As the grefs are not known apriori, and provide no
guarantees on their ordering, we have to perform a search
through this tree to find the page, for every gref we receive. This
operation takes O(log n) time in the worst case. In blkfront grants
are stored using a single linked list.

The maximum number of grants that blkback will persistenly map is
currently set to RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, to
prevent a malicios guest from attempting a DoS, by supplying fresh
grefs, causing the Dom0 kernel to map excessively. If a guest
is using persistent grants and exceeds the maximum number of grants to
map persistenly the newly passed grefs will be mapped and unmaped.
Using this approach, we can have requests that mix persistent and
non-persistent grants, and we need to handle them correctly.
This allows us to set the maximum number of persistent grants to a
lower value than RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, although
setting it will lead to unpredictable performance.

In writing this patch, the question arrises as to if the additional
cost of performing memcpys in the guest (to/from the pool of granted
pages) outweigh the gains of not performing TLB shootdowns. The answer
to that question is `no'. There appears to be very little, if any
additional cost to the guest of using persistent grants. There is
perhaps a small saving, from the reduced number of hypercalls
performed in granting, and ending foreign access.

Signed-off-by: Oliver Chick 
Signed-off-by: Roger Pau Monne 
Cc: 
Cc: 
---
Changes since v1:
 * Changed the unmap_seg array to a bitmap.
 * Only report using persistent grants in blkfront if blkback supports
   it.
 * Reword some comments.
 * Fix a bug when setting the handler, index j was not incremented
   correctly.
 * Check that the tree of grants in blkback is not empty before
   iterating over it when doing the cleanup.
 * Rebase on top of linux-net.
---
Benchmarks showing the impact of this patch in blk performance can be
found at:

http://xenbits.xensource.com/people/royger/persistent_grants/
---
 drivers/block/xen-blkback/blkback.c |  292 ++++++++++++++++++++++++++++++++---
 drivers/block/xen-blkback/common.h  |   17 ++
 drivers/block/xen-blkback/xenbus.c  |   23 +++-
 drivers/block/xen-blkfront.c        |  197 ++++++++++++++++++++----
 4 files changed, 474 insertions(+), 55 deletions(-)

diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
index 280a138..663d42d 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -79,6 +80,7 @@ struct pending_req {
 	unsigned short		operation;
 	int			status;
 	struct list_head	free_list;
+	DECLARE_BITMAP(unmap_seg, BLKIF_MAX_SEGMENTS_PER_REQUEST);
 };
 
 #define BLKBACK_INVALID_HANDLE (~0)
@@ -99,6 +101,36 @@ struct xen_blkbk {
 static struct xen_blkbk *blkbk;
 
 /*
+ * Maximum number of grant pages that can be mapped in blkback.
+ * BLKIF_MAX_SEGMENTS_PER_REQUEST * RING_SIZE is the maximum number of
+ * pages that blkback will persistently map.
+ * Currently, this is:
+ * RING_SIZE = 32 (for all known ring types)
+ * BLKIF_MAX_SEGMENTS_PER_REQUEST = 11
+ * sizeof(struct persistent_gnt) = 48
+ * So the maximum memory used to store the grants is:
+ * 32 * 11 * 48 = 16896 bytes
+ */
+static inline unsigned int max_mapped_grant_pages(enum blkif_protocol protocol)
+{
+	switch (protocol) {
+	case BLKIF_PROTOCOL_NATIVE:
+		return __CONST_RING_SIZE(blkif, PAGE_SIZE) *
+			   BLKIF_MAX_SEGMENTS_PER_REQUEST;
+	case BLKIF_PROTOCOL_X86_32:
+		return __CONST_RING_SIZE(blkif_x86_32, PAGE_SIZE) *
+			   BLKIF_MAX_SEGMENTS_PER_REQUEST;
+	case BLKIF_PROTOCOL_X86_64:
+		return __CONST_RING_SIZE(blkif_x86_64, PAGE_SIZE) *
+			   BLKIF_MAX_SEGMENTS_PER_REQUEST;
+	default:
+		BUG();
+	}
+	return 0;
+}
+
+
+/*
  * Little helpful macro to figure out the index and virtual address of the
  * pending_pages[..]. For each 'pending_req' we have have up to
  * BLKIF_MAX_SEGMENTS_PER_REQUEST (11) pages. The seg would be from 0 through
@@ -129,6 +161,57 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 static void make_response(struct xen_blkif *blkif, u64 id,
 			  unsigned short op, int st);
 
+#define foreach_grant(pos, rbtree, node) \
+	for ((pos) = container_of(rb_first((rbtree)), typeof(*(pos)), node); \
+	     &(pos)->node != NULL; \
+	     (pos) = container_of(rb_next(&(pos)->node), typeof(*(pos)), node))
+
+
+static void add_persistent_gnt(struct rb_root *root,
+			       struct persistent_gnt *persistent_gnt)
+{
+	struct rb_node **new = &(root->rb_node), *parent = NULL;
+	struct persistent_gnt *this;
+
+	/* Figure out where to put new node */
+	while (*new) {
+		this = container_of(*new, struct persistent_gnt, node);
+
+		parent = *new;
+		if (persistent_gnt->gnt < this->gnt)
+			new = &((*new)->rb_left);
+		else if (persistent_gnt->gnt > this->gnt)
+			new = &((*new)->rb_right);
+		else {
+			pr_alert(DRV_PFX " trying to add a gref that's already in the tree\n");
+			BUG();
+		}
+	}
+
+	/* Add new node and rebalance tree. */
+	rb_link_node(&(persistent_gnt->node), parent, new);
+	rb_insert_color(&(persistent_gnt->node), root);
+}
+
+static struct persistent_gnt *get_persistent_gnt(struct rb_root *root,
+						 grant_ref_t gref)
+{
+	struct persistent_gnt *data;
+	struct rb_node *node = root->rb_node;
+
+	while (node) {
+		data = container_of(node, struct persistent_gnt, node);
+
+		if (gref < data->gnt)
+			node = node->rb_left;
+		else if (gref > data->gnt)
+			node = node->rb_right;
+		else
+			return data;
+	}
+	return NULL;
+}
+
 /*
  * Retrieve from the 'pending_reqs' a free pending_req structure to be used.
  */
@@ -275,6 +358,11 @@ int xen_blkif_schedule(void *arg)
 {
 	struct xen_blkif *blkif = arg;
 	struct xen_vbd *vbd = &blkif->vbd;
+	struct gnttab_unmap_grant_ref unmap[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct persistent_gnt *persistent_gnt;
+	int ret = 0;
+	int segs_to_unmap = 0;
 
 	xen_blkif_get(blkif);
 
@@ -302,6 +390,36 @@ int xen_blkif_schedule(void *arg)
 			print_stats(blkif);
 	}
 
+	/* Free all persistent grant pages */
+	if (!RB_EMPTY_ROOT(&blkif->persistent_gnts)) {
+		foreach_grant(persistent_gnt, &blkif->persistent_gnts, node) {
+			BUG_ON(persistent_gnt->handle ==
+				BLKBACK_INVALID_HANDLE);
+			gnttab_set_unmap_op(&unmap[segs_to_unmap],
+			    (unsigned long) pfn_to_kaddr(page_to_pfn(
+				persistent_gnt->page)),
+			    GNTMAP_host_map,
+			    persistent_gnt->handle);
+
+			pages[segs_to_unmap] = persistent_gnt->page;
+			rb_erase(&persistent_gnt->node,
+				&blkif->persistent_gnts);
+			kfree(persistent_gnt);
+			blkif->persistent_gnt_c--;
+
+			if (++segs_to_unmap == BLKIF_MAX_SEGMENTS_PER_REQUEST ||
+				!rb_next(&persistent_gnt->node)) {
+				ret = gnttab_unmap_refs(unmap, NULL, pages,
+							segs_to_unmap);
+				BUG_ON(ret);
+				segs_to_unmap = 0;
+			}
+		}
+	}
+
+	BUG_ON(blkif->persistent_gnt_c != 0);
+	BUG_ON(!RB_EMPTY_ROOT(&blkif->persistent_gnts));
+
 	if (log_stats)
 		print_stats(blkif);
 
@@ -328,6 +446,8 @@ static void xen_blkbk_unmap(struct pending_req *req)
 	int ret;
 
 	for (i = 0; i < req->nr_pages; i++) {
+		if (!test_bit(i, req->unmap_seg))
+			continue;
 		handle = pending_handle(req, i);
 		if (handle == BLKBACK_INVALID_HANDLE)
 			continue;
@@ -344,12 +464,26 @@ static void xen_blkbk_unmap(struct pending_req *req)
 
 static int xen_blkbk_map(struct blkif_request *req,
 			 struct pending_req *pending_req,
-			 struct seg_buf seg[])
+			 struct seg_buf seg[],
+			 struct page *pages[])
 {
 	struct gnttab_map_grant_ref map[BLKIF_MAX_SEGMENTS_PER_REQUEST];
-	int i;
+	struct persistent_gnt *persistent_gnts[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct page *pages_to_gnt[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct persistent_gnt *persistent_gnt = NULL;
+	struct xen_blkif *blkif = pending_req->blkif;
+	phys_addr_t addr = 0;
+	int i, j;
+	bool new_map;
 	int nseg = req->u.rw.nr_segments;
+	int segs_to_map = 0;
 	int ret = 0;
+	int use_persistent_gnts;
+
+	use_persistent_gnts = (blkif->vbd.feature_gnt_persistent);
+
+	BUG_ON(blkif->persistent_gnt_c >
+		   max_mapped_grant_pages(pending_req->blkif->blk_protocol));
 
 	/*
 	 * Fill out preq.nr_sects with proper amount of sectors, and setup
@@ -359,36 +493,143 @@ static int xen_blkbk_map(struct blkif_request *req,
 	for (i = 0; i < nseg; i++) {
 		uint32_t flags;
 
-		flags = GNTMAP_host_map;
-		if (pending_req->operation != BLKIF_OP_READ)
-			flags |= GNTMAP_readonly;
-		gnttab_set_map_op(&map[i], vaddr(pending_req, i), flags,
-				  req->u.rw.seg[i].gref,
-				  pending_req->blkif->domid);
+		if (use_persistent_gnts)
+			persistent_gnt = get_persistent_gnt(
+				&blkif->persistent_gnts,
+				req->u.rw.seg[i].gref);
+
+		if (persistent_gnt) {
+			/*
+			 * We are using persistent grants and
+			 * the grant is already mapped
+			 */
+			new_map = 0;
+		} else if (use_persistent_gnts &&
+			   blkif->persistent_gnt_c <
+			   max_mapped_grant_pages(blkif->blk_protocol)) {
+			/*
+			 * We are using persistent grants, the grant is
+			 * not mapped but we have room for it
+			 */
+			new_map = 1;
+			persistent_gnt = kzalloc(
+				sizeof(struct persistent_gnt),
+				GFP_KERNEL);
+			if (!persistent_gnt)
+				return -ENOMEM;
+			persistent_gnt->page = alloc_page(GFP_KERNEL);
+			if (!persistent_gnt->page) {
+				kfree(persistent_gnt);
+				return -ENOMEM;
+			}
+			persistent_gnt->gnt = req->u.rw.seg[i].gref;
+
+			pages_to_gnt[segs_to_map] =
+				persistent_gnt->page;
+			addr = (unsigned long) pfn_to_kaddr(
+				page_to_pfn(persistent_gnt->page));
+
+			add_persistent_gnt(&blkif->persistent_gnts,
+				persistent_gnt);
+			blkif->persistent_gnt_c++;
+			pr_debug(DRV_PFX " grant %u added to the tree of persistent grants, using %u/%u\n",
+				 persistent_gnt->gnt, blkif->persistent_gnt_c,
+				 max_mapped_grant_pages(blkif->blk_protocol));
+		} else {
+			/*
+			 * We are either using persistent grants and
+			 * hit the maximum limit of grants mapped,
+			 * or we are not using persistent grants.
+			 */
+			if (use_persistent_gnts &&
+				!blkif->vbd.overflow_max_grants) {
+				blkif->vbd.overflow_max_grants = 1;
+				pr_alert(DRV_PFX " domain %u, device %#x is using maximum number of persistent grants\n",
+					 blkif->domid, blkif->vbd.handle);
+			}
+			new_map = 1;
+			pages[i] = blkbk->pending_page(pending_req, i);
+			addr = vaddr(pending_req, i);
+			pages_to_gnt[segs_to_map] =
+				blkbk->pending_page(pending_req, i);
+		}
+
+		if (persistent_gnt) {
+			pages[i] = persistent_gnt->page;
+			persistent_gnts[i] = persistent_gnt;
+		} else {
+			persistent_gnts[i] = NULL;
+		}
+
+		if (new_map) {
+			flags = GNTMAP_host_map;
+			if (!persistent_gnt &&
+			    (pending_req->operation != BLKIF_OP_READ))
+				flags |= GNTMAP_readonly;
+			gnttab_set_map_op(&map[segs_to_map++], addr,
+					  flags, req->u.rw.seg[i].gref,
+					  blkif->domid);
+		}
 	}
 
-	ret = gnttab_map_refs(map, NULL, &blkbk->pending_page(pending_req, 0), nseg);
-	BUG_ON(ret);
+	if (segs_to_map) {
+		ret = gnttab_map_refs(map, NULL, pages_to_gnt, segs_to_map);
+		BUG_ON(ret);
+	}
 
 	/*
 	 * Now swizzle the MFN in our domain with the MFN from the other domain
 	 * so that when we access vaddr(pending_req,i) it has the contents of
 	 * the page from the other domain.
 	 */
-	for (i = 0; i < nseg; i++) {
-		if (unlikely(map[i].status != 0)) {
-			pr_debug(DRV_PFX "invalid buffer -- could not remap it\n");
-			map[i].handle = BLKBACK_INVALID_HANDLE;
-			ret |= 1;
+	bitmap_zero(pending_req->unmap_seg, BLKIF_MAX_SEGMENTS_PER_REQUEST);
+	for (i = 0, j = 0; i < nseg; i++) {
+		if (!persistent_gnts[i] || !persistent_gnts[i]->handle) {
+			/* This is a newly mapped grant */
+			BUG_ON(j >= segs_to_map);
+			if (unlikely(map[j].status != 0)) {
+				pr_debug(DRV_PFX "invalid buffer -- could not remap it\n");
+				map[j].handle = BLKBACK_INVALID_HANDLE;
+				ret |= 1;
+				if (persistent_gnts[i]) {
+					rb_erase(&persistent_gnts[i]->node,
+						 &blkif->persistent_gnts);
+					blkif->persistent_gnt_c--;
+					kfree(persistent_gnts[i]);
+					persistent_gnts[i] = NULL;
+				}
+			}
+		}
+		if (persistent_gnts[i]) {
+			if (!persistent_gnts[i]->handle) {
+				/*
+				 * If this is a new persistent grant
+				 * save the handler
+				 */
+				persistent_gnts[i]->handle = map[j].handle;
+				persistent_gnts[i]->dev_bus_addr =
+					map[j++].dev_bus_addr;
+			}
+			pending_handle(pending_req, i) =
+				persistent_gnts[i]->handle;
+
+			if (ret)
+				continue;
+
+			seg[i].buf = persistent_gnts[i]->dev_bus_addr |
+				(req->u.rw.seg[i].first_sect << 9);
+		} else {
+			pending_handle(pending_req, i) = map[j].handle;
+			bitmap_set(pending_req->unmap_seg, i, 1);
+
+			if (ret) {
+				j++;
+				continue;
+			}
+
+			seg[i].buf = map[j++].dev_bus_addr |
+				(req->u.rw.seg[i].first_sect << 9);
 		}
-
-		pending_handle(pending_req, i) = map[i].handle;
-
-		if (ret)
-			continue;
-
-		seg[i].buf  = map[i].dev_bus_addr |
-			(req->u.rw.seg[i].first_sect << 9);
 	}
 	return ret;
 }
@@ -591,6 +832,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 	int operation;
 	struct blk_plug plug;
 	bool drain = false;
+	struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 
 	switch (req->operation) {
 	case BLKIF_OP_READ:
@@ -677,7 +919,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 	 * the hypercall to unmap the grants - that is all done in
 	 * xen_blkbk_unmap.
 	 */
-	if (xen_blkbk_map(req, pending_req, seg))
+	if (xen_blkbk_map(req, pending_req, seg, pages))
 		goto fail_flush;
 
 	/*
@@ -689,7 +931,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 	for (i = 0; i < nseg; i++) {
 		while ((bio == NULL) ||
 		       (bio_add_page(bio,
-				     blkbk->pending_page(pending_req, i),
+				     pages[i],
 				     seg[i].nsec << 9,
 				     seg[i].buf & ~PAGE_MASK) == 0)) {
 
diff --git a/drivers/block/xen-blkback/common.h b/drivers/block/xen-blkback/common.h
index 9ad3b5e..ae7951f 100644
--- a/drivers/block/xen-blkback/common.h
+++ b/drivers/block/xen-blkback/common.h
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -160,10 +161,22 @@ struct xen_vbd {
 	sector_t		size;
 	bool			flush_support;
 	bool			discard_secure;
+
+	unsigned int		feature_gnt_persistent:1;
+	unsigned int		overflow_max_grants:1;
 };
 
 struct backend_info;
 
+
+struct persistent_gnt {
+	struct page *page;
+	grant_ref_t gnt;
+	grant_handle_t handle;
+	uint64_t dev_bus_addr;
+	struct rb_node node;
+};
+
 struct xen_blkif {
 	/* Unique identifier for this interface. */
 	domid_t			domid;
@@ -190,6 +203,10 @@ struct xen_blkif {
 	struct task_struct	*xenblkd;
 	unsigned int		waiting_reqs;
 
+	/* tree to store persistent grants */
+	struct rb_root		persistent_gnts;
+	unsigned int		persistent_gnt_c;
+
 	/* statistics */
 	unsigned long		st_print;
 	int			st_rd_req;
diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c
index 4f66171..b225026 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -118,6 +118,7 @@ static struct xen_blkif *xen_blkif_alloc(domid_t domid)
 	atomic_set(&blkif->drain, 0);
 	blkif->st_print = jiffies;
 	init_waitqueue_head(&blkif->waiting_to_free);
+	blkif->persistent_gnts.rb_node = NULL;
 
 	return blkif;
 }
@@ -673,6 +674,13 @@ again:
 
 	xen_blkbk_barrier(xbt, be, be->blkif->vbd.flush_support);
 
+	err = xenbus_printf(xbt, dev->nodename, "feature-persistent", "%u", 1);
+	if (err) {
+		xenbus_dev_fatal(dev, err, "writing %s/feature-persistent",
+				 dev->nodename);
+		goto abort;
+	}
+
 	err = xenbus_printf(xbt, dev->nodename, "sectors", "%llu",
 			    (unsigned long long)vbd_sz(&be->blkif->vbd));
 	if (err) {
@@ -721,6 +729,7 @@ static int connect_ring(struct backend_info *be)
 	struct xenbus_device *dev = be->dev;
 	unsigned long ring_ref;
 	unsigned int evtchn;
+	unsigned int pers_grants;
 	char protocol[64] = "";
 	int err;
 
@@ -750,8 +759,18 @@ static int connect_ring(struct backend_info *be)
 		xenbus_dev_fatal(dev, err, "unknown fe protocol %s", protocol);
 		return -1;
 	}
-	pr_info(DRV_PFX "ring-ref %ld, event-channel %d, protocol %d (%s)\n",
-		ring_ref, evtchn, be->blkif->blk_protocol, protocol);
+	err = xenbus_gather(XBT_NIL, dev->otherend,
+			    "feature-persistent-grants", "%u",
+			    &pers_grants, NULL);
+	if (err)
+		pers_grants = 0;
+
+	be->blkif->vbd.feature_gnt_persistent = pers_grants;
+	be->blkif->vbd.overflow_max_grants = 0;
+
+	pr_info(DRV_PFX "ring-ref %ld, event-channel %d, protocol %d (%s) %s\n",
+		ring_ref, evtchn, be->blkif->blk_protocol, protocol,
+		pers_grants ? "persistent grants" : "");
 
 	/* Map the shared frame, irq etc. */
 	err = xen_blkif_map(be->blkif, ring_ref, evtchn);
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 007db89..911d733 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -44,6 +44,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -64,10 +65,17 @@ enum blkif_state {
 	BLKIF_STATE_SUSPENDED,
 };
 
+struct grant {
+	grant_ref_t gref;
+	unsigned long pfn;
+	struct llist_node node;
+};
+
 struct blk_shadow {
 	struct blkif_request req;
 	struct request *request;
 	unsigned long frame[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct grant *grants_used[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 };
 
 static DEFINE_MUTEX(blkfront_mutex);
@@ -97,6 +105,8 @@ struct blkfront_info
 	struct work_struct work;
 	struct gnttab_free_callback callback;
 	struct blk_shadow shadow[BLK_RING_SIZE];
+	struct llist_head persistent_gnts;
+	unsigned int persistent_gnts_c;
 	unsigned long shadow_free;
 	unsigned int feature_flush;
 	unsigned int flush_op;
@@ -104,6 +114,7 @@ struct blkfront_info
 	unsigned int feature_secdiscard:1;
 	unsigned int discard_granularity;
 	unsigned int discard_alignment;
+	unsigned int feature_persistent:1;
 	int is_ready;
 };
 
@@ -287,21 +298,36 @@ static int blkif_queue_request(struct request *req)
 	unsigned long id;
 	unsigned int fsect, lsect;
 	int i, ref;
+
+	/*
+	 * Used to store if we are able to queue the request by just using
+	 * existing persistent grants, or if we have to get new grants,
+	 * as there are not sufficiently many free.
+	 */
+	bool new_persistent_gnts;
 	grant_ref_t gref_head;
+	struct page *granted_page;
+	struct grant *gnt_list_entry = NULL;
 	struct scatterlist *sg;
 
 	if (unlikely(info->connected != BLKIF_STATE_CONNECTED))
 		return 1;
 
-	if (gnttab_alloc_grant_references(
-		BLKIF_MAX_SEGMENTS_PER_REQUEST, &gref_head) < 0) {
-		gnttab_request_free_callback(
-			&info->callback,
-			blkif_restart_queue_callback,
-			info,
-			BLKIF_MAX_SEGMENTS_PER_REQUEST);
-		return 1;
-	}
+	/* Check if we have enought grants to allocate a requests */
+	if (info->persistent_gnts_c < BLKIF_MAX_SEGMENTS_PER_REQUEST) {
+		new_persistent_gnts = 1;
+		if (gnttab_alloc_grant_references(
+		    BLKIF_MAX_SEGMENTS_PER_REQUEST - info->persistent_gnts_c,
+		    &gref_head) < 0) {
+			gnttab_request_free_callback(
+				&info->callback,
+				blkif_restart_queue_callback,
+				info,
+				BLKIF_MAX_SEGMENTS_PER_REQUEST);
+			return 1;
+		}
+	} else
+		new_persistent_gnts = 0;
 
 	/* Fill out a communications ring structure. */
 	ring_req = RING_GET_REQUEST(&info->ring, info->ring.req_prod_pvt);
@@ -341,18 +367,73 @@ static int blkif_queue_request(struct request *req)
 		       BLKIF_MAX_SEGMENTS_PER_REQUEST);
 
 		for_each_sg(info->sg, sg, ring_req->u.rw.nr_segments, i) {
-			buffer_mfn = pfn_to_mfn(page_to_pfn(sg_page(sg)));
 			fsect = sg->offset >> 9;
 			lsect = fsect + (sg->length >> 9) - 1;
-			/* install a grant reference. */
-			ref = gnttab_claim_grant_reference(&gref_head);
-			BUG_ON(ref == -ENOSPC);
 
-			gnttab_grant_foreign_access_ref(
-					ref,
+			if (info->persistent_gnts_c) {
+				BUG_ON(llist_empty(&info->persistent_gnts));
+				gnt_list_entry = llist_entry(
+					llist_del_first(&info->persistent_gnts),
+					struct grant, node);
+
+				ref = gnt_list_entry->gref;
+				buffer_mfn = pfn_to_mfn(gnt_list_entry->pfn);
+				info->persistent_gnts_c--;
+			} else {
+				ref = gnttab_claim_grant_reference(&gref_head);
+				BUG_ON(ref == -ENOSPC);
+
+				gnt_list_entry =
+					kmalloc(sizeof(struct grant),
+							 GFP_ATOMIC);
+				if (!gnt_list_entry)
+					return -ENOMEM;
+
+				granted_page = alloc_page(GFP_ATOMIC);
+				if (!granted_page) {
+					kfree(gnt_list_entry);
+					return -ENOMEM;
+				}
+
+				gnt_list_entry->pfn =
+					page_to_pfn(granted_page);
+				gnt_list_entry->gref = ref;
+
+				buffer_mfn = pfn_to_mfn(page_to_pfn(
+								granted_page));
+				gnttab_grant_foreign_access_ref(ref,
 					info->xbdev->otherend_id,
-					buffer_mfn,
-					rq_data_dir(req));
+					buffer_mfn, 0);
+			}
+
+			info->shadow[id].grants_used[i] = gnt_list_entry;
+
+			if (rq_data_dir(req)) {
+				char *bvec_data;
+				void *shared_data;
+
+				BUG_ON(sg->offset + sg->length > PAGE_SIZE);
+
+				shared_data = kmap_atomic(
+					pfn_to_page(gnt_list_entry->pfn));
+				bvec_data = kmap_atomic(sg_page(sg));
+
+				/*
+				 * this does not wipe data stored outside the
+				 * range sg->offset..sg->offset+sg->length.
+				 * Therefore, blkback *could* see data from
+				 * previous requests. This is OK as long as
+				 * persistent grants are shared with just one
+				 * domain. It may need refactoring if this
+				 * changes
+				 */
+				memcpy(shared_data + sg->offset,
+				       bvec_data   + sg->offset,
+				       sg->length);
+
+				kunmap_atomic(bvec_data);
+				kunmap_atomic(shared_data);
+			}
 
 			info->shadow[id].frame[i] = mfn_to_pfn(buffer_mfn);
 			ring_req->u.rw.seg[i] =
@@ -368,7 +449,8 @@ static int blkif_queue_request(struct request *req)
 	/* Keep a private copy so we can reissue requests when recovering. */
 	info->shadow[id].req = *ring_req;
 
-	gnttab_free_grant_references(gref_head);
+	if (new_persistent_gnts)
+		gnttab_free_grant_references(gref_head);
 
 	return 0;
 }
@@ -480,12 +562,13 @@ static int xlvbd_init_blk_queue(struct gendisk *gd, u16 sector_size)
 static void xlvbd_flush(struct blkfront_info *info)
 {
 	blk_queue_flush(info->rq, info->feature_flush);
-	printk(KERN_INFO "blkfront: %s: %s: %s\n",
+	printk(KERN_INFO "blkfront: %s: %s: %s %s\n",
 	       info->gd->disk_name,
 	       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
 		"barrier" : (info->flush_op == BLKIF_OP_FLUSH_DISKCACHE ?
 		"flush diskcache" : "barrier or flush"),
-	       info->feature_flush ? "enabled" : "disabled");
+	       info->feature_flush ? "enabled" : "disabled",
+	       info->feature_persistent ? "using persistent grants" : "");
 }
 
 static int xen_translate_vdev(int vdevice, int *minor, unsigned int *offset)
@@ -707,6 +790,9 @@ static void blkif_restart_queue(struct work_struct *work)
 
 static void blkif_free(struct blkfront_info *info, int suspend)
 {
+	struct llist_node *all_gnts;
+	struct grant *persistent_gnt;
+
 	/* Prevent new requests being issued until we fix things up. */
 	spin_lock_irq(&info->io_lock);
 	info->connected = suspend ?
@@ -714,6 +800,17 @@ static void blkif_free(struct blkfront_info *info, int suspend)
 	/* No more blkif_request(). */
 	if (info->rq)
 		blk_stop_queue(info->rq);
+
+	/* Remove all persistent grants */
+	if (info->persistent_gnts_c) {
+		all_gnts = llist_del_all(&info->persistent_gnts);
+		llist_for_each_entry(persistent_gnt, all_gnts, node) {
+			gnttab_end_foreign_access(persistent_gnt->gref, 0, 0UL);
+			kfree(persistent_gnt);
+		}
+		info->persistent_gnts_c = 0;
+	}
+
 	/* No more gnttab callback work. */
 	gnttab_cancel_free_callback(&info->callback);
 	spin_unlock_irq(&info->io_lock);
@@ -734,13 +831,42 @@ static void blkif_free(struct blkfront_info *info, int suspend)
 
 }
 
-static void blkif_completion(struct blk_shadow *s)
+static void blkif_completion(struct blk_shadow *s, struct blkfront_info *info,
+			     struct blkif_response *bret)
 {
 	int i;
-	/* Do not let BLKIF_OP_DISCARD as nr_segment is in the same place
-	 * flag. */
-	for (i = 0; i < s->req.u.rw.nr_segments; i++)
-		gnttab_end_foreign_access(s->req.u.rw.seg[i].gref, 0, 0UL);
+	struct bio_vec *bvec;
+	struct req_iterator iter;
+	unsigned long flags;
+	char *bvec_data;
+	void *shared_data;
+	unsigned int offset = 0;
+
+	if (bret->operation == BLKIF_OP_READ) {
+		/*
+		 * Copy the data received from the backend into the bvec.
+		 * Since bv_offset can be different than 0, and bv_len different
+		 * than PAGE_SIZE, we have to keep track of the current offset,
+		 * to be sure we are copying the data from the right shared page.
+		 */
+		rq_for_each_segment(bvec, s->request, iter) {
+			BUG_ON((bvec->bv_offset + bvec->bv_len) > PAGE_SIZE);
+			i = offset >> PAGE_SHIFT;
+			shared_data = kmap_atomic(
+				pfn_to_page(s->grants_used[i]->pfn));
+			bvec_data = bvec_kmap_irq(bvec, &flags);
+			memcpy(bvec_data, shared_data + bvec->bv_offset,
+				bvec->bv_len);
+			bvec_kunmap_irq(bvec_data, &flags);
+			kunmap_atomic(shared_data);
+			offset += bvec->bv_len;
+		}
+	}
+	/* Add the persistent grant into the list of free grants */
+	for (i = 0; i < s->req.u.rw.nr_segments; i++) {
+		llist_add(&s->grants_used[i]->node, &info->persistent_gnts);
+		info->persistent_gnts_c++;
+	}
 }
 
 static irqreturn_t blkif_interrupt(int irq, void *dev_id)
@@ -783,7 +909,7 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
 		req  = info->shadow[id].request;
 
 		if (bret->operation != BLKIF_OP_DISCARD)
-			blkif_completion(&info->shadow[id]);
+			blkif_completion(&info->shadow[id], info, bret);
 
 		if (add_id_to_freelist(info, id)) {
 			WARN(1, "%s: response to %s (id %ld) couldn't be recycled!\n",
@@ -942,6 +1068,11 @@ again:
 		message = "writing protocol";
 		goto abort_transaction;
 	}
+	err = xenbus_printf(xbt, dev->nodename,
+			    "feature-persistent-grants", "%u", 1);
+	if (err)
+		dev_warn(&dev->dev,
+			 "writing persistent grants feature to xenbus");
 
 	err = xenbus_transaction_end(xbt, 0);
 	if (err) {
@@ -1029,6 +1160,8 @@ static int blkfront_probe(struct xenbus_device *dev,
 	spin_lock_init(&info->io_lock);
 	info->xbdev = dev;
 	info->vdevice = vdevice;
+	init_llist_head(&info->persistent_gnts);
+	info->persistent_gnts_c = 0;
 	info->connected = BLKIF_STATE_DISCONNECTED;
 	INIT_WORK(&info->work, blkif_restart_queue);
 
@@ -1093,7 +1226,7 @@ static int blkif_recover(struct blkfront_info *info)
 					req->u.rw.seg[j].gref,
 					info->xbdev->otherend_id,
 					pfn_to_mfn(info->shadow[req->u.rw.id].frame[j]),
-					rq_data_dir(info->shadow[req->u.rw.id].request));
+					0);
 		}
 		info->shadow[req->u.rw.id].req = *req;
 
@@ -1225,7 +1358,7 @@ static void blkfront_connect(struct blkfront_info *info)
 	unsigned long sector_size;
 	unsigned int binfo;
 	int err;
-	int barrier, flush, discard;
+	int barrier, flush, discard, persistent;
 
 	switch (info->connected) {
 	case BLKIF_STATE_CONNECTED:
@@ -1303,6 +1436,14 @@ static void blkfront_connect(struct blkfront_info *info)
 	if (!err && discard)
 		blkfront_setup_discard(info);
 
+	err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
+			    "feature-persistent", "%u", &persistent,
+			    NULL);
+	if (err)
+		info->feature_persistent = 0;
+	else
+		info->feature_persistent = persistent;
+
 	err = xlvbd_alloc_gendisk(sectors, info, binfo, sector_size);
 	if (err) {
 		xenbus_dev_fatal(info->xbdev, err, "xlvbd_add at %s",
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 17:03:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 17:03:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR4MO-0004F0-Kq; Wed, 24 Oct 2012 17:03:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR4MM-0004DJ-4k
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 17:03:14 +0000
Received: from [85.158.143.35:25942] by server-1.bemta-4.messagelabs.com id
	C0/39-19134-15F18805; Wed, 24 Oct 2012 17:03:13 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1351098192!7768901!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27843 invoked from network); 24 Oct 2012 17:03:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 17:03:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15366074"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 17:02:35 +0000
Received: from [127.0.1.1] (10.80.3.216) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 18:02:35 +0100
MIME-Version: 1.0
X-Mercurial-Node: bcb5a61828686d1bab35faa55ae5a716b9f74a60
Message-ID: 
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 24 Oct 2012 18:02:23 +0100
From: Thanos Makatos 
To: 
Cc: thanos.makatos@citrix.com
Subject: [Xen-devel] [PATCH 04 of 16 RFC] blktap3: change
 libxl__blktap_devpath prototype to return an error code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Make libxl__blktap_devpath return an error code instead of the device, since there is no device in dom0 any more. Amend the libxl code that uses this functions accordingly.

diff -r 80e0bc67dcda -r bcb5a6182868 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Wed Oct 24 17:24:53 2012 +0100
+++ b/tools/libxl/libxl.c	Wed Oct 24 17:25:02 2012 +0100
@@ -1844,13 +1844,14 @@ static void device_disk_add(libxl__egc *
                 break;
 
             case LIBXL_DISK_BACKEND_TAP:
-                dev = libxl__blktap_devpath(gc, disk->pdev_path, disk->format);
-                if (!dev) {
-                    LOG(ERROR, "failed to get blktap devpath for %p\n",
-                        disk->pdev_path);
+                rc = libxl__blktap_devpath(gc, disk->pdev_path, disk->format);
+                if (rc) {
+                    LOG(ERROR, "failed to get blktap devpath for %s: %s\n",
+                        disk->pdev_path, strerror(rc));
                     rc = ERROR_FAIL;
                     goto out;
                 }
+                dev = NULL;
                 flexarray_append(back, "tapdisk-params");
                 flexarray_append(back, libxl__sprintf(gc, "%s:%s",
                     libxl__device_disk_string_of_format(disk->format),
@@ -2277,8 +2278,13 @@ void libxl__device_disk_local_initiate_a
                 dev = disk->pdev_path;
                 break;
             case LIBXL_DISK_FORMAT_VHD:
-                dev = libxl__blktap_devpath(gc, disk->pdev_path,
-                                            disk->format);
+                rc = libxl__blktap_devpath(gc, disk->pdev_path, disk->format);
+                if (!rc) {
+                    LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                           "error getting tapdisk: %s", strerror(rc));
+                    rc = ERROR_FAIL;
+                    goto out;
+                }
                 break;
             case LIBXL_DISK_FORMAT_QCOW:
             case LIBXL_DISK_FORMAT_QCOW2:
diff -r 80e0bc67dcda -r bcb5a6182868 tools/libxl/libxl_blktap3.c
--- a/tools/libxl/libxl_blktap3.c	Wed Oct 24 17:24:53 2012 +0100
+++ b/tools/libxl/libxl_blktap3.c	Wed Oct 24 17:25:02 2012 +0100
@@ -5,9 +5,9 @@ int libxl__blktap_enabled(libxl__gc *gc)
     return 1;
 }
 
-char *libxl__blktap_devpath(libxl__gc *gc, const char *disk,
+int libxl__blktap_devpath(libxl__gc *gc, const char *disk,
     libxl_disk_format format) {
-    return NULL;
+    return -ENOSYS;
 }
 
 int libxl__device_destroy_tapdisk(libxl__gc *gc, const char *be_path) {
diff -r 80e0bc67dcda -r bcb5a6182868 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Wed Oct 24 17:24:53 2012 +0100
+++ b/tools/libxl/libxl_internal.h	Wed Oct 24 17:25:02 2012 +0100
@@ -1344,10 +1344,9 @@ struct libxl__cpuid_policy {
 /* libxl__blktap_devpath:
  *    Argument: path and disk image as specified in config file.
  *      The type specifies whether this is aio, qcow, qcow2, etc.
- *    returns device path xenstore wants to have. returns NULL
- *      if no device corresponds to the disk.
+ *    returns 0 on success, an error code otherwise 
  */
-_hidden char *libxl__blktap_devpath(libxl__gc *gc,
+_hidden int libxl__blktap_devpath(libxl__gc *gc,
                                     const char *disk,
                                     libxl_disk_format format);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 17:03:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 17:03:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR4MS-0004Hy-M7; Wed, 24 Oct 2012 17:03:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR4MN-0004E5-GP
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 17:03:15 +0000
Received: from [85.158.143.35:26101] by server-2.bemta-4.messagelabs.com id
	D8/CC-22268-25F18805; Wed, 24 Oct 2012 17:03:14 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1351098192!7768901!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27996 invoked from network); 24 Oct 2012 17:03:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 17:03:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15366086"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 17:02:37 +0000
Received: from [127.0.1.1] (10.80.3.216) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 18:02:37 +0100
MIME-Version: 1.0
X-Mercurial-Node: b12c1bb767d391c641488cb0e0474c13bac831c0
Message-ID: 
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 24 Oct 2012 18:02:34 +0100
From: Thanos Makatos 
To: xen-devel@lists.xensource.com
Cc: thanos.makatos@citrix.com
Subject: [Xen-devel] [PATCH 15 of 16 RFC] blktap3: Include the
 blktap3/control Makefile in the blktap3 compilation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

diff -r 9f5d1f1f9791 -r b12c1bb767d3 tools/blktap3/Makefile
--- a/tools/blktap3/Makefile	Wed Oct 24 17:27:38 2012 +0100
+++ b/tools/blktap3/Makefile	Wed Oct 24 17:28:12 2012 +0100
@@ -1,12 +1,25 @@
-XEN_ROOT := $(CURDIR)/../../
+XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
-all: build
+override CFLAGS = \
+	-Wall \
+	-Wextra \
+	-Werror
+export CFLAGS
 
-build: ;
+SUBDIRS-y = \
+	control
 
-clean: ;
+override CPPCHECK_DIR ?= .
 
-install: ;
+tags:
+	ctags -R --language-force=C --c-kinds=+px
 
-.PHONY: all build clean install
+clean:
+	rm -rf *.a *.so *.o *.rpm $(LIB) *~ $(DEPS) TAGS tags
+
+check:
+	cppcheck --enable=all -q $(CPPCHECK_DIR)
+
+.PHONY: all clean install tags check
+all clean install: %: subdirs-%

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 17:03:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 17:03:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR4MU-0004JL-1i; Wed, 24 Oct 2012 17:03:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR4MP-0004DJ-5p
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 17:03:17 +0000
Received: from [85.158.143.35:26197] by server-1.bemta-4.messagelabs.com id
	ED/39-19134-35F18805; Wed, 24 Oct 2012 17:03:15 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1351098192!7768901!7
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28037 invoked from network); 24 Oct 2012 17:03:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 17:03:14 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15366085"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 17:02:37 +0000
Received: from [127.0.1.1] (10.80.3.216) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 18:02:37 +0100
MIME-Version: 1.0
X-Mercurial-Node: 9f5d1f1f979114cf41fc6473a11dd7ad8d659631
Message-ID: <9f5d1f1f979114cf41fc.1351098153@makatos-desktop>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 24 Oct 2012 18:02:33 +0100
From: Thanos Makatos 
To: xen-devel@lists.xensource.com
Cc: thanos.makatos@citrix.com
Subject: [Xen-devel] [PATCH 14 of 16 RFC] blktap3: Provide Makefile for
 compiling the blktap3 control library
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This library will be used by libxl to create/destroy tapdisks.

diff -r 092fce05f530 -r 9f5d1f1f9791 tools/blktap3/control/Makefile
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/blktap3/control/Makefile	Wed Oct 24 17:27:38 2012 +0100
@@ -0,0 +1,57 @@
+XEN_ROOT := $(CURDIR)/../../../
+include $(XEN_ROOT)/tools/Rules.mk
+
+LIBDIR ?= /usr/lib
+
+MAJOR = 1.0
+MINOR = 0
+LIBNAME = libblktapctl
+LIBSONAME = $(LIBNAME).so.$(MAJOR)
+
+override CFLAGS += \
+	-I ../include \
+	$(CFLAGS_xeninclude)
+
+CTL_OBJS = \
+		   tap-ctl-destroy.o \
+		   tap-ctl-create.o \
+		   tap-ctl-list.o
+
+CTL_PICS  = $(patsubst %.o,%.opic,$(CTL_OBJS))
+
+OBJS = $(CTL_OBJS) tap-ctl.o
+PICS = $(CTL_PICS)
+
+LIB_STATIC = $(LIBNAME).a
+LIB_SHARED = $(LIBSONAME).$(MINOR)
+
+all: build
+
+build: $(LIB_STATIC) $(LIB_SHARED)
+
+$(LIBNAME).so: $(LIBSONAME)
+	ln -sf $< $@
+
+$(LIBSONAME): $(LIB_SHARED)
+	ln -sf $< $@
+
+$(LIB_STATIC): $(CTL_OBJS)
+	$(AR) r $@ $^
+
+$(LIB_SHARED): $(CTL_PICS)
+	$(CC) $(LDFLAGS) -fPIC  -Wl,$(SONAME_LDFLAG) -Wl,$(LIBSONAME) \
+		$(SHLIB_LDFLAGS) -rdynamic $^ -o $@
+
+# TODO install in /usr/sbin?
+install: $(LIB_STATIC) $(LIB_SHARED)
+	$(INSTALL_DIR) -p $(DESTDIR)$(SBINDIR)
+	$(INSTALL_PROG) $(LIB_SHARED) $(DESTDIR)$(LIBDIR)
+	ln -sf $(LIBSONAME) $(DESTDIR)$(LIBDIR)/$(LIBNAME).so
+	ln -sf $(LIB_SHARED) $(DESTDIR)$(LIBDIR)/$(LIBSONAME)
+
+clean:
+	rm -f $(OBJS) $(PICS) $(LIB_STATIC) $(LIB_SHARED)
+	rm -f $(LIBNAME).so $(LIBSONAME)
+	rm -f *~
+
+.PHONY: all build clean install

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 17:03:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 17:03:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR4MQ-0004Fw-9v; Wed, 24 Oct 2012 17:03:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR4MM-0004Db-PE
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 17:03:14 +0000
Received: from [85.158.137.99:12288] by server-10.bemta-3.messagelabs.com id
	81/89-00901-25F18805; Wed, 24 Oct 2012 17:03:14 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1351098192!22853898!7
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30262 invoked from network); 24 Oct 2012 17:03:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 17:03:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15366083"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 17:02:36 +0000
Received: from [127.0.1.1] (10.80.3.216) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 18:02:36 +0100
MIME-Version: 1.0
X-Mercurial-Node: 26faf531ed07813fd58704bb668dd38589f36fb6
Message-ID: <26faf531ed07813fd587.1351098151@makatos-desktop>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 24 Oct 2012 18:02:31 +0100
From: Thanos Makatos 
To: xen-devel@lists.xensource.com
Cc: thanos.makatos@citrix.com
Subject: [Xen-devel] [PATCH 12 of 16 RFC] blktap3: Provide empty
 implementation for tap_ctl_destroy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

It will be used in a later patch.

diff -r 7cbf20d7e4d6 -r 26faf531ed07 tools/blktap3/control/tap-ctl-destroy.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/blktap3/control/tap-ctl-destroy.c	Wed Oct 24 17:26:57 2012 +0100
@@ -0,0 +1,42 @@
+/*
+ * FIXME this is the github blktap2 license
+ * 
+ * Copyright (c) 2008, XenSource Inc.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *     * Redistributions of source code must retain the above copyright
+ *       notice, this list of conditions and the following disclaimer.
+ *     * Redistributions in binary form must reproduce the above copyright
+ *       notice, this list of conditions and the following disclaimer in the
+ *       documentation and/or other materials provided with the distribution.
+ *     * Neither the name of XenSource Inc. nor the names of its contributors
+ *       may be used to endorse or promote products derived from this software
+ *       without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER
+ * OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
+ * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
+ * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+ * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
+ * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include "tap-ctl.h"
+
+int tap_ctl_destroy(__attribute__((__unused__)) const int id,
+        __attribute__((__unused__)) const int minor,
+        __attribute__((__unused__)) int force,
+        __attribute__((__unused__)) struct timeval *timeout)
+{
+    return -ENOSYS;
+}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 17:03:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 17:03:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR4MR-0004H4-JK; Wed, 24 Oct 2012 17:03:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR4MN-0004Dv-4n
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 17:03:15 +0000
Received: from [85.158.143.35:63985] by server-3.bemta-4.messagelabs.com id
	14/6A-24279-25F18805; Wed, 24 Oct 2012 17:03:14 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1351098192!7768901!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27944 invoked from network); 24 Oct 2012 17:03:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 17:03:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15366082"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 17:02:36 +0000
Received: from [127.0.1.1] (10.80.3.216) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 18:02:36 +0100
MIME-Version: 1.0
X-Mercurial-Node: 7cbf20d7e4d6b72aa8d0e12014041d8d5a1e5bc1
Message-ID: <7cbf20d7e4d6b72aa8d0.1351098150@makatos-desktop>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 24 Oct 2012 18:02:30 +0100
From: Thanos Makatos 
To: xen-devel@lists.xensource.com
Cc: thanos.makatos@citrix.com
Subject: [Xen-devel] [PATCH 11 of 16 RFC] blktap3: Provide empty
 implementation for the tap_ctl_list and tap_ctl_list_free functions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

They will be used in a later patch.

diff -r a17c7217bef2 -r 7cbf20d7e4d6 tools/blktap3/control/tap-ctl-list.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/blktap3/control/tap-ctl-list.c	Wed Oct 24 17:26:26 2012 +0100
@@ -0,0 +1,44 @@
+/*
+ * FIXME this is the github blktap2 license
+ * 
+ * Copyright (c) 2008, XenSource Inc.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *     * Redistributions of source code must retain the above copyright
+ *       notice, this list of conditions and the following disclaimer.
+ *     * Redistributions in binary form must reproduce the above copyright
+ *       notice, this list of conditions and the following disclaimer in the
+ *       documentation and/or other materials provided with the distribution.
+ *     * Neither the name of XenSource Inc. nor the names of its contributors
+ *       may be used to endorse or promote products derived from this software
+ *       without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER
+ * OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
+ * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
+ * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+ * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
+ * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include "tap-ctl.h"
+
+void tap_ctl_list_free(__attribute__((__unused__)) struct tqh_tap_list *list)
+{
+    return;
+}
+
+int tap_ctl_list(__attribute__((__unused__)) struct tqh_tap_list *list)
+{
+    return -ENOSYS;
+}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 17:03:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 17:03:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR4MQ-0004Fw-9v; Wed, 24 Oct 2012 17:03:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR4MM-0004Db-PE
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 17:03:14 +0000
Received: from [85.158.137.99:12288] by server-10.bemta-3.messagelabs.com id
	81/89-00901-25F18805; Wed, 24 Oct 2012 17:03:14 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1351098192!22853898!7
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30262 invoked from network); 24 Oct 2012 17:03:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 17:03:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15366083"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 17:02:36 +0000
Received: from [127.0.1.1] (10.80.3.216) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 18:02:36 +0100
MIME-Version: 1.0
X-Mercurial-Node: 26faf531ed07813fd58704bb668dd38589f36fb6
Message-ID: <26faf531ed07813fd587.1351098151@makatos-desktop>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 24 Oct 2012 18:02:31 +0100
From: Thanos Makatos 
To: xen-devel@lists.xensource.com
Cc: thanos.makatos@citrix.com
Subject: [Xen-devel] [PATCH 12 of 16 RFC] blktap3: Provide empty
 implementation for tap_ctl_destroy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

It will be used in a later patch.

diff -r 7cbf20d7e4d6 -r 26faf531ed07 tools/blktap3/control/tap-ctl-destroy.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/blktap3/control/tap-ctl-destroy.c	Wed Oct 24 17:26:57 2012 +0100
@@ -0,0 +1,42 @@
+/*
+ * FIXME this is the github blktap2 license
+ * 
+ * Copyright (c) 2008, XenSource Inc.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *     * Redistributions of source code must retain the above copyright
+ *       notice, this list of conditions and the following disclaimer.
+ *     * Redistributions in binary form must reproduce the above copyright
+ *       notice, this list of conditions and the following disclaimer in the
+ *       documentation and/or other materials provided with the distribution.
+ *     * Neither the name of XenSource Inc. nor the names of its contributors
+ *       may be used to endorse or promote products derived from this software
+ *       without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER
+ * OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
+ * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
+ * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+ * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
+ * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include "tap-ctl.h"
+
+int tap_ctl_destroy(__attribute__((__unused__)) const int id,
+        __attribute__((__unused__)) const int minor,
+        __attribute__((__unused__)) int force,
+        __attribute__((__unused__)) struct timeval *timeout)
+{
+    return -ENOSYS;
+}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 17:03:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 17:03:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR4MR-0004H4-JK; Wed, 24 Oct 2012 17:03:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR4MN-0004Dv-4n
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 17:03:15 +0000
Received: from [85.158.143.35:63985] by server-3.bemta-4.messagelabs.com id
	14/6A-24279-25F18805; Wed, 24 Oct 2012 17:03:14 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1351098192!7768901!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27944 invoked from network); 24 Oct 2012 17:03:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 17:03:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15366082"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 17:02:36 +0000
Received: from [127.0.1.1] (10.80.3.216) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 18:02:36 +0100
MIME-Version: 1.0
X-Mercurial-Node: 7cbf20d7e4d6b72aa8d0e12014041d8d5a1e5bc1
Message-ID: <7cbf20d7e4d6b72aa8d0.1351098150@makatos-desktop>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 24 Oct 2012 18:02:30 +0100
From: Thanos Makatos 
To: xen-devel@lists.xensource.com
Cc: thanos.makatos@citrix.com
Subject: [Xen-devel] [PATCH 11 of 16 RFC] blktap3: Provide empty
 implementation for the tap_ctl_list and tap_ctl_list_free functions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

They will be used in a later patch.

diff -r a17c7217bef2 -r 7cbf20d7e4d6 tools/blktap3/control/tap-ctl-list.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/blktap3/control/tap-ctl-list.c	Wed Oct 24 17:26:26 2012 +0100
@@ -0,0 +1,44 @@
+/*
+ * FIXME this is the github blktap2 license
+ * 
+ * Copyright (c) 2008, XenSource Inc.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *     * Redistributions of source code must retain the above copyright
+ *       notice, this list of conditions and the following disclaimer.
+ *     * Redistributions in binary form must reproduce the above copyright
+ *       notice, this list of conditions and the following disclaimer in the
+ *       documentation and/or other materials provided with the distribution.
+ *     * Neither the name of XenSource Inc. nor the names of its contributors
+ *       may be used to endorse or promote products derived from this software
+ *       without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER
+ * OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
+ * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
+ * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+ * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
+ * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include "tap-ctl.h"
+
+void tap_ctl_list_free(__attribute__((__unused__)) struct tqh_tap_list *list)
+{
+    return;
+}
+
+int tap_ctl_list(__attribute__((__unused__)) struct tqh_tap_list *list)
+{
+    return -ENOSYS;
+}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 17:03:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 17:03:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR4MO-0004F0-Kq; Wed, 24 Oct 2012 17:03:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR4MM-0004DJ-4k
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 17:03:14 +0000
Received: from [85.158.143.35:25942] by server-1.bemta-4.messagelabs.com id
	C0/39-19134-15F18805; Wed, 24 Oct 2012 17:03:13 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1351098192!7768901!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27843 invoked from network); 24 Oct 2012 17:03:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 17:03:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15366074"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 17:02:35 +0000
Received: from [127.0.1.1] (10.80.3.216) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 18:02:35 +0100
MIME-Version: 1.0
X-Mercurial-Node: bcb5a61828686d1bab35faa55ae5a716b9f74a60
Message-ID: 
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 24 Oct 2012 18:02:23 +0100
From: Thanos Makatos 
To: 
Cc: thanos.makatos@citrix.com
Subject: [Xen-devel] [PATCH 04 of 16 RFC] blktap3: change
 libxl__blktap_devpath prototype to return an error code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Make libxl__blktap_devpath return an error code instead of the device, since there is no device in dom0 any more. Amend the libxl code that uses this functions accordingly.

diff -r 80e0bc67dcda -r bcb5a6182868 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Wed Oct 24 17:24:53 2012 +0100
+++ b/tools/libxl/libxl.c	Wed Oct 24 17:25:02 2012 +0100
@@ -1844,13 +1844,14 @@ static void device_disk_add(libxl__egc *
                 break;
 
             case LIBXL_DISK_BACKEND_TAP:
-                dev = libxl__blktap_devpath(gc, disk->pdev_path, disk->format);
-                if (!dev) {
-                    LOG(ERROR, "failed to get blktap devpath for %p\n",
-                        disk->pdev_path);
+                rc = libxl__blktap_devpath(gc, disk->pdev_path, disk->format);
+                if (rc) {
+                    LOG(ERROR, "failed to get blktap devpath for %s: %s\n",
+                        disk->pdev_path, strerror(rc));
                     rc = ERROR_FAIL;
                     goto out;
                 }
+                dev = NULL;
                 flexarray_append(back, "tapdisk-params");
                 flexarray_append(back, libxl__sprintf(gc, "%s:%s",
                     libxl__device_disk_string_of_format(disk->format),
@@ -2277,8 +2278,13 @@ void libxl__device_disk_local_initiate_a
                 dev = disk->pdev_path;
                 break;
             case LIBXL_DISK_FORMAT_VHD:
-                dev = libxl__blktap_devpath(gc, disk->pdev_path,
-                                            disk->format);
+                rc = libxl__blktap_devpath(gc, disk->pdev_path, disk->format);
+                if (!rc) {
+                    LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                           "error getting tapdisk: %s", strerror(rc));
+                    rc = ERROR_FAIL;
+                    goto out;
+                }
                 break;
             case LIBXL_DISK_FORMAT_QCOW:
             case LIBXL_DISK_FORMAT_QCOW2:
diff -r 80e0bc67dcda -r bcb5a6182868 tools/libxl/libxl_blktap3.c
--- a/tools/libxl/libxl_blktap3.c	Wed Oct 24 17:24:53 2012 +0100
+++ b/tools/libxl/libxl_blktap3.c	Wed Oct 24 17:25:02 2012 +0100
@@ -5,9 +5,9 @@ int libxl__blktap_enabled(libxl__gc *gc)
     return 1;
 }
 
-char *libxl__blktap_devpath(libxl__gc *gc, const char *disk,
+int libxl__blktap_devpath(libxl__gc *gc, const char *disk,
     libxl_disk_format format) {
-    return NULL;
+    return -ENOSYS;
 }
 
 int libxl__device_destroy_tapdisk(libxl__gc *gc, const char *be_path) {
diff -r 80e0bc67dcda -r bcb5a6182868 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Wed Oct 24 17:24:53 2012 +0100
+++ b/tools/libxl/libxl_internal.h	Wed Oct 24 17:25:02 2012 +0100
@@ -1344,10 +1344,9 @@ struct libxl__cpuid_policy {
 /* libxl__blktap_devpath:
  *    Argument: path and disk image as specified in config file.
  *      The type specifies whether this is aio, qcow, qcow2, etc.
- *    returns device path xenstore wants to have. returns NULL
- *      if no device corresponds to the disk.
+ *    returns 0 on success, an error code otherwise 
  */
-_hidden char *libxl__blktap_devpath(libxl__gc *gc,
+_hidden int libxl__blktap_devpath(libxl__gc *gc,
                                     const char *disk,
                                     libxl_disk_format format);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 17:03:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 17:03:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR4MQ-0004GY-RI; Wed, 24 Oct 2012 17:03:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR4MM-0004DJ-Uv
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 17:03:15 +0000
Received: from [85.158.143.35:63981] by server-1.bemta-4.messagelabs.com id
	65/39-19134-25F18805; Wed, 24 Oct 2012 17:03:14 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1351098192!7768901!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27975 invoked from network); 24 Oct 2012 17:03:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 17:03:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15366084"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 17:02:36 +0000
Received: from [127.0.1.1] (10.80.3.216) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 18:02:37 +0100
MIME-Version: 1.0
X-Mercurial-Node: 092fce05f530712504fc2cf4fc41fd6edf213c4d
Message-ID: <092fce05f530712504fc.1351098152@makatos-desktop>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 24 Oct 2012 18:02:32 +0100
From: Thanos Makatos 
To: xen-devel@lists.xensource.com
Cc: thanos.makatos@citrix.com
Subject: [Xen-devel] [PATCH 13 of 16 RFC] blktap3: Provide empty
 implementation for tap_ctl_create
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

It will be used in a later patch.

diff -r 26faf531ed07 -r 092fce05f530 tools/blktap3/control/tap-ctl-create.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/blktap3/control/tap-ctl-create.c	Wed Oct 24 17:27:10 2012 +0100
@@ -0,0 +1,43 @@
+/*
+ * FIXME this is the github blktap2 license
+ * 
+ * Copyright (c) 2008, XenSource Inc.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *     * Redistributions of source code must retain the above copyright
+ *       notice, this list of conditions and the following disclaimer.
+ *     * Redistributions in binary form must reproduce the above copyright
+ *       notice, this list of conditions and the following disclaimer in the
+ *       documentation and/or other materials provided with the distribution.
+ *     * Neither the name of XenSource Inc. nor the names of its contributors
+ *       may be used to endorse or promote products derived from this software
+ *       without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER
+ * OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
+ * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
+ * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+ * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
+ * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include "tap-ctl.h"
+
+int tap_ctl_create(__attribute__((__unused__)) const char *params,
+        __attribute__((__unused__)) int flags,
+        __attribute__((__unused__)) int parent_minor,
+        __attribute__((__unused__)) char *secondary)
+{
+    return -ENOSYS;
+}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 17:03:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 17:03:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR4MO-0004Et-8c; Wed, 24 Oct 2012 17:03:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR4ML-0004DF-W8
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 17:03:14 +0000
Received: from [85.158.137.99:41809] by server-2.bemta-3.messagelabs.com id
	89/40-00604-15F18805; Wed, 24 Oct 2012 17:03:13 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1351098192!22853898!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30165 invoked from network); 24 Oct 2012 17:03:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 17:03:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15366072"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 17:02:34 +0000
Received: from [127.0.1.1] (10.80.3.216) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 18:02:34 +0100
MIME-Version: 1.0
X-Mercurial-Node: 513739de43b51c832e04bb23b31e6908b1bf97e0
Message-ID: <513739de43b51c832e04.1351098141@makatos-desktop>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 24 Oct 2012 18:02:21 +0100
From: Thanos Makatos 
To: xen-devel@lists.xensource.com
Cc: thanos.makatos@citrix.com
Subject: [Xen-devel] [PATCH 02 of 16 RFC] blktap3: Introduce blktap3 support
	for libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

These functions will be implemented at a later patch.

diff -r fef81de66bf7 -r 513739de43b5 tools/libxl/libxl_blktap3.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxl/libxl_blktap3.c	Wed Oct 24 17:24:37 2012 +0100
@@ -0,0 +1,15 @@
+#include "libxl_osdeps.h"
+#include "libxl_internal.h"
+
+int libxl__blktap_enabled(libxl__gc *gc) {
+    return 1;
+}
+
+char *libxl__blktap_devpath(libxl__gc *gc, const char *disk,
+    libxl_disk_format format) {
+    return NULL;
+}
+
+int libxl__device_destroy_tapdisk(libxl__gc *gc, const char *be_path) {
+    return -ENOSYS;
+}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 17:03:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 17:03:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR4MS-0004Hy-M7; Wed, 24 Oct 2012 17:03:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR4MN-0004E5-GP
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 17:03:15 +0000
Received: from [85.158.143.35:26101] by server-2.bemta-4.messagelabs.com id
	D8/CC-22268-25F18805; Wed, 24 Oct 2012 17:03:14 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1351098192!7768901!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27996 invoked from network); 24 Oct 2012 17:03:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 17:03:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15366086"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 17:02:37 +0000
Received: from [127.0.1.1] (10.80.3.216) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 18:02:37 +0100
MIME-Version: 1.0
X-Mercurial-Node: b12c1bb767d391c641488cb0e0474c13bac831c0
Message-ID: 
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 24 Oct 2012 18:02:34 +0100
From: Thanos Makatos 
To: xen-devel@lists.xensource.com
Cc: thanos.makatos@citrix.com
Subject: [Xen-devel] [PATCH 15 of 16 RFC] blktap3: Include the
 blktap3/control Makefile in the blktap3 compilation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

diff -r 9f5d1f1f9791 -r b12c1bb767d3 tools/blktap3/Makefile
--- a/tools/blktap3/Makefile	Wed Oct 24 17:27:38 2012 +0100
+++ b/tools/blktap3/Makefile	Wed Oct 24 17:28:12 2012 +0100
@@ -1,12 +1,25 @@
-XEN_ROOT := $(CURDIR)/../../
+XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
-all: build
+override CFLAGS = \
+	-Wall \
+	-Wextra \
+	-Werror
+export CFLAGS
 
-build: ;
+SUBDIRS-y = \
+	control
 
-clean: ;
+override CPPCHECK_DIR ?= .
 
-install: ;
+tags:
+	ctags -R --language-force=C --c-kinds=+px
 
-.PHONY: all build clean install
+clean:
+	rm -rf *.a *.so *.o *.rpm $(LIB) *~ $(DEPS) TAGS tags
+
+check:
+	cppcheck --enable=all -q $(CPPCHECK_DIR)
+
+.PHONY: all clean install tags check
+all clean install: %: subdirs-%

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 17:03:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 17:03:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR4MP-0004Fj-Rd; Wed, 24 Oct 2012 17:03:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR4MM-0004DJ-JG
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 17:03:14 +0000
Received: from [85.158.143.35:25973] by server-1.bemta-4.messagelabs.com id
	D1/39-19134-15F18805; Wed, 24 Oct 2012 17:03:13 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1351098192!7768901!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27897 invoked from network); 24 Oct 2012 17:03:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 17:03:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15366076"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 17:02:35 +0000
Received: from [127.0.1.1] (10.80.3.216) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 18:02:35 +0100
MIME-Version: 1.0
X-Mercurial-Node: 5a0b0e799ae8c1dadedc5a2601da561229ae4ed4
Message-ID: <5a0b0e799ae8c1dadedc.1351098145@makatos-desktop>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 24 Oct 2012 18:02:25 +0100
From: Thanos Makatos 
To: xen-devel@lists.xensource.com
Cc: thanos.makatos@citrix.com
Subject: [Xen-devel] [PATCH 06 of 16 RFC] blktap3: Remove physical device
 creation for libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

blktap3 doesn't need a device in dom0.

diff -r 57896068356d -r 5a0b0e799ae8 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Wed Oct 24 17:25:12 2012 +0100
+++ b/tools/libxl/libxl.c	Wed Oct 24 17:25:26 2012 +0100
@@ -1818,7 +1818,6 @@ static void device_disk_add(libxl__egc *
             case LIBXL_DISK_BACKEND_PHY:
                 dev = disk->pdev_path;
 
-        do_backend_phy:
                 flexarray_append(back, "params");
                 flexarray_append(back, dev);
 
@@ -1856,13 +1855,7 @@ static void device_disk_add(libxl__egc *
                 flexarray_append(back, libxl__sprintf(gc, "%s:%s",
                     libxl__device_disk_string_of_format(disk->format),
                     disk->pdev_path));
-
-                /* tap backends with scripts are rejected by
-                 * libxl__device_disk_set_backend */
-                assert(!disk->script);
-
-                /* now create a phy device to export the device to the guest */
-                goto do_backend_phy;
+                break;
             case LIBXL_DISK_BACKEND_QDISK:
                 flexarray_append(back, "params");
                 flexarray_append(back, libxl__sprintf(gc, "%s:%s",

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 17:03:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 17:03:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR4MU-0004JL-1i; Wed, 24 Oct 2012 17:03:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR4MP-0004DJ-5p
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 17:03:17 +0000
Received: from [85.158.143.35:26197] by server-1.bemta-4.messagelabs.com id
	ED/39-19134-35F18805; Wed, 24 Oct 2012 17:03:15 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1351098192!7768901!7
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28037 invoked from network); 24 Oct 2012 17:03:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 17:03:14 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15366085"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 17:02:37 +0000
Received: from [127.0.1.1] (10.80.3.216) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 18:02:37 +0100
MIME-Version: 1.0
X-Mercurial-Node: 9f5d1f1f979114cf41fc6473a11dd7ad8d659631
Message-ID: <9f5d1f1f979114cf41fc.1351098153@makatos-desktop>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 24 Oct 2012 18:02:33 +0100
From: Thanos Makatos 
To: xen-devel@lists.xensource.com
Cc: thanos.makatos@citrix.com
Subject: [Xen-devel] [PATCH 14 of 16 RFC] blktap3: Provide Makefile for
 compiling the blktap3 control library
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This library will be used by libxl to create/destroy tapdisks.

diff -r 092fce05f530 -r 9f5d1f1f9791 tools/blktap3/control/Makefile
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/blktap3/control/Makefile	Wed Oct 24 17:27:38 2012 +0100
@@ -0,0 +1,57 @@
+XEN_ROOT := $(CURDIR)/../../../
+include $(XEN_ROOT)/tools/Rules.mk
+
+LIBDIR ?= /usr/lib
+
+MAJOR = 1.0
+MINOR = 0
+LIBNAME = libblktapctl
+LIBSONAME = $(LIBNAME).so.$(MAJOR)
+
+override CFLAGS += \
+	-I ../include \
+	$(CFLAGS_xeninclude)
+
+CTL_OBJS = \
+		   tap-ctl-destroy.o \
+		   tap-ctl-create.o \
+		   tap-ctl-list.o
+
+CTL_PICS  = $(patsubst %.o,%.opic,$(CTL_OBJS))
+
+OBJS = $(CTL_OBJS) tap-ctl.o
+PICS = $(CTL_PICS)
+
+LIB_STATIC = $(LIBNAME).a
+LIB_SHARED = $(LIBSONAME).$(MINOR)
+
+all: build
+
+build: $(LIB_STATIC) $(LIB_SHARED)
+
+$(LIBNAME).so: $(LIBSONAME)
+	ln -sf $< $@
+
+$(LIBSONAME): $(LIB_SHARED)
+	ln -sf $< $@
+
+$(LIB_STATIC): $(CTL_OBJS)
+	$(AR) r $@ $^
+
+$(LIB_SHARED): $(CTL_PICS)
+	$(CC) $(LDFLAGS) -fPIC  -Wl,$(SONAME_LDFLAG) -Wl,$(LIBSONAME) \
+		$(SHLIB_LDFLAGS) -rdynamic $^ -o $@
+
+# TODO install in /usr/sbin?
+install: $(LIB_STATIC) $(LIB_SHARED)
+	$(INSTALL_DIR) -p $(DESTDIR)$(SBINDIR)
+	$(INSTALL_PROG) $(LIB_SHARED) $(DESTDIR)$(LIBDIR)
+	ln -sf $(LIBSONAME) $(DESTDIR)$(LIBDIR)/$(LIBNAME).so
+	ln -sf $(LIB_SHARED) $(DESTDIR)$(LIBDIR)/$(LIBSONAME)
+
+clean:
+	rm -f $(OBJS) $(PICS) $(LIB_STATIC) $(LIB_SHARED)
+	rm -f $(LIBNAME).so $(LIBSONAME)
+	rm -f *~
+
+.PHONY: all build clean install

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 17:03:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 17:03:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR4MN-0004EN-HE; Wed, 24 Oct 2012 17:03:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR4MM-0004DE-15
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 17:03:14 +0000
Received: from [85.158.137.99:64594] by server-3.bemta-3.messagelabs.com id
	4C/6D-09368-05F18805; Wed, 24 Oct 2012 17:03:12 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1351098192!22853898!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30158 invoked from network); 24 Oct 2012 17:03:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 17:03:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15366070"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 17:02:34 +0000
Received: from [127.0.1.1] (10.80.3.216) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 18:02:34 +0100
MIME-Version: 1.0
Message-ID: 
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 24 Oct 2012 18:02:19 +0100
From: Thanos Makatos 
To: 
Cc: thanos.makatos@citrix.com
Subject: [Xen-devel] [PATCH 00 of 16 RFC] add libxl support for blktap3 and
 introduce the blktap3 build system
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This series introduces support for blktap3 in libxl and adds the basis of the
blktap3 build system. There is no essential blktap3 functionality yet: all
blktap3 functions are stubs and they will be implemented in later patches. This
means that trying to use tap as the disk backend for a guest will make libxl
complain since all of blktap3 functions return a failure error code. Most
header files introduced in this series require some basic documentation.
Finally, licenses need to be verified.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 17:03:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 17:03:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR4MQ-0004GY-RI; Wed, 24 Oct 2012 17:03:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR4MM-0004DJ-Uv
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 17:03:15 +0000
Received: from [85.158.143.35:63981] by server-1.bemta-4.messagelabs.com id
	65/39-19134-25F18805; Wed, 24 Oct 2012 17:03:14 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1351098192!7768901!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27975 invoked from network); 24 Oct 2012 17:03:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 17:03:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15366084"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 17:02:36 +0000
Received: from [127.0.1.1] (10.80.3.216) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 18:02:37 +0100
MIME-Version: 1.0
X-Mercurial-Node: 092fce05f530712504fc2cf4fc41fd6edf213c4d
Message-ID: <092fce05f530712504fc.1351098152@makatos-desktop>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 24 Oct 2012 18:02:32 +0100
From: Thanos Makatos 
To: xen-devel@lists.xensource.com
Cc: thanos.makatos@citrix.com
Subject: [Xen-devel] [PATCH 13 of 16 RFC] blktap3: Provide empty
 implementation for tap_ctl_create
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

It will be used in a later patch.

diff -r 26faf531ed07 -r 092fce05f530 tools/blktap3/control/tap-ctl-create.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/blktap3/control/tap-ctl-create.c	Wed Oct 24 17:27:10 2012 +0100
@@ -0,0 +1,43 @@
+/*
+ * FIXME this is the github blktap2 license
+ * 
+ * Copyright (c) 2008, XenSource Inc.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *     * Redistributions of source code must retain the above copyright
+ *       notice, this list of conditions and the following disclaimer.
+ *     * Redistributions in binary form must reproduce the above copyright
+ *       notice, this list of conditions and the following disclaimer in the
+ *       documentation and/or other materials provided with the distribution.
+ *     * Neither the name of XenSource Inc. nor the names of its contributors
+ *       may be used to endorse or promote products derived from this software
+ *       without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER
+ * OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
+ * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
+ * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+ * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
+ * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include "tap-ctl.h"
+
+int tap_ctl_create(__attribute__((__unused__)) const char *params,
+        __attribute__((__unused__)) int flags,
+        __attribute__((__unused__)) int parent_minor,
+        __attribute__((__unused__)) char *secondary)
+{
+    return -ENOSYS;
+}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 17:03:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 17:03:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR4MP-0004FC-2G; Wed, 24 Oct 2012 17:03:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR4MM-0004DI-9j
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 17:03:14 +0000
Received: from [85.158.137.99:12280] by server-5.bemta-3.messagelabs.com id
	BE/D9-12440-15F18805; Wed, 24 Oct 2012 17:03:13 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1351098192!22853898!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30201 invoked from network); 24 Oct 2012 17:03:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 17:03:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15366073"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 17:02:34 +0000
Received: from [127.0.1.1] (10.80.3.216) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 18:02:35 +0100
MIME-Version: 1.0
X-Mercurial-Node: 80e0bc67dcdaadc40d3a197a7d6640d3b07b400e
Message-ID: <80e0bc67dcdaadc40d3a.1351098142@makatos-desktop>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 24 Oct 2012 18:02:22 +0100
From: Thanos Makatos 
To: xen-devel@lists.xensource.com
Cc: thanos.makatos@citrix.com
Subject: [Xen-devel] [PATCH 03 of 16 RFC] blktap3: support for blktap3 in
	libxl Makefile
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Point the libxl Makefile to the blktap3 include and library directories instead
of the blktap2 ones, don't link with the blktap2 control library, and compile
libxl with the unimplemented functions introduced in the previous patch.

diff -r 513739de43b5 -r 80e0bc67dcda tools/Rules.mk
--- a/tools/Rules.mk	Wed Oct 24 17:24:37 2012 +0100
+++ b/tools/Rules.mk	Wed Oct 24 17:24:53 2012 +0100
@@ -15,6 +15,7 @@ XEN_XENLIGHT       = $(XEN_ROOT)/tools/l
 XEN_XENSTORE       = $(XEN_ROOT)/tools/xenstore
 XEN_LIBXENSTAT     = $(XEN_ROOT)/tools/xenstat/libxenstat/src
 XEN_BLKTAP2        = $(XEN_ROOT)/tools/blktap2
+XEN_BLKTAP3        = $(XEN_ROOT)/tools/blktap3
 XEN_LIBVCHAN       = $(XEN_ROOT)/tools/libvchan
 
 CFLAGS_xeninclude = -I$(XEN_INCLUDE)
@@ -46,9 +47,9 @@ LIBXL_BLKTAP ?= n
 endif
 
 ifeq ($(LIBXL_BLKTAP),y)
-CFLAGS_libblktapctl = -I$(XEN_BLKTAP2)/control -I$(XEN_BLKTAP2)/include $(CFLAGS_xeninclude)
-LDLIBS_libblktapctl = -L$(XEN_BLKTAP2)/control -lblktapctl
-SHLIB_libblktapctl  = -Wl,-rpath-link=$(XEN_BLKTAP2)/control
+CFLAGS_libblktapctl = -I$(XEN_BLKTAP3)/control -I$(XEN_BLKTAP3)/include $(CFLAGS_xeninclude)
+LDLIBS_libblktapctl = -L$(XEN_BLKTAP3)/control -lblktapctl
+SHLIB_libblktapctl  = -Wl,-rpath-link=$(XEN_BLKTAP3)/control
 else
 CFLAGS_libblktapctl =
 LDLIBS_libblktapctl =
diff -r 513739de43b5 -r 80e0bc67dcda tools/libxl/Makefile
--- a/tools/libxl/Makefile	Wed Oct 24 17:24:37 2012 +0100
+++ b/tools/libxl/Makefile	Wed Oct 24 17:24:53 2012 +0100
@@ -20,7 +20,7 @@ LIBUUID_LIBS += -luuid
 endif
 
 LIBXL_LIBS =
-LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS)
+LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS)
 
 CFLAGS_LIBXL += $(CFLAGS_libxenctrl)
 CFLAGS_LIBXL += $(CFLAGS_libxenguest)
@@ -36,9 +36,9 @@ LIBXLU_LIBS =
 
 LIBXL_OBJS-y = osdeps.o libxl_paths.o libxl_bootloader.o flexarray.o
 ifeq ($(LIBXL_BLKTAP),y)
-LIBXL_OBJS-y += libxl_blktap2.o
+LIBXL_OBJS-y += libxl_blktap3.o
 else
-LIBXL_OBJS-y += libxl_noblktap2.o
+LIBXL_OBJS-y += libxl_noblktap3.o
 endif
 LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o
 LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o libxl_noarch.o
@@ -77,7 +77,8 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_c
 			libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
-$(LIBXL_OBJS): CFLAGS += $(CFLAGS_LIBXL) -include $(XEN_ROOT)/tools/config.h
+$(LIBXL_OBJS): CFLAGS += $(CFLAGS_LIBXL) -include $(XEN_ROOT)/tools/config.h \
+	$(CFLAGS_libblktapctl)
 
 AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h _paths.h \
 	_libxl_save_msgs_callout.h _libxl_save_msgs_helper.h

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 17:03:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 17:03:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR4MR-0004Gn-7f; Wed, 24 Oct 2012 17:03:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR4MM-0004DI-Qp
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 17:03:15 +0000
Received: from [85.158.137.99:41849] by server-5.bemta-3.messagelabs.com id
	23/E9-12440-25F18805; Wed, 24 Oct 2012 17:03:14 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1351098192!22853898!9
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30280 invoked from network); 24 Oct 2012 17:03:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 17:03:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15366081"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 17:02:36 +0000
Received: from [127.0.1.1] (10.80.3.216) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 18:02:36 +0100
MIME-Version: 1.0
X-Mercurial-Node: a17c7217bef2913aee6de4394e92c3adf194fafb
Message-ID: 
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 24 Oct 2012 18:02:29 +0100
From: Thanos Makatos 
To: xen-devel@lists.xensource.com
Cc: thanos.makatos@citrix.com
Subject: [Xen-devel] [PATCH 10 of 16 RFC] blktap3: Introduce the blktap
	header file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In this file various file-system paths are specified, similar to the XEN
blktap2. These defines need to be documented. Unused defines (i.e. IOCTLs) have
been removed.

diff -r efb6b2844256 -r a17c7217bef2 tools/blktap3/include/blktap.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/blktap3/include/blktap.h	Wed Oct 24 17:26:14 2012 +0100
@@ -0,0 +1,85 @@
+/*
+ * FIXME this is the github blktap2 license.
+ *
+ * Copyright (c) 2008, XenSource Inc.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *     * Redistributions of source code must retain the above copyright
+ *       notice, this list of conditions and the following disclaimer.
+ *     * Redistributions in binary form must reproduce the above copyright
+ *       notice, this list of conditions and the following disclaimer in the
+ *       documentation and/or other materials provided with the distribution.
+ *     * Neither the name of XenSource Inc. nor the names of its contributors
+ *       may be used to endorse or promote products derived from this software
+ *       without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER
+ * OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
+ * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
+ * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+ * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
+ * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef __BLKTAP_3_H__
+#define __BLKTAP_3_H__
+
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * TODO Document what each define is.
+ */
+#define BLKTAP3_SYSFS_DIR                   "/sys/class/blktap3"
+#define BLKTAP3_CONTROL_NAME                "blktap-control"
+#define BLKTAP3_CONTROL_DIR                 "/var/run/"BLKTAP3_CONTROL_NAME
+#define BLKTAP3_CONTROL_SOCKET              "ctl"
+#define BLKTAP3_DIRECTORY                   "/dev/xen/blktap-3"
+#define BLKTAP3_RING_DEVICE                 BLKTAP3_DIRECTORY"/blktap"
+#define BLKTAP3_IO_DEVICEBLKTAP3_DIRECTORY  "/tapdev"
+#define BLKTAP3_ENOSPC_SIGNAL_FILE          "/var/run/tapdisk3-enospc"
+
+/*
+ * TODO Can these be supplied from somewhere else?
+ */
+#define likely(_cond)   __builtin_expect(!!(_cond), 1)
+#define unlikely(_cond) __builtin_expect(!!(_cond), 0)
+
+/*
+ * FIXME taken from list.h
+ */
+#define containerof(_ptr, _type, _memb) \
+    ((_type*)((void*)(_ptr) - offsetof(_type, _memb)))
+
+/*
+ * FIXME shouldn't these be supplied from somewhere?
+ */
+#define __printf(a, b) __attribute__((format(printf, a, b)))
+#define __scanf(_f, _a) __attribute__((format (scanf, _f, _a)))
+
+#define TAILQ_MOVE_HEAD(node, src, dst, entry)  \
+    TAILQ_REMOVE(src, node, entry);             \
+    TAILQ_INSERT_HEAD(dst, node, entry);
+
+#define TAILQ_MOVE_TAIL(node, src, dst, entry)  \
+    TAILQ_REMOVE(src, node, entry);             \
+    TAILQ_INSERT_TAIL(dst, node, entry);
+
+/*
+ * TODO This is defined in xen/lib.h, use that instead of redefining it
+ * here.
+ */
+#ifndef ARRAY_SIZE
+#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
+#endif /* ARRAY_SIZE */
+
+#endif /* __BLKTAP_3_H__ */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 17:03:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 17:03:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR4MN-0004EC-4z; Wed, 24 Oct 2012 17:03:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR4MM-0004DD-0q
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 17:03:14 +0000
Received: from [85.158.137.99:64602] by server-7.bemta-3.messagelabs.com id
	99/A2-06991-15F18805; Wed, 24 Oct 2012 17:03:13 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1351098192!22853898!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30175 invoked from network); 24 Oct 2012 17:03:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 17:03:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15366071"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 17:02:34 +0000
Received: from [127.0.1.1] (10.80.3.216) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 18:02:34 +0100
MIME-Version: 1.0
X-Mercurial-Node: fef81de66bf7461516cb1d51c4616363356dcc4b
Message-ID: 
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 24 Oct 2012 18:02:20 +0100
From: Thanos Makatos 
To: xen-devel@lists.xensource.com
Cc: thanos.makatos@citrix.com
Subject: [Xen-devel] [PATCH 01 of 16 RFC] blktap3: Introduce the blktap3
	device type
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This device is used when tap is specifed as the disk backend, instead of vbd.

diff -r 3cd5bf62ded7 -r fef81de66bf7 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Wed Oct 24 17:22:39 2012 +0100
+++ b/tools/libxl/libxl.c	Wed Oct 24 17:24:01 2012 +0100
@@ -1742,7 +1742,7 @@ int libxl__device_from_disk(libxl__gc *g
             device->backend_kind = LIBXL__DEVICE_KIND_VBD;
             break;
         case LIBXL_DISK_BACKEND_TAP:
-            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
+            device->backend_kind = LIBXL__DEVICE_KIND_XENIO;
             break;
         case LIBXL_DISK_BACKEND_QDISK:
             device->backend_kind = LIBXL__DEVICE_KIND_QDISK;
diff -r 3cd5bf62ded7 -r fef81de66bf7 tools/libxl/libxl_types_internal.idl
--- a/tools/libxl/libxl_types_internal.idl	Wed Oct 24 17:22:39 2012 +0100
+++ b/tools/libxl/libxl_types_internal.idl	Wed Oct 24 17:24:01 2012 +0100
@@ -19,6 +19,7 @@ libxl__device_kind = Enumeration("device
     (5, "VFB"),
     (6, "VKBD"),
     (7, "CONSOLE"),
+    (8, "XENIO"),
     ])
 
 libxl__console_backend = Enumeration("console_backend", [

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 17:03:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 17:03:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR4MR-0004HR-Vo; Wed, 24 Oct 2012 17:03:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR4MN-0004Dt-6p
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 17:03:15 +0000
Received: from [85.158.137.99:64675] by server-16.bemta-3.messagelabs.com id
	9A/E2-07461-25F18805; Wed, 24 Oct 2012 17:03:14 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1351098192!22853898!10
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30290 invoked from network); 24 Oct 2012 17:03:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 17:03:14 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15366080"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 17:02:36 +0000
Received: from [127.0.1.1] (10.80.3.216) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 18:02:36 +0100
MIME-Version: 1.0
X-Mercurial-Node: efb6b2844256020918ca4abd055e1b3cd2bcffe8
Message-ID: 
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 24 Oct 2012 18:02:28 +0100
From: Thanos Makatos 
To: xen-devel@lists.xensource.com
Cc: thanos.makatos@citrix.com
Subject: [Xen-devel] [PATCH 09 of 16 RFC] blktap3: Introduce the tapdisk
 control function prototypes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This file is based on the github blktap2, which in turn is based on the XEN
blktap2. Most of the changes here are prototype function changes introduced by
the the github blktap2. In blktap3, Linux lists are replaced with BSD tail
queues.

diff -r 23e2537c7257 -r efb6b2844256 tools/blktap3/include/tap-ctl.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/blktap3/include/tap-ctl.h	Wed Oct 24 17:26:04 2012 +0100
@@ -0,0 +1,184 @@
+/*
+ * FIXME this is the github blktap2 license
+ *
+ * Copyright (c) 2008, XenSource Inc.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *     * Redistributions of source code must retain the above copyright
+ *       notice, this list of conditions and the following disclaimer.
+ *     * Redistributions in binary form must reproduce the above copyright
+ *       notice, this list of conditions and the following disclaimer in the
+ *       documentation and/or other materials provided with the distribution.
+ *     * Neither the name of XenSource Inc. nor the names of its contributors
+ *       may be used to endorse or promote products derived from this software
+ *       without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER
+ * OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
+ * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
+ * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+ * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
+ * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef __TAP_CTL_H__
+#define __TAP_CTL_H__
+
+#include 
+#include 
+#include 
+#include 
+#include "blktap.h"
+
+/**
+ * Contains information about a tapdisk process.
+ */
+typedef struct tap_list {
+
+    /**
+     * The process ID.
+     */
+    pid_t pid;
+
+    /**
+     * TODO? 
+     */
+    int minor;
+
+    /**
+     * State of the VBD, specified in drivers/tapdisk-vbd.h.
+     */
+    int state;
+
+    /**
+     * TODO type?
+     */
+    char *type;
+
+    /**
+     * /path/to/file
+     */
+    char *path;
+
+    /**
+     * for linked lists
+     */
+    TAILQ_ENTRY(tap_list) entry;
+} tap_list_t;
+
+TAILQ_HEAD(tqh_tap_list, tap_list);
+
+/**
+ * Iterate over a list of struct tap_list.
+ */
+#define tap_list_for_each_entry(_pos, _head) \
+    TAILQ_FOREACH(_pos, _head, entry)
+
+/**
+ * Iterate over a list of struct tap_list allowing deletions without having to
+ * restart the iteration.
+ */
+#define tap_list_for_each_entry_safe(_pos, _n, _head) \
+    TAILQ_FOREACH_SAFE(_pos, _head, entry, _n)
+
+/**
+ * Connects to a tapdisk.
+ *
+ * @param /path/to/file of the control socket (e.g. /var/run/blktap-control/ctl/
+ * @param socket output parameter that receives the connection
+ * @returns 0 on success, an error code otherwise
+ */
+int tap_ctl_connect(const char *path, int *socket);
+
+/**
+ * Connects to a tapdisk.
+ *
+ * @param id the process ID of the tapdisk to connect to
+ * @param socket output parameter that receives the connection
+ * @returns 0 on success, an error code otherwise
+ */
+int tap_ctl_connect_id(const int id, int *socket);
+
+/**
+ * Reads from the tapdisk connection to the buffer.
+ *
+ * @param fd the file descriptor of the socket to read from
+ * @param buf buffer that receives the output
+ * @param sz size, in bytes, of the buffer
+ * @param timeout (optional) specifies the maximum time to wait for reading
+ * @returns 0 on success, an error code otherwise
+ */
+int tap_ctl_read_raw(const int fd, void *buf, const size_t sz,
+        struct timeval *timeout);
+
+int tap_ctl_read_message(int fd, tapdisk_message_t * message,
+                         struct timeval *timeout);
+int tap_ctl_write_message(int fd, tapdisk_message_t * message,
+                          struct timeval *timeout);
+int tap_ctl_send_and_receive(int fd, tapdisk_message_t * message,
+                             struct timeval *timeout);
+int tap_ctl_connect_send_and_receive(int id, tapdisk_message_t * message,
+                                     struct timeval *timeout);
+char *tap_ctl_socket_name(int id);
+int tap_ctl_list_pid(pid_t pid, struct tqh_tap_list *list);
+
+
+/**
+ * Retrieves a list of all tapdisks.
+ *
+ * @param list output parameter that receives the list of tapdisks
+ * @returns 0 on success, an error code otherwise
+ */
+int tap_ctl_list(struct tqh_tap_list *list);
+
+/**
+ * Deallocates a list of struct tap_list.
+ *
+ * @param list the tapdisk information structure to deallocate.
+ */
+void tap_ctl_list_free(struct tqh_tap_list *list);
+
+/**
+ * Creates a tapdisk process.
+ *
+ * TODO document parameters
+ * @param params
+ * @param flags
+ * @param prt_minor
+ * @param secondary
+ * @returns 0 on success, en error code otherwise
+ */
+int tap_ctl_create(const char *params, int flags, int prt_minor,
+                   char *secondary);
+int tap_ctl_destroy(const int id, const int minor, int force,
+                    struct timeval *timeout);
+
+/*
+ * TODO The following functions are not currently used by anything else other
+ * than the tapdisk itself. Move to a private header?
+ */
+int tap_ctl_spawn(void);
+pid_t tap_ctl_get_pid(const int id);
+
+int tap_ctl_attach(const int id, const int minor);
+int tap_ctl_detach(const int id, const int minor);
+
+int tap_ctl_open(const int id, const int minor, const char *params,
+                 int flags, const int prt_minor, const char *secondary);
+int tap_ctl_close(const int id, const int minor, const int force,
+                  struct timeval *timeout);
+
+int tap_ctl_pause(const int id, const int minor, struct timeval *timeout);
+int tap_ctl_unpause(const int id, const int minor, const char *params);
+
+ssize_t tap_ctl_stats(pid_t pid, int minor, char *buf, size_t size);
+int tap_ctl_stats_fwrite(pid_t pid, int minor, FILE * out);
+
+#endif /* __TAP_CTL_H__ */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 17:03:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 17:03:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR4MT-0004In-G8; Wed, 24 Oct 2012 17:03:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR4MN-0004DJ-FQ
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 17:03:15 +0000
Received: from [85.158.143.35:64113] by server-1.bemta-4.messagelabs.com id
	5B/39-19134-35F18805; Wed, 24 Oct 2012 17:03:15 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1351098192!7768901!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28011 invoked from network); 24 Oct 2012 17:03:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 17:03:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15366079"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 17:02:35 +0000
Received: from [127.0.1.1] (10.80.3.216) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 18:02:36 +0100
MIME-Version: 1.0
X-Mercurial-Node: 23e2537c7257e0e5b00ecf02441f23095a4e0a93
Message-ID: <23e2537c7257e0e5b00e.1351098147@makatos-desktop>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 24 Oct 2012 18:02:27 +0100
From: Thanos Makatos 
To: xen-devel@lists.xensource.com
Cc: thanos.makatos@citrix.com
Subject: [Xen-devel] [PATCH 08 of 16 RFC] blktap3: Introduce message types
	and structures
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The main difference over the the XEN version is the addition of the stats
structure (used for retrieving stats from a running tapdisk), and the addition
of the tapdisk_message_blkif struct, which is required for the user-space
counterpart of blktap/blkback to communicate with tapdisk.

diff -r 17eea5a9a20c -r 23e2537c7257 tools/blktap3/include/tapdisk-message.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/blktap3/include/tapdisk-message.h	Wed Oct 24 17:25:37 2012 +0100
@@ -0,0 +1,267 @@
+/* FIXME this is the github blktap2 license (which is the same the blktap2
+ * license)
+ *
+ * Copyright (c) 2008, XenSource Inc.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *     * Redistributions of source code must retain the above copyright
+ *       notice, this list of conditions and the following disclaimer.
+ *     * Redistributions in binary form must reproduce the above copyright
+ *       notice, this list of conditions and the following disclaimer in the
+ *       documentation and/or other materials provided with the distribution.
+ *     * Neither the name of XenSource Inc. nor the names of its contributors
+ *       may be used to endorse or promote products derived from this software
+ *       without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER
+ * OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
+ * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
+ * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+ * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
+ * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef __TAPDISK_MESSAGE_H__
+#define __TAPDISK_MESSAGE_H__
+
+#include 
+#include 
+
+#define TAPDISK_MESSAGE_MAX_PATH_LENGTH  256
+#define TAPDISK_MESSAGE_STRING_LENGTH    256
+
+#define TAPDISK_MESSAGE_MAX_MINORS \
+    ((TAPDISK_MESSAGE_MAX_PATH_LENGTH / sizeof(int)) - 1)
+
+#define TAPDISK_MESSAGE_FLAG_SHARED      0x001
+#define TAPDISK_MESSAGE_FLAG_RDONLY      0x002
+#define TAPDISK_MESSAGE_FLAG_ADD_CACHE   0x004
+#define TAPDISK_MESSAGE_FLAG_VHD_INDEX   0x008
+#define TAPDISK_MESSAGE_FLAG_LOG_DIRTY   0x010
+#define TAPDISK_MESSAGE_FLAG_ADD_LCACHE  0x020
+#define TAPDISK_MESSAGE_FLAG_REUSE_PRT   0x040
+#define TAPDISK_MESSAGE_FLAG_SECONDARY   0x080
+#define TAPDISK_MESSAGE_FLAG_STANDBY     0x100
+
+typedef struct tapdisk_message tapdisk_message_t;
+typedef uint32_t tapdisk_message_flag_t;
+typedef struct tapdisk_message_image tapdisk_message_image_t;
+typedef struct tapdisk_message_params tapdisk_message_params_t;
+typedef struct tapdisk_message_string tapdisk_message_string_t;
+typedef struct tapdisk_message_response tapdisk_message_response_t;
+typedef struct tapdisk_message_minors tapdisk_message_minors_t;
+typedef struct tapdisk_message_list tapdisk_message_list_t;
+typedef struct tapdisk_message_stat tapdisk_message_stat_t;
+typedef struct tapdisk_message_blkif tapdisk_message_blkif_t;
+
+struct tapdisk_message_params {
+    tapdisk_message_flag_t flags;
+
+    uint32_t devnum;
+    uint32_t domid;
+    char path[TAPDISK_MESSAGE_MAX_PATH_LENGTH];
+    uint32_t prt_devnum;
+    char secondary[TAPDISK_MESSAGE_MAX_PATH_LENGTH];
+};
+
+struct tapdisk_message_image {
+    uint64_t sectors;
+    uint32_t sector_size;
+    uint32_t info;
+};
+
+struct tapdisk_message_string {
+    char text[TAPDISK_MESSAGE_STRING_LENGTH];
+};
+
+struct tapdisk_message_response {
+    int error;
+    char message[TAPDISK_MESSAGE_STRING_LENGTH];
+};
+
+struct tapdisk_message_minors {
+    int count;
+    int list[TAPDISK_MESSAGE_MAX_MINORS];
+};
+
+struct tapdisk_message_list {
+    int count;
+    int minor;
+    int state;
+    char path[TAPDISK_MESSAGE_MAX_PATH_LENGTH];
+};
+
+struct tapdisk_message_stat {
+    uint16_t type;
+    uint16_t cookie;
+    size_t length;
+};
+
+struct tapdisk_message_blkif {
+    uint32_t domid;
+    uint32_t devid;
+    uint32_t gref[8];
+    uint32_t order;
+    uint32_t proto;
+    char pool[TAPDISK_MESSAGE_STRING_LENGTH];
+    uint32_t port;
+};
+
+struct tapdisk_message {
+    uint16_t type;
+    uint16_t cookie;
+
+    union {
+        pid_t tapdisk_pid;
+        tapdisk_message_image_t image;
+        tapdisk_message_params_t params;
+        tapdisk_message_string_t string;
+        tapdisk_message_minors_t minors;
+        tapdisk_message_response_t response;
+        tapdisk_message_list_t list;
+        tapdisk_message_stat_t info;
+        tapdisk_message_blkif_t blkif;
+    } u;
+};
+
+enum tapdisk_message_id {
+    TAPDISK_MESSAGE_ERROR = 1,
+    TAPDISK_MESSAGE_RUNTIME_ERROR,
+    TAPDISK_MESSAGE_PID,
+    TAPDISK_MESSAGE_PID_RSP,
+    TAPDISK_MESSAGE_ATTACH,
+    TAPDISK_MESSAGE_ATTACH_RSP,
+    TAPDISK_MESSAGE_OPEN,
+    TAPDISK_MESSAGE_OPEN_RSP,
+    TAPDISK_MESSAGE_PAUSE,
+    TAPDISK_MESSAGE_PAUSE_RSP,
+    TAPDISK_MESSAGE_RESUME,
+    TAPDISK_MESSAGE_RESUME_RSP,
+    TAPDISK_MESSAGE_CLOSE,
+    TAPDISK_MESSAGE_CLOSE_RSP,
+    TAPDISK_MESSAGE_DETACH,
+    TAPDISK_MESSAGE_DETACH_RSP,
+    TAPDISK_MESSAGE_LIST_MINORS,
+    TAPDISK_MESSAGE_LIST_MINORS_RSP,
+    TAPDISK_MESSAGE_LIST,
+    TAPDISK_MESSAGE_LIST_RSP,
+    TAPDISK_MESSAGE_STATS,
+    TAPDISK_MESSAGE_STATS_RSP,
+    TAPDISK_MESSAGE_FORCE_SHUTDOWN,
+    TAPDISK_MESSAGE_DISK_INFO,
+    TAPDISK_MESSAGE_DISK_INFO_RSP,
+    TAPDISK_MESSAGE_XENBLKIF_CONNECT,
+    TAPDISK_MESSAGE_XENBLKIF_CONNECT_RSP,
+    TAPDISK_MESSAGE_XENBLKIF_DISCONNECT,
+    TAPDISK_MESSAGE_XENBLKIF_DISCONNECT_RSP,
+    TAPDISK_MESSAGE_EXIT,
+};
+
+#define TAPDISK_MESSAGE_MAX TAPDISK_MESSAGE_EXIT
+
+/**
+ * Retrieves the human-readable representation of the type of the message.
+ */
+static inline char *tapdisk_message_name(enum tapdisk_message_id id)
+{
+    switch (id) {
+    case TAPDISK_MESSAGE_ERROR:
+        return "error";
+
+    case TAPDISK_MESSAGE_PID:
+        return "pid";
+
+    case TAPDISK_MESSAGE_PID_RSP:
+        return "pid response";
+
+    case TAPDISK_MESSAGE_OPEN:
+        return "open";
+
+    case TAPDISK_MESSAGE_OPEN_RSP:
+        return "open response";
+
+    case TAPDISK_MESSAGE_PAUSE:
+        return "pause";
+
+    case TAPDISK_MESSAGE_PAUSE_RSP:
+        return "pause response";
+
+    case TAPDISK_MESSAGE_RESUME:
+        return "resume";
+
+    case TAPDISK_MESSAGE_RESUME_RSP:
+        return "resume response";
+
+    case TAPDISK_MESSAGE_CLOSE:
+        return "close";
+
+    case TAPDISK_MESSAGE_FORCE_SHUTDOWN:
+        return "force shutdown";
+
+    case TAPDISK_MESSAGE_CLOSE_RSP:
+        return "close response";
+
+    case TAPDISK_MESSAGE_ATTACH:
+        return "attach";
+
+    case TAPDISK_MESSAGE_ATTACH_RSP:
+        return "attach response";
+
+    case TAPDISK_MESSAGE_DETACH:
+        return "detach";
+
+    case TAPDISK_MESSAGE_DETACH_RSP:
+        return "detach response";
+
+    case TAPDISK_MESSAGE_LIST_MINORS:
+        return "list minors";
+
+    case TAPDISK_MESSAGE_LIST_MINORS_RSP:
+        return "list minors response";
+
+    case TAPDISK_MESSAGE_LIST:
+        return "list";
+
+    case TAPDISK_MESSAGE_LIST_RSP:
+        return "list response";
+
+    case TAPDISK_MESSAGE_STATS:
+        return "stats";
+
+    case TAPDISK_MESSAGE_STATS_RSP:
+        return "stats response";
+
+    case TAPDISK_MESSAGE_DISK_INFO:
+        return "disk info";
+
+    case TAPDISK_MESSAGE_DISK_INFO_RSP:
+        return "disk info response";
+
+    case TAPDISK_MESSAGE_XENBLKIF_CONNECT:
+        return "blkif connect";
+
+    case TAPDISK_MESSAGE_XENBLKIF_CONNECT_RSP:
+        return "blkif connect response";
+
+    case TAPDISK_MESSAGE_XENBLKIF_DISCONNECT:
+        return "blkif disconnect";
+
+    case TAPDISK_MESSAGE_XENBLKIF_DISCONNECT_RSP:
+        return "blkif disconnect response";
+
+    case TAPDISK_MESSAGE_EXIT:
+        return "exit";
+
+    default:
+        return "unknown";
+    }
+}
+
+#endif /* __TAPDISK_MESSAGE_H__ */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 17:03:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 17:03:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR4MT-0004IP-21; Wed, 24 Oct 2012 17:03:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR4MM-0004Dh-Ro
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 17:03:15 +0000
Received: from [85.158.137.99:64650] by server-9.bemta-3.messagelabs.com id
	8D/C2-16841-25F18805; Wed, 24 Oct 2012 17:03:14 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1351098192!22853898!8
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30269 invoked from network); 24 Oct 2012 17:03:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 17:03:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15366087"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 17:02:37 +0000
Received: from [127.0.1.1] (10.80.3.216) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 18:02:37 +0100
MIME-Version: 1.0
X-Mercurial-Node: 0f87cc018fb689f212cb35c5a8e95367d1379ab4
Message-ID: <0f87cc018fb689f212cb.1351098155@makatos-desktop>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 24 Oct 2012 18:02:35 +0100
From: Thanos Makatos 
To: xen-devel@lists.xensource.com
Cc: thanos.makatos@citrix.com
Subject: [Xen-devel] [PATCH 16 of 16 RFC] blktap3: Implement
 libxl__blktap_devpath and libxl__device_destroy_tapdisk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Provide implementation for the libxl__blktap_devpath and
libxl__device_destroy_tapdisk functions: the former spawns the tapdisk process,
the latter destroys it. Both of these functions use the blktap_find function,
a function that lists all running tapdisks and looks for one serving a specific
file. Finally, link libxl with the blktap3 control library.

diff -r b12c1bb767d3 -r 0f87cc018fb6 tools/libxl/Makefile
--- a/tools/libxl/Makefile	Wed Oct 24 17:28:12 2012 +0100
+++ b/tools/libxl/Makefile	Wed Oct 24 17:42:44 2012 +0100
@@ -20,7 +20,7 @@ LIBUUID_LIBS += -luuid
 endif
 
 LIBXL_LIBS =
-LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS)
+LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS) $(LDLIBS_libblktapctl)
 
 CFLAGS_LIBXL += $(CFLAGS_libxenctrl)
 CFLAGS_LIBXL += $(CFLAGS_libxenguest)
@@ -29,7 +29,9 @@ CFLAGS_LIBXL += $(CFLAGS_libblktapctl)
 CFLAGS_LIBXL += -Wshadow
 
 CFLAGS += $(PTHREAD_CFLAGS)
-LDFLAGS += $(PTHREAD_LDFLAGS)
+override LDFLAGS += \
+	$(PTHREAD_LDFLAGS) \
+	-L $(XEN_BLKTAP3)/control
 LIBXL_LIBS += $(PTHREAD_LIBS)
 
 LIBXLU_LIBS =
@@ -172,6 +174,7 @@ libxenlight.so.$(MAJOR): libxenlight.so.
 	ln -sf $< $@
 
 libxenlight.so.$(MAJOR).$(MINOR): $(LIBXL_OBJS)
+	make -C $(XEN_BLKTAP3)
 	$(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxenlight.so.$(MAJOR) $(SHLIB_LDFLAGS) -o $@ $^ $(LIBXL_LIBS) $(APPEND_LDFLAGS)
 
 libxenlight.a: $(LIBXL_OBJS)
diff -r b12c1bb767d3 -r 0f87cc018fb6 tools/libxl/libxl_blktap3.c
--- a/tools/libxl/libxl_blktap3.c	Wed Oct 24 17:28:12 2012 +0100
+++ b/tools/libxl/libxl_blktap3.c	Wed Oct 24 17:42:44 2012 +0100
@@ -1,11 +1,176 @@
+/*
+ * FIXME license
+ */
+
 #include "libxl_osdeps.h"
 #include "libxl_internal.h"
+#include "tap-ctl.h"
 
-int libxl__blktap_devpath(libxl__gc *gc, const char *disk,
-    libxl_disk_format format) {
-    return -ENOSYS;
+/**
+ * Retrieves the tapdisk serving the specified file.
+ *
+ * @param type
+ * @param path
+ * @param tap output parameter that receives the tapdisk information
+ *
+ * @return 0 on success, an error code otherwise
+ *
+ * TODO If neither type nor path are specified, the first tapdisk will be
+ * returned. Not sure if this behaviour is desirable...
+ */
+static int blktap_find(libxl__gc *gc, const char *type, const char *path,
+        struct tap_list *tap)
+{
+    struct tqh_tap_list list;
+    struct tap_list *entry, *next_t;
+    int ret = -ENOENT, err;
+
+    /*
+     * Get all the tapdisks.
+     */
+    TAILQ_INIT(&list);
+    err = tap_ctl_list(&list);
+    if (err) {
+        LOG(DEBUG, "can't list tapdisks: %s\n", strerror(err));
+        return err;
+    }
+
+    if (TAILQ_EMPTY(&list))
+        return ret;
+
+    tap_list_for_each_entry_safe(entry, next_t, &list) {
+
+        /*
+         * Look for the tapdisk that matches the type and path. If the user
+         * supplied a NULL type/path, it's treated as a matching one.
+         */
+
+        if (type && (!entry->type || strcmp(entry->type, type)))
+            continue;
+
+        if (path && (!entry->path || strcmp(entry->path, path)))
+            continue;
+
+        *tap = *entry;
+
+        /*
+         * Set them to NULL so that when the user calls tap_ctl_list_free it
+         * won't free them. The strings weren't copied by the assignment above!
+         */
+        tap->type = tap->path = NULL;
+
+        ret = 0;
+        break;
+    }
+
+    tap_ctl_list_free(&list);
+
+    return ret;
 }
 
-int libxl__device_destroy_tapdisk(libxl__gc *gc, const char *be_path) {
-    return -ENOSYS;
+/**
+ * Creates a tapdisk for the specified path.
+ *
+ * TODO document parameters
+ *
+ * @param gc
+ * @param disk
+ * @param format
+ *
+ * @returns 0 on success, an error code otherwise
+ */
+int libxl__blktap_devpath(libxl__gc *gc, const char *disk,
+        libxl_disk_format format)
+{
+    const char *type = NULL;
+    char *params = NULL;
+    struct tap_list tap;
+    int err = 0;
+
+    type = libxl__device_disk_string_of_format(format);
+
+    /*
+     * Ensure that no other tapdisk is serving this path.
+     * XXX Does libxl protect us against race conditions? What if somebody
+     * manually attaches a tapdisk to this path?
+     */
+    if (!(err = blktap_find(gc, type, disk, &tap))) {
+        LOG(DEBUG, "tapdisk %d already serving %s\n", tap.pid, disk);
+        return 0;
+    }
+
+    LOG(DEBUG, "tapdisk not found\n");
+
+    /*
+     * TODO Should we worry about return codes other than ENOENT?
+     */
+
+    params = libxl__sprintf(gc, "%s:%s", type, disk);
+    if (!(err = tap_ctl_create(params, 0, -1, NULL))) {
+        LOG(DEBUG, "created tapdisk\n");        
+        return 0;
+    }
+
+    LOG(ERROR, "error creating tapdisk: %s\n", strerror(err));
+
+    return err;
 }
+
+/**
+ * Destroys the tapdisk serving the specified path.
+ *
+ * TODO document parameters
+ *
+ * @param gc
+ * @param be_path
+ *
+ * @returns 0 on success, an error code otherwise
+ */
+int libxl__device_destroy_tapdisk(libxl__gc *gc, const char *be_path)
+{
+    char *disk;
+    int err;
+    struct tap_list tap;
+
+    LOG(DEBUG, "destroying tapdisk %s\n", be_path);
+
+    /*
+     * TODO is the path is in the following format?
+     * :/path/to/file
+     */
+    disk = strchr(be_path, ':');
+    if (!disk) {
+        LOG(ERROR, "Unable to parse params %s", be_path);
+        return ERROR_INVAL;
+    }
+
+    /*
+     * Replace the ':' with '\0' effectively creating two strings in the same
+     * buffer: the first is the type and the second is the path.
+     */ 
+    *disk++ = '\0';
+
+    err = blktap_find(gc, be_path, disk, &tap);
+    if (err < 0) {
+        /* returns -errno */
+        LOGEV(ERROR, -err, "Unable to find type %s disk %s", be_path, disk);
+        return ERROR_FAIL;
+    }
+
+    err = tap_ctl_destroy(tap.pid, tap.minor, 0, NULL);
+    if (err < 0) {
+        LOGEV(ERROR, -err, "Failed to destroy tap device id %d minor %d",
+              tap.pid, tap.minor);
+        return ERROR_FAIL;
+    }
+
+    return 0;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 17:03:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 17:03:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR4MN-0004Ek-Sj; Wed, 24 Oct 2012 17:03:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR4ML-0004DH-V0
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 17:03:14 +0000
Received: from [85.158.137.99:64615] by server-1.bemta-3.messagelabs.com id
	90/A6-31728-15F18805; Wed, 24 Oct 2012 17:03:13 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1351098192!22853898!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30187 invoked from network); 24 Oct 2012 17:03:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 17:03:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15366075"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 17:02:35 +0000
Received: from [127.0.1.1] (10.80.3.216) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 18:02:35 +0100
MIME-Version: 1.0
X-Mercurial-Node: 57896068356d4870c74a527623b9e9c26df40846
Message-ID: <57896068356d4870c74a.1351098144@makatos-desktop>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 24 Oct 2012 18:02:24 +0100
From: Thanos Makatos 
To: 
Cc: thanos.makatos@citrix.com
Subject: [Xen-devel] [PATCH 05 of 16 RFC] blktap3: Don't check if blktap is
	available
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Don't check if blktap is enabled since it will always be enabled (no blktap/blkback requirement anymore).

diff -r bcb5a6182868 -r 57896068356d tools/libxl/libxl_blktap3.c
--- a/tools/libxl/libxl_blktap3.c	Wed Oct 24 17:25:02 2012 +0100
+++ b/tools/libxl/libxl_blktap3.c	Wed Oct 24 17:25:12 2012 +0100
@@ -1,10 +1,6 @@
 #include "libxl_osdeps.h"
 #include "libxl_internal.h"
 
-int libxl__blktap_enabled(libxl__gc *gc) {
-    return 1;
-}
-
 int libxl__blktap_devpath(libxl__gc *gc, const char *disk,
     libxl_disk_format format) {
     return -ENOSYS;
diff -r bcb5a6182868 -r 57896068356d tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Wed Oct 24 17:25:02 2012 +0100
+++ b/tools/libxl/libxl_device.c	Wed Oct 24 17:25:12 2012 +0100
@@ -177,13 +177,6 @@ static int disk_try_backend(disk_try_bac
 
     case LIBXL_DISK_BACKEND_TAP:
         if (a->disk->script) goto bad_script;
-
-        if (!libxl__blktap_enabled(a->gc)) {
-            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, backend tap"
-                       " unsuitable because blktap not available",
-                       a->disk->vdev);
-            return 0;
-        }
         if (!(a->disk->format == LIBXL_DISK_FORMAT_RAW ||
               a->disk->format == LIBXL_DISK_FORMAT_VHD)) {
             goto bad_format;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 17:03:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 17:03:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR4MR-0004Gn-7f; Wed, 24 Oct 2012 17:03:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR4MM-0004DI-Qp
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 17:03:15 +0000
Received: from [85.158.137.99:41849] by server-5.bemta-3.messagelabs.com id
	23/E9-12440-25F18805; Wed, 24 Oct 2012 17:03:14 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1351098192!22853898!9
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30280 invoked from network); 24 Oct 2012 17:03:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 17:03:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15366081"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 17:02:36 +0000
Received: from [127.0.1.1] (10.80.3.216) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 18:02:36 +0100
MIME-Version: 1.0
X-Mercurial-Node: a17c7217bef2913aee6de4394e92c3adf194fafb
Message-ID: 
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 24 Oct 2012 18:02:29 +0100
From: Thanos Makatos 
To: xen-devel@lists.xensource.com
Cc: thanos.makatos@citrix.com
Subject: [Xen-devel] [PATCH 10 of 16 RFC] blktap3: Introduce the blktap
	header file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In this file various file-system paths are specified, similar to the XEN
blktap2. These defines need to be documented. Unused defines (i.e. IOCTLs) have
been removed.

diff -r efb6b2844256 -r a17c7217bef2 tools/blktap3/include/blktap.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/blktap3/include/blktap.h	Wed Oct 24 17:26:14 2012 +0100
@@ -0,0 +1,85 @@
+/*
+ * FIXME this is the github blktap2 license.
+ *
+ * Copyright (c) 2008, XenSource Inc.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *     * Redistributions of source code must retain the above copyright
+ *       notice, this list of conditions and the following disclaimer.
+ *     * Redistributions in binary form must reproduce the above copyright
+ *       notice, this list of conditions and the following disclaimer in the
+ *       documentation and/or other materials provided with the distribution.
+ *     * Neither the name of XenSource Inc. nor the names of its contributors
+ *       may be used to endorse or promote products derived from this software
+ *       without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER
+ * OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
+ * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
+ * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+ * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
+ * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef __BLKTAP_3_H__
+#define __BLKTAP_3_H__
+
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * TODO Document what each define is.
+ */
+#define BLKTAP3_SYSFS_DIR                   "/sys/class/blktap3"
+#define BLKTAP3_CONTROL_NAME                "blktap-control"
+#define BLKTAP3_CONTROL_DIR                 "/var/run/"BLKTAP3_CONTROL_NAME
+#define BLKTAP3_CONTROL_SOCKET              "ctl"
+#define BLKTAP3_DIRECTORY                   "/dev/xen/blktap-3"
+#define BLKTAP3_RING_DEVICE                 BLKTAP3_DIRECTORY"/blktap"
+#define BLKTAP3_IO_DEVICEBLKTAP3_DIRECTORY  "/tapdev"
+#define BLKTAP3_ENOSPC_SIGNAL_FILE          "/var/run/tapdisk3-enospc"
+
+/*
+ * TODO Can these be supplied from somewhere else?
+ */
+#define likely(_cond)   __builtin_expect(!!(_cond), 1)
+#define unlikely(_cond) __builtin_expect(!!(_cond), 0)
+
+/*
+ * FIXME taken from list.h
+ */
+#define containerof(_ptr, _type, _memb) \
+    ((_type*)((void*)(_ptr) - offsetof(_type, _memb)))
+
+/*
+ * FIXME shouldn't these be supplied from somewhere?
+ */
+#define __printf(a, b) __attribute__((format(printf, a, b)))
+#define __scanf(_f, _a) __attribute__((format (scanf, _f, _a)))
+
+#define TAILQ_MOVE_HEAD(node, src, dst, entry)  \
+    TAILQ_REMOVE(src, node, entry);             \
+    TAILQ_INSERT_HEAD(dst, node, entry);
+
+#define TAILQ_MOVE_TAIL(node, src, dst, entry)  \
+    TAILQ_REMOVE(src, node, entry);             \
+    TAILQ_INSERT_TAIL(dst, node, entry);
+
+/*
+ * TODO This is defined in xen/lib.h, use that instead of redefining it
+ * here.
+ */
+#ifndef ARRAY_SIZE
+#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
+#endif /* ARRAY_SIZE */
+
+#endif /* __BLKTAP_3_H__ */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 17:03:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 17:03:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR4MN-0004Ek-Sj; Wed, 24 Oct 2012 17:03:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR4ML-0004DH-V0
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 17:03:14 +0000
Received: from [85.158.137.99:64615] by server-1.bemta-3.messagelabs.com id
	90/A6-31728-15F18805; Wed, 24 Oct 2012 17:03:13 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1351098192!22853898!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30187 invoked from network); 24 Oct 2012 17:03:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 17:03:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15366075"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 17:02:35 +0000
Received: from [127.0.1.1] (10.80.3.216) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 18:02:35 +0100
MIME-Version: 1.0
X-Mercurial-Node: 57896068356d4870c74a527623b9e9c26df40846
Message-ID: <57896068356d4870c74a.1351098144@makatos-desktop>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 24 Oct 2012 18:02:24 +0100
From: Thanos Makatos 
To: 
Cc: thanos.makatos@citrix.com
Subject: [Xen-devel] [PATCH 05 of 16 RFC] blktap3: Don't check if blktap is
	available
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Don't check if blktap is enabled since it will always be enabled (no blktap/blkback requirement anymore).

diff -r bcb5a6182868 -r 57896068356d tools/libxl/libxl_blktap3.c
--- a/tools/libxl/libxl_blktap3.c	Wed Oct 24 17:25:02 2012 +0100
+++ b/tools/libxl/libxl_blktap3.c	Wed Oct 24 17:25:12 2012 +0100
@@ -1,10 +1,6 @@
 #include "libxl_osdeps.h"
 #include "libxl_internal.h"
 
-int libxl__blktap_enabled(libxl__gc *gc) {
-    return 1;
-}
-
 int libxl__blktap_devpath(libxl__gc *gc, const char *disk,
     libxl_disk_format format) {
     return -ENOSYS;
diff -r bcb5a6182868 -r 57896068356d tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Wed Oct 24 17:25:02 2012 +0100
+++ b/tools/libxl/libxl_device.c	Wed Oct 24 17:25:12 2012 +0100
@@ -177,13 +177,6 @@ static int disk_try_backend(disk_try_bac
 
     case LIBXL_DISK_BACKEND_TAP:
         if (a->disk->script) goto bad_script;
-
-        if (!libxl__blktap_enabled(a->gc)) {
-            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, backend tap"
-                       " unsuitable because blktap not available",
-                       a->disk->vdev);
-            return 0;
-        }
         if (!(a->disk->format == LIBXL_DISK_FORMAT_RAW ||
               a->disk->format == LIBXL_DISK_FORMAT_VHD)) {
             goto bad_format;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 17:03:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 17:03:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR4MN-0004EN-HE; Wed, 24 Oct 2012 17:03:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR4MM-0004DE-15
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 17:03:14 +0000
Received: from [85.158.137.99:64594] by server-3.bemta-3.messagelabs.com id
	4C/6D-09368-05F18805; Wed, 24 Oct 2012 17:03:12 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1351098192!22853898!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30158 invoked from network); 24 Oct 2012 17:03:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 17:03:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15366070"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 17:02:34 +0000
Received: from [127.0.1.1] (10.80.3.216) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 18:02:34 +0100
MIME-Version: 1.0
Message-ID: 
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 24 Oct 2012 18:02:19 +0100
From: Thanos Makatos 
To: 
Cc: thanos.makatos@citrix.com
Subject: [Xen-devel] [PATCH 00 of 16 RFC] add libxl support for blktap3 and
 introduce the blktap3 build system
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This series introduces support for blktap3 in libxl and adds the basis of the
blktap3 build system. There is no essential blktap3 functionality yet: all
blktap3 functions are stubs and they will be implemented in later patches. This
means that trying to use tap as the disk backend for a guest will make libxl
complain since all of blktap3 functions return a failure error code. Most
header files introduced in this series require some basic documentation.
Finally, licenses need to be verified.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 17:03:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 17:03:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR4MR-0004HR-Vo; Wed, 24 Oct 2012 17:03:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR4MN-0004Dt-6p
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 17:03:15 +0000
Received: from [85.158.137.99:64675] by server-16.bemta-3.messagelabs.com id
	9A/E2-07461-25F18805; Wed, 24 Oct 2012 17:03:14 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1351098192!22853898!10
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30290 invoked from network); 24 Oct 2012 17:03:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 17:03:14 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15366080"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 17:02:36 +0000
Received: from [127.0.1.1] (10.80.3.216) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 18:02:36 +0100
MIME-Version: 1.0
X-Mercurial-Node: efb6b2844256020918ca4abd055e1b3cd2bcffe8
Message-ID: 
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 24 Oct 2012 18:02:28 +0100
From: Thanos Makatos 
To: xen-devel@lists.xensource.com
Cc: thanos.makatos@citrix.com
Subject: [Xen-devel] [PATCH 09 of 16 RFC] blktap3: Introduce the tapdisk
 control function prototypes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This file is based on the github blktap2, which in turn is based on the XEN
blktap2. Most of the changes here are prototype function changes introduced by
the the github blktap2. In blktap3, Linux lists are replaced with BSD tail
queues.

diff -r 23e2537c7257 -r efb6b2844256 tools/blktap3/include/tap-ctl.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/blktap3/include/tap-ctl.h	Wed Oct 24 17:26:04 2012 +0100
@@ -0,0 +1,184 @@
+/*
+ * FIXME this is the github blktap2 license
+ *
+ * Copyright (c) 2008, XenSource Inc.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *     * Redistributions of source code must retain the above copyright
+ *       notice, this list of conditions and the following disclaimer.
+ *     * Redistributions in binary form must reproduce the above copyright
+ *       notice, this list of conditions and the following disclaimer in the
+ *       documentation and/or other materials provided with the distribution.
+ *     * Neither the name of XenSource Inc. nor the names of its contributors
+ *       may be used to endorse or promote products derived from this software
+ *       without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER
+ * OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
+ * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
+ * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+ * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
+ * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef __TAP_CTL_H__
+#define __TAP_CTL_H__
+
+#include 
+#include 
+#include 
+#include 
+#include "blktap.h"
+
+/**
+ * Contains information about a tapdisk process.
+ */
+typedef struct tap_list {
+
+    /**
+     * The process ID.
+     */
+    pid_t pid;
+
+    /**
+     * TODO? 
+     */
+    int minor;
+
+    /**
+     * State of the VBD, specified in drivers/tapdisk-vbd.h.
+     */
+    int state;
+
+    /**
+     * TODO type?
+     */
+    char *type;
+
+    /**
+     * /path/to/file
+     */
+    char *path;
+
+    /**
+     * for linked lists
+     */
+    TAILQ_ENTRY(tap_list) entry;
+} tap_list_t;
+
+TAILQ_HEAD(tqh_tap_list, tap_list);
+
+/**
+ * Iterate over a list of struct tap_list.
+ */
+#define tap_list_for_each_entry(_pos, _head) \
+    TAILQ_FOREACH(_pos, _head, entry)
+
+/**
+ * Iterate over a list of struct tap_list allowing deletions without having to
+ * restart the iteration.
+ */
+#define tap_list_for_each_entry_safe(_pos, _n, _head) \
+    TAILQ_FOREACH_SAFE(_pos, _head, entry, _n)
+
+/**
+ * Connects to a tapdisk.
+ *
+ * @param /path/to/file of the control socket (e.g. /var/run/blktap-control/ctl/
+ * @param socket output parameter that receives the connection
+ * @returns 0 on success, an error code otherwise
+ */
+int tap_ctl_connect(const char *path, int *socket);
+
+/**
+ * Connects to a tapdisk.
+ *
+ * @param id the process ID of the tapdisk to connect to
+ * @param socket output parameter that receives the connection
+ * @returns 0 on success, an error code otherwise
+ */
+int tap_ctl_connect_id(const int id, int *socket);
+
+/**
+ * Reads from the tapdisk connection to the buffer.
+ *
+ * @param fd the file descriptor of the socket to read from
+ * @param buf buffer that receives the output
+ * @param sz size, in bytes, of the buffer
+ * @param timeout (optional) specifies the maximum time to wait for reading
+ * @returns 0 on success, an error code otherwise
+ */
+int tap_ctl_read_raw(const int fd, void *buf, const size_t sz,
+        struct timeval *timeout);
+
+int tap_ctl_read_message(int fd, tapdisk_message_t * message,
+                         struct timeval *timeout);
+int tap_ctl_write_message(int fd, tapdisk_message_t * message,
+                          struct timeval *timeout);
+int tap_ctl_send_and_receive(int fd, tapdisk_message_t * message,
+                             struct timeval *timeout);
+int tap_ctl_connect_send_and_receive(int id, tapdisk_message_t * message,
+                                     struct timeval *timeout);
+char *tap_ctl_socket_name(int id);
+int tap_ctl_list_pid(pid_t pid, struct tqh_tap_list *list);
+
+
+/**
+ * Retrieves a list of all tapdisks.
+ *
+ * @param list output parameter that receives the list of tapdisks
+ * @returns 0 on success, an error code otherwise
+ */
+int tap_ctl_list(struct tqh_tap_list *list);
+
+/**
+ * Deallocates a list of struct tap_list.
+ *
+ * @param list the tapdisk information structure to deallocate.
+ */
+void tap_ctl_list_free(struct tqh_tap_list *list);
+
+/**
+ * Creates a tapdisk process.
+ *
+ * TODO document parameters
+ * @param params
+ * @param flags
+ * @param prt_minor
+ * @param secondary
+ * @returns 0 on success, en error code otherwise
+ */
+int tap_ctl_create(const char *params, int flags, int prt_minor,
+                   char *secondary);
+int tap_ctl_destroy(const int id, const int minor, int force,
+                    struct timeval *timeout);
+
+/*
+ * TODO The following functions are not currently used by anything else other
+ * than the tapdisk itself. Move to a private header?
+ */
+int tap_ctl_spawn(void);
+pid_t tap_ctl_get_pid(const int id);
+
+int tap_ctl_attach(const int id, const int minor);
+int tap_ctl_detach(const int id, const int minor);
+
+int tap_ctl_open(const int id, const int minor, const char *params,
+                 int flags, const int prt_minor, const char *secondary);
+int tap_ctl_close(const int id, const int minor, const int force,
+                  struct timeval *timeout);
+
+int tap_ctl_pause(const int id, const int minor, struct timeval *timeout);
+int tap_ctl_unpause(const int id, const int minor, const char *params);
+
+ssize_t tap_ctl_stats(pid_t pid, int minor, char *buf, size_t size);
+int tap_ctl_stats_fwrite(pid_t pid, int minor, FILE * out);
+
+#endif /* __TAP_CTL_H__ */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 17:03:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 17:03:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR4MT-0004IP-21; Wed, 24 Oct 2012 17:03:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR4MM-0004Dh-Ro
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 17:03:15 +0000
Received: from [85.158.137.99:64650] by server-9.bemta-3.messagelabs.com id
	8D/C2-16841-25F18805; Wed, 24 Oct 2012 17:03:14 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1351098192!22853898!8
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30269 invoked from network); 24 Oct 2012 17:03:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 17:03:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15366087"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 17:02:37 +0000
Received: from [127.0.1.1] (10.80.3.216) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 18:02:37 +0100
MIME-Version: 1.0
X-Mercurial-Node: 0f87cc018fb689f212cb35c5a8e95367d1379ab4
Message-ID: <0f87cc018fb689f212cb.1351098155@makatos-desktop>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 24 Oct 2012 18:02:35 +0100
From: Thanos Makatos 
To: xen-devel@lists.xensource.com
Cc: thanos.makatos@citrix.com
Subject: [Xen-devel] [PATCH 16 of 16 RFC] blktap3: Implement
 libxl__blktap_devpath and libxl__device_destroy_tapdisk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Provide implementation for the libxl__blktap_devpath and
libxl__device_destroy_tapdisk functions: the former spawns the tapdisk process,
the latter destroys it. Both of these functions use the blktap_find function,
a function that lists all running tapdisks and looks for one serving a specific
file. Finally, link libxl with the blktap3 control library.

diff -r b12c1bb767d3 -r 0f87cc018fb6 tools/libxl/Makefile
--- a/tools/libxl/Makefile	Wed Oct 24 17:28:12 2012 +0100
+++ b/tools/libxl/Makefile	Wed Oct 24 17:42:44 2012 +0100
@@ -20,7 +20,7 @@ LIBUUID_LIBS += -luuid
 endif
 
 LIBXL_LIBS =
-LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS)
+LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS) $(LDLIBS_libblktapctl)
 
 CFLAGS_LIBXL += $(CFLAGS_libxenctrl)
 CFLAGS_LIBXL += $(CFLAGS_libxenguest)
@@ -29,7 +29,9 @@ CFLAGS_LIBXL += $(CFLAGS_libblktapctl)
 CFLAGS_LIBXL += -Wshadow
 
 CFLAGS += $(PTHREAD_CFLAGS)
-LDFLAGS += $(PTHREAD_LDFLAGS)
+override LDFLAGS += \
+	$(PTHREAD_LDFLAGS) \
+	-L $(XEN_BLKTAP3)/control
 LIBXL_LIBS += $(PTHREAD_LIBS)
 
 LIBXLU_LIBS =
@@ -172,6 +174,7 @@ libxenlight.so.$(MAJOR): libxenlight.so.
 	ln -sf $< $@
 
 libxenlight.so.$(MAJOR).$(MINOR): $(LIBXL_OBJS)
+	make -C $(XEN_BLKTAP3)
 	$(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxenlight.so.$(MAJOR) $(SHLIB_LDFLAGS) -o $@ $^ $(LIBXL_LIBS) $(APPEND_LDFLAGS)
 
 libxenlight.a: $(LIBXL_OBJS)
diff -r b12c1bb767d3 -r 0f87cc018fb6 tools/libxl/libxl_blktap3.c
--- a/tools/libxl/libxl_blktap3.c	Wed Oct 24 17:28:12 2012 +0100
+++ b/tools/libxl/libxl_blktap3.c	Wed Oct 24 17:42:44 2012 +0100
@@ -1,11 +1,176 @@
+/*
+ * FIXME license
+ */
+
 #include "libxl_osdeps.h"
 #include "libxl_internal.h"
+#include "tap-ctl.h"
 
-int libxl__blktap_devpath(libxl__gc *gc, const char *disk,
-    libxl_disk_format format) {
-    return -ENOSYS;
+/**
+ * Retrieves the tapdisk serving the specified file.
+ *
+ * @param type
+ * @param path
+ * @param tap output parameter that receives the tapdisk information
+ *
+ * @return 0 on success, an error code otherwise
+ *
+ * TODO If neither type nor path are specified, the first tapdisk will be
+ * returned. Not sure if this behaviour is desirable...
+ */
+static int blktap_find(libxl__gc *gc, const char *type, const char *path,
+        struct tap_list *tap)
+{
+    struct tqh_tap_list list;
+    struct tap_list *entry, *next_t;
+    int ret = -ENOENT, err;
+
+    /*
+     * Get all the tapdisks.
+     */
+    TAILQ_INIT(&list);
+    err = tap_ctl_list(&list);
+    if (err) {
+        LOG(DEBUG, "can't list tapdisks: %s\n", strerror(err));
+        return err;
+    }
+
+    if (TAILQ_EMPTY(&list))
+        return ret;
+
+    tap_list_for_each_entry_safe(entry, next_t, &list) {
+
+        /*
+         * Look for the tapdisk that matches the type and path. If the user
+         * supplied a NULL type/path, it's treated as a matching one.
+         */
+
+        if (type && (!entry->type || strcmp(entry->type, type)))
+            continue;
+
+        if (path && (!entry->path || strcmp(entry->path, path)))
+            continue;
+
+        *tap = *entry;
+
+        /*
+         * Set them to NULL so that when the user calls tap_ctl_list_free it
+         * won't free them. The strings weren't copied by the assignment above!
+         */
+        tap->type = tap->path = NULL;
+
+        ret = 0;
+        break;
+    }
+
+    tap_ctl_list_free(&list);
+
+    return ret;
 }
 
-int libxl__device_destroy_tapdisk(libxl__gc *gc, const char *be_path) {
-    return -ENOSYS;
+/**
+ * Creates a tapdisk for the specified path.
+ *
+ * TODO document parameters
+ *
+ * @param gc
+ * @param disk
+ * @param format
+ *
+ * @returns 0 on success, an error code otherwise
+ */
+int libxl__blktap_devpath(libxl__gc *gc, const char *disk,
+        libxl_disk_format format)
+{
+    const char *type = NULL;
+    char *params = NULL;
+    struct tap_list tap;
+    int err = 0;
+
+    type = libxl__device_disk_string_of_format(format);
+
+    /*
+     * Ensure that no other tapdisk is serving this path.
+     * XXX Does libxl protect us against race conditions? What if somebody
+     * manually attaches a tapdisk to this path?
+     */
+    if (!(err = blktap_find(gc, type, disk, &tap))) {
+        LOG(DEBUG, "tapdisk %d already serving %s\n", tap.pid, disk);
+        return 0;
+    }
+
+    LOG(DEBUG, "tapdisk not found\n");
+
+    /*
+     * TODO Should we worry about return codes other than ENOENT?
+     */
+
+    params = libxl__sprintf(gc, "%s:%s", type, disk);
+    if (!(err = tap_ctl_create(params, 0, -1, NULL))) {
+        LOG(DEBUG, "created tapdisk\n");        
+        return 0;
+    }
+
+    LOG(ERROR, "error creating tapdisk: %s\n", strerror(err));
+
+    return err;
 }
+
+/**
+ * Destroys the tapdisk serving the specified path.
+ *
+ * TODO document parameters
+ *
+ * @param gc
+ * @param be_path
+ *
+ * @returns 0 on success, an error code otherwise
+ */
+int libxl__device_destroy_tapdisk(libxl__gc *gc, const char *be_path)
+{
+    char *disk;
+    int err;
+    struct tap_list tap;
+
+    LOG(DEBUG, "destroying tapdisk %s\n", be_path);
+
+    /*
+     * TODO is the path is in the following format?
+     * :/path/to/file
+     */
+    disk = strchr(be_path, ':');
+    if (!disk) {
+        LOG(ERROR, "Unable to parse params %s", be_path);
+        return ERROR_INVAL;
+    }
+
+    /*
+     * Replace the ':' with '\0' effectively creating two strings in the same
+     * buffer: the first is the type and the second is the path.
+     */ 
+    *disk++ = '\0';
+
+    err = blktap_find(gc, be_path, disk, &tap);
+    if (err < 0) {
+        /* returns -errno */
+        LOGEV(ERROR, -err, "Unable to find type %s disk %s", be_path, disk);
+        return ERROR_FAIL;
+    }
+
+    err = tap_ctl_destroy(tap.pid, tap.minor, 0, NULL);
+    if (err < 0) {
+        LOGEV(ERROR, -err, "Failed to destroy tap device id %d minor %d",
+              tap.pid, tap.minor);
+        return ERROR_FAIL;
+    }
+
+    return 0;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 17:03:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 17:03:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR4MP-0004FC-2G; Wed, 24 Oct 2012 17:03:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR4MM-0004DI-9j
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 17:03:14 +0000
Received: from [85.158.137.99:12280] by server-5.bemta-3.messagelabs.com id
	BE/D9-12440-15F18805; Wed, 24 Oct 2012 17:03:13 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1351098192!22853898!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30201 invoked from network); 24 Oct 2012 17:03:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 17:03:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15366073"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 17:02:34 +0000
Received: from [127.0.1.1] (10.80.3.216) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 18:02:35 +0100
MIME-Version: 1.0
X-Mercurial-Node: 80e0bc67dcdaadc40d3a197a7d6640d3b07b400e
Message-ID: <80e0bc67dcdaadc40d3a.1351098142@makatos-desktop>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 24 Oct 2012 18:02:22 +0100
From: Thanos Makatos 
To: xen-devel@lists.xensource.com
Cc: thanos.makatos@citrix.com
Subject: [Xen-devel] [PATCH 03 of 16 RFC] blktap3: support for blktap3 in
	libxl Makefile
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Point the libxl Makefile to the blktap3 include and library directories instead
of the blktap2 ones, don't link with the blktap2 control library, and compile
libxl with the unimplemented functions introduced in the previous patch.

diff -r 513739de43b5 -r 80e0bc67dcda tools/Rules.mk
--- a/tools/Rules.mk	Wed Oct 24 17:24:37 2012 +0100
+++ b/tools/Rules.mk	Wed Oct 24 17:24:53 2012 +0100
@@ -15,6 +15,7 @@ XEN_XENLIGHT       = $(XEN_ROOT)/tools/l
 XEN_XENSTORE       = $(XEN_ROOT)/tools/xenstore
 XEN_LIBXENSTAT     = $(XEN_ROOT)/tools/xenstat/libxenstat/src
 XEN_BLKTAP2        = $(XEN_ROOT)/tools/blktap2
+XEN_BLKTAP3        = $(XEN_ROOT)/tools/blktap3
 XEN_LIBVCHAN       = $(XEN_ROOT)/tools/libvchan
 
 CFLAGS_xeninclude = -I$(XEN_INCLUDE)
@@ -46,9 +47,9 @@ LIBXL_BLKTAP ?= n
 endif
 
 ifeq ($(LIBXL_BLKTAP),y)
-CFLAGS_libblktapctl = -I$(XEN_BLKTAP2)/control -I$(XEN_BLKTAP2)/include $(CFLAGS_xeninclude)
-LDLIBS_libblktapctl = -L$(XEN_BLKTAP2)/control -lblktapctl
-SHLIB_libblktapctl  = -Wl,-rpath-link=$(XEN_BLKTAP2)/control
+CFLAGS_libblktapctl = -I$(XEN_BLKTAP3)/control -I$(XEN_BLKTAP3)/include $(CFLAGS_xeninclude)
+LDLIBS_libblktapctl = -L$(XEN_BLKTAP3)/control -lblktapctl
+SHLIB_libblktapctl  = -Wl,-rpath-link=$(XEN_BLKTAP3)/control
 else
 CFLAGS_libblktapctl =
 LDLIBS_libblktapctl =
diff -r 513739de43b5 -r 80e0bc67dcda tools/libxl/Makefile
--- a/tools/libxl/Makefile	Wed Oct 24 17:24:37 2012 +0100
+++ b/tools/libxl/Makefile	Wed Oct 24 17:24:53 2012 +0100
@@ -20,7 +20,7 @@ LIBUUID_LIBS += -luuid
 endif
 
 LIBXL_LIBS =
-LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS)
+LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS)
 
 CFLAGS_LIBXL += $(CFLAGS_libxenctrl)
 CFLAGS_LIBXL += $(CFLAGS_libxenguest)
@@ -36,9 +36,9 @@ LIBXLU_LIBS =
 
 LIBXL_OBJS-y = osdeps.o libxl_paths.o libxl_bootloader.o flexarray.o
 ifeq ($(LIBXL_BLKTAP),y)
-LIBXL_OBJS-y += libxl_blktap2.o
+LIBXL_OBJS-y += libxl_blktap3.o
 else
-LIBXL_OBJS-y += libxl_noblktap2.o
+LIBXL_OBJS-y += libxl_noblktap3.o
 endif
 LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o
 LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o libxl_noarch.o
@@ -77,7 +77,8 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_c
 			libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
-$(LIBXL_OBJS): CFLAGS += $(CFLAGS_LIBXL) -include $(XEN_ROOT)/tools/config.h
+$(LIBXL_OBJS): CFLAGS += $(CFLAGS_LIBXL) -include $(XEN_ROOT)/tools/config.h \
+	$(CFLAGS_libblktapctl)
 
 AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h _paths.h \
 	_libxl_save_msgs_callout.h _libxl_save_msgs_helper.h

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 17:03:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 17:03:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR4MN-0004EC-4z; Wed, 24 Oct 2012 17:03:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR4MM-0004DD-0q
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 17:03:14 +0000
Received: from [85.158.137.99:64602] by server-7.bemta-3.messagelabs.com id
	99/A2-06991-15F18805; Wed, 24 Oct 2012 17:03:13 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1351098192!22853898!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30175 invoked from network); 24 Oct 2012 17:03:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 17:03:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15366071"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 17:02:34 +0000
Received: from [127.0.1.1] (10.80.3.216) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 18:02:34 +0100
MIME-Version: 1.0
X-Mercurial-Node: fef81de66bf7461516cb1d51c4616363356dcc4b
Message-ID: 
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 24 Oct 2012 18:02:20 +0100
From: Thanos Makatos 
To: xen-devel@lists.xensource.com
Cc: thanos.makatos@citrix.com
Subject: [Xen-devel] [PATCH 01 of 16 RFC] blktap3: Introduce the blktap3
	device type
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This device is used when tap is specifed as the disk backend, instead of vbd.

diff -r 3cd5bf62ded7 -r fef81de66bf7 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Wed Oct 24 17:22:39 2012 +0100
+++ b/tools/libxl/libxl.c	Wed Oct 24 17:24:01 2012 +0100
@@ -1742,7 +1742,7 @@ int libxl__device_from_disk(libxl__gc *g
             device->backend_kind = LIBXL__DEVICE_KIND_VBD;
             break;
         case LIBXL_DISK_BACKEND_TAP:
-            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
+            device->backend_kind = LIBXL__DEVICE_KIND_XENIO;
             break;
         case LIBXL_DISK_BACKEND_QDISK:
             device->backend_kind = LIBXL__DEVICE_KIND_QDISK;
diff -r 3cd5bf62ded7 -r fef81de66bf7 tools/libxl/libxl_types_internal.idl
--- a/tools/libxl/libxl_types_internal.idl	Wed Oct 24 17:22:39 2012 +0100
+++ b/tools/libxl/libxl_types_internal.idl	Wed Oct 24 17:24:01 2012 +0100
@@ -19,6 +19,7 @@ libxl__device_kind = Enumeration("device
     (5, "VFB"),
     (6, "VKBD"),
     (7, "CONSOLE"),
+    (8, "XENIO"),
     ])
 
 libxl__console_backend = Enumeration("console_backend", [

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 17:03:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 17:03:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR4MP-0004FU-Fs; Wed, 24 Oct 2012 17:03:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR4MM-0004DK-HK
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 17:03:14 +0000
Received: from [85.158.137.99:64630] by server-4.bemta-3.messagelabs.com id
	2A/2F-01405-15F18805; Wed, 24 Oct 2012 17:03:13 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1351098192!22853898!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30239 invoked from network); 24 Oct 2012 17:03:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 17:03:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15366077"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 17:02:35 +0000
Received: from [127.0.1.1] (10.80.3.216) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 18:02:35 +0100
MIME-Version: 1.0
X-Mercurial-Node: 17eea5a9a20cc43d7de11f5abed870d721105892
Message-ID: <17eea5a9a20cc43d7de1.1351098146@makatos-desktop>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 24 Oct 2012 18:02:26 +0100
From: Thanos Makatos 
To: xen-devel@lists.xensource.com
Cc: thanos.makatos@citrix.com
Subject: [Xen-devel] [PATCH 07 of 16 RFC] blktap3: Introduce blktap3
	top-level Makefile
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

diff -r 5a0b0e799ae8 -r 17eea5a9a20c tools/blktap3/Makefile
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/blktap3/Makefile	Wed Oct 24 17:25:32 2012 +0100
@@ -0,0 +1,12 @@
+XEN_ROOT := $(CURDIR)/../../
+include $(XEN_ROOT)/tools/Rules.mk
+
+all: build
+
+build: ;
+
+clean: ;
+
+install: ;
+
+.PHONY: all build clean install

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 17:03:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 17:03:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR4MP-0004FU-Fs; Wed, 24 Oct 2012 17:03:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR4MM-0004DK-HK
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 17:03:14 +0000
Received: from [85.158.137.99:64630] by server-4.bemta-3.messagelabs.com id
	2A/2F-01405-15F18805; Wed, 24 Oct 2012 17:03:13 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1351098192!22853898!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30239 invoked from network); 24 Oct 2012 17:03:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 17:03:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15366077"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 17:02:35 +0000
Received: from [127.0.1.1] (10.80.3.216) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 18:02:35 +0100
MIME-Version: 1.0
X-Mercurial-Node: 17eea5a9a20cc43d7de11f5abed870d721105892
Message-ID: <17eea5a9a20cc43d7de1.1351098146@makatos-desktop>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 24 Oct 2012 18:02:26 +0100
From: Thanos Makatos 
To: xen-devel@lists.xensource.com
Cc: thanos.makatos@citrix.com
Subject: [Xen-devel] [PATCH 07 of 16 RFC] blktap3: Introduce blktap3
	top-level Makefile
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

diff -r 5a0b0e799ae8 -r 17eea5a9a20c tools/blktap3/Makefile
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/blktap3/Makefile	Wed Oct 24 17:25:32 2012 +0100
@@ -0,0 +1,12 @@
+XEN_ROOT := $(CURDIR)/../../
+include $(XEN_ROOT)/tools/Rules.mk
+
+all: build
+
+build: ;
+
+clean: ;
+
+install: ;
+
+.PHONY: all build clean install

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 17:03:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 17:03:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR4MP-0004Fj-Rd; Wed, 24 Oct 2012 17:03:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR4MM-0004DJ-JG
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 17:03:14 +0000
Received: from [85.158.143.35:25973] by server-1.bemta-4.messagelabs.com id
	D1/39-19134-15F18805; Wed, 24 Oct 2012 17:03:13 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1351098192!7768901!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27897 invoked from network); 24 Oct 2012 17:03:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 17:03:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15366076"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 17:02:35 +0000
Received: from [127.0.1.1] (10.80.3.216) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 18:02:35 +0100
MIME-Version: 1.0
X-Mercurial-Node: 5a0b0e799ae8c1dadedc5a2601da561229ae4ed4
Message-ID: <5a0b0e799ae8c1dadedc.1351098145@makatos-desktop>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 24 Oct 2012 18:02:25 +0100
From: Thanos Makatos 
To: xen-devel@lists.xensource.com
Cc: thanos.makatos@citrix.com
Subject: [Xen-devel] [PATCH 06 of 16 RFC] blktap3: Remove physical device
 creation for libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

blktap3 doesn't need a device in dom0.

diff -r 57896068356d -r 5a0b0e799ae8 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Wed Oct 24 17:25:12 2012 +0100
+++ b/tools/libxl/libxl.c	Wed Oct 24 17:25:26 2012 +0100
@@ -1818,7 +1818,6 @@ static void device_disk_add(libxl__egc *
             case LIBXL_DISK_BACKEND_PHY:
                 dev = disk->pdev_path;
 
-        do_backend_phy:
                 flexarray_append(back, "params");
                 flexarray_append(back, dev);
 
@@ -1856,13 +1855,7 @@ static void device_disk_add(libxl__egc *
                 flexarray_append(back, libxl__sprintf(gc, "%s:%s",
                     libxl__device_disk_string_of_format(disk->format),
                     disk->pdev_path));
-
-                /* tap backends with scripts are rejected by
-                 * libxl__device_disk_set_backend */
-                assert(!disk->script);
-
-                /* now create a phy device to export the device to the guest */
-                goto do_backend_phy;
+                break;
             case LIBXL_DISK_BACKEND_QDISK:
                 flexarray_append(back, "params");
                 flexarray_append(back, libxl__sprintf(gc, "%s:%s",

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 17:03:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 17:03:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR4MO-0004Et-8c; Wed, 24 Oct 2012 17:03:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR4ML-0004DF-W8
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 17:03:14 +0000
Received: from [85.158.137.99:41809] by server-2.bemta-3.messagelabs.com id
	89/40-00604-15F18805; Wed, 24 Oct 2012 17:03:13 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1351098192!22853898!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30165 invoked from network); 24 Oct 2012 17:03:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 17:03:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15366072"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 17:02:34 +0000
Received: from [127.0.1.1] (10.80.3.216) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 18:02:34 +0100
MIME-Version: 1.0
X-Mercurial-Node: 513739de43b51c832e04bb23b31e6908b1bf97e0
Message-ID: <513739de43b51c832e04.1351098141@makatos-desktop>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 24 Oct 2012 18:02:21 +0100
From: Thanos Makatos 
To: xen-devel@lists.xensource.com
Cc: thanos.makatos@citrix.com
Subject: [Xen-devel] [PATCH 02 of 16 RFC] blktap3: Introduce blktap3 support
	for libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

These functions will be implemented at a later patch.

diff -r fef81de66bf7 -r 513739de43b5 tools/libxl/libxl_blktap3.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxl/libxl_blktap3.c	Wed Oct 24 17:24:37 2012 +0100
@@ -0,0 +1,15 @@
+#include "libxl_osdeps.h"
+#include "libxl_internal.h"
+
+int libxl__blktap_enabled(libxl__gc *gc) {
+    return 1;
+}
+
+char *libxl__blktap_devpath(libxl__gc *gc, const char *disk,
+    libxl_disk_format format) {
+    return NULL;
+}
+
+int libxl__device_destroy_tapdisk(libxl__gc *gc, const char *be_path) {
+    return -ENOSYS;
+}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 17:03:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 17:03:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR4MT-0004In-G8; Wed, 24 Oct 2012 17:03:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR4MN-0004DJ-FQ
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 17:03:15 +0000
Received: from [85.158.143.35:64113] by server-1.bemta-4.messagelabs.com id
	5B/39-19134-35F18805; Wed, 24 Oct 2012 17:03:15 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1351098192!7768901!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28011 invoked from network); 24 Oct 2012 17:03:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 17:03:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15366079"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 17:02:35 +0000
Received: from [127.0.1.1] (10.80.3.216) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 24 Oct 2012 18:02:36 +0100
MIME-Version: 1.0
X-Mercurial-Node: 23e2537c7257e0e5b00ecf02441f23095a4e0a93
Message-ID: <23e2537c7257e0e5b00e.1351098147@makatos-desktop>
In-Reply-To: 
References: 
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 24 Oct 2012 18:02:27 +0100
From: Thanos Makatos 
To: xen-devel@lists.xensource.com
Cc: thanos.makatos@citrix.com
Subject: [Xen-devel] [PATCH 08 of 16 RFC] blktap3: Introduce message types
	and structures
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The main difference over the the XEN version is the addition of the stats
structure (used for retrieving stats from a running tapdisk), and the addition
of the tapdisk_message_blkif struct, which is required for the user-space
counterpart of blktap/blkback to communicate with tapdisk.

diff -r 17eea5a9a20c -r 23e2537c7257 tools/blktap3/include/tapdisk-message.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/blktap3/include/tapdisk-message.h	Wed Oct 24 17:25:37 2012 +0100
@@ -0,0 +1,267 @@
+/* FIXME this is the github blktap2 license (which is the same the blktap2
+ * license)
+ *
+ * Copyright (c) 2008, XenSource Inc.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *     * Redistributions of source code must retain the above copyright
+ *       notice, this list of conditions and the following disclaimer.
+ *     * Redistributions in binary form must reproduce the above copyright
+ *       notice, this list of conditions and the following disclaimer in the
+ *       documentation and/or other materials provided with the distribution.
+ *     * Neither the name of XenSource Inc. nor the names of its contributors
+ *       may be used to endorse or promote products derived from this software
+ *       without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER
+ * OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
+ * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
+ * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+ * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
+ * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef __TAPDISK_MESSAGE_H__
+#define __TAPDISK_MESSAGE_H__
+
+#include 
+#include 
+
+#define TAPDISK_MESSAGE_MAX_PATH_LENGTH  256
+#define TAPDISK_MESSAGE_STRING_LENGTH    256
+
+#define TAPDISK_MESSAGE_MAX_MINORS \
+    ((TAPDISK_MESSAGE_MAX_PATH_LENGTH / sizeof(int)) - 1)
+
+#define TAPDISK_MESSAGE_FLAG_SHARED      0x001
+#define TAPDISK_MESSAGE_FLAG_RDONLY      0x002
+#define TAPDISK_MESSAGE_FLAG_ADD_CACHE   0x004
+#define TAPDISK_MESSAGE_FLAG_VHD_INDEX   0x008
+#define TAPDISK_MESSAGE_FLAG_LOG_DIRTY   0x010
+#define TAPDISK_MESSAGE_FLAG_ADD_LCACHE  0x020
+#define TAPDISK_MESSAGE_FLAG_REUSE_PRT   0x040
+#define TAPDISK_MESSAGE_FLAG_SECONDARY   0x080
+#define TAPDISK_MESSAGE_FLAG_STANDBY     0x100
+
+typedef struct tapdisk_message tapdisk_message_t;
+typedef uint32_t tapdisk_message_flag_t;
+typedef struct tapdisk_message_image tapdisk_message_image_t;
+typedef struct tapdisk_message_params tapdisk_message_params_t;
+typedef struct tapdisk_message_string tapdisk_message_string_t;
+typedef struct tapdisk_message_response tapdisk_message_response_t;
+typedef struct tapdisk_message_minors tapdisk_message_minors_t;
+typedef struct tapdisk_message_list tapdisk_message_list_t;
+typedef struct tapdisk_message_stat tapdisk_message_stat_t;
+typedef struct tapdisk_message_blkif tapdisk_message_blkif_t;
+
+struct tapdisk_message_params {
+    tapdisk_message_flag_t flags;
+
+    uint32_t devnum;
+    uint32_t domid;
+    char path[TAPDISK_MESSAGE_MAX_PATH_LENGTH];
+    uint32_t prt_devnum;
+    char secondary[TAPDISK_MESSAGE_MAX_PATH_LENGTH];
+};
+
+struct tapdisk_message_image {
+    uint64_t sectors;
+    uint32_t sector_size;
+    uint32_t info;
+};
+
+struct tapdisk_message_string {
+    char text[TAPDISK_MESSAGE_STRING_LENGTH];
+};
+
+struct tapdisk_message_response {
+    int error;
+    char message[TAPDISK_MESSAGE_STRING_LENGTH];
+};
+
+struct tapdisk_message_minors {
+    int count;
+    int list[TAPDISK_MESSAGE_MAX_MINORS];
+};
+
+struct tapdisk_message_list {
+    int count;
+    int minor;
+    int state;
+    char path[TAPDISK_MESSAGE_MAX_PATH_LENGTH];
+};
+
+struct tapdisk_message_stat {
+    uint16_t type;
+    uint16_t cookie;
+    size_t length;
+};
+
+struct tapdisk_message_blkif {
+    uint32_t domid;
+    uint32_t devid;
+    uint32_t gref[8];
+    uint32_t order;
+    uint32_t proto;
+    char pool[TAPDISK_MESSAGE_STRING_LENGTH];
+    uint32_t port;
+};
+
+struct tapdisk_message {
+    uint16_t type;
+    uint16_t cookie;
+
+    union {
+        pid_t tapdisk_pid;
+        tapdisk_message_image_t image;
+        tapdisk_message_params_t params;
+        tapdisk_message_string_t string;
+        tapdisk_message_minors_t minors;
+        tapdisk_message_response_t response;
+        tapdisk_message_list_t list;
+        tapdisk_message_stat_t info;
+        tapdisk_message_blkif_t blkif;
+    } u;
+};
+
+enum tapdisk_message_id {
+    TAPDISK_MESSAGE_ERROR = 1,
+    TAPDISK_MESSAGE_RUNTIME_ERROR,
+    TAPDISK_MESSAGE_PID,
+    TAPDISK_MESSAGE_PID_RSP,
+    TAPDISK_MESSAGE_ATTACH,
+    TAPDISK_MESSAGE_ATTACH_RSP,
+    TAPDISK_MESSAGE_OPEN,
+    TAPDISK_MESSAGE_OPEN_RSP,
+    TAPDISK_MESSAGE_PAUSE,
+    TAPDISK_MESSAGE_PAUSE_RSP,
+    TAPDISK_MESSAGE_RESUME,
+    TAPDISK_MESSAGE_RESUME_RSP,
+    TAPDISK_MESSAGE_CLOSE,
+    TAPDISK_MESSAGE_CLOSE_RSP,
+    TAPDISK_MESSAGE_DETACH,
+    TAPDISK_MESSAGE_DETACH_RSP,
+    TAPDISK_MESSAGE_LIST_MINORS,
+    TAPDISK_MESSAGE_LIST_MINORS_RSP,
+    TAPDISK_MESSAGE_LIST,
+    TAPDISK_MESSAGE_LIST_RSP,
+    TAPDISK_MESSAGE_STATS,
+    TAPDISK_MESSAGE_STATS_RSP,
+    TAPDISK_MESSAGE_FORCE_SHUTDOWN,
+    TAPDISK_MESSAGE_DISK_INFO,
+    TAPDISK_MESSAGE_DISK_INFO_RSP,
+    TAPDISK_MESSAGE_XENBLKIF_CONNECT,
+    TAPDISK_MESSAGE_XENBLKIF_CONNECT_RSP,
+    TAPDISK_MESSAGE_XENBLKIF_DISCONNECT,
+    TAPDISK_MESSAGE_XENBLKIF_DISCONNECT_RSP,
+    TAPDISK_MESSAGE_EXIT,
+};
+
+#define TAPDISK_MESSAGE_MAX TAPDISK_MESSAGE_EXIT
+
+/**
+ * Retrieves the human-readable representation of the type of the message.
+ */
+static inline char *tapdisk_message_name(enum tapdisk_message_id id)
+{
+    switch (id) {
+    case TAPDISK_MESSAGE_ERROR:
+        return "error";
+
+    case TAPDISK_MESSAGE_PID:
+        return "pid";
+
+    case TAPDISK_MESSAGE_PID_RSP:
+        return "pid response";
+
+    case TAPDISK_MESSAGE_OPEN:
+        return "open";
+
+    case TAPDISK_MESSAGE_OPEN_RSP:
+        return "open response";
+
+    case TAPDISK_MESSAGE_PAUSE:
+        return "pause";
+
+    case TAPDISK_MESSAGE_PAUSE_RSP:
+        return "pause response";
+
+    case TAPDISK_MESSAGE_RESUME:
+        return "resume";
+
+    case TAPDISK_MESSAGE_RESUME_RSP:
+        return "resume response";
+
+    case TAPDISK_MESSAGE_CLOSE:
+        return "close";
+
+    case TAPDISK_MESSAGE_FORCE_SHUTDOWN:
+        return "force shutdown";
+
+    case TAPDISK_MESSAGE_CLOSE_RSP:
+        return "close response";
+
+    case TAPDISK_MESSAGE_ATTACH:
+        return "attach";
+
+    case TAPDISK_MESSAGE_ATTACH_RSP:
+        return "attach response";
+
+    case TAPDISK_MESSAGE_DETACH:
+        return "detach";
+
+    case TAPDISK_MESSAGE_DETACH_RSP:
+        return "detach response";
+
+    case TAPDISK_MESSAGE_LIST_MINORS:
+        return "list minors";
+
+    case TAPDISK_MESSAGE_LIST_MINORS_RSP:
+        return "list minors response";
+
+    case TAPDISK_MESSAGE_LIST:
+        return "list";
+
+    case TAPDISK_MESSAGE_LIST_RSP:
+        return "list response";
+
+    case TAPDISK_MESSAGE_STATS:
+        return "stats";
+
+    case TAPDISK_MESSAGE_STATS_RSP:
+        return "stats response";
+
+    case TAPDISK_MESSAGE_DISK_INFO:
+        return "disk info";
+
+    case TAPDISK_MESSAGE_DISK_INFO_RSP:
+        return "disk info response";
+
+    case TAPDISK_MESSAGE_XENBLKIF_CONNECT:
+        return "blkif connect";
+
+    case TAPDISK_MESSAGE_XENBLKIF_CONNECT_RSP:
+        return "blkif connect response";
+
+    case TAPDISK_MESSAGE_XENBLKIF_DISCONNECT:
+        return "blkif disconnect";
+
+    case TAPDISK_MESSAGE_XENBLKIF_DISCONNECT_RSP:
+        return "blkif disconnect response";
+
+    case TAPDISK_MESSAGE_EXIT:
+        return "exit";
+
+    default:
+        return "unknown";
+    }
+}
+
+#endif /* __TAPDISK_MESSAGE_H__ */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 17:36:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 17:36:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR4sG-0007LR-8r; Wed, 24 Oct 2012 17:36:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR4sF-0007LM-Jd
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 17:36:11 +0000
Received: from [193.109.254.147:31934] by server-12.bemta-14.messagelabs.com
	id 6C/F1-00510-A0728805; Wed, 24 Oct 2012 17:36:10 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1351100169!11257632!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 998 invoked from network); 24 Oct 2012 17:36:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 17:36:10 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15367022"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 17:36:09 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 24 Oct 2012 18:36:09 +0100
Date: Wed, 24 Oct 2012 18:35:40 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Tim Deegan 
In-Reply-To: <20121024155945.GD39126@ocelot.phlegethon.org>
Message-ID: 
References: 
	<1351091027-20740-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20121024155945.GD39126@ocelot.phlegethon.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	Ian Campbell ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 6/7] xen/arm: flush D-cache and I-cache when
 appropriate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 24 Oct 2012, Tim Deegan wrote:
> At 16:03 +0100 on 24 Oct (1351094626), Stefano Stabellini wrote:
> > - invalidate tlb after setting WXN;
> > - flush D-cache and I-cache after relocation;
> > - flush D-cache after writing to smp_up_cpu;
> > - flush TLB before changing HTTBR;
> > - flush I-cache after changing HTTBR;
> > - flush I-cache and branch predictor after writing Xen text ptes.
> > 
> > Signed-off-by: Stefano Stabellini 
> 
> > @@ -244,10 +245,18 @@ void __init setup_pagetables(unsigned long boot_phys_offset, paddr_t xen_paddr)
> >  
> >      /* Change pagetables to the copy in the relocated Xen */
> >      boot_httbr = (unsigned long) xen_pgtable + phys_offset;
> > +    flush_xen_dcache_va((unsigned long)&boot_httbr);
> > +    for ( i = 0; i < _end - _start; i += cacheline_size )
> > +        flush_xen_dcache_va(dest_va + i);
> > +    flush_xen_text_tlb();
> > +
> >      asm volatile (
> > +        "dsb;"                        /* Ensure visibility of HTTBR update */
> 
> That comment should be changed -- this dsb is to make sure all the PT
> changes are completed, right?

The comment is certainly wrong. I actually think that this dsb is
not necessary, thanks to flush_xen_text_tlb.


> >          STORE_CP64(0, HTTBR)          /* Change translation base */
> >          "dsb;"                        /* Ensure visibility of HTTBR update */
> > +        "isb;"
> >          STORE_CP32(0, TLBIALLH)       /* Flush hypervisor TLB */
> > +        STORE_CP32(0, ICIALLU)        /* Flush I-cache */
> >          STORE_CP32(0, BPIALL)         /* Flush branch predictor */
> >          "dsb;"                        /* Ensure completion of TLB+BP flush */
> >          "isb;"
> 
> > diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
> > index 9511c45..7d70d8c 100644
> > --- a/xen/include/asm-arm/page.h
> > +++ b/xen/include/asm-arm/page.h
> > @@ -232,13 +232,26 @@ static inline lpae_t mfn_to_p2m_entry(unsigned long mfn, unsigned int mattr)
> >  static inline void write_pte(lpae_t *p, lpae_t pte)
> >  {
> >      asm volatile (
> > +        "dsb;"
> 
> I guess this is to make sure all writes that used the old mapping have
> completed?  Can you add a comment?

Yes, that is exactly the reason. I'll add a comment.


> >          /* Safely write the entry (STRD is atomic on CPUs that support LPAE) */
> >          "strd %0, %H0, [%1];"
> > +        "dsb;"
> >          /* Push this cacheline to the PoC so the rest of the system sees it. */
> >          STORE_CP32(1, DCCMVAC)
> > +        "isb;"
> 
> This is for code modifications, right?  I think we can drop it, and have
> all the paths that modify text mappings do explicit isb()s there -- the
> vast majority of PTE writes don't need it. 

Yes. Thinking twice about it we should have a dsb there instead, for data
mappings too, otherwise we can't be sure that the DCCMVAC is completed
before returning.


> >          : : "r" (pte.bits), "r" (p) : "memory");
> >  }
> >  
> > +static inline void flush_xen_dcache_va(unsigned long va)
> 
> Three of the four users of this function cast their arguments from
> pointer types - maybe it should take a void * instead?.

I can do that


> > +{
> > +    register unsigned long r0 asm ("r0") = va;
> 
> I don't think this is necessary - why not just pass va directly to the
> inline asm?  We don't care what register it's in (and if we did I'm not
> convinced this would guarantee it was r0).
> 
> > +    asm volatile (
> > +        "dsb;"
> > +        STORE_CP32(0, DCCMVAC)
> > +        "isb;"
> > +        : : "r" (r0) : "memory");
> 
> Does this need a 'memory' clobber?  Can we get away with just saying it
> consumes *va as an input?  All we need to be sure of is that the
> particular thing we're flushing has been written out; no need to stop
> any other optimizations.

you are right on both points


> I guess it might need to be re-cast as a macro so the compiler knows how
> big *va is?

I don't think it is necessary, after all the size of a register has to
be the same of a virtual address

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 17:36:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 17:36:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR4sG-0007LR-8r; Wed, 24 Oct 2012 17:36:12 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR4sF-0007LM-Jd
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 17:36:11 +0000
Received: from [193.109.254.147:31934] by server-12.bemta-14.messagelabs.com
	id 6C/F1-00510-A0728805; Wed, 24 Oct 2012 17:36:10 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1351100169!11257632!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 998 invoked from network); 24 Oct 2012 17:36:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 17:36:10 -0000
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="15367022"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 17:36:09 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 24 Oct 2012 18:36:09 +0100
Date: Wed, 24 Oct 2012 18:35:40 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Tim Deegan 
In-Reply-To: <20121024155945.GD39126@ocelot.phlegethon.org>
Message-ID: 
References: 
	<1351091027-20740-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20121024155945.GD39126@ocelot.phlegethon.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	Ian Campbell ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 6/7] xen/arm: flush D-cache and I-cache when
 appropriate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 24 Oct 2012, Tim Deegan wrote:
> At 16:03 +0100 on 24 Oct (1351094626), Stefano Stabellini wrote:
> > - invalidate tlb after setting WXN;
> > - flush D-cache and I-cache after relocation;
> > - flush D-cache after writing to smp_up_cpu;
> > - flush TLB before changing HTTBR;
> > - flush I-cache after changing HTTBR;
> > - flush I-cache and branch predictor after writing Xen text ptes.
> > 
> > Signed-off-by: Stefano Stabellini 
> 
> > @@ -244,10 +245,18 @@ void __init setup_pagetables(unsigned long boot_phys_offset, paddr_t xen_paddr)
> >  
> >      /* Change pagetables to the copy in the relocated Xen */
> >      boot_httbr = (unsigned long) xen_pgtable + phys_offset;
> > +    flush_xen_dcache_va((unsigned long)&boot_httbr);
> > +    for ( i = 0; i < _end - _start; i += cacheline_size )
> > +        flush_xen_dcache_va(dest_va + i);
> > +    flush_xen_text_tlb();
> > +
> >      asm volatile (
> > +        "dsb;"                        /* Ensure visibility of HTTBR update */
> 
> That comment should be changed -- this dsb is to make sure all the PT
> changes are completed, right?

The comment is certainly wrong. I actually think that this dsb is
not necessary, thanks to flush_xen_text_tlb.


> >          STORE_CP64(0, HTTBR)          /* Change translation base */
> >          "dsb;"                        /* Ensure visibility of HTTBR update */
> > +        "isb;"
> >          STORE_CP32(0, TLBIALLH)       /* Flush hypervisor TLB */
> > +        STORE_CP32(0, ICIALLU)        /* Flush I-cache */
> >          STORE_CP32(0, BPIALL)         /* Flush branch predictor */
> >          "dsb;"                        /* Ensure completion of TLB+BP flush */
> >          "isb;"
> 
> > diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
> > index 9511c45..7d70d8c 100644
> > --- a/xen/include/asm-arm/page.h
> > +++ b/xen/include/asm-arm/page.h
> > @@ -232,13 +232,26 @@ static inline lpae_t mfn_to_p2m_entry(unsigned long mfn, unsigned int mattr)
> >  static inline void write_pte(lpae_t *p, lpae_t pte)
> >  {
> >      asm volatile (
> > +        "dsb;"
> 
> I guess this is to make sure all writes that used the old mapping have
> completed?  Can you add a comment?

Yes, that is exactly the reason. I'll add a comment.


> >          /* Safely write the entry (STRD is atomic on CPUs that support LPAE) */
> >          "strd %0, %H0, [%1];"
> > +        "dsb;"
> >          /* Push this cacheline to the PoC so the rest of the system sees it. */
> >          STORE_CP32(1, DCCMVAC)
> > +        "isb;"
> 
> This is for code modifications, right?  I think we can drop it, and have
> all the paths that modify text mappings do explicit isb()s there -- the
> vast majority of PTE writes don't need it. 

Yes. Thinking twice about it we should have a dsb there instead, for data
mappings too, otherwise we can't be sure that the DCCMVAC is completed
before returning.


> >          : : "r" (pte.bits), "r" (p) : "memory");
> >  }
> >  
> > +static inline void flush_xen_dcache_va(unsigned long va)
> 
> Three of the four users of this function cast their arguments from
> pointer types - maybe it should take a void * instead?.

I can do that


> > +{
> > +    register unsigned long r0 asm ("r0") = va;
> 
> I don't think this is necessary - why not just pass va directly to the
> inline asm?  We don't care what register it's in (and if we did I'm not
> convinced this would guarantee it was r0).
> 
> > +    asm volatile (
> > +        "dsb;"
> > +        STORE_CP32(0, DCCMVAC)
> > +        "isb;"
> > +        : : "r" (r0) : "memory");
> 
> Does this need a 'memory' clobber?  Can we get away with just saying it
> consumes *va as an input?  All we need to be sure of is that the
> particular thing we're flushing has been written out; no need to stop
> any other optimizations.

you are right on both points


> I guess it might need to be re-cast as a macro so the compiler knows how
> big *va is?

I don't think it is necessary, after all the size of a register has to
be the same of a virtual address

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 17:37:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 17:37:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR4t2-0007PD-N6; Wed, 24 Oct 2012 17:37:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR4t0-0007Ow-AA
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 17:36:59 +0000
Received: from [85.158.139.211:41957] by server-4.bemta-5.messagelabs.com id
	B3/90-01455-93728805; Wed, 24 Oct 2012 17:36:57 +0000
X-Env-Sender: jefranca@gmail.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1351100214!23626333!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21058 invoked from network); 24 Oct 2012 17:36:56 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 17:36:56 -0000
Received: by mail-vc0-f173.google.com with SMTP id fl15so68142vcb.32
	for ; Wed, 24 Oct 2012 10:36:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=SEBgB/8zHhAsOXb+SgiHQsWuem34c0gJ932lNyrBjXs=;
	b=MBWiWGmbCPNADWnd9JY3JpAjYMDxUU1fJGQSeA1BJyoPF+Ojuyw7BmJJAk1Xc3M8Uu
	9fbOMcCtvLAAeXHK7WDspzUHzN0ym0IAkSRg5jDoySwLBZ1bsZIwvvqqyWKwA3cn/HlK
	GTab7fzRLecyhtFnK3I+6sMqD9KvdK+tFbDW9EW5xxFLoqPsOl74YFTfRiTBFWod0git
	raxb/y+ZR6tZOLjs3EJ4qpJfQ18iKfejdhLZ2wxBjSX9Q9Q3DRhr6Zcw6XXMjTuvN/AE
	jKrD+4mOVgYRiq72FDPqPS5DCM7bOyj2LKuLP6mGFTW1KRBZ8yfDVI3fHiJwS5zM9IYy
	UQmw==
MIME-Version: 1.0
Received: by 10.52.72.132 with SMTP id d4mr14884180vdv.91.1351100214137; Wed,
	24 Oct 2012 10:36:54 -0700 (PDT)
Received: by 10.58.13.9 with HTTP; Wed, 24 Oct 2012 10:36:53 -0700 (PDT)
In-Reply-To: 
References: 
	<75A1D5EB-12C7-4829-A3F7-4D77B2405FBB@gmail.com>
	
	
	
Date: Wed, 24 Oct 2012 15:36:53 -0200
Message-ID: 
From: =?ISO-8859-1?Q?Jos=E9_Eduardo_Fran=E7a?= 
To: xen-devel@lists.xen.org
Content-Type: multipart/mixed; boundary=bcaec501655751d1f904ccd188f0
Subject: [Xen-devel] Fwd:  How to get the checkpoint size in remus code?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--bcaec501655751d1f904ccd188f0
Content-Type: multipart/alternative; boundary=bcaec501655751d1f504ccd188ee

--bcaec501655751d1f504ccd188ee
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

---------- Forwarded message ----------
From: Jos=E9 Eduardo Fran=E7a 
Date: 2012/10/17
Subject: Re: [Xen-devel] How to get the checkpoint size in remus code?
To: rshriram@cs.ubc.ca


Hi Shriram,

Thank you for your reply. I'm sorry coz I saw your email yesterday and my
English is bad.
Ok... I saw your patch but I need to explain more my problem.

In my master research, I intend to deploy a based-time dynamic checkpoint
that should work this way: if checkpoint size breaks *Lmax* (see attached
figure) I reduce checkpoint interval, and if checkpoint size doesn't break =
*
Lmin* I increase checkpoint interval. After that I will evaluate the
performace.

I had read remus code and I saw that remus control the elapsed time in

            endtime =3D time.time()
            elapsed =3D (endtime - closure.starttime) * 1000

            if elapsed < cfg.interval:
                time.sleep((cfg.interval - elapsed) / 1000.0)

Then I thought I could change the checkpoint interval close to code above,
but I suppose I need get checkpoint size. But here the remus code is python
and I saw (or thought) that checkpoint size is gotten on *xc_shadow_op_stat=
s_t
*stats* or better on *stats->dirty_count*PAGE_SIZE*.

Would I get checkpoint size into remus code? I thought it's easier this way
for I intend to do.
Please, help me, coz my time is running out.

Thanks jefranca

PS: My English is terrible coz I'm not native


2012/10/5 Shriram Rajagopalan 

> On Wed, Oct 3, 2012 at 4:11 AM, Jos=E9 Eduardo Fran=E7a 
> wrote:
> >
> > I thought remus used xc_domain_save. Is this function used from live
> > migration?
> >
> > Futhermore I have two doubts if really Remus takes the last iteration o=
f
> > live migration
> >
> > What's the function?
>
> There is no specific function. xc_domain_save is where everything
> happens. The infinite loop
> that basically keeps sending checkpoints @ a particular frequency
>
>
> > And how to get de I/O disk size on each period?
> >
>
> This depends on the disk backend. With blktap2 (unfortunately not
> available in 3.* kernels)
> tap-remus driver can give you the number of disk blocks sent per
> checkpoint.
>
> With DRBD, it needs a little bit of hacking into the kernel module to
> return the number of disk blocks
> being sent with each checkpoint.
>
>
> >> I'm doing my master research and I need to adapt remus code. Now... I
> >> wanna get the checkpoint size (memory + disk) on each period. Does
> someone
> >> know what function does this? I think some fd object's function in rem=
us
> >> code could just get the memory size.
> >>
>
> You can get memory checkpoint stats for each iteration - like
> number of pages dirtied, size of data actually transmitted after
> compression (including headers, etc),
> time to checkpoint, etc.
>
> The attached patch (for xen-4.1.2) will give you the memory checkpoint
> stats for each checkpoint and
> can be easily parsed.
>
> shriram
>

--bcaec501655751d1f504ccd188ee
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



---------- Forwarded message ----------<=
br>From: Jos=E9 Eduardo Fran=E7a <jefranca@gmail.com&=
gt;

Date: 2012/10/17
Subject: Re: [Xen-devel] How to get the checkpoint size=
 in remus code?
To: rshriram@cs.ub=
c.ca


Hi Shriram,

Thank you for your reply. I'm so=
rry coz I saw your email yesterday and my English is bad.

Ok... I saw your patch but I need to explain more my problem.

In my =
master research, I intend to deploy a based-time dynamic checkpoint that sh=
ould work this way: if checkpoint size breaks Lmax (see attached fig=
ure) I reduce checkpoint interval, and if checkpoint size doesn't break=
 Lmin  I increase checkpoint interval. After that I will evaluate th=
e performace.



I had read remus code and I saw that remus control the elapsed time in<=
br>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 endtime =3D time.time()
=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0 elapsed =3D (endtime - closure.starttime) * 100=
0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 if elapsed < cfg.interval:

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 time.sleep((cfg.interval - el=
apsed) / 1000.0)

Then I thought I could change the checkpoint interv=
al close to code above, but I suppose I need get checkpoint size. But here =
the  remus code is python and I saw (or thought) that checkpoint size is go=
tten on xc_shadow_op_stats_t *stats or better on stats->dirty_=
count*PAGE_SIZE.



Would I get checkpoint size into remus code? I thought it's easier =
this way for I intend to do.
Please, help me, coz my time is running out.


Thanks jefranca

PS: My English is terrible coz I'm not nativ=
e


2012/10/5 Shriram Rajagopalan <rshriram@cs.ubc.ca>



On Wed, Oct 3, 2012 at 4:11 AM, Jos=E9 =
Eduardo Fran=E7a <jefranca@gmail.com> wrote:



>

> I thought remus used xc_domain_save. Is this function used from live
> migration?

>

> Futhermore I have two doubts if really Remus takes the last iteration =
of

> live migration

>

> What's the function?




There is no specific function. xc_domain_save is where everything

happens. The infinite loop

that basically keeps sending checkpoints @ a particular frequency






> And how to get de I/O disk size on each period?

>




This depends on the disk backend. With blktap2 (unfortunately not

available in 3.* kernels)

tap-remus driver can give you the number of disk blocks sent per checkpoint=
.



With DRBD, it needs a little bit of hacking into the kernel module to

return the number of disk blocks

being sent with each checkpoint.






>> I'm doing my master research and I need to adapt remus code. N=
ow... I

>> wanna get the checkpoint size (memory + disk) on each period. Does=
 someone

>> know what function does this? I think some fd object's functio=
n in remus

>> code could just get the memory size.

>>




You can get memory checkpoint stats for each iteration - like

number of pages dirtied, size of data actually transmitted after

compression (including headers, etc),

time to checkpoint, etc.



The attached patch (for xen-4.1.2) will give you the memory checkpoint

stats for each checkpoint and

can be easily parsed.



shriram








--bcaec501655751d1f504ccd188ee--
--bcaec501655751d1f904ccd188f0
Content-Type: image/png; name="dynamic-checkpoint.png"
Content-Disposition: attachment; filename="dynamic-checkpoint.png"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h8ee33pe1

iVBORw0KGgoAAAANSUhEUgAAA2EAAAHoCAIAAABPTnBRAAAAA3NCSVQICAjb4U/gAAAACXBIWXMA
AA7EAAAOxAGVKw4bAAAgAElEQVR4nOzdd1RTSRcA8JvQu3SkKIJYUUQQ1gIWBBuISnMV7GL57GXB
svaCit3Fhm3tgAUV0RWwUFRUxN4QRBGR3kvq9weKkVCTkPeS3N/Zs8c8Xl6uzMzzZmbeDIXNZgNC
CCGEEEIcqEQHgBBCCCGESAdzRIQQQgghVBvmiAghhBBCqDbMERFCCCGEUG2YIyKEEEIIodowR/wh
KSkpNzeX6CgQQgghhEiBgmvfAACTyZSWltbR0fn+/TvRsSCEEEIIEQ/7EQEAwsLCAKC0tLSiooLo
WBBCCCGEiIc5IgDA7t27AcDAwCAyMpLoWBBCCCGEiIc5IjCZzMePHwMAjUYLDQ0lOhyEEEIIIeJJ
Ex0A8cLCwuh0OgCkp6cXFBRUVFQoKCgQHRRCCCGEEJGwH/HHQHM1XV1dHG5GCCGEEJL0HLFmoLka
DjcjhBBCCAGONdcMNFfD4WaEEEIIIcB+RM6B5mo43IwQQgghJNE5Yq2B5mo43IwQQgghJNFjzbUG
mqvhcDNCCCGEkET3I3IPNFfD4WaEEEIISTjJzRHrHGiuhsPNCCGEEJJwkjvWXOdAczUcbkYIIYSQ
hJPcfsT6Bpqr4XAzQgghhCSZhOaIDQw0V8PhZoQQQghJMgkda25goLkaDjcjhBBCSJJJaD9iwwPN
1XC4GSGEEEISSxJzxEYHmqvhcDNCCCGEJJYkjjVTqdSGB5qrpaenN+U0hBBCCCHxI4n9iBQKhc1B
VVW15kf29vazZs2q+dHXr18JjBMhhBBCiCiSmCMihBBCCKGGYY6IEEIIIYRqwxwRIYQQQgjVhjki
QgghhBCqDXNEhBBCCCFUG+aICCGEEEKoNswREUIIIYRQbZgjIoQQQgih2jBHRAghhBBCtWGOiBBC
CCGEasMcESGEEEII1YY5IkIIIYQQqg1zRIQQQgghVBvmiAghhBBCqDbMERFCCCGEUG2YIyKEEEII
odowR0QIIYQQQrVhjogQQgghhGrDHBEhhBBCCNWGOSJCCCGEEKoNc0SEEEIIIVQb5ogIIYQQQqg2
zBERQgghhFBt0kQHgEQcu+LtkZnTT6QCAIDF+oh9A1QJjggJABarCMHCQlgHUMvAfkTED1bxk6AV
P25MAEChUOo9lfE1ZLKdnZ2d3cSzGQyhBId4hcUqQrCwENYB1FIwR0S8Y+Xe2bbqcjbHkfrvTfSM
W+EpAABdxgxsjd3XZIbFKkKwsBDWAdRyMEdEvKJnhK/beKcEQMdpfE85AACgUOu7N9E+XY/4DADS
Pd366UgJLUbUbFisIgQLC2EdQC0Jc0TEm8oPp//e8ZQG0NZ7/UwLeRZAQ99eK99fuZkFAPI27rYa
WOnIC4tVhGBhIawDqGVhZzPiAask6cDyIykA1M6z1k/uoviIzgSocxoMI+PstD+DPv58WZmw3Nn+
10/b+p465tNWRhgho8ZhsYoQLCyEdQC1OPwqgZqNlR+7fdWFLAA5q8VrPNvJAotBZwFAHdWJ/vm/
Kx+5LvBTh9EOhnhjIgssVhGChYWwDiAhwH5E1Ez0zGvr10cXASj3X7bSWV8agM2s/vpax/dXGZMp
Z++OilrsvvYxHXQ8g8/M7Sgn/JBR47BYRQgWFsI6gIQC+xFRs1R9PPv39sdVAFrOa5YO1KICALCZ
9OpFFOpccoGVm3DhCR0ADIePMMEbEzlhsYoQLCyEdQAJCeaIqOnYZc8OLj/8ngVgOHb9HBu1n7WH
WVX9/RXquDUxvt25+JINACYjh7TBAQ0ywmIVIVhYCOsAEh7MEVFTsfLjd6wMzQSgmE1bP9VcqeZG
1MAYB9AzboV/AADoMhqX4yIlLFYRgoWFsA4gYcIcETUNI+v6xrX/FQLIWMxfN669PMeP2Az6z++v
te9NP5fjkurpZofLcZEQFqsIwcJCWAeQcGGOiJqiKvX8qm2JlQCKff1Xj6r1EBybSfvx/bX20q0/
l+OSs3HD5bhICItVhGBhIawDSNiwvqBGscteHFlx4A0LQH3IKr/B2lzfQ2vuTbVmwpS9uhSdDwBK
/dx7qta/gygiBBarCMHCQlgHEAEwR0SNYBXe373ybAYA6LmtW9BHnbvKcDxP99vh4uQLsSUA0Grg
6G7KeGsiFyxWEYKFhbAOIEJgjogaxPx+c9PayHwAMJm0YaZFnbeYmrnSwDnGwSp4dOFBBQBoO47s
pCCEUFHTYbGKECwshHUAEQRzRNQA2qfQ1VvulwNIm89dN6GjfN1fQmvmwXAOcbAKH19JogOA7uCh
prgcF6lgsYoQLCyEdQARBnNEVB92+atjK/95xQSQt126ekwD23kyfs2Vrrk5Vby//YoJAAqdbQxl
WzxW1GRYrCIECwthHUBEwpWSUN1YRYl7V55KBwDQ7mdFeRZ981l9p9JS08sA4Lfn6ZiF6ZlVAAAV
b29FPVLupqskTQGgyGm01lHCtReIg8UqQrCwENYBRCzMEVFdmDlRAauv5Va/yIkK2hTVlHdxDIFQ
lfS0ZSCVDpB1fdui6z+OarkdPLugC8e9ifZh//gpV7rtCFvVS0lAoaP6YbGKEPIVFiMn4czxiMQX
r16n5dGhre/pYz64ZUeLIlcdoGXdv3Tu6u37T99klrJAXrtz31FTZ/9pq4N1QJzhWDPiRv98cU1A
XFnz3/irOlFa9fXfPM2hi54SRxXTG+psxrnoK9AzH7+TM3f16IaZhBBgsYoQAguLWVlWVsFgc1+a
8S02POp1iVqXPl0Umx8Yai6i6kA9FYCZn3A46GqaQo/RMxf7LZnt2r4g+vAS3233i1jNjxCJDAqb
Xce9QKKoqakVFxdX/9ne3r5r165BQUHEhoQQQsQoT1w+cknhsqv/OKjVfjaCzWJTqBRgfD0/dew+
JvYjiqf6KgC7Mie9WKWtzs9HZlj50cu81iSY+F3c76yNvU3iCksWEYVdHL/CyW7csTQ60ZEgAcJi
FSHNLCyuDTyQ6GtyHaDIaxvrcDxTTVXr0ssQoPBbCbOBdyERhzkiIgir4NGF+xWmro5G2BUhRrBY
RQgWFuK9DrCK3yZ+Adm2HTXxsQYxhoWLiMHKS7jwhNl18QB9rINiBItVhNQUVmsoLyqk/Zh1VFFK
Y7EZZYWFhezqPiOKjJKKkgx2J4ilH3Vgoa1SaWFh9aGmVQBWQULQrvtVRt6TbbjmJCAxgjdyRAhm
1p2LL6R6rOqHE1nECRarCPlVWJVPlo1ekvDbWOM275Hbfv6587LLB4ZrYomKoR91wE85yM3lftMr
ALv8zUn/VTfKe87bPanzb4+/IHGDOSIiAj3jVvgHeZtNNnVsO4pEFharCOEoLIVO0wO3j6FXdyRW
vj2yKrjszzVzLX/s+Cal2l4Vy1Ms/awDfa1b6293a2IFYFeknPefF/y+/eR9m9yNce8WMYc5IiIA
7dP1a+nK/eb1xFEKcYLFKkJ+Kyy19j1t2v/4QTklXIYibWZta4vFKOZq6oB6KyX1plUAdmXqhRX/
++eZ/rhdgZO6KmENEXv49RAJX+X7Kzey1AeO7o7r54kTLFYRgoWFml8HqtLDV83e/UjLbdvuGZbY
uSwRsB8RCV3Zq0vR+TrDXTviRBZxgsUqQngrLHpOcvyzXAYr/10RAOtDQkzUeylpjW59e+ric9Gi
p7l1gJUfu2Xu9vtl+kOmdC5+HPNjyxeKvKF1n05qmC+KK8wRkZCxi5MvxJYYjh1hgjNZxAgWqwjh
tbAqXgX/vbZmv+Db/2y4DQDmf18JclLHQUcR0/w6wCx487IAADJv7t1w89dhlaH7Lq6wwC+G4gpz
RCRczO8xpxIYPf1c2mLXgxjBYhUhDReWos2mqHt1v1F1wL7Y2BYNDQlJA3WgvgogY+obEusrhNgQ
mWCOiISFVZz64tXre8f2ve8w+dAgXBxFTGCxihAsLIR1ADUH5ohISCpe7F845zq7w8CpOxZ6meKA
pJjAYhUhWFgI6wBqFgqbzSY6BoKpqakVFxdX/9ne3r5r165BQUHEhoQQQgghRCzsaEYIIYQQQrVh
jogQQgghhGrDHBEJQFVV1eDBg4mOAgnY3r17Q0NDiY4CNcm3b9+8vLyIjgIR6dy5c7t27SI6CiRW
cD4izkcUgJSUFDMzs5ycHC0tLaJjQQJDoVCMjIw+f/5MdCCocXfv3h0wYADezyWZoaHh169fsQ4g
AcJ+RCQAHz58AICPHz8SHQgSMBqNRnQIqEmys7MBIC8vj+hAEGHKy8uJDgGJG8wRkQDEx8fX/B+J
h8LCQgAoLy9nMplEx4Ia9+TJk5r/IwmUkpKioKDQsWPHe/fqWQIdoebDHBHxi81mnz17duvWrWfO
nCE6FiQwFy5ccHd379y5c0xMDNGxoMZdv3591KhRERERRAeCiLF582ZfX18/P7/169cTHQsSH5gj
In5duXJFRUVl8eLFeXl5d+/eJTocJABMJnP79u3Tp0/39fXdsmUL0eGgRjx//jwvL2/Tpk1hYWE4
PUAC3blz5+bNm/PmzfP29s7IyDh37hzRESExgTki4ktVVdXSpUu3bt1KpVK3bt26YMECHJoUA4cO
HdLT03NycpowYcLXr1+xd4rkNm3atGDBgs6dO1taWh49epTocJBQff78+c8//zxx4oS6urqMjExI
SMi8efOePn1KdFxIHGCOiPji5+fXs2dPJycnAPDw8NDR0cGRDlGXkpKydu3aPXv2AICMjMzevXvn
zJmTk5NDdFyobg8ePLh3797s2bMBYNWqVRs3bqyeS4okQVpamqOj4/Llyx0cHKqPdOvWbf/+/S4u
LsnJycTGhsQA5oiIdwcPHoyIiNi7d2/NkSNHjhw9ehQX1RNdBQUFw4YNW716tbm5efWRwYMHjx07
duTIkTiISUKlpaU+Pj779u1TUlICABsbm1GjRs2aNYvouJAwJCYm2tnZzZ07d+7cuZzH3dzcdu3a
NWTIkMjISKJiQ+IBc0TEo+Dg4A0bNkRGRmpra9ccNDQ0jIiImDt37vnz5wmMDfEmMzNz0KBBf/75
Z60kY9OmTV26dBk6dGhRURFRsSFuNBrN3d3dyclpzJgxNQe3bdv2/v37TZs2ERgYamk0Gm3dunXD
hg07cODAnDlzuE9wd3cPDw+fPHnyggULSkpKhB8hEg+YI6Jmo9Foc+bMCQwMjImJad++fa2fduvW
7b///lu2bNmKFSsYDAYhESIeJCQk2Nraenl5rVu3rtaPKBTKwYMHu3Xr1rt379evXxMSHqqloqLC
1dVVWVl5586dnMfl5eWvXr164sSJjRs3EhUbajlsNvvSpUvdunVLTk5OTk52dnau78w//vjj1atX
ZWVlnTt3Pn78ON6NEQ8wR0TNwGazL1682LVr19zc3AcPHpiZmdV5Wvfu3R88ePDixQsLCwsc7CC/
r1+/Tp061d3d/dChQ/7+/nWeIy0tvXv3bj8/v/79+y9ZsqSgoEDIQSJODx486Nmzp5GR0ZkzZ2Rl
ZWv9VF9f//bt2xEREc7OzpmZmYREiASuoKBgz549nTp12rx5886dOy9evGhkZNTwWzQ1NQ8fPnz+
/PlTp061a9du06ZNWVlZwokWiQfciw/34msEnU7PyMj48OHD7du3z58/r6WltXXr1gEDBjTlvTdu
3Pjrr7+qqqq8vLz69+/fvn17AwMDaWnpFg4ZNS4vL+/Lly+JiYnh4eEPHjyYNWuWv7+/srJyo2/M
zc1ds2bN6dOnBw8e7OLiUp2pqKmpCSFmCUen0z99+pSYmHjy5Mnnz5/v3r3bw8Oj4fM3bNiwZ8+e
MWPGuLm5de/e3cDAgEKhCC1gxA86nZ6Tk/P9+/f09PTExMSYmJg3b94MHz587ty5ffr04eGCz58/
37dvX1hYWJs2bQYNGtSnTx9jY2M9PT1tbW05OTmBx4/EA+aIxOSITCYzOjr64sWLSUlJnz9/Ligo
IO0DAfLy8rq6uu3bt7e1tfX09LSwsGjuFR4/fhwaGvrgwYO0tLTc3NyKioqWiJN/0tLS2trabdu2
7dWrl5ubm52dHZXavI72L1++nD9/PiYmJiUl5du3b6WlpS0UKp9kZGSUlZWNjIwsLCyGDx/u4uJS
/cRD0xUUFFy6dCkyMvLNmzdZWVlk3gJOVVXVwMCgQ4cOTk5Onp6ezdpS/NOnT8eOHYuMjPz48WNR
URHh6zqZmpp2797dzc3N3d29if+u5+TkHDt27NatWy9fviRDH5KRkVHXrl2HDx8+YcIE3r5a5OXl
3b59+969e8+ePavOovLz8wUeJxno6+tX35EsLS0HDBjQu3dv/pM5BoPx+PHj27dvP3r06PPnz9+/
f8/IyBBItGSjqqraunVrHR2dTp062dvbDxo0SF9fn+igRA/miMLOEVks1vHjx1evXq2vr+/u7m5v
b9+mTZvWrVu33CeiJmKz2d++fUtNTY2NjQ0JCSkuLt6wYcPYsWOb0vWSkpLy999/37hxw93dfcSI
EZ07d27btq28vLwQwkYNKysr+/Tp04sXL65evXrt2rU///xz9erVjba4kpKS5cuXnzx5ctq0acOH
D+/evXuzkktUJxaL9eXLl+Tk5HPnzt26dWvlypXz589vYtcmnU4PDQ09cODA8+fP7ezsHBwcunbt
amBgoKOjg0WDuBUWFmZlZeXk5Dx9+jQ2Nvb27dtt27b19fX19vZu7ldiicaWeKqqqjW/DXt7+1mz
ZrXcZ7169crGxsbe3v7x48ct9ylIIOLj462trfv375+amtrAaQwGY/369VpaWoGBgRUVFUILD/Gg
qKhoxYoVGhoaBw8ebOC0N2/edOjQYdq0aYWFhUKLTdJ8+PChb9++Q4cObfSXXFVVtXPnTn19fQcH
h0uXLtHpdOFEiMQJk8mMiooaPXq0lpbWqlWrSkpKiI5INGCOKLwc8ebNmzo6Ov/88w+LxWqhj0CC
xWQyt27dqqenFxsbW+cJJSUlLi4u9vb2GRkZQo4N8ez169cWFhbTpk2j0WjcP3358qWent6xY8eE
HpfEYTAYs2bN6tWrVwNpYmxsrLm5+dChQ58/fy7M2JC4SktL8/b2btOmzeXLl4mORQTwO9bMKHgX
H3Pv0YvUb/lF5VJd/rd5jvmP4TVW+feM7AoWRVZdv7WaDInnSQtnrPnq1aszZswICQnp16+fwC+O
WtR///03fvz48+fPDxo0iPN4eXm5k5NTx44dDxw4ICMjQ1R4iAelpaXu7u4qKirnzp2TkpKqOf79
+3crK6sdO3Z4enoSGJ5EmTt37qtXr27dusVZEADAZrPXrVt36NCh3bt3u7u7ExUeEkv37t2bMmVK
//79g4KC8JGdBvCRI7KKnp3euPbQfY4tuiw339jT78dAPzPr8hyv7S9Z1O7+YXtHaJN3kR0h5IhP
nz51cnK6fv16r169BHtlJBwxMTFjx46Nj4+vWe6HzWZ7eHjIy8ufOnWK2NgQb2g02rBhw7p3716z
viCbzR45cqSFhcWGDRuIjU2isFgsJyengQMHrlixouZgVVXV5MmTP3/+HB4erqmpSWB4SFxVVlb6
+Pjk5ORcvHhRQ0OD6HBIitfUjVWStHfmnJ8JopIG9+NpUrqDJw1UAmA9v/Iwj8VHiKKuvLzcw8Pj
0KFDmCCKrkGDBgUEBHh4eNDp9OojQUFBmZmZR48eJTYwxDNZWdmLFy9GRESEh4dXHwkJCcnIyFi9
ejWxgUkaKpV64sSJPXv2vH//vvoIk8n08PCoqKiIiorCBBG1EHl5+fPnz1tbWzs5OeFWNPXhMUes
eHV4fVgGAKja+O68GBN5xt+S6xyKsrlLbyUA+HDnbakEPzwdEBBga2s7evRoogNBfJkyZYqhoeGe
PXsAICsra+3atSdOnOBevhiJEDU1tSNHjsyfP7+8vJzFYq1ZsyYwMBCnDQifgYHBvHnzarpvV65c
WVFRERYWhisDoBZFpVIDAwN79uw5efJkPufdiSueckR2cdKZyFwAMPTZsdHHWru+2YaKpv3MqAD0
9NfZkroJUFZW1t69e7du3Up0IEgAdu7cGRAQUFRUtGnTJm9v7/q2mZEIrOLH28fY2dl5n/rM0bjZ
5R+uHTtxK4Oka33Wwc7OzsrK6sCBAxERESoqKg4ODkRHJKHmzJlz7dq1jIyM6OjoU6dOnT17ttb0
RIRayL59+9LT0w8cOEB0IGTE044XVRkPX1cCQJfxo80a+ppHkddt2wqS8wu/FNABJPLL+enTp93c
3AwMDIgOBAmAmZnZgAEDzp49e+rUKcnetpiVH7dz3eVcAJCW4/iKyCq4f2DnSYbfSB/iQmu+5cuX
jx071sbGZsqUKUTHIrnU1NTGjBlz4cKF48eP//PPP7jkIRIaWVnZkydP9u/f38fHpyl7TUkUnvoR
mYVfiwBA3cxYpeH3U2UVpAGAVkaT1E7ckJCQcePGER0FEphx48YdOHDA2tpaT0+P6FgIw8z+L2BT
XJup0zsDSMtJ1+SIrLyEC0nUXu62GuR9RK0OVlZWUlJSERERw4cPJzoWiebs7Hz69Gk2m+3i4kJ0
LEiydOrUaeDAgTi/nBtv9/LqhfHZjT6JwijJLgUAWUVZEq9903IqKyuTkpKauLUxEgmOjo4vX74c
OHAg0YEQh55xed325+YLVwxVZwPIyEtRAACYWZd8+4/Z8oJRmbDc2d7Orv+cyBzReVTNysqKQqG0
adOG6EAkmo2NzcuXL8ePH4+bSiPh8/HxuXz5MtFRkA5PY83SrQxbwcPcwrSMcpa5fP1pZlV6/Ity
ANAy1ZLIgeb09HRjY+Pm7vmLyExZWVlKSkpHR4foQIhS9fHsqn9SbVf8O1S7KpQGIPejH5Gq0W/a
mJOLoy037JtqJgtUGVUtEi94VZumpqaCggLRUUg6PT29yspKKysrogNBksjGxubZs2dER0E6POWI
soa2neUvxFa+Do/NdnTVq2diMSPrv4PhOQCgbtmrtUTmiEpKSv7+/kRHgQTM09PT0pL7OX5JwC5/
eeTvI7kDN24fqEVlppXRgCorU93+KVD4JCFHZ4jnH8b6orcgraOjI36XIxyVSnV2du7UqRPRgSBJ
pK2tvWDBAjqdjisbcOLptkhRsfBy1ABgvdy3+WJqZR1zDdkVaZEBc7c+oQGA4Ui3jpK5gIGhoSGT
ySQ6CiRgdnZ2PXv2JDoKArCKnwStOlc54u/5fdSpACxaWdWv6YiV76/cyDIcPsKEgAQxKQk0NCAp
ifcruLi49O3bV3ARIR45Ozvr6+sTHQWSULq6upgg1sLjV2fFbtOWOLUCqEzaM3H8kl1n/3ueDwBQ
+uXlo7vXTu5aNsl1wqabWQAAemOWjjWR3DXkZsyYQXQISMAktExZ+XE71oRLu6/+n7UqFQCATSun
gcyPHLHs1aWYApORQ9oQcYMNDoaCAggO5usiuPkeGUho40LkgNWPG09jzQBA1ei3dO/iivnbY/Oz
Ey8EJVYf/RC0ZBHnWZoDl+38X09lCZ5/rK6uTnQISMAkskyZ328GbIxp5X1wenelH+2ZTSujgbSc
FAWAXZx8Iba08/8Gtub1hsIXRcVf/0ciTSIbFyILrH7ceL+lU+SNR2043fXm0aCjlx5nca2RrWkx
etqc6cM7NbI6jrjLz88nOgQkYBJYpvQvl9YFPtSfcmRSZ4VfK93QymggJScDwC5+Fp5Y1WVRHx1i
Fj0ODARtbfDz4+siuMsCGUhg40LkgdWPG39f+6nKZsPm7Rw2q+jzm5dvP33LK6lkSSmo67Y169bN
VEtOsrNDhMREZcqZ1Xuey/Sarv8l4faXmsMVL78xQVpOmgq0zKSUKqpuzvtXr3Ll1dua6itWt31W
TsTS9WWLdngacNxnKl7sW7Tu+ptsremnjo43ElS/I58JIkIIkUDFs61ec64WAGi5HTy7oAvxj3II
5BYto9ame9823QVxKXFjbW39+PFjoqNAgiRZZcouf3n07+APbIDEw+sTuX5sICdNARk9m35mkZeC
/WcHUy2Wh+3R/zHqS9Uetm0Xlcr8fDMk09rtD00pAAA5E68NR0beWrKeZE9zeXp6hoSEEB2FpJOs
xoVIhvjqV/bi0u0CAIDWw5wb3MVOaAiZPiRBnjx5QnQISMAkq0wpiuazz8bObvgk9d6Ljt5YVOsg
/dOJBQcN1m8crJCblPC+4+gfOSJVSVuT8ZV8c5RDQ0OJDgFJWONCJEN09WMXJV2ILwUAMB45tC05
HrDmKUekpUeeikynUZXaD3ZzMFGs/3bPrkiJOBOVQWk7zHtYW4l8uNkPx8DEDpZpk9DSbjzQGhGg
ToVKIXxaaiqYmPB1BV9fXwHFgniHjQsRiODqx8p/GJZYCQDQcZSDATlSRN5yRPqXyGOnnwIAnLqZ
vDZw/kC9ev427IoPV4+ffg2W5l4SmiMGBAQQHQISMCzTpqh8d+1pa7PCFdOPV7JKP6eVvZp5T15K
o9/S9ZPMBL6C4pkzMH48nD4N/GyNfvDgQcFFhHiEjQsRiNjqx8qJu/CUAQBUCzd7XWKe/+PG53Ml
7PTwVT4LjiQVis7OrMJFdN81ErwmlimN1tKBkFnZi6vvOo1x998XHBz8z18DLTw2HAgOPrS1mQki
kwlNWYQ+Lu7X/3lWUFDA1/uRIOANExGI0OrHyIy59JoNALK93P7QJM0jv/wEotq1kyoAVD4/Pn/i
yosfynHpCG7W1tZEh4AErOEyraiALVugfXuQk4Pt24UWFLmwi5KufrYc0aGuOdf0tJCVc1ece/c+
5O+5K0PS6A1d57//QFoa+vaF8HBg1f89tHrXG573vmGz2dnZ2RoaGjy+HwkO3jARgYisfvTP/135
CACg2MfNuhVpUkS+nlnRd16/acrlFctOv6Hlx+6c6vtxzbYFgyRzZ2Yk6VgsOH8eAgPh2TNgMqF6
OzEfH6LDIgYzO/Zq0cC5P/dXUui5bNev/E2mneeG/U3c0sTREaSkICEBRo8GOTlwdISVK8HGpvZp
06aBpb3bKLwAACAASURBVCVYWTV+wQ8fPty4ceP+/ftpaWlpaWmFhYVVVVVNiwUhhFpKVWpERAYA
gFr/MRYqJHqmj7/nmqU0bWbuO2ESuHR9ZAY7/crqCampWzZN6alOnhyYaB8/fiQ6BCRgtco0NhY2
bIA7d34bXO7ZExwcQEdH2LERj5UX909geEmf+YsM+V80QVoaxo+Hf/8FNhsqK+HqVYiIAFVVcHOD
lSvB2PjXmfUliCUlJWFhYZcvX05KSvr27Vut/dMVFRUBQEpKCvdVJwm8YSICEVf9Kt6G38oGANAa
PKozqXaM4v82Lmvo5B/cpv3aJXvvF1W+PDF/0scFgSvHmCmRKBEmkAmfD1si8uEs0+xssLev45zS
UtDXB4okNgJNgM0AELhCMJdzdv7tJYsFsrJw7hwcOQKJidCrVx1vYTAYly9fPn78+IMHD/Ly8uq8
rIyMDJ1OV1BQLi8vB5ACwByRFPCGiQhEWPUj37KINQTS40dV6uS5+d/t3l3kACA/btdU363RmRI9
Y7+Gv78/0SEgAeMsU01NOHkSRo4EZWXo2BFqprQVFYG8PLDZ+B+//8n/vGGqqYGzMzg7A5MJNjZw
+DB06fJbuZSUlAQEBHTr1k1eXt7DwyMiIqK+BBEA5OTkqosJANhsnCBDFnjDRAQiqPqRcVnEGgIb
FZbSsJmx9/iqEYYAwP58bc3E+YcfFzAl/jGWLVu2EB0CEjDOMpWSAm9vCA+H9HRYsAA6dwY1NejU
CVJS4OJFoDf4QAZqFI0GN26AmRmMGQOqqvD5M9jbQ3IyxMTAtGmgpAQAUFFRsX37dj29Va1atVq2
bNnLly+5B46p1N9udCoqKkpKStLSsgxGawBgscqE9RdCjcAbJiIQMdWPlMsi1hDozEFZQ8e/goPn
9WkFAJUv/104cUXYewm/+w4ePJjoEJCA1VmmGhowcybExUFyMvj4gKEhZGTApk3Cj06s3LkDpaVQ
UADt20NEBDx7BkuXgqHhj59GRETY2tqqqKgsWVL+/fs6KamN9V1HUVGxVatWI0eOHDp0qIWFBZvN
zsnJYbE6A/Ts23fX4cOHr1y5Ysw5vRERBG+YiECEVD9yLotYQ9B78VGVOnpsOmF8ZPmyk6+qCu6f
ChPw9UXNrVu3iA4BCVjDZWpsDMuXw/LlEB8PuI4Hn5yc4M4dsLMDzn7AwsLC1atXHz9+vLi4+Ocx
LQBgMFpxvldRUdHa2lpTU7OoqCgmJkZBQUFFRaVXr15WVlbdunWbPVvtzBlQVobbt0FGBgDAxcVF
SH8rVD+8YSICEVH9SLosYo2W2K9ZSqOX754TJjuXrr32pQUuj5Ao6NuX6AjEQv/+v/785MmThQsX
xsfHs+paLJHNZktLSysoKAwcOJBKpSYnJ3/+/NnMzMzNze3UqVOtW7euOfPNGzh3DigUOH36R4KI
EEIEIOuyiDV4yhFljV1nT7cGvS7K9T63KWsweOnhNu0DAy+9L2MrGCmT8K8uFBoaGvn5+URHgQQJ
y1T4Ll++/Ndff3348KGBc9q1a/fpE7OkpCQrK8vV1XX9+vXm5uZ1njliBLBY0LMnjBz566CpqSku
vEI4bFyIQMKvfqRdFrEGTzmijKHDnxMaPYuq1MFt9SE3Xj5AfOAGX+IHy1Ro2Gz2yZMn/f39v337
VucJcnJyAwcOfP/eJDUVSktLd+zYMXbsWD09vQaueekSpKcDlQoREb8dT01NFWDkiDfYuBCBhF79
yLssYo2WGGtGv4SEhBAdAhKwgwcPEh2CRDh27Nhff/2Vm5tb5087dOhgbW397t27V69e6eioA4C7
u/uCBY1ftndvMDUFf3+olUkGBAQIIGjEH2xciEDCrn4kXhaxBoXNlvT1adTU1Gomv9vb23ft2jUo
KIjYkBCSZNeuXZsxY0ZmZib3j6hUav/+/bW1te/cuWNpafm///1v+PDhc+dK7d8Ps2ZBExsuiwVU
SZ39ghAiB3ZRrL/78oRKAHlLn1mD9erusaPKG/V2sNQk7HnnJvQjsiq+f/lewQagSKvoGmjKU34d
aSKKgq6RroJE3pRDQ0M9PDyIjgIJEpZpy0lKSho/fvzbt2+5fyQrKztixAgajfbgwYNJkybFx8e3
b9+et0+pM0GMiorChVcIh40LEUio1e/XsohQ+fTkzqf1nCZtteoCkfelJuSIFU82ei97CgCg7LT3
4t89FDiONJHl5ht7+inxGKJI8/T0xJ5aMYNl2hKys7O9vb3rXHtCUVHRxcUlPz//4cOHCxcuPHv2
rIqKisADcHR0xGIlHDYuRCBhVr+aZREbJv+Hu406kR1sOB8RIUQkBoOxevXqrVu3Mhi175jy8vIu
Li5ZWVmJiYlLly69cuWKvDyPs3bu3YO9e+HsWZDGex5CiGhUXdeD91yb8w5W3s0F7huKJwaMq7x2
+tr91CJmK4vJm7dMMs25feLgv9fupxYx1XtMCQiY1EWp+gFpembMseDw+OQ3qTkVAHK6Fi5z/p49
QFcGWLmR89w2vbZee2HbIHUqALvs7bkVCw5k2q/as9RB7/flwJpwv5Tr6PP3sqEMAIp8mzayvx1p
ImntjnLN+E2IE/xOLH6wTAXo7t27Hh4eOTk5ACAnJ0ej0ap/vdLS0q6urqWlpQ8fPly7dq23t7c0
H8ldcTE4OAAAXLoE9Q0l4ZIrZICNCxGI1NWPmR174SmDqnHzRLzD8An+Tjk3d/1z599dBzJl3tGt
hk/wH5JzY8c/d8+eezt2nZUCAAD925PnpQb2f9qP1VaVKnp/K/ifsC2H+v/xdw95qobtyB5Sz5Ku
PCkcMLhV0aMDi/3CwD3w0Mxe3Cs0NuG2K63dy2l4I0cQQqg5iouLx44dGxkZWXOkqqpKSkqKyWQO
HDhQU1MzNja2uu9QVla24Uv5+8PNm+DvX+8Jbm7AYIC2Nri713uOurp6s/8OCCEkFIxvty+9AaXe
07dtdDaUAYBy+Zijd+58zbUK/meYgQwAlMveOnL3ubLcz1UWZdq4LFhU8/4e7cqib+yuoLEAAKit
erlaySQ9CU94zXq2dmOswcygjWM7KdW1PqNEPkgiRI6OjkSHgAQMy5R/J0+e1NXV5UwQq+nq6gLA
s2fPTExM3r59u3jx4kYTRABo0wY+foQ2ber+aUICREcDhQLh4UCpf5HaGTNmND1+1EKwcSECkbj6
0T/fDE+VsV6wdLhh9VgwPTPpXYWszaIlQwyqD9C+PnlfqWBhZ1w9assqT7t9bMM8n1FOA+zs7Ozs
+o/Z+hZMbNtWT9ahtrIaaS3LTN4ya/3jLv7BW/+sO0GElskRmWVZae/fpWYW0UncbyskUVFRRIeA
BAzLlB9FRUX9+/efMGFCZWUl53FVVdUpU6bIysq6ubk9ffp0y5YtrVq1qu8iTcdmg6srsNng6Ai9
ezd05qFDh/j/OMQnbFyIQOStflUpERFflQeMs9Om/jxw/cY31YHj+/zc4rkyJeK/LBW7Ud2VKQCs
vNhtkydtiqX2Gue3bf/RE/8e3z7eCKjmI3v/fD+jokpWDgD0xm9dMcywgS/iPE7xYeYn/3c7pYza
ytxhUCfVmkSTXZkeuWPVjsjUKgAAoLa2m/m3v1c3VcntrfT19SU6BCRgWKY8u3jxoo+PT3l5ea3j
w4cPB4C4uLjg4GCH6pmDArJuHeTlgbQ0hIY2ciYuuUIG2LgQgUhb/SreXvkvR8NhdDelXwdu5Wg4
jOry80D5m8tRuRoOo82VAFj5d7etvybtHRw0raM8BQCg8vX16C8yVlP7aFEBgF2ZFr523s7nGjrU
kqzHz/OZZnr1L7/IW/ZG/xoRuGnX7t2n3oLcryuwS5/uXbD5Z4IIAKxvsUHz/ELT6Tx9iFjAbQPE
D5YpD6qqqtzd3d3c3GoliIaGhlOmTHn06JGtre3z588FmyDm5sL69cBmw5YtoKrayMm4JRIZYONC
BCJp9WOXvrh0u1B3yMiO8pwH9Ia5dPh5oOT5xXtFekNGdpAHYOUlnIuv6PznKLPqBJFV9OjA2vNZ
Cn+49VKnAqvkxYlFvrs+D9h4fN9f/ZXgXUTsd2YDH85Tjsgqfp2QDgDa/Qe3+/XAMjPr5v4ruQAA
un3+/N/Cud72+gDAeHn4n/gCFi8fIw5wE1jxg1vKNldycrKhoeGFCxc4D1IoFA8PD01NzS9fviQk
JKxatUpOjsflD96+BW1t4F5429UVmEzQ14dFi+p6GyIfbFyIQOSsfuziJ2FxZUbOw9vJ/jyQdCG+
rO3IYcY/DrCKki4klLV1HmEsCwDMku9FAAUfPxfRK/M/xp1YOXv1hUxQsXProcrKS9gze95p1tjd
+xf2025l7vKHEnyIiP3WwCo1POWI9Oy33wBApr21IWeKGHv1LQBQOi/Ys3H22DGeM9bvW24tA1CV
eCmpSFJnJpqamhIdAhIwDQ0NokMQJYGBgVZWVrW2XTYyMpo+ffrdu3fnz5//33//8bxjSrU9eyA3
F/bs+e1gVBTcvw8UCly/3qSLUBp4ngUJCzYuRCBSVj9W/oMLj6raj3L88bAKsPIfXkis7DDa4deB
B2GPaGauP86QaTNi8lDjwrAFIwe5TAu4ybAf17sVaDiMNiuIXD99WVTruQd3TbFQpQKAUheXvirw
MeJeA0kiT/MRGcVZJQDQylD912KLrKLXsWkAIGXpOfDHvoNUrb6jLWUeJ9I/JWdWOaiTdMdqhFCL
qKysdHZ2jo6OrnXc1dU1Ly/v7du3Dx8+NDY2bomPZjLB2xvYbBg9GiwsWuITEEJICKiaQ/bcHvLb
Aafdt504D2gN3Xtn6K/X0npDVpwcsoLjjKEjAADAfM3FYb9dW8nq7+uxfzf88TwFzahiAICUrPSv
b96Vn+I/sADAdKB5zSqMFHndduoAUJJd0tB4tzh7/Pgx0SEgAcMybYqUlBRjY+NaCaKqquqMGTMS
EhJGjhx5+/btFkoQAYDBAGtrMDGBU6ea+hacj0gG2LgQgbD6ceOpH5EipyQLUFmSXVqT+tG+PnhZ
BgC6PbtocOSdVCkqALAYkjrUDFZWVkSHgAQMy7RRISEh3t7edPpvT6tZWlq2bt36wYMH0dHR3bp1
a9EA5OTg6lUoKQFFxaa+BZ9rJgNsXIhAWP248dSPKKNtpgMAZS/uf6FVH6Glx9z+DgCKXWwMOFba
YRZnFQOAorpC/U9Wk8RNADbA3Xv3gvbvBwqFx//u3q112S1btjQjiOXLf12KSuXlPwoF1q3j6xdx
5Qrvn14Tw3D+tuHJyeE3BioVlJQa/6CGKSrWGcaWpscgLQ05OXzFYGwsgOJ4/ZqvGIYObVYMC6hU
Ly8vzgSRAjDOyamkpKRdu3YPHz7kJUFcs6ahGPbvBwDYv5/zIEWKqtrq999Dg42x8fURT5wQQFmM
Hdvsvzunt2/5bRdUKvDffSsjw28MFAoUF3NfuBk3TENDARTHx498/R769RNADA8e8BXDwoUCiOHo
Ub5iEEjTmDiRrxji4vj/V2NL69Z8xQAAUlIt+6sWOt5yRD3bP7QBIOv8xqDoD99zPz84vu1cFgAo
WA3pyPG9nZ7z+mM5AGi31+J9q1UhMeD/EgMGwI0btY75N7BBGLe0tF9/ZrN5+a9HD7h/n6+/RUYG
759e/Z+JCfD5NHf16sr8xMBmA9cifM1Go9UZhn/TY2jdGrKy+IqhehNhfn4PlpaQnMxXDF++NDGG
KjZ7IJu9+/c9T5UB5unp3YqPX7Nmzb59+3h8ePndu4ZiqNFAeNbW8PRpA5/Q+D4r1c2Tz6bx7Bkv
f/0ahYX8tgtlZX7rJAAwGPyGoa4OhYXcF27GDbM6xeQnBnPzOh6Gbxb+75a2tnDnDl8xvHkjgBgS
E/mKgf+m0aXLjzbOs+xsfmNQVvbnv2mwWC37qxY63nI3OTOPKVaXtzyhpV5YM+XXghaGYyZaqf6a
osjMe3w3HQDUOnUmf47YQoTddy0jA1JE99lKSUET9k8TAfU86NqMElVQaKEYmkFYMeQDWAOk/X6w
I4A1wPWiomhf327jx/MbCT9kZRtuGsLYr1lKCmRkGj+tRVEoIM/384MUCrD5m0BUT7Vsxg1TdJpG
y8bAPzk5oBK9z4W0NBmahlVL/+tJhl91M/EYrpTe8LXbJlkocxzSslu8eVJHjpsPPePW5XcAINvF
rh2P656JPpwDK36wRLm9AzDhShAdANQAygAeWVl109MjJrImy6/uskWEwhsmItBjZeXGT5IwPPfv
UdV6Tt17ZXRK8vO03CpZHTOL7ibqv30NYJUXqwyaOJEhrdvPUpn8K489B2gP8E5NTVFRkcfV2u7c
4XcenqUlnDsHdna8XyE1FTQ1+YqhekFHfmLIy4PMTL5iqH7QgJ8YACA2lq+3AwCDAd27g5oaXzHw
2aWqrQ2tWkHbtnzF4OfHVwwdO0JKCtjY1PfzO0VFQ168oP3eseSjo3OnqGh269Z+RkaU2FjgsxOx
4aaR0hq+AVuvdXy2HYsFHTuBjjbXOa9egQF/M0o6dwbgu2nwuUhvdevmJwYaDR4+5CsGAGCzoVcv
vvojY2NBmr/RJVVVATSNpj/TVKcOHSA/n6/Vle7cAS8vvmKwtoabN/mqEomJwOczZPw3jcxMoPO3
IZuhIb8xCKRpNBwD/79qoaOw+RwyEH1qamrFxcWyAJMAzMzM9PX1x40bx+O1uHZ7NDU1/disadFn
zkBpKY+fXs3dHfhcCPTGDfj8ma8rDBoE/K2KDHFx/D5p0aNHA2lNk7x+DXFx3IdNV6z4uHFjk67Q
vj0MGsRXDFlZcOUKX1fQ0AB3d76uUFoKZ87U98MziYk+R4+yOG4jstLSM+3tzz56dGLSpGHm5j+O
8r8R6vHjP2aIcpl9pt/+u11m9X892SwuNxeGDavzrEaahrW1deOdWFeu8DuZb+hQaNOGryvw3zRs
bKBHD76ukJzM77SqeppGM26Ynz9zz/9uHj09GDmSrys02DSaRFYWJk3i6wrQUNNoqnHjgM8utLAw
4LMnnv+mERMDKSn8XMB0/fqP1dOvedZo0+D/Vy1cmCP+yBGr/2xvb9+1a9egoCBBXZxCwd+wuMEy
rbF79+4FCxZwHlFXVx8/fvzly5evXLliaWkpnDD27IH582H3bpg3j/eLYLGSAZYCIhBWP26S+iyJ
sJB0j3DEh4CAAKJDIIXly5dv3rwZOG6sxsbGdnZ2d+7ciY+Pb8Nnl0BzzJsHrVsDn+sb+vE5Io8E
ARsXIhBWP26YNbdsPyJCYmnOnDn//PNP9Z+rc0Rzc3NDQ0M6nX7hwgU1fiZxNh+dTvwzkQghJH5E
7DFskRMVFUV0CEjAsEynTJlSkyACQPX3zLdv3+rp6V2/fl3ICeK7d9C2Lezbx+91Uvlc1BMJAjYu
RCCsftwwR2xZjo6ORIeABEzCy9Tb2/vYsWOcR6p/IcuWLTt69Kis0JfGdHGBb98gIoLf65hWP9GP
CCXhjQsRC6sfN5yPiBBqKi8vr5CQEM4jrq6ur1+/DggIIGQ+X1ERUKmgpASjRwv/wxFCSMxhP2LL
woV5xY/ElunYsWNrJYgeHh4vXryYPXs2UQ98qKnBvXuwYAHMmAF79vB1qeatUYVahsQ2LkQGWP24
YT9iyxLGBl9IuCSzTCdPnnz+/HnOI15eXg8ePPDz85s1axZRUQGAjs6Pddn43HrXxMREIPEgfkhm
40IkgdWPG/YjtixPT0+iQ0ACNmPGDKJDELaFCxceP36c88jYsWPj4+NXrFhBbIIoQP7+/kSHgCSx
cSHywOrHjacckZH3PPb27djneYxGTmSVf358t0lniqvQ0FCiQ0ACdujQIaJDEKr169fv2rWL84ib
m9u9e/c2btw4ffp0oqKKjoaKCkFecMuWLYK8HOKJpDUuRCpY/bjxlCNWvQlevmrV8uA3VY2cyMyO
2b6ySWeKKw8+F/ZF5CNRZRoUFLRq1SrOI2PGjImLi9u+ffuECROIimrHDhgyhN8toGsZPHiwIC+H
eCJRjQuRDVY/bjjW3LJqzfFHYkByyvTq1atz5szhPOLi4vLkyZMtW7aMHTuWqKiKi8HfH5hM6NVL
kJe9deuWIC+HeCI5jQuREFY/bi2cI7KYbACgSlNa9mMQQgL26NGj0aNHc+7DNHDgwLS0tP/9738T
J04kMDB3d6DTQVsbcAIhQgi1qJbNEWk5afkAoKCmIKn9lRQKpsfiRhLK9M2bN/369WMymTVHbG1t
S0tLnZ2dly5dSmBgCQkQFQUUCly+DIItBw0NDUFeDvFEEhoXIi2sftyavPYNqzI/O7+SBQAA5XmV
AACVed8yMxXrOZ1elpf+9GrQ3QoA0DdvLezNFxBCPCoqKrK1taXRaDVHzM3NFRUV27dvv2nTJgID
Y7PB1RXYbHB0hD59BHzxgoICAV8RIYREXJNzxIrHazyWPf3t0JvAyV5NeKdUd9e+OlLNDUxM4CQn
8SPeZUqj0aysrEpKSmqOGBoampqaUiiU/fv3E/s9e906yMsDaWkICxP8xQ8ePCj4i6JmEu/GhUgO
qx+3ll5DW6HD6BWrR+hJaoqID0uKIfEu0xEjRnDuOKKmptanT5/c3NzIyEgpKSLbcW4urF8PbDZs
2QKqqoK/vq+vr+AvippJvBsXIjmsftyanCPKtvdcPN++epnDqpTzByKyQG/ETK/2cnWeTaHKKKrp
GHXo2slIVaK3cjl06BD+2yNmxLhMFy1aFBUVVfNSVlbWy8srKSkpKipKVpbg+SKjRgGTCfr6sGhR
7R9NmwbHjsG0aXxdPzQ0FFe+IJwYNy5Eflj9uFE4n1tsqrK4eUOXPQXLzTf29FNqgaCES01Nrbi4
uPrP9vb2Xbt2DQoKEtTFKRSefsOIxMS1TM+cOTP+9yUH//e//125cuXhw4etW7cmKqpq0dHg6AgA
8PQpWFi0yEeIa7GKFiwFRCCsftx46uST7zZ3z84iUDOTF3Q4Ygc3gRU/Yrmn54sXL2qtaDN16tSQ
kJDr168TniACwKVLQKWCq2tLJYiIJMSycSFRgdWPG085opSamaW1oCMRT5xTu5B4yM/PJzoEASsq
KrKzs2Mwfu2YOXTo0JiYmL1791pbk6Klb9sG1tYwaVILfgT2H5CB+DUuJEKw+nHje7IgoyQz5UPq
15ziChqTVc9dVkbXdrCtrgy/H4UQEjg2m21vb19UVFRzxNzcvLi4ePz48V5eTVm4QBgUFFo2QUQI
IcSN9xyRVZ76X/Ce4ItPvjMbPddys72E5ojW1taPHz8mOgokSGJWpr6+vs+fP695qamp2aVLFxqN
tm7dOgKjapbcXBg+HK5fBy0t3i/i6emJO3ERTswaFxItWP248bj/CbvsxeHZkzaGNiVBlGhPnjwh
OgQkYOJUpqGhocHBwTUvpaSkPD0937x5c/r0aTJsOZCfD3l5jZ+2ahU8egSrVvH1WaGhoXy9HwmC
ODUuJHKw+nHjrR+R9vH0xlMf2QAA6hYjPUf07Wai10pBhlrPPyoUeW0FniMUbX5+fkSHgARMbMo0
IyPD29ub88jEiRMvXbr04MEDRcV6NlASIjodrKxAVhaio8HQsMU/Dte8IAOxaVxIFGH148bTk970
lIPjJp/KAtBz23VknpWqaG/G3KJr3yBETkwms3379p8+fao5MmTIkOTk5LCwsH79+hEX1y8zZ8LB
g6CsDLm5IFf3Oqw/lJeDpyeEhAAJMluEEBIfPKV3tJyUXACArpPGW4p4gtjSsO9a/IhHmU6ZMoUz
QTQzMysoKFi6dClJEsRPn+DwYQCAgwcbSRABQFERrl3jN0HE/ZrJQDwaFxJRWP248ZbhVU9VUtLX
V8YMsWEkWToECZAYlOnFixf//fffmpfy8vL9+vXT1tZexL2HCUGGDwcWCzp3hnHjhPSJGhoaQvok
VD8xaFxIdGH148bTfERZvS56cP9LRV4hjQ0KxM9sRwg1WXZ2dq39VKZPn3758uWkpCQyPKcCAKdP
w9u3QKXC9etEh4IQQhKMp35AGYNBI0wBWK8jnxSwBB2ReME1tMWPSJcpm812cHCorKysOeLq6hoW
Fnbq1CktflaOEZzKSpg+HdhsmD4djI2F97m45gUZiHTjQqIOqx833saKZYzclk0xo1beD9x2/UsV
bk9QP9yLT/yIdJkuW7bs5cuXNS9NTEwKCgpmzZplb29PYFScpk2DigpQVoa9e5v6lrg4oFAgLo6v
z7WysuLr/UgQRLpxIVGH1Y8bTzkim15epeu6Zr1nx6q4Ld6Tlu8Pj3v5KSs3v7AeRWV0Sc0jZ8yY
QXQISMD8/f2JDoFHSUlJO3bsqHkpLS3t4OAgLS29fPlyAqPi9PYtnD0LFAqcPg0yTV51/8yZX//n
2ZYtW/h6PxIE0W1cSAxg9ePG09o3ZXHzhi572ow3WG6+saefUrM/RzhadO0bCoWn3zAiMREtUzqd
bmRk9P37dwCQlZWl0WhTpkyJjIx88uRJ69atiY7uB1NTSE0FS0tISmrGuwICYNky2LwZ+LnDi2ix
ihksBUQgrH7c+N6vGTVo8ODBRIeABExEy3TGjBnVCSIA0Ol0aWnpEydOXL9+nTwJ4tOn8PUrSElB
RETz3ujvDxoawOca2DjMRAYi2riQeMDqx423NbQzosNivtKbfL6MwSB3B0Oy7teMa2gjsRcXF2dv
b1/T2FVUVEpKSpYsWbJt2zZiA6tl926wtATSzI1ECCGJhj2rmCMiMVdVVWVgYJDHsfPxzJkzY2Nj
nzx5Itfo+tQIIYQkFa6B3bJwYV7xI3JlOmPGDM4EcfDgweHh4UePHsUEkZOpqSnRISDRa1xInGD1
44Y5YsvCDb7Ej2iVaWJiIueWKhoaGkpKSj4+PjY2NgRGVUtpKb9XiIri9wqpqan8XgLxTbQaFxIz
WP24YY7YskJCQogOAQnYwYMHiQ6hqeh0uouLC+d8Em9v73fv3q1du5bAqGo5fhxat4bISN6vEBwM
ejKIawAAIABJREFUjo4QHMxXGAEBAXy9HwmCCDUuJH6w+nFrwnPNrIrvX75XsAEo0iq6BprylF9H
moiioGukqyCR6aiHhwfRISAB8+XzAVohWrBgQXZ2ds3LwYMHX7hwITQ0VF5ensCoOBUXg68vMBiQ
ns77RaoXymnWcjnc/Pz8+Ho/EgQRalxI/GD149aEHLHiyUbv6tUQlZ32Xvy7hwLHkSYi9fqILSo0
NBTTRDEjKmX65s2bAwcO1LxUVVVVVVX18vLq3bs3gVHV4u4OdDpoaQHhi81HRUXhyheEE5XGhcQS
Vj9uuD5iy/L09MQnx8WMqJSpi4sLi/VrP/Xx48dHRUWdOnWKwJBqSUiAqCigUCA8HCgUgoNxdHQU
iWIVb6LSuJBYwurHrQk5olxHn7+XDWUAUOTbtJH97UhTP0S7Iz5AiZAQ7dy5k3N/eltb26tXr549
e1ZBQYHAqDix2TBqFLDZ4OgIffoQHQ1CSPJkZWWNHz/ex8dn0qRJRMdCUk3IEaW1ezkNb+QIqgd+
KRE/5C/TwsJCzo1HZWRk9PT0/vjjj379+hEYVS3r10NuLkhLQ1gY0aEAAEB+fj7RISARaFxIJGRn
Zy9cuPDVq1dVVVWUegYpiouLMzMz2Wx2TEyMkZGRg4MDVj9uONaMkLiZMGECjUareTl27Ni7d++e
Pn2awJBqyc2FdeuAzYaAAFBVJToaAABQV1cnOgSEkABcu3bNw8OjsrKyiedLS0v7+Pi8e/dORUWl
RQMTRRL5sLEQOTo6Eh0CEjCSl2liYuLVq1drXpqYmDx9+jQwMFBJiURPjY0aBUwm6OvD4sVEh/LT
DMKfmkGkb1yI5JhM5uzZs11cXCorK2VlZRs9X1paGgAYDAaNRps/fz5WP2789yOy6YVpzx49fZ36
NaewjAaySq20DUy6WPayaNdKhuhp6MSL4n9tX0QyZC5TNpvt5eXFeWTw4MGpqamkelgvKgoSEoBC
gYgIokPhcOjQIVwdjXBkblyI5LKzswcMGPDmzZvql5xjKfVRUFAoKSkxNjbu0aPH2bNnm971KDn4
yhHpOYnn9uw5cSe9qo4fyhkPnDhv7the2jL8fISow/WWxA+Zy3Tnzp2fPn2qeTlkyJBLly7du3eP
uIjq8L//AQC4ukKPHkSHwoFUabTEInPjQmQWFxc3bNiw0rq2bOrRoweVWveQaXp6OgB8+vSpV69e
X758WbFiRctGKYIovE7SZFd8OOf/v6CkigbPUuw5e1/AWDMFMncoqqmpFRcXV//Z3t6+a9euQUFB
xIaEEA9KS0u1tbVrvgrLy8u7uroaGhoGBgYSG1gtN27AwYNw+jQoKgrmgrNnw/79MGsWYMNFSAIF
Bgb6+flxLvUFAEOHDk1OTq6qqurZs2d9j618+vRJWVl5+/btgwYNEkqkoofHfkRW0aNdS34kiNJG
fcaMcupt0cFIW0UOqkpyMz48v3/r8sW4dDqUJwUt2WX6r5+NmoROfExNTTUxMSE6CiRIBQUF5Hy+
YdasWZxjJRMnTrx69WrNyAt5DB0KQ4cK8oLTpsGxYzBtmiCviQhB2saFyInBYLi5uV25coXzoJyc
3OzZs8PCwmbMmLFq1ar6OhG5YfXjxls/Ij395BTvQ58AZDpPDAyY3FNDiusUZmHyv8sWH31JA2jn
e+qIT1vSDjm3aD8ihcJzTy0iKXKWaUpKSocOHWoCa9OmjZaW1rx58yZOnEhsYKKCnMUqabAUUNPl
5+fb2tqmpKRwHmzTpo2Hh8fp06ePHj06bNiwZl0Qqx83nrr3GN8Tbn0CAPk/lm2aUleCCABSrXpM
3LiirwIApN1K+N70BbcRQs3n4eHBeXcbOnSogoLChAkTCAypFrz3IoQE5cWLF8bGxrUSRDs7Oysr
q9u3byckJDQ3QUR14ilHpH179Q0A5K3H9NZq4AJUDdsxNgoA8O1VVuMPGImnx48fEx0CEjASlmlk
ZGRycnLNS1tb2ytXruzbt6++WTjCR6eDgwOsXEl0HPULCQkhOgRExsaFSCg0NLRnz54lJSWcBydN
mpSXl6ehoREfH9+uXTseLovVjxtPOSKbVkoDAGXdVo0MIMuo6akAAK2sSlK7EKysrIgOAQkY2cqU
zWZP45iLR6VS27VrN3r06B5kemx44UK4cwf274equhZBIAN8rpkMyNa4EAmtXbvWy8uLwfg1Oikn
Jzd37tzr168vWrQoODhYXl6etytj9ePGU45IVWilAABFX7IrG8z92FU5nwsBQEFNQUIfWYEtW7YQ
HQISMLKV6eHDhzMzM2teOjs7R0dHr1+/nsCQuCUlAZUKe/aAXAts3Z6bCzY2kJvL10UOHTokoHAQ
78jWuBCpsFgsNze3NWvWcM6r0dXV9fDwuHbt2vXr16dOncrP9bH6ceNphiYr65Kvx453QDVfcGav
m0F9z0YzvoUvGBf4jAEdF4UeGq1H1jQRn1lBzUKqMqXT6dra2kVFRdUv5eXl7ezsRowYMX/+fGID
q6WwEB4/hsGDW+TiAln7hlTFKrGwFFB9SktL//jjj1evXnEe7N69u7a2NpPJDAsL09TU5PMjsPpx
460fUbu3c1cqAOvlrsVbb36qqON3yq78Er1zSeAzBgC1q3NvbbImiC0N+67FD6nKdOPGjTUJIgC4
u7u/f/9+5syZBIZUp1atWipBFBRc84IMSNW4EHmkpaUZGxvXShCdnJyYTKaZmdmtW7f4TxABq19d
eFsfUUp3yLw/Q2ec/gxfIzf43Dvbb+igP7qZGWopywKtNO9ryouHt2/e+1A9nbTNn/OH6Nb56LMk
wDmw4oc8ZVpeXs45OKKpqZmWlrZmzRq5lhjQFXf5+flEh4BI1LgQeURHRw8fPrzW3nrjx4+PiYnx
9/efN2+eoD4Iqx83HtfQpih0mbp9Ve7cdTezAMo+xl34GHehrvP0hqzaPrUzqbdZQUhU+fv7cy6a
7ebmFhsb6+PjQ2BItbx+DUZGoKJCdBwIIdG0bds2Pz8/ziFgWVnZCRMmXL169dixY7jATUvjfQxY
Rs9x+Yl/V4/rbVRnn4WcUZ/xa/49sdxRj7SLZwuDqakp0SEgASNJmRYVFR04cKDmpZGRUWJi4rp1
66SkyNJr//YtWFvDoEFApxMdShNYW1sTHQIiS+NCZMBkMl1cXP766y/OBFFLS8vLyysmJiY6Olrg
CSJWP2489iNWoyq2Gzxr62Dfssz3L998zMgtrqCDjIKqlqFpZ/MO+kpk+aeKSKmpqUSHgASMJGU6
d+5cOkfy5ezs/OjRIzc3NwJDqsXbGyoqQEoKZEThe+KTJ0+IDgGRpXEhwuXk5FhbW3/+/JnzYMeO
Hdu1a5eWlvbw4UMtLS2BfyhWP2585Yg/SCnpd7bV72wrgEuJnYMHDxIdAhKwgIAAokOAnJycM2fO
1Lxs3759TEzM3r17ybNoNpsNjo7w/TtcvEh0KE3j5+dHdAiIFI0LEe7mzZujRo3inEgDAAMGDCgs
LNTT0ztw4EALTbnG6sdNME96s+mlOZmZ2YVldJBRVNPWN9BRkSHLv1WNatG1bxBqCW5ubhc5ki9f
X9+UlJTo6GgCQ6oTjQaysi3+KQJZ+wYhRAaLFy/euXNnrczEy8srPj5+7ty5f/31F1GBSSb++hFZ
5elxYadCrt1+9u333RPk9CwGOHt4e9gZK0rqqjfVoqKiBpN8zQ/UTISX6ffv3y9fvlzzslu3bjdu
3CDnVnJCSBAFJTU11cTEhOgoJB3hjQsRqKyszM7O7unTp5wHFRQURo0adfv27RMnTjg5ObVoAFj9
uPGeI7JKXp5e7X/oUVFdP6zKenYz+NnNUGvfzWvHd1OV3DzR0dER1+QUM4SX6fTp01ksVs1LKyur
oqIiW1uc7MEXU1NTbKqEI7xxIaLExMSMHDmyrKyM86CBgYGZmVn1BMQ2bdq0dAxY/bjxmiNWfji1
eM7hN0wAAJA37Nm3V1dTfU1lOagqzfv68dXj+KSMSoCix4fmLmEf3jPBjMftExFCv8nOzo6IiKh5
2bVr18jIyJiYGAJDqmXtWujTBxwdhfeJioq//o8QEi0MBmPatGn//vtvrfysd+/e379/Nzc337Fj
h4xIPPgmjnjLERkZ4QHVCaJqr6mr/cfb6NQuP3p24unNa448LmG+ORwQPuigl6Egno4RPbgwr/gh
tkznzJnD2YloYWEhJSXVpUsXAkPitGMHrF0LrVrB9+/Ce5w5MBCkpYHP6eYfP34UUDiId3jDlDTx
8fGjR4/OycnhPCglJTVy5MjY2Nh9+/Z5eXkJLRisftx4GgWmf4258h4AwMx3b8Ak7gQRAGR0bCYF
7PM1AwB4fyXmqygskNYScIMv8UNgmRYWFnI+qmJubh4VFbVixQqi4qmluBj8/YHNhvnzhb3eDf/P
I+JkRDIQeOOif7kwf8Qgu8FL7pc1fjISptLS0lGjRvXr169Wgqinp+fk5PTu3bvY2FhhJoiA/17X
hacckfbt5TcAkPlj0sh2DcxJl2s3cqKtDAB8e/WNVv9pYs3T05PoEJCAzZgxg6iP/uuvv5hMZs3L
Xr162dnZdezYkah4anF3BzodtLRg1SqiQ2k+f39/okNAAm5c7Io3J9aEaU2b1EGmpu+dmRnm67np
abkAPwY13+7du3V0dMLDw2sdHzZsmJaWloaGxsOHDzt16iTkqAi8t5MWb0+TVE8b0DRp3fAuexQF
fVNNAGCzJHYWaGhoKNEhIAE7dOgQIZ9bXl5+4sSJmpcdOnSIjo4mT2aTkABRUUChQHg4kGaVxmbg
3PkaEUWQjYtVlLhvY5zV8gV9NaTg5z9B9IyoayV9RnXGyatE+T975x3WRLbG4V8SCB2kiVJsiL2L
olJUELuIvddde1s7lnXVXVe9ruWuq17d1S2KHUXFrmBHpKmoiArSRJTeEkhI5v6RNY6AEDJJJmXe
h4dnZpic85FT5ptzvnLkyBFbW9vvvvuOz+eTr1tYWEyfPj0qKmr27NlHjhwxNTVVvWx0ze3qjFxW
gvo2TWzwMLMkp0RU/Y2ikuwSADbONrpqbzpq1Ci6RWBQMHS16caNG8lZ7b28vJKTk9UkgxxBwN//
37jZPXrQIEBSEijuFTMxL9QBxQ0u0ccbW3ekDNq6o61JQYpERRS83jdh+tFMALN8gwA4Tv7rnxnO
uvpsUj0hISGzZs3KyMio/Cdvb++SkpL4+PiwsLDWrVurXjYJzPO6MnKtI3Ib9PaqCxSFX3hSWM0K
IVH45MLDIsCuV+8GmhMmTbGoZ9Q6BirQ0qYCgWD37t3S0wYNGty/f199FhF//BHZ2dDTw+nTNNQe
HAxnZ5BCRsrD9evXFSQOg/woanAJkk9tPIhv1o1u9O+jhwDAdZn2g7+Dy8wjoXfu3L59+3bgt4yC
qBpOnDjRoEGDIUOGVFYQGzZsOHHixLi4uAkTJty7d49GBRHM87oq5NtrNmg2adlAGxReW7/x1MsS
cVW3iEtentqw/lohbAYtneCilLw5DAw6w+7du3m8zzZU/fr1MzU19fHxoVEkKdnZ2LgRBIEtW2Bu
ToMA1659/s3AQJQ8O7ghpOHSlX3qcj5fBFDy/OxDy8G+jvosFpvNZrM10CRCoyAIIjAw0N7efuzY
sWlpaRUyhRoZGY0cOdLIyCgnJycyMnLBggVstu6GUlZb5NprJoR8Vstvf14qWL/9xu4Zwy73Hja4
d9c2TeytTLkQFOdmJD17FBpy9tYbPhx8l63/piUK8/O/LIGlb2Juojnp+uSHxVJMtkMG9UH1bUoQ
xObNm6WnNjY2T548UZ/8wsOGQSSCvT2WLqVbFApYWVkxkS9oRwGDS5z34L8/R3t8v7uLBUnjIACi
IPbME/uhc0iKI4PyOHny5Hfffff+/XvpFYIgDAwMysrKuFzuoEGD0tLSEhIStm3bNnjwYBrlJMM8
rysjl47Ii1g1eJU0XQ7/TdjRXWFHq7zz3fVfZlz/pYo/dNx85VcPE3kqZ2DQNU6ePJmTkyM9HTJk
yIMHD4YNG0ajSFIePcL9+2CxQArsrZHk5eXRLQIDdcozL2/ZnTXyl+UtyQ6VBABxXuTZBOfhy62Z
tSolc/Xq1ZkzZ6amplb+k0QD69y589OnT9evXz9+/Hhm7VDN0c3I1qqDMXLSPlTfpqtXr5YeGxkZ
JScnr1ixQk3mVoEAZmYYNw4dOtAtCjX2799PtwgMVAdXWdLxDUeMZv3m71jJ0FCcHR6c0nJCJwsd
2L6ijZiYmIkTJ8bHx1f+kyTtcl5e3pUrV8aMGTNnzhyu+mVzZ57XlZFLR+Q2Gjp3hiuVsNj6Do3U
rnsoBcZZUvtQcZveu3cvKSlJejp48ODw8PCJEyeqUoZq8PDAixdwcKBbDsrMnDmTbhEYKA0uovjJ
gQ3XW6zY07OqpcKS12FvDFrZ6BFABS2x9Nn2qTvs/rN/YoPPiqW45FXwLxv33khhN+q76OeVg5x0
43klP7m5uWPHjq1SxzIxMRkzZkxOTk5YWNiKFSvOnDljZGSkegllgXleV0a+2DeOPuMmK1oS7eTA
gQPMs0fLUHGbSpyXjY2NeTwem80uKSlZsmSJWr2Ca4GCCODUqVNM5AvakX9wiXPvbF9zMqkACwdU
4VvP6sS1a9+04MD0vn8CdmP+CJzfXOpIadhm6fFDFe4vfXM7s+u608vM436bu2X/k94/dWECKn4F
sVi8adOmH3/8USisuG5kZGQ0ZsyYkpKSkJCQJUuWBAYGmpiotYUZ87yujEosNAkxwVJfFzILC4vC
wkLJsZeXV+vWrffu3auowhkbWO1DlW2amZlpb28vqY7FYtnY2PB4vMzMTFoCzKotc+di3z7MmQMq
A5cZquoAtVb496MVSiAIAizWJzdmQiwmWJ9dmonC+99PP+m+b+cAW/79xaOP+R/7rSfJN1/8IXju
kpRFhxa1VHlsjoQEODhAzQd6VFTUsGHD0tPTK1zX09MbMWIEgNDQ0IULFy5atMjMzIwOAWsHMwlU
Ri6TprK3t6KzawifLUX4/tr2nZG6miuTSQKrfagyp+eKFSukcxZBEFlZWUuXLlUHBfHDBzD2ewwK
h9rgYklgfwmHw+F8VgpZX8S8Eec9OvPSeXh3azYAQkywWeRHovD91d8uNZo7ubnKFcRHj9CjB6ZN
U3W9siMUCqdNm9a1a9fKCmKvXr2GDx9+8+bNFi1avHr1au3atRqhIILJ11wVcumI5e/OrvluX0xh
lYERv0CYcfWn2T+eT9HVdM1ITEykWwQGBaOyCCkCgYAc07V9+/aWlpbqkFFUKESzZvjuO1y+TLco
ioNZP1AHVBx+SJx9Pzi1zfCWcd95enr2XxVTFLtmgKdnz0X3SgBx7r1ff7zTPuC7Hpaq9w578wZ5
ebh1S+UVy0ZsbKyjo+Nff/1VYdQ0b9586tSpT548cXZ2TkhIWL9+fZ06degSUg6Y6FeVkdOvmShJ
ObFshcW+HRObG391E1mYcfnHOT+H5QIN5RWPgUF3+e2338rKyqSnHTp0cHFxsbe3p1EkCQsXorAQ
Rkbo3ZtuUVRFTAxsbeHkRLccDIqkPCPsfJbr/HZ127vdvYuSewtHnhx18r/uJgQLBdEHNl1ruPSH
EU0M6TCTatoUlpbqOL4IglizZs3WrVvF4i/WiIyMjMaPH3/37t3c3NzY2NiGDZmHvpYg1wuSnrVL
fUD4/MCiH86lfmWJUPju8sbZP4flArD28WtmSEFGTUZN0ukyKBCVten27dulxzY2No8ePZo3b55q
qq6GlBRIEt///jsM1WNc+/t//i03vr6+lS/Gx2PsWJibo3NnNGtGqXwGWVDphClMu3apxGNoC7KT
LYvNYrPZLH7c34GPwv471dfL07Pn/Jv5Cltjzs4Gi4Vp05CcXN1tXbviwQMcquhKQzO5ubmurq6b
N2+uoCB6eXn5+PiEhoZu37793LlzmqsgMs/ryshpoSl8d3HdjC33igDrvht+X+1t+2XkemH6pQ1z
Nt/OB2DdZ93/VvvWU+O0mIzPCkOtUE2bhoeH9+jRQ3o6adKk6OjoZ8+eVchnpXpatcLLl2jRAi9e
0CvIF+TlgaIpEblZP3zApk04cQIfPwKAmRlEIjx8iLZtKQvKUC2qmzAJwfvQTYtOt9m5e5RD1dtp
BEH8KwtLcWn7RCLo64MgwGbD3h7TpmHxYqpdVzU8evTIx8enuLiYfNHc3HzcuHHnzp2bPn362rVr
1TaojYwwz+vKyGlooe8w8Idf57bnAjnXfli0O7KA9FYhSL+4frZEQbTxVXcFUdmoT8I0BkWhmjZd
tWqV9FhPTy8/P3/OnDm0K4hHj+LlS3XMqkL9KTtz5kyRCD//DGdn1K+P3bv/VRABtG6Npk0ZBVEV
qGrC5D/dMXnmEYPpa/y/oiAC+Oz9osBRx+Fg2zYAEIuRno4ff4StLdq0we+/g2RXonb8/vvv3bt3
r6Ag9ujRw9vb+/bt2yEhIZs2bdJ0BRHM87oqqGjN4qInv89fcCSJAKfl9H07p7Y0YUGQFrJ+zta7
BQBs+/6wN6CP+iuISl1HZGCQg/z8fGtra+mGzqBBg8LDw9++fWtubl79B5VKWRksLcHnY+ZMrXVq
lijhVlYgG6936AAbG9y4QZdQDFrFwIG4dKniRSMj8PnYvx/qFp6PIIi5c+f+73//k17R09MTiUSj
R4+OiIgYOHDgtm3bjI2Z6JFaCxWHLbZZ+xk7Nw+pB4jiDy36/kxyYeqFH6QK4nqNUBCVTXR0NN0i
MCiStLS0Bw8eKLuWn376iWzxY2NjM2bMGHoVRAAzZoDPh4kJfvuNXkGUgiRfc0kJjhxBt24wNUWL
FrCwAIA3b5CYCIJgfpT+ExUVTbsMyv6ZNOlzr3NywvDh6NMHXC7c3NC69ec/BQaiUlQZVSMSifr0
6UNWEAFYWloSBHHixIk9e/bs2bNHmxRE5nldGeq778LMKxu+3XS7AOCYckTFIgC2fdfvW+VjpyG5
oBl7RAYZSUtLa9CgAQA3N7dly5YNGzaMw+HU+KnaQhCEpaVlQUGB5NTFxYXH4125cqVNmzYKr0t2
Xr1Cy5YgCJw9i6FDaRSkambNorq0WWGofvyI48dx5AgSE2Fri4QEXL8OJlOXstGFCdPdHdHRkLhI
PXiADh0wYQJGjPj3hUTC+fMYNQrOznRa/ZaVlXXr1u3x48fki507d7a3t8/Ozj5z5ky9evXokk1J
0Nr9+E/+M2b+hTzAZsT+Y9+1Ug9/QGrriBL06/Vb++uCTobAvwpivw0apCAyMMiISCTy8vKSHEdE
RIwePVpPT6+kRPHR4S9cuCBVEAG4u7s7OzvTqyACGDIEYjE6dFBHBXHuXBw4gLlzFVlm3bpYuBCP
HuHBA4weDQDjximyfAbdJDMTDx6grAzp6ejVC0+f4uZNTJ/+hYIIoLgY5eXIzqZJSoDH47m6ulZQ
EIcMGSIWiy0tLcPCwrRPQaSZkrizYXkAUH/AYBd1URAhU3xEQlhSWCKsVre26rP8h7Rlq4Lfmbsv
2TK7k0Fxfj75zyx9E3MTfbVNxqdMmBja2gFBEL169UpOTsand01jY+OSkhI+n6/wDKTr16+XHhsZ
GSUmJs6fP1+xVdSWggKwWDAxQUgIvYIokaioqCqvN2+OjRuxYYNauxRoDVo/YdarhxUrMGUKWrWq
7jYPDzRr9sWutCopLS11dXWNj48nX5w0aVJYWNiCBQtWrFhBj1jKh77uRxTEBN0vBoBGfv0bqpOR
ngwrqyX3FvZfFUuplo6br/zqoa65vBmfFYYaGT9+/LFjx6SnbDZbLBZ7eHjcvXtXsRXl5OTY2tpK
R6Wfn19UVNTbt2+5XK5iK6otHz6goEBNYwSmpqJ3b4SFoUEDukVhYNBwBAJBly5dnj59Kr3CYrFm
zZoVFBT0559/Dho0iEbZtBZxzrXFI3+MKQeaf3dy/4j6ijdhkhvVJxnSLdQhcxoDRdasWUNWEAHM
nDkTwNGjRxVe1/r168mvbfr6+t988w3tCiIAOzs1VRABNGiAxESqCuLWrVsVJA6D/AQEBNAtgk5D
EIS3tzdZQWSz2QsXLjx79uyZM2e0XkGkq/uJs+4FxZYDYLcf4WWnRgoiZFpHFKbfPB36TkihEn0H
75E+juq0fEqG8VlhqIZ9+/bNrWTpVr9+/fPnzysjKL+lpWX+J0sNFxeX3Nzcx48fOzo6Krwihgow
Q1UdYFqBXqZMmfLPP/9IT1ks1uLFiwMDA4OCgtzd3WkUTDXQ1P3K0499O25vIsB123j6P71pyA9e
DTLYI+o7+oybrHxJtJM+jCekJrNkyZJdu3aRrwwaNOj69etHjhxRhoJ469atfJIpb/v27UUiEb0K
YmgouneH5gfHrZkmTZrQLQIDM2HSyY4dO8gKIoDZs2cHBgaeOXOGnPNJi6Gn+wlTr51PBADjHiNc
66iVgghmr1nZXL9+nW4RGOQhMjLS2dl5586d5NdKX1/fp0+fHjp0yNvbWxmVkr1VuFxuRkbGlClT
lFGRjOzahb59MWECjSKoDq33ltAImAlTQnExJkzA5cuqq/HWrVvLli0jX5k4ceKZM2eCg4N1REEE
Td2vLOnixXQAsOg5vL2Z2vn2MjoiA8MXREdHu7q6du3aNSkpiXzd1dU1IyNj7ty5E5SjNJWWlt6/
f1966uPj8/r16wEDBiijLlkoLMSKFRCJoP5p7l++hK0tXr6kWw4GBgVx/jyOH8e0aSqq7uPHjwMH
DiS/D/v7+9+4cePw4cPdunVTkRA6Cv/luesfAcCmj39LNQxHLqeOKPoY9uvagIC1O65mlH/tnvLM
67vWBgSs3X0nSySveBqPlZUV3SIwyERJScm6descHBxcXV0rRNtns9kAoqKiBg0aFBAQoKQ2PXjw
YHn559FkZWU1ZswYGr1VRo2CUAgbG5ASR6spv/6K7Gz8+iulQpydnRUkDoP8MBOmFIKASCVYDZFo
AAAgAElEQVRPToIgPD09+Xy+9EqPHj3evHmzatUqX0mkb52Bhu6nrmERpcgX6lqYfuXgqdspcJg6
0/arJehZu9RJ2hiUhoyW/j0mOOlmUG1Jgi8GteXJkyeHDh26detWXFxcldbKbDZ7wIABFy9eHDJk
yJYtW6C0Nv2VpOPUrVs3IiJCGX7TMhIejuvXwWLh3Ll/UxirM5JkYBRTglVYNmagBWbCVD3Lly9/
9eqV9NTJycnc3Lx169YLFy6kUSpaUHn3U9+wiFLk0tzEubF3UgA4+PZ2qua/0nfo6et48FD629tP
8sY52erktvbJkyfpFkGtKS0tzcrKys7OzsrKKioqEgqFYrHY2trazMysfv36NjY2ZmZmCqxOLBbH
xsbeuHEjIiLi8ePH6enpQmF1Hvtdu3ZlsVhv3749e/asv7+/5KIy2jQzM/P169fSU29v78ePH3fp
0kXhFckCQWDoUBAE+vSBRlgi/fIL9PSwZQulQrZQ/DyDImAmTBXz9OnTnTt3Sk/19fV79eqVmpr6
m1YmZa8JVXc/cW7E6UelANDc38dBLVVE+XREQebzDACGTdvWq/a/0rdr52KMdF5G3HvBYFt1XEZV
OqNGjaJbBLXjzp07P//8c2xsbE5OjkiG3RQWi8VisfT09CS/y8vLCYIwMzMzMDDgcDimpqb6+vom
JiaGhobm5uZ6enoWFhYGBgbGxsYfPnwoKCjIycnJy8vLy8vLysoSi8VVLhZaWlqS3yBZLJaHh4ex
sfGzZ89Wr149c+ZMPb3PI0UZbbpp0yayYGKxeBJdORaAH39Edjb09BAURJcItYa6grdy5UpFCMJA
CWbCVCUikWjgwIFisVh6ZcqUKdevX4+MjFSHmKyqR8XdT53DIkqRS0cUleSUADCxMavhv+KY2JoA
vOLsEl21SDx16hQz60nJzs4eOHBgZGRklX91cHB49+5d5esEQRAEIRAIAJR9SoiWk5NTTUX6+vrV
LxBWQJof2dbWtmPHjrm5uS9evFiwYMHp06dNTU0r3KyMNiXH6G7Xrl1oaOi2bdsUW4WMZGdj40YQ
BLZsgbk5LSLQw40bN5jAK7TDTJiqZM2aNeQp18PD4/r16wcOHLC1taVRKhpRbfcrzwg9+4IAwO0y
opu1um60ymclyNbjAGJBcVkN0SYJQbEAAEtd/3vlM3r0aCYkrITXr1+7uroWFhZK1gItLCykmpnC
MTAwqJWO2KhRo6SkJAsLC6FQaGxsPHfu3AEDBnztTVrhbRoTE0NWeTt16mRtbd2Aprxyw4ZBJIK9
PZYsoaV+2vD19WWGKu0wE6bKSE5O/uWXX6SnZmZmDRo0aN68ed++fWmUil5U2v3UOyyiFLl0RH2r
hpYI/1gU/+SDsEM1dpblH58+LwBg6VhHNz1WAEtLS7pFUAsyMjI6dOjA4/E4HI5IJNLT0ysqKlKx
DIaGhqWlpZJjCwuLpk2bWltbC4XCtLS0rKysTp06TZs2bfz48ap3bdu0aZP0mMPhZGZm0hUWMTQU
9++DxcLFixrgqkImKQlMDGwGBtnx8/MTiUTSzCKTJ08OCQkhZ+FjUCpqHhZRily6G9ehS2vj4x95
qacDY/wD3Cyq1oDFhTGBJ1MAGLbo6qiLtg0AkJubS7cI9FNeXt69e3cejwdAMiuJxWKJEYy/v79Y
LObxeEVFRY8fPwbQtGlTfX19Q0NDFovF5XLFYrGenp5ku5nNZpeXlz969IjD4Xh5eZWWlkr2oPl8
fllZmUAgKCoqEovFUu2TzWabmZkZGRmZmZmZm5vHxcUBcHd3f//+fUZGRmFhYcuWLd3c3Dw9Pdu2
bSsJcCMLin3RJAjiypUr0lNPT8+IiAi6LPeDgsBmw88PHTrQUr+cBAdj2DCcPYtPbkXywAxVdYBZ
RFQNO3fulMyHknnVycnp8uXLBw4cMNcp+5JKqLD7qXtYRCnyre+ZtB3paxV2Ljf/8ppVdlt/mtLZ
qmI55bkx/3y/5lIeAMs+o9upsZbMoHTmzZuXmpoqfWE1NTWVqHETJkxo2bKltbW1ra2tlZWVxJ2Z
x+OVlpYWFxcLhcL8/HyRSFRQUCAQCEpKSng8XllZWbt27YqLi/X09MrKyiRXpL+5XC6Px9PT05M4
oFhaWlpaWlpZWUl+t27dulmzZi1atGjRooWLi4uaGGVfunRJoj1LcHR0dHBwUKw3t+z88gs6d8b0
6bRULj/Xrv37m4qOyCz5M+gIGRkZK1askJ4SBJGSkjJ58mRd3mVWNWofFlGKnHvARm2mL/G5tfZm
QVncX98Nu9xpwACvzi0a2JoborQwK/Vl9J3Ll2M+iAHAwnvpjHYmihRZo/D19dXx7FLPnz///fff
ARAEweVyORzOnDlzAgMDw8PDnZyc6JZOHhTbplu3bpUeGxoaxsfHk7eeVYyRkeYpiIpi1qxZ+/fv
p1sKXYeZMCVwueBwUMlfTjF4eXmRw/UPGjTo2bNnuhnspgKq6n6fwyIa1sPTy+dfVHkX29Cpu09H
a/n9nQWv902Yfr7tjtPrusivg8lrJ8i28lq5c37hgt8iSyD+EHPxr5iLVdxl7rZgV4CXldpaYyqf
Gzdu0C0CzYwdO1a6gC8UCgUCwT///PPo0SMNVRCh0DYtLy8PDw+Xnvbs2TMuLo7xrqWFAwcOMDoi
7TATpoSRI1FWhp49FV/ynDlzyKnJHR0dY2Jijh8/TtfehVqhou73OSwiSmMP74z9ym16ndcFUXkW
CDOiEgzaDB3VltIinfy+JCwjlzHbjrUMPrDvn5BnlS15rNv5TZ0z06/NV4wVdYWZM2fSLQKdnD9/
/tmzZ9JTLy+v27dvnzt3TnMVRCi0TU+cOEF+oTc1NZ0wYQKHo+pAWbm5IAhYW6u4WvWCCbmiDuj4
hElGGWnhT5w48b///U96yuFwGjdu3L17d09PT8VXpoGopvtJwyJWj2G3kV0tqehP+o3G7ToyjkIB
AACWAow0ibKcpOfPXqV8yCsRgGtqadegeZs2ja25GmKDaGFhUVhYKDn28vJq3br13r176RVJa3B0
dJTG39LT0xs7dqyZmRnz9Urp3r37w4cPJcfm5ubW1tbBwcHt2rVTpQxCIZo3h74+QkPh4KDKmhXG
3LnYtw9z5oDpWQwMX+POnTve3t7ktAV+fn4pKSmPHj1SE+Nshq8jzrn63cifCqdsGV8aEhgSnlQg
qtN+2uatU52zwv7e/09IeFKByLLD9C1bprYyYQEAUXh/7ciAt+P++XtaY07O1e9G/lQwcf2w4kun
r0WlFIqNGvdfunVFv/oypHZRREwaloG1c6eezp0UUJTWkZSU1ERXY3KEhISQA7QOGzbsypUrL15U
bXqhQeTl5SnEv6G8vDw6Olp66u7unpiYqGIFEcCmTXj7FiYmur6OyKAOKGpwMVQgPj7e19eXrCB6
eXk9ePAgLCyMURClqG/3E328GxRbzra6+vd9n4GTA/pmXd2159Y/u/6XoZ8g7DxwckC/rCs79tw+
dvzl2I2djQCI8yLPhPOdZ/k66UOUeTcothwmYdc+TJ6yafwadvzvC9eE/HV5vPf0xjUriboat1BV
ODs762w0h6VLl0qPuVxufn7+mjVrtCCCv5WVlULaNCgoiBzo28TEZPjw4dSLrS1OTjA2xj//wFCt
veuUjtTvnoFGFDW4tICMDFhZKWZUJiYmurq6SlJVSWjSpElBQcH333/fpk0bBVSgLaht9yt/H3Y2
HibdZ2zbNNhRHwDPMPTQrVvvsjv/sWeAgz4AHvf6wdtPTQ0k27finAdBUaLWS3vZ66E8PexsPOr0
Xf3fNV7WbAAEt6sDK6TIhCvTRjZVHbE8L+F+6J3IuKT3uQU8Tqt5m+e3+bdPi3kf0j/yxSyupX19
C30N2XdmUBQxMTGvXr2Sng4ePPjhw4chISE0iqRukB0Jzc3Nnz17Rg5IoTK++QajRulW2j0GBjXn
0SMMGABvb5w6RbWoxMTE9u3bkwNs2djY2NnZdejQYeHChVRLZ1AFwtSr55L0XdcsH+goWfgTZsQk
8Lld1y3r5yC5IHgX/arUqL1nIwMAEGXePhPH6bjOw5YNYfLVc0ncrj/M8/iU7o/3+m4iUW9oJ1uZ
DN8p6IjigieBmzYcCM8ilZb/eSWbKAzfPGX7MzG7XcDp3YNsddR1JSoqim4R6GHt2rXSYxaLJRKJ
FixYoB2bGgppU6FQGBERIT318vJ68uSJq6sr9ZLlgFEQATAhV9QBnZ0wK/DmDfLycOsW1XLCw8O9
vb2l+aUAWFhYtGrVysnJaffu3VRL1zrUtPuVvbl48Z1pr6Wen/SosjeXrrw37x3Q45PaV/rm4rVM
M8+V7UxZAITpN4JfG7pt7mrJRlnCxYvvTHsu7f4pvgxR+PjMvWLHcf0ayfY0lld1ExfF7J49/5OC
aGJlUekOjl2fqb1NAPHT8xE5Yjmr0Xg6d+5Mtwg0UFRUJMkdoq+vb2Rk5Onpeffu3dmzZ9Mtl2JQ
SJtevHiRvNFcp06d4cOHszQr/512wYQcUgd0c8JUEocPH/b09JQoiJK5xdTU1M3NzcLC4tChQ6qP
n6D+qGf34788fy3LymeYNIYN/+X561lWPv6tPl3gxQffyLbyGdbGBAAEyZcupJh6Du9owar8WXFe
ZNBDflN/XycZ/FUAuXVE/vPffzydDsC868ydZ0IvHw3oWOkelmmbId1NALy+9bJYHbf4VQE5QrLu
sGHDBolVh1Ao5PP5d+7cmTx5cp06deiWSzEopE337NkjPTY3N3/x4sWwYcOoFys7V6/ixAlVVqhE
JOkhKCaJOHDggEKEYaCCbk6YyiAgIGDy5MlSJxXJhGxtbS0QCI4fP64dWzoKRx27H1EcdzYs366f
X3ND8oV6A4Y0+3Sh6OmZOwX1+vlJLpS+On8l09Lbv61J5c9CnP3gdLSozfDe9rLuIculIxKFMUcv
ZwNwnLRj0yRX269ZGxo7e7iwAWHKi481BwPSTgICAugWgQb+/PNP6bHErXvBggX0iaNgqLcpQRD3
7t2Tnnp5eaWnp3t4eFAsVnZevcKgQZg+HcnJKqtTifj7IzeXUiI+ALNmzVKQOAzyo5sTpmIpKyvz
9vauoO7Y2dlZWloaGhoGBwcbG6tzfmA6UcPuRxRGn75X4jR4YGPupwsxQfdLGvoN+LRXLC6ICXpQ
0nDwIMmFkhfBobl1+/m1MKz8WZS/v3XmGafTCHcbmVU/uXTEsvSIF6UAWk0YVm2mQZahXcM6APLT
8oTV3KbNqOfatVIJDQ3Nzf0cVN3Nza1Pnz7aFACIepvevn2bbCFkZWU1dOhQVW79rF4NsRjNmqFR
I5XVqVyoB6xQ05gXOoYOTpiK5eXLl05OTmFhYeSLzs7Ozs7OHh4eUVFRFhaVDcMY/kX9up8492FQ
ZFlTf99/nVUgzo0IelTabJjP5wsPT0cKXIZK7iAKHwfdKXQaPLAJt/JnIUy/fu61oduILrWIzS2X
z4oo/10BAEuXRmbV18TmGukBEJQIdHWvWU1tYJXJDz/8ID3mcrmpqanfffcdjfIoHOptumvXLumx
gYFBQkLC+vXrKZZZK3buhIEBmAStZMgvNgx0oYMTpgL59ddflyxZQg6CCKB79+45OTlubm7btm1j
bBCrR/26H9u6369h/b640Pe/YWSzGrZN/923+n86Y5m7b7p299+Tip+FfqOpgXen1lKC2t3+SQ4W
CwBRoydKedHHYgBcY03JucJAkeLi4gcPHkhPvb2937x54+fnR6NIakhoaKj02MPD49WrV97e3qoU
wMkJgYEKWHtjYGBQB3g8no+Pz6JFiyooiKNHj05OTl68ePGOHTsYBZFBDuTSEfXqONYBkP82nVet
mliWcj+OB8DG2UZGFxqtw9nZmW4RVMrWrVvF4s+dwszMbOrUqVpmH02xTWNjY4uKiqSn9evXHzRo
kJZ9RaqHuh0RXYGHGMjo2oSpEB4+fNioUSPymycAU1PTKVOm3Lp16+DBg1oTU0LZMN2vCgg5EBc+
WNXHw8PDa3bw+3KCIAii+O4CDw8PjwV3iz/fJXx/fpG3h4eHx5CtT/nyVKMizM3NAQQBBCAGxADB
YsnzAxARERUKr903/OOPhNy1S2XYvp3S1xESQkUAMUAAxwEADRs2rFu37uvXr2stQ1YWpS9B8uPg
QOl7IAjC1LTK5qhFDzE3J3JyKpQ6ZcoU6ejjcDheXl5BQUFflcHZWQFd4lMTCIWEWFz772HQIAXI
EBtb+4pJVDs05mAvQMzB3hpk2L27mhpqHqqHDyvge5gxg9L38PIlwWZTHRrt21OSgSAILpeqDMbG
RFFR5YJrMWE2bEi1OVgsIiWF0vfQq5eShkZgIMFiETY2NdQvFouXduki2aUj79W1BPoDnYFXMspw
7Bil70EhQ2PePEoyPHhAtTNItkcpwuEo96tWOXKtI7LM2o/xtQLEz37bfCaptApbQ4L/9vKWBf+J
FgBw9BvRXP2zfDUHALAkI40g5Pnp1g1nz1Yodv/+/bUQ4vlzyF275KdDB1AMBZySQkUAFpAEdAAA
uLm5tW3btmnTprWWgc+n9CVIfkipouWEzweqaI5a9BBz88piSCJHSujSpcuTJ0/69++Pr/HxY5Uy
1OKnY0c8eiQpbMgQDBny779VC96+pSqDmxtI/7U8VD80pFQjg6srSL7klVm5cmUNMrx5Q/V7aNIE
d+/WUEv15OVBLKYkg6kpXr6kJAMAgYCSDAQBAwNUZQC6ZcsWWWWQfJyKDK1bIy6O0veg5KFRfbzU
zMzMVq1abY+MrPAEHg7wgabAfcBFRhkoRuumPjRatQJFW8D376n2SVPTLXqUsxOLRMr9qlWOnN+I
cdtvl/W9u/pafsyvUyY8HDHSg5sLAMVpzyJvZ72MvX/j0r0kyZOo3vDlY5voxj5aVZk1Z86cqVIZ
9PVBt9GJCBAAHA4nIyNj/vz59ApDCeoRrY2MKlzIzMz88OGD9NTR0dHe3r66UBSKk2HnTly9Ci4X
PF5luapFCd8DDXC51Q+NWmgncsPhQJ9usxsWSwE5gFksENT8EL/SJWrW1MkyUIR6t1SaDB06oF49
VJO//fTp0xMmTCCnYCYAY4AH3Af2AbWItmpgADbdidD09NRhaKw0Man5Niqow1ddS+TVmtlWHst3
L+Uv2n439+OjoL3/rlO83rtsCfku696rds7rZKrDDis3btzQzfwNXl5ez58/V3FcaPXnv//9L/k0
Jydn+vTpKqi3sBArV4IgEBAAa2sVVKh5JCUlaVOEJg1FZyfMCrRqhYSEqhVIkUj0zTff/P333xWu
ewDGwBvgBtBYFTJqITfKy5nOVwH5V1ZZho38fwpsffXQ3kNnozIrxci2bj/s2/kzBraoITqO2vAK
aAk8s7AwNjaWZ3sUwK1b6N27wjVfX19C9hfu1q0BwNMTgJxvG6mpoBgf1dERAHr2rO3n3iYnp6ak
AKgDNAUsLS2nTZsmpyuGZJ2j9jJ8we3blD4OoLwcHTtWTmZ8+/btnjLKdvt2hbWr4OBg6XHjxo2j
o6PPVrJP+AJTU9jYwMlJRpGrlmHx4lGjIBTCxgakwEQy4+SE5GRQcem4dQtDh8r/cQDNmwNf7xKv
7ZEB2NvD5evtkpBQvXbs7Oxcw1Bt3Lg6GWQhPx/p6fJ/HIAkWREVGcrLcf8+JRkAEAS6dYOBgfwl
3L5d5RRXiwnTwABNmlAdGhTXrhwcUFSENm0oyfCVoWFmVsXFrKwsd3f3169fky/qA9/a21/OzR1m
YxPSpIl+bVc3Hz+Gi0vtPlIB6kPj40eq1kF161KVobzc9/59BYTpq0YG6l+1ymHVQoP5KsKC1Phn
L5Pf5xSVijlGlnYNXdq2dbYx0BDt0MLCorCwkAtMBVxcXOzt7cePHy9nWZV2llmsWn7DR4+iuBgA
8vLklGH6dNjayvlZCadPIzGxth/auHEjj8eTHEfWq/dMLL5//76c2jaAa9cQGyvnZyV060ZVy4yN
xbVrlS8HBATIui/ZqhWGDJGeCYVCIyMjaXAKPz+/4uLimzdvVldCejoCA2UXuQpsbcNbTnd3B4C7
dyE5qB2Fhdi3j5IMAGTfQ/wau3ahrKzKv8wN7rvvYcc53WL3+lfRXp+pdmjINFQDA6kqeSNHgqLv
JPWh0bMnunWjVMLDh1Tfwb4cGlJqMWEmJuL0aUoyODpiwgRKJVAfGgYGkDl87J07d/r378//0qC4
cePGQxs0OBYd/b9hw/wlqwxyMGdO5Zfh2nHoELKyKJVAfWhcuIAXL6gUwAoIoKoR1Tg0qH/VqkUh
OqJmI9ERJcdeXl6tW7feu3evogrPy8vThfwNISEhQ0gz/ogRI3g83qVLl2gUSXnI3aanTp0aPXq0
9NTPz8/d3X3FihWKE60KCAL16uHjR/TpQ9WdSW2ZOxf79mHOHFAZuMxeszqgIxOmHGzfvn358uUV
ntf+/v6lpaX5+fknTpxo0KABXbJpDUz3q4yGrPVpLDrS4ZYvXy495nK5iYmJmu2tUi1ytyk5jbWZ
mdmLFy+q82hWEJs2ISsLenoIClJ2VZoNoyCqAzoyYcrCtm3/ugsDmD179rJly8gKooGBwdKlS2Nj
Y1u3bn3nzh1GQVQITPerDKMjKhfyupG2EhkZ+ZIUTcPHx6e4uFgF2g9dyN2m5Aw03bp14/F4bdu2
VZBQVZOTg/XrQRDYskWz9jdoIIB6GG4GyujChCkLR49i1Sp4ekIkEg0aNKhCDDVHR8cZM2YcOXJk
z549v/zyiz7tHsHaAtP9KkM5GlB5Ucab10nvsgr5ApH4K/vW+nZufdzsdLIbnzp1im4RlM6MGTOk
x5IsjbNnz2Zrmoe/7MjXpsnJyQUFBdJTGxsbX19fFvXYGdXi7w+RCPb2WLKk5pt1nK1bt6oi/A1D
tejChCkjYjHKywWenr3Cw8PJ193c3MzMzGJjYx89esQsHyoWpvtVRn4dUcxLuvbHr3+cif4gqvHe
jpu9dFRHHDVqFN0iKJfw8PAnT55IT728vKKjo0+cOEGjSMpGvjb9448/yKc5OTlTp05VjEBfISYG
Dx+CxUJIiALiuGk9TMgVdUD7JkyCwLVr8PFB7cMzC/Lzu4aHPyFf8vf3T0hIcHd337p1qx71gM8M
X6J93Y86cnYyoiTu93nzjiTqur9LjZw8eZJuEZRLhUygBgYGixcvNqsybIO2IF+bkmPctGjRIiIi
4ujRo4oTqgratMHAgXB3R8eOSq2Hfn75Bamp+OUXSoVc11aPHo1CmyZMsRhHjmDxYhQWYtQo1Gq4
i0TlBNG9vPwLBXHGjBlXrlxZvnz5ggULFCwrAwDt6n6KQj4dUZAYuOlfBdGyvd/oQe5tm9SrY6TP
/spiBcvQVg3yLNCCdvtJHThw4OnTp5JjFovVvXv3x48fn6YYkEIbEQqFr169kp62b9/e3NzcWsnB
rLlcnDun1BrUBWNjhITQLQQDwydEIhw4gIAAFBWBIMDhYMSIWnycIIitW/sDMdIrLBZr3rx5p0+f
3r59u/yh2RgYao9cOqIw9eb1dwBQb8Sugws7m2ut5Rl1rKystDW6UFlZ2eLFi6WnBEE8ePBg8+bN
2r2ICDliXgI3btwoL/8izny/fv0UKhQDVaysrHKryiDMoErkGFxqhUCA337D99//m3NeTw+zZ2PT
ptp5jM2YMeP5889hU1ks1uzZs0+ePPn3339rsS+gOqDp3U8ZyKXeCbLeZANA66kTOjIKoq4ybtw4
adBsAMOHDzc0NGQ2Qark0KFD0mNjY+NXr1717duXRnkYKpMnd9R6BgagtBQbNsDcHEuXgseDvj5W
rEB+Pnbvrp2C+Ntvvx08eJB8Zc6cOWfPnj1//jyjIDKoHvk0PIk7pom9vSmjIVaPtho5PXr0iJxW
zsbGJi4u7sSJEybKzomuBsjRpnfv3pUed+vW7e3bt927d1eoUJ+JiUHnznj/XknFay0Vwosw0IKG
TpivXsHaGuvXo6wMhoZYvx4FBdi6FbWdDsPDwxctWkS+8s0335w6derkyZNubm6KlJihKjS0+ykV
uXQ8br1W9QDwc/IFzLJs9WilsyRBEP7+/uQ1+Z49e7Zs2dLPz49GqVRGbdu0oKDgw4cP0lM7Ozsf
Hx/Ol3mcFUV5OXr1QmwsDhxQRvFqyr17YLFw7x6lQmZWSqTJoHo0dMJ89gxsNkxMsH07Cgvxww//
5pyvFXl5eX379hWLxdIrXO6Imzdv7ty509PTU5HiMnwFDe1+SkUuHVHfwXuQMyB+cTk6T1zz7brM
AW18Vi9ZsuQ9aZ2qe/fut2/f3r17N40iqZLatumRI0fIpwUFBcozRly0CEVFMDBQQHpkDULiMUrR
TZwJjaYOaMqEmZsLESno2/DhuHULBQVYsgRyB7QeMGBAcXEx6YKbWJz27bffTqCYVJpBZjSl+6kS
+faK9Z1GrJruwi4N/2XbpbQyZi3x68yaNYtuERTMs2fPfv31V+mpoaGhnp7eihUrdCeaa23blBwt
0tbWNioqSkk6YkoK/vc/APj9d3mWMXQcJsWCOqARE+aECahfHwsXfnGxc2dQ2Rv4888/IyIipKcG
BqYsloW+vsvq1avlL5ShlmhE91MxMvg1E8KSwhJhRUXQbuj6H4s3bji5deLU+2PHDvJs37SeuaFe
1SonS9/E3ERfJ6P4alkSWJFI1KdPH/JuyIgRI+Li4sgOzlpPbYMZxcbGSo87d+6ckpKiJH164EAQ
BJo3x8SJyiiegUHpqH+ksIMHcfw4CAKkrElU4fF45AT3bDa7rKy4fv3MmzcvKDsVEwMZ9e9+qkcG
HZEXsWrwqtiv/z393tFf7lW/zdNx85VfPbTfmaEKEhMT6RZBkUyaNIlsWufq6nrr1q2TJ0/qVMT/
WkVISUpKIu8fmZiYKGkR8fhxxMcDwKVLyihe+2FiXqgD6h9+aPx4vHiB3r0xeLDCyt6mcj4AACAA
SURBVFy4cCE5RsTUqVODg4MfPDjXqBFXYXUwyID6dz/Vw/glM8jKhQsXjh07Jj01NjauU6fO+PHj
e/ToQaNUao40jAWbzeZwOKGhocrQEcvKMH06CALffgvtWrlmYKCT+HgMHQpSjiQYGWH7dkUqiPn5
+X///bf01MHBobi4eN68eY0aNVJYHQwM8iLD8g+30dC5M1yFFCrRd9DZ1yFXV9eoqCi6pVAAOTk5
FQy2/P39X758+dNPP9ElEl3Uqk0vX74sOZBs0Ofl5fXs2VPhIs2aBT4fJibYs0fhZesKvr6+TOQL
2lGrCfP+fXh7QyhEXByGDVNWLYsXLyYH2J80adKxY8f+/PNPZdXH8HXUqvupCTLoiPqOPuMmK18S
7SQ6OppuERQAQRCenp6lpaXSK7169bp27drdu3e5XJ1T/2vVpi9fvpQeDxgwoKioyMhIwYkpX7/G
4cNgsXDkiPw+lQw3btygWwQG9Zow69ZF3bqoVw+k7RMFIxAIyJszzZs3v3z58rZt24yNjYuKYGQE
XbLioR+16n5qArPXrFxWakUMkhkzZsRLjN0AAPXr18/Nzd20aVOLFi1olIouZG/TpKQkPp8vPTU0
NFRGnLNx4yAWo317+PsrvGwdgomPqA7QO2HevQuSuTVcXPD6NSIj0bSpsmr8448/ysrKpKceHh7m
5uajRo168QLNm+O775RVL0OVaMfzWrHUSkcUCwUCgUAgEIpqsu4mRJ9u1fH4iVu2bKFbBKocPnyY
nBuKw+H06tWrSZMmOvtMlb1N//nnH/Lphw8flKEj+vrC0REXLyq8YN2CybOiDtA1YYaEoEED9O6N
Pn1ACtug9BhSO3fulB7b2dndvXt3w4YNAB4/RmYmTp5Ubu0MFdCC57XCkV1HFGVdWT7Qx8fHp//i
M6mCGm4WpJ5Z3N/Hx8dnUMD1LF1WEzV97TouLm7atGnkK5MmTbp3794ff/xBl0i0I3ubXiL5GDs7
O8fFxSnDv2fzZrx5A3t7hResWzD5mtUBFU+YBIFTp2BnBz8/pKWBIDBmDNiq2l1LS0t78+aN9FSS
w713794A6tWDkRF0cp+GTjT9ea0MZB4NvGd/7XtUCnBdl64b2dighrsNGo9ct6QzF+CH7z38gl/D
3VqMq6sr3SLIT35+vqenp4iUT8DX1/fixYvHjx+3tramUTB6kb1Nnz9/Lj1u06ZN06ZNLSwslCGS
QU0DUrvx8Pj8W26srKwUIgwDFVQ2YYrF+Ptv2NhgzBh8/Ag2G+PG4f17rF2rmvoBYNeuXeTT8vLy
KVOmSI69vRESgjNnVCcMAzT8ea0kZNQRiYKowKu5ABzHL+hrJ0s0eY5dvwXjHQFkXw6MLmAij2kc
IpGoR48eBaRAsU2bNk1LS9u0aRMT7EYWkpOTyTHPjI2NmaSrSmL8eERFYfx4uuVg0ATKy7FvHywt
MW0acnPBZmP6dHz8iKNHUbeuSiUhe6t07Njx+vXrE0nh73v3ho2NSuVhYKiMjDpiyYsrsWUAXEYO
bCir56R+owHDXQCURl15yavxbi1Fc2NoDx06lOynYmFh0bhx4549e86YMYNGqdQBGdv05JfGRB8/
flSsjvjjj2A8caV07ky1BCbmhTqg7Anz/Xs0bIh581BYCA4H8+cjNxcHD0L1i8jv37/PzMw0NjaW
BDpo1apV27ZtdSejqXqiuc9r5SGbjih4//h1KYD63TrYyJ6SkmPbsVt9AKUJj9/XZMCorWhoLr6V
K1deJDlBcDicwYMH8/l8cqZmnUXGNiV/gY0aNYqNjVWgjrhzJ374AaNGQUglcCkDic7U1UwGyih7
wszJgVgMLhcrVyI/H7t3w9xcqRV+lT/++IMgCB6PJwl9EBgYKN1oZqALDX1eKxXZdMTyvNQ8ALB1
tqlNtCY9W2cbAMhLyS2v6V4tRRNzhO/fv/8///kP+cq0adPu3LkTFBSkg9EQKxMQECDLbU+fPpUe
t2nTxsbGxs7OTiECFBZi5UoQBBYsYAIiKoytW7fSLQKDrINLdkpKvkis3KYNwsJQUIAtW2BCa3rY
4OBg6XG9evUADBkyhHxDWBiys1UtlY6j8O6nBcimIxICvhAAW99QrzYJxll6hlw2ACFPqKsGiQcO
HKBbhNpx+fLlOXPmkK8MHz48ODj4zJkzdVVsraOuyKJM5Obm5ufnS0/NzMy8vLwUJcDo0RAKYWOD
DRsUVaTGQ13BYx4P6oACNfXCQsybB2trDB36RTibFi3UwsfrxYsX0uNu3bp17tyZ7DUVGoohQzBi
BB2S6TDMi2JlZNMRWVxjfQBiXj6/NoFsxPx8nhgA11i/NqqlNtGnTx+6RagFUVFRQ4YMIYjPGr2P
j8+DBw8OHjzIOHxJkaVNyYsEAPLy8jwout1+4uFDXLsGFgvBwWDp6rCqwLp1CAjAunWUCmG2mdQB
hUyYOTmYNg1WVti7F2VlEApBClOtFrx48YKctsrIyKhXr17kGzIzweOBZBDOoAo063mtGmTTEfUs
nSwBIOPpu9oYFgrePckAgDoNLHU1oZAGZYB9+PChu7s7OdJNp06dkpOT161b5+fnR6Ng6oYsbXr2
7FnpsZWVVVxcnEKMEQkCQ4eCIODtDXd36uVpCZItOYobc4y5ujpAccL88AGjR8PODn/9BbEYVlb4
+2/cvQtF57+kypEjR6THLBbr/fv3FdK4d+iAevUwerTKJdNtNOh5rTJk0xG59Ts4GwAoCL+aILuL
Mu/llfACAAZN29dnzNjUm7/++svDw0MgELBYLBaLBcDZ2RnAqFGjKmw9M8hCZGSk9Lhjx45Q0DLV
pk3IyoKeHoKCqBemPXz7LQwN8e23dMvBQB/p6RgyBPb2OHUKYjHq1cPJk8jOxuTJqouJLTtXrlyR
Hrdq1So6OrrCO2SrVkhIwJfxExkYaEDG0WPSckAnLoC8i3vOp8jmSSlIPrfnUj4Abqf+LWk1DqYT
9Q/MGxER0aZNm2nTpklWEAmCkOw1p6WltWzZ8ueff6ZbQLWjxjYVCAQfP36UnlpbWytkETEnB+vX
gyDw889QTihuTaVTJ/D56NSJUiGSlyIGepFjwiQITJqEhg1x8SIIAg0a4OJFvH+PkSPV1xjj5cuX
0mMXF5dmzZrVqVOnwj1mZtDT1f03ulD/57XqkbEPsup0nTTIJvxstjh+z7Lt9X5b2suuWn9KYebN
X5btfSkGYDN4Utc66jpUlQ71BF8ikejt27evX78uLS01MTGxtbW1s7MzMjKysLBgf+UFubi4ODs7
OyUlJTU1NTMzs7CwUCAQAJAkR2Gz2QUFBe/evUtISHj+/LkkSjaLxZKaIdra2ubl5Tk5OR06dIil
trMsfdTYpmFhYWSbTh6PN2DAAOr1DhsGkQj162PZMuqFMVQkKSmJbhEY5JkwX75EcDAIAk2b4vff
8eWerTry9u1bSbwbCfr6+pL8ewy0wyTkrIzM7ylGracv73dr5dU8ZF78fnzCgFlzJg9xdTSqpKSI
eemRF/7au/9qkhAALPsvn9ZazWxBVMlJebOyi8XiI0eObN26NT4+nqxwVIDNZkt2h8VisUTPE4tr
lx9b8imCIAwMDAQCQZMmTUxNTQcMGPD7778zkW6qpMY2Jd/A5XITEhKoL8dGRuLePbBYuHhRfVdH
NJotW7bQLQKDrBOmWPx5B7llS5w9C0tLBcRRVw1kY0QAGRkZTGRENUHu57UWw6pG/6gIwXsVuHzO
/qdStxUj+5btWjRxsK1jwmWLBSV5Welv45/Gv5e6a3Hbzdq3bUIzY/V+pFlYWBQWFkqOvby8Wrdu
vXfvXnpFCgkJmTVrVkZGhvSKvb09+bQCtra2WVlZla8bGBiU1eTRZ25uLvn3pUuJ69atW79+PbOC
KDctWrRISEiQHHfs2DElJSUrK+tri74ycu8eBg3CmDHQtGBKDAyK5P59LFwIJyecPaupL0vdu3d/
+PCh5LhBgwa5ubnv3r0zrxTLe9s2DBuGpk1VLh8DA4naPLdYxs0mbP9zzeDGnxYf+RnxEaEXz5wI
PHz4cOCJM5dCH31WEPUaD17753a1VxCVzalTp2p1v0gkmjJlypAhQ6QaoSyLeXpfsVuRZU2xpKQE
gJubW48ePVgsVlBQ0IYNGxgFsRpqbNPk5GTpcf369d3d3SkqiAA8PPD8OaMgVk12Nrp2perXfIPJ
bKgGVDO4bt5E06bw9ERMDO7cQWamKuVSJM+ePZMeN2/evFWrVpUVxKNHsWoVmATvKqa2z2tdoJaP
LpZhg/4r/ww+sHpir+aWVasRLMvmvSauPhD858p+DQx1XtMYXZvoBWVlZV27dv3nn3/IF42NjeWu
nRzIpgJcLrdhw4bdunWTmMJERESMHz+ez+cPHz5c7up0hOrbNC0tjbx2y2KxFBUZ0dFRIcVoIevW
ITKSanxEX19fBYnDID9VDq6QEDRoAF9fJCaCxULfvoiORv36qpdOAbx79664uFh6WjkyohSxGOW6
mp+MLmr1vNYR5PGb4li0HDDrxwGzyoveJ71OTH2fXcATiNlcYwub+g2aNmtSz5RxxpJiaWkp450C
gcDNze3JkyfSK4aGhgKBoFOnTqGhoZKkHVZWVjY2NgYGBgRBcLlcgiD09fX19PTS09MBeHl5lZaW
lpeXi8VisVhcVlYm2fG0tLTMy8szMzPjcDgA8vPzDQ0NRSJRWVmZqalpjx49AgICPD09GetDhVDB
ouXjx49M+HEGBjkgCJw6hQULkJUFggCbjaFD8dtvcHCgWzIKHDp0CACHwzE1NRWLxWlpabNnz6Zb
KAaGr0JFndMzq9+sU/1mCpNFG8nNzZXxzoEDB5IVRABeXl7Xrl2Li4vbuXNnx44d7e3ti4uLRSJR
fn5+eXl5UVFRaWkpn88vKSkRCASmpqZ8Pt/c3NzMzMzExMTExKROnTqSA1NTUzMzMx6PJ1lWZLFY
BgYGRuoWVVZzqN6ElxyFtV69ei9fvuxEISjLx48IDsbMmXIXoBNs3IiEBGzcSKkQ2YcqA3X4fP6h
Q4cePnyYk5MDgMPhbNy4sWPHjtLBFRyM6dORnw+CAIeD0aOxaxe0IBuo5B1SJBIVFBSwWKzY2FhF
7TMwUKcW7hk6A7PkpxasXbv25s2bbDZbYkHIYrFmzZp17ty5jRs3rl69WrL+R5HKJi8MyuDp06fS
49atW6emplaOfCYj5eVo1gxlZXB0xMCBCpJPG7Gxwc2bVAuRfcmfQW5EItGxY8d27tz5+PFjsrU0
l8sNCQmRPqE/fMDYsSgrA4eDKVOwbRu0I24dQRDkyIg+Pj4AzMzM6JOIgaEG1C8CvXYhi5FTVFSU
NDaKxLlh/vz5Z8+eDQwM/P777xWiIDIokGraVCwWk6Nn16lTh8pG8759KCoCAG9vuctgkJVZs2bR
LYI2c+vWrT59+hgbG0+aNCkmJkYSq0v6V0NDQwsLC3waXHZ22LoVa9ciNxcHD2qJggjg1KlT5SQb
Q6FQOHToUBrlYagAY5RcmdrEvtFSlBr7hhybukrKy8sdHBykioX0/lu3bvVU/2iwOkk1bfrkyZMO
HTpIT/39/T09PZcsWSJfRTweBg/G5s1wc5OvAIZaUONQZZCDhISEDRs2hISEFEled77k03duaGi4
giDM+PxlbLY2t0LPnj3v3LkjOTYwMDA1NY2NjXVycqp859GjmDgR1taoKqYZg7JgJoHKMHvNymVm
TaZky5cvJ688ubu737t3LyQkhFEQ1ZZq2vTs2bPk03fv3lExRjQ2Rmio3J9mqB2jRo2iWwTtITs7
++effz569OiHDx+quY3FYunpWQERpaXOQPmzZzVPmJqLSCSShkUE0Llz57KysioVRAa60OLuJzfM
XrNy2b9/fzV/zcrK2r17t/TU3Nzc2tp6/vz5gwYNUr5oDHJSTZtKFwkAODs7x8fHd9aU5A+azL17
MDLCvXuUCmFSLCiK+fPn169ff+fOnV9TECWZnPz8/DgcDotVoqeXyWYXtmy5u23bGiZMjWb37t2S
nKgSLCwsmI1mdUOLu5/cMDqicqk+Cez06dPJIQxHjRqVkJDwn//8R/lyMchPNTk9ydFxXVxcHB0d
5TNIZ7Y7asXRoygtxdGjdMvBAFy4cGHv3r3lVUX209fX79Wr1+DBUywser99+7ZLly4JCQllZfys
LHeBwPzFi8XQ6oS55IScderUef78+bBhw2iUh6EyWtz95IbZa1Yuzs7OX7NvSE1NvXjxovS0TZs2
N27cOHLkCBOVRs2xsrKqsk3Ly8slgTwkWFhYyOewsmsXjh/HtWtgPNFVCWOKRJ2ysrIJEyYQBFHh
y3R1dW3UqFFSUlJUlF9JySILC9GVK/pt2vz7VxOTzyV8bXBpOoGBgeR0qW5ubsXFxW2kX0FVsNn4
Sv4sBmWhrd2PCkwfpI158+ZJuqORkRGfz+/SpUtBQQETK0tziYyMJIfzKCsr69atW20LSUrC0qVg
sRATg6/kX2BgUFMGDRok8U2RzGwsFqtJkyaOjo6PHz9u1arVDz/859tvfXg8ODqyGzSgW1bVsnjx
Yukxh8NJTEzcs2dPNfePHInISIwdq3zJGBiqhdERlUtUVFSV1/Pz8y9fviw55vP5AP78809JWhQG
NedrbRoSEiI95nA46enpcqwj3rsHfX106MAoiKqGHPycQQ62bNlykxSm0sTEpKSkxNjYdNasWf7+
/pLtkdBQZGWhd++vFvK1waXR7Nixg7yI2K1bN7FY3Ldv32o+wuVi507lS8bwJVrZ/SjC6IjK5Wsu
Cxs3biRbIvbp08fExKRZMyZpjQbwtTa9R3KaaNq0aXx8fMeOHWtb+KRJMDfHkCHyi8cgH3369KFb
BA3m8OHDq1evJl/p1u2bmJhZ+vqt+vWD1Hym2s1V4OuDS3NJTk5esWIFAC6XKxAIDAwMsrKy/vvf
/9ItF0MVaF/3ow7js6Jctm7dWuX1gwcPSo+dnZ1fvHhBtmhmUGe+1qbx8fHS48aNGzdq1MiEbGkl
GywW/P3BxE1XPQcOHKBbBE3lxIkTU6dOJRlydbKwSLx5c1deXqvnz5GSUouivja4NBQej9etWzfJ
coBAIGCxWLa2tpaWlv3796dbNIYq0LLupxAYHVG5BAQEVL549epVadRuAG5ubs2aNWvVqpUK5WKQ
nyrbVCQSkR1WTE1NqWRYYVA9TJ4V+Vi7du3YsWM/WeK6A8+BqIKCJiwWq0sXREaiVovpVQ4uDUUg
EHTq1IkcAKhu3brp6elbtmyhUSqGatCm7qcoGB1RuVS5dr1582bpsYGBQUJCwqJFi1QoFAMlqmzT
uLg4ssNKaWlprbYtSktByvPMQANMvubakpeX17Vr102bNgHgcPoCb4C7QCsAjRqlxcfj0SO0bVu7
MrVmsy8vL69Dhw5kE3NjY+P27dvPmTOnlwy2xm/eoEEDMBqLitGa7qdAGB1RuVS2gRUKhQ8ePJCe
9urVKyMjw8/PT7VyMchPlXbNwcHB5NP09PQuXbrIXmaXLujdGxERVGVjkJvc3Fy6RdAYysvLV65c
aWdnFxkZCbgBaSLRFcAZIMzNw+fM2fb2rVPz5vKUrB1OAyEhIY6OjvHx8dKc1CwWa/jw4VlZWTt2
7JClhEePkJ6OQ4eUKSVDJbSj+ykWxmdF1Rw7dkwoFEpPLS0tR48ezWYzyrpmc/fuXemxk5PTq1ev
2rVrJ+Nnd+7E8+fgcNC0qXKEY2BQEB8+fFi7du3Jkyc/WctwgAuADUBYWNwqKJg0cmS/vXsP1lCK
9pKamjpx4kTpbMBisSShIidMmBAWFnbv3j1DQ0PZS2NC9THQDqMjKhdnZ+fExETylWPHjgEwNTUt
Li42MzOLiYk5fPgwTdIxyEPlNgXw4sUL6XGTJk0sLS2NjY1lKa2wECtXgiCwahWsrRUpp+4gyYlN
ITM2ALi6umrHKkJqauqpU6fCw8MzMzOLi4tLSkqsra0dHBwcHR1btGjRrl27jh07ytg5JYhEotDQ
0GPHjt24cSM9Pf3LIMMiYCLgN2BAZEzMlXXrVpADAcpBlYNLI7h37973339/+/Zt8vcjFotZLJaD
g8Pt27dv3rzZqFEj+gRkqBnN7X7Kg9ERlUvlXHy3b98GUFxcDKCoqKi0tLRr1640SMYgL1XmVyTH
PzM3N3d2dpaxtNGjIRTC2hrr1ytEOl3k22/RqBEoxq6Jjo5WkDj0kJ2dvWnTpkOHDpH94STx+dPT
0yO+tGNgs9mGhoZmZmampqYmJiampqbm5ubGxsYWFhYlJSUlJSW5ubl5eXn5+fmFhYV8Pv+T3qMH
zAHc9PUXCYX5kqIaNkzo0uVWRETEqVOnPD09Kf4X1ScvVUPevXu3fv36oKCgKtO42dra1q1bNzU1
NSoqigltpv5oXPdTAYyOqFwq5AhPTk6WRMyWwOFwpk6dqmqZGKhR2S0xMTGRHO1SdoeVhw9x7RpY
LJw7B8bcgArUgxuuXLlSEYLQQHFx8TfffHP69Gmy15QES0tLPp9vbm5eWlpKvi4Wi3k8Ho/HI3vd
fg0WiwVwgYXABsAIIITC8xxOsL6+fv/+/SMiIoyNjR89elSvXj3q/4um+PwmJCTs3LkzJCTk3bt3
0otsNpvcBH379n3//r2Li8udO3esrKzoEJOhdmhK91MljI6oXGbOnEk+JYdFBNC9e/ehQ4eqViIG
qlRWJi5dukQ+/fjxoyzGiASBoUNBEPD2hru7IiVkkAMNfTxcuHBh7NixPB6vmnsMDAxkLM3KyqqS
744hh/N9eflSQFKIANjq4vK0qMg2MzOzqKgoJCSkE8VtfhLqrKnn5+cHBgYGBQVFR0eTF2ulSBXE
tm3bNmzYMDw8fPPmzTNmzFCtmAzyo87djy6YtQvlcuPGDfIpWZlo3rz548ePqe/OMKiYCm2KLzOs
mJmZvXnzpq0MMT9+/hlZWdDTw5kzCpaQQQ40cZtpzZo1fn5+ZAVR6hJha2vbsWNHQ0NDNpstFAql
Dra1wRT4BSgsL18NcAG+re3u/v1He3ndyM7O9vHxefDgwY0bNxSoIKKqwUUvUVFRy5Yt69Kli4WF
haWl5fz588PCwqpUEAFwOBxJ2PyMjIxWrVrFx8czCqJmoW7dTx1g1hGVi6+vL9mE+dWrV9Lj5s2b
W1hYmJub0yEXg/xUaFMAz549kx43bdo0JyfHwsKi+kJyc/HDDyAI/PwzarqXoWYOHMCXS/a1xtnZ
mdAcP1KCIEaPHn369OkK1+3s7FJSUnr37h0ZGZmVlWVgYNCuXbuUlBSCILhcbp06dSTeVFwuF4BA
IODz+aWlpaWlpTweT6JHcjgcY+P6ItFPfP4EgtADwGLxCOL7+vVPA0JLy15jxviPHDnS1NRUGf9X
5cGlSgiCePr06fnz5+/evfvs2bOPHz+SbUiqoWXLls2bN09LS3vy5MnKlSuXLl1qa2urbGkZFA69
3U89YXRE1VFWViZxVZHAZrNlCabKoP6kpaVJj21tbe3t7Wv8yLBhEIlQvz6WLVOmZLrBli1YtQq5
uboSc5isIOrp6YnFYrFY7OjoOGDAgAsXLvTp02fmzJlnz56t8KIiEokyMzNTU1PfvXuXnp6enp6e
m5tbVFSUn59fVFRUXFxcVFSUmpoKQCQ6zeN1BVhcLr9nz0s+Pm9btPBq23ZekyZN6PmHlYZAILh9
+/bly5cjIiJev36dk5NT2aazGtq1a+fs7FxUVBQVFdW+ffuNGzf269ePw2TSZNAiGB1RuZCNe8LC
wsh/ysrKmjJlisolYqBKBYMtoVBIVv319PRq3GjOzcWTJ2CzERICefYAGb4kNfXzb7nRoJgXM2bM
kK4glpeX6+npGRoaNmzY8MWLF1evXv2aLSyHw3FwcHBwcKix/AMHsHkzfvwREyYYsVgjFCl6TSg7
krlYLI6Ojj516lRoaOibN28KCgpqW4KtrW379u1NTEySk5NTU1ObN28+efLk06dP17h1wKD+MIH0
K8PoiMqFnODr+vXr0mN9ff23b98q1pSHQTVUSNoWHh5O3p4oKSmpUUe0skJwMEpLqYb0Y1AgmrJI
tmPHjgqubyNGjPh/e/cd19TZ9gH8yg5bwhCQoQJu64NFkApYB24UHG1tHXVhtVZrHUVr1draqtXW
Wmvdtfq2j6P6WFs3bm0Vxb2QoQwFQfYm47x/ROMhODAQTsbv+4efk5skXPHKCVfuc49t27b16NFj
zpw5OqzGn55Oe/dSVNTTrytRUbW9cK8zfeyIqFQqT5w4sWXLllOnTqWkpCgUild9hqZNm7q7u4tE
ouzs7MTExPz8/Ndff33y5MmhoaFCoV7+hvr4kL09demij+eG58KGnNWhRtSvt956a/v27erjS5cu
adp9fX3T0tI8PDw4igt0x84pER08eJD90wcPHtRkwgpGGRia6Ohow5/afObMmelVRyeMGzfuwIED
GzZsGD169Ks+W2IiRUXRiRPE51NxMU2bVneB6krr5KqN9PT0NWvWbN++XWtpqpfi8XiNGzf28vKy
tLQsKChISEgoKytzcHAICgrq2LGjv7+/hYVFnUT4AgEB9M8/VIM+X6hLdfj2MxmoEfVrx44dmmP2
xEk3NzcbGxudJhsCx9g5JaLz589rjj08PNLS0lq0aFHvQUFtLV682MBrxLy8vF69erE7rSMjI48f
Pz5z5sxXLRBv3KCxY5/uD+7jQxMn1mGkutM6uXRQUFCwdOnSX375hb1y4YuJxeLmzZu7urpKJJLi
4uJ79+5lZ2e7ubk1a9YsICCgU6dOnp6etYxKB7pteA21Ufu3n+lBjahfQ4YM0Ryzt+JQjx/iIiKo
LXZOqepcdQ8PjwYNGohEouc9NiuLnJ31GBvorHvtl+HWs+7du7NHvgYFBd26dWv8+PGTJk2q+ZNc
vEhjx9Lly8QwxONRmza0YQN16KCHcHWidXK9krNnz37yySdnz57VlNECgeCZHRfFSQAAIABJREFU
PYhCobBVq1Zubm5CoTA/Pz8pKen+/fvOzs4tWrTw8/P7z3/+06xZM0w9MUO1efuZKtSI+qXpuGYY
hr3DikKhaNWqFUdBQa1oXYxg71RhbW39gi1Z9++ngQNpxgxasEB/0YGO2MOFDdDnn39+8eJFzU1X
V1cLC4vAwMBpNb5CfOYMRUXRrVuPb3boQBs2UA2GRdQr3a707d+/f8qUKQkJCVrt7AJRKpUGBga6
ubkplcqkpKT4+Hh7e/vg4OAOHTr4+flx0lMIhgYXmqtDjahfeXl56mGwqamp7ItERUVFuCJpAioq
Kti7nPF4vOcNRlQo6O23qaKCnrWtK8CLxMXFLVmyRLPVm0AgCA8Pv3nz5rffflvDZ5g7l7766nHf
YUgIrVtHprF78JkzZ0aMGPHS9c8jIyOTk5MvXbokFotDQkImTZoUEBBQ8+1nOPHbb9S5M7m7cx0H
mDfUiPolk8nUpSG7D4CIcnJy3HH2Gycej6cp90+dOsX+UXFxccuWLZ/5qI8/pqIikkqpxn/WoV49
axs6g1BRUdGjR4/KykoejycSieRy+YgRI/7888/z58/XfFKtrS2JRPTmm7RmDT2/p5t77JPrxR49
evT2228fPXr0mT9t2rRpUFBQfn7+3r17fXx8AgMDZ8yY4e/v/4JxIAZlzx4aPZq8venmTa5DMSc1
f/uZD9SI9eTGjRuaY0tLy8zMTNSIJuD48ePsmw8ePHhmjZiaSj//TES0di092SwNDEueoXbwhoeH
q4tXhmEUCgWPx/vll1/+/vvvF6yKwDAUG0uBgU9bpk+nkSPJZPb+WLVq1dSpUysrK6nq33U+n9+j
Rw8bG5vjx4+npKS8++67mzdvlslknAari+JiksuJNYIdgBuoEfVLM8iJPVbGw8MjPT3dGD+5gKoO
XGN3D7u5uWVmZj5zmb0+fYhhqHlzGj68PiIEHaxZs4brEJ7hxx9/ZL/fbG1tS0pKpkyZ0rdv3+c9
JD6egoKotJSWLKHJk5+2G0WB+NJRoTk5OT179oyLi9O0iMXiyspKgUAQGRlJREePHh01alRsbOwL
RgYDPJOBD0rmBGpE/dJMlrx3756m0dHREaveGC/2BNj4+HjNsZeXl0wmq375b9u2xxeM9u2rl/jM
T3Q0HTxY2434orhaNvr5zp8/P3XqVHZLv379kpKSvvnmmxc8KjqaCgpIIKCAAD3Hpwcvnl3+77//
hoWFlZSUsBsrKirUc5BPnDgxceLE1atX4+s36MbwFzeof6+8KD+8krVr16oPMjIyNI3W1ta40Gy8
NDmlqpOa7ezsql9orqig0aOJYWjMGDKSjTyMj6cnJSVRLWemGtrSaPfv3+/cuTN7Zm5ERERMTMzW
rVtfPKhuxw76/nvKyaGOHfUfZV1jn1xa1q1bFxwcrFUgNm/efMKECUqlcsGCBYmJifPmzUOBCDp7
wdvPbKFG1K/x48erD9jD4SUSCXZYMV6anCoUCvZfLIFAUH2u+vjxVFpKVla0alX9RQg6eOutt7gO
4an8/Py2bduyV8t67bXXrly5snr1ava6quXlNHcuNWpEZ88+faxQSJMnk41NfcZbZzQnl5aZM2dG
RUWpp3WrCQSC0aNH29jYxMfHJyUlzZo1y8ZIXzMYjOe9/cwZrjXrl2Z0GnvxW5VKhX5E46XJ6dWr
V9ntpaWlWv2ICQm0ZQvxeLRlCxnJfErgXm5ubqtWrdhzaJycnGQy2ZtvvhkREcG+5+ef07JlRET7
9hllr2F1zxzOO2rUqE2bNrFbXF1dw8PDd+/e/c0334waNQpDd6BOGMum7fUJNaJ+JSUlqQ/UU/A0
x6gRjZcmp0eOHGG3Z2RkaPUjzp5NDEOvvUaRkfUXHujGQNa8OHz4cGRkJLt/WiwWt2/fXiAQVF8N
cdAg2rmTJk+mV9lpxaBpTi6NCRMmbNq0iT15OTAw0MXF5fr165cvX3Z1da33GMFkVX/7Aa4114eH
Dx9qLaCNGtEEsCdX2trapqSkNK+6x+rSpTR0KD1nBTeoM7dvk5MT3b7NdRy1U1xc3Ldv3549e5aU
lAiFQnXfmEAg6NGjR0lJyY4dO4qKxN98Q6wvm9SxIyUn08cfU43XSTQyixYtWr16tfpYPTElPDxc
IBBYWFgcOXIEBSKAvpnoR4vB8Pf3v3DhwvXr19mNeXl5GI9ovNQ5JaLbrKrE09OzuLjY0tKSfU8v
L/rtt/oOzwytWEGPHtGKFbUa9BkWFlbnK1/cvn179+7d165dy8jIqKysrKysbNSokbe3d4cOHdq0
adOkSRNLS8uEhIRDhw5t3bo1Li5OMwBRoVAIBAKGYcLDw+/evbtjx8mRIy137SKGoYsXycBm19Ql
zclFRPv27Zs9e7b6mGEYlUrVoEGD27dvDx48eOHChbi+DHWO/fYDNdSI+qXuarp27ZqmRSwWZ2Rk
oEY0Xpruw/T0dE2jo6MjcmrUYmJi6uR5VCrV/v37lyxZEhsby96nUb2TnnpzFIVCUf2BYrGYfdPW
1jYvL2/fvushITdatBCrVMTjkYsLLV1aJ2EaKM3JlZaWNnDgQPbll27dusXExCxZsmTcuHEcRVev
eDzi4zpf/WJfGgI1vAf169NPPyWiW7duaVoaNmyo/kLMXVBQK+qcElFBQYGmUSqV+vj4qI+fVQCA
oav9+oilpaWzZs2yt7fv16/fyZMnKyoq2D/VnPKeTxbp0bpUKpfLNceBgYGNG3dv0OCSQpFw9KiY
YcjLi/btowcPiDWt2QSpTy6GYbp06cL+D+zcufOjR4/Mp0Ds1Yv696cVK7iOw8xoPttBA/2I+rVo
0SKquoC2vb29ra0tZwFBralzmp+fz+4NUqlUzZo1Ux8PGEBE9McfZGHBRXygk9rss6JQKBYsWPDD
Dz8UFhZqGu3s7PLz86vf+dGjR898EoZhxGKxUCjs1GncsWPDlMrXiXhE5OtL69dTSIjO0RkT9ck1
f/589uwBX19fGxubpk2bzpgxg7vQ6pVMRv/7H9dBmB/12w/Y0I+oX+q+6/v372tarKysPGu52i9w
Sp3TU6dOsRsLCwvV/YjLl9P+/XTkCJWWchMe6Ebn/ZpPnTrl4eHx5ZdfFhUVsds1Nx0dHdu2bcvj
8SQSiUwmY9eRGtbW1sHBwTKZrLS0Z0zMdwqFPxGvTRuKjaX4eHMpEIkoLi4uMzPz66+/1rRIJJKQ
kJDCwkLN5BUAPcG15upQI+qXv78/Ve05EIvF2EjUqKlzepa9bDFRRkaGr69vURHNnEkMQzNnkoMD
R/GBTnTYn6OiomLo0KGhoaGZmZlUdfUca2vr/v37E5Gnp6ednV1CQkJ+fj7DMPwnQ8x8fHzU62H5
+fn5+vryeLyysrKJEydu3PijpSU/IICuXKGrV8nfv25enbHw9/cfO3Ysu4d+5MiRR48e/eOPP7TG
awLUOX9zO99qANea6wN74BrDMOhHNAHsuequrq4PHz708vIKDye5nBwcaP587iKDenHjxo0uXbpk
Z2ezGy0tLSsqKsaMGXP37t3Tp0/PmDGjS5cuPj4+jRs31mygV1lZmZWVlZ6enpWVpVKpkpPduna1
9PJqZG9vr75DZCSZ83Dlfax9zdu1a3fmzJnly5c7OTlxGBKA2UI/on6pR9WwB1+Xl5ejH9GoqXOa
mJioaXFzc/Py8oqLEx48SDwe7d6NCYnG55XWvFi9enW7du20CkQ7O7shQ4Yolcq4uLhhw4alpqYu
WbKkd+/evr6+7B2WxWKxu7t7x44dVar+kyZFREcHLFvWRlMgEpl1gRgQEMDujg0LC3NychqgHuFr
TlJT6T//ocWLuY7DzGAN7erQj6hfTZs2vXv3LvtTr7CwEP2IRk29X5P68qJagwYNXFxc+vcnhqEu
XSg4mLvgQFevv/56Te6mVCqHDh26o9oShX369JFKpSdPnty/f3+vXr1e8AwMQ9u20eTJ9OgRMQzx
+dS5s+5hm5KsrKy4uDj1WtlKpbJbt26///77X3/9xXVcHDh9mq5do4wMwkTb+oS9+KpDd4d+jR8/
/vz58+yWrKws9CMatejoaCJizzwQi8W5uT7Z2SQU0q5d3EUGtbC4Bp02ubm5nTp10ioQbW1tP/jg
gwsXLnh7e1+/fv0FBaJKRRs3koMDvfsuZWcTn0/DhlFmJo0dWwfxm4CFCxcqnxCJRAkJCT169Gjf
vj3XcXFALCY+n6ouyQ96p/5sBzbUiPq1du3aS5cuaW5KJJKysjIXFxcOQ4JaWrx4cUFBAXtYfWmp
/Ny5ZgxDCxea9YVCrqj75WvZO//SPw/Xr19v0qTJuXPn2I1+fn5du3Y9ffr0oUOHlixZYvmcv+oK
Ba1cSQ0a0NixlJdHAgFFRVF2Nm3ZQhhop7F161bNsa2tbWpq6hdffMFhPBwaPJg2baKqayeA3tXk
i6K5wbVm/erevTt7coObm5tUKuVjtJox6969u9ak5osXC1Uqb1dXMpvl2wxLdDTJZFTLNbBffK15
586d77zzjvqLgUgkUiqVKpVq8ODB8fHxdnZ2586de151SERpadS2LRUWEsOQSEQTJ9KXX5KNTa2i
NT0JCQlZWVmamwMHDkxISDDnYTnvvcd1BOane/fuXIdgcFCs6Nfhw4eTk5M1Nx/lq2Tu5vupZxoO
Hz5ctUbkyW15wcFfef/nu1sVz30U6FWtN0mpPmdFcX/byJCQkJAB330w6/MhQ4Zoeo7lcjmfz5dK
padOnZo4ceKmTZteUCAS0blzpFSSWEyzZlF+Pi1fjgLxGX799VfNMY/HKyoqioiIYGfhZvkLHg1Q
B+p8x3YTgH5EvWMvoC0USht5NeYuFqgb7A24ZTJZOU9BJCLRCx4BRolhmFvnNpzec5PdaG9vHxoa
euDAgT179gQEBFR/VHExWViQQPD45uDB5OZG/v6EBf5eYPfu3ZpjPz+/o0ePYtMLAM6hH1G/tLdV
4PHcGzfhLhyoAzKZjN037O7eyM0e5aHR8/b21mopKKm4ePFi7sMqBaKPj09QUFBWVta9e/eqF4gF
BTRhAjk50ccfV2l/4w0UiC9x584dzbGvr6+Hh4eXaW9N/TIPHlA5uk7rlw4L6Zs81Ij6lZeXx174
RiEv827RisN4oPby8vLYC9/Y29t7yFAjciwmprbPwK77iSgu7mLAhzvLysrYjR07drS0tHR0dDx2
7JjWzLOcHBo5khwcaPVqqqig9PTaxmNW0tLS5HK55mZlZWW/fv04jIdzsbHUti0NH851HGZG5w05
TRhqRP3q27cv+2Z5SU6r9jVahg0M1vbt2/Pz8zU3pVKpuwP6iLi0fj2FhdH69bV6EvaVzcWLF7/x
RkhJuYJ9h/79+6empg4fPvzXX3+VSCSa9owMGjSInJ1p82ZSqcjRkTZvxhJIr+bkyZPsmzk5Oc+8
iG8+EhMpL4+OH+c6DjOzfft2rkMwOKgR9Ys9U8/S0pLH5zu7unEYD9Te4MGDy1kXgXg8nrs9akQu
Xbz49F+dffrpp0RUVFTUsWPH6OhouVzO4/HUPxIIBO+99965c+fWrVs3ffp0zUNSU6lPH3J3p127
iGHIzY3++IOys2nYMHryUKiR2NhYzbFIJCooKHB1deUwHs55epKNDXXowHUcZmbIkCFch2BwUCPq
F3vhG7FYbG3XiMNgoE6sWrWKPX6goqLCHdeaOdWjx9N/dRYTE7Nt27aGDRuqV0BkGIbPIyISiq3C
IgadPXv22LFjffr0Ud+ZYahfP2rShA4cIIYhLy/av5/u36eBA2v3SszV3bt3Nceurq4ZGRlubmb9
XTo4mI4cod9/5zoOM1N9/6R6Nm7cOIFAMH78eMPZFRA1oh5lZmayxzPx+XwrO3cO44E6MWnSJPbN
3NxcD1xr5lREBCUlUUSE7s+QmJgYFhb2zjvvsE9YpYohIqW8LC/nUWxsbMuWLTU/2r2bDh0ihqFm
zejECbp3j3r2rMULMHvscWAODg55eXlOZr+2uL8/FuSvb2+99Ra3AVy7dk2lUq1du7ZZs2bOzs6G
UCyiRtSj77//nn2zsrLSVtaYo1hAL3g8XmbmQ3cZakSO6bzPamJiYufOnZs1a6bVzuPxenXwJCIX
r47r/jqoNeFxwAD6+Wc6f55u36aQEB1/NWiUlJRojoVCobOzMzYaADOkGd+iUqmys7MNoVjEeahH
u1gD192drMrKyuwctNfXAKMTHh6uOXZxccnPz3eywTqjRikpKcnX1/fkyZPswQNE5OzsHBHR/3LS
o9atW3u/NujyOWFAAM2d+/QOfD6NGUMv3JkFXoFcLpdIJM7Ozg0bNkxNTdVKB0D9MMA3HufFIs8A
/1PYTpw4MX78eL1+p4yPj1epVOpjS0tLiURSJ/spq1Sq+Ph4zU1LqbBCzkgsHFzcHSQYz27MkpOT
Kyoeb6gilUpVKpWnk8WDPDnxrZFc46JUKtnL8qlZW1tXVlZKpVJHK8osUKioQUWZnXobPW9vTEbR
i5ycHPb0Pmtraw8PDyIiYuSFGeZ5chUVkYUFCfH105zcu3dPa72t6vh8voODQ2Rk5MyZM6uv6lr3
GMP24Ycf6v2/AAAAAMB48Pl8JyenqKioxMRE/dVguNYMAAAAYEzYl6FlMtnChQv18VvQkQ0AAABg
TPh8focOHdzd3e/duxcXF3ft2jV9/BZDrxHt7OykUmmrVnrcv+7KlStKpVJ9bG1tbWFh8WQoTB1i
5Hkpd7MrSdDAs4mzFL23RqiykhISyMKi+hRaJNe4MQyjUqkEAkFZGSUkkFJJjRqRszPSagiQBTAj
8fHx7Dn+z6QpDdPS0hITE1u2bLlgwYLu3buL9bMlvKHXiB999NHff/+t1522eaxR6CKRSCKR6OHX
MRXyTGGeikSWdjKZFT7pjJOTE/H51WctILmmw86OLCxIICCk1TAgC2BGhM+fo1S9NJw3b57+SkMN
Q5/XXA/s7OwKCwvVx6Ghoa1bt161alVd/xLF/W1j3lmZTLLINds+aSWt66cHLiG5JglpNQTIApiR
oKCgs2fPslvYpWFSUlJ4ePiQIUPqoTTUMPR+RAAAAADzwVWvYXWoEQEAAAA4xuPx3NzcgoKCOC8N
NVAjAgAAAHBs7NixY8aMsbGx4bw01ECNCAAAAMCx0aNHjxw5UiAQcB3IU5gnBgAAAMA9gyoQCTUi
AAAAAFSHGhEAAAAAtKFGBAAAAABtqBEBAAAAQBtqRAAAAADQhhoRAAAAALRhfcT6wbdu1mNQ/wcq
WXsZ/stNDZJrkpBWQ4AsAHCJxzAM1zFwzM7OrrCwUH0cGhraunXrVatWcRsSAAAAALdwrRkAAAAA
tKFGBAAAAABtqBE5p3q454PQkJCQkHd/uSvnOhh4Jcid6UFODQGyAGAQUCNyTfHg+P9uMETkMyDM
Q8R1NPAqkDvTg5waAmQBwDCgRuSYPO3wn4lExGszsIsbJu4ZFeTO9CCnhgBZADAQqBG5VXl33940
IhK2H9jJEckwKsid6UFODQGyAGAocAJyqjz+z0MPiUjacXCAPXJhVJA704OcGgJkAcBg4AzkUsm1
/x3NJSKbkEF+djyuo4FXgdyZHuTUECALAIYDYz30Q1GQcHrvvuPnLl6NT8sukRORVObV3C+4Z+Sg
Xq85iXhEREzBpV2niolI1jWyjVXVx8uz/t301ZebLxUROQVPmPfp2+0aCOr/VZgn5M70IKeGAFkA
MDaoEesaU55+YuOS7/57Ka9qe3luypUjKVdSHV5fN8RNQESqvNg/zpYTUcOe/ZtLWU9Qmnzgxy+W
/J2sIFHTfjPmfdSrqSW+TdcL5M70IKeGAFkAME6oEetURdr+JdO+PpRBRGTbolvf7kHtfFztJMri
h/duxB7bd+Ca88DOLuqvvqrs0zsvKojIo1+fJuLHj1fmXdm2+Iufz2QT2bYfOeezkUHOWPihniB3
pgc5NQTIAoDRQo1YdypTd8+JWna2hMiy3bC5c0Z1chFrftbGr2O3yJEfZuSJH8/Te7oAWESYu4iI
mIr7J9d+uXD7jTIit24fz58W2dIGo0XrC3JnepBTQ4AsABgz1Ih1RFV08adpy86WENmFzlo9r4+7
uPp9hLauTo8PWQuAvekqVBXf3vP9F98dSmdI2nLwrLnju7hLcSGl3iB3pgc5NQTIAoCRQ41YJ5ji
y6sX7MokIvehi2b3ftZHYRVPFgATvT4wgC5snLbglwsFRLKOUfNmDW0vQ1LqE3JnepBTQ4AsABg9
nHh1QZ6ya/meHCKS9Z85srXVS7/sPlkAjFxtT336zrEkOfG9es+YP6WPjxUupNQz5M70IKeGAFkA
MH6oEetAybXft98lImr23rttX/5ZqFkAjCj16DEiIt8Jm35+t4lEnzHCsyF3pgc5NQTIAoAJwBe0
WmOKru46XkBE/HaDu7q+vOjWLABm1TaokbopYW9MSrleg4RnQu5MD3JqCJAFAJOAGpEcHR2dnZ2D
goKCgoJOnjz5yo+vSDp6sYyIqHFouxrsHKVZAMyp7+TP5r3rTkREqZsX7UyRv/KvhlpC7kwPcmoI
kAUAk4Aakc6dO7dy5cqpU6dOnTp1+/btS5cufaWHK3Pu3CkiIhK5eNq9fNV/zQJg7v36etu1GBEd
qZ7Ul7B+yd8PFK8ePdQCcmd6kFNDgCwAmAbUiOTo6DiExdLS8pUerizNLSUiIkVxUSXzsntrFgDz
HtDDU0Q8q7ZjZva0IyJSXF21LCZbqcMLAF0hd6YHOTUEyAKAaUCNWFtCWxc7IiJiru84lFb9yoiy
JPtRuerxDc0CYK0iu7gJiYj4dgETp4VaERGVxy5fcTpXVe0ZQF+QO9ODnBoCZAHANKBGrC2+g38P
XyIiUt1aGfXRkv/GxF6PT7h9/eKZQzs3LJ4+csDwNfeUj/+bnywAJvQbFOL05L+eLwudPLmDhIio
5Piy1RcKq30eVib8PCSk94LzJfXygsyI4eROkf3P5m8/mzQiomtISEjIsC2pGIalI8PJKVFl5r/b
ls/+4O3enUNCQkLCBkbN33wuyywya0hZUBVd+XXexGEDwkJDQkJCQnu9/eHX2y7lom8SoCaw9k2t
CRv1nzX+2Pg11+VEJTf+WnXjryo/lkXMaGOlPnyyAJi04+BA9jhuQcMen3zw17Afrispb//ijX03
T2nHXitC/uBCvKTNgCFtrfT/YsxMfedOWV5SzkgsLYTaS4EoMk79GXPTulmrN1rFnbhZ9y/UjHBw
Pj4nrcrcf9at+qusfffID4a6WZbdO7Nr27rpl9OX/BodZGfqX84NJwtE5Q9T8u3a9h4R2chBIn90
5+Su/62cfD137cYJLaV1/KoBTA6PYV46WgReiqnMjN3569b9/1y9m1tJRCRp0KhxszbtA0O6dnuj
uYOIR0RUcn7B4E8OF5N12Hd/zO2gVfBV3t0yfsTaRCIij+HrN0Y1x8dXPanH3JXGzu4/PX/WXz91
s9P+O8aoGB6fR4r728a8s1IZ9dsvwz1Fdfs6zUn9no/PSytTnp1SaOPl/GQHOVXukVlvz/+n6ae7
fu7nZOpFIhlKFqpRPtgx7u0V2eE/75jZBp+yAC/BgEFTFZyeHRY8dGNyJdeRwKuqlruSc7O6hUyI
yVc99yHy9K0jgoPf25yCdBumZ52PL0/rY4oHO94PDn5rbRKyWzu1ygJTcOKTN4P7LrpapscIAUyE
GXybNWqqvPO7/i3zHhDmgV4lY4PcmZ5a5VRVeDs2jcRezR0wxKdWdMkCo6goKystzk2/8uePK2NV
PgMH+qITEeCl8GFl0FQ5/+y8oGw97U03JMrYPM7d1ECr4vx8dVNZcaWKUZTk5+cz6sthPJGVjZUI
X9SMheZ8dKXSgvwni7rULK2qvH9WLf+3wmPYqICXXAyFF9MlC8qMXVFv/5hMRESiZkOXLnsfJSJA
DaD0MGTKzBO7rgn85gabw+glE/M4d59arxoU/m+VuazfDuv/7ZPjlrN2r+7jgOwah6fnY3ncrMjp
/9Q8rUzprS3Rcw+Utp/8w/uYKVE7OmWB79h1zkrfosqS7IQzf/zy3+lTaMVPH7SzxpkH8GKoEQ2Y
PD1md4I08JuAGmxmBYblSe46+bu4LRskV/d1lN/eMHd9ydD5H/lZq7s6BLY+tsitsWCdjxYtxi1d
NrCGaWXKErdFT15/x2fUyq8HN5ZwEboJ0S0LPLGjbztHIqIOnUJaC4dO+u8P+yPWDXF7+R4wAGYN
NaLhqry3768U65Apfrg0ZXQ0ubNvYGUf4PO4tZT3p4gn9PUPDERKjU+V89HOp33N0sqUJ+/87MOf
rri9u3zp+62tkPda0i0LbDwLr3ZutPtBSq6cUCMCvBg6MQxW+Z09BzLtu0ZgWUTjg9yZHp1yWpHy
59yJP5x3HPTtD+P90GVcezpkgVFVXX9blXfp2F0iZx9HcV1HB2By0I9oqEpu7j6a69ynfwuMXjI6
OuROnn35zJVHClVufAGRKuGfozF3BEJZ207tG2JStEHQIaeq3FOLP1r2b4lbz9EtCy8cjVG38qTu
/m+0MPlFtPVDhywo7v8x9bMzDf3beTdythWWZlw/sWf/1RKXiPFdnZEDgJdBjWiYmMLLO08Wegzt
0xTfdY2NTrkru7H+8y+uPLl17KevjhFRm8/3rOphj8uT3NMpp8q8W9fziOjBwR+/Ovi02abXyl2f
tcNXv1enUxb4dq2CW507eGz7kewSBZHEwdtv4LSRo8LboFsX4OWwzwoAAAAAaMNXKQAAAADQhhoR
AAAAALShRgQAAAAAbagRAQAAAEAbakQAAAAA0IYaEQAAAAC0oUYEAAAAAG2oEQEAAABAG2pEAAAA
ANCGGhEAAAAAtKFGBAAAAABtqBEBAAAAQBtqRAAAAADQhhoRAAAAALShRgQAAAAAbagRAQAAAEAb
akQAAAAA0IYaEQAAAAC0oUYEAAAAAG2oEQEAAABAG2pEAAAAANCGGhGfeu+kAAAErElEQVQAAAAA
tKFGBAAAAABtqBEBAAAAQBtqRAAAAADQhhoRAAAAALShRgQAQ1dyekpoSEjIgO9ulnMdCgCA2UCN
CAAAAADaeAzDcB0DAICGPGXTyGEbhBP/u3Gou1DdpCrNTMkoYUQNGnk4SHjchgcAYC6EXAcAAMDC
FCfE3SfyYrfxLV2aeHMVEACAmcK1ZgAwJBWpsckqroMAAABcawYAQ1ESO6v/tNOV7CZZxOpt01or
T0/pPesiI4tcs+2TVlIq+Xda35mxSu/J29f1Lti7auVvh69klhPfxiug/7hPxnR2FSkeXdi2au3O
E7eyK0lo7/NG5AdThwc6Vr1qIs+5su/3rXtPXorPLFERSRyatgvu++7IyNedRPX6ogEADBWuNQOA
gRDatwntWHT7wpV0BQkatXvdw0Lk2MxWQKSsej+eQCIkUlbm3dry8Re/xEucPb1cclMyi1LO/jbn
Y+XP3722e+Lsg7lWLp6eDXNSH+Ylntw4PY02rR/lLX78BEzJrf+LnrL2chkR396zedMG/KK0+OTY
P3+M3Xd0zMplI1tZYdAjAABqRAAwEBLf9+Yt6rpjzFsrkshzQPRizZyVSq07CoR8IsrY9/0u1xEr
9rzvZy8gVX7s96On7c5+sOOL6X+V+U5eN39QC2s+KXNOLxo960Du3V077wyd2UZKRMQUX1wZvfZy
Gbn2mbtsancPKY+ImLJ7+xd//M2RGxvmrPbb8kk7VIkAYPYwHhEAjAyPx+cRkSLHZdTn7/vZC4iI
+A3aD4n0IiJl5sMWk6MHtbDmExEJHALf6etGRPm37+Srhzmqso6u25tL5DZ84Sdh6gKRiHgWjXtP
n9PLjih77+bzBRiCAwCAGhEAjJRv704uAs0toayJE5+IqEUff9nTTzahQxMZEVFpbqmSiEiVf/XQ
LYbItVu3xpIqT8ezbtnDz4JIfutMSkU9hA8AYNhwrRkAjJPU1d2W/S2XJ5IIiSpt3Rtaspp5QqmI
iEgpVzJERPKs2w9URJS5f8GEWK3pKaryjDIiKkpJL1a1k+IbNACYN9SIAGCcBBJR1UGDPB4RkVAi
fEarhqo0r5SIiHmUHP/oOc9cVlCuwlUWADB3qBEBwKzw1EVji5m71oQ7oQ4EAHgefEICgDkRWDtY
ExEVPSxSvuy+AADmDDUiAJgTkXPLRgIiyricWIT9XAAAng81IgAYFPXwQZVCpZ/1Z3g2bcJa84lU
V7bHPFBU+ZEq68CsEeNm/bgf05oBAFAjAoBB4YmtJERED2/cLdFPNx/fsfOYvjIiil/52c//ZMkf
N8uzz62dvfj03dtn7yilGKgNAIA5KwBgSPi2zTu408308jNzBkY42QndR/70fYRtnf4KnrXfh4vG
3v1o/fXk7Z8O+tPFx8dJUpaZkJxdSUSO3WfP6dVQ8NInAQAweehHBABDImo8dO7EYHcJkTwvu1Tq
YCeu+13xeFYtR67Y+sPHA4N8HHmZiTeu3UjOEbm16f7+/F//7/OwhvjqDABARDyGwaZTAAAAAFAF
+hEBAAAAQBtqRAAAAADQhhoRAAAAALShRgQAAAAAbagRAQAAAEAbakQAAAAA0Pb/rUFzUJorZIsA
AAAASUVORK5CYII=
--bcaec501655751d1f904ccd188f0
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--bcaec501655751d1f904ccd188f0--


From xen-devel-bounces@lists.xen.org Wed Oct 24 17:37:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 17:37:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR4t2-0007PD-N6; Wed, 24 Oct 2012 17:37:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR4t0-0007Ow-AA
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 17:36:59 +0000
Received: from [85.158.139.211:41957] by server-4.bemta-5.messagelabs.com id
	B3/90-01455-93728805; Wed, 24 Oct 2012 17:36:57 +0000
X-Env-Sender: jefranca@gmail.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1351100214!23626333!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21058 invoked from network); 24 Oct 2012 17:36:56 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 17:36:56 -0000
Received: by mail-vc0-f173.google.com with SMTP id fl15so68142vcb.32
	for ; Wed, 24 Oct 2012 10:36:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=SEBgB/8zHhAsOXb+SgiHQsWuem34c0gJ932lNyrBjXs=;
	b=MBWiWGmbCPNADWnd9JY3JpAjYMDxUU1fJGQSeA1BJyoPF+Ojuyw7BmJJAk1Xc3M8Uu
	9fbOMcCtvLAAeXHK7WDspzUHzN0ym0IAkSRg5jDoySwLBZ1bsZIwvvqqyWKwA3cn/HlK
	GTab7fzRLecyhtFnK3I+6sMqD9KvdK+tFbDW9EW5xxFLoqPsOl74YFTfRiTBFWod0git
	raxb/y+ZR6tZOLjs3EJ4qpJfQ18iKfejdhLZ2wxBjSX9Q9Q3DRhr6Zcw6XXMjTuvN/AE
	jKrD+4mOVgYRiq72FDPqPS5DCM7bOyj2LKuLP6mGFTW1KRBZ8yfDVI3fHiJwS5zM9IYy
	UQmw==
MIME-Version: 1.0
Received: by 10.52.72.132 with SMTP id d4mr14884180vdv.91.1351100214137; Wed,
	24 Oct 2012 10:36:54 -0700 (PDT)
Received: by 10.58.13.9 with HTTP; Wed, 24 Oct 2012 10:36:53 -0700 (PDT)
In-Reply-To: 
References: 
	<75A1D5EB-12C7-4829-A3F7-4D77B2405FBB@gmail.com>
	
	
	
Date: Wed, 24 Oct 2012 15:36:53 -0200
Message-ID: 
From: =?ISO-8859-1?Q?Jos=E9_Eduardo_Fran=E7a?= 
To: xen-devel@lists.xen.org
Content-Type: multipart/mixed; boundary=bcaec501655751d1f904ccd188f0
Subject: [Xen-devel] Fwd:  How to get the checkpoint size in remus code?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--bcaec501655751d1f904ccd188f0
Content-Type: multipart/alternative; boundary=bcaec501655751d1f504ccd188ee

--bcaec501655751d1f504ccd188ee
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

---------- Forwarded message ----------
From: Jos=E9 Eduardo Fran=E7a 
Date: 2012/10/17
Subject: Re: [Xen-devel] How to get the checkpoint size in remus code?
To: rshriram@cs.ubc.ca


Hi Shriram,

Thank you for your reply. I'm sorry coz I saw your email yesterday and my
English is bad.
Ok... I saw your patch but I need to explain more my problem.

In my master research, I intend to deploy a based-time dynamic checkpoint
that should work this way: if checkpoint size breaks *Lmax* (see attached
figure) I reduce checkpoint interval, and if checkpoint size doesn't break =
*
Lmin* I increase checkpoint interval. After that I will evaluate the
performace.

I had read remus code and I saw that remus control the elapsed time in

            endtime =3D time.time()
            elapsed =3D (endtime - closure.starttime) * 1000

            if elapsed < cfg.interval:
                time.sleep((cfg.interval - elapsed) / 1000.0)

Then I thought I could change the checkpoint interval close to code above,
but I suppose I need get checkpoint size. But here the remus code is python
and I saw (or thought) that checkpoint size is gotten on *xc_shadow_op_stat=
s_t
*stats* or better on *stats->dirty_count*PAGE_SIZE*.

Would I get checkpoint size into remus code? I thought it's easier this way
for I intend to do.
Please, help me, coz my time is running out.

Thanks jefranca

PS: My English is terrible coz I'm not native


2012/10/5 Shriram Rajagopalan 

> On Wed, Oct 3, 2012 at 4:11 AM, Jos=E9 Eduardo Fran=E7a 
> wrote:
> >
> > I thought remus used xc_domain_save. Is this function used from live
> > migration?
> >
> > Futhermore I have two doubts if really Remus takes the last iteration o=
f
> > live migration
> >
> > What's the function?
>
> There is no specific function. xc_domain_save is where everything
> happens. The infinite loop
> that basically keeps sending checkpoints @ a particular frequency
>
>
> > And how to get de I/O disk size on each period?
> >
>
> This depends on the disk backend. With blktap2 (unfortunately not
> available in 3.* kernels)
> tap-remus driver can give you the number of disk blocks sent per
> checkpoint.
>
> With DRBD, it needs a little bit of hacking into the kernel module to
> return the number of disk blocks
> being sent with each checkpoint.
>
>
> >> I'm doing my master research and I need to adapt remus code. Now... I
> >> wanna get the checkpoint size (memory + disk) on each period. Does
> someone
> >> know what function does this? I think some fd object's function in rem=
us
> >> code could just get the memory size.
> >>
>
> You can get memory checkpoint stats for each iteration - like
> number of pages dirtied, size of data actually transmitted after
> compression (including headers, etc),
> time to checkpoint, etc.
>
> The attached patch (for xen-4.1.2) will give you the memory checkpoint
> stats for each checkpoint and
> can be easily parsed.
>
> shriram
>

--bcaec501655751d1f504ccd188ee
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



---------- Forwarded message ----------<=
br>From: Jos=E9 Eduardo Fran=E7a <jefranca@gmail.com&=
gt;

Date: 2012/10/17
Subject: Re: [Xen-devel] How to get the checkpoint size=
 in remus code?
To: rshriram@cs.ub=
c.ca


Hi Shriram,

Thank you for your reply. I'm so=
rry coz I saw your email yesterday and my English is bad.

Ok... I saw your patch but I need to explain more my problem.

In my =
master research, I intend to deploy a based-time dynamic checkpoint that sh=
ould work this way: if checkpoint size breaks Lmax (see attached fig=
ure) I reduce checkpoint interval, and if checkpoint size doesn't break=
 Lmin  I increase checkpoint interval. After that I will evaluate th=
e performace.



I had read remus code and I saw that remus control the elapsed time in<=
br>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 endtime =3D time.time()
=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0 elapsed =3D (endtime - closure.starttime) * 100=
0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 if elapsed < cfg.interval:

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 time.sleep((cfg.interval - el=
apsed) / 1000.0)

Then I thought I could change the checkpoint interv=
al close to code above, but I suppose I need get checkpoint size. But here =
the  remus code is python and I saw (or thought) that checkpoint size is go=
tten on xc_shadow_op_stats_t *stats or better on stats->dirty_=
count*PAGE_SIZE.



Would I get checkpoint size into remus code? I thought it's easier =
this way for I intend to do.
Please, help me, coz my time is running out.


Thanks jefranca

PS: My English is terrible coz I'm not nativ=
e


2012/10/5 Shriram Rajagopalan <rshriram@cs.ubc.ca>



On Wed, Oct 3, 2012 at 4:11 AM, Jos=E9 =
Eduardo Fran=E7a <jefranca@gmail.com> wrote:



>

> I thought remus used xc_domain_save. Is this function used from live
> migration?

>

> Futhermore I have two doubts if really Remus takes the last iteration =
of

> live migration

>

> What's the function?




There is no specific function. xc_domain_save is where everything

happens. The infinite loop

that basically keeps sending checkpoints @ a particular frequency






> And how to get de I/O disk size on each period?

>




This depends on the disk backend. With blktap2 (unfortunately not

available in 3.* kernels)

tap-remus driver can give you the number of disk blocks sent per checkpoint=
.



With DRBD, it needs a little bit of hacking into the kernel module to

return the number of disk blocks

being sent with each checkpoint.






>> I'm doing my master research and I need to adapt remus code. N=
ow... I

>> wanna get the checkpoint size (memory + disk) on each period. Does=
 someone

>> know what function does this? I think some fd object's functio=
n in remus

>> code could just get the memory size.

>>




You can get memory checkpoint stats for each iteration - like

number of pages dirtied, size of data actually transmitted after

compression (including headers, etc),

time to checkpoint, etc.



The attached patch (for xen-4.1.2) will give you the memory checkpoint

stats for each checkpoint and

can be easily parsed.



shriram








--bcaec501655751d1f504ccd188ee--
--bcaec501655751d1f904ccd188f0
Content-Type: image/png; name="dynamic-checkpoint.png"
Content-Disposition: attachment; filename="dynamic-checkpoint.png"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h8ee33pe1

iVBORw0KGgoAAAANSUhEUgAAA2EAAAHoCAIAAABPTnBRAAAAA3NCSVQICAjb4U/gAAAACXBIWXMA
AA7EAAAOxAGVKw4bAAAgAElEQVR4nOzdd1RTSRcA8JvQu3SkKIJYUUQQ1gIWBBuISnMV7GL57GXB
svaCit3Fhm3tgAUV0RWwUFRUxN4QRBGR3kvq9weKkVCTkPeS3N/Zs8c8Xl6uzMzzZmbeDIXNZgNC
CCGEEEIcqEQHgBBCCCGESAdzRIQQQgghVBvmiAghhBBCqDbMERFCCCGEUG2YIyKEEEIIodowR/wh
KSkpNzeX6CgQQgghhEiBgmvfAACTyZSWltbR0fn+/TvRsSCEEEIIEQ/7EQEAwsLCAKC0tLSiooLo
WBBCCCGEiIc5IgDA7t27AcDAwCAyMpLoWBBCCCGEiIc5IjCZzMePHwMAjUYLDQ0lOhyEEEIIIeJJ
Ex0A8cLCwuh0OgCkp6cXFBRUVFQoKCgQHRRCCCGEEJGwH/HHQHM1XV1dHG5GCCGEEJL0HLFmoLka
DjcjhBBCCAGONdcMNFfD4WaEEEIIIcB+RM6B5mo43IwQQgghJNE5Yq2B5mo43IwQQgghJNFjzbUG
mqvhcDNCCCGEkET3I3IPNFfD4WaEEEIISTjJzRHrHGiuhsPNCCGEEJJwkjvWXOdAczUcbkYIIYSQ
hJPcfsT6Bpqr4XAzQgghhCSZhOaIDQw0V8PhZoQQQghJMgkda25goLkaDjcjhBBCSJJJaD9iwwPN
1XC4GSGEEEISSxJzxEYHmqvhcDNCCCGEJJYkjjVTqdSGB5qrpaenN+U0hBBCCCHxI4n9iBQKhc1B
VVW15kf29vazZs2q+dHXr18JjBMhhBBCiCiSmCMihBBCCKGGYY6IEEIIIYRqwxwRIYQQQgjVhjki
QgghhBCqDXNEhBBCCCFUG+aICCGEEEKoNswREUIIIYRQbZgjIoQQQgih2jBHRAghhBBCtWGOiBBC
CCGEasMcESGEEEII1YY5IkIIIYQQqg1zRIQQQgghVBvmiAghhBBCqDbMERFCCCGEUG2YIyKEEEII
odowR0QIIYQQQrVhjogQQgghhGrDHBEhhBBCCNWGOSJCCCGEEKoNc0SEEEIIIVQb5ogIIYQQQqg2
zBERQgghhFBt0kQHgEQcu+LtkZnTT6QCAIDF+oh9A1QJjggJABarCMHCQlgHUMvAfkTED1bxk6AV
P25MAEChUOo9lfE1ZLKdnZ2d3cSzGQyhBId4hcUqQrCwENYB1FIwR0S8Y+Xe2bbqcjbHkfrvTfSM
W+EpAABdxgxsjd3XZIbFKkKwsBDWAdRyMEdEvKJnhK/beKcEQMdpfE85AACgUOu7N9E+XY/4DADS
Pd366UgJLUbUbFisIgQLC2EdQC0Jc0TEm8oPp//e8ZQG0NZ7/UwLeRZAQ99eK99fuZkFAPI27rYa
WOnIC4tVhGBhIawDqGVhZzPiAask6cDyIykA1M6z1k/uoviIzgSocxoMI+PstD+DPv58WZmw3Nn+
10/b+p465tNWRhgho8ZhsYoQLCyEdQC1OPwqgZqNlR+7fdWFLAA5q8VrPNvJAotBZwFAHdWJ/vm/
Kx+5LvBTh9EOhnhjIgssVhGChYWwDiAhwH5E1Ez0zGvr10cXASj3X7bSWV8agM2s/vpax/dXGZMp
Z++OilrsvvYxHXQ8g8/M7Sgn/JBR47BYRQgWFsI6gIQC+xFRs1R9PPv39sdVAFrOa5YO1KICALCZ
9OpFFOpccoGVm3DhCR0ADIePMMEbEzlhsYoQLCyEdQAJCeaIqOnYZc8OLj/8ngVgOHb9HBu1n7WH
WVX9/RXquDUxvt25+JINACYjh7TBAQ0ywmIVIVhYCOsAEh7MEVFTsfLjd6wMzQSgmE1bP9VcqeZG
1MAYB9AzboV/AADoMhqX4yIlLFYRgoWFsA4gYcIcETUNI+v6xrX/FQLIWMxfN669PMeP2Az6z++v
te9NP5fjkurpZofLcZEQFqsIwcJCWAeQcGGOiJqiKvX8qm2JlQCKff1Xj6r1EBybSfvx/bX20q0/
l+OSs3HD5bhICItVhGBhIawDSNiwvqBGscteHFlx4A0LQH3IKr/B2lzfQ2vuTbVmwpS9uhSdDwBK
/dx7qta/gygiBBarCMHCQlgHEAEwR0SNYBXe373ybAYA6LmtW9BHnbvKcDxP99vh4uQLsSUA0Grg
6G7KeGsiFyxWEYKFhbAOIEJgjogaxPx+c9PayHwAMJm0YaZFnbeYmrnSwDnGwSp4dOFBBQBoO47s
pCCEUFHTYbGKECwshHUAEQRzRNQA2qfQ1VvulwNIm89dN6GjfN1fQmvmwXAOcbAKH19JogOA7uCh
prgcF6lgsYoQLCyEdQARBnNEVB92+atjK/95xQSQt126ekwD23kyfs2Vrrk5Vby//YoJAAqdbQxl
WzxW1GRYrCIECwthHUBEwpWSUN1YRYl7V55KBwDQ7mdFeRZ981l9p9JS08sA4Lfn6ZiF6ZlVAAAV
b29FPVLupqskTQGgyGm01lHCtReIg8UqQrCwENYBRCzMEVFdmDlRAauv5Va/yIkK2hTVlHdxDIFQ
lfS0ZSCVDpB1fdui6z+OarkdPLugC8e9ifZh//gpV7rtCFvVS0lAoaP6YbGKEPIVFiMn4czxiMQX
r16n5dGhre/pYz64ZUeLIlcdoGXdv3Tu6u37T99klrJAXrtz31FTZ/9pq4N1QJzhWDPiRv98cU1A
XFnz3/irOlFa9fXfPM2hi54SRxXTG+psxrnoK9AzH7+TM3f16IaZhBBgsYoQAguLWVlWVsFgc1+a
8S02POp1iVqXPl0Umx8Yai6i6kA9FYCZn3A46GqaQo/RMxf7LZnt2r4g+vAS3233i1jNjxCJDAqb
Xce9QKKoqakVFxdX/9ne3r5r165BQUHEhoQQQsQoT1w+cknhsqv/OKjVfjaCzWJTqBRgfD0/dew+
JvYjiqf6KgC7Mie9WKWtzs9HZlj50cu81iSY+F3c76yNvU3iCksWEYVdHL/CyW7csTQ60ZEgAcJi
FSHNLCyuDTyQ6GtyHaDIaxvrcDxTTVXr0ssQoPBbCbOBdyERhzkiIgir4NGF+xWmro5G2BUhRrBY
RQgWFuK9DrCK3yZ+Adm2HTXxsQYxhoWLiMHKS7jwhNl18QB9rINiBItVhNQUVmsoLyqk/Zh1VFFK
Y7EZZYWFhezqPiOKjJKKkgx2J4ilH3Vgoa1SaWFh9aGmVQBWQULQrvtVRt6TbbjmJCAxgjdyRAhm
1p2LL6R6rOqHE1nECRarCPlVWJVPlo1ekvDbWOM275Hbfv6587LLB4ZrYomKoR91wE85yM3lftMr
ALv8zUn/VTfKe87bPanzb4+/IHGDOSIiAj3jVvgHeZtNNnVsO4pEFharCOEoLIVO0wO3j6FXdyRW
vj2yKrjszzVzLX/s+Cal2l4Vy1Ms/awDfa1b6293a2IFYFeknPefF/y+/eR9m9yNce8WMYc5IiIA
7dP1a+nK/eb1xFEKcYLFKkJ+Kyy19j1t2v/4QTklXIYibWZta4vFKOZq6oB6KyX1plUAdmXqhRX/
++eZ/rhdgZO6KmENEXv49RAJX+X7Kzey1AeO7o7r54kTLFYRgoWFml8HqtLDV83e/UjLbdvuGZbY
uSwRsB8RCV3Zq0vR+TrDXTviRBZxgsUqQngrLHpOcvyzXAYr/10RAOtDQkzUeylpjW59e+ric9Gi
p7l1gJUfu2Xu9vtl+kOmdC5+HPNjyxeKvKF1n05qmC+KK8wRkZCxi5MvxJYYjh1hgjNZxAgWqwjh
tbAqXgX/vbZmv+Db/2y4DQDmf18JclLHQUcR0/w6wCx487IAADJv7t1w89dhlaH7Lq6wwC+G4gpz
RCRczO8xpxIYPf1c2mLXgxjBYhUhDReWos2mqHt1v1F1wL7Y2BYNDQlJA3WgvgogY+obEusrhNgQ
mWCOiISFVZz64tXre8f2ve8w+dAgXBxFTGCxihAsLIR1ADUH5ohISCpe7F845zq7w8CpOxZ6meKA
pJjAYhUhWFgI6wBqFgqbzSY6BoKpqakVFxdX/9ne3r5r165BQUHEhoQQQgghRCzsaEYIIYQQQrVh
jogQQgghhGrDHBEJQFVV1eDBg4mOAgnY3r17Q0NDiY4CNcm3b9+8vLyIjgIR6dy5c7t27SI6CiRW
cD4izkcUgJSUFDMzs5ycHC0tLaJjQQJDoVCMjIw+f/5MdCCocXfv3h0wYADezyWZoaHh169fsQ4g
AcJ+RCQAHz58AICPHz8SHQgSMBqNRnQIqEmys7MBIC8vj+hAEGHKy8uJDgGJG8wRkQDEx8fX/B+J
h8LCQgAoLy9nMplEx4Ia9+TJk5r/IwmUkpKioKDQsWPHe/fqWQIdoebDHBHxi81mnz17duvWrWfO
nCE6FiQwFy5ccHd379y5c0xMDNGxoMZdv3591KhRERERRAeCiLF582ZfX18/P7/169cTHQsSH5gj
In5duXJFRUVl8eLFeXl5d+/eJTocJABMJnP79u3Tp0/39fXdsmUL0eGgRjx//jwvL2/Tpk1hYWE4
PUAC3blz5+bNm/PmzfP29s7IyDh37hzRESExgTki4ktVVdXSpUu3bt1KpVK3bt26YMECHJoUA4cO
HdLT03NycpowYcLXr1+xd4rkNm3atGDBgs6dO1taWh49epTocJBQff78+c8//zxx4oS6urqMjExI
SMi8efOePn1KdFxIHGCOiPji5+fXs2dPJycnAPDw8NDR0cGRDlGXkpKydu3aPXv2AICMjMzevXvn
zJmTk5NDdFyobg8ePLh3797s2bMBYNWqVRs3bqyeS4okQVpamqOj4/Llyx0cHKqPdOvWbf/+/S4u
LsnJycTGhsQA5oiIdwcPHoyIiNi7d2/NkSNHjhw9ehQX1RNdBQUFw4YNW716tbm5efWRwYMHjx07
duTIkTiISUKlpaU+Pj779u1TUlICABsbm1GjRs2aNYvouJAwJCYm2tnZzZ07d+7cuZzH3dzcdu3a
NWTIkMjISKJiQ+IBc0TEo+Dg4A0bNkRGRmpra9ccNDQ0jIiImDt37vnz5wmMDfEmMzNz0KBBf/75
Z60kY9OmTV26dBk6dGhRURFRsSFuNBrN3d3dyclpzJgxNQe3bdv2/v37TZs2ERgYamk0Gm3dunXD
hg07cODAnDlzuE9wd3cPDw+fPHnyggULSkpKhB8hEg+YI6Jmo9Foc+bMCQwMjImJad++fa2fduvW
7b///lu2bNmKFSsYDAYhESIeJCQk2Nraenl5rVu3rtaPKBTKwYMHu3Xr1rt379evXxMSHqqloqLC
1dVVWVl5586dnMfl5eWvXr164sSJjRs3EhUbajlsNvvSpUvdunVLTk5OTk52dnau78w//vjj1atX
ZWVlnTt3Pn78ON6NEQ8wR0TNwGazL1682LVr19zc3AcPHpiZmdV5Wvfu3R88ePDixQsLCwsc7CC/
r1+/Tp061d3d/dChQ/7+/nWeIy0tvXv3bj8/v/79+y9ZsqSgoEDIQSJODx486Nmzp5GR0ZkzZ2Rl
ZWv9VF9f//bt2xEREc7OzpmZmYREiASuoKBgz549nTp12rx5886dOy9evGhkZNTwWzQ1NQ8fPnz+
/PlTp061a9du06ZNWVlZwokWiQfciw/34msEnU7PyMj48OHD7du3z58/r6WltXXr1gEDBjTlvTdu
3Pjrr7+qqqq8vLz69+/fvn17AwMDaWnpFg4ZNS4vL+/Lly+JiYnh4eEPHjyYNWuWv7+/srJyo2/M
zc1ds2bN6dOnBw8e7OLiUp2pqKmpCSFmCUen0z99+pSYmHjy5Mnnz5/v3r3bw8Oj4fM3bNiwZ8+e
MWPGuLm5de/e3cDAgEKhCC1gxA86nZ6Tk/P9+/f09PTExMSYmJg3b94MHz587ty5ffr04eGCz58/
37dvX1hYWJs2bQYNGtSnTx9jY2M9PT1tbW05OTmBx4/EA+aIxOSITCYzOjr64sWLSUlJnz9/Ligo
IO0DAfLy8rq6uu3bt7e1tfX09LSwsGjuFR4/fhwaGvrgwYO0tLTc3NyKioqWiJN/0tLS2trabdu2
7dWrl5ubm52dHZXavI72L1++nD9/PiYmJiUl5du3b6WlpS0UKp9kZGSUlZWNjIwsLCyGDx/u4uJS
/cRD0xUUFFy6dCkyMvLNmzdZWVlk3gJOVVXVwMCgQ4cOTk5Onp6ezdpS/NOnT8eOHYuMjPz48WNR
URHh6zqZmpp2797dzc3N3d29if+u5+TkHDt27NatWy9fviRDH5KRkVHXrl2HDx8+YcIE3r5a5OXl
3b59+969e8+ePavOovLz8wUeJxno6+tX35EsLS0HDBjQu3dv/pM5BoPx+PHj27dvP3r06PPnz9+/
f8/IyBBItGSjqqraunVrHR2dTp062dvbDxo0SF9fn+igRA/miMLOEVks1vHjx1evXq2vr+/u7m5v
b9+mTZvWrVu33CeiJmKz2d++fUtNTY2NjQ0JCSkuLt6wYcPYsWOb0vWSkpLy999/37hxw93dfcSI
EZ07d27btq28vLwQwkYNKysr+/Tp04sXL65evXrt2rU///xz9erVjba4kpKS5cuXnzx5ctq0acOH
D+/evXuzkktUJxaL9eXLl+Tk5HPnzt26dWvlypXz589vYtcmnU4PDQ09cODA8+fP7ezsHBwcunbt
amBgoKOjg0WDuBUWFmZlZeXk5Dx9+jQ2Nvb27dtt27b19fX19vZu7ldiicaWeKqqqjW/DXt7+1mz
ZrXcZ7169crGxsbe3v7x48ct9ylIIOLj462trfv375+amtrAaQwGY/369VpaWoGBgRUVFUILD/Gg
qKhoxYoVGhoaBw8ebOC0N2/edOjQYdq0aYWFhUKLTdJ8+PChb9++Q4cObfSXXFVVtXPnTn19fQcH
h0uXLtHpdOFEiMQJk8mMiooaPXq0lpbWqlWrSkpKiI5INGCOKLwc8ebNmzo6Ov/88w+LxWqhj0CC
xWQyt27dqqenFxsbW+cJJSUlLi4u9vb2GRkZQo4N8ez169cWFhbTpk2j0WjcP3358qWent6xY8eE
HpfEYTAYs2bN6tWrVwNpYmxsrLm5+dChQ58/fy7M2JC4SktL8/b2btOmzeXLl4mORQTwO9bMKHgX
H3Pv0YvUb/lF5VJd/rd5jvmP4TVW+feM7AoWRVZdv7WaDInnSQtnrPnq1aszZswICQnp16+fwC+O
WtR///03fvz48+fPDxo0iPN4eXm5k5NTx44dDxw4ICMjQ1R4iAelpaXu7u4qKirnzp2TkpKqOf79
+3crK6sdO3Z4enoSGJ5EmTt37qtXr27dusVZEADAZrPXrVt36NCh3bt3u7u7ExUeEkv37t2bMmVK
//79g4KC8JGdBvCRI7KKnp3euPbQfY4tuiw339jT78dAPzPr8hyv7S9Z1O7+YXtHaJN3kR0h5IhP
nz51cnK6fv16r169BHtlJBwxMTFjx46Nj4+vWe6HzWZ7eHjIy8ufOnWK2NgQb2g02rBhw7p3716z
viCbzR45cqSFhcWGDRuIjU2isFgsJyengQMHrlixouZgVVXV5MmTP3/+HB4erqmpSWB4SFxVVlb6
+Pjk5ORcvHhRQ0OD6HBIitfUjVWStHfmnJ8JopIG9+NpUrqDJw1UAmA9v/Iwj8VHiKKuvLzcw8Pj
0KFDmCCKrkGDBgUEBHh4eNDp9OojQUFBmZmZR48eJTYwxDNZWdmLFy9GRESEh4dXHwkJCcnIyFi9
ejWxgUkaKpV64sSJPXv2vH//vvoIk8n08PCoqKiIiorCBBG1EHl5+fPnz1tbWzs5OeFWNPXhMUes
eHV4fVgGAKja+O68GBN5xt+S6xyKsrlLbyUA+HDnbakEPzwdEBBga2s7evRoogNBfJkyZYqhoeGe
PXsAICsra+3atSdOnOBevhiJEDU1tSNHjsyfP7+8vJzFYq1ZsyYwMBCnDQifgYHBvHnzarpvV65c
WVFRERYWhisDoBZFpVIDAwN79uw5efJkPufdiSueckR2cdKZyFwAMPTZsdHHWru+2YaKpv3MqAD0
9NfZkroJUFZW1t69e7du3Up0IEgAdu7cGRAQUFRUtGnTJm9v7/q2mZEIrOLH28fY2dl5n/rM0bjZ
5R+uHTtxK4Oka33Wwc7OzsrK6sCBAxERESoqKg4ODkRHJKHmzJlz7dq1jIyM6OjoU6dOnT17ttb0
RIRayL59+9LT0w8cOEB0IGTE044XVRkPX1cCQJfxo80a+ppHkddt2wqS8wu/FNABJPLL+enTp93c
3AwMDIgOBAmAmZnZgAEDzp49e+rUKcnetpiVH7dz3eVcAJCW4/iKyCq4f2DnSYbfSB/iQmu+5cuX
jx071sbGZsqUKUTHIrnU1NTGjBlz4cKF48eP//PPP7jkIRIaWVnZkydP9u/f38fHpyl7TUkUnvoR
mYVfiwBA3cxYpeH3U2UVpAGAVkaT1E7ckJCQcePGER0FEphx48YdOHDA2tpaT0+P6FgIw8z+L2BT
XJup0zsDSMtJ1+SIrLyEC0nUXu62GuR9RK0OVlZWUlJSERERw4cPJzoWiebs7Hz69Gk2m+3i4kJ0
LEiydOrUaeDAgTi/nBtv9/LqhfHZjT6JwijJLgUAWUVZEq9903IqKyuTkpKauLUxEgmOjo4vX74c
OHAg0YEQh55xed325+YLVwxVZwPIyEtRAACYWZd8+4/Z8oJRmbDc2d7Orv+cyBzReVTNysqKQqG0
adOG6EAkmo2NzcuXL8ePH4+bSiPh8/HxuXz5MtFRkA5PY83SrQxbwcPcwrSMcpa5fP1pZlV6/Ity
ANAy1ZLIgeb09HRjY+Pm7vmLyExZWVlKSkpHR4foQIhS9fHsqn9SbVf8O1S7KpQGIPejH5Gq0W/a
mJOLoy037JtqJgtUGVUtEi94VZumpqaCggLRUUg6PT29yspKKysrogNBksjGxubZs2dER0E6POWI
soa2neUvxFa+Do/NdnTVq2diMSPrv4PhOQCgbtmrtUTmiEpKSv7+/kRHgQTM09PT0pL7OX5JwC5/
eeTvI7kDN24fqEVlppXRgCorU93+KVD4JCFHZ4jnH8b6orcgraOjI36XIxyVSnV2du7UqRPRgSBJ
pK2tvWDBAjqdjisbcOLptkhRsfBy1ABgvdy3+WJqZR1zDdkVaZEBc7c+oQGA4Ui3jpK5gIGhoSGT
ySQ6CiRgdnZ2PXv2JDoKArCKnwStOlc54u/5fdSpACxaWdWv6YiV76/cyDIcPsKEgAQxKQk0NCAp
ifcruLi49O3bV3ARIR45Ozvr6+sTHQWSULq6upgg1sLjV2fFbtOWOLUCqEzaM3H8kl1n/3ueDwBQ
+uXlo7vXTu5aNsl1wqabWQAAemOWjjWR3DXkZsyYQXQISMAktExZ+XE71oRLu6/+n7UqFQCATSun
gcyPHLHs1aWYApORQ9oQcYMNDoaCAggO5usiuPkeGUho40LkgNWPG09jzQBA1ei3dO/iivnbY/Oz
Ey8EJVYf/RC0ZBHnWZoDl+38X09lCZ5/rK6uTnQISMAkskyZ328GbIxp5X1wenelH+2ZTSujgbSc
FAWAXZx8Iba08/8Gtub1hsIXRcVf/0ciTSIbFyILrH7ceL+lU+SNR2043fXm0aCjlx5nca2RrWkx
etqc6cM7NbI6jrjLz88nOgQkYBJYpvQvl9YFPtSfcmRSZ4VfK93QymggJScDwC5+Fp5Y1WVRHx1i
Fj0ODARtbfDz4+siuMsCGUhg40LkgdWPG39f+6nKZsPm7Rw2q+jzm5dvP33LK6lkSSmo67Y169bN
VEtOsrNDhMREZcqZ1Xuey/Sarv8l4faXmsMVL78xQVpOmgq0zKSUKqpuzvtXr3Ll1dua6itWt31W
TsTS9WWLdngacNxnKl7sW7Tu+ptsremnjo43ElS/I58JIkIIkUDFs61ec64WAGi5HTy7oAvxj3II
5BYto9ame9823QVxKXFjbW39+PFjoqNAgiRZZcouf3n07+APbIDEw+sTuX5sICdNARk9m35mkZeC
/WcHUy2Wh+3R/zHqS9Uetm0Xlcr8fDMk09rtD00pAAA5E68NR0beWrKeZE9zeXp6hoSEEB2FpJOs
xoVIhvjqV/bi0u0CAIDWw5wb3MVOaAiZPiRBnjx5QnQISMAkq0wpiuazz8bObvgk9d6Ljt5YVOsg
/dOJBQcN1m8crJCblPC+4+gfOSJVSVuT8ZV8c5RDQ0OJDgFJWONCJEN09WMXJV2ILwUAMB45tC05
HrDmKUekpUeeikynUZXaD3ZzMFGs/3bPrkiJOBOVQWk7zHtYW4l8uNkPx8DEDpZpk9DSbjzQGhGg
ToVKIXxaaiqYmPB1BV9fXwHFgniHjQsRiODqx8p/GJZYCQDQcZSDATlSRN5yRPqXyGOnnwIAnLqZ
vDZw/kC9ev427IoPV4+ffg2W5l4SmiMGBAQQHQISMCzTpqh8d+1pa7PCFdOPV7JKP6eVvZp5T15K
o9/S9ZPMBL6C4pkzMH48nD4N/GyNfvDgQcFFhHiEjQsRiNjqx8qJu/CUAQBUCzd7XWKe/+PG53Ml
7PTwVT4LjiQVis7OrMJFdN81ErwmlimN1tKBkFnZi6vvOo1x998XHBz8z18DLTw2HAgOPrS1mQki
kwlNWYQ+Lu7X/3lWUFDA1/uRIOANExGI0OrHyIy59JoNALK93P7QJM0jv/wEotq1kyoAVD4/Pn/i
yosfynHpCG7W1tZEh4AErOEyraiALVugfXuQk4Pt24UWFLmwi5KufrYc0aGuOdf0tJCVc1ece/c+
5O+5K0PS6A1d57//QFoa+vaF8HBg1f89tHrXG573vmGz2dnZ2RoaGjy+HwkO3jARgYisfvTP/135
CACg2MfNuhVpUkS+nlnRd16/acrlFctOv6Hlx+6c6vtxzbYFgyRzZ2Yk6VgsOH8eAgPh2TNgMqF6
OzEfH6LDIgYzO/Zq0cC5P/dXUui5bNev/E2mneeG/U3c0sTREaSkICEBRo8GOTlwdISVK8HGpvZp
06aBpb3bKLwAACAASURBVCVYWTV+wQ8fPty4ceP+/ftpaWlpaWmFhYVVVVVNiwUhhFpKVWpERAYA
gFr/MRYqJHqmj7/nmqU0bWbuO2ESuHR9ZAY7/crqCampWzZN6alOnhyYaB8/fiQ6BCRgtco0NhY2
bIA7d34bXO7ZExwcQEdH2LERj5UX909geEmf+YsM+V80QVoaxo+Hf/8FNhsqK+HqVYiIAFVVcHOD
lSvB2PjXmfUliCUlJWFhYZcvX05KSvr27Vut/dMVFRUBQEpKCvdVJwm8YSICEVf9Kt6G38oGANAa
PKozqXaM4v82Lmvo5B/cpv3aJXvvF1W+PDF/0scFgSvHmCmRKBEmkAmfD1si8uEs0+xssLev45zS
UtDXB4okNgJNgM0AELhCMJdzdv7tJYsFsrJw7hwcOQKJidCrVx1vYTAYly9fPn78+IMHD/Ly8uq8
rIyMDJ1OV1BQLi8vB5ACwByRFPCGiQhEWPUj37KINQTS40dV6uS5+d/t3l3kACA/btdU363RmRI9
Y7+Gv78/0SEgAeMsU01NOHkSRo4EZWXo2BFqprQVFYG8PLDZ+B+//8n/vGGqqYGzMzg7A5MJNjZw
+DB06fJbuZSUlAQEBHTr1k1eXt7DwyMiIqK+BBEA5OTkqosJANhsnCBDFnjDRAQiqPqRcVnEGgIb
FZbSsJmx9/iqEYYAwP58bc3E+YcfFzAl/jGWLVu2EB0CEjDOMpWSAm9vCA+H9HRYsAA6dwY1NejU
CVJS4OJFoDf4QAZqFI0GN26AmRmMGQOqqvD5M9jbQ3IyxMTAtGmgpAQAUFFRsX37dj29Va1atVq2
bNnLly+5B46p1N9udCoqKkpKStLSsgxGawBgscqE9RdCjcAbJiIQMdWPlMsi1hDozEFZQ8e/goPn
9WkFAJUv/104cUXYewm/+w4ePJjoEJCA1VmmGhowcybExUFyMvj4gKEhZGTApk3Cj06s3LkDpaVQ
UADt20NEBDx7BkuXgqHhj59GRETY2tqqqKgsWVL+/fs6KamN9V1HUVGxVatWI0eOHDp0qIWFBZvN
zsnJYbE6A/Ts23fX4cOHr1y5Ysw5vRERBG+YiECEVD9yLotYQ9B78VGVOnpsOmF8ZPmyk6+qCu6f
ChPw9UXNrVu3iA4BCVjDZWpsDMuXw/LlEB8PuI4Hn5yc4M4dsLMDzn7AwsLC1atXHz9+vLi4+Ocx
LQBgMFpxvldRUdHa2lpTU7OoqCgmJkZBQUFFRaVXr15WVlbdunWbPVvtzBlQVobbt0FGBgDAxcVF
SH8rVD+8YSICEVH9SLosYo2W2K9ZSqOX754TJjuXrr32pQUuj5Ao6NuX6AjEQv/+v/785MmThQsX
xsfHs+paLJHNZktLSysoKAwcOJBKpSYnJ3/+/NnMzMzNze3UqVOtW7euOfPNGzh3DigUOH36R4KI
EEIEIOuyiDV4yhFljV1nT7cGvS7K9T63KWsweOnhNu0DAy+9L2MrGCmT8K8uFBoaGvn5+URHgQQJ
y1T4Ll++/Ndff3348KGBc9q1a/fpE7OkpCQrK8vV1XX9+vXm5uZ1njliBLBY0LMnjBz566CpqSku
vEI4bFyIQMKvfqRdFrEGTzmijKHDnxMaPYuq1MFt9SE3Xj5AfOAGX+IHy1Ro2Gz2yZMn/f39v337
VucJcnJyAwcOfP/eJDUVSktLd+zYMXbsWD09vQaueekSpKcDlQoREb8dT01NFWDkiDfYuBCBhF79
yLssYo2WGGtGv4SEhBAdAhKwgwcPEh2CRDh27Nhff/2Vm5tb5087dOhgbW397t27V69e6eioA4C7
u/uCBY1ftndvMDUFf3+olUkGBAQIIGjEH2xciEDCrn4kXhaxBoXNlvT1adTU1Gomv9vb23ft2jUo
KIjYkBCSZNeuXZsxY0ZmZib3j6hUav/+/bW1te/cuWNpafm///1v+PDhc+dK7d8Ps2ZBExsuiwVU
SZ39ghAiB3ZRrL/78oRKAHlLn1mD9erusaPKG/V2sNQk7HnnJvQjsiq+f/lewQagSKvoGmjKU34d
aSKKgq6RroJE3pRDQ0M9PDyIjgIJEpZpy0lKSho/fvzbt2+5fyQrKztixAgajfbgwYNJkybFx8e3
b9+et0+pM0GMiorChVcIh40LEUio1e/XsohQ+fTkzqf1nCZtteoCkfelJuSIFU82ei97CgCg7LT3
4t89FDiONJHl5ht7+inxGKJI8/T0xJ5aMYNl2hKys7O9vb3rXHtCUVHRxcUlPz//4cOHCxcuPHv2
rIqKisADcHR0xGIlHDYuRCBhVr+aZREbJv+Hu406kR1sOB8RIUQkBoOxevXqrVu3Mhi175jy8vIu
Li5ZWVmJiYlLly69cuWKvDyPs3bu3YO9e+HsWZDGex5CiGhUXdeD91yb8w5W3s0F7huKJwaMq7x2
+tr91CJmK4vJm7dMMs25feLgv9fupxYx1XtMCQiY1EWp+gFpembMseDw+OQ3qTkVAHK6Fi5z/p49
QFcGWLmR89w2vbZee2HbIHUqALvs7bkVCw5k2q/as9RB7/flwJpwv5Tr6PP3sqEMAIp8mzayvx1p
ImntjnLN+E2IE/xOLH6wTAXo7t27Hh4eOTk5ACAnJ0ej0ap/vdLS0q6urqWlpQ8fPly7dq23t7c0
H8ldcTE4OAAAXLoE9Q0l4ZIrZICNCxGI1NWPmR174SmDqnHzRLzD8An+Tjk3d/1z599dBzJl3tGt
hk/wH5JzY8c/d8+eezt2nZUCAAD925PnpQb2f9qP1VaVKnp/K/ifsC2H+v/xdw95qobtyB5Sz5Ku
PCkcMLhV0aMDi/3CwD3w0Mxe3Cs0NuG2K63dy2l4I0cQQqg5iouLx44dGxkZWXOkqqpKSkqKyWQO
HDhQU1MzNja2uu9QVla24Uv5+8PNm+DvX+8Jbm7AYIC2Nri713uOurp6s/8OCCEkFIxvty+9AaXe
07dtdDaUAYBy+Zijd+58zbUK/meYgQwAlMveOnL3ubLcz1UWZdq4LFhU8/4e7cqib+yuoLEAAKit
erlaySQ9CU94zXq2dmOswcygjWM7KdW1PqNEPkgiRI6OjkSHgAQMy5R/J0+e1NXV5UwQq+nq6gLA
s2fPTExM3r59u3jx4kYTRABo0wY+foQ2ber+aUICREcDhQLh4UCpf5HaGTNmND1+1EKwcSECkbj6
0T/fDE+VsV6wdLhh9VgwPTPpXYWszaIlQwyqD9C+PnlfqWBhZ1w9assqT7t9bMM8n1FOA+zs7Ozs
+o/Z+hZMbNtWT9ahtrIaaS3LTN4ya/3jLv7BW/+sO0GElskRmWVZae/fpWYW0UncbyskUVFRRIeA
BAzLlB9FRUX9+/efMGFCZWUl53FVVdUpU6bIysq6ubk9ffp0y5YtrVq1qu8iTcdmg6srsNng6Ai9
ezd05qFDh/j/OMQnbFyIQOStflUpERFflQeMs9Om/jxw/cY31YHj+/zc4rkyJeK/LBW7Ud2VKQCs
vNhtkydtiqX2Gue3bf/RE/8e3z7eCKjmI3v/fD+jokpWDgD0xm9dMcywgS/iPE7xYeYn/3c7pYza
ytxhUCfVmkSTXZkeuWPVjsjUKgAAoLa2m/m3v1c3VcntrfT19SU6BCRgWKY8u3jxoo+PT3l5ea3j
w4cPB4C4uLjg4GCH6pmDArJuHeTlgbQ0hIY2ciYuuUIG2LgQgUhb/SreXvkvR8NhdDelXwdu5Wg4
jOry80D5m8tRuRoOo82VAFj5d7etvybtHRw0raM8BQCg8vX16C8yVlP7aFEBgF2ZFr523s7nGjrU
kqzHz/OZZnr1L7/IW/ZG/xoRuGnX7t2n3oLcryuwS5/uXbD5Z4IIAKxvsUHz/ELT6Tx9iFjAbQPE
D5YpD6qqqtzd3d3c3GoliIaGhlOmTHn06JGtre3z588FmyDm5sL69cBmw5YtoKrayMm4JRIZYONC
BCJp9WOXvrh0u1B3yMiO8pwH9Ia5dPh5oOT5xXtFekNGdpAHYOUlnIuv6PznKLPqBJFV9OjA2vNZ
Cn+49VKnAqvkxYlFvrs+D9h4fN9f/ZXgXUTsd2YDH85Tjsgqfp2QDgDa/Qe3+/XAMjPr5v4ruQAA
un3+/N/Cud72+gDAeHn4n/gCFi8fIw5wE1jxg1vKNldycrKhoeGFCxc4D1IoFA8PD01NzS9fviQk
JKxatUpOjsflD96+BW1t4F5429UVmEzQ14dFi+p6GyIfbFyIQOSsfuziJ2FxZUbOw9vJ/jyQdCG+
rO3IYcY/DrCKki4klLV1HmEsCwDMku9FAAUfPxfRK/M/xp1YOXv1hUxQsXProcrKS9gze95p1tjd
+xf2025l7vKHEnyIiP3WwCo1POWI9Oy33wBApr21IWeKGHv1LQBQOi/Ys3H22DGeM9bvW24tA1CV
eCmpSFJnJpqamhIdAhIwDQ0NokMQJYGBgVZWVrW2XTYyMpo+ffrdu3fnz5//33//8bxjSrU9eyA3
F/bs+e1gVBTcvw8UCly/3qSLUBp4ngUJCzYuRCBSVj9W/oMLj6raj3L88bAKsPIfXkis7DDa4deB
B2GPaGauP86QaTNi8lDjwrAFIwe5TAu4ybAf17sVaDiMNiuIXD99WVTruQd3TbFQpQKAUheXvirw
MeJeA0kiT/MRGcVZJQDQylD912KLrKLXsWkAIGXpOfDHvoNUrb6jLWUeJ9I/JWdWOaiTdMdqhFCL
qKysdHZ2jo6OrnXc1dU1Ly/v7du3Dx8+NDY2bomPZjLB2xvYbBg9GiwsWuITEEJICKiaQ/bcHvLb
Aafdt504D2gN3Xtn6K/X0npDVpwcsoLjjKEjAADAfM3FYb9dW8nq7+uxfzf88TwFzahiAICUrPSv
b96Vn+I/sADAdKB5zSqMFHndduoAUJJd0tB4tzh7/Pgx0SEgAcMybYqUlBRjY+NaCaKqquqMGTMS
EhJGjhx5+/btFkoQAYDBAGtrMDGBU6ea+hacj0gG2LgQgbD6ceOpH5EipyQLUFmSXVqT+tG+PnhZ
BgC6PbtocOSdVCkqALAYkjrUDFZWVkSHgAQMy7RRISEh3t7edPpvT6tZWlq2bt36wYMH0dHR3bp1
a9EA5OTg6lUoKQFFxaa+BZ9rJgNsXIhAWP248dSPKKNtpgMAZS/uf6FVH6Glx9z+DgCKXWwMOFba
YRZnFQOAorpC/U9Wk8RNADbA3Xv3gvbvBwqFx//u3q112S1btjQjiOXLf12KSuXlPwoF1q3j6xdx
5Qrvn14Tw3D+tuHJyeE3BioVlJQa/6CGKSrWGcaWpscgLQ05OXzFYGwsgOJ4/ZqvGIYObVYMC6hU
Ly8vzgSRAjDOyamkpKRdu3YPHz7kJUFcs6ahGPbvBwDYv5/zIEWKqtrq999Dg42x8fURT5wQQFmM
Hdvsvzunt2/5bRdUKvDffSsjw28MFAoUF3NfuBk3TENDARTHx498/R769RNADA8e8BXDwoUCiOHo
Ub5iEEjTmDiRrxji4vj/V2NL69Z8xQAAUlIt+6sWOt5yRD3bP7QBIOv8xqDoD99zPz84vu1cFgAo
WA3pyPG9nZ7z+mM5AGi31+J9q1UhMeD/EgMGwI0btY75N7BBGLe0tF9/ZrN5+a9HD7h/n6+/RUYG
759e/Z+JCfD5NHf16sr8xMBmA9cifM1Go9UZhn/TY2jdGrKy+IqhehNhfn4PlpaQnMxXDF++NDGG
KjZ7IJu9+/c9T5UB5unp3YqPX7Nmzb59+3h8ePndu4ZiqNFAeNbW8PRpA5/Q+D4r1c2Tz6bx7Bkv
f/0ahYX8tgtlZX7rJAAwGPyGoa4OhYXcF27GDbM6xeQnBnPzOh6Gbxb+75a2tnDnDl8xvHkjgBgS
E/mKgf+m0aXLjzbOs+xsfmNQVvbnv2mwWC37qxY63nI3OTOPKVaXtzyhpV5YM+XXghaGYyZaqf6a
osjMe3w3HQDUOnUmf47YQoTddy0jA1JE99lKSUET9k8TAfU86NqMElVQaKEYmkFYMeQDWAOk/X6w
I4A1wPWiomhf327jx/MbCT9kZRtuGsLYr1lKCmRkGj+tRVEoIM/384MUCrD5m0BUT7Vsxg1TdJpG
y8bAPzk5oBK9z4W0NBmahlVL/+tJhl91M/EYrpTe8LXbJlkocxzSslu8eVJHjpsPPePW5XcAINvF
rh2P656JPpwDK36wRLm9AzDhShAdANQAygAeWVl109MjJrImy6/uskWEwhsmItBjZeXGT5IwPPfv
UdV6Tt17ZXRK8vO03CpZHTOL7ibqv30NYJUXqwyaOJEhrdvPUpn8K489B2gP8E5NTVFRkcfV2u7c
4XcenqUlnDsHdna8XyE1FTQ1+YqhekFHfmLIy4PMTL5iqH7QgJ8YACA2lq+3AwCDAd27g5oaXzHw
2aWqrQ2tWkHbtnzF4OfHVwwdO0JKCtjY1PfzO0VFQ168oP3eseSjo3OnqGh269Z+RkaU2FjgsxOx
4aaR0hq+AVuvdXy2HYsFHTuBjjbXOa9egQF/M0o6dwbgu2nwuUhvdevmJwYaDR4+5CsGAGCzoVcv
vvojY2NBmr/RJVVVATSNpj/TVKcOHSA/n6/Vle7cAS8vvmKwtoabN/mqEomJwOczZPw3jcxMoPO3
IZuhIb8xCKRpNBwD/79qoaOw+RwyEH1qamrFxcWyAJMAzMzM9PX1x40bx+O1uHZ7NDU1/disadFn
zkBpKY+fXs3dHfhcCPTGDfj8ma8rDBoE/K2KDHFx/D5p0aNHA2lNk7x+DXFx3IdNV6z4uHFjk67Q
vj0MGsRXDFlZcOUKX1fQ0AB3d76uUFoKZ87U98MziYk+R4+yOG4jstLSM+3tzz56dGLSpGHm5j+O
8r8R6vHjP2aIcpl9pt/+u11m9X892SwuNxeGDavzrEaahrW1deOdWFeu8DuZb+hQaNOGryvw3zRs
bKBHD76ukJzM77SqeppGM26Ynz9zz/9uHj09GDmSrys02DSaRFYWJk3i6wrQUNNoqnHjgM8utLAw
4LMnnv+mERMDKSn8XMB0/fqP1dOvedZo0+D/Vy1cmCP+yBGr/2xvb9+1a9egoCBBXZxCwd+wuMEy
rbF79+4FCxZwHlFXVx8/fvzly5evXLliaWkpnDD27IH582H3bpg3j/eLYLGSAZYCIhBWP26S+iyJ
sJB0j3DEh4CAAKJDIIXly5dv3rwZOG6sxsbGdnZ2d+7ciY+Pb8Nnl0BzzJsHrVsDn+sb+vE5Io8E
ARsXIhBWP26YNbdsPyJCYmnOnDn//PNP9Z+rc0Rzc3NDQ0M6nX7hwgU1fiZxNh+dTvwzkQghJH5E
7DFskRMVFUV0CEjAsEynTJlSkyACQPX3zLdv3+rp6V2/fl3ICeK7d9C2Lezbx+91Uvlc1BMJAjYu
RCCsftwwR2xZjo6ORIeABEzCy9Tb2/vYsWOcR6p/IcuWLTt69Kis0JfGdHGBb98gIoLf65hWP9GP
CCXhjQsRC6sfN5yPiBBqKi8vr5CQEM4jrq6ur1+/DggIIGQ+X1ERUKmgpASjRwv/wxFCSMxhP2LL
woV5xY/ElunYsWNrJYgeHh4vXryYPXs2UQ98qKnBvXuwYAHMmAF79vB1qeatUYVahsQ2LkQGWP24
YT9iyxLGBl9IuCSzTCdPnnz+/HnOI15eXg8ePPDz85s1axZRUQGAjs6Pddn43HrXxMREIPEgfkhm
40IkgdWPG/YjtixPT0+iQ0ACNmPGDKJDELaFCxceP36c88jYsWPj4+NXrFhBbIIoQP7+/kSHgCSx
cSHywOrHjacckZH3PPb27djneYxGTmSVf358t0lniqvQ0FCiQ0ACdujQIaJDEKr169fv2rWL84ib
m9u9e/c2btw4ffp0oqKKjoaKCkFecMuWLYK8HOKJpDUuRCpY/bjxlCNWvQlevmrV8uA3VY2cyMyO
2b6ySWeKKw8+F/ZF5CNRZRoUFLRq1SrOI2PGjImLi9u+ffuECROIimrHDhgyhN8toGsZPHiwIC+H
eCJRjQuRDVY/bjjW3LJqzfFHYkByyvTq1atz5szhPOLi4vLkyZMtW7aMHTuWqKiKi8HfH5hM6NVL
kJe9deuWIC+HeCI5jQuREFY/bi2cI7KYbACgSlNa9mMQQgL26NGj0aNHc+7DNHDgwLS0tP/9738T
J04kMDB3d6DTQVsbcAIhQgi1qJbNEWk5afkAoKCmIKn9lRQKpsfiRhLK9M2bN/369WMymTVHbG1t
S0tLnZ2dly5dSmBgCQkQFQUUCly+DIItBw0NDUFeDvFEEhoXIi2sftyavPYNqzI/O7+SBQAA5XmV
AACVed8yMxXrOZ1elpf+9GrQ3QoA0DdvLezNFxBCPCoqKrK1taXRaDVHzM3NFRUV27dvv2nTJgID
Y7PB1RXYbHB0hD59BHzxgoICAV8RIYREXJNzxIrHazyWPf3t0JvAyV5NeKdUd9e+OlLNDUxM4CQn
8SPeZUqj0aysrEpKSmqOGBoampqaUiiU/fv3E/s9e906yMsDaWkICxP8xQ8ePCj4i6JmEu/GhUgO
qx+3ll5DW6HD6BWrR+hJaoqID0uKIfEu0xEjRnDuOKKmptanT5/c3NzIyEgpKSLbcW4urF8PbDZs
2QKqqoK/vq+vr+AvippJvBsXIjmsftyanCPKtvdcPN++epnDqpTzByKyQG/ETK/2cnWeTaHKKKrp
GHXo2slIVaK3cjl06BD+2yNmxLhMFy1aFBUVVfNSVlbWy8srKSkpKipKVpbg+SKjRgGTCfr6sGhR
7R9NmwbHjsG0aXxdPzQ0FFe+IJwYNy5Eflj9uFE4n1tsqrK4eUOXPQXLzTf29FNqgaCES01Nrbi4
uPrP9vb2Xbt2DQoKEtTFKRSefsOIxMS1TM+cOTP+9yUH//e//125cuXhw4etW7cmKqpq0dHg6AgA
8PQpWFi0yEeIa7GKFiwFRCCsftx46uST7zZ3z84iUDOTF3Q4Ygc3gRU/Yrmn54sXL2qtaDN16tSQ
kJDr168TniACwKVLQKWCq2tLJYiIJMSycSFRgdWPG085opSamaW1oCMRT5xTu5B4yM/PJzoEASsq
KrKzs2Mwfu2YOXTo0JiYmL1791pbk6Klb9sG1tYwaVILfgT2H5CB+DUuJEKw+nHje7IgoyQz5UPq
15ziChqTVc9dVkbXdrCtrgy/H4UQEjg2m21vb19UVFRzxNzcvLi4ePz48V5eTVm4QBgUFFo2QUQI
IcSN9xyRVZ76X/Ce4ItPvjMbPddys72E5ojW1taPHz8mOgokSGJWpr6+vs+fP695qamp2aVLFxqN
tm7dOgKjapbcXBg+HK5fBy0t3i/i6emJO3ERTswaFxItWP248bj/CbvsxeHZkzaGNiVBlGhPnjwh
OgQkYOJUpqGhocHBwTUvpaSkPD0937x5c/r0aTJsOZCfD3l5jZ+2ahU8egSrVvH1WaGhoXy9HwmC
ODUuJHKw+nHjrR+R9vH0xlMf2QAA6hYjPUf07Wai10pBhlrPPyoUeW0FniMUbX5+fkSHgARMbMo0
IyPD29ub88jEiRMvXbr04MEDRcV6NlASIjodrKxAVhaio8HQsMU/Dte8IAOxaVxIFGH148bTk970
lIPjJp/KAtBz23VknpWqaG/G3KJr3yBETkwms3379p8+fao5MmTIkOTk5LCwsH79+hEX1y8zZ8LB
g6CsDLm5IFf3Oqw/lJeDpyeEhAAJMluEEBIfPKV3tJyUXACArpPGW4p4gtjSsO9a/IhHmU6ZMoUz
QTQzMysoKFi6dClJEsRPn+DwYQCAgwcbSRABQFERrl3jN0HE/ZrJQDwaFxJRWP248ZbhVU9VUtLX
V8YMsWEkWToECZAYlOnFixf//fffmpfy8vL9+vXT1tZexL2HCUGGDwcWCzp3hnHjhPSJGhoaQvok
VD8xaFxIdGH148bTfERZvS56cP9LRV4hjQ0KxM9sRwg1WXZ2dq39VKZPn3758uWkpCQyPKcCAKdP
w9u3QKXC9etEh4IQQhKMp35AGYNBI0wBWK8jnxSwBB2ReME1tMWPSJcpm812cHCorKysOeLq6hoW
Fnbq1CktflaOEZzKSpg+HdhsmD4djI2F97m45gUZiHTjQqIOqx833saKZYzclk0xo1beD9x2/UsV
bk9QP9yLT/yIdJkuW7bs5cuXNS9NTEwKCgpmzZplb29PYFScpk2DigpQVoa9e5v6lrg4oFAgLo6v
z7WysuLr/UgQRLpxIVGH1Y8bTzkim15epeu6Zr1nx6q4Ld6Tlu8Pj3v5KSs3v7AeRWV0Sc0jZ8yY
QXQISMD8/f2JDoFHSUlJO3bsqHkpLS3t4OAgLS29fPlyAqPi9PYtnD0LFAqcPg0yTV51/8yZX//n
2ZYtW/h6PxIE0W1cSAxg9ePG09o3ZXHzhi572ow3WG6+saefUrM/RzhadO0bCoWn3zAiMREtUzqd
bmRk9P37dwCQlZWl0WhTpkyJjIx88uRJ69atiY7uB1NTSE0FS0tISmrGuwICYNky2LwZ+LnDi2ix
ihksBUQgrH7c+N6vGTVo8ODBRIeABExEy3TGjBnVCSIA0Ol0aWnpEydOXL9+nTwJ4tOn8PUrSElB
RETz3ujvDxoawOca2DjMRAYi2riQeMDqx423NbQzosNivtKbfL6MwSB3B0Oy7teMa2gjsRcXF2dv
b1/T2FVUVEpKSpYsWbJt2zZiA6tl926wtATSzI1ECCGJhj2rmCMiMVdVVWVgYJDHsfPxzJkzY2Nj
nzx5Itfo+tQIIYQkFa6B3bJwYV7xI3JlOmPGDM4EcfDgweHh4UePHsUEkZOpqSnRISDRa1xInGD1
44Y5YsvCDb7Ej2iVaWJiIueWKhoaGkpKSj4+PjY2NgRGVUtpKb9XiIri9wqpqan8XgLxTbQaFxIz
WP24YY7YskJCQogOAQnYwYMHiQ6hqeh0uouLC+d8Em9v73fv3q1du5bAqGo5fhxat4bISN6vEBwM
ejKIawAAIABJREFUjo4QHMxXGAEBAXy9HwmCCDUuJH6w+nFrwnPNrIrvX75XsAEo0iq6BprylF9H
moiioGukqyCR6aiHhwfRISAB8+XzAVohWrBgQXZ2ds3LwYMHX7hwITQ0VF5ensCoOBUXg68vMBiQ
ns77RaoXymnWcjnc/Pz8+Ho/EgQRalxI/GD149aEHLHiyUbv6tUQlZ32Xvy7hwLHkSYi9fqILSo0
NBTTRDEjKmX65s2bAwcO1LxUVVVVVVX18vLq3bs3gVHV4u4OdDpoaQHhi81HRUXhyheEE5XGhcQS
Vj9uuD5iy/L09MQnx8WMqJSpi4sLi/VrP/Xx48dHRUWdOnWKwJBqSUiAqCigUCA8HCgUgoNxdHQU
iWIVb6LSuJBYwurHrQk5olxHn7+XDWUAUOTbtJH97UhTP0S7Iz5AiZAQ7dy5k3N/eltb26tXr549
e1ZBQYHAqDix2TBqFLDZ4OgIffoQHQ1CSPJkZWWNHz/ex8dn0qRJRMdCUk3IEaW1ezkNb+QIqgd+
KRE/5C/TwsJCzo1HZWRk9PT0/vjjj379+hEYVS3r10NuLkhLQ1gY0aEAAEB+fj7RISARaFxIJGRn
Zy9cuPDVq1dVVVWUegYpiouLMzMz2Wx2TEyMkZGRg4MDVj9uONaMkLiZMGECjUareTl27Ni7d++e
Pn2awJBqyc2FdeuAzYaAAFBVJToaAABQV1cnOgSEkABcu3bNw8OjsrKyiedLS0v7+Pi8e/dORUWl
RQMTRRL5sLEQOTo6Eh0CEjCSl2liYuLVq1drXpqYmDx9+jQwMFBJiURPjY0aBUwm6OvD4sVEh/LT
DMKfmkGkb1yI5JhM5uzZs11cXCorK2VlZRs9X1paGgAYDAaNRps/fz5WP2789yOy6YVpzx49fZ36
NaewjAaySq20DUy6WPayaNdKhuhp6MSL4n9tX0QyZC5TNpvt5eXFeWTw4MGpqamkelgvKgoSEoBC
gYgIokPhcOjQIVwdjXBkblyI5LKzswcMGPDmzZvql5xjKfVRUFAoKSkxNjbu0aPH2bNnm971KDn4
yhHpOYnn9uw5cSe9qo4fyhkPnDhv7the2jL8fISow/WWxA+Zy3Tnzp2fPn2qeTlkyJBLly7du3eP
uIjq8L//AQC4ukKPHkSHwoFUabTEInPjQmQWFxc3bNiw0rq2bOrRoweVWveQaXp6OgB8+vSpV69e
X758WbFiRctGKYIovE7SZFd8OOf/v6CkigbPUuw5e1/AWDMFMncoqqmpFRcXV//Z3t6+a9euQUFB
xIaEEA9KS0u1tbVrvgrLy8u7uroaGhoGBgYSG1gtN27AwYNw+jQoKgrmgrNnw/79MGsWYMNFSAIF
Bgb6+flxLvUFAEOHDk1OTq6qqurZs2d9j618+vRJWVl5+/btgwYNEkqkoofHfkRW0aNdS34kiNJG
fcaMcupt0cFIW0UOqkpyMz48v3/r8sW4dDqUJwUt2WX6r5+NmoROfExNTTUxMSE6CiRIBQUF5Hy+
YdasWZxjJRMnTrx69WrNyAt5DB0KQ4cK8oLTpsGxYzBtmiCviQhB2saFyInBYLi5uV25coXzoJyc
3OzZs8PCwmbMmLFq1ar6OhG5YfXjxls/Ij395BTvQ58AZDpPDAyY3FNDiusUZmHyv8sWH31JA2jn
e+qIT1vSDjm3aD8ihcJzTy0iKXKWaUpKSocOHWoCa9OmjZaW1rx58yZOnEhsYKKCnMUqabAUUNPl
5+fb2tqmpKRwHmzTpo2Hh8fp06ePHj06bNiwZl0Qqx83nrr3GN8Tbn0CAPk/lm2aUleCCABSrXpM
3LiirwIApN1K+N70BbcRQs3n4eHBeXcbOnSogoLChAkTCAypFrz3IoQE5cWLF8bGxrUSRDs7Oysr
q9u3byckJDQ3QUR14ilHpH179Q0A5K3H9NZq4AJUDdsxNgoA8O1VVuMPGImnx48fEx0CEjASlmlk
ZGRycnLNS1tb2ytXruzbt6++WTjCR6eDgwOsXEl0HPULCQkhOgRExsaFSCg0NLRnz54lJSWcBydN
mpSXl6ehoREfH9+uXTseLovVjxtPOSKbVkoDAGXdVo0MIMuo6akAAK2sSlK7EKysrIgOAQkY2cqU
zWZP45iLR6VS27VrN3r06B5kemx44UK4cwf274equhZBIAN8rpkMyNa4EAmtXbvWy8uLwfg1Oikn
Jzd37tzr168vWrQoODhYXl6etytj9ePGU45IVWilAABFX7IrG8z92FU5nwsBQEFNQUIfWYEtW7YQ
HQISMLKV6eHDhzMzM2teOjs7R0dHr1+/nsCQuCUlAZUKe/aAXAts3Z6bCzY2kJvL10UOHTokoHAQ
78jWuBCpsFgsNze3NWvWcM6r0dXV9fDwuHbt2vXr16dOncrP9bH6ceNphiYr65Kvx453QDVfcGav
m0F9z0YzvoUvGBf4jAEdF4UeGq1H1jQRn1lBzUKqMqXT6dra2kVFRdUv5eXl7ezsRowYMX/+fGID
q6WwEB4/hsGDW+TiAln7hlTFKrGwFFB9SktL//jjj1evXnEe7N69u7a2NpPJDAsL09TU5PMjsPpx
460fUbu3c1cqAOvlrsVbb36qqON3yq78Er1zSeAzBgC1q3NvbbImiC0N+67FD6nKdOPGjTUJIgC4
u7u/f/9+5syZBIZUp1atWipBFBRc84IMSNW4EHmkpaUZGxvXShCdnJyYTKaZmdmtW7f4TxABq19d
eFsfUUp3yLw/Q2ec/gxfIzf43Dvbb+igP7qZGWopywKtNO9ryouHt2/e+1A9nbTNn/OH6Nb56LMk
wDmw4oc8ZVpeXs45OKKpqZmWlrZmzRq5lhjQFXf5+flEh4BI1LgQeURHRw8fPrzW3nrjx4+PiYnx
9/efN2+eoD4Iqx83HtfQpih0mbp9Ve7cdTezAMo+xl34GHehrvP0hqzaPrUzqbdZQUhU+fv7cy6a
7ebmFhsb6+PjQ2BItbx+DUZGoKJCdBwIIdG0bds2Pz8/ziFgWVnZCRMmXL169dixY7jATUvjfQxY
Rs9x+Yl/V4/rbVRnn4WcUZ/xa/49sdxRj7SLZwuDqakp0SEgASNJmRYVFR04cKDmpZGRUWJi4rp1
66SkyNJr//YtWFvDoEFApxMdShNYW1sTHQIiS+NCZMBkMl1cXP766y/OBFFLS8vLyysmJiY6Olrg
CSJWP2489iNWoyq2Gzxr62Dfssz3L998zMgtrqCDjIKqlqFpZ/MO+kpk+aeKSKmpqUSHgASMJGU6
d+5cOkfy5ezs/OjRIzc3NwJDqsXbGyoqQEoKZEThe+KTJ0+IDgGRpXEhwuXk5FhbW3/+/JnzYMeO
Hdu1a5eWlvbw4UMtLS2BfyhWP2585Yg/SCnpd7bV72wrgEuJnYMHDxIdAhKwgIAAokOAnJycM2fO
1Lxs3759TEzM3r17ybNoNpsNjo7w/TtcvEh0KE3j5+dHdAiIFI0LEe7mzZujRo3inEgDAAMGDCgs
LNTT0ztw4EALTbnG6sdNME96s+mlOZmZ2YVldJBRVNPWN9BRkSHLv1WNatG1bxBqCW5ubhc5ki9f
X9+UlJTo6GgCQ6oTjQaysi3+KQJZ+wYhRAaLFy/euXNnrczEy8srPj5+7ty5f/31F1GBSSb++hFZ
5elxYadCrt1+9u333RPk9CwGOHt4e9gZK0rqqjfVoqKiBpN8zQ/UTISX6ffv3y9fvlzzslu3bjdu
3CDnVnJCSBAFJTU11cTEhOgoJB3hjQsRqKyszM7O7unTp5wHFRQURo0adfv27RMnTjg5ObVoAFj9
uPGeI7JKXp5e7X/oUVFdP6zKenYz+NnNUGvfzWvHd1OV3DzR0dER1+QUM4SX6fTp01ksVs1LKyur
oqIiW1uc7MEXU1NTbKqEI7xxIaLExMSMHDmyrKyM86CBgYGZmVn1BMQ2bdq0dAxY/bjxmiNWfji1
eM7hN0wAAJA37Nm3V1dTfU1lOagqzfv68dXj+KSMSoCix4fmLmEf3jPBjMftExFCv8nOzo6IiKh5
2bVr18jIyJiYGAJDqmXtWujTBxwdhfeJioq//o8QEi0MBmPatGn//vtvrfysd+/e379/Nzc337Fj
h4xIPPgmjnjLERkZ4QHVCaJqr6mr/cfb6NQuP3p24unNa448LmG+ORwQPuigl6Egno4RPbgwr/gh
tkznzJnD2YloYWEhJSXVpUsXAkPitGMHrF0LrVrB9+/Ce5w5MBCkpYHP6eYfP34UUDiId3jDlDTx
8fGjR4/OycnhPCglJTVy5MjY2Nh9+/Z5eXkJLRisftx4GgWmf4258h4AwMx3b8Ak7gQRAGR0bCYF
7PM1AwB4fyXmqygskNYScIMv8UNgmRYWFnI+qmJubh4VFbVixQqi4qmluBj8/YHNhvnzhb3eDf/P
I+JkRDIQeOOif7kwf8Qgu8FL7pc1fjISptLS0lGjRvXr169Wgqinp+fk5PTu3bvY2FhhJoiA/17X
hacckfbt5TcAkPlj0sh2DcxJl2s3cqKtDAB8e/WNVv9pYs3T05PoEJCAzZgxg6iP/uuvv5hMZs3L
Xr162dnZdezYkah4anF3BzodtLRg1SqiQ2k+f39/okNAAm5c7Io3J9aEaU2b1EGmpu+dmRnm67np
abkAPwY13+7du3V0dMLDw2sdHzZsmJaWloaGxsOHDzt16iTkqAi8t5MWb0+TVE8b0DRp3fAuexQF
fVNNAGCzJHYWaGhoKNEhIAE7dOgQIZ9bXl5+4sSJmpcdOnSIjo4mT2aTkABRUUChQHg4kGaVxmbg
3PkaEUWQjYtVlLhvY5zV8gV9NaTg5z9B9IyoayV9RnXGyatE+T975x3WRLbG4V8SCB2kiVJsiL2L
olJUELuIvddde1s7lnXVXVe9ruWuq17d1S2KHUXFrmBHpKmoiArSRJTeEkhI5v6RNY6AEDJJJmXe
h4dnZpic85FT5ptzvnLkyBFbW9vvvvuOz+eTr1tYWEyfPj0qKmr27NlHjhwxNTVVvWx0ze3qjFxW
gvo2TWzwMLMkp0RU/Y2ikuwSADbONrpqbzpq1Ci6RWBQMHS16caNG8lZ7b28vJKTk9UkgxxBwN//
37jZPXrQIEBSEijuFTMxL9QBxQ0u0ccbW3ekDNq6o61JQYpERRS83jdh+tFMALN8gwA4Tv7rnxnO
uvpsUj0hISGzZs3KyMio/Cdvb++SkpL4+PiwsLDWrVurXjYJzPO6MnKtI3Ib9PaqCxSFX3hSWM0K
IVH45MLDIsCuV+8GmhMmTbGoZ9Q6BirQ0qYCgWD37t3S0wYNGty/f199FhF//BHZ2dDTw+nTNNQe
HAxnZ5BCRsrD9evXFSQOg/woanAJkk9tPIhv1o1u9O+jhwDAdZn2g7+Dy8wjoXfu3L59+3bgt4yC
qBpOnDjRoEGDIUOGVFYQGzZsOHHixLi4uAkTJty7d49GBRHM87oq5NtrNmg2adlAGxReW7/x1MsS
cVW3iEtentqw/lohbAYtneCilLw5DAw6w+7du3m8zzZU/fr1MzU19fHxoVEkKdnZ2LgRBIEtW2Bu
ToMA1659/s3AQJQ8O7ghpOHSlX3qcj5fBFDy/OxDy8G+jvosFpvNZrM10CRCoyAIIjAw0N7efuzY
sWlpaRUyhRoZGY0cOdLIyCgnJycyMnLBggVstu6GUlZb5NprJoR8Vstvf14qWL/9xu4Zwy73Hja4
d9c2TeytTLkQFOdmJD17FBpy9tYbPhx8l63/piUK8/O/LIGlb2Juojnp+uSHxVJMtkMG9UH1bUoQ
xObNm6WnNjY2T548UZ/8wsOGQSSCvT2WLqVbFApYWVkxkS9oRwGDS5z34L8/R3t8v7uLBUnjIACi
IPbME/uhc0iKI4PyOHny5Hfffff+/XvpFYIgDAwMysrKuFzuoEGD0tLSEhIStm3bNnjwYBrlJMM8
rysjl47Ii1g1eJU0XQ7/TdjRXWFHq7zz3fVfZlz/pYo/dNx85VcPE3kqZ2DQNU6ePJmTkyM9HTJk
yIMHD4YNG0ajSFIePcL9+2CxQArsrZHk5eXRLQIDdcozL2/ZnTXyl+UtyQ6VBABxXuTZBOfhy62Z
tSolc/Xq1ZkzZ6amplb+k0QD69y589OnT9evXz9+/Hhm7VDN0c3I1qqDMXLSPlTfpqtXr5YeGxkZ
JScnr1ixQk3mVoEAZmYYNw4dOtAtCjX2799PtwgMVAdXWdLxDUeMZv3m71jJ0FCcHR6c0nJCJwsd
2L6ijZiYmIkTJ8bHx1f+kyTtcl5e3pUrV8aMGTNnzhyu+mVzZ57XlZFLR+Q2Gjp3hiuVsNj6Do3U
rnsoBcZZUvtQcZveu3cvKSlJejp48ODw8PCJEyeqUoZq8PDAixdwcKBbDsrMnDmTbhEYKA0uovjJ
gQ3XW6zY07OqpcKS12FvDFrZ6BFABS2x9Nn2qTvs/rN/YoPPiqW45FXwLxv33khhN+q76OeVg5x0
43klP7m5uWPHjq1SxzIxMRkzZkxOTk5YWNiKFSvOnDljZGSkegllgXleV0a+2DeOPuMmK1oS7eTA
gQPMs0fLUHGbSpyXjY2NeTwem80uKSlZsmSJWr2Ca4GCCODUqVNM5AvakX9wiXPvbF9zMqkACwdU
4VvP6sS1a9+04MD0vn8CdmP+CJzfXOpIadhm6fFDFe4vfXM7s+u608vM436bu2X/k94/dWECKn4F
sVi8adOmH3/8USisuG5kZGQ0ZsyYkpKSkJCQJUuWBAYGmpiotYUZ87yujEosNAkxwVJfFzILC4vC
wkLJsZeXV+vWrffu3auowhkbWO1DlW2amZlpb28vqY7FYtnY2PB4vMzMTFoCzKotc+di3z7MmQMq
A5cZquoAtVb496MVSiAIAizWJzdmQiwmWJ9dmonC+99PP+m+b+cAW/79xaOP+R/7rSfJN1/8IXju
kpRFhxa1VHlsjoQEODhAzQd6VFTUsGHD0tPTK1zX09MbMWIEgNDQ0IULFy5atMjMzIwOAWsHMwlU
Ri6TprK3t6KzawifLUX4/tr2nZG6miuTSQKrfagyp+eKFSukcxZBEFlZWUuXLlUHBfHDBzD2ewwK
h9rgYklgfwmHw+F8VgpZX8S8Eec9OvPSeXh3azYAQkywWeRHovD91d8uNZo7ubnKFcRHj9CjB6ZN
U3W9siMUCqdNm9a1a9fKCmKvXr2GDx9+8+bNFi1avHr1au3atRqhIILJ11wVcumI5e/OrvluX0xh
lYERv0CYcfWn2T+eT9HVdM1ITEykWwQGBaOyCCkCgYAc07V9+/aWlpbqkFFUKESzZvjuO1y+TLco
ioNZP1AHVBx+SJx9Pzi1zfCWcd95enr2XxVTFLtmgKdnz0X3SgBx7r1ff7zTPuC7Hpaq9w578wZ5
ebh1S+UVy0ZsbKyjo+Nff/1VYdQ0b9586tSpT548cXZ2TkhIWL9+fZ06degSUg6Y6FeVkdOvmShJ
ObFshcW+HRObG391E1mYcfnHOT+H5QIN5RWPgUF3+e2338rKyqSnHTp0cHFxsbe3p1EkCQsXorAQ
Rkbo3ZtuUVRFTAxsbeHkRLccDIqkPCPsfJbr/HZ127vdvYuSewtHnhx18r/uJgQLBdEHNl1ruPSH
EU0M6TCTatoUlpbqOL4IglizZs3WrVvF4i/WiIyMjMaPH3/37t3c3NzY2NiGDZmHvpYg1wuSnrVL
fUD4/MCiH86lfmWJUPju8sbZP4flArD28WtmSEFGTUZN0ukyKBCVten27dulxzY2No8ePZo3b55q
qq6GlBRIEt///jsM1WNc+/t//i03vr6+lS/Gx2PsWJibo3NnNGtGqXwGWVDphClMu3apxGNoC7KT
LYvNYrPZLH7c34GPwv471dfL07Pn/Jv5Cltjzs4Gi4Vp05CcXN1tXbviwQMcquhKQzO5ubmurq6b
N2+uoCB6eXn5+PiEhoZu37793LlzmqsgMs/ryshpoSl8d3HdjC33igDrvht+X+1t+2XkemH6pQ1z
Nt/OB2DdZ93/VvvWU+O0mIzPCkOtUE2bhoeH9+jRQ3o6adKk6OjoZ8+eVchnpXpatcLLl2jRAi9e
0CvIF+TlgaIpEblZP3zApk04cQIfPwKAmRlEIjx8iLZtKQvKUC2qmzAJwfvQTYtOt9m5e5RD1dtp
BEH8KwtLcWn7RCLo64MgwGbD3h7TpmHxYqpdVzU8evTIx8enuLiYfNHc3HzcuHHnzp2bPn362rVr
1TaojYwwz+vKyGlooe8w8Idf57bnAjnXfli0O7KA9FYhSL+4frZEQbTxVXcFUdmoT8I0BkWhmjZd
tWqV9FhPTy8/P3/OnDm0K4hHj+LlS3XMqkL9KTtz5kyRCD//DGdn1K+P3bv/VRABtG6Npk0ZBVEV
qGrC5D/dMXnmEYPpa/y/oiAC+Oz9osBRx+Fg2zYAEIuRno4ff4StLdq0we+/g2RXonb8/vvv3bt3
r6Ag9ujRw9vb+/bt2yEhIZs2bdJ0BRHM87oqqGjN4qInv89fcCSJAKfl9H07p7Y0YUGQFrJ+zta7
BQBs+/6wN6CP+iuISl1HZGCQg/z8fGtra+mGzqBBg8LDw9++fWtubl79B5VKWRksLcHnY+ZMrXVq
lijhVlYgG6936AAbG9y4QZdQDFrFwIG4dKniRSMj8PnYvx/qFp6PIIi5c+f+73//k17R09MTiUSj
R4+OiIgYOHDgtm3bjI2Z6JFaCxWHLbZZ+xk7Nw+pB4jiDy36/kxyYeqFH6QK4nqNUBCVTXR0NN0i
MCiStLS0Bw8eKLuWn376iWzxY2NjM2bMGHoVRAAzZoDPh4kJfvuNXkGUgiRfc0kJjhxBt24wNUWL
FrCwAIA3b5CYCIJgfpT+ExUVTbsMyv6ZNOlzr3NywvDh6NMHXC7c3NC69ec/BQaiUlQZVSMSifr0
6UNWEAFYWloSBHHixIk9e/bs2bNHmxRE5nldGeq778LMKxu+3XS7AOCYckTFIgC2fdfvW+VjpyG5
oBl7RAYZSUtLa9CgAQA3N7dly5YNGzaMw+HU+KnaQhCEpaVlQUGB5NTFxYXH4125cqVNmzYKr0t2
Xr1Cy5YgCJw9i6FDaRSkambNorq0WWGofvyI48dx5AgSE2Fri4QEXL8OJlOXstGFCdPdHdHRkLhI
PXiADh0wYQJGjPj3hUTC+fMYNQrOznRa/ZaVlXXr1u3x48fki507d7a3t8/Ozj5z5ky9evXokk1J
0Nr9+E/+M2b+hTzAZsT+Y9+1Ug9/QGrriBL06/Vb++uCTobAvwpivw0apCAyMMiISCTy8vKSHEdE
RIwePVpPT6+kRPHR4S9cuCBVEAG4u7s7OzvTqyACGDIEYjE6dFBHBXHuXBw4gLlzFVlm3bpYuBCP
HuHBA4weDQDjximyfAbdJDMTDx6grAzp6ejVC0+f4uZNTJ/+hYIIoLgY5eXIzqZJSoDH47m6ulZQ
EIcMGSIWiy0tLcPCwrRPQaSZkrizYXkAUH/AYBd1URAhU3xEQlhSWCKsVre26rP8h7Rlq4Lfmbsv
2TK7k0Fxfj75zyx9E3MTfbVNxqdMmBja2gFBEL169UpOTsand01jY+OSkhI+n6/wDKTr16+XHhsZ
GSUmJs6fP1+xVdSWggKwWDAxQUgIvYIokaioqCqvN2+OjRuxYYNauxRoDVo/YdarhxUrMGUKWrWq
7jYPDzRr9sWutCopLS11dXWNj48nX5w0aVJYWNiCBQtWrFhBj1jKh77uRxTEBN0vBoBGfv0bqpOR
ngwrqyX3FvZfFUuplo6br/zqoa65vBmfFYYaGT9+/LFjx6SnbDZbLBZ7eHjcvXtXsRXl5OTY2tpK
R6Wfn19UVNTbt2+5XK5iK6otHz6goEBNYwSmpqJ3b4SFoUEDukVhYNBwBAJBly5dnj59Kr3CYrFm
zZoVFBT0559/Dho0iEbZtBZxzrXFI3+MKQeaf3dy/4j6ijdhkhvVJxnSLdQhcxoDRdasWUNWEAHM
nDkTwNGjRxVe1/r168mvbfr6+t988w3tCiIAOzs1VRABNGiAxESqCuLWrVsVJA6D/AQEBNAtgk5D
EIS3tzdZQWSz2QsXLjx79uyZM2e0XkGkq/uJs+4FxZYDYLcf4WWnRgoiZFpHFKbfPB36TkihEn0H
75E+juq0fEqG8VlhqIZ9+/bNrWTpVr9+/fPnzysjKL+lpWX+J0sNFxeX3Nzcx48fOzo6Krwihgow
Q1UdYFqBXqZMmfLPP/9IT1ks1uLFiwMDA4OCgtzd3WkUTDXQ1P3K0499O25vIsB123j6P71pyA9e
DTLYI+o7+oybrHxJtJM+jCekJrNkyZJdu3aRrwwaNOj69etHjhxRhoJ469atfJIpb/v27UUiEb0K
YmgouneH5gfHrZkmTZrQLQIDM2HSyY4dO8gKIoDZs2cHBgaeOXOGnPNJi6Gn+wlTr51PBADjHiNc
66iVgghmr1nZXL9+nW4RGOQhMjLS2dl5586d5NdKX1/fp0+fHjp0yNvbWxmVkr1VuFxuRkbGlClT
lFGRjOzahb59MWECjSKoDq33ltAImAlTQnExJkzA5cuqq/HWrVvLli0jX5k4ceKZM2eCg4N1REEE
Td2vLOnixXQAsOg5vL2Z2vn2MjoiA8MXREdHu7q6du3aNSkpiXzd1dU1IyNj7ty5E5SjNJWWlt6/
f1966uPj8/r16wEDBiijLlkoLMSKFRCJoP5p7l++hK0tXr6kWw4GBgVx/jyOH8e0aSqq7uPHjwMH
DiS/D/v7+9+4cePw4cPdunVTkRA6Cv/luesfAcCmj39LNQxHLqeOKPoY9uvagIC1O65mlH/tnvLM
67vWBgSs3X0nSySveBqPlZUV3SIwyERJScm6descHBxcXV0rRNtns9kAoqKiBg0aFBAQoKQ2PXjw
YHn559FkZWU1ZswYGr1VRo2CUAgbG5ASR6spv/6K7Gz8+iulQpydnRUkDoP8MBOmFIKASCVYDZFo
AAAgAElEQVRPToIgPD09+Xy+9EqPHj3evHmzatUqX0mkb52Bhu6nrmERpcgX6lqYfuXgqdspcJg6
0/arJehZu9RJ2hiUhoyW/j0mOOlmUG1Jgi8GteXJkyeHDh26detWXFxcldbKbDZ7wIABFy9eHDJk
yJYtW6C0Nv2VpOPUrVs3IiJCGX7TMhIejuvXwWLh3Ll/UxirM5JkYBRTglVYNmagBWbCVD3Lly9/
9eqV9NTJycnc3Lx169YLFy6kUSpaUHn3U9+wiFLk0tzEubF3UgA4+PZ2qua/0nfo6et48FD629tP
8sY52erktvbJkyfpFkGtKS0tzcrKys7OzsrKKioqEgqFYrHY2trazMysfv36NjY2ZmZmCqxOLBbH
xsbeuHEjIiLi8ePH6enpQmF1Hvtdu3ZlsVhv3749e/asv7+/5KIy2jQzM/P169fSU29v78ePH3fp
0kXhFckCQWDoUBAE+vSBRlgi/fIL9PSwZQulQrZQ/DyDImAmTBXz9OnTnTt3Sk/19fV79eqVmpr6
m1YmZa8JVXc/cW7E6UelANDc38dBLVVE+XREQebzDACGTdvWq/a/0rdr52KMdF5G3HvBYFt1XEZV
OqNGjaJbBLXjzp07P//8c2xsbE5OjkiG3RQWi8VisfT09CS/y8vLCYIwMzMzMDDgcDimpqb6+vom
JiaGhobm5uZ6enoWFhYGBgbGxsYfPnwoKCjIycnJy8vLy8vLysoSi8VVLhZaWlqS3yBZLJaHh4ex
sfGzZ89Wr149c+ZMPb3PI0UZbbpp0yayYGKxeBJdORaAH39Edjb09BAURJcItYa6grdy5UpFCMJA
CWbCVCUikWjgwIFisVh6ZcqUKdevX4+MjFSHmKyqR8XdT53DIkqRS0cUleSUADCxMavhv+KY2JoA
vOLsEl21SDx16hQz60nJzs4eOHBgZGRklX91cHB49+5d5esEQRAEIRAIAJR9SoiWk5NTTUX6+vrV
LxBWQJof2dbWtmPHjrm5uS9evFiwYMHp06dNTU0r3KyMNiXH6G7Xrl1oaOi2bdsUW4WMZGdj40YQ
BLZsgbk5LSLQw40bN5jAK7TDTJiqZM2aNeQp18PD4/r16wcOHLC1taVRKhpRbfcrzwg9+4IAwO0y
opu1um60ymclyNbjAGJBcVkN0SYJQbEAAEtd/3vlM3r0aCYkrITXr1+7uroWFhZK1gItLCykmpnC
MTAwqJWO2KhRo6SkJAsLC6FQaGxsPHfu3AEDBnztTVrhbRoTE0NWeTt16mRtbd2Aprxyw4ZBJIK9
PZYsoaV+2vD19WWGKu0wE6bKSE5O/uWXX6SnZmZmDRo0aN68ed++fWmUil5U2v3UOyyiFLl0RH2r
hpYI/1gU/+SDsEM1dpblH58+LwBg6VhHNz1WAEtLS7pFUAsyMjI6dOjA4/E4HI5IJNLT0ysqKlKx
DIaGhqWlpZJjCwuLpk2bWltbC4XCtLS0rKysTp06TZs2bfz48ap3bdu0aZP0mMPhZGZm0hUWMTQU
9++DxcLFixrgqkImKQlMDGwGBtnx8/MTiUTSzCKTJ08OCQkhZ+FjUCpqHhZRily6G9ehS2vj4x95
qacDY/wD3Cyq1oDFhTGBJ1MAGLbo6qiLtg0AkJubS7cI9FNeXt69e3cejwdAMiuJxWKJEYy/v79Y
LObxeEVFRY8fPwbQtGlTfX19Q0NDFovF5XLFYrGenp5ku5nNZpeXlz969IjD4Xh5eZWWlkr2oPl8
fllZmUAgKCoqEovFUu2TzWabmZkZGRmZmZmZm5vHxcUBcHd3f//+fUZGRmFhYcuWLd3c3Dw9Pdu2
bSsJcCMLin3RJAjiypUr0lNPT8+IiAi6LPeDgsBmw88PHTrQUr+cBAdj2DCcPYtPbkXywAxVdYBZ
RFQNO3fulMyHknnVycnp8uXLBw4cMNcp+5JKqLD7qXtYRCnyre+ZtB3paxV2Ljf/8ppVdlt/mtLZ
qmI55bkx/3y/5lIeAMs+o9upsZbMoHTmzZuXmpoqfWE1NTWVqHETJkxo2bKltbW1ra2tlZWVxJ2Z
x+OVlpYWFxcLhcL8/HyRSFRQUCAQCEpKSng8XllZWbt27YqLi/X09MrKyiRXpL+5XC6Px9PT05M4
oFhaWlpaWlpZWUl+t27dulmzZi1atGjRooWLi4uaGGVfunRJoj1LcHR0dHBwUKw3t+z88gs6d8b0
6bRULj/Xrv37m4qOyCz5M+gIGRkZK1askJ4SBJGSkjJ58mRd3mVWNWofFlGKnHvARm2mL/G5tfZm
QVncX98Nu9xpwACvzi0a2JoborQwK/Vl9J3Ll2M+iAHAwnvpjHYmihRZo/D19dXx7FLPnz///fff
ARAEweVyORzOnDlzAgMDw8PDnZyc6JZOHhTbplu3bpUeGxoaxsfHk7eeVYyRkeYpiIpi1qxZ+/fv
p1sKXYeZMCVwueBwUMlfTjF4eXmRw/UPGjTo2bNnuhnspgKq6n6fwyIa1sPTy+dfVHkX29Cpu09H
a/n9nQWv902Yfr7tjtPrusivg8lrJ8i28lq5c37hgt8iSyD+EHPxr5iLVdxl7rZgV4CXldpaYyqf
Gzdu0C0CzYwdO1a6gC8UCgUCwT///PPo0SMNVRCh0DYtLy8PDw+Xnvbs2TMuLo7xrqWFAwcOMDoi
7TATpoSRI1FWhp49FV/ynDlzyKnJHR0dY2Jijh8/TtfehVqhou73OSwiSmMP74z9ym16ndcFUXkW
CDOiEgzaDB3VltIinfy+JCwjlzHbjrUMPrDvn5BnlS15rNv5TZ0z06/NV4wVdYWZM2fSLQKdnD9/
/tmzZ9JTLy+v27dvnzt3TnMVRCi0TU+cOEF+oTc1NZ0wYQKHo+pAWbm5IAhYW6u4WvWCCbmiDuj4
hElGGWnhT5w48b///U96yuFwGjdu3L17d09PT8VXpoGopvtJwyJWj2G3kV0tqehP+o3G7ToyjkIB
AACWAow0ibKcpOfPXqV8yCsRgGtqadegeZs2ja25GmKDaGFhUVhYKDn28vJq3br13r176RVJa3B0
dJTG39LT0xs7dqyZmRnz9Urp3r37w4cPJcfm5ubW1tbBwcHt2rVTpQxCIZo3h74+QkPh4KDKmhXG
3LnYtw9z5oDpWQwMX+POnTve3t7ktAV+fn4pKSmPHj1SE+Nshq8jzrn63cifCqdsGV8aEhgSnlQg
qtN+2uatU52zwv7e/09IeFKByLLD9C1bprYyYQEAUXh/7ciAt+P++XtaY07O1e9G/lQwcf2w4kun
r0WlFIqNGvdfunVFv/oypHZRREwaloG1c6eezp0UUJTWkZSU1ERXY3KEhISQA7QOGzbsypUrL15U
bXqhQeTl5SnEv6G8vDw6Olp66u7unpiYqGIFEcCmTXj7FiYmur6OyKAOKGpwMVQgPj7e19eXrCB6
eXk9ePAgLCyMURClqG/3E328GxRbzra6+vd9n4GTA/pmXd2159Y/u/6XoZ8g7DxwckC/rCs79tw+
dvzl2I2djQCI8yLPhPOdZ/k66UOUeTcothwmYdc+TJ6yafwadvzvC9eE/HV5vPf0xjUriboat1BV
ODs762w0h6VLl0qPuVxufn7+mjVrtCCCv5WVlULaNCgoiBzo28TEZPjw4dSLrS1OTjA2xj//wFCt
veuUjtTvnoFGFDW4tICMDFhZKWZUJiYmurq6SlJVSWjSpElBQcH333/fpk0bBVSgLaht9yt/H3Y2
HibdZ2zbNNhRHwDPMPTQrVvvsjv/sWeAgz4AHvf6wdtPTQ0k27finAdBUaLWS3vZ66E8PexsPOr0
Xf3fNV7WbAAEt6sDK6TIhCvTRjZVHbE8L+F+6J3IuKT3uQU8Tqt5m+e3+bdPi3kf0j/yxSyupX19
C30N2XdmUBQxMTGvXr2Sng4ePPjhw4chISE0iqRukB0Jzc3Nnz17Rg5IoTK++QajRulW2j0GBjXn
0SMMGABvb5w6RbWoxMTE9u3bkwNs2djY2NnZdejQYeHChVRLZ1AFwtSr55L0XdcsH+goWfgTZsQk
8Lld1y3r5yC5IHgX/arUqL1nIwMAEGXePhPH6bjOw5YNYfLVc0ncrj/M8/iU7o/3+m4iUW9oJ1uZ
DN8p6IjigieBmzYcCM8ilZb/eSWbKAzfPGX7MzG7XcDp3YNsddR1JSoqim4R6GHt2rXSYxaLJRKJ
FixYoB2bGgppU6FQGBERIT318vJ68uSJq6sr9ZLlgFEQATAhV9QBnZ0wK/DmDfLycOsW1XLCw8O9
vb2l+aUAWFhYtGrVysnJaffu3VRL1zrUtPuVvbl48Z1pr6Wen/SosjeXrrw37x3Q45PaV/rm4rVM
M8+V7UxZAITpN4JfG7pt7mrJRlnCxYvvTHsu7f4pvgxR+PjMvWLHcf0ayfY0lld1ExfF7J49/5OC
aGJlUekOjl2fqb1NAPHT8xE5Yjmr0Xg6d+5Mtwg0UFRUJMkdoq+vb2Rk5Onpeffu3dmzZ9Mtl2JQ
SJtevHiRvNFcp06d4cOHszQr/512wYQcUgd0c8JUEocPH/b09JQoiJK5xdTU1M3NzcLC4tChQ6qP
n6D+qGf34788fy3LymeYNIYN/+X561lWPv6tPl3gxQffyLbyGdbGBAAEyZcupJh6Du9owar8WXFe
ZNBDflN/XycZ/FUAuXVE/vPffzydDsC868ydZ0IvHw3oWOkelmmbId1NALy+9bJYHbf4VQE5QrLu
sGHDBolVh1Ao5PP5d+7cmTx5cp06deiWSzEopE337NkjPTY3N3/x4sWwYcOoFys7V6/ixAlVVqhE
JOkhKCaJOHDggEKEYaCCbk6YyiAgIGDy5MlSJxXJhGxtbS0QCI4fP64dWzoKRx27H1EcdzYs366f
X3ND8oV6A4Y0+3Sh6OmZOwX1+vlJLpS+On8l09Lbv61J5c9CnP3gdLSozfDe9rLuIculIxKFMUcv
ZwNwnLRj0yRX269ZGxo7e7iwAWHKi481BwPSTgICAugWgQb+/PNP6bHErXvBggX0iaNgqLcpQRD3
7t2Tnnp5eaWnp3t4eFAsVnZevcKgQZg+HcnJKqtTifj7IzeXUiI+ALNmzVKQOAzyo5sTpmIpKyvz
9vauoO7Y2dlZWloaGhoGBwcbG6tzfmA6UcPuRxRGn75X4jR4YGPupwsxQfdLGvoN+LRXLC6ICXpQ
0nDwIMmFkhfBobl1+/m1MKz8WZS/v3XmGafTCHcbmVU/uXTEsvSIF6UAWk0YVm2mQZahXcM6APLT
8oTV3KbNqOfatVIJDQ3Nzf0cVN3Nza1Pnz7aFACIepvevn2bbCFkZWU1dOhQVW79rF4NsRjNmqFR
I5XVqVyoB6xQ05gXOoYOTpiK5eXLl05OTmFhYeSLzs7Ozs7OHh4eUVFRFhaVDcMY/kX9up8492FQ
ZFlTf99/nVUgzo0IelTabJjP5wsPT0cKXIZK7iAKHwfdKXQaPLAJt/JnIUy/fu61oduILrWIzS2X
z4oo/10BAEuXRmbV18TmGukBEJQIdHWvWU1tYJXJDz/8ID3mcrmpqanfffcdjfIoHOptumvXLumx
gYFBQkLC+vXrKZZZK3buhIEBmAStZMgvNgx0oYMTpgL59ddflyxZQg6CCKB79+45OTlubm7btm1j
bBCrR/26H9u6369h/b640Pe/YWSzGrZN/923+n86Y5m7b7p299+Tip+FfqOpgXen1lKC2t3+SQ4W
CwBRoydKedHHYgBcY03JucJAkeLi4gcPHkhPvb2937x54+fnR6NIakhoaKj02MPD49WrV97e3qoU
wMkJgYEKWHtjYGBQB3g8no+Pz6JFiyooiKNHj05OTl68ePGOHTsYBZFBDuTSEfXqONYBkP82nVet
mliWcj+OB8DG2UZGFxqtw9nZmW4RVMrWrVvF4s+dwszMbOrUqVpmH02xTWNjY4uKiqSn9evXHzRo
kJZ9RaqHuh0RXYGHGMjo2oSpEB4+fNioUSPymycAU1PTKVOm3Lp16+DBg1oTU0LZMN2vCgg5EBc+
WNXHw8PDa3bw+3KCIAii+O4CDw8PjwV3iz/fJXx/fpG3h4eHx5CtT/nyVKMizM3NAQQBBCAGxADB
YsnzAxARERUKr903/OOPhNy1S2XYvp3S1xESQkUAMUAAxwEADRs2rFu37uvXr2stQ1YWpS9B8uPg
QOl7IAjC1LTK5qhFDzE3J3JyKpQ6ZcoU6ejjcDheXl5BQUFflcHZWQFd4lMTCIWEWFz772HQIAXI
EBtb+4pJVDs05mAvQMzB3hpk2L27mhpqHqqHDyvge5gxg9L38PIlwWZTHRrt21OSgSAILpeqDMbG
RFFR5YJrMWE2bEi1OVgsIiWF0vfQq5eShkZgIMFiETY2NdQvFouXduki2aUj79W1BPoDnYFXMspw
7Bil70EhQ2PePEoyPHhAtTNItkcpwuEo96tWOXKtI7LM2o/xtQLEz37bfCaptApbQ4L/9vKWBf+J
FgBw9BvRXP2zfDUHALAkI40g5Pnp1g1nz1Yodv/+/bUQ4vlzyF275KdDB1AMBZySQkUAFpAEdAAA
uLm5tW3btmnTprWWgc+n9CVIfkipouWEzweqaI5a9BBz88piSCJHSujSpcuTJ0/69++Pr/HxY5Uy
1OKnY0c8eiQpbMgQDBny779VC96+pSqDmxtI/7U8VD80pFQjg6srSL7klVm5cmUNMrx5Q/V7aNIE
d+/WUEv15OVBLKYkg6kpXr6kJAMAgYCSDAQBAwNUZQC6ZcsWWWWQfJyKDK1bIy6O0veg5KFRfbzU
zMzMVq1abY+MrPAEHg7wgabAfcBFRhkoRuumPjRatQJFW8D376n2SVPTLXqUsxOLRMr9qlWOnN+I
cdtvl/W9u/pafsyvUyY8HDHSg5sLAMVpzyJvZ72MvX/j0r0kyZOo3vDlY5voxj5aVZk1Z86cqVIZ
9PVBt9GJCBAAHA4nIyNj/vz59ApDCeoRrY2MKlzIzMz88OGD9NTR0dHe3r66UBSKk2HnTly9Ci4X
PF5luapFCd8DDXC51Q+NWmgncsPhQJ9usxsWSwE5gFksENT8EL/SJWrW1MkyUIR6t1SaDB06oF49
VJO//fTp0xMmTCCnYCYAY4AH3Af2AbWItmpgADbdidD09NRhaKw0Man5Niqow1ddS+TVmtlWHst3
L+Uv2n439+OjoL3/rlO83rtsCfku696rds7rZKrDDis3btzQzfwNXl5ez58/V3FcaPXnv//9L/k0
Jydn+vTpKqi3sBArV4IgEBAAa2sVVKh5JCUlaVOEJg1FZyfMCrRqhYSEqhVIkUj0zTff/P333xWu
ewDGwBvgBtBYFTJqITfKy5nOVwH5V1ZZho38fwpsffXQ3kNnozIrxci2bj/s2/kzBraoITqO2vAK
aAk8s7AwNjaWZ3sUwK1b6N27wjVfX19C9hfu1q0BwNMTgJxvG6mpoBgf1dERAHr2rO3n3iYnp6ak
AKgDNAUsLS2nTZsmpyuGZJ2j9jJ8we3blD4OoLwcHTtWTmZ8+/btnjLKdvt2hbWr4OBg6XHjxo2j
o6PPVrJP+AJTU9jYwMlJRpGrlmHx4lGjIBTCxgakwEQy4+SE5GRQcem4dQtDh8r/cQDNmwNf7xKv
7ZEB2NvD5evtkpBQvXbs7Oxcw1Bt3Lg6GWQhPx/p6fJ/HIAkWREVGcrLcf8+JRkAEAS6dYOBgfwl
3L5d5RRXiwnTwABNmlAdGhTXrhwcUFSENm0oyfCVoWFmVsXFrKwsd3f3169fky/qA9/a21/OzR1m
YxPSpIl+bVc3Hz+Gi0vtPlIB6kPj40eq1kF161KVobzc9/59BYTpq0YG6l+1ymHVQoP5KsKC1Phn
L5Pf5xSVijlGlnYNXdq2dbYx0BDt0MLCorCwkAtMBVxcXOzt7cePHy9nWZV2llmsWn7DR4+iuBgA
8vLklGH6dNjayvlZCadPIzGxth/auHEjj8eTHEfWq/dMLL5//76c2jaAa9cQGyvnZyV060ZVy4yN
xbVrlS8HBATIui/ZqhWGDJGeCYVCIyMjaXAKPz+/4uLimzdvVldCejoCA2UXuQpsbcNbTnd3B4C7
dyE5qB2Fhdi3j5IMAGTfQ/wau3ahrKzKv8wN7rvvYcc53WL3+lfRXp+pdmjINFQDA6kqeSNHgqLv
JPWh0bMnunWjVMLDh1Tfwb4cGlJqMWEmJuL0aUoyODpiwgRKJVAfGgYGkDl87J07d/r378//0qC4
cePGQxs0OBYd/b9hw/wlqwxyMGdO5Zfh2nHoELKyKJVAfWhcuIAXL6gUwAoIoKoR1Tg0qH/VqkUh
OqJmI9ERJcdeXl6tW7feu3evogrPy8vThfwNISEhQ0gz/ogRI3g83qVLl2gUSXnI3aanTp0aPXq0
9NTPz8/d3X3FihWKE60KCAL16uHjR/TpQ9WdSW2ZOxf79mHOHFAZuMxeszqgIxOmHGzfvn358uUV
ntf+/v6lpaX5+fknTpxo0KABXbJpDUz3q4yGrPVpLDrS4ZYvXy495nK5iYmJmu2tUi1ytyk5jbWZ
mdmLFy+q82hWEJs2ISsLenoIClJ2VZoNoyCqAzoyYcrCtm3/ugsDmD179rJly8gKooGBwdKlS2Nj
Y1u3bn3nzh1GQVQITPerDKMjKhfyupG2EhkZ+ZIUTcPHx6e4uFgF2g9dyN2m5Aw03bp14/F4bdu2
VZBQVZOTg/XrQRDYskWz9jdoIIB6GG4GyujChCkLR49i1Sp4ekIkEg0aNKhCDDVHR8cZM2YcOXJk
z549v/zyiz7tHsHaAtP9KkM5GlB5Ucab10nvsgr5ApH4K/vW+nZufdzsdLIbnzp1im4RlM6MGTOk
x5IsjbNnz2Zrmoe/7MjXpsnJyQUFBdJTGxsbX19fFvXYGdXi7w+RCPb2WLKk5pt1nK1bt6oi/A1D
tejChCkjYjHKywWenr3Cw8PJ193c3MzMzGJjYx89esQsHyoWpvtVRn4dUcxLuvbHr3+cif4gqvHe
jpu9dFRHHDVqFN0iKJfw8PAnT55IT728vKKjo0+cOEGjSMpGvjb9448/yKc5OTlTp05VjEBfISYG
Dx+CxUJIiALiuGk9TMgVdUD7JkyCwLVr8PFB7cMzC/Lzu4aHPyFf8vf3T0hIcHd337p1qx71gM8M
X6J93Y86cnYyoiTu93nzjiTqur9LjZw8eZJuEZRLhUygBgYGixcvNqsybIO2IF+bkmPctGjRIiIi
4ujRo4oTqgratMHAgXB3R8eOSq2Hfn75Bamp+OUXSoVc11aPHo1CmyZMsRhHjmDxYhQWYtQo1Gq4
i0TlBNG9vPwLBXHGjBlXrlxZvnz5ggULFCwrAwDt6n6KQj4dUZAYuOlfBdGyvd/oQe5tm9SrY6TP
/spiBcvQVg3yLNCCdvtJHThw4OnTp5JjFovVvXv3x48fn6YYkEIbEQqFr169kp62b9/e3NzcWsnB
rLlcnDun1BrUBWNjhITQLQQDwydEIhw4gIAAFBWBIMDhYMSIWnycIIitW/sDMdIrLBZr3rx5p0+f
3r59u/yh2RgYao9cOqIw9eb1dwBQb8Sugws7m2ut5Rl1rKystDW6UFlZ2eLFi6WnBEE8ePBg8+bN
2r2ICDliXgI3btwoL/8izny/fv0UKhQDVaysrHKryiDMoErkGFxqhUCA337D99//m3NeTw+zZ2PT
ptp5jM2YMeP5889hU1ks1uzZs0+ePPn3339rsS+gOqDp3U8ZyKXeCbLeZANA66kTOjIKoq4ybtw4
adBsAMOHDzc0NGQ2Qark0KFD0mNjY+NXr1717duXRnkYKpMnd9R6BgagtBQbNsDcHEuXgseDvj5W
rEB+Pnbvrp2C+Ntvvx08eJB8Zc6cOWfPnj1//jyjIDKoHvk0PIk7pom9vSmjIVaPtho5PXr0iJxW
zsbGJi4u7sSJEybKzomuBsjRpnfv3pUed+vW7e3bt927d1eoUJ+JiUHnznj/XknFay0Vwosw0IKG
TpivXsHaGuvXo6wMhoZYvx4FBdi6FbWdDsPDwxctWkS+8s0335w6derkyZNubm6KlJihKjS0+ykV
uXQ8br1W9QDwc/IFzLJs9WilsyRBEP7+/uQ1+Z49e7Zs2dLPz49GqVRGbdu0oKDgw4cP0lM7Ozsf
Hx/Ol3mcFUV5OXr1QmwsDhxQRvFqyr17YLFw7x6lQmZWSqTJoHo0dMJ89gxsNkxMsH07Cgvxww//
5pyvFXl5eX379hWLxdIrXO6Imzdv7ty509PTU5HiMnwFDe1+SkUuHVHfwXuQMyB+cTk6T1zz7brM
AW18Vi9ZsuQ9aZ2qe/fut2/f3r17N40iqZLatumRI0fIpwUFBcozRly0CEVFMDBQQHpkDULiMUrR
TZwJjaYOaMqEmZsLESno2/DhuHULBQVYsgRyB7QeMGBAcXEx6YKbWJz27bffTqCYVJpBZjSl+6kS
+faK9Z1GrJruwi4N/2XbpbQyZi3x68yaNYtuERTMs2fPfv31V+mpoaGhnp7eihUrdCeaa23blBwt
0tbWNioqSkk6YkoK/vc/APj9d3mWMXQcJsWCOqARE+aECahfHwsXfnGxc2dQ2Rv4888/IyIipKcG
BqYsloW+vsvq1avlL5ShlmhE91MxMvg1E8KSwhJhRUXQbuj6H4s3bji5deLU+2PHDvJs37SeuaFe
1SonS9/E3ERfJ6P4alkSWJFI1KdPH/JuyIgRI+Li4sgOzlpPbYMZxcbGSo87d+6ckpKiJH164EAQ
BJo3x8SJyiiegUHpqH+ksIMHcfw4CAKkrElU4fF45AT3bDa7rKy4fv3MmzcvKDsVEwMZ9e9+qkcG
HZEXsWrwqtiv/z393tFf7lW/zdNx85VfPbTfmaEKEhMT6RZBkUyaNIlsWufq6nrr1q2TJ0/qVMT/
WkVISUpKIu8fmZiYKGkR8fhxxMcDwKVLyihe+2FiXqgD6h9+aPx4vHiB3r0xeLDCyt6mcj4AACAA
SURBVFy4cCE5RsTUqVODg4MfPDjXqBFXYXUwyID6dz/Vw/glM8jKhQsXjh07Jj01NjauU6fO+PHj
e/ToQaNUao40jAWbzeZwOKGhocrQEcvKMH06CALffgvtWrlmYKCT+HgMHQpSjiQYGWH7dkUqiPn5
+X///bf01MHBobi4eN68eY0aNVJYHQwM8iLD8g+30dC5M1yFFCrRd9DZ1yFXV9eoqCi6pVAAOTk5
FQy2/P39X758+dNPP9ElEl3Uqk0vX74sOZBs0Ofl5fXs2VPhIs2aBT4fJibYs0fhZesKvr6+TOQL
2lGrCfP+fXh7QyhEXByGDVNWLYsXLyYH2J80adKxY8f+/PNPZdXH8HXUqvupCTLoiPqOPuMmK18S
7SQ6OppuERQAQRCenp6lpaXSK7169bp27drdu3e5XJ1T/2vVpi9fvpQeDxgwoKioyMhIwYkpX7/G
4cNgsXDkiPw+lQw3btygWwQG9Zow69ZF3bqoVw+k7RMFIxAIyJszzZs3v3z58rZt24yNjYuKYGQE
XbLioR+16n5qArPXrFxWakUMkhkzZsRLjN0AAPXr18/Nzd20aVOLFi1olIouZG/TpKQkPp8vPTU0
NFRGnLNx4yAWo317+PsrvGwdgomPqA7QO2HevQuSuTVcXPD6NSIj0bSpsmr8448/ysrKpKceHh7m
5uajRo168QLNm+O775RVL0OVaMfzWrHUSkcUCwUCgUAgEIpqsu4mRJ9u1fH4iVu2bKFbBKocPnyY
nBuKw+H06tWrSZMmOvtMlb1N//nnH/Lphw8flKEj+vrC0REXLyq8YN2CybOiDtA1YYaEoEED9O6N
Pn1ACtug9BhSO3fulB7b2dndvXt3w4YNAB4/RmYmTp5Ubu0MFdCC57XCkV1HFGVdWT7Qx8fHp//i
M6mCGm4WpJ5Z3N/Hx8dnUMD1LF1WEzV97TouLm7atGnkK5MmTbp3794ff/xBl0i0I3ubXiL5GDs7
O8fFxSnDv2fzZrx5A3t7hResWzD5mtUBFU+YBIFTp2BnBz8/pKWBIDBmDNiq2l1LS0t78+aN9FSS
w713794A6tWDkRF0cp+GTjT9ea0MZB4NvGd/7XtUCnBdl64b2dighrsNGo9ct6QzF+CH7z38gl/D
3VqMq6sr3SLIT35+vqenp4iUT8DX1/fixYvHjx+3tramUTB6kb1Nnz9/Lj1u06ZN06ZNLSwslCGS
QU0DUrvx8Pj8W26srKwUIgwDFVQ2YYrF+Ptv2NhgzBh8/Ag2G+PG4f17rF2rmvoBYNeuXeTT8vLy
KVOmSI69vRESgjNnVCcMAzT8ea0kZNQRiYKowKu5ABzHL+hrJ0s0eY5dvwXjHQFkXw6MLmAij2kc
IpGoR48eBaRAsU2bNk1LS9u0aRMT7EYWkpOTyTHPjI2NmaSrSmL8eERFYfx4uuVg0ATKy7FvHywt
MW0acnPBZmP6dHz8iKNHUbeuSiUhe6t07Njx+vXrE0nh73v3ho2NSuVhYKiMjDpiyYsrsWUAXEYO
bCir56R+owHDXQCURl15yavxbi1Fc2NoDx06lOynYmFh0bhx4549e86YMYNGqdQBGdv05JfGRB8/
flSsjvjjj2A8caV07ky1BCbmhTqg7Anz/Xs0bIh581BYCA4H8+cjNxcHD0L1i8jv37/PzMw0NjaW
BDpo1apV27ZtdSejqXqiuc9r5SGbjih4//h1KYD63TrYyJ6SkmPbsVt9AKUJj9/XZMCorWhoLr6V
K1deJDlBcDicwYMH8/l8cqZmnUXGNiV/gY0aNYqNjVWgjrhzJ374AaNGQUglcCkDic7U1UwGyih7
wszJgVgMLhcrVyI/H7t3w9xcqRV+lT/++IMgCB6PJwl9EBgYKN1oZqALDX1eKxXZdMTyvNQ8ALB1
tqlNtCY9W2cbAMhLyS2v6V4tRRNzhO/fv/8///kP+cq0adPu3LkTFBSkg9EQKxMQECDLbU+fPpUe
t2nTxsbGxs7OTiECFBZi5UoQBBYsYAIiKoytW7fSLQKDrINLdkpKvkis3KYNwsJQUIAtW2BCa3rY
4OBg6XG9evUADBkyhHxDWBiys1UtlY6j8O6nBcimIxICvhAAW99QrzYJxll6hlw2ACFPqKsGiQcO
HKBbhNpx+fLlOXPmkK8MHz48ODj4zJkzdVVsraOuyKJM5Obm5ufnS0/NzMy8vLwUJcDo0RAKYWOD
DRsUVaTGQ13BYx4P6oACNfXCQsybB2trDB36RTibFi3UwsfrxYsX0uNu3bp17tyZ7DUVGoohQzBi
BB2S6TDMi2JlZNMRWVxjfQBiXj6/NoFsxPx8nhgA11i/NqqlNtGnTx+6RagFUVFRQ4YMIYjPGr2P
j8+DBw8OHjzIOHxJkaVNyYsEAPLy8jwout1+4uFDXLsGFgvBwWDp6rCqwLp1CAjAunWUCmG2mdQB
hUyYOTmYNg1WVti7F2VlEApBClOtFrx48YKctsrIyKhXr17kGzIzweOBZBDOoAo063mtGmTTEfUs
nSwBIOPpu9oYFgrePckAgDoNLHU1oZAGZYB9+PChu7s7OdJNp06dkpOT161b5+fnR6Ng6oYsbXr2
7FnpsZWVVVxcnEKMEQkCQ4eCIODtDXd36uVpCZItOYobc4y5ujpAccL88AGjR8PODn/9BbEYVlb4
+2/cvQtF57+kypEjR6THLBbr/fv3FdK4d+iAevUwerTKJdNtNOh5rTJk0xG59Ts4GwAoCL+aILuL
Mu/llfACAAZN29dnzNjUm7/++svDw0MgELBYLBaLBcDZ2RnAqFGjKmw9M8hCZGSk9Lhjx45Q0DLV
pk3IyoKeHoKCqBemPXz7LQwN8e23dMvBQB/p6RgyBPb2OHUKYjHq1cPJk8jOxuTJqouJLTtXrlyR
Hrdq1So6OrrCO2SrVkhIwJfxExkYaEDG0WPSckAnLoC8i3vOp8jmSSlIPrfnUj4Abqf+LWk1DqYT
9Q/MGxER0aZNm2nTpklWEAmCkOw1p6WltWzZ8ueff6ZbQLWjxjYVCAQfP36UnlpbWytkETEnB+vX
gyDw889QTihuTaVTJ/D56NSJUiGSlyIGepFjwiQITJqEhg1x8SIIAg0a4OJFvH+PkSPV1xjj5cuX
0mMXF5dmzZrVqVOnwj1mZtDT1f03ulD/57XqkbEPsup0nTTIJvxstjh+z7Lt9X5b2suuWn9KYebN
X5btfSkGYDN4Utc66jpUlQ71BF8ikejt27evX78uLS01MTGxtbW1s7MzMjKysLBgf+UFubi4ODs7
OyUlJTU1NTMzs7CwUCAQAJAkR2Gz2QUFBe/evUtISHj+/LkkSjaLxZKaIdra2ubl5Tk5OR06dIil
trMsfdTYpmFhYWSbTh6PN2DAAOr1DhsGkQj162PZMuqFMVQkKSmJbhEY5JkwX75EcDAIAk2b4vff
8eWerTry9u1bSbwbCfr6+pL8ewy0wyTkrIzM7ylGracv73dr5dU8ZF78fnzCgFlzJg9xdTSqpKSI
eemRF/7au/9qkhAALPsvn9ZazWxBVMlJebOyi8XiI0eObN26NT4+nqxwVIDNZkt2h8VisUTPE4tr
lx9b8imCIAwMDAQCQZMmTUxNTQcMGPD7778zkW6qpMY2Jd/A5XITEhKoL8dGRuLePbBYuHhRfVdH
NJotW7bQLQKDrBOmWPx5B7llS5w9C0tLBcRRVw1kY0QAGRkZTGRENUHu57UWw6pG/6gIwXsVuHzO
/qdStxUj+5btWjRxsK1jwmWLBSV5Welv45/Gv5e6a3Hbzdq3bUIzY/V+pFlYWBQWFkqOvby8Wrdu
vXfvXnpFCgkJmTVrVkZGhvSKvb09+bQCtra2WVlZla8bGBiU1eTRZ25uLvn3pUuJ69atW79+PbOC
KDctWrRISEiQHHfs2DElJSUrK+tri74ycu8eBg3CmDHQtGBKDAyK5P59LFwIJyecPaupL0vdu3d/
+PCh5LhBgwa5ubnv3r0zrxTLe9s2DBuGpk1VLh8DA4naPLdYxs0mbP9zzeDGnxYf+RnxEaEXz5wI
PHz4cOCJM5dCH31WEPUaD17753a1VxCVzalTp2p1v0gkmjJlypAhQ6QaoSyLeXpfsVuRZU2xpKQE
gJubW48ePVgsVlBQ0IYNGxgFsRpqbNPk5GTpcf369d3d3SkqiAA8PPD8OaMgVk12Nrp2perXfIPJ
bKgGVDO4bt5E06bw9ERMDO7cQWamKuVSJM+ePZMeN2/evFWrVpUVxKNHsWoVmATvKqa2z2tdoJaP
LpZhg/4r/ww+sHpir+aWVasRLMvmvSauPhD858p+DQx1XtMYXZvoBWVlZV27dv3nn3/IF42NjeWu
nRzIpgJcLrdhw4bdunWTmMJERESMHz+ez+cPHz5c7up0hOrbNC0tjbx2y2KxFBUZ0dFRIcVoIevW
ITKSanxEX19fBYnDID9VDq6QEDRoAF9fJCaCxULfvoiORv36qpdOAbx79664uFh6WjkyohSxGOW6
mp+MLmr1vNYR5PGb4li0HDDrxwGzyoveJ71OTH2fXcATiNlcYwub+g2aNmtSz5RxxpJiaWkp450C
gcDNze3JkyfSK4aGhgKBoFOnTqGhoZKkHVZWVjY2NgYGBgRBcLlcgiD09fX19PTS09MBeHl5lZaW
lpeXi8VisVhcVlYm2fG0tLTMy8szMzPjcDgA8vPzDQ0NRSJRWVmZqalpjx49AgICPD09GetDhVDB
ouXjx49M+HEGBjkgCJw6hQULkJUFggCbjaFD8dtvcHCgWzIKHDp0CACHwzE1NRWLxWlpabNnz6Zb
KAaGr0JFndMzq9+sU/1mCpNFG8nNzZXxzoEDB5IVRABeXl7Xrl2Li4vbuXNnx44d7e3ti4uLRSJR
fn5+eXl5UVFRaWkpn88vKSkRCASmpqZ8Pt/c3NzMzMzExMTExKROnTqSA1NTUzMzMx6PJ1lWZLFY
BgYGRuoWVVZzqN6ElxyFtV69ei9fvuxEISjLx48IDsbMmXIXoBNs3IiEBGzcSKkQ2YcqA3X4fP6h
Q4cePnyYk5MDgMPhbNy4sWPHjtLBFRyM6dORnw+CAIeD0aOxaxe0IBuo5B1SJBIVFBSwWKzY2FhF
7TMwUKcW7hk6A7PkpxasXbv25s2bbDZbYkHIYrFmzZp17ty5jRs3rl69WrL+R5HKJi8MyuDp06fS
49atW6emplaOfCYj5eVo1gxlZXB0xMCBCpJPG7Gxwc2bVAuRfcmfQW5EItGxY8d27tz5+PFjsrU0
l8sNCQmRPqE/fMDYsSgrA4eDKVOwbRu0I24dQRDkyIg+Pj4AzMzM6JOIgaEG1C8CvXYhi5FTVFSU
NDaKxLlh/vz5Z8+eDQwM/P777xWiIDIokGraVCwWk6Nn16lTh8pG8759KCoCAG9vuctgkJVZs2bR
LYI2c+vWrT59+hgbG0+aNCkmJkYSq0v6V0NDQwsLC3waXHZ22LoVa9ciNxcHD2qJggjg1KlT5SQb
Q6FQOHToUBrlYagAY5RcmdrEvtFSlBr7hhybukrKy8sdHBykioX0/lu3bvVU/2iwOkk1bfrkyZMO
HTpIT/39/T09PZcsWSJfRTweBg/G5s1wc5OvAIZaUONQZZCDhISEDRs2hISEFEled77k03duaGi4
giDM+PxlbLY2t0LPnj3v3LkjOTYwMDA1NY2NjXVycqp859GjmDgR1taoKqYZg7JgJoHKMHvNymVm
TaZky5cvJ688ubu737t3LyQkhFEQ1ZZq2vTs2bPk03fv3lExRjQ2Rmio3J9mqB2jRo2iWwTtITs7
++effz569OiHDx+quY3FYunpWQERpaXOQPmzZzVPmJqLSCSShkUE0Llz57KysioVRAa60OLuJzfM
XrNy2b9/fzV/zcrK2r17t/TU3Nzc2tp6/vz5gwYNUr5oDHJSTZtKFwkAODs7x8fHd9aU5A+azL17
MDLCvXuUCmFSLCiK+fPn169ff+fOnV9TECWZnPz8/DgcDotVoqeXyWYXtmy5u23bGiZMjWb37t2S
nKgSLCwsmI1mdUOLu5/cMDqicqk+Cez06dPJIQxHjRqVkJDwn//8R/lyMchPNTk9ydFxXVxcHB0d
5TNIZ7Y7asXRoygtxdGjdMvBAFy4cGHv3r3lVUX209fX79Wr1+DBUywser99+7ZLly4JCQllZfys
LHeBwPzFi8XQ6oS55IScderUef78+bBhw2iUh6EyWtz95IbZa1Yuzs7OX7NvSE1NvXjxovS0TZs2
N27cOHLkCBOVRs2xsrKqsk3Ly8slgTwkWFhYyOewsmsXjh/HtWtgPNFVCWOKRJ2ysrIJEyYQBFHh
y3R1dW3UqFFSUlJUlF9JySILC9GVK/pt2vz7VxOTzyV8bXBpOoGBgeR0qW5ubsXFxW2kX0FVsNn4
Sv4sBmWhrd2PCkwfpI158+ZJuqORkRGfz+/SpUtBQQETK0tziYyMJIfzKCsr69atW20LSUrC0qVg
sRATg6/kX2BgUFMGDRok8U2RzGwsFqtJkyaOjo6PHz9u1arVDz/859tvfXg8ODqyGzSgW1bVsnjx
Yukxh8NJTEzcs2dPNfePHInISIwdq3zJGBiqhdERlUtUVFSV1/Pz8y9fviw55vP5AP78809JWhQG
NedrbRoSEiI95nA46enpcqwj3rsHfX106MAoiKqGHPycQQ62bNlykxSm0sTEpKSkxNjYdNasWf7+
/pLtkdBQZGWhd++vFvK1waXR7Nixg7yI2K1bN7FY3Ldv32o+wuVi507lS8bwJVrZ/SjC6IjK5Wsu
Cxs3biRbIvbp08fExKRZMyZpjQbwtTa9R3KaaNq0aXx8fMeOHWtb+KRJMDfHkCHyi8cgH3369KFb
BA3m8OHDq1evJl/p1u2bmJhZ+vqt+vWD1Hym2s1V4OuDS3NJTk5esWIFAC6XKxAIDAwMsrKy/vvf
/9ItF0MVaF/3ow7js6Jctm7dWuX1gwcPSo+dnZ1fvHhBtmhmUGe+1qbx8fHS48aNGzdq1MiEbGkl
GywW/P3BxE1XPQcOHKBbBE3lxIkTU6dOJRlydbKwSLx5c1deXqvnz5GSUouivja4NBQej9etWzfJ
coBAIGCxWLa2tpaWlv3796dbNIYq0LLupxAYHVG5BAQEVL549epVadRuAG5ubs2aNWvVqpUK5WKQ
nyrbVCQSkR1WTE1NqWRYYVA9TJ4V+Vi7du3YsWM/WeK6A8+BqIKCJiwWq0sXREaiVovpVQ4uDUUg
EHTq1IkcAKhu3brp6elbtmyhUSqGatCm7qcoGB1RuVS5dr1582bpsYGBQUJCwqJFi1QoFAMlqmzT
uLg4ssNKaWlprbYtSktByvPMQANMvubakpeX17Vr102bNgHgcPoCb4C7QCsAjRqlxcfj0SO0bVu7
MrVmsy8vL69Dhw5kE3NjY+P27dvPmTOnlwy2xm/eoEEDMBqLitGa7qdAGB1RuVS2gRUKhQ8ePJCe
9urVKyMjw8/PT7VyMchPlXbNwcHB5NP09PQuXbrIXmaXLujdGxERVGVjkJvc3Fy6RdAYysvLV65c
aWdnFxkZCbgBaSLRFcAZIMzNw+fM2fb2rVPz5vKUrB1OAyEhIY6OjvHx8dKc1CwWa/jw4VlZWTt2
7JClhEePkJ6OQ4eUKSVDJbSj+ykWxmdF1Rw7dkwoFEpPLS0tR48ezWYzyrpmc/fuXemxk5PTq1ev
2rVrJ+Nnd+7E8+fgcNC0qXKEY2BQEB8+fFi7du3Jkyc/WctwgAuADUBYWNwqKJg0cmS/vXsP1lCK
9pKamjpx4kTpbMBisSShIidMmBAWFnbv3j1DQ0PZS2NC9THQDqMjKhdnZ+fExETylWPHjgEwNTUt
Li42MzOLiYk5fPgwTdIxyEPlNgXw4sUL6XGTJk0sLS2NjY1lKa2wECtXgiCwahWsrRUpp+4gyYlN
ITM2ALi6umrHKkJqauqpU6fCw8MzMzOLi4tLSkqsra0dHBwcHR1btGjRrl27jh07ytg5JYhEotDQ
0GPHjt24cSM9Pf3LIMMiYCLgN2BAZEzMlXXrVpADAcpBlYNLI7h37973339/+/Zt8vcjFotZLJaD
g8Pt27dv3rzZqFEj+gRkqBnN7X7Kg9ERlUvlXHy3b98GUFxcDKCoqKi0tLRr1640SMYgL1XmVyTH
PzM3N3d2dpaxtNGjIRTC2hrr1ytEOl3k22/RqBEoxq6Jjo5WkDj0kJ2dvWnTpkOHDpH94STx+dPT
0yO+tGNgs9mGhoZmZmampqYmJiampqbm5ubGxsYWFhYlJSUlJSW5ubl5eXn5+fmFhYV8Pv+T3qMH
zAHc9PUXCYX5kqIaNkzo0uVWRETEqVOnPD09Kf4X1ScvVUPevXu3fv36oKCgKtO42dra1q1bNzU1
NSoqigltpv5oXPdTAYyOqFwq5AhPTk6WRMyWwOFwpk6dqmqZGKhR2S0xMTGRHO1SdoeVhw9x7RpY
LJw7B8bcgArUgxuuXLlSEYLQQHFx8TfffHP69Gmy15QES0tLPp9vbm5eWlpKvi4Wi3k8Ho/HI3vd
fg0WiwVwgYXABsAIIITC8xxOsL6+fv/+/SMiIoyNjR89elSvXj3q/4um+PwmJCTs3LkzJCTk3bt3
0otsNpvcBH379n3//r2Li8udO3esrKzoEJOhdmhK91MljI6oXGbOnEk+JYdFBNC9e/ehQ4eqViIG
qlRWJi5dukQ+/fjxoyzGiASBoUNBEPD2hru7IiVkkAMNfTxcuHBh7NixPB6vmnsMDAxkLM3KyqqS
744hh/N9eflSQFKIANjq4vK0qMg2MzOzqKgoJCSkE8VtfhLqrKnn5+cHBgYGBQVFR0eTF2ulSBXE
tm3bNmzYMDw8fPPmzTNmzFCtmAzyo87djy6YtQvlcuPGDfIpWZlo3rz548ePqe/OMKiYCm2KLzOs
mJmZvXnzpq0MMT9+/hlZWdDTw5kzCpaQQQ40cZtpzZo1fn5+ZAVR6hJha2vbsWNHQ0NDNpstFAql
Dra1wRT4BSgsL18NcAG+re3u/v1He3ndyM7O9vHxefDgwY0bNxSoIKKqwUUvUVFRy5Yt69Kli4WF
haWl5fz588PCwqpUEAFwOBxJ2PyMjIxWrVrFx8czCqJmoW7dTx1g1hGVi6+vL9mE+dWrV9Lj5s2b
W1hYmJub0yEXg/xUaFMAz549kx43bdo0JyfHwsKi+kJyc/HDDyAI/PwzarqXoWYOHMCXS/a1xtnZ
mdAcP1KCIEaPHn369OkK1+3s7FJSUnr37h0ZGZmVlWVgYNCuXbuUlBSCILhcbp06dSTeVFwuF4BA
IODz+aWlpaWlpTweT6JHcjgcY+P6ItFPfP4EgtADwGLxCOL7+vVPA0JLy15jxviPHDnS1NRUGf9X
5cGlSgiCePr06fnz5+/evfvs2bOPHz+SbUiqoWXLls2bN09LS3vy5MnKlSuXLl1qa2urbGkZFA69
3U89YXRE1VFWViZxVZHAZrNlCabKoP6kpaVJj21tbe3t7Wv8yLBhEIlQvz6WLVOmZLrBli1YtQq5
uboSc5isIOrp6YnFYrFY7OjoOGDAgAsXLvTp02fmzJlnz56t8KIiEokyMzNTU1PfvXuXnp6enp6e
m5tbVFSUn59fVFRUXFxcVFSUmpoKQCQ6zeN1BVhcLr9nz0s+Pm9btPBq23ZekyZN6PmHlYZAILh9
+/bly5cjIiJev36dk5NT2aazGtq1a+fs7FxUVBQVFdW+ffuNGzf269ePw2TSZNAiGB1RuZCNe8LC
wsh/ysrKmjJlisolYqBKBYMtoVBIVv319PRq3GjOzcWTJ2CzERICefYAGb4kNfXzb7nRoJgXM2bM
kK4glpeX6+npGRoaNmzY8MWLF1evXv2aLSyHw3FwcHBwcKix/AMHsHkzfvwREyYYsVgjFCl6TSg7
krlYLI6Ojj516lRoaOibN28KCgpqW4KtrW379u1NTEySk5NTU1ObN28+efLk06dP17h1wKD+MIH0
K8PoiMqFnODr+vXr0mN9ff23b98q1pSHQTVUSNoWHh5O3p4oKSmpUUe0skJwMEpLqYb0Y1AgmrJI
tmPHjgqubyNGjPh/e/cd19TZ9gH8yg5bwhCQoQJu64NFkApYB24UHG1tHXVhtVZrHUVr1draqtXW
Wmvdtfq2j6P6WFs3bm0Vxb2QoQwFQfYm47x/ROMhODAQTsbv+4efk5skXPHKCVfuc49t27b16NFj
zpw5OqzGn55Oe/dSVNTTrytRUbW9cK8zfeyIqFQqT5w4sWXLllOnTqWkpCgUild9hqZNm7q7u4tE
ouzs7MTExPz8/Ndff33y5MmhoaFCoV7+hvr4kL09demij+eG58KGnNWhRtSvt956a/v27erjS5cu
adp9fX3T0tI8PDw4igt0x84pER08eJD90wcPHtRkwgpGGRia6Ohow5/afObMmelVRyeMGzfuwIED
GzZsGD169Ks+W2IiRUXRiRPE51NxMU2bVneB6krr5KqN9PT0NWvWbN++XWtpqpfi8XiNGzf28vKy
tLQsKChISEgoKytzcHAICgrq2LGjv7+/hYVFnUT4AgEB9M8/VIM+X6hLdfj2MxmoEfVrx44dmmP2
xEk3NzcbGxudJhsCx9g5JaLz589rjj08PNLS0lq0aFHvQUFtLV682MBrxLy8vF69erE7rSMjI48f
Pz5z5sxXLRBv3KCxY5/uD+7jQxMn1mGkutM6uXRQUFCwdOnSX375hb1y4YuJxeLmzZu7urpKJJLi
4uJ79+5lZ2e7ubk1a9YsICCgU6dOnp6etYxKB7pteA21Ufu3n+lBjahfQ4YM0Ryzt+JQjx/iIiKo
LXZOqepcdQ8PjwYNGohEouc9NiuLnJ31GBvorHvtl+HWs+7du7NHvgYFBd26dWv8+PGTJk2q+ZNc
vEhjx9Lly8QwxONRmza0YQN16KCHcHWidXK9krNnz37yySdnz57VlNECgeCZHRfFSQAAIABJREFU
PYhCobBVq1Zubm5CoTA/Pz8pKen+/fvOzs4tWrTw8/P7z3/+06xZM0w9MUO1efuZKtSI+qXpuGYY
hr3DikKhaNWqFUdBQa1oXYxg71RhbW39gi1Z9++ngQNpxgxasEB/0YGO2MOFDdDnn39+8eJFzU1X
V1cLC4vAwMBpNb5CfOYMRUXRrVuPb3boQBs2UA2GRdQr3a707d+/f8qUKQkJCVrt7AJRKpUGBga6
ubkplcqkpKT4+Hh7e/vg4OAOHTr4+flx0lMIhgYXmqtDjahfeXl56mGwqamp7ItERUVFuCJpAioq
Kti7nPF4vOcNRlQo6O23qaKCnrWtK8CLxMXFLVmyRLPVm0AgCA8Pv3nz5rffflvDZ5g7l7766nHf
YUgIrVtHprF78JkzZ0aMGPHS9c8jIyOTk5MvXbokFotDQkImTZoUEBBQ8+1nOPHbb9S5M7m7cx0H
mDfUiPolk8nUpSG7D4CIcnJy3HH2Gycej6cp90+dOsX+UXFxccuWLZ/5qI8/pqIikkqpxn/WoV49
axs6g1BRUdGjR4/KykoejycSieRy+YgRI/7888/z58/XfFKtrS2JRPTmm7RmDT2/p5t77JPrxR49
evT2228fPXr0mT9t2rRpUFBQfn7+3r17fXx8AgMDZ8yY4e/v/4JxIAZlzx4aPZq8venmTa5DMSc1
f/uZD9SI9eTGjRuaY0tLy8zMTNSIJuD48ePsmw8ePHhmjZiaSj//TES0di092SwNDEueoXbwhoeH
q4tXhmEUCgWPx/vll1/+/vvvF6yKwDAUG0uBgU9bpk+nkSPJZPb+WLVq1dSpUysrK6nq33U+n9+j
Rw8bG5vjx4+npKS8++67mzdvlslknAari+JiksuJNYIdgBuoEfVLM8iJPVbGw8MjPT3dGD+5gKoO
XGN3D7u5uWVmZj5zmb0+fYhhqHlzGj68PiIEHaxZs4brEJ7hxx9/ZL/fbG1tS0pKpkyZ0rdv3+c9
JD6egoKotJSWLKHJk5+2G0WB+NJRoTk5OT179oyLi9O0iMXiyspKgUAQGRlJREePHh01alRsbOwL
RgYDPJOBD0rmBGpE/dJMlrx3756m0dHREaveGC/2BNj4+HjNsZeXl0wmq375b9u2xxeM9u2rl/jM
T3Q0HTxY2434orhaNvr5zp8/P3XqVHZLv379kpKSvvnmmxc8KjqaCgpIIKCAAD3Hpwcvnl3+77//
hoWFlZSUsBsrKirUc5BPnDgxceLE1atX4+s36MbwFzeof6+8KD+8krVr16oPMjIyNI3W1ta40Gy8
NDmlqpOa7ezsql9orqig0aOJYWjMGDKSjTyMj6cnJSVRLWemGtrSaPfv3+/cuTN7Zm5ERERMTMzW
rVtfPKhuxw76/nvKyaGOHfUfZV1jn1xa1q1bFxwcrFUgNm/efMKECUqlcsGCBYmJifPmzUOBCDp7
wdvPbKFG1K/x48erD9jD4SUSCXZYMV6anCoUCvZfLIFAUH2u+vjxVFpKVla0alX9RQg6eOutt7gO
4an8/Py2bduyV8t67bXXrly5snr1ava6quXlNHcuNWpEZ88+faxQSJMnk41NfcZbZzQnl5aZM2dG
RUWpp3WrCQSC0aNH29jYxMfHJyUlzZo1y8ZIXzMYjOe9/cwZrjXrl2Z0GnvxW5VKhX5E46XJ6dWr
V9ntpaWlWv2ICQm0ZQvxeLRlCxnJfErgXm5ubqtWrdhzaJycnGQy2ZtvvhkREcG+5+ef07JlRET7
9hllr2F1zxzOO2rUqE2bNrFbXF1dw8PDd+/e/c0334waNQpDd6BOGMum7fUJNaJ+JSUlqQ/UU/A0
x6gRjZcmp0eOHGG3Z2RkaPUjzp5NDEOvvUaRkfUXHujGQNa8OHz4cGRkJLt/WiwWt2/fXiAQVF8N
cdAg2rmTJk+mV9lpxaBpTi6NCRMmbNq0iT15OTAw0MXF5fr165cvX3Z1da33GMFkVX/7Aa4114eH
Dx9qLaCNGtEEsCdX2trapqSkNK+6x+rSpTR0KD1nBTeoM7dvk5MT3b7NdRy1U1xc3Ldv3549e5aU
lAiFQnXfmEAg6NGjR0lJyY4dO4qKxN98Q6wvm9SxIyUn08cfU43XSTQyixYtWr16tfpYPTElPDxc
IBBYWFgcOXIEBSKAvpnoR4vB8Pf3v3DhwvXr19mNeXl5GI9ovNQ5JaLbrKrE09OzuLjY0tKSfU8v
L/rtt/oOzwytWEGPHtGKFbUa9BkWFlbnK1/cvn179+7d165dy8jIqKysrKysbNSokbe3d4cOHdq0
adOkSRNLS8uEhIRDhw5t3bo1Li5OMwBRoVAIBAKGYcLDw+/evbtjx8mRIy137SKGoYsXycBm19Ql
zclFRPv27Zs9e7b6mGEYlUrVoEGD27dvDx48eOHChbi+DHWO/fYDNdSI+qXuarp27ZqmRSwWZ2Rk
oEY0Xpruw/T0dE2jo6MjcmrUYmJi6uR5VCrV/v37lyxZEhsby96nUb2TnnpzFIVCUf2BYrGYfdPW
1jYvL2/fvushITdatBCrVMTjkYsLLV1aJ2EaKM3JlZaWNnDgQPbll27dusXExCxZsmTcuHEcRVev
eDzi4zpf/WJfGgI1vAf169NPPyWiW7duaVoaNmyo/kLMXVBQK+qcElFBQYGmUSqV+vj4qI+fVQCA
oav9+oilpaWzZs2yt7fv16/fyZMnKyoq2D/VnPKeTxbp0bpUKpfLNceBgYGNG3dv0OCSQpFw9KiY
YcjLi/btowcPiDWt2QSpTy6GYbp06cL+D+zcufOjR4/Mp0Ds1Yv696cVK7iOw8xoPttBA/2I+rVo
0SKquoC2vb29ra0tZwFBralzmp+fz+4NUqlUzZo1Ux8PGEBE9McfZGHBRXygk9rss6JQKBYsWPDD
Dz8UFhZqGu3s7PLz86vf+dGjR898EoZhxGKxUCjs1GncsWPDlMrXiXhE5OtL69dTSIjO0RkT9ck1
f/589uwBX19fGxubpk2bzpgxg7vQ6pVMRv/7H9dBmB/12w/Y0I+oX+q+6/v372tarKysPGu52i9w
Sp3TU6dOsRsLCwvV/YjLl9P+/XTkCJWWchMe6Ebn/ZpPnTrl4eHx5ZdfFhUVsds1Nx0dHdu2bcvj
8SQSiUwmY9eRGtbW1sHBwTKZrLS0Z0zMdwqFPxGvTRuKjaX4eHMpEIkoLi4uMzPz66+/1rRIJJKQ
kJDCwkLN5BUAPcG15upQI+qXv78/Ve05EIvF2EjUqKlzepa9bDFRRkaGr69vURHNnEkMQzNnkoMD
R/GBTnTYn6OiomLo0KGhoaGZmZlUdfUca2vr/v37E5Gnp6ednV1CQkJ+fj7DMPwnQ8x8fHzU62H5
+fn5+vryeLyysrKJEydu3PijpSU/IICuXKGrV8nfv25enbHw9/cfO3Ysu4d+5MiRR48e/eOPP7TG
awLUOX9zO99qANea6wN74BrDMOhHNAHsuequrq4PHz708vIKDye5nBwcaP587iKDenHjxo0uXbpk
Z2ezGy0tLSsqKsaMGXP37t3Tp0/PmDGjS5cuPj4+jRs31mygV1lZmZWVlZ6enpWVpVKpkpPduna1
9PJqZG9vr75DZCSZ83Dlfax9zdu1a3fmzJnly5c7OTlxGBKA2UI/on6pR9WwB1+Xl5ejH9GoqXOa
mJioaXFzc/Py8oqLEx48SDwe7d6NCYnG55XWvFi9enW7du20CkQ7O7shQ4Yolcq4uLhhw4alpqYu
WbKkd+/evr6+7B2WxWKxu7t7x44dVar+kyZFREcHLFvWRlMgEpl1gRgQEMDujg0LC3NychqgHuFr
TlJT6T//ocWLuY7DzGAN7erQj6hfTZs2vXv3LvtTr7CwEP2IRk29X5P68qJagwYNXFxc+vcnhqEu
XSg4mLvgQFevv/56Te6mVCqHDh26o9oShX369JFKpSdPnty/f3+vXr1e8AwMQ9u20eTJ9OgRMQzx
+dS5s+5hm5KsrKy4uDj1WtlKpbJbt26///77X3/9xXVcHDh9mq5do4wMwkTb+oS9+KpDd4d+jR8/
/vz58+yWrKws9CMatejoaCJizzwQi8W5uT7Z2SQU0q5d3EUGtbC4Bp02ubm5nTp10ioQbW1tP/jg
gwsXLnh7e1+/fv0FBaJKRRs3koMDvfsuZWcTn0/DhlFmJo0dWwfxm4CFCxcqnxCJRAkJCT169Gjf
vj3XcXFALCY+n6ouyQ96p/5sBzbUiPq1du3aS5cuaW5KJJKysjIXFxcOQ4JaWrx4cUFBAXtYfWmp
/Ny5ZgxDCxea9YVCrqj75WvZO//SPw/Xr19v0qTJuXPn2I1+fn5du3Y9ffr0oUOHlixZYvmcv+oK
Ba1cSQ0a0NixlJdHAgFFRVF2Nm3ZQhhop7F161bNsa2tbWpq6hdffMFhPBwaPJg2baKqayeA3tXk
i6K5wbVm/erevTt7coObm5tUKuVjtJox6969u9ak5osXC1Uqb1dXMpvl2wxLdDTJZFTLNbBffK15
586d77zzjvqLgUgkUiqVKpVq8ODB8fHxdnZ2586de151SERpadS2LRUWEsOQSEQTJ9KXX5KNTa2i
NT0JCQlZWVmamwMHDkxISDDnYTnvvcd1BOane/fuXIdgcFCs6Nfhw4eTk5M1Nx/lq2Tu5vupZxoO
Hz5ctUbkyW15wcFfef/nu1sVz30U6FWtN0mpPmdFcX/byJCQkJAB330w6/MhQ4Zoeo7lcjmfz5dK
padOnZo4ceKmTZteUCAS0blzpFSSWEyzZlF+Pi1fjgLxGX799VfNMY/HKyoqioiIYGfhZvkLHg1Q
B+p8x3YTgH5EvWMvoC0USht5NeYuFqgb7A24ZTJZOU9BJCLRCx4BRolhmFvnNpzec5PdaG9vHxoa
euDAgT179gQEBFR/VHExWViQQPD45uDB5OZG/v6EBf5eYPfu3ZpjPz+/o0ePYtMLAM6hH1G/tLdV
4PHcGzfhLhyoAzKZjN037O7eyM0e5aHR8/b21mopKKm4ePFi7sMqBaKPj09QUFBWVta9e/eqF4gF
BTRhAjk50ccfV2l/4w0UiC9x584dzbGvr6+Hh4eXaW9N/TIPHlA5uk7rlw4L6Zs81Ij6lZeXx174
RiEv827RisN4oPby8vLYC9/Y29t7yFAjciwmprbPwK77iSgu7mLAhzvLysrYjR07drS0tHR0dDx2
7JjWzLOcHBo5khwcaPVqqqig9PTaxmNW0tLS5HK55mZlZWW/fv04jIdzsbHUti0NH851HGZG5w05
TRhqRP3q27cv+2Z5SU6r9jVahg0M1vbt2/Pz8zU3pVKpuwP6iLi0fj2FhdH69bV6EvaVzcWLF7/x
RkhJuYJ9h/79+6empg4fPvzXX3+VSCSa9owMGjSInJ1p82ZSqcjRkTZvxhJIr+bkyZPsmzk5Oc+8
iG8+EhMpL4+OH+c6DjOzfft2rkMwOKgR9Ys9U8/S0pLH5zu7unEYD9Te4MGDy1kXgXg8nrs9akQu
Xbz49F+dffrpp0RUVFTUsWPH6OhouVzO4/HUPxIIBO+99965c+fWrVs3ffp0zUNSU6lPH3J3p127
iGHIzY3++IOys2nYMHryUKiR2NhYzbFIJCooKHB1deUwHs55epKNDXXowHUcZmbIkCFch2BwUCPq
F3vhG7FYbG3XiMNgoE6sWrWKPX6goqLCHdeaOdWjx9N/dRYTE7Nt27aGDRuqV0BkGIbPIyISiq3C
IgadPXv22LFjffr0Ud+ZYahfP2rShA4cIIYhLy/av5/u36eBA2v3SszV3bt3Nceurq4ZGRlubmb9
XTo4mI4cod9/5zoOM1N9/6R6Nm7cOIFAMH78eMPZFRA1oh5lZmayxzPx+XwrO3cO44E6MWnSJPbN
3NxcD1xr5lREBCUlUUSE7s+QmJgYFhb2zjvvsE9YpYohIqW8LC/nUWxsbMuWLTU/2r2bDh0ihqFm
zejECbp3j3r2rMULMHvscWAODg55eXlOZr+2uL8/FuSvb2+99Ra3AVy7dk2lUq1du7ZZs2bOzs6G
UCyiRtSj77//nn2zsrLSVtaYo1hAL3g8XmbmQ3cZakSO6bzPamJiYufOnZs1a6bVzuPxenXwJCIX
r47r/jqoNeFxwAD6+Wc6f55u36aQEB1/NWiUlJRojoVCobOzMzYaADOkGd+iUqmys7MNoVjEeahH
u1gD192drMrKyuwctNfXAKMTHh6uOXZxccnPz3eywTqjRikpKcnX1/fkyZPswQNE5OzsHBHR/3LS
o9atW3u/NujyOWFAAM2d+/QOfD6NGUMv3JkFXoFcLpdIJM7Ozg0bNkxNTdVKB0D9MMA3HufFIs8A
/1PYTpw4MX78eL1+p4yPj1epVOpjS0tLiURSJ/spq1Sq+Ph4zU1LqbBCzkgsHFzcHSQYz27MkpOT
Kyoeb6gilUpVKpWnk8WDPDnxrZFc46JUKtnL8qlZW1tXVlZKpVJHK8osUKioQUWZnXobPW9vTEbR
i5ycHPb0Pmtraw8PDyIiYuSFGeZ5chUVkYUFCfH105zcu3dPa72t6vh8voODQ2Rk5MyZM6uv6lr3
GMP24Ycf6v2/AAAAAMB48Pl8JyenqKioxMRE/dVguNYMAAAAYEzYl6FlMtnChQv18VvQkQ0AAABg
TPh8focOHdzd3e/duxcXF3ft2jV9/BZDrxHt7OykUmmrVnrcv+7KlStKpVJ9bG1tbWFh8WQoTB1i
5Hkpd7MrSdDAs4mzFL23RqiykhISyMKi+hRaJNe4MQyjUqkEAkFZGSUkkFJJjRqRszPSagiQBTAj
8fHx7Dn+z6QpDdPS0hITE1u2bLlgwYLu3buL9bMlvKHXiB999NHff/+t1522eaxR6CKRSCKR6OHX
MRXyTGGeikSWdjKZFT7pjJOTE/H51WctILmmw86OLCxIICCk1TAgC2BGhM+fo1S9NJw3b57+SkMN
Q5/XXA/s7OwKCwvVx6Ghoa1bt161alVd/xLF/W1j3lmZTLLINds+aSWt66cHLiG5JglpNQTIApiR
oKCgs2fPslvYpWFSUlJ4ePiQIUPqoTTUMPR+RAAAAADzwVWvYXWoEQEAAAA4xuPx3NzcgoKCOC8N
NVAjAgAAAHBs7NixY8aMsbGx4bw01ECNCAAAAMCx0aNHjxw5UiAQcB3IU5gnBgAAAMA9gyoQCTUi
AAAAAFSHGhEAAAAAtKFGBAAAAABtqBEBAAAAQBtqRAAAAADQhhoRAAAAALRhfcT6wbdu1mNQ/wcq
WXsZ/stNDZJrkpBWQ4AsAHCJxzAM1zFwzM7OrrCwUH0cGhraunXrVatWcRsSAAAAALdwrRkAAAAA
tKFGBAAAAABtqBE5p3q454PQkJCQkHd/uSvnOhh4Jcid6UFODQGyAGAQUCNyTfHg+P9uMETkMyDM
Q8R1NPAqkDvTg5waAmQBwDCgRuSYPO3wn4lExGszsIsbJu4ZFeTO9CCnhgBZADAQqBG5VXl33940
IhK2H9jJEckwKsid6UFODQGyAGAocAJyqjz+z0MPiUjacXCAPXJhVJA704OcGgJkAcBg4AzkUsm1
/x3NJSKbkEF+djyuo4FXgdyZHuTUECALAIYDYz30Q1GQcHrvvuPnLl6NT8sukRORVObV3C+4Z+Sg
Xq85iXhEREzBpV2niolI1jWyjVXVx8uz/t301ZebLxUROQVPmPfp2+0aCOr/VZgn5M70IKeGAFkA
MDaoEesaU55+YuOS7/57Ka9qe3luypUjKVdSHV5fN8RNQESqvNg/zpYTUcOe/ZtLWU9Qmnzgxy+W
/J2sIFHTfjPmfdSrqSW+TdcL5M70IKeGAFkAME6oEetURdr+JdO+PpRBRGTbolvf7kHtfFztJMri
h/duxB7bd+Ca88DOLuqvvqrs0zsvKojIo1+fJuLHj1fmXdm2+Iufz2QT2bYfOeezkUHOWPihniB3
pgc5NQTIAoDRQo1YdypTd8+JWna2hMiy3bC5c0Z1chFrftbGr2O3yJEfZuSJH8/Te7oAWESYu4iI
mIr7J9d+uXD7jTIit24fz58W2dIGo0XrC3JnepBTQ4AsABgz1Ih1RFV08adpy86WENmFzlo9r4+7
uPp9hLauTo8PWQuAvekqVBXf3vP9F98dSmdI2nLwrLnju7hLcSGl3iB3pgc5NQTIAoCRQ41YJ5ji
y6sX7MokIvehi2b3ftZHYRVPFgATvT4wgC5snLbglwsFRLKOUfNmDW0vQ1LqE3JnepBTQ4AsABg9
nHh1QZ6ya/meHCKS9Z85srXVS7/sPlkAjFxtT336zrEkOfG9es+YP6WPjxUupNQz5M70IKeGAFkA
MH6oEetAybXft98lImr23rttX/5ZqFkAjCj16DEiIt8Jm35+t4lEnzHCsyF3pgc5NQTIAoAJwBe0
WmOKru46XkBE/HaDu7q+vOjWLABm1TaokbopYW9MSrleg4RnQu5MD3JqCJAFAJOAGpEcHR2dnZ2D
goKCgoJOnjz5yo+vSDp6sYyIqHFouxrsHKVZAMyp7+TP5r3rTkREqZsX7UyRv/KvhlpC7kwPcmoI
kAUAk4Aakc6dO7dy5cqpU6dOnTp1+/btS5cufaWHK3Pu3CkiIhK5eNq9fNV/zQJg7v36etu1GBEd
qZ7Ul7B+yd8PFK8ePdQCcmd6kFNDgCwAmAbUiOTo6DiExdLS8pUerizNLSUiIkVxUSXzsntrFgDz
HtDDU0Q8q7ZjZva0IyJSXF21LCZbqcMLAF0hd6YHOTUEyAKAaUCNWFtCWxc7IiJiru84lFb9yoiy
JPtRuerxDc0CYK0iu7gJiYj4dgETp4VaERGVxy5fcTpXVe0ZQF+QO9ODnBoCZAHANKBGrC2+g38P
XyIiUt1aGfXRkv/GxF6PT7h9/eKZQzs3LJ4+csDwNfeUj/+bnywAJvQbFOL05L+eLwudPLmDhIio
5Piy1RcKq30eVib8PCSk94LzJfXygsyI4eROkf3P5m8/mzQiomtISEjIsC2pGIalI8PJKVFl5r/b
ls/+4O3enUNCQkLCBkbN33wuyywya0hZUBVd+XXexGEDwkJDQkJCQnu9/eHX2y7lom8SoCaw9k2t
CRv1nzX+2Pg11+VEJTf+WnXjryo/lkXMaGOlPnyyAJi04+BA9jhuQcMen3zw17Afrispb//ijX03
T2nHXitC/uBCvKTNgCFtrfT/YsxMfedOWV5SzkgsLYTaS4EoMk79GXPTulmrN1rFnbhZ9y/UjHBw
Pj4nrcrcf9at+qusfffID4a6WZbdO7Nr27rpl9OX/BodZGfqX84NJwtE5Q9T8u3a9h4R2chBIn90
5+Su/62cfD137cYJLaV1/KoBTA6PYV46WgReiqnMjN3569b9/1y9m1tJRCRp0KhxszbtA0O6dnuj
uYOIR0RUcn7B4E8OF5N12Hd/zO2gVfBV3t0yfsTaRCIij+HrN0Y1x8dXPanH3JXGzu4/PX/WXz91
s9P+O8aoGB6fR4r728a8s1IZ9dsvwz1Fdfs6zUn9no/PSytTnp1SaOPl/GQHOVXukVlvz/+n6ae7
fu7nZOpFIhlKFqpRPtgx7u0V2eE/75jZBp+yAC/BgEFTFZyeHRY8dGNyJdeRwKuqlruSc7O6hUyI
yVc99yHy9K0jgoPf25yCdBumZ52PL0/rY4oHO94PDn5rbRKyWzu1ygJTcOKTN4P7LrpapscIAUyE
GXybNWqqvPO7/i3zHhDmgV4lY4PcmZ5a5VRVeDs2jcRezR0wxKdWdMkCo6goKystzk2/8uePK2NV
PgMH+qITEeCl8GFl0FQ5/+y8oGw97U03JMrYPM7d1ECr4vx8dVNZcaWKUZTk5+cz6sthPJGVjZUI
X9SMheZ8dKXSgvwni7rULK2qvH9WLf+3wmPYqICXXAyFF9MlC8qMXVFv/5hMRESiZkOXLnsfJSJA
DaD0MGTKzBO7rgn85gabw+glE/M4d59arxoU/m+VuazfDuv/7ZPjlrN2r+7jgOwah6fnY3ncrMjp
/9Q8rUzprS3Rcw+Utp/8w/uYKVE7OmWB79h1zkrfosqS7IQzf/zy3+lTaMVPH7SzxpkH8GKoEQ2Y
PD1md4I08JuAGmxmBYblSe46+bu4LRskV/d1lN/eMHd9ydD5H/lZq7s6BLY+tsitsWCdjxYtxi1d
NrCGaWXKErdFT15/x2fUyq8HN5ZwEboJ0S0LPLGjbztHIqIOnUJaC4dO+u8P+yPWDXF7+R4wAGYN
NaLhqry3768U65Apfrg0ZXQ0ubNvYGUf4PO4tZT3p4gn9PUPDERKjU+V89HOp33N0sqUJ+/87MOf
rri9u3zp+62tkPda0i0LbDwLr3ZutPtBSq6cUCMCvBg6MQxW+Z09BzLtu0ZgWUTjg9yZHp1yWpHy
59yJP5x3HPTtD+P90GVcezpkgVFVXX9blXfp2F0iZx9HcV1HB2By0I9oqEpu7j6a69ynfwuMXjI6
OuROnn35zJVHClVufAGRKuGfozF3BEJZ207tG2JStEHQIaeq3FOLP1r2b4lbz9EtCy8cjVG38qTu
/m+0MPlFtPVDhywo7v8x9bMzDf3beTdythWWZlw/sWf/1RKXiPFdnZEDgJdBjWiYmMLLO08Wegzt
0xTfdY2NTrkru7H+8y+uPLl17KevjhFRm8/3rOphj8uT3NMpp8q8W9fziOjBwR+/Ovi02abXyl2f
tcNXv1enUxb4dq2CW507eGz7kewSBZHEwdtv4LSRo8LboFsX4OWwzwoAAAAAaMNXKQAAAADQhhoR
AAAAALShRgQAAAAAbagRAQAAAEAbakQAAAAA0IYaEQAAAAC0oUYEAAAAAG2oEQEAAABAG2pEAAAA
ANCGGhEAAAAAtKFGBAAAAABtqBEBAAAAQBtqRAAAAADQhhoRAAAAALShRgQAAAAAbagRAQAAAEAb
akQAAAAA0IYaEQAAAAC0oUYEAAAAAG2oEQEAAABAG2pEAAAAANCGGhGfeu+kAAAErElEQVQAAAAA
tKFGBAAAAABtqBEBAAAAQBtqRAAAAADQhhoRAAAAALShRgQAQ1dyekpoSEjIgO9ulnMdCgCA2UCN
CAAAAADaeAzDcB0DAICGPGXTyGEbhBP/u3Gou1DdpCrNTMkoYUQNGnk4SHjchgcAYC6EXAcAAMDC
FCfE3SfyYrfxLV2aeHMVEACAmcK1ZgAwJBWpsckqroMAAABcawYAQ1ESO6v/tNOV7CZZxOpt01or
T0/pPesiI4tcs+2TVlIq+Xda35mxSu/J29f1Lti7auVvh69klhPfxiug/7hPxnR2FSkeXdi2au3O
E7eyK0lo7/NG5AdThwc6Vr1qIs+5su/3rXtPXorPLFERSRyatgvu++7IyNedRPX6ogEADBWuNQOA
gRDatwntWHT7wpV0BQkatXvdw0Lk2MxWQKSsej+eQCIkUlbm3dry8Re/xEucPb1cclMyi1LO/jbn
Y+XP3722e+Lsg7lWLp6eDXNSH+Ylntw4PY02rR/lLX78BEzJrf+LnrL2chkR396zedMG/KK0+OTY
P3+M3Xd0zMplI1tZYdAjAABqRAAwEBLf9+Yt6rpjzFsrkshzQPRizZyVSq07CoR8IsrY9/0u1xEr
9rzvZy8gVX7s96On7c5+sOOL6X+V+U5eN39QC2s+KXNOLxo960Du3V077wyd2UZKRMQUX1wZvfZy
Gbn2mbtsancPKY+ImLJ7+xd//M2RGxvmrPbb8kk7VIkAYPYwHhEAjAyPx+cRkSLHZdTn7/vZC4iI
+A3aD4n0IiJl5sMWk6MHtbDmExEJHALf6etGRPm37+Srhzmqso6u25tL5DZ84Sdh6gKRiHgWjXtP
n9PLjih77+bzBRiCAwCAGhEAjJRv704uAs0toayJE5+IqEUff9nTTzahQxMZEVFpbqmSiEiVf/XQ
LYbItVu3xpIqT8ezbtnDz4JIfutMSkU9hA8AYNhwrRkAjJPU1d2W/S2XJ5IIiSpt3Rtaspp5QqmI
iEgpVzJERPKs2w9URJS5f8GEWK3pKaryjDIiKkpJL1a1k+IbNACYN9SIAGCcBBJR1UGDPB4RkVAi
fEarhqo0r5SIiHmUHP/oOc9cVlCuwlUWADB3qBEBwKzw1EVji5m71oQ7oQ4EAHgefEICgDkRWDtY
ExEVPSxSvuy+AADmDDUiAJgTkXPLRgIiyricWIT9XAAAng81IgAYFPXwQZVCpZ/1Z3g2bcJa84lU
V7bHPFBU+ZEq68CsEeNm/bgf05oBAFAjAoBB4YmtJERED2/cLdFPNx/fsfOYvjIiil/52c//ZMkf
N8uzz62dvfj03dtn7yilGKgNAIA5KwBgSPi2zTu408308jNzBkY42QndR/70fYRtnf4KnrXfh4vG
3v1o/fXk7Z8O+tPFx8dJUpaZkJxdSUSO3WfP6dVQ8NInAQAweehHBABDImo8dO7EYHcJkTwvu1Tq
YCeu+13xeFYtR67Y+sPHA4N8HHmZiTeu3UjOEbm16f7+/F//7/OwhvjqDABARDyGwaZTAAAAAFAF
+hEBAAAAQBtqRAAAAADQhhoRAAAAALShRgQAAAAAbagRAQAAAEAbakQAAAAA0Pb/rUFzUJorZIsA
AAAASUVORK5CYII=
--bcaec501655751d1f904ccd188f0
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--bcaec501655751d1f904ccd188f0--


From xen-devel-bounces@lists.xen.org Wed Oct 24 17:49:48 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 17:49:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR557-0007pp-6D; Wed, 24 Oct 2012 17:49:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR555-0007pj-Dw
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 17:49:27 +0000
Received: from [85.158.138.51:6686] by server-11.bemta-3.messagelabs.com id
	5C/EB-24008-62A28805; Wed, 24 Oct 2012 17:49:26 +0000
X-Env-Sender: jefranca@gmail.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1351100963!29316044!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3341 invoked from network); 24 Oct 2012 17:49:25 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 17:49:25 -0000
Received: by mail-vb0-f45.google.com with SMTP id p1so1032529vbi.32
	for ; Wed, 24 Oct 2012 10:49:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=/AH54cJ3Nxj5PmkO9y13XPMfGAfTu5Mpih2x8+YZjRE=;
	b=LH22KQiLB8StdXc293te29OjN7yrcLd0ix8/0qPOKB76FAtEW2TgOWhQMftLI/H1pl
	FcwOvhLnCmCVgvdZGxctqOC33m+rxYQd9COd5M7yHQAXkA+wiUiICJ0OU0SZqZfG5Ys9
	a7scMAoamyeI48OR7xD9HtRZAjjXCoBLMemnHFSL1zb4gaX7Ao0BaWQLO+zfWlVv+/9k
	fbAIKVBncoEbddeWYqUCuYmpgsTC07QGnYuVTabYzwxbpnV3MhnvTWXNbfbuSB+8mcjn
	czEo83QCrjd3B0omD9n/2T1XbjOEYMJ9UfyNKJadW7LoBHYDm6ukcYOozBgNzesCGxLd
	M7ow==
MIME-Version: 1.0
Received: by 10.220.154.139 with SMTP id o11mr9381727vcw.69.1351100946008;
	Wed, 24 Oct 2012 10:49:06 -0700 (PDT)
Received: by 10.58.13.9 with HTTP; Wed, 24 Oct 2012 10:49:05 -0700 (PDT)
In-Reply-To: 
References: 
	<75A1D5EB-12C7-4829-A3F7-4D77B2405FBB@gmail.com>
	
	
	
Date: Wed, 24 Oct 2012 15:49:05 -0200
Message-ID: 
From: =?ISO-8859-1?Q?Jos=E9_Eduardo_Fran=E7a?= 
To: rshriram@cs.ubc.ca
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] How to get the checkpoint size in remus code?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============7204630991224475497=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7204630991224475497==
Content-Type: multipart/alternative; boundary=f46d04389489f14bf904ccd1b380

--f46d04389489f14bf904ccd1b380
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Guys,

I see too that I can get stats using struct xen_domctl.

Then could I put the code below anywhere and get the dirty_count? For
example:

    DECLARE_DOMCTL;
    uint32_t dirty_count =3D domctl.u.shadow_op.stats.dirty_count;

Can I do this?

Or are there a permanent data that return dirty_count or checkpoint_size?
If yes, what's it?

thanks

2012/10/17 Jos=E9 Eduardo Fran=E7a 

> Hi Shriram,
>
> Thank you for your reply. I'm sorry coz I saw your email yesterday and my
> English is bad.
> Ok... I saw your patch but I need to explain more my problem.
>
> In my master research, I intend to deploy a based-time dynamic checkpoint
> that should work this way: if checkpoint size breaks *Lmax* (see attached
> figure) I reduce checkpoint interval, and if checkpoint size doesn't brea=
k
> *Lmin* I increase checkpoint interval. After that I will evaluate the
> performace.
>
> I had read remus code and I saw that remus control the elapsed time in
>
>             endtime =3D time.time()
>             elapsed =3D (endtime - closure.starttime) * 1000
>
>             if elapsed < cfg.interval:
>                 time.sleep((cfg.interval - elapsed) / 1000.0)
>
> Then I thought I could change the checkpoint interval close to code above=
,
> but I suppose I need get checkpoint size. But here the remus code is pyth=
on
> and I saw (or thought) that checkpoint size is gotten on *xc_shadow_op_st=
ats_t
> *stats* or better on *stats->dirty_count*PAGE_SIZE*.
>
> Would I get checkpoint size into remus code? I thought it's easier this
> way for I intend to do.
> Please, help me, coz my time is running out.
>
> Thanks jefranca
>
> PS: My English is terrible coz I'm not native
>
>
> 2012/10/5 Shriram Rajagopalan 
>
>> On Wed, Oct 3, 2012 at 4:11 AM, Jos=E9 Eduardo Fran=E7a 
>> wrote:
>> >
>> > I thought remus used xc_domain_save. Is this function used from live
>> > migration?
>> >
>> > Futhermore I have two doubts if really Remus takes the last iteration =
of
>> > live migration
>> >
>> > What's the function?
>>
>> There is no specific function. xc_domain_save is where everything
>> happens. The infinite loop
>> that basically keeps sending checkpoints @ a particular frequency
>>
>>
>> > And how to get de I/O disk size on each period?
>> >
>>
>> This depends on the disk backend. With blktap2 (unfortunately not
>> available in 3.* kernels)
>> tap-remus driver can give you the number of disk blocks sent per
>> checkpoint.
>>
>> With DRBD, it needs a little bit of hacking into the kernel module to
>> return the number of disk blocks
>> being sent with each checkpoint.
>>
>>
>> >> I'm doing my master research and I need to adapt remus code. Now... I
>> >> wanna get the checkpoint size (memory + disk) on each period. Does
>> someone
>> >> know what function does this? I think some fd object's function in
>> remus
>> >> code could just get the memory size.
>> >>
>>
>> You can get memory checkpoint stats for each iteration - like
>> number of pages dirtied, size of data actually transmitted after
>> compression (including headers, etc),
>> time to checkpoint, etc.
>>
>> The attached patch (for xen-4.1.2) will give you the memory checkpoint
>> stats for each checkpoint and
>> can be easily parsed.
>>
>> shriram
>>
>
>

--f46d04389489f14bf904ccd1b380
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Guys,

I see too that I can get stats using struct xen_domctl.
=

Then could I put the code below anywhere and get the dirty_count? For e=
xample:

=A0=A0=A0 DECLARE_DOMCTL;
=A0=A0=A0 uint32_t dirty_count =
=3D domctl.u.shadow_op.stats.dirty_count;


Can I do this?

Or are there a permanent data that return dirty=
_count or checkpoint_size? If yes, what's it?

than=
ks


2012/10/17 Jos=E9 Eduardo Fran=E7a <jefran=
ca@gmail.com>

Hi Shriram,

Thank you for your reply. I'm sorry coz I saw your e=
mail yesterday and my English is bad.
Ok... I saw your patch but I need =
to explain more my problem.

In my master research, I intend to deplo=
y a based-time dynamic checkpoint that should work this way: if checkpoint =
size breaks Lmax (see attached figure) I reduce checkpoint interval,=
 and if checkpoint size doesn't break Lmin  I increase checkpoin=
t interval. After that I will evaluate the performace.



I had read remus code and I saw that remus control the elapsed time in<=
br>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 endtime =3D time.time()
=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0 elapsed =3D (endtime - closure.starttime) * 100=
0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 if elapsed < cfg.interval:

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 time.sleep((cfg.interval - el=
apsed) / 1000.0)

Then I thought I could change the checkpoint interv=
al close to code above, but I suppose I need get checkpoint size. But here =
the  remus code is python and I saw (or thought) that checkpoint size is go=
tten on xc_shadow_op_stats_t *stats or better on stats->dirty_=
count*PAGE_SIZE.



Would I get checkpoint size into remus code? I thought it's easier =
this way for I intend to do.
Please, help me, coz my time is running out.


Thanks jefranca

PS: My English is terrible coz I'm not nativ=
e


2012/10/5 Shriram Rajagopalan <rshriram@cs.ubc.ca>



On Wed, Oct 3, 2012 at 4:11 AM, Jos=E9 =
Eduardo Fran=E7a <jefranca@gmail.com> wrote:



>

> I thought remus used xc_domain_save. Is this function used from live
> migration?

>

> Futhermore I have two doubts if really Remus takes the last iteration =
of

> live migration

>

> What's the function?




There is no specific function. xc_domain_save is where everything

happens. The infinite loop

that basically keeps sending checkpoints @ a particular frequency






> And how to get de I/O disk size on each period?

>




This depends on the disk backend. With blktap2 (unfortunately not

available in 3.* kernels)

tap-remus driver can give you the number of disk blocks sent per checkpoint=
.



With DRBD, it needs a little bit of hacking into the kernel module to

return the number of disk blocks

being sent with each checkpoint.






>> I'm doing my master research and I need to adapt remus code. N=
ow... I

>> wanna get the checkpoint size (memory + disk) on each period. Does=
 someone

>> know what function does this? I think some fd object's functio=
n in remus

>> code could just get the memory size.

>>




You can get memory checkpoint stats for each iteration - like

number of pages dirtied, size of data actually transmitted after

compression (including headers, etc),

time to checkpoint, etc.



The attached patch (for xen-4.1.2) will give you the memory checkpoint

stats for each checkpoint and

can be easily parsed.



shriram








--f46d04389489f14bf904ccd1b380--


--===============7204630991224475497==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7204630991224475497==--


From xen-devel-bounces@lists.xen.org Wed Oct 24 17:49:48 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 17:49:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR557-0007pp-6D; Wed, 24 Oct 2012 17:49:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR555-0007pj-Dw
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 17:49:27 +0000
Received: from [85.158.138.51:6686] by server-11.bemta-3.messagelabs.com id
	5C/EB-24008-62A28805; Wed, 24 Oct 2012 17:49:26 +0000
X-Env-Sender: jefranca@gmail.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1351100963!29316044!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3341 invoked from network); 24 Oct 2012 17:49:25 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 17:49:25 -0000
Received: by mail-vb0-f45.google.com with SMTP id p1so1032529vbi.32
	for ; Wed, 24 Oct 2012 10:49:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=/AH54cJ3Nxj5PmkO9y13XPMfGAfTu5Mpih2x8+YZjRE=;
	b=LH22KQiLB8StdXc293te29OjN7yrcLd0ix8/0qPOKB76FAtEW2TgOWhQMftLI/H1pl
	FcwOvhLnCmCVgvdZGxctqOC33m+rxYQd9COd5M7yHQAXkA+wiUiICJ0OU0SZqZfG5Ys9
	a7scMAoamyeI48OR7xD9HtRZAjjXCoBLMemnHFSL1zb4gaX7Ao0BaWQLO+zfWlVv+/9k
	fbAIKVBncoEbddeWYqUCuYmpgsTC07QGnYuVTabYzwxbpnV3MhnvTWXNbfbuSB+8mcjn
	czEo83QCrjd3B0omD9n/2T1XbjOEYMJ9UfyNKJadW7LoBHYDm6ukcYOozBgNzesCGxLd
	M7ow==
MIME-Version: 1.0
Received: by 10.220.154.139 with SMTP id o11mr9381727vcw.69.1351100946008;
	Wed, 24 Oct 2012 10:49:06 -0700 (PDT)
Received: by 10.58.13.9 with HTTP; Wed, 24 Oct 2012 10:49:05 -0700 (PDT)
In-Reply-To: 
References: 
	<75A1D5EB-12C7-4829-A3F7-4D77B2405FBB@gmail.com>
	
	
	
Date: Wed, 24 Oct 2012 15:49:05 -0200
Message-ID: 
From: =?ISO-8859-1?Q?Jos=E9_Eduardo_Fran=E7a?= 
To: rshriram@cs.ubc.ca
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] How to get the checkpoint size in remus code?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============7204630991224475497=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7204630991224475497==
Content-Type: multipart/alternative; boundary=f46d04389489f14bf904ccd1b380

--f46d04389489f14bf904ccd1b380
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Guys,

I see too that I can get stats using struct xen_domctl.

Then could I put the code below anywhere and get the dirty_count? For
example:

    DECLARE_DOMCTL;
    uint32_t dirty_count =3D domctl.u.shadow_op.stats.dirty_count;

Can I do this?

Or are there a permanent data that return dirty_count or checkpoint_size?
If yes, what's it?

thanks

2012/10/17 Jos=E9 Eduardo Fran=E7a 

> Hi Shriram,
>
> Thank you for your reply. I'm sorry coz I saw your email yesterday and my
> English is bad.
> Ok... I saw your patch but I need to explain more my problem.
>
> In my master research, I intend to deploy a based-time dynamic checkpoint
> that should work this way: if checkpoint size breaks *Lmax* (see attached
> figure) I reduce checkpoint interval, and if checkpoint size doesn't brea=
k
> *Lmin* I increase checkpoint interval. After that I will evaluate the
> performace.
>
> I had read remus code and I saw that remus control the elapsed time in
>
>             endtime =3D time.time()
>             elapsed =3D (endtime - closure.starttime) * 1000
>
>             if elapsed < cfg.interval:
>                 time.sleep((cfg.interval - elapsed) / 1000.0)
>
> Then I thought I could change the checkpoint interval close to code above=
,
> but I suppose I need get checkpoint size. But here the remus code is pyth=
on
> and I saw (or thought) that checkpoint size is gotten on *xc_shadow_op_st=
ats_t
> *stats* or better on *stats->dirty_count*PAGE_SIZE*.
>
> Would I get checkpoint size into remus code? I thought it's easier this
> way for I intend to do.
> Please, help me, coz my time is running out.
>
> Thanks jefranca
>
> PS: My English is terrible coz I'm not native
>
>
> 2012/10/5 Shriram Rajagopalan 
>
>> On Wed, Oct 3, 2012 at 4:11 AM, Jos=E9 Eduardo Fran=E7a 
>> wrote:
>> >
>> > I thought remus used xc_domain_save. Is this function used from live
>> > migration?
>> >
>> > Futhermore I have two doubts if really Remus takes the last iteration =
of
>> > live migration
>> >
>> > What's the function?
>>
>> There is no specific function. xc_domain_save is where everything
>> happens. The infinite loop
>> that basically keeps sending checkpoints @ a particular frequency
>>
>>
>> > And how to get de I/O disk size on each period?
>> >
>>
>> This depends on the disk backend. With blktap2 (unfortunately not
>> available in 3.* kernels)
>> tap-remus driver can give you the number of disk blocks sent per
>> checkpoint.
>>
>> With DRBD, it needs a little bit of hacking into the kernel module to
>> return the number of disk blocks
>> being sent with each checkpoint.
>>
>>
>> >> I'm doing my master research and I need to adapt remus code. Now... I
>> >> wanna get the checkpoint size (memory + disk) on each period. Does
>> someone
>> >> know what function does this? I think some fd object's function in
>> remus
>> >> code could just get the memory size.
>> >>
>>
>> You can get memory checkpoint stats for each iteration - like
>> number of pages dirtied, size of data actually transmitted after
>> compression (including headers, etc),
>> time to checkpoint, etc.
>>
>> The attached patch (for xen-4.1.2) will give you the memory checkpoint
>> stats for each checkpoint and
>> can be easily parsed.
>>
>> shriram
>>
>
>

--f46d04389489f14bf904ccd1b380
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Guys,

I see too that I can get stats using struct xen_domctl.
=

Then could I put the code below anywhere and get the dirty_count? For e=
xample:

=A0=A0=A0 DECLARE_DOMCTL;
=A0=A0=A0 uint32_t dirty_count =
=3D domctl.u.shadow_op.stats.dirty_count;


Can I do this?

Or are there a permanent data that return dirty=
_count or checkpoint_size? If yes, what's it?

than=
ks


2012/10/17 Jos=E9 Eduardo Fran=E7a <jefran=
ca@gmail.com>

Hi Shriram,

Thank you for your reply. I'm sorry coz I saw your e=
mail yesterday and my English is bad.
Ok... I saw your patch but I need =
to explain more my problem.

In my master research, I intend to deplo=
y a based-time dynamic checkpoint that should work this way: if checkpoint =
size breaks Lmax (see attached figure) I reduce checkpoint interval,=
 and if checkpoint size doesn't break Lmin  I increase checkpoin=
t interval. After that I will evaluate the performace.



I had read remus code and I saw that remus control the elapsed time in<=
br>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 endtime =3D time.time()
=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0 elapsed =3D (endtime - closure.starttime) * 100=
0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 if elapsed < cfg.interval:

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 time.sleep((cfg.interval - el=
apsed) / 1000.0)

Then I thought I could change the checkpoint interv=
al close to code above, but I suppose I need get checkpoint size. But here =
the  remus code is python and I saw (or thought) that checkpoint size is go=
tten on xc_shadow_op_stats_t *stats or better on stats->dirty_=
count*PAGE_SIZE.



Would I get checkpoint size into remus code? I thought it's easier =
this way for I intend to do.
Please, help me, coz my time is running out.


Thanks jefranca

PS: My English is terrible coz I'm not nativ=
e


2012/10/5 Shriram Rajagopalan <rshriram@cs.ubc.ca>



On Wed, Oct 3, 2012 at 4:11 AM, Jos=E9 =
Eduardo Fran=E7a <jefranca@gmail.com> wrote:



>

> I thought remus used xc_domain_save. Is this function used from live
> migration?

>

> Futhermore I have two doubts if really Remus takes the last iteration =
of

> live migration

>

> What's the function?




There is no specific function. xc_domain_save is where everything

happens. The infinite loop

that basically keeps sending checkpoints @ a particular frequency






> And how to get de I/O disk size on each period?

>




This depends on the disk backend. With blktap2 (unfortunately not

available in 3.* kernels)

tap-remus driver can give you the number of disk blocks sent per checkpoint=
.



With DRBD, it needs a little bit of hacking into the kernel module to

return the number of disk blocks

being sent with each checkpoint.






>> I'm doing my master research and I need to adapt remus code. N=
ow... I

>> wanna get the checkpoint size (memory + disk) on each period. Does=
 someone

>> know what function does this? I think some fd object's functio=
n in remus

>> code could just get the memory size.

>>




You can get memory checkpoint stats for each iteration - like

number of pages dirtied, size of data actually transmitted after

compression (including headers, etc),

time to checkpoint, etc.



The attached patch (for xen-4.1.2) will give you the memory checkpoint

stats for each checkpoint and

can be easily parsed.



shriram








--f46d04389489f14bf904ccd1b380--


--===============7204630991224475497==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7204630991224475497==--


From xen-devel-bounces@lists.xen.org Wed Oct 24 17:57:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 17:57:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR5CZ-000804-4I; Wed, 24 Oct 2012 17:57:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR5CY-0007zz-I8
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 17:57:10 +0000
Received: from [85.158.143.99:12685] by server-1.bemta-4.messagelabs.com id
	BB/BB-19134-5FB28805; Wed, 24 Oct 2012 17:57:09 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-216.messagelabs.com!1351101428!27267423!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDM4NDA=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDM4NDA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22113 invoked from network); 24 Oct 2012 17:57:09 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Oct 2012 17:57:09 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll387qFkE=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-086-014.pools.arcor-ip.net [84.57.86.14])
	by smtp.strato.de (joses mo21) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 601f20o9OHMRXj
	for ; Wed, 24 Oct 2012 19:57:08 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 67C45183A7
	for ; Wed, 24 Oct 2012 19:57:07 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 6a0c73ae9ce5cca72f788c0e0f8fd6872010d83e
Message-Id: <6a0c73ae9ce5cca72f78.1351101425@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Wed, 24 Oct 2012 19:57:05 +0200
From: Olaf Hering 
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] tools/hvmloader: move shared_info to reserved
	memory area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering 
# Date 1351101387 -7200
# Node ID 6a0c73ae9ce5cca72f788c0e0f8fd6872010d83e
# Parent  22e08c9ac770db07c3c3e7c844aa7153050939f3
tools/hvmloader: move shared_info to reserved memory area

Reserve a range of 1MB for the HVM shared info page at 0xFE700000. This
area is already marked as reserved in the E820 map. The purpose of this
change is to provide Linux PVonHVM guests with a fixed page outside of
ordinary RAM. If the shared page is located in RAM it would be
overwritten during a kexec boot.

Signed-off-by: Olaf Hering 

diff -r 22e08c9ac770 -r 6a0c73ae9ce5 tools/firmware/hvmloader/config.h
--- a/tools/firmware/hvmloader/config.h
+++ b/tools/firmware/hvmloader/config.h
@@ -68,6 +68,8 @@ extern unsigned long pci_mem_start, pci_
 /* NB. ACPI_INFO_PHYSICAL_ADDRESS *MUST* match definition in acpi/dsdt.asl! */
 #define ACPI_INFO_PHYSICAL_ADDRESS    0xFC000000
 #define RESERVED_MEMORY_DYNAMIC       0xFC001000
+#define HVM_SHARED_INFO_AREA          0xFE700000
+#define HVM_SHARED_INFO_SIZE          0x00100000
 
 extern unsigned long scratch_start;
 
diff -r 22e08c9ac770 -r 6a0c73ae9ce5 tools/firmware/hvmloader/util.c
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -433,11 +433,18 @@ void *mem_alloc(uint32_t size, uint32_t 
     if ( align < 16 )
         align = 16;
 
+retry:
     s = (reserve + align) & ~(align - 1);
     e = s + size - 1;
 
     BUG_ON((e < s) || (e >> PAGE_SHIFT) >= hvm_info->reserved_mem_pgstart);
 
+    /* Skip the shared info region */
+    if (s <= HVM_SHARED_INFO_AREA && e >= HVM_SHARED_INFO_AREA) {
+	    reserve = HVM_SHARED_INFO_AREA + HVM_SHARED_INFO_SIZE - 1;
+	    goto retry;
+    }
+
     while ( (reserve >> PAGE_SHIFT) != (e >> PAGE_SHIFT) )
     {
         reserve += PAGE_SIZE;
@@ -765,7 +772,7 @@ struct shared_info *get_shared_info(void
     xatp.domid = DOMID_SELF;
     xatp.space = XENMAPSPACE_shared_info;
     xatp.idx   = 0;
-    xatp.gpfn  = mem_hole_alloc(1);
+    xatp.gpfn  = HVM_SHARED_INFO_AREA >> PAGE_SHIFT;
     shared_info = (struct shared_info *)(xatp.gpfn << PAGE_SHIFT);
     if ( hypercall_memory_op(XENMEM_add_to_physmap, &xatp) != 0 )
         BUG();

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 17:57:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 17:57:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR5CZ-000804-4I; Wed, 24 Oct 2012 17:57:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR5CY-0007zz-I8
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 17:57:10 +0000
Received: from [85.158.143.99:12685] by server-1.bemta-4.messagelabs.com id
	BB/BB-19134-5FB28805; Wed, 24 Oct 2012 17:57:09 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-216.messagelabs.com!1351101428!27267423!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDM4NDA=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDM4NDA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22113 invoked from network); 24 Oct 2012 17:57:09 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Oct 2012 17:57:09 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll387qFkE=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-086-014.pools.arcor-ip.net [84.57.86.14])
	by smtp.strato.de (joses mo21) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 601f20o9OHMRXj
	for ; Wed, 24 Oct 2012 19:57:08 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 67C45183A7
	for ; Wed, 24 Oct 2012 19:57:07 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 6a0c73ae9ce5cca72f788c0e0f8fd6872010d83e
Message-Id: <6a0c73ae9ce5cca72f78.1351101425@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Wed, 24 Oct 2012 19:57:05 +0200
From: Olaf Hering 
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] tools/hvmloader: move shared_info to reserved
	memory area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering 
# Date 1351101387 -7200
# Node ID 6a0c73ae9ce5cca72f788c0e0f8fd6872010d83e
# Parent  22e08c9ac770db07c3c3e7c844aa7153050939f3
tools/hvmloader: move shared_info to reserved memory area

Reserve a range of 1MB for the HVM shared info page at 0xFE700000. This
area is already marked as reserved in the E820 map. The purpose of this
change is to provide Linux PVonHVM guests with a fixed page outside of
ordinary RAM. If the shared page is located in RAM it would be
overwritten during a kexec boot.

Signed-off-by: Olaf Hering 

diff -r 22e08c9ac770 -r 6a0c73ae9ce5 tools/firmware/hvmloader/config.h
--- a/tools/firmware/hvmloader/config.h
+++ b/tools/firmware/hvmloader/config.h
@@ -68,6 +68,8 @@ extern unsigned long pci_mem_start, pci_
 /* NB. ACPI_INFO_PHYSICAL_ADDRESS *MUST* match definition in acpi/dsdt.asl! */
 #define ACPI_INFO_PHYSICAL_ADDRESS    0xFC000000
 #define RESERVED_MEMORY_DYNAMIC       0xFC001000
+#define HVM_SHARED_INFO_AREA          0xFE700000
+#define HVM_SHARED_INFO_SIZE          0x00100000
 
 extern unsigned long scratch_start;
 
diff -r 22e08c9ac770 -r 6a0c73ae9ce5 tools/firmware/hvmloader/util.c
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -433,11 +433,18 @@ void *mem_alloc(uint32_t size, uint32_t 
     if ( align < 16 )
         align = 16;
 
+retry:
     s = (reserve + align) & ~(align - 1);
     e = s + size - 1;
 
     BUG_ON((e < s) || (e >> PAGE_SHIFT) >= hvm_info->reserved_mem_pgstart);
 
+    /* Skip the shared info region */
+    if (s <= HVM_SHARED_INFO_AREA && e >= HVM_SHARED_INFO_AREA) {
+	    reserve = HVM_SHARED_INFO_AREA + HVM_SHARED_INFO_SIZE - 1;
+	    goto retry;
+    }
+
     while ( (reserve >> PAGE_SHIFT) != (e >> PAGE_SHIFT) )
     {
         reserve += PAGE_SIZE;
@@ -765,7 +772,7 @@ struct shared_info *get_shared_info(void
     xatp.domid = DOMID_SELF;
     xatp.space = XENMAPSPACE_shared_info;
     xatp.idx   = 0;
-    xatp.gpfn  = mem_hole_alloc(1);
+    xatp.gpfn  = HVM_SHARED_INFO_AREA >> PAGE_SHIFT;
     shared_info = (struct shared_info *)(xatp.gpfn << PAGE_SHIFT);
     if ( hypercall_memory_op(XENMEM_add_to_physmap, &xatp) != 0 )
         BUG();

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 18:12:15 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 18:12:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR5Qj-0008Hh-IP; Wed, 24 Oct 2012 18:11:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR5Qh-0008HZ-EV
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 18:11:47 +0000
Received: from [85.158.139.83:36552] by server-11.bemta-5.messagelabs.com id
	BF/25-14870-26F28805; Wed, 24 Oct 2012 18:11:46 +0000
X-Env-Sender: jfehlig@suse.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1351102303!32051376!1
X-Originating-IP: [137.65.250.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5058 invoked from network); 24 Oct 2012 18:11:45 -0000
Received: from victor.provo.novell.com (HELO victor.provo.novell.com)
	(137.65.250.26)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Oct 2012 18:11:45 -0000
Received: from [137.65.135.33] (prv-ext-foundry1int.gns.novell.com
	[137.65.251.240])
	by victor.provo.novell.com with ESMTP (TLS encrypted);
	Wed, 24 Oct 2012 12:11:38 -0600
Message-ID: <50882F59.6070203@suse.com>
Date: Wed, 24 Oct 2012 12:11:37 -0600
From: Jim Fehlig 
User-Agent: Thunderbird 2.0.0.24 (X11/20100302)
MIME-Version: 1.0
To: George Dunlap 
References: 
In-Reply-To: 
Cc: Dario Faggioli ,
	Bamvor Jian Zhang ,
	=?ISO-8859-1?Q?Ondr=28ej_Holec=28?= =?ISO-8859-1?Q?ek?=
	, Chun Yan Liu , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] libxl drivers for libvirt?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap wrote:
> Hey Jim,
>
> I was wondering if you or someone on your team could give me an idea
> what the status of libxl support is in libvirt, particularly wrt
> various releases?
>
> I'm asking because I'm going to UDS next week to talk about the 13.04
> release, and it would be good to get Xen 4.2 in; but that in part
> depends on whether there will be libvirt support for 4.2 in whatever
> version of libvirt they ship as well.  I know Dario has been facing
> the same kind of questions for Fedora 18.
>
> It appears that libvirt 0.10.2 has limited support for the 4.1 libxl
> driver; but:
> * This doesn't include some core features, like live migration

Right.  Chunyan has some patches to implement migration against 4.1
libxl, but IIRC she is still investigating a bug.  Chunyan, can you give
George an update on your libvirt libxl migration patches?

> * It won't compile against 4.2's libxl

Right again.  Ondrej has been looking into this.  Ondrej, do you have
any status to report?  Any questions for the Xen folks wrt 4.1 vs 4.2 libxl?

> Is that right?
>
> So I guess it would be nice to know:
> * What kind of Xen support is available in the most recent release
> (0.10.2, I believe), both xend and libxl

I've provided a table below that lists all of the libvirt hypervisor
driver functions and their implementation status for qemu/kvm, legacy
xen, and libxl drivers.

> * What kind of Xen support for libxl is in the libvirt development
> branch, and do you have an idea when full support for 4.2 (at least,
> including migration, suspend/resume, &c) might be available?

Nothing has changed in git master over what is available in 0.10.2, but
we are now starting to pick up this work.  Our priorities are to first
get the libxl driver compiling against 4.2 and all of the existing
functionality that works with 4.1 working with 4.2, followed by closing
the feature gap with the legacy xen driver, and finally closing the
feature gap with the qemu driver where it makes sense.  This is
obviously quite a bit of work and any help would be appreciated :).

BTW, we don't have any motivation to add features to the 4.1 version of
the libvirt libxl driver.  Bamvor recently sent a patchset to add
finer-grained locking to the libxl driver, but this code is independent
of underlying libxl version IMO

https://www.redhat.com/archives/libvir-list/2012-October/msg00503.html


> * Whether it would be easy for distros to backport 4.2 libxl support
> to whatever their release is?

Until we have patches to make the driver work with 4.2 libxl, I can't
speculate on the effort to backport to previous libvirt releases.

Regards,
Jim

> That would help us better advise distros whether to:
> * Stick with Xen 4.1 for the next release
> * Go with Xen 4.2 but suggest continuing to use xend if libvirt
> support is wanted
> * Go with Xen 4.2 and backport patches to make libvirt work with libxl
> * Go with Xen 4.2 and expect that libxl support will show up without
> too much effort
>
> Obviously change is the only constant, so you can't predict with
> perfect certainty; but if we have an idea what's most likely, we can
> plan on that and then adjust based on what actually happens.
>
> Thanks!
>  -George
>

libvirt hypervisor driver funcs         qemu  xend  libxl
-----------------------------------------------------------------
virDrvOpen                             |  x  |  x  |  x  |
virDrvClose                            |  x  |  x  |  x  |
virDrvDrvSupportsFeature               |  x  |  x  |     |
virDrvGetType                          |  x  |  x  |  x  |
virDrvGetVersion                       |  x  |  x  |  x  |
virDrvGetLibVersion                    |  x  |  x  |  x  |
virDrvGetHostname                      |  x  |  x  |  x  |
virDrvGetSysinfo                       |  x  |     |     |
virDrvGetMaxVcpus                      |  x  |  x  |  x  |
virDrvNodeGetInfo                      |  x  |  x  |  x  |
virDrvGetCapabilities                  |  x  |  x  |  x  |
virDrvListDomains                      |  x  |  x  |  x  |
virDrvNumOfDomains                     |  x  |  x  |  x  |
virDrvListAllDomains                   |  x  |     |  x  |
virDrvDomainCreateXML                  |  x  |  x  |  x  |
virDrvDomainLookupByID                 |  x  |  x  |  x  |
virDrvDomainLookupByUUID               |  x  |  x  |  x  |
virDrvDomainLookupByName               |  x  |  x  |  x  |
virDrvDomainSuspend                    |  x  |  x  |  x  |
virDrvDomainResume                     |  x  |  x  |  x  |
virDrvDomainPMSuspendForDuration       |  x  |     |     |
virDrvDomainPMWakeup                   |  x  |     |     |
virDrvDomainShutdown                   |  x  |  x  |  x  |
virDrvDomainShutdownFlags              |  x  |  x  |  x  |
virDrvDomainReboot                     |  x  |  x  |  x  |
virDrvDomainReset                      |  x  |     |     |
virDrvDomainDestroy                    |  x  |  x  |  x  |
virDrvDomainDestroyFlags               |  x  |  x  |  x  |
virDrvDomainGetOSType                  |  x  |  x  |  x  |
virDrvDomainGetHostname                |     |     |     |
virDrvDomainGetMaxMemory               |  x  |  x  |  x  |
virDrvDomainSetMaxMemory               |  x  |  x  |  x  |
virDrvDomainSetMemory                  |  x  |  x  |  x  |
virDrvDomainSetMemoryFlags             |  x  |     |  x  |
virDrvDomainSetMemoryParameters        |  x  |     |     |
virDrvDomainGetMemoryParameters        |  x  |     |     |
virDrvDomainSetNumaParameters          |  x  |     |     |
virDrvDomainGetNumaParameters          |  x  |     |     |
virDrvDomainSetBlkioParameters         |  x  |     |     |
virDrvDomainGetBlkioParameters         |  x  |     |     |
virDrvDomainGetInfo                    |  x  |  x  |  x  |
virDrvDomainGetState                   |  x  |  x  |  x  |
virDrvDomainGetControlInfo             |  x  |     |     |
virDrvDomainSave                       |  x  |  x  |  x  |
virDrvDomainSaveFlags                  |  x  |  x  |  x  |
virDrvDomainRestore                    |  x  |  x  |  x  |
virDrvDomainRestoreFlags               |  x  |  x  |  x  |
virDrvDomainSaveImageGetXMLDesc        |  x  |     |     |
virDrvDomainSaveImageDefineXML         |  x  |     |     |
virDrvDomainCoreDump                   |  x  |  x  |  x  |
virDrvDomainScreenshot                 |  x  |     |     |
virDrvDomainSetVcpus                   |  x  |  x  |  x  |
virDrvDomainSetVcpusFlags              |  x  |  x  |  x  |
virDrvDomainGetVcpusFlags              |  x  |  x  |  x  |
virDrvDomainPinVcpu                    |  x  |  x  |  x  |
virDrvDomainPinVcpuFlags               |  x  |     |     |
virDrvDomainGetVcpuPinInfo             |  x  |     |     |
virDrvDomainPinEmulator                |  x  |     |     |
virDrvDomainGetEmulatorPinInfo         |  x  |     |     |
virDrvDomainGetVcpus                   |  x  |  x  |  x  |
virDrvDomainGetMaxVcpus                |  x  |  x  |     |
virDrvDomainGetSecurityLabel           |  x  |     |     |
virDrvDomainGetSecurityLabelList       |  x  |     |     |
virDrvNodeGetSecurityModel             |  x  |     |     |
virDrvDomainGetXMLDesc                 |  x  |  x  |  x  |
virDrvConnectDomainXMLFromNative       |  x  |  x  |  x  |
virDrvConnectDomainXMLToNative         |  x  |  x  |  x  |
virDrvListDefinedDomains               |  x  |  x  |  x  |
virDrvNumOfDefinedDomains              |  x  |  x  |  x  |
virDrvDomainCreate                     |  x  |  x  |  x  |
virDrvDomainCreateWithFlags            |  x  |  x  |  x  |
virDrvDomainDefineXML                  |  x  |  x  |  x  |
virDrvDomainUndefine                   |  x  |  x  |  x  |
virDrvDomainUndefineFlags              |  x  |  x  |  x  |
virDrvDomainAttachDevice               |  x  |  x  |  x  |
virDrvDomainAttachDeviceFlags          |  x  |  x  |  x  |
virDrvDomainDetachDevice               |  x  |  x  |  x  |
virDrvDomainDetachDeviceFlags          |  x  |  x  |  x  |
virDrvDomainUpdateDeviceFlags          |  x  |  x  |  x  |
virDrvDomainGetAutostart               |  x  |  x  |  x  |
virDrvDomainSetAutostart               |  x  |  x  |  x  | 
virDrvDomainGetSchedulerType           |  x  |  x  |  x  |
virDrvDomainGetSchedulerParameters     |  x  |  x  |  x  |
virDrvDomainGetSchedulerParametersFlags|  x  |  x  |  x  |
virDrvDomainSetSchedulerParameters     |  x  |  x  |  x  |
virDrvDomainSetSchedulerParametersFlags|  x  |  x  |  x  |
virDrvDomainMigratePrepare             |     |  x  |     |
virDrvDomainMigratePerform             |  x  |  x  |     |
virDrvDomainMigrateFinish              |     |  x  |     |
virDrvDomainBlockResize                |  x  |     |     |
virDrvDomainBlockStats                 |  x  |     |     |
virDrvDomainBlockStatsFlags            |  x  |     |     |
virDrvDomainInterfaceStats             |  x  |  x  |     |
virDrvDomainSetInterfaceParameters     |  x  |     |     |
virDrvDomainGetInterfaceParameters     |  x  |     |     |
virDrvDomainMemoryStats                |  x  |     |     |
virDrvDomainBlockPeek                  |  x  |  x  |     |
virDrvDomainMemoryPeek                 |  x  |     |     |
virDrvDomainGetBlockInfo               |  x  |     |     |
virDrvNodeGetCPUStats                  |  x  |     |     |
virDrvNodeGetMemoryStats               |  x  |     |     |
virDrvNodeGetCellsFreeMemory           |  x  |  x  |     |
virDrvNodeGetFreeMemory                |  x  |  x  |  x  |
virDrvDomainEventRegister              |  x  |  x  |  x  |
virDrvDomainEventDeregister            |  x  |  x  |  x  |
virDrvDomainMigratePrepare2            |  x  |     |     |
virDrvDomainMigrateFinish2             |  x  |     |     |
virDrvNodeDeviceDettach                |  x  |  x  |     |
virDrvNodeDeviceReAttach               |  x  |  x  |     |
virDrvNodeDeviceReset                  |  x  |  x  |     |
virDrvDomainMigratePrepareTunnel       |  x  |     |     |
virDrvConnectIsEncrypted               |  x  |  x  |     |
virDrvConnectIsSecure                  |  x  |  x  |     |
virDrvDomainIsActive                   |  x  |  x  |  x  |
virDrvDomainIsPersistent               |  x  |  x  |  x  |
virDrvDomainIsUpdated                  |  x  |  x  |  x  |
virDrvCompareCPU                       |  x  |     |     |
virDrvBaselineCPU                      |  x  |     |     |
virDrvDomainGetJobInfo                 |  x  |     |     |
virDrvDomainAbortJob                   |  x  |     |     |
virDrvDomainMigrateSetMaxDowntime      |  x  |     |     |
virDrvDomainMigrateGetMaxSpeed         |  x  |     |     |
virDrvDomainMigrateSetMaxSpeed         |  x  |     |     |
virDrvDomainEventRegisterAny           |  x  |     |  x  |
virDrvDomainEventDeregisterAny         |  x  |     |  x  |
virDrvDomainManagedSave                |  x  |     |  x  |
virDrvDomainHasManagedSaveImage        |  x  |     |  x  |
virDrvDomainManagedSaveRemove          |  x  |     |  x  |
virDrvDomainSnapshotCreateXML          |  x  |     |     |
virDrvDomainSnapshotGetXMLDesc         |  x  |     |     |
virDrvDomainSnapshotNum                |  x  |     |     |
virDrvDomainSnapshotListNames          |  x  |     |     |
virDrvDomainListAllSnapshots           |  x  |     |     |
virDrvDomainSnapshotNumChildren        |  x  |     |     |
virDrvDomainSnapshotListChildrenNames  |  x  |     |     |
virDrvDomainSnapshotListAllChildren    |  x  |     |     |
virDrvDomainSnapshotLookupByName       |  x  |     |     |
virDrvDomainHasCurrentSnapshot         |  x  |     |     |
virDrvDomainSnapshotGetParent          |  x  |     |     |
virDrvDomainSnapshotCurrent            |  x  |     |     |
virDrvDomainSnapshotIsCurrent          |  x  |     |     |
virDrvDomainSnapshotHasMetadata        |  x  |     |     |
virDrvDomainRevertToSnapshot           |  x  |     |     |
virDrvDomainSnapshotDelete             |  x  |     |     |
virDrvDomainQemuMonitorCommand         |  x  |     |     |
virDrvDomainQemuAttach                 |  x  |     |     |
virDrvDomainQemuAgentCommand           |  x  |     |     |
virDrvDomainOpenConsole                |  x  |  x  |     |
virDrvDomainOpenGraphics               |  x  |     |     |
virDrvDomainInjectNMI                  |  x  |     |     |
virDrvDomainMigrateBegin3              |  x  |     |     |
virDrvDomainMigratePrepare3            |  x  |     |     |
virDrvDomainMigratePrepareTunnel3      |  x  |     |     |
virDrvDomainMigratePerform3            |  x  |     |     |
virDrvDomainMigrateFinish3             |  x  |     |     |
virDrvDomainMigrateConfirm3            |  x  |     |     |
virDrvDomainSendKey                    |  x  |     |     |
virDrvDomainBlockJobAbort              |  x  |     |     |
virDrvDomainGetBlockJobInfo            |  x  |     |     |
virDrvDomainBlockJobSetSpeed           |  x  |     |     |
virDrvDomainBlockPull                  |  x  |     |     |
virDrvDomainBlockRebase                |  x  |     |     |
virDrvDomainBlockCommit                |  x  |     |     |
virDrvSetKeepAlive                     |     |     |     |
virDrvConnectIsAlive                   |  x  |     |     |
virDrvNodeSuspendForDuration           |  x  |  x  |     |
virDrvDomainSetBlockIoTune             |  x  |     |     |
virDrvDomainGetBlockIoTune             |  x  |     |     |
virDrvDomainGetCPUStats                |  x  |     |     |
virDrvDomainGetDiskErrors              |  x  |     |     |
virDrvDomainSetMetadata                |  x  |     |     |
virDrvDomainGetMetadata                |  x  |     |     |
virDrvNodeGetMemoryParameters          |  x  |  x  |     |
virDrvNodeSetMemoryParameters          |  x  |  x  |     |


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 18:12:15 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 18:12:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR5Qj-0008Hh-IP; Wed, 24 Oct 2012 18:11:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR5Qh-0008HZ-EV
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 18:11:47 +0000
Received: from [85.158.139.83:36552] by server-11.bemta-5.messagelabs.com id
	BF/25-14870-26F28805; Wed, 24 Oct 2012 18:11:46 +0000
X-Env-Sender: jfehlig@suse.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1351102303!32051376!1
X-Originating-IP: [137.65.250.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5058 invoked from network); 24 Oct 2012 18:11:45 -0000
Received: from victor.provo.novell.com (HELO victor.provo.novell.com)
	(137.65.250.26)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Oct 2012 18:11:45 -0000
Received: from [137.65.135.33] (prv-ext-foundry1int.gns.novell.com
	[137.65.251.240])
	by victor.provo.novell.com with ESMTP (TLS encrypted);
	Wed, 24 Oct 2012 12:11:38 -0600
Message-ID: <50882F59.6070203@suse.com>
Date: Wed, 24 Oct 2012 12:11:37 -0600
From: Jim Fehlig 
User-Agent: Thunderbird 2.0.0.24 (X11/20100302)
MIME-Version: 1.0
To: George Dunlap 
References: 
In-Reply-To: 
Cc: Dario Faggioli ,
	Bamvor Jian Zhang ,
	=?ISO-8859-1?Q?Ondr=28ej_Holec=28?= =?ISO-8859-1?Q?ek?=
	, Chun Yan Liu , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] libxl drivers for libvirt?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap wrote:
> Hey Jim,
>
> I was wondering if you or someone on your team could give me an idea
> what the status of libxl support is in libvirt, particularly wrt
> various releases?
>
> I'm asking because I'm going to UDS next week to talk about the 13.04
> release, and it would be good to get Xen 4.2 in; but that in part
> depends on whether there will be libvirt support for 4.2 in whatever
> version of libvirt they ship as well.  I know Dario has been facing
> the same kind of questions for Fedora 18.
>
> It appears that libvirt 0.10.2 has limited support for the 4.1 libxl
> driver; but:
> * This doesn't include some core features, like live migration

Right.  Chunyan has some patches to implement migration against 4.1
libxl, but IIRC she is still investigating a bug.  Chunyan, can you give
George an update on your libvirt libxl migration patches?

> * It won't compile against 4.2's libxl

Right again.  Ondrej has been looking into this.  Ondrej, do you have
any status to report?  Any questions for the Xen folks wrt 4.1 vs 4.2 libxl?

> Is that right?
>
> So I guess it would be nice to know:
> * What kind of Xen support is available in the most recent release
> (0.10.2, I believe), both xend and libxl

I've provided a table below that lists all of the libvirt hypervisor
driver functions and their implementation status for qemu/kvm, legacy
xen, and libxl drivers.

> * What kind of Xen support for libxl is in the libvirt development
> branch, and do you have an idea when full support for 4.2 (at least,
> including migration, suspend/resume, &c) might be available?

Nothing has changed in git master over what is available in 0.10.2, but
we are now starting to pick up this work.  Our priorities are to first
get the libxl driver compiling against 4.2 and all of the existing
functionality that works with 4.1 working with 4.2, followed by closing
the feature gap with the legacy xen driver, and finally closing the
feature gap with the qemu driver where it makes sense.  This is
obviously quite a bit of work and any help would be appreciated :).

BTW, we don't have any motivation to add features to the 4.1 version of
the libvirt libxl driver.  Bamvor recently sent a patchset to add
finer-grained locking to the libxl driver, but this code is independent
of underlying libxl version IMO

https://www.redhat.com/archives/libvir-list/2012-October/msg00503.html


> * Whether it would be easy for distros to backport 4.2 libxl support
> to whatever their release is?

Until we have patches to make the driver work with 4.2 libxl, I can't
speculate on the effort to backport to previous libvirt releases.

Regards,
Jim

> That would help us better advise distros whether to:
> * Stick with Xen 4.1 for the next release
> * Go with Xen 4.2 but suggest continuing to use xend if libvirt
> support is wanted
> * Go with Xen 4.2 and backport patches to make libvirt work with libxl
> * Go with Xen 4.2 and expect that libxl support will show up without
> too much effort
>
> Obviously change is the only constant, so you can't predict with
> perfect certainty; but if we have an idea what's most likely, we can
> plan on that and then adjust based on what actually happens.
>
> Thanks!
>  -George
>

libvirt hypervisor driver funcs         qemu  xend  libxl
-----------------------------------------------------------------
virDrvOpen                             |  x  |  x  |  x  |
virDrvClose                            |  x  |  x  |  x  |
virDrvDrvSupportsFeature               |  x  |  x  |     |
virDrvGetType                          |  x  |  x  |  x  |
virDrvGetVersion                       |  x  |  x  |  x  |
virDrvGetLibVersion                    |  x  |  x  |  x  |
virDrvGetHostname                      |  x  |  x  |  x  |
virDrvGetSysinfo                       |  x  |     |     |
virDrvGetMaxVcpus                      |  x  |  x  |  x  |
virDrvNodeGetInfo                      |  x  |  x  |  x  |
virDrvGetCapabilities                  |  x  |  x  |  x  |
virDrvListDomains                      |  x  |  x  |  x  |
virDrvNumOfDomains                     |  x  |  x  |  x  |
virDrvListAllDomains                   |  x  |     |  x  |
virDrvDomainCreateXML                  |  x  |  x  |  x  |
virDrvDomainLookupByID                 |  x  |  x  |  x  |
virDrvDomainLookupByUUID               |  x  |  x  |  x  |
virDrvDomainLookupByName               |  x  |  x  |  x  |
virDrvDomainSuspend                    |  x  |  x  |  x  |
virDrvDomainResume                     |  x  |  x  |  x  |
virDrvDomainPMSuspendForDuration       |  x  |     |     |
virDrvDomainPMWakeup                   |  x  |     |     |
virDrvDomainShutdown                   |  x  |  x  |  x  |
virDrvDomainShutdownFlags              |  x  |  x  |  x  |
virDrvDomainReboot                     |  x  |  x  |  x  |
virDrvDomainReset                      |  x  |     |     |
virDrvDomainDestroy                    |  x  |  x  |  x  |
virDrvDomainDestroyFlags               |  x  |  x  |  x  |
virDrvDomainGetOSType                  |  x  |  x  |  x  |
virDrvDomainGetHostname                |     |     |     |
virDrvDomainGetMaxMemory               |  x  |  x  |  x  |
virDrvDomainSetMaxMemory               |  x  |  x  |  x  |
virDrvDomainSetMemory                  |  x  |  x  |  x  |
virDrvDomainSetMemoryFlags             |  x  |     |  x  |
virDrvDomainSetMemoryParameters        |  x  |     |     |
virDrvDomainGetMemoryParameters        |  x  |     |     |
virDrvDomainSetNumaParameters          |  x  |     |     |
virDrvDomainGetNumaParameters          |  x  |     |     |
virDrvDomainSetBlkioParameters         |  x  |     |     |
virDrvDomainGetBlkioParameters         |  x  |     |     |
virDrvDomainGetInfo                    |  x  |  x  |  x  |
virDrvDomainGetState                   |  x  |  x  |  x  |
virDrvDomainGetControlInfo             |  x  |     |     |
virDrvDomainSave                       |  x  |  x  |  x  |
virDrvDomainSaveFlags                  |  x  |  x  |  x  |
virDrvDomainRestore                    |  x  |  x  |  x  |
virDrvDomainRestoreFlags               |  x  |  x  |  x  |
virDrvDomainSaveImageGetXMLDesc        |  x  |     |     |
virDrvDomainSaveImageDefineXML         |  x  |     |     |
virDrvDomainCoreDump                   |  x  |  x  |  x  |
virDrvDomainScreenshot                 |  x  |     |     |
virDrvDomainSetVcpus                   |  x  |  x  |  x  |
virDrvDomainSetVcpusFlags              |  x  |  x  |  x  |
virDrvDomainGetVcpusFlags              |  x  |  x  |  x  |
virDrvDomainPinVcpu                    |  x  |  x  |  x  |
virDrvDomainPinVcpuFlags               |  x  |     |     |
virDrvDomainGetVcpuPinInfo             |  x  |     |     |
virDrvDomainPinEmulator                |  x  |     |     |
virDrvDomainGetEmulatorPinInfo         |  x  |     |     |
virDrvDomainGetVcpus                   |  x  |  x  |  x  |
virDrvDomainGetMaxVcpus                |  x  |  x  |     |
virDrvDomainGetSecurityLabel           |  x  |     |     |
virDrvDomainGetSecurityLabelList       |  x  |     |     |
virDrvNodeGetSecurityModel             |  x  |     |     |
virDrvDomainGetXMLDesc                 |  x  |  x  |  x  |
virDrvConnectDomainXMLFromNative       |  x  |  x  |  x  |
virDrvConnectDomainXMLToNative         |  x  |  x  |  x  |
virDrvListDefinedDomains               |  x  |  x  |  x  |
virDrvNumOfDefinedDomains              |  x  |  x  |  x  |
virDrvDomainCreate                     |  x  |  x  |  x  |
virDrvDomainCreateWithFlags            |  x  |  x  |  x  |
virDrvDomainDefineXML                  |  x  |  x  |  x  |
virDrvDomainUndefine                   |  x  |  x  |  x  |
virDrvDomainUndefineFlags              |  x  |  x  |  x  |
virDrvDomainAttachDevice               |  x  |  x  |  x  |
virDrvDomainAttachDeviceFlags          |  x  |  x  |  x  |
virDrvDomainDetachDevice               |  x  |  x  |  x  |
virDrvDomainDetachDeviceFlags          |  x  |  x  |  x  |
virDrvDomainUpdateDeviceFlags          |  x  |  x  |  x  |
virDrvDomainGetAutostart               |  x  |  x  |  x  |
virDrvDomainSetAutostart               |  x  |  x  |  x  | 
virDrvDomainGetSchedulerType           |  x  |  x  |  x  |
virDrvDomainGetSchedulerParameters     |  x  |  x  |  x  |
virDrvDomainGetSchedulerParametersFlags|  x  |  x  |  x  |
virDrvDomainSetSchedulerParameters     |  x  |  x  |  x  |
virDrvDomainSetSchedulerParametersFlags|  x  |  x  |  x  |
virDrvDomainMigratePrepare             |     |  x  |     |
virDrvDomainMigratePerform             |  x  |  x  |     |
virDrvDomainMigrateFinish              |     |  x  |     |
virDrvDomainBlockResize                |  x  |     |     |
virDrvDomainBlockStats                 |  x  |     |     |
virDrvDomainBlockStatsFlags            |  x  |     |     |
virDrvDomainInterfaceStats             |  x  |  x  |     |
virDrvDomainSetInterfaceParameters     |  x  |     |     |
virDrvDomainGetInterfaceParameters     |  x  |     |     |
virDrvDomainMemoryStats                |  x  |     |     |
virDrvDomainBlockPeek                  |  x  |  x  |     |
virDrvDomainMemoryPeek                 |  x  |     |     |
virDrvDomainGetBlockInfo               |  x  |     |     |
virDrvNodeGetCPUStats                  |  x  |     |     |
virDrvNodeGetMemoryStats               |  x  |     |     |
virDrvNodeGetCellsFreeMemory           |  x  |  x  |     |
virDrvNodeGetFreeMemory                |  x  |  x  |  x  |
virDrvDomainEventRegister              |  x  |  x  |  x  |
virDrvDomainEventDeregister            |  x  |  x  |  x  |
virDrvDomainMigratePrepare2            |  x  |     |     |
virDrvDomainMigrateFinish2             |  x  |     |     |
virDrvNodeDeviceDettach                |  x  |  x  |     |
virDrvNodeDeviceReAttach               |  x  |  x  |     |
virDrvNodeDeviceReset                  |  x  |  x  |     |
virDrvDomainMigratePrepareTunnel       |  x  |     |     |
virDrvConnectIsEncrypted               |  x  |  x  |     |
virDrvConnectIsSecure                  |  x  |  x  |     |
virDrvDomainIsActive                   |  x  |  x  |  x  |
virDrvDomainIsPersistent               |  x  |  x  |  x  |
virDrvDomainIsUpdated                  |  x  |  x  |  x  |
virDrvCompareCPU                       |  x  |     |     |
virDrvBaselineCPU                      |  x  |     |     |
virDrvDomainGetJobInfo                 |  x  |     |     |
virDrvDomainAbortJob                   |  x  |     |     |
virDrvDomainMigrateSetMaxDowntime      |  x  |     |     |
virDrvDomainMigrateGetMaxSpeed         |  x  |     |     |
virDrvDomainMigrateSetMaxSpeed         |  x  |     |     |
virDrvDomainEventRegisterAny           |  x  |     |  x  |
virDrvDomainEventDeregisterAny         |  x  |     |  x  |
virDrvDomainManagedSave                |  x  |     |  x  |
virDrvDomainHasManagedSaveImage        |  x  |     |  x  |
virDrvDomainManagedSaveRemove          |  x  |     |  x  |
virDrvDomainSnapshotCreateXML          |  x  |     |     |
virDrvDomainSnapshotGetXMLDesc         |  x  |     |     |
virDrvDomainSnapshotNum                |  x  |     |     |
virDrvDomainSnapshotListNames          |  x  |     |     |
virDrvDomainListAllSnapshots           |  x  |     |     |
virDrvDomainSnapshotNumChildren        |  x  |     |     |
virDrvDomainSnapshotListChildrenNames  |  x  |     |     |
virDrvDomainSnapshotListAllChildren    |  x  |     |     |
virDrvDomainSnapshotLookupByName       |  x  |     |     |
virDrvDomainHasCurrentSnapshot         |  x  |     |     |
virDrvDomainSnapshotGetParent          |  x  |     |     |
virDrvDomainSnapshotCurrent            |  x  |     |     |
virDrvDomainSnapshotIsCurrent          |  x  |     |     |
virDrvDomainSnapshotHasMetadata        |  x  |     |     |
virDrvDomainRevertToSnapshot           |  x  |     |     |
virDrvDomainSnapshotDelete             |  x  |     |     |
virDrvDomainQemuMonitorCommand         |  x  |     |     |
virDrvDomainQemuAttach                 |  x  |     |     |
virDrvDomainQemuAgentCommand           |  x  |     |     |
virDrvDomainOpenConsole                |  x  |  x  |     |
virDrvDomainOpenGraphics               |  x  |     |     |
virDrvDomainInjectNMI                  |  x  |     |     |
virDrvDomainMigrateBegin3              |  x  |     |     |
virDrvDomainMigratePrepare3            |  x  |     |     |
virDrvDomainMigratePrepareTunnel3      |  x  |     |     |
virDrvDomainMigratePerform3            |  x  |     |     |
virDrvDomainMigrateFinish3             |  x  |     |     |
virDrvDomainMigrateConfirm3            |  x  |     |     |
virDrvDomainSendKey                    |  x  |     |     |
virDrvDomainBlockJobAbort              |  x  |     |     |
virDrvDomainGetBlockJobInfo            |  x  |     |     |
virDrvDomainBlockJobSetSpeed           |  x  |     |     |
virDrvDomainBlockPull                  |  x  |     |     |
virDrvDomainBlockRebase                |  x  |     |     |
virDrvDomainBlockCommit                |  x  |     |     |
virDrvSetKeepAlive                     |     |     |     |
virDrvConnectIsAlive                   |  x  |     |     |
virDrvNodeSuspendForDuration           |  x  |  x  |     |
virDrvDomainSetBlockIoTune             |  x  |     |     |
virDrvDomainGetBlockIoTune             |  x  |     |     |
virDrvDomainGetCPUStats                |  x  |     |     |
virDrvDomainGetDiskErrors              |  x  |     |     |
virDrvDomainSetMetadata                |  x  |     |     |
virDrvDomainGetMetadata                |  x  |     |     |
virDrvNodeGetMemoryParameters          |  x  |  x  |     |
virDrvNodeSetMemoryParameters          |  x  |  x  |     |


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 18:19:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 18:19:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR5YI-0008S3-Kv; Wed, 24 Oct 2012 18:19:38 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR5YG-0008Rw-Mp
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 18:19:36 +0000
Received: from [193.109.254.147:16122] by server-12.bemta-14.messagelabs.com
	id C9/BA-00510-73138805; Wed, 24 Oct 2012 18:19:35 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-13.tower-27.messagelabs.com!1351102774!11169342!1
X-Originating-IP: [149.20.54.216]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5164 invoked from network); 24 Oct 2012 18:19:35 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-13.tower-27.messagelabs.com with SMTP;
	24 Oct 2012 18:19:35 -0000
Received: from localhost (cpe-66-108-116-58.nyc.res.rr.com [66.108.116.58])
	by shards.monkeyblade.net (Postfix) with ESMTPSA id B10C758107A;
	Wed, 24 Oct 2012 11:19:35 -0700 (PDT)
Date: Wed, 24 Oct 2012 14:19:32 -0400 (EDT)
Message-Id: <20121024.141932.1360126659291040918.davem@davemloft.net>
To: ian.campbell@citrix.com
From: David Miller 
In-Reply-To: <1351078936-14159-1-git-send-email-ian.campbell@citrix.com>
References: <1351078936-14159-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: Mew version 6.5 on Emacs 24.1 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Cc: netdev@vger.kernel.org, edumazet@google.com, xen-devel@lists.xen.org,
	konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH] net: allow configuration of the size of
 page in __netdev_alloc_frag
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


I'm not applying this.

Fix your drivers and the infrastructure they use, don't paper
around it.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 18:19:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 18:19:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR5YI-0008S3-Kv; Wed, 24 Oct 2012 18:19:38 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR5YG-0008Rw-Mp
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 18:19:36 +0000
Received: from [193.109.254.147:16122] by server-12.bemta-14.messagelabs.com
	id C9/BA-00510-73138805; Wed, 24 Oct 2012 18:19:35 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-13.tower-27.messagelabs.com!1351102774!11169342!1
X-Originating-IP: [149.20.54.216]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5164 invoked from network); 24 Oct 2012 18:19:35 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(149.20.54.216) by server-13.tower-27.messagelabs.com with SMTP;
	24 Oct 2012 18:19:35 -0000
Received: from localhost (cpe-66-108-116-58.nyc.res.rr.com [66.108.116.58])
	by shards.monkeyblade.net (Postfix) with ESMTPSA id B10C758107A;
	Wed, 24 Oct 2012 11:19:35 -0700 (PDT)
Date: Wed, 24 Oct 2012 14:19:32 -0400 (EDT)
Message-Id: <20121024.141932.1360126659291040918.davem@davemloft.net>
To: ian.campbell@citrix.com
From: David Miller 
In-Reply-To: <1351078936-14159-1-git-send-email-ian.campbell@citrix.com>
References: <1351078936-14159-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: Mew version 6.5 on Emacs 24.1 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Cc: netdev@vger.kernel.org, edumazet@google.com, xen-devel@lists.xen.org,
	konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH] net: allow configuration of the size of
 page in __netdev_alloc_frag
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


I'm not applying this.

Fix your drivers and the infrastructure they use, don't paper
around it.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 18:56:56 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 18:56:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR682-0000uq-2X; Wed, 24 Oct 2012 18:56:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR680-0000ul-HC
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 18:56:32 +0000
Received: from [85.158.138.51:20959] by server-15.bemta-3.messagelabs.com id
	20/AB-09445-FD938805; Wed, 24 Oct 2012 18:56:31 +0000
X-Env-Sender: peter.maloney@brockmann-consult.de
X-Msg-Ref: server-11.tower-174.messagelabs.com!1351104990!35641900!1
X-Originating-IP: [212.227.126.187]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xODcgPT4gODE2MTc=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xODcgPT4gODE2MTc=\n,BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6771 invoked from network); 24 Oct 2012 18:56:31 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.126.187)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 18:56:31 -0000
Received: from [192.168.179.201] (hmbg-5f76797c.pool.mediaWays.net
	[95.118.121.124])
	by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis)
	id 0MEaJJ-1TcJL51mhN-00GEXk; Wed, 24 Oct 2012 20:56:30 +0200
Message-ID: <508839DD.6060000@brockmann-consult.de>
Date: Wed, 24 Oct 2012 20:56:29 +0200
From: Peter Maloney 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120825 Thunderbird/15.0
MIME-Version: 1.0
To: xen-devel@lists.xen.org
X-Provags-ID: V02:K0:BoXwzZKe7zNoPwL7EPdm04yPi7esYiWSYJOR+WS1v6U
	enzKiBhNSHZrm6WDIIwyX9s2CJ/m680tBsRFFvozfUZpCP0w3o
	Y41AgZlsmdzNIFyVUYKwoAACECo1R17ZYUjTjf9LpNbZJQueav
	9g1wtOP9BQ21YZ1sBEVyB7NgrY2I3X+7XpnavHlzzWsGU1QUwB
	faQo0h453VXq8QDXstb/uebTtoj/GLa1bhMnnYEY/2S4bdCOhW
	jbzFa1I7LrbYeVPAAiyUIzGPMvzwYTxDAKNHxe9Hx5Bd+oq2ku
	sFSbAc6jSSuZHU1XKpve09E739e1HTDpUn21TxNYDYfKepVKib
	LI3vAIxzRMR+Eoob/vT6dh1OFgYUdGSgu7dO09yPXUc950MbV/
	8en9sXunELl4A==
Subject: [Xen-devel] bug with pvonhvm, maybe triggered by rsync
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Using openSUSE 12.1
kernel vanilla 3.7rc2 built from source, with xen front drivers and
other xen stuff (same kernel as dom0)
using fglrx

Possibly triggered the bug by sending some git repositories from dom0 to
the domu using "rsync -avHP ..."

Here's a pastebin of the same you see below: http://pastebin.com/CtjxWDsV

[  752.577291] ------------[ cut here ]------------
[  752.577298] WARNING: at net/core/skbuff.c:3442
skb_try_coalesce+0x383/0x3c0()
[  752.577300] Hardware name: HVM domU
[  752.577301] Modules linked in: xt_tcpudp xt_pkttype xt_LOG xt_limit
ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_raw ipt_REJECT
iptable_raw iptable_filter ip6table_mangle nf_conntrack_netbios_ns
nf_conntrack_broadcast nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables
xt_conntrack nf_conntrack ip6table_filter ip6_tables x_tables microcode
mperf dm_mod snd_hda_codec_hdmi snd_hda_intel crc32c_intel snd_hda_codec
ghash_clmulni_intel snd_ens1370 aesni_intel snd_hwdep gameport
ablk_helper cryptd snd_rawmidi snd_seq_device snd_pcm lrw aes_x86_64 xts
joydev gf128mul snd_timer ata_generic snd hid_generic ppdev ata_piix
parport_pc soundcore parport snd_page_alloc i2c_piix4 button floppy
pcspkr autofs4 usbhid ohci_hcd uhci_hcd ehci_hcd usbcore processor
thermal_sys usb_common [last unloaded: microcode]
[  752.577340] Pid: 3045, comm: sshd Tainted: G        W   
3.7.0-rc2-1-default #5
[  752.577341] Call Trace:
[  752.577343]    [] warn_slowpath_common+0x7a/0xb0
[  752.577349]  [] warn_slowpath_null+0x15/0x20
[  752.577351]  [] skb_try_coalesce+0x383/0x3c0
[  752.577354]  [] tcp_try_coalesce.part.50+0x2f/0x90
[  752.577356]  [] tcp_queue_rcv+0x104/0x120
[  752.577358]  [] tcp_rcv_established+0x408/0x780
[  752.577361]  [] tcp_v4_do_rcv+0x141/0x200
[  752.577362]  [] tcp_v4_rcv+0x559/0x820
[  752.577364]  [] ? nf_hook_slow+0x75/0x150
[  752.577366]  [] ? ip_rcv_finish+0x360/0x360
[  752.577368]  [] ip_local_deliver_finish+0xd6/0x270
[  752.577369]  [] ip_local_deliver+0x45/0x80
[  752.577371]  [] ip_rcv_finish+0x119/0x360
[  752.577373]  [] ip_rcv+0x20d/0x2f0
[  752.577375]  [] __netif_receive_skb+0x5e2/0x750
[  752.577376]  [] netif_receive_skb+0x1e/0x80
[  752.577379]  [] handle_incoming_queue+0xdb/0xe0
[  752.577381]  [] xennet_poll+0x279/0x420
[  752.577382]  [] ? xennet_tx_buf_gc+0x162/0x190
[  752.577384]  [] net_rx_action+0x139/0x250
[  752.577386]  [] __do_softirq+0xb8/0x240
[  752.577389]  [] call_softirq+0x1c/0x30
[  752.577391]  [] do_softirq+0x65/0xa0
[  752.577392]  [] irq_exit+0x8e/0xb0
[  752.577395]  [] xen_evtchn_do_upcall+0x2f/0x40
[  752.577397]  [] xen_hvm_callback_vector+0x6d/0x80
[  752.577398]    [] ? system_call_fastpath+0x16/0x1b
[  752.577400] ---[ end trace 4dbd6f8d2234fde1 ]---


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 18:56:56 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 18:56:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR682-0000uq-2X; Wed, 24 Oct 2012 18:56:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR680-0000ul-HC
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 18:56:32 +0000
Received: from [85.158.138.51:20959] by server-15.bemta-3.messagelabs.com id
	20/AB-09445-FD938805; Wed, 24 Oct 2012 18:56:31 +0000
X-Env-Sender: peter.maloney@brockmann-consult.de
X-Msg-Ref: server-11.tower-174.messagelabs.com!1351104990!35641900!1
X-Originating-IP: [212.227.126.187]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xODcgPT4gODE2MTc=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xODcgPT4gODE2MTc=\n,BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6771 invoked from network); 24 Oct 2012 18:56:31 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.126.187)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 18:56:31 -0000
Received: from [192.168.179.201] (hmbg-5f76797c.pool.mediaWays.net
	[95.118.121.124])
	by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis)
	id 0MEaJJ-1TcJL51mhN-00GEXk; Wed, 24 Oct 2012 20:56:30 +0200
Message-ID: <508839DD.6060000@brockmann-consult.de>
Date: Wed, 24 Oct 2012 20:56:29 +0200
From: Peter Maloney 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120825 Thunderbird/15.0
MIME-Version: 1.0
To: xen-devel@lists.xen.org
X-Provags-ID: V02:K0:BoXwzZKe7zNoPwL7EPdm04yPi7esYiWSYJOR+WS1v6U
	enzKiBhNSHZrm6WDIIwyX9s2CJ/m680tBsRFFvozfUZpCP0w3o
	Y41AgZlsmdzNIFyVUYKwoAACECo1R17ZYUjTjf9LpNbZJQueav
	9g1wtOP9BQ21YZ1sBEVyB7NgrY2I3X+7XpnavHlzzWsGU1QUwB
	faQo0h453VXq8QDXstb/uebTtoj/GLa1bhMnnYEY/2S4bdCOhW
	jbzFa1I7LrbYeVPAAiyUIzGPMvzwYTxDAKNHxe9Hx5Bd+oq2ku
	sFSbAc6jSSuZHU1XKpve09E739e1HTDpUn21TxNYDYfKepVKib
	LI3vAIxzRMR+Eoob/vT6dh1OFgYUdGSgu7dO09yPXUc950MbV/
	8en9sXunELl4A==
Subject: [Xen-devel] bug with pvonhvm, maybe triggered by rsync
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Using openSUSE 12.1
kernel vanilla 3.7rc2 built from source, with xen front drivers and
other xen stuff (same kernel as dom0)
using fglrx

Possibly triggered the bug by sending some git repositories from dom0 to
the domu using "rsync -avHP ..."

Here's a pastebin of the same you see below: http://pastebin.com/CtjxWDsV

[  752.577291] ------------[ cut here ]------------
[  752.577298] WARNING: at net/core/skbuff.c:3442
skb_try_coalesce+0x383/0x3c0()
[  752.577300] Hardware name: HVM domU
[  752.577301] Modules linked in: xt_tcpudp xt_pkttype xt_LOG xt_limit
ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_raw ipt_REJECT
iptable_raw iptable_filter ip6table_mangle nf_conntrack_netbios_ns
nf_conntrack_broadcast nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables
xt_conntrack nf_conntrack ip6table_filter ip6_tables x_tables microcode
mperf dm_mod snd_hda_codec_hdmi snd_hda_intel crc32c_intel snd_hda_codec
ghash_clmulni_intel snd_ens1370 aesni_intel snd_hwdep gameport
ablk_helper cryptd snd_rawmidi snd_seq_device snd_pcm lrw aes_x86_64 xts
joydev gf128mul snd_timer ata_generic snd hid_generic ppdev ata_piix
parport_pc soundcore parport snd_page_alloc i2c_piix4 button floppy
pcspkr autofs4 usbhid ohci_hcd uhci_hcd ehci_hcd usbcore processor
thermal_sys usb_common [last unloaded: microcode]
[  752.577340] Pid: 3045, comm: sshd Tainted: G        W   
3.7.0-rc2-1-default #5
[  752.577341] Call Trace:
[  752.577343]    [] warn_slowpath_common+0x7a/0xb0
[  752.577349]  [] warn_slowpath_null+0x15/0x20
[  752.577351]  [] skb_try_coalesce+0x383/0x3c0
[  752.577354]  [] tcp_try_coalesce.part.50+0x2f/0x90
[  752.577356]  [] tcp_queue_rcv+0x104/0x120
[  752.577358]  [] tcp_rcv_established+0x408/0x780
[  752.577361]  [] tcp_v4_do_rcv+0x141/0x200
[  752.577362]  [] tcp_v4_rcv+0x559/0x820
[  752.577364]  [] ? nf_hook_slow+0x75/0x150
[  752.577366]  [] ? ip_rcv_finish+0x360/0x360
[  752.577368]  [] ip_local_deliver_finish+0xd6/0x270
[  752.577369]  [] ip_local_deliver+0x45/0x80
[  752.577371]  [] ip_rcv_finish+0x119/0x360
[  752.577373]  [] ip_rcv+0x20d/0x2f0
[  752.577375]  [] __netif_receive_skb+0x5e2/0x750
[  752.577376]  [] netif_receive_skb+0x1e/0x80
[  752.577379]  [] handle_incoming_queue+0xdb/0xe0
[  752.577381]  [] xennet_poll+0x279/0x420
[  752.577382]  [] ? xennet_tx_buf_gc+0x162/0x190
[  752.577384]  [] net_rx_action+0x139/0x250
[  752.577386]  [] __do_softirq+0xb8/0x240
[  752.577389]  [] call_softirq+0x1c/0x30
[  752.577391]  [] do_softirq+0x65/0xa0
[  752.577392]  [] irq_exit+0x8e/0xb0
[  752.577395]  [] xen_evtchn_do_upcall+0x2f/0x40
[  752.577397]  [] xen_hvm_callback_vector+0x6d/0x80
[  752.577398]    [] ? system_call_fastpath+0x16/0x1b
[  752.577400] ---[ end trace 4dbd6f8d2234fde1 ]---


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 19:06:06 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 19:06:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR6Gu-00017m-3X; Wed, 24 Oct 2012 19:05:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR6Gs-00017e-SS
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 19:05:43 +0000
Received: from [85.158.139.211:12479] by server-1.bemta-5.messagelabs.com id
	23/7C-21640-60C38805; Wed, 24 Oct 2012 19:05:42 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1351105539!19617656!1
X-Originating-IP: [209.85.210.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9157 invoked from network); 24 Oct 2012 19:05:40 -0000
Received: from mail-da0-f45.google.com (HELO mail-da0-f45.google.com)
	(209.85.210.45)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 19:05:40 -0000
Received: by mail-da0-f45.google.com with SMTP id n15so405446dad.32
	for ; Wed, 24 Oct 2012 12:05:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type;
	bh=DghMC3uTD0xfZph05+qijX14uaBz8C1FgBAK4AhLRZY=;
	b=HY4T1ZCVR+4s3uKEIkkUjuLARgTJzawNfxSX1iR0Yv6nefDYO5pjWmrn7s+cSbpK2b
	5i+RO5W9yU87s0VlwXdj5+qsWNyKtH+XP0tPMUk9y1LgIjwNarzn6CtKaelkDtskxhMm
	8vluGXED8Gja4dfRWMLKTTuzNxWEcd91ePybm9mgc5vkDlp4b9O3ODYwWTvrj06pq/SK
	fRKQQb5KlfF6Q2mdtrNLeanRvXZTc3yJzv/cJmzlI3wBXPwzrsSVviwUsh/8DTbZKEsm
	JI45Yv/gHM9fXitiHxdZYoKe6u7r+gz06MIm8szpjky/lnzLtog6fR20ne+t6xiitLfB
	sfhQ==
Received: by 10.68.203.164 with SMTP id kr4mr52660539pbc.46.1351105538561;
	Wed, 24 Oct 2012 12:05:38 -0700 (PDT)
Received: from [10.128.0.122] (S0106001c25a066a0.vc.shawcable.net.
	[24.85.255.130])
	by mx.google.com with ESMTPS id v9sm9905619paz.6.2012.10.24.12.05.35
	(version=SSLv3 cipher=OTHER); Wed, 24 Oct 2012 12:05:36 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Wed, 24 Oct 2012 12:05:32 -0700
From: Keir Fraser 
To: Olaf Hering ,
	
Message-ID: 
Thread-Topic: [Xen-devel] [PATCH] tools/hvmloader: move shared_info to
	reserved memory area
Thread-Index: Ac2yGooifZF2FxMPpUWZ0XQCDj/UjA==
In-Reply-To: <6a0c73ae9ce5cca72f78.1351101425@probook.site>
Mime-version: 1.0
Content-type: multipart/mixed;
	boundary="B_3433925136_72471762"
Subject: Re: [Xen-devel] [PATCH] tools/hvmloader: move shared_info to
 reserved memory area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3433925136_72471762
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

On 24/10/2012 10:57, "Olaf Hering"  wrote:

> # HG changeset patch
> # User Olaf Hering 
> # Date 1351101387 -7200
> # Node ID 6a0c73ae9ce5cca72f788c0e0f8fd6872010d83e
> # Parent  22e08c9ac770db07c3c3e7c844aa7153050939f3
> tools/hvmloader: move shared_info to reserved memory area
> 
> Reserve a range of 1MB for the HVM shared info page at 0xFE700000. This
> area is already marked as reserved in the E820 map. The purpose of this
> change is to provide Linux PVonHVM guests with a fixed page outside of
> ordinary RAM. If the shared page is located in RAM it would be
> overwritten during a kexec boot.

I don't think hvmloader actually needs to map shared-info to the new
location, it justs needs to guarantee that this location is unused, and
document it so that it never *becomes* used in future.

Which can be as simple as the attached patch (in fact all the changes apart
from introducing GUEST_RESERVED_{START,END} are really cleaning up and
bug-fixing the out-of-space checks in the mem_hole_alloc/mem_alloc
functions).

This then just requires that the guest maps shared-info to FE700000 itself.
Should be quite easy. :)

 -- Keir

> Signed-off-by: Olaf Hering 
> 
> diff -r 22e08c9ac770 -r 6a0c73ae9ce5 tools/firmware/hvmloader/config.h
> --- a/tools/firmware/hvmloader/config.h
> +++ b/tools/firmware/hvmloader/config.h
> @@ -68,6 +68,8 @@ extern unsigned long pci_mem_start, pci_
>  /* NB. ACPI_INFO_PHYSICAL_ADDRESS *MUST* match definition in acpi/dsdt.asl!
> */
>  #define ACPI_INFO_PHYSICAL_ADDRESS    0xFC000000
>  #define RESERVED_MEMORY_DYNAMIC       0xFC001000
> +#define HVM_SHARED_INFO_AREA          0xFE700000
> +#define HVM_SHARED_INFO_SIZE          0x00100000
>  
>  extern unsigned long scratch_start;
>  
> diff -r 22e08c9ac770 -r 6a0c73ae9ce5 tools/firmware/hvmloader/util.c
> --- a/tools/firmware/hvmloader/util.c
> +++ b/tools/firmware/hvmloader/util.c
> @@ -433,11 +433,18 @@ void *mem_alloc(uint32_t size, uint32_t
>      if ( align < 16 )
>          align = 16;
>  
> +retry:
>      s = (reserve + align) & ~(align - 1);
>      e = s + size - 1;
>  
>      BUG_ON((e < s) || (e >> PAGE_SHIFT) >= hvm_info->reserved_mem_pgstart);
>  
> +    /* Skip the shared info region */
> +    if (s <= HVM_SHARED_INFO_AREA && e >= HVM_SHARED_INFO_AREA) {
> +     reserve = HVM_SHARED_INFO_AREA + HVM_SHARED_INFO_SIZE - 1;
> +     goto retry;
> +    }
> +
>      while ( (reserve >> PAGE_SHIFT) != (e >> PAGE_SHIFT) )
>      {
>          reserve += PAGE_SIZE;
> @@ -765,7 +772,7 @@ struct shared_info *get_shared_info(void
>      xatp.domid = DOMID_SELF;
>      xatp.space = XENMAPSPACE_shared_info;
>      xatp.idx   = 0;
> -    xatp.gpfn  = mem_hole_alloc(1);
> +    xatp.gpfn  = HVM_SHARED_INFO_AREA >> PAGE_SHIFT;
>      shared_info = (struct shared_info *)(xatp.gpfn << PAGE_SHIFT);
>      if ( hypercall_memory_op(XENMEM_add_to_physmap, &xatp) != 0 )
>          BUG();
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


--B_3433925136_72471762
Content-type: application/octet-stream; name="00-hvmloader-reserved-mem"
Content-disposition: attachment;
	filename="00-hvmloader-reserved-mem"
Content-transfer-encoding: base64


ZGlmZiAtciAyMmUwOGM5YWM3NzAgdG9vbHMvZmlybXdhcmUvaHZtbG9hZGVyL2NvbmZpZy5o
Ci0tLSBhL3Rvb2xzL2Zpcm13YXJlL2h2bWxvYWRlci9jb25maWcuaAlXZWQgT2N0IDI0IDE3
OjUxOjQ4IDIwMTIgKzAyMDAKKysrIGIvdG9vbHMvZmlybXdhcmUvaHZtbG9hZGVyL2NvbmZp
Zy5oCVdlZCBPY3QgMjQgMDQ6MDE6MjQgMjAxMiAtMDcwMApAQCAtNjcsNyArNjcsMTUgQEAg
ZXh0ZXJuIHVuc2lnbmVkIGxvbmcgcGNpX21lbV9zdGFydCwgcGNpXwogI2RlZmluZSBSRVNF
UlZFRF9NRU1CQVNFICAgICAgICAgICAgICAweEZDMDAwMDAwCiAvKiBOQi4gQUNQSV9JTkZP
X1BIWVNJQ0FMX0FERFJFU1MgKk1VU1QqIG1hdGNoIGRlZmluaXRpb24gaW4gYWNwaS9kc2R0
LmFzbCEgKi8KICNkZWZpbmUgQUNQSV9JTkZPX1BIWVNJQ0FMX0FERFJFU1MgICAgMHhGQzAw
MDAwMAotI2RlZmluZSBSRVNFUlZFRF9NRU1PUllfRFlOQU1JQyAgICAgICAweEZDMDAxMDAw
CisjZGVmaW5lIFJFU0VSVkVEX01FTU9SWV9EWU5BTUlDX1NUQVJUIDB4RkMwMDEwMDAKKyNk
ZWZpbmUgUkVTRVJWRURfTUVNT1JZX0RZTkFNSUNfRU5EICAgMHhGRTAwMDAwMAorLyoKKyAq
IEdVRVNUX1JFU0VSVkVEOiBQaHlzaWNhbCBhZGRyZXNzIHNwYWNlIHJlc2VydmVkIGZvciBn
dWVzdCB1c2UuCisgKiBUaGlzIGlzIG5vdCBkeW5hbWljYWxseSBhZHZlcnRpc2VkIHRvIGd1
ZXN0cywgc28gdGhpcyByYW5nZSBtdXN0ICpuZXZlcioKKyAqIGJlIHVzZWQgZm9yIGFueSBw
dXJwb3NlIGJ5IHVzLCBpbiBmdXR1cmUuCisgKi8KKyNkZWZpbmUgR1VFU1RfUkVTRVJWRURf
U1RBUlQgICAgICAgICAgMHhGRTcwMDAwMAorI2RlZmluZSBHVUVTVF9SRVNFUlZFRF9FTkQg
ICAgICAgICAgICAweEZFODAwMDAwCiAKIGV4dGVybiB1bnNpZ25lZCBsb25nIHNjcmF0Y2hf
c3RhcnQ7CiAKZGlmZiAtciAyMmUwOGM5YWM3NzAgdG9vbHMvZmlybXdhcmUvaHZtbG9hZGVy
L3V0aWwuYwotLS0gYS90b29scy9maXJtd2FyZS9odm1sb2FkZXIvdXRpbC5jCVdlZCBPY3Qg
MjQgMTc6NTE6NDggMjAxMiArMDIwMAorKysgYi90b29scy9maXJtd2FyZS9odm1sb2FkZXIv
dXRpbC5jCVdlZCBPY3QgMjQgMDQ6MDE6MjQgMjAxMiAtMDcwMApAQCAtNDE2LDEzICs0MTYs
MTQgQEAgdm9pZCBtZW1faG9sZV9wb3B1bGF0ZV9yYW0oeGVuX3Bmbl90IG1mbgogICAgIH0K
IH0KIAotc3RhdGljIHVpbnQzMl90IHJlc2VydmUgPSBSRVNFUlZFRF9NRU1PUllfRFlOQU1J
QyAtIDE7CitzdGF0aWMgdWludDMyX3QgYWxsb2NfdXAgPSBSRVNFUlZFRF9NRU1PUllfRFlO
QU1JQ19TVEFSVCAtIDE7CitzdGF0aWMgdWludDMyX3QgYWxsb2NfZG93biA9IFJFU0VSVkVE
X01FTU9SWV9EWU5BTUlDX0VORDsKIAogeGVuX3Bmbl90IG1lbV9ob2xlX2FsbG9jKHVpbnQz
Ml90IG5yX21mbnMpCiB7Ci0gICAgaHZtX2luZm8tPnJlc2VydmVkX21lbV9wZ3N0YXJ0IC09
IG5yX21mbnM7Ci0gICAgQlVHX09OKGh2bV9pbmZvLT5yZXNlcnZlZF9tZW1fcGdzdGFydCA8
PSAocmVzZXJ2ZSA+PiBQQUdFX1NISUZUKSk7Ci0gICAgcmV0dXJuIGh2bV9pbmZvLT5yZXNl
cnZlZF9tZW1fcGdzdGFydDsKKyAgICBhbGxvY19kb3duIC09IG5yX21mbnMgPDwgUEFHRV9T
SElGVDsKKyAgICBCVUdfT04oYWxsb2NfdXAgPj0gYWxsb2NfZG93bik7CisgICAgcmV0dXJu
IGFsbG9jX2Rvd24gPj4gUEFHRV9TSElGVDsKIH0KIAogdm9pZCAqbWVtX2FsbG9jKHVpbnQz
Ml90IHNpemUsIHVpbnQzMl90IGFsaWduKQpAQCAtNDMzLDE4ICs0MzQsMTggQEAgdm9pZCAq
bWVtX2FsbG9jKHVpbnQzMl90IHNpemUsIHVpbnQzMl90IAogICAgIGlmICggYWxpZ24gPCAx
NiApCiAgICAgICAgIGFsaWduID0gMTY7CiAKLSAgICBzID0gKHJlc2VydmUgKyBhbGlnbikg
JiB+KGFsaWduIC0gMSk7CisgICAgcyA9IChhbGxvY191cCArIGFsaWduKSAmIH4oYWxpZ24g
LSAxKTsKICAgICBlID0gcyArIHNpemUgLSAxOwogCi0gICAgQlVHX09OKChlIDwgcykgfHwg
KGUgPj4gUEFHRV9TSElGVCkgPj0gaHZtX2luZm8tPnJlc2VydmVkX21lbV9wZ3N0YXJ0KTsK
KyAgICBCVUdfT04oKGUgPCBzKSB8fCAoZSA+PSBhbGxvY19kb3duKSk7CiAKLSAgICB3aGls
ZSAoIChyZXNlcnZlID4+IFBBR0VfU0hJRlQpICE9IChlID4+IFBBR0VfU0hJRlQpICkKKyAg
ICB3aGlsZSAoIChhbGxvY191cCA+PiBQQUdFX1NISUZUKSAhPSAoZSA+PiBQQUdFX1NISUZU
KSApCiAgICAgewotICAgICAgICByZXNlcnZlICs9IFBBR0VfU0laRTsKLSAgICAgICAgbWVt
X2hvbGVfcG9wdWxhdGVfcmFtKHJlc2VydmUgPj4gUEFHRV9TSElGVCwgMSk7CisgICAgICAg
IGFsbG9jX3VwICs9IFBBR0VfU0laRTsKKyAgICAgICAgbWVtX2hvbGVfcG9wdWxhdGVfcmFt
KGFsbG9jX3VwID4+IFBBR0VfU0hJRlQsIDEpOwogICAgIH0KIAotICAgIHJlc2VydmUgPSBl
OworICAgIGFsbG9jX3VwID0gZTsKIAogICAgIHJldHVybiAodm9pZCAqKSh1bnNpZ25lZCBs
b25nKXM7CiB9Cg==
--B_3433925136_72471762
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--B_3433925136_72471762--




From xen-devel-bounces@lists.xen.org Wed Oct 24 19:06:06 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 19:06:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR6Gu-00017m-3X; Wed, 24 Oct 2012 19:05:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR6Gs-00017e-SS
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 19:05:43 +0000
Received: from [85.158.139.211:12479] by server-1.bemta-5.messagelabs.com id
	23/7C-21640-60C38805; Wed, 24 Oct 2012 19:05:42 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1351105539!19617656!1
X-Originating-IP: [209.85.210.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9157 invoked from network); 24 Oct 2012 19:05:40 -0000
Received: from mail-da0-f45.google.com (HELO mail-da0-f45.google.com)
	(209.85.210.45)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 19:05:40 -0000
Received: by mail-da0-f45.google.com with SMTP id n15so405446dad.32
	for ; Wed, 24 Oct 2012 12:05:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type;
	bh=DghMC3uTD0xfZph05+qijX14uaBz8C1FgBAK4AhLRZY=;
	b=HY4T1ZCVR+4s3uKEIkkUjuLARgTJzawNfxSX1iR0Yv6nefDYO5pjWmrn7s+cSbpK2b
	5i+RO5W9yU87s0VlwXdj5+qsWNyKtH+XP0tPMUk9y1LgIjwNarzn6CtKaelkDtskxhMm
	8vluGXED8Gja4dfRWMLKTTuzNxWEcd91ePybm9mgc5vkDlp4b9O3ODYwWTvrj06pq/SK
	fRKQQb5KlfF6Q2mdtrNLeanRvXZTc3yJzv/cJmzlI3wBXPwzrsSVviwUsh/8DTbZKEsm
	JI45Yv/gHM9fXitiHxdZYoKe6u7r+gz06MIm8szpjky/lnzLtog6fR20ne+t6xiitLfB
	sfhQ==
Received: by 10.68.203.164 with SMTP id kr4mr52660539pbc.46.1351105538561;
	Wed, 24 Oct 2012 12:05:38 -0700 (PDT)
Received: from [10.128.0.122] (S0106001c25a066a0.vc.shawcable.net.
	[24.85.255.130])
	by mx.google.com with ESMTPS id v9sm9905619paz.6.2012.10.24.12.05.35
	(version=SSLv3 cipher=OTHER); Wed, 24 Oct 2012 12:05:36 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Wed, 24 Oct 2012 12:05:32 -0700
From: Keir Fraser 
To: Olaf Hering ,
	
Message-ID: 
Thread-Topic: [Xen-devel] [PATCH] tools/hvmloader: move shared_info to
	reserved memory area
Thread-Index: Ac2yGooifZF2FxMPpUWZ0XQCDj/UjA==
In-Reply-To: <6a0c73ae9ce5cca72f78.1351101425@probook.site>
Mime-version: 1.0
Content-type: multipart/mixed;
	boundary="B_3433925136_72471762"
Subject: Re: [Xen-devel] [PATCH] tools/hvmloader: move shared_info to
 reserved memory area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3433925136_72471762
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

On 24/10/2012 10:57, "Olaf Hering"  wrote:

> # HG changeset patch
> # User Olaf Hering 
> # Date 1351101387 -7200
> # Node ID 6a0c73ae9ce5cca72f788c0e0f8fd6872010d83e
> # Parent  22e08c9ac770db07c3c3e7c844aa7153050939f3
> tools/hvmloader: move shared_info to reserved memory area
> 
> Reserve a range of 1MB for the HVM shared info page at 0xFE700000. This
> area is already marked as reserved in the E820 map. The purpose of this
> change is to provide Linux PVonHVM guests with a fixed page outside of
> ordinary RAM. If the shared page is located in RAM it would be
> overwritten during a kexec boot.

I don't think hvmloader actually needs to map shared-info to the new
location, it justs needs to guarantee that this location is unused, and
document it so that it never *becomes* used in future.

Which can be as simple as the attached patch (in fact all the changes apart
from introducing GUEST_RESERVED_{START,END} are really cleaning up and
bug-fixing the out-of-space checks in the mem_hole_alloc/mem_alloc
functions).

This then just requires that the guest maps shared-info to FE700000 itself.
Should be quite easy. :)

 -- Keir

> Signed-off-by: Olaf Hering 
> 
> diff -r 22e08c9ac770 -r 6a0c73ae9ce5 tools/firmware/hvmloader/config.h
> --- a/tools/firmware/hvmloader/config.h
> +++ b/tools/firmware/hvmloader/config.h
> @@ -68,6 +68,8 @@ extern unsigned long pci_mem_start, pci_
>  /* NB. ACPI_INFO_PHYSICAL_ADDRESS *MUST* match definition in acpi/dsdt.asl!
> */
>  #define ACPI_INFO_PHYSICAL_ADDRESS    0xFC000000
>  #define RESERVED_MEMORY_DYNAMIC       0xFC001000
> +#define HVM_SHARED_INFO_AREA          0xFE700000
> +#define HVM_SHARED_INFO_SIZE          0x00100000
>  
>  extern unsigned long scratch_start;
>  
> diff -r 22e08c9ac770 -r 6a0c73ae9ce5 tools/firmware/hvmloader/util.c
> --- a/tools/firmware/hvmloader/util.c
> +++ b/tools/firmware/hvmloader/util.c
> @@ -433,11 +433,18 @@ void *mem_alloc(uint32_t size, uint32_t
>      if ( align < 16 )
>          align = 16;
>  
> +retry:
>      s = (reserve + align) & ~(align - 1);
>      e = s + size - 1;
>  
>      BUG_ON((e < s) || (e >> PAGE_SHIFT) >= hvm_info->reserved_mem_pgstart);
>  
> +    /* Skip the shared info region */
> +    if (s <= HVM_SHARED_INFO_AREA && e >= HVM_SHARED_INFO_AREA) {
> +     reserve = HVM_SHARED_INFO_AREA + HVM_SHARED_INFO_SIZE - 1;
> +     goto retry;
> +    }
> +
>      while ( (reserve >> PAGE_SHIFT) != (e >> PAGE_SHIFT) )
>      {
>          reserve += PAGE_SIZE;
> @@ -765,7 +772,7 @@ struct shared_info *get_shared_info(void
>      xatp.domid = DOMID_SELF;
>      xatp.space = XENMAPSPACE_shared_info;
>      xatp.idx   = 0;
> -    xatp.gpfn  = mem_hole_alloc(1);
> +    xatp.gpfn  = HVM_SHARED_INFO_AREA >> PAGE_SHIFT;
>      shared_info = (struct shared_info *)(xatp.gpfn << PAGE_SHIFT);
>      if ( hypercall_memory_op(XENMEM_add_to_physmap, &xatp) != 0 )
>          BUG();
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


--B_3433925136_72471762
Content-type: application/octet-stream; name="00-hvmloader-reserved-mem"
Content-disposition: attachment;
	filename="00-hvmloader-reserved-mem"
Content-transfer-encoding: base64


ZGlmZiAtciAyMmUwOGM5YWM3NzAgdG9vbHMvZmlybXdhcmUvaHZtbG9hZGVyL2NvbmZpZy5o
Ci0tLSBhL3Rvb2xzL2Zpcm13YXJlL2h2bWxvYWRlci9jb25maWcuaAlXZWQgT2N0IDI0IDE3
OjUxOjQ4IDIwMTIgKzAyMDAKKysrIGIvdG9vbHMvZmlybXdhcmUvaHZtbG9hZGVyL2NvbmZp
Zy5oCVdlZCBPY3QgMjQgMDQ6MDE6MjQgMjAxMiAtMDcwMApAQCAtNjcsNyArNjcsMTUgQEAg
ZXh0ZXJuIHVuc2lnbmVkIGxvbmcgcGNpX21lbV9zdGFydCwgcGNpXwogI2RlZmluZSBSRVNF
UlZFRF9NRU1CQVNFICAgICAgICAgICAgICAweEZDMDAwMDAwCiAvKiBOQi4gQUNQSV9JTkZP
X1BIWVNJQ0FMX0FERFJFU1MgKk1VU1QqIG1hdGNoIGRlZmluaXRpb24gaW4gYWNwaS9kc2R0
LmFzbCEgKi8KICNkZWZpbmUgQUNQSV9JTkZPX1BIWVNJQ0FMX0FERFJFU1MgICAgMHhGQzAw
MDAwMAotI2RlZmluZSBSRVNFUlZFRF9NRU1PUllfRFlOQU1JQyAgICAgICAweEZDMDAxMDAw
CisjZGVmaW5lIFJFU0VSVkVEX01FTU9SWV9EWU5BTUlDX1NUQVJUIDB4RkMwMDEwMDAKKyNk
ZWZpbmUgUkVTRVJWRURfTUVNT1JZX0RZTkFNSUNfRU5EICAgMHhGRTAwMDAwMAorLyoKKyAq
IEdVRVNUX1JFU0VSVkVEOiBQaHlzaWNhbCBhZGRyZXNzIHNwYWNlIHJlc2VydmVkIGZvciBn
dWVzdCB1c2UuCisgKiBUaGlzIGlzIG5vdCBkeW5hbWljYWxseSBhZHZlcnRpc2VkIHRvIGd1
ZXN0cywgc28gdGhpcyByYW5nZSBtdXN0ICpuZXZlcioKKyAqIGJlIHVzZWQgZm9yIGFueSBw
dXJwb3NlIGJ5IHVzLCBpbiBmdXR1cmUuCisgKi8KKyNkZWZpbmUgR1VFU1RfUkVTRVJWRURf
U1RBUlQgICAgICAgICAgMHhGRTcwMDAwMAorI2RlZmluZSBHVUVTVF9SRVNFUlZFRF9FTkQg
ICAgICAgICAgICAweEZFODAwMDAwCiAKIGV4dGVybiB1bnNpZ25lZCBsb25nIHNjcmF0Y2hf
c3RhcnQ7CiAKZGlmZiAtciAyMmUwOGM5YWM3NzAgdG9vbHMvZmlybXdhcmUvaHZtbG9hZGVy
L3V0aWwuYwotLS0gYS90b29scy9maXJtd2FyZS9odm1sb2FkZXIvdXRpbC5jCVdlZCBPY3Qg
MjQgMTc6NTE6NDggMjAxMiArMDIwMAorKysgYi90b29scy9maXJtd2FyZS9odm1sb2FkZXIv
dXRpbC5jCVdlZCBPY3QgMjQgMDQ6MDE6MjQgMjAxMiAtMDcwMApAQCAtNDE2LDEzICs0MTYs
MTQgQEAgdm9pZCBtZW1faG9sZV9wb3B1bGF0ZV9yYW0oeGVuX3Bmbl90IG1mbgogICAgIH0K
IH0KIAotc3RhdGljIHVpbnQzMl90IHJlc2VydmUgPSBSRVNFUlZFRF9NRU1PUllfRFlOQU1J
QyAtIDE7CitzdGF0aWMgdWludDMyX3QgYWxsb2NfdXAgPSBSRVNFUlZFRF9NRU1PUllfRFlO
QU1JQ19TVEFSVCAtIDE7CitzdGF0aWMgdWludDMyX3QgYWxsb2NfZG93biA9IFJFU0VSVkVE
X01FTU9SWV9EWU5BTUlDX0VORDsKIAogeGVuX3Bmbl90IG1lbV9ob2xlX2FsbG9jKHVpbnQz
Ml90IG5yX21mbnMpCiB7Ci0gICAgaHZtX2luZm8tPnJlc2VydmVkX21lbV9wZ3N0YXJ0IC09
IG5yX21mbnM7Ci0gICAgQlVHX09OKGh2bV9pbmZvLT5yZXNlcnZlZF9tZW1fcGdzdGFydCA8
PSAocmVzZXJ2ZSA+PiBQQUdFX1NISUZUKSk7Ci0gICAgcmV0dXJuIGh2bV9pbmZvLT5yZXNl
cnZlZF9tZW1fcGdzdGFydDsKKyAgICBhbGxvY19kb3duIC09IG5yX21mbnMgPDwgUEFHRV9T
SElGVDsKKyAgICBCVUdfT04oYWxsb2NfdXAgPj0gYWxsb2NfZG93bik7CisgICAgcmV0dXJu
IGFsbG9jX2Rvd24gPj4gUEFHRV9TSElGVDsKIH0KIAogdm9pZCAqbWVtX2FsbG9jKHVpbnQz
Ml90IHNpemUsIHVpbnQzMl90IGFsaWduKQpAQCAtNDMzLDE4ICs0MzQsMTggQEAgdm9pZCAq
bWVtX2FsbG9jKHVpbnQzMl90IHNpemUsIHVpbnQzMl90IAogICAgIGlmICggYWxpZ24gPCAx
NiApCiAgICAgICAgIGFsaWduID0gMTY7CiAKLSAgICBzID0gKHJlc2VydmUgKyBhbGlnbikg
JiB+KGFsaWduIC0gMSk7CisgICAgcyA9IChhbGxvY191cCArIGFsaWduKSAmIH4oYWxpZ24g
LSAxKTsKICAgICBlID0gcyArIHNpemUgLSAxOwogCi0gICAgQlVHX09OKChlIDwgcykgfHwg
KGUgPj4gUEFHRV9TSElGVCkgPj0gaHZtX2luZm8tPnJlc2VydmVkX21lbV9wZ3N0YXJ0KTsK
KyAgICBCVUdfT04oKGUgPCBzKSB8fCAoZSA+PSBhbGxvY19kb3duKSk7CiAKLSAgICB3aGls
ZSAoIChyZXNlcnZlID4+IFBBR0VfU0hJRlQpICE9IChlID4+IFBBR0VfU0hJRlQpICkKKyAg
ICB3aGlsZSAoIChhbGxvY191cCA+PiBQQUdFX1NISUZUKSAhPSAoZSA+PiBQQUdFX1NISUZU
KSApCiAgICAgewotICAgICAgICByZXNlcnZlICs9IFBBR0VfU0laRTsKLSAgICAgICAgbWVt
X2hvbGVfcG9wdWxhdGVfcmFtKHJlc2VydmUgPj4gUEFHRV9TSElGVCwgMSk7CisgICAgICAg
IGFsbG9jX3VwICs9IFBBR0VfU0laRTsKKyAgICAgICAgbWVtX2hvbGVfcG9wdWxhdGVfcmFt
KGFsbG9jX3VwID4+IFBBR0VfU0hJRlQsIDEpOwogICAgIH0KIAotICAgIHJlc2VydmUgPSBl
OworICAgIGFsbG9jX3VwID0gZTsKIAogICAgIHJldHVybiAodm9pZCAqKSh1bnNpZ25lZCBs
b25nKXM7CiB9Cg==
--B_3433925136_72471762
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--B_3433925136_72471762--




From xen-devel-bounces@lists.xen.org Wed Oct 24 21:23:18 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 21:23:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR8PW-00021G-2m; Wed, 24 Oct 2012 21:22:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR8PU-00021B-BV
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 21:22:44 +0000
Received: from [85.158.138.51:39568] by server-7.bemta-3.messagelabs.com id
	3D/9A-06991-32C58805; Wed, 24 Oct 2012 21:22:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1351113762!35575488!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21095 invoked from network); 24 Oct 2012 21:22:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 21:22:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,642,1344211200"; d="scan'208";a="15370122"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 21:22:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 24 Oct 2012 22:22:42 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TR8PR-0006pU-Vb;
	Wed, 24 Oct 2012 21:22:41 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TR8PQ-0004Tf-21;
	Wed, 24 Oct 2012 22:22:41 +0100
To: 
Message-ID: 
From: xen.org 
Date: Wed, 24 Oct 2012 22:22:40 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14074: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14074 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14074/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 14072
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 14072
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 14072
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 14072

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  22e08c9ac770
baseline version:
 xen                  07cf00a917cd

------------------------------------------------------------
People who touched revisions under test:
  Dario Faggioli 
  George Dunlap 
  Jan Beulich 
  Keir Fraser 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=22e08c9ac770
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 22e08c9ac770
+ branch=xen-unstable
+ revision=22e08c9ac770
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 22e08c9ac770 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 21:23:18 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 21:23:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR8PW-00021G-2m; Wed, 24 Oct 2012 21:22:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR8PU-00021B-BV
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 21:22:44 +0000
Received: from [85.158.138.51:39568] by server-7.bemta-3.messagelabs.com id
	3D/9A-06991-32C58805; Wed, 24 Oct 2012 21:22:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1351113762!35575488!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU0NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21095 invoked from network); 24 Oct 2012 21:22:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Oct 2012 21:22:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,642,1344211200"; d="scan'208";a="15370122"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Oct 2012 21:22:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 24 Oct 2012 22:22:42 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TR8PR-0006pU-Vb;
	Wed, 24 Oct 2012 21:22:41 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TR8PQ-0004Tf-21;
	Wed, 24 Oct 2012 22:22:41 +0100
To: 
Message-ID: 
From: xen.org 
Date: Wed, 24 Oct 2012 22:22:40 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14074: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14074 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14074/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 14072
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 14072
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 14072
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 14072

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  22e08c9ac770
baseline version:
 xen                  07cf00a917cd

------------------------------------------------------------
People who touched revisions under test:
  Dario Faggioli 
  George Dunlap 
  Jan Beulich 
  Keir Fraser 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=22e08c9ac770
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 22e08c9ac770
+ branch=xen-unstable
+ revision=22e08c9ac770
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 22e08c9ac770 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 21:34:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 21:34:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR8a4-0002C4-AC; Wed, 24 Oct 2012 21:33:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR8a1-0002Bz-BF
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 21:33:38 +0000
Received: from [85.158.137.99:24206] by server-4.bemta-3.messagelabs.com id
	E1/0D-01405-0BE58805; Wed, 24 Oct 2012 21:33:36 +0000
X-Env-Sender: rdunlap@xenotime.net
X-Msg-Ref: server-16.tower-217.messagelabs.com!1351114411!22911396!1
X-Originating-IP: [69.89.22.20]
X-SpamReason: No, hits=3.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA2OS44OS4yMi4yMCA9PiA0MDQ4Nw==\n,sa_preprocessor: 
	QmFkIElQOiA2OS44OS4yMi4yMCA9PiA0MDQ4Nw==\n, UNIQUE_WORDS,
	UPPERCASE_75_100
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23101 invoked from network); 24 Oct 2012 21:33:32 -0000
Received: from oproxy8-pub.bluehost.com (HELO oproxy8-pub.bluehost.com)
	(69.89.22.20) by server-16.tower-217.messagelabs.com with SMTP;
	24 Oct 2012 21:33:32 -0000
Received: (qmail 25523 invoked by uid 0); 24 Oct 2012 21:33:31 -0000
Received: from unknown (HELO box742.bluehost.com) (66.147.244.242)
	by oproxy8.bluehost.com with SMTP; 24 Oct 2012 21:33:31 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenotime.net;
	s=default; 
	h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID;
	bh=QcBR+E/yPIP7SclfSHItTsDy/bkvP0IgtfotBdug0qA=; 
	b=ckO+oEd6Uo4MnEtc5qWAJ2OcBM/q45Kt7Kd6p45RSbeX71KYoeGtdJf+qRwykHMlV+XmpdZ04Ug6aR/2xViPQLna1SW3wX41yhaR4JFDvFd+ubZIAZbAMm3sbSAnq20F;
Received: from [50.53.38.135] (port=54779 helo=[192.168.1.7])
	by box742.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256)
	(Exim 4.76) (envelope-from )
	id 1TR8Zu-00073J-N4; Wed, 24 Oct 2012 15:33:31 -0600
Message-ID: <50885EA8.3050007@xenotime.net>
Date: Wed, 24 Oct 2012 14:33:28 -0700
From: Randy Dunlap 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.15) Gecko/20110323 Thunderbird/3.1.9
MIME-Version: 1.0
To: Stephen Rothwell 
References: <20121024151957.28a1626cd9a59c014e78c401@canb.auug.org.au>
In-Reply-To: <20121024151957.28a1626cd9a59c014e78c401@canb.auug.org.au>
Content-Type: multipart/mixed; boundary="------------080408090803040002050408"
X-Identified-User: {1807:box742.bluehost.com:xenotime:xenotime.net}
	{sentby:smtp auth 50.53.38.135 authed with
	rdunlap@xenotime.net}
Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk ,
	linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org,
	linux-next@vger.kernel.org
Subject: Re: [Xen-devel] linux-next: Tree for Oct 24 (xen)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--------------080408090803040002050408
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 10/23/2012 09:19 PM, Stephen Rothwell wrote:

> Hi all,
> 
> Changes since 201201023:
> 

on x86_64:

drivers/built-in.o: In function `dbgp_reset_prep':
(.text+0xb96b5): undefined reference to `xen_dbgp_reset_prep'
drivers/built-in.o: In function `dbgp_external_startup':
(.text+0xb9d95): undefined reference to `xen_dbgp_external_startup'


Full randconfig file is attached.


-- 
~Randy

--------------080408090803040002050408
Content-Type: text/plain;
 name="config-r8330"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="config-r8330"

#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 3.7.0-rc2 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_DEFAULT_IDLE=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_ARCH_HAS_CPU_AUTOPROBE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_HAVE_IRQ_WORK=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SWAP is not set
# CONFIG_SYSVIPC is not set
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
# CONFIG_FHANDLE is not set
CONFIG_AUDIT=y
# CONFIG_AUDITSYSCALL is not set
# CONFIG_AUDIT_LOGINUID_IMMUTABLE is not set
CONFIG_HAVE_GENERIC_HARDIRQS=y

#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_DEBUG=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_IRQ_TIME_ACCOUNTING is not set
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_TASKSTATS=y
# CONFIG_TASK_DELAY_ACCT is not set
# CONFIG_TASK_XACCT is not set

#
# RCU Subsystem
#
CONFIG_TINY_RCU=y
# CONFIG_PREEMPT_RCU is not set
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_CGROUPS=y
CONFIG_CGROUP_DEBUG=y
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CPUSETS=y
CONFIG_PROC_PID_CPUSET=y
CONFIG_CGROUP_CPUACCT=y
# CONFIG_RESOURCE_COUNTERS is not set
# CONFIG_CGROUP_PERF is not set
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
# CONFIG_CFS_BANDWIDTH is not set
CONFIG_RT_GROUP_SCHED=y
# CONFIG_BLK_CGROUP is not set
# CONFIG_CHECKPOINT_RESTORE is not set
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
# CONFIG_IPC_NS is not set
# CONFIG_PID_NS is not set
CONFIG_NET_NS=y
CONFIG_SCHED_AUTOGROUP=y
CONFIG_SYSFS_DEPRECATED=y
# CONFIG_SYSFS_DEPRECATED_V2 is not set
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
# CONFIG_EXPERT is not set
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_SYSCTL_EXCEPTION_TRACE=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_PCSPKR_PLATFORM=y
CONFIG_HAVE_PCSPKR_PLATFORM=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
# CONFIG_EMBEDDED is not set
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_USE_VMALLOC=y

#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
CONFIG_DEBUG_PERF_USE_VMALLOC=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_PCI_QUIRKS=y
CONFIG_SLUB_DEBUG=y
# CONFIG_COMPAT_BRK is not set
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_PROFILING is not set
CONFIG_HAVE_OPROFILE=y
CONFIG_OPROFILE_NMI_TIMER=y
CONFIG_KPROBES=y
# CONFIG_JUMP_LABEL is not set
CONFIG_OPTPROBES=y
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_KRETPROBES=y
CONFIG_HAVE_IOREMAP_PROT=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_OPTPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_HW_BREAKPOINT=y
CONFIG_HAVE_MIXED_BREAKPOINTS_REGS=y
CONFIG_HAVE_USER_RETURN_NOTIFIER=y
CONFIG_HAVE_PERF_EVENTS_NMI=y
CONFIG_HAVE_PERF_REGS=y
CONFIG_HAVE_PERF_USER_STACK_DUMP=y
CONFIG_HAVE_ARCH_JUMP_LABEL=y
CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG=y
CONFIG_HAVE_ALIGNED_STRUCT_PAGE=y
CONFIG_HAVE_CMPXCHG_LOCAL=y
CONFIG_HAVE_CMPXCHG_DOUBLE=y
CONFIG_GENERIC_KERNEL_THREAD=y
CONFIG_GENERIC_KERNEL_EXECVE=y
CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
CONFIG_SECCOMP_FILTER=y
CONFIG_HAVE_RCU_USER_QS=y
CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y
CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y
CONFIG_MODULES_USE_ELF_RELA=y

#
# GCOV-based kernel profiling
#
# CONFIG_GCOV_KERNEL is not set
# CONFIG_HAVE_GENERIC_DMA_COHERENT is not set
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
# CONFIG_MODULE_FORCE_LOAD is not set
# CONFIG_MODULE_UNLOAD is not set
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
# CONFIG_MODULE_SIG is not set
CONFIG_BLOCK=y
CONFIG_BLK_DEV_BSG=y
CONFIG_BLK_DEV_BSGLIB=y
CONFIG_BLK_DEV_INTEGRITY=y

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
CONFIG_MAC_PARTITION=y
# CONFIG_MSDOS_PARTITION is not set
# CONFIG_LDM_PARTITION is not set
CONFIG_SGI_PARTITION=y
CONFIG_ULTRIX_PARTITION=y
# CONFIG_SUN_PARTITION is not set
# CONFIG_KARMA_PARTITION is not set
# CONFIG_EFI_PARTITION is not set
# CONFIG_SYSV68_PARTITION is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_DEADLINE is not set
CONFIG_IOSCHED_CFQ=m
CONFIG_DEFAULT_NOOP=y
CONFIG_DEFAULT_IOSCHED="noop"
CONFIG_UNINLINE_SPIN_UNLOCK=y
CONFIG_FREEZER=y

#
# Processor type and features
#
CONFIG_ZONE_DMA=y
# CONFIG_SMP is not set
# CONFIG_X86_MPPARSE is not set
# CONFIG_X86_EXTENDED_PLATFORM is not set
CONFIG_X86_SUPPORTS_MEMORY_FAILURE=y
CONFIG_SCHED_OMIT_FRAME_POINTER=y
CONFIG_KVMTOOL_TEST_ENABLE=y
CONFIG_PARAVIRT_GUEST=y
CONFIG_PARAVIRT_TIME_ACCOUNTING=y
CONFIG_XEN=y
CONFIG_XEN_DOM0=y
CONFIG_XEN_PRIVILEGED_GUEST=y
CONFIG_XEN_PVHVM=y
CONFIG_XEN_MAX_DOMAIN_MEMORY=500
CONFIG_XEN_SAVE_RESTORE=y
CONFIG_XEN_DEBUG_FS=y
CONFIG_KVM_GUEST=y
CONFIG_PARAVIRT=y
CONFIG_PARAVIRT_CLOCK=y
# CONFIG_PARAVIRT_DEBUG is not set
CONFIG_NO_BOOTMEM=y
CONFIG_MEMTEST=y
# CONFIG_MK8 is not set
# CONFIG_MPSC is not set
# CONFIG_MCORE2 is not set
# CONFIG_MATOM is not set
CONFIG_GENERIC_CPU=y
CONFIG_X86_INTERNODE_CACHE_SHIFT=6
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_XADD=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_TSC=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=64
CONFIG_X86_DEBUGCTLMSR=y
CONFIG_CPU_SUP_INTEL=y
CONFIG_CPU_SUP_AMD=y
CONFIG_CPU_SUP_CENTAUR=y
CONFIG_HPET_TIMER=y
CONFIG_DMI=y
CONFIG_GART_IOMMU=y
CONFIG_CALGARY_IOMMU=y
CONFIG_CALGARY_IOMMU_ENABLED_BY_DEFAULT=y
CONFIG_SWIOTLB=y
CONFIG_IOMMU_HELPER=y
CONFIG_NR_CPUS=1
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_PREEMPT_COUNT=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
# CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS is not set
CONFIG_X86_MCE=y
CONFIG_X86_MCE_INTEL=y
CONFIG_X86_MCE_AMD=y
CONFIG_X86_MCE_THRESHOLD=y
# CONFIG_X86_MCE_INJECT is not set
CONFIG_X86_THERMAL_VECTOR=y
CONFIG_I8K=m
CONFIG_MICROCODE=m
# CONFIG_MICROCODE_INTEL is not set
CONFIG_MICROCODE_AMD=y
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_X86_MSR=m
# CONFIG_X86_CPUID is not set
CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
CONFIG_ARCH_DMA_ADDR_T_64BIT=y
CONFIG_DIRECT_GBPAGES=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_DEFAULT=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ILLEGAL_POINTER_VALUE=0xdead000000000000
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_SPARSEMEM_MANUAL=y
CONFIG_SPARSEMEM=y
CONFIG_HAVE_MEMORY_PRESENT=y
CONFIG_SPARSEMEM_EXTREME=y
CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER=y
CONFIG_SPARSEMEM_VMEMMAP=y
CONFIG_HAVE_MEMBLOCK=y
CONFIG_HAVE_MEMBLOCK_NODE_MAP=y
CONFIG_ARCH_DISCARD_MEMBLOCK=y
# CONFIG_MEMORY_HOTPLUG is not set
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=999999
CONFIG_COMPACTION=y
CONFIG_MIGRATION=y
CONFIG_PHYS_ADDR_T_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
# CONFIG_KSM is not set
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_ARCH_SUPPORTS_MEMORY_FAILURE=y
# CONFIG_MEMORY_FAILURE is not set
CONFIG_TRANSPARENT_HUGEPAGE=y
CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y
# CONFIG_TRANSPARENT_HUGEPAGE_MADVISE is not set
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_NEED_PER_CPU_KM=y
# CONFIG_CLEANCACHE is not set
CONFIG_X86_CHECK_BIOS_CORRUPTION=y
CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK=y
CONFIG_X86_RESERVE_LOW=64
CONFIG_MTRR=y
CONFIG_MTRR_SANITIZER=y
CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=0
CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
CONFIG_X86_PAT=y
CONFIG_ARCH_USES_PG_UNCACHED=y
CONFIG_ARCH_RANDOM=y
CONFIG_X86_SMAP=y
# CONFIG_EFI is not set
CONFIG_SECCOMP=y
# CONFIG_CC_STACKPROTECTOR is not set
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
CONFIG_HZ_300=y
# CONFIG_HZ_1000 is not set
CONFIG_HZ=300
CONFIG_SCHED_HRTICK=y
# CONFIG_KEXEC is not set
CONFIG_CRASH_DUMP=y
CONFIG_PHYSICAL_START=0x1000000
# CONFIG_RELOCATABLE is not set
CONFIG_PHYSICAL_ALIGN=0x1000000
CONFIG_CMDLINE_BOOL=y
CONFIG_CMDLINE=""
CONFIG_CMDLINE_OVERRIDE=y
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y

#
# Power management and ACPI options
#
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
CONFIG_HIBERNATE_CALLBACKS=y
CONFIG_PM_SLEEP=y
# CONFIG_PM_AUTOSLEEP is not set
CONFIG_PM_WAKELOCKS=y
CONFIG_PM_WAKELOCKS_LIMIT=100
# CONFIG_PM_WAKELOCKS_GC is not set
# CONFIG_PM_RUNTIME is not set
CONFIG_PM=y
CONFIG_PM_DEBUG=y
# CONFIG_PM_ADVANCED_DEBUG is not set
CONFIG_PM_SLEEP_DEBUG=y
CONFIG_PM_TRACE=y
CONFIG_PM_TRACE_RTC=y
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
# CONFIG_ACPI_PROCFS is not set
# CONFIG_ACPI_PROCFS_POWER is not set
# CONFIG_ACPI_EC_DEBUGFS is not set
CONFIG_ACPI_PROC_EVENT=y
# CONFIG_ACPI_AC is not set
CONFIG_ACPI_BATTERY=m
# CONFIG_ACPI_BUTTON is not set
CONFIG_ACPI_VIDEO=m
# CONFIG_ACPI_FAN is not set
CONFIG_ACPI_DOCK=y
CONFIG_ACPI_PROCESSOR=m
CONFIG_ACPI_IPMI=m
CONFIG_ACPI_PROCESSOR_AGGREGATOR=m
# CONFIG_ACPI_THERMAL is not set
# CONFIG_ACPI_CUSTOM_DSDT is not set
CONFIG_ACPI_INITRD_TABLE_OVERRIDE=y
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
# CONFIG_ACPI_PCI_SLOT is not set
CONFIG_X86_PM_TIMER=y
# CONFIG_ACPI_CONTAINER is not set
# CONFIG_ACPI_SBS is not set
CONFIG_ACPI_HED=y
# CONFIG_ACPI_CUSTOM_METHOD is not set
CONFIG_ACPI_APEI=y
CONFIG_ACPI_APEI_GHES=y
# CONFIG_ACPI_APEI_PCIEAER is not set
CONFIG_ACPI_APEI_EINJ=m
# CONFIG_ACPI_APEI_ERST_DEBUG is not set
CONFIG_SFI=y

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set
CONFIG_CPU_IDLE=y
CONFIG_CPU_IDLE_GOV_LADDER=y
CONFIG_CPU_IDLE_GOV_MENU=y
# CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set
# CONFIG_INTEL_IDLE is not set

#
# Memory power savings
#
# CONFIG_I7300_IDLE is not set

#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
CONFIG_PCI_DIRECT=y
# CONFIG_PCI_MMCONFIG is not set
CONFIG_PCI_XEN=y
CONFIG_PCI_DOMAINS=y
CONFIG_PCIEPORTBUS=y
CONFIG_HOTPLUG_PCI_PCIE=m
CONFIG_PCIEAER=y
# CONFIG_PCIE_ECRC is not set
# CONFIG_PCIEAER_INJECT is not set
CONFIG_PCIEASPM=y
# CONFIG_PCIEASPM_DEBUG is not set
# CONFIG_PCIEASPM_DEFAULT is not set
# CONFIG_PCIEASPM_POWERSAVE is not set
CONFIG_PCIEASPM_PERFORMANCE=y
CONFIG_ARCH_SUPPORTS_MSI=y
CONFIG_PCI_MSI=y
CONFIG_PCI_DEBUG=y
# CONFIG_PCI_REALLOC_ENABLE_AUTO is not set
# CONFIG_PCI_STUB is not set
CONFIG_XEN_PCIDEV_FRONTEND=m
CONFIG_HT_IRQ=y
# CONFIG_PCI_IOV is not set
# CONFIG_PCI_PRI is not set
# CONFIG_PCI_PASID is not set
CONFIG_PCI_IOAPIC=m
CONFIG_PCI_LABEL=y
CONFIG_ISA_DMA_API=y
CONFIG_AMD_NB=y
# CONFIG_PCCARD is not set
CONFIG_HOTPLUG_PCI=m
# CONFIG_HOTPLUG_PCI_ACPI is not set
CONFIG_HOTPLUG_PCI_CPCI=y
# CONFIG_HOTPLUG_PCI_CPCI_ZT5550 is not set
CONFIG_HOTPLUG_PCI_CPCI_GENERIC=m
# CONFIG_HOTPLUG_PCI_SHPC is not set
# CONFIG_RAPIDIO is not set

#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y
CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
# CONFIG_HAVE_AOUT is not set
# CONFIG_BINFMT_MISC is not set
CONFIG_COREDUMP=y
# CONFIG_IA32_EMULATION is not set
CONFIG_HAVE_TEXT_POKE_SMP=y
CONFIG_X86_DEV_DMA_OPS=y
CONFIG_NET=y

#
# Networking options
#
# CONFIG_PACKET is not set
CONFIG_UNIX=m
CONFIG_UNIX_DIAG=m
CONFIG_XFRM=y
CONFIG_XFRM_ALGO=m
# CONFIG_XFRM_USER is not set
# CONFIG_XFRM_SUB_POLICY is not set
CONFIG_XFRM_MIGRATE=y
CONFIG_XFRM_STATISTICS=y
CONFIG_XFRM_IPCOMP=m
CONFIG_NET_KEY=m
CONFIG_NET_KEY_MIGRATE=y
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_IP_FIB_TRIE_STATS=y
# CONFIG_IP_MULTIPLE_TABLES is not set
CONFIG_IP_ROUTE_MULTIPATH=y
# CONFIG_IP_ROUTE_VERBOSE is not set
CONFIG_IP_ROUTE_CLASSID=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
# CONFIG_IP_PNP_BOOTP is not set
CONFIG_IP_PNP_RARP=y
CONFIG_NET_IPIP=m
# CONFIG_NET_IPGRE_DEMUX is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
CONFIG_NET_IPVTI=m
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
CONFIG_INET_TUNNEL=m
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
CONFIG_INET_XFRM_MODE_TUNNEL=m
CONFIG_INET_XFRM_MODE_BEET=m
CONFIG_INET_LRO=m
CONFIG_INET_DIAG=m
CONFIG_INET_TCP_DIAG=m
# CONFIG_INET_UDP_DIAG is not set
CONFIG_TCP_CONG_ADVANCED=y
# CONFIG_TCP_CONG_BIC is not set
# CONFIG_TCP_CONG_CUBIC is not set
# CONFIG_TCP_CONG_WESTWOOD is not set
# CONFIG_TCP_CONG_HTCP is not set
# CONFIG_TCP_CONG_HSTCP is not set
CONFIG_TCP_CONG_HYBLA=m
# CONFIG_TCP_CONG_VEGAS is not set
# CONFIG_TCP_CONG_SCALABLE is not set
# CONFIG_TCP_CONG_LP is not set
# CONFIG_TCP_CONG_VENO is not set
# CONFIG_TCP_CONG_YEAH is not set
CONFIG_TCP_CONG_ILLINOIS=m
CONFIG_DEFAULT_RENO=y
CONFIG_DEFAULT_TCP_CONG="reno"
CONFIG_TCP_MD5SIG=y
CONFIG_IPV6=m
# CONFIG_IPV6_PRIVACY is not set
CONFIG_IPV6_ROUTER_PREF=y
# CONFIG_IPV6_ROUTE_INFO is not set
CONFIG_IPV6_OPTIMISTIC_DAD=y
# CONFIG_INET6_AH is not set
CONFIG_INET6_ESP=m
CONFIG_INET6_IPCOMP=m
# CONFIG_IPV6_MIP6 is not set
CONFIG_INET6_XFRM_TUNNEL=m
CONFIG_INET6_TUNNEL=m
# CONFIG_INET6_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET6_XFRM_MODE_TUNNEL is not set
CONFIG_INET6_XFRM_MODE_BEET=m
CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION=m
CONFIG_IPV6_SIT=m
CONFIG_IPV6_SIT_6RD=y
CONFIG_IPV6_NDISC_NODETYPE=y
CONFIG_IPV6_TUNNEL=m
CONFIG_IPV6_GRE=m
CONFIG_IPV6_MULTIPLE_TABLES=y
# CONFIG_IPV6_SUBTREES is not set
# CONFIG_IPV6_MROUTE is not set
# CONFIG_NETLABEL is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETWORK_PHY_TIMESTAMPING is not set
# CONFIG_NETFILTER is not set
# CONFIG_IP_DCCP is not set
CONFIG_IP_SCTP=m
# CONFIG_NET_SCTPPROBE is not set
CONFIG_SCTP_DBG_MSG=y
CONFIG_SCTP_DBG_OBJCNT=y
# CONFIG_SCTP_HMAC_NONE is not set
# CONFIG_SCTP_HMAC_SHA1 is not set
CONFIG_SCTP_HMAC_MD5=y
# CONFIG_RDS is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
CONFIG_L2TP=m
CONFIG_L2TP_DEBUGFS=m
CONFIG_L2TP_V3=y
# CONFIG_L2TP_IP is not set
CONFIG_L2TP_ETH=m
CONFIG_STP=m
CONFIG_BRIDGE=m
CONFIG_BRIDGE_IGMP_SNOOPING=y
CONFIG_NET_DSA=m
CONFIG_NET_DSA_TAG_DSA=y
# CONFIG_NET_DSA_TAG_EDSA is not set
# CONFIG_NET_DSA_TAG_TRAILER is not set
# CONFIG_VLAN_8021Q is not set
CONFIG_DECNET=m
CONFIG_DECNET_ROUTER=y
CONFIG_LLC=m
CONFIG_LLC2=m
# CONFIG_IPX is not set
CONFIG_ATALK=m
CONFIG_DEV_APPLETALK=m
CONFIG_IPDDP=m
# CONFIG_IPDDP_ENCAP is not set
# CONFIG_IPDDP_DECAP is not set
CONFIG_X25=m
CONFIG_LAPB=m
# CONFIG_WAN_ROUTER is not set
CONFIG_PHONET=m
CONFIG_IEEE802154=m
# CONFIG_IEEE802154_6LOWPAN is not set
# CONFIG_MAC802154 is not set
CONFIG_NET_SCHED=y

#
# Queueing/Scheduling
#
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
# CONFIG_NET_SCH_HFSC is not set
# CONFIG_NET_SCH_PRIO is not set
# CONFIG_NET_SCH_MULTIQ is not set
# CONFIG_NET_SCH_RED is not set
CONFIG_NET_SCH_SFB=m
CONFIG_NET_SCH_SFQ=m
# CONFIG_NET_SCH_TEQL is not set
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
# CONFIG_NET_SCH_DSMARK is not set
CONFIG_NET_SCH_NETEM=m
CONFIG_NET_SCH_DRR=m
CONFIG_NET_SCH_MQPRIO=m
CONFIG_NET_SCH_CHOKE=m
# CONFIG_NET_SCH_QFQ is not set
CONFIG_NET_SCH_CODEL=m
# CONFIG_NET_SCH_FQ_CODEL is not set
CONFIG_NET_SCH_INGRESS=m
CONFIG_NET_SCH_PLUG=m

#
# Classification
#
CONFIG_NET_CLS=y
CONFIG_NET_CLS_BASIC=m
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
# CONFIG_NET_CLS_FW is not set
# CONFIG_NET_CLS_U32 is not set
CONFIG_NET_CLS_RSVP=m
CONFIG_NET_CLS_RSVP6=m
CONFIG_NET_CLS_FLOW=m
# CONFIG_NET_CLS_CGROUP is not set
CONFIG_NET_EMATCH=y
CONFIG_NET_EMATCH_STACK=32
CONFIG_NET_EMATCH_CMP=m
CONFIG_NET_EMATCH_NBYTE=m
# CONFIG_NET_EMATCH_U32 is not set
# CONFIG_NET_EMATCH_META is not set
CONFIG_NET_EMATCH_TEXT=m
CONFIG_NET_CLS_ACT=y
CONFIG_NET_ACT_POLICE=m
# CONFIG_NET_ACT_GACT is not set
# CONFIG_NET_ACT_MIRRED is not set
# CONFIG_NET_ACT_NAT is not set
# CONFIG_NET_ACT_PEDIT is not set
CONFIG_NET_ACT_SIMP=m
CONFIG_NET_ACT_SKBEDIT=m
# CONFIG_NET_ACT_CSUM is not set
CONFIG_NET_SCH_FIFO=y
# CONFIG_DCB is not set
CONFIG_DNS_RESOLVER=m
CONFIG_BATMAN_ADV=m
CONFIG_BATMAN_ADV_BLA=y
CONFIG_BATMAN_ADV_DEBUG=y
CONFIG_OPENVSWITCH=m
# CONFIG_NETPRIO_CGROUP is not set
CONFIG_BQL=y
CONFIG_BPF_JIT=y

#
# Network testing
#
CONFIG_NET_PKTGEN=m
CONFIG_NET_TCPPROBE=m
CONFIG_HAMRADIO=y

#
# Packet Radio protocols
#
CONFIG_AX25=m
# CONFIG_AX25_DAMA_SLAVE is not set
CONFIG_NETROM=m
# CONFIG_ROSE is not set

#
# AX.25 network device drivers
#
CONFIG_MKISS=m
# CONFIG_6PACK is not set
# CONFIG_BPQETHER is not set
CONFIG_BAYCOM_SER_FDX=m
# CONFIG_BAYCOM_SER_HDX is not set
CONFIG_YAM=m
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
CONFIG_AF_RXRPC=m
# CONFIG_AF_RXRPC_DEBUG is not set
# CONFIG_RXKAD is not set
CONFIG_FIB_RULES=y
# CONFIG_WIRELESS is not set
# CONFIG_WIMAX is not set
# CONFIG_RFKILL is not set
# CONFIG_RFKILL_REGULATOR is not set
CONFIG_NET_9P=y
CONFIG_NET_9P_VIRTIO=y
CONFIG_NET_9P_DEBUG=y
CONFIG_CAIF=m
# CONFIG_CAIF_DEBUG is not set
CONFIG_CAIF_NETDEV=m
# CONFIG_CAIF_USB is not set
CONFIG_CEPH_LIB=m
# CONFIG_CEPH_LIB_PRETTYDEBUG is not set
CONFIG_CEPH_LIB_USE_DNS_RESOLVER=y
CONFIG_NFC=m
# CONFIG_NFC_NCI is not set
# CONFIG_NFC_HCI is not set
CONFIG_NFC_LLCP=y

#
# Near Field Communication (NFC) devices
#
CONFIG_HAVE_BPF_JIT=y

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH=""
CONFIG_DEVTMPFS=y
# CONFIG_DEVTMPFS_MOUNT is not set
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
# CONFIG_FIRMWARE_IN_KERNEL is not set
CONFIG_EXTRA_FIRMWARE=""
CONFIG_DEBUG_DRIVER=y
CONFIG_DEBUG_DEVRES=y
CONFIG_SYS_HYPERVISOR=y
# CONFIG_GENERIC_CPU_DEVICES is not set
CONFIG_REGMAP=y
CONFIG_REGMAP_I2C=m
CONFIG_REGMAP_SPI=y
CONFIG_DMA_SHARED_BUFFER=y

#
# Bus devices
#
CONFIG_OMAP_OCP2SCP=m
CONFIG_CONNECTOR=m
# CONFIG_MTD is not set
# CONFIG_PARPORT is not set
CONFIG_PNP=y
# CONFIG_PNP_DEBUG_MESSAGES is not set

#
# Protocols
#
CONFIG_PNPACPI=y
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_DEV_PCIESSD_MTIP32XX is not set
CONFIG_BLK_CPQ_DA=m
CONFIG_BLK_CPQ_CISS_DA=m
CONFIG_CISS_SCSI_TAPE=y
CONFIG_BLK_DEV_DAC960=m
CONFIG_BLK_DEV_UMEM=m
# CONFIG_BLK_DEV_COW_COMMON is not set
# CONFIG_BLK_DEV_LOOP is not set
# CONFIG_BLK_DEV_DRBD is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_NVME is not set
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_RAM is not set
CONFIG_CDROM_PKTCDVD=m
CONFIG_CDROM_PKTCDVD_BUFFERS=8
# CONFIG_CDROM_PKTCDVD_WCACHE is not set
CONFIG_ATA_OVER_ETH=m
CONFIG_XEN_BLKDEV_FRONTEND=m
CONFIG_VIRTIO_BLK=y
CONFIG_BLK_DEV_HD=y
CONFIG_BLK_DEV_RBD=m

#
# Misc devices
#
CONFIG_SENSORS_LIS3LV02D=m
CONFIG_AD525X_DPOT=m
# CONFIG_AD525X_DPOT_I2C is not set
# CONFIG_AD525X_DPOT_SPI is not set
CONFIG_IBM_ASM=m
CONFIG_PHANTOM=m
# CONFIG_INTEL_MID_PTI is not set
# CONFIG_SGI_IOC4 is not set
CONFIG_TIFM_CORE=m
# CONFIG_TIFM_7XX1 is not set
CONFIG_ICS932S401=m
# CONFIG_ENCLOSURE_SERVICES is not set
# CONFIG_CS5535_MFGPT is not set
CONFIG_HP_ILO=m
CONFIG_APDS9802ALS=m
CONFIG_ISL29003=m
# CONFIG_ISL29020 is not set
CONFIG_SENSORS_TSL2550=m
# CONFIG_SENSORS_BH1780 is not set
CONFIG_SENSORS_BH1770=m
# CONFIG_SENSORS_APDS990X is not set
CONFIG_HMC6352=m
CONFIG_DS1682=m
CONFIG_TI_DAC7512=m
CONFIG_VMWARE_BALLOON=m
# CONFIG_BMP085_I2C is not set
# CONFIG_BMP085_SPI is not set
CONFIG_PCH_PHUB=m
# CONFIG_USB_SWITCH_FSA9480 is not set
CONFIG_C2PORT=m
CONFIG_C2PORT_DURAMAR_2150=m

#
# EEPROM support
#
CONFIG_EEPROM_AT24=m
CONFIG_EEPROM_AT25=m
# CONFIG_EEPROM_LEGACY is not set
CONFIG_EEPROM_MAX6875=m
# CONFIG_EEPROM_93CX6 is not set
# CONFIG_EEPROM_93XX46 is not set
# CONFIG_CB710_CORE is not set

#
# Texas Instruments shared transport line discipline
#
CONFIG_SENSORS_LIS3_I2C=m

#
# Altera FPGA firmware download module
#
# CONFIG_ALTERA_STAPL is not set
CONFIG_INTEL_MEI=m
CONFIG_HAVE_IDE=y
CONFIG_IDE=m

#
# Please see Documentation/ide/ide.txt for help/info on IDE drives
#
CONFIG_IDE_XFER_MODE=y
CONFIG_IDE_TIMINGS=y
CONFIG_IDE_ATAPI=y
CONFIG_BLK_DEV_IDE_SATA=y
# CONFIG_IDE_GD is not set
# CONFIG_BLK_DEV_IDECD is not set
CONFIG_BLK_DEV_IDETAPE=m
CONFIG_BLK_DEV_IDEACPI=y
# CONFIG_IDE_TASK_IOCTL is not set
# CONFIG_IDE_PROC_FS is not set

#
# IDE chipset support/bugfixes
#
# CONFIG_IDE_GENERIC is not set
# CONFIG_BLK_DEV_PLATFORM is not set
CONFIG_BLK_DEV_CMD640=m
CONFIG_BLK_DEV_CMD640_ENHANCED=y
CONFIG_BLK_DEV_IDEPNP=m
CONFIG_BLK_DEV_IDEDMA_SFF=y

#
# PCI IDE chipsets support
#
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_BLK_DEV_OFFBOARD=y
CONFIG_BLK_DEV_GENERIC=m
# CONFIG_BLK_DEV_OPTI621 is not set
CONFIG_BLK_DEV_RZ1000=m
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_AEC62XX is not set
CONFIG_BLK_DEV_ALI15X3=m
CONFIG_BLK_DEV_AMD74XX=m
# CONFIG_BLK_DEV_ATIIXP is not set
# CONFIG_BLK_DEV_CMD64X is not set
CONFIG_BLK_DEV_TRIFLEX=m
CONFIG_BLK_DEV_CS5520=m
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_HPT366 is not set
CONFIG_BLK_DEV_JMICRON=m
# CONFIG_BLK_DEV_SC1200 is not set
CONFIG_BLK_DEV_PIIX=m
CONFIG_BLK_DEV_IT8172=m
CONFIG_BLK_DEV_IT8213=m
# CONFIG_BLK_DEV_IT821X is not set
CONFIG_BLK_DEV_NS87415=m
CONFIG_BLK_DEV_PDC202XX_OLD=m
CONFIG_BLK_DEV_PDC202XX_NEW=m
CONFIG_BLK_DEV_SVWKS=m
# CONFIG_BLK_DEV_SIIMAGE is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
CONFIG_BLK_DEV_TRM290=m
CONFIG_BLK_DEV_VIA82CXXX=m
# CONFIG_BLK_DEV_TC86C001 is not set
CONFIG_BLK_DEV_IDEDMA=y

#
# SCSI device support
#
CONFIG_SCSI_MOD=m
CONFIG_RAID_ATTRS=m
CONFIG_SCSI=m
CONFIG_SCSI_DMA=y
CONFIG_SCSI_TGT=m
CONFIG_SCSI_NETLINK=y
# CONFIG_SCSI_PROC_FS is not set

#
# SCSI support type (disk, tape, CD-ROM)
#
# CONFIG_BLK_DEV_SD is not set
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
# CONFIG_CHR_DEV_SG is not set
CONFIG_CHR_DEV_SCH=m
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
# CONFIG_SCSI_SCAN_ASYNC is not set

#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=m
CONFIG_SCSI_FC_ATTRS=m
CONFIG_SCSI_FC_TGT_ATTRS=y
CONFIG_SCSI_ISCSI_ATTRS=m
CONFIG_SCSI_SAS_ATTRS=m
CONFIG_SCSI_SAS_LIBSAS=m
# CONFIG_SCSI_SAS_ATA is not set
CONFIG_SCSI_SAS_HOST_SMP=y
CONFIG_SCSI_SRP_ATTRS=m
CONFIG_SCSI_SRP_TGT_ATTRS=y
CONFIG_SCSI_LOWLEVEL=y
# CONFIG_ISCSI_TCP is not set
# CONFIG_ISCSI_BOOT_SYSFS is not set
CONFIG_SCSI_CXGB3_ISCSI=m
CONFIG_SCSI_CXGB4_ISCSI=m
CONFIG_SCSI_BNX2_ISCSI=m
# CONFIG_SCSI_BNX2X_FCOE is not set
# CONFIG_BE2ISCSI is not set
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
CONFIG_SCSI_HPSA=m
CONFIG_SCSI_3W_9XXX=m
# CONFIG_SCSI_3W_SAS is not set
# CONFIG_SCSI_ACARD is not set
CONFIG_SCSI_AACRAID=m
# CONFIG_SCSI_AIC7XXX is not set
CONFIG_SCSI_AIC7XXX_OLD=m
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_AIC94XX is not set
CONFIG_SCSI_MVSAS=m
# CONFIG_SCSI_MVSAS_DEBUG is not set
CONFIG_SCSI_MVSAS_TASKLET=y
CONFIG_SCSI_MVUMI=m
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_ADVANSYS is not set
CONFIG_SCSI_ARCMSR=m
CONFIG_MEGARAID_NEWGEN=y
CONFIG_MEGARAID_MM=m
# CONFIG_MEGARAID_MAILBOX is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
CONFIG_SCSI_MPT2SAS=m
CONFIG_SCSI_MPT2SAS_MAX_SGE=128
# CONFIG_SCSI_MPT2SAS_LOGGING is not set
CONFIG_SCSI_UFSHCD=m
CONFIG_SCSI_HPTIOP=m
CONFIG_SCSI_BUSLOGIC=m
CONFIG_VMWARE_PVSCSI=m
CONFIG_LIBFC=m
CONFIG_LIBFCOE=m
# CONFIG_FCOE is not set
CONFIG_FCOE_FNIC=m
CONFIG_SCSI_DMX3191D=m
CONFIG_SCSI_EATA=m
# CONFIG_SCSI_EATA_TAGGED_QUEUE is not set
CONFIG_SCSI_EATA_LINKED_COMMANDS=y
CONFIG_SCSI_EATA_MAX_TAGS=16
CONFIG_SCSI_FUTURE_DOMAIN=m
CONFIG_SCSI_GDTH=m
# CONFIG_SCSI_ISCI is not set
# CONFIG_SCSI_IPS is not set
CONFIG_SCSI_INITIO=m
# CONFIG_SCSI_INIA100 is not set
CONFIG_SCSI_STEX=m
CONFIG_SCSI_SYM53C8XX_2=m
CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1
CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16
CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64
# CONFIG_SCSI_SYM53C8XX_MMIO is not set
CONFIG_SCSI_IPR=m
# CONFIG_SCSI_IPR_TRACE is not set
# CONFIG_SCSI_IPR_DUMP is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLA_FC is not set
# CONFIG_SCSI_QLA_ISCSI is not set
# CONFIG_SCSI_LPFC is not set
CONFIG_SCSI_DC395x=m
# CONFIG_SCSI_DC390T is not set
CONFIG_SCSI_DEBUG=m
CONFIG_SCSI_PMCRAID=m
# CONFIG_SCSI_PM8001 is not set
CONFIG_SCSI_SRP=m
# CONFIG_SCSI_BFA_FC is not set
CONFIG_SCSI_VIRTIO=m
# CONFIG_SCSI_DH is not set
# CONFIG_SCSI_OSD_INITIATOR is not set
CONFIG_ATA=m
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_ATA_VERBOSE_ERROR=y
# CONFIG_ATA_ACPI is not set
# CONFIG_SATA_PMP is not set

#
# Controllers with non-SFF native interface
#
CONFIG_SATA_AHCI=m
# CONFIG_SATA_AHCI_PLATFORM is not set
CONFIG_SATA_INIC162X=m
CONFIG_SATA_ACARD_AHCI=m
CONFIG_SATA_SIL24=m
# CONFIG_ATA_SFF is not set
CONFIG_MD=y
# CONFIG_BLK_DEV_MD is not set
# CONFIG_BLK_DEV_DM is not set
# CONFIG_TARGET_CORE is not set
CONFIG_FUSION=y
CONFIG_FUSION_SPI=m
# CONFIG_FUSION_FC is not set
CONFIG_FUSION_SAS=m
CONFIG_FUSION_MAX_SGE=128
# CONFIG_FUSION_CTL is not set
# CONFIG_FUSION_LOGGING is not set

#
# IEEE 1394 (FireWire) support
#
CONFIG_FIREWIRE=m
# CONFIG_FIREWIRE_OHCI is not set
# CONFIG_FIREWIRE_SBP2 is not set
CONFIG_FIREWIRE_NET=m
CONFIG_FIREWIRE_NOSY=m
CONFIG_I2O=m
# CONFIG_I2O_LCT_NOTIFY_ON_CHANGES is not set
CONFIG_I2O_EXT_ADAPTEC=y
CONFIG_I2O_EXT_ADAPTEC_DMA64=y
# CONFIG_I2O_CONFIG is not set
# CONFIG_I2O_BUS is not set
# CONFIG_I2O_BLOCK is not set
CONFIG_I2O_SCSI=m
# CONFIG_I2O_PROC is not set
CONFIG_MACINTOSH_DRIVERS=y
CONFIG_MAC_EMUMOUSEBTN=m
CONFIG_NETDEVICES=y
CONFIG_NET_CORE=y
CONFIG_BONDING=m
CONFIG_DUMMY=m
CONFIG_EQUALIZER=m
# CONFIG_NET_FC is not set
CONFIG_MII=m
CONFIG_IFB=m
CONFIG_NET_TEAM=m
CONFIG_NET_TEAM_MODE_BROADCAST=m
# CONFIG_NET_TEAM_MODE_ROUNDROBIN is not set
# CONFIG_NET_TEAM_MODE_ACTIVEBACKUP is not set
CONFIG_NET_TEAM_MODE_LOADBALANCE=m
# CONFIG_MACVLAN is not set
# CONFIG_VXLAN is not set
CONFIG_NETCONSOLE=m
# CONFIG_NETCONSOLE_DYNAMIC is not set
CONFIG_NETPOLL=y
# CONFIG_NETPOLL_TRAP is not set
CONFIG_NET_POLL_CONTROLLER=y
# CONFIG_TUN is not set
CONFIG_VETH=m
CONFIG_VIRTIO_NET=y
CONFIG_ARCNET=m
# CONFIG_ARCNET_1201 is not set
CONFIG_ARCNET_1051=m
CONFIG_ARCNET_RAW=m
CONFIG_ARCNET_CAP=m
CONFIG_ARCNET_COM90xx=m
# CONFIG_ARCNET_COM90xxIO is not set
CONFIG_ARCNET_RIM_I=m
# CONFIG_ARCNET_COM20020 is not set

#
# CAIF transport drivers
#
CONFIG_CAIF_TTY=m
# CONFIG_CAIF_SPI_SLAVE is not set
# CONFIG_CAIF_HSI is not set

#
# Distributed Switch Architecture drivers
#
CONFIG_NET_DSA_MV88E6XXX=m
# CONFIG_NET_DSA_MV88E6060 is not set
CONFIG_NET_DSA_MV88E6XXX_NEED_PPU=y
CONFIG_NET_DSA_MV88E6131=m
# CONFIG_NET_DSA_MV88E6123_61_65 is not set
CONFIG_ETHERNET=y
CONFIG_MDIO=m
# CONFIG_NET_VENDOR_3COM is not set
CONFIG_NET_VENDOR_ADAPTEC=y
CONFIG_ADAPTEC_STARFIRE=m
CONFIG_NET_VENDOR_ALTEON=y
# CONFIG_ACENIC is not set
CONFIG_NET_VENDOR_AMD=y
CONFIG_AMD8111_ETH=m
CONFIG_PCNET32=m
# CONFIG_NET_VENDOR_ATHEROS is not set
CONFIG_NET_CADENCE=y
# CONFIG_ARM_AT91_ETHER is not set
# CONFIG_MACB is not set
CONFIG_NET_VENDOR_BROADCOM=y
# CONFIG_B44 is not set
CONFIG_BNX2=m
CONFIG_CNIC=m
CONFIG_TIGON3=m
CONFIG_BNX2X=m
# CONFIG_NET_VENDOR_BROCADE is not set
# CONFIG_NET_CALXEDA_XGMAC is not set
CONFIG_NET_VENDOR_CHELSIO=y
# CONFIG_CHELSIO_T1 is not set
CONFIG_CHELSIO_T3=m
CONFIG_CHELSIO_T4=m
CONFIG_CHELSIO_T4VF=m
# CONFIG_NET_VENDOR_CISCO is not set
# CONFIG_DNET is not set
# CONFIG_NET_VENDOR_DEC is not set
CONFIG_NET_VENDOR_DLINK=y
# CONFIG_DL2K is not set
# CONFIG_SUNDANCE is not set
# CONFIG_NET_VENDOR_EMULEX is not set
CONFIG_NET_VENDOR_EXAR=y
# CONFIG_S2IO is not set
CONFIG_VXGE=m
CONFIG_VXGE_DEBUG_TRACE_ALL=y
CONFIG_NET_VENDOR_HP=y
CONFIG_HP100=m
# CONFIG_NET_VENDOR_INTEL is not set
# CONFIG_IP1000 is not set
CONFIG_JME=m
CONFIG_NET_VENDOR_MARVELL=y
# CONFIG_SKGE is not set
CONFIG_SKY2=m
# CONFIG_SKY2_DEBUG is not set
# CONFIG_NET_VENDOR_MELLANOX is not set
# CONFIG_NET_VENDOR_MICREL is not set
# CONFIG_NET_VENDOR_MICROCHIP is not set
# CONFIG_NET_VENDOR_MYRI is not set
# CONFIG_FEALNX is not set
# CONFIG_NET_VENDOR_NATSEMI is not set
# CONFIG_NET_VENDOR_NVIDIA is not set
CONFIG_NET_VENDOR_OKI=y
# CONFIG_PCH_GBE is not set
CONFIG_ETHOC=m
# CONFIG_NET_PACKET_ENGINE is not set
CONFIG_NET_VENDOR_QLOGIC=y
# CONFIG_QLA3XXX is not set
# CONFIG_QLCNIC is not set
CONFIG_QLGE=m
# CONFIG_NETXEN_NIC is not set
CONFIG_NET_VENDOR_REALTEK=y
# CONFIG_8139CP is not set
CONFIG_8139TOO=m
# CONFIG_8139TOO_PIO is not set
CONFIG_8139TOO_TUNE_TWISTER=y
# CONFIG_8139TOO_8129 is not set
CONFIG_8139_OLD_RX_RESET=y
# CONFIG_R8169 is not set
CONFIG_NET_VENDOR_RDC=y
# CONFIG_R6040 is not set
# CONFIG_NET_VENDOR_SEEQ is not set
# CONFIG_NET_VENDOR_SILAN is not set
CONFIG_NET_VENDOR_SIS=y
# CONFIG_SIS900 is not set
CONFIG_SIS190=m
CONFIG_SFC=m
CONFIG_SFC_MCDI_MON=y
CONFIG_NET_VENDOR_SMSC=y
CONFIG_EPIC100=m
CONFIG_SMSC9420=m
# CONFIG_NET_VENDOR_STMICRO is not set
# CONFIG_NET_VENDOR_SUN is not set
CONFIG_NET_VENDOR_TEHUTI=y
# CONFIG_TEHUTI is not set
# CONFIG_NET_VENDOR_TI is not set
CONFIG_NET_VENDOR_VIA=y
# CONFIG_VIA_RHINE is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_NET_VENDOR_WIZNET is not set
CONFIG_FDDI=m
# CONFIG_DEFXX is not set
CONFIG_SKFP=m
# CONFIG_HIPPI is not set
# CONFIG_NET_SB1000 is not set
CONFIG_PHYLIB=m

#
# MII PHY device drivers
#
CONFIG_AT803X_PHY=m
CONFIG_AMD_PHY=m
# CONFIG_MARVELL_PHY is not set
CONFIG_DAVICOM_PHY=m
CONFIG_QSEMI_PHY=m
CONFIG_LXT_PHY=m
# CONFIG_CICADA_PHY is not set
CONFIG_VITESSE_PHY=m
CONFIG_SMSC_PHY=m
# CONFIG_BROADCOM_PHY is not set
CONFIG_BCM87XX_PHY=m
# CONFIG_ICPLUS_PHY is not set
# CONFIG_REALTEK_PHY is not set
# CONFIG_NATIONAL_PHY is not set
# CONFIG_STE10XP is not set
# CONFIG_LSI_ET1011C_PHY is not set
CONFIG_MICREL_PHY=m
CONFIG_MDIO_BITBANG=m
CONFIG_MICREL_KS8995MA=m
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_WLAN is not set

#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#
CONFIG_WAN=y
# CONFIG_HDLC is not set
# CONFIG_DLCI is not set
CONFIG_LAPBETHER=m
# CONFIG_X25_ASY is not set
CONFIG_SBNI=m
# CONFIG_SBNI_MULTILINE is not set
# CONFIG_IEEE802154_DRIVERS is not set
# CONFIG_XEN_NETDEV_FRONTEND is not set
CONFIG_VMXNET3=m
# CONFIG_ISDN is not set

#
# Input device support
#
CONFIG_INPUT=y
CONFIG_INPUT_FF_MEMLESS=m
CONFIG_INPUT_POLLDEV=m
# CONFIG_INPUT_SPARSEKMAP is not set
CONFIG_INPUT_MATRIXKMAP=m

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_INPUT_JOYDEV=m
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ADP5588=m
CONFIG_KEYBOARD_ADP5589=m
CONFIG_KEYBOARD_ATKBD=y
CONFIG_KEYBOARD_QT1070=m
CONFIG_KEYBOARD_QT2160=m
CONFIG_KEYBOARD_LKKBD=m
CONFIG_KEYBOARD_TCA6416=m
# CONFIG_KEYBOARD_TCA8418 is not set
# CONFIG_KEYBOARD_LM8323 is not set
CONFIG_KEYBOARD_LM8333=m
CONFIG_KEYBOARD_MAX7359=m
# CONFIG_KEYBOARD_MCS is not set
CONFIG_KEYBOARD_MPR121=m
CONFIG_KEYBOARD_NEWTON=m
# CONFIG_KEYBOARD_OPENCORES is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
CONFIG_KEYBOARD_SUNKBD=m
# CONFIG_KEYBOARD_STMPE is not set
# CONFIG_KEYBOARD_OMAP4 is not set
CONFIG_KEYBOARD_XTKBD=m
CONFIG_INPUT_MOUSE=y
# CONFIG_MOUSE_PS2 is not set
CONFIG_MOUSE_SERIAL=m
CONFIG_MOUSE_VSXXXAA=m
# CONFIG_MOUSE_SYNAPTICS_I2C is not set
CONFIG_INPUT_JOYSTICK=y
CONFIG_JOYSTICK_ANALOG=m
# CONFIG_JOYSTICK_A3D is not set
CONFIG_JOYSTICK_ADI=m
CONFIG_JOYSTICK_COBRA=m
# CONFIG_JOYSTICK_GF2K is not set
# CONFIG_JOYSTICK_GRIP is not set
CONFIG_JOYSTICK_GRIP_MP=m
CONFIG_JOYSTICK_GUILLEMOT=m
# CONFIG_JOYSTICK_INTERACT is not set
CONFIG_JOYSTICK_SIDEWINDER=m
# CONFIG_JOYSTICK_TMDC is not set
CONFIG_JOYSTICK_IFORCE=m
# CONFIG_JOYSTICK_IFORCE_232 is not set
CONFIG_JOYSTICK_WARRIOR=m
CONFIG_JOYSTICK_MAGELLAN=m
CONFIG_JOYSTICK_SPACEORB=m
# CONFIG_JOYSTICK_SPACEBALL is not set
# CONFIG_JOYSTICK_STINGER is not set
# CONFIG_JOYSTICK_TWIDJOY is not set
CONFIG_JOYSTICK_ZHENHUA=m
# CONFIG_JOYSTICK_AS5011 is not set
CONFIG_JOYSTICK_JOYDUMP=m
CONFIG_INPUT_TABLET=y
CONFIG_INPUT_TOUCHSCREEN=y
CONFIG_TOUCHSCREEN_ADS7846=m
CONFIG_TOUCHSCREEN_AD7877=m
# CONFIG_TOUCHSCREEN_AD7879 is not set
# CONFIG_TOUCHSCREEN_ATMEL_MXT is not set
# CONFIG_TOUCHSCREEN_BU21013 is not set
# CONFIG_TOUCHSCREEN_CYTTSP_CORE is not set
# CONFIG_TOUCHSCREEN_DYNAPRO is not set
CONFIG_TOUCHSCREEN_HAMPSHIRE=m
CONFIG_TOUCHSCREEN_EETI=m
CONFIG_TOUCHSCREEN_EGALAX=m
# CONFIG_TOUCHSCREEN_FUJITSU is not set
CONFIG_TOUCHSCREEN_ILI210X=m
CONFIG_TOUCHSCREEN_GUNZE=m
CONFIG_TOUCHSCREEN_ELO=m
CONFIG_TOUCHSCREEN_WACOM_W8001=m
# CONFIG_TOUCHSCREEN_WACOM_I2C is not set
# CONFIG_TOUCHSCREEN_MAX11801 is not set
# CONFIG_TOUCHSCREEN_MCS5000 is not set
# CONFIG_TOUCHSCREEN_MMS114 is not set
# CONFIG_TOUCHSCREEN_MTOUCH is not set
CONFIG_TOUCHSCREEN_INEXIO=m
# CONFIG_TOUCHSCREEN_MK712 is not set
CONFIG_TOUCHSCREEN_PENMOUNT=m
# CONFIG_TOUCHSCREEN_EDT_FT5X06 is not set
CONFIG_TOUCHSCREEN_TOUCHRIGHT=m
CONFIG_TOUCHSCREEN_TOUCHWIN=m
CONFIG_TOUCHSCREEN_PIXCIR=m
# CONFIG_TOUCHSCREEN_WM831X is not set
# CONFIG_TOUCHSCREEN_MC13783 is not set
CONFIG_TOUCHSCREEN_TOUCHIT213=m
# CONFIG_TOUCHSCREEN_TSC_SERIO is not set
CONFIG_TOUCHSCREEN_TSC2005=m
CONFIG_TOUCHSCREEN_TSC2007=m
# CONFIG_TOUCHSCREEN_PCAP is not set
CONFIG_TOUCHSCREEN_ST1232=m
# CONFIG_TOUCHSCREEN_STMPE is not set
# CONFIG_TOUCHSCREEN_TPS6507X is not set
# CONFIG_INPUT_MISC is not set
CONFIG_INPUT_XEN_KBDDEV_FRONTEND=m

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=m
CONFIG_SERIO_CT82C710=m
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
CONFIG_SERIO_RAW=m
CONFIG_SERIO_ALTERA_PS2=m
CONFIG_SERIO_PS2MULT=m
CONFIG_SERIO_ARC_PS2=m
CONFIG_GAMEPORT=m
# CONFIG_GAMEPORT_NS558 is not set
CONFIG_GAMEPORT_L4=m
# CONFIG_GAMEPORT_EMU10K1 is not set
CONFIG_GAMEPORT_FM801=m

#
# Character devices
#
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_VT_CONSOLE_SLEEP=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_UNIX98_PTYS=y
CONFIG_DEVPTS_MULTIPLE_INSTANCES=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
CONFIG_SERIAL_NONSTANDARD=y
CONFIG_ROCKETPORT=m
CONFIG_CYCLADES=m
# CONFIG_CYZ_INTR is not set
# CONFIG_MOXA_INTELLIO is not set
# CONFIG_MOXA_SMARTIO is not set
# CONFIG_SYNCLINK is not set
# CONFIG_SYNCLINKMP is not set
CONFIG_SYNCLINK_GT=m
# CONFIG_NOZOMI is not set
CONFIG_ISI=m
CONFIG_N_HDLC=m
# CONFIG_N_GSM is not set
# CONFIG_TRACE_SINK is not set
CONFIG_DEVKMEM=y
# CONFIG_STALDRV is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_PNP=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
# CONFIG_SERIAL_8250_SHARE_IRQ is not set
CONFIG_SERIAL_8250_DETECT_IRQ=y
CONFIG_SERIAL_8250_RSA=y

#
# Non-8250 serial port support
#
CONFIG_SERIAL_KGDB_NMI=y
CONFIG_SERIAL_MAX3100=m
CONFIG_SERIAL_MAX310X=y
# CONFIG_SERIAL_MRST_MAX3110 is not set
CONFIG_SERIAL_MFD_HSU=m
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_CONSOLE_POLL=y
CONFIG_SERIAL_JSM=m
CONFIG_SERIAL_SCCNXP=m
CONFIG_SERIAL_TIMBERDALE=m
CONFIG_SERIAL_ALTERA_JTAGUART=m
# CONFIG_SERIAL_ALTERA_UART is not set
CONFIG_SERIAL_PCH_UART=m
# CONFIG_SERIAL_XILINX_PS_UART is not set
CONFIG_HVC_DRIVER=y
CONFIG_HVC_IRQ=y
CONFIG_HVC_XEN=y
# CONFIG_HVC_XEN_FRONTEND is not set
CONFIG_VIRTIO_CONSOLE=y
CONFIG_IPMI_HANDLER=m
CONFIG_IPMI_PANIC_EVENT=y
CONFIG_IPMI_PANIC_STRING=y
# CONFIG_IPMI_DEVICE_INTERFACE is not set
CONFIG_IPMI_SI=m
# CONFIG_IPMI_WATCHDOG is not set
# CONFIG_IPMI_POWEROFF is not set
CONFIG_HW_RANDOM=m
# CONFIG_HW_RANDOM_TIMERIOMEM is not set
CONFIG_HW_RANDOM_INTEL=m
# CONFIG_HW_RANDOM_AMD is not set
# CONFIG_HW_RANDOM_VIA is not set
CONFIG_HW_RANDOM_VIRTIO=m
CONFIG_HW_RANDOM_TPM=m
CONFIG_NVRAM=m
# CONFIG_RTC is not set
# CONFIG_GEN_RTC is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_MWAVE is not set
# CONFIG_RAW_DRIVER is not set
CONFIG_HPET=y
# CONFIG_HPET_MMAP is not set
# CONFIG_HANGCHECK_TIMER is not set
CONFIG_TCG_TPM=y
CONFIG_TCG_TIS=y
CONFIG_TCG_TIS_I2C_INFINEON=m
# CONFIG_TCG_NSC is not set
# CONFIG_TCG_ATMEL is not set
CONFIG_TCG_INFINEON=m
CONFIG_TELCLOCK=m
CONFIG_DEVPORT=y
CONFIG_I2C=m
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_COMPAT=y
# CONFIG_I2C_CHARDEV is not set
CONFIG_I2C_MUX=m

#
# Multiplexer I2C Chip support
#
# CONFIG_I2C_MUX_PCA9541 is not set
# CONFIG_I2C_MUX_PCA954x is not set
# CONFIG_I2C_HELPER_AUTO is not set
CONFIG_I2C_SMBUS=m

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=m
# CONFIG_I2C_ALGOPCF is not set
CONFIG_I2C_ALGOPCA=m

#
# I2C Hardware Bus support
#

#
# PC SMBus host controller drivers
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
CONFIG_I2C_AMD756=m
# CONFIG_I2C_AMD756_S4882 is not set
CONFIG_I2C_AMD8111=m
CONFIG_I2C_I801=m
CONFIG_I2C_ISCH=m
CONFIG_I2C_PIIX4=m
CONFIG_I2C_NFORCE2=m
CONFIG_I2C_NFORCE2_S4985=m
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_VIA is not set
CONFIG_I2C_VIAPRO=m

#
# ACPI drivers
#
CONFIG_I2C_SCMI=m

#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_DESIGNWARE_PCI is not set
# CONFIG_I2C_EG20T is not set
# CONFIG_I2C_INTEL_MID is not set
# CONFIG_I2C_OCORES is not set
CONFIG_I2C_PCA_PLATFORM=m
# CONFIG_I2C_PXA_PCI is not set
# CONFIG_I2C_SIMTEC is not set
# CONFIG_I2C_XILINX is not set

#
# External I2C/SMBus adapter drivers
#
CONFIG_I2C_PARPORT_LIGHT=m
# CONFIG_I2C_TAOS_EVM is not set

#
# Other I2C/SMBus bus drivers
#
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_DEBUG_CORE is not set
CONFIG_I2C_DEBUG_ALGO=y
CONFIG_I2C_DEBUG_BUS=y
CONFIG_SPI=y
# CONFIG_SPI_DEBUG is not set
CONFIG_SPI_MASTER=y

#
# SPI Master Controller Drivers
#
# CONFIG_SPI_ALTERA is not set
CONFIG_SPI_BITBANG=m
# CONFIG_SPI_PXA2XX_PCI is not set
# CONFIG_SPI_SC18IS602 is not set
# CONFIG_SPI_TOPCLIFF_PCH is not set
CONFIG_SPI_XCOMM=m
# CONFIG_SPI_XILINX is not set
CONFIG_SPI_DESIGNWARE=m
CONFIG_SPI_DW_PCI=m
# CONFIG_SPI_DW_MID_DMA is not set

#
# SPI Protocol Masters
#
# CONFIG_SPI_SPIDEV is not set
# CONFIG_SPI_TLE62X0 is not set
# CONFIG_HSI is not set

#
# PPS support
#
CONFIG_PPS=m
# CONFIG_PPS_DEBUG is not set

#
# PPS clients support
#
# CONFIG_PPS_CLIENT_KTIMER is not set
CONFIG_PPS_CLIENT_LDISC=m
# CONFIG_PPS_CLIENT_GPIO is not set

#
# PPS generators support
#

#
# PTP clock support
#
# CONFIG_PTP_1588_CLOCK is not set
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
# CONFIG_GPIOLIB is not set
CONFIG_W1=m
CONFIG_W1_CON=y

#
# 1-wire Bus Masters
#
# CONFIG_W1_MASTER_MATROX is not set
# CONFIG_W1_MASTER_DS2482 is not set
CONFIG_W1_MASTER_DS1WM=m
# CONFIG_HDQ_MASTER_OMAP is not set

#
# 1-wire Slaves
#
# CONFIG_W1_SLAVE_THERM is not set
CONFIG_W1_SLAVE_SMEM=m
CONFIG_W1_SLAVE_DS2408=m
CONFIG_W1_SLAVE_DS2423=m
# CONFIG_W1_SLAVE_DS2431 is not set
CONFIG_W1_SLAVE_DS2433=m
CONFIG_W1_SLAVE_DS2433_CRC=y
CONFIG_W1_SLAVE_DS2760=m
CONFIG_W1_SLAVE_DS2780=m
CONFIG_W1_SLAVE_DS2781=m
CONFIG_W1_SLAVE_DS28E04=m
CONFIG_W1_SLAVE_BQ27000=m
CONFIG_POWER_SUPPLY=y
CONFIG_POWER_SUPPLY_DEBUG=y
CONFIG_PDA_POWER=m
# CONFIG_WM831X_BACKUP is not set
# CONFIG_WM831X_POWER is not set
CONFIG_TEST_POWER=m
# CONFIG_BATTERY_DS2760 is not set
CONFIG_BATTERY_DS2780=m
# CONFIG_BATTERY_DS2781 is not set
# CONFIG_BATTERY_DS2782 is not set
# CONFIG_BATTERY_SBS is not set
CONFIG_BATTERY_BQ27x00=m
# CONFIG_BATTERY_BQ27X00_I2C is not set
CONFIG_BATTERY_BQ27X00_PLATFORM=y
CONFIG_BATTERY_MAX17040=m
# CONFIG_BATTERY_MAX17042 is not set
CONFIG_CHARGER_PCF50633=m
# CONFIG_CHARGER_MAX8903 is not set
# CONFIG_CHARGER_LP8727 is not set
CONFIG_CHARGER_SMB347=m
CONFIG_POWER_AVS=y
CONFIG_HWMON=m
CONFIG_HWMON_VID=m
CONFIG_HWMON_DEBUG_CHIP=y

#
# Native drivers
#
CONFIG_SENSORS_ABITUGURU=m
CONFIG_SENSORS_ABITUGURU3=m
CONFIG_SENSORS_AD7314=m
# CONFIG_SENSORS_AD7414 is not set
CONFIG_SENSORS_AD7418=m
CONFIG_SENSORS_ADCXX=m
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
CONFIG_SENSORS_ADM1026=m
# CONFIG_SENSORS_ADM1029 is not set
# CONFIG_SENSORS_ADM1031 is not set
CONFIG_SENSORS_ADM9240=m
# CONFIG_SENSORS_ADT7410 is not set
CONFIG_SENSORS_ADT7411=m
# CONFIG_SENSORS_ADT7462 is not set
CONFIG_SENSORS_ADT7470=m
# CONFIG_SENSORS_ADT7475 is not set
# CONFIG_SENSORS_ASC7621 is not set
CONFIG_SENSORS_K8TEMP=m
CONFIG_SENSORS_K10TEMP=m
# CONFIG_SENSORS_FAM15H_POWER is not set
CONFIG_SENSORS_ASB100=m
CONFIG_SENSORS_ATXP1=m
CONFIG_SENSORS_DS620=m
CONFIG_SENSORS_DS1621=m
# CONFIG_SENSORS_I5K_AMB is not set
# CONFIG_SENSORS_F71805F is not set
CONFIG_SENSORS_F71882FG=m
CONFIG_SENSORS_F75375S=m
# CONFIG_SENSORS_FSCHMD is not set
# CONFIG_SENSORS_G760A is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_GL520SM is not set
# CONFIG_SENSORS_HIH6130 is not set
# CONFIG_SENSORS_CORETEMP is not set
# CONFIG_SENSORS_IBMAEM is not set
CONFIG_SENSORS_IBMPEX=m
CONFIG_SENSORS_IT87=m
CONFIG_SENSORS_JC42=m
# CONFIG_SENSORS_LINEAGE is not set
CONFIG_SENSORS_LM63=m
# CONFIG_SENSORS_LM70 is not set
CONFIG_SENSORS_LM73=m
# CONFIG_SENSORS_LM75 is not set
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM80 is not set
CONFIG_SENSORS_LM83=m
CONFIG_SENSORS_LM85=m
# CONFIG_SENSORS_LM87 is not set
# CONFIG_SENSORS_LM90 is not set
CONFIG_SENSORS_LM92=m
# CONFIG_SENSORS_LM93 is not set
# CONFIG_SENSORS_LTC4151 is not set
# CONFIG_SENSORS_LTC4215 is not set
CONFIG_SENSORS_LTC4245=m
# CONFIG_SENSORS_LTC4261 is not set
# CONFIG_SENSORS_LM95241 is not set
# CONFIG_SENSORS_LM95245 is not set
# CONFIG_SENSORS_MAX1111 is not set
CONFIG_SENSORS_MAX16065=m
CONFIG_SENSORS_MAX1619=m
# CONFIG_SENSORS_MAX1668 is not set
CONFIG_SENSORS_MAX197=m
# CONFIG_SENSORS_MAX6639 is not set
# CONFIG_SENSORS_MAX6642 is not set
CONFIG_SENSORS_MAX6650=m
CONFIG_SENSORS_MCP3021=m
CONFIG_SENSORS_NTC_THERMISTOR=m
# CONFIG_SENSORS_PC87360 is not set
CONFIG_SENSORS_PC87427=m
CONFIG_SENSORS_PCF8591=m
# CONFIG_PMBUS is not set
CONFIG_SENSORS_SHT21=m
# CONFIG_SENSORS_SIS5595 is not set
CONFIG_SENSORS_SMM665=m
# CONFIG_SENSORS_DME1737 is not set
CONFIG_SENSORS_EMC1403=m
CONFIG_SENSORS_EMC2103=m
# CONFIG_SENSORS_EMC6W201 is not set
CONFIG_SENSORS_SMSC47M1=m
# CONFIG_SENSORS_SMSC47M192 is not set
# CONFIG_SENSORS_SMSC47B397 is not set
CONFIG_SENSORS_SCH56XX_COMMON=m
CONFIG_SENSORS_SCH5627=m
# CONFIG_SENSORS_SCH5636 is not set
CONFIG_SENSORS_ADS1015=m
CONFIG_SENSORS_ADS7828=m
# CONFIG_SENSORS_ADS7871 is not set
CONFIG_SENSORS_AMC6821=m
CONFIG_SENSORS_INA2XX=m
# CONFIG_SENSORS_THMC50 is not set
CONFIG_SENSORS_TMP102=m
CONFIG_SENSORS_TMP401=m
# CONFIG_SENSORS_TMP421 is not set
CONFIG_SENSORS_VIA_CPUTEMP=m
# CONFIG_SENSORS_VIA686A is not set
# CONFIG_SENSORS_VT1211 is not set
CONFIG_SENSORS_VT8231=m
CONFIG_SENSORS_W83781D=m
# CONFIG_SENSORS_W83791D is not set
CONFIG_SENSORS_W83792D=m
CONFIG_SENSORS_W83793=m
CONFIG_SENSORS_W83795=m
# CONFIG_SENSORS_W83795_FANCTRL is not set
# CONFIG_SENSORS_W83L785TS is not set
CONFIG_SENSORS_W83L786NG=m
CONFIG_SENSORS_W83627HF=m
# CONFIG_SENSORS_W83627EHF is not set
# CONFIG_SENSORS_WM831X is not set
CONFIG_SENSORS_APPLESMC=m
CONFIG_SENSORS_MC13783_ADC=m

#
# ACPI drivers
#
CONFIG_SENSORS_ACPI_POWER=m
# CONFIG_SENSORS_ATK0110 is not set
CONFIG_THERMAL=m
CONFIG_THERMAL_HWMON=y
CONFIG_FAIR_SHARE=y
CONFIG_STEP_WISE=y
CONFIG_USER_SPACE=y
# CONFIG_THERMAL_DEFAULT_GOV_STEP_WISE is not set
# CONFIG_THERMAL_DEFAULT_GOV_FAIR_SHARE is not set
CONFIG_THERMAL_DEFAULT_GOV_USER_SPACE=y
CONFIG_WATCHDOG=y
CONFIG_WATCHDOG_CORE=y
CONFIG_WATCHDOG_NOWAYOUT=y

#
# Watchdog Device Drivers
#
# CONFIG_SOFT_WATCHDOG is not set
# CONFIG_WM831X_WATCHDOG is not set
CONFIG_ACQUIRE_WDT=m
CONFIG_ADVANTECH_WDT=m
CONFIG_ALIM1535_WDT=m
CONFIG_ALIM7101_WDT=m
CONFIG_F71808E_WDT=m
# CONFIG_SP5100_TCO is not set
CONFIG_SC520_WDT=m
# CONFIG_SBC_FITPC2_WATCHDOG is not set
# CONFIG_EUROTECH_WDT is not set
CONFIG_IB700_WDT=m
CONFIG_IBMASR=m
CONFIG_WAFER_WDT=m
# CONFIG_I6300ESB_WDT is not set
# CONFIG_IE6XX_WDT is not set
# CONFIG_ITCO_WDT is not set
CONFIG_IT8712F_WDT=m
CONFIG_IT87_WDT=m
CONFIG_HP_WATCHDOG=m
CONFIG_HPWDT_NMI_DECODING=y
# CONFIG_SC1200_WDT is not set
CONFIG_PC87413_WDT=m
# CONFIG_NV_TCO is not set
# CONFIG_60XX_WDT is not set
CONFIG_SBC8360_WDT=m
CONFIG_CPU5_WDT=m
CONFIG_SMSC_SCH311X_WDT=m
CONFIG_SMSC37B787_WDT=m
CONFIG_VIA_WDT=m
# CONFIG_W83627HF_WDT is not set
CONFIG_W83697HF_WDT=m
CONFIG_W83697UG_WDT=m
# CONFIG_W83877F_WDT is not set
# CONFIG_W83977F_WDT is not set
CONFIG_MACHZ_WDT=m
CONFIG_SBC_EPX_C3_WATCHDOG=m
# CONFIG_XEN_WDT is not set

#
# PCI-based Watchdog Cards
#
CONFIG_PCIPCWATCHDOG=m
# CONFIG_WDTPCI is not set
CONFIG_SSB_POSSIBLE=y

#
# Sonics Silicon Backplane
#
CONFIG_SSB=m
CONFIG_SSB_PCIHOST_POSSIBLE=y
# CONFIG_SSB_PCIHOST is not set
CONFIG_SSB_DEBUG=y
CONFIG_BCMA_POSSIBLE=y

#
# Broadcom specific AMBA
#
# CONFIG_BCMA is not set

#
# Multifunction device drivers
#
CONFIG_MFD_CORE=y
# CONFIG_MFD_SM501 is not set
# CONFIG_HTC_PASIC3 is not set
CONFIG_MFD_LM3533=m
CONFIG_TPS6105X=m
CONFIG_TPS6507X=m
CONFIG_MFD_TPS65217=m
CONFIG_MFD_STMPE=y

#
# STMPE Interface Drivers
#
CONFIG_STMPE_SPI=y
# CONFIG_MFD_TMIO is not set
# CONFIG_MFD_DA9052_SPI is not set
# CONFIG_MFD_ARIZONA_I2C is not set
# CONFIG_MFD_ARIZONA_SPI is not set
CONFIG_MFD_WM831X=y
CONFIG_MFD_WM831X_SPI=y
CONFIG_MFD_PCF50633=m
# CONFIG_PCF50633_ADC is not set
CONFIG_PCF50633_GPIO=m
CONFIG_MFD_MC13783=m
CONFIG_MFD_MC13XXX=m
CONFIG_MFD_MC13XXX_SPI=m
# CONFIG_MFD_MC13XXX_I2C is not set
# CONFIG_ABX500_CORE is not set
CONFIG_EZX_PCAP=y
CONFIG_MFD_CS5535=m
CONFIG_LPC_SCH=m
CONFIG_LPC_ICH=m
CONFIG_MFD_RDC321X=m
# CONFIG_MFD_JANZ_CMODIO is not set
# CONFIG_MFD_VX855 is not set
CONFIG_MFD_WL1273_CORE=m
CONFIG_REGULATOR=y
CONFIG_REGULATOR_DEBUG=y
# CONFIG_REGULATOR_DUMMY is not set
CONFIG_REGULATOR_FIXED_VOLTAGE=m
CONFIG_REGULATOR_VIRTUAL_CONSUMER=m
CONFIG_REGULATOR_USERSPACE_CONSUMER=m
# CONFIG_REGULATOR_AD5398 is not set
CONFIG_REGULATOR_FAN53555=m
CONFIG_REGULATOR_MC13XXX_CORE=m
# CONFIG_REGULATOR_MC13783 is not set
CONFIG_REGULATOR_MC13892=m
# CONFIG_REGULATOR_ISL6271A is not set
CONFIG_REGULATOR_MAX1586=m
CONFIG_REGULATOR_MAX8649=m
CONFIG_REGULATOR_MAX8660=m
# CONFIG_REGULATOR_MAX8952 is not set
CONFIG_REGULATOR_PCAP=m
CONFIG_REGULATOR_LP3971=m
# CONFIG_REGULATOR_LP3972 is not set
# CONFIG_REGULATOR_PCF50633 is not set
CONFIG_REGULATOR_TPS51632=m
CONFIG_REGULATOR_TPS6105X=m
# CONFIG_REGULATOR_TPS62360 is not set
CONFIG_REGULATOR_TPS65023=m
CONFIG_REGULATOR_TPS6507X=m
# CONFIG_REGULATOR_TPS65217 is not set
# CONFIG_REGULATOR_TPS6524X is not set
CONFIG_REGULATOR_WM831X=m
# CONFIG_MEDIA_SUPPORT is not set

#
# Graphics support
#
CONFIG_AGP=m
CONFIG_AGP_AMD64=m
# CONFIG_AGP_INTEL is not set
CONFIG_AGP_SIS=m
CONFIG_AGP_VIA=m
CONFIG_VGA_ARB=y
CONFIG_VGA_ARB_MAX_GPUS=16
# CONFIG_VGA_SWITCHEROO is not set
CONFIG_DRM=m
CONFIG_DRM_KMS_HELPER=m
# CONFIG_DRM_LOAD_EDID_FIRMWARE is not set
CONFIG_DRM_TTM=m
CONFIG_DRM_TDFX=m
# CONFIG_DRM_R128 is not set
CONFIG_DRM_RADEON=m
# CONFIG_DRM_RADEON_KMS is not set
# CONFIG_DRM_NOUVEAU is not set

#
# I2C encoder or helper chips
#
# CONFIG_DRM_I2C_CH7006 is not set
# CONFIG_DRM_I2C_SIL164 is not set
# CONFIG_DRM_MGA is not set
CONFIG_DRM_SIS=m
# CONFIG_DRM_VIA is not set
# CONFIG_DRM_SAVAGE is not set
CONFIG_DRM_VMWGFX=m
# CONFIG_DRM_VMWGFX_FBCON is not set
CONFIG_DRM_GMA500=m
CONFIG_DRM_GMA600=y
# CONFIG_DRM_GMA3600 is not set
CONFIG_DRM_AST=m
# CONFIG_DRM_MGAG200 is not set
CONFIG_DRM_CIRRUS_QEMU=m
# CONFIG_STUB_POULSBO is not set
CONFIG_VGASTATE=m
CONFIG_VIDEO_OUTPUT_CONTROL=m
CONFIG_FB=m
CONFIG_FIRMWARE_EDID=y
CONFIG_FB_DDC=m
# CONFIG_FB_BOOT_VESA_SUPPORT is not set
CONFIG_FB_CFB_FILLRECT=m
CONFIG_FB_CFB_COPYAREA=m
CONFIG_FB_CFB_IMAGEBLIT=m
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
CONFIG_FB_SYS_FILLRECT=m
CONFIG_FB_SYS_COPYAREA=m
CONFIG_FB_SYS_IMAGEBLIT=m
# CONFIG_FB_FOREIGN_ENDIAN is not set
CONFIG_FB_SYS_FOPS=m
# CONFIG_FB_WMT_GE_ROPS is not set
CONFIG_FB_DEFERRED_IO=y
CONFIG_FB_SVGALIB=m
# CONFIG_FB_MACMODES is not set
CONFIG_FB_BACKLIGHT=y
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y

#
# Frame buffer hardware drivers
#
CONFIG_FB_CIRRUS=m
CONFIG_FB_PM2=m
CONFIG_FB_PM2_FIFO_DISCONNECT=y
# CONFIG_FB_CYBER2000 is not set
CONFIG_FB_ARC=m
# CONFIG_FB_VGA16 is not set
CONFIG_FB_UVESA=m
# CONFIG_FB_N411 is not set
# CONFIG_FB_HGA is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_NVIDIA is not set
CONFIG_FB_RIVA=m
CONFIG_FB_RIVA_I2C=y
# CONFIG_FB_RIVA_DEBUG is not set
# CONFIG_FB_RIVA_BACKLIGHT is not set
CONFIG_FB_I740=m
# CONFIG_FB_LE80578 is not set
# CONFIG_FB_MATROX is not set
CONFIG_FB_RADEON=m
CONFIG_FB_RADEON_I2C=y
CONFIG_FB_RADEON_BACKLIGHT=y
# CONFIG_FB_RADEON_DEBUG is not set
# CONFIG_FB_ATY128 is not set
CONFIG_FB_ATY=m
CONFIG_FB_ATY_CT=y
# CONFIG_FB_ATY_GENERIC_LCD is not set
CONFIG_FB_ATY_GX=y
# CONFIG_FB_ATY_BACKLIGHT is not set
# CONFIG_FB_S3 is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_VIA is not set
# CONFIG_FB_NEOMAGIC is not set
CONFIG_FB_KYRO=m
CONFIG_FB_3DFX=m
# CONFIG_FB_3DFX_ACCEL is not set
# CONFIG_FB_3DFX_I2C is not set
CONFIG_FB_VOODOO1=m
CONFIG_FB_VT8623=m
# CONFIG_FB_TRIDENT is not set
CONFIG_FB_ARK=m
CONFIG_FB_PM3=m
CONFIG_FB_CARMINE=m
CONFIG_FB_CARMINE_DRAM_EVAL=y
# CONFIG_CARMINE_DRAM_CUSTOM is not set
# CONFIG_FB_GEODE is not set
CONFIG_FB_TMIO=m
CONFIG_FB_TMIO_ACCELL=y
# CONFIG_FB_VIRTUAL is not set
CONFIG_XEN_FBDEV_FRONTEND=m
# CONFIG_FB_METRONOME is not set
CONFIG_FB_MB862XX=m
CONFIG_FB_MB862XX_PCI_GDC=y
# CONFIG_FB_MB862XX_I2C is not set
# CONFIG_FB_BROADSHEET is not set
# CONFIG_FB_AUO_K190X is not set
# CONFIG_EXYNOS_VIDEO is not set
CONFIG_BACKLIGHT_LCD_SUPPORT=y
# CONFIG_LCD_CLASS_DEVICE is not set
CONFIG_BACKLIGHT_CLASS_DEVICE=m
# CONFIG_BACKLIGHT_GENERIC is not set
CONFIG_BACKLIGHT_LM3533=m
# CONFIG_BACKLIGHT_PWM is not set
# CONFIG_BACKLIGHT_APPLE is not set
CONFIG_BACKLIGHT_SAHARA=m
# CONFIG_BACKLIGHT_WM831X is not set
# CONFIG_BACKLIGHT_ADP8860 is not set
# CONFIG_BACKLIGHT_ADP8870 is not set
CONFIG_BACKLIGHT_PCF50633=m
CONFIG_BACKLIGHT_LM3630=m
# CONFIG_BACKLIGHT_LM3639 is not set
CONFIG_BACKLIGHT_LP855X=m
CONFIG_BACKLIGHT_TPS65217=m

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_VGACON_SOFT_SCROLLBACK=y
CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=m
CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
# CONFIG_LOGO is not set
# CONFIG_SOUND is not set

#
# HID support
#
# CONFIG_HID is not set
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB_ARCH_HAS_XHCI=y
# CONFIG_USB_SUPPORT is not set
CONFIG_UWB=m
CONFIG_UWB_WHCI=m
# CONFIG_MMC is not set
CONFIG_MEMSTICK=m
CONFIG_MEMSTICK_DEBUG=y

#
# MemoryStick drivers
#
# CONFIG_MEMSTICK_UNSAFE_RESUME is not set
CONFIG_MSPRO_BLOCK=m
CONFIG_MS_BLOCK=m

#
# MemoryStick Host Controller Drivers
#
# CONFIG_MEMSTICK_TIFM_MS is not set
# CONFIG_MEMSTICK_JMICRON_38X is not set
CONFIG_MEMSTICK_R592=m
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=m

#
# LED drivers
#
# CONFIG_LEDS_LM3530 is not set
CONFIG_LEDS_LM3533=m
# CONFIG_LEDS_LM3642 is not set
# CONFIG_LEDS_PCA9532 is not set
# CONFIG_LEDS_LP3944 is not set
# CONFIG_LEDS_LP5521 is not set
CONFIG_LEDS_LP5523=m
CONFIG_LEDS_CLEVO_MAIL=m
CONFIG_LEDS_PCA955X=m
# CONFIG_LEDS_PCA9633 is not set
CONFIG_LEDS_WM831X_STATUS=m
# CONFIG_LEDS_DAC124S085 is not set
# CONFIG_LEDS_REGULATOR is not set
# CONFIG_LEDS_BD2802 is not set
# CONFIG_LEDS_INTEL_SS4200 is not set
# CONFIG_LEDS_MC13783 is not set
CONFIG_LEDS_TCA6507=m
CONFIG_LEDS_LM355x=m
CONFIG_LEDS_OT200=m
CONFIG_LEDS_BLINKM=m
CONFIG_LEDS_TRIGGERS=y

#
# LED Triggers
#
CONFIG_LEDS_TRIGGER_TIMER=m
CONFIG_LEDS_TRIGGER_ONESHOT=m
# CONFIG_LEDS_TRIGGER_HEARTBEAT is not set
# CONFIG_LEDS_TRIGGER_BACKLIGHT is not set
CONFIG_LEDS_TRIGGER_CPU=y
CONFIG_LEDS_TRIGGER_DEFAULT_ON=m

#
# iptables trigger is under Netfilter config (LED target)
#
# CONFIG_LEDS_TRIGGER_TRANSIENT is not set
# CONFIG_ACCESSIBILITY is not set
# CONFIG_INFINIBAND is not set
CONFIG_EDAC=y

#
# Reporting subsystems
#
# CONFIG_EDAC_LEGACY_SYSFS is not set
# CONFIG_EDAC_DEBUG is not set
CONFIG_EDAC_DECODE_MCE=m
# CONFIG_EDAC_MCE_INJ is not set
# CONFIG_EDAC_MM_EDAC is not set
# CONFIG_RTC_CLASS is not set
CONFIG_DMADEVICES=y
CONFIG_DMADEVICES_DEBUG=y
CONFIG_DMADEVICES_VDEBUG=y

#
# DMA Devices
#
CONFIG_INTEL_MID_DMAC=m
CONFIG_INTEL_IOATDMA=m
CONFIG_TIMB_DMA=m
CONFIG_PCH_DMA=m
CONFIG_DMA_ENGINE=y

#
# DMA Clients
#
# CONFIG_NET_DMA is not set
# CONFIG_ASYNC_TX_DMA is not set
CONFIG_DMATEST=m
CONFIG_DCA=m
CONFIG_AUXDISPLAY=y
CONFIG_UIO=m
# CONFIG_UIO_CIF is not set
CONFIG_UIO_PDRV=m
# CONFIG_UIO_PDRV_GENIRQ is not set
CONFIG_UIO_AEC=m
# CONFIG_UIO_SERCOS3 is not set
CONFIG_UIO_PCI_GENERIC=m
CONFIG_UIO_NETX=m
CONFIG_VIRTIO=y

#
# Virtio drivers
#
CONFIG_VIRTIO_PCI=y
# CONFIG_VIRTIO_BALLOON is not set
CONFIG_VIRTIO_MMIO=m
# CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES is not set

#
# Microsoft Hyper-V guest support
#
# CONFIG_HYPERV is not set

#
# Xen driver support
#
CONFIG_XEN_BALLOON=y
# CONFIG_XEN_SCRUB_PAGES is not set
CONFIG_XEN_DEV_EVTCHN=m
# CONFIG_XEN_BACKEND is not set
CONFIG_XENFS=m
# CONFIG_XEN_COMPAT_XENFS is not set
CONFIG_XEN_SYS_HYPERVISOR=y
CONFIG_XEN_XENBUS_FRONTEND=m
# CONFIG_XEN_GNTDEV is not set
CONFIG_XEN_GRANT_DEV_ALLOC=m
CONFIG_SWIOTLB_XEN=y
CONFIG_XEN_PRIVCMD=m
# CONFIG_XEN_MCE_LOG is not set
CONFIG_STAGING=y
# CONFIG_ET131X is not set
# CONFIG_SLICOSS is not set
CONFIG_ECHO=m
CONFIG_COMEDI=m
# CONFIG_COMEDI_DEBUG is not set
CONFIG_COMEDI_DEFAULT_BUF_SIZE_KB=2048
CONFIG_COMEDI_DEFAULT_BUF_MAXSIZE_KB=20480
# CONFIG_COMEDI_MISC_DRIVERS is not set
# CONFIG_COMEDI_PCI_DRIVERS is not set
CONFIG_COMEDI_8255=m
# CONFIG_RTS_PSTOR is not set
# CONFIG_DX_SEP is not set
# CONFIG_ZRAM is not set
CONFIG_ZSMALLOC=m
# CONFIG_FB_SM7XX is not set
# CONFIG_CRYSTALHD is not set
# CONFIG_FB_XGI is not set
# CONFIG_ACPI_QUICKSTART is not set
# CONFIG_FT1000 is not set

#
# Speakup console speech
#
# CONFIG_SPEAKUP is not set
CONFIG_TOUCHSCREEN_SYNAPTICS_I2C_RMI4=m
# CONFIG_STAGING_MEDIA is not set

#
# Android
#
CONFIG_ANDROID=y
# CONFIG_ANDROID_BINDER_IPC is not set
CONFIG_ASHMEM=y
# CONFIG_ANDROID_LOGGER is not set
CONFIG_ANDROID_TIMED_OUTPUT=y
# CONFIG_ANDROID_LOW_MEMORY_KILLER is not set
# CONFIG_PHONE is not set
CONFIG_IPACK_BUS=m
CONFIG_BOARD_TPCI200=m
# CONFIG_SERIAL_IPOCTAL is not set
CONFIG_WIMAX_GDM72XX=m
# CONFIG_WIMAX_GDM72XX_QOS is not set
# CONFIG_WIMAX_GDM72XX_K_MODE is not set
# CONFIG_WIMAX_GDM72XX_WIMAX2 is not set
CONFIG_NET_VENDOR_SILICOM=y
CONFIG_SBYPASS=m
# CONFIG_BPCTL is not set
# CONFIG_X86_PLATFORM_DEVICES is not set

#
# Hardware Spinlock drivers
#
CONFIG_CLKEVT_I8253=y
CONFIG_I8253_LOCK=y
CONFIG_CLKBLD_I8253=y
# CONFIG_IOMMU_SUPPORT is not set

#
# Remoteproc drivers (EXPERIMENTAL)
#
# CONFIG_STE_MODEM_RPROC is not set

#
# Rpmsg drivers (EXPERIMENTAL)
#
# CONFIG_VIRT_DRIVERS is not set
CONFIG_PM_DEVFREQ=y

#
# DEVFREQ Governors
#
CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND=y
CONFIG_DEVFREQ_GOV_PERFORMANCE=y
# CONFIG_DEVFREQ_GOV_POWERSAVE is not set
CONFIG_DEVFREQ_GOV_USERSPACE=y

#
# DEVFREQ Drivers
#
CONFIG_EXTCON=m

#
# Extcon Device Drivers
#
CONFIG_MEMORY=y
# CONFIG_IIO is not set
# CONFIG_VME_BUS is not set
CONFIG_PWM=y

#
# Firmware Drivers
#
CONFIG_EDD=m
# CONFIG_EDD_OFF is not set
CONFIG_FIRMWARE_MEMMAP=y
# CONFIG_DELL_RBU is not set
CONFIG_DCDBAS=m
# CONFIG_DMIID is not set
# CONFIG_DMI_SYSFS is not set
# CONFIG_ISCSI_IBFT_FIND is not set
CONFIG_GOOGLE_FIRMWARE=y

#
# Google Firmware Drivers
#
# CONFIG_GOOGLE_SMI is not set
# CONFIG_GOOGLE_MEMCONSOLE is not set

#
# File systems
#
CONFIG_DCACHE_WORD_ACCESS=y
CONFIG_EXT2_FS=m
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
# CONFIG_EXT2_FS_SECURITY is not set
CONFIG_EXT2_FS_XIP=y
CONFIG_EXT3_FS=m
CONFIG_EXT3_DEFAULTS_TO_ORDERED=y
# CONFIG_EXT3_FS_XATTR is not set
CONFIG_EXT4_FS=m
CONFIG_EXT4_FS_XATTR=y
CONFIG_EXT4_FS_POSIX_ACL=y
CONFIG_EXT4_FS_SECURITY=y
CONFIG_EXT4_DEBUG=y
CONFIG_FS_XIP=y
CONFIG_JBD=m
# CONFIG_JBD_DEBUG is not set
CONFIG_JBD2=m
# CONFIG_JBD2_DEBUG is not set
CONFIG_FS_MBCACHE=m
CONFIG_REISERFS_FS=m
# CONFIG_REISERFS_CHECK is not set
CONFIG_REISERFS_PROC_INFO=y
# CONFIG_REISERFS_FS_XATTR is not set
CONFIG_JFS_FS=m
# CONFIG_JFS_POSIX_ACL is not set
CONFIG_JFS_SECURITY=y
# CONFIG_JFS_DEBUG is not set
CONFIG_JFS_STATISTICS=y
# CONFIG_XFS_FS is not set
CONFIG_GFS2_FS=m
# CONFIG_GFS2_FS_LOCKING_DLM is not set
CONFIG_OCFS2_FS=m
# CONFIG_OCFS2_FS_O2CB is not set
# CONFIG_OCFS2_FS_USERSPACE_CLUSTER is not set
CONFIG_OCFS2_FS_STATS=y
# CONFIG_OCFS2_DEBUG_MASKLOG is not set
CONFIG_OCFS2_DEBUG_FS=y
# CONFIG_BTRFS_FS is not set
# CONFIG_NILFS2_FS is not set
CONFIG_FS_POSIX_ACL=y
CONFIG_EXPORTFS=m
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
# CONFIG_DNOTIFY is not set
CONFIG_INOTIFY_USER=y
# CONFIG_FANOTIFY is not set
CONFIG_QUOTA=y
# CONFIG_QUOTA_NETLINK_INTERFACE is not set
# CONFIG_PRINT_QUOTA_WARNING is not set
CONFIG_QUOTA_DEBUG=y
CONFIG_QUOTA_TREE=m
# CONFIG_QFMT_V1 is not set
CONFIG_QFMT_V2=m
CONFIG_QUOTACTL=y
# CONFIG_AUTOFS4_FS is not set
CONFIG_FUSE_FS=m
CONFIG_CUSE=m

#
# Caches
#
CONFIG_FSCACHE=m
CONFIG_FSCACHE_STATS=y
# CONFIG_FSCACHE_HISTOGRAM is not set
# CONFIG_FSCACHE_DEBUG is not set
CONFIG_FSCACHE_OBJECT_LIST=y
# CONFIG_CACHEFILES is not set

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
CONFIG_UDF_FS=m
CONFIG_UDF_NLS=y

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=m
# CONFIG_MSDOS_FS is not set
CONFIG_VFAT_FS=m
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
# CONFIG_PROC_KCORE is not set
# CONFIG_PROC_VMCORE is not set
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_TMPFS_XATTR is not set
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
CONFIG_CONFIGFS_FS=m
CONFIG_MISC_FILESYSTEMS=y
CONFIG_ADFS_FS=m
CONFIG_ADFS_FS_RW=y
CONFIG_AFFS_FS=m
# CONFIG_ECRYPT_FS is not set
# CONFIG_HFS_FS is not set
CONFIG_HFSPLUS_FS=m
# CONFIG_BEFS_FS is not set
CONFIG_BFS_FS=m
CONFIG_EFS_FS=m
CONFIG_LOGFS=m
CONFIG_CRAMFS=m
# CONFIG_SQUASHFS is not set
CONFIG_VXFS_FS=m
CONFIG_MINIX_FS=m
CONFIG_OMFS_FS=m
# CONFIG_HPFS_FS is not set
CONFIG_QNX4FS_FS=m
# CONFIG_QNX6FS_FS is not set
CONFIG_ROMFS_FS=m
CONFIG_ROMFS_BACKED_BY_BLOCK=y
CONFIG_ROMFS_ON_BLOCK=y
CONFIG_PSTORE=y
# CONFIG_PSTORE_CONSOLE is not set
# CONFIG_PSTORE_RAM is not set
CONFIG_SYSV_FS=m
CONFIG_UFS_FS=m
# CONFIG_UFS_FS_WRITE is not set
# CONFIG_UFS_DEBUG is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=m
CONFIG_NFS_V2=m
# CONFIG_NFS_V3 is not set
# CONFIG_NFS_V4 is not set
CONFIG_NFS_SWAP=y
# CONFIG_NFS_FSCACHE is not set
CONFIG_NFS_DEBUG=y
CONFIG_NFSD=m
CONFIG_NFSD_V3=y
# CONFIG_NFSD_V3_ACL is not set
# CONFIG_NFSD_V4 is not set
CONFIG_LOCKD=m
CONFIG_LOCKD_V4=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=m
CONFIG_SUNRPC_SWAP=y
CONFIG_SUNRPC_DEBUG=y
CONFIG_CEPH_FS=m
CONFIG_CIFS=m
# CONFIG_CIFS_STATS is not set
CONFIG_CIFS_WEAK_PW_HASH=y
CONFIG_CIFS_UPCALL=y
# CONFIG_CIFS_XATTR is not set
CONFIG_CIFS_DEBUG2=y
# CONFIG_CIFS_DFS_UPCALL is not set
CONFIG_CIFS_SMB2=y
CONFIG_CIFS_FSCACHE=y
CONFIG_NCP_FS=m
CONFIG_NCPFS_PACKET_SIGNING=y
CONFIG_NCPFS_IOCTL_LOCKING=y
# CONFIG_NCPFS_STRONG is not set
CONFIG_NCPFS_NFS_NS=y
# CONFIG_NCPFS_OS2_NS is not set
CONFIG_NCPFS_SMALLDOS=y
CONFIG_NCPFS_NLS=y
CONFIG_NCPFS_EXTRAS=y
CONFIG_CODA_FS=m
# CONFIG_AFS_FS is not set
CONFIG_9P_FS=y
# CONFIG_9P_FS_POSIX_ACL is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
# CONFIG_NLS_CODEPAGE_437 is not set
CONFIG_NLS_CODEPAGE_737=m
CONFIG_NLS_CODEPAGE_775=m
CONFIG_NLS_CODEPAGE_850=m
# CONFIG_NLS_CODEPAGE_852 is not set
CONFIG_NLS_CODEPAGE_855=m
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
CONFIG_NLS_CODEPAGE_861=m
CONFIG_NLS_CODEPAGE_862=m
CONFIG_NLS_CODEPAGE_863=m
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
CONFIG_NLS_CODEPAGE_869=m
CONFIG_NLS_CODEPAGE_936=m
# CONFIG_NLS_CODEPAGE_950 is not set
CONFIG_NLS_CODEPAGE_932=m
CONFIG_NLS_CODEPAGE_949=m
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=m
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
CONFIG_NLS_ISO8859_4=m
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
CONFIG_NLS_ISO8859_7=m
CONFIG_NLS_ISO8859_9=m
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=m
# CONFIG_NLS_KOI8_R is not set
CONFIG_NLS_KOI8_U=m
# CONFIG_NLS_MAC_ROMAN is not set
# CONFIG_NLS_MAC_CELTIC is not set
CONFIG_NLS_MAC_CENTEURO=m
# CONFIG_NLS_MAC_CROATIAN is not set
# CONFIG_NLS_MAC_CYRILLIC is not set
CONFIG_NLS_MAC_GAELIC=m
# CONFIG_NLS_MAC_GREEK is not set
CONFIG_NLS_MAC_ICELAND=m
CONFIG_NLS_MAC_INUIT=m
CONFIG_NLS_MAC_ROMANIAN=m
# CONFIG_NLS_MAC_TURKISH is not set
CONFIG_NLS_UTF8=m
CONFIG_DLM=m
# CONFIG_DLM_DEBUG is not set

#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
# CONFIG_PRINTK_TIME is not set
CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4
CONFIG_ENABLE_WARN_DEPRECATED=y
# CONFIG_ENABLE_MUST_CHECK is not set
CONFIG_FRAME_WARN=2048
CONFIG_MAGIC_SYSRQ=y
# CONFIG_STRIP_ASM_SYMS is not set
# CONFIG_READABLE_ASM is not set
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_FS=y
CONFIG_HEADERS_CHECK=y
CONFIG_DEBUG_SECTION_MISMATCH=y
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
CONFIG_LOCKUP_DETECTOR=y
CONFIG_HARDLOCKUP_DETECTOR=y
CONFIG_BOOTPARAM_HARDLOCKUP_PANIC=y
CONFIG_BOOTPARAM_HARDLOCKUP_PANIC_VALUE=1
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC=y
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=1
# CONFIG_PANIC_ON_OOPS is not set
CONFIG_PANIC_ON_OOPS_VALUE=0
# CONFIG_DETECT_HUNG_TASK is not set
CONFIG_SCHED_DEBUG=y
CONFIG_SCHEDSTATS=y
CONFIG_TIMER_STATS=y
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_SLUB_STATS is not set
CONFIG_HAVE_DEBUG_KMEMLEAK=y
# CONFIG_DEBUG_KMEMLEAK is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
CONFIG_RT_MUTEX_TESTER=y
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_LOCK_ALLOC=y
# CONFIG_PROVE_LOCKING is not set
CONFIG_SPARSE_RCU_POINTER=y
CONFIG_LOCKDEP=y
# CONFIG_LOCK_STAT is not set
CONFIG_DEBUG_LOCKDEP=y
CONFIG_DEBUG_ATOMIC_SLEEP=y
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
CONFIG_STACKTRACE=y
# CONFIG_DEBUG_STACK_USAGE is not set
CONFIG_DEBUG_KOBJECT=y
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_VM is not set
CONFIG_DEBUG_VIRTUAL=y
CONFIG_DEBUG_WRITECOUNT=y
CONFIG_DEBUG_MEMORY_INIT=y
# CONFIG_DEBUG_LIST is not set
CONFIG_TEST_LIST_SORT=y
CONFIG_DEBUG_SG=y
CONFIG_DEBUG_NOTIFIERS=y
CONFIG_DEBUG_CREDENTIALS=y
CONFIG_ARCH_WANT_FRAME_POINTERS=y
CONFIG_FRAME_POINTER=y
# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_RCU_TRACE is not set
CONFIG_KPROBES_SANITY_TEST=y
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
CONFIG_LKDTM=m
CONFIG_NOTIFIER_ERROR_INJECTION=m
# CONFIG_PM_NOTIFIER_ERROR_INJECT is not set
CONFIG_FAULT_INJECTION=y
# CONFIG_FAILSLAB is not set
CONFIG_FAIL_PAGE_ALLOC=y
# CONFIG_FAIL_MAKE_REQUEST is not set
# CONFIG_FAIL_IO_TIMEOUT is not set
CONFIG_FAULT_INJECTION_DEBUG_FS=y
CONFIG_LATENCYTOP=y
CONFIG_USER_STACKTRACE_SUPPORT=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST=y
CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_HAVE_FENTRY=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_TRACING_SUPPORT=y
# CONFIG_FTRACE is not set
# CONFIG_RBTREE_TEST is not set
# CONFIG_INTERVAL_TREE_TEST is not set
# CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set
CONFIG_BUILD_DOCSRC=y
# CONFIG_DYNAMIC_DEBUG is not set
CONFIG_DMA_API_DEBUG=y
CONFIG_ATOMIC64_SELFTEST=y
CONFIG_SAMPLES=y
CONFIG_SAMPLE_KOBJECT=m
# CONFIG_SAMPLE_KPROBES is not set
CONFIG_SAMPLE_HW_BREAKPOINT=m
CONFIG_SAMPLE_KFIFO=m
CONFIG_HAVE_ARCH_KGDB=y
CONFIG_KGDB=y
CONFIG_KGDB_SERIAL_CONSOLE=y
CONFIG_KGDB_TESTS=y
CONFIG_KGDB_TESTS_ON_BOOT=y
CONFIG_KGDB_TESTS_BOOT_STRING="V1F100"
CONFIG_KGDB_LOW_LEVEL_TRAP=y
# CONFIG_KGDB_KDB is not set
CONFIG_HAVE_ARCH_KMEMCHECK=y
CONFIG_KMEMCHECK=y
# CONFIG_KMEMCHECK_DISABLED_BY_DEFAULT is not set
CONFIG_KMEMCHECK_ENABLED_BY_DEFAULT=y
# CONFIG_KMEMCHECK_ONESHOT_BY_DEFAULT is not set
CONFIG_KMEMCHECK_QUEUE_SIZE=64
CONFIG_KMEMCHECK_SHADOW_COPY_SHIFT=5
CONFIG_KMEMCHECK_PARTIAL_OK=y
CONFIG_KMEMCHECK_BITOPS_OK=y
CONFIG_TEST_KSTRTOX=m
# CONFIG_STRICT_DEVMEM is not set
# CONFIG_X86_VERBOSE_BOOTUP is not set
CONFIG_EARLY_PRINTK=y
CONFIG_EARLY_PRINTK_DBGP=y
CONFIG_DEBUG_STACKOVERFLOW=y
CONFIG_X86_PTDUMP=y
CONFIG_DEBUG_RODATA=y
CONFIG_DEBUG_RODATA_TEST=y
CONFIG_DEBUG_SET_MODULE_RONX=y
CONFIG_DEBUG_NX_TEST=m
CONFIG_DEBUG_TLBFLUSH=y
# CONFIG_IOMMU_DEBUG is not set
CONFIG_IOMMU_STRESS=y
CONFIG_HAVE_MMIOTRACE_SUPPORT=y
# CONFIG_X86_DECODER_SELFTEST is not set
CONFIG_IO_DELAY_TYPE_0X80=0
CONFIG_IO_DELAY_TYPE_0XED=1
CONFIG_IO_DELAY_TYPE_UDELAY=2
CONFIG_IO_DELAY_TYPE_NONE=3
# CONFIG_IO_DELAY_0X80 is not set
# CONFIG_IO_DELAY_0XED is not set
# CONFIG_IO_DELAY_UDELAY is not set
CONFIG_IO_DELAY_NONE=y
CONFIG_DEFAULT_IO_DELAY_TYPE=3
CONFIG_DEBUG_BOOT_PARAMS=y
CONFIG_CPA_DEBUG=y
# CONFIG_OPTIMIZE_INLINING is not set
# CONFIG_DEBUG_STRICT_USER_COPY_CHECKS is not set
CONFIG_DEBUG_NMI_SELFTEST=y

#
# Security options
#
CONFIG_KEYS=y
# CONFIG_TRUSTED_KEYS is not set
# CONFIG_ENCRYPTED_KEYS is not set
CONFIG_KEYS_DEBUG_PROC_KEYS=y
# CONFIG_SECURITY_DMESG_RESTRICT is not set
CONFIG_SECURITY=y
CONFIG_SECURITYFS=y
CONFIG_SECURITY_NETWORK=y
# CONFIG_SECURITY_NETWORK_XFRM is not set
CONFIG_SECURITY_PATH=y
# CONFIG_SECURITY_SELINUX is not set
# CONFIG_SECURITY_TOMOYO is not set
# CONFIG_SECURITY_APPARMOR is not set
CONFIG_SECURITY_YAMA=y
CONFIG_SECURITY_YAMA_STACKED=y
CONFIG_INTEGRITY=y
# CONFIG_INTEGRITY_SIGNATURE is not set
CONFIG_IMA=y
CONFIG_IMA_MEASURE_PCR_IDX=10
# CONFIG_IMA_AUDIT is not set
CONFIG_IMA_APPRAISE=y
# CONFIG_EVM is not set
CONFIG_DEFAULT_SECURITY_YAMA=y
# CONFIG_DEFAULT_SECURITY_DAC is not set
CONFIG_DEFAULT_SECURITY="yama"
CONFIG_ASYNC_TX_DISABLE_PQ_VAL_DMA=y
CONFIG_ASYNC_TX_DISABLE_XOR_VAL_DMA=y
CONFIG_CRYPTO=y

#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD=m
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=m
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG=m
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_PCOMP=m
CONFIG_CRYPTO_PCOMP2=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
CONFIG_CRYPTO_USER=m
CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
CONFIG_CRYPTO_GF128MUL=m
CONFIG_CRYPTO_NULL=m
CONFIG_CRYPTO_WORKQUEUE=y
CONFIG_CRYPTO_CRYPTD=m
CONFIG_CRYPTO_AUTHENC=m
# CONFIG_CRYPTO_TEST is not set
CONFIG_CRYPTO_ABLK_HELPER_X86=m
CONFIG_CRYPTO_GLUE_HELPER_X86=m

#
# Authenticated Encryption with Associated Data
#
# CONFIG_CRYPTO_CCM is not set
# CONFIG_CRYPTO_GCM is not set
CONFIG_CRYPTO_SEQIV=m

#
# Block modes
#
CONFIG_CRYPTO_CBC=m
CONFIG_CRYPTO_CTR=m
# CONFIG_CRYPTO_CTS is not set
CONFIG_CRYPTO_ECB=m
CONFIG_CRYPTO_LRW=m
# CONFIG_CRYPTO_PCBC is not set
CONFIG_CRYPTO_XTS=m

#
# Hash modes
#
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_XCBC=m
CONFIG_CRYPTO_VMAC=m

#
# Digest
#
CONFIG_CRYPTO_CRC32C=m
# CONFIG_CRYPTO_CRC32C_INTEL is not set
CONFIG_CRYPTO_GHASH=m
CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MD5=y
# CONFIG_CRYPTO_MICHAEL_MIC is not set
CONFIG_CRYPTO_RMD128=m
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
CONFIG_CRYPTO_RMD320=m
CONFIG_CRYPTO_SHA1=y
# CONFIG_CRYPTO_SHA1_SSSE3 is not set
CONFIG_CRYPTO_SHA256=m
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_WP512 is not set
CONFIG_CRYPTO_GHASH_CLMUL_NI_INTEL=m

#
# Ciphers
#
CONFIG_CRYPTO_AES=y
CONFIG_CRYPTO_AES_X86_64=m
CONFIG_CRYPTO_AES_NI_INTEL=m
# CONFIG_CRYPTO_ANUBIS is not set
CONFIG_CRYPTO_ARC4=m
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_BLOWFISH_X86_64 is not set
# CONFIG_CRYPTO_CAMELLIA is not set
CONFIG_CRYPTO_CAMELLIA_X86_64=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST5_AVX_X86_64=m
CONFIG_CRYPTO_CAST6=m
# CONFIG_CRYPTO_CAST6_AVX_X86_64 is not set
CONFIG_CRYPTO_DES=m
CONFIG_CRYPTO_FCRYPT=m
# CONFIG_CRYPTO_KHAZAD is not set
CONFIG_CRYPTO_SALSA20=m
CONFIG_CRYPTO_SALSA20_X86_64=m
CONFIG_CRYPTO_SEED=m
CONFIG_CRYPTO_SERPENT=m
# CONFIG_CRYPTO_SERPENT_SSE2_X86_64 is not set
# CONFIG_CRYPTO_SERPENT_AVX_X86_64 is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_TWOFISH_X86_64 is not set
# CONFIG_CRYPTO_TWOFISH_X86_64_3WAY is not set
# CONFIG_CRYPTO_TWOFISH_AVX_X86_64 is not set

#
# Compression
#
CONFIG_CRYPTO_DEFLATE=m
CONFIG_CRYPTO_ZLIB=m
CONFIG_CRYPTO_LZO=m

#
# Random Number Generation
#
CONFIG_CRYPTO_ANSI_CPRNG=m
CONFIG_CRYPTO_USER_API=m
CONFIG_CRYPTO_USER_API_HASH=m
# CONFIG_CRYPTO_USER_API_SKCIPHER is not set
# CONFIG_CRYPTO_HW is not set
# CONFIG_ASYMMETRIC_KEY_TYPE is not set
CONFIG_HAVE_KVM=y
CONFIG_VIRTUALIZATION=y
# CONFIG_KVM is not set
CONFIG_VHOST_NET=m
# CONFIG_BINARY_PRINTF is not set

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_GENERIC_STRNCPY_FROM_USER=y
CONFIG_GENERIC_STRNLEN_USER=y
CONFIG_GENERIC_FIND_FIRST_BIT=y
CONFIG_GENERIC_PCI_IOMAP=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_IO=y
CONFIG_CRC_CCITT=m
CONFIG_CRC16=m
CONFIG_CRC_T10DIF=m
CONFIG_CRC_ITU_T=m
CONFIG_CRC32=y
CONFIG_CRC32_SELFTEST=y
# CONFIG_CRC32_SLICEBY8 is not set
# CONFIG_CRC32_SLICEBY4 is not set
# CONFIG_CRC32_SARWATE is not set
CONFIG_CRC32_BIT=y
CONFIG_CRC7=m
CONFIG_LIBCRC32C=m
CONFIG_CRC8=m
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=m
CONFIG_LZO_COMPRESS=y
CONFIG_LZO_DECOMPRESS=y
CONFIG_XZ_DEC=y
CONFIG_XZ_DEC_X86=y
CONFIG_XZ_DEC_POWERPC=y
CONFIG_XZ_DEC_IA64=y
CONFIG_XZ_DEC_ARM=y
CONFIG_XZ_DEC_ARMTHUMB=y
CONFIG_XZ_DEC_SPARC=y
CONFIG_XZ_DEC_BCJ=y
# CONFIG_XZ_DEC_TEST is not set
CONFIG_DECOMPRESS_GZIP=y
CONFIG_DECOMPRESS_BZIP2=y
CONFIG_DECOMPRESS_LZMA=y
CONFIG_DECOMPRESS_XZ=y
CONFIG_DECOMPRESS_LZO=y
CONFIG_GENERIC_ALLOCATOR=y
CONFIG_TEXTSEARCH=y
CONFIG_TEXTSEARCH_KMP=m
CONFIG_TEXTSEARCH_BM=m
CONFIG_TEXTSEARCH_FSM=m
CONFIG_BTREE=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_CHECK_SIGNATURE=y
CONFIG_DQL=y
CONFIG_NLATTR=y
CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y
CONFIG_AVERAGE=y
# CONFIG_CORDIC is not set
CONFIG_DDR=y

--------------080408090803040002050408
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------080408090803040002050408--


From xen-devel-bounces@lists.xen.org Wed Oct 24 21:34:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 21:34:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TR8a4-0002C4-AC; Wed, 24 Oct 2012 21:33:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TR8a1-0002Bz-BF
	for xen-devel@lists.xensource.com; Wed, 24 Oct 2012 21:33:38 +0000
Received: from [85.158.137.99:24206] by server-4.bemta-3.messagelabs.com id
	E1/0D-01405-0BE58805; Wed, 24 Oct 2012 21:33:36 +0000
X-Env-Sender: rdunlap@xenotime.net
X-Msg-Ref: server-16.tower-217.messagelabs.com!1351114411!22911396!1
X-Originating-IP: [69.89.22.20]
X-SpamReason: No, hits=3.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA2OS44OS4yMi4yMCA9PiA0MDQ4Nw==\n,sa_preprocessor: 
	QmFkIElQOiA2OS44OS4yMi4yMCA9PiA0MDQ4Nw==\n, UNIQUE_WORDS,
	UPPERCASE_75_100
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23101 invoked from network); 24 Oct 2012 21:33:32 -0000
Received: from oproxy8-pub.bluehost.com (HELO oproxy8-pub.bluehost.com)
	(69.89.22.20) by server-16.tower-217.messagelabs.com with SMTP;
	24 Oct 2012 21:33:32 -0000
Received: (qmail 25523 invoked by uid 0); 24 Oct 2012 21:33:31 -0000
Received: from unknown (HELO box742.bluehost.com) (66.147.244.242)
	by oproxy8.bluehost.com with SMTP; 24 Oct 2012 21:33:31 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenotime.net;
	s=default; 
	h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID;
	bh=QcBR+E/yPIP7SclfSHItTsDy/bkvP0IgtfotBdug0qA=; 
	b=ckO+oEd6Uo4MnEtc5qWAJ2OcBM/q45Kt7Kd6p45RSbeX71KYoeGtdJf+qRwykHMlV+XmpdZ04Ug6aR/2xViPQLna1SW3wX41yhaR4JFDvFd+ubZIAZbAMm3sbSAnq20F;
Received: from [50.53.38.135] (port=54779 helo=[192.168.1.7])
	by box742.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256)
	(Exim 4.76) (envelope-from )
	id 1TR8Zu-00073J-N4; Wed, 24 Oct 2012 15:33:31 -0600
Message-ID: <50885EA8.3050007@xenotime.net>
Date: Wed, 24 Oct 2012 14:33:28 -0700
From: Randy Dunlap 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.15) Gecko/20110323 Thunderbird/3.1.9
MIME-Version: 1.0
To: Stephen Rothwell 
References: <20121024151957.28a1626cd9a59c014e78c401@canb.auug.org.au>
In-Reply-To: <20121024151957.28a1626cd9a59c014e78c401@canb.auug.org.au>
Content-Type: multipart/mixed; boundary="------------080408090803040002050408"
X-Identified-User: {1807:box742.bluehost.com:xenotime:xenotime.net}
	{sentby:smtp auth 50.53.38.135 authed with
	rdunlap@xenotime.net}
Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk ,
	linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org,
	linux-next@vger.kernel.org
Subject: Re: [Xen-devel] linux-next: Tree for Oct 24 (xen)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--------------080408090803040002050408
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 10/23/2012 09:19 PM, Stephen Rothwell wrote:

> Hi all,
> 
> Changes since 201201023:
> 

on x86_64:

drivers/built-in.o: In function `dbgp_reset_prep':
(.text+0xb96b5): undefined reference to `xen_dbgp_reset_prep'
drivers/built-in.o: In function `dbgp_external_startup':
(.text+0xb9d95): undefined reference to `xen_dbgp_external_startup'


Full randconfig file is attached.


-- 
~Randy

--------------080408090803040002050408
Content-Type: text/plain;
 name="config-r8330"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="config-r8330"

#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 3.7.0-rc2 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_DEFAULT_IDLE=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_ARCH_HAS_CPU_AUTOPROBE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_HAVE_IRQ_WORK=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SWAP is not set
# CONFIG_SYSVIPC is not set
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
# CONFIG_FHANDLE is not set
CONFIG_AUDIT=y
# CONFIG_AUDITSYSCALL is not set
# CONFIG_AUDIT_LOGINUID_IMMUTABLE is not set
CONFIG_HAVE_GENERIC_HARDIRQS=y

#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_DEBUG=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_IRQ_TIME_ACCOUNTING is not set
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_TASKSTATS=y
# CONFIG_TASK_DELAY_ACCT is not set
# CONFIG_TASK_XACCT is not set

#
# RCU Subsystem
#
CONFIG_TINY_RCU=y
# CONFIG_PREEMPT_RCU is not set
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_CGROUPS=y
CONFIG_CGROUP_DEBUG=y
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CPUSETS=y
CONFIG_PROC_PID_CPUSET=y
CONFIG_CGROUP_CPUACCT=y
# CONFIG_RESOURCE_COUNTERS is not set
# CONFIG_CGROUP_PERF is not set
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
# CONFIG_CFS_BANDWIDTH is not set
CONFIG_RT_GROUP_SCHED=y
# CONFIG_BLK_CGROUP is not set
# CONFIG_CHECKPOINT_RESTORE is not set
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
# CONFIG_IPC_NS is not set
# CONFIG_PID_NS is not set
CONFIG_NET_NS=y
CONFIG_SCHED_AUTOGROUP=y
CONFIG_SYSFS_DEPRECATED=y
# CONFIG_SYSFS_DEPRECATED_V2 is not set
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
# CONFIG_EXPERT is not set
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_SYSCTL_EXCEPTION_TRACE=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_PCSPKR_PLATFORM=y
CONFIG_HAVE_PCSPKR_PLATFORM=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
# CONFIG_EMBEDDED is not set
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_USE_VMALLOC=y

#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
CONFIG_DEBUG_PERF_USE_VMALLOC=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_PCI_QUIRKS=y
CONFIG_SLUB_DEBUG=y
# CONFIG_COMPAT_BRK is not set
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_PROFILING is not set
CONFIG_HAVE_OPROFILE=y
CONFIG_OPROFILE_NMI_TIMER=y
CONFIG_KPROBES=y
# CONFIG_JUMP_LABEL is not set
CONFIG_OPTPROBES=y
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_KRETPROBES=y
CONFIG_HAVE_IOREMAP_PROT=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_OPTPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_HW_BREAKPOINT=y
CONFIG_HAVE_MIXED_BREAKPOINTS_REGS=y
CONFIG_HAVE_USER_RETURN_NOTIFIER=y
CONFIG_HAVE_PERF_EVENTS_NMI=y
CONFIG_HAVE_PERF_REGS=y
CONFIG_HAVE_PERF_USER_STACK_DUMP=y
CONFIG_HAVE_ARCH_JUMP_LABEL=y
CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG=y
CONFIG_HAVE_ALIGNED_STRUCT_PAGE=y
CONFIG_HAVE_CMPXCHG_LOCAL=y
CONFIG_HAVE_CMPXCHG_DOUBLE=y
CONFIG_GENERIC_KERNEL_THREAD=y
CONFIG_GENERIC_KERNEL_EXECVE=y
CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
CONFIG_SECCOMP_FILTER=y
CONFIG_HAVE_RCU_USER_QS=y
CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y
CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y
CONFIG_MODULES_USE_ELF_RELA=y

#
# GCOV-based kernel profiling
#
# CONFIG_GCOV_KERNEL is not set
# CONFIG_HAVE_GENERIC_DMA_COHERENT is not set
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
# CONFIG_MODULE_FORCE_LOAD is not set
# CONFIG_MODULE_UNLOAD is not set
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
# CONFIG_MODULE_SIG is not set
CONFIG_BLOCK=y
CONFIG_BLK_DEV_BSG=y
CONFIG_BLK_DEV_BSGLIB=y
CONFIG_BLK_DEV_INTEGRITY=y

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
CONFIG_MAC_PARTITION=y
# CONFIG_MSDOS_PARTITION is not set
# CONFIG_LDM_PARTITION is not set
CONFIG_SGI_PARTITION=y
CONFIG_ULTRIX_PARTITION=y
# CONFIG_SUN_PARTITION is not set
# CONFIG_KARMA_PARTITION is not set
# CONFIG_EFI_PARTITION is not set
# CONFIG_SYSV68_PARTITION is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_DEADLINE is not set
CONFIG_IOSCHED_CFQ=m
CONFIG_DEFAULT_NOOP=y
CONFIG_DEFAULT_IOSCHED="noop"
CONFIG_UNINLINE_SPIN_UNLOCK=y
CONFIG_FREEZER=y

#
# Processor type and features
#
CONFIG_ZONE_DMA=y
# CONFIG_SMP is not set
# CONFIG_X86_MPPARSE is not set
# CONFIG_X86_EXTENDED_PLATFORM is not set
CONFIG_X86_SUPPORTS_MEMORY_FAILURE=y
CONFIG_SCHED_OMIT_FRAME_POINTER=y
CONFIG_KVMTOOL_TEST_ENABLE=y
CONFIG_PARAVIRT_GUEST=y
CONFIG_PARAVIRT_TIME_ACCOUNTING=y
CONFIG_XEN=y
CONFIG_XEN_DOM0=y
CONFIG_XEN_PRIVILEGED_GUEST=y
CONFIG_XEN_PVHVM=y
CONFIG_XEN_MAX_DOMAIN_MEMORY=500
CONFIG_XEN_SAVE_RESTORE=y
CONFIG_XEN_DEBUG_FS=y
CONFIG_KVM_GUEST=y
CONFIG_PARAVIRT=y
CONFIG_PARAVIRT_CLOCK=y
# CONFIG_PARAVIRT_DEBUG is not set
CONFIG_NO_BOOTMEM=y
CONFIG_MEMTEST=y
# CONFIG_MK8 is not set
# CONFIG_MPSC is not set
# CONFIG_MCORE2 is not set
# CONFIG_MATOM is not set
CONFIG_GENERIC_CPU=y
CONFIG_X86_INTERNODE_CACHE_SHIFT=6
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_XADD=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_TSC=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=64
CONFIG_X86_DEBUGCTLMSR=y
CONFIG_CPU_SUP_INTEL=y
CONFIG_CPU_SUP_AMD=y
CONFIG_CPU_SUP_CENTAUR=y
CONFIG_HPET_TIMER=y
CONFIG_DMI=y
CONFIG_GART_IOMMU=y
CONFIG_CALGARY_IOMMU=y
CONFIG_CALGARY_IOMMU_ENABLED_BY_DEFAULT=y
CONFIG_SWIOTLB=y
CONFIG_IOMMU_HELPER=y
CONFIG_NR_CPUS=1
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_PREEMPT_COUNT=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
# CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS is not set
CONFIG_X86_MCE=y
CONFIG_X86_MCE_INTEL=y
CONFIG_X86_MCE_AMD=y
CONFIG_X86_MCE_THRESHOLD=y
# CONFIG_X86_MCE_INJECT is not set
CONFIG_X86_THERMAL_VECTOR=y
CONFIG_I8K=m
CONFIG_MICROCODE=m
# CONFIG_MICROCODE_INTEL is not set
CONFIG_MICROCODE_AMD=y
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_X86_MSR=m
# CONFIG_X86_CPUID is not set
CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
CONFIG_ARCH_DMA_ADDR_T_64BIT=y
CONFIG_DIRECT_GBPAGES=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_DEFAULT=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ILLEGAL_POINTER_VALUE=0xdead000000000000
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_SPARSEMEM_MANUAL=y
CONFIG_SPARSEMEM=y
CONFIG_HAVE_MEMORY_PRESENT=y
CONFIG_SPARSEMEM_EXTREME=y
CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER=y
CONFIG_SPARSEMEM_VMEMMAP=y
CONFIG_HAVE_MEMBLOCK=y
CONFIG_HAVE_MEMBLOCK_NODE_MAP=y
CONFIG_ARCH_DISCARD_MEMBLOCK=y
# CONFIG_MEMORY_HOTPLUG is not set
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=999999
CONFIG_COMPACTION=y
CONFIG_MIGRATION=y
CONFIG_PHYS_ADDR_T_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
# CONFIG_KSM is not set
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_ARCH_SUPPORTS_MEMORY_FAILURE=y
# CONFIG_MEMORY_FAILURE is not set
CONFIG_TRANSPARENT_HUGEPAGE=y
CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y
# CONFIG_TRANSPARENT_HUGEPAGE_MADVISE is not set
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_NEED_PER_CPU_KM=y
# CONFIG_CLEANCACHE is not set
CONFIG_X86_CHECK_BIOS_CORRUPTION=y
CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK=y
CONFIG_X86_RESERVE_LOW=64
CONFIG_MTRR=y
CONFIG_MTRR_SANITIZER=y
CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=0
CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
CONFIG_X86_PAT=y
CONFIG_ARCH_USES_PG_UNCACHED=y
CONFIG_ARCH_RANDOM=y
CONFIG_X86_SMAP=y
# CONFIG_EFI is not set
CONFIG_SECCOMP=y
# CONFIG_CC_STACKPROTECTOR is not set
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
CONFIG_HZ_300=y
# CONFIG_HZ_1000 is not set
CONFIG_HZ=300
CONFIG_SCHED_HRTICK=y
# CONFIG_KEXEC is not set
CONFIG_CRASH_DUMP=y
CONFIG_PHYSICAL_START=0x1000000
# CONFIG_RELOCATABLE is not set
CONFIG_PHYSICAL_ALIGN=0x1000000
CONFIG_CMDLINE_BOOL=y
CONFIG_CMDLINE=""
CONFIG_CMDLINE_OVERRIDE=y
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y

#
# Power management and ACPI options
#
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
CONFIG_HIBERNATE_CALLBACKS=y
CONFIG_PM_SLEEP=y
# CONFIG_PM_AUTOSLEEP is not set
CONFIG_PM_WAKELOCKS=y
CONFIG_PM_WAKELOCKS_LIMIT=100
# CONFIG_PM_WAKELOCKS_GC is not set
# CONFIG_PM_RUNTIME is not set
CONFIG_PM=y
CONFIG_PM_DEBUG=y
# CONFIG_PM_ADVANCED_DEBUG is not set
CONFIG_PM_SLEEP_DEBUG=y
CONFIG_PM_TRACE=y
CONFIG_PM_TRACE_RTC=y
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
# CONFIG_ACPI_PROCFS is not set
# CONFIG_ACPI_PROCFS_POWER is not set
# CONFIG_ACPI_EC_DEBUGFS is not set
CONFIG_ACPI_PROC_EVENT=y
# CONFIG_ACPI_AC is not set
CONFIG_ACPI_BATTERY=m
# CONFIG_ACPI_BUTTON is not set
CONFIG_ACPI_VIDEO=m
# CONFIG_ACPI_FAN is not set
CONFIG_ACPI_DOCK=y
CONFIG_ACPI_PROCESSOR=m
CONFIG_ACPI_IPMI=m
CONFIG_ACPI_PROCESSOR_AGGREGATOR=m
# CONFIG_ACPI_THERMAL is not set
# CONFIG_ACPI_CUSTOM_DSDT is not set
CONFIG_ACPI_INITRD_TABLE_OVERRIDE=y
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
# CONFIG_ACPI_PCI_SLOT is not set
CONFIG_X86_PM_TIMER=y
# CONFIG_ACPI_CONTAINER is not set
# CONFIG_ACPI_SBS is not set
CONFIG_ACPI_HED=y
# CONFIG_ACPI_CUSTOM_METHOD is not set
CONFIG_ACPI_APEI=y
CONFIG_ACPI_APEI_GHES=y
# CONFIG_ACPI_APEI_PCIEAER is not set
CONFIG_ACPI_APEI_EINJ=m
# CONFIG_ACPI_APEI_ERST_DEBUG is not set
CONFIG_SFI=y

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set
CONFIG_CPU_IDLE=y
CONFIG_CPU_IDLE_GOV_LADDER=y
CONFIG_CPU_IDLE_GOV_MENU=y
# CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set
# CONFIG_INTEL_IDLE is not set

#
# Memory power savings
#
# CONFIG_I7300_IDLE is not set

#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
CONFIG_PCI_DIRECT=y
# CONFIG_PCI_MMCONFIG is not set
CONFIG_PCI_XEN=y
CONFIG_PCI_DOMAINS=y
CONFIG_PCIEPORTBUS=y
CONFIG_HOTPLUG_PCI_PCIE=m
CONFIG_PCIEAER=y
# CONFIG_PCIE_ECRC is not set
# CONFIG_PCIEAER_INJECT is not set
CONFIG_PCIEASPM=y
# CONFIG_PCIEASPM_DEBUG is not set
# CONFIG_PCIEASPM_DEFAULT is not set
# CONFIG_PCIEASPM_POWERSAVE is not set
CONFIG_PCIEASPM_PERFORMANCE=y
CONFIG_ARCH_SUPPORTS_MSI=y
CONFIG_PCI_MSI=y
CONFIG_PCI_DEBUG=y
# CONFIG_PCI_REALLOC_ENABLE_AUTO is not set
# CONFIG_PCI_STUB is not set
CONFIG_XEN_PCIDEV_FRONTEND=m
CONFIG_HT_IRQ=y
# CONFIG_PCI_IOV is not set
# CONFIG_PCI_PRI is not set
# CONFIG_PCI_PASID is not set
CONFIG_PCI_IOAPIC=m
CONFIG_PCI_LABEL=y
CONFIG_ISA_DMA_API=y
CONFIG_AMD_NB=y
# CONFIG_PCCARD is not set
CONFIG_HOTPLUG_PCI=m
# CONFIG_HOTPLUG_PCI_ACPI is not set
CONFIG_HOTPLUG_PCI_CPCI=y
# CONFIG_HOTPLUG_PCI_CPCI_ZT5550 is not set
CONFIG_HOTPLUG_PCI_CPCI_GENERIC=m
# CONFIG_HOTPLUG_PCI_SHPC is not set
# CONFIG_RAPIDIO is not set

#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y
CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
# CONFIG_HAVE_AOUT is not set
# CONFIG_BINFMT_MISC is not set
CONFIG_COREDUMP=y
# CONFIG_IA32_EMULATION is not set
CONFIG_HAVE_TEXT_POKE_SMP=y
CONFIG_X86_DEV_DMA_OPS=y
CONFIG_NET=y

#
# Networking options
#
# CONFIG_PACKET is not set
CONFIG_UNIX=m
CONFIG_UNIX_DIAG=m
CONFIG_XFRM=y
CONFIG_XFRM_ALGO=m
# CONFIG_XFRM_USER is not set
# CONFIG_XFRM_SUB_POLICY is not set
CONFIG_XFRM_MIGRATE=y
CONFIG_XFRM_STATISTICS=y
CONFIG_XFRM_IPCOMP=m
CONFIG_NET_KEY=m
CONFIG_NET_KEY_MIGRATE=y
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_IP_FIB_TRIE_STATS=y
# CONFIG_IP_MULTIPLE_TABLES is not set
CONFIG_IP_ROUTE_MULTIPATH=y
# CONFIG_IP_ROUTE_VERBOSE is not set
CONFIG_IP_ROUTE_CLASSID=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
# CONFIG_IP_PNP_BOOTP is not set
CONFIG_IP_PNP_RARP=y
CONFIG_NET_IPIP=m
# CONFIG_NET_IPGRE_DEMUX is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
CONFIG_NET_IPVTI=m
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
CONFIG_INET_TUNNEL=m
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
CONFIG_INET_XFRM_MODE_TUNNEL=m
CONFIG_INET_XFRM_MODE_BEET=m
CONFIG_INET_LRO=m
CONFIG_INET_DIAG=m
CONFIG_INET_TCP_DIAG=m
# CONFIG_INET_UDP_DIAG is not set
CONFIG_TCP_CONG_ADVANCED=y
# CONFIG_TCP_CONG_BIC is not set
# CONFIG_TCP_CONG_CUBIC is not set
# CONFIG_TCP_CONG_WESTWOOD is not set
# CONFIG_TCP_CONG_HTCP is not set
# CONFIG_TCP_CONG_HSTCP is not set
CONFIG_TCP_CONG_HYBLA=m
# CONFIG_TCP_CONG_VEGAS is not set
# CONFIG_TCP_CONG_SCALABLE is not set
# CONFIG_TCP_CONG_LP is not set
# CONFIG_TCP_CONG_VENO is not set
# CONFIG_TCP_CONG_YEAH is not set
CONFIG_TCP_CONG_ILLINOIS=m
CONFIG_DEFAULT_RENO=y
CONFIG_DEFAULT_TCP_CONG="reno"
CONFIG_TCP_MD5SIG=y
CONFIG_IPV6=m
# CONFIG_IPV6_PRIVACY is not set
CONFIG_IPV6_ROUTER_PREF=y
# CONFIG_IPV6_ROUTE_INFO is not set
CONFIG_IPV6_OPTIMISTIC_DAD=y
# CONFIG_INET6_AH is not set
CONFIG_INET6_ESP=m
CONFIG_INET6_IPCOMP=m
# CONFIG_IPV6_MIP6 is not set
CONFIG_INET6_XFRM_TUNNEL=m
CONFIG_INET6_TUNNEL=m
# CONFIG_INET6_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET6_XFRM_MODE_TUNNEL is not set
CONFIG_INET6_XFRM_MODE_BEET=m
CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION=m
CONFIG_IPV6_SIT=m
CONFIG_IPV6_SIT_6RD=y
CONFIG_IPV6_NDISC_NODETYPE=y
CONFIG_IPV6_TUNNEL=m
CONFIG_IPV6_GRE=m
CONFIG_IPV6_MULTIPLE_TABLES=y
# CONFIG_IPV6_SUBTREES is not set
# CONFIG_IPV6_MROUTE is not set
# CONFIG_NETLABEL is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETWORK_PHY_TIMESTAMPING is not set
# CONFIG_NETFILTER is not set
# CONFIG_IP_DCCP is not set
CONFIG_IP_SCTP=m
# CONFIG_NET_SCTPPROBE is not set
CONFIG_SCTP_DBG_MSG=y
CONFIG_SCTP_DBG_OBJCNT=y
# CONFIG_SCTP_HMAC_NONE is not set
# CONFIG_SCTP_HMAC_SHA1 is not set
CONFIG_SCTP_HMAC_MD5=y
# CONFIG_RDS is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
CONFIG_L2TP=m
CONFIG_L2TP_DEBUGFS=m
CONFIG_L2TP_V3=y
# CONFIG_L2TP_IP is not set
CONFIG_L2TP_ETH=m
CONFIG_STP=m
CONFIG_BRIDGE=m
CONFIG_BRIDGE_IGMP_SNOOPING=y
CONFIG_NET_DSA=m
CONFIG_NET_DSA_TAG_DSA=y
# CONFIG_NET_DSA_TAG_EDSA is not set
# CONFIG_NET_DSA_TAG_TRAILER is not set
# CONFIG_VLAN_8021Q is not set
CONFIG_DECNET=m
CONFIG_DECNET_ROUTER=y
CONFIG_LLC=m
CONFIG_LLC2=m
# CONFIG_IPX is not set
CONFIG_ATALK=m
CONFIG_DEV_APPLETALK=m
CONFIG_IPDDP=m
# CONFIG_IPDDP_ENCAP is not set
# CONFIG_IPDDP_DECAP is not set
CONFIG_X25=m
CONFIG_LAPB=m
# CONFIG_WAN_ROUTER is not set
CONFIG_PHONET=m
CONFIG_IEEE802154=m
# CONFIG_IEEE802154_6LOWPAN is not set
# CONFIG_MAC802154 is not set
CONFIG_NET_SCHED=y

#
# Queueing/Scheduling
#
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
# CONFIG_NET_SCH_HFSC is not set
# CONFIG_NET_SCH_PRIO is not set
# CONFIG_NET_SCH_MULTIQ is not set
# CONFIG_NET_SCH_RED is not set
CONFIG_NET_SCH_SFB=m
CONFIG_NET_SCH_SFQ=m
# CONFIG_NET_SCH_TEQL is not set
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
# CONFIG_NET_SCH_DSMARK is not set
CONFIG_NET_SCH_NETEM=m
CONFIG_NET_SCH_DRR=m
CONFIG_NET_SCH_MQPRIO=m
CONFIG_NET_SCH_CHOKE=m
# CONFIG_NET_SCH_QFQ is not set
CONFIG_NET_SCH_CODEL=m
# CONFIG_NET_SCH_FQ_CODEL is not set
CONFIG_NET_SCH_INGRESS=m
CONFIG_NET_SCH_PLUG=m

#
# Classification
#
CONFIG_NET_CLS=y
CONFIG_NET_CLS_BASIC=m
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
# CONFIG_NET_CLS_FW is not set
# CONFIG_NET_CLS_U32 is not set
CONFIG_NET_CLS_RSVP=m
CONFIG_NET_CLS_RSVP6=m
CONFIG_NET_CLS_FLOW=m
# CONFIG_NET_CLS_CGROUP is not set
CONFIG_NET_EMATCH=y
CONFIG_NET_EMATCH_STACK=32
CONFIG_NET_EMATCH_CMP=m
CONFIG_NET_EMATCH_NBYTE=m
# CONFIG_NET_EMATCH_U32 is not set
# CONFIG_NET_EMATCH_META is not set
CONFIG_NET_EMATCH_TEXT=m
CONFIG_NET_CLS_ACT=y
CONFIG_NET_ACT_POLICE=m
# CONFIG_NET_ACT_GACT is not set
# CONFIG_NET_ACT_MIRRED is not set
# CONFIG_NET_ACT_NAT is not set
# CONFIG_NET_ACT_PEDIT is not set
CONFIG_NET_ACT_SIMP=m
CONFIG_NET_ACT_SKBEDIT=m
# CONFIG_NET_ACT_CSUM is not set
CONFIG_NET_SCH_FIFO=y
# CONFIG_DCB is not set
CONFIG_DNS_RESOLVER=m
CONFIG_BATMAN_ADV=m
CONFIG_BATMAN_ADV_BLA=y
CONFIG_BATMAN_ADV_DEBUG=y
CONFIG_OPENVSWITCH=m
# CONFIG_NETPRIO_CGROUP is not set
CONFIG_BQL=y
CONFIG_BPF_JIT=y

#
# Network testing
#
CONFIG_NET_PKTGEN=m
CONFIG_NET_TCPPROBE=m
CONFIG_HAMRADIO=y

#
# Packet Radio protocols
#
CONFIG_AX25=m
# CONFIG_AX25_DAMA_SLAVE is not set
CONFIG_NETROM=m
# CONFIG_ROSE is not set

#
# AX.25 network device drivers
#
CONFIG_MKISS=m
# CONFIG_6PACK is not set
# CONFIG_BPQETHER is not set
CONFIG_BAYCOM_SER_FDX=m
# CONFIG_BAYCOM_SER_HDX is not set
CONFIG_YAM=m
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
CONFIG_AF_RXRPC=m
# CONFIG_AF_RXRPC_DEBUG is not set
# CONFIG_RXKAD is not set
CONFIG_FIB_RULES=y
# CONFIG_WIRELESS is not set
# CONFIG_WIMAX is not set
# CONFIG_RFKILL is not set
# CONFIG_RFKILL_REGULATOR is not set
CONFIG_NET_9P=y
CONFIG_NET_9P_VIRTIO=y
CONFIG_NET_9P_DEBUG=y
CONFIG_CAIF=m
# CONFIG_CAIF_DEBUG is not set
CONFIG_CAIF_NETDEV=m
# CONFIG_CAIF_USB is not set
CONFIG_CEPH_LIB=m
# CONFIG_CEPH_LIB_PRETTYDEBUG is not set
CONFIG_CEPH_LIB_USE_DNS_RESOLVER=y
CONFIG_NFC=m
# CONFIG_NFC_NCI is not set
# CONFIG_NFC_HCI is not set
CONFIG_NFC_LLCP=y

#
# Near Field Communication (NFC) devices
#
CONFIG_HAVE_BPF_JIT=y

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH=""
CONFIG_DEVTMPFS=y
# CONFIG_DEVTMPFS_MOUNT is not set
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
# CONFIG_FIRMWARE_IN_KERNEL is not set
CONFIG_EXTRA_FIRMWARE=""
CONFIG_DEBUG_DRIVER=y
CONFIG_DEBUG_DEVRES=y
CONFIG_SYS_HYPERVISOR=y
# CONFIG_GENERIC_CPU_DEVICES is not set
CONFIG_REGMAP=y
CONFIG_REGMAP_I2C=m
CONFIG_REGMAP_SPI=y
CONFIG_DMA_SHARED_BUFFER=y

#
# Bus devices
#
CONFIG_OMAP_OCP2SCP=m
CONFIG_CONNECTOR=m
# CONFIG_MTD is not set
# CONFIG_PARPORT is not set
CONFIG_PNP=y
# CONFIG_PNP_DEBUG_MESSAGES is not set

#
# Protocols
#
CONFIG_PNPACPI=y
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_DEV_PCIESSD_MTIP32XX is not set
CONFIG_BLK_CPQ_DA=m
CONFIG_BLK_CPQ_CISS_DA=m
CONFIG_CISS_SCSI_TAPE=y
CONFIG_BLK_DEV_DAC960=m
CONFIG_BLK_DEV_UMEM=m
# CONFIG_BLK_DEV_COW_COMMON is not set
# CONFIG_BLK_DEV_LOOP is not set
# CONFIG_BLK_DEV_DRBD is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_NVME is not set
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_RAM is not set
CONFIG_CDROM_PKTCDVD=m
CONFIG_CDROM_PKTCDVD_BUFFERS=8
# CONFIG_CDROM_PKTCDVD_WCACHE is not set
CONFIG_ATA_OVER_ETH=m
CONFIG_XEN_BLKDEV_FRONTEND=m
CONFIG_VIRTIO_BLK=y
CONFIG_BLK_DEV_HD=y
CONFIG_BLK_DEV_RBD=m

#
# Misc devices
#
CONFIG_SENSORS_LIS3LV02D=m
CONFIG_AD525X_DPOT=m
# CONFIG_AD525X_DPOT_I2C is not set
# CONFIG_AD525X_DPOT_SPI is not set
CONFIG_IBM_ASM=m
CONFIG_PHANTOM=m
# CONFIG_INTEL_MID_PTI is not set
# CONFIG_SGI_IOC4 is not set
CONFIG_TIFM_CORE=m
# CONFIG_TIFM_7XX1 is not set
CONFIG_ICS932S401=m
# CONFIG_ENCLOSURE_SERVICES is not set
# CONFIG_CS5535_MFGPT is not set
CONFIG_HP_ILO=m
CONFIG_APDS9802ALS=m
CONFIG_ISL29003=m
# CONFIG_ISL29020 is not set
CONFIG_SENSORS_TSL2550=m
# CONFIG_SENSORS_BH1780 is not set
CONFIG_SENSORS_BH1770=m
# CONFIG_SENSORS_APDS990X is not set
CONFIG_HMC6352=m
CONFIG_DS1682=m
CONFIG_TI_DAC7512=m
CONFIG_VMWARE_BALLOON=m
# CONFIG_BMP085_I2C is not set
# CONFIG_BMP085_SPI is not set
CONFIG_PCH_PHUB=m
# CONFIG_USB_SWITCH_FSA9480 is not set
CONFIG_C2PORT=m
CONFIG_C2PORT_DURAMAR_2150=m

#
# EEPROM support
#
CONFIG_EEPROM_AT24=m
CONFIG_EEPROM_AT25=m
# CONFIG_EEPROM_LEGACY is not set
CONFIG_EEPROM_MAX6875=m
# CONFIG_EEPROM_93CX6 is not set
# CONFIG_EEPROM_93XX46 is not set
# CONFIG_CB710_CORE is not set

#
# Texas Instruments shared transport line discipline
#
CONFIG_SENSORS_LIS3_I2C=m

#
# Altera FPGA firmware download module
#
# CONFIG_ALTERA_STAPL is not set
CONFIG_INTEL_MEI=m
CONFIG_HAVE_IDE=y
CONFIG_IDE=m

#
# Please see Documentation/ide/ide.txt for help/info on IDE drives
#
CONFIG_IDE_XFER_MODE=y
CONFIG_IDE_TIMINGS=y
CONFIG_IDE_ATAPI=y
CONFIG_BLK_DEV_IDE_SATA=y
# CONFIG_IDE_GD is not set
# CONFIG_BLK_DEV_IDECD is not set
CONFIG_BLK_DEV_IDETAPE=m
CONFIG_BLK_DEV_IDEACPI=y
# CONFIG_IDE_TASK_IOCTL is not set
# CONFIG_IDE_PROC_FS is not set

#
# IDE chipset support/bugfixes
#
# CONFIG_IDE_GENERIC is not set
# CONFIG_BLK_DEV_PLATFORM is not set
CONFIG_BLK_DEV_CMD640=m
CONFIG_BLK_DEV_CMD640_ENHANCED=y
CONFIG_BLK_DEV_IDEPNP=m
CONFIG_BLK_DEV_IDEDMA_SFF=y

#
# PCI IDE chipsets support
#
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_BLK_DEV_OFFBOARD=y
CONFIG_BLK_DEV_GENERIC=m
# CONFIG_BLK_DEV_OPTI621 is not set
CONFIG_BLK_DEV_RZ1000=m
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_AEC62XX is not set
CONFIG_BLK_DEV_ALI15X3=m
CONFIG_BLK_DEV_AMD74XX=m
# CONFIG_BLK_DEV_ATIIXP is not set
# CONFIG_BLK_DEV_CMD64X is not set
CONFIG_BLK_DEV_TRIFLEX=m
CONFIG_BLK_DEV_CS5520=m
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_HPT366 is not set
CONFIG_BLK_DEV_JMICRON=m
# CONFIG_BLK_DEV_SC1200 is not set
CONFIG_BLK_DEV_PIIX=m
CONFIG_BLK_DEV_IT8172=m
CONFIG_BLK_DEV_IT8213=m
# CONFIG_BLK_DEV_IT821X is not set
CONFIG_BLK_DEV_NS87415=m
CONFIG_BLK_DEV_PDC202XX_OLD=m
CONFIG_BLK_DEV_PDC202XX_NEW=m
CONFIG_BLK_DEV_SVWKS=m
# CONFIG_BLK_DEV_SIIMAGE is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
CONFIG_BLK_DEV_TRM290=m
CONFIG_BLK_DEV_VIA82CXXX=m
# CONFIG_BLK_DEV_TC86C001 is not set
CONFIG_BLK_DEV_IDEDMA=y

#
# SCSI device support
#
CONFIG_SCSI_MOD=m
CONFIG_RAID_ATTRS=m
CONFIG_SCSI=m
CONFIG_SCSI_DMA=y
CONFIG_SCSI_TGT=m
CONFIG_SCSI_NETLINK=y
# CONFIG_SCSI_PROC_FS is not set

#
# SCSI support type (disk, tape, CD-ROM)
#
# CONFIG_BLK_DEV_SD is not set
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
# CONFIG_CHR_DEV_SG is not set
CONFIG_CHR_DEV_SCH=m
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
# CONFIG_SCSI_SCAN_ASYNC is not set

#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=m
CONFIG_SCSI_FC_ATTRS=m
CONFIG_SCSI_FC_TGT_ATTRS=y
CONFIG_SCSI_ISCSI_ATTRS=m
CONFIG_SCSI_SAS_ATTRS=m
CONFIG_SCSI_SAS_LIBSAS=m
# CONFIG_SCSI_SAS_ATA is not set
CONFIG_SCSI_SAS_HOST_SMP=y
CONFIG_SCSI_SRP_ATTRS=m
CONFIG_SCSI_SRP_TGT_ATTRS=y
CONFIG_SCSI_LOWLEVEL=y
# CONFIG_ISCSI_TCP is not set
# CONFIG_ISCSI_BOOT_SYSFS is not set
CONFIG_SCSI_CXGB3_ISCSI=m
CONFIG_SCSI_CXGB4_ISCSI=m
CONFIG_SCSI_BNX2_ISCSI=m
# CONFIG_SCSI_BNX2X_FCOE is not set
# CONFIG_BE2ISCSI is not set
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
CONFIG_SCSI_HPSA=m
CONFIG_SCSI_3W_9XXX=m
# CONFIG_SCSI_3W_SAS is not set
# CONFIG_SCSI_ACARD is not set
CONFIG_SCSI_AACRAID=m
# CONFIG_SCSI_AIC7XXX is not set
CONFIG_SCSI_AIC7XXX_OLD=m
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_AIC94XX is not set
CONFIG_SCSI_MVSAS=m
# CONFIG_SCSI_MVSAS_DEBUG is not set
CONFIG_SCSI_MVSAS_TASKLET=y
CONFIG_SCSI_MVUMI=m
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_ADVANSYS is not set
CONFIG_SCSI_ARCMSR=m
CONFIG_MEGARAID_NEWGEN=y
CONFIG_MEGARAID_MM=m
# CONFIG_MEGARAID_MAILBOX is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
CONFIG_SCSI_MPT2SAS=m
CONFIG_SCSI_MPT2SAS_MAX_SGE=128
# CONFIG_SCSI_MPT2SAS_LOGGING is not set
CONFIG_SCSI_UFSHCD=m
CONFIG_SCSI_HPTIOP=m
CONFIG_SCSI_BUSLOGIC=m
CONFIG_VMWARE_PVSCSI=m
CONFIG_LIBFC=m
CONFIG_LIBFCOE=m
# CONFIG_FCOE is not set
CONFIG_FCOE_FNIC=m
CONFIG_SCSI_DMX3191D=m
CONFIG_SCSI_EATA=m
# CONFIG_SCSI_EATA_TAGGED_QUEUE is not set
CONFIG_SCSI_EATA_LINKED_COMMANDS=y
CONFIG_SCSI_EATA_MAX_TAGS=16
CONFIG_SCSI_FUTURE_DOMAIN=m
CONFIG_SCSI_GDTH=m
# CONFIG_SCSI_ISCI is not set
# CONFIG_SCSI_IPS is not set
CONFIG_SCSI_INITIO=m
# CONFIG_SCSI_INIA100 is not set
CONFIG_SCSI_STEX=m
CONFIG_SCSI_SYM53C8XX_2=m
CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1
CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16
CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64
# CONFIG_SCSI_SYM53C8XX_MMIO is not set
CONFIG_SCSI_IPR=m
# CONFIG_SCSI_IPR_TRACE is not set
# CONFIG_SCSI_IPR_DUMP is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLA_FC is not set
# CONFIG_SCSI_QLA_ISCSI is not set
# CONFIG_SCSI_LPFC is not set
CONFIG_SCSI_DC395x=m
# CONFIG_SCSI_DC390T is not set
CONFIG_SCSI_DEBUG=m
CONFIG_SCSI_PMCRAID=m
# CONFIG_SCSI_PM8001 is not set
CONFIG_SCSI_SRP=m
# CONFIG_SCSI_BFA_FC is not set
CONFIG_SCSI_VIRTIO=m
# CONFIG_SCSI_DH is not set
# CONFIG_SCSI_OSD_INITIATOR is not set
CONFIG_ATA=m
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_ATA_VERBOSE_ERROR=y
# CONFIG_ATA_ACPI is not set
# CONFIG_SATA_PMP is not set

#
# Controllers with non-SFF native interface
#
CONFIG_SATA_AHCI=m
# CONFIG_SATA_AHCI_PLATFORM is not set
CONFIG_SATA_INIC162X=m
CONFIG_SATA_ACARD_AHCI=m
CONFIG_SATA_SIL24=m
# CONFIG_ATA_SFF is not set
CONFIG_MD=y
# CONFIG_BLK_DEV_MD is not set
# CONFIG_BLK_DEV_DM is not set
# CONFIG_TARGET_CORE is not set
CONFIG_FUSION=y
CONFIG_FUSION_SPI=m
# CONFIG_FUSION_FC is not set
CONFIG_FUSION_SAS=m
CONFIG_FUSION_MAX_SGE=128
# CONFIG_FUSION_CTL is not set
# CONFIG_FUSION_LOGGING is not set

#
# IEEE 1394 (FireWire) support
#
CONFIG_FIREWIRE=m
# CONFIG_FIREWIRE_OHCI is not set
# CONFIG_FIREWIRE_SBP2 is not set
CONFIG_FIREWIRE_NET=m
CONFIG_FIREWIRE_NOSY=m
CONFIG_I2O=m
# CONFIG_I2O_LCT_NOTIFY_ON_CHANGES is not set
CONFIG_I2O_EXT_ADAPTEC=y
CONFIG_I2O_EXT_ADAPTEC_DMA64=y
# CONFIG_I2O_CONFIG is not set
# CONFIG_I2O_BUS is not set
# CONFIG_I2O_BLOCK is not set
CONFIG_I2O_SCSI=m
# CONFIG_I2O_PROC is not set
CONFIG_MACINTOSH_DRIVERS=y
CONFIG_MAC_EMUMOUSEBTN=m
CONFIG_NETDEVICES=y
CONFIG_NET_CORE=y
CONFIG_BONDING=m
CONFIG_DUMMY=m
CONFIG_EQUALIZER=m
# CONFIG_NET_FC is not set
CONFIG_MII=m
CONFIG_IFB=m
CONFIG_NET_TEAM=m
CONFIG_NET_TEAM_MODE_BROADCAST=m
# CONFIG_NET_TEAM_MODE_ROUNDROBIN is not set
# CONFIG_NET_TEAM_MODE_ACTIVEBACKUP is not set
CONFIG_NET_TEAM_MODE_LOADBALANCE=m
# CONFIG_MACVLAN is not set
# CONFIG_VXLAN is not set
CONFIG_NETCONSOLE=m
# CONFIG_NETCONSOLE_DYNAMIC is not set
CONFIG_NETPOLL=y
# CONFIG_NETPOLL_TRAP is not set
CONFIG_NET_POLL_CONTROLLER=y
# CONFIG_TUN is not set
CONFIG_VETH=m
CONFIG_VIRTIO_NET=y
CONFIG_ARCNET=m
# CONFIG_ARCNET_1201 is not set
CONFIG_ARCNET_1051=m
CONFIG_ARCNET_RAW=m
CONFIG_ARCNET_CAP=m
CONFIG_ARCNET_COM90xx=m
# CONFIG_ARCNET_COM90xxIO is not set
CONFIG_ARCNET_RIM_I=m
# CONFIG_ARCNET_COM20020 is not set

#
# CAIF transport drivers
#
CONFIG_CAIF_TTY=m
# CONFIG_CAIF_SPI_SLAVE is not set
# CONFIG_CAIF_HSI is not set

#
# Distributed Switch Architecture drivers
#
CONFIG_NET_DSA_MV88E6XXX=m
# CONFIG_NET_DSA_MV88E6060 is not set
CONFIG_NET_DSA_MV88E6XXX_NEED_PPU=y
CONFIG_NET_DSA_MV88E6131=m
# CONFIG_NET_DSA_MV88E6123_61_65 is not set
CONFIG_ETHERNET=y
CONFIG_MDIO=m
# CONFIG_NET_VENDOR_3COM is not set
CONFIG_NET_VENDOR_ADAPTEC=y
CONFIG_ADAPTEC_STARFIRE=m
CONFIG_NET_VENDOR_ALTEON=y
# CONFIG_ACENIC is not set
CONFIG_NET_VENDOR_AMD=y
CONFIG_AMD8111_ETH=m
CONFIG_PCNET32=m
# CONFIG_NET_VENDOR_ATHEROS is not set
CONFIG_NET_CADENCE=y
# CONFIG_ARM_AT91_ETHER is not set
# CONFIG_MACB is not set
CONFIG_NET_VENDOR_BROADCOM=y
# CONFIG_B44 is not set
CONFIG_BNX2=m
CONFIG_CNIC=m
CONFIG_TIGON3=m
CONFIG_BNX2X=m
# CONFIG_NET_VENDOR_BROCADE is not set
# CONFIG_NET_CALXEDA_XGMAC is not set
CONFIG_NET_VENDOR_CHELSIO=y
# CONFIG_CHELSIO_T1 is not set
CONFIG_CHELSIO_T3=m
CONFIG_CHELSIO_T4=m
CONFIG_CHELSIO_T4VF=m
# CONFIG_NET_VENDOR_CISCO is not set
# CONFIG_DNET is not set
# CONFIG_NET_VENDOR_DEC is not set
CONFIG_NET_VENDOR_DLINK=y
# CONFIG_DL2K is not set
# CONFIG_SUNDANCE is not set
# CONFIG_NET_VENDOR_EMULEX is not set
CONFIG_NET_VENDOR_EXAR=y
# CONFIG_S2IO is not set
CONFIG_VXGE=m
CONFIG_VXGE_DEBUG_TRACE_ALL=y
CONFIG_NET_VENDOR_HP=y
CONFIG_HP100=m
# CONFIG_NET_VENDOR_INTEL is not set
# CONFIG_IP1000 is not set
CONFIG_JME=m
CONFIG_NET_VENDOR_MARVELL=y
# CONFIG_SKGE is not set
CONFIG_SKY2=m
# CONFIG_SKY2_DEBUG is not set
# CONFIG_NET_VENDOR_MELLANOX is not set
# CONFIG_NET_VENDOR_MICREL is not set
# CONFIG_NET_VENDOR_MICROCHIP is not set
# CONFIG_NET_VENDOR_MYRI is not set
# CONFIG_FEALNX is not set
# CONFIG_NET_VENDOR_NATSEMI is not set
# CONFIG_NET_VENDOR_NVIDIA is not set
CONFIG_NET_VENDOR_OKI=y
# CONFIG_PCH_GBE is not set
CONFIG_ETHOC=m
# CONFIG_NET_PACKET_ENGINE is not set
CONFIG_NET_VENDOR_QLOGIC=y
# CONFIG_QLA3XXX is not set
# CONFIG_QLCNIC is not set
CONFIG_QLGE=m
# CONFIG_NETXEN_NIC is not set
CONFIG_NET_VENDOR_REALTEK=y
# CONFIG_8139CP is not set
CONFIG_8139TOO=m
# CONFIG_8139TOO_PIO is not set
CONFIG_8139TOO_TUNE_TWISTER=y
# CONFIG_8139TOO_8129 is not set
CONFIG_8139_OLD_RX_RESET=y
# CONFIG_R8169 is not set
CONFIG_NET_VENDOR_RDC=y
# CONFIG_R6040 is not set
# CONFIG_NET_VENDOR_SEEQ is not set
# CONFIG_NET_VENDOR_SILAN is not set
CONFIG_NET_VENDOR_SIS=y
# CONFIG_SIS900 is not set
CONFIG_SIS190=m
CONFIG_SFC=m
CONFIG_SFC_MCDI_MON=y
CONFIG_NET_VENDOR_SMSC=y
CONFIG_EPIC100=m
CONFIG_SMSC9420=m
# CONFIG_NET_VENDOR_STMICRO is not set
# CONFIG_NET_VENDOR_SUN is not set
CONFIG_NET_VENDOR_TEHUTI=y
# CONFIG_TEHUTI is not set
# CONFIG_NET_VENDOR_TI is not set
CONFIG_NET_VENDOR_VIA=y
# CONFIG_VIA_RHINE is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_NET_VENDOR_WIZNET is not set
CONFIG_FDDI=m
# CONFIG_DEFXX is not set
CONFIG_SKFP=m
# CONFIG_HIPPI is not set
# CONFIG_NET_SB1000 is not set
CONFIG_PHYLIB=m

#
# MII PHY device drivers
#
CONFIG_AT803X_PHY=m
CONFIG_AMD_PHY=m
# CONFIG_MARVELL_PHY is not set
CONFIG_DAVICOM_PHY=m
CONFIG_QSEMI_PHY=m
CONFIG_LXT_PHY=m
# CONFIG_CICADA_PHY is not set
CONFIG_VITESSE_PHY=m
CONFIG_SMSC_PHY=m
# CONFIG_BROADCOM_PHY is not set
CONFIG_BCM87XX_PHY=m
# CONFIG_ICPLUS_PHY is not set
# CONFIG_REALTEK_PHY is not set
# CONFIG_NATIONAL_PHY is not set
# CONFIG_STE10XP is not set
# CONFIG_LSI_ET1011C_PHY is not set
CONFIG_MICREL_PHY=m
CONFIG_MDIO_BITBANG=m
CONFIG_MICREL_KS8995MA=m
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_WLAN is not set

#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#
CONFIG_WAN=y
# CONFIG_HDLC is not set
# CONFIG_DLCI is not set
CONFIG_LAPBETHER=m
# CONFIG_X25_ASY is not set
CONFIG_SBNI=m
# CONFIG_SBNI_MULTILINE is not set
# CONFIG_IEEE802154_DRIVERS is not set
# CONFIG_XEN_NETDEV_FRONTEND is not set
CONFIG_VMXNET3=m
# CONFIG_ISDN is not set

#
# Input device support
#
CONFIG_INPUT=y
CONFIG_INPUT_FF_MEMLESS=m
CONFIG_INPUT_POLLDEV=m
# CONFIG_INPUT_SPARSEKMAP is not set
CONFIG_INPUT_MATRIXKMAP=m

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_INPUT_JOYDEV=m
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ADP5588=m
CONFIG_KEYBOARD_ADP5589=m
CONFIG_KEYBOARD_ATKBD=y
CONFIG_KEYBOARD_QT1070=m
CONFIG_KEYBOARD_QT2160=m
CONFIG_KEYBOARD_LKKBD=m
CONFIG_KEYBOARD_TCA6416=m
# CONFIG_KEYBOARD_TCA8418 is not set
# CONFIG_KEYBOARD_LM8323 is not set
CONFIG_KEYBOARD_LM8333=m
CONFIG_KEYBOARD_MAX7359=m
# CONFIG_KEYBOARD_MCS is not set
CONFIG_KEYBOARD_MPR121=m
CONFIG_KEYBOARD_NEWTON=m
# CONFIG_KEYBOARD_OPENCORES is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
CONFIG_KEYBOARD_SUNKBD=m
# CONFIG_KEYBOARD_STMPE is not set
# CONFIG_KEYBOARD_OMAP4 is not set
CONFIG_KEYBOARD_XTKBD=m
CONFIG_INPUT_MOUSE=y
# CONFIG_MOUSE_PS2 is not set
CONFIG_MOUSE_SERIAL=m
CONFIG_MOUSE_VSXXXAA=m
# CONFIG_MOUSE_SYNAPTICS_I2C is not set
CONFIG_INPUT_JOYSTICK=y
CONFIG_JOYSTICK_ANALOG=m
# CONFIG_JOYSTICK_A3D is not set
CONFIG_JOYSTICK_ADI=m
CONFIG_JOYSTICK_COBRA=m
# CONFIG_JOYSTICK_GF2K is not set
# CONFIG_JOYSTICK_GRIP is not set
CONFIG_JOYSTICK_GRIP_MP=m
CONFIG_JOYSTICK_GUILLEMOT=m
# CONFIG_JOYSTICK_INTERACT is not set
CONFIG_JOYSTICK_SIDEWINDER=m
# CONFIG_JOYSTICK_TMDC is not set
CONFIG_JOYSTICK_IFORCE=m
# CONFIG_JOYSTICK_IFORCE_232 is not set
CONFIG_JOYSTICK_WARRIOR=m
CONFIG_JOYSTICK_MAGELLAN=m
CONFIG_JOYSTICK_SPACEORB=m
# CONFIG_JOYSTICK_SPACEBALL is not set
# CONFIG_JOYSTICK_STINGER is not set
# CONFIG_JOYSTICK_TWIDJOY is not set
CONFIG_JOYSTICK_ZHENHUA=m
# CONFIG_JOYSTICK_AS5011 is not set
CONFIG_JOYSTICK_JOYDUMP=m
CONFIG_INPUT_TABLET=y
CONFIG_INPUT_TOUCHSCREEN=y
CONFIG_TOUCHSCREEN_ADS7846=m
CONFIG_TOUCHSCREEN_AD7877=m
# CONFIG_TOUCHSCREEN_AD7879 is not set
# CONFIG_TOUCHSCREEN_ATMEL_MXT is not set
# CONFIG_TOUCHSCREEN_BU21013 is not set
# CONFIG_TOUCHSCREEN_CYTTSP_CORE is not set
# CONFIG_TOUCHSCREEN_DYNAPRO is not set
CONFIG_TOUCHSCREEN_HAMPSHIRE=m
CONFIG_TOUCHSCREEN_EETI=m
CONFIG_TOUCHSCREEN_EGALAX=m
# CONFIG_TOUCHSCREEN_FUJITSU is not set
CONFIG_TOUCHSCREEN_ILI210X=m
CONFIG_TOUCHSCREEN_GUNZE=m
CONFIG_TOUCHSCREEN_ELO=m
CONFIG_TOUCHSCREEN_WACOM_W8001=m
# CONFIG_TOUCHSCREEN_WACOM_I2C is not set
# CONFIG_TOUCHSCREEN_MAX11801 is not set
# CONFIG_TOUCHSCREEN_MCS5000 is not set
# CONFIG_TOUCHSCREEN_MMS114 is not set
# CONFIG_TOUCHSCREEN_MTOUCH is not set
CONFIG_TOUCHSCREEN_INEXIO=m
# CONFIG_TOUCHSCREEN_MK712 is not set
CONFIG_TOUCHSCREEN_PENMOUNT=m
# CONFIG_TOUCHSCREEN_EDT_FT5X06 is not set
CONFIG_TOUCHSCREEN_TOUCHRIGHT=m
CONFIG_TOUCHSCREEN_TOUCHWIN=m
CONFIG_TOUCHSCREEN_PIXCIR=m
# CONFIG_TOUCHSCREEN_WM831X is not set
# CONFIG_TOUCHSCREEN_MC13783 is not set
CONFIG_TOUCHSCREEN_TOUCHIT213=m
# CONFIG_TOUCHSCREEN_TSC_SERIO is not set
CONFIG_TOUCHSCREEN_TSC2005=m
CONFIG_TOUCHSCREEN_TSC2007=m
# CONFIG_TOUCHSCREEN_PCAP is not set
CONFIG_TOUCHSCREEN_ST1232=m
# CONFIG_TOUCHSCREEN_STMPE is not set
# CONFIG_TOUCHSCREEN_TPS6507X is not set
# CONFIG_INPUT_MISC is not set
CONFIG_INPUT_XEN_KBDDEV_FRONTEND=m

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=m
CONFIG_SERIO_CT82C710=m
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
CONFIG_SERIO_RAW=m
CONFIG_SERIO_ALTERA_PS2=m
CONFIG_SERIO_PS2MULT=m
CONFIG_SERIO_ARC_PS2=m
CONFIG_GAMEPORT=m
# CONFIG_GAMEPORT_NS558 is not set
CONFIG_GAMEPORT_L4=m
# CONFIG_GAMEPORT_EMU10K1 is not set
CONFIG_GAMEPORT_FM801=m

#
# Character devices
#
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_VT_CONSOLE_SLEEP=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_UNIX98_PTYS=y
CONFIG_DEVPTS_MULTIPLE_INSTANCES=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
CONFIG_SERIAL_NONSTANDARD=y
CONFIG_ROCKETPORT=m
CONFIG_CYCLADES=m
# CONFIG_CYZ_INTR is not set
# CONFIG_MOXA_INTELLIO is not set
# CONFIG_MOXA_SMARTIO is not set
# CONFIG_SYNCLINK is not set
# CONFIG_SYNCLINKMP is not set
CONFIG_SYNCLINK_GT=m
# CONFIG_NOZOMI is not set
CONFIG_ISI=m
CONFIG_N_HDLC=m
# CONFIG_N_GSM is not set
# CONFIG_TRACE_SINK is not set
CONFIG_DEVKMEM=y
# CONFIG_STALDRV is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_PNP=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
# CONFIG_SERIAL_8250_SHARE_IRQ is not set
CONFIG_SERIAL_8250_DETECT_IRQ=y
CONFIG_SERIAL_8250_RSA=y

#
# Non-8250 serial port support
#
CONFIG_SERIAL_KGDB_NMI=y
CONFIG_SERIAL_MAX3100=m
CONFIG_SERIAL_MAX310X=y
# CONFIG_SERIAL_MRST_MAX3110 is not set
CONFIG_SERIAL_MFD_HSU=m
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_CONSOLE_POLL=y
CONFIG_SERIAL_JSM=m
CONFIG_SERIAL_SCCNXP=m
CONFIG_SERIAL_TIMBERDALE=m
CONFIG_SERIAL_ALTERA_JTAGUART=m
# CONFIG_SERIAL_ALTERA_UART is not set
CONFIG_SERIAL_PCH_UART=m
# CONFIG_SERIAL_XILINX_PS_UART is not set
CONFIG_HVC_DRIVER=y
CONFIG_HVC_IRQ=y
CONFIG_HVC_XEN=y
# CONFIG_HVC_XEN_FRONTEND is not set
CONFIG_VIRTIO_CONSOLE=y
CONFIG_IPMI_HANDLER=m
CONFIG_IPMI_PANIC_EVENT=y
CONFIG_IPMI_PANIC_STRING=y
# CONFIG_IPMI_DEVICE_INTERFACE is not set
CONFIG_IPMI_SI=m
# CONFIG_IPMI_WATCHDOG is not set
# CONFIG_IPMI_POWEROFF is not set
CONFIG_HW_RANDOM=m
# CONFIG_HW_RANDOM_TIMERIOMEM is not set
CONFIG_HW_RANDOM_INTEL=m
# CONFIG_HW_RANDOM_AMD is not set
# CONFIG_HW_RANDOM_VIA is not set
CONFIG_HW_RANDOM_VIRTIO=m
CONFIG_HW_RANDOM_TPM=m
CONFIG_NVRAM=m
# CONFIG_RTC is not set
# CONFIG_GEN_RTC is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_MWAVE is not set
# CONFIG_RAW_DRIVER is not set
CONFIG_HPET=y
# CONFIG_HPET_MMAP is not set
# CONFIG_HANGCHECK_TIMER is not set
CONFIG_TCG_TPM=y
CONFIG_TCG_TIS=y
CONFIG_TCG_TIS_I2C_INFINEON=m
# CONFIG_TCG_NSC is not set
# CONFIG_TCG_ATMEL is not set
CONFIG_TCG_INFINEON=m
CONFIG_TELCLOCK=m
CONFIG_DEVPORT=y
CONFIG_I2C=m
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_COMPAT=y
# CONFIG_I2C_CHARDEV is not set
CONFIG_I2C_MUX=m

#
# Multiplexer I2C Chip support
#
# CONFIG_I2C_MUX_PCA9541 is not set
# CONFIG_I2C_MUX_PCA954x is not set
# CONFIG_I2C_HELPER_AUTO is not set
CONFIG_I2C_SMBUS=m

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=m
# CONFIG_I2C_ALGOPCF is not set
CONFIG_I2C_ALGOPCA=m

#
# I2C Hardware Bus support
#

#
# PC SMBus host controller drivers
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
CONFIG_I2C_AMD756=m
# CONFIG_I2C_AMD756_S4882 is not set
CONFIG_I2C_AMD8111=m
CONFIG_I2C_I801=m
CONFIG_I2C_ISCH=m
CONFIG_I2C_PIIX4=m
CONFIG_I2C_NFORCE2=m
CONFIG_I2C_NFORCE2_S4985=m
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_VIA is not set
CONFIG_I2C_VIAPRO=m

#
# ACPI drivers
#
CONFIG_I2C_SCMI=m

#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_DESIGNWARE_PCI is not set
# CONFIG_I2C_EG20T is not set
# CONFIG_I2C_INTEL_MID is not set
# CONFIG_I2C_OCORES is not set
CONFIG_I2C_PCA_PLATFORM=m
# CONFIG_I2C_PXA_PCI is not set
# CONFIG_I2C_SIMTEC is not set
# CONFIG_I2C_XILINX is not set

#
# External I2C/SMBus adapter drivers
#
CONFIG_I2C_PARPORT_LIGHT=m
# CONFIG_I2C_TAOS_EVM is not set

#
# Other I2C/SMBus bus drivers
#
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_DEBUG_CORE is not set
CONFIG_I2C_DEBUG_ALGO=y
CONFIG_I2C_DEBUG_BUS=y
CONFIG_SPI=y
# CONFIG_SPI_DEBUG is not set
CONFIG_SPI_MASTER=y

#
# SPI Master Controller Drivers
#
# CONFIG_SPI_ALTERA is not set
CONFIG_SPI_BITBANG=m
# CONFIG_SPI_PXA2XX_PCI is not set
# CONFIG_SPI_SC18IS602 is not set
# CONFIG_SPI_TOPCLIFF_PCH is not set
CONFIG_SPI_XCOMM=m
# CONFIG_SPI_XILINX is not set
CONFIG_SPI_DESIGNWARE=m
CONFIG_SPI_DW_PCI=m
# CONFIG_SPI_DW_MID_DMA is not set

#
# SPI Protocol Masters
#
# CONFIG_SPI_SPIDEV is not set
# CONFIG_SPI_TLE62X0 is not set
# CONFIG_HSI is not set

#
# PPS support
#
CONFIG_PPS=m
# CONFIG_PPS_DEBUG is not set

#
# PPS clients support
#
# CONFIG_PPS_CLIENT_KTIMER is not set
CONFIG_PPS_CLIENT_LDISC=m
# CONFIG_PPS_CLIENT_GPIO is not set

#
# PPS generators support
#

#
# PTP clock support
#
# CONFIG_PTP_1588_CLOCK is not set
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
# CONFIG_GPIOLIB is not set
CONFIG_W1=m
CONFIG_W1_CON=y

#
# 1-wire Bus Masters
#
# CONFIG_W1_MASTER_MATROX is not set
# CONFIG_W1_MASTER_DS2482 is not set
CONFIG_W1_MASTER_DS1WM=m
# CONFIG_HDQ_MASTER_OMAP is not set

#
# 1-wire Slaves
#
# CONFIG_W1_SLAVE_THERM is not set
CONFIG_W1_SLAVE_SMEM=m
CONFIG_W1_SLAVE_DS2408=m
CONFIG_W1_SLAVE_DS2423=m
# CONFIG_W1_SLAVE_DS2431 is not set
CONFIG_W1_SLAVE_DS2433=m
CONFIG_W1_SLAVE_DS2433_CRC=y
CONFIG_W1_SLAVE_DS2760=m
CONFIG_W1_SLAVE_DS2780=m
CONFIG_W1_SLAVE_DS2781=m
CONFIG_W1_SLAVE_DS28E04=m
CONFIG_W1_SLAVE_BQ27000=m
CONFIG_POWER_SUPPLY=y
CONFIG_POWER_SUPPLY_DEBUG=y
CONFIG_PDA_POWER=m
# CONFIG_WM831X_BACKUP is not set
# CONFIG_WM831X_POWER is not set
CONFIG_TEST_POWER=m
# CONFIG_BATTERY_DS2760 is not set
CONFIG_BATTERY_DS2780=m
# CONFIG_BATTERY_DS2781 is not set
# CONFIG_BATTERY_DS2782 is not set
# CONFIG_BATTERY_SBS is not set
CONFIG_BATTERY_BQ27x00=m
# CONFIG_BATTERY_BQ27X00_I2C is not set
CONFIG_BATTERY_BQ27X00_PLATFORM=y
CONFIG_BATTERY_MAX17040=m
# CONFIG_BATTERY_MAX17042 is not set
CONFIG_CHARGER_PCF50633=m
# CONFIG_CHARGER_MAX8903 is not set
# CONFIG_CHARGER_LP8727 is not set
CONFIG_CHARGER_SMB347=m
CONFIG_POWER_AVS=y
CONFIG_HWMON=m
CONFIG_HWMON_VID=m
CONFIG_HWMON_DEBUG_CHIP=y

#
# Native drivers
#
CONFIG_SENSORS_ABITUGURU=m
CONFIG_SENSORS_ABITUGURU3=m
CONFIG_SENSORS_AD7314=m
# CONFIG_SENSORS_AD7414 is not set
CONFIG_SENSORS_AD7418=m
CONFIG_SENSORS_ADCXX=m
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
CONFIG_SENSORS_ADM1026=m
# CONFIG_SENSORS_ADM1029 is not set
# CONFIG_SENSORS_ADM1031 is not set
CONFIG_SENSORS_ADM9240=m
# CONFIG_SENSORS_ADT7410 is not set
CONFIG_SENSORS_ADT7411=m
# CONFIG_SENSORS_ADT7462 is not set
CONFIG_SENSORS_ADT7470=m
# CONFIG_SENSORS_ADT7475 is not set
# CONFIG_SENSORS_ASC7621 is not set
CONFIG_SENSORS_K8TEMP=m
CONFIG_SENSORS_K10TEMP=m
# CONFIG_SENSORS_FAM15H_POWER is not set
CONFIG_SENSORS_ASB100=m
CONFIG_SENSORS_ATXP1=m
CONFIG_SENSORS_DS620=m
CONFIG_SENSORS_DS1621=m
# CONFIG_SENSORS_I5K_AMB is not set
# CONFIG_SENSORS_F71805F is not set
CONFIG_SENSORS_F71882FG=m
CONFIG_SENSORS_F75375S=m
# CONFIG_SENSORS_FSCHMD is not set
# CONFIG_SENSORS_G760A is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_GL520SM is not set
# CONFIG_SENSORS_HIH6130 is not set
# CONFIG_SENSORS_CORETEMP is not set
# CONFIG_SENSORS_IBMAEM is not set
CONFIG_SENSORS_IBMPEX=m
CONFIG_SENSORS_IT87=m
CONFIG_SENSORS_JC42=m
# CONFIG_SENSORS_LINEAGE is not set
CONFIG_SENSORS_LM63=m
# CONFIG_SENSORS_LM70 is not set
CONFIG_SENSORS_LM73=m
# CONFIG_SENSORS_LM75 is not set
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM80 is not set
CONFIG_SENSORS_LM83=m
CONFIG_SENSORS_LM85=m
# CONFIG_SENSORS_LM87 is not set
# CONFIG_SENSORS_LM90 is not set
CONFIG_SENSORS_LM92=m
# CONFIG_SENSORS_LM93 is not set
# CONFIG_SENSORS_LTC4151 is not set
# CONFIG_SENSORS_LTC4215 is not set
CONFIG_SENSORS_LTC4245=m
# CONFIG_SENSORS_LTC4261 is not set
# CONFIG_SENSORS_LM95241 is not set
# CONFIG_SENSORS_LM95245 is not set
# CONFIG_SENSORS_MAX1111 is not set
CONFIG_SENSORS_MAX16065=m
CONFIG_SENSORS_MAX1619=m
# CONFIG_SENSORS_MAX1668 is not set
CONFIG_SENSORS_MAX197=m
# CONFIG_SENSORS_MAX6639 is not set
# CONFIG_SENSORS_MAX6642 is not set
CONFIG_SENSORS_MAX6650=m
CONFIG_SENSORS_MCP3021=m
CONFIG_SENSORS_NTC_THERMISTOR=m
# CONFIG_SENSORS_PC87360 is not set
CONFIG_SENSORS_PC87427=m
CONFIG_SENSORS_PCF8591=m
# CONFIG_PMBUS is not set
CONFIG_SENSORS_SHT21=m
# CONFIG_SENSORS_SIS5595 is not set
CONFIG_SENSORS_SMM665=m
# CONFIG_SENSORS_DME1737 is not set
CONFIG_SENSORS_EMC1403=m
CONFIG_SENSORS_EMC2103=m
# CONFIG_SENSORS_EMC6W201 is not set
CONFIG_SENSORS_SMSC47M1=m
# CONFIG_SENSORS_SMSC47M192 is not set
# CONFIG_SENSORS_SMSC47B397 is not set
CONFIG_SENSORS_SCH56XX_COMMON=m
CONFIG_SENSORS_SCH5627=m
# CONFIG_SENSORS_SCH5636 is not set
CONFIG_SENSORS_ADS1015=m
CONFIG_SENSORS_ADS7828=m
# CONFIG_SENSORS_ADS7871 is not set
CONFIG_SENSORS_AMC6821=m
CONFIG_SENSORS_INA2XX=m
# CONFIG_SENSORS_THMC50 is not set
CONFIG_SENSORS_TMP102=m
CONFIG_SENSORS_TMP401=m
# CONFIG_SENSORS_TMP421 is not set
CONFIG_SENSORS_VIA_CPUTEMP=m
# CONFIG_SENSORS_VIA686A is not set
# CONFIG_SENSORS_VT1211 is not set
CONFIG_SENSORS_VT8231=m
CONFIG_SENSORS_W83781D=m
# CONFIG_SENSORS_W83791D is not set
CONFIG_SENSORS_W83792D=m
CONFIG_SENSORS_W83793=m
CONFIG_SENSORS_W83795=m
# CONFIG_SENSORS_W83795_FANCTRL is not set
# CONFIG_SENSORS_W83L785TS is not set
CONFIG_SENSORS_W83L786NG=m
CONFIG_SENSORS_W83627HF=m
# CONFIG_SENSORS_W83627EHF is not set
# CONFIG_SENSORS_WM831X is not set
CONFIG_SENSORS_APPLESMC=m
CONFIG_SENSORS_MC13783_ADC=m

#
# ACPI drivers
#
CONFIG_SENSORS_ACPI_POWER=m
# CONFIG_SENSORS_ATK0110 is not set
CONFIG_THERMAL=m
CONFIG_THERMAL_HWMON=y
CONFIG_FAIR_SHARE=y
CONFIG_STEP_WISE=y
CONFIG_USER_SPACE=y
# CONFIG_THERMAL_DEFAULT_GOV_STEP_WISE is not set
# CONFIG_THERMAL_DEFAULT_GOV_FAIR_SHARE is not set
CONFIG_THERMAL_DEFAULT_GOV_USER_SPACE=y
CONFIG_WATCHDOG=y
CONFIG_WATCHDOG_CORE=y
CONFIG_WATCHDOG_NOWAYOUT=y

#
# Watchdog Device Drivers
#
# CONFIG_SOFT_WATCHDOG is not set
# CONFIG_WM831X_WATCHDOG is not set
CONFIG_ACQUIRE_WDT=m
CONFIG_ADVANTECH_WDT=m
CONFIG_ALIM1535_WDT=m
CONFIG_ALIM7101_WDT=m
CONFIG_F71808E_WDT=m
# CONFIG_SP5100_TCO is not set
CONFIG_SC520_WDT=m
# CONFIG_SBC_FITPC2_WATCHDOG is not set
# CONFIG_EUROTECH_WDT is not set
CONFIG_IB700_WDT=m
CONFIG_IBMASR=m
CONFIG_WAFER_WDT=m
# CONFIG_I6300ESB_WDT is not set
# CONFIG_IE6XX_WDT is not set
# CONFIG_ITCO_WDT is not set
CONFIG_IT8712F_WDT=m
CONFIG_IT87_WDT=m
CONFIG_HP_WATCHDOG=m
CONFIG_HPWDT_NMI_DECODING=y
# CONFIG_SC1200_WDT is not set
CONFIG_PC87413_WDT=m
# CONFIG_NV_TCO is not set
# CONFIG_60XX_WDT is not set
CONFIG_SBC8360_WDT=m
CONFIG_CPU5_WDT=m
CONFIG_SMSC_SCH311X_WDT=m
CONFIG_SMSC37B787_WDT=m
CONFIG_VIA_WDT=m
# CONFIG_W83627HF_WDT is not set
CONFIG_W83697HF_WDT=m
CONFIG_W83697UG_WDT=m
# CONFIG_W83877F_WDT is not set
# CONFIG_W83977F_WDT is not set
CONFIG_MACHZ_WDT=m
CONFIG_SBC_EPX_C3_WATCHDOG=m
# CONFIG_XEN_WDT is not set

#
# PCI-based Watchdog Cards
#
CONFIG_PCIPCWATCHDOG=m
# CONFIG_WDTPCI is not set
CONFIG_SSB_POSSIBLE=y

#
# Sonics Silicon Backplane
#
CONFIG_SSB=m
CONFIG_SSB_PCIHOST_POSSIBLE=y
# CONFIG_SSB_PCIHOST is not set
CONFIG_SSB_DEBUG=y
CONFIG_BCMA_POSSIBLE=y

#
# Broadcom specific AMBA
#
# CONFIG_BCMA is not set

#
# Multifunction device drivers
#
CONFIG_MFD_CORE=y
# CONFIG_MFD_SM501 is not set
# CONFIG_HTC_PASIC3 is not set
CONFIG_MFD_LM3533=m
CONFIG_TPS6105X=m
CONFIG_TPS6507X=m
CONFIG_MFD_TPS65217=m
CONFIG_MFD_STMPE=y

#
# STMPE Interface Drivers
#
CONFIG_STMPE_SPI=y
# CONFIG_MFD_TMIO is not set
# CONFIG_MFD_DA9052_SPI is not set
# CONFIG_MFD_ARIZONA_I2C is not set
# CONFIG_MFD_ARIZONA_SPI is not set
CONFIG_MFD_WM831X=y
CONFIG_MFD_WM831X_SPI=y
CONFIG_MFD_PCF50633=m
# CONFIG_PCF50633_ADC is not set
CONFIG_PCF50633_GPIO=m
CONFIG_MFD_MC13783=m
CONFIG_MFD_MC13XXX=m
CONFIG_MFD_MC13XXX_SPI=m
# CONFIG_MFD_MC13XXX_I2C is not set
# CONFIG_ABX500_CORE is not set
CONFIG_EZX_PCAP=y
CONFIG_MFD_CS5535=m
CONFIG_LPC_SCH=m
CONFIG_LPC_ICH=m
CONFIG_MFD_RDC321X=m
# CONFIG_MFD_JANZ_CMODIO is not set
# CONFIG_MFD_VX855 is not set
CONFIG_MFD_WL1273_CORE=m
CONFIG_REGULATOR=y
CONFIG_REGULATOR_DEBUG=y
# CONFIG_REGULATOR_DUMMY is not set
CONFIG_REGULATOR_FIXED_VOLTAGE=m
CONFIG_REGULATOR_VIRTUAL_CONSUMER=m
CONFIG_REGULATOR_USERSPACE_CONSUMER=m
# CONFIG_REGULATOR_AD5398 is not set
CONFIG_REGULATOR_FAN53555=m
CONFIG_REGULATOR_MC13XXX_CORE=m
# CONFIG_REGULATOR_MC13783 is not set
CONFIG_REGULATOR_MC13892=m
# CONFIG_REGULATOR_ISL6271A is not set
CONFIG_REGULATOR_MAX1586=m
CONFIG_REGULATOR_MAX8649=m
CONFIG_REGULATOR_MAX8660=m
# CONFIG_REGULATOR_MAX8952 is not set
CONFIG_REGULATOR_PCAP=m
CONFIG_REGULATOR_LP3971=m
# CONFIG_REGULATOR_LP3972 is not set
# CONFIG_REGULATOR_PCF50633 is not set
CONFIG_REGULATOR_TPS51632=m
CONFIG_REGULATOR_TPS6105X=m
# CONFIG_REGULATOR_TPS62360 is not set
CONFIG_REGULATOR_TPS65023=m
CONFIG_REGULATOR_TPS6507X=m
# CONFIG_REGULATOR_TPS65217 is not set
# CONFIG_REGULATOR_TPS6524X is not set
CONFIG_REGULATOR_WM831X=m
# CONFIG_MEDIA_SUPPORT is not set

#
# Graphics support
#
CONFIG_AGP=m
CONFIG_AGP_AMD64=m
# CONFIG_AGP_INTEL is not set
CONFIG_AGP_SIS=m
CONFIG_AGP_VIA=m
CONFIG_VGA_ARB=y
CONFIG_VGA_ARB_MAX_GPUS=16
# CONFIG_VGA_SWITCHEROO is not set
CONFIG_DRM=m
CONFIG_DRM_KMS_HELPER=m
# CONFIG_DRM_LOAD_EDID_FIRMWARE is not set
CONFIG_DRM_TTM=m
CONFIG_DRM_TDFX=m
# CONFIG_DRM_R128 is not set
CONFIG_DRM_RADEON=m
# CONFIG_DRM_RADEON_KMS is not set
# CONFIG_DRM_NOUVEAU is not set

#
# I2C encoder or helper chips
#
# CONFIG_DRM_I2C_CH7006 is not set
# CONFIG_DRM_I2C_SIL164 is not set
# CONFIG_DRM_MGA is not set
CONFIG_DRM_SIS=m
# CONFIG_DRM_VIA is not set
# CONFIG_DRM_SAVAGE is not set
CONFIG_DRM_VMWGFX=m
# CONFIG_DRM_VMWGFX_FBCON is not set
CONFIG_DRM_GMA500=m
CONFIG_DRM_GMA600=y
# CONFIG_DRM_GMA3600 is not set
CONFIG_DRM_AST=m
# CONFIG_DRM_MGAG200 is not set
CONFIG_DRM_CIRRUS_QEMU=m
# CONFIG_STUB_POULSBO is not set
CONFIG_VGASTATE=m
CONFIG_VIDEO_OUTPUT_CONTROL=m
CONFIG_FB=m
CONFIG_FIRMWARE_EDID=y
CONFIG_FB_DDC=m
# CONFIG_FB_BOOT_VESA_SUPPORT is not set
CONFIG_FB_CFB_FILLRECT=m
CONFIG_FB_CFB_COPYAREA=m
CONFIG_FB_CFB_IMAGEBLIT=m
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
CONFIG_FB_SYS_FILLRECT=m
CONFIG_FB_SYS_COPYAREA=m
CONFIG_FB_SYS_IMAGEBLIT=m
# CONFIG_FB_FOREIGN_ENDIAN is not set
CONFIG_FB_SYS_FOPS=m
# CONFIG_FB_WMT_GE_ROPS is not set
CONFIG_FB_DEFERRED_IO=y
CONFIG_FB_SVGALIB=m
# CONFIG_FB_MACMODES is not set
CONFIG_FB_BACKLIGHT=y
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y

#
# Frame buffer hardware drivers
#
CONFIG_FB_CIRRUS=m
CONFIG_FB_PM2=m
CONFIG_FB_PM2_FIFO_DISCONNECT=y
# CONFIG_FB_CYBER2000 is not set
CONFIG_FB_ARC=m
# CONFIG_FB_VGA16 is not set
CONFIG_FB_UVESA=m
# CONFIG_FB_N411 is not set
# CONFIG_FB_HGA is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_NVIDIA is not set
CONFIG_FB_RIVA=m
CONFIG_FB_RIVA_I2C=y
# CONFIG_FB_RIVA_DEBUG is not set
# CONFIG_FB_RIVA_BACKLIGHT is not set
CONFIG_FB_I740=m
# CONFIG_FB_LE80578 is not set
# CONFIG_FB_MATROX is not set
CONFIG_FB_RADEON=m
CONFIG_FB_RADEON_I2C=y
CONFIG_FB_RADEON_BACKLIGHT=y
# CONFIG_FB_RADEON_DEBUG is not set
# CONFIG_FB_ATY128 is not set
CONFIG_FB_ATY=m
CONFIG_FB_ATY_CT=y
# CONFIG_FB_ATY_GENERIC_LCD is not set
CONFIG_FB_ATY_GX=y
# CONFIG_FB_ATY_BACKLIGHT is not set
# CONFIG_FB_S3 is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_VIA is not set
# CONFIG_FB_NEOMAGIC is not set
CONFIG_FB_KYRO=m
CONFIG_FB_3DFX=m
# CONFIG_FB_3DFX_ACCEL is not set
# CONFIG_FB_3DFX_I2C is not set
CONFIG_FB_VOODOO1=m
CONFIG_FB_VT8623=m
# CONFIG_FB_TRIDENT is not set
CONFIG_FB_ARK=m
CONFIG_FB_PM3=m
CONFIG_FB_CARMINE=m
CONFIG_FB_CARMINE_DRAM_EVAL=y
# CONFIG_CARMINE_DRAM_CUSTOM is not set
# CONFIG_FB_GEODE is not set
CONFIG_FB_TMIO=m
CONFIG_FB_TMIO_ACCELL=y
# CONFIG_FB_VIRTUAL is not set
CONFIG_XEN_FBDEV_FRONTEND=m
# CONFIG_FB_METRONOME is not set
CONFIG_FB_MB862XX=m
CONFIG_FB_MB862XX_PCI_GDC=y
# CONFIG_FB_MB862XX_I2C is not set
# CONFIG_FB_BROADSHEET is not set
# CONFIG_FB_AUO_K190X is not set
# CONFIG_EXYNOS_VIDEO is not set
CONFIG_BACKLIGHT_LCD_SUPPORT=y
# CONFIG_LCD_CLASS_DEVICE is not set
CONFIG_BACKLIGHT_CLASS_DEVICE=m
# CONFIG_BACKLIGHT_GENERIC is not set
CONFIG_BACKLIGHT_LM3533=m
# CONFIG_BACKLIGHT_PWM is not set
# CONFIG_BACKLIGHT_APPLE is not set
CONFIG_BACKLIGHT_SAHARA=m
# CONFIG_BACKLIGHT_WM831X is not set
# CONFIG_BACKLIGHT_ADP8860 is not set
# CONFIG_BACKLIGHT_ADP8870 is not set
CONFIG_BACKLIGHT_PCF50633=m
CONFIG_BACKLIGHT_LM3630=m
# CONFIG_BACKLIGHT_LM3639 is not set
CONFIG_BACKLIGHT_LP855X=m
CONFIG_BACKLIGHT_TPS65217=m

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_VGACON_SOFT_SCROLLBACK=y
CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=m
CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
# CONFIG_LOGO is not set
# CONFIG_SOUND is not set

#
# HID support
#
# CONFIG_HID is not set
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB_ARCH_HAS_XHCI=y
# CONFIG_USB_SUPPORT is not set
CONFIG_UWB=m
CONFIG_UWB_WHCI=m
# CONFIG_MMC is not set
CONFIG_MEMSTICK=m
CONFIG_MEMSTICK_DEBUG=y

#
# MemoryStick drivers
#
# CONFIG_MEMSTICK_UNSAFE_RESUME is not set
CONFIG_MSPRO_BLOCK=m
CONFIG_MS_BLOCK=m

#
# MemoryStick Host Controller Drivers
#
# CONFIG_MEMSTICK_TIFM_MS is not set
# CONFIG_MEMSTICK_JMICRON_38X is not set
CONFIG_MEMSTICK_R592=m
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=m

#
# LED drivers
#
# CONFIG_LEDS_LM3530 is not set
CONFIG_LEDS_LM3533=m
# CONFIG_LEDS_LM3642 is not set
# CONFIG_LEDS_PCA9532 is not set
# CONFIG_LEDS_LP3944 is not set
# CONFIG_LEDS_LP5521 is not set
CONFIG_LEDS_LP5523=m
CONFIG_LEDS_CLEVO_MAIL=m
CONFIG_LEDS_PCA955X=m
# CONFIG_LEDS_PCA9633 is not set
CONFIG_LEDS_WM831X_STATUS=m
# CONFIG_LEDS_DAC124S085 is not set
# CONFIG_LEDS_REGULATOR is not set
# CONFIG_LEDS_BD2802 is not set
# CONFIG_LEDS_INTEL_SS4200 is not set
# CONFIG_LEDS_MC13783 is not set
CONFIG_LEDS_TCA6507=m
CONFIG_LEDS_LM355x=m
CONFIG_LEDS_OT200=m
CONFIG_LEDS_BLINKM=m
CONFIG_LEDS_TRIGGERS=y

#
# LED Triggers
#
CONFIG_LEDS_TRIGGER_TIMER=m
CONFIG_LEDS_TRIGGER_ONESHOT=m
# CONFIG_LEDS_TRIGGER_HEARTBEAT is not set
# CONFIG_LEDS_TRIGGER_BACKLIGHT is not set
CONFIG_LEDS_TRIGGER_CPU=y
CONFIG_LEDS_TRIGGER_DEFAULT_ON=m

#
# iptables trigger is under Netfilter config (LED target)
#
# CONFIG_LEDS_TRIGGER_TRANSIENT is not set
# CONFIG_ACCESSIBILITY is not set
# CONFIG_INFINIBAND is not set
CONFIG_EDAC=y

#
# Reporting subsystems
#
# CONFIG_EDAC_LEGACY_SYSFS is not set
# CONFIG_EDAC_DEBUG is not set
CONFIG_EDAC_DECODE_MCE=m
# CONFIG_EDAC_MCE_INJ is not set
# CONFIG_EDAC_MM_EDAC is not set
# CONFIG_RTC_CLASS is not set
CONFIG_DMADEVICES=y
CONFIG_DMADEVICES_DEBUG=y
CONFIG_DMADEVICES_VDEBUG=y

#
# DMA Devices
#
CONFIG_INTEL_MID_DMAC=m
CONFIG_INTEL_IOATDMA=m
CONFIG_TIMB_DMA=m
CONFIG_PCH_DMA=m
CONFIG_DMA_ENGINE=y

#
# DMA Clients
#
# CONFIG_NET_DMA is not set
# CONFIG_ASYNC_TX_DMA is not set
CONFIG_DMATEST=m
CONFIG_DCA=m
CONFIG_AUXDISPLAY=y
CONFIG_UIO=m
# CONFIG_UIO_CIF is not set
CONFIG_UIO_PDRV=m
# CONFIG_UIO_PDRV_GENIRQ is not set
CONFIG_UIO_AEC=m
# CONFIG_UIO_SERCOS3 is not set
CONFIG_UIO_PCI_GENERIC=m
CONFIG_UIO_NETX=m
CONFIG_VIRTIO=y

#
# Virtio drivers
#
CONFIG_VIRTIO_PCI=y
# CONFIG_VIRTIO_BALLOON is not set
CONFIG_VIRTIO_MMIO=m
# CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES is not set

#
# Microsoft Hyper-V guest support
#
# CONFIG_HYPERV is not set

#
# Xen driver support
#
CONFIG_XEN_BALLOON=y
# CONFIG_XEN_SCRUB_PAGES is not set
CONFIG_XEN_DEV_EVTCHN=m
# CONFIG_XEN_BACKEND is not set
CONFIG_XENFS=m
# CONFIG_XEN_COMPAT_XENFS is not set
CONFIG_XEN_SYS_HYPERVISOR=y
CONFIG_XEN_XENBUS_FRONTEND=m
# CONFIG_XEN_GNTDEV is not set
CONFIG_XEN_GRANT_DEV_ALLOC=m
CONFIG_SWIOTLB_XEN=y
CONFIG_XEN_PRIVCMD=m
# CONFIG_XEN_MCE_LOG is not set
CONFIG_STAGING=y
# CONFIG_ET131X is not set
# CONFIG_SLICOSS is not set
CONFIG_ECHO=m
CONFIG_COMEDI=m
# CONFIG_COMEDI_DEBUG is not set
CONFIG_COMEDI_DEFAULT_BUF_SIZE_KB=2048
CONFIG_COMEDI_DEFAULT_BUF_MAXSIZE_KB=20480
# CONFIG_COMEDI_MISC_DRIVERS is not set
# CONFIG_COMEDI_PCI_DRIVERS is not set
CONFIG_COMEDI_8255=m
# CONFIG_RTS_PSTOR is not set
# CONFIG_DX_SEP is not set
# CONFIG_ZRAM is not set
CONFIG_ZSMALLOC=m
# CONFIG_FB_SM7XX is not set
# CONFIG_CRYSTALHD is not set
# CONFIG_FB_XGI is not set
# CONFIG_ACPI_QUICKSTART is not set
# CONFIG_FT1000 is not set

#
# Speakup console speech
#
# CONFIG_SPEAKUP is not set
CONFIG_TOUCHSCREEN_SYNAPTICS_I2C_RMI4=m
# CONFIG_STAGING_MEDIA is not set

#
# Android
#
CONFIG_ANDROID=y
# CONFIG_ANDROID_BINDER_IPC is not set
CONFIG_ASHMEM=y
# CONFIG_ANDROID_LOGGER is not set
CONFIG_ANDROID_TIMED_OUTPUT=y
# CONFIG_ANDROID_LOW_MEMORY_KILLER is not set
# CONFIG_PHONE is not set
CONFIG_IPACK_BUS=m
CONFIG_BOARD_TPCI200=m
# CONFIG_SERIAL_IPOCTAL is not set
CONFIG_WIMAX_GDM72XX=m
# CONFIG_WIMAX_GDM72XX_QOS is not set
# CONFIG_WIMAX_GDM72XX_K_MODE is not set
# CONFIG_WIMAX_GDM72XX_WIMAX2 is not set
CONFIG_NET_VENDOR_SILICOM=y
CONFIG_SBYPASS=m
# CONFIG_BPCTL is not set
# CONFIG_X86_PLATFORM_DEVICES is not set

#
# Hardware Spinlock drivers
#
CONFIG_CLKEVT_I8253=y
CONFIG_I8253_LOCK=y
CONFIG_CLKBLD_I8253=y
# CONFIG_IOMMU_SUPPORT is not set

#
# Remoteproc drivers (EXPERIMENTAL)
#
# CONFIG_STE_MODEM_RPROC is not set

#
# Rpmsg drivers (EXPERIMENTAL)
#
# CONFIG_VIRT_DRIVERS is not set
CONFIG_PM_DEVFREQ=y

#
# DEVFREQ Governors
#
CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND=y
CONFIG_DEVFREQ_GOV_PERFORMANCE=y
# CONFIG_DEVFREQ_GOV_POWERSAVE is not set
CONFIG_DEVFREQ_GOV_USERSPACE=y

#
# DEVFREQ Drivers
#
CONFIG_EXTCON=m

#
# Extcon Device Drivers
#
CONFIG_MEMORY=y
# CONFIG_IIO is not set
# CONFIG_VME_BUS is not set
CONFIG_PWM=y

#
# Firmware Drivers
#
CONFIG_EDD=m
# CONFIG_EDD_OFF is not set
CONFIG_FIRMWARE_MEMMAP=y
# CONFIG_DELL_RBU is not set
CONFIG_DCDBAS=m
# CONFIG_DMIID is not set
# CONFIG_DMI_SYSFS is not set
# CONFIG_ISCSI_IBFT_FIND is not set
CONFIG_GOOGLE_FIRMWARE=y

#
# Google Firmware Drivers
#
# CONFIG_GOOGLE_SMI is not set
# CONFIG_GOOGLE_MEMCONSOLE is not set

#
# File systems
#
CONFIG_DCACHE_WORD_ACCESS=y
CONFIG_EXT2_FS=m
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
# CONFIG_EXT2_FS_SECURITY is not set
CONFIG_EXT2_FS_XIP=y
CONFIG_EXT3_FS=m
CONFIG_EXT3_DEFAULTS_TO_ORDERED=y
# CONFIG_EXT3_FS_XATTR is not set
CONFIG_EXT4_FS=m
CONFIG_EXT4_FS_XATTR=y
CONFIG_EXT4_FS_POSIX_ACL=y
CONFIG_EXT4_FS_SECURITY=y
CONFIG_EXT4_DEBUG=y
CONFIG_FS_XIP=y
CONFIG_JBD=m
# CONFIG_JBD_DEBUG is not set
CONFIG_JBD2=m
# CONFIG_JBD2_DEBUG is not set
CONFIG_FS_MBCACHE=m
CONFIG_REISERFS_FS=m
# CONFIG_REISERFS_CHECK is not set
CONFIG_REISERFS_PROC_INFO=y
# CONFIG_REISERFS_FS_XATTR is not set
CONFIG_JFS_FS=m
# CONFIG_JFS_POSIX_ACL is not set
CONFIG_JFS_SECURITY=y
# CONFIG_JFS_DEBUG is not set
CONFIG_JFS_STATISTICS=y
# CONFIG_XFS_FS is not set
CONFIG_GFS2_FS=m
# CONFIG_GFS2_FS_LOCKING_DLM is not set
CONFIG_OCFS2_FS=m
# CONFIG_OCFS2_FS_O2CB is not set
# CONFIG_OCFS2_FS_USERSPACE_CLUSTER is not set
CONFIG_OCFS2_FS_STATS=y
# CONFIG_OCFS2_DEBUG_MASKLOG is not set
CONFIG_OCFS2_DEBUG_FS=y
# CONFIG_BTRFS_FS is not set
# CONFIG_NILFS2_FS is not set
CONFIG_FS_POSIX_ACL=y
CONFIG_EXPORTFS=m
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
# CONFIG_DNOTIFY is not set
CONFIG_INOTIFY_USER=y
# CONFIG_FANOTIFY is not set
CONFIG_QUOTA=y
# CONFIG_QUOTA_NETLINK_INTERFACE is not set
# CONFIG_PRINT_QUOTA_WARNING is not set
CONFIG_QUOTA_DEBUG=y
CONFIG_QUOTA_TREE=m
# CONFIG_QFMT_V1 is not set
CONFIG_QFMT_V2=m
CONFIG_QUOTACTL=y
# CONFIG_AUTOFS4_FS is not set
CONFIG_FUSE_FS=m
CONFIG_CUSE=m

#
# Caches
#
CONFIG_FSCACHE=m
CONFIG_FSCACHE_STATS=y
# CONFIG_FSCACHE_HISTOGRAM is not set
# CONFIG_FSCACHE_DEBUG is not set
CONFIG_FSCACHE_OBJECT_LIST=y
# CONFIG_CACHEFILES is not set

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
CONFIG_UDF_FS=m
CONFIG_UDF_NLS=y

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=m
# CONFIG_MSDOS_FS is not set
CONFIG_VFAT_FS=m
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
# CONFIG_PROC_KCORE is not set
# CONFIG_PROC_VMCORE is not set
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_TMPFS_XATTR is not set
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
CONFIG_CONFIGFS_FS=m
CONFIG_MISC_FILESYSTEMS=y
CONFIG_ADFS_FS=m
CONFIG_ADFS_FS_RW=y
CONFIG_AFFS_FS=m
# CONFIG_ECRYPT_FS is not set
# CONFIG_HFS_FS is not set
CONFIG_HFSPLUS_FS=m
# CONFIG_BEFS_FS is not set
CONFIG_BFS_FS=m
CONFIG_EFS_FS=m
CONFIG_LOGFS=m
CONFIG_CRAMFS=m
# CONFIG_SQUASHFS is not set
CONFIG_VXFS_FS=m
CONFIG_MINIX_FS=m
CONFIG_OMFS_FS=m
# CONFIG_HPFS_FS is not set
CONFIG_QNX4FS_FS=m
# CONFIG_QNX6FS_FS is not set
CONFIG_ROMFS_FS=m
CONFIG_ROMFS_BACKED_BY_BLOCK=y
CONFIG_ROMFS_ON_BLOCK=y
CONFIG_PSTORE=y
# CONFIG_PSTORE_CONSOLE is not set
# CONFIG_PSTORE_RAM is not set
CONFIG_SYSV_FS=m
CONFIG_UFS_FS=m
# CONFIG_UFS_FS_WRITE is not set
# CONFIG_UFS_DEBUG is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=m
CONFIG_NFS_V2=m
# CONFIG_NFS_V3 is not set
# CONFIG_NFS_V4 is not set
CONFIG_NFS_SWAP=y
# CONFIG_NFS_FSCACHE is not set
CONFIG_NFS_DEBUG=y
CONFIG_NFSD=m
CONFIG_NFSD_V3=y
# CONFIG_NFSD_V3_ACL is not set
# CONFIG_NFSD_V4 is not set
CONFIG_LOCKD=m
CONFIG_LOCKD_V4=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=m
CONFIG_SUNRPC_SWAP=y
CONFIG_SUNRPC_DEBUG=y
CONFIG_CEPH_FS=m
CONFIG_CIFS=m
# CONFIG_CIFS_STATS is not set
CONFIG_CIFS_WEAK_PW_HASH=y
CONFIG_CIFS_UPCALL=y
# CONFIG_CIFS_XATTR is not set
CONFIG_CIFS_DEBUG2=y
# CONFIG_CIFS_DFS_UPCALL is not set
CONFIG_CIFS_SMB2=y
CONFIG_CIFS_FSCACHE=y
CONFIG_NCP_FS=m
CONFIG_NCPFS_PACKET_SIGNING=y
CONFIG_NCPFS_IOCTL_LOCKING=y
# CONFIG_NCPFS_STRONG is not set
CONFIG_NCPFS_NFS_NS=y
# CONFIG_NCPFS_OS2_NS is not set
CONFIG_NCPFS_SMALLDOS=y
CONFIG_NCPFS_NLS=y
CONFIG_NCPFS_EXTRAS=y
CONFIG_CODA_FS=m
# CONFIG_AFS_FS is not set
CONFIG_9P_FS=y
# CONFIG_9P_FS_POSIX_ACL is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
# CONFIG_NLS_CODEPAGE_437 is not set
CONFIG_NLS_CODEPAGE_737=m
CONFIG_NLS_CODEPAGE_775=m
CONFIG_NLS_CODEPAGE_850=m
# CONFIG_NLS_CODEPAGE_852 is not set
CONFIG_NLS_CODEPAGE_855=m
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
CONFIG_NLS_CODEPAGE_861=m
CONFIG_NLS_CODEPAGE_862=m
CONFIG_NLS_CODEPAGE_863=m
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
CONFIG_NLS_CODEPAGE_869=m
CONFIG_NLS_CODEPAGE_936=m
# CONFIG_NLS_CODEPAGE_950 is not set
CONFIG_NLS_CODEPAGE_932=m
CONFIG_NLS_CODEPAGE_949=m
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=m
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
CONFIG_NLS_ISO8859_4=m
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
CONFIG_NLS_ISO8859_7=m
CONFIG_NLS_ISO8859_9=m
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=m
# CONFIG_NLS_KOI8_R is not set
CONFIG_NLS_KOI8_U=m
# CONFIG_NLS_MAC_ROMAN is not set
# CONFIG_NLS_MAC_CELTIC is not set
CONFIG_NLS_MAC_CENTEURO=m
# CONFIG_NLS_MAC_CROATIAN is not set
# CONFIG_NLS_MAC_CYRILLIC is not set
CONFIG_NLS_MAC_GAELIC=m
# CONFIG_NLS_MAC_GREEK is not set
CONFIG_NLS_MAC_ICELAND=m
CONFIG_NLS_MAC_INUIT=m
CONFIG_NLS_MAC_ROMANIAN=m
# CONFIG_NLS_MAC_TURKISH is not set
CONFIG_NLS_UTF8=m
CONFIG_DLM=m
# CONFIG_DLM_DEBUG is not set

#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
# CONFIG_PRINTK_TIME is not set
CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4
CONFIG_ENABLE_WARN_DEPRECATED=y
# CONFIG_ENABLE_MUST_CHECK is not set
CONFIG_FRAME_WARN=2048
CONFIG_MAGIC_SYSRQ=y
# CONFIG_STRIP_ASM_SYMS is not set
# CONFIG_READABLE_ASM is not set
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_FS=y
CONFIG_HEADERS_CHECK=y
CONFIG_DEBUG_SECTION_MISMATCH=y
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
CONFIG_LOCKUP_DETECTOR=y
CONFIG_HARDLOCKUP_DETECTOR=y
CONFIG_BOOTPARAM_HARDLOCKUP_PANIC=y
CONFIG_BOOTPARAM_HARDLOCKUP_PANIC_VALUE=1
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC=y
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=1
# CONFIG_PANIC_ON_OOPS is not set
CONFIG_PANIC_ON_OOPS_VALUE=0
# CONFIG_DETECT_HUNG_TASK is not set
CONFIG_SCHED_DEBUG=y
CONFIG_SCHEDSTATS=y
CONFIG_TIMER_STATS=y
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_SLUB_STATS is not set
CONFIG_HAVE_DEBUG_KMEMLEAK=y
# CONFIG_DEBUG_KMEMLEAK is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
CONFIG_RT_MUTEX_TESTER=y
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_LOCK_ALLOC=y
# CONFIG_PROVE_LOCKING is not set
CONFIG_SPARSE_RCU_POINTER=y
CONFIG_LOCKDEP=y
# CONFIG_LOCK_STAT is not set
CONFIG_DEBUG_LOCKDEP=y
CONFIG_DEBUG_ATOMIC_SLEEP=y
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
CONFIG_STACKTRACE=y
# CONFIG_DEBUG_STACK_USAGE is not set
CONFIG_DEBUG_KOBJECT=y
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_VM is not set
CONFIG_DEBUG_VIRTUAL=y
CONFIG_DEBUG_WRITECOUNT=y
CONFIG_DEBUG_MEMORY_INIT=y
# CONFIG_DEBUG_LIST is not set
CONFIG_TEST_LIST_SORT=y
CONFIG_DEBUG_SG=y
CONFIG_DEBUG_NOTIFIERS=y
CONFIG_DEBUG_CREDENTIALS=y
CONFIG_ARCH_WANT_FRAME_POINTERS=y
CONFIG_FRAME_POINTER=y
# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_RCU_TRACE is not set
CONFIG_KPROBES_SANITY_TEST=y
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
CONFIG_LKDTM=m
CONFIG_NOTIFIER_ERROR_INJECTION=m
# CONFIG_PM_NOTIFIER_ERROR_INJECT is not set
CONFIG_FAULT_INJECTION=y
# CONFIG_FAILSLAB is not set
CONFIG_FAIL_PAGE_ALLOC=y
# CONFIG_FAIL_MAKE_REQUEST is not set
# CONFIG_FAIL_IO_TIMEOUT is not set
CONFIG_FAULT_INJECTION_DEBUG_FS=y
CONFIG_LATENCYTOP=y
CONFIG_USER_STACKTRACE_SUPPORT=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST=y
CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_HAVE_FENTRY=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_TRACING_SUPPORT=y
# CONFIG_FTRACE is not set
# CONFIG_RBTREE_TEST is not set
# CONFIG_INTERVAL_TREE_TEST is not set
# CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set
CONFIG_BUILD_DOCSRC=y
# CONFIG_DYNAMIC_DEBUG is not set
CONFIG_DMA_API_DEBUG=y
CONFIG_ATOMIC64_SELFTEST=y
CONFIG_SAMPLES=y
CONFIG_SAMPLE_KOBJECT=m
# CONFIG_SAMPLE_KPROBES is not set
CONFIG_SAMPLE_HW_BREAKPOINT=m
CONFIG_SAMPLE_KFIFO=m
CONFIG_HAVE_ARCH_KGDB=y
CONFIG_KGDB=y
CONFIG_KGDB_SERIAL_CONSOLE=y
CONFIG_KGDB_TESTS=y
CONFIG_KGDB_TESTS_ON_BOOT=y
CONFIG_KGDB_TESTS_BOOT_STRING="V1F100"
CONFIG_KGDB_LOW_LEVEL_TRAP=y
# CONFIG_KGDB_KDB is not set
CONFIG_HAVE_ARCH_KMEMCHECK=y
CONFIG_KMEMCHECK=y
# CONFIG_KMEMCHECK_DISABLED_BY_DEFAULT is not set
CONFIG_KMEMCHECK_ENABLED_BY_DEFAULT=y
# CONFIG_KMEMCHECK_ONESHOT_BY_DEFAULT is not set
CONFIG_KMEMCHECK_QUEUE_SIZE=64
CONFIG_KMEMCHECK_SHADOW_COPY_SHIFT=5
CONFIG_KMEMCHECK_PARTIAL_OK=y
CONFIG_KMEMCHECK_BITOPS_OK=y
CONFIG_TEST_KSTRTOX=m
# CONFIG_STRICT_DEVMEM is not set
# CONFIG_X86_VERBOSE_BOOTUP is not set
CONFIG_EARLY_PRINTK=y
CONFIG_EARLY_PRINTK_DBGP=y
CONFIG_DEBUG_STACKOVERFLOW=y
CONFIG_X86_PTDUMP=y
CONFIG_DEBUG_RODATA=y
CONFIG_DEBUG_RODATA_TEST=y
CONFIG_DEBUG_SET_MODULE_RONX=y
CONFIG_DEBUG_NX_TEST=m
CONFIG_DEBUG_TLBFLUSH=y
# CONFIG_IOMMU_DEBUG is not set
CONFIG_IOMMU_STRESS=y
CONFIG_HAVE_MMIOTRACE_SUPPORT=y
# CONFIG_X86_DECODER_SELFTEST is not set
CONFIG_IO_DELAY_TYPE_0X80=0
CONFIG_IO_DELAY_TYPE_0XED=1
CONFIG_IO_DELAY_TYPE_UDELAY=2
CONFIG_IO_DELAY_TYPE_NONE=3
# CONFIG_IO_DELAY_0X80 is not set
# CONFIG_IO_DELAY_0XED is not set
# CONFIG_IO_DELAY_UDELAY is not set
CONFIG_IO_DELAY_NONE=y
CONFIG_DEFAULT_IO_DELAY_TYPE=3
CONFIG_DEBUG_BOOT_PARAMS=y
CONFIG_CPA_DEBUG=y
# CONFIG_OPTIMIZE_INLINING is not set
# CONFIG_DEBUG_STRICT_USER_COPY_CHECKS is not set
CONFIG_DEBUG_NMI_SELFTEST=y

#
# Security options
#
CONFIG_KEYS=y
# CONFIG_TRUSTED_KEYS is not set
# CONFIG_ENCRYPTED_KEYS is not set
CONFIG_KEYS_DEBUG_PROC_KEYS=y
# CONFIG_SECURITY_DMESG_RESTRICT is not set
CONFIG_SECURITY=y
CONFIG_SECURITYFS=y
CONFIG_SECURITY_NETWORK=y
# CONFIG_SECURITY_NETWORK_XFRM is not set
CONFIG_SECURITY_PATH=y
# CONFIG_SECURITY_SELINUX is not set
# CONFIG_SECURITY_TOMOYO is not set
# CONFIG_SECURITY_APPARMOR is not set
CONFIG_SECURITY_YAMA=y
CONFIG_SECURITY_YAMA_STACKED=y
CONFIG_INTEGRITY=y
# CONFIG_INTEGRITY_SIGNATURE is not set
CONFIG_IMA=y
CONFIG_IMA_MEASURE_PCR_IDX=10
# CONFIG_IMA_AUDIT is not set
CONFIG_IMA_APPRAISE=y
# CONFIG_EVM is not set
CONFIG_DEFAULT_SECURITY_YAMA=y
# CONFIG_DEFAULT_SECURITY_DAC is not set
CONFIG_DEFAULT_SECURITY="yama"
CONFIG_ASYNC_TX_DISABLE_PQ_VAL_DMA=y
CONFIG_ASYNC_TX_DISABLE_XOR_VAL_DMA=y
CONFIG_CRYPTO=y

#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD=m
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=m
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG=m
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_PCOMP=m
CONFIG_CRYPTO_PCOMP2=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
CONFIG_CRYPTO_USER=m
CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
CONFIG_CRYPTO_GF128MUL=m
CONFIG_CRYPTO_NULL=m
CONFIG_CRYPTO_WORKQUEUE=y
CONFIG_CRYPTO_CRYPTD=m
CONFIG_CRYPTO_AUTHENC=m
# CONFIG_CRYPTO_TEST is not set
CONFIG_CRYPTO_ABLK_HELPER_X86=m
CONFIG_CRYPTO_GLUE_HELPER_X86=m

#
# Authenticated Encryption with Associated Data
#
# CONFIG_CRYPTO_CCM is not set
# CONFIG_CRYPTO_GCM is not set
CONFIG_CRYPTO_SEQIV=m

#
# Block modes
#
CONFIG_CRYPTO_CBC=m
CONFIG_CRYPTO_CTR=m
# CONFIG_CRYPTO_CTS is not set
CONFIG_CRYPTO_ECB=m
CONFIG_CRYPTO_LRW=m
# CONFIG_CRYPTO_PCBC is not set
CONFIG_CRYPTO_XTS=m

#
# Hash modes
#
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_XCBC=m
CONFIG_CRYPTO_VMAC=m

#
# Digest
#
CONFIG_CRYPTO_CRC32C=m
# CONFIG_CRYPTO_CRC32C_INTEL is not set
CONFIG_CRYPTO_GHASH=m
CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MD5=y
# CONFIG_CRYPTO_MICHAEL_MIC is not set
CONFIG_CRYPTO_RMD128=m
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
CONFIG_CRYPTO_RMD320=m
CONFIG_CRYPTO_SHA1=y
# CONFIG_CRYPTO_SHA1_SSSE3 is not set
CONFIG_CRYPTO_SHA256=m
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_WP512 is not set
CONFIG_CRYPTO_GHASH_CLMUL_NI_INTEL=m

#
# Ciphers
#
CONFIG_CRYPTO_AES=y
CONFIG_CRYPTO_AES_X86_64=m
CONFIG_CRYPTO_AES_NI_INTEL=m
# CONFIG_CRYPTO_ANUBIS is not set
CONFIG_CRYPTO_ARC4=m
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_BLOWFISH_X86_64 is not set
# CONFIG_CRYPTO_CAMELLIA is not set
CONFIG_CRYPTO_CAMELLIA_X86_64=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST5_AVX_X86_64=m
CONFIG_CRYPTO_CAST6=m
# CONFIG_CRYPTO_CAST6_AVX_X86_64 is not set
CONFIG_CRYPTO_DES=m
CONFIG_CRYPTO_FCRYPT=m
# CONFIG_CRYPTO_KHAZAD is not set
CONFIG_CRYPTO_SALSA20=m
CONFIG_CRYPTO_SALSA20_X86_64=m
CONFIG_CRYPTO_SEED=m
CONFIG_CRYPTO_SERPENT=m
# CONFIG_CRYPTO_SERPENT_SSE2_X86_64 is not set
# CONFIG_CRYPTO_SERPENT_AVX_X86_64 is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_TWOFISH_X86_64 is not set
# CONFIG_CRYPTO_TWOFISH_X86_64_3WAY is not set
# CONFIG_CRYPTO_TWOFISH_AVX_X86_64 is not set

#
# Compression
#
CONFIG_CRYPTO_DEFLATE=m
CONFIG_CRYPTO_ZLIB=m
CONFIG_CRYPTO_LZO=m

#
# Random Number Generation
#
CONFIG_CRYPTO_ANSI_CPRNG=m
CONFIG_CRYPTO_USER_API=m
CONFIG_CRYPTO_USER_API_HASH=m
# CONFIG_CRYPTO_USER_API_SKCIPHER is not set
# CONFIG_CRYPTO_HW is not set
# CONFIG_ASYMMETRIC_KEY_TYPE is not set
CONFIG_HAVE_KVM=y
CONFIG_VIRTUALIZATION=y
# CONFIG_KVM is not set
CONFIG_VHOST_NET=m
# CONFIG_BINARY_PRINTF is not set

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_GENERIC_STRNCPY_FROM_USER=y
CONFIG_GENERIC_STRNLEN_USER=y
CONFIG_GENERIC_FIND_FIRST_BIT=y
CONFIG_GENERIC_PCI_IOMAP=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_IO=y
CONFIG_CRC_CCITT=m
CONFIG_CRC16=m
CONFIG_CRC_T10DIF=m
CONFIG_CRC_ITU_T=m
CONFIG_CRC32=y
CONFIG_CRC32_SELFTEST=y
# CONFIG_CRC32_SLICEBY8 is not set
# CONFIG_CRC32_SLICEBY4 is not set
# CONFIG_CRC32_SARWATE is not set
CONFIG_CRC32_BIT=y
CONFIG_CRC7=m
CONFIG_LIBCRC32C=m
CONFIG_CRC8=m
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=m
CONFIG_LZO_COMPRESS=y
CONFIG_LZO_DECOMPRESS=y
CONFIG_XZ_DEC=y
CONFIG_XZ_DEC_X86=y
CONFIG_XZ_DEC_POWERPC=y
CONFIG_XZ_DEC_IA64=y
CONFIG_XZ_DEC_ARM=y
CONFIG_XZ_DEC_ARMTHUMB=y
CONFIG_XZ_DEC_SPARC=y
CONFIG_XZ_DEC_BCJ=y
# CONFIG_XZ_DEC_TEST is not set
CONFIG_DECOMPRESS_GZIP=y
CONFIG_DECOMPRESS_BZIP2=y
CONFIG_DECOMPRESS_LZMA=y
CONFIG_DECOMPRESS_XZ=y
CONFIG_DECOMPRESS_LZO=y
CONFIG_GENERIC_ALLOCATOR=y
CONFIG_TEXTSEARCH=y
CONFIG_TEXTSEARCH_KMP=m
CONFIG_TEXTSEARCH_BM=m
CONFIG_TEXTSEARCH_FSM=m
CONFIG_BTREE=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_CHECK_SIGNATURE=y
CONFIG_DQL=y
CONFIG_NLATTR=y
CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y
CONFIG_AVERAGE=y
# CONFIG_CORDIC is not set
CONFIG_DDR=y

--------------080408090803040002050408
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------080408090803040002050408--


From xen-devel-bounces@lists.xen.org Wed Oct 24 23:44:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 23:44:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRAcZ-0003Dc-KZ; Wed, 24 Oct 2012 23:44:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRAcY-0003DX-0O
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 23:44:22 +0000
Received: from [85.158.143.99:50689] by server-2.bemta-4.messagelabs.com id
	86/EB-22268-55D78805; Wed, 24 Oct 2012 23:44:21 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1351122259!25642321!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgyOTc4MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4188 invoked from network); 24 Oct 2012 23:44:20 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Oct 2012 23:44:20 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9ONiFIk008948
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 24 Oct 2012 23:44:16 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9ONiD70009697
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 24 Oct 2012 23:44:15 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9ONiDrO021495; Wed, 24 Oct 2012 18:44:13 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 24 Oct 2012 16:44:13 -0700
Date: Wed, 24 Oct 2012 16:44:11 -0700
From: Mukesh Rathor 
To: Ian Campbell 
Message-ID: <20121024164411.5b000087@mantra.us.oracle.com>
In-Reply-To: <1351084777-28898-4-git-send-email-ian.campbell@citrix.com>
References: <1351084756.18035.28.camel@zakaz.uk.xensource.com>
	<1351084777-28898-4-git-send-email-ian.campbell@citrix.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel ,
	Stefano Stabellini ,
	linux-kernel ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 4/5] xen: arm: implement remap interfaces
 needed for privcmd mappings.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>  
>  #ifndef HYPERVISOR_VIRT_START
> diff --git a/include/xen/interface/memory.h
> b/include/xen/interface/memory.h index ad0dff5..5de2b36 100644
> --- a/include/xen/interface/memory.h
> +++ b/include/xen/interface/memory.h
> @@ -188,6 +188,24 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_physmap);
>  /*** REMOVED ***/
>  /*#define XENMEM_translate_gpfn_list  8*/
>  
> +#define XENMEM_add_to_physmap_range 23
> +struct xen_add_to_physmap_range {
> +    /* Which domain to change the mapping for. */
> +    domid_t domid;
> +    uint16_t space; /* => enum phys_map_space */
> +
> +    /* Number of pages to go through */
> +    uint16_t size;
> +    domid_t foreign_domid; /* IFF gmfn_foreign */
> +
> +    /* Indexes into space being mapped. */
> +    GUEST_HANDLE(xen_ulong_t) idxs;
> +
> +    /* GPFN in domid where the source mapping page should appear. */
> +    GUEST_HANDLE(xen_pfn_t) gpfns;


Looking at your arm implementation in xen, doesn't look like you are
expecting idxs and gpfns to be contigous. In that case, shouldn't idxs
and gpfns be pointers, ie, they are sent down as arrays? Or does
GUEST_HANDLE do that, I can't seem to find where it's defined quickly.

thanks
Mukesh


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 24 23:44:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 24 Oct 2012 23:44:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRAcZ-0003Dc-KZ; Wed, 24 Oct 2012 23:44:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRAcY-0003DX-0O
	for xen-devel@lists.xen.org; Wed, 24 Oct 2012 23:44:22 +0000
Received: from [85.158.143.99:50689] by server-2.bemta-4.messagelabs.com id
	86/EB-22268-55D78805; Wed, 24 Oct 2012 23:44:21 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1351122259!25642321!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgyOTc4MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4188 invoked from network); 24 Oct 2012 23:44:20 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Oct 2012 23:44:20 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9ONiFIk008948
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 24 Oct 2012 23:44:16 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9ONiD70009697
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 24 Oct 2012 23:44:15 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9ONiDrO021495; Wed, 24 Oct 2012 18:44:13 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 24 Oct 2012 16:44:13 -0700
Date: Wed, 24 Oct 2012 16:44:11 -0700
From: Mukesh Rathor 
To: Ian Campbell 
Message-ID: <20121024164411.5b000087@mantra.us.oracle.com>
In-Reply-To: <1351084777-28898-4-git-send-email-ian.campbell@citrix.com>
References: <1351084756.18035.28.camel@zakaz.uk.xensource.com>
	<1351084777-28898-4-git-send-email-ian.campbell@citrix.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel ,
	Stefano Stabellini ,
	linux-kernel ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 4/5] xen: arm: implement remap interfaces
 needed for privcmd mappings.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>  
>  #ifndef HYPERVISOR_VIRT_START
> diff --git a/include/xen/interface/memory.h
> b/include/xen/interface/memory.h index ad0dff5..5de2b36 100644
> --- a/include/xen/interface/memory.h
> +++ b/include/xen/interface/memory.h
> @@ -188,6 +188,24 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_physmap);
>  /*** REMOVED ***/
>  /*#define XENMEM_translate_gpfn_list  8*/
>  
> +#define XENMEM_add_to_physmap_range 23
> +struct xen_add_to_physmap_range {
> +    /* Which domain to change the mapping for. */
> +    domid_t domid;
> +    uint16_t space; /* => enum phys_map_space */
> +
> +    /* Number of pages to go through */
> +    uint16_t size;
> +    domid_t foreign_domid; /* IFF gmfn_foreign */
> +
> +    /* Indexes into space being mapped. */
> +    GUEST_HANDLE(xen_ulong_t) idxs;
> +
> +    /* GPFN in domid where the source mapping page should appear. */
> +    GUEST_HANDLE(xen_pfn_t) gpfns;


Looking at your arm implementation in xen, doesn't look like you are
expecting idxs and gpfns to be contigous. In that case, shouldn't idxs
and gpfns be pointers, ie, they are sent down as arrays? Or does
GUEST_HANDLE do that, I can't seem to find where it's defined quickly.

thanks
Mukesh


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 00:08:28 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 00:08:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRAzN-0003s4-Un; Thu, 25 Oct 2012 00:07:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRAzM-0003rc-2e
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 00:07:56 +0000
Received: from [85.158.143.99:38896] by server-3.bemta-4.messagelabs.com id
	62/F8-24279-BD288805; Thu, 25 Oct 2012 00:07:55 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1351123673!35399147!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgzMDQyOQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8063 invoked from network); 25 Oct 2012 00:07:54 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Oct 2012 00:07:54 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9P07nvO021108
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 25 Oct 2012 00:07:50 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9P07mNC005544
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 25 Oct 2012 00:07:49 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9P07lHm000641; Wed, 24 Oct 2012 19:07:47 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 24 Oct 2012 17:07:47 -0700
Date: Wed, 24 Oct 2012 17:07:46 -0700
From: Mukesh Rathor 
To: Mukesh Rathor 
Message-ID: <20121024170746.7c89a790@mantra.us.oracle.com>
In-Reply-To: <20121024164411.5b000087@mantra.us.oracle.com>
References: <1351084756.18035.28.camel@zakaz.uk.xensource.com>
	<1351084777-28898-4-git-send-email-ian.campbell@citrix.com>
	<20121024164411.5b000087@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: linux-kernel ,
	Konrad Rzeszutek Wilk ,
	Stefano Stabellini ,
	Ian Campbell , xen-devel 
Subject: Re: [Xen-devel] [PATCH 4/5] xen: arm: implement remap interfaces
 needed for privcmd mappings.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gV2VkLCAyNCBPY3QgMjAxMiAxNjo0NDoxMSAtMDcwMApNdWtlc2ggUmF0aG9yIDxtdWtlc2gu
cmF0aG9yQG9yYWNsZS5jb20+IHdyb3RlOgoKPiA+ICAKPiA+ICAjaWZuZGVmIEhZUEVSVklTT1Jf
VklSVF9TVEFSVAo+ID4gZGlmZiAtLWdpdCBhL2luY2x1ZGUveGVuL2ludGVyZmFjZS9tZW1vcnku
aAo+ID4gYi9pbmNsdWRlL3hlbi9pbnRlcmZhY2UvbWVtb3J5LmggaW5kZXggYWQwZGZmNS4uNWRl
MmIzNiAxMDA2NDQKPiA+IC0tLSBhL2luY2x1ZGUveGVuL2ludGVyZmFjZS9tZW1vcnkuaAo+ID4g
KysrIGIvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL21lbW9yeS5oCj4gPiBAQCAtMTg4LDYgKzE4OCwy
NCBAQCBERUZJTkVfR1VFU1RfSEFORExFX1NUUlVDVCh4ZW5fYWRkX3RvX3BoeXNtYXApOwo+ID4g
IC8qKiogUkVNT1ZFRCAqKiovCj4gPiAgLyojZGVmaW5lIFhFTk1FTV90cmFuc2xhdGVfZ3Bmbl9s
aXN0ICA4Ki8KPiA+ICAKPiA+ICsjZGVmaW5lIFhFTk1FTV9hZGRfdG9fcGh5c21hcF9yYW5nZSAy
Mwo+ID4gK3N0cnVjdCB4ZW5fYWRkX3RvX3BoeXNtYXBfcmFuZ2Ugewo+ID4gKyAgICAvKiBXaGlj
aCBkb21haW4gdG8gY2hhbmdlIHRoZSBtYXBwaW5nIGZvci4gKi8KPiA+ICsgICAgZG9taWRfdCBk
b21pZDsKPiA+ICsgICAgdWludDE2X3Qgc3BhY2U7IC8qID0+IGVudW0gcGh5c19tYXBfc3BhY2Ug
Ki8KPiA+ICsKPiA+ICsgICAgLyogTnVtYmVyIG9mIHBhZ2VzIHRvIGdvIHRocm91Z2ggKi8KPiA+
ICsgICAgdWludDE2X3Qgc2l6ZTsKPiA+ICsgICAgZG9taWRfdCBmb3JlaWduX2RvbWlkOyAvKiBJ
RkYgZ21mbl9mb3JlaWduICovCj4gPiArCj4gPiArICAgIC8qIEluZGV4ZXMgaW50byBzcGFjZSBi
ZWluZyBtYXBwZWQuICovCj4gPiArICAgIEdVRVNUX0hBTkRMRSh4ZW5fdWxvbmdfdCkgaWR4czsK
PiA+ICsKPiA+ICsgICAgLyogR1BGTiBpbiBkb21pZCB3aGVyZSB0aGUgc291cmNlIG1hcHBpbmcg
cGFnZSBzaG91bGQgYXBwZWFyLgo+ID4gKi8KPiA+ICsgICAgR1VFU1RfSEFORExFKHhlbl9wZm5f
dCkgZ3BmbnM7Cj4gCj4gCj4gTG9va2luZyBhdCB5b3VyIGFybSBpbXBsZW1lbnRhdGlvbiBpbiB4
ZW4sIGRvZXNuJ3QgbG9vayBsaWtlIHlvdSBhcmUKPiBleHBlY3RpbmcgaWR4cyBhbmQgZ3BmbnMg
dG8gYmUgY29udGlnb3VzLiBJbiB0aGF0IGNhc2UsIHNob3VsZG4ndCBpZHhzCj4gYW5kIGdwZm5z
IGJlIHBvaW50ZXJzLCBpZSwgdGhleSBhcmUgc2VudCBkb3duIGFzIGFycmF5cz8gT3IgZG9lcwo+
IEdVRVNUX0hBTkRMRSBkbyB0aGF0LCBJIGNhbid0IHNlZW0gdG8gZmluZCB3aGVyZSBpdCdzIGRl
ZmluZWQgcXVpY2tseS4KCk5ldmVyIG1pbmQsIEkgc2VlIGl0IGdvdCBjb3JyZWN0ZWQgdG8gWEVO
X0dVRVNUX0hBTkRMRSBpbiBzdGFnaW5nIHRyZWUuClN0aWxsIGRvZXNuJ3QgY29tcGlsZSB0aG86
CgpwdWJsaWMvbWVtb3J5Lmg6MjQ2OiBlcnJvcjogZXhwZWN0ZWQgc3BlY2lmaWVyLXF1YWxpZmll
ci1saXN0IGJlZm9yZQrigJhfX2d1ZXN0X2hhbmRsZV94ZW5fdWxvbmdfdOKAmQoKSSdsbCBmaWd1
cmUgaXQgb3V0LgoKdGhhbmtzLApNdWtlc2gKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3Rz
Lnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Oct 25 00:08:28 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 00:08:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRAzN-0003s4-Un; Thu, 25 Oct 2012 00:07:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRAzM-0003rc-2e
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 00:07:56 +0000
Received: from [85.158.143.99:38896] by server-3.bemta-4.messagelabs.com id
	62/F8-24279-BD288805; Thu, 25 Oct 2012 00:07:55 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1351123673!35399147!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgzMDQyOQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8063 invoked from network); 25 Oct 2012 00:07:54 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Oct 2012 00:07:54 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9P07nvO021108
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 25 Oct 2012 00:07:50 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9P07mNC005544
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 25 Oct 2012 00:07:49 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9P07lHm000641; Wed, 24 Oct 2012 19:07:47 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 24 Oct 2012 17:07:47 -0700
Date: Wed, 24 Oct 2012 17:07:46 -0700
From: Mukesh Rathor 
To: Mukesh Rathor 
Message-ID: <20121024170746.7c89a790@mantra.us.oracle.com>
In-Reply-To: <20121024164411.5b000087@mantra.us.oracle.com>
References: <1351084756.18035.28.camel@zakaz.uk.xensource.com>
	<1351084777-28898-4-git-send-email-ian.campbell@citrix.com>
	<20121024164411.5b000087@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: linux-kernel ,
	Konrad Rzeszutek Wilk ,
	Stefano Stabellini ,
	Ian Campbell , xen-devel 
Subject: Re: [Xen-devel] [PATCH 4/5] xen: arm: implement remap interfaces
 needed for privcmd mappings.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gV2VkLCAyNCBPY3QgMjAxMiAxNjo0NDoxMSAtMDcwMApNdWtlc2ggUmF0aG9yIDxtdWtlc2gu
cmF0aG9yQG9yYWNsZS5jb20+IHdyb3RlOgoKPiA+ICAKPiA+ICAjaWZuZGVmIEhZUEVSVklTT1Jf
VklSVF9TVEFSVAo+ID4gZGlmZiAtLWdpdCBhL2luY2x1ZGUveGVuL2ludGVyZmFjZS9tZW1vcnku
aAo+ID4gYi9pbmNsdWRlL3hlbi9pbnRlcmZhY2UvbWVtb3J5LmggaW5kZXggYWQwZGZmNS4uNWRl
MmIzNiAxMDA2NDQKPiA+IC0tLSBhL2luY2x1ZGUveGVuL2ludGVyZmFjZS9tZW1vcnkuaAo+ID4g
KysrIGIvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL21lbW9yeS5oCj4gPiBAQCAtMTg4LDYgKzE4OCwy
NCBAQCBERUZJTkVfR1VFU1RfSEFORExFX1NUUlVDVCh4ZW5fYWRkX3RvX3BoeXNtYXApOwo+ID4g
IC8qKiogUkVNT1ZFRCAqKiovCj4gPiAgLyojZGVmaW5lIFhFTk1FTV90cmFuc2xhdGVfZ3Bmbl9s
aXN0ICA4Ki8KPiA+ICAKPiA+ICsjZGVmaW5lIFhFTk1FTV9hZGRfdG9fcGh5c21hcF9yYW5nZSAy
Mwo+ID4gK3N0cnVjdCB4ZW5fYWRkX3RvX3BoeXNtYXBfcmFuZ2Ugewo+ID4gKyAgICAvKiBXaGlj
aCBkb21haW4gdG8gY2hhbmdlIHRoZSBtYXBwaW5nIGZvci4gKi8KPiA+ICsgICAgZG9taWRfdCBk
b21pZDsKPiA+ICsgICAgdWludDE2X3Qgc3BhY2U7IC8qID0+IGVudW0gcGh5c19tYXBfc3BhY2Ug
Ki8KPiA+ICsKPiA+ICsgICAgLyogTnVtYmVyIG9mIHBhZ2VzIHRvIGdvIHRocm91Z2ggKi8KPiA+
ICsgICAgdWludDE2X3Qgc2l6ZTsKPiA+ICsgICAgZG9taWRfdCBmb3JlaWduX2RvbWlkOyAvKiBJ
RkYgZ21mbl9mb3JlaWduICovCj4gPiArCj4gPiArICAgIC8qIEluZGV4ZXMgaW50byBzcGFjZSBi
ZWluZyBtYXBwZWQuICovCj4gPiArICAgIEdVRVNUX0hBTkRMRSh4ZW5fdWxvbmdfdCkgaWR4czsK
PiA+ICsKPiA+ICsgICAgLyogR1BGTiBpbiBkb21pZCB3aGVyZSB0aGUgc291cmNlIG1hcHBpbmcg
cGFnZSBzaG91bGQgYXBwZWFyLgo+ID4gKi8KPiA+ICsgICAgR1VFU1RfSEFORExFKHhlbl9wZm5f
dCkgZ3BmbnM7Cj4gCj4gCj4gTG9va2luZyBhdCB5b3VyIGFybSBpbXBsZW1lbnRhdGlvbiBpbiB4
ZW4sIGRvZXNuJ3QgbG9vayBsaWtlIHlvdSBhcmUKPiBleHBlY3RpbmcgaWR4cyBhbmQgZ3BmbnMg
dG8gYmUgY29udGlnb3VzLiBJbiB0aGF0IGNhc2UsIHNob3VsZG4ndCBpZHhzCj4gYW5kIGdwZm5z
IGJlIHBvaW50ZXJzLCBpZSwgdGhleSBhcmUgc2VudCBkb3duIGFzIGFycmF5cz8gT3IgZG9lcwo+
IEdVRVNUX0hBTkRMRSBkbyB0aGF0LCBJIGNhbid0IHNlZW0gdG8gZmluZCB3aGVyZSBpdCdzIGRl
ZmluZWQgcXVpY2tseS4KCk5ldmVyIG1pbmQsIEkgc2VlIGl0IGdvdCBjb3JyZWN0ZWQgdG8gWEVO
X0dVRVNUX0hBTkRMRSBpbiBzdGFnaW5nIHRyZWUuClN0aWxsIGRvZXNuJ3QgY29tcGlsZSB0aG86
CgpwdWJsaWMvbWVtb3J5Lmg6MjQ2OiBlcnJvcjogZXhwZWN0ZWQgc3BlY2lmaWVyLXF1YWxpZmll
ci1saXN0IGJlZm9yZQrigJhfX2d1ZXN0X2hhbmRsZV94ZW5fdWxvbmdfdOKAmQoKSSdsbCBmaWd1
cmUgaXQgb3V0LgoKdGhhbmtzLApNdWtlc2gKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3Rz
Lnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Oct 25 00:14:48 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 00:14:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRB5b-00041l-0E; Thu, 25 Oct 2012 00:14:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRB5Y-00041c-PC
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 00:14:20 +0000
Received: from [85.158.143.99:39878] by server-3.bemta-4.messagelabs.com id
	90/DA-24279-C5488805; Thu, 25 Oct 2012 00:14:20 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1351124058!27898475!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODIyNjI0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4480 invoked from network); 25 Oct 2012 00:14:19 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Oct 2012 00:14:19 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9P0EEZY010207
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 25 Oct 2012 00:14:15 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9P0EEY5013577
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 25 Oct 2012 00:14:14 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9P0EE0L008565; Wed, 24 Oct 2012 19:14:14 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 24 Oct 2012 17:14:13 -0700
Date: Wed, 24 Oct 2012 17:14:12 -0700
From: Mukesh Rathor 
To: Mukesh Rathor 
Message-ID: <20121024171412.7d2e8d3b@mantra.us.oracle.com>
In-Reply-To: <20121024170746.7c89a790@mantra.us.oracle.com>
References: <1351084756.18035.28.camel@zakaz.uk.xensource.com>
	<1351084777-28898-4-git-send-email-ian.campbell@citrix.com>
	<20121024164411.5b000087@mantra.us.oracle.com>
	<20121024170746.7c89a790@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: linux-kernel ,
	Konrad Rzeszutek Wilk ,
	Stefano Stabellini ,
	Ian Campbell , xen-devel 
Subject: Re: [Xen-devel] [PATCH 4/5] xen: arm: implement remap interfaces
 needed for privcmd mappings.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gV2VkLCAyNCBPY3QgMjAxMiAxNzowNzo0NiAtMDcwMApNdWtlc2ggUmF0aG9yIDxtdWtlc2gu
cmF0aG9yQG9yYWNsZS5jb20+IHdyb3RlOgoKPiBPbiBXZWQsIDI0IE9jdCAyMDEyIDE2OjQ0OjEx
IC0wNzAwCj4gTXVrZXNoIFJhdGhvciA8bXVrZXNoLnJhdGhvckBvcmFjbGUuY29tPiB3cm90ZToK
PiAKPiA+ID4gIAo+ID4gPiAgI2lmbmRlZiBIWVBFUlZJU09SX1ZJUlRfU1RBUlQKPiA+ID4gZGlm
ZiAtLWdpdCBhL2luY2x1ZGUveGVuL2ludGVyZmFjZS9tZW1vcnkuaAo+ID4gPiBiL2luY2x1ZGUv
eGVuL2ludGVyZmFjZS9tZW1vcnkuaCBpbmRleCBhZDBkZmY1Li41ZGUyYjM2IDEwMDY0NAo+ID4g
PiAtLS0gYS9pbmNsdWRlL3hlbi9pbnRlcmZhY2UvbWVtb3J5LmgKPiA+ID4gKysrIGIvaW5jbHVk
ZS94ZW4vaW50ZXJmYWNlL21lbW9yeS5oCj4gPiA+IEBAIC0xODgsNiArMTg4LDI0IEBACj4gPiA+
IERFRklORV9HVUVTVF9IQU5ETEVfU1RSVUNUKHhlbl9hZGRfdG9fcGh5c21hcCk7IC8qKiogUkVN
T1ZFRCAqKiovCj4gPiA+ICAvKiNkZWZpbmUgWEVOTUVNX3RyYW5zbGF0ZV9ncGZuX2xpc3QgIDgq
Lwo+ID4gPiAgCj4gPiA+ICsjZGVmaW5lIFhFTk1FTV9hZGRfdG9fcGh5c21hcF9yYW5nZSAyMwo+
ID4gPiArc3RydWN0IHhlbl9hZGRfdG9fcGh5c21hcF9yYW5nZSB7Cj4gPiA+ICsgICAgLyogV2hp
Y2ggZG9tYWluIHRvIGNoYW5nZSB0aGUgbWFwcGluZyBmb3IuICovCj4gPiA+ICsgICAgZG9taWRf
dCBkb21pZDsKPiA+ID4gKyAgICB1aW50MTZfdCBzcGFjZTsgLyogPT4gZW51bSBwaHlzX21hcF9z
cGFjZSAqLwo+ID4gPiArCj4gPiA+ICsgICAgLyogTnVtYmVyIG9mIHBhZ2VzIHRvIGdvIHRocm91
Z2ggKi8KPiA+ID4gKyAgICB1aW50MTZfdCBzaXplOwo+ID4gPiArICAgIGRvbWlkX3QgZm9yZWln
bl9kb21pZDsgLyogSUZGIGdtZm5fZm9yZWlnbiAqLwo+ID4gPiArCj4gPiA+ICsgICAgLyogSW5k
ZXhlcyBpbnRvIHNwYWNlIGJlaW5nIG1hcHBlZC4gKi8KPiA+ID4gKyAgICBHVUVTVF9IQU5ETEUo
eGVuX3Vsb25nX3QpIGlkeHM7Cj4gPiA+ICsKPiA+ID4gKyAgICAvKiBHUEZOIGluIGRvbWlkIHdo
ZXJlIHRoZSBzb3VyY2UgbWFwcGluZyBwYWdlIHNob3VsZCBhcHBlYXIuCj4gPiA+ICovCj4gPiA+
ICsgICAgR1VFU1RfSEFORExFKHhlbl9wZm5fdCkgZ3BmbnM7Cj4gPiAKPiA+IAo+ID4gTG9va2lu
ZyBhdCB5b3VyIGFybSBpbXBsZW1lbnRhdGlvbiBpbiB4ZW4sIGRvZXNuJ3QgbG9vayBsaWtlIHlv
dSBhcmUKPiA+IGV4cGVjdGluZyBpZHhzIGFuZCBncGZucyB0byBiZSBjb250aWdvdXMuIEluIHRo
YXQgY2FzZSwgc2hvdWxkbid0Cj4gPiBpZHhzIGFuZCBncGZucyBiZSBwb2ludGVycywgaWUsIHRo
ZXkgYXJlIHNlbnQgZG93biBhcyBhcnJheXM/IE9yCj4gPiBkb2VzIEdVRVNUX0hBTkRMRSBkbyB0
aGF0LCBJIGNhbid0IHNlZW0gdG8gZmluZCB3aGVyZSBpdCdzIGRlZmluZWQKPiA+IHF1aWNrbHku
Cj4gCj4gTmV2ZXIgbWluZCwgSSBzZWUgaXQgZ290IGNvcnJlY3RlZCB0byBYRU5fR1VFU1RfSEFO
RExFIGluIHN0YWdpbmcKPiB0cmVlLiBTdGlsbCBkb2Vzbid0IGNvbXBpbGUgdGhvOgo+IAo+IHB1
YmxpYy9tZW1vcnkuaDoyNDY6IGVycm9yOiBleHBlY3RlZCBzcGVjaWZpZXItcXVhbGlmaWVyLWxp
c3QgYmVmb3JlCj4g4oCYX19ndWVzdF9oYW5kbGVfeGVuX3Vsb25nX3TigJkKPiAKPiBJJ2xsIGZp
Z3VyZSBpdCBvdXQuCgpPaCwgeWVhaCwgbWlzc2VkOgorREVGSU5FX1hFTl9HVUVTVF9IQU5ETEUo
eGVuX3Vsb25nX3QpOwoKY29tcGlsZXMgbm93LgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxp
c3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Oct 25 00:14:48 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 00:14:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRB5b-00041l-0E; Thu, 25 Oct 2012 00:14:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRB5Y-00041c-PC
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 00:14:20 +0000
Received: from [85.158.143.99:39878] by server-3.bemta-4.messagelabs.com id
	90/DA-24279-C5488805; Thu, 25 Oct 2012 00:14:20 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1351124058!27898475!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODIyNjI0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4480 invoked from network); 25 Oct 2012 00:14:19 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Oct 2012 00:14:19 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9P0EEZY010207
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 25 Oct 2012 00:14:15 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9P0EEY5013577
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 25 Oct 2012 00:14:14 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9P0EE0L008565; Wed, 24 Oct 2012 19:14:14 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 24 Oct 2012 17:14:13 -0700
Date: Wed, 24 Oct 2012 17:14:12 -0700
From: Mukesh Rathor 
To: Mukesh Rathor 
Message-ID: <20121024171412.7d2e8d3b@mantra.us.oracle.com>
In-Reply-To: <20121024170746.7c89a790@mantra.us.oracle.com>
References: <1351084756.18035.28.camel@zakaz.uk.xensource.com>
	<1351084777-28898-4-git-send-email-ian.campbell@citrix.com>
	<20121024164411.5b000087@mantra.us.oracle.com>
	<20121024170746.7c89a790@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: linux-kernel ,
	Konrad Rzeszutek Wilk ,
	Stefano Stabellini ,
	Ian Campbell , xen-devel 
Subject: Re: [Xen-devel] [PATCH 4/5] xen: arm: implement remap interfaces
 needed for privcmd mappings.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gV2VkLCAyNCBPY3QgMjAxMiAxNzowNzo0NiAtMDcwMApNdWtlc2ggUmF0aG9yIDxtdWtlc2gu
cmF0aG9yQG9yYWNsZS5jb20+IHdyb3RlOgoKPiBPbiBXZWQsIDI0IE9jdCAyMDEyIDE2OjQ0OjEx
IC0wNzAwCj4gTXVrZXNoIFJhdGhvciA8bXVrZXNoLnJhdGhvckBvcmFjbGUuY29tPiB3cm90ZToK
PiAKPiA+ID4gIAo+ID4gPiAgI2lmbmRlZiBIWVBFUlZJU09SX1ZJUlRfU1RBUlQKPiA+ID4gZGlm
ZiAtLWdpdCBhL2luY2x1ZGUveGVuL2ludGVyZmFjZS9tZW1vcnkuaAo+ID4gPiBiL2luY2x1ZGUv
eGVuL2ludGVyZmFjZS9tZW1vcnkuaCBpbmRleCBhZDBkZmY1Li41ZGUyYjM2IDEwMDY0NAo+ID4g
PiAtLS0gYS9pbmNsdWRlL3hlbi9pbnRlcmZhY2UvbWVtb3J5LmgKPiA+ID4gKysrIGIvaW5jbHVk
ZS94ZW4vaW50ZXJmYWNlL21lbW9yeS5oCj4gPiA+IEBAIC0xODgsNiArMTg4LDI0IEBACj4gPiA+
IERFRklORV9HVUVTVF9IQU5ETEVfU1RSVUNUKHhlbl9hZGRfdG9fcGh5c21hcCk7IC8qKiogUkVN
T1ZFRCAqKiovCj4gPiA+ICAvKiNkZWZpbmUgWEVOTUVNX3RyYW5zbGF0ZV9ncGZuX2xpc3QgIDgq
Lwo+ID4gPiAgCj4gPiA+ICsjZGVmaW5lIFhFTk1FTV9hZGRfdG9fcGh5c21hcF9yYW5nZSAyMwo+
ID4gPiArc3RydWN0IHhlbl9hZGRfdG9fcGh5c21hcF9yYW5nZSB7Cj4gPiA+ICsgICAgLyogV2hp
Y2ggZG9tYWluIHRvIGNoYW5nZSB0aGUgbWFwcGluZyBmb3IuICovCj4gPiA+ICsgICAgZG9taWRf
dCBkb21pZDsKPiA+ID4gKyAgICB1aW50MTZfdCBzcGFjZTsgLyogPT4gZW51bSBwaHlzX21hcF9z
cGFjZSAqLwo+ID4gPiArCj4gPiA+ICsgICAgLyogTnVtYmVyIG9mIHBhZ2VzIHRvIGdvIHRocm91
Z2ggKi8KPiA+ID4gKyAgICB1aW50MTZfdCBzaXplOwo+ID4gPiArICAgIGRvbWlkX3QgZm9yZWln
bl9kb21pZDsgLyogSUZGIGdtZm5fZm9yZWlnbiAqLwo+ID4gPiArCj4gPiA+ICsgICAgLyogSW5k
ZXhlcyBpbnRvIHNwYWNlIGJlaW5nIG1hcHBlZC4gKi8KPiA+ID4gKyAgICBHVUVTVF9IQU5ETEUo
eGVuX3Vsb25nX3QpIGlkeHM7Cj4gPiA+ICsKPiA+ID4gKyAgICAvKiBHUEZOIGluIGRvbWlkIHdo
ZXJlIHRoZSBzb3VyY2UgbWFwcGluZyBwYWdlIHNob3VsZCBhcHBlYXIuCj4gPiA+ICovCj4gPiA+
ICsgICAgR1VFU1RfSEFORExFKHhlbl9wZm5fdCkgZ3BmbnM7Cj4gPiAKPiA+IAo+ID4gTG9va2lu
ZyBhdCB5b3VyIGFybSBpbXBsZW1lbnRhdGlvbiBpbiB4ZW4sIGRvZXNuJ3QgbG9vayBsaWtlIHlv
dSBhcmUKPiA+IGV4cGVjdGluZyBpZHhzIGFuZCBncGZucyB0byBiZSBjb250aWdvdXMuIEluIHRo
YXQgY2FzZSwgc2hvdWxkbid0Cj4gPiBpZHhzIGFuZCBncGZucyBiZSBwb2ludGVycywgaWUsIHRo
ZXkgYXJlIHNlbnQgZG93biBhcyBhcnJheXM/IE9yCj4gPiBkb2VzIEdVRVNUX0hBTkRMRSBkbyB0
aGF0LCBJIGNhbid0IHNlZW0gdG8gZmluZCB3aGVyZSBpdCdzIGRlZmluZWQKPiA+IHF1aWNrbHku
Cj4gCj4gTmV2ZXIgbWluZCwgSSBzZWUgaXQgZ290IGNvcnJlY3RlZCB0byBYRU5fR1VFU1RfSEFO
RExFIGluIHN0YWdpbmcKPiB0cmVlLiBTdGlsbCBkb2Vzbid0IGNvbXBpbGUgdGhvOgo+IAo+IHB1
YmxpYy9tZW1vcnkuaDoyNDY6IGVycm9yOiBleHBlY3RlZCBzcGVjaWZpZXItcXVhbGlmaWVyLWxp
c3QgYmVmb3JlCj4g4oCYX19ndWVzdF9oYW5kbGVfeGVuX3Vsb25nX3TigJkKPiAKPiBJJ2xsIGZp
Z3VyZSBpdCBvdXQuCgpPaCwgeWVhaCwgbWlzc2VkOgorREVGSU5FX1hFTl9HVUVTVF9IQU5ETEUo
eGVuX3Vsb25nX3QpOwoKY29tcGlsZXMgbm93LgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxp
c3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Oct 25 02:08:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 02:08:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRCrb-0000Cy-5t; Thu, 25 Oct 2012 02:08:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRCrY-0000Ct-VS
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 02:08:01 +0000
Received: from [85.158.137.99:5804] by server-7.bemta-3.messagelabs.com id
	03/18-06991-FFE98805; Thu, 25 Oct 2012 02:07:59 +0000
X-Env-Sender: xiantao.zhang@intel.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1351130878!17875930!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzE1MTcz\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9296 invoked from network); 25 Oct 2012 02:07:58 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-3.tower-217.messagelabs.com with SMTP;
	25 Oct 2012 02:07:58 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 24 Oct 2012 19:07:57 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,643,1344236400"; d="scan'208";a="232156246"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by orsmga002.jf.intel.com with ESMTP; 24 Oct 2012 19:07:56 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 24 Oct 2012 19:07:56 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.186]) with mapi id
	14.01.0355.002; Thu, 25 Oct 2012 10:07:55 +0800
From: "Zhang, Xiantao" 
To: Jan Beulich , xen-devel 
Thread-Topic: [PATCH v3] IOMMU: keep disabled until iommu_setup() is called
Thread-Index: AQHNsf9A6rQ7sMvBykK755M0gaxMLJfJRsMA
Date: Thu, 25 Oct 2012 02:07:54 +0000
Message-ID: 
References: <50882A4002000078000A4131@nat28.tlf.novell.com>
In-Reply-To: <50882A4002000078000A4131@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Wei Wang , Ronny Hegewald ,
	"Zhang, Xiantao" 
Subject: Re: [Xen-devel] [PATCH v3] IOMMU: keep disabled until iommu_setup()
	is called
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Looks fine, Thanks!
Acked-by: Xiantao Zhang 

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Wednesday, October 24, 2012 11:50 PM
> To: xen-devel
> Cc: Wei Wang; Zhang, Xiantao; Ronny Hegewald
> Subject: [PATCH v3] IOMMU: keep disabled until iommu_setup() is called
> 
> The iommu is enabled by default when xen is booting and later disabled in
> iommu_setup() when no iommu is present.
> 
> But under some circumstances iommu code can be called before
> iommu_setup() is processed. If there is no iommu available xen crashes.
> 
> This can happen for example when panic(...) is called as introduced with the
> patch "x86-64: detect processors subject to AMD erratum #121 and refuse to
> boot" since xen 4.1.3, resulting in
> find_iommu_for_device() to be called in the context of
> disable_IO_APIC() / __stop_this_cpu().
> 
> This patch fixes this by keeping the iommu disabled until iommu_setup() is
> entered.
> 
> Originally-by: Ronny Hegewald 
> 
> In order for iommu_enable to be off initially, iommu_supports_eim() must
> not depend on it anymore, nor must acpi_parse_dmar(). The former in turn
> requires that iommu_intremap gets uncoupled from iommu_enabled (in
> particular, failure during IOMMU setup should no longer result in
> iommu_intremap getting cleared by generic code; IOMMU specific code can
> still do so provided in can live with the consequences).
> 
> This could have the nice side effect of allowing to use "iommu=off"
> even when x2APIC was pre-enabled by the BIOS (in which case interrupt
> remapping is a requirement, but DMA translation [obviously] isn't), but that
> doesn't currently work (and hence x2apic_bsp_setup() forces the IOMMU
> on rather than just interrupt remapping).
> 
> For consistency with VT-d, make the AMD IOMMU code also skip all ACPI
> table parsing when neither iommu_enable nor iommu_intremap are set.
> 
> Signed-off-by: Jan Beulich 
> 
> --- a/xen/arch/x86/apic.c
> +++ b/xen/arch/x86/apic.c
> @@ -975,6 +975,8 @@ void __init x2apic_bsp_setup(void)
>          goto restore_out;
>      }
> 
> +    force_iommu = 1;
> +
>      genapic = apic_x2apic_probe();
>      printk("Switched to APIC driver %s.\n", genapic->name);
> 
> --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
> +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
> @@ -164,9 +164,13 @@ int __init amd_iov_detect(void)  {
>      INIT_LIST_HEAD(&amd_iommu_head);
> 
> +    if ( !iommu_enable && !iommu_intremap )
> +        return 0;
> +
>      if ( (amd_iommu_detect_acpi() !=0) || (iommu_found() == 0) )
>      {
>          printk("AMD-Vi: IOMMU not found!\n");
> +        iommu_intremap = 0;
>          return -ENODEV;
>      }
> 
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -41,7 +41,8 @@ static void iommu_dump_p2m_table(unsigne
>   *   no-intremap                Disable VT-d Interrupt Remapping
>   */
>  custom_param("iommu", parse_iommu_param); -bool_t __read_mostly
> iommu_enabled = 1;
> +bool_t __initdata iommu_enable = 1;
> +bool_t __read_mostly iommu_enabled;
>  bool_t __read_mostly force_iommu;
>  bool_t __initdata iommu_dom0_strict;
>  bool_t __read_mostly iommu_verbose;
> @@ -77,7 +78,7 @@ static void __init parse_iommu_param(cha
>              *ss = '\0';
> 
>          if ( !parse_bool(s) )
> -            iommu_enabled = 0;
> +            iommu_enable = 0;
>          else if ( !strcmp(s, "force") || !strcmp(s, "required") )
>              force_iommu = val;
>          else if ( !strcmp(s, "workaround_bios_bug") ) @@ -395,7 +396,7 @@ int
> __init iommu_setup(void)
>      if ( iommu_dom0_strict )
>          iommu_passthrough = 0;
> 
> -    if ( iommu_enabled )
> +    if ( iommu_enable )
>      {
>          rc = iommu_hardware_setup();
>          iommu_enabled = (rc == 0);
> @@ -409,8 +410,6 @@ int __init iommu_setup(void)
>      if ( !iommu_enabled )
>      {
>          iommu_snoop = 0;
> -        iommu_qinval = 0;
> -        iommu_intremap = 0;
>          iommu_passthrough = 0;
>          iommu_dom0_strict = 0;
>      }
> @@ -419,6 +418,8 @@ int __init iommu_setup(void)
>          printk(" - Dom0 mode: %s\n",
>                 iommu_passthrough ? "Passthrough" :
>                 iommu_dom0_strict ? "Strict" : "Relaxed");
> +    else if ( iommu_intremap )
> +        printk("Interrupt remapping enabled\n");
> 
>      return rc;
>  }
> --- a/xen/drivers/passthrough/vtd/dmar.c
> +++ b/xen/drivers/passthrough/vtd/dmar.c
> @@ -744,7 +744,7 @@ static int __init acpi_parse_dmar(struct
>      dmar = (struct acpi_table_dmar *)table;
>      dmar_flags = dmar->flags;
> 
> -    if ( !iommu_enabled )
> +    if ( !iommu_enable && !iommu_intremap )
>      {
>          ret = -EINVAL;
>          goto out;
> --- a/xen/drivers/passthrough/vtd/intremap.c
> +++ b/xen/drivers/passthrough/vtd/intremap.c
> @@ -149,8 +149,7 @@ int iommu_supports_eim(void)
>      struct acpi_drhd_unit *drhd;
>      int apic;
> 
> -    if ( !iommu_enabled || !iommu_qinval || !iommu_intremap ||
> -         list_empty(&acpi_drhd_units) )
> +    if ( !iommu_qinval || !iommu_intremap ||
> + list_empty(&acpi_drhd_units) )
>          return 0;
> 
>      /* We MUST have a DRHD unit for each IOAPIC. */
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -2086,7 +2086,10 @@ int __init intel_vtd_setup(void)
>      int ret;
> 
>      if ( list_empty(&acpi_drhd_units) )
> -        return -ENODEV;
> +    {
> +        ret = -ENODEV;
> +        goto error;
> +    }
> 
>      platform_quirks_init();
> 
> --- a/xen/include/xen/iommu.h
> +++ b/xen/include/xen/iommu.h
> @@ -26,7 +26,7 @@
>  #include 
>  #include 
> 
> -extern bool_t iommu_enabled;
> +extern bool_t iommu_enable, iommu_enabled;
>  extern bool_t force_iommu, iommu_verbose;  extern bool_t
> iommu_workaround_bios_bug, iommu_passthrough;  extern bool_t
> iommu_snoop, iommu_qinval, iommu_intremap;
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 02:08:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 02:08:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRCrb-0000Cy-5t; Thu, 25 Oct 2012 02:08:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRCrY-0000Ct-VS
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 02:08:01 +0000
Received: from [85.158.137.99:5804] by server-7.bemta-3.messagelabs.com id
	03/18-06991-FFE98805; Thu, 25 Oct 2012 02:07:59 +0000
X-Env-Sender: xiantao.zhang@intel.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1351130878!17875930!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzE1MTcz\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9296 invoked from network); 25 Oct 2012 02:07:58 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-3.tower-217.messagelabs.com with SMTP;
	25 Oct 2012 02:07:58 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 24 Oct 2012 19:07:57 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,643,1344236400"; d="scan'208";a="232156246"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by orsmga002.jf.intel.com with ESMTP; 24 Oct 2012 19:07:56 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 24 Oct 2012 19:07:56 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.186]) with mapi id
	14.01.0355.002; Thu, 25 Oct 2012 10:07:55 +0800
From: "Zhang, Xiantao" 
To: Jan Beulich , xen-devel 
Thread-Topic: [PATCH v3] IOMMU: keep disabled until iommu_setup() is called
Thread-Index: AQHNsf9A6rQ7sMvBykK755M0gaxMLJfJRsMA
Date: Thu, 25 Oct 2012 02:07:54 +0000
Message-ID: 
References: <50882A4002000078000A4131@nat28.tlf.novell.com>
In-Reply-To: <50882A4002000078000A4131@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Wei Wang , Ronny Hegewald ,
	"Zhang, Xiantao" 
Subject: Re: [Xen-devel] [PATCH v3] IOMMU: keep disabled until iommu_setup()
	is called
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Looks fine, Thanks!
Acked-by: Xiantao Zhang 

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Wednesday, October 24, 2012 11:50 PM
> To: xen-devel
> Cc: Wei Wang; Zhang, Xiantao; Ronny Hegewald
> Subject: [PATCH v3] IOMMU: keep disabled until iommu_setup() is called
> 
> The iommu is enabled by default when xen is booting and later disabled in
> iommu_setup() when no iommu is present.
> 
> But under some circumstances iommu code can be called before
> iommu_setup() is processed. If there is no iommu available xen crashes.
> 
> This can happen for example when panic(...) is called as introduced with the
> patch "x86-64: detect processors subject to AMD erratum #121 and refuse to
> boot" since xen 4.1.3, resulting in
> find_iommu_for_device() to be called in the context of
> disable_IO_APIC() / __stop_this_cpu().
> 
> This patch fixes this by keeping the iommu disabled until iommu_setup() is
> entered.
> 
> Originally-by: Ronny Hegewald 
> 
> In order for iommu_enable to be off initially, iommu_supports_eim() must
> not depend on it anymore, nor must acpi_parse_dmar(). The former in turn
> requires that iommu_intremap gets uncoupled from iommu_enabled (in
> particular, failure during IOMMU setup should no longer result in
> iommu_intremap getting cleared by generic code; IOMMU specific code can
> still do so provided in can live with the consequences).
> 
> This could have the nice side effect of allowing to use "iommu=off"
> even when x2APIC was pre-enabled by the BIOS (in which case interrupt
> remapping is a requirement, but DMA translation [obviously] isn't), but that
> doesn't currently work (and hence x2apic_bsp_setup() forces the IOMMU
> on rather than just interrupt remapping).
> 
> For consistency with VT-d, make the AMD IOMMU code also skip all ACPI
> table parsing when neither iommu_enable nor iommu_intremap are set.
> 
> Signed-off-by: Jan Beulich 
> 
> --- a/xen/arch/x86/apic.c
> +++ b/xen/arch/x86/apic.c
> @@ -975,6 +975,8 @@ void __init x2apic_bsp_setup(void)
>          goto restore_out;
>      }
> 
> +    force_iommu = 1;
> +
>      genapic = apic_x2apic_probe();
>      printk("Switched to APIC driver %s.\n", genapic->name);
> 
> --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
> +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
> @@ -164,9 +164,13 @@ int __init amd_iov_detect(void)  {
>      INIT_LIST_HEAD(&amd_iommu_head);
> 
> +    if ( !iommu_enable && !iommu_intremap )
> +        return 0;
> +
>      if ( (amd_iommu_detect_acpi() !=0) || (iommu_found() == 0) )
>      {
>          printk("AMD-Vi: IOMMU not found!\n");
> +        iommu_intremap = 0;
>          return -ENODEV;
>      }
> 
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -41,7 +41,8 @@ static void iommu_dump_p2m_table(unsigne
>   *   no-intremap                Disable VT-d Interrupt Remapping
>   */
>  custom_param("iommu", parse_iommu_param); -bool_t __read_mostly
> iommu_enabled = 1;
> +bool_t __initdata iommu_enable = 1;
> +bool_t __read_mostly iommu_enabled;
>  bool_t __read_mostly force_iommu;
>  bool_t __initdata iommu_dom0_strict;
>  bool_t __read_mostly iommu_verbose;
> @@ -77,7 +78,7 @@ static void __init parse_iommu_param(cha
>              *ss = '\0';
> 
>          if ( !parse_bool(s) )
> -            iommu_enabled = 0;
> +            iommu_enable = 0;
>          else if ( !strcmp(s, "force") || !strcmp(s, "required") )
>              force_iommu = val;
>          else if ( !strcmp(s, "workaround_bios_bug") ) @@ -395,7 +396,7 @@ int
> __init iommu_setup(void)
>      if ( iommu_dom0_strict )
>          iommu_passthrough = 0;
> 
> -    if ( iommu_enabled )
> +    if ( iommu_enable )
>      {
>          rc = iommu_hardware_setup();
>          iommu_enabled = (rc == 0);
> @@ -409,8 +410,6 @@ int __init iommu_setup(void)
>      if ( !iommu_enabled )
>      {
>          iommu_snoop = 0;
> -        iommu_qinval = 0;
> -        iommu_intremap = 0;
>          iommu_passthrough = 0;
>          iommu_dom0_strict = 0;
>      }
> @@ -419,6 +418,8 @@ int __init iommu_setup(void)
>          printk(" - Dom0 mode: %s\n",
>                 iommu_passthrough ? "Passthrough" :
>                 iommu_dom0_strict ? "Strict" : "Relaxed");
> +    else if ( iommu_intremap )
> +        printk("Interrupt remapping enabled\n");
> 
>      return rc;
>  }
> --- a/xen/drivers/passthrough/vtd/dmar.c
> +++ b/xen/drivers/passthrough/vtd/dmar.c
> @@ -744,7 +744,7 @@ static int __init acpi_parse_dmar(struct
>      dmar = (struct acpi_table_dmar *)table;
>      dmar_flags = dmar->flags;
> 
> -    if ( !iommu_enabled )
> +    if ( !iommu_enable && !iommu_intremap )
>      {
>          ret = -EINVAL;
>          goto out;
> --- a/xen/drivers/passthrough/vtd/intremap.c
> +++ b/xen/drivers/passthrough/vtd/intremap.c
> @@ -149,8 +149,7 @@ int iommu_supports_eim(void)
>      struct acpi_drhd_unit *drhd;
>      int apic;
> 
> -    if ( !iommu_enabled || !iommu_qinval || !iommu_intremap ||
> -         list_empty(&acpi_drhd_units) )
> +    if ( !iommu_qinval || !iommu_intremap ||
> + list_empty(&acpi_drhd_units) )
>          return 0;
> 
>      /* We MUST have a DRHD unit for each IOAPIC. */
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -2086,7 +2086,10 @@ int __init intel_vtd_setup(void)
>      int ret;
> 
>      if ( list_empty(&acpi_drhd_units) )
> -        return -ENODEV;
> +    {
> +        ret = -ENODEV;
> +        goto error;
> +    }
> 
>      platform_quirks_init();
> 
> --- a/xen/include/xen/iommu.h
> +++ b/xen/include/xen/iommu.h
> @@ -26,7 +26,7 @@
>  #include 
>  #include 
> 
> -extern bool_t iommu_enabled;
> +extern bool_t iommu_enable, iommu_enabled;
>  extern bool_t force_iommu, iommu_verbose;  extern bool_t
> iommu_workaround_bios_bug, iommu_passthrough;  extern bool_t
> iommu_snoop, iommu_qinval, iommu_intremap;
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 03:40:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 03:40:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TREIL-0000ez-Q6; Thu, 25 Oct 2012 03:39:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TREIJ-0000eu-FY
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 03:39:43 +0000
Received: from [85.158.143.35:49028] by server-1.bemta-4.messagelabs.com id
	CD/44-19134-E74B8805; Thu, 25 Oct 2012 03:39:42 +0000
X-Env-Sender: john.krstev@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1351136379!12600967!1
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30184 invoked from network); 25 Oct 2012 03:39:40 -0000
Received: from mail-qa0-f43.google.com (HELO mail-qa0-f43.google.com)
	(209.85.216.43)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 03:39:40 -0000
Received: by mail-qa0-f43.google.com with SMTP id k1so3451358qaf.9
	for ;
	Wed, 24 Oct 2012 20:39:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=mMzlvNrag6xNXW5QtM82KwAWCq1ycfRpVJoA1WDS78o=;
	b=PtP8m9oMaE+4VBLBi0Wr0J0cw8AdSYX3/lHr4w76VUUsk636zpr/wQMe+O580dOb5+
	or3Vsp0/NHl+sS/3xdfU710pmjC4sSVvPQWUIev0hsDV9+49C4s08YJsDptdmCOAij5e
	wo3fWvf2bJZGvuLzXGAYZGRZ/Jeto788xodfeePWpgFhi9YsGiJvf5GvvZbX6pf3ygQj
	d9ko5VHfRFOJkStddBQjkHpV/GC43es5mT9j3QttbZOhUk2KoknSOa/UA6cjDZtsTJyY
	5uTe3Tfh5nL5MsC69MpdiYEaR/OOeyoySOiCTSiDELxk16u92wx5WFZyThoZ0ZjZ1W42
	1dWg==
MIME-Version: 1.0
Received: by 10.224.40.14 with SMTP id i14mr6734967qae.37.1351136379073; Wed,
	24 Oct 2012 20:39:39 -0700 (PDT)
Received: by 10.49.96.134 with HTTP; Wed, 24 Oct 2012 20:39:38 -0700 (PDT)
In-Reply-To: 
References: 
	<20120921172901.GA6821@phenom.dumpdata.com>
	<099949C5-C4C0-4D57-A778-849C94781372@gmail.com>
	<20120925141013.GC16478@phenom.dumpdata.com>
	
	
Date: Thu, 25 Oct 2012 14:39:38 +1100
Message-ID: 
From: John Krstev 
To: Konrad Rzeszutek Wilk 
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] Xen + DVB = not working. memory allocation issue?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0526011290617067797=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0526011290617067797==
Content-Type: multipart/alternative; boundary=20cf3074b3b2eaf45104ccd9f394

--20cf3074b3b2eaf45104ccd9f394
Content-Type: text/plain; charset=ISO-8859-1

Hi Konrad,


> >> Apologies if this has been asked before (I wasn't able to find another
> >> patch), but is there a patch to get this (suspected vmalloc_32) fixed
> >> and DVB card working?
> >

It would appear some recent-ish patches to the linux kernel has caused this
issue for me; while it did work on 3.2.

I don't think I am the only person in this situation.

> >> I have a winfast DVT 2000H (cx88) DVB card which is not able to
> >> scan/watch digital TV when running under Xen.


Could you post some patches you may think could help (which I can test) /
recommendations on using different kernel version, etc?

I'm not too sure what else to try / test at my end here....

FYI Xen 4.3-unstable with linux 3.6.4 (-pf patches applied) for Dom0.

Thank you again for your input! :)

Regards,

John

On 12 October 2012 15:43, John Krstev  wrote:

> Hi Konrad,
>
> I have done some more testing and like to share my findings:
>
>
> > > Did you first try running it under baremetal Linux (using a Live CD for
> > > example?) Did it work there?
> I have found that under kernel version 3.2.0 (stock debian kernel) when
> running on baremetal I get data, with or without kernel parameter
> "intel_iommu=1"  'cat /dev/video > /tmp/file' produces data there too.
> However when booting this kernel under Xen (Dom0) cannot get DVB data and
> get filter timeout with scan utility.
>
> With (custom built vanilla) kernel 3.6 and custom built 3.5 (with -pf
> patches), when running on baremetal; with intel_iommu=1 I am unable to get
> any DVB data. I have tried intel_iommu=0 and I still cannot get DVB data.
> To add to this I now have DMAR messages in dmesg output (06:00.0 is the DVB
> card) :
>
> [   * 0.074639*] DMAR:[DMA Read] Request device [06:00.0] fault addr
> 80c6000
> [    *0.074639*] DMAR:[fault reason 02] Present bit in context entry is
> clear
> [    0.422177] DMAR: No ATSR found
> [   49.194033] DMAR:[DMA Read] Request device [06:00.0] fault addr fff7f000
> [   49.194033] DMAR:[fault reason 02] Present bit in context entry is clear
>
> Also, I'm getting these (with intel_iommu=0 or with intel_iommu=1) under
> 3.5-pf kernel and 3.6 custom vanilla:
>
> [    0.418811] IOMMU: Setting identity map for device 0000:00:1f.0 [0x0 -
> 0xffffff]
> [    0.419294]  [] ? intel_iommu_device_group+0x64/0xb1
> [    0.419330]  [] ? bus_set_iommu+0x37/0x37
> [    0.419364]  [] ? add_iommu_group+0x12/0x2f
> [    0.419399]  [] ? bus_set_iommu+0x37/0x37
> [    0.420778]  [] ? bus_set_iommu+0x33/0x37
> [    0.420813]  [] ? intel_iommu_init+0x9a9/0xac5
> [    0.420920]  [] ? pci_iommu_init+0xe/0x37
>
>
> Now; I did manage to get it it work WITH Xen under the following
> conditions:
>
> Debian kernel 3.2.0 and Xen (Dom0) and passing "iommu=0" on the xen line.
>
> FYI I'd like to mention that I have had success doing VGA passthrough to
> Win XP guest (Intel on board graphics) so I'm reasonably confident the BIOS
> IOMMU code is OK (Asrock Z77 Extreme 4 motherboard - BIOS version 1.30).
>
> What are your thoughts?
>
> Regards,
>
> John
>
>
>
> On 26 September 2012 11:02, John Krstev  wrote:
>
>> Hey Konrad,
>>
>> >Please do not top-post.
>> Apologies.
>>
>>
>> >So try also limiting how much memory the hypervisor has to eliminate
>> >this being a 4GB issue. Meaning on the _hypervisor_ line add 'mem=4G'.
>>
>> Yes, that was on the hypervisor line which I was specifying mem=3G. I've
>> also tried mem=4G and still having the same problem.
>>
>>
>> >And I need to know whether you are running this in a domain or in the
>> initial domain?
>>
>> Running in Dom0.
>>
>>
>> >If you do it manually (cat /dev/video0 > /tmp/file.mpg)
>> >does the file increase? Is it full of garbage ?
>>
>> cat: /dev/video0: Input/output error
>>
>> The file size is 0 bytes.
>>
>>
>> >Does the channel selection work? Can you select the proper channel?
>> Analogue selection works ok and I can also watch analogue TV. When using
>> digital, I get a lock but no video data.
>>
>>
>> > If you crank up all the debug options do you get anything saying what
>> the problem is
>>
>> With debug turned on to level 8 (echo 8 > /proc/sys/kernel/printk) I see
>> the following in dmesg which may be useful:
>> [130009.484098] cx88[0]/0: [ffff8802c03b3400/0] timeout - dma=0x96a7e000
>>
>> Let me know if there's anything else I can try?
>>
>> Regards,
>>
>> John
>>
>>
>> On 26 September 2012 00:10, Konrad Rzeszutek Wilk wrote:
>>
>>> On Tue, Sep 25, 2012 at 10:49:38AM +1000, John Krstev wrote:
>>> > Hello Konrad,
>>>
>>> Hey John,
>>>
>>> Please do not top-post.
>>> >
>>> > Do you have any patches I can try? FYI I've tried booting dom0 with
>>> mem=3G and various other options, still does not work. As I mentioned it
>>> runs fine on bare metal.
>>>
>>> So try also limiting how much memory the hypervisor has to eliminate
>>> this being a 4GB issue. Meaning on the _hypervisor_ line add 'mem=4G'.
>>>
>>> The next step is to actually figure out if where in the driver (cx88)
>>> fails. And I need to know whether you are running this in a domain or
>>> in the initial domain? If you crank up all the debug options do you
>>> get anything saying what the problem is? How do you 'capture' the
>>> video output? If you do it manually (cat /dev/video0 > /tmp/file.mpg)
>>> does the file increase? Is it full of garbage ?
>>>
>>> Does the channel selection work? Can you select the proper channel?
>>>
>>> >
>>> > Last time it did work with xen was Jeremy's kernel + xen 4.0, also
>>> kernel 3.0.8 with xen 4.0.4 i believe (cannot reproduce success).
>>> >
>>> > Thank you again for your input.
>>> >
>>> > Regards,
>>> >
>>> > John
>>> >
>>> >
>>> >
>>> > On 22/09/2012, at 3:29, Konrad Rzeszutek Wilk 
>>> wrote:
>>> >
>>> > > On Fri, Sep 21, 2012 at 01:02:23PM +1000, John Krstev wrote:
>>> > >> Hi Konrad,
>>> > >
>>> > > Hey John,
>>> > >
>>> > > Please next time also include xen-devel on the To header. I've done
>>> that
>>> > > for you.
>>> > >>
>>> > >> I refer to your patch at:
>>> > >> http://lists.xen.org/archives/html/xen-devel/2012-01/msg01927.html
>>> > >> which I found reading
>>> > >> http://www.gossamer-threads.com/lists/xen/devel/256197
>>> > >>
>>> > >> I have a winfast DVT 2000H (cx88) DVB card which is not able to
>>> > >> scan/watch digital TV when running under Xen.
>>> > >
>>> > > Did you first try running it under baremetal Linux (using a Live CD
>>> for
>>> > > example?) Did it work there?
>>> > >
>>> > > How does it not work? Can you program it? Is this under a guest or
>>> the
>>> > > main kernel? When it wsa not working, did you try all the debug
>>> > > options enable (http://wiki.xen.org/wiki/XenSerialConsole) to
>>> > > see if there is anthing being reported?
>>> > >
>>> > >>
>>> > >> I've tried installing the above patch to the 3.6-rc6 kernel, but did
>>> > >> not seem to help.
>>> > >>
>>> > >> Apologies if this has been asked before (I wasn't able to find
>>> another
>>> > >> patch), but is there a patch to get this (suspected vmalloc_32)
>>> fixed
>>> > >> and DVB card working?
>>> > >
>>> > > Eventually yes.
>>> > >>
>>> > >> FYI I'm running 64 bit 3.5-rc6 and xen 4.3-unstable.
>>> > >
>>> > > 3.5-rc6 or 3.6-rc6?
>>> > > I presume the latter?
>>> > >>
>>> > >> Thank you! :)
>>> > >>
>>> > >> Regards,
>>> > >>
>>> > >> John
>>> > >>
>>> >
>>> > _______________________________________________
>>> > Xen-devel mailing list
>>> > Xen-devel@lists.xen.org
>>> > http://lists.xen.org/xen-devel
>>> >
>>>
>>
>>
>

--20cf3074b3b2eaf45104ccd9f394
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Konrad,


> >> Apologies if this has been asked before=
 (I wasn't able to find another

> >> patch), but is there a patch to get this (suspected vmalloc_3=
2) fixed

> >> and DVB card working?

> >

It would appear some recent-ish patches to the linux kerne=
l has caused this issue for me; while it did work on 3.2.

I don'=
t think I am the only person in this situation.

> >> I have=
 a winfast DVT 2000H (cx88) DVB card which is not able to


> >> scan/watch digital TV when running under Xen.


Coul=
d you post some patches you may think could help (which I can test) / recom=
mendations on using different kernel version, etc?

I'm not too s=
ure what else to try / test at my end here....


FYI Xen 4.3-unstable with linux 3.6.4 (-pf patches applied) for Dom0.
Thank you again for your input! :)

Regards,

John
On 12 October 2012 15:43, John Krstev <joh=
n.krstev@gmail.com> wrote:


Hi Konrad,

I have done some more test=
ing and like to share my findings:


> > Did y=
ou first try running it under baremetal Linux (using a Live CD for


> > example?) Did it work there?
I have found that under ker=
nel version 3.2.0 (stock debian kernel) when running on baremetal I get dat=
a, with or without kernel parameter "intel_iommu=3D1"=A0 'cat=
 /dev/video > /tmp/file' produces data there too. However when booti=
ng this kernel under Xen (Dom0) cannot get DVB data and get filter timeout =
with scan utility.



With (custom built vanilla) kernel 3.6 and custom built 3.5 (with -pf p=
atches), when running on baremetal; with intel_iommu=3D1 I am unable to get=
 any DVB data. I have tried intel_iommu=3D0 and I still cannot get DVB data=
. To add to this I now have DMAR messages in dmesg output (06:00.0 is the D=
VB card) :



[=A0=A0=A0 0.074639] DMAR:[DMA Read] Request device [06:00.0] fa=
ult addr 80c6000
[=A0=A0=A0 0.074639] DMAR:[fault reason 02] Pres=
ent bit in context entry is clear
[=A0=A0=A0 0.422177] DMAR: No ATSR fou=
nd
[=A0=A0 49.194033] DMAR:[DMA Read] Request device [06:00.0] fault add=
r fff7f000


[=A0=A0 49.194033] DMAR:[fault reason 02] Present bit in context entry is c=
lear

Also, I'm getting these (with intel_iommu=3D0 or with intel=
_iommu=3D1) under 3.5-pf kernel and 3.6 custom vanilla:

[=A0=A0=A0 0=
.418811] IOMMU: Setting identity map for device 0000:00:1f.0 [0x0 - 0xfffff=
f]


[=A0=A0=A0 0.419294]=A0 [<ffffffff81250d01>] ? intel_iommu_device_gro=
up+0x64/0xb1
[=A0=A0=A0 0.419330]=A0 [<ffffffff8124c9b0>] ? bus_se=
t_iommu+0x37/0x37
[=A0=A0=A0 0.419364]=A0 [<ffffffff8124c9c2>] ? a=
dd_iommu_group+0x12/0x2f


[=A0=A0=A0 0.419399]=A0 [<ffffffff8124c9b0>] ? bus_set_iommu+0x37/0x3=
7
[=A0=A0=A0 0.420778]=A0 [<ffffffff8124c9ac>] ? bus_set_iommu+0x3=
3/0x37
[=A0=A0=A0 0.420813]=A0 [<ffffffff814c39c0>] ? intel_iommu_=
init+0x9a9/0xac5


[=A0=A0=A0 0.420920]=A0 [<ffffffff8149c7df>] ? pci_iommu_init+0xe/0x3=
7


Now; I did manage to get it it work WITH Xen under the followi=
ng conditions:

Debian kernel 3.2.0 and Xen (Dom0) and passing "=
iommu=3D0" on the xen line. 



FYI I'd like to mention that I have had success doing VGA passthrou=
gh to Win XP guest (Intel on board graphics) so I'm reasonably confiden=
t the BIOS IOMMU code is OK (Asrock Z77 Extreme 4 motherboard - BIOS versio=
n 1.30).



What are your thoughts?

Regards,

John



On 26 September =
2012 11:02, John Krstev <john.krstev@gmail.com> wrote:


Hey Konrad,

>Please do not top-pos=
t.
Apologies. 


>So try also limiting how much memory =
the hypervisor has to eliminate



>this being a 4GB issue. Meaning on the _hypervisor_ line add 'mem=
=3D4G'.

Yes, that was on the hypervisor line which I was s=
pecifying mem=3D3G. I've also tried mem=3D4G and still having the same =
problem.





>And I need to know whether you are running this in a domain or in t=
he initial domain?


Running in Dom0.


>If you do it manually (cat /dev/=
video0 > /tmp/file.mpg)

>does the file increase? Is it full of garbage ?

cat: /dev/=
video0: Input/output error

The file size is 0 bytes.


>=
;Does the channel selection work? Can you select the proper channel?



Analogue selection works ok and I can also watch analogue TV. When us=
ing digital, I get a lock but no video data.




> If you crank up all the debug options do you get anything saying w=
hat the problem is

With debug turned on to level 8 (echo 8 >=
; /proc/sys/kernel/printk) I see the following in dmesg which may be useful=
:



[130009.484098] cx88[0]/0: [ffff8802c03b3400/0] timeout - dma=3D0x96a7e000<=
br>
Let me know if there's anything else I can try?

Regards,<=
br>
John



On 26 September 2012 00:10, Konrad Rzeszutek Wilk <konrad@kernel.org&g=
t; wrote:



On Tue, Sep 25, 2012 at 10:49:38AM +1000, John Krstev wrote:

> Hello Konrad,



Hey John,



Please do not top-post.


>

> Do you have any patches I can try? FYI I've tried booting dom0 wit=
h mem=3D3G and various other options, still does not work. As I mentioned i=
t runs fine on bare metal.




So try also limiting how much memory the hypervisor has to eliminate<=
br>
this being a 4GB issue. Meaning on the _hypervisor_ line add 'mem=3D4G&=
#39;.



The next step is to actually figure out if where in the driver (cx88)

fails. And I need to know whether you are running this in a domain or

in the initial domain? If you crank up all the debug options do you

get anything saying what the problem is? How do you 'capture' the
video output? If you do it manually (cat /dev/video0 > /tmp/file.mpg)
does the file increase? Is it full of garbage ?



Does the channel selection work? Can you select the proper channel?




>

> Last time it did work with xen was Jeremy's kernel + xen 4.0, also=
 kernel 3.0.8 with xen 4.0.4 i believe (cannot reproduce success).

>

> Thank you again for your input.

>

> Regards,

>

> John

>

>

>

> On 22/09/2012, at 3:29, Konrad Rzeszutek Wilk <konrad@kernel.org> wrote:

>

> > On Fri, Sep 21, 2012 at 01:02:23PM +1000, John Krstev wrote:

> >> Hi Konrad,

> >

> > Hey John,

> >

> > Please next time also include xen-devel on the To header. I'v=
e done that

> > for you.

> >>

> >> I refer to your patch at:

> >> http://lists.xen.org/archives/html/xen-=
devel/2012-01/msg01927.html

> >> which I found reading

> >> http://www.gossamer-threads.com/lists/xen/devel/256=
197

> >>

> >> I have a winfast DVT 2000H (cx88) DVB card which is not able =
to

> >> scan/watch digital TV when running under Xen.

> >

> > Did you first try running it under baremetal Linux (using a Live =
CD for

> > example?) Did it work there?

> >

> > How does it not work? Can you program it? Is this under a guest o=
r the

> > main kernel? When it wsa not working, did you try all the debug
> > options enable (http://wiki.xen.org/wiki/XenSerialConsole) to
> > see if there is anthing being reported?

> >

> >>

> >> I've tried installing the above patch to the 3.6-rc6 kern=
el, but did

> >> not seem to help.

> >>

> >> Apologies if this has been asked before (I wasn't able to=
 find another

> >> patch), but is there a patch to get this (suspected vmalloc_3=
2) fixed

> >> and DVB card working?

> >

> > Eventually yes.

> >>

> >> FYI I'm running 64 bit 3.5-rc6 and xen 4.3-unstable.

> >

> > 3.5-rc6 or 3.6-rc6?

> > I presume the latter?

> >>

> >> Thank you! :)

> >>

> >> Regards,

> >>

> >> John

> >>

>


> _______________________________________________

> Xen-devel mailing list

> Xen-devel=
@lists.xen.org

> http://li=
sts.xen.org/xen-devel

>











--20cf3074b3b2eaf45104ccd9f394--


--===============0526011290617067797==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0526011290617067797==--


From xen-devel-bounces@lists.xen.org Thu Oct 25 03:40:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 03:40:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TREIL-0000ez-Q6; Thu, 25 Oct 2012 03:39:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TREIJ-0000eu-FY
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 03:39:43 +0000
Received: from [85.158.143.35:49028] by server-1.bemta-4.messagelabs.com id
	CD/44-19134-E74B8805; Thu, 25 Oct 2012 03:39:42 +0000
X-Env-Sender: john.krstev@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1351136379!12600967!1
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30184 invoked from network); 25 Oct 2012 03:39:40 -0000
Received: from mail-qa0-f43.google.com (HELO mail-qa0-f43.google.com)
	(209.85.216.43)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 03:39:40 -0000
Received: by mail-qa0-f43.google.com with SMTP id k1so3451358qaf.9
	for ;
	Wed, 24 Oct 2012 20:39:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=mMzlvNrag6xNXW5QtM82KwAWCq1ycfRpVJoA1WDS78o=;
	b=PtP8m9oMaE+4VBLBi0Wr0J0cw8AdSYX3/lHr4w76VUUsk636zpr/wQMe+O580dOb5+
	or3Vsp0/NHl+sS/3xdfU710pmjC4sSVvPQWUIev0hsDV9+49C4s08YJsDptdmCOAij5e
	wo3fWvf2bJZGvuLzXGAYZGRZ/Jeto788xodfeePWpgFhi9YsGiJvf5GvvZbX6pf3ygQj
	d9ko5VHfRFOJkStddBQjkHpV/GC43es5mT9j3QttbZOhUk2KoknSOa/UA6cjDZtsTJyY
	5uTe3Tfh5nL5MsC69MpdiYEaR/OOeyoySOiCTSiDELxk16u92wx5WFZyThoZ0ZjZ1W42
	1dWg==
MIME-Version: 1.0
Received: by 10.224.40.14 with SMTP id i14mr6734967qae.37.1351136379073; Wed,
	24 Oct 2012 20:39:39 -0700 (PDT)
Received: by 10.49.96.134 with HTTP; Wed, 24 Oct 2012 20:39:38 -0700 (PDT)
In-Reply-To: 
References: 
	<20120921172901.GA6821@phenom.dumpdata.com>
	<099949C5-C4C0-4D57-A778-849C94781372@gmail.com>
	<20120925141013.GC16478@phenom.dumpdata.com>
	
	
Date: Thu, 25 Oct 2012 14:39:38 +1100
Message-ID: 
From: John Krstev 
To: Konrad Rzeszutek Wilk 
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] Xen + DVB = not working. memory allocation issue?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0526011290617067797=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0526011290617067797==
Content-Type: multipart/alternative; boundary=20cf3074b3b2eaf45104ccd9f394

--20cf3074b3b2eaf45104ccd9f394
Content-Type: text/plain; charset=ISO-8859-1

Hi Konrad,


> >> Apologies if this has been asked before (I wasn't able to find another
> >> patch), but is there a patch to get this (suspected vmalloc_32) fixed
> >> and DVB card working?
> >

It would appear some recent-ish patches to the linux kernel has caused this
issue for me; while it did work on 3.2.

I don't think I am the only person in this situation.

> >> I have a winfast DVT 2000H (cx88) DVB card which is not able to
> >> scan/watch digital TV when running under Xen.


Could you post some patches you may think could help (which I can test) /
recommendations on using different kernel version, etc?

I'm not too sure what else to try / test at my end here....

FYI Xen 4.3-unstable with linux 3.6.4 (-pf patches applied) for Dom0.

Thank you again for your input! :)

Regards,

John

On 12 October 2012 15:43, John Krstev  wrote:

> Hi Konrad,
>
> I have done some more testing and like to share my findings:
>
>
> > > Did you first try running it under baremetal Linux (using a Live CD for
> > > example?) Did it work there?
> I have found that under kernel version 3.2.0 (stock debian kernel) when
> running on baremetal I get data, with or without kernel parameter
> "intel_iommu=1"  'cat /dev/video > /tmp/file' produces data there too.
> However when booting this kernel under Xen (Dom0) cannot get DVB data and
> get filter timeout with scan utility.
>
> With (custom built vanilla) kernel 3.6 and custom built 3.5 (with -pf
> patches), when running on baremetal; with intel_iommu=1 I am unable to get
> any DVB data. I have tried intel_iommu=0 and I still cannot get DVB data.
> To add to this I now have DMAR messages in dmesg output (06:00.0 is the DVB
> card) :
>
> [   * 0.074639*] DMAR:[DMA Read] Request device [06:00.0] fault addr
> 80c6000
> [    *0.074639*] DMAR:[fault reason 02] Present bit in context entry is
> clear
> [    0.422177] DMAR: No ATSR found
> [   49.194033] DMAR:[DMA Read] Request device [06:00.0] fault addr fff7f000
> [   49.194033] DMAR:[fault reason 02] Present bit in context entry is clear
>
> Also, I'm getting these (with intel_iommu=0 or with intel_iommu=1) under
> 3.5-pf kernel and 3.6 custom vanilla:
>
> [    0.418811] IOMMU: Setting identity map for device 0000:00:1f.0 [0x0 -
> 0xffffff]
> [    0.419294]  [] ? intel_iommu_device_group+0x64/0xb1
> [    0.419330]  [] ? bus_set_iommu+0x37/0x37
> [    0.419364]  [] ? add_iommu_group+0x12/0x2f
> [    0.419399]  [] ? bus_set_iommu+0x37/0x37
> [    0.420778]  [] ? bus_set_iommu+0x33/0x37
> [    0.420813]  [] ? intel_iommu_init+0x9a9/0xac5
> [    0.420920]  [] ? pci_iommu_init+0xe/0x37
>
>
> Now; I did manage to get it it work WITH Xen under the following
> conditions:
>
> Debian kernel 3.2.0 and Xen (Dom0) and passing "iommu=0" on the xen line.
>
> FYI I'd like to mention that I have had success doing VGA passthrough to
> Win XP guest (Intel on board graphics) so I'm reasonably confident the BIOS
> IOMMU code is OK (Asrock Z77 Extreme 4 motherboard - BIOS version 1.30).
>
> What are your thoughts?
>
> Regards,
>
> John
>
>
>
> On 26 September 2012 11:02, John Krstev  wrote:
>
>> Hey Konrad,
>>
>> >Please do not top-post.
>> Apologies.
>>
>>
>> >So try also limiting how much memory the hypervisor has to eliminate
>> >this being a 4GB issue. Meaning on the _hypervisor_ line add 'mem=4G'.
>>
>> Yes, that was on the hypervisor line which I was specifying mem=3G. I've
>> also tried mem=4G and still having the same problem.
>>
>>
>> >And I need to know whether you are running this in a domain or in the
>> initial domain?
>>
>> Running in Dom0.
>>
>>
>> >If you do it manually (cat /dev/video0 > /tmp/file.mpg)
>> >does the file increase? Is it full of garbage ?
>>
>> cat: /dev/video0: Input/output error
>>
>> The file size is 0 bytes.
>>
>>
>> >Does the channel selection work? Can you select the proper channel?
>> Analogue selection works ok and I can also watch analogue TV. When using
>> digital, I get a lock but no video data.
>>
>>
>> > If you crank up all the debug options do you get anything saying what
>> the problem is
>>
>> With debug turned on to level 8 (echo 8 > /proc/sys/kernel/printk) I see
>> the following in dmesg which may be useful:
>> [130009.484098] cx88[0]/0: [ffff8802c03b3400/0] timeout - dma=0x96a7e000
>>
>> Let me know if there's anything else I can try?
>>
>> Regards,
>>
>> John
>>
>>
>> On 26 September 2012 00:10, Konrad Rzeszutek Wilk wrote:
>>
>>> On Tue, Sep 25, 2012 at 10:49:38AM +1000, John Krstev wrote:
>>> > Hello Konrad,
>>>
>>> Hey John,
>>>
>>> Please do not top-post.
>>> >
>>> > Do you have any patches I can try? FYI I've tried booting dom0 with
>>> mem=3G and various other options, still does not work. As I mentioned it
>>> runs fine on bare metal.
>>>
>>> So try also limiting how much memory the hypervisor has to eliminate
>>> this being a 4GB issue. Meaning on the _hypervisor_ line add 'mem=4G'.
>>>
>>> The next step is to actually figure out if where in the driver (cx88)
>>> fails. And I need to know whether you are running this in a domain or
>>> in the initial domain? If you crank up all the debug options do you
>>> get anything saying what the problem is? How do you 'capture' the
>>> video output? If you do it manually (cat /dev/video0 > /tmp/file.mpg)
>>> does the file increase? Is it full of garbage ?
>>>
>>> Does the channel selection work? Can you select the proper channel?
>>>
>>> >
>>> > Last time it did work with xen was Jeremy's kernel + xen 4.0, also
>>> kernel 3.0.8 with xen 4.0.4 i believe (cannot reproduce success).
>>> >
>>> > Thank you again for your input.
>>> >
>>> > Regards,
>>> >
>>> > John
>>> >
>>> >
>>> >
>>> > On 22/09/2012, at 3:29, Konrad Rzeszutek Wilk 
>>> wrote:
>>> >
>>> > > On Fri, Sep 21, 2012 at 01:02:23PM +1000, John Krstev wrote:
>>> > >> Hi Konrad,
>>> > >
>>> > > Hey John,
>>> > >
>>> > > Please next time also include xen-devel on the To header. I've done
>>> that
>>> > > for you.
>>> > >>
>>> > >> I refer to your patch at:
>>> > >> http://lists.xen.org/archives/html/xen-devel/2012-01/msg01927.html
>>> > >> which I found reading
>>> > >> http://www.gossamer-threads.com/lists/xen/devel/256197
>>> > >>
>>> > >> I have a winfast DVT 2000H (cx88) DVB card which is not able to
>>> > >> scan/watch digital TV when running under Xen.
>>> > >
>>> > > Did you first try running it under baremetal Linux (using a Live CD
>>> for
>>> > > example?) Did it work there?
>>> > >
>>> > > How does it not work? Can you program it? Is this under a guest or
>>> the
>>> > > main kernel? When it wsa not working, did you try all the debug
>>> > > options enable (http://wiki.xen.org/wiki/XenSerialConsole) to
>>> > > see if there is anthing being reported?
>>> > >
>>> > >>
>>> > >> I've tried installing the above patch to the 3.6-rc6 kernel, but did
>>> > >> not seem to help.
>>> > >>
>>> > >> Apologies if this has been asked before (I wasn't able to find
>>> another
>>> > >> patch), but is there a patch to get this (suspected vmalloc_32)
>>> fixed
>>> > >> and DVB card working?
>>> > >
>>> > > Eventually yes.
>>> > >>
>>> > >> FYI I'm running 64 bit 3.5-rc6 and xen 4.3-unstable.
>>> > >
>>> > > 3.5-rc6 or 3.6-rc6?
>>> > > I presume the latter?
>>> > >>
>>> > >> Thank you! :)
>>> > >>
>>> > >> Regards,
>>> > >>
>>> > >> John
>>> > >>
>>> >
>>> > _______________________________________________
>>> > Xen-devel mailing list
>>> > Xen-devel@lists.xen.org
>>> > http://lists.xen.org/xen-devel
>>> >
>>>
>>
>>
>

--20cf3074b3b2eaf45104ccd9f394
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Konrad,


> >> Apologies if this has been asked before=
 (I wasn't able to find another

> >> patch), but is there a patch to get this (suspected vmalloc_3=
2) fixed

> >> and DVB card working?

> >

It would appear some recent-ish patches to the linux kerne=
l has caused this issue for me; while it did work on 3.2.

I don'=
t think I am the only person in this situation.

> >> I have=
 a winfast DVT 2000H (cx88) DVB card which is not able to


> >> scan/watch digital TV when running under Xen.


Coul=
d you post some patches you may think could help (which I can test) / recom=
mendations on using different kernel version, etc?

I'm not too s=
ure what else to try / test at my end here....


FYI Xen 4.3-unstable with linux 3.6.4 (-pf patches applied) for Dom0.
Thank you again for your input! :)

Regards,

John
On 12 October 2012 15:43, John Krstev <joh=
n.krstev@gmail.com> wrote:


Hi Konrad,

I have done some more test=
ing and like to share my findings:


> > Did y=
ou first try running it under baremetal Linux (using a Live CD for


> > example?) Did it work there?
I have found that under ker=
nel version 3.2.0 (stock debian kernel) when running on baremetal I get dat=
a, with or without kernel parameter "intel_iommu=3D1"=A0 'cat=
 /dev/video > /tmp/file' produces data there too. However when booti=
ng this kernel under Xen (Dom0) cannot get DVB data and get filter timeout =
with scan utility.



With (custom built vanilla) kernel 3.6 and custom built 3.5 (with -pf p=
atches), when running on baremetal; with intel_iommu=3D1 I am unable to get=
 any DVB data. I have tried intel_iommu=3D0 and I still cannot get DVB data=
. To add to this I now have DMAR messages in dmesg output (06:00.0 is the D=
VB card) :



[=A0=A0=A0 0.074639] DMAR:[DMA Read] Request device [06:00.0] fa=
ult addr 80c6000
[=A0=A0=A0 0.074639] DMAR:[fault reason 02] Pres=
ent bit in context entry is clear
[=A0=A0=A0 0.422177] DMAR: No ATSR fou=
nd
[=A0=A0 49.194033] DMAR:[DMA Read] Request device [06:00.0] fault add=
r fff7f000


[=A0=A0 49.194033] DMAR:[fault reason 02] Present bit in context entry is c=
lear

Also, I'm getting these (with intel_iommu=3D0 or with intel=
_iommu=3D1) under 3.5-pf kernel and 3.6 custom vanilla:

[=A0=A0=A0 0=
.418811] IOMMU: Setting identity map for device 0000:00:1f.0 [0x0 - 0xfffff=
f]


[=A0=A0=A0 0.419294]=A0 [<ffffffff81250d01>] ? intel_iommu_device_gro=
up+0x64/0xb1
[=A0=A0=A0 0.419330]=A0 [<ffffffff8124c9b0>] ? bus_se=
t_iommu+0x37/0x37
[=A0=A0=A0 0.419364]=A0 [<ffffffff8124c9c2>] ? a=
dd_iommu_group+0x12/0x2f


[=A0=A0=A0 0.419399]=A0 [<ffffffff8124c9b0>] ? bus_set_iommu+0x37/0x3=
7
[=A0=A0=A0 0.420778]=A0 [<ffffffff8124c9ac>] ? bus_set_iommu+0x3=
3/0x37
[=A0=A0=A0 0.420813]=A0 [<ffffffff814c39c0>] ? intel_iommu_=
init+0x9a9/0xac5


[=A0=A0=A0 0.420920]=A0 [<ffffffff8149c7df>] ? pci_iommu_init+0xe/0x3=
7


Now; I did manage to get it it work WITH Xen under the followi=
ng conditions:

Debian kernel 3.2.0 and Xen (Dom0) and passing "=
iommu=3D0" on the xen line. 



FYI I'd like to mention that I have had success doing VGA passthrou=
gh to Win XP guest (Intel on board graphics) so I'm reasonably confiden=
t the BIOS IOMMU code is OK (Asrock Z77 Extreme 4 motherboard - BIOS versio=
n 1.30).



What are your thoughts?

Regards,

John



On 26 September =
2012 11:02, John Krstev <john.krstev@gmail.com> wrote:


Hey Konrad,

>Please do not top-pos=
t.
Apologies. 


>So try also limiting how much memory =
the hypervisor has to eliminate



>this being a 4GB issue. Meaning on the _hypervisor_ line add 'mem=
=3D4G'.

Yes, that was on the hypervisor line which I was s=
pecifying mem=3D3G. I've also tried mem=3D4G and still having the same =
problem.





>And I need to know whether you are running this in a domain or in t=
he initial domain?


Running in Dom0.


>If you do it manually (cat /dev/=
video0 > /tmp/file.mpg)

>does the file increase? Is it full of garbage ?

cat: /dev/=
video0: Input/output error

The file size is 0 bytes.


>=
;Does the channel selection work? Can you select the proper channel?



Analogue selection works ok and I can also watch analogue TV. When us=
ing digital, I get a lock but no video data.




> If you crank up all the debug options do you get anything saying w=
hat the problem is

With debug turned on to level 8 (echo 8 >=
; /proc/sys/kernel/printk) I see the following in dmesg which may be useful=
:



[130009.484098] cx88[0]/0: [ffff8802c03b3400/0] timeout - dma=3D0x96a7e000<=
br>
Let me know if there's anything else I can try?

Regards,<=
br>
John



On 26 September 2012 00:10, Konrad Rzeszutek Wilk <konrad@kernel.org&g=
t; wrote:



On Tue, Sep 25, 2012 at 10:49:38AM +1000, John Krstev wrote:

> Hello Konrad,



Hey John,



Please do not top-post.


>

> Do you have any patches I can try? FYI I've tried booting dom0 wit=
h mem=3D3G and various other options, still does not work. As I mentioned i=
t runs fine on bare metal.




So try also limiting how much memory the hypervisor has to eliminate<=
br>
this being a 4GB issue. Meaning on the _hypervisor_ line add 'mem=3D4G&=
#39;.



The next step is to actually figure out if where in the driver (cx88)

fails. And I need to know whether you are running this in a domain or

in the initial domain? If you crank up all the debug options do you

get anything saying what the problem is? How do you 'capture' the
video output? If you do it manually (cat /dev/video0 > /tmp/file.mpg)
does the file increase? Is it full of garbage ?



Does the channel selection work? Can you select the proper channel?




>

> Last time it did work with xen was Jeremy's kernel + xen 4.0, also=
 kernel 3.0.8 with xen 4.0.4 i believe (cannot reproduce success).

>

> Thank you again for your input.

>

> Regards,

>

> John

>

>

>

> On 22/09/2012, at 3:29, Konrad Rzeszutek Wilk <konrad@kernel.org> wrote:

>

> > On Fri, Sep 21, 2012 at 01:02:23PM +1000, John Krstev wrote:

> >> Hi Konrad,

> >

> > Hey John,

> >

> > Please next time also include xen-devel on the To header. I'v=
e done that

> > for you.

> >>

> >> I refer to your patch at:

> >> http://lists.xen.org/archives/html/xen-=
devel/2012-01/msg01927.html

> >> which I found reading

> >> http://www.gossamer-threads.com/lists/xen/devel/256=
197

> >>

> >> I have a winfast DVT 2000H (cx88) DVB card which is not able =
to

> >> scan/watch digital TV when running under Xen.

> >

> > Did you first try running it under baremetal Linux (using a Live =
CD for

> > example?) Did it work there?

> >

> > How does it not work? Can you program it? Is this under a guest o=
r the

> > main kernel? When it wsa not working, did you try all the debug
> > options enable (http://wiki.xen.org/wiki/XenSerialConsole) to
> > see if there is anthing being reported?

> >

> >>

> >> I've tried installing the above patch to the 3.6-rc6 kern=
el, but did

> >> not seem to help.

> >>

> >> Apologies if this has been asked before (I wasn't able to=
 find another

> >> patch), but is there a patch to get this (suspected vmalloc_3=
2) fixed

> >> and DVB card working?

> >

> > Eventually yes.

> >>

> >> FYI I'm running 64 bit 3.5-rc6 and xen 4.3-unstable.

> >

> > 3.5-rc6 or 3.6-rc6?

> > I presume the latter?

> >>

> >> Thank you! :)

> >>

> >> Regards,

> >>

> >> John

> >>

>


> _______________________________________________

> Xen-devel mailing list

> Xen-devel=
@lists.xen.org

> http://li=
sts.xen.org/xen-devel

>











--20cf3074b3b2eaf45104ccd9f394--


--===============0526011290617067797==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0526011290617067797==--


From xen-devel-bounces@lists.xen.org Thu Oct 25 04:33:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 04:33:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRF7r-00013I-Jg; Thu, 25 Oct 2012 04:32:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRF7q-00013D-6f
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 04:32:58 +0000
Received: from [85.158.143.99:9338] by server-2.bemta-4.messagelabs.com id
	4D/8A-22268-9F0C8805; Thu, 25 Oct 2012 04:32:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1351139576!29191610!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU2MTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22222 invoked from network); 25 Oct 2012 04:32:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 04:32:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,645,1344211200"; d="scan'208";a="15372862"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 04:32:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 05:32:48 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TRF7g-0000lh-ES;
	Thu, 25 Oct 2012 04:32:48 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TRF7f-000837-Vu;
	Thu, 25 Oct 2012 05:32:48 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Thu, 25 Oct 2012 05:32:48 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14075: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14075 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14075/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 14074
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 14074
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 14074
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 14074

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  22e08c9ac770
baseline version:
 xen                  22e08c9ac770

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 04:33:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 04:33:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRF7r-00013I-Jg; Thu, 25 Oct 2012 04:32:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRF7q-00013D-6f
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 04:32:58 +0000
Received: from [85.158.143.99:9338] by server-2.bemta-4.messagelabs.com id
	4D/8A-22268-9F0C8805; Thu, 25 Oct 2012 04:32:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1351139576!29191610!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU2MTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22222 invoked from network); 25 Oct 2012 04:32:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 04:32:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,645,1344211200"; d="scan'208";a="15372862"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 04:32:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 05:32:48 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TRF7g-0000lh-ES;
	Thu, 25 Oct 2012 04:32:48 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TRF7f-000837-Vu;
	Thu, 25 Oct 2012 05:32:48 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Thu, 25 Oct 2012 05:32:48 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14075: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14075 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14075/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 14074
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 14074
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 14074
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 14074

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  22e08c9ac770
baseline version:
 xen                  22e08c9ac770

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 07:31:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 07:31:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRHu9-00029L-Ou; Thu, 25 Oct 2012 07:31:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRHu7-00029G-Ou
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 07:30:59 +0000
Received: from [85.158.143.35:38233] by server-1.bemta-4.messagelabs.com id
	17/54-19134-3BAE8805; Thu, 25 Oct 2012 07:30:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1351150257!11632311!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMjA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9234 invoked from network); 25 Oct 2012 07:30:58 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-21.messagelabs.com with SMTP;
	25 Oct 2012 07:30:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 25 Oct 2012 08:30:56 +0100
Message-Id: <508906CE02000078000A4553@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 25 Oct 2012 08:30:54 +0100
From: "Jan Beulich" 
To: "Stefano Stabellini" ,
	,
	"Konrad Rzeszutek Wilk" ,
	"Randy Dunlap" 
References: <20121024151957.28a1626cd9a59c014e78c401@canb.auug.org.au>
	<50885EA8.3050007@xenotime.net>
In-Reply-To: <50885EA8.3050007@xenotime.net>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Stephen Rothwell ,
	Jeremy Fitzhardinge , linux-kernel@vger.kernel.org,
	xen-devel , linux-next@vger.kernel.org,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] linux-next: Tree for Oct 24 (xen)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 24.10.12 at 23:33, Randy Dunlap  wrote:
> On 10/23/2012 09:19 PM, Stephen Rothwell wrote:
> 
>> Hi all,
>> 
>> Changes since 201201023:
>> 
> 
> on x86_64:
> 
> drivers/built-in.o: In function `dbgp_reset_prep':
> (.text+0xb96b5): undefined reference to `xen_dbgp_reset_prep'
> drivers/built-in.o: In function `dbgp_external_startup':
> (.text+0xb9d95): undefined reference to `xen_dbgp_external_startup'
> 
> 
> Full randconfig file is attached.

So this is because with !USB_SUPPORT but EARLY_PRINTK_DBGP
dbgp_reset_prep() and dbgp_external_startup() get pointlessly
defined and exported. This got broken by the merge
recommendation for the ARM side changes (originally compilation
of drivers/xen/dbgp.c depended on just CONFIG_XEN_DOM0).

>From my pov, fixing the USB side would be the clean solution (i.e.
putting those function definitions inside a CONFIG_USB_SUPPORT
conditional).

The alternative of a smaller change would be to extend the
conditional around the respective xen_dbgp_...() declarations
in include/linux/usb/ehci_def.h to become

#if defined(CONFIG_XEN_DOM0) && defined(CONFIG_USB_SUPPORT)

Please advise towards your preference.

Jan




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 07:31:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 07:31:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRHu9-00029L-Ou; Thu, 25 Oct 2012 07:31:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRHu7-00029G-Ou
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 07:30:59 +0000
Received: from [85.158.143.35:38233] by server-1.bemta-4.messagelabs.com id
	17/54-19134-3BAE8805; Thu, 25 Oct 2012 07:30:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1351150257!11632311!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMjA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9234 invoked from network); 25 Oct 2012 07:30:58 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-21.messagelabs.com with SMTP;
	25 Oct 2012 07:30:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 25 Oct 2012 08:30:56 +0100
Message-Id: <508906CE02000078000A4553@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 25 Oct 2012 08:30:54 +0100
From: "Jan Beulich" 
To: "Stefano Stabellini" ,
	,
	"Konrad Rzeszutek Wilk" ,
	"Randy Dunlap" 
References: <20121024151957.28a1626cd9a59c014e78c401@canb.auug.org.au>
	<50885EA8.3050007@xenotime.net>
In-Reply-To: <50885EA8.3050007@xenotime.net>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Stephen Rothwell ,
	Jeremy Fitzhardinge , linux-kernel@vger.kernel.org,
	xen-devel , linux-next@vger.kernel.org,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] linux-next: Tree for Oct 24 (xen)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 24.10.12 at 23:33, Randy Dunlap  wrote:
> On 10/23/2012 09:19 PM, Stephen Rothwell wrote:
> 
>> Hi all,
>> 
>> Changes since 201201023:
>> 
> 
> on x86_64:
> 
> drivers/built-in.o: In function `dbgp_reset_prep':
> (.text+0xb96b5): undefined reference to `xen_dbgp_reset_prep'
> drivers/built-in.o: In function `dbgp_external_startup':
> (.text+0xb9d95): undefined reference to `xen_dbgp_external_startup'
> 
> 
> Full randconfig file is attached.

So this is because with !USB_SUPPORT but EARLY_PRINTK_DBGP
dbgp_reset_prep() and dbgp_external_startup() get pointlessly
defined and exported. This got broken by the merge
recommendation for the ARM side changes (originally compilation
of drivers/xen/dbgp.c depended on just CONFIG_XEN_DOM0).

>From my pov, fixing the USB side would be the clean solution (i.e.
putting those function definitions inside a CONFIG_USB_SUPPORT
conditional).

The alternative of a smaller change would be to extend the
conditional around the respective xen_dbgp_...() declarations
in include/linux/usb/ehci_def.h to become

#if defined(CONFIG_XEN_DOM0) && defined(CONFIG_USB_SUPPORT)

Please advise towards your preference.

Jan




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 07:37:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 07:37:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRHzx-0002Jl-W6; Thu, 25 Oct 2012 07:37:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRHzv-0002Jf-JF
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 07:37:00 +0000
Received: from [85.158.139.211:9355] by server-3.bemta-5.messagelabs.com id
	B5/B8-28618-A1CE8805; Thu, 25 Oct 2012 07:36:58 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-16.tower-206.messagelabs.com!1351150618!23684715!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_TEST_2,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11548 invoked from network); 25 Oct 2012 07:36:58 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 07:36:58 -0000
Received: by mail-ee0-f43.google.com with SMTP id c13so576962eek.30
	for ;
	Thu, 25 Oct 2012 00:36:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google;
	h=mime-version:sender:x-originating-ip:from:date:x-google-sender-auth
	:message-id:subject:to:content-type;
	bh=3GPjMLYWR06AC9EVcMXdj/Z/6soRfoPYA3Kl37jrbfY=;
	b=NveA56eUTTZr/7SZtr9pkZIxabstnj5+5hUyJow5j61HlE/1oO6FmD+1OhtmZN4CUK
	ierZOyWlvuSfIdTld/Kf96yHYWOMFg8TKjwfaQfgB9/iWeKI9fUPfLIeFJwlIltZA2dq
	XK0Xa5c0CA6+AjFOzEZEik3bvoIHc3m8+FwkI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:sender:x-originating-ip:from:date:x-google-sender-auth
	:message-id:subject:to:content-type:x-gm-message-state;
	bh=3GPjMLYWR06AC9EVcMXdj/Z/6soRfoPYA3Kl37jrbfY=;
	b=VkbH0lz8O8xhZCBJs92aaufq3Os/r+2snqGIxp0GzH8BUcOKKn8bX7e52WNvzIRRKa
	NvKTUStWd/eA83zSlQ7BF5+T3h99IkmqS+1oyrWFH0t6oAyqTfX7JmEBpfll8E3jaaI0
	SrFtTUW9O0Gam/QJ2YQp8Lmz57gYgnpG+DDBIviu+xpMQGyJsVyr16398+Tz1TDuVvyM
	sQLtq1aHsFPb4lr0vACGH7XbSh5ucY9K1pMisT1055M2n+zBUH1ONeF9uFOF21Rv2uQN
	ILo0/IT+zIzxvlIwBkXXKrrBa47DIG5bneLtl4fWBDVyc+nHDoXCPw2j7xkaDZt8GSsW
	cdUg==
Received: by 10.14.194.71 with SMTP id l47mr24832947een.6.1351150618044; Thu,
	25 Oct 2012 00:36:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.14.133.143 with HTTP; Thu, 25 Oct 2012 00:36:42 -0700 (PDT)
X-Originating-IP: [85.143.161.18]
From: Vasiliy Tolstov 
Date: Thu, 25 Oct 2012 11:36:42 +0400
X-Google-Sender-Auth: YGqdhBhe2CJt2frBwFpHsKug8IM
Message-ID: 
To: xen-devel@lists.xensource.com
X-Gm-Message-State: ALoCoQncPbn6vELJmyLGluYtRGcqitwle6OaRt7FiwwpByF+V6mjNEmnMk/5R++mu60FIwEzj8YD
Subject: [Xen-devel] status of the curernt virtio support under xen pvm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello, xen-team. Does xen have any progress for supporting virtio
after publishing this wiki page http://wiki.xen.org/wiki/Virtio_On_Xen
?
Does xen 4.2 have support virtio on dom0 side?

-- 
Vasiliy Tolstov,
Clodo.ru
e-mail: v.tolstov@selfip.ru
jabber: vase@selfip.ru

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 07:37:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 07:37:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRHzx-0002Jl-W6; Thu, 25 Oct 2012 07:37:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRHzv-0002Jf-JF
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 07:37:00 +0000
Received: from [85.158.139.211:9355] by server-3.bemta-5.messagelabs.com id
	B5/B8-28618-A1CE8805; Thu, 25 Oct 2012 07:36:58 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-16.tower-206.messagelabs.com!1351150618!23684715!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_TEST_2,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11548 invoked from network); 25 Oct 2012 07:36:58 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 07:36:58 -0000
Received: by mail-ee0-f43.google.com with SMTP id c13so576962eek.30
	for ;
	Thu, 25 Oct 2012 00:36:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google;
	h=mime-version:sender:x-originating-ip:from:date:x-google-sender-auth
	:message-id:subject:to:content-type;
	bh=3GPjMLYWR06AC9EVcMXdj/Z/6soRfoPYA3Kl37jrbfY=;
	b=NveA56eUTTZr/7SZtr9pkZIxabstnj5+5hUyJow5j61HlE/1oO6FmD+1OhtmZN4CUK
	ierZOyWlvuSfIdTld/Kf96yHYWOMFg8TKjwfaQfgB9/iWeKI9fUPfLIeFJwlIltZA2dq
	XK0Xa5c0CA6+AjFOzEZEik3bvoIHc3m8+FwkI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:sender:x-originating-ip:from:date:x-google-sender-auth
	:message-id:subject:to:content-type:x-gm-message-state;
	bh=3GPjMLYWR06AC9EVcMXdj/Z/6soRfoPYA3Kl37jrbfY=;
	b=VkbH0lz8O8xhZCBJs92aaufq3Os/r+2snqGIxp0GzH8BUcOKKn8bX7e52WNvzIRRKa
	NvKTUStWd/eA83zSlQ7BF5+T3h99IkmqS+1oyrWFH0t6oAyqTfX7JmEBpfll8E3jaaI0
	SrFtTUW9O0Gam/QJ2YQp8Lmz57gYgnpG+DDBIviu+xpMQGyJsVyr16398+Tz1TDuVvyM
	sQLtq1aHsFPb4lr0vACGH7XbSh5ucY9K1pMisT1055M2n+zBUH1ONeF9uFOF21Rv2uQN
	ILo0/IT+zIzxvlIwBkXXKrrBa47DIG5bneLtl4fWBDVyc+nHDoXCPw2j7xkaDZt8GSsW
	cdUg==
Received: by 10.14.194.71 with SMTP id l47mr24832947een.6.1351150618044; Thu,
	25 Oct 2012 00:36:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.14.133.143 with HTTP; Thu, 25 Oct 2012 00:36:42 -0700 (PDT)
X-Originating-IP: [85.143.161.18]
From: Vasiliy Tolstov 
Date: Thu, 25 Oct 2012 11:36:42 +0400
X-Google-Sender-Auth: YGqdhBhe2CJt2frBwFpHsKug8IM
Message-ID: 
To: xen-devel@lists.xensource.com
X-Gm-Message-State: ALoCoQncPbn6vELJmyLGluYtRGcqitwle6OaRt7FiwwpByF+V6mjNEmnMk/5R++mu60FIwEzj8YD
Subject: [Xen-devel] status of the curernt virtio support under xen pvm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello, xen-team. Does xen have any progress for supporting virtio
after publishing this wiki page http://wiki.xen.org/wiki/Virtio_On_Xen
?
Does xen 4.2 have support virtio on dom0 side?

-- 
Vasiliy Tolstov,
Clodo.ru
e-mail: v.tolstov@selfip.ru
jabber: vase@selfip.ru

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 07:43:03 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 07:43:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRI5E-0002Si-PN; Thu, 25 Oct 2012 07:42:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRI5D-0002Sc-4L
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 07:42:27 +0000
Received: from [85.158.143.99:21153] by server-1.bemta-4.messagelabs.com id
	FB/63-19134-26DE8805; Thu, 25 Oct 2012 07:42:26 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-216.messagelabs.com!1351150945!22019846!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NjkxNzU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NjkxNzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26197 invoked from network); 25 Oct 2012 07:42:25 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Oct 2012 07:42:25 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll387qFkE=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-086-014.pools.arcor-ip.net [84.57.86.14])
	by smtp.strato.de (joses mo33) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id c02094o9P6sQKp ;
	Thu, 25 Oct 2012 09:42:25 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id AB46818642; Thu, 25 Oct 2012 09:42:23 +0200 (CEST)
Date: Thu, 25 Oct 2012 09:42:23 +0200
From: Olaf Hering 
To: Keir Fraser 
Message-ID: <20121025074223.GA15400@aepfle.de>
References: <6a0c73ae9ce5cca72f78.1351101425@probook.site>
	
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools/hvmloader: move shared_info to
 reserved memory area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 24, Keir Fraser wrote:

> Which can be as simple as the attached patch (in fact all the changes apart
> from introducing GUEST_RESERVED_{START,END} are really cleaning up and
> bug-fixing the out-of-space checks in the mem_hole_alloc/mem_alloc
> functions).
> 
> This then just requires that the guest maps shared-info to FE700000 itself.
> Should be quite easy. :)

The patch works for me. And the kernel patch I sent yesterday works as
well.
Is the memory area starting from 0xFC000000 also reserved in older
versions, such as Xen3?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 07:43:03 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 07:43:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRI5E-0002Si-PN; Thu, 25 Oct 2012 07:42:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRI5D-0002Sc-4L
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 07:42:27 +0000
Received: from [85.158.143.99:21153] by server-1.bemta-4.messagelabs.com id
	FB/63-19134-26DE8805; Thu, 25 Oct 2012 07:42:26 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-216.messagelabs.com!1351150945!22019846!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NjkxNzU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NjkxNzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26197 invoked from network); 25 Oct 2012 07:42:25 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Oct 2012 07:42:25 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll387qFkE=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-086-014.pools.arcor-ip.net [84.57.86.14])
	by smtp.strato.de (joses mo33) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id c02094o9P6sQKp ;
	Thu, 25 Oct 2012 09:42:25 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id AB46818642; Thu, 25 Oct 2012 09:42:23 +0200 (CEST)
Date: Thu, 25 Oct 2012 09:42:23 +0200
From: Olaf Hering 
To: Keir Fraser 
Message-ID: <20121025074223.GA15400@aepfle.de>
References: <6a0c73ae9ce5cca72f78.1351101425@probook.site>
	
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools/hvmloader: move shared_info to
 reserved memory area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 24, Keir Fraser wrote:

> Which can be as simple as the attached patch (in fact all the changes apart
> from introducing GUEST_RESERVED_{START,END} are really cleaning up and
> bug-fixing the out-of-space checks in the mem_hole_alloc/mem_alloc
> functions).
> 
> This then just requires that the guest maps shared-info to FE700000 itself.
> Should be quite easy. :)

The patch works for me. And the kernel patch I sent yesterday works as
well.
Is the memory area starting from 0xFC000000 also reserved in older
versions, such as Xen3?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 07:47:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 07:47:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRI9g-0002bT-IF; Thu, 25 Oct 2012 07:47:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRI9f-0002bN-9T
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 07:47:03 +0000
Received: from [193.109.254.147:10209] by server-11.bemta-14.messagelabs.com
	id 87/BE-29027-67EE8805; Thu, 25 Oct 2012 07:47:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1351151221!3481030!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU2MTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5450 invoked from network); 25 Oct 2012 07:47:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 07:47:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,646,1344211200"; d="scan'208";a="15374970"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 07:47:01 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 25 Oct 2012 08:47:01 +0100
Message-ID: <1351151219.18035.94.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Mukesh Rathor 
Date: Thu, 25 Oct 2012 08:46:59 +0100
In-Reply-To: <20121024170746.7c89a790@mantra.us.oracle.com>
References: <1351084756.18035.28.camel@zakaz.uk.xensource.com>
	<1351084777-28898-4-git-send-email-ian.campbell@citrix.com>
	<20121024164411.5b000087@mantra.us.oracle.com>
	<20121024170746.7c89a790@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	linux-kernel ,
	Konrad Rzeszutek Wilk ,
	xen-devel 
Subject: Re: [Xen-devel] [PATCH 4/5] xen: arm: implement remap interfaces
 needed for privcmd mappings.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVGh1LCAyMDEyLTEwLTI1IGF0IDAxOjA3ICswMTAwLCBNdWtlc2ggUmF0aG9yIHdyb3RlOgo+
IE9uIFdlZCwgMjQgT2N0IDIwMTIgMTY6NDQ6MTEgLTA3MDAKPiBNdWtlc2ggUmF0aG9yIDxtdWtl
c2gucmF0aG9yQG9yYWNsZS5jb20+IHdyb3RlOgo+IAo+ID4gPiAgCj4gPiA+ICAjaWZuZGVmIEhZ
UEVSVklTT1JfVklSVF9TVEFSVAo+ID4gPiBkaWZmIC0tZ2l0IGEvaW5jbHVkZS94ZW4vaW50ZXJm
YWNlL21lbW9yeS5oCj4gPiA+IGIvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL21lbW9yeS5oIGluZGV4
IGFkMGRmZjUuLjVkZTJiMzYgMTAwNjQ0Cj4gPiA+IC0tLSBhL2luY2x1ZGUveGVuL2ludGVyZmFj
ZS9tZW1vcnkuaAo+ID4gPiArKysgYi9pbmNsdWRlL3hlbi9pbnRlcmZhY2UvbWVtb3J5LmgKPiA+
ID4gQEAgLTE4OCw2ICsxODgsMjQgQEAgREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QoeGVuX2Fk
ZF90b19waHlzbWFwKTsKPiA+ID4gIC8qKiogUkVNT1ZFRCAqKiovCj4gPiA+ICAvKiNkZWZpbmUg
WEVOTUVNX3RyYW5zbGF0ZV9ncGZuX2xpc3QgIDgqLwo+ID4gPiAgCj4gPiA+ICsjZGVmaW5lIFhF
Tk1FTV9hZGRfdG9fcGh5c21hcF9yYW5nZSAyMwo+ID4gPiArc3RydWN0IHhlbl9hZGRfdG9fcGh5
c21hcF9yYW5nZSB7Cj4gPiA+ICsgICAgLyogV2hpY2ggZG9tYWluIHRvIGNoYW5nZSB0aGUgbWFw
cGluZyBmb3IuICovCj4gPiA+ICsgICAgZG9taWRfdCBkb21pZDsKPiA+ID4gKyAgICB1aW50MTZf
dCBzcGFjZTsgLyogPT4gZW51bSBwaHlzX21hcF9zcGFjZSAqLwo+ID4gPiArCj4gPiA+ICsgICAg
LyogTnVtYmVyIG9mIHBhZ2VzIHRvIGdvIHRocm91Z2ggKi8KPiA+ID4gKyAgICB1aW50MTZfdCBz
aXplOwo+ID4gPiArICAgIGRvbWlkX3QgZm9yZWlnbl9kb21pZDsgLyogSUZGIGdtZm5fZm9yZWln
biAqLwo+ID4gPiArCj4gPiA+ICsgICAgLyogSW5kZXhlcyBpbnRvIHNwYWNlIGJlaW5nIG1hcHBl
ZC4gKi8KPiA+ID4gKyAgICBHVUVTVF9IQU5ETEUoeGVuX3Vsb25nX3QpIGlkeHM7Cj4gPiA+ICsK
PiA+ID4gKyAgICAvKiBHUEZOIGluIGRvbWlkIHdoZXJlIHRoZSBzb3VyY2UgbWFwcGluZyBwYWdl
IHNob3VsZCBhcHBlYXIuCj4gPiA+ICovCj4gPiA+ICsgICAgR1VFU1RfSEFORExFKHhlbl9wZm5f
dCkgZ3BmbnM7Cj4gPiAKPiA+IAo+ID4gTG9va2luZyBhdCB5b3VyIGFybSBpbXBsZW1lbnRhdGlv
biBpbiB4ZW4sIGRvZXNuJ3QgbG9vayBsaWtlIHlvdSBhcmUKPiA+IGV4cGVjdGluZyBpZHhzIGFu
ZCBncGZucyB0byBiZSBjb250aWdvdXMuIEluIHRoYXQgY2FzZSwgc2hvdWxkbid0IGlkeHMKPiA+
IGFuZCBncGZucyBiZSBwb2ludGVycywgaWUsIHRoZXkgYXJlIHNlbnQgZG93biBhcyBhcnJheXM/
IE9yIGRvZXMKPiA+IEdVRVNUX0hBTkRMRSBkbyB0aGF0LCBJIGNhbid0IHNlZW0gdG8gZmluZCB3
aGVyZSBpdCdzIGRlZmluZWQgcXVpY2tseS4KPiAKPiBOZXZlciBtaW5kLCBJIHNlZSBpdCBnb3Qg
Y29ycmVjdGVkIHRvIFhFTl9HVUVTVF9IQU5ETEUgaW4gc3RhZ2luZyB0cmVlLgoKVGhlIG1hY3Jv
IGlzIGNhbGxlZCBYRU5fR1VFU1RfSEFORExFIGluIFhlbiBhbmQganVzdCBHVUVTVF9IQU5ETEUg
aW4KTGludXguCgo+IFN0aWxsIGRvZXNuJ3QgY29tcGlsZSB0aG86Cj4gCj4gcHVibGljL21lbW9y
eS5oOjI0NjogZXJyb3I6IGV4cGVjdGVkIHNwZWNpZmllci1xdWFsaWZpZXItbGlzdCBiZWZvcmUK
PiDigJhfX2d1ZXN0X2hhbmRsZV94ZW5fdWxvbmdfdOKAmQo+IAo+IEknbGwgZmlndXJlIGl0IG91
dC4KCkxvb2tzIGxpa2UgeW91J3ZlIGdvdCBpdCBhbGwgc29ydGVkPwoKSWFuLgoKCl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5n
IGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRl
dmVsCg==

From xen-devel-bounces@lists.xen.org Thu Oct 25 07:47:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 07:47:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRI9g-0002bT-IF; Thu, 25 Oct 2012 07:47:04 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRI9f-0002bN-9T
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 07:47:03 +0000
Received: from [193.109.254.147:10209] by server-11.bemta-14.messagelabs.com
	id 87/BE-29027-67EE8805; Thu, 25 Oct 2012 07:47:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1351151221!3481030!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU2MTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5450 invoked from network); 25 Oct 2012 07:47:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 07:47:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,646,1344211200"; d="scan'208";a="15374970"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 07:47:01 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 25 Oct 2012 08:47:01 +0100
Message-ID: <1351151219.18035.94.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Mukesh Rathor 
Date: Thu, 25 Oct 2012 08:46:59 +0100
In-Reply-To: <20121024170746.7c89a790@mantra.us.oracle.com>
References: <1351084756.18035.28.camel@zakaz.uk.xensource.com>
	<1351084777-28898-4-git-send-email-ian.campbell@citrix.com>
	<20121024164411.5b000087@mantra.us.oracle.com>
	<20121024170746.7c89a790@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	linux-kernel ,
	Konrad Rzeszutek Wilk ,
	xen-devel 
Subject: Re: [Xen-devel] [PATCH 4/5] xen: arm: implement remap interfaces
 needed for privcmd mappings.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVGh1LCAyMDEyLTEwLTI1IGF0IDAxOjA3ICswMTAwLCBNdWtlc2ggUmF0aG9yIHdyb3RlOgo+
IE9uIFdlZCwgMjQgT2N0IDIwMTIgMTY6NDQ6MTEgLTA3MDAKPiBNdWtlc2ggUmF0aG9yIDxtdWtl
c2gucmF0aG9yQG9yYWNsZS5jb20+IHdyb3RlOgo+IAo+ID4gPiAgCj4gPiA+ICAjaWZuZGVmIEhZ
UEVSVklTT1JfVklSVF9TVEFSVAo+ID4gPiBkaWZmIC0tZ2l0IGEvaW5jbHVkZS94ZW4vaW50ZXJm
YWNlL21lbW9yeS5oCj4gPiA+IGIvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL21lbW9yeS5oIGluZGV4
IGFkMGRmZjUuLjVkZTJiMzYgMTAwNjQ0Cj4gPiA+IC0tLSBhL2luY2x1ZGUveGVuL2ludGVyZmFj
ZS9tZW1vcnkuaAo+ID4gPiArKysgYi9pbmNsdWRlL3hlbi9pbnRlcmZhY2UvbWVtb3J5LmgKPiA+
ID4gQEAgLTE4OCw2ICsxODgsMjQgQEAgREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QoeGVuX2Fk
ZF90b19waHlzbWFwKTsKPiA+ID4gIC8qKiogUkVNT1ZFRCAqKiovCj4gPiA+ICAvKiNkZWZpbmUg
WEVOTUVNX3RyYW5zbGF0ZV9ncGZuX2xpc3QgIDgqLwo+ID4gPiAgCj4gPiA+ICsjZGVmaW5lIFhF
Tk1FTV9hZGRfdG9fcGh5c21hcF9yYW5nZSAyMwo+ID4gPiArc3RydWN0IHhlbl9hZGRfdG9fcGh5
c21hcF9yYW5nZSB7Cj4gPiA+ICsgICAgLyogV2hpY2ggZG9tYWluIHRvIGNoYW5nZSB0aGUgbWFw
cGluZyBmb3IuICovCj4gPiA+ICsgICAgZG9taWRfdCBkb21pZDsKPiA+ID4gKyAgICB1aW50MTZf
dCBzcGFjZTsgLyogPT4gZW51bSBwaHlzX21hcF9zcGFjZSAqLwo+ID4gPiArCj4gPiA+ICsgICAg
LyogTnVtYmVyIG9mIHBhZ2VzIHRvIGdvIHRocm91Z2ggKi8KPiA+ID4gKyAgICB1aW50MTZfdCBz
aXplOwo+ID4gPiArICAgIGRvbWlkX3QgZm9yZWlnbl9kb21pZDsgLyogSUZGIGdtZm5fZm9yZWln
biAqLwo+ID4gPiArCj4gPiA+ICsgICAgLyogSW5kZXhlcyBpbnRvIHNwYWNlIGJlaW5nIG1hcHBl
ZC4gKi8KPiA+ID4gKyAgICBHVUVTVF9IQU5ETEUoeGVuX3Vsb25nX3QpIGlkeHM7Cj4gPiA+ICsK
PiA+ID4gKyAgICAvKiBHUEZOIGluIGRvbWlkIHdoZXJlIHRoZSBzb3VyY2UgbWFwcGluZyBwYWdl
IHNob3VsZCBhcHBlYXIuCj4gPiA+ICovCj4gPiA+ICsgICAgR1VFU1RfSEFORExFKHhlbl9wZm5f
dCkgZ3BmbnM7Cj4gPiAKPiA+IAo+ID4gTG9va2luZyBhdCB5b3VyIGFybSBpbXBsZW1lbnRhdGlv
biBpbiB4ZW4sIGRvZXNuJ3QgbG9vayBsaWtlIHlvdSBhcmUKPiA+IGV4cGVjdGluZyBpZHhzIGFu
ZCBncGZucyB0byBiZSBjb250aWdvdXMuIEluIHRoYXQgY2FzZSwgc2hvdWxkbid0IGlkeHMKPiA+
IGFuZCBncGZucyBiZSBwb2ludGVycywgaWUsIHRoZXkgYXJlIHNlbnQgZG93biBhcyBhcnJheXM/
IE9yIGRvZXMKPiA+IEdVRVNUX0hBTkRMRSBkbyB0aGF0LCBJIGNhbid0IHNlZW0gdG8gZmluZCB3
aGVyZSBpdCdzIGRlZmluZWQgcXVpY2tseS4KPiAKPiBOZXZlciBtaW5kLCBJIHNlZSBpdCBnb3Qg
Y29ycmVjdGVkIHRvIFhFTl9HVUVTVF9IQU5ETEUgaW4gc3RhZ2luZyB0cmVlLgoKVGhlIG1hY3Jv
IGlzIGNhbGxlZCBYRU5fR1VFU1RfSEFORExFIGluIFhlbiBhbmQganVzdCBHVUVTVF9IQU5ETEUg
aW4KTGludXguCgo+IFN0aWxsIGRvZXNuJ3QgY29tcGlsZSB0aG86Cj4gCj4gcHVibGljL21lbW9y
eS5oOjI0NjogZXJyb3I6IGV4cGVjdGVkIHNwZWNpZmllci1xdWFsaWZpZXItbGlzdCBiZWZvcmUK
PiDigJhfX2d1ZXN0X2hhbmRsZV94ZW5fdWxvbmdfdOKAmQo+IAo+IEknbGwgZmlndXJlIGl0IG91
dC4KCkxvb2tzIGxpa2UgeW91J3ZlIGdvdCBpdCBhbGwgc29ydGVkPwoKSWFuLgoKCl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5n
IGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRl
dmVsCg==

From xen-devel-bounces@lists.xen.org Thu Oct 25 07:51:38 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 07:51:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRIDf-0002kN-8G; Thu, 25 Oct 2012 07:51:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRIDe-0002kD-BC
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 07:51:10 +0000
Received: from [85.158.137.99:5787] by server-9.bemta-3.messagelabs.com id
	44/4E-16841-D6FE8805; Thu, 25 Oct 2012 07:51:09 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-217.messagelabs.com!1351151468!12309162!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NjkxNzU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NjkxNzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18171 invoked from network); 25 Oct 2012 07:51:09 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-6.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Oct 2012 07:51:09 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll387qFkE=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-086-014.pools.arcor-ip.net [84.57.86.14])
	by smtp.strato.de (josoe mo33) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id c0340eo9P60eA2 ;
	Thu, 25 Oct 2012 09:51:08 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 12A7F18642; Thu, 25 Oct 2012 09:51:06 +0200 (CEST)
Date: Thu, 25 Oct 2012 09:51:06 +0200
From: Olaf Hering 
To: Keir Fraser 
Message-ID: <20121025075106.GA16484@aepfle.de>
References: <6a0c73ae9ce5cca72f78.1351101425@probook.site>
	
	<20121025074223.GA15400@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20121025074223.GA15400@aepfle.de>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools/hvmloader: move shared_info to
 reserved memory area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Oct 25, Olaf Hering wrote:

> On Wed, Oct 24, Keir Fraser wrote:
> 
> > Which can be as simple as the attached patch (in fact all the changes apart
> > from introducing GUEST_RESERVED_{START,END} are really cleaning up and
> > bug-fixing the out-of-space checks in the mem_hole_alloc/mem_alloc
> > functions).
> > 
> > This then just requires that the guest maps shared-info to FE700000 itself.
> > Should be quite easy. :)
> 
> The patch works for me. And the kernel patch I sent yesterday works as
> well.
> Is the memory area starting from 0xFC000000 also reserved in older
> versions, such as Xen3?

And if the guest runs on an older tool stack, is there a slim chance
that something allocated memory up to 0xFE700000?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 07:51:38 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 07:51:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRIDf-0002kN-8G; Thu, 25 Oct 2012 07:51:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRIDe-0002kD-BC
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 07:51:10 +0000
Received: from [85.158.137.99:5787] by server-9.bemta-3.messagelabs.com id
	44/4E-16841-D6FE8805; Thu, 25 Oct 2012 07:51:09 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-217.messagelabs.com!1351151468!12309162!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NjkxNzU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NjkxNzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18171 invoked from network); 25 Oct 2012 07:51:09 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-6.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Oct 2012 07:51:09 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll387qFkE=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-086-014.pools.arcor-ip.net [84.57.86.14])
	by smtp.strato.de (josoe mo33) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id c0340eo9P60eA2 ;
	Thu, 25 Oct 2012 09:51:08 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 12A7F18642; Thu, 25 Oct 2012 09:51:06 +0200 (CEST)
Date: Thu, 25 Oct 2012 09:51:06 +0200
From: Olaf Hering 
To: Keir Fraser 
Message-ID: <20121025075106.GA16484@aepfle.de>
References: <6a0c73ae9ce5cca72f78.1351101425@probook.site>
	
	<20121025074223.GA15400@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20121025074223.GA15400@aepfle.de>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools/hvmloader: move shared_info to
 reserved memory area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Oct 25, Olaf Hering wrote:

> On Wed, Oct 24, Keir Fraser wrote:
> 
> > Which can be as simple as the attached patch (in fact all the changes apart
> > from introducing GUEST_RESERVED_{START,END} are really cleaning up and
> > bug-fixing the out-of-space checks in the mem_hole_alloc/mem_alloc
> > functions).
> > 
> > This then just requires that the guest maps shared-info to FE700000 itself.
> > Should be quite easy. :)
> 
> The patch works for me. And the kernel patch I sent yesterday works as
> well.
> Is the memory area starting from 0xFC000000 also reserved in older
> versions, such as Xen3?

And if the guest runs on an older tool stack, is there a slim chance
that something allocated memory up to 0xFE700000?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 08:19:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 08:19:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRIe8-0003R8-QY; Thu, 25 Oct 2012 08:18:32 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRIe7-0003R3-7l
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 08:18:31 +0000
Received: from [193.109.254.147:8986] by server-12.bemta-14.messagelabs.com id
	34/CF-00510-6D5F8805; Thu, 25 Oct 2012 08:18:30 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1351153104!11088307!1
X-Originating-IP: [216.32.180.187]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20452 invoked from network); 25 Oct 2012 08:18:26 -0000
Received: from co1ehsobe004.messaging.microsoft.com (HELO
	co1outboundpool.messaging.microsoft.com) (216.32.180.187)
	by server-4.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Oct 2012 08:18:26 -0000
Received: from mail206-co1-R.bigfish.com (10.243.78.233) by
	CO1EHSOBE001.bigfish.com (10.243.66.64) with Microsoft SMTP Server id
	14.1.225.23; Thu, 25 Oct 2012 08:18:24 +0000
Received: from mail206-co1 (localhost [127.0.0.1])	by
	mail206-co1-R.bigfish.com (Postfix) with ESMTP id CD4DC7400B5;
	Thu, 25 Oct 2012 08:18:23 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: -3
X-BigFish: VPS-3(zzbb2dI98dI1432Izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h)
Received: from mail206-co1 (localhost.localdomain [127.0.0.1]) by mail206-co1
	(MessageSwitch) id 1351153102567496_26317;
	Thu, 25 Oct 2012 08:18:22 +0000 (UTC)
Received: from CO1EHSMHS020.bigfish.com (unknown [10.243.78.241])	by
	mail206-co1.bigfish.com (Postfix) with ESMTP id 889D6600043;
	Thu, 25 Oct 2012 08:18:22 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CO1EHSMHS020.bigfish.com (10.243.66.30) with Microsoft SMTP Server id
	14.1.225.23; Thu, 25 Oct 2012 08:18:22 +0000
X-WSS-ID: 0MCFWEI-02-1EF-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2E715FCC017;	Thu, 25 Oct 2012 03:18:17 -0500 (CDT)
Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 25 Oct 2012 03:18:25 -0500
Received: from STOREXDAG02.amd.com (10.1.13.11) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Thu, 25 Oct 2012 03:18:10 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag02.amd.com
	(10.1.13.11) with Microsoft SMTP Server id 14.2.318.4; Thu, 25 Oct 2012
	04:18:08 -0400
Message-ID: <5088F5BF.2090603@amd.com>
Date: Thu, 25 Oct 2012 10:18:07 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich 
References: <50782D4B.50607@amd.com>
	<5087F8B902000078000A3F38@nat28.tlf.novell.com>
In-Reply-To: <5087F8B902000078000A3F38@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] x86/MCE: Implement clearbank callback for
 AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/24/12 14:18, Jan Beulich wrote:
>>>> On 12.10.12 at 16:46, Christoph Egger  wrote:
>> +static int k8_need_clearbank_scan(enum mca_source who, uint64_t status)
>> +{
>> +	switch (who) {
>> +	case MCA_MCE_SCAN:
>> +	case MCA_MCE_HANDLER:
>> +		break;
>> +	default:
>> +		return 1;
>> +	}
>> +
>> +	/* For fatal error, it shouldn't be cleared so that sticky bank
>> +	 * have chance to be handled after reboot by polling.
>> +	 */
>> +	if ( (status & MCi_STATUS_UC) && (status & MCi_STATUS_PCC) )
>> +		return 0;
>> +	/* Spurious need clear bank */
>> +	if ( !(status & MCi_STATUS_OVER)
>> +	    && (status & MCi_STATUS_UC) && !(status & MCi_STATUS_EN))
>> +		return 1;
>> +
>> +	return 1;
>> }
> 
> So what's the purpose of first conditionally returning 1, and then
> also doing so unconditionally? Do anticipate to insert code between
> the two parts within the very near future? Otherwise I'd drop the
> whole if() construct.

This function is derived from  intel_need_clearbank_scan().
I just took over the relevant parts for AMD.

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 08:19:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 08:19:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRIe8-0003R8-QY; Thu, 25 Oct 2012 08:18:32 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRIe7-0003R3-7l
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 08:18:31 +0000
Received: from [193.109.254.147:8986] by server-12.bemta-14.messagelabs.com id
	34/CF-00510-6D5F8805; Thu, 25 Oct 2012 08:18:30 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1351153104!11088307!1
X-Originating-IP: [216.32.180.187]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20452 invoked from network); 25 Oct 2012 08:18:26 -0000
Received: from co1ehsobe004.messaging.microsoft.com (HELO
	co1outboundpool.messaging.microsoft.com) (216.32.180.187)
	by server-4.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Oct 2012 08:18:26 -0000
Received: from mail206-co1-R.bigfish.com (10.243.78.233) by
	CO1EHSOBE001.bigfish.com (10.243.66.64) with Microsoft SMTP Server id
	14.1.225.23; Thu, 25 Oct 2012 08:18:24 +0000
Received: from mail206-co1 (localhost [127.0.0.1])	by
	mail206-co1-R.bigfish.com (Postfix) with ESMTP id CD4DC7400B5;
	Thu, 25 Oct 2012 08:18:23 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: -3
X-BigFish: VPS-3(zzbb2dI98dI1432Izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h)
Received: from mail206-co1 (localhost.localdomain [127.0.0.1]) by mail206-co1
	(MessageSwitch) id 1351153102567496_26317;
	Thu, 25 Oct 2012 08:18:22 +0000 (UTC)
Received: from CO1EHSMHS020.bigfish.com (unknown [10.243.78.241])	by
	mail206-co1.bigfish.com (Postfix) with ESMTP id 889D6600043;
	Thu, 25 Oct 2012 08:18:22 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CO1EHSMHS020.bigfish.com (10.243.66.30) with Microsoft SMTP Server id
	14.1.225.23; Thu, 25 Oct 2012 08:18:22 +0000
X-WSS-ID: 0MCFWEI-02-1EF-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2E715FCC017;	Thu, 25 Oct 2012 03:18:17 -0500 (CDT)
Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 25 Oct 2012 03:18:25 -0500
Received: from STOREXDAG02.amd.com (10.1.13.11) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Thu, 25 Oct 2012 03:18:10 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag02.amd.com
	(10.1.13.11) with Microsoft SMTP Server id 14.2.318.4; Thu, 25 Oct 2012
	04:18:08 -0400
Message-ID: <5088F5BF.2090603@amd.com>
Date: Thu, 25 Oct 2012 10:18:07 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich 
References: <50782D4B.50607@amd.com>
	<5087F8B902000078000A3F38@nat28.tlf.novell.com>
In-Reply-To: <5087F8B902000078000A3F38@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] x86/MCE: Implement clearbank callback for
 AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/24/12 14:18, Jan Beulich wrote:
>>>> On 12.10.12 at 16:46, Christoph Egger  wrote:
>> +static int k8_need_clearbank_scan(enum mca_source who, uint64_t status)
>> +{
>> +	switch (who) {
>> +	case MCA_MCE_SCAN:
>> +	case MCA_MCE_HANDLER:
>> +		break;
>> +	default:
>> +		return 1;
>> +	}
>> +
>> +	/* For fatal error, it shouldn't be cleared so that sticky bank
>> +	 * have chance to be handled after reboot by polling.
>> +	 */
>> +	if ( (status & MCi_STATUS_UC) && (status & MCi_STATUS_PCC) )
>> +		return 0;
>> +	/* Spurious need clear bank */
>> +	if ( !(status & MCi_STATUS_OVER)
>> +	    && (status & MCi_STATUS_UC) && !(status & MCi_STATUS_EN))
>> +		return 1;
>> +
>> +	return 1;
>> }
> 
> So what's the purpose of first conditionally returning 1, and then
> also doing so unconditionally? Do anticipate to insert code between
> the two parts within the very near future? Otherwise I'd drop the
> whole if() construct.

This function is derived from  intel_need_clearbank_scan().
I just took over the relevant parts for AMD.

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 08:55:35 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 08:55:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRJDb-00041z-PQ; Thu, 25 Oct 2012 08:55:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRJDb-00041r-1r
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 08:55:11 +0000
Received: from [85.158.139.83:39079] by server-1.bemta-5.messagelabs.com id
	4C/90-21640-E6EF8805; Thu, 25 Oct 2012 08:55:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1351155309!24674467!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMjA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25268 invoked from network); 25 Oct 2012 08:55:09 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-182.messagelabs.com with SMTP;
	25 Oct 2012 08:55:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 25 Oct 2012 09:55:09 +0100
Message-Id: <50891A8B02000078000A45C5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 25 Oct 2012 09:55:07 +0100
From: "Jan Beulich" 
To: "Christoph Egger" 
References: <50782D4B.50607@amd.com>
	<5087F8B902000078000A3F38@nat28.tlf.novell.com>
	<5088F5BF.2090603@amd.com>
In-Reply-To: <5088F5BF.2090603@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] x86/MCE: Implement clearbank callback for
 AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 25.10.12 at 10:18, Christoph Egger  wrote:
> On 10/24/12 14:18, Jan Beulich wrote:
>>>>> On 12.10.12 at 16:46, Christoph Egger  wrote:
>>> +static int k8_need_clearbank_scan(enum mca_source who, uint64_t status)
>>> +{
>>> +	switch (who) {
>>> +	case MCA_MCE_SCAN:
>>> +	case MCA_MCE_HANDLER:
>>> +		break;
>>> +	default:
>>> +		return 1;
>>> +	}
>>> +
>>> +	/* For fatal error, it shouldn't be cleared so that sticky bank
>>> +	 * have chance to be handled after reboot by polling.
>>> +	 */
>>> +	if ( (status & MCi_STATUS_UC) && (status & MCi_STATUS_PCC) )
>>> +		return 0;
>>> +	/* Spurious need clear bank */
>>> +	if ( !(status & MCi_STATUS_OVER)
>>> +	    && (status & MCi_STATUS_UC) && !(status & MCi_STATUS_EN))
>>> +		return 1;
>>> +
>>> +	return 1;
>>> }
>> 
>> So what's the purpose of first conditionally returning 1, and then
>> also doing so unconditionally? Do anticipate to insert code between
>> the two parts within the very near future? Otherwise I'd drop the
>> whole if() construct.
> 
> This function is derived from  intel_need_clearbank_scan().
> I just took over the relevant parts for AMD.

But that would suggest that the final return be "return 0" rather
than "return 1".

Further, the Intel code does no extra checking for the
MCA_MCE_HANDLER case, so I'd like you to confirm that this is
indeed to be different for your CPUs.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 08:55:35 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 08:55:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRJDb-00041z-PQ; Thu, 25 Oct 2012 08:55:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRJDb-00041r-1r
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 08:55:11 +0000
Received: from [85.158.139.83:39079] by server-1.bemta-5.messagelabs.com id
	4C/90-21640-E6EF8805; Thu, 25 Oct 2012 08:55:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1351155309!24674467!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMjA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25268 invoked from network); 25 Oct 2012 08:55:09 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-182.messagelabs.com with SMTP;
	25 Oct 2012 08:55:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 25 Oct 2012 09:55:09 +0100
Message-Id: <50891A8B02000078000A45C5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 25 Oct 2012 09:55:07 +0100
From: "Jan Beulich" 
To: "Christoph Egger" 
References: <50782D4B.50607@amd.com>
	<5087F8B902000078000A3F38@nat28.tlf.novell.com>
	<5088F5BF.2090603@amd.com>
In-Reply-To: <5088F5BF.2090603@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] x86/MCE: Implement clearbank callback for
 AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 25.10.12 at 10:18, Christoph Egger  wrote:
> On 10/24/12 14:18, Jan Beulich wrote:
>>>>> On 12.10.12 at 16:46, Christoph Egger  wrote:
>>> +static int k8_need_clearbank_scan(enum mca_source who, uint64_t status)
>>> +{
>>> +	switch (who) {
>>> +	case MCA_MCE_SCAN:
>>> +	case MCA_MCE_HANDLER:
>>> +		break;
>>> +	default:
>>> +		return 1;
>>> +	}
>>> +
>>> +	/* For fatal error, it shouldn't be cleared so that sticky bank
>>> +	 * have chance to be handled after reboot by polling.
>>> +	 */
>>> +	if ( (status & MCi_STATUS_UC) && (status & MCi_STATUS_PCC) )
>>> +		return 0;
>>> +	/* Spurious need clear bank */
>>> +	if ( !(status & MCi_STATUS_OVER)
>>> +	    && (status & MCi_STATUS_UC) && !(status & MCi_STATUS_EN))
>>> +		return 1;
>>> +
>>> +	return 1;
>>> }
>> 
>> So what's the purpose of first conditionally returning 1, and then
>> also doing so unconditionally? Do anticipate to insert code between
>> the two parts within the very near future? Otherwise I'd drop the
>> whole if() construct.
> 
> This function is derived from  intel_need_clearbank_scan().
> I just took over the relevant parts for AMD.

But that would suggest that the final return be "return 0" rather
than "return 1".

Further, the Intel code does no extra checking for the
MCA_MCE_HANDLER case, so I'd like you to confirm that this is
indeed to be different for your CPUs.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 09:01:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 09:01:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRJIv-0004Cf-M5; Thu, 25 Oct 2012 09:00:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRJIt-0004CX-ST
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 09:00:39 +0000
Received: from [85.158.143.35:36291] by server-3.bemta-4.messagelabs.com id
	68/41-24279-7BFF8805; Thu, 25 Oct 2012 09:00:39 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-21.messagelabs.com!1351155636!15730117!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDUxMTY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDUxMTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2673 invoked from network); 25 Oct 2012 09:00:37 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Oct 2012 09:00:37 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll387qFkE=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-086-014.pools.arcor-ip.net [84.57.86.14])
	by smtp.strato.de (jored mo50) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id z01024o9P8jera ;
	Thu, 25 Oct 2012 11:00:29 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 1BEA418642; Thu, 25 Oct 2012 11:00:27 +0200 (CEST)
From: Olaf Hering 
To: Jeremy Fitzhardinge ,
	Konrad Rzeszutek Wilk 
Date: Thu, 25 Oct 2012 11:00:24 +0200
Message-Id: <1351155624-25512-1-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 1.7.12.4
Cc: Olaf Hering , xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Subject: [Xen-devel] [PATCH] x86: remove obsolete comment from
	asm/xen/hypervisor.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Olaf Hering 
---
 arch/x86/include/asm/xen/hypervisor.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/x86/include/asm/xen/hypervisor.h b/arch/x86/include/asm/xen/hypervisor.h
index 66d0fff..125f344 100644
--- a/arch/x86/include/asm/xen/hypervisor.h
+++ b/arch/x86/include/asm/xen/hypervisor.h
@@ -33,7 +33,6 @@
 #ifndef _ASM_X86_XEN_HYPERVISOR_H
 #define _ASM_X86_XEN_HYPERVISOR_H
 
-/* arch/i386/kernel/setup.c */
 extern struct shared_info *HYPERVISOR_shared_info;
 extern struct start_info *xen_start_info;
 
-- 
1.7.12.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 09:01:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 09:01:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRJIv-0004Cf-M5; Thu, 25 Oct 2012 09:00:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRJIt-0004CX-ST
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 09:00:39 +0000
Received: from [85.158.143.35:36291] by server-3.bemta-4.messagelabs.com id
	68/41-24279-7BFF8805; Thu, 25 Oct 2012 09:00:39 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-21.messagelabs.com!1351155636!15730117!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDUxMTY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDUxMTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2673 invoked from network); 25 Oct 2012 09:00:37 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Oct 2012 09:00:37 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll387qFkE=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-086-014.pools.arcor-ip.net [84.57.86.14])
	by smtp.strato.de (jored mo50) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id z01024o9P8jera ;
	Thu, 25 Oct 2012 11:00:29 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 1BEA418642; Thu, 25 Oct 2012 11:00:27 +0200 (CEST)
From: Olaf Hering 
To: Jeremy Fitzhardinge ,
	Konrad Rzeszutek Wilk 
Date: Thu, 25 Oct 2012 11:00:24 +0200
Message-Id: <1351155624-25512-1-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 1.7.12.4
Cc: Olaf Hering , xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Subject: [Xen-devel] [PATCH] x86: remove obsolete comment from
	asm/xen/hypervisor.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Olaf Hering 
---
 arch/x86/include/asm/xen/hypervisor.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/x86/include/asm/xen/hypervisor.h b/arch/x86/include/asm/xen/hypervisor.h
index 66d0fff..125f344 100644
--- a/arch/x86/include/asm/xen/hypervisor.h
+++ b/arch/x86/include/asm/xen/hypervisor.h
@@ -33,7 +33,6 @@
 #ifndef _ASM_X86_XEN_HYPERVISOR_H
 #define _ASM_X86_XEN_HYPERVISOR_H
 
-/* arch/i386/kernel/setup.c */
 extern struct shared_info *HYPERVISOR_shared_info;
 extern struct start_info *xen_start_info;
 
-- 
1.7.12.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 09:05:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 09:05:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRJMv-0004MU-As; Thu, 25 Oct 2012 09:04:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRJMt-0004MM-HD
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 09:04:47 +0000
Received: from [85.158.139.83:31699] by server-11.bemta-5.messagelabs.com id
	6A/DF-14870-EA009805; Thu, 25 Oct 2012 09:04:46 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-182.messagelabs.com!1351155885!30800800!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NjkxNzU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NjkxNzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11892 invoked from network); 25 Oct 2012 09:04:46 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Oct 2012 09:04:46 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll387qFkE=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-086-014.pools.arcor-ip.net [84.57.86.14])
	by smtp.strato.de (jored mo11) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 0004f0o9P8FfQI ;
	Thu, 25 Oct 2012 11:04:40 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id E4C2318642; Thu, 25 Oct 2012 11:04:38 +0200 (CEST)
From: Olaf Hering 
To: Jeremy Fitzhardinge ,
	Konrad Rzeszutek Wilk 
Date: Thu, 25 Oct 2012 11:04:33 +0200
Message-Id: <1351155873-26500-1-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 1.7.12.4
Cc: Olaf Hering , xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Subject: [Xen-devel] [PATCH] xen PVonHVM: move shared_info to reserved
	memory area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a respin of 00e37bdb0113a98408de42db85be002f21dbffd3
("xen PVonHVM: move shared_info to MMIO before kexec").

Currently kexec in a PVonHVM guest fails with a triple fault because the
new kernel overwrites the shared info page. The exact failure depends on
the size of the kernel image. This patch moves the pfn from RAM into an
E820 reserved memory area.

The pfn containing the shared_info is located somewhere in RAM. This will
cause trouble if the current kernel is doing a kexec boot into a new
kernel. The new kernel (and its startup code) can not know where the pfn
is, so it can not reserve the page. The hypervisor will continue to update
the pfn, and as a result memory corruption occours in the new kernel.

The toolstack marks the memory area FC000000-FFFFFFFF as reserved in the
E820 map. Within that range newer toolstacks will keep 1MB starting from
FE700000 as reserved for guest use. Older toolstacks will usually not
allocate areas up to FE700000, so FE700000 is expected to work also with
older toolstacks.

Signed-off-by: Olaf Hering 
---
 arch/x86/xen/enlighten.c | 46 ++++++++++++++++++++++++++++++----------------
 arch/x86/xen/suspend.c   |  2 +-
 arch/x86/xen/xen-ops.h   |  2 +-
 3 files changed, 32 insertions(+), 18 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 586d838..11a7b8b 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -101,7 +101,6 @@ struct shared_info xen_dummy_shared_info;
 
 void *xen_initial_gdt;
 
-RESERVE_BRK(shared_info_page_brk, PAGE_SIZE);
 __read_mostly int xen_have_vector_callback;
 EXPORT_SYMBOL_GPL(xen_have_vector_callback);
 
@@ -1495,38 +1494,53 @@ asmlinkage void __init xen_start_kernel(void)
 #endif
 }
 
-void __ref xen_hvm_init_shared_info(void)
+#ifdef CONFIG_XEN_PVHVM
+#define HVM_SHARED_INFO_ADDR 0xFE700000UL
+static struct shared_info *xen_hvm_shared_info;
+
+static void xen_hvm_connect_shared_info(unsigned long pfn)
 {
-	int cpu;
 	struct xen_add_to_physmap xatp;
-	static struct shared_info *shared_info_page = 0;
 
-	if (!shared_info_page)
-		shared_info_page = (struct shared_info *)
-			extend_brk(PAGE_SIZE, PAGE_SIZE);
 	xatp.domid = DOMID_SELF;
 	xatp.idx = 0;
 	xatp.space = XENMAPSPACE_shared_info;
-	xatp.gpfn = __pa(shared_info_page) >> PAGE_SHIFT;
+	xatp.gpfn = pfn;
 	if (HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp))
 		BUG();
 
-	HYPERVISOR_shared_info = (struct shared_info *)shared_info_page;
+}
+static void xen_hvm_set_shared_info(struct shared_info *sip)
+{
+	int cpu;
+
+	HYPERVISOR_shared_info = sip;
 
 	/* xen_vcpu is a pointer to the vcpu_info struct in the shared_info
 	 * page, we use it in the event channel upcall and in some pvclock
 	 * related functions. We don't need the vcpu_info placement
 	 * optimizations because we don't use any pv_mmu or pv_irq op on
-	 * HVM.
-	 * When xen_hvm_init_shared_info is run at boot time only vcpu 0 is
-	 * online but xen_hvm_init_shared_info is run at resume time too and
-	 * in that case multiple vcpus might be online. */
-	for_each_online_cpu(cpu) {
+	 * HVM. */
+	for_each_online_cpu(cpu)
 		per_cpu(xen_vcpu, cpu) = &HYPERVISOR_shared_info->vcpu_info[cpu];
-	}
 }
 
-#ifdef CONFIG_XEN_PVHVM
+/* Reconnect the shared_info pfn to a (new) mfn */
+void xen_hvm_resume_shared_info(void)
+{
+	xen_hvm_connect_shared_info(HVM_SHARED_INFO_ADDR >> PAGE_SHIFT);
+}
+
+/* Obtain an address to the pfn in reserved area */
+void __init xen_hvm_init_shared_info(void)
+{
+	set_fixmap(FIX_PARAVIRT_BOOTMAP, HVM_SHARED_INFO_ADDR);
+	xen_hvm_shared_info =
+		(struct shared_info *)fix_to_virt(FIX_PARAVIRT_BOOTMAP);
+	xen_hvm_connect_shared_info(HVM_SHARED_INFO_ADDR >> PAGE_SHIFT);
+	xen_hvm_set_shared_info(xen_hvm_shared_info);
+}
+
 static void __init init_hvm_pv_info(void)
 {
 	int major, minor;
diff --git a/arch/x86/xen/suspend.c b/arch/x86/xen/suspend.c
index 45329c8..ae8a00c 100644
--- a/arch/x86/xen/suspend.c
+++ b/arch/x86/xen/suspend.c
@@ -30,7 +30,7 @@ void xen_arch_hvm_post_suspend(int suspend_cancelled)
 {
 #ifdef CONFIG_XEN_PVHVM
 	int cpu;
-	xen_hvm_init_shared_info();
+	xen_hvm_resume_shared_info();
 	xen_callback_vector();
 	xen_unplug_emulated_devices();
 	if (xen_feature(XENFEAT_hvm_safe_pvclock)) {
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index a95b417..d2e73d1 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -40,7 +40,7 @@ void xen_enable_syscall(void);
 void xen_vcpu_restore(void);
 
 void xen_callback_vector(void);
-void xen_hvm_init_shared_info(void);
+void xen_hvm_resume_shared_info(void);
 void xen_unplug_emulated_devices(void);
 
 void __init xen_build_dynamic_phys_to_machine(void);
-- 
1.7.12.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 09:05:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 09:05:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRJMv-0004MU-As; Thu, 25 Oct 2012 09:04:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRJMt-0004MM-HD
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 09:04:47 +0000
Received: from [85.158.139.83:31699] by server-11.bemta-5.messagelabs.com id
	6A/DF-14870-EA009805; Thu, 25 Oct 2012 09:04:46 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-182.messagelabs.com!1351155885!30800800!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NjkxNzU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NjkxNzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11892 invoked from network); 25 Oct 2012 09:04:46 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Oct 2012 09:04:46 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll387qFkE=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-086-014.pools.arcor-ip.net [84.57.86.14])
	by smtp.strato.de (jored mo11) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 0004f0o9P8FfQI ;
	Thu, 25 Oct 2012 11:04:40 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id E4C2318642; Thu, 25 Oct 2012 11:04:38 +0200 (CEST)
From: Olaf Hering 
To: Jeremy Fitzhardinge ,
	Konrad Rzeszutek Wilk 
Date: Thu, 25 Oct 2012 11:04:33 +0200
Message-Id: <1351155873-26500-1-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 1.7.12.4
Cc: Olaf Hering , xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Subject: [Xen-devel] [PATCH] xen PVonHVM: move shared_info to reserved
	memory area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a respin of 00e37bdb0113a98408de42db85be002f21dbffd3
("xen PVonHVM: move shared_info to MMIO before kexec").

Currently kexec in a PVonHVM guest fails with a triple fault because the
new kernel overwrites the shared info page. The exact failure depends on
the size of the kernel image. This patch moves the pfn from RAM into an
E820 reserved memory area.

The pfn containing the shared_info is located somewhere in RAM. This will
cause trouble if the current kernel is doing a kexec boot into a new
kernel. The new kernel (and its startup code) can not know where the pfn
is, so it can not reserve the page. The hypervisor will continue to update
the pfn, and as a result memory corruption occours in the new kernel.

The toolstack marks the memory area FC000000-FFFFFFFF as reserved in the
E820 map. Within that range newer toolstacks will keep 1MB starting from
FE700000 as reserved for guest use. Older toolstacks will usually not
allocate areas up to FE700000, so FE700000 is expected to work also with
older toolstacks.

Signed-off-by: Olaf Hering 
---
 arch/x86/xen/enlighten.c | 46 ++++++++++++++++++++++++++++++----------------
 arch/x86/xen/suspend.c   |  2 +-
 arch/x86/xen/xen-ops.h   |  2 +-
 3 files changed, 32 insertions(+), 18 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 586d838..11a7b8b 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -101,7 +101,6 @@ struct shared_info xen_dummy_shared_info;
 
 void *xen_initial_gdt;
 
-RESERVE_BRK(shared_info_page_brk, PAGE_SIZE);
 __read_mostly int xen_have_vector_callback;
 EXPORT_SYMBOL_GPL(xen_have_vector_callback);
 
@@ -1495,38 +1494,53 @@ asmlinkage void __init xen_start_kernel(void)
 #endif
 }
 
-void __ref xen_hvm_init_shared_info(void)
+#ifdef CONFIG_XEN_PVHVM
+#define HVM_SHARED_INFO_ADDR 0xFE700000UL
+static struct shared_info *xen_hvm_shared_info;
+
+static void xen_hvm_connect_shared_info(unsigned long pfn)
 {
-	int cpu;
 	struct xen_add_to_physmap xatp;
-	static struct shared_info *shared_info_page = 0;
 
-	if (!shared_info_page)
-		shared_info_page = (struct shared_info *)
-			extend_brk(PAGE_SIZE, PAGE_SIZE);
 	xatp.domid = DOMID_SELF;
 	xatp.idx = 0;
 	xatp.space = XENMAPSPACE_shared_info;
-	xatp.gpfn = __pa(shared_info_page) >> PAGE_SHIFT;
+	xatp.gpfn = pfn;
 	if (HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp))
 		BUG();
 
-	HYPERVISOR_shared_info = (struct shared_info *)shared_info_page;
+}
+static void xen_hvm_set_shared_info(struct shared_info *sip)
+{
+	int cpu;
+
+	HYPERVISOR_shared_info = sip;
 
 	/* xen_vcpu is a pointer to the vcpu_info struct in the shared_info
 	 * page, we use it in the event channel upcall and in some pvclock
 	 * related functions. We don't need the vcpu_info placement
 	 * optimizations because we don't use any pv_mmu or pv_irq op on
-	 * HVM.
-	 * When xen_hvm_init_shared_info is run at boot time only vcpu 0 is
-	 * online but xen_hvm_init_shared_info is run at resume time too and
-	 * in that case multiple vcpus might be online. */
-	for_each_online_cpu(cpu) {
+	 * HVM. */
+	for_each_online_cpu(cpu)
 		per_cpu(xen_vcpu, cpu) = &HYPERVISOR_shared_info->vcpu_info[cpu];
-	}
 }
 
-#ifdef CONFIG_XEN_PVHVM
+/* Reconnect the shared_info pfn to a (new) mfn */
+void xen_hvm_resume_shared_info(void)
+{
+	xen_hvm_connect_shared_info(HVM_SHARED_INFO_ADDR >> PAGE_SHIFT);
+}
+
+/* Obtain an address to the pfn in reserved area */
+void __init xen_hvm_init_shared_info(void)
+{
+	set_fixmap(FIX_PARAVIRT_BOOTMAP, HVM_SHARED_INFO_ADDR);
+	xen_hvm_shared_info =
+		(struct shared_info *)fix_to_virt(FIX_PARAVIRT_BOOTMAP);
+	xen_hvm_connect_shared_info(HVM_SHARED_INFO_ADDR >> PAGE_SHIFT);
+	xen_hvm_set_shared_info(xen_hvm_shared_info);
+}
+
 static void __init init_hvm_pv_info(void)
 {
 	int major, minor;
diff --git a/arch/x86/xen/suspend.c b/arch/x86/xen/suspend.c
index 45329c8..ae8a00c 100644
--- a/arch/x86/xen/suspend.c
+++ b/arch/x86/xen/suspend.c
@@ -30,7 +30,7 @@ void xen_arch_hvm_post_suspend(int suspend_cancelled)
 {
 #ifdef CONFIG_XEN_PVHVM
 	int cpu;
-	xen_hvm_init_shared_info();
+	xen_hvm_resume_shared_info();
 	xen_callback_vector();
 	xen_unplug_emulated_devices();
 	if (xen_feature(XENFEAT_hvm_safe_pvclock)) {
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index a95b417..d2e73d1 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -40,7 +40,7 @@ void xen_enable_syscall(void);
 void xen_vcpu_restore(void);
 
 void xen_callback_vector(void);
-void xen_hvm_init_shared_info(void);
+void xen_hvm_resume_shared_info(void);
 void xen_unplug_emulated_devices(void);
 
 void __init xen_build_dynamic_phys_to_machine(void);
-- 
1.7.12.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 09:19:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 09:19:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRJau-0004YZ-RH; Thu, 25 Oct 2012 09:19:16 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRJat-0004YU-JU
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 09:19:15 +0000
Received: from [193.109.254.147:42669] by server-12.bemta-14.messagelabs.com
	id EB/54-00510-21409805; Thu, 25 Oct 2012 09:19:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1351156752!14538067!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30238 invoked from network); 25 Oct 2012 09:19:12 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-27.messagelabs.com with SMTP;
	25 Oct 2012 09:19:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 25 Oct 2012 10:19:11 +0100
Message-Id: <5089202E02000078000A45E7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 25 Oct 2012 10:19:10 +0100
From: "Jan Beulich" 
To: "Olaf Hering" 
References: <1351155873-26500-1-git-send-email-olaf@aepfle.de>
In-Reply-To: <1351155873-26500-1-git-send-email-olaf@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH] xen PVonHVM: move shared_info to reserved
 memory area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 25.10.12 at 11:04, Olaf Hering  wrote:
> @@ -1495,38 +1494,53 @@ asmlinkage void __init xen_start_kernel(void)
>  #endif
>  }
>  
> -void __ref xen_hvm_init_shared_info(void)

Was the __ref here in fact unnecessary (i.e. did you check that
its removal doesn't cause any section mismatch warnings)?

> +#ifdef CONFIG_XEN_PVHVM
> +#define HVM_SHARED_INFO_ADDR 0xFE700000UL
> +static struct shared_info *xen_hvm_shared_info;
> +
> +static void xen_hvm_connect_shared_info(unsigned long pfn)
>  {
> -	int cpu;
>  	struct xen_add_to_physmap xatp;
> -	static struct shared_info *shared_info_page = 0;
>  
> -	if (!shared_info_page)
> -		shared_info_page = (struct shared_info *)
> -			extend_brk(PAGE_SIZE, PAGE_SIZE);
>  	xatp.domid = DOMID_SELF;
>  	xatp.idx = 0;
>  	xatp.space = XENMAPSPACE_shared_info;
> -	xatp.gpfn = __pa(shared_info_page) >> PAGE_SHIFT;
> +	xatp.gpfn = pfn;
>  	if (HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp))
>  		BUG();
>  
> -	HYPERVISOR_shared_info = (struct shared_info *)shared_info_page;
> +}
> +static void xen_hvm_set_shared_info(struct shared_info *sip)

With its sole caller being __init, this should also be __init.

Jan

> +{
> +	int cpu;
> +
> +	HYPERVISOR_shared_info = sip;
>  
>  	/* xen_vcpu is a pointer to the vcpu_info struct in the shared_info
>  	 * page, we use it in the event channel upcall and in some pvclock
>  	 * related functions. We don't need the vcpu_info placement
>  	 * optimizations because we don't use any pv_mmu or pv_irq op on
> -	 * HVM.
> -	 * When xen_hvm_init_shared_info is run at boot time only vcpu 0 is
> -	 * online but xen_hvm_init_shared_info is run at resume time too and
> -	 * in that case multiple vcpus might be online. */
> -	for_each_online_cpu(cpu) {
> +	 * HVM. */
> +	for_each_online_cpu(cpu)
>  		per_cpu(xen_vcpu, cpu) = &HYPERVISOR_shared_info->vcpu_info[cpu];
> -	}
>  }
>  
> -#ifdef CONFIG_XEN_PVHVM
> +/* Reconnect the shared_info pfn to a (new) mfn */
> +void xen_hvm_resume_shared_info(void)
> +{
> +	xen_hvm_connect_shared_info(HVM_SHARED_INFO_ADDR >> PAGE_SHIFT);
> +}
> +
> +/* Obtain an address to the pfn in reserved area */
> +void __init xen_hvm_init_shared_info(void)
> +{
> +	set_fixmap(FIX_PARAVIRT_BOOTMAP, HVM_SHARED_INFO_ADDR);
> +	xen_hvm_shared_info =
> +		(struct shared_info *)fix_to_virt(FIX_PARAVIRT_BOOTMAP);
> +	xen_hvm_connect_shared_info(HVM_SHARED_INFO_ADDR >> PAGE_SHIFT);
> +	xen_hvm_set_shared_info(xen_hvm_shared_info);
> +}
> +
>  static void __init init_hvm_pv_info(void)
>  {
>  	int major, minor;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 09:19:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 09:19:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRJau-0004YZ-RH; Thu, 25 Oct 2012 09:19:16 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRJat-0004YU-JU
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 09:19:15 +0000
Received: from [193.109.254.147:42669] by server-12.bemta-14.messagelabs.com
	id EB/54-00510-21409805; Thu, 25 Oct 2012 09:19:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1351156752!14538067!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30238 invoked from network); 25 Oct 2012 09:19:12 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-27.messagelabs.com with SMTP;
	25 Oct 2012 09:19:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 25 Oct 2012 10:19:11 +0100
Message-Id: <5089202E02000078000A45E7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 25 Oct 2012 10:19:10 +0100
From: "Jan Beulich" 
To: "Olaf Hering" 
References: <1351155873-26500-1-git-send-email-olaf@aepfle.de>
In-Reply-To: <1351155873-26500-1-git-send-email-olaf@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH] xen PVonHVM: move shared_info to reserved
 memory area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 25.10.12 at 11:04, Olaf Hering  wrote:
> @@ -1495,38 +1494,53 @@ asmlinkage void __init xen_start_kernel(void)
>  #endif
>  }
>  
> -void __ref xen_hvm_init_shared_info(void)

Was the __ref here in fact unnecessary (i.e. did you check that
its removal doesn't cause any section mismatch warnings)?

> +#ifdef CONFIG_XEN_PVHVM
> +#define HVM_SHARED_INFO_ADDR 0xFE700000UL
> +static struct shared_info *xen_hvm_shared_info;
> +
> +static void xen_hvm_connect_shared_info(unsigned long pfn)
>  {
> -	int cpu;
>  	struct xen_add_to_physmap xatp;
> -	static struct shared_info *shared_info_page = 0;
>  
> -	if (!shared_info_page)
> -		shared_info_page = (struct shared_info *)
> -			extend_brk(PAGE_SIZE, PAGE_SIZE);
>  	xatp.domid = DOMID_SELF;
>  	xatp.idx = 0;
>  	xatp.space = XENMAPSPACE_shared_info;
> -	xatp.gpfn = __pa(shared_info_page) >> PAGE_SHIFT;
> +	xatp.gpfn = pfn;
>  	if (HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp))
>  		BUG();
>  
> -	HYPERVISOR_shared_info = (struct shared_info *)shared_info_page;
> +}
> +static void xen_hvm_set_shared_info(struct shared_info *sip)

With its sole caller being __init, this should also be __init.

Jan

> +{
> +	int cpu;
> +
> +	HYPERVISOR_shared_info = sip;
>  
>  	/* xen_vcpu is a pointer to the vcpu_info struct in the shared_info
>  	 * page, we use it in the event channel upcall and in some pvclock
>  	 * related functions. We don't need the vcpu_info placement
>  	 * optimizations because we don't use any pv_mmu or pv_irq op on
> -	 * HVM.
> -	 * When xen_hvm_init_shared_info is run at boot time only vcpu 0 is
> -	 * online but xen_hvm_init_shared_info is run at resume time too and
> -	 * in that case multiple vcpus might be online. */
> -	for_each_online_cpu(cpu) {
> +	 * HVM. */
> +	for_each_online_cpu(cpu)
>  		per_cpu(xen_vcpu, cpu) = &HYPERVISOR_shared_info->vcpu_info[cpu];
> -	}
>  }
>  
> -#ifdef CONFIG_XEN_PVHVM
> +/* Reconnect the shared_info pfn to a (new) mfn */
> +void xen_hvm_resume_shared_info(void)
> +{
> +	xen_hvm_connect_shared_info(HVM_SHARED_INFO_ADDR >> PAGE_SHIFT);
> +}
> +
> +/* Obtain an address to the pfn in reserved area */
> +void __init xen_hvm_init_shared_info(void)
> +{
> +	set_fixmap(FIX_PARAVIRT_BOOTMAP, HVM_SHARED_INFO_ADDR);
> +	xen_hvm_shared_info =
> +		(struct shared_info *)fix_to_virt(FIX_PARAVIRT_BOOTMAP);
> +	xen_hvm_connect_shared_info(HVM_SHARED_INFO_ADDR >> PAGE_SHIFT);
> +	xen_hvm_set_shared_info(xen_hvm_shared_info);
> +}
> +
>  static void __init init_hvm_pv_info(void)
>  {
>  	int major, minor;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 09:27:57 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 09:27:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRJiu-0004i1-Sc; Thu, 25 Oct 2012 09:27:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRJis-0004ht-U1
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 09:27:31 +0000
Received: from [85.158.143.99:51654] by server-3.bemta-4.messagelabs.com id
	6F/31-24279-20609805; Thu, 25 Oct 2012 09:27:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1351157249!20280935!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24199 invoked from network); 25 Oct 2012 09:27:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 09:27:29 -0000
X-IronPort-AV: E=Sophos;i="4.80,646,1344211200"; d="scan'208";a="15382360"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 09:27:28 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 25 Oct 2012 10:27:28 +0100
Message-ID: <1351157246.18035.129.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Thu, 25 Oct 2012 10:27:26 +0100
In-Reply-To: <1351091027-20740-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: 
	<1351091027-20740-1-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" , "Tim
	\(Xen.org\)" 
Subject: Re: [Xen-devel] [PATCH 1/7] xen/arm: fix rank calculation in
 vgic_vcpu_inject_irq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 16:03 +0100, Stefano Stabellini wrote:
> Each rank holds 32 irqs, so we should divide by 32 rather than by 4.

I think this is wrong, because idx isn't used in the way your reasoning
implies, when we use it we assume 8 bits-per-interrupt in the register
not 1.

The accessor function vgix_irq_rank is couched in terms of
GICD_, which is convenient where we are emulating register
accesses but is very confusing in this one function where we aren't
thinking in terms of registers!

vgic_irq_rank(v, 8, idx) is saying "find me the rank containing
GICD_ where FOO has 8 bits per interrupt". Since 4 lots of 8
bits goes into 32 we therefore need to divide by 4. This makes sense if
you consider that FOO here is PRIORITY and that GICD_PRIORITY0 controls
irq 0..3, GICD_PRIORITY1 irq 4..7 etc.

With idx = irq >> 2 you get:

IRQ00: idx = 00 REG_RANK_NR(08, 00) = 0, REG_RANK_INDEX(08, 00) = 0, BYTE = 0
IRQ01: idx = 00 REG_RANK_NR(08, 00) = 0, REG_RANK_INDEX(08, 00) = 0, BYTE = 1
IRQ02: idx = 00 REG_RANK_NR(08, 00) = 0, REG_RANK_INDEX(08, 00) = 0, BYTE = 2
IRQ03: idx = 00 REG_RANK_NR(08, 00) = 0, REG_RANK_INDEX(08, 00) = 0, BYTE = 3
IRQ04: idx = 01 REG_RANK_NR(08, 01) = 0, REG_RANK_INDEX(08, 01) = 1, BYTE = 0
IRQ05: idx = 01 REG_RANK_NR(08, 01) = 0, REG_RANK_INDEX(08, 01) = 1, BYTE = 1
[...]
IRQ30: idx = 07 REG_RANK_NR(08, 07) = 0, REG_RANK_INDEX(08, 07) = 7, BYTE = 2
IRQ31: idx = 07 REG_RANK_NR(08, 07) = 0, REG_RANK_INDEX(08, 07) = 7, BYTE = 3
IRQ32: idx = 08 REG_RANK_NR(08, 08) = 1, REG_RANK_INDEX(08, 08) = 0, BYTE = 0
IRQ33: idx = 08 REG_RANK_NR(08, 08) = 1, REG_RANK_INDEX(08, 08) = 0, BYTE = 1
[...]
IRQ62: idx = 15 REG_RANK_NR(08, 15) = 1, REG_RANK_INDEX(08, 15) = 7, BYTE = 2
IRQ63: idx = 15 REG_RANK_NR(08, 15) = 1, REG_RANK_INDEX(08, 15) = 7, BYTE = 3
IRQ64: idx = 16 REG_RANK_NR(08, 16) = 2, REG_RANK_INDEX(08, 16) = 0, BYTE = 0
IRQ65: idx = 16 REG_RANK_NR(08, 16) = 2, REG_RANK_INDEX(08, 16) = 0, BYTE = 1
[...]

IOW interrupts 0..31 are in rank 0, 32..63 are rank 1 etc, which is correct

With idx = irq / 32 you instead get:

IRQ00: idx = 00 REG_RANK_NR(08, 00) = 0, REG_RANK_INDEX(08, 00) = 0, BYTE = 0
IRQ01: idx = 00 REG_RANK_NR(08, 00) = 0, REG_RANK_INDEX(08, 00) = 0, BYTE = 1
IRQ02: idx = 00 REG_RANK_NR(08, 00) = 0, REG_RANK_INDEX(08, 00) = 0, BYTE = 2
IRQ03: idx = 00 REG_RANK_NR(08, 00) = 0, REG_RANK_INDEX(08, 00) = 0, BYTE = 3
IRQ04: idx = 00 REG_RANK_NR(08, 00) = 0, REG_RANK_INDEX(08, 00) = 0, BYTE = 0
IRQ05: idx = 00 REG_RANK_NR(08, 00) = 0, REG_RANK_INDEX(08, 00) = 0, BYTE = 1
[...]
IRQ30: idx = 00 REG_RANK_NR(08, 00) = 0, REG_RANK_INDEX(08, 00) = 0, BYTE = 2
IRQ31: idx = 00 REG_RANK_NR(08, 00) = 0, REG_RANK_INDEX(08, 00) = 0, BYTE = 3
IRQ32: idx = 01 REG_RANK_NR(08, 01) = 0, REG_RANK_INDEX(08, 01) = 1, BYTE = 0
IRQ33: idx = 01 REG_RANK_NR(08, 01) = 0, REG_RANK_INDEX(08, 01) = 1, BYTE = 1
[...]
IRQ62: idx = 01 REG_RANK_NR(08, 01) = 0, REG_RANK_INDEX(08, 01) = 1, BYTE = 2
IRQ63: idx = 01 REG_RANK_NR(08, 01) = 0, REG_RANK_INDEX(08, 01) = 1, BYTE = 3
IRQ64: idx = 02 REG_RANK_NR(08, 02) = 0, REG_RANK_INDEX(08, 02) = 2, BYTE = 0
IRQ65: idx = 02 REG_RANK_NR(08, 02) = 0, REG_RANK_INDEX(08, 02) = 2, BYTE = 1
[...]
IRQ255: idx = 07 REG_RANK_NR(08, 07) = 0, REG_RANK_INDEX(08, 07) = 7, BYTE = 3
IRQ256: idx = 08 REG_RANK_NR(08, 08) = 1, REG_RANK_INDEX(08, 08) = 0, BYTE = 0

Here allinterrupts up to 255 are in rank 0, which is wrong.

For idx = irq / 32 you would need to use REG_RANK_NR(1, idx) not (8,
idx). (and you'd need to trivially fix REG_RANK_NR to handle b == 1).

Perhaps the way to think of it is not as "/ 32" but rather as ">> 5". 
Since REG_RANK_NR(8, ) is effectively >> 3 when combined with the
existing >> 2 we get >> 5 overall.

If you change it as you have done then you are doing >> 5 *and* >> 3,
i.e. >> 8 aka "/ 256" -- which explains why interrupts up to 255 end up
in rank 0 with your change.

Perhaps this could be made clearer by renaming vgic_irq_rank to
vgic_register_rank? Then perhaps as a helper:
#define VGIC_IRQ_RANK(v, irq) vgic_register_rank(v, 1, irq/32) for the
case of looking up a rank from an irq rather than a register offset?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 09:27:57 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 09:27:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRJiu-0004i1-Sc; Thu, 25 Oct 2012 09:27:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRJis-0004ht-U1
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 09:27:31 +0000
Received: from [85.158.143.99:51654] by server-3.bemta-4.messagelabs.com id
	6F/31-24279-20609805; Thu, 25 Oct 2012 09:27:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1351157249!20280935!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24199 invoked from network); 25 Oct 2012 09:27:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 09:27:29 -0000
X-IronPort-AV: E=Sophos;i="4.80,646,1344211200"; d="scan'208";a="15382360"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 09:27:28 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 25 Oct 2012 10:27:28 +0100
Message-ID: <1351157246.18035.129.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Thu, 25 Oct 2012 10:27:26 +0100
In-Reply-To: <1351091027-20740-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: 
	<1351091027-20740-1-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" , "Tim
	\(Xen.org\)" 
Subject: Re: [Xen-devel] [PATCH 1/7] xen/arm: fix rank calculation in
 vgic_vcpu_inject_irq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 16:03 +0100, Stefano Stabellini wrote:
> Each rank holds 32 irqs, so we should divide by 32 rather than by 4.

I think this is wrong, because idx isn't used in the way your reasoning
implies, when we use it we assume 8 bits-per-interrupt in the register
not 1.

The accessor function vgix_irq_rank is couched in terms of
GICD_, which is convenient where we are emulating register
accesses but is very confusing in this one function where we aren't
thinking in terms of registers!

vgic_irq_rank(v, 8, idx) is saying "find me the rank containing
GICD_ where FOO has 8 bits per interrupt". Since 4 lots of 8
bits goes into 32 we therefore need to divide by 4. This makes sense if
you consider that FOO here is PRIORITY and that GICD_PRIORITY0 controls
irq 0..3, GICD_PRIORITY1 irq 4..7 etc.

With idx = irq >> 2 you get:

IRQ00: idx = 00 REG_RANK_NR(08, 00) = 0, REG_RANK_INDEX(08, 00) = 0, BYTE = 0
IRQ01: idx = 00 REG_RANK_NR(08, 00) = 0, REG_RANK_INDEX(08, 00) = 0, BYTE = 1
IRQ02: idx = 00 REG_RANK_NR(08, 00) = 0, REG_RANK_INDEX(08, 00) = 0, BYTE = 2
IRQ03: idx = 00 REG_RANK_NR(08, 00) = 0, REG_RANK_INDEX(08, 00) = 0, BYTE = 3
IRQ04: idx = 01 REG_RANK_NR(08, 01) = 0, REG_RANK_INDEX(08, 01) = 1, BYTE = 0
IRQ05: idx = 01 REG_RANK_NR(08, 01) = 0, REG_RANK_INDEX(08, 01) = 1, BYTE = 1
[...]
IRQ30: idx = 07 REG_RANK_NR(08, 07) = 0, REG_RANK_INDEX(08, 07) = 7, BYTE = 2
IRQ31: idx = 07 REG_RANK_NR(08, 07) = 0, REG_RANK_INDEX(08, 07) = 7, BYTE = 3
IRQ32: idx = 08 REG_RANK_NR(08, 08) = 1, REG_RANK_INDEX(08, 08) = 0, BYTE = 0
IRQ33: idx = 08 REG_RANK_NR(08, 08) = 1, REG_RANK_INDEX(08, 08) = 0, BYTE = 1
[...]
IRQ62: idx = 15 REG_RANK_NR(08, 15) = 1, REG_RANK_INDEX(08, 15) = 7, BYTE = 2
IRQ63: idx = 15 REG_RANK_NR(08, 15) = 1, REG_RANK_INDEX(08, 15) = 7, BYTE = 3
IRQ64: idx = 16 REG_RANK_NR(08, 16) = 2, REG_RANK_INDEX(08, 16) = 0, BYTE = 0
IRQ65: idx = 16 REG_RANK_NR(08, 16) = 2, REG_RANK_INDEX(08, 16) = 0, BYTE = 1
[...]

IOW interrupts 0..31 are in rank 0, 32..63 are rank 1 etc, which is correct

With idx = irq / 32 you instead get:

IRQ00: idx = 00 REG_RANK_NR(08, 00) = 0, REG_RANK_INDEX(08, 00) = 0, BYTE = 0
IRQ01: idx = 00 REG_RANK_NR(08, 00) = 0, REG_RANK_INDEX(08, 00) = 0, BYTE = 1
IRQ02: idx = 00 REG_RANK_NR(08, 00) = 0, REG_RANK_INDEX(08, 00) = 0, BYTE = 2
IRQ03: idx = 00 REG_RANK_NR(08, 00) = 0, REG_RANK_INDEX(08, 00) = 0, BYTE = 3
IRQ04: idx = 00 REG_RANK_NR(08, 00) = 0, REG_RANK_INDEX(08, 00) = 0, BYTE = 0
IRQ05: idx = 00 REG_RANK_NR(08, 00) = 0, REG_RANK_INDEX(08, 00) = 0, BYTE = 1
[...]
IRQ30: idx = 00 REG_RANK_NR(08, 00) = 0, REG_RANK_INDEX(08, 00) = 0, BYTE = 2
IRQ31: idx = 00 REG_RANK_NR(08, 00) = 0, REG_RANK_INDEX(08, 00) = 0, BYTE = 3
IRQ32: idx = 01 REG_RANK_NR(08, 01) = 0, REG_RANK_INDEX(08, 01) = 1, BYTE = 0
IRQ33: idx = 01 REG_RANK_NR(08, 01) = 0, REG_RANK_INDEX(08, 01) = 1, BYTE = 1
[...]
IRQ62: idx = 01 REG_RANK_NR(08, 01) = 0, REG_RANK_INDEX(08, 01) = 1, BYTE = 2
IRQ63: idx = 01 REG_RANK_NR(08, 01) = 0, REG_RANK_INDEX(08, 01) = 1, BYTE = 3
IRQ64: idx = 02 REG_RANK_NR(08, 02) = 0, REG_RANK_INDEX(08, 02) = 2, BYTE = 0
IRQ65: idx = 02 REG_RANK_NR(08, 02) = 0, REG_RANK_INDEX(08, 02) = 2, BYTE = 1
[...]
IRQ255: idx = 07 REG_RANK_NR(08, 07) = 0, REG_RANK_INDEX(08, 07) = 7, BYTE = 3
IRQ256: idx = 08 REG_RANK_NR(08, 08) = 1, REG_RANK_INDEX(08, 08) = 0, BYTE = 0

Here allinterrupts up to 255 are in rank 0, which is wrong.

For idx = irq / 32 you would need to use REG_RANK_NR(1, idx) not (8,
idx). (and you'd need to trivially fix REG_RANK_NR to handle b == 1).

Perhaps the way to think of it is not as "/ 32" but rather as ">> 5". 
Since REG_RANK_NR(8, ) is effectively >> 3 when combined with the
existing >> 2 we get >> 5 overall.

If you change it as you have done then you are doing >> 5 *and* >> 3,
i.e. >> 8 aka "/ 256" -- which explains why interrupts up to 255 end up
in rank 0 with your change.

Perhaps this could be made clearer by renaming vgic_irq_rank to
vgic_register_rank? Then perhaps as a helper:
#define VGIC_IRQ_RANK(v, irq) vgic_register_rank(v, 1, irq/32) for the
case of looking up a rank from an irq rather than a register offset?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 09:30:40 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 09:30:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRJlW-0004nW-DG; Thu, 25 Oct 2012 09:30:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRJlV-0004nQ-8Q
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 09:30:13 +0000
Received: from [85.158.138.51:38200] by server-6.bemta-3.messagelabs.com id
	90/D3-32375-4A609805; Thu, 25 Oct 2012 09:30:12 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1351157408!27274025!1
X-Originating-IP: [216.32.180.16]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32554 invoked from network); 25 Oct 2012 09:30:10 -0000
Received: from va3ehsobe006.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.16)
	by server-16.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Oct 2012 09:30:10 -0000
Received: from mail87-va3-R.bigfish.com (10.7.14.248) by
	VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id
	14.1.225.23; Thu, 25 Oct 2012 09:30:08 +0000
Received: from mail87-va3 (localhost [127.0.0.1])	by mail87-va3-R.bigfish.com
	(Postfix) with ESMTP id CB2223400CF;
	Thu, 25 Oct 2012 09:30:07 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: -3
X-BigFish: VPS-3(zzbb2dI98dI1432Izz1202h1d1ah1d2ahzz8275bhz2dh668h839he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h)
Received: from mail87-va3 (localhost.localdomain [127.0.0.1]) by mail87-va3
	(MessageSwitch) id 1351157405698561_26255;
	Thu, 25 Oct 2012 09:30:05 +0000 (UTC)
Received: from VA3EHSMHS008.bigfish.com (unknown [10.7.14.247])	by
	mail87-va3.bigfish.com (Postfix) with ESMTP id 9C4A7300099;
	Thu, 25 Oct 2012 09:30:05 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS008.bigfish.com (10.7.99.18) with Microsoft SMTP Server id
	14.1.225.23; Thu, 25 Oct 2012 09:30:02 +0000
X-WSS-ID: 0MCFZQ0-01-87Q-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2D0D210280ED;	Thu, 25 Oct 2012 04:29:59 -0500 (CDT)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 25 Oct 2012 04:30:15 -0500
Received: from STOREXDAG02.amd.com (10.1.13.11) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Thu, 25 Oct 2012 04:29:59 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag02.amd.com
	(10.1.13.11) with Microsoft SMTP Server id 14.2.318.4; Thu, 25 Oct 2012
	05:29:58 -0400
Message-ID: <50890695.7040306@amd.com>
Date: Thu, 25 Oct 2012 11:29:57 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich 
References: <50782D4B.50607@amd.com>
	<5087F8B902000078000A3F38@nat28.tlf.novell.com>
	<5088F5BF.2090603@amd.com>
	<50891A8B02000078000A45C5@nat28.tlf.novell.com>
In-Reply-To: <50891A8B02000078000A45C5@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] x86/MCE: Implement clearbank callback for
 AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/25/12 10:55, Jan Beulich wrote:
>>>> On 25.10.12 at 10:18, Christoph Egger  wrote:
>> On 10/24/12 14:18, Jan Beulich wrote:
>>>>>> On 12.10.12 at 16:46, Christoph Egger  wrote:
>>>> +static int k8_need_clearbank_scan(enum mca_source who, uint64_t status)
>>>> +{
>>>> +	switch (who) {
>>>> +	case MCA_MCE_SCAN:
>>>> +	case MCA_MCE_HANDLER:
>>>> +		break;
>>>> +	default:
>>>> +		return 1;
>>>> +	}
>>>> +
>>>> +	/* For fatal error, it shouldn't be cleared so that sticky bank
>>>> +	 * have chance to be handled after reboot by polling.
>>>> +	 */
>>>> +	if ( (status & MCi_STATUS_UC) && (status & MCi_STATUS_PCC) )
>>>> +		return 0;
>>>> +	/* Spurious need clear bank */
>>>> +	if ( !(status & MCi_STATUS_OVER)
>>>> +	    && (status & MCi_STATUS_UC) && !(status & MCi_STATUS_EN))
>>>> +		return 1;
>>>> +
>>>> +	return 1;
>>>> }
>>>
>>> So what's the purpose of first conditionally returning 1, and then
>>> also doing so unconditionally? Do anticipate to insert code between
>>> the two parts within the very near future? Otherwise I'd drop the
>>> whole if() construct.
>>
>> This function is derived from  intel_need_clearbank_scan().
>> I just took over the relevant parts for AMD.
> 
> But that would suggest that the final return be "return 0" rather
> than "return 1".
> 
> Further, the Intel code does no extra checking for the
> MCA_MCE_HANDLER case, so I'd like you to confirm that this is
> indeed to be different for your CPUs.

I just noticed that MCA_MCE_HANDLER is not used at all and can be
removed entirely.

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 09:30:40 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 09:30:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRJlW-0004nW-DG; Thu, 25 Oct 2012 09:30:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRJlV-0004nQ-8Q
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 09:30:13 +0000
Received: from [85.158.138.51:38200] by server-6.bemta-3.messagelabs.com id
	90/D3-32375-4A609805; Thu, 25 Oct 2012 09:30:12 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1351157408!27274025!1
X-Originating-IP: [216.32.180.16]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32554 invoked from network); 25 Oct 2012 09:30:10 -0000
Received: from va3ehsobe006.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.16)
	by server-16.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Oct 2012 09:30:10 -0000
Received: from mail87-va3-R.bigfish.com (10.7.14.248) by
	VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id
	14.1.225.23; Thu, 25 Oct 2012 09:30:08 +0000
Received: from mail87-va3 (localhost [127.0.0.1])	by mail87-va3-R.bigfish.com
	(Postfix) with ESMTP id CB2223400CF;
	Thu, 25 Oct 2012 09:30:07 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: -3
X-BigFish: VPS-3(zzbb2dI98dI1432Izz1202h1d1ah1d2ahzz8275bhz2dh668h839he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h)
Received: from mail87-va3 (localhost.localdomain [127.0.0.1]) by mail87-va3
	(MessageSwitch) id 1351157405698561_26255;
	Thu, 25 Oct 2012 09:30:05 +0000 (UTC)
Received: from VA3EHSMHS008.bigfish.com (unknown [10.7.14.247])	by
	mail87-va3.bigfish.com (Postfix) with ESMTP id 9C4A7300099;
	Thu, 25 Oct 2012 09:30:05 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS008.bigfish.com (10.7.99.18) with Microsoft SMTP Server id
	14.1.225.23; Thu, 25 Oct 2012 09:30:02 +0000
X-WSS-ID: 0MCFZQ0-01-87Q-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2D0D210280ED;	Thu, 25 Oct 2012 04:29:59 -0500 (CDT)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 25 Oct 2012 04:30:15 -0500
Received: from STOREXDAG02.amd.com (10.1.13.11) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Thu, 25 Oct 2012 04:29:59 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag02.amd.com
	(10.1.13.11) with Microsoft SMTP Server id 14.2.318.4; Thu, 25 Oct 2012
	05:29:58 -0400
Message-ID: <50890695.7040306@amd.com>
Date: Thu, 25 Oct 2012 11:29:57 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich 
References: <50782D4B.50607@amd.com>
	<5087F8B902000078000A3F38@nat28.tlf.novell.com>
	<5088F5BF.2090603@amd.com>
	<50891A8B02000078000A45C5@nat28.tlf.novell.com>
In-Reply-To: <50891A8B02000078000A45C5@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] x86/MCE: Implement clearbank callback for
 AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/25/12 10:55, Jan Beulich wrote:
>>>> On 25.10.12 at 10:18, Christoph Egger  wrote:
>> On 10/24/12 14:18, Jan Beulich wrote:
>>>>>> On 12.10.12 at 16:46, Christoph Egger  wrote:
>>>> +static int k8_need_clearbank_scan(enum mca_source who, uint64_t status)
>>>> +{
>>>> +	switch (who) {
>>>> +	case MCA_MCE_SCAN:
>>>> +	case MCA_MCE_HANDLER:
>>>> +		break;
>>>> +	default:
>>>> +		return 1;
>>>> +	}
>>>> +
>>>> +	/* For fatal error, it shouldn't be cleared so that sticky bank
>>>> +	 * have chance to be handled after reboot by polling.
>>>> +	 */
>>>> +	if ( (status & MCi_STATUS_UC) && (status & MCi_STATUS_PCC) )
>>>> +		return 0;
>>>> +	/* Spurious need clear bank */
>>>> +	if ( !(status & MCi_STATUS_OVER)
>>>> +	    && (status & MCi_STATUS_UC) && !(status & MCi_STATUS_EN))
>>>> +		return 1;
>>>> +
>>>> +	return 1;
>>>> }
>>>
>>> So what's the purpose of first conditionally returning 1, and then
>>> also doing so unconditionally? Do anticipate to insert code between
>>> the two parts within the very near future? Otherwise I'd drop the
>>> whole if() construct.
>>
>> This function is derived from  intel_need_clearbank_scan().
>> I just took over the relevant parts for AMD.
> 
> But that would suggest that the final return be "return 0" rather
> than "return 1".
> 
> Further, the Intel code does no extra checking for the
> MCA_MCE_HANDLER case, so I'd like you to confirm that this is
> indeed to be different for your CPUs.

I just noticed that MCA_MCE_HANDLER is not used at all and can be
removed entirely.

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 09:31:40 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 09:31:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRJme-0004ue-1G; Thu, 25 Oct 2012 09:31:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRJmd-0004uS-0S
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 09:31:23 +0000
Received: from [85.158.138.51:60723] by server-15.bemta-3.messagelabs.com id
	7C/A9-09445-AE609805; Thu, 25 Oct 2012 09:31:22 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-174.messagelabs.com!1351157481!19281527!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0NDg1OTU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0NDg1OTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30855 invoked from network); 25 Oct 2012 09:31:21 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Oct 2012 09:31:21 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll387qFkE=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-086-014.pools.arcor-ip.net [84.57.86.14])
	by smtp.strato.de (josoe mo47) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id K03860o9P9NFE4 ;
	Thu, 25 Oct 2012 11:31:12 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id F40EA18642; Thu, 25 Oct 2012 11:31:10 +0200 (CEST)
Date: Thu, 25 Oct 2012 11:31:10 +0200
From: Olaf Hering 
To: Jan Beulich 
Message-ID: <20121025093110.GA29278@aepfle.de>
References: <1351155873-26500-1-git-send-email-olaf@aepfle.de>
	<5089202E02000078000A45E7@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5089202E02000078000A45E7@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH] xen PVonHVM: move shared_info to reserved
 memory area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Oct 25, Jan Beulich wrote:

> >>> On 25.10.12 at 11:04, Olaf Hering  wrote:
> > @@ -1495,38 +1494,53 @@ asmlinkage void __init xen_start_kernel(void)
> >  #endif
> >  }
> >  
> > -void __ref xen_hvm_init_shared_info(void)
> 
> Was the __ref here in fact unnecessary (i.e. did you check that
> its removal doesn't cause any section mismatch warnings)?

It does not cause any warnings for me.

> > +static void xen_hvm_set_shared_info(struct shared_info *sip)
> 
> With its sole caller being __init, this should also be __init.

Thanks, I will respin the patch with this change.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 09:31:40 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 09:31:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRJme-0004ue-1G; Thu, 25 Oct 2012 09:31:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRJmd-0004uS-0S
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 09:31:23 +0000
Received: from [85.158.138.51:60723] by server-15.bemta-3.messagelabs.com id
	7C/A9-09445-AE609805; Thu, 25 Oct 2012 09:31:22 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-174.messagelabs.com!1351157481!19281527!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0NDg1OTU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0NDg1OTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30855 invoked from network); 25 Oct 2012 09:31:21 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Oct 2012 09:31:21 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll387qFkE=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-086-014.pools.arcor-ip.net [84.57.86.14])
	by smtp.strato.de (josoe mo47) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id K03860o9P9NFE4 ;
	Thu, 25 Oct 2012 11:31:12 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id F40EA18642; Thu, 25 Oct 2012 11:31:10 +0200 (CEST)
Date: Thu, 25 Oct 2012 11:31:10 +0200
From: Olaf Hering 
To: Jan Beulich 
Message-ID: <20121025093110.GA29278@aepfle.de>
References: <1351155873-26500-1-git-send-email-olaf@aepfle.de>
	<5089202E02000078000A45E7@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5089202E02000078000A45E7@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH] xen PVonHVM: move shared_info to reserved
 memory area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Oct 25, Jan Beulich wrote:

> >>> On 25.10.12 at 11:04, Olaf Hering  wrote:
> > @@ -1495,38 +1494,53 @@ asmlinkage void __init xen_start_kernel(void)
> >  #endif
> >  }
> >  
> > -void __ref xen_hvm_init_shared_info(void)
> 
> Was the __ref here in fact unnecessary (i.e. did you check that
> its removal doesn't cause any section mismatch warnings)?

It does not cause any warnings for me.

> > +static void xen_hvm_set_shared_info(struct shared_info *sip)
> 
> With its sole caller being __init, this should also be __init.

Thanks, I will respin the patch with this change.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 09:33:48 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 09:33:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRJoh-00054p-Hp; Thu, 25 Oct 2012 09:33:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRJog-00054f-BZ
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 09:33:30 +0000
Received: from [85.158.143.99:20513] by server-2.bemta-4.messagelabs.com id
	1C/D4-22268-96709805; Thu, 25 Oct 2012 09:33:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1351157609!27343805!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6169 invoked from network); 25 Oct 2012 09:33:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 09:33:29 -0000
X-IronPort-AV: E=Sophos;i="4.80,646,1344211200"; d="scan'208";a="15382733"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 09:33:28 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 25 Oct 2012 10:33:27 +0100
Message-ID: <1351157606.18035.133.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Thu, 25 Oct 2012 10:33:26 +0100
In-Reply-To: <1351091027-20740-2-git-send-email-stefano.stabellini@eu.citrix.com>
References: 
	<1351091027-20740-2-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" , "Tim
	\(Xen.org\)" 
Subject: Re: [Xen-devel] [PATCH 2/7] xen/arm: setup the fixmap in head.S
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 16:03 +0100, Stefano Stabellini wrote:
> @@ -183,6 +184,16 @@ skip_bss:
>         teq   r12, #0
>         bne   pt_ready
>         
> +       /* console fixmap */
> +       ldr   r1, =xen_fixmap
> +       add   r1, r1, r10            /* r1 := paddr (xen_fixmap) */
> +       mov   r3, #0
> +       lsr   r2, r11, #12
> +       lsl   r2, r2, #12            /* 4K aligned paddr of UART */
> +       orr   r2, r2, #PT_UPPER(DEV_L3)
> +       orr   r2, r2, #PT_LOWER(DEV_L3) /* r2:r3 := 4K dev map including UART */
> +       strd  r2, r3, [r1, #0]       /* Map it in the first fixmap's slot */
> +       
>         /* Build the baseline idle pagetable's first-level entries */
>         ldr   r1, =xen_second
>         add   r1, r1, r10            /* r1 := paddr (xen_second) */
[...]
> @@ -205,12 +216,13 @@ skip_bss:
>  	ldr   r4, =start
>  	lsr   r4, #18                /* Slot for vaddr(start) */
>  	strd  r2, r3, [r1, r4]       /* Map Xen there too */
> +
>  #ifdef EARLY_UART_ADDRESS
> -	ldr   r3, =(1<<(54-32))      /* NS for device mapping */
> -	lsr   r2, r11, #21
> -	lsl   r2, r2, #21            /* 2MB-aligned paddr of UART */
> -	orr   r2, r2, #PT_UPPER(DEV)
> -	orr   r2, r2, #PT_LOWER(DEV) /* r2:r3 := 2MB dev map including UART */
> +	/* xen_fixmap pagetable */
> +	ldr r2, =xen_fixmap
> +	add r2, r2, r10
> +	orr   r2, r2, #PT_UPPER(PT)
> +	orr   r2, r2, #PT_LOWER(PT) /* r2:r3 := paddr (xen_fixmap) */

We should setup the fixmap infrastructure even if !EARLY_UART_ADDRESS,
unless we set it up again later?

As it stands it looks like you setup the generic fixmap mapping iff
EARLY_UART_ADDRESS (second hunk above) but setup the UART mapping within
that unconditionally (first hunk) which is exactly backwards, isn't it ?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 09:33:48 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 09:33:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRJoh-00054p-Hp; Thu, 25 Oct 2012 09:33:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRJog-00054f-BZ
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 09:33:30 +0000
Received: from [85.158.143.99:20513] by server-2.bemta-4.messagelabs.com id
	1C/D4-22268-96709805; Thu, 25 Oct 2012 09:33:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1351157609!27343805!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6169 invoked from network); 25 Oct 2012 09:33:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 09:33:29 -0000
X-IronPort-AV: E=Sophos;i="4.80,646,1344211200"; d="scan'208";a="15382733"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 09:33:28 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 25 Oct 2012 10:33:27 +0100
Message-ID: <1351157606.18035.133.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Thu, 25 Oct 2012 10:33:26 +0100
In-Reply-To: <1351091027-20740-2-git-send-email-stefano.stabellini@eu.citrix.com>
References: 
	<1351091027-20740-2-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" , "Tim
	\(Xen.org\)" 
Subject: Re: [Xen-devel] [PATCH 2/7] xen/arm: setup the fixmap in head.S
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 16:03 +0100, Stefano Stabellini wrote:
> @@ -183,6 +184,16 @@ skip_bss:
>         teq   r12, #0
>         bne   pt_ready
>         
> +       /* console fixmap */
> +       ldr   r1, =xen_fixmap
> +       add   r1, r1, r10            /* r1 := paddr (xen_fixmap) */
> +       mov   r3, #0
> +       lsr   r2, r11, #12
> +       lsl   r2, r2, #12            /* 4K aligned paddr of UART */
> +       orr   r2, r2, #PT_UPPER(DEV_L3)
> +       orr   r2, r2, #PT_LOWER(DEV_L3) /* r2:r3 := 4K dev map including UART */
> +       strd  r2, r3, [r1, #0]       /* Map it in the first fixmap's slot */
> +       
>         /* Build the baseline idle pagetable's first-level entries */
>         ldr   r1, =xen_second
>         add   r1, r1, r10            /* r1 := paddr (xen_second) */
[...]
> @@ -205,12 +216,13 @@ skip_bss:
>  	ldr   r4, =start
>  	lsr   r4, #18                /* Slot for vaddr(start) */
>  	strd  r2, r3, [r1, r4]       /* Map Xen there too */
> +
>  #ifdef EARLY_UART_ADDRESS
> -	ldr   r3, =(1<<(54-32))      /* NS for device mapping */
> -	lsr   r2, r11, #21
> -	lsl   r2, r2, #21            /* 2MB-aligned paddr of UART */
> -	orr   r2, r2, #PT_UPPER(DEV)
> -	orr   r2, r2, #PT_LOWER(DEV) /* r2:r3 := 2MB dev map including UART */
> +	/* xen_fixmap pagetable */
> +	ldr r2, =xen_fixmap
> +	add r2, r2, r10
> +	orr   r2, r2, #PT_UPPER(PT)
> +	orr   r2, r2, #PT_LOWER(PT) /* r2:r3 := paddr (xen_fixmap) */

We should setup the fixmap infrastructure even if !EARLY_UART_ADDRESS,
unless we set it up again later?

As it stands it looks like you setup the generic fixmap mapping iff
EARLY_UART_ADDRESS (second hunk above) but setup the UART mapping within
that unconditionally (first hunk) which is exactly backwards, isn't it ?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 09:37:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 09:37:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRJsT-0005Id-72; Thu, 25 Oct 2012 09:37:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRJsQ-0005IX-TB
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 09:37:23 +0000
Received: from [85.158.138.51:15105] by server-8.bemta-3.messagelabs.com id
	A7/C5-10525-25809805; Thu, 25 Oct 2012 09:37:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1351157841!27449115!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25353 invoked from network); 25 Oct 2012 09:37:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 09:37:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,646,1344211200"; d="scan'208";a="15382847"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 09:37:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 25 Oct 2012 10:37:21 +0100
Message-ID: <1351157839.18035.135.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Thu, 25 Oct 2012 10:37:19 +0100
In-Reply-To: <1351091027-20740-3-git-send-email-stefano.stabellini@eu.citrix.com>
References: 
	<1351091027-20740-3-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" , "Tim
	\(Xen.org\)" 
Subject: Re: [Xen-devel] [PATCH 3/7] pl011: set baud and clock_hz to the
 right defaults for Versatile Express
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Can we get these (or at least the clock_hz) from DTB?

On Wed, 2012-10-24 at 16:03 +0100, Stefano Stabellini wrote:
> Signed-off-by: Stefano Stabellini 
> ---
>  xen/drivers/char/pl011.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c
> index 6af45aa..6ccb73a 100644
> --- a/xen/drivers/char/pl011.c
> +++ b/xen/drivers/char/pl011.c
> @@ -241,8 +241,8 @@ void __init pl011_init(int index, unsigned long register_base_address)
>  
>      uart = &pl011_com[index];
>  
> -    uart->clock_hz  = 7372800;
> -    uart->baud      = 115200;
> +    uart->clock_hz  = 0x16e3600;
> +    uart->baud      = 38400;
>      uart->data_bits = 8;
>      uart->parity    = PARITY_NONE;
>      uart->stop_bits = 1;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 09:37:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 09:37:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRJsT-0005Id-72; Thu, 25 Oct 2012 09:37:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRJsQ-0005IX-TB
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 09:37:23 +0000
Received: from [85.158.138.51:15105] by server-8.bemta-3.messagelabs.com id
	A7/C5-10525-25809805; Thu, 25 Oct 2012 09:37:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1351157841!27449115!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25353 invoked from network); 25 Oct 2012 09:37:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 09:37:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,646,1344211200"; d="scan'208";a="15382847"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 09:37:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 25 Oct 2012 10:37:21 +0100
Message-ID: <1351157839.18035.135.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Thu, 25 Oct 2012 10:37:19 +0100
In-Reply-To: <1351091027-20740-3-git-send-email-stefano.stabellini@eu.citrix.com>
References: 
	<1351091027-20740-3-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" , "Tim
	\(Xen.org\)" 
Subject: Re: [Xen-devel] [PATCH 3/7] pl011: set baud and clock_hz to the
 right defaults for Versatile Express
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Can we get these (or at least the clock_hz) from DTB?

On Wed, 2012-10-24 at 16:03 +0100, Stefano Stabellini wrote:
> Signed-off-by: Stefano Stabellini 
> ---
>  xen/drivers/char/pl011.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c
> index 6af45aa..6ccb73a 100644
> --- a/xen/drivers/char/pl011.c
> +++ b/xen/drivers/char/pl011.c
> @@ -241,8 +241,8 @@ void __init pl011_init(int index, unsigned long register_base_address)
>  
>      uart = &pl011_com[index];
>  
> -    uart->clock_hz  = 7372800;
> -    uart->baud      = 115200;
> +    uart->clock_hz  = 0x16e3600;
> +    uart->baud      = 38400;
>      uart->data_bits = 8;
>      uart->parity    = PARITY_NONE;
>      uart->stop_bits = 1;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 09:52:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 09:52:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRK6v-0005WH-LO; Thu, 25 Oct 2012 09:52:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRK6u-0005WC-Se
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 09:52:21 +0000
Received: from [85.158.139.83:62815] by server-6.bemta-5.messagelabs.com id
	3F/DC-32589-3DB09805; Thu, 25 Oct 2012 09:52:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1351158739!31890560!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18017 invoked from network); 25 Oct 2012 09:52:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 09:52:19 -0000
X-IronPort-AV: E=Sophos;i="4.80,646,1344211200"; d="scan'208";a="15383417"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 09:52:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 25 Oct 2012 10:52:19 +0100
Message-ID: <1351158737.18035.142.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Thu, 25 Oct 2012 10:52:17 +0100
In-Reply-To: <1351091027-20740-4-git-send-email-stefano.stabellini@eu.citrix.com>
References: 
	<1351091027-20740-4-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" , "Tim
	\(Xen.org\)" 
Subject: Re: [Xen-devel] [PATCH 4/7] xen/arm: set the SMP bit in the ACTLR
	register
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 16:03 +0100, Stefano Stabellini wrote:
> From the Cortex A15 manual:
> 
> "Enables the processor to receive instruction cache, BTB, and TLB maintenance
> operations from other processors"
> 
> ...
> 
> "You must set this bit before enabling the caches and MMU, or
> performing any cache and TLB maintenance operations. The only time
> you must clear this bit is during a processor power-down sequence"

Is it considered a bug that the firmware doesn't do this?

> Signed-off-by: Stefano Stabellini 
> ---
>  xen/arch/arm/head.S             |    6 ++++++
>  xen/include/asm-arm/processor.h |   30 ++++++++++++++++++++++++++++++
>  2 files changed, 36 insertions(+), 0 deletions(-)
> 
> diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
> index 3d01be0..c784f4d 100644
> --- a/xen/arch/arm/head.S
> +++ b/xen/arch/arm/head.S
> @@ -148,6 +148,12 @@ skip_bss:
>  
>  	PRINT("- Setting up control registers -\r\n")
>  	
> +	/* XXX: Cortex A15 specific */

We probably need some sort of early proc info keyed of the processor id
(like Linux) has so we can push this processor specific stuff into the
right places.

> +	/* Set up the SMP bit in ACTLR */
> +	mrc   CP32(r0, ACTLR)
> +	orr   r0, r0, #(ACTLR_SMP) /* enable SMP bit*/
> +	mcr   CP32(r0, ACTLR)

Linux does this IFF it isn't already set for some reason:
#ifdef CONFIG_SMP
        ALT_SMP(mrc     p15, 0, r0, c1, c0, 1)
        ALT_UP(mov      r0, #(1 << 6))          @ fake it for UP
        tst     r0, #(1 << 6)                   @ SMP/nAMP mode enabled?
        orreq   r0, r0, #(1 << 6)               @ Enable SMP/nAMP mode
        orreq   r0, r0, r10                     @ Enable CPU-specific SMP bits
        mcreq   p15, 0, r0, c1, c0, 1
#endif

Might just relate to the "fake it up for UP" thing I suppose.

> +
>  	/* Set up memory attribute type tables */
>  	ldr   r0, =MAIR0VAL
>  	ldr   r1, =MAIR1VAL
> diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
> index 3849b23..91a5836 100644
> --- a/xen/include/asm-arm/processor.h
> +++ b/xen/include/asm-arm/processor.h
> @@ -34,6 +34,36 @@
>  #define SCTLR_A         (1<<1)
>  #define SCTLR_M         (1<<0)
>  
> +/* ACTLR Auxiliary Control Register */
> +#define ACTLR_SNOOP_DELAYED      (1<<31)

If these are CortexA15 specific then I think they ought to be
ACTLR_CA15_FOO or something. And possibly in a new processor-ca15.h
header instead.

> +#define ACTLR_MAIN_CLOCK         (1<<30)
> +#define ACTLR_NEON_CLOCK         (1<<29)
> +#define ACTLR_NONCACHE           (1<<24)
> +#define ACTLR_INORDER_REQ        (1<<23)
> +#define ACTLR_INORDER_LOAD       (1<<22)
> +#define ACTLR_L2_TLB_PREFETCH    (1<<21)
> +#define ACTLR_L2_IPA_PA_CACHE    (1<<20)
> +#define ACTLR_L2_CACHE           (1<<19)
> +#define ACTLR_L2_PA_CACHE        (1<<18)
> +#define ACTLR_TLB                (1<<17)
> +#define ACTLR_STRONGY_ORDERED    (1<<16)
> +#define ACTLR_INORDER            (1<<15)
> +#define ACTLR_FORCE_LIM          (1<<14)
> +#define ACTLR_CP_FLUSH           (1<<13)
> +#define ACTLR_CP_PUSH            (1<<12)
> +#define ACTLR_LIM                (1<<11)
> +#define ACTLR_SER                (1<<10)
> +#define ACTLR_OPT                (1<<9)
> +#define ACTLR_WFI                (1<<8)
> +#define ACTLR_WFE                (1<<7)
> +#define ACTLR_SMP                (1<<6)
> +#define ACTLR_PLD                (1<<5)
> +#define ACTLR_IP                 (1<<4)
> +#define ACTLR_MICRO_BTB          (1<<3)
> +#define ACTLR_LOOP_ONE           (1<<2)
> +#define ACTLR_LOOP_DISABLE       (1<<1)
> +#define ACTLR_BTB                (1<<0)
> +
>  #define SCTLR_BASE        0x00c50078
>  #define HSCTLR_BASE       0x30c51878
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 09:52:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 09:52:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRK6v-0005WH-LO; Thu, 25 Oct 2012 09:52:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRK6u-0005WC-Se
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 09:52:21 +0000
Received: from [85.158.139.83:62815] by server-6.bemta-5.messagelabs.com id
	3F/DC-32589-3DB09805; Thu, 25 Oct 2012 09:52:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1351158739!31890560!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18017 invoked from network); 25 Oct 2012 09:52:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 09:52:19 -0000
X-IronPort-AV: E=Sophos;i="4.80,646,1344211200"; d="scan'208";a="15383417"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 09:52:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 25 Oct 2012 10:52:19 +0100
Message-ID: <1351158737.18035.142.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Thu, 25 Oct 2012 10:52:17 +0100
In-Reply-To: <1351091027-20740-4-git-send-email-stefano.stabellini@eu.citrix.com>
References: 
	<1351091027-20740-4-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" , "Tim
	\(Xen.org\)" 
Subject: Re: [Xen-devel] [PATCH 4/7] xen/arm: set the SMP bit in the ACTLR
	register
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 16:03 +0100, Stefano Stabellini wrote:
> From the Cortex A15 manual:
> 
> "Enables the processor to receive instruction cache, BTB, and TLB maintenance
> operations from other processors"
> 
> ...
> 
> "You must set this bit before enabling the caches and MMU, or
> performing any cache and TLB maintenance operations. The only time
> you must clear this bit is during a processor power-down sequence"

Is it considered a bug that the firmware doesn't do this?

> Signed-off-by: Stefano Stabellini 
> ---
>  xen/arch/arm/head.S             |    6 ++++++
>  xen/include/asm-arm/processor.h |   30 ++++++++++++++++++++++++++++++
>  2 files changed, 36 insertions(+), 0 deletions(-)
> 
> diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
> index 3d01be0..c784f4d 100644
> --- a/xen/arch/arm/head.S
> +++ b/xen/arch/arm/head.S
> @@ -148,6 +148,12 @@ skip_bss:
>  
>  	PRINT("- Setting up control registers -\r\n")
>  	
> +	/* XXX: Cortex A15 specific */

We probably need some sort of early proc info keyed of the processor id
(like Linux) has so we can push this processor specific stuff into the
right places.

> +	/* Set up the SMP bit in ACTLR */
> +	mrc   CP32(r0, ACTLR)
> +	orr   r0, r0, #(ACTLR_SMP) /* enable SMP bit*/
> +	mcr   CP32(r0, ACTLR)

Linux does this IFF it isn't already set for some reason:
#ifdef CONFIG_SMP
        ALT_SMP(mrc     p15, 0, r0, c1, c0, 1)
        ALT_UP(mov      r0, #(1 << 6))          @ fake it for UP
        tst     r0, #(1 << 6)                   @ SMP/nAMP mode enabled?
        orreq   r0, r0, #(1 << 6)               @ Enable SMP/nAMP mode
        orreq   r0, r0, r10                     @ Enable CPU-specific SMP bits
        mcreq   p15, 0, r0, c1, c0, 1
#endif

Might just relate to the "fake it up for UP" thing I suppose.

> +
>  	/* Set up memory attribute type tables */
>  	ldr   r0, =MAIR0VAL
>  	ldr   r1, =MAIR1VAL
> diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
> index 3849b23..91a5836 100644
> --- a/xen/include/asm-arm/processor.h
> +++ b/xen/include/asm-arm/processor.h
> @@ -34,6 +34,36 @@
>  #define SCTLR_A         (1<<1)
>  #define SCTLR_M         (1<<0)
>  
> +/* ACTLR Auxiliary Control Register */
> +#define ACTLR_SNOOP_DELAYED      (1<<31)

If these are CortexA15 specific then I think they ought to be
ACTLR_CA15_FOO or something. And possibly in a new processor-ca15.h
header instead.

> +#define ACTLR_MAIN_CLOCK         (1<<30)
> +#define ACTLR_NEON_CLOCK         (1<<29)
> +#define ACTLR_NONCACHE           (1<<24)
> +#define ACTLR_INORDER_REQ        (1<<23)
> +#define ACTLR_INORDER_LOAD       (1<<22)
> +#define ACTLR_L2_TLB_PREFETCH    (1<<21)
> +#define ACTLR_L2_IPA_PA_CACHE    (1<<20)
> +#define ACTLR_L2_CACHE           (1<<19)
> +#define ACTLR_L2_PA_CACHE        (1<<18)
> +#define ACTLR_TLB                (1<<17)
> +#define ACTLR_STRONGY_ORDERED    (1<<16)
> +#define ACTLR_INORDER            (1<<15)
> +#define ACTLR_FORCE_LIM          (1<<14)
> +#define ACTLR_CP_FLUSH           (1<<13)
> +#define ACTLR_CP_PUSH            (1<<12)
> +#define ACTLR_LIM                (1<<11)
> +#define ACTLR_SER                (1<<10)
> +#define ACTLR_OPT                (1<<9)
> +#define ACTLR_WFI                (1<<8)
> +#define ACTLR_WFE                (1<<7)
> +#define ACTLR_SMP                (1<<6)
> +#define ACTLR_PLD                (1<<5)
> +#define ACTLR_IP                 (1<<4)
> +#define ACTLR_MICRO_BTB          (1<<3)
> +#define ACTLR_LOOP_ONE           (1<<2)
> +#define ACTLR_LOOP_DISABLE       (1<<1)
> +#define ACTLR_BTB                (1<<0)
> +
>  #define SCTLR_BASE        0x00c50078
>  #define HSCTLR_BASE       0x30c51878
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 10:00:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 10:00:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRKE4-0005fy-Iw; Thu, 25 Oct 2012 09:59:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRKE3-0005ft-CF
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 09:59:43 +0000
Received: from [193.109.254.147:64330] by server-15.bemta-14.messagelabs.com
	id E6/8B-12105-E8D09805; Thu, 25 Oct 2012 09:59:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1351159162!11105391!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7122 invoked from network); 25 Oct 2012 09:59:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 09:59:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,646,1344211200"; d="scan'208";a="15383600"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 09:59:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 25 Oct 2012 10:59:21 +0100
Message-ID: <1351159160.18035.147.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Thu, 25 Oct 2012 10:59:20 +0100
In-Reply-To: <1351091027-20740-5-git-send-email-stefano.stabellini@eu.citrix.com>
References: 
	<1351091027-20740-5-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" , "Tim
	\(Xen.org\)" 
Subject: Re: [Xen-devel] [PATCH 5/7] xen/arm: wake up secondary cpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 16:03 +0100, Stefano Stabellini wrote:
> Secondary cpus are held by the firmware until we send an IPI to them.
> 
> Signed-off-by: Stefano Stabellini 
> ---
>  xen/arch/arm/head.S        |    8 ++++++--
>  xen/arch/arm/mode_switch.S |   31 +++++++++++++++++++++++++++++++
>  2 files changed, 37 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
> index c784f4d..39c4774 100644
> --- a/xen/arch/arm/head.S
> +++ b/xen/arch/arm/head.S
> @@ -79,12 +79,12 @@ start:
>  	beq   boot_cpu               /* If we're CPU 0, boot now */
>  
>  	/* Non-boot CPUs wait here to be woken up one at a time. */
> -1:	wfe
> -	dsb
> +1:	dsb
>  	ldr   r0, =smp_up_cpu        /* VA of gate */
>  	add   r0, r0, r10            /* PA of gate */
>  	ldr   r1, [r0]               /* Which CPU is being booted? */
>  	teq   r1, r12                /* Is it us? */
> +	wfene
>  	bne   1b

This is a semi-independent bug fix relating to unnecessarily waiting
(and perhaps blocking indefinitely) on the first iteration of the loop?

>  
>  boot_cpu:
> @@ -98,6 +98,10 @@ boot_cpu:
>  	PRINT(" booting -\r\n")
>  #endif
>  
> +	/* Wake up secondary cpus */
> +	teq   r12, #0
> +	bleq  kick_cpus

Does this have to be done this early? Couldn't we defer it to C land
where it would be easier to isolate the processor/platform specific
behaviour?

>  	/* Check that this CPU has Hyp mode */
>  	mrc   CP32(r0, ID_PFR1)
>  	and   r0, r0, #0xf000        /* Bits 12-15 define virt extensions */
> diff --git a/xen/arch/arm/mode_switch.S b/xen/arch/arm/mode_switch.S
> index 83a682b..39d80e8 100644
> --- a/xen/arch/arm/mode_switch.S
> +++ b/xen/arch/arm/mode_switch.S
> @@ -21,6 +21,37 @@
>  #include 
>  #include 
>  
> +/* XXX: Versatile Express specific code */
> +/* wake up secondary cpus */
> +.globl kick_cpus
> +kick_cpus:

My understanding was the mode_switch.S was intended to be a place to
hold the hacks and fixups required because there is no firmware on the
models and/or to address short comings in the firmware. This kick
function is a normal/expected part of booting on a vexpress so I don't
think it especially belongs here.

> +    /* write start paddr to v2m sysreg FLAGSSET register */
> +	ldr   r0, =0x1c010000 /* base V2M sysreg MMIO address */
> +	add   r1, r0, #0x34   /* SYS_FLAGSCLR register */

As well as Tim's comment about using the GICD_* registers you should
define names for the V2M registers somewhere too.

> +	dsb
> +	mov   r2, #0xffffffff
> +	str   r2, [r1]
> +	dsb
> +	add   r1, r0, #0x30   /* SYS_FLAGSSET register */
> +	ldr   r2, =start
> +	add   r2, r2, r10
> +	str   r2, [r1]
> +	dsb
> +	/* send an interrupt */
> +	ldr   r0, =0x2c001000 /* base GICD MMIO address */
> +	mov   r1, r0
> +	mov   r2, #0x1        /* GICD_CTLR */
> +	str   r2, [r1]        /* enable distributor */
> +	add   r1, r0, #0xf00  /* GICD_SGIR */
> +	mov   r2, #0xfe0000
> +	str   r2, [r1]        /* send IPI to everybody */
> +	dsb
> +	mov   r1, r0
> +	mov   r2, #0x0        /* GICD_CTLR */
> +	str   r2, [r1]        /* disable distributor */
> +	mov   pc, lr
> +
> +
>  /* Get up a CPU into Hyp mode.  Clobbers r0-r3.
>   *
>   * Expects r12 == CPU number



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 10:00:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 10:00:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRKE4-0005fy-Iw; Thu, 25 Oct 2012 09:59:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRKE3-0005ft-CF
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 09:59:43 +0000
Received: from [193.109.254.147:64330] by server-15.bemta-14.messagelabs.com
	id E6/8B-12105-E8D09805; Thu, 25 Oct 2012 09:59:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1351159162!11105391!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7122 invoked from network); 25 Oct 2012 09:59:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 09:59:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,646,1344211200"; d="scan'208";a="15383600"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 09:59:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 25 Oct 2012 10:59:21 +0100
Message-ID: <1351159160.18035.147.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Thu, 25 Oct 2012 10:59:20 +0100
In-Reply-To: <1351091027-20740-5-git-send-email-stefano.stabellini@eu.citrix.com>
References: 
	<1351091027-20740-5-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" , "Tim
	\(Xen.org\)" 
Subject: Re: [Xen-devel] [PATCH 5/7] xen/arm: wake up secondary cpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 16:03 +0100, Stefano Stabellini wrote:
> Secondary cpus are held by the firmware until we send an IPI to them.
> 
> Signed-off-by: Stefano Stabellini 
> ---
>  xen/arch/arm/head.S        |    8 ++++++--
>  xen/arch/arm/mode_switch.S |   31 +++++++++++++++++++++++++++++++
>  2 files changed, 37 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
> index c784f4d..39c4774 100644
> --- a/xen/arch/arm/head.S
> +++ b/xen/arch/arm/head.S
> @@ -79,12 +79,12 @@ start:
>  	beq   boot_cpu               /* If we're CPU 0, boot now */
>  
>  	/* Non-boot CPUs wait here to be woken up one at a time. */
> -1:	wfe
> -	dsb
> +1:	dsb
>  	ldr   r0, =smp_up_cpu        /* VA of gate */
>  	add   r0, r0, r10            /* PA of gate */
>  	ldr   r1, [r0]               /* Which CPU is being booted? */
>  	teq   r1, r12                /* Is it us? */
> +	wfene
>  	bne   1b

This is a semi-independent bug fix relating to unnecessarily waiting
(and perhaps blocking indefinitely) on the first iteration of the loop?

>  
>  boot_cpu:
> @@ -98,6 +98,10 @@ boot_cpu:
>  	PRINT(" booting -\r\n")
>  #endif
>  
> +	/* Wake up secondary cpus */
> +	teq   r12, #0
> +	bleq  kick_cpus

Does this have to be done this early? Couldn't we defer it to C land
where it would be easier to isolate the processor/platform specific
behaviour?

>  	/* Check that this CPU has Hyp mode */
>  	mrc   CP32(r0, ID_PFR1)
>  	and   r0, r0, #0xf000        /* Bits 12-15 define virt extensions */
> diff --git a/xen/arch/arm/mode_switch.S b/xen/arch/arm/mode_switch.S
> index 83a682b..39d80e8 100644
> --- a/xen/arch/arm/mode_switch.S
> +++ b/xen/arch/arm/mode_switch.S
> @@ -21,6 +21,37 @@
>  #include 
>  #include 
>  
> +/* XXX: Versatile Express specific code */
> +/* wake up secondary cpus */
> +.globl kick_cpus
> +kick_cpus:

My understanding was the mode_switch.S was intended to be a place to
hold the hacks and fixups required because there is no firmware on the
models and/or to address short comings in the firmware. This kick
function is a normal/expected part of booting on a vexpress so I don't
think it especially belongs here.

> +    /* write start paddr to v2m sysreg FLAGSSET register */
> +	ldr   r0, =0x1c010000 /* base V2M sysreg MMIO address */
> +	add   r1, r0, #0x34   /* SYS_FLAGSCLR register */

As well as Tim's comment about using the GICD_* registers you should
define names for the V2M registers somewhere too.

> +	dsb
> +	mov   r2, #0xffffffff
> +	str   r2, [r1]
> +	dsb
> +	add   r1, r0, #0x30   /* SYS_FLAGSSET register */
> +	ldr   r2, =start
> +	add   r2, r2, r10
> +	str   r2, [r1]
> +	dsb
> +	/* send an interrupt */
> +	ldr   r0, =0x2c001000 /* base GICD MMIO address */
> +	mov   r1, r0
> +	mov   r2, #0x1        /* GICD_CTLR */
> +	str   r2, [r1]        /* enable distributor */
> +	add   r1, r0, #0xf00  /* GICD_SGIR */
> +	mov   r2, #0xfe0000
> +	str   r2, [r1]        /* send IPI to everybody */
> +	dsb
> +	mov   r1, r0
> +	mov   r2, #0x0        /* GICD_CTLR */
> +	str   r2, [r1]        /* disable distributor */
> +	mov   pc, lr
> +
> +
>  /* Get up a CPU into Hyp mode.  Clobbers r0-r3.
>   *
>   * Expects r12 == CPU number



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 10:03:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 10:03:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRKH6-0005tx-B4; Thu, 25 Oct 2012 10:02:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRKH4-0005tm-GN
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 10:02:50 +0000
Received: from [85.158.137.99:55542] by server-3.bemta-3.messagelabs.com id
	02/E9-09368-94E09805; Thu, 25 Oct 2012 10:02:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1351159368!19829378!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18016 invoked from network); 25 Oct 2012 10:02:49 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 10:02:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,646,1344211200"; d="scan'208";a="15383729"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 10:02:48 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 25 Oct 2012 11:02:48 +0100
Message-ID: <1351159367.18035.149.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Thu, 25 Oct 2012 11:02:47 +0100
In-Reply-To: <1351091027-20740-7-git-send-email-stefano.stabellini@eu.citrix.com>
References: 
	<1351091027-20740-7-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" , "Tim
	\(Xen.org\)" 
Subject: Re: [Xen-devel] [PATCH 7/7] xen/arm: get the number of cpus from
	device tree
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
> index 3d1f0f4..3ae0f4d 100644
> --- a/xen/common/device_tree.c
> +++ b/xen/common/device_tree.c
> @@ -153,6 +153,26 @@ const char *device_tree_bootargs(const void *fdt)
>      return prop->data;
>  }
>  
> +int device_tree_cpus(const void *fdt)
> +{
> +    int node, depth;
> +    int cpus = 0;
> +
> +    node = fdt_path_offset(fdt, "/cpus");
> +    if ( node < 0 )
> +        return -1;

With this we will stumble on with cpus == -1 (~4 billion, which would
make a nice system ;-) ). Perhaps we should either assume UP (with a big
printk) or BUG on failure here?

> +    do {
> +        node = fdt_next_node(fdt, node, &depth);
> +        if ( node < 0 )
> +            break;
> +        if ( strncmp(fdt_get_name(fdt, node, NULL), "cpu", 3) )
> +            break;

If we find /cpus/foo (for any foo != "cpu*") then we stop counting,
rather than just ignoring that node?

> +        cpus++;
> +    } while ( depth > 0 );
> +
> +    return cpus;
> +}
> +
>  static int dump_node(const void *fdt, int node, const char *name, int depth,
>                       u32 address_cells, u32 size_cells, void *data)
>  {
> diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
> index 4d010c0..46bc0f8 100644
> --- a/xen/include/xen/device_tree.h
> +++ b/xen/include/xen/device_tree.h
> @@ -49,6 +49,7 @@ bool_t device_tree_node_matches(const void *fdt, int node, const char *match);
>  int device_tree_for_each_node(const void *fdt,
>                                device_tree_node_func func, void *data);
>  const char *device_tree_bootargs(const void *fdt);
> +int device_tree_cpus(const void *fdt);
>  void device_tree_dump(const void *fdt);
>  
>  #endif



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 10:03:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 10:03:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRKH6-0005tx-B4; Thu, 25 Oct 2012 10:02:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRKH4-0005tm-GN
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 10:02:50 +0000
Received: from [85.158.137.99:55542] by server-3.bemta-3.messagelabs.com id
	02/E9-09368-94E09805; Thu, 25 Oct 2012 10:02:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1351159368!19829378!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18016 invoked from network); 25 Oct 2012 10:02:49 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 10:02:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,646,1344211200"; d="scan'208";a="15383729"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 10:02:48 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 25 Oct 2012 11:02:48 +0100
Message-ID: <1351159367.18035.149.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Thu, 25 Oct 2012 11:02:47 +0100
In-Reply-To: <1351091027-20740-7-git-send-email-stefano.stabellini@eu.citrix.com>
References: 
	<1351091027-20740-7-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" , "Tim
	\(Xen.org\)" 
Subject: Re: [Xen-devel] [PATCH 7/7] xen/arm: get the number of cpus from
	device tree
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
> index 3d1f0f4..3ae0f4d 100644
> --- a/xen/common/device_tree.c
> +++ b/xen/common/device_tree.c
> @@ -153,6 +153,26 @@ const char *device_tree_bootargs(const void *fdt)
>      return prop->data;
>  }
>  
> +int device_tree_cpus(const void *fdt)
> +{
> +    int node, depth;
> +    int cpus = 0;
> +
> +    node = fdt_path_offset(fdt, "/cpus");
> +    if ( node < 0 )
> +        return -1;

With this we will stumble on with cpus == -1 (~4 billion, which would
make a nice system ;-) ). Perhaps we should either assume UP (with a big
printk) or BUG on failure here?

> +    do {
> +        node = fdt_next_node(fdt, node, &depth);
> +        if ( node < 0 )
> +            break;
> +        if ( strncmp(fdt_get_name(fdt, node, NULL), "cpu", 3) )
> +            break;

If we find /cpus/foo (for any foo != "cpu*") then we stop counting,
rather than just ignoring that node?

> +        cpus++;
> +    } while ( depth > 0 );
> +
> +    return cpus;
> +}
> +
>  static int dump_node(const void *fdt, int node, const char *name, int depth,
>                       u32 address_cells, u32 size_cells, void *data)
>  {
> diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
> index 4d010c0..46bc0f8 100644
> --- a/xen/include/xen/device_tree.h
> +++ b/xen/include/xen/device_tree.h
> @@ -49,6 +49,7 @@ bool_t device_tree_node_matches(const void *fdt, int node, const char *match);
>  int device_tree_for_each_node(const void *fdt,
>                                device_tree_node_func func, void *data);
>  const char *device_tree_bootargs(const void *fdt);
> +int device_tree_cpus(const void *fdt);
>  void device_tree_dump(const void *fdt);
>  
>  #endif



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 10:03:57 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 10:03:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRKHu-00061u-PD; Thu, 25 Oct 2012 10:03:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRKHt-00061g-NI
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 10:03:41 +0000
Received: from [85.158.143.35:5334] by server-1.bemta-4.messagelabs.com id
	23/FF-19134-D7E09805; Thu, 25 Oct 2012 10:03:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1351159386!10142264!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2202 invoked from network); 25 Oct 2012 10:03:06 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-21.messagelabs.com with SMTP;
	25 Oct 2012 10:03:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 25 Oct 2012 11:03:07 +0100
Message-Id: <50892A7A02000078000A4627@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 25 Oct 2012 11:03:06 +0100
From: "Jan Beulich" 
To: "Christoph Egger" 
References: <50782D4B.50607@amd.com>
	<5087F8B902000078000A3F38@nat28.tlf.novell.com>
	<5088F5BF.2090603@amd.com>
	<50891A8B02000078000A45C5@nat28.tlf.novell.com>
	<50890695.7040306@amd.com>
In-Reply-To: <50890695.7040306@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] x86/MCE: Implement clearbank callback for
 AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 25.10.12 at 11:29, Christoph Egger  wrote:
> On 10/25/12 10:55, Jan Beulich wrote:
>>>>> On 25.10.12 at 10:18, Christoph Egger  wrote:
>>> On 10/24/12 14:18, Jan Beulich wrote:
>>>>>>> On 12.10.12 at 16:46, Christoph Egger  wrote:
>>>>> +static int k8_need_clearbank_scan(enum mca_source who, uint64_t status)
>>>>> +{
>>>>> +	switch (who) {
>>>>> +	case MCA_MCE_SCAN:
>>>>> +	case MCA_MCE_HANDLER:
>>>>> +		break;
>>>>> +	default:
>>>>> +		return 1;
>>>>> +	}
>>>>> +
>>>>> +	/* For fatal error, it shouldn't be cleared so that sticky bank
>>>>> +	 * have chance to be handled after reboot by polling.
>>>>> +	 */
>>>>> +	if ( (status & MCi_STATUS_UC) && (status & MCi_STATUS_PCC) )
>>>>> +		return 0;
>>>>> +	/* Spurious need clear bank */
>>>>> +	if ( !(status & MCi_STATUS_OVER)
>>>>> +	    && (status & MCi_STATUS_UC) && !(status & MCi_STATUS_EN))
>>>>> +		return 1;
>>>>> +
>>>>> +	return 1;
>>>>> }
>>>>
>>>> So what's the purpose of first conditionally returning 1, and then
>>>> also doing so unconditionally? Do anticipate to insert code between
>>>> the two parts within the very near future? Otherwise I'd drop the
>>>> whole if() construct.
>>>
>>> This function is derived from  intel_need_clearbank_scan().
>>> I just took over the relevant parts for AMD.
>> 
>> But that would suggest that the final return be "return 0" rather
>> than "return 1".
>> 
>> Further, the Intel code does no extra checking for the
>> MCA_MCE_HANDLER case, so I'd like you to confirm that this is
>> indeed to be different for your CPUs.
> 
> I just noticed that MCA_MCE_HANDLER is not used at all and can be
> removed entirely.

Will do. But how about the "return" related question above?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 10:03:57 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 10:03:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRKHu-00061u-PD; Thu, 25 Oct 2012 10:03:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRKHt-00061g-NI
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 10:03:41 +0000
Received: from [85.158.143.35:5334] by server-1.bemta-4.messagelabs.com id
	23/FF-19134-D7E09805; Thu, 25 Oct 2012 10:03:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1351159386!10142264!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2202 invoked from network); 25 Oct 2012 10:03:06 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-21.messagelabs.com with SMTP;
	25 Oct 2012 10:03:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 25 Oct 2012 11:03:07 +0100
Message-Id: <50892A7A02000078000A4627@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 25 Oct 2012 11:03:06 +0100
From: "Jan Beulich" 
To: "Christoph Egger" 
References: <50782D4B.50607@amd.com>
	<5087F8B902000078000A3F38@nat28.tlf.novell.com>
	<5088F5BF.2090603@amd.com>
	<50891A8B02000078000A45C5@nat28.tlf.novell.com>
	<50890695.7040306@amd.com>
In-Reply-To: <50890695.7040306@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] x86/MCE: Implement clearbank callback for
 AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 25.10.12 at 11:29, Christoph Egger  wrote:
> On 10/25/12 10:55, Jan Beulich wrote:
>>>>> On 25.10.12 at 10:18, Christoph Egger  wrote:
>>> On 10/24/12 14:18, Jan Beulich wrote:
>>>>>>> On 12.10.12 at 16:46, Christoph Egger  wrote:
>>>>> +static int k8_need_clearbank_scan(enum mca_source who, uint64_t status)
>>>>> +{
>>>>> +	switch (who) {
>>>>> +	case MCA_MCE_SCAN:
>>>>> +	case MCA_MCE_HANDLER:
>>>>> +		break;
>>>>> +	default:
>>>>> +		return 1;
>>>>> +	}
>>>>> +
>>>>> +	/* For fatal error, it shouldn't be cleared so that sticky bank
>>>>> +	 * have chance to be handled after reboot by polling.
>>>>> +	 */
>>>>> +	if ( (status & MCi_STATUS_UC) && (status & MCi_STATUS_PCC) )
>>>>> +		return 0;
>>>>> +	/* Spurious need clear bank */
>>>>> +	if ( !(status & MCi_STATUS_OVER)
>>>>> +	    && (status & MCi_STATUS_UC) && !(status & MCi_STATUS_EN))
>>>>> +		return 1;
>>>>> +
>>>>> +	return 1;
>>>>> }
>>>>
>>>> So what's the purpose of first conditionally returning 1, and then
>>>> also doing so unconditionally? Do anticipate to insert code between
>>>> the two parts within the very near future? Otherwise I'd drop the
>>>> whole if() construct.
>>>
>>> This function is derived from  intel_need_clearbank_scan().
>>> I just took over the relevant parts for AMD.
>> 
>> But that would suggest that the final return be "return 0" rather
>> than "return 1".
>> 
>> Further, the Intel code does no extra checking for the
>> MCA_MCE_HANDLER case, so I'd like you to confirm that this is
>> indeed to be different for your CPUs.
> 
> I just noticed that MCA_MCE_HANDLER is not used at all and can be
> removed entirely.

Will do. But how about the "return" related question above?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 10:13:50 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 10:13:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRKRS-0006Kc-1k; Thu, 25 Oct 2012 10:13:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRKRP-0006KX-Vu
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 10:13:32 +0000
Received: from [85.158.139.211:56175] by server-12.bemta-5.messagelabs.com id
	05/55-26919-BC019805; Thu, 25 Oct 2012 10:13:31 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1351160010!23682683!1
X-Originating-IP: [213.199.154.204]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20591 invoked from network); 25 Oct 2012 10:13:30 -0000
Received: from am1ehsobe001.messaging.microsoft.com (HELO
	am1outboundpool.messaging.microsoft.com) (213.199.154.204)
	by server-11.tower-206.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Oct 2012 10:13:30 -0000
Received: from mail91-am1-R.bigfish.com (10.3.201.225) by
	AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id
	14.1.225.23; Thu, 25 Oct 2012 10:13:30 +0000
Received: from mail91-am1 (localhost [127.0.0.1])	by mail91-am1-R.bigfish.com
	(Postfix) with ESMTP id 3BF1B601EE;
	Thu, 25 Oct 2012 10:13:30 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: -3
X-BigFish: VPS-3(zzbb2dI98dI1432Izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h)
Received: from mail91-am1 (localhost.localdomain [127.0.0.1]) by mail91-am1
	(MessageSwitch) id 1351160007736315_21578;
	Thu, 25 Oct 2012 10:13:27 +0000 (UTC)
Received: from AM1EHSMHS013.bigfish.com (unknown [10.3.201.235])	by
	mail91-am1.bigfish.com (Postfix) with ESMTP id A7EF418004A;
	Thu, 25 Oct 2012 10:13:27 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS013.bigfish.com (10.3.207.151) with Microsoft SMTP Server id
	14.1.225.23; Thu, 25 Oct 2012 10:13:23 +0000
X-WSS-ID: 0MCG1QA-01-AN1-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 247841028103;	Thu, 25 Oct 2012 05:13:21 -0500 (CDT)
Received: from SAUSEXDAG05.amd.com (163.181.55.6) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 25 Oct 2012 05:13:38 -0500
Received: from STOREXDAG04.amd.com (10.1.13.13) by sausexdag05.amd.com
	(163.181.55.6) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Thu, 25 Oct 2012 05:13:21 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag04.amd.com
	(10.1.13.13) with Microsoft SMTP Server id 14.2.318.4; Thu, 25 Oct 2012
	06:13:20 -0400
Message-ID: <508910BF.6030805@amd.com>
Date: Thu, 25 Oct 2012 12:13:19 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich 
References: <50782D4B.50607@amd.com>
	<5087F8B902000078000A3F38@nat28.tlf.novell.com>
	<5088F5BF.2090603@amd.com>
	<50891A8B02000078000A45C5@nat28.tlf.novell.com>
	<50890695.7040306@amd.com>
	<50892A7A02000078000A4627@nat28.tlf.novell.com>
In-Reply-To: <50892A7A02000078000A4627@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] x86/MCE: Implement clearbank callback for
 AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/25/12 12:03, Jan Beulich wrote:
>>>> On 25.10.12 at 11:29, Christoph Egger  wrote:
>> On 10/25/12 10:55, Jan Beulich wrote:
>>>>>> On 25.10.12 at 10:18, Christoph Egger  wrote:
>>>> On 10/24/12 14:18, Jan Beulich wrote:
>>>>>>>> On 12.10.12 at 16:46, Christoph Egger  wrote:
>>>>>> +static int k8_need_clearbank_scan(enum mca_source who, uint64_t status)
>>>>>> +{
>>>>>> +	switch (who) {
>>>>>> +	case MCA_MCE_SCAN:
>>>>>> +	case MCA_MCE_HANDLER:
>>>>>> +		break;
>>>>>> +	default:
>>>>>> +		return 1;
>>>>>> +	}
>>>>>> +
>>>>>> +	/* For fatal error, it shouldn't be cleared so that sticky bank
>>>>>> +	 * have chance to be handled after reboot by polling.
>>>>>> +	 */
>>>>>> +	if ( (status & MCi_STATUS_UC) && (status & MCi_STATUS_PCC) )
>>>>>> +		return 0;
>>>>>> +	/* Spurious need clear bank */
>>>>>> +	if ( !(status & MCi_STATUS_OVER)
>>>>>> +	    && (status & MCi_STATUS_UC) && !(status & MCi_STATUS_EN))
>>>>>> +		return 1;
>>>>>> +
>>>>>> +	return 1;
>>>>>> }
>>>>>
>>>>> So what's the purpose of first conditionally returning 1, and then
>>>>> also doing so unconditionally? Do anticipate to insert code between
>>>>> the two parts within the very near future? Otherwise I'd drop the
>>>>> whole if() construct.
>>>>
>>>> This function is derived from  intel_need_clearbank_scan().
>>>> I just took over the relevant parts for AMD.
>>>
>>> But that would suggest that the final return be "return 0" rather
>>> than "return 1".
>>>
>>> Further, the Intel code does no extra checking for the
>>> MCA_MCE_HANDLER case, so I'd like you to confirm that this is
>>> indeed to be different for your CPUs.
>>
>> I just noticed that MCA_MCE_HANDLER is not used at all and can be
>> removed entirely.
> 
> Will do.

Ok, thanks.

> But how about the "return" related question above?

I just run some tests.
Remove this part:

> +	/* Spurious need clear bank */
> +	if ( !(status & MCi_STATUS_OVER)
> +	    && (status & MCi_STATUS_UC) && !(status & MCi_STATUS_EN))
> +		return 1;

Christoph

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 10:13:50 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 10:13:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRKRS-0006Kc-1k; Thu, 25 Oct 2012 10:13:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRKRP-0006KX-Vu
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 10:13:32 +0000
Received: from [85.158.139.211:56175] by server-12.bemta-5.messagelabs.com id
	05/55-26919-BC019805; Thu, 25 Oct 2012 10:13:31 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1351160010!23682683!1
X-Originating-IP: [213.199.154.204]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20591 invoked from network); 25 Oct 2012 10:13:30 -0000
Received: from am1ehsobe001.messaging.microsoft.com (HELO
	am1outboundpool.messaging.microsoft.com) (213.199.154.204)
	by server-11.tower-206.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Oct 2012 10:13:30 -0000
Received: from mail91-am1-R.bigfish.com (10.3.201.225) by
	AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id
	14.1.225.23; Thu, 25 Oct 2012 10:13:30 +0000
Received: from mail91-am1 (localhost [127.0.0.1])	by mail91-am1-R.bigfish.com
	(Postfix) with ESMTP id 3BF1B601EE;
	Thu, 25 Oct 2012 10:13:30 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: -3
X-BigFish: VPS-3(zzbb2dI98dI1432Izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h)
Received: from mail91-am1 (localhost.localdomain [127.0.0.1]) by mail91-am1
	(MessageSwitch) id 1351160007736315_21578;
	Thu, 25 Oct 2012 10:13:27 +0000 (UTC)
Received: from AM1EHSMHS013.bigfish.com (unknown [10.3.201.235])	by
	mail91-am1.bigfish.com (Postfix) with ESMTP id A7EF418004A;
	Thu, 25 Oct 2012 10:13:27 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS013.bigfish.com (10.3.207.151) with Microsoft SMTP Server id
	14.1.225.23; Thu, 25 Oct 2012 10:13:23 +0000
X-WSS-ID: 0MCG1QA-01-AN1-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 247841028103;	Thu, 25 Oct 2012 05:13:21 -0500 (CDT)
Received: from SAUSEXDAG05.amd.com (163.181.55.6) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 25 Oct 2012 05:13:38 -0500
Received: from STOREXDAG04.amd.com (10.1.13.13) by sausexdag05.amd.com
	(163.181.55.6) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Thu, 25 Oct 2012 05:13:21 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag04.amd.com
	(10.1.13.13) with Microsoft SMTP Server id 14.2.318.4; Thu, 25 Oct 2012
	06:13:20 -0400
Message-ID: <508910BF.6030805@amd.com>
Date: Thu, 25 Oct 2012 12:13:19 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich 
References: <50782D4B.50607@amd.com>
	<5087F8B902000078000A3F38@nat28.tlf.novell.com>
	<5088F5BF.2090603@amd.com>
	<50891A8B02000078000A45C5@nat28.tlf.novell.com>
	<50890695.7040306@amd.com>
	<50892A7A02000078000A4627@nat28.tlf.novell.com>
In-Reply-To: <50892A7A02000078000A4627@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] x86/MCE: Implement clearbank callback for
 AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/25/12 12:03, Jan Beulich wrote:
>>>> On 25.10.12 at 11:29, Christoph Egger  wrote:
>> On 10/25/12 10:55, Jan Beulich wrote:
>>>>>> On 25.10.12 at 10:18, Christoph Egger  wrote:
>>>> On 10/24/12 14:18, Jan Beulich wrote:
>>>>>>>> On 12.10.12 at 16:46, Christoph Egger  wrote:
>>>>>> +static int k8_need_clearbank_scan(enum mca_source who, uint64_t status)
>>>>>> +{
>>>>>> +	switch (who) {
>>>>>> +	case MCA_MCE_SCAN:
>>>>>> +	case MCA_MCE_HANDLER:
>>>>>> +		break;
>>>>>> +	default:
>>>>>> +		return 1;
>>>>>> +	}
>>>>>> +
>>>>>> +	/* For fatal error, it shouldn't be cleared so that sticky bank
>>>>>> +	 * have chance to be handled after reboot by polling.
>>>>>> +	 */
>>>>>> +	if ( (status & MCi_STATUS_UC) && (status & MCi_STATUS_PCC) )
>>>>>> +		return 0;
>>>>>> +	/* Spurious need clear bank */
>>>>>> +	if ( !(status & MCi_STATUS_OVER)
>>>>>> +	    && (status & MCi_STATUS_UC) && !(status & MCi_STATUS_EN))
>>>>>> +		return 1;
>>>>>> +
>>>>>> +	return 1;
>>>>>> }
>>>>>
>>>>> So what's the purpose of first conditionally returning 1, and then
>>>>> also doing so unconditionally? Do anticipate to insert code between
>>>>> the two parts within the very near future? Otherwise I'd drop the
>>>>> whole if() construct.
>>>>
>>>> This function is derived from  intel_need_clearbank_scan().
>>>> I just took over the relevant parts for AMD.
>>>
>>> But that would suggest that the final return be "return 0" rather
>>> than "return 1".
>>>
>>> Further, the Intel code does no extra checking for the
>>> MCA_MCE_HANDLER case, so I'd like you to confirm that this is
>>> indeed to be different for your CPUs.
>>
>> I just noticed that MCA_MCE_HANDLER is not used at all and can be
>> removed entirely.
> 
> Will do.

Ok, thanks.

> But how about the "return" related question above?

I just run some tests.
Remove this part:

> +	/* Spurious need clear bank */
> +	if ( !(status & MCi_STATUS_OVER)
> +	    && (status & MCi_STATUS_UC) && !(status & MCi_STATUS_EN))
> +		return 1;

Christoph

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 10:24:39 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 10:24:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRKbq-0006U5-7X; Thu, 25 Oct 2012 10:24:18 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRKbo-0006U0-LB
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 10:24:16 +0000
Received: from [193.109.254.147:53239] by server-16.bemta-14.messagelabs.com
	id 11/85-09215-E4319805; Thu, 25 Oct 2012 10:24:14 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1351160651!14548112!1
X-Originating-IP: [216.32.180.184]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19536 invoked from network); 25 Oct 2012 10:24:12 -0000
Received: from co1ehsobe001.messaging.microsoft.com (HELO
	co1outboundpool.messaging.microsoft.com) (216.32.180.184)
	by server-16.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Oct 2012 10:24:12 -0000
Received: from mail56-co1-R.bigfish.com (10.243.78.238) by
	CO1EHSOBE002.bigfish.com (10.243.66.65) with Microsoft SMTP Server id
	14.1.225.23; Thu, 25 Oct 2012 10:24:10 +0000
Received: from mail56-co1 (localhost [127.0.0.1])	by mail56-co1-R.bigfish.com
	(Postfix) with ESMTP id 50AD4B00088;
	Thu, 25 Oct 2012 10:24:10 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: -3
X-BigFish: VPS-3(zzbb2dI98dI1432Izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h)
Received: from mail56-co1 (localhost.localdomain [127.0.0.1]) by mail56-co1
	(MessageSwitch) id 1351160647938090_12819;
	Thu, 25 Oct 2012 10:24:07 +0000 (UTC)
Received: from CO1EHSMHS023.bigfish.com (unknown [10.243.78.231])	by
	mail56-co1.bigfish.com (Postfix) with ESMTP id D77D63C0062;
	Thu, 25 Oct 2012 10:24:07 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CO1EHSMHS023.bigfish.com (10.243.66.33) with Microsoft SMTP Server id
	14.1.225.23; Thu, 25 Oct 2012 10:24:05 +0000
X-WSS-ID: 0MCG283-01-B6E-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 270F010280FD;	Thu, 25 Oct 2012 05:24:02 -0500 (CDT)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 25 Oct 2012 05:24:18 -0500
Received: from STOREXDAG03.amd.com (10.1.13.12) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Thu, 25 Oct 2012 05:24:02 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag03.amd.com
	(10.1.13.12) with Microsoft SMTP Server id 14.2.318.4; Thu, 25 Oct 2012
	06:24:01 -0400
Message-ID: <5089133F.2050203@amd.com>
Date: Thu, 25 Oct 2012 12:23:59 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich 
References: <50782D4B.50607@amd.com>
	<5087F8B902000078000A3F38@nat28.tlf.novell.com>
	<5088F5BF.2090603@amd.com>
	<50891A8B02000078000A45C5@nat28.tlf.novell.com>
	<50890695.7040306@amd.com>
	<50892A7A02000078000A4627@nat28.tlf.novell.com>
	<508910BF.6030805@amd.com>
In-Reply-To: <508910BF.6030805@amd.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] x86/MCE: Implement clearbank callback for
 AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/25/12 12:13, Christoph Egger wrote:
> On 10/25/12 12:03, Jan Beulich wrote:
>>>>> On 25.10.12 at 11:29, Christoph Egger  wrote:
>>> On 10/25/12 10:55, Jan Beulich wrote:
>>>>>>> On 25.10.12 at 10:18, Christoph Egger  wrote:
>>>>> On 10/24/12 14:18, Jan Beulich wrote:
>>>>>>>>> On 12.10.12 at 16:46, Christoph Egger  wrote:
>>>>>>> +static int k8_need_clearbank_scan(enum mca_source who, uint64_t status)
>>>>>>> +{
>>>>>>> +	switch (who) {
>>>>>>> +	case MCA_MCE_SCAN:
>>>>>>> +	case MCA_MCE_HANDLER:
>>>>>>> +		break;
>>>>>>> +	default:
>>>>>>> +		return 1;
>>>>>>> +	}
>>>>>>> +
>>>>>>> +	/* For fatal error, it shouldn't be cleared so that sticky bank
>>>>>>> +	 * have chance to be handled after reboot by polling.
>>>>>>> +	 */
>>>>>>> +	if ( (status & MCi_STATUS_UC) && (status & MCi_STATUS_PCC) )
>>>>>>> +		return 0;
>>>>>>> +	/* Spurious need clear bank */
>>>>>>> +	if ( !(status & MCi_STATUS_OVER)
>>>>>>> +	    && (status & MCi_STATUS_UC) && !(status & MCi_STATUS_EN))
>>>>>>> +		return 1;
>>>>>>> +
>>>>>>> +	return 1;
>>>>>>> }
>>>>>>
>>>>>> So what's the purpose of first conditionally returning 1, and then
>>>>>> also doing so unconditionally? Do anticipate to insert code between
>>>>>> the two parts within the very near future? Otherwise I'd drop the
>>>>>> whole if() construct.
>>>>>
>>>>> This function is derived from  intel_need_clearbank_scan().
>>>>> I just took over the relevant parts for AMD.
>>>>
>>>> But that would suggest that the final return be "return 0" rather
>>>> than "return 1".
>>>>
>>>> Further, the Intel code does no extra checking for the
>>>> MCA_MCE_HANDLER case, so I'd like you to confirm that this is
>>>> indeed to be different for your CPUs.
>>>
>>> I just noticed that MCA_MCE_HANDLER is not used at all and can be
>>> removed entirely.
>>
>> Will do.
> 
> Ok, thanks.
> 
>> But how about the "return" related question above?
> 
> I just run some tests.
> Remove this part:
> 
>> +	/* Spurious need clear bank */
>> +	if ( !(status & MCi_STATUS_OVER)
>> +	    && (status & MCi_STATUS_UC) && !(status & MCi_STATUS_EN))
>> +		return 1;
> 

And I changed the switch (who) to:

   if (who != MCA_MCE_SCAN)
       return 1;

Christoph



-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 10:24:39 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 10:24:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRKbq-0006U5-7X; Thu, 25 Oct 2012 10:24:18 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRKbo-0006U0-LB
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 10:24:16 +0000
Received: from [193.109.254.147:53239] by server-16.bemta-14.messagelabs.com
	id 11/85-09215-E4319805; Thu, 25 Oct 2012 10:24:14 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1351160651!14548112!1
X-Originating-IP: [216.32.180.184]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19536 invoked from network); 25 Oct 2012 10:24:12 -0000
Received: from co1ehsobe001.messaging.microsoft.com (HELO
	co1outboundpool.messaging.microsoft.com) (216.32.180.184)
	by server-16.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Oct 2012 10:24:12 -0000
Received: from mail56-co1-R.bigfish.com (10.243.78.238) by
	CO1EHSOBE002.bigfish.com (10.243.66.65) with Microsoft SMTP Server id
	14.1.225.23; Thu, 25 Oct 2012 10:24:10 +0000
Received: from mail56-co1 (localhost [127.0.0.1])	by mail56-co1-R.bigfish.com
	(Postfix) with ESMTP id 50AD4B00088;
	Thu, 25 Oct 2012 10:24:10 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: -3
X-BigFish: VPS-3(zzbb2dI98dI1432Izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h)
Received: from mail56-co1 (localhost.localdomain [127.0.0.1]) by mail56-co1
	(MessageSwitch) id 1351160647938090_12819;
	Thu, 25 Oct 2012 10:24:07 +0000 (UTC)
Received: from CO1EHSMHS023.bigfish.com (unknown [10.243.78.231])	by
	mail56-co1.bigfish.com (Postfix) with ESMTP id D77D63C0062;
	Thu, 25 Oct 2012 10:24:07 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CO1EHSMHS023.bigfish.com (10.243.66.33) with Microsoft SMTP Server id
	14.1.225.23; Thu, 25 Oct 2012 10:24:05 +0000
X-WSS-ID: 0MCG283-01-B6E-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 270F010280FD;	Thu, 25 Oct 2012 05:24:02 -0500 (CDT)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 25 Oct 2012 05:24:18 -0500
Received: from STOREXDAG03.amd.com (10.1.13.12) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Thu, 25 Oct 2012 05:24:02 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag03.amd.com
	(10.1.13.12) with Microsoft SMTP Server id 14.2.318.4; Thu, 25 Oct 2012
	06:24:01 -0400
Message-ID: <5089133F.2050203@amd.com>
Date: Thu, 25 Oct 2012 12:23:59 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich 
References: <50782D4B.50607@amd.com>
	<5087F8B902000078000A3F38@nat28.tlf.novell.com>
	<5088F5BF.2090603@amd.com>
	<50891A8B02000078000A45C5@nat28.tlf.novell.com>
	<50890695.7040306@amd.com>
	<50892A7A02000078000A4627@nat28.tlf.novell.com>
	<508910BF.6030805@amd.com>
In-Reply-To: <508910BF.6030805@amd.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] x86/MCE: Implement clearbank callback for
 AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/25/12 12:13, Christoph Egger wrote:
> On 10/25/12 12:03, Jan Beulich wrote:
>>>>> On 25.10.12 at 11:29, Christoph Egger  wrote:
>>> On 10/25/12 10:55, Jan Beulich wrote:
>>>>>>> On 25.10.12 at 10:18, Christoph Egger  wrote:
>>>>> On 10/24/12 14:18, Jan Beulich wrote:
>>>>>>>>> On 12.10.12 at 16:46, Christoph Egger  wrote:
>>>>>>> +static int k8_need_clearbank_scan(enum mca_source who, uint64_t status)
>>>>>>> +{
>>>>>>> +	switch (who) {
>>>>>>> +	case MCA_MCE_SCAN:
>>>>>>> +	case MCA_MCE_HANDLER:
>>>>>>> +		break;
>>>>>>> +	default:
>>>>>>> +		return 1;
>>>>>>> +	}
>>>>>>> +
>>>>>>> +	/* For fatal error, it shouldn't be cleared so that sticky bank
>>>>>>> +	 * have chance to be handled after reboot by polling.
>>>>>>> +	 */
>>>>>>> +	if ( (status & MCi_STATUS_UC) && (status & MCi_STATUS_PCC) )
>>>>>>> +		return 0;
>>>>>>> +	/* Spurious need clear bank */
>>>>>>> +	if ( !(status & MCi_STATUS_OVER)
>>>>>>> +	    && (status & MCi_STATUS_UC) && !(status & MCi_STATUS_EN))
>>>>>>> +		return 1;
>>>>>>> +
>>>>>>> +	return 1;
>>>>>>> }
>>>>>>
>>>>>> So what's the purpose of first conditionally returning 1, and then
>>>>>> also doing so unconditionally? Do anticipate to insert code between
>>>>>> the two parts within the very near future? Otherwise I'd drop the
>>>>>> whole if() construct.
>>>>>
>>>>> This function is derived from  intel_need_clearbank_scan().
>>>>> I just took over the relevant parts for AMD.
>>>>
>>>> But that would suggest that the final return be "return 0" rather
>>>> than "return 1".
>>>>
>>>> Further, the Intel code does no extra checking for the
>>>> MCA_MCE_HANDLER case, so I'd like you to confirm that this is
>>>> indeed to be different for your CPUs.
>>>
>>> I just noticed that MCA_MCE_HANDLER is not used at all and can be
>>> removed entirely.
>>
>> Will do.
> 
> Ok, thanks.
> 
>> But how about the "return" related question above?
> 
> I just run some tests.
> Remove this part:
> 
>> +	/* Spurious need clear bank */
>> +	if ( !(status & MCi_STATUS_OVER)
>> +	    && (status & MCi_STATUS_UC) && !(status & MCi_STATUS_EN))
>> +		return 1;
> 

And I changed the switch (who) to:

   if (who != MCA_MCE_SCAN)
       return 1;

Christoph



-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 10:29:13 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 10:29:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRKgM-0006c1-VU; Thu, 25 Oct 2012 10:28:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRKgL-0006bu-Rj
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 10:28:57 +0000
Received: from [85.158.137.99:61471] by server-10.bemta-3.messagelabs.com id
	8C/D2-00901-76419805; Thu, 25 Oct 2012 10:28:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1351160935!20614542!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30579 invoked from network); 25 Oct 2012 10:28:55 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-217.messagelabs.com with SMTP;
	25 Oct 2012 10:28:55 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 25 Oct 2012 11:28:56 +0100
Message-Id: <5089308402000078000A4661@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 25 Oct 2012 11:28:52 +0100
From: "Jan Beulich" 
To: "Christoph Egger" 
References: <50782D4B.50607@amd.com>
	<5087F8B902000078000A3F38@nat28.tlf.novell.com>
	<5088F5BF.2090603@amd.com>
	<50891A8B02000078000A45C5@nat28.tlf.novell.com>
	<50890695.7040306@amd.com>
	<50892A7A02000078000A4627@nat28.tlf.novell.com>
	<508910BF.6030805@amd.com> <5089133F.2050203@amd.com>
In-Reply-To: <5089133F.2050203@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] x86/MCE: Implement clearbank callback for
 AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 25.10.12 at 12:23, Christoph Egger  wrote:
> And I changed the switch (who) to:
> 
>    if (who != MCA_MCE_SCAN)
>        return 1;

That's what I did too.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 10:29:13 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 10:29:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRKgM-0006c1-VU; Thu, 25 Oct 2012 10:28:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRKgL-0006bu-Rj
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 10:28:57 +0000
Received: from [85.158.137.99:61471] by server-10.bemta-3.messagelabs.com id
	8C/D2-00901-76419805; Thu, 25 Oct 2012 10:28:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1351160935!20614542!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30579 invoked from network); 25 Oct 2012 10:28:55 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-217.messagelabs.com with SMTP;
	25 Oct 2012 10:28:55 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 25 Oct 2012 11:28:56 +0100
Message-Id: <5089308402000078000A4661@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 25 Oct 2012 11:28:52 +0100
From: "Jan Beulich" 
To: "Christoph Egger" 
References: <50782D4B.50607@amd.com>
	<5087F8B902000078000A3F38@nat28.tlf.novell.com>
	<5088F5BF.2090603@amd.com>
	<50891A8B02000078000A45C5@nat28.tlf.novell.com>
	<50890695.7040306@amd.com>
	<50892A7A02000078000A4627@nat28.tlf.novell.com>
	<508910BF.6030805@amd.com> <5089133F.2050203@amd.com>
In-Reply-To: <5089133F.2050203@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] x86/MCE: Implement clearbank callback for
 AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 25.10.12 at 12:23, Christoph Egger  wrote:
> And I changed the switch (who) to:
> 
>    if (who != MCA_MCE_SCAN)
>        return 1;

That's what I did too.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 10:31:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 10:31:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRKiK-0006iL-G4; Thu, 25 Oct 2012 10:31:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRKiI-0006iF-D9
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 10:30:58 +0000
Received: from [193.109.254.147:41534] by server-8.bemta-14.messagelabs.com id
	66/40-16549-1E419805; Thu, 25 Oct 2012 10:30:57 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1351161055!13994794!1
X-Originating-IP: [216.32.181.184]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25101 invoked from network); 25 Oct 2012 10:30:57 -0000
Received: from ch1ehsobe004.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.184)
	by server-3.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Oct 2012 10:30:57 -0000
Received: from mail159-ch1-R.bigfish.com (10.43.68.229) by
	CH1EHSOBE015.bigfish.com (10.43.70.65) with Microsoft SMTP Server id
	14.1.225.23; Thu, 25 Oct 2012 10:30:55 +0000
Received: from mail159-ch1 (localhost [127.0.0.1])	by
	mail159-ch1-R.bigfish.com (Postfix) with ESMTP id 6F9EA44030A;
	Thu, 25 Oct 2012 10:30:55 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: -3
X-BigFish: VPS-3(zzbb2dI98dI1432Izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h)
Received: from mail159-ch1 (localhost.localdomain [127.0.0.1]) by mail159-ch1
	(MessageSwitch) id 1351161052795703_26647;
	Thu, 25 Oct 2012 10:30:52 +0000 (UTC)
Received: from CH1EHSMHS027.bigfish.com (snatpool2.int.messaging.microsoft.com
	[10.43.68.238])	by mail159-ch1.bigfish.com (Postfix) with ESMTP id
	BF1F52000F8;	Thu, 25 Oct 2012 10:30:52 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS027.bigfish.com (10.43.70.27) with Microsoft SMTP Server id
	14.1.225.23; Thu, 25 Oct 2012 10:30:49 +0000
X-WSS-ID: 0MCG2JC-01-BH7-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2855F1028098;	Thu, 25 Oct 2012 05:30:47 -0500 (CDT)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 25 Oct 2012 05:31:03 -0500
Received: from STOREXDAG02.amd.com (10.1.13.11) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Thu, 25 Oct 2012 05:30:47 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag02.amd.com
	(10.1.13.11) with Microsoft SMTP Server id 14.2.318.4; Thu, 25 Oct 2012
	06:30:46 -0400
Message-ID: <508914D5.8010009@amd.com>
Date: Thu, 25 Oct 2012 12:30:45 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich 
References: <50782D4B.50607@amd.com>
	<5087F8B902000078000A3F38@nat28.tlf.novell.com>
	<5088F5BF.2090603@amd.com>
	<50891A8B02000078000A45C5@nat28.tlf.novell.com>
	<50890695.7040306@amd.com>
	<50892A7A02000078000A4627@nat28.tlf.novell.com>
	<508910BF.6030805@amd.com> <5089133F.2050203@amd.com>
	<5089308402000078000A4661@nat28.tlf.novell.com>
In-Reply-To: <5089308402000078000A4661@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] x86/MCE: Implement clearbank callback for
 AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/25/12 12:28, Jan Beulich wrote:
>>>> On 25.10.12 at 12:23, Christoph Egger  wrote:
>> And I changed the switch (who) to:
>>
>>    if (who != MCA_MCE_SCAN)
>>        return 1;
> 
> That's what I did too.

Thanks.

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 10:31:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 10:31:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRKiK-0006iL-G4; Thu, 25 Oct 2012 10:31:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRKiI-0006iF-D9
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 10:30:58 +0000
Received: from [193.109.254.147:41534] by server-8.bemta-14.messagelabs.com id
	66/40-16549-1E419805; Thu, 25 Oct 2012 10:30:57 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1351161055!13994794!1
X-Originating-IP: [216.32.181.184]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25101 invoked from network); 25 Oct 2012 10:30:57 -0000
Received: from ch1ehsobe004.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.184)
	by server-3.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Oct 2012 10:30:57 -0000
Received: from mail159-ch1-R.bigfish.com (10.43.68.229) by
	CH1EHSOBE015.bigfish.com (10.43.70.65) with Microsoft SMTP Server id
	14.1.225.23; Thu, 25 Oct 2012 10:30:55 +0000
Received: from mail159-ch1 (localhost [127.0.0.1])	by
	mail159-ch1-R.bigfish.com (Postfix) with ESMTP id 6F9EA44030A;
	Thu, 25 Oct 2012 10:30:55 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: -3
X-BigFish: VPS-3(zzbb2dI98dI1432Izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h)
Received: from mail159-ch1 (localhost.localdomain [127.0.0.1]) by mail159-ch1
	(MessageSwitch) id 1351161052795703_26647;
	Thu, 25 Oct 2012 10:30:52 +0000 (UTC)
Received: from CH1EHSMHS027.bigfish.com (snatpool2.int.messaging.microsoft.com
	[10.43.68.238])	by mail159-ch1.bigfish.com (Postfix) with ESMTP id
	BF1F52000F8;	Thu, 25 Oct 2012 10:30:52 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS027.bigfish.com (10.43.70.27) with Microsoft SMTP Server id
	14.1.225.23; Thu, 25 Oct 2012 10:30:49 +0000
X-WSS-ID: 0MCG2JC-01-BH7-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2855F1028098;	Thu, 25 Oct 2012 05:30:47 -0500 (CDT)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 25 Oct 2012 05:31:03 -0500
Received: from STOREXDAG02.amd.com (10.1.13.11) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Thu, 25 Oct 2012 05:30:47 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag02.amd.com
	(10.1.13.11) with Microsoft SMTP Server id 14.2.318.4; Thu, 25 Oct 2012
	06:30:46 -0400
Message-ID: <508914D5.8010009@amd.com>
Date: Thu, 25 Oct 2012 12:30:45 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich 
References: <50782D4B.50607@amd.com>
	<5087F8B902000078000A3F38@nat28.tlf.novell.com>
	<5088F5BF.2090603@amd.com>
	<50891A8B02000078000A45C5@nat28.tlf.novell.com>
	<50890695.7040306@amd.com>
	<50892A7A02000078000A4627@nat28.tlf.novell.com>
	<508910BF.6030805@amd.com> <5089133F.2050203@amd.com>
	<5089308402000078000A4661@nat28.tlf.novell.com>
In-Reply-To: <5089308402000078000A4661@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] x86/MCE: Implement clearbank callback for
 AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/25/12 12:28, Jan Beulich wrote:
>>>> On 25.10.12 at 12:23, Christoph Egger  wrote:
>> And I changed the switch (who) to:
>>
>>    if (who != MCA_MCE_SCAN)
>>        return 1;
> 
> That's what I did too.

Thanks.

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 10:40:26 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 10:40:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRKr1-0006yP-IU; Thu, 25 Oct 2012 10:39:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRKr0-0006yK-5b
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 10:39:58 +0000
Received: from [193.109.254.147:8295] by server-5.bemta-14.messagelabs.com id
	7A/11-18309-DF619805; Thu, 25 Oct 2012 10:39:57 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1351161530!14550077!1
X-Originating-IP: [65.55.88.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1294 invoked from network); 25 Oct 2012 10:38:51 -0000
Received: from tx2ehsobe003.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.13)
	by server-16.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Oct 2012 10:38:51 -0000
Received: from mail263-tx2-R.bigfish.com (10.9.14.247) by
	TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id
	14.1.225.23; Thu, 25 Oct 2012 10:38:50 +0000
Received: from mail263-tx2 (localhost [127.0.0.1])	by
	mail263-tx2-R.bigfish.com (Postfix) with ESMTP id 10140E80150	for
	; Thu, 25 Oct 2012 10:38:50 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzc85fhc85dhzz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh34h1155h)
Received: from mail263-tx2 (localhost.localdomain [127.0.0.1]) by mail263-tx2
	(MessageSwitch) id 1351161527545728_23116;
	Thu, 25 Oct 2012 10:38:47 +0000 (UTC)
Received: from TX2EHSMHS029.bigfish.com (unknown [10.9.14.235])	by
	mail263-tx2.bigfish.com (Postfix) with ESMTP id 83444700065	for
	; Thu, 25 Oct 2012 10:38:47 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS029.bigfish.com (10.9.99.129) with Microsoft SMTP Server id
	14.1.225.23; Thu, 25 Oct 2012 10:38:47 +0000
X-WSS-ID: 0MCG2WL-02-0KV-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 222D5C8056	for ; Thu, 25 Oct 2012
	05:38:45 -0500 (CDT)
Received: from SAUSEXDAG05.amd.com (163.181.55.6) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 25 Oct 2012 05:39:01 -0500
Received: from STOREXDAG03.amd.com (10.1.13.12) by sausexdag05.amd.com
	(163.181.55.6) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Thu, 25 Oct 2012 05:38:45 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag03.amd.com
	(10.1.13.12) with Microsoft SMTP Server id 14.2.318.4; Thu, 25 Oct 2012
	06:38:44 -0400
Message-ID: <508916B3.2030403@amd.com>
Date: Thu, 25 Oct 2012 12:38:43 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" 
Content-Type: multipart/mixed; boundary="------------010805020702090409040504"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] tools: use PREFIX when building upstream qemu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------010805020702090409040504
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit


use PREFIX when building upstream qemu.

Signed-off-by: Christoph Egger 

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------010805020702090409040504
Content-Type: text/plain; charset="us-ascii"; name="xen_qemu_prefix.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_qemu_prefix.diff"
Content-Description: xen_qemu_prefix.diff

diff -r 3d327e56bff2 -r 6b73078a4403 tools/Makefile
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -190,6 +190,7 @@ subdir-all-qemu-xen-dir: qemu-xen-dir-fi
 	fi; \
 	cd qemu-xen-dir; \
 	$$source/configure --enable-xen --target-list=i386-softmmu \
+		--prefix=$(PREFIX) \
 		--source-path=$$source \
 		--extra-cflags="-I$(XEN_ROOT)/tools/include \
 		-I$(XEN_ROOT)/tools/libxc \

--------------010805020702090409040504
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------010805020702090409040504--


From xen-devel-bounces@lists.xen.org Thu Oct 25 10:40:26 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 10:40:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRKr1-0006yP-IU; Thu, 25 Oct 2012 10:39:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRKr0-0006yK-5b
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 10:39:58 +0000
Received: from [193.109.254.147:8295] by server-5.bemta-14.messagelabs.com id
	7A/11-18309-DF619805; Thu, 25 Oct 2012 10:39:57 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1351161530!14550077!1
X-Originating-IP: [65.55.88.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1294 invoked from network); 25 Oct 2012 10:38:51 -0000
Received: from tx2ehsobe003.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.13)
	by server-16.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Oct 2012 10:38:51 -0000
Received: from mail263-tx2-R.bigfish.com (10.9.14.247) by
	TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id
	14.1.225.23; Thu, 25 Oct 2012 10:38:50 +0000
Received: from mail263-tx2 (localhost [127.0.0.1])	by
	mail263-tx2-R.bigfish.com (Postfix) with ESMTP id 10140E80150	for
	; Thu, 25 Oct 2012 10:38:50 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzc85fhc85dhzz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh34h1155h)
Received: from mail263-tx2 (localhost.localdomain [127.0.0.1]) by mail263-tx2
	(MessageSwitch) id 1351161527545728_23116;
	Thu, 25 Oct 2012 10:38:47 +0000 (UTC)
Received: from TX2EHSMHS029.bigfish.com (unknown [10.9.14.235])	by
	mail263-tx2.bigfish.com (Postfix) with ESMTP id 83444700065	for
	; Thu, 25 Oct 2012 10:38:47 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS029.bigfish.com (10.9.99.129) with Microsoft SMTP Server id
	14.1.225.23; Thu, 25 Oct 2012 10:38:47 +0000
X-WSS-ID: 0MCG2WL-02-0KV-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 222D5C8056	for ; Thu, 25 Oct 2012
	05:38:45 -0500 (CDT)
Received: from SAUSEXDAG05.amd.com (163.181.55.6) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 25 Oct 2012 05:39:01 -0500
Received: from STOREXDAG03.amd.com (10.1.13.12) by sausexdag05.amd.com
	(163.181.55.6) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Thu, 25 Oct 2012 05:38:45 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag03.amd.com
	(10.1.13.12) with Microsoft SMTP Server id 14.2.318.4; Thu, 25 Oct 2012
	06:38:44 -0400
Message-ID: <508916B3.2030403@amd.com>
Date: Thu, 25 Oct 2012 12:38:43 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" 
Content-Type: multipart/mixed; boundary="------------010805020702090409040504"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] tools: use PREFIX when building upstream qemu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------010805020702090409040504
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit


use PREFIX when building upstream qemu.

Signed-off-by: Christoph Egger 

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------010805020702090409040504
Content-Type: text/plain; charset="us-ascii"; name="xen_qemu_prefix.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_qemu_prefix.diff"
Content-Description: xen_qemu_prefix.diff

diff -r 3d327e56bff2 -r 6b73078a4403 tools/Makefile
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -190,6 +190,7 @@ subdir-all-qemu-xen-dir: qemu-xen-dir-fi
 	fi; \
 	cd qemu-xen-dir; \
 	$$source/configure --enable-xen --target-list=i386-softmmu \
+		--prefix=$(PREFIX) \
 		--source-path=$$source \
 		--extra-cflags="-I$(XEN_ROOT)/tools/include \
 		-I$(XEN_ROOT)/tools/libxc \

--------------010805020702090409040504
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------010805020702090409040504--


From xen-devel-bounces@lists.xen.org Thu Oct 25 10:49:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 10:49:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRKzt-00078D-KY; Thu, 25 Oct 2012 10:49:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRKzs-000788-0A
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 10:49:08 +0000
Received: from [85.158.137.99:64419] by server-8.bemta-3.messagelabs.com id
	DE/2E-10525-E1919805; Thu, 25 Oct 2012 10:49:02 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1351162140!23013459!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26156 invoked from network); 25 Oct 2012 10:49:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 10:49:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,646,1344211200"; d="scan'208";a="15384943"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 10:49:00 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 11:49:00 +0100
Date: Thu, 25 Oct 2012 11:48:30 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Jan Beulich 
In-Reply-To: <508906CE02000078000A4553@nat28.tlf.novell.com>
Message-ID: 
References: <20121024151957.28a1626cd9a59c014e78c401@canb.auug.org.au>
	<50885EA8.3050007@xenotime.net>
	<508906CE02000078000A4553@nat28.tlf.novell.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Stephen Rothwell ,
	Jeremy Fitzhardinge ,
	Konrad Rzeszutek Wilk ,
	"gregkh@linuxfoundation.org" ,
	Stefano Stabellini ,
	"linux-kernel@vger.kernel.org" ,
	"virtualization@lists.linux-foundation.org"
	,
	Randy Dunlap ,
	"linux-next@vger.kernel.org" ,
	xen-devel 
Subject: Re: [Xen-devel] linux-next: Tree for Oct 24 (xen)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 25 Oct 2012, Jan Beulich wrote:
> >>> On 24.10.12 at 23:33, Randy Dunlap  wrote:
> > On 10/23/2012 09:19 PM, Stephen Rothwell wrote:
> > 
> >> Hi all,
> >> 
> >> Changes since 201201023:
> >> 
> > 
> > on x86_64:
> > 
> > drivers/built-in.o: In function `dbgp_reset_prep':
> > (.text+0xb96b5): undefined reference to `xen_dbgp_reset_prep'
> > drivers/built-in.o: In function `dbgp_external_startup':
> > (.text+0xb9d95): undefined reference to `xen_dbgp_external_startup'
> > 
> > 
> > Full randconfig file is attached.
> 
> So this is because with !USB_SUPPORT but EARLY_PRINTK_DBGP
> dbgp_reset_prep() and dbgp_external_startup() get pointlessly
> defined and exported. This got broken by the merge
> recommendation for the ARM side changes (originally compilation
> of drivers/xen/dbgp.c depended on just CONFIG_XEN_DOM0).
> 
> >From my pov, fixing the USB side would be the clean solution (i.e.
> putting those function definitions inside a CONFIG_USB_SUPPORT
> conditional).
>
> The alternative of a smaller change would be to extend the
> conditional around the respective xen_dbgp_...() declarations
> in include/linux/usb/ehci_def.h to become
> 
> #if defined(CONFIG_XEN_DOM0) && defined(CONFIG_USB_SUPPORT)
> 
> Please advise towards your preference.

I think that your first suggestion is the right one.


Otherwise we could also make drivers/xen/dbgp.c compile if
CONFIG_EARLY_PRINTK_DBGP rather than CONFIG_USB_SUPPORT.
I think that it would create fewer maintenance pains if dbgp_reset_prep
and dbgp_external_startup had the same compile requirements as their xen
counterparts (aside from Xen support of course).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 10:49:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 10:49:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRKzt-00078D-KY; Thu, 25 Oct 2012 10:49:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRKzs-000788-0A
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 10:49:08 +0000
Received: from [85.158.137.99:64419] by server-8.bemta-3.messagelabs.com id
	DE/2E-10525-E1919805; Thu, 25 Oct 2012 10:49:02 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1351162140!23013459!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26156 invoked from network); 25 Oct 2012 10:49:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 10:49:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,646,1344211200"; d="scan'208";a="15384943"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 10:49:00 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 11:49:00 +0100
Date: Thu, 25 Oct 2012 11:48:30 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Jan Beulich 
In-Reply-To: <508906CE02000078000A4553@nat28.tlf.novell.com>
Message-ID: 
References: <20121024151957.28a1626cd9a59c014e78c401@canb.auug.org.au>
	<50885EA8.3050007@xenotime.net>
	<508906CE02000078000A4553@nat28.tlf.novell.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Stephen Rothwell ,
	Jeremy Fitzhardinge ,
	Konrad Rzeszutek Wilk ,
	"gregkh@linuxfoundation.org" ,
	Stefano Stabellini ,
	"linux-kernel@vger.kernel.org" ,
	"virtualization@lists.linux-foundation.org"
	,
	Randy Dunlap ,
	"linux-next@vger.kernel.org" ,
	xen-devel 
Subject: Re: [Xen-devel] linux-next: Tree for Oct 24 (xen)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 25 Oct 2012, Jan Beulich wrote:
> >>> On 24.10.12 at 23:33, Randy Dunlap  wrote:
> > On 10/23/2012 09:19 PM, Stephen Rothwell wrote:
> > 
> >> Hi all,
> >> 
> >> Changes since 201201023:
> >> 
> > 
> > on x86_64:
> > 
> > drivers/built-in.o: In function `dbgp_reset_prep':
> > (.text+0xb96b5): undefined reference to `xen_dbgp_reset_prep'
> > drivers/built-in.o: In function `dbgp_external_startup':
> > (.text+0xb9d95): undefined reference to `xen_dbgp_external_startup'
> > 
> > 
> > Full randconfig file is attached.
> 
> So this is because with !USB_SUPPORT but EARLY_PRINTK_DBGP
> dbgp_reset_prep() and dbgp_external_startup() get pointlessly
> defined and exported. This got broken by the merge
> recommendation for the ARM side changes (originally compilation
> of drivers/xen/dbgp.c depended on just CONFIG_XEN_DOM0).
> 
> >From my pov, fixing the USB side would be the clean solution (i.e.
> putting those function definitions inside a CONFIG_USB_SUPPORT
> conditional).
>
> The alternative of a smaller change would be to extend the
> conditional around the respective xen_dbgp_...() declarations
> in include/linux/usb/ehci_def.h to become
> 
> #if defined(CONFIG_XEN_DOM0) && defined(CONFIG_USB_SUPPORT)
> 
> Please advise towards your preference.

I think that your first suggestion is the right one.


Otherwise we could also make drivers/xen/dbgp.c compile if
CONFIG_EARLY_PRINTK_DBGP rather than CONFIG_USB_SUPPORT.
I think that it would create fewer maintenance pains if dbgp_reset_prep
and dbgp_external_startup had the same compile requirements as their xen
counterparts (aside from Xen support of course).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 10:58:34 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 10:58:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRL8f-0007Ja-RF; Thu, 25 Oct 2012 10:58:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRL8d-0007JS-TE
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 10:58:12 +0000
Received: from [85.158.138.51:31197] by server-15.bemta-3.messagelabs.com id
	6B/98-09445-24B19805; Thu, 25 Oct 2012 10:58:10 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1351162690!27381924!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32041 invoked from network); 25 Oct 2012 10:58:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 10:58:10 -0000
X-IronPort-AV: E=Sophos;i="4.80,646,1344211200"; d="scan'208";a="15385126"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 10:58:07 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 11:58:07 +0100
Date: Thu, 25 Oct 2012 11:57:36 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1351157839.18035.135.camel@zakaz.uk.xensource.com>
Message-ID: 
References: 
	<1351091027-20740-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<1351157839.18035.135.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" , "Tim
	\(Xen.org\)" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 3/7] pl011: set baud and clock_hz to the
 right defaults for Versatile Express
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 25 Oct 2012, Ian Campbell wrote:
> Can we get these (or at least the clock_hz) from DTB?

Unfortunately we cannot.


> On Wed, 2012-10-24 at 16:03 +0100, Stefano Stabellini wrote:
> > Signed-off-by: Stefano Stabellini 
> > ---
> >  xen/drivers/char/pl011.c |    4 ++--
> >  1 files changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c
> > index 6af45aa..6ccb73a 100644
> > --- a/xen/drivers/char/pl011.c
> > +++ b/xen/drivers/char/pl011.c
> > @@ -241,8 +241,8 @@ void __init pl011_init(int index, unsigned long register_base_address)
> >  
> >      uart = &pl011_com[index];
> >  
> > -    uart->clock_hz  = 7372800;
> > -    uart->baud      = 115200;
> > +    uart->clock_hz  = 0x16e3600;
> > +    uart->baud      = 38400;
> >      uart->data_bits = 8;
> >      uart->parity    = PARITY_NONE;
> >      uart->stop_bits = 1;
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 10:58:34 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 10:58:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRL8f-0007Ja-RF; Thu, 25 Oct 2012 10:58:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRL8d-0007JS-TE
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 10:58:12 +0000
Received: from [85.158.138.51:31197] by server-15.bemta-3.messagelabs.com id
	6B/98-09445-24B19805; Thu, 25 Oct 2012 10:58:10 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1351162690!27381924!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32041 invoked from network); 25 Oct 2012 10:58:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 10:58:10 -0000
X-IronPort-AV: E=Sophos;i="4.80,646,1344211200"; d="scan'208";a="15385126"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 10:58:07 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 11:58:07 +0100
Date: Thu, 25 Oct 2012 11:57:36 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1351157839.18035.135.camel@zakaz.uk.xensource.com>
Message-ID: 
References: 
	<1351091027-20740-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<1351157839.18035.135.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" , "Tim
	\(Xen.org\)" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 3/7] pl011: set baud and clock_hz to the
 right defaults for Versatile Express
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 25 Oct 2012, Ian Campbell wrote:
> Can we get these (or at least the clock_hz) from DTB?

Unfortunately we cannot.


> On Wed, 2012-10-24 at 16:03 +0100, Stefano Stabellini wrote:
> > Signed-off-by: Stefano Stabellini 
> > ---
> >  xen/drivers/char/pl011.c |    4 ++--
> >  1 files changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c
> > index 6af45aa..6ccb73a 100644
> > --- a/xen/drivers/char/pl011.c
> > +++ b/xen/drivers/char/pl011.c
> > @@ -241,8 +241,8 @@ void __init pl011_init(int index, unsigned long register_base_address)
> >  
> >      uart = &pl011_com[index];
> >  
> > -    uart->clock_hz  = 7372800;
> > -    uart->baud      = 115200;
> > +    uart->clock_hz  = 0x16e3600;
> > +    uart->baud      = 38400;
> >      uart->data_bits = 8;
> >      uart->parity    = PARITY_NONE;
> >      uart->stop_bits = 1;
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 11:01:00 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 11:01:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRLB8-0007Qx-CO; Thu, 25 Oct 2012 11:00:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRLB6-0007Qp-C3
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 11:00:44 +0000
Received: from [85.158.138.51:48742] by server-9.bemta-3.messagelabs.com id
	C7/DB-16841-BDB19805; Thu, 25 Oct 2012 11:00:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1351162839!19438635!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16021 invoked from network); 25 Oct 2012 11:00:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 11:00:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,646,1344211200"; d="scan'208";a="15385206"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 11:00:39 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 12:00:40 +0100
Date: Thu, 25 Oct 2012 12:00:09 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1351157606.18035.133.camel@zakaz.uk.xensource.com>
Message-ID: 
References: 
	<1351091027-20740-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<1351157606.18035.133.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" , "Tim
	\(Xen.org\)" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 2/7] xen/arm: setup the fixmap in head.S
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 25 Oct 2012, Ian Campbell wrote:
> On Wed, 2012-10-24 at 16:03 +0100, Stefano Stabellini wrote:
> > @@ -183,6 +184,16 @@ skip_bss:
> >         teq   r12, #0
> >         bne   pt_ready
> >         
> > +       /* console fixmap */
> > +       ldr   r1, =xen_fixmap
> > +       add   r1, r1, r10            /* r1 := paddr (xen_fixmap) */
> > +       mov   r3, #0
> > +       lsr   r2, r11, #12
> > +       lsl   r2, r2, #12            /* 4K aligned paddr of UART */
> > +       orr   r2, r2, #PT_UPPER(DEV_L3)
> > +       orr   r2, r2, #PT_LOWER(DEV_L3) /* r2:r3 := 4K dev map including UART */
> > +       strd  r2, r3, [r1, #0]       /* Map it in the first fixmap's slot */
> > +       
> >         /* Build the baseline idle pagetable's first-level entries */
> >         ldr   r1, =xen_second
> >         add   r1, r1, r10            /* r1 := paddr (xen_second) */
> [...]
> > @@ -205,12 +216,13 @@ skip_bss:
> >  	ldr   r4, =start
> >  	lsr   r4, #18                /* Slot for vaddr(start) */
> >  	strd  r2, r3, [r1, r4]       /* Map Xen there too */
> > +
> >  #ifdef EARLY_UART_ADDRESS
> > -	ldr   r3, =(1<<(54-32))      /* NS for device mapping */
> > -	lsr   r2, r11, #21
> > -	lsl   r2, r2, #21            /* 2MB-aligned paddr of UART */
> > -	orr   r2, r2, #PT_UPPER(DEV)
> > -	orr   r2, r2, #PT_LOWER(DEV) /* r2:r3 := 2MB dev map including UART */
> > +	/* xen_fixmap pagetable */
> > +	ldr r2, =xen_fixmap
> > +	add r2, r2, r10
> > +	orr   r2, r2, #PT_UPPER(PT)
> > +	orr   r2, r2, #PT_LOWER(PT) /* r2:r3 := paddr (xen_fixmap) */
> 
> We should setup the fixmap infrastructure even if !EARLY_UART_ADDRESS,
> unless we set it up again later?
> 
> As it stands it looks like you setup the generic fixmap mapping iff
> EARLY_UART_ADDRESS (second hunk above) but setup the UART mapping within
> that unconditionally (first hunk) which is exactly backwards, isn't it ?

Yes, you are right, they should be inverted.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 11:01:00 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 11:01:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRLB8-0007Qx-CO; Thu, 25 Oct 2012 11:00:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRLB6-0007Qp-C3
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 11:00:44 +0000
Received: from [85.158.138.51:48742] by server-9.bemta-3.messagelabs.com id
	C7/DB-16841-BDB19805; Thu, 25 Oct 2012 11:00:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1351162839!19438635!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16021 invoked from network); 25 Oct 2012 11:00:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 11:00:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,646,1344211200"; d="scan'208";a="15385206"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 11:00:39 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 12:00:40 +0100
Date: Thu, 25 Oct 2012 12:00:09 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1351157606.18035.133.camel@zakaz.uk.xensource.com>
Message-ID: 
References: 
	<1351091027-20740-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<1351157606.18035.133.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" , "Tim
	\(Xen.org\)" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 2/7] xen/arm: setup the fixmap in head.S
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 25 Oct 2012, Ian Campbell wrote:
> On Wed, 2012-10-24 at 16:03 +0100, Stefano Stabellini wrote:
> > @@ -183,6 +184,16 @@ skip_bss:
> >         teq   r12, #0
> >         bne   pt_ready
> >         
> > +       /* console fixmap */
> > +       ldr   r1, =xen_fixmap
> > +       add   r1, r1, r10            /* r1 := paddr (xen_fixmap) */
> > +       mov   r3, #0
> > +       lsr   r2, r11, #12
> > +       lsl   r2, r2, #12            /* 4K aligned paddr of UART */
> > +       orr   r2, r2, #PT_UPPER(DEV_L3)
> > +       orr   r2, r2, #PT_LOWER(DEV_L3) /* r2:r3 := 4K dev map including UART */
> > +       strd  r2, r3, [r1, #0]       /* Map it in the first fixmap's slot */
> > +       
> >         /* Build the baseline idle pagetable's first-level entries */
> >         ldr   r1, =xen_second
> >         add   r1, r1, r10            /* r1 := paddr (xen_second) */
> [...]
> > @@ -205,12 +216,13 @@ skip_bss:
> >  	ldr   r4, =start
> >  	lsr   r4, #18                /* Slot for vaddr(start) */
> >  	strd  r2, r3, [r1, r4]       /* Map Xen there too */
> > +
> >  #ifdef EARLY_UART_ADDRESS
> > -	ldr   r3, =(1<<(54-32))      /* NS for device mapping */
> > -	lsr   r2, r11, #21
> > -	lsl   r2, r2, #21            /* 2MB-aligned paddr of UART */
> > -	orr   r2, r2, #PT_UPPER(DEV)
> > -	orr   r2, r2, #PT_LOWER(DEV) /* r2:r3 := 2MB dev map including UART */
> > +	/* xen_fixmap pagetable */
> > +	ldr r2, =xen_fixmap
> > +	add r2, r2, r10
> > +	orr   r2, r2, #PT_UPPER(PT)
> > +	orr   r2, r2, #PT_LOWER(PT) /* r2:r3 := paddr (xen_fixmap) */
> 
> We should setup the fixmap infrastructure even if !EARLY_UART_ADDRESS,
> unless we set it up again later?
> 
> As it stands it looks like you setup the generic fixmap mapping iff
> EARLY_UART_ADDRESS (second hunk above) but setup the UART mapping within
> that unconditionally (first hunk) which is exactly backwards, isn't it ?

Yes, you are right, they should be inverted.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 11:01:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 11:01:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRLBO-0007Sj-Pn; Thu, 25 Oct 2012 11:01:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRLBN-0007SR-Rr
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 11:01:01 +0000
Received: from [85.158.139.83:2882] by server-3.bemta-5.messagelabs.com id
	61/1D-28618-CEB19805; Thu, 25 Oct 2012 11:01:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1351162860!35874441!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10245 invoked from network); 25 Oct 2012 11:01:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 11:01:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,646,1344211200"; d="scan'208";a="15385214"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 11:01:00 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 25 Oct 2012 12:01:00 +0100
Message-ID: <1351162858.18035.163.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Thu, 25 Oct 2012 12:00:58 +0100
In-Reply-To: 
References: 
	<1351091027-20740-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<1351157839.18035.135.camel@zakaz.uk.xensource.com>
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" , "Tim
	\(Xen.org\)" 
Subject: Re: [Xen-devel] [PATCH 3/7] pl011: set baud and clock_hz to the
 right defaults for Versatile Express
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-25 at 11:57 +0100, Stefano Stabellini wrote:
> On Thu, 25 Oct 2012, Ian Campbell wrote:
> > Can we get these (or at least the clock_hz) from DTB?
> 
> Unfortunately we cannot.

I suppose we ought to get them from the pl011 equivalent of the com1
command line parameter then.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 11:01:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 11:01:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRLBO-0007Sj-Pn; Thu, 25 Oct 2012 11:01:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRLBN-0007SR-Rr
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 11:01:01 +0000
Received: from [85.158.139.83:2882] by server-3.bemta-5.messagelabs.com id
	61/1D-28618-CEB19805; Thu, 25 Oct 2012 11:01:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1351162860!35874441!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10245 invoked from network); 25 Oct 2012 11:01:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 11:01:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,646,1344211200"; d="scan'208";a="15385214"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 11:01:00 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 25 Oct 2012 12:01:00 +0100
Message-ID: <1351162858.18035.163.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Thu, 25 Oct 2012 12:00:58 +0100
In-Reply-To: 
References: 
	<1351091027-20740-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<1351157839.18035.135.camel@zakaz.uk.xensource.com>
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" , "Tim
	\(Xen.org\)" 
Subject: Re: [Xen-devel] [PATCH 3/7] pl011: set baud and clock_hz to the
 right defaults for Versatile Express
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-25 at 11:57 +0100, Stefano Stabellini wrote:
> On Thu, 25 Oct 2012, Ian Campbell wrote:
> > Can we get these (or at least the clock_hz) from DTB?
> 
> Unfortunately we cannot.

I suppose we ought to get them from the pl011 equivalent of the com1
command line parameter then.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 11:22:21 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 11:22:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRLVl-0007qx-OD; Thu, 25 Oct 2012 11:22:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRLVj-0007qs-Qt
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 11:22:03 +0000
Received: from [85.158.143.35:34131] by server-3.bemta-4.messagelabs.com id
	C8/7D-24279-BD029805; Thu, 25 Oct 2012 11:22:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1351164081!14429623!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2915 invoked from network); 25 Oct 2012 11:21:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 11:21:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,646,1344211200"; d="scan'208";a="15385861"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 11:21:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 12:21:20 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TRLV2-0003qs-58; Thu, 25 Oct 2012 11:21:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TRLV2-0000iT-1I;
	Thu, 25 Oct 2012 12:21:20 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20617.8367.946706.92097@mariner.uk.xensource.com>
Date: Thu, 25 Oct 2012 12:21:19 +0100
To: "Liu, Jinsong" 
Newsgroups: chiark.mail.xen.devel
In-Reply-To: 
References: 
	<20609.26910.2416.305293@mariner.uk.xensource.com>
	
	
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live
	migration	when	vMCE	occur
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Liu, Jinsong writes ("Re: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration when	vMCE	occur"):
> Update patch 4/5 as attached.

Thanks.  As for the tools parts:

Acked-by: Ian Jackson 

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 11:22:21 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 11:22:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRLVl-0007qx-OD; Thu, 25 Oct 2012 11:22:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRLVj-0007qs-Qt
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 11:22:03 +0000
Received: from [85.158.143.35:34131] by server-3.bemta-4.messagelabs.com id
	C8/7D-24279-BD029805; Thu, 25 Oct 2012 11:22:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1351164081!14429623!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2915 invoked from network); 25 Oct 2012 11:21:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 11:21:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,646,1344211200"; d="scan'208";a="15385861"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 11:21:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 12:21:20 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TRLV2-0003qs-58; Thu, 25 Oct 2012 11:21:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TRLV2-0000iT-1I;
	Thu, 25 Oct 2012 12:21:20 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20617.8367.946706.92097@mariner.uk.xensource.com>
Date: Thu, 25 Oct 2012 12:21:19 +0100
To: "Liu, Jinsong" 
Newsgroups: chiark.mail.xen.devel
In-Reply-To: 
References: 
	<20609.26910.2416.305293@mariner.uk.xensource.com>
	
	
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live
	migration	when	vMCE	occur
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Liu, Jinsong writes ("Re: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration when	vMCE	occur"):
> Update patch 4/5 as attached.

Thanks.  As for the tools parts:

Acked-by: Ian Jackson 

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 11:33:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 11:33:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRLgb-00084i-3S; Thu, 25 Oct 2012 11:33:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRLgZ-00084d-Oz
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 11:33:15 +0000
Received: from [85.158.138.51:57291] by server-16.bemta-3.messagelabs.com id
	34/D6-07461-A7329805; Thu, 25 Oct 2012 11:33:14 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1351164787!27415107!1
X-Originating-IP: [209.85.220.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5584 invoked from network); 25 Oct 2012 11:33:09 -0000
Received: from mail-pa0-f45.google.com (HELO mail-pa0-f45.google.com)
	(209.85.220.45)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 11:33:09 -0000
Received: by mail-pa0-f45.google.com with SMTP id fb10so1139049pad.32
	for ; Thu, 25 Oct 2012 04:33:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=9NSPO7tPrruLiKHxy9DX7g6VIIdMZFWQV3np17gTBzk=;
	b=V7cnVD/viTX2iV6MrkhMTnNHSL0n46h/yWUCnW5IKqmvuxpkSSfd7keGYmbMr4VNNh
	Ej6mcC8Wgx1EfEyUd8FNdN5FCzYrmzaM2N6HK4OrvDL8jvgtwKf0JydGTmrHgWNlO7fL
	YABqHwR+OFE6oNgIBNMJJT0jbwUmjuEnKpE1VErPx5/YnX6JfvcO6ljg22dUQuJwAnF9
	QLgAKBDiZePAsDTdt0THsFGmeFpLd+BTBitOmXwZrvFQC9fDMpFkhhnChOs5+PH5hbi4
	OM1gVBA/1l5rriihN74A2eWYr+Q3mrHq+ybeOkhVHQJgYzhKx83kYcfa9afPyN6UrBCQ
	Vl1Q==
Received: by 10.68.129.233 with SMTP id nz9mr59218288pbb.136.1351164786808;
	Thu, 25 Oct 2012 04:33:06 -0700 (PDT)
Received: from [101.2.20.10] ([96.49.152.177])
	by mx.google.com with ESMTPS id vi9sm11084329pbc.41.2012.10.25.04.33.04
	(version=SSLv3 cipher=OTHER); Thu, 25 Oct 2012 04:33:05 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Thu, 25 Oct 2012 04:33:01 -0700
From: Keir Fraser 
To: Olaf Hering 
Message-ID: 
Thread-Topic: [Xen-devel] [PATCH] tools/hvmloader: move shared_info to
	reserved memory area
Thread-Index: Ac2ypH1KIVD5Vp78uUm04TvdLbIo9Q==
In-Reply-To: <20121025075106.GA16484@aepfle.de>
Mime-version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools/hvmloader: move shared_info to
 reserved memory area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 25/10/2012 00:51, "Olaf Hering"  wrote:

> On Thu, Oct 25, Olaf Hering wrote:
> 
>> On Wed, Oct 24, Keir Fraser wrote:
>> 
>>> Which can be as simple as the attached patch (in fact all the changes apart
>>> from introducing GUEST_RESERVED_{START,END} are really cleaning up and
>>> bug-fixing the out-of-space checks in the mem_hole_alloc/mem_alloc
>>> functions).
>>> 
>>> This then just requires that the guest maps shared-info to FE700000 itself.
>>> Should be quite easy. :)
>> 
>> The patch works for me. And the kernel patch I sent yesterday works as
>> well.
>> Is the memory area starting from 0xFC000000 also reserved in older
>> versions, such as Xen3?

It is marked as E820_RESERVED in the e820 map as far back as Xen-3.4.0
(released Spring 2009). Before that it was not covered by an e820 entry, and
there is a slim chance your guest kernel may decide to map something else at
FE700000 (PCI BAR remapping f.ex)?

> And if the guest runs on an older tool stack, is there a slim chance
> that something allocated memory up to 0xFE700000?

Again, back as far as at least Xen-3.4.0, nothing would ever have got mapped
at FE700000. Earlier than that, can't be as authoritative, but I think it's
very unlikely.

 -- Keir

> Olaf



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 11:33:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 11:33:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRLgb-00084i-3S; Thu, 25 Oct 2012 11:33:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRLgZ-00084d-Oz
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 11:33:15 +0000
Received: from [85.158.138.51:57291] by server-16.bemta-3.messagelabs.com id
	34/D6-07461-A7329805; Thu, 25 Oct 2012 11:33:14 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1351164787!27415107!1
X-Originating-IP: [209.85.220.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5584 invoked from network); 25 Oct 2012 11:33:09 -0000
Received: from mail-pa0-f45.google.com (HELO mail-pa0-f45.google.com)
	(209.85.220.45)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 11:33:09 -0000
Received: by mail-pa0-f45.google.com with SMTP id fb10so1139049pad.32
	for ; Thu, 25 Oct 2012 04:33:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=9NSPO7tPrruLiKHxy9DX7g6VIIdMZFWQV3np17gTBzk=;
	b=V7cnVD/viTX2iV6MrkhMTnNHSL0n46h/yWUCnW5IKqmvuxpkSSfd7keGYmbMr4VNNh
	Ej6mcC8Wgx1EfEyUd8FNdN5FCzYrmzaM2N6HK4OrvDL8jvgtwKf0JydGTmrHgWNlO7fL
	YABqHwR+OFE6oNgIBNMJJT0jbwUmjuEnKpE1VErPx5/YnX6JfvcO6ljg22dUQuJwAnF9
	QLgAKBDiZePAsDTdt0THsFGmeFpLd+BTBitOmXwZrvFQC9fDMpFkhhnChOs5+PH5hbi4
	OM1gVBA/1l5rriihN74A2eWYr+Q3mrHq+ybeOkhVHQJgYzhKx83kYcfa9afPyN6UrBCQ
	Vl1Q==
Received: by 10.68.129.233 with SMTP id nz9mr59218288pbb.136.1351164786808;
	Thu, 25 Oct 2012 04:33:06 -0700 (PDT)
Received: from [101.2.20.10] ([96.49.152.177])
	by mx.google.com with ESMTPS id vi9sm11084329pbc.41.2012.10.25.04.33.04
	(version=SSLv3 cipher=OTHER); Thu, 25 Oct 2012 04:33:05 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Thu, 25 Oct 2012 04:33:01 -0700
From: Keir Fraser 
To: Olaf Hering 
Message-ID: 
Thread-Topic: [Xen-devel] [PATCH] tools/hvmloader: move shared_info to
	reserved memory area
Thread-Index: Ac2ypH1KIVD5Vp78uUm04TvdLbIo9Q==
In-Reply-To: <20121025075106.GA16484@aepfle.de>
Mime-version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools/hvmloader: move shared_info to
 reserved memory area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 25/10/2012 00:51, "Olaf Hering"  wrote:

> On Thu, Oct 25, Olaf Hering wrote:
> 
>> On Wed, Oct 24, Keir Fraser wrote:
>> 
>>> Which can be as simple as the attached patch (in fact all the changes apart
>>> from introducing GUEST_RESERVED_{START,END} are really cleaning up and
>>> bug-fixing the out-of-space checks in the mem_hole_alloc/mem_alloc
>>> functions).
>>> 
>>> This then just requires that the guest maps shared-info to FE700000 itself.
>>> Should be quite easy. :)
>> 
>> The patch works for me. And the kernel patch I sent yesterday works as
>> well.
>> Is the memory area starting from 0xFC000000 also reserved in older
>> versions, such as Xen3?

It is marked as E820_RESERVED in the e820 map as far back as Xen-3.4.0
(released Spring 2009). Before that it was not covered by an e820 entry, and
there is a slim chance your guest kernel may decide to map something else at
FE700000 (PCI BAR remapping f.ex)?

> And if the guest runs on an older tool stack, is there a slim chance
> that something allocated memory up to 0xFE700000?

Again, back as far as at least Xen-3.4.0, nothing would ever have got mapped
at FE700000. Earlier than that, can't be as authoritative, but I think it's
very unlikely.

 -- Keir

> Olaf



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 11:40:12 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 11:40:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRLmx-0008Dk-Un; Thu, 25 Oct 2012 11:39:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRLmw-0008Df-GR
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 11:39:50 +0000
Received: from [85.158.139.211:57466] by server-7.bemta-5.messagelabs.com id
	CB/F2-23102-50529805; Thu, 25 Oct 2012 11:39:49 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1351165187!23684469!1
X-Originating-IP: [209.85.210.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12670 invoked from network); 25 Oct 2012 11:39:48 -0000
Received: from mail-da0-f45.google.com (HELO mail-da0-f45.google.com)
	(209.85.210.45)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 11:39:48 -0000
Received: by mail-da0-f45.google.com with SMTP id n15so776667dad.32
	for ; Thu, 25 Oct 2012 04:39:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=w5l9xML0AJRcX4g28lxjUdBdFiZYmtulP/aeQiJaxm4=;
	b=PLFSk1deSxfyQN0wzCZpNtp6mxrT8GLwo1B6kwKkiLPQyMT228yBS3AQVrHJQVW82G
	6GcJ3sfu1CCGEQD7AY/+qv8oB4rkN1ugQZXfY5fqLQ2nKR4UAr5bc58f3Yc9/9IAKH67
	b3mhUQNDEFq+rAyLv+Vu58gGb8+ch0HlaA/u5WFUiv2LSKFoEFjw1sRdOxTQA542THO1
	D5+aI9vVsgtTweY5tYfBtOcXfDL0s9oj5/H+LzeEQZ/dGIzIhggDfAG0bl5QyUzQpqGO
	J1Sw8N1k82XDJywllMuy+/b8LuMoPK2XmeF5k4TRackmJdUA4648RuDxZ8uRD6Bly7s4
	Motg==
Received: by 10.68.230.232 with SMTP id tb8mr59326112pbc.19.1351165186647;
	Thu, 25 Oct 2012 04:39:46 -0700 (PDT)
Received: from [101.2.20.10] ([96.49.152.177])
	by mx.google.com with ESMTPS id tw5sm11090809pbc.48.2012.10.25.04.39.44
	(version=SSLv3 cipher=OTHER); Thu, 25 Oct 2012 04:39:45 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Thu, 25 Oct 2012 04:39:40 -0700
From: Keir Fraser 
To: Olaf Hering 
Message-ID: 
Thread-Topic: [Xen-devel] [PATCH] tools/hvmloader: move shared_info to
	reserved memory area
Thread-Index: Ac2ypH1KIVD5Vp78uUm04TvdLbIo9QAAO3R5
In-Reply-To: 
Mime-version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools/hvmloader: move shared_info to
 reserved memory area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 25/10/2012 04:33, "Keir Fraser"  wrote:

> On 25/10/2012 00:51, "Olaf Hering"  wrote:
> 
>> On Thu, Oct 25, Olaf Hering wrote:
>> 
>>> On Wed, Oct 24, Keir Fraser wrote:
>>> 
>>>> Which can be as simple as the attached patch (in fact all the changes apart
>>>> from introducing GUEST_RESERVED_{START,END} are really cleaning up and
>>>> bug-fixing the out-of-space checks in the mem_hole_alloc/mem_alloc
>>>> functions).
>>>> 
>>>> This then just requires that the guest maps shared-info to FE700000 itself.
>>>> Should be quite easy. :)
>>> 
>>> The patch works for me. And the kernel patch I sent yesterday works as
>>> well.
>>> Is the memory area starting from 0xFC000000 also reserved in older
>>> versions, such as Xen3?
> 
> It is marked as E820_RESERVED in the e820 map as far back as Xen-3.4.0
> (released Spring 2009). Before that it was not covered by an e820 entry, and
> there is a slim chance your guest kernel may decide to map something else at
> FE700000 (PCI BAR remapping f.ex)?
> 
>> And if the guest runs on an older tool stack, is there a slim chance
>> that something allocated memory up to 0xFE700000?
> 
> Again, back as far as at least Xen-3.4.0, nothing would ever have got mapped
> at FE700000. Earlier than that, can't be as authoritative, but I think it's
> very unlikely.

To be honest, given that the XenPVHVM extensions to Linux won't have been
tested on such old hypervisors, it wouldn't be a bad thing to bail on
setting up the extensions when you detect running on a really old Xen
version (e.g., earlier than 3.4.0) anyway. There's a fair chance of doing
more harm than good?

 -- Keir

>  -- Keir
> 
>> Olaf
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 11:40:12 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 11:40:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRLmx-0008Dk-Un; Thu, 25 Oct 2012 11:39:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRLmw-0008Df-GR
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 11:39:50 +0000
Received: from [85.158.139.211:57466] by server-7.bemta-5.messagelabs.com id
	CB/F2-23102-50529805; Thu, 25 Oct 2012 11:39:49 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1351165187!23684469!1
X-Originating-IP: [209.85.210.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12670 invoked from network); 25 Oct 2012 11:39:48 -0000
Received: from mail-da0-f45.google.com (HELO mail-da0-f45.google.com)
	(209.85.210.45)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 11:39:48 -0000
Received: by mail-da0-f45.google.com with SMTP id n15so776667dad.32
	for ; Thu, 25 Oct 2012 04:39:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=w5l9xML0AJRcX4g28lxjUdBdFiZYmtulP/aeQiJaxm4=;
	b=PLFSk1deSxfyQN0wzCZpNtp6mxrT8GLwo1B6kwKkiLPQyMT228yBS3AQVrHJQVW82G
	6GcJ3sfu1CCGEQD7AY/+qv8oB4rkN1ugQZXfY5fqLQ2nKR4UAr5bc58f3Yc9/9IAKH67
	b3mhUQNDEFq+rAyLv+Vu58gGb8+ch0HlaA/u5WFUiv2LSKFoEFjw1sRdOxTQA542THO1
	D5+aI9vVsgtTweY5tYfBtOcXfDL0s9oj5/H+LzeEQZ/dGIzIhggDfAG0bl5QyUzQpqGO
	J1Sw8N1k82XDJywllMuy+/b8LuMoPK2XmeF5k4TRackmJdUA4648RuDxZ8uRD6Bly7s4
	Motg==
Received: by 10.68.230.232 with SMTP id tb8mr59326112pbc.19.1351165186647;
	Thu, 25 Oct 2012 04:39:46 -0700 (PDT)
Received: from [101.2.20.10] ([96.49.152.177])
	by mx.google.com with ESMTPS id tw5sm11090809pbc.48.2012.10.25.04.39.44
	(version=SSLv3 cipher=OTHER); Thu, 25 Oct 2012 04:39:45 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Thu, 25 Oct 2012 04:39:40 -0700
From: Keir Fraser 
To: Olaf Hering 
Message-ID: 
Thread-Topic: [Xen-devel] [PATCH] tools/hvmloader: move shared_info to
	reserved memory area
Thread-Index: Ac2ypH1KIVD5Vp78uUm04TvdLbIo9QAAO3R5
In-Reply-To: 
Mime-version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools/hvmloader: move shared_info to
 reserved memory area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 25/10/2012 04:33, "Keir Fraser"  wrote:

> On 25/10/2012 00:51, "Olaf Hering"  wrote:
> 
>> On Thu, Oct 25, Olaf Hering wrote:
>> 
>>> On Wed, Oct 24, Keir Fraser wrote:
>>> 
>>>> Which can be as simple as the attached patch (in fact all the changes apart
>>>> from introducing GUEST_RESERVED_{START,END} are really cleaning up and
>>>> bug-fixing the out-of-space checks in the mem_hole_alloc/mem_alloc
>>>> functions).
>>>> 
>>>> This then just requires that the guest maps shared-info to FE700000 itself.
>>>> Should be quite easy. :)
>>> 
>>> The patch works for me. And the kernel patch I sent yesterday works as
>>> well.
>>> Is the memory area starting from 0xFC000000 also reserved in older
>>> versions, such as Xen3?
> 
> It is marked as E820_RESERVED in the e820 map as far back as Xen-3.4.0
> (released Spring 2009). Before that it was not covered by an e820 entry, and
> there is a slim chance your guest kernel may decide to map something else at
> FE700000 (PCI BAR remapping f.ex)?
> 
>> And if the guest runs on an older tool stack, is there a slim chance
>> that something allocated memory up to 0xFE700000?
> 
> Again, back as far as at least Xen-3.4.0, nothing would ever have got mapped
> at FE700000. Earlier than that, can't be as authoritative, but I think it's
> very unlikely.

To be honest, given that the XenPVHVM extensions to Linux won't have been
tested on such old hypervisors, it wouldn't be a bad thing to bail on
setting up the extensions when you detect running on a really old Xen
version (e.g., earlier than 3.4.0) anyway. There's a fair chance of doing
more harm than good?

 -- Keir

>  -- Keir
> 
>> Olaf
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 11:47:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 11:47:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRLti-0008My-RJ; Thu, 25 Oct 2012 11:46:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRLth-0008Mt-2F
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 11:46:49 +0000
Received: from [85.158.139.211:13548] by server-10.bemta-5.messagelabs.com id
	29/0B-01025-8A629805; Thu, 25 Oct 2012 11:46:48 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-206.messagelabs.com!1351165607!23620244!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0Njk5Mzc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0Njk5Mzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6576 invoked from network); 25 Oct 2012 11:46:47 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Oct 2012 11:46:47 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll387qFkE=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-086-014.pools.arcor-ip.net [84.57.86.14])
	by smtp.strato.de (joses mo36) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id x021fdo9PAiPLx ;
	Thu, 25 Oct 2012 13:46:47 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id CB67218642; Thu, 25 Oct 2012 13:46:45 +0200 (CEST)
Date: Thu, 25 Oct 2012 13:46:45 +0200
From: Olaf Hering 
To: Keir Fraser , Konrad Rzeszutek Wilk 
Message-ID: <20121025114645.GA7218@aepfle.de>
References: 
	
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools/hvmloader: move shared_info to
 reserved memory area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Oct 25, Keir Fraser wrote:

> To be honest, given that the XenPVHVM extensions to Linux won't have been
> tested on such old hypervisors, it wouldn't be a bad thing to bail on
> setting up the extensions when you detect running on a really old Xen
> version (e.g., earlier than 3.4.0) anyway. There's a fair chance of doing
> more harm than good?

I could stick such a check into
arch/x86/xen/enlighten.c:x86_hyper_xen_hvm->detect, by rearranging the
code of xen_hvm_platform and init_hvm_pv_info.  Konrad, what do you
think about that? Recent changes indicate that you did some testing on
3.4 based hosts.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 11:47:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 11:47:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRLti-0008My-RJ; Thu, 25 Oct 2012 11:46:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRLth-0008Mt-2F
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 11:46:49 +0000
Received: from [85.158.139.211:13548] by server-10.bemta-5.messagelabs.com id
	29/0B-01025-8A629805; Thu, 25 Oct 2012 11:46:48 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-206.messagelabs.com!1351165607!23620244!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0Njk5Mzc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0Njk5Mzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6576 invoked from network); 25 Oct 2012 11:46:47 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Oct 2012 11:46:47 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll387qFkE=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-086-014.pools.arcor-ip.net [84.57.86.14])
	by smtp.strato.de (joses mo36) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id x021fdo9PAiPLx ;
	Thu, 25 Oct 2012 13:46:47 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id CB67218642; Thu, 25 Oct 2012 13:46:45 +0200 (CEST)
Date: Thu, 25 Oct 2012 13:46:45 +0200
From: Olaf Hering 
To: Keir Fraser , Konrad Rzeszutek Wilk 
Message-ID: <20121025114645.GA7218@aepfle.de>
References: 
	
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools/hvmloader: move shared_info to
 reserved memory area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Oct 25, Keir Fraser wrote:

> To be honest, given that the XenPVHVM extensions to Linux won't have been
> tested on such old hypervisors, it wouldn't be a bad thing to bail on
> setting up the extensions when you detect running on a really old Xen
> version (e.g., earlier than 3.4.0) anyway. There's a fair chance of doing
> more harm than good?

I could stick such a check into
arch/x86/xen/enlighten.c:x86_hyper_xen_hvm->detect, by rearranging the
code of xen_hvm_platform and init_hvm_pv_info.  Konrad, what do you
think about that? Recent changes indicate that you did some testing on
3.4 based hosts.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 11:49:22 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 11:49:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRLvu-0008U7-W3; Thu, 25 Oct 2012 11:49:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRLvt-0008Tf-G2
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 11:49:05 +0000
Received: from [85.158.139.211:59445] by server-9.bemta-5.messagelabs.com id
	8C/3A-23053-03729805; Thu, 25 Oct 2012 11:49:04 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1351165743!23220136!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6213 invoked from network); 25 Oct 2012 11:49:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 11:49:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,646,1344211200"; d="scan'208";a="15386524"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 11:49:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 12:49:00 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53] helo=spongy)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TRLvo-0003zk-Pm;
	Thu, 25 Oct 2012 11:49:00 +0000
Received: by spongy (Postfix, from userid 2023)	id 98D1D34040D; Thu, 25 Oct
	2012 12:52:09 +0100 (BST)
From: Jean Guyader 
To: 
Date: Thu, 25 Oct 2012 12:52:03 +0100
Message-ID: <1351165926-23259-1-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: tim@xen.org, Jean Guyader , JBeulich@suse.com
Subject: [Xen-devel] [PATCH 0/3] Add V4V to Xen (v7)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: quoted-printable

v7 changes:
        - Remove v4v_send from the API (v4v_sendv should be
          used instead).
        - Remove internal_v4v_iov
        - Remove useless padding
        - Switch back to use uint64_t for the pfn list
          instead of xen_pfn_t (to avoid some compat code)
        - Rename v4v_iptable to v4v_table.
        - Use __copy_to/from_guest when possible

v6 changes:
        - Check compiler before using [0] or [].

v5 changes:
        - Fix prototypes in v4v.h for do_v4v_op
        - Add padding to make sure all the structures
          are 64 bits aligned
        - Replace [0] with []

v4 changes:
        - Stop using ssize_t, use long instead
        - Return -MSGSIZE for message bigger than 2GB
        - Fixup size handling
        - Rename protocol with message_type to avoid the
          confusion with the IP protocol flag
        - Replaced V4V_DOMID_ANY value with DOMID_INVALID
        - Replaced v4v_pfn_t with xen_pfn_t
        - Add padding to struct v4v_info
        - Fixup hypercall documentation
        - Move V4V_ROUNDUP to v4v.c
        - Remove v4v_utils.h (we could potentially add it later).

v3 changes:
        - Switch to event channel
                - Allocated a unbound event channel
                  per domain.
                - Add a new v4v call to share the
                  event channel port.
        - Public headers with actual type definition
        - Align all the v4v type to 64 bits
        - Modify v4v MAGIC numbers because we won't
          but backward compatible anymore
        - Merge insert and insertv
        - Merge send and sendv
        - Turn all the lock prerequisite from comment
          to ASSERT()
        - Make use or write_atomic instead of volatile pointers
        - Merge v4v_memcpy_to_guest_ring and
          v4v_memcpy_to_guest_ring_from_guest
                - Introduce copy_from_guest_maybe that can take
                  a void * and a handle as src address.
        - Replace 6 arguments hypercalls with 5 arguments hypercalls.

v2 changes:
        - Cleanup plugin header
        - Include basic access control
        - Use guest_handle_for_field

Jean Guyader (3):
  xen: virq, remove VIRQ_XC_RESERVED
  xen: events, exposes evtchn_alloc_unbound_domain
  xen: Add V4V implementation

 xen/arch/x86/hvm/hvm.c             |    6 +-
 xen/arch/x86/x86_64/compat/entry.S |    2 +
 xen/arch/x86/x86_64/entry.S        |    2 +
 xen/common/Makefile                |    1 +
 xen/common/domain.c                |   13 +-
 xen/common/event_channel.c         |   39 +-
 xen/common/v4v.c                   | 1848 ++++++++++++++++++++++++++++++=
++++++
 xen/include/public/v4v.h           |  308 ++++++
 xen/include/public/xen.h           |    3 +-
 xen/include/xen/event.h            |    3 +
 xen/include/xen/sched.h            |    4 +
 xen/include/xen/v4v.h              |  134 +++
 12 files changed, 2346 insertions(+), 17 deletions(-)
 create mode 100644 xen/common/v4v.c
 create mode 100644 xen/include/public/v4v.h
 create mode 100644 xen/include/xen/v4v.h

--=20
1.7.9.5


--------------true
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------true--


From xen-devel-bounces@lists.xen.org Thu Oct 25 11:49:22 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 11:49:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRLvu-0008U7-W3; Thu, 25 Oct 2012 11:49:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRLvt-0008Tf-G2
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 11:49:05 +0000
Received: from [85.158.139.211:59445] by server-9.bemta-5.messagelabs.com id
	8C/3A-23053-03729805; Thu, 25 Oct 2012 11:49:04 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1351165743!23220136!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6213 invoked from network); 25 Oct 2012 11:49:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 11:49:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,646,1344211200"; d="scan'208";a="15386524"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 11:49:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 12:49:00 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53] helo=spongy)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TRLvo-0003zk-Pm;
	Thu, 25 Oct 2012 11:49:00 +0000
Received: by spongy (Postfix, from userid 2023)	id 98D1D34040D; Thu, 25 Oct
	2012 12:52:09 +0100 (BST)
From: Jean Guyader 
To: 
Date: Thu, 25 Oct 2012 12:52:03 +0100
Message-ID: <1351165926-23259-1-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: tim@xen.org, Jean Guyader , JBeulich@suse.com
Subject: [Xen-devel] [PATCH 0/3] Add V4V to Xen (v7)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: quoted-printable

v7 changes:
        - Remove v4v_send from the API (v4v_sendv should be
          used instead).
        - Remove internal_v4v_iov
        - Remove useless padding
        - Switch back to use uint64_t for the pfn list
          instead of xen_pfn_t (to avoid some compat code)
        - Rename v4v_iptable to v4v_table.
        - Use __copy_to/from_guest when possible

v6 changes:
        - Check compiler before using [0] or [].

v5 changes:
        - Fix prototypes in v4v.h for do_v4v_op
        - Add padding to make sure all the structures
          are 64 bits aligned
        - Replace [0] with []

v4 changes:
        - Stop using ssize_t, use long instead
        - Return -MSGSIZE for message bigger than 2GB
        - Fixup size handling
        - Rename protocol with message_type to avoid the
          confusion with the IP protocol flag
        - Replaced V4V_DOMID_ANY value with DOMID_INVALID
        - Replaced v4v_pfn_t with xen_pfn_t
        - Add padding to struct v4v_info
        - Fixup hypercall documentation
        - Move V4V_ROUNDUP to v4v.c
        - Remove v4v_utils.h (we could potentially add it later).

v3 changes:
        - Switch to event channel
                - Allocated a unbound event channel
                  per domain.
                - Add a new v4v call to share the
                  event channel port.
        - Public headers with actual type definition
        - Align all the v4v type to 64 bits
        - Modify v4v MAGIC numbers because we won't
          but backward compatible anymore
        - Merge insert and insertv
        - Merge send and sendv
        - Turn all the lock prerequisite from comment
          to ASSERT()
        - Make use or write_atomic instead of volatile pointers
        - Merge v4v_memcpy_to_guest_ring and
          v4v_memcpy_to_guest_ring_from_guest
                - Introduce copy_from_guest_maybe that can take
                  a void * and a handle as src address.
        - Replace 6 arguments hypercalls with 5 arguments hypercalls.

v2 changes:
        - Cleanup plugin header
        - Include basic access control
        - Use guest_handle_for_field

Jean Guyader (3):
  xen: virq, remove VIRQ_XC_RESERVED
  xen: events, exposes evtchn_alloc_unbound_domain
  xen: Add V4V implementation

 xen/arch/x86/hvm/hvm.c             |    6 +-
 xen/arch/x86/x86_64/compat/entry.S |    2 +
 xen/arch/x86/x86_64/entry.S        |    2 +
 xen/common/Makefile                |    1 +
 xen/common/domain.c                |   13 +-
 xen/common/event_channel.c         |   39 +-
 xen/common/v4v.c                   | 1848 ++++++++++++++++++++++++++++++=
++++++
 xen/include/public/v4v.h           |  308 ++++++
 xen/include/public/xen.h           |    3 +-
 xen/include/xen/event.h            |    3 +
 xen/include/xen/sched.h            |    4 +
 xen/include/xen/v4v.h              |  134 +++
 12 files changed, 2346 insertions(+), 17 deletions(-)
 create mode 100644 xen/common/v4v.c
 create mode 100644 xen/include/public/v4v.h
 create mode 100644 xen/include/xen/v4v.h

--=20
1.7.9.5


--------------true
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------true--


From xen-devel-bounces@lists.xen.org Thu Oct 25 11:49:22 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 11:49:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRLvu-0008U0-KL; Thu, 25 Oct 2012 11:49:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRLvt-0008Tg-7s
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 11:49:05 +0000
Received: from [85.158.139.211:48726] by server-15.bemta-5.messagelabs.com id
	75/12-26920-03729805; Thu, 25 Oct 2012 11:49:04 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1351165743!23220136!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6206 invoked from network); 25 Oct 2012 11:49:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 11:49:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,646,1344211200"; d="scan'208";a="15386523"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 11:49:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 12:49:01 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53] helo=spongy)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TRLvo-0003zl-Sg;
	Thu, 25 Oct 2012 11:49:00 +0000
Received: by spongy (Postfix, from userid 2023)	id C0966340D86; Thu, 25 Oct
	2012 12:52:09 +0100 (BST)
From: Jean Guyader 
To: 
Date: Thu, 25 Oct 2012 12:52:04 +0100
Message-ID: <1351165926-23259-2-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1351165926-23259-1-git-send-email-jean.guyader@citrix.com>
References: <1351165926-23259-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: tim@xen.org, Jean Guyader , JBeulich@suse.com
Subject: [Xen-devel] [PATCH 1/3] xen: virq, remove VIRQ_XC_RESERVED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: quoted-printable


VIRQ_XC_RESERVED was reserved for V4V but we have switched
to event channels so this place holder is no longer required.

Signed-off-by: Jean Guyader 
---
 xen/include/public/xen.h |    1 -
 1 file changed, 1 deletion(-)


--------------true
Content-Type: text/x-patch;
	name="0001-xen-virq-remove-VIRQ_XC_RESERVED.patch"
Content-Disposition: attachment;
	filename="0001-xen-virq-remove-VIRQ_XC_RESERVED.patch"
Content-Transfer-Encoding: quoted-printable

diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 7352d1e..268df3e 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -158,7 +158,6 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
 #define VIRQ_CON_RING   8  /* G. (DOM0) Bytes received on console       =
     */
 #define VIRQ_PCPU_STATE 9  /* G. (DOM0) PCPU state changed              =
     */
 #define VIRQ_MEM_EVENT  10 /* G. (DOM0) A memory event has occured      =
     */
-#define VIRQ_XC_RESERVED 11 /* G. Reserved for XenClient                =
     */
 #define VIRQ_ENOMEM     12 /* G. (DOM0) Low on heap memory       */
=20
 /* Architecture-specific VIRQ definitions. */

--------------true
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------true--


From xen-devel-bounces@lists.xen.org Thu Oct 25 11:49:22 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 11:49:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRLvu-0008U0-KL; Thu, 25 Oct 2012 11:49:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRLvt-0008Tg-7s
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 11:49:05 +0000
Received: from [85.158.139.211:48726] by server-15.bemta-5.messagelabs.com id
	75/12-26920-03729805; Thu, 25 Oct 2012 11:49:04 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1351165743!23220136!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6206 invoked from network); 25 Oct 2012 11:49:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 11:49:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,646,1344211200"; d="scan'208";a="15386523"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 11:49:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 12:49:01 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53] helo=spongy)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TRLvo-0003zl-Sg;
	Thu, 25 Oct 2012 11:49:00 +0000
Received: by spongy (Postfix, from userid 2023)	id C0966340D86; Thu, 25 Oct
	2012 12:52:09 +0100 (BST)
From: Jean Guyader 
To: 
Date: Thu, 25 Oct 2012 12:52:04 +0100
Message-ID: <1351165926-23259-2-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1351165926-23259-1-git-send-email-jean.guyader@citrix.com>
References: <1351165926-23259-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: tim@xen.org, Jean Guyader , JBeulich@suse.com
Subject: [Xen-devel] [PATCH 1/3] xen: virq, remove VIRQ_XC_RESERVED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: quoted-printable


VIRQ_XC_RESERVED was reserved for V4V but we have switched
to event channels so this place holder is no longer required.

Signed-off-by: Jean Guyader 
---
 xen/include/public/xen.h |    1 -
 1 file changed, 1 deletion(-)


--------------true
Content-Type: text/x-patch;
	name="0001-xen-virq-remove-VIRQ_XC_RESERVED.patch"
Content-Disposition: attachment;
	filename="0001-xen-virq-remove-VIRQ_XC_RESERVED.patch"
Content-Transfer-Encoding: quoted-printable

diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 7352d1e..268df3e 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -158,7 +158,6 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
 #define VIRQ_CON_RING   8  /* G. (DOM0) Bytes received on console       =
     */
 #define VIRQ_PCPU_STATE 9  /* G. (DOM0) PCPU state changed              =
     */
 #define VIRQ_MEM_EVENT  10 /* G. (DOM0) A memory event has occured      =
     */
-#define VIRQ_XC_RESERVED 11 /* G. Reserved for XenClient                =
     */
 #define VIRQ_ENOMEM     12 /* G. (DOM0) Low on heap memory       */
=20
 /* Architecture-specific VIRQ definitions. */

--------------true
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------true--


From xen-devel-bounces@lists.xen.org Thu Oct 25 11:49:23 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 11:49:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRLvv-0008UY-Tn; Thu, 25 Oct 2012 11:49:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRLvt-0008Th-T7
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 11:49:06 +0000
Received: from [85.158.139.211:59505] by server-12.bemta-5.messagelabs.com id
	A7/22-26919-13729805; Thu, 25 Oct 2012 11:49:05 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1351165743!23220136!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6244 invoked from network); 25 Oct 2012 11:49:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 11:49:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,646,1344211200"; d="scan'208";a="15386525"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 11:49:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 12:49:01 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53] helo=spongy)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TRLvp-0003zr-13;
	Thu, 25 Oct 2012 11:49:01 +0000
Received: by spongy (Postfix, from userid 2023)	id 1675734040D; Thu, 25 Oct
	2012 12:52:09 +0100 (BST)
From: Jean Guyader 
To: 
Date: Thu, 25 Oct 2012 12:52:06 +0100
Message-ID: <1351165926-23259-4-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1351165926-23259-1-git-send-email-jean.guyader@citrix.com>
References: <1351165926-23259-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: tim@xen.org, Jean Guyader , JBeulich@suse.com
Subject: [Xen-devel] [PATCH 3/3] xen: Add V4V implementation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: quoted-printable


Setup of v4v domains a domain gets created and cleanup
when a domain die. Wire up the v4v hypercall.

Include v4v internal and public headers.

Signed-off-by: Jean Guyader 
---
 xen/arch/x86/hvm/hvm.c             |    6 +-
 xen/arch/x86/x86_64/compat/entry.S |    2 +
 xen/arch/x86/x86_64/entry.S        |    2 +
 xen/common/Makefile                |    1 +
 xen/common/domain.c                |   13 +-
 xen/common/v4v.c                   | 1848 ++++++++++++++++++++++++++++++=
++++++
 xen/include/public/v4v.h           |  308 ++++++
 xen/include/public/xen.h           |    2 +-
 xen/include/xen/sched.h            |    4 +
 xen/include/xen/v4v.h              |  134 +++
 10 files changed, 2316 insertions(+), 4 deletions(-)
 create mode 100644 xen/common/v4v.c
 create mode 100644 xen/include/public/v4v.h
 create mode 100644 xen/include/xen/v4v.h


--------------true
Content-Type: text/x-patch; name="0003-xen-Add-V4V-implementation.patch"
Content-Disposition: attachment;
	filename="0003-xen-Add-V4V-implementation.patch"
Content-Transfer-Encoding: quoted-printable

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 34da2f5..e5237f9 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3242,7 +3242,8 @@ static hvm_hypercall_t *const hvm_hypercall64_table=
[NR_hypercalls] =3D {
     HYPERCALL(set_timer_op),
     HYPERCALL(hvm_op),
     HYPERCALL(sysctl),
-    HYPERCALL(tmem_op)
+    HYPERCALL(tmem_op),
+    HYPERCALL(v4v_op)
 };
=20
 #define COMPAT_CALL(x)                                        \
@@ -3259,7 +3260,8 @@ static hvm_hypercall_t *const hvm_hypercall32_table=
[NR_hypercalls] =3D {
     COMPAT_CALL(set_timer_op),
     HYPERCALL(hvm_op),
     HYPERCALL(sysctl),
-    HYPERCALL(tmem_op)
+    HYPERCALL(tmem_op),
+    HYPERCALL(v4v_op)
 };
=20
 int hvm_do_hypercall(struct cpu_user_regs *regs)
diff --git a/xen/arch/x86/x86_64/compat/entry.S b/xen/arch/x86/x86_64/com=
pat/entry.S
index e6b52f3..4902c4f 100644
--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -414,6 +414,7 @@ ENTRY(compat_hypercall_table)
         .quad do_domctl
         .quad compat_kexec_op
         .quad do_tmem_op
+        .quad do_v4v_op
         .rept __HYPERVISOR_arch_0-((.-compat_hypercall_table)/8)
         .quad compat_ni_hypercall
         .endr
@@ -462,6 +463,7 @@ ENTRY(compat_hypercall_args_table)
         .byte 1 /* do_domctl                */
         .byte 2 /* compat_kexec_op          */
         .byte 1 /* do_tmem_op               */
+        .byte 5 /* do_v4v_op		    */
         .rept __HYPERVISOR_arch_0-(.-compat_hypercall_args_table)
         .byte 0 /* compat_ni_hypercall      */
         .endr
diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S
index ffb9314..78006cf 100644
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -707,6 +707,7 @@ ENTRY(hypercall_table)
         .quad do_domctl
         .quad do_kexec_op
         .quad do_tmem_op
+        .quad do_v4v_op
         .rept __HYPERVISOR_arch_0-((.-hypercall_table)/8)
         .quad do_ni_hypercall
         .endr
@@ -755,6 +756,7 @@ ENTRY(hypercall_args_table)
         .byte 1 /* do_domctl            */
         .byte 2 /* do_kexec             */
         .byte 1 /* do_tmem_op           */
+        .byte 5 /* do_v4v_op		*/
         .rept __HYPERVISOR_arch_0-(.-hypercall_args_table)
         .byte 0 /* do_ni_hypercall      */
         .endr
diff --git a/xen/common/Makefile b/xen/common/Makefile
index c1c100f..ba63cec 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -45,6 +45,7 @@ obj-y +=3D tmem_xen.o
 obj-y +=3D radix-tree.o
 obj-y +=3D rbtree.o
 obj-y +=3D lzo.o
+obj-y +=3D v4v.o
=20
 obj-bin-$(CONFIG_X86) +=3D $(foreach n,decompress bunzip2 unxz unlzma un=
lzo,$(n).init.o)
=20
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 0e3e36a..60cd8e3 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -195,7 +195,8 @@ struct domain *domain_create(
 {
     struct domain *d, **pd;
     enum { INIT_xsm =3D 1u<<0, INIT_watchdog =3D 1u<<1, INIT_rangeset =3D=
 1u<<2,
-           INIT_evtchn =3D 1u<<3, INIT_gnttab =3D 1u<<4, INIT_arch =3D 1=
u<<5 };
+           INIT_evtchn =3D 1u<<3, INIT_gnttab =3D 1u<<4, INIT_arch =3D 1=
u<<5,
+           INIT_v4v =3D 1u<<6 };
     int err, init_status =3D 0;
     int poolid =3D CPUPOOLID_NONE;
=20
@@ -307,6 +308,13 @@ struct domain *domain_create(
         spin_unlock(&domlist_update_lock);
     }
=20
+    if ( !is_idle_domain(d) )
+    {
+        if ( v4v_init(d) !=3D 0 )
+            goto fail;
+        init_status |=3D INIT_v4v;
+    }
+
     return d;
=20
  fail:
@@ -315,6 +323,8 @@ struct domain *domain_create(
     xfree(d->mem_event);
     if ( init_status & INIT_arch )
         arch_domain_destroy(d);
+    if ( init_status & INIT_v4v )
+	v4v_destroy(d);
     if ( init_status & INIT_gnttab )
         grant_table_destroy(d);
     if ( init_status & INIT_evtchn )
@@ -489,6 +499,7 @@ int domain_kill(struct domain *d)
         domain_pause(d);
         d->is_dying =3D DOMDYING_dying;
         spin_barrier(&d->domain_lock);
+        v4v_destroy(d);
         evtchn_destroy(d);
         gnttab_release_mappings(d);
         tmem_destroy(d->tmem);
diff --git a/xen/common/v4v.c b/xen/common/v4v.c
new file mode 100644
index 0000000..b821950
--- /dev/null
+++ b/xen/common/v4v.c
@@ -0,0 +1,1848 @@
+/***********************************************************************=
*******
+ * V4V
+ *
+ * Version 2 of v2v (Virtual-to-Virtual)
+ *
+ * Copyright (c) 2010, Citrix Systems
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 =
 USA
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#ifdef V4V_DEBUG
+#define v4v_dprintk(format, args...)            \
+    do {                                        \
+        printk("%s:%d " format,                 \
+               __FILE__, __LINE__, ## args );   \
+    } while ( 1 =3D=3D 0 )
+#else
+#define v4v_dprintk(format, ... ) (void)0
+#endif
+
+/*
+ * Messages on the ring are padded to 128 bits
+ * Len here refers to the exact length of the data not including the
+ * 128 bit header. The message uses
+ * ((len +0xf) & ~0xf) + sizeof(v4v_ring_message_header) bytes
+ */
+#define V4V_ROUNDUP(a) (((a) +0xf ) & ~0xf)
+
+DEFINE_XEN_GUEST_HANDLE(uint8_t);
+static struct v4v_ring_info *v4v_ring_find_info(struct domain *d,
+                                                v4v_ring_id_t *id);
+
+static struct v4v_ring_info *v4v_ring_find_info_by_addr(struct domain *d=
,
+                                                        struct v4v_addr =
*a,
+                                                        domid_t p);
+
+typedef struct internal_v4v_iov
+{
+    XEN_GUEST_HANDLE(v4v_iov_t) guest_iov;
+    v4v_iov_t                   *xen_iov;
+} internal_v4v_iov_t;
+
+struct list_head v4vtables_rules =3D LIST_HEAD_INIT(v4vtables_rules);
+
+/*
+ * locks
+ */
+
+/*
+ * locking is organized as follows:
+ *
+ * the global lock v4v_lock: L1 protects the v4v elements
+ * of all struct domain *d in the system, it does not
+ * protect any of the elements of d->v4v, just their
+ * addresses. By extension since the destruction of
+ * a domain with a non-NULL d->v4v will need to free
+ * the d->v4v pointer, holding this lock gauruntees
+ * that no domains pointers in which v4v is interested
+ * become invalid whilst this lock is held.
+ */
+
+static DEFINE_RWLOCK(v4v_lock); /* L1 */
+
+/*
+ * the lock d->v4v->lock: L2:  Read on protects the hash table and
+ * the elements in the hash_table d->v4v->ring_hash, and
+ * the node and id fields in struct v4v_ring_info in the
+ * hash table. Write on L2 protects all of the elements of
+ * struct v4v_ring_info. To take L2 you must already have R(L1)
+ * W(L1) implies W(L2) and L3
+ *
+ * the lock v4v_ring_info *ringinfo; ringinfo->lock: L3:
+ * protects len,tx_ptr the guest ring, the
+ * guest ring_data and the pending list. To take L3 you must
+ * already have R(L2). W(L2) implies L3
+ */
+
+/*
+ * lock to protect the filtering rules list: v4vtable_rules
+ *
+ * The write lock is held for viptables_del and viptables_add
+ * The read lock is held for viptable_list
+ */
+static DEFINE_RWLOCK(v4vtables_rules_lock);
+
+
+/*
+ * Debugs
+ */
+
+#ifdef V4V_DEBUG
+static void __attribute__((unused))
+v4v_hexdump(void *_p, int len)
+{
+    uint8_t *buf =3D (uint8_t *)_p;
+    int i, j;
+
+    for ( i =3D 0; i < len; i +=3D 16 )
+    {
+        printk(KERN_ERR "%p:", &buf[i]);
+        for ( j =3D 0; j < 16; ++j )
+        {
+            int k =3D i + j;
+            if ( k < len )
+                printk(" %02x", buf[k]);
+            else
+                printk("   ");
+        }
+        printk(" ");
+
+        for ( j =3D 0; j < 16; ++j )
+        {
+            int k =3D i + j;
+            if ( k < len )
+                printk("%c", ((buf[k] > 32) && (buf[k] < 127)) ? buf[k] =
: '.');
+            else
+                printk(" ");
+        }
+        printk("\n");
+    }
+}
+#endif
+
+
+/*
+ * Event channel
+ */
+
+static void
+v4v_signal_domain(struct domain *d)
+{
+    v4v_dprintk("send guest VIRQ_V4V domid:%d\n", d->domain_id);
+
+    evtchn_send(d, d->v4v->evtchn_port);
+}
+
+static void
+v4v_signal_domid(domid_t id)
+{
+    struct domain *d =3D get_domain_by_id(id);
+    if ( !d )
+        return;
+    v4v_signal_domain(d);
+    put_domain(d);
+}
+
+
+/*
+ * ring buffer
+ */
+
+static void
+v4v_ring_unmap(struct v4v_ring_info *ring_info)
+{
+    int i;
+
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    for ( i =3D 0; i < ring_info->npage; ++i )
+    {
+        if ( !ring_info->mfn_mapping[i] )
+            continue;
+        v4v_dprintk("unmapping page %p from %p\n",
+                    (void*)mfn_x(ring_info->mfns[i]),
+                    ring_info->mfn_mapping[i]);
+
+        unmap_domain_page(ring_info->mfn_mapping[i]);
+        ring_info->mfn_mapping[i] =3D NULL;
+    }
+}
+
+static uint8_t *
+v4v_ring_map_page(struct v4v_ring_info *ring_info, int i)
+{
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    if ( i >=3D ring_info->npage )
+        return NULL;
+    if ( ring_info->mfn_mapping[i] )
+        return ring_info->mfn_mapping[i];
+    ring_info->mfn_mapping[i] =3D map_domain_page(mfn_x(ring_info->mfns[=
i]));
+
+    v4v_dprintk("mapping page %p to %p\n",
+                (void *)mfn_x(ring_info->mfns[i]),
+                ring_info->mfn_mapping[i]);
+    return ring_info->mfn_mapping[i];
+}
+
+static int
+v4v_memcpy_from_guest_ring(void *_dst, struct v4v_ring_info *ring_info,
+                           uint32_t offset, uint32_t len)
+{
+    int page =3D offset >> PAGE_SHIFT;
+    uint8_t *src;
+    uint8_t *dst =3D _dst;
+
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    offset &=3D PAGE_SIZE - 1;
+
+    while ( (offset + len) > PAGE_SIZE )
+    {
+        src =3D v4v_ring_map_page(ring_info, page);
+
+        if ( !src )
+            return -EFAULT;
+
+        v4v_dprintk("memcpy(%p,%p+%d,%d)\n",
+                    dst, src, offset,
+                    (int)(PAGE_SIZE - offset));
+        memcpy(dst, src + offset, PAGE_SIZE - offset);
+
+        page++;
+        len -=3D PAGE_SIZE - offset;
+        dst +=3D PAGE_SIZE - offset;
+        offset =3D 0;
+    }
+
+    src =3D v4v_ring_map_page(ring_info, page);
+    if ( !src )
+        return -EFAULT;
+
+    v4v_dprintk("memcpy(%p,%p+%d,%d)\n", dst, src, offset, len);
+    memcpy(dst, src + offset, len);
+
+    return 0;
+}
+
+static int
+v4v_update_tx_ptr(struct v4v_ring_info *ring_info, uint32_t tx_ptr)
+{
+    uint8_t *dst =3D v4v_ring_map_page(ring_info, 0);
+    uint32_t *p =3D (uint32_t *)(dst + offsetof(v4v_ring_t, tx_ptr));
+
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    if ( !dst )
+        return -EFAULT;
+    write_atomic(p, tx_ptr);
+    mb();
+    return 0;
+}
+
+static int
+v4v_copy_from_guest_maybe(void *dst, void *src,
+                          XEN_GUEST_HANDLE(uint8_t) src_hnd,
+                          uint32_t len)
+{
+    int rc =3D 0;
+
+    if ( src )
+        memcpy(dst, src, len);
+    else
+        rc =3D __copy_from_guest(dst, src_hnd, len);
+    return rc;
+}
+
+static int
+v4v_memcpy_to_guest_ring(struct v4v_ring_info *ring_info,
+                         uint32_t offset,
+                         void *src,
+                         XEN_GUEST_HANDLE(uint8_t) src_hnd,
+                         uint32_t len)
+{
+    int page =3D offset >> PAGE_SHIFT;
+    uint8_t *dst;
+
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    offset &=3D PAGE_SIZE - 1;
+
+    while ( (offset + len) > PAGE_SIZE )
+    {
+        dst =3D v4v_ring_map_page(ring_info, page);
+        if ( !dst )
+            return -EFAULT;
+
+        if ( v4v_copy_from_guest_maybe(dst + offset, src, src_hnd,
+                                       PAGE_SIZE - offset) )
+            return -EFAULT;
+
+        page++;
+        len -=3D PAGE_SIZE - offset;
+        if ( src )
+            src +=3D (PAGE_SIZE - offset);
+        else
+            guest_handle_add_offset(src_hnd, PAGE_SIZE - offset);
+        offset =3D 0;
+    }
+
+    dst =3D v4v_ring_map_page(ring_info, page);
+    if ( !dst )
+        return -EFAULT;
+
+    if ( v4v_copy_from_guest_maybe(dst + offset, src, src_hnd, len) )
+        return -EFAULT;
+
+    return 0;
+}
+
+static int
+v4v_ringbuf_get_rx_ptr(struct domain *d, struct v4v_ring_info *ring_info=
,
+                        uint32_t * rx_ptr)
+{
+    v4v_ring_t *ringp;
+
+    if ( ring_info->npage =3D=3D 0 )
+        return -1;
+
+    ringp =3D map_domain_page(mfn_x(ring_info->mfns[0]));
+
+    v4v_dprintk("v4v_ringbuf_payload_space: mapped %p to %p\n",
+                (void *)mfn_x(ring_info->mfns[0]), ringp);
+    if ( !ringp )
+        return -1;
+
+    write_atomic(rx_ptr, ringp->rx_ptr);
+    mb();
+
+    unmap_domain_page(mfn_x(ring_info->mfns[0]));
+    return 0;
+}
+
+uint32_t
+v4v_ringbuf_payload_space(struct domain * d, struct v4v_ring_info * ring=
_info)
+{
+    v4v_ring_t ring;
+    int32_t ret;
+
+    ring.tx_ptr =3D ring_info->tx_ptr;
+    ring.len =3D ring_info->len;
+
+    if ( v4v_ringbuf_get_rx_ptr(d, ring_info, &ring.rx_ptr) )
+        return 0;
+
+    v4v_dprintk("v4v_ringbuf_payload_space:tx_ptr=3D%d rx_ptr=3D%d\n",
+                (int)ring.tx_ptr, (int)ring.rx_ptr);
+    if ( ring.rx_ptr =3D=3D ring.tx_ptr )
+        return ring.len - sizeof (struct v4v_ring_message_header);
+
+    ret =3D ring.rx_ptr - ring.tx_ptr;
+    if ( ret < 0 )
+        ret +=3D ring.len;
+
+    ret -=3D sizeof (struct v4v_ring_message_header);
+    ret -=3D V4V_ROUNDUP(1);
+
+    return (ret < 0) ? 0 : ret;
+}
+
+static long
+v4v_iov_count(XEN_GUEST_HANDLE(v4v_iov_t) iovs, int niov)
+{
+    v4v_iov_t iov;
+    size_t ret =3D 0;
+
+    while ( niov-- )
+    {
+        if ( copy_from_guest(&iov, iovs, 1) )
+            return -EFAULT;
+
+        ret +=3D iov.iov_len;
+
+        /* message bigger than 2G can't be sent */
+        if (ret > 2L * 1024 * 1024 * 1024)
+            return -EMSGSIZE;
+
+        guest_handle_add_offset(iovs, 1);
+    }
+
+    return ret;
+}
+
+static long
+v4v_ringbuf_insertv(struct domain *d,
+                    struct v4v_ring_info *ring_info,
+                    v4v_ring_id_t *src_id, uint32_t proto,
+                    XEN_GUEST_HANDLE(v4v_iov_t) iovs, uint32_t niov,
+                    size_t len)
+{
+    v4v_ring_t ring;
+    struct v4v_ring_message_header mh =3D { 0 };
+    int32_t sp;
+    long happy_ret;
+    int32_t ret =3D 0;
+    XEN_GUEST_HANDLE(uint8_t) empty_hnd =3D { 0 };
+
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    happy_ret =3D len;
+
+    if ( (V4V_ROUNDUP(len) + sizeof (struct v4v_ring_message_header) ) >=
=3D
+            ring_info->len)
+        return -EMSGSIZE;
+
+    do
+    {
+        if ( (ret =3D v4v_memcpy_from_guest_ring(&ring, ring_info, 0,
+                                               sizeof (ring))) )
+            break;
+
+        ring.tx_ptr =3D ring_info->tx_ptr;
+        ring.len =3D ring_info->len;
+
+        v4v_dprintk("ring.tx_ptr=3D%d ring.rx_ptr=3D%d ring.len=3D%d rin=
g_info->tx_ptr=3D%d\n",
+                    ring.tx_ptr, ring.rx_ptr, ring.len, ring_info->tx_pt=
r);
+
+        if ( ring.rx_ptr =3D=3D ring.tx_ptr )
+            sp =3D ring_info->len;
+        else
+        {
+            sp =3D ring.rx_ptr - ring.tx_ptr;
+            if ( sp < 0 )
+                sp +=3D ring.len;
+        }
+
+        if ( (V4V_ROUNDUP(len) + sizeof (struct v4v_ring_message_header)=
) >=3D sp )
+        {
+            v4v_dprintk("EAGAIN\n");
+            ret =3D -EAGAIN;
+            break;
+        }
+
+        mh.len =3D len + sizeof (struct v4v_ring_message_header);
+        mh.source =3D src_id->addr;
+        mh.message_type =3D proto;
+
+        if ( (ret =3D v4v_memcpy_to_guest_ring(ring_info,
+                                             ring.tx_ptr + sizeof (v4v_r=
ing_t),
+                                             &mh, empty_hnd,
+                                             sizeof (mh))) )
+            break;
+
+        ring.tx_ptr +=3D sizeof (mh);
+        if ( ring.tx_ptr =3D=3D ring_info->len )
+            ring.tx_ptr =3D 0;
+
+        while ( niov-- )
+        {
+            XEN_GUEST_HANDLE(uint8_t) buf_hnd;
+            v4v_iov_t iov;
+
+            if ( copy_from_guest(&iov, iovs, 1) )
+            {
+                ret =3D -EFAULT;
+                break;
+            }
+
+            buf_hnd.p =3D (uint8_t *)iov.iov_base; //FIXME
+            len =3D iov.iov_len;
+
+            if ( unlikely(!guest_handle_okay(buf_hnd, len)) )
+            {
+                ret =3D -EFAULT;
+                break;
+            }
+
+            sp =3D ring.len - ring.tx_ptr;
+
+            if ( len > sp )
+            {
+                ret =3D v4v_memcpy_to_guest_ring(ring_info,
+                        ring.tx_ptr + sizeof (v4v_ring_t),
+                        NULL, buf_hnd, sp);
+                if ( ret )
+                    break;
+
+                ring.tx_ptr =3D 0;
+                len -=3D sp;
+                guest_handle_add_offset(buf_hnd, sp);
+            }
+
+            ret =3D v4v_memcpy_to_guest_ring(ring_info,
+                    ring.tx_ptr + sizeof (v4v_ring_t),
+                    NULL, buf_hnd, len);
+            if ( ret )
+                break;
+
+            ring.tx_ptr +=3D len;
+
+            if ( ring.tx_ptr =3D=3D ring_info->len )
+                ring.tx_ptr =3D 0;
+
+            guest_handle_add_offset(iovs, 1);
+        }
+        if ( ret )
+            break;
+
+        ring.tx_ptr =3D V4V_ROUNDUP(ring.tx_ptr);
+
+        if ( ring.tx_ptr >=3D ring_info->len )
+            ring.tx_ptr -=3D ring_info->len;
+
+        mb();
+        ring_info->tx_ptr =3D ring.tx_ptr;
+        if ( (ret =3D v4v_update_tx_ptr(ring_info, ring.tx_ptr)) )
+            break;
+    }
+    while ( 0 );
+
+    v4v_ring_unmap(ring_info);
+
+    return ret ? ret : happy_ret;
+}
+
+
+
+/* pending */
+static void
+v4v_pending_remove_ent(struct v4v_pending_ent *ent)
+{
+    hlist_del(&ent->node);
+    xfree(ent);
+}
+
+static void
+v4v_pending_remove_all(struct v4v_ring_info *info)
+{
+    struct hlist_node *node, *next;
+    struct v4v_pending_ent *pending_ent;
+
+    ASSERT(spin_is_locked(&info->lock));
+    hlist_for_each_entry_safe(pending_ent, node, next, &info->pending,
+            node) v4v_pending_remove_ent(pending_ent);
+}
+
+static void
+v4v_pending_notify(struct domain *caller_d, struct hlist_head *to_notify=
)
+{
+    struct hlist_node *node, *next;
+    struct v4v_pending_ent *pending_ent;
+
+    ASSERT(rw_is_locked(&v4v_lock));
+
+    hlist_for_each_entry_safe(pending_ent, node, next, to_notify, node)
+    {
+        hlist_del(&pending_ent->node);
+        v4v_signal_domid(pending_ent->id);
+        xfree(pending_ent);
+    }
+
+}
+
+static void
+v4v_pending_find(struct domain *d, struct v4v_ring_info *ring_info,
+                 uint32_t payload_space, struct hlist_head *to_notify)
+{
+    struct hlist_node *node, *next;
+    struct v4v_pending_ent *ent;
+
+    ASSERT(rw_is_locked(&d->v4v->lock));
+
+    spin_lock(&ring_info->lock);
+    hlist_for_each_entry_safe(ent, node, next, &ring_info->pending, node=
)
+    {
+        if ( payload_space >=3D ent->len )
+        {
+            hlist_del(&ent->node);
+            hlist_add_head(&ent->node, to_notify);
+        }
+    }
+    spin_unlock(&ring_info->lock);
+}
+
+/*caller must have L3 */
+static int
+v4v_pending_queue(struct v4v_ring_info *ring_info, domid_t src_id, int l=
en)
+{
+    struct v4v_pending_ent *ent =3D xmalloc(struct v4v_pending_ent);
+
+    if ( !ent )
+    {
+        v4v_dprintk("ENOMEM\n");
+        return -ENOMEM;
+    }
+
+    ent->len =3D len;
+    ent->id =3D src_id;
+
+    hlist_add_head(&ent->node, &ring_info->pending);
+
+    return 0;
+}
+
+/* L3 */
+static int
+v4v_pending_requeue(struct v4v_ring_info *ring_info, domid_t src_id, int=
 len)
+{
+    struct hlist_node *node;
+    struct v4v_pending_ent *ent;
+
+    hlist_for_each_entry(ent, node, &ring_info->pending, node)
+    {
+        if ( ent->id =3D=3D src_id )
+        {
+            if ( ent->len < len )
+                ent->len =3D len;
+            return 0;
+        }
+    }
+
+    return v4v_pending_queue(ring_info, src_id, len);
+}
+
+
+/* L3 */
+static void
+v4v_pending_cancel(struct v4v_ring_info *ring_info, domid_t src_id)
+{
+    struct hlist_node *node, *next;
+    struct v4v_pending_ent *ent;
+
+    hlist_for_each_entry_safe(ent, node, next, &ring_info->pending, node=
)
+    {
+        if ( ent->id =3D=3D src_id)
+        {
+            hlist_del(&ent->node);
+            xfree(ent);
+        }
+    }
+}
+
+/*
+ * ring data
+ */
+
+/*Caller should hold R(L1)*/
+static int
+v4v_fill_ring_data(struct domain *src_d,
+                   XEN_GUEST_HANDLE(v4v_ring_data_ent_t) data_ent_hnd)
+{
+    v4v_ring_data_ent_t ent;
+    struct domain *dst_d;
+    struct v4v_ring_info *ring_info;
+
+    if ( copy_from_guest(&ent, data_ent_hnd, 1) )
+    {
+        v4v_dprintk("EFAULT\n");
+        return -EFAULT;
+    }
+
+    v4v_dprintk("v4v_fill_ring_data: ent.ring.domain=3D%d,ent.ring.port=3D=
%u\n",
+                (int)ent.ring.domain, (int)ent.ring.port);
+
+    ent.flags =3D 0;
+
+    dst_d =3D get_domain_by_id(ent.ring.domain);
+
+    if ( dst_d && dst_d->v4v )
+    {
+        read_lock(&dst_d->v4v->lock);
+        ring_info =3D v4v_ring_find_info_by_addr(dst_d, &ent.ring,
+                                               src_d->domain_id);
+
+        if ( ring_info )
+        {
+            uint32_t space_avail;
+
+            ent.flags |=3D V4V_RING_DATA_F_EXISTS;
+            ent.max_message_size =3D
+                ring_info->len - sizeof (struct v4v_ring_message_header)=
 -
+                V4V_ROUNDUP(1);
+            spin_lock(&ring_info->lock);
+
+            space_avail =3D v4v_ringbuf_payload_space(dst_d, ring_info);
+
+            if ( space_avail >=3D ent.space_required )
+            {
+                v4v_pending_cancel(ring_info, src_d->domain_id);
+                ent.flags |=3D V4V_RING_DATA_F_SUFFICIENT;
+            }
+            else
+            {
+                v4v_pending_requeue(ring_info, src_d->domain_id,
+                        ent.space_required);
+                ent.flags |=3D V4V_RING_DATA_F_PENDING;
+            }
+
+            spin_unlock(&ring_info->lock);
+
+            if ( space_avail =3D=3D ent.max_message_size )
+                ent.flags |=3D V4V_RING_DATA_F_EMPTY;
+
+        }
+        read_unlock(&dst_d->v4v->lock);
+    }
+
+    if ( dst_d )
+        put_domain(dst_d);
+
+    if ( copy_field_to_guest(data_ent_hnd, &ent, flags) )
+    {
+        v4v_dprintk("EFAULT\n");
+        return -EFAULT;
+    }
+    return 0;
+}
+
+/*Called should hold no more than R(L1) */
+static int
+v4v_fill_ring_datas(struct domain *d, int nent,
+                     XEN_GUEST_HANDLE(v4v_ring_data_ent_t) data_ent_hnd)
+{
+    int ret =3D 0;
+
+    read_lock(&v4v_lock);
+    while ( !ret && nent-- )
+    {
+        ret =3D v4v_fill_ring_data(d, data_ent_hnd);
+        guest_handle_add_offset(data_ent_hnd, 1);
+    }
+    read_unlock(&v4v_lock);
+    return ret;
+}
+
+/*
+ * ring
+ */
+static int
+v4v_find_ring_mfns(struct domain *d, struct v4v_ring_info *ring_info,
+                   uint32_t npage, XEN_GUEST_HANDLE(v4v_pfn_t) pfn_hnd)
+{
+    int i,j;
+    mfn_t *mfns;
+    uint8_t **mfn_mapping;
+    unsigned long mfn;
+    struct page_info *page;
+    int ret =3D 0;
+
+    if ( (npage << PAGE_SHIFT) < ring_info->len )
+    {
+        v4v_dprintk("EINVAL\n");
+        return -EINVAL;
+    }
+
+    mfns =3D xmalloc_array(mfn_t, npage);
+    if ( !mfns )
+    {
+        v4v_dprintk("ENOMEM\n");
+        return -ENOMEM;
+    }
+
+    mfn_mapping =3D xmalloc_array(uint8_t *, npage);
+    if ( !mfn_mapping )
+    {
+        xfree(mfns);
+        return -ENOMEM;
+    }
+
+    for ( i =3D 0; i < npage; ++i )
+    {
+        unsigned long pfn;
+        p2m_type_t p2mt;
+
+        if ( copy_from_guest_offset(&pfn, pfn_hnd, i, 1) )
+        {
+            ret =3D -EFAULT;
+            v4v_dprintk("EFAULT\n");
+            break;
+        }
+
+        mfn =3D mfn_x(get_gfn(d, pfn, &p2mt));
+        if ( !mfn_valid(mfn) )
+        {
+            printk(KERN_ERR "v4v domain %d passed invalid mfn %"PRI_mfn"=
 ring %p seq %d\n",
+                    d->domain_id, mfn, ring_info, i);
+            ret =3D -EINVAL;
+            break;
+        }
+        page =3D mfn_to_page(mfn);
+        if ( !get_page_and_type(page, d, PGT_writable_page) )
+        {
+            printk(KERN_ERR "v4v domain %d passed wrong type mfn %"PRI_m=
fn" ring %p seq %d\n",
+                    d->domain_id, mfn, ring_info, i);
+            ret =3D -EINVAL;
+            break;
+        }
+        mfns[i] =3D _mfn(mfn);
+        v4v_dprintk("v4v_find_ring_mfns: %d: %lx -> %lx\n",
+                    i, (unsigned long)pfn, (unsigned long)mfn_x(mfns[i])=
);
+        mfn_mapping[i] =3D NULL;
+        put_gfn(d, pfn);
+    }
+
+    if ( !ret )
+    {
+        ring_info->npage =3D npage;
+        ring_info->mfns =3D mfns;
+        ring_info->mfn_mapping =3D mfn_mapping;
+    }
+    else
+    {
+        j =3D i;
+        for ( i =3D 0; i < j; ++i )
+            if ( mfn_x(mfns[i]) !=3D 0 )
+                put_page_and_type(mfn_to_page(mfn_x(mfns[i])));
+        xfree(mfn_mapping);
+        xfree(mfns);
+    }
+    return ret;
+}
+
+
+static struct v4v_ring_info *
+v4v_ring_find_info(struct domain *d, v4v_ring_id_t *id)
+{
+    uint16_t hash;
+    struct hlist_node *node;
+    struct v4v_ring_info *ring_info;
+
+    ASSERT(rw_is_locked(&d->v4v->lock));
+
+    hash =3D v4v_hash_fn(id);
+
+    v4v_dprintk("ring_find_info: d->v4v=3D%p, d->v4v->ring_hash[%d]=3D%p=
 id=3D%p\n",
+                d->v4v, (int)hash, d->v4v->ring_hash[hash].first, id);
+    v4v_dprintk("ring_find_info: id.addr.port=3D%d id.addr.domain=3D%d i=
d.addr.partner=3D%d\n",
+                id->addr.port, id->addr.domain, id->partner);
+
+    hlist_for_each_entry(ring_info, node, &d->v4v->ring_hash[hash], node=
)
+    {
+        v4v_ring_id_t *cmpid =3D &ring_info->id;
+
+        if ( cmpid->addr.port =3D=3D id->addr.port &&
+             cmpid->addr.domain =3D=3D id->addr.domain &&
+             cmpid->partner =3D=3D id->partner)
+        {
+            v4v_dprintk("ring_find_info: ring_info=3D%p\n", ring_info);
+            return ring_info;
+        }
+    }
+    v4v_dprintk("ring_find_info: no ring_info found\n");
+    return NULL;
+}
+
+static struct v4v_ring_info *
+v4v_ring_find_info_by_addr(struct domain *d, struct v4v_addr *a, domid_t=
 p)
+{
+    v4v_ring_id_t id;
+    struct v4v_ring_info *ret;
+
+    ASSERT(rw_is_locked(&d->v4v->lock));
+
+    if ( !a )
+        return NULL;
+
+    id.addr.port =3D a->port;
+    id.addr.domain =3D d->domain_id;
+    id.partner =3D p;
+
+    ret =3D v4v_ring_find_info(d, &id);
+    if ( ret )
+        return ret;
+
+    id.partner =3D V4V_DOMID_ANY;
+
+    return v4v_ring_find_info(d, &id);
+}
+
+static void v4v_ring_remove_mfns(struct domain *d, struct v4v_ring_info =
*ring_info)
+{
+    int i;
+
+    ASSERT(rw_is_write_locked(&d->v4v->lock));
+
+    if ( ring_info->mfns )
+    {
+        for ( i =3D 0; i < ring_info->npage; ++i )
+            if ( mfn_x(ring_info->mfns[i]) !=3D 0 )
+                put_page_and_type(mfn_to_page(mfn_x(ring_info->mfns[i]))=
);
+        xfree(ring_info->mfns);
+    }
+    if ( ring_info->mfn_mapping )
+        xfree(ring_info->mfn_mapping);
+    ring_info->mfns =3D NULL;
+
+}
+
+static void
+v4v_ring_remove_info(struct domain *d, struct v4v_ring_info *ring_info)
+{
+    ASSERT(rw_is_write_locked(&d->v4v->lock));
+
+    spin_lock(&ring_info->lock);
+
+    v4v_pending_remove_all(ring_info);
+    hlist_del(&ring_info->node);
+    v4v_ring_remove_mfns(d, ring_info);
+
+    spin_unlock(&ring_info->lock);
+
+    xfree(ring_info);
+}
+
+/* Call from guest to unpublish a ring */
+static long
+v4v_ring_remove(struct domain *d, XEN_GUEST_HANDLE(v4v_ring_t) ring_hnd)
+{
+    struct v4v_ring ring;
+    struct v4v_ring_info *ring_info;
+    int ret =3D 0;
+
+    read_lock(&v4v_lock);
+
+    do
+    {
+        if ( !d->v4v )
+        {
+            v4v_dprintk("EINVAL\n");
+            ret =3D -EINVAL;
+            break;
+        }
+
+        if ( copy_from_guest(&ring, ring_hnd, 1) )
+        {
+            v4v_dprintk("EFAULT\n");
+            ret =3D -EFAULT;
+            break;
+        }
+
+        if ( ring.magic !=3D V4V_RING_MAGIC )
+        {
+            v4v_dprintk("ring.magic(%"PRIx64") !=3D V4V_RING_MAGIC(%"PRI=
x64"), EINVAL\n",
+                    ring.magic, V4V_RING_MAGIC);
+            ret =3D -EINVAL;
+            break;
+        }
+
+        ring.id.addr.domain =3D d->domain_id;
+
+        write_lock(&d->v4v->lock);
+        ring_info =3D v4v_ring_find_info(d, &ring.id);
+
+        if ( ring_info )
+            v4v_ring_remove_info(d, ring_info);
+
+        write_unlock(&d->v4v->lock);
+
+        if ( !ring_info )
+        {
+            v4v_dprintk("ENOENT\n");
+            ret =3D -ENOENT;
+            break;
+        }
+
+    }
+    while ( 0 );
+
+    read_unlock(&v4v_lock);
+    return ret;
+}
+
+/* call from guest to publish a ring */
+static long
+v4v_ring_add(struct domain *d, XEN_GUEST_HANDLE(v4v_ring_t) ring_hnd,
+             uint32_t npage, XEN_GUEST_HANDLE(v4v_pfn_t) pfn_hnd)
+{
+    struct v4v_ring ring;
+    struct v4v_ring_info *ring_info;
+    int need_to_insert =3D 0;
+    int ret =3D 0;
+
+    if ( (long)ring_hnd.p & (PAGE_SIZE - 1) )
+    {
+        v4v_dprintk("EINVAL\n");
+        return -EINVAL;
+    }
+
+    read_lock(&v4v_lock);
+    do
+    {
+        if ( !d->v4v )
+        {
+            v4v_dprintk(" !d->v4v, EINVAL\n");
+            ret =3D -EINVAL;
+            break;
+        }
+
+        if ( copy_from_guest(&ring, ring_hnd, 1) )
+        {
+            v4v_dprintk(" copy_from_guest failed, EFAULT\n");
+            ret =3D -EFAULT;
+            break;
+        }
+
+        if ( ring.magic !=3D V4V_RING_MAGIC )
+        {
+            v4v_dprintk("ring.magic(%lx) !=3D V4V_RING_MAGIC(%lx), EINVA=
L\n",
+                        ring.magic, V4V_RING_MAGIC);
+            ret =3D -EINVAL;
+            break;
+        }
+
+        if ( (ring.len <
+                    (sizeof (struct v4v_ring_message_header) + V4V_ROUND=
UP(1) +
+                     V4V_ROUNDUP(1))) || (V4V_ROUNDUP(ring.len) !=3D rin=
g.len) )
+        {
+            v4v_dprintk("EINVAL\n");
+            ret =3D -EINVAL;
+            break;
+        }
+
+        ring.id.addr.domain =3D d->domain_id;
+        if ( copy_field_to_guest(ring_hnd, &ring, id) )
+        {
+            v4v_dprintk("EFAULT\n");
+            ret =3D -EFAULT;
+            break;
+        }
+
+        /*
+         * no need for a lock yet, because only we know about this
+         * set the tx pointer if it looks bogus (we don't reset it
+         * because this might be a re-register after S4)
+         */
+        if ( (ring.tx_ptr >=3D ring.len)
+                || (V4V_ROUNDUP(ring.tx_ptr) !=3D ring.tx_ptr) )
+        {
+            ring.tx_ptr =3D ring.rx_ptr;
+        }
+        copy_field_to_guest(ring_hnd, &ring, tx_ptr);
+
+        read_lock(&d->v4v->lock);
+        ring_info =3D v4v_ring_find_info(d, &ring.id);
+
+        if ( !ring_info )
+        {
+            read_unlock(&d->v4v->lock);
+            ring_info =3D xmalloc(struct v4v_ring_info);
+            if ( !ring_info )
+            {
+                v4v_dprintk("ENOMEM\n");
+                ret =3D -ENOMEM;
+                break;
+            }
+            need_to_insert++;
+            spin_lock_init(&ring_info->lock);
+            INIT_HLIST_HEAD(&ring_info->pending);
+            ring_info->mfns =3D NULL;
+
+        }
+        else
+        {
+            /*
+             * Ring info already existed.
+             */
+            printk(KERN_INFO "v4v: dom%d ring already registered\n",
+                    current->domain->domain_id);
+            ret =3D -EEXIST;
+            break;
+        }
+
+        spin_lock(&ring_info->lock);
+        ring_info->id =3D ring.id;
+        ring_info->len =3D ring.len;
+        ring_info->tx_ptr =3D ring.tx_ptr;
+        ring_info->ring =3D ring_hnd;
+        if ( ring_info->mfns )
+            xfree(ring_info->mfns);
+        ret =3D v4v_find_ring_mfns(d, ring_info, npage, pfn_hnd);
+        spin_unlock(&ring_info->lock);
+        if ( ret )
+            break;
+
+        if ( !need_to_insert )
+        {
+            read_unlock(&d->v4v->lock);
+        }
+        else
+        {
+            uint16_t hash =3D v4v_hash_fn(&ring.id);
+            write_lock(&d->v4v->lock);
+            hlist_add_head(&ring_info->node, &d->v4v->ring_hash[hash]);
+            write_unlock(&d->v4v->lock);
+        }
+    }
+    while ( 0 );
+
+    read_unlock(&v4v_lock);
+    return ret;
+}
+
+
+/*
+ * io
+ */
+
+static void
+v4v_notify_ring(struct domain *d, struct v4v_ring_info *ring_info,
+                struct hlist_head *to_notify)
+{
+    uint32_t space;
+
+    ASSERT(rw_is_locked(&v4v_lock));
+    ASSERT(rw_is_locked(&d->v4v->lock));
+
+    spin_lock(&ring_info->lock);
+    space =3D v4v_ringbuf_payload_space(d, ring_info);
+    spin_unlock(&ring_info->lock);
+
+    v4v_pending_find(d, ring_info, space, to_notify);
+}
+
+/*notify hypercall*/
+static long
+v4v_notify(struct domain *d,
+           XEN_GUEST_HANDLE(v4v_ring_data_t) ring_data_hnd)
+{
+    v4v_ring_data_t ring_data;
+    HLIST_HEAD(to_notify);
+    int i;
+    int ret =3D 0;
+
+    read_lock(&v4v_lock);
+
+    if ( !d->v4v )
+    {
+        read_unlock(&v4v_lock);
+        v4v_dprintk("!d->v4v, ENODEV\n");
+        return -ENODEV;
+    }
+
+    read_lock(&d->v4v->lock);
+    for ( i =3D 0; i < V4V_HTABLE_SIZE; ++i )
+    {
+        struct hlist_node *node, *next;
+        struct v4v_ring_info *ring_info;
+
+        hlist_for_each_entry_safe(ring_info, node,
+                next, &d->v4v->ring_hash[i],
+                node)
+        {
+            v4v_notify_ring(d, ring_info, &to_notify);
+        }
+    }
+    read_unlock(&d->v4v->lock);
+
+    if ( !hlist_empty(&to_notify) )
+        v4v_pending_notify(d, &to_notify);
+
+    do
+    {
+        if ( !guest_handle_is_null(ring_data_hnd) )
+        {
+            /* Quick sanity check on ring_data_hnd */
+            if ( copy_field_from_guest(&ring_data, ring_data_hnd, magic)=
 )
+            {
+                v4v_dprintk("copy_field_from_guest failed\n");
+                ret =3D -EFAULT;
+                break;
+            }
+
+            if ( ring_data.magic !=3D V4V_RING_DATA_MAGIC )
+            {
+                v4v_dprintk("ring.magic(%lx) !=3D V4V_RING_MAGIC(%lx), E=
INVAL\n",
+                        ring_data.magic, V4V_RING_MAGIC);
+                ret =3D -EINVAL;
+                break;
+            }
+
+            if ( copy_from_guest(&ring_data, ring_data_hnd, 1) )
+            {
+                v4v_dprintk("copy_from_guest failed\n");
+                ret =3D -EFAULT;
+                break;
+            }
+
+            {
+                XEN_GUEST_HANDLE(v4v_ring_data_ent_t) ring_data_ent_hnd;
+                ring_data_ent_hnd =3D
+                    guest_handle_for_field(ring_data_hnd, v4v_ring_data_=
ent_t, data[0]);
+                ret =3D v4v_fill_ring_datas(d, ring_data.nent, ring_data=
_ent_hnd);
+            }
+        }
+    }
+    while ( 0 );
+
+    read_unlock(&v4v_lock);
+
+    return ret;
+}
+
+#ifdef V4V_DEBUG
+void
+v4vtables_print_rule(struct v4vtables_rule_node *node)
+{
+    v4vtables_rule_t *rule;
+
+    if ( node =3D=3D NULL )
+    {
+        printk("(null)\n");
+        return;
+    }
+
+    rule =3D &node->rule;
+
+    if ( rule->accept =3D=3D 1 )
+        printk("ACCEPT");
+    else
+        printk("REJECT");
+
+    printk(" ");
+
+    if ( rule->src.domain =3D=3D V4V_DOMID_ANY )
+        printk("*");
+    else
+        printk("%i", rule->src.domain);
+
+    printk(":");
+
+    if ( rule->src.port =3D=3D -1 )
+        printk("*");
+    else
+        printk("%i", rule->src.port);
+
+    printk(" -> ");
+
+    if ( rule->dst.domain =3D=3D V4V_DOMID_ANY )
+        printk("*");
+    else
+        printk("%i", rule->dst.domain);
+
+    printk(":");
+
+    if ( rule->dst.port =3D=3D -1 )
+        printk("*");
+    else
+        printk("%i", rule->dst.port);
+
+    printk("\n");
+}
+#endif /* V4V_DEBUG */
+
+int
+v4vtables_add(struct domain *src_d,
+              XEN_GUEST_HANDLE(v4vtables_rule_t) rule,
+              int32_t position)
+{
+    struct v4vtables_rule_node* new =3D NULL;
+    struct list_head* tmp;
+
+    ASSERT(rw_is_write_locked(&v4vtables_rules_lock));
+
+    /* First rule is n.1 */
+    position--;
+
+    new =3D xmalloc(struct v4vtables_rule_node);
+    if ( new =3D=3D NULL )
+        return -ENOMEM;
+
+    if ( copy_from_guest(&new->rule, rule, 1) )
+    {
+        xfree(new);
+        return -EFAULT;
+    }
+
+#ifdef V4V_DEBUG
+    printk(KERN_ERR "VIPTables: ");
+    v4vtables_print_rule(new);
+#endif /* V4V_DEBUG */
+
+    tmp =3D &v4vtables_rules;
+    while ( position !=3D 0 && tmp->next !=3D &v4vtables_rules)
+    {
+        tmp =3D tmp->next;
+        position--;
+    }
+    list_add(&new->list, tmp);
+
+    return 0;
+}
+
+int
+v4vtables_del(struct domain *src_d,
+              XEN_GUEST_HANDLE(v4vtables_rule_t) rule_hnd,
+              int32_t position)
+{
+    struct list_head *tmp =3D NULL;
+    struct list_head *to_delete =3D NULL;
+    struct list_head *next =3D NULL;
+    struct v4vtables_rule_node *node;
+
+    ASSERT(rw_is_write_locked(&v4vtables_rules_lock));
+
+    v4v_dprintk("v4vtables_del position:%d\n", position);
+
+    if ( position !=3D -1 )
+    {
+        /* We want to delete the rule number  */
+        list_for_each(tmp, &v4vtables_rules)
+        {
+            to_delete =3D tmp;
+            if (position =3D=3D 0)
+                break;
+            position--;
+        }
+        /* Can't find the position */
+        if (position !=3D 0)
+            to_delete =3D NULL;
+    }
+    else if ( !guest_handle_is_null(rule_hnd) )
+    {
+        struct v4vtables_rule r;
+
+        if ( copy_from_guest(&r, rule_hnd, 1) )
+            return -EFAULT;
+
+        list_for_each(tmp, &v4vtables_rules)
+        {
+            node =3D list_entry(tmp, struct v4vtables_rule_node, list);
+
+            if ( (node->rule.src.domain =3D=3D r.src.domain) &&
+                 (node->rule.src.port   =3D=3D r.src.port)   &&
+                 (node->rule.dst.domain =3D=3D r.dst.domain) &&
+                 (node->rule.dst.port   =3D=3D r.dst.port))
+            {
+                to_delete =3D tmp;
+                break;
+            }
+        }
+    }
+    else
+    {
+        /* We want to flush the rules! */
+        printk(KERN_ERR "VIPTables: flushing rules\n");
+        list_for_each_safe(tmp, next, &v4vtables_rules)
+        {
+            node =3D list_entry(tmp, struct v4vtables_rule_node, list);
+            list_del(tmp);
+            xfree(node);
+        }
+    }
+
+    if ( to_delete )
+    {
+        node =3D list_entry(to_delete, struct v4vtables_rule_node, list)=
;
+#ifdef V4V_DEBUG
+        printk(KERN_ERR "VIPTables: deleting rule: ");
+        v4vtables_print_rule(node);
+#endif /* V4V_DEBUG */
+        list_del(to_delete);
+        xfree(node);
+    }
+
+    return 0;
+}
+
+static size_t
+v4vtables_list(struct domain *src_d,
+               XEN_GUEST_HANDLE(v4vtables_list_t) list_hnd)
+{
+    struct list_head *ptr;
+    struct v4vtables_rule_node *node;
+    struct v4vtables_list rules_list;
+    uint32_t nbrules;
+    XEN_GUEST_HANDLE(v4vtables_rule_t) guest_rules;
+
+    ASSERT(rw_is_locked(&v4vtables_rules_lock));
+
+    memset(&rules_list, 0, sizeof (rules_list));
+    if ( copy_from_guest(&rules_list, list_hnd, 1) )
+        return -EFAULT;
+
+    ptr =3D v4vtables_rules.next;
+    while ( rules_list.start_rule !=3D 0 && ptr->next !=3D &v4vtables_ru=
les )
+    {
+        ptr =3D ptr->next;
+        rules_list.start_rule--;
+    }
+
+    if ( rules_list.nb_rules =3D=3D 0 )
+        return -EINVAL;
+
+    guest_rules =3D guest_handle_for_field(list_hnd, v4vtables_rule_t, r=
ules[0]);
+
+    nbrules =3D 0;
+    while ( nbrules < rules_list.nb_rules && ptr !=3D &v4vtables_rules )
+    {
+        node =3D list_entry(ptr, struct v4vtables_rule_node, list);
+
+        if ( copy_to_guest(guest_rules, &node->rule, 1) )
+            break;
+
+        guest_handle_add_offset(guest_rules, 1);
+
+        nbrules++;
+        ptr =3D ptr->next;
+    }
+
+    rules_list.nb_rules =3D nbrules;
+    if ( copy_field_to_guest(list_hnd, &rules_list, nb_rules) )
+        return -EFAULT;
+
+    return 0;
+}
+
+static size_t
+v4vtables_check(v4v_addr_t * src, v4v_addr_t * dst)
+{
+    struct list_head *ptr;
+    struct v4vtables_rule_node *node;
+    size_t ret =3D 0; /* Defaulting to ACCEPT */
+
+    read_lock(&v4vtables_rules_lock);
+
+    list_for_each(ptr, &v4vtables_rules)
+    {
+        node =3D list_entry(ptr, struct v4vtables_rule_node, list);
+
+        if ( (node->rule.src.domain =3D=3D V4V_DOMID_ANY ||
+              node->rule.src.domain =3D=3D src->domain) &&
+             (node->rule.src.port =3D=3D V4V_PORT_ANY ||
+              node->rule.src.port =3D=3D src->port) &&
+             (node->rule.dst.domain =3D=3D V4V_DOMID_ANY ||
+              node->rule.dst.domain =3D=3D dst->domain) &&
+             (node->rule.dst.port =3D=3D V4V_PORT_ANY ||
+              node->rule.dst.port =3D=3D dst->port) )
+        {
+            ret =3D !node->rule.accept;
+            break;
+        }
+    }
+
+    read_unlock(&v4vtables_rules_lock);
+    return ret;
+}
+
+/*
+ * Hypercall to do the send
+ */
+static long
+v4v_sendv(struct domain *src_d, v4v_addr_t * src_addr,
+          v4v_addr_t * dst_addr, uint32_t proto,
+          XEN_GUEST_HANDLE(v4v_iov_t) iovs, size_t niov)
+{
+    struct domain *dst_d;
+    v4v_ring_id_t src_id;
+    struct v4v_ring_info *ring_info;
+    int ret =3D 0;
+
+    if ( !dst_addr )
+    {
+        v4v_dprintk("!dst_addr, EINVAL\n");
+        return -EINVAL;
+    }
+
+    read_lock(&v4v_lock);
+    if ( !src_d->v4v )
+    {
+        read_unlock(&v4v_lock);
+        v4v_dprintk("!src_d->v4v, EINVAL\n");
+        return -EINVAL;
+    }
+
+    src_id.addr.port =3D src_addr->port;
+    src_id.addr.domain =3D src_d->domain_id;
+    src_id.partner =3D dst_addr->domain;
+
+    dst_d =3D get_domain_by_id(dst_addr->domain);
+    if ( !dst_d )
+    {
+        read_unlock(&v4v_lock);
+        v4v_dprintk("!dst_d, ECONNREFUSED\n");
+        return -ECONNREFUSED;
+    }
+
+    if ( v4vtables_check(src_addr, dst_addr) !=3D 0 )
+    {
+        read_unlock(&v4v_lock);
+        gdprintk(XENLOG_WARNING,
+                 "V4V: VIPTables REJECTED %i:%i -> %i:%i\n",
+                 src_addr->domain, src_addr->port,
+                 dst_addr->domain, dst_addr->port);
+        return -ECONNREFUSED;
+    }
+
+    do
+    {
+        if ( !dst_d->v4v )
+        {
+            v4v_dprintk("dst_d->v4v, ECONNREFUSED\n");
+            ret =3D -ECONNREFUSED;
+            break;
+        }
+
+        read_lock(&dst_d->v4v->lock);
+        ring_info =3D
+            v4v_ring_find_info_by_addr(dst_d, dst_addr, src_addr->domain=
);
+
+        if ( !ring_info )
+        {
+            ret =3D -ECONNREFUSED;
+            v4v_dprintk(" !ring_info, ECONNREFUSED\n");
+        }
+        else
+        {
+            long len =3D v4v_iov_count(iovs, niov);
+
+            if ( len < 0 )
+            {
+                ret =3D len;
+                break;
+            }
+
+            spin_lock(&ring_info->lock);
+            ret =3D
+                v4v_ringbuf_insertv(dst_d, ring_info, &src_id, proto, io=
vs,
+                        niov, len);
+            if ( ret =3D=3D -EAGAIN )
+            {
+                v4v_dprintk("v4v_ringbuf_insertv failed, EAGAIN\n");
+                /* Schedule a wake up on the event channel when space is=
 there */
+                if ( v4v_pending_requeue(ring_info, src_d->domain_id, le=
n) )
+                {
+                    v4v_dprintk("v4v_pending_requeue failed, ENOMEM\n");
+                    ret =3D -ENOMEM;
+                }
+            }
+            spin_unlock(&ring_info->lock);
+
+            if ( ret >=3D 0 )
+            {
+                v4v_signal_domain(dst_d);
+            }
+
+        }
+        read_unlock(&dst_d->v4v->lock);
+
+    }
+    while ( 0 );
+
+    put_domain(dst_d);
+    read_unlock(&v4v_lock);
+    return ret;
+}
+
+static void
+v4v_info(struct domain *d, v4v_info_t *info)
+{
+    read_lock(&d->v4v->lock);
+    info->ring_magic =3D V4V_RING_MAGIC;
+    info->data_magic =3D V4V_RING_DATA_MAGIC;
+    info->evtchn =3D d->v4v->evtchn_port;
+    read_unlock(&d->v4v->lock);
+}
+
+/*
+ * hypercall glue
+ */
+long
+do_v4v_op(int cmd, XEN_GUEST_HANDLE(void) arg1,
+          XEN_GUEST_HANDLE(void) arg2,
+          uint32_t arg3, uint32_t arg4)
+{
+    struct domain *d =3D current->domain;
+    long rc =3D -EFAULT;
+
+    v4v_dprintk("->do_v4v_op(%d,%p,%p,%d,%d)\n", cmd,
+                (void *)arg1.p, (void *)arg2.p, (int) arg3, (int) arg4);
+
+    domain_lock(d);
+    switch (cmd)
+    {
+        case V4VOP_register_ring:
+            {
+                XEN_GUEST_HANDLE(v4v_ring_t) ring_hnd =3D
+                    guest_handle_cast(arg1, v4v_ring_t);
+                XEN_GUEST_HANDLE(v4v_pfn_t) pfn_hnd =3D
+                    guest_handle_cast(arg2, v4v_pfn_t);
+                uint32_t npage =3D arg3;
+                if ( unlikely(!guest_handle_okay(pfn_hnd, npage)) )
+                    goto out;
+                rc =3D v4v_ring_add(d, ring_hnd, npage, pfn_hnd);
+                break;
+            }
+        case V4VOP_unregister_ring:
+            {
+                XEN_GUEST_HANDLE(v4v_ring_t) ring_hnd =3D
+                    guest_handle_cast(arg1, v4v_ring_t);
+                rc =3D v4v_ring_remove(d, ring_hnd);
+                break;
+            }
+        case V4VOP_sendv:
+            {
+                uint32_t niov =3D arg3;
+                uint32_t message_type =3D arg4;
+                XEN_GUEST_HANDLE(v4v_send_addr_t) addr_hnd =3D
+                    guest_handle_cast(arg1, v4v_send_addr_t);
+                v4v_send_addr_t addr;
+
+                if ( copy_from_guest(&addr, addr_hnd, 1) )
+                    goto out;
+
+                rc =3D v4v_sendv(d, &addr.src, &addr.dst, message_type,
+                        guest_handle_cast(arg2, v4v_iov_t), niov);
+                break;
+            }
+        case V4VOP_notify:
+            {
+                XEN_GUEST_HANDLE(v4v_ring_data_t) ring_data_hnd =3D
+                    guest_handle_cast(arg1, v4v_ring_data_t);
+                rc =3D v4v_notify(d, ring_data_hnd);
+                break;
+            }
+        case V4VOP_tables_add:
+            {
+                uint32_t position =3D arg3;
+                XEN_GUEST_HANDLE(v4vtables_rule_t) rule_hnd =3D
+                    guest_handle_cast(arg1, v4vtables_rule_t);
+                rc =3D -EPERM;
+                if ( !IS_PRIV(d) )
+                    goto out;
+
+                write_lock(&v4vtables_rules_lock);
+                rc =3D v4vtables_add(d, rule_hnd, position);
+                write_unlock(&v4vtables_rules_lock);
+                break;
+            }
+        case V4VOP_tables_del:
+            {
+                uint32_t position =3D arg3;
+                XEN_GUEST_HANDLE(v4vtables_rule_t) rule_hnd =3D
+                    guest_handle_cast(arg1, v4vtables_rule_t);
+                rc =3D -EPERM;
+                if ( !IS_PRIV(d) )
+                    goto out;
+
+                write_lock(&v4vtables_rules_lock);
+                rc =3D v4vtables_del(d, rule_hnd, position);
+                write_unlock(&v4vtables_rules_lock);
+                break;
+            }
+        case V4VOP_tables_list:
+            {
+                XEN_GUEST_HANDLE(v4vtables_list_t) rules_list_hnd =3D
+                    guest_handle_cast(arg1, v4vtables_list_t);
+                rc =3D -EPERM;
+                if ( !IS_PRIV(d) )
+                    goto out;
+
+                read_lock(&v4vtables_rules_lock);
+                rc =3D v4vtables_list(d, rules_list_hnd);
+                read_unlock(&v4vtables_rules_lock);
+                break;
+            }
+        case V4VOP_info:
+            {
+                XEN_GUEST_HANDLE(v4v_info_t) info_hnd =3D
+                    guest_handle_cast(arg1, v4v_info_t);
+                v4v_info_t info;
+
+                if ( unlikely(!guest_handle_okay(info_hnd, 1)) )
+                    goto out;
+                v4v_info(d, &info);
+                if ( __copy_to_guest(info_hnd, &info, 1) )
+                    goto out;
+                rc =3D 0;
+                break;
+            }
+        default:
+            rc =3D -ENOSYS;
+            break;
+    }
+out:
+    domain_unlock(d);
+    v4v_dprintk("<-do_v4v_op()=3D%d\n", (int)rc);
+    return rc;
+}
+
+/*
+ * init
+ */
+
+void
+v4v_destroy(struct domain *d)
+{
+    int i;
+
+    BUG_ON(!d->is_dying);
+    write_lock(&v4v_lock);
+
+    v4v_dprintk("d->v=3D%p\n", d->v4v);
+
+    if ( d->v4v )
+    {
+        for ( i =3D 0; i < V4V_HTABLE_SIZE; ++i )
+        {
+            struct hlist_node *node, *next;
+            struct v4v_ring_info *ring_info;
+
+            hlist_for_each_entry_safe(ring_info, node,
+                    next, &d->v4v->ring_hash[i],
+                    node)
+            {
+                v4v_ring_remove_info(d, ring_info);
+            }
+        }
+    }
+
+    d->v4v =3D NULL;
+    write_unlock(&v4v_lock);
+}
+
+int
+v4v_init(struct domain *d)
+{
+    struct v4v_domain *v4v;
+    evtchn_port_t port;
+    int i;
+    int rc;
+
+    v4v =3D xmalloc(struct v4v_domain);
+    if ( !v4v )
+        return -ENOMEM;
+
+    rc =3D evtchn_alloc_unbound_domain(d, &port, d->domain_id);
+    if ( rc )
+        return rc;
+
+    rwlock_init(&v4v->lock);
+
+    v4v->evtchn_port =3D port;
+    for ( i =3D 0; i < V4V_HTABLE_SIZE; ++i )
+        INIT_HLIST_HEAD(&v4v->ring_hash[i]);
+
+    write_lock(&v4v_lock);
+    d->v4v =3D v4v;
+    write_unlock(&v4v_lock);
+
+    return 0;
+}
+
+
+/*
+ * debug
+ */
+
+static void
+dump_domain_ring(struct domain *d, struct v4v_ring_info *ring_info)
+{
+    uint32_t rx_ptr;
+
+    printk(KERN_ERR "  ring: domid=3D%d port=3D0x%08x partner=3D%d npage=
=3D%d\n",
+           (int)d->domain_id, (int)ring_info->id.addr.port,
+           (int)ring_info->id.partner, (int)ring_info->npage);
+
+    if ( v4v_ringbuf_get_rx_ptr(d, ring_info, &rx_ptr) )
+    {
+        printk(KERN_ERR "   Failed to read rx_ptr\n");
+        return;
+    }
+
+    printk(KERN_ERR "   tx_ptr=3D%d rx_ptr=3D%d len=3D%d\n",
+           (int)ring_info->tx_ptr, (int)rx_ptr, (int)ring_info->len);
+}
+
+static void
+dump_domain(struct domain *d)
+{
+    int i;
+
+    printk(KERN_ERR " domain %d:\n", (int)d->domain_id);
+
+    read_lock(&d->v4v->lock);
+
+    for ( i =3D 0; i < V4V_HTABLE_SIZE; ++i )
+    {
+        struct hlist_node *node;
+        struct v4v_ring_info *ring_info;
+
+        hlist_for_each_entry(ring_info, node, &d->v4v->ring_hash[i], nod=
e)
+            dump_domain_ring(d, ring_info);
+    }
+
+    printk(KERN_ERR "  event channel: %d\n",  d->v4v->evtchn_port);
+    read_unlock(&d->v4v->lock);
+
+    printk(KERN_ERR "\n");
+    v4v_signal_domain(d);
+}
+
+static void
+dump_state(unsigned char key)
+{
+    struct domain *d;
+
+    printk(KERN_ERR "\n\nV4V:\n");
+    read_lock(&v4v_lock);
+
+    rcu_read_lock(&domlist_read_lock);
+
+    for_each_domain(d)
+        dump_domain(d);
+
+    rcu_read_unlock(&domlist_read_lock);
+
+    read_unlock(&v4v_lock);
+}
+
+struct keyhandler v4v_info_keyhandler =3D
+{
+    .diagnostic =3D 1,
+    .u.fn =3D dump_state,
+    .desc =3D "dump v4v states and interupt"
+};
+
+static int __init
+setup_dump_rings(void)
+{
+    register_keyhandler('4', &v4v_info_keyhandler);
+    return 0;
+}
+
+__initcall(setup_dump_rings);
+
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/public/v4v.h b/xen/include/public/v4v.h
new file mode 100644
index 0000000..3d55229
--- /dev/null
+++ b/xen/include/public/v4v.h
@@ -0,0 +1,308 @@
+/***********************************************************************=
*******
+ * V4V
+ *
+ * Version 2 of v2v (Virtual-to-Virtual)
+ *
+ * Copyright (c) 2010, Citrix Systems
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 =
 USA
+ */
+
+#ifndef __XEN_PUBLIC_V4V_H__
+#define __XEN_PUBLIC_V4V_H__
+
+#include "xen.h"
+#include "event_channel.h"
+
+/*
+ * Structure definitions
+ */
+
+#define V4V_RING_MAGIC          0xa822f72bb0b9d8ccUL
+#define V4V_RING_DATA_MAGIC	0x45fe852220b801d4UL
+
+#define V4V_MESSAGE_DGRAM       0x3c2c1db8
+#define V4V_MESSAGE_STREAM 	0x70f6a8e5
+
+#define V4V_DOMID_ANY           DOMID_INVALID
+#define V4V_PORT_ANY            0
+
+typedef uint64_t v4v_pfn_t;
+
+typedef struct v4v_iov
+{
+    uint64_t iov_base;
+    uint32_t iov_len;
+    uint32_t pad;
+} v4v_iov_t;
+
+typedef struct v4v_addr
+{
+    uint32_t port;
+    domid_t domain;
+    uint16_t pad;
+} v4v_addr_t;
+
+typedef struct v4v_ring_id
+{
+    v4v_addr_t addr;
+    domid_t partner;
+    uint16_t pad;
+} v4v_ring_id_t;
+
+typedef struct
+{
+    v4v_addr_t src;
+    v4v_addr_t dst;
+} v4v_send_addr_t;
+
+/*
+ * v4v_ring
+ * id: xen only looks at this during register/unregister
+ *     and will fill in id.addr.domain
+ * rx_ptr: rx pointer, modified by domain
+ * tx_ptr: tx pointer, modified by xen
+ *
+ */
+struct v4v_ring
+{
+    uint64_t magic;
+    v4v_ring_id_t id;
+    uint32_t len;
+    uint32_t rx_ptr;
+    uint32_t tx_ptr;
+    uint8_t reserved[32];
+#if defined(__STDC_VERSION__) && __STDC_VERSION__ >=3D 199901L
+    uint8_t ring[];
+#elif defined(__GNUC__)
+    uint8_t ring[0];
+#endif
+};
+typedef struct v4v_ring v4v_ring_t;
+
+#define V4V_RING_DATA_F_EMPTY       (1U << 0) /* Ring is empty */
+#define V4V_RING_DATA_F_EXISTS      (1U << 1) /* Ring exists */
+#define V4V_RING_DATA_F_PENDING     (1U << 2) /* Pending interrupt exist=
s - do not
+                                               * rely on this field - fo=
r
+                                               * profiling only */
+#define V4V_RING_DATA_F_SUFFICIENT  (1U << 3) /* Sufficient space to que=
ue
+                                               * space_required bytes ex=
ists */
+
+typedef struct v4v_ring_data_ent
+{
+    v4v_addr_t ring;
+    uint16_t flags;
+    uint32_t space_required;
+    uint32_t max_message_size;
+} v4v_ring_data_ent_t;
+
+typedef struct v4v_ring_data
+{
+    uint64_t magic;
+    uint32_t nent;
+    uint32_t pad;
+    uint64_t reserved[4];
+#if defined(__STDC_VERSION__) && __STDC_VERSION__ >=3D 199901L
+    v4v_ring_data_ent_t data[];
+#elif defined(__GNUC__)
+    v4v_ring_data_ent_t data[0];
+#endif
+} v4v_ring_data_t;
+
+struct v4v_info
+{
+    uint64_t ring_magic;
+    uint64_t data_magic;
+    evtchn_port_t evtchn;
+    uint32_t pad;
+};
+typedef struct v4v_info v4v_info_t;
+
+#define V4V_SHF_SYN		(1 << 0)
+#define V4V_SHF_ACK		(1 << 1)
+#define V4V_SHF_RST		(1 << 2)
+
+#define V4V_SHF_PING		(1 << 8)
+#define V4V_SHF_PONG		(1 << 9)
+
+struct v4v_stream_header
+{
+    uint32_t flags;
+    uint32_t conid;
+};
+
+struct v4v_ring_message_header
+{
+    uint32_t len;
+    uint32_t pad0;
+    v4v_addr_t source;
+    uint32_t message_type;
+#if defined(__STDC_VERSION__) && __STDC_VERSION__ >=3D 199901L
+    uint8_t data[];
+#elif defined(__GNUC__)
+    uint8_t data[0];
+#endif
+};
+
+typedef struct v4vtables_rule
+{
+    v4v_addr_t src;
+    v4v_addr_t dst;
+    uint32_t accept;
+    uint32_t pad;
+} v4vtables_rule_t;
+
+typedef struct v4vtables_list
+{
+    uint32_t start_rule;
+    uint32_t nb_rules;
+#if defined(__STDC_VERSION__) && __STDC_VERSION__ >=3D 199901L
+    struct v4vtables_rule rules[];
+#elif defined(__GNUC__)
+    struct v4vtables_rule rules[0];
+#endif
+} v4vtables_list_t;
+
+/*
+ * HYPERCALLS
+ */
+
+/*
+ * V4VOP_register_ring
+ *
+ * Registers a ring with Xen. If a ring with the same v4v_ring_id exists=
,
+ * the hypercall will return -EEXIST.
+ *
+ * do_v4v_op(V4VOP_register_ring,
+ *           XEN_GUEST_HANDLE(v4v_ring_t), XEN_GUEST_HANDLE(v4v_pfn_t),
+ *           npage, 0)
+ */
+#define V4VOP_register_ring 	1
+
+
+/*
+ * V4VOP_unregister_ring
+ *
+ * Unregister a ring.
+ *
+ * do_v4v_op(V4VOP_unregister_ring,
+ *           XEN_GUEST_HANDLE(v4v_ring_t),
+ *           NULL, 0, 0)
+ */
+#define V4VOP_unregister_ring 	2
+
+/*
+ * V4VOP_notify
+ *
+ * Asks xen for information about other rings in the system
+ *
+ * ent->ring is the v4v_addr_t of the ring you want information on
+ * the same matching rules are used as for V4VOP_send.
+ *
+ * ent->space_required  if this field is not null xen will check
+ * that there is space in the destination ring for this many bytes
+ * of payload. If there is it will set the V4V_RING_DATA_F_SUFFICIENT
+ * and CANCEL any pending interrupt for that ent->ring, if insufficient
+ * space is available it will schedule an interrupt and the flag will
+ * not be set.
+ *
+ * The flags are set by xen when notify replies
+ * V4V_RING_DATA_F_EMPTY	ring is empty
+ * V4V_RING_DATA_F_PENDING	interrupt is pending - don't rely on this
+ * V4V_RING_DATA_F_SUFFICIENT	sufficient space for space_required is the=
re
+ * V4V_RING_DATA_F_EXISTS	ring exists
+ *
+ * do_v4v_op(V4VOP_notify,
+ *           XEN_GUEST_HANDLE(v4v_ring_data_ent_t) ent,
+ *           NULL, 0, 0)
+ */
+#define V4VOP_notify 		4
+
+/*
+ * V4VOP_sendv
+ *
+ * Sends of list of buffer contained in iov.
+ *
+ * For each iov entry send iov_len bytes of iov_base to addr.dst, giving
+ * src as the source address (xen will ignore src->domain and put your
+ * domain in the actually message), xen first looks for a ring with id.a=
ddr=3D=3Ddst
+ * and id.partner=3D=3Dsending_domain if that fails it looks for id.addr=
=3D=3Ddst and
+ * id.partner=3D=3DDOMID_ANY.
+ * message_type is the 32 bit number used from the message
+ * most likely V4V_MESSAGE_DGRAM or V4V_MESSAGE_STREAM. If insufficient =
space exists
+ * it will return -EAGAIN and xen will twing the V4V_INTERRUPT when
+ * sufficient space becomes available
+ *
+ * do_v4v_op(V4VOP_sendv,
+ *           XEN_GUEST_HANDLE(v4v_send_addr_t) addr,
+ *           XEN_GUEST_HANDLE(v4v_iov_t) iov,
+ *           uint32_t niov,
+ *           uint32_t message_type)
+ */
+#define V4VOP_sendv		5
+
+/*
+ * V4VOP_tables_add
+ *
+ * Insert a filtering rules after a given position.
+ *
+ * do_v4v_op(V4VOP_tables_add,
+ *           XEN_GUEST_HANDLE(v4vtables_rule_t) rule,
+ *           NULL,
+ *           uint32_t position, 0)
+ */
+#define V4VOP_tables_add     6
+
+/*
+ * V4VOP_tables_del
+ *
+ * Delete a filtering rules at a position or the rule
+ * that matches "rule".
+ *
+ * do_v4v_op(V4VOP_tables_del,
+ *           XEN_GUEST_HANDLE(v4vtables_rule_t) rule,
+ *           NULL,
+ *           uint32_t position, 0)
+ */
+#define V4VOP_tables_del     7
+
+/*
+ * V4VOP_tables_list
+ *
+ * do_v4v_op(V4VOP_tables_list,
+ *           XEN_GUEST_HANDLE(v4vtpables_list_t) list,
+ *           NULL, 0, 0)
+ */
+#define V4VOP_tables_list    8
+
+/*
+ * V4VOP_info
+ *
+ * Returns v4v info for the current domain (domain that issued the hyper=
call).
+ *      - V4V magic number
+ *      - event channel port (for current domain)
+ *
+ * do_v4v_op(V4VOP_info,
+ *           XEN_GUEST_HANDLE(v4v_info_t) info,
+ *           NULL, 0, 0)
+ */
+#define V4VOP_info              9
+
+#endif /* __XEN_PUBLIC_V4V_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 268df3e..b3e6d40 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -100,7 +100,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
 #define __HYPERVISOR_domctl               36
 #define __HYPERVISOR_kexec_op             37
 #define __HYPERVISOR_tmem_op              38
-#define __HYPERVISOR_xc_reserved_op       39 /* reserved for XenClient *=
/
+#define __HYPERVISOR_v4v_op               39
=20
 /* Architecture-specific hypercall definitions. */
 #define __HYPERVISOR_arch_0               48
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 6c55039..2fd9313 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
=20
 #ifdef CONFIG_COMPAT
 #include 
@@ -363,6 +364,9 @@ struct domain
     nodemask_t node_affinity;
     unsigned int last_alloc_node;
     spinlock_t node_affinity_lock;
+
+    /* v4v */
+    struct v4v_domain *v4v;
 };
=20
 struct domain_setup_info
diff --git a/xen/include/xen/v4v.h b/xen/include/xen/v4v.h
new file mode 100644
index 0000000..d09e2cc
--- /dev/null
+++ b/xen/include/xen/v4v.h
@@ -0,0 +1,134 @@
+/***********************************************************************=
*******
+ * V4V
+ *
+ * Version 2 of v2v (Virtual-to-Virtual)
+ *
+ * Copyright (c) 2010, Citrix Systems
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 =
 USA
+ */
+
+#ifndef __V4V_PRIVATE_H__
+#define __V4V_PRIVATE_H__
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define V4V_HTABLE_SIZE 32
+
+/*
+ * Handlers
+ */
+
+DEFINE_XEN_GUEST_HANDLE (v4v_iov_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_addr_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_send_addr_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_ring_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_ent_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_info_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_pfn_t);
+
+DEFINE_XEN_GUEST_HANDLE (v4vtables_rule_t);
+DEFINE_XEN_GUEST_HANDLE (v4vtables_list_t);
+
+/*
+ * Helper functions
+ */
+
+static inline uint16_t
+v4v_hash_fn (v4v_ring_id_t *id)
+{
+    uint16_t ret;
+    ret =3D (uint16_t) (id->addr.port >> 16);
+    ret ^=3D (uint16_t) id->addr.port;
+    ret ^=3D id->addr.domain;
+    ret ^=3D id->partner;
+
+    ret &=3D (V4V_HTABLE_SIZE-1);
+
+    return ret;
+}
+
+struct v4v_pending_ent
+{
+    struct hlist_node node;
+    domid_t id;
+    uint32_t len;
+};
+
+
+struct v4v_ring_info
+{
+    /* next node in the hash, protected by L2  */
+    struct hlist_node node;
+    /* this ring's id, protected by L2 */
+    v4v_ring_id_t id;
+    /* L3 */
+    spinlock_t lock;
+    /* cached length of the ring (from ring->len), protected by L3 */
+    uint32_t len;
+    uint32_t npage;
+    /* cached tx pointer location, protected by L3 */
+    uint32_t tx_ptr;
+    /* guest ring, protected by L3 */
+    XEN_GUEST_HANDLE(v4v_ring_t) ring;
+    /* mapped ring pages protected by L3*/
+    uint8_t **mfn_mapping;
+    /* list of mfns of guest ring */
+    mfn_t *mfns;
+    /* list of struct v4v_pending_ent for this ring, L3 */
+    struct hlist_head pending;
+};
+
+/*
+ * The value of the v4v element in a struct domain is
+ * protected by the global lock L1
+ */
+struct v4v_domain
+{
+    /* L2 */
+    rwlock_t lock;
+    /* event channel */
+    evtchn_port_t evtchn_port;
+    /* protected by L2 */
+    struct hlist_head ring_hash[V4V_HTABLE_SIZE];
+};
+
+typedef struct v4vtables_rule_node
+{
+    struct list_head list;
+    v4vtables_rule_t rule;
+} v4vtables_rule_node_t;
+
+void v4v_destroy(struct domain *d);
+int v4v_init(struct domain *d);
+long do_v4v_op (int cmd,
+                XEN_GUEST_HANDLE (void) arg1,
+                XEN_GUEST_HANDLE (void) arg2,
+                uint32_t arg3,
+                uint32_t arg4);
+
+#endif /* __V4V_PRIVATE_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */

--------------true
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------true--


From xen-devel-bounces@lists.xen.org Thu Oct 25 11:49:23 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 11:49:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRLvv-0008UY-Tn; Thu, 25 Oct 2012 11:49:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRLvt-0008Th-T7
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 11:49:06 +0000
Received: from [85.158.139.211:59505] by server-12.bemta-5.messagelabs.com id
	A7/22-26919-13729805; Thu, 25 Oct 2012 11:49:05 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1351165743!23220136!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6244 invoked from network); 25 Oct 2012 11:49:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 11:49:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,646,1344211200"; d="scan'208";a="15386525"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 11:49:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 12:49:01 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53] helo=spongy)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TRLvp-0003zr-13;
	Thu, 25 Oct 2012 11:49:01 +0000
Received: by spongy (Postfix, from userid 2023)	id 1675734040D; Thu, 25 Oct
	2012 12:52:09 +0100 (BST)
From: Jean Guyader 
To: 
Date: Thu, 25 Oct 2012 12:52:06 +0100
Message-ID: <1351165926-23259-4-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1351165926-23259-1-git-send-email-jean.guyader@citrix.com>
References: <1351165926-23259-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: tim@xen.org, Jean Guyader , JBeulich@suse.com
Subject: [Xen-devel] [PATCH 3/3] xen: Add V4V implementation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: quoted-printable


Setup of v4v domains a domain gets created and cleanup
when a domain die. Wire up the v4v hypercall.

Include v4v internal and public headers.

Signed-off-by: Jean Guyader 
---
 xen/arch/x86/hvm/hvm.c             |    6 +-
 xen/arch/x86/x86_64/compat/entry.S |    2 +
 xen/arch/x86/x86_64/entry.S        |    2 +
 xen/common/Makefile                |    1 +
 xen/common/domain.c                |   13 +-
 xen/common/v4v.c                   | 1848 ++++++++++++++++++++++++++++++=
++++++
 xen/include/public/v4v.h           |  308 ++++++
 xen/include/public/xen.h           |    2 +-
 xen/include/xen/sched.h            |    4 +
 xen/include/xen/v4v.h              |  134 +++
 10 files changed, 2316 insertions(+), 4 deletions(-)
 create mode 100644 xen/common/v4v.c
 create mode 100644 xen/include/public/v4v.h
 create mode 100644 xen/include/xen/v4v.h


--------------true
Content-Type: text/x-patch; name="0003-xen-Add-V4V-implementation.patch"
Content-Disposition: attachment;
	filename="0003-xen-Add-V4V-implementation.patch"
Content-Transfer-Encoding: quoted-printable

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 34da2f5..e5237f9 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3242,7 +3242,8 @@ static hvm_hypercall_t *const hvm_hypercall64_table=
[NR_hypercalls] =3D {
     HYPERCALL(set_timer_op),
     HYPERCALL(hvm_op),
     HYPERCALL(sysctl),
-    HYPERCALL(tmem_op)
+    HYPERCALL(tmem_op),
+    HYPERCALL(v4v_op)
 };
=20
 #define COMPAT_CALL(x)                                        \
@@ -3259,7 +3260,8 @@ static hvm_hypercall_t *const hvm_hypercall32_table=
[NR_hypercalls] =3D {
     COMPAT_CALL(set_timer_op),
     HYPERCALL(hvm_op),
     HYPERCALL(sysctl),
-    HYPERCALL(tmem_op)
+    HYPERCALL(tmem_op),
+    HYPERCALL(v4v_op)
 };
=20
 int hvm_do_hypercall(struct cpu_user_regs *regs)
diff --git a/xen/arch/x86/x86_64/compat/entry.S b/xen/arch/x86/x86_64/com=
pat/entry.S
index e6b52f3..4902c4f 100644
--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -414,6 +414,7 @@ ENTRY(compat_hypercall_table)
         .quad do_domctl
         .quad compat_kexec_op
         .quad do_tmem_op
+        .quad do_v4v_op
         .rept __HYPERVISOR_arch_0-((.-compat_hypercall_table)/8)
         .quad compat_ni_hypercall
         .endr
@@ -462,6 +463,7 @@ ENTRY(compat_hypercall_args_table)
         .byte 1 /* do_domctl                */
         .byte 2 /* compat_kexec_op          */
         .byte 1 /* do_tmem_op               */
+        .byte 5 /* do_v4v_op		    */
         .rept __HYPERVISOR_arch_0-(.-compat_hypercall_args_table)
         .byte 0 /* compat_ni_hypercall      */
         .endr
diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S
index ffb9314..78006cf 100644
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -707,6 +707,7 @@ ENTRY(hypercall_table)
         .quad do_domctl
         .quad do_kexec_op
         .quad do_tmem_op
+        .quad do_v4v_op
         .rept __HYPERVISOR_arch_0-((.-hypercall_table)/8)
         .quad do_ni_hypercall
         .endr
@@ -755,6 +756,7 @@ ENTRY(hypercall_args_table)
         .byte 1 /* do_domctl            */
         .byte 2 /* do_kexec             */
         .byte 1 /* do_tmem_op           */
+        .byte 5 /* do_v4v_op		*/
         .rept __HYPERVISOR_arch_0-(.-hypercall_args_table)
         .byte 0 /* do_ni_hypercall      */
         .endr
diff --git a/xen/common/Makefile b/xen/common/Makefile
index c1c100f..ba63cec 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -45,6 +45,7 @@ obj-y +=3D tmem_xen.o
 obj-y +=3D radix-tree.o
 obj-y +=3D rbtree.o
 obj-y +=3D lzo.o
+obj-y +=3D v4v.o
=20
 obj-bin-$(CONFIG_X86) +=3D $(foreach n,decompress bunzip2 unxz unlzma un=
lzo,$(n).init.o)
=20
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 0e3e36a..60cd8e3 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -195,7 +195,8 @@ struct domain *domain_create(
 {
     struct domain *d, **pd;
     enum { INIT_xsm =3D 1u<<0, INIT_watchdog =3D 1u<<1, INIT_rangeset =3D=
 1u<<2,
-           INIT_evtchn =3D 1u<<3, INIT_gnttab =3D 1u<<4, INIT_arch =3D 1=
u<<5 };
+           INIT_evtchn =3D 1u<<3, INIT_gnttab =3D 1u<<4, INIT_arch =3D 1=
u<<5,
+           INIT_v4v =3D 1u<<6 };
     int err, init_status =3D 0;
     int poolid =3D CPUPOOLID_NONE;
=20
@@ -307,6 +308,13 @@ struct domain *domain_create(
         spin_unlock(&domlist_update_lock);
     }
=20
+    if ( !is_idle_domain(d) )
+    {
+        if ( v4v_init(d) !=3D 0 )
+            goto fail;
+        init_status |=3D INIT_v4v;
+    }
+
     return d;
=20
  fail:
@@ -315,6 +323,8 @@ struct domain *domain_create(
     xfree(d->mem_event);
     if ( init_status & INIT_arch )
         arch_domain_destroy(d);
+    if ( init_status & INIT_v4v )
+	v4v_destroy(d);
     if ( init_status & INIT_gnttab )
         grant_table_destroy(d);
     if ( init_status & INIT_evtchn )
@@ -489,6 +499,7 @@ int domain_kill(struct domain *d)
         domain_pause(d);
         d->is_dying =3D DOMDYING_dying;
         spin_barrier(&d->domain_lock);
+        v4v_destroy(d);
         evtchn_destroy(d);
         gnttab_release_mappings(d);
         tmem_destroy(d->tmem);
diff --git a/xen/common/v4v.c b/xen/common/v4v.c
new file mode 100644
index 0000000..b821950
--- /dev/null
+++ b/xen/common/v4v.c
@@ -0,0 +1,1848 @@
+/***********************************************************************=
*******
+ * V4V
+ *
+ * Version 2 of v2v (Virtual-to-Virtual)
+ *
+ * Copyright (c) 2010, Citrix Systems
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 =
 USA
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#ifdef V4V_DEBUG
+#define v4v_dprintk(format, args...)            \
+    do {                                        \
+        printk("%s:%d " format,                 \
+               __FILE__, __LINE__, ## args );   \
+    } while ( 1 =3D=3D 0 )
+#else
+#define v4v_dprintk(format, ... ) (void)0
+#endif
+
+/*
+ * Messages on the ring are padded to 128 bits
+ * Len here refers to the exact length of the data not including the
+ * 128 bit header. The message uses
+ * ((len +0xf) & ~0xf) + sizeof(v4v_ring_message_header) bytes
+ */
+#define V4V_ROUNDUP(a) (((a) +0xf ) & ~0xf)
+
+DEFINE_XEN_GUEST_HANDLE(uint8_t);
+static struct v4v_ring_info *v4v_ring_find_info(struct domain *d,
+                                                v4v_ring_id_t *id);
+
+static struct v4v_ring_info *v4v_ring_find_info_by_addr(struct domain *d=
,
+                                                        struct v4v_addr =
*a,
+                                                        domid_t p);
+
+typedef struct internal_v4v_iov
+{
+    XEN_GUEST_HANDLE(v4v_iov_t) guest_iov;
+    v4v_iov_t                   *xen_iov;
+} internal_v4v_iov_t;
+
+struct list_head v4vtables_rules =3D LIST_HEAD_INIT(v4vtables_rules);
+
+/*
+ * locks
+ */
+
+/*
+ * locking is organized as follows:
+ *
+ * the global lock v4v_lock: L1 protects the v4v elements
+ * of all struct domain *d in the system, it does not
+ * protect any of the elements of d->v4v, just their
+ * addresses. By extension since the destruction of
+ * a domain with a non-NULL d->v4v will need to free
+ * the d->v4v pointer, holding this lock gauruntees
+ * that no domains pointers in which v4v is interested
+ * become invalid whilst this lock is held.
+ */
+
+static DEFINE_RWLOCK(v4v_lock); /* L1 */
+
+/*
+ * the lock d->v4v->lock: L2:  Read on protects the hash table and
+ * the elements in the hash_table d->v4v->ring_hash, and
+ * the node and id fields in struct v4v_ring_info in the
+ * hash table. Write on L2 protects all of the elements of
+ * struct v4v_ring_info. To take L2 you must already have R(L1)
+ * W(L1) implies W(L2) and L3
+ *
+ * the lock v4v_ring_info *ringinfo; ringinfo->lock: L3:
+ * protects len,tx_ptr the guest ring, the
+ * guest ring_data and the pending list. To take L3 you must
+ * already have R(L2). W(L2) implies L3
+ */
+
+/*
+ * lock to protect the filtering rules list: v4vtable_rules
+ *
+ * The write lock is held for viptables_del and viptables_add
+ * The read lock is held for viptable_list
+ */
+static DEFINE_RWLOCK(v4vtables_rules_lock);
+
+
+/*
+ * Debugs
+ */
+
+#ifdef V4V_DEBUG
+static void __attribute__((unused))
+v4v_hexdump(void *_p, int len)
+{
+    uint8_t *buf =3D (uint8_t *)_p;
+    int i, j;
+
+    for ( i =3D 0; i < len; i +=3D 16 )
+    {
+        printk(KERN_ERR "%p:", &buf[i]);
+        for ( j =3D 0; j < 16; ++j )
+        {
+            int k =3D i + j;
+            if ( k < len )
+                printk(" %02x", buf[k]);
+            else
+                printk("   ");
+        }
+        printk(" ");
+
+        for ( j =3D 0; j < 16; ++j )
+        {
+            int k =3D i + j;
+            if ( k < len )
+                printk("%c", ((buf[k] > 32) && (buf[k] < 127)) ? buf[k] =
: '.');
+            else
+                printk(" ");
+        }
+        printk("\n");
+    }
+}
+#endif
+
+
+/*
+ * Event channel
+ */
+
+static void
+v4v_signal_domain(struct domain *d)
+{
+    v4v_dprintk("send guest VIRQ_V4V domid:%d\n", d->domain_id);
+
+    evtchn_send(d, d->v4v->evtchn_port);
+}
+
+static void
+v4v_signal_domid(domid_t id)
+{
+    struct domain *d =3D get_domain_by_id(id);
+    if ( !d )
+        return;
+    v4v_signal_domain(d);
+    put_domain(d);
+}
+
+
+/*
+ * ring buffer
+ */
+
+static void
+v4v_ring_unmap(struct v4v_ring_info *ring_info)
+{
+    int i;
+
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    for ( i =3D 0; i < ring_info->npage; ++i )
+    {
+        if ( !ring_info->mfn_mapping[i] )
+            continue;
+        v4v_dprintk("unmapping page %p from %p\n",
+                    (void*)mfn_x(ring_info->mfns[i]),
+                    ring_info->mfn_mapping[i]);
+
+        unmap_domain_page(ring_info->mfn_mapping[i]);
+        ring_info->mfn_mapping[i] =3D NULL;
+    }
+}
+
+static uint8_t *
+v4v_ring_map_page(struct v4v_ring_info *ring_info, int i)
+{
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    if ( i >=3D ring_info->npage )
+        return NULL;
+    if ( ring_info->mfn_mapping[i] )
+        return ring_info->mfn_mapping[i];
+    ring_info->mfn_mapping[i] =3D map_domain_page(mfn_x(ring_info->mfns[=
i]));
+
+    v4v_dprintk("mapping page %p to %p\n",
+                (void *)mfn_x(ring_info->mfns[i]),
+                ring_info->mfn_mapping[i]);
+    return ring_info->mfn_mapping[i];
+}
+
+static int
+v4v_memcpy_from_guest_ring(void *_dst, struct v4v_ring_info *ring_info,
+                           uint32_t offset, uint32_t len)
+{
+    int page =3D offset >> PAGE_SHIFT;
+    uint8_t *src;
+    uint8_t *dst =3D _dst;
+
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    offset &=3D PAGE_SIZE - 1;
+
+    while ( (offset + len) > PAGE_SIZE )
+    {
+        src =3D v4v_ring_map_page(ring_info, page);
+
+        if ( !src )
+            return -EFAULT;
+
+        v4v_dprintk("memcpy(%p,%p+%d,%d)\n",
+                    dst, src, offset,
+                    (int)(PAGE_SIZE - offset));
+        memcpy(dst, src + offset, PAGE_SIZE - offset);
+
+        page++;
+        len -=3D PAGE_SIZE - offset;
+        dst +=3D PAGE_SIZE - offset;
+        offset =3D 0;
+    }
+
+    src =3D v4v_ring_map_page(ring_info, page);
+    if ( !src )
+        return -EFAULT;
+
+    v4v_dprintk("memcpy(%p,%p+%d,%d)\n", dst, src, offset, len);
+    memcpy(dst, src + offset, len);
+
+    return 0;
+}
+
+static int
+v4v_update_tx_ptr(struct v4v_ring_info *ring_info, uint32_t tx_ptr)
+{
+    uint8_t *dst =3D v4v_ring_map_page(ring_info, 0);
+    uint32_t *p =3D (uint32_t *)(dst + offsetof(v4v_ring_t, tx_ptr));
+
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    if ( !dst )
+        return -EFAULT;
+    write_atomic(p, tx_ptr);
+    mb();
+    return 0;
+}
+
+static int
+v4v_copy_from_guest_maybe(void *dst, void *src,
+                          XEN_GUEST_HANDLE(uint8_t) src_hnd,
+                          uint32_t len)
+{
+    int rc =3D 0;
+
+    if ( src )
+        memcpy(dst, src, len);
+    else
+        rc =3D __copy_from_guest(dst, src_hnd, len);
+    return rc;
+}
+
+static int
+v4v_memcpy_to_guest_ring(struct v4v_ring_info *ring_info,
+                         uint32_t offset,
+                         void *src,
+                         XEN_GUEST_HANDLE(uint8_t) src_hnd,
+                         uint32_t len)
+{
+    int page =3D offset >> PAGE_SHIFT;
+    uint8_t *dst;
+
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    offset &=3D PAGE_SIZE - 1;
+
+    while ( (offset + len) > PAGE_SIZE )
+    {
+        dst =3D v4v_ring_map_page(ring_info, page);
+        if ( !dst )
+            return -EFAULT;
+
+        if ( v4v_copy_from_guest_maybe(dst + offset, src, src_hnd,
+                                       PAGE_SIZE - offset) )
+            return -EFAULT;
+
+        page++;
+        len -=3D PAGE_SIZE - offset;
+        if ( src )
+            src +=3D (PAGE_SIZE - offset);
+        else
+            guest_handle_add_offset(src_hnd, PAGE_SIZE - offset);
+        offset =3D 0;
+    }
+
+    dst =3D v4v_ring_map_page(ring_info, page);
+    if ( !dst )
+        return -EFAULT;
+
+    if ( v4v_copy_from_guest_maybe(dst + offset, src, src_hnd, len) )
+        return -EFAULT;
+
+    return 0;
+}
+
+static int
+v4v_ringbuf_get_rx_ptr(struct domain *d, struct v4v_ring_info *ring_info=
,
+                        uint32_t * rx_ptr)
+{
+    v4v_ring_t *ringp;
+
+    if ( ring_info->npage =3D=3D 0 )
+        return -1;
+
+    ringp =3D map_domain_page(mfn_x(ring_info->mfns[0]));
+
+    v4v_dprintk("v4v_ringbuf_payload_space: mapped %p to %p\n",
+                (void *)mfn_x(ring_info->mfns[0]), ringp);
+    if ( !ringp )
+        return -1;
+
+    write_atomic(rx_ptr, ringp->rx_ptr);
+    mb();
+
+    unmap_domain_page(mfn_x(ring_info->mfns[0]));
+    return 0;
+}
+
+uint32_t
+v4v_ringbuf_payload_space(struct domain * d, struct v4v_ring_info * ring=
_info)
+{
+    v4v_ring_t ring;
+    int32_t ret;
+
+    ring.tx_ptr =3D ring_info->tx_ptr;
+    ring.len =3D ring_info->len;
+
+    if ( v4v_ringbuf_get_rx_ptr(d, ring_info, &ring.rx_ptr) )
+        return 0;
+
+    v4v_dprintk("v4v_ringbuf_payload_space:tx_ptr=3D%d rx_ptr=3D%d\n",
+                (int)ring.tx_ptr, (int)ring.rx_ptr);
+    if ( ring.rx_ptr =3D=3D ring.tx_ptr )
+        return ring.len - sizeof (struct v4v_ring_message_header);
+
+    ret =3D ring.rx_ptr - ring.tx_ptr;
+    if ( ret < 0 )
+        ret +=3D ring.len;
+
+    ret -=3D sizeof (struct v4v_ring_message_header);
+    ret -=3D V4V_ROUNDUP(1);
+
+    return (ret < 0) ? 0 : ret;
+}
+
+static long
+v4v_iov_count(XEN_GUEST_HANDLE(v4v_iov_t) iovs, int niov)
+{
+    v4v_iov_t iov;
+    size_t ret =3D 0;
+
+    while ( niov-- )
+    {
+        if ( copy_from_guest(&iov, iovs, 1) )
+            return -EFAULT;
+
+        ret +=3D iov.iov_len;
+
+        /* message bigger than 2G can't be sent */
+        if (ret > 2L * 1024 * 1024 * 1024)
+            return -EMSGSIZE;
+
+        guest_handle_add_offset(iovs, 1);
+    }
+
+    return ret;
+}
+
+static long
+v4v_ringbuf_insertv(struct domain *d,
+                    struct v4v_ring_info *ring_info,
+                    v4v_ring_id_t *src_id, uint32_t proto,
+                    XEN_GUEST_HANDLE(v4v_iov_t) iovs, uint32_t niov,
+                    size_t len)
+{
+    v4v_ring_t ring;
+    struct v4v_ring_message_header mh =3D { 0 };
+    int32_t sp;
+    long happy_ret;
+    int32_t ret =3D 0;
+    XEN_GUEST_HANDLE(uint8_t) empty_hnd =3D { 0 };
+
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    happy_ret =3D len;
+
+    if ( (V4V_ROUNDUP(len) + sizeof (struct v4v_ring_message_header) ) >=
=3D
+            ring_info->len)
+        return -EMSGSIZE;
+
+    do
+    {
+        if ( (ret =3D v4v_memcpy_from_guest_ring(&ring, ring_info, 0,
+                                               sizeof (ring))) )
+            break;
+
+        ring.tx_ptr =3D ring_info->tx_ptr;
+        ring.len =3D ring_info->len;
+
+        v4v_dprintk("ring.tx_ptr=3D%d ring.rx_ptr=3D%d ring.len=3D%d rin=
g_info->tx_ptr=3D%d\n",
+                    ring.tx_ptr, ring.rx_ptr, ring.len, ring_info->tx_pt=
r);
+
+        if ( ring.rx_ptr =3D=3D ring.tx_ptr )
+            sp =3D ring_info->len;
+        else
+        {
+            sp =3D ring.rx_ptr - ring.tx_ptr;
+            if ( sp < 0 )
+                sp +=3D ring.len;
+        }
+
+        if ( (V4V_ROUNDUP(len) + sizeof (struct v4v_ring_message_header)=
) >=3D sp )
+        {
+            v4v_dprintk("EAGAIN\n");
+            ret =3D -EAGAIN;
+            break;
+        }
+
+        mh.len =3D len + sizeof (struct v4v_ring_message_header);
+        mh.source =3D src_id->addr;
+        mh.message_type =3D proto;
+
+        if ( (ret =3D v4v_memcpy_to_guest_ring(ring_info,
+                                             ring.tx_ptr + sizeof (v4v_r=
ing_t),
+                                             &mh, empty_hnd,
+                                             sizeof (mh))) )
+            break;
+
+        ring.tx_ptr +=3D sizeof (mh);
+        if ( ring.tx_ptr =3D=3D ring_info->len )
+            ring.tx_ptr =3D 0;
+
+        while ( niov-- )
+        {
+            XEN_GUEST_HANDLE(uint8_t) buf_hnd;
+            v4v_iov_t iov;
+
+            if ( copy_from_guest(&iov, iovs, 1) )
+            {
+                ret =3D -EFAULT;
+                break;
+            }
+
+            buf_hnd.p =3D (uint8_t *)iov.iov_base; //FIXME
+            len =3D iov.iov_len;
+
+            if ( unlikely(!guest_handle_okay(buf_hnd, len)) )
+            {
+                ret =3D -EFAULT;
+                break;
+            }
+
+            sp =3D ring.len - ring.tx_ptr;
+
+            if ( len > sp )
+            {
+                ret =3D v4v_memcpy_to_guest_ring(ring_info,
+                        ring.tx_ptr + sizeof (v4v_ring_t),
+                        NULL, buf_hnd, sp);
+                if ( ret )
+                    break;
+
+                ring.tx_ptr =3D 0;
+                len -=3D sp;
+                guest_handle_add_offset(buf_hnd, sp);
+            }
+
+            ret =3D v4v_memcpy_to_guest_ring(ring_info,
+                    ring.tx_ptr + sizeof (v4v_ring_t),
+                    NULL, buf_hnd, len);
+            if ( ret )
+                break;
+
+            ring.tx_ptr +=3D len;
+
+            if ( ring.tx_ptr =3D=3D ring_info->len )
+                ring.tx_ptr =3D 0;
+
+            guest_handle_add_offset(iovs, 1);
+        }
+        if ( ret )
+            break;
+
+        ring.tx_ptr =3D V4V_ROUNDUP(ring.tx_ptr);
+
+        if ( ring.tx_ptr >=3D ring_info->len )
+            ring.tx_ptr -=3D ring_info->len;
+
+        mb();
+        ring_info->tx_ptr =3D ring.tx_ptr;
+        if ( (ret =3D v4v_update_tx_ptr(ring_info, ring.tx_ptr)) )
+            break;
+    }
+    while ( 0 );
+
+    v4v_ring_unmap(ring_info);
+
+    return ret ? ret : happy_ret;
+}
+
+
+
+/* pending */
+static void
+v4v_pending_remove_ent(struct v4v_pending_ent *ent)
+{
+    hlist_del(&ent->node);
+    xfree(ent);
+}
+
+static void
+v4v_pending_remove_all(struct v4v_ring_info *info)
+{
+    struct hlist_node *node, *next;
+    struct v4v_pending_ent *pending_ent;
+
+    ASSERT(spin_is_locked(&info->lock));
+    hlist_for_each_entry_safe(pending_ent, node, next, &info->pending,
+            node) v4v_pending_remove_ent(pending_ent);
+}
+
+static void
+v4v_pending_notify(struct domain *caller_d, struct hlist_head *to_notify=
)
+{
+    struct hlist_node *node, *next;
+    struct v4v_pending_ent *pending_ent;
+
+    ASSERT(rw_is_locked(&v4v_lock));
+
+    hlist_for_each_entry_safe(pending_ent, node, next, to_notify, node)
+    {
+        hlist_del(&pending_ent->node);
+        v4v_signal_domid(pending_ent->id);
+        xfree(pending_ent);
+    }
+
+}
+
+static void
+v4v_pending_find(struct domain *d, struct v4v_ring_info *ring_info,
+                 uint32_t payload_space, struct hlist_head *to_notify)
+{
+    struct hlist_node *node, *next;
+    struct v4v_pending_ent *ent;
+
+    ASSERT(rw_is_locked(&d->v4v->lock));
+
+    spin_lock(&ring_info->lock);
+    hlist_for_each_entry_safe(ent, node, next, &ring_info->pending, node=
)
+    {
+        if ( payload_space >=3D ent->len )
+        {
+            hlist_del(&ent->node);
+            hlist_add_head(&ent->node, to_notify);
+        }
+    }
+    spin_unlock(&ring_info->lock);
+}
+
+/*caller must have L3 */
+static int
+v4v_pending_queue(struct v4v_ring_info *ring_info, domid_t src_id, int l=
en)
+{
+    struct v4v_pending_ent *ent =3D xmalloc(struct v4v_pending_ent);
+
+    if ( !ent )
+    {
+        v4v_dprintk("ENOMEM\n");
+        return -ENOMEM;
+    }
+
+    ent->len =3D len;
+    ent->id =3D src_id;
+
+    hlist_add_head(&ent->node, &ring_info->pending);
+
+    return 0;
+}
+
+/* L3 */
+static int
+v4v_pending_requeue(struct v4v_ring_info *ring_info, domid_t src_id, int=
 len)
+{
+    struct hlist_node *node;
+    struct v4v_pending_ent *ent;
+
+    hlist_for_each_entry(ent, node, &ring_info->pending, node)
+    {
+        if ( ent->id =3D=3D src_id )
+        {
+            if ( ent->len < len )
+                ent->len =3D len;
+            return 0;
+        }
+    }
+
+    return v4v_pending_queue(ring_info, src_id, len);
+}
+
+
+/* L3 */
+static void
+v4v_pending_cancel(struct v4v_ring_info *ring_info, domid_t src_id)
+{
+    struct hlist_node *node, *next;
+    struct v4v_pending_ent *ent;
+
+    hlist_for_each_entry_safe(ent, node, next, &ring_info->pending, node=
)
+    {
+        if ( ent->id =3D=3D src_id)
+        {
+            hlist_del(&ent->node);
+            xfree(ent);
+        }
+    }
+}
+
+/*
+ * ring data
+ */
+
+/*Caller should hold R(L1)*/
+static int
+v4v_fill_ring_data(struct domain *src_d,
+                   XEN_GUEST_HANDLE(v4v_ring_data_ent_t) data_ent_hnd)
+{
+    v4v_ring_data_ent_t ent;
+    struct domain *dst_d;
+    struct v4v_ring_info *ring_info;
+
+    if ( copy_from_guest(&ent, data_ent_hnd, 1) )
+    {
+        v4v_dprintk("EFAULT\n");
+        return -EFAULT;
+    }
+
+    v4v_dprintk("v4v_fill_ring_data: ent.ring.domain=3D%d,ent.ring.port=3D=
%u\n",
+                (int)ent.ring.domain, (int)ent.ring.port);
+
+    ent.flags =3D 0;
+
+    dst_d =3D get_domain_by_id(ent.ring.domain);
+
+    if ( dst_d && dst_d->v4v )
+    {
+        read_lock(&dst_d->v4v->lock);
+        ring_info =3D v4v_ring_find_info_by_addr(dst_d, &ent.ring,
+                                               src_d->domain_id);
+
+        if ( ring_info )
+        {
+            uint32_t space_avail;
+
+            ent.flags |=3D V4V_RING_DATA_F_EXISTS;
+            ent.max_message_size =3D
+                ring_info->len - sizeof (struct v4v_ring_message_header)=
 -
+                V4V_ROUNDUP(1);
+            spin_lock(&ring_info->lock);
+
+            space_avail =3D v4v_ringbuf_payload_space(dst_d, ring_info);
+
+            if ( space_avail >=3D ent.space_required )
+            {
+                v4v_pending_cancel(ring_info, src_d->domain_id);
+                ent.flags |=3D V4V_RING_DATA_F_SUFFICIENT;
+            }
+            else
+            {
+                v4v_pending_requeue(ring_info, src_d->domain_id,
+                        ent.space_required);
+                ent.flags |=3D V4V_RING_DATA_F_PENDING;
+            }
+
+            spin_unlock(&ring_info->lock);
+
+            if ( space_avail =3D=3D ent.max_message_size )
+                ent.flags |=3D V4V_RING_DATA_F_EMPTY;
+
+        }
+        read_unlock(&dst_d->v4v->lock);
+    }
+
+    if ( dst_d )
+        put_domain(dst_d);
+
+    if ( copy_field_to_guest(data_ent_hnd, &ent, flags) )
+    {
+        v4v_dprintk("EFAULT\n");
+        return -EFAULT;
+    }
+    return 0;
+}
+
+/*Called should hold no more than R(L1) */
+static int
+v4v_fill_ring_datas(struct domain *d, int nent,
+                     XEN_GUEST_HANDLE(v4v_ring_data_ent_t) data_ent_hnd)
+{
+    int ret =3D 0;
+
+    read_lock(&v4v_lock);
+    while ( !ret && nent-- )
+    {
+        ret =3D v4v_fill_ring_data(d, data_ent_hnd);
+        guest_handle_add_offset(data_ent_hnd, 1);
+    }
+    read_unlock(&v4v_lock);
+    return ret;
+}
+
+/*
+ * ring
+ */
+static int
+v4v_find_ring_mfns(struct domain *d, struct v4v_ring_info *ring_info,
+                   uint32_t npage, XEN_GUEST_HANDLE(v4v_pfn_t) pfn_hnd)
+{
+    int i,j;
+    mfn_t *mfns;
+    uint8_t **mfn_mapping;
+    unsigned long mfn;
+    struct page_info *page;
+    int ret =3D 0;
+
+    if ( (npage << PAGE_SHIFT) < ring_info->len )
+    {
+        v4v_dprintk("EINVAL\n");
+        return -EINVAL;
+    }
+
+    mfns =3D xmalloc_array(mfn_t, npage);
+    if ( !mfns )
+    {
+        v4v_dprintk("ENOMEM\n");
+        return -ENOMEM;
+    }
+
+    mfn_mapping =3D xmalloc_array(uint8_t *, npage);
+    if ( !mfn_mapping )
+    {
+        xfree(mfns);
+        return -ENOMEM;
+    }
+
+    for ( i =3D 0; i < npage; ++i )
+    {
+        unsigned long pfn;
+        p2m_type_t p2mt;
+
+        if ( copy_from_guest_offset(&pfn, pfn_hnd, i, 1) )
+        {
+            ret =3D -EFAULT;
+            v4v_dprintk("EFAULT\n");
+            break;
+        }
+
+        mfn =3D mfn_x(get_gfn(d, pfn, &p2mt));
+        if ( !mfn_valid(mfn) )
+        {
+            printk(KERN_ERR "v4v domain %d passed invalid mfn %"PRI_mfn"=
 ring %p seq %d\n",
+                    d->domain_id, mfn, ring_info, i);
+            ret =3D -EINVAL;
+            break;
+        }
+        page =3D mfn_to_page(mfn);
+        if ( !get_page_and_type(page, d, PGT_writable_page) )
+        {
+            printk(KERN_ERR "v4v domain %d passed wrong type mfn %"PRI_m=
fn" ring %p seq %d\n",
+                    d->domain_id, mfn, ring_info, i);
+            ret =3D -EINVAL;
+            break;
+        }
+        mfns[i] =3D _mfn(mfn);
+        v4v_dprintk("v4v_find_ring_mfns: %d: %lx -> %lx\n",
+                    i, (unsigned long)pfn, (unsigned long)mfn_x(mfns[i])=
);
+        mfn_mapping[i] =3D NULL;
+        put_gfn(d, pfn);
+    }
+
+    if ( !ret )
+    {
+        ring_info->npage =3D npage;
+        ring_info->mfns =3D mfns;
+        ring_info->mfn_mapping =3D mfn_mapping;
+    }
+    else
+    {
+        j =3D i;
+        for ( i =3D 0; i < j; ++i )
+            if ( mfn_x(mfns[i]) !=3D 0 )
+                put_page_and_type(mfn_to_page(mfn_x(mfns[i])));
+        xfree(mfn_mapping);
+        xfree(mfns);
+    }
+    return ret;
+}
+
+
+static struct v4v_ring_info *
+v4v_ring_find_info(struct domain *d, v4v_ring_id_t *id)
+{
+    uint16_t hash;
+    struct hlist_node *node;
+    struct v4v_ring_info *ring_info;
+
+    ASSERT(rw_is_locked(&d->v4v->lock));
+
+    hash =3D v4v_hash_fn(id);
+
+    v4v_dprintk("ring_find_info: d->v4v=3D%p, d->v4v->ring_hash[%d]=3D%p=
 id=3D%p\n",
+                d->v4v, (int)hash, d->v4v->ring_hash[hash].first, id);
+    v4v_dprintk("ring_find_info: id.addr.port=3D%d id.addr.domain=3D%d i=
d.addr.partner=3D%d\n",
+                id->addr.port, id->addr.domain, id->partner);
+
+    hlist_for_each_entry(ring_info, node, &d->v4v->ring_hash[hash], node=
)
+    {
+        v4v_ring_id_t *cmpid =3D &ring_info->id;
+
+        if ( cmpid->addr.port =3D=3D id->addr.port &&
+             cmpid->addr.domain =3D=3D id->addr.domain &&
+             cmpid->partner =3D=3D id->partner)
+        {
+            v4v_dprintk("ring_find_info: ring_info=3D%p\n", ring_info);
+            return ring_info;
+        }
+    }
+    v4v_dprintk("ring_find_info: no ring_info found\n");
+    return NULL;
+}
+
+static struct v4v_ring_info *
+v4v_ring_find_info_by_addr(struct domain *d, struct v4v_addr *a, domid_t=
 p)
+{
+    v4v_ring_id_t id;
+    struct v4v_ring_info *ret;
+
+    ASSERT(rw_is_locked(&d->v4v->lock));
+
+    if ( !a )
+        return NULL;
+
+    id.addr.port =3D a->port;
+    id.addr.domain =3D d->domain_id;
+    id.partner =3D p;
+
+    ret =3D v4v_ring_find_info(d, &id);
+    if ( ret )
+        return ret;
+
+    id.partner =3D V4V_DOMID_ANY;
+
+    return v4v_ring_find_info(d, &id);
+}
+
+static void v4v_ring_remove_mfns(struct domain *d, struct v4v_ring_info =
*ring_info)
+{
+    int i;
+
+    ASSERT(rw_is_write_locked(&d->v4v->lock));
+
+    if ( ring_info->mfns )
+    {
+        for ( i =3D 0; i < ring_info->npage; ++i )
+            if ( mfn_x(ring_info->mfns[i]) !=3D 0 )
+                put_page_and_type(mfn_to_page(mfn_x(ring_info->mfns[i]))=
);
+        xfree(ring_info->mfns);
+    }
+    if ( ring_info->mfn_mapping )
+        xfree(ring_info->mfn_mapping);
+    ring_info->mfns =3D NULL;
+
+}
+
+static void
+v4v_ring_remove_info(struct domain *d, struct v4v_ring_info *ring_info)
+{
+    ASSERT(rw_is_write_locked(&d->v4v->lock));
+
+    spin_lock(&ring_info->lock);
+
+    v4v_pending_remove_all(ring_info);
+    hlist_del(&ring_info->node);
+    v4v_ring_remove_mfns(d, ring_info);
+
+    spin_unlock(&ring_info->lock);
+
+    xfree(ring_info);
+}
+
+/* Call from guest to unpublish a ring */
+static long
+v4v_ring_remove(struct domain *d, XEN_GUEST_HANDLE(v4v_ring_t) ring_hnd)
+{
+    struct v4v_ring ring;
+    struct v4v_ring_info *ring_info;
+    int ret =3D 0;
+
+    read_lock(&v4v_lock);
+
+    do
+    {
+        if ( !d->v4v )
+        {
+            v4v_dprintk("EINVAL\n");
+            ret =3D -EINVAL;
+            break;
+        }
+
+        if ( copy_from_guest(&ring, ring_hnd, 1) )
+        {
+            v4v_dprintk("EFAULT\n");
+            ret =3D -EFAULT;
+            break;
+        }
+
+        if ( ring.magic !=3D V4V_RING_MAGIC )
+        {
+            v4v_dprintk("ring.magic(%"PRIx64") !=3D V4V_RING_MAGIC(%"PRI=
x64"), EINVAL\n",
+                    ring.magic, V4V_RING_MAGIC);
+            ret =3D -EINVAL;
+            break;
+        }
+
+        ring.id.addr.domain =3D d->domain_id;
+
+        write_lock(&d->v4v->lock);
+        ring_info =3D v4v_ring_find_info(d, &ring.id);
+
+        if ( ring_info )
+            v4v_ring_remove_info(d, ring_info);
+
+        write_unlock(&d->v4v->lock);
+
+        if ( !ring_info )
+        {
+            v4v_dprintk("ENOENT\n");
+            ret =3D -ENOENT;
+            break;
+        }
+
+    }
+    while ( 0 );
+
+    read_unlock(&v4v_lock);
+    return ret;
+}
+
+/* call from guest to publish a ring */
+static long
+v4v_ring_add(struct domain *d, XEN_GUEST_HANDLE(v4v_ring_t) ring_hnd,
+             uint32_t npage, XEN_GUEST_HANDLE(v4v_pfn_t) pfn_hnd)
+{
+    struct v4v_ring ring;
+    struct v4v_ring_info *ring_info;
+    int need_to_insert =3D 0;
+    int ret =3D 0;
+
+    if ( (long)ring_hnd.p & (PAGE_SIZE - 1) )
+    {
+        v4v_dprintk("EINVAL\n");
+        return -EINVAL;
+    }
+
+    read_lock(&v4v_lock);
+    do
+    {
+        if ( !d->v4v )
+        {
+            v4v_dprintk(" !d->v4v, EINVAL\n");
+            ret =3D -EINVAL;
+            break;
+        }
+
+        if ( copy_from_guest(&ring, ring_hnd, 1) )
+        {
+            v4v_dprintk(" copy_from_guest failed, EFAULT\n");
+            ret =3D -EFAULT;
+            break;
+        }
+
+        if ( ring.magic !=3D V4V_RING_MAGIC )
+        {
+            v4v_dprintk("ring.magic(%lx) !=3D V4V_RING_MAGIC(%lx), EINVA=
L\n",
+                        ring.magic, V4V_RING_MAGIC);
+            ret =3D -EINVAL;
+            break;
+        }
+
+        if ( (ring.len <
+                    (sizeof (struct v4v_ring_message_header) + V4V_ROUND=
UP(1) +
+                     V4V_ROUNDUP(1))) || (V4V_ROUNDUP(ring.len) !=3D rin=
g.len) )
+        {
+            v4v_dprintk("EINVAL\n");
+            ret =3D -EINVAL;
+            break;
+        }
+
+        ring.id.addr.domain =3D d->domain_id;
+        if ( copy_field_to_guest(ring_hnd, &ring, id) )
+        {
+            v4v_dprintk("EFAULT\n");
+            ret =3D -EFAULT;
+            break;
+        }
+
+        /*
+         * no need for a lock yet, because only we know about this
+         * set the tx pointer if it looks bogus (we don't reset it
+         * because this might be a re-register after S4)
+         */
+        if ( (ring.tx_ptr >=3D ring.len)
+                || (V4V_ROUNDUP(ring.tx_ptr) !=3D ring.tx_ptr) )
+        {
+            ring.tx_ptr =3D ring.rx_ptr;
+        }
+        copy_field_to_guest(ring_hnd, &ring, tx_ptr);
+
+        read_lock(&d->v4v->lock);
+        ring_info =3D v4v_ring_find_info(d, &ring.id);
+
+        if ( !ring_info )
+        {
+            read_unlock(&d->v4v->lock);
+            ring_info =3D xmalloc(struct v4v_ring_info);
+            if ( !ring_info )
+            {
+                v4v_dprintk("ENOMEM\n");
+                ret =3D -ENOMEM;
+                break;
+            }
+            need_to_insert++;
+            spin_lock_init(&ring_info->lock);
+            INIT_HLIST_HEAD(&ring_info->pending);
+            ring_info->mfns =3D NULL;
+
+        }
+        else
+        {
+            /*
+             * Ring info already existed.
+             */
+            printk(KERN_INFO "v4v: dom%d ring already registered\n",
+                    current->domain->domain_id);
+            ret =3D -EEXIST;
+            break;
+        }
+
+        spin_lock(&ring_info->lock);
+        ring_info->id =3D ring.id;
+        ring_info->len =3D ring.len;
+        ring_info->tx_ptr =3D ring.tx_ptr;
+        ring_info->ring =3D ring_hnd;
+        if ( ring_info->mfns )
+            xfree(ring_info->mfns);
+        ret =3D v4v_find_ring_mfns(d, ring_info, npage, pfn_hnd);
+        spin_unlock(&ring_info->lock);
+        if ( ret )
+            break;
+
+        if ( !need_to_insert )
+        {
+            read_unlock(&d->v4v->lock);
+        }
+        else
+        {
+            uint16_t hash =3D v4v_hash_fn(&ring.id);
+            write_lock(&d->v4v->lock);
+            hlist_add_head(&ring_info->node, &d->v4v->ring_hash[hash]);
+            write_unlock(&d->v4v->lock);
+        }
+    }
+    while ( 0 );
+
+    read_unlock(&v4v_lock);
+    return ret;
+}
+
+
+/*
+ * io
+ */
+
+static void
+v4v_notify_ring(struct domain *d, struct v4v_ring_info *ring_info,
+                struct hlist_head *to_notify)
+{
+    uint32_t space;
+
+    ASSERT(rw_is_locked(&v4v_lock));
+    ASSERT(rw_is_locked(&d->v4v->lock));
+
+    spin_lock(&ring_info->lock);
+    space =3D v4v_ringbuf_payload_space(d, ring_info);
+    spin_unlock(&ring_info->lock);
+
+    v4v_pending_find(d, ring_info, space, to_notify);
+}
+
+/*notify hypercall*/
+static long
+v4v_notify(struct domain *d,
+           XEN_GUEST_HANDLE(v4v_ring_data_t) ring_data_hnd)
+{
+    v4v_ring_data_t ring_data;
+    HLIST_HEAD(to_notify);
+    int i;
+    int ret =3D 0;
+
+    read_lock(&v4v_lock);
+
+    if ( !d->v4v )
+    {
+        read_unlock(&v4v_lock);
+        v4v_dprintk("!d->v4v, ENODEV\n");
+        return -ENODEV;
+    }
+
+    read_lock(&d->v4v->lock);
+    for ( i =3D 0; i < V4V_HTABLE_SIZE; ++i )
+    {
+        struct hlist_node *node, *next;
+        struct v4v_ring_info *ring_info;
+
+        hlist_for_each_entry_safe(ring_info, node,
+                next, &d->v4v->ring_hash[i],
+                node)
+        {
+            v4v_notify_ring(d, ring_info, &to_notify);
+        }
+    }
+    read_unlock(&d->v4v->lock);
+
+    if ( !hlist_empty(&to_notify) )
+        v4v_pending_notify(d, &to_notify);
+
+    do
+    {
+        if ( !guest_handle_is_null(ring_data_hnd) )
+        {
+            /* Quick sanity check on ring_data_hnd */
+            if ( copy_field_from_guest(&ring_data, ring_data_hnd, magic)=
 )
+            {
+                v4v_dprintk("copy_field_from_guest failed\n");
+                ret =3D -EFAULT;
+                break;
+            }
+
+            if ( ring_data.magic !=3D V4V_RING_DATA_MAGIC )
+            {
+                v4v_dprintk("ring.magic(%lx) !=3D V4V_RING_MAGIC(%lx), E=
INVAL\n",
+                        ring_data.magic, V4V_RING_MAGIC);
+                ret =3D -EINVAL;
+                break;
+            }
+
+            if ( copy_from_guest(&ring_data, ring_data_hnd, 1) )
+            {
+                v4v_dprintk("copy_from_guest failed\n");
+                ret =3D -EFAULT;
+                break;
+            }
+
+            {
+                XEN_GUEST_HANDLE(v4v_ring_data_ent_t) ring_data_ent_hnd;
+                ring_data_ent_hnd =3D
+                    guest_handle_for_field(ring_data_hnd, v4v_ring_data_=
ent_t, data[0]);
+                ret =3D v4v_fill_ring_datas(d, ring_data.nent, ring_data=
_ent_hnd);
+            }
+        }
+    }
+    while ( 0 );
+
+    read_unlock(&v4v_lock);
+
+    return ret;
+}
+
+#ifdef V4V_DEBUG
+void
+v4vtables_print_rule(struct v4vtables_rule_node *node)
+{
+    v4vtables_rule_t *rule;
+
+    if ( node =3D=3D NULL )
+    {
+        printk("(null)\n");
+        return;
+    }
+
+    rule =3D &node->rule;
+
+    if ( rule->accept =3D=3D 1 )
+        printk("ACCEPT");
+    else
+        printk("REJECT");
+
+    printk(" ");
+
+    if ( rule->src.domain =3D=3D V4V_DOMID_ANY )
+        printk("*");
+    else
+        printk("%i", rule->src.domain);
+
+    printk(":");
+
+    if ( rule->src.port =3D=3D -1 )
+        printk("*");
+    else
+        printk("%i", rule->src.port);
+
+    printk(" -> ");
+
+    if ( rule->dst.domain =3D=3D V4V_DOMID_ANY )
+        printk("*");
+    else
+        printk("%i", rule->dst.domain);
+
+    printk(":");
+
+    if ( rule->dst.port =3D=3D -1 )
+        printk("*");
+    else
+        printk("%i", rule->dst.port);
+
+    printk("\n");
+}
+#endif /* V4V_DEBUG */
+
+int
+v4vtables_add(struct domain *src_d,
+              XEN_GUEST_HANDLE(v4vtables_rule_t) rule,
+              int32_t position)
+{
+    struct v4vtables_rule_node* new =3D NULL;
+    struct list_head* tmp;
+
+    ASSERT(rw_is_write_locked(&v4vtables_rules_lock));
+
+    /* First rule is n.1 */
+    position--;
+
+    new =3D xmalloc(struct v4vtables_rule_node);
+    if ( new =3D=3D NULL )
+        return -ENOMEM;
+
+    if ( copy_from_guest(&new->rule, rule, 1) )
+    {
+        xfree(new);
+        return -EFAULT;
+    }
+
+#ifdef V4V_DEBUG
+    printk(KERN_ERR "VIPTables: ");
+    v4vtables_print_rule(new);
+#endif /* V4V_DEBUG */
+
+    tmp =3D &v4vtables_rules;
+    while ( position !=3D 0 && tmp->next !=3D &v4vtables_rules)
+    {
+        tmp =3D tmp->next;
+        position--;
+    }
+    list_add(&new->list, tmp);
+
+    return 0;
+}
+
+int
+v4vtables_del(struct domain *src_d,
+              XEN_GUEST_HANDLE(v4vtables_rule_t) rule_hnd,
+              int32_t position)
+{
+    struct list_head *tmp =3D NULL;
+    struct list_head *to_delete =3D NULL;
+    struct list_head *next =3D NULL;
+    struct v4vtables_rule_node *node;
+
+    ASSERT(rw_is_write_locked(&v4vtables_rules_lock));
+
+    v4v_dprintk("v4vtables_del position:%d\n", position);
+
+    if ( position !=3D -1 )
+    {
+        /* We want to delete the rule number  */
+        list_for_each(tmp, &v4vtables_rules)
+        {
+            to_delete =3D tmp;
+            if (position =3D=3D 0)
+                break;
+            position--;
+        }
+        /* Can't find the position */
+        if (position !=3D 0)
+            to_delete =3D NULL;
+    }
+    else if ( !guest_handle_is_null(rule_hnd) )
+    {
+        struct v4vtables_rule r;
+
+        if ( copy_from_guest(&r, rule_hnd, 1) )
+            return -EFAULT;
+
+        list_for_each(tmp, &v4vtables_rules)
+        {
+            node =3D list_entry(tmp, struct v4vtables_rule_node, list);
+
+            if ( (node->rule.src.domain =3D=3D r.src.domain) &&
+                 (node->rule.src.port   =3D=3D r.src.port)   &&
+                 (node->rule.dst.domain =3D=3D r.dst.domain) &&
+                 (node->rule.dst.port   =3D=3D r.dst.port))
+            {
+                to_delete =3D tmp;
+                break;
+            }
+        }
+    }
+    else
+    {
+        /* We want to flush the rules! */
+        printk(KERN_ERR "VIPTables: flushing rules\n");
+        list_for_each_safe(tmp, next, &v4vtables_rules)
+        {
+            node =3D list_entry(tmp, struct v4vtables_rule_node, list);
+            list_del(tmp);
+            xfree(node);
+        }
+    }
+
+    if ( to_delete )
+    {
+        node =3D list_entry(to_delete, struct v4vtables_rule_node, list)=
;
+#ifdef V4V_DEBUG
+        printk(KERN_ERR "VIPTables: deleting rule: ");
+        v4vtables_print_rule(node);
+#endif /* V4V_DEBUG */
+        list_del(to_delete);
+        xfree(node);
+    }
+
+    return 0;
+}
+
+static size_t
+v4vtables_list(struct domain *src_d,
+               XEN_GUEST_HANDLE(v4vtables_list_t) list_hnd)
+{
+    struct list_head *ptr;
+    struct v4vtables_rule_node *node;
+    struct v4vtables_list rules_list;
+    uint32_t nbrules;
+    XEN_GUEST_HANDLE(v4vtables_rule_t) guest_rules;
+
+    ASSERT(rw_is_locked(&v4vtables_rules_lock));
+
+    memset(&rules_list, 0, sizeof (rules_list));
+    if ( copy_from_guest(&rules_list, list_hnd, 1) )
+        return -EFAULT;
+
+    ptr =3D v4vtables_rules.next;
+    while ( rules_list.start_rule !=3D 0 && ptr->next !=3D &v4vtables_ru=
les )
+    {
+        ptr =3D ptr->next;
+        rules_list.start_rule--;
+    }
+
+    if ( rules_list.nb_rules =3D=3D 0 )
+        return -EINVAL;
+
+    guest_rules =3D guest_handle_for_field(list_hnd, v4vtables_rule_t, r=
ules[0]);
+
+    nbrules =3D 0;
+    while ( nbrules < rules_list.nb_rules && ptr !=3D &v4vtables_rules )
+    {
+        node =3D list_entry(ptr, struct v4vtables_rule_node, list);
+
+        if ( copy_to_guest(guest_rules, &node->rule, 1) )
+            break;
+
+        guest_handle_add_offset(guest_rules, 1);
+
+        nbrules++;
+        ptr =3D ptr->next;
+    }
+
+    rules_list.nb_rules =3D nbrules;
+    if ( copy_field_to_guest(list_hnd, &rules_list, nb_rules) )
+        return -EFAULT;
+
+    return 0;
+}
+
+static size_t
+v4vtables_check(v4v_addr_t * src, v4v_addr_t * dst)
+{
+    struct list_head *ptr;
+    struct v4vtables_rule_node *node;
+    size_t ret =3D 0; /* Defaulting to ACCEPT */
+
+    read_lock(&v4vtables_rules_lock);
+
+    list_for_each(ptr, &v4vtables_rules)
+    {
+        node =3D list_entry(ptr, struct v4vtables_rule_node, list);
+
+        if ( (node->rule.src.domain =3D=3D V4V_DOMID_ANY ||
+              node->rule.src.domain =3D=3D src->domain) &&
+             (node->rule.src.port =3D=3D V4V_PORT_ANY ||
+              node->rule.src.port =3D=3D src->port) &&
+             (node->rule.dst.domain =3D=3D V4V_DOMID_ANY ||
+              node->rule.dst.domain =3D=3D dst->domain) &&
+             (node->rule.dst.port =3D=3D V4V_PORT_ANY ||
+              node->rule.dst.port =3D=3D dst->port) )
+        {
+            ret =3D !node->rule.accept;
+            break;
+        }
+    }
+
+    read_unlock(&v4vtables_rules_lock);
+    return ret;
+}
+
+/*
+ * Hypercall to do the send
+ */
+static long
+v4v_sendv(struct domain *src_d, v4v_addr_t * src_addr,
+          v4v_addr_t * dst_addr, uint32_t proto,
+          XEN_GUEST_HANDLE(v4v_iov_t) iovs, size_t niov)
+{
+    struct domain *dst_d;
+    v4v_ring_id_t src_id;
+    struct v4v_ring_info *ring_info;
+    int ret =3D 0;
+
+    if ( !dst_addr )
+    {
+        v4v_dprintk("!dst_addr, EINVAL\n");
+        return -EINVAL;
+    }
+
+    read_lock(&v4v_lock);
+    if ( !src_d->v4v )
+    {
+        read_unlock(&v4v_lock);
+        v4v_dprintk("!src_d->v4v, EINVAL\n");
+        return -EINVAL;
+    }
+
+    src_id.addr.port =3D src_addr->port;
+    src_id.addr.domain =3D src_d->domain_id;
+    src_id.partner =3D dst_addr->domain;
+
+    dst_d =3D get_domain_by_id(dst_addr->domain);
+    if ( !dst_d )
+    {
+        read_unlock(&v4v_lock);
+        v4v_dprintk("!dst_d, ECONNREFUSED\n");
+        return -ECONNREFUSED;
+    }
+
+    if ( v4vtables_check(src_addr, dst_addr) !=3D 0 )
+    {
+        read_unlock(&v4v_lock);
+        gdprintk(XENLOG_WARNING,
+                 "V4V: VIPTables REJECTED %i:%i -> %i:%i\n",
+                 src_addr->domain, src_addr->port,
+                 dst_addr->domain, dst_addr->port);
+        return -ECONNREFUSED;
+    }
+
+    do
+    {
+        if ( !dst_d->v4v )
+        {
+            v4v_dprintk("dst_d->v4v, ECONNREFUSED\n");
+            ret =3D -ECONNREFUSED;
+            break;
+        }
+
+        read_lock(&dst_d->v4v->lock);
+        ring_info =3D
+            v4v_ring_find_info_by_addr(dst_d, dst_addr, src_addr->domain=
);
+
+        if ( !ring_info )
+        {
+            ret =3D -ECONNREFUSED;
+            v4v_dprintk(" !ring_info, ECONNREFUSED\n");
+        }
+        else
+        {
+            long len =3D v4v_iov_count(iovs, niov);
+
+            if ( len < 0 )
+            {
+                ret =3D len;
+                break;
+            }
+
+            spin_lock(&ring_info->lock);
+            ret =3D
+                v4v_ringbuf_insertv(dst_d, ring_info, &src_id, proto, io=
vs,
+                        niov, len);
+            if ( ret =3D=3D -EAGAIN )
+            {
+                v4v_dprintk("v4v_ringbuf_insertv failed, EAGAIN\n");
+                /* Schedule a wake up on the event channel when space is=
 there */
+                if ( v4v_pending_requeue(ring_info, src_d->domain_id, le=
n) )
+                {
+                    v4v_dprintk("v4v_pending_requeue failed, ENOMEM\n");
+                    ret =3D -ENOMEM;
+                }
+            }
+            spin_unlock(&ring_info->lock);
+
+            if ( ret >=3D 0 )
+            {
+                v4v_signal_domain(dst_d);
+            }
+
+        }
+        read_unlock(&dst_d->v4v->lock);
+
+    }
+    while ( 0 );
+
+    put_domain(dst_d);
+    read_unlock(&v4v_lock);
+    return ret;
+}
+
+static void
+v4v_info(struct domain *d, v4v_info_t *info)
+{
+    read_lock(&d->v4v->lock);
+    info->ring_magic =3D V4V_RING_MAGIC;
+    info->data_magic =3D V4V_RING_DATA_MAGIC;
+    info->evtchn =3D d->v4v->evtchn_port;
+    read_unlock(&d->v4v->lock);
+}
+
+/*
+ * hypercall glue
+ */
+long
+do_v4v_op(int cmd, XEN_GUEST_HANDLE(void) arg1,
+          XEN_GUEST_HANDLE(void) arg2,
+          uint32_t arg3, uint32_t arg4)
+{
+    struct domain *d =3D current->domain;
+    long rc =3D -EFAULT;
+
+    v4v_dprintk("->do_v4v_op(%d,%p,%p,%d,%d)\n", cmd,
+                (void *)arg1.p, (void *)arg2.p, (int) arg3, (int) arg4);
+
+    domain_lock(d);
+    switch (cmd)
+    {
+        case V4VOP_register_ring:
+            {
+                XEN_GUEST_HANDLE(v4v_ring_t) ring_hnd =3D
+                    guest_handle_cast(arg1, v4v_ring_t);
+                XEN_GUEST_HANDLE(v4v_pfn_t) pfn_hnd =3D
+                    guest_handle_cast(arg2, v4v_pfn_t);
+                uint32_t npage =3D arg3;
+                if ( unlikely(!guest_handle_okay(pfn_hnd, npage)) )
+                    goto out;
+                rc =3D v4v_ring_add(d, ring_hnd, npage, pfn_hnd);
+                break;
+            }
+        case V4VOP_unregister_ring:
+            {
+                XEN_GUEST_HANDLE(v4v_ring_t) ring_hnd =3D
+                    guest_handle_cast(arg1, v4v_ring_t);
+                rc =3D v4v_ring_remove(d, ring_hnd);
+                break;
+            }
+        case V4VOP_sendv:
+            {
+                uint32_t niov =3D arg3;
+                uint32_t message_type =3D arg4;
+                XEN_GUEST_HANDLE(v4v_send_addr_t) addr_hnd =3D
+                    guest_handle_cast(arg1, v4v_send_addr_t);
+                v4v_send_addr_t addr;
+
+                if ( copy_from_guest(&addr, addr_hnd, 1) )
+                    goto out;
+
+                rc =3D v4v_sendv(d, &addr.src, &addr.dst, message_type,
+                        guest_handle_cast(arg2, v4v_iov_t), niov);
+                break;
+            }
+        case V4VOP_notify:
+            {
+                XEN_GUEST_HANDLE(v4v_ring_data_t) ring_data_hnd =3D
+                    guest_handle_cast(arg1, v4v_ring_data_t);
+                rc =3D v4v_notify(d, ring_data_hnd);
+                break;
+            }
+        case V4VOP_tables_add:
+            {
+                uint32_t position =3D arg3;
+                XEN_GUEST_HANDLE(v4vtables_rule_t) rule_hnd =3D
+                    guest_handle_cast(arg1, v4vtables_rule_t);
+                rc =3D -EPERM;
+                if ( !IS_PRIV(d) )
+                    goto out;
+
+                write_lock(&v4vtables_rules_lock);
+                rc =3D v4vtables_add(d, rule_hnd, position);
+                write_unlock(&v4vtables_rules_lock);
+                break;
+            }
+        case V4VOP_tables_del:
+            {
+                uint32_t position =3D arg3;
+                XEN_GUEST_HANDLE(v4vtables_rule_t) rule_hnd =3D
+                    guest_handle_cast(arg1, v4vtables_rule_t);
+                rc =3D -EPERM;
+                if ( !IS_PRIV(d) )
+                    goto out;
+
+                write_lock(&v4vtables_rules_lock);
+                rc =3D v4vtables_del(d, rule_hnd, position);
+                write_unlock(&v4vtables_rules_lock);
+                break;
+            }
+        case V4VOP_tables_list:
+            {
+                XEN_GUEST_HANDLE(v4vtables_list_t) rules_list_hnd =3D
+                    guest_handle_cast(arg1, v4vtables_list_t);
+                rc =3D -EPERM;
+                if ( !IS_PRIV(d) )
+                    goto out;
+
+                read_lock(&v4vtables_rules_lock);
+                rc =3D v4vtables_list(d, rules_list_hnd);
+                read_unlock(&v4vtables_rules_lock);
+                break;
+            }
+        case V4VOP_info:
+            {
+                XEN_GUEST_HANDLE(v4v_info_t) info_hnd =3D
+                    guest_handle_cast(arg1, v4v_info_t);
+                v4v_info_t info;
+
+                if ( unlikely(!guest_handle_okay(info_hnd, 1)) )
+                    goto out;
+                v4v_info(d, &info);
+                if ( __copy_to_guest(info_hnd, &info, 1) )
+                    goto out;
+                rc =3D 0;
+                break;
+            }
+        default:
+            rc =3D -ENOSYS;
+            break;
+    }
+out:
+    domain_unlock(d);
+    v4v_dprintk("<-do_v4v_op()=3D%d\n", (int)rc);
+    return rc;
+}
+
+/*
+ * init
+ */
+
+void
+v4v_destroy(struct domain *d)
+{
+    int i;
+
+    BUG_ON(!d->is_dying);
+    write_lock(&v4v_lock);
+
+    v4v_dprintk("d->v=3D%p\n", d->v4v);
+
+    if ( d->v4v )
+    {
+        for ( i =3D 0; i < V4V_HTABLE_SIZE; ++i )
+        {
+            struct hlist_node *node, *next;
+            struct v4v_ring_info *ring_info;
+
+            hlist_for_each_entry_safe(ring_info, node,
+                    next, &d->v4v->ring_hash[i],
+                    node)
+            {
+                v4v_ring_remove_info(d, ring_info);
+            }
+        }
+    }
+
+    d->v4v =3D NULL;
+    write_unlock(&v4v_lock);
+}
+
+int
+v4v_init(struct domain *d)
+{
+    struct v4v_domain *v4v;
+    evtchn_port_t port;
+    int i;
+    int rc;
+
+    v4v =3D xmalloc(struct v4v_domain);
+    if ( !v4v )
+        return -ENOMEM;
+
+    rc =3D evtchn_alloc_unbound_domain(d, &port, d->domain_id);
+    if ( rc )
+        return rc;
+
+    rwlock_init(&v4v->lock);
+
+    v4v->evtchn_port =3D port;
+    for ( i =3D 0; i < V4V_HTABLE_SIZE; ++i )
+        INIT_HLIST_HEAD(&v4v->ring_hash[i]);
+
+    write_lock(&v4v_lock);
+    d->v4v =3D v4v;
+    write_unlock(&v4v_lock);
+
+    return 0;
+}
+
+
+/*
+ * debug
+ */
+
+static void
+dump_domain_ring(struct domain *d, struct v4v_ring_info *ring_info)
+{
+    uint32_t rx_ptr;
+
+    printk(KERN_ERR "  ring: domid=3D%d port=3D0x%08x partner=3D%d npage=
=3D%d\n",
+           (int)d->domain_id, (int)ring_info->id.addr.port,
+           (int)ring_info->id.partner, (int)ring_info->npage);
+
+    if ( v4v_ringbuf_get_rx_ptr(d, ring_info, &rx_ptr) )
+    {
+        printk(KERN_ERR "   Failed to read rx_ptr\n");
+        return;
+    }
+
+    printk(KERN_ERR "   tx_ptr=3D%d rx_ptr=3D%d len=3D%d\n",
+           (int)ring_info->tx_ptr, (int)rx_ptr, (int)ring_info->len);
+}
+
+static void
+dump_domain(struct domain *d)
+{
+    int i;
+
+    printk(KERN_ERR " domain %d:\n", (int)d->domain_id);
+
+    read_lock(&d->v4v->lock);
+
+    for ( i =3D 0; i < V4V_HTABLE_SIZE; ++i )
+    {
+        struct hlist_node *node;
+        struct v4v_ring_info *ring_info;
+
+        hlist_for_each_entry(ring_info, node, &d->v4v->ring_hash[i], nod=
e)
+            dump_domain_ring(d, ring_info);
+    }
+
+    printk(KERN_ERR "  event channel: %d\n",  d->v4v->evtchn_port);
+    read_unlock(&d->v4v->lock);
+
+    printk(KERN_ERR "\n");
+    v4v_signal_domain(d);
+}
+
+static void
+dump_state(unsigned char key)
+{
+    struct domain *d;
+
+    printk(KERN_ERR "\n\nV4V:\n");
+    read_lock(&v4v_lock);
+
+    rcu_read_lock(&domlist_read_lock);
+
+    for_each_domain(d)
+        dump_domain(d);
+
+    rcu_read_unlock(&domlist_read_lock);
+
+    read_unlock(&v4v_lock);
+}
+
+struct keyhandler v4v_info_keyhandler =3D
+{
+    .diagnostic =3D 1,
+    .u.fn =3D dump_state,
+    .desc =3D "dump v4v states and interupt"
+};
+
+static int __init
+setup_dump_rings(void)
+{
+    register_keyhandler('4', &v4v_info_keyhandler);
+    return 0;
+}
+
+__initcall(setup_dump_rings);
+
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/public/v4v.h b/xen/include/public/v4v.h
new file mode 100644
index 0000000..3d55229
--- /dev/null
+++ b/xen/include/public/v4v.h
@@ -0,0 +1,308 @@
+/***********************************************************************=
*******
+ * V4V
+ *
+ * Version 2 of v2v (Virtual-to-Virtual)
+ *
+ * Copyright (c) 2010, Citrix Systems
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 =
 USA
+ */
+
+#ifndef __XEN_PUBLIC_V4V_H__
+#define __XEN_PUBLIC_V4V_H__
+
+#include "xen.h"
+#include "event_channel.h"
+
+/*
+ * Structure definitions
+ */
+
+#define V4V_RING_MAGIC          0xa822f72bb0b9d8ccUL
+#define V4V_RING_DATA_MAGIC	0x45fe852220b801d4UL
+
+#define V4V_MESSAGE_DGRAM       0x3c2c1db8
+#define V4V_MESSAGE_STREAM 	0x70f6a8e5
+
+#define V4V_DOMID_ANY           DOMID_INVALID
+#define V4V_PORT_ANY            0
+
+typedef uint64_t v4v_pfn_t;
+
+typedef struct v4v_iov
+{
+    uint64_t iov_base;
+    uint32_t iov_len;
+    uint32_t pad;
+} v4v_iov_t;
+
+typedef struct v4v_addr
+{
+    uint32_t port;
+    domid_t domain;
+    uint16_t pad;
+} v4v_addr_t;
+
+typedef struct v4v_ring_id
+{
+    v4v_addr_t addr;
+    domid_t partner;
+    uint16_t pad;
+} v4v_ring_id_t;
+
+typedef struct
+{
+    v4v_addr_t src;
+    v4v_addr_t dst;
+} v4v_send_addr_t;
+
+/*
+ * v4v_ring
+ * id: xen only looks at this during register/unregister
+ *     and will fill in id.addr.domain
+ * rx_ptr: rx pointer, modified by domain
+ * tx_ptr: tx pointer, modified by xen
+ *
+ */
+struct v4v_ring
+{
+    uint64_t magic;
+    v4v_ring_id_t id;
+    uint32_t len;
+    uint32_t rx_ptr;
+    uint32_t tx_ptr;
+    uint8_t reserved[32];
+#if defined(__STDC_VERSION__) && __STDC_VERSION__ >=3D 199901L
+    uint8_t ring[];
+#elif defined(__GNUC__)
+    uint8_t ring[0];
+#endif
+};
+typedef struct v4v_ring v4v_ring_t;
+
+#define V4V_RING_DATA_F_EMPTY       (1U << 0) /* Ring is empty */
+#define V4V_RING_DATA_F_EXISTS      (1U << 1) /* Ring exists */
+#define V4V_RING_DATA_F_PENDING     (1U << 2) /* Pending interrupt exist=
s - do not
+                                               * rely on this field - fo=
r
+                                               * profiling only */
+#define V4V_RING_DATA_F_SUFFICIENT  (1U << 3) /* Sufficient space to que=
ue
+                                               * space_required bytes ex=
ists */
+
+typedef struct v4v_ring_data_ent
+{
+    v4v_addr_t ring;
+    uint16_t flags;
+    uint32_t space_required;
+    uint32_t max_message_size;
+} v4v_ring_data_ent_t;
+
+typedef struct v4v_ring_data
+{
+    uint64_t magic;
+    uint32_t nent;
+    uint32_t pad;
+    uint64_t reserved[4];
+#if defined(__STDC_VERSION__) && __STDC_VERSION__ >=3D 199901L
+    v4v_ring_data_ent_t data[];
+#elif defined(__GNUC__)
+    v4v_ring_data_ent_t data[0];
+#endif
+} v4v_ring_data_t;
+
+struct v4v_info
+{
+    uint64_t ring_magic;
+    uint64_t data_magic;
+    evtchn_port_t evtchn;
+    uint32_t pad;
+};
+typedef struct v4v_info v4v_info_t;
+
+#define V4V_SHF_SYN		(1 << 0)
+#define V4V_SHF_ACK		(1 << 1)
+#define V4V_SHF_RST		(1 << 2)
+
+#define V4V_SHF_PING		(1 << 8)
+#define V4V_SHF_PONG		(1 << 9)
+
+struct v4v_stream_header
+{
+    uint32_t flags;
+    uint32_t conid;
+};
+
+struct v4v_ring_message_header
+{
+    uint32_t len;
+    uint32_t pad0;
+    v4v_addr_t source;
+    uint32_t message_type;
+#if defined(__STDC_VERSION__) && __STDC_VERSION__ >=3D 199901L
+    uint8_t data[];
+#elif defined(__GNUC__)
+    uint8_t data[0];
+#endif
+};
+
+typedef struct v4vtables_rule
+{
+    v4v_addr_t src;
+    v4v_addr_t dst;
+    uint32_t accept;
+    uint32_t pad;
+} v4vtables_rule_t;
+
+typedef struct v4vtables_list
+{
+    uint32_t start_rule;
+    uint32_t nb_rules;
+#if defined(__STDC_VERSION__) && __STDC_VERSION__ >=3D 199901L
+    struct v4vtables_rule rules[];
+#elif defined(__GNUC__)
+    struct v4vtables_rule rules[0];
+#endif
+} v4vtables_list_t;
+
+/*
+ * HYPERCALLS
+ */
+
+/*
+ * V4VOP_register_ring
+ *
+ * Registers a ring with Xen. If a ring with the same v4v_ring_id exists=
,
+ * the hypercall will return -EEXIST.
+ *
+ * do_v4v_op(V4VOP_register_ring,
+ *           XEN_GUEST_HANDLE(v4v_ring_t), XEN_GUEST_HANDLE(v4v_pfn_t),
+ *           npage, 0)
+ */
+#define V4VOP_register_ring 	1
+
+
+/*
+ * V4VOP_unregister_ring
+ *
+ * Unregister a ring.
+ *
+ * do_v4v_op(V4VOP_unregister_ring,
+ *           XEN_GUEST_HANDLE(v4v_ring_t),
+ *           NULL, 0, 0)
+ */
+#define V4VOP_unregister_ring 	2
+
+/*
+ * V4VOP_notify
+ *
+ * Asks xen for information about other rings in the system
+ *
+ * ent->ring is the v4v_addr_t of the ring you want information on
+ * the same matching rules are used as for V4VOP_send.
+ *
+ * ent->space_required  if this field is not null xen will check
+ * that there is space in the destination ring for this many bytes
+ * of payload. If there is it will set the V4V_RING_DATA_F_SUFFICIENT
+ * and CANCEL any pending interrupt for that ent->ring, if insufficient
+ * space is available it will schedule an interrupt and the flag will
+ * not be set.
+ *
+ * The flags are set by xen when notify replies
+ * V4V_RING_DATA_F_EMPTY	ring is empty
+ * V4V_RING_DATA_F_PENDING	interrupt is pending - don't rely on this
+ * V4V_RING_DATA_F_SUFFICIENT	sufficient space for space_required is the=
re
+ * V4V_RING_DATA_F_EXISTS	ring exists
+ *
+ * do_v4v_op(V4VOP_notify,
+ *           XEN_GUEST_HANDLE(v4v_ring_data_ent_t) ent,
+ *           NULL, 0, 0)
+ */
+#define V4VOP_notify 		4
+
+/*
+ * V4VOP_sendv
+ *
+ * Sends of list of buffer contained in iov.
+ *
+ * For each iov entry send iov_len bytes of iov_base to addr.dst, giving
+ * src as the source address (xen will ignore src->domain and put your
+ * domain in the actually message), xen first looks for a ring with id.a=
ddr=3D=3Ddst
+ * and id.partner=3D=3Dsending_domain if that fails it looks for id.addr=
=3D=3Ddst and
+ * id.partner=3D=3DDOMID_ANY.
+ * message_type is the 32 bit number used from the message
+ * most likely V4V_MESSAGE_DGRAM or V4V_MESSAGE_STREAM. If insufficient =
space exists
+ * it will return -EAGAIN and xen will twing the V4V_INTERRUPT when
+ * sufficient space becomes available
+ *
+ * do_v4v_op(V4VOP_sendv,
+ *           XEN_GUEST_HANDLE(v4v_send_addr_t) addr,
+ *           XEN_GUEST_HANDLE(v4v_iov_t) iov,
+ *           uint32_t niov,
+ *           uint32_t message_type)
+ */
+#define V4VOP_sendv		5
+
+/*
+ * V4VOP_tables_add
+ *
+ * Insert a filtering rules after a given position.
+ *
+ * do_v4v_op(V4VOP_tables_add,
+ *           XEN_GUEST_HANDLE(v4vtables_rule_t) rule,
+ *           NULL,
+ *           uint32_t position, 0)
+ */
+#define V4VOP_tables_add     6
+
+/*
+ * V4VOP_tables_del
+ *
+ * Delete a filtering rules at a position or the rule
+ * that matches "rule".
+ *
+ * do_v4v_op(V4VOP_tables_del,
+ *           XEN_GUEST_HANDLE(v4vtables_rule_t) rule,
+ *           NULL,
+ *           uint32_t position, 0)
+ */
+#define V4VOP_tables_del     7
+
+/*
+ * V4VOP_tables_list
+ *
+ * do_v4v_op(V4VOP_tables_list,
+ *           XEN_GUEST_HANDLE(v4vtpables_list_t) list,
+ *           NULL, 0, 0)
+ */
+#define V4VOP_tables_list    8
+
+/*
+ * V4VOP_info
+ *
+ * Returns v4v info for the current domain (domain that issued the hyper=
call).
+ *      - V4V magic number
+ *      - event channel port (for current domain)
+ *
+ * do_v4v_op(V4VOP_info,
+ *           XEN_GUEST_HANDLE(v4v_info_t) info,
+ *           NULL, 0, 0)
+ */
+#define V4VOP_info              9
+
+#endif /* __XEN_PUBLIC_V4V_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 268df3e..b3e6d40 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -100,7 +100,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
 #define __HYPERVISOR_domctl               36
 #define __HYPERVISOR_kexec_op             37
 #define __HYPERVISOR_tmem_op              38
-#define __HYPERVISOR_xc_reserved_op       39 /* reserved for XenClient *=
/
+#define __HYPERVISOR_v4v_op               39
=20
 /* Architecture-specific hypercall definitions. */
 #define __HYPERVISOR_arch_0               48
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 6c55039..2fd9313 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
=20
 #ifdef CONFIG_COMPAT
 #include 
@@ -363,6 +364,9 @@ struct domain
     nodemask_t node_affinity;
     unsigned int last_alloc_node;
     spinlock_t node_affinity_lock;
+
+    /* v4v */
+    struct v4v_domain *v4v;
 };
=20
 struct domain_setup_info
diff --git a/xen/include/xen/v4v.h b/xen/include/xen/v4v.h
new file mode 100644
index 0000000..d09e2cc
--- /dev/null
+++ b/xen/include/xen/v4v.h
@@ -0,0 +1,134 @@
+/***********************************************************************=
*******
+ * V4V
+ *
+ * Version 2 of v2v (Virtual-to-Virtual)
+ *
+ * Copyright (c) 2010, Citrix Systems
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 =
 USA
+ */
+
+#ifndef __V4V_PRIVATE_H__
+#define __V4V_PRIVATE_H__
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define V4V_HTABLE_SIZE 32
+
+/*
+ * Handlers
+ */
+
+DEFINE_XEN_GUEST_HANDLE (v4v_iov_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_addr_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_send_addr_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_ring_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_ent_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_info_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_pfn_t);
+
+DEFINE_XEN_GUEST_HANDLE (v4vtables_rule_t);
+DEFINE_XEN_GUEST_HANDLE (v4vtables_list_t);
+
+/*
+ * Helper functions
+ */
+
+static inline uint16_t
+v4v_hash_fn (v4v_ring_id_t *id)
+{
+    uint16_t ret;
+    ret =3D (uint16_t) (id->addr.port >> 16);
+    ret ^=3D (uint16_t) id->addr.port;
+    ret ^=3D id->addr.domain;
+    ret ^=3D id->partner;
+
+    ret &=3D (V4V_HTABLE_SIZE-1);
+
+    return ret;
+}
+
+struct v4v_pending_ent
+{
+    struct hlist_node node;
+    domid_t id;
+    uint32_t len;
+};
+
+
+struct v4v_ring_info
+{
+    /* next node in the hash, protected by L2  */
+    struct hlist_node node;
+    /* this ring's id, protected by L2 */
+    v4v_ring_id_t id;
+    /* L3 */
+    spinlock_t lock;
+    /* cached length of the ring (from ring->len), protected by L3 */
+    uint32_t len;
+    uint32_t npage;
+    /* cached tx pointer location, protected by L3 */
+    uint32_t tx_ptr;
+    /* guest ring, protected by L3 */
+    XEN_GUEST_HANDLE(v4v_ring_t) ring;
+    /* mapped ring pages protected by L3*/
+    uint8_t **mfn_mapping;
+    /* list of mfns of guest ring */
+    mfn_t *mfns;
+    /* list of struct v4v_pending_ent for this ring, L3 */
+    struct hlist_head pending;
+};
+
+/*
+ * The value of the v4v element in a struct domain is
+ * protected by the global lock L1
+ */
+struct v4v_domain
+{
+    /* L2 */
+    rwlock_t lock;
+    /* event channel */
+    evtchn_port_t evtchn_port;
+    /* protected by L2 */
+    struct hlist_head ring_hash[V4V_HTABLE_SIZE];
+};
+
+typedef struct v4vtables_rule_node
+{
+    struct list_head list;
+    v4vtables_rule_t rule;
+} v4vtables_rule_node_t;
+
+void v4v_destroy(struct domain *d);
+int v4v_init(struct domain *d);
+long do_v4v_op (int cmd,
+                XEN_GUEST_HANDLE (void) arg1,
+                XEN_GUEST_HANDLE (void) arg2,
+                uint32_t arg3,
+                uint32_t arg4);
+
+#endif /* __V4V_PRIVATE_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */

--------------true
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------true--


From xen-devel-bounces@lists.xen.org Thu Oct 25 11:49:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 11:49:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRLvv-0008UM-Fo; Thu, 25 Oct 2012 11:49:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRLvt-0008Tm-Vk
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 11:49:06 +0000
Received: from [85.158.139.211:30012] by server-13.bemta-5.messagelabs.com id
	14/CF-27809-13729805; Thu, 25 Oct 2012 11:49:05 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1351165743!23220136!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6273 invoked from network); 25 Oct 2012 11:49:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 11:49:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,646,1344211200"; d="scan'208";a="15386526"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 11:49:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 12:49:01 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53] helo=spongy)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TRLvo-0003zo-Vf;
	Thu, 25 Oct 2012 11:49:01 +0000
Received: by spongy (Postfix, from userid 2023)	id 08023340D87; Thu, 25 Oct
	2012 12:52:09 +0100 (BST)
From: Jean Guyader 
To: 
Date: Thu, 25 Oct 2012 12:52:05 +0100
Message-ID: <1351165926-23259-3-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1351165926-23259-1-git-send-email-jean.guyader@citrix.com>
References: <1351165926-23259-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: tim@xen.org, Jean Guyader , JBeulich@suse.com
Subject: [Xen-devel] [PATCH 2/3] xen: events,
	exposes evtchn_alloc_unbound_domain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: quoted-printable


Exposes evtchn_alloc_unbound_domain to the rest of
Xen so we can create allocated unbound evtchn within Xen.

Signed-off-by: Jean Guyader 
---
 xen/common/event_channel.c |   39 +++++++++++++++++++++++++++-----------=
-
 xen/include/xen/event.h    |    3 +++
 2 files changed, 30 insertions(+), 12 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0002-xen-events-exposes-evtchn_alloc_unbound_domain.patch"
Content-Disposition: attachment;
	filename="0002-xen-events-exposes-evtchn_alloc_unbound_domain.patch"
Content-Transfer-Encoding: quoted-printable

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index a80a0d1..a868b89 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -159,36 +159,51 @@ static int get_free_port(struct domain *d)
=20
 static long evtchn_alloc_unbound(evtchn_alloc_unbound_t *alloc)
 {
-    struct evtchn *chn;
     struct domain *d;
-    int            port;
-    domid_t        dom =3D alloc->dom;
     long           rc;
=20
-    rc =3D rcu_lock_target_domain_by_id(dom, &d);
+    rc =3D rcu_lock_target_domain_by_id(alloc->dom, &d);
     if ( rc )
         return rc;
=20
+    rc =3D evtchn_alloc_unbound_domain(d, &alloc->port, alloc->remote_do=
m);
+    if ( rc )
+        ERROR_EXIT_DOM((int)rc, d);
+
+ out:
+    rcu_unlock_domain(d);
+
+    return rc;
+}
+
+int evtchn_alloc_unbound_domain(struct domain *d, evtchn_port_t *port,
+                                domid_t remote_domid)
+{
+    struct evtchn *chn;
+    int           rc;
+    int           free_port;
+
     spin_lock(&d->event_lock);
=20
-    if ( (port =3D get_free_port(d)) < 0 )
-        ERROR_EXIT_DOM(port, d);
-    chn =3D evtchn_from_port(d, port);
+    rc =3D free_port =3D get_free_port(d);
+    if ( free_port < 0 )
+        goto out;
=20
-    rc =3D xsm_evtchn_unbound(d, chn, alloc->remote_dom);
+    chn =3D evtchn_from_port(d, free_port);
+    rc =3D xsm_evtchn_unbound(d, chn, remote_domid);
     if ( rc )
         goto out;
=20
     chn->state =3D ECS_UNBOUND;
-    if ( (chn->u.unbound.remote_domid =3D alloc->remote_dom) =3D=3D DOMI=
D_SELF )
+    if ( (chn->u.unbound.remote_domid =3D remote_domid) =3D=3D DOMID_SEL=
F )
         chn->u.unbound.remote_domid =3D current->domain->domain_id;
=20
-    alloc->port =3D port;
+    *port =3D free_port;
+    /* Everything is fine, returns 0 */
+    rc =3D 0;
=20
  out:
     spin_unlock(&d->event_lock);
-    rcu_unlock_domain(d);
-
     return rc;
 }
=20
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 71c3e92..1a0c832 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -69,6 +69,9 @@ int guest_enabled_event(struct vcpu *v, uint32_t virq);
 /* Notify remote end of a Xen-attached event channel.*/
 void notify_via_xen_event_channel(struct domain *ld, int lport);
=20
+int evtchn_alloc_unbound_domain(struct domain *d, evtchn_port_t *port,
+                                domid_t remote_domid);
+
 /* Internal event channel object accessors */
 #define bucket_from_port(d,p) \
     ((d)->evtchn[(p)/EVTCHNS_PER_BUCKET])

--------------true
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------true--


From xen-devel-bounces@lists.xen.org Thu Oct 25 11:49:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 11:49:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRLvv-0008UM-Fo; Thu, 25 Oct 2012 11:49:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRLvt-0008Tm-Vk
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 11:49:06 +0000
Received: from [85.158.139.211:30012] by server-13.bemta-5.messagelabs.com id
	14/CF-27809-13729805; Thu, 25 Oct 2012 11:49:05 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1351165743!23220136!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6273 invoked from network); 25 Oct 2012 11:49:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 11:49:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,646,1344211200"; d="scan'208";a="15386526"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 11:49:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 12:49:01 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53] helo=spongy)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TRLvo-0003zo-Vf;
	Thu, 25 Oct 2012 11:49:01 +0000
Received: by spongy (Postfix, from userid 2023)	id 08023340D87; Thu, 25 Oct
	2012 12:52:09 +0100 (BST)
From: Jean Guyader 
To: 
Date: Thu, 25 Oct 2012 12:52:05 +0100
Message-ID: <1351165926-23259-3-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1351165926-23259-1-git-send-email-jean.guyader@citrix.com>
References: <1351165926-23259-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: tim@xen.org, Jean Guyader , JBeulich@suse.com
Subject: [Xen-devel] [PATCH 2/3] xen: events,
	exposes evtchn_alloc_unbound_domain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: quoted-printable


Exposes evtchn_alloc_unbound_domain to the rest of
Xen so we can create allocated unbound evtchn within Xen.

Signed-off-by: Jean Guyader 
---
 xen/common/event_channel.c |   39 +++++++++++++++++++++++++++-----------=
-
 xen/include/xen/event.h    |    3 +++
 2 files changed, 30 insertions(+), 12 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0002-xen-events-exposes-evtchn_alloc_unbound_domain.patch"
Content-Disposition: attachment;
	filename="0002-xen-events-exposes-evtchn_alloc_unbound_domain.patch"
Content-Transfer-Encoding: quoted-printable

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index a80a0d1..a868b89 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -159,36 +159,51 @@ static int get_free_port(struct domain *d)
=20
 static long evtchn_alloc_unbound(evtchn_alloc_unbound_t *alloc)
 {
-    struct evtchn *chn;
     struct domain *d;
-    int            port;
-    domid_t        dom =3D alloc->dom;
     long           rc;
=20
-    rc =3D rcu_lock_target_domain_by_id(dom, &d);
+    rc =3D rcu_lock_target_domain_by_id(alloc->dom, &d);
     if ( rc )
         return rc;
=20
+    rc =3D evtchn_alloc_unbound_domain(d, &alloc->port, alloc->remote_do=
m);
+    if ( rc )
+        ERROR_EXIT_DOM((int)rc, d);
+
+ out:
+    rcu_unlock_domain(d);
+
+    return rc;
+}
+
+int evtchn_alloc_unbound_domain(struct domain *d, evtchn_port_t *port,
+                                domid_t remote_domid)
+{
+    struct evtchn *chn;
+    int           rc;
+    int           free_port;
+
     spin_lock(&d->event_lock);
=20
-    if ( (port =3D get_free_port(d)) < 0 )
-        ERROR_EXIT_DOM(port, d);
-    chn =3D evtchn_from_port(d, port);
+    rc =3D free_port =3D get_free_port(d);
+    if ( free_port < 0 )
+        goto out;
=20
-    rc =3D xsm_evtchn_unbound(d, chn, alloc->remote_dom);
+    chn =3D evtchn_from_port(d, free_port);
+    rc =3D xsm_evtchn_unbound(d, chn, remote_domid);
     if ( rc )
         goto out;
=20
     chn->state =3D ECS_UNBOUND;
-    if ( (chn->u.unbound.remote_domid =3D alloc->remote_dom) =3D=3D DOMI=
D_SELF )
+    if ( (chn->u.unbound.remote_domid =3D remote_domid) =3D=3D DOMID_SEL=
F )
         chn->u.unbound.remote_domid =3D current->domain->domain_id;
=20
-    alloc->port =3D port;
+    *port =3D free_port;
+    /* Everything is fine, returns 0 */
+    rc =3D 0;
=20
  out:
     spin_unlock(&d->event_lock);
-    rcu_unlock_domain(d);
-
     return rc;
 }
=20
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 71c3e92..1a0c832 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -69,6 +69,9 @@ int guest_enabled_event(struct vcpu *v, uint32_t virq);
 /* Notify remote end of a Xen-attached event channel.*/
 void notify_via_xen_event_channel(struct domain *ld, int lport);
=20
+int evtchn_alloc_unbound_domain(struct domain *d, evtchn_port_t *port,
+                                domid_t remote_domid);
+
 /* Internal event channel object accessors */
 #define bucket_from_port(d,p) \
     ((d)->evtchn[(p)/EVTCHNS_PER_BUCKET])

--------------true
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------true--


From xen-devel-bounces@lists.xen.org Thu Oct 25 11:52:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 11:52:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRLzB-0000am-Qa; Thu, 25 Oct 2012 11:52:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRLzA-0000aa-8O
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 11:52:28 +0000
Received: from [85.158.139.83:64955] by server-13.bemta-5.messagelabs.com id
	31/B7-27809-BF729805; Thu, 25 Oct 2012 11:52:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1351165920!36733910!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14994 invoked from network); 25 Oct 2012 11:52:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-182.messagelabs.com with SMTP;
	25 Oct 2012 11:52:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 25 Oct 2012 12:52:16 +0100
Message-Id: <508943FF02000078000A46FE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 25 Oct 2012 12:51:59 +0100
From: "Jan Beulich" 
To: "xen-devel" 
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part59688DCF.0__="
Subject: [Xen-devel] [PATCH] compiler.h adjustments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part59688DCF.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

- replace __attribute_used__ with just __used
- add __maybe_unused and explain the difference between the two
- remove gcc 3.x specifics (as we don't support building with it
  anymore; really for quite some time we didn't even support building
  with the checked for minor versions)
- remove left over __setup() from init.h (rather than adjusting it)

Signed-off-by: Jan Beulich 

--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -41,7 +41,7 @@
 #include 
 #include "gic.h"
=20
-static __attribute_used__ void init_done(void)
+static __used void init_done(void)
 {
     free_init_memory();
     startup_cpu_idle_loop();
--- a/xen/include/xen/compiler.h
+++ b/xen/include/xen/compiler.h
@@ -1,7 +1,7 @@
 #ifndef __LINUX_COMPILER_H
 #define __LINUX_COMPILER_H
=20
-#if !defined(__GNUC__) || (__GNUC__ < 3)
+#if !defined(__GNUC__) || (__GNUC__ < 4)
 #error Sorry, your compiler is too old/not recognized.
 #endif
=20
@@ -17,11 +17,11 @@
 #ifdef __clang__
 /* Clang can replace some vars with new automatic ones that go in .data;
  * mark all explicit-segment vars 'used' to prevent that. */
-#define __section(s)      __attribute_used__ __attribute__((__section__(s)=
))
+#define __section(s)      __used __attribute__((__section__(s)))
 #else
 #define __section(s)      __attribute__((__section__(s)))
 #endif
-#define __used_section(s) __attribute_used__ __attribute__((__section__(s)=
))
+#define __used_section(s) __used __attribute__((__section__(s)))
 #define __text_section(s) __attribute__((__section__(s)))
=20
 #ifdef INIT_SECTIONS_ONLY
@@ -36,23 +36,23 @@
 #define __attribute_pure__  __attribute__((pure))
 #define __attribute_const__ __attribute__((__const__))
=20
-#if __GNUC__ > 3 || (__GNUC__ =3D=3D 3 && __GNUC_MINOR__ >=3D 3)
-#define __attribute_used__ __attribute__((__used__))
-#else
-#define __attribute_used__ __attribute__((__unused__))
-#endif
+/*
+ * The difference between the following two attributes is that __used is
+ * intended to be used in cases where a reference to an identifier may be
+ * invisible to the compiler (e.g. an inline assembly operand not listed
+ * in the asm()'s operands), preventing the compiler from eliminating the
+ * variable or function.
+ * __maybe_unused otoh is to be used to merely prevent warnings (e.g. =
when
+ * an identifier is used only inside a preprocessor conditional, yet =
putting
+ * its declaration/definition inside another conditional would harm code
+ * readability).
+ */
+#define __used         __attribute__((__used__))
+#define __maybe_unused __attribute__((__unused__))
=20
-#if __GNUC__ > 3 || (__GNUC__ =3D=3D 3 && __GNUC_MINOR__ >=3D 4)
 #define __must_check __attribute__((warn_unused_result))
-#else
-#define __must_check
-#endif
=20
-#if __GNUC__ > 3
 #define offsetof(a,b) __builtin_offsetof(a,b)
-#else
-#define offsetof(a,b) ((unsigned long)&(((a *)0)->b))
-#endif
=20
 /* &a[0] degrades to a pointer: a different type from an array */
 #define __must_be_array(a) \
--- a/xen/include/xen/init.h
+++ b/xen/include/xen/init.h
@@ -114,9 +114,6 @@ extern struct kernel_param __setup_start
     __kparam __setup_##_var =3D \
         { __setup_str_##_var, OPT_STR, &_var, sizeof(_var) }
=20
-/* Make sure obsolete cmdline params don't break the build. */
-#define __setup(_name, _fn) static void * __attribute_used__ _dummy_##_fn =
=3D _fn
-   =20
 #endif /* __ASSEMBLY__ */
=20
 #ifdef CONFIG_HOTPLUG




--=__Part59688DCF.0__=
Content-Type: text/plain; name="attrib-used-unused.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="attrib-used-unused.patch"

compiler.h adjustments=0A=0A- replace __attribute_used__ with just =
__used=0A- add __maybe_unused and explain the difference between the =
two=0A- remove gcc 3.x specifics (as we don't support building with it=0A  =
anymore; really for quite some time we didn't even support building=0A  =
with the checked for minor versions)=0A- remove left over __setup() from =
init.h (rather than adjusting it)=0A=0ASigned-off-by: Jan Beulich =
=0A=0A--- a/xen/arch/arm/setup.c=0A+++ b/xen/arch/arm/se=
tup.c=0A@@ -41,7 +41,7 @@=0A #include =0A #include =
"gic.h"=0A =0A-static __attribute_used__ void init_done(void)=0A+static =
__used void init_done(void)=0A {=0A     free_init_memory();=0A     =
startup_cpu_idle_loop();=0A--- a/xen/include/xen/compiler.h=0A+++ =
b/xen/include/xen/compiler.h=0A@@ -1,7 +1,7 @@=0A #ifndef __LINUX_COMPILER_=
H=0A #define __LINUX_COMPILER_H=0A =0A-#if !defined(__GNUC__) || (__GNUC__ =
< 3)=0A+#if !defined(__GNUC__) || (__GNUC__ < 4)=0A #error Sorry, your =
compiler is too old/not recognized.=0A #endif=0A =0A@@ -17,11 +17,11 @@=0A =
#ifdef __clang__=0A /* Clang can replace some vars with new automatic ones =
that go in .data;=0A  * mark all explicit-segment vars 'used' to prevent =
that. */=0A-#define __section(s)      __attribute_used__ __attribute__((__s=
ection__(s)))=0A+#define __section(s)      __used __attribute__((__section_=
_(s)))=0A #else=0A #define __section(s)      __attribute__((__section__(s))=
)=0A #endif=0A-#define __used_section(s) __attribute_used__ __attribute__((=
__section__(s)))=0A+#define __used_section(s) __used __attribute__((__secti=
on__(s)))=0A #define __text_section(s) __attribute__((__section__(s)))=0A =
=0A #ifdef INIT_SECTIONS_ONLY=0A@@ -36,23 +36,23 @@=0A #define __attribute_=
pure__  __attribute__((pure))=0A #define __attribute_const__ __attribute__(=
(__const__))=0A =0A-#if __GNUC__ > 3 || (__GNUC__ =3D=3D 3 && __GNUC_MINOR_=
_ >=3D 3)=0A-#define __attribute_used__ __attribute__((__used__))=0A-#else=
=0A-#define __attribute_used__ __attribute__((__unused__))=0A-#endif=0A+/*=
=0A+ * The difference between the following two attributes is that __used =
is=0A+ * intended to be used in cases where a reference to an identifier =
may be=0A+ * invisible to the compiler (e.g. an inline assembly operand =
not listed=0A+ * in the asm()'s operands), preventing the compiler from =
eliminating the=0A+ * variable or function.=0A+ * __maybe_unused otoh is =
to be used to merely prevent warnings (e.g. when=0A+ * an identifier is =
used only inside a preprocessor conditional, yet putting=0A+ * its =
declaration/definition inside another conditional would harm code=0A+ * =
readability).=0A+ */=0A+#define __used         __attribute__((__used__))=0A=
+#define __maybe_unused __attribute__((__unused__))=0A =0A-#if __GNUC__ > =
3 || (__GNUC__ =3D=3D 3 && __GNUC_MINOR__ >=3D 4)=0A #define __must_check =
__attribute__((warn_unused_result))=0A-#else=0A-#define __must_check=0A-#en=
dif=0A =0A-#if __GNUC__ > 3=0A #define offsetof(a,b) __builtin_offsetof(a,b=
)=0A-#else=0A-#define offsetof(a,b) ((unsigned long)&(((a *)0)->b))=0A-#end=
if=0A =0A /* &a[0] degrades to a pointer: a different type from an array =
*/=0A #define __must_be_array(a) \=0A--- a/xen/include/xen/init.h=0A+++ =
b/xen/include/xen/init.h=0A@@ -114,9 +114,6 @@ extern struct kernel_param =
__setup_start=0A     __kparam __setup_##_var =3D \=0A         { __setup_str=
_##_var, OPT_STR, &_var, sizeof(_var) }=0A =0A-/* Make sure obsolete =
cmdline params don't break the build. */=0A-#define __setup(_name, _fn) =
static void * __attribute_used__ _dummy_##_fn =3D _fn=0A-    =0A #endif /* =
__ASSEMBLY__ */=0A =0A #ifdef CONFIG_HOTPLUG=0A
--=__Part59688DCF.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__Part59688DCF.0__=--


From xen-devel-bounces@lists.xen.org Thu Oct 25 11:52:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 11:52:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRLzB-0000am-Qa; Thu, 25 Oct 2012 11:52:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRLzA-0000aa-8O
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 11:52:28 +0000
Received: from [85.158.139.83:64955] by server-13.bemta-5.messagelabs.com id
	31/B7-27809-BF729805; Thu, 25 Oct 2012 11:52:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1351165920!36733910!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14994 invoked from network); 25 Oct 2012 11:52:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-182.messagelabs.com with SMTP;
	25 Oct 2012 11:52:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 25 Oct 2012 12:52:16 +0100
Message-Id: <508943FF02000078000A46FE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 25 Oct 2012 12:51:59 +0100
From: "Jan Beulich" 
To: "xen-devel" 
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part59688DCF.0__="
Subject: [Xen-devel] [PATCH] compiler.h adjustments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part59688DCF.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

- replace __attribute_used__ with just __used
- add __maybe_unused and explain the difference between the two
- remove gcc 3.x specifics (as we don't support building with it
  anymore; really for quite some time we didn't even support building
  with the checked for minor versions)
- remove left over __setup() from init.h (rather than adjusting it)

Signed-off-by: Jan Beulich 

--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -41,7 +41,7 @@
 #include 
 #include "gic.h"
=20
-static __attribute_used__ void init_done(void)
+static __used void init_done(void)
 {
     free_init_memory();
     startup_cpu_idle_loop();
--- a/xen/include/xen/compiler.h
+++ b/xen/include/xen/compiler.h
@@ -1,7 +1,7 @@
 #ifndef __LINUX_COMPILER_H
 #define __LINUX_COMPILER_H
=20
-#if !defined(__GNUC__) || (__GNUC__ < 3)
+#if !defined(__GNUC__) || (__GNUC__ < 4)
 #error Sorry, your compiler is too old/not recognized.
 #endif
=20
@@ -17,11 +17,11 @@
 #ifdef __clang__
 /* Clang can replace some vars with new automatic ones that go in .data;
  * mark all explicit-segment vars 'used' to prevent that. */
-#define __section(s)      __attribute_used__ __attribute__((__section__(s)=
))
+#define __section(s)      __used __attribute__((__section__(s)))
 #else
 #define __section(s)      __attribute__((__section__(s)))
 #endif
-#define __used_section(s) __attribute_used__ __attribute__((__section__(s)=
))
+#define __used_section(s) __used __attribute__((__section__(s)))
 #define __text_section(s) __attribute__((__section__(s)))
=20
 #ifdef INIT_SECTIONS_ONLY
@@ -36,23 +36,23 @@
 #define __attribute_pure__  __attribute__((pure))
 #define __attribute_const__ __attribute__((__const__))
=20
-#if __GNUC__ > 3 || (__GNUC__ =3D=3D 3 && __GNUC_MINOR__ >=3D 3)
-#define __attribute_used__ __attribute__((__used__))
-#else
-#define __attribute_used__ __attribute__((__unused__))
-#endif
+/*
+ * The difference between the following two attributes is that __used is
+ * intended to be used in cases where a reference to an identifier may be
+ * invisible to the compiler (e.g. an inline assembly operand not listed
+ * in the asm()'s operands), preventing the compiler from eliminating the
+ * variable or function.
+ * __maybe_unused otoh is to be used to merely prevent warnings (e.g. =
when
+ * an identifier is used only inside a preprocessor conditional, yet =
putting
+ * its declaration/definition inside another conditional would harm code
+ * readability).
+ */
+#define __used         __attribute__((__used__))
+#define __maybe_unused __attribute__((__unused__))
=20
-#if __GNUC__ > 3 || (__GNUC__ =3D=3D 3 && __GNUC_MINOR__ >=3D 4)
 #define __must_check __attribute__((warn_unused_result))
-#else
-#define __must_check
-#endif
=20
-#if __GNUC__ > 3
 #define offsetof(a,b) __builtin_offsetof(a,b)
-#else
-#define offsetof(a,b) ((unsigned long)&(((a *)0)->b))
-#endif
=20
 /* &a[0] degrades to a pointer: a different type from an array */
 #define __must_be_array(a) \
--- a/xen/include/xen/init.h
+++ b/xen/include/xen/init.h
@@ -114,9 +114,6 @@ extern struct kernel_param __setup_start
     __kparam __setup_##_var =3D \
         { __setup_str_##_var, OPT_STR, &_var, sizeof(_var) }
=20
-/* Make sure obsolete cmdline params don't break the build. */
-#define __setup(_name, _fn) static void * __attribute_used__ _dummy_##_fn =
=3D _fn
-   =20
 #endif /* __ASSEMBLY__ */
=20
 #ifdef CONFIG_HOTPLUG




--=__Part59688DCF.0__=
Content-Type: text/plain; name="attrib-used-unused.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="attrib-used-unused.patch"

compiler.h adjustments=0A=0A- replace __attribute_used__ with just =
__used=0A- add __maybe_unused and explain the difference between the =
two=0A- remove gcc 3.x specifics (as we don't support building with it=0A  =
anymore; really for quite some time we didn't even support building=0A  =
with the checked for minor versions)=0A- remove left over __setup() from =
init.h (rather than adjusting it)=0A=0ASigned-off-by: Jan Beulich =
=0A=0A--- a/xen/arch/arm/setup.c=0A+++ b/xen/arch/arm/se=
tup.c=0A@@ -41,7 +41,7 @@=0A #include =0A #include =
"gic.h"=0A =0A-static __attribute_used__ void init_done(void)=0A+static =
__used void init_done(void)=0A {=0A     free_init_memory();=0A     =
startup_cpu_idle_loop();=0A--- a/xen/include/xen/compiler.h=0A+++ =
b/xen/include/xen/compiler.h=0A@@ -1,7 +1,7 @@=0A #ifndef __LINUX_COMPILER_=
H=0A #define __LINUX_COMPILER_H=0A =0A-#if !defined(__GNUC__) || (__GNUC__ =
< 3)=0A+#if !defined(__GNUC__) || (__GNUC__ < 4)=0A #error Sorry, your =
compiler is too old/not recognized.=0A #endif=0A =0A@@ -17,11 +17,11 @@=0A =
#ifdef __clang__=0A /* Clang can replace some vars with new automatic ones =
that go in .data;=0A  * mark all explicit-segment vars 'used' to prevent =
that. */=0A-#define __section(s)      __attribute_used__ __attribute__((__s=
ection__(s)))=0A+#define __section(s)      __used __attribute__((__section_=
_(s)))=0A #else=0A #define __section(s)      __attribute__((__section__(s))=
)=0A #endif=0A-#define __used_section(s) __attribute_used__ __attribute__((=
__section__(s)))=0A+#define __used_section(s) __used __attribute__((__secti=
on__(s)))=0A #define __text_section(s) __attribute__((__section__(s)))=0A =
=0A #ifdef INIT_SECTIONS_ONLY=0A@@ -36,23 +36,23 @@=0A #define __attribute_=
pure__  __attribute__((pure))=0A #define __attribute_const__ __attribute__(=
(__const__))=0A =0A-#if __GNUC__ > 3 || (__GNUC__ =3D=3D 3 && __GNUC_MINOR_=
_ >=3D 3)=0A-#define __attribute_used__ __attribute__((__used__))=0A-#else=
=0A-#define __attribute_used__ __attribute__((__unused__))=0A-#endif=0A+/*=
=0A+ * The difference between the following two attributes is that __used =
is=0A+ * intended to be used in cases where a reference to an identifier =
may be=0A+ * invisible to the compiler (e.g. an inline assembly operand =
not listed=0A+ * in the asm()'s operands), preventing the compiler from =
eliminating the=0A+ * variable or function.=0A+ * __maybe_unused otoh is =
to be used to merely prevent warnings (e.g. when=0A+ * an identifier is =
used only inside a preprocessor conditional, yet putting=0A+ * its =
declaration/definition inside another conditional would harm code=0A+ * =
readability).=0A+ */=0A+#define __used         __attribute__((__used__))=0A=
+#define __maybe_unused __attribute__((__unused__))=0A =0A-#if __GNUC__ > =
3 || (__GNUC__ =3D=3D 3 && __GNUC_MINOR__ >=3D 4)=0A #define __must_check =
__attribute__((warn_unused_result))=0A-#else=0A-#define __must_check=0A-#en=
dif=0A =0A-#if __GNUC__ > 3=0A #define offsetof(a,b) __builtin_offsetof(a,b=
)=0A-#else=0A-#define offsetof(a,b) ((unsigned long)&(((a *)0)->b))=0A-#end=
if=0A =0A /* &a[0] degrades to a pointer: a different type from an array =
*/=0A #define __must_be_array(a) \=0A--- a/xen/include/xen/init.h=0A+++ =
b/xen/include/xen/init.h=0A@@ -114,9 +114,6 @@ extern struct kernel_param =
__setup_start=0A     __kparam __setup_##_var =3D \=0A         { __setup_str=
_##_var, OPT_STR, &_var, sizeof(_var) }=0A =0A-/* Make sure obsolete =
cmdline params don't break the build. */=0A-#define __setup(_name, _fn) =
static void * __attribute_used__ _dummy_##_fn =3D _fn=0A-    =0A #endif /* =
__ASSEMBLY__ */=0A =0A #ifdef CONFIG_HOTPLUG=0A
--=__Part59688DCF.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__Part59688DCF.0__=--


From xen-devel-bounces@lists.xen.org Thu Oct 25 11:53:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 11:53:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRLzp-0000fn-7v; Thu, 25 Oct 2012 11:53:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRLzo-0000fO-3T
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 11:53:08 +0000
Received: from [85.158.139.83:2522] by server-12.bemta-5.messagelabs.com id
	E5/4C-26919-32829805; Thu, 25 Oct 2012 11:53:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1351165986!30834138!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9143 invoked from network); 25 Oct 2012 11:53:06 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-182.messagelabs.com with SMTP;
	25 Oct 2012 11:53:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 25 Oct 2012 12:53:23 +0100
Message-Id: <5089444102000078000A4702@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 25 Oct 2012 12:53:05 +0100
From: "Jan Beulich" 
To: "Keir Fraser" 
References: <5081241402000078000A2837@nat28.tlf.novell.com>
	
In-Reply-To: 
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartA8997C31.0__="
Cc: xen-devel 
Subject: [Xen-devel] [PATCH v2] x86/HPET: cache MSI message last written
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartA8997C31.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Rather than spending measurable amounts of time reading back the most
recently written message, cache it in space previously unused, and thus
accelerate the CPU's entering of the intended C-state.

hpet_msi_read() ends up being unused after this change, but rather than
removing the function, it's being marked "unused" in order - that way
it can easily get used again should a new need for it arise.

Signed-off-by: Jan Beulich 
---
v2: Re-based on top of the previously sent patch "compiler.h
    adjustments".

--- a/xen/arch/x86/hpet.c
+++ b/xen/arch/x86/hpet.c
@@ -253,17 +253,19 @@ static void hpet_msi_mask(struct irq_des
=20
 static void hpet_msi_write(struct hpet_event_channel *ch, struct msi_msg =
*msg)
 {
+    ch->msi.msg =3D *msg;
     if ( iommu_intremap )
         iommu_update_ire_from_msi(&ch->msi, msg);
     hpet_write32(msg->data, HPET_Tn_ROUTE(ch->idx));
     hpet_write32(msg->address_lo, HPET_Tn_ROUTE(ch->idx) + 4);
 }
=20
-static void hpet_msi_read(struct hpet_event_channel *ch, struct msi_msg =
*msg)
+static void __maybe_unused
+hpet_msi_read(struct hpet_event_channel *ch, struct msi_msg *msg)
 {
     msg->data =3D hpet_read32(HPET_Tn_ROUTE(ch->idx));
     msg->address_lo =3D hpet_read32(HPET_Tn_ROUTE(ch->idx) + 4);
-    msg->address_hi =3D 0;
+    msg->address_hi =3D MSI_ADDR_BASE_HI;
     if ( iommu_intremap )
         iommu_read_msi_from_ire(&ch->msi, msg);
 }
@@ -285,20 +287,19 @@ static void hpet_msi_ack(struct irq_desc
=20
 static void hpet_msi_set_affinity(struct irq_desc *desc, const cpumask_t =
*mask)
 {
-    struct msi_msg msg;
-    unsigned int dest;
+    struct hpet_event_channel *ch =3D desc->action->dev_id;
+    struct msi_msg msg =3D ch->msi.msg;
=20
-    dest =3D set_desc_affinity(desc, mask);
-    if (dest =3D=3D BAD_APICID)
+    msg.dest32 =3D set_desc_affinity(desc, mask);
+    if ( msg.dest32 =3D=3D BAD_APICID )
         return;
=20
-    hpet_msi_read(desc->action->dev_id, &msg);
     msg.data &=3D ~MSI_DATA_VECTOR_MASK;
     msg.data |=3D MSI_DATA_VECTOR(desc->arch.vector);
     msg.address_lo &=3D ~MSI_ADDR_DEST_ID_MASK;
-    msg.address_lo |=3D MSI_ADDR_DEST_ID(dest);
-    msg.dest32 =3D dest;
-    hpet_msi_write(desc->action->dev_id, &msg);
+    msg.address_lo |=3D MSI_ADDR_DEST_ID(msg.dest32);
+    if ( msg.data !=3D ch->msi.msg.data || msg.dest32 !=3D ch->msi.msg.des=
t32 )
+        hpet_msi_write(ch, &msg);
 }
=20
 /*




--=__PartA8997C31.0__=
Content-Type: text/plain; name="x86-HPET-msg-cache.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-HPET-msg-cache.patch"

x86/HPET: cache MSI message last written=0A=0ARather than spending =
measurable amounts of time reading back the most=0Arecently written =
message, cache it in space previously unused, and thus=0Aaccelerate the =
CPU's entering of the intended C-state.=0A=0Ahpet_msi_read() ends up being =
unused after this change, but rather than=0Aremoving the function, it's =
being marked "unused" in order - that way=0Ait can easily get used again =
should a new need for it arise.=0A=0ASigned-off-by: Jan Beulich =0A---=0Av2: Re-based on top of the previously sent patch =
"compiler.h=0A    adjustments".=0A=0A--- a/xen/arch/x86/hpet.c=0A+++ =
b/xen/arch/x86/hpet.c=0A@@ -253,17 +253,19 @@ static void hpet_msi_mask(str=
uct irq_des=0A =0A static void hpet_msi_write(struct hpet_event_channel =
*ch, struct msi_msg *msg)=0A {=0A+    ch->msi.msg =3D *msg;=0A     if ( =
iommu_intremap )=0A         iommu_update_ire_from_msi(&ch->msi, msg);=0A   =
  hpet_write32(msg->data, HPET_Tn_ROUTE(ch->idx));=0A     hpet_write32(msg-=
>address_lo, HPET_Tn_ROUTE(ch->idx) + 4);=0A }=0A =0A-static void =
hpet_msi_read(struct hpet_event_channel *ch, struct msi_msg *msg)=0A+static=
 void __maybe_unused=0A+hpet_msi_read(struct hpet_event_channel *ch, =
struct msi_msg *msg)=0A {=0A     msg->data =3D hpet_read32(HPET_Tn_ROUTE(ch=
->idx));=0A     msg->address_lo =3D hpet_read32(HPET_Tn_ROUTE(ch->idx) + =
4);=0A-    msg->address_hi =3D 0;=0A+    msg->address_hi =3D MSI_ADDR_BASE_=
HI;=0A     if ( iommu_intremap )=0A         iommu_read_msi_from_ire(&ch->ms=
i, msg);=0A }=0A@@ -285,20 +287,19 @@ static void hpet_msi_ack(struct =
irq_desc=0A =0A static void hpet_msi_set_affinity(struct irq_desc *desc, =
const cpumask_t *mask)=0A {=0A-    struct msi_msg msg;=0A-    unsigned int =
dest;=0A+    struct hpet_event_channel *ch =3D desc->action->dev_id;=0A+   =
 struct msi_msg msg =3D ch->msi.msg;=0A =0A-    dest =3D set_desc_affinity(=
desc, mask);=0A-    if (dest =3D=3D BAD_APICID)=0A+    msg.dest32 =3D =
set_desc_affinity(desc, mask);=0A+    if ( msg.dest32 =3D=3D BAD_APICID =
)=0A         return;=0A =0A-    hpet_msi_read(desc->action->dev_id, =
&msg);=0A     msg.data &=3D ~MSI_DATA_VECTOR_MASK;=0A     msg.data |=3D =
MSI_DATA_VECTOR(desc->arch.vector);=0A     msg.address_lo &=3D ~MSI_ADDR_DE=
ST_ID_MASK;=0A-    msg.address_lo |=3D MSI_ADDR_DEST_ID(dest);=0A-    =
msg.dest32 =3D dest;=0A-    hpet_msi_write(desc->action->dev_id, &msg);=0A+=
    msg.address_lo |=3D MSI_ADDR_DEST_ID(msg.dest32);=0A+    if ( msg.data =
!=3D ch->msi.msg.data || msg.dest32 !=3D ch->msi.msg.dest32 )=0A+        =
hpet_msi_write(ch, &msg);=0A }=0A =0A /*=0A
--=__PartA8997C31.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__PartA8997C31.0__=--


From xen-devel-bounces@lists.xen.org Thu Oct 25 11:53:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 11:53:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRLzp-0000fn-7v; Thu, 25 Oct 2012 11:53:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRLzo-0000fO-3T
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 11:53:08 +0000
Received: from [85.158.139.83:2522] by server-12.bemta-5.messagelabs.com id
	E5/4C-26919-32829805; Thu, 25 Oct 2012 11:53:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1351165986!30834138!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9143 invoked from network); 25 Oct 2012 11:53:06 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-182.messagelabs.com with SMTP;
	25 Oct 2012 11:53:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 25 Oct 2012 12:53:23 +0100
Message-Id: <5089444102000078000A4702@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 25 Oct 2012 12:53:05 +0100
From: "Jan Beulich" 
To: "Keir Fraser" 
References: <5081241402000078000A2837@nat28.tlf.novell.com>
	
In-Reply-To: 
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartA8997C31.0__="
Cc: xen-devel 
Subject: [Xen-devel] [PATCH v2] x86/HPET: cache MSI message last written
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartA8997C31.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Rather than spending measurable amounts of time reading back the most
recently written message, cache it in space previously unused, and thus
accelerate the CPU's entering of the intended C-state.

hpet_msi_read() ends up being unused after this change, but rather than
removing the function, it's being marked "unused" in order - that way
it can easily get used again should a new need for it arise.

Signed-off-by: Jan Beulich 
---
v2: Re-based on top of the previously sent patch "compiler.h
    adjustments".

--- a/xen/arch/x86/hpet.c
+++ b/xen/arch/x86/hpet.c
@@ -253,17 +253,19 @@ static void hpet_msi_mask(struct irq_des
=20
 static void hpet_msi_write(struct hpet_event_channel *ch, struct msi_msg =
*msg)
 {
+    ch->msi.msg =3D *msg;
     if ( iommu_intremap )
         iommu_update_ire_from_msi(&ch->msi, msg);
     hpet_write32(msg->data, HPET_Tn_ROUTE(ch->idx));
     hpet_write32(msg->address_lo, HPET_Tn_ROUTE(ch->idx) + 4);
 }
=20
-static void hpet_msi_read(struct hpet_event_channel *ch, struct msi_msg =
*msg)
+static void __maybe_unused
+hpet_msi_read(struct hpet_event_channel *ch, struct msi_msg *msg)
 {
     msg->data =3D hpet_read32(HPET_Tn_ROUTE(ch->idx));
     msg->address_lo =3D hpet_read32(HPET_Tn_ROUTE(ch->idx) + 4);
-    msg->address_hi =3D 0;
+    msg->address_hi =3D MSI_ADDR_BASE_HI;
     if ( iommu_intremap )
         iommu_read_msi_from_ire(&ch->msi, msg);
 }
@@ -285,20 +287,19 @@ static void hpet_msi_ack(struct irq_desc
=20
 static void hpet_msi_set_affinity(struct irq_desc *desc, const cpumask_t =
*mask)
 {
-    struct msi_msg msg;
-    unsigned int dest;
+    struct hpet_event_channel *ch =3D desc->action->dev_id;
+    struct msi_msg msg =3D ch->msi.msg;
=20
-    dest =3D set_desc_affinity(desc, mask);
-    if (dest =3D=3D BAD_APICID)
+    msg.dest32 =3D set_desc_affinity(desc, mask);
+    if ( msg.dest32 =3D=3D BAD_APICID )
         return;
=20
-    hpet_msi_read(desc->action->dev_id, &msg);
     msg.data &=3D ~MSI_DATA_VECTOR_MASK;
     msg.data |=3D MSI_DATA_VECTOR(desc->arch.vector);
     msg.address_lo &=3D ~MSI_ADDR_DEST_ID_MASK;
-    msg.address_lo |=3D MSI_ADDR_DEST_ID(dest);
-    msg.dest32 =3D dest;
-    hpet_msi_write(desc->action->dev_id, &msg);
+    msg.address_lo |=3D MSI_ADDR_DEST_ID(msg.dest32);
+    if ( msg.data !=3D ch->msi.msg.data || msg.dest32 !=3D ch->msi.msg.des=
t32 )
+        hpet_msi_write(ch, &msg);
 }
=20
 /*




--=__PartA8997C31.0__=
Content-Type: text/plain; name="x86-HPET-msg-cache.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-HPET-msg-cache.patch"

x86/HPET: cache MSI message last written=0A=0ARather than spending =
measurable amounts of time reading back the most=0Arecently written =
message, cache it in space previously unused, and thus=0Aaccelerate the =
CPU's entering of the intended C-state.=0A=0Ahpet_msi_read() ends up being =
unused after this change, but rather than=0Aremoving the function, it's =
being marked "unused" in order - that way=0Ait can easily get used again =
should a new need for it arise.=0A=0ASigned-off-by: Jan Beulich =0A---=0Av2: Re-based on top of the previously sent patch =
"compiler.h=0A    adjustments".=0A=0A--- a/xen/arch/x86/hpet.c=0A+++ =
b/xen/arch/x86/hpet.c=0A@@ -253,17 +253,19 @@ static void hpet_msi_mask(str=
uct irq_des=0A =0A static void hpet_msi_write(struct hpet_event_channel =
*ch, struct msi_msg *msg)=0A {=0A+    ch->msi.msg =3D *msg;=0A     if ( =
iommu_intremap )=0A         iommu_update_ire_from_msi(&ch->msi, msg);=0A   =
  hpet_write32(msg->data, HPET_Tn_ROUTE(ch->idx));=0A     hpet_write32(msg-=
>address_lo, HPET_Tn_ROUTE(ch->idx) + 4);=0A }=0A =0A-static void =
hpet_msi_read(struct hpet_event_channel *ch, struct msi_msg *msg)=0A+static=
 void __maybe_unused=0A+hpet_msi_read(struct hpet_event_channel *ch, =
struct msi_msg *msg)=0A {=0A     msg->data =3D hpet_read32(HPET_Tn_ROUTE(ch=
->idx));=0A     msg->address_lo =3D hpet_read32(HPET_Tn_ROUTE(ch->idx) + =
4);=0A-    msg->address_hi =3D 0;=0A+    msg->address_hi =3D MSI_ADDR_BASE_=
HI;=0A     if ( iommu_intremap )=0A         iommu_read_msi_from_ire(&ch->ms=
i, msg);=0A }=0A@@ -285,20 +287,19 @@ static void hpet_msi_ack(struct =
irq_desc=0A =0A static void hpet_msi_set_affinity(struct irq_desc *desc, =
const cpumask_t *mask)=0A {=0A-    struct msi_msg msg;=0A-    unsigned int =
dest;=0A+    struct hpet_event_channel *ch =3D desc->action->dev_id;=0A+   =
 struct msi_msg msg =3D ch->msi.msg;=0A =0A-    dest =3D set_desc_affinity(=
desc, mask);=0A-    if (dest =3D=3D BAD_APICID)=0A+    msg.dest32 =3D =
set_desc_affinity(desc, mask);=0A+    if ( msg.dest32 =3D=3D BAD_APICID =
)=0A         return;=0A =0A-    hpet_msi_read(desc->action->dev_id, =
&msg);=0A     msg.data &=3D ~MSI_DATA_VECTOR_MASK;=0A     msg.data |=3D =
MSI_DATA_VECTOR(desc->arch.vector);=0A     msg.address_lo &=3D ~MSI_ADDR_DE=
ST_ID_MASK;=0A-    msg.address_lo |=3D MSI_ADDR_DEST_ID(dest);=0A-    =
msg.dest32 =3D dest;=0A-    hpet_msi_write(desc->action->dev_id, &msg);=0A+=
    msg.address_lo |=3D MSI_ADDR_DEST_ID(msg.dest32);=0A+    if ( msg.data =
!=3D ch->msi.msg.data || msg.dest32 !=3D ch->msi.msg.dest32 )=0A+        =
hpet_msi_write(ch, &msg);=0A }=0A =0A /*=0A
--=__PartA8997C31.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__PartA8997C31.0__=--


From xen-devel-bounces@lists.xen.org Thu Oct 25 11:54:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 11:54:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRM0t-0000on-Mt; Thu, 25 Oct 2012 11:54:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRM0s-0000og-74
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 11:54:14 +0000
Received: from [85.158.139.83:17948] by server-7.bemta-5.messagelabs.com id
	EC/EE-23102-56829805; Thu, 25 Oct 2012 11:54:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1351166052!29235866!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32372 invoked from network); 25 Oct 2012 11:54:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 11:54:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,646,1344211200"; d="scan'208";a="15386643"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 11:53:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 12:53:30 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TRM0A-00042m-PW; Thu, 25 Oct 2012 11:53:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TRM0A-0000mk-Lp;
	Thu, 25 Oct 2012 12:53:30 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20617.10298.494649.507500@mariner.uk.xensource.com>
Date: Thu, 25 Oct 2012 12:53:30 +0100
To: Ian Campbell , Christoph Egger
	
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <5087C813.8090609@amd.com>,
	<1351078090.18035.4.camel@zakaz.uk.xensource.com>
References: <5087B6A4.6030203@amd.com>
	<1351072711.2237.139.camel@zakaz.uk.xensource.com>
	<5087C813.8090609@amd.com>
	<5087EA1F02000078000A3EAE@nat28.tlf.novell.com>
	<1351078090.18035.4.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Jan Beulich ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] libxl: build error [and 1 more messages]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Christoph Egger writes ("Re: [Xen-devel] libxl: build error"):
> patch attached.

Thanks.  I have applied this.  NB in future it would be helpful for
you to supply a suitable commit message.  In this case I wrote one -
see below.

On Wed, 2012-10-24 at 12:16 +0100, Jan Beulich wrote:
> Afaict that's a mistake of whatever provides this header on your
> system - there's no unconditionally visible "reboot" in the specs
> I have available.

This is true, but I think it's a very forgiveable error and we might
well end up including various headers which import os-specific names.
So Christoph's patch is the right thing to do.

Ian.

# HG changeset patch
# User Christoph Egger 
# Date 1351165885 -3600
# Node ID 580aa3946f87eb56690671bf1aa0022228f59c8c
# Parent  22e08c9ac770db07c3c3e7c844aa7153050939f3
xl: avoid shadowing reboot(2)

On NetBSD  mistakenly exposes reboot(2).  Work around this.

Signed-off-by: Christoph Egger 
Signed-off-by: Ian Jackson 
Acked-by: Ian Jackson 
Committed-by: Ian Jackson 

diff -r 22e08c9ac770 -r 580aa3946f87 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Oct 24 17:51:48 2012 +0200
+++ b/tools/libxl/xl_cmdimpl.c	Thu Oct 25 12:51:25 2012 +0100
@@ -3721,11 +3721,11 @@ int main_destroy(int argc, char **argv)
     return 0;
 }
 
-static int main_shutdown_or_reboot(int reboot, int argc, char **argv)
+static int main_shutdown_or_reboot(int do_reboot, int argc, char **argv)
 {
     void (*fn)(uint32_t domid,
                libxl_evgen_domain_death **, libxl_ev_user, int) =
-        reboot ? &reboot_domain : &shutdown_domain;
+        do_reboot ? &reboot_domain : &shutdown_domain;
     int opt, i, nb_domain;
     int wait_for_it = 0, all =0;
     int fallback_trigger = 0;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 11:54:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 11:54:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRM0t-0000on-Mt; Thu, 25 Oct 2012 11:54:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRM0s-0000og-74
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 11:54:14 +0000
Received: from [85.158.139.83:17948] by server-7.bemta-5.messagelabs.com id
	EC/EE-23102-56829805; Thu, 25 Oct 2012 11:54:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1351166052!29235866!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32372 invoked from network); 25 Oct 2012 11:54:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 11:54:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,646,1344211200"; d="scan'208";a="15386643"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 11:53:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 12:53:30 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TRM0A-00042m-PW; Thu, 25 Oct 2012 11:53:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TRM0A-0000mk-Lp;
	Thu, 25 Oct 2012 12:53:30 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20617.10298.494649.507500@mariner.uk.xensource.com>
Date: Thu, 25 Oct 2012 12:53:30 +0100
To: Ian Campbell , Christoph Egger
	
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <5087C813.8090609@amd.com>,
	<1351078090.18035.4.camel@zakaz.uk.xensource.com>
References: <5087B6A4.6030203@amd.com>
	<1351072711.2237.139.camel@zakaz.uk.xensource.com>
	<5087C813.8090609@amd.com>
	<5087EA1F02000078000A3EAE@nat28.tlf.novell.com>
	<1351078090.18035.4.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Jan Beulich ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] libxl: build error [and 1 more messages]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Christoph Egger writes ("Re: [Xen-devel] libxl: build error"):
> patch attached.

Thanks.  I have applied this.  NB in future it would be helpful for
you to supply a suitable commit message.  In this case I wrote one -
see below.

On Wed, 2012-10-24 at 12:16 +0100, Jan Beulich wrote:
> Afaict that's a mistake of whatever provides this header on your
> system - there's no unconditionally visible "reboot" in the specs
> I have available.

This is true, but I think it's a very forgiveable error and we might
well end up including various headers which import os-specific names.
So Christoph's patch is the right thing to do.

Ian.

# HG changeset patch
# User Christoph Egger 
# Date 1351165885 -3600
# Node ID 580aa3946f87eb56690671bf1aa0022228f59c8c
# Parent  22e08c9ac770db07c3c3e7c844aa7153050939f3
xl: avoid shadowing reboot(2)

On NetBSD  mistakenly exposes reboot(2).  Work around this.

Signed-off-by: Christoph Egger 
Signed-off-by: Ian Jackson 
Acked-by: Ian Jackson 
Committed-by: Ian Jackson 

diff -r 22e08c9ac770 -r 580aa3946f87 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Oct 24 17:51:48 2012 +0200
+++ b/tools/libxl/xl_cmdimpl.c	Thu Oct 25 12:51:25 2012 +0100
@@ -3721,11 +3721,11 @@ int main_destroy(int argc, char **argv)
     return 0;
 }
 
-static int main_shutdown_or_reboot(int reboot, int argc, char **argv)
+static int main_shutdown_or_reboot(int do_reboot, int argc, char **argv)
 {
     void (*fn)(uint32_t domid,
                libxl_evgen_domain_death **, libxl_ev_user, int) =
-        reboot ? &reboot_domain : &shutdown_domain;
+        do_reboot ? &reboot_domain : &shutdown_domain;
     int opt, i, nb_domain;
     int wait_for_it = 0, all =0;
     int fallback_trigger = 0;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 12:03:07 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 12:03:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRM9C-0001FC-Ed; Thu, 25 Oct 2012 12:02:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRM9B-0001F3-0A
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 12:02:49 +0000
Received: from [85.158.139.211:32098] by server-1.bemta-5.messagelabs.com id
	2A/6F-21640-76A29805; Thu, 25 Oct 2012 12:02:47 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1351166567!22681548!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8901 invoked from network); 25 Oct 2012 12:02:47 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 12:02:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,646,1344211200"; d="scan'208";a="15386760"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 11:57:44 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 12:57:44 +0100
Date: Thu, 25 Oct 2012 12:57:13 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1351158737.18035.142.camel@zakaz.uk.xensource.com>
Message-ID: 
References: 
	<1351091027-20740-4-git-send-email-stefano.stabellini@eu.citrix.com>
	<1351158737.18035.142.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" , "Tim
	\(Xen.org\)" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 4/7] xen/arm: set the SMP bit in the ACTLR
	register
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 25 Oct 2012, Ian Campbell wrote:
> On Wed, 2012-10-24 at 16:03 +0100, Stefano Stabellini wrote:
> > From the Cortex A15 manual:
> > 
> > "Enables the processor to receive instruction cache, BTB, and TLB maintenance
> > operations from other processors"
> > 
> > ...
> > 
> > "You must set this bit before enabling the caches and MMU, or
> > performing any cache and TLB maintenance operations. The only time
> > you must clear this bit is during a processor power-down sequence"
> 
> Is it considered a bug that the firmware doesn't do this?

Why would it be? You can run fairly complicated pieces of software
without caches or MMU.


> > Signed-off-by: Stefano Stabellini 
> > ---
> >  xen/arch/arm/head.S             |    6 ++++++
> >  xen/include/asm-arm/processor.h |   30 ++++++++++++++++++++++++++++++
> >  2 files changed, 36 insertions(+), 0 deletions(-)
> > 
> > diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
> > index 3d01be0..c784f4d 100644
> > --- a/xen/arch/arm/head.S
> > +++ b/xen/arch/arm/head.S
> > @@ -148,6 +148,12 @@ skip_bss:
> >  
> >  	PRINT("- Setting up control registers -\r\n")
> >  	
> > +	/* XXX: Cortex A15 specific */
> 
> We probably need some sort of early proc info keyed of the processor id
> (like Linux) has so we can push this processor specific stuff into the
> right places.

Indeed.
I wrote something simple that should be OK until we get more than
~10 different processors.


> > +	/* Set up the SMP bit in ACTLR */
> > +	mrc   CP32(r0, ACTLR)
> > +	orr   r0, r0, #(ACTLR_SMP) /* enable SMP bit*/
> > +	mcr   CP32(r0, ACTLR)
> 
> Linux does this IFF it isn't already set for some reason:
> #ifdef CONFIG_SMP
>         ALT_SMP(mrc     p15, 0, r0, c1, c0, 1)
>         ALT_UP(mov      r0, #(1 << 6))          @ fake it for UP
>         tst     r0, #(1 << 6)                   @ SMP/nAMP mode enabled?
>         orreq   r0, r0, #(1 << 6)               @ Enable SMP/nAMP mode
>         orreq   r0, r0, r10                     @ Enable CPU-specific SMP bits
>         mcreq   p15, 0, r0, c1, c0, 1
> #endif
> 
> Might just relate to the "fake it up for UP" thing I suppose.

Considering that we don't have a UP config option for Xen (I am aware
of), there is no need for us to do that, I think.


> > +
> >  	/* Set up memory attribute type tables */
> >  	ldr   r0, =MAIR0VAL
> >  	ldr   r1, =MAIR1VAL
> > diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
> > index 3849b23..91a5836 100644
> > --- a/xen/include/asm-arm/processor.h
> > +++ b/xen/include/asm-arm/processor.h
> > @@ -34,6 +34,36 @@
> >  #define SCTLR_A         (1<<1)
> >  #define SCTLR_M         (1<<0)
> >  
> > +/* ACTLR Auxiliary Control Register */
> > +#define ACTLR_SNOOP_DELAYED      (1<<31)
> 
> If these are CortexA15 specific then I think they ought to be
> ACTLR_CA15_FOO or something. And possibly in a new processor-ca15.h
> header instead.

OK

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 12:03:07 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 12:03:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRM9C-0001FC-Ed; Thu, 25 Oct 2012 12:02:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRM9B-0001F3-0A
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 12:02:49 +0000
Received: from [85.158.139.211:32098] by server-1.bemta-5.messagelabs.com id
	2A/6F-21640-76A29805; Thu, 25 Oct 2012 12:02:47 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1351166567!22681548!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8901 invoked from network); 25 Oct 2012 12:02:47 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 12:02:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,646,1344211200"; d="scan'208";a="15386760"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 11:57:44 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 12:57:44 +0100
Date: Thu, 25 Oct 2012 12:57:13 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1351158737.18035.142.camel@zakaz.uk.xensource.com>
Message-ID: 
References: 
	<1351091027-20740-4-git-send-email-stefano.stabellini@eu.citrix.com>
	<1351158737.18035.142.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" , "Tim
	\(Xen.org\)" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 4/7] xen/arm: set the SMP bit in the ACTLR
	register
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 25 Oct 2012, Ian Campbell wrote:
> On Wed, 2012-10-24 at 16:03 +0100, Stefano Stabellini wrote:
> > From the Cortex A15 manual:
> > 
> > "Enables the processor to receive instruction cache, BTB, and TLB maintenance
> > operations from other processors"
> > 
> > ...
> > 
> > "You must set this bit before enabling the caches and MMU, or
> > performing any cache and TLB maintenance operations. The only time
> > you must clear this bit is during a processor power-down sequence"
> 
> Is it considered a bug that the firmware doesn't do this?

Why would it be? You can run fairly complicated pieces of software
without caches or MMU.


> > Signed-off-by: Stefano Stabellini 
> > ---
> >  xen/arch/arm/head.S             |    6 ++++++
> >  xen/include/asm-arm/processor.h |   30 ++++++++++++++++++++++++++++++
> >  2 files changed, 36 insertions(+), 0 deletions(-)
> > 
> > diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
> > index 3d01be0..c784f4d 100644
> > --- a/xen/arch/arm/head.S
> > +++ b/xen/arch/arm/head.S
> > @@ -148,6 +148,12 @@ skip_bss:
> >  
> >  	PRINT("- Setting up control registers -\r\n")
> >  	
> > +	/* XXX: Cortex A15 specific */
> 
> We probably need some sort of early proc info keyed of the processor id
> (like Linux) has so we can push this processor specific stuff into the
> right places.

Indeed.
I wrote something simple that should be OK until we get more than
~10 different processors.


> > +	/* Set up the SMP bit in ACTLR */
> > +	mrc   CP32(r0, ACTLR)
> > +	orr   r0, r0, #(ACTLR_SMP) /* enable SMP bit*/
> > +	mcr   CP32(r0, ACTLR)
> 
> Linux does this IFF it isn't already set for some reason:
> #ifdef CONFIG_SMP
>         ALT_SMP(mrc     p15, 0, r0, c1, c0, 1)
>         ALT_UP(mov      r0, #(1 << 6))          @ fake it for UP
>         tst     r0, #(1 << 6)                   @ SMP/nAMP mode enabled?
>         orreq   r0, r0, #(1 << 6)               @ Enable SMP/nAMP mode
>         orreq   r0, r0, r10                     @ Enable CPU-specific SMP bits
>         mcreq   p15, 0, r0, c1, c0, 1
> #endif
> 
> Might just relate to the "fake it up for UP" thing I suppose.

Considering that we don't have a UP config option for Xen (I am aware
of), there is no need for us to do that, I think.


> > +
> >  	/* Set up memory attribute type tables */
> >  	ldr   r0, =MAIR0VAL
> >  	ldr   r1, =MAIR1VAL
> > diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
> > index 3849b23..91a5836 100644
> > --- a/xen/include/asm-arm/processor.h
> > +++ b/xen/include/asm-arm/processor.h
> > @@ -34,6 +34,36 @@
> >  #define SCTLR_A         (1<<1)
> >  #define SCTLR_M         (1<<0)
> >  
> > +/* ACTLR Auxiliary Control Register */
> > +#define ACTLR_SNOOP_DELAYED      (1<<31)
> 
> If these are CortexA15 specific then I think they ought to be
> ACTLR_CA15_FOO or something. And possibly in a new processor-ca15.h
> header instead.

OK

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 12:05:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 12:05:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRMB9-0001NW-VI; Thu, 25 Oct 2012 12:04:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRMB8-0001NO-So
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 12:04:51 +0000
Received: from [85.158.143.35:9543] by server-3.bemta-4.messagelabs.com id
	B1/9F-24279-2EA29805; Thu, 25 Oct 2012 12:04:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1351166689!11294107!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5942 invoked from network); 25 Oct 2012 12:04:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 12:04:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,646,1344211200"; d="scan'208";a="15386923"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 12:04:31 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 25 Oct 2012 13:04:31 +0100
Message-ID: <1351166670.18035.177.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Thu, 25 Oct 2012 13:04:30 +0100
In-Reply-To: 
References: 
	<1351091027-20740-4-git-send-email-stefano.stabellini@eu.citrix.com>
	<1351158737.18035.142.camel@zakaz.uk.xensource.com>
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" , "Tim
	\(Xen.org\)" 
Subject: Re: [Xen-devel] [PATCH 4/7] xen/arm: set the SMP bit in the ACTLR
	register
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-25 at 12:57 +0100, Stefano Stabellini wrote:
> On Thu, 25 Oct 2012, Ian Campbell wrote:
> > On Wed, 2012-10-24 at 16:03 +0100, Stefano Stabellini wrote:
> > > From the Cortex A15 manual:
> > > 
> > > "Enables the processor to receive instruction cache, BTB, and TLB maintenance
> > > operations from other processors"
> > > 
> > > ...
> > > 
> > > "You must set this bit before enabling the caches and MMU, or
> > > performing any cache and TLB maintenance operations. The only time
> > > you must clear this bit is during a processor power-down sequence"
> > 
> > Is it considered a bug that the firmware doesn't do this?
> 
> Why would it be? You can run fairly complicated pieces of software
> without caches or MMU.

True, I guess I just considered that not setting the SMP bit on the
second processor when the firmware starts it seemed a bit odd. If you
aren't caches/MMU/etc them then setting the bit is pretty much a NOP (or
maybe it isn't?).

> 
> 
> > > Signed-off-by: Stefano Stabellini 
> > > ---
> > >  xen/arch/arm/head.S             |    6 ++++++
> > >  xen/include/asm-arm/processor.h |   30 ++++++++++++++++++++++++++++++
> > >  2 files changed, 36 insertions(+), 0 deletions(-)
> > > 
> > > diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
> > > index 3d01be0..c784f4d 100644
> > > --- a/xen/arch/arm/head.S
> > > +++ b/xen/arch/arm/head.S
> > > @@ -148,6 +148,12 @@ skip_bss:
> > >  
> > >  	PRINT("- Setting up control registers -\r\n")
> > >  	
> > > +	/* XXX: Cortex A15 specific */
> > 
> > We probably need some sort of early proc info keyed of the processor id
> > (like Linux) has so we can push this processor specific stuff into the
> > right places.
> 
> Indeed.
> I wrote something simple that should be OK until we get more than
> ~10 different processors.
> 
> 
> > > +	/* Set up the SMP bit in ACTLR */
> > > +	mrc   CP32(r0, ACTLR)
> > > +	orr   r0, r0, #(ACTLR_SMP) /* enable SMP bit*/
> > > +	mcr   CP32(r0, ACTLR)
> > 
> > Linux does this IFF it isn't already set for some reason:
> > #ifdef CONFIG_SMP
> >         ALT_SMP(mrc     p15, 0, r0, c1, c0, 1)
> >         ALT_UP(mov      r0, #(1 << 6))          @ fake it for UP
> >         tst     r0, #(1 << 6)                   @ SMP/nAMP mode enabled?
> >         orreq   r0, r0, #(1 << 6)               @ Enable SMP/nAMP mode
> >         orreq   r0, r0, r10                     @ Enable CPU-specific SMP bits
> >         mcreq   p15, 0, r0, c1, c0, 1
> > #endif
> > 
> > Might just relate to the "fake it up for UP" thing I suppose.
> 
> Considering that we don't have a UP config option for Xen (I am aware
> of), there is no need for us to do that, I think.
> 
> 
> > > +
> > >  	/* Set up memory attribute type tables */
> > >  	ldr   r0, =MAIR0VAL
> > >  	ldr   r1, =MAIR1VAL
> > > diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
> > > index 3849b23..91a5836 100644
> > > --- a/xen/include/asm-arm/processor.h
> > > +++ b/xen/include/asm-arm/processor.h
> > > @@ -34,6 +34,36 @@
> > >  #define SCTLR_A         (1<<1)
> > >  #define SCTLR_M         (1<<0)
> > >  
> > > +/* ACTLR Auxiliary Control Register */
> > > +#define ACTLR_SNOOP_DELAYED      (1<<31)
> > 
> > If these are CortexA15 specific then I think they ought to be
> > ACTLR_CA15_FOO or something. And possibly in a new processor-ca15.h
> > header instead.
> 
> OK



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 12:05:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 12:05:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRMB9-0001NW-VI; Thu, 25 Oct 2012 12:04:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRMB8-0001NO-So
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 12:04:51 +0000
Received: from [85.158.143.35:9543] by server-3.bemta-4.messagelabs.com id
	B1/9F-24279-2EA29805; Thu, 25 Oct 2012 12:04:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1351166689!11294107!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5942 invoked from network); 25 Oct 2012 12:04:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 12:04:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,646,1344211200"; d="scan'208";a="15386923"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 12:04:31 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 25 Oct 2012 13:04:31 +0100
Message-ID: <1351166670.18035.177.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Thu, 25 Oct 2012 13:04:30 +0100
In-Reply-To: 
References: 
	<1351091027-20740-4-git-send-email-stefano.stabellini@eu.citrix.com>
	<1351158737.18035.142.camel@zakaz.uk.xensource.com>
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" , "Tim
	\(Xen.org\)" 
Subject: Re: [Xen-devel] [PATCH 4/7] xen/arm: set the SMP bit in the ACTLR
	register
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-25 at 12:57 +0100, Stefano Stabellini wrote:
> On Thu, 25 Oct 2012, Ian Campbell wrote:
> > On Wed, 2012-10-24 at 16:03 +0100, Stefano Stabellini wrote:
> > > From the Cortex A15 manual:
> > > 
> > > "Enables the processor to receive instruction cache, BTB, and TLB maintenance
> > > operations from other processors"
> > > 
> > > ...
> > > 
> > > "You must set this bit before enabling the caches and MMU, or
> > > performing any cache and TLB maintenance operations. The only time
> > > you must clear this bit is during a processor power-down sequence"
> > 
> > Is it considered a bug that the firmware doesn't do this?
> 
> Why would it be? You can run fairly complicated pieces of software
> without caches or MMU.

True, I guess I just considered that not setting the SMP bit on the
second processor when the firmware starts it seemed a bit odd. If you
aren't caches/MMU/etc them then setting the bit is pretty much a NOP (or
maybe it isn't?).

> 
> 
> > > Signed-off-by: Stefano Stabellini 
> > > ---
> > >  xen/arch/arm/head.S             |    6 ++++++
> > >  xen/include/asm-arm/processor.h |   30 ++++++++++++++++++++++++++++++
> > >  2 files changed, 36 insertions(+), 0 deletions(-)
> > > 
> > > diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
> > > index 3d01be0..c784f4d 100644
> > > --- a/xen/arch/arm/head.S
> > > +++ b/xen/arch/arm/head.S
> > > @@ -148,6 +148,12 @@ skip_bss:
> > >  
> > >  	PRINT("- Setting up control registers -\r\n")
> > >  	
> > > +	/* XXX: Cortex A15 specific */
> > 
> > We probably need some sort of early proc info keyed of the processor id
> > (like Linux) has so we can push this processor specific stuff into the
> > right places.
> 
> Indeed.
> I wrote something simple that should be OK until we get more than
> ~10 different processors.
> 
> 
> > > +	/* Set up the SMP bit in ACTLR */
> > > +	mrc   CP32(r0, ACTLR)
> > > +	orr   r0, r0, #(ACTLR_SMP) /* enable SMP bit*/
> > > +	mcr   CP32(r0, ACTLR)
> > 
> > Linux does this IFF it isn't already set for some reason:
> > #ifdef CONFIG_SMP
> >         ALT_SMP(mrc     p15, 0, r0, c1, c0, 1)
> >         ALT_UP(mov      r0, #(1 << 6))          @ fake it for UP
> >         tst     r0, #(1 << 6)                   @ SMP/nAMP mode enabled?
> >         orreq   r0, r0, #(1 << 6)               @ Enable SMP/nAMP mode
> >         orreq   r0, r0, r10                     @ Enable CPU-specific SMP bits
> >         mcreq   p15, 0, r0, c1, c0, 1
> > #endif
> > 
> > Might just relate to the "fake it up for UP" thing I suppose.
> 
> Considering that we don't have a UP config option for Xen (I am aware
> of), there is no need for us to do that, I think.
> 
> 
> > > +
> > >  	/* Set up memory attribute type tables */
> > >  	ldr   r0, =MAIR0VAL
> > >  	ldr   r1, =MAIR1VAL
> > > diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
> > > index 3849b23..91a5836 100644
> > > --- a/xen/include/asm-arm/processor.h
> > > +++ b/xen/include/asm-arm/processor.h
> > > @@ -34,6 +34,36 @@
> > >  #define SCTLR_A         (1<<1)
> > >  #define SCTLR_M         (1<<0)
> > >  
> > > +/* ACTLR Auxiliary Control Register */
> > > +#define ACTLR_SNOOP_DELAYED      (1<<31)
> > 
> > If these are CortexA15 specific then I think they ought to be
> > ACTLR_CA15_FOO or something. And possibly in a new processor-ca15.h
> > header instead.
> 
> OK



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 12:10:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 12:10:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRMGh-0001bx-ON; Thu, 25 Oct 2012 12:10:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRMGg-0001bh-06
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 12:10:34 +0000
Received: from [85.158.143.99:42767] by server-2.bemta-4.messagelabs.com id
	4C/68-22268-93C29805; Thu, 25 Oct 2012 12:10:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1351167030!22067346!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9992 invoked from network); 25 Oct 2012 12:10:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 12:10:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,646,1344211200"; d="scan'208";a="15387082"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 12:10:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 25 Oct 2012 13:10:29 +0100
Message-ID: <1351167028.18035.179.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Olaf Hering 
Date: Thu, 25 Oct 2012 13:10:28 +0100
In-Reply-To: <20121025114645.GA7218@aepfle.de>
References: 
	 <20121025114645.GA7218@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk , Keir Fraser ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] tools/hvmloader: move shared_info to
 reserved memory area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-25 at 12:46 +0100, Olaf Hering wrote:
> On Thu, Oct 25, Keir Fraser wrote:
> 
> > To be honest, given that the XenPVHVM extensions to Linux won't have been
> > tested on such old hypervisors, it wouldn't be a bad thing to bail on
> > setting up the extensions when you detect running on a really old Xen
> > version (e.g., earlier than 3.4.0) anyway. There's a fair chance of doing
> > more harm than good?
> 
> I could stick such a check into
> arch/x86/xen/enlighten.c:x86_hyper_xen_hvm->detect, by rearranging the
> code of xen_hvm_platform and init_hvm_pv_info.  Konrad, what do you
> think about that?

If you do something like this please could you add a command line option
to allow it to be forced both off and on?

I suppose this relates a bit to xen_emul_unplug too?

> Recent changes indicate that you did some testing on
> 3.4 based hosts.

NB Keir said "earlier than 3.4". I think we would want to try and
support 3.4, but not 3.3.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 12:10:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 12:10:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRMGh-0001bx-ON; Thu, 25 Oct 2012 12:10:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRMGg-0001bh-06
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 12:10:34 +0000
Received: from [85.158.143.99:42767] by server-2.bemta-4.messagelabs.com id
	4C/68-22268-93C29805; Thu, 25 Oct 2012 12:10:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1351167030!22067346!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9992 invoked from network); 25 Oct 2012 12:10:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 12:10:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,646,1344211200"; d="scan'208";a="15387082"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 12:10:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 25 Oct 2012 13:10:29 +0100
Message-ID: <1351167028.18035.179.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Olaf Hering 
Date: Thu, 25 Oct 2012 13:10:28 +0100
In-Reply-To: <20121025114645.GA7218@aepfle.de>
References: 
	 <20121025114645.GA7218@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk , Keir Fraser ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] tools/hvmloader: move shared_info to
 reserved memory area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-25 at 12:46 +0100, Olaf Hering wrote:
> On Thu, Oct 25, Keir Fraser wrote:
> 
> > To be honest, given that the XenPVHVM extensions to Linux won't have been
> > tested on such old hypervisors, it wouldn't be a bad thing to bail on
> > setting up the extensions when you detect running on a really old Xen
> > version (e.g., earlier than 3.4.0) anyway. There's a fair chance of doing
> > more harm than good?
> 
> I could stick such a check into
> arch/x86/xen/enlighten.c:x86_hyper_xen_hvm->detect, by rearranging the
> code of xen_hvm_platform and init_hvm_pv_info.  Konrad, what do you
> think about that?

If you do something like this please could you add a command line option
to allow it to be forced both off and on?

I suppose this relates a bit to xen_emul_unplug too?

> Recent changes indicate that you did some testing on
> 3.4 based hosts.

NB Keir said "earlier than 3.4". I think we would want to try and
support 3.4, but not 3.3.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 12:16:38 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 12:16:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRMMI-0001nf-H0; Thu, 25 Oct 2012 12:16:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRMMH-0001na-2Y
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 12:16:21 +0000
Received: from [193.109.254.147:45371] by server-5.bemta-14.messagelabs.com id
	06/BD-18309-49D29805; Thu, 25 Oct 2012 12:16:20 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-27.messagelabs.com!1351167379!2605872!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDU4NDI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDU4NDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7525 invoked from network); 25 Oct 2012 12:16:19 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Oct 2012 12:16:19 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll387qFkE=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-086-014.pools.arcor-ip.net [84.57.86.14])
	by smtp.strato.de (josoe mo28) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 303285o9PBh2Vq ;
	Thu, 25 Oct 2012 14:16:19 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 14E0B18642; Thu, 25 Oct 2012 14:16:17 +0200 (CEST)
Date: Thu, 25 Oct 2012 14:16:17 +0200
From: Olaf Hering 
To: Ian Campbell 
Message-ID: <20121025121617.GA12285@aepfle.de>
References: 
	
	<20121025114645.GA7218@aepfle.de>
	<1351167028.18035.179.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1351167028.18035.179.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: Konrad Rzeszutek Wilk , Keir Fraser ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] tools/hvmloader: move shared_info to
 reserved memory area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Oct 25, Ian Campbell wrote:

> NB Keir said "earlier than 3.4". I think we would want to try and
> support 3.4, but not 3.3.

Absolutely.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 12:16:38 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 12:16:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRMMI-0001nf-H0; Thu, 25 Oct 2012 12:16:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRMMH-0001na-2Y
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 12:16:21 +0000
Received: from [193.109.254.147:45371] by server-5.bemta-14.messagelabs.com id
	06/BD-18309-49D29805; Thu, 25 Oct 2012 12:16:20 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-27.messagelabs.com!1351167379!2605872!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDU4NDI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0NDU4NDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7525 invoked from network); 25 Oct 2012 12:16:19 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Oct 2012 12:16:19 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll387qFkE=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-086-014.pools.arcor-ip.net [84.57.86.14])
	by smtp.strato.de (josoe mo28) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 303285o9PBh2Vq ;
	Thu, 25 Oct 2012 14:16:19 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 14E0B18642; Thu, 25 Oct 2012 14:16:17 +0200 (CEST)
Date: Thu, 25 Oct 2012 14:16:17 +0200
From: Olaf Hering 
To: Ian Campbell 
Message-ID: <20121025121617.GA12285@aepfle.de>
References: 
	
	<20121025114645.GA7218@aepfle.de>
	<1351167028.18035.179.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1351167028.18035.179.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: Konrad Rzeszutek Wilk , Keir Fraser ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] tools/hvmloader: move shared_info to
 reserved memory area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Oct 25, Ian Campbell wrote:

> NB Keir said "earlier than 3.4". I think we would want to try and
> support 3.4, but not 3.3.

Absolutely.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 12:18:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 12:18:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRMNs-0001sU-0D; Thu, 25 Oct 2012 12:18:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRMNq-0001sP-Ib
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 12:17:58 +0000
Received: from [193.109.254.147:48451] by server-16.bemta-14.messagelabs.com
	id 4D/94-09215-5FD29805; Thu, 25 Oct 2012 12:17:57 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1351167474!14011226!1
X-Originating-IP: [209.85.220.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6651 invoked from network); 25 Oct 2012 12:17:55 -0000
Received: from mail-pa0-f45.google.com (HELO mail-pa0-f45.google.com)
	(209.85.220.45)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 12:17:55 -0000
Received: by mail-pa0-f45.google.com with SMTP id fb10so1167018pad.32
	for ; Thu, 25 Oct 2012 05:17:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=Y4oHrD7D4zLxVetvDpBzwcucamf8MAYCkKEkyr/Gq1o=;
	b=bjup2iW9xCKPyq1sXs3SOrAUA8fDPr+KWxj1SLqInUdmOMtJWnWX5QX87HGDS6WVly
	uT32XaFFP2G23Qi8oaT+VsX6vltvHo4K2YBXPVHWgJbt/0waojz0c2rl0tbxBwcMGLn4
	CAwhecQheCrYswESCSxOmKWAlVafvl6+7QaI6FAYdLHPfvAaqkKPs8JWKZVSQ2OI7GsI
	j/q2aEIYOpx/vdxFiyBUoFbVZbOpCGo0NTelvsZ3fApSjw6pERq0eaNmVzw4Kyt3TmkL
	l6pVjYZxLRpCfccBjStge+9J5WN3ZqM5TiwlWoKCulw2ZNqT4yeRV42b4eim+XP3gTDk
	vPjg==
Received: by 10.68.234.201 with SMTP id ug9mr17910528pbc.63.1351167473774;
	Thu, 25 Oct 2012 05:17:53 -0700 (PDT)
Received: from [101.2.20.10] ([96.49.152.177])
	by mx.google.com with ESMTPS id o5sm11208775paz.32.2012.10.25.05.17.47
	(version=SSLv3 cipher=OTHER); Thu, 25 Oct 2012 05:17:52 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Thu, 25 Oct 2012 05:17:43 -0700
From: Keir Fraser 
To: Jan Beulich ,
	xen-devel 
Message-ID: 
Thread-Topic: [Xen-devel] [PATCH] compiler.h adjustments
Thread-Index: Ac2yqrviYS3WhkdDKUWLA/tabV/Wsw==
In-Reply-To: <508943FF02000078000A46FE@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] compiler.h adjustments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 25/10/2012 04:51, "Jan Beulich"  wrote:

> - replace __attribute_used__ with just __used
> - add __maybe_unused and explain the difference between the two
> - remove gcc 3.x specifics (as we don't support building with it
>   anymore; really for quite some time we didn't even support building
>   with the checked for minor versions)
> - remove left over __setup() from init.h (rather than adjusting it)
> 
> Signed-off-by: Jan Beulich 

Acked-by: Keir Fraser 

> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -41,7 +41,7 @@
>  #include 
>  #include "gic.h"
>  
> -static __attribute_used__ void init_done(void)
> +static __used void init_done(void)
>  {
>      free_init_memory();
>      startup_cpu_idle_loop();
> --- a/xen/include/xen/compiler.h
> +++ b/xen/include/xen/compiler.h
> @@ -1,7 +1,7 @@
>  #ifndef __LINUX_COMPILER_H
>  #define __LINUX_COMPILER_H
>  
> -#if !defined(__GNUC__) || (__GNUC__ < 3)
> +#if !defined(__GNUC__) || (__GNUC__ < 4)
>  #error Sorry, your compiler is too old/not recognized.
>  #endif
>  
> @@ -17,11 +17,11 @@
>  #ifdef __clang__
>  /* Clang can replace some vars with new automatic ones that go in .data;
>   * mark all explicit-segment vars 'used' to prevent that. */
> -#define __section(s)      __attribute_used__ __attribute__((__section__(s)))
> +#define __section(s)      __used __attribute__((__section__(s)))
>  #else
>  #define __section(s)      __attribute__((__section__(s)))
>  #endif
> -#define __used_section(s) __attribute_used__ __attribute__((__section__(s)))
> +#define __used_section(s) __used __attribute__((__section__(s)))
>  #define __text_section(s) __attribute__((__section__(s)))
>  
>  #ifdef INIT_SECTIONS_ONLY
> @@ -36,23 +36,23 @@
>  #define __attribute_pure__  __attribute__((pure))
>  #define __attribute_const__ __attribute__((__const__))
>  
> -#if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 3)
> -#define __attribute_used__ __attribute__((__used__))
> -#else
> -#define __attribute_used__ __attribute__((__unused__))
> -#endif
> +/*
> + * The difference between the following two attributes is that __used is
> + * intended to be used in cases where a reference to an identifier may be
> + * invisible to the compiler (e.g. an inline assembly operand not listed
> + * in the asm()'s operands), preventing the compiler from eliminating the
> + * variable or function.
> + * __maybe_unused otoh is to be used to merely prevent warnings (e.g. when
> + * an identifier is used only inside a preprocessor conditional, yet putting
> + * its declaration/definition inside another conditional would harm code
> + * readability).
> + */
> +#define __used         __attribute__((__used__))
> +#define __maybe_unused __attribute__((__unused__))
>  
> -#if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 4)
>  #define __must_check __attribute__((warn_unused_result))
> -#else
> -#define __must_check
> -#endif
>  
> -#if __GNUC__ > 3
>  #define offsetof(a,b) __builtin_offsetof(a,b)
> -#else
> -#define offsetof(a,b) ((unsigned long)&(((a *)0)->b))
> -#endif
>  
>  /* &a[0] degrades to a pointer: a different type from an array */
>  #define __must_be_array(a) \
> --- a/xen/include/xen/init.h
> +++ b/xen/include/xen/init.h
> @@ -114,9 +114,6 @@ extern struct kernel_param __setup_start
>      __kparam __setup_##_var = \
>          { __setup_str_##_var, OPT_STR, &_var, sizeof(_var) }
>  
> -/* Make sure obsolete cmdline params don't break the build. */
> -#define __setup(_name, _fn) static void * __attribute_used__ _dummy_##_fn =
> _fn
> -    
>  #endif /* __ASSEMBLY__ */
>  
>  #ifdef CONFIG_HOTPLUG
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 12:18:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 12:18:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRMNs-0001sU-0D; Thu, 25 Oct 2012 12:18:00 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRMNq-0001sP-Ib
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 12:17:58 +0000
Received: from [193.109.254.147:48451] by server-16.bemta-14.messagelabs.com
	id 4D/94-09215-5FD29805; Thu, 25 Oct 2012 12:17:57 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1351167474!14011226!1
X-Originating-IP: [209.85.220.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6651 invoked from network); 25 Oct 2012 12:17:55 -0000
Received: from mail-pa0-f45.google.com (HELO mail-pa0-f45.google.com)
	(209.85.220.45)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 12:17:55 -0000
Received: by mail-pa0-f45.google.com with SMTP id fb10so1167018pad.32
	for ; Thu, 25 Oct 2012 05:17:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=Y4oHrD7D4zLxVetvDpBzwcucamf8MAYCkKEkyr/Gq1o=;
	b=bjup2iW9xCKPyq1sXs3SOrAUA8fDPr+KWxj1SLqInUdmOMtJWnWX5QX87HGDS6WVly
	uT32XaFFP2G23Qi8oaT+VsX6vltvHo4K2YBXPVHWgJbt/0waojz0c2rl0tbxBwcMGLn4
	CAwhecQheCrYswESCSxOmKWAlVafvl6+7QaI6FAYdLHPfvAaqkKPs8JWKZVSQ2OI7GsI
	j/q2aEIYOpx/vdxFiyBUoFbVZbOpCGo0NTelvsZ3fApSjw6pERq0eaNmVzw4Kyt3TmkL
	l6pVjYZxLRpCfccBjStge+9J5WN3ZqM5TiwlWoKCulw2ZNqT4yeRV42b4eim+XP3gTDk
	vPjg==
Received: by 10.68.234.201 with SMTP id ug9mr17910528pbc.63.1351167473774;
	Thu, 25 Oct 2012 05:17:53 -0700 (PDT)
Received: from [101.2.20.10] ([96.49.152.177])
	by mx.google.com with ESMTPS id o5sm11208775paz.32.2012.10.25.05.17.47
	(version=SSLv3 cipher=OTHER); Thu, 25 Oct 2012 05:17:52 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Thu, 25 Oct 2012 05:17:43 -0700
From: Keir Fraser 
To: Jan Beulich ,
	xen-devel 
Message-ID: 
Thread-Topic: [Xen-devel] [PATCH] compiler.h adjustments
Thread-Index: Ac2yqrviYS3WhkdDKUWLA/tabV/Wsw==
In-Reply-To: <508943FF02000078000A46FE@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] compiler.h adjustments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 25/10/2012 04:51, "Jan Beulich"  wrote:

> - replace __attribute_used__ with just __used
> - add __maybe_unused and explain the difference between the two
> - remove gcc 3.x specifics (as we don't support building with it
>   anymore; really for quite some time we didn't even support building
>   with the checked for minor versions)
> - remove left over __setup() from init.h (rather than adjusting it)
> 
> Signed-off-by: Jan Beulich 

Acked-by: Keir Fraser 

> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -41,7 +41,7 @@
>  #include 
>  #include "gic.h"
>  
> -static __attribute_used__ void init_done(void)
> +static __used void init_done(void)
>  {
>      free_init_memory();
>      startup_cpu_idle_loop();
> --- a/xen/include/xen/compiler.h
> +++ b/xen/include/xen/compiler.h
> @@ -1,7 +1,7 @@
>  #ifndef __LINUX_COMPILER_H
>  #define __LINUX_COMPILER_H
>  
> -#if !defined(__GNUC__) || (__GNUC__ < 3)
> +#if !defined(__GNUC__) || (__GNUC__ < 4)
>  #error Sorry, your compiler is too old/not recognized.
>  #endif
>  
> @@ -17,11 +17,11 @@
>  #ifdef __clang__
>  /* Clang can replace some vars with new automatic ones that go in .data;
>   * mark all explicit-segment vars 'used' to prevent that. */
> -#define __section(s)      __attribute_used__ __attribute__((__section__(s)))
> +#define __section(s)      __used __attribute__((__section__(s)))
>  #else
>  #define __section(s)      __attribute__((__section__(s)))
>  #endif
> -#define __used_section(s) __attribute_used__ __attribute__((__section__(s)))
> +#define __used_section(s) __used __attribute__((__section__(s)))
>  #define __text_section(s) __attribute__((__section__(s)))
>  
>  #ifdef INIT_SECTIONS_ONLY
> @@ -36,23 +36,23 @@
>  #define __attribute_pure__  __attribute__((pure))
>  #define __attribute_const__ __attribute__((__const__))
>  
> -#if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 3)
> -#define __attribute_used__ __attribute__((__used__))
> -#else
> -#define __attribute_used__ __attribute__((__unused__))
> -#endif
> +/*
> + * The difference between the following two attributes is that __used is
> + * intended to be used in cases where a reference to an identifier may be
> + * invisible to the compiler (e.g. an inline assembly operand not listed
> + * in the asm()'s operands), preventing the compiler from eliminating the
> + * variable or function.
> + * __maybe_unused otoh is to be used to merely prevent warnings (e.g. when
> + * an identifier is used only inside a preprocessor conditional, yet putting
> + * its declaration/definition inside another conditional would harm code
> + * readability).
> + */
> +#define __used         __attribute__((__used__))
> +#define __maybe_unused __attribute__((__unused__))
>  
> -#if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 4)
>  #define __must_check __attribute__((warn_unused_result))
> -#else
> -#define __must_check
> -#endif
>  
> -#if __GNUC__ > 3
>  #define offsetof(a,b) __builtin_offsetof(a,b)
> -#else
> -#define offsetof(a,b) ((unsigned long)&(((a *)0)->b))
> -#endif
>  
>  /* &a[0] degrades to a pointer: a different type from an array */
>  #define __must_be_array(a) \
> --- a/xen/include/xen/init.h
> +++ b/xen/include/xen/init.h
> @@ -114,9 +114,6 @@ extern struct kernel_param __setup_start
>      __kparam __setup_##_var = \
>          { __setup_str_##_var, OPT_STR, &_var, sizeof(_var) }
>  
> -/* Make sure obsolete cmdline params don't break the build. */
> -#define __setup(_name, _fn) static void * __attribute_used__ _dummy_##_fn =
> _fn
> -    
>  #endif /* __ASSEMBLY__ */
>  
>  #ifdef CONFIG_HOTPLUG
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 12:18:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 12:18:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRMO2-0001tQ-CU; Thu, 25 Oct 2012 12:18:10 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRMO0-0001t3-Ps
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 12:18:08 +0000
Received: from [193.109.254.147:6419] by server-13.bemta-14.messagelabs.com id
	81/19-11239-00E29805; Thu, 25 Oct 2012 12:18:08 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1351167474!14011226!2
X-Originating-IP: [209.85.220.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7421 invoked from network); 25 Oct 2012 12:18:07 -0000
Received: from mail-pa0-f45.google.com (HELO mail-pa0-f45.google.com)
	(209.85.220.45)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 12:18:07 -0000
Received: by mail-pa0-f45.google.com with SMTP id fb10so1167018pad.32
	for ; Thu, 25 Oct 2012 05:18:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=NZSPqYKdCdvzBK815fRDKGZjP5N1VUJzqUfgAWju8rY=;
	b=owYY1wKCOwD2YVz/2hgxB1YMzgS9FQv2iUybFVg+/4ROYMSrgN/P9Z6a+uYCdZUkKG
	IRzoU5EZf24HwXRzpYCqdRxFW6firdHD1jCQwZhUdWaVRuKdq54MQaJZSdRGgsQ8wHEw
	IYvwybzupMO+YYOu3GQUVlVmkCNeF87OJirQvkMYU5AIlv7sX/NqNMctn9m3wsDVafVh
	6mndOyGcYA11PZqsa/ZJ6t4CTU9j6NWJefp7zcoYOP40x+f3MofrZg0R1uGNntItMBh5
	Cjmp92Pbmdu8BCc61Pi6eAu1KseDHan9AJ5vGph6snEugAsG2gyWzPEDUO/eAU0OE7tG
	6eaA==
Received: by 10.66.89.98 with SMTP id bn2mr52489270pab.72.1351167486801;
	Thu, 25 Oct 2012 05:18:06 -0700 (PDT)
Received: from [101.2.20.10] ([96.49.152.177])
	by mx.google.com with ESMTPS id lb4sm9755665pbc.6.2012.10.25.05.18.03
	(version=SSLv3 cipher=OTHER); Thu, 25 Oct 2012 05:18:05 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Thu, 25 Oct 2012 05:18:01 -0700
From: Keir Fraser 
To: Jan Beulich ,
	Keir Fraser 
Message-ID: 
Thread-Topic: [PATCH v2] x86/HPET: cache MSI message last written
Thread-Index: Ac2yqsadj1mMntSy4U2Lp0kpaMtOHA==
In-Reply-To: <5089444102000078000A4702@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel 
Subject: Re: [Xen-devel] [PATCH v2] x86/HPET: cache MSI message last written
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 25/10/2012 04:53, "Jan Beulich"  wrote:

> Rather than spending measurable amounts of time reading back the most
> recently written message, cache it in space previously unused, and thus
> accelerate the CPU's entering of the intended C-state.
> 
> hpet_msi_read() ends up being unused after this change, but rather than
> removing the function, it's being marked "unused" in order - that way
> it can easily get used again should a new need for it arise.
> 
> Signed-off-by: Jan Beulich 

Acked-by: Keir Fraser 

> ---
> v2: Re-based on top of the previously sent patch "compiler.h
>     adjustments".
> 
> --- a/xen/arch/x86/hpet.c
> +++ b/xen/arch/x86/hpet.c
> @@ -253,17 +253,19 @@ static void hpet_msi_mask(struct irq_des
>  
>  static void hpet_msi_write(struct hpet_event_channel *ch, struct msi_msg
> *msg)
>  {
> +    ch->msi.msg = *msg;
>      if ( iommu_intremap )
>          iommu_update_ire_from_msi(&ch->msi, msg);
>      hpet_write32(msg->data, HPET_Tn_ROUTE(ch->idx));
>      hpet_write32(msg->address_lo, HPET_Tn_ROUTE(ch->idx) + 4);
>  }
>  
> -static void hpet_msi_read(struct hpet_event_channel *ch, struct msi_msg *msg)
> +static void __maybe_unused
> +hpet_msi_read(struct hpet_event_channel *ch, struct msi_msg *msg)
>  {
>      msg->data = hpet_read32(HPET_Tn_ROUTE(ch->idx));
>      msg->address_lo = hpet_read32(HPET_Tn_ROUTE(ch->idx) + 4);
> -    msg->address_hi = 0;
> +    msg->address_hi = MSI_ADDR_BASE_HI;
>      if ( iommu_intremap )
>          iommu_read_msi_from_ire(&ch->msi, msg);
>  }
> @@ -285,20 +287,19 @@ static void hpet_msi_ack(struct irq_desc
>  
>  static void hpet_msi_set_affinity(struct irq_desc *desc, const cpumask_t
> *mask)
>  {
> -    struct msi_msg msg;
> -    unsigned int dest;
> +    struct hpet_event_channel *ch = desc->action->dev_id;
> +    struct msi_msg msg = ch->msi.msg;
>  
> -    dest = set_desc_affinity(desc, mask);
> -    if (dest == BAD_APICID)
> +    msg.dest32 = set_desc_affinity(desc, mask);
> +    if ( msg.dest32 == BAD_APICID )
>          return;
>  
> -    hpet_msi_read(desc->action->dev_id, &msg);
>      msg.data &= ~MSI_DATA_VECTOR_MASK;
>      msg.data |= MSI_DATA_VECTOR(desc->arch.vector);
>      msg.address_lo &= ~MSI_ADDR_DEST_ID_MASK;
> -    msg.address_lo |= MSI_ADDR_DEST_ID(dest);
> -    msg.dest32 = dest;
> -    hpet_msi_write(desc->action->dev_id, &msg);
> +    msg.address_lo |= MSI_ADDR_DEST_ID(msg.dest32);
> +    if ( msg.data != ch->msi.msg.data || msg.dest32 != ch->msi.msg.dest32 )
> +        hpet_msi_write(ch, &msg);
>  }
>  
>  /*
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 12:18:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 12:18:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRMO2-0001tQ-CU; Thu, 25 Oct 2012 12:18:10 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRMO0-0001t3-Ps
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 12:18:08 +0000
Received: from [193.109.254.147:6419] by server-13.bemta-14.messagelabs.com id
	81/19-11239-00E29805; Thu, 25 Oct 2012 12:18:08 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1351167474!14011226!2
X-Originating-IP: [209.85.220.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7421 invoked from network); 25 Oct 2012 12:18:07 -0000
Received: from mail-pa0-f45.google.com (HELO mail-pa0-f45.google.com)
	(209.85.220.45)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 12:18:07 -0000
Received: by mail-pa0-f45.google.com with SMTP id fb10so1167018pad.32
	for ; Thu, 25 Oct 2012 05:18:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=NZSPqYKdCdvzBK815fRDKGZjP5N1VUJzqUfgAWju8rY=;
	b=owYY1wKCOwD2YVz/2hgxB1YMzgS9FQv2iUybFVg+/4ROYMSrgN/P9Z6a+uYCdZUkKG
	IRzoU5EZf24HwXRzpYCqdRxFW6firdHD1jCQwZhUdWaVRuKdq54MQaJZSdRGgsQ8wHEw
	IYvwybzupMO+YYOu3GQUVlVmkCNeF87OJirQvkMYU5AIlv7sX/NqNMctn9m3wsDVafVh
	6mndOyGcYA11PZqsa/ZJ6t4CTU9j6NWJefp7zcoYOP40x+f3MofrZg0R1uGNntItMBh5
	Cjmp92Pbmdu8BCc61Pi6eAu1KseDHan9AJ5vGph6snEugAsG2gyWzPEDUO/eAU0OE7tG
	6eaA==
Received: by 10.66.89.98 with SMTP id bn2mr52489270pab.72.1351167486801;
	Thu, 25 Oct 2012 05:18:06 -0700 (PDT)
Received: from [101.2.20.10] ([96.49.152.177])
	by mx.google.com with ESMTPS id lb4sm9755665pbc.6.2012.10.25.05.18.03
	(version=SSLv3 cipher=OTHER); Thu, 25 Oct 2012 05:18:05 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Thu, 25 Oct 2012 05:18:01 -0700
From: Keir Fraser 
To: Jan Beulich ,
	Keir Fraser 
Message-ID: 
Thread-Topic: [PATCH v2] x86/HPET: cache MSI message last written
Thread-Index: Ac2yqsadj1mMntSy4U2Lp0kpaMtOHA==
In-Reply-To: <5089444102000078000A4702@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel 
Subject: Re: [Xen-devel] [PATCH v2] x86/HPET: cache MSI message last written
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 25/10/2012 04:53, "Jan Beulich"  wrote:

> Rather than spending measurable amounts of time reading back the most
> recently written message, cache it in space previously unused, and thus
> accelerate the CPU's entering of the intended C-state.
> 
> hpet_msi_read() ends up being unused after this change, but rather than
> removing the function, it's being marked "unused" in order - that way
> it can easily get used again should a new need for it arise.
> 
> Signed-off-by: Jan Beulich 

Acked-by: Keir Fraser 

> ---
> v2: Re-based on top of the previously sent patch "compiler.h
>     adjustments".
> 
> --- a/xen/arch/x86/hpet.c
> +++ b/xen/arch/x86/hpet.c
> @@ -253,17 +253,19 @@ static void hpet_msi_mask(struct irq_des
>  
>  static void hpet_msi_write(struct hpet_event_channel *ch, struct msi_msg
> *msg)
>  {
> +    ch->msi.msg = *msg;
>      if ( iommu_intremap )
>          iommu_update_ire_from_msi(&ch->msi, msg);
>      hpet_write32(msg->data, HPET_Tn_ROUTE(ch->idx));
>      hpet_write32(msg->address_lo, HPET_Tn_ROUTE(ch->idx) + 4);
>  }
>  
> -static void hpet_msi_read(struct hpet_event_channel *ch, struct msi_msg *msg)
> +static void __maybe_unused
> +hpet_msi_read(struct hpet_event_channel *ch, struct msi_msg *msg)
>  {
>      msg->data = hpet_read32(HPET_Tn_ROUTE(ch->idx));
>      msg->address_lo = hpet_read32(HPET_Tn_ROUTE(ch->idx) + 4);
> -    msg->address_hi = 0;
> +    msg->address_hi = MSI_ADDR_BASE_HI;
>      if ( iommu_intremap )
>          iommu_read_msi_from_ire(&ch->msi, msg);
>  }
> @@ -285,20 +287,19 @@ static void hpet_msi_ack(struct irq_desc
>  
>  static void hpet_msi_set_affinity(struct irq_desc *desc, const cpumask_t
> *mask)
>  {
> -    struct msi_msg msg;
> -    unsigned int dest;
> +    struct hpet_event_channel *ch = desc->action->dev_id;
> +    struct msi_msg msg = ch->msi.msg;
>  
> -    dest = set_desc_affinity(desc, mask);
> -    if (dest == BAD_APICID)
> +    msg.dest32 = set_desc_affinity(desc, mask);
> +    if ( msg.dest32 == BAD_APICID )
>          return;
>  
> -    hpet_msi_read(desc->action->dev_id, &msg);
>      msg.data &= ~MSI_DATA_VECTOR_MASK;
>      msg.data |= MSI_DATA_VECTOR(desc->arch.vector);
>      msg.address_lo &= ~MSI_ADDR_DEST_ID_MASK;
> -    msg.address_lo |= MSI_ADDR_DEST_ID(dest);
> -    msg.dest32 = dest;
> -    hpet_msi_write(desc->action->dev_id, &msg);
> +    msg.address_lo |= MSI_ADDR_DEST_ID(msg.dest32);
> +    if ( msg.data != ch->msi.msg.data || msg.dest32 != ch->msi.msg.dest32 )
> +        hpet_msi_write(ch, &msg);
>  }
>  
>  /*
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 12:20:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 12:20:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRMQ0-00027s-25; Thu, 25 Oct 2012 12:20:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRMPy-00027h-PJ
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 12:20:11 +0000
Received: from [85.158.137.99:35756] by server-10.bemta-3.messagelabs.com id
	F7/F7-00901-A7E29805; Thu, 25 Oct 2012 12:20:10 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1351167607!20634211!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzU5MzUw\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25411 invoked from network); 25 Oct 2012 12:20:08 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-15.tower-217.messagelabs.com with SMTP;
	25 Oct 2012 12:20:08 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 25 Oct 2012 05:19:37 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,646,1344236400"; 
	d="scan'208,223";a="232379272"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by orsmga002.jf.intel.com with ESMTP; 25 Oct 2012 05:20:03 -0700
Received: from fmsmsx151.amr.corp.intel.com (10.19.17.220) by
	FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 25 Oct 2012 05:20:02 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX151.amr.corp.intel.com (10.19.17.220) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 25 Oct 2012 05:20:02 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.186]) with mapi id
	14.01.0355.002; Thu, 25 Oct 2012 20:20:00 +0800
From: "Liu, Jinsong" 
To: Konrad Rzeszutek Wilk ,
	"linux-kernel@vger.kernel.org" ,
	"xen-devel@lists.xensource.com" 
Thread-Topic: [PATCH 1/2] Xen acpi pad implement
Thread-Index: Ac2yqwziy4ng7bX0TLqjDy8/5OpTbg==
Date: Thu, 25 Oct 2012 12:19:59 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC829233537157FSHSMSX101ccrcorpi_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 1/2] Xen acpi pad implement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC829233537157FSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From f233ad06cf924116693d7d38be9ae9d8c11f8a9b Mon Sep 17 00:00:00 2001
From: Liu, Jinsong 
Date: Fri, 26 Oct 2012 02:32:48 +0800
Subject: [PATCH 1/2] Xen acpi pad implement

PAD is acpi Processor Aggregator Device which provides a control point
that enables the platform to perform specific processor configuration
and control that applies to all processors in the platform.

This patch is to implement Xen acpi pad logic. When running under Xen
virt platform, native pad driver would not work. Instead Xen pad driver,
a self-contained and very thin logic level, would take over acpi pad staff.
When acpi pad notify OSPM, xen pad logic intercept and parse _PUR object
and then hypercall to hyervisor for the rest work, say, core parking.

Signed-off-by: Liu, Jinsong 
---
 drivers/xen/Makefile             |    1 +
 drivers/xen/xen_acpi_pad.c       |  173 ++++++++++++++++++++++++++++++++++=
++++
 include/xen/interface/platform.h |   17 ++++
 3 files changed, 191 insertions(+), 0 deletions(-)
 create mode 100644 drivers/xen/xen_acpi_pad.c

diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 0e86370..a2af622 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_XEN_MCE_LOG)		+=3D mcelog.o
 obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+=3D xen-pciback/
 obj-$(CONFIG_XEN_PRIVCMD)		+=3D xen-privcmd.o
 obj-$(CONFIG_XEN_ACPI_PROCESSOR)	+=3D xen-acpi-processor.o
+obj-$(CONFIG_XEN_DOM0)			+=3D xen_acpi_pad.o
 xen-evtchn-y				:=3D evtchn.o
 xen-gntdev-y				:=3D gntdev.o
 xen-gntalloc-y				:=3D gntalloc.o
diff --git a/drivers/xen/xen_acpi_pad.c b/drivers/xen/xen_acpi_pad.c
new file mode 100644
index 0000000..e7b7dca
--- /dev/null
+++ b/drivers/xen/xen_acpi_pad.c
@@ -0,0 +1,173 @@
+/*
+ * xen_acpi_pad.c - Xen pad interface
+ *
+ * Copyright (c) 2012, Intel Corporation.
+ *    Author: Liu, Jinsong 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License f=
or
+ * more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#if defined(CONFIG_ACPI_PROCESSOR_AGGREGATOR) || \
+		defined(CONFIG_ACPI_PROCESSOR_AGGREGATOR_MODULE)
+
+#define ACPI_PROCESSOR_AGGREGATOR_CLASS	"acpi_pad"
+#define ACPI_PROCESSOR_AGGREGATOR_DEVICE_NAME "Processor Aggregator"
+#define ACPI_PROCESSOR_AGGREGATOR_NOTIFY 0x80
+
+static int xen_acpi_pad_idle_cpus(int *num_cpus)
+{
+	int ret;
+
+	struct xen_platform_op op =3D {
+		.cmd =3D XENPF_core_parking,
+		.interface_version =3D XENPF_INTERFACE_VERSION,
+	};
+
+	/* set cpu nums expected to be idled */
+	op.u.core_parking.type =3D XEN_CORE_PARKING_SET;
+	op.u.core_parking.idle_nums =3D (uint32_t)*num_cpus;
+	ret =3D HYPERVISOR_dom0_op(&op);
+	if (ret)
+		return ret;
+
+	/*
+	 * get cpu nums actually be idled
+	 * cannot get it by using hypercall once (shared with _SET)
+	 * because of the characteristic of Xen continue_hypercall_on_cpu
+	 */
+	op.u.core_parking.type =3D XEN_CORE_PARKING_GET;
+	ret =3D HYPERVISOR_dom0_op(&op);
+	if (ret)
+		return ret;
+
+	*num_cpus =3D op.u.core_parking.idle_nums;
+	return 0;
+}
+
+/*
+ * Query firmware how many CPUs should be idle
+ * return -1 on failure
+ */
+static int xen_acpi_pad_pur(acpi_handle handle)
+{
+	struct acpi_buffer buffer =3D {ACPI_ALLOCATE_BUFFER, NULL};
+	union acpi_object *package;
+	int num =3D -1;
+
+	if (ACPI_FAILURE(acpi_evaluate_object(handle, "_PUR", NULL, &buffer)))
+		return num;
+
+	if (!buffer.length || !buffer.pointer)
+		return num;
+
+	package =3D buffer.pointer;
+
+	if (package->type =3D=3D ACPI_TYPE_PACKAGE &&
+		package->package.count =3D=3D 2 &&
+		package->package.elements[0].integer.value =3D=3D 1) /* rev 1 */
+
+		num =3D package->package.elements[1].integer.value;
+
+	kfree(buffer.pointer);
+	return num;
+}
+
+/* Notify firmware how many CPUs are idle */
+static void xen_acpi_pad_ost(acpi_handle handle, int stat,
+	uint32_t idle_cpus)
+{
+	union acpi_object params[3] =3D {
+		{.type =3D ACPI_TYPE_INTEGER,},
+		{.type =3D ACPI_TYPE_INTEGER,},
+		{.type =3D ACPI_TYPE_BUFFER,},
+	};
+	struct acpi_object_list arg_list =3D {3, params};
+
+	params[0].integer.value =3D ACPI_PROCESSOR_AGGREGATOR_NOTIFY;
+	params[1].integer.value =3D  stat;
+	params[2].buffer.length =3D 4;
+	params[2].buffer.pointer =3D (void *)&idle_cpus;
+	acpi_evaluate_object(handle, "_OST", &arg_list, NULL);
+}
+
+static void xen_acpi_pad_handle_notify(acpi_handle handle)
+{
+	int ret, num_cpus;
+
+	num_cpus =3D xen_acpi_pad_pur(handle);
+	if (num_cpus < 0)
+		return;
+
+	ret =3D xen_acpi_pad_idle_cpus(&num_cpus);
+	if (ret)
+		return;
+
+	xen_acpi_pad_ost(handle, 0, num_cpus);
+}
+
+static void xen_acpi_pad_notify(acpi_handle handle, u32 event,
+	void *data)
+{
+	switch (event) {
+	case ACPI_PROCESSOR_AGGREGATOR_NOTIFY:
+		xen_acpi_pad_handle_notify(handle);
+		break;
+	default:
+		pr_warn("Unsupported event [0x%x]\n", event);
+		break;
+	}
+}
+
+static int xen_acpi_pad_add(struct acpi_device *device)
+{
+	acpi_status status;
+
+	strcpy(acpi_device_name(device), ACPI_PROCESSOR_AGGREGATOR_DEVICE_NAME);
+	strcpy(acpi_device_class(device), ACPI_PROCESSOR_AGGREGATOR_CLASS);
+
+	status =3D acpi_install_notify_handler(device->handle,
+		 ACPI_DEVICE_NOTIFY, xen_acpi_pad_notify, device);
+	if (ACPI_FAILURE(status))
+		return -ENODEV;
+
+	return 0;
+}
+
+static const struct acpi_device_id pad_device_ids[] =3D {
+	{"ACPI000C", 0},
+	{"", 0},
+};
+
+static struct acpi_driver xen_acpi_pad_driver =3D {
+	.name =3D "processor_aggregator",
+	.class =3D ACPI_PROCESSOR_AGGREGATOR_CLASS,
+	.ids =3D pad_device_ids,
+	.ops =3D {
+		.add =3D xen_acpi_pad_add,
+	},
+};
+
+static int __init xen_acpi_pad_init(void)
+{
+	/* Only DOM0 is responsible for Xen acpi pad */
+	if (xen_initial_domain())
+		return acpi_bus_register_driver(&xen_acpi_pad_driver);
+
+	return -ENODEV;
+}
+subsys_initcall(xen_acpi_pad_init);
+
+#endif
diff --git a/include/xen/interface/platform.h b/include/xen/interface/platf=
orm.h
index 4755b5f..0f44376 100644
--- a/include/xen/interface/platform.h
+++ b/include/xen/interface/platform.h
@@ -324,6 +324,22 @@ struct xenpf_cpu_ol {
 };
 DEFINE_GUEST_HANDLE_STRUCT(xenpf_cpu_ol);
=20
+/*
+ * CMD 58 and 59 are reserved for cpu hotadd and memory hotadd,
+ * which already occupied at Xen hypervisor side.
+ */
+#define XENPF_core_parking	60
+struct xenpf_core_parking {
+	/* IN variables */
+#define XEN_CORE_PARKING_SET	1
+#define XEN_CORE_PARKING_GET	2
+	uint32_t type;
+	/* IN variables:  set cpu nums expected to be idled */
+	/* OUT variables: get cpu nums actually be idled */
+	uint32_t idle_nums;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xenpf_core_parking);
+
 struct xen_platform_op {
 	uint32_t cmd;
 	uint32_t interface_version; /* XENPF_INTERFACE_VERSION */
@@ -341,6 +357,7 @@ struct xen_platform_op {
 		struct xenpf_set_processor_pminfo set_pminfo;
 		struct xenpf_pcpuinfo          pcpu_info;
 		struct xenpf_cpu_ol            cpu_ol;
+		struct xenpf_core_parking      core_parking;
 		uint8_t                        pad[128];
 	} u;
 };
--=20
1.7.1

--_002_DE8DF0795D48FD4CA783C40EC829233537157FSHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="0001-Xen-acpi-pad-implement.patch"
Content-Description: 0001-Xen-acpi-pad-implement.patch
Content-Disposition: attachment;
	filename="0001-Xen-acpi-pad-implement.patch"; size=7390;
	creation-date="Thu, 25 Oct 2012 12:15:46 GMT";
	modification-date="Thu, 25 Oct 2012 20:07:22 GMT"
Content-Transfer-Encoding: base64

RnJvbSBmMjMzYWQwNmNmOTI0MTE2NjkzZDdkMzhiZTlhZTlkOGMxMWY4YTliIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4K
RGF0ZTogRnJpLCAyNiBPY3QgMjAxMiAwMjozMjo0OCArMDgwMApTdWJqZWN0OiBbUEFUQ0ggMS8y
XSBYZW4gYWNwaSBwYWQgaW1wbGVtZW50CgpQQUQgaXMgYWNwaSBQcm9jZXNzb3IgQWdncmVnYXRv
ciBEZXZpY2Ugd2hpY2ggcHJvdmlkZXMgYSBjb250cm9sIHBvaW50CnRoYXQgZW5hYmxlcyB0aGUg
cGxhdGZvcm0gdG8gcGVyZm9ybSBzcGVjaWZpYyBwcm9jZXNzb3IgY29uZmlndXJhdGlvbgphbmQg
Y29udHJvbCB0aGF0IGFwcGxpZXMgdG8gYWxsIHByb2Nlc3NvcnMgaW4gdGhlIHBsYXRmb3JtLgoK
VGhpcyBwYXRjaCBpcyB0byBpbXBsZW1lbnQgWGVuIGFjcGkgcGFkIGxvZ2ljLiBXaGVuIHJ1bm5p
bmcgdW5kZXIgWGVuCnZpcnQgcGxhdGZvcm0sIG5hdGl2ZSBwYWQgZHJpdmVyIHdvdWxkIG5vdCB3
b3JrLiBJbnN0ZWFkIFhlbiBwYWQgZHJpdmVyLAphIHNlbGYtY29udGFpbmVkIGFuZCB2ZXJ5IHRo
aW4gbG9naWMgbGV2ZWwsIHdvdWxkIHRha2Ugb3ZlciBhY3BpIHBhZCBzdGFmZi4KV2hlbiBhY3Bp
IHBhZCBub3RpZnkgT1NQTSwgeGVuIHBhZCBsb2dpYyBpbnRlcmNlcHQgYW5kIHBhcnNlIF9QVVIg
b2JqZWN0CmFuZCB0aGVuIGh5cGVyY2FsbCB0byBoeWVydmlzb3IgZm9yIHRoZSByZXN0IHdvcmss
IHNheSwgY29yZSBwYXJraW5nLgoKU2lnbmVkLW9mZi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25n
LmxpdUBpbnRlbC5jb20+Ci0tLQogZHJpdmVycy94ZW4vTWFrZWZpbGUgICAgICAgICAgICAgfCAg
ICAxICsKIGRyaXZlcnMveGVuL3hlbl9hY3BpX3BhZC5jICAgICAgIHwgIDE3MyArKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKwogaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3BsYXRm
b3JtLmggfCAgIDE3ICsrKysKIDMgZmlsZXMgY2hhbmdlZCwgMTkxIGluc2VydGlvbnMoKyksIDAg
ZGVsZXRpb25zKC0pCiBjcmVhdGUgbW9kZSAxMDA2NDQgZHJpdmVycy94ZW4veGVuX2FjcGlfcGFk
LmMKCmRpZmYgLS1naXQgYS9kcml2ZXJzL3hlbi9NYWtlZmlsZSBiL2RyaXZlcnMveGVuL01ha2Vm
aWxlCmluZGV4IDBlODYzNzAuLmEyYWY2MjIgMTAwNjQ0Ci0tLSBhL2RyaXZlcnMveGVuL01ha2Vm
aWxlCisrKyBiL2RyaXZlcnMveGVuL01ha2VmaWxlCkBAIC0yOSw2ICsyOSw3IEBAIG9iai0kKENP
TkZJR19YRU5fTUNFX0xPRykJCSs9IG1jZWxvZy5vCiBvYmotJChDT05GSUdfWEVOX1BDSURFVl9C
QUNLRU5EKQkrPSB4ZW4tcGNpYmFjay8KIG9iai0kKENPTkZJR19YRU5fUFJJVkNNRCkJCSs9IHhl
bi1wcml2Y21kLm8KIG9iai0kKENPTkZJR19YRU5fQUNQSV9QUk9DRVNTT1IpCSs9IHhlbi1hY3Bp
LXByb2Nlc3Nvci5vCitvYmotJChDT05GSUdfWEVOX0RPTTApCQkJKz0geGVuX2FjcGlfcGFkLm8K
IHhlbi1ldnRjaG4teQkJCQk6PSBldnRjaG4ubwogeGVuLWdudGRldi15CQkJCTo9IGdudGRldi5v
CiB4ZW4tZ250YWxsb2MteQkJCQk6PSBnbnRhbGxvYy5vCmRpZmYgLS1naXQgYS9kcml2ZXJzL3hl
bi94ZW5fYWNwaV9wYWQuYyBiL2RyaXZlcnMveGVuL3hlbl9hY3BpX3BhZC5jCm5ldyBmaWxlIG1v
ZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAuLmU3YjdkY2EKLS0tIC9kZXYvbnVsbAorKysgYi9kcml2
ZXJzL3hlbi94ZW5fYWNwaV9wYWQuYwpAQCAtMCwwICsxLDE3MyBAQAorLyoKKyAqIHhlbl9hY3Bp
X3BhZC5jIC0gWGVuIHBhZCBpbnRlcmZhY2UKKyAqCisgKiBDb3B5cmlnaHQgKGMpIDIwMTIsIElu
dGVsIENvcnBvcmF0aW9uLgorICogICAgQXV0aG9yOiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1
QGludGVsLmNvbT4KKyAqCisgKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNh
biByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeSBpdAorICogdW5kZXIgdGhlIHRlcm1zIGFu
ZCBjb25kaXRpb25zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSwKKyAqIHZlcnNp
b24gMiwgYXMgcHVibGlzaGVkIGJ5IHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24uCisgKgor
ICogVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3BlIGl0IHdpbGwgYmUgdXNl
ZnVsLCBidXQgV0lUSE9VVAorICogQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxp
ZWQgd2FycmFudHkgb2YgTUVSQ0hBTlRBQklMSVRZIG9yCisgKiBGSVRORVNTIEZPUiBBIFBBUlRJ
Q1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9yCisg
KiBtb3JlIGRldGFpbHMuCisgKi8KKworI2luY2x1ZGUgPGxpbnV4L2tlcm5lbC5oPgorI2luY2x1
ZGUgPGxpbnV4L3R5cGVzLmg+CisjaW5jbHVkZSA8YWNwaS9hY3BpX2J1cy5oPgorI2luY2x1ZGUg
PGFjcGkvYWNwaV9kcml2ZXJzLmg+CisjaW5jbHVkZSA8YXNtL3hlbi9oeXBlcmNhbGwuaD4KKwor
I2lmIGRlZmluZWQoQ09ORklHX0FDUElfUFJPQ0VTU09SX0FHR1JFR0FUT1IpIHx8IFwKKwkJZGVm
aW5lZChDT05GSUdfQUNQSV9QUk9DRVNTT1JfQUdHUkVHQVRPUl9NT0RVTEUpCisKKyNkZWZpbmUg
QUNQSV9QUk9DRVNTT1JfQUdHUkVHQVRPUl9DTEFTUwkiYWNwaV9wYWQiCisjZGVmaW5lIEFDUElf
UFJPQ0VTU09SX0FHR1JFR0FUT1JfREVWSUNFX05BTUUgIlByb2Nlc3NvciBBZ2dyZWdhdG9yIgor
I2RlZmluZSBBQ1BJX1BST0NFU1NPUl9BR0dSRUdBVE9SX05PVElGWSAweDgwCisKK3N0YXRpYyBp
bnQgeGVuX2FjcGlfcGFkX2lkbGVfY3B1cyhpbnQgKm51bV9jcHVzKQoreworCWludCByZXQ7CisK
KwlzdHJ1Y3QgeGVuX3BsYXRmb3JtX29wIG9wID0geworCQkuY21kID0gWEVOUEZfY29yZV9wYXJr
aW5nLAorCQkuaW50ZXJmYWNlX3ZlcnNpb24gPSBYRU5QRl9JTlRFUkZBQ0VfVkVSU0lPTiwKKwl9
OworCisJLyogc2V0IGNwdSBudW1zIGV4cGVjdGVkIHRvIGJlIGlkbGVkICovCisJb3AudS5jb3Jl
X3BhcmtpbmcudHlwZSA9IFhFTl9DT1JFX1BBUktJTkdfU0VUOworCW9wLnUuY29yZV9wYXJraW5n
LmlkbGVfbnVtcyA9ICh1aW50MzJfdCkqbnVtX2NwdXM7CisJcmV0ID0gSFlQRVJWSVNPUl9kb20w
X29wKCZvcCk7CisJaWYgKHJldCkKKwkJcmV0dXJuIHJldDsKKworCS8qCisJICogZ2V0IGNwdSBu
dW1zIGFjdHVhbGx5IGJlIGlkbGVkCisJICogY2Fubm90IGdldCBpdCBieSB1c2luZyBoeXBlcmNh
bGwgb25jZSAoc2hhcmVkIHdpdGggX1NFVCkKKwkgKiBiZWNhdXNlIG9mIHRoZSBjaGFyYWN0ZXJp
c3RpYyBvZiBYZW4gY29udGludWVfaHlwZXJjYWxsX29uX2NwdQorCSAqLworCW9wLnUuY29yZV9w
YXJraW5nLnR5cGUgPSBYRU5fQ09SRV9QQVJLSU5HX0dFVDsKKwlyZXQgPSBIWVBFUlZJU09SX2Rv
bTBfb3AoJm9wKTsKKwlpZiAocmV0KQorCQlyZXR1cm4gcmV0OworCisJKm51bV9jcHVzID0gb3Au
dS5jb3JlX3BhcmtpbmcuaWRsZV9udW1zOworCXJldHVybiAwOworfQorCisvKgorICogUXVlcnkg
ZmlybXdhcmUgaG93IG1hbnkgQ1BVcyBzaG91bGQgYmUgaWRsZQorICogcmV0dXJuIC0xIG9uIGZh
aWx1cmUKKyAqLworc3RhdGljIGludCB4ZW5fYWNwaV9wYWRfcHVyKGFjcGlfaGFuZGxlIGhhbmRs
ZSkKK3sKKwlzdHJ1Y3QgYWNwaV9idWZmZXIgYnVmZmVyID0ge0FDUElfQUxMT0NBVEVfQlVGRkVS
LCBOVUxMfTsKKwl1bmlvbiBhY3BpX29iamVjdCAqcGFja2FnZTsKKwlpbnQgbnVtID0gLTE7CisK
KwlpZiAoQUNQSV9GQUlMVVJFKGFjcGlfZXZhbHVhdGVfb2JqZWN0KGhhbmRsZSwgIl9QVVIiLCBO
VUxMLCAmYnVmZmVyKSkpCisJCXJldHVybiBudW07CisKKwlpZiAoIWJ1ZmZlci5sZW5ndGggfHwg
IWJ1ZmZlci5wb2ludGVyKQorCQlyZXR1cm4gbnVtOworCisJcGFja2FnZSA9IGJ1ZmZlci5wb2lu
dGVyOworCisJaWYgKHBhY2thZ2UtPnR5cGUgPT0gQUNQSV9UWVBFX1BBQ0tBR0UgJiYKKwkJcGFj
a2FnZS0+cGFja2FnZS5jb3VudCA9PSAyICYmCisJCXBhY2thZ2UtPnBhY2thZ2UuZWxlbWVudHNb
MF0uaW50ZWdlci52YWx1ZSA9PSAxKSAvKiByZXYgMSAqLworCisJCW51bSA9IHBhY2thZ2UtPnBh
Y2thZ2UuZWxlbWVudHNbMV0uaW50ZWdlci52YWx1ZTsKKworCWtmcmVlKGJ1ZmZlci5wb2ludGVy
KTsKKwlyZXR1cm4gbnVtOworfQorCisvKiBOb3RpZnkgZmlybXdhcmUgaG93IG1hbnkgQ1BVcyBh
cmUgaWRsZSAqLworc3RhdGljIHZvaWQgeGVuX2FjcGlfcGFkX29zdChhY3BpX2hhbmRsZSBoYW5k
bGUsIGludCBzdGF0LAorCXVpbnQzMl90IGlkbGVfY3B1cykKK3sKKwl1bmlvbiBhY3BpX29iamVj
dCBwYXJhbXNbM10gPSB7CisJCXsudHlwZSA9IEFDUElfVFlQRV9JTlRFR0VSLH0sCisJCXsudHlw
ZSA9IEFDUElfVFlQRV9JTlRFR0VSLH0sCisJCXsudHlwZSA9IEFDUElfVFlQRV9CVUZGRVIsfSwK
Kwl9OworCXN0cnVjdCBhY3BpX29iamVjdF9saXN0IGFyZ19saXN0ID0gezMsIHBhcmFtc307CisK
KwlwYXJhbXNbMF0uaW50ZWdlci52YWx1ZSA9IEFDUElfUFJPQ0VTU09SX0FHR1JFR0FUT1JfTk9U
SUZZOworCXBhcmFtc1sxXS5pbnRlZ2VyLnZhbHVlID0gIHN0YXQ7CisJcGFyYW1zWzJdLmJ1ZmZl
ci5sZW5ndGggPSA0OworCXBhcmFtc1syXS5idWZmZXIucG9pbnRlciA9ICh2b2lkICopJmlkbGVf
Y3B1czsKKwlhY3BpX2V2YWx1YXRlX29iamVjdChoYW5kbGUsICJfT1NUIiwgJmFyZ19saXN0LCBO
VUxMKTsKK30KKworc3RhdGljIHZvaWQgeGVuX2FjcGlfcGFkX2hhbmRsZV9ub3RpZnkoYWNwaV9o
YW5kbGUgaGFuZGxlKQoreworCWludCByZXQsIG51bV9jcHVzOworCisJbnVtX2NwdXMgPSB4ZW5f
YWNwaV9wYWRfcHVyKGhhbmRsZSk7CisJaWYgKG51bV9jcHVzIDwgMCkKKwkJcmV0dXJuOworCisJ
cmV0ID0geGVuX2FjcGlfcGFkX2lkbGVfY3B1cygmbnVtX2NwdXMpOworCWlmIChyZXQpCisJCXJl
dHVybjsKKworCXhlbl9hY3BpX3BhZF9vc3QoaGFuZGxlLCAwLCBudW1fY3B1cyk7Cit9CisKK3N0
YXRpYyB2b2lkIHhlbl9hY3BpX3BhZF9ub3RpZnkoYWNwaV9oYW5kbGUgaGFuZGxlLCB1MzIgZXZl
bnQsCisJdm9pZCAqZGF0YSkKK3sKKwlzd2l0Y2ggKGV2ZW50KSB7CisJY2FzZSBBQ1BJX1BST0NF
U1NPUl9BR0dSRUdBVE9SX05PVElGWToKKwkJeGVuX2FjcGlfcGFkX2hhbmRsZV9ub3RpZnkoaGFu
ZGxlKTsKKwkJYnJlYWs7CisJZGVmYXVsdDoKKwkJcHJfd2FybigiVW5zdXBwb3J0ZWQgZXZlbnQg
WzB4JXhdXG4iLCBldmVudCk7CisJCWJyZWFrOworCX0KK30KKworc3RhdGljIGludCB4ZW5fYWNw
aV9wYWRfYWRkKHN0cnVjdCBhY3BpX2RldmljZSAqZGV2aWNlKQoreworCWFjcGlfc3RhdHVzIHN0
YXR1czsKKworCXN0cmNweShhY3BpX2RldmljZV9uYW1lKGRldmljZSksIEFDUElfUFJPQ0VTU09S
X0FHR1JFR0FUT1JfREVWSUNFX05BTUUpOworCXN0cmNweShhY3BpX2RldmljZV9jbGFzcyhkZXZp
Y2UpLCBBQ1BJX1BST0NFU1NPUl9BR0dSRUdBVE9SX0NMQVNTKTsKKworCXN0YXR1cyA9IGFjcGlf
aW5zdGFsbF9ub3RpZnlfaGFuZGxlcihkZXZpY2UtPmhhbmRsZSwKKwkJIEFDUElfREVWSUNFX05P
VElGWSwgeGVuX2FjcGlfcGFkX25vdGlmeSwgZGV2aWNlKTsKKwlpZiAoQUNQSV9GQUlMVVJFKHN0
YXR1cykpCisJCXJldHVybiAtRU5PREVWOworCisJcmV0dXJuIDA7Cit9CisKK3N0YXRpYyBjb25z
dCBzdHJ1Y3QgYWNwaV9kZXZpY2VfaWQgcGFkX2RldmljZV9pZHNbXSA9IHsKKwl7IkFDUEkwMDBD
IiwgMH0sCisJeyIiLCAwfSwKK307CisKK3N0YXRpYyBzdHJ1Y3QgYWNwaV9kcml2ZXIgeGVuX2Fj
cGlfcGFkX2RyaXZlciA9IHsKKwkubmFtZSA9ICJwcm9jZXNzb3JfYWdncmVnYXRvciIsCisJLmNs
YXNzID0gQUNQSV9QUk9DRVNTT1JfQUdHUkVHQVRPUl9DTEFTUywKKwkuaWRzID0gcGFkX2Rldmlj
ZV9pZHMsCisJLm9wcyA9IHsKKwkJLmFkZCA9IHhlbl9hY3BpX3BhZF9hZGQsCisJfSwKK307CisK
K3N0YXRpYyBpbnQgX19pbml0IHhlbl9hY3BpX3BhZF9pbml0KHZvaWQpCit7CisJLyogT25seSBE
T00wIGlzIHJlc3BvbnNpYmxlIGZvciBYZW4gYWNwaSBwYWQgKi8KKwlpZiAoeGVuX2luaXRpYWxf
ZG9tYWluKCkpCisJCXJldHVybiBhY3BpX2J1c19yZWdpc3Rlcl9kcml2ZXIoJnhlbl9hY3BpX3Bh
ZF9kcml2ZXIpOworCisJcmV0dXJuIC1FTk9ERVY7Cit9CitzdWJzeXNfaW5pdGNhbGwoeGVuX2Fj
cGlfcGFkX2luaXQpOworCisjZW5kaWYKZGlmZiAtLWdpdCBhL2luY2x1ZGUveGVuL2ludGVyZmFj
ZS9wbGF0Zm9ybS5oIGIvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3BsYXRmb3JtLmgKaW5kZXggNDc1
NWI1Zi4uMGY0NDM3NiAxMDA2NDQKLS0tIGEvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3BsYXRmb3Jt
LmgKKysrIGIvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3BsYXRmb3JtLmgKQEAgLTMyNCw2ICszMjQs
MjIgQEAgc3RydWN0IHhlbnBmX2NwdV9vbCB7CiB9OwogREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJV
Q1QoeGVucGZfY3B1X29sKTsKIAorLyoKKyAqIENNRCA1OCBhbmQgNTkgYXJlIHJlc2VydmVkIGZv
ciBjcHUgaG90YWRkIGFuZCBtZW1vcnkgaG90YWRkLAorICogd2hpY2ggYWxyZWFkeSBvY2N1cGll
ZCBhdCBYZW4gaHlwZXJ2aXNvciBzaWRlLgorICovCisjZGVmaW5lIFhFTlBGX2NvcmVfcGFya2lu
Zwk2MAorc3RydWN0IHhlbnBmX2NvcmVfcGFya2luZyB7CisJLyogSU4gdmFyaWFibGVzICovCisj
ZGVmaW5lIFhFTl9DT1JFX1BBUktJTkdfU0VUCTEKKyNkZWZpbmUgWEVOX0NPUkVfUEFSS0lOR19H
RVQJMgorCXVpbnQzMl90IHR5cGU7CisJLyogSU4gdmFyaWFibGVzOiAgc2V0IGNwdSBudW1zIGV4
cGVjdGVkIHRvIGJlIGlkbGVkICovCisJLyogT1VUIHZhcmlhYmxlczogZ2V0IGNwdSBudW1zIGFj
dHVhbGx5IGJlIGlkbGVkICovCisJdWludDMyX3QgaWRsZV9udW1zOworfTsKK0RFRklORV9HVUVT
VF9IQU5ETEVfU1RSVUNUKHhlbnBmX2NvcmVfcGFya2luZyk7CisKIHN0cnVjdCB4ZW5fcGxhdGZv
cm1fb3AgewogCXVpbnQzMl90IGNtZDsKIAl1aW50MzJfdCBpbnRlcmZhY2VfdmVyc2lvbjsgLyog
WEVOUEZfSU5URVJGQUNFX1ZFUlNJT04gKi8KQEAgLTM0MSw2ICszNTcsNyBAQCBzdHJ1Y3QgeGVu
X3BsYXRmb3JtX29wIHsKIAkJc3RydWN0IHhlbnBmX3NldF9wcm9jZXNzb3JfcG1pbmZvIHNldF9w
bWluZm87CiAJCXN0cnVjdCB4ZW5wZl9wY3B1aW5mbyAgICAgICAgICBwY3B1X2luZm87CiAJCXN0
cnVjdCB4ZW5wZl9jcHVfb2wgICAgICAgICAgICBjcHVfb2w7CisJCXN0cnVjdCB4ZW5wZl9jb3Jl
X3BhcmtpbmcgICAgICBjb3JlX3Bhcmtpbmc7CiAJCXVpbnQ4X3QgICAgICAgICAgICAgICAgICAg
ICAgICBwYWRbMTI4XTsKIAl9IHU7CiB9OwotLSAKMS43LjEKCg==

--_002_DE8DF0795D48FD4CA783C40EC829233537157FSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC829233537157FSHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Thu Oct 25 12:20:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 12:20:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRMQ0-00027s-25; Thu, 25 Oct 2012 12:20:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRMPy-00027h-PJ
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 12:20:11 +0000
Received: from [85.158.137.99:35756] by server-10.bemta-3.messagelabs.com id
	F7/F7-00901-A7E29805; Thu, 25 Oct 2012 12:20:10 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1351167607!20634211!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzU5MzUw\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25411 invoked from network); 25 Oct 2012 12:20:08 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-15.tower-217.messagelabs.com with SMTP;
	25 Oct 2012 12:20:08 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 25 Oct 2012 05:19:37 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,646,1344236400"; 
	d="scan'208,223";a="232379272"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by orsmga002.jf.intel.com with ESMTP; 25 Oct 2012 05:20:03 -0700
Received: from fmsmsx151.amr.corp.intel.com (10.19.17.220) by
	FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 25 Oct 2012 05:20:02 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX151.amr.corp.intel.com (10.19.17.220) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 25 Oct 2012 05:20:02 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.186]) with mapi id
	14.01.0355.002; Thu, 25 Oct 2012 20:20:00 +0800
From: "Liu, Jinsong" 
To: Konrad Rzeszutek Wilk ,
	"linux-kernel@vger.kernel.org" ,
	"xen-devel@lists.xensource.com" 
Thread-Topic: [PATCH 1/2] Xen acpi pad implement
Thread-Index: Ac2yqwziy4ng7bX0TLqjDy8/5OpTbg==
Date: Thu, 25 Oct 2012 12:19:59 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC829233537157FSHSMSX101ccrcorpi_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 1/2] Xen acpi pad implement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC829233537157FSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From f233ad06cf924116693d7d38be9ae9d8c11f8a9b Mon Sep 17 00:00:00 2001
From: Liu, Jinsong 
Date: Fri, 26 Oct 2012 02:32:48 +0800
Subject: [PATCH 1/2] Xen acpi pad implement

PAD is acpi Processor Aggregator Device which provides a control point
that enables the platform to perform specific processor configuration
and control that applies to all processors in the platform.

This patch is to implement Xen acpi pad logic. When running under Xen
virt platform, native pad driver would not work. Instead Xen pad driver,
a self-contained and very thin logic level, would take over acpi pad staff.
When acpi pad notify OSPM, xen pad logic intercept and parse _PUR object
and then hypercall to hyervisor for the rest work, say, core parking.

Signed-off-by: Liu, Jinsong 
---
 drivers/xen/Makefile             |    1 +
 drivers/xen/xen_acpi_pad.c       |  173 ++++++++++++++++++++++++++++++++++=
++++
 include/xen/interface/platform.h |   17 ++++
 3 files changed, 191 insertions(+), 0 deletions(-)
 create mode 100644 drivers/xen/xen_acpi_pad.c

diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 0e86370..a2af622 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_XEN_MCE_LOG)		+=3D mcelog.o
 obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+=3D xen-pciback/
 obj-$(CONFIG_XEN_PRIVCMD)		+=3D xen-privcmd.o
 obj-$(CONFIG_XEN_ACPI_PROCESSOR)	+=3D xen-acpi-processor.o
+obj-$(CONFIG_XEN_DOM0)			+=3D xen_acpi_pad.o
 xen-evtchn-y				:=3D evtchn.o
 xen-gntdev-y				:=3D gntdev.o
 xen-gntalloc-y				:=3D gntalloc.o
diff --git a/drivers/xen/xen_acpi_pad.c b/drivers/xen/xen_acpi_pad.c
new file mode 100644
index 0000000..e7b7dca
--- /dev/null
+++ b/drivers/xen/xen_acpi_pad.c
@@ -0,0 +1,173 @@
+/*
+ * xen_acpi_pad.c - Xen pad interface
+ *
+ * Copyright (c) 2012, Intel Corporation.
+ *    Author: Liu, Jinsong 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License f=
or
+ * more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#if defined(CONFIG_ACPI_PROCESSOR_AGGREGATOR) || \
+		defined(CONFIG_ACPI_PROCESSOR_AGGREGATOR_MODULE)
+
+#define ACPI_PROCESSOR_AGGREGATOR_CLASS	"acpi_pad"
+#define ACPI_PROCESSOR_AGGREGATOR_DEVICE_NAME "Processor Aggregator"
+#define ACPI_PROCESSOR_AGGREGATOR_NOTIFY 0x80
+
+static int xen_acpi_pad_idle_cpus(int *num_cpus)
+{
+	int ret;
+
+	struct xen_platform_op op =3D {
+		.cmd =3D XENPF_core_parking,
+		.interface_version =3D XENPF_INTERFACE_VERSION,
+	};
+
+	/* set cpu nums expected to be idled */
+	op.u.core_parking.type =3D XEN_CORE_PARKING_SET;
+	op.u.core_parking.idle_nums =3D (uint32_t)*num_cpus;
+	ret =3D HYPERVISOR_dom0_op(&op);
+	if (ret)
+		return ret;
+
+	/*
+	 * get cpu nums actually be idled
+	 * cannot get it by using hypercall once (shared with _SET)
+	 * because of the characteristic of Xen continue_hypercall_on_cpu
+	 */
+	op.u.core_parking.type =3D XEN_CORE_PARKING_GET;
+	ret =3D HYPERVISOR_dom0_op(&op);
+	if (ret)
+		return ret;
+
+	*num_cpus =3D op.u.core_parking.idle_nums;
+	return 0;
+}
+
+/*
+ * Query firmware how many CPUs should be idle
+ * return -1 on failure
+ */
+static int xen_acpi_pad_pur(acpi_handle handle)
+{
+	struct acpi_buffer buffer =3D {ACPI_ALLOCATE_BUFFER, NULL};
+	union acpi_object *package;
+	int num =3D -1;
+
+	if (ACPI_FAILURE(acpi_evaluate_object(handle, "_PUR", NULL, &buffer)))
+		return num;
+
+	if (!buffer.length || !buffer.pointer)
+		return num;
+
+	package =3D buffer.pointer;
+
+	if (package->type =3D=3D ACPI_TYPE_PACKAGE &&
+		package->package.count =3D=3D 2 &&
+		package->package.elements[0].integer.value =3D=3D 1) /* rev 1 */
+
+		num =3D package->package.elements[1].integer.value;
+
+	kfree(buffer.pointer);
+	return num;
+}
+
+/* Notify firmware how many CPUs are idle */
+static void xen_acpi_pad_ost(acpi_handle handle, int stat,
+	uint32_t idle_cpus)
+{
+	union acpi_object params[3] =3D {
+		{.type =3D ACPI_TYPE_INTEGER,},
+		{.type =3D ACPI_TYPE_INTEGER,},
+		{.type =3D ACPI_TYPE_BUFFER,},
+	};
+	struct acpi_object_list arg_list =3D {3, params};
+
+	params[0].integer.value =3D ACPI_PROCESSOR_AGGREGATOR_NOTIFY;
+	params[1].integer.value =3D  stat;
+	params[2].buffer.length =3D 4;
+	params[2].buffer.pointer =3D (void *)&idle_cpus;
+	acpi_evaluate_object(handle, "_OST", &arg_list, NULL);
+}
+
+static void xen_acpi_pad_handle_notify(acpi_handle handle)
+{
+	int ret, num_cpus;
+
+	num_cpus =3D xen_acpi_pad_pur(handle);
+	if (num_cpus < 0)
+		return;
+
+	ret =3D xen_acpi_pad_idle_cpus(&num_cpus);
+	if (ret)
+		return;
+
+	xen_acpi_pad_ost(handle, 0, num_cpus);
+}
+
+static void xen_acpi_pad_notify(acpi_handle handle, u32 event,
+	void *data)
+{
+	switch (event) {
+	case ACPI_PROCESSOR_AGGREGATOR_NOTIFY:
+		xen_acpi_pad_handle_notify(handle);
+		break;
+	default:
+		pr_warn("Unsupported event [0x%x]\n", event);
+		break;
+	}
+}
+
+static int xen_acpi_pad_add(struct acpi_device *device)
+{
+	acpi_status status;
+
+	strcpy(acpi_device_name(device), ACPI_PROCESSOR_AGGREGATOR_DEVICE_NAME);
+	strcpy(acpi_device_class(device), ACPI_PROCESSOR_AGGREGATOR_CLASS);
+
+	status =3D acpi_install_notify_handler(device->handle,
+		 ACPI_DEVICE_NOTIFY, xen_acpi_pad_notify, device);
+	if (ACPI_FAILURE(status))
+		return -ENODEV;
+
+	return 0;
+}
+
+static const struct acpi_device_id pad_device_ids[] =3D {
+	{"ACPI000C", 0},
+	{"", 0},
+};
+
+static struct acpi_driver xen_acpi_pad_driver =3D {
+	.name =3D "processor_aggregator",
+	.class =3D ACPI_PROCESSOR_AGGREGATOR_CLASS,
+	.ids =3D pad_device_ids,
+	.ops =3D {
+		.add =3D xen_acpi_pad_add,
+	},
+};
+
+static int __init xen_acpi_pad_init(void)
+{
+	/* Only DOM0 is responsible for Xen acpi pad */
+	if (xen_initial_domain())
+		return acpi_bus_register_driver(&xen_acpi_pad_driver);
+
+	return -ENODEV;
+}
+subsys_initcall(xen_acpi_pad_init);
+
+#endif
diff --git a/include/xen/interface/platform.h b/include/xen/interface/platf=
orm.h
index 4755b5f..0f44376 100644
--- a/include/xen/interface/platform.h
+++ b/include/xen/interface/platform.h
@@ -324,6 +324,22 @@ struct xenpf_cpu_ol {
 };
 DEFINE_GUEST_HANDLE_STRUCT(xenpf_cpu_ol);
=20
+/*
+ * CMD 58 and 59 are reserved for cpu hotadd and memory hotadd,
+ * which already occupied at Xen hypervisor side.
+ */
+#define XENPF_core_parking	60
+struct xenpf_core_parking {
+	/* IN variables */
+#define XEN_CORE_PARKING_SET	1
+#define XEN_CORE_PARKING_GET	2
+	uint32_t type;
+	/* IN variables:  set cpu nums expected to be idled */
+	/* OUT variables: get cpu nums actually be idled */
+	uint32_t idle_nums;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xenpf_core_parking);
+
 struct xen_platform_op {
 	uint32_t cmd;
 	uint32_t interface_version; /* XENPF_INTERFACE_VERSION */
@@ -341,6 +357,7 @@ struct xen_platform_op {
 		struct xenpf_set_processor_pminfo set_pminfo;
 		struct xenpf_pcpuinfo          pcpu_info;
 		struct xenpf_cpu_ol            cpu_ol;
+		struct xenpf_core_parking      core_parking;
 		uint8_t                        pad[128];
 	} u;
 };
--=20
1.7.1

--_002_DE8DF0795D48FD4CA783C40EC829233537157FSHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="0001-Xen-acpi-pad-implement.patch"
Content-Description: 0001-Xen-acpi-pad-implement.patch
Content-Disposition: attachment;
	filename="0001-Xen-acpi-pad-implement.patch"; size=7390;
	creation-date="Thu, 25 Oct 2012 12:15:46 GMT";
	modification-date="Thu, 25 Oct 2012 20:07:22 GMT"
Content-Transfer-Encoding: base64

RnJvbSBmMjMzYWQwNmNmOTI0MTE2NjkzZDdkMzhiZTlhZTlkOGMxMWY4YTliIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4K
RGF0ZTogRnJpLCAyNiBPY3QgMjAxMiAwMjozMjo0OCArMDgwMApTdWJqZWN0OiBbUEFUQ0ggMS8y
XSBYZW4gYWNwaSBwYWQgaW1wbGVtZW50CgpQQUQgaXMgYWNwaSBQcm9jZXNzb3IgQWdncmVnYXRv
ciBEZXZpY2Ugd2hpY2ggcHJvdmlkZXMgYSBjb250cm9sIHBvaW50CnRoYXQgZW5hYmxlcyB0aGUg
cGxhdGZvcm0gdG8gcGVyZm9ybSBzcGVjaWZpYyBwcm9jZXNzb3IgY29uZmlndXJhdGlvbgphbmQg
Y29udHJvbCB0aGF0IGFwcGxpZXMgdG8gYWxsIHByb2Nlc3NvcnMgaW4gdGhlIHBsYXRmb3JtLgoK
VGhpcyBwYXRjaCBpcyB0byBpbXBsZW1lbnQgWGVuIGFjcGkgcGFkIGxvZ2ljLiBXaGVuIHJ1bm5p
bmcgdW5kZXIgWGVuCnZpcnQgcGxhdGZvcm0sIG5hdGl2ZSBwYWQgZHJpdmVyIHdvdWxkIG5vdCB3
b3JrLiBJbnN0ZWFkIFhlbiBwYWQgZHJpdmVyLAphIHNlbGYtY29udGFpbmVkIGFuZCB2ZXJ5IHRo
aW4gbG9naWMgbGV2ZWwsIHdvdWxkIHRha2Ugb3ZlciBhY3BpIHBhZCBzdGFmZi4KV2hlbiBhY3Bp
IHBhZCBub3RpZnkgT1NQTSwgeGVuIHBhZCBsb2dpYyBpbnRlcmNlcHQgYW5kIHBhcnNlIF9QVVIg
b2JqZWN0CmFuZCB0aGVuIGh5cGVyY2FsbCB0byBoeWVydmlzb3IgZm9yIHRoZSByZXN0IHdvcmss
IHNheSwgY29yZSBwYXJraW5nLgoKU2lnbmVkLW9mZi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25n
LmxpdUBpbnRlbC5jb20+Ci0tLQogZHJpdmVycy94ZW4vTWFrZWZpbGUgICAgICAgICAgICAgfCAg
ICAxICsKIGRyaXZlcnMveGVuL3hlbl9hY3BpX3BhZC5jICAgICAgIHwgIDE3MyArKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKwogaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3BsYXRm
b3JtLmggfCAgIDE3ICsrKysKIDMgZmlsZXMgY2hhbmdlZCwgMTkxIGluc2VydGlvbnMoKyksIDAg
ZGVsZXRpb25zKC0pCiBjcmVhdGUgbW9kZSAxMDA2NDQgZHJpdmVycy94ZW4veGVuX2FjcGlfcGFk
LmMKCmRpZmYgLS1naXQgYS9kcml2ZXJzL3hlbi9NYWtlZmlsZSBiL2RyaXZlcnMveGVuL01ha2Vm
aWxlCmluZGV4IDBlODYzNzAuLmEyYWY2MjIgMTAwNjQ0Ci0tLSBhL2RyaXZlcnMveGVuL01ha2Vm
aWxlCisrKyBiL2RyaXZlcnMveGVuL01ha2VmaWxlCkBAIC0yOSw2ICsyOSw3IEBAIG9iai0kKENP
TkZJR19YRU5fTUNFX0xPRykJCSs9IG1jZWxvZy5vCiBvYmotJChDT05GSUdfWEVOX1BDSURFVl9C
QUNLRU5EKQkrPSB4ZW4tcGNpYmFjay8KIG9iai0kKENPTkZJR19YRU5fUFJJVkNNRCkJCSs9IHhl
bi1wcml2Y21kLm8KIG9iai0kKENPTkZJR19YRU5fQUNQSV9QUk9DRVNTT1IpCSs9IHhlbi1hY3Bp
LXByb2Nlc3Nvci5vCitvYmotJChDT05GSUdfWEVOX0RPTTApCQkJKz0geGVuX2FjcGlfcGFkLm8K
IHhlbi1ldnRjaG4teQkJCQk6PSBldnRjaG4ubwogeGVuLWdudGRldi15CQkJCTo9IGdudGRldi5v
CiB4ZW4tZ250YWxsb2MteQkJCQk6PSBnbnRhbGxvYy5vCmRpZmYgLS1naXQgYS9kcml2ZXJzL3hl
bi94ZW5fYWNwaV9wYWQuYyBiL2RyaXZlcnMveGVuL3hlbl9hY3BpX3BhZC5jCm5ldyBmaWxlIG1v
ZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAuLmU3YjdkY2EKLS0tIC9kZXYvbnVsbAorKysgYi9kcml2
ZXJzL3hlbi94ZW5fYWNwaV9wYWQuYwpAQCAtMCwwICsxLDE3MyBAQAorLyoKKyAqIHhlbl9hY3Bp
X3BhZC5jIC0gWGVuIHBhZCBpbnRlcmZhY2UKKyAqCisgKiBDb3B5cmlnaHQgKGMpIDIwMTIsIElu
dGVsIENvcnBvcmF0aW9uLgorICogICAgQXV0aG9yOiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1
QGludGVsLmNvbT4KKyAqCisgKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNh
biByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeSBpdAorICogdW5kZXIgdGhlIHRlcm1zIGFu
ZCBjb25kaXRpb25zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSwKKyAqIHZlcnNp
b24gMiwgYXMgcHVibGlzaGVkIGJ5IHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24uCisgKgor
ICogVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3BlIGl0IHdpbGwgYmUgdXNl
ZnVsLCBidXQgV0lUSE9VVAorICogQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxp
ZWQgd2FycmFudHkgb2YgTUVSQ0hBTlRBQklMSVRZIG9yCisgKiBGSVRORVNTIEZPUiBBIFBBUlRJ
Q1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9yCisg
KiBtb3JlIGRldGFpbHMuCisgKi8KKworI2luY2x1ZGUgPGxpbnV4L2tlcm5lbC5oPgorI2luY2x1
ZGUgPGxpbnV4L3R5cGVzLmg+CisjaW5jbHVkZSA8YWNwaS9hY3BpX2J1cy5oPgorI2luY2x1ZGUg
PGFjcGkvYWNwaV9kcml2ZXJzLmg+CisjaW5jbHVkZSA8YXNtL3hlbi9oeXBlcmNhbGwuaD4KKwor
I2lmIGRlZmluZWQoQ09ORklHX0FDUElfUFJPQ0VTU09SX0FHR1JFR0FUT1IpIHx8IFwKKwkJZGVm
aW5lZChDT05GSUdfQUNQSV9QUk9DRVNTT1JfQUdHUkVHQVRPUl9NT0RVTEUpCisKKyNkZWZpbmUg
QUNQSV9QUk9DRVNTT1JfQUdHUkVHQVRPUl9DTEFTUwkiYWNwaV9wYWQiCisjZGVmaW5lIEFDUElf
UFJPQ0VTU09SX0FHR1JFR0FUT1JfREVWSUNFX05BTUUgIlByb2Nlc3NvciBBZ2dyZWdhdG9yIgor
I2RlZmluZSBBQ1BJX1BST0NFU1NPUl9BR0dSRUdBVE9SX05PVElGWSAweDgwCisKK3N0YXRpYyBp
bnQgeGVuX2FjcGlfcGFkX2lkbGVfY3B1cyhpbnQgKm51bV9jcHVzKQoreworCWludCByZXQ7CisK
KwlzdHJ1Y3QgeGVuX3BsYXRmb3JtX29wIG9wID0geworCQkuY21kID0gWEVOUEZfY29yZV9wYXJr
aW5nLAorCQkuaW50ZXJmYWNlX3ZlcnNpb24gPSBYRU5QRl9JTlRFUkZBQ0VfVkVSU0lPTiwKKwl9
OworCisJLyogc2V0IGNwdSBudW1zIGV4cGVjdGVkIHRvIGJlIGlkbGVkICovCisJb3AudS5jb3Jl
X3BhcmtpbmcudHlwZSA9IFhFTl9DT1JFX1BBUktJTkdfU0VUOworCW9wLnUuY29yZV9wYXJraW5n
LmlkbGVfbnVtcyA9ICh1aW50MzJfdCkqbnVtX2NwdXM7CisJcmV0ID0gSFlQRVJWSVNPUl9kb20w
X29wKCZvcCk7CisJaWYgKHJldCkKKwkJcmV0dXJuIHJldDsKKworCS8qCisJICogZ2V0IGNwdSBu
dW1zIGFjdHVhbGx5IGJlIGlkbGVkCisJICogY2Fubm90IGdldCBpdCBieSB1c2luZyBoeXBlcmNh
bGwgb25jZSAoc2hhcmVkIHdpdGggX1NFVCkKKwkgKiBiZWNhdXNlIG9mIHRoZSBjaGFyYWN0ZXJp
c3RpYyBvZiBYZW4gY29udGludWVfaHlwZXJjYWxsX29uX2NwdQorCSAqLworCW9wLnUuY29yZV9w
YXJraW5nLnR5cGUgPSBYRU5fQ09SRV9QQVJLSU5HX0dFVDsKKwlyZXQgPSBIWVBFUlZJU09SX2Rv
bTBfb3AoJm9wKTsKKwlpZiAocmV0KQorCQlyZXR1cm4gcmV0OworCisJKm51bV9jcHVzID0gb3Au
dS5jb3JlX3BhcmtpbmcuaWRsZV9udW1zOworCXJldHVybiAwOworfQorCisvKgorICogUXVlcnkg
ZmlybXdhcmUgaG93IG1hbnkgQ1BVcyBzaG91bGQgYmUgaWRsZQorICogcmV0dXJuIC0xIG9uIGZh
aWx1cmUKKyAqLworc3RhdGljIGludCB4ZW5fYWNwaV9wYWRfcHVyKGFjcGlfaGFuZGxlIGhhbmRs
ZSkKK3sKKwlzdHJ1Y3QgYWNwaV9idWZmZXIgYnVmZmVyID0ge0FDUElfQUxMT0NBVEVfQlVGRkVS
LCBOVUxMfTsKKwl1bmlvbiBhY3BpX29iamVjdCAqcGFja2FnZTsKKwlpbnQgbnVtID0gLTE7CisK
KwlpZiAoQUNQSV9GQUlMVVJFKGFjcGlfZXZhbHVhdGVfb2JqZWN0KGhhbmRsZSwgIl9QVVIiLCBO
VUxMLCAmYnVmZmVyKSkpCisJCXJldHVybiBudW07CisKKwlpZiAoIWJ1ZmZlci5sZW5ndGggfHwg
IWJ1ZmZlci5wb2ludGVyKQorCQlyZXR1cm4gbnVtOworCisJcGFja2FnZSA9IGJ1ZmZlci5wb2lu
dGVyOworCisJaWYgKHBhY2thZ2UtPnR5cGUgPT0gQUNQSV9UWVBFX1BBQ0tBR0UgJiYKKwkJcGFj
a2FnZS0+cGFja2FnZS5jb3VudCA9PSAyICYmCisJCXBhY2thZ2UtPnBhY2thZ2UuZWxlbWVudHNb
MF0uaW50ZWdlci52YWx1ZSA9PSAxKSAvKiByZXYgMSAqLworCisJCW51bSA9IHBhY2thZ2UtPnBh
Y2thZ2UuZWxlbWVudHNbMV0uaW50ZWdlci52YWx1ZTsKKworCWtmcmVlKGJ1ZmZlci5wb2ludGVy
KTsKKwlyZXR1cm4gbnVtOworfQorCisvKiBOb3RpZnkgZmlybXdhcmUgaG93IG1hbnkgQ1BVcyBh
cmUgaWRsZSAqLworc3RhdGljIHZvaWQgeGVuX2FjcGlfcGFkX29zdChhY3BpX2hhbmRsZSBoYW5k
bGUsIGludCBzdGF0LAorCXVpbnQzMl90IGlkbGVfY3B1cykKK3sKKwl1bmlvbiBhY3BpX29iamVj
dCBwYXJhbXNbM10gPSB7CisJCXsudHlwZSA9IEFDUElfVFlQRV9JTlRFR0VSLH0sCisJCXsudHlw
ZSA9IEFDUElfVFlQRV9JTlRFR0VSLH0sCisJCXsudHlwZSA9IEFDUElfVFlQRV9CVUZGRVIsfSwK
Kwl9OworCXN0cnVjdCBhY3BpX29iamVjdF9saXN0IGFyZ19saXN0ID0gezMsIHBhcmFtc307CisK
KwlwYXJhbXNbMF0uaW50ZWdlci52YWx1ZSA9IEFDUElfUFJPQ0VTU09SX0FHR1JFR0FUT1JfTk9U
SUZZOworCXBhcmFtc1sxXS5pbnRlZ2VyLnZhbHVlID0gIHN0YXQ7CisJcGFyYW1zWzJdLmJ1ZmZl
ci5sZW5ndGggPSA0OworCXBhcmFtc1syXS5idWZmZXIucG9pbnRlciA9ICh2b2lkICopJmlkbGVf
Y3B1czsKKwlhY3BpX2V2YWx1YXRlX29iamVjdChoYW5kbGUsICJfT1NUIiwgJmFyZ19saXN0LCBO
VUxMKTsKK30KKworc3RhdGljIHZvaWQgeGVuX2FjcGlfcGFkX2hhbmRsZV9ub3RpZnkoYWNwaV9o
YW5kbGUgaGFuZGxlKQoreworCWludCByZXQsIG51bV9jcHVzOworCisJbnVtX2NwdXMgPSB4ZW5f
YWNwaV9wYWRfcHVyKGhhbmRsZSk7CisJaWYgKG51bV9jcHVzIDwgMCkKKwkJcmV0dXJuOworCisJ
cmV0ID0geGVuX2FjcGlfcGFkX2lkbGVfY3B1cygmbnVtX2NwdXMpOworCWlmIChyZXQpCisJCXJl
dHVybjsKKworCXhlbl9hY3BpX3BhZF9vc3QoaGFuZGxlLCAwLCBudW1fY3B1cyk7Cit9CisKK3N0
YXRpYyB2b2lkIHhlbl9hY3BpX3BhZF9ub3RpZnkoYWNwaV9oYW5kbGUgaGFuZGxlLCB1MzIgZXZl
bnQsCisJdm9pZCAqZGF0YSkKK3sKKwlzd2l0Y2ggKGV2ZW50KSB7CisJY2FzZSBBQ1BJX1BST0NF
U1NPUl9BR0dSRUdBVE9SX05PVElGWToKKwkJeGVuX2FjcGlfcGFkX2hhbmRsZV9ub3RpZnkoaGFu
ZGxlKTsKKwkJYnJlYWs7CisJZGVmYXVsdDoKKwkJcHJfd2FybigiVW5zdXBwb3J0ZWQgZXZlbnQg
WzB4JXhdXG4iLCBldmVudCk7CisJCWJyZWFrOworCX0KK30KKworc3RhdGljIGludCB4ZW5fYWNw
aV9wYWRfYWRkKHN0cnVjdCBhY3BpX2RldmljZSAqZGV2aWNlKQoreworCWFjcGlfc3RhdHVzIHN0
YXR1czsKKworCXN0cmNweShhY3BpX2RldmljZV9uYW1lKGRldmljZSksIEFDUElfUFJPQ0VTU09S
X0FHR1JFR0FUT1JfREVWSUNFX05BTUUpOworCXN0cmNweShhY3BpX2RldmljZV9jbGFzcyhkZXZp
Y2UpLCBBQ1BJX1BST0NFU1NPUl9BR0dSRUdBVE9SX0NMQVNTKTsKKworCXN0YXR1cyA9IGFjcGlf
aW5zdGFsbF9ub3RpZnlfaGFuZGxlcihkZXZpY2UtPmhhbmRsZSwKKwkJIEFDUElfREVWSUNFX05P
VElGWSwgeGVuX2FjcGlfcGFkX25vdGlmeSwgZGV2aWNlKTsKKwlpZiAoQUNQSV9GQUlMVVJFKHN0
YXR1cykpCisJCXJldHVybiAtRU5PREVWOworCisJcmV0dXJuIDA7Cit9CisKK3N0YXRpYyBjb25z
dCBzdHJ1Y3QgYWNwaV9kZXZpY2VfaWQgcGFkX2RldmljZV9pZHNbXSA9IHsKKwl7IkFDUEkwMDBD
IiwgMH0sCisJeyIiLCAwfSwKK307CisKK3N0YXRpYyBzdHJ1Y3QgYWNwaV9kcml2ZXIgeGVuX2Fj
cGlfcGFkX2RyaXZlciA9IHsKKwkubmFtZSA9ICJwcm9jZXNzb3JfYWdncmVnYXRvciIsCisJLmNs
YXNzID0gQUNQSV9QUk9DRVNTT1JfQUdHUkVHQVRPUl9DTEFTUywKKwkuaWRzID0gcGFkX2Rldmlj
ZV9pZHMsCisJLm9wcyA9IHsKKwkJLmFkZCA9IHhlbl9hY3BpX3BhZF9hZGQsCisJfSwKK307CisK
K3N0YXRpYyBpbnQgX19pbml0IHhlbl9hY3BpX3BhZF9pbml0KHZvaWQpCit7CisJLyogT25seSBE
T00wIGlzIHJlc3BvbnNpYmxlIGZvciBYZW4gYWNwaSBwYWQgKi8KKwlpZiAoeGVuX2luaXRpYWxf
ZG9tYWluKCkpCisJCXJldHVybiBhY3BpX2J1c19yZWdpc3Rlcl9kcml2ZXIoJnhlbl9hY3BpX3Bh
ZF9kcml2ZXIpOworCisJcmV0dXJuIC1FTk9ERVY7Cit9CitzdWJzeXNfaW5pdGNhbGwoeGVuX2Fj
cGlfcGFkX2luaXQpOworCisjZW5kaWYKZGlmZiAtLWdpdCBhL2luY2x1ZGUveGVuL2ludGVyZmFj
ZS9wbGF0Zm9ybS5oIGIvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3BsYXRmb3JtLmgKaW5kZXggNDc1
NWI1Zi4uMGY0NDM3NiAxMDA2NDQKLS0tIGEvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3BsYXRmb3Jt
LmgKKysrIGIvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3BsYXRmb3JtLmgKQEAgLTMyNCw2ICszMjQs
MjIgQEAgc3RydWN0IHhlbnBmX2NwdV9vbCB7CiB9OwogREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJV
Q1QoeGVucGZfY3B1X29sKTsKIAorLyoKKyAqIENNRCA1OCBhbmQgNTkgYXJlIHJlc2VydmVkIGZv
ciBjcHUgaG90YWRkIGFuZCBtZW1vcnkgaG90YWRkLAorICogd2hpY2ggYWxyZWFkeSBvY2N1cGll
ZCBhdCBYZW4gaHlwZXJ2aXNvciBzaWRlLgorICovCisjZGVmaW5lIFhFTlBGX2NvcmVfcGFya2lu
Zwk2MAorc3RydWN0IHhlbnBmX2NvcmVfcGFya2luZyB7CisJLyogSU4gdmFyaWFibGVzICovCisj
ZGVmaW5lIFhFTl9DT1JFX1BBUktJTkdfU0VUCTEKKyNkZWZpbmUgWEVOX0NPUkVfUEFSS0lOR19H
RVQJMgorCXVpbnQzMl90IHR5cGU7CisJLyogSU4gdmFyaWFibGVzOiAgc2V0IGNwdSBudW1zIGV4
cGVjdGVkIHRvIGJlIGlkbGVkICovCisJLyogT1VUIHZhcmlhYmxlczogZ2V0IGNwdSBudW1zIGFj
dHVhbGx5IGJlIGlkbGVkICovCisJdWludDMyX3QgaWRsZV9udW1zOworfTsKK0RFRklORV9HVUVT
VF9IQU5ETEVfU1RSVUNUKHhlbnBmX2NvcmVfcGFya2luZyk7CisKIHN0cnVjdCB4ZW5fcGxhdGZv
cm1fb3AgewogCXVpbnQzMl90IGNtZDsKIAl1aW50MzJfdCBpbnRlcmZhY2VfdmVyc2lvbjsgLyog
WEVOUEZfSU5URVJGQUNFX1ZFUlNJT04gKi8KQEAgLTM0MSw2ICszNTcsNyBAQCBzdHJ1Y3QgeGVu
X3BsYXRmb3JtX29wIHsKIAkJc3RydWN0IHhlbnBmX3NldF9wcm9jZXNzb3JfcG1pbmZvIHNldF9w
bWluZm87CiAJCXN0cnVjdCB4ZW5wZl9wY3B1aW5mbyAgICAgICAgICBwY3B1X2luZm87CiAJCXN0
cnVjdCB4ZW5wZl9jcHVfb2wgICAgICAgICAgICBjcHVfb2w7CisJCXN0cnVjdCB4ZW5wZl9jb3Jl
X3BhcmtpbmcgICAgICBjb3JlX3Bhcmtpbmc7CiAJCXVpbnQ4X3QgICAgICAgICAgICAgICAgICAg
ICAgICBwYWRbMTI4XTsKIAl9IHU7CiB9OwotLSAKMS43LjEKCg==

--_002_DE8DF0795D48FD4CA783C40EC829233537157FSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC829233537157FSHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Thu Oct 25 12:26:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 12:26:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRMVu-0002Nu-0Y; Thu, 25 Oct 2012 12:26:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRMVs-0002Np-L9
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 12:26:16 +0000
Received: from [85.158.138.51:25931] by server-2.bemta-3.messagelabs.com id
	49/5E-00604-7EF29805; Thu, 25 Oct 2012 12:26:15 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1351167974!27355756!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14521 invoked from network); 25 Oct 2012 12:26:15 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 12:26:15 -0000
Received: by mail-bk0-f45.google.com with SMTP id jf3so702541bkc.32
	for ; Thu, 25 Oct 2012 05:26:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:to
	:subject:content-type:content-transfer-encoding;
	bh=r9lNQWFXIFXPjjceICrI3FBG4orL6KV/LHsffj7jmz8=;
	b=dDxzmzWM5Pxv3jf+c5yHWNfx13DJ84ZO/z8HGeASvcLCmHc4tJNHFloloFGqUIGKqb
	xe+MiFb63vpMa0qcoTyRIIGXToNgqVweFhAyNT78Cp/d6tsfBj25NVqsej8Wkptk4xR/
	TzZ8ZVZzncMdnkIYLFA0XZGqiqEStt3IeERsKFcMQ1YeduYoRsOCsDzyGIP0zDjKnGzu
	3dIT6yjIwAJKHD+UzinoY+vukDbJeE3cXwaSl8RHcIW46qvyTyP1xH45K/Ar1aYdu2oh
	nN6CSdzXT4xrTzZIaKagtb5hjrKi3W528lcha80LcbNRpT6iOYXznCybAoabpjYzO4uw
	Otqw==
Received: by 10.204.152.25 with SMTP id e25mr6030924bkw.70.1351167974669;
	Thu, 25 Oct 2012 05:26:14 -0700 (PDT)
Received: from [172.16.26.11] (b0fb5ab2.bb.sky.com. [176.251.90.178])
	by mx.google.com with ESMTPS id g8sm10035847bkv.6.2012.10.25.05.26.13
	(version=SSLv3 cipher=OTHER); Thu, 25 Oct 2012 05:26:14 -0700 (PDT)
Message-ID: <50892FE5.3080205@xen.org>
Date: Thu, 25 Oct 2012 13:26:13 +0100
From: Lars Kurth 
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" 
Subject: [Xen-devel] Minutes of October Xen Maintainer,
	Committer and Developer Meeting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: lars.kurth@xen.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

See 
http://wiki.xen.org/wiki/Xen_Maintainer,_Committer_and_Developer_Meeting/October_2012_Minutes

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 12:26:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 12:26:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRMVu-0002Nu-0Y; Thu, 25 Oct 2012 12:26:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRMVs-0002Np-L9
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 12:26:16 +0000
Received: from [85.158.138.51:25931] by server-2.bemta-3.messagelabs.com id
	49/5E-00604-7EF29805; Thu, 25 Oct 2012 12:26:15 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1351167974!27355756!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14521 invoked from network); 25 Oct 2012 12:26:15 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 12:26:15 -0000
Received: by mail-bk0-f45.google.com with SMTP id jf3so702541bkc.32
	for ; Thu, 25 Oct 2012 05:26:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:to
	:subject:content-type:content-transfer-encoding;
	bh=r9lNQWFXIFXPjjceICrI3FBG4orL6KV/LHsffj7jmz8=;
	b=dDxzmzWM5Pxv3jf+c5yHWNfx13DJ84ZO/z8HGeASvcLCmHc4tJNHFloloFGqUIGKqb
	xe+MiFb63vpMa0qcoTyRIIGXToNgqVweFhAyNT78Cp/d6tsfBj25NVqsej8Wkptk4xR/
	TzZ8ZVZzncMdnkIYLFA0XZGqiqEStt3IeERsKFcMQ1YeduYoRsOCsDzyGIP0zDjKnGzu
	3dIT6yjIwAJKHD+UzinoY+vukDbJeE3cXwaSl8RHcIW46qvyTyP1xH45K/Ar1aYdu2oh
	nN6CSdzXT4xrTzZIaKagtb5hjrKi3W528lcha80LcbNRpT6iOYXznCybAoabpjYzO4uw
	Otqw==
Received: by 10.204.152.25 with SMTP id e25mr6030924bkw.70.1351167974669;
	Thu, 25 Oct 2012 05:26:14 -0700 (PDT)
Received: from [172.16.26.11] (b0fb5ab2.bb.sky.com. [176.251.90.178])
	by mx.google.com with ESMTPS id g8sm10035847bkv.6.2012.10.25.05.26.13
	(version=SSLv3 cipher=OTHER); Thu, 25 Oct 2012 05:26:14 -0700 (PDT)
Message-ID: <50892FE5.3080205@xen.org>
Date: Thu, 25 Oct 2012 13:26:13 +0100
From: Lars Kurth 
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" 
Subject: [Xen-devel] Minutes of October Xen Maintainer,
	Committer and Developer Meeting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: lars.kurth@xen.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

See 
http://wiki.xen.org/wiki/Xen_Maintainer,_Committer_and_Developer_Meeting/October_2012_Minutes

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 12:32:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 12:32:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRMbX-0002Wr-Pz; Thu, 25 Oct 2012 12:32:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRMbW-0002Wm-1L
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 12:32:06 +0000
Received: from [85.158.143.99:3999] by server-3.bemta-4.messagelabs.com id
	B0/7B-24279-54139805; Thu, 25 Oct 2012 12:32:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1351168324!20311046!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19545 invoked from network); 25 Oct 2012 12:32:04 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-216.messagelabs.com with SMTP;
	25 Oct 2012 12:32:04 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 25 Oct 2012 13:34:19 +0100
Message-Id: <50894D6202000078000A47FE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 25 Oct 2012 13:32:02 +0100
From: "Jan Beulich" 
To: "George Dunlap" ,
	"Ian Jackson" ,
	"Jinsong Liu" 
References: 
	<20609.26910.2416.305293@mariner.uk.xensource.com>
	
	
	<20617.8367.946706.92097@mariner.uk.xensource.com>
In-Reply-To: <20617.8367.946706.92097@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , IanCampbell 
Subject: Re: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration
 when	vMCE	occur
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 25.10.12 at 13:21, Ian Jackson  wrote:
> Liu, Jinsong writes ("Re: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live 
> migration when	vMCE	occur"):
>> Update patch 4/5 as attached.
> 
> Thanks.  As for the tools parts:
> 
> Acked-by: Ian Jackson 

Now I'm confused - wasn't the earlier discussion leading towards
this patch being unnecessary (patch alone 5 being sufficient)?

Anyway, I think there were resubmission plans for both of the
remaining patches anyway - Jinsong?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 12:32:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 12:32:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRMbX-0002Wr-Pz; Thu, 25 Oct 2012 12:32:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRMbW-0002Wm-1L
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 12:32:06 +0000
Received: from [85.158.143.99:3999] by server-3.bemta-4.messagelabs.com id
	B0/7B-24279-54139805; Thu, 25 Oct 2012 12:32:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1351168324!20311046!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19545 invoked from network); 25 Oct 2012 12:32:04 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-216.messagelabs.com with SMTP;
	25 Oct 2012 12:32:04 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 25 Oct 2012 13:34:19 +0100
Message-Id: <50894D6202000078000A47FE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 25 Oct 2012 13:32:02 +0100
From: "Jan Beulich" 
To: "George Dunlap" ,
	"Ian Jackson" ,
	"Jinsong Liu" 
References: 
	<20609.26910.2416.305293@mariner.uk.xensource.com>
	
	
	<20617.8367.946706.92097@mariner.uk.xensource.com>
In-Reply-To: <20617.8367.946706.92097@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , IanCampbell 
Subject: Re: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration
 when	vMCE	occur
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 25.10.12 at 13:21, Ian Jackson  wrote:
> Liu, Jinsong writes ("Re: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live 
> migration when	vMCE	occur"):
>> Update patch 4/5 as attached.
> 
> Thanks.  As for the tools parts:
> 
> Acked-by: Ian Jackson 

Now I'm confused - wasn't the earlier discussion leading towards
this patch being unnecessary (patch alone 5 being sufficient)?

Anyway, I think there were resubmission plans for both of the
remaining patches anyway - Jinsong?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 12:36:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 12:36:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRMfy-0002ki-Jo; Thu, 25 Oct 2012 12:36:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRMfx-0002ka-DI
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 12:36:41 +0000
Received: from [85.158.143.99:39606] by server-3.bemta-4.messagelabs.com id
	86/02-24279-85239805; Thu, 25 Oct 2012 12:36:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1351168600!19819565!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4070 invoked from network); 25 Oct 2012 12:36:40 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-216.messagelabs.com with SMTP;
	25 Oct 2012 12:36:40 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 25 Oct 2012 13:39:03 +0100
Message-Id: <50894E7802000078000A4810@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 25 Oct 2012 13:36:40 +0100
From: "Jan Beulich" 
To: "Jean Guyader" 
References: <1351165926-23259-1-git-send-email-jean.guyader@citrix.com>
	<1351165926-23259-2-git-send-email-jean.guyader@citrix.com>
In-Reply-To: <1351165926-23259-2-git-send-email-jean.guyader@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/3] xen: virq, remove VIRQ_XC_RESERVED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 25.10.12 at 13:52, Jean Guyader  wrote:
> VIRQ_XC_RESERVED was reserved for V4V but we have switched
> to event channels so this place holder is no longer required.

I don't recall what we settled on in earlier discussions here: Is it
certain that re-use of this vIRQ won't cause problems when a
guest trying to use it for another purpose would be run on a
host having the supposed old meaning of it in use? If not, it may
need to remain permanently reserved.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 12:36:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 12:36:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRMfy-0002ki-Jo; Thu, 25 Oct 2012 12:36:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRMfx-0002ka-DI
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 12:36:41 +0000
Received: from [85.158.143.99:39606] by server-3.bemta-4.messagelabs.com id
	86/02-24279-85239805; Thu, 25 Oct 2012 12:36:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1351168600!19819565!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4070 invoked from network); 25 Oct 2012 12:36:40 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-216.messagelabs.com with SMTP;
	25 Oct 2012 12:36:40 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 25 Oct 2012 13:39:03 +0100
Message-Id: <50894E7802000078000A4810@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 25 Oct 2012 13:36:40 +0100
From: "Jan Beulich" 
To: "Jean Guyader" 
References: <1351165926-23259-1-git-send-email-jean.guyader@citrix.com>
	<1351165926-23259-2-git-send-email-jean.guyader@citrix.com>
In-Reply-To: <1351165926-23259-2-git-send-email-jean.guyader@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/3] xen: virq, remove VIRQ_XC_RESERVED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 25.10.12 at 13:52, Jean Guyader  wrote:
> VIRQ_XC_RESERVED was reserved for V4V but we have switched
> to event channels so this place holder is no longer required.

I don't recall what we settled on in earlier discussions here: Is it
certain that re-use of this vIRQ won't cause problems when a
guest trying to use it for another purpose would be run on a
host having the supposed old meaning of it in use? If not, it may
need to remain permanently reserved.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 12:38:46 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 12:38:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRMhj-0002qj-4O; Thu, 25 Oct 2012 12:38:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRMhi-0002qc-1w
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 12:38:30 +0000
Received: from [85.158.143.99:54506] by server-2.bemta-4.messagelabs.com id
	87/81-22268-5C239805; Thu, 25 Oct 2012 12:38:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1351168708!27328462!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18001 invoked from network); 25 Oct 2012 12:38:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 12:38:28 -0000
X-IronPort-AV: E=Sophos;i="4.80,646,1344211200"; d="scan'208";a="15387859"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 12:38:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 13:38:28 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TRMhg-0004NH-BV; Thu, 25 Oct 2012 12:38:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TRMhg-0000tH-7K;
	Thu, 25 Oct 2012 13:38:28 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20617.12996.126396.575918@mariner.uk.xensource.com>
Date: Thu, 25 Oct 2012 13:38:28 +0100
To: Jan Beulich 
In-Reply-To: <50894D6202000078000A47FE@nat28.tlf.novell.com>
References: 
	<20609.26910.2416.305293@mariner.uk.xensource.com>
	
	
	<20617.8367.946706.92097@mariner.uk.xensource.com>
	<50894D6202000078000A47FE@nat28.tlf.novell.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Jinsong Liu ,
	Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	George Dunlap 
Subject: Re: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration
	when	vMCE	occur
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Jan Beulich writes ("Re: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration when	vMCE occur"):
> Now I'm confused - wasn't the earlier discussion leading towards
> this patch being unnecessary (patch alone 5 being sufficient)?

No.  4/5 is for MCEs which happen _during_ migration; 5/5 is for ones
which have happened previously.

> Anyway, I think there were resubmission plans for both of the
> remaining patches anyway - Jinsong?

This is the resubmitted version addressing my comments.  Unless there
are other changes needed in the hypervisor part ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 12:38:46 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 12:38:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRMhj-0002qj-4O; Thu, 25 Oct 2012 12:38:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRMhi-0002qc-1w
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 12:38:30 +0000
Received: from [85.158.143.99:54506] by server-2.bemta-4.messagelabs.com id
	87/81-22268-5C239805; Thu, 25 Oct 2012 12:38:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1351168708!27328462!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18001 invoked from network); 25 Oct 2012 12:38:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 12:38:28 -0000
X-IronPort-AV: E=Sophos;i="4.80,646,1344211200"; d="scan'208";a="15387859"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 12:38:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 13:38:28 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TRMhg-0004NH-BV; Thu, 25 Oct 2012 12:38:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TRMhg-0000tH-7K;
	Thu, 25 Oct 2012 13:38:28 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20617.12996.126396.575918@mariner.uk.xensource.com>
Date: Thu, 25 Oct 2012 13:38:28 +0100
To: Jan Beulich 
In-Reply-To: <50894D6202000078000A47FE@nat28.tlf.novell.com>
References: 
	<20609.26910.2416.305293@mariner.uk.xensource.com>
	
	
	<20617.8367.946706.92097@mariner.uk.xensource.com>
	<50894D6202000078000A47FE@nat28.tlf.novell.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Jinsong Liu ,
	Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	George Dunlap 
Subject: Re: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration
	when	vMCE	occur
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Jan Beulich writes ("Re: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration when	vMCE occur"):
> Now I'm confused - wasn't the earlier discussion leading towards
> this patch being unnecessary (patch alone 5 being sufficient)?

No.  4/5 is for MCEs which happen _during_ migration; 5/5 is for ones
which have happened previously.

> Anyway, I think there were resubmission plans for both of the
> remaining patches anyway - Jinsong?

This is the resubmitted version addressing my comments.  Unless there
are other changes needed in the hypervisor part ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 12:39:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 12:39:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRMiG-0002uf-O0; Thu, 25 Oct 2012 12:39:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRMiE-0002u9-E2
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 12:39:02 +0000
Received: from [85.158.143.99:58142] by server-1.bemta-4.messagelabs.com id
	16/6B-19134-5E239805; Thu, 25 Oct 2012 12:39:01 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1351168739!26450139!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgzMTMyMA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31103 invoked from network); 25 Oct 2012 12:39:01 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Oct 2012 12:39:01 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9PCcssX009907
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 25 Oct 2012 12:38:55 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9PCcrU8023757
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 25 Oct 2012 12:38:53 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9PCcq8M023860; Thu, 25 Oct 2012 07:38:52 -0500
Received: from localhost.localdomain (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 25 Oct 2012 05:38:52 -0700
Date: Thu, 25 Oct 2012 08:38:46 -0400
From: Konrad Rzeszutek Wilk 
To: Mukesh Rathor 
Message-ID: <20121025123828.GA25640@localhost.localdomain>
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
	<1350695882-12820-5-git-send-email-konrad.wilk@oracle.com>
	
	<20121022155717.GB25200@phenom.dumpdata.com>
	
	<20121023164729.0ed51a1d@mantra.us.oracle.com>
	<20121023170310.3b2a7e20@mantra.us.oracle.com>
	<20121023171051.2ed9af3c@mantra.us.oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20121023171051.2ed9af3c@mantra.us.oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "linux-kernel@vger.kernel.org" ,
	"xen-devel@lists.xensource.com" ,
	Ian Campbell ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 4/6] xen/pvh: bootup and setup related
 changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > > > Yes, I think that this version looks better
> > > 
> > > But doesn't boot:
> > > 
> > > (XEN) vmx_hybrid.c:710:d0 Dom:0 EPT violation 0x181 (r--/---), gpa
> > > 0x000000bf421e1c, mfn 0xffffffffffffffff, type 4. (XEN)
> > > p2m-ept.c:642:d0 Walking EPT tables for domain 0 gfn bf421 (XEN)
> > > p2m-ept.c:648:d0  gfn exceeds max_mapped_pfn 4b062 (XEN)
> > > vmx_hybrid.c:717:d0  --- GLA 0xffffffffff477e1c
> > > 
> > > 
> > > I'll have to debug it, or we can go back to the prev version, which
> > > I don't think is that un-pretty :).
> > > 
> > 
> > The reason being:
> > xen_set_identity_and_release_chunk():
> > NEW : > for (pfn = start_pfn; pfn <= max_pfn_mapped && pfn < end_pfn;
> > pfn++) {
> > 
> > xen_pvh_identity_map_chunk():
> > OLD: for (pfn = start_pfn; pfn < end_pfn; pfn++)
> > 
> > IOW, for PVH we need to avoid testing for max_pfn_mapped, as we are
> > mapping the entire IO space. 
> 
> Also, now your counts for released and identity are off. Can we please
> go back to the way it was? 

Lets drop this patch then for right now. Can you post an alpha-RFC of your
Xen hypervisor patches so that I can wrangle the PV and PVH in the E820
code to use same paths as much as possible.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 12:39:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 12:39:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRMiG-0002uf-O0; Thu, 25 Oct 2012 12:39:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRMiE-0002u9-E2
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 12:39:02 +0000
Received: from [85.158.143.99:58142] by server-1.bemta-4.messagelabs.com id
	16/6B-19134-5E239805; Thu, 25 Oct 2012 12:39:01 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1351168739!26450139!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgzMTMyMA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31103 invoked from network); 25 Oct 2012 12:39:01 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Oct 2012 12:39:01 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9PCcssX009907
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 25 Oct 2012 12:38:55 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9PCcrU8023757
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 25 Oct 2012 12:38:53 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9PCcq8M023860; Thu, 25 Oct 2012 07:38:52 -0500
Received: from localhost.localdomain (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 25 Oct 2012 05:38:52 -0700
Date: Thu, 25 Oct 2012 08:38:46 -0400
From: Konrad Rzeszutek Wilk 
To: Mukesh Rathor 
Message-ID: <20121025123828.GA25640@localhost.localdomain>
References: <1350695882-12820-1-git-send-email-konrad.wilk@oracle.com>
	<1350695882-12820-5-git-send-email-konrad.wilk@oracle.com>
	
	<20121022155717.GB25200@phenom.dumpdata.com>
	
	<20121023164729.0ed51a1d@mantra.us.oracle.com>
	<20121023170310.3b2a7e20@mantra.us.oracle.com>
	<20121023171051.2ed9af3c@mantra.us.oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20121023171051.2ed9af3c@mantra.us.oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "linux-kernel@vger.kernel.org" ,
	"xen-devel@lists.xensource.com" ,
	Ian Campbell ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 4/6] xen/pvh: bootup and setup related
 changes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > > > Yes, I think that this version looks better
> > > 
> > > But doesn't boot:
> > > 
> > > (XEN) vmx_hybrid.c:710:d0 Dom:0 EPT violation 0x181 (r--/---), gpa
> > > 0x000000bf421e1c, mfn 0xffffffffffffffff, type 4. (XEN)
> > > p2m-ept.c:642:d0 Walking EPT tables for domain 0 gfn bf421 (XEN)
> > > p2m-ept.c:648:d0  gfn exceeds max_mapped_pfn 4b062 (XEN)
> > > vmx_hybrid.c:717:d0  --- GLA 0xffffffffff477e1c
> > > 
> > > 
> > > I'll have to debug it, or we can go back to the prev version, which
> > > I don't think is that un-pretty :).
> > > 
> > 
> > The reason being:
> > xen_set_identity_and_release_chunk():
> > NEW : > for (pfn = start_pfn; pfn <= max_pfn_mapped && pfn < end_pfn;
> > pfn++) {
> > 
> > xen_pvh_identity_map_chunk():
> > OLD: for (pfn = start_pfn; pfn < end_pfn; pfn++)
> > 
> > IOW, for PVH we need to avoid testing for max_pfn_mapped, as we are
> > mapping the entire IO space. 
> 
> Also, now your counts for released and identity are off. Can we please
> go back to the way it was? 

Lets drop this patch then for right now. Can you post an alpha-RFC of your
Xen hypervisor patches so that I can wrangle the PV and PVH in the E820
code to use same paths as much as possible.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 12:40:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 12:40:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRMjF-00033x-6e; Thu, 25 Oct 2012 12:40:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRMjE-00033n-KL
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 12:40:04 +0000
Received: from [85.158.138.51:16526] by server-2.bemta-3.messagelabs.com id
	88/58-00604-32339805; Thu, 25 Oct 2012 12:40:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1351168803!25640824!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 579 invoked from network); 25 Oct 2012 12:40:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 12:40:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,646,1344211200"; d="scan'208";a="15387892"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 12:39:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 13:39:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TRMiY-0004NZ-JQ; Thu, 25 Oct 2012 12:39:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TRMiY-0000tY-FL;
	Thu, 25 Oct 2012 13:39:22 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20617.13045.486553.172990@mariner.uk.xensource.com>
Date: Thu, 25 Oct 2012 13:39:17 +0100
To: Christoph Egger 
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <508916B3.2030403@amd.com>
References: <508916B3.2030403@amd.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] tools: use PREFIX when building upstream
	qemu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Christoph Egger writes ("[Xen-devel] [PATCH] tools: use PREFIX when building upstream qemu"):
> 
> use PREFIX when building upstream qemu.
> 
> Signed-off-by: Christoph Egger 

This looks reasonable but can you explain what goes wrong when,
without this ?  I'd like to be able to verify the bug and fix myself.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 12:40:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 12:40:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRMjF-00033x-6e; Thu, 25 Oct 2012 12:40:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRMjE-00033n-KL
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 12:40:04 +0000
Received: from [85.158.138.51:16526] by server-2.bemta-3.messagelabs.com id
	88/58-00604-32339805; Thu, 25 Oct 2012 12:40:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1351168803!25640824!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 579 invoked from network); 25 Oct 2012 12:40:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 12:40:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,646,1344211200"; d="scan'208";a="15387892"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 12:39:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 13:39:22 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TRMiY-0004NZ-JQ; Thu, 25 Oct 2012 12:39:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TRMiY-0000tY-FL;
	Thu, 25 Oct 2012 13:39:22 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20617.13045.486553.172990@mariner.uk.xensource.com>
Date: Thu, 25 Oct 2012 13:39:17 +0100
To: Christoph Egger 
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <508916B3.2030403@amd.com>
References: <508916B3.2030403@amd.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] tools: use PREFIX when building upstream
	qemu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Christoph Egger writes ("[Xen-devel] [PATCH] tools: use PREFIX when building upstream qemu"):
> 
> use PREFIX when building upstream qemu.
> 
> Signed-off-by: Christoph Egger 

This looks reasonable but can you explain what goes wrong when,
without this ?  I'd like to be able to verify the bug and fix myself.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 12:41:22 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 12:41:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRMkK-0003C7-Kj; Thu, 25 Oct 2012 12:41:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRMkI-0003Bq-Ne
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 12:41:10 +0000
Received: from [85.158.138.51:3457] by server-15.bemta-3.messagelabs.com id
	80/59-09445-56339805; Thu, 25 Oct 2012 12:41:09 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1351168868!19455115!1
X-Originating-IP: [209.85.219.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4489 invoked from network); 25 Oct 2012 12:41:09 -0000
Received: from mail-oa0-f45.google.com (HELO mail-oa0-f45.google.com)
	(209.85.219.45)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 12:41:09 -0000
Received: by mail-oa0-f45.google.com with SMTP id i18so1948978oag.32
	for ; Thu, 25 Oct 2012 05:41:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=OYYFRxi6J4xjKGYs7TiDl1bylaUmBqXX4TZdRDTZXao=;
	b=sjW381g3DhDf+TTvXo+VALhp6eU4iqeWog2D0e3PKeDFiCHHjvUUqeC6zJqZCsE+1e
	LmDtWM8OqSvMU9YW/Pj3KLAhRkQmr73nBSIDYDIzLrKSm5wZN8nMmd5UFRDoGJd7nJsy
	onCcZgrnt9q1Kx/dngS3HU2kKI6boxmi4Bxk3AunSXOx8DtT/TEOqyT9TTKvH6zUn8f2
	SipvWtn/qnHTcLPvIh6VARflpp7+2tt8B5O+DmRtG8n62/JbVGOW2RQfdrt9pdjezPXM
	54rK2CoSNL2tOsNjO4lKXi/TvSsQoRLybqUhMTs3N1KOkieKqB+cxGX6qaTXy/mKMe2Q
	ItZQ==
Received: by 10.60.27.9 with SMTP id p9mr16688393oeg.65.1351168867799; Thu, 25
	Oct 2012 05:41:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.76.90.138 with HTTP; Thu, 25 Oct 2012 05:40:47 -0700 (PDT)
In-Reply-To: <50894E7802000078000A4810@nat28.tlf.novell.com>
References: <1351165926-23259-1-git-send-email-jean.guyader@citrix.com>
	<1351165926-23259-2-git-send-email-jean.guyader@citrix.com>
	<50894E7802000078000A4810@nat28.tlf.novell.com>
From: Jean Guyader 
Date: Thu, 25 Oct 2012 13:40:47 +0100
Message-ID: 
To: Jan Beulich 
Cc: tim@xen.org, Jean Guyader ,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/3] xen: virq, remove VIRQ_XC_RESERVED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 25 October 2012 13:36, Jan Beulich  wrote:
>>>> On 25.10.12 at 13:52, Jean Guyader  wrote:
>> VIRQ_XC_RESERVED was reserved for V4V but we have switched
>> to event channels so this place holder is no longer required.
>
> I don't recall what we settled on in earlier discussions here: Is it
> certain that re-use of this vIRQ won't cause problems when a
> guest trying to use it for another purpose would be run on a
> host having the supposed old meaning of it in use? If not, it may
> need to remain permanently reserved.
>

Ok. I'll remove this patch from the next series.
That can be done later down the road.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 12:41:22 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 12:41:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRMkK-0003C7-Kj; Thu, 25 Oct 2012 12:41:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRMkI-0003Bq-Ne
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 12:41:10 +0000
Received: from [85.158.138.51:3457] by server-15.bemta-3.messagelabs.com id
	80/59-09445-56339805; Thu, 25 Oct 2012 12:41:09 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1351168868!19455115!1
X-Originating-IP: [209.85.219.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4489 invoked from network); 25 Oct 2012 12:41:09 -0000
Received: from mail-oa0-f45.google.com (HELO mail-oa0-f45.google.com)
	(209.85.219.45)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 12:41:09 -0000
Received: by mail-oa0-f45.google.com with SMTP id i18so1948978oag.32
	for ; Thu, 25 Oct 2012 05:41:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=OYYFRxi6J4xjKGYs7TiDl1bylaUmBqXX4TZdRDTZXao=;
	b=sjW381g3DhDf+TTvXo+VALhp6eU4iqeWog2D0e3PKeDFiCHHjvUUqeC6zJqZCsE+1e
	LmDtWM8OqSvMU9YW/Pj3KLAhRkQmr73nBSIDYDIzLrKSm5wZN8nMmd5UFRDoGJd7nJsy
	onCcZgrnt9q1Kx/dngS3HU2kKI6boxmi4Bxk3AunSXOx8DtT/TEOqyT9TTKvH6zUn8f2
	SipvWtn/qnHTcLPvIh6VARflpp7+2tt8B5O+DmRtG8n62/JbVGOW2RQfdrt9pdjezPXM
	54rK2CoSNL2tOsNjO4lKXi/TvSsQoRLybqUhMTs3N1KOkieKqB+cxGX6qaTXy/mKMe2Q
	ItZQ==
Received: by 10.60.27.9 with SMTP id p9mr16688393oeg.65.1351168867799; Thu, 25
	Oct 2012 05:41:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.76.90.138 with HTTP; Thu, 25 Oct 2012 05:40:47 -0700 (PDT)
In-Reply-To: <50894E7802000078000A4810@nat28.tlf.novell.com>
References: <1351165926-23259-1-git-send-email-jean.guyader@citrix.com>
	<1351165926-23259-2-git-send-email-jean.guyader@citrix.com>
	<50894E7802000078000A4810@nat28.tlf.novell.com>
From: Jean Guyader 
Date: Thu, 25 Oct 2012 13:40:47 +0100
Message-ID: 
To: Jan Beulich 
Cc: tim@xen.org, Jean Guyader ,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/3] xen: virq, remove VIRQ_XC_RESERVED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 25 October 2012 13:36, Jan Beulich  wrote:
>>>> On 25.10.12 at 13:52, Jean Guyader  wrote:
>> VIRQ_XC_RESERVED was reserved for V4V but we have switched
>> to event channels so this place holder is no longer required.
>
> I don't recall what we settled on in earlier discussions here: Is it
> certain that re-use of this vIRQ won't cause problems when a
> guest trying to use it for another purpose would be run on a
> host having the supposed old meaning of it in use? If not, it may
> need to remain permanently reserved.
>

Ok. I'll remove this patch from the next series.
That can be done later down the road.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 12:42:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 12:42:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRMl3-0003JD-27; Thu, 25 Oct 2012 12:41:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRMl1-0003Ip-L0
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 12:41:55 +0000
Received: from [85.158.137.99:9902] by server-10.bemta-3.messagelabs.com id
	36/A7-00901-F8339805; Thu, 25 Oct 2012 12:41:51 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1351168909!19882850!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAxNjY2Nw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23060 invoked from network); 25 Oct 2012 12:41:51 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-12.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Oct 2012 12:41:51 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9PCeHsD008992
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 25 Oct 2012 12:40:18 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9PCeGw8024820
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 25 Oct 2012 12:40:17 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9PCeGwL024764; Thu, 25 Oct 2012 07:40:16 -0500
Received: from localhost.localdomain (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 25 Oct 2012 05:40:16 -0700
Date: Thu, 25 Oct 2012 08:40:14 -0400
From: Konrad Rzeszutek Wilk 
To: Jan Beulich 
Message-ID: <20121025124013.GB25640@localhost.localdomain>
References: <1350559321-19066-1-git-send-email-roger.pau@citrix.com>
	<20121022134708.GA13832@konrad-lan.dumpdata.com>
	<5086C0C8.5000306@citrix.com>
	<20121023172008.GB11787@phenom.dumpdata.com>
	<5086DD57.4000206@citrix.com>
	<20121023185049.GB20350@phenom.dumpdata.com>
	<5087B77A02000078000A3D00@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5087B77A02000078000A3D00@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Konrad Rzeszutek Wilk ,
	"xen-devel@lists.xen.org" ,
	"linux-kernel@vger.kernel.org" ,
	roger.pau@citrix.com
Subject: Re: [Xen-devel] [PATCH RFC] Persistent grant maps for xen blk
	drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 24, 2012 at 08:40:10AM +0100, Jan Beulich wrote:
> >>> On 23.10.12 at 20:50, Konrad Rzeszutek Wilk  wrote:
> > On Tue, Oct 23, 2012 at 08:09:27PM +0200, Roger Pau Monn=E9 wrote:
> >> On 23/10/12 19:20, Konrad Rzeszutek Wilk wrote:
> >> >>>> diff --git a/drivers/block/xen-blkback/blkback.c =

> > b/drivers/block/xen-blkback/blkback.c
> >> >>>> index c6decb9..2b982b2 100644
> >> >>>> --- a/drivers/block/xen-blkback/blkback.c
> >> >>>> +++ b/drivers/block/xen-blkback/blkback.c
> >> >>>> @@ -78,6 +78,7 @@ struct pending_req {
> >> >>>>       unsigned short          operation;
> >> >>>>       int                     status;
> >> >>>>       struct list_head        free_list;
> >> >>>> +     unsigned int            unmap_seg[BLKIF_MAX_SEGMENTS_PER_RE=
QUEST];
> >> =

> >> Should I change this to a bool? Since we are only setting it to 0 or 1.
> > =

> > I would just keep it as 'int'. Eventually we can replace this with a
> > bit-map, but that can be done later.
> =

> I think this should be a bitmap from the beginning - why would
> you want to waste 44 bytes per request for something that fits
> in a single unsigned long (and the picture would get worse with
> the number-of-segments extension)?
> =

> Also - am I taking this work being done here as a silent agreement
> to not invest into blkif2 to streamline the various extensions
> floating around?

I haven't been able (time-wise) to look at making blkif2 a possibility
and I don't want to hinder this work - which provides great
performance benefits.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 12:42:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 12:42:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRMl3-0003JD-27; Thu, 25 Oct 2012 12:41:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRMl1-0003Ip-L0
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 12:41:55 +0000
Received: from [85.158.137.99:9902] by server-10.bemta-3.messagelabs.com id
	36/A7-00901-F8339805; Thu, 25 Oct 2012 12:41:51 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1351168909!19882850!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAxNjY2Nw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23060 invoked from network); 25 Oct 2012 12:41:51 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-12.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Oct 2012 12:41:51 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9PCeHsD008992
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 25 Oct 2012 12:40:18 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9PCeGw8024820
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 25 Oct 2012 12:40:17 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9PCeGwL024764; Thu, 25 Oct 2012 07:40:16 -0500
Received: from localhost.localdomain (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 25 Oct 2012 05:40:16 -0700
Date: Thu, 25 Oct 2012 08:40:14 -0400
From: Konrad Rzeszutek Wilk 
To: Jan Beulich 
Message-ID: <20121025124013.GB25640@localhost.localdomain>
References: <1350559321-19066-1-git-send-email-roger.pau@citrix.com>
	<20121022134708.GA13832@konrad-lan.dumpdata.com>
	<5086C0C8.5000306@citrix.com>
	<20121023172008.GB11787@phenom.dumpdata.com>
	<5086DD57.4000206@citrix.com>
	<20121023185049.GB20350@phenom.dumpdata.com>
	<5087B77A02000078000A3D00@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5087B77A02000078000A3D00@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Konrad Rzeszutek Wilk ,
	"xen-devel@lists.xen.org" ,
	"linux-kernel@vger.kernel.org" ,
	roger.pau@citrix.com
Subject: Re: [Xen-devel] [PATCH RFC] Persistent grant maps for xen blk
	drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 24, 2012 at 08:40:10AM +0100, Jan Beulich wrote:
> >>> On 23.10.12 at 20:50, Konrad Rzeszutek Wilk  wrote:
> > On Tue, Oct 23, 2012 at 08:09:27PM +0200, Roger Pau Monn=E9 wrote:
> >> On 23/10/12 19:20, Konrad Rzeszutek Wilk wrote:
> >> >>>> diff --git a/drivers/block/xen-blkback/blkback.c =

> > b/drivers/block/xen-blkback/blkback.c
> >> >>>> index c6decb9..2b982b2 100644
> >> >>>> --- a/drivers/block/xen-blkback/blkback.c
> >> >>>> +++ b/drivers/block/xen-blkback/blkback.c
> >> >>>> @@ -78,6 +78,7 @@ struct pending_req {
> >> >>>>       unsigned short          operation;
> >> >>>>       int                     status;
> >> >>>>       struct list_head        free_list;
> >> >>>> +     unsigned int            unmap_seg[BLKIF_MAX_SEGMENTS_PER_RE=
QUEST];
> >> =

> >> Should I change this to a bool? Since we are only setting it to 0 or 1.
> > =

> > I would just keep it as 'int'. Eventually we can replace this with a
> > bit-map, but that can be done later.
> =

> I think this should be a bitmap from the beginning - why would
> you want to waste 44 bytes per request for something that fits
> in a single unsigned long (and the picture would get worse with
> the number-of-segments extension)?
> =

> Also - am I taking this work being done here as a silent agreement
> to not invest into blkif2 to streamline the various extensions
> floating around?

I haven't been able (time-wise) to look at making blkif2 a possibility
and I don't want to hinder this work - which provides great
performance benefits.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 12:44:44 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 12:44:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRMnY-0003Yt-La; Thu, 25 Oct 2012 12:44:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRMnX-0003Yk-OT
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 12:44:31 +0000
Received: from [85.158.137.99:49845] by server-12.bemta-3.messagelabs.com id
	51/7F-27853-A2439805; Thu, 25 Oct 2012 12:44:26 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1351169064!19855265!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjIzMTI0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2658 invoked from network); 25 Oct 2012 12:44:25 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-9.tower-217.messagelabs.com with SMTP;
	25 Oct 2012 12:44:25 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 25 Oct 2012 05:44:23 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,646,1344236400"; d="scan'208";a="160478620"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by AZSMGA002.ch.intel.com with ESMTP; 25 Oct 2012 05:44:23 -0700
Received: from fmsmsx151.amr.corp.intel.com (10.19.17.220) by
	FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 25 Oct 2012 05:44:23 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX151.amr.corp.intel.com (10.19.17.220) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 25 Oct 2012 05:44:22 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.186]) with mapi id
	14.01.0355.002; Thu, 25 Oct 2012 20:44:21 +0800
From: "Liu, Jinsong" 
To: Jan Beulich , George Dunlap
	, Ian Jackson 
Thread-Topic: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration when
	vMCE	occur
Thread-Index: AQHNsqzG1d0fFTiH/k2kGLRULCwaEZfJ9KCw
Date: Thu, 25 Oct 2012 12:44:20 +0000
Message-ID: 
References: 
	<20609.26910.2416.305293@mariner.uk.xensource.com>
	
	
	<20617.8367.946706.92097@mariner.uk.xensource.com>
	<50894D6202000078000A47FE@nat28.tlf.novell.com>
In-Reply-To: <50894D6202000078000A47FE@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , IanCampbell 
Subject: Re: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration
	when	vMCE	occur
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Jan Beulich wrote:
>>>> On 25.10.12 at 13:21, Ian Jackson 
>>>> wrote: 
>> Liu, Jinsong writes ("Re: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live
>> migration when	vMCE	occur"):
>>> Update patch 4/5 as attached.
>> 
>> Thanks.  As for the tools parts:
>> 
>> Acked-by: Ian Jackson 
> 
> Now I'm confused - wasn't the earlier discussion leading towards
> this patch being unnecessary (patch alone 5 being sufficient)?
> 
> Anyway, I think there were resubmission plans for both of the
> remaining patches anyway - Jinsong?
> 
> Jan

A little bit confusing here.

I think IanJ acked for my updated patch according to his comments earlier. Later, George present an approach about how to handle the case 'vMCE occur during migration' (patch 4). IMO it's perfect. So please temporarily not check patch4/5 in, I will update later.

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 12:44:44 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 12:44:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRMnY-0003Yt-La; Thu, 25 Oct 2012 12:44:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRMnX-0003Yk-OT
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 12:44:31 +0000
Received: from [85.158.137.99:49845] by server-12.bemta-3.messagelabs.com id
	51/7F-27853-A2439805; Thu, 25 Oct 2012 12:44:26 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1351169064!19855265!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjIzMTI0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2658 invoked from network); 25 Oct 2012 12:44:25 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-9.tower-217.messagelabs.com with SMTP;
	25 Oct 2012 12:44:25 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 25 Oct 2012 05:44:23 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,646,1344236400"; d="scan'208";a="160478620"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by AZSMGA002.ch.intel.com with ESMTP; 25 Oct 2012 05:44:23 -0700
Received: from fmsmsx151.amr.corp.intel.com (10.19.17.220) by
	FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 25 Oct 2012 05:44:23 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX151.amr.corp.intel.com (10.19.17.220) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 25 Oct 2012 05:44:22 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.186]) with mapi id
	14.01.0355.002; Thu, 25 Oct 2012 20:44:21 +0800
From: "Liu, Jinsong" 
To: Jan Beulich , George Dunlap
	, Ian Jackson 
Thread-Topic: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration when
	vMCE	occur
Thread-Index: AQHNsqzG1d0fFTiH/k2kGLRULCwaEZfJ9KCw
Date: Thu, 25 Oct 2012 12:44:20 +0000
Message-ID: 
References: 
	<20609.26910.2416.305293@mariner.uk.xensource.com>
	
	
	<20617.8367.946706.92097@mariner.uk.xensource.com>
	<50894D6202000078000A47FE@nat28.tlf.novell.com>
In-Reply-To: <50894D6202000078000A47FE@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , IanCampbell 
Subject: Re: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration
	when	vMCE	occur
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Jan Beulich wrote:
>>>> On 25.10.12 at 13:21, Ian Jackson 
>>>> wrote: 
>> Liu, Jinsong writes ("Re: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live
>> migration when	vMCE	occur"):
>>> Update patch 4/5 as attached.
>> 
>> Thanks.  As for the tools parts:
>> 
>> Acked-by: Ian Jackson 
> 
> Now I'm confused - wasn't the earlier discussion leading towards
> this patch being unnecessary (patch alone 5 being sufficient)?
> 
> Anyway, I think there were resubmission plans for both of the
> remaining patches anyway - Jinsong?
> 
> Jan

A little bit confusing here.

I think IanJ acked for my updated patch according to his comments earlier. Later, George present an approach about how to handle the case 'vMCE occur during migration' (patch 4). IMO it's perfect. So please temporarily not check patch4/5 in, I will update later.

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 12:47:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 12:47:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRMqZ-0003is-8g; Thu, 25 Oct 2012 12:47:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRMqX-0003id-IR
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 12:47:37 +0000
Received: from [85.158.139.83:27167] by server-7.bemta-5.messagelabs.com id
	08/B1-23102-8E439805; Thu, 25 Oct 2012 12:47:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1351169256!34256964!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7588 invoked from network); 25 Oct 2012 12:47:36 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-182.messagelabs.com with SMTP;
	25 Oct 2012 12:47:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 25 Oct 2012 13:49:58 +0100
Message-Id: <5089510702000078000A484C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 25 Oct 2012 13:47:35 +0100
From: "Jan Beulich" 
To: "Jean Guyader" 
References: <1351165926-23259-1-git-send-email-jean.guyader@citrix.com>
	<1351165926-23259-4-git-send-email-jean.guyader@citrix.com>
In-Reply-To: <1351165926-23259-4-git-send-email-jean.guyader@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3/3] xen: Add V4V implementation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 25.10.12 at 13:52, Jean Guyader  wrote:
>+typedef struct v4v_ring_data_ent
>+{
>+    v4v_addr_t ring;
>+    uint16_t flags;

Missing padding here?

>+    uint32_t space_required;
>+    uint32_t max_message_size;
>+} v4v_ring_data_ent_t;

>+typedef struct v4vtables_rule
>+{
>+    v4v_addr_t src;
>+    v4v_addr_t dst;
>+    uint32_t accept;
>+    uint32_t pad;

Pointless padding here?

>+} v4vtables_rule_t;

>+DEFINE_XEN_GUEST_HANDLE (v4v_iov_t);
>+DEFINE_XEN_GUEST_HANDLE (v4v_addr_t);
>+DEFINE_XEN_GUEST_HANDLE (v4v_send_addr_t);
>+DEFINE_XEN_GUEST_HANDLE (v4v_ring_t);
>+DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_ent_t);
>+DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_t);
>+DEFINE_XEN_GUEST_HANDLE (v4v_info_t);
>+DEFINE_XEN_GUEST_HANDLE (v4v_pfn_t);
>+
>+DEFINE_XEN_GUEST_HANDLE (v4vtables_rule_t);
>+DEFINE_XEN_GUEST_HANDLE (v4vtables_list_t);

Extra blanks before opening parens (also elsewhere).

>+/*
>+ * Helper functions
>+ */
>+
>+static inline uint16_t
>+v4v_hash_fn (v4v_ring_id_t *id)
>+{

These and the types further down make sense to be put in a
globally visible header only if they are expected to be used
from more than one source file.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 12:47:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 12:47:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRMqZ-0003is-8g; Thu, 25 Oct 2012 12:47:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRMqX-0003id-IR
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 12:47:37 +0000
Received: from [85.158.139.83:27167] by server-7.bemta-5.messagelabs.com id
	08/B1-23102-8E439805; Thu, 25 Oct 2012 12:47:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1351169256!34256964!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7588 invoked from network); 25 Oct 2012 12:47:36 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-182.messagelabs.com with SMTP;
	25 Oct 2012 12:47:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 25 Oct 2012 13:49:58 +0100
Message-Id: <5089510702000078000A484C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 25 Oct 2012 13:47:35 +0100
From: "Jan Beulich" 
To: "Jean Guyader" 
References: <1351165926-23259-1-git-send-email-jean.guyader@citrix.com>
	<1351165926-23259-4-git-send-email-jean.guyader@citrix.com>
In-Reply-To: <1351165926-23259-4-git-send-email-jean.guyader@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3/3] xen: Add V4V implementation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 25.10.12 at 13:52, Jean Guyader  wrote:
>+typedef struct v4v_ring_data_ent
>+{
>+    v4v_addr_t ring;
>+    uint16_t flags;

Missing padding here?

>+    uint32_t space_required;
>+    uint32_t max_message_size;
>+} v4v_ring_data_ent_t;

>+typedef struct v4vtables_rule
>+{
>+    v4v_addr_t src;
>+    v4v_addr_t dst;
>+    uint32_t accept;
>+    uint32_t pad;

Pointless padding here?

>+} v4vtables_rule_t;

>+DEFINE_XEN_GUEST_HANDLE (v4v_iov_t);
>+DEFINE_XEN_GUEST_HANDLE (v4v_addr_t);
>+DEFINE_XEN_GUEST_HANDLE (v4v_send_addr_t);
>+DEFINE_XEN_GUEST_HANDLE (v4v_ring_t);
>+DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_ent_t);
>+DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_t);
>+DEFINE_XEN_GUEST_HANDLE (v4v_info_t);
>+DEFINE_XEN_GUEST_HANDLE (v4v_pfn_t);
>+
>+DEFINE_XEN_GUEST_HANDLE (v4vtables_rule_t);
>+DEFINE_XEN_GUEST_HANDLE (v4vtables_list_t);

Extra blanks before opening parens (also elsewhere).

>+/*
>+ * Helper functions
>+ */
>+
>+static inline uint16_t
>+v4v_hash_fn (v4v_ring_id_t *id)
>+{

These and the types further down make sense to be put in a
globally visible header only if they are expected to be used
from more than one source file.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 12:51:34 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 12:51:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRMuA-0003t7-TE; Thu, 25 Oct 2012 12:51:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRMu9-0003t2-0B
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 12:51:21 +0000
Received: from [193.109.254.147:16934] by server-10.bemta-14.messagelabs.com
	id 13/99-31741-8C539805; Thu, 25 Oct 2012 12:51:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1351169479!4137591!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8286 invoked from network); 25 Oct 2012 12:51:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 12:51:19 -0000
X-IronPort-AV: E=Sophos;i="4.80,646,1344211200"; d="scan'208";a="15388279"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 12:51:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 13:51:18 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TRMu6-0004bP-Nl; Thu, 25 Oct 2012 12:51:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TRMu6-0000uH-JX;
	Thu, 25 Oct 2012 13:51:18 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20617.13766.270465.139091@mariner.uk.xensource.com>
Date: Thu, 25 Oct 2012 13:51:18 +0100
To: "Liu, Jinsong" 
In-Reply-To: 
References: 
	<20609.26910.2416.305293@mariner.uk.xensource.com>
	
	
	<20617.8367.946706.92097@mariner.uk.xensource.com>
	<50894D6202000078000A47FE@nat28.tlf.novell.com>
	
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	George Dunlap ,
	Ian Jackson , Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration
	when	vMCE	occur
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Liu, Jinsong writes ("RE: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration when	vMCE occur"):
> I think IanJ acked for my updated patch according to his comments earlier. Later, George present an approach about how to handle the case 'vMCE occur during migration' (patch 4). IMO it's perfect. So please temporarily not check patch4/5 in, I will update later.

Ah I missed George's comments, OK.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 12:51:34 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 12:51:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRMuA-0003t7-TE; Thu, 25 Oct 2012 12:51:22 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRMu9-0003t2-0B
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 12:51:21 +0000
Received: from [193.109.254.147:16934] by server-10.bemta-14.messagelabs.com
	id 13/99-31741-8C539805; Thu, 25 Oct 2012 12:51:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1351169479!4137591!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8286 invoked from network); 25 Oct 2012 12:51:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 12:51:19 -0000
X-IronPort-AV: E=Sophos;i="4.80,646,1344211200"; d="scan'208";a="15388279"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 12:51:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 13:51:18 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TRMu6-0004bP-Nl; Thu, 25 Oct 2012 12:51:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TRMu6-0000uH-JX;
	Thu, 25 Oct 2012 13:51:18 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20617.13766.270465.139091@mariner.uk.xensource.com>
Date: Thu, 25 Oct 2012 13:51:18 +0100
To: "Liu, Jinsong" 
In-Reply-To: 
References: 
	<20609.26910.2416.305293@mariner.uk.xensource.com>
	
	
	<20617.8367.946706.92097@mariner.uk.xensource.com>
	<50894D6202000078000A47FE@nat28.tlf.novell.com>
	
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	George Dunlap ,
	Ian Jackson , Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration
	when	vMCE	occur
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Liu, Jinsong writes ("RE: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration when	vMCE occur"):
> I think IanJ acked for my updated patch according to his comments earlier. Later, George present an approach about how to handle the case 'vMCE occur during migration' (patch 4). IMO it's perfect. So please temporarily not check patch4/5 in, I will update later.

Ah I missed George's comments, OK.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 13:05:48 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 13:05:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRN7r-0004D2-9c; Thu, 25 Oct 2012 13:05:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRN7p-0004Cx-JL
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 13:05:29 +0000
Received: from [85.158.138.51:11390] by server-4.bemta-3.messagelabs.com id
	D4/A9-01405-81939805; Thu, 25 Oct 2012 13:05:28 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1351170327!18498865!1
X-Originating-IP: [209.85.212.169]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3194 invoked from network); 25 Oct 2012 13:05:28 -0000
Received: from mail-wi0-f169.google.com (HELO mail-wi0-f169.google.com)
	(209.85.212.169)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 13:05:28 -0000
Received: by mail-wi0-f169.google.com with SMTP id hq4so4939030wib.0
	for ;
	Thu, 25 Oct 2012 06:05:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:subject:from:to:cc:date:in-reply-to:references
	:content-type:x-mailer:mime-version;
	bh=oJVlT5dYwjdYE+wfmlh+ttz4AT4nvU3/WQfzq2/HqTc=;
	b=VDbLfk+jxxkyNiUhwoN+FdAa2B2FABLfDtEwnUW4ffiOuWtFdNt2nHkI+BmfUe464N
	PiaRWJ68/b9B/v+LyyBLILVos9hH3hYSJdzH19ObOSSRkFjFrYDhyeervubdjh2mAshi
	Q9g6LcSyzq8grvtQ96yfGgcJQqnErbrrFUAN2zrLNdk0qU2lpVItcSY/VVpLhqNkNuwM
	bTRjLTHe+PLMKcOJRL0Jz8K9iS7ATrJ8ner7v+IsTuBdnF99QGA16NpkY0X4QNENyZJ9
	/F8qg2IKGAOlT3GJoY+XsHiUZqxZpyhkmeesXDedhNS/VunTSg85ne7otfgDugpcWqrv
	s7FA==
Received: by 10.216.45.144 with SMTP id p16mr11870726web.170.1351170327321;
	Thu, 25 Oct 2012 06:05:27 -0700 (PDT)
Received: from [192.168.0.40] (ip-180-234.sn1.eutelia.it. [62.94.180.234])
	by mx.google.com with ESMTPS id hb6sm9847951wib.7.2012.10.25.06.05.25
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 25 Oct 2012 06:05:26 -0700 (PDT)
Message-ID: <1351170318.18330.20.camel@Solace>
From: Dario Faggioli 
To: Vasiliy Tolstov 
Date: Thu, 25 Oct 2012 15:05:18 +0200
In-Reply-To: 
References: 
X-Mailer: Evolution 3.4.4-1
Mime-Version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] status of the curernt virtio support under xen pvm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============6701376683847870711=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============6701376683847870711==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-Z1AAPhbK5rERLXV7m/l1"


--=-Z1AAPhbK5rERLXV7m/l1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-10-25 at 11:36 +0400, Vasiliy Tolstov wrote:
> Hello,=20
>
Hi,

> xen-team. Does xen have any progress for supporting virtio
> after publishing this wiki page http://wiki.xen.org/wiki/Virtio_On_Xen
> ?
>
I really think I'm the _worst_ person to tr to reply to such question...
Anyway, I don't think we support virtio in any decent way and, although
I'm not sure whether that WiKi page is properly updated, I think that if
you want to work on that, there should be plenty of things to do. :-)

> Does xen 4.2 have support virtio on dom0 side?
>=20
I'd say no. But, again, don't trust me!

Thanks and Regards,
Dario

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-Z1AAPhbK5rERLXV7m/l1
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlCJOQ4ACgkQk4XaBE3IOsTKeACeKdFUycPdsd4KTKMcZGH7dH2q
I8AAoJ+AHB4IqZKdbCgjW75AHnwrew9R
=EjKZ
-----END PGP SIGNATURE-----

--=-Z1AAPhbK5rERLXV7m/l1--



--===============6701376683847870711==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6701376683847870711==--



From xen-devel-bounces@lists.xen.org Thu Oct 25 13:05:48 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 13:05:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRN7r-0004D2-9c; Thu, 25 Oct 2012 13:05:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRN7p-0004Cx-JL
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 13:05:29 +0000
Received: from [85.158.138.51:11390] by server-4.bemta-3.messagelabs.com id
	D4/A9-01405-81939805; Thu, 25 Oct 2012 13:05:28 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1351170327!18498865!1
X-Originating-IP: [209.85.212.169]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3194 invoked from network); 25 Oct 2012 13:05:28 -0000
Received: from mail-wi0-f169.google.com (HELO mail-wi0-f169.google.com)
	(209.85.212.169)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 13:05:28 -0000
Received: by mail-wi0-f169.google.com with SMTP id hq4so4939030wib.0
	for ;
	Thu, 25 Oct 2012 06:05:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:subject:from:to:cc:date:in-reply-to:references
	:content-type:x-mailer:mime-version;
	bh=oJVlT5dYwjdYE+wfmlh+ttz4AT4nvU3/WQfzq2/HqTc=;
	b=VDbLfk+jxxkyNiUhwoN+FdAa2B2FABLfDtEwnUW4ffiOuWtFdNt2nHkI+BmfUe464N
	PiaRWJ68/b9B/v+LyyBLILVos9hH3hYSJdzH19ObOSSRkFjFrYDhyeervubdjh2mAshi
	Q9g6LcSyzq8grvtQ96yfGgcJQqnErbrrFUAN2zrLNdk0qU2lpVItcSY/VVpLhqNkNuwM
	bTRjLTHe+PLMKcOJRL0Jz8K9iS7ATrJ8ner7v+IsTuBdnF99QGA16NpkY0X4QNENyZJ9
	/F8qg2IKGAOlT3GJoY+XsHiUZqxZpyhkmeesXDedhNS/VunTSg85ne7otfgDugpcWqrv
	s7FA==
Received: by 10.216.45.144 with SMTP id p16mr11870726web.170.1351170327321;
	Thu, 25 Oct 2012 06:05:27 -0700 (PDT)
Received: from [192.168.0.40] (ip-180-234.sn1.eutelia.it. [62.94.180.234])
	by mx.google.com with ESMTPS id hb6sm9847951wib.7.2012.10.25.06.05.25
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 25 Oct 2012 06:05:26 -0700 (PDT)
Message-ID: <1351170318.18330.20.camel@Solace>
From: Dario Faggioli 
To: Vasiliy Tolstov 
Date: Thu, 25 Oct 2012 15:05:18 +0200
In-Reply-To: 
References: 
X-Mailer: Evolution 3.4.4-1
Mime-Version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] status of the curernt virtio support under xen pvm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============6701376683847870711=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============6701376683847870711==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-Z1AAPhbK5rERLXV7m/l1"


--=-Z1AAPhbK5rERLXV7m/l1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-10-25 at 11:36 +0400, Vasiliy Tolstov wrote:
> Hello,=20
>
Hi,

> xen-team. Does xen have any progress for supporting virtio
> after publishing this wiki page http://wiki.xen.org/wiki/Virtio_On_Xen
> ?
>
I really think I'm the _worst_ person to tr to reply to such question...
Anyway, I don't think we support virtio in any decent way and, although
I'm not sure whether that WiKi page is properly updated, I think that if
you want to work on that, there should be plenty of things to do. :-)

> Does xen 4.2 have support virtio on dom0 side?
>=20
I'd say no. But, again, don't trust me!

Thanks and Regards,
Dario

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-Z1AAPhbK5rERLXV7m/l1
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlCJOQ4ACgkQk4XaBE3IOsTKeACeKdFUycPdsd4KTKMcZGH7dH2q
I8AAoJ+AHB4IqZKdbCgjW75AHnwrew9R
=EjKZ
-----END PGP SIGNATURE-----

--=-Z1AAPhbK5rERLXV7m/l1--



--===============6701376683847870711==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6701376683847870711==--



From xen-devel-bounces@lists.xen.org Thu Oct 25 13:12:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 13:12:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRNEM-0004N7-BQ; Thu, 25 Oct 2012 13:12:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRNEL-0004N1-1S
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 13:12:13 +0000
Received: from [85.158.138.51:59988] by server-7.bemta-3.messagelabs.com id
	6A/A8-06991-CAA39805; Thu, 25 Oct 2012 13:12:12 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1351170727!18500063!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjIzMTI0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6427 invoked from network); 25 Oct 2012 13:12:08 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-7.tower-174.messagelabs.com with SMTP;
	25 Oct 2012 13:12:08 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 25 Oct 2012 06:12:06 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,646,1344236400"; 
	d="scan'208,223";a="209179775"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by azsmga001.ch.intel.com with ESMTP; 25 Oct 2012 06:12:06 -0700
Received: from fmsmsx152.amr.corp.intel.com (10.19.17.221) by
	FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 25 Oct 2012 06:12:06 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	fmsmsx152.amr.corp.intel.com (10.19.17.221) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 25 Oct 2012 06:12:05 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.186]) with mapi id
	14.01.0355.002; Thu, 25 Oct 2012 21:12:04 +0800
From: "Liu, Jinsong" 
To: Konrad Rzeszutek Wilk ,
	"linux-kernel@vger.kernel.org" ,
	"xen-devel@lists.xensource.com" 
Thread-Topic: [PATCH 2/2] Revert pad config check in xen_check_mwait
Thread-Index: Ac2yslLcYde/7kJ6SnCXVbHberM6CA==
Date: Thu, 25 Oct 2012 13:12:02 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC8292335371767SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 2/2] Revert pad config check in xen_check_mwait
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC8292335371767SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Seems my mail server has a little problem, so re-send it. If you receive it=
 twice, please ignore one. Sorry :)

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>From 9ed5cd6012ac0832973be6e7fa01fc159f373e1c Mon Sep 17 00:00:00 2001
From: Liu, Jinsong 
Date: Fri, 26 Oct 2012 03:14:46 +0800
Subject: [PATCH 2/2] Revert pad config check in xen_check_mwait

With Xen acpi pad logic added into kernel, we can now revert xen mwait rela=
ted
patch df88b2d96e36d9a9e325bfcd12eb45671cbbc937. The reason is, when runs un=
der
Xen platform, Xen pad driver would be early loaded, so native pad driver wo=
uld
fail to be loaded, and hence no mwait/monitor #UD risk again.

Signed-off-by: Liu, Jinsong 
---
 arch/x86/xen/enlighten.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 586d838..8bf28b1 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -287,8 +287,7 @@ static void xen_cpuid(unsigned int *ax, unsigned int *b=
x,
=20
 static bool __init xen_check_mwait(void)
 {
-#if defined(CONFIG_ACPI) && !defined(CONFIG_ACPI_PROCESSOR_AGGREGATOR) && =
\
-	!defined(CONFIG_ACPI_PROCESSOR_AGGREGATOR_MODULE)
+#ifdef CONFIG_ACPI
 	struct xen_platform_op op =3D {
 		.cmd			=3D XENPF_set_processor_pminfo,
 		.u.set_pminfo.id	=3D -1,
--=20
1.7.1

--_002_DE8DF0795D48FD4CA783C40EC8292335371767SHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="0002-Revert-pad-config-check-in-xen_check_mwait.patch"
Content-Description: 0002-Revert-pad-config-check-in-xen_check_mwait.patch
Content-Disposition: attachment;
	filename="0002-Revert-pad-config-check-in-xen_check_mwait.patch"; size=1201;
	creation-date="Thu, 25 Oct 2012 12:15:46 GMT";
	modification-date="Thu, 25 Oct 2012 20:07:22 GMT"
Content-Transfer-Encoding: base64

RnJvbSA5ZWQ1Y2Q2MDEyYWMwODMyOTczYmU2ZTdmYTAxZmMxNTlmMzczZTFjIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4K
RGF0ZTogRnJpLCAyNiBPY3QgMjAxMiAwMzoxNDo0NiArMDgwMApTdWJqZWN0OiBbUEFUQ0ggMi8y
XSBSZXZlcnQgcGFkIGNvbmZpZyBjaGVjayBpbiB4ZW5fY2hlY2tfbXdhaXQKCldpdGggWGVuIGFj
cGkgcGFkIGxvZ2ljIGFkZGVkIGludG8ga2VybmVsLCB3ZSBjYW4gbm93IHJldmVydCB4ZW4gbXdh
aXQgcmVsYXRlZApwYXRjaCBkZjg4YjJkOTZlMzZkOWE5ZTMyNWJmY2QxMmViNDU2NzFjYmJjOTM3
LiBUaGUgcmVhc29uIGlzLCB3aGVuIHJ1bnMgdW5kZXIKWGVuIHBsYXRmb3JtLCBYZW4gcGFkIGRy
aXZlciB3b3VsZCBiZSBlYXJseSBsb2FkZWQsIHNvIG5hdGl2ZSBwYWQgZHJpdmVyIHdvdWxkCmZh
aWwgdG8gYmUgbG9hZGVkLCBhbmQgaGVuY2Ugbm8gbXdhaXQvbW9uaXRvciAjVUQgcmlzayBhZ2Fp
bi4KClNpZ25lZC1vZmYtYnk6IExpdSwgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgot
LS0KIGFyY2gveDg2L3hlbi9lbmxpZ2h0ZW4uYyB8ICAgIDMgKy0tCiAxIGZpbGVzIGNoYW5nZWQs
IDEgaW5zZXJ0aW9ucygrKSwgMiBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9hcmNoL3g4Ni94
ZW4vZW5saWdodGVuLmMgYi9hcmNoL3g4Ni94ZW4vZW5saWdodGVuLmMKaW5kZXggNTg2ZDgzOC4u
OGJmMjhiMSAxMDA2NDQKLS0tIGEvYXJjaC94ODYveGVuL2VubGlnaHRlbi5jCisrKyBiL2FyY2gv
eDg2L3hlbi9lbmxpZ2h0ZW4uYwpAQCAtMjg3LDggKzI4Nyw3IEBAIHN0YXRpYyB2b2lkIHhlbl9j
cHVpZCh1bnNpZ25lZCBpbnQgKmF4LCB1bnNpZ25lZCBpbnQgKmJ4LAogCiBzdGF0aWMgYm9vbCBf
X2luaXQgeGVuX2NoZWNrX213YWl0KHZvaWQpCiB7Ci0jaWYgZGVmaW5lZChDT05GSUdfQUNQSSkg
JiYgIWRlZmluZWQoQ09ORklHX0FDUElfUFJPQ0VTU09SX0FHR1JFR0FUT1IpICYmIFwKLQkhZGVm
aW5lZChDT05GSUdfQUNQSV9QUk9DRVNTT1JfQUdHUkVHQVRPUl9NT0RVTEUpCisjaWZkZWYgQ09O
RklHX0FDUEkKIAlzdHJ1Y3QgeGVuX3BsYXRmb3JtX29wIG9wID0gewogCQkuY21kCQkJPSBYRU5Q
Rl9zZXRfcHJvY2Vzc29yX3BtaW5mbywKIAkJLnUuc2V0X3BtaW5mby5pZAk9IC0xLAotLSAKMS43
LjEKCg==

--_002_DE8DF0795D48FD4CA783C40EC8292335371767SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC8292335371767SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Thu Oct 25 13:12:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 13:12:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRNEM-0004N7-BQ; Thu, 25 Oct 2012 13:12:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRNEL-0004N1-1S
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 13:12:13 +0000
Received: from [85.158.138.51:59988] by server-7.bemta-3.messagelabs.com id
	6A/A8-06991-CAA39805; Thu, 25 Oct 2012 13:12:12 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1351170727!18500063!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjIzMTI0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6427 invoked from network); 25 Oct 2012 13:12:08 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-7.tower-174.messagelabs.com with SMTP;
	25 Oct 2012 13:12:08 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 25 Oct 2012 06:12:06 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,646,1344236400"; 
	d="scan'208,223";a="209179775"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by azsmga001.ch.intel.com with ESMTP; 25 Oct 2012 06:12:06 -0700
Received: from fmsmsx152.amr.corp.intel.com (10.19.17.221) by
	FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 25 Oct 2012 06:12:06 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	fmsmsx152.amr.corp.intel.com (10.19.17.221) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 25 Oct 2012 06:12:05 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.186]) with mapi id
	14.01.0355.002; Thu, 25 Oct 2012 21:12:04 +0800
From: "Liu, Jinsong" 
To: Konrad Rzeszutek Wilk ,
	"linux-kernel@vger.kernel.org" ,
	"xen-devel@lists.xensource.com" 
Thread-Topic: [PATCH 2/2] Revert pad config check in xen_check_mwait
Thread-Index: Ac2yslLcYde/7kJ6SnCXVbHberM6CA==
Date: Thu, 25 Oct 2012 13:12:02 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC8292335371767SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 2/2] Revert pad config check in xen_check_mwait
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC8292335371767SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Seems my mail server has a little problem, so re-send it. If you receive it=
 twice, please ignore one. Sorry :)

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>From 9ed5cd6012ac0832973be6e7fa01fc159f373e1c Mon Sep 17 00:00:00 2001
From: Liu, Jinsong 
Date: Fri, 26 Oct 2012 03:14:46 +0800
Subject: [PATCH 2/2] Revert pad config check in xen_check_mwait

With Xen acpi pad logic added into kernel, we can now revert xen mwait rela=
ted
patch df88b2d96e36d9a9e325bfcd12eb45671cbbc937. The reason is, when runs un=
der
Xen platform, Xen pad driver would be early loaded, so native pad driver wo=
uld
fail to be loaded, and hence no mwait/monitor #UD risk again.

Signed-off-by: Liu, Jinsong 
---
 arch/x86/xen/enlighten.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 586d838..8bf28b1 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -287,8 +287,7 @@ static void xen_cpuid(unsigned int *ax, unsigned int *b=
x,
=20
 static bool __init xen_check_mwait(void)
 {
-#if defined(CONFIG_ACPI) && !defined(CONFIG_ACPI_PROCESSOR_AGGREGATOR) && =
\
-	!defined(CONFIG_ACPI_PROCESSOR_AGGREGATOR_MODULE)
+#ifdef CONFIG_ACPI
 	struct xen_platform_op op =3D {
 		.cmd			=3D XENPF_set_processor_pminfo,
 		.u.set_pminfo.id	=3D -1,
--=20
1.7.1

--_002_DE8DF0795D48FD4CA783C40EC8292335371767SHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="0002-Revert-pad-config-check-in-xen_check_mwait.patch"
Content-Description: 0002-Revert-pad-config-check-in-xen_check_mwait.patch
Content-Disposition: attachment;
	filename="0002-Revert-pad-config-check-in-xen_check_mwait.patch"; size=1201;
	creation-date="Thu, 25 Oct 2012 12:15:46 GMT";
	modification-date="Thu, 25 Oct 2012 20:07:22 GMT"
Content-Transfer-Encoding: base64

RnJvbSA5ZWQ1Y2Q2MDEyYWMwODMyOTczYmU2ZTdmYTAxZmMxNTlmMzczZTFjIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4K
RGF0ZTogRnJpLCAyNiBPY3QgMjAxMiAwMzoxNDo0NiArMDgwMApTdWJqZWN0OiBbUEFUQ0ggMi8y
XSBSZXZlcnQgcGFkIGNvbmZpZyBjaGVjayBpbiB4ZW5fY2hlY2tfbXdhaXQKCldpdGggWGVuIGFj
cGkgcGFkIGxvZ2ljIGFkZGVkIGludG8ga2VybmVsLCB3ZSBjYW4gbm93IHJldmVydCB4ZW4gbXdh
aXQgcmVsYXRlZApwYXRjaCBkZjg4YjJkOTZlMzZkOWE5ZTMyNWJmY2QxMmViNDU2NzFjYmJjOTM3
LiBUaGUgcmVhc29uIGlzLCB3aGVuIHJ1bnMgdW5kZXIKWGVuIHBsYXRmb3JtLCBYZW4gcGFkIGRy
aXZlciB3b3VsZCBiZSBlYXJseSBsb2FkZWQsIHNvIG5hdGl2ZSBwYWQgZHJpdmVyIHdvdWxkCmZh
aWwgdG8gYmUgbG9hZGVkLCBhbmQgaGVuY2Ugbm8gbXdhaXQvbW9uaXRvciAjVUQgcmlzayBhZ2Fp
bi4KClNpZ25lZC1vZmYtYnk6IExpdSwgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgot
LS0KIGFyY2gveDg2L3hlbi9lbmxpZ2h0ZW4uYyB8ICAgIDMgKy0tCiAxIGZpbGVzIGNoYW5nZWQs
IDEgaW5zZXJ0aW9ucygrKSwgMiBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9hcmNoL3g4Ni94
ZW4vZW5saWdodGVuLmMgYi9hcmNoL3g4Ni94ZW4vZW5saWdodGVuLmMKaW5kZXggNTg2ZDgzOC4u
OGJmMjhiMSAxMDA2NDQKLS0tIGEvYXJjaC94ODYveGVuL2VubGlnaHRlbi5jCisrKyBiL2FyY2gv
eDg2L3hlbi9lbmxpZ2h0ZW4uYwpAQCAtMjg3LDggKzI4Nyw3IEBAIHN0YXRpYyB2b2lkIHhlbl9j
cHVpZCh1bnNpZ25lZCBpbnQgKmF4LCB1bnNpZ25lZCBpbnQgKmJ4LAogCiBzdGF0aWMgYm9vbCBf
X2luaXQgeGVuX2NoZWNrX213YWl0KHZvaWQpCiB7Ci0jaWYgZGVmaW5lZChDT05GSUdfQUNQSSkg
JiYgIWRlZmluZWQoQ09ORklHX0FDUElfUFJPQ0VTU09SX0FHR1JFR0FUT1IpICYmIFwKLQkhZGVm
aW5lZChDT05GSUdfQUNQSV9QUk9DRVNTT1JfQUdHUkVHQVRPUl9NT0RVTEUpCisjaWZkZWYgQ09O
RklHX0FDUEkKIAlzdHJ1Y3QgeGVuX3BsYXRmb3JtX29wIG9wID0gewogCQkuY21kCQkJPSBYRU5Q
Rl9zZXRfcHJvY2Vzc29yX3BtaW5mbywKIAkJLnUuc2V0X3BtaW5mby5pZAk9IC0xLAotLSAKMS43
LjEKCg==

--_002_DE8DF0795D48FD4CA783C40EC8292335371767SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC8292335371767SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Thu Oct 25 13:43:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 13:43:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRNhx-0004gi-8c; Thu, 25 Oct 2012 13:42:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRNhw-0004gb-F0
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 13:42:48 +0000
Received: from [193.109.254.147:57167] by server-16.bemta-14.messagelabs.com
	id 08/68-09215-7D149805; Thu, 25 Oct 2012 13:42:47 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1351172565!9919805!1
X-Originating-IP: [209.85.219.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13682 invoked from network); 25 Oct 2012 13:42:47 -0000
Received: from mail-oa0-f45.google.com (HELO mail-oa0-f45.google.com)
	(209.85.219.45)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 13:42:47 -0000
Received: by mail-oa0-f45.google.com with SMTP id i18so2029356oag.32
	for ; Thu, 25 Oct 2012 06:42:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=ZFNcc9CcShhbUg6w+6o/tuZmNWMt13kmE+OlsXNJhJM=;
	b=Fw6lLu6b8L9ja8sI7HvErfKjlfPoghUN+UqSbA8iISya870rZRmrNi/b+RgU4WDJbm
	WIrFclpbQfHGB0fGlgMK7B2//66Q97M6fCt6u9ioC5jhhxg7Ur0loh+cIVcFTwOtOsMD
	ZKg/pFPexTsDmUTcfIjycX/8GWogZdIWoT0NlokI78HY/pTMmoj2hOjr7qSIzTTJ3UXv
	Jfu3+adEtIsIswxZ2HloWWOHFsNnJSe+GBC18y+XViLY3UGCEV1GmIop4tVd146w2okX
	Lrd9pJDtrtkpA33eC2K34IsfjDpGwm6hNAnrFUUWA6h2MTh7U0x980sAPWlUfOQ35nPf
	WJJw==
Received: by 10.182.124.102 with SMTP id mh6mr15475636obb.48.1351172565531;
	Thu, 25 Oct 2012 06:42:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.76.90.138 with HTTP; Thu, 25 Oct 2012 06:42:25 -0700 (PDT)
In-Reply-To: <1351165926-23259-3-git-send-email-jean.guyader@citrix.com>
References: <1351165926-23259-1-git-send-email-jean.guyader@citrix.com>
	<1351165926-23259-3-git-send-email-jean.guyader@citrix.com>
From: Jean Guyader 
Date: Thu, 25 Oct 2012 14:42:25 +0100
Message-ID: 
To: Jean Guyader 
Cc: tim@xen.org, JBeulich@suse.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2/3] xen: events,
	exposes evtchn_alloc_unbound_domain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 25 October 2012 12:52, Jean Guyader  wrote:
>
> Exposes evtchn_alloc_unbound_domain to the rest of
> Xen so we can create allocated unbound evtchn within Xen.
>
> Signed-off-by: Jean Guyader 
> ---
>  xen/common/event_channel.c |   39 +++++++++++++++++++++++++++------------
>  xen/include/xen/event.h    |    3 +++
>  2 files changed, 30 insertions(+), 12 deletions(-)
>

I think this patch could be applied on its own. That will make the
next v4v round
one patch smaller.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 13:43:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 13:43:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRNhx-0004gi-8c; Thu, 25 Oct 2012 13:42:49 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRNhw-0004gb-F0
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 13:42:48 +0000
Received: from [193.109.254.147:57167] by server-16.bemta-14.messagelabs.com
	id 08/68-09215-7D149805; Thu, 25 Oct 2012 13:42:47 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1351172565!9919805!1
X-Originating-IP: [209.85.219.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13682 invoked from network); 25 Oct 2012 13:42:47 -0000
Received: from mail-oa0-f45.google.com (HELO mail-oa0-f45.google.com)
	(209.85.219.45)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 13:42:47 -0000
Received: by mail-oa0-f45.google.com with SMTP id i18so2029356oag.32
	for ; Thu, 25 Oct 2012 06:42:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=ZFNcc9CcShhbUg6w+6o/tuZmNWMt13kmE+OlsXNJhJM=;
	b=Fw6lLu6b8L9ja8sI7HvErfKjlfPoghUN+UqSbA8iISya870rZRmrNi/b+RgU4WDJbm
	WIrFclpbQfHGB0fGlgMK7B2//66Q97M6fCt6u9ioC5jhhxg7Ur0loh+cIVcFTwOtOsMD
	ZKg/pFPexTsDmUTcfIjycX/8GWogZdIWoT0NlokI78HY/pTMmoj2hOjr7qSIzTTJ3UXv
	Jfu3+adEtIsIswxZ2HloWWOHFsNnJSe+GBC18y+XViLY3UGCEV1GmIop4tVd146w2okX
	Lrd9pJDtrtkpA33eC2K34IsfjDpGwm6hNAnrFUUWA6h2MTh7U0x980sAPWlUfOQ35nPf
	WJJw==
Received: by 10.182.124.102 with SMTP id mh6mr15475636obb.48.1351172565531;
	Thu, 25 Oct 2012 06:42:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.76.90.138 with HTTP; Thu, 25 Oct 2012 06:42:25 -0700 (PDT)
In-Reply-To: <1351165926-23259-3-git-send-email-jean.guyader@citrix.com>
References: <1351165926-23259-1-git-send-email-jean.guyader@citrix.com>
	<1351165926-23259-3-git-send-email-jean.guyader@citrix.com>
From: Jean Guyader 
Date: Thu, 25 Oct 2012 14:42:25 +0100
Message-ID: 
To: Jean Guyader 
Cc: tim@xen.org, JBeulich@suse.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2/3] xen: events,
	exposes evtchn_alloc_unbound_domain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 25 October 2012 12:52, Jean Guyader  wrote:
>
> Exposes evtchn_alloc_unbound_domain to the rest of
> Xen so we can create allocated unbound evtchn within Xen.
>
> Signed-off-by: Jean Guyader 
> ---
>  xen/common/event_channel.c |   39 +++++++++++++++++++++++++++------------
>  xen/include/xen/event.h    |    3 +++
>  2 files changed, 30 insertions(+), 12 deletions(-)
>

I think this patch could be applied on its own. That will make the
next v4v round
one patch smaller.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 13:47:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 13:47:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRNlz-0004pM-38; Thu, 25 Oct 2012 13:46:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRNlx-0004pG-C3
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 13:46:57 +0000
Received: from [85.158.138.51:5511] by server-2.bemta-3.messagelabs.com id
	99/0D-00604-0D249805; Thu, 25 Oct 2012 13:46:56 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1351172814!8725524!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAxNjY2Nw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28974 invoked from network); 25 Oct 2012 13:46:55 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Oct 2012 13:46:55 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9PDkcPG005099
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 25 Oct 2012 13:46:39 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9PDkbZb006154
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 25 Oct 2012 13:46:37 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9PDkY36026871; Thu, 25 Oct 2012 08:46:34 -0500
Received: from localhost.localdomain (/208.54.36.128)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 25 Oct 2012 06:46:34 -0700
Date: Thu, 25 Oct 2012 09:46:30 -0400
From: Konrad Rzeszutek Wilk 
To: Stefano Stabellini 
Message-ID: <20121025134628.GE26209@localhost.localdomain>
References: <20121024151957.28a1626cd9a59c014e78c401@canb.auug.org.au>
	<50885EA8.3050007@xenotime.net>
	<508906CE02000078000A4553@nat28.tlf.novell.com>
	
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Stephen Rothwell ,
	Jeremy Fitzhardinge ,
	"gregkh@linuxfoundation.org" ,
	"linux-kernel@vger.kernel.org" ,
	"virtualization@lists.linux-foundation.org"
	,
	Randy Dunlap ,
	"linux-next@vger.kernel.org" ,
	Jan Beulich , xen-devel 
Subject: Re: [Xen-devel] linux-next: Tree for Oct 24 (xen)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Oct 25, 2012 at 11:48:30AM +0100, Stefano Stabellini wrote:
> On Thu, 25 Oct 2012, Jan Beulich wrote:
> > >>> On 24.10.12 at 23:33, Randy Dunlap  wrote:
> > > On 10/23/2012 09:19 PM, Stephen Rothwell wrote:
> > > 
> > >> Hi all,
> > >> 
> > >> Changes since 201201023:
> > >> 
> > > 
> > > on x86_64:
> > > 
> > > drivers/built-in.o: In function `dbgp_reset_prep':
> > > (.text+0xb96b5): undefined reference to `xen_dbgp_reset_prep'
> > > drivers/built-in.o: In function `dbgp_external_startup':
> > > (.text+0xb9d95): undefined reference to `xen_dbgp_external_startup'
> > > 
> > > 
> > > Full randconfig file is attached.
> > 
> > So this is because with !USB_SUPPORT but EARLY_PRINTK_DBGP
> > dbgp_reset_prep() and dbgp_external_startup() get pointlessly
> > defined and exported. This got broken by the merge
> > recommendation for the ARM side changes (originally compilation
> > of drivers/xen/dbgp.c depended on just CONFIG_XEN_DOM0).
> > 
> > >From my pov, fixing the USB side would be the clean solution (i.e.
> > putting those function definitions inside a CONFIG_USB_SUPPORT
> > conditional).
> >
> > The alternative of a smaller change would be to extend the
> > conditional around the respective xen_dbgp_...() declarations
> > in include/linux/usb/ehci_def.h to become
> > 
> > #if defined(CONFIG_XEN_DOM0) && defined(CONFIG_USB_SUPPORT)
> > 
> > Please advise towards your preference.
> 
> I think that your first suggestion is the right one.

Can you guys spin up a patch pls and make sure it does not break
compilation. Thx.
> 
> 
> Otherwise we could also make drivers/xen/dbgp.c compile if
> CONFIG_EARLY_PRINTK_DBGP rather than CONFIG_USB_SUPPORT.
> I think that it would create fewer maintenance pains if dbgp_reset_prep
> and dbgp_external_startup had the same compile requirements as their xen
> counterparts (aside from Xen support of course).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 13:47:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 13:47:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRNlz-0004pM-38; Thu, 25 Oct 2012 13:46:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRNlx-0004pG-C3
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 13:46:57 +0000
Received: from [85.158.138.51:5511] by server-2.bemta-3.messagelabs.com id
	99/0D-00604-0D249805; Thu, 25 Oct 2012 13:46:56 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1351172814!8725524!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAxNjY2Nw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28974 invoked from network); 25 Oct 2012 13:46:55 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Oct 2012 13:46:55 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9PDkcPG005099
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 25 Oct 2012 13:46:39 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9PDkbZb006154
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 25 Oct 2012 13:46:37 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9PDkY36026871; Thu, 25 Oct 2012 08:46:34 -0500
Received: from localhost.localdomain (/208.54.36.128)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 25 Oct 2012 06:46:34 -0700
Date: Thu, 25 Oct 2012 09:46:30 -0400
From: Konrad Rzeszutek Wilk 
To: Stefano Stabellini 
Message-ID: <20121025134628.GE26209@localhost.localdomain>
References: <20121024151957.28a1626cd9a59c014e78c401@canb.auug.org.au>
	<50885EA8.3050007@xenotime.net>
	<508906CE02000078000A4553@nat28.tlf.novell.com>
	
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Stephen Rothwell ,
	Jeremy Fitzhardinge ,
	"gregkh@linuxfoundation.org" ,
	"linux-kernel@vger.kernel.org" ,
	"virtualization@lists.linux-foundation.org"
	,
	Randy Dunlap ,
	"linux-next@vger.kernel.org" ,
	Jan Beulich , xen-devel 
Subject: Re: [Xen-devel] linux-next: Tree for Oct 24 (xen)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Oct 25, 2012 at 11:48:30AM +0100, Stefano Stabellini wrote:
> On Thu, 25 Oct 2012, Jan Beulich wrote:
> > >>> On 24.10.12 at 23:33, Randy Dunlap  wrote:
> > > On 10/23/2012 09:19 PM, Stephen Rothwell wrote:
> > > 
> > >> Hi all,
> > >> 
> > >> Changes since 201201023:
> > >> 
> > > 
> > > on x86_64:
> > > 
> > > drivers/built-in.o: In function `dbgp_reset_prep':
> > > (.text+0xb96b5): undefined reference to `xen_dbgp_reset_prep'
> > > drivers/built-in.o: In function `dbgp_external_startup':
> > > (.text+0xb9d95): undefined reference to `xen_dbgp_external_startup'
> > > 
> > > 
> > > Full randconfig file is attached.
> > 
> > So this is because with !USB_SUPPORT but EARLY_PRINTK_DBGP
> > dbgp_reset_prep() and dbgp_external_startup() get pointlessly
> > defined and exported. This got broken by the merge
> > recommendation for the ARM side changes (originally compilation
> > of drivers/xen/dbgp.c depended on just CONFIG_XEN_DOM0).
> > 
> > >From my pov, fixing the USB side would be the clean solution (i.e.
> > putting those function definitions inside a CONFIG_USB_SUPPORT
> > conditional).
> >
> > The alternative of a smaller change would be to extend the
> > conditional around the respective xen_dbgp_...() declarations
> > in include/linux/usb/ehci_def.h to become
> > 
> > #if defined(CONFIG_XEN_DOM0) && defined(CONFIG_USB_SUPPORT)
> > 
> > Please advise towards your preference.
> 
> I think that your first suggestion is the right one.

Can you guys spin up a patch pls and make sure it does not break
compilation. Thx.
> 
> 
> Otherwise we could also make drivers/xen/dbgp.c compile if
> CONFIG_EARLY_PRINTK_DBGP rather than CONFIG_USB_SUPPORT.
> I think that it would create fewer maintenance pains if dbgp_reset_prep
> and dbgp_external_startup had the same compile requirements as their xen
> counterparts (aside from Xen support of course).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 13:47:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 13:47:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRNmY-0004rw-HR; Thu, 25 Oct 2012 13:47:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRNmX-0004rm-FI
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 13:47:33 +0000
Received: from [85.158.139.83:54171] by server-7.bemta-5.messagelabs.com id
	34/A8-23102-4F249805; Thu, 25 Oct 2012 13:47:32 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-16.tower-182.messagelabs.com!1351172851!29143299!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18762 invoked from network); 25 Oct 2012 13:47:32 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-16.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	25 Oct 2012 13:47:32 -0000
Received: from 255-64-ftth.onsneteindhoven.nl ([88.159.64.255]:49427
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TRNoV-0001A1-VS; Thu, 25 Oct 2012 15:49:36 +0200
Date: Thu, 25 Oct 2012 15:47:25 +0200
From: Sander Eikelenboom 
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <648905893.20121025154725@eikelenboom.it>
To: linux@eikelenboom.it
In-Reply-To: <1350688384-2482-2-git-send-email-linux@eikelenboom.it>
References: <1350688384-2482-1-git-send-email-linux@eikelenboom.it>
	<1350688384-2482-2-git-send-email-linux@eikelenboom.it>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/1] xl: Fix accidently waiting for domains
	to shutdown without --wait option
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ping ?

Saturday, October 20, 2012, 1:13:04 AM, you wrote:

> From: Sander Eikelenboom 

> Introduced by changeset 26091: "xl: Add --wait and --all to xl reboot."

> Signed-off-by: Sander Eikelenboom 
> ---
>  tools/libxl/xl_cmdimpl.c |    4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)

> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index dc80595..0e65f2b 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -3774,7 +3774,9 @@ static int main_shutdown_or_reboot(int reboot, int argc, char **argv)
>                 fallback_trigger);
>          }
>  
> -        wait_for_domain_deaths(deathws, nb_domain - 1 /* not dom 0 */);
> +        if (wait_for_it)
> +            wait_for_domain_deaths(deathws, nb_domain - 1 /* not dom 0 */);
> +
>          libxl_dominfo_list_free(dominfo, nb_domain);
>      } else {
>          libxl_evgen_domain_death *deathw = NULL;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 13:47:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 13:47:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRNmY-0004rw-HR; Thu, 25 Oct 2012 13:47:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRNmX-0004rm-FI
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 13:47:33 +0000
Received: from [85.158.139.83:54171] by server-7.bemta-5.messagelabs.com id
	34/A8-23102-4F249805; Thu, 25 Oct 2012 13:47:32 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-16.tower-182.messagelabs.com!1351172851!29143299!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18762 invoked from network); 25 Oct 2012 13:47:32 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-16.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	25 Oct 2012 13:47:32 -0000
Received: from 255-64-ftth.onsneteindhoven.nl ([88.159.64.255]:49427
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TRNoV-0001A1-VS; Thu, 25 Oct 2012 15:49:36 +0200
Date: Thu, 25 Oct 2012 15:47:25 +0200
From: Sander Eikelenboom 
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <648905893.20121025154725@eikelenboom.it>
To: linux@eikelenboom.it
In-Reply-To: <1350688384-2482-2-git-send-email-linux@eikelenboom.it>
References: <1350688384-2482-1-git-send-email-linux@eikelenboom.it>
	<1350688384-2482-2-git-send-email-linux@eikelenboom.it>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/1] xl: Fix accidently waiting for domains
	to shutdown without --wait option
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ping ?

Saturday, October 20, 2012, 1:13:04 AM, you wrote:

> From: Sander Eikelenboom 

> Introduced by changeset 26091: "xl: Add --wait and --all to xl reboot."

> Signed-off-by: Sander Eikelenboom 
> ---
>  tools/libxl/xl_cmdimpl.c |    4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)

> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index dc80595..0e65f2b 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -3774,7 +3774,9 @@ static int main_shutdown_or_reboot(int reboot, int argc, char **argv)
>                 fallback_trigger);
>          }
>  
> -        wait_for_domain_deaths(deathws, nb_domain - 1 /* not dom 0 */);
> +        if (wait_for_it)
> +            wait_for_domain_deaths(deathws, nb_domain - 1 /* not dom 0 */);
> +
>          libxl_dominfo_list_free(dominfo, nb_domain);
>      } else {
>          libxl_evgen_domain_death *deathw = NULL;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 13:53:03 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 13:53:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRNrY-000578-A3; Thu, 25 Oct 2012 13:52:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRNrX-000572-CX
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 13:52:43 +0000
Received: from [193.109.254.147:13152] by server-7.bemta-14.messagelabs.com id
	35/A8-24122-A2449805; Thu, 25 Oct 2012 13:52:42 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1351173159!1944666!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMzNTQ0NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7563 invoked from network); 25 Oct 2012 13:52:40 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-11.tower-27.messagelabs.com with SMTP;
	25 Oct 2012 13:52:40 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 25 Oct 2012 06:52:39 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,646,1344236400"; 
	d="scan'208,223";a="240107351"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by fmsmga002.fm.intel.com with ESMTP; 25 Oct 2012 05:21:56 -0700
Received: from fmsmsx102.amr.corp.intel.com (10.19.9.53) by
	FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 25 Oct 2012 05:21:56 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX102.amr.corp.intel.com (10.19.9.53) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 25 Oct 2012 05:21:56 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.123]) with mapi id
	14.01.0355.002; Thu, 25 Oct 2012 20:21:54 +0800
From: "Liu, Jinsong" 
To: Konrad Rzeszutek Wilk ,
	"linux-kernel@vger.kernel.org" ,
	"xen-devel@lists.xensource.com" 
Thread-Topic: [PATCH 2/2] Revert pad config check in xen_check_mwait
Thread-Index: Ac2yq1FN1e+6ZP87QOCrcigNApJpmA==
Date: Thu, 25 Oct 2012 12:21:53 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC8292335371593SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 2/2] Revert pad config check in xen_check_mwait
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC8292335371593SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 9ed5cd6012ac0832973be6e7fa01fc159f373e1c Mon Sep 17 00:00:00 2001
From: Liu, Jinsong 
Date: Fri, 26 Oct 2012 03:14:46 +0800
Subject: [PATCH 2/2] Revert pad config check in xen_check_mwait

With Xen acpi pad logic added into kernel, we can now revert xen mwait rela=
ted
patch df88b2d96e36d9a9e325bfcd12eb45671cbbc937. The reason is, when runs un=
der
Xen platform, Xen pad driver would be early loaded, so native pad driver wo=
uld
fail to be loaded, and hence no mwait/monitor #UD risk again.

Signed-off-by: Liu, Jinsong 
---
 arch/x86/xen/enlighten.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 586d838..8bf28b1 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -287,8 +287,7 @@ static void xen_cpuid(unsigned int *ax, unsigned int *b=
x,
=20
 static bool __init xen_check_mwait(void)
 {
-#if defined(CONFIG_ACPI) && !defined(CONFIG_ACPI_PROCESSOR_AGGREGATOR) && =
\
-	!defined(CONFIG_ACPI_PROCESSOR_AGGREGATOR_MODULE)
+#ifdef CONFIG_ACPI
 	struct xen_platform_op op =3D {
 		.cmd			=3D XENPF_set_processor_pminfo,
 		.u.set_pminfo.id	=3D -1,
--=20
1.7.1

--_002_DE8DF0795D48FD4CA783C40EC8292335371593SHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="0002-Revert-pad-config-check-in-xen_check_mwait.patch"
Content-Description: 0002-Revert-pad-config-check-in-xen_check_mwait.patch
Content-Disposition: attachment;
	filename="0002-Revert-pad-config-check-in-xen_check_mwait.patch"; size=1201;
	creation-date="Thu, 25 Oct 2012 12:15:46 GMT";
	modification-date="Thu, 25 Oct 2012 20:07:22 GMT"
Content-Transfer-Encoding: base64

RnJvbSA5ZWQ1Y2Q2MDEyYWMwODMyOTczYmU2ZTdmYTAxZmMxNTlmMzczZTFjIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4K
RGF0ZTogRnJpLCAyNiBPY3QgMjAxMiAwMzoxNDo0NiArMDgwMApTdWJqZWN0OiBbUEFUQ0ggMi8y
XSBSZXZlcnQgcGFkIGNvbmZpZyBjaGVjayBpbiB4ZW5fY2hlY2tfbXdhaXQKCldpdGggWGVuIGFj
cGkgcGFkIGxvZ2ljIGFkZGVkIGludG8ga2VybmVsLCB3ZSBjYW4gbm93IHJldmVydCB4ZW4gbXdh
aXQgcmVsYXRlZApwYXRjaCBkZjg4YjJkOTZlMzZkOWE5ZTMyNWJmY2QxMmViNDU2NzFjYmJjOTM3
LiBUaGUgcmVhc29uIGlzLCB3aGVuIHJ1bnMgdW5kZXIKWGVuIHBsYXRmb3JtLCBYZW4gcGFkIGRy
aXZlciB3b3VsZCBiZSBlYXJseSBsb2FkZWQsIHNvIG5hdGl2ZSBwYWQgZHJpdmVyIHdvdWxkCmZh
aWwgdG8gYmUgbG9hZGVkLCBhbmQgaGVuY2Ugbm8gbXdhaXQvbW9uaXRvciAjVUQgcmlzayBhZ2Fp
bi4KClNpZ25lZC1vZmYtYnk6IExpdSwgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgot
LS0KIGFyY2gveDg2L3hlbi9lbmxpZ2h0ZW4uYyB8ICAgIDMgKy0tCiAxIGZpbGVzIGNoYW5nZWQs
IDEgaW5zZXJ0aW9ucygrKSwgMiBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9hcmNoL3g4Ni94
ZW4vZW5saWdodGVuLmMgYi9hcmNoL3g4Ni94ZW4vZW5saWdodGVuLmMKaW5kZXggNTg2ZDgzOC4u
OGJmMjhiMSAxMDA2NDQKLS0tIGEvYXJjaC94ODYveGVuL2VubGlnaHRlbi5jCisrKyBiL2FyY2gv
eDg2L3hlbi9lbmxpZ2h0ZW4uYwpAQCAtMjg3LDggKzI4Nyw3IEBAIHN0YXRpYyB2b2lkIHhlbl9j
cHVpZCh1bnNpZ25lZCBpbnQgKmF4LCB1bnNpZ25lZCBpbnQgKmJ4LAogCiBzdGF0aWMgYm9vbCBf
X2luaXQgeGVuX2NoZWNrX213YWl0KHZvaWQpCiB7Ci0jaWYgZGVmaW5lZChDT05GSUdfQUNQSSkg
JiYgIWRlZmluZWQoQ09ORklHX0FDUElfUFJPQ0VTU09SX0FHR1JFR0FUT1IpICYmIFwKLQkhZGVm
aW5lZChDT05GSUdfQUNQSV9QUk9DRVNTT1JfQUdHUkVHQVRPUl9NT0RVTEUpCisjaWZkZWYgQ09O
RklHX0FDUEkKIAlzdHJ1Y3QgeGVuX3BsYXRmb3JtX29wIG9wID0gewogCQkuY21kCQkJPSBYRU5Q
Rl9zZXRfcHJvY2Vzc29yX3BtaW5mbywKIAkJLnUuc2V0X3BtaW5mby5pZAk9IC0xLAotLSAKMS43
LjEKCg==

--_002_DE8DF0795D48FD4CA783C40EC8292335371593SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC8292335371593SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Thu Oct 25 13:53:03 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 13:53:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRNrY-000578-A3; Thu, 25 Oct 2012 13:52:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRNrX-000572-CX
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 13:52:43 +0000
Received: from [193.109.254.147:13152] by server-7.bemta-14.messagelabs.com id
	35/A8-24122-A2449805; Thu, 25 Oct 2012 13:52:42 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1351173159!1944666!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMzNTQ0NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7563 invoked from network); 25 Oct 2012 13:52:40 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-11.tower-27.messagelabs.com with SMTP;
	25 Oct 2012 13:52:40 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 25 Oct 2012 06:52:39 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,646,1344236400"; 
	d="scan'208,223";a="240107351"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by fmsmga002.fm.intel.com with ESMTP; 25 Oct 2012 05:21:56 -0700
Received: from fmsmsx102.amr.corp.intel.com (10.19.9.53) by
	FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 25 Oct 2012 05:21:56 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX102.amr.corp.intel.com (10.19.9.53) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 25 Oct 2012 05:21:56 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.123]) with mapi id
	14.01.0355.002; Thu, 25 Oct 2012 20:21:54 +0800
From: "Liu, Jinsong" 
To: Konrad Rzeszutek Wilk ,
	"linux-kernel@vger.kernel.org" ,
	"xen-devel@lists.xensource.com" 
Thread-Topic: [PATCH 2/2] Revert pad config check in xen_check_mwait
Thread-Index: Ac2yq1FN1e+6ZP87QOCrcigNApJpmA==
Date: Thu, 25 Oct 2012 12:21:53 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC8292335371593SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 2/2] Revert pad config check in xen_check_mwait
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC8292335371593SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From 9ed5cd6012ac0832973be6e7fa01fc159f373e1c Mon Sep 17 00:00:00 2001
From: Liu, Jinsong 
Date: Fri, 26 Oct 2012 03:14:46 +0800
Subject: [PATCH 2/2] Revert pad config check in xen_check_mwait

With Xen acpi pad logic added into kernel, we can now revert xen mwait rela=
ted
patch df88b2d96e36d9a9e325bfcd12eb45671cbbc937. The reason is, when runs un=
der
Xen platform, Xen pad driver would be early loaded, so native pad driver wo=
uld
fail to be loaded, and hence no mwait/monitor #UD risk again.

Signed-off-by: Liu, Jinsong 
---
 arch/x86/xen/enlighten.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 586d838..8bf28b1 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -287,8 +287,7 @@ static void xen_cpuid(unsigned int *ax, unsigned int *b=
x,
=20
 static bool __init xen_check_mwait(void)
 {
-#if defined(CONFIG_ACPI) && !defined(CONFIG_ACPI_PROCESSOR_AGGREGATOR) && =
\
-	!defined(CONFIG_ACPI_PROCESSOR_AGGREGATOR_MODULE)
+#ifdef CONFIG_ACPI
 	struct xen_platform_op op =3D {
 		.cmd			=3D XENPF_set_processor_pminfo,
 		.u.set_pminfo.id	=3D -1,
--=20
1.7.1

--_002_DE8DF0795D48FD4CA783C40EC8292335371593SHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="0002-Revert-pad-config-check-in-xen_check_mwait.patch"
Content-Description: 0002-Revert-pad-config-check-in-xen_check_mwait.patch
Content-Disposition: attachment;
	filename="0002-Revert-pad-config-check-in-xen_check_mwait.patch"; size=1201;
	creation-date="Thu, 25 Oct 2012 12:15:46 GMT";
	modification-date="Thu, 25 Oct 2012 20:07:22 GMT"
Content-Transfer-Encoding: base64

RnJvbSA5ZWQ1Y2Q2MDEyYWMwODMyOTczYmU2ZTdmYTAxZmMxNTlmMzczZTFjIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4K
RGF0ZTogRnJpLCAyNiBPY3QgMjAxMiAwMzoxNDo0NiArMDgwMApTdWJqZWN0OiBbUEFUQ0ggMi8y
XSBSZXZlcnQgcGFkIGNvbmZpZyBjaGVjayBpbiB4ZW5fY2hlY2tfbXdhaXQKCldpdGggWGVuIGFj
cGkgcGFkIGxvZ2ljIGFkZGVkIGludG8ga2VybmVsLCB3ZSBjYW4gbm93IHJldmVydCB4ZW4gbXdh
aXQgcmVsYXRlZApwYXRjaCBkZjg4YjJkOTZlMzZkOWE5ZTMyNWJmY2QxMmViNDU2NzFjYmJjOTM3
LiBUaGUgcmVhc29uIGlzLCB3aGVuIHJ1bnMgdW5kZXIKWGVuIHBsYXRmb3JtLCBYZW4gcGFkIGRy
aXZlciB3b3VsZCBiZSBlYXJseSBsb2FkZWQsIHNvIG5hdGl2ZSBwYWQgZHJpdmVyIHdvdWxkCmZh
aWwgdG8gYmUgbG9hZGVkLCBhbmQgaGVuY2Ugbm8gbXdhaXQvbW9uaXRvciAjVUQgcmlzayBhZ2Fp
bi4KClNpZ25lZC1vZmYtYnk6IExpdSwgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgot
LS0KIGFyY2gveDg2L3hlbi9lbmxpZ2h0ZW4uYyB8ICAgIDMgKy0tCiAxIGZpbGVzIGNoYW5nZWQs
IDEgaW5zZXJ0aW9ucygrKSwgMiBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9hcmNoL3g4Ni94
ZW4vZW5saWdodGVuLmMgYi9hcmNoL3g4Ni94ZW4vZW5saWdodGVuLmMKaW5kZXggNTg2ZDgzOC4u
OGJmMjhiMSAxMDA2NDQKLS0tIGEvYXJjaC94ODYveGVuL2VubGlnaHRlbi5jCisrKyBiL2FyY2gv
eDg2L3hlbi9lbmxpZ2h0ZW4uYwpAQCAtMjg3LDggKzI4Nyw3IEBAIHN0YXRpYyB2b2lkIHhlbl9j
cHVpZCh1bnNpZ25lZCBpbnQgKmF4LCB1bnNpZ25lZCBpbnQgKmJ4LAogCiBzdGF0aWMgYm9vbCBf
X2luaXQgeGVuX2NoZWNrX213YWl0KHZvaWQpCiB7Ci0jaWYgZGVmaW5lZChDT05GSUdfQUNQSSkg
JiYgIWRlZmluZWQoQ09ORklHX0FDUElfUFJPQ0VTU09SX0FHR1JFR0FUT1IpICYmIFwKLQkhZGVm
aW5lZChDT05GSUdfQUNQSV9QUk9DRVNTT1JfQUdHUkVHQVRPUl9NT0RVTEUpCisjaWZkZWYgQ09O
RklHX0FDUEkKIAlzdHJ1Y3QgeGVuX3BsYXRmb3JtX29wIG9wID0gewogCQkuY21kCQkJPSBYRU5Q
Rl9zZXRfcHJvY2Vzc29yX3BtaW5mbywKIAkJLnUuc2V0X3BtaW5mby5pZAk9IC0xLAotLSAKMS43
LjEKCg==

--_002_DE8DF0795D48FD4CA783C40EC8292335371593SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC8292335371593SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Thu Oct 25 13:55:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 13:55:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRNte-0005DH-Re; Thu, 25 Oct 2012 13:54:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRNtd-0005DA-Kl
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 13:54:53 +0000
Received: from [85.158.138.51:32597] by server-13.bemta-3.messagelabs.com id
	7E/AD-24887-CA449805; Thu, 25 Oct 2012 13:54:52 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1351173291!27411192!1
X-Originating-IP: [213.199.154.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12400 invoked from network); 25 Oct 2012 13:54:52 -0000
Received: from am1ehsobe005.messaging.microsoft.com (HELO
	am1outboundpool.messaging.microsoft.com) (213.199.154.208)
	by server-11.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Oct 2012 13:54:52 -0000
Received: from mail33-am1-R.bigfish.com (10.3.201.251) by
	AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id
	14.1.225.23; Thu, 25 Oct 2012 13:54:48 +0000
Received: from mail33-am1 (localhost [127.0.0.1])	by mail33-am1-R.bigfish.com
	(Postfix) with ESMTP id 0B91134016D	for ;
	Thu, 25 Oct 2012 13:54:48 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzc85fhc85dhzz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh34h1155h)
Received: from mail33-am1 (localhost.localdomain [127.0.0.1]) by mail33-am1
	(MessageSwitch) id 1351173285240284_21893;
	Thu, 25 Oct 2012 13:54:45 +0000 (UTC)
Received: from AM1EHSMHS005.bigfish.com (unknown [10.3.201.241])	by
	mail33-am1.bigfish.com (Postfix) with ESMTP id 2EEE71200F3	for
	; Thu, 25 Oct 2012 13:54:45 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS005.bigfish.com (10.3.207.105) with Microsoft SMTP Server id
	14.1.225.23; Thu, 25 Oct 2012 13:54:42 +0000
X-WSS-ID: 0MCGBZ3-01-CJ6-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1) with ESMTP id 2C9C810280ED	for ;
	Thu, 25 Oct 2012 08:54:38 -0500 (CDT)
Received: from SAUSEXDAG06.amd.com (163.181.55.7) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 25 Oct 2012 08:54:55 -0500
Received: from STOREXDAG04.amd.com (10.1.13.13) by sausexdag06.amd.com
	(163.181.55.7) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Thu, 25 Oct 2012 08:54:38 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag04.amd.com
	(10.1.13.13) with Microsoft SMTP Server id 14.2.318.4; Thu, 25 Oct 2012
	09:54:37 -0400
Message-ID: <5089449C.7020700@amd.com>
Date: Thu, 25 Oct 2012 15:54:36 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" 
Content-Type: multipart/mixed; boundary="------------080306090603060904090803"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] MCE: support cpu notification chain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------080306090603060904090803
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit


Add support for cpu notification chain.
This is useful with nested virtualization when Xen
runs as l1 hypervisor.
This cleans up mce initialization cleanup as a side-effect.

Signed-off-by: Christoph Egger 


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------080306090603060904090803
Content-Type: text/plain; charset="us-ascii"; name="xen_mce_init.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_mce_init.diff"
Content-Description: xen_mce_init.diff

diff -r 7abb25095de0 xen/arch/x86/cpu/mcheck/mce.c
--- a/xen/arch/x86/cpu/mcheck/mce.c	Thu Oct 25 13:15:19 2012 +0200
+++ b/xen/arch/x86/cpu/mcheck/mce.c	Thu Oct 25 14:20:49 2012 +0200
@@ -560,30 +560,6 @@ void mcheck_mca_clearbanks(struct mca_ba
     }
 }
 
-static enum mcheck_type amd_mcheck_init(struct cpuinfo_x86 *ci)
-{
-    enum mcheck_type rc = mcheck_none;
-
-    switch (ci->x86) {
-    case 6:
-        rc = amd_k7_mcheck_init(ci);
-        break;
-
-    default:
-        /* Assume that machine check support is available.
-         * The minimum provided support is at least the K8. */
-    case 0xf:
-        rc = amd_k8_mcheck_init(ci);
-        break;
-
-    case 0x10 ... 0x17:
-        rc = amd_f10_mcheck_init(ci);
-        break;
-    }
-
-    return rc;
-}
-
 /*check the existence of Machine Check*/
 int mce_available(struct cpuinfo_x86 *c)
 {
@@ -774,7 +750,7 @@ void mcheck_init(struct cpuinfo_x86 *c, 
 
     switch (c->x86_vendor) {
     case X86_VENDOR_AMD:
-        inited = amd_mcheck_init(c);
+        inited = amd_mcheck_init(c, bsp);
         break;
 
     case X86_VENDOR_INTEL:
diff -r 7abb25095de0 xen/arch/x86/cpu/mcheck/mce.h
--- a/xen/arch/x86/cpu/mcheck/mce.h	Thu Oct 25 13:15:19 2012 +0200
+++ b/xen/arch/x86/cpu/mcheck/mce.h	Thu Oct 25 14:20:49 2012 +0200
@@ -39,10 +39,7 @@ enum mcheck_type {
 };
 
 /* Init functions */
-enum mcheck_type amd_k7_mcheck_init(struct cpuinfo_x86 *c);
-enum mcheck_type amd_k8_mcheck_init(struct cpuinfo_x86 *c);
-enum mcheck_type amd_f10_mcheck_init(struct cpuinfo_x86 *c);
-
+enum mcheck_type amd_mcheck_init(struct cpuinfo_x86 *c, bool_t bsp);
 enum mcheck_type intel_mcheck_init(struct cpuinfo_x86 *c, bool_t bsp);
 
 void intel_mcheck_timer(struct cpuinfo_x86 *c);
diff -r 7abb25095de0 xen/arch/x86/cpu/mcheck/mce_amd.c
--- a/xen/arch/x86/cpu/mcheck/mce_amd.c	Thu Oct 25 13:15:19 2012 +0200
+++ b/xen/arch/x86/cpu/mcheck/mce_amd.c	Thu Oct 25 14:20:49 2012 +0200
@@ -19,6 +19,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -98,3 +99,85 @@ mc_amd_addrcheck(uint64_t status, uint64
     BUG();
     return 0;
 }
+
+static void
+amd_cpu_mcabank_free(unsigned int cpu)
+{
+    struct mca_banks *mb;
+
+    mb = per_cpu(mce_clear_banks, cpu);
+    mcabanks_free(mb);
+}
+
+static int
+amd_cpu_mcabank_alloc(unsigned int cpu)
+{
+    struct mca_banks *mb;
+
+    mb = mcabanks_alloc();
+    if (!mb)
+        return -ENOMEM;
+
+    per_cpu(mce_clear_banks, cpu) = mb;
+    return 0;
+}
+
+static int
+amd_cpu_callback(struct notifier_block *nfb, unsigned long action, void *hcpu)
+{
+    unsigned int cpu = (unsigned long)hcpu;
+    int rc = 0;
+
+    switch (action) {
+    case CPU_UP_PREPARE:
+        rc = amd_cpu_mcabank_alloc(cpu);
+        break;
+    case CPU_DYING:
+        clear_in_cr4(X86_CR4_MCE);
+        break;
+    case CPU_UP_CANCELED:
+    case CPU_DEAD:
+        amd_cpu_mcabank_free(cpu);
+        break;
+    default:
+        break;
+    }
+
+    return !rc ? NOTIFY_DONE : notifier_from_errno(rc);
+}
+
+static struct notifier_block cpu_nfb = {
+    .notifier_call = amd_cpu_callback
+};
+
+enum mcheck_type
+amd_mcheck_init(struct cpuinfo_x86 *ci, bool_t bsp)
+{
+    enum mcheck_type rc = mcheck_none;
+
+    if (bsp) {
+        /* Early MCE initialization for BSP. */
+        if ( amd_cpu_mcabank_alloc(0) )
+            BUG();
+        register_cpu_notifier(&cpu_nfb);
+    }
+
+    switch (ci->x86) {
+    case 6:
+        rc = amd_k7_mcheck_init(ci);
+        break;
+
+    default:
+        /* Assume that machine check support is available.
+         * The minimum provided support is at least the K8. */
+    case 0xf:
+        rc = amd_k8_mcheck_init(ci);
+        break;
+
+    case 0x10 ... 0x17:
+        rc = amd_f10_mcheck_init(ci);
+        break;
+    }
+
+    return rc;
+}
diff -r 7abb25095de0 xen/arch/x86/cpu/mcheck/mce_amd.h
--- a/xen/arch/x86/cpu/mcheck/mce_amd.h	Thu Oct 25 13:15:19 2012 +0200
+++ b/xen/arch/x86/cpu/mcheck/mce_amd.h	Thu Oct 25 14:20:49 2012 +0200
@@ -1,6 +1,10 @@
 #ifndef _MCHECK_AMD_H
 #define _MCHECK_AMD_H
 
+enum mcheck_type amd_k7_mcheck_init(struct cpuinfo_x86 *c);
+enum mcheck_type amd_k8_mcheck_init(struct cpuinfo_x86 *c);
+enum mcheck_type amd_f10_mcheck_init(struct cpuinfo_x86 *c);
+
 int mc_amd_recoverable_scan(uint64_t status);
 int mc_amd_addrcheck(uint64_t status, uint64_t misc, int addrtype);
 

--------------080306090603060904090803
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------080306090603060904090803--


From xen-devel-bounces@lists.xen.org Thu Oct 25 13:55:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 13:55:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRNte-0005DH-Re; Thu, 25 Oct 2012 13:54:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRNtd-0005DA-Kl
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 13:54:53 +0000
Received: from [85.158.138.51:32597] by server-13.bemta-3.messagelabs.com id
	7E/AD-24887-CA449805; Thu, 25 Oct 2012 13:54:52 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1351173291!27411192!1
X-Originating-IP: [213.199.154.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12400 invoked from network); 25 Oct 2012 13:54:52 -0000
Received: from am1ehsobe005.messaging.microsoft.com (HELO
	am1outboundpool.messaging.microsoft.com) (213.199.154.208)
	by server-11.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Oct 2012 13:54:52 -0000
Received: from mail33-am1-R.bigfish.com (10.3.201.251) by
	AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id
	14.1.225.23; Thu, 25 Oct 2012 13:54:48 +0000
Received: from mail33-am1 (localhost [127.0.0.1])	by mail33-am1-R.bigfish.com
	(Postfix) with ESMTP id 0B91134016D	for ;
	Thu, 25 Oct 2012 13:54:48 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzc85fhc85dhzz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh34h1155h)
Received: from mail33-am1 (localhost.localdomain [127.0.0.1]) by mail33-am1
	(MessageSwitch) id 1351173285240284_21893;
	Thu, 25 Oct 2012 13:54:45 +0000 (UTC)
Received: from AM1EHSMHS005.bigfish.com (unknown [10.3.201.241])	by
	mail33-am1.bigfish.com (Postfix) with ESMTP id 2EEE71200F3	for
	; Thu, 25 Oct 2012 13:54:45 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS005.bigfish.com (10.3.207.105) with Microsoft SMTP Server id
	14.1.225.23; Thu, 25 Oct 2012 13:54:42 +0000
X-WSS-ID: 0MCGBZ3-01-CJ6-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1) with ESMTP id 2C9C810280ED	for ;
	Thu, 25 Oct 2012 08:54:38 -0500 (CDT)
Received: from SAUSEXDAG06.amd.com (163.181.55.7) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 25 Oct 2012 08:54:55 -0500
Received: from STOREXDAG04.amd.com (10.1.13.13) by sausexdag06.amd.com
	(163.181.55.7) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Thu, 25 Oct 2012 08:54:38 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag04.amd.com
	(10.1.13.13) with Microsoft SMTP Server id 14.2.318.4; Thu, 25 Oct 2012
	09:54:37 -0400
Message-ID: <5089449C.7020700@amd.com>
Date: Thu, 25 Oct 2012 15:54:36 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" 
Content-Type: multipart/mixed; boundary="------------080306090603060904090803"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] MCE: support cpu notification chain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------080306090603060904090803
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit


Add support for cpu notification chain.
This is useful with nested virtualization when Xen
runs as l1 hypervisor.
This cleans up mce initialization cleanup as a side-effect.

Signed-off-by: Christoph Egger 


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------080306090603060904090803
Content-Type: text/plain; charset="us-ascii"; name="xen_mce_init.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_mce_init.diff"
Content-Description: xen_mce_init.diff

diff -r 7abb25095de0 xen/arch/x86/cpu/mcheck/mce.c
--- a/xen/arch/x86/cpu/mcheck/mce.c	Thu Oct 25 13:15:19 2012 +0200
+++ b/xen/arch/x86/cpu/mcheck/mce.c	Thu Oct 25 14:20:49 2012 +0200
@@ -560,30 +560,6 @@ void mcheck_mca_clearbanks(struct mca_ba
     }
 }
 
-static enum mcheck_type amd_mcheck_init(struct cpuinfo_x86 *ci)
-{
-    enum mcheck_type rc = mcheck_none;
-
-    switch (ci->x86) {
-    case 6:
-        rc = amd_k7_mcheck_init(ci);
-        break;
-
-    default:
-        /* Assume that machine check support is available.
-         * The minimum provided support is at least the K8. */
-    case 0xf:
-        rc = amd_k8_mcheck_init(ci);
-        break;
-
-    case 0x10 ... 0x17:
-        rc = amd_f10_mcheck_init(ci);
-        break;
-    }
-
-    return rc;
-}
-
 /*check the existence of Machine Check*/
 int mce_available(struct cpuinfo_x86 *c)
 {
@@ -774,7 +750,7 @@ void mcheck_init(struct cpuinfo_x86 *c, 
 
     switch (c->x86_vendor) {
     case X86_VENDOR_AMD:
-        inited = amd_mcheck_init(c);
+        inited = amd_mcheck_init(c, bsp);
         break;
 
     case X86_VENDOR_INTEL:
diff -r 7abb25095de0 xen/arch/x86/cpu/mcheck/mce.h
--- a/xen/arch/x86/cpu/mcheck/mce.h	Thu Oct 25 13:15:19 2012 +0200
+++ b/xen/arch/x86/cpu/mcheck/mce.h	Thu Oct 25 14:20:49 2012 +0200
@@ -39,10 +39,7 @@ enum mcheck_type {
 };
 
 /* Init functions */
-enum mcheck_type amd_k7_mcheck_init(struct cpuinfo_x86 *c);
-enum mcheck_type amd_k8_mcheck_init(struct cpuinfo_x86 *c);
-enum mcheck_type amd_f10_mcheck_init(struct cpuinfo_x86 *c);
-
+enum mcheck_type amd_mcheck_init(struct cpuinfo_x86 *c, bool_t bsp);
 enum mcheck_type intel_mcheck_init(struct cpuinfo_x86 *c, bool_t bsp);
 
 void intel_mcheck_timer(struct cpuinfo_x86 *c);
diff -r 7abb25095de0 xen/arch/x86/cpu/mcheck/mce_amd.c
--- a/xen/arch/x86/cpu/mcheck/mce_amd.c	Thu Oct 25 13:15:19 2012 +0200
+++ b/xen/arch/x86/cpu/mcheck/mce_amd.c	Thu Oct 25 14:20:49 2012 +0200
@@ -19,6 +19,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -98,3 +99,85 @@ mc_amd_addrcheck(uint64_t status, uint64
     BUG();
     return 0;
 }
+
+static void
+amd_cpu_mcabank_free(unsigned int cpu)
+{
+    struct mca_banks *mb;
+
+    mb = per_cpu(mce_clear_banks, cpu);
+    mcabanks_free(mb);
+}
+
+static int
+amd_cpu_mcabank_alloc(unsigned int cpu)
+{
+    struct mca_banks *mb;
+
+    mb = mcabanks_alloc();
+    if (!mb)
+        return -ENOMEM;
+
+    per_cpu(mce_clear_banks, cpu) = mb;
+    return 0;
+}
+
+static int
+amd_cpu_callback(struct notifier_block *nfb, unsigned long action, void *hcpu)
+{
+    unsigned int cpu = (unsigned long)hcpu;
+    int rc = 0;
+
+    switch (action) {
+    case CPU_UP_PREPARE:
+        rc = amd_cpu_mcabank_alloc(cpu);
+        break;
+    case CPU_DYING:
+        clear_in_cr4(X86_CR4_MCE);
+        break;
+    case CPU_UP_CANCELED:
+    case CPU_DEAD:
+        amd_cpu_mcabank_free(cpu);
+        break;
+    default:
+        break;
+    }
+
+    return !rc ? NOTIFY_DONE : notifier_from_errno(rc);
+}
+
+static struct notifier_block cpu_nfb = {
+    .notifier_call = amd_cpu_callback
+};
+
+enum mcheck_type
+amd_mcheck_init(struct cpuinfo_x86 *ci, bool_t bsp)
+{
+    enum mcheck_type rc = mcheck_none;
+
+    if (bsp) {
+        /* Early MCE initialization for BSP. */
+        if ( amd_cpu_mcabank_alloc(0) )
+            BUG();
+        register_cpu_notifier(&cpu_nfb);
+    }
+
+    switch (ci->x86) {
+    case 6:
+        rc = amd_k7_mcheck_init(ci);
+        break;
+
+    default:
+        /* Assume that machine check support is available.
+         * The minimum provided support is at least the K8. */
+    case 0xf:
+        rc = amd_k8_mcheck_init(ci);
+        break;
+
+    case 0x10 ... 0x17:
+        rc = amd_f10_mcheck_init(ci);
+        break;
+    }
+
+    return rc;
+}
diff -r 7abb25095de0 xen/arch/x86/cpu/mcheck/mce_amd.h
--- a/xen/arch/x86/cpu/mcheck/mce_amd.h	Thu Oct 25 13:15:19 2012 +0200
+++ b/xen/arch/x86/cpu/mcheck/mce_amd.h	Thu Oct 25 14:20:49 2012 +0200
@@ -1,6 +1,10 @@
 #ifndef _MCHECK_AMD_H
 #define _MCHECK_AMD_H
 
+enum mcheck_type amd_k7_mcheck_init(struct cpuinfo_x86 *c);
+enum mcheck_type amd_k8_mcheck_init(struct cpuinfo_x86 *c);
+enum mcheck_type amd_f10_mcheck_init(struct cpuinfo_x86 *c);
+
 int mc_amd_recoverable_scan(uint64_t status);
 int mc_amd_addrcheck(uint64_t status, uint64_t misc, int addrtype);
 

--------------080306090603060904090803
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------080306090603060904090803--


From xen-devel-bounces@lists.xen.org Thu Oct 25 14:06:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 14:06:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRO4F-0005ah-70; Thu, 25 Oct 2012 14:05:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRO4D-0005ac-IT
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 14:05:49 +0000
Received: from [85.158.143.35:62512] by server-1.bemta-4.messagelabs.com id
	29/2B-19134-C3749805; Thu, 25 Oct 2012 14:05:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1351173945!14459359!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29633 invoked from network); 25 Oct 2012 14:05:46 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-21.messagelabs.com with SMTP;
	25 Oct 2012 14:05:46 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 25 Oct 2012 15:05:44 +0100
Message-Id: <5089635702000078000A48D7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 25 Oct 2012 15:05:43 +0100
From: "Jan Beulich" 
To: "Stefano Stabellini" ,
	"Konrad Rzeszutek Wilk" 
References: <20121024151957.28a1626cd9a59c014e78c401@canb.auug.org.au>
	<50885EA8.3050007@xenotime.net>
	<508906CE02000078000A4553@nat28.tlf.novell.com>
	
	<20121025134628.GE26209@localhost.localdomain>
In-Reply-To: <20121025134628.GE26209@localhost.localdomain>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Stephen Rothwell ,
	Jeremy Fitzhardinge ,
	"gregkh@linuxfoundation.org" ,
	"linux-kernel@vger.kernel.org" ,
	"virtualization@lists.linux-foundation.org"
	,
	Randy Dunlap ,
	"linux-next@vger.kernel.org" ,
	xen-devel 
Subject: Re: [Xen-devel] linux-next: Tree for Oct 24 (xen)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 25.10.12 at 15:46, Konrad Rzeszutek Wilk  wrote:
> On Thu, Oct 25, 2012 at 11:48:30AM +0100, Stefano Stabellini wrote:
>> On Thu, 25 Oct 2012, Jan Beulich wrote:
>> > >>> On 24.10.12 at 23:33, Randy Dunlap  wrote:
>> > > On 10/23/2012 09:19 PM, Stephen Rothwell wrote:
>> > > 
>> > >> Hi all,
>> > >> 
>> > >> Changes since 201201023:
>> > >> 
>> > > 
>> > > on x86_64:
>> > > 
>> > > drivers/built-in.o: In function `dbgp_reset_prep':
>> > > (.text+0xb96b5): undefined reference to `xen_dbgp_reset_prep'
>> > > drivers/built-in.o: In function `dbgp_external_startup':
>> > > (.text+0xb9d95): undefined reference to `xen_dbgp_external_startup'
>> > > 
>> > > 
>> > > Full randconfig file is attached.
>> > 
>> > So this is because with !USB_SUPPORT but EARLY_PRINTK_DBGP
>> > dbgp_reset_prep() and dbgp_external_startup() get pointlessly
>> > defined and exported. This got broken by the merge
>> > recommendation for the ARM side changes (originally compilation
>> > of drivers/xen/dbgp.c depended on just CONFIG_XEN_DOM0).
>> > 
>> > >From my pov, fixing the USB side would be the clean solution (i.e.
>> > putting those function definitions inside a CONFIG_USB_SUPPORT
>> > conditional).
>> >
>> > The alternative of a smaller change would be to extend the
>> > conditional around the respective xen_dbgp_...() declarations
>> > in include/linux/usb/ehci_def.h to become
>> > 
>> > #if defined(CONFIG_XEN_DOM0) && defined(CONFIG_USB_SUPPORT)
>> > 
>> > Please advise towards your preference.
>> 
>> I think that your first suggestion is the right one.
> 
> Can you guys spin up a patch pls and make sure it does not break
> compilation. Thx.

I'd really like to hear Greg's opinion on which route to take before
pointlessly trying the other one.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 14:06:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 14:06:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRO4F-0005ah-70; Thu, 25 Oct 2012 14:05:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRO4D-0005ac-IT
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 14:05:49 +0000
Received: from [85.158.143.35:62512] by server-1.bemta-4.messagelabs.com id
	29/2B-19134-C3749805; Thu, 25 Oct 2012 14:05:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1351173945!14459359!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29633 invoked from network); 25 Oct 2012 14:05:46 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-21.messagelabs.com with SMTP;
	25 Oct 2012 14:05:46 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 25 Oct 2012 15:05:44 +0100
Message-Id: <5089635702000078000A48D7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 25 Oct 2012 15:05:43 +0100
From: "Jan Beulich" 
To: "Stefano Stabellini" ,
	"Konrad Rzeszutek Wilk" 
References: <20121024151957.28a1626cd9a59c014e78c401@canb.auug.org.au>
	<50885EA8.3050007@xenotime.net>
	<508906CE02000078000A4553@nat28.tlf.novell.com>
	
	<20121025134628.GE26209@localhost.localdomain>
In-Reply-To: <20121025134628.GE26209@localhost.localdomain>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Stephen Rothwell ,
	Jeremy Fitzhardinge ,
	"gregkh@linuxfoundation.org" ,
	"linux-kernel@vger.kernel.org" ,
	"virtualization@lists.linux-foundation.org"
	,
	Randy Dunlap ,
	"linux-next@vger.kernel.org" ,
	xen-devel 
Subject: Re: [Xen-devel] linux-next: Tree for Oct 24 (xen)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 25.10.12 at 15:46, Konrad Rzeszutek Wilk  wrote:
> On Thu, Oct 25, 2012 at 11:48:30AM +0100, Stefano Stabellini wrote:
>> On Thu, 25 Oct 2012, Jan Beulich wrote:
>> > >>> On 24.10.12 at 23:33, Randy Dunlap  wrote:
>> > > On 10/23/2012 09:19 PM, Stephen Rothwell wrote:
>> > > 
>> > >> Hi all,
>> > >> 
>> > >> Changes since 201201023:
>> > >> 
>> > > 
>> > > on x86_64:
>> > > 
>> > > drivers/built-in.o: In function `dbgp_reset_prep':
>> > > (.text+0xb96b5): undefined reference to `xen_dbgp_reset_prep'
>> > > drivers/built-in.o: In function `dbgp_external_startup':
>> > > (.text+0xb9d95): undefined reference to `xen_dbgp_external_startup'
>> > > 
>> > > 
>> > > Full randconfig file is attached.
>> > 
>> > So this is because with !USB_SUPPORT but EARLY_PRINTK_DBGP
>> > dbgp_reset_prep() and dbgp_external_startup() get pointlessly
>> > defined and exported. This got broken by the merge
>> > recommendation for the ARM side changes (originally compilation
>> > of drivers/xen/dbgp.c depended on just CONFIG_XEN_DOM0).
>> > 
>> > >From my pov, fixing the USB side would be the clean solution (i.e.
>> > putting those function definitions inside a CONFIG_USB_SUPPORT
>> > conditional).
>> >
>> > The alternative of a smaller change would be to extend the
>> > conditional around the respective xen_dbgp_...() declarations
>> > in include/linux/usb/ehci_def.h to become
>> > 
>> > #if defined(CONFIG_XEN_DOM0) && defined(CONFIG_USB_SUPPORT)
>> > 
>> > Please advise towards your preference.
>> 
>> I think that your first suggestion is the right one.
> 
> Can you guys spin up a patch pls and make sure it does not break
> compilation. Thx.

I'd really like to hear Greg's opinion on which route to take before
pointlessly trying the other one.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 14:10:35 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 14:10:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRO8a-0005iM-S9; Thu, 25 Oct 2012 14:10:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRO8Z-0005iG-OU
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 14:10:19 +0000
Received: from [85.158.143.35:33375] by server-1.bemta-4.messagelabs.com id
	09/B2-19134-B4849805; Thu, 25 Oct 2012 14:10:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1351174210!4679287!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25493 invoked from network); 25 Oct 2012 14:10:11 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-21.messagelabs.com with SMTP;
	25 Oct 2012 14:10:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 25 Oct 2012 15:10:10 +0100
Message-Id: <5089646102000078000A48DA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 25 Oct 2012 15:10:09 +0100
From: "Jan Beulich" 
To: "Christoph Egger" 
References: <5089449C.7020700@amd.com>
In-Reply-To: <5089449C.7020700@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] MCE: support cpu notification chain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 25.10.12 at 15:54, Christoph Egger  wrote:
> Add support for cpu notification chain.
> This is useful with nested virtualization when Xen
> runs as l1 hypervisor.
> This cleans up mce initialization cleanup as a side-effect.

Did you notice the fix I had done to your earlier patch before
committing c/s 26106:1883c1d29de9? With the change here,
mce_clear_banks will get allocated twice (once in generic code
and once in AMD specific code), leaking one instance.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 14:10:35 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 14:10:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRO8a-0005iM-S9; Thu, 25 Oct 2012 14:10:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRO8Z-0005iG-OU
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 14:10:19 +0000
Received: from [85.158.143.35:33375] by server-1.bemta-4.messagelabs.com id
	09/B2-19134-B4849805; Thu, 25 Oct 2012 14:10:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1351174210!4679287!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25493 invoked from network); 25 Oct 2012 14:10:11 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-21.messagelabs.com with SMTP;
	25 Oct 2012 14:10:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 25 Oct 2012 15:10:10 +0100
Message-Id: <5089646102000078000A48DA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 25 Oct 2012 15:10:09 +0100
From: "Jan Beulich" 
To: "Christoph Egger" 
References: <5089449C.7020700@amd.com>
In-Reply-To: <5089449C.7020700@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] MCE: support cpu notification chain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 25.10.12 at 15:54, Christoph Egger  wrote:
> Add support for cpu notification chain.
> This is useful with nested virtualization when Xen
> runs as l1 hypervisor.
> This cleans up mce initialization cleanup as a side-effect.

Did you notice the fix I had done to your earlier patch before
committing c/s 26106:1883c1d29de9? With the change here,
mce_clear_banks will get allocated twice (once in generic code
and once in AMD specific code), leaking one instance.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 14:13:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 14:13:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TROAw-0005pV-DD; Thu, 25 Oct 2012 14:12:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TROAu-0005pP-Oq
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 14:12:44 +0000
Received: from [85.158.137.99:25347] by server-13.bemta-3.messagelabs.com id
	FF/DE-24887-7D849805; Thu, 25 Oct 2012 14:12:39 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1351174348!20653164!1
X-Originating-IP: [216.32.181.183]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26921 invoked from network); 25 Oct 2012 14:12:38 -0000
Received: from ch1ehsobe003.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.183)
	by server-15.tower-217.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Oct 2012 14:12:38 -0000
Received: from mail192-ch1-R.bigfish.com (10.43.68.234) by
	CH1EHSOBE016.bigfish.com (10.43.70.66) with Microsoft SMTP Server id
	14.1.225.23; Thu, 25 Oct 2012 14:12:27 +0000
Received: from mail192-ch1 (localhost [127.0.0.1])	by
	mail192-ch1-R.bigfish.com (Postfix) with ESMTP id 8AFD22601F2	for
	; Thu, 25 Oct 2012 14:12:27 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzc85fhc85dhzz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh34h1155h)
Received: from mail192-ch1 (localhost.localdomain [127.0.0.1]) by mail192-ch1
	(MessageSwitch) id 1351174345671974_12885;
	Thu, 25 Oct 2012 14:12:25 +0000 (UTC)
Received: from CH1EHSMHS018.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.247])	by mail192-ch1.bigfish.com (Postfix) with ESMTP id
	98B01E0059
	for ; Thu, 25 Oct 2012 14:12:25 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS018.bigfish.com (10.43.70.18) with Microsoft SMTP Server id
	14.1.225.23; Thu, 25 Oct 2012 14:12:24 +0000
X-WSS-ID: 0MCGCSL-01-E6Q-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1) with ESMTP id 25BCA10280FD	for ;
	Thu, 25 Oct 2012 09:12:21 -0500 (CDT)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 25 Oct 2012 09:12:38 -0500
Received: from STOREXDAG02.amd.com (10.1.13.11) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Thu, 25 Oct 2012 09:12:22 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag02.amd.com
	(10.1.13.11) with Microsoft SMTP Server id 14.2.318.4; Thu, 25 Oct 2012
	10:12:20 -0400
Message-ID: <508948C3.5020106@amd.com>
Date: Thu, 25 Oct 2012 16:12:19 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" 
Content-Type: multipart/mixed; boundary="------------000302030609060900070201"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] libxl: NetBSD PCI passthrough support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------000302030609060900070201
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit


Add PCI passthrough support for HVM guests.

Signed-off-by: Christoph Egger 

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------000302030609060900070201
Content-Type: text/plain; charset="us-ascii"; name="libxl_pci_netbsd.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="libxl_pci_netbsd.diff"
Content-Description: libxl_pci_netbsd.diff

NetBSD PCI passthrough support

diff -r 0149ba2b0ce8 -r a4baabcd7d56 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -373,8 +373,6 @@ typedef struct {
 #define PCI_SLOT(devfn)         (((devfn) >> 3) & 0x1f)
 #define PCI_FUNC(devfn)         ((devfn) & 0x07)
 #define AUTO_PHP_SLOT          0x100
-#define SYSFS_PCI_DEV          "/sys/bus/pci/devices"
-#define SYSFS_PCIBACK_DRIVER   "/sys/bus/pci/drivers/pciback"
 #define XENSTORE_PID_FILE      "/var/run/xenstored.pid"
 
 #define PROC_PCI_NUM_RESOURCES 7
diff -r 0149ba2b0ce8 -r a4baabcd7d56 tools/libxl/libxl_osdeps.h
--- a/tools/libxl/libxl_osdeps.h
+++ b/tools/libxl/libxl_osdeps.h
@@ -23,14 +23,27 @@
 
 #define _GNU_SOURCE
 
-#if defined(__NetBSD__) || defined(__OpenBSD__)
+#if defined(__NetBSD__)
+#define SYSFS_PCI_DEV          "/sys/bus/pci/devices"
+#define SYSFS_PCIBACK_DRIVER   "/kern/xen/pci"
+#include 
+#elif defined(__OpenBSD__)
 #include 
 #elif defined(__linux__)
+#define SYSFS_PCI_DEV          "/sys/bus/pci/devices"
+#define SYSFS_PCIBACK_DRIVER   "/sys/bus/pci/drivers/pciback"
 #include 
 #elif defined(__sun__)
 #include 
 #endif
 
+#ifndef SYSFS_PCIBACK_DRIVER
+#error define SYSFS_PCIBACK_DRIVER for your platform
+#endif
+#ifndef SYSFS_PCI_DEV
+#error define SYSFS_PCI_DEV for your platform
+#endif
+
 #ifdef NEED_OWN_ASPRINTF
 #include 
 

--------------000302030609060900070201
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------000302030609060900070201--


From xen-devel-bounces@lists.xen.org Thu Oct 25 14:13:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 14:13:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TROAw-0005pV-DD; Thu, 25 Oct 2012 14:12:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TROAu-0005pP-Oq
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 14:12:44 +0000
Received: from [85.158.137.99:25347] by server-13.bemta-3.messagelabs.com id
	FF/DE-24887-7D849805; Thu, 25 Oct 2012 14:12:39 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1351174348!20653164!1
X-Originating-IP: [216.32.181.183]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26921 invoked from network); 25 Oct 2012 14:12:38 -0000
Received: from ch1ehsobe003.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.183)
	by server-15.tower-217.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Oct 2012 14:12:38 -0000
Received: from mail192-ch1-R.bigfish.com (10.43.68.234) by
	CH1EHSOBE016.bigfish.com (10.43.70.66) with Microsoft SMTP Server id
	14.1.225.23; Thu, 25 Oct 2012 14:12:27 +0000
Received: from mail192-ch1 (localhost [127.0.0.1])	by
	mail192-ch1-R.bigfish.com (Postfix) with ESMTP id 8AFD22601F2	for
	; Thu, 25 Oct 2012 14:12:27 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzc85fhc85dhzz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh34h1155h)
Received: from mail192-ch1 (localhost.localdomain [127.0.0.1]) by mail192-ch1
	(MessageSwitch) id 1351174345671974_12885;
	Thu, 25 Oct 2012 14:12:25 +0000 (UTC)
Received: from CH1EHSMHS018.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.247])	by mail192-ch1.bigfish.com (Postfix) with ESMTP id
	98B01E0059
	for ; Thu, 25 Oct 2012 14:12:25 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS018.bigfish.com (10.43.70.18) with Microsoft SMTP Server id
	14.1.225.23; Thu, 25 Oct 2012 14:12:24 +0000
X-WSS-ID: 0MCGCSL-01-E6Q-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1) with ESMTP id 25BCA10280FD	for ;
	Thu, 25 Oct 2012 09:12:21 -0500 (CDT)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 25 Oct 2012 09:12:38 -0500
Received: from STOREXDAG02.amd.com (10.1.13.11) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Thu, 25 Oct 2012 09:12:22 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag02.amd.com
	(10.1.13.11) with Microsoft SMTP Server id 14.2.318.4; Thu, 25 Oct 2012
	10:12:20 -0400
Message-ID: <508948C3.5020106@amd.com>
Date: Thu, 25 Oct 2012 16:12:19 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" 
Content-Type: multipart/mixed; boundary="------------000302030609060900070201"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] libxl: NetBSD PCI passthrough support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------000302030609060900070201
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit


Add PCI passthrough support for HVM guests.

Signed-off-by: Christoph Egger 

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------000302030609060900070201
Content-Type: text/plain; charset="us-ascii"; name="libxl_pci_netbsd.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="libxl_pci_netbsd.diff"
Content-Description: libxl_pci_netbsd.diff

NetBSD PCI passthrough support

diff -r 0149ba2b0ce8 -r a4baabcd7d56 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -373,8 +373,6 @@ typedef struct {
 #define PCI_SLOT(devfn)         (((devfn) >> 3) & 0x1f)
 #define PCI_FUNC(devfn)         ((devfn) & 0x07)
 #define AUTO_PHP_SLOT          0x100
-#define SYSFS_PCI_DEV          "/sys/bus/pci/devices"
-#define SYSFS_PCIBACK_DRIVER   "/sys/bus/pci/drivers/pciback"
 #define XENSTORE_PID_FILE      "/var/run/xenstored.pid"
 
 #define PROC_PCI_NUM_RESOURCES 7
diff -r 0149ba2b0ce8 -r a4baabcd7d56 tools/libxl/libxl_osdeps.h
--- a/tools/libxl/libxl_osdeps.h
+++ b/tools/libxl/libxl_osdeps.h
@@ -23,14 +23,27 @@
 
 #define _GNU_SOURCE
 
-#if defined(__NetBSD__) || defined(__OpenBSD__)
+#if defined(__NetBSD__)
+#define SYSFS_PCI_DEV          "/sys/bus/pci/devices"
+#define SYSFS_PCIBACK_DRIVER   "/kern/xen/pci"
+#include 
+#elif defined(__OpenBSD__)
 #include 
 #elif defined(__linux__)
+#define SYSFS_PCI_DEV          "/sys/bus/pci/devices"
+#define SYSFS_PCIBACK_DRIVER   "/sys/bus/pci/drivers/pciback"
 #include 
 #elif defined(__sun__)
 #include 
 #endif
 
+#ifndef SYSFS_PCIBACK_DRIVER
+#error define SYSFS_PCIBACK_DRIVER for your platform
+#endif
+#ifndef SYSFS_PCI_DEV
+#error define SYSFS_PCI_DEV for your platform
+#endif
+
 #ifdef NEED_OWN_ASPRINTF
 #include 
 

--------------000302030609060900070201
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------000302030609060900070201--


From xen-devel-bounces@lists.xen.org Thu Oct 25 14:14:49 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 14:14:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TROCf-0005wB-Tj; Thu, 25 Oct 2012 14:14:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TROCe-0005w1-HG
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 14:14:32 +0000
Received: from [193.109.254.147:61148] by server-3.bemta-14.messagelabs.com id
	48/44-04486-74949805; Thu, 25 Oct 2012 14:14:31 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1351174469!4871481!1
X-Originating-IP: [65.55.88.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29422 invoked from network); 25 Oct 2012 14:14:30 -0000
Received: from tx2ehsobe005.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.15)
	by server-6.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Oct 2012 14:14:30 -0000
Received: from mail55-tx2-R.bigfish.com (10.9.14.240) by
	TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id
	14.1.225.23; Thu, 25 Oct 2012 14:14:29 +0000
Received: from mail55-tx2 (localhost [127.0.0.1])	by mail55-tx2-R.bigfish.com
	(Postfix) with ESMTP id 1354842005A	for ;
	Thu, 25 Oct 2012 14:14:29 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzc85fhc85dhzz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh34h1155h)
Received: from mail55-tx2 (localhost.localdomain [127.0.0.1]) by mail55-tx2
	(MessageSwitch) id 1351174467726010_26120;
	Thu, 25 Oct 2012 14:14:27 +0000 (UTC)
Received: from TX2EHSMHS029.bigfish.com (unknown [10.9.14.238])	by
	mail55-tx2.bigfish.com (Postfix) with ESMTP id ADC582C0114	for
	; Thu, 25 Oct 2012 14:14:27 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS029.bigfish.com (10.9.99.129) with Microsoft SMTP Server id
	14.1.225.23; Thu, 25 Oct 2012 14:14:26 +0000
X-WSS-ID: 0MCGCVZ-01-EDR-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1) with ESMTP id 2B89610280ED	for ;
	Thu, 25 Oct 2012 09:14:22 -0500 (CDT)
Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 25 Oct 2012 09:14:39 -0500
Received: from STOREXDAG02.amd.com (10.1.13.11) by sausexdag03.amd.com
	(163.181.55.3) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Thu, 25 Oct 2012 09:14:22 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag02.amd.com
	(10.1.13.11) with Microsoft SMTP Server id 14.2.318.4; Thu, 25 Oct 2012
	10:14:21 -0400
Message-ID: <5089493C.9020908@amd.com>
Date: Thu, 25 Oct 2012 16:14:20 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" 
Content-Type: multipart/mixed; boundary="------------080904050601020106030805"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] ioemu: add pci passthrough support to NetBSD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------080904050601020106030805
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit


Support PCI passthrough for NetBSD.

Signed-off-by: Christoph Egger 

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------080904050601020106030805
Content-Type: text/plain; charset="us-ascii";
	name="qemu_xen_traditional_pci_netbsd.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="qemu_xen_traditional_pci_netbsd.diff"
Content-Description: qemu_xen_traditional_pci_netbsd.diff

diff --git a/hw/pass-through.c b/hw/pass-through.c
index 8581253..ca2f75a 100644
--- a/hw/pass-through.c
+++ b/hw/pass-through.c
@@ -84,8 +84,6 @@
  */
 
 #include "pass-through.h"
-#include "pci/header.h"
-#include "pci/pci.h"
 #include "pt-msi.h"
 #include "qemu-xen.h"
 #include "iomulti.h"
diff --git a/hw/pass-through.h b/hw/pass-through.h
index d7d837c..98b6f5e 100644
--- a/hw/pass-through.h
+++ b/hw/pass-through.h
@@ -20,8 +20,13 @@
 
 #include "hw.h"
 #include "pci.h"
+#ifdef __NetBSD__
+#include "pciutils/header.h"
+#include "pciutils/pci.h"
+#else
 #include "pci/header.h"
 #include "pci/pci.h"
+#endif
 #include "exec-all.h"
 #include "sys-queue.h"
 #include "qemu-timer.h"
diff --git a/hw/piix4acpi.c b/hw/piix4acpi.c
index fb1e5c3..d8ca298 100644
--- a/hw/piix4acpi.c
+++ b/hw/piix4acpi.c
@@ -41,7 +41,7 @@
 #define PIIX4ACPI_LOG(level, fmt, ...) do { if (level <= PIIX4ACPI_LOGLEVEL) qemu_log(fmt, ## __VA_ARGS__); } while (0)
 
 #ifdef CONFIG_PASSTHROUGH
-#include 
+#include "pass-through.h"
 #endif
 
 /* PM1a_CNT bits, as defined in the ACPI specification. */
diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
index c6f8869..3bbd856 100644
--- a/hw/pt-graphics.c
+++ b/hw/pt-graphics.c
@@ -3,8 +3,6 @@
  */
 
 #include "pass-through.h"
-#include "pci/header.h"
-#include "pci/pci.h"
 
 #include 
 #include 
diff --git a/hw/pt-msi.c b/hw/pt-msi.c
index 70c4023..0bd9446 100644
--- a/hw/pt-msi.c
+++ b/hw/pt-msi.c
@@ -22,6 +22,11 @@
 #include "pt-msi.h"
 #include 
 
+#ifdef __NetBSD__
+/* MAP_LOCKED is Linux specific. MAP_WIRED is NetBSD's equivalent. */
+#define MAP_LOCKED MAP_WIRED
+#endif
+
 void msi_set_enable(struct pt_dev *dev, int en)
 {
     uint16_t val = 0;
diff --git a/hw/pt-msi.h b/hw/pt-msi.h
index 94e0d35..4b552dc 100644
--- a/hw/pt-msi.h
+++ b/hw/pt-msi.h
@@ -1,7 +1,6 @@
 #ifndef _PT_MSI_H
 #define _PT_MSI_H
 
-#include "pci/pci.h"
 #include "pass-through.h"
 
 #define  PCI_CAP_ID_MSI     0x05    /* Message Signalled Interrupts */
diff --git a/xen-hooks.mak b/xen-hooks.mak
index b55f45b..430c40d 100644
--- a/xen-hooks.mak
+++ b/xen-hooks.mak
@@ -57,8 +57,16 @@ endif
 ifdef CONFIG_STUBDOM
 CONFIG_PASSTHROUGH=1
 else
-  ifeq (,$(wildcard /usr/include/pci))
-$(warning === pciutils-dev package not found - missing /usr/include/pci)
+  PCIUTILS_NetBSD=/usr/pkg/include/pciutils
+  PCIUTILS_Linux=/usr/include/pci
+  ifeq ($(CONFIG_NetBSD), y)
+PCIUTILS_HEADER=$(PCIUTILS_NetBSD)
+  endif
+  ifeq ($(CONFIG_Linux), y)
+PCIUTILS_HEADER=$(PCITUILS_Linux)
+  endif
+  ifeq (,$(wildcard $(PCIUTILS_HEADER)))
+$(warning === pciutils-dev package not found - missing $(PCIUTILS_HEADER))
 $(warning === PCI passthrough capability has been disabled)
   else
 CONFIG_PASSTHROUGH=1
@@ -67,7 +75,11 @@ endif
 
 ifdef CONFIG_PASSTHROUGH
 OBJS+= pass-through.o pt-msi.o pt-graphics.o
+ifeq ($(CONFIG_NetBSD), y)
+LIBS += -lpciutils -lpci
+else
 LIBS += -lpci
+endif
 CFLAGS += -DCONFIG_PASSTHROUGH 
 $(info === PCI passthrough capability has been enabled ===)
 endif

--------------080904050601020106030805
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------080904050601020106030805--


From xen-devel-bounces@lists.xen.org Thu Oct 25 14:14:49 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 14:14:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TROCf-0005wB-Tj; Thu, 25 Oct 2012 14:14:33 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TROCe-0005w1-HG
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 14:14:32 +0000
Received: from [193.109.254.147:61148] by server-3.bemta-14.messagelabs.com id
	48/44-04486-74949805; Thu, 25 Oct 2012 14:14:31 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1351174469!4871481!1
X-Originating-IP: [65.55.88.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29422 invoked from network); 25 Oct 2012 14:14:30 -0000
Received: from tx2ehsobe005.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.15)
	by server-6.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Oct 2012 14:14:30 -0000
Received: from mail55-tx2-R.bigfish.com (10.9.14.240) by
	TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id
	14.1.225.23; Thu, 25 Oct 2012 14:14:29 +0000
Received: from mail55-tx2 (localhost [127.0.0.1])	by mail55-tx2-R.bigfish.com
	(Postfix) with ESMTP id 1354842005A	for ;
	Thu, 25 Oct 2012 14:14:29 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzc85fhc85dhzz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh34h1155h)
Received: from mail55-tx2 (localhost.localdomain [127.0.0.1]) by mail55-tx2
	(MessageSwitch) id 1351174467726010_26120;
	Thu, 25 Oct 2012 14:14:27 +0000 (UTC)
Received: from TX2EHSMHS029.bigfish.com (unknown [10.9.14.238])	by
	mail55-tx2.bigfish.com (Postfix) with ESMTP id ADC582C0114	for
	; Thu, 25 Oct 2012 14:14:27 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS029.bigfish.com (10.9.99.129) with Microsoft SMTP Server id
	14.1.225.23; Thu, 25 Oct 2012 14:14:26 +0000
X-WSS-ID: 0MCGCVZ-01-EDR-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1) with ESMTP id 2B89610280ED	for ;
	Thu, 25 Oct 2012 09:14:22 -0500 (CDT)
Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 25 Oct 2012 09:14:39 -0500
Received: from STOREXDAG02.amd.com (10.1.13.11) by sausexdag03.amd.com
	(163.181.55.3) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Thu, 25 Oct 2012 09:14:22 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag02.amd.com
	(10.1.13.11) with Microsoft SMTP Server id 14.2.318.4; Thu, 25 Oct 2012
	10:14:21 -0400
Message-ID: <5089493C.9020908@amd.com>
Date: Thu, 25 Oct 2012 16:14:20 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" 
Content-Type: multipart/mixed; boundary="------------080904050601020106030805"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] ioemu: add pci passthrough support to NetBSD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------080904050601020106030805
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit


Support PCI passthrough for NetBSD.

Signed-off-by: Christoph Egger 

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------080904050601020106030805
Content-Type: text/plain; charset="us-ascii";
	name="qemu_xen_traditional_pci_netbsd.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="qemu_xen_traditional_pci_netbsd.diff"
Content-Description: qemu_xen_traditional_pci_netbsd.diff

diff --git a/hw/pass-through.c b/hw/pass-through.c
index 8581253..ca2f75a 100644
--- a/hw/pass-through.c
+++ b/hw/pass-through.c
@@ -84,8 +84,6 @@
  */
 
 #include "pass-through.h"
-#include "pci/header.h"
-#include "pci/pci.h"
 #include "pt-msi.h"
 #include "qemu-xen.h"
 #include "iomulti.h"
diff --git a/hw/pass-through.h b/hw/pass-through.h
index d7d837c..98b6f5e 100644
--- a/hw/pass-through.h
+++ b/hw/pass-through.h
@@ -20,8 +20,13 @@
 
 #include "hw.h"
 #include "pci.h"
+#ifdef __NetBSD__
+#include "pciutils/header.h"
+#include "pciutils/pci.h"
+#else
 #include "pci/header.h"
 #include "pci/pci.h"
+#endif
 #include "exec-all.h"
 #include "sys-queue.h"
 #include "qemu-timer.h"
diff --git a/hw/piix4acpi.c b/hw/piix4acpi.c
index fb1e5c3..d8ca298 100644
--- a/hw/piix4acpi.c
+++ b/hw/piix4acpi.c
@@ -41,7 +41,7 @@
 #define PIIX4ACPI_LOG(level, fmt, ...) do { if (level <= PIIX4ACPI_LOGLEVEL) qemu_log(fmt, ## __VA_ARGS__); } while (0)
 
 #ifdef CONFIG_PASSTHROUGH
-#include 
+#include "pass-through.h"
 #endif
 
 /* PM1a_CNT bits, as defined in the ACPI specification. */
diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
index c6f8869..3bbd856 100644
--- a/hw/pt-graphics.c
+++ b/hw/pt-graphics.c
@@ -3,8 +3,6 @@
  */
 
 #include "pass-through.h"
-#include "pci/header.h"
-#include "pci/pci.h"
 
 #include 
 #include 
diff --git a/hw/pt-msi.c b/hw/pt-msi.c
index 70c4023..0bd9446 100644
--- a/hw/pt-msi.c
+++ b/hw/pt-msi.c
@@ -22,6 +22,11 @@
 #include "pt-msi.h"
 #include 
 
+#ifdef __NetBSD__
+/* MAP_LOCKED is Linux specific. MAP_WIRED is NetBSD's equivalent. */
+#define MAP_LOCKED MAP_WIRED
+#endif
+
 void msi_set_enable(struct pt_dev *dev, int en)
 {
     uint16_t val = 0;
diff --git a/hw/pt-msi.h b/hw/pt-msi.h
index 94e0d35..4b552dc 100644
--- a/hw/pt-msi.h
+++ b/hw/pt-msi.h
@@ -1,7 +1,6 @@
 #ifndef _PT_MSI_H
 #define _PT_MSI_H
 
-#include "pci/pci.h"
 #include "pass-through.h"
 
 #define  PCI_CAP_ID_MSI     0x05    /* Message Signalled Interrupts */
diff --git a/xen-hooks.mak b/xen-hooks.mak
index b55f45b..430c40d 100644
--- a/xen-hooks.mak
+++ b/xen-hooks.mak
@@ -57,8 +57,16 @@ endif
 ifdef CONFIG_STUBDOM
 CONFIG_PASSTHROUGH=1
 else
-  ifeq (,$(wildcard /usr/include/pci))
-$(warning === pciutils-dev package not found - missing /usr/include/pci)
+  PCIUTILS_NetBSD=/usr/pkg/include/pciutils
+  PCIUTILS_Linux=/usr/include/pci
+  ifeq ($(CONFIG_NetBSD), y)
+PCIUTILS_HEADER=$(PCIUTILS_NetBSD)
+  endif
+  ifeq ($(CONFIG_Linux), y)
+PCIUTILS_HEADER=$(PCITUILS_Linux)
+  endif
+  ifeq (,$(wildcard $(PCIUTILS_HEADER)))
+$(warning === pciutils-dev package not found - missing $(PCIUTILS_HEADER))
 $(warning === PCI passthrough capability has been disabled)
   else
 CONFIG_PASSTHROUGH=1
@@ -67,7 +75,11 @@ endif
 
 ifdef CONFIG_PASSTHROUGH
 OBJS+= pass-through.o pt-msi.o pt-graphics.o
+ifeq ($(CONFIG_NetBSD), y)
+LIBS += -lpciutils -lpci
+else
 LIBS += -lpci
+endif
 CFLAGS += -DCONFIG_PASSTHROUGH 
 $(info === PCI passthrough capability has been enabled ===)
 endif

--------------080904050601020106030805
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------080904050601020106030805--


From xen-devel-bounces@lists.xen.org Thu Oct 25 14:15:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 14:15:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TROD8-0005zH-BF; Thu, 25 Oct 2012 14:15:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TROD6-0005z1-UF
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 14:15:01 +0000
Received: from [85.158.143.99:54533] by server-2.bemta-4.messagelabs.com id
	F1/50-22268-46949805; Thu, 25 Oct 2012 14:15:00 +0000
X-Env-Sender: gregkh@linuxfoundation.org
X-Msg-Ref: server-6.tower-216.messagelabs.com!1351174497!20327834!1
X-Originating-IP: [209.85.210.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13704 invoked from network); 25 Oct 2012 14:14:59 -0000
Received: from mail-da0-f45.google.com (HELO mail-da0-f45.google.com)
	(209.85.210.45)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 14:14:59 -0000
Received: by mail-da0-f45.google.com with SMTP id n15so839870dad.32
	for ; Thu, 25 Oct 2012 07:14:57 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent
	:x-gm-message-state;
	bh=psz2aKTq3xDN6SbnOigt29WxqTLXIAoQ3gJIrjPmmZU=;
	b=UzLRIe0FZYuncVDVDLpNpIoQuszDznhqNvN1ux5STdd1a8/ZgtGfe6ADqOvE5Bg/jm
	KBWUV3MoSnxhBGD/xeAY33S82q1tjOsth4qBqYiSPZe78RUfRlnsKybaBcxAtZ9a9y91
	kEbxbsQFbEl2HZDQFeAyMh8E9UWeiS0YhOl4ndt5lgjLSWF4lVUoVcB0djKFvpZFsm3N
	LBx59z+XPdX3Lc4Hz5OcOVZAJQljRXkfcj9xJu9zpe2b0J6qamu9Ex+UpAcyJ9u2F3Lr
	FiK5s9f5NsOFzVt5WN9Y8FFaBog1KwcqEDJWu7Qz/+wwUwP5c7lTnK/Eu2loEDu44Q7G
	UIEA==
Received: by 10.66.85.8 with SMTP id d8mr53719359paz.30.1351174497460;
	Thu, 25 Oct 2012 07:14:57 -0700 (PDT)
Received: from localhost (c-67-168-183-230.hsd1.wa.comcast.net.
	[67.168.183.230])
	by mx.google.com with ESMTPS id o1sm11349076paz.34.2012.10.25.07.14.55
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 25 Oct 2012 07:14:56 -0700 (PDT)
Date: Thu, 25 Oct 2012 07:15:35 -0700
From: "gregkh@linuxfoundation.org" 
To: Jan Beulich 
Message-ID: <20121025141535.GA29620@kroah.com>
References: <20121024151957.28a1626cd9a59c014e78c401@canb.auug.org.au>
	<50885EA8.3050007@xenotime.net>
	<508906CE02000078000A4553@nat28.tlf.novell.com>
	
	<20121025134628.GE26209@localhost.localdomain>
	<5089635702000078000A48D7@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5089635702000078000A48D7@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Gm-Message-State: ALoCoQlsVqyD5ukWgSQSlkkIphY0+Dv+ZTuVzv6QmeUciuvKmSxr5n0rQtktNiVDNF3Z/c7Y9hMT
Cc: Stephen Rothwell ,
	Jeremy Fitzhardinge ,
	Konrad Rzeszutek Wilk ,
	Stefano Stabellini ,
	"linux-kernel@vger.kernel.org" ,
	"virtualization@lists.linux-foundation.org"
	,
	Randy Dunlap ,
	"linux-next@vger.kernel.org" ,
	xen-devel 
Subject: Re: [Xen-devel] linux-next: Tree for Oct 24 (xen)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Oct 25, 2012 at 03:05:43PM +0100, Jan Beulich wrote:
> >>> On 25.10.12 at 15:46, Konrad Rzeszutek Wilk  wrote:
> > On Thu, Oct 25, 2012 at 11:48:30AM +0100, Stefano Stabellini wrote:
> >> On Thu, 25 Oct 2012, Jan Beulich wrote:
> >> > >>> On 24.10.12 at 23:33, Randy Dunlap  wrote:
> >> > > On 10/23/2012 09:19 PM, Stephen Rothwell wrote:
> >> > > 
> >> > >> Hi all,
> >> > >> 
> >> > >> Changes since 201201023:
> >> > >> 
> >> > > 
> >> > > on x86_64:
> >> > > 
> >> > > drivers/built-in.o: In function `dbgp_reset_prep':
> >> > > (.text+0xb96b5): undefined reference to `xen_dbgp_reset_prep'
> >> > > drivers/built-in.o: In function `dbgp_external_startup':
> >> > > (.text+0xb9d95): undefined reference to `xen_dbgp_external_startup'
> >> > > 
> >> > > 
> >> > > Full randconfig file is attached.
> >> > 
> >> > So this is because with !USB_SUPPORT but EARLY_PRINTK_DBGP
> >> > dbgp_reset_prep() and dbgp_external_startup() get pointlessly
> >> > defined and exported. This got broken by the merge
> >> > recommendation for the ARM side changes (originally compilation
> >> > of drivers/xen/dbgp.c depended on just CONFIG_XEN_DOM0).
> >> > 
> >> > >From my pov, fixing the USB side would be the clean solution (i.e.
> >> > putting those function definitions inside a CONFIG_USB_SUPPORT
> >> > conditional).
> >> >
> >> > The alternative of a smaller change would be to extend the
> >> > conditional around the respective xen_dbgp_...() declarations
> >> > in include/linux/usb/ehci_def.h to become
> >> > 
> >> > #if defined(CONFIG_XEN_DOM0) && defined(CONFIG_USB_SUPPORT)
> >> > 
> >> > Please advise towards your preference.
> >> 
> >> I think that your first suggestion is the right one.
> > 
> > Can you guys spin up a patch pls and make sure it does not break
> > compilation. Thx.
> 
> I'd really like to hear Greg's opinion on which route to take before
> pointlessly trying the other one.

I have no idea, please send patches.

greg k-h

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 14:15:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 14:15:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TROD8-0005zH-BF; Thu, 25 Oct 2012 14:15:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TROD6-0005z1-UF
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 14:15:01 +0000
Received: from [85.158.143.99:54533] by server-2.bemta-4.messagelabs.com id
	F1/50-22268-46949805; Thu, 25 Oct 2012 14:15:00 +0000
X-Env-Sender: gregkh@linuxfoundation.org
X-Msg-Ref: server-6.tower-216.messagelabs.com!1351174497!20327834!1
X-Originating-IP: [209.85.210.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13704 invoked from network); 25 Oct 2012 14:14:59 -0000
Received: from mail-da0-f45.google.com (HELO mail-da0-f45.google.com)
	(209.85.210.45)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 14:14:59 -0000
Received: by mail-da0-f45.google.com with SMTP id n15so839870dad.32
	for ; Thu, 25 Oct 2012 07:14:57 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent
	:x-gm-message-state;
	bh=psz2aKTq3xDN6SbnOigt29WxqTLXIAoQ3gJIrjPmmZU=;
	b=UzLRIe0FZYuncVDVDLpNpIoQuszDznhqNvN1ux5STdd1a8/ZgtGfe6ADqOvE5Bg/jm
	KBWUV3MoSnxhBGD/xeAY33S82q1tjOsth4qBqYiSPZe78RUfRlnsKybaBcxAtZ9a9y91
	kEbxbsQFbEl2HZDQFeAyMh8E9UWeiS0YhOl4ndt5lgjLSWF4lVUoVcB0djKFvpZFsm3N
	LBx59z+XPdX3Lc4Hz5OcOVZAJQljRXkfcj9xJu9zpe2b0J6qamu9Ex+UpAcyJ9u2F3Lr
	FiK5s9f5NsOFzVt5WN9Y8FFaBog1KwcqEDJWu7Qz/+wwUwP5c7lTnK/Eu2loEDu44Q7G
	UIEA==
Received: by 10.66.85.8 with SMTP id d8mr53719359paz.30.1351174497460;
	Thu, 25 Oct 2012 07:14:57 -0700 (PDT)
Received: from localhost (c-67-168-183-230.hsd1.wa.comcast.net.
	[67.168.183.230])
	by mx.google.com with ESMTPS id o1sm11349076paz.34.2012.10.25.07.14.55
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 25 Oct 2012 07:14:56 -0700 (PDT)
Date: Thu, 25 Oct 2012 07:15:35 -0700
From: "gregkh@linuxfoundation.org" 
To: Jan Beulich 
Message-ID: <20121025141535.GA29620@kroah.com>
References: <20121024151957.28a1626cd9a59c014e78c401@canb.auug.org.au>
	<50885EA8.3050007@xenotime.net>
	<508906CE02000078000A4553@nat28.tlf.novell.com>
	
	<20121025134628.GE26209@localhost.localdomain>
	<5089635702000078000A48D7@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5089635702000078000A48D7@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Gm-Message-State: ALoCoQlsVqyD5ukWgSQSlkkIphY0+Dv+ZTuVzv6QmeUciuvKmSxr5n0rQtktNiVDNF3Z/c7Y9hMT
Cc: Stephen Rothwell ,
	Jeremy Fitzhardinge ,
	Konrad Rzeszutek Wilk ,
	Stefano Stabellini ,
	"linux-kernel@vger.kernel.org" ,
	"virtualization@lists.linux-foundation.org"
	,
	Randy Dunlap ,
	"linux-next@vger.kernel.org" ,
	xen-devel 
Subject: Re: [Xen-devel] linux-next: Tree for Oct 24 (xen)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Oct 25, 2012 at 03:05:43PM +0100, Jan Beulich wrote:
> >>> On 25.10.12 at 15:46, Konrad Rzeszutek Wilk  wrote:
> > On Thu, Oct 25, 2012 at 11:48:30AM +0100, Stefano Stabellini wrote:
> >> On Thu, 25 Oct 2012, Jan Beulich wrote:
> >> > >>> On 24.10.12 at 23:33, Randy Dunlap  wrote:
> >> > > On 10/23/2012 09:19 PM, Stephen Rothwell wrote:
> >> > > 
> >> > >> Hi all,
> >> > >> 
> >> > >> Changes since 201201023:
> >> > >> 
> >> > > 
> >> > > on x86_64:
> >> > > 
> >> > > drivers/built-in.o: In function `dbgp_reset_prep':
> >> > > (.text+0xb96b5): undefined reference to `xen_dbgp_reset_prep'
> >> > > drivers/built-in.o: In function `dbgp_external_startup':
> >> > > (.text+0xb9d95): undefined reference to `xen_dbgp_external_startup'
> >> > > 
> >> > > 
> >> > > Full randconfig file is attached.
> >> > 
> >> > So this is because with !USB_SUPPORT but EARLY_PRINTK_DBGP
> >> > dbgp_reset_prep() and dbgp_external_startup() get pointlessly
> >> > defined and exported. This got broken by the merge
> >> > recommendation for the ARM side changes (originally compilation
> >> > of drivers/xen/dbgp.c depended on just CONFIG_XEN_DOM0).
> >> > 
> >> > >From my pov, fixing the USB side would be the clean solution (i.e.
> >> > putting those function definitions inside a CONFIG_USB_SUPPORT
> >> > conditional).
> >> >
> >> > The alternative of a smaller change would be to extend the
> >> > conditional around the respective xen_dbgp_...() declarations
> >> > in include/linux/usb/ehci_def.h to become
> >> > 
> >> > #if defined(CONFIG_XEN_DOM0) && defined(CONFIG_USB_SUPPORT)
> >> > 
> >> > Please advise towards your preference.
> >> 
> >> I think that your first suggestion is the right one.
> > 
> > Can you guys spin up a patch pls and make sure it does not break
> > compilation. Thx.
> 
> I'd really like to hear Greg's opinion on which route to take before
> pointlessly trying the other one.

I have no idea, please send patches.

greg k-h

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 14:18:51 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 14:18:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TROGc-0006Hm-VS; Thu, 25 Oct 2012 14:18:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TROGb-0006Hd-TC
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 14:18:38 +0000
Received: from [85.158.139.211:9558] by server-15.bemta-5.messagelabs.com id
	0F/E8-26920-D3A49805; Thu, 25 Oct 2012 14:18:37 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1351174715!23710177!1
X-Originating-IP: [216.32.180.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31595 invoked from network); 25 Oct 2012 14:18:36 -0000
Received: from va3ehsobe003.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.13)
	by server-8.tower-206.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Oct 2012 14:18:36 -0000
Received: from mail213-va3-R.bigfish.com (10.7.14.245) by
	VA3EHSOBE014.bigfish.com (10.7.40.64) with Microsoft SMTP Server id
	14.1.225.23; Thu, 25 Oct 2012 14:18:34 +0000
Received: from mail213-va3 (localhost [127.0.0.1])	by
	mail213-va3-R.bigfish.com (Postfix) with ESMTP id B083A54009B;
	Thu, 25 Oct 2012 14:18:34 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: -3
X-BigFish: VPS-3(zzbb2dI98dI1432Izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h)
Received: from mail213-va3 (localhost.localdomain [127.0.0.1]) by mail213-va3
	(MessageSwitch) id 1351174713345235_21744;
	Thu, 25 Oct 2012 14:18:33 +0000 (UTC)
Received: from VA3EHSMHS028.bigfish.com (unknown [10.7.14.247])	by
	mail213-va3.bigfish.com (Postfix) with ESMTP id 4F94A6C0078;
	Thu, 25 Oct 2012 14:18:33 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS028.bigfish.com (10.7.99.38) with Microsoft SMTP Server id
	14.1.225.23; Thu, 25 Oct 2012 14:18:26 +0000
X-WSS-ID: 0MCGD2N-02-27R-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 24235C80D0;	Thu, 25 Oct 2012 09:18:22 -0500 (CDT)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 25 Oct 2012 09:18:40 -0500
Received: from STOREXDAG03.amd.com (10.1.13.12) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Thu, 25 Oct 2012 09:18:23 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag03.amd.com
	(10.1.13.12) with Microsoft SMTP Server id 14.2.318.4; Thu, 25 Oct 2012
	10:18:22 -0400
Message-ID: <50894A2D.8030007@amd.com>
Date: Thu, 25 Oct 2012 16:18:21 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich 
References: <5089449C.7020700@amd.com>
	<5089646102000078000A48DA@nat28.tlf.novell.com>
In-Reply-To: <5089646102000078000A48DA@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] MCE: support cpu notification chain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/25/12 16:10, Jan Beulich wrote:
>>>> On 25.10.12 at 15:54, Christoph Egger  wrote:
>> Add support for cpu notification chain.
>> This is useful with nested virtualization when Xen
>> runs as l1 hypervisor.
>> This cleans up mce initialization cleanup as a side-effect.
> 
> Did you notice the fix I had done to your earlier patch before
> committing c/s 26106:1883c1d29de9? With the change here,
> mce_clear_banks will get allocated twice (once in generic code
> and once in AMD specific code), leaking one instance.

Ugh... must be a merge botch.

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 14:18:51 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 14:18:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TROGc-0006Hm-VS; Thu, 25 Oct 2012 14:18:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TROGb-0006Hd-TC
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 14:18:38 +0000
Received: from [85.158.139.211:9558] by server-15.bemta-5.messagelabs.com id
	0F/E8-26920-D3A49805; Thu, 25 Oct 2012 14:18:37 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1351174715!23710177!1
X-Originating-IP: [216.32.180.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31595 invoked from network); 25 Oct 2012 14:18:36 -0000
Received: from va3ehsobe003.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.13)
	by server-8.tower-206.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Oct 2012 14:18:36 -0000
Received: from mail213-va3-R.bigfish.com (10.7.14.245) by
	VA3EHSOBE014.bigfish.com (10.7.40.64) with Microsoft SMTP Server id
	14.1.225.23; Thu, 25 Oct 2012 14:18:34 +0000
Received: from mail213-va3 (localhost [127.0.0.1])	by
	mail213-va3-R.bigfish.com (Postfix) with ESMTP id B083A54009B;
	Thu, 25 Oct 2012 14:18:34 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: -3
X-BigFish: VPS-3(zzbb2dI98dI1432Izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h)
Received: from mail213-va3 (localhost.localdomain [127.0.0.1]) by mail213-va3
	(MessageSwitch) id 1351174713345235_21744;
	Thu, 25 Oct 2012 14:18:33 +0000 (UTC)
Received: from VA3EHSMHS028.bigfish.com (unknown [10.7.14.247])	by
	mail213-va3.bigfish.com (Postfix) with ESMTP id 4F94A6C0078;
	Thu, 25 Oct 2012 14:18:33 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS028.bigfish.com (10.7.99.38) with Microsoft SMTP Server id
	14.1.225.23; Thu, 25 Oct 2012 14:18:26 +0000
X-WSS-ID: 0MCGD2N-02-27R-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 24235C80D0;	Thu, 25 Oct 2012 09:18:22 -0500 (CDT)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 25 Oct 2012 09:18:40 -0500
Received: from STOREXDAG03.amd.com (10.1.13.12) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Thu, 25 Oct 2012 09:18:23 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag03.amd.com
	(10.1.13.12) with Microsoft SMTP Server id 14.2.318.4; Thu, 25 Oct 2012
	10:18:22 -0400
Message-ID: <50894A2D.8030007@amd.com>
Date: Thu, 25 Oct 2012 16:18:21 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich 
References: <5089449C.7020700@amd.com>
	<5089646102000078000A48DA@nat28.tlf.novell.com>
In-Reply-To: <5089646102000078000A48DA@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] MCE: support cpu notification chain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/25/12 16:10, Jan Beulich wrote:
>>>> On 25.10.12 at 15:54, Christoph Egger  wrote:
>> Add support for cpu notification chain.
>> This is useful with nested virtualization when Xen
>> runs as l1 hypervisor.
>> This cleans up mce initialization cleanup as a side-effect.
> 
> Did you notice the fix I had done to your earlier patch before
> committing c/s 26106:1883c1d29de9? With the change here,
> mce_clear_banks will get allocated twice (once in generic code
> and once in AMD specific code), leaking one instance.

Ugh... must be a merge botch.

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 14:23:23 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 14:23:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TROKw-0006UF-RA; Thu, 25 Oct 2012 14:23:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TROKv-0006U9-Ll
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 14:23:05 +0000
Received: from [85.158.139.211:26965] by server-14.bemta-5.messagelabs.com id
	8C/E2-21768-84B49805; Thu, 25 Oct 2012 14:23:04 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1351174984!23766691!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26580 invoked from network); 25 Oct 2012 14:23:04 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-206.messagelabs.com with SMTP;
	25 Oct 2012 14:23:04 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 25 Oct 2012 15:23:03 +0100
Message-Id: <5089676602000078000A4928@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 25 Oct 2012 15:23:02 +0100
From: "Jan Beulich" 
To: "Jinsong Liu" 
References: 
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk ,
	"linux-kernel@vger.kernel.org" ,
	xen-devel 
Subject: Re: [Xen-devel] [PATCH 1/2] Xen acpi pad implement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 25.10.12 at 14:19, "Liu, Jinsong"  wrote:
> --- /dev/null
> +++ b/drivers/xen/xen_acpi_pad.c
> @@ -0,0 +1,173 @@
> +/*
> + * xen_acpi_pad.c - Xen pad interface
> + *
> + * Copyright (c) 2012, Intel Corporation.
> + *    Author: Liu, Jinsong 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#if defined(CONFIG_ACPI_PROCESSOR_AGGREGATOR) || \
> +		defined(CONFIG_ACPI_PROCESSOR_AGGREGATOR_MODULE)
> +
> +#define ACPI_PROCESSOR_AGGREGATOR_CLASS	"acpi_pad"
> +#define ACPI_PROCESSOR_AGGREGATOR_DEVICE_NAME "Processor Aggregator"
> +#define ACPI_PROCESSOR_AGGREGATOR_NOTIFY 0x80
> +
> +static int xen_acpi_pad_idle_cpus(int *num_cpus)
> +{
> +	int ret;
> +

Stray blank line.

> +	struct xen_platform_op op = {
> +		.cmd = XENPF_core_parking,
> +		.interface_version = XENPF_INTERFACE_VERSION,

This is redundant with HYPERVISOR_dom0_op().

> +	};
> +
> +	/* set cpu nums expected to be idled */
> +	op.u.core_parking.type = XEN_CORE_PARKING_SET;
> +	op.u.core_parking.idle_nums = (uint32_t)*num_cpus;

It is quite a bit more efficient in terms of generated code to
initialize all fields using assignments (the use of an initializer
setting only a subset of fields will cause all other fields to get
zero initialized). In any case I think it is bad style to mix both
approaches.

> +	ret = HYPERVISOR_dom0_op(&op);
> +	if (ret)
> +		return ret;
> +
> +	/*
> +	 * get cpu nums actually be idled
> +	 * cannot get it by using hypercall once (shared with _SET)
> +	 * because of the characteristic of Xen continue_hypercall_on_cpu
> +	 */
> +	op.u.core_parking.type = XEN_CORE_PARKING_GET;
> +	ret = HYPERVISOR_dom0_op(&op);
> +	if (ret)
> +		return ret;
> +
> +	*num_cpus = op.u.core_parking.idle_nums;

"num_cpus" doesn't need to be a pointer, and you don't need to
call _GET here either - callers that care for the count in effect
after the call can invoke the corresponding _GET on their own.

> +	return 0;
> +}
> +
> +/*
> + * Query firmware how many CPUs should be idle
> + * return -1 on failure
> + */
> +static int xen_acpi_pad_pur(acpi_handle handle)
> +{
> +	struct acpi_buffer buffer = {ACPI_ALLOCATE_BUFFER, NULL};
> +	union acpi_object *package;
> +	int num = -1;
> +
> +	if (ACPI_FAILURE(acpi_evaluate_object(handle, "_PUR", NULL, &buffer)))
> +		return num;
> +
> +	if (!buffer.length || !buffer.pointer)
> +		return num;
> +
> +	package = buffer.pointer;
> +
> +	if (package->type == ACPI_TYPE_PACKAGE &&
> +		package->package.count == 2 &&
> +		package->package.elements[0].integer.value == 1) /* rev 1 */
> +
> +		num = package->package.elements[1].integer.value;
> +
> +	kfree(buffer.pointer);
> +	return num;
> +}
> +
> +/* Notify firmware how many CPUs are idle */
> +static void xen_acpi_pad_ost(acpi_handle handle, int stat,
> +	uint32_t idle_cpus)
> +{
> +	union acpi_object params[3] = {
> +		{.type = ACPI_TYPE_INTEGER,},
> +		{.type = ACPI_TYPE_INTEGER,},
> +		{.type = ACPI_TYPE_BUFFER,},
> +	};
> +	struct acpi_object_list arg_list = {3, params};
> +
> +	params[0].integer.value = ACPI_PROCESSOR_AGGREGATOR_NOTIFY;
> +	params[1].integer.value =  stat;
> +	params[2].buffer.length = 4;
> +	params[2].buffer.pointer = (void *)&idle_cpus;
> +	acpi_evaluate_object(handle, "_OST", &arg_list, NULL);
> +}
> +
> +static void xen_acpi_pad_handle_notify(acpi_handle handle)
> +{
> +	int ret, num_cpus;
> +
> +	num_cpus = xen_acpi_pad_pur(handle);
> +	if (num_cpus < 0)
> +		return;
> +
> +	ret = xen_acpi_pad_idle_cpus(&num_cpus);
> +	if (ret)
> +		return;
> +
> +	xen_acpi_pad_ost(handle, 0, num_cpus);
> +}
> +
> +static void xen_acpi_pad_notify(acpi_handle handle, u32 event,
> +	void *data)
> +{
> +	switch (event) {
> +	case ACPI_PROCESSOR_AGGREGATOR_NOTIFY:
> +		xen_acpi_pad_handle_notify(handle);
> +		break;
> +	default:
> +		pr_warn("Unsupported event [0x%x]\n", event);
> +		break;
> +	}
> +}
> +
> +static int xen_acpi_pad_add(struct acpi_device *device)
> +{
> +	acpi_status status;
> +
> +	strcpy(acpi_device_name(device), ACPI_PROCESSOR_AGGREGATOR_DEVICE_NAME);
> +	strcpy(acpi_device_class(device), ACPI_PROCESSOR_AGGREGATOR_CLASS);
> +
> +	status = acpi_install_notify_handler(device->handle,
> +		 ACPI_DEVICE_NOTIFY, xen_acpi_pad_notify, device);
> +	if (ACPI_FAILURE(status))
> +		return -ENODEV;
> +
> +	return 0;
> +}
> +
> +static const struct acpi_device_id pad_device_ids[] = {
> +	{"ACPI000C", 0},
> +	{"", 0},
> +};
> +
> +static struct acpi_driver xen_acpi_pad_driver = {
> +	.name = "processor_aggregator",
> +	.class = ACPI_PROCESSOR_AGGREGATOR_CLASS,
> +	.ids = pad_device_ids,
> +	.ops = {
> +		.add = xen_acpi_pad_add,

.remove?

> +	},
> +};
> +
> +static int __init xen_acpi_pad_init(void)
> +{
> +	/* Only DOM0 is responsible for Xen acpi pad */
> +	if (xen_initial_domain())
> +		return acpi_bus_register_driver(&xen_acpi_pad_driver);
> +
> +	return -ENODEV;
> +}
> +subsys_initcall(xen_acpi_pad_init);
> +
> +#endif

Overall I'd recommend taking a look at the cleaned up driver in
our kernels.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 14:23:23 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 14:23:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TROKw-0006UF-RA; Thu, 25 Oct 2012 14:23:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TROKv-0006U9-Ll
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 14:23:05 +0000
Received: from [85.158.139.211:26965] by server-14.bemta-5.messagelabs.com id
	8C/E2-21768-84B49805; Thu, 25 Oct 2012 14:23:04 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1351174984!23766691!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26580 invoked from network); 25 Oct 2012 14:23:04 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-206.messagelabs.com with SMTP;
	25 Oct 2012 14:23:04 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 25 Oct 2012 15:23:03 +0100
Message-Id: <5089676602000078000A4928@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 25 Oct 2012 15:23:02 +0100
From: "Jan Beulich" 
To: "Jinsong Liu" 
References: 
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk ,
	"linux-kernel@vger.kernel.org" ,
	xen-devel 
Subject: Re: [Xen-devel] [PATCH 1/2] Xen acpi pad implement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 25.10.12 at 14:19, "Liu, Jinsong"  wrote:
> --- /dev/null
> +++ b/drivers/xen/xen_acpi_pad.c
> @@ -0,0 +1,173 @@
> +/*
> + * xen_acpi_pad.c - Xen pad interface
> + *
> + * Copyright (c) 2012, Intel Corporation.
> + *    Author: Liu, Jinsong 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#if defined(CONFIG_ACPI_PROCESSOR_AGGREGATOR) || \
> +		defined(CONFIG_ACPI_PROCESSOR_AGGREGATOR_MODULE)
> +
> +#define ACPI_PROCESSOR_AGGREGATOR_CLASS	"acpi_pad"
> +#define ACPI_PROCESSOR_AGGREGATOR_DEVICE_NAME "Processor Aggregator"
> +#define ACPI_PROCESSOR_AGGREGATOR_NOTIFY 0x80
> +
> +static int xen_acpi_pad_idle_cpus(int *num_cpus)
> +{
> +	int ret;
> +

Stray blank line.

> +	struct xen_platform_op op = {
> +		.cmd = XENPF_core_parking,
> +		.interface_version = XENPF_INTERFACE_VERSION,

This is redundant with HYPERVISOR_dom0_op().

> +	};
> +
> +	/* set cpu nums expected to be idled */
> +	op.u.core_parking.type = XEN_CORE_PARKING_SET;
> +	op.u.core_parking.idle_nums = (uint32_t)*num_cpus;

It is quite a bit more efficient in terms of generated code to
initialize all fields using assignments (the use of an initializer
setting only a subset of fields will cause all other fields to get
zero initialized). In any case I think it is bad style to mix both
approaches.

> +	ret = HYPERVISOR_dom0_op(&op);
> +	if (ret)
> +		return ret;
> +
> +	/*
> +	 * get cpu nums actually be idled
> +	 * cannot get it by using hypercall once (shared with _SET)
> +	 * because of the characteristic of Xen continue_hypercall_on_cpu
> +	 */
> +	op.u.core_parking.type = XEN_CORE_PARKING_GET;
> +	ret = HYPERVISOR_dom0_op(&op);
> +	if (ret)
> +		return ret;
> +
> +	*num_cpus = op.u.core_parking.idle_nums;

"num_cpus" doesn't need to be a pointer, and you don't need to
call _GET here either - callers that care for the count in effect
after the call can invoke the corresponding _GET on their own.

> +	return 0;
> +}
> +
> +/*
> + * Query firmware how many CPUs should be idle
> + * return -1 on failure
> + */
> +static int xen_acpi_pad_pur(acpi_handle handle)
> +{
> +	struct acpi_buffer buffer = {ACPI_ALLOCATE_BUFFER, NULL};
> +	union acpi_object *package;
> +	int num = -1;
> +
> +	if (ACPI_FAILURE(acpi_evaluate_object(handle, "_PUR", NULL, &buffer)))
> +		return num;
> +
> +	if (!buffer.length || !buffer.pointer)
> +		return num;
> +
> +	package = buffer.pointer;
> +
> +	if (package->type == ACPI_TYPE_PACKAGE &&
> +		package->package.count == 2 &&
> +		package->package.elements[0].integer.value == 1) /* rev 1 */
> +
> +		num = package->package.elements[1].integer.value;
> +
> +	kfree(buffer.pointer);
> +	return num;
> +}
> +
> +/* Notify firmware how many CPUs are idle */
> +static void xen_acpi_pad_ost(acpi_handle handle, int stat,
> +	uint32_t idle_cpus)
> +{
> +	union acpi_object params[3] = {
> +		{.type = ACPI_TYPE_INTEGER,},
> +		{.type = ACPI_TYPE_INTEGER,},
> +		{.type = ACPI_TYPE_BUFFER,},
> +	};
> +	struct acpi_object_list arg_list = {3, params};
> +
> +	params[0].integer.value = ACPI_PROCESSOR_AGGREGATOR_NOTIFY;
> +	params[1].integer.value =  stat;
> +	params[2].buffer.length = 4;
> +	params[2].buffer.pointer = (void *)&idle_cpus;
> +	acpi_evaluate_object(handle, "_OST", &arg_list, NULL);
> +}
> +
> +static void xen_acpi_pad_handle_notify(acpi_handle handle)
> +{
> +	int ret, num_cpus;
> +
> +	num_cpus = xen_acpi_pad_pur(handle);
> +	if (num_cpus < 0)
> +		return;
> +
> +	ret = xen_acpi_pad_idle_cpus(&num_cpus);
> +	if (ret)
> +		return;
> +
> +	xen_acpi_pad_ost(handle, 0, num_cpus);
> +}
> +
> +static void xen_acpi_pad_notify(acpi_handle handle, u32 event,
> +	void *data)
> +{
> +	switch (event) {
> +	case ACPI_PROCESSOR_AGGREGATOR_NOTIFY:
> +		xen_acpi_pad_handle_notify(handle);
> +		break;
> +	default:
> +		pr_warn("Unsupported event [0x%x]\n", event);
> +		break;
> +	}
> +}
> +
> +static int xen_acpi_pad_add(struct acpi_device *device)
> +{
> +	acpi_status status;
> +
> +	strcpy(acpi_device_name(device), ACPI_PROCESSOR_AGGREGATOR_DEVICE_NAME);
> +	strcpy(acpi_device_class(device), ACPI_PROCESSOR_AGGREGATOR_CLASS);
> +
> +	status = acpi_install_notify_handler(device->handle,
> +		 ACPI_DEVICE_NOTIFY, xen_acpi_pad_notify, device);
> +	if (ACPI_FAILURE(status))
> +		return -ENODEV;
> +
> +	return 0;
> +}
> +
> +static const struct acpi_device_id pad_device_ids[] = {
> +	{"ACPI000C", 0},
> +	{"", 0},
> +};
> +
> +static struct acpi_driver xen_acpi_pad_driver = {
> +	.name = "processor_aggregator",
> +	.class = ACPI_PROCESSOR_AGGREGATOR_CLASS,
> +	.ids = pad_device_ids,
> +	.ops = {
> +		.add = xen_acpi_pad_add,

.remove?

> +	},
> +};
> +
> +static int __init xen_acpi_pad_init(void)
> +{
> +	/* Only DOM0 is responsible for Xen acpi pad */
> +	if (xen_initial_domain())
> +		return acpi_bus_register_driver(&xen_acpi_pad_driver);
> +
> +	return -ENODEV;
> +}
> +subsys_initcall(xen_acpi_pad_init);
> +
> +#endif

Overall I'd recommend taking a look at the cleaned up driver in
our kernels.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 14:46:26 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 14:46:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TROh7-0006k8-Sw; Thu, 25 Oct 2012 14:46:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TROh5-0006k3-NE
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 14:46:00 +0000
Received: from [85.158.137.99:5179] by server-5.bemta-3.messagelabs.com id
	3C/13-12440-6A059805; Thu, 25 Oct 2012 14:45:58 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1351176356!18236550!1
X-Originating-IP: [216.32.180.14]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26830 invoked from network); 25 Oct 2012 14:45:57 -0000
Received: from va3ehsobe004.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.14)
	by server-7.tower-217.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Oct 2012 14:45:57 -0000
Received: from mail197-va3-R.bigfish.com (10.7.14.248) by
	VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id
	14.1.225.23; Thu, 25 Oct 2012 14:45:56 +0000
Received: from mail197-va3 (localhost [127.0.0.1])	by
	mail197-va3-R.bigfish.com (Postfix) with ESMTP id DDE4560067;
	Thu, 25 Oct 2012 14:45:55 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: -3
X-BigFish: VPS-3(zzbb2dI98dIc85fhc85dh1432Izz1202h1d1ah1d2ahzz8275bhz2dh668h839he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh34h1155h)
Received: from mail197-va3 (localhost.localdomain [127.0.0.1]) by mail197-va3
	(MessageSwitch) id 135117635437676_25541;
	Thu, 25 Oct 2012 14:45:54 +0000 (UTC)
Received: from VA3EHSMHS011.bigfish.com (unknown [10.7.14.249])	by
	mail197-va3.bigfish.com (Postfix) with ESMTP id F05DFE00A9;
	Thu, 25 Oct 2012 14:45:53 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS011.bigfish.com (10.7.99.21) with Microsoft SMTP Server id
	14.1.225.23; Thu, 25 Oct 2012 14:45:49 +0000
X-WSS-ID: 0MCGECC-01-H2Y-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 23E031028099;	Thu, 25 Oct 2012 09:45:47 -0500 (CDT)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 25 Oct 2012 09:46:04 -0500
Received: from STOREXDAG04.amd.com (10.1.13.13) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Thu, 25 Oct 2012 09:45:47 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag04.amd.com
	(10.1.13.13) with Microsoft SMTP Server id 14.2.318.4; Thu, 25 Oct 2012
	10:45:45 -0400
Message-ID: <50895098.50405@amd.com>
Date: Thu, 25 Oct 2012 16:45:44 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich 
References: <5089449C.7020700@amd.com>
	<5089646102000078000A48DA@nat28.tlf.novell.com>
	<50894A2D.8030007@amd.com>
In-Reply-To: <50894A2D.8030007@amd.com>
Content-Type: multipart/mixed; boundary="------------030003000508070003020702"
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] MCE: support cpu notification chain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------030003000508070003020702
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

On 10/25/12 16:18, Christoph Egger wrote:
> On 10/25/12 16:10, Jan Beulich wrote:
>>>>> On 25.10.12 at 15:54, Christoph Egger  wrote:
>>> Add support for cpu notification chain.
>>> This is useful with nested virtualization when Xen
>>> runs as l1 hypervisor.
>>> This cleans up mce initialization cleanup as a side-effect.
>>
>> Did you notice the fix I had done to your earlier patch before
>> committing c/s 26106:1883c1d29de9? With the change here,
>> mce_clear_banks will get allocated twice (once in generic code
>> and once in AMD specific code), leaking one instance.
> 
> Ugh... must be a merge botch.

Updated patch attached.

Signed-off-by: Christoph Egger 


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------030003000508070003020702
Content-Type: text/plain; charset="us-ascii"; name="xen_mce_init.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_mce_init.diff"
Content-Description: xen_mce_init.diff

diff -r 7abb25095de0 xen/arch/x86/cpu/mcheck/mce.c
--- a/xen/arch/x86/cpu/mcheck/mce.c	Thu Oct 25 13:15:19 2012 +0200
+++ b/xen/arch/x86/cpu/mcheck/mce.c	Thu Oct 25 15:13:24 2012 +0200
@@ -560,30 +560,6 @@ void mcheck_mca_clearbanks(struct mca_ba
     }
 }
 
-static enum mcheck_type amd_mcheck_init(struct cpuinfo_x86 *ci)
-{
-    enum mcheck_type rc = mcheck_none;
-
-    switch (ci->x86) {
-    case 6:
-        rc = amd_k7_mcheck_init(ci);
-        break;
-
-    default:
-        /* Assume that machine check support is available.
-         * The minimum provided support is at least the K8. */
-    case 0xf:
-        rc = amd_k8_mcheck_init(ci);
-        break;
-
-    case 0x10 ... 0x17:
-        rc = amd_f10_mcheck_init(ci);
-        break;
-    }
-
-    return rc;
-}
-
 /*check the existence of Machine Check*/
 int mce_available(struct cpuinfo_x86 *c)
 {
@@ -774,7 +750,7 @@ void mcheck_init(struct cpuinfo_x86 *c, 
 
     switch (c->x86_vendor) {
     case X86_VENDOR_AMD:
-        inited = amd_mcheck_init(c);
+        inited = amd_mcheck_init(c, bsp);
         break;
 
     case X86_VENDOR_INTEL:
diff -r 7abb25095de0 xen/arch/x86/cpu/mcheck/mce.h
--- a/xen/arch/x86/cpu/mcheck/mce.h	Thu Oct 25 13:15:19 2012 +0200
+++ b/xen/arch/x86/cpu/mcheck/mce.h	Thu Oct 25 15:13:24 2012 +0200
@@ -39,10 +39,7 @@ enum mcheck_type {
 };
 
 /* Init functions */
-enum mcheck_type amd_k7_mcheck_init(struct cpuinfo_x86 *c);
-enum mcheck_type amd_k8_mcheck_init(struct cpuinfo_x86 *c);
-enum mcheck_type amd_f10_mcheck_init(struct cpuinfo_x86 *c);
-
+enum mcheck_type amd_mcheck_init(struct cpuinfo_x86 *c, bool_t bsp);
 enum mcheck_type intel_mcheck_init(struct cpuinfo_x86 *c, bool_t bsp);
 
 void intel_mcheck_timer(struct cpuinfo_x86 *c);
diff -r 7abb25095de0 xen/arch/x86/cpu/mcheck/mce_amd.c
--- a/xen/arch/x86/cpu/mcheck/mce_amd.c	Thu Oct 25 13:15:19 2012 +0200
+++ b/xen/arch/x86/cpu/mcheck/mce_amd.c	Thu Oct 25 15:13:24 2012 +0200
@@ -19,6 +19,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -98,3 +99,53 @@ mc_amd_addrcheck(uint64_t status, uint64
     BUG();
     return 0;
 }
+
+static int
+amd_cpu_callback(struct notifier_block *nfb, unsigned long action, void *hcpu)
+{
+    int rc = 0;
+
+    switch (action) {
+    case CPU_DYING:
+        clear_in_cr4(X86_CR4_MCE);
+        break;
+    default:
+        break;
+    }
+
+    return notifier_from_errno(rc);
+}
+
+static struct notifier_block cpu_nfb = {
+    .notifier_call = amd_cpu_callback
+};
+
+enum mcheck_type
+amd_mcheck_init(struct cpuinfo_x86 *ci, bool_t bsp)
+{
+    enum mcheck_type rc = mcheck_none;
+
+    if (bsp) {
+        /* Early MCE initialization for BSP. */
+        register_cpu_notifier(&cpu_nfb);
+    }
+
+    switch (ci->x86) {
+    case 6:
+        rc = amd_k7_mcheck_init(ci);
+        break;
+
+    default:
+        /* Assume that machine check support is available.
+         * The minimum provided support is at least the K8. */
+    case 0xf:
+        rc = amd_k8_mcheck_init(ci);
+        break;
+
+    case 0x10 ... 0x17:
+        rc = amd_f10_mcheck_init(ci);
+        break;
+    }
+
+    return rc;
+}
diff -r 7abb25095de0 xen/arch/x86/cpu/mcheck/mce_amd.h
--- a/xen/arch/x86/cpu/mcheck/mce_amd.h	Thu Oct 25 13:15:19 2012 +0200
+++ b/xen/arch/x86/cpu/mcheck/mce_amd.h	Thu Oct 25 15:13:24 2012 +0200
@@ -1,6 +1,10 @@
 #ifndef _MCHECK_AMD_H
 #define _MCHECK_AMD_H
 
+enum mcheck_type amd_k7_mcheck_init(struct cpuinfo_x86 *c);
+enum mcheck_type amd_k8_mcheck_init(struct cpuinfo_x86 *c);
+enum mcheck_type amd_f10_mcheck_init(struct cpuinfo_x86 *c);
+
 int mc_amd_recoverable_scan(uint64_t status);
 int mc_amd_addrcheck(uint64_t status, uint64_t misc, int addrtype);
 

--------------030003000508070003020702
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------030003000508070003020702--


From xen-devel-bounces@lists.xen.org Thu Oct 25 14:46:26 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 14:46:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TROh7-0006k8-Sw; Thu, 25 Oct 2012 14:46:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TROh5-0006k3-NE
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 14:46:00 +0000
Received: from [85.158.137.99:5179] by server-5.bemta-3.messagelabs.com id
	3C/13-12440-6A059805; Thu, 25 Oct 2012 14:45:58 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1351176356!18236550!1
X-Originating-IP: [216.32.180.14]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26830 invoked from network); 25 Oct 2012 14:45:57 -0000
Received: from va3ehsobe004.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.14)
	by server-7.tower-217.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Oct 2012 14:45:57 -0000
Received: from mail197-va3-R.bigfish.com (10.7.14.248) by
	VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id
	14.1.225.23; Thu, 25 Oct 2012 14:45:56 +0000
Received: from mail197-va3 (localhost [127.0.0.1])	by
	mail197-va3-R.bigfish.com (Postfix) with ESMTP id DDE4560067;
	Thu, 25 Oct 2012 14:45:55 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: -3
X-BigFish: VPS-3(zzbb2dI98dIc85fhc85dh1432Izz1202h1d1ah1d2ahzz8275bhz2dh668h839he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh34h1155h)
Received: from mail197-va3 (localhost.localdomain [127.0.0.1]) by mail197-va3
	(MessageSwitch) id 135117635437676_25541;
	Thu, 25 Oct 2012 14:45:54 +0000 (UTC)
Received: from VA3EHSMHS011.bigfish.com (unknown [10.7.14.249])	by
	mail197-va3.bigfish.com (Postfix) with ESMTP id F05DFE00A9;
	Thu, 25 Oct 2012 14:45:53 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS011.bigfish.com (10.7.99.21) with Microsoft SMTP Server id
	14.1.225.23; Thu, 25 Oct 2012 14:45:49 +0000
X-WSS-ID: 0MCGECC-01-H2Y-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 23E031028099;	Thu, 25 Oct 2012 09:45:47 -0500 (CDT)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 25 Oct 2012 09:46:04 -0500
Received: from STOREXDAG04.amd.com (10.1.13.13) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Thu, 25 Oct 2012 09:45:47 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag04.amd.com
	(10.1.13.13) with Microsoft SMTP Server id 14.2.318.4; Thu, 25 Oct 2012
	10:45:45 -0400
Message-ID: <50895098.50405@amd.com>
Date: Thu, 25 Oct 2012 16:45:44 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich 
References: <5089449C.7020700@amd.com>
	<5089646102000078000A48DA@nat28.tlf.novell.com>
	<50894A2D.8030007@amd.com>
In-Reply-To: <50894A2D.8030007@amd.com>
Content-Type: multipart/mixed; boundary="------------030003000508070003020702"
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] MCE: support cpu notification chain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------030003000508070003020702
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

On 10/25/12 16:18, Christoph Egger wrote:
> On 10/25/12 16:10, Jan Beulich wrote:
>>>>> On 25.10.12 at 15:54, Christoph Egger  wrote:
>>> Add support for cpu notification chain.
>>> This is useful with nested virtualization when Xen
>>> runs as l1 hypervisor.
>>> This cleans up mce initialization cleanup as a side-effect.
>>
>> Did you notice the fix I had done to your earlier patch before
>> committing c/s 26106:1883c1d29de9? With the change here,
>> mce_clear_banks will get allocated twice (once in generic code
>> and once in AMD specific code), leaking one instance.
> 
> Ugh... must be a merge botch.

Updated patch attached.

Signed-off-by: Christoph Egger 


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------030003000508070003020702
Content-Type: text/plain; charset="us-ascii"; name="xen_mce_init.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_mce_init.diff"
Content-Description: xen_mce_init.diff

diff -r 7abb25095de0 xen/arch/x86/cpu/mcheck/mce.c
--- a/xen/arch/x86/cpu/mcheck/mce.c	Thu Oct 25 13:15:19 2012 +0200
+++ b/xen/arch/x86/cpu/mcheck/mce.c	Thu Oct 25 15:13:24 2012 +0200
@@ -560,30 +560,6 @@ void mcheck_mca_clearbanks(struct mca_ba
     }
 }
 
-static enum mcheck_type amd_mcheck_init(struct cpuinfo_x86 *ci)
-{
-    enum mcheck_type rc = mcheck_none;
-
-    switch (ci->x86) {
-    case 6:
-        rc = amd_k7_mcheck_init(ci);
-        break;
-
-    default:
-        /* Assume that machine check support is available.
-         * The minimum provided support is at least the K8. */
-    case 0xf:
-        rc = amd_k8_mcheck_init(ci);
-        break;
-
-    case 0x10 ... 0x17:
-        rc = amd_f10_mcheck_init(ci);
-        break;
-    }
-
-    return rc;
-}
-
 /*check the existence of Machine Check*/
 int mce_available(struct cpuinfo_x86 *c)
 {
@@ -774,7 +750,7 @@ void mcheck_init(struct cpuinfo_x86 *c, 
 
     switch (c->x86_vendor) {
     case X86_VENDOR_AMD:
-        inited = amd_mcheck_init(c);
+        inited = amd_mcheck_init(c, bsp);
         break;
 
     case X86_VENDOR_INTEL:
diff -r 7abb25095de0 xen/arch/x86/cpu/mcheck/mce.h
--- a/xen/arch/x86/cpu/mcheck/mce.h	Thu Oct 25 13:15:19 2012 +0200
+++ b/xen/arch/x86/cpu/mcheck/mce.h	Thu Oct 25 15:13:24 2012 +0200
@@ -39,10 +39,7 @@ enum mcheck_type {
 };
 
 /* Init functions */
-enum mcheck_type amd_k7_mcheck_init(struct cpuinfo_x86 *c);
-enum mcheck_type amd_k8_mcheck_init(struct cpuinfo_x86 *c);
-enum mcheck_type amd_f10_mcheck_init(struct cpuinfo_x86 *c);
-
+enum mcheck_type amd_mcheck_init(struct cpuinfo_x86 *c, bool_t bsp);
 enum mcheck_type intel_mcheck_init(struct cpuinfo_x86 *c, bool_t bsp);
 
 void intel_mcheck_timer(struct cpuinfo_x86 *c);
diff -r 7abb25095de0 xen/arch/x86/cpu/mcheck/mce_amd.c
--- a/xen/arch/x86/cpu/mcheck/mce_amd.c	Thu Oct 25 13:15:19 2012 +0200
+++ b/xen/arch/x86/cpu/mcheck/mce_amd.c	Thu Oct 25 15:13:24 2012 +0200
@@ -19,6 +19,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -98,3 +99,53 @@ mc_amd_addrcheck(uint64_t status, uint64
     BUG();
     return 0;
 }
+
+static int
+amd_cpu_callback(struct notifier_block *nfb, unsigned long action, void *hcpu)
+{
+    int rc = 0;
+
+    switch (action) {
+    case CPU_DYING:
+        clear_in_cr4(X86_CR4_MCE);
+        break;
+    default:
+        break;
+    }
+
+    return notifier_from_errno(rc);
+}
+
+static struct notifier_block cpu_nfb = {
+    .notifier_call = amd_cpu_callback
+};
+
+enum mcheck_type
+amd_mcheck_init(struct cpuinfo_x86 *ci, bool_t bsp)
+{
+    enum mcheck_type rc = mcheck_none;
+
+    if (bsp) {
+        /* Early MCE initialization for BSP. */
+        register_cpu_notifier(&cpu_nfb);
+    }
+
+    switch (ci->x86) {
+    case 6:
+        rc = amd_k7_mcheck_init(ci);
+        break;
+
+    default:
+        /* Assume that machine check support is available.
+         * The minimum provided support is at least the K8. */
+    case 0xf:
+        rc = amd_k8_mcheck_init(ci);
+        break;
+
+    case 0x10 ... 0x17:
+        rc = amd_f10_mcheck_init(ci);
+        break;
+    }
+
+    return rc;
+}
diff -r 7abb25095de0 xen/arch/x86/cpu/mcheck/mce_amd.h
--- a/xen/arch/x86/cpu/mcheck/mce_amd.h	Thu Oct 25 13:15:19 2012 +0200
+++ b/xen/arch/x86/cpu/mcheck/mce_amd.h	Thu Oct 25 15:13:24 2012 +0200
@@ -1,6 +1,10 @@
 #ifndef _MCHECK_AMD_H
 #define _MCHECK_AMD_H
 
+enum mcheck_type amd_k7_mcheck_init(struct cpuinfo_x86 *c);
+enum mcheck_type amd_k8_mcheck_init(struct cpuinfo_x86 *c);
+enum mcheck_type amd_f10_mcheck_init(struct cpuinfo_x86 *c);
+
 int mc_amd_recoverable_scan(uint64_t status);
 int mc_amd_addrcheck(uint64_t status, uint64_t misc, int addrtype);
 

--------------030003000508070003020702
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------030003000508070003020702--


From xen-devel-bounces@lists.xen.org Thu Oct 25 14:57:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 14:57:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TROrt-0006tq-44; Thu, 25 Oct 2012 14:57:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TROrr-0006tl-Te
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 14:57:08 +0000
Received: from [85.158.137.99:43992] by server-9.bemta-3.messagelabs.com id
	58/48-16841-14359805; Thu, 25 Oct 2012 14:57:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1351177024!18238350!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1924 invoked from network); 25 Oct 2012 14:57:04 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-217.messagelabs.com with SMTP;
	25 Oct 2012 14:57:04 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 25 Oct 2012 15:57:03 +0100
Message-Id: <50896F5D02000078000A4991@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 25 Oct 2012 15:57:01 +0100
From: "Jan Beulich" 
To: "Christoph Egger" 
References: <5089449C.7020700@amd.com>
	<5089646102000078000A48DA@nat28.tlf.novell.com>
	<50894A2D.8030007@amd.com> <50895098.50405@amd.com>
In-Reply-To: <50895098.50405@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] MCE: support cpu notification chain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 25.10.12 at 16:45, Christoph Egger  wrote:
> On 10/25/12 16:18, Christoph Egger wrote:
>> On 10/25/12 16:10, Jan Beulich wrote:
>>>>>> On 25.10.12 at 15:54, Christoph Egger  wrote:
>>>> Add support for cpu notification chain.
>>>> This is useful with nested virtualization when Xen
>>>> runs as l1 hypervisor.
>>>> This cleans up mce initialization cleanup as a side-effect.
>>>
>>> Did you notice the fix I had done to your earlier patch before
>>> committing c/s 26106:1883c1d29de9? With the change here,
>>> mce_clear_banks will get allocated twice (once in generic code
>>> and once in AMD specific code), leaking one instance.
>> 
>> Ugh... must be a merge botch.
> 
> Updated patch attached.
> 
> Signed-off-by: Christoph Egger 

Subject and patch don't really fit together anymore. This is
mostly cleanup (code movement) now, and I wonder whether
this

>+amd_cpu_callback(struct notifier_block *nfb, unsigned long action, void *hcpu)
>+{
>+    int rc = 0;
>+
>+    switch (action) {
>+    case CPU_DYING:
>+        clear_in_cr4(X86_CR4_MCE);
>+        break;

if needed at all, isn't rather to be put in generic code (you might
need to settle on this with the Intel folks). In any case it would
need an explanation in the commit message.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 14:57:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 14:57:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TROrt-0006tq-44; Thu, 25 Oct 2012 14:57:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TROrr-0006tl-Te
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 14:57:08 +0000
Received: from [85.158.137.99:43992] by server-9.bemta-3.messagelabs.com id
	58/48-16841-14359805; Thu, 25 Oct 2012 14:57:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1351177024!18238350!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1924 invoked from network); 25 Oct 2012 14:57:04 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-217.messagelabs.com with SMTP;
	25 Oct 2012 14:57:04 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 25 Oct 2012 15:57:03 +0100
Message-Id: <50896F5D02000078000A4991@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 25 Oct 2012 15:57:01 +0100
From: "Jan Beulich" 
To: "Christoph Egger" 
References: <5089449C.7020700@amd.com>
	<5089646102000078000A48DA@nat28.tlf.novell.com>
	<50894A2D.8030007@amd.com> <50895098.50405@amd.com>
In-Reply-To: <50895098.50405@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] MCE: support cpu notification chain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 25.10.12 at 16:45, Christoph Egger  wrote:
> On 10/25/12 16:18, Christoph Egger wrote:
>> On 10/25/12 16:10, Jan Beulich wrote:
>>>>>> On 25.10.12 at 15:54, Christoph Egger  wrote:
>>>> Add support for cpu notification chain.
>>>> This is useful with nested virtualization when Xen
>>>> runs as l1 hypervisor.
>>>> This cleans up mce initialization cleanup as a side-effect.
>>>
>>> Did you notice the fix I had done to your earlier patch before
>>> committing c/s 26106:1883c1d29de9? With the change here,
>>> mce_clear_banks will get allocated twice (once in generic code
>>> and once in AMD specific code), leaking one instance.
>> 
>> Ugh... must be a merge botch.
> 
> Updated patch attached.
> 
> Signed-off-by: Christoph Egger 

Subject and patch don't really fit together anymore. This is
mostly cleanup (code movement) now, and I wonder whether
this

>+amd_cpu_callback(struct notifier_block *nfb, unsigned long action, void *hcpu)
>+{
>+    int rc = 0;
>+
>+    switch (action) {
>+    case CPU_DYING:
>+        clear_in_cr4(X86_CR4_MCE);
>+        break;

if needed at all, isn't rather to be put in generic code (you might
need to settle on this with the Intel folks). In any case it would
need an explanation in the commit message.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 15:02:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 15:02:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TROxC-00074P-St; Thu, 25 Oct 2012 15:02:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TROxB-00074J-Bi
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 15:02:37 +0000
Received: from [85.158.139.83:55319] by server-5.bemta-5.messagelabs.com id
	55/31-09732-C8459805; Thu, 25 Oct 2012 15:02:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1351177355!32600393!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9177 invoked from network); 25 Oct 2012 15:02:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 15:02:36 -0000
X-IronPort-AV: E=Sophos;i="4.80,648,1344211200"; d="scan'208";a="15392687"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 15:02:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 16:02:14 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TROwo-00063G-AR; Thu, 25 Oct 2012 15:02:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TROwo-000141-61;
	Thu, 25 Oct 2012 16:02:14 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20617.21621.886298.796143@mariner.uk.xensource.com>
Date: Thu, 25 Oct 2012 16:02:13 +0100
To: "Charles Arnold" 
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <50814E190200009100082117@novprvoes0310.provo.novell.com>
References: <50814E190200009100082117@novprvoes0310.provo.novell.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] pygrub: Add option to list grub entries
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Charles Arnold writes ("[Xen-devel]  [PATCH] pygrub: Add option to list grub entries"):
> pygrub: Add option to list grub entries
> 
> The argument to "--entry" allows 2 syntaxes, either directly the entry number
> in menu.lst, or the whole string behind the "title" key word. This poses the
> following issue:
> >From Dom0 there is no way to guess the number and, or the complete title
> string because this string contains the kernel version, which will change
> with a kernel update.
> This patch adds [-l|--list-entries] as an argument to pygrub.

> +    if list_entries:
> +        for i in range(len(g.cf.images)):
> +            img = g.cf.images[i]
> +            print "title: %s" % img.title
> +            print "  root: %s" % img.root
> +            print "  kernel: %s" % img.kernel[1]
> +            print "  args: %s" % img.args
> +            print "  initrd: %s" % img.initrd[1]

Is it possible for any of these to contain newlines ?  I don't think
so but I'm not entirely sure.  If it is then they need to be quoted
somehow or the caller may be unable to unambigously parse the output.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 15:02:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 15:02:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TROxC-00074P-St; Thu, 25 Oct 2012 15:02:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TROxB-00074J-Bi
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 15:02:37 +0000
Received: from [85.158.139.83:55319] by server-5.bemta-5.messagelabs.com id
	55/31-09732-C8459805; Thu, 25 Oct 2012 15:02:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1351177355!32600393!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9177 invoked from network); 25 Oct 2012 15:02:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 15:02:36 -0000
X-IronPort-AV: E=Sophos;i="4.80,648,1344211200"; d="scan'208";a="15392687"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 15:02:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 16:02:14 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TROwo-00063G-AR; Thu, 25 Oct 2012 15:02:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TROwo-000141-61;
	Thu, 25 Oct 2012 16:02:14 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20617.21621.886298.796143@mariner.uk.xensource.com>
Date: Thu, 25 Oct 2012 16:02:13 +0100
To: "Charles Arnold" 
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <50814E190200009100082117@novprvoes0310.provo.novell.com>
References: <50814E190200009100082117@novprvoes0310.provo.novell.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] pygrub: Add option to list grub entries
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Charles Arnold writes ("[Xen-devel]  [PATCH] pygrub: Add option to list grub entries"):
> pygrub: Add option to list grub entries
> 
> The argument to "--entry" allows 2 syntaxes, either directly the entry number
> in menu.lst, or the whole string behind the "title" key word. This poses the
> following issue:
> >From Dom0 there is no way to guess the number and, or the complete title
> string because this string contains the kernel version, which will change
> with a kernel update.
> This patch adds [-l|--list-entries] as an argument to pygrub.

> +    if list_entries:
> +        for i in range(len(g.cf.images)):
> +            img = g.cf.images[i]
> +            print "title: %s" % img.title
> +            print "  root: %s" % img.root
> +            print "  kernel: %s" % img.kernel[1]
> +            print "  args: %s" % img.args
> +            print "  initrd: %s" % img.initrd[1]

Is it possible for any of these to contain newlines ?  I don't think
so but I'm not entirely sure.  If it is then they need to be quoted
somehow or the caller may be unable to unambigously parse the output.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 15:05:38 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 15:05:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TROzf-0007DX-FK; Thu, 25 Oct 2012 15:05:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TROzd-0007DH-Ez
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 15:05:09 +0000
Received: from [85.158.139.211:25575] by server-12.bemta-5.messagelabs.com id
	89/04-26919-42559805; Thu, 25 Oct 2012 15:05:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1351177507!23251296!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24753 invoked from network); 25 Oct 2012 15:05:08 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 15:05:08 -0000
X-IronPort-AV: E=Sophos;i="4.80,648,1344211200"; d="scan'208";a="15392752"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 15:05:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 16:05:07 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TROza-00067R-OB; Thu, 25 Oct 2012 15:05:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TROza-00014a-Jt;
	Thu, 25 Oct 2012 16:05:06 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20617.21794.506626.237868@mariner.uk.xensource.com>
Date: Thu, 25 Oct 2012 16:05:06 +0100
To: 
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1350688384-2482-2-git-send-email-linux@eikelenboom.it>
References: <1350688384-2482-1-git-send-email-linux@eikelenboom.it>
	<1350688384-2482-2-git-send-email-linux@eikelenboom.it>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian.Jackson@eu.citrix.com, ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/1] xl: Fix accidently waiting for domains
	to	shutdown without --wait option
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

linux@eikelenboom.it writes ("[Xen-devel] [PATCH 1/1] xl: Fix accidently waiting for domains to shutdown without --wait option"):
> From: Sander Eikelenboom 
> 
> Introduced by changeset 26091: "xl: Add --wait and --all to xl reboot."
> 
> Signed-off-by: Sander Eikelenboom 

Acked-by: Ian Jackson 
Committed-by: Ian Jackson 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 15:05:38 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 15:05:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TROzf-0007DX-FK; Thu, 25 Oct 2012 15:05:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TROzd-0007DH-Ez
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 15:05:09 +0000
Received: from [85.158.139.211:25575] by server-12.bemta-5.messagelabs.com id
	89/04-26919-42559805; Thu, 25 Oct 2012 15:05:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1351177507!23251296!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24753 invoked from network); 25 Oct 2012 15:05:08 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 15:05:08 -0000
X-IronPort-AV: E=Sophos;i="4.80,648,1344211200"; d="scan'208";a="15392752"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 15:05:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 16:05:07 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TROza-00067R-OB; Thu, 25 Oct 2012 15:05:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TROza-00014a-Jt;
	Thu, 25 Oct 2012 16:05:06 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20617.21794.506626.237868@mariner.uk.xensource.com>
Date: Thu, 25 Oct 2012 16:05:06 +0100
To: 
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1350688384-2482-2-git-send-email-linux@eikelenboom.it>
References: <1350688384-2482-1-git-send-email-linux@eikelenboom.it>
	<1350688384-2482-2-git-send-email-linux@eikelenboom.it>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian.Jackson@eu.citrix.com, ian.campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/1] xl: Fix accidently waiting for domains
	to	shutdown without --wait option
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

linux@eikelenboom.it writes ("[Xen-devel] [PATCH 1/1] xl: Fix accidently waiting for domains to shutdown without --wait option"):
> From: Sander Eikelenboom 
> 
> Introduced by changeset 26091: "xl: Add --wait and --all to xl reboot."
> 
> Signed-off-by: Sander Eikelenboom 

Acked-by: Ian Jackson 
Committed-by: Ian Jackson 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 15:19:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 15:19:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRPD3-0007Tl-1q; Thu, 25 Oct 2012 15:19:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRPD1-0007Tg-GE
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 15:18:59 +0000
Received: from [85.158.137.99:34493] by server-9.bemta-3.messagelabs.com id
	7A/AD-16841-26859805; Thu, 25 Oct 2012 15:18:58 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-5.tower-217.messagelabs.com!1351178337!18308895!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31663 invoked from network); 25 Oct 2012 15:18:58 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-5.tower-217.messagelabs.com with AES256-SHA encrypted SMTP;
	25 Oct 2012 15:18:58 -0000
Received: from 255-64-ftth.onsneteindhoven.nl ([88.159.64.255]:50901
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TRPEy-0001Zm-Hc; Thu, 25 Oct 2012 17:21:00 +0200
Date: Thu, 25 Oct 2012 17:18:50 +0200
From: Sander Eikelenboom 
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1782427534.20121025171850@eikelenboom.it>
To: Ian Jackson 
In-Reply-To: <20609.10681.742423.773459@mariner.uk.xensource.com>
References: 
	<692244188.20121015123235@eikelenboom.it>
	<1350297477.18058.27.camel@zakaz.uk.xensource.com>
	<751865457.20121015132140@eikelenboom.it>
	<1350301533.18058.35.camel@zakaz.uk.xensource.com>
	<20609.10681.742423.773459@mariner.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl shutdown compatibility with xm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Friday, October 19, 2012, 12:21:45 PM, you wrote:

> Ian Campbell writes ("Re: [PATCH 0 of 5] xl shutdown compatibility with xm"):
>> On Mon, 2012-10-15 at 12:21 +0100, Sander Eikelenboom wrote:
>> >     - On shutdown with xl as toolstack and when the guest doesn't
>> > support pv shutdown, the init.d/xendomains script doesn't even attempt
>> > to shutdown this guest by acpi fallback.
>> >     - As a result when using xl as toolstack, the guest is terminated
>> > non gracefully when the whole machine finally shutsdown, which seems
>> > less desirable then at least *trying* to shut it down gracefully by
>> > using the acpi button.
>> 
>> Using the ACPI fallback is a decision which can only be made locally
>> with full knowledge of the configuration of the guests.

> I'm still with Sander on this, I'm afraid.

> Certainly in the init scripts the default should be to try
>  xl shutdown -F
> and only do destroy if that didn't seem to work.

So Ian, what would your prefer ?

A) only fix the xendomains init script, since it's automated and a administator can not intervene, for manual usage of xl shutdown keep the current behaviour
B) Drop the -F option and let xl shutdown always try the acpi fallback. In this case you can very well turn around IanC's argumentation:
   An administrator who knows that a domain can't be shutdown with either the pv or acpi fallback just shouldn't try to use xl shutdown manually.
   (and if he does probably nothing devastating will happen)
C) Invert the -F option, to NOT try to use the apci fallback

I think option B is acceptable and preferable:
  - It reduces config options
  - Will work out of the box in most cases (for domains without PV drivers), since most of the time the acpi power button event is wired correctly.
  - In most cases nothing devastating will happen when it doesn't work.
  - Only in very special cases, probably setup explicitly, a admin should shutdown the domain by other means, but he has that knowledge in those cases
    and shouldn't use xl shutdown on that domain, and shut the domain down before shutting down the machine (and running the xendomains init script)

--
Sander



> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 15:19:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 15:19:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRPD3-0007Tl-1q; Thu, 25 Oct 2012 15:19:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRPD1-0007Tg-GE
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 15:18:59 +0000
Received: from [85.158.137.99:34493] by server-9.bemta-3.messagelabs.com id
	7A/AD-16841-26859805; Thu, 25 Oct 2012 15:18:58 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-5.tower-217.messagelabs.com!1351178337!18308895!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31663 invoked from network); 25 Oct 2012 15:18:58 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-5.tower-217.messagelabs.com with AES256-SHA encrypted SMTP;
	25 Oct 2012 15:18:58 -0000
Received: from 255-64-ftth.onsneteindhoven.nl ([88.159.64.255]:50901
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TRPEy-0001Zm-Hc; Thu, 25 Oct 2012 17:21:00 +0200
Date: Thu, 25 Oct 2012 17:18:50 +0200
From: Sander Eikelenboom 
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1782427534.20121025171850@eikelenboom.it>
To: Ian Jackson 
In-Reply-To: <20609.10681.742423.773459@mariner.uk.xensource.com>
References: 
	<692244188.20121015123235@eikelenboom.it>
	<1350297477.18058.27.camel@zakaz.uk.xensource.com>
	<751865457.20121015132140@eikelenboom.it>
	<1350301533.18058.35.camel@zakaz.uk.xensource.com>
	<20609.10681.742423.773459@mariner.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl shutdown compatibility with xm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Friday, October 19, 2012, 12:21:45 PM, you wrote:

> Ian Campbell writes ("Re: [PATCH 0 of 5] xl shutdown compatibility with xm"):
>> On Mon, 2012-10-15 at 12:21 +0100, Sander Eikelenboom wrote:
>> >     - On shutdown with xl as toolstack and when the guest doesn't
>> > support pv shutdown, the init.d/xendomains script doesn't even attempt
>> > to shutdown this guest by acpi fallback.
>> >     - As a result when using xl as toolstack, the guest is terminated
>> > non gracefully when the whole machine finally shutsdown, which seems
>> > less desirable then at least *trying* to shut it down gracefully by
>> > using the acpi button.
>> 
>> Using the ACPI fallback is a decision which can only be made locally
>> with full knowledge of the configuration of the guests.

> I'm still with Sander on this, I'm afraid.

> Certainly in the init scripts the default should be to try
>  xl shutdown -F
> and only do destroy if that didn't seem to work.

So Ian, what would your prefer ?

A) only fix the xendomains init script, since it's automated and a administator can not intervene, for manual usage of xl shutdown keep the current behaviour
B) Drop the -F option and let xl shutdown always try the acpi fallback. In this case you can very well turn around IanC's argumentation:
   An administrator who knows that a domain can't be shutdown with either the pv or acpi fallback just shouldn't try to use xl shutdown manually.
   (and if he does probably nothing devastating will happen)
C) Invert the -F option, to NOT try to use the apci fallback

I think option B is acceptable and preferable:
  - It reduces config options
  - Will work out of the box in most cases (for domains without PV drivers), since most of the time the acpi power button event is wired correctly.
  - In most cases nothing devastating will happen when it doesn't work.
  - Only in very special cases, probably setup explicitly, a admin should shutdown the domain by other means, but he has that knowledge in those cases
    and shouldn't use xl shutdown on that domain, and shut the domain down before shutting down the machine (and running the xendomains init script)

--
Sander



> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 15:23:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 15:23:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRPHE-0007dQ-Dm; Thu, 25 Oct 2012 15:23:20 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRPHD-0007dL-AK
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 15:23:19 +0000
Received: from [193.109.254.147:21107] by server-7.bemta-14.messagelabs.com id
	FD/73-24122-66959805; Thu, 25 Oct 2012 15:23:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1351178598!4881883!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19681 invoked from network); 25 Oct 2012 15:23:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 15:23:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,648,1344211200"; d="scan'208";a="15393205"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 15:23:18 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 16:23:18 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TRPHB-0006YV-Rq; Thu, 25 Oct 2012 15:23:17 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TRPHB-00017B-Nm;
	Thu, 25 Oct 2012 16:23:17 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20617.22885.630643.630122@mariner.uk.xensource.com>
Date: Thu, 25 Oct 2012 16:23:17 +0100
To: Sander Eikelenboom 
In-Reply-To: <1782427534.20121025171850@eikelenboom.it>
References: 
	<692244188.20121015123235@eikelenboom.it>
	<1350297477.18058.27.camel@zakaz.uk.xensource.com>
	<751865457.20121015132140@eikelenboom.it>
	<1350301533.18058.35.camel@zakaz.uk.xensource.com>
	<20609.10681.742423.773459@mariner.uk.xensource.com>
	<1782427534.20121025171850@eikelenboom.it>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl shutdown compatibility with xm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Sander Eikelenboom writes ("Re: [PATCH 0 of 5] xl shutdown compatibility with xm"):
> 
> So Ian, what would your prefer ?
> 
> A) only fix the xendomains init script, since it's automated and a administator can not intervene, for manual usage of xl shutdown keep the current behaviour
> B) Drop the -F option and let xl shutdown always try the acpi fallback. In this case you can very well turn around IanC's argumentation:
>    An administrator who knows that a domain can't be shutdown with either the pv or acpi fallback just shouldn't try to use xl shutdown manually.
>    (and if he does probably nothing devastating will happen)
> C) Invert the -F option, to NOT try to use the apci fallback
> 
> I think option B is acceptable and preferable:

I agree with you.  But I think we need to convince Ian C.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 15:23:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 15:23:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRPHE-0007dQ-Dm; Thu, 25 Oct 2012 15:23:20 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRPHD-0007dL-AK
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 15:23:19 +0000
Received: from [193.109.254.147:21107] by server-7.bemta-14.messagelabs.com id
	FD/73-24122-66959805; Thu, 25 Oct 2012 15:23:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1351178598!4881883!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19681 invoked from network); 25 Oct 2012 15:23:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 15:23:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,648,1344211200"; d="scan'208";a="15393205"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 15:23:18 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 16:23:18 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TRPHB-0006YV-Rq; Thu, 25 Oct 2012 15:23:17 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TRPHB-00017B-Nm;
	Thu, 25 Oct 2012 16:23:17 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20617.22885.630643.630122@mariner.uk.xensource.com>
Date: Thu, 25 Oct 2012 16:23:17 +0100
To: Sander Eikelenboom 
In-Reply-To: <1782427534.20121025171850@eikelenboom.it>
References: 
	<692244188.20121015123235@eikelenboom.it>
	<1350297477.18058.27.camel@zakaz.uk.xensource.com>
	<751865457.20121015132140@eikelenboom.it>
	<1350301533.18058.35.camel@zakaz.uk.xensource.com>
	<20609.10681.742423.773459@mariner.uk.xensource.com>
	<1782427534.20121025171850@eikelenboom.it>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl shutdown compatibility with xm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Sander Eikelenboom writes ("Re: [PATCH 0 of 5] xl shutdown compatibility with xm"):
> 
> So Ian, what would your prefer ?
> 
> A) only fix the xendomains init script, since it's automated and a administator can not intervene, for manual usage of xl shutdown keep the current behaviour
> B) Drop the -F option and let xl shutdown always try the acpi fallback. In this case you can very well turn around IanC's argumentation:
>    An administrator who knows that a domain can't be shutdown with either the pv or acpi fallback just shouldn't try to use xl shutdown manually.
>    (and if he does probably nothing devastating will happen)
> C) Invert the -F option, to NOT try to use the apci fallback
> 
> I think option B is acceptable and preferable:

I agree with you.  But I think we need to convince Ian C.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 15:33:28 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 15:33:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRPQg-0007pp-Ew; Thu, 25 Oct 2012 15:33:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRPQe-0007pf-UL
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 15:33:05 +0000
Received: from [85.158.138.51:62049] by server-6.bemta-3.messagelabs.com id
	86/CD-32375-DAB59805; Thu, 25 Oct 2012 15:33:01 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-11.tower-174.messagelabs.com!1351179180!27426580!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17015 invoked from network); 25 Oct 2012 15:33:00 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-11.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	25 Oct 2012 15:33:00 -0000
Received: from 255-64-ftth.onsneteindhoven.nl ([88.159.64.255]:51274
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TRPSa-0001dz-K3; Thu, 25 Oct 2012 17:35:04 +0200
Date: Thu, 25 Oct 2012 17:32:54 +0200
From: Sander Eikelenboom 
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <394587962.20121025173254@eikelenboom.it>
To: Ian Jackson 
In-Reply-To: <20617.22885.630643.630122@mariner.uk.xensource.com>
References: 
	<692244188.20121015123235@eikelenboom.it>
	<1350297477.18058.27.camel@zakaz.uk.xensource.com>
	<751865457.20121015132140@eikelenboom.it>
	<1350301533.18058.35.camel@zakaz.uk.xensource.com>
	<20609.10681.742423.773459@mariner.uk.xensource.com>
	<1782427534.20121025171850@eikelenboom.it>
	<20617.22885.630643.630122@mariner.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl shutdown compatibility with xm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Thursday, October 25, 2012, 5:23:17 PM, you wrote:

> Sander Eikelenboom writes ("Re: [PATCH 0 of 5] xl shutdown compatibility with xm"):
>> 
>> So Ian, what would your prefer ?
>> 
>> A) only fix the xendomains init script, since it's automated and a administator can not intervene, for manual usage of xl shutdown keep the current behaviour
>> B) Drop the -F option and let xl shutdown always try the acpi fallback. In this case you can very well turn around IanC's argumentation:
>>    An administrator who knows that a domain can't be shutdown with either the pv or acpi fallback just shouldn't try to use xl shutdown manually.
>>    (and if he does probably nothing devastating will happen)
>> C) Invert the -F option, to NOT try to use the apci fallback
>> 
>> I think option B is acceptable and preferable:

> I agree with you.  But I think we need to convince Ian C.

Ok I tried with the reasoning above.
I agree with his argumentation that for domains that do not properly shutdown with pv and acpi fallback intervention by a admin was and is required.
But i try to explain that for this special case it doesn't matter if xl shutdown tries to do the acpi fallback automatically, since this admin shouldn't use xl shutdown on this domain anyway.


> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 15:33:28 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 15:33:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRPQg-0007pp-Ew; Thu, 25 Oct 2012 15:33:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRPQe-0007pf-UL
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 15:33:05 +0000
Received: from [85.158.138.51:62049] by server-6.bemta-3.messagelabs.com id
	86/CD-32375-DAB59805; Thu, 25 Oct 2012 15:33:01 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-11.tower-174.messagelabs.com!1351179180!27426580!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17015 invoked from network); 25 Oct 2012 15:33:00 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-11.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	25 Oct 2012 15:33:00 -0000
Received: from 255-64-ftth.onsneteindhoven.nl ([88.159.64.255]:51274
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TRPSa-0001dz-K3; Thu, 25 Oct 2012 17:35:04 +0200
Date: Thu, 25 Oct 2012 17:32:54 +0200
From: Sander Eikelenboom 
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <394587962.20121025173254@eikelenboom.it>
To: Ian Jackson 
In-Reply-To: <20617.22885.630643.630122@mariner.uk.xensource.com>
References: 
	<692244188.20121015123235@eikelenboom.it>
	<1350297477.18058.27.camel@zakaz.uk.xensource.com>
	<751865457.20121015132140@eikelenboom.it>
	<1350301533.18058.35.camel@zakaz.uk.xensource.com>
	<20609.10681.742423.773459@mariner.uk.xensource.com>
	<1782427534.20121025171850@eikelenboom.it>
	<20617.22885.630643.630122@mariner.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl shutdown compatibility with xm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Thursday, October 25, 2012, 5:23:17 PM, you wrote:

> Sander Eikelenboom writes ("Re: [PATCH 0 of 5] xl shutdown compatibility with xm"):
>> 
>> So Ian, what would your prefer ?
>> 
>> A) only fix the xendomains init script, since it's automated and a administator can not intervene, for manual usage of xl shutdown keep the current behaviour
>> B) Drop the -F option and let xl shutdown always try the acpi fallback. In this case you can very well turn around IanC's argumentation:
>>    An administrator who knows that a domain can't be shutdown with either the pv or acpi fallback just shouldn't try to use xl shutdown manually.
>>    (and if he does probably nothing devastating will happen)
>> C) Invert the -F option, to NOT try to use the apci fallback
>> 
>> I think option B is acceptable and preferable:

> I agree with you.  But I think we need to convince Ian C.

Ok I tried with the reasoning above.
I agree with his argumentation that for domains that do not properly shutdown with pv and acpi fallback intervention by a admin was and is required.
But i try to explain that for this special case it doesn't matter if xl shutdown tries to do the acpi fallback automatically, since this admin shouldn't use xl shutdown on this domain anyway.


> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 15:34:47 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 15:34:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRPRy-0007uI-Ts; Thu, 25 Oct 2012 15:34:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRPRx-0007u9-49
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 15:34:25 +0000
Received: from [85.158.139.211:62106] by server-16.bemta-5.messagelabs.com id
	F1/22-04786-00C59805; Thu, 25 Oct 2012 15:34:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1351179263!23776836!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20430 invoked from network); 25 Oct 2012 15:34:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 15:34:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,648,1344211200"; d="scan'208";a="15393486"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 15:34:23 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 25 Oct 2012 16:34:23 +0100
Message-ID: <1351179261.18035.215.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Ian Jackson 
Date: Thu, 25 Oct 2012 16:34:21 +0100
In-Reply-To: <20617.22885.630643.630122@mariner.uk.xensource.com>
References: 
	<692244188.20121015123235@eikelenboom.it>
	<1350297477.18058.27.camel@zakaz.uk.xensource.com>
	<751865457.20121015132140@eikelenboom.it>
	<1350301533.18058.35.camel@zakaz.uk.xensource.com>
	<20609.10681.742423.773459@mariner.uk.xensource.com>
	<1782427534.20121025171850@eikelenboom.it>
	<20617.22885.630643.630122@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Sander Eikelenboom ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl shutdown compatibility with xm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-25 at 16:23 +0100, Ian Jackson wrote:
> Sander Eikelenboom writes ("Re: [PATCH 0 of 5] xl shutdown compatibility with xm"):
> > 
> > So Ian, what would your prefer ?
> > 
> > A) only fix the xendomains init script, since it's automated and a administator can not intervene, for manual usage of xl shutdown keep the current behaviour
> > B) Drop the -F option and let xl shutdown always try the acpi fallback. In this case you can very well turn around IanC's argumentation:
> >    An administrator who knows that a domain can't be shutdown with either the pv or acpi fallback just shouldn't try to use xl shutdown manually.
> >    (and if he does probably nothing devastating will happen)
> > C) Invert the -F option, to NOT try to use the apci fallback
> > 
> > I think option B is acceptable and preferable:
> 
> I agree with you.  But I think we need to convince Ian C.

My main concern is that triggering a hibernation or suspend is, AUIU, a
reasonably common out of the box configuration for some versions of
Windows, which combined with hibernation being (historically at least)
notoriously flakey on real hardware (and I would expect more so on a
virtualised platform) worries me. Also note that we don't actually
implement suspend to RAM -- the domain will quiesce itself and come to a
stop but AFAIK it won't actually die and the domain's RAM won't be saved
anywhere. Presumably this is roughly equivalent to your battery running
out while suspended and therefore not all that dangerous.

But anyway I seem to be in the minority. We can always revert it if it
starts eating peoples data.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 15:34:47 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 15:34:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRPRy-0007uI-Ts; Thu, 25 Oct 2012 15:34:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRPRx-0007u9-49
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 15:34:25 +0000
Received: from [85.158.139.211:62106] by server-16.bemta-5.messagelabs.com id
	F1/22-04786-00C59805; Thu, 25 Oct 2012 15:34:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1351179263!23776836!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20430 invoked from network); 25 Oct 2012 15:34:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 15:34:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,648,1344211200"; d="scan'208";a="15393486"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 15:34:23 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 25 Oct 2012 16:34:23 +0100
Message-ID: <1351179261.18035.215.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Ian Jackson 
Date: Thu, 25 Oct 2012 16:34:21 +0100
In-Reply-To: <20617.22885.630643.630122@mariner.uk.xensource.com>
References: 
	<692244188.20121015123235@eikelenboom.it>
	<1350297477.18058.27.camel@zakaz.uk.xensource.com>
	<751865457.20121015132140@eikelenboom.it>
	<1350301533.18058.35.camel@zakaz.uk.xensource.com>
	<20609.10681.742423.773459@mariner.uk.xensource.com>
	<1782427534.20121025171850@eikelenboom.it>
	<20617.22885.630643.630122@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Sander Eikelenboom ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl shutdown compatibility with xm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-25 at 16:23 +0100, Ian Jackson wrote:
> Sander Eikelenboom writes ("Re: [PATCH 0 of 5] xl shutdown compatibility with xm"):
> > 
> > So Ian, what would your prefer ?
> > 
> > A) only fix the xendomains init script, since it's automated and a administator can not intervene, for manual usage of xl shutdown keep the current behaviour
> > B) Drop the -F option and let xl shutdown always try the acpi fallback. In this case you can very well turn around IanC's argumentation:
> >    An administrator who knows that a domain can't be shutdown with either the pv or acpi fallback just shouldn't try to use xl shutdown manually.
> >    (and if he does probably nothing devastating will happen)
> > C) Invert the -F option, to NOT try to use the apci fallback
> > 
> > I think option B is acceptable and preferable:
> 
> I agree with you.  But I think we need to convince Ian C.

My main concern is that triggering a hibernation or suspend is, AUIU, a
reasonably common out of the box configuration for some versions of
Windows, which combined with hibernation being (historically at least)
notoriously flakey on real hardware (and I would expect more so on a
virtualised platform) worries me. Also note that we don't actually
implement suspend to RAM -- the domain will quiesce itself and come to a
stop but AFAIK it won't actually die and the domain's RAM won't be saved
anywhere. Presumably this is roughly equivalent to your battery running
out while suspended and therefore not all that dangerous.

But anyway I seem to be in the minority. We can always revert it if it
starts eating peoples data.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 15:41:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 15:41:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRPYV-00088d-Pk; Thu, 25 Oct 2012 15:41:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRPYT-00088V-OX
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 15:41:09 +0000
Received: from [85.158.137.99:22172] by server-8.bemta-3.messagelabs.com id
	53/F8-10525-49D59805; Thu, 25 Oct 2012 15:41:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1351179668!17985389!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5059 invoked from network); 25 Oct 2012 15:41:08 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 15:41:08 -0000
X-IronPort-AV: E=Sophos;i="4.80,648,1344211200"; d="scan'208";a="15393634"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 15:41:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 16:41:07 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TRPYR-0006sv-99; Thu, 25 Oct 2012 15:41:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TRPYQ-00019G-Bv;
	Thu, 25 Oct 2012 16:41:06 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20617.23954.274359.877623@mariner.uk.xensource.com>
Date: Thu, 25 Oct 2012 16:41:06 +0100
To: Ian Campbell 
In-Reply-To: <1351179261.18035.215.camel@zakaz.uk.xensource.com>
References: 
	<692244188.20121015123235@eikelenboom.it>
	<1350297477.18058.27.camel@zakaz.uk.xensource.com>
	<751865457.20121015132140@eikelenboom.it>
	<1350301533.18058.35.camel@zakaz.uk.xensource.com>
	<20609.10681.742423.773459@mariner.uk.xensource.com>
	<1782427534.20121025171850@eikelenboom.it>
	<20617.22885.630643.630122@mariner.uk.xensource.com>
	<1351179261.18035.215.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Sander Eikelenboom ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl shutdown compatibility with xm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [PATCH 0 of 5] xl shutdown compatibility with xm"):
> My main concern is that triggering a hibernation or suspend is, AUIU, a
> reasonably common out of the box configuration for some versions of
> Windows, which combined with hibernation being (historically at least)
> notoriously flakey on real hardware (and I would expect more so on a
> virtualised platform) worries me. Also note that we don't actually
> implement suspend to RAM -- the domain will quiesce itself and come to a
> stop but AFAIK it won't actually die and the domain's RAM won't be saved
> anywhere. Presumably this is roughly equivalent to your battery running
> out while suspended and therefore not all that dangerous.

If it triggers a suspend, the domain won't end up shutting down so if
we wait for it there will be no data loss.  If we time out and do a
destroy then doing the suspend first was probably a big improvement.

If it triggers a hibernation, then if the hibernation is broken the
effect will be just as if the user pressed the power button and the
hibernation is broken: the machine will fail to come back and
effectively will have been crashed.  This is probably worse than doing
nothing (in the case where the caller/user isn't going to time out and
do a destroy instead) but it is definitely better than a destroy.

> But anyway I seem to be in the minority. We can always revert it if it
> starts eating peoples data.

OK, I think that's a go-ahead.  Thanks.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 15:41:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 15:41:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRPYV-00088d-Pk; Thu, 25 Oct 2012 15:41:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRPYT-00088V-OX
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 15:41:09 +0000
Received: from [85.158.137.99:22172] by server-8.bemta-3.messagelabs.com id
	53/F8-10525-49D59805; Thu, 25 Oct 2012 15:41:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1351179668!17985389!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5059 invoked from network); 25 Oct 2012 15:41:08 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 15:41:08 -0000
X-IronPort-AV: E=Sophos;i="4.80,648,1344211200"; d="scan'208";a="15393634"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 15:41:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 16:41:07 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TRPYR-0006sv-99; Thu, 25 Oct 2012 15:41:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TRPYQ-00019G-Bv;
	Thu, 25 Oct 2012 16:41:06 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20617.23954.274359.877623@mariner.uk.xensource.com>
Date: Thu, 25 Oct 2012 16:41:06 +0100
To: Ian Campbell 
In-Reply-To: <1351179261.18035.215.camel@zakaz.uk.xensource.com>
References: 
	<692244188.20121015123235@eikelenboom.it>
	<1350297477.18058.27.camel@zakaz.uk.xensource.com>
	<751865457.20121015132140@eikelenboom.it>
	<1350301533.18058.35.camel@zakaz.uk.xensource.com>
	<20609.10681.742423.773459@mariner.uk.xensource.com>
	<1782427534.20121025171850@eikelenboom.it>
	<20617.22885.630643.630122@mariner.uk.xensource.com>
	<1351179261.18035.215.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Sander Eikelenboom ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl shutdown compatibility with xm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [PATCH 0 of 5] xl shutdown compatibility with xm"):
> My main concern is that triggering a hibernation or suspend is, AUIU, a
> reasonably common out of the box configuration for some versions of
> Windows, which combined with hibernation being (historically at least)
> notoriously flakey on real hardware (and I would expect more so on a
> virtualised platform) worries me. Also note that we don't actually
> implement suspend to RAM -- the domain will quiesce itself and come to a
> stop but AFAIK it won't actually die and the domain's RAM won't be saved
> anywhere. Presumably this is roughly equivalent to your battery running
> out while suspended and therefore not all that dangerous.

If it triggers a suspend, the domain won't end up shutting down so if
we wait for it there will be no data loss.  If we time out and do a
destroy then doing the suspend first was probably a big improvement.

If it triggers a hibernation, then if the hibernation is broken the
effect will be just as if the user pressed the power button and the
hibernation is broken: the machine will fail to come back and
effectively will have been crashed.  This is probably worse than doing
nothing (in the case where the caller/user isn't going to time out and
do a destroy instead) but it is definitely better than a destroy.

> But anyway I seem to be in the minority. We can always revert it if it
> starts eating peoples data.

OK, I think that's a go-ahead.  Thanks.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 15:48:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 15:48:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRPev-0008Hv-N4; Thu, 25 Oct 2012 15:47:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRPeu-0008Hq-Dd
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 15:47:48 +0000
Received: from [85.158.139.83:32506] by server-14.bemta-5.messagelabs.com id
	D9/E6-21768-32F59805; Thu, 25 Oct 2012 15:47:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1351180066!16329255!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25180 invoked from network); 25 Oct 2012 15:47:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 15:47:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,648,1344211200"; d="scan'208";a="15393833"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 15:47:30 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 25 Oct 2012 16:47:30 +0100
Message-ID: <1351180049.18035.219.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Sander Eikelenboom 
Date: Thu, 25 Oct 2012 16:47:29 +0100
In-Reply-To: <394587962.20121025173254@eikelenboom.it>
References: 
	<692244188.20121015123235@eikelenboom.it>
	<1350297477.18058.27.camel@zakaz.uk.xensource.com>
	<751865457.20121015132140@eikelenboom.it>
	<1350301533.18058.35.camel@zakaz.uk.xensource.com>
	<20609.10681.742423.773459@mariner.uk.xensource.com>
	<1782427534.20121025171850@eikelenboom.it>
	<20617.22885.630643.630122@mariner.uk.xensource.com>
	<394587962.20121025173254@eikelenboom.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl shutdown compatibility with xm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-25 at 16:32 +0100, Sander Eikelenboom wrote:
> Thursday, October 25, 2012, 5:23:17 PM, you wrote:
> 
> > Sander Eikelenboom writes ("Re: [PATCH 0 of 5] xl shutdown compatibility with xm"):
> >> 
> >> So Ian, what would your prefer ?
> >> 
> >> A) only fix the xendomains init script, since it's automated and a administator can not intervene, for manual usage of xl shutdown keep the current behaviour
> >> B) Drop the -F option and let xl shutdown always try the acpi fallback. In this case you can very well turn around IanC's argumentation:
> >>    An administrator who knows that a domain can't be shutdown with either the pv or acpi fallback just shouldn't try to use xl shutdown manually.
> >>    (and if he does probably nothing devastating will happen)
> >> C) Invert the -F option, to NOT try to use the apci fallback
> >> 
> >> I think option B is acceptable and preferable:
> 
> > I agree with you.  But I think we need to convince Ian C.
> 
> Ok I tried with the reasoning above.

> I agree with his argumentation that for domains that do not properly
> shutdown with pv and acpi fallback intervention by a admin was and is
> required.

ACPI fallback != shutdown. It might just as likely be a hibernate or
(more likely) a reboot.

Are we going to add code to xl which forces on_reboot = destroy when xl
shutdown -F is invoked on a domain?

> But i try to explain that for this special case it doesn't matter if
> xl shutdown tries to do the acpi fallback automatically, since this
> admin shouldn't use xl shutdown on this domain anyway.

Whether they should or not the xendomains script is going to magically
do it for them.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 15:48:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 15:48:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRPev-0008Hv-N4; Thu, 25 Oct 2012 15:47:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRPeu-0008Hq-Dd
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 15:47:48 +0000
Received: from [85.158.139.83:32506] by server-14.bemta-5.messagelabs.com id
	D9/E6-21768-32F59805; Thu, 25 Oct 2012 15:47:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1351180066!16329255!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25180 invoked from network); 25 Oct 2012 15:47:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 15:47:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,648,1344211200"; d="scan'208";a="15393833"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 15:47:30 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 25 Oct 2012 16:47:30 +0100
Message-ID: <1351180049.18035.219.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Sander Eikelenboom 
Date: Thu, 25 Oct 2012 16:47:29 +0100
In-Reply-To: <394587962.20121025173254@eikelenboom.it>
References: 
	<692244188.20121015123235@eikelenboom.it>
	<1350297477.18058.27.camel@zakaz.uk.xensource.com>
	<751865457.20121015132140@eikelenboom.it>
	<1350301533.18058.35.camel@zakaz.uk.xensource.com>
	<20609.10681.742423.773459@mariner.uk.xensource.com>
	<1782427534.20121025171850@eikelenboom.it>
	<20617.22885.630643.630122@mariner.uk.xensource.com>
	<394587962.20121025173254@eikelenboom.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl shutdown compatibility with xm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-25 at 16:32 +0100, Sander Eikelenboom wrote:
> Thursday, October 25, 2012, 5:23:17 PM, you wrote:
> 
> > Sander Eikelenboom writes ("Re: [PATCH 0 of 5] xl shutdown compatibility with xm"):
> >> 
> >> So Ian, what would your prefer ?
> >> 
> >> A) only fix the xendomains init script, since it's automated and a administator can not intervene, for manual usage of xl shutdown keep the current behaviour
> >> B) Drop the -F option and let xl shutdown always try the acpi fallback. In this case you can very well turn around IanC's argumentation:
> >>    An administrator who knows that a domain can't be shutdown with either the pv or acpi fallback just shouldn't try to use xl shutdown manually.
> >>    (and if he does probably nothing devastating will happen)
> >> C) Invert the -F option, to NOT try to use the apci fallback
> >> 
> >> I think option B is acceptable and preferable:
> 
> > I agree with you.  But I think we need to convince Ian C.
> 
> Ok I tried with the reasoning above.

> I agree with his argumentation that for domains that do not properly
> shutdown with pv and acpi fallback intervention by a admin was and is
> required.

ACPI fallback != shutdown. It might just as likely be a hibernate or
(more likely) a reboot.

Are we going to add code to xl which forces on_reboot = destroy when xl
shutdown -F is invoked on a domain?

> But i try to explain that for this special case it doesn't matter if
> xl shutdown tries to do the acpi fallback automatically, since this
> admin shouldn't use xl shutdown on this domain anyway.

Whether they should or not the xendomains script is going to magically
do it for them.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 15:56:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 15:56:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRPmu-0008R6-Mg; Thu, 25 Oct 2012 15:56:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRPms-0008R1-N0
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 15:56:02 +0000
Received: from [85.158.139.211:65094] by server-14.bemta-5.messagelabs.com id
	13/8A-21768-11169805; Thu, 25 Oct 2012 15:56:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1351180561!22218401!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6343 invoked from network); 25 Oct 2012 15:56:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 15:56:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,648,1344211200"; d="scan'208";a="15394072"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 15:56:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 16:56:01 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TRPmq-000765-RF; Thu, 25 Oct 2012 15:56:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TRPmq-0001At-NL;
	Thu, 25 Oct 2012 16:56:00 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20617.24848.614667.919081@mariner.uk.xensource.com>
Date: Thu, 25 Oct 2012 16:56:00 +0100
To: Ian Campbell 
In-Reply-To: <1351180049.18035.219.camel@zakaz.uk.xensource.com>
References: 
	<692244188.20121015123235@eikelenboom.it>
	<1350297477.18058.27.camel@zakaz.uk.xensource.com>
	<751865457.20121015132140@eikelenboom.it>
	<1350301533.18058.35.camel@zakaz.uk.xensource.com>
	<20609.10681.742423.773459@mariner.uk.xensource.com>
	<1782427534.20121025171850@eikelenboom.it>
	<20617.22885.630643.630122@mariner.uk.xensource.com>
	<394587962.20121025173254@eikelenboom.it>
	<1351180049.18035.219.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Sander Eikelenboom ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl shutdown compatibility with xm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [PATCH 0 of 5] xl shutdown compatibility with xm"):
> ACPI fallback != shutdown. It might just as likely be a hibernate or
> (more likely) a reboot.
> 
> Are we going to add code to xl which forces on_reboot = destroy when xl
> shutdown -F is invoked on a domain?

We might need to do something along those lines.

> > But i try to explain that for this special case it doesn't matter if
> > xl shutdown tries to do the acpi fallback automatically, since this
> > admin shouldn't use xl shutdown on this domain anyway.
> 
> Whether they should or not the xendomains script is going to magically
> do it for them.

Well, at the moment the xendomains script will try "xl shutdown" and
if that fails the guest will be shot in the head.  Trying the acpi
fallback is surely better?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 15:56:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 15:56:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRPmu-0008R6-Mg; Thu, 25 Oct 2012 15:56:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRPms-0008R1-N0
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 15:56:02 +0000
Received: from [85.158.139.211:65094] by server-14.bemta-5.messagelabs.com id
	13/8A-21768-11169805; Thu, 25 Oct 2012 15:56:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1351180561!22218401!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6343 invoked from network); 25 Oct 2012 15:56:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 15:56:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,648,1344211200"; d="scan'208";a="15394072"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 15:56:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 16:56:01 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TRPmq-000765-RF; Thu, 25 Oct 2012 15:56:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TRPmq-0001At-NL;
	Thu, 25 Oct 2012 16:56:00 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20617.24848.614667.919081@mariner.uk.xensource.com>
Date: Thu, 25 Oct 2012 16:56:00 +0100
To: Ian Campbell 
In-Reply-To: <1351180049.18035.219.camel@zakaz.uk.xensource.com>
References: 
	<692244188.20121015123235@eikelenboom.it>
	<1350297477.18058.27.camel@zakaz.uk.xensource.com>
	<751865457.20121015132140@eikelenboom.it>
	<1350301533.18058.35.camel@zakaz.uk.xensource.com>
	<20609.10681.742423.773459@mariner.uk.xensource.com>
	<1782427534.20121025171850@eikelenboom.it>
	<20617.22885.630643.630122@mariner.uk.xensource.com>
	<394587962.20121025173254@eikelenboom.it>
	<1351180049.18035.219.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Sander Eikelenboom ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl shutdown compatibility with xm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [PATCH 0 of 5] xl shutdown compatibility with xm"):
> ACPI fallback != shutdown. It might just as likely be a hibernate or
> (more likely) a reboot.
> 
> Are we going to add code to xl which forces on_reboot = destroy when xl
> shutdown -F is invoked on a domain?

We might need to do something along those lines.

> > But i try to explain that for this special case it doesn't matter if
> > xl shutdown tries to do the acpi fallback automatically, since this
> > admin shouldn't use xl shutdown on this domain anyway.
> 
> Whether they should or not the xendomains script is going to magically
> do it for them.

Well, at the moment the xendomains script will try "xl shutdown" and
if that fails the guest will be shot in the head.  Trying the acpi
fallback is surely better?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 15:57:12 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 15:57:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRPnk-0008Tz-4E; Thu, 25 Oct 2012 15:56:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRPni-0008Tm-3q
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 15:56:54 +0000
Received: from [85.158.143.35:59338] by server-3.bemta-4.messagelabs.com id
	F8/47-24279-54169805; Thu, 25 Oct 2012 15:56:53 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-16.tower-21.messagelabs.com!1351180555!13197649!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11794 invoked from network); 25 Oct 2012 15:55:56 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-16.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	25 Oct 2012 15:55:56 -0000
Received: from 255-64-ftth.onsneteindhoven.nl ([88.159.64.255]:51627
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TRPol-0001kl-Cc; Thu, 25 Oct 2012 17:57:59 +0200
Date: Thu, 25 Oct 2012 17:55:49 +0200
From: Sander Eikelenboom 
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <382575208.20121025175549@eikelenboom.it>
To: Ian Campbell 
In-Reply-To: <1351180049.18035.219.camel@zakaz.uk.xensource.com>
References: 
	<692244188.20121015123235@eikelenboom.it>
	<1350297477.18058.27.camel@zakaz.uk.xensource.com>
	<751865457.20121015132140@eikelenboom.it>
	<1350301533.18058.35.camel@zakaz.uk.xensource.com>
	<20609.10681.742423.773459@mariner.uk.xensource.com>
	<1782427534.20121025171850@eikelenboom.it>
	<20617.22885.630643.630122@mariner.uk.xensource.com>
	<394587962.20121025173254@eikelenboom.it>
	<1351180049.18035.219.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl shutdown compatibility with xm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Thursday, October 25, 2012, 5:47:29 PM, you wrote:

> On Thu, 2012-10-25 at 16:32 +0100, Sander Eikelenboom wrote:
>> Thursday, October 25, 2012, 5:23:17 PM, you wrote:
>> 
>> > Sander Eikelenboom writes ("Re: [PATCH 0 of 5] xl shutdown compatibility with xm"):
>> >> 
>> >> So Ian, what would your prefer ?
>> >> 
>> >> A) only fix the xendomains init script, since it's automated and a administator can not intervene, for manual usage of xl shutdown keep the current behaviour
>> >> B) Drop the -F option and let xl shutdown always try the acpi fallback. In this case you can very well turn around IanC's argumentation:
>> >>    An administrator who knows that a domain can't be shutdown with either the pv or acpi fallback just shouldn't try to use xl shutdown manually.
>> >>    (and if he does probably nothing devastating will happen)
>> >> C) Invert the -F option, to NOT try to use the apci fallback
>> >> 
>> >> I think option B is acceptable and preferable:
>> 
>> > I agree with you.  But I think we need to convince Ian C.
>> 
>> Ok I tried with the reasoning above.

>> I agree with his argumentation that for domains that do not properly
>> shutdown with pv and acpi fallback intervention by a admin was and is
>> required.

> ACPI fallback != shutdown. It might just as likely be a hibernate or
> (more likely) a reboot.

> Are we going to add code to xl which forces on_reboot = destroy when xl
> shutdown -F is invoked on a domain?

If you don't want your guests to be shutdown, you would presumably use save and restore instead of shutdown for the xendomains init scripts ?


>> But i try to explain that for this special case it doesn't matter if
>> xl shutdown tries to do the acpi fallback automatically, since this
>> admin shouldn't use xl shutdown on this domain anyway.

> Whether they should or not the xendomains script is going to magically
> do it for them.

Well at the moment the xl shutdown fails, the script continues and the hardware shutdown.
So the guest is also destroyed in the end anyhow.

So if a admin has a special guest that doesn't properly shutdown on either pv or acpi he should shut it down manually before invoking the xendomains init script.
That's the case at present (without the change) and would be the future case (when changing to try the fallback).


> Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 15:57:12 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 15:57:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRPnk-0008Tz-4E; Thu, 25 Oct 2012 15:56:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRPni-0008Tm-3q
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 15:56:54 +0000
Received: from [85.158.143.35:59338] by server-3.bemta-4.messagelabs.com id
	F8/47-24279-54169805; Thu, 25 Oct 2012 15:56:53 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-16.tower-21.messagelabs.com!1351180555!13197649!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11794 invoked from network); 25 Oct 2012 15:55:56 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-16.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	25 Oct 2012 15:55:56 -0000
Received: from 255-64-ftth.onsneteindhoven.nl ([88.159.64.255]:51627
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TRPol-0001kl-Cc; Thu, 25 Oct 2012 17:57:59 +0200
Date: Thu, 25 Oct 2012 17:55:49 +0200
From: Sander Eikelenboom 
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <382575208.20121025175549@eikelenboom.it>
To: Ian Campbell 
In-Reply-To: <1351180049.18035.219.camel@zakaz.uk.xensource.com>
References: 
	<692244188.20121015123235@eikelenboom.it>
	<1350297477.18058.27.camel@zakaz.uk.xensource.com>
	<751865457.20121015132140@eikelenboom.it>
	<1350301533.18058.35.camel@zakaz.uk.xensource.com>
	<20609.10681.742423.773459@mariner.uk.xensource.com>
	<1782427534.20121025171850@eikelenboom.it>
	<20617.22885.630643.630122@mariner.uk.xensource.com>
	<394587962.20121025173254@eikelenboom.it>
	<1351180049.18035.219.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl shutdown compatibility with xm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Thursday, October 25, 2012, 5:47:29 PM, you wrote:

> On Thu, 2012-10-25 at 16:32 +0100, Sander Eikelenboom wrote:
>> Thursday, October 25, 2012, 5:23:17 PM, you wrote:
>> 
>> > Sander Eikelenboom writes ("Re: [PATCH 0 of 5] xl shutdown compatibility with xm"):
>> >> 
>> >> So Ian, what would your prefer ?
>> >> 
>> >> A) only fix the xendomains init script, since it's automated and a administator can not intervene, for manual usage of xl shutdown keep the current behaviour
>> >> B) Drop the -F option and let xl shutdown always try the acpi fallback. In this case you can very well turn around IanC's argumentation:
>> >>    An administrator who knows that a domain can't be shutdown with either the pv or acpi fallback just shouldn't try to use xl shutdown manually.
>> >>    (and if he does probably nothing devastating will happen)
>> >> C) Invert the -F option, to NOT try to use the apci fallback
>> >> 
>> >> I think option B is acceptable and preferable:
>> 
>> > I agree with you.  But I think we need to convince Ian C.
>> 
>> Ok I tried with the reasoning above.

>> I agree with his argumentation that for domains that do not properly
>> shutdown with pv and acpi fallback intervention by a admin was and is
>> required.

> ACPI fallback != shutdown. It might just as likely be a hibernate or
> (more likely) a reboot.

> Are we going to add code to xl which forces on_reboot = destroy when xl
> shutdown -F is invoked on a domain?

If you don't want your guests to be shutdown, you would presumably use save and restore instead of shutdown for the xendomains init scripts ?


>> But i try to explain that for this special case it doesn't matter if
>> xl shutdown tries to do the acpi fallback automatically, since this
>> admin shouldn't use xl shutdown on this domain anyway.

> Whether they should or not the xendomains script is going to magically
> do it for them.

Well at the moment the xl shutdown fails, the script continues and the hardware shutdown.
So the guest is also destroyed in the end anyhow.

So if a admin has a special guest that doesn't properly shutdown on either pv or acpi he should shut it down manually before invoking the xendomains init script.
That's the case at present (without the change) and would be the future case (when changing to try the fallback).


> Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 16:02:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 16:02:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRPsx-0000hP-1B; Thu, 25 Oct 2012 16:02:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRPsv-0000hJ-Tr
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 16:02:18 +0000
Received: from [85.158.143.35:23434] by server-2.bemta-4.messagelabs.com id
	37/F4-22268-98269805; Thu, 25 Oct 2012 16:02:17 +0000
X-Env-Sender: Aurelien.MILLIAT@clarte.asso.fr
X-Msg-Ref: server-9.tower-21.messagelabs.com!1351180889!4696746!1
X-Originating-IP: [194.3.193.29]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17151 invoked from network); 25 Oct 2012 16:01:29 -0000
Received: from ns3.ingenierium.com (HELO Dulac.clarte.asso.fr) (194.3.193.29)
	by server-9.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Oct 2012 16:01:29 -0000
Received: from dulac.ingenierium.com ([192.168.59.1]) by dulac
	([192.168.59.1]) with mapi id 14.01.0289.001;
	Thu, 25 Oct 2012 18:01:28 +0200
From: =?iso-8859-1?Q?Aur=E9lien_MILLIAT?= 
To: "xen-devel@lists.xen.org" 
Thread-Topic: [Xen-devel] ATI VGA passthrough and S400 Synchronization module
Thread-Index: Ac1ps8zkCPzyeRZ3RWeWIDwxqaix/gFrW5YABEg0R6AAKGBEAAAGx1yADF6AhaA=
Date: Thu, 25 Oct 2012 16:01:27 +0000
Message-ID: <36774CA35642C143BCDE93BA0C68DC5702C10094@dulac>
References: <36774CA35642C143BCDE93BA0C68DC5702C0AE46@dulac>
	<20120731231246.GD32698@phenom.dumpdata.com>
	<36774CA35642C143BCDE93BA0C68DC5702C0C852@dulac>
	<20120823133635.GA10700@phenom.dumpdata.com> 
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.54.111]
x-avast-antispam: clean, score=0
x-original-content-type: application/ms-tnef
MIME-Version: 1.0
Subject: Re: [Xen-devel] ATI VGA passthrough and S400 Synchronization module
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>On Wed, Aug 22, 2012 at 04:23:02PM +0000, Aur=E9lien MILLIAT wrote:
>> On Tue, Jul 24, 2012 at 04:05:20PM +0000, Aur=E9lien MILLIAT wrote:
>> > Hi,
>> > =

>> > I'm currently trying to use XEN on graphical cluster.
>> > VGA passtrough works fine and I'm able to use quad-buffer for active s=
tereo.
>> > The last thing to do is to synchronize all GPU from the cluster.
>> > For this purpose I use ATI FirePro S400 and it didn't works.
>> > =

>> > I've seen two behaviors:
>> > -When I run lspci command on Dom0 I've got:
>> > 0f:00.0 VGA compatible controller: ATI Technologies Inc Device 6888
>> > 0f:00.1 Audio device: ATI Technologies Inc Cypress HDMI Audio =

>> > [Radeon HD 5800 Series] And sometimes just
>> > 0f:00.0 VGA compatible controller: ATI Technologies Inc Device 6888 =

>> > -When a DomU(Windows 7) is running, it's very slow (I can't do anythin=
g) and crash after several minutes.
>> > I've tried with the unstable version and I've seen the same 'lspci' be=
havior.
>> > =

>> > I've a couple of questions:
>> > Is it possible to passthrough a VGA with this extension?
>> =

>> I never tried. I just pass in the VGA card and don't try to pass in the =
HDMI driver.
>> =

>> > As it's a particular use of VGA passtrough is it planned to able to us=
e synchronization module?
>> =

>> So what is synchronization module for you? That is the HDMI part?
>> =

>> > Is it easy to add this feature (time cost)?
>> > =

>> > Computers : HP Z800 workstation
>> > GPU: ATI FirePro V8800
>> > CPU: Intel Xeon E5640
>> > MB: Intel 5520 chipset
>> > =

>> > XEN :
>> > Version  4.1.2
>> > With ATI patch from
>> > http://old-list-archives.xen.org/archives/html/xen-users/2011-05/msg
>> > 00048.html
>> > Thanks,
>> > Aur=E9lien Milliat
>> > =

>> Hi,
>> =

>> I've been able to use ATI FirePro S400 with the unstable version. I've u=
pdated my Dom0 and pass the graphic card as secondary adaptor.
>>
>>
>>Please do not top post.
>Sorry !
>>
>> What did you upgrade dom0 to?
>>
>
>I've update Debian 6.0.4 to 6.0.5, update all packages and remove everythi=
ng I've made from my previous test. =

>
>I've continue my tests and I've got an issue with active stereo. Previousl=
y, I've got tested active stereo with the stable release.  =

>
>On unstable version, only the right eye is render (OGLplane and Virtools d=
emos).
>Quad buffer is on, everything seems to be setup as usual for active stereo=
. =

>I've tried with and without the S400 card.
>
>I will try to gather more informations about this.
>
>>
>> I've made a quick test for Xen 4.1.2 with these updates but it's still c=
rash (no matter I will use the unstable version).
>>
>> Aur=E9lien
>> =

Hi,

I've got the time to run some test to find what's going on with the active =
stereo with the following configuration:

release                : 2.6.32-5-xen-amd64
version                : #1 SMP Sun May 6 08:57:29 UTC 2012
machine                : x86_64
nr_cpus                : 8
nr_nodes               : 1
cores_per_socket       : 4
threads_per_core       : 2
cpu_mhz                : 2660
hw_caps                : bfebfbff:2c100800:00000000:00003f40:029ee3ff:00000=
000:00000001:00000000
virt_caps              : hvm hvm_directio
total_memory           : 4079
free_cpus              : 0
xen_major              : 4
xen_minor              : 2
xen_extra              : -unstable
xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-=
3.0-x86_32p hvm-3.0-x86_64 =

xen_scheduler          : credit
xen_pagesize           : 4096
platform_params        : virt_start=3D0xffff800000000000
xen_changeset          : Sun Jul 22 16:37:25 2012 +0100 25622:3c426da4788e
xen_commandline        : placeholder
cc_compiler            : gcc version 4.4.5 (Debian 4.4.5-8) =

xend_config_format     : 4

I've tested with:
-XP SP2 and SP3 32bits (Pro): =

	+ Driver (version: 2012.07.11): active stereo (quadbuffer) enable, S400 fo=
und.
	+ OGLplane: Impossible to run active stereo mode: "OpenGL stereo not suppo=
rted".

-Windows 7 32 bits (Pro):
	+ Driver (version: 2012.07.11): active stereo enable, S400 found.
	+ OGLplane: run without sync signal and render only one eye.

-Windows 8 64bits (debug checked build):
	+ Driver (version: 2012.07.11): active stereo enable, S400 found.
	+ OGLplane: active stereo seems to be ok.

I will run some tests with the same configuration:
-Windows 7 64 bits (Pro)
-Windows 8 64bits (Final)
-Windows 8 32bits (Final)

I've made a quick test on Xen 4.2.0-rc2 with a compiled kernel from:
http://wiki.xen.org/wiki/Mainline_Linux_Kernel_Configs
Windows 7 has the same behavior and I haven't tried other OS.

Does anyone have run tests for active stereo with VGA passthrough?

Thanks,
Aur=E9lien
>> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> =

> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> =


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 16:02:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 16:02:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRPsx-0000hP-1B; Thu, 25 Oct 2012 16:02:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRPsv-0000hJ-Tr
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 16:02:18 +0000
Received: from [85.158.143.35:23434] by server-2.bemta-4.messagelabs.com id
	37/F4-22268-98269805; Thu, 25 Oct 2012 16:02:17 +0000
X-Env-Sender: Aurelien.MILLIAT@clarte.asso.fr
X-Msg-Ref: server-9.tower-21.messagelabs.com!1351180889!4696746!1
X-Originating-IP: [194.3.193.29]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17151 invoked from network); 25 Oct 2012 16:01:29 -0000
Received: from ns3.ingenierium.com (HELO Dulac.clarte.asso.fr) (194.3.193.29)
	by server-9.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Oct 2012 16:01:29 -0000
Received: from dulac.ingenierium.com ([192.168.59.1]) by dulac
	([192.168.59.1]) with mapi id 14.01.0289.001;
	Thu, 25 Oct 2012 18:01:28 +0200
From: =?iso-8859-1?Q?Aur=E9lien_MILLIAT?= 
To: "xen-devel@lists.xen.org" 
Thread-Topic: [Xen-devel] ATI VGA passthrough and S400 Synchronization module
Thread-Index: Ac1ps8zkCPzyeRZ3RWeWIDwxqaix/gFrW5YABEg0R6AAKGBEAAAGx1yADF6AhaA=
Date: Thu, 25 Oct 2012 16:01:27 +0000
Message-ID: <36774CA35642C143BCDE93BA0C68DC5702C10094@dulac>
References: <36774CA35642C143BCDE93BA0C68DC5702C0AE46@dulac>
	<20120731231246.GD32698@phenom.dumpdata.com>
	<36774CA35642C143BCDE93BA0C68DC5702C0C852@dulac>
	<20120823133635.GA10700@phenom.dumpdata.com> 
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.54.111]
x-avast-antispam: clean, score=0
x-original-content-type: application/ms-tnef
MIME-Version: 1.0
Subject: Re: [Xen-devel] ATI VGA passthrough and S400 Synchronization module
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>On Wed, Aug 22, 2012 at 04:23:02PM +0000, Aur=E9lien MILLIAT wrote:
>> On Tue, Jul 24, 2012 at 04:05:20PM +0000, Aur=E9lien MILLIAT wrote:
>> > Hi,
>> > =

>> > I'm currently trying to use XEN on graphical cluster.
>> > VGA passtrough works fine and I'm able to use quad-buffer for active s=
tereo.
>> > The last thing to do is to synchronize all GPU from the cluster.
>> > For this purpose I use ATI FirePro S400 and it didn't works.
>> > =

>> > I've seen two behaviors:
>> > -When I run lspci command on Dom0 I've got:
>> > 0f:00.0 VGA compatible controller: ATI Technologies Inc Device 6888
>> > 0f:00.1 Audio device: ATI Technologies Inc Cypress HDMI Audio =

>> > [Radeon HD 5800 Series] And sometimes just
>> > 0f:00.0 VGA compatible controller: ATI Technologies Inc Device 6888 =

>> > -When a DomU(Windows 7) is running, it's very slow (I can't do anythin=
g) and crash after several minutes.
>> > I've tried with the unstable version and I've seen the same 'lspci' be=
havior.
>> > =

>> > I've a couple of questions:
>> > Is it possible to passthrough a VGA with this extension?
>> =

>> I never tried. I just pass in the VGA card and don't try to pass in the =
HDMI driver.
>> =

>> > As it's a particular use of VGA passtrough is it planned to able to us=
e synchronization module?
>> =

>> So what is synchronization module for you? That is the HDMI part?
>> =

>> > Is it easy to add this feature (time cost)?
>> > =

>> > Computers : HP Z800 workstation
>> > GPU: ATI FirePro V8800
>> > CPU: Intel Xeon E5640
>> > MB: Intel 5520 chipset
>> > =

>> > XEN :
>> > Version  4.1.2
>> > With ATI patch from
>> > http://old-list-archives.xen.org/archives/html/xen-users/2011-05/msg
>> > 00048.html
>> > Thanks,
>> > Aur=E9lien Milliat
>> > =

>> Hi,
>> =

>> I've been able to use ATI FirePro S400 with the unstable version. I've u=
pdated my Dom0 and pass the graphic card as secondary adaptor.
>>
>>
>>Please do not top post.
>Sorry !
>>
>> What did you upgrade dom0 to?
>>
>
>I've update Debian 6.0.4 to 6.0.5, update all packages and remove everythi=
ng I've made from my previous test. =

>
>I've continue my tests and I've got an issue with active stereo. Previousl=
y, I've got tested active stereo with the stable release.  =

>
>On unstable version, only the right eye is render (OGLplane and Virtools d=
emos).
>Quad buffer is on, everything seems to be setup as usual for active stereo=
. =

>I've tried with and without the S400 card.
>
>I will try to gather more informations about this.
>
>>
>> I've made a quick test for Xen 4.1.2 with these updates but it's still c=
rash (no matter I will use the unstable version).
>>
>> Aur=E9lien
>> =

Hi,

I've got the time to run some test to find what's going on with the active =
stereo with the following configuration:

release                : 2.6.32-5-xen-amd64
version                : #1 SMP Sun May 6 08:57:29 UTC 2012
machine                : x86_64
nr_cpus                : 8
nr_nodes               : 1
cores_per_socket       : 4
threads_per_core       : 2
cpu_mhz                : 2660
hw_caps                : bfebfbff:2c100800:00000000:00003f40:029ee3ff:00000=
000:00000001:00000000
virt_caps              : hvm hvm_directio
total_memory           : 4079
free_cpus              : 0
xen_major              : 4
xen_minor              : 2
xen_extra              : -unstable
xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-=
3.0-x86_32p hvm-3.0-x86_64 =

xen_scheduler          : credit
xen_pagesize           : 4096
platform_params        : virt_start=3D0xffff800000000000
xen_changeset          : Sun Jul 22 16:37:25 2012 +0100 25622:3c426da4788e
xen_commandline        : placeholder
cc_compiler            : gcc version 4.4.5 (Debian 4.4.5-8) =

xend_config_format     : 4

I've tested with:
-XP SP2 and SP3 32bits (Pro): =

	+ Driver (version: 2012.07.11): active stereo (quadbuffer) enable, S400 fo=
und.
	+ OGLplane: Impossible to run active stereo mode: "OpenGL stereo not suppo=
rted".

-Windows 7 32 bits (Pro):
	+ Driver (version: 2012.07.11): active stereo enable, S400 found.
	+ OGLplane: run without sync signal and render only one eye.

-Windows 8 64bits (debug checked build):
	+ Driver (version: 2012.07.11): active stereo enable, S400 found.
	+ OGLplane: active stereo seems to be ok.

I will run some tests with the same configuration:
-Windows 7 64 bits (Pro)
-Windows 8 64bits (Final)
-Windows 8 32bits (Final)

I've made a quick test on Xen 4.2.0-rc2 with a compiled kernel from:
http://wiki.xen.org/wiki/Mainline_Linux_Kernel_Configs
Windows 7 has the same behavior and I haven't tried other OS.

Does anyone have run tests for active stereo with VGA passthrough?

Thanks,
Aur=E9lien
>> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> =

> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> =


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 16:05:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 16:05:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRPva-0000pb-9Z; Thu, 25 Oct 2012 16:05:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRPvY-0000pU-6s
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 16:05:00 +0000
Received: from [85.158.139.211:18661] by server-4.bemta-5.messagelabs.com id
	67/93-01455-B2369805; Thu, 25 Oct 2012 16:04:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1351181098!22219738!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7697 invoked from network); 25 Oct 2012 16:04:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 16:04:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,648,1344211200"; d="scan'208";a="15394360"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 16:04:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 17:04:58 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TRPvW-0007GB-Cj; Thu, 25 Oct 2012 16:04:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TRPvW-0001CD-93;
	Thu, 25 Oct 2012 17:04:58 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20617.25386.174306.720784@mariner.uk.xensource.com>
Date: Thu, 25 Oct 2012 17:04:58 +0100
To: Ian Campbell ,
	"xen-devel@lists.xen.org" 
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20609.12641.710380.815515@mariner.uk.xensource.com>
References: 
	<20609.12641.710380.815515@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [PATCH] xl: Do not leak events when a domain exits
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson writes ("Re: [Xen-devel] [PATCH] xl: Do not leak events when a domain exits"):
> Ian Campbell writes ("[PATCH] xl: Do not leak events when a domain exits"):
> > xl: Do not leak events when a domain exits.
> 
> Acked-by: Ian Jackson 

Committed-by: Ian Jackson 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 16:05:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 16:05:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRPva-0000pb-9Z; Thu, 25 Oct 2012 16:05:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRPvY-0000pU-6s
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 16:05:00 +0000
Received: from [85.158.139.211:18661] by server-4.bemta-5.messagelabs.com id
	67/93-01455-B2369805; Thu, 25 Oct 2012 16:04:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1351181098!22219738!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7697 invoked from network); 25 Oct 2012 16:04:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 16:04:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,648,1344211200"; d="scan'208";a="15394360"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 16:04:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 17:04:58 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TRPvW-0007GB-Cj; Thu, 25 Oct 2012 16:04:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TRPvW-0001CD-93;
	Thu, 25 Oct 2012 17:04:58 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20617.25386.174306.720784@mariner.uk.xensource.com>
Date: Thu, 25 Oct 2012 17:04:58 +0100
To: Ian Campbell ,
	"xen-devel@lists.xen.org" 
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20609.12641.710380.815515@mariner.uk.xensource.com>
References: 
	<20609.12641.710380.815515@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [PATCH] xl: Do not leak events when a domain exits
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson writes ("Re: [Xen-devel] [PATCH] xl: Do not leak events when a domain exits"):
> Ian Campbell writes ("[PATCH] xl: Do not leak events when a domain exits"):
> > xl: Do not leak events when a domain exits.
> 
> Acked-by: Ian Jackson 

Committed-by: Ian Jackson 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 16:06:00 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 16:06:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRPwJ-0000tS-Nn; Thu, 25 Oct 2012 16:05:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRPwI-0000tJ-6z
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 16:05:46 +0000
Received: from [85.158.137.99:52880] by server-6.bemta-3.messagelabs.com id
	81/56-32375-95369805; Thu, 25 Oct 2012 16:05:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1351181144!20669509!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 438 invoked from network); 25 Oct 2012 16:05:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 16:05:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,648,1344211200"; d="scan'208";a="15394383"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 16:05:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 17:05:44 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TRPwF-0007GR-VJ; Thu, 25 Oct 2012 16:05:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TRPwF-0001Cb-RI;
	Thu, 25 Oct 2012 17:05:43 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20617.25431.723017.76213@mariner.uk.xensource.com>
Date: Thu, 25 Oct 2012 17:05:43 +0100
To: Ian Campbell ,
	"xen-devel@lists.xen.org" 
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20609.12622.366009.448395@mariner.uk.xensource.com>
References: 
	<20609.12622.366009.448395@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [PATCH] libxl: Use libxl__realloc in a couple of
 places in libxl_events.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson writes ("Re: [Xen-devel] [PATCH] libxl: Use libxl__realloc in a couple of places in libxl_events.c"):
> Ian Campbell writes ("[PATCH] libxl: Use libxl__realloc in a couple of places in libxl_events.c"):
> > libxl: Use libxl__realloc in a couple of places in libxl_events.c
> > 
> > This avoids us having to think about the error handling on failure.
> 
> As far as it goes,
> 
> Acked-by: Ian Jackson 

Committed-by: Ian Jackson 

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 16:06:00 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 16:06:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRPwJ-0000tS-Nn; Thu, 25 Oct 2012 16:05:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRPwI-0000tJ-6z
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 16:05:46 +0000
Received: from [85.158.137.99:52880] by server-6.bemta-3.messagelabs.com id
	81/56-32375-95369805; Thu, 25 Oct 2012 16:05:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1351181144!20669509!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 438 invoked from network); 25 Oct 2012 16:05:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 16:05:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,648,1344211200"; d="scan'208";a="15394383"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 16:05:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 17:05:44 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TRPwF-0007GR-VJ; Thu, 25 Oct 2012 16:05:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TRPwF-0001Cb-RI;
	Thu, 25 Oct 2012 17:05:43 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20617.25431.723017.76213@mariner.uk.xensource.com>
Date: Thu, 25 Oct 2012 17:05:43 +0100
To: Ian Campbell ,
	"xen-devel@lists.xen.org" 
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20609.12622.366009.448395@mariner.uk.xensource.com>
References: 
	<20609.12622.366009.448395@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [PATCH] libxl: Use libxl__realloc in a couple of
 places in libxl_events.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson writes ("Re: [Xen-devel] [PATCH] libxl: Use libxl__realloc in a couple of places in libxl_events.c"):
> Ian Campbell writes ("[PATCH] libxl: Use libxl__realloc in a couple of places in libxl_events.c"):
> > libxl: Use libxl__realloc in a couple of places in libxl_events.c
> > 
> > This avoids us having to think about the error handling on failure.
> 
> As far as it goes,
> 
> Acked-by: Ian Jackson 

Committed-by: Ian Jackson 

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 16:14:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 16:14:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRQ44-0001Dp-R0; Thu, 25 Oct 2012 16:13:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRQ44-0001Dk-C8
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 16:13:48 +0000
Received: from [85.158.143.35:65386] by server-2.bemta-4.messagelabs.com id
	E5/D1-22268-B3569805; Thu, 25 Oct 2012 16:13:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1351181611!5289346!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9790 invoked from network); 25 Oct 2012 16:13:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 16:13:35 -0000
X-IronPort-AV: E=Sophos;i="4.80,648,1344211200"; d="scan'208";a="15394556"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 16:13:04 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 17:13:04 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TRQ3L-0007Iu-VS; Thu, 25 Oct 2012 16:13:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TRQ3L-0001E3-Ra;
	Thu, 25 Oct 2012 17:13:03 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20617.25871.731838.107495@mariner.uk.xensource.com>
Date: Thu, 25 Oct 2012 17:13:03 +0100
To: Christoph Egger 
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <508948C3.5020106@amd.com>
References: <508948C3.5020106@amd.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] libxl: NetBSD PCI passthrough support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Christoph Egger writes ("[Xen-devel] [PATCH] libxl: NetBSD PCI passthrough support"):
> 
> Add PCI passthrough support for HVM guests.

Thanks.

Committed-by: Ian Jackson 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 16:14:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 16:14:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRQ44-0001Dp-R0; Thu, 25 Oct 2012 16:13:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRQ44-0001Dk-C8
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 16:13:48 +0000
Received: from [85.158.143.35:65386] by server-2.bemta-4.messagelabs.com id
	E5/D1-22268-B3569805; Thu, 25 Oct 2012 16:13:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1351181611!5289346!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9790 invoked from network); 25 Oct 2012 16:13:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 16:13:35 -0000
X-IronPort-AV: E=Sophos;i="4.80,648,1344211200"; d="scan'208";a="15394556"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 16:13:04 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 17:13:04 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TRQ3L-0007Iu-VS; Thu, 25 Oct 2012 16:13:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TRQ3L-0001E3-Ra;
	Thu, 25 Oct 2012 17:13:03 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20617.25871.731838.107495@mariner.uk.xensource.com>
Date: Thu, 25 Oct 2012 17:13:03 +0100
To: Christoph Egger 
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <508948C3.5020106@amd.com>
References: <508948C3.5020106@amd.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] libxl: NetBSD PCI passthrough support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Christoph Egger writes ("[Xen-devel] [PATCH] libxl: NetBSD PCI passthrough support"):
> 
> Add PCI passthrough support for HVM guests.

Thanks.

Committed-by: Ian Jackson 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 16:14:44 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 16:14:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRQ4i-0001GL-8F; Thu, 25 Oct 2012 16:14:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRQ4h-0001GD-JI
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 16:14:27 +0000
Received: from [85.158.143.99:44826] by server-3.bemta-4.messagelabs.com id
	E4/5C-24279-26569805; Thu, 25 Oct 2012 16:14:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1351181666!17614304!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16790 invoked from network); 25 Oct 2012 16:14:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 16:14:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,648,1344211200"; d="scan'208";a="15394593"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 16:14:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 17:14:25 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TRQ4f-0007JS-Cc; Thu, 25 Oct 2012 16:14:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TRQ4f-0001EE-97;
	Thu, 25 Oct 2012 17:14:25 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20617.25953.12308.24952@mariner.uk.xensource.com>
Date: Thu, 25 Oct 2012 17:14:25 +0100
To: Christoph Egger 
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <5089493C.9020908@amd.com>
References: <5089493C.9020908@amd.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] ioemu: add pci passthrough support to NetBSD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Christoph Egger writes ("[Xen-devel] [PATCH] ioemu: add pci passthrough support to NetBSD"):
> 
> Support PCI passthrough for NetBSD.

Hmm.  I'm a bit reluctant to add new features to
qemu-xen-traditional.  Does this work with the new upstream-based
qemu-xen ?

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 16:14:44 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 16:14:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRQ4i-0001GL-8F; Thu, 25 Oct 2012 16:14:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRQ4h-0001GD-JI
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 16:14:27 +0000
Received: from [85.158.143.99:44826] by server-3.bemta-4.messagelabs.com id
	E4/5C-24279-26569805; Thu, 25 Oct 2012 16:14:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1351181666!17614304!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16790 invoked from network); 25 Oct 2012 16:14:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 16:14:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,648,1344211200"; d="scan'208";a="15394593"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 16:14:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 17:14:25 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TRQ4f-0007JS-Cc; Thu, 25 Oct 2012 16:14:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TRQ4f-0001EE-97;
	Thu, 25 Oct 2012 17:14:25 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20617.25953.12308.24952@mariner.uk.xensource.com>
Date: Thu, 25 Oct 2012 17:14:25 +0100
To: Christoph Egger 
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <5089493C.9020908@amd.com>
References: <5089493C.9020908@amd.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] ioemu: add pci passthrough support to NetBSD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Christoph Egger writes ("[Xen-devel] [PATCH] ioemu: add pci passthrough support to NetBSD"):
> 
> Support PCI passthrough for NetBSD.

Hmm.  I'm a bit reluctant to add new features to
qemu-xen-traditional.  Does this work with the new upstream-based
qemu-xen ?

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 16:18:26 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 16:18:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRQ8K-0001Sp-TX; Thu, 25 Oct 2012 16:18:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRQ8J-0001Si-Pz
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 16:18:11 +0000
Received: from [85.158.139.211:34197] by server-15.bemta-5.messagelabs.com id
	A2/1D-26920-34669805; Thu, 25 Oct 2012 16:18:11 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1351181888!23720961!1
X-Originating-IP: [216.32.180.187]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15380 invoked from network); 25 Oct 2012 16:18:10 -0000
Received: from co1ehsobe004.messaging.microsoft.com (HELO
	co1outboundpool.messaging.microsoft.com) (216.32.180.187)
	by server-3.tower-206.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Oct 2012 16:18:10 -0000
Received: from mail181-co1-R.bigfish.com (10.243.78.252) by
	CO1EHSOBE001.bigfish.com (10.243.66.64) with Microsoft SMTP Server id
	14.1.225.23; Thu, 25 Oct 2012 16:18:08 +0000
Received: from mail181-co1 (localhost [127.0.0.1])	by
	mail181-co1-R.bigfish.com (Postfix) with ESMTP id 1FBC5DC0250;
	Thu, 25 Oct 2012 16:18:08 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: -9
X-BigFish: VPS-9(zzbb2dI98dI1432I179dNzz1202h1d1ah1d2ahzzz2dh668h839he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h)
Received: from mail181-co1 (localhost.localdomain [127.0.0.1]) by mail181-co1
	(MessageSwitch) id 1351181885629051_16590;
	Thu, 25 Oct 2012 16:18:05 +0000 (UTC)
Received: from CO1EHSMHS027.bigfish.com (unknown [10.243.78.244])	by
	mail181-co1.bigfish.com (Postfix) with ESMTP id 97CE99800F9;
	Thu, 25 Oct 2012 16:18:05 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CO1EHSMHS027.bigfish.com (10.243.66.37) with Microsoft SMTP Server id
	14.1.225.23; Thu, 25 Oct 2012 16:18:02 +0000
X-WSS-ID: 0MCGIM0-01-5D8-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2CA501028104;	Thu, 25 Oct 2012 11:18:00 -0500 (CDT)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 25 Oct 2012 11:18:17 -0500
Received: from STOREXDAG03.amd.com (10.1.13.12) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Thu, 25 Oct 2012 11:18:00 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag03.amd.com
	(10.1.13.12) with Microsoft SMTP Server id 14.2.318.4; Thu, 25 Oct 2012
	12:17:59 -0400
Message-ID: <50896635.7000102@amd.com>
Date: Thu, 25 Oct 2012 18:17:57 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Jackson 
References: <5089493C.9020908@amd.com>
	<20617.25953.12308.24952@mariner.uk.xensource.com>
In-Reply-To: <20617.25953.12308.24952@mariner.uk.xensource.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] ioemu: add pci passthrough support to NetBSD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/25/12 18:14, Ian Jackson wrote:
> Christoph Egger writes ("[Xen-devel] [PATCH] ioemu: add pci passthrough support to NetBSD"):
>>
>> Support PCI passthrough for NetBSD.
> 
> Hmm.  I'm a bit reluctant to add new features to
> qemu-xen-traditional.  Does this work with the new upstream-based
> qemu-xen ?

I do not know.

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 16:18:26 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 16:18:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRQ8K-0001Sp-TX; Thu, 25 Oct 2012 16:18:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRQ8J-0001Si-Pz
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 16:18:11 +0000
Received: from [85.158.139.211:34197] by server-15.bemta-5.messagelabs.com id
	A2/1D-26920-34669805; Thu, 25 Oct 2012 16:18:11 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1351181888!23720961!1
X-Originating-IP: [216.32.180.187]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15380 invoked from network); 25 Oct 2012 16:18:10 -0000
Received: from co1ehsobe004.messaging.microsoft.com (HELO
	co1outboundpool.messaging.microsoft.com) (216.32.180.187)
	by server-3.tower-206.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Oct 2012 16:18:10 -0000
Received: from mail181-co1-R.bigfish.com (10.243.78.252) by
	CO1EHSOBE001.bigfish.com (10.243.66.64) with Microsoft SMTP Server id
	14.1.225.23; Thu, 25 Oct 2012 16:18:08 +0000
Received: from mail181-co1 (localhost [127.0.0.1])	by
	mail181-co1-R.bigfish.com (Postfix) with ESMTP id 1FBC5DC0250;
	Thu, 25 Oct 2012 16:18:08 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: -9
X-BigFish: VPS-9(zzbb2dI98dI1432I179dNzz1202h1d1ah1d2ahzzz2dh668h839he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h)
Received: from mail181-co1 (localhost.localdomain [127.0.0.1]) by mail181-co1
	(MessageSwitch) id 1351181885629051_16590;
	Thu, 25 Oct 2012 16:18:05 +0000 (UTC)
Received: from CO1EHSMHS027.bigfish.com (unknown [10.243.78.244])	by
	mail181-co1.bigfish.com (Postfix) with ESMTP id 97CE99800F9;
	Thu, 25 Oct 2012 16:18:05 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CO1EHSMHS027.bigfish.com (10.243.66.37) with Microsoft SMTP Server id
	14.1.225.23; Thu, 25 Oct 2012 16:18:02 +0000
X-WSS-ID: 0MCGIM0-01-5D8-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2CA501028104;	Thu, 25 Oct 2012 11:18:00 -0500 (CDT)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 25 Oct 2012 11:18:17 -0500
Received: from STOREXDAG03.amd.com (10.1.13.12) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Thu, 25 Oct 2012 11:18:00 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag03.amd.com
	(10.1.13.12) with Microsoft SMTP Server id 14.2.318.4; Thu, 25 Oct 2012
	12:17:59 -0400
Message-ID: <50896635.7000102@amd.com>
Date: Thu, 25 Oct 2012 18:17:57 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Jackson 
References: <5089493C.9020908@amd.com>
	<20617.25953.12308.24952@mariner.uk.xensource.com>
In-Reply-To: <20617.25953.12308.24952@mariner.uk.xensource.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] ioemu: add pci passthrough support to NetBSD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/25/12 18:14, Ian Jackson wrote:
> Christoph Egger writes ("[Xen-devel] [PATCH] ioemu: add pci passthrough support to NetBSD"):
>>
>> Support PCI passthrough for NetBSD.
> 
> Hmm.  I'm a bit reluctant to add new features to
> qemu-xen-traditional.  Does this work with the new upstream-based
> qemu-xen ?

I do not know.

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 16:38:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 16:38:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRQRR-0001ty-OZ; Thu, 25 Oct 2012 16:37:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRQRQ-0001tS-37; Thu, 25 Oct 2012 16:37:56 +0000
Received: from [85.158.139.211:19705] by server-13.bemta-5.messagelabs.com id
	7E/F0-27809-3EA69805; Thu, 25 Oct 2012 16:37:55 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1351183074!23682480!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22804 invoked from network); 25 Oct 2012 16:37:54 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 16:37:54 -0000
Received: by mail-bk0-f45.google.com with SMTP id jf3so914028bkc.32
	for ; Thu, 25 Oct 2012 09:37:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:to
	:subject:content-type;
	bh=psJUc8Anu+HOiBCah+chmXgGVPmZmNVEySiEZ7u1SKc=;
	b=K/SWz68nc8+E52FeCCDBGqto4FDA02SJSUkmlCuZPErtUWxuSjlphAvOX4F/qkb/4R
	eU2oBvaJlRvF9gFUkj+1u9NsmV6HeFVWBghgazLtuk6MhN7+jPm6xFWW+v69sOVscaQV
	LhBRkthOakhn36ZSr/MLwAA5A+Ff+ZqWaAPGVYPNbh3K4CrHRc4wSdz3gohBrQbgb6hc
	MpK6Fnw6lF73b+nufboF/NixfOIvmht0V04h+192BzzJUaFEqPeG+zWBzEUJ0yA38pBw
	TwBjMjtXHfp1TLL1vy8EIFAz43aHn57M48v7rmF+87dbyFVFNNntcOmBIVwsfqVAhDoq
	Eg2w==
Received: by 10.205.136.2 with SMTP id ii2mr6156855bkc.114.1351183073837;
	Thu, 25 Oct 2012 09:37:53 -0700 (PDT)
Received: from [172.16.26.11] (b0fb5ab2.bb.sky.com. [176.251.90.178])
	by mx.google.com with ESMTPS id z13sm10722770bkv.8.2012.10.25.09.37.52
	(version=SSLv3 cipher=OTHER); Thu, 25 Oct 2012 09:37:53 -0700 (PDT)
Message-ID: <50896ADF.3070505@xen.org>
Date: Thu, 25 Oct 2012 17:37:51 +0100
From: Lars Kurth 
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" , 
	"xen-api@lists.xen.org" ,
	xen-users@lists.xen.org, xen-arm@lists.xen.org
Subject: [Xen-devel] Xen Document Day: Oct 29th,
	2012 on IRC freenode #xendocs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: lars.kurth@xen.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============8610166817331146231=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============8610166817331146231==
Content-Type: multipart/alternative;
 boundary="------------000204010709090409020906"

This is a multi-part message in MIME format.
--------------000204010709090409020906
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

everybody. A quick reminder that the next Xen Document Day is happening 
next Monday. More info on document days at 
http://wiki.xen.org/wiki/Xen_Document_Days

Hope to see you on IRC! Feel free to add stuff to the TODO list 
(http://wiki.xen.org/wiki/Xen_Document_Days/TODO) or put your name 
besides an item if you intend to work on it. I just cleaned up the list 
in preparation for Monday.

Best Regards
Lars

*********************
* Xen Document Days *
*********************

We have another Xen document day come up next Monday. Xen Document Days 
are for people who care about Xen Documentation and want to improve it. 
We introduced Documentation Days, because working on documentation in 
parallel with like minded-people, is just more fun than working alone! 
Everybody who can contribute is welcome to join!

For a list of items that need work, check out the community maintained 
TODO list (http://wiki.xen.org/wiki/Xen_Document_Days/TODO). Of course, 
you can work on anything you like: the list just provides suggestions.

How do I participate?
=====================

- Join us on IRC: freenode channel #xendocs
- Tell people what you intend to work on (to avoid doing something somebody
   else is already working on)
- Fix some documentation
- Help others
- And above all: have fun!

--------------000204010709090409020906
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    

      
Hi, 

        

        everybody. A quick reminder that the next Xen Document Day is
        happening next Monday. More info on document days at http://wiki.xen.org/wiki/Xen_Document_Days
        

        

        Hope to see you on IRC! Feel free to add stuff to the TODO list
        (http://wiki.xen.org/wiki/Xen_Document_Days/TODO)
        or put your name besides an item if you intend to work on it. I
        just cleaned up the list in preparation for Monday. 

        

        Best Regards 

        Lars 

        

        ********************* 

        * Xen Document Days * 

        ********************* 

        

        We have another Xen document day come up next Monday. Xen
        Document Days are for people who care about Xen Documentation
        and want to improve it. We introduced Documentation Days,
        because working on documentation in parallel with like
        minded-people, is just more fun than working alone! Everybody
        who can contribute is welcome to join! 

        

        For a list of items that need work, check out the community
        maintained TODO list (http://wiki.xen.org/wiki/Xen_Document_Days/TODO).

        Of course, you can work on anything you like: the list just
        provides suggestions. 

        

        How do I participate? 

        ===================== 

        

        - Join us on IRC: freenode channel #xendocs 

        - Tell people what you intend to work on (to avoid doing
        something somebody 

          else is already working on) 

        - Fix some documentation 

        - Help others 

        - And above all: have fun! 

      

    

  


--------------000204010709090409020906--


--===============8610166817331146231==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8610166817331146231==--


From xen-devel-bounces@lists.xen.org Thu Oct 25 16:38:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 16:38:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRQRR-0001ty-OZ; Thu, 25 Oct 2012 16:37:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRQRQ-0001tS-37; Thu, 25 Oct 2012 16:37:56 +0000
Received: from [85.158.139.211:19705] by server-13.bemta-5.messagelabs.com id
	7E/F0-27809-3EA69805; Thu, 25 Oct 2012 16:37:55 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1351183074!23682480!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22804 invoked from network); 25 Oct 2012 16:37:54 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 16:37:54 -0000
Received: by mail-bk0-f45.google.com with SMTP id jf3so914028bkc.32
	for ; Thu, 25 Oct 2012 09:37:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:to
	:subject:content-type;
	bh=psJUc8Anu+HOiBCah+chmXgGVPmZmNVEySiEZ7u1SKc=;
	b=K/SWz68nc8+E52FeCCDBGqto4FDA02SJSUkmlCuZPErtUWxuSjlphAvOX4F/qkb/4R
	eU2oBvaJlRvF9gFUkj+1u9NsmV6HeFVWBghgazLtuk6MhN7+jPm6xFWW+v69sOVscaQV
	LhBRkthOakhn36ZSr/MLwAA5A+Ff+ZqWaAPGVYPNbh3K4CrHRc4wSdz3gohBrQbgb6hc
	MpK6Fnw6lF73b+nufboF/NixfOIvmht0V04h+192BzzJUaFEqPeG+zWBzEUJ0yA38pBw
	TwBjMjtXHfp1TLL1vy8EIFAz43aHn57M48v7rmF+87dbyFVFNNntcOmBIVwsfqVAhDoq
	Eg2w==
Received: by 10.205.136.2 with SMTP id ii2mr6156855bkc.114.1351183073837;
	Thu, 25 Oct 2012 09:37:53 -0700 (PDT)
Received: from [172.16.26.11] (b0fb5ab2.bb.sky.com. [176.251.90.178])
	by mx.google.com with ESMTPS id z13sm10722770bkv.8.2012.10.25.09.37.52
	(version=SSLv3 cipher=OTHER); Thu, 25 Oct 2012 09:37:53 -0700 (PDT)
Message-ID: <50896ADF.3070505@xen.org>
Date: Thu, 25 Oct 2012 17:37:51 +0100
From: Lars Kurth 
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" , 
	"xen-api@lists.xen.org" ,
	xen-users@lists.xen.org, xen-arm@lists.xen.org
Subject: [Xen-devel] Xen Document Day: Oct 29th,
	2012 on IRC freenode #xendocs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: lars.kurth@xen.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============8610166817331146231=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============8610166817331146231==
Content-Type: multipart/alternative;
 boundary="------------000204010709090409020906"

This is a multi-part message in MIME format.
--------------000204010709090409020906
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

everybody. A quick reminder that the next Xen Document Day is happening 
next Monday. More info on document days at 
http://wiki.xen.org/wiki/Xen_Document_Days

Hope to see you on IRC! Feel free to add stuff to the TODO list 
(http://wiki.xen.org/wiki/Xen_Document_Days/TODO) or put your name 
besides an item if you intend to work on it. I just cleaned up the list 
in preparation for Monday.

Best Regards
Lars

*********************
* Xen Document Days *
*********************

We have another Xen document day come up next Monday. Xen Document Days 
are for people who care about Xen Documentation and want to improve it. 
We introduced Documentation Days, because working on documentation in 
parallel with like minded-people, is just more fun than working alone! 
Everybody who can contribute is welcome to join!

For a list of items that need work, check out the community maintained 
TODO list (http://wiki.xen.org/wiki/Xen_Document_Days/TODO). Of course, 
you can work on anything you like: the list just provides suggestions.

How do I participate?
=====================

- Join us on IRC: freenode channel #xendocs
- Tell people what you intend to work on (to avoid doing something somebody
   else is already working on)
- Fix some documentation
- Help others
- And above all: have fun!

--------------000204010709090409020906
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    

      
Hi, 

        

        everybody. A quick reminder that the next Xen Document Day is
        happening next Monday. More info on document days at http://wiki.xen.org/wiki/Xen_Document_Days
        

        

        Hope to see you on IRC! Feel free to add stuff to the TODO list
        (http://wiki.xen.org/wiki/Xen_Document_Days/TODO)
        or put your name besides an item if you intend to work on it. I
        just cleaned up the list in preparation for Monday. 

        

        Best Regards 

        Lars 

        

        ********************* 

        * Xen Document Days * 

        ********************* 

        

        We have another Xen document day come up next Monday. Xen
        Document Days are for people who care about Xen Documentation
        and want to improve it. We introduced Documentation Days,
        because working on documentation in parallel with like
        minded-people, is just more fun than working alone! Everybody
        who can contribute is welcome to join! 

        

        For a list of items that need work, check out the community
        maintained TODO list (http://wiki.xen.org/wiki/Xen_Document_Days/TODO).

        Of course, you can work on anything you like: the list just
        provides suggestions. 

        

        How do I participate? 

        ===================== 

        

        - Join us on IRC: freenode channel #xendocs 

        - Tell people what you intend to work on (to avoid doing
        something somebody 

          else is already working on) 

        - Fix some documentation 

        - Help others 

        - And above all: have fun! 

      

    

  


--------------000204010709090409020906--


--===============8610166817331146231==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8610166817331146231==--


From xen-devel-bounces@lists.xen.org Thu Oct 25 17:27:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 17:27:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRRDM-00039m-Ag; Thu, 25 Oct 2012 17:27:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRRDK-00039h-Lr
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 17:27:26 +0000
Received: from [85.158.137.99:61707] by server-11.bemta-3.messagelabs.com id
	7F/3B-24008-D7679805; Thu, 25 Oct 2012 17:27:25 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-6.tower-217.messagelabs.com!1351186044!12403100!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7270 invoked from network); 25 Oct 2012 17:27:25 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-6.tower-217.messagelabs.com with AES256-SHA encrypted SMTP;
	25 Oct 2012 17:27:25 -0000
Received: from 255-64-ftth.onsneteindhoven.nl ([88.159.64.255]:51700
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TRRFI-0002Ak-NX; Thu, 25 Oct 2012 19:29:28 +0200
Date: Thu, 25 Oct 2012 19:27:18 +0200
From: Sander Eikelenboom 
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1157156278.20121025192718@eikelenboom.it>
To: Ian Jackson 
In-Reply-To: <20617.24848.614667.919081@mariner.uk.xensource.com>
References: 
	<692244188.20121015123235@eikelenboom.it>
	<1350297477.18058.27.camel@zakaz.uk.xensource.com>
	<751865457.20121015132140@eikelenboom.it>
	<1350301533.18058.35.camel@zakaz.uk.xensource.com>
	<20609.10681.742423.773459@mariner.uk.xensource.com>
	<1782427534.20121025171850@eikelenboom.it>
	<20617.22885.630643.630122@mariner.uk.xensource.com>
	<394587962.20121025173254@eikelenboom.it>
	<1351180049.18035.219.camel@zakaz.uk.xensource.com>
	<20617.24848.614667.919081@mariner.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl shutdown compatibility with xm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Thursday, October 25, 2012, 5:56:00 PM, you wrote:

> Ian Campbell writes ("Re: [PATCH 0 of 5] xl shutdown compatibility with xm"):
>> ACPI fallback != shutdown. It might just as likely be a hibernate or
>> (more likely) a reboot.
>> 
>> Are we going to add code to xl which forces on_reboot = destroy when xl
>> shutdown -F is invoked on a domain?

> We might need to do something along those lines.

>> > But i try to explain that for this special case it doesn't matter if
>> > xl shutdown tries to do the acpi fallback automatically, since this
>> > admin shouldn't use xl shutdown on this domain anyway.
>> 
>> Whether they should or not the xendomains script is going to magically
>> do it for them.

> Well, at the moment the xendomains script will try "xl shutdown" and
> if that fails the guest will be shot in the head.  Trying the acpi
> fallback is surely better?

Perhaps it helps to keep the 2 "use cases", 2 possible changes and their arguments apart:
1) xl shutdown invoked by the xendomains init script
2) xl shutdown invoked manually by a admin or admin-scripts

Possible variants:
Change A) Only change the xendomains init/sysconfig script, and add the -F option to the command.
  Or
Change B) Change the xl shutdown command and remove the -F option, always try acpi fallback when pv fails.





1) xl shutdown invoked by the xendomains init script (also used in a non machine shutdown scenario)
   At present:
               - a guest which can handle the pv shutdown:                                     Guest will shutdown properly.
               - a guest which can't handle pv but would do *shutdown* on the acpi fallback:   Xl shutdown will fail, guest will be shot through the head on hardware shutdown.
               - a guest which can't handle pv but would do *something* on the acpi fallback:  Xl shutdown will fail, guest will be shot through the head on hardware shutdown.
               - a guest which can't handle pv and does nothing on acpi fallback:              Xl shutdown will fail, guest will be shot through the head on hardware shutdown.

               So at present if the domain doesn't react to pv it will be shot through the head anyway, so it could eat your data at present as well, (but in my case i seem to
               be testing and relying on journalling filesystems for some time) :-)

    After change (both A or B):
               - a guest which can handle the pv shutdown:                                     Guest will shutdown properly.
               - a guest which can't handle pv but would do *shutdown* on the acpi fallback:   Guest will shutdown properly.
               - a guest which can't handle pv but would do *something* on the acpi fallback:  Xl shutdown will fail, guest will do *somehting* AND be shot through the head on hardware shutdown.
               - a guest which can't handle pv and does nothing on acpi fallback:              Xl shutdown will fail, guest will be shot through the head on hardware shutdown.

    So both change A or B seem to have no serious negative side effects unless the acpi fallback triggers something like a "rm -rf /" in the guest.
    Such disastrous behavior seems unlikely, but if present, it would probably be known to the admin. In that case he should take special care of this guest anyway.

    It does make a guest that supports properly shutting down on acpi power button to do just that, so in my opinion both change A or B would be a win in this use case.


2)  xl shutdown invoked manually by a admin or admin-scripts (also used in a non machine shutdown scenario)
    At present:
               - a guest which can handle the pv shutdown:                                     Guest will shutdown properly.
               - a guest which can't handle pv but would do *shutdown* on the acpi fallback:   Xl shutdown will fail, admin can supply -F after which the guest will shutdown properly.
               - a guest which can't handle pv but would do *something* on the acpi fallback:  Xl shutdown will fail, admin can supply -F after which the guest will do *something* but doesn't shutdown.
               - a guest which can't handle pv and does nothing on acpi fallback:              Xl shutdown will fail, guest will do nothing and doesn't shutdown.

    After change (A)):
               - Same as present

    After change (B)):
               - a guest which can handle the pv shutdown:                                     Guest will shutdown properly.
               - a guest which can't handle pv but would do *shutdown* on the acpi fallback:   Guest will shutdown properly.
               - a guest which can't handle pv but would do *something* on the acpi fallback:  Guest will do *something* but doesn't shutdown.
               - a guest which can't handle pv and does nothing on acpi fallback:              Xl shutdown will fail, guest will do nothing and doesn't shutdown.

               In this case the win is for the guests that support shutdown on the acpi fallback, it removes the need for a user intervention and supplying the -F option.
               The downside would be a admin using xl shutdown on a domain that does *something* on acpi fallback, where *something* is some devastating action.
               This seems unlikely, but if present, it would probably be known to the admin. In that case he shouldn't use xl shutdown, and probably won't use it anyway since it won't help him anyway.

Summary:

               - change (A) looks quite uncontroversial to me
               - change (B) has as additional benefit that it's one option and manual intervention less to care about (especially for scripts, since it's quite possible to forget the -F option there (see IanJ with the test harness scripts)

--
Sander

> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 17:27:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 17:27:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRRDM-00039m-Ag; Thu, 25 Oct 2012 17:27:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRRDK-00039h-Lr
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 17:27:26 +0000
Received: from [85.158.137.99:61707] by server-11.bemta-3.messagelabs.com id
	7F/3B-24008-D7679805; Thu, 25 Oct 2012 17:27:25 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-6.tower-217.messagelabs.com!1351186044!12403100!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7270 invoked from network); 25 Oct 2012 17:27:25 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-6.tower-217.messagelabs.com with AES256-SHA encrypted SMTP;
	25 Oct 2012 17:27:25 -0000
Received: from 255-64-ftth.onsneteindhoven.nl ([88.159.64.255]:51700
	helo=[172.16.1.20])
	by smtp.eikelenboom.it with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TRRFI-0002Ak-NX; Thu, 25 Oct 2012 19:29:28 +0200
Date: Thu, 25 Oct 2012 19:27:18 +0200
From: Sander Eikelenboom 
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1157156278.20121025192718@eikelenboom.it>
To: Ian Jackson 
In-Reply-To: <20617.24848.614667.919081@mariner.uk.xensource.com>
References: 
	<692244188.20121015123235@eikelenboom.it>
	<1350297477.18058.27.camel@zakaz.uk.xensource.com>
	<751865457.20121015132140@eikelenboom.it>
	<1350301533.18058.35.camel@zakaz.uk.xensource.com>
	<20609.10681.742423.773459@mariner.uk.xensource.com>
	<1782427534.20121025171850@eikelenboom.it>
	<20617.22885.630643.630122@mariner.uk.xensource.com>
	<394587962.20121025173254@eikelenboom.it>
	<1351180049.18035.219.camel@zakaz.uk.xensource.com>
	<20617.24848.614667.919081@mariner.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl shutdown compatibility with xm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Thursday, October 25, 2012, 5:56:00 PM, you wrote:

> Ian Campbell writes ("Re: [PATCH 0 of 5] xl shutdown compatibility with xm"):
>> ACPI fallback != shutdown. It might just as likely be a hibernate or
>> (more likely) a reboot.
>> 
>> Are we going to add code to xl which forces on_reboot = destroy when xl
>> shutdown -F is invoked on a domain?

> We might need to do something along those lines.

>> > But i try to explain that for this special case it doesn't matter if
>> > xl shutdown tries to do the acpi fallback automatically, since this
>> > admin shouldn't use xl shutdown on this domain anyway.
>> 
>> Whether they should or not the xendomains script is going to magically
>> do it for them.

> Well, at the moment the xendomains script will try "xl shutdown" and
> if that fails the guest will be shot in the head.  Trying the acpi
> fallback is surely better?

Perhaps it helps to keep the 2 "use cases", 2 possible changes and their arguments apart:
1) xl shutdown invoked by the xendomains init script
2) xl shutdown invoked manually by a admin or admin-scripts

Possible variants:
Change A) Only change the xendomains init/sysconfig script, and add the -F option to the command.
  Or
Change B) Change the xl shutdown command and remove the -F option, always try acpi fallback when pv fails.





1) xl shutdown invoked by the xendomains init script (also used in a non machine shutdown scenario)
   At present:
               - a guest which can handle the pv shutdown:                                     Guest will shutdown properly.
               - a guest which can't handle pv but would do *shutdown* on the acpi fallback:   Xl shutdown will fail, guest will be shot through the head on hardware shutdown.
               - a guest which can't handle pv but would do *something* on the acpi fallback:  Xl shutdown will fail, guest will be shot through the head on hardware shutdown.
               - a guest which can't handle pv and does nothing on acpi fallback:              Xl shutdown will fail, guest will be shot through the head on hardware shutdown.

               So at present if the domain doesn't react to pv it will be shot through the head anyway, so it could eat your data at present as well, (but in my case i seem to
               be testing and relying on journalling filesystems for some time) :-)

    After change (both A or B):
               - a guest which can handle the pv shutdown:                                     Guest will shutdown properly.
               - a guest which can't handle pv but would do *shutdown* on the acpi fallback:   Guest will shutdown properly.
               - a guest which can't handle pv but would do *something* on the acpi fallback:  Xl shutdown will fail, guest will do *somehting* AND be shot through the head on hardware shutdown.
               - a guest which can't handle pv and does nothing on acpi fallback:              Xl shutdown will fail, guest will be shot through the head on hardware shutdown.

    So both change A or B seem to have no serious negative side effects unless the acpi fallback triggers something like a "rm -rf /" in the guest.
    Such disastrous behavior seems unlikely, but if present, it would probably be known to the admin. In that case he should take special care of this guest anyway.

    It does make a guest that supports properly shutting down on acpi power button to do just that, so in my opinion both change A or B would be a win in this use case.


2)  xl shutdown invoked manually by a admin or admin-scripts (also used in a non machine shutdown scenario)
    At present:
               - a guest which can handle the pv shutdown:                                     Guest will shutdown properly.
               - a guest which can't handle pv but would do *shutdown* on the acpi fallback:   Xl shutdown will fail, admin can supply -F after which the guest will shutdown properly.
               - a guest which can't handle pv but would do *something* on the acpi fallback:  Xl shutdown will fail, admin can supply -F after which the guest will do *something* but doesn't shutdown.
               - a guest which can't handle pv and does nothing on acpi fallback:              Xl shutdown will fail, guest will do nothing and doesn't shutdown.

    After change (A)):
               - Same as present

    After change (B)):
               - a guest which can handle the pv shutdown:                                     Guest will shutdown properly.
               - a guest which can't handle pv but would do *shutdown* on the acpi fallback:   Guest will shutdown properly.
               - a guest which can't handle pv but would do *something* on the acpi fallback:  Guest will do *something* but doesn't shutdown.
               - a guest which can't handle pv and does nothing on acpi fallback:              Xl shutdown will fail, guest will do nothing and doesn't shutdown.

               In this case the win is for the guests that support shutdown on the acpi fallback, it removes the need for a user intervention and supplying the -F option.
               The downside would be a admin using xl shutdown on a domain that does *something* on acpi fallback, where *something* is some devastating action.
               This seems unlikely, but if present, it would probably be known to the admin. In that case he shouldn't use xl shutdown, and probably won't use it anyway since it won't help him anyway.

Summary:

               - change (A) looks quite uncontroversial to me
               - change (B) has as additional benefit that it's one option and manual intervention less to care about (especially for scripts, since it's quite possible to forget the -F option there (see IanJ with the test harness scripts)

--
Sander

> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 17:46:21 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 17:46:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRRVI-0003b2-Ni; Thu, 25 Oct 2012 17:46:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRRVG-0003aw-M9
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 17:45:58 +0000
Received: from [85.158.138.51:53832] by server-4.bemta-3.messagelabs.com id
	BF/62-01405-5DA79805; Thu, 25 Oct 2012 17:45:57 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1351187157!27520353!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14141 invoked from network); 25 Oct 2012 17:45:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 17:45:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,648,1344211200"; d="scan'208";a="15396392"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 17:45:41 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 18:45:42 +0100
Date: Thu, 25 Oct 2012 18:45:11 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1351159160.18035.147.camel@zakaz.uk.xensource.com>
Message-ID: 
References: 
	<1351091027-20740-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<1351159160.18035.147.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" , "Tim
	\(Xen.org\)" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 5/7] xen/arm: wake up secondary cpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 25 Oct 2012, Ian Campbell wrote:
> On Wed, 2012-10-24 at 16:03 +0100, Stefano Stabellini wrote:
> > Secondary cpus are held by the firmware until we send an IPI to them.
> > 
> > Signed-off-by: Stefano Stabellini 
> > ---
> >  xen/arch/arm/head.S        |    8 ++++++--
> >  xen/arch/arm/mode_switch.S |   31 +++++++++++++++++++++++++++++++
> >  2 files changed, 37 insertions(+), 2 deletions(-)
> > 
> > diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
> > index c784f4d..39c4774 100644
> > --- a/xen/arch/arm/head.S
> > +++ b/xen/arch/arm/head.S
> > @@ -79,12 +79,12 @@ start:
> >  	beq   boot_cpu               /* If we're CPU 0, boot now */
> >  
> >  	/* Non-boot CPUs wait here to be woken up one at a time. */
> > -1:	wfe
> > -	dsb
> > +1:	dsb
> >  	ldr   r0, =smp_up_cpu        /* VA of gate */
> >  	add   r0, r0, r10            /* PA of gate */
> >  	ldr   r1, [r0]               /* Which CPU is being booted? */
> >  	teq   r1, r12                /* Is it us? */
> > +	wfene
> >  	bne   1b
> 
> This is a semi-independent bug fix relating to unnecessarily waiting
> (and perhaps blocking indefinitely) on the first iteration of the loop?

yes


> >  
> >  boot_cpu:
> > @@ -98,6 +98,10 @@ boot_cpu:
> >  	PRINT(" booting -\r\n")
> >  #endif
> >  
> > +	/* Wake up secondary cpus */
> > +	teq   r12, #0
> > +	bleq  kick_cpus
> 
> Does this have to be done this early? Couldn't we defer it to C land
> where it would be easier to isolate the processor/platform specific
> behaviour?

Yes, it does because we need to send an interrupt to cpus running in
secure mode, so this has to happen before we drop off secure state and we
enter hypervisor state.


> >  	/* Check that this CPU has Hyp mode */
> >  	mrc   CP32(r0, ID_PFR1)
> >  	and   r0, r0, #0xf000        /* Bits 12-15 define virt extensions */
> > diff --git a/xen/arch/arm/mode_switch.S b/xen/arch/arm/mode_switch.S
> > index 83a682b..39d80e8 100644
> > --- a/xen/arch/arm/mode_switch.S
> > +++ b/xen/arch/arm/mode_switch.S
> > @@ -21,6 +21,37 @@
> >  #include 
> >  #include 
> >  
> > +/* XXX: Versatile Express specific code */
> > +/* wake up secondary cpus */
> > +.globl kick_cpus
> > +kick_cpus:
> 
> My understanding was the mode_switch.S was intended to be a place to
> hold the hacks and fixups required because there is no firmware on the
> models and/or to address short comings in the firmware. This kick
> function is a normal/expected part of booting on a vexpress so I don't
> think it especially belongs here.

I have created a processor.S file for processor specific initializations
(see ACTLR), maybe I can move it there.


> > +    /* write start paddr to v2m sysreg FLAGSSET register */
> > +	ldr   r0, =0x1c010000 /* base V2M sysreg MMIO address */
> > +	add   r1, r0, #0x34   /* SYS_FLAGSCLR register */
> 
> As well as Tim's comment about using the GICD_* registers you should
> define names for the V2M registers somewhere too.

sure

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 17:46:21 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 17:46:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRRVI-0003b2-Ni; Thu, 25 Oct 2012 17:46:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRRVG-0003aw-M9
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 17:45:58 +0000
Received: from [85.158.138.51:53832] by server-4.bemta-3.messagelabs.com id
	BF/62-01405-5DA79805; Thu, 25 Oct 2012 17:45:57 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1351187157!27520353!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14141 invoked from network); 25 Oct 2012 17:45:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 17:45:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,648,1344211200"; d="scan'208";a="15396392"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 17:45:41 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 18:45:42 +0100
Date: Thu, 25 Oct 2012 18:45:11 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1351159160.18035.147.camel@zakaz.uk.xensource.com>
Message-ID: 
References: 
	<1351091027-20740-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<1351159160.18035.147.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" , "Tim
	\(Xen.org\)" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 5/7] xen/arm: wake up secondary cpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 25 Oct 2012, Ian Campbell wrote:
> On Wed, 2012-10-24 at 16:03 +0100, Stefano Stabellini wrote:
> > Secondary cpus are held by the firmware until we send an IPI to them.
> > 
> > Signed-off-by: Stefano Stabellini 
> > ---
> >  xen/arch/arm/head.S        |    8 ++++++--
> >  xen/arch/arm/mode_switch.S |   31 +++++++++++++++++++++++++++++++
> >  2 files changed, 37 insertions(+), 2 deletions(-)
> > 
> > diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
> > index c784f4d..39c4774 100644
> > --- a/xen/arch/arm/head.S
> > +++ b/xen/arch/arm/head.S
> > @@ -79,12 +79,12 @@ start:
> >  	beq   boot_cpu               /* If we're CPU 0, boot now */
> >  
> >  	/* Non-boot CPUs wait here to be woken up one at a time. */
> > -1:	wfe
> > -	dsb
> > +1:	dsb
> >  	ldr   r0, =smp_up_cpu        /* VA of gate */
> >  	add   r0, r0, r10            /* PA of gate */
> >  	ldr   r1, [r0]               /* Which CPU is being booted? */
> >  	teq   r1, r12                /* Is it us? */
> > +	wfene
> >  	bne   1b
> 
> This is a semi-independent bug fix relating to unnecessarily waiting
> (and perhaps blocking indefinitely) on the first iteration of the loop?

yes


> >  
> >  boot_cpu:
> > @@ -98,6 +98,10 @@ boot_cpu:
> >  	PRINT(" booting -\r\n")
> >  #endif
> >  
> > +	/* Wake up secondary cpus */
> > +	teq   r12, #0
> > +	bleq  kick_cpus
> 
> Does this have to be done this early? Couldn't we defer it to C land
> where it would be easier to isolate the processor/platform specific
> behaviour?

Yes, it does because we need to send an interrupt to cpus running in
secure mode, so this has to happen before we drop off secure state and we
enter hypervisor state.


> >  	/* Check that this CPU has Hyp mode */
> >  	mrc   CP32(r0, ID_PFR1)
> >  	and   r0, r0, #0xf000        /* Bits 12-15 define virt extensions */
> > diff --git a/xen/arch/arm/mode_switch.S b/xen/arch/arm/mode_switch.S
> > index 83a682b..39d80e8 100644
> > --- a/xen/arch/arm/mode_switch.S
> > +++ b/xen/arch/arm/mode_switch.S
> > @@ -21,6 +21,37 @@
> >  #include 
> >  #include 
> >  
> > +/* XXX: Versatile Express specific code */
> > +/* wake up secondary cpus */
> > +.globl kick_cpus
> > +kick_cpus:
> 
> My understanding was the mode_switch.S was intended to be a place to
> hold the hacks and fixups required because there is no firmware on the
> models and/or to address short comings in the firmware. This kick
> function is a normal/expected part of booting on a vexpress so I don't
> think it especially belongs here.

I have created a processor.S file for processor specific initializations
(see ACTLR), maybe I can move it there.


> > +    /* write start paddr to v2m sysreg FLAGSSET register */
> > +	ldr   r0, =0x1c010000 /* base V2M sysreg MMIO address */
> > +	add   r1, r0, #0x34   /* SYS_FLAGSCLR register */
> 
> As well as Tim's comment about using the GICD_* registers you should
> define names for the V2M registers somewhere too.

sure

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 17:52:44 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 17:52:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRRbW-0003nG-B1; Thu, 25 Oct 2012 17:52:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRRbU-0003mo-NM
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 17:52:25 +0000
Received: from [85.158.139.211:8231] by server-13.bemta-5.messagelabs.com id
	A8/B9-27809-85C79805; Thu, 25 Oct 2012 17:52:24 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1351187542!19760106!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16705 invoked from network); 25 Oct 2012 17:52:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 17:52:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,648,1344211200"; d="scan'208";a="15396444"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 17:52:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 18:52:22 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53] helo=spongy)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TRRbS-00006i-1M;
	Thu, 25 Oct 2012 17:52:22 +0000
Received: by spongy (Postfix, from userid 2023)	id 7417B34040D; Thu, 25 Oct
	2012 18:55:31 +0100 (BST)
From: Jean Guyader 
To: 
Date: Thu, 25 Oct 2012 18:55:29 +0100
Message-ID: <1351187729-4681-3-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1351187729-4681-1-git-send-email-jean.guyader@citrix.com>
References: <1351187729-4681-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: tim@xen.org, Jean Guyader , JBeulich@suse.com
Subject: [Xen-devel] [PATCH 2/2] xen: Add V4V implementation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: quoted-printable


Setup of v4v domains a domain gets created and cleanup
when a domain die. Wire up the v4v hypercall.

Include v4v internal and public headers.

Signed-off-by: Jean Guyader 
---
 xen/arch/x86/hvm/hvm.c             |    6 +-
 xen/arch/x86/x86_64/compat/entry.S |    2 +
 xen/arch/x86/x86_64/entry.S        |    2 +
 xen/common/Makefile                |    1 +
 xen/common/domain.c                |   13 +-
 xen/common/v4v.c                   | 1922 ++++++++++++++++++++++++++++++=
++++++
 xen/include/public/v4v.h           |  308 ++++++
 xen/include/public/xen.h           |    2 +-
 xen/include/xen/sched.h            |    4 +
 xen/include/xen/v4v.h              |   49 +
 10 files changed, 2305 insertions(+), 4 deletions(-)
 create mode 100644 xen/common/v4v.c
 create mode 100644 xen/include/public/v4v.h
 create mode 100644 xen/include/xen/v4v.h


--------------true
Content-Type: text/x-patch; name="0002-xen-Add-V4V-implementation.patch"
Content-Disposition: attachment;
	filename="0002-xen-Add-V4V-implementation.patch"
Content-Transfer-Encoding: quoted-printable

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 34da2f5..e5237f9 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3242,7 +3242,8 @@ static hvm_hypercall_t *const hvm_hypercall64_table=
[NR_hypercalls] =3D {
     HYPERCALL(set_timer_op),
     HYPERCALL(hvm_op),
     HYPERCALL(sysctl),
-    HYPERCALL(tmem_op)
+    HYPERCALL(tmem_op),
+    HYPERCALL(v4v_op)
 };
=20
 #define COMPAT_CALL(x)                                        \
@@ -3259,7 +3260,8 @@ static hvm_hypercall_t *const hvm_hypercall32_table=
[NR_hypercalls] =3D {
     COMPAT_CALL(set_timer_op),
     HYPERCALL(hvm_op),
     HYPERCALL(sysctl),
-    HYPERCALL(tmem_op)
+    HYPERCALL(tmem_op),
+    HYPERCALL(v4v_op)
 };
=20
 int hvm_do_hypercall(struct cpu_user_regs *regs)
diff --git a/xen/arch/x86/x86_64/compat/entry.S b/xen/arch/x86/x86_64/com=
pat/entry.S
index e6b52f3..4902c4f 100644
--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -414,6 +414,7 @@ ENTRY(compat_hypercall_table)
         .quad do_domctl
         .quad compat_kexec_op
         .quad do_tmem_op
+        .quad do_v4v_op
         .rept __HYPERVISOR_arch_0-((.-compat_hypercall_table)/8)
         .quad compat_ni_hypercall
         .endr
@@ -462,6 +463,7 @@ ENTRY(compat_hypercall_args_table)
         .byte 1 /* do_domctl                */
         .byte 2 /* compat_kexec_op          */
         .byte 1 /* do_tmem_op               */
+        .byte 5 /* do_v4v_op		    */
         .rept __HYPERVISOR_arch_0-(.-compat_hypercall_args_table)
         .byte 0 /* compat_ni_hypercall      */
         .endr
diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S
index ffb9314..78006cf 100644
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -707,6 +707,7 @@ ENTRY(hypercall_table)
         .quad do_domctl
         .quad do_kexec_op
         .quad do_tmem_op
+        .quad do_v4v_op
         .rept __HYPERVISOR_arch_0-((.-hypercall_table)/8)
         .quad do_ni_hypercall
         .endr
@@ -755,6 +756,7 @@ ENTRY(hypercall_args_table)
         .byte 1 /* do_domctl            */
         .byte 2 /* do_kexec             */
         .byte 1 /* do_tmem_op           */
+        .byte 5 /* do_v4v_op		*/
         .rept __HYPERVISOR_arch_0-(.-hypercall_args_table)
         .byte 0 /* do_ni_hypercall      */
         .endr
diff --git a/xen/common/Makefile b/xen/common/Makefile
index c1c100f..ba63cec 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -45,6 +45,7 @@ obj-y +=3D tmem_xen.o
 obj-y +=3D radix-tree.o
 obj-y +=3D rbtree.o
 obj-y +=3D lzo.o
+obj-y +=3D v4v.o
=20
 obj-bin-$(CONFIG_X86) +=3D $(foreach n,decompress bunzip2 unxz unlzma un=
lzo,$(n).init.o)
=20
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 0e3e36a..60cd8e3 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -195,7 +195,8 @@ struct domain *domain_create(
 {
     struct domain *d, **pd;
     enum { INIT_xsm =3D 1u<<0, INIT_watchdog =3D 1u<<1, INIT_rangeset =3D=
 1u<<2,
-           INIT_evtchn =3D 1u<<3, INIT_gnttab =3D 1u<<4, INIT_arch =3D 1=
u<<5 };
+           INIT_evtchn =3D 1u<<3, INIT_gnttab =3D 1u<<4, INIT_arch =3D 1=
u<<5,
+           INIT_v4v =3D 1u<<6 };
     int err, init_status =3D 0;
     int poolid =3D CPUPOOLID_NONE;
=20
@@ -307,6 +308,13 @@ struct domain *domain_create(
         spin_unlock(&domlist_update_lock);
     }
=20
+    if ( !is_idle_domain(d) )
+    {
+        if ( v4v_init(d) !=3D 0 )
+            goto fail;
+        init_status |=3D INIT_v4v;
+    }
+
     return d;
=20
  fail:
@@ -315,6 +323,8 @@ struct domain *domain_create(
     xfree(d->mem_event);
     if ( init_status & INIT_arch )
         arch_domain_destroy(d);
+    if ( init_status & INIT_v4v )
+	v4v_destroy(d);
     if ( init_status & INIT_gnttab )
         grant_table_destroy(d);
     if ( init_status & INIT_evtchn )
@@ -489,6 +499,7 @@ int domain_kill(struct domain *d)
         domain_pause(d);
         d->is_dying =3D DOMDYING_dying;
         spin_barrier(&d->domain_lock);
+        v4v_destroy(d);
         evtchn_destroy(d);
         gnttab_release_mappings(d);
         tmem_destroy(d->tmem);
diff --git a/xen/common/v4v.c b/xen/common/v4v.c
new file mode 100644
index 0000000..404ae3d
--- /dev/null
+++ b/xen/common/v4v.c
@@ -0,0 +1,1922 @@
+/***********************************************************************=
*******
+ * V4V
+ *
+ * Version 2 of v2v (Virtual-to-Virtual)
+ *
+ * Copyright (c) 2010, Citrix Systems
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 =
 USA
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DEFINE_XEN_GUEST_HANDLE(v4v_iov_t);
+DEFINE_XEN_GUEST_HANDLE(v4v_addr_t);
+DEFINE_XEN_GUEST_HANDLE(v4v_send_addr_t);
+DEFINE_XEN_GUEST_HANDLE(v4v_ring_t);
+DEFINE_XEN_GUEST_HANDLE(v4v_ring_data_ent_t);
+DEFINE_XEN_GUEST_HANDLE(v4v_ring_data_t);
+DEFINE_XEN_GUEST_HANDLE(v4v_info_t);
+DEFINE_XEN_GUEST_HANDLE(v4v_pfn_t);
+DEFINE_XEN_GUEST_HANDLE(v4vtables_rule_t);
+DEFINE_XEN_GUEST_HANDLE(v4vtables_list_t);
+DEFINE_XEN_GUEST_HANDLE(uint8_t);
+
+struct v4v_pending_ent
+{
+    struct hlist_node node;
+    domid_t id;
+    uint32_t len;
+};
+
+typedef struct v4vtables_rule_node
+{
+    struct list_head list;
+    v4vtables_rule_t rule;
+} v4vtables_rule_node_t;
+
+struct v4v_ring_info
+{
+    /* next node in the hash, protected by L2  */
+    struct hlist_node node;
+    /* this ring's id, protected by L2 */
+    v4v_ring_id_t id;
+    /* L3 */
+    spinlock_t lock;
+    /* cached length of the ring (from ring->len), protected by L3 */
+    uint32_t len;
+    uint32_t npage;
+    /* cached tx pointer location, protected by L3 */
+    uint32_t tx_ptr;
+    /* guest ring, protected by L3 */
+    XEN_GUEST_HANDLE(v4v_ring_t) ring;
+    /* mapped ring pages protected by L3*/
+    uint8_t **mfn_mapping;
+    /* list of mfns of guest ring */
+    mfn_t *mfns;
+    /* list of struct v4v_pending_ent for this ring, L3 */
+    struct hlist_head pending;
+};
+
+/*
+ * The value of the v4v element in a struct domain is
+ * protected by the global lock L1
+ */
+#define V4V_HTABLE_SIZE 32
+struct v4v_domain
+{
+    /* L2 */
+    rwlock_t lock;
+    /* event channel */
+    evtchn_port_t evtchn_port;
+    /* protected by L2 */
+    struct hlist_head ring_hash[V4V_HTABLE_SIZE];
+};
+
+/*
+ * Messages on the ring are padded to 128 bits
+ * Len here refers to the exact length of the data not including the
+ * 128 bit header. The message uses
+ * ((len +0xf) & ~0xf) + sizeof(v4v_ring_message_header) bytes
+ */
+#define V4V_ROUNDUP(a) (((a) +0xf ) & ~0xf)
+
+/*
+ * Helper functions
+ */
+
+static inline uint16_t
+v4v_hash_fn(v4v_ring_id_t *id)
+{
+    uint16_t ret;
+    ret =3D (uint16_t)(id->addr.port >> 16);
+    ret ^=3D (uint16_t)id->addr.port;
+    ret ^=3D id->addr.domain;
+    ret ^=3D id->partner;
+
+    ret &=3D (V4V_HTABLE_SIZE - 1);
+
+    return ret;
+}
+
+static struct v4v_ring_info *v4v_ring_find_info(struct domain *d,
+                                                v4v_ring_id_t *id);
+
+static struct v4v_ring_info *v4v_ring_find_info_by_addr(struct domain *d=
,
+                                                        struct v4v_addr =
*a,
+                                                        domid_t p);
+
+struct list_head v4vtables_rules =3D LIST_HEAD_INIT(v4vtables_rules);
+
+/*
+ * locks
+ */
+
+/*
+ * locking is organized as follows:
+ *
+ * the global lock v4v_lock: L1 protects the v4v elements
+ * of all struct domain *d in the system, it does not
+ * protect any of the elements of d->v4v, just their
+ * addresses. By extension since the destruction of
+ * a domain with a non-NULL d->v4v will need to free
+ * the d->v4v pointer, holding this lock gauruntees
+ * that no domains pointers in which v4v is interested
+ * become invalid whilst this lock is held.
+ */
+
+static DEFINE_RWLOCK(v4v_lock); /* L1 */
+
+/*
+ * the lock d->v4v->lock: L2:  Read on protects the hash table and
+ * the elements in the hash_table d->v4v->ring_hash, and
+ * the node and id fields in struct v4v_ring_info in the
+ * hash table. Write on L2 protects all of the elements of
+ * struct v4v_ring_info. To take L2 you must already have R(L1)
+ * W(L1) implies W(L2) and L3
+ *
+ * the lock v4v_ring_info *ringinfo; ringinfo->lock: L3:
+ * protects len,tx_ptr the guest ring, the
+ * guest ring_data and the pending list. To take L3 you must
+ * already have R(L2). W(L2) implies L3
+ */
+
+/*
+ * lock to protect the filtering rules list: v4vtable_rules
+ *
+ * The write lock is held for viptables_del and viptables_add
+ * The read lock is held for viptable_list
+ */
+static DEFINE_RWLOCK(v4vtables_rules_lock);
+
+
+/*
+ * Debugs
+ */
+
+#ifdef V4V_DEBUG
+#define v4v_dprintk(format, args...)            \
+    do {                                        \
+        printk("%s:%d " format,                 \
+               __FILE__, __LINE__, ## args );   \
+    } while ( 1 =3D=3D 0 )
+#else
+#define v4v_dprintk(format, ... ) (void)0
+#endif
+
+#ifdef V4V_DEBUG
+static void __attribute__((unused))
+v4v_hexdump(void *_p, int len)
+{
+    uint8_t *buf =3D (uint8_t *)_p;
+    int i, j;
+
+    for ( i =3D 0; i < len; i +=3D 16 )
+    {
+        printk(KERN_ERR "%p:", &buf[i]);
+        for ( j =3D 0; j < 16; ++j )
+        {
+            int k =3D i + j;
+            if ( k < len )
+                printk(" %02x", buf[k]);
+            else
+                printk("   ");
+        }
+        printk(" ");
+
+        for ( j =3D 0; j < 16; ++j )
+        {
+            int k =3D i + j;
+            if ( k < len )
+                printk("%c", ((buf[k] > 32) && (buf[k] < 127)) ? buf[k] =
: '.');
+            else
+                printk(" ");
+        }
+        printk("\n");
+    }
+}
+#endif
+
+
+/*
+ * Event channel
+ */
+
+static void
+v4v_signal_domain(struct domain *d)
+{
+    v4v_dprintk("send guest VIRQ_V4V domid:%d\n", d->domain_id);
+
+    evtchn_send(d, d->v4v->evtchn_port);
+}
+
+static void
+v4v_signal_domid(domid_t id)
+{
+    struct domain *d =3D get_domain_by_id(id);
+    if ( !d )
+        return;
+    v4v_signal_domain(d);
+    put_domain(d);
+}
+
+
+/*
+ * ring buffer
+ */
+
+static void
+v4v_ring_unmap(struct v4v_ring_info *ring_info)
+{
+    int i;
+
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    for ( i =3D 0; i < ring_info->npage; ++i )
+    {
+        if ( !ring_info->mfn_mapping[i] )
+            continue;
+        v4v_dprintk("unmapping page %p from %p\n",
+                    (void*)mfn_x(ring_info->mfns[i]),
+                    ring_info->mfn_mapping[i]);
+
+        unmap_domain_page(ring_info->mfn_mapping[i]);
+        ring_info->mfn_mapping[i] =3D NULL;
+    }
+}
+
+static uint8_t *
+v4v_ring_map_page(struct v4v_ring_info *ring_info, int i)
+{
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    if ( i >=3D ring_info->npage )
+        return NULL;
+    if ( ring_info->mfn_mapping[i] )
+        return ring_info->mfn_mapping[i];
+    ring_info->mfn_mapping[i] =3D map_domain_page(mfn_x(ring_info->mfns[=
i]));
+
+    v4v_dprintk("mapping page %p to %p\n",
+                (void *)mfn_x(ring_info->mfns[i]),
+                ring_info->mfn_mapping[i]);
+    return ring_info->mfn_mapping[i];
+}
+
+static int
+v4v_memcpy_from_guest_ring(void *_dst, struct v4v_ring_info *ring_info,
+                           uint32_t offset, uint32_t len)
+{
+    int page =3D offset >> PAGE_SHIFT;
+    uint8_t *src;
+    uint8_t *dst =3D _dst;
+
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    offset &=3D PAGE_SIZE - 1;
+
+    while ( (offset + len) > PAGE_SIZE )
+    {
+        src =3D v4v_ring_map_page(ring_info, page);
+
+        if ( !src )
+            return -EFAULT;
+
+        v4v_dprintk("memcpy(%p,%p+%d,%d)\n",
+                    dst, src, offset,
+                    (int)(PAGE_SIZE - offset));
+        memcpy(dst, src + offset, PAGE_SIZE - offset);
+
+        page++;
+        len -=3D PAGE_SIZE - offset;
+        dst +=3D PAGE_SIZE - offset;
+        offset =3D 0;
+    }
+
+    src =3D v4v_ring_map_page(ring_info, page);
+    if ( !src )
+        return -EFAULT;
+
+    v4v_dprintk("memcpy(%p,%p+%d,%d)\n", dst, src, offset, len);
+    memcpy(dst, src + offset, len);
+
+    return 0;
+}
+
+static int
+v4v_update_tx_ptr(struct v4v_ring_info *ring_info, uint32_t tx_ptr)
+{
+    uint8_t *dst =3D v4v_ring_map_page(ring_info, 0);
+    uint32_t *p =3D (uint32_t *)(dst + offsetof(v4v_ring_t, tx_ptr));
+
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    if ( !dst )
+        return -EFAULT;
+    write_atomic(p, tx_ptr);
+    mb();
+    return 0;
+}
+
+static int
+v4v_copy_from_guest_maybe(void *dst, void *src,
+                          XEN_GUEST_HANDLE(uint8_t) src_hnd,
+                          uint32_t len)
+{
+    int rc =3D 0;
+
+    if ( src )
+        memcpy(dst, src, len);
+    else
+        rc =3D __copy_from_guest(dst, src_hnd, len);
+    return rc;
+}
+
+static int
+v4v_memcpy_to_guest_ring(struct v4v_ring_info *ring_info,
+                         uint32_t offset,
+                         void *src,
+                         XEN_GUEST_HANDLE(uint8_t) src_hnd,
+                         uint32_t len)
+{
+    int page =3D offset >> PAGE_SHIFT;
+    uint8_t *dst;
+
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    offset &=3D PAGE_SIZE - 1;
+
+    while ( (offset + len) > PAGE_SIZE )
+    {
+        dst =3D v4v_ring_map_page(ring_info, page);
+        if ( !dst )
+            return -EFAULT;
+
+        if ( v4v_copy_from_guest_maybe(dst + offset, src, src_hnd,
+                                       PAGE_SIZE - offset) )
+            return -EFAULT;
+
+        page++;
+        len -=3D PAGE_SIZE - offset;
+        if ( src )
+            src +=3D (PAGE_SIZE - offset);
+        else
+            guest_handle_add_offset(src_hnd, PAGE_SIZE - offset);
+        offset =3D 0;
+    }
+
+    dst =3D v4v_ring_map_page(ring_info, page);
+    if ( !dst )
+        return -EFAULT;
+
+    if ( v4v_copy_from_guest_maybe(dst + offset, src, src_hnd, len) )
+        return -EFAULT;
+
+    return 0;
+}
+
+static int
+v4v_ringbuf_get_rx_ptr(struct domain *d, struct v4v_ring_info *ring_info=
,
+                        uint32_t * rx_ptr)
+{
+    v4v_ring_t *ringp;
+
+    if ( ring_info->npage =3D=3D 0 )
+        return -1;
+
+    ringp =3D map_domain_page(mfn_x(ring_info->mfns[0]));
+
+    v4v_dprintk("v4v_ringbuf_payload_space: mapped %p to %p\n",
+                (void *)mfn_x(ring_info->mfns[0]), ringp);
+    if ( !ringp )
+        return -1;
+
+    write_atomic(rx_ptr, ringp->rx_ptr);
+    mb();
+
+    unmap_domain_page(mfn_x(ring_info->mfns[0]));
+    return 0;
+}
+
+uint32_t
+v4v_ringbuf_payload_space(struct domain * d, struct v4v_ring_info * ring=
_info)
+{
+    v4v_ring_t ring;
+    int32_t ret;
+
+    ring.tx_ptr =3D ring_info->tx_ptr;
+    ring.len =3D ring_info->len;
+
+    if ( v4v_ringbuf_get_rx_ptr(d, ring_info, &ring.rx_ptr) )
+        return 0;
+
+    v4v_dprintk("v4v_ringbuf_payload_space:tx_ptr=3D%d rx_ptr=3D%d\n",
+                (int)ring.tx_ptr, (int)ring.rx_ptr);
+    if ( ring.rx_ptr =3D=3D ring.tx_ptr )
+        return ring.len - sizeof (struct v4v_ring_message_header);
+
+    ret =3D ring.rx_ptr - ring.tx_ptr;
+    if ( ret < 0 )
+        ret +=3D ring.len;
+
+    ret -=3D sizeof (struct v4v_ring_message_header);
+    ret -=3D V4V_ROUNDUP(1);
+
+    return (ret < 0) ? 0 : ret;
+}
+
+static long
+v4v_iov_count(XEN_GUEST_HANDLE(v4v_iov_t) iovs, int niov)
+{
+    v4v_iov_t iov;
+    size_t ret =3D 0;
+
+    while ( niov-- )
+    {
+        if ( copy_from_guest(&iov, iovs, 1) )
+            return -EFAULT;
+
+        ret +=3D iov.iov_len;
+
+        /* message bigger than 2G can't be sent */
+        if (ret > 2L * 1024 * 1024 * 1024)
+            return -EMSGSIZE;
+
+        guest_handle_add_offset(iovs, 1);
+    }
+
+    return ret;
+}
+
+static long
+v4v_ringbuf_insertv(struct domain *d,
+                    struct v4v_ring_info *ring_info,
+                    v4v_ring_id_t *src_id, uint32_t proto,
+                    XEN_GUEST_HANDLE(v4v_iov_t) iovs, uint32_t niov,
+                    size_t len)
+{
+    v4v_ring_t ring;
+    struct v4v_ring_message_header mh =3D { 0 };
+    int32_t sp;
+    long happy_ret;
+    int32_t ret =3D 0;
+    XEN_GUEST_HANDLE(uint8_t) empty_hnd =3D { 0 };
+
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    happy_ret =3D len;
+
+    if ( (V4V_ROUNDUP(len) + sizeof (struct v4v_ring_message_header) ) >=
=3D
+            ring_info->len)
+        return -EMSGSIZE;
+
+    do
+    {
+        if ( (ret =3D v4v_memcpy_from_guest_ring(&ring, ring_info, 0,
+                                               sizeof (ring))) )
+            break;
+
+        ring.tx_ptr =3D ring_info->tx_ptr;
+        ring.len =3D ring_info->len;
+
+        v4v_dprintk("ring.tx_ptr=3D%d ring.rx_ptr=3D%d ring.len=3D%d rin=
g_info->tx_ptr=3D%d\n",
+                    ring.tx_ptr, ring.rx_ptr, ring.len, ring_info->tx_pt=
r);
+
+        if ( ring.rx_ptr =3D=3D ring.tx_ptr )
+            sp =3D ring_info->len;
+        else
+        {
+            sp =3D ring.rx_ptr - ring.tx_ptr;
+            if ( sp < 0 )
+                sp +=3D ring.len;
+        }
+
+        if ( (V4V_ROUNDUP(len) + sizeof (struct v4v_ring_message_header)=
) >=3D sp )
+        {
+            v4v_dprintk("EAGAIN\n");
+            ret =3D -EAGAIN;
+            break;
+        }
+
+        mh.len =3D len + sizeof (struct v4v_ring_message_header);
+        mh.source =3D src_id->addr;
+        mh.message_type =3D proto;
+
+        if ( (ret =3D v4v_memcpy_to_guest_ring(ring_info,
+                                             ring.tx_ptr + sizeof (v4v_r=
ing_t),
+                                             &mh, empty_hnd,
+                                             sizeof (mh))) )
+            break;
+
+        ring.tx_ptr +=3D sizeof (mh);
+        if ( ring.tx_ptr =3D=3D ring_info->len )
+            ring.tx_ptr =3D 0;
+
+        while ( niov-- )
+        {
+            XEN_GUEST_HANDLE(uint8_t) buf_hnd;
+            v4v_iov_t iov;
+
+            if ( copy_from_guest(&iov, iovs, 1) )
+            {
+                ret =3D -EFAULT;
+                break;
+            }
+
+            buf_hnd.p =3D (uint8_t *)iov.iov_base; //FIXME
+            len =3D iov.iov_len;
+
+            if ( unlikely(!guest_handle_okay(buf_hnd, len)) )
+            {
+                ret =3D -EFAULT;
+                break;
+            }
+
+            sp =3D ring.len - ring.tx_ptr;
+
+            if ( len > sp )
+            {
+                ret =3D v4v_memcpy_to_guest_ring(ring_info,
+                        ring.tx_ptr + sizeof (v4v_ring_t),
+                        NULL, buf_hnd, sp);
+                if ( ret )
+                    break;
+
+                ring.tx_ptr =3D 0;
+                len -=3D sp;
+                guest_handle_add_offset(buf_hnd, sp);
+            }
+
+            ret =3D v4v_memcpy_to_guest_ring(ring_info,
+                    ring.tx_ptr + sizeof (v4v_ring_t),
+                    NULL, buf_hnd, len);
+            if ( ret )
+                break;
+
+            ring.tx_ptr +=3D len;
+
+            if ( ring.tx_ptr =3D=3D ring_info->len )
+                ring.tx_ptr =3D 0;
+
+            guest_handle_add_offset(iovs, 1);
+        }
+        if ( ret )
+            break;
+
+        ring.tx_ptr =3D V4V_ROUNDUP(ring.tx_ptr);
+
+        if ( ring.tx_ptr >=3D ring_info->len )
+            ring.tx_ptr -=3D ring_info->len;
+
+        mb();
+        ring_info->tx_ptr =3D ring.tx_ptr;
+        if ( (ret =3D v4v_update_tx_ptr(ring_info, ring.tx_ptr)) )
+            break;
+    }
+    while ( 0 );
+
+    v4v_ring_unmap(ring_info);
+
+    return ret ? ret : happy_ret;
+}
+
+
+
+/* pending */
+static void
+v4v_pending_remove_ent(struct v4v_pending_ent *ent)
+{
+    hlist_del(&ent->node);
+    xfree(ent);
+}
+
+static void
+v4v_pending_remove_all(struct v4v_ring_info *info)
+{
+    struct hlist_node *node, *next;
+    struct v4v_pending_ent *pending_ent;
+
+    ASSERT(spin_is_locked(&info->lock));
+    hlist_for_each_entry_safe(pending_ent, node, next, &info->pending,
+            node) v4v_pending_remove_ent(pending_ent);
+}
+
+static void
+v4v_pending_notify(struct domain *caller_d, struct hlist_head *to_notify=
)
+{
+    struct hlist_node *node, *next;
+    struct v4v_pending_ent *pending_ent;
+
+    ASSERT(rw_is_locked(&v4v_lock));
+
+    hlist_for_each_entry_safe(pending_ent, node, next, to_notify, node)
+    {
+        hlist_del(&pending_ent->node);
+        v4v_signal_domid(pending_ent->id);
+        xfree(pending_ent);
+    }
+
+}
+
+static void
+v4v_pending_find(struct domain *d, struct v4v_ring_info *ring_info,
+                 uint32_t payload_space, struct hlist_head *to_notify)
+{
+    struct hlist_node *node, *next;
+    struct v4v_pending_ent *ent;
+
+    ASSERT(rw_is_locked(&d->v4v->lock));
+
+    spin_lock(&ring_info->lock);
+    hlist_for_each_entry_safe(ent, node, next, &ring_info->pending, node=
)
+    {
+        if ( payload_space >=3D ent->len )
+        {
+            hlist_del(&ent->node);
+            hlist_add_head(&ent->node, to_notify);
+        }
+    }
+    spin_unlock(&ring_info->lock);
+}
+
+/*caller must have L3 */
+static int
+v4v_pending_queue(struct v4v_ring_info *ring_info, domid_t src_id, int l=
en)
+{
+    struct v4v_pending_ent *ent =3D xmalloc(struct v4v_pending_ent);
+
+    if ( !ent )
+    {
+        v4v_dprintk("ENOMEM\n");
+        return -ENOMEM;
+    }
+
+    ent->len =3D len;
+    ent->id =3D src_id;
+
+    hlist_add_head(&ent->node, &ring_info->pending);
+
+    return 0;
+}
+
+/* L3 */
+static int
+v4v_pending_requeue(struct v4v_ring_info *ring_info, domid_t src_id, int=
 len)
+{
+    struct hlist_node *node;
+    struct v4v_pending_ent *ent;
+
+    hlist_for_each_entry(ent, node, &ring_info->pending, node)
+    {
+        if ( ent->id =3D=3D src_id )
+        {
+            if ( ent->len < len )
+                ent->len =3D len;
+            return 0;
+        }
+    }
+
+    return v4v_pending_queue(ring_info, src_id, len);
+}
+
+
+/* L3 */
+static void
+v4v_pending_cancel(struct v4v_ring_info *ring_info, domid_t src_id)
+{
+    struct hlist_node *node, *next;
+    struct v4v_pending_ent *ent;
+
+    hlist_for_each_entry_safe(ent, node, next, &ring_info->pending, node=
)
+    {
+        if ( ent->id =3D=3D src_id)
+        {
+            hlist_del(&ent->node);
+            xfree(ent);
+        }
+    }
+}
+
+/*
+ * ring data
+ */
+
+/*Caller should hold R(L1)*/
+static int
+v4v_fill_ring_data(struct domain *src_d,
+                   XEN_GUEST_HANDLE(v4v_ring_data_ent_t) data_ent_hnd)
+{
+    v4v_ring_data_ent_t ent;
+    struct domain *dst_d;
+    struct v4v_ring_info *ring_info;
+
+    if ( copy_from_guest(&ent, data_ent_hnd, 1) )
+    {
+        v4v_dprintk("EFAULT\n");
+        return -EFAULT;
+    }
+
+    v4v_dprintk("v4v_fill_ring_data: ent.ring.domain=3D%d,ent.ring.port=3D=
%u\n",
+                (int)ent.ring.domain, (int)ent.ring.port);
+
+    ent.flags =3D 0;
+
+    dst_d =3D get_domain_by_id(ent.ring.domain);
+
+    if ( dst_d && dst_d->v4v )
+    {
+        read_lock(&dst_d->v4v->lock);
+        ring_info =3D v4v_ring_find_info_by_addr(dst_d, &ent.ring,
+                                               src_d->domain_id);
+
+        if ( ring_info )
+        {
+            uint32_t space_avail;
+
+            ent.flags |=3D V4V_RING_DATA_F_EXISTS;
+            ent.max_message_size =3D
+                ring_info->len - sizeof (struct v4v_ring_message_header)=
 -
+                V4V_ROUNDUP(1);
+            spin_lock(&ring_info->lock);
+
+            space_avail =3D v4v_ringbuf_payload_space(dst_d, ring_info);
+
+            if ( space_avail >=3D ent.space_required )
+            {
+                v4v_pending_cancel(ring_info, src_d->domain_id);
+                ent.flags |=3D V4V_RING_DATA_F_SUFFICIENT;
+            }
+            else
+            {
+                v4v_pending_requeue(ring_info, src_d->domain_id,
+                        ent.space_required);
+                ent.flags |=3D V4V_RING_DATA_F_PENDING;
+            }
+
+            spin_unlock(&ring_info->lock);
+
+            if ( space_avail =3D=3D ent.max_message_size )
+                ent.flags |=3D V4V_RING_DATA_F_EMPTY;
+
+        }
+        read_unlock(&dst_d->v4v->lock);
+    }
+
+    if ( dst_d )
+        put_domain(dst_d);
+
+    if ( copy_field_to_guest(data_ent_hnd, &ent, flags) )
+    {
+        v4v_dprintk("EFAULT\n");
+        return -EFAULT;
+    }
+    return 0;
+}
+
+/*Called should hold no more than R(L1) */
+static int
+v4v_fill_ring_datas(struct domain *d, int nent,
+                     XEN_GUEST_HANDLE(v4v_ring_data_ent_t) data_ent_hnd)
+{
+    int ret =3D 0;
+
+    read_lock(&v4v_lock);
+    while ( !ret && nent-- )
+    {
+        ret =3D v4v_fill_ring_data(d, data_ent_hnd);
+        guest_handle_add_offset(data_ent_hnd, 1);
+    }
+    read_unlock(&v4v_lock);
+    return ret;
+}
+
+/*
+ * ring
+ */
+static int
+v4v_find_ring_mfns(struct domain *d, struct v4v_ring_info *ring_info,
+                   uint32_t npage, XEN_GUEST_HANDLE(v4v_pfn_t) pfn_hnd)
+{
+    int i,j;
+    mfn_t *mfns;
+    uint8_t **mfn_mapping;
+    unsigned long mfn;
+    struct page_info *page;
+    int ret =3D 0;
+
+    if ( (npage << PAGE_SHIFT) < ring_info->len )
+    {
+        v4v_dprintk("EINVAL\n");
+        return -EINVAL;
+    }
+
+    mfns =3D xmalloc_array(mfn_t, npage);
+    if ( !mfns )
+    {
+        v4v_dprintk("ENOMEM\n");
+        return -ENOMEM;
+    }
+
+    mfn_mapping =3D xmalloc_array(uint8_t *, npage);
+    if ( !mfn_mapping )
+    {
+        xfree(mfns);
+        return -ENOMEM;
+    }
+
+    for ( i =3D 0; i < npage; ++i )
+    {
+        unsigned long pfn;
+        p2m_type_t p2mt;
+
+        if ( copy_from_guest_offset(&pfn, pfn_hnd, i, 1) )
+        {
+            ret =3D -EFAULT;
+            v4v_dprintk("EFAULT\n");
+            break;
+        }
+
+        mfn =3D mfn_x(get_gfn(d, pfn, &p2mt));
+        if ( !mfn_valid(mfn) )
+        {
+            printk(KERN_ERR "v4v domain %d passed invalid mfn %"PRI_mfn"=
 ring %p seq %d\n",
+                    d->domain_id, mfn, ring_info, i);
+            ret =3D -EINVAL;
+            break;
+        }
+        page =3D mfn_to_page(mfn);
+        if ( !get_page_and_type(page, d, PGT_writable_page) )
+        {
+            printk(KERN_ERR "v4v domain %d passed wrong type mfn %"PRI_m=
fn" ring %p seq %d\n",
+                    d->domain_id, mfn, ring_info, i);
+            ret =3D -EINVAL;
+            break;
+        }
+        mfns[i] =3D _mfn(mfn);
+        v4v_dprintk("v4v_find_ring_mfns: %d: %lx -> %lx\n",
+                    i, (unsigned long)pfn, (unsigned long)mfn_x(mfns[i])=
);
+        mfn_mapping[i] =3D NULL;
+        put_gfn(d, pfn);
+    }
+
+    if ( !ret )
+    {
+        ring_info->npage =3D npage;
+        ring_info->mfns =3D mfns;
+        ring_info->mfn_mapping =3D mfn_mapping;
+    }
+    else
+    {
+        j =3D i;
+        for ( i =3D 0; i < j; ++i )
+            if ( mfn_x(mfns[i]) !=3D 0 )
+                put_page_and_type(mfn_to_page(mfn_x(mfns[i])));
+        xfree(mfn_mapping);
+        xfree(mfns);
+    }
+    return ret;
+}
+
+
+static struct v4v_ring_info *
+v4v_ring_find_info(struct domain *d, v4v_ring_id_t *id)
+{
+    uint16_t hash;
+    struct hlist_node *node;
+    struct v4v_ring_info *ring_info;
+
+    ASSERT(rw_is_locked(&d->v4v->lock));
+
+    hash =3D v4v_hash_fn(id);
+
+    v4v_dprintk("ring_find_info: d->v4v=3D%p, d->v4v->ring_hash[%d]=3D%p=
 id=3D%p\n",
+                d->v4v, (int)hash, d->v4v->ring_hash[hash].first, id);
+    v4v_dprintk("ring_find_info: id.addr.port=3D%d id.addr.domain=3D%d i=
d.addr.partner=3D%d\n",
+                id->addr.port, id->addr.domain, id->partner);
+
+    hlist_for_each_entry(ring_info, node, &d->v4v->ring_hash[hash], node=
)
+    {
+        v4v_ring_id_t *cmpid =3D &ring_info->id;
+
+        if ( cmpid->addr.port =3D=3D id->addr.port &&
+             cmpid->addr.domain =3D=3D id->addr.domain &&
+             cmpid->partner =3D=3D id->partner)
+        {
+            v4v_dprintk("ring_find_info: ring_info=3D%p\n", ring_info);
+            return ring_info;
+        }
+    }
+    v4v_dprintk("ring_find_info: no ring_info found\n");
+    return NULL;
+}
+
+static struct v4v_ring_info *
+v4v_ring_find_info_by_addr(struct domain *d, struct v4v_addr *a, domid_t=
 p)
+{
+    v4v_ring_id_t id;
+    struct v4v_ring_info *ret;
+
+    ASSERT(rw_is_locked(&d->v4v->lock));
+
+    if ( !a )
+        return NULL;
+
+    id.addr.port =3D a->port;
+    id.addr.domain =3D d->domain_id;
+    id.partner =3D p;
+
+    ret =3D v4v_ring_find_info(d, &id);
+    if ( ret )
+        return ret;
+
+    id.partner =3D V4V_DOMID_ANY;
+
+    return v4v_ring_find_info(d, &id);
+}
+
+static void v4v_ring_remove_mfns(struct domain *d, struct v4v_ring_info =
*ring_info)
+{
+    int i;
+
+    ASSERT(rw_is_write_locked(&d->v4v->lock));
+
+    if ( ring_info->mfns )
+    {
+        for ( i =3D 0; i < ring_info->npage; ++i )
+            if ( mfn_x(ring_info->mfns[i]) !=3D 0 )
+                put_page_and_type(mfn_to_page(mfn_x(ring_info->mfns[i]))=
);
+        xfree(ring_info->mfns);
+    }
+    if ( ring_info->mfn_mapping )
+        xfree(ring_info->mfn_mapping);
+    ring_info->mfns =3D NULL;
+
+}
+
+static void
+v4v_ring_remove_info(struct domain *d, struct v4v_ring_info *ring_info)
+{
+    ASSERT(rw_is_write_locked(&d->v4v->lock));
+
+    spin_lock(&ring_info->lock);
+
+    v4v_pending_remove_all(ring_info);
+    hlist_del(&ring_info->node);
+    v4v_ring_remove_mfns(d, ring_info);
+
+    spin_unlock(&ring_info->lock);
+
+    xfree(ring_info);
+}
+
+/* Call from guest to unpublish a ring */
+static long
+v4v_ring_remove(struct domain *d, XEN_GUEST_HANDLE(v4v_ring_t) ring_hnd)
+{
+    struct v4v_ring ring;
+    struct v4v_ring_info *ring_info;
+    int ret =3D 0;
+
+    read_lock(&v4v_lock);
+
+    do
+    {
+        if ( !d->v4v )
+        {
+            v4v_dprintk("EINVAL\n");
+            ret =3D -EINVAL;
+            break;
+        }
+
+        if ( copy_from_guest(&ring, ring_hnd, 1) )
+        {
+            v4v_dprintk("EFAULT\n");
+            ret =3D -EFAULT;
+            break;
+        }
+
+        if ( ring.magic !=3D V4V_RING_MAGIC )
+        {
+            v4v_dprintk("ring.magic(%"PRIx64") !=3D V4V_RING_MAGIC(%"PRI=
x64"), EINVAL\n",
+                    ring.magic, V4V_RING_MAGIC);
+            ret =3D -EINVAL;
+            break;
+        }
+
+        ring.id.addr.domain =3D d->domain_id;
+
+        write_lock(&d->v4v->lock);
+        ring_info =3D v4v_ring_find_info(d, &ring.id);
+
+        if ( ring_info )
+            v4v_ring_remove_info(d, ring_info);
+
+        write_unlock(&d->v4v->lock);
+
+        if ( !ring_info )
+        {
+            v4v_dprintk("ENOENT\n");
+            ret =3D -ENOENT;
+            break;
+        }
+
+    }
+    while ( 0 );
+
+    read_unlock(&v4v_lock);
+    return ret;
+}
+
+/* call from guest to publish a ring */
+static long
+v4v_ring_add(struct domain *d, XEN_GUEST_HANDLE(v4v_ring_t) ring_hnd,
+             uint32_t npage, XEN_GUEST_HANDLE(v4v_pfn_t) pfn_hnd)
+{
+    struct v4v_ring ring;
+    struct v4v_ring_info *ring_info;
+    int need_to_insert =3D 0;
+    int ret =3D 0;
+
+    if ( (long)ring_hnd.p & (PAGE_SIZE - 1) )
+    {
+        v4v_dprintk("EINVAL\n");
+        return -EINVAL;
+    }
+
+    read_lock(&v4v_lock);
+    do
+    {
+        if ( !d->v4v )
+        {
+            v4v_dprintk(" !d->v4v, EINVAL\n");
+            ret =3D -EINVAL;
+            break;
+        }
+
+        if ( copy_from_guest(&ring, ring_hnd, 1) )
+        {
+            v4v_dprintk(" copy_from_guest failed, EFAULT\n");
+            ret =3D -EFAULT;
+            break;
+        }
+
+        if ( ring.magic !=3D V4V_RING_MAGIC )
+        {
+            v4v_dprintk("ring.magic(%lx) !=3D V4V_RING_MAGIC(%lx), EINVA=
L\n",
+                        ring.magic, V4V_RING_MAGIC);
+            ret =3D -EINVAL;
+            break;
+        }
+
+        if ( (ring.len <
+                    (sizeof (struct v4v_ring_message_header) + V4V_ROUND=
UP(1) +
+                     V4V_ROUNDUP(1))) || (V4V_ROUNDUP(ring.len) !=3D rin=
g.len) )
+        {
+            v4v_dprintk("EINVAL\n");
+            ret =3D -EINVAL;
+            break;
+        }
+
+        ring.id.addr.domain =3D d->domain_id;
+        if ( copy_field_to_guest(ring_hnd, &ring, id) )
+        {
+            v4v_dprintk("EFAULT\n");
+            ret =3D -EFAULT;
+            break;
+        }
+
+        /*
+         * no need for a lock yet, because only we know about this
+         * set the tx pointer if it looks bogus (we don't reset it
+         * because this might be a re-register after S4)
+         */
+        if ( (ring.tx_ptr >=3D ring.len)
+                || (V4V_ROUNDUP(ring.tx_ptr) !=3D ring.tx_ptr) )
+        {
+            ring.tx_ptr =3D ring.rx_ptr;
+        }
+        copy_field_to_guest(ring_hnd, &ring, tx_ptr);
+
+        read_lock(&d->v4v->lock);
+        ring_info =3D v4v_ring_find_info(d, &ring.id);
+
+        if ( !ring_info )
+        {
+            read_unlock(&d->v4v->lock);
+            ring_info =3D xmalloc(struct v4v_ring_info);
+            if ( !ring_info )
+            {
+                v4v_dprintk("ENOMEM\n");
+                ret =3D -ENOMEM;
+                break;
+            }
+            need_to_insert++;
+            spin_lock_init(&ring_info->lock);
+            INIT_HLIST_HEAD(&ring_info->pending);
+            ring_info->mfns =3D NULL;
+
+        }
+        else
+        {
+            /*
+             * Ring info already existed.
+             */
+            printk(KERN_INFO "v4v: dom%d ring already registered\n",
+                    current->domain->domain_id);
+            ret =3D -EEXIST;
+            break;
+        }
+
+        spin_lock(&ring_info->lock);
+        ring_info->id =3D ring.id;
+        ring_info->len =3D ring.len;
+        ring_info->tx_ptr =3D ring.tx_ptr;
+        ring_info->ring =3D ring_hnd;
+        if ( ring_info->mfns )
+            xfree(ring_info->mfns);
+        ret =3D v4v_find_ring_mfns(d, ring_info, npage, pfn_hnd);
+        spin_unlock(&ring_info->lock);
+        if ( ret )
+            break;
+
+        if ( !need_to_insert )
+        {
+            read_unlock(&d->v4v->lock);
+        }
+        else
+        {
+            uint16_t hash =3D v4v_hash_fn(&ring.id);
+            write_lock(&d->v4v->lock);
+            hlist_add_head(&ring_info->node, &d->v4v->ring_hash[hash]);
+            write_unlock(&d->v4v->lock);
+        }
+    }
+    while ( 0 );
+
+    read_unlock(&v4v_lock);
+    return ret;
+}
+
+
+/*
+ * io
+ */
+
+static void
+v4v_notify_ring(struct domain *d, struct v4v_ring_info *ring_info,
+                struct hlist_head *to_notify)
+{
+    uint32_t space;
+
+    ASSERT(rw_is_locked(&v4v_lock));
+    ASSERT(rw_is_locked(&d->v4v->lock));
+
+    spin_lock(&ring_info->lock);
+    space =3D v4v_ringbuf_payload_space(d, ring_info);
+    spin_unlock(&ring_info->lock);
+
+    v4v_pending_find(d, ring_info, space, to_notify);
+}
+
+/*notify hypercall*/
+static long
+v4v_notify(struct domain *d,
+           XEN_GUEST_HANDLE(v4v_ring_data_t) ring_data_hnd)
+{
+    v4v_ring_data_t ring_data;
+    HLIST_HEAD(to_notify);
+    int i;
+    int ret =3D 0;
+
+    read_lock(&v4v_lock);
+
+    if ( !d->v4v )
+    {
+        read_unlock(&v4v_lock);
+        v4v_dprintk("!d->v4v, ENODEV\n");
+        return -ENODEV;
+    }
+
+    read_lock(&d->v4v->lock);
+    for ( i =3D 0; i < V4V_HTABLE_SIZE; ++i )
+    {
+        struct hlist_node *node, *next;
+        struct v4v_ring_info *ring_info;
+
+        hlist_for_each_entry_safe(ring_info, node,
+                next, &d->v4v->ring_hash[i],
+                node)
+        {
+            v4v_notify_ring(d, ring_info, &to_notify);
+        }
+    }
+    read_unlock(&d->v4v->lock);
+
+    if ( !hlist_empty(&to_notify) )
+        v4v_pending_notify(d, &to_notify);
+
+    do
+    {
+        if ( !guest_handle_is_null(ring_data_hnd) )
+        {
+            /* Quick sanity check on ring_data_hnd */
+            if ( copy_field_from_guest(&ring_data, ring_data_hnd, magic)=
 )
+            {
+                v4v_dprintk("copy_field_from_guest failed\n");
+                ret =3D -EFAULT;
+                break;
+            }
+
+            if ( ring_data.magic !=3D V4V_RING_DATA_MAGIC )
+            {
+                v4v_dprintk("ring.magic(%lx) !=3D V4V_RING_MAGIC(%lx), E=
INVAL\n",
+                        ring_data.magic, V4V_RING_MAGIC);
+                ret =3D -EINVAL;
+                break;
+            }
+
+            if ( copy_from_guest(&ring_data, ring_data_hnd, 1) )
+            {
+                v4v_dprintk("copy_from_guest failed\n");
+                ret =3D -EFAULT;
+                break;
+            }
+
+            {
+                XEN_GUEST_HANDLE(v4v_ring_data_ent_t) ring_data_ent_hnd;
+                ring_data_ent_hnd =3D
+                    guest_handle_for_field(ring_data_hnd, v4v_ring_data_=
ent_t, data[0]);
+                ret =3D v4v_fill_ring_datas(d, ring_data.nent, ring_data=
_ent_hnd);
+            }
+        }
+    }
+    while ( 0 );
+
+    read_unlock(&v4v_lock);
+
+    return ret;
+}
+
+#ifdef V4V_DEBUG
+void
+v4vtables_print_rule(struct v4vtables_rule_node *node)
+{
+    v4vtables_rule_t *rule;
+
+    if ( node =3D=3D NULL )
+    {
+        printk("(null)\n");
+        return;
+    }
+
+    rule =3D &node->rule;
+
+    if ( rule->accept =3D=3D 1 )
+        printk("ACCEPT");
+    else
+        printk("REJECT");
+
+    printk(" ");
+
+    if ( rule->src.domain =3D=3D V4V_DOMID_ANY )
+        printk("*");
+    else
+        printk("%i", rule->src.domain);
+
+    printk(":");
+
+    if ( rule->src.port =3D=3D -1 )
+        printk("*");
+    else
+        printk("%i", rule->src.port);
+
+    printk(" -> ");
+
+    if ( rule->dst.domain =3D=3D V4V_DOMID_ANY )
+        printk("*");
+    else
+        printk("%i", rule->dst.domain);
+
+    printk(":");
+
+    if ( rule->dst.port =3D=3D -1 )
+        printk("*");
+    else
+        printk("%i", rule->dst.port);
+
+    printk("\n");
+}
+#endif /* V4V_DEBUG */
+
+int
+v4vtables_add(struct domain *src_d,
+              XEN_GUEST_HANDLE(v4vtables_rule_t) rule,
+              int32_t position)
+{
+    struct v4vtables_rule_node* new =3D NULL;
+    struct list_head* tmp;
+
+    ASSERT(rw_is_write_locked(&v4vtables_rules_lock));
+
+    /* First rule is n.1 */
+    position--;
+
+    new =3D xmalloc(struct v4vtables_rule_node);
+    if ( new =3D=3D NULL )
+        return -ENOMEM;
+
+    if ( copy_from_guest(&new->rule, rule, 1) )
+    {
+        xfree(new);
+        return -EFAULT;
+    }
+
+#ifdef V4V_DEBUG
+    printk(KERN_ERR "VIPTables: ");
+    v4vtables_print_rule(new);
+#endif /* V4V_DEBUG */
+
+    tmp =3D &v4vtables_rules;
+    while ( position !=3D 0 && tmp->next !=3D &v4vtables_rules)
+    {
+        tmp =3D tmp->next;
+        position--;
+    }
+    list_add(&new->list, tmp);
+
+    return 0;
+}
+
+int
+v4vtables_del(struct domain *src_d,
+              XEN_GUEST_HANDLE(v4vtables_rule_t) rule_hnd,
+              int32_t position)
+{
+    struct list_head *tmp =3D NULL;
+    struct list_head *to_delete =3D NULL;
+    struct list_head *next =3D NULL;
+    struct v4vtables_rule_node *node;
+
+    ASSERT(rw_is_write_locked(&v4vtables_rules_lock));
+
+    v4v_dprintk("v4vtables_del position:%d\n", position);
+
+    if ( position !=3D -1 )
+    {
+        /* We want to delete the rule number  */
+        list_for_each(tmp, &v4vtables_rules)
+        {
+            to_delete =3D tmp;
+            if (position =3D=3D 0)
+                break;
+            position--;
+        }
+        /* Can't find the position */
+        if (position !=3D 0)
+            to_delete =3D NULL;
+    }
+    else if ( !guest_handle_is_null(rule_hnd) )
+    {
+        struct v4vtables_rule r;
+
+        if ( copy_from_guest(&r, rule_hnd, 1) )
+            return -EFAULT;
+
+        list_for_each(tmp, &v4vtables_rules)
+        {
+            node =3D list_entry(tmp, struct v4vtables_rule_node, list);
+
+            if ( (node->rule.src.domain =3D=3D r.src.domain) &&
+                 (node->rule.src.port   =3D=3D r.src.port)   &&
+                 (node->rule.dst.domain =3D=3D r.dst.domain) &&
+                 (node->rule.dst.port   =3D=3D r.dst.port))
+            {
+                to_delete =3D tmp;
+                break;
+            }
+        }
+    }
+    else
+    {
+        /* We want to flush the rules! */
+        printk(KERN_ERR "VIPTables: flushing rules\n");
+        list_for_each_safe(tmp, next, &v4vtables_rules)
+        {
+            node =3D list_entry(tmp, struct v4vtables_rule_node, list);
+            list_del(tmp);
+            xfree(node);
+        }
+    }
+
+    if ( to_delete )
+    {
+        node =3D list_entry(to_delete, struct v4vtables_rule_node, list)=
;
+#ifdef V4V_DEBUG
+        printk(KERN_ERR "VIPTables: deleting rule: ");
+        v4vtables_print_rule(node);
+#endif /* V4V_DEBUG */
+        list_del(to_delete);
+        xfree(node);
+    }
+
+    return 0;
+}
+
+static size_t
+v4vtables_list(struct domain *src_d,
+               XEN_GUEST_HANDLE(v4vtables_list_t) list_hnd)
+{
+    struct list_head *ptr;
+    struct v4vtables_rule_node *node;
+    struct v4vtables_list rules_list;
+    uint32_t nbrules;
+    XEN_GUEST_HANDLE(v4vtables_rule_t) guest_rules;
+
+    ASSERT(rw_is_locked(&v4vtables_rules_lock));
+
+    memset(&rules_list, 0, sizeof (rules_list));
+    if ( copy_from_guest(&rules_list, list_hnd, 1) )
+        return -EFAULT;
+
+    ptr =3D v4vtables_rules.next;
+    while ( rules_list.start_rule !=3D 0 && ptr->next !=3D &v4vtables_ru=
les )
+    {
+        ptr =3D ptr->next;
+        rules_list.start_rule--;
+    }
+
+    if ( rules_list.nb_rules =3D=3D 0 )
+        return -EINVAL;
+
+    guest_rules =3D guest_handle_for_field(list_hnd, v4vtables_rule_t, r=
ules[0]);
+
+    nbrules =3D 0;
+    while ( nbrules < rules_list.nb_rules && ptr !=3D &v4vtables_rules )
+    {
+        node =3D list_entry(ptr, struct v4vtables_rule_node, list);
+
+        if ( copy_to_guest(guest_rules, &node->rule, 1) )
+            break;
+
+        guest_handle_add_offset(guest_rules, 1);
+
+        nbrules++;
+        ptr =3D ptr->next;
+    }
+
+    rules_list.nb_rules =3D nbrules;
+    if ( copy_field_to_guest(list_hnd, &rules_list, nb_rules) )
+        return -EFAULT;
+
+    return 0;
+}
+
+static size_t
+v4vtables_check(v4v_addr_t * src, v4v_addr_t * dst)
+{
+    struct list_head *ptr;
+    struct v4vtables_rule_node *node;
+    size_t ret =3D 0; /* Defaulting to ACCEPT */
+
+    read_lock(&v4vtables_rules_lock);
+
+    list_for_each(ptr, &v4vtables_rules)
+    {
+        node =3D list_entry(ptr, struct v4vtables_rule_node, list);
+
+        if ( (node->rule.src.domain =3D=3D V4V_DOMID_ANY ||
+              node->rule.src.domain =3D=3D src->domain) &&
+             (node->rule.src.port =3D=3D V4V_PORT_ANY ||
+              node->rule.src.port =3D=3D src->port) &&
+             (node->rule.dst.domain =3D=3D V4V_DOMID_ANY ||
+              node->rule.dst.domain =3D=3D dst->domain) &&
+             (node->rule.dst.port =3D=3D V4V_PORT_ANY ||
+              node->rule.dst.port =3D=3D dst->port) )
+        {
+            ret =3D !node->rule.accept;
+            break;
+        }
+    }
+
+    read_unlock(&v4vtables_rules_lock);
+    return ret;
+}
+
+/*
+ * Hypercall to do the send
+ */
+static long
+v4v_sendv(struct domain *src_d, v4v_addr_t * src_addr,
+          v4v_addr_t * dst_addr, uint32_t proto,
+          XEN_GUEST_HANDLE(v4v_iov_t) iovs, size_t niov)
+{
+    struct domain *dst_d;
+    v4v_ring_id_t src_id;
+    struct v4v_ring_info *ring_info;
+    int ret =3D 0;
+
+    if ( !dst_addr )
+    {
+        v4v_dprintk("!dst_addr, EINVAL\n");
+        return -EINVAL;
+    }
+
+    read_lock(&v4v_lock);
+    if ( !src_d->v4v )
+    {
+        read_unlock(&v4v_lock);
+        v4v_dprintk("!src_d->v4v, EINVAL\n");
+        return -EINVAL;
+    }
+
+    src_id.addr.port =3D src_addr->port;
+    src_id.addr.domain =3D src_d->domain_id;
+    src_id.partner =3D dst_addr->domain;
+
+    dst_d =3D get_domain_by_id(dst_addr->domain);
+    if ( !dst_d )
+    {
+        read_unlock(&v4v_lock);
+        v4v_dprintk("!dst_d, ECONNREFUSED\n");
+        return -ECONNREFUSED;
+    }
+
+    if ( v4vtables_check(src_addr, dst_addr) !=3D 0 )
+    {
+        read_unlock(&v4v_lock);
+        gdprintk(XENLOG_WARNING,
+                 "V4V: VIPTables REJECTED %i:%i -> %i:%i\n",
+                 src_addr->domain, src_addr->port,
+                 dst_addr->domain, dst_addr->port);
+        return -ECONNREFUSED;
+    }
+
+    do
+    {
+        if ( !dst_d->v4v )
+        {
+            v4v_dprintk("dst_d->v4v, ECONNREFUSED\n");
+            ret =3D -ECONNREFUSED;
+            break;
+        }
+
+        read_lock(&dst_d->v4v->lock);
+        ring_info =3D
+            v4v_ring_find_info_by_addr(dst_d, dst_addr, src_addr->domain=
);
+
+        if ( !ring_info )
+        {
+            ret =3D -ECONNREFUSED;
+            v4v_dprintk(" !ring_info, ECONNREFUSED\n");
+        }
+        else
+        {
+            long len =3D v4v_iov_count(iovs, niov);
+
+            if ( len < 0 )
+            {
+                ret =3D len;
+                break;
+            }
+
+            spin_lock(&ring_info->lock);
+            ret =3D
+                v4v_ringbuf_insertv(dst_d, ring_info, &src_id, proto, io=
vs,
+                        niov, len);
+            if ( ret =3D=3D -EAGAIN )
+            {
+                v4v_dprintk("v4v_ringbuf_insertv failed, EAGAIN\n");
+                /* Schedule a wake up on the event channel when space is=
 there */
+                if ( v4v_pending_requeue(ring_info, src_d->domain_id, le=
n) )
+                {
+                    v4v_dprintk("v4v_pending_requeue failed, ENOMEM\n");
+                    ret =3D -ENOMEM;
+                }
+            }
+            spin_unlock(&ring_info->lock);
+
+            if ( ret >=3D 0 )
+            {
+                v4v_signal_domain(dst_d);
+            }
+
+        }
+        read_unlock(&dst_d->v4v->lock);
+
+    }
+    while ( 0 );
+
+    put_domain(dst_d);
+    read_unlock(&v4v_lock);
+    return ret;
+}
+
+static void
+v4v_info(struct domain *d, v4v_info_t *info)
+{
+    read_lock(&d->v4v->lock);
+    info->ring_magic =3D V4V_RING_MAGIC;
+    info->data_magic =3D V4V_RING_DATA_MAGIC;
+    info->evtchn =3D d->v4v->evtchn_port;
+    read_unlock(&d->v4v->lock);
+}
+
+/*
+ * hypercall glue
+ */
+long
+do_v4v_op(int cmd, XEN_GUEST_HANDLE(void) arg1,
+          XEN_GUEST_HANDLE(void) arg2,
+          uint32_t arg3, uint32_t arg4)
+{
+    struct domain *d =3D current->domain;
+    long rc =3D -EFAULT;
+
+    v4v_dprintk("->do_v4v_op(%d,%p,%p,%d,%d)\n", cmd,
+                (void *)arg1.p, (void *)arg2.p, (int) arg3, (int) arg4);
+
+    domain_lock(d);
+    switch (cmd)
+    {
+        case V4VOP_register_ring:
+            {
+                XEN_GUEST_HANDLE(v4v_ring_t) ring_hnd =3D
+                    guest_handle_cast(arg1, v4v_ring_t);
+                XEN_GUEST_HANDLE(v4v_pfn_t) pfn_hnd =3D
+                    guest_handle_cast(arg2, v4v_pfn_t);
+                uint32_t npage =3D arg3;
+                if ( unlikely(!guest_handle_okay(pfn_hnd, npage)) )
+                    goto out;
+                rc =3D v4v_ring_add(d, ring_hnd, npage, pfn_hnd);
+                break;
+            }
+        case V4VOP_unregister_ring:
+            {
+                XEN_GUEST_HANDLE(v4v_ring_t) ring_hnd =3D
+                    guest_handle_cast(arg1, v4v_ring_t);
+                rc =3D v4v_ring_remove(d, ring_hnd);
+                break;
+            }
+        case V4VOP_sendv:
+            {
+                uint32_t niov =3D arg3;
+                uint32_t message_type =3D arg4;
+                XEN_GUEST_HANDLE(v4v_send_addr_t) addr_hnd =3D
+                    guest_handle_cast(arg1, v4v_send_addr_t);
+                v4v_send_addr_t addr;
+
+                if ( copy_from_guest(&addr, addr_hnd, 1) )
+                    goto out;
+
+                rc =3D v4v_sendv(d, &addr.src, &addr.dst, message_type,
+                        guest_handle_cast(arg2, v4v_iov_t), niov);
+                break;
+            }
+        case V4VOP_notify:
+            {
+                XEN_GUEST_HANDLE(v4v_ring_data_t) ring_data_hnd =3D
+                    guest_handle_cast(arg1, v4v_ring_data_t);
+                rc =3D v4v_notify(d, ring_data_hnd);
+                break;
+            }
+        case V4VOP_tables_add:
+            {
+                uint32_t position =3D arg3;
+                XEN_GUEST_HANDLE(v4vtables_rule_t) rule_hnd =3D
+                    guest_handle_cast(arg1, v4vtables_rule_t);
+                rc =3D -EPERM;
+                if ( !IS_PRIV(d) )
+                    goto out;
+
+                write_lock(&v4vtables_rules_lock);
+                rc =3D v4vtables_add(d, rule_hnd, position);
+                write_unlock(&v4vtables_rules_lock);
+                break;
+            }
+        case V4VOP_tables_del:
+            {
+                uint32_t position =3D arg3;
+                XEN_GUEST_HANDLE(v4vtables_rule_t) rule_hnd =3D
+                    guest_handle_cast(arg1, v4vtables_rule_t);
+                rc =3D -EPERM;
+                if ( !IS_PRIV(d) )
+                    goto out;
+
+                write_lock(&v4vtables_rules_lock);
+                rc =3D v4vtables_del(d, rule_hnd, position);
+                write_unlock(&v4vtables_rules_lock);
+                break;
+            }
+        case V4VOP_tables_list:
+            {
+                XEN_GUEST_HANDLE(v4vtables_list_t) rules_list_hnd =3D
+                    guest_handle_cast(arg1, v4vtables_list_t);
+                rc =3D -EPERM;
+                if ( !IS_PRIV(d) )
+                    goto out;
+
+                read_lock(&v4vtables_rules_lock);
+                rc =3D v4vtables_list(d, rules_list_hnd);
+                read_unlock(&v4vtables_rules_lock);
+                break;
+            }
+        case V4VOP_info:
+            {
+                XEN_GUEST_HANDLE(v4v_info_t) info_hnd =3D
+                    guest_handle_cast(arg1, v4v_info_t);
+                v4v_info_t info;
+
+                if ( unlikely(!guest_handle_okay(info_hnd, 1)) )
+                    goto out;
+                v4v_info(d, &info);
+                if ( __copy_to_guest(info_hnd, &info, 1) )
+                    goto out;
+                rc =3D 0;
+                break;
+            }
+        default:
+            rc =3D -ENOSYS;
+            break;
+    }
+out:
+    domain_unlock(d);
+    v4v_dprintk("<-do_v4v_op()=3D%d\n", (int)rc);
+    return rc;
+}
+
+/*
+ * init
+ */
+
+void
+v4v_destroy(struct domain *d)
+{
+    int i;
+
+    BUG_ON(!d->is_dying);
+    write_lock(&v4v_lock);
+
+    v4v_dprintk("d->v=3D%p\n", d->v4v);
+
+    if ( d->v4v )
+    {
+        for ( i =3D 0; i < V4V_HTABLE_SIZE; ++i )
+        {
+            struct hlist_node *node, *next;
+            struct v4v_ring_info *ring_info;
+
+            hlist_for_each_entry_safe(ring_info, node,
+                    next, &d->v4v->ring_hash[i],
+                    node)
+            {
+                v4v_ring_remove_info(d, ring_info);
+            }
+        }
+    }
+
+    d->v4v =3D NULL;
+    write_unlock(&v4v_lock);
+}
+
+int
+v4v_init(struct domain *d)
+{
+    struct v4v_domain *v4v;
+    evtchn_port_t port;
+    int i;
+    int rc;
+
+    v4v =3D xmalloc(struct v4v_domain);
+    if ( !v4v )
+        return -ENOMEM;
+
+    rc =3D evtchn_alloc_unbound_domain(d, &port, d->domain_id);
+    if ( rc )
+        return rc;
+
+    rwlock_init(&v4v->lock);
+
+    v4v->evtchn_port =3D port;
+    for ( i =3D 0; i < V4V_HTABLE_SIZE; ++i )
+        INIT_HLIST_HEAD(&v4v->ring_hash[i]);
+
+    write_lock(&v4v_lock);
+    d->v4v =3D v4v;
+    write_unlock(&v4v_lock);
+
+    return 0;
+}
+
+
+/*
+ * debug
+ */
+
+static void
+dump_domain_ring(struct domain *d, struct v4v_ring_info *ring_info)
+{
+    uint32_t rx_ptr;
+
+    printk(KERN_ERR "  ring: domid=3D%d port=3D0x%08x partner=3D%d npage=
=3D%d\n",
+           (int)d->domain_id, (int)ring_info->id.addr.port,
+           (int)ring_info->id.partner, (int)ring_info->npage);
+
+    if ( v4v_ringbuf_get_rx_ptr(d, ring_info, &rx_ptr) )
+    {
+        printk(KERN_ERR "   Failed to read rx_ptr\n");
+        return;
+    }
+
+    printk(KERN_ERR "   tx_ptr=3D%d rx_ptr=3D%d len=3D%d\n",
+           (int)ring_info->tx_ptr, (int)rx_ptr, (int)ring_info->len);
+}
+
+static void
+dump_domain(struct domain *d)
+{
+    int i;
+
+    printk(KERN_ERR " domain %d:\n", (int)d->domain_id);
+
+    read_lock(&d->v4v->lock);
+
+    for ( i =3D 0; i < V4V_HTABLE_SIZE; ++i )
+    {
+        struct hlist_node *node;
+        struct v4v_ring_info *ring_info;
+
+        hlist_for_each_entry(ring_info, node, &d->v4v->ring_hash[i], nod=
e)
+            dump_domain_ring(d, ring_info);
+    }
+
+    printk(KERN_ERR "  event channel: %d\n",  d->v4v->evtchn_port);
+    read_unlock(&d->v4v->lock);
+
+    printk(KERN_ERR "\n");
+    v4v_signal_domain(d);
+}
+
+static void
+dump_state(unsigned char key)
+{
+    struct domain *d;
+
+    printk(KERN_ERR "\n\nV4V:\n");
+    read_lock(&v4v_lock);
+
+    rcu_read_lock(&domlist_read_lock);
+
+    for_each_domain(d)
+        dump_domain(d);
+
+    rcu_read_unlock(&domlist_read_lock);
+
+    read_unlock(&v4v_lock);
+}
+
+struct keyhandler v4v_info_keyhandler =3D
+{
+    .diagnostic =3D 1,
+    .u.fn =3D dump_state,
+    .desc =3D "dump v4v states and interupt"
+};
+
+static int __init
+setup_dump_rings(void)
+{
+    register_keyhandler('4', &v4v_info_keyhandler);
+    return 0;
+}
+
+__initcall(setup_dump_rings);
+
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/public/v4v.h b/xen/include/public/v4v.h
new file mode 100644
index 0000000..c7425cc
--- /dev/null
+++ b/xen/include/public/v4v.h
@@ -0,0 +1,308 @@
+/***********************************************************************=
*******
+ * V4V
+ *
+ * Version 2 of v2v (Virtual-to-Virtual)
+ *
+ * Copyright (c) 2010, Citrix Systems
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 =
 USA
+ */
+
+#ifndef __XEN_PUBLIC_V4V_H__
+#define __XEN_PUBLIC_V4V_H__
+
+#include "xen.h"
+#include "event_channel.h"
+
+/*
+ * Structure definitions
+ */
+
+#define V4V_RING_MAGIC          0xa822f72bb0b9d8ccUL
+#define V4V_RING_DATA_MAGIC	0x45fe852220b801d4UL
+
+#define V4V_MESSAGE_DGRAM       0x3c2c1db8
+#define V4V_MESSAGE_STREAM 	0x70f6a8e5
+
+#define V4V_DOMID_ANY           DOMID_INVALID
+#define V4V_PORT_ANY            0
+
+typedef uint64_t v4v_pfn_t;
+
+typedef struct v4v_iov
+{
+    uint64_t iov_base;
+    uint32_t iov_len;
+    uint32_t pad;
+} v4v_iov_t;
+
+typedef struct v4v_addr
+{
+    uint32_t port;
+    domid_t domain;
+    uint16_t pad;
+} v4v_addr_t;
+
+typedef struct v4v_ring_id
+{
+    v4v_addr_t addr;
+    domid_t partner;
+    uint16_t pad;
+} v4v_ring_id_t;
+
+typedef struct
+{
+    v4v_addr_t src;
+    v4v_addr_t dst;
+} v4v_send_addr_t;
+
+/*
+ * v4v_ring
+ * id: xen only looks at this during register/unregister
+ *     and will fill in id.addr.domain
+ * rx_ptr: rx pointer, modified by domain
+ * tx_ptr: tx pointer, modified by xen
+ *
+ */
+struct v4v_ring
+{
+    uint64_t magic;
+    v4v_ring_id_t id;
+    uint32_t len;
+    uint32_t rx_ptr;
+    uint32_t tx_ptr;
+    uint8_t reserved[32];
+#if defined(__STDC_VERSION__) && __STDC_VERSION__ >=3D 199901L
+    uint8_t ring[];
+#elif defined(__GNUC__)
+    uint8_t ring[0];
+#endif
+};
+typedef struct v4v_ring v4v_ring_t;
+
+#define V4V_RING_DATA_F_EMPTY       (1U << 0) /* Ring is empty */
+#define V4V_RING_DATA_F_EXISTS      (1U << 1) /* Ring exists */
+#define V4V_RING_DATA_F_PENDING     (1U << 2) /* Pending interrupt exist=
s - do not
+                                               * rely on this field - fo=
r
+                                               * profiling only */
+#define V4V_RING_DATA_F_SUFFICIENT  (1U << 3) /* Sufficient space to que=
ue
+                                               * space_required bytes ex=
ists */
+
+typedef struct v4v_ring_data_ent
+{
+    v4v_addr_t ring;
+    uint16_t flags;
+    uint16_t pad;
+    uint32_t space_required;
+    uint32_t max_message_size;
+} v4v_ring_data_ent_t;
+
+typedef struct v4v_ring_data
+{
+    uint64_t magic;
+    uint32_t nent;
+    uint32_t pad;
+    uint64_t reserved[4];
+#if defined(__STDC_VERSION__) && __STDC_VERSION__ >=3D 199901L
+    v4v_ring_data_ent_t data[];
+#elif defined(__GNUC__)
+    v4v_ring_data_ent_t data[0];
+#endif
+} v4v_ring_data_t;
+
+struct v4v_info
+{
+    uint64_t ring_magic;
+    uint64_t data_magic;
+    evtchn_port_t evtchn;
+    uint32_t pad;
+};
+typedef struct v4v_info v4v_info_t;
+
+#define V4V_SHF_SYN		(1 << 0)
+#define V4V_SHF_ACK		(1 << 1)
+#define V4V_SHF_RST		(1 << 2)
+
+#define V4V_SHF_PING		(1 << 8)
+#define V4V_SHF_PONG		(1 << 9)
+
+struct v4v_stream_header
+{
+    uint32_t flags;
+    uint32_t conid;
+};
+
+struct v4v_ring_message_header
+{
+    uint32_t len;
+    uint32_t pad0;
+    v4v_addr_t source;
+    uint32_t message_type;
+#if defined(__STDC_VERSION__) && __STDC_VERSION__ >=3D 199901L
+    uint8_t data[];
+#elif defined(__GNUC__)
+    uint8_t data[0];
+#endif
+};
+
+typedef struct v4vtables_rule
+{
+    v4v_addr_t src;
+    v4v_addr_t dst;
+    uint32_t accept;
+} v4vtables_rule_t;
+
+typedef struct v4vtables_list
+{
+    uint32_t start_rule;
+    uint32_t nb_rules;
+#if defined(__STDC_VERSION__) && __STDC_VERSION__ >=3D 199901L
+    struct v4vtables_rule rules[];
+#elif defined(__GNUC__)
+    struct v4vtables_rule rules[0];
+#endif
+} v4vtables_list_t;
+
+/*
+ * HYPERCALLS
+ */
+
+/*
+ * V4VOP_register_ring
+ *
+ * Registers a ring with Xen. If a ring with the same v4v_ring_id exists=
,
+ * the hypercall will return -EEXIST.
+ *
+ * do_v4v_op(V4VOP_register_ring,
+ *           XEN_GUEST_HANDLE(v4v_ring_t), XEN_GUEST_HANDLE(v4v_pfn_t),
+ *           npage, 0)
+ */
+#define V4VOP_register_ring 	1
+
+
+/*
+ * V4VOP_unregister_ring
+ *
+ * Unregister a ring.
+ *
+ * do_v4v_op(V4VOP_unregister_ring,
+ *           XEN_GUEST_HANDLE(v4v_ring_t),
+ *           NULL, 0, 0)
+ */
+#define V4VOP_unregister_ring 	2
+
+/*
+ * V4VOP_notify
+ *
+ * Asks xen for information about other rings in the system
+ *
+ * ent->ring is the v4v_addr_t of the ring you want information on
+ * the same matching rules are used as for V4VOP_send.
+ *
+ * ent->space_required  if this field is not null xen will check
+ * that there is space in the destination ring for this many bytes
+ * of payload. If there is it will set the V4V_RING_DATA_F_SUFFICIENT
+ * and CANCEL any pending interrupt for that ent->ring, if insufficient
+ * space is available it will schedule an interrupt and the flag will
+ * not be set.
+ *
+ * The flags are set by xen when notify replies
+ * V4V_RING_DATA_F_EMPTY	ring is empty
+ * V4V_RING_DATA_F_PENDING	interrupt is pending - don't rely on this
+ * V4V_RING_DATA_F_SUFFICIENT	sufficient space for space_required is the=
re
+ * V4V_RING_DATA_F_EXISTS	ring exists
+ *
+ * do_v4v_op(V4VOP_notify,
+ *           XEN_GUEST_HANDLE(v4v_ring_data_ent_t) ent,
+ *           NULL, 0, 0)
+ */
+#define V4VOP_notify 		4
+
+/*
+ * V4VOP_sendv
+ *
+ * Sends of list of buffer contained in iov.
+ *
+ * For each iov entry send iov_len bytes of iov_base to addr.dst, giving
+ * src as the source address (xen will ignore src->domain and put your
+ * domain in the actually message), xen first looks for a ring with id.a=
ddr=3D=3Ddst
+ * and id.partner=3D=3Dsending_domain if that fails it looks for id.addr=
=3D=3Ddst and
+ * id.partner=3D=3DDOMID_ANY.
+ * message_type is the 32 bit number used from the message
+ * most likely V4V_MESSAGE_DGRAM or V4V_MESSAGE_STREAM. If insufficient =
space exists
+ * it will return -EAGAIN and xen will twing the V4V_INTERRUPT when
+ * sufficient space becomes available
+ *
+ * do_v4v_op(V4VOP_sendv,
+ *           XEN_GUEST_HANDLE(v4v_send_addr_t) addr,
+ *           XEN_GUEST_HANDLE(v4v_iov_t) iov,
+ *           uint32_t niov,
+ *           uint32_t message_type)
+ */
+#define V4VOP_sendv		5
+
+/*
+ * V4VOP_tables_add
+ *
+ * Insert a filtering rules after a given position.
+ *
+ * do_v4v_op(V4VOP_tables_add,
+ *           XEN_GUEST_HANDLE(v4vtables_rule_t) rule,
+ *           NULL,
+ *           uint32_t position, 0)
+ */
+#define V4VOP_tables_add     6
+
+/*
+ * V4VOP_tables_del
+ *
+ * Delete a filtering rules at a position or the rule
+ * that matches "rule".
+ *
+ * do_v4v_op(V4VOP_tables_del,
+ *           XEN_GUEST_HANDLE(v4vtables_rule_t) rule,
+ *           NULL,
+ *           uint32_t position, 0)
+ */
+#define V4VOP_tables_del     7
+
+/*
+ * V4VOP_tables_list
+ *
+ * do_v4v_op(V4VOP_tables_list,
+ *           XEN_GUEST_HANDLE(v4vtpables_list_t) list,
+ *           NULL, 0, 0)
+ */
+#define V4VOP_tables_list    8
+
+/*
+ * V4VOP_info
+ *
+ * Returns v4v info for the current domain (domain that issued the hyper=
call).
+ *      - V4V magic number
+ *      - event channel port (for current domain)
+ *
+ * do_v4v_op(V4VOP_info,
+ *           XEN_GUEST_HANDLE(v4v_info_t) info,
+ *           NULL, 0, 0)
+ */
+#define V4VOP_info              9
+
+#endif /* __XEN_PUBLIC_V4V_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 7352d1e..66a3605 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -100,7 +100,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
 #define __HYPERVISOR_domctl               36
 #define __HYPERVISOR_kexec_op             37
 #define __HYPERVISOR_tmem_op              38
-#define __HYPERVISOR_xc_reserved_op       39 /* reserved for XenClient *=
/
+#define __HYPERVISOR_v4v_op               39
=20
 /* Architecture-specific hypercall definitions. */
 #define __HYPERVISOR_arch_0               48
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 6c55039..2fd9313 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
=20
 #ifdef CONFIG_COMPAT
 #include 
@@ -363,6 +364,9 @@ struct domain
     nodemask_t node_affinity;
     unsigned int last_alloc_node;
     spinlock_t node_affinity_lock;
+
+    /* v4v */
+    struct v4v_domain *v4v;
 };
=20
 struct domain_setup_info
diff --git a/xen/include/xen/v4v.h b/xen/include/xen/v4v.h
new file mode 100644
index 0000000..dd6fce4
--- /dev/null
+++ b/xen/include/xen/v4v.h
@@ -0,0 +1,49 @@
+/***********************************************************************=
*******
+ * V4V
+ *
+ * Version 2 of v2v (Virtual-to-Virtual)
+ *
+ * Copyright (c) 2010, Citrix Systems
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 =
 USA
+ */
+
+#ifndef __V4V_PRIVATE_H__
+#define __V4V_PRIVATE_H__
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct v4v_domain;
+
+void v4v_destroy(struct domain *d);
+int v4v_init(struct domain *d);
+long do_v4v_op (int cmd,
+                XEN_GUEST_HANDLE (void) arg1,
+                XEN_GUEST_HANDLE (void) arg2,
+                uint32_t arg3,
+                uint32_t arg4);
+
+#endif /* __V4V_PRIVATE_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */

--------------true
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------true--


From xen-devel-bounces@lists.xen.org Thu Oct 25 17:52:44 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 17:52:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRRbW-0003nG-B1; Thu, 25 Oct 2012 17:52:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRRbU-0003mo-NM
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 17:52:25 +0000
Received: from [85.158.139.211:8231] by server-13.bemta-5.messagelabs.com id
	A8/B9-27809-85C79805; Thu, 25 Oct 2012 17:52:24 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1351187542!19760106!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16705 invoked from network); 25 Oct 2012 17:52:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 17:52:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,648,1344211200"; d="scan'208";a="15396444"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 17:52:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 18:52:22 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53] helo=spongy)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TRRbS-00006i-1M;
	Thu, 25 Oct 2012 17:52:22 +0000
Received: by spongy (Postfix, from userid 2023)	id 7417B34040D; Thu, 25 Oct
	2012 18:55:31 +0100 (BST)
From: Jean Guyader 
To: 
Date: Thu, 25 Oct 2012 18:55:29 +0100
Message-ID: <1351187729-4681-3-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1351187729-4681-1-git-send-email-jean.guyader@citrix.com>
References: <1351187729-4681-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: tim@xen.org, Jean Guyader , JBeulich@suse.com
Subject: [Xen-devel] [PATCH 2/2] xen: Add V4V implementation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: quoted-printable


Setup of v4v domains a domain gets created and cleanup
when a domain die. Wire up the v4v hypercall.

Include v4v internal and public headers.

Signed-off-by: Jean Guyader 
---
 xen/arch/x86/hvm/hvm.c             |    6 +-
 xen/arch/x86/x86_64/compat/entry.S |    2 +
 xen/arch/x86/x86_64/entry.S        |    2 +
 xen/common/Makefile                |    1 +
 xen/common/domain.c                |   13 +-
 xen/common/v4v.c                   | 1922 ++++++++++++++++++++++++++++++=
++++++
 xen/include/public/v4v.h           |  308 ++++++
 xen/include/public/xen.h           |    2 +-
 xen/include/xen/sched.h            |    4 +
 xen/include/xen/v4v.h              |   49 +
 10 files changed, 2305 insertions(+), 4 deletions(-)
 create mode 100644 xen/common/v4v.c
 create mode 100644 xen/include/public/v4v.h
 create mode 100644 xen/include/xen/v4v.h


--------------true
Content-Type: text/x-patch; name="0002-xen-Add-V4V-implementation.patch"
Content-Disposition: attachment;
	filename="0002-xen-Add-V4V-implementation.patch"
Content-Transfer-Encoding: quoted-printable

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 34da2f5..e5237f9 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3242,7 +3242,8 @@ static hvm_hypercall_t *const hvm_hypercall64_table=
[NR_hypercalls] =3D {
     HYPERCALL(set_timer_op),
     HYPERCALL(hvm_op),
     HYPERCALL(sysctl),
-    HYPERCALL(tmem_op)
+    HYPERCALL(tmem_op),
+    HYPERCALL(v4v_op)
 };
=20
 #define COMPAT_CALL(x)                                        \
@@ -3259,7 +3260,8 @@ static hvm_hypercall_t *const hvm_hypercall32_table=
[NR_hypercalls] =3D {
     COMPAT_CALL(set_timer_op),
     HYPERCALL(hvm_op),
     HYPERCALL(sysctl),
-    HYPERCALL(tmem_op)
+    HYPERCALL(tmem_op),
+    HYPERCALL(v4v_op)
 };
=20
 int hvm_do_hypercall(struct cpu_user_regs *regs)
diff --git a/xen/arch/x86/x86_64/compat/entry.S b/xen/arch/x86/x86_64/com=
pat/entry.S
index e6b52f3..4902c4f 100644
--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -414,6 +414,7 @@ ENTRY(compat_hypercall_table)
         .quad do_domctl
         .quad compat_kexec_op
         .quad do_tmem_op
+        .quad do_v4v_op
         .rept __HYPERVISOR_arch_0-((.-compat_hypercall_table)/8)
         .quad compat_ni_hypercall
         .endr
@@ -462,6 +463,7 @@ ENTRY(compat_hypercall_args_table)
         .byte 1 /* do_domctl                */
         .byte 2 /* compat_kexec_op          */
         .byte 1 /* do_tmem_op               */
+        .byte 5 /* do_v4v_op		    */
         .rept __HYPERVISOR_arch_0-(.-compat_hypercall_args_table)
         .byte 0 /* compat_ni_hypercall      */
         .endr
diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S
index ffb9314..78006cf 100644
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -707,6 +707,7 @@ ENTRY(hypercall_table)
         .quad do_domctl
         .quad do_kexec_op
         .quad do_tmem_op
+        .quad do_v4v_op
         .rept __HYPERVISOR_arch_0-((.-hypercall_table)/8)
         .quad do_ni_hypercall
         .endr
@@ -755,6 +756,7 @@ ENTRY(hypercall_args_table)
         .byte 1 /* do_domctl            */
         .byte 2 /* do_kexec             */
         .byte 1 /* do_tmem_op           */
+        .byte 5 /* do_v4v_op		*/
         .rept __HYPERVISOR_arch_0-(.-hypercall_args_table)
         .byte 0 /* do_ni_hypercall      */
         .endr
diff --git a/xen/common/Makefile b/xen/common/Makefile
index c1c100f..ba63cec 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -45,6 +45,7 @@ obj-y +=3D tmem_xen.o
 obj-y +=3D radix-tree.o
 obj-y +=3D rbtree.o
 obj-y +=3D lzo.o
+obj-y +=3D v4v.o
=20
 obj-bin-$(CONFIG_X86) +=3D $(foreach n,decompress bunzip2 unxz unlzma un=
lzo,$(n).init.o)
=20
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 0e3e36a..60cd8e3 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -195,7 +195,8 @@ struct domain *domain_create(
 {
     struct domain *d, **pd;
     enum { INIT_xsm =3D 1u<<0, INIT_watchdog =3D 1u<<1, INIT_rangeset =3D=
 1u<<2,
-           INIT_evtchn =3D 1u<<3, INIT_gnttab =3D 1u<<4, INIT_arch =3D 1=
u<<5 };
+           INIT_evtchn =3D 1u<<3, INIT_gnttab =3D 1u<<4, INIT_arch =3D 1=
u<<5,
+           INIT_v4v =3D 1u<<6 };
     int err, init_status =3D 0;
     int poolid =3D CPUPOOLID_NONE;
=20
@@ -307,6 +308,13 @@ struct domain *domain_create(
         spin_unlock(&domlist_update_lock);
     }
=20
+    if ( !is_idle_domain(d) )
+    {
+        if ( v4v_init(d) !=3D 0 )
+            goto fail;
+        init_status |=3D INIT_v4v;
+    }
+
     return d;
=20
  fail:
@@ -315,6 +323,8 @@ struct domain *domain_create(
     xfree(d->mem_event);
     if ( init_status & INIT_arch )
         arch_domain_destroy(d);
+    if ( init_status & INIT_v4v )
+	v4v_destroy(d);
     if ( init_status & INIT_gnttab )
         grant_table_destroy(d);
     if ( init_status & INIT_evtchn )
@@ -489,6 +499,7 @@ int domain_kill(struct domain *d)
         domain_pause(d);
         d->is_dying =3D DOMDYING_dying;
         spin_barrier(&d->domain_lock);
+        v4v_destroy(d);
         evtchn_destroy(d);
         gnttab_release_mappings(d);
         tmem_destroy(d->tmem);
diff --git a/xen/common/v4v.c b/xen/common/v4v.c
new file mode 100644
index 0000000..404ae3d
--- /dev/null
+++ b/xen/common/v4v.c
@@ -0,0 +1,1922 @@
+/***********************************************************************=
*******
+ * V4V
+ *
+ * Version 2 of v2v (Virtual-to-Virtual)
+ *
+ * Copyright (c) 2010, Citrix Systems
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 =
 USA
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DEFINE_XEN_GUEST_HANDLE(v4v_iov_t);
+DEFINE_XEN_GUEST_HANDLE(v4v_addr_t);
+DEFINE_XEN_GUEST_HANDLE(v4v_send_addr_t);
+DEFINE_XEN_GUEST_HANDLE(v4v_ring_t);
+DEFINE_XEN_GUEST_HANDLE(v4v_ring_data_ent_t);
+DEFINE_XEN_GUEST_HANDLE(v4v_ring_data_t);
+DEFINE_XEN_GUEST_HANDLE(v4v_info_t);
+DEFINE_XEN_GUEST_HANDLE(v4v_pfn_t);
+DEFINE_XEN_GUEST_HANDLE(v4vtables_rule_t);
+DEFINE_XEN_GUEST_HANDLE(v4vtables_list_t);
+DEFINE_XEN_GUEST_HANDLE(uint8_t);
+
+struct v4v_pending_ent
+{
+    struct hlist_node node;
+    domid_t id;
+    uint32_t len;
+};
+
+typedef struct v4vtables_rule_node
+{
+    struct list_head list;
+    v4vtables_rule_t rule;
+} v4vtables_rule_node_t;
+
+struct v4v_ring_info
+{
+    /* next node in the hash, protected by L2  */
+    struct hlist_node node;
+    /* this ring's id, protected by L2 */
+    v4v_ring_id_t id;
+    /* L3 */
+    spinlock_t lock;
+    /* cached length of the ring (from ring->len), protected by L3 */
+    uint32_t len;
+    uint32_t npage;
+    /* cached tx pointer location, protected by L3 */
+    uint32_t tx_ptr;
+    /* guest ring, protected by L3 */
+    XEN_GUEST_HANDLE(v4v_ring_t) ring;
+    /* mapped ring pages protected by L3*/
+    uint8_t **mfn_mapping;
+    /* list of mfns of guest ring */
+    mfn_t *mfns;
+    /* list of struct v4v_pending_ent for this ring, L3 */
+    struct hlist_head pending;
+};
+
+/*
+ * The value of the v4v element in a struct domain is
+ * protected by the global lock L1
+ */
+#define V4V_HTABLE_SIZE 32
+struct v4v_domain
+{
+    /* L2 */
+    rwlock_t lock;
+    /* event channel */
+    evtchn_port_t evtchn_port;
+    /* protected by L2 */
+    struct hlist_head ring_hash[V4V_HTABLE_SIZE];
+};
+
+/*
+ * Messages on the ring are padded to 128 bits
+ * Len here refers to the exact length of the data not including the
+ * 128 bit header. The message uses
+ * ((len +0xf) & ~0xf) + sizeof(v4v_ring_message_header) bytes
+ */
+#define V4V_ROUNDUP(a) (((a) +0xf ) & ~0xf)
+
+/*
+ * Helper functions
+ */
+
+static inline uint16_t
+v4v_hash_fn(v4v_ring_id_t *id)
+{
+    uint16_t ret;
+    ret =3D (uint16_t)(id->addr.port >> 16);
+    ret ^=3D (uint16_t)id->addr.port;
+    ret ^=3D id->addr.domain;
+    ret ^=3D id->partner;
+
+    ret &=3D (V4V_HTABLE_SIZE - 1);
+
+    return ret;
+}
+
+static struct v4v_ring_info *v4v_ring_find_info(struct domain *d,
+                                                v4v_ring_id_t *id);
+
+static struct v4v_ring_info *v4v_ring_find_info_by_addr(struct domain *d=
,
+                                                        struct v4v_addr =
*a,
+                                                        domid_t p);
+
+struct list_head v4vtables_rules =3D LIST_HEAD_INIT(v4vtables_rules);
+
+/*
+ * locks
+ */
+
+/*
+ * locking is organized as follows:
+ *
+ * the global lock v4v_lock: L1 protects the v4v elements
+ * of all struct domain *d in the system, it does not
+ * protect any of the elements of d->v4v, just their
+ * addresses. By extension since the destruction of
+ * a domain with a non-NULL d->v4v will need to free
+ * the d->v4v pointer, holding this lock gauruntees
+ * that no domains pointers in which v4v is interested
+ * become invalid whilst this lock is held.
+ */
+
+static DEFINE_RWLOCK(v4v_lock); /* L1 */
+
+/*
+ * the lock d->v4v->lock: L2:  Read on protects the hash table and
+ * the elements in the hash_table d->v4v->ring_hash, and
+ * the node and id fields in struct v4v_ring_info in the
+ * hash table. Write on L2 protects all of the elements of
+ * struct v4v_ring_info. To take L2 you must already have R(L1)
+ * W(L1) implies W(L2) and L3
+ *
+ * the lock v4v_ring_info *ringinfo; ringinfo->lock: L3:
+ * protects len,tx_ptr the guest ring, the
+ * guest ring_data and the pending list. To take L3 you must
+ * already have R(L2). W(L2) implies L3
+ */
+
+/*
+ * lock to protect the filtering rules list: v4vtable_rules
+ *
+ * The write lock is held for viptables_del and viptables_add
+ * The read lock is held for viptable_list
+ */
+static DEFINE_RWLOCK(v4vtables_rules_lock);
+
+
+/*
+ * Debugs
+ */
+
+#ifdef V4V_DEBUG
+#define v4v_dprintk(format, args...)            \
+    do {                                        \
+        printk("%s:%d " format,                 \
+               __FILE__, __LINE__, ## args );   \
+    } while ( 1 =3D=3D 0 )
+#else
+#define v4v_dprintk(format, ... ) (void)0
+#endif
+
+#ifdef V4V_DEBUG
+static void __attribute__((unused))
+v4v_hexdump(void *_p, int len)
+{
+    uint8_t *buf =3D (uint8_t *)_p;
+    int i, j;
+
+    for ( i =3D 0; i < len; i +=3D 16 )
+    {
+        printk(KERN_ERR "%p:", &buf[i]);
+        for ( j =3D 0; j < 16; ++j )
+        {
+            int k =3D i + j;
+            if ( k < len )
+                printk(" %02x", buf[k]);
+            else
+                printk("   ");
+        }
+        printk(" ");
+
+        for ( j =3D 0; j < 16; ++j )
+        {
+            int k =3D i + j;
+            if ( k < len )
+                printk("%c", ((buf[k] > 32) && (buf[k] < 127)) ? buf[k] =
: '.');
+            else
+                printk(" ");
+        }
+        printk("\n");
+    }
+}
+#endif
+
+
+/*
+ * Event channel
+ */
+
+static void
+v4v_signal_domain(struct domain *d)
+{
+    v4v_dprintk("send guest VIRQ_V4V domid:%d\n", d->domain_id);
+
+    evtchn_send(d, d->v4v->evtchn_port);
+}
+
+static void
+v4v_signal_domid(domid_t id)
+{
+    struct domain *d =3D get_domain_by_id(id);
+    if ( !d )
+        return;
+    v4v_signal_domain(d);
+    put_domain(d);
+}
+
+
+/*
+ * ring buffer
+ */
+
+static void
+v4v_ring_unmap(struct v4v_ring_info *ring_info)
+{
+    int i;
+
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    for ( i =3D 0; i < ring_info->npage; ++i )
+    {
+        if ( !ring_info->mfn_mapping[i] )
+            continue;
+        v4v_dprintk("unmapping page %p from %p\n",
+                    (void*)mfn_x(ring_info->mfns[i]),
+                    ring_info->mfn_mapping[i]);
+
+        unmap_domain_page(ring_info->mfn_mapping[i]);
+        ring_info->mfn_mapping[i] =3D NULL;
+    }
+}
+
+static uint8_t *
+v4v_ring_map_page(struct v4v_ring_info *ring_info, int i)
+{
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    if ( i >=3D ring_info->npage )
+        return NULL;
+    if ( ring_info->mfn_mapping[i] )
+        return ring_info->mfn_mapping[i];
+    ring_info->mfn_mapping[i] =3D map_domain_page(mfn_x(ring_info->mfns[=
i]));
+
+    v4v_dprintk("mapping page %p to %p\n",
+                (void *)mfn_x(ring_info->mfns[i]),
+                ring_info->mfn_mapping[i]);
+    return ring_info->mfn_mapping[i];
+}
+
+static int
+v4v_memcpy_from_guest_ring(void *_dst, struct v4v_ring_info *ring_info,
+                           uint32_t offset, uint32_t len)
+{
+    int page =3D offset >> PAGE_SHIFT;
+    uint8_t *src;
+    uint8_t *dst =3D _dst;
+
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    offset &=3D PAGE_SIZE - 1;
+
+    while ( (offset + len) > PAGE_SIZE )
+    {
+        src =3D v4v_ring_map_page(ring_info, page);
+
+        if ( !src )
+            return -EFAULT;
+
+        v4v_dprintk("memcpy(%p,%p+%d,%d)\n",
+                    dst, src, offset,
+                    (int)(PAGE_SIZE - offset));
+        memcpy(dst, src + offset, PAGE_SIZE - offset);
+
+        page++;
+        len -=3D PAGE_SIZE - offset;
+        dst +=3D PAGE_SIZE - offset;
+        offset =3D 0;
+    }
+
+    src =3D v4v_ring_map_page(ring_info, page);
+    if ( !src )
+        return -EFAULT;
+
+    v4v_dprintk("memcpy(%p,%p+%d,%d)\n", dst, src, offset, len);
+    memcpy(dst, src + offset, len);
+
+    return 0;
+}
+
+static int
+v4v_update_tx_ptr(struct v4v_ring_info *ring_info, uint32_t tx_ptr)
+{
+    uint8_t *dst =3D v4v_ring_map_page(ring_info, 0);
+    uint32_t *p =3D (uint32_t *)(dst + offsetof(v4v_ring_t, tx_ptr));
+
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    if ( !dst )
+        return -EFAULT;
+    write_atomic(p, tx_ptr);
+    mb();
+    return 0;
+}
+
+static int
+v4v_copy_from_guest_maybe(void *dst, void *src,
+                          XEN_GUEST_HANDLE(uint8_t) src_hnd,
+                          uint32_t len)
+{
+    int rc =3D 0;
+
+    if ( src )
+        memcpy(dst, src, len);
+    else
+        rc =3D __copy_from_guest(dst, src_hnd, len);
+    return rc;
+}
+
+static int
+v4v_memcpy_to_guest_ring(struct v4v_ring_info *ring_info,
+                         uint32_t offset,
+                         void *src,
+                         XEN_GUEST_HANDLE(uint8_t) src_hnd,
+                         uint32_t len)
+{
+    int page =3D offset >> PAGE_SHIFT;
+    uint8_t *dst;
+
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    offset &=3D PAGE_SIZE - 1;
+
+    while ( (offset + len) > PAGE_SIZE )
+    {
+        dst =3D v4v_ring_map_page(ring_info, page);
+        if ( !dst )
+            return -EFAULT;
+
+        if ( v4v_copy_from_guest_maybe(dst + offset, src, src_hnd,
+                                       PAGE_SIZE - offset) )
+            return -EFAULT;
+
+        page++;
+        len -=3D PAGE_SIZE - offset;
+        if ( src )
+            src +=3D (PAGE_SIZE - offset);
+        else
+            guest_handle_add_offset(src_hnd, PAGE_SIZE - offset);
+        offset =3D 0;
+    }
+
+    dst =3D v4v_ring_map_page(ring_info, page);
+    if ( !dst )
+        return -EFAULT;
+
+    if ( v4v_copy_from_guest_maybe(dst + offset, src, src_hnd, len) )
+        return -EFAULT;
+
+    return 0;
+}
+
+static int
+v4v_ringbuf_get_rx_ptr(struct domain *d, struct v4v_ring_info *ring_info=
,
+                        uint32_t * rx_ptr)
+{
+    v4v_ring_t *ringp;
+
+    if ( ring_info->npage =3D=3D 0 )
+        return -1;
+
+    ringp =3D map_domain_page(mfn_x(ring_info->mfns[0]));
+
+    v4v_dprintk("v4v_ringbuf_payload_space: mapped %p to %p\n",
+                (void *)mfn_x(ring_info->mfns[0]), ringp);
+    if ( !ringp )
+        return -1;
+
+    write_atomic(rx_ptr, ringp->rx_ptr);
+    mb();
+
+    unmap_domain_page(mfn_x(ring_info->mfns[0]));
+    return 0;
+}
+
+uint32_t
+v4v_ringbuf_payload_space(struct domain * d, struct v4v_ring_info * ring=
_info)
+{
+    v4v_ring_t ring;
+    int32_t ret;
+
+    ring.tx_ptr =3D ring_info->tx_ptr;
+    ring.len =3D ring_info->len;
+
+    if ( v4v_ringbuf_get_rx_ptr(d, ring_info, &ring.rx_ptr) )
+        return 0;
+
+    v4v_dprintk("v4v_ringbuf_payload_space:tx_ptr=3D%d rx_ptr=3D%d\n",
+                (int)ring.tx_ptr, (int)ring.rx_ptr);
+    if ( ring.rx_ptr =3D=3D ring.tx_ptr )
+        return ring.len - sizeof (struct v4v_ring_message_header);
+
+    ret =3D ring.rx_ptr - ring.tx_ptr;
+    if ( ret < 0 )
+        ret +=3D ring.len;
+
+    ret -=3D sizeof (struct v4v_ring_message_header);
+    ret -=3D V4V_ROUNDUP(1);
+
+    return (ret < 0) ? 0 : ret;
+}
+
+static long
+v4v_iov_count(XEN_GUEST_HANDLE(v4v_iov_t) iovs, int niov)
+{
+    v4v_iov_t iov;
+    size_t ret =3D 0;
+
+    while ( niov-- )
+    {
+        if ( copy_from_guest(&iov, iovs, 1) )
+            return -EFAULT;
+
+        ret +=3D iov.iov_len;
+
+        /* message bigger than 2G can't be sent */
+        if (ret > 2L * 1024 * 1024 * 1024)
+            return -EMSGSIZE;
+
+        guest_handle_add_offset(iovs, 1);
+    }
+
+    return ret;
+}
+
+static long
+v4v_ringbuf_insertv(struct domain *d,
+                    struct v4v_ring_info *ring_info,
+                    v4v_ring_id_t *src_id, uint32_t proto,
+                    XEN_GUEST_HANDLE(v4v_iov_t) iovs, uint32_t niov,
+                    size_t len)
+{
+    v4v_ring_t ring;
+    struct v4v_ring_message_header mh =3D { 0 };
+    int32_t sp;
+    long happy_ret;
+    int32_t ret =3D 0;
+    XEN_GUEST_HANDLE(uint8_t) empty_hnd =3D { 0 };
+
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    happy_ret =3D len;
+
+    if ( (V4V_ROUNDUP(len) + sizeof (struct v4v_ring_message_header) ) >=
=3D
+            ring_info->len)
+        return -EMSGSIZE;
+
+    do
+    {
+        if ( (ret =3D v4v_memcpy_from_guest_ring(&ring, ring_info, 0,
+                                               sizeof (ring))) )
+            break;
+
+        ring.tx_ptr =3D ring_info->tx_ptr;
+        ring.len =3D ring_info->len;
+
+        v4v_dprintk("ring.tx_ptr=3D%d ring.rx_ptr=3D%d ring.len=3D%d rin=
g_info->tx_ptr=3D%d\n",
+                    ring.tx_ptr, ring.rx_ptr, ring.len, ring_info->tx_pt=
r);
+
+        if ( ring.rx_ptr =3D=3D ring.tx_ptr )
+            sp =3D ring_info->len;
+        else
+        {
+            sp =3D ring.rx_ptr - ring.tx_ptr;
+            if ( sp < 0 )
+                sp +=3D ring.len;
+        }
+
+        if ( (V4V_ROUNDUP(len) + sizeof (struct v4v_ring_message_header)=
) >=3D sp )
+        {
+            v4v_dprintk("EAGAIN\n");
+            ret =3D -EAGAIN;
+            break;
+        }
+
+        mh.len =3D len + sizeof (struct v4v_ring_message_header);
+        mh.source =3D src_id->addr;
+        mh.message_type =3D proto;
+
+        if ( (ret =3D v4v_memcpy_to_guest_ring(ring_info,
+                                             ring.tx_ptr + sizeof (v4v_r=
ing_t),
+                                             &mh, empty_hnd,
+                                             sizeof (mh))) )
+            break;
+
+        ring.tx_ptr +=3D sizeof (mh);
+        if ( ring.tx_ptr =3D=3D ring_info->len )
+            ring.tx_ptr =3D 0;
+
+        while ( niov-- )
+        {
+            XEN_GUEST_HANDLE(uint8_t) buf_hnd;
+            v4v_iov_t iov;
+
+            if ( copy_from_guest(&iov, iovs, 1) )
+            {
+                ret =3D -EFAULT;
+                break;
+            }
+
+            buf_hnd.p =3D (uint8_t *)iov.iov_base; //FIXME
+            len =3D iov.iov_len;
+
+            if ( unlikely(!guest_handle_okay(buf_hnd, len)) )
+            {
+                ret =3D -EFAULT;
+                break;
+            }
+
+            sp =3D ring.len - ring.tx_ptr;
+
+            if ( len > sp )
+            {
+                ret =3D v4v_memcpy_to_guest_ring(ring_info,
+                        ring.tx_ptr + sizeof (v4v_ring_t),
+                        NULL, buf_hnd, sp);
+                if ( ret )
+                    break;
+
+                ring.tx_ptr =3D 0;
+                len -=3D sp;
+                guest_handle_add_offset(buf_hnd, sp);
+            }
+
+            ret =3D v4v_memcpy_to_guest_ring(ring_info,
+                    ring.tx_ptr + sizeof (v4v_ring_t),
+                    NULL, buf_hnd, len);
+            if ( ret )
+                break;
+
+            ring.tx_ptr +=3D len;
+
+            if ( ring.tx_ptr =3D=3D ring_info->len )
+                ring.tx_ptr =3D 0;
+
+            guest_handle_add_offset(iovs, 1);
+        }
+        if ( ret )
+            break;
+
+        ring.tx_ptr =3D V4V_ROUNDUP(ring.tx_ptr);
+
+        if ( ring.tx_ptr >=3D ring_info->len )
+            ring.tx_ptr -=3D ring_info->len;
+
+        mb();
+        ring_info->tx_ptr =3D ring.tx_ptr;
+        if ( (ret =3D v4v_update_tx_ptr(ring_info, ring.tx_ptr)) )
+            break;
+    }
+    while ( 0 );
+
+    v4v_ring_unmap(ring_info);
+
+    return ret ? ret : happy_ret;
+}
+
+
+
+/* pending */
+static void
+v4v_pending_remove_ent(struct v4v_pending_ent *ent)
+{
+    hlist_del(&ent->node);
+    xfree(ent);
+}
+
+static void
+v4v_pending_remove_all(struct v4v_ring_info *info)
+{
+    struct hlist_node *node, *next;
+    struct v4v_pending_ent *pending_ent;
+
+    ASSERT(spin_is_locked(&info->lock));
+    hlist_for_each_entry_safe(pending_ent, node, next, &info->pending,
+            node) v4v_pending_remove_ent(pending_ent);
+}
+
+static void
+v4v_pending_notify(struct domain *caller_d, struct hlist_head *to_notify=
)
+{
+    struct hlist_node *node, *next;
+    struct v4v_pending_ent *pending_ent;
+
+    ASSERT(rw_is_locked(&v4v_lock));
+
+    hlist_for_each_entry_safe(pending_ent, node, next, to_notify, node)
+    {
+        hlist_del(&pending_ent->node);
+        v4v_signal_domid(pending_ent->id);
+        xfree(pending_ent);
+    }
+
+}
+
+static void
+v4v_pending_find(struct domain *d, struct v4v_ring_info *ring_info,
+                 uint32_t payload_space, struct hlist_head *to_notify)
+{
+    struct hlist_node *node, *next;
+    struct v4v_pending_ent *ent;
+
+    ASSERT(rw_is_locked(&d->v4v->lock));
+
+    spin_lock(&ring_info->lock);
+    hlist_for_each_entry_safe(ent, node, next, &ring_info->pending, node=
)
+    {
+        if ( payload_space >=3D ent->len )
+        {
+            hlist_del(&ent->node);
+            hlist_add_head(&ent->node, to_notify);
+        }
+    }
+    spin_unlock(&ring_info->lock);
+}
+
+/*caller must have L3 */
+static int
+v4v_pending_queue(struct v4v_ring_info *ring_info, domid_t src_id, int l=
en)
+{
+    struct v4v_pending_ent *ent =3D xmalloc(struct v4v_pending_ent);
+
+    if ( !ent )
+    {
+        v4v_dprintk("ENOMEM\n");
+        return -ENOMEM;
+    }
+
+    ent->len =3D len;
+    ent->id =3D src_id;
+
+    hlist_add_head(&ent->node, &ring_info->pending);
+
+    return 0;
+}
+
+/* L3 */
+static int
+v4v_pending_requeue(struct v4v_ring_info *ring_info, domid_t src_id, int=
 len)
+{
+    struct hlist_node *node;
+    struct v4v_pending_ent *ent;
+
+    hlist_for_each_entry(ent, node, &ring_info->pending, node)
+    {
+        if ( ent->id =3D=3D src_id )
+        {
+            if ( ent->len < len )
+                ent->len =3D len;
+            return 0;
+        }
+    }
+
+    return v4v_pending_queue(ring_info, src_id, len);
+}
+
+
+/* L3 */
+static void
+v4v_pending_cancel(struct v4v_ring_info *ring_info, domid_t src_id)
+{
+    struct hlist_node *node, *next;
+    struct v4v_pending_ent *ent;
+
+    hlist_for_each_entry_safe(ent, node, next, &ring_info->pending, node=
)
+    {
+        if ( ent->id =3D=3D src_id)
+        {
+            hlist_del(&ent->node);
+            xfree(ent);
+        }
+    }
+}
+
+/*
+ * ring data
+ */
+
+/*Caller should hold R(L1)*/
+static int
+v4v_fill_ring_data(struct domain *src_d,
+                   XEN_GUEST_HANDLE(v4v_ring_data_ent_t) data_ent_hnd)
+{
+    v4v_ring_data_ent_t ent;
+    struct domain *dst_d;
+    struct v4v_ring_info *ring_info;
+
+    if ( copy_from_guest(&ent, data_ent_hnd, 1) )
+    {
+        v4v_dprintk("EFAULT\n");
+        return -EFAULT;
+    }
+
+    v4v_dprintk("v4v_fill_ring_data: ent.ring.domain=3D%d,ent.ring.port=3D=
%u\n",
+                (int)ent.ring.domain, (int)ent.ring.port);
+
+    ent.flags =3D 0;
+
+    dst_d =3D get_domain_by_id(ent.ring.domain);
+
+    if ( dst_d && dst_d->v4v )
+    {
+        read_lock(&dst_d->v4v->lock);
+        ring_info =3D v4v_ring_find_info_by_addr(dst_d, &ent.ring,
+                                               src_d->domain_id);
+
+        if ( ring_info )
+        {
+            uint32_t space_avail;
+
+            ent.flags |=3D V4V_RING_DATA_F_EXISTS;
+            ent.max_message_size =3D
+                ring_info->len - sizeof (struct v4v_ring_message_header)=
 -
+                V4V_ROUNDUP(1);
+            spin_lock(&ring_info->lock);
+
+            space_avail =3D v4v_ringbuf_payload_space(dst_d, ring_info);
+
+            if ( space_avail >=3D ent.space_required )
+            {
+                v4v_pending_cancel(ring_info, src_d->domain_id);
+                ent.flags |=3D V4V_RING_DATA_F_SUFFICIENT;
+            }
+            else
+            {
+                v4v_pending_requeue(ring_info, src_d->domain_id,
+                        ent.space_required);
+                ent.flags |=3D V4V_RING_DATA_F_PENDING;
+            }
+
+            spin_unlock(&ring_info->lock);
+
+            if ( space_avail =3D=3D ent.max_message_size )
+                ent.flags |=3D V4V_RING_DATA_F_EMPTY;
+
+        }
+        read_unlock(&dst_d->v4v->lock);
+    }
+
+    if ( dst_d )
+        put_domain(dst_d);
+
+    if ( copy_field_to_guest(data_ent_hnd, &ent, flags) )
+    {
+        v4v_dprintk("EFAULT\n");
+        return -EFAULT;
+    }
+    return 0;
+}
+
+/*Called should hold no more than R(L1) */
+static int
+v4v_fill_ring_datas(struct domain *d, int nent,
+                     XEN_GUEST_HANDLE(v4v_ring_data_ent_t) data_ent_hnd)
+{
+    int ret =3D 0;
+
+    read_lock(&v4v_lock);
+    while ( !ret && nent-- )
+    {
+        ret =3D v4v_fill_ring_data(d, data_ent_hnd);
+        guest_handle_add_offset(data_ent_hnd, 1);
+    }
+    read_unlock(&v4v_lock);
+    return ret;
+}
+
+/*
+ * ring
+ */
+static int
+v4v_find_ring_mfns(struct domain *d, struct v4v_ring_info *ring_info,
+                   uint32_t npage, XEN_GUEST_HANDLE(v4v_pfn_t) pfn_hnd)
+{
+    int i,j;
+    mfn_t *mfns;
+    uint8_t **mfn_mapping;
+    unsigned long mfn;
+    struct page_info *page;
+    int ret =3D 0;
+
+    if ( (npage << PAGE_SHIFT) < ring_info->len )
+    {
+        v4v_dprintk("EINVAL\n");
+        return -EINVAL;
+    }
+
+    mfns =3D xmalloc_array(mfn_t, npage);
+    if ( !mfns )
+    {
+        v4v_dprintk("ENOMEM\n");
+        return -ENOMEM;
+    }
+
+    mfn_mapping =3D xmalloc_array(uint8_t *, npage);
+    if ( !mfn_mapping )
+    {
+        xfree(mfns);
+        return -ENOMEM;
+    }
+
+    for ( i =3D 0; i < npage; ++i )
+    {
+        unsigned long pfn;
+        p2m_type_t p2mt;
+
+        if ( copy_from_guest_offset(&pfn, pfn_hnd, i, 1) )
+        {
+            ret =3D -EFAULT;
+            v4v_dprintk("EFAULT\n");
+            break;
+        }
+
+        mfn =3D mfn_x(get_gfn(d, pfn, &p2mt));
+        if ( !mfn_valid(mfn) )
+        {
+            printk(KERN_ERR "v4v domain %d passed invalid mfn %"PRI_mfn"=
 ring %p seq %d\n",
+                    d->domain_id, mfn, ring_info, i);
+            ret =3D -EINVAL;
+            break;
+        }
+        page =3D mfn_to_page(mfn);
+        if ( !get_page_and_type(page, d, PGT_writable_page) )
+        {
+            printk(KERN_ERR "v4v domain %d passed wrong type mfn %"PRI_m=
fn" ring %p seq %d\n",
+                    d->domain_id, mfn, ring_info, i);
+            ret =3D -EINVAL;
+            break;
+        }
+        mfns[i] =3D _mfn(mfn);
+        v4v_dprintk("v4v_find_ring_mfns: %d: %lx -> %lx\n",
+                    i, (unsigned long)pfn, (unsigned long)mfn_x(mfns[i])=
);
+        mfn_mapping[i] =3D NULL;
+        put_gfn(d, pfn);
+    }
+
+    if ( !ret )
+    {
+        ring_info->npage =3D npage;
+        ring_info->mfns =3D mfns;
+        ring_info->mfn_mapping =3D mfn_mapping;
+    }
+    else
+    {
+        j =3D i;
+        for ( i =3D 0; i < j; ++i )
+            if ( mfn_x(mfns[i]) !=3D 0 )
+                put_page_and_type(mfn_to_page(mfn_x(mfns[i])));
+        xfree(mfn_mapping);
+        xfree(mfns);
+    }
+    return ret;
+}
+
+
+static struct v4v_ring_info *
+v4v_ring_find_info(struct domain *d, v4v_ring_id_t *id)
+{
+    uint16_t hash;
+    struct hlist_node *node;
+    struct v4v_ring_info *ring_info;
+
+    ASSERT(rw_is_locked(&d->v4v->lock));
+
+    hash =3D v4v_hash_fn(id);
+
+    v4v_dprintk("ring_find_info: d->v4v=3D%p, d->v4v->ring_hash[%d]=3D%p=
 id=3D%p\n",
+                d->v4v, (int)hash, d->v4v->ring_hash[hash].first, id);
+    v4v_dprintk("ring_find_info: id.addr.port=3D%d id.addr.domain=3D%d i=
d.addr.partner=3D%d\n",
+                id->addr.port, id->addr.domain, id->partner);
+
+    hlist_for_each_entry(ring_info, node, &d->v4v->ring_hash[hash], node=
)
+    {
+        v4v_ring_id_t *cmpid =3D &ring_info->id;
+
+        if ( cmpid->addr.port =3D=3D id->addr.port &&
+             cmpid->addr.domain =3D=3D id->addr.domain &&
+             cmpid->partner =3D=3D id->partner)
+        {
+            v4v_dprintk("ring_find_info: ring_info=3D%p\n", ring_info);
+            return ring_info;
+        }
+    }
+    v4v_dprintk("ring_find_info: no ring_info found\n");
+    return NULL;
+}
+
+static struct v4v_ring_info *
+v4v_ring_find_info_by_addr(struct domain *d, struct v4v_addr *a, domid_t=
 p)
+{
+    v4v_ring_id_t id;
+    struct v4v_ring_info *ret;
+
+    ASSERT(rw_is_locked(&d->v4v->lock));
+
+    if ( !a )
+        return NULL;
+
+    id.addr.port =3D a->port;
+    id.addr.domain =3D d->domain_id;
+    id.partner =3D p;
+
+    ret =3D v4v_ring_find_info(d, &id);
+    if ( ret )
+        return ret;
+
+    id.partner =3D V4V_DOMID_ANY;
+
+    return v4v_ring_find_info(d, &id);
+}
+
+static void v4v_ring_remove_mfns(struct domain *d, struct v4v_ring_info =
*ring_info)
+{
+    int i;
+
+    ASSERT(rw_is_write_locked(&d->v4v->lock));
+
+    if ( ring_info->mfns )
+    {
+        for ( i =3D 0; i < ring_info->npage; ++i )
+            if ( mfn_x(ring_info->mfns[i]) !=3D 0 )
+                put_page_and_type(mfn_to_page(mfn_x(ring_info->mfns[i]))=
);
+        xfree(ring_info->mfns);
+    }
+    if ( ring_info->mfn_mapping )
+        xfree(ring_info->mfn_mapping);
+    ring_info->mfns =3D NULL;
+
+}
+
+static void
+v4v_ring_remove_info(struct domain *d, struct v4v_ring_info *ring_info)
+{
+    ASSERT(rw_is_write_locked(&d->v4v->lock));
+
+    spin_lock(&ring_info->lock);
+
+    v4v_pending_remove_all(ring_info);
+    hlist_del(&ring_info->node);
+    v4v_ring_remove_mfns(d, ring_info);
+
+    spin_unlock(&ring_info->lock);
+
+    xfree(ring_info);
+}
+
+/* Call from guest to unpublish a ring */
+static long
+v4v_ring_remove(struct domain *d, XEN_GUEST_HANDLE(v4v_ring_t) ring_hnd)
+{
+    struct v4v_ring ring;
+    struct v4v_ring_info *ring_info;
+    int ret =3D 0;
+
+    read_lock(&v4v_lock);
+
+    do
+    {
+        if ( !d->v4v )
+        {
+            v4v_dprintk("EINVAL\n");
+            ret =3D -EINVAL;
+            break;
+        }
+
+        if ( copy_from_guest(&ring, ring_hnd, 1) )
+        {
+            v4v_dprintk("EFAULT\n");
+            ret =3D -EFAULT;
+            break;
+        }
+
+        if ( ring.magic !=3D V4V_RING_MAGIC )
+        {
+            v4v_dprintk("ring.magic(%"PRIx64") !=3D V4V_RING_MAGIC(%"PRI=
x64"), EINVAL\n",
+                    ring.magic, V4V_RING_MAGIC);
+            ret =3D -EINVAL;
+            break;
+        }
+
+        ring.id.addr.domain =3D d->domain_id;
+
+        write_lock(&d->v4v->lock);
+        ring_info =3D v4v_ring_find_info(d, &ring.id);
+
+        if ( ring_info )
+            v4v_ring_remove_info(d, ring_info);
+
+        write_unlock(&d->v4v->lock);
+
+        if ( !ring_info )
+        {
+            v4v_dprintk("ENOENT\n");
+            ret =3D -ENOENT;
+            break;
+        }
+
+    }
+    while ( 0 );
+
+    read_unlock(&v4v_lock);
+    return ret;
+}
+
+/* call from guest to publish a ring */
+static long
+v4v_ring_add(struct domain *d, XEN_GUEST_HANDLE(v4v_ring_t) ring_hnd,
+             uint32_t npage, XEN_GUEST_HANDLE(v4v_pfn_t) pfn_hnd)
+{
+    struct v4v_ring ring;
+    struct v4v_ring_info *ring_info;
+    int need_to_insert =3D 0;
+    int ret =3D 0;
+
+    if ( (long)ring_hnd.p & (PAGE_SIZE - 1) )
+    {
+        v4v_dprintk("EINVAL\n");
+        return -EINVAL;
+    }
+
+    read_lock(&v4v_lock);
+    do
+    {
+        if ( !d->v4v )
+        {
+            v4v_dprintk(" !d->v4v, EINVAL\n");
+            ret =3D -EINVAL;
+            break;
+        }
+
+        if ( copy_from_guest(&ring, ring_hnd, 1) )
+        {
+            v4v_dprintk(" copy_from_guest failed, EFAULT\n");
+            ret =3D -EFAULT;
+            break;
+        }
+
+        if ( ring.magic !=3D V4V_RING_MAGIC )
+        {
+            v4v_dprintk("ring.magic(%lx) !=3D V4V_RING_MAGIC(%lx), EINVA=
L\n",
+                        ring.magic, V4V_RING_MAGIC);
+            ret =3D -EINVAL;
+            break;
+        }
+
+        if ( (ring.len <
+                    (sizeof (struct v4v_ring_message_header) + V4V_ROUND=
UP(1) +
+                     V4V_ROUNDUP(1))) || (V4V_ROUNDUP(ring.len) !=3D rin=
g.len) )
+        {
+            v4v_dprintk("EINVAL\n");
+            ret =3D -EINVAL;
+            break;
+        }
+
+        ring.id.addr.domain =3D d->domain_id;
+        if ( copy_field_to_guest(ring_hnd, &ring, id) )
+        {
+            v4v_dprintk("EFAULT\n");
+            ret =3D -EFAULT;
+            break;
+        }
+
+        /*
+         * no need for a lock yet, because only we know about this
+         * set the tx pointer if it looks bogus (we don't reset it
+         * because this might be a re-register after S4)
+         */
+        if ( (ring.tx_ptr >=3D ring.len)
+                || (V4V_ROUNDUP(ring.tx_ptr) !=3D ring.tx_ptr) )
+        {
+            ring.tx_ptr =3D ring.rx_ptr;
+        }
+        copy_field_to_guest(ring_hnd, &ring, tx_ptr);
+
+        read_lock(&d->v4v->lock);
+        ring_info =3D v4v_ring_find_info(d, &ring.id);
+
+        if ( !ring_info )
+        {
+            read_unlock(&d->v4v->lock);
+            ring_info =3D xmalloc(struct v4v_ring_info);
+            if ( !ring_info )
+            {
+                v4v_dprintk("ENOMEM\n");
+                ret =3D -ENOMEM;
+                break;
+            }
+            need_to_insert++;
+            spin_lock_init(&ring_info->lock);
+            INIT_HLIST_HEAD(&ring_info->pending);
+            ring_info->mfns =3D NULL;
+
+        }
+        else
+        {
+            /*
+             * Ring info already existed.
+             */
+            printk(KERN_INFO "v4v: dom%d ring already registered\n",
+                    current->domain->domain_id);
+            ret =3D -EEXIST;
+            break;
+        }
+
+        spin_lock(&ring_info->lock);
+        ring_info->id =3D ring.id;
+        ring_info->len =3D ring.len;
+        ring_info->tx_ptr =3D ring.tx_ptr;
+        ring_info->ring =3D ring_hnd;
+        if ( ring_info->mfns )
+            xfree(ring_info->mfns);
+        ret =3D v4v_find_ring_mfns(d, ring_info, npage, pfn_hnd);
+        spin_unlock(&ring_info->lock);
+        if ( ret )
+            break;
+
+        if ( !need_to_insert )
+        {
+            read_unlock(&d->v4v->lock);
+        }
+        else
+        {
+            uint16_t hash =3D v4v_hash_fn(&ring.id);
+            write_lock(&d->v4v->lock);
+            hlist_add_head(&ring_info->node, &d->v4v->ring_hash[hash]);
+            write_unlock(&d->v4v->lock);
+        }
+    }
+    while ( 0 );
+
+    read_unlock(&v4v_lock);
+    return ret;
+}
+
+
+/*
+ * io
+ */
+
+static void
+v4v_notify_ring(struct domain *d, struct v4v_ring_info *ring_info,
+                struct hlist_head *to_notify)
+{
+    uint32_t space;
+
+    ASSERT(rw_is_locked(&v4v_lock));
+    ASSERT(rw_is_locked(&d->v4v->lock));
+
+    spin_lock(&ring_info->lock);
+    space =3D v4v_ringbuf_payload_space(d, ring_info);
+    spin_unlock(&ring_info->lock);
+
+    v4v_pending_find(d, ring_info, space, to_notify);
+}
+
+/*notify hypercall*/
+static long
+v4v_notify(struct domain *d,
+           XEN_GUEST_HANDLE(v4v_ring_data_t) ring_data_hnd)
+{
+    v4v_ring_data_t ring_data;
+    HLIST_HEAD(to_notify);
+    int i;
+    int ret =3D 0;
+
+    read_lock(&v4v_lock);
+
+    if ( !d->v4v )
+    {
+        read_unlock(&v4v_lock);
+        v4v_dprintk("!d->v4v, ENODEV\n");
+        return -ENODEV;
+    }
+
+    read_lock(&d->v4v->lock);
+    for ( i =3D 0; i < V4V_HTABLE_SIZE; ++i )
+    {
+        struct hlist_node *node, *next;
+        struct v4v_ring_info *ring_info;
+
+        hlist_for_each_entry_safe(ring_info, node,
+                next, &d->v4v->ring_hash[i],
+                node)
+        {
+            v4v_notify_ring(d, ring_info, &to_notify);
+        }
+    }
+    read_unlock(&d->v4v->lock);
+
+    if ( !hlist_empty(&to_notify) )
+        v4v_pending_notify(d, &to_notify);
+
+    do
+    {
+        if ( !guest_handle_is_null(ring_data_hnd) )
+        {
+            /* Quick sanity check on ring_data_hnd */
+            if ( copy_field_from_guest(&ring_data, ring_data_hnd, magic)=
 )
+            {
+                v4v_dprintk("copy_field_from_guest failed\n");
+                ret =3D -EFAULT;
+                break;
+            }
+
+            if ( ring_data.magic !=3D V4V_RING_DATA_MAGIC )
+            {
+                v4v_dprintk("ring.magic(%lx) !=3D V4V_RING_MAGIC(%lx), E=
INVAL\n",
+                        ring_data.magic, V4V_RING_MAGIC);
+                ret =3D -EINVAL;
+                break;
+            }
+
+            if ( copy_from_guest(&ring_data, ring_data_hnd, 1) )
+            {
+                v4v_dprintk("copy_from_guest failed\n");
+                ret =3D -EFAULT;
+                break;
+            }
+
+            {
+                XEN_GUEST_HANDLE(v4v_ring_data_ent_t) ring_data_ent_hnd;
+                ring_data_ent_hnd =3D
+                    guest_handle_for_field(ring_data_hnd, v4v_ring_data_=
ent_t, data[0]);
+                ret =3D v4v_fill_ring_datas(d, ring_data.nent, ring_data=
_ent_hnd);
+            }
+        }
+    }
+    while ( 0 );
+
+    read_unlock(&v4v_lock);
+
+    return ret;
+}
+
+#ifdef V4V_DEBUG
+void
+v4vtables_print_rule(struct v4vtables_rule_node *node)
+{
+    v4vtables_rule_t *rule;
+
+    if ( node =3D=3D NULL )
+    {
+        printk("(null)\n");
+        return;
+    }
+
+    rule =3D &node->rule;
+
+    if ( rule->accept =3D=3D 1 )
+        printk("ACCEPT");
+    else
+        printk("REJECT");
+
+    printk(" ");
+
+    if ( rule->src.domain =3D=3D V4V_DOMID_ANY )
+        printk("*");
+    else
+        printk("%i", rule->src.domain);
+
+    printk(":");
+
+    if ( rule->src.port =3D=3D -1 )
+        printk("*");
+    else
+        printk("%i", rule->src.port);
+
+    printk(" -> ");
+
+    if ( rule->dst.domain =3D=3D V4V_DOMID_ANY )
+        printk("*");
+    else
+        printk("%i", rule->dst.domain);
+
+    printk(":");
+
+    if ( rule->dst.port =3D=3D -1 )
+        printk("*");
+    else
+        printk("%i", rule->dst.port);
+
+    printk("\n");
+}
+#endif /* V4V_DEBUG */
+
+int
+v4vtables_add(struct domain *src_d,
+              XEN_GUEST_HANDLE(v4vtables_rule_t) rule,
+              int32_t position)
+{
+    struct v4vtables_rule_node* new =3D NULL;
+    struct list_head* tmp;
+
+    ASSERT(rw_is_write_locked(&v4vtables_rules_lock));
+
+    /* First rule is n.1 */
+    position--;
+
+    new =3D xmalloc(struct v4vtables_rule_node);
+    if ( new =3D=3D NULL )
+        return -ENOMEM;
+
+    if ( copy_from_guest(&new->rule, rule, 1) )
+    {
+        xfree(new);
+        return -EFAULT;
+    }
+
+#ifdef V4V_DEBUG
+    printk(KERN_ERR "VIPTables: ");
+    v4vtables_print_rule(new);
+#endif /* V4V_DEBUG */
+
+    tmp =3D &v4vtables_rules;
+    while ( position !=3D 0 && tmp->next !=3D &v4vtables_rules)
+    {
+        tmp =3D tmp->next;
+        position--;
+    }
+    list_add(&new->list, tmp);
+
+    return 0;
+}
+
+int
+v4vtables_del(struct domain *src_d,
+              XEN_GUEST_HANDLE(v4vtables_rule_t) rule_hnd,
+              int32_t position)
+{
+    struct list_head *tmp =3D NULL;
+    struct list_head *to_delete =3D NULL;
+    struct list_head *next =3D NULL;
+    struct v4vtables_rule_node *node;
+
+    ASSERT(rw_is_write_locked(&v4vtables_rules_lock));
+
+    v4v_dprintk("v4vtables_del position:%d\n", position);
+
+    if ( position !=3D -1 )
+    {
+        /* We want to delete the rule number  */
+        list_for_each(tmp, &v4vtables_rules)
+        {
+            to_delete =3D tmp;
+            if (position =3D=3D 0)
+                break;
+            position--;
+        }
+        /* Can't find the position */
+        if (position !=3D 0)
+            to_delete =3D NULL;
+    }
+    else if ( !guest_handle_is_null(rule_hnd) )
+    {
+        struct v4vtables_rule r;
+
+        if ( copy_from_guest(&r, rule_hnd, 1) )
+            return -EFAULT;
+
+        list_for_each(tmp, &v4vtables_rules)
+        {
+            node =3D list_entry(tmp, struct v4vtables_rule_node, list);
+
+            if ( (node->rule.src.domain =3D=3D r.src.domain) &&
+                 (node->rule.src.port   =3D=3D r.src.port)   &&
+                 (node->rule.dst.domain =3D=3D r.dst.domain) &&
+                 (node->rule.dst.port   =3D=3D r.dst.port))
+            {
+                to_delete =3D tmp;
+                break;
+            }
+        }
+    }
+    else
+    {
+        /* We want to flush the rules! */
+        printk(KERN_ERR "VIPTables: flushing rules\n");
+        list_for_each_safe(tmp, next, &v4vtables_rules)
+        {
+            node =3D list_entry(tmp, struct v4vtables_rule_node, list);
+            list_del(tmp);
+            xfree(node);
+        }
+    }
+
+    if ( to_delete )
+    {
+        node =3D list_entry(to_delete, struct v4vtables_rule_node, list)=
;
+#ifdef V4V_DEBUG
+        printk(KERN_ERR "VIPTables: deleting rule: ");
+        v4vtables_print_rule(node);
+#endif /* V4V_DEBUG */
+        list_del(to_delete);
+        xfree(node);
+    }
+
+    return 0;
+}
+
+static size_t
+v4vtables_list(struct domain *src_d,
+               XEN_GUEST_HANDLE(v4vtables_list_t) list_hnd)
+{
+    struct list_head *ptr;
+    struct v4vtables_rule_node *node;
+    struct v4vtables_list rules_list;
+    uint32_t nbrules;
+    XEN_GUEST_HANDLE(v4vtables_rule_t) guest_rules;
+
+    ASSERT(rw_is_locked(&v4vtables_rules_lock));
+
+    memset(&rules_list, 0, sizeof (rules_list));
+    if ( copy_from_guest(&rules_list, list_hnd, 1) )
+        return -EFAULT;
+
+    ptr =3D v4vtables_rules.next;
+    while ( rules_list.start_rule !=3D 0 && ptr->next !=3D &v4vtables_ru=
les )
+    {
+        ptr =3D ptr->next;
+        rules_list.start_rule--;
+    }
+
+    if ( rules_list.nb_rules =3D=3D 0 )
+        return -EINVAL;
+
+    guest_rules =3D guest_handle_for_field(list_hnd, v4vtables_rule_t, r=
ules[0]);
+
+    nbrules =3D 0;
+    while ( nbrules < rules_list.nb_rules && ptr !=3D &v4vtables_rules )
+    {
+        node =3D list_entry(ptr, struct v4vtables_rule_node, list);
+
+        if ( copy_to_guest(guest_rules, &node->rule, 1) )
+            break;
+
+        guest_handle_add_offset(guest_rules, 1);
+
+        nbrules++;
+        ptr =3D ptr->next;
+    }
+
+    rules_list.nb_rules =3D nbrules;
+    if ( copy_field_to_guest(list_hnd, &rules_list, nb_rules) )
+        return -EFAULT;
+
+    return 0;
+}
+
+static size_t
+v4vtables_check(v4v_addr_t * src, v4v_addr_t * dst)
+{
+    struct list_head *ptr;
+    struct v4vtables_rule_node *node;
+    size_t ret =3D 0; /* Defaulting to ACCEPT */
+
+    read_lock(&v4vtables_rules_lock);
+
+    list_for_each(ptr, &v4vtables_rules)
+    {
+        node =3D list_entry(ptr, struct v4vtables_rule_node, list);
+
+        if ( (node->rule.src.domain =3D=3D V4V_DOMID_ANY ||
+              node->rule.src.domain =3D=3D src->domain) &&
+             (node->rule.src.port =3D=3D V4V_PORT_ANY ||
+              node->rule.src.port =3D=3D src->port) &&
+             (node->rule.dst.domain =3D=3D V4V_DOMID_ANY ||
+              node->rule.dst.domain =3D=3D dst->domain) &&
+             (node->rule.dst.port =3D=3D V4V_PORT_ANY ||
+              node->rule.dst.port =3D=3D dst->port) )
+        {
+            ret =3D !node->rule.accept;
+            break;
+        }
+    }
+
+    read_unlock(&v4vtables_rules_lock);
+    return ret;
+}
+
+/*
+ * Hypercall to do the send
+ */
+static long
+v4v_sendv(struct domain *src_d, v4v_addr_t * src_addr,
+          v4v_addr_t * dst_addr, uint32_t proto,
+          XEN_GUEST_HANDLE(v4v_iov_t) iovs, size_t niov)
+{
+    struct domain *dst_d;
+    v4v_ring_id_t src_id;
+    struct v4v_ring_info *ring_info;
+    int ret =3D 0;
+
+    if ( !dst_addr )
+    {
+        v4v_dprintk("!dst_addr, EINVAL\n");
+        return -EINVAL;
+    }
+
+    read_lock(&v4v_lock);
+    if ( !src_d->v4v )
+    {
+        read_unlock(&v4v_lock);
+        v4v_dprintk("!src_d->v4v, EINVAL\n");
+        return -EINVAL;
+    }
+
+    src_id.addr.port =3D src_addr->port;
+    src_id.addr.domain =3D src_d->domain_id;
+    src_id.partner =3D dst_addr->domain;
+
+    dst_d =3D get_domain_by_id(dst_addr->domain);
+    if ( !dst_d )
+    {
+        read_unlock(&v4v_lock);
+        v4v_dprintk("!dst_d, ECONNREFUSED\n");
+        return -ECONNREFUSED;
+    }
+
+    if ( v4vtables_check(src_addr, dst_addr) !=3D 0 )
+    {
+        read_unlock(&v4v_lock);
+        gdprintk(XENLOG_WARNING,
+                 "V4V: VIPTables REJECTED %i:%i -> %i:%i\n",
+                 src_addr->domain, src_addr->port,
+                 dst_addr->domain, dst_addr->port);
+        return -ECONNREFUSED;
+    }
+
+    do
+    {
+        if ( !dst_d->v4v )
+        {
+            v4v_dprintk("dst_d->v4v, ECONNREFUSED\n");
+            ret =3D -ECONNREFUSED;
+            break;
+        }
+
+        read_lock(&dst_d->v4v->lock);
+        ring_info =3D
+            v4v_ring_find_info_by_addr(dst_d, dst_addr, src_addr->domain=
);
+
+        if ( !ring_info )
+        {
+            ret =3D -ECONNREFUSED;
+            v4v_dprintk(" !ring_info, ECONNREFUSED\n");
+        }
+        else
+        {
+            long len =3D v4v_iov_count(iovs, niov);
+
+            if ( len < 0 )
+            {
+                ret =3D len;
+                break;
+            }
+
+            spin_lock(&ring_info->lock);
+            ret =3D
+                v4v_ringbuf_insertv(dst_d, ring_info, &src_id, proto, io=
vs,
+                        niov, len);
+            if ( ret =3D=3D -EAGAIN )
+            {
+                v4v_dprintk("v4v_ringbuf_insertv failed, EAGAIN\n");
+                /* Schedule a wake up on the event channel when space is=
 there */
+                if ( v4v_pending_requeue(ring_info, src_d->domain_id, le=
n) )
+                {
+                    v4v_dprintk("v4v_pending_requeue failed, ENOMEM\n");
+                    ret =3D -ENOMEM;
+                }
+            }
+            spin_unlock(&ring_info->lock);
+
+            if ( ret >=3D 0 )
+            {
+                v4v_signal_domain(dst_d);
+            }
+
+        }
+        read_unlock(&dst_d->v4v->lock);
+
+    }
+    while ( 0 );
+
+    put_domain(dst_d);
+    read_unlock(&v4v_lock);
+    return ret;
+}
+
+static void
+v4v_info(struct domain *d, v4v_info_t *info)
+{
+    read_lock(&d->v4v->lock);
+    info->ring_magic =3D V4V_RING_MAGIC;
+    info->data_magic =3D V4V_RING_DATA_MAGIC;
+    info->evtchn =3D d->v4v->evtchn_port;
+    read_unlock(&d->v4v->lock);
+}
+
+/*
+ * hypercall glue
+ */
+long
+do_v4v_op(int cmd, XEN_GUEST_HANDLE(void) arg1,
+          XEN_GUEST_HANDLE(void) arg2,
+          uint32_t arg3, uint32_t arg4)
+{
+    struct domain *d =3D current->domain;
+    long rc =3D -EFAULT;
+
+    v4v_dprintk("->do_v4v_op(%d,%p,%p,%d,%d)\n", cmd,
+                (void *)arg1.p, (void *)arg2.p, (int) arg3, (int) arg4);
+
+    domain_lock(d);
+    switch (cmd)
+    {
+        case V4VOP_register_ring:
+            {
+                XEN_GUEST_HANDLE(v4v_ring_t) ring_hnd =3D
+                    guest_handle_cast(arg1, v4v_ring_t);
+                XEN_GUEST_HANDLE(v4v_pfn_t) pfn_hnd =3D
+                    guest_handle_cast(arg2, v4v_pfn_t);
+                uint32_t npage =3D arg3;
+                if ( unlikely(!guest_handle_okay(pfn_hnd, npage)) )
+                    goto out;
+                rc =3D v4v_ring_add(d, ring_hnd, npage, pfn_hnd);
+                break;
+            }
+        case V4VOP_unregister_ring:
+            {
+                XEN_GUEST_HANDLE(v4v_ring_t) ring_hnd =3D
+                    guest_handle_cast(arg1, v4v_ring_t);
+                rc =3D v4v_ring_remove(d, ring_hnd);
+                break;
+            }
+        case V4VOP_sendv:
+            {
+                uint32_t niov =3D arg3;
+                uint32_t message_type =3D arg4;
+                XEN_GUEST_HANDLE(v4v_send_addr_t) addr_hnd =3D
+                    guest_handle_cast(arg1, v4v_send_addr_t);
+                v4v_send_addr_t addr;
+
+                if ( copy_from_guest(&addr, addr_hnd, 1) )
+                    goto out;
+
+                rc =3D v4v_sendv(d, &addr.src, &addr.dst, message_type,
+                        guest_handle_cast(arg2, v4v_iov_t), niov);
+                break;
+            }
+        case V4VOP_notify:
+            {
+                XEN_GUEST_HANDLE(v4v_ring_data_t) ring_data_hnd =3D
+                    guest_handle_cast(arg1, v4v_ring_data_t);
+                rc =3D v4v_notify(d, ring_data_hnd);
+                break;
+            }
+        case V4VOP_tables_add:
+            {
+                uint32_t position =3D arg3;
+                XEN_GUEST_HANDLE(v4vtables_rule_t) rule_hnd =3D
+                    guest_handle_cast(arg1, v4vtables_rule_t);
+                rc =3D -EPERM;
+                if ( !IS_PRIV(d) )
+                    goto out;
+
+                write_lock(&v4vtables_rules_lock);
+                rc =3D v4vtables_add(d, rule_hnd, position);
+                write_unlock(&v4vtables_rules_lock);
+                break;
+            }
+        case V4VOP_tables_del:
+            {
+                uint32_t position =3D arg3;
+                XEN_GUEST_HANDLE(v4vtables_rule_t) rule_hnd =3D
+                    guest_handle_cast(arg1, v4vtables_rule_t);
+                rc =3D -EPERM;
+                if ( !IS_PRIV(d) )
+                    goto out;
+
+                write_lock(&v4vtables_rules_lock);
+                rc =3D v4vtables_del(d, rule_hnd, position);
+                write_unlock(&v4vtables_rules_lock);
+                break;
+            }
+        case V4VOP_tables_list:
+            {
+                XEN_GUEST_HANDLE(v4vtables_list_t) rules_list_hnd =3D
+                    guest_handle_cast(arg1, v4vtables_list_t);
+                rc =3D -EPERM;
+                if ( !IS_PRIV(d) )
+                    goto out;
+
+                read_lock(&v4vtables_rules_lock);
+                rc =3D v4vtables_list(d, rules_list_hnd);
+                read_unlock(&v4vtables_rules_lock);
+                break;
+            }
+        case V4VOP_info:
+            {
+                XEN_GUEST_HANDLE(v4v_info_t) info_hnd =3D
+                    guest_handle_cast(arg1, v4v_info_t);
+                v4v_info_t info;
+
+                if ( unlikely(!guest_handle_okay(info_hnd, 1)) )
+                    goto out;
+                v4v_info(d, &info);
+                if ( __copy_to_guest(info_hnd, &info, 1) )
+                    goto out;
+                rc =3D 0;
+                break;
+            }
+        default:
+            rc =3D -ENOSYS;
+            break;
+    }
+out:
+    domain_unlock(d);
+    v4v_dprintk("<-do_v4v_op()=3D%d\n", (int)rc);
+    return rc;
+}
+
+/*
+ * init
+ */
+
+void
+v4v_destroy(struct domain *d)
+{
+    int i;
+
+    BUG_ON(!d->is_dying);
+    write_lock(&v4v_lock);
+
+    v4v_dprintk("d->v=3D%p\n", d->v4v);
+
+    if ( d->v4v )
+    {
+        for ( i =3D 0; i < V4V_HTABLE_SIZE; ++i )
+        {
+            struct hlist_node *node, *next;
+            struct v4v_ring_info *ring_info;
+
+            hlist_for_each_entry_safe(ring_info, node,
+                    next, &d->v4v->ring_hash[i],
+                    node)
+            {
+                v4v_ring_remove_info(d, ring_info);
+            }
+        }
+    }
+
+    d->v4v =3D NULL;
+    write_unlock(&v4v_lock);
+}
+
+int
+v4v_init(struct domain *d)
+{
+    struct v4v_domain *v4v;
+    evtchn_port_t port;
+    int i;
+    int rc;
+
+    v4v =3D xmalloc(struct v4v_domain);
+    if ( !v4v )
+        return -ENOMEM;
+
+    rc =3D evtchn_alloc_unbound_domain(d, &port, d->domain_id);
+    if ( rc )
+        return rc;
+
+    rwlock_init(&v4v->lock);
+
+    v4v->evtchn_port =3D port;
+    for ( i =3D 0; i < V4V_HTABLE_SIZE; ++i )
+        INIT_HLIST_HEAD(&v4v->ring_hash[i]);
+
+    write_lock(&v4v_lock);
+    d->v4v =3D v4v;
+    write_unlock(&v4v_lock);
+
+    return 0;
+}
+
+
+/*
+ * debug
+ */
+
+static void
+dump_domain_ring(struct domain *d, struct v4v_ring_info *ring_info)
+{
+    uint32_t rx_ptr;
+
+    printk(KERN_ERR "  ring: domid=3D%d port=3D0x%08x partner=3D%d npage=
=3D%d\n",
+           (int)d->domain_id, (int)ring_info->id.addr.port,
+           (int)ring_info->id.partner, (int)ring_info->npage);
+
+    if ( v4v_ringbuf_get_rx_ptr(d, ring_info, &rx_ptr) )
+    {
+        printk(KERN_ERR "   Failed to read rx_ptr\n");
+        return;
+    }
+
+    printk(KERN_ERR "   tx_ptr=3D%d rx_ptr=3D%d len=3D%d\n",
+           (int)ring_info->tx_ptr, (int)rx_ptr, (int)ring_info->len);
+}
+
+static void
+dump_domain(struct domain *d)
+{
+    int i;
+
+    printk(KERN_ERR " domain %d:\n", (int)d->domain_id);
+
+    read_lock(&d->v4v->lock);
+
+    for ( i =3D 0; i < V4V_HTABLE_SIZE; ++i )
+    {
+        struct hlist_node *node;
+        struct v4v_ring_info *ring_info;
+
+        hlist_for_each_entry(ring_info, node, &d->v4v->ring_hash[i], nod=
e)
+            dump_domain_ring(d, ring_info);
+    }
+
+    printk(KERN_ERR "  event channel: %d\n",  d->v4v->evtchn_port);
+    read_unlock(&d->v4v->lock);
+
+    printk(KERN_ERR "\n");
+    v4v_signal_domain(d);
+}
+
+static void
+dump_state(unsigned char key)
+{
+    struct domain *d;
+
+    printk(KERN_ERR "\n\nV4V:\n");
+    read_lock(&v4v_lock);
+
+    rcu_read_lock(&domlist_read_lock);
+
+    for_each_domain(d)
+        dump_domain(d);
+
+    rcu_read_unlock(&domlist_read_lock);
+
+    read_unlock(&v4v_lock);
+}
+
+struct keyhandler v4v_info_keyhandler =3D
+{
+    .diagnostic =3D 1,
+    .u.fn =3D dump_state,
+    .desc =3D "dump v4v states and interupt"
+};
+
+static int __init
+setup_dump_rings(void)
+{
+    register_keyhandler('4', &v4v_info_keyhandler);
+    return 0;
+}
+
+__initcall(setup_dump_rings);
+
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/public/v4v.h b/xen/include/public/v4v.h
new file mode 100644
index 0000000..c7425cc
--- /dev/null
+++ b/xen/include/public/v4v.h
@@ -0,0 +1,308 @@
+/***********************************************************************=
*******
+ * V4V
+ *
+ * Version 2 of v2v (Virtual-to-Virtual)
+ *
+ * Copyright (c) 2010, Citrix Systems
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 =
 USA
+ */
+
+#ifndef __XEN_PUBLIC_V4V_H__
+#define __XEN_PUBLIC_V4V_H__
+
+#include "xen.h"
+#include "event_channel.h"
+
+/*
+ * Structure definitions
+ */
+
+#define V4V_RING_MAGIC          0xa822f72bb0b9d8ccUL
+#define V4V_RING_DATA_MAGIC	0x45fe852220b801d4UL
+
+#define V4V_MESSAGE_DGRAM       0x3c2c1db8
+#define V4V_MESSAGE_STREAM 	0x70f6a8e5
+
+#define V4V_DOMID_ANY           DOMID_INVALID
+#define V4V_PORT_ANY            0
+
+typedef uint64_t v4v_pfn_t;
+
+typedef struct v4v_iov
+{
+    uint64_t iov_base;
+    uint32_t iov_len;
+    uint32_t pad;
+} v4v_iov_t;
+
+typedef struct v4v_addr
+{
+    uint32_t port;
+    domid_t domain;
+    uint16_t pad;
+} v4v_addr_t;
+
+typedef struct v4v_ring_id
+{
+    v4v_addr_t addr;
+    domid_t partner;
+    uint16_t pad;
+} v4v_ring_id_t;
+
+typedef struct
+{
+    v4v_addr_t src;
+    v4v_addr_t dst;
+} v4v_send_addr_t;
+
+/*
+ * v4v_ring
+ * id: xen only looks at this during register/unregister
+ *     and will fill in id.addr.domain
+ * rx_ptr: rx pointer, modified by domain
+ * tx_ptr: tx pointer, modified by xen
+ *
+ */
+struct v4v_ring
+{
+    uint64_t magic;
+    v4v_ring_id_t id;
+    uint32_t len;
+    uint32_t rx_ptr;
+    uint32_t tx_ptr;
+    uint8_t reserved[32];
+#if defined(__STDC_VERSION__) && __STDC_VERSION__ >=3D 199901L
+    uint8_t ring[];
+#elif defined(__GNUC__)
+    uint8_t ring[0];
+#endif
+};
+typedef struct v4v_ring v4v_ring_t;
+
+#define V4V_RING_DATA_F_EMPTY       (1U << 0) /* Ring is empty */
+#define V4V_RING_DATA_F_EXISTS      (1U << 1) /* Ring exists */
+#define V4V_RING_DATA_F_PENDING     (1U << 2) /* Pending interrupt exist=
s - do not
+                                               * rely on this field - fo=
r
+                                               * profiling only */
+#define V4V_RING_DATA_F_SUFFICIENT  (1U << 3) /* Sufficient space to que=
ue
+                                               * space_required bytes ex=
ists */
+
+typedef struct v4v_ring_data_ent
+{
+    v4v_addr_t ring;
+    uint16_t flags;
+    uint16_t pad;
+    uint32_t space_required;
+    uint32_t max_message_size;
+} v4v_ring_data_ent_t;
+
+typedef struct v4v_ring_data
+{
+    uint64_t magic;
+    uint32_t nent;
+    uint32_t pad;
+    uint64_t reserved[4];
+#if defined(__STDC_VERSION__) && __STDC_VERSION__ >=3D 199901L
+    v4v_ring_data_ent_t data[];
+#elif defined(__GNUC__)
+    v4v_ring_data_ent_t data[0];
+#endif
+} v4v_ring_data_t;
+
+struct v4v_info
+{
+    uint64_t ring_magic;
+    uint64_t data_magic;
+    evtchn_port_t evtchn;
+    uint32_t pad;
+};
+typedef struct v4v_info v4v_info_t;
+
+#define V4V_SHF_SYN		(1 << 0)
+#define V4V_SHF_ACK		(1 << 1)
+#define V4V_SHF_RST		(1 << 2)
+
+#define V4V_SHF_PING		(1 << 8)
+#define V4V_SHF_PONG		(1 << 9)
+
+struct v4v_stream_header
+{
+    uint32_t flags;
+    uint32_t conid;
+};
+
+struct v4v_ring_message_header
+{
+    uint32_t len;
+    uint32_t pad0;
+    v4v_addr_t source;
+    uint32_t message_type;
+#if defined(__STDC_VERSION__) && __STDC_VERSION__ >=3D 199901L
+    uint8_t data[];
+#elif defined(__GNUC__)
+    uint8_t data[0];
+#endif
+};
+
+typedef struct v4vtables_rule
+{
+    v4v_addr_t src;
+    v4v_addr_t dst;
+    uint32_t accept;
+} v4vtables_rule_t;
+
+typedef struct v4vtables_list
+{
+    uint32_t start_rule;
+    uint32_t nb_rules;
+#if defined(__STDC_VERSION__) && __STDC_VERSION__ >=3D 199901L
+    struct v4vtables_rule rules[];
+#elif defined(__GNUC__)
+    struct v4vtables_rule rules[0];
+#endif
+} v4vtables_list_t;
+
+/*
+ * HYPERCALLS
+ */
+
+/*
+ * V4VOP_register_ring
+ *
+ * Registers a ring with Xen. If a ring with the same v4v_ring_id exists=
,
+ * the hypercall will return -EEXIST.
+ *
+ * do_v4v_op(V4VOP_register_ring,
+ *           XEN_GUEST_HANDLE(v4v_ring_t), XEN_GUEST_HANDLE(v4v_pfn_t),
+ *           npage, 0)
+ */
+#define V4VOP_register_ring 	1
+
+
+/*
+ * V4VOP_unregister_ring
+ *
+ * Unregister a ring.
+ *
+ * do_v4v_op(V4VOP_unregister_ring,
+ *           XEN_GUEST_HANDLE(v4v_ring_t),
+ *           NULL, 0, 0)
+ */
+#define V4VOP_unregister_ring 	2
+
+/*
+ * V4VOP_notify
+ *
+ * Asks xen for information about other rings in the system
+ *
+ * ent->ring is the v4v_addr_t of the ring you want information on
+ * the same matching rules are used as for V4VOP_send.
+ *
+ * ent->space_required  if this field is not null xen will check
+ * that there is space in the destination ring for this many bytes
+ * of payload. If there is it will set the V4V_RING_DATA_F_SUFFICIENT
+ * and CANCEL any pending interrupt for that ent->ring, if insufficient
+ * space is available it will schedule an interrupt and the flag will
+ * not be set.
+ *
+ * The flags are set by xen when notify replies
+ * V4V_RING_DATA_F_EMPTY	ring is empty
+ * V4V_RING_DATA_F_PENDING	interrupt is pending - don't rely on this
+ * V4V_RING_DATA_F_SUFFICIENT	sufficient space for space_required is the=
re
+ * V4V_RING_DATA_F_EXISTS	ring exists
+ *
+ * do_v4v_op(V4VOP_notify,
+ *           XEN_GUEST_HANDLE(v4v_ring_data_ent_t) ent,
+ *           NULL, 0, 0)
+ */
+#define V4VOP_notify 		4
+
+/*
+ * V4VOP_sendv
+ *
+ * Sends of list of buffer contained in iov.
+ *
+ * For each iov entry send iov_len bytes of iov_base to addr.dst, giving
+ * src as the source address (xen will ignore src->domain and put your
+ * domain in the actually message), xen first looks for a ring with id.a=
ddr=3D=3Ddst
+ * and id.partner=3D=3Dsending_domain if that fails it looks for id.addr=
=3D=3Ddst and
+ * id.partner=3D=3DDOMID_ANY.
+ * message_type is the 32 bit number used from the message
+ * most likely V4V_MESSAGE_DGRAM or V4V_MESSAGE_STREAM. If insufficient =
space exists
+ * it will return -EAGAIN and xen will twing the V4V_INTERRUPT when
+ * sufficient space becomes available
+ *
+ * do_v4v_op(V4VOP_sendv,
+ *           XEN_GUEST_HANDLE(v4v_send_addr_t) addr,
+ *           XEN_GUEST_HANDLE(v4v_iov_t) iov,
+ *           uint32_t niov,
+ *           uint32_t message_type)
+ */
+#define V4VOP_sendv		5
+
+/*
+ * V4VOP_tables_add
+ *
+ * Insert a filtering rules after a given position.
+ *
+ * do_v4v_op(V4VOP_tables_add,
+ *           XEN_GUEST_HANDLE(v4vtables_rule_t) rule,
+ *           NULL,
+ *           uint32_t position, 0)
+ */
+#define V4VOP_tables_add     6
+
+/*
+ * V4VOP_tables_del
+ *
+ * Delete a filtering rules at a position or the rule
+ * that matches "rule".
+ *
+ * do_v4v_op(V4VOP_tables_del,
+ *           XEN_GUEST_HANDLE(v4vtables_rule_t) rule,
+ *           NULL,
+ *           uint32_t position, 0)
+ */
+#define V4VOP_tables_del     7
+
+/*
+ * V4VOP_tables_list
+ *
+ * do_v4v_op(V4VOP_tables_list,
+ *           XEN_GUEST_HANDLE(v4vtpables_list_t) list,
+ *           NULL, 0, 0)
+ */
+#define V4VOP_tables_list    8
+
+/*
+ * V4VOP_info
+ *
+ * Returns v4v info for the current domain (domain that issued the hyper=
call).
+ *      - V4V magic number
+ *      - event channel port (for current domain)
+ *
+ * do_v4v_op(V4VOP_info,
+ *           XEN_GUEST_HANDLE(v4v_info_t) info,
+ *           NULL, 0, 0)
+ */
+#define V4VOP_info              9
+
+#endif /* __XEN_PUBLIC_V4V_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 7352d1e..66a3605 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -100,7 +100,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
 #define __HYPERVISOR_domctl               36
 #define __HYPERVISOR_kexec_op             37
 #define __HYPERVISOR_tmem_op              38
-#define __HYPERVISOR_xc_reserved_op       39 /* reserved for XenClient *=
/
+#define __HYPERVISOR_v4v_op               39
=20
 /* Architecture-specific hypercall definitions. */
 #define __HYPERVISOR_arch_0               48
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 6c55039..2fd9313 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
=20
 #ifdef CONFIG_COMPAT
 #include 
@@ -363,6 +364,9 @@ struct domain
     nodemask_t node_affinity;
     unsigned int last_alloc_node;
     spinlock_t node_affinity_lock;
+
+    /* v4v */
+    struct v4v_domain *v4v;
 };
=20
 struct domain_setup_info
diff --git a/xen/include/xen/v4v.h b/xen/include/xen/v4v.h
new file mode 100644
index 0000000..dd6fce4
--- /dev/null
+++ b/xen/include/xen/v4v.h
@@ -0,0 +1,49 @@
+/***********************************************************************=
*******
+ * V4V
+ *
+ * Version 2 of v2v (Virtual-to-Virtual)
+ *
+ * Copyright (c) 2010, Citrix Systems
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 =
 USA
+ */
+
+#ifndef __V4V_PRIVATE_H__
+#define __V4V_PRIVATE_H__
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct v4v_domain;
+
+void v4v_destroy(struct domain *d);
+int v4v_init(struct domain *d);
+long do_v4v_op (int cmd,
+                XEN_GUEST_HANDLE (void) arg1,
+                XEN_GUEST_HANDLE (void) arg2,
+                uint32_t arg3,
+                uint32_t arg4);
+
+#endif /* __V4V_PRIVATE_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */

--------------true
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------true--


From xen-devel-bounces@lists.xen.org Thu Oct 25 17:52:44 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 17:52:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRRbV-0003n8-VA; Thu, 25 Oct 2012 17:52:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRRbU-0003mn-JT
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 17:52:24 +0000
Received: from [85.158.139.211:53096] by server-8.bemta-5.messagelabs.com id
	0D/72-23193-75C79805; Thu, 25 Oct 2012 17:52:23 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1351187542!19760106!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16696 invoked from network); 25 Oct 2012 17:52:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 17:52:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,648,1344211200"; d="scan'208";a="15396443"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 17:52:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 18:52:22 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53] helo=spongy)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TRRbR-00006h-V8;
	Thu, 25 Oct 2012 17:52:22 +0000
Received: by spongy (Postfix, from userid 2023)	id 5567F340D86; Thu, 25 Oct
	2012 18:55:31 +0100 (BST)
From: Jean Guyader 
To: 
Date: Thu, 25 Oct 2012 18:55:28 +0100
Message-ID: <1351187729-4681-2-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1351187729-4681-1-git-send-email-jean.guyader@citrix.com>
References: <1351187729-4681-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: tim@xen.org, Jean Guyader , JBeulich@suse.com
Subject: [Xen-devel] [PATCH 1/2] xen: events,
	exposes evtchn_alloc_unbound_domain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: quoted-printable


Exposes evtchn_alloc_unbound_domain to the rest of
Xen so we can create allocated unbound evtchn within Xen.

Signed-off-by: Jean Guyader 
---
 xen/common/event_channel.c |   39 +++++++++++++++++++++++++++-----------=
-
 xen/include/xen/event.h    |    3 +++
 2 files changed, 30 insertions(+), 12 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0001-xen-events-exposes-evtchn_alloc_unbound_domain.patch"
Content-Disposition: attachment;
	filename="0001-xen-events-exposes-evtchn_alloc_unbound_domain.patch"
Content-Transfer-Encoding: quoted-printable

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index a80a0d1..a868b89 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -159,36 +159,51 @@ static int get_free_port(struct domain *d)
=20
 static long evtchn_alloc_unbound(evtchn_alloc_unbound_t *alloc)
 {
-    struct evtchn *chn;
     struct domain *d;
-    int            port;
-    domid_t        dom =3D alloc->dom;
     long           rc;
=20
-    rc =3D rcu_lock_target_domain_by_id(dom, &d);
+    rc =3D rcu_lock_target_domain_by_id(alloc->dom, &d);
     if ( rc )
         return rc;
=20
+    rc =3D evtchn_alloc_unbound_domain(d, &alloc->port, alloc->remote_do=
m);
+    if ( rc )
+        ERROR_EXIT_DOM((int)rc, d);
+
+ out:
+    rcu_unlock_domain(d);
+
+    return rc;
+}
+
+int evtchn_alloc_unbound_domain(struct domain *d, evtchn_port_t *port,
+                                domid_t remote_domid)
+{
+    struct evtchn *chn;
+    int           rc;
+    int           free_port;
+
     spin_lock(&d->event_lock);
=20
-    if ( (port =3D get_free_port(d)) < 0 )
-        ERROR_EXIT_DOM(port, d);
-    chn =3D evtchn_from_port(d, port);
+    rc =3D free_port =3D get_free_port(d);
+    if ( free_port < 0 )
+        goto out;
=20
-    rc =3D xsm_evtchn_unbound(d, chn, alloc->remote_dom);
+    chn =3D evtchn_from_port(d, free_port);
+    rc =3D xsm_evtchn_unbound(d, chn, remote_domid);
     if ( rc )
         goto out;
=20
     chn->state =3D ECS_UNBOUND;
-    if ( (chn->u.unbound.remote_domid =3D alloc->remote_dom) =3D=3D DOMI=
D_SELF )
+    if ( (chn->u.unbound.remote_domid =3D remote_domid) =3D=3D DOMID_SEL=
F )
         chn->u.unbound.remote_domid =3D current->domain->domain_id;
=20
-    alloc->port =3D port;
+    *port =3D free_port;
+    /* Everything is fine, returns 0 */
+    rc =3D 0;
=20
  out:
     spin_unlock(&d->event_lock);
-    rcu_unlock_domain(d);
-
     return rc;
 }
=20
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 71c3e92..1a0c832 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -69,6 +69,9 @@ int guest_enabled_event(struct vcpu *v, uint32_t virq);
 /* Notify remote end of a Xen-attached event channel.*/
 void notify_via_xen_event_channel(struct domain *ld, int lport);
=20
+int evtchn_alloc_unbound_domain(struct domain *d, evtchn_port_t *port,
+                                domid_t remote_domid);
+
 /* Internal event channel object accessors */
 #define bucket_from_port(d,p) \
     ((d)->evtchn[(p)/EVTCHNS_PER_BUCKET])

--------------true
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------true--


From xen-devel-bounces@lists.xen.org Thu Oct 25 17:52:44 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 17:52:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRRbV-0003n8-VA; Thu, 25 Oct 2012 17:52:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRRbU-0003mn-JT
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 17:52:24 +0000
Received: from [85.158.139.211:53096] by server-8.bemta-5.messagelabs.com id
	0D/72-23193-75C79805; Thu, 25 Oct 2012 17:52:23 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1351187542!19760106!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16696 invoked from network); 25 Oct 2012 17:52:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 17:52:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,648,1344211200"; d="scan'208";a="15396443"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 17:52:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 18:52:22 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53] helo=spongy)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TRRbR-00006h-V8;
	Thu, 25 Oct 2012 17:52:22 +0000
Received: by spongy (Postfix, from userid 2023)	id 5567F340D86; Thu, 25 Oct
	2012 18:55:31 +0100 (BST)
From: Jean Guyader 
To: 
Date: Thu, 25 Oct 2012 18:55:28 +0100
Message-ID: <1351187729-4681-2-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1351187729-4681-1-git-send-email-jean.guyader@citrix.com>
References: <1351187729-4681-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: tim@xen.org, Jean Guyader , JBeulich@suse.com
Subject: [Xen-devel] [PATCH 1/2] xen: events,
	exposes evtchn_alloc_unbound_domain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: quoted-printable


Exposes evtchn_alloc_unbound_domain to the rest of
Xen so we can create allocated unbound evtchn within Xen.

Signed-off-by: Jean Guyader 
---
 xen/common/event_channel.c |   39 +++++++++++++++++++++++++++-----------=
-
 xen/include/xen/event.h    |    3 +++
 2 files changed, 30 insertions(+), 12 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0001-xen-events-exposes-evtchn_alloc_unbound_domain.patch"
Content-Disposition: attachment;
	filename="0001-xen-events-exposes-evtchn_alloc_unbound_domain.patch"
Content-Transfer-Encoding: quoted-printable

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index a80a0d1..a868b89 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -159,36 +159,51 @@ static int get_free_port(struct domain *d)
=20
 static long evtchn_alloc_unbound(evtchn_alloc_unbound_t *alloc)
 {
-    struct evtchn *chn;
     struct domain *d;
-    int            port;
-    domid_t        dom =3D alloc->dom;
     long           rc;
=20
-    rc =3D rcu_lock_target_domain_by_id(dom, &d);
+    rc =3D rcu_lock_target_domain_by_id(alloc->dom, &d);
     if ( rc )
         return rc;
=20
+    rc =3D evtchn_alloc_unbound_domain(d, &alloc->port, alloc->remote_do=
m);
+    if ( rc )
+        ERROR_EXIT_DOM((int)rc, d);
+
+ out:
+    rcu_unlock_domain(d);
+
+    return rc;
+}
+
+int evtchn_alloc_unbound_domain(struct domain *d, evtchn_port_t *port,
+                                domid_t remote_domid)
+{
+    struct evtchn *chn;
+    int           rc;
+    int           free_port;
+
     spin_lock(&d->event_lock);
=20
-    if ( (port =3D get_free_port(d)) < 0 )
-        ERROR_EXIT_DOM(port, d);
-    chn =3D evtchn_from_port(d, port);
+    rc =3D free_port =3D get_free_port(d);
+    if ( free_port < 0 )
+        goto out;
=20
-    rc =3D xsm_evtchn_unbound(d, chn, alloc->remote_dom);
+    chn =3D evtchn_from_port(d, free_port);
+    rc =3D xsm_evtchn_unbound(d, chn, remote_domid);
     if ( rc )
         goto out;
=20
     chn->state =3D ECS_UNBOUND;
-    if ( (chn->u.unbound.remote_domid =3D alloc->remote_dom) =3D=3D DOMI=
D_SELF )
+    if ( (chn->u.unbound.remote_domid =3D remote_domid) =3D=3D DOMID_SEL=
F )
         chn->u.unbound.remote_domid =3D current->domain->domain_id;
=20
-    alloc->port =3D port;
+    *port =3D free_port;
+    /* Everything is fine, returns 0 */
+    rc =3D 0;
=20
  out:
     spin_unlock(&d->event_lock);
-    rcu_unlock_domain(d);
-
     return rc;
 }
=20
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 71c3e92..1a0c832 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -69,6 +69,9 @@ int guest_enabled_event(struct vcpu *v, uint32_t virq);
 /* Notify remote end of a Xen-attached event channel.*/
 void notify_via_xen_event_channel(struct domain *ld, int lport);
=20
+int evtchn_alloc_unbound_domain(struct domain *d, evtchn_port_t *port,
+                                domid_t remote_domid);
+
 /* Internal event channel object accessors */
 #define bucket_from_port(d,p) \
     ((d)->evtchn[(p)/EVTCHNS_PER_BUCKET])

--------------true
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------true--


From xen-devel-bounces@lists.xen.org Thu Oct 25 17:52:44 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 17:52:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRRbV-0003n1-Jc; Thu, 25 Oct 2012 17:52:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRRbU-0003mm-C4
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 17:52:24 +0000
Received: from [85.158.139.211:8198] by server-14.bemta-5.messagelabs.com id
	98/AC-21768-75C79805; Thu, 25 Oct 2012 17:52:23 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1351187542!19760106!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16683 invoked from network); 25 Oct 2012 17:52:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 17:52:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,648,1344211200"; d="scan'208";a="15396442"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 17:52:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 18:52:22 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53] helo=spongy)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TRRbR-00006e-RM;
	Thu, 25 Oct 2012 17:52:21 +0000
Received: by spongy (Postfix, from userid 2023)	id 2D99B34040D; Thu, 25 Oct
	2012 18:55:31 +0100 (BST)
From: Jean Guyader 
To: 
Date: Thu, 25 Oct 2012 18:55:27 +0100
Message-ID: <1351187729-4681-1-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: tim@xen.org, Jean Guyader , JBeulich@suse.com
Subject: [Xen-devel] [PATCH 0/2] Add V4V to Xen (v8)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: quoted-printable

v8 changes:
        - Move v4v private structures to v4v.c
        - fix padding
        - Fix some coding style issues
        - Drop the VIRQ_XC_RESERVED patch

v7 changes:
        - Remove v4v_send from the API (v4v_sendv should be
          used instead).
        - Remove internal_v4v_iov
        - Remove useless padding
        - Switch back to use uint64_t for the pfn list
          instead of xen_pfn_t (to avoid some compat code)
        - Rename v4v_iptable to v4v_table.
        - Use __copy_to/from_guest when possible

v6 changes:
        - Check compiler before using [0] or [].

v5 changes:
        - Fix prototypes in v4v.h for do_v4v_op
        - Add padding to make sure all the structures
          are 64 bits aligned
        - Replace [0] with []

v4 changes:
        - Stop using ssize_t, use long instead
        - Return -MSGSIZE for message bigger than 2GB
        - Fixup size handling
        - Rename protocol with message_type to avoid the
          confusion with the IP protocol flag
        - Replaced V4V_DOMID_ANY value with DOMID_INVALID
        - Replaced v4v_pfn_t with xen_pfn_t
        - Add padding to struct v4v_info
        - Fixup hypercall documentation
        - Move V4V_ROUNDUP to v4v.c
        - Remove v4v_utils.h (we could potentially add it later).

v3 changes:
        - Switch to event channel
                - Allocated a unbound event channel
                  per domain.
                - Add a new v4v call to share the
                  event channel port.
        - Public headers with actual type definition
        - Align all the v4v type to 64 bits
        - Modify v4v MAGIC numbers because we won't
          but backward compatible anymore
        - Merge insert and insertv
        - Merge send and sendv
        - Turn all the lock prerequisite from comment
          to ASSERT()
        - Make use or write_atomic instead of volatile pointers
        - Merge v4v_memcpy_to_guest_ring and
          v4v_memcpy_to_guest_ring_from_guest
                - Introduce copy_from_guest_maybe that can take
                  a void * and a handle as src address.
        - Replace 6 arguments hypercalls with 5 arguments hypercalls.

v2 changes:
        - Cleanup plugin header
        - Include basic access control
        - Use guest_handle_for_field

Jean Guyader (2):
  xen: events, exposes evtchn_alloc_unbound_domain
  xen: Add V4V implementation

 xen/arch/x86/hvm/hvm.c             |    6 +-
 xen/arch/x86/x86_64/compat/entry.S |    2 +
 xen/arch/x86/x86_64/entry.S        |    2 +
 xen/common/Makefile                |    1 +
 xen/common/domain.c                |   13 +-
 xen/common/event_channel.c         |   39 +-
 xen/common/v4v.c                   | 1922 ++++++++++++++++++++++++++++++=
++++++
 xen/include/public/v4v.h           |  308 ++++++
 xen/include/public/xen.h           |    2 +-
 xen/include/xen/event.h            |    3 +
 xen/include/xen/sched.h            |    4 +
 xen/include/xen/v4v.h              |   49 +
 12 files changed, 2335 insertions(+), 16 deletions(-)
 create mode 100644 xen/common/v4v.c
 create mode 100644 xen/include/public/v4v.h
 create mode 100644 xen/include/xen/v4v.h

--=20
1.7.9.5


--------------true
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------true--


From xen-devel-bounces@lists.xen.org Thu Oct 25 17:52:44 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 17:52:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRRbV-0003n1-Jc; Thu, 25 Oct 2012 17:52:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRRbU-0003mm-C4
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 17:52:24 +0000
Received: from [85.158.139.211:8198] by server-14.bemta-5.messagelabs.com id
	98/AC-21768-75C79805; Thu, 25 Oct 2012 17:52:23 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1351187542!19760106!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16683 invoked from network); 25 Oct 2012 17:52:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 17:52:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,648,1344211200"; d="scan'208";a="15396442"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 17:52:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 18:52:22 +0100
Received: from spongy.cam.xci-test.com ([10.80.248.53] helo=spongy)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TRRbR-00006e-RM;
	Thu, 25 Oct 2012 17:52:21 +0000
Received: by spongy (Postfix, from userid 2023)	id 2D99B34040D; Thu, 25 Oct
	2012 18:55:31 +0100 (BST)
From: Jean Guyader 
To: 
Date: Thu, 25 Oct 2012 18:55:27 +0100
Message-ID: <1351187729-4681-1-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: tim@xen.org, Jean Guyader , JBeulich@suse.com
Subject: [Xen-devel] [PATCH 0/2] Add V4V to Xen (v8)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: quoted-printable

v8 changes:
        - Move v4v private structures to v4v.c
        - fix padding
        - Fix some coding style issues
        - Drop the VIRQ_XC_RESERVED patch

v7 changes:
        - Remove v4v_send from the API (v4v_sendv should be
          used instead).
        - Remove internal_v4v_iov
        - Remove useless padding
        - Switch back to use uint64_t for the pfn list
          instead of xen_pfn_t (to avoid some compat code)
        - Rename v4v_iptable to v4v_table.
        - Use __copy_to/from_guest when possible

v6 changes:
        - Check compiler before using [0] or [].

v5 changes:
        - Fix prototypes in v4v.h for do_v4v_op
        - Add padding to make sure all the structures
          are 64 bits aligned
        - Replace [0] with []

v4 changes:
        - Stop using ssize_t, use long instead
        - Return -MSGSIZE for message bigger than 2GB
        - Fixup size handling
        - Rename protocol with message_type to avoid the
          confusion with the IP protocol flag
        - Replaced V4V_DOMID_ANY value with DOMID_INVALID
        - Replaced v4v_pfn_t with xen_pfn_t
        - Add padding to struct v4v_info
        - Fixup hypercall documentation
        - Move V4V_ROUNDUP to v4v.c
        - Remove v4v_utils.h (we could potentially add it later).

v3 changes:
        - Switch to event channel
                - Allocated a unbound event channel
                  per domain.
                - Add a new v4v call to share the
                  event channel port.
        - Public headers with actual type definition
        - Align all the v4v type to 64 bits
        - Modify v4v MAGIC numbers because we won't
          but backward compatible anymore
        - Merge insert and insertv
        - Merge send and sendv
        - Turn all the lock prerequisite from comment
          to ASSERT()
        - Make use or write_atomic instead of volatile pointers
        - Merge v4v_memcpy_to_guest_ring and
          v4v_memcpy_to_guest_ring_from_guest
                - Introduce copy_from_guest_maybe that can take
                  a void * and a handle as src address.
        - Replace 6 arguments hypercalls with 5 arguments hypercalls.

v2 changes:
        - Cleanup plugin header
        - Include basic access control
        - Use guest_handle_for_field

Jean Guyader (2):
  xen: events, exposes evtchn_alloc_unbound_domain
  xen: Add V4V implementation

 xen/arch/x86/hvm/hvm.c             |    6 +-
 xen/arch/x86/x86_64/compat/entry.S |    2 +
 xen/arch/x86/x86_64/entry.S        |    2 +
 xen/common/Makefile                |    1 +
 xen/common/domain.c                |   13 +-
 xen/common/event_channel.c         |   39 +-
 xen/common/v4v.c                   | 1922 ++++++++++++++++++++++++++++++=
++++++
 xen/include/public/v4v.h           |  308 ++++++
 xen/include/public/xen.h           |    2 +-
 xen/include/xen/event.h            |    3 +
 xen/include/xen/sched.h            |    4 +
 xen/include/xen/v4v.h              |   49 +
 12 files changed, 2335 insertions(+), 16 deletions(-)
 create mode 100644 xen/common/v4v.c
 create mode 100644 xen/include/public/v4v.h
 create mode 100644 xen/include/xen/v4v.h

--=20
1.7.9.5


--------------true
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------true--


From xen-devel-bounces@lists.xen.org Thu Oct 25 18:15:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 18:15:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRRxJ-0004Qu-Mj; Thu, 25 Oct 2012 18:14:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRRxI-0004Qp-Om
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 18:14:57 +0000
Received: from [85.158.138.51:5899] by server-9.bemta-3.messagelabs.com id
	0D/E7-16841-F9189805; Thu, 25 Oct 2012 18:14:55 +0000
X-Env-Sender: burns.me.uk@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1351188894!25684224!1
X-Originating-IP: [209.85.219.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5245 invoked from network); 25 Oct 2012 18:14:55 -0000
Received: from mail-oa0-f43.google.com (HELO mail-oa0-f43.google.com)
	(209.85.219.43)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 18:14:55 -0000
Received: by mail-oa0-f43.google.com with SMTP id k1so2570055oag.30
	for ;
	Thu, 25 Oct 2012 11:14:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:cc:content-type;
	bh=fiFfilQpIp1EMRxBjv3RqmYXK4plzam2DAFZGYV9aQU=;
	b=zcm7+Cb7gAs4OWd2nBocn4B3Uwc9EsWNEsTwVFJYKdrgi2hhaTMArpBROUx23LiB4X
	0aBR/gcR1qAmg2IUJDiFR5LKTFdAYW1EELukk0k4yuSINVTUt3365h3Rkjd/hgVHVjFb
	+IHmMZrJycE91E/Jv/Bhs2e8aAPfGfEkENfGxu9n6CJSRIVaf572l9Apu+L2OZ174Moy
	EslqCbCcCjPE0DEgU1k9nzkotpXTSGPsb/ZNqo3P20itjwhhBnZSpos3SdxMHTkxGiZv
	eME28n+hNbf0Jj8goXklWDX0IBOCSBQDzZn77DtzWeM9iEN1g8iQg2iMBFE+8ocs94d5
	GQSw==
MIME-Version: 1.0
Received: by 10.60.169.134 with SMTP id ae6mr17690032oec.32.1351188893445;
	Thu, 25 Oct 2012 11:14:53 -0700 (PDT)
Received: by 10.182.41.230 with HTTP; Thu, 25 Oct 2012 11:14:53 -0700 (PDT)
In-Reply-To: <20120925141013.GC16478@phenom.dumpdata.com>
References: 
	<20120921172901.GA6821@phenom.dumpdata.com>
	<099949C5-C4C0-4D57-A778-849C94781372@gmail.com>
	<20120925141013.GC16478@phenom.dumpdata.com>
Date: Thu, 25 Oct 2012 19:14:53 +0100
X-Google-Sender-Auth: Sszsim1ecPt4D-AAdU9Yl3wcV2o
Message-ID: 
From: Andy Burns 
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] Xen + DVB = not working. memory allocation issue?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 25 September 2012 15:10, Konrad Rzeszutek Wilk  wrote:

> So try also limiting how much memory the hypervisor has to eliminate
> this being a 4GB issue. Meaning on the _hypervisor_ line add 'mem=4G'.

I previously required that with xen 4.1.x but now I've upgraded to Xen
4.2 (and dom0 and domU to 3.6.x kernels) I no longer require it.

Has the O/P got  iommu=soft in the domU kernel command line if it's a PV domU?

Also try 'pci=resource_alignment=BB:DD.F;BB:DD.F' etc on the
hypervisor command line for your relevant PCI device(s)

Those tweaks are all I need to use these days for PCI passthrough :-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 18:15:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 18:15:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRRxJ-0004Qu-Mj; Thu, 25 Oct 2012 18:14:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRRxI-0004Qp-Om
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 18:14:57 +0000
Received: from [85.158.138.51:5899] by server-9.bemta-3.messagelabs.com id
	0D/E7-16841-F9189805; Thu, 25 Oct 2012 18:14:55 +0000
X-Env-Sender: burns.me.uk@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1351188894!25684224!1
X-Originating-IP: [209.85.219.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5245 invoked from network); 25 Oct 2012 18:14:55 -0000
Received: from mail-oa0-f43.google.com (HELO mail-oa0-f43.google.com)
	(209.85.219.43)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 18:14:55 -0000
Received: by mail-oa0-f43.google.com with SMTP id k1so2570055oag.30
	for ;
	Thu, 25 Oct 2012 11:14:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:cc:content-type;
	bh=fiFfilQpIp1EMRxBjv3RqmYXK4plzam2DAFZGYV9aQU=;
	b=zcm7+Cb7gAs4OWd2nBocn4B3Uwc9EsWNEsTwVFJYKdrgi2hhaTMArpBROUx23LiB4X
	0aBR/gcR1qAmg2IUJDiFR5LKTFdAYW1EELukk0k4yuSINVTUt3365h3Rkjd/hgVHVjFb
	+IHmMZrJycE91E/Jv/Bhs2e8aAPfGfEkENfGxu9n6CJSRIVaf572l9Apu+L2OZ174Moy
	EslqCbCcCjPE0DEgU1k9nzkotpXTSGPsb/ZNqo3P20itjwhhBnZSpos3SdxMHTkxGiZv
	eME28n+hNbf0Jj8goXklWDX0IBOCSBQDzZn77DtzWeM9iEN1g8iQg2iMBFE+8ocs94d5
	GQSw==
MIME-Version: 1.0
Received: by 10.60.169.134 with SMTP id ae6mr17690032oec.32.1351188893445;
	Thu, 25 Oct 2012 11:14:53 -0700 (PDT)
Received: by 10.182.41.230 with HTTP; Thu, 25 Oct 2012 11:14:53 -0700 (PDT)
In-Reply-To: <20120925141013.GC16478@phenom.dumpdata.com>
References: 
	<20120921172901.GA6821@phenom.dumpdata.com>
	<099949C5-C4C0-4D57-A778-849C94781372@gmail.com>
	<20120925141013.GC16478@phenom.dumpdata.com>
Date: Thu, 25 Oct 2012 19:14:53 +0100
X-Google-Sender-Auth: Sszsim1ecPt4D-AAdU9Yl3wcV2o
Message-ID: 
From: Andy Burns 
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] Xen + DVB = not working. memory allocation issue?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 25 September 2012 15:10, Konrad Rzeszutek Wilk  wrote:

> So try also limiting how much memory the hypervisor has to eliminate
> this being a 4GB issue. Meaning on the _hypervisor_ line add 'mem=4G'.

I previously required that with xen 4.1.x but now I've upgraded to Xen
4.2 (and dom0 and domU to 3.6.x kernels) I no longer require it.

Has the O/P got  iommu=soft in the domU kernel command line if it's a PV domU?

Also try 'pci=resource_alignment=BB:DD.F;BB:DD.F' etc on the
hypervisor command line for your relevant PCI device(s)

Those tweaks are all I need to use these days for PCI passthrough :-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 19:37:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 19:37:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRTF6-0004tP-80; Thu, 25 Oct 2012 19:37:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRTF4-0004tK-1A
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 19:37:22 +0000
Received: from [85.158.143.35:32725] by server-1.bemta-4.messagelabs.com id
	45/EE-19134-1F499805; Thu, 25 Oct 2012 19:37:21 +0000
X-Env-Sender: carnold@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1351193840!11702643!1
X-Originating-IP: [137.65.248.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM3LjY1LjI0OC43NCA9PiA0MDk5\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1899 invoked from network); 25 Oct 2012 19:37:20 -0000
Received: from novprvoes0310.provo.novell.com (HELO
	novprvoes0310.provo.novell.com) (137.65.248.74)
	by server-7.tower-21.messagelabs.com with SMTP;
	25 Oct 2012 19:37:20 -0000
Received: from INET-PRV-MTA by novprvoes0310.provo.novell.com
	with Novell_GroupWise; Thu, 25 Oct 2012 13:37:19 -0600
Message-Id: <5089408D0200009100082462@novprvoes0310.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 25 Oct 2012 13:37:17 -0600
From: "Charles Arnold" 
To: "Ian Jackson" 
References: <50814E190200009100082117@novprvoes0310.provo.novell.com>
	<20617.21621.886298.796143@mariner.uk.xensource.com>
In-Reply-To: <20617.21621.886298.796143@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] pygrub: Add option to list grub entries
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 10/25/2012 at 09:02 AM, in message
<20617.21621.886298.796143@mariner.uk.xensource.com>, Ian Jackson
 wrote: 
> Charles Arnold writes ("[Xen-devel]  [PATCH] pygrub: Add option to list grub 
> entries"):
>> pygrub: Add option to list grub entries
>> 
>> The argument to "--entry" allows 2 syntaxes, either directly the entry number
>> in menu.lst, or the whole string behind the "title" key word. This poses the
>> following issue:
>> >From Dom0 there is no way to guess the number and, or the complete title
>> string because this string contains the kernel version, which will change
>> with a kernel update.
>> This patch adds [-l|--list-entries] as an argument to pygrub.
> 
>> +    if list_entries:
>> +        for i in range(len(g.cf.images)):
>> +            img = g.cf.images[i]
>> +            print "title: %s" % img.title
>> +            print "  root: %s" % img.root
>> +            print "  kernel: %s" % img.kernel[1]
>> +            print "  args: %s" % img.args
>> +            print "  initrd: %s" % img.initrd[1]
> 
> Is it possible for any of these to contain newlines ?  I don't think
> so but I'm not entirely sure.  If it is then they need to be quoted
> somehow or the caller may be unable to unambigously parse the output.
> 
> Ian.

No, newlines in the menu.lst / grub.cfg files are treated as terminating
characters for each entry option.  Nothing I've read in the grub specification
indicates that the entries can be wrapped with an escaped newline character.
My attempts to force a newline character in an entry always fails.  The
parsing code in GrubConf.py splits the config file at all newlines.

- Charles



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 19:37:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 19:37:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRTF6-0004tP-80; Thu, 25 Oct 2012 19:37:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRTF4-0004tK-1A
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 19:37:22 +0000
Received: from [85.158.143.35:32725] by server-1.bemta-4.messagelabs.com id
	45/EE-19134-1F499805; Thu, 25 Oct 2012 19:37:21 +0000
X-Env-Sender: carnold@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1351193840!11702643!1
X-Originating-IP: [137.65.248.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM3LjY1LjI0OC43NCA9PiA0MDk5\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1899 invoked from network); 25 Oct 2012 19:37:20 -0000
Received: from novprvoes0310.provo.novell.com (HELO
	novprvoes0310.provo.novell.com) (137.65.248.74)
	by server-7.tower-21.messagelabs.com with SMTP;
	25 Oct 2012 19:37:20 -0000
Received: from INET-PRV-MTA by novprvoes0310.provo.novell.com
	with Novell_GroupWise; Thu, 25 Oct 2012 13:37:19 -0600
Message-Id: <5089408D0200009100082462@novprvoes0310.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.1 
Date: Thu, 25 Oct 2012 13:37:17 -0600
From: "Charles Arnold" 
To: "Ian Jackson" 
References: <50814E190200009100082117@novprvoes0310.provo.novell.com>
	<20617.21621.886298.796143@mariner.uk.xensource.com>
In-Reply-To: <20617.21621.886298.796143@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] pygrub: Add option to list grub entries
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 10/25/2012 at 09:02 AM, in message
<20617.21621.886298.796143@mariner.uk.xensource.com>, Ian Jackson
 wrote: 
> Charles Arnold writes ("[Xen-devel]  [PATCH] pygrub: Add option to list grub 
> entries"):
>> pygrub: Add option to list grub entries
>> 
>> The argument to "--entry" allows 2 syntaxes, either directly the entry number
>> in menu.lst, or the whole string behind the "title" key word. This poses the
>> following issue:
>> >From Dom0 there is no way to guess the number and, or the complete title
>> string because this string contains the kernel version, which will change
>> with a kernel update.
>> This patch adds [-l|--list-entries] as an argument to pygrub.
> 
>> +    if list_entries:
>> +        for i in range(len(g.cf.images)):
>> +            img = g.cf.images[i]
>> +            print "title: %s" % img.title
>> +            print "  root: %s" % img.root
>> +            print "  kernel: %s" % img.kernel[1]
>> +            print "  args: %s" % img.args
>> +            print "  initrd: %s" % img.initrd[1]
> 
> Is it possible for any of these to contain newlines ?  I don't think
> so but I'm not entirely sure.  If it is then they need to be quoted
> somehow or the caller may be unable to unambigously parse the output.
> 
> Ian.

No, newlines in the menu.lst / grub.cfg files are treated as terminating
characters for each entry option.  Nothing I've read in the grub specification
indicates that the entries can be wrapped with an escaped newline character.
My attempts to force a newline character in an entry always fails.  The
parsing code in GrubConf.py splits the config file at all newlines.

- Charles



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 20:14:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 20:14:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRToH-0005Bw-BS; Thu, 25 Oct 2012 20:13:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRToF-0005Br-M0
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 20:13:44 +0000
Received: from [85.158.137.99:55890] by server-2.bemta-3.messagelabs.com id
	AB/D4-00604-67D99805; Thu, 25 Oct 2012 20:13:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1351196021!12417233!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10276 invoked from network); 25 Oct 2012 20:13:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 20:13:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,650,1344211200"; d="scan'208";a="15398071"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 20:13:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 21:13:41 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TRToD-00012v-50;
	Thu, 25 Oct 2012 20:13:41 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TRToC-0006XE-Ie;
	Thu, 25 Oct 2012 21:13:40 +0100
To: 
Message-ID: 
From: xen.org 
Date: Thu, 25 Oct 2012 21:13:40 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 14076: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14076 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14076/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  40ccbee890e1
baseline version:
 xen                  27db446078b5

------------------------------------------------------------
People who touched revisions under test:
  Christoph Egger 
  Dario Faggioli 
  George Dunlap 
  Jacob Shin 
  Jan Beulich 
  Keir Fraser 
  Olaf Hering 
  Tim Deegan 
  Wei Wang 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-4.2-testing
+ revision=40ccbee890e1
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.2-testing 40ccbee890e1
+ branch=xen-4.2-testing
+ revision=40ccbee890e1
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.2-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-4.2-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.2-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.2-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.2-testing.git
++ : daily-cron.xen-4.2-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.2-testing.git
+ info_linux_tree xen-4.2-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.2-testing.hg
+ hg push -r 40ccbee890e1 ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 10 changesets with 11 changes to 9 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 20:14:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 20:14:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRToH-0005Bw-BS; Thu, 25 Oct 2012 20:13:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRToF-0005Br-M0
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 20:13:44 +0000
Received: from [85.158.137.99:55890] by server-2.bemta-3.messagelabs.com id
	AB/D4-00604-67D99805; Thu, 25 Oct 2012 20:13:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1351196021!12417233!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTU3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10276 invoked from network); 25 Oct 2012 20:13:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 20:13:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,650,1344211200"; d="scan'208";a="15398071"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 20:13:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 21:13:41 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TRToD-00012v-50;
	Thu, 25 Oct 2012 20:13:41 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TRToC-0006XE-Ie;
	Thu, 25 Oct 2012 21:13:40 +0100
To: 
Message-ID: 
From: xen.org 
Date: Thu, 25 Oct 2012 21:13:40 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 14076: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14076 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14076/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  40ccbee890e1
baseline version:
 xen                  27db446078b5

------------------------------------------------------------
People who touched revisions under test:
  Christoph Egger 
  Dario Faggioli 
  George Dunlap 
  Jacob Shin 
  Jan Beulich 
  Keir Fraser 
  Olaf Hering 
  Tim Deegan 
  Wei Wang 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-4.2-testing
+ revision=40ccbee890e1
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.2-testing 40ccbee890e1
+ branch=xen-4.2-testing
+ revision=40ccbee890e1
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.2-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-4.2-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.2-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.2-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.2-testing.git
++ : daily-cron.xen-4.2-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.2-testing.git
+ info_linux_tree xen-4.2-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.2-testing.hg
+ hg push -r 40ccbee890e1 ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 10 changesets with 11 changes to 9 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 20:57:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 20:57:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRUU6-0005j8-OL; Thu, 25 Oct 2012 20:56:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRUU5-0005j3-9J
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 20:56:57 +0000
Received: from [85.158.143.35:5142] by server-3.bemta-4.messagelabs.com id
	84/EA-24279-897A9805; Thu, 25 Oct 2012 20:56:56 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1351198615!15828409!1
X-Originating-IP: [140.77.166.68]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31088 invoked from network); 25 Oct 2012 20:56:55 -0000
Received: from toccata.ens-lyon.fr (HELO toccata.ens-lyon.org) (140.77.166.68)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Oct 2012 20:56:55 -0000
Received: from localhost (localhost [127.0.0.1])
	by toccata.ens-lyon.org (Postfix) with ESMTP id A577884095;
	Thu, 25 Oct 2012 22:56:54 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at toccata.ens-lyon.org
Received: from toccata.ens-lyon.org ([127.0.0.1])
	by localhost (toccata.ens-lyon.org [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id m2jMpOKX90-X; Thu, 25 Oct 2012 22:56:54 +0200 (CEST)
Received: from type.ipv6 (chello080108109065.34.11.vie.surfer.at
	[80.108.109.65])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by toccata.ens-lyon.org (Postfix) with ESMTPSA id 57A5D8408D;
	Thu, 25 Oct 2012 22:56:54 +0200 (CEST)
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from )
	id 1TRUU1-00029w-AA; Thu, 25 Oct 2012 22:56:53 +0200
Date: Thu, 25 Oct 2012 22:56:53 +0200
From: Samuel Thibault 
To: Xu Zhang 
Message-ID: <20121025205653.GW5925@type.chello.at>
Mail-Followup-To: Samuel Thibault ,
	Xu Zhang ,
	"xen-devel@lists.xen.org" ,
	gm281@cam.ac.uk
References: <50871D90.50606@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50871D90.50606@gmail.com>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: gm281@cam.ac.uk, "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Nested events in 64bit mini-OS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Xu Zhang, le Tue 23 Oct 2012 17:43:28 -0500, a =E9crit :
> 64-bit mini-OS seems to adopt a mixed use of both (in HYPERVISOR_IRET).
> mini-OS doesn't have an userspace, so unless an NMI happened, it always
> perform interrupt/exception return with machine instruction iret, without
> checking against nested events. This is wrong to me. Am I missing somethi=
ng
> here?

I don't think you are missing anything. Cc-ing Grzegorz, who actually
wrote the code.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 20:57:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 20:57:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRUU6-0005j8-OL; Thu, 25 Oct 2012 20:56:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRUU5-0005j3-9J
	for xen-devel@lists.xen.org; Thu, 25 Oct 2012 20:56:57 +0000
Received: from [85.158.143.35:5142] by server-3.bemta-4.messagelabs.com id
	84/EA-24279-897A9805; Thu, 25 Oct 2012 20:56:56 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1351198615!15828409!1
X-Originating-IP: [140.77.166.68]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31088 invoked from network); 25 Oct 2012 20:56:55 -0000
Received: from toccata.ens-lyon.fr (HELO toccata.ens-lyon.org) (140.77.166.68)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Oct 2012 20:56:55 -0000
Received: from localhost (localhost [127.0.0.1])
	by toccata.ens-lyon.org (Postfix) with ESMTP id A577884095;
	Thu, 25 Oct 2012 22:56:54 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at toccata.ens-lyon.org
Received: from toccata.ens-lyon.org ([127.0.0.1])
	by localhost (toccata.ens-lyon.org [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id m2jMpOKX90-X; Thu, 25 Oct 2012 22:56:54 +0200 (CEST)
Received: from type.ipv6 (chello080108109065.34.11.vie.surfer.at
	[80.108.109.65])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by toccata.ens-lyon.org (Postfix) with ESMTPSA id 57A5D8408D;
	Thu, 25 Oct 2012 22:56:54 +0200 (CEST)
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from )
	id 1TRUU1-00029w-AA; Thu, 25 Oct 2012 22:56:53 +0200
Date: Thu, 25 Oct 2012 22:56:53 +0200
From: Samuel Thibault 
To: Xu Zhang 
Message-ID: <20121025205653.GW5925@type.chello.at>
Mail-Followup-To: Samuel Thibault ,
	Xu Zhang ,
	"xen-devel@lists.xen.org" ,
	gm281@cam.ac.uk
References: <50871D90.50606@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50871D90.50606@gmail.com>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: gm281@cam.ac.uk, "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Nested events in 64bit mini-OS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Xu Zhang, le Tue 23 Oct 2012 17:43:28 -0500, a =E9crit :
> 64-bit mini-OS seems to adopt a mixed use of both (in HYPERVISOR_IRET).
> mini-OS doesn't have an userspace, so unless an NMI happened, it always
> perform interrupt/exception return with machine instruction iret, without
> checking against nested events. This is wrong to me. Am I missing somethi=
ng
> here?

I don't think you are missing anything. Cc-ing Grzegorz, who actually
wrote the code.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 21:51:15 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 21:51:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRVKA-00063E-Vh; Thu, 25 Oct 2012 21:50:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRVK9-000636-Oc
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 21:50:46 +0000
Received: from [193.109.254.147:14636] by server-13.bemta-14.messagelabs.com
	id 66/8E-11239-534B9805; Thu, 25 Oct 2012 21:50:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1351201843!11183212!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYxMTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6077 invoked from network); 25 Oct 2012 21:50:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 21:50:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,650,1344211200"; d="scan'208";a="15398734"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 21:50:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 22:50:42 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TRVK6-0001be-Fu;
	Thu, 25 Oct 2012 21:50:42 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TRVK6-00088q-9h;
	Thu, 25 Oct 2012 22:50:42 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Thu, 25 Oct 2012 22:50:42 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14077: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14077 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14077/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 14075
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 14075
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 14075
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 14075

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  1883c1d29de9
baseline version:
 xen                  22e08c9ac770

------------------------------------------------------------
People who touched revisions under test:
  Christoph Egger 
  Ian Jackson 
  Jan Beulich 
  Keir Fraser 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=1883c1d29de9
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 1883c1d29de9
+ branch=xen-unstable
+ revision=1883c1d29de9
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 1883c1d29de9 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 4 changesets with 11 changes to 11 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 21:51:15 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 21:51:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRVKA-00063E-Vh; Thu, 25 Oct 2012 21:50:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRVK9-000636-Oc
	for xen-devel@lists.xensource.com; Thu, 25 Oct 2012 21:50:46 +0000
Received: from [193.109.254.147:14636] by server-13.bemta-14.messagelabs.com
	id 66/8E-11239-534B9805; Thu, 25 Oct 2012 21:50:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1351201843!11183212!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYxMTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6077 invoked from network); 25 Oct 2012 21:50:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 21:50:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,650,1344211200"; d="scan'208";a="15398734"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Oct 2012 21:50:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 25 Oct 2012 22:50:42 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TRVK6-0001be-Fu;
	Thu, 25 Oct 2012 21:50:42 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TRVK6-00088q-9h;
	Thu, 25 Oct 2012 22:50:42 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Thu, 25 Oct 2012 22:50:42 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14077: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14077 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14077/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 14075
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 14075
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 14075
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 14075

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  1883c1d29de9
baseline version:
 xen                  22e08c9ac770

------------------------------------------------------------
People who touched revisions under test:
  Christoph Egger 
  Ian Jackson 
  Jan Beulich 
  Keir Fraser 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=1883c1d29de9
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 1883c1d29de9
+ branch=xen-unstable
+ revision=1883c1d29de9
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 1883c1d29de9 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 4 changesets with 11 changes to 11 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Oct 25 23:12:23 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 23:12:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRWah-0006e2-Qt; Thu, 25 Oct 2012 23:11:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRWag-0006dx-TM
	for Xen-devel@lists.xen.org; Thu, 25 Oct 2012 23:11:55 +0000
Received: from [85.158.139.211:43892] by server-15.bemta-5.messagelabs.com id
	5C/56-26920-A37C9805; Thu, 25 Oct 2012 23:11:54 +0000
X-Env-Sender: xinxinjin89@gmail.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1351206712!23801830!1
X-Originating-IP: [209.85.216.52]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5368 invoked from network); 25 Oct 2012 23:11:53 -0000
Received: from mail-qa0-f52.google.com (HELO mail-qa0-f52.google.com)
	(209.85.216.52)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 23:11:53 -0000
Received: by mail-qa0-f52.google.com with SMTP id g24so31989qab.11
	for ; Thu, 25 Oct 2012 16:11:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=ujwAMaMLieSRDDuEH+jdPbYauUV+3REfq8Aqy/ptoUA=;
	b=yg05smtcG97QVhC0LPw/0LoMZ6ewtbmW62+tokh4mz2zFc8BQlgcg+s1LyKxVo0/XD
	Pwanx5NfohQnQ68Jb1pyDmIciiITB2eo2HJgiNfIc81dRlXJV9xRqqdQJKo+Xy72RSzK
	ubcBpqZevZmYp6N3i9yC5UCCMdLccn1qpvnFcSn4O9+K6J47D2RyYte0TTqlt+0I9Qyj
	JGGkSMwXJyyWU9H13urK/yiXr6ZCLS+j59JyRWcfjgas9pXq/w+fgeEWECycuLLYo1OJ
	H9+QoCDz1VMPhQXwHwjEcfNvkf+mo7hwNK8grrkj4juaV+s7QL3l/LimvE0XANt4nhI/
	Ph2A==
MIME-Version: 1.0
Received: by 10.49.96.162 with SMTP id dt2mr11977953qeb.48.1351206712336; Thu,
	25 Oct 2012 16:11:52 -0700 (PDT)
Received: by 10.229.235.13 with HTTP; Thu, 25 Oct 2012 16:11:52 -0700 (PDT)
Date: Thu, 25 Oct 2012 16:11:52 -0700
Message-ID: 
From: Xinxin Jin 
To: Xen-devel@lists.xen.org
Subject: [Xen-devel] What is fastcall in Xen?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============8799397187194971324=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8799397187194971324==
Content-Type: multipart/alternative; boundary=047d7bb04e401b62c704ccea5445

--047d7bb04e401b62c704ccea5445
Content-Type: text/plain; charset=ISO-8859-1

Hi, I found some interrupt handler functions are declared with "fastcall"
keyword, such as:
fastcall void event_check_interrupt(void);
So what does fastcall implicate here? Is there some special things in the
fastcall handling ?
Thanks,

-- 
Xinxin

--047d7bb04e401b62c704ccea5445
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Hi, I found some interrupt handler functions are declared with "f=
astcall" keyword, such as:
fastcall void event_check_interrupt(vo=
id);
So what does fastcall implicate here? Is there s=
ome special things in the fastcall handling ?


Thanks,

-- 
Xinxin






--047d7bb04e401b62c704ccea5445--


--===============8799397187194971324==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8799397187194971324==--


From xen-devel-bounces@lists.xen.org Thu Oct 25 23:12:23 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 23:12:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRWah-0006e2-Qt; Thu, 25 Oct 2012 23:11:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRWag-0006dx-TM
	for Xen-devel@lists.xen.org; Thu, 25 Oct 2012 23:11:55 +0000
Received: from [85.158.139.211:43892] by server-15.bemta-5.messagelabs.com id
	5C/56-26920-A37C9805; Thu, 25 Oct 2012 23:11:54 +0000
X-Env-Sender: xinxinjin89@gmail.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1351206712!23801830!1
X-Originating-IP: [209.85.216.52]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5368 invoked from network); 25 Oct 2012 23:11:53 -0000
Received: from mail-qa0-f52.google.com (HELO mail-qa0-f52.google.com)
	(209.85.216.52)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 23:11:53 -0000
Received: by mail-qa0-f52.google.com with SMTP id g24so31989qab.11
	for ; Thu, 25 Oct 2012 16:11:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=ujwAMaMLieSRDDuEH+jdPbYauUV+3REfq8Aqy/ptoUA=;
	b=yg05smtcG97QVhC0LPw/0LoMZ6ewtbmW62+tokh4mz2zFc8BQlgcg+s1LyKxVo0/XD
	Pwanx5NfohQnQ68Jb1pyDmIciiITB2eo2HJgiNfIc81dRlXJV9xRqqdQJKo+Xy72RSzK
	ubcBpqZevZmYp6N3i9yC5UCCMdLccn1qpvnFcSn4O9+K6J47D2RyYte0TTqlt+0I9Qyj
	JGGkSMwXJyyWU9H13urK/yiXr6ZCLS+j59JyRWcfjgas9pXq/w+fgeEWECycuLLYo1OJ
	H9+QoCDz1VMPhQXwHwjEcfNvkf+mo7hwNK8grrkj4juaV+s7QL3l/LimvE0XANt4nhI/
	Ph2A==
MIME-Version: 1.0
Received: by 10.49.96.162 with SMTP id dt2mr11977953qeb.48.1351206712336; Thu,
	25 Oct 2012 16:11:52 -0700 (PDT)
Received: by 10.229.235.13 with HTTP; Thu, 25 Oct 2012 16:11:52 -0700 (PDT)
Date: Thu, 25 Oct 2012 16:11:52 -0700
Message-ID: 
From: Xinxin Jin 
To: Xen-devel@lists.xen.org
Subject: [Xen-devel] What is fastcall in Xen?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============8799397187194971324=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8799397187194971324==
Content-Type: multipart/alternative; boundary=047d7bb04e401b62c704ccea5445

--047d7bb04e401b62c704ccea5445
Content-Type: text/plain; charset=ISO-8859-1

Hi, I found some interrupt handler functions are declared with "fastcall"
keyword, such as:
fastcall void event_check_interrupt(void);
So what does fastcall implicate here? Is there some special things in the
fastcall handling ?
Thanks,

-- 
Xinxin

--047d7bb04e401b62c704ccea5445
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Hi, I found some interrupt handler functions are declared with "f=
astcall" keyword, such as:
fastcall void event_check_interrupt(vo=
id);
So what does fastcall implicate here? Is there s=
ome special things in the fastcall handling ?


Thanks,

-- 
Xinxin






--047d7bb04e401b62c704ccea5445--


--===============8799397187194971324==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8799397187194971324==--


From xen-devel-bounces@lists.xen.org Thu Oct 25 23:38:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 23:38:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRX0P-0006rY-2X; Thu, 25 Oct 2012 23:38:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRX0O-0006rT-1N
	for Xen-devel@lists.xen.org; Thu, 25 Oct 2012 23:38:28 +0000
Received: from [193.109.254.147:24178] by server-14.bemta-14.messagelabs.com
	id CB/52-14517-37DC9805; Thu, 25 Oct 2012 23:38:27 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1351208304!6251321!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=1.4 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	MAILTO_TO_SPAM_ADDR, MIME_QP_LONG_LINE, ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP, spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7463 invoked from network); 25 Oct 2012 23:38:26 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 23:38:26 -0000
Received: by mail-pb0-f45.google.com with SMTP id rp2so2465573pbb.32
	for ; Thu, 25 Oct 2012 16:38:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type;
	bh=m8PrD9fCmzzEhv0cB2Q2AXkMpb4cJTlBxAmV09YImCk=;
	b=mxdsTw4LuJDdLO3L3OqycXKrq2F/dIOdNlKlrcIKPLF//FHEWe51yP52KOhESMpGmW
	5s8ebQ2MFw2erK8VaRgp5rvsIiih2MA8kLY1QApj+2mdYUuOJ5KAixt/CSPqVB4O+vdU
	ttOSE3qlauIesYcdsqv4FFPG8hdPb6mmuntU5pfUFb1ar99wNyGE3BJefui2ZGgpyJJZ
	JEyb3eBZe3bJOP7/lcN79CsEeQeoW8q1/SY814iOp3MBorDZoL7GYgAEG0f55xAMb6vo
	jTk3Cz7ZhbmioxvPvQMnPKfVjMJ8LJZsHnLjLPxstbm3sxr2WYg0DZ8XQr1nYBCNzqtT
	dcdw==
Received: by 10.68.209.136 with SMTP id mm8mr63858124pbc.146.1351208304182;
	Thu, 25 Oct 2012 16:38:24 -0700 (PDT)
Received: from [10.128.0.122] (S0106001c25a066a0.vc.shawcable.net.
	[24.85.255.130])
	by mx.google.com with ESMTPS id ho7sm140464pbc.3.2012.10.25.16.38.22
	(version=SSLv3 cipher=OTHER); Thu, 25 Oct 2012 16:38:23 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Thu, 25 Oct 2012 16:38:18 -0700
From: Keir Fraser 
To: Xinxin Jin ,
	
Message-ID: 
Thread-Topic: [Xen-devel] What is fastcall in Xen?
Thread-Index: Ac2zCc9xosyTeUVZPEKm4Nd6JE6S/g==
In-Reply-To: 
Mime-version: 1.0
Subject: Re: [Xen-devel] What is fastcall in Xen?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1438027790141072984=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============1438027790141072984==
Content-type: multipart/alternative;
	boundary="B_3434027902_76509252"

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3434027902_76509252
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

No, fastcall is defined away to nothing.


On 25/10/2012 16:11, "Xinxin Jin"  wrote:

> Hi, I found some interrupt handler functions are declared with "fastcall"
> keyword, such as:
> fastcall void event_check_interrupt(void);
> So what does fastcall implicate here? Is there some special things in the
> fastcall handling ?
> Thanks,


--B_3434027902_76509252
Content-type: text/html;
	charset="US-ASCII"
Content-transfer-encoding: quoted-printable



Re: [Xen-devel] What is fastcall in Xen?


No, fastcall is defined away to nothing.





On 25/10/2012 16:11, "Xinxin Jin" <xinxinjin89@gmail.com> wrote:




<=
SPAN STYLE=3D'font-size:11pt'>Hi, I found some interrupt handler functions are=
 declared with "fastcall" keyword, such as:

fastcall void event_check_interrupt(void);

So what does fastcall implicate here? Is there some special things in the f=
astcall handling ?

Thanks,







--B_3434027902_76509252--




--===============1438027790141072984==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1438027790141072984==--




From xen-devel-bounces@lists.xen.org Thu Oct 25 23:38:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 25 Oct 2012 23:38:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRX0P-0006rY-2X; Thu, 25 Oct 2012 23:38:29 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRX0O-0006rT-1N
	for Xen-devel@lists.xen.org; Thu, 25 Oct 2012 23:38:28 +0000
Received: from [193.109.254.147:24178] by server-14.bemta-14.messagelabs.com
	id CB/52-14517-37DC9805; Thu, 25 Oct 2012 23:38:27 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1351208304!6251321!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=1.4 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	MAILTO_TO_SPAM_ADDR, MIME_QP_LONG_LINE, ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP, spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7463 invoked from network); 25 Oct 2012 23:38:26 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Oct 2012 23:38:26 -0000
Received: by mail-pb0-f45.google.com with SMTP id rp2so2465573pbb.32
	for ; Thu, 25 Oct 2012 16:38:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type;
	bh=m8PrD9fCmzzEhv0cB2Q2AXkMpb4cJTlBxAmV09YImCk=;
	b=mxdsTw4LuJDdLO3L3OqycXKrq2F/dIOdNlKlrcIKPLF//FHEWe51yP52KOhESMpGmW
	5s8ebQ2MFw2erK8VaRgp5rvsIiih2MA8kLY1QApj+2mdYUuOJ5KAixt/CSPqVB4O+vdU
	ttOSE3qlauIesYcdsqv4FFPG8hdPb6mmuntU5pfUFb1ar99wNyGE3BJefui2ZGgpyJJZ
	JEyb3eBZe3bJOP7/lcN79CsEeQeoW8q1/SY814iOp3MBorDZoL7GYgAEG0f55xAMb6vo
	jTk3Cz7ZhbmioxvPvQMnPKfVjMJ8LJZsHnLjLPxstbm3sxr2WYg0DZ8XQr1nYBCNzqtT
	dcdw==
Received: by 10.68.209.136 with SMTP id mm8mr63858124pbc.146.1351208304182;
	Thu, 25 Oct 2012 16:38:24 -0700 (PDT)
Received: from [10.128.0.122] (S0106001c25a066a0.vc.shawcable.net.
	[24.85.255.130])
	by mx.google.com with ESMTPS id ho7sm140464pbc.3.2012.10.25.16.38.22
	(version=SSLv3 cipher=OTHER); Thu, 25 Oct 2012 16:38:23 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Thu, 25 Oct 2012 16:38:18 -0700
From: Keir Fraser 
To: Xinxin Jin ,
	
Message-ID: 
Thread-Topic: [Xen-devel] What is fastcall in Xen?
Thread-Index: Ac2zCc9xosyTeUVZPEKm4Nd6JE6S/g==
In-Reply-To: 
Mime-version: 1.0
Subject: Re: [Xen-devel] What is fastcall in Xen?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1438027790141072984=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============1438027790141072984==
Content-type: multipart/alternative;
	boundary="B_3434027902_76509252"

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3434027902_76509252
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

No, fastcall is defined away to nothing.


On 25/10/2012 16:11, "Xinxin Jin"  wrote:

> Hi, I found some interrupt handler functions are declared with "fastcall"
> keyword, such as:
> fastcall void event_check_interrupt(void);
> So what does fastcall implicate here? Is there some special things in the
> fastcall handling ?
> Thanks,


--B_3434027902_76509252
Content-type: text/html;
	charset="US-ASCII"
Content-transfer-encoding: quoted-printable



Re: [Xen-devel] What is fastcall in Xen?


No, fastcall is defined away to nothing.





On 25/10/2012 16:11, "Xinxin Jin" <xinxinjin89@gmail.com> wrote:




<=
SPAN STYLE=3D'font-size:11pt'>Hi, I found some interrupt handler functions are=
 declared with "fastcall" keyword, such as:

fastcall void event_check_interrupt(void);

So what does fastcall implicate here? Is there some special things in the f=
astcall handling ?

Thanks,







--B_3434027902_76509252--




--===============1438027790141072984==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1438027790141072984==--




From xen-devel-bounces@lists.xen.org Fri Oct 26 01:39:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 01:39:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRYsb-00038b-DZ; Fri, 26 Oct 2012 01:38:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRYsZ-00038W-5k
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 01:38:31 +0000
Received: from [85.158.138.51:11944] by server-12.bemta-3.messagelabs.com id
	02/26-27853-699E9805; Fri, 26 Oct 2012 01:38:30 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1351215508!23436732!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODI0OTM3\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12818 invoked from network); 26 Oct 2012 01:38:29 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Oct 2012 01:38:29 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9Q1cPcf013410
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 26 Oct 2012 01:38:25 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9Q1cODx012306
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 26 Oct 2012 01:38:24 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9Q1cNmt011915; Thu, 25 Oct 2012 20:38:23 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 25 Oct 2012 18:38:23 -0700
Date: Thu, 25 Oct 2012 18:38:22 -0700
From: Mukesh Rathor 
To: Ian Campbell 
Message-ID: <20121025183822.1ec77078@mantra.us.oracle.com>
In-Reply-To: <1351084777-28898-5-git-send-email-ian.campbell@citrix.com>
References: <1351084756.18035.28.camel@zakaz.uk.xensource.com>
	<1351084777-28898-5-git-send-email-ian.campbell@citrix.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel ,
	Stefano Stabellini ,
	linux-kernel ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 5/5] xen: x86 pvh: use
 XENMEM_add_to_physmap_range for foreign gmfn mappings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 24 Oct 2012 14:19:37 +0100
Ian Campbell  wrote:

> Squeezing the necessary fields into the existing XENMEM_add_to_physmap
> interface was proving to be a bit tricky so we have decided to go with
> a new interface upstream (the XENMAPSPACE_gmfn_foreign interface using
> XENMEM_add_to_physmap was never committed anywhere). This interface
> also allows for batching which was impossible to support at the same
> time as foreign mfns in the old interface.
> 
> This reverts the relevant parts of "PVH: basic and header changes,
> elfnote changes, ..." and followups and trivially converts
> pvh_add_to_xen_p2m over.
> 
> Signed-off-by: Ian Campbell 
> Acked-by: Stefano Stabellini 

Ok, I made the change on the xen side for x86 and tested it out. Works
fine. Second ack.

thanks, 
Mukesh


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 01:39:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 01:39:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRYsb-00038b-DZ; Fri, 26 Oct 2012 01:38:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRYsZ-00038W-5k
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 01:38:31 +0000
Received: from [85.158.138.51:11944] by server-12.bemta-3.messagelabs.com id
	02/26-27853-699E9805; Fri, 26 Oct 2012 01:38:30 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1351215508!23436732!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODI0OTM3\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12818 invoked from network); 26 Oct 2012 01:38:29 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Oct 2012 01:38:29 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9Q1cPcf013410
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 26 Oct 2012 01:38:25 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9Q1cODx012306
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 26 Oct 2012 01:38:24 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9Q1cNmt011915; Thu, 25 Oct 2012 20:38:23 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 25 Oct 2012 18:38:23 -0700
Date: Thu, 25 Oct 2012 18:38:22 -0700
From: Mukesh Rathor 
To: Ian Campbell 
Message-ID: <20121025183822.1ec77078@mantra.us.oracle.com>
In-Reply-To: <1351084777-28898-5-git-send-email-ian.campbell@citrix.com>
References: <1351084756.18035.28.camel@zakaz.uk.xensource.com>
	<1351084777-28898-5-git-send-email-ian.campbell@citrix.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel ,
	Stefano Stabellini ,
	linux-kernel ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 5/5] xen: x86 pvh: use
 XENMEM_add_to_physmap_range for foreign gmfn mappings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 24 Oct 2012 14:19:37 +0100
Ian Campbell  wrote:

> Squeezing the necessary fields into the existing XENMEM_add_to_physmap
> interface was proving to be a bit tricky so we have decided to go with
> a new interface upstream (the XENMAPSPACE_gmfn_foreign interface using
> XENMEM_add_to_physmap was never committed anywhere). This interface
> also allows for batching which was impossible to support at the same
> time as foreign mfns in the old interface.
> 
> This reverts the relevant parts of "PVH: basic and header changes,
> elfnote changes, ..." and followups and trivially converts
> pvh_add_to_xen_p2m over.
> 
> Signed-off-by: Ian Campbell 
> Acked-by: Stefano Stabellini 

Ok, I made the change on the xen side for x86 and tested it out. Works
fine. Second ack.

thanks, 
Mukesh


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 01:40:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 01:40:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRYuD-0003Cp-Tb; Fri, 26 Oct 2012 01:40:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRYuC-0003Ch-Ja
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 01:40:12 +0000
Received: from [85.158.138.51:15953] by server-5.bemta-3.messagelabs.com id
	5A/6C-12440-BF9E9805; Fri, 26 Oct 2012 01:40:11 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1351215609!8790692!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAxODQ5MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6115 invoked from network); 26 Oct 2012 01:40:10 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Oct 2012 01:40:10 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9Q1e0KV024026
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 26 Oct 2012 01:40:01 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9Q1e0Se010966
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 26 Oct 2012 01:40:00 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9Q1dxLC011494; Thu, 25 Oct 2012 20:39:59 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 25 Oct 2012 18:39:59 -0700
Date: Thu, 25 Oct 2012 18:39:58 -0700
From: Mukesh Rathor 
To: Ian Campbell 
Message-ID: <20121025183958.0a4ae846@mantra.us.oracle.com>
In-Reply-To: <1351151219.18035.94.camel@zakaz.uk.xensource.com>
References: <1351084756.18035.28.camel@zakaz.uk.xensource.com>
	<1351084777-28898-4-git-send-email-ian.campbell@citrix.com>
	<20121024164411.5b000087@mantra.us.oracle.com>
	<20121024170746.7c89a790@mantra.us.oracle.com>
	<1351151219.18035.94.camel@zakaz.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Stefano Stabellini ,
	linux-kernel ,
	Konrad Rzeszutek Wilk ,
	xen-devel 
Subject: Re: [Xen-devel] [PATCH 4/5] xen: arm: implement remap interfaces
 needed for privcmd mappings.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVGh1LCAyNSBPY3QgMjAxMiAwODo0Njo1OSArMDEwMApJYW4gQ2FtcGJlbGwgPElhbi5DYW1w
YmVsbEBjaXRyaXguY29tPiB3cm90ZToKCj4gT24gVGh1LCAyMDEyLTEwLTI1IGF0IDAxOjA3ICsw
MTAwLCBNdWtlc2ggUmF0aG9yIHdyb3RlOgo+ID4gT24gV2VkLCAyNCBPY3QgMjAxMiAxNjo0NDox
MSAtMDcwMAo+ID4gTXVrZXNoIFJhdGhvciA8bXVrZXNoLnJhdGhvckBvcmFjbGUuY29tPiB3cm90
ZToKPiA+IAo+ID4gPiA+ICAKPiA+ID4gPiArICAgIC8qIEluZGV4ZXMgaW50byBzcGFjZSBiZWlu
ZyBtYXBwZWQuICovCj4gPiA+ID4gKyAgICBHVUVTVF9IQU5ETEUoeGVuX3Vsb25nX3QpIGlkeHM7
Cj4gPiA+ID4gKwo+ID4gPiA+ICsgICAgLyogR1BGTiBpbiBkb21pZCB3aGVyZSB0aGUgc291cmNl
IG1hcHBpbmcgcGFnZSBzaG91bGQKPiA+ID4gPiBhcHBlYXIuICovCj4gPiA+ID4gKyAgICBHVUVT
VF9IQU5ETEUoeGVuX3Bmbl90KSBncGZuczsKPiA+ID4gCj4gPiA+IAo+ID4gPiBMb29raW5nIGF0
IHlvdXIgYXJtIGltcGxlbWVudGF0aW9uIGluIHhlbiwgZG9lc24ndCBsb29rIGxpa2UgeW91Cj4g
PiA+IGFyZSBleHBlY3RpbmcgaWR4cyBhbmQgZ3BmbnMgdG8gYmUgY29udGlnb3VzLiBJbiB0aGF0
IGNhc2UsCj4gPiA+IHNob3VsZG4ndCBpZHhzIGFuZCBncGZucyBiZSBwb2ludGVycywgaWUsIHRo
ZXkgYXJlIHNlbnQgZG93biBhcwo+ID4gPiBhcnJheXM/IE9yIGRvZXMgR1VFU1RfSEFORExFIGRv
IHRoYXQsIEkgY2FuJ3Qgc2VlbSB0byBmaW5kIHdoZXJlCj4gPiA+IGl0J3MgZGVmaW5lZCBxdWlj
a2x5Lgo+ID4gCj4gPiBOZXZlciBtaW5kLCBJIHNlZSBpdCBnb3QgY29ycmVjdGVkIHRvIFhFTl9H
VUVTVF9IQU5ETEUgaW4gc3RhZ2luZwo+ID4gdHJlZS4KPiAKPiBUaGUgbWFjcm8gaXMgY2FsbGVk
IFhFTl9HVUVTVF9IQU5ETEUgaW4gWGVuIGFuZCBqdXN0IEdVRVNUX0hBTkRMRSBpbgo+IExpbnV4
Lgo+IAo+ID4gU3RpbGwgZG9lc24ndCBjb21waWxlIHRobzoKPiA+IAo+ID4gcHVibGljL21lbW9y
eS5oOjI0NjogZXJyb3I6IGV4cGVjdGVkIHNwZWNpZmllci1xdWFsaWZpZXItbGlzdCBiZWZvcmUK
PiA+IOKAmF9fZ3Vlc3RfaGFuZGxlX3hlbl91bG9uZ1904oCZCj4gPiAKPiA+IEknbGwgZmlndXJl
IGl0IG91dC4KPiAKPiBMb29rcyBsaWtlIHlvdSd2ZSBnb3QgaXQgYWxsIHNvcnRlZD8KCll1cC4g
SSBtYWRlIHRoZSBjaGFuZ2Ugb24geGVuIHNpZGUgYW5kIGFkZGVkIHRoaXMgcGF0Y2ggdG8gbXkg
dHJlZQphbmQgZ290IGl0IHdvcmtpbmcgYWZ0ZXIgcmV2ZXJ0aW5nIEtvbnJhZCdzIHNldHVwLmMg
Y2hhbmdlcy4gTm90IHN1cmUKaWYgeW91IG5lZWQgYW4gYWNrIGZyb20geDg2LCBidXQgaWYgeW91
IGRvOgoKQWNrZWQtYnk6IE11a2VzaCBSYXRob3IgPG11a2VzaC5yYXRob3JAb3JhY2xlLmNvbT4K
CnRoYW5rcwpNdWtlc2gKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0
dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Fri Oct 26 01:40:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 01:40:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRYuD-0003Cp-Tb; Fri, 26 Oct 2012 01:40:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRYuC-0003Ch-Ja
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 01:40:12 +0000
Received: from [85.158.138.51:15953] by server-5.bemta-3.messagelabs.com id
	5A/6C-12440-BF9E9805; Fri, 26 Oct 2012 01:40:11 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1351215609!8790692!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAxODQ5MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6115 invoked from network); 26 Oct 2012 01:40:10 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Oct 2012 01:40:10 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9Q1e0KV024026
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 26 Oct 2012 01:40:01 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9Q1e0Se010966
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 26 Oct 2012 01:40:00 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9Q1dxLC011494; Thu, 25 Oct 2012 20:39:59 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 25 Oct 2012 18:39:59 -0700
Date: Thu, 25 Oct 2012 18:39:58 -0700
From: Mukesh Rathor 
To: Ian Campbell 
Message-ID: <20121025183958.0a4ae846@mantra.us.oracle.com>
In-Reply-To: <1351151219.18035.94.camel@zakaz.uk.xensource.com>
References: <1351084756.18035.28.camel@zakaz.uk.xensource.com>
	<1351084777-28898-4-git-send-email-ian.campbell@citrix.com>
	<20121024164411.5b000087@mantra.us.oracle.com>
	<20121024170746.7c89a790@mantra.us.oracle.com>
	<1351151219.18035.94.camel@zakaz.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Stefano Stabellini ,
	linux-kernel ,
	Konrad Rzeszutek Wilk ,
	xen-devel 
Subject: Re: [Xen-devel] [PATCH 4/5] xen: arm: implement remap interfaces
 needed for privcmd mappings.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVGh1LCAyNSBPY3QgMjAxMiAwODo0Njo1OSArMDEwMApJYW4gQ2FtcGJlbGwgPElhbi5DYW1w
YmVsbEBjaXRyaXguY29tPiB3cm90ZToKCj4gT24gVGh1LCAyMDEyLTEwLTI1IGF0IDAxOjA3ICsw
MTAwLCBNdWtlc2ggUmF0aG9yIHdyb3RlOgo+ID4gT24gV2VkLCAyNCBPY3QgMjAxMiAxNjo0NDox
MSAtMDcwMAo+ID4gTXVrZXNoIFJhdGhvciA8bXVrZXNoLnJhdGhvckBvcmFjbGUuY29tPiB3cm90
ZToKPiA+IAo+ID4gPiA+ICAKPiA+ID4gPiArICAgIC8qIEluZGV4ZXMgaW50byBzcGFjZSBiZWlu
ZyBtYXBwZWQuICovCj4gPiA+ID4gKyAgICBHVUVTVF9IQU5ETEUoeGVuX3Vsb25nX3QpIGlkeHM7
Cj4gPiA+ID4gKwo+ID4gPiA+ICsgICAgLyogR1BGTiBpbiBkb21pZCB3aGVyZSB0aGUgc291cmNl
IG1hcHBpbmcgcGFnZSBzaG91bGQKPiA+ID4gPiBhcHBlYXIuICovCj4gPiA+ID4gKyAgICBHVUVT
VF9IQU5ETEUoeGVuX3Bmbl90KSBncGZuczsKPiA+ID4gCj4gPiA+IAo+ID4gPiBMb29raW5nIGF0
IHlvdXIgYXJtIGltcGxlbWVudGF0aW9uIGluIHhlbiwgZG9lc24ndCBsb29rIGxpa2UgeW91Cj4g
PiA+IGFyZSBleHBlY3RpbmcgaWR4cyBhbmQgZ3BmbnMgdG8gYmUgY29udGlnb3VzLiBJbiB0aGF0
IGNhc2UsCj4gPiA+IHNob3VsZG4ndCBpZHhzIGFuZCBncGZucyBiZSBwb2ludGVycywgaWUsIHRo
ZXkgYXJlIHNlbnQgZG93biBhcwo+ID4gPiBhcnJheXM/IE9yIGRvZXMgR1VFU1RfSEFORExFIGRv
IHRoYXQsIEkgY2FuJ3Qgc2VlbSB0byBmaW5kIHdoZXJlCj4gPiA+IGl0J3MgZGVmaW5lZCBxdWlj
a2x5Lgo+ID4gCj4gPiBOZXZlciBtaW5kLCBJIHNlZSBpdCBnb3QgY29ycmVjdGVkIHRvIFhFTl9H
VUVTVF9IQU5ETEUgaW4gc3RhZ2luZwo+ID4gdHJlZS4KPiAKPiBUaGUgbWFjcm8gaXMgY2FsbGVk
IFhFTl9HVUVTVF9IQU5ETEUgaW4gWGVuIGFuZCBqdXN0IEdVRVNUX0hBTkRMRSBpbgo+IExpbnV4
Lgo+IAo+ID4gU3RpbGwgZG9lc24ndCBjb21waWxlIHRobzoKPiA+IAo+ID4gcHVibGljL21lbW9y
eS5oOjI0NjogZXJyb3I6IGV4cGVjdGVkIHNwZWNpZmllci1xdWFsaWZpZXItbGlzdCBiZWZvcmUK
PiA+IOKAmF9fZ3Vlc3RfaGFuZGxlX3hlbl91bG9uZ1904oCZCj4gPiAKPiA+IEknbGwgZmlndXJl
IGl0IG91dC4KPiAKPiBMb29rcyBsaWtlIHlvdSd2ZSBnb3QgaXQgYWxsIHNvcnRlZD8KCll1cC4g
SSBtYWRlIHRoZSBjaGFuZ2Ugb24geGVuIHNpZGUgYW5kIGFkZGVkIHRoaXMgcGF0Y2ggdG8gbXkg
dHJlZQphbmQgZ290IGl0IHdvcmtpbmcgYWZ0ZXIgcmV2ZXJ0aW5nIEtvbnJhZCdzIHNldHVwLmMg
Y2hhbmdlcy4gTm90IHN1cmUKaWYgeW91IG5lZWQgYW4gYWNrIGZyb20geDg2LCBidXQgaWYgeW91
IGRvOgoKQWNrZWQtYnk6IE11a2VzaCBSYXRob3IgPG11a2VzaC5yYXRob3JAb3JhY2xlLmNvbT4K
CnRoYW5rcwpNdWtlc2gKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0
dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Fri Oct 26 01:53:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 01:53:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRZ6z-0003gZ-0O; Fri, 26 Oct 2012 01:53:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRZ6x-0003gU-DJ
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 01:53:23 +0000
Received: from [85.158.138.51:62424] by server-13.bemta-3.messagelabs.com id
	3D/A7-24887-21DE9805; Fri, 26 Oct 2012 01:53:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1351216401!19532986!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYxMTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10396 invoked from network); 26 Oct 2012 01:53:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 01:53:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,650,1344211200"; d="scan'208";a="15399965"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 01:53:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 26 Oct 2012 02:53:21 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TRZ6v-0002td-43;
	Fri, 26 Oct 2012 01:53:21 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TRZ6u-0006sH-V2;
	Fri, 26 Oct 2012 02:53:21 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Fri, 26 Oct 2012 02:53:20 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14078: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14078 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14078/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 14077
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 14077
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 14077
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 14077

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  c26e1a79fe77
baseline version:
 xen                  1883c1d29de9

------------------------------------------------------------
People who touched revisions under test:
  Christoph Egger 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Keir Fraser 
  Sander Eikelenboom 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=c26e1a79fe77
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable c26e1a79fe77
+ branch=xen-unstable
+ revision=c26e1a79fe77
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r c26e1a79fe77 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 5 changesets with 11 changes to 10 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 01:53:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 01:53:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRZ6z-0003gZ-0O; Fri, 26 Oct 2012 01:53:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRZ6x-0003gU-DJ
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 01:53:23 +0000
Received: from [85.158.138.51:62424] by server-13.bemta-3.messagelabs.com id
	3D/A7-24887-21DE9805; Fri, 26 Oct 2012 01:53:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1351216401!19532986!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYxMTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10396 invoked from network); 26 Oct 2012 01:53:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 01:53:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,650,1344211200"; d="scan'208";a="15399965"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 01:53:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 26 Oct 2012 02:53:21 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TRZ6v-0002td-43;
	Fri, 26 Oct 2012 01:53:21 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TRZ6u-0006sH-V2;
	Fri, 26 Oct 2012 02:53:21 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Fri, 26 Oct 2012 02:53:20 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14078: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14078 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14078/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 14077
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 14077
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 14077
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 14077

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  c26e1a79fe77
baseline version:
 xen                  1883c1d29de9

------------------------------------------------------------
People who touched revisions under test:
  Christoph Egger 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Keir Fraser 
  Sander Eikelenboom 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=c26e1a79fe77
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable c26e1a79fe77
+ branch=xen-unstable
+ revision=c26e1a79fe77
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r c26e1a79fe77 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 5 changesets with 11 changes to 10 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 06:14:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 06:14:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRdAx-0005T5-El; Fri, 26 Oct 2012 06:13:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRdAw-0005Sy-7i
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 06:13:46 +0000
Received: from [85.158.139.211:55130] by server-12.bemta-5.messagelabs.com id
	1B/89-26919-91A2A805; Fri, 26 Oct 2012 06:13:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1351232024!23739874!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYxMTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 564 invoked from network); 26 Oct 2012 06:13:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 06:13:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,652,1344211200"; d="scan'208";a="15401122"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 06:13:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 26 Oct 2012 07:13:44 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TRdAu-0004Jy-Gu;
	Fri, 26 Oct 2012 06:13:44 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TRdAu-0004wz-8V;
	Fri, 26 Oct 2012 07:13:44 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Fri, 26 Oct 2012 07:13:44 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14079: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14079 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14079/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 14078
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 14078
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 14078
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 14078

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  c26e1a79fe77
baseline version:
 xen                  c26e1a79fe77

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 06:14:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 06:14:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRdAx-0005T5-El; Fri, 26 Oct 2012 06:13:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRdAw-0005Sy-7i
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 06:13:46 +0000
Received: from [85.158.139.211:55130] by server-12.bemta-5.messagelabs.com id
	1B/89-26919-91A2A805; Fri, 26 Oct 2012 06:13:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1351232024!23739874!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYxMTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 564 invoked from network); 26 Oct 2012 06:13:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 06:13:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,652,1344211200"; d="scan'208";a="15401122"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 06:13:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 26 Oct 2012 07:13:44 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TRdAu-0004Jy-Gu;
	Fri, 26 Oct 2012 06:13:44 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TRdAu-0004wz-8V;
	Fri, 26 Oct 2012 07:13:44 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Fri, 26 Oct 2012 07:13:44 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14079: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14079 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14079/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 14078
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 14078
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 14078
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 14078

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  c26e1a79fe77
baseline version:
 xen                  c26e1a79fe77

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 06:19:01 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 06:19:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRdFY-0005cM-CU; Fri, 26 Oct 2012 06:18:32 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRdFW-0005cG-N2
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 06:18:30 +0000
Received: from [193.109.254.147:30352] by server-3.bemta-14.messagelabs.com id
	3D/AB-04486-63B2A805; Fri, 26 Oct 2012 06:18:30 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1351232308!1641164!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjIzNTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20851 invoked from network); 26 Oct 2012 06:18:29 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-14.tower-27.messagelabs.com with SMTP;
	26 Oct 2012 06:18:29 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 25 Oct 2012 23:18:26 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,652,1344236400"; d="scan'208";a="209548559"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by azsmga001.ch.intel.com with ESMTP; 25 Oct 2012 23:18:25 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 25 Oct 2012 23:18:25 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.186]) with mapi id
	14.01.0355.002; Fri, 26 Oct 2012 14:18:24 +0800
From: "Liu, Jinsong" 
To: Jan Beulich 
Thread-Topic: [Xen-devel] [PATCH 1/2] Xen acpi pad implement
Thread-Index: AQHNsrxDTi91BiFLfUibRvXA4zlK85fLG3Tw
Date: Fri, 26 Oct 2012 06:18:23 +0000
Message-ID: 
References: 
	<5089676602000078000A4928@nat28.tlf.novell.com>
In-Reply-To: <5089676602000078000A4928@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk ,
	"linux-kernel@vger.kernel.org" ,
	xen-devel 
Subject: Re: [Xen-devel] [PATCH 1/2] Xen acpi pad implement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thanks! updated accordingly, w/ 2 comments left as below:

> +static const struct acpi_device_id pad_device_ids[] = {
> +	{"ACPI000C", 0},
> +	{"", 0},
> +};
> +
> +static struct acpi_driver xen_acpi_pad_driver = {
> +	.name = "processor_aggregator",
> +	.class = ACPI_PROCESSOR_AGGREGATOR_CLASS,
> +	.ids = pad_device_ids,
> +	.ops = {
> +		.add = xen_acpi_pad_add,

.remove?

[Jinsong] .remove method not used by any logic now (any possible point use it?), so we remove it from our former patch.

> +	},
> +};
> +
> +static int __init xen_acpi_pad_init(void)
> +{
> +	/* Only DOM0 is responsible for Xen acpi pad */
> +	if (xen_initial_domain())
> +		return acpi_bus_register_driver(&xen_acpi_pad_driver);
> +
> +	return -ENODEV;
> +}
> +subsys_initcall(xen_acpi_pad_init);
> +
> +#endif

Overall I'd recommend taking a look at the cleaned up driver in
our kernels.

[Jinsong] What's your point here?

Thanks,
Jinsong

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 06:19:01 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 06:19:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRdFY-0005cM-CU; Fri, 26 Oct 2012 06:18:32 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRdFW-0005cG-N2
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 06:18:30 +0000
Received: from [193.109.254.147:30352] by server-3.bemta-14.messagelabs.com id
	3D/AB-04486-63B2A805; Fri, 26 Oct 2012 06:18:30 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1351232308!1641164!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjIzNTk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20851 invoked from network); 26 Oct 2012 06:18:29 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-14.tower-27.messagelabs.com with SMTP;
	26 Oct 2012 06:18:29 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 25 Oct 2012 23:18:26 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,652,1344236400"; d="scan'208";a="209548559"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by azsmga001.ch.intel.com with ESMTP; 25 Oct 2012 23:18:25 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 25 Oct 2012 23:18:25 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.186]) with mapi id
	14.01.0355.002; Fri, 26 Oct 2012 14:18:24 +0800
From: "Liu, Jinsong" 
To: Jan Beulich 
Thread-Topic: [Xen-devel] [PATCH 1/2] Xen acpi pad implement
Thread-Index: AQHNsrxDTi91BiFLfUibRvXA4zlK85fLG3Tw
Date: Fri, 26 Oct 2012 06:18:23 +0000
Message-ID: 
References: 
	<5089676602000078000A4928@nat28.tlf.novell.com>
In-Reply-To: <5089676602000078000A4928@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk ,
	"linux-kernel@vger.kernel.org" ,
	xen-devel 
Subject: Re: [Xen-devel] [PATCH 1/2] Xen acpi pad implement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thanks! updated accordingly, w/ 2 comments left as below:

> +static const struct acpi_device_id pad_device_ids[] = {
> +	{"ACPI000C", 0},
> +	{"", 0},
> +};
> +
> +static struct acpi_driver xen_acpi_pad_driver = {
> +	.name = "processor_aggregator",
> +	.class = ACPI_PROCESSOR_AGGREGATOR_CLASS,
> +	.ids = pad_device_ids,
> +	.ops = {
> +		.add = xen_acpi_pad_add,

.remove?

[Jinsong] .remove method not used by any logic now (any possible point use it?), so we remove it from our former patch.

> +	},
> +};
> +
> +static int __init xen_acpi_pad_init(void)
> +{
> +	/* Only DOM0 is responsible for Xen acpi pad */
> +	if (xen_initial_domain())
> +		return acpi_bus_register_driver(&xen_acpi_pad_driver);
> +
> +	return -ENODEV;
> +}
> +subsys_initcall(xen_acpi_pad_init);
> +
> +#endif

Overall I'd recommend taking a look at the cleaned up driver in
our kernels.

[Jinsong] What's your point here?

Thanks,
Jinsong

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 07:30:51 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 07:30:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TReN3-0006Fn-MB; Fri, 26 Oct 2012 07:30:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TReN2-0006Fh-O7
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 07:30:20 +0000
Received: from [193.109.254.147:7140] by server-4.bemta-14.messagelabs.com id
	BB/8D-04248-B0C3A805; Fri, 26 Oct 2012 07:30:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1351236619!8501579!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYxMTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9023 invoked from network); 26 Oct 2012 07:30:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 07:30:19 -0000
X-IronPort-AV: E=Sophos;i="4.80,653,1344211200"; d="scan'208";a="15402195"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 07:30:18 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 08:30:18 +0100
Message-ID: <1351236618.8558.4.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Fri, 26 Oct 2012 08:30:18 +0100
In-Reply-To: 
References: 
	<1351091027-20740-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<1351159160.18035.147.camel@zakaz.uk.xensource.com>
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" , "Tim
	\(Xen.org\)" 
Subject: Re: [Xen-devel] [PATCH 5/7] xen/arm: wake up secondary cpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-25 at 18:45 +0100, Stefano Stabellini wrote:
> > >  
> > >  boot_cpu:
> > > @@ -98,6 +98,10 @@ boot_cpu:
> > >  	PRINT(" booting -\r\n")
> > >  #endif
> > >  
> > > +	/* Wake up secondary cpus */
> > > +	teq   r12, #0
> > > +	bleq  kick_cpus
> > 
> > Does this have to be done this early? Couldn't we defer it to C land
> > where it would be easier to isolate the processor/platform specific
> > behaviour?
> 
> Yes, it does because we need to send an interrupt to cpus running in
> secure mode, so this has to happen before we drop off secure state and we
> enter hypervisor state.

Hrm, so maybe this stuff does belong in mode_switch.S after all?

Or is there perhaps some register (e.g. in the GIC?) which would allow
non-secure hyp mode to sent an event to a processor in secure monitor
mode? Or are secondary CPUs actually spinning in secure supervisor mode?

I guess this works in Linux because the boot CPU is in *secure* kernel
mode and that is allowed to send events to other secure modes? That's a
further argument that this is related to the firmware not bringing us up
in Hyp / NS mode and therefore that the fix should be in mode_switch.S.

> > >  	/* Check that this CPU has Hyp mode */
> > >  	mrc   CP32(r0, ID_PFR1)
> > >  	and   r0, r0, #0xf000        /* Bits 12-15 define virt extensions */
> > > diff --git a/xen/arch/arm/mode_switch.S b/xen/arch/arm/mode_switch.S
> > > index 83a682b..39d80e8 100644
> > > --- a/xen/arch/arm/mode_switch.S
> > > +++ b/xen/arch/arm/mode_switch.S
> > > @@ -21,6 +21,37 @@
> > >  #include 
> > >  #include 
> > >  
> > > +/* XXX: Versatile Express specific code */
> > > +/* wake up secondary cpus */
> > > +.globl kick_cpus
> > > +kick_cpus:
> > 
> > My understanding was the mode_switch.S was intended to be a place to
> > hold the hacks and fixups required because there is no firmware on the
> > models and/or to address short comings in the firmware. This kick
> > function is a normal/expected part of booting on a vexpress so I don't
> > think it especially belongs here.
> 
> I have created a processor.S file for processor specific initializations
> (see ACTLR), maybe I can move it there.

proc-ca15.S perhaps? So we can add proc-exynos.S etc in the future?

Ian


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 07:30:51 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 07:30:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TReN3-0006Fn-MB; Fri, 26 Oct 2012 07:30:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TReN2-0006Fh-O7
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 07:30:20 +0000
Received: from [193.109.254.147:7140] by server-4.bemta-14.messagelabs.com id
	BB/8D-04248-B0C3A805; Fri, 26 Oct 2012 07:30:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1351236619!8501579!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYxMTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9023 invoked from network); 26 Oct 2012 07:30:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 07:30:19 -0000
X-IronPort-AV: E=Sophos;i="4.80,653,1344211200"; d="scan'208";a="15402195"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 07:30:18 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 08:30:18 +0100
Message-ID: <1351236618.8558.4.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Fri, 26 Oct 2012 08:30:18 +0100
In-Reply-To: 
References: 
	<1351091027-20740-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<1351159160.18035.147.camel@zakaz.uk.xensource.com>
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" , "Tim
	\(Xen.org\)" 
Subject: Re: [Xen-devel] [PATCH 5/7] xen/arm: wake up secondary cpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-10-25 at 18:45 +0100, Stefano Stabellini wrote:
> > >  
> > >  boot_cpu:
> > > @@ -98,6 +98,10 @@ boot_cpu:
> > >  	PRINT(" booting -\r\n")
> > >  #endif
> > >  
> > > +	/* Wake up secondary cpus */
> > > +	teq   r12, #0
> > > +	bleq  kick_cpus
> > 
> > Does this have to be done this early? Couldn't we defer it to C land
> > where it would be easier to isolate the processor/platform specific
> > behaviour?
> 
> Yes, it does because we need to send an interrupt to cpus running in
> secure mode, so this has to happen before we drop off secure state and we
> enter hypervisor state.

Hrm, so maybe this stuff does belong in mode_switch.S after all?

Or is there perhaps some register (e.g. in the GIC?) which would allow
non-secure hyp mode to sent an event to a processor in secure monitor
mode? Or are secondary CPUs actually spinning in secure supervisor mode?

I guess this works in Linux because the boot CPU is in *secure* kernel
mode and that is allowed to send events to other secure modes? That's a
further argument that this is related to the firmware not bringing us up
in Hyp / NS mode and therefore that the fix should be in mode_switch.S.

> > >  	/* Check that this CPU has Hyp mode */
> > >  	mrc   CP32(r0, ID_PFR1)
> > >  	and   r0, r0, #0xf000        /* Bits 12-15 define virt extensions */
> > > diff --git a/xen/arch/arm/mode_switch.S b/xen/arch/arm/mode_switch.S
> > > index 83a682b..39d80e8 100644
> > > --- a/xen/arch/arm/mode_switch.S
> > > +++ b/xen/arch/arm/mode_switch.S
> > > @@ -21,6 +21,37 @@
> > >  #include 
> > >  #include 
> > >  
> > > +/* XXX: Versatile Express specific code */
> > > +/* wake up secondary cpus */
> > > +.globl kick_cpus
> > > +kick_cpus:
> > 
> > My understanding was the mode_switch.S was intended to be a place to
> > hold the hacks and fixups required because there is no firmware on the
> > models and/or to address short comings in the firmware. This kick
> > function is a normal/expected part of booting on a vexpress so I don't
> > think it especially belongs here.
> 
> I have created a processor.S file for processor specific initializations
> (see ACTLR), maybe I can move it there.

proc-ca15.S perhaps? So we can add proc-exynos.S etc in the future?

Ian


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 07:58:56 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 07:58:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TReoG-00070i-Qv; Fri, 26 Oct 2012 07:58:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TReoF-00070d-7Y
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 07:58:27 +0000
Received: from [85.158.139.211:23874] by server-11.bemta-5.messagelabs.com id
	B1/3A-14870-2A24A805; Fri, 26 Oct 2012 07:58:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1351238305!23792993!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYxMTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2779 invoked from network); 26 Oct 2012 07:58:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 07:58:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,653,1344211200"; d="scan'208";a="15402717"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 07:58:25 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 08:58:25 +0100
Message-ID: <1351238303.18035.236.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Mukesh Rathor 
Date: Fri, 26 Oct 2012 08:58:23 +0100
In-Reply-To: <20121025183958.0a4ae846@mantra.us.oracle.com>
References: <1351084756.18035.28.camel@zakaz.uk.xensource.com>
	<1351084777-28898-4-git-send-email-ian.campbell@citrix.com>
	<20121024164411.5b000087@mantra.us.oracle.com>
	<20121024170746.7c89a790@mantra.us.oracle.com>
	<1351151219.18035.94.camel@zakaz.uk.xensource.com>
	<20121025183958.0a4ae846@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	linux-kernel ,
	Konrad Rzeszutek Wilk ,
	xen-devel 
Subject: Re: [Xen-devel] [PATCH 4/5] xen: arm: implement remap interfaces
 needed for privcmd mappings.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-26 at 02:39 +0100, Mukesh Rathor wrote:
> Yup. I made the change on xen side and added this patch to my tree
> and got it working after reverting Konrad's setup.c changes. Not sure
> if you need an ack from x86, but if you do:
> 
> Acked-by: Mukesh Rathor 

The more ack's the merrier, thanks!



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 07:58:56 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 07:58:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TReoG-00070i-Qv; Fri, 26 Oct 2012 07:58:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TReoF-00070d-7Y
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 07:58:27 +0000
Received: from [85.158.139.211:23874] by server-11.bemta-5.messagelabs.com id
	B1/3A-14870-2A24A805; Fri, 26 Oct 2012 07:58:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1351238305!23792993!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYxMTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2779 invoked from network); 26 Oct 2012 07:58:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 07:58:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,653,1344211200"; d="scan'208";a="15402717"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 07:58:25 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 08:58:25 +0100
Message-ID: <1351238303.18035.236.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Mukesh Rathor 
Date: Fri, 26 Oct 2012 08:58:23 +0100
In-Reply-To: <20121025183958.0a4ae846@mantra.us.oracle.com>
References: <1351084756.18035.28.camel@zakaz.uk.xensource.com>
	<1351084777-28898-4-git-send-email-ian.campbell@citrix.com>
	<20121024164411.5b000087@mantra.us.oracle.com>
	<20121024170746.7c89a790@mantra.us.oracle.com>
	<1351151219.18035.94.camel@zakaz.uk.xensource.com>
	<20121025183958.0a4ae846@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Stefano Stabellini ,
	linux-kernel ,
	Konrad Rzeszutek Wilk ,
	xen-devel 
Subject: Re: [Xen-devel] [PATCH 4/5] xen: arm: implement remap interfaces
 needed for privcmd mappings.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-26 at 02:39 +0100, Mukesh Rathor wrote:
> Yup. I made the change on xen side and added this patch to my tree
> and got it working after reverting Konrad's setup.c changes. Not sure
> if you need an ack from x86, but if you do:
> 
> Acked-by: Mukesh Rathor 

The more ack's the merrier, thanks!



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 08:26:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 08:26:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRfEm-0007gJ-Fl; Fri, 26 Oct 2012 08:25:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRfEl-0007gE-5p
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 08:25:51 +0000
Received: from [85.158.143.35:64115] by server-3.bemta-4.messagelabs.com id
	20/06-24279-E094A805; Fri, 26 Oct 2012 08:25:50 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1351239871!13261135!1
X-Originating-IP: [216.32.180.187]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31231 invoked from network); 26 Oct 2012 08:24:32 -0000
Received: from co1ehsobe004.messaging.microsoft.com (HELO
	co1outboundpool.messaging.microsoft.com) (216.32.180.187)
	by server-3.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	26 Oct 2012 08:24:32 -0000
Received: from mail133-co1-R.bigfish.com (10.243.78.241) by
	CO1EHSOBE004.bigfish.com (10.243.66.67) with Microsoft SMTP Server id
	14.1.225.23; Fri, 26 Oct 2012 08:24:30 +0000
Received: from mail133-co1 (localhost [127.0.0.1])	by
	mail133-co1-R.bigfish.com (Postfix) with ESMTP id 4F3B740056;
	Fri, 26 Oct 2012 08:24:30 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: -3
X-BigFish: VPS-3(zzbb2dI98dI1432Izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h)
Received: from mail133-co1 (localhost.localdomain [127.0.0.1]) by mail133-co1
	(MessageSwitch) id 1351239868816867_8839;
	Fri, 26 Oct 2012 08:24:28 +0000 (UTC)
Received: from CO1EHSMHS031.bigfish.com (unknown [10.243.78.252])	by
	mail133-co1.bigfish.com (Postfix) with ESMTP id C58E4A60048;
	Fri, 26 Oct 2012 08:24:28 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CO1EHSMHS031.bigfish.com (10.243.66.41) with Microsoft SMTP Server id
	14.1.225.23; Fri, 26 Oct 2012 08:24:28 +0000
X-WSS-ID: 0MCHRCQ-02-EQT-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 29424C8113;	Fri, 26 Oct 2012 03:24:26 -0500 (CDT)
Received: from SAUSEXDAG05.amd.com (163.181.55.6) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 26 Oct 2012 03:24:45 -0500
Received: from STOREXDAG02.amd.com (10.1.13.11) by sausexdag05.amd.com
	(163.181.55.6) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Fri, 26 Oct 2012 03:24:25 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag02.amd.com
	(10.1.13.11) with Microsoft SMTP Server id 14.2.318.4; Fri, 26 Oct 2012
	04:24:24 -0400
Message-ID: <508A48B7.8050201@amd.com>
Date: Fri, 26 Oct 2012 10:24:23 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich 
References: <5089449C.7020700@amd.com>
	<5089646102000078000A48DA@nat28.tlf.novell.com>
	<50894A2D.8030007@amd.com> <50895098.50405@amd.com>
	<50896F5D02000078000A4991@nat28.tlf.novell.com>
In-Reply-To: <50896F5D02000078000A4991@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] MCE: support cpu notification chain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/25/12 16:57, Jan Beulich wrote:
>>>> On 25.10.12 at 16:45, Christoph Egger  wrote:
>> On 10/25/12 16:18, Christoph Egger wrote:
>>> On 10/25/12 16:10, Jan Beulich wrote:
>>>>>>> On 25.10.12 at 15:54, Christoph Egger  wrote:
>>>>> Add support for cpu notification chain.
>>>>> This is useful with nested virtualization when Xen
>>>>> runs as l1 hypervisor.
>>>>> This cleans up mce initialization cleanup as a side-effect.
>>>>
>>>> Did you notice the fix I had done to your earlier patch before
>>>> committing c/s 26106:1883c1d29de9? With the change here,
>>>> mce_clear_banks will get allocated twice (once in generic code
>>>> and once in AMD specific code), leaking one instance.
>>>
>>> Ugh... must be a merge botch.
>>
>> Updated patch attached.
>>
>> Signed-off-by: Christoph Egger 
> 
> Subject and patch don't really fit together anymore. This is
> mostly cleanup (code movement) now, and I wonder whether
> this

Will adjust and resend.

Christoph

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 08:26:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 08:26:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRfEm-0007gJ-Fl; Fri, 26 Oct 2012 08:25:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRfEl-0007gE-5p
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 08:25:51 +0000
Received: from [85.158.143.35:64115] by server-3.bemta-4.messagelabs.com id
	20/06-24279-E094A805; Fri, 26 Oct 2012 08:25:50 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1351239871!13261135!1
X-Originating-IP: [216.32.180.187]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31231 invoked from network); 26 Oct 2012 08:24:32 -0000
Received: from co1ehsobe004.messaging.microsoft.com (HELO
	co1outboundpool.messaging.microsoft.com) (216.32.180.187)
	by server-3.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	26 Oct 2012 08:24:32 -0000
Received: from mail133-co1-R.bigfish.com (10.243.78.241) by
	CO1EHSOBE004.bigfish.com (10.243.66.67) with Microsoft SMTP Server id
	14.1.225.23; Fri, 26 Oct 2012 08:24:30 +0000
Received: from mail133-co1 (localhost [127.0.0.1])	by
	mail133-co1-R.bigfish.com (Postfix) with ESMTP id 4F3B740056;
	Fri, 26 Oct 2012 08:24:30 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: -3
X-BigFish: VPS-3(zzbb2dI98dI1432Izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h)
Received: from mail133-co1 (localhost.localdomain [127.0.0.1]) by mail133-co1
	(MessageSwitch) id 1351239868816867_8839;
	Fri, 26 Oct 2012 08:24:28 +0000 (UTC)
Received: from CO1EHSMHS031.bigfish.com (unknown [10.243.78.252])	by
	mail133-co1.bigfish.com (Postfix) with ESMTP id C58E4A60048;
	Fri, 26 Oct 2012 08:24:28 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CO1EHSMHS031.bigfish.com (10.243.66.41) with Microsoft SMTP Server id
	14.1.225.23; Fri, 26 Oct 2012 08:24:28 +0000
X-WSS-ID: 0MCHRCQ-02-EQT-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 29424C8113;	Fri, 26 Oct 2012 03:24:26 -0500 (CDT)
Received: from SAUSEXDAG05.amd.com (163.181.55.6) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 26 Oct 2012 03:24:45 -0500
Received: from STOREXDAG02.amd.com (10.1.13.11) by sausexdag05.amd.com
	(163.181.55.6) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Fri, 26 Oct 2012 03:24:25 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag02.amd.com
	(10.1.13.11) with Microsoft SMTP Server id 14.2.318.4; Fri, 26 Oct 2012
	04:24:24 -0400
Message-ID: <508A48B7.8050201@amd.com>
Date: Fri, 26 Oct 2012 10:24:23 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich 
References: <5089449C.7020700@amd.com>
	<5089646102000078000A48DA@nat28.tlf.novell.com>
	<50894A2D.8030007@amd.com> <50895098.50405@amd.com>
	<50896F5D02000078000A4991@nat28.tlf.novell.com>
In-Reply-To: <50896F5D02000078000A4991@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] MCE: support cpu notification chain
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/25/12 16:57, Jan Beulich wrote:
>>>> On 25.10.12 at 16:45, Christoph Egger  wrote:
>> On 10/25/12 16:18, Christoph Egger wrote:
>>> On 10/25/12 16:10, Jan Beulich wrote:
>>>>>>> On 25.10.12 at 15:54, Christoph Egger  wrote:
>>>>> Add support for cpu notification chain.
>>>>> This is useful with nested virtualization when Xen
>>>>> runs as l1 hypervisor.
>>>>> This cleans up mce initialization cleanup as a side-effect.
>>>>
>>>> Did you notice the fix I had done to your earlier patch before
>>>> committing c/s 26106:1883c1d29de9? With the change here,
>>>> mce_clear_banks will get allocated twice (once in generic code
>>>> and once in AMD specific code), leaking one instance.
>>>
>>> Ugh... must be a merge botch.
>>
>> Updated patch attached.
>>
>> Signed-off-by: Christoph Egger 
> 
> Subject and patch don't really fit together anymore. This is
> mostly cleanup (code movement) now, and I wonder whether
> this

Will adjust and resend.

Christoph

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 08:26:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 08:26:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRfF2-0007h1-TH; Fri, 26 Oct 2012 08:26:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRfF1-0007gs-JM
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 08:26:07 +0000
Received: from [85.158.138.51:43856] by server-12.bemta-3.messagelabs.com id
	74/3F-27853-E194A805; Fri, 26 Oct 2012 08:26:06 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1351239966!18606447!1
X-Originating-IP: [213.199.154.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15954 invoked from network); 26 Oct 2012 08:26:06 -0000
Received: from am1ehsobe005.messaging.microsoft.com (HELO
	am1outboundpool.messaging.microsoft.com) (213.199.154.208)
	by server-7.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	26 Oct 2012 08:26:06 -0000
Received: from mail22-am1-R.bigfish.com (10.3.201.241) by
	AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id
	14.1.225.23; Fri, 26 Oct 2012 08:26:06 +0000
Received: from mail22-am1 (localhost [127.0.0.1])	by mail22-am1-R.bigfish.com
	(Postfix) with ESMTP id C5EF31E0120	for ;
	Fri, 26 Oct 2012 08:26:05 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: 15
X-BigFish: VPS15(zzzz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh133w1155h)
Received: from mail22-am1 (localhost.localdomain [127.0.0.1]) by mail22-am1
	(MessageSwitch) id 1351239963247892_5941;
	Fri, 26 Oct 2012 08:26:03 +0000 (UTC)
Received: from AM1EHSMHS004.bigfish.com (unknown [10.3.201.245])	by
	mail22-am1.bigfish.com (Postfix) with ESMTP id 2F49D260047	for
	; Fri, 26 Oct 2012 08:26:03 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS004.bigfish.com (10.3.207.104) with Microsoft SMTP Server id
	14.1.225.23; Fri, 26 Oct 2012 08:25:52 +0000
X-WSS-ID: 0MCHRF2-01-2TW-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1) with ESMTP id 2E22610280A4	for ;
	Fri, 26 Oct 2012 03:25:50 -0500 (CDT)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 26 Oct 2012 03:26:09 -0500
Received: from STOREXDAG02.amd.com (10.1.13.11) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Fri, 26 Oct 2012 03:25:50 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag02.amd.com
	(10.1.13.11) with Microsoft SMTP Server id 14.2.318.4; Fri, 26 Oct 2012
	04:25:48 -0400
Message-ID: <508A490B.4050407@amd.com>
Date: Fri, 26 Oct 2012 10:25:47 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" 
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] MCE: consolidate AMD initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Move AMD specific initialization to AMD files.

Signed-off-by: Christoph Egger 

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 08:26:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 08:26:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRfF2-0007h1-TH; Fri, 26 Oct 2012 08:26:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRfF1-0007gs-JM
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 08:26:07 +0000
Received: from [85.158.138.51:43856] by server-12.bemta-3.messagelabs.com id
	74/3F-27853-E194A805; Fri, 26 Oct 2012 08:26:06 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1351239966!18606447!1
X-Originating-IP: [213.199.154.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15954 invoked from network); 26 Oct 2012 08:26:06 -0000
Received: from am1ehsobe005.messaging.microsoft.com (HELO
	am1outboundpool.messaging.microsoft.com) (213.199.154.208)
	by server-7.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	26 Oct 2012 08:26:06 -0000
Received: from mail22-am1-R.bigfish.com (10.3.201.241) by
	AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id
	14.1.225.23; Fri, 26 Oct 2012 08:26:06 +0000
Received: from mail22-am1 (localhost [127.0.0.1])	by mail22-am1-R.bigfish.com
	(Postfix) with ESMTP id C5EF31E0120	for ;
	Fri, 26 Oct 2012 08:26:05 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: 15
X-BigFish: VPS15(zzzz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh133w1155h)
Received: from mail22-am1 (localhost.localdomain [127.0.0.1]) by mail22-am1
	(MessageSwitch) id 1351239963247892_5941;
	Fri, 26 Oct 2012 08:26:03 +0000 (UTC)
Received: from AM1EHSMHS004.bigfish.com (unknown [10.3.201.245])	by
	mail22-am1.bigfish.com (Postfix) with ESMTP id 2F49D260047	for
	; Fri, 26 Oct 2012 08:26:03 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS004.bigfish.com (10.3.207.104) with Microsoft SMTP Server id
	14.1.225.23; Fri, 26 Oct 2012 08:25:52 +0000
X-WSS-ID: 0MCHRF2-01-2TW-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1) with ESMTP id 2E22610280A4	for ;
	Fri, 26 Oct 2012 03:25:50 -0500 (CDT)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 26 Oct 2012 03:26:09 -0500
Received: from STOREXDAG02.amd.com (10.1.13.11) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Fri, 26 Oct 2012 03:25:50 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag02.amd.com
	(10.1.13.11) with Microsoft SMTP Server id 14.2.318.4; Fri, 26 Oct 2012
	04:25:48 -0400
Message-ID: <508A490B.4050407@amd.com>
Date: Fri, 26 Oct 2012 10:25:47 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" 
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] MCE: consolidate AMD initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Move AMD specific initialization to AMD files.

Signed-off-by: Christoph Egger 

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 08:28:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 08:28:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRfH5-0007qd-E1; Fri, 26 Oct 2012 08:28:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRfH4-0007qV-0J
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 08:28:14 +0000
Received: from [85.158.143.35:16292] by server-3.bemta-4.messagelabs.com id
	33/E9-24279-D994A805; Fri, 26 Oct 2012 08:28:13 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1351239998!12628680!1
X-Originating-IP: [216.32.180.14]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21007 invoked from network); 26 Oct 2012 08:26:39 -0000
Received: from va3ehsobe004.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.14)
	by server-8.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	26 Oct 2012 08:26:39 -0000
Received: from mail257-va3-R.bigfish.com (10.7.14.251) by
	VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id
	14.1.225.23; Fri, 26 Oct 2012 08:26:37 +0000
Received: from mail257-va3 (localhost [127.0.0.1])	by
	mail257-va3-R.bigfish.com (Postfix) with ESMTP id DD4EC1A00142	for
	; Fri, 26 Oct 2012 08:26:37 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: -3
X-BigFish: VPS-3(zzbb2dI98dIc85fhc85dh1432Izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh34h1155h)
Received: from mail257-va3 (localhost.localdomain [127.0.0.1]) by mail257-va3
	(MessageSwitch) id 1351239996118201_5120;
	Fri, 26 Oct 2012 08:26:36 +0000 (UTC)
Received: from VA3EHSMHS021.bigfish.com (unknown [10.7.14.235])	by
	mail257-va3.bigfish.com (Postfix) with ESMTP id 1B05013C004F	for
	; Fri, 26 Oct 2012 08:26:36 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS021.bigfish.com (10.7.99.31) with Microsoft SMTP Server id
	14.1.225.23; Fri, 26 Oct 2012 08:26:32 +0000
X-WSS-ID: 0MCHRG8-02-ETL-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2AEB1C80CE	for ; Fri, 26 Oct 2012
	03:26:31 -0500 (CDT)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 26 Oct 2012 03:26:51 -0500
Received: from STOREXDAG02.amd.com (10.1.13.11) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Fri, 26 Oct 2012 03:26:31 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag02.amd.com
	(10.1.13.11) with Microsoft SMTP Server id 14.2.318.4; Fri, 26 Oct 2012
	04:26:30 -0400
Message-ID: <508A4935.6090801@amd.com>
Date: Fri, 26 Oct 2012 10:26:29 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" 
References: <508A490B.4050407@amd.com>
In-Reply-To: <508A490B.4050407@amd.com>
Content-Type: multipart/mixed; boundary="------------010209000300050807000308"
X-OriginatorOrg: amd.com
Subject: Re: [Xen-devel] [PATCH] MCE: consolidate AMD initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------010209000300050807000308
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit

On 10/26/12 10:25, Christoph Egger wrote:
> 
> Move AMD specific initialization to AMD files.
> 
> Signed-off-by: Christoph Egger 
> 


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------010209000300050807000308
Content-Type: text/plain; charset="us-ascii"; name="xen_mce_init.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_mce_init.diff"
Content-Description: xen_mce_init.diff

diff -r 7abb25095de0 xen/arch/x86/cpu/mcheck/mce.c
--- a/xen/arch/x86/cpu/mcheck/mce.c	Thu Oct 25 13:15:19 2012 +0200
+++ b/xen/arch/x86/cpu/mcheck/mce.c	Fri Oct 26 08:50:17 2012 +0200
@@ -560,30 +560,6 @@ void mcheck_mca_clearbanks(struct mca_ba
     }
 }
 
-static enum mcheck_type amd_mcheck_init(struct cpuinfo_x86 *ci)
-{
-    enum mcheck_type rc = mcheck_none;
-
-    switch (ci->x86) {
-    case 6:
-        rc = amd_k7_mcheck_init(ci);
-        break;
-
-    default:
-        /* Assume that machine check support is available.
-         * The minimum provided support is at least the K8. */
-    case 0xf:
-        rc = amd_k8_mcheck_init(ci);
-        break;
-
-    case 0x10 ... 0x17:
-        rc = amd_f10_mcheck_init(ci);
-        break;
-    }
-
-    return rc;
-}
-
 /*check the existence of Machine Check*/
 int mce_available(struct cpuinfo_x86 *c)
 {
diff -r 7abb25095de0 xen/arch/x86/cpu/mcheck/mce.h
--- a/xen/arch/x86/cpu/mcheck/mce.h	Thu Oct 25 13:15:19 2012 +0200
+++ b/xen/arch/x86/cpu/mcheck/mce.h	Fri Oct 26 08:50:17 2012 +0200
@@ -39,10 +39,7 @@ enum mcheck_type {
 };
 
 /* Init functions */
-enum mcheck_type amd_k7_mcheck_init(struct cpuinfo_x86 *c);
-enum mcheck_type amd_k8_mcheck_init(struct cpuinfo_x86 *c);
-enum mcheck_type amd_f10_mcheck_init(struct cpuinfo_x86 *c);
-
+enum mcheck_type amd_mcheck_init(struct cpuinfo_x86 *c);
 enum mcheck_type intel_mcheck_init(struct cpuinfo_x86 *c, bool_t bsp);
 
 void intel_mcheck_timer(struct cpuinfo_x86 *c);
diff -r 7abb25095de0 xen/arch/x86/cpu/mcheck/mce_amd.c
--- a/xen/arch/x86/cpu/mcheck/mce_amd.c	Thu Oct 25 13:15:19 2012 +0200
+++ b/xen/arch/x86/cpu/mcheck/mce_amd.c	Fri Oct 26 08:50:17 2012 +0200
@@ -98,3 +98,28 @@ mc_amd_addrcheck(uint64_t status, uint64
     BUG();
     return 0;
 }
+
+enum mcheck_type
+amd_mcheck_init(struct cpuinfo_x86 *ci)
+{
+    enum mcheck_type rc = mcheck_none;
+
+    switch (ci->x86) {
+    case 6:
+        rc = amd_k7_mcheck_init(ci);
+        break;
+
+    default:
+        /* Assume that machine check support is available.
+         * The minimum provided support is at least the K8. */
+    case 0xf:
+        rc = amd_k8_mcheck_init(ci);
+        break;
+
+    case 0x10 ... 0x17:
+        rc = amd_f10_mcheck_init(ci);
+        break;
+    }
+
+    return rc;
+}
diff -r 7abb25095de0 xen/arch/x86/cpu/mcheck/mce_amd.h
--- a/xen/arch/x86/cpu/mcheck/mce_amd.h	Thu Oct 25 13:15:19 2012 +0200
+++ b/xen/arch/x86/cpu/mcheck/mce_amd.h	Fri Oct 26 08:50:17 2012 +0200
@@ -1,6 +1,10 @@
 #ifndef _MCHECK_AMD_H
 #define _MCHECK_AMD_H
 
+enum mcheck_type amd_k7_mcheck_init(struct cpuinfo_x86 *c);
+enum mcheck_type amd_k8_mcheck_init(struct cpuinfo_x86 *c);
+enum mcheck_type amd_f10_mcheck_init(struct cpuinfo_x86 *c);
+
 int mc_amd_recoverable_scan(uint64_t status);
 int mc_amd_addrcheck(uint64_t status, uint64_t misc, int addrtype);
 

--------------010209000300050807000308
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------010209000300050807000308--


From xen-devel-bounces@lists.xen.org Fri Oct 26 08:28:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 08:28:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRfH5-0007qd-E1; Fri, 26 Oct 2012 08:28:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRfH4-0007qV-0J
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 08:28:14 +0000
Received: from [85.158.143.35:16292] by server-3.bemta-4.messagelabs.com id
	33/E9-24279-D994A805; Fri, 26 Oct 2012 08:28:13 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1351239998!12628680!1
X-Originating-IP: [216.32.180.14]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21007 invoked from network); 26 Oct 2012 08:26:39 -0000
Received: from va3ehsobe004.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.14)
	by server-8.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	26 Oct 2012 08:26:39 -0000
Received: from mail257-va3-R.bigfish.com (10.7.14.251) by
	VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id
	14.1.225.23; Fri, 26 Oct 2012 08:26:37 +0000
Received: from mail257-va3 (localhost [127.0.0.1])	by
	mail257-va3-R.bigfish.com (Postfix) with ESMTP id DD4EC1A00142	for
	; Fri, 26 Oct 2012 08:26:37 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: -3
X-BigFish: VPS-3(zzbb2dI98dIc85fhc85dh1432Izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh34h1155h)
Received: from mail257-va3 (localhost.localdomain [127.0.0.1]) by mail257-va3
	(MessageSwitch) id 1351239996118201_5120;
	Fri, 26 Oct 2012 08:26:36 +0000 (UTC)
Received: from VA3EHSMHS021.bigfish.com (unknown [10.7.14.235])	by
	mail257-va3.bigfish.com (Postfix) with ESMTP id 1B05013C004F	for
	; Fri, 26 Oct 2012 08:26:36 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS021.bigfish.com (10.7.99.31) with Microsoft SMTP Server id
	14.1.225.23; Fri, 26 Oct 2012 08:26:32 +0000
X-WSS-ID: 0MCHRG8-02-ETL-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2AEB1C80CE	for ; Fri, 26 Oct 2012
	03:26:31 -0500 (CDT)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 26 Oct 2012 03:26:51 -0500
Received: from STOREXDAG02.amd.com (10.1.13.11) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Fri, 26 Oct 2012 03:26:31 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag02.amd.com
	(10.1.13.11) with Microsoft SMTP Server id 14.2.318.4; Fri, 26 Oct 2012
	04:26:30 -0400
Message-ID: <508A4935.6090801@amd.com>
Date: Fri, 26 Oct 2012 10:26:29 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" 
References: <508A490B.4050407@amd.com>
In-Reply-To: <508A490B.4050407@amd.com>
Content-Type: multipart/mixed; boundary="------------010209000300050807000308"
X-OriginatorOrg: amd.com
Subject: Re: [Xen-devel] [PATCH] MCE: consolidate AMD initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------010209000300050807000308
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit

On 10/26/12 10:25, Christoph Egger wrote:
> 
> Move AMD specific initialization to AMD files.
> 
> Signed-off-by: Christoph Egger 
> 


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------010209000300050807000308
Content-Type: text/plain; charset="us-ascii"; name="xen_mce_init.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_mce_init.diff"
Content-Description: xen_mce_init.diff

diff -r 7abb25095de0 xen/arch/x86/cpu/mcheck/mce.c
--- a/xen/arch/x86/cpu/mcheck/mce.c	Thu Oct 25 13:15:19 2012 +0200
+++ b/xen/arch/x86/cpu/mcheck/mce.c	Fri Oct 26 08:50:17 2012 +0200
@@ -560,30 +560,6 @@ void mcheck_mca_clearbanks(struct mca_ba
     }
 }
 
-static enum mcheck_type amd_mcheck_init(struct cpuinfo_x86 *ci)
-{
-    enum mcheck_type rc = mcheck_none;
-
-    switch (ci->x86) {
-    case 6:
-        rc = amd_k7_mcheck_init(ci);
-        break;
-
-    default:
-        /* Assume that machine check support is available.
-         * The minimum provided support is at least the K8. */
-    case 0xf:
-        rc = amd_k8_mcheck_init(ci);
-        break;
-
-    case 0x10 ... 0x17:
-        rc = amd_f10_mcheck_init(ci);
-        break;
-    }
-
-    return rc;
-}
-
 /*check the existence of Machine Check*/
 int mce_available(struct cpuinfo_x86 *c)
 {
diff -r 7abb25095de0 xen/arch/x86/cpu/mcheck/mce.h
--- a/xen/arch/x86/cpu/mcheck/mce.h	Thu Oct 25 13:15:19 2012 +0200
+++ b/xen/arch/x86/cpu/mcheck/mce.h	Fri Oct 26 08:50:17 2012 +0200
@@ -39,10 +39,7 @@ enum mcheck_type {
 };
 
 /* Init functions */
-enum mcheck_type amd_k7_mcheck_init(struct cpuinfo_x86 *c);
-enum mcheck_type amd_k8_mcheck_init(struct cpuinfo_x86 *c);
-enum mcheck_type amd_f10_mcheck_init(struct cpuinfo_x86 *c);
-
+enum mcheck_type amd_mcheck_init(struct cpuinfo_x86 *c);
 enum mcheck_type intel_mcheck_init(struct cpuinfo_x86 *c, bool_t bsp);
 
 void intel_mcheck_timer(struct cpuinfo_x86 *c);
diff -r 7abb25095de0 xen/arch/x86/cpu/mcheck/mce_amd.c
--- a/xen/arch/x86/cpu/mcheck/mce_amd.c	Thu Oct 25 13:15:19 2012 +0200
+++ b/xen/arch/x86/cpu/mcheck/mce_amd.c	Fri Oct 26 08:50:17 2012 +0200
@@ -98,3 +98,28 @@ mc_amd_addrcheck(uint64_t status, uint64
     BUG();
     return 0;
 }
+
+enum mcheck_type
+amd_mcheck_init(struct cpuinfo_x86 *ci)
+{
+    enum mcheck_type rc = mcheck_none;
+
+    switch (ci->x86) {
+    case 6:
+        rc = amd_k7_mcheck_init(ci);
+        break;
+
+    default:
+        /* Assume that machine check support is available.
+         * The minimum provided support is at least the K8. */
+    case 0xf:
+        rc = amd_k8_mcheck_init(ci);
+        break;
+
+    case 0x10 ... 0x17:
+        rc = amd_f10_mcheck_init(ci);
+        break;
+    }
+
+    return rc;
+}
diff -r 7abb25095de0 xen/arch/x86/cpu/mcheck/mce_amd.h
--- a/xen/arch/x86/cpu/mcheck/mce_amd.h	Thu Oct 25 13:15:19 2012 +0200
+++ b/xen/arch/x86/cpu/mcheck/mce_amd.h	Fri Oct 26 08:50:17 2012 +0200
@@ -1,6 +1,10 @@
 #ifndef _MCHECK_AMD_H
 #define _MCHECK_AMD_H
 
+enum mcheck_type amd_k7_mcheck_init(struct cpuinfo_x86 *c);
+enum mcheck_type amd_k8_mcheck_init(struct cpuinfo_x86 *c);
+enum mcheck_type amd_f10_mcheck_init(struct cpuinfo_x86 *c);
+
 int mc_amd_recoverable_scan(uint64_t status);
 int mc_amd_addrcheck(uint64_t status, uint64_t misc, int addrtype);
 

--------------010209000300050807000308
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------010209000300050807000308--


From xen-devel-bounces@lists.xen.org Fri Oct 26 08:56:46 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 08:56:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRfiH-0008BW-TD; Fri, 26 Oct 2012 08:56:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TRfiF-0008BR-LH
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 08:56:19 +0000
Received: from [193.109.254.147:46371] by server-1.bemta-14.messagelabs.com id
	74/AC-20415-2305A805; Fri, 26 Oct 2012 08:56:18 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1351241778!829962!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9407 invoked from network); 26 Oct 2012 08:56:18 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Oct 2012 08:56:18 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TRfiB-000JoD-1t; Fri, 26 Oct 2012 08:56:15 +0000
Date: Fri, 26 Oct 2012 09:56:15 +0100
From: Tim Deegan 
To: Ian Campbell 
Message-ID: <20121026085615.GA76080@ocelot.phlegethon.org>
References: 
	<1351091027-20740-4-git-send-email-stefano.stabellini@eu.citrix.com>
	<1351158737.18035.142.camel@zakaz.uk.xensource.com>
	
	<1351166670.18035.177.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1351166670.18035.177.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 4/7] xen/arm: set the SMP bit in the ACTLR
	register
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 13:04 +0100 on 25 Oct (1351170270), Ian Campbell wrote:
> On Thu, 2012-10-25 at 12:57 +0100, Stefano Stabellini wrote:
> > On Thu, 25 Oct 2012, Ian Campbell wrote:
> > > On Wed, 2012-10-24 at 16:03 +0100, Stefano Stabellini wrote:
> > > > From the Cortex A15 manual:
> > > > 
> > > > "Enables the processor to receive instruction cache, BTB, and TLB maintenance
> > > > operations from other processors"
> > > > 
> > > > ...
> > > > 
> > > > "You must set this bit before enabling the caches and MMU, or
> > > > performing any cache and TLB maintenance operations. The only time
> > > > you must clear this bit is during a processor power-down sequence"
> > > 
> > > Is it considered a bug that the firmware doesn't do this?
> > 
> > Why would it be? You can run fairly complicated pieces of software
> > without caches or MMU.
> 
> True, I guess I just considered that not setting the SMP bit on the
> second processor when the firmware starts it seemed a bit odd. If you
> aren't caches/MMU/etc them then setting the bit is pretty much a NOP (or
> maybe it isn't?).

Well, given that you're not allowed to clear it except at power-down, I
think it would be impolite of the firmware to set it if there's _any_
reason the OS might not want it set.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 08:56:46 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 08:56:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRfiH-0008BW-TD; Fri, 26 Oct 2012 08:56:21 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TRfiF-0008BR-LH
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 08:56:19 +0000
Received: from [193.109.254.147:46371] by server-1.bemta-14.messagelabs.com id
	74/AC-20415-2305A805; Fri, 26 Oct 2012 08:56:18 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1351241778!829962!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9407 invoked from network); 26 Oct 2012 08:56:18 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Oct 2012 08:56:18 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TRfiB-000JoD-1t; Fri, 26 Oct 2012 08:56:15 +0000
Date: Fri, 26 Oct 2012 09:56:15 +0100
From: Tim Deegan 
To: Ian Campbell 
Message-ID: <20121026085615.GA76080@ocelot.phlegethon.org>
References: 
	<1351091027-20740-4-git-send-email-stefano.stabellini@eu.citrix.com>
	<1351158737.18035.142.camel@zakaz.uk.xensource.com>
	
	<1351166670.18035.177.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1351166670.18035.177.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 4/7] xen/arm: set the SMP bit in the ACTLR
	register
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 13:04 +0100 on 25 Oct (1351170270), Ian Campbell wrote:
> On Thu, 2012-10-25 at 12:57 +0100, Stefano Stabellini wrote:
> > On Thu, 25 Oct 2012, Ian Campbell wrote:
> > > On Wed, 2012-10-24 at 16:03 +0100, Stefano Stabellini wrote:
> > > > From the Cortex A15 manual:
> > > > 
> > > > "Enables the processor to receive instruction cache, BTB, and TLB maintenance
> > > > operations from other processors"
> > > > 
> > > > ...
> > > > 
> > > > "You must set this bit before enabling the caches and MMU, or
> > > > performing any cache and TLB maintenance operations. The only time
> > > > you must clear this bit is during a processor power-down sequence"
> > > 
> > > Is it considered a bug that the firmware doesn't do this?
> > 
> > Why would it be? You can run fairly complicated pieces of software
> > without caches or MMU.
> 
> True, I guess I just considered that not setting the SMP bit on the
> second processor when the firmware starts it seemed a bit odd. If you
> aren't caches/MMU/etc them then setting the bit is pretty much a NOP (or
> maybe it isn't?).

Well, given that you're not allowed to clear it except at power-down, I
think it would be impolite of the firmware to set it if there's _any_
reason the OS might not want it set.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 09:00:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 09:00:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRflY-0008JF-Kr; Fri, 26 Oct 2012 08:59:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRflX-0008J9-Eo
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 08:59:43 +0000
Received: from [193.109.254.147:17002] by server-11.bemta-14.messagelabs.com
	id 9E/00-29027-EF05A805; Fri, 26 Oct 2012 08:59:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1351241982!6095693!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15810 invoked from network); 26 Oct 2012 08:59:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 08:59:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,653,1344211200"; d="scan'208";a="15404354"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 08:59:42 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 09:59:42 +0100
Message-ID: <1351241980.15162.4.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Tim Deegan 
Date: Fri, 26 Oct 2012 09:59:40 +0100
In-Reply-To: <20121026085615.GA76080@ocelot.phlegethon.org>
References: 
	<1351091027-20740-4-git-send-email-stefano.stabellini@eu.citrix.com>
	<1351158737.18035.142.camel@zakaz.uk.xensource.com>
	
	<1351166670.18035.177.camel@zakaz.uk.xensource.com>
	<20121026085615.GA76080@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 4/7] xen/arm: set the SMP bit in the ACTLR
	register
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-26 at 09:56 +0100, Tim Deegan wrote:
> At 13:04 +0100 on 25 Oct (1351170270), Ian Campbell wrote:
> > On Thu, 2012-10-25 at 12:57 +0100, Stefano Stabellini wrote:
> > > On Thu, 25 Oct 2012, Ian Campbell wrote:
> > > > On Wed, 2012-10-24 at 16:03 +0100, Stefano Stabellini wrote:
> > > > > From the Cortex A15 manual:
> > > > > 
> > > > > "Enables the processor to receive instruction cache, BTB, and TLB maintenance
> > > > > operations from other processors"
> > > > > 
> > > > > ...
> > > > > 
> > > > > "You must set this bit before enabling the caches and MMU, or
> > > > > performing any cache and TLB maintenance operations. The only time
> > > > > you must clear this bit is during a processor power-down sequence"
> > > > 
> > > > Is it considered a bug that the firmware doesn't do this?
> > > 
> > > Why would it be? You can run fairly complicated pieces of software
> > > without caches or MMU.
> > 
> > True, I guess I just considered that not setting the SMP bit on the
> > second processor when the firmware starts it seemed a bit odd. If you
> > aren't caches/MMU/etc them then setting the bit is pretty much a NOP (or
> > maybe it isn't?).
> 
> Well, given that you're not allowed to clear it except at power-down, I
> think it would be impolite of the firmware to set it if there's _any_
> reason the OS might not want it set.

True.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 09:00:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 09:00:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRflY-0008JF-Kr; Fri, 26 Oct 2012 08:59:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRflX-0008J9-Eo
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 08:59:43 +0000
Received: from [193.109.254.147:17002] by server-11.bemta-14.messagelabs.com
	id 9E/00-29027-EF05A805; Fri, 26 Oct 2012 08:59:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1351241982!6095693!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15810 invoked from network); 26 Oct 2012 08:59:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 08:59:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,653,1344211200"; d="scan'208";a="15404354"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 08:59:42 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 09:59:42 +0100
Message-ID: <1351241980.15162.4.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Tim Deegan 
Date: Fri, 26 Oct 2012 09:59:40 +0100
In-Reply-To: <20121026085615.GA76080@ocelot.phlegethon.org>
References: 
	<1351091027-20740-4-git-send-email-stefano.stabellini@eu.citrix.com>
	<1351158737.18035.142.camel@zakaz.uk.xensource.com>
	
	<1351166670.18035.177.camel@zakaz.uk.xensource.com>
	<20121026085615.GA76080@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 4/7] xen/arm: set the SMP bit in the ACTLR
	register
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-26 at 09:56 +0100, Tim Deegan wrote:
> At 13:04 +0100 on 25 Oct (1351170270), Ian Campbell wrote:
> > On Thu, 2012-10-25 at 12:57 +0100, Stefano Stabellini wrote:
> > > On Thu, 25 Oct 2012, Ian Campbell wrote:
> > > > On Wed, 2012-10-24 at 16:03 +0100, Stefano Stabellini wrote:
> > > > > From the Cortex A15 manual:
> > > > > 
> > > > > "Enables the processor to receive instruction cache, BTB, and TLB maintenance
> > > > > operations from other processors"
> > > > > 
> > > > > ...
> > > > > 
> > > > > "You must set this bit before enabling the caches and MMU, or
> > > > > performing any cache and TLB maintenance operations. The only time
> > > > > you must clear this bit is during a processor power-down sequence"
> > > > 
> > > > Is it considered a bug that the firmware doesn't do this?
> > > 
> > > Why would it be? You can run fairly complicated pieces of software
> > > without caches or MMU.
> > 
> > True, I guess I just considered that not setting the SMP bit on the
> > second processor when the firmware starts it seemed a bit odd. If you
> > aren't caches/MMU/etc them then setting the bit is pretty much a NOP (or
> > maybe it isn't?).
> 
> Well, given that you're not allowed to clear it except at power-down, I
> think it would be impolite of the firmware to set it if there's _any_
> reason the OS might not want it set.

True.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 09:02:03 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 09:02:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRfnU-0008SV-7N; Fri, 26 Oct 2012 09:01:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TRfnS-0008SM-UF
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 09:01:43 +0000
Received: from [85.158.143.99:7776] by server-1.bemta-4.messagelabs.com id
	0F/55-19134-6715A805; Fri, 26 Oct 2012 09:01:42 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-216.messagelabs.com!1351242101!17696973!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6118 invoked from network); 26 Oct 2012 09:01:41 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Oct 2012 09:01:41 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TRfnR-000JpT-6p; Fri, 26 Oct 2012 09:01:41 +0000
Date: Fri, 26 Oct 2012 10:01:41 +0100
From: Tim Deegan 
To: Stefano Stabellini 
Message-ID: <20121026090141.GB76080@ocelot.phlegethon.org>
References: 
	<1351091027-20740-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20121024155945.GD39126@ocelot.phlegethon.org>
	
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" ,
	Ian Campbell 
Subject: Re: [Xen-devel] [PATCH 6/7] xen/arm: flush D-cache and I-cache when
	appropriate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 18:35 +0100 on 24 Oct (1351103740), Stefano Stabellini wrote:
> > I don't think this is necessary - why not just pass va directly to the
> > inline asm?  We don't care what register it's in (and if we did I'm not
> > convinced this would guarantee it was r0).
> > 
> > > +    asm volatile (
> > > +        "dsb;"
> > > +        STORE_CP32(0, DCCMVAC)
> > > +        "isb;"
> > > +        : : "r" (r0) : "memory");
> > 
> > Does this need a 'memory' clobber?  Can we get away with just saying it
> > consumes *va as an input?  All we need to be sure of is that the
> > particular thing we're flushing has been written out; no need to stop
> > any other optimizations.
> 
> you are right on both points
> 
> > I guess it might need to be re-cast as a macro so the compiler knows how
> > big *va is?
> 
> I don't think it is necessary, after all the size of a register has to
> be the same of a virtual address

But it's the size of the thing in memory that's being flushed that
matters, not the size of the pointer to it!  E.g. after a PTE write we
need a 64-bit memory input operand to stop the compiler from hoisting
any part of the PTE write past the cache flush. (well OK we explicitly use
a 64-bit atomic write for PTE writes, but YKWIM).

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 09:02:03 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 09:02:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRfnU-0008SV-7N; Fri, 26 Oct 2012 09:01:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TRfnS-0008SM-UF
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 09:01:43 +0000
Received: from [85.158.143.99:7776] by server-1.bemta-4.messagelabs.com id
	0F/55-19134-6715A805; Fri, 26 Oct 2012 09:01:42 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-216.messagelabs.com!1351242101!17696973!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6118 invoked from network); 26 Oct 2012 09:01:41 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Oct 2012 09:01:41 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TRfnR-000JpT-6p; Fri, 26 Oct 2012 09:01:41 +0000
Date: Fri, 26 Oct 2012 10:01:41 +0100
From: Tim Deegan 
To: Stefano Stabellini 
Message-ID: <20121026090141.GB76080@ocelot.phlegethon.org>
References: 
	<1351091027-20740-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20121024155945.GD39126@ocelot.phlegethon.org>
	
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" ,
	Ian Campbell 
Subject: Re: [Xen-devel] [PATCH 6/7] xen/arm: flush D-cache and I-cache when
	appropriate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 18:35 +0100 on 24 Oct (1351103740), Stefano Stabellini wrote:
> > I don't think this is necessary - why not just pass va directly to the
> > inline asm?  We don't care what register it's in (and if we did I'm not
> > convinced this would guarantee it was r0).
> > 
> > > +    asm volatile (
> > > +        "dsb;"
> > > +        STORE_CP32(0, DCCMVAC)
> > > +        "isb;"
> > > +        : : "r" (r0) : "memory");
> > 
> > Does this need a 'memory' clobber?  Can we get away with just saying it
> > consumes *va as an input?  All we need to be sure of is that the
> > particular thing we're flushing has been written out; no need to stop
> > any other optimizations.
> 
> you are right on both points
> 
> > I guess it might need to be re-cast as a macro so the compiler knows how
> > big *va is?
> 
> I don't think it is necessary, after all the size of a register has to
> be the same of a virtual address

But it's the size of the thing in memory that's being flushed that
matters, not the size of the pointer to it!  E.g. after a PTE write we
need a 64-bit memory input operand to stop the compiler from hoisting
any part of the PTE write past the cache flush. (well OK we explicitly use
a 64-bit atomic write for PTE writes, but YKWIM).

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 09:29:20 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 09:29:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRgDm-0000Jo-OH; Fri, 26 Oct 2012 09:28:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRgDk-0000JY-CW; Fri, 26 Oct 2012 09:28:52 +0000
Received: from [85.158.137.99:60296] by server-14.bemta-3.messagelabs.com id
	4E/35-12788-3D75A805; Fri, 26 Oct 2012 09:28:51 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1351243722!21897305!1
X-Originating-IP: [209.85.215.45]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14, ML_RADAR_SPEW_LINKS_8, RCVD_BY_IP,
	spamassassin: , 
	async_handler: YXN5bmNfZGVsYXk6IDcwNDU2MDcgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19523 invoked from network); 26 Oct 2012 09:28:43 -0000
Received: from mail-la0-f45.google.com (HELO mail-la0-f45.google.com)
	(209.85.215.45)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 09:28:43 -0000
Received: by mail-la0-f45.google.com with SMTP id m13so2928707lah.32
	for ; Fri, 26 Oct 2012 02:28:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=UPzZwpCuJ1nz4Xz7Yr1VbbxEX0sJkS4RiLfc/pPhxWc=;
	b=wmvUs49JHI4ot25pRtTGESOaXwqSiSosYg+qeTvGbuydu/g1JsJPTcCj65141nNhs5
	33bYXhuH8LPxPInbzoKH+jWoTC/JOLYTNRjgvJ7K64SmO6AeO6+1za07LgFQcJNYMoy2
	B4FiqjRtwFmGLwhsaxjh2owrGLpBHTRpeT2t+A81NpqUAHGESfc4C7IKC3QApclJNVGq
	KZ/sPRBm0szbXfcc8ZR+Y0sNkFKiMCeJFCrv8aC/6ga/IYJrM3+rXd5C0VnaPIiwmh3Z
	EBehePtwHTGuEfDDYbG5hGvEful+eSDQgDlVw/P06RTO3wL6tVFFMk50wiSIRrWOu2Ea
	t5LQ==
MIME-Version: 1.0
Received: by 10.152.105.33 with SMTP id gj1mr19994272lab.49.1351243722532;
	Fri, 26 Oct 2012 02:28:42 -0700 (PDT)
Received: by 10.112.26.166 with HTTP; Fri, 26 Oct 2012 02:28:42 -0700 (PDT)
Date: Fri, 26 Oct 2012 10:28:42 +0100
Message-ID: 
From: Lars Kurth 
To: xen-devel@lists.xen.org, xci-devel@lists.xen.org
Subject: [Xen-devel] XCI Archivation Review (VOTE)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============2762083895025238992=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2762083895025238992==
Content-Type: multipart/alternative; boundary=f46d040716e31625bb04ccf2f22c

--f46d040716e31625bb04ccf2f22c
Content-Type: text/plain; charset=ISO-8859-1

Hi everybody,

it's been on my list of things to do for a while, to formally close and
archive the XCI project. The reason for archiving the project is:

   - There is no Project Lead
   - The last try to revive the project in April/May did not lead anywhere
   - No activity in any of the repos for a year
   - No activity on XCI related wiki pages for a year
   - No activity on the mailing list for a year

What happens after the review?

   - The mailing list is archived (i.e. it is moved to the archived
   section) and closed for new posts
   - The wiki pages are archived
   - The web pages are moved into the xen.org archive
   - We will archive the repos

What needs to happen formally vote on an archivation review?

*Reviews:* These are off-line reviews which are open to all community
members by which a proposal is published for review
[This is this e-mail, done]

*Voting:* The community manager arranges a timed private vote as outlined
above (voting should be open for a minimum of a week). Any maintainer of a
mature project and the Xen.org community manager is allowed to vote. Voting
follows the conventions as laid out in "Principle: Consensus Decision
Making".

The link to vote privately is here:
https://docs.google.com/spreadsheet/ccc?key=0Ao04FrB3gtj2dG9pRTkxbTJkTC1weExuWmVTS0tHdHc#gid=0
The vote will be open for two weeks until Nov 9th 2012.

Best Regards
Lars

--f46d040716e31625bb04ccf2f22c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi everybody,

it's been on my list of things to do for a while, =
to formally close and archive the XCI project. The reason for archiving the=
 project is:
  • There is no Project Lead
  • The last try to re=
vive the project in April/May did not lead anywhere
    

  • No activity in any of the repos for a year
  • No activity on =
XCI related wiki pages for a year
  • No activity on the mailing list f=
or a year
What happens after the review?
  • The mailing li=
st is archived (i.e. it is moved to the archived section) and closed for ne=
w posts
    • 

  • The wiki pages are archived
  • The web pages are moved into the xen.org archive
  • We will archive the re=
pos
What needs to happen formally vote on an archivation revie=
w?


Reviews: These are off-line reviews which are open to all commun=
ity members by which a proposal is published for review
[This is this e-=
mail, done]

Voting: The community manager arranges a timed pr=
ivate vote as=20
outlined above (voting should be open for a minimum of a week). Any=20
maintainer of a mature
    project and the Xen.org community manager is allowed to vote. Voting
 follows the conventions as laid out in "Principle: Consensus Decision=
=20
Making".

The link to vote privately is here: https://docs.google.com/spreadsheet/ccc?key=3D0Ao04FrB3gt=
j2dG9pRTkxbTJkTC1weExuWmVTS0tHdHc#gid=3D0

The vote will be open for two weeks until Nov 9th 2012.

Best Regards=

Lars


--f46d040716e31625bb04ccf2f22c--


--===============2762083895025238992==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2762083895025238992==--


From xen-devel-bounces@lists.xen.org Fri Oct 26 09:29:20 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 09:29:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRgDm-0000Jo-OH; Fri, 26 Oct 2012 09:28:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRgDk-0000JY-CW; Fri, 26 Oct 2012 09:28:52 +0000
Received: from [85.158.137.99:60296] by server-14.bemta-3.messagelabs.com id
	4E/35-12788-3D75A805; Fri, 26 Oct 2012 09:28:51 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1351243722!21897305!1
X-Originating-IP: [209.85.215.45]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14, ML_RADAR_SPEW_LINKS_8, RCVD_BY_IP,
	spamassassin: , 
	async_handler: YXN5bmNfZGVsYXk6IDcwNDU2MDcgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19523 invoked from network); 26 Oct 2012 09:28:43 -0000
Received: from mail-la0-f45.google.com (HELO mail-la0-f45.google.com)
	(209.85.215.45)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 09:28:43 -0000
Received: by mail-la0-f45.google.com with SMTP id m13so2928707lah.32
	for ; Fri, 26 Oct 2012 02:28:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=UPzZwpCuJ1nz4Xz7Yr1VbbxEX0sJkS4RiLfc/pPhxWc=;
	b=wmvUs49JHI4ot25pRtTGESOaXwqSiSosYg+qeTvGbuydu/g1JsJPTcCj65141nNhs5
	33bYXhuH8LPxPInbzoKH+jWoTC/JOLYTNRjgvJ7K64SmO6AeO6+1za07LgFQcJNYMoy2
	B4FiqjRtwFmGLwhsaxjh2owrGLpBHTRpeT2t+A81NpqUAHGESfc4C7IKC3QApclJNVGq
	KZ/sPRBm0szbXfcc8ZR+Y0sNkFKiMCeJFCrv8aC/6ga/IYJrM3+rXd5C0VnaPIiwmh3Z
	EBehePtwHTGuEfDDYbG5hGvEful+eSDQgDlVw/P06RTO3wL6tVFFMk50wiSIRrWOu2Ea
	t5LQ==
MIME-Version: 1.0
Received: by 10.152.105.33 with SMTP id gj1mr19994272lab.49.1351243722532;
	Fri, 26 Oct 2012 02:28:42 -0700 (PDT)
Received: by 10.112.26.166 with HTTP; Fri, 26 Oct 2012 02:28:42 -0700 (PDT)
Date: Fri, 26 Oct 2012 10:28:42 +0100
Message-ID: 
From: Lars Kurth 
To: xen-devel@lists.xen.org, xci-devel@lists.xen.org
Subject: [Xen-devel] XCI Archivation Review (VOTE)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============2762083895025238992=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2762083895025238992==
Content-Type: multipart/alternative; boundary=f46d040716e31625bb04ccf2f22c

--f46d040716e31625bb04ccf2f22c
Content-Type: text/plain; charset=ISO-8859-1

Hi everybody,

it's been on my list of things to do for a while, to formally close and
archive the XCI project. The reason for archiving the project is:

   - There is no Project Lead
   - The last try to revive the project in April/May did not lead anywhere
   - No activity in any of the repos for a year
   - No activity on XCI related wiki pages for a year
   - No activity on the mailing list for a year

What happens after the review?

   - The mailing list is archived (i.e. it is moved to the archived
   section) and closed for new posts
   - The wiki pages are archived
   - The web pages are moved into the xen.org archive
   - We will archive the repos

What needs to happen formally vote on an archivation review?

*Reviews:* These are off-line reviews which are open to all community
members by which a proposal is published for review
[This is this e-mail, done]

*Voting:* The community manager arranges a timed private vote as outlined
above (voting should be open for a minimum of a week). Any maintainer of a
mature project and the Xen.org community manager is allowed to vote. Voting
follows the conventions as laid out in "Principle: Consensus Decision
Making".

The link to vote privately is here:
https://docs.google.com/spreadsheet/ccc?key=0Ao04FrB3gtj2dG9pRTkxbTJkTC1weExuWmVTS0tHdHc#gid=0
The vote will be open for two weeks until Nov 9th 2012.

Best Regards
Lars

--f46d040716e31625bb04ccf2f22c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi everybody,

it's been on my list of things to do for a while, =
to formally close and archive the XCI project. The reason for archiving the=
 project is:
  • There is no Project Lead
  • The last try to re=
vive the project in April/May did not lead anywhere
    

  • No activity in any of the repos for a year
  • No activity on =
XCI related wiki pages for a year
  • No activity on the mailing list f=
or a year
What happens after the review?
  • The mailing li=
st is archived (i.e. it is moved to the archived section) and closed for ne=
w posts
    • 

  • The wiki pages are archived
  • The web pages are moved into the xen.org archive
  • We will archive the re=
pos
What needs to happen formally vote on an archivation revie=
w?


Reviews: These are off-line reviews which are open to all commun=
ity members by which a proposal is published for review
[This is this e-=
mail, done]

Voting: The community manager arranges a timed pr=
ivate vote as=20
outlined above (voting should be open for a minimum of a week). Any=20
maintainer of a mature
    project and the Xen.org community manager is allowed to vote. Voting
 follows the conventions as laid out in "Principle: Consensus Decision=
=20
Making".

The link to vote privately is here: https://docs.google.com/spreadsheet/ccc?key=3D0Ao04FrB3gt=
j2dG9pRTkxbTJkTC1weExuWmVTS0tHdHc#gid=3D0

The vote will be open for two weeks until Nov 9th 2012.

Best Regards=

Lars


--f46d040716e31625bb04ccf2f22c--


--===============2762083895025238992==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2762083895025238992==--


From xen-devel-bounces@lists.xen.org Fri Oct 26 09:32:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 09:32:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRgGx-0000Qk-DV; Fri, 26 Oct 2012 09:32:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRgGw-0000Qe-RH
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 09:32:11 +0000
Received: from [85.158.139.83:61621] by server-12.bemta-5.messagelabs.com id
	F6/88-26919-9985A805; Fri, 26 Oct 2012 09:32:09 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1351243928!27420837!1
X-Originating-IP: [216.32.180.16]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18715 invoked from network); 26 Oct 2012 09:32:09 -0000
Received: from va3ehsobe006.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.16)
	by server-3.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	26 Oct 2012 09:32:09 -0000
Received: from mail88-va3-R.bigfish.com (10.7.14.246) by
	VA3EHSOBE006.bigfish.com (10.7.40.26) with Microsoft SMTP Server id
	14.1.225.23; Fri, 26 Oct 2012 09:32:08 +0000
Received: from mail88-va3 (localhost [127.0.0.1])	by mail88-va3-R.bigfish.com
	(Postfix) with ESMTP id CAABE120169	for ;
	Fri, 26 Oct 2012 09:32:07 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzc85fhc85dhzz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh34h1155h)
Received: from mail88-va3 (localhost.localdomain [127.0.0.1]) by mail88-va3
	(MessageSwitch) id 1351243925965461_15650;
	Fri, 26 Oct 2012 09:32:05 +0000 (UTC)
Received: from VA3EHSMHS046.bigfish.com (unknown [10.7.14.235])	by
	mail88-va3.bigfish.com (Postfix) with ESMTP id E6FF122006B	for
	; Fri, 26 Oct 2012 09:32:05 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS046.bigfish.com (10.7.99.56) with Microsoft SMTP Server id
	14.1.225.23; Fri, 26 Oct 2012 09:32:00 +0000
X-WSS-ID: 0MCHUH9-02-HD8-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2CA46C8118	for ; Fri, 26 Oct 2012
	04:31:56 -0500 (CDT)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 26 Oct 2012 04:32:16 -0500
Received: from STOREXDAG02.amd.com (10.1.13.11) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Fri, 26 Oct 2012 04:31:56 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag02.amd.com
	(10.1.13.11) with Microsoft SMTP Server id 14.2.318.4; Fri, 26 Oct 2012
	05:31:55 -0400
Message-ID: <508A5889.8030801@amd.com>
Date: Fri, 26 Oct 2012 11:31:53 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" 
Content-Type: multipart/mixed; boundary="------------050805080700050003060106"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] MCE: Allow AMD MSRs injected via xen-mceinj
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------050805080700050003060106
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit


Allow AMD MSRs injected via xen-mceinj

Signed-off-by: Christoph Egger 

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------050805080700050003060106
Content-Type: text/plain; charset="us-ascii"; name="xen_mce_msrinject.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_mce_msrinject.diff"
Content-Description: xen_mce_msrinject.diff

diff -r 7abb25095de0 xen/arch/x86/cpu/mcheck/mce.c
--- a/xen/arch/x86/cpu/mcheck/mce.c	Thu Oct 25 13:15:19 2012 +0200
+++ b/xen/arch/x86/cpu/mcheck/mce.c	Fri Oct 26 09:55:35 2012 +0200
@@ -1145,6 +1121,19 @@ static int x86_mc_msrinject_verify(struc
             case MSR_IA32_MCG_STATUS:
                 break;
 
+            case MSR_F10_MC4_MISC1:
+            case MSR_F10_MC4_MISC2:
+            case MSR_F10_MC4_MISC3:
+                if (c->x86_vendor != X86_VENDOR_AMD) {
+                    reason = "only supported on AMD";
+                    break;
+                }
+                if (c->x86 < 0x10) {
+                    reason = "only supported on AMD Family 10h+";
+                    break;
+                }
+                break;
+
                 /* MSRs that the HV will take care of */
             case MSR_K8_HWCR:
                 if (c->x86_vendor == X86_VENDOR_AMD)

--------------050805080700050003060106
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------050805080700050003060106--


From xen-devel-bounces@lists.xen.org Fri Oct 26 09:32:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 09:32:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRgGx-0000Qk-DV; Fri, 26 Oct 2012 09:32:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRgGw-0000Qe-RH
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 09:32:11 +0000
Received: from [85.158.139.83:61621] by server-12.bemta-5.messagelabs.com id
	F6/88-26919-9985A805; Fri, 26 Oct 2012 09:32:09 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1351243928!27420837!1
X-Originating-IP: [216.32.180.16]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18715 invoked from network); 26 Oct 2012 09:32:09 -0000
Received: from va3ehsobe006.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.16)
	by server-3.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	26 Oct 2012 09:32:09 -0000
Received: from mail88-va3-R.bigfish.com (10.7.14.246) by
	VA3EHSOBE006.bigfish.com (10.7.40.26) with Microsoft SMTP Server id
	14.1.225.23; Fri, 26 Oct 2012 09:32:08 +0000
Received: from mail88-va3 (localhost [127.0.0.1])	by mail88-va3-R.bigfish.com
	(Postfix) with ESMTP id CAABE120169	for ;
	Fri, 26 Oct 2012 09:32:07 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzc85fhc85dhzz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh34h1155h)
Received: from mail88-va3 (localhost.localdomain [127.0.0.1]) by mail88-va3
	(MessageSwitch) id 1351243925965461_15650;
	Fri, 26 Oct 2012 09:32:05 +0000 (UTC)
Received: from VA3EHSMHS046.bigfish.com (unknown [10.7.14.235])	by
	mail88-va3.bigfish.com (Postfix) with ESMTP id E6FF122006B	for
	; Fri, 26 Oct 2012 09:32:05 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS046.bigfish.com (10.7.99.56) with Microsoft SMTP Server id
	14.1.225.23; Fri, 26 Oct 2012 09:32:00 +0000
X-WSS-ID: 0MCHUH9-02-HD8-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2CA46C8118	for ; Fri, 26 Oct 2012
	04:31:56 -0500 (CDT)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 26 Oct 2012 04:32:16 -0500
Received: from STOREXDAG02.amd.com (10.1.13.11) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Fri, 26 Oct 2012 04:31:56 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag02.amd.com
	(10.1.13.11) with Microsoft SMTP Server id 14.2.318.4; Fri, 26 Oct 2012
	05:31:55 -0400
Message-ID: <508A5889.8030801@amd.com>
Date: Fri, 26 Oct 2012 11:31:53 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" 
Content-Type: multipart/mixed; boundary="------------050805080700050003060106"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] MCE: Allow AMD MSRs injected via xen-mceinj
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------050805080700050003060106
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit


Allow AMD MSRs injected via xen-mceinj

Signed-off-by: Christoph Egger 

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------050805080700050003060106
Content-Type: text/plain; charset="us-ascii"; name="xen_mce_msrinject.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_mce_msrinject.diff"
Content-Description: xen_mce_msrinject.diff

diff -r 7abb25095de0 xen/arch/x86/cpu/mcheck/mce.c
--- a/xen/arch/x86/cpu/mcheck/mce.c	Thu Oct 25 13:15:19 2012 +0200
+++ b/xen/arch/x86/cpu/mcheck/mce.c	Fri Oct 26 09:55:35 2012 +0200
@@ -1145,6 +1121,19 @@ static int x86_mc_msrinject_verify(struc
             case MSR_IA32_MCG_STATUS:
                 break;
 
+            case MSR_F10_MC4_MISC1:
+            case MSR_F10_MC4_MISC2:
+            case MSR_F10_MC4_MISC3:
+                if (c->x86_vendor != X86_VENDOR_AMD) {
+                    reason = "only supported on AMD";
+                    break;
+                }
+                if (c->x86 < 0x10) {
+                    reason = "only supported on AMD Family 10h+";
+                    break;
+                }
+                break;
+
                 /* MSRs that the HV will take care of */
             case MSR_K8_HWCR:
                 if (c->x86_vendor == X86_VENDOR_AMD)

--------------050805080700050003060106
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------050805080700050003060106--


From xen-devel-bounces@lists.xen.org Fri Oct 26 10:05:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 10:05:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRgmz-0000qG-QB; Fri, 26 Oct 2012 10:05:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRgmy-0000qB-EN
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 10:05:16 +0000
Received: from [85.158.143.35:34436] by server-1.bemta-4.messagelabs.com id
	80/1A-19134-B506A805; Fri, 26 Oct 2012 10:05:15 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1351245913!15901148!1
X-Originating-IP: [216.32.180.31]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15052 invoked from network); 26 Oct 2012 10:05:14 -0000
Received: from va3ehsobe005.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.31)
	by server-14.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	26 Oct 2012 10:05:14 -0000
Received: from mail219-va3-R.bigfish.com (10.7.14.245) by
	VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id
	14.1.225.23; Fri, 26 Oct 2012 10:05:12 +0000
Received: from mail219-va3 (localhost [127.0.0.1])	by
	mail219-va3-R.bigfish.com (Postfix) with ESMTP id 98CFE60012C;
	Fri, 26 Oct 2012 10:05:12 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: -3
X-BigFish: VPS-3(zzbb2dI98dI1432Izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h)
Received: from mail219-va3 (localhost.localdomain [127.0.0.1]) by mail219-va3
	(MessageSwitch) id 1351245909999266_11401;
	Fri, 26 Oct 2012 10:05:09 +0000 (UTC)
Received: from VA3EHSMHS013.bigfish.com (unknown [10.7.14.245])	by
	mail219-va3.bigfish.com (Postfix) with ESMTP id EFE9D7E016E;
	Fri, 26 Oct 2012 10:05:09 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS013.bigfish.com (10.7.99.23) with Microsoft SMTP Server id
	14.1.225.23; Fri, 26 Oct 2012 10:05:05 +0000
X-WSS-ID: 0MCHV7F-01-5R6-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2E5A0D100BA;	Fri, 26 Oct 2012 04:47:38 -0500 (CDT)
Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 26 Oct 2012 04:47:58 -0500
Received: from STOREXDAG02.amd.com (10.1.13.11) by sausexdag03.amd.com
	(163.181.55.3) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Fri, 26 Oct 2012 04:47:38 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag02.amd.com
	(10.1.13.11) with Microsoft SMTP Server id 14.2.318.4; Fri, 26 Oct 2012
	05:47:37 -0400
Message-ID: <508A5C38.4010609@amd.com>
Date: Fri, 26 Oct 2012 11:47:36 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Jackson 
References: <508916B3.2030403@amd.com>
	<20617.13045.486553.172990@mariner.uk.xensource.com>
In-Reply-To: <20617.13045.486553.172990@mariner.uk.xensource.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] tools: use PREFIX when building upstream
 qemu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/25/12 14:39, Ian Jackson wrote:
> Christoph Egger writes ("[Xen-devel] [PATCH] tools: use PREFIX when building upstream qemu"):
>>
>> use PREFIX when building upstream qemu.
>>
>> Signed-off-by: Christoph Egger 
> 
> This looks reasonable but can you explain what goes wrong when,
> without this ?  I'd like to be able to verify the bug and fix myself.

qemu's configure assumes /usr/local as prefix by default, otherwise.
With this patch, qemu config files and manpages are installed under
the specified $(PREFIX).

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 10:05:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 10:05:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRgmz-0000qG-QB; Fri, 26 Oct 2012 10:05:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRgmy-0000qB-EN
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 10:05:16 +0000
Received: from [85.158.143.35:34436] by server-1.bemta-4.messagelabs.com id
	80/1A-19134-B506A805; Fri, 26 Oct 2012 10:05:15 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1351245913!15901148!1
X-Originating-IP: [216.32.180.31]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15052 invoked from network); 26 Oct 2012 10:05:14 -0000
Received: from va3ehsobe005.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.31)
	by server-14.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	26 Oct 2012 10:05:14 -0000
Received: from mail219-va3-R.bigfish.com (10.7.14.245) by
	VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id
	14.1.225.23; Fri, 26 Oct 2012 10:05:12 +0000
Received: from mail219-va3 (localhost [127.0.0.1])	by
	mail219-va3-R.bigfish.com (Postfix) with ESMTP id 98CFE60012C;
	Fri, 26 Oct 2012 10:05:12 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: -3
X-BigFish: VPS-3(zzbb2dI98dI1432Izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h)
Received: from mail219-va3 (localhost.localdomain [127.0.0.1]) by mail219-va3
	(MessageSwitch) id 1351245909999266_11401;
	Fri, 26 Oct 2012 10:05:09 +0000 (UTC)
Received: from VA3EHSMHS013.bigfish.com (unknown [10.7.14.245])	by
	mail219-va3.bigfish.com (Postfix) with ESMTP id EFE9D7E016E;
	Fri, 26 Oct 2012 10:05:09 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS013.bigfish.com (10.7.99.23) with Microsoft SMTP Server id
	14.1.225.23; Fri, 26 Oct 2012 10:05:05 +0000
X-WSS-ID: 0MCHV7F-01-5R6-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2E5A0D100BA;	Fri, 26 Oct 2012 04:47:38 -0500 (CDT)
Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 26 Oct 2012 04:47:58 -0500
Received: from STOREXDAG02.amd.com (10.1.13.11) by sausexdag03.amd.com
	(163.181.55.3) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Fri, 26 Oct 2012 04:47:38 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag02.amd.com
	(10.1.13.11) with Microsoft SMTP Server id 14.2.318.4; Fri, 26 Oct 2012
	05:47:37 -0400
Message-ID: <508A5C38.4010609@amd.com>
Date: Fri, 26 Oct 2012 11:47:36 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Jackson 
References: <508916B3.2030403@amd.com>
	<20617.13045.486553.172990@mariner.uk.xensource.com>
In-Reply-To: <20617.13045.486553.172990@mariner.uk.xensource.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] tools: use PREFIX when building upstream
 qemu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/25/12 14:39, Ian Jackson wrote:
> Christoph Egger writes ("[Xen-devel] [PATCH] tools: use PREFIX when building upstream qemu"):
>>
>> use PREFIX when building upstream qemu.
>>
>> Signed-off-by: Christoph Egger 
> 
> This looks reasonable but can you explain what goes wrong when,
> without this ?  I'd like to be able to verify the bug and fix myself.

qemu's configure assumes /usr/local as prefix by default, otherwise.
With this patch, qemu config files and manpages are installed under
the specified $(PREFIX).

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 10:16:22 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 10:16:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRgxK-000107-WB; Fri, 26 Oct 2012 10:15:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRgxJ-000102-Ho
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 10:15:57 +0000
Received: from [85.158.139.211:35073] by server-7.bemta-5.messagelabs.com id
	A4/E6-23102-CD26A805; Fri, 26 Oct 2012 10:15:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1351246552!19845088!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30435 invoked from network); 26 Oct 2012 10:15:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 10:15:53 -0000
X-IronPort-AV: E=Sophos;i="4.80,653,1344211200"; d="scan'208";a="15406541"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 10:15:20 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 11:15:20 +0100
Message-ID: <1351246518.15162.23.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Christoph Egger 
Date: Fri, 26 Oct 2012 11:15:18 +0100
In-Reply-To: <508A5C38.4010609@amd.com>
References: <508916B3.2030403@amd.com>
	<20617.13045.486553.172990@mariner.uk.xensource.com>
	<508A5C38.4010609@amd.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] tools: use PREFIX when building upstream
 qemu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-26 at 10:47 +0100, Christoph Egger wrote:
> On 10/25/12 14:39, Ian Jackson wrote:
> > Christoph Egger writes ("[Xen-devel] [PATCH] tools: use PREFIX when building upstream qemu"):
> >>
> >> use PREFIX when building upstream qemu.
> >>
> >> Signed-off-by: Christoph Egger 
> > 
> > This looks reasonable but can you explain what goes wrong when,
> > without this ?  I'd like to be able to verify the bug and fix myself.
> 
> qemu's configure assumes /usr/local as prefix by default, otherwise.
> With this patch, qemu config files and manpages are installed under
> the specified $(PREFIX).

Is that what we want? Or do we want our version of qemu to be
under /usr/lib/xen?

> 
> Christoph
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 10:16:22 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 10:16:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRgxK-000107-WB; Fri, 26 Oct 2012 10:15:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRgxJ-000102-Ho
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 10:15:57 +0000
Received: from [85.158.139.211:35073] by server-7.bemta-5.messagelabs.com id
	A4/E6-23102-CD26A805; Fri, 26 Oct 2012 10:15:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1351246552!19845088!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30435 invoked from network); 26 Oct 2012 10:15:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 10:15:53 -0000
X-IronPort-AV: E=Sophos;i="4.80,653,1344211200"; d="scan'208";a="15406541"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 10:15:20 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 11:15:20 +0100
Message-ID: <1351246518.15162.23.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Christoph Egger 
Date: Fri, 26 Oct 2012 11:15:18 +0100
In-Reply-To: <508A5C38.4010609@amd.com>
References: <508916B3.2030403@amd.com>
	<20617.13045.486553.172990@mariner.uk.xensource.com>
	<508A5C38.4010609@amd.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] tools: use PREFIX when building upstream
 qemu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-26 at 10:47 +0100, Christoph Egger wrote:
> On 10/25/12 14:39, Ian Jackson wrote:
> > Christoph Egger writes ("[Xen-devel] [PATCH] tools: use PREFIX when building upstream qemu"):
> >>
> >> use PREFIX when building upstream qemu.
> >>
> >> Signed-off-by: Christoph Egger 
> > 
> > This looks reasonable but can you explain what goes wrong when,
> > without this ?  I'd like to be able to verify the bug and fix myself.
> 
> qemu's configure assumes /usr/local as prefix by default, otherwise.
> With this patch, qemu config files and manpages are installed under
> the specified $(PREFIX).

Is that what we want? Or do we want our version of qemu to be
under /usr/lib/xen?

> 
> Christoph
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 10:26:21 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 10:26:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRh75-00019a-57; Fri, 26 Oct 2012 10:26:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRh73-00019N-N8; Fri, 26 Oct 2012 10:26:02 +0000
Received: from [85.158.139.83:25588] by server-10.bemta-5.messagelabs.com id
	A7/49-01025-8356A805; Fri, 26 Oct 2012 10:26:00 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1351247150!16168215!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_8,RCVD_BY_IP,spamassassin: ,async_handler: 
	YXN5bmNfZGVsYXk6IDcwNDgyMjIgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24505 invoked from network); 26 Oct 2012 10:25:50 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 10:25:50 -0000
Received: by mail-bk0-f45.google.com with SMTP id jf3so1194541bkc.32
	for ; Fri, 26 Oct 2012 03:25:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:cc
	:subject:references:in-reply-to:content-type;
	bh=Rkc0wN4ul7KRm1RUNisie4vDhJrHvSwW2GcNENrZol4=;
	b=ryZSZ1EwzlRfVhUaMpQAE8YQQKWFvBOjBwXN77dt6QVuqRgJbhjKg5CUSu6xqdBZWC
	HyxH0PsgN/RKf+uYjD2DajzKxh3bziFdWLDdZqeT3Yygf4r0lRJM8uY6iLbTkN3np6vA
	PB8Q+xf84GvD+G9DpOO/2iN25RuXhTwtxTV3l36p0jvOLaqKj17VD93wbkfNaYdT87zE
	UKbDf3ncak3ejRxrnAHxQ8I0bukwCgeVMbk10MZWGLDUNugrDObWbS/GJJGHn6ntb4kk
	j+B7lEqZm3/tCjY6bD8hwAIWrKVsIe1UZQHcCS72qQ8ulIHvWwkTBu38H4I0Y3Ux8qzf
	GQUw==
Received: by 10.204.156.202 with SMTP id y10mr7033431bkw.6.1351247149951;
	Fri, 26 Oct 2012 03:25:49 -0700 (PDT)
Received: from [172.16.26.11] (b0fb5ab2.bb.sky.com. [176.251.90.178])
	by mx.google.com with ESMTPS id 9sm599246bkq.13.2012.10.26.03.25.47
	(version=SSLv3 cipher=OTHER); Fri, 26 Oct 2012 03:25:48 -0700 (PDT)
Message-ID: <508A652A.7050002@xen.org>
Date: Fri, 26 Oct 2012 11:25:46 +0100
From: Lars Kurth 
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
References: 
In-Reply-To: 
Cc: xci-devel@lists.xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] XCI Archivation Review (VOTE)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: lars.kurth@xen.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0932937670750885955=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============0932937670750885955==
Content-Type: multipart/alternative;
 boundary="------------080401090107040802060705"

This is a multi-part message in MIME format.
--------------080401090107040802060705
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

If you do not want to use Google Docs, please reply privately
+1 (for Archivation)
0 (Abstain)
-1 (against archivation)

Lars

On 26/10/2012 10:28, Lars Kurth wrote:
> Hi everybody,
>
> it's been on my list of things to do for a while, to formally close 
> and archive the XCI project. The reason for archiving the project is:
>
>   * There is no Project Lead
>   * The last try to revive the project in April/May did not lead anywhere
>   * No activity in any of the repos for a year
>   * No activity on XCI related wiki pages for a year
>   * No activity on the mailing list for a year
>
> What happens after the review?
>
>   * The mailing list is archived (i.e. it is moved to the archived
>     section) and closed for new posts
>   * The wiki pages are archived
>   * The web pages are moved into the xen.org  archive
>   * We will archive the repos
>
> What needs to happen formally vote on an archivation review?
>
> *Reviews:* These are off-line reviews which are open to all community 
> members by which a proposal is published for review
> [This is this e-mail, done]
>
> *Voting:* The community manager arranges a timed private vote as 
> outlined above (voting should be open for a minimum of a week). Any 
> maintainer of a mature project and the Xen.org community manager is 
> allowed to vote. Voting follows the conventions as laid out in 
> "Principle: Consensus Decision Making".
>
> The link to vote privately is here: 
> https://docs.google.com/spreadsheet/ccc?key=0Ao04FrB3gtj2dG9pRTkxbTJkTC1weExuWmVTS0tHdHc#gid=0
> The vote will be open for two weeks until Nov 9th 2012.
>
> Best Regards
> Lars


--------------080401090107040802060705
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
If you do not want to use Google Docs,
      please reply privately

      +1 (for Archivation)

      0 (Abstain)

      -1 (against archivation)

      

      Lars

       

      On 26/10/2012 10:28, Lars Kurth wrote:

    

    
Hi everybody,

      

      it's been on my list of things to do for a while, to formally
      close and archive the XCI project. The reason for archiving the
      project is:

      
    
        
  • There is no Project Lead
    • 
        
  • The last try to revive the project in April/May did not lead
          anywhere
    
        
    • 
        
  • No activity in any of the repos for a year
    • 
        
  • No activity on XCI related wiki pages for a year
    • 
        
  • No activity on the mailing list for a year
    • 
      

      What happens after the review?

      
    
        
  • The mailing list is archived (i.e. it is moved to the
          archived section) and closed for new posts
    • 
        
  • The wiki pages are archived
    • 
        
  • The web pages are moved into the xen.org archive
    • 
        
  • We will archive the repos
    
        
    • 
      

      What needs to happen formally vote on an archivation review?

      

      Reviews: These are off-line reviews which are open to all
      community members by which a proposal is published for review

      [This is this e-mail, done]

      

      Voting: The community manager arranges a timed private vote
      as outlined above (voting should be open for a minimum of a week).
      Any maintainer of a mature project and the Xen.org community
      manager is allowed to vote. Voting follows the conventions as laid
      out in "Principle: Consensus Decision Making".

      

      The link to vote privately is here: https://docs.google.com/spreadsheet/ccc?key=0Ao04FrB3gtj2dG9pRTkxbTJkTC1weExuWmVTS0tHdHc#gid=0

      The vote will be open for two weeks until Nov 9th 2012.

      

      Best Regards

      Lars

    

    

  


--------------080401090107040802060705--


--===============0932937670750885955==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0932937670750885955==--


From xen-devel-bounces@lists.xen.org Fri Oct 26 10:26:21 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 10:26:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRh75-00019a-57; Fri, 26 Oct 2012 10:26:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRh73-00019N-N8; Fri, 26 Oct 2012 10:26:02 +0000
Received: from [85.158.139.83:25588] by server-10.bemta-5.messagelabs.com id
	A7/49-01025-8356A805; Fri, 26 Oct 2012 10:26:00 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1351247150!16168215!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_8,RCVD_BY_IP,spamassassin: ,async_handler: 
	YXN5bmNfZGVsYXk6IDcwNDgyMjIgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24505 invoked from network); 26 Oct 2012 10:25:50 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 10:25:50 -0000
Received: by mail-bk0-f45.google.com with SMTP id jf3so1194541bkc.32
	for ; Fri, 26 Oct 2012 03:25:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:cc
	:subject:references:in-reply-to:content-type;
	bh=Rkc0wN4ul7KRm1RUNisie4vDhJrHvSwW2GcNENrZol4=;
	b=ryZSZ1EwzlRfVhUaMpQAE8YQQKWFvBOjBwXN77dt6QVuqRgJbhjKg5CUSu6xqdBZWC
	HyxH0PsgN/RKf+uYjD2DajzKxh3bziFdWLDdZqeT3Yygf4r0lRJM8uY6iLbTkN3np6vA
	PB8Q+xf84GvD+G9DpOO/2iN25RuXhTwtxTV3l36p0jvOLaqKj17VD93wbkfNaYdT87zE
	UKbDf3ncak3ejRxrnAHxQ8I0bukwCgeVMbk10MZWGLDUNugrDObWbS/GJJGHn6ntb4kk
	j+B7lEqZm3/tCjY6bD8hwAIWrKVsIe1UZQHcCS72qQ8ulIHvWwkTBu38H4I0Y3Ux8qzf
	GQUw==
Received: by 10.204.156.202 with SMTP id y10mr7033431bkw.6.1351247149951;
	Fri, 26 Oct 2012 03:25:49 -0700 (PDT)
Received: from [172.16.26.11] (b0fb5ab2.bb.sky.com. [176.251.90.178])
	by mx.google.com with ESMTPS id 9sm599246bkq.13.2012.10.26.03.25.47
	(version=SSLv3 cipher=OTHER); Fri, 26 Oct 2012 03:25:48 -0700 (PDT)
Message-ID: <508A652A.7050002@xen.org>
Date: Fri, 26 Oct 2012 11:25:46 +0100
From: Lars Kurth 
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
References: 
In-Reply-To: 
Cc: xci-devel@lists.xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] XCI Archivation Review (VOTE)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: lars.kurth@xen.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0932937670750885955=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============0932937670750885955==
Content-Type: multipart/alternative;
 boundary="------------080401090107040802060705"

This is a multi-part message in MIME format.
--------------080401090107040802060705
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

If you do not want to use Google Docs, please reply privately
+1 (for Archivation)
0 (Abstain)
-1 (against archivation)

Lars

On 26/10/2012 10:28, Lars Kurth wrote:
> Hi everybody,
>
> it's been on my list of things to do for a while, to formally close 
> and archive the XCI project. The reason for archiving the project is:
>
>   * There is no Project Lead
>   * The last try to revive the project in April/May did not lead anywhere
>   * No activity in any of the repos for a year
>   * No activity on XCI related wiki pages for a year
>   * No activity on the mailing list for a year
>
> What happens after the review?
>
>   * The mailing list is archived (i.e. it is moved to the archived
>     section) and closed for new posts
>   * The wiki pages are archived
>   * The web pages are moved into the xen.org  archive
>   * We will archive the repos
>
> What needs to happen formally vote on an archivation review?
>
> *Reviews:* These are off-line reviews which are open to all community 
> members by which a proposal is published for review
> [This is this e-mail, done]
>
> *Voting:* The community manager arranges a timed private vote as 
> outlined above (voting should be open for a minimum of a week). Any 
> maintainer of a mature project and the Xen.org community manager is 
> allowed to vote. Voting follows the conventions as laid out in 
> "Principle: Consensus Decision Making".
>
> The link to vote privately is here: 
> https://docs.google.com/spreadsheet/ccc?key=0Ao04FrB3gtj2dG9pRTkxbTJkTC1weExuWmVTS0tHdHc#gid=0
> The vote will be open for two weeks until Nov 9th 2012.
>
> Best Regards
> Lars


--------------080401090107040802060705
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
If you do not want to use Google Docs,
      please reply privately

      +1 (for Archivation)

      0 (Abstain)

      -1 (against archivation)

      

      Lars

       

      On 26/10/2012 10:28, Lars Kurth wrote:

    

    
Hi everybody,

      

      it's been on my list of things to do for a while, to formally
      close and archive the XCI project. The reason for archiving the
      project is:

      
    
        
  • There is no Project Lead
    • 
        
  • The last try to revive the project in April/May did not lead
          anywhere
    
        
    • 
        
  • No activity in any of the repos for a year
    • 
        
  • No activity on XCI related wiki pages for a year
    • 
        
  • No activity on the mailing list for a year
    • 
      

      What happens after the review?

      
    
        
  • The mailing list is archived (i.e. it is moved to the
          archived section) and closed for new posts
    • 
        
  • The wiki pages are archived
    • 
        
  • The web pages are moved into the xen.org archive
    • 
        
  • We will archive the repos
    
        
    • 
      

      What needs to happen formally vote on an archivation review?

      

      Reviews: These are off-line reviews which are open to all
      community members by which a proposal is published for review

      [This is this e-mail, done]

      

      Voting: The community manager arranges a timed private vote
      as outlined above (voting should be open for a minimum of a week).
      Any maintainer of a mature project and the Xen.org community
      manager is allowed to vote. Voting follows the conventions as laid
      out in "Principle: Consensus Decision Making".

      

      The link to vote privately is here: https://docs.google.com/spreadsheet/ccc?key=0Ao04FrB3gtj2dG9pRTkxbTJkTC1weExuWmVTS0tHdHc#gid=0

      The vote will be open for two weeks until Nov 9th 2012.

      

      Best Regards

      Lars

    

    

  


--------------080401090107040802060705--


--===============0932937670750885955==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0932937670750885955==--


From xen-devel-bounces@lists.xen.org Fri Oct 26 10:29:06 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 10:29:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRh9m-0001Hu-VM; Fri, 26 Oct 2012 10:28:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRh9k-0001HY-Np; Fri, 26 Oct 2012 10:28:49 +0000
Received: from [85.158.143.35:31572] by server-1.bemta-4.messagelabs.com id
	7C/3D-19134-0E56A805; Fri, 26 Oct 2012 10:28:48 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1351247297!11786649!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_8,RCVD_BY_IP,spamassassin: ,async_handler: 
	YXN5bmNfZGVsYXk6IDcwNjI5MTkgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17129 invoked from network); 26 Oct 2012 10:28:18 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 10:28:18 -0000
Received: by mail-bk0-f45.google.com with SMTP id jf3so1195636bkc.32
	for ; Fri, 26 Oct 2012 03:28:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:cc
	:subject:references:in-reply-to:content-type;
	bh=0kq4GRZ+4j33xG6w1K5ISb2rqhN+XOarlyjjvSPQZEY=;
	b=fAV+OAf72eQbXUvbGzynrvHm5H7cdJLwH1PJuuOgly9QeTgIGxgoqrB2Fs8sRfEwFe
	ttiz52rYHzZWiwX81i+bznC6a3ikdVMM5hr4BmsWdEo5s+aKG3s7GG150dKhNHCO17pH
	FDVwcfhjlsqCfTq2AU5JV7gQzwieUvtE0+Uhvmlq+lhqG+Un69P7ASQ9WXe+E4KEe5ms
	OAe+5azrutVEF8DQNACAACS9265vvaHKnl6V02dX2B/X8NyhztWjcIuVeTX6TQWyFMoJ
	cPspxKx9yX7X+BvUA5InVEQfC5axztWmtiyUJNah8jiW7yjvEbQxfwXP8kNoB2Z4AXQh
	UX2w==
Received: by 10.204.11.70 with SMTP id s6mr7159920bks.63.1351247297500;
	Fri, 26 Oct 2012 03:28:17 -0700 (PDT)
Received: from [172.16.26.11] (b0fb5ab2.bb.sky.com. [176.251.90.178])
	by mx.google.com with ESMTPS id x13sm605119bkv.16.2012.10.26.03.28.16
	(version=SSLv3 cipher=OTHER); Fri, 26 Oct 2012 03:28:16 -0700 (PDT)
Message-ID: <508A65BF.5040807@xen.org>
Date: Fri, 26 Oct 2012 11:28:15 +0100
From: Lars Kurth 
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
References: 
	<508A652A.7050002@xen.org>
In-Reply-To: <508A652A.7050002@xen.org>
Cc: xci-devel@lists.xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] XCI Archivation Review (VOTE)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: lars.kurth@xen.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============2376557697284371667=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============2376557697284371667==
Content-Type: multipart/alternative;
 boundary="------------070703040306090909000703"

This is a multi-part message in MIME format.
--------------070703040306090909000703
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

And I just realized that I sent the wrong voting link: it should be
https://docs.google.com/spreadsheet/viewform?formkey=dG9pRTkxbTJkTC1weExuWmVTS0tHdHc6MA#gid=0

Sorry

Lars

On 26/10/2012 11:25, Lars Kurth wrote:
> If you do not want to use Google Docs, please reply privately
> +1 (for Archivation)
> 0 (Abstain)
> -1 (against archivation)
>
> Lars
>
> On 26/10/2012 10:28, Lars Kurth wrote:
>> Hi everybody,
>>
>> it's been on my list of things to do for a while, to formally close 
>> and archive the XCI project. The reason for archiving the project is:
>>
>>   * There is no Project Lead
>>   * The last try to revive the project in April/May did not lead anywhere
>>   * No activity in any of the repos for a year
>>   * No activity on XCI related wiki pages for a year
>>   * No activity on the mailing list for a year
>>
>> What happens after the review?
>>
>>   * The mailing list is archived (i.e. it is moved to the archived
>>     section) and closed for new posts
>>   * The wiki pages are archived
>>   * The web pages are moved into the xen.org  archive
>>   * We will archive the repos
>>
>> What needs to happen formally vote on an archivation review?
>>
>> *Reviews:* These are off-line reviews which are open to all community 
>> members by which a proposal is published for review
>> [This is this e-mail, done]
>>
>> *Voting:* The community manager arranges a timed private vote as 
>> outlined above (voting should be open for a minimum of a week). Any 
>> maintainer of a mature project and the Xen.org community manager is 
>> allowed to vote. Voting follows the conventions as laid out in 
>> "Principle: Consensus Decision Making".
>>
>> The link to vote privately is here: 
>> https://docs.google.com/spreadsheet/ccc?key=0Ao04FrB3gtj2dG9pRTkxbTJkTC1weExuWmVTS0tHdHc#gid=0
>> The vote will be open for two weeks until Nov 9th 2012.
>>
>> Best Regards
>> Lars
>


--------------070703040306090909000703
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
And I just realized that I sent the
      wrong voting link: it should be 

https://docs.google.com/spreadsheet/viewform?formkey=dG9pRTkxbTJkTC1weExuWmVTS0tHdHc6MA#gid=0

      

      Sorry

      

      Lars

      

      On 26/10/2012 11:25, Lars Kurth wrote:

    

    

      
      
If you do not want to use Google
        Docs, please reply privately

        +1 (for Archivation)

        0 (Abstain)

        -1 (against archivation)

        

        Lars

         

        On 26/10/2012 10:28, Lars Kurth wrote:

      

      
Hi everybody,

        

        it's been on my list of things to do for a while, to formally
        close and archive the XCI project. The reason for archiving the
        project is:

        
    
          
  • There is no Project Lead
    • 
          
  • The last try to revive the project in April/May did not
            lead anywhere
    
          
    • 
          
  • No activity in any of the repos for a year
    • 
          
  • No activity on XCI related wiki pages for a year
    • 
          
  • No activity on the mailing list for a year
    • 
        

        What happens after the review?

        
    
          
  • The mailing list is archived (i.e. it is moved to the
            archived section) and closed for new posts
    • 
          
  • The wiki pages are archived
    • 
          
  • The web pages are moved into the xen.org
            archive
    • 
          
  • We will archive the repos
    
          
    • 
        

        What needs to happen formally vote on an archivation review?

        

        Reviews: These are off-line reviews which are open to all
        community members by which a proposal is published for review

        [This is this e-mail, done]

        

        Voting: The community manager arranges a timed private
        vote as outlined above (voting should be open for a minimum of a
        week). Any maintainer of a mature project and the Xen.org
        community manager is allowed to vote. Voting follows the
        conventions as laid out in "Principle: Consensus Decision
        Making".

        

        The link to vote privately is here: https://docs.google.com/spreadsheet/ccc?key=0Ao04FrB3gtj2dG9pRTkxbTJkTC1weExuWmVTS0tHdHc#gid=0

        The vote will be open for two weeks until Nov 9th 2012.

        

        Best Regards

        Lars

      

      

    

    

  


--------------070703040306090909000703--


--===============2376557697284371667==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2376557697284371667==--


From xen-devel-bounces@lists.xen.org Fri Oct 26 10:29:06 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 10:29:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRh9m-0001Hu-VM; Fri, 26 Oct 2012 10:28:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRh9k-0001HY-Np; Fri, 26 Oct 2012 10:28:49 +0000
Received: from [85.158.143.35:31572] by server-1.bemta-4.messagelabs.com id
	7C/3D-19134-0E56A805; Fri, 26 Oct 2012 10:28:48 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1351247297!11786649!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_8,RCVD_BY_IP,spamassassin: ,async_handler: 
	YXN5bmNfZGVsYXk6IDcwNjI5MTkgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17129 invoked from network); 26 Oct 2012 10:28:18 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 10:28:18 -0000
Received: by mail-bk0-f45.google.com with SMTP id jf3so1195636bkc.32
	for ; Fri, 26 Oct 2012 03:28:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:cc
	:subject:references:in-reply-to:content-type;
	bh=0kq4GRZ+4j33xG6w1K5ISb2rqhN+XOarlyjjvSPQZEY=;
	b=fAV+OAf72eQbXUvbGzynrvHm5H7cdJLwH1PJuuOgly9QeTgIGxgoqrB2Fs8sRfEwFe
	ttiz52rYHzZWiwX81i+bznC6a3ikdVMM5hr4BmsWdEo5s+aKG3s7GG150dKhNHCO17pH
	FDVwcfhjlsqCfTq2AU5JV7gQzwieUvtE0+Uhvmlq+lhqG+Un69P7ASQ9WXe+E4KEe5ms
	OAe+5azrutVEF8DQNACAACS9265vvaHKnl6V02dX2B/X8NyhztWjcIuVeTX6TQWyFMoJ
	cPspxKx9yX7X+BvUA5InVEQfC5axztWmtiyUJNah8jiW7yjvEbQxfwXP8kNoB2Z4AXQh
	UX2w==
Received: by 10.204.11.70 with SMTP id s6mr7159920bks.63.1351247297500;
	Fri, 26 Oct 2012 03:28:17 -0700 (PDT)
Received: from [172.16.26.11] (b0fb5ab2.bb.sky.com. [176.251.90.178])
	by mx.google.com with ESMTPS id x13sm605119bkv.16.2012.10.26.03.28.16
	(version=SSLv3 cipher=OTHER); Fri, 26 Oct 2012 03:28:16 -0700 (PDT)
Message-ID: <508A65BF.5040807@xen.org>
Date: Fri, 26 Oct 2012 11:28:15 +0100
From: Lars Kurth 
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
References: 
	<508A652A.7050002@xen.org>
In-Reply-To: <508A652A.7050002@xen.org>
Cc: xci-devel@lists.xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] XCI Archivation Review (VOTE)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: lars.kurth@xen.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============2376557697284371667=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============2376557697284371667==
Content-Type: multipart/alternative;
 boundary="------------070703040306090909000703"

This is a multi-part message in MIME format.
--------------070703040306090909000703
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

And I just realized that I sent the wrong voting link: it should be
https://docs.google.com/spreadsheet/viewform?formkey=dG9pRTkxbTJkTC1weExuWmVTS0tHdHc6MA#gid=0

Sorry

Lars

On 26/10/2012 11:25, Lars Kurth wrote:
> If you do not want to use Google Docs, please reply privately
> +1 (for Archivation)
> 0 (Abstain)
> -1 (against archivation)
>
> Lars
>
> On 26/10/2012 10:28, Lars Kurth wrote:
>> Hi everybody,
>>
>> it's been on my list of things to do for a while, to formally close 
>> and archive the XCI project. The reason for archiving the project is:
>>
>>   * There is no Project Lead
>>   * The last try to revive the project in April/May did not lead anywhere
>>   * No activity in any of the repos for a year
>>   * No activity on XCI related wiki pages for a year
>>   * No activity on the mailing list for a year
>>
>> What happens after the review?
>>
>>   * The mailing list is archived (i.e. it is moved to the archived
>>     section) and closed for new posts
>>   * The wiki pages are archived
>>   * The web pages are moved into the xen.org  archive
>>   * We will archive the repos
>>
>> What needs to happen formally vote on an archivation review?
>>
>> *Reviews:* These are off-line reviews which are open to all community 
>> members by which a proposal is published for review
>> [This is this e-mail, done]
>>
>> *Voting:* The community manager arranges a timed private vote as 
>> outlined above (voting should be open for a minimum of a week). Any 
>> maintainer of a mature project and the Xen.org community manager is 
>> allowed to vote. Voting follows the conventions as laid out in 
>> "Principle: Consensus Decision Making".
>>
>> The link to vote privately is here: 
>> https://docs.google.com/spreadsheet/ccc?key=0Ao04FrB3gtj2dG9pRTkxbTJkTC1weExuWmVTS0tHdHc#gid=0
>> The vote will be open for two weeks until Nov 9th 2012.
>>
>> Best Regards
>> Lars
>


--------------070703040306090909000703
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
And I just realized that I sent the
      wrong voting link: it should be 

https://docs.google.com/spreadsheet/viewform?formkey=dG9pRTkxbTJkTC1weExuWmVTS0tHdHc6MA#gid=0

      

      Sorry

      

      Lars

      

      On 26/10/2012 11:25, Lars Kurth wrote:

    

    

      
      
If you do not want to use Google
        Docs, please reply privately

        +1 (for Archivation)

        0 (Abstain)

        -1 (against archivation)

        

        Lars

         

        On 26/10/2012 10:28, Lars Kurth wrote:

      

      
Hi everybody,

        

        it's been on my list of things to do for a while, to formally
        close and archive the XCI project. The reason for archiving the
        project is:

        
    
          
  • There is no Project Lead
    • 
          
  • The last try to revive the project in April/May did not
            lead anywhere
    
          
    • 
          
  • No activity in any of the repos for a year
    • 
          
  • No activity on XCI related wiki pages for a year
    • 
          
  • No activity on the mailing list for a year
    • 
        

        What happens after the review?

        
    
          
  • The mailing list is archived (i.e. it is moved to the
            archived section) and closed for new posts
    • 
          
  • The wiki pages are archived
    • 
          
  • The web pages are moved into the xen.org
            archive
    • 
          
  • We will archive the repos
    
          
    • 
        

        What needs to happen formally vote on an archivation review?

        

        Reviews: These are off-line reviews which are open to all
        community members by which a proposal is published for review

        [This is this e-mail, done]

        

        Voting: The community manager arranges a timed private
        vote as outlined above (voting should be open for a minimum of a
        week). Any maintainer of a mature project and the Xen.org
        community manager is allowed to vote. Voting follows the
        conventions as laid out in "Principle: Consensus Decision
        Making".

        

        The link to vote privately is here: https://docs.google.com/spreadsheet/ccc?key=0Ao04FrB3gtj2dG9pRTkxbTJkTC1weExuWmVTS0tHdHc#gid=0

        The vote will be open for two weeks until Nov 9th 2012.

        

        Best Regards

        Lars

      

      

    

    

  


--------------070703040306090909000703--


--===============2376557697284371667==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2376557697284371667==--


From xen-devel-bounces@lists.xen.org Fri Oct 26 11:02:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 11:02:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRhft-0001fJ-Un; Fri, 26 Oct 2012 11:02:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRhfr-0001f2-T8; Fri, 26 Oct 2012 11:02:00 +0000
Received: from [85.158.139.83:61094] by server-4.bemta-5.messagelabs.com id
	3D/F1-01455-6AD6A805; Fri, 26 Oct 2012 11:01:58 +0000
X-Env-Sender: iwj@xenbits.xen.org
X-Msg-Ref: server-3.tower-182.messagelabs.com!1351249316!27438188!1
X-Originating-IP: [50.57.168.107]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22601 invoked from network); 26 Oct 2012 11:01:57 -0000
Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107)
	by server-3.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Oct 2012 11:01:57 -0000
Received: from xenbits.xen.org ([50.57.170.242])
	by mail.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRhfg-0003oA-7z; Fri, 26 Oct 2012 11:01:48 +0000
Received: from iwj by xenbits.xen.org with local (Exim 4.72)
	(envelope-from )
	id 1TRhff-0004iR-Vi; Fri, 26 Oct 2012 11:01:48 +0000
Date: Fri, 26 Oct 2012 11:01:47 +0000
Message-Id: 
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
	xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team 
Cc: "Xen.org security team" 
Subject: [Xen-devel] Xen Security Advisory 25 (CVE-2012-4544) - Xen domain
 builder Out-of-memory due to malicious kernel/ramdisk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

	     Xen Security Advisory CVE-2012-4544 / XSA-25

   Xen domain builder Out-of-memory due to malicious kernel/ramdisk

ISSUE DESCRIPTION
=================

The Xen PV domain builder contained no validation of the size of the
supplied kernel or ramdisk either before or after decompression. This
could cause the toolstack to consume all available RAM in the domain
running the domain builder.

IMPACT
======

A malicious guest administrator who can supply a kernel or ramdisk can
exhaust memory in domain 0 leading to a denial of service attack.

VULNERABLE SYSTEMS
==================

All versions of Xen are vulnerable.

MITIGATION
==========

Running only trusted kernels and ramdisks will avoid this
vulnerability.

Using pvgrub also avoids this vulnerability since the builder will run
in guest context. (nb: use of pygrub *is* vulnerable).

Running only HVM guests will avoid this vulnerability.

RELATED ISSUE
=============

CVE-2012-2625 covers a bug in pygrub which caused that process to
consume excessive amount of memory under similar circumstances to the
above.

This was fixed in xen-unstable (and the fix inherited by Xen 4.2.x) in
revision 25589:60f09d1ab1fe but not called out as a security problem.
This fix is also included, where relevant, in the patches below.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue, including
the related pygrub fix where neccesary.

xsa25-unstable.patch        Xen unstable
xsa25-4.2.patch             Xen 4.2.x
xsa25-4.1.patch             Xen 4.1.x

$ sha256sum xsa25*.patch
613e4b82cdc9cabf9cbd52076118887b298c47e680c2066a28a77f12e9f90606  xsa25-4.1.patch
135bc089d003f9b97991764c37b1ab8d37e9cbcfa1b9bd7429b4503abe00c8f5  xsa25-4.2.patch
534495b7eef6e599f5814f0a67fc84fbe2e8eee9d223a09ad178ff63bdcda3dd  xsa25-unstable.patch

Note that these patches impose a new size limit of 1Gby on both the
compressed and uncompressed sizes of ramdisks.  On some systems it may
be desirable to relax these limits and risk virtual address or memory
exhaustion in the toolstack.  This can be achieved by setting
XC_DOM_DECOMPRESS_MAX to the desired limit (in bytes). This can be
done by building with "APPEND_CFLAGS=-DXC_DOM_DECOMPRESS_MAX="
or by editing tools/libxc/xc_dom.h directly.

NOTE REGARDING LACK OF EMBARGO
==============================

These issues have already been discussed in public in various places,
including https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-2625
and http://bugs.debian.org/688125.  This advisory is therefore not
subject to an embargo.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJQim1nAAoJEIP+FMlX6CvZgw0IAKTyGbRlt5N2i8YbRdAj0+wF
OA4X5G1GlAEf0iGVjYi92/HnVyjWxLSNCKJK4YSWAUrlnkAC2IEUU6vqQOkxN/ic
88D1VS8tEtQwRGa9jNxf4RTCLvdGxrVK4lnSDu7OplgwMDT7O/X+Dq89xKN2VCYw
/iqpzlAndmC0Lqz0U8VlV71JryS5uwg980GWimQaIEinyOWFS5cuImvBamptl+zU
aoU3JxERd3YWASrspm8dBOtwc75DucWY1hOjz52uloodKcJha55Objcm8dn76xwN
JV7sHGFRrQyxHnQJ9GeSuV0RHkxB6VhMXTGWKFaynOLjtUUoidkawgs1ld+Qsms=
=Vj6Q
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa25-4.1.patch"
Content-Disposition: attachment; filename="xsa25-4.1.patch"
Content-Transfer-Encoding: base64

bGlieGM6IGJ1aWxkZXI6IGxpbWl0IG1heGltdW0gc2l6ZSBvZiBrZXJuZWwv
cmFtZGlzay4KCkFsbG93aW5nIHVzZXIgc3VwcGxpZWQga2VybmVscyBvZiBh
cmJpdHJhcnkgc2l6ZXMsIGVzcGVjaWFsbHkgZHVyaW5nCmRlY29tcHJlc3Np
b24sIGNhbiBzd2FsbG93IHVwIGRvbTAgbWVtb3J5IGxlYWRpbmcgdG8gZWl0
aGVyIHZpcnR1YWwKYWRkcmVzcyBzcGFjZSBleGhhdXN0aW9uIGluIHRoZSBi
dWlsZGVyIHByb2Nlc3Mgb3IgYWxsb2NhdGlvbgpmYWlsdXJlcy9PT00ga2ls
bGluZyBvZiBib3RoIHRvb2xzdGFjayBhbmQgdW5yZWxhdGVkIHByb2Nlc3Nl
cy4KCldlIGRpc2FibGUgdGhlc2UgY2hlY2tzIHdoZW4gYnVpbGRpbmcgaW4g
YSBzdHViIGRvbWFpbiBmb3IgcHZncnViCnNpbmNlIHRoaXMgdXNlcyB0aGUg
Z3Vlc3QncyBvd24gbWVtb3J5IGFuZCBpcyBpc29sYXRlZC4KCkRlY29tcHJl
c3Npb24gb2YgZ3ppcCBjb21wcmVzc2VkIGtlcm5lbHMgYW5kIHJhbWRpc2tz
IGhhcyBiZWVuIHNhZmUKc2luY2UgMTQ5NTQ6NTgyMDUyNTc1MTdkIChYZW4g
My4xLjAgb253YXJkcykuCgpUaGlzIGlzIFhTQS0yNSAvIENWRS0yMDEyLTQ1
NDQuCgpBbHNvIG1ha2UgZXhwbGljaXQgY2hlY2tzIGZvciBidWZmZXIgb3Zl
cmZsb3dzIGluIHZhcmlvdXMKZGVjb21wcmVzc2lvbiByb3V0aW5lcy4gVGhl
c2Ugd2VyZSBhbHJlYWR5IHJ1bGVkIG91dCBkdWUgdG8gb3RoZXIKcHJvcGVy
dGllcyBvZiB0aGUgY29kZSBidXQgY2hlY2sgdGhlbSBhcyBhIGJlbHQtYW5k
LWJyYWNlcyBtZWFzdXJlLgoKU2lnbmVkLW9mZi1ieTogSWFuIENhbXBiZWxs
IDxpYW4uY2FtcGJlbGxAY2l0cml4LmNvbT4KQWNrZWQtYnk6IElhbiBKYWNr
c29uIDxpYW4uamFja3NvbkBldS5jaXRyaXguY29tPgpbIEluY2x1ZGVzIDI1
NTg5OjYwZjA5ZDFhYjFmZSBmb3IgQ1ZFLTIwMTItMjYyNSBdCgpkaWZmIC0t
Z2l0IGEvc3R1YmRvbS9ncnViL2tleGVjLmMgYi9zdHViZG9tL2dydWIva2V4
ZWMuYwppbmRleCAwNmJlZjUyLi5iMjFjOTFhIDEwMDY0NAotLS0gYS9zdHVi
ZG9tL2dydWIva2V4ZWMuYworKysgYi9zdHViZG9tL2dydWIva2V4ZWMuYwpA
QCAtMTM3LDYgKzEzNywxMCBAQCB2b2lkIGtleGVjKHZvaWQgKmtlcm5lbCwg
bG9uZyBrZXJuZWxfc2l6ZSwgdm9pZCAqbW9kdWxlLCBsb25nIG1vZHVsZV9z
aXplLCBjaGFyCiAgICAgZG9tID0geGNfZG9tX2FsbG9jYXRlKHhjX2hhbmRs
ZSwgY21kbGluZSwgZmVhdHVyZXMpOwogICAgIGRvbS0+YWxsb2NhdGUgPSBr
ZXhlY19hbGxvY2F0ZTsKIAorICAgIC8qIFdlIGFyZSB1c2luZyBndWVzdCBv
d25lZCBtZW1vcnksIHRoZXJlZm9yZSBubyBsaW1pdHMuICovCisgICAgeGNf
ZG9tX2tlcm5lbF9tYXhfc2l6ZShkb20sIDApOworICAgIHhjX2RvbV9yYW1k
aXNrX21heF9zaXplKGRvbSwgMCk7CisKICAgICBkb20tPmtlcm5lbF9ibG9i
ID0ga2VybmVsOwogICAgIGRvbS0+a2VybmVsX3NpemUgPSBrZXJuZWxfc2l6
ZTsKIApkaWZmIC0tZ2l0IGEvdG9vbHMvbGlieGMveGNfZG9tLmggYi90b29s
cy9saWJ4Yy94Y19kb20uaAppbmRleCBlNzJmMDY2Li43MDQzZjk2IDEwMDY0
NAotLS0gYS90b29scy9saWJ4Yy94Y19kb20uaAorKysgYi90b29scy9saWJ4
Yy94Y19kb20uaApAQCAtNTIsNiArNTIsOSBAQCBzdHJ1Y3QgeGNfZG9tX2lt
YWdlIHsKICAgICB2b2lkICpyYW1kaXNrX2Jsb2I7CiAgICAgc2l6ZV90IHJh
bWRpc2tfc2l6ZTsKIAorICAgIHNpemVfdCBtYXhfa2VybmVsX3NpemU7Cisg
ICAgc2l6ZV90IG1heF9yYW1kaXNrX3NpemU7CisKICAgICAvKiBhcmd1bWVu
dHMgYW5kIHBhcmFtZXRlcnMgKi8KICAgICBjaGFyICpjbWRsaW5lOwogICAg
IHVpbnQzMl90IGZfcmVxdWVzdGVkW1hFTkZFQVRfTlJfU1VCTUFQU107CkBA
IC0xNzUsNiArMTc4LDIzIEBAIHZvaWQgeGNfZG9tX3JlbGVhc2VfcGh5cyhz
dHJ1Y3QgeGNfZG9tX2ltYWdlICpkb20pOwogdm9pZCB4Y19kb21fcmVsZWFz
ZShzdHJ1Y3QgeGNfZG9tX2ltYWdlICpkb20pOwogaW50IHhjX2RvbV9tZW1f
aW5pdChzdHJ1Y3QgeGNfZG9tX2ltYWdlICpkb20sIHVuc2lnbmVkIGludCBt
ZW1fbWIpOwogCisvKiBTZXQgdGhpcyBsYXJnZXIgaWYgeW91IGhhdmUgZW5v
cm1vdXMgcmFtZGlza3Mva2VybmVscy4gTm90ZSB0aGF0CisgKiB5b3Ugc2hv
dWxkIHRydXN0IGFsbCBrZXJuZWxzIG5vdCB0byBiZSBtYWxpY2lvdXNseSBs
YXJnZSAoZS5nLiB0bworICogZXhoYXVzdCBhbGwgZG9tMCBtZW1vcnkpIGlm
IHlvdSBkbyB0aGlzIChzZWUgQ1ZFLTIwMTItNDU0NCAvCisgKiBYU0EtMjUp
LiBZb3UgY2FuIGFsc28gc2V0IHRoZSBkZWZhdWx0IGluZGVwZW5kZW50bHkg
Zm9yCisgKiByYW1kaXNrcy9rZXJuZWxzIGluIHhjX2RvbV9hbGxvY2F0ZSgp
IG9yIGNhbGwKKyAqIHhjX2RvbV97a2VybmVsLHJhbWRpc2t9X21heF9zaXpl
LgorICovCisjaWZuZGVmIFhDX0RPTV9ERUNPTVBSRVNTX01BWAorI2RlZmlu
ZSBYQ19ET01fREVDT01QUkVTU19NQVggKDEwMjQqMTAyNCoxMDI0KSAvKiAx
R0IgKi8KKyNlbmRpZgorCitpbnQgeGNfZG9tX2tlcm5lbF9jaGVja19zaXpl
KHN0cnVjdCB4Y19kb21faW1hZ2UgKmRvbSwgc2l6ZV90IHN6KTsKK2ludCB4
Y19kb21fa2VybmVsX21heF9zaXplKHN0cnVjdCB4Y19kb21faW1hZ2UgKmRv
bSwgc2l6ZV90IHN6KTsKKworaW50IHhjX2RvbV9yYW1kaXNrX2NoZWNrX3Np
emUoc3RydWN0IHhjX2RvbV9pbWFnZSAqZG9tLCBzaXplX3Qgc3opOworaW50
IHhjX2RvbV9yYW1kaXNrX21heF9zaXplKHN0cnVjdCB4Y19kb21faW1hZ2Ug
KmRvbSwgc2l6ZV90IHN6KTsKKwogc2l6ZV90IHhjX2RvbV9jaGVja19nemlw
KHhjX2ludGVyZmFjZSAqeGNoLAogICAgICAgICAgICAgICAgICAgICAgdm9p
ZCAqYmxvYiwgc2l6ZV90IHppcGxlbik7CiBpbnQgeGNfZG9tX2RvX2d1bnpp
cCh4Y19pbnRlcmZhY2UgKnhjaCwKQEAgLTIyNCw3ICsyNDQsOCBAQCB2b2lk
IHhjX2RvbV9sb2dfbWVtb3J5X2Zvb3RwcmludChzdHJ1Y3QgeGNfZG9tX2lt
YWdlICpkb20pOwogdm9pZCAqeGNfZG9tX21hbGxvYyhzdHJ1Y3QgeGNfZG9t
X2ltYWdlICpkb20sIHNpemVfdCBzaXplKTsKIHZvaWQgKnhjX2RvbV9tYWxs
b2NfcGFnZV9hbGlnbmVkKHN0cnVjdCB4Y19kb21faW1hZ2UgKmRvbSwgc2l6
ZV90IHNpemUpOwogdm9pZCAqeGNfZG9tX21hbGxvY19maWxlbWFwKHN0cnVj
dCB4Y19kb21faW1hZ2UgKmRvbSwKLSAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBjb25zdCBjaGFyICpmaWxlbmFtZSwgc2l6ZV90ICogc2l6ZSk7Cisg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgY2hhciAqZmlsZW5h
bWUsIHNpemVfdCAqIHNpemUsCisgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgY29uc3Qgc2l6ZV90IG1heF9zaXplKTsKIGNoYXIgKnhjX2RvbV9zdHJk
dXAoc3RydWN0IHhjX2RvbV9pbWFnZSAqZG9tLCBjb25zdCBjaGFyICpzdHIp
OwogCiAvKiAtLS0gYWxsb2MgbWVtb3J5IHBvb2wgLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAqLwpkaWZmIC0tZ2l0IGEv
dG9vbHMvbGlieGMveGNfZG9tX2J6aW1hZ2Vsb2FkZXIuYyBiL3Rvb2xzL2xp
YnhjL3hjX2RvbV9iemltYWdlbG9hZGVyLmMKaW5kZXggOTg1MmU2Ny4uNzNj
ZmFkMSAxMDA2NDQKLS0tIGEvdG9vbHMvbGlieGMveGNfZG9tX2J6aW1hZ2Vs
b2FkZXIuYworKysgYi90b29scy9saWJ4Yy94Y19kb21fYnppbWFnZWxvYWRl
ci5jCkBAIC00NywxMyArNDcsMTkgQEAgc3RhdGljIGludCB4Y190cnlfYnpp
cDJfZGVjb2RlKAogICAgIGNoYXIgKm91dF9idWY7CiAgICAgY2hhciAqdG1w
X2J1ZjsKICAgICBpbnQgcmV0dmFsID0gLTE7Ci0gICAgaW50IG91dHNpemU7
CisgICAgdW5zaWduZWQgaW50IG91dHNpemU7CiAgICAgdWludDY0X3QgdG90
YWw7CiAKICAgICBzdHJlYW0uYnphbGxvYyA9IE5VTEw7CiAgICAgc3RyZWFt
LmJ6ZnJlZSA9IE5VTEw7CiAgICAgc3RyZWFtLm9wYXF1ZSA9IE5VTEw7CiAK
KyAgICBpZiAoIGRvbS0+a2VybmVsX3NpemUgPT0gMCkKKyAgICB7CisgICAg
ICAgIERPTVBSSU5URigiQlpJUDI6IElucHV0IGlzIDAgc2l6ZSIpOworICAg
ICAgICByZXR1cm4gLTE7CisgICAgfQorCiAgICAgcmV0ID0gQloyX2J6RGVj
b21wcmVzc0luaXQoJnN0cmVhbSwgMCwgMCk7CiAgICAgaWYgKCByZXQgIT0g
QlpfT0sgKQogICAgIHsKQEAgLTY2LDYgKzcyLDE3IEBAIHN0YXRpYyBpbnQg
eGNfdHJ5X2J6aXAyX2RlY29kZSgKICAgICAgKiB0aGUgaW5wdXQgYnVmZmVy
IHRvIHN0YXJ0LCBhbmQgd2UnbGwgcmVhbGxvYyBhcyBuZWVkZWQuCiAgICAg
ICovCiAgICAgb3V0c2l6ZSA9IGRvbS0+a2VybmVsX3NpemU7CisKKyAgICAv
KgorICAgICAqIHN0cmVhbS5hdmFpbF9pbiBhbmQgb3V0c2l6ZSBhcmUgdW5z
aWduZWQgaW50LCB3aGlsZSBrZXJuZWxfc2l6ZQorICAgICAqIGlzIGEgc2l6
ZV90LiBDaGVjayB3ZSBhcmVuJ3Qgb3ZlcmZsb3dpbmcuCisgICAgICovCisg
ICAgaWYgKCBvdXRzaXplICE9IGRvbS0+a2VybmVsX3NpemUgKQorICAgIHsK
KyAgICAgICAgRE9NUFJJTlRGKCJCWklQMjogSW5wdXQgdG9vIGxhcmdlIik7
CisgICAgICAgIGdvdG8gYnppcDJfY2xlYW51cDsKKyAgICB9CisKICAgICBv
dXRfYnVmID0gbWFsbG9jKG91dHNpemUpOwogICAgIGlmICggb3V0X2J1ZiA9
PSBOVUxMICkKICAgICB7CkBAIC05OCwxMyArMTE1LDIwIEBAIHN0YXRpYyBp
bnQgeGNfdHJ5X2J6aXAyX2RlY29kZSgKICAgICAgICAgaWYgKCBzdHJlYW0u
YXZhaWxfb3V0ID09IDAgKQogICAgICAgICB7CiAgICAgICAgICAgICAvKiBQ
cm90ZWN0IGFnYWluc3Qgb3V0cHV0IGJ1ZmZlciBvdmVyZmxvdyAqLwotICAg
ICAgICAgICAgaWYgKCBvdXRzaXplID4gSU5UX01BWCAvIDIgKQorICAgICAg
ICAgICAgaWYgKCBvdXRzaXplID4gVUlOVF9NQVggLyAyICkKICAgICAgICAg
ICAgIHsKICAgICAgICAgICAgICAgICBET01QUklOVEYoIkJaSVAyOiBvdXRw
dXQgYnVmZmVyIG92ZXJmbG93Iik7CiAgICAgICAgICAgICAgICAgZnJlZShv
dXRfYnVmKTsKICAgICAgICAgICAgICAgICBnb3RvIGJ6aXAyX2NsZWFudXA7
CiAgICAgICAgICAgICB9CiAKKyAgICAgICAgICAgIGlmICggeGNfZG9tX2tl
cm5lbF9jaGVja19zaXplKGRvbSwgb3V0c2l6ZSAqIDIpICkKKyAgICAgICAg
ICAgIHsKKyAgICAgICAgICAgICAgICBET01QUklOVEYoIkJaSVAyOiBvdXRw
dXQgdG9vIGxhcmdlIik7CisgICAgICAgICAgICAgICAgZnJlZShvdXRfYnVm
KTsKKyAgICAgICAgICAgICAgICBnb3RvIGJ6aXAyX2NsZWFudXA7CisgICAg
ICAgICAgICB9CisKICAgICAgICAgICAgIHRtcF9idWYgPSByZWFsbG9jKG91
dF9idWYsIG91dHNpemUgKiAyKTsKICAgICAgICAgICAgIGlmICggdG1wX2J1
ZiA9PSBOVUxMICkKICAgICAgICAgICAgIHsKQEAgLTE3Miw5ICsxOTYsMTUg
QEAgc3RhdGljIGludCB4Y190cnlfbHptYV9kZWNvZGUoCiAgICAgdW5zaWdu
ZWQgY2hhciAqb3V0X2J1ZjsKICAgICB1bnNpZ25lZCBjaGFyICp0bXBfYnVm
OwogICAgIGludCByZXR2YWwgPSAtMTsKLSAgICBpbnQgb3V0c2l6ZTsKKyAg
ICBzaXplX3Qgb3V0c2l6ZTsKICAgICBjb25zdCBjaGFyICptc2c7CiAKKyAg
ICBpZiAoIGRvbS0+a2VybmVsX3NpemUgPT0gMCkKKyAgICB7CisgICAgICAg
IERPTVBSSU5URigiTFpNQTogSW5wdXQgaXMgMCBzaXplIik7CisgICAgICAg
IHJldHVybiAtMTsKKyAgICB9CisKICAgICByZXQgPSBsem1hX2Fsb25lX2Rl
Y29kZXIoJnN0cmVhbSwgMTI4KjEwMjQqMTAyNCk7CiAgICAgaWYgKCByZXQg
IT0gTFpNQV9PSyApCiAgICAgewpAQCAtMjUxLDEzICsyODEsMjAgQEAgc3Rh
dGljIGludCB4Y190cnlfbHptYV9kZWNvZGUoCiAgICAgICAgIGlmICggc3Ry
ZWFtLmF2YWlsX291dCA9PSAwICkKICAgICAgICAgewogICAgICAgICAgICAg
LyogUHJvdGVjdCBhZ2FpbnN0IG91dHB1dCBidWZmZXIgb3ZlcmZsb3cgKi8K
LSAgICAgICAgICAgIGlmICggb3V0c2l6ZSA+IElOVF9NQVggLyAyICkKKyAg
ICAgICAgICAgIGlmICggb3V0c2l6ZSA+IFNJWkVfTUFYIC8gMiApCiAgICAg
ICAgICAgICB7CiAgICAgICAgICAgICAgICAgRE9NUFJJTlRGKCJMWk1BOiBv
dXRwdXQgYnVmZmVyIG92ZXJmbG93Iik7CiAgICAgICAgICAgICAgICAgZnJl
ZShvdXRfYnVmKTsKICAgICAgICAgICAgICAgICBnb3RvIGx6bWFfY2xlYW51
cDsKICAgICAgICAgICAgIH0KIAorICAgICAgICAgICAgaWYgKCB4Y19kb21f
a2VybmVsX2NoZWNrX3NpemUoZG9tLCBvdXRzaXplICogMikgKQorICAgICAg
ICAgICAgeworICAgICAgICAgICAgICAgIERPTVBSSU5URigiTFpNQTogb3V0
cHV0IHRvbyBsYXJnZSIpOworICAgICAgICAgICAgICAgIGZyZWUob3V0X2J1
Zik7CisgICAgICAgICAgICAgICAgZ290byBsem1hX2NsZWFudXA7CisgICAg
ICAgICAgICB9CisKICAgICAgICAgICAgIHRtcF9idWYgPSByZWFsbG9jKG91
dF9idWYsIG91dHNpemUgKiAyKTsKICAgICAgICAgICAgIGlmICggdG1wX2J1
ZiA9PSBOVUxMICkKICAgICAgICAgICAgIHsKQEAgLTMyNyw2ICszNjQsMTIg
QEAgc3RhdGljIGludCB4Y190cnlfbHpvMXhfZGVjb2RlKAogICAgICAgICAw
eDg5LCAweDRjLCAweDVhLCAweDRmLCAweDAwLCAweDBkLCAweDBhLCAweDFh
LCAweDBhCiAgICAgfTsKIAorICAgIC8qCisgICAgICogbHpvX3VpbnQgc2hv
dWxkIG1hdGNoIHNpemVfdC4gQ2hlY2sgdGhhdCB0aGlzIGlzIHRoZSBjYXNl
IHRvIGJlCisgICAgICogc3VyZSB3ZSB3b24ndCBvdmVyZmxvdyB2YXJpb3Vz
IGx6b191aW50IGZpZWxkcy4KKyAgICAgKi8KKyAgICBYQ19CVUlMRF9CVUdf
T04oc2l6ZW9mKGx6b191aW50KSAhPSBzaXplb2Yoc2l6ZV90KSk7CisKICAg
ICByZXQgPSBsem9faW5pdCgpOwogICAgIGlmICggcmV0ICE9IExaT19FX09L
ICkKICAgICB7CkBAIC00MDYsNiArNDQ5LDE0IEBAIHN0YXRpYyBpbnQgeGNf
dHJ5X2x6bzF4X2RlY29kZSgKICAgICAgICAgaWYgKCBzcmNfbGVuIDw9IDAg
fHwgc3JjX2xlbiA+IGRzdF9sZW4gfHwgc3JjX2xlbiA+IGxlZnQgKQogICAg
ICAgICAgICAgYnJlYWs7CiAKKyAgICAgICAgbXNnID0gIk91dHB1dCBidWZm
ZXIgb3ZlcmZsb3ciOworICAgICAgICBpZiAoICpzaXplID4gU0laRV9NQVgg
LSBkc3RfbGVuICkKKyAgICAgICAgICAgIGJyZWFrOworCisgICAgICAgIG1z
ZyA9ICJEZWNvbXByZXNzZWQgaW1hZ2UgdG9vIGxhcmdlIjsKKyAgICAgICAg
aWYgKCB4Y19kb21fa2VybmVsX2NoZWNrX3NpemUoZG9tLCAqc2l6ZSArIGRz
dF9sZW4pICkKKyAgICAgICAgICAgIGJyZWFrOworCiAgICAgICAgIG1zZyA9
ICJGYWlsZWQgdG8gKHJlKWFsbG9jIG1lbW9yeSI7CiAgICAgICAgIHRtcF9i
dWYgPSByZWFsbG9jKG91dF9idWYsICpzaXplICsgZHN0X2xlbik7CiAgICAg
ICAgIGlmICggdG1wX2J1ZiA9PSBOVUxMICkKZGlmZiAtLWdpdCBhL3Rvb2xz
L2xpYnhjL3hjX2RvbV9jb3JlLmMgYi90b29scy9saWJ4Yy94Y19kb21fY29y
ZS5jCmluZGV4IGZlYTlkZTUuLjJhMDFkN2MgMTAwNjQ0Ci0tLSBhL3Rvb2xz
L2xpYnhjL3hjX2RvbV9jb3JlLmMKKysrIGIvdG9vbHMvbGlieGMveGNfZG9t
X2NvcmUuYwpAQCAtMTU5LDcgKzE1OSw4IEBAIHZvaWQgKnhjX2RvbV9tYWxs
b2NfcGFnZV9hbGlnbmVkKHN0cnVjdCB4Y19kb21faW1hZ2UgKmRvbSwgc2l6
ZV90IHNpemUpCiB9CiAKIHZvaWQgKnhjX2RvbV9tYWxsb2NfZmlsZW1hcChz
dHJ1Y3QgeGNfZG9tX2ltYWdlICpkb20sCi0gICAgICAgICAgICAgICAgICAg
ICAgICAgICAgY29uc3QgY2hhciAqZmlsZW5hbWUsIHNpemVfdCAqIHNpemUp
CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgY2hhciAqZmls
ZW5hbWUsIHNpemVfdCAqIHNpemUsCisgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgY29uc3Qgc2l6ZV90IG1heF9zaXplKQogewogICAgIHN0cnVjdCB4
Y19kb21fbWVtICpibG9jayA9IE5VTEw7CiAgICAgaW50IGZkID0gLTE7CkBA
IC0xNzEsNiArMTcyLDEzIEBAIHZvaWQgKnhjX2RvbV9tYWxsb2NfZmlsZW1h
cChzdHJ1Y3QgeGNfZG9tX2ltYWdlICpkb20sCiAgICAgbHNlZWsoZmQsIDAs
IFNFRUtfU0VUKTsKICAgICAqc2l6ZSA9IGxzZWVrKGZkLCAwLCBTRUVLX0VO
RCk7CiAKKyAgICBpZiAoIG1heF9zaXplICYmICpzaXplID4gbWF4X3NpemUg
KQorICAgIHsKKyAgICAgICAgeGNfZG9tX3BhbmljKGRvbS0+eGNoLCBYQ19P
VVRfT0ZfTUVNT1JZLAorICAgICAgICAgICAgICAgICAgICAgInRyaWVkIHRv
IG1hcCBmaWxlIHdoaWNoIGlzIHRvbyBsYXJnZSIpOworICAgICAgICBnb3Rv
IGVycjsKKyAgICB9CisKICAgICBibG9jayA9IG1hbGxvYyhzaXplb2YoKmJs
b2NrKSk7CiAgICAgaWYgKCBibG9jayA9PSBOVUxMICkKICAgICAgICAgZ290
byBlcnI7CkBAIC0yMjIsNiArMjMwLDQwIEBAIGNoYXIgKnhjX2RvbV9zdHJk
dXAoc3RydWN0IHhjX2RvbV9pbWFnZSAqZG9tLCBjb25zdCBjaGFyICpzdHIp
CiB9CiAKIC8qIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAqLworLyog
ZGVjb21wcmVzc2lvbiBidWZmZXIgc2l6aW5nICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICovCitpbnQgeGNfZG9tX2tl
cm5lbF9jaGVja19zaXplKHN0cnVjdCB4Y19kb21faW1hZ2UgKmRvbSwgc2l6
ZV90IHN6KQoreworICAgIC8qIE5vIGxpbWl0ICovCisgICAgaWYgKCAhZG9t
LT5tYXhfa2VybmVsX3NpemUgKQorICAgICAgICByZXR1cm4gMDsKKworICAg
IGlmICggc3ogPiBkb20tPm1heF9rZXJuZWxfc2l6ZSApCisgICAgeworICAg
ICAgICB4Y19kb21fcGFuaWMoZG9tLT54Y2gsIFhDX0lOVkFMSURfS0VSTkVM
LAorICAgICAgICAgICAgICAgICAgICAgImtlcm5lbCBpbWFnZSB0b28gbGFy
Z2UiKTsKKyAgICAgICAgcmV0dXJuIDE7CisgICAgfQorCisgICAgcmV0dXJu
IDA7Cit9CisKK2ludCB4Y19kb21fcmFtZGlza19jaGVja19zaXplKHN0cnVj
dCB4Y19kb21faW1hZ2UgKmRvbSwgc2l6ZV90IHN6KQoreworICAgIC8qIE5v
IGxpbWl0ICovCisgICAgaWYgKCAhZG9tLT5tYXhfcmFtZGlza19zaXplICkK
KyAgICAgICAgcmV0dXJuIDA7CisKKyAgICBpZiAoIHN6ID4gZG9tLT5tYXhf
cmFtZGlza19zaXplICkKKyAgICB7CisgICAgICAgIHhjX2RvbV9wYW5pYyhk
b20tPnhjaCwgWENfSU5WQUxJRF9LRVJORUwsCisgICAgICAgICAgICAgICAg
ICAgICAicmFtZGlzayBpbWFnZSB0b28gbGFyZ2UiKTsKKyAgICAgICAgcmV0
dXJuIDE7CisgICAgfQorCisgICAgcmV0dXJuIDA7Cit9CisKKy8qIC0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAqLwogLyogcmVhZCBmaWxlcywgY29w
eSBtZW1vcnkgYmxvY2tzLCB3aXRoIHRyYW5zcGFyZW50IGd1bnppcCAgICAg
ICAgICAgICAgICAgICovCiAKIHNpemVfdCB4Y19kb21fY2hlY2tfZ3ppcCh4
Y19pbnRlcmZhY2UgKnhjaCwgdm9pZCAqYmxvYiwgc2l6ZV90IHppcGxlbikK
QEAgLTIzNSw3ICsyNzcsNyBAQCBzaXplX3QgeGNfZG9tX2NoZWNrX2d6aXAo
eGNfaW50ZXJmYWNlICp4Y2gsIHZvaWQgKmJsb2IsIHNpemVfdCB6aXBsZW4p
CiAKICAgICBnemxlbiA9IGJsb2IgKyB6aXBsZW4gLSA0OwogICAgIHVuemlw
bGVuID0gZ3psZW5bM10gPDwgMjQgfCBnemxlblsyXSA8PCAxNiB8IGd6bGVu
WzFdIDw8IDggfCBnemxlblswXTsKLSAgICBpZiAoICh1bnppcGxlbiA8IDAp
IHx8ICh1bnppcGxlbiA+ICgxMDI0KjEwMjQqMTAyNCkpICkgLyogMUdCIGxp
bWl0ICovCisgICAgaWYgKCAodW56aXBsZW4gPCAwKSB8fCAodW56aXBsZW4g
PiBYQ19ET01fREVDT01QUkVTU19NQVgpICkKICAgICB7CiAgICAgICAgIHhj
X2RvbV9wcmludGYKICAgICAgICAgICAgICh4Y2gsCkBAIC0yODgsNiArMzMw
LDkgQEAgaW50IHhjX2RvbV90cnlfZ3VuemlwKHN0cnVjdCB4Y19kb21faW1h
Z2UgKmRvbSwgdm9pZCAqKmJsb2IsIHNpemVfdCAqIHNpemUpCiAgICAgaWYg
KCB1bnppcGxlbiA9PSAwICkKICAgICAgICAgcmV0dXJuIDA7CiAKKyAgICBp
ZiAoIHhjX2RvbV9rZXJuZWxfY2hlY2tfc2l6ZShkb20sIHVuemlwbGVuKSAp
CisgICAgICAgIHJldHVybiAwOworCiAgICAgdW56aXAgPSB4Y19kb21fbWFs
bG9jKGRvbSwgdW56aXBsZW4pOwogICAgIGlmICggdW56aXAgPT0gTlVMTCAp
CiAgICAgICAgIHJldHVybiAtMTsKQEAgLTU4OCw2ICs2MzMsOSBAQCBzdHJ1
Y3QgeGNfZG9tX2ltYWdlICp4Y19kb21fYWxsb2NhdGUoeGNfaW50ZXJmYWNl
ICp4Y2gsCiAgICAgbWVtc2V0KGRvbSwgMCwgc2l6ZW9mKCpkb20pKTsKICAg
ICBkb20tPnhjaCA9IHhjaDsKIAorICAgIGRvbS0+bWF4X2tlcm5lbF9zaXpl
ID0gWENfRE9NX0RFQ09NUFJFU1NfTUFYOworICAgIGRvbS0+bWF4X3JhbWRp
c2tfc2l6ZSA9IFhDX0RPTV9ERUNPTVBSRVNTX01BWDsKKwogICAgIGlmICgg
Y21kbGluZSApCiAgICAgICAgIGRvbS0+Y21kbGluZSA9IHhjX2RvbV9zdHJk
dXAoZG9tLCBjbWRsaW5lKTsKICAgICBpZiAoIGZlYXR1cmVzICkKQEAgLTYw
OCwxMCArNjU2LDI1IEBAIHN0cnVjdCB4Y19kb21faW1hZ2UgKnhjX2RvbV9h
bGxvY2F0ZSh4Y19pbnRlcmZhY2UgKnhjaCwKICAgICByZXR1cm4gTlVMTDsK
IH0KIAoraW50IHhjX2RvbV9rZXJuZWxfbWF4X3NpemUoc3RydWN0IHhjX2Rv
bV9pbWFnZSAqZG9tLCBzaXplX3Qgc3opCit7CisgICAgRE9NUFJJTlRGKCIl
czoga2VybmVsX21heF9zaXplPSV6eCIsIF9fRlVOQ1RJT05fXywgc3opOwor
ICAgIGRvbS0+bWF4X2tlcm5lbF9zaXplID0gc3o7CisgICAgcmV0dXJuIDA7
Cit9CisKK2ludCB4Y19kb21fcmFtZGlza19tYXhfc2l6ZShzdHJ1Y3QgeGNf
ZG9tX2ltYWdlICpkb20sIHNpemVfdCBzeikKK3sKKyAgICBET01QUklOVEYo
IiVzOiByYW1kaXNrX21heF9zaXplPSV6eCIsIF9fRlVOQ1RJT05fXywgc3op
OworICAgIGRvbS0+bWF4X3JhbWRpc2tfc2l6ZSA9IHN6OworICAgIHJldHVy
biAwOworfQorCiBpbnQgeGNfZG9tX2tlcm5lbF9maWxlKHN0cnVjdCB4Y19k
b21faW1hZ2UgKmRvbSwgY29uc3QgY2hhciAqZmlsZW5hbWUpCiB7CiAgICAg
RE9NUFJJTlRGKCIlczogZmlsZW5hbWU9XCIlc1wiIiwgX19GVU5DVElPTl9f
LCBmaWxlbmFtZSk7Ci0gICAgZG9tLT5rZXJuZWxfYmxvYiA9IHhjX2RvbV9t
YWxsb2NfZmlsZW1hcChkb20sIGZpbGVuYW1lLCAmZG9tLT5rZXJuZWxfc2l6
ZSk7CisgICAgZG9tLT5rZXJuZWxfYmxvYiA9IHhjX2RvbV9tYWxsb2NfZmls
ZW1hcChkb20sIGZpbGVuYW1lLCAmZG9tLT5rZXJuZWxfc2l6ZSwKKyAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRvbS0+
bWF4X2tlcm5lbF9zaXplKTsKICAgICBpZiAoIGRvbS0+a2VybmVsX2Jsb2Ig
PT0gTlVMTCApCiAgICAgICAgIHJldHVybiAtMTsKICAgICByZXR1cm4geGNf
ZG9tX3RyeV9ndW56aXAoZG9tLCAmZG9tLT5rZXJuZWxfYmxvYiwgJmRvbS0+
a2VybmVsX3NpemUpOwpAQCAtNjIxLDcgKzY4NCw5IEBAIGludCB4Y19kb21f
cmFtZGlza19maWxlKHN0cnVjdCB4Y19kb21faW1hZ2UgKmRvbSwgY29uc3Qg
Y2hhciAqZmlsZW5hbWUpCiB7CiAgICAgRE9NUFJJTlRGKCIlczogZmlsZW5h
bWU9XCIlc1wiIiwgX19GVU5DVElPTl9fLCBmaWxlbmFtZSk7CiAgICAgZG9t
LT5yYW1kaXNrX2Jsb2IgPQotICAgICAgICB4Y19kb21fbWFsbG9jX2ZpbGVt
YXAoZG9tLCBmaWxlbmFtZSwgJmRvbS0+cmFtZGlza19zaXplKTsKKyAgICAg
ICAgeGNfZG9tX21hbGxvY19maWxlbWFwKGRvbSwgZmlsZW5hbWUsICZkb20t
PnJhbWRpc2tfc2l6ZSwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IGRvbS0+bWF4X3JhbWRpc2tfc2l6ZSk7CisKICAgICBpZiAoIGRvbS0+cmFt
ZGlza19ibG9iID09IE5VTEwgKQogICAgICAgICByZXR1cm4gLTE7CiAvLyAg
ICByZXR1cm4geGNfZG9tX3RyeV9ndW56aXAoZG9tLCAmZG9tLT5yYW1kaXNr
X2Jsb2IsICZkb20tPnJhbWRpc2tfc2l6ZSk7CkBAIC03ODEsNyArODQ2LDEx
IEBAIGludCB4Y19kb21fYnVpbGRfaW1hZ2Uoc3RydWN0IHhjX2RvbV9pbWFn
ZSAqZG9tKQogICAgICAgICB2b2lkICpyYW1kaXNrbWFwOwogCiAgICAgICAg
IHVuemlwbGVuID0geGNfZG9tX2NoZWNrX2d6aXAoZG9tLT54Y2gsIGRvbS0+
cmFtZGlza19ibG9iLCBkb20tPnJhbWRpc2tfc2l6ZSk7CisgICAgICAgIGlm
ICggeGNfZG9tX3JhbWRpc2tfY2hlY2tfc2l6ZShkb20sIHVuemlwbGVuKSAh
PSAwICkKKyAgICAgICAgICAgIHVuemlwbGVuID0gMDsKKwogICAgICAgICBy
YW1kaXNrbGVuID0gdW56aXBsZW4gPyB1bnppcGxlbiA6IGRvbS0+cmFtZGlz
a19zaXplOworCiAgICAgICAgIGlmICggeGNfZG9tX2FsbG9jX3NlZ21lbnQo
ZG9tLCAmZG9tLT5yYW1kaXNrX3NlZywgInJhbWRpc2siLCAwLAogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJhbWRpc2tsZW4pICE9IDAg
KQogICAgICAgICAgICAgZ290byBlcnI7CmRpZmYgLS1naXQgYS90b29scy9w
eWdydWIvc3JjL3B5Z3J1YiBiL3Rvb2xzL3B5Z3J1Yi9zcmMvcHlncnViCmlu
ZGV4IDE3YzAwODMuLjFhM2MxYzMgMTAwNjQ0Ci0tLSBhL3Rvb2xzL3B5Z3J1
Yi9zcmMvcHlncnViCisrKyBiL3Rvb2xzL3B5Z3J1Yi9zcmMvcHlncnViCkBA
IC0yOCw2ICsyOCw3IEBAIGltcG9ydCBncnViLkxpbG9Db25mCiBpbXBvcnQg
Z3J1Yi5FeHRMaW51eENvbmYKIAogUFlHUlVCX1ZFUiA9IDAuNgorRlNfUkVB
RF9NQVggPSAxMDI0ICogMTAyNAogCiBkZWYgZW5hYmxlX2N1cnNvcihpc29u
KToKICAgICBpZiBpc29uOgpAQCAtNDIxLDcgKzQyMiw4IEBAIGNsYXNzIEdy
dWI6CiAgICAgICAgIGlmIHNlbGYuX19kaWN0X18uZ2V0KCdjZicsIE5vbmUp
IGlzIE5vbmU6CiAgICAgICAgICAgICByYWlzZSBSdW50aW1lRXJyb3IsICJj
b3VsZG4ndCBmaW5kIGJvb3Rsb2FkZXIgY29uZmlnIGZpbGUgaW4gdGhlIGlt
YWdlIHByb3ZpZGVkLiIKICAgICAgICAgZiA9IGZzLm9wZW5fZmlsZShzZWxm
LmNmLmZpbGVuYW1lKQotICAgICAgICBidWYgPSBmLnJlYWQoKQorICAgICAg
ICAjIGxpbWl0IHJlYWQgc2l6ZSB0byBhdm9pZCBwYXRob2xvZ2ljYWwgY2Fz
ZXMKKyAgICAgICAgYnVmID0gZi5yZWFkKEZTX1JFQURfTUFYKQogICAgICAg
ICBkZWwgZgogICAgICAgICBzZWxmLmNmLnBhcnNlKGJ1ZikKIApAQCAtNjcw
LDYgKzY3MiwzNyBAQCBpZiBfX25hbWVfXyA9PSAiX19tYWluX18iOgogICAg
IGRlZiB1c2FnZSgpOgogICAgICAgICBwcmludCA+PiBzeXMuc3RkZXJyLCAi
VXNhZ2U6ICVzIFstcXwtLXF1aWV0XSBbLWl8LS1pbnRlcmFjdGl2ZV0gWy1u
fC0tbm90LXJlYWxseV0gWy0tb3V0cHV0PV0gWy0ta2VybmVsPV0gWy0tcmFt
ZGlzaz1dIFstLWFyZ3M9XSBbLS1lbnRyeT1dIFstLW91dHB1dC1kaXJlY3Rv
cnk9XSBbLS1vdXRwdXQtZm9ybWF0PXN4cHxzaW1wbGV8c2ltcGxlMF0gPGlt
YWdlPiIgJShzeXMuYXJndlswXSwpCiAKKyAgICBkZWYgY29weV9mcm9tX2lt
YWdlKGZzLCBmaWxlX3RvX3JlYWQsIGZpbGVfdHlwZSwgb3V0cHV0X2RpcmVj
dG9yeSwKKyAgICAgICAgICAgICAgICAgICAgICAgIG5vdF9yZWFsbHkpOgor
ICAgICAgICBpZiBub3RfcmVhbGx5OgorICAgICAgICAgICAgaWYgZnMuZmls
ZV9leGlzdHMoZmlsZV90b19yZWFkKToKKyAgICAgICAgICAgICAgICByZXR1
cm4gIjwlczolcz4iICUgKGZpbGVfdHlwZSwgZmlsZV90b19yZWFkKQorICAg
ICAgICAgICAgZWxzZToKKyAgICAgICAgICAgICAgICBzeXMuZXhpdCgiVGhl
IHJlcXVlc3RlZCAlcyBmaWxlIGRvZXMgbm90IGV4aXN0IiAlIGZpbGVfdHlw
ZSkKKyAgICAgICAgdHJ5OgorICAgICAgICAgICAgZGF0YWZpbGUgPSBmcy5v
cGVuX2ZpbGUoZmlsZV90b19yZWFkKQorICAgICAgICBleGNlcHQgRXhjZXB0
aW9uLCBlOgorICAgICAgICAgICAgcHJpbnQgPj5zeXMuc3RkZXJyLCBlCisg
ICAgICAgICAgICBzeXMuZXhpdCgiRXJyb3Igb3BlbmluZyAlcyBpbiBndWVz
dCIgJSBmaWxlX3RvX3JlYWQpCisgICAgICAgICh0ZmQsIHJldCkgPSB0ZW1w
ZmlsZS5ta3N0ZW1wKHByZWZpeD0iYm9vdF8iK2ZpbGVfdHlwZSsiLiIsCisg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRpcj1vdXRw
dXRfZGlyZWN0b3J5KQorICAgICAgICBkYXRhb2ZmID0gMAorICAgICAgICB3
aGlsZSBUcnVlOgorICAgICAgICAgICAgZGF0YSA9IGRhdGFmaWxlLnJlYWQo
RlNfUkVBRF9NQVgsIGRhdGFvZmYpCisgICAgICAgICAgICBpZiBsZW4oZGF0
YSkgPT0gMDoKKyAgICAgICAgICAgICAgICBvcy5jbG9zZSh0ZmQpCisgICAg
ICAgICAgICAgICAgZGVsIGRhdGFmaWxlCisgICAgICAgICAgICAgICAgcmV0
dXJuIHJldAorICAgICAgICAgICAgdHJ5OgorICAgICAgICAgICAgICAgIG9z
LndyaXRlKHRmZCwgZGF0YSkKKyAgICAgICAgICAgIGV4Y2VwdCBFeGNlcHRp
b24sIGU6CisgICAgICAgICAgICAgICAgcHJpbnQgPj5zeXMuc3RkZXJyLCBl
CisgICAgICAgICAgICAgICAgb3MuY2xvc2UodGZkKQorICAgICAgICAgICAg
ICAgIG9zLnVubGluayhyZXQpCisgICAgICAgICAgICAgICAgZGVsIGRhdGFm
aWxlCisgICAgICAgICAgICAgICAgc3lzLmV4aXQoIkVycm9yIHdyaXRpbmcg
dGVtcG9yYXJ5IGNvcHkgb2YgIitmaWxlX3R5cGUpCisgICAgICAgICAgICBk
YXRhb2ZmICs9IGxlbihkYXRhKQorCiAgICAgdHJ5OgogICAgICAgICBvcHRz
LCBhcmdzID0gZ2V0b3B0LmdudV9nZXRvcHQoc3lzLmFyZ3ZbMTpdLCAncWlu
aDo6JywKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWyJx
dWlldCIsICJpbnRlcmFjdGl2ZSIsICJub3QtcmVhbGx5IiwgImhlbHAiLCAK
QEAgLTc4NiwyNCArODE5LDE4IEBAIGlmIF9fbmFtZV9fID09ICJfX21haW5f
XyI6CiAgICAgaWYgbm90IGZzOgogICAgICAgICByYWlzZSBSdW50aW1lRXJy
b3IsICJVbmFibGUgdG8gZmluZCBwYXJ0aXRpb24gY29udGFpbmluZyBrZXJu
ZWwiCiAKLSAgICBpZiBub3RfcmVhbGx5OgotICAgICAgICBib290Y2ZnWyJr
ZXJuZWwiXSA9ICI8a2VybmVsOiVzPiIgJSBjaG9zZW5jZmdbImtlcm5lbCJd
Ci0gICAgZWxzZToKLSAgICAgICAgZGF0YSA9IGZzLm9wZW5fZmlsZShjaG9z
ZW5jZmdbImtlcm5lbCJdKS5yZWFkKCkKLSAgICAgICAgKHRmZCwgYm9vdGNm
Z1sia2VybmVsIl0pID0gdGVtcGZpbGUubWtzdGVtcChwcmVmaXg9ImJvb3Rf
a2VybmVsLiIsCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgZGlyPW91dHB1dF9kaXJlY3RvcnkpCi0gICAg
ICAgIG9zLndyaXRlKHRmZCwgZGF0YSkKLSAgICAgICAgb3MuY2xvc2UodGZk
KQorICAgIGJvb3RjZmdbImtlcm5lbCJdID0gY29weV9mcm9tX2ltYWdlKGZz
LCBjaG9zZW5jZmdbImtlcm5lbCJdLCAia2VybmVsIiwKKyAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBvdXRwdXRfZGlyZWN0b3J5
LCBub3RfcmVhbGx5KQogCiAgICAgaWYgY2hvc2VuY2ZnWyJyYW1kaXNrIl06
Ci0gICAgICAgIGlmIG5vdF9yZWFsbHk6Ci0gICAgICAgICAgICBib290Y2Zn
WyJyYW1kaXNrIl0gPSAiPHJhbWRpc2s6JXM+IiAlIGNob3NlbmNmZ1sicmFt
ZGlzayJdCi0gICAgICAgIGVsc2U6Ci0gICAgICAgICAgICBkYXRhID0gZnMu
b3Blbl9maWxlKGNob3NlbmNmZ1sicmFtZGlzayJdLCkucmVhZCgpCi0gICAg
ICAgICAgICAodGZkLCBib290Y2ZnWyJyYW1kaXNrIl0pID0gdGVtcGZpbGUu
bWtzdGVtcCgKLSAgICAgICAgICAgICAgICBwcmVmaXg9ImJvb3RfcmFtZGlz
ay4iLCBkaXI9b3V0cHV0X2RpcmVjdG9yeSkKLSAgICAgICAgICAgIG9zLndy
aXRlKHRmZCwgZGF0YSkKLSAgICAgICAgICAgIG9zLmNsb3NlKHRmZCkKKyAg
ICAgICAgdHJ5OgorICAgICAgICAgICAgYm9vdGNmZ1sicmFtZGlzayJdID0g
Y29weV9mcm9tX2ltYWdlKGZzLCBjaG9zZW5jZmdbInJhbWRpc2siXSwKKyAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAicmFtZGlzayIsIG91dHB1dF9kaXJlY3RvcnksCisgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbm90X3JlYWxs
eSkKKyAgICAgICAgZXhjZXB0OgorICAgICAgICAgICAgaWYgbm90IG5vdF9y
ZWFsbHk6CisgICAgICAgICAgICAgICAgb3MudW5saW5rKGJvb3RjZmdbImtl
cm5lbCJdKQorICAgICAgICAgICAgcmFpc2UKICAgICBlbHNlOgogICAgICAg
ICBpbml0cmQgPSBOb25lCiAK

--=separator
Content-Type: application/octet-stream; name="xsa25-4.2.patch"
Content-Disposition: attachment; filename="xsa25-4.2.patch"
Content-Transfer-Encoding: base64

bGlieGM6IGJ1aWxkZXI6IGxpbWl0IG1heGltdW0gc2l6ZSBvZiBrZXJuZWwv
cmFtZGlzay4KCkFsbG93aW5nIHVzZXIgc3VwcGxpZWQga2VybmVscyBvZiBh
cmJpdHJhcnkgc2l6ZXMsIGVzcGVjaWFsbHkgZHVyaW5nCmRlY29tcHJlc3Np
b24sIGNhbiBzd2FsbG93IHVwIGRvbTAgbWVtb3J5IGxlYWRpbmcgdG8gZWl0
aGVyIHZpcnR1YWwKYWRkcmVzcyBzcGFjZSBleGhhdXN0aW9uIGluIHRoZSBi
dWlsZGVyIHByb2Nlc3Mgb3IgYWxsb2NhdGlvbgpmYWlsdXJlcy9PT00ga2ls
bGluZyBvZiBib3RoIHRvb2xzdGFjayBhbmQgdW5yZWxhdGVkIHByb2Nlc3Nl
cy4KCldlIGRpc2FibGUgdGhlc2UgY2hlY2tzIHdoZW4gYnVpbGRpbmcgaW4g
YSBzdHViIGRvbWFpbiBmb3IgcHZncnViCnNpbmNlIHRoaXMgdXNlcyB0aGUg
Z3Vlc3QncyBvd24gbWVtb3J5IGFuZCBpcyBpc29sYXRlZC4KCkRlY29tcHJl
c3Npb24gb2YgZ3ppcCBjb21wcmVzc2VkIGtlcm5lbHMgYW5kIHJhbWRpc2tz
IGhhcyBiZWVuIHNhZmUKc2luY2UgMTQ5NTQ6NTgyMDUyNTc1MTdkIChYZW4g
My4xLjAgb253YXJkcykuCgpUaGlzIGlzIFhTQS0yNSAvIENWRS0yMDEyLTQ1
NDQuCgpBbHNvIG1ha2UgZXhwbGljaXQgY2hlY2tzIGZvciBidWZmZXIgb3Zl
cmZsb3dzIGluIHZhcmlvdXMKZGVjb21wcmVzc2lvbiByb3V0aW5lcy4gVGhl
c2Ugd2VyZSBhbHJlYWR5IHJ1bGVkIG91dCBkdWUgdG8gb3RoZXIKcHJvcGVy
dGllcyBvZiB0aGUgY29kZSBidXQgY2hlY2sgdGhlbSBhcyBhIGJlbHQtYW5k
LWJyYWNlcyBtZWFzdXJlLgoKU2lnbmVkLW9mZi1ieTogSWFuIENhbXBiZWxs
IDxpYW4uY2FtcGJlbGxAY2l0cml4LmNvbT4KQWNrZWQtYnk6IElhbiBKYWNr
c29uIDxpYW4uamFja3NvbkBldS5jaXRyaXguY29tPgoKZGlmZiAtLWdpdCBh
L3N0dWJkb20vZ3J1Yi9rZXhlYy5jIGIvc3R1YmRvbS9ncnViL2tleGVjLmMK
aW5kZXggMDZiZWY1Mi4uYjIxYzkxYSAxMDA2NDQKLS0tIGEvc3R1YmRvbS9n
cnViL2tleGVjLmMKKysrIGIvc3R1YmRvbS9ncnViL2tleGVjLmMKQEAgLTEz
Nyw2ICsxMzcsMTAgQEAgdm9pZCBrZXhlYyh2b2lkICprZXJuZWwsIGxvbmcg
a2VybmVsX3NpemUsIHZvaWQgKm1vZHVsZSwgbG9uZyBtb2R1bGVfc2l6ZSwg
Y2hhcgogICAgIGRvbSA9IHhjX2RvbV9hbGxvY2F0ZSh4Y19oYW5kbGUsIGNt
ZGxpbmUsIGZlYXR1cmVzKTsKICAgICBkb20tPmFsbG9jYXRlID0ga2V4ZWNf
YWxsb2NhdGU7CiAKKyAgICAvKiBXZSBhcmUgdXNpbmcgZ3Vlc3Qgb3duZWQg
bWVtb3J5LCB0aGVyZWZvcmUgbm8gbGltaXRzLiAqLworICAgIHhjX2RvbV9r
ZXJuZWxfbWF4X3NpemUoZG9tLCAwKTsKKyAgICB4Y19kb21fcmFtZGlza19t
YXhfc2l6ZShkb20sIDApOworCiAgICAgZG9tLT5rZXJuZWxfYmxvYiA9IGtl
cm5lbDsKICAgICBkb20tPmtlcm5lbF9zaXplID0ga2VybmVsX3NpemU7CiAK
ZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnhjL3hjX2RvbS5oIGIvdG9vbHMvbGli
eGMveGNfZG9tLmgKaW5kZXggMmFlZjY0YS4uNmE3MmFhOSAxMDA2NDQKLS0t
IGEvdG9vbHMvbGlieGMveGNfZG9tLmgKKysrIGIvdG9vbHMvbGlieGMveGNf
ZG9tLmgKQEAgLTU1LDYgKzU1LDkgQEAgc3RydWN0IHhjX2RvbV9pbWFnZSB7
CiAgICAgdm9pZCAqcmFtZGlza19ibG9iOwogICAgIHNpemVfdCByYW1kaXNr
X3NpemU7CiAKKyAgICBzaXplX3QgbWF4X2tlcm5lbF9zaXplOworICAgIHNp
emVfdCBtYXhfcmFtZGlza19zaXplOworCiAgICAgLyogYXJndW1lbnRzIGFu
ZCBwYXJhbWV0ZXJzICovCiAgICAgY2hhciAqY21kbGluZTsKICAgICB1aW50
MzJfdCBmX3JlcXVlc3RlZFtYRU5GRUFUX05SX1NVQk1BUFNdOwpAQCAtMTgw
LDYgKzE4MywyMyBAQCB2b2lkIHhjX2RvbV9yZWxlYXNlX3BoeXMoc3RydWN0
IHhjX2RvbV9pbWFnZSAqZG9tKTsKIHZvaWQgeGNfZG9tX3JlbGVhc2Uoc3Ry
dWN0IHhjX2RvbV9pbWFnZSAqZG9tKTsKIGludCB4Y19kb21fbWVtX2luaXQo
c3RydWN0IHhjX2RvbV9pbWFnZSAqZG9tLCB1bnNpZ25lZCBpbnQgbWVtX21i
KTsKIAorLyogU2V0IHRoaXMgbGFyZ2VyIGlmIHlvdSBoYXZlIGVub3Jtb3Vz
IHJhbWRpc2tzL2tlcm5lbHMuIE5vdGUgdGhhdAorICogeW91IHNob3VsZCB0
cnVzdCBhbGwga2VybmVscyBub3QgdG8gYmUgbWFsaWNpb3VzbHkgbGFyZ2Ug
KGUuZy4gdG8KKyAqIGV4aGF1c3QgYWxsIGRvbTAgbWVtb3J5KSBpZiB5b3Ug
ZG8gdGhpcyAoc2VlIENWRS0yMDEyLTQ1NDQgLworICogWFNBLTI1KS4gWW91
IGNhbiBhbHNvIHNldCB0aGUgZGVmYXVsdCBpbmRlcGVuZGVudGx5IGZvcgor
ICogcmFtZGlza3Mva2VybmVscyBpbiB4Y19kb21fYWxsb2NhdGUoKSBvciBj
YWxsCisgKiB4Y19kb21fe2tlcm5lbCxyYW1kaXNrfV9tYXhfc2l6ZS4KKyAq
LworI2lmbmRlZiBYQ19ET01fREVDT01QUkVTU19NQVgKKyNkZWZpbmUgWENf
RE9NX0RFQ09NUFJFU1NfTUFYICgxMDI0KjEwMjQqMTAyNCkgLyogMUdCICov
CisjZW5kaWYKKworaW50IHhjX2RvbV9rZXJuZWxfY2hlY2tfc2l6ZShzdHJ1
Y3QgeGNfZG9tX2ltYWdlICpkb20sIHNpemVfdCBzeik7CitpbnQgeGNfZG9t
X2tlcm5lbF9tYXhfc2l6ZShzdHJ1Y3QgeGNfZG9tX2ltYWdlICpkb20sIHNp
emVfdCBzeik7CisKK2ludCB4Y19kb21fcmFtZGlza19jaGVja19zaXplKHN0
cnVjdCB4Y19kb21faW1hZ2UgKmRvbSwgc2l6ZV90IHN6KTsKK2ludCB4Y19k
b21fcmFtZGlza19tYXhfc2l6ZShzdHJ1Y3QgeGNfZG9tX2ltYWdlICpkb20s
IHNpemVfdCBzeik7CisKIHNpemVfdCB4Y19kb21fY2hlY2tfZ3ppcCh4Y19p
bnRlcmZhY2UgKnhjaCwKICAgICAgICAgICAgICAgICAgICAgIHZvaWQgKmJs
b2IsIHNpemVfdCB6aXBsZW4pOwogaW50IHhjX2RvbV9kb19ndW56aXAoeGNf
aW50ZXJmYWNlICp4Y2gsCkBAIC0yNDAsNyArMjYwLDggQEAgdm9pZCB4Y19k
b21fbG9nX21lbW9yeV9mb290cHJpbnQoc3RydWN0IHhjX2RvbV9pbWFnZSAq
ZG9tKTsKIHZvaWQgKnhjX2RvbV9tYWxsb2Moc3RydWN0IHhjX2RvbV9pbWFn
ZSAqZG9tLCBzaXplX3Qgc2l6ZSk7CiB2b2lkICp4Y19kb21fbWFsbG9jX3Bh
Z2VfYWxpZ25lZChzdHJ1Y3QgeGNfZG9tX2ltYWdlICpkb20sIHNpemVfdCBz
aXplKTsKIHZvaWQgKnhjX2RvbV9tYWxsb2NfZmlsZW1hcChzdHJ1Y3QgeGNf
ZG9tX2ltYWdlICpkb20sCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAg
Y29uc3QgY2hhciAqZmlsZW5hbWUsIHNpemVfdCAqIHNpemUpOworICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IGNoYXIgKmZpbGVuYW1lLCBz
aXplX3QgKiBzaXplLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNv
bnN0IHNpemVfdCBtYXhfc2l6ZSk7CiBjaGFyICp4Y19kb21fc3RyZHVwKHN0
cnVjdCB4Y19kb21faW1hZ2UgKmRvbSwgY29uc3QgY2hhciAqc3RyKTsKIAog
LyogLS0tIGFsbG9jIG1lbW9yeSBwb29sIC0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gKi8KZGlmZiAtLWdpdCBhL3Rvb2xz
L2xpYnhjL3hjX2RvbV9iemltYWdlbG9hZGVyLmMgYi90b29scy9saWJ4Yy94
Y19kb21fYnppbWFnZWxvYWRlci5jCmluZGV4IDExM2Q0MGYuLmIxYjJlYjAg
MTAwNjQ0Ci0tLSBhL3Rvb2xzL2xpYnhjL3hjX2RvbV9iemltYWdlbG9hZGVy
LmMKKysrIGIvdG9vbHMvbGlieGMveGNfZG9tX2J6aW1hZ2Vsb2FkZXIuYwpA
QCAtNDcsMTMgKzQ3LDE5IEBAIHN0YXRpYyBpbnQgeGNfdHJ5X2J6aXAyX2Rl
Y29kZSgKICAgICBjaGFyICpvdXRfYnVmOwogICAgIGNoYXIgKnRtcF9idWY7
CiAgICAgaW50IHJldHZhbCA9IC0xOwotICAgIGludCBvdXRzaXplOworICAg
IHVuc2lnbmVkIGludCBvdXRzaXplOwogICAgIHVpbnQ2NF90IHRvdGFsOwog
CiAgICAgc3RyZWFtLmJ6YWxsb2MgPSBOVUxMOwogICAgIHN0cmVhbS5iemZy
ZWUgPSBOVUxMOwogICAgIHN0cmVhbS5vcGFxdWUgPSBOVUxMOwogCisgICAg
aWYgKCBkb20tPmtlcm5lbF9zaXplID09IDApCisgICAgeworICAgICAgICBE
T01QUklOVEYoIkJaSVAyOiBJbnB1dCBpcyAwIHNpemUiKTsKKyAgICAgICAg
cmV0dXJuIC0xOworICAgIH0KKwogICAgIHJldCA9IEJaMl9iekRlY29tcHJl
c3NJbml0KCZzdHJlYW0sIDAsIDApOwogICAgIGlmICggcmV0ICE9IEJaX09L
ICkKICAgICB7CkBAIC02Niw2ICs3MiwxNyBAQCBzdGF0aWMgaW50IHhjX3Ry
eV9iemlwMl9kZWNvZGUoCiAgICAgICogdGhlIGlucHV0IGJ1ZmZlciB0byBz
dGFydCwgYW5kIHdlJ2xsIHJlYWxsb2MgYXMgbmVlZGVkLgogICAgICAqLwog
ICAgIG91dHNpemUgPSBkb20tPmtlcm5lbF9zaXplOworCisgICAgLyoKKyAg
ICAgKiBzdHJlYW0uYXZhaWxfaW4gYW5kIG91dHNpemUgYXJlIHVuc2lnbmVk
IGludCwgd2hpbGUga2VybmVsX3NpemUKKyAgICAgKiBpcyBhIHNpemVfdC4g
Q2hlY2sgd2UgYXJlbid0IG92ZXJmbG93aW5nLgorICAgICAqLworICAgIGlm
ICggb3V0c2l6ZSAhPSBkb20tPmtlcm5lbF9zaXplICkKKyAgICB7CisgICAg
ICAgIERPTVBSSU5URigiQlpJUDI6IElucHV0IHRvbyBsYXJnZSIpOworICAg
ICAgICBnb3RvIGJ6aXAyX2NsZWFudXA7CisgICAgfQorCiAgICAgb3V0X2J1
ZiA9IG1hbGxvYyhvdXRzaXplKTsKICAgICBpZiAoIG91dF9idWYgPT0gTlVM
TCApCiAgICAgewpAQCAtOTgsMTMgKzExNSwyMCBAQCBzdGF0aWMgaW50IHhj
X3RyeV9iemlwMl9kZWNvZGUoCiAgICAgICAgIGlmICggc3RyZWFtLmF2YWls
X291dCA9PSAwICkKICAgICAgICAgewogICAgICAgICAgICAgLyogUHJvdGVj
dCBhZ2FpbnN0IG91dHB1dCBidWZmZXIgb3ZlcmZsb3cgKi8KLSAgICAgICAg
ICAgIGlmICggb3V0c2l6ZSA+IElOVF9NQVggLyAyICkKKyAgICAgICAgICAg
IGlmICggb3V0c2l6ZSA+IFVJTlRfTUFYIC8gMiApCiAgICAgICAgICAgICB7
CiAgICAgICAgICAgICAgICAgRE9NUFJJTlRGKCJCWklQMjogb3V0cHV0IGJ1
ZmZlciBvdmVyZmxvdyIpOwogICAgICAgICAgICAgICAgIGZyZWUob3V0X2J1
Zik7CiAgICAgICAgICAgICAgICAgZ290byBiemlwMl9jbGVhbnVwOwogICAg
ICAgICAgICAgfQogCisgICAgICAgICAgICBpZiAoIHhjX2RvbV9rZXJuZWxf
Y2hlY2tfc2l6ZShkb20sIG91dHNpemUgKiAyKSApCisgICAgICAgICAgICB7
CisgICAgICAgICAgICAgICAgRE9NUFJJTlRGKCJCWklQMjogb3V0cHV0IHRv
byBsYXJnZSIpOworICAgICAgICAgICAgICAgIGZyZWUob3V0X2J1Zik7Cisg
ICAgICAgICAgICAgICAgZ290byBiemlwMl9jbGVhbnVwOworICAgICAgICAg
ICAgfQorCiAgICAgICAgICAgICB0bXBfYnVmID0gcmVhbGxvYyhvdXRfYnVm
LCBvdXRzaXplICogMik7CiAgICAgICAgICAgICBpZiAoIHRtcF9idWYgPT0g
TlVMTCApCiAgICAgICAgICAgICB7CkBAIC0xNzIsOSArMTk2LDE1IEBAIHN0
YXRpYyBpbnQgX3hjX3RyeV9sem1hX2RlY29kZSgKICAgICB1bnNpZ25lZCBj
aGFyICpvdXRfYnVmOwogICAgIHVuc2lnbmVkIGNoYXIgKnRtcF9idWY7CiAg
ICAgaW50IHJldHZhbCA9IC0xOwotICAgIGludCBvdXRzaXplOworICAgIHNp
emVfdCBvdXRzaXplOwogICAgIGNvbnN0IGNoYXIgKm1zZzsKIAorICAgIGlm
ICggZG9tLT5rZXJuZWxfc2l6ZSA9PSAwKQorICAgIHsKKyAgICAgICAgRE9N
UFJJTlRGKCIlczogSW5wdXQgaXMgMCBzaXplIiwgd2hhdCk7CisgICAgICAg
IHJldHVybiAtMTsKKyAgICB9CisKICAgICAvKiBzaWdoLiAgV2UgZG9uJ3Qg
a25vdyB1cC1mcm9udCBob3cgbXVjaCBtZW1vcnkgd2UgYXJlIGdvaW5nIHRv
IG5lZWQKICAgICAgKiBmb3IgdGhlIG91dHB1dCBidWZmZXIuICBBbGxvY2F0
ZSB0aGUgb3V0cHV0IGJ1ZmZlciB0byBiZSBlcXVhbAogICAgICAqIHRoZSBp
bnB1dCBidWZmZXIgdG8gc3RhcnQsIGFuZCB3ZSdsbCByZWFsbG9jIGFzIG5l
ZWRlZC4KQEAgLTI0NCwxMyArMjc0LDIwIEBAIHN0YXRpYyBpbnQgX3hjX3Ry
eV9sem1hX2RlY29kZSgKICAgICAgICAgaWYgKCBzdHJlYW0tPmF2YWlsX291
dCA9PSAwICkKICAgICAgICAgewogICAgICAgICAgICAgLyogUHJvdGVjdCBh
Z2FpbnN0IG91dHB1dCBidWZmZXIgb3ZlcmZsb3cgKi8KLSAgICAgICAgICAg
IGlmICggb3V0c2l6ZSA+IElOVF9NQVggLyAyICkKKyAgICAgICAgICAgIGlm
ICggb3V0c2l6ZSA+IFNJWkVfTUFYIC8gMiApCiAgICAgICAgICAgICB7CiAg
ICAgICAgICAgICAgICAgRE9NUFJJTlRGKCIlczogb3V0cHV0IGJ1ZmZlciBv
dmVyZmxvdyIsIHdoYXQpOwogICAgICAgICAgICAgICAgIGZyZWUob3V0X2J1
Zik7CiAgICAgICAgICAgICAgICAgZ290byBsem1hX2NsZWFudXA7CiAgICAg
ICAgICAgICB9CiAKKyAgICAgICAgICAgIGlmICggeGNfZG9tX2tlcm5lbF9j
aGVja19zaXplKGRvbSwgb3V0c2l6ZSAqIDIpICkKKyAgICAgICAgICAgIHsK
KyAgICAgICAgICAgICAgICBET01QUklOVEYoIiVzOiBvdXRwdXQgdG9vIGxh
cmdlIiwgd2hhdCk7CisgICAgICAgICAgICAgICAgZnJlZShvdXRfYnVmKTsK
KyAgICAgICAgICAgICAgICBnb3RvIGx6bWFfY2xlYW51cDsKKyAgICAgICAg
ICAgIH0KKwogICAgICAgICAgICAgdG1wX2J1ZiA9IHJlYWxsb2Mob3V0X2J1
Ziwgb3V0c2l6ZSAqIDIpOwogICAgICAgICAgICAgaWYgKCB0bXBfYnVmID09
IE5VTEwgKQogICAgICAgICAgICAgewpAQCAtMzU5LDYgKzM5NiwxMiBAQCBz
dGF0aWMgaW50IHhjX3RyeV9sem8xeF9kZWNvZGUoCiAgICAgICAgIDB4ODks
IDB4NGMsIDB4NWEsIDB4NGYsIDB4MDAsIDB4MGQsIDB4MGEsIDB4MWEsIDB4
MGEKICAgICB9OwogCisgICAgLyoKKyAgICAgKiBsem9fdWludCBzaG91bGQg
bWF0Y2ggc2l6ZV90LiBDaGVjayB0aGF0IHRoaXMgaXMgdGhlIGNhc2UgdG8g
YmUKKyAgICAgKiBzdXJlIHdlIHdvbid0IG92ZXJmbG93IHZhcmlvdXMgbHpv
X3VpbnQgZmllbGRzLgorICAgICAqLworICAgIFhDX0JVSUxEX0JVR19PTihz
aXplb2YobHpvX3VpbnQpICE9IHNpemVvZihzaXplX3QpKTsKKwogICAgIHJl
dCA9IGx6b19pbml0KCk7CiAgICAgaWYgKCByZXQgIT0gTFpPX0VfT0sgKQog
ICAgIHsKQEAgLTQzOCw2ICs0ODEsMTQgQEAgc3RhdGljIGludCB4Y190cnlf
bHpvMXhfZGVjb2RlKAogICAgICAgICBpZiAoIHNyY19sZW4gPD0gMCB8fCBz
cmNfbGVuID4gZHN0X2xlbiB8fCBzcmNfbGVuID4gbGVmdCApCiAgICAgICAg
ICAgICBicmVhazsKIAorICAgICAgICBtc2cgPSAiT3V0cHV0IGJ1ZmZlciBv
dmVyZmxvdyI7CisgICAgICAgIGlmICggKnNpemUgPiBTSVpFX01BWCAtIGRz
dF9sZW4gKQorICAgICAgICAgICAgYnJlYWs7CisKKyAgICAgICAgbXNnID0g
IkRlY29tcHJlc3NlZCBpbWFnZSB0b28gbGFyZ2UiOworICAgICAgICBpZiAo
IHhjX2RvbV9rZXJuZWxfY2hlY2tfc2l6ZShkb20sICpzaXplICsgZHN0X2xl
bikgKQorICAgICAgICAgICAgYnJlYWs7CisKICAgICAgICAgbXNnID0gIkZh
aWxlZCB0byAocmUpYWxsb2MgbWVtb3J5IjsKICAgICAgICAgdG1wX2J1ZiA9
IHJlYWxsb2Mob3V0X2J1ZiwgKnNpemUgKyBkc3RfbGVuKTsKICAgICAgICAg
aWYgKCB0bXBfYnVmID09IE5VTEwgKQpkaWZmIC0tZ2l0IGEvdG9vbHMvbGli
eGMveGNfZG9tX2NvcmUuYyBiL3Rvb2xzL2xpYnhjL3hjX2RvbV9jb3JlLmMK
aW5kZXggZmVhOWRlNS4uMmEwMWQ3YyAxMDA2NDQKLS0tIGEvdG9vbHMvbGli
eGMveGNfZG9tX2NvcmUuYworKysgYi90b29scy9saWJ4Yy94Y19kb21fY29y
ZS5jCkBAIC0xNTksNyArMTU5LDggQEAgdm9pZCAqeGNfZG9tX21hbGxvY19w
YWdlX2FsaWduZWQoc3RydWN0IHhjX2RvbV9pbWFnZSAqZG9tLCBzaXplX3Qg
c2l6ZSkKIH0KIAogdm9pZCAqeGNfZG9tX21hbGxvY19maWxlbWFwKHN0cnVj
dCB4Y19kb21faW1hZ2UgKmRvbSwKLSAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBjb25zdCBjaGFyICpmaWxlbmFtZSwgc2l6ZV90ICogc2l6ZSkKKyAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCBjaGFyICpmaWxlbmFt
ZSwgc2l6ZV90ICogc2l6ZSwKKyAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBjb25zdCBzaXplX3QgbWF4X3NpemUpCiB7CiAgICAgc3RydWN0IHhjX2Rv
bV9tZW0gKmJsb2NrID0gTlVMTDsKICAgICBpbnQgZmQgPSAtMTsKQEAgLTE3
MSw2ICsxNzIsMTMgQEAgdm9pZCAqeGNfZG9tX21hbGxvY19maWxlbWFwKHN0
cnVjdCB4Y19kb21faW1hZ2UgKmRvbSwKICAgICBsc2VlayhmZCwgMCwgU0VF
S19TRVQpOwogICAgICpzaXplID0gbHNlZWsoZmQsIDAsIFNFRUtfRU5EKTsK
IAorICAgIGlmICggbWF4X3NpemUgJiYgKnNpemUgPiBtYXhfc2l6ZSApCisg
ICAgeworICAgICAgICB4Y19kb21fcGFuaWMoZG9tLT54Y2gsIFhDX09VVF9P
Rl9NRU1PUlksCisgICAgICAgICAgICAgICAgICAgICAidHJpZWQgdG8gbWFw
IGZpbGUgd2hpY2ggaXMgdG9vIGxhcmdlIik7CisgICAgICAgIGdvdG8gZXJy
OworICAgIH0KKwogICAgIGJsb2NrID0gbWFsbG9jKHNpemVvZigqYmxvY2sp
KTsKICAgICBpZiAoIGJsb2NrID09IE5VTEwgKQogICAgICAgICBnb3RvIGVy
cjsKQEAgLTIyMiw2ICsyMzAsNDAgQEAgY2hhciAqeGNfZG9tX3N0cmR1cChz
dHJ1Y3QgeGNfZG9tX2ltYWdlICpkb20sIGNvbnN0IGNoYXIgKnN0cikKIH0K
IAogLyogLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tICovCisvKiBkZWNv
bXByZXNzaW9uIGJ1ZmZlciBzaXppbmcgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgKi8KK2ludCB4Y19kb21fa2VybmVs
X2NoZWNrX3NpemUoc3RydWN0IHhjX2RvbV9pbWFnZSAqZG9tLCBzaXplX3Qg
c3opCit7CisgICAgLyogTm8gbGltaXQgKi8KKyAgICBpZiAoICFkb20tPm1h
eF9rZXJuZWxfc2l6ZSApCisgICAgICAgIHJldHVybiAwOworCisgICAgaWYg
KCBzeiA+IGRvbS0+bWF4X2tlcm5lbF9zaXplICkKKyAgICB7CisgICAgICAg
IHhjX2RvbV9wYW5pYyhkb20tPnhjaCwgWENfSU5WQUxJRF9LRVJORUwsCisg
ICAgICAgICAgICAgICAgICAgICAia2VybmVsIGltYWdlIHRvbyBsYXJnZSIp
OworICAgICAgICByZXR1cm4gMTsKKyAgICB9CisKKyAgICByZXR1cm4gMDsK
K30KKworaW50IHhjX2RvbV9yYW1kaXNrX2NoZWNrX3NpemUoc3RydWN0IHhj
X2RvbV9pbWFnZSAqZG9tLCBzaXplX3Qgc3opCit7CisgICAgLyogTm8gbGlt
aXQgKi8KKyAgICBpZiAoICFkb20tPm1heF9yYW1kaXNrX3NpemUgKQorICAg
ICAgICByZXR1cm4gMDsKKworICAgIGlmICggc3ogPiBkb20tPm1heF9yYW1k
aXNrX3NpemUgKQorICAgIHsKKyAgICAgICAgeGNfZG9tX3BhbmljKGRvbS0+
eGNoLCBYQ19JTlZBTElEX0tFUk5FTCwKKyAgICAgICAgICAgICAgICAgICAg
ICJyYW1kaXNrIGltYWdlIHRvbyBsYXJnZSIpOworICAgICAgICByZXR1cm4g
MTsKKyAgICB9CisKKyAgICByZXR1cm4gMDsKK30KKworLyogLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tICovCiAvKiByZWFkIGZpbGVzLCBjb3B5IG1l
bW9yeSBibG9ja3MsIHdpdGggdHJhbnNwYXJlbnQgZ3VuemlwICAgICAgICAg
ICAgICAgICAgKi8KIAogc2l6ZV90IHhjX2RvbV9jaGVja19nemlwKHhjX2lu
dGVyZmFjZSAqeGNoLCB2b2lkICpibG9iLCBzaXplX3QgemlwbGVuKQpAQCAt
MjM1LDcgKzI3Nyw3IEBAIHNpemVfdCB4Y19kb21fY2hlY2tfZ3ppcCh4Y19p
bnRlcmZhY2UgKnhjaCwgdm9pZCAqYmxvYiwgc2l6ZV90IHppcGxlbikKIAog
ICAgIGd6bGVuID0gYmxvYiArIHppcGxlbiAtIDQ7CiAgICAgdW56aXBsZW4g
PSBnemxlblszXSA8PCAyNCB8IGd6bGVuWzJdIDw8IDE2IHwgZ3psZW5bMV0g
PDwgOCB8IGd6bGVuWzBdOwotICAgIGlmICggKHVuemlwbGVuIDwgMCkgfHwg
KHVuemlwbGVuID4gKDEwMjQqMTAyNCoxMDI0KSkgKSAvKiAxR0IgbGltaXQg
Ki8KKyAgICBpZiAoICh1bnppcGxlbiA8IDApIHx8ICh1bnppcGxlbiA+IFhD
X0RPTV9ERUNPTVBSRVNTX01BWCkgKQogICAgIHsKICAgICAgICAgeGNfZG9t
X3ByaW50ZgogICAgICAgICAgICAgKHhjaCwKQEAgLTI4OCw2ICszMzAsOSBA
QCBpbnQgeGNfZG9tX3RyeV9ndW56aXAoc3RydWN0IHhjX2RvbV9pbWFnZSAq
ZG9tLCB2b2lkICoqYmxvYiwgc2l6ZV90ICogc2l6ZSkKICAgICBpZiAoIHVu
emlwbGVuID09IDAgKQogICAgICAgICByZXR1cm4gMDsKIAorICAgIGlmICgg
eGNfZG9tX2tlcm5lbF9jaGVja19zaXplKGRvbSwgdW56aXBsZW4pICkKKyAg
ICAgICAgcmV0dXJuIDA7CisKICAgICB1bnppcCA9IHhjX2RvbV9tYWxsb2Mo
ZG9tLCB1bnppcGxlbik7CiAgICAgaWYgKCB1bnppcCA9PSBOVUxMICkKICAg
ICAgICAgcmV0dXJuIC0xOwpAQCAtNTg4LDYgKzYzMyw5IEBAIHN0cnVjdCB4
Y19kb21faW1hZ2UgKnhjX2RvbV9hbGxvY2F0ZSh4Y19pbnRlcmZhY2UgKnhj
aCwKICAgICBtZW1zZXQoZG9tLCAwLCBzaXplb2YoKmRvbSkpOwogICAgIGRv
bS0+eGNoID0geGNoOwogCisgICAgZG9tLT5tYXhfa2VybmVsX3NpemUgPSBY
Q19ET01fREVDT01QUkVTU19NQVg7CisgICAgZG9tLT5tYXhfcmFtZGlza19z
aXplID0gWENfRE9NX0RFQ09NUFJFU1NfTUFYOworCiAgICAgaWYgKCBjbWRs
aW5lICkKICAgICAgICAgZG9tLT5jbWRsaW5lID0geGNfZG9tX3N0cmR1cChk
b20sIGNtZGxpbmUpOwogICAgIGlmICggZmVhdHVyZXMgKQpAQCAtNjA4LDEw
ICs2NTYsMjUgQEAgc3RydWN0IHhjX2RvbV9pbWFnZSAqeGNfZG9tX2FsbG9j
YXRlKHhjX2ludGVyZmFjZSAqeGNoLAogICAgIHJldHVybiBOVUxMOwogfQog
CitpbnQgeGNfZG9tX2tlcm5lbF9tYXhfc2l6ZShzdHJ1Y3QgeGNfZG9tX2lt
YWdlICpkb20sIHNpemVfdCBzeikKK3sKKyAgICBET01QUklOVEYoIiVzOiBr
ZXJuZWxfbWF4X3NpemU9JXp4IiwgX19GVU5DVElPTl9fLCBzeik7CisgICAg
ZG9tLT5tYXhfa2VybmVsX3NpemUgPSBzejsKKyAgICByZXR1cm4gMDsKK30K
KworaW50IHhjX2RvbV9yYW1kaXNrX21heF9zaXplKHN0cnVjdCB4Y19kb21f
aW1hZ2UgKmRvbSwgc2l6ZV90IHN6KQoreworICAgIERPTVBSSU5URigiJXM6
IHJhbWRpc2tfbWF4X3NpemU9JXp4IiwgX19GVU5DVElPTl9fLCBzeik7Cisg
ICAgZG9tLT5tYXhfcmFtZGlza19zaXplID0gc3o7CisgICAgcmV0dXJuIDA7
Cit9CisKIGludCB4Y19kb21fa2VybmVsX2ZpbGUoc3RydWN0IHhjX2RvbV9p
bWFnZSAqZG9tLCBjb25zdCBjaGFyICpmaWxlbmFtZSkKIHsKICAgICBET01Q
UklOVEYoIiVzOiBmaWxlbmFtZT1cIiVzXCIiLCBfX0ZVTkNUSU9OX18sIGZp
bGVuYW1lKTsKLSAgICBkb20tPmtlcm5lbF9ibG9iID0geGNfZG9tX21hbGxv
Y19maWxlbWFwKGRvbSwgZmlsZW5hbWUsICZkb20tPmtlcm5lbF9zaXplKTsK
KyAgICBkb20tPmtlcm5lbF9ibG9iID0geGNfZG9tX21hbGxvY19maWxlbWFw
KGRvbSwgZmlsZW5hbWUsICZkb20tPmtlcm5lbF9zaXplLAorICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZG9tLT5tYXhf
a2VybmVsX3NpemUpOwogICAgIGlmICggZG9tLT5rZXJuZWxfYmxvYiA9PSBO
VUxMICkKICAgICAgICAgcmV0dXJuIC0xOwogICAgIHJldHVybiB4Y19kb21f
dHJ5X2d1bnppcChkb20sICZkb20tPmtlcm5lbF9ibG9iLCAmZG9tLT5rZXJu
ZWxfc2l6ZSk7CkBAIC02MjEsNyArNjg0LDkgQEAgaW50IHhjX2RvbV9yYW1k
aXNrX2ZpbGUoc3RydWN0IHhjX2RvbV9pbWFnZSAqZG9tLCBjb25zdCBjaGFy
ICpmaWxlbmFtZSkKIHsKICAgICBET01QUklOVEYoIiVzOiBmaWxlbmFtZT1c
IiVzXCIiLCBfX0ZVTkNUSU9OX18sIGZpbGVuYW1lKTsKICAgICBkb20tPnJh
bWRpc2tfYmxvYiA9Ci0gICAgICAgIHhjX2RvbV9tYWxsb2NfZmlsZW1hcChk
b20sIGZpbGVuYW1lLCAmZG9tLT5yYW1kaXNrX3NpemUpOworICAgICAgICB4
Y19kb21fbWFsbG9jX2ZpbGVtYXAoZG9tLCBmaWxlbmFtZSwgJmRvbS0+cmFt
ZGlza19zaXplLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZG9t
LT5tYXhfcmFtZGlza19zaXplKTsKKwogICAgIGlmICggZG9tLT5yYW1kaXNr
X2Jsb2IgPT0gTlVMTCApCiAgICAgICAgIHJldHVybiAtMTsKIC8vICAgIHJl
dHVybiB4Y19kb21fdHJ5X2d1bnppcChkb20sICZkb20tPnJhbWRpc2tfYmxv
YiwgJmRvbS0+cmFtZGlza19zaXplKTsKQEAgLTc4MSw3ICs4NDYsMTEgQEAg
aW50IHhjX2RvbV9idWlsZF9pbWFnZShzdHJ1Y3QgeGNfZG9tX2ltYWdlICpk
b20pCiAgICAgICAgIHZvaWQgKnJhbWRpc2ttYXA7CiAKICAgICAgICAgdW56
aXBsZW4gPSB4Y19kb21fY2hlY2tfZ3ppcChkb20tPnhjaCwgZG9tLT5yYW1k
aXNrX2Jsb2IsIGRvbS0+cmFtZGlza19zaXplKTsKKyAgICAgICAgaWYgKCB4
Y19kb21fcmFtZGlza19jaGVja19zaXplKGRvbSwgdW56aXBsZW4pICE9IDAg
KQorICAgICAgICAgICAgdW56aXBsZW4gPSAwOworCiAgICAgICAgIHJhbWRp
c2tsZW4gPSB1bnppcGxlbiA/IHVuemlwbGVuIDogZG9tLT5yYW1kaXNrX3Np
emU7CisKICAgICAgICAgaWYgKCB4Y19kb21fYWxsb2Nfc2VnbWVudChkb20s
ICZkb20tPnJhbWRpc2tfc2VnLCAicmFtZGlzayIsIDAsCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgcmFtZGlza2xlbikgIT0gMCApCiAg
ICAgICAgICAgICBnb3RvIGVycjsK

--=separator
Content-Type: application/octet-stream; name="xsa25-unstable.patch"
Content-Disposition: attachment; filename="xsa25-unstable.patch"
Content-Transfer-Encoding: base64

bGlieGM6IGJ1aWxkZXI6IGxpbWl0IG1heGltdW0gc2l6ZSBvZiBrZXJuZWwv
cmFtZGlzay4KCkFsbG93aW5nIHVzZXIgc3VwcGxpZWQga2VybmVscyBvZiBh
cmJpdHJhcnkgc2l6ZXMsIGVzcGVjaWFsbHkgZHVyaW5nCmRlY29tcHJlc3Np
b24sIGNhbiBzd2FsbG93IHVwIGRvbTAgbWVtb3J5IGxlYWRpbmcgdG8gZWl0
aGVyIHZpcnR1YWwKYWRkcmVzcyBzcGFjZSBleGhhdXN0aW9uIGluIHRoZSBi
dWlsZGVyIHByb2Nlc3Mgb3IgYWxsb2NhdGlvbgpmYWlsdXJlcy9PT00ga2ls
bGluZyBvZiBib3RoIHRvb2xzdGFjayBhbmQgdW5yZWxhdGVkIHByb2Nlc3Nl
cy4KCldlIGRpc2FibGUgdGhlc2UgY2hlY2tzIHdoZW4gYnVpbGRpbmcgaW4g
YSBzdHViIGRvbWFpbiBmb3IgcHZncnViCnNpbmNlIHRoaXMgdXNlcyB0aGUg
Z3Vlc3QncyBvd24gbWVtb3J5IGFuZCBpcyBpc29sYXRlZC4KCkRlY29tcHJl
c3Npb24gb2YgZ3ppcCBjb21wcmVzc2VkIGtlcm5lbHMgYW5kIHJhbWRpc2tz
IGhhcyBiZWVuIHNhZmUKc2luY2UgMTQ5NTQ6NTgyMDUyNTc1MTdkIChYZW4g
My4xLjAgb253YXJkcykuCgpUaGlzIGlzIFhTQS0yNSAvIENWRS0yMDEyLTQ1
NDQuCgpBbHNvIG1ha2UgZXhwbGljaXQgY2hlY2tzIGZvciBidWZmZXIgb3Zl
cmZsb3dzIGluIHZhcmlvdXMKZGVjb21wcmVzc2lvbiByb3V0aW5lcy4gVGhl
c2Ugd2VyZSBhbHJlYWR5IHJ1bGVkIG91dCBkdWUgdG8gb3RoZXIKcHJvcGVy
dGllcyBvZiB0aGUgY29kZSBidXQgY2hlY2sgdGhlbSBhcyBhIGJlbHQtYW5k
LWJyYWNlcyBtZWFzdXJlLgoKU2lnbmVkLW9mZi1ieTogSWFuIENhbXBiZWxs
IDxpYW4uY2FtcGJlbGxAY2l0cml4LmNvbT4KQWNrZWQtYnk6IElhbiBKYWNr
c29uIDxpYW4uamFja3NvbkBldS5jaXRyaXguY29tPgoKZGlmZiAtciBiOWMx
ZTA4NmQ5YjcgLXIgODIzNDM1ODlhNzExIHN0dWJkb20vZ3J1Yi9rZXhlYy5j
Ci0tLSBhL3N0dWJkb20vZ3J1Yi9rZXhlYy5jCVdlZCBPY3QgMjQgMTU6NDk6
NDEgMjAxMiArMDEwMAorKysgYi9zdHViZG9tL2dydWIva2V4ZWMuYwlGcmkg
T2N0IDI2IDA5OjE5OjIyIDIwMTIgKzAxMDAKQEAgLTEzNyw2ICsxMzcsMTAg
QEAgdm9pZCBrZXhlYyh2b2lkICprZXJuZWwsIGxvbmcga2VybmVsX3Npegog
ICAgIGRvbSA9IHhjX2RvbV9hbGxvY2F0ZSh4Y19oYW5kbGUsIGNtZGxpbmUs
IGZlYXR1cmVzKTsKICAgICBkb20tPmFsbG9jYXRlID0ga2V4ZWNfYWxsb2Nh
dGU7CiAKKyAgICAvKiBXZSBhcmUgdXNpbmcgZ3Vlc3Qgb3duZWQgbWVtb3J5
LCB0aGVyZWZvcmUgbm8gbGltaXRzLiAqLworICAgIHhjX2RvbV9rZXJuZWxf
bWF4X3NpemUoZG9tLCAwKTsKKyAgICB4Y19kb21fcmFtZGlza19tYXhfc2l6
ZShkb20sIDApOworCiAgICAgZG9tLT5rZXJuZWxfYmxvYiA9IGtlcm5lbDsK
ICAgICBkb20tPmtlcm5lbF9zaXplID0ga2VybmVsX3NpemU7CiAKZGlmZiAt
ciBiOWMxZTA4NmQ5YjcgLXIgODIzNDM1ODlhNzExIHRvb2xzL2xpYnhjL3hj
X2RvbS5oCi0tLSBhL3Rvb2xzL2xpYnhjL3hjX2RvbS5oCVdlZCBPY3QgMjQg
MTU6NDk6NDEgMjAxMiArMDEwMAorKysgYi90b29scy9saWJ4Yy94Y19kb20u
aAlGcmkgT2N0IDI2IDA5OjE5OjIyIDIwMTIgKzAxMDAKQEAgLTU1LDYgKzU1
LDkgQEAgc3RydWN0IHhjX2RvbV9pbWFnZSB7CiAgICAgdm9pZCAqcmFtZGlz
a19ibG9iOwogICAgIHNpemVfdCByYW1kaXNrX3NpemU7CiAKKyAgICBzaXpl
X3QgbWF4X2tlcm5lbF9zaXplOworICAgIHNpemVfdCBtYXhfcmFtZGlza19z
aXplOworCiAgICAgLyogYXJndW1lbnRzIGFuZCBwYXJhbWV0ZXJzICovCiAg
ICAgY2hhciAqY21kbGluZTsKICAgICB1aW50MzJfdCBmX3JlcXVlc3RlZFtY
RU5GRUFUX05SX1NVQk1BUFNdOwpAQCAtMTk0LDYgKzE5NywyMyBAQCB2b2lk
IHhjX2RvbV9yZWxlYXNlX3BoeXMoc3RydWN0IHhjX2RvbV9pCiB2b2lkIHhj
X2RvbV9yZWxlYXNlKHN0cnVjdCB4Y19kb21faW1hZ2UgKmRvbSk7CiBpbnQg
eGNfZG9tX21lbV9pbml0KHN0cnVjdCB4Y19kb21faW1hZ2UgKmRvbSwgdW5z
aWduZWQgaW50IG1lbV9tYik7CiAKKy8qIFNldCB0aGlzIGxhcmdlciBpZiB5
b3UgaGF2ZSBlbm9ybW91cyByYW1kaXNrcy9rZXJuZWxzLiBOb3RlIHRoYXQK
KyAqIHlvdSBzaG91bGQgdHJ1c3QgYWxsIGtlcm5lbHMgbm90IHRvIGJlIG1h
bGljaW91c2x5IGxhcmdlIChlLmcuIHRvCisgKiBleGhhdXN0IGFsbCBkb20w
IG1lbW9yeSkgaWYgeW91IGRvIHRoaXMgKHNlZSBDVkUtMjAxMi00NTQ0IC8K
KyAqIFhTQS0yNSkuIFlvdSBjYW4gYWxzbyBzZXQgdGhlIGRlZmF1bHQgaW5k
ZXBlbmRlbnRseSBmb3IKKyAqIHJhbWRpc2tzL2tlcm5lbHMgaW4geGNfZG9t
X2FsbG9jYXRlKCkgb3IgY2FsbAorICogeGNfZG9tX3trZXJuZWwscmFtZGlz
a31fbWF4X3NpemUuCisgKi8KKyNpZm5kZWYgWENfRE9NX0RFQ09NUFJFU1Nf
TUFYCisjZGVmaW5lIFhDX0RPTV9ERUNPTVBSRVNTX01BWCAoMTAyNCoxMDI0
KjEwMjQpIC8qIDFHQiAqLworI2VuZGlmCisKK2ludCB4Y19kb21fa2VybmVs
X2NoZWNrX3NpemUoc3RydWN0IHhjX2RvbV9pbWFnZSAqZG9tLCBzaXplX3Qg
c3opOworaW50IHhjX2RvbV9rZXJuZWxfbWF4X3NpemUoc3RydWN0IHhjX2Rv
bV9pbWFnZSAqZG9tLCBzaXplX3Qgc3opOworCitpbnQgeGNfZG9tX3JhbWRp
c2tfY2hlY2tfc2l6ZShzdHJ1Y3QgeGNfZG9tX2ltYWdlICpkb20sIHNpemVf
dCBzeik7CitpbnQgeGNfZG9tX3JhbWRpc2tfbWF4X3NpemUoc3RydWN0IHhj
X2RvbV9pbWFnZSAqZG9tLCBzaXplX3Qgc3opOworCiBzaXplX3QgeGNfZG9t
X2NoZWNrX2d6aXAoeGNfaW50ZXJmYWNlICp4Y2gsCiAgICAgICAgICAgICAg
ICAgICAgICB2b2lkICpibG9iLCBzaXplX3QgemlwbGVuKTsKIGludCB4Y19k
b21fZG9fZ3VuemlwKHhjX2ludGVyZmFjZSAqeGNoLApAQCAtMjU0LDcgKzI3
NCw4IEBAIHZvaWQgeGNfZG9tX2xvZ19tZW1vcnlfZm9vdHByaW50KHN0cnVj
dCAKIHZvaWQgKnhjX2RvbV9tYWxsb2Moc3RydWN0IHhjX2RvbV9pbWFnZSAq
ZG9tLCBzaXplX3Qgc2l6ZSk7CiB2b2lkICp4Y19kb21fbWFsbG9jX3BhZ2Vf
YWxpZ25lZChzdHJ1Y3QgeGNfZG9tX2ltYWdlICpkb20sIHNpemVfdCBzaXpl
KTsKIHZvaWQgKnhjX2RvbV9tYWxsb2NfZmlsZW1hcChzdHJ1Y3QgeGNfZG9t
X2ltYWdlICpkb20sCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgY29u
c3QgY2hhciAqZmlsZW5hbWUsIHNpemVfdCAqIHNpemUpOworICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIGNvbnN0IGNoYXIgKmZpbGVuYW1lLCBzaXpl
X3QgKiBzaXplLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0
IHNpemVfdCBtYXhfc2l6ZSk7CiBjaGFyICp4Y19kb21fc3RyZHVwKHN0cnVj
dCB4Y19kb21faW1hZ2UgKmRvbSwgY29uc3QgY2hhciAqc3RyKTsKIAogLyog
LS0tIGFsbG9jIG1lbW9yeSBwb29sIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0gKi8KZGlmZiAtciBiOWMxZTA4NmQ5Yjcg
LXIgODIzNDM1ODlhNzExIHRvb2xzL2xpYnhjL3hjX2RvbV9iemltYWdlbG9h
ZGVyLmMKLS0tIGEvdG9vbHMvbGlieGMveGNfZG9tX2J6aW1hZ2Vsb2FkZXIu
YwlXZWQgT2N0IDI0IDE1OjQ5OjQxIDIwMTIgKzAxMDAKKysrIGIvdG9vbHMv
bGlieGMveGNfZG9tX2J6aW1hZ2Vsb2FkZXIuYwlGcmkgT2N0IDI2IDA5OjE5
OjIyIDIwMTIgKzAxMDAKQEAgLTQ3LDEzICs0NywxOSBAQCBzdGF0aWMgaW50
IHhjX3RyeV9iemlwMl9kZWNvZGUoCiAgICAgY2hhciAqb3V0X2J1ZjsKICAg
ICBjaGFyICp0bXBfYnVmOwogICAgIGludCByZXR2YWwgPSAtMTsKLSAgICBp
bnQgb3V0c2l6ZTsKKyAgICB1bnNpZ25lZCBpbnQgb3V0c2l6ZTsKICAgICB1
aW50NjRfdCB0b3RhbDsKIAogICAgIHN0cmVhbS5iemFsbG9jID0gTlVMTDsK
ICAgICBzdHJlYW0uYnpmcmVlID0gTlVMTDsKICAgICBzdHJlYW0ub3BhcXVl
ID0gTlVMTDsKIAorICAgIGlmICggZG9tLT5rZXJuZWxfc2l6ZSA9PSAwKQor
ICAgIHsKKyAgICAgICAgRE9NUFJJTlRGKCJCWklQMjogSW5wdXQgaXMgMCBz
aXplIik7CisgICAgICAgIHJldHVybiAtMTsKKyAgICB9CisKICAgICByZXQg
PSBCWjJfYnpEZWNvbXByZXNzSW5pdCgmc3RyZWFtLCAwLCAwKTsKICAgICBp
ZiAoIHJldCAhPSBCWl9PSyApCiAgICAgewpAQCAtNjYsNiArNzIsMTcgQEAg
c3RhdGljIGludCB4Y190cnlfYnppcDJfZGVjb2RlKAogICAgICAqIHRoZSBp
bnB1dCBidWZmZXIgdG8gc3RhcnQsIGFuZCB3ZSdsbCByZWFsbG9jIGFzIG5l
ZWRlZC4KICAgICAgKi8KICAgICBvdXRzaXplID0gZG9tLT5rZXJuZWxfc2l6
ZTsKKworICAgIC8qCisgICAgICogc3RyZWFtLmF2YWlsX2luIGFuZCBvdXRz
aXplIGFyZSB1bnNpZ25lZCBpbnQsIHdoaWxlIGtlcm5lbF9zaXplCisgICAg
ICogaXMgYSBzaXplX3QuIENoZWNrIHdlIGFyZW4ndCBvdmVyZmxvd2luZy4K
KyAgICAgKi8KKyAgICBpZiAoIG91dHNpemUgIT0gZG9tLT5rZXJuZWxfc2l6
ZSApCisgICAgeworICAgICAgICBET01QUklOVEYoIkJaSVAyOiBJbnB1dCB0
b28gbGFyZ2UiKTsKKyAgICAgICAgZ290byBiemlwMl9jbGVhbnVwOworICAg
IH0KKwogICAgIG91dF9idWYgPSBtYWxsb2Mob3V0c2l6ZSk7CiAgICAgaWYg
KCBvdXRfYnVmID09IE5VTEwgKQogICAgIHsKQEAgLTk4LDEzICsxMTUsMjAg
QEAgc3RhdGljIGludCB4Y190cnlfYnppcDJfZGVjb2RlKAogICAgICAgICBp
ZiAoIHN0cmVhbS5hdmFpbF9vdXQgPT0gMCApCiAgICAgICAgIHsKICAgICAg
ICAgICAgIC8qIFByb3RlY3QgYWdhaW5zdCBvdXRwdXQgYnVmZmVyIG92ZXJm
bG93ICovCi0gICAgICAgICAgICBpZiAoIG91dHNpemUgPiBJTlRfTUFYIC8g
MiApCisgICAgICAgICAgICBpZiAoIG91dHNpemUgPiBVSU5UX01BWCAvIDIg
KQogICAgICAgICAgICAgewogICAgICAgICAgICAgICAgIERPTVBSSU5URigi
QlpJUDI6IG91dHB1dCBidWZmZXIgb3ZlcmZsb3ciKTsKICAgICAgICAgICAg
ICAgICBmcmVlKG91dF9idWYpOwogICAgICAgICAgICAgICAgIGdvdG8gYnpp
cDJfY2xlYW51cDsKICAgICAgICAgICAgIH0KIAorICAgICAgICAgICAgaWYg
KCB4Y19kb21fa2VybmVsX2NoZWNrX3NpemUoZG9tLCBvdXRzaXplICogMikg
KQorICAgICAgICAgICAgeworICAgICAgICAgICAgICAgIERPTVBSSU5URigi
QlpJUDI6IG91dHB1dCB0b28gbGFyZ2UiKTsKKyAgICAgICAgICAgICAgICBm
cmVlKG91dF9idWYpOworICAgICAgICAgICAgICAgIGdvdG8gYnppcDJfY2xl
YW51cDsKKyAgICAgICAgICAgIH0KKwogICAgICAgICAgICAgdG1wX2J1ZiA9
IHJlYWxsb2Mob3V0X2J1Ziwgb3V0c2l6ZSAqIDIpOwogICAgICAgICAgICAg
aWYgKCB0bXBfYnVmID09IE5VTEwgKQogICAgICAgICAgICAgewpAQCAtMTcy
LDkgKzE5NiwxNSBAQCBzdGF0aWMgaW50IF94Y190cnlfbHptYV9kZWNvZGUo
CiAgICAgdW5zaWduZWQgY2hhciAqb3V0X2J1ZjsKICAgICB1bnNpZ25lZCBj
aGFyICp0bXBfYnVmOwogICAgIGludCByZXR2YWwgPSAtMTsKLSAgICBpbnQg
b3V0c2l6ZTsKKyAgICBzaXplX3Qgb3V0c2l6ZTsKICAgICBjb25zdCBjaGFy
ICptc2c7CiAKKyAgICBpZiAoIGRvbS0+a2VybmVsX3NpemUgPT0gMCkKKyAg
ICB7CisgICAgICAgIERPTVBSSU5URigiJXM6IElucHV0IGlzIDAgc2l6ZSIs
IHdoYXQpOworICAgICAgICByZXR1cm4gLTE7CisgICAgfQorCiAgICAgLyog
c2lnaC4gIFdlIGRvbid0IGtub3cgdXAtZnJvbnQgaG93IG11Y2ggbWVtb3J5
IHdlIGFyZSBnb2luZyB0byBuZWVkCiAgICAgICogZm9yIHRoZSBvdXRwdXQg
YnVmZmVyLiAgQWxsb2NhdGUgdGhlIG91dHB1dCBidWZmZXIgdG8gYmUgZXF1
YWwKICAgICAgKiB0aGUgaW5wdXQgYnVmZmVyIHRvIHN0YXJ0LCBhbmQgd2Un
bGwgcmVhbGxvYyBhcyBuZWVkZWQuCkBAIC0yNDQsMTMgKzI3NCwyMCBAQCBz
dGF0aWMgaW50IF94Y190cnlfbHptYV9kZWNvZGUoCiAgICAgICAgIGlmICgg
c3RyZWFtLT5hdmFpbF9vdXQgPT0gMCApCiAgICAgICAgIHsKICAgICAgICAg
ICAgIC8qIFByb3RlY3QgYWdhaW5zdCBvdXRwdXQgYnVmZmVyIG92ZXJmbG93
ICovCi0gICAgICAgICAgICBpZiAoIG91dHNpemUgPiBJTlRfTUFYIC8gMiAp
CisgICAgICAgICAgICBpZiAoIG91dHNpemUgPiBTSVpFX01BWCAvIDIgKQog
ICAgICAgICAgICAgewogICAgICAgICAgICAgICAgIERPTVBSSU5URigiJXM6
IG91dHB1dCBidWZmZXIgb3ZlcmZsb3ciLCB3aGF0KTsKICAgICAgICAgICAg
ICAgICBmcmVlKG91dF9idWYpOwogICAgICAgICAgICAgICAgIGdvdG8gbHpt
YV9jbGVhbnVwOwogICAgICAgICAgICAgfQogCisgICAgICAgICAgICBpZiAo
IHhjX2RvbV9rZXJuZWxfY2hlY2tfc2l6ZShkb20sIG91dHNpemUgKiAyKSAp
CisgICAgICAgICAgICB7CisgICAgICAgICAgICAgICAgRE9NUFJJTlRGKCIl
czogb3V0cHV0IHRvbyBsYXJnZSIsIHdoYXQpOworICAgICAgICAgICAgICAg
IGZyZWUob3V0X2J1Zik7CisgICAgICAgICAgICAgICAgZ290byBsem1hX2Ns
ZWFudXA7CisgICAgICAgICAgICB9CisKICAgICAgICAgICAgIHRtcF9idWYg
PSByZWFsbG9jKG91dF9idWYsIG91dHNpemUgKiAyKTsKICAgICAgICAgICAg
IGlmICggdG1wX2J1ZiA9PSBOVUxMICkKICAgICAgICAgICAgIHsKQEAgLTM1
OSw2ICszOTYsMTIgQEAgc3RhdGljIGludCB4Y190cnlfbHpvMXhfZGVjb2Rl
KAogICAgICAgICAweDg5LCAweDRjLCAweDVhLCAweDRmLCAweDAwLCAweDBk
LCAweDBhLCAweDFhLCAweDBhCiAgICAgfTsKIAorICAgIC8qCisgICAgICog
bHpvX3VpbnQgc2hvdWxkIG1hdGNoIHNpemVfdC4gQ2hlY2sgdGhhdCB0aGlz
IGlzIHRoZSBjYXNlIHRvIGJlCisgICAgICogc3VyZSB3ZSB3b24ndCBvdmVy
ZmxvdyB2YXJpb3VzIGx6b191aW50IGZpZWxkcy4KKyAgICAgKi8KKyAgICBY
Q19CVUlMRF9CVUdfT04oc2l6ZW9mKGx6b191aW50KSAhPSBzaXplb2Yoc2l6
ZV90KSk7CisKICAgICByZXQgPSBsem9faW5pdCgpOwogICAgIGlmICggcmV0
ICE9IExaT19FX09LICkKICAgICB7CkBAIC00MzgsNiArNDgxLDE0IEBAIHN0
YXRpYyBpbnQgeGNfdHJ5X2x6bzF4X2RlY29kZSgKICAgICAgICAgaWYgKCBz
cmNfbGVuIDw9IDAgfHwgc3JjX2xlbiA+IGRzdF9sZW4gfHwgc3JjX2xlbiA+
IGxlZnQgKQogICAgICAgICAgICAgYnJlYWs7CiAKKyAgICAgICAgbXNnID0g
Ik91dHB1dCBidWZmZXIgb3ZlcmZsb3ciOworICAgICAgICBpZiAoICpzaXpl
ID4gU0laRV9NQVggLSBkc3RfbGVuICkKKyAgICAgICAgICAgIGJyZWFrOwor
CisgICAgICAgIG1zZyA9ICJEZWNvbXByZXNzZWQgaW1hZ2UgdG9vIGxhcmdl
IjsKKyAgICAgICAgaWYgKCB4Y19kb21fa2VybmVsX2NoZWNrX3NpemUoZG9t
LCAqc2l6ZSArIGRzdF9sZW4pICkKKyAgICAgICAgICAgIGJyZWFrOworCiAg
ICAgICAgIG1zZyA9ICJGYWlsZWQgdG8gKHJlKWFsbG9jIG1lbW9yeSI7CiAg
ICAgICAgIHRtcF9idWYgPSByZWFsbG9jKG91dF9idWYsICpzaXplICsgZHN0
X2xlbik7CiAgICAgICAgIGlmICggdG1wX2J1ZiA9PSBOVUxMICkKZGlmZiAt
ciBiOWMxZTA4NmQ5YjcgLXIgODIzNDM1ODlhNzExIHRvb2xzL2xpYnhjL3hj
X2RvbV9jb3JlLmMKLS0tIGEvdG9vbHMvbGlieGMveGNfZG9tX2NvcmUuYwlX
ZWQgT2N0IDI0IDE1OjQ5OjQxIDIwMTIgKzAxMDAKKysrIGIvdG9vbHMvbGli
eGMveGNfZG9tX2NvcmUuYwlGcmkgT2N0IDI2IDA5OjE5OjIyIDIwMTIgKzAx
MDAKQEAgLTE1OSw3ICsxNTksOCBAQCB2b2lkICp4Y19kb21fbWFsbG9jX3Bh
Z2VfYWxpZ25lZChzdHJ1Y3QgCiB9CiAKIHZvaWQgKnhjX2RvbV9tYWxsb2Nf
ZmlsZW1hcChzdHJ1Y3QgeGNfZG9tX2ltYWdlICpkb20sCi0gICAgICAgICAg
ICAgICAgICAgICAgICAgICAgY29uc3QgY2hhciAqZmlsZW5hbWUsIHNpemVf
dCAqIHNpemUpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3Qg
Y2hhciAqZmlsZW5hbWUsIHNpemVfdCAqIHNpemUsCisgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgY29uc3Qgc2l6ZV90IG1heF9zaXplKQogewogICAg
IHN0cnVjdCB4Y19kb21fbWVtICpibG9jayA9IE5VTEw7CiAgICAgaW50IGZk
ID0gLTE7CkBAIC0xNzEsNiArMTcyLDEzIEBAIHZvaWQgKnhjX2RvbV9tYWxs
b2NfZmlsZW1hcChzdHJ1Y3QgeGNfZG8KICAgICBsc2VlayhmZCwgMCwgU0VF
S19TRVQpOwogICAgICpzaXplID0gbHNlZWsoZmQsIDAsIFNFRUtfRU5EKTsK
IAorICAgIGlmICggbWF4X3NpemUgJiYgKnNpemUgPiBtYXhfc2l6ZSApCisg
ICAgeworICAgICAgICB4Y19kb21fcGFuaWMoZG9tLT54Y2gsIFhDX09VVF9P
Rl9NRU1PUlksCisgICAgICAgICAgICAgICAgICAgICAidHJpZWQgdG8gbWFw
IGZpbGUgd2hpY2ggaXMgdG9vIGxhcmdlIik7CisgICAgICAgIGdvdG8gZXJy
OworICAgIH0KKwogICAgIGJsb2NrID0gbWFsbG9jKHNpemVvZigqYmxvY2sp
KTsKICAgICBpZiAoIGJsb2NrID09IE5VTEwgKQogICAgICAgICBnb3RvIGVy
cjsKQEAgLTIyMiw2ICsyMzAsNDAgQEAgY2hhciAqeGNfZG9tX3N0cmR1cChz
dHJ1Y3QgeGNfZG9tX2ltYWdlIAogfQogCiAvKiAtLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0gKi8KKy8qIGRlY29tcHJlc3Npb24gYnVmZmVyIHNpemlu
ZyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAqLworaW50IHhjX2RvbV9rZXJuZWxfY2hlY2tfc2l6ZShzdHJ1Y3QgeGNf
ZG9tX2ltYWdlICpkb20sIHNpemVfdCBzeikKK3sKKyAgICAvKiBObyBsaW1p
dCAqLworICAgIGlmICggIWRvbS0+bWF4X2tlcm5lbF9zaXplICkKKyAgICAg
ICAgcmV0dXJuIDA7CisKKyAgICBpZiAoIHN6ID4gZG9tLT5tYXhfa2VybmVs
X3NpemUgKQorICAgIHsKKyAgICAgICAgeGNfZG9tX3BhbmljKGRvbS0+eGNo
LCBYQ19JTlZBTElEX0tFUk5FTCwKKyAgICAgICAgICAgICAgICAgICAgICJr
ZXJuZWwgaW1hZ2UgdG9vIGxhcmdlIik7CisgICAgICAgIHJldHVybiAxOwor
ICAgIH0KKworICAgIHJldHVybiAwOworfQorCitpbnQgeGNfZG9tX3JhbWRp
c2tfY2hlY2tfc2l6ZShzdHJ1Y3QgeGNfZG9tX2ltYWdlICpkb20sIHNpemVf
dCBzeikKK3sKKyAgICAvKiBObyBsaW1pdCAqLworICAgIGlmICggIWRvbS0+
bWF4X3JhbWRpc2tfc2l6ZSApCisgICAgICAgIHJldHVybiAwOworCisgICAg
aWYgKCBzeiA+IGRvbS0+bWF4X3JhbWRpc2tfc2l6ZSApCisgICAgeworICAg
ICAgICB4Y19kb21fcGFuaWMoZG9tLT54Y2gsIFhDX0lOVkFMSURfS0VSTkVM
LAorICAgICAgICAgICAgICAgICAgICAgInJhbWRpc2sgaW1hZ2UgdG9vIGxh
cmdlIik7CisgICAgICAgIHJldHVybiAxOworICAgIH0KKworICAgIHJldHVy
biAwOworfQorCisvKiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gKi8K
IC8qIHJlYWQgZmlsZXMsIGNvcHkgbWVtb3J5IGJsb2Nrcywgd2l0aCB0cmFu
c3BhcmVudCBndW56aXAgICAgICAgICAgICAgICAgICAqLwogCiBzaXplX3Qg
eGNfZG9tX2NoZWNrX2d6aXAoeGNfaW50ZXJmYWNlICp4Y2gsIHZvaWQgKmJs
b2IsIHNpemVfdCB6aXBsZW4pCkBAIC0yMzUsNyArMjc3LDcgQEAgc2l6ZV90
IHhjX2RvbV9jaGVja19nemlwKHhjX2ludGVyZmFjZSAqeAogCiAgICAgZ3ps
ZW4gPSBibG9iICsgemlwbGVuIC0gNDsKICAgICB1bnppcGxlbiA9IGd6bGVu
WzNdIDw8IDI0IHwgZ3psZW5bMl0gPDwgMTYgfCBnemxlblsxXSA8PCA4IHwg
Z3psZW5bMF07Ci0gICAgaWYgKCAodW56aXBsZW4gPCAwKSB8fCAodW56aXBs
ZW4gPiAoMTAyNCoxMDI0KjEwMjQpKSApIC8qIDFHQiBsaW1pdCAqLworICAg
IGlmICggKHVuemlwbGVuIDwgMCkgfHwgKHVuemlwbGVuID4gWENfRE9NX0RF
Q09NUFJFU1NfTUFYKSApCiAgICAgewogICAgICAgICB4Y19kb21fcHJpbnRm
CiAgICAgICAgICAgICAoeGNoLApAQCAtMjg4LDYgKzMzMCw5IEBAIGludCB4
Y19kb21fdHJ5X2d1bnppcChzdHJ1Y3QgeGNfZG9tX2ltYWcKICAgICBpZiAo
IHVuemlwbGVuID09IDAgKQogICAgICAgICByZXR1cm4gMDsKIAorICAgIGlm
ICggeGNfZG9tX2tlcm5lbF9jaGVja19zaXplKGRvbSwgdW56aXBsZW4pICkK
KyAgICAgICAgcmV0dXJuIDA7CisKICAgICB1bnppcCA9IHhjX2RvbV9tYWxs
b2MoZG9tLCB1bnppcGxlbik7CiAgICAgaWYgKCB1bnppcCA9PSBOVUxMICkK
ICAgICAgICAgcmV0dXJuIC0xOwpAQCAtNTkwLDYgKzYzNSw5IEBAIHN0cnVj
dCB4Y19kb21faW1hZ2UgKnhjX2RvbV9hbGxvY2F0ZSh4Y18KICAgICBtZW1z
ZXQoZG9tLCAwLCBzaXplb2YoKmRvbSkpOwogICAgIGRvbS0+eGNoID0geGNo
OwogCisgICAgZG9tLT5tYXhfa2VybmVsX3NpemUgPSBYQ19ET01fREVDT01Q
UkVTU19NQVg7CisgICAgZG9tLT5tYXhfcmFtZGlza19zaXplID0gWENfRE9N
X0RFQ09NUFJFU1NfTUFYOworCiAgICAgaWYgKCBjbWRsaW5lICkKICAgICAg
ICAgZG9tLT5jbWRsaW5lID0geGNfZG9tX3N0cmR1cChkb20sIGNtZGxpbmUp
OwogICAgIGlmICggZmVhdHVyZXMgKQpAQCAtNjEwLDEwICs2NTgsMjUgQEAg
c3RydWN0IHhjX2RvbV9pbWFnZSAqeGNfZG9tX2FsbG9jYXRlKHhjXwogICAg
IHJldHVybiBOVUxMOwogfQogCitpbnQgeGNfZG9tX2tlcm5lbF9tYXhfc2l6
ZShzdHJ1Y3QgeGNfZG9tX2ltYWdlICpkb20sIHNpemVfdCBzeikKK3sKKyAg
ICBET01QUklOVEYoIiVzOiBrZXJuZWxfbWF4X3NpemU9JXp4IiwgX19GVU5D
VElPTl9fLCBzeik7CisgICAgZG9tLT5tYXhfa2VybmVsX3NpemUgPSBzejsK
KyAgICByZXR1cm4gMDsKK30KKworaW50IHhjX2RvbV9yYW1kaXNrX21heF9z
aXplKHN0cnVjdCB4Y19kb21faW1hZ2UgKmRvbSwgc2l6ZV90IHN6KQorewor
ICAgIERPTVBSSU5URigiJXM6IHJhbWRpc2tfbWF4X3NpemU9JXp4IiwgX19G
VU5DVElPTl9fLCBzeik7CisgICAgZG9tLT5tYXhfcmFtZGlza19zaXplID0g
c3o7CisgICAgcmV0dXJuIDA7Cit9CisKIGludCB4Y19kb21fa2VybmVsX2Zp
bGUoc3RydWN0IHhjX2RvbV9pbWFnZSAqZG9tLCBjb25zdCBjaGFyICpmaWxl
bmFtZSkKIHsKICAgICBET01QUklOVEYoIiVzOiBmaWxlbmFtZT1cIiVzXCIi
LCBfX0ZVTkNUSU9OX18sIGZpbGVuYW1lKTsKLSAgICBkb20tPmtlcm5lbF9i
bG9iID0geGNfZG9tX21hbGxvY19maWxlbWFwKGRvbSwgZmlsZW5hbWUsICZk
b20tPmtlcm5lbF9zaXplKTsKKyAgICBkb20tPmtlcm5lbF9ibG9iID0geGNf
ZG9tX21hbGxvY19maWxlbWFwKGRvbSwgZmlsZW5hbWUsICZkb20tPmtlcm5l
bF9zaXplLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgZG9tLT5tYXhfa2VybmVsX3NpemUpOwogICAgIGlmICggZG9t
LT5rZXJuZWxfYmxvYiA9PSBOVUxMICkKICAgICAgICAgcmV0dXJuIC0xOwog
ICAgIHJldHVybiB4Y19kb21fdHJ5X2d1bnppcChkb20sICZkb20tPmtlcm5l
bF9ibG9iLCAmZG9tLT5rZXJuZWxfc2l6ZSk7CkBAIC02MjMsNyArNjg2LDkg
QEAgaW50IHhjX2RvbV9yYW1kaXNrX2ZpbGUoc3RydWN0IHhjX2RvbV9pbQog
ewogICAgIERPTVBSSU5URigiJXM6IGZpbGVuYW1lPVwiJXNcIiIsIF9fRlVO
Q1RJT05fXywgZmlsZW5hbWUpOwogICAgIGRvbS0+cmFtZGlza19ibG9iID0K
LSAgICAgICAgeGNfZG9tX21hbGxvY19maWxlbWFwKGRvbSwgZmlsZW5hbWUs
ICZkb20tPnJhbWRpc2tfc2l6ZSk7CisgICAgICAgIHhjX2RvbV9tYWxsb2Nf
ZmlsZW1hcChkb20sIGZpbGVuYW1lLCAmZG9tLT5yYW1kaXNrX3NpemUsCisg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkb20tPm1heF9yYW1kaXNr
X3NpemUpOworCiAgICAgaWYgKCBkb20tPnJhbWRpc2tfYmxvYiA9PSBOVUxM
ICkKICAgICAgICAgcmV0dXJuIC0xOwogLy8gICAgcmV0dXJuIHhjX2RvbV90
cnlfZ3VuemlwKGRvbSwgJmRvbS0+cmFtZGlza19ibG9iLCAmZG9tLT5yYW1k
aXNrX3NpemUpOwpAQCAtNzgzLDcgKzg0OCwxMSBAQCBpbnQgeGNfZG9tX2J1
aWxkX2ltYWdlKHN0cnVjdCB4Y19kb21faW1hCiAgICAgICAgIHZvaWQgKnJh
bWRpc2ttYXA7CiAKICAgICAgICAgdW56aXBsZW4gPSB4Y19kb21fY2hlY2tf
Z3ppcChkb20tPnhjaCwgZG9tLT5yYW1kaXNrX2Jsb2IsIGRvbS0+cmFtZGlz
a19zaXplKTsKKyAgICAgICAgaWYgKCB4Y19kb21fcmFtZGlza19jaGVja19z
aXplKGRvbSwgdW56aXBsZW4pICE9IDAgKQorICAgICAgICAgICAgdW56aXBs
ZW4gPSAwOworCiAgICAgICAgIHJhbWRpc2tsZW4gPSB1bnppcGxlbiA/IHVu
emlwbGVuIDogZG9tLT5yYW1kaXNrX3NpemU7CisKICAgICAgICAgaWYgKCB4
Y19kb21fYWxsb2Nfc2VnbWVudChkb20sICZkb20tPnJhbWRpc2tfc2VnLCAi
cmFtZGlzayIsIDAsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgcmFtZGlza2xlbikgIT0gMCApCiAgICAgICAgICAgICBnb3RvIGVycjsK

--=separator
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=separator--


From xen-devel-bounces@lists.xen.org Fri Oct 26 11:02:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 11:02:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRhft-0001fJ-Un; Fri, 26 Oct 2012 11:02:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRhfr-0001f2-T8; Fri, 26 Oct 2012 11:02:00 +0000
Received: from [85.158.139.83:61094] by server-4.bemta-5.messagelabs.com id
	3D/F1-01455-6AD6A805; Fri, 26 Oct 2012 11:01:58 +0000
X-Env-Sender: iwj@xenbits.xen.org
X-Msg-Ref: server-3.tower-182.messagelabs.com!1351249316!27438188!1
X-Originating-IP: [50.57.168.107]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22601 invoked from network); 26 Oct 2012 11:01:57 -0000
Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107)
	by server-3.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Oct 2012 11:01:57 -0000
Received: from xenbits.xen.org ([50.57.170.242])
	by mail.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRhfg-0003oA-7z; Fri, 26 Oct 2012 11:01:48 +0000
Received: from iwj by xenbits.xen.org with local (Exim 4.72)
	(envelope-from )
	id 1TRhff-0004iR-Vi; Fri, 26 Oct 2012 11:01:48 +0000
Date: Fri, 26 Oct 2012 11:01:47 +0000
Message-Id: 
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
	xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team 
Cc: "Xen.org security team" 
Subject: [Xen-devel] Xen Security Advisory 25 (CVE-2012-4544) - Xen domain
 builder Out-of-memory due to malicious kernel/ramdisk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

	     Xen Security Advisory CVE-2012-4544 / XSA-25

   Xen domain builder Out-of-memory due to malicious kernel/ramdisk

ISSUE DESCRIPTION
=================

The Xen PV domain builder contained no validation of the size of the
supplied kernel or ramdisk either before or after decompression. This
could cause the toolstack to consume all available RAM in the domain
running the domain builder.

IMPACT
======

A malicious guest administrator who can supply a kernel or ramdisk can
exhaust memory in domain 0 leading to a denial of service attack.

VULNERABLE SYSTEMS
==================

All versions of Xen are vulnerable.

MITIGATION
==========

Running only trusted kernels and ramdisks will avoid this
vulnerability.

Using pvgrub also avoids this vulnerability since the builder will run
in guest context. (nb: use of pygrub *is* vulnerable).

Running only HVM guests will avoid this vulnerability.

RELATED ISSUE
=============

CVE-2012-2625 covers a bug in pygrub which caused that process to
consume excessive amount of memory under similar circumstances to the
above.

This was fixed in xen-unstable (and the fix inherited by Xen 4.2.x) in
revision 25589:60f09d1ab1fe but not called out as a security problem.
This fix is also included, where relevant, in the patches below.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue, including
the related pygrub fix where neccesary.

xsa25-unstable.patch        Xen unstable
xsa25-4.2.patch             Xen 4.2.x
xsa25-4.1.patch             Xen 4.1.x

$ sha256sum xsa25*.patch
613e4b82cdc9cabf9cbd52076118887b298c47e680c2066a28a77f12e9f90606  xsa25-4.1.patch
135bc089d003f9b97991764c37b1ab8d37e9cbcfa1b9bd7429b4503abe00c8f5  xsa25-4.2.patch
534495b7eef6e599f5814f0a67fc84fbe2e8eee9d223a09ad178ff63bdcda3dd  xsa25-unstable.patch

Note that these patches impose a new size limit of 1Gby on both the
compressed and uncompressed sizes of ramdisks.  On some systems it may
be desirable to relax these limits and risk virtual address or memory
exhaustion in the toolstack.  This can be achieved by setting
XC_DOM_DECOMPRESS_MAX to the desired limit (in bytes). This can be
done by building with "APPEND_CFLAGS=-DXC_DOM_DECOMPRESS_MAX="
or by editing tools/libxc/xc_dom.h directly.

NOTE REGARDING LACK OF EMBARGO
==============================

These issues have already been discussed in public in various places,
including https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-2625
and http://bugs.debian.org/688125.  This advisory is therefore not
subject to an embargo.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJQim1nAAoJEIP+FMlX6CvZgw0IAKTyGbRlt5N2i8YbRdAj0+wF
OA4X5G1GlAEf0iGVjYi92/HnVyjWxLSNCKJK4YSWAUrlnkAC2IEUU6vqQOkxN/ic
88D1VS8tEtQwRGa9jNxf4RTCLvdGxrVK4lnSDu7OplgwMDT7O/X+Dq89xKN2VCYw
/iqpzlAndmC0Lqz0U8VlV71JryS5uwg980GWimQaIEinyOWFS5cuImvBamptl+zU
aoU3JxERd3YWASrspm8dBOtwc75DucWY1hOjz52uloodKcJha55Objcm8dn76xwN
JV7sHGFRrQyxHnQJ9GeSuV0RHkxB6VhMXTGWKFaynOLjtUUoidkawgs1ld+Qsms=
=Vj6Q
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa25-4.1.patch"
Content-Disposition: attachment; filename="xsa25-4.1.patch"
Content-Transfer-Encoding: base64

bGlieGM6IGJ1aWxkZXI6IGxpbWl0IG1heGltdW0gc2l6ZSBvZiBrZXJuZWwv
cmFtZGlzay4KCkFsbG93aW5nIHVzZXIgc3VwcGxpZWQga2VybmVscyBvZiBh
cmJpdHJhcnkgc2l6ZXMsIGVzcGVjaWFsbHkgZHVyaW5nCmRlY29tcHJlc3Np
b24sIGNhbiBzd2FsbG93IHVwIGRvbTAgbWVtb3J5IGxlYWRpbmcgdG8gZWl0
aGVyIHZpcnR1YWwKYWRkcmVzcyBzcGFjZSBleGhhdXN0aW9uIGluIHRoZSBi
dWlsZGVyIHByb2Nlc3Mgb3IgYWxsb2NhdGlvbgpmYWlsdXJlcy9PT00ga2ls
bGluZyBvZiBib3RoIHRvb2xzdGFjayBhbmQgdW5yZWxhdGVkIHByb2Nlc3Nl
cy4KCldlIGRpc2FibGUgdGhlc2UgY2hlY2tzIHdoZW4gYnVpbGRpbmcgaW4g
YSBzdHViIGRvbWFpbiBmb3IgcHZncnViCnNpbmNlIHRoaXMgdXNlcyB0aGUg
Z3Vlc3QncyBvd24gbWVtb3J5IGFuZCBpcyBpc29sYXRlZC4KCkRlY29tcHJl
c3Npb24gb2YgZ3ppcCBjb21wcmVzc2VkIGtlcm5lbHMgYW5kIHJhbWRpc2tz
IGhhcyBiZWVuIHNhZmUKc2luY2UgMTQ5NTQ6NTgyMDUyNTc1MTdkIChYZW4g
My4xLjAgb253YXJkcykuCgpUaGlzIGlzIFhTQS0yNSAvIENWRS0yMDEyLTQ1
NDQuCgpBbHNvIG1ha2UgZXhwbGljaXQgY2hlY2tzIGZvciBidWZmZXIgb3Zl
cmZsb3dzIGluIHZhcmlvdXMKZGVjb21wcmVzc2lvbiByb3V0aW5lcy4gVGhl
c2Ugd2VyZSBhbHJlYWR5IHJ1bGVkIG91dCBkdWUgdG8gb3RoZXIKcHJvcGVy
dGllcyBvZiB0aGUgY29kZSBidXQgY2hlY2sgdGhlbSBhcyBhIGJlbHQtYW5k
LWJyYWNlcyBtZWFzdXJlLgoKU2lnbmVkLW9mZi1ieTogSWFuIENhbXBiZWxs
IDxpYW4uY2FtcGJlbGxAY2l0cml4LmNvbT4KQWNrZWQtYnk6IElhbiBKYWNr
c29uIDxpYW4uamFja3NvbkBldS5jaXRyaXguY29tPgpbIEluY2x1ZGVzIDI1
NTg5OjYwZjA5ZDFhYjFmZSBmb3IgQ1ZFLTIwMTItMjYyNSBdCgpkaWZmIC0t
Z2l0IGEvc3R1YmRvbS9ncnViL2tleGVjLmMgYi9zdHViZG9tL2dydWIva2V4
ZWMuYwppbmRleCAwNmJlZjUyLi5iMjFjOTFhIDEwMDY0NAotLS0gYS9zdHVi
ZG9tL2dydWIva2V4ZWMuYworKysgYi9zdHViZG9tL2dydWIva2V4ZWMuYwpA
QCAtMTM3LDYgKzEzNywxMCBAQCB2b2lkIGtleGVjKHZvaWQgKmtlcm5lbCwg
bG9uZyBrZXJuZWxfc2l6ZSwgdm9pZCAqbW9kdWxlLCBsb25nIG1vZHVsZV9z
aXplLCBjaGFyCiAgICAgZG9tID0geGNfZG9tX2FsbG9jYXRlKHhjX2hhbmRs
ZSwgY21kbGluZSwgZmVhdHVyZXMpOwogICAgIGRvbS0+YWxsb2NhdGUgPSBr
ZXhlY19hbGxvY2F0ZTsKIAorICAgIC8qIFdlIGFyZSB1c2luZyBndWVzdCBv
d25lZCBtZW1vcnksIHRoZXJlZm9yZSBubyBsaW1pdHMuICovCisgICAgeGNf
ZG9tX2tlcm5lbF9tYXhfc2l6ZShkb20sIDApOworICAgIHhjX2RvbV9yYW1k
aXNrX21heF9zaXplKGRvbSwgMCk7CisKICAgICBkb20tPmtlcm5lbF9ibG9i
ID0ga2VybmVsOwogICAgIGRvbS0+a2VybmVsX3NpemUgPSBrZXJuZWxfc2l6
ZTsKIApkaWZmIC0tZ2l0IGEvdG9vbHMvbGlieGMveGNfZG9tLmggYi90b29s
cy9saWJ4Yy94Y19kb20uaAppbmRleCBlNzJmMDY2Li43MDQzZjk2IDEwMDY0
NAotLS0gYS90b29scy9saWJ4Yy94Y19kb20uaAorKysgYi90b29scy9saWJ4
Yy94Y19kb20uaApAQCAtNTIsNiArNTIsOSBAQCBzdHJ1Y3QgeGNfZG9tX2lt
YWdlIHsKICAgICB2b2lkICpyYW1kaXNrX2Jsb2I7CiAgICAgc2l6ZV90IHJh
bWRpc2tfc2l6ZTsKIAorICAgIHNpemVfdCBtYXhfa2VybmVsX3NpemU7Cisg
ICAgc2l6ZV90IG1heF9yYW1kaXNrX3NpemU7CisKICAgICAvKiBhcmd1bWVu
dHMgYW5kIHBhcmFtZXRlcnMgKi8KICAgICBjaGFyICpjbWRsaW5lOwogICAg
IHVpbnQzMl90IGZfcmVxdWVzdGVkW1hFTkZFQVRfTlJfU1VCTUFQU107CkBA
IC0xNzUsNiArMTc4LDIzIEBAIHZvaWQgeGNfZG9tX3JlbGVhc2VfcGh5cyhz
dHJ1Y3QgeGNfZG9tX2ltYWdlICpkb20pOwogdm9pZCB4Y19kb21fcmVsZWFz
ZShzdHJ1Y3QgeGNfZG9tX2ltYWdlICpkb20pOwogaW50IHhjX2RvbV9tZW1f
aW5pdChzdHJ1Y3QgeGNfZG9tX2ltYWdlICpkb20sIHVuc2lnbmVkIGludCBt
ZW1fbWIpOwogCisvKiBTZXQgdGhpcyBsYXJnZXIgaWYgeW91IGhhdmUgZW5v
cm1vdXMgcmFtZGlza3Mva2VybmVscy4gTm90ZSB0aGF0CisgKiB5b3Ugc2hv
dWxkIHRydXN0IGFsbCBrZXJuZWxzIG5vdCB0byBiZSBtYWxpY2lvdXNseSBs
YXJnZSAoZS5nLiB0bworICogZXhoYXVzdCBhbGwgZG9tMCBtZW1vcnkpIGlm
IHlvdSBkbyB0aGlzIChzZWUgQ1ZFLTIwMTItNDU0NCAvCisgKiBYU0EtMjUp
LiBZb3UgY2FuIGFsc28gc2V0IHRoZSBkZWZhdWx0IGluZGVwZW5kZW50bHkg
Zm9yCisgKiByYW1kaXNrcy9rZXJuZWxzIGluIHhjX2RvbV9hbGxvY2F0ZSgp
IG9yIGNhbGwKKyAqIHhjX2RvbV97a2VybmVsLHJhbWRpc2t9X21heF9zaXpl
LgorICovCisjaWZuZGVmIFhDX0RPTV9ERUNPTVBSRVNTX01BWAorI2RlZmlu
ZSBYQ19ET01fREVDT01QUkVTU19NQVggKDEwMjQqMTAyNCoxMDI0KSAvKiAx
R0IgKi8KKyNlbmRpZgorCitpbnQgeGNfZG9tX2tlcm5lbF9jaGVja19zaXpl
KHN0cnVjdCB4Y19kb21faW1hZ2UgKmRvbSwgc2l6ZV90IHN6KTsKK2ludCB4
Y19kb21fa2VybmVsX21heF9zaXplKHN0cnVjdCB4Y19kb21faW1hZ2UgKmRv
bSwgc2l6ZV90IHN6KTsKKworaW50IHhjX2RvbV9yYW1kaXNrX2NoZWNrX3Np
emUoc3RydWN0IHhjX2RvbV9pbWFnZSAqZG9tLCBzaXplX3Qgc3opOworaW50
IHhjX2RvbV9yYW1kaXNrX21heF9zaXplKHN0cnVjdCB4Y19kb21faW1hZ2Ug
KmRvbSwgc2l6ZV90IHN6KTsKKwogc2l6ZV90IHhjX2RvbV9jaGVja19nemlw
KHhjX2ludGVyZmFjZSAqeGNoLAogICAgICAgICAgICAgICAgICAgICAgdm9p
ZCAqYmxvYiwgc2l6ZV90IHppcGxlbik7CiBpbnQgeGNfZG9tX2RvX2d1bnpp
cCh4Y19pbnRlcmZhY2UgKnhjaCwKQEAgLTIyNCw3ICsyNDQsOCBAQCB2b2lk
IHhjX2RvbV9sb2dfbWVtb3J5X2Zvb3RwcmludChzdHJ1Y3QgeGNfZG9tX2lt
YWdlICpkb20pOwogdm9pZCAqeGNfZG9tX21hbGxvYyhzdHJ1Y3QgeGNfZG9t
X2ltYWdlICpkb20sIHNpemVfdCBzaXplKTsKIHZvaWQgKnhjX2RvbV9tYWxs
b2NfcGFnZV9hbGlnbmVkKHN0cnVjdCB4Y19kb21faW1hZ2UgKmRvbSwgc2l6
ZV90IHNpemUpOwogdm9pZCAqeGNfZG9tX21hbGxvY19maWxlbWFwKHN0cnVj
dCB4Y19kb21faW1hZ2UgKmRvbSwKLSAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBjb25zdCBjaGFyICpmaWxlbmFtZSwgc2l6ZV90ICogc2l6ZSk7Cisg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgY2hhciAqZmlsZW5h
bWUsIHNpemVfdCAqIHNpemUsCisgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgY29uc3Qgc2l6ZV90IG1heF9zaXplKTsKIGNoYXIgKnhjX2RvbV9zdHJk
dXAoc3RydWN0IHhjX2RvbV9pbWFnZSAqZG9tLCBjb25zdCBjaGFyICpzdHIp
OwogCiAvKiAtLS0gYWxsb2MgbWVtb3J5IHBvb2wgLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAqLwpkaWZmIC0tZ2l0IGEv
dG9vbHMvbGlieGMveGNfZG9tX2J6aW1hZ2Vsb2FkZXIuYyBiL3Rvb2xzL2xp
YnhjL3hjX2RvbV9iemltYWdlbG9hZGVyLmMKaW5kZXggOTg1MmU2Ny4uNzNj
ZmFkMSAxMDA2NDQKLS0tIGEvdG9vbHMvbGlieGMveGNfZG9tX2J6aW1hZ2Vs
b2FkZXIuYworKysgYi90b29scy9saWJ4Yy94Y19kb21fYnppbWFnZWxvYWRl
ci5jCkBAIC00NywxMyArNDcsMTkgQEAgc3RhdGljIGludCB4Y190cnlfYnpp
cDJfZGVjb2RlKAogICAgIGNoYXIgKm91dF9idWY7CiAgICAgY2hhciAqdG1w
X2J1ZjsKICAgICBpbnQgcmV0dmFsID0gLTE7Ci0gICAgaW50IG91dHNpemU7
CisgICAgdW5zaWduZWQgaW50IG91dHNpemU7CiAgICAgdWludDY0X3QgdG90
YWw7CiAKICAgICBzdHJlYW0uYnphbGxvYyA9IE5VTEw7CiAgICAgc3RyZWFt
LmJ6ZnJlZSA9IE5VTEw7CiAgICAgc3RyZWFtLm9wYXF1ZSA9IE5VTEw7CiAK
KyAgICBpZiAoIGRvbS0+a2VybmVsX3NpemUgPT0gMCkKKyAgICB7CisgICAg
ICAgIERPTVBSSU5URigiQlpJUDI6IElucHV0IGlzIDAgc2l6ZSIpOworICAg
ICAgICByZXR1cm4gLTE7CisgICAgfQorCiAgICAgcmV0ID0gQloyX2J6RGVj
b21wcmVzc0luaXQoJnN0cmVhbSwgMCwgMCk7CiAgICAgaWYgKCByZXQgIT0g
QlpfT0sgKQogICAgIHsKQEAgLTY2LDYgKzcyLDE3IEBAIHN0YXRpYyBpbnQg
eGNfdHJ5X2J6aXAyX2RlY29kZSgKICAgICAgKiB0aGUgaW5wdXQgYnVmZmVy
IHRvIHN0YXJ0LCBhbmQgd2UnbGwgcmVhbGxvYyBhcyBuZWVkZWQuCiAgICAg
ICovCiAgICAgb3V0c2l6ZSA9IGRvbS0+a2VybmVsX3NpemU7CisKKyAgICAv
KgorICAgICAqIHN0cmVhbS5hdmFpbF9pbiBhbmQgb3V0c2l6ZSBhcmUgdW5z
aWduZWQgaW50LCB3aGlsZSBrZXJuZWxfc2l6ZQorICAgICAqIGlzIGEgc2l6
ZV90LiBDaGVjayB3ZSBhcmVuJ3Qgb3ZlcmZsb3dpbmcuCisgICAgICovCisg
ICAgaWYgKCBvdXRzaXplICE9IGRvbS0+a2VybmVsX3NpemUgKQorICAgIHsK
KyAgICAgICAgRE9NUFJJTlRGKCJCWklQMjogSW5wdXQgdG9vIGxhcmdlIik7
CisgICAgICAgIGdvdG8gYnppcDJfY2xlYW51cDsKKyAgICB9CisKICAgICBv
dXRfYnVmID0gbWFsbG9jKG91dHNpemUpOwogICAgIGlmICggb3V0X2J1ZiA9
PSBOVUxMICkKICAgICB7CkBAIC05OCwxMyArMTE1LDIwIEBAIHN0YXRpYyBp
bnQgeGNfdHJ5X2J6aXAyX2RlY29kZSgKICAgICAgICAgaWYgKCBzdHJlYW0u
YXZhaWxfb3V0ID09IDAgKQogICAgICAgICB7CiAgICAgICAgICAgICAvKiBQ
cm90ZWN0IGFnYWluc3Qgb3V0cHV0IGJ1ZmZlciBvdmVyZmxvdyAqLwotICAg
ICAgICAgICAgaWYgKCBvdXRzaXplID4gSU5UX01BWCAvIDIgKQorICAgICAg
ICAgICAgaWYgKCBvdXRzaXplID4gVUlOVF9NQVggLyAyICkKICAgICAgICAg
ICAgIHsKICAgICAgICAgICAgICAgICBET01QUklOVEYoIkJaSVAyOiBvdXRw
dXQgYnVmZmVyIG92ZXJmbG93Iik7CiAgICAgICAgICAgICAgICAgZnJlZShv
dXRfYnVmKTsKICAgICAgICAgICAgICAgICBnb3RvIGJ6aXAyX2NsZWFudXA7
CiAgICAgICAgICAgICB9CiAKKyAgICAgICAgICAgIGlmICggeGNfZG9tX2tl
cm5lbF9jaGVja19zaXplKGRvbSwgb3V0c2l6ZSAqIDIpICkKKyAgICAgICAg
ICAgIHsKKyAgICAgICAgICAgICAgICBET01QUklOVEYoIkJaSVAyOiBvdXRw
dXQgdG9vIGxhcmdlIik7CisgICAgICAgICAgICAgICAgZnJlZShvdXRfYnVm
KTsKKyAgICAgICAgICAgICAgICBnb3RvIGJ6aXAyX2NsZWFudXA7CisgICAg
ICAgICAgICB9CisKICAgICAgICAgICAgIHRtcF9idWYgPSByZWFsbG9jKG91
dF9idWYsIG91dHNpemUgKiAyKTsKICAgICAgICAgICAgIGlmICggdG1wX2J1
ZiA9PSBOVUxMICkKICAgICAgICAgICAgIHsKQEAgLTE3Miw5ICsxOTYsMTUg
QEAgc3RhdGljIGludCB4Y190cnlfbHptYV9kZWNvZGUoCiAgICAgdW5zaWdu
ZWQgY2hhciAqb3V0X2J1ZjsKICAgICB1bnNpZ25lZCBjaGFyICp0bXBfYnVm
OwogICAgIGludCByZXR2YWwgPSAtMTsKLSAgICBpbnQgb3V0c2l6ZTsKKyAg
ICBzaXplX3Qgb3V0c2l6ZTsKICAgICBjb25zdCBjaGFyICptc2c7CiAKKyAg
ICBpZiAoIGRvbS0+a2VybmVsX3NpemUgPT0gMCkKKyAgICB7CisgICAgICAg
IERPTVBSSU5URigiTFpNQTogSW5wdXQgaXMgMCBzaXplIik7CisgICAgICAg
IHJldHVybiAtMTsKKyAgICB9CisKICAgICByZXQgPSBsem1hX2Fsb25lX2Rl
Y29kZXIoJnN0cmVhbSwgMTI4KjEwMjQqMTAyNCk7CiAgICAgaWYgKCByZXQg
IT0gTFpNQV9PSyApCiAgICAgewpAQCAtMjUxLDEzICsyODEsMjAgQEAgc3Rh
dGljIGludCB4Y190cnlfbHptYV9kZWNvZGUoCiAgICAgICAgIGlmICggc3Ry
ZWFtLmF2YWlsX291dCA9PSAwICkKICAgICAgICAgewogICAgICAgICAgICAg
LyogUHJvdGVjdCBhZ2FpbnN0IG91dHB1dCBidWZmZXIgb3ZlcmZsb3cgKi8K
LSAgICAgICAgICAgIGlmICggb3V0c2l6ZSA+IElOVF9NQVggLyAyICkKKyAg
ICAgICAgICAgIGlmICggb3V0c2l6ZSA+IFNJWkVfTUFYIC8gMiApCiAgICAg
ICAgICAgICB7CiAgICAgICAgICAgICAgICAgRE9NUFJJTlRGKCJMWk1BOiBv
dXRwdXQgYnVmZmVyIG92ZXJmbG93Iik7CiAgICAgICAgICAgICAgICAgZnJl
ZShvdXRfYnVmKTsKICAgICAgICAgICAgICAgICBnb3RvIGx6bWFfY2xlYW51
cDsKICAgICAgICAgICAgIH0KIAorICAgICAgICAgICAgaWYgKCB4Y19kb21f
a2VybmVsX2NoZWNrX3NpemUoZG9tLCBvdXRzaXplICogMikgKQorICAgICAg
ICAgICAgeworICAgICAgICAgICAgICAgIERPTVBSSU5URigiTFpNQTogb3V0
cHV0IHRvbyBsYXJnZSIpOworICAgICAgICAgICAgICAgIGZyZWUob3V0X2J1
Zik7CisgICAgICAgICAgICAgICAgZ290byBsem1hX2NsZWFudXA7CisgICAg
ICAgICAgICB9CisKICAgICAgICAgICAgIHRtcF9idWYgPSByZWFsbG9jKG91
dF9idWYsIG91dHNpemUgKiAyKTsKICAgICAgICAgICAgIGlmICggdG1wX2J1
ZiA9PSBOVUxMICkKICAgICAgICAgICAgIHsKQEAgLTMyNyw2ICszNjQsMTIg
QEAgc3RhdGljIGludCB4Y190cnlfbHpvMXhfZGVjb2RlKAogICAgICAgICAw
eDg5LCAweDRjLCAweDVhLCAweDRmLCAweDAwLCAweDBkLCAweDBhLCAweDFh
LCAweDBhCiAgICAgfTsKIAorICAgIC8qCisgICAgICogbHpvX3VpbnQgc2hv
dWxkIG1hdGNoIHNpemVfdC4gQ2hlY2sgdGhhdCB0aGlzIGlzIHRoZSBjYXNl
IHRvIGJlCisgICAgICogc3VyZSB3ZSB3b24ndCBvdmVyZmxvdyB2YXJpb3Vz
IGx6b191aW50IGZpZWxkcy4KKyAgICAgKi8KKyAgICBYQ19CVUlMRF9CVUdf
T04oc2l6ZW9mKGx6b191aW50KSAhPSBzaXplb2Yoc2l6ZV90KSk7CisKICAg
ICByZXQgPSBsem9faW5pdCgpOwogICAgIGlmICggcmV0ICE9IExaT19FX09L
ICkKICAgICB7CkBAIC00MDYsNiArNDQ5LDE0IEBAIHN0YXRpYyBpbnQgeGNf
dHJ5X2x6bzF4X2RlY29kZSgKICAgICAgICAgaWYgKCBzcmNfbGVuIDw9IDAg
fHwgc3JjX2xlbiA+IGRzdF9sZW4gfHwgc3JjX2xlbiA+IGxlZnQgKQogICAg
ICAgICAgICAgYnJlYWs7CiAKKyAgICAgICAgbXNnID0gIk91dHB1dCBidWZm
ZXIgb3ZlcmZsb3ciOworICAgICAgICBpZiAoICpzaXplID4gU0laRV9NQVgg
LSBkc3RfbGVuICkKKyAgICAgICAgICAgIGJyZWFrOworCisgICAgICAgIG1z
ZyA9ICJEZWNvbXByZXNzZWQgaW1hZ2UgdG9vIGxhcmdlIjsKKyAgICAgICAg
aWYgKCB4Y19kb21fa2VybmVsX2NoZWNrX3NpemUoZG9tLCAqc2l6ZSArIGRz
dF9sZW4pICkKKyAgICAgICAgICAgIGJyZWFrOworCiAgICAgICAgIG1zZyA9
ICJGYWlsZWQgdG8gKHJlKWFsbG9jIG1lbW9yeSI7CiAgICAgICAgIHRtcF9i
dWYgPSByZWFsbG9jKG91dF9idWYsICpzaXplICsgZHN0X2xlbik7CiAgICAg
ICAgIGlmICggdG1wX2J1ZiA9PSBOVUxMICkKZGlmZiAtLWdpdCBhL3Rvb2xz
L2xpYnhjL3hjX2RvbV9jb3JlLmMgYi90b29scy9saWJ4Yy94Y19kb21fY29y
ZS5jCmluZGV4IGZlYTlkZTUuLjJhMDFkN2MgMTAwNjQ0Ci0tLSBhL3Rvb2xz
L2xpYnhjL3hjX2RvbV9jb3JlLmMKKysrIGIvdG9vbHMvbGlieGMveGNfZG9t
X2NvcmUuYwpAQCAtMTU5LDcgKzE1OSw4IEBAIHZvaWQgKnhjX2RvbV9tYWxs
b2NfcGFnZV9hbGlnbmVkKHN0cnVjdCB4Y19kb21faW1hZ2UgKmRvbSwgc2l6
ZV90IHNpemUpCiB9CiAKIHZvaWQgKnhjX2RvbV9tYWxsb2NfZmlsZW1hcChz
dHJ1Y3QgeGNfZG9tX2ltYWdlICpkb20sCi0gICAgICAgICAgICAgICAgICAg
ICAgICAgICAgY29uc3QgY2hhciAqZmlsZW5hbWUsIHNpemVfdCAqIHNpemUp
CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgY2hhciAqZmls
ZW5hbWUsIHNpemVfdCAqIHNpemUsCisgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgY29uc3Qgc2l6ZV90IG1heF9zaXplKQogewogICAgIHN0cnVjdCB4
Y19kb21fbWVtICpibG9jayA9IE5VTEw7CiAgICAgaW50IGZkID0gLTE7CkBA
IC0xNzEsNiArMTcyLDEzIEBAIHZvaWQgKnhjX2RvbV9tYWxsb2NfZmlsZW1h
cChzdHJ1Y3QgeGNfZG9tX2ltYWdlICpkb20sCiAgICAgbHNlZWsoZmQsIDAs
IFNFRUtfU0VUKTsKICAgICAqc2l6ZSA9IGxzZWVrKGZkLCAwLCBTRUVLX0VO
RCk7CiAKKyAgICBpZiAoIG1heF9zaXplICYmICpzaXplID4gbWF4X3NpemUg
KQorICAgIHsKKyAgICAgICAgeGNfZG9tX3BhbmljKGRvbS0+eGNoLCBYQ19P
VVRfT0ZfTUVNT1JZLAorICAgICAgICAgICAgICAgICAgICAgInRyaWVkIHRv
IG1hcCBmaWxlIHdoaWNoIGlzIHRvbyBsYXJnZSIpOworICAgICAgICBnb3Rv
IGVycjsKKyAgICB9CisKICAgICBibG9jayA9IG1hbGxvYyhzaXplb2YoKmJs
b2NrKSk7CiAgICAgaWYgKCBibG9jayA9PSBOVUxMICkKICAgICAgICAgZ290
byBlcnI7CkBAIC0yMjIsNiArMjMwLDQwIEBAIGNoYXIgKnhjX2RvbV9zdHJk
dXAoc3RydWN0IHhjX2RvbV9pbWFnZSAqZG9tLCBjb25zdCBjaGFyICpzdHIp
CiB9CiAKIC8qIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAqLworLyog
ZGVjb21wcmVzc2lvbiBidWZmZXIgc2l6aW5nICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICovCitpbnQgeGNfZG9tX2tl
cm5lbF9jaGVja19zaXplKHN0cnVjdCB4Y19kb21faW1hZ2UgKmRvbSwgc2l6
ZV90IHN6KQoreworICAgIC8qIE5vIGxpbWl0ICovCisgICAgaWYgKCAhZG9t
LT5tYXhfa2VybmVsX3NpemUgKQorICAgICAgICByZXR1cm4gMDsKKworICAg
IGlmICggc3ogPiBkb20tPm1heF9rZXJuZWxfc2l6ZSApCisgICAgeworICAg
ICAgICB4Y19kb21fcGFuaWMoZG9tLT54Y2gsIFhDX0lOVkFMSURfS0VSTkVM
LAorICAgICAgICAgICAgICAgICAgICAgImtlcm5lbCBpbWFnZSB0b28gbGFy
Z2UiKTsKKyAgICAgICAgcmV0dXJuIDE7CisgICAgfQorCisgICAgcmV0dXJu
IDA7Cit9CisKK2ludCB4Y19kb21fcmFtZGlza19jaGVja19zaXplKHN0cnVj
dCB4Y19kb21faW1hZ2UgKmRvbSwgc2l6ZV90IHN6KQoreworICAgIC8qIE5v
IGxpbWl0ICovCisgICAgaWYgKCAhZG9tLT5tYXhfcmFtZGlza19zaXplICkK
KyAgICAgICAgcmV0dXJuIDA7CisKKyAgICBpZiAoIHN6ID4gZG9tLT5tYXhf
cmFtZGlza19zaXplICkKKyAgICB7CisgICAgICAgIHhjX2RvbV9wYW5pYyhk
b20tPnhjaCwgWENfSU5WQUxJRF9LRVJORUwsCisgICAgICAgICAgICAgICAg
ICAgICAicmFtZGlzayBpbWFnZSB0b28gbGFyZ2UiKTsKKyAgICAgICAgcmV0
dXJuIDE7CisgICAgfQorCisgICAgcmV0dXJuIDA7Cit9CisKKy8qIC0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAqLwogLyogcmVhZCBmaWxlcywgY29w
eSBtZW1vcnkgYmxvY2tzLCB3aXRoIHRyYW5zcGFyZW50IGd1bnppcCAgICAg
ICAgICAgICAgICAgICovCiAKIHNpemVfdCB4Y19kb21fY2hlY2tfZ3ppcCh4
Y19pbnRlcmZhY2UgKnhjaCwgdm9pZCAqYmxvYiwgc2l6ZV90IHppcGxlbikK
QEAgLTIzNSw3ICsyNzcsNyBAQCBzaXplX3QgeGNfZG9tX2NoZWNrX2d6aXAo
eGNfaW50ZXJmYWNlICp4Y2gsIHZvaWQgKmJsb2IsIHNpemVfdCB6aXBsZW4p
CiAKICAgICBnemxlbiA9IGJsb2IgKyB6aXBsZW4gLSA0OwogICAgIHVuemlw
bGVuID0gZ3psZW5bM10gPDwgMjQgfCBnemxlblsyXSA8PCAxNiB8IGd6bGVu
WzFdIDw8IDggfCBnemxlblswXTsKLSAgICBpZiAoICh1bnppcGxlbiA8IDAp
IHx8ICh1bnppcGxlbiA+ICgxMDI0KjEwMjQqMTAyNCkpICkgLyogMUdCIGxp
bWl0ICovCisgICAgaWYgKCAodW56aXBsZW4gPCAwKSB8fCAodW56aXBsZW4g
PiBYQ19ET01fREVDT01QUkVTU19NQVgpICkKICAgICB7CiAgICAgICAgIHhj
X2RvbV9wcmludGYKICAgICAgICAgICAgICh4Y2gsCkBAIC0yODgsNiArMzMw
LDkgQEAgaW50IHhjX2RvbV90cnlfZ3VuemlwKHN0cnVjdCB4Y19kb21faW1h
Z2UgKmRvbSwgdm9pZCAqKmJsb2IsIHNpemVfdCAqIHNpemUpCiAgICAgaWYg
KCB1bnppcGxlbiA9PSAwICkKICAgICAgICAgcmV0dXJuIDA7CiAKKyAgICBp
ZiAoIHhjX2RvbV9rZXJuZWxfY2hlY2tfc2l6ZShkb20sIHVuemlwbGVuKSAp
CisgICAgICAgIHJldHVybiAwOworCiAgICAgdW56aXAgPSB4Y19kb21fbWFs
bG9jKGRvbSwgdW56aXBsZW4pOwogICAgIGlmICggdW56aXAgPT0gTlVMTCAp
CiAgICAgICAgIHJldHVybiAtMTsKQEAgLTU4OCw2ICs2MzMsOSBAQCBzdHJ1
Y3QgeGNfZG9tX2ltYWdlICp4Y19kb21fYWxsb2NhdGUoeGNfaW50ZXJmYWNl
ICp4Y2gsCiAgICAgbWVtc2V0KGRvbSwgMCwgc2l6ZW9mKCpkb20pKTsKICAg
ICBkb20tPnhjaCA9IHhjaDsKIAorICAgIGRvbS0+bWF4X2tlcm5lbF9zaXpl
ID0gWENfRE9NX0RFQ09NUFJFU1NfTUFYOworICAgIGRvbS0+bWF4X3JhbWRp
c2tfc2l6ZSA9IFhDX0RPTV9ERUNPTVBSRVNTX01BWDsKKwogICAgIGlmICgg
Y21kbGluZSApCiAgICAgICAgIGRvbS0+Y21kbGluZSA9IHhjX2RvbV9zdHJk
dXAoZG9tLCBjbWRsaW5lKTsKICAgICBpZiAoIGZlYXR1cmVzICkKQEAgLTYw
OCwxMCArNjU2LDI1IEBAIHN0cnVjdCB4Y19kb21faW1hZ2UgKnhjX2RvbV9h
bGxvY2F0ZSh4Y19pbnRlcmZhY2UgKnhjaCwKICAgICByZXR1cm4gTlVMTDsK
IH0KIAoraW50IHhjX2RvbV9rZXJuZWxfbWF4X3NpemUoc3RydWN0IHhjX2Rv
bV9pbWFnZSAqZG9tLCBzaXplX3Qgc3opCit7CisgICAgRE9NUFJJTlRGKCIl
czoga2VybmVsX21heF9zaXplPSV6eCIsIF9fRlVOQ1RJT05fXywgc3opOwor
ICAgIGRvbS0+bWF4X2tlcm5lbF9zaXplID0gc3o7CisgICAgcmV0dXJuIDA7
Cit9CisKK2ludCB4Y19kb21fcmFtZGlza19tYXhfc2l6ZShzdHJ1Y3QgeGNf
ZG9tX2ltYWdlICpkb20sIHNpemVfdCBzeikKK3sKKyAgICBET01QUklOVEYo
IiVzOiByYW1kaXNrX21heF9zaXplPSV6eCIsIF9fRlVOQ1RJT05fXywgc3op
OworICAgIGRvbS0+bWF4X3JhbWRpc2tfc2l6ZSA9IHN6OworICAgIHJldHVy
biAwOworfQorCiBpbnQgeGNfZG9tX2tlcm5lbF9maWxlKHN0cnVjdCB4Y19k
b21faW1hZ2UgKmRvbSwgY29uc3QgY2hhciAqZmlsZW5hbWUpCiB7CiAgICAg
RE9NUFJJTlRGKCIlczogZmlsZW5hbWU9XCIlc1wiIiwgX19GVU5DVElPTl9f
LCBmaWxlbmFtZSk7Ci0gICAgZG9tLT5rZXJuZWxfYmxvYiA9IHhjX2RvbV9t
YWxsb2NfZmlsZW1hcChkb20sIGZpbGVuYW1lLCAmZG9tLT5rZXJuZWxfc2l6
ZSk7CisgICAgZG9tLT5rZXJuZWxfYmxvYiA9IHhjX2RvbV9tYWxsb2NfZmls
ZW1hcChkb20sIGZpbGVuYW1lLCAmZG9tLT5rZXJuZWxfc2l6ZSwKKyAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRvbS0+
bWF4X2tlcm5lbF9zaXplKTsKICAgICBpZiAoIGRvbS0+a2VybmVsX2Jsb2Ig
PT0gTlVMTCApCiAgICAgICAgIHJldHVybiAtMTsKICAgICByZXR1cm4geGNf
ZG9tX3RyeV9ndW56aXAoZG9tLCAmZG9tLT5rZXJuZWxfYmxvYiwgJmRvbS0+
a2VybmVsX3NpemUpOwpAQCAtNjIxLDcgKzY4NCw5IEBAIGludCB4Y19kb21f
cmFtZGlza19maWxlKHN0cnVjdCB4Y19kb21faW1hZ2UgKmRvbSwgY29uc3Qg
Y2hhciAqZmlsZW5hbWUpCiB7CiAgICAgRE9NUFJJTlRGKCIlczogZmlsZW5h
bWU9XCIlc1wiIiwgX19GVU5DVElPTl9fLCBmaWxlbmFtZSk7CiAgICAgZG9t
LT5yYW1kaXNrX2Jsb2IgPQotICAgICAgICB4Y19kb21fbWFsbG9jX2ZpbGVt
YXAoZG9tLCBmaWxlbmFtZSwgJmRvbS0+cmFtZGlza19zaXplKTsKKyAgICAg
ICAgeGNfZG9tX21hbGxvY19maWxlbWFwKGRvbSwgZmlsZW5hbWUsICZkb20t
PnJhbWRpc2tfc2l6ZSwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IGRvbS0+bWF4X3JhbWRpc2tfc2l6ZSk7CisKICAgICBpZiAoIGRvbS0+cmFt
ZGlza19ibG9iID09IE5VTEwgKQogICAgICAgICByZXR1cm4gLTE7CiAvLyAg
ICByZXR1cm4geGNfZG9tX3RyeV9ndW56aXAoZG9tLCAmZG9tLT5yYW1kaXNr
X2Jsb2IsICZkb20tPnJhbWRpc2tfc2l6ZSk7CkBAIC03ODEsNyArODQ2LDEx
IEBAIGludCB4Y19kb21fYnVpbGRfaW1hZ2Uoc3RydWN0IHhjX2RvbV9pbWFn
ZSAqZG9tKQogICAgICAgICB2b2lkICpyYW1kaXNrbWFwOwogCiAgICAgICAg
IHVuemlwbGVuID0geGNfZG9tX2NoZWNrX2d6aXAoZG9tLT54Y2gsIGRvbS0+
cmFtZGlza19ibG9iLCBkb20tPnJhbWRpc2tfc2l6ZSk7CisgICAgICAgIGlm
ICggeGNfZG9tX3JhbWRpc2tfY2hlY2tfc2l6ZShkb20sIHVuemlwbGVuKSAh
PSAwICkKKyAgICAgICAgICAgIHVuemlwbGVuID0gMDsKKwogICAgICAgICBy
YW1kaXNrbGVuID0gdW56aXBsZW4gPyB1bnppcGxlbiA6IGRvbS0+cmFtZGlz
a19zaXplOworCiAgICAgICAgIGlmICggeGNfZG9tX2FsbG9jX3NlZ21lbnQo
ZG9tLCAmZG9tLT5yYW1kaXNrX3NlZywgInJhbWRpc2siLCAwLAogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJhbWRpc2tsZW4pICE9IDAg
KQogICAgICAgICAgICAgZ290byBlcnI7CmRpZmYgLS1naXQgYS90b29scy9w
eWdydWIvc3JjL3B5Z3J1YiBiL3Rvb2xzL3B5Z3J1Yi9zcmMvcHlncnViCmlu
ZGV4IDE3YzAwODMuLjFhM2MxYzMgMTAwNjQ0Ci0tLSBhL3Rvb2xzL3B5Z3J1
Yi9zcmMvcHlncnViCisrKyBiL3Rvb2xzL3B5Z3J1Yi9zcmMvcHlncnViCkBA
IC0yOCw2ICsyOCw3IEBAIGltcG9ydCBncnViLkxpbG9Db25mCiBpbXBvcnQg
Z3J1Yi5FeHRMaW51eENvbmYKIAogUFlHUlVCX1ZFUiA9IDAuNgorRlNfUkVB
RF9NQVggPSAxMDI0ICogMTAyNAogCiBkZWYgZW5hYmxlX2N1cnNvcihpc29u
KToKICAgICBpZiBpc29uOgpAQCAtNDIxLDcgKzQyMiw4IEBAIGNsYXNzIEdy
dWI6CiAgICAgICAgIGlmIHNlbGYuX19kaWN0X18uZ2V0KCdjZicsIE5vbmUp
IGlzIE5vbmU6CiAgICAgICAgICAgICByYWlzZSBSdW50aW1lRXJyb3IsICJj
b3VsZG4ndCBmaW5kIGJvb3Rsb2FkZXIgY29uZmlnIGZpbGUgaW4gdGhlIGlt
YWdlIHByb3ZpZGVkLiIKICAgICAgICAgZiA9IGZzLm9wZW5fZmlsZShzZWxm
LmNmLmZpbGVuYW1lKQotICAgICAgICBidWYgPSBmLnJlYWQoKQorICAgICAg
ICAjIGxpbWl0IHJlYWQgc2l6ZSB0byBhdm9pZCBwYXRob2xvZ2ljYWwgY2Fz
ZXMKKyAgICAgICAgYnVmID0gZi5yZWFkKEZTX1JFQURfTUFYKQogICAgICAg
ICBkZWwgZgogICAgICAgICBzZWxmLmNmLnBhcnNlKGJ1ZikKIApAQCAtNjcw
LDYgKzY3MiwzNyBAQCBpZiBfX25hbWVfXyA9PSAiX19tYWluX18iOgogICAg
IGRlZiB1c2FnZSgpOgogICAgICAgICBwcmludCA+PiBzeXMuc3RkZXJyLCAi
VXNhZ2U6ICVzIFstcXwtLXF1aWV0XSBbLWl8LS1pbnRlcmFjdGl2ZV0gWy1u
fC0tbm90LXJlYWxseV0gWy0tb3V0cHV0PV0gWy0ta2VybmVsPV0gWy0tcmFt
ZGlzaz1dIFstLWFyZ3M9XSBbLS1lbnRyeT1dIFstLW91dHB1dC1kaXJlY3Rv
cnk9XSBbLS1vdXRwdXQtZm9ybWF0PXN4cHxzaW1wbGV8c2ltcGxlMF0gPGlt
YWdlPiIgJShzeXMuYXJndlswXSwpCiAKKyAgICBkZWYgY29weV9mcm9tX2lt
YWdlKGZzLCBmaWxlX3RvX3JlYWQsIGZpbGVfdHlwZSwgb3V0cHV0X2RpcmVj
dG9yeSwKKyAgICAgICAgICAgICAgICAgICAgICAgIG5vdF9yZWFsbHkpOgor
ICAgICAgICBpZiBub3RfcmVhbGx5OgorICAgICAgICAgICAgaWYgZnMuZmls
ZV9leGlzdHMoZmlsZV90b19yZWFkKToKKyAgICAgICAgICAgICAgICByZXR1
cm4gIjwlczolcz4iICUgKGZpbGVfdHlwZSwgZmlsZV90b19yZWFkKQorICAg
ICAgICAgICAgZWxzZToKKyAgICAgICAgICAgICAgICBzeXMuZXhpdCgiVGhl
IHJlcXVlc3RlZCAlcyBmaWxlIGRvZXMgbm90IGV4aXN0IiAlIGZpbGVfdHlw
ZSkKKyAgICAgICAgdHJ5OgorICAgICAgICAgICAgZGF0YWZpbGUgPSBmcy5v
cGVuX2ZpbGUoZmlsZV90b19yZWFkKQorICAgICAgICBleGNlcHQgRXhjZXB0
aW9uLCBlOgorICAgICAgICAgICAgcHJpbnQgPj5zeXMuc3RkZXJyLCBlCisg
ICAgICAgICAgICBzeXMuZXhpdCgiRXJyb3Igb3BlbmluZyAlcyBpbiBndWVz
dCIgJSBmaWxlX3RvX3JlYWQpCisgICAgICAgICh0ZmQsIHJldCkgPSB0ZW1w
ZmlsZS5ta3N0ZW1wKHByZWZpeD0iYm9vdF8iK2ZpbGVfdHlwZSsiLiIsCisg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRpcj1vdXRw
dXRfZGlyZWN0b3J5KQorICAgICAgICBkYXRhb2ZmID0gMAorICAgICAgICB3
aGlsZSBUcnVlOgorICAgICAgICAgICAgZGF0YSA9IGRhdGFmaWxlLnJlYWQo
RlNfUkVBRF9NQVgsIGRhdGFvZmYpCisgICAgICAgICAgICBpZiBsZW4oZGF0
YSkgPT0gMDoKKyAgICAgICAgICAgICAgICBvcy5jbG9zZSh0ZmQpCisgICAg
ICAgICAgICAgICAgZGVsIGRhdGFmaWxlCisgICAgICAgICAgICAgICAgcmV0
dXJuIHJldAorICAgICAgICAgICAgdHJ5OgorICAgICAgICAgICAgICAgIG9z
LndyaXRlKHRmZCwgZGF0YSkKKyAgICAgICAgICAgIGV4Y2VwdCBFeGNlcHRp
b24sIGU6CisgICAgICAgICAgICAgICAgcHJpbnQgPj5zeXMuc3RkZXJyLCBl
CisgICAgICAgICAgICAgICAgb3MuY2xvc2UodGZkKQorICAgICAgICAgICAg
ICAgIG9zLnVubGluayhyZXQpCisgICAgICAgICAgICAgICAgZGVsIGRhdGFm
aWxlCisgICAgICAgICAgICAgICAgc3lzLmV4aXQoIkVycm9yIHdyaXRpbmcg
dGVtcG9yYXJ5IGNvcHkgb2YgIitmaWxlX3R5cGUpCisgICAgICAgICAgICBk
YXRhb2ZmICs9IGxlbihkYXRhKQorCiAgICAgdHJ5OgogICAgICAgICBvcHRz
LCBhcmdzID0gZ2V0b3B0LmdudV9nZXRvcHQoc3lzLmFyZ3ZbMTpdLCAncWlu
aDo6JywKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWyJx
dWlldCIsICJpbnRlcmFjdGl2ZSIsICJub3QtcmVhbGx5IiwgImhlbHAiLCAK
QEAgLTc4NiwyNCArODE5LDE4IEBAIGlmIF9fbmFtZV9fID09ICJfX21haW5f
XyI6CiAgICAgaWYgbm90IGZzOgogICAgICAgICByYWlzZSBSdW50aW1lRXJy
b3IsICJVbmFibGUgdG8gZmluZCBwYXJ0aXRpb24gY29udGFpbmluZyBrZXJu
ZWwiCiAKLSAgICBpZiBub3RfcmVhbGx5OgotICAgICAgICBib290Y2ZnWyJr
ZXJuZWwiXSA9ICI8a2VybmVsOiVzPiIgJSBjaG9zZW5jZmdbImtlcm5lbCJd
Ci0gICAgZWxzZToKLSAgICAgICAgZGF0YSA9IGZzLm9wZW5fZmlsZShjaG9z
ZW5jZmdbImtlcm5lbCJdKS5yZWFkKCkKLSAgICAgICAgKHRmZCwgYm9vdGNm
Z1sia2VybmVsIl0pID0gdGVtcGZpbGUubWtzdGVtcChwcmVmaXg9ImJvb3Rf
a2VybmVsLiIsCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgZGlyPW91dHB1dF9kaXJlY3RvcnkpCi0gICAg
ICAgIG9zLndyaXRlKHRmZCwgZGF0YSkKLSAgICAgICAgb3MuY2xvc2UodGZk
KQorICAgIGJvb3RjZmdbImtlcm5lbCJdID0gY29weV9mcm9tX2ltYWdlKGZz
LCBjaG9zZW5jZmdbImtlcm5lbCJdLCAia2VybmVsIiwKKyAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBvdXRwdXRfZGlyZWN0b3J5
LCBub3RfcmVhbGx5KQogCiAgICAgaWYgY2hvc2VuY2ZnWyJyYW1kaXNrIl06
Ci0gICAgICAgIGlmIG5vdF9yZWFsbHk6Ci0gICAgICAgICAgICBib290Y2Zn
WyJyYW1kaXNrIl0gPSAiPHJhbWRpc2s6JXM+IiAlIGNob3NlbmNmZ1sicmFt
ZGlzayJdCi0gICAgICAgIGVsc2U6Ci0gICAgICAgICAgICBkYXRhID0gZnMu
b3Blbl9maWxlKGNob3NlbmNmZ1sicmFtZGlzayJdLCkucmVhZCgpCi0gICAg
ICAgICAgICAodGZkLCBib290Y2ZnWyJyYW1kaXNrIl0pID0gdGVtcGZpbGUu
bWtzdGVtcCgKLSAgICAgICAgICAgICAgICBwcmVmaXg9ImJvb3RfcmFtZGlz
ay4iLCBkaXI9b3V0cHV0X2RpcmVjdG9yeSkKLSAgICAgICAgICAgIG9zLndy
aXRlKHRmZCwgZGF0YSkKLSAgICAgICAgICAgIG9zLmNsb3NlKHRmZCkKKyAg
ICAgICAgdHJ5OgorICAgICAgICAgICAgYm9vdGNmZ1sicmFtZGlzayJdID0g
Y29weV9mcm9tX2ltYWdlKGZzLCBjaG9zZW5jZmdbInJhbWRpc2siXSwKKyAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAicmFtZGlzayIsIG91dHB1dF9kaXJlY3RvcnksCisgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbm90X3JlYWxs
eSkKKyAgICAgICAgZXhjZXB0OgorICAgICAgICAgICAgaWYgbm90IG5vdF9y
ZWFsbHk6CisgICAgICAgICAgICAgICAgb3MudW5saW5rKGJvb3RjZmdbImtl
cm5lbCJdKQorICAgICAgICAgICAgcmFpc2UKICAgICBlbHNlOgogICAgICAg
ICBpbml0cmQgPSBOb25lCiAK

--=separator
Content-Type: application/octet-stream; name="xsa25-4.2.patch"
Content-Disposition: attachment; filename="xsa25-4.2.patch"
Content-Transfer-Encoding: base64

bGlieGM6IGJ1aWxkZXI6IGxpbWl0IG1heGltdW0gc2l6ZSBvZiBrZXJuZWwv
cmFtZGlzay4KCkFsbG93aW5nIHVzZXIgc3VwcGxpZWQga2VybmVscyBvZiBh
cmJpdHJhcnkgc2l6ZXMsIGVzcGVjaWFsbHkgZHVyaW5nCmRlY29tcHJlc3Np
b24sIGNhbiBzd2FsbG93IHVwIGRvbTAgbWVtb3J5IGxlYWRpbmcgdG8gZWl0
aGVyIHZpcnR1YWwKYWRkcmVzcyBzcGFjZSBleGhhdXN0aW9uIGluIHRoZSBi
dWlsZGVyIHByb2Nlc3Mgb3IgYWxsb2NhdGlvbgpmYWlsdXJlcy9PT00ga2ls
bGluZyBvZiBib3RoIHRvb2xzdGFjayBhbmQgdW5yZWxhdGVkIHByb2Nlc3Nl
cy4KCldlIGRpc2FibGUgdGhlc2UgY2hlY2tzIHdoZW4gYnVpbGRpbmcgaW4g
YSBzdHViIGRvbWFpbiBmb3IgcHZncnViCnNpbmNlIHRoaXMgdXNlcyB0aGUg
Z3Vlc3QncyBvd24gbWVtb3J5IGFuZCBpcyBpc29sYXRlZC4KCkRlY29tcHJl
c3Npb24gb2YgZ3ppcCBjb21wcmVzc2VkIGtlcm5lbHMgYW5kIHJhbWRpc2tz
IGhhcyBiZWVuIHNhZmUKc2luY2UgMTQ5NTQ6NTgyMDUyNTc1MTdkIChYZW4g
My4xLjAgb253YXJkcykuCgpUaGlzIGlzIFhTQS0yNSAvIENWRS0yMDEyLTQ1
NDQuCgpBbHNvIG1ha2UgZXhwbGljaXQgY2hlY2tzIGZvciBidWZmZXIgb3Zl
cmZsb3dzIGluIHZhcmlvdXMKZGVjb21wcmVzc2lvbiByb3V0aW5lcy4gVGhl
c2Ugd2VyZSBhbHJlYWR5IHJ1bGVkIG91dCBkdWUgdG8gb3RoZXIKcHJvcGVy
dGllcyBvZiB0aGUgY29kZSBidXQgY2hlY2sgdGhlbSBhcyBhIGJlbHQtYW5k
LWJyYWNlcyBtZWFzdXJlLgoKU2lnbmVkLW9mZi1ieTogSWFuIENhbXBiZWxs
IDxpYW4uY2FtcGJlbGxAY2l0cml4LmNvbT4KQWNrZWQtYnk6IElhbiBKYWNr
c29uIDxpYW4uamFja3NvbkBldS5jaXRyaXguY29tPgoKZGlmZiAtLWdpdCBh
L3N0dWJkb20vZ3J1Yi9rZXhlYy5jIGIvc3R1YmRvbS9ncnViL2tleGVjLmMK
aW5kZXggMDZiZWY1Mi4uYjIxYzkxYSAxMDA2NDQKLS0tIGEvc3R1YmRvbS9n
cnViL2tleGVjLmMKKysrIGIvc3R1YmRvbS9ncnViL2tleGVjLmMKQEAgLTEz
Nyw2ICsxMzcsMTAgQEAgdm9pZCBrZXhlYyh2b2lkICprZXJuZWwsIGxvbmcg
a2VybmVsX3NpemUsIHZvaWQgKm1vZHVsZSwgbG9uZyBtb2R1bGVfc2l6ZSwg
Y2hhcgogICAgIGRvbSA9IHhjX2RvbV9hbGxvY2F0ZSh4Y19oYW5kbGUsIGNt
ZGxpbmUsIGZlYXR1cmVzKTsKICAgICBkb20tPmFsbG9jYXRlID0ga2V4ZWNf
YWxsb2NhdGU7CiAKKyAgICAvKiBXZSBhcmUgdXNpbmcgZ3Vlc3Qgb3duZWQg
bWVtb3J5LCB0aGVyZWZvcmUgbm8gbGltaXRzLiAqLworICAgIHhjX2RvbV9r
ZXJuZWxfbWF4X3NpemUoZG9tLCAwKTsKKyAgICB4Y19kb21fcmFtZGlza19t
YXhfc2l6ZShkb20sIDApOworCiAgICAgZG9tLT5rZXJuZWxfYmxvYiA9IGtl
cm5lbDsKICAgICBkb20tPmtlcm5lbF9zaXplID0ga2VybmVsX3NpemU7CiAK
ZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnhjL3hjX2RvbS5oIGIvdG9vbHMvbGli
eGMveGNfZG9tLmgKaW5kZXggMmFlZjY0YS4uNmE3MmFhOSAxMDA2NDQKLS0t
IGEvdG9vbHMvbGlieGMveGNfZG9tLmgKKysrIGIvdG9vbHMvbGlieGMveGNf
ZG9tLmgKQEAgLTU1LDYgKzU1LDkgQEAgc3RydWN0IHhjX2RvbV9pbWFnZSB7
CiAgICAgdm9pZCAqcmFtZGlza19ibG9iOwogICAgIHNpemVfdCByYW1kaXNr
X3NpemU7CiAKKyAgICBzaXplX3QgbWF4X2tlcm5lbF9zaXplOworICAgIHNp
emVfdCBtYXhfcmFtZGlza19zaXplOworCiAgICAgLyogYXJndW1lbnRzIGFu
ZCBwYXJhbWV0ZXJzICovCiAgICAgY2hhciAqY21kbGluZTsKICAgICB1aW50
MzJfdCBmX3JlcXVlc3RlZFtYRU5GRUFUX05SX1NVQk1BUFNdOwpAQCAtMTgw
LDYgKzE4MywyMyBAQCB2b2lkIHhjX2RvbV9yZWxlYXNlX3BoeXMoc3RydWN0
IHhjX2RvbV9pbWFnZSAqZG9tKTsKIHZvaWQgeGNfZG9tX3JlbGVhc2Uoc3Ry
dWN0IHhjX2RvbV9pbWFnZSAqZG9tKTsKIGludCB4Y19kb21fbWVtX2luaXQo
c3RydWN0IHhjX2RvbV9pbWFnZSAqZG9tLCB1bnNpZ25lZCBpbnQgbWVtX21i
KTsKIAorLyogU2V0IHRoaXMgbGFyZ2VyIGlmIHlvdSBoYXZlIGVub3Jtb3Vz
IHJhbWRpc2tzL2tlcm5lbHMuIE5vdGUgdGhhdAorICogeW91IHNob3VsZCB0
cnVzdCBhbGwga2VybmVscyBub3QgdG8gYmUgbWFsaWNpb3VzbHkgbGFyZ2Ug
KGUuZy4gdG8KKyAqIGV4aGF1c3QgYWxsIGRvbTAgbWVtb3J5KSBpZiB5b3Ug
ZG8gdGhpcyAoc2VlIENWRS0yMDEyLTQ1NDQgLworICogWFNBLTI1KS4gWW91
IGNhbiBhbHNvIHNldCB0aGUgZGVmYXVsdCBpbmRlcGVuZGVudGx5IGZvcgor
ICogcmFtZGlza3Mva2VybmVscyBpbiB4Y19kb21fYWxsb2NhdGUoKSBvciBj
YWxsCisgKiB4Y19kb21fe2tlcm5lbCxyYW1kaXNrfV9tYXhfc2l6ZS4KKyAq
LworI2lmbmRlZiBYQ19ET01fREVDT01QUkVTU19NQVgKKyNkZWZpbmUgWENf
RE9NX0RFQ09NUFJFU1NfTUFYICgxMDI0KjEwMjQqMTAyNCkgLyogMUdCICov
CisjZW5kaWYKKworaW50IHhjX2RvbV9rZXJuZWxfY2hlY2tfc2l6ZShzdHJ1
Y3QgeGNfZG9tX2ltYWdlICpkb20sIHNpemVfdCBzeik7CitpbnQgeGNfZG9t
X2tlcm5lbF9tYXhfc2l6ZShzdHJ1Y3QgeGNfZG9tX2ltYWdlICpkb20sIHNp
emVfdCBzeik7CisKK2ludCB4Y19kb21fcmFtZGlza19jaGVja19zaXplKHN0
cnVjdCB4Y19kb21faW1hZ2UgKmRvbSwgc2l6ZV90IHN6KTsKK2ludCB4Y19k
b21fcmFtZGlza19tYXhfc2l6ZShzdHJ1Y3QgeGNfZG9tX2ltYWdlICpkb20s
IHNpemVfdCBzeik7CisKIHNpemVfdCB4Y19kb21fY2hlY2tfZ3ppcCh4Y19p
bnRlcmZhY2UgKnhjaCwKICAgICAgICAgICAgICAgICAgICAgIHZvaWQgKmJs
b2IsIHNpemVfdCB6aXBsZW4pOwogaW50IHhjX2RvbV9kb19ndW56aXAoeGNf
aW50ZXJmYWNlICp4Y2gsCkBAIC0yNDAsNyArMjYwLDggQEAgdm9pZCB4Y19k
b21fbG9nX21lbW9yeV9mb290cHJpbnQoc3RydWN0IHhjX2RvbV9pbWFnZSAq
ZG9tKTsKIHZvaWQgKnhjX2RvbV9tYWxsb2Moc3RydWN0IHhjX2RvbV9pbWFn
ZSAqZG9tLCBzaXplX3Qgc2l6ZSk7CiB2b2lkICp4Y19kb21fbWFsbG9jX3Bh
Z2VfYWxpZ25lZChzdHJ1Y3QgeGNfZG9tX2ltYWdlICpkb20sIHNpemVfdCBz
aXplKTsKIHZvaWQgKnhjX2RvbV9tYWxsb2NfZmlsZW1hcChzdHJ1Y3QgeGNf
ZG9tX2ltYWdlICpkb20sCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAg
Y29uc3QgY2hhciAqZmlsZW5hbWUsIHNpemVfdCAqIHNpemUpOworICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IGNoYXIgKmZpbGVuYW1lLCBz
aXplX3QgKiBzaXplLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNv
bnN0IHNpemVfdCBtYXhfc2l6ZSk7CiBjaGFyICp4Y19kb21fc3RyZHVwKHN0
cnVjdCB4Y19kb21faW1hZ2UgKmRvbSwgY29uc3QgY2hhciAqc3RyKTsKIAog
LyogLS0tIGFsbG9jIG1lbW9yeSBwb29sIC0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gKi8KZGlmZiAtLWdpdCBhL3Rvb2xz
L2xpYnhjL3hjX2RvbV9iemltYWdlbG9hZGVyLmMgYi90b29scy9saWJ4Yy94
Y19kb21fYnppbWFnZWxvYWRlci5jCmluZGV4IDExM2Q0MGYuLmIxYjJlYjAg
MTAwNjQ0Ci0tLSBhL3Rvb2xzL2xpYnhjL3hjX2RvbV9iemltYWdlbG9hZGVy
LmMKKysrIGIvdG9vbHMvbGlieGMveGNfZG9tX2J6aW1hZ2Vsb2FkZXIuYwpA
QCAtNDcsMTMgKzQ3LDE5IEBAIHN0YXRpYyBpbnQgeGNfdHJ5X2J6aXAyX2Rl
Y29kZSgKICAgICBjaGFyICpvdXRfYnVmOwogICAgIGNoYXIgKnRtcF9idWY7
CiAgICAgaW50IHJldHZhbCA9IC0xOwotICAgIGludCBvdXRzaXplOworICAg
IHVuc2lnbmVkIGludCBvdXRzaXplOwogICAgIHVpbnQ2NF90IHRvdGFsOwog
CiAgICAgc3RyZWFtLmJ6YWxsb2MgPSBOVUxMOwogICAgIHN0cmVhbS5iemZy
ZWUgPSBOVUxMOwogICAgIHN0cmVhbS5vcGFxdWUgPSBOVUxMOwogCisgICAg
aWYgKCBkb20tPmtlcm5lbF9zaXplID09IDApCisgICAgeworICAgICAgICBE
T01QUklOVEYoIkJaSVAyOiBJbnB1dCBpcyAwIHNpemUiKTsKKyAgICAgICAg
cmV0dXJuIC0xOworICAgIH0KKwogICAgIHJldCA9IEJaMl9iekRlY29tcHJl
c3NJbml0KCZzdHJlYW0sIDAsIDApOwogICAgIGlmICggcmV0ICE9IEJaX09L
ICkKICAgICB7CkBAIC02Niw2ICs3MiwxNyBAQCBzdGF0aWMgaW50IHhjX3Ry
eV9iemlwMl9kZWNvZGUoCiAgICAgICogdGhlIGlucHV0IGJ1ZmZlciB0byBz
dGFydCwgYW5kIHdlJ2xsIHJlYWxsb2MgYXMgbmVlZGVkLgogICAgICAqLwog
ICAgIG91dHNpemUgPSBkb20tPmtlcm5lbF9zaXplOworCisgICAgLyoKKyAg
ICAgKiBzdHJlYW0uYXZhaWxfaW4gYW5kIG91dHNpemUgYXJlIHVuc2lnbmVk
IGludCwgd2hpbGUga2VybmVsX3NpemUKKyAgICAgKiBpcyBhIHNpemVfdC4g
Q2hlY2sgd2UgYXJlbid0IG92ZXJmbG93aW5nLgorICAgICAqLworICAgIGlm
ICggb3V0c2l6ZSAhPSBkb20tPmtlcm5lbF9zaXplICkKKyAgICB7CisgICAg
ICAgIERPTVBSSU5URigiQlpJUDI6IElucHV0IHRvbyBsYXJnZSIpOworICAg
ICAgICBnb3RvIGJ6aXAyX2NsZWFudXA7CisgICAgfQorCiAgICAgb3V0X2J1
ZiA9IG1hbGxvYyhvdXRzaXplKTsKICAgICBpZiAoIG91dF9idWYgPT0gTlVM
TCApCiAgICAgewpAQCAtOTgsMTMgKzExNSwyMCBAQCBzdGF0aWMgaW50IHhj
X3RyeV9iemlwMl9kZWNvZGUoCiAgICAgICAgIGlmICggc3RyZWFtLmF2YWls
X291dCA9PSAwICkKICAgICAgICAgewogICAgICAgICAgICAgLyogUHJvdGVj
dCBhZ2FpbnN0IG91dHB1dCBidWZmZXIgb3ZlcmZsb3cgKi8KLSAgICAgICAg
ICAgIGlmICggb3V0c2l6ZSA+IElOVF9NQVggLyAyICkKKyAgICAgICAgICAg
IGlmICggb3V0c2l6ZSA+IFVJTlRfTUFYIC8gMiApCiAgICAgICAgICAgICB7
CiAgICAgICAgICAgICAgICAgRE9NUFJJTlRGKCJCWklQMjogb3V0cHV0IGJ1
ZmZlciBvdmVyZmxvdyIpOwogICAgICAgICAgICAgICAgIGZyZWUob3V0X2J1
Zik7CiAgICAgICAgICAgICAgICAgZ290byBiemlwMl9jbGVhbnVwOwogICAg
ICAgICAgICAgfQogCisgICAgICAgICAgICBpZiAoIHhjX2RvbV9rZXJuZWxf
Y2hlY2tfc2l6ZShkb20sIG91dHNpemUgKiAyKSApCisgICAgICAgICAgICB7
CisgICAgICAgICAgICAgICAgRE9NUFJJTlRGKCJCWklQMjogb3V0cHV0IHRv
byBsYXJnZSIpOworICAgICAgICAgICAgICAgIGZyZWUob3V0X2J1Zik7Cisg
ICAgICAgICAgICAgICAgZ290byBiemlwMl9jbGVhbnVwOworICAgICAgICAg
ICAgfQorCiAgICAgICAgICAgICB0bXBfYnVmID0gcmVhbGxvYyhvdXRfYnVm
LCBvdXRzaXplICogMik7CiAgICAgICAgICAgICBpZiAoIHRtcF9idWYgPT0g
TlVMTCApCiAgICAgICAgICAgICB7CkBAIC0xNzIsOSArMTk2LDE1IEBAIHN0
YXRpYyBpbnQgX3hjX3RyeV9sem1hX2RlY29kZSgKICAgICB1bnNpZ25lZCBj
aGFyICpvdXRfYnVmOwogICAgIHVuc2lnbmVkIGNoYXIgKnRtcF9idWY7CiAg
ICAgaW50IHJldHZhbCA9IC0xOwotICAgIGludCBvdXRzaXplOworICAgIHNp
emVfdCBvdXRzaXplOwogICAgIGNvbnN0IGNoYXIgKm1zZzsKIAorICAgIGlm
ICggZG9tLT5rZXJuZWxfc2l6ZSA9PSAwKQorICAgIHsKKyAgICAgICAgRE9N
UFJJTlRGKCIlczogSW5wdXQgaXMgMCBzaXplIiwgd2hhdCk7CisgICAgICAg
IHJldHVybiAtMTsKKyAgICB9CisKICAgICAvKiBzaWdoLiAgV2UgZG9uJ3Qg
a25vdyB1cC1mcm9udCBob3cgbXVjaCBtZW1vcnkgd2UgYXJlIGdvaW5nIHRv
IG5lZWQKICAgICAgKiBmb3IgdGhlIG91dHB1dCBidWZmZXIuICBBbGxvY2F0
ZSB0aGUgb3V0cHV0IGJ1ZmZlciB0byBiZSBlcXVhbAogICAgICAqIHRoZSBp
bnB1dCBidWZmZXIgdG8gc3RhcnQsIGFuZCB3ZSdsbCByZWFsbG9jIGFzIG5l
ZWRlZC4KQEAgLTI0NCwxMyArMjc0LDIwIEBAIHN0YXRpYyBpbnQgX3hjX3Ry
eV9sem1hX2RlY29kZSgKICAgICAgICAgaWYgKCBzdHJlYW0tPmF2YWlsX291
dCA9PSAwICkKICAgICAgICAgewogICAgICAgICAgICAgLyogUHJvdGVjdCBh
Z2FpbnN0IG91dHB1dCBidWZmZXIgb3ZlcmZsb3cgKi8KLSAgICAgICAgICAg
IGlmICggb3V0c2l6ZSA+IElOVF9NQVggLyAyICkKKyAgICAgICAgICAgIGlm
ICggb3V0c2l6ZSA+IFNJWkVfTUFYIC8gMiApCiAgICAgICAgICAgICB7CiAg
ICAgICAgICAgICAgICAgRE9NUFJJTlRGKCIlczogb3V0cHV0IGJ1ZmZlciBv
dmVyZmxvdyIsIHdoYXQpOwogICAgICAgICAgICAgICAgIGZyZWUob3V0X2J1
Zik7CiAgICAgICAgICAgICAgICAgZ290byBsem1hX2NsZWFudXA7CiAgICAg
ICAgICAgICB9CiAKKyAgICAgICAgICAgIGlmICggeGNfZG9tX2tlcm5lbF9j
aGVja19zaXplKGRvbSwgb3V0c2l6ZSAqIDIpICkKKyAgICAgICAgICAgIHsK
KyAgICAgICAgICAgICAgICBET01QUklOVEYoIiVzOiBvdXRwdXQgdG9vIGxh
cmdlIiwgd2hhdCk7CisgICAgICAgICAgICAgICAgZnJlZShvdXRfYnVmKTsK
KyAgICAgICAgICAgICAgICBnb3RvIGx6bWFfY2xlYW51cDsKKyAgICAgICAg
ICAgIH0KKwogICAgICAgICAgICAgdG1wX2J1ZiA9IHJlYWxsb2Mob3V0X2J1
Ziwgb3V0c2l6ZSAqIDIpOwogICAgICAgICAgICAgaWYgKCB0bXBfYnVmID09
IE5VTEwgKQogICAgICAgICAgICAgewpAQCAtMzU5LDYgKzM5NiwxMiBAQCBz
dGF0aWMgaW50IHhjX3RyeV9sem8xeF9kZWNvZGUoCiAgICAgICAgIDB4ODks
IDB4NGMsIDB4NWEsIDB4NGYsIDB4MDAsIDB4MGQsIDB4MGEsIDB4MWEsIDB4
MGEKICAgICB9OwogCisgICAgLyoKKyAgICAgKiBsem9fdWludCBzaG91bGQg
bWF0Y2ggc2l6ZV90LiBDaGVjayB0aGF0IHRoaXMgaXMgdGhlIGNhc2UgdG8g
YmUKKyAgICAgKiBzdXJlIHdlIHdvbid0IG92ZXJmbG93IHZhcmlvdXMgbHpv
X3VpbnQgZmllbGRzLgorICAgICAqLworICAgIFhDX0JVSUxEX0JVR19PTihz
aXplb2YobHpvX3VpbnQpICE9IHNpemVvZihzaXplX3QpKTsKKwogICAgIHJl
dCA9IGx6b19pbml0KCk7CiAgICAgaWYgKCByZXQgIT0gTFpPX0VfT0sgKQog
ICAgIHsKQEAgLTQzOCw2ICs0ODEsMTQgQEAgc3RhdGljIGludCB4Y190cnlf
bHpvMXhfZGVjb2RlKAogICAgICAgICBpZiAoIHNyY19sZW4gPD0gMCB8fCBz
cmNfbGVuID4gZHN0X2xlbiB8fCBzcmNfbGVuID4gbGVmdCApCiAgICAgICAg
ICAgICBicmVhazsKIAorICAgICAgICBtc2cgPSAiT3V0cHV0IGJ1ZmZlciBv
dmVyZmxvdyI7CisgICAgICAgIGlmICggKnNpemUgPiBTSVpFX01BWCAtIGRz
dF9sZW4gKQorICAgICAgICAgICAgYnJlYWs7CisKKyAgICAgICAgbXNnID0g
IkRlY29tcHJlc3NlZCBpbWFnZSB0b28gbGFyZ2UiOworICAgICAgICBpZiAo
IHhjX2RvbV9rZXJuZWxfY2hlY2tfc2l6ZShkb20sICpzaXplICsgZHN0X2xl
bikgKQorICAgICAgICAgICAgYnJlYWs7CisKICAgICAgICAgbXNnID0gIkZh
aWxlZCB0byAocmUpYWxsb2MgbWVtb3J5IjsKICAgICAgICAgdG1wX2J1ZiA9
IHJlYWxsb2Mob3V0X2J1ZiwgKnNpemUgKyBkc3RfbGVuKTsKICAgICAgICAg
aWYgKCB0bXBfYnVmID09IE5VTEwgKQpkaWZmIC0tZ2l0IGEvdG9vbHMvbGli
eGMveGNfZG9tX2NvcmUuYyBiL3Rvb2xzL2xpYnhjL3hjX2RvbV9jb3JlLmMK
aW5kZXggZmVhOWRlNS4uMmEwMWQ3YyAxMDA2NDQKLS0tIGEvdG9vbHMvbGli
eGMveGNfZG9tX2NvcmUuYworKysgYi90b29scy9saWJ4Yy94Y19kb21fY29y
ZS5jCkBAIC0xNTksNyArMTU5LDggQEAgdm9pZCAqeGNfZG9tX21hbGxvY19w
YWdlX2FsaWduZWQoc3RydWN0IHhjX2RvbV9pbWFnZSAqZG9tLCBzaXplX3Qg
c2l6ZSkKIH0KIAogdm9pZCAqeGNfZG9tX21hbGxvY19maWxlbWFwKHN0cnVj
dCB4Y19kb21faW1hZ2UgKmRvbSwKLSAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBjb25zdCBjaGFyICpmaWxlbmFtZSwgc2l6ZV90ICogc2l6ZSkKKyAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCBjaGFyICpmaWxlbmFt
ZSwgc2l6ZV90ICogc2l6ZSwKKyAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBjb25zdCBzaXplX3QgbWF4X3NpemUpCiB7CiAgICAgc3RydWN0IHhjX2Rv
bV9tZW0gKmJsb2NrID0gTlVMTDsKICAgICBpbnQgZmQgPSAtMTsKQEAgLTE3
MSw2ICsxNzIsMTMgQEAgdm9pZCAqeGNfZG9tX21hbGxvY19maWxlbWFwKHN0
cnVjdCB4Y19kb21faW1hZ2UgKmRvbSwKICAgICBsc2VlayhmZCwgMCwgU0VF
S19TRVQpOwogICAgICpzaXplID0gbHNlZWsoZmQsIDAsIFNFRUtfRU5EKTsK
IAorICAgIGlmICggbWF4X3NpemUgJiYgKnNpemUgPiBtYXhfc2l6ZSApCisg
ICAgeworICAgICAgICB4Y19kb21fcGFuaWMoZG9tLT54Y2gsIFhDX09VVF9P
Rl9NRU1PUlksCisgICAgICAgICAgICAgICAgICAgICAidHJpZWQgdG8gbWFw
IGZpbGUgd2hpY2ggaXMgdG9vIGxhcmdlIik7CisgICAgICAgIGdvdG8gZXJy
OworICAgIH0KKwogICAgIGJsb2NrID0gbWFsbG9jKHNpemVvZigqYmxvY2sp
KTsKICAgICBpZiAoIGJsb2NrID09IE5VTEwgKQogICAgICAgICBnb3RvIGVy
cjsKQEAgLTIyMiw2ICsyMzAsNDAgQEAgY2hhciAqeGNfZG9tX3N0cmR1cChz
dHJ1Y3QgeGNfZG9tX2ltYWdlICpkb20sIGNvbnN0IGNoYXIgKnN0cikKIH0K
IAogLyogLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tICovCisvKiBkZWNv
bXByZXNzaW9uIGJ1ZmZlciBzaXppbmcgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgKi8KK2ludCB4Y19kb21fa2VybmVs
X2NoZWNrX3NpemUoc3RydWN0IHhjX2RvbV9pbWFnZSAqZG9tLCBzaXplX3Qg
c3opCit7CisgICAgLyogTm8gbGltaXQgKi8KKyAgICBpZiAoICFkb20tPm1h
eF9rZXJuZWxfc2l6ZSApCisgICAgICAgIHJldHVybiAwOworCisgICAgaWYg
KCBzeiA+IGRvbS0+bWF4X2tlcm5lbF9zaXplICkKKyAgICB7CisgICAgICAg
IHhjX2RvbV9wYW5pYyhkb20tPnhjaCwgWENfSU5WQUxJRF9LRVJORUwsCisg
ICAgICAgICAgICAgICAgICAgICAia2VybmVsIGltYWdlIHRvbyBsYXJnZSIp
OworICAgICAgICByZXR1cm4gMTsKKyAgICB9CisKKyAgICByZXR1cm4gMDsK
K30KKworaW50IHhjX2RvbV9yYW1kaXNrX2NoZWNrX3NpemUoc3RydWN0IHhj
X2RvbV9pbWFnZSAqZG9tLCBzaXplX3Qgc3opCit7CisgICAgLyogTm8gbGlt
aXQgKi8KKyAgICBpZiAoICFkb20tPm1heF9yYW1kaXNrX3NpemUgKQorICAg
ICAgICByZXR1cm4gMDsKKworICAgIGlmICggc3ogPiBkb20tPm1heF9yYW1k
aXNrX3NpemUgKQorICAgIHsKKyAgICAgICAgeGNfZG9tX3BhbmljKGRvbS0+
eGNoLCBYQ19JTlZBTElEX0tFUk5FTCwKKyAgICAgICAgICAgICAgICAgICAg
ICJyYW1kaXNrIGltYWdlIHRvbyBsYXJnZSIpOworICAgICAgICByZXR1cm4g
MTsKKyAgICB9CisKKyAgICByZXR1cm4gMDsKK30KKworLyogLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tICovCiAvKiByZWFkIGZpbGVzLCBjb3B5IG1l
bW9yeSBibG9ja3MsIHdpdGggdHJhbnNwYXJlbnQgZ3VuemlwICAgICAgICAg
ICAgICAgICAgKi8KIAogc2l6ZV90IHhjX2RvbV9jaGVja19nemlwKHhjX2lu
dGVyZmFjZSAqeGNoLCB2b2lkICpibG9iLCBzaXplX3QgemlwbGVuKQpAQCAt
MjM1LDcgKzI3Nyw3IEBAIHNpemVfdCB4Y19kb21fY2hlY2tfZ3ppcCh4Y19p
bnRlcmZhY2UgKnhjaCwgdm9pZCAqYmxvYiwgc2l6ZV90IHppcGxlbikKIAog
ICAgIGd6bGVuID0gYmxvYiArIHppcGxlbiAtIDQ7CiAgICAgdW56aXBsZW4g
PSBnemxlblszXSA8PCAyNCB8IGd6bGVuWzJdIDw8IDE2IHwgZ3psZW5bMV0g
PDwgOCB8IGd6bGVuWzBdOwotICAgIGlmICggKHVuemlwbGVuIDwgMCkgfHwg
KHVuemlwbGVuID4gKDEwMjQqMTAyNCoxMDI0KSkgKSAvKiAxR0IgbGltaXQg
Ki8KKyAgICBpZiAoICh1bnppcGxlbiA8IDApIHx8ICh1bnppcGxlbiA+IFhD
X0RPTV9ERUNPTVBSRVNTX01BWCkgKQogICAgIHsKICAgICAgICAgeGNfZG9t
X3ByaW50ZgogICAgICAgICAgICAgKHhjaCwKQEAgLTI4OCw2ICszMzAsOSBA
QCBpbnQgeGNfZG9tX3RyeV9ndW56aXAoc3RydWN0IHhjX2RvbV9pbWFnZSAq
ZG9tLCB2b2lkICoqYmxvYiwgc2l6ZV90ICogc2l6ZSkKICAgICBpZiAoIHVu
emlwbGVuID09IDAgKQogICAgICAgICByZXR1cm4gMDsKIAorICAgIGlmICgg
eGNfZG9tX2tlcm5lbF9jaGVja19zaXplKGRvbSwgdW56aXBsZW4pICkKKyAg
ICAgICAgcmV0dXJuIDA7CisKICAgICB1bnppcCA9IHhjX2RvbV9tYWxsb2Mo
ZG9tLCB1bnppcGxlbik7CiAgICAgaWYgKCB1bnppcCA9PSBOVUxMICkKICAg
ICAgICAgcmV0dXJuIC0xOwpAQCAtNTg4LDYgKzYzMyw5IEBAIHN0cnVjdCB4
Y19kb21faW1hZ2UgKnhjX2RvbV9hbGxvY2F0ZSh4Y19pbnRlcmZhY2UgKnhj
aCwKICAgICBtZW1zZXQoZG9tLCAwLCBzaXplb2YoKmRvbSkpOwogICAgIGRv
bS0+eGNoID0geGNoOwogCisgICAgZG9tLT5tYXhfa2VybmVsX3NpemUgPSBY
Q19ET01fREVDT01QUkVTU19NQVg7CisgICAgZG9tLT5tYXhfcmFtZGlza19z
aXplID0gWENfRE9NX0RFQ09NUFJFU1NfTUFYOworCiAgICAgaWYgKCBjbWRs
aW5lICkKICAgICAgICAgZG9tLT5jbWRsaW5lID0geGNfZG9tX3N0cmR1cChk
b20sIGNtZGxpbmUpOwogICAgIGlmICggZmVhdHVyZXMgKQpAQCAtNjA4LDEw
ICs2NTYsMjUgQEAgc3RydWN0IHhjX2RvbV9pbWFnZSAqeGNfZG9tX2FsbG9j
YXRlKHhjX2ludGVyZmFjZSAqeGNoLAogICAgIHJldHVybiBOVUxMOwogfQog
CitpbnQgeGNfZG9tX2tlcm5lbF9tYXhfc2l6ZShzdHJ1Y3QgeGNfZG9tX2lt
YWdlICpkb20sIHNpemVfdCBzeikKK3sKKyAgICBET01QUklOVEYoIiVzOiBr
ZXJuZWxfbWF4X3NpemU9JXp4IiwgX19GVU5DVElPTl9fLCBzeik7CisgICAg
ZG9tLT5tYXhfa2VybmVsX3NpemUgPSBzejsKKyAgICByZXR1cm4gMDsKK30K
KworaW50IHhjX2RvbV9yYW1kaXNrX21heF9zaXplKHN0cnVjdCB4Y19kb21f
aW1hZ2UgKmRvbSwgc2l6ZV90IHN6KQoreworICAgIERPTVBSSU5URigiJXM6
IHJhbWRpc2tfbWF4X3NpemU9JXp4IiwgX19GVU5DVElPTl9fLCBzeik7Cisg
ICAgZG9tLT5tYXhfcmFtZGlza19zaXplID0gc3o7CisgICAgcmV0dXJuIDA7
Cit9CisKIGludCB4Y19kb21fa2VybmVsX2ZpbGUoc3RydWN0IHhjX2RvbV9p
bWFnZSAqZG9tLCBjb25zdCBjaGFyICpmaWxlbmFtZSkKIHsKICAgICBET01Q
UklOVEYoIiVzOiBmaWxlbmFtZT1cIiVzXCIiLCBfX0ZVTkNUSU9OX18sIGZp
bGVuYW1lKTsKLSAgICBkb20tPmtlcm5lbF9ibG9iID0geGNfZG9tX21hbGxv
Y19maWxlbWFwKGRvbSwgZmlsZW5hbWUsICZkb20tPmtlcm5lbF9zaXplKTsK
KyAgICBkb20tPmtlcm5lbF9ibG9iID0geGNfZG9tX21hbGxvY19maWxlbWFw
KGRvbSwgZmlsZW5hbWUsICZkb20tPmtlcm5lbF9zaXplLAorICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZG9tLT5tYXhf
a2VybmVsX3NpemUpOwogICAgIGlmICggZG9tLT5rZXJuZWxfYmxvYiA9PSBO
VUxMICkKICAgICAgICAgcmV0dXJuIC0xOwogICAgIHJldHVybiB4Y19kb21f
dHJ5X2d1bnppcChkb20sICZkb20tPmtlcm5lbF9ibG9iLCAmZG9tLT5rZXJu
ZWxfc2l6ZSk7CkBAIC02MjEsNyArNjg0LDkgQEAgaW50IHhjX2RvbV9yYW1k
aXNrX2ZpbGUoc3RydWN0IHhjX2RvbV9pbWFnZSAqZG9tLCBjb25zdCBjaGFy
ICpmaWxlbmFtZSkKIHsKICAgICBET01QUklOVEYoIiVzOiBmaWxlbmFtZT1c
IiVzXCIiLCBfX0ZVTkNUSU9OX18sIGZpbGVuYW1lKTsKICAgICBkb20tPnJh
bWRpc2tfYmxvYiA9Ci0gICAgICAgIHhjX2RvbV9tYWxsb2NfZmlsZW1hcChk
b20sIGZpbGVuYW1lLCAmZG9tLT5yYW1kaXNrX3NpemUpOworICAgICAgICB4
Y19kb21fbWFsbG9jX2ZpbGVtYXAoZG9tLCBmaWxlbmFtZSwgJmRvbS0+cmFt
ZGlza19zaXplLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZG9t
LT5tYXhfcmFtZGlza19zaXplKTsKKwogICAgIGlmICggZG9tLT5yYW1kaXNr
X2Jsb2IgPT0gTlVMTCApCiAgICAgICAgIHJldHVybiAtMTsKIC8vICAgIHJl
dHVybiB4Y19kb21fdHJ5X2d1bnppcChkb20sICZkb20tPnJhbWRpc2tfYmxv
YiwgJmRvbS0+cmFtZGlza19zaXplKTsKQEAgLTc4MSw3ICs4NDYsMTEgQEAg
aW50IHhjX2RvbV9idWlsZF9pbWFnZShzdHJ1Y3QgeGNfZG9tX2ltYWdlICpk
b20pCiAgICAgICAgIHZvaWQgKnJhbWRpc2ttYXA7CiAKICAgICAgICAgdW56
aXBsZW4gPSB4Y19kb21fY2hlY2tfZ3ppcChkb20tPnhjaCwgZG9tLT5yYW1k
aXNrX2Jsb2IsIGRvbS0+cmFtZGlza19zaXplKTsKKyAgICAgICAgaWYgKCB4
Y19kb21fcmFtZGlza19jaGVja19zaXplKGRvbSwgdW56aXBsZW4pICE9IDAg
KQorICAgICAgICAgICAgdW56aXBsZW4gPSAwOworCiAgICAgICAgIHJhbWRp
c2tsZW4gPSB1bnppcGxlbiA/IHVuemlwbGVuIDogZG9tLT5yYW1kaXNrX3Np
emU7CisKICAgICAgICAgaWYgKCB4Y19kb21fYWxsb2Nfc2VnbWVudChkb20s
ICZkb20tPnJhbWRpc2tfc2VnLCAicmFtZGlzayIsIDAsCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgcmFtZGlza2xlbikgIT0gMCApCiAg
ICAgICAgICAgICBnb3RvIGVycjsK

--=separator
Content-Type: application/octet-stream; name="xsa25-unstable.patch"
Content-Disposition: attachment; filename="xsa25-unstable.patch"
Content-Transfer-Encoding: base64

bGlieGM6IGJ1aWxkZXI6IGxpbWl0IG1heGltdW0gc2l6ZSBvZiBrZXJuZWwv
cmFtZGlzay4KCkFsbG93aW5nIHVzZXIgc3VwcGxpZWQga2VybmVscyBvZiBh
cmJpdHJhcnkgc2l6ZXMsIGVzcGVjaWFsbHkgZHVyaW5nCmRlY29tcHJlc3Np
b24sIGNhbiBzd2FsbG93IHVwIGRvbTAgbWVtb3J5IGxlYWRpbmcgdG8gZWl0
aGVyIHZpcnR1YWwKYWRkcmVzcyBzcGFjZSBleGhhdXN0aW9uIGluIHRoZSBi
dWlsZGVyIHByb2Nlc3Mgb3IgYWxsb2NhdGlvbgpmYWlsdXJlcy9PT00ga2ls
bGluZyBvZiBib3RoIHRvb2xzdGFjayBhbmQgdW5yZWxhdGVkIHByb2Nlc3Nl
cy4KCldlIGRpc2FibGUgdGhlc2UgY2hlY2tzIHdoZW4gYnVpbGRpbmcgaW4g
YSBzdHViIGRvbWFpbiBmb3IgcHZncnViCnNpbmNlIHRoaXMgdXNlcyB0aGUg
Z3Vlc3QncyBvd24gbWVtb3J5IGFuZCBpcyBpc29sYXRlZC4KCkRlY29tcHJl
c3Npb24gb2YgZ3ppcCBjb21wcmVzc2VkIGtlcm5lbHMgYW5kIHJhbWRpc2tz
IGhhcyBiZWVuIHNhZmUKc2luY2UgMTQ5NTQ6NTgyMDUyNTc1MTdkIChYZW4g
My4xLjAgb253YXJkcykuCgpUaGlzIGlzIFhTQS0yNSAvIENWRS0yMDEyLTQ1
NDQuCgpBbHNvIG1ha2UgZXhwbGljaXQgY2hlY2tzIGZvciBidWZmZXIgb3Zl
cmZsb3dzIGluIHZhcmlvdXMKZGVjb21wcmVzc2lvbiByb3V0aW5lcy4gVGhl
c2Ugd2VyZSBhbHJlYWR5IHJ1bGVkIG91dCBkdWUgdG8gb3RoZXIKcHJvcGVy
dGllcyBvZiB0aGUgY29kZSBidXQgY2hlY2sgdGhlbSBhcyBhIGJlbHQtYW5k
LWJyYWNlcyBtZWFzdXJlLgoKU2lnbmVkLW9mZi1ieTogSWFuIENhbXBiZWxs
IDxpYW4uY2FtcGJlbGxAY2l0cml4LmNvbT4KQWNrZWQtYnk6IElhbiBKYWNr
c29uIDxpYW4uamFja3NvbkBldS5jaXRyaXguY29tPgoKZGlmZiAtciBiOWMx
ZTA4NmQ5YjcgLXIgODIzNDM1ODlhNzExIHN0dWJkb20vZ3J1Yi9rZXhlYy5j
Ci0tLSBhL3N0dWJkb20vZ3J1Yi9rZXhlYy5jCVdlZCBPY3QgMjQgMTU6NDk6
NDEgMjAxMiArMDEwMAorKysgYi9zdHViZG9tL2dydWIva2V4ZWMuYwlGcmkg
T2N0IDI2IDA5OjE5OjIyIDIwMTIgKzAxMDAKQEAgLTEzNyw2ICsxMzcsMTAg
QEAgdm9pZCBrZXhlYyh2b2lkICprZXJuZWwsIGxvbmcga2VybmVsX3Npegog
ICAgIGRvbSA9IHhjX2RvbV9hbGxvY2F0ZSh4Y19oYW5kbGUsIGNtZGxpbmUs
IGZlYXR1cmVzKTsKICAgICBkb20tPmFsbG9jYXRlID0ga2V4ZWNfYWxsb2Nh
dGU7CiAKKyAgICAvKiBXZSBhcmUgdXNpbmcgZ3Vlc3Qgb3duZWQgbWVtb3J5
LCB0aGVyZWZvcmUgbm8gbGltaXRzLiAqLworICAgIHhjX2RvbV9rZXJuZWxf
bWF4X3NpemUoZG9tLCAwKTsKKyAgICB4Y19kb21fcmFtZGlza19tYXhfc2l6
ZShkb20sIDApOworCiAgICAgZG9tLT5rZXJuZWxfYmxvYiA9IGtlcm5lbDsK
ICAgICBkb20tPmtlcm5lbF9zaXplID0ga2VybmVsX3NpemU7CiAKZGlmZiAt
ciBiOWMxZTA4NmQ5YjcgLXIgODIzNDM1ODlhNzExIHRvb2xzL2xpYnhjL3hj
X2RvbS5oCi0tLSBhL3Rvb2xzL2xpYnhjL3hjX2RvbS5oCVdlZCBPY3QgMjQg
MTU6NDk6NDEgMjAxMiArMDEwMAorKysgYi90b29scy9saWJ4Yy94Y19kb20u
aAlGcmkgT2N0IDI2IDA5OjE5OjIyIDIwMTIgKzAxMDAKQEAgLTU1LDYgKzU1
LDkgQEAgc3RydWN0IHhjX2RvbV9pbWFnZSB7CiAgICAgdm9pZCAqcmFtZGlz
a19ibG9iOwogICAgIHNpemVfdCByYW1kaXNrX3NpemU7CiAKKyAgICBzaXpl
X3QgbWF4X2tlcm5lbF9zaXplOworICAgIHNpemVfdCBtYXhfcmFtZGlza19z
aXplOworCiAgICAgLyogYXJndW1lbnRzIGFuZCBwYXJhbWV0ZXJzICovCiAg
ICAgY2hhciAqY21kbGluZTsKICAgICB1aW50MzJfdCBmX3JlcXVlc3RlZFtY
RU5GRUFUX05SX1NVQk1BUFNdOwpAQCAtMTk0LDYgKzE5NywyMyBAQCB2b2lk
IHhjX2RvbV9yZWxlYXNlX3BoeXMoc3RydWN0IHhjX2RvbV9pCiB2b2lkIHhj
X2RvbV9yZWxlYXNlKHN0cnVjdCB4Y19kb21faW1hZ2UgKmRvbSk7CiBpbnQg
eGNfZG9tX21lbV9pbml0KHN0cnVjdCB4Y19kb21faW1hZ2UgKmRvbSwgdW5z
aWduZWQgaW50IG1lbV9tYik7CiAKKy8qIFNldCB0aGlzIGxhcmdlciBpZiB5
b3UgaGF2ZSBlbm9ybW91cyByYW1kaXNrcy9rZXJuZWxzLiBOb3RlIHRoYXQK
KyAqIHlvdSBzaG91bGQgdHJ1c3QgYWxsIGtlcm5lbHMgbm90IHRvIGJlIG1h
bGljaW91c2x5IGxhcmdlIChlLmcuIHRvCisgKiBleGhhdXN0IGFsbCBkb20w
IG1lbW9yeSkgaWYgeW91IGRvIHRoaXMgKHNlZSBDVkUtMjAxMi00NTQ0IC8K
KyAqIFhTQS0yNSkuIFlvdSBjYW4gYWxzbyBzZXQgdGhlIGRlZmF1bHQgaW5k
ZXBlbmRlbnRseSBmb3IKKyAqIHJhbWRpc2tzL2tlcm5lbHMgaW4geGNfZG9t
X2FsbG9jYXRlKCkgb3IgY2FsbAorICogeGNfZG9tX3trZXJuZWwscmFtZGlz
a31fbWF4X3NpemUuCisgKi8KKyNpZm5kZWYgWENfRE9NX0RFQ09NUFJFU1Nf
TUFYCisjZGVmaW5lIFhDX0RPTV9ERUNPTVBSRVNTX01BWCAoMTAyNCoxMDI0
KjEwMjQpIC8qIDFHQiAqLworI2VuZGlmCisKK2ludCB4Y19kb21fa2VybmVs
X2NoZWNrX3NpemUoc3RydWN0IHhjX2RvbV9pbWFnZSAqZG9tLCBzaXplX3Qg
c3opOworaW50IHhjX2RvbV9rZXJuZWxfbWF4X3NpemUoc3RydWN0IHhjX2Rv
bV9pbWFnZSAqZG9tLCBzaXplX3Qgc3opOworCitpbnQgeGNfZG9tX3JhbWRp
c2tfY2hlY2tfc2l6ZShzdHJ1Y3QgeGNfZG9tX2ltYWdlICpkb20sIHNpemVf
dCBzeik7CitpbnQgeGNfZG9tX3JhbWRpc2tfbWF4X3NpemUoc3RydWN0IHhj
X2RvbV9pbWFnZSAqZG9tLCBzaXplX3Qgc3opOworCiBzaXplX3QgeGNfZG9t
X2NoZWNrX2d6aXAoeGNfaW50ZXJmYWNlICp4Y2gsCiAgICAgICAgICAgICAg
ICAgICAgICB2b2lkICpibG9iLCBzaXplX3QgemlwbGVuKTsKIGludCB4Y19k
b21fZG9fZ3VuemlwKHhjX2ludGVyZmFjZSAqeGNoLApAQCAtMjU0LDcgKzI3
NCw4IEBAIHZvaWQgeGNfZG9tX2xvZ19tZW1vcnlfZm9vdHByaW50KHN0cnVj
dCAKIHZvaWQgKnhjX2RvbV9tYWxsb2Moc3RydWN0IHhjX2RvbV9pbWFnZSAq
ZG9tLCBzaXplX3Qgc2l6ZSk7CiB2b2lkICp4Y19kb21fbWFsbG9jX3BhZ2Vf
YWxpZ25lZChzdHJ1Y3QgeGNfZG9tX2ltYWdlICpkb20sIHNpemVfdCBzaXpl
KTsKIHZvaWQgKnhjX2RvbV9tYWxsb2NfZmlsZW1hcChzdHJ1Y3QgeGNfZG9t
X2ltYWdlICpkb20sCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgY29u
c3QgY2hhciAqZmlsZW5hbWUsIHNpemVfdCAqIHNpemUpOworICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIGNvbnN0IGNoYXIgKmZpbGVuYW1lLCBzaXpl
X3QgKiBzaXplLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0
IHNpemVfdCBtYXhfc2l6ZSk7CiBjaGFyICp4Y19kb21fc3RyZHVwKHN0cnVj
dCB4Y19kb21faW1hZ2UgKmRvbSwgY29uc3QgY2hhciAqc3RyKTsKIAogLyog
LS0tIGFsbG9jIG1lbW9yeSBwb29sIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0gKi8KZGlmZiAtciBiOWMxZTA4NmQ5Yjcg
LXIgODIzNDM1ODlhNzExIHRvb2xzL2xpYnhjL3hjX2RvbV9iemltYWdlbG9h
ZGVyLmMKLS0tIGEvdG9vbHMvbGlieGMveGNfZG9tX2J6aW1hZ2Vsb2FkZXIu
YwlXZWQgT2N0IDI0IDE1OjQ5OjQxIDIwMTIgKzAxMDAKKysrIGIvdG9vbHMv
bGlieGMveGNfZG9tX2J6aW1hZ2Vsb2FkZXIuYwlGcmkgT2N0IDI2IDA5OjE5
OjIyIDIwMTIgKzAxMDAKQEAgLTQ3LDEzICs0NywxOSBAQCBzdGF0aWMgaW50
IHhjX3RyeV9iemlwMl9kZWNvZGUoCiAgICAgY2hhciAqb3V0X2J1ZjsKICAg
ICBjaGFyICp0bXBfYnVmOwogICAgIGludCByZXR2YWwgPSAtMTsKLSAgICBp
bnQgb3V0c2l6ZTsKKyAgICB1bnNpZ25lZCBpbnQgb3V0c2l6ZTsKICAgICB1
aW50NjRfdCB0b3RhbDsKIAogICAgIHN0cmVhbS5iemFsbG9jID0gTlVMTDsK
ICAgICBzdHJlYW0uYnpmcmVlID0gTlVMTDsKICAgICBzdHJlYW0ub3BhcXVl
ID0gTlVMTDsKIAorICAgIGlmICggZG9tLT5rZXJuZWxfc2l6ZSA9PSAwKQor
ICAgIHsKKyAgICAgICAgRE9NUFJJTlRGKCJCWklQMjogSW5wdXQgaXMgMCBz
aXplIik7CisgICAgICAgIHJldHVybiAtMTsKKyAgICB9CisKICAgICByZXQg
PSBCWjJfYnpEZWNvbXByZXNzSW5pdCgmc3RyZWFtLCAwLCAwKTsKICAgICBp
ZiAoIHJldCAhPSBCWl9PSyApCiAgICAgewpAQCAtNjYsNiArNzIsMTcgQEAg
c3RhdGljIGludCB4Y190cnlfYnppcDJfZGVjb2RlKAogICAgICAqIHRoZSBp
bnB1dCBidWZmZXIgdG8gc3RhcnQsIGFuZCB3ZSdsbCByZWFsbG9jIGFzIG5l
ZWRlZC4KICAgICAgKi8KICAgICBvdXRzaXplID0gZG9tLT5rZXJuZWxfc2l6
ZTsKKworICAgIC8qCisgICAgICogc3RyZWFtLmF2YWlsX2luIGFuZCBvdXRz
aXplIGFyZSB1bnNpZ25lZCBpbnQsIHdoaWxlIGtlcm5lbF9zaXplCisgICAg
ICogaXMgYSBzaXplX3QuIENoZWNrIHdlIGFyZW4ndCBvdmVyZmxvd2luZy4K
KyAgICAgKi8KKyAgICBpZiAoIG91dHNpemUgIT0gZG9tLT5rZXJuZWxfc2l6
ZSApCisgICAgeworICAgICAgICBET01QUklOVEYoIkJaSVAyOiBJbnB1dCB0
b28gbGFyZ2UiKTsKKyAgICAgICAgZ290byBiemlwMl9jbGVhbnVwOworICAg
IH0KKwogICAgIG91dF9idWYgPSBtYWxsb2Mob3V0c2l6ZSk7CiAgICAgaWYg
KCBvdXRfYnVmID09IE5VTEwgKQogICAgIHsKQEAgLTk4LDEzICsxMTUsMjAg
QEAgc3RhdGljIGludCB4Y190cnlfYnppcDJfZGVjb2RlKAogICAgICAgICBp
ZiAoIHN0cmVhbS5hdmFpbF9vdXQgPT0gMCApCiAgICAgICAgIHsKICAgICAg
ICAgICAgIC8qIFByb3RlY3QgYWdhaW5zdCBvdXRwdXQgYnVmZmVyIG92ZXJm
bG93ICovCi0gICAgICAgICAgICBpZiAoIG91dHNpemUgPiBJTlRfTUFYIC8g
MiApCisgICAgICAgICAgICBpZiAoIG91dHNpemUgPiBVSU5UX01BWCAvIDIg
KQogICAgICAgICAgICAgewogICAgICAgICAgICAgICAgIERPTVBSSU5URigi
QlpJUDI6IG91dHB1dCBidWZmZXIgb3ZlcmZsb3ciKTsKICAgICAgICAgICAg
ICAgICBmcmVlKG91dF9idWYpOwogICAgICAgICAgICAgICAgIGdvdG8gYnpp
cDJfY2xlYW51cDsKICAgICAgICAgICAgIH0KIAorICAgICAgICAgICAgaWYg
KCB4Y19kb21fa2VybmVsX2NoZWNrX3NpemUoZG9tLCBvdXRzaXplICogMikg
KQorICAgICAgICAgICAgeworICAgICAgICAgICAgICAgIERPTVBSSU5URigi
QlpJUDI6IG91dHB1dCB0b28gbGFyZ2UiKTsKKyAgICAgICAgICAgICAgICBm
cmVlKG91dF9idWYpOworICAgICAgICAgICAgICAgIGdvdG8gYnppcDJfY2xl
YW51cDsKKyAgICAgICAgICAgIH0KKwogICAgICAgICAgICAgdG1wX2J1ZiA9
IHJlYWxsb2Mob3V0X2J1Ziwgb3V0c2l6ZSAqIDIpOwogICAgICAgICAgICAg
aWYgKCB0bXBfYnVmID09IE5VTEwgKQogICAgICAgICAgICAgewpAQCAtMTcy
LDkgKzE5NiwxNSBAQCBzdGF0aWMgaW50IF94Y190cnlfbHptYV9kZWNvZGUo
CiAgICAgdW5zaWduZWQgY2hhciAqb3V0X2J1ZjsKICAgICB1bnNpZ25lZCBj
aGFyICp0bXBfYnVmOwogICAgIGludCByZXR2YWwgPSAtMTsKLSAgICBpbnQg
b3V0c2l6ZTsKKyAgICBzaXplX3Qgb3V0c2l6ZTsKICAgICBjb25zdCBjaGFy
ICptc2c7CiAKKyAgICBpZiAoIGRvbS0+a2VybmVsX3NpemUgPT0gMCkKKyAg
ICB7CisgICAgICAgIERPTVBSSU5URigiJXM6IElucHV0IGlzIDAgc2l6ZSIs
IHdoYXQpOworICAgICAgICByZXR1cm4gLTE7CisgICAgfQorCiAgICAgLyog
c2lnaC4gIFdlIGRvbid0IGtub3cgdXAtZnJvbnQgaG93IG11Y2ggbWVtb3J5
IHdlIGFyZSBnb2luZyB0byBuZWVkCiAgICAgICogZm9yIHRoZSBvdXRwdXQg
YnVmZmVyLiAgQWxsb2NhdGUgdGhlIG91dHB1dCBidWZmZXIgdG8gYmUgZXF1
YWwKICAgICAgKiB0aGUgaW5wdXQgYnVmZmVyIHRvIHN0YXJ0LCBhbmQgd2Un
bGwgcmVhbGxvYyBhcyBuZWVkZWQuCkBAIC0yNDQsMTMgKzI3NCwyMCBAQCBz
dGF0aWMgaW50IF94Y190cnlfbHptYV9kZWNvZGUoCiAgICAgICAgIGlmICgg
c3RyZWFtLT5hdmFpbF9vdXQgPT0gMCApCiAgICAgICAgIHsKICAgICAgICAg
ICAgIC8qIFByb3RlY3QgYWdhaW5zdCBvdXRwdXQgYnVmZmVyIG92ZXJmbG93
ICovCi0gICAgICAgICAgICBpZiAoIG91dHNpemUgPiBJTlRfTUFYIC8gMiAp
CisgICAgICAgICAgICBpZiAoIG91dHNpemUgPiBTSVpFX01BWCAvIDIgKQog
ICAgICAgICAgICAgewogICAgICAgICAgICAgICAgIERPTVBSSU5URigiJXM6
IG91dHB1dCBidWZmZXIgb3ZlcmZsb3ciLCB3aGF0KTsKICAgICAgICAgICAg
ICAgICBmcmVlKG91dF9idWYpOwogICAgICAgICAgICAgICAgIGdvdG8gbHpt
YV9jbGVhbnVwOwogICAgICAgICAgICAgfQogCisgICAgICAgICAgICBpZiAo
IHhjX2RvbV9rZXJuZWxfY2hlY2tfc2l6ZShkb20sIG91dHNpemUgKiAyKSAp
CisgICAgICAgICAgICB7CisgICAgICAgICAgICAgICAgRE9NUFJJTlRGKCIl
czogb3V0cHV0IHRvbyBsYXJnZSIsIHdoYXQpOworICAgICAgICAgICAgICAg
IGZyZWUob3V0X2J1Zik7CisgICAgICAgICAgICAgICAgZ290byBsem1hX2Ns
ZWFudXA7CisgICAgICAgICAgICB9CisKICAgICAgICAgICAgIHRtcF9idWYg
PSByZWFsbG9jKG91dF9idWYsIG91dHNpemUgKiAyKTsKICAgICAgICAgICAg
IGlmICggdG1wX2J1ZiA9PSBOVUxMICkKICAgICAgICAgICAgIHsKQEAgLTM1
OSw2ICszOTYsMTIgQEAgc3RhdGljIGludCB4Y190cnlfbHpvMXhfZGVjb2Rl
KAogICAgICAgICAweDg5LCAweDRjLCAweDVhLCAweDRmLCAweDAwLCAweDBk
LCAweDBhLCAweDFhLCAweDBhCiAgICAgfTsKIAorICAgIC8qCisgICAgICog
bHpvX3VpbnQgc2hvdWxkIG1hdGNoIHNpemVfdC4gQ2hlY2sgdGhhdCB0aGlz
IGlzIHRoZSBjYXNlIHRvIGJlCisgICAgICogc3VyZSB3ZSB3b24ndCBvdmVy
ZmxvdyB2YXJpb3VzIGx6b191aW50IGZpZWxkcy4KKyAgICAgKi8KKyAgICBY
Q19CVUlMRF9CVUdfT04oc2l6ZW9mKGx6b191aW50KSAhPSBzaXplb2Yoc2l6
ZV90KSk7CisKICAgICByZXQgPSBsem9faW5pdCgpOwogICAgIGlmICggcmV0
ICE9IExaT19FX09LICkKICAgICB7CkBAIC00MzgsNiArNDgxLDE0IEBAIHN0
YXRpYyBpbnQgeGNfdHJ5X2x6bzF4X2RlY29kZSgKICAgICAgICAgaWYgKCBz
cmNfbGVuIDw9IDAgfHwgc3JjX2xlbiA+IGRzdF9sZW4gfHwgc3JjX2xlbiA+
IGxlZnQgKQogICAgICAgICAgICAgYnJlYWs7CiAKKyAgICAgICAgbXNnID0g
Ik91dHB1dCBidWZmZXIgb3ZlcmZsb3ciOworICAgICAgICBpZiAoICpzaXpl
ID4gU0laRV9NQVggLSBkc3RfbGVuICkKKyAgICAgICAgICAgIGJyZWFrOwor
CisgICAgICAgIG1zZyA9ICJEZWNvbXByZXNzZWQgaW1hZ2UgdG9vIGxhcmdl
IjsKKyAgICAgICAgaWYgKCB4Y19kb21fa2VybmVsX2NoZWNrX3NpemUoZG9t
LCAqc2l6ZSArIGRzdF9sZW4pICkKKyAgICAgICAgICAgIGJyZWFrOworCiAg
ICAgICAgIG1zZyA9ICJGYWlsZWQgdG8gKHJlKWFsbG9jIG1lbW9yeSI7CiAg
ICAgICAgIHRtcF9idWYgPSByZWFsbG9jKG91dF9idWYsICpzaXplICsgZHN0
X2xlbik7CiAgICAgICAgIGlmICggdG1wX2J1ZiA9PSBOVUxMICkKZGlmZiAt
ciBiOWMxZTA4NmQ5YjcgLXIgODIzNDM1ODlhNzExIHRvb2xzL2xpYnhjL3hj
X2RvbV9jb3JlLmMKLS0tIGEvdG9vbHMvbGlieGMveGNfZG9tX2NvcmUuYwlX
ZWQgT2N0IDI0IDE1OjQ5OjQxIDIwMTIgKzAxMDAKKysrIGIvdG9vbHMvbGli
eGMveGNfZG9tX2NvcmUuYwlGcmkgT2N0IDI2IDA5OjE5OjIyIDIwMTIgKzAx
MDAKQEAgLTE1OSw3ICsxNTksOCBAQCB2b2lkICp4Y19kb21fbWFsbG9jX3Bh
Z2VfYWxpZ25lZChzdHJ1Y3QgCiB9CiAKIHZvaWQgKnhjX2RvbV9tYWxsb2Nf
ZmlsZW1hcChzdHJ1Y3QgeGNfZG9tX2ltYWdlICpkb20sCi0gICAgICAgICAg
ICAgICAgICAgICAgICAgICAgY29uc3QgY2hhciAqZmlsZW5hbWUsIHNpemVf
dCAqIHNpemUpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3Qg
Y2hhciAqZmlsZW5hbWUsIHNpemVfdCAqIHNpemUsCisgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgY29uc3Qgc2l6ZV90IG1heF9zaXplKQogewogICAg
IHN0cnVjdCB4Y19kb21fbWVtICpibG9jayA9IE5VTEw7CiAgICAgaW50IGZk
ID0gLTE7CkBAIC0xNzEsNiArMTcyLDEzIEBAIHZvaWQgKnhjX2RvbV9tYWxs
b2NfZmlsZW1hcChzdHJ1Y3QgeGNfZG8KICAgICBsc2VlayhmZCwgMCwgU0VF
S19TRVQpOwogICAgICpzaXplID0gbHNlZWsoZmQsIDAsIFNFRUtfRU5EKTsK
IAorICAgIGlmICggbWF4X3NpemUgJiYgKnNpemUgPiBtYXhfc2l6ZSApCisg
ICAgeworICAgICAgICB4Y19kb21fcGFuaWMoZG9tLT54Y2gsIFhDX09VVF9P
Rl9NRU1PUlksCisgICAgICAgICAgICAgICAgICAgICAidHJpZWQgdG8gbWFw
IGZpbGUgd2hpY2ggaXMgdG9vIGxhcmdlIik7CisgICAgICAgIGdvdG8gZXJy
OworICAgIH0KKwogICAgIGJsb2NrID0gbWFsbG9jKHNpemVvZigqYmxvY2sp
KTsKICAgICBpZiAoIGJsb2NrID09IE5VTEwgKQogICAgICAgICBnb3RvIGVy
cjsKQEAgLTIyMiw2ICsyMzAsNDAgQEAgY2hhciAqeGNfZG9tX3N0cmR1cChz
dHJ1Y3QgeGNfZG9tX2ltYWdlIAogfQogCiAvKiAtLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0gKi8KKy8qIGRlY29tcHJlc3Npb24gYnVmZmVyIHNpemlu
ZyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAqLworaW50IHhjX2RvbV9rZXJuZWxfY2hlY2tfc2l6ZShzdHJ1Y3QgeGNf
ZG9tX2ltYWdlICpkb20sIHNpemVfdCBzeikKK3sKKyAgICAvKiBObyBsaW1p
dCAqLworICAgIGlmICggIWRvbS0+bWF4X2tlcm5lbF9zaXplICkKKyAgICAg
ICAgcmV0dXJuIDA7CisKKyAgICBpZiAoIHN6ID4gZG9tLT5tYXhfa2VybmVs
X3NpemUgKQorICAgIHsKKyAgICAgICAgeGNfZG9tX3BhbmljKGRvbS0+eGNo
LCBYQ19JTlZBTElEX0tFUk5FTCwKKyAgICAgICAgICAgICAgICAgICAgICJr
ZXJuZWwgaW1hZ2UgdG9vIGxhcmdlIik7CisgICAgICAgIHJldHVybiAxOwor
ICAgIH0KKworICAgIHJldHVybiAwOworfQorCitpbnQgeGNfZG9tX3JhbWRp
c2tfY2hlY2tfc2l6ZShzdHJ1Y3QgeGNfZG9tX2ltYWdlICpkb20sIHNpemVf
dCBzeikKK3sKKyAgICAvKiBObyBsaW1pdCAqLworICAgIGlmICggIWRvbS0+
bWF4X3JhbWRpc2tfc2l6ZSApCisgICAgICAgIHJldHVybiAwOworCisgICAg
aWYgKCBzeiA+IGRvbS0+bWF4X3JhbWRpc2tfc2l6ZSApCisgICAgeworICAg
ICAgICB4Y19kb21fcGFuaWMoZG9tLT54Y2gsIFhDX0lOVkFMSURfS0VSTkVM
LAorICAgICAgICAgICAgICAgICAgICAgInJhbWRpc2sgaW1hZ2UgdG9vIGxh
cmdlIik7CisgICAgICAgIHJldHVybiAxOworICAgIH0KKworICAgIHJldHVy
biAwOworfQorCisvKiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gKi8K
IC8qIHJlYWQgZmlsZXMsIGNvcHkgbWVtb3J5IGJsb2Nrcywgd2l0aCB0cmFu
c3BhcmVudCBndW56aXAgICAgICAgICAgICAgICAgICAqLwogCiBzaXplX3Qg
eGNfZG9tX2NoZWNrX2d6aXAoeGNfaW50ZXJmYWNlICp4Y2gsIHZvaWQgKmJs
b2IsIHNpemVfdCB6aXBsZW4pCkBAIC0yMzUsNyArMjc3LDcgQEAgc2l6ZV90
IHhjX2RvbV9jaGVja19nemlwKHhjX2ludGVyZmFjZSAqeAogCiAgICAgZ3ps
ZW4gPSBibG9iICsgemlwbGVuIC0gNDsKICAgICB1bnppcGxlbiA9IGd6bGVu
WzNdIDw8IDI0IHwgZ3psZW5bMl0gPDwgMTYgfCBnemxlblsxXSA8PCA4IHwg
Z3psZW5bMF07Ci0gICAgaWYgKCAodW56aXBsZW4gPCAwKSB8fCAodW56aXBs
ZW4gPiAoMTAyNCoxMDI0KjEwMjQpKSApIC8qIDFHQiBsaW1pdCAqLworICAg
IGlmICggKHVuemlwbGVuIDwgMCkgfHwgKHVuemlwbGVuID4gWENfRE9NX0RF
Q09NUFJFU1NfTUFYKSApCiAgICAgewogICAgICAgICB4Y19kb21fcHJpbnRm
CiAgICAgICAgICAgICAoeGNoLApAQCAtMjg4LDYgKzMzMCw5IEBAIGludCB4
Y19kb21fdHJ5X2d1bnppcChzdHJ1Y3QgeGNfZG9tX2ltYWcKICAgICBpZiAo
IHVuemlwbGVuID09IDAgKQogICAgICAgICByZXR1cm4gMDsKIAorICAgIGlm
ICggeGNfZG9tX2tlcm5lbF9jaGVja19zaXplKGRvbSwgdW56aXBsZW4pICkK
KyAgICAgICAgcmV0dXJuIDA7CisKICAgICB1bnppcCA9IHhjX2RvbV9tYWxs
b2MoZG9tLCB1bnppcGxlbik7CiAgICAgaWYgKCB1bnppcCA9PSBOVUxMICkK
ICAgICAgICAgcmV0dXJuIC0xOwpAQCAtNTkwLDYgKzYzNSw5IEBAIHN0cnVj
dCB4Y19kb21faW1hZ2UgKnhjX2RvbV9hbGxvY2F0ZSh4Y18KICAgICBtZW1z
ZXQoZG9tLCAwLCBzaXplb2YoKmRvbSkpOwogICAgIGRvbS0+eGNoID0geGNo
OwogCisgICAgZG9tLT5tYXhfa2VybmVsX3NpemUgPSBYQ19ET01fREVDT01Q
UkVTU19NQVg7CisgICAgZG9tLT5tYXhfcmFtZGlza19zaXplID0gWENfRE9N
X0RFQ09NUFJFU1NfTUFYOworCiAgICAgaWYgKCBjbWRsaW5lICkKICAgICAg
ICAgZG9tLT5jbWRsaW5lID0geGNfZG9tX3N0cmR1cChkb20sIGNtZGxpbmUp
OwogICAgIGlmICggZmVhdHVyZXMgKQpAQCAtNjEwLDEwICs2NTgsMjUgQEAg
c3RydWN0IHhjX2RvbV9pbWFnZSAqeGNfZG9tX2FsbG9jYXRlKHhjXwogICAg
IHJldHVybiBOVUxMOwogfQogCitpbnQgeGNfZG9tX2tlcm5lbF9tYXhfc2l6
ZShzdHJ1Y3QgeGNfZG9tX2ltYWdlICpkb20sIHNpemVfdCBzeikKK3sKKyAg
ICBET01QUklOVEYoIiVzOiBrZXJuZWxfbWF4X3NpemU9JXp4IiwgX19GVU5D
VElPTl9fLCBzeik7CisgICAgZG9tLT5tYXhfa2VybmVsX3NpemUgPSBzejsK
KyAgICByZXR1cm4gMDsKK30KKworaW50IHhjX2RvbV9yYW1kaXNrX21heF9z
aXplKHN0cnVjdCB4Y19kb21faW1hZ2UgKmRvbSwgc2l6ZV90IHN6KQorewor
ICAgIERPTVBSSU5URigiJXM6IHJhbWRpc2tfbWF4X3NpemU9JXp4IiwgX19G
VU5DVElPTl9fLCBzeik7CisgICAgZG9tLT5tYXhfcmFtZGlza19zaXplID0g
c3o7CisgICAgcmV0dXJuIDA7Cit9CisKIGludCB4Y19kb21fa2VybmVsX2Zp
bGUoc3RydWN0IHhjX2RvbV9pbWFnZSAqZG9tLCBjb25zdCBjaGFyICpmaWxl
bmFtZSkKIHsKICAgICBET01QUklOVEYoIiVzOiBmaWxlbmFtZT1cIiVzXCIi
LCBfX0ZVTkNUSU9OX18sIGZpbGVuYW1lKTsKLSAgICBkb20tPmtlcm5lbF9i
bG9iID0geGNfZG9tX21hbGxvY19maWxlbWFwKGRvbSwgZmlsZW5hbWUsICZk
b20tPmtlcm5lbF9zaXplKTsKKyAgICBkb20tPmtlcm5lbF9ibG9iID0geGNf
ZG9tX21hbGxvY19maWxlbWFwKGRvbSwgZmlsZW5hbWUsICZkb20tPmtlcm5l
bF9zaXplLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgZG9tLT5tYXhfa2VybmVsX3NpemUpOwogICAgIGlmICggZG9t
LT5rZXJuZWxfYmxvYiA9PSBOVUxMICkKICAgICAgICAgcmV0dXJuIC0xOwog
ICAgIHJldHVybiB4Y19kb21fdHJ5X2d1bnppcChkb20sICZkb20tPmtlcm5l
bF9ibG9iLCAmZG9tLT5rZXJuZWxfc2l6ZSk7CkBAIC02MjMsNyArNjg2LDkg
QEAgaW50IHhjX2RvbV9yYW1kaXNrX2ZpbGUoc3RydWN0IHhjX2RvbV9pbQog
ewogICAgIERPTVBSSU5URigiJXM6IGZpbGVuYW1lPVwiJXNcIiIsIF9fRlVO
Q1RJT05fXywgZmlsZW5hbWUpOwogICAgIGRvbS0+cmFtZGlza19ibG9iID0K
LSAgICAgICAgeGNfZG9tX21hbGxvY19maWxlbWFwKGRvbSwgZmlsZW5hbWUs
ICZkb20tPnJhbWRpc2tfc2l6ZSk7CisgICAgICAgIHhjX2RvbV9tYWxsb2Nf
ZmlsZW1hcChkb20sIGZpbGVuYW1lLCAmZG9tLT5yYW1kaXNrX3NpemUsCisg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkb20tPm1heF9yYW1kaXNr
X3NpemUpOworCiAgICAgaWYgKCBkb20tPnJhbWRpc2tfYmxvYiA9PSBOVUxM
ICkKICAgICAgICAgcmV0dXJuIC0xOwogLy8gICAgcmV0dXJuIHhjX2RvbV90
cnlfZ3VuemlwKGRvbSwgJmRvbS0+cmFtZGlza19ibG9iLCAmZG9tLT5yYW1k
aXNrX3NpemUpOwpAQCAtNzgzLDcgKzg0OCwxMSBAQCBpbnQgeGNfZG9tX2J1
aWxkX2ltYWdlKHN0cnVjdCB4Y19kb21faW1hCiAgICAgICAgIHZvaWQgKnJh
bWRpc2ttYXA7CiAKICAgICAgICAgdW56aXBsZW4gPSB4Y19kb21fY2hlY2tf
Z3ppcChkb20tPnhjaCwgZG9tLT5yYW1kaXNrX2Jsb2IsIGRvbS0+cmFtZGlz
a19zaXplKTsKKyAgICAgICAgaWYgKCB4Y19kb21fcmFtZGlza19jaGVja19z
aXplKGRvbSwgdW56aXBsZW4pICE9IDAgKQorICAgICAgICAgICAgdW56aXBs
ZW4gPSAwOworCiAgICAgICAgIHJhbWRpc2tsZW4gPSB1bnppcGxlbiA/IHVu
emlwbGVuIDogZG9tLT5yYW1kaXNrX3NpemU7CisKICAgICAgICAgaWYgKCB4
Y19kb21fYWxsb2Nfc2VnbWVudChkb20sICZkb20tPnJhbWRpc2tfc2VnLCAi
cmFtZGlzayIsIDAsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgcmFtZGlza2xlbikgIT0gMCApCiAgICAgICAgICAgICBnb3RvIGVycjsK

--=separator
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=separator--


From xen-devel-bounces@lists.xen.org Fri Oct 26 11:04:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 11:04:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRhhm-0001tJ-Gt; Fri, 26 Oct 2012 11:03:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRhhl-0001t4-DJ
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 11:03:57 +0000
Received: from [85.158.143.99:12776] by server-3.bemta-4.messagelabs.com id
	2D/C4-24279-B1E6A805; Fri, 26 Oct 2012 11:03:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1351249434!26585412!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17142 invoked from network); 26 Oct 2012 11:03:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 11:03:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15407935"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 11:03:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 26 Oct 2012 12:03:54 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TRhhi-0006yr-8c; Fri, 26 Oct 2012 11:03:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TRhhi-00024h-5G;
	Fri, 26 Oct 2012 12:03:54 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20618.28185.826290.846793@mariner.uk.xensource.com>
Date: Fri, 26 Oct 2012 12:03:53 +0100
To: Ian Campbell 
Newsgroups: chiark.mail.xen.devel
In-Reply-To: 
References: 
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xl: Do not leak events when a domain exits
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[Xen-devel] [PATCH] xl: Do not leak events when a domain exits"):
> xl: Do not leak events when a domain exits.

My first attempt at committing this, 26109, was corrupted due to
leftover changes in my working tree.  I have reverted it and
recommitted a clean version.

Sorry.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 11:04:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 11:04:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRhhm-0001tJ-Gt; Fri, 26 Oct 2012 11:03:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRhhl-0001t4-DJ
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 11:03:57 +0000
Received: from [85.158.143.99:12776] by server-3.bemta-4.messagelabs.com id
	2D/C4-24279-B1E6A805; Fri, 26 Oct 2012 11:03:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1351249434!26585412!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17142 invoked from network); 26 Oct 2012 11:03:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 11:03:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15407935"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 11:03:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 26 Oct 2012 12:03:54 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TRhhi-0006yr-8c; Fri, 26 Oct 2012 11:03:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TRhhi-00024h-5G;
	Fri, 26 Oct 2012 12:03:54 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20618.28185.826290.846793@mariner.uk.xensource.com>
Date: Fri, 26 Oct 2012 12:03:53 +0100
To: Ian Campbell 
Newsgroups: chiark.mail.xen.devel
In-Reply-To: 
References: 
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xl: Do not leak events when a domain exits
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[Xen-devel] [PATCH] xl: Do not leak events when a domain exits"):
> xl: Do not leak events when a domain exits.

My first attempt at committing this, 26109, was corrupted due to
leftover changes in my working tree.  I have reverted it and
recommitted a clean version.

Sorry.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 11:05:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 11:05:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRhj5-00022N-11; Fri, 26 Oct 2012 11:05:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRhj3-000225-JK
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 11:05:17 +0000
Received: from [85.158.137.99:21004] by server-15.bemta-3.messagelabs.com id
	C3/60-09445-C6E6A805; Fri, 26 Oct 2012 11:05:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1351249514!23113228!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19971 invoked from network); 26 Oct 2012 11:05:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 11:05:15 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15407965"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 11:05:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 26 Oct 2012 12:05:14 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TRhj0-00072P-17; Fri, 26 Oct 2012 11:05:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TRhiz-00024r-U1;
	Fri, 26 Oct 2012 12:05:13 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20618.28265.830671.372037@mariner.uk.xensource.com>
Date: Fri, 26 Oct 2012 12:05:13 +0100
To: Charles Arnold 
In-Reply-To: <5089408D0200009100082462@novprvoes0310.provo.novell.com>
References: <50814E190200009100082117@novprvoes0310.provo.novell.com>
	<20617.21621.886298.796143@mariner.uk.xensource.com>
	<5089408D0200009100082462@novprvoes0310.provo.novell.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" ,
	Ian Jackson 
Subject: Re: [Xen-devel] [PATCH] pygrub: Add option to list grub entries
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Charles Arnold writes ("Re: [Xen-devel]  [PATCH] pygrub: Add option to list grub entries"):
> No, newlines in the menu.lst / grub.cfg files are treated as terminating
> characters for each entry option.  Nothing I've read in the grub specification
> indicates that the entries can be wrapped with an escaped newline character.
> My attempts to force a newline character in an entry always fails.  The
> parsing code in GrubConf.py splits the config file at all newlines.

Excellent, thanks for checking.

Acked-by: Ian Jackson 
Committed-by: Ian Jackson 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 11:05:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 11:05:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRhj5-00022N-11; Fri, 26 Oct 2012 11:05:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRhj3-000225-JK
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 11:05:17 +0000
Received: from [85.158.137.99:21004] by server-15.bemta-3.messagelabs.com id
	C3/60-09445-C6E6A805; Fri, 26 Oct 2012 11:05:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1351249514!23113228!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19971 invoked from network); 26 Oct 2012 11:05:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 11:05:15 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15407965"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 11:05:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 26 Oct 2012 12:05:14 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TRhj0-00072P-17; Fri, 26 Oct 2012 11:05:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TRhiz-00024r-U1;
	Fri, 26 Oct 2012 12:05:13 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20618.28265.830671.372037@mariner.uk.xensource.com>
Date: Fri, 26 Oct 2012 12:05:13 +0100
To: Charles Arnold 
In-Reply-To: <5089408D0200009100082462@novprvoes0310.provo.novell.com>
References: <50814E190200009100082117@novprvoes0310.provo.novell.com>
	<20617.21621.886298.796143@mariner.uk.xensource.com>
	<5089408D0200009100082462@novprvoes0310.provo.novell.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" ,
	Ian Jackson 
Subject: Re: [Xen-devel] [PATCH] pygrub: Add option to list grub entries
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Charles Arnold writes ("Re: [Xen-devel]  [PATCH] pygrub: Add option to list grub entries"):
> No, newlines in the menu.lst / grub.cfg files are treated as terminating
> characters for each entry option.  Nothing I've read in the grub specification
> indicates that the entries can be wrapped with an escaped newline character.
> My attempts to force a newline character in an entry always fails.  The
> parsing code in GrubConf.py splits the config file at all newlines.

Excellent, thanks for checking.

Acked-by: Ian Jackson 
Committed-by: Ian Jackson 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 11:09:49 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 11:09:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRhn8-0002RU-Ei; Fri, 26 Oct 2012 11:09:30 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRhn6-0002RF-Tt
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 11:09:29 +0000
Received: from [193.109.254.147:52616] by server-9.bemta-14.messagelabs.com id
	DF/80-30773-86F6A805; Fri, 26 Oct 2012 11:09:28 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1351249761!1681129!1
X-Originating-IP: [65.55.88.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26830 invoked from network); 26 Oct 2012 11:09:27 -0000
Received: from tx2ehsobe003.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.13)
	by server-14.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	26 Oct 2012 11:09:27 -0000
Received: from mail1-tx2-R.bigfish.com (10.9.14.245) by
	TX2EHSOBE013.bigfish.com (10.9.40.33) with Microsoft SMTP Server id
	14.1.225.23; Fri, 26 Oct 2012 11:09:16 +0000
Received: from mail1-tx2 (localhost [127.0.0.1])	by mail1-tx2-R.bigfish.com
	(Postfix) with ESMTP id 430402A01E0;
	Fri, 26 Oct 2012 11:09:16 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: -4
X-BigFish: VPS-4(zzbb2dI98dI936eI1432Izz1202h1d1ah1d2ahzz8275bhz2dh668h839h93fhd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h)
Received: from mail1-tx2 (localhost.localdomain [127.0.0.1]) by mail1-tx2
	(MessageSwitch) id 1351249753401190_32301;
	Fri, 26 Oct 2012 11:09:13 +0000 (UTC)
Received: from TX2EHSMHS025.bigfish.com (unknown [10.9.14.249])	by
	mail1-tx2.bigfish.com (Postfix) with ESMTP id 510F7160049;
	Fri, 26 Oct 2012 11:09:13 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS025.bigfish.com (10.9.99.125) with Microsoft SMTP Server id
	14.1.225.23; Fri, 26 Oct 2012 11:09:12 +0000
X-WSS-ID: 0MCHYZA-01-1LW-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2F2FA10280A3;	Fri, 26 Oct 2012 06:09:09 -0500 (CDT)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 26 Oct 2012 06:09:30 -0500
Received: from STOREXDAG04.amd.com (10.1.13.13) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Fri, 26 Oct 2012 06:09:10 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag04.amd.com
	(10.1.13.13) with Microsoft SMTP Server id 14.2.318.4; Fri, 26 Oct 2012
	07:09:09 -0400
Message-ID: <508A6F53.9000700@amd.com>
Date: Fri, 26 Oct 2012 13:09:07 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell 
References: <508916B3.2030403@amd.com>
	<20617.13045.486553.172990@mariner.uk.xensource.com>
	<508A5C38.4010609@amd.com>
	<1351246518.15162.23.camel@zakaz.uk.xensource.com>
In-Reply-To: <1351246518.15162.23.camel@zakaz.uk.xensource.com>
X-OriginatorOrg: amd.com
Cc: Ian Jackson ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] tools: use PREFIX when building upstream
 qemu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/26/12 12:15, Ian Campbell wrote:
> On Fri, 2012-10-26 at 10:47 +0100, Christoph Egger wrote:
>> On 10/25/12 14:39, Ian Jackson wrote:
>>> Christoph Egger writes ("[Xen-devel] [PATCH] tools: use PREFIX when building upstream qemu"):
>>>>
>>>> use PREFIX when building upstream qemu.
>>>>
>>>> Signed-off-by: Christoph Egger 
>>>
>>> This looks reasonable but can you explain what goes wrong when,
>>> without this ?  I'd like to be able to verify the bug and fix myself.
>>
>> qemu's configure assumes /usr/local as prefix by default, otherwise.
>> With this patch, qemu config files and manpages are installed under
>> the specified $(PREFIX).
> 
> Is that what we want?

Yes, we want everything that is not explicitely specified
to configure under $(PREFIX).

Christoph

> Or do we want our version of qemu to be
> under /usr/lib/xen?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 11:09:49 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 11:09:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRhn8-0002RU-Ei; Fri, 26 Oct 2012 11:09:30 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRhn6-0002RF-Tt
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 11:09:29 +0000
Received: from [193.109.254.147:52616] by server-9.bemta-14.messagelabs.com id
	DF/80-30773-86F6A805; Fri, 26 Oct 2012 11:09:28 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1351249761!1681129!1
X-Originating-IP: [65.55.88.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26830 invoked from network); 26 Oct 2012 11:09:27 -0000
Received: from tx2ehsobe003.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.13)
	by server-14.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	26 Oct 2012 11:09:27 -0000
Received: from mail1-tx2-R.bigfish.com (10.9.14.245) by
	TX2EHSOBE013.bigfish.com (10.9.40.33) with Microsoft SMTP Server id
	14.1.225.23; Fri, 26 Oct 2012 11:09:16 +0000
Received: from mail1-tx2 (localhost [127.0.0.1])	by mail1-tx2-R.bigfish.com
	(Postfix) with ESMTP id 430402A01E0;
	Fri, 26 Oct 2012 11:09:16 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: -4
X-BigFish: VPS-4(zzbb2dI98dI936eI1432Izz1202h1d1ah1d2ahzz8275bhz2dh668h839h93fhd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h)
Received: from mail1-tx2 (localhost.localdomain [127.0.0.1]) by mail1-tx2
	(MessageSwitch) id 1351249753401190_32301;
	Fri, 26 Oct 2012 11:09:13 +0000 (UTC)
Received: from TX2EHSMHS025.bigfish.com (unknown [10.9.14.249])	by
	mail1-tx2.bigfish.com (Postfix) with ESMTP id 510F7160049;
	Fri, 26 Oct 2012 11:09:13 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS025.bigfish.com (10.9.99.125) with Microsoft SMTP Server id
	14.1.225.23; Fri, 26 Oct 2012 11:09:12 +0000
X-WSS-ID: 0MCHYZA-01-1LW-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2F2FA10280A3;	Fri, 26 Oct 2012 06:09:09 -0500 (CDT)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 26 Oct 2012 06:09:30 -0500
Received: from STOREXDAG04.amd.com (10.1.13.13) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Fri, 26 Oct 2012 06:09:10 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag04.amd.com
	(10.1.13.13) with Microsoft SMTP Server id 14.2.318.4; Fri, 26 Oct 2012
	07:09:09 -0400
Message-ID: <508A6F53.9000700@amd.com>
Date: Fri, 26 Oct 2012 13:09:07 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell 
References: <508916B3.2030403@amd.com>
	<20617.13045.486553.172990@mariner.uk.xensource.com>
	<508A5C38.4010609@amd.com>
	<1351246518.15162.23.camel@zakaz.uk.xensource.com>
In-Reply-To: <1351246518.15162.23.camel@zakaz.uk.xensource.com>
X-OriginatorOrg: amd.com
Cc: Ian Jackson ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] tools: use PREFIX when building upstream
 qemu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/26/12 12:15, Ian Campbell wrote:
> On Fri, 2012-10-26 at 10:47 +0100, Christoph Egger wrote:
>> On 10/25/12 14:39, Ian Jackson wrote:
>>> Christoph Egger writes ("[Xen-devel] [PATCH] tools: use PREFIX when building upstream qemu"):
>>>>
>>>> use PREFIX when building upstream qemu.
>>>>
>>>> Signed-off-by: Christoph Egger 
>>>
>>> This looks reasonable but can you explain what goes wrong when,
>>> without this ?  I'd like to be able to verify the bug and fix myself.
>>
>> qemu's configure assumes /usr/local as prefix by default, otherwise.
>> With this patch, qemu config files and manpages are installed under
>> the specified $(PREFIX).
> 
> Is that what we want?

Yes, we want everything that is not explicitely specified
to configure under $(PREFIX).

Christoph

> Or do we want our version of qemu to be
> under /usr/lib/xen?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 11:15:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 11:15:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRhsP-0002mb-9T; Fri, 26 Oct 2012 11:14:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRhsN-0002mT-Jp
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 11:14:55 +0000
Received: from [85.158.139.83:45888] by server-15.bemta-5.messagelabs.com id
	A9/AD-26920-EA07A805; Fri, 26 Oct 2012 11:14:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1351250094!23572062!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30245 invoked from network); 26 Oct 2012 11:14:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 11:14:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15408231"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 11:14:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 12:14:54 +0100
Message-ID: <1351250092.15162.33.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Thanos Makatos 
Date: Fri, 26 Oct 2012 12:14:52 +0100
In-Reply-To: 
References: 
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 00 of 16 RFC] add libxl support for blktap3
 and introduce the blktap3 build system
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 18:02 +0100, Thanos Makatos wrote:
> This series introduces support for blktap3 in libxl and adds the basis of the
> blktap3 build system. There is no essential blktap3 functionality yet: all
> blktap3 functions are stubs and they will be implemented in later patches. This
> means that trying to use tap as the disk backend for a guest will make libxl
> complain since all of blktap3 functions return a failure error code. Most
> header files introduced in this series require some basic documentation.
> Finally, licenses need to be verified.

As it stands this series will break the build and/or xl functionality at
various points. I recommend ordering them as:
      * Stage 1: populate tools/blktap3, make it build with make -C
        tools/blktap3 (build breakage within tools/blktap3 doesn't
        matter during this stage)
      * Stage 2: connect tools/blktap3 to the top-level build system,
        but don't use it anywhere yet. At this point tools/blktap3 must
        compile successfully.
      * Third tranche: Patch libxl/xl etc to make them use blktap3
        instead of blktap2.

I'm also not convinced this pattern of adding dummy functions up front
and then switching them in with real implementations later is necessary
here. Sometimes that can be a useful technique for avoiding bisection
breakage but it doesn't seem like it should be needed if you follow
something like the staging proposal above.

I'm going to take a pass through the patches but I won't comment on
anything arising from either of the above.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 11:15:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 11:15:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRhsP-0002mb-9T; Fri, 26 Oct 2012 11:14:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRhsN-0002mT-Jp
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 11:14:55 +0000
Received: from [85.158.139.83:45888] by server-15.bemta-5.messagelabs.com id
	A9/AD-26920-EA07A805; Fri, 26 Oct 2012 11:14:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1351250094!23572062!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30245 invoked from network); 26 Oct 2012 11:14:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 11:14:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15408231"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 11:14:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 12:14:54 +0100
Message-ID: <1351250092.15162.33.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Thanos Makatos 
Date: Fri, 26 Oct 2012 12:14:52 +0100
In-Reply-To: 
References: 
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 00 of 16 RFC] add libxl support for blktap3
 and introduce the blktap3 build system
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 18:02 +0100, Thanos Makatos wrote:
> This series introduces support for blktap3 in libxl and adds the basis of the
> blktap3 build system. There is no essential blktap3 functionality yet: all
> blktap3 functions are stubs and they will be implemented in later patches. This
> means that trying to use tap as the disk backend for a guest will make libxl
> complain since all of blktap3 functions return a failure error code. Most
> header files introduced in this series require some basic documentation.
> Finally, licenses need to be verified.

As it stands this series will break the build and/or xl functionality at
various points. I recommend ordering them as:
      * Stage 1: populate tools/blktap3, make it build with make -C
        tools/blktap3 (build breakage within tools/blktap3 doesn't
        matter during this stage)
      * Stage 2: connect tools/blktap3 to the top-level build system,
        but don't use it anywhere yet. At this point tools/blktap3 must
        compile successfully.
      * Third tranche: Patch libxl/xl etc to make them use blktap3
        instead of blktap2.

I'm also not convinced this pattern of adding dummy functions up front
and then switching them in with real implementations later is necessary
here. Sometimes that can be a useful technique for avoiding bisection
breakage but it doesn't seem like it should be needed if you follow
something like the staging proposal above.

I'm going to take a pass through the patches but I won't comment on
anything arising from either of the above.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 11:18:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 11:18:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRhuZ-0002uP-QK; Fri, 26 Oct 2012 11:17:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRhuY-0002uI-P9
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 11:17:10 +0000
Received: from [85.158.139.83:63817] by server-4.bemta-5.messagelabs.com id
	5F/CD-01455-6317A805; Fri, 26 Oct 2012 11:17:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1351250229!27441179!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19559 invoked from network); 26 Oct 2012 11:17:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 11:17:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15408293"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 11:17:09 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 12:17:09 +0100
Message-ID: <1351250227.15162.36.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Thanos Makatos 
Date: Fri, 26 Oct 2012 12:17:07 +0100
In-Reply-To: 
References: 
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 01 of 16 RFC] blktap3: Introduce the blktap3
 device type
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 18:02 +0100, Thanos Makatos wrote:
> This device is used when tap is specifed as the disk backend, instead of vbd.
> 
> diff -r 3cd5bf62ded7 -r fef81de66bf7 tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c	Wed Oct 24 17:22:39 2012 +0100
> +++ b/tools/libxl/libxl.c	Wed Oct 24 17:24:01 2012 +0100
> @@ -1742,7 +1742,7 @@ int libxl__device_from_disk(libxl__gc *g
>              device->backend_kind = LIBXL__DEVICE_KIND_VBD;
>              break;
>          case LIBXL_DISK_BACKEND_TAP:
> -            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
> +            device->backend_kind = LIBXL__DEVICE_KIND_XENIO;

Presumably as well as this change a bunch of related infrastructure
changes are needed? I'd suggest putting all those first and making this
switch at the end, so that xl remains functional at each point in the
series.

>              break;
>          case LIBXL_DISK_BACKEND_QDISK:
>              device->backend_kind = LIBXL__DEVICE_KIND_QDISK;
> diff -r 3cd5bf62ded7 -r fef81de66bf7 tools/libxl/libxl_types_internal.idl
> --- a/tools/libxl/libxl_types_internal.idl	Wed Oct 24 17:22:39 2012 +0100
> +++ b/tools/libxl/libxl_types_internal.idl	Wed Oct 24 17:24:01 2012 +0100
> @@ -19,6 +19,7 @@ libxl__device_kind = Enumeration("device
>      (5, "VFB"),
>      (6, "VKBD"),
>      (7, "CONSOLE"),
> +    (8, "XENIO"),

I know this is what it is called internally but for libxl purposes can
we use BLKTAP or something descriptive like that?

>      ])
>  
>  libxl__console_backend = Enumeration("console_backend", [
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 11:18:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 11:18:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRhuZ-0002uP-QK; Fri, 26 Oct 2012 11:17:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRhuY-0002uI-P9
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 11:17:10 +0000
Received: from [85.158.139.83:63817] by server-4.bemta-5.messagelabs.com id
	5F/CD-01455-6317A805; Fri, 26 Oct 2012 11:17:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1351250229!27441179!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19559 invoked from network); 26 Oct 2012 11:17:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 11:17:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15408293"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 11:17:09 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 12:17:09 +0100
Message-ID: <1351250227.15162.36.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Thanos Makatos 
Date: Fri, 26 Oct 2012 12:17:07 +0100
In-Reply-To: 
References: 
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 01 of 16 RFC] blktap3: Introduce the blktap3
 device type
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 18:02 +0100, Thanos Makatos wrote:
> This device is used when tap is specifed as the disk backend, instead of vbd.
> 
> diff -r 3cd5bf62ded7 -r fef81de66bf7 tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c	Wed Oct 24 17:22:39 2012 +0100
> +++ b/tools/libxl/libxl.c	Wed Oct 24 17:24:01 2012 +0100
> @@ -1742,7 +1742,7 @@ int libxl__device_from_disk(libxl__gc *g
>              device->backend_kind = LIBXL__DEVICE_KIND_VBD;
>              break;
>          case LIBXL_DISK_BACKEND_TAP:
> -            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
> +            device->backend_kind = LIBXL__DEVICE_KIND_XENIO;

Presumably as well as this change a bunch of related infrastructure
changes are needed? I'd suggest putting all those first and making this
switch at the end, so that xl remains functional at each point in the
series.

>              break;
>          case LIBXL_DISK_BACKEND_QDISK:
>              device->backend_kind = LIBXL__DEVICE_KIND_QDISK;
> diff -r 3cd5bf62ded7 -r fef81de66bf7 tools/libxl/libxl_types_internal.idl
> --- a/tools/libxl/libxl_types_internal.idl	Wed Oct 24 17:22:39 2012 +0100
> +++ b/tools/libxl/libxl_types_internal.idl	Wed Oct 24 17:24:01 2012 +0100
> @@ -19,6 +19,7 @@ libxl__device_kind = Enumeration("device
>      (5, "VFB"),
>      (6, "VKBD"),
>      (7, "CONSOLE"),
> +    (8, "XENIO"),

I know this is what it is called internally but for libxl purposes can
we use BLKTAP or something descriptive like that?

>      ])
>  
>  libxl__console_backend = Enumeration("console_backend", [
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 11:19:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 11:19:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRhwc-00034G-At; Fri, 26 Oct 2012 11:19:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRhwb-000347-Bg
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 11:19:17 +0000
Received: from [85.158.143.99:23299] by server-1.bemta-4.messagelabs.com id
	76/97-19134-4B17A805; Fri, 26 Oct 2012 11:19:16 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1351250356!16288921!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8817 invoked from network); 26 Oct 2012 11:19:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 11:19:16 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15408343"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 11:19:15 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 26 Oct 2012 12:19:15 +0100
Date: Fri, 26 Oct 2012 12:18:44 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1351236618.8558.4.camel@dagon.hellion.org.uk>
Message-ID: 
References: 
	<1351091027-20740-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<1351159160.18035.147.camel@zakaz.uk.xensource.com>
	
	<1351236618.8558.4.camel@dagon.hellion.org.uk>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" , "Tim
	\(Xen.org\)" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 5/7] xen/arm: wake up secondary cpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 26 Oct 2012, Ian Campbell wrote:
> On Thu, 2012-10-25 at 18:45 +0100, Stefano Stabellini wrote:
> > > >  
> > > >  boot_cpu:
> > > > @@ -98,6 +98,10 @@ boot_cpu:
> > > >  	PRINT(" booting -\r\n")
> > > >  #endif
> > > >  
> > > > +	/* Wake up secondary cpus */
> > > > +	teq   r12, #0
> > > > +	bleq  kick_cpus
> > > 
> > > Does this have to be done this early? Couldn't we defer it to C land
> > > where it would be easier to isolate the processor/platform specific
> > > behaviour?
> > 
> > Yes, it does because we need to send an interrupt to cpus running in
> > secure mode, so this has to happen before we drop off secure state and we
> > enter hypervisor state.
> 
> Hrm, so maybe this stuff does belong in mode_switch.S after all?
> 
> Or is there perhaps some register (e.g. in the GIC?) which would allow
> non-secure hyp mode to sent an event to a processor in secure monitor
> mode?

Whether the target processor in secure mode receives the interrupt or
not, depends only on the GIC configuration on the target processor.
I don't think there is anything we can do from cpu0 in non-secure mode.


> Or are secondary CPUs actually spinning in secure supervisor mode?

Yes.


> I guess this works in Linux because the boot CPU is in *secure* kernel
> mode and that is allowed to send events to other secure modes? That's a
> further argument that this is related to the firmware not bringing us up
> in Hyp / NS mode and therefore that the fix should be in mode_switch.S.

That's right.


> > I have created a processor.S file for processor specific initializations
> > (see ACTLR), maybe I can move it there.
> 
> proc-ca15.S perhaps? So we can add proc-exynos.S etc in the future?
 
OK

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 11:19:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 11:19:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRhwc-00034G-At; Fri, 26 Oct 2012 11:19:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRhwb-000347-Bg
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 11:19:17 +0000
Received: from [85.158.143.99:23299] by server-1.bemta-4.messagelabs.com id
	76/97-19134-4B17A805; Fri, 26 Oct 2012 11:19:16 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1351250356!16288921!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8817 invoked from network); 26 Oct 2012 11:19:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 11:19:16 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15408343"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 11:19:15 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 26 Oct 2012 12:19:15 +0100
Date: Fri, 26 Oct 2012 12:18:44 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1351236618.8558.4.camel@dagon.hellion.org.uk>
Message-ID: 
References: 
	<1351091027-20740-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<1351159160.18035.147.camel@zakaz.uk.xensource.com>
	
	<1351236618.8558.4.camel@dagon.hellion.org.uk>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" , "Tim
	\(Xen.org\)" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 5/7] xen/arm: wake up secondary cpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 26 Oct 2012, Ian Campbell wrote:
> On Thu, 2012-10-25 at 18:45 +0100, Stefano Stabellini wrote:
> > > >  
> > > >  boot_cpu:
> > > > @@ -98,6 +98,10 @@ boot_cpu:
> > > >  	PRINT(" booting -\r\n")
> > > >  #endif
> > > >  
> > > > +	/* Wake up secondary cpus */
> > > > +	teq   r12, #0
> > > > +	bleq  kick_cpus
> > > 
> > > Does this have to be done this early? Couldn't we defer it to C land
> > > where it would be easier to isolate the processor/platform specific
> > > behaviour?
> > 
> > Yes, it does because we need to send an interrupt to cpus running in
> > secure mode, so this has to happen before we drop off secure state and we
> > enter hypervisor state.
> 
> Hrm, so maybe this stuff does belong in mode_switch.S after all?
> 
> Or is there perhaps some register (e.g. in the GIC?) which would allow
> non-secure hyp mode to sent an event to a processor in secure monitor
> mode?

Whether the target processor in secure mode receives the interrupt or
not, depends only on the GIC configuration on the target processor.
I don't think there is anything we can do from cpu0 in non-secure mode.


> Or are secondary CPUs actually spinning in secure supervisor mode?

Yes.


> I guess this works in Linux because the boot CPU is in *secure* kernel
> mode and that is allowed to send events to other secure modes? That's a
> further argument that this is related to the firmware not bringing us up
> in Hyp / NS mode and therefore that the fix should be in mode_switch.S.

That's right.


> > I have created a processor.S file for processor specific initializations
> > (see ACTLR), maybe I can move it there.
> 
> proc-ca15.S perhaps? So we can add proc-exynos.S etc in the future?
 
OK

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 11:19:34 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 11:19:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRhwi-000354-N1; Fri, 26 Oct 2012 11:19:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRhwh-00034m-C7
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 11:19:23 +0000
Received: from [85.158.139.83:19629] by server-7.bemta-5.messagelabs.com id
	FE/88-23102-AB17A805; Fri, 26 Oct 2012 11:19:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1351250361!26906600!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6327 invoked from network); 26 Oct 2012 11:19:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 11:19:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15408344"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 11:19:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 12:19:21 +0100
Message-ID: <1351250360.15162.38.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Thanos Makatos 
Date: Fri, 26 Oct 2012 12:19:20 +0100
In-Reply-To: <80e0bc67dcdaadc40d3a.1351098142@makatos-desktop>
References: 
	<80e0bc67dcdaadc40d3a.1351098142@makatos-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 03 of 16 RFC] blktap3: support for blktap3
 in libxl Makefile
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> diff -r 513739de43b5 -r 80e0bc67dcda tools/libxl/Makefile
> --- a/tools/libxl/Makefile	Wed Oct 24 17:24:37 2012 +0100
> +++ b/tools/libxl/Makefile	Wed Oct 24 17:24:53 2012 +0100
> @@ -20,7 +20,7 @@ LIBUUID_LIBS += -luuid
>  endif
>  
>  LIBXL_LIBS =
> -LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS)
> +LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS)

What happened to LDLIBS_libblktapctl here?

>  CFLAGS_LIBXL += $(CFLAGS_libxenctrl)
>  CFLAGS_LIBXL += $(CFLAGS_libxenguest)
> @@ -77,7 +77,8 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_c
>  			libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
>  LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
>  
> -$(LIBXL_OBJS): CFLAGS += $(CFLAGS_LIBXL) -include $(XEN_ROOT)/tools/config.h
> +$(LIBXL_OBJS): CFLAGS += $(CFLAGS_LIBXL) -include $(XEN_ROOT)/tools/config.h \
> +	$(CFLAGS_libblktapctl)

This Makefile already contains
CFLAGS_LIBXL += $(CFLAGS_libblktapctl) 
so I think this change is redundant (or else incomplete).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 11:19:34 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 11:19:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRhwi-000354-N1; Fri, 26 Oct 2012 11:19:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRhwh-00034m-C7
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 11:19:23 +0000
Received: from [85.158.139.83:19629] by server-7.bemta-5.messagelabs.com id
	FE/88-23102-AB17A805; Fri, 26 Oct 2012 11:19:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1351250361!26906600!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6327 invoked from network); 26 Oct 2012 11:19:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 11:19:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15408344"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 11:19:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 12:19:21 +0100
Message-ID: <1351250360.15162.38.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Thanos Makatos 
Date: Fri, 26 Oct 2012 12:19:20 +0100
In-Reply-To: <80e0bc67dcdaadc40d3a.1351098142@makatos-desktop>
References: 
	<80e0bc67dcdaadc40d3a.1351098142@makatos-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 03 of 16 RFC] blktap3: support for blktap3
 in libxl Makefile
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> diff -r 513739de43b5 -r 80e0bc67dcda tools/libxl/Makefile
> --- a/tools/libxl/Makefile	Wed Oct 24 17:24:37 2012 +0100
> +++ b/tools/libxl/Makefile	Wed Oct 24 17:24:53 2012 +0100
> @@ -20,7 +20,7 @@ LIBUUID_LIBS += -luuid
>  endif
>  
>  LIBXL_LIBS =
> -LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS)
> +LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS)

What happened to LDLIBS_libblktapctl here?

>  CFLAGS_LIBXL += $(CFLAGS_libxenctrl)
>  CFLAGS_LIBXL += $(CFLAGS_libxenguest)
> @@ -77,7 +77,8 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_c
>  			libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
>  LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
>  
> -$(LIBXL_OBJS): CFLAGS += $(CFLAGS_LIBXL) -include $(XEN_ROOT)/tools/config.h
> +$(LIBXL_OBJS): CFLAGS += $(CFLAGS_LIBXL) -include $(XEN_ROOT)/tools/config.h \
> +	$(CFLAGS_libblktapctl)

This Makefile already contains
CFLAGS_LIBXL += $(CFLAGS_libblktapctl) 
so I think this change is redundant (or else incomplete).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 11:21:57 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 11:21:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRhyz-0003Lq-8T; Fri, 26 Oct 2012 11:21:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRhyx-0003Le-IU
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 11:21:43 +0000
Received: from [85.158.139.211:41058] by server-11.bemta-5.messagelabs.com id
	F4/1E-14870-6427A805; Fri, 26 Oct 2012 11:21:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1351250502!22325044!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25660 invoked from network); 26 Oct 2012 11:21:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 11:21:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15408399"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 11:21:42 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 12:21:42 +0100
Message-ID: <1351250500.15162.40.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Thanos Makatos 
Date: Fri, 26 Oct 2012 12:21:40 +0100
In-Reply-To: 
References: 
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 04 of 16 RFC] blktap3: change
 libxl__blktap_devpath prototype to return an error code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 18:02 +0100, Thanos Makatos wrote:
> Make libxl__blktap_devpath return an error code instead of the device,
>  since there is no device in dom0 any more.

Does this function eventually go away then? Or will it eventually return
some sort of metadata which can be used to connect to the created tap
device?

>  Amend the libxl code that uses this functions accordingly.
> 
> diff -r 80e0bc67dcda -r bcb5a6182868 tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c	Wed Oct 24 17:24:53 2012 +0100
> +++ b/tools/libxl/libxl.c	Wed Oct 24 17:25:02 2012 +0100
> @@ -1844,13 +1844,14 @@ static void device_disk_add(libxl__egc *
>                  break;
>  
>              case LIBXL_DISK_BACKEND_TAP:
> -                dev = libxl__blktap_devpath(gc, disk->pdev_path, disk->format);
> -                if (!dev) {
> -                    LOG(ERROR, "failed to get blktap devpath for %p\n",
> -                        disk->pdev_path);
> +                rc = libxl__blktap_devpath(gc, disk->pdev_path, disk->format);
> +                if (rc) {
> +                    LOG(ERROR, "failed to get blktap devpath for %s: %s\n",
> +                        disk->pdev_path, strerror(rc));
>                      rc = ERROR_FAIL;
>                      goto out;
>                  }
> +                dev = NULL;
>                  flexarray_append(back, "tapdisk-params");
>                  flexarray_append(back, libxl__sprintf(gc, "%s:%s",
>                      libxl__device_disk_string_of_format(disk->format),
> @@ -2277,8 +2278,13 @@ void libxl__device_disk_local_initiate_a
>                  dev = disk->pdev_path;
>                  break;
>              case LIBXL_DISK_FORMAT_VHD:
> -                dev = libxl__blktap_devpath(gc, disk->pdev_path,
> -                                            disk->format);
> +                rc = libxl__blktap_devpath(gc, disk->pdev_path, disk->format);
> +                if (!rc) {
> +                    LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> +                           "error getting tapdisk: %s", strerror(rc));
> +                    rc = ERROR_FAIL;
> +                    goto out;
> +                }
>                  break;
>              case LIBXL_DISK_FORMAT_QCOW:
>              case LIBXL_DISK_FORMAT_QCOW2:
> diff -r 80e0bc67dcda -r bcb5a6182868 tools/libxl/libxl_blktap3.c
> --- a/tools/libxl/libxl_blktap3.c	Wed Oct 24 17:24:53 2012 +0100
> +++ b/tools/libxl/libxl_blktap3.c	Wed Oct 24 17:25:02 2012 +0100
> @@ -5,9 +5,9 @@ int libxl__blktap_enabled(libxl__gc *gc)
>      return 1;
>  }
>  
> -char *libxl__blktap_devpath(libxl__gc *gc, const char *disk,
> +int libxl__blktap_devpath(libxl__gc *gc, const char *disk,
>      libxl_disk_format format) {
> -    return NULL;
> +    return -ENOSYS;
>  }
>  
>  int libxl__device_destroy_tapdisk(libxl__gc *gc, const char *be_path) {
> diff -r 80e0bc67dcda -r bcb5a6182868 tools/libxl/libxl_internal.h
> --- a/tools/libxl/libxl_internal.h	Wed Oct 24 17:24:53 2012 +0100
> +++ b/tools/libxl/libxl_internal.h	Wed Oct 24 17:25:02 2012 +0100
> @@ -1344,10 +1344,9 @@ struct libxl__cpuid_policy {
>  /* libxl__blktap_devpath:
>   *    Argument: path and disk image as specified in config file.
>   *      The type specifies whether this is aio, qcow, qcow2, etc.
> - *    returns device path xenstore wants to have. returns NULL
> - *      if no device corresponds to the disk.
> + *    returns 0 on success, an error code otherwise 
>   */
> -_hidden char *libxl__blktap_devpath(libxl__gc *gc,
> +_hidden int libxl__blktap_devpath(libxl__gc *gc,
>                                      const char *disk,
>                                      libxl_disk_format format);
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 11:21:57 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 11:21:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRhyz-0003Lq-8T; Fri, 26 Oct 2012 11:21:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRhyx-0003Le-IU
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 11:21:43 +0000
Received: from [85.158.139.211:41058] by server-11.bemta-5.messagelabs.com id
	F4/1E-14870-6427A805; Fri, 26 Oct 2012 11:21:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1351250502!22325044!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25660 invoked from network); 26 Oct 2012 11:21:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 11:21:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15408399"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 11:21:42 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 12:21:42 +0100
Message-ID: <1351250500.15162.40.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Thanos Makatos 
Date: Fri, 26 Oct 2012 12:21:40 +0100
In-Reply-To: 
References: 
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 04 of 16 RFC] blktap3: change
 libxl__blktap_devpath prototype to return an error code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 18:02 +0100, Thanos Makatos wrote:
> Make libxl__blktap_devpath return an error code instead of the device,
>  since there is no device in dom0 any more.

Does this function eventually go away then? Or will it eventually return
some sort of metadata which can be used to connect to the created tap
device?

>  Amend the libxl code that uses this functions accordingly.
> 
> diff -r 80e0bc67dcda -r bcb5a6182868 tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c	Wed Oct 24 17:24:53 2012 +0100
> +++ b/tools/libxl/libxl.c	Wed Oct 24 17:25:02 2012 +0100
> @@ -1844,13 +1844,14 @@ static void device_disk_add(libxl__egc *
>                  break;
>  
>              case LIBXL_DISK_BACKEND_TAP:
> -                dev = libxl__blktap_devpath(gc, disk->pdev_path, disk->format);
> -                if (!dev) {
> -                    LOG(ERROR, "failed to get blktap devpath for %p\n",
> -                        disk->pdev_path);
> +                rc = libxl__blktap_devpath(gc, disk->pdev_path, disk->format);
> +                if (rc) {
> +                    LOG(ERROR, "failed to get blktap devpath for %s: %s\n",
> +                        disk->pdev_path, strerror(rc));
>                      rc = ERROR_FAIL;
>                      goto out;
>                  }
> +                dev = NULL;
>                  flexarray_append(back, "tapdisk-params");
>                  flexarray_append(back, libxl__sprintf(gc, "%s:%s",
>                      libxl__device_disk_string_of_format(disk->format),
> @@ -2277,8 +2278,13 @@ void libxl__device_disk_local_initiate_a
>                  dev = disk->pdev_path;
>                  break;
>              case LIBXL_DISK_FORMAT_VHD:
> -                dev = libxl__blktap_devpath(gc, disk->pdev_path,
> -                                            disk->format);
> +                rc = libxl__blktap_devpath(gc, disk->pdev_path, disk->format);
> +                if (!rc) {
> +                    LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> +                           "error getting tapdisk: %s", strerror(rc));
> +                    rc = ERROR_FAIL;
> +                    goto out;
> +                }
>                  break;
>              case LIBXL_DISK_FORMAT_QCOW:
>              case LIBXL_DISK_FORMAT_QCOW2:
> diff -r 80e0bc67dcda -r bcb5a6182868 tools/libxl/libxl_blktap3.c
> --- a/tools/libxl/libxl_blktap3.c	Wed Oct 24 17:24:53 2012 +0100
> +++ b/tools/libxl/libxl_blktap3.c	Wed Oct 24 17:25:02 2012 +0100
> @@ -5,9 +5,9 @@ int libxl__blktap_enabled(libxl__gc *gc)
>      return 1;
>  }
>  
> -char *libxl__blktap_devpath(libxl__gc *gc, const char *disk,
> +int libxl__blktap_devpath(libxl__gc *gc, const char *disk,
>      libxl_disk_format format) {
> -    return NULL;
> +    return -ENOSYS;
>  }
>  
>  int libxl__device_destroy_tapdisk(libxl__gc *gc, const char *be_path) {
> diff -r 80e0bc67dcda -r bcb5a6182868 tools/libxl/libxl_internal.h
> --- a/tools/libxl/libxl_internal.h	Wed Oct 24 17:24:53 2012 +0100
> +++ b/tools/libxl/libxl_internal.h	Wed Oct 24 17:25:02 2012 +0100
> @@ -1344,10 +1344,9 @@ struct libxl__cpuid_policy {
>  /* libxl__blktap_devpath:
>   *    Argument: path and disk image as specified in config file.
>   *      The type specifies whether this is aio, qcow, qcow2, etc.
> - *    returns device path xenstore wants to have. returns NULL
> - *      if no device corresponds to the disk.
> + *    returns 0 on success, an error code otherwise 
>   */
> -_hidden char *libxl__blktap_devpath(libxl__gc *gc,
> +_hidden int libxl__blktap_devpath(libxl__gc *gc,
>                                      const char *disk,
>                                      libxl_disk_format format);
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 11:24:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 11:24:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRi0z-0003ZE-U2; Fri, 26 Oct 2012 11:23:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRi0y-0003Z4-NQ
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 11:23:48 +0000
Received: from [85.158.137.99:18817] by server-7.bemta-3.messagelabs.com id
	03/7D-06991-3C27A805; Fri, 26 Oct 2012 11:23:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1351250627!20779124!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18299 invoked from network); 26 Oct 2012 11:23:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 11:23:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15408444"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 11:23:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 12:23:47 +0100
Message-ID: <1351250625.15162.42.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Thanos Makatos 
Date: Fri, 26 Oct 2012 12:23:45 +0100
In-Reply-To: <57896068356d4870c74a.1351098144@makatos-desktop>
References: 
	<57896068356d4870c74a.1351098144@makatos-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 05 of 16 RFC] blktap3: Don't check if blktap
 is available
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 18:02 +0100, Thanos Makatos wrote:
> Don't check if blktap is enabled since it will always be enabled (no
> blktap/blkback requirement anymore).

I think this needs to stay until the *BSD dom0's implement the necessary
kernel drivers (gnttab/gntalloc etc) such that blktap3 can run on them.
Currently we use libxl_noblktap2.c on those platforms and I think until
then we need to retain a libxl_noblktap3.c for use there.

Perhaps even on Linux we would want a sanity check that the drivers are
present and loaded etc?

> 
> diff -r bcb5a6182868 -r 57896068356d tools/libxl/libxl_blktap3.c
> --- a/tools/libxl/libxl_blktap3.c	Wed Oct 24 17:25:02 2012 +0100
> +++ b/tools/libxl/libxl_blktap3.c	Wed Oct 24 17:25:12 2012 +0100
> @@ -1,10 +1,6 @@
>  #include "libxl_osdeps.h"
>  #include "libxl_internal.h"
>  
> -int libxl__blktap_enabled(libxl__gc *gc) {
> -    return 1;
> -}
> -
>  int libxl__blktap_devpath(libxl__gc *gc, const char *disk,
>      libxl_disk_format format) {
>      return -ENOSYS;
> diff -r bcb5a6182868 -r 57896068356d tools/libxl/libxl_device.c
> --- a/tools/libxl/libxl_device.c	Wed Oct 24 17:25:02 2012 +0100
> +++ b/tools/libxl/libxl_device.c	Wed Oct 24 17:25:12 2012 +0100
> @@ -177,13 +177,6 @@ static int disk_try_backend(disk_try_bac
>  
>      case LIBXL_DISK_BACKEND_TAP:
>          if (a->disk->script) goto bad_script;
> -
> -        if (!libxl__blktap_enabled(a->gc)) {
> -            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, backend tap"
> -                       " unsuitable because blktap not available",
> -                       a->disk->vdev);
> -            return 0;
> -        }
>          if (!(a->disk->format == LIBXL_DISK_FORMAT_RAW ||
>                a->disk->format == LIBXL_DISK_FORMAT_VHD)) {
>              goto bad_format;
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 11:24:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 11:24:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRi0z-0003ZE-U2; Fri, 26 Oct 2012 11:23:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRi0y-0003Z4-NQ
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 11:23:48 +0000
Received: from [85.158.137.99:18817] by server-7.bemta-3.messagelabs.com id
	03/7D-06991-3C27A805; Fri, 26 Oct 2012 11:23:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1351250627!20779124!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18299 invoked from network); 26 Oct 2012 11:23:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 11:23:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15408444"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 11:23:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 12:23:47 +0100
Message-ID: <1351250625.15162.42.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Thanos Makatos 
Date: Fri, 26 Oct 2012 12:23:45 +0100
In-Reply-To: <57896068356d4870c74a.1351098144@makatos-desktop>
References: 
	<57896068356d4870c74a.1351098144@makatos-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 05 of 16 RFC] blktap3: Don't check if blktap
 is available
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 18:02 +0100, Thanos Makatos wrote:
> Don't check if blktap is enabled since it will always be enabled (no
> blktap/blkback requirement anymore).

I think this needs to stay until the *BSD dom0's implement the necessary
kernel drivers (gnttab/gntalloc etc) such that blktap3 can run on them.
Currently we use libxl_noblktap2.c on those platforms and I think until
then we need to retain a libxl_noblktap3.c for use there.

Perhaps even on Linux we would want a sanity check that the drivers are
present and loaded etc?

> 
> diff -r bcb5a6182868 -r 57896068356d tools/libxl/libxl_blktap3.c
> --- a/tools/libxl/libxl_blktap3.c	Wed Oct 24 17:25:02 2012 +0100
> +++ b/tools/libxl/libxl_blktap3.c	Wed Oct 24 17:25:12 2012 +0100
> @@ -1,10 +1,6 @@
>  #include "libxl_osdeps.h"
>  #include "libxl_internal.h"
>  
> -int libxl__blktap_enabled(libxl__gc *gc) {
> -    return 1;
> -}
> -
>  int libxl__blktap_devpath(libxl__gc *gc, const char *disk,
>      libxl_disk_format format) {
>      return -ENOSYS;
> diff -r bcb5a6182868 -r 57896068356d tools/libxl/libxl_device.c
> --- a/tools/libxl/libxl_device.c	Wed Oct 24 17:25:02 2012 +0100
> +++ b/tools/libxl/libxl_device.c	Wed Oct 24 17:25:12 2012 +0100
> @@ -177,13 +177,6 @@ static int disk_try_backend(disk_try_bac
>  
>      case LIBXL_DISK_BACKEND_TAP:
>          if (a->disk->script) goto bad_script;
> -
> -        if (!libxl__blktap_enabled(a->gc)) {
> -            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, backend tap"
> -                       " unsuitable because blktap not available",
> -                       a->disk->vdev);
> -            return 0;
> -        }
>          if (!(a->disk->format == LIBXL_DISK_FORMAT_RAW ||
>                a->disk->format == LIBXL_DISK_FORMAT_VHD)) {
>              goto bad_format;
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 11:26:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 11:26:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRi32-0003ip-EJ; Fri, 26 Oct 2012 11:25:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRi30-0003ij-Is
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 11:25:54 +0000
Received: from [193.109.254.147:55854] by server-8.bemta-14.messagelabs.com id
	FA/E0-16549-0437A805; Fri, 26 Oct 2012 11:25:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1351250703!8511292!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1425 invoked from network); 26 Oct 2012 11:25:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 11:25:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15408483"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 11:25:03 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 12:25:03 +0100
Message-ID: <1351250701.15162.43.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Thanos Makatos 
Date: Fri, 26 Oct 2012 12:25:01 +0100
In-Reply-To: <17eea5a9a20cc43d7de1.1351098146@makatos-desktop>
References: 
	<17eea5a9a20cc43d7de1.1351098146@makatos-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 07 of 16 RFC] blktap3: Introduce blktap3
 top-level Makefile
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 18:02 +0100, Thanos Makatos wrote:
> diff -r 5a0b0e799ae8 -r 17eea5a9a20c tools/blktap3/Makefile
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/tools/blktap3/Makefile	Wed Oct 24 17:25:32 2012 +0100
> @@ -0,0 +1,12 @@
> +XEN_ROOT := $(CURDIR)/../../
> +include $(XEN_ROOT)/tools/Rules.mk
> +
> +all: build
> +
> +build: ;

What does the ";" in this syntax do?

> +
> +clean: ;
> +
> +install: ;
> +
> +.PHONY: all build clean install
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 11:26:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 11:26:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRi32-0003ip-EJ; Fri, 26 Oct 2012 11:25:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRi30-0003ij-Is
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 11:25:54 +0000
Received: from [193.109.254.147:55854] by server-8.bemta-14.messagelabs.com id
	FA/E0-16549-0437A805; Fri, 26 Oct 2012 11:25:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1351250703!8511292!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1425 invoked from network); 26 Oct 2012 11:25:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 11:25:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15408483"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 11:25:03 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 12:25:03 +0100
Message-ID: <1351250701.15162.43.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Thanos Makatos 
Date: Fri, 26 Oct 2012 12:25:01 +0100
In-Reply-To: <17eea5a9a20cc43d7de1.1351098146@makatos-desktop>
References: 
	<17eea5a9a20cc43d7de1.1351098146@makatos-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 07 of 16 RFC] blktap3: Introduce blktap3
 top-level Makefile
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 18:02 +0100, Thanos Makatos wrote:
> diff -r 5a0b0e799ae8 -r 17eea5a9a20c tools/blktap3/Makefile
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/tools/blktap3/Makefile	Wed Oct 24 17:25:32 2012 +0100
> @@ -0,0 +1,12 @@
> +XEN_ROOT := $(CURDIR)/../../
> +include $(XEN_ROOT)/tools/Rules.mk
> +
> +all: build
> +
> +build: ;

What does the ";" in this syntax do?

> +
> +clean: ;
> +
> +install: ;
> +
> +.PHONY: all build clean install
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 11:28:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 11:28:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRi5T-0003sF-5Q; Fri, 26 Oct 2012 11:28:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRi5S-0003s4-2c
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 11:28:26 +0000
Received: from [85.158.139.211:51620] by server-8.bemta-5.messagelabs.com id
	8A/B7-23193-9D37A805; Fri, 26 Oct 2012 11:28:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1351250904!23874657!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8953 invoked from network); 26 Oct 2012 11:28:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 11:28:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15408531"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 11:27:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 12:27:43 +0100
Message-ID: <1351250861.15162.46.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Thanos Makatos 
Date: Fri, 26 Oct 2012 12:27:41 +0100
In-Reply-To: <23e2537c7257e0e5b00e.1351098147@makatos-desktop>
References: 
	<23e2537c7257e0e5b00e.1351098147@makatos-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 08 of 16 RFC] blktap3: Introduce message
 types and structures
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 18:02 +0100, Thanos Makatos wrote:
> The main difference over the the XEN version

what do you mean by "the XEN version"? Is there an existing version of
this header somewhere?

>  is the addition of the stats
> structure (used for retrieving stats from a running tapdisk), and the addition
> of the tapdisk_message_blkif struct, which is required for the user-space
> counterpart of blktap/blkback to communicate with tapdisk.

Am I correct that the interface defined here is one which is private
between the tapdisk processes and the supplied control tools, abstracted
away via libblktapctl?

> +/**
> + * Retrieves the human-readable representation of the type of the message.
> + */
> +static inline char *tapdisk_message_name(enum tapdisk_message_id id)
> +{
> +    switch (id) {

Would a static lookup table be nicer?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 11:28:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 11:28:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRi5T-0003sF-5Q; Fri, 26 Oct 2012 11:28:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRi5S-0003s4-2c
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 11:28:26 +0000
Received: from [85.158.139.211:51620] by server-8.bemta-5.messagelabs.com id
	8A/B7-23193-9D37A805; Fri, 26 Oct 2012 11:28:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1351250904!23874657!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8953 invoked from network); 26 Oct 2012 11:28:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 11:28:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15408531"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 11:27:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 12:27:43 +0100
Message-ID: <1351250861.15162.46.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Thanos Makatos 
Date: Fri, 26 Oct 2012 12:27:41 +0100
In-Reply-To: <23e2537c7257e0e5b00e.1351098147@makatos-desktop>
References: 
	<23e2537c7257e0e5b00e.1351098147@makatos-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 08 of 16 RFC] blktap3: Introduce message
 types and structures
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 18:02 +0100, Thanos Makatos wrote:
> The main difference over the the XEN version

what do you mean by "the XEN version"? Is there an existing version of
this header somewhere?

>  is the addition of the stats
> structure (used for retrieving stats from a running tapdisk), and the addition
> of the tapdisk_message_blkif struct, which is required for the user-space
> counterpart of blktap/blkback to communicate with tapdisk.

Am I correct that the interface defined here is one which is private
between the tapdisk processes and the supplied control tools, abstracted
away via libblktapctl?

> +/**
> + * Retrieves the human-readable representation of the type of the message.
> + */
> +static inline char *tapdisk_message_name(enum tapdisk_message_id id)
> +{
> +    switch (id) {

Would a static lookup table be nicer?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 11:32:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 11:32:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRi9b-00044a-RD; Fri, 26 Oct 2012 11:32:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRi9a-00044P-7R
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 11:32:42 +0000
Received: from [85.158.139.83:58662] by server-12.bemta-5.messagelabs.com id
	29/D5-26919-9D47A805; Fri, 26 Oct 2012 11:32:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1351251160!23499521!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18596 invoked from network); 26 Oct 2012 11:32:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 11:32:40 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15408670"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 11:32:40 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 12:32:40 +0100
Message-ID: <1351251159.15162.50.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Thanos Makatos 
Date: Fri, 26 Oct 2012 12:32:39 +0100
In-Reply-To: 
References: 
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 09 of 16 RFC] blktap3: Introduce the tapdisk
 control function prototypes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 18:02 +0100, Thanos Makatos wrote:

> +    /**
> +     * for linked lists
> +     */
> +    TAILQ_ENTRY(tap_list) entry;

This file doesn't seem to include the necessary header to define this?
(Perhaps it is indirectly included?)

Anyway, since I think this header is intended to be used by consumers of
blktap (rather than internally) I think you need to namespace the
macros. See tools/include/xen-external/bsd-sys-queue-h-seddery and its
usages in tools/libxl/Makefile and extras/mini-os/Makefile to create
local namespaced versions for libxl and mini-os.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 11:32:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 11:32:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRi9b-00044a-RD; Fri, 26 Oct 2012 11:32:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRi9a-00044P-7R
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 11:32:42 +0000
Received: from [85.158.139.83:58662] by server-12.bemta-5.messagelabs.com id
	29/D5-26919-9D47A805; Fri, 26 Oct 2012 11:32:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1351251160!23499521!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18596 invoked from network); 26 Oct 2012 11:32:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 11:32:40 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15408670"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 11:32:40 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 12:32:40 +0100
Message-ID: <1351251159.15162.50.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Thanos Makatos 
Date: Fri, 26 Oct 2012 12:32:39 +0100
In-Reply-To: 
References: 
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 09 of 16 RFC] blktap3: Introduce the tapdisk
 control function prototypes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 18:02 +0100, Thanos Makatos wrote:

> +    /**
> +     * for linked lists
> +     */
> +    TAILQ_ENTRY(tap_list) entry;

This file doesn't seem to include the necessary header to define this?
(Perhaps it is indirectly included?)

Anyway, since I think this header is intended to be used by consumers of
blktap (rather than internally) I think you need to namespace the
macros. See tools/include/xen-external/bsd-sys-queue-h-seddery and its
usages in tools/libxl/Makefile and extras/mini-os/Makefile to create
local namespaced versions for libxl and mini-os.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 11:37:03 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 11:37:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRiDV-0004DF-GH; Fri, 26 Oct 2012 11:36:45 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRiDT-0004D3-Nj
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 11:36:43 +0000
Received: from [193.109.254.147:53196] by server-16.bemta-14.messagelabs.com
	id C4/38-09215-BC57A805; Fri, 26 Oct 2012 11:36:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1351251400!8552757!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23320 invoked from network); 26 Oct 2012 11:36:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 11:36:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15408747"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 11:36:40 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 12:36:40 +0100
Message-ID: <1351251399.15162.53.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Thanos Makatos 
Date: Fri, 26 Oct 2012 12:36:39 +0100
In-Reply-To: 
References: 
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 10 of 16 RFC] blktap3: Introduce the blktap
 header file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 18:02 +0100, Thanos Makatos wrote:
> In this file various file-system paths are specified, similar to the XEN
> blktap2. These defines need to be documented. Unused defines (i.e. IOCTLs) have
> been removed.
> 
> diff -r efb6b2844256 -r a17c7217bef2 tools/blktap3/include/blktap.h
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/tools/blktap3/include/blktap.h	Wed Oct 24 17:26:14 2012 +0100
> @@ -0,0 +1,85 @@
> +/*
> + * FIXME this is the github blktap2 license.
> + *
> + * Copyright (c) 2008, XenSource Inc.
> + * All rights reserved.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions are met:
> + *     * Redistributions of source code must retain the above copyright
> + *       notice, this list of conditions and the following disclaimer.
> + *     * Redistributions in binary form must reproduce the above copyright
> + *       notice, this list of conditions and the following disclaimer in the
> + *       documentation and/or other materials provided with the distribution.
> + *     * Neither the name of XenSource Inc. nor the names of its contributors
> + *       may be used to endorse or promote products derived from this software
> + *       without specific prior written permission.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
> + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER
> + * OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
> + * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
> + * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
> + * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
> + * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
> + * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
> + * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +#ifndef __BLKTAP_3_H__
> +#define __BLKTAP_3_H__
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/*
> + * TODO Document what each define is.
> + */
> +#define BLKTAP3_SYSFS_DIR                   "/sys/class/blktap3"

I thought there was no kernel side to blktap3?

> +#define BLKTAP3_CONTROL_NAME                "blktap-control"
> +#define BLKTAP3_CONTROL_DIR                 "/var/run/"BLKTAP3_CONTROL_NAME
> +#define BLKTAP3_CONTROL_SOCKET              "ctl"

> +#define BLKTAP3_DIRECTORY                   "/dev/xen/blktap-3"
> +#define BLKTAP3_RING_DEVICE                 BLKTAP3_DIRECTORY"/blktap"

Likewise these two.

> +#define BLKTAP3_IO_DEVICEBLKTAP3_DIRECTORY  "/tapdev"
> +#define BLKTAP3_ENOSPC_SIGNAL_FILE          "/var/run/tapdisk3-enospc"
> +
> +/*
> + * TODO Can these be supplied from somewhere else?
> + */
> +#define likely(_cond)   __builtin_expect(!!(_cond), 1)
> +#define unlikely(_cond) __builtin_expect(!!(_cond), 0)
> +
> +/*
> + * FIXME taken from list.h
> + */
> +#define containerof(_ptr, _type, _memb) \
> +    ((_type*)((void*)(_ptr) - offsetof(_type, _memb)))
> +
> +/*
> + * FIXME shouldn't these be supplied from somewhere?
> + */
> +#define __printf(a, b) __attribute__((format(printf, a, b)))
> +#define __scanf(_f, _a) __attribute__((format (scanf, _f, _a)))

These are all abstractions of gcc-isms (presumably to ease ports to
other compilers). We generally don't bother with this sort of thing in
the tools, although you can if you like. You might want to put into a
compiler.h and add suitable #if like those in
xen/include/xen/compiler.h.

> +
> +#define TAILQ_MOVE_HEAD(node, src, dst, entry)  \
> +    TAILQ_REMOVE(src, node, entry);             \
> +    TAILQ_INSERT_HEAD(dst, node, entry);
> +
> +#define TAILQ_MOVE_TAIL(node, src, dst, entry)  \
> +    TAILQ_REMOVE(src, node, entry);             \
> +    TAILQ_INSERT_TAIL(dst, node, entry);
> +
> +/*
> + * TODO This is defined in xen/lib.h, use that instead of redefining it
> + * here.

xen/lib.h is a hypervisor internal header so isn't available to you
here. I think it is fine to define your own (although it should be in a
private header, not part of the libblktap API)

> + */
> +#ifndef ARRAY_SIZE
> +#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
> +#endif /* ARRAY_SIZE */
> +
> +#endif /* __BLKTAP_3_H__ */
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 11:37:03 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 11:37:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRiDV-0004DF-GH; Fri, 26 Oct 2012 11:36:45 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRiDT-0004D3-Nj
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 11:36:43 +0000
Received: from [193.109.254.147:53196] by server-16.bemta-14.messagelabs.com
	id C4/38-09215-BC57A805; Fri, 26 Oct 2012 11:36:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1351251400!8552757!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23320 invoked from network); 26 Oct 2012 11:36:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 11:36:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15408747"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 11:36:40 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 12:36:40 +0100
Message-ID: <1351251399.15162.53.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Thanos Makatos 
Date: Fri, 26 Oct 2012 12:36:39 +0100
In-Reply-To: 
References: 
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 10 of 16 RFC] blktap3: Introduce the blktap
 header file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 18:02 +0100, Thanos Makatos wrote:
> In this file various file-system paths are specified, similar to the XEN
> blktap2. These defines need to be documented. Unused defines (i.e. IOCTLs) have
> been removed.
> 
> diff -r efb6b2844256 -r a17c7217bef2 tools/blktap3/include/blktap.h
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/tools/blktap3/include/blktap.h	Wed Oct 24 17:26:14 2012 +0100
> @@ -0,0 +1,85 @@
> +/*
> + * FIXME this is the github blktap2 license.
> + *
> + * Copyright (c) 2008, XenSource Inc.
> + * All rights reserved.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions are met:
> + *     * Redistributions of source code must retain the above copyright
> + *       notice, this list of conditions and the following disclaimer.
> + *     * Redistributions in binary form must reproduce the above copyright
> + *       notice, this list of conditions and the following disclaimer in the
> + *       documentation and/or other materials provided with the distribution.
> + *     * Neither the name of XenSource Inc. nor the names of its contributors
> + *       may be used to endorse or promote products derived from this software
> + *       without specific prior written permission.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
> + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER
> + * OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
> + * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
> + * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
> + * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
> + * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
> + * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
> + * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +#ifndef __BLKTAP_3_H__
> +#define __BLKTAP_3_H__
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/*
> + * TODO Document what each define is.
> + */
> +#define BLKTAP3_SYSFS_DIR                   "/sys/class/blktap3"

I thought there was no kernel side to blktap3?

> +#define BLKTAP3_CONTROL_NAME                "blktap-control"
> +#define BLKTAP3_CONTROL_DIR                 "/var/run/"BLKTAP3_CONTROL_NAME
> +#define BLKTAP3_CONTROL_SOCKET              "ctl"

> +#define BLKTAP3_DIRECTORY                   "/dev/xen/blktap-3"
> +#define BLKTAP3_RING_DEVICE                 BLKTAP3_DIRECTORY"/blktap"

Likewise these two.

> +#define BLKTAP3_IO_DEVICEBLKTAP3_DIRECTORY  "/tapdev"
> +#define BLKTAP3_ENOSPC_SIGNAL_FILE          "/var/run/tapdisk3-enospc"
> +
> +/*
> + * TODO Can these be supplied from somewhere else?
> + */
> +#define likely(_cond)   __builtin_expect(!!(_cond), 1)
> +#define unlikely(_cond) __builtin_expect(!!(_cond), 0)
> +
> +/*
> + * FIXME taken from list.h
> + */
> +#define containerof(_ptr, _type, _memb) \
> +    ((_type*)((void*)(_ptr) - offsetof(_type, _memb)))
> +
> +/*
> + * FIXME shouldn't these be supplied from somewhere?
> + */
> +#define __printf(a, b) __attribute__((format(printf, a, b)))
> +#define __scanf(_f, _a) __attribute__((format (scanf, _f, _a)))

These are all abstractions of gcc-isms (presumably to ease ports to
other compilers). We generally don't bother with this sort of thing in
the tools, although you can if you like. You might want to put into a
compiler.h and add suitable #if like those in
xen/include/xen/compiler.h.

> +
> +#define TAILQ_MOVE_HEAD(node, src, dst, entry)  \
> +    TAILQ_REMOVE(src, node, entry);             \
> +    TAILQ_INSERT_HEAD(dst, node, entry);
> +
> +#define TAILQ_MOVE_TAIL(node, src, dst, entry)  \
> +    TAILQ_REMOVE(src, node, entry);             \
> +    TAILQ_INSERT_TAIL(dst, node, entry);
> +
> +/*
> + * TODO This is defined in xen/lib.h, use that instead of redefining it
> + * here.

xen/lib.h is a hypervisor internal header so isn't available to you
here. I think it is fine to define your own (although it should be in a
private header, not part of the libblktap API)

> + */
> +#ifndef ARRAY_SIZE
> +#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
> +#endif /* ARRAY_SIZE */
> +
> +#endif /* __BLKTAP_3_H__ */
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 11:37:40 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 11:37:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRiEE-0004IT-V8; Fri, 26 Oct 2012 11:37:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRiED-0004IC-KI
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 11:37:29 +0000
Received: from [85.158.138.51:24451] by server-2.bemta-3.messagelabs.com id
	D2/38-00604-8F57A805; Fri, 26 Oct 2012 11:37:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1351251447!8856312!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5835 invoked from network); 26 Oct 2012 11:37:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 11:37:27 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15408775"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 11:37:27 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 12:37:27 +0100
Message-ID: <1351251446.15162.54.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Thanos Makatos 
Date: Fri, 26 Oct 2012 12:37:26 +0100
In-Reply-To: <7cbf20d7e4d6b72aa8d0.1351098150@makatos-desktop>
References: 
	<7cbf20d7e4d6b72aa8d0.1351098150@makatos-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 11 of 16 RFC] blktap3: Provide empty
 implementation for the tap_ctl_list and tap_ctl_list_free functions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 18:02 +0100, Thanos Makatos wrote:
> +#ifdef HAVE_CONFIG_H
> +#include "config.h"
> +#endif

I think the presence of config.h will be statically determined, wont it?

> +
> +#include "tap-ctl.h"
> +
> +void tap_ctl_list_free(__attribute__((__unused__)) struct tqh_tap_list *list)
> +{
> +    return;
> +}
> +
> +int tap_ctl_list(__attribute__((__unused__)) struct tqh_tap_list *list)
> +{
> +    return -ENOSYS;
> +}
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 11:37:40 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 11:37:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRiEE-0004IT-V8; Fri, 26 Oct 2012 11:37:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRiED-0004IC-KI
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 11:37:29 +0000
Received: from [85.158.138.51:24451] by server-2.bemta-3.messagelabs.com id
	D2/38-00604-8F57A805; Fri, 26 Oct 2012 11:37:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1351251447!8856312!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5835 invoked from network); 26 Oct 2012 11:37:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 11:37:27 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15408775"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 11:37:27 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 12:37:27 +0100
Message-ID: <1351251446.15162.54.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Thanos Makatos 
Date: Fri, 26 Oct 2012 12:37:26 +0100
In-Reply-To: <7cbf20d7e4d6b72aa8d0.1351098150@makatos-desktop>
References: 
	<7cbf20d7e4d6b72aa8d0.1351098150@makatos-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 11 of 16 RFC] blktap3: Provide empty
 implementation for the tap_ctl_list and tap_ctl_list_free functions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 18:02 +0100, Thanos Makatos wrote:
> +#ifdef HAVE_CONFIG_H
> +#include "config.h"
> +#endif

I think the presence of config.h will be statically determined, wont it?

> +
> +#include "tap-ctl.h"
> +
> +void tap_ctl_list_free(__attribute__((__unused__)) struct tqh_tap_list *list)
> +{
> +    return;
> +}
> +
> +int tap_ctl_list(__attribute__((__unused__)) struct tqh_tap_list *list)
> +{
> +    return -ENOSYS;
> +}
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 11:46:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 11:46:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRiMe-0005LL-Vz; Fri, 26 Oct 2012 11:46:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRiMd-0005L8-HW
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 11:46:11 +0000
Received: from [85.158.137.99:46186] by server-2.bemta-3.messagelabs.com id
	AD/C4-00604-2087A805; Fri, 26 Oct 2012 11:46:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1351251964!23154758!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13958 invoked from network); 26 Oct 2012 11:46:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 11:46:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15408978"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 11:46:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 12:46:04 +0100
Message-ID: <1351251963.15162.61.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Thanos Makatos 
Date: Fri, 26 Oct 2012 12:46:03 +0100
In-Reply-To: <0f87cc018fb689f212cb.1351098155@makatos-desktop>
References: 
	<0f87cc018fb689f212cb.1351098155@makatos-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 16 of 16 RFC] blktap3: Implement
 libxl__blktap_devpath and libxl__device_destroy_tapdisk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 18:02 +0100, Thanos Makatos wrote:
> Provide implementation for the libxl__blktap_devpath and
> libxl__device_destroy_tapdisk functions: the former spawns the tapdisk process,
> the latter destroys it. Both of these functions use the blktap_find function,
> a function that lists all running tapdisks and looks for one serving a specific
> file. Finally, link libxl with the blktap3 control library.
> 
> diff -r b12c1bb767d3 -r 0f87cc018fb6 tools/libxl/Makefile
> --- a/tools/libxl/Makefile	Wed Oct 24 17:28:12 2012 +0100
> +++ b/tools/libxl/Makefile	Wed Oct 24 17:42:44 2012 +0100
> @@ -20,7 +20,7 @@ LIBUUID_LIBS += -luuid
>  endif
>  
>  LIBXL_LIBS =
> -LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS)
> +LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS) $(LDLIBS_libblktapctl)

Is this adding back the thing I commented on earlier?

>  CFLAGS_LIBXL += $(CFLAGS_libxenctrl)
>  CFLAGS_LIBXL += $(CFLAGS_libxenguest)
> @@ -29,7 +29,9 @@ CFLAGS_LIBXL += $(CFLAGS_libblktapctl)
>  CFLAGS_LIBXL += -Wshadow
>  
>  CFLAGS += $(PTHREAD_CFLAGS)
> -LDFLAGS += $(PTHREAD_LDFLAGS)
> +override LDFLAGS += \
> +	$(PTHREAD_LDFLAGS) \
> +	-L $(XEN_BLKTAP3)/control

Please (defined and) use LDLIBS_libblktapctl. Also this change to use
override looks very dubious to me -- what does it do?

>  LIBXL_LIBS += $(PTHREAD_LIBS)
>  
>  LIBXLU_LIBS =
> @@ -172,6 +174,7 @@ libxenlight.so.$(MAJOR): libxenlight.so.
>  	ln -sf $< $@
>  
>  libxenlight.so.$(MAJOR).$(MINOR): $(LIBXL_OBJS)
> +	make -C $(XEN_BLKTAP3)

This shouldn't be needed if the tools/Makefile has things ordered
correctly. It is reasonable for tools/libxl to assume that its
prerequisites are already built. People who build with make -C
tools/libxl need to take care of this themself.

>  	$(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxenlight.so.$(MAJOR) $(SHLIB_LDFLAGS) -o $@ $^ $(LIBXL_LIBS) $(APPEND_LDFLAGS)
>  
>  libxenlight.a: $(LIBXL_OBJS)
> diff -r b12c1bb767d3 -r 0f87cc018fb6 tools/libxl/libxl_blktap3.c
> --- a/tools/libxl/libxl_blktap3.c	Wed Oct 24 17:28:12 2012 +0100
> +++ b/tools/libxl/libxl_blktap3.c	Wed Oct 24 17:42:44 2012 +0100
>  
> -int libxl__device_destroy_tapdisk(libxl__gc *gc, const char *be_path) {
> -    return -ENOSYS;
> +/**
> + * Creates a tapdisk for the specified path.
> + *
> + * TODO document parameters
> + *
> + * @param gc
> + * @param disk
> + * @param format
> + *
> + * @returns 0 on success, an error code otherwise
> + */
> +int libxl__blktap_devpath(libxl__gc *gc, const char *disk,
> +        libxl_disk_format format)
> +{
> +    const char *type = NULL;
> +    char *params = NULL;
> +    struct tap_list tap;
> +    int err = 0;
> +
> +    type = libxl__device_disk_string_of_format(format);
> +
> +    /*
> +     * Ensure that no other tapdisk is serving this path.
> +     * XXX Does libxl protect us against race conditions?

Not AFAIK. Does tapdisk not open the file O_EXCL when necessary?

>  What if somebody
> +     * manually attaches a tapdisk to this path?
> +     */
> +    if (!(err = blktap_find(gc, type, disk, &tap))) {
> +        LOG(DEBUG, "tapdisk %d already serving %s\n", tap.pid, disk);
> +        return 0;
> +    }
> +
> +    LOG(DEBUG, "tapdisk not found\n");
> +
> +    /*
> +     * TODO Should we worry about return codes other than ENOENT?
> +     */
> +
> +    params = libxl__sprintf(gc, "%s:%s", type, disk);
> +    if (!(err = tap_ctl_create(params, 0, -1, NULL))) {
> +        LOG(DEBUG, "created tapdisk\n");        
> +        return 0;
> +    }
> +
> +    LOG(ERROR, "error creating tapdisk: %s\n", strerror(err));

You can use LOGE or LOGEV here to get the errno type thing printed
automatically in a consistent way.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 11:46:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 11:46:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRiMe-0005LL-Vz; Fri, 26 Oct 2012 11:46:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRiMd-0005L8-HW
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 11:46:11 +0000
Received: from [85.158.137.99:46186] by server-2.bemta-3.messagelabs.com id
	AD/C4-00604-2087A805; Fri, 26 Oct 2012 11:46:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1351251964!23154758!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13958 invoked from network); 26 Oct 2012 11:46:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 11:46:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15408978"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 11:46:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 12:46:04 +0100
Message-ID: <1351251963.15162.61.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Thanos Makatos 
Date: Fri, 26 Oct 2012 12:46:03 +0100
In-Reply-To: <0f87cc018fb689f212cb.1351098155@makatos-desktop>
References: 
	<0f87cc018fb689f212cb.1351098155@makatos-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 16 of 16 RFC] blktap3: Implement
 libxl__blktap_devpath and libxl__device_destroy_tapdisk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 18:02 +0100, Thanos Makatos wrote:
> Provide implementation for the libxl__blktap_devpath and
> libxl__device_destroy_tapdisk functions: the former spawns the tapdisk process,
> the latter destroys it. Both of these functions use the blktap_find function,
> a function that lists all running tapdisks and looks for one serving a specific
> file. Finally, link libxl with the blktap3 control library.
> 
> diff -r b12c1bb767d3 -r 0f87cc018fb6 tools/libxl/Makefile
> --- a/tools/libxl/Makefile	Wed Oct 24 17:28:12 2012 +0100
> +++ b/tools/libxl/Makefile	Wed Oct 24 17:42:44 2012 +0100
> @@ -20,7 +20,7 @@ LIBUUID_LIBS += -luuid
>  endif
>  
>  LIBXL_LIBS =
> -LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS)
> +LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS) $(LDLIBS_libblktapctl)

Is this adding back the thing I commented on earlier?

>  CFLAGS_LIBXL += $(CFLAGS_libxenctrl)
>  CFLAGS_LIBXL += $(CFLAGS_libxenguest)
> @@ -29,7 +29,9 @@ CFLAGS_LIBXL += $(CFLAGS_libblktapctl)
>  CFLAGS_LIBXL += -Wshadow
>  
>  CFLAGS += $(PTHREAD_CFLAGS)
> -LDFLAGS += $(PTHREAD_LDFLAGS)
> +override LDFLAGS += \
> +	$(PTHREAD_LDFLAGS) \
> +	-L $(XEN_BLKTAP3)/control

Please (defined and) use LDLIBS_libblktapctl. Also this change to use
override looks very dubious to me -- what does it do?

>  LIBXL_LIBS += $(PTHREAD_LIBS)
>  
>  LIBXLU_LIBS =
> @@ -172,6 +174,7 @@ libxenlight.so.$(MAJOR): libxenlight.so.
>  	ln -sf $< $@
>  
>  libxenlight.so.$(MAJOR).$(MINOR): $(LIBXL_OBJS)
> +	make -C $(XEN_BLKTAP3)

This shouldn't be needed if the tools/Makefile has things ordered
correctly. It is reasonable for tools/libxl to assume that its
prerequisites are already built. People who build with make -C
tools/libxl need to take care of this themself.

>  	$(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxenlight.so.$(MAJOR) $(SHLIB_LDFLAGS) -o $@ $^ $(LIBXL_LIBS) $(APPEND_LDFLAGS)
>  
>  libxenlight.a: $(LIBXL_OBJS)
> diff -r b12c1bb767d3 -r 0f87cc018fb6 tools/libxl/libxl_blktap3.c
> --- a/tools/libxl/libxl_blktap3.c	Wed Oct 24 17:28:12 2012 +0100
> +++ b/tools/libxl/libxl_blktap3.c	Wed Oct 24 17:42:44 2012 +0100
>  
> -int libxl__device_destroy_tapdisk(libxl__gc *gc, const char *be_path) {
> -    return -ENOSYS;
> +/**
> + * Creates a tapdisk for the specified path.
> + *
> + * TODO document parameters
> + *
> + * @param gc
> + * @param disk
> + * @param format
> + *
> + * @returns 0 on success, an error code otherwise
> + */
> +int libxl__blktap_devpath(libxl__gc *gc, const char *disk,
> +        libxl_disk_format format)
> +{
> +    const char *type = NULL;
> +    char *params = NULL;
> +    struct tap_list tap;
> +    int err = 0;
> +
> +    type = libxl__device_disk_string_of_format(format);
> +
> +    /*
> +     * Ensure that no other tapdisk is serving this path.
> +     * XXX Does libxl protect us against race conditions?

Not AFAIK. Does tapdisk not open the file O_EXCL when necessary?

>  What if somebody
> +     * manually attaches a tapdisk to this path?
> +     */
> +    if (!(err = blktap_find(gc, type, disk, &tap))) {
> +        LOG(DEBUG, "tapdisk %d already serving %s\n", tap.pid, disk);
> +        return 0;
> +    }
> +
> +    LOG(DEBUG, "tapdisk not found\n");
> +
> +    /*
> +     * TODO Should we worry about return codes other than ENOENT?
> +     */
> +
> +    params = libxl__sprintf(gc, "%s:%s", type, disk);
> +    if (!(err = tap_ctl_create(params, 0, -1, NULL))) {
> +        LOG(DEBUG, "created tapdisk\n");        
> +        return 0;
> +    }
> +
> +    LOG(ERROR, "error creating tapdisk: %s\n", strerror(err));

You can use LOGE or LOGEV here to get the errno type thing printed
automatically in a consistent way.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 11:47:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 11:47:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRiNL-0005Qm-ML; Fri, 26 Oct 2012 11:46:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRiHJ-0004Vj-PC
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 11:40:41 +0000
Received: from [193.109.254.147:17178] by server-2.bemta-14.messagelabs.com id
	7B/AE-19917-9B67A805; Fri, 26 Oct 2012 11:40:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1351251640!8613241!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13103 invoked from network); 26 Oct 2012 11:40:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 11:40:40 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15408871"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 11:40:40 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 12:40:40 +0100
Message-ID: <1351251638.15162.56.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Thanos Makatos 
Date: Fri, 26 Oct 2012 12:40:38 +0100
In-Reply-To: <9f5d1f1f979114cf41fc.1351098153@makatos-desktop>
References: 
	<9f5d1f1f979114cf41fc.1351098153@makatos-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 14 of 16 RFC] blktap3: Provide Makefile for
 compiling the blktap3 control library
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 18:02 +0100, Thanos Makatos wrote:
> This library will be used by libxl to create/destroy tapdisks.
> 
> diff -r 092fce05f530 -r 9f5d1f1f9791 tools/blktap3/control/Makefile
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/tools/blktap3/control/Makefile	Wed Oct 24 17:27:38 2012 +0100
> @@ -0,0 +1,57 @@
> +XEN_ROOT := $(CURDIR)/../../../
> +include $(XEN_ROOT)/tools/Rules.mk
> +
> +LIBDIR ?= /usr/lib

This comes from configure via config/Tools.mk now.

> +
> +MAJOR = 1.0
> +MINOR = 0
> +LIBNAME = libblktapctl
> +LIBSONAME = $(LIBNAME).so.$(MAJOR)
> +
> +override CFLAGS += \
> +	-I ../include \
> +	$(CFLAGS_xeninclude)
> +
> +CTL_OBJS = \
> +		   tap-ctl-destroy.o \
> +		   tap-ctl-create.o \
> +		   tap-ctl-list.o
> +
> +CTL_PICS  = $(patsubst %.o,%.opic,$(CTL_OBJS))
> +
> +OBJS = $(CTL_OBJS) tap-ctl.o
> +PICS = $(CTL_PICS)
> +
> +LIB_STATIC = $(LIBNAME).a
> +LIB_SHARED = $(LIBSONAME).$(MINOR)
> +
> +all: build
> +
> +build: $(LIB_STATIC) $(LIB_SHARED)
> +
> +$(LIBNAME).so: $(LIBSONAME)
> +	ln -sf $< $@
> +
> +$(LIBSONAME): $(LIB_SHARED)
> +	ln -sf $< $@
> +
> +$(LIB_STATIC): $(CTL_OBJS)
> +	$(AR) r $@ $^
> +
> +$(LIB_SHARED): $(CTL_PICS)
> +	$(CC) $(LDFLAGS) -fPIC  -Wl,$(SONAME_LDFLAG) -Wl,$(LIBSONAME) \
> +		$(SHLIB_LDFLAGS) -rdynamic $^ -o $@
> +
> +# TODO install in /usr/sbin?
> +install: $(LIB_STATIC) $(LIB_SHARED)
> +	$(INSTALL_DIR) -p $(DESTDIR)$(SBINDIR)

Was this intended to be LIBDIR? At least until the TODO is resolved.

> +	$(INSTALL_PROG) $(LIB_SHARED) $(DESTDIR)$(LIBDIR)
> +	ln -sf $(LIBSONAME) $(DESTDIR)$(LIBDIR)/$(LIBNAME).so
> +	ln -sf $(LIB_SHARED) $(DESTDIR)$(LIBDIR)/$(LIBSONAME)
> +
> +clean:
> +	rm -f $(OBJS) $(PICS) $(LIB_STATIC) $(LIB_SHARED)
> +	rm -f $(LIBNAME).so $(LIBSONAME)
> +	rm -f *~
> +
> +.PHONY: all build clean install
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 11:47:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 11:47:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRiNL-0005Qm-ML; Fri, 26 Oct 2012 11:46:55 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRiHJ-0004Vj-PC
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 11:40:41 +0000
Received: from [193.109.254.147:17178] by server-2.bemta-14.messagelabs.com id
	7B/AE-19917-9B67A805; Fri, 26 Oct 2012 11:40:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1351251640!8613241!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13103 invoked from network); 26 Oct 2012 11:40:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 11:40:40 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15408871"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 11:40:40 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 12:40:40 +0100
Message-ID: <1351251638.15162.56.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Thanos Makatos 
Date: Fri, 26 Oct 2012 12:40:38 +0100
In-Reply-To: <9f5d1f1f979114cf41fc.1351098153@makatos-desktop>
References: 
	<9f5d1f1f979114cf41fc.1351098153@makatos-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 14 of 16 RFC] blktap3: Provide Makefile for
 compiling the blktap3 control library
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-24 at 18:02 +0100, Thanos Makatos wrote:
> This library will be used by libxl to create/destroy tapdisks.
> 
> diff -r 092fce05f530 -r 9f5d1f1f9791 tools/blktap3/control/Makefile
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/tools/blktap3/control/Makefile	Wed Oct 24 17:27:38 2012 +0100
> @@ -0,0 +1,57 @@
> +XEN_ROOT := $(CURDIR)/../../../
> +include $(XEN_ROOT)/tools/Rules.mk
> +
> +LIBDIR ?= /usr/lib

This comes from configure via config/Tools.mk now.

> +
> +MAJOR = 1.0
> +MINOR = 0
> +LIBNAME = libblktapctl
> +LIBSONAME = $(LIBNAME).so.$(MAJOR)
> +
> +override CFLAGS += \
> +	-I ../include \
> +	$(CFLAGS_xeninclude)
> +
> +CTL_OBJS = \
> +		   tap-ctl-destroy.o \
> +		   tap-ctl-create.o \
> +		   tap-ctl-list.o
> +
> +CTL_PICS  = $(patsubst %.o,%.opic,$(CTL_OBJS))
> +
> +OBJS = $(CTL_OBJS) tap-ctl.o
> +PICS = $(CTL_PICS)
> +
> +LIB_STATIC = $(LIBNAME).a
> +LIB_SHARED = $(LIBSONAME).$(MINOR)
> +
> +all: build
> +
> +build: $(LIB_STATIC) $(LIB_SHARED)
> +
> +$(LIBNAME).so: $(LIBSONAME)
> +	ln -sf $< $@
> +
> +$(LIBSONAME): $(LIB_SHARED)
> +	ln -sf $< $@
> +
> +$(LIB_STATIC): $(CTL_OBJS)
> +	$(AR) r $@ $^
> +
> +$(LIB_SHARED): $(CTL_PICS)
> +	$(CC) $(LDFLAGS) -fPIC  -Wl,$(SONAME_LDFLAG) -Wl,$(LIBSONAME) \
> +		$(SHLIB_LDFLAGS) -rdynamic $^ -o $@
> +
> +# TODO install in /usr/sbin?
> +install: $(LIB_STATIC) $(LIB_SHARED)
> +	$(INSTALL_DIR) -p $(DESTDIR)$(SBINDIR)

Was this intended to be LIBDIR? At least until the TODO is resolved.

> +	$(INSTALL_PROG) $(LIB_SHARED) $(DESTDIR)$(LIBDIR)
> +	ln -sf $(LIBSONAME) $(DESTDIR)$(LIBDIR)/$(LIBNAME).so
> +	ln -sf $(LIB_SHARED) $(DESTDIR)$(LIBDIR)/$(LIBSONAME)
> +
> +clean:
> +	rm -f $(OBJS) $(PICS) $(LIB_STATIC) $(LIB_SHARED)
> +	rm -f $(LIBNAME).so $(LIBSONAME)
> +	rm -f *~
> +
> +.PHONY: all build clean install
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 11:53:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 11:53:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRiT6-0005j0-Hg; Fri, 26 Oct 2012 11:52:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRiT4-0005iu-NZ
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 11:52:50 +0000
Received: from [85.158.138.51:59107] by server-13.bemta-3.messagelabs.com id
	D4/AE-24887-C897A805; Fri, 26 Oct 2012 11:52:44 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1351252362!21195701!1
X-Originating-IP: [216.32.181.183]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21672 invoked from network); 26 Oct 2012 11:52:44 -0000
Received: from ch1ehsobe003.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.183)
	by server-14.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	26 Oct 2012 11:52:44 -0000
Received: from mail24-ch1-R.bigfish.com (10.43.68.252) by
	CH1EHSOBE004.bigfish.com (10.43.70.54) with Microsoft SMTP Server id
	14.1.225.23; Fri, 26 Oct 2012 11:52:42 +0000
Received: from mail24-ch1 (localhost [127.0.0.1])	by mail24-ch1-R.bigfish.com
	(Postfix) with ESMTP id 49C03C0238	for ;
	Fri, 26 Oct 2012 11:52:42 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzc85fhc85dhzz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh34h1155h)
Received: from mail24-ch1 (localhost.localdomain [127.0.0.1]) by mail24-ch1
	(MessageSwitch) id 1351252358864627_20099;
	Fri, 26 Oct 2012 11:52:38 +0000 (UTC)
Received: from CH1EHSMHS007.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.250])	by mail24-ch1.bigfish.com (Postfix) with ESMTP id
	D13172C0061
	for ; Fri, 26 Oct 2012 11:52:38 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS007.bigfish.com (10.43.70.7) with Microsoft SMTP Server id
	14.1.225.23; Fri, 26 Oct 2012 11:52:37 +0000
X-WSS-ID: 0MCI062-01-2MK-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1) with ESMTP id 292DC10282A9	for ;
	Fri, 26 Oct 2012 06:34:49 -0500 (CDT)
Received: from SAUSEXDAG05.amd.com (163.181.55.6) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 26 Oct 2012 06:35:10 -0500
Received: from STOREXDAG03.amd.com (10.1.13.12) by sausexdag05.amd.com
	(163.181.55.6) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Fri, 26 Oct 2012 06:34:49 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag03.amd.com
	(10.1.13.12) with Microsoft SMTP Server id 14.2.318.4; Fri, 26 Oct 2012
	07:34:48 -0400
Message-ID: <508A7553.9000308@amd.com>
Date: Fri, 26 Oct 2012 13:34:43 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" 
Content-Type: multipart/mixed; boundary="------------060504010403040506030001"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] MCE: remove unused MCA_MCE_HANDLER
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------060504010403040506030001
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit


Remove unused MCA_MCE_HANDLER.
MCA_MCE_SCAN is used everywhere instead.

Signed-off-by: Christoph Egger 

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------060504010403040506030001
Content-Type: text/plain; charset="us-ascii"; name="xen_mce_unused.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_mce_unused.diff"
Content-Description: xen_mce_unused.diff

diff -r 7abb25095de0 xen/arch/x86/cpu/mcheck/mce.c
--- a/xen/arch/x86/cpu/mcheck/mce.c	Thu Oct 25 13:15:19 2012 +0200
+++ b/xen/arch/x86/cpu/mcheck/mce.c	Fri Oct 26 12:00:08 2012 +0200
@@ -298,7 +298,6 @@ mcheck_mca_logout(enum mca_source who, s
 
     gstatus = mca_rdmsr(MSR_IA32_MCG_STATUS);
     switch (who) {
-    case MCA_MCE_HANDLER:
     case MCA_MCE_SCAN:
         mc_flags = MC_FLAG_MCE;
         which = MC_URGENT;
diff -r 7abb25095de0 xen/arch/x86/cpu/mcheck/mce.h
--- a/xen/arch/x86/cpu/mcheck/mce.h	Thu Oct 25 13:15:19 2012 +0200
+++ b/xen/arch/x86/cpu/mcheck/mce.h	Fri Oct 26 12:00:08 2012 +0200
@@ -104,7 +101,6 @@ static inline uint64_t mca_rdmsr(unsigne
  * of the MCA data observed in the logout operation. */
 
 enum mca_source {
-	MCA_MCE_HANDLER,
 	MCA_POLLER,
 	MCA_CMCI_HANDLER,
 	MCA_RESET,

--------------060504010403040506030001
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------060504010403040506030001--


From xen-devel-bounces@lists.xen.org Fri Oct 26 11:53:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 11:53:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRiT6-0005j0-Hg; Fri, 26 Oct 2012 11:52:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRiT4-0005iu-NZ
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 11:52:50 +0000
Received: from [85.158.138.51:59107] by server-13.bemta-3.messagelabs.com id
	D4/AE-24887-C897A805; Fri, 26 Oct 2012 11:52:44 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1351252362!21195701!1
X-Originating-IP: [216.32.181.183]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21672 invoked from network); 26 Oct 2012 11:52:44 -0000
Received: from ch1ehsobe003.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.183)
	by server-14.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	26 Oct 2012 11:52:44 -0000
Received: from mail24-ch1-R.bigfish.com (10.43.68.252) by
	CH1EHSOBE004.bigfish.com (10.43.70.54) with Microsoft SMTP Server id
	14.1.225.23; Fri, 26 Oct 2012 11:52:42 +0000
Received: from mail24-ch1 (localhost [127.0.0.1])	by mail24-ch1-R.bigfish.com
	(Postfix) with ESMTP id 49C03C0238	for ;
	Fri, 26 Oct 2012 11:52:42 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzc85fhc85dhzz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh34h1155h)
Received: from mail24-ch1 (localhost.localdomain [127.0.0.1]) by mail24-ch1
	(MessageSwitch) id 1351252358864627_20099;
	Fri, 26 Oct 2012 11:52:38 +0000 (UTC)
Received: from CH1EHSMHS007.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.250])	by mail24-ch1.bigfish.com (Postfix) with ESMTP id
	D13172C0061
	for ; Fri, 26 Oct 2012 11:52:38 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS007.bigfish.com (10.43.70.7) with Microsoft SMTP Server id
	14.1.225.23; Fri, 26 Oct 2012 11:52:37 +0000
X-WSS-ID: 0MCI062-01-2MK-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1) with ESMTP id 292DC10282A9	for ;
	Fri, 26 Oct 2012 06:34:49 -0500 (CDT)
Received: from SAUSEXDAG05.amd.com (163.181.55.6) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 26 Oct 2012 06:35:10 -0500
Received: from STOREXDAG03.amd.com (10.1.13.12) by sausexdag05.amd.com
	(163.181.55.6) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Fri, 26 Oct 2012 06:34:49 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag03.amd.com
	(10.1.13.12) with Microsoft SMTP Server id 14.2.318.4; Fri, 26 Oct 2012
	07:34:48 -0400
Message-ID: <508A7553.9000308@amd.com>
Date: Fri, 26 Oct 2012 13:34:43 +0200
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" 
Content-Type: multipart/mixed; boundary="------------060504010403040506030001"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] MCE: remove unused MCA_MCE_HANDLER
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------060504010403040506030001
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit


Remove unused MCA_MCE_HANDLER.
MCA_MCE_SCAN is used everywhere instead.

Signed-off-by: Christoph Egger 

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------060504010403040506030001
Content-Type: text/plain; charset="us-ascii"; name="xen_mce_unused.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_mce_unused.diff"
Content-Description: xen_mce_unused.diff

diff -r 7abb25095de0 xen/arch/x86/cpu/mcheck/mce.c
--- a/xen/arch/x86/cpu/mcheck/mce.c	Thu Oct 25 13:15:19 2012 +0200
+++ b/xen/arch/x86/cpu/mcheck/mce.c	Fri Oct 26 12:00:08 2012 +0200
@@ -298,7 +298,6 @@ mcheck_mca_logout(enum mca_source who, s
 
     gstatus = mca_rdmsr(MSR_IA32_MCG_STATUS);
     switch (who) {
-    case MCA_MCE_HANDLER:
     case MCA_MCE_SCAN:
         mc_flags = MC_FLAG_MCE;
         which = MC_URGENT;
diff -r 7abb25095de0 xen/arch/x86/cpu/mcheck/mce.h
--- a/xen/arch/x86/cpu/mcheck/mce.h	Thu Oct 25 13:15:19 2012 +0200
+++ b/xen/arch/x86/cpu/mcheck/mce.h	Fri Oct 26 12:00:08 2012 +0200
@@ -104,7 +101,6 @@ static inline uint64_t mca_rdmsr(unsigne
  * of the MCA data observed in the logout operation. */
 
 enum mca_source {
-	MCA_MCE_HANDLER,
 	MCA_POLLER,
 	MCA_CMCI_HANDLER,
 	MCA_RESET,

--------------060504010403040506030001
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------060504010403040506030001--


From xen-devel-bounces@lists.xen.org Fri Oct 26 11:58:46 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 11:58:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRiYb-0005ue-Ao; Fri, 26 Oct 2012 11:58:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRiYZ-0005uW-6P
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 11:58:31 +0000
Received: from [85.158.137.99:37595] by server-13.bemta-3.messagelabs.com id
	F3/57-24887-6EA7A805; Fri, 26 Oct 2012 11:58:30 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1351252708!20030516!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28107 invoked from network); 26 Oct 2012 11:58:29 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 11:58:29 -0000
Received: by mail-qc0-f173.google.com with SMTP id b12so1647741qca.32
	for ; Fri, 26 Oct 2012 04:58:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=gyyBNm9/h08X0S7t8BItoV6Y0uf6bgNxN3vcoCTzoLU=;
	b=KJ9H6YPxI1lV+G7wsBb4xtLgZx7gUCp4S4JBjVNmPujQg3TlBRJNyQSmHZJQzw29B6
	KrGXOH5bcFOWK+kXQGIc7EySFG17tXhcTStROVM7NWdJrdVA31yJYPQhhoC/YPBsQkOe
	I6jFfKge1IY/vdaA+35Co6oH2Ns3ZBUpUHS1QoCfTGw80wIugnoxNTTDzZy7N2x7hkMv
	XUpL2y0QjkG4xuOxRUz23GGAOSm0ieGMFVaKt1jNBLMbppsCNJD+uThhcct4VRzMDkbk
	e45aIjyn3lkzuwVMIleXWQFgUeVnw8hbYJOX3b8kRvOhi56EDurO1u6+8BM0HntQnyS3
	Wflw==
Received: by 10.224.42.8 with SMTP id q8mr11120402qae.77.1351252708435;
	Fri, 26 Oct 2012 04:58:28 -0700 (PDT)
Received: from localhost.localdomain
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id c9sm602495qeh.1.2012.10.26.04.58.27
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 26 Oct 2012 04:58:27 -0700 (PDT)
Date: Fri, 26 Oct 2012 07:58:19 -0400
From: Konrad Rzeszutek Wilk 
To: Olaf Hering 
Message-ID: <20121026115817.GA27383@localhost.localdomain>
References: 
	
	<20121025114645.GA7218@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20121025114645.GA7218@aepfle.de>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Keir Fraser , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools/hvmloader: move shared_info to
 reserved memory area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Oct 25, 2012 at 01:46:45PM +0200, Olaf Hering wrote:
> On Thu, Oct 25, Keir Fraser wrote:
> 
> > To be honest, given that the XenPVHVM extensions to Linux won't have been
> > tested on such old hypervisors, it wouldn't be a bad thing to bail on
> > setting up the extensions when you detect running on a really old Xen
> > version (e.g., earlier than 3.4.0) anyway. There's a fair chance of doing
> > more harm than good?
> 
> I could stick such a check into
> arch/x86/xen/enlighten.c:x86_hyper_xen_hvm->detect, by rearranging the
> code of xen_hvm_platform and init_hvm_pv_info.  Konrad, what do you
> think about that? Recent changes indicate that you did some testing on
> 3.4 based hosts.

Sure. It might make sense to streamline this a bit. Meaning after the
version check, have an int (or function) called 'xen_old_hypervisor()'
which your code and the XenBus code could call?

That way on ARM that function can just become a nop while on X86 we
do the cpuids (or if those had already been done - we just return
true or false).


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 11:58:46 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 11:58:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRiYb-0005ue-Ao; Fri, 26 Oct 2012 11:58:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRiYZ-0005uW-6P
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 11:58:31 +0000
Received: from [85.158.137.99:37595] by server-13.bemta-3.messagelabs.com id
	F3/57-24887-6EA7A805; Fri, 26 Oct 2012 11:58:30 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1351252708!20030516!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28107 invoked from network); 26 Oct 2012 11:58:29 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 11:58:29 -0000
Received: by mail-qc0-f173.google.com with SMTP id b12so1647741qca.32
	for ; Fri, 26 Oct 2012 04:58:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=gyyBNm9/h08X0S7t8BItoV6Y0uf6bgNxN3vcoCTzoLU=;
	b=KJ9H6YPxI1lV+G7wsBb4xtLgZx7gUCp4S4JBjVNmPujQg3TlBRJNyQSmHZJQzw29B6
	KrGXOH5bcFOWK+kXQGIc7EySFG17tXhcTStROVM7NWdJrdVA31yJYPQhhoC/YPBsQkOe
	I6jFfKge1IY/vdaA+35Co6oH2Ns3ZBUpUHS1QoCfTGw80wIugnoxNTTDzZy7N2x7hkMv
	XUpL2y0QjkG4xuOxRUz23GGAOSm0ieGMFVaKt1jNBLMbppsCNJD+uThhcct4VRzMDkbk
	e45aIjyn3lkzuwVMIleXWQFgUeVnw8hbYJOX3b8kRvOhi56EDurO1u6+8BM0HntQnyS3
	Wflw==
Received: by 10.224.42.8 with SMTP id q8mr11120402qae.77.1351252708435;
	Fri, 26 Oct 2012 04:58:28 -0700 (PDT)
Received: from localhost.localdomain
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id c9sm602495qeh.1.2012.10.26.04.58.27
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 26 Oct 2012 04:58:27 -0700 (PDT)
Date: Fri, 26 Oct 2012 07:58:19 -0400
From: Konrad Rzeszutek Wilk 
To: Olaf Hering 
Message-ID: <20121026115817.GA27383@localhost.localdomain>
References: 
	
	<20121025114645.GA7218@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20121025114645.GA7218@aepfle.de>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Keir Fraser , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools/hvmloader: move shared_info to
 reserved memory area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Oct 25, 2012 at 01:46:45PM +0200, Olaf Hering wrote:
> On Thu, Oct 25, Keir Fraser wrote:
> 
> > To be honest, given that the XenPVHVM extensions to Linux won't have been
> > tested on such old hypervisors, it wouldn't be a bad thing to bail on
> > setting up the extensions when you detect running on a really old Xen
> > version (e.g., earlier than 3.4.0) anyway. There's a fair chance of doing
> > more harm than good?
> 
> I could stick such a check into
> arch/x86/xen/enlighten.c:x86_hyper_xen_hvm->detect, by rearranging the
> code of xen_hvm_platform and init_hvm_pv_info.  Konrad, what do you
> think about that? Recent changes indicate that you did some testing on
> 3.4 based hosts.

Sure. It might make sense to streamline this a bit. Meaning after the
version check, have an int (or function) called 'xen_old_hypervisor()'
which your code and the XenBus code could call?

That way on ARM that function can just become a nop while on X86 we
do the cpuids (or if those had already been done - we just return
true or false).


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 12:02:22 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 12:02:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRic4-0006D6-EZ; Fri, 26 Oct 2012 12:02:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRic3-0006Cz-5j
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 12:02:07 +0000
Received: from [85.158.139.83:55623] by server-5.bemta-5.messagelabs.com id
	48/4A-09732-EBB7A805; Fri, 26 Oct 2012 12:02:06 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1351252925!26770679!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5NTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17099 invoked from network); 26 Oct 2012 12:02:05 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-182.messagelabs.com with SMTP;
	26 Oct 2012 12:02:05 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 26 Oct 2012 13:02:04 +0100
Message-Id: <508A89CB020000780008E6ED@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 26 Oct 2012 13:02:03 +0100
From: "Jan Beulich" 
To: 
References: 
	<5089676602000078000A4928@nat28.tlf.novell.com>
	
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: konrad.wilk@oracle.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/2] Xen acpi pad implement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> "Liu, Jinsong"  10/26/12 8:18 AM >>>
>> +static struct acpi_driver xen_acpi_pad_driver = {
>> +    .name = "processor_aggregator",
>> +    .class = ACPI_PROCESSOR_AGGREGATOR_CLASS,
>> +    .ids = pad_device_ids,
>> +    .ops = {
>> +        .add = xen_acpi_pad_add,
>
>.remove?
>
>[Jinsong] .remove method not used by any logic now (any possible point use it?), so we remove it from our former patch.

Unless there is technical difficulty implementing it, I wouldn't defer adding that code until the point where something doesn't work anymore.

>Overall I'd recommend taking a look at the cleaned up driver in
>our kernels.
>
>[Jinsong] What's your point here?

There's quite a bit of cleanup/simplification potential here, and rather than pointing the pieces out individually I would think comparing with what we have in production use might be worthwhile. But that's up to you of course.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 12:02:22 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 12:02:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRic4-0006D6-EZ; Fri, 26 Oct 2012 12:02:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRic3-0006Cz-5j
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 12:02:07 +0000
Received: from [85.158.139.83:55623] by server-5.bemta-5.messagelabs.com id
	48/4A-09732-EBB7A805; Fri, 26 Oct 2012 12:02:06 +0000
X-Env-Sender: jbeulich@suse.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1351252925!26770679!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5NTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17099 invoked from network); 26 Oct 2012 12:02:05 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-182.messagelabs.com with SMTP;
	26 Oct 2012 12:02:05 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 26 Oct 2012 13:02:04 +0100
Message-Id: <508A89CB020000780008E6ED@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 26 Oct 2012 13:02:03 +0100
From: "Jan Beulich" 
To: 
References: 
	<5089676602000078000A4928@nat28.tlf.novell.com>
	
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: konrad.wilk@oracle.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/2] Xen acpi pad implement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> "Liu, Jinsong"  10/26/12 8:18 AM >>>
>> +static struct acpi_driver xen_acpi_pad_driver = {
>> +    .name = "processor_aggregator",
>> +    .class = ACPI_PROCESSOR_AGGREGATOR_CLASS,
>> +    .ids = pad_device_ids,
>> +    .ops = {
>> +        .add = xen_acpi_pad_add,
>
>.remove?
>
>[Jinsong] .remove method not used by any logic now (any possible point use it?), so we remove it from our former patch.

Unless there is technical difficulty implementing it, I wouldn't defer adding that code until the point where something doesn't work anymore.

>Overall I'd recommend taking a look at the cleaned up driver in
>our kernels.
>
>[Jinsong] What's your point here?

There's quite a bit of cleanup/simplification potential here, and rather than pointing the pieces out individually I would think comparing with what we have in production use might be worthwhile. But that's up to you of course.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 12:16:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 12:16:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRiqA-0006el-EL; Fri, 26 Oct 2012 12:16:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRiq9-0006eU-1j
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 12:16:41 +0000
Received: from [85.158.139.211:12759] by server-1.bemta-5.messagelabs.com id
	5B/A5-21640-82F7A805; Fri, 26 Oct 2012 12:16:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1351253797!19862593!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32728 invoked from network); 26 Oct 2012 12:16:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 12:16:38 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15409742"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 12:16:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 13:16:37 +0100
Message-ID: <1351253796.15162.63.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Fri, 26 Oct 2012 13:16:36 +0100
In-Reply-To: 
References: 
	<1351091027-20740-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<1351159160.18035.147.camel@zakaz.uk.xensource.com>
	
	<1351236618.8558.4.camel@dagon.hellion.org.uk>
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" , "Tim
	\(Xen.org\)" 
Subject: Re: [Xen-devel] [PATCH 5/7] xen/arm: wake up secondary cpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-26 at 12:18 +0100, Stefano Stabellini wrote:
> On Fri, 26 Oct 2012, Ian Campbell wrote:
> > On Thu, 2012-10-25 at 18:45 +0100, Stefano Stabellini wrote:
> > > > >  
> > > > >  boot_cpu:
> > > > > @@ -98,6 +98,10 @@ boot_cpu:
> > > > >  	PRINT(" booting -\r\n")
> > > > >  #endif
> > > > >  
> > > > > +	/* Wake up secondary cpus */
> > > > > +	teq   r12, #0
> > > > > +	bleq  kick_cpus
> > > > 
> > > > Does this have to be done this early? Couldn't we defer it to C land
> > > > where it would be easier to isolate the processor/platform specific
> > > > behaviour?
> > > 
> > > Yes, it does because we need to send an interrupt to cpus running in
> > > secure mode, so this has to happen before we drop off secure state and we
> > > enter hypervisor state.
> > 
> > Hrm, so maybe this stuff does belong in mode_switch.S after all?
> > 
> > Or is there perhaps some register (e.g. in the GIC?) which would allow
> > non-secure hyp mode to sent an event to a processor in secure monitor
> > mode?
> 
> Whether the target processor in secure mode receives the interrupt or
> not, depends only on the GIC configuration on the target processor.
> I don't think there is anything we can do from cpu0 in non-secure mode.

Isn't this controlled by the GICD_GROUP register, which can be set from
cpu0 but affects all cpus?

Or is it the case that we need to do this poke before mode_switch.S
makes all interrupts into grp1 interrupts?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 12:16:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 12:16:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRiqA-0006el-EL; Fri, 26 Oct 2012 12:16:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRiq9-0006eU-1j
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 12:16:41 +0000
Received: from [85.158.139.211:12759] by server-1.bemta-5.messagelabs.com id
	5B/A5-21640-82F7A805; Fri, 26 Oct 2012 12:16:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1351253797!19862593!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32728 invoked from network); 26 Oct 2012 12:16:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 12:16:38 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15409742"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 12:16:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 13:16:37 +0100
Message-ID: <1351253796.15162.63.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Fri, 26 Oct 2012 13:16:36 +0100
In-Reply-To: 
References: 
	<1351091027-20740-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<1351159160.18035.147.camel@zakaz.uk.xensource.com>
	
	<1351236618.8558.4.camel@dagon.hellion.org.uk>
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" , "Tim
	\(Xen.org\)" 
Subject: Re: [Xen-devel] [PATCH 5/7] xen/arm: wake up secondary cpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-26 at 12:18 +0100, Stefano Stabellini wrote:
> On Fri, 26 Oct 2012, Ian Campbell wrote:
> > On Thu, 2012-10-25 at 18:45 +0100, Stefano Stabellini wrote:
> > > > >  
> > > > >  boot_cpu:
> > > > > @@ -98,6 +98,10 @@ boot_cpu:
> > > > >  	PRINT(" booting -\r\n")
> > > > >  #endif
> > > > >  
> > > > > +	/* Wake up secondary cpus */
> > > > > +	teq   r12, #0
> > > > > +	bleq  kick_cpus
> > > > 
> > > > Does this have to be done this early? Couldn't we defer it to C land
> > > > where it would be easier to isolate the processor/platform specific
> > > > behaviour?
> > > 
> > > Yes, it does because we need to send an interrupt to cpus running in
> > > secure mode, so this has to happen before we drop off secure state and we
> > > enter hypervisor state.
> > 
> > Hrm, so maybe this stuff does belong in mode_switch.S after all?
> > 
> > Or is there perhaps some register (e.g. in the GIC?) which would allow
> > non-secure hyp mode to sent an event to a processor in secure monitor
> > mode?
> 
> Whether the target processor in secure mode receives the interrupt or
> not, depends only on the GIC configuration on the target processor.
> I don't think there is anything we can do from cpu0 in non-secure mode.

Isn't this controlled by the GICD_GROUP register, which can be set from
cpu0 but affects all cpus?

Or is it the case that we need to do this poke before mode_switch.S
makes all interrupts into grp1 interrupts?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 12:38:20 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 12:38:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRjAn-0007NM-3H; Fri, 26 Oct 2012 12:38:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRjAl-0007NG-QR
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 12:38:00 +0000
Received: from [85.158.137.99:11073] by server-12.bemta-3.messagelabs.com id
	14/7F-27853-2248A805; Fri, 26 Oct 2012 12:37:54 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1351255072!21927137!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzE1Njk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14776 invoked from network); 26 Oct 2012 12:37:53 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-11.tower-217.messagelabs.com with SMTP;
	26 Oct 2012 12:37:53 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 26 Oct 2012 05:37:52 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,654,1344236400"; d="scan'208";a="232899605"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by orsmga002.jf.intel.com with ESMTP; 26 Oct 2012 05:37:39 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 26 Oct 2012 05:37:39 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.123]) with mapi id
	14.01.0355.002; Fri, 26 Oct 2012 20:37:37 +0800
From: "Liu, Jinsong" 
To: Jan Beulich 
Thread-Topic: [Xen-devel] [PATCH 1/2] Xen acpi pad implement
Thread-Index: AQHNs3G2Ti91BiFLfUibRvXA4zlK85fLgkyg
Date: Fri, 26 Oct 2012 12:37:36 +0000
Message-ID: 
References: 
	<5089676602000078000A4928@nat28.tlf.novell.com>
	
	<508A89CB020000780008E6ED@nat28.tlf.novell.com>
In-Reply-To: <508A89CB020000780008E6ED@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" ,
	"linux-kernel@vger.kernel.org" ,
	"konrad.wilk@oracle.com" 
Subject: Re: [Xen-devel] [PATCH 1/2] Xen acpi pad implement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 

-----Original Message-----
From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Jan Beulich
Sent: Friday, October 26, 2012 8:02 PM
To: Liu, Jinsong
Cc: konrad.wilk@oracle.com; linux-kernel@vger.kernel.org; xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/2] Xen acpi pad implement

>>> "Liu, Jinsong"  10/26/12 8:18 AM >>>
>> +static struct acpi_driver xen_acpi_pad_driver = {
>> +    .name = "processor_aggregator",
>> +    .class = ACPI_PROCESSOR_AGGREGATOR_CLASS,
>> +    .ids = pad_device_ids,
>> +    .ops = {
>> +        .add = xen_acpi_pad_add,
>
>.remove?
>
>[Jinsong] .remove method not used by any logic now (any possible point use it?), so we remove it from our former patch.

Unless there is technical difficulty implementing it, I wouldn't defer adding that code until the point where something doesn't work anymore.

[Jinsong] No technical difficulty at all, in fact at last version it has .remove method. I will re-add it.

>Overall I'd recommend taking a look at the cleaned up driver in
>our kernels.
>
>[Jinsong] What's your point here?

There's quite a bit of cleanup/simplification potential here, and rather than pointing the pieces out individually I would think comparing with what we have in production use might be worthwhile. But that's up to you of course.

[Jinsong] I know your concern now -- we can cleanup/simplify xen pad logic by piggyback on native acpi pad code -- technically it's true. However, we intentionally do so in order to keep xen pad logic self-contained, just like what xen mcelog logic did before.

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 12:38:20 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 12:38:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRjAn-0007NM-3H; Fri, 26 Oct 2012 12:38:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRjAl-0007NG-QR
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 12:38:00 +0000
Received: from [85.158.137.99:11073] by server-12.bemta-3.messagelabs.com id
	14/7F-27853-2248A805; Fri, 26 Oct 2012 12:37:54 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1351255072!21927137!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzE1Njk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14776 invoked from network); 26 Oct 2012 12:37:53 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-11.tower-217.messagelabs.com with SMTP;
	26 Oct 2012 12:37:53 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 26 Oct 2012 05:37:52 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,654,1344236400"; d="scan'208";a="232899605"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by orsmga002.jf.intel.com with ESMTP; 26 Oct 2012 05:37:39 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 26 Oct 2012 05:37:39 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.123]) with mapi id
	14.01.0355.002; Fri, 26 Oct 2012 20:37:37 +0800
From: "Liu, Jinsong" 
To: Jan Beulich 
Thread-Topic: [Xen-devel] [PATCH 1/2] Xen acpi pad implement
Thread-Index: AQHNs3G2Ti91BiFLfUibRvXA4zlK85fLgkyg
Date: Fri, 26 Oct 2012 12:37:36 +0000
Message-ID: 
References: 
	<5089676602000078000A4928@nat28.tlf.novell.com>
	
	<508A89CB020000780008E6ED@nat28.tlf.novell.com>
In-Reply-To: <508A89CB020000780008E6ED@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" ,
	"linux-kernel@vger.kernel.org" ,
	"konrad.wilk@oracle.com" 
Subject: Re: [Xen-devel] [PATCH 1/2] Xen acpi pad implement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 

-----Original Message-----
From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Jan Beulich
Sent: Friday, October 26, 2012 8:02 PM
To: Liu, Jinsong
Cc: konrad.wilk@oracle.com; linux-kernel@vger.kernel.org; xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/2] Xen acpi pad implement

>>> "Liu, Jinsong"  10/26/12 8:18 AM >>>
>> +static struct acpi_driver xen_acpi_pad_driver = {
>> +    .name = "processor_aggregator",
>> +    .class = ACPI_PROCESSOR_AGGREGATOR_CLASS,
>> +    .ids = pad_device_ids,
>> +    .ops = {
>> +        .add = xen_acpi_pad_add,
>
>.remove?
>
>[Jinsong] .remove method not used by any logic now (any possible point use it?), so we remove it from our former patch.

Unless there is technical difficulty implementing it, I wouldn't defer adding that code until the point where something doesn't work anymore.

[Jinsong] No technical difficulty at all, in fact at last version it has .remove method. I will re-add it.

>Overall I'd recommend taking a look at the cleaned up driver in
>our kernels.
>
>[Jinsong] What's your point here?

There's quite a bit of cleanup/simplification potential here, and rather than pointing the pieces out individually I would think comparing with what we have in production use might be worthwhile. But that's up to you of course.

[Jinsong] I know your concern now -- we can cleanup/simplify xen pad logic by piggyback on native acpi pad code -- technically it's true. However, we intentionally do so in order to keep xen pad logic self-contained, just like what xen mcelog logic did before.

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 12:58:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 12:58:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRjUc-00080v-4G; Fri, 26 Oct 2012 12:58:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRjR7-000803-0M
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 12:54:53 +0000
Received: from [85.158.139.83:61654] by server-9.bemta-5.messagelabs.com id
	51/88-23053-C188A805; Fri, 26 Oct 2012 12:54:52 +0000
X-Env-Sender: oholecek@suse.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1351256091!26922061!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19882 invoked from network); 26 Oct 2012 12:54:51 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Oct 2012 12:54:51 -0000
Received: from relay1.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id DA8249D938;
	Fri, 26 Oct 2012 14:54:49 +0200 (CEST)
From: =?utf-8?B?T25kxZllaiBIb2xlxI1law==?= 
To: Jim Fehlig 
Date: Fri, 26 Oct 2012 14:54:44 +0200
Message-ID: <5728419.j1LincOg6h@aaannz-nb.suse.cz>
Organization: SUSE
User-Agent: KMail/4.9.2 (Linux/3.6.2-6-desktop; KDE/4.9.2; x86_64; ; )
In-Reply-To: <50882F59.6070203@suse.com>
References: 
	<50882F59.6070203@suse.com>
MIME-Version: 1.0
X-Mailman-Approved-At: Fri, 26 Oct 2012 12:58:29 +0000
Cc: George Dunlap ,
	Dario Faggioli ,
	Bamvor Jian Zhang ,
	Chun Yan Liu , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] libxl drivers for libvirt?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Wednesday 24 of October 2012 12:11:37, Jim Fehlig:
> George Dunlap wrote:
> > Hey Jim,
> >
> > I was wondering if you or someone on your team could give me an idea
> > what the status of libxl support is in libvirt, particularly wrt
> > various releases?
> >
> > I'm asking because I'm going to UDS next week to talk about the 13.04
> > release, and it would be good to get Xen 4.2 in; but that in part
> > depends on whether there will be libvirt support for 4.2 in whatever
> > version of libvirt they ship as well.  I know Dario has been facing
> > the same kind of questions for Fedora 18.
> >
> > It appears that libvirt 0.10.2 has limited support for the 4.1 libxl
> > driver; but:
> > * This doesn't include some core features, like live migration
> 
> Right.  Chunyan has some patches to implement migration against 4.1
> libxl, but IIRC she is still investigating a bug.  Chunyan, can you give
> George an update on your libvirt libxl migration patches?
> 
> > * It won't compile against 4.2's libxl
> 
> Right again.  Ondrej has been looking into this.  Ondrej, do you have
> any status to report?  Any questions for the Xen folks wrt 4.1 vs 4.2 libxl?

Hi,

I have libxl which compiles without errors under Xen 4.2, but I didn't test it much yet. I based my port on patch [1], but there 
were numerous other issues like replaced libxl_cpumap by libxl_bitmap, added async operations, etc.
Right now I'm focusing on how to, if even possible, to support both 4.1 and 4.2 in same source files. Right now my libxl_compat.h is dangerously
growing.

I would definitely appreciate any detailed overview what and why changed between 4.1 and 4.2 libxl iface.

[1] http://lists.xen.org/archives/html/xen-devel/2012-05/msg00565.html

> 
> > Is that right?
> >
> > So I guess it would be nice to know:
> > * What kind of Xen support is available in the most recent release
> > (0.10.2, I believe), both xend and libxl
> 
> I've provided a table below that lists all of the libvirt hypervisor
> driver functions and their implementation status for qemu/kvm, legacy
> xen, and libxl drivers.
> 
> > * What kind of Xen support for libxl is in the libvirt development
> > branch, and do you have an idea when full support for 4.2 (at least,
> > including migration, suspend/resume, &c) might be available?
> 
> Nothing has changed in git master over what is available in 0.10.2, but
> we are now starting to pick up this work.  Our priorities are to first
> get the libxl driver compiling against 4.2 and all of the existing
> functionality that works with 4.1 working with 4.2, followed by closing
> the feature gap with the legacy xen driver, and finally closing the
> feature gap with the qemu driver where it makes sense.  This is
> obviously quite a bit of work and any help would be appreciated :).
> 
> BTW, we don't have any motivation to add features to the 4.1 version of
> the libvirt libxl driver.  Bamvor recently sent a patchset to add
> finer-grained locking to the libxl driver, but this code is independent
> of underlying libxl version IMO
> 
> https://www.redhat.com/archives/libvir-list/2012-October/msg00503.html
> 
> 
> > * Whether it would be easy for distros to backport 4.2 libxl support
> > to whatever their release is?
> 
> Until we have patches to make the driver work with 4.2 libxl, I can't
> speculate on the effort to backport to previous libvirt releases.
> 
> Regards,
> Jim
> 
> > That would help us better advise distros whether to:
> > * Stick with Xen 4.1 for the next release
> > * Go with Xen 4.2 but suggest continuing to use xend if libvirt
> > support is wanted
> > * Go with Xen 4.2 and backport patches to make libvirt work with libxl
> > * Go with Xen 4.2 and expect that libxl support will show up without
> > too much effort
> >
> > Obviously change is the only constant, so you can't predict with
> > perfect certainty; but if we have an idea what's most likely, we can
> > plan on that and then adjust based on what actually happens.
> >
> > Thanks!
> >  -George
> >
> 
> libvirt hypervisor driver funcs         qemu  xend  libxl
> -----------------------------------------------------------------
> virDrvOpen                             |  x  |  x  |  x  |
> virDrvClose                            |  x  |  x  |  x  |
> virDrvDrvSupportsFeature               |  x  |  x  |     |
> virDrvGetType                          |  x  |  x  |  x  |
> virDrvGetVersion                       |  x  |  x  |  x  |
> virDrvGetLibVersion                    |  x  |  x  |  x  |
> virDrvGetHostname                      |  x  |  x  |  x  |
> virDrvGetSysinfo                       |  x  |     |     |
> virDrvGetMaxVcpus                      |  x  |  x  |  x  |
> virDrvNodeGetInfo                      |  x  |  x  |  x  |
> virDrvGetCapabilities                  |  x  |  x  |  x  |
> virDrvListDomains                      |  x  |  x  |  x  |
> virDrvNumOfDomains                     |  x  |  x  |  x  |
> virDrvListAllDomains                   |  x  |     |  x  |
> virDrvDomainCreateXML                  |  x  |  x  |  x  |
> virDrvDomainLookupByID                 |  x  |  x  |  x  |
> virDrvDomainLookupByUUID               |  x  |  x  |  x  |
> virDrvDomainLookupByName               |  x  |  x  |  x  |
> virDrvDomainSuspend                    |  x  |  x  |  x  |
> virDrvDomainResume                     |  x  |  x  |  x  |
> virDrvDomainPMSuspendForDuration       |  x  |     |     |
> virDrvDomainPMWakeup                   |  x  |     |     |
> virDrvDomainShutdown                   |  x  |  x  |  x  |
> virDrvDomainShutdownFlags              |  x  |  x  |  x  |
> virDrvDomainReboot                     |  x  |  x  |  x  |
> virDrvDomainReset                      |  x  |     |     |
> virDrvDomainDestroy                    |  x  |  x  |  x  |
> virDrvDomainDestroyFlags               |  x  |  x  |  x  |
> virDrvDomainGetOSType                  |  x  |  x  |  x  |
> virDrvDomainGetHostname                |     |     |     |
> virDrvDomainGetMaxMemory               |  x  |  x  |  x  |
> virDrvDomainSetMaxMemory               |  x  |  x  |  x  |
> virDrvDomainSetMemory                  |  x  |  x  |  x  |
> virDrvDomainSetMemoryFlags             |  x  |     |  x  |
> virDrvDomainSetMemoryParameters        |  x  |     |     |
> virDrvDomainGetMemoryParameters        |  x  |     |     |
> virDrvDomainSetNumaParameters          |  x  |     |     |
> virDrvDomainGetNumaParameters          |  x  |     |     |
> virDrvDomainSetBlkioParameters         |  x  |     |     |
> virDrvDomainGetBlkioParameters         |  x  |     |     |
> virDrvDomainGetInfo                    |  x  |  x  |  x  |
> virDrvDomainGetState                   |  x  |  x  |  x  |
> virDrvDomainGetControlInfo             |  x  |     |     |
> virDrvDomainSave                       |  x  |  x  |  x  |
> virDrvDomainSaveFlags                  |  x  |  x  |  x  |
> virDrvDomainRestore                    |  x  |  x  |  x  |
> virDrvDomainRestoreFlags               |  x  |  x  |  x  |
> virDrvDomainSaveImageGetXMLDesc        |  x  |     |     |
> virDrvDomainSaveImageDefineXML         |  x  |     |     |
> virDrvDomainCoreDump                   |  x  |  x  |  x  |
> virDrvDomainScreenshot                 |  x  |     |     |
> virDrvDomainSetVcpus                   |  x  |  x  |  x  |
> virDrvDomainSetVcpusFlags              |  x  |  x  |  x  |
> virDrvDomainGetVcpusFlags              |  x  |  x  |  x  |
> virDrvDomainPinVcpu                    |  x  |  x  |  x  |
> virDrvDomainPinVcpuFlags               |  x  |     |     |
> virDrvDomainGetVcpuPinInfo             |  x  |     |     |
> virDrvDomainPinEmulator                |  x  |     |     |
> virDrvDomainGetEmulatorPinInfo         |  x  |     |     |
> virDrvDomainGetVcpus                   |  x  |  x  |  x  |
> virDrvDomainGetMaxVcpus                |  x  |  x  |     |
> virDrvDomainGetSecurityLabel           |  x  |     |     |
> virDrvDomainGetSecurityLabelList       |  x  |     |     |
> virDrvNodeGetSecurityModel             |  x  |     |     |
> virDrvDomainGetXMLDesc                 |  x  |  x  |  x  |
> virDrvConnectDomainXMLFromNative       |  x  |  x  |  x  |
> virDrvConnectDomainXMLToNative         |  x  |  x  |  x  |
> virDrvListDefinedDomains               |  x  |  x  |  x  |
> virDrvNumOfDefinedDomains              |  x  |  x  |  x  |
> virDrvDomainCreate                     |  x  |  x  |  x  |
> virDrvDomainCreateWithFlags            |  x  |  x  |  x  |
> virDrvDomainDefineXML                  |  x  |  x  |  x  |
> virDrvDomainUndefine                   |  x  |  x  |  x  |
> virDrvDomainUndefineFlags              |  x  |  x  |  x  |
> virDrvDomainAttachDevice               |  x  |  x  |  x  |
> virDrvDomainAttachDeviceFlags          |  x  |  x  |  x  |
> virDrvDomainDetachDevice               |  x  |  x  |  x  |
> virDrvDomainDetachDeviceFlags          |  x  |  x  |  x  |
> virDrvDomainUpdateDeviceFlags          |  x  |  x  |  x  |
> virDrvDomainGetAutostart               |  x  |  x  |  x  |
> virDrvDomainSetAutostart               |  x  |  x  |  x  | 
> virDrvDomainGetSchedulerType           |  x  |  x  |  x  |
> virDrvDomainGetSchedulerParameters     |  x  |  x  |  x  |
> virDrvDomainGetSchedulerParametersFlags|  x  |  x  |  x  |
> virDrvDomainSetSchedulerParameters     |  x  |  x  |  x  |
> virDrvDomainSetSchedulerParametersFlags|  x  |  x  |  x  |
> virDrvDomainMigratePrepare             |     |  x  |     |
> virDrvDomainMigratePerform             |  x  |  x  |     |
> virDrvDomainMigrateFinish              |     |  x  |     |
> virDrvDomainBlockResize                |  x  |     |     |
> virDrvDomainBlockStats                 |  x  |     |     |
> virDrvDomainBlockStatsFlags            |  x  |     |     |
> virDrvDomainInterfaceStats             |  x  |  x  |     |
> virDrvDomainSetInterfaceParameters     |  x  |     |     |
> virDrvDomainGetInterfaceParameters     |  x  |     |     |
> virDrvDomainMemoryStats                |  x  |     |     |
> virDrvDomainBlockPeek                  |  x  |  x  |     |
> virDrvDomainMemoryPeek                 |  x  |     |     |
> virDrvDomainGetBlockInfo               |  x  |     |     |
> virDrvNodeGetCPUStats                  |  x  |     |     |
> virDrvNodeGetMemoryStats               |  x  |     |     |
> virDrvNodeGetCellsFreeMemory           |  x  |  x  |     |
> virDrvNodeGetFreeMemory                |  x  |  x  |  x  |
> virDrvDomainEventRegister              |  x  |  x  |  x  |
> virDrvDomainEventDeregister            |  x  |  x  |  x  |
> virDrvDomainMigratePrepare2            |  x  |     |     |
> virDrvDomainMigrateFinish2             |  x  |     |     |
> virDrvNodeDeviceDettach                |  x  |  x  |     |
> virDrvNodeDeviceReAttach               |  x  |  x  |     |
> virDrvNodeDeviceReset                  |  x  |  x  |     |
> virDrvDomainMigratePrepareTunnel       |  x  |     |     |
> virDrvConnectIsEncrypted               |  x  |  x  |     |
> virDrvConnectIsSecure                  |  x  |  x  |     |
> virDrvDomainIsActive                   |  x  |  x  |  x  |
> virDrvDomainIsPersistent               |  x  |  x  |  x  |
> virDrvDomainIsUpdated                  |  x  |  x  |  x  |
> virDrvCompareCPU                       |  x  |     |     |
> virDrvBaselineCPU                      |  x  |     |     |
> virDrvDomainGetJobInfo                 |  x  |     |     |
> virDrvDomainAbortJob                   |  x  |     |     |
> virDrvDomainMigrateSetMaxDowntime      |  x  |     |     |
> virDrvDomainMigrateGetMaxSpeed         |  x  |     |     |
> virDrvDomainMigrateSetMaxSpeed         |  x  |     |     |
> virDrvDomainEventRegisterAny           |  x  |     |  x  |
> virDrvDomainEventDeregisterAny         |  x  |     |  x  |
> virDrvDomainManagedSave                |  x  |     |  x  |
> virDrvDomainHasManagedSaveImage        |  x  |     |  x  |
> virDrvDomainManagedSaveRemove          |  x  |     |  x  |
> virDrvDomainSnapshotCreateXML          |  x  |     |     |
> virDrvDomainSnapshotGetXMLDesc         |  x  |     |     |
> virDrvDomainSnapshotNum                |  x  |     |     |
> virDrvDomainSnapshotListNames          |  x  |     |     |
> virDrvDomainListAllSnapshots           |  x  |     |     |
> virDrvDomainSnapshotNumChildren        |  x  |     |     |
> virDrvDomainSnapshotListChildrenNames  |  x  |     |     |
> virDrvDomainSnapshotListAllChildren    |  x  |     |     |
> virDrvDomainSnapshotLookupByName       |  x  |     |     |
> virDrvDomainHasCurrentSnapshot         |  x  |     |     |
> virDrvDomainSnapshotGetParent          |  x  |     |     |
> virDrvDomainSnapshotCurrent            |  x  |     |     |
> virDrvDomainSnapshotIsCurrent          |  x  |     |     |
> virDrvDomainSnapshotHasMetadata        |  x  |     |     |
> virDrvDomainRevertToSnapshot           |  x  |     |     |
> virDrvDomainSnapshotDelete             |  x  |     |     |
> virDrvDomainQemuMonitorCommand         |  x  |     |     |
> virDrvDomainQemuAttach                 |  x  |     |     |
> virDrvDomainQemuAgentCommand           |  x  |     |     |
> virDrvDomainOpenConsole                |  x  |  x  |     |
> virDrvDomainOpenGraphics               |  x  |     |     |
> virDrvDomainInjectNMI                  |  x  |     |     |
> virDrvDomainMigrateBegin3              |  x  |     |     |
> virDrvDomainMigratePrepare3            |  x  |     |     |
> virDrvDomainMigratePrepareTunnel3      |  x  |     |     |
> virDrvDomainMigratePerform3            |  x  |     |     |
> virDrvDomainMigrateFinish3             |  x  |     |     |
> virDrvDomainMigrateConfirm3            |  x  |     |     |
> virDrvDomainSendKey                    |  x  |     |     |
> virDrvDomainBlockJobAbort              |  x  |     |     |
> virDrvDomainGetBlockJobInfo            |  x  |     |     |
> virDrvDomainBlockJobSetSpeed           |  x  |     |     |
> virDrvDomainBlockPull                  |  x  |     |     |
> virDrvDomainBlockRebase                |  x  |     |     |
> virDrvDomainBlockCommit                |  x  |     |     |
> virDrvSetKeepAlive                     |     |     |     |
> virDrvConnectIsAlive                   |  x  |     |     |
> virDrvNodeSuspendForDuration           |  x  |  x  |     |
> virDrvDomainSetBlockIoTune             |  x  |     |     |
> virDrvDomainGetBlockIoTune             |  x  |     |     |
> virDrvDomainGetCPUStats                |  x  |     |     |
> virDrvDomainGetDiskErrors              |  x  |     |     |
> virDrvDomainSetMetadata                |  x  |     |     |
> virDrvDomainGetMetadata                |  x  |     |     |
> virDrvNodeGetMemoryParameters          |  x  |  x  |     |
> virDrvNodeSetMemoryParameters          |  x  |  x  |     |
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 12:58:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 12:58:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRjUc-00080v-4G; Fri, 26 Oct 2012 12:58:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRjR7-000803-0M
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 12:54:53 +0000
Received: from [85.158.139.83:61654] by server-9.bemta-5.messagelabs.com id
	51/88-23053-C188A805; Fri, 26 Oct 2012 12:54:52 +0000
X-Env-Sender: oholecek@suse.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1351256091!26922061!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19882 invoked from network); 26 Oct 2012 12:54:51 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Oct 2012 12:54:51 -0000
Received: from relay1.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id DA8249D938;
	Fri, 26 Oct 2012 14:54:49 +0200 (CEST)
From: =?utf-8?B?T25kxZllaiBIb2xlxI1law==?= 
To: Jim Fehlig 
Date: Fri, 26 Oct 2012 14:54:44 +0200
Message-ID: <5728419.j1LincOg6h@aaannz-nb.suse.cz>
Organization: SUSE
User-Agent: KMail/4.9.2 (Linux/3.6.2-6-desktop; KDE/4.9.2; x86_64; ; )
In-Reply-To: <50882F59.6070203@suse.com>
References: 
	<50882F59.6070203@suse.com>
MIME-Version: 1.0
X-Mailman-Approved-At: Fri, 26 Oct 2012 12:58:29 +0000
Cc: George Dunlap ,
	Dario Faggioli ,
	Bamvor Jian Zhang ,
	Chun Yan Liu , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] libxl drivers for libvirt?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Wednesday 24 of October 2012 12:11:37, Jim Fehlig:
> George Dunlap wrote:
> > Hey Jim,
> >
> > I was wondering if you or someone on your team could give me an idea
> > what the status of libxl support is in libvirt, particularly wrt
> > various releases?
> >
> > I'm asking because I'm going to UDS next week to talk about the 13.04
> > release, and it would be good to get Xen 4.2 in; but that in part
> > depends on whether there will be libvirt support for 4.2 in whatever
> > version of libvirt they ship as well.  I know Dario has been facing
> > the same kind of questions for Fedora 18.
> >
> > It appears that libvirt 0.10.2 has limited support for the 4.1 libxl
> > driver; but:
> > * This doesn't include some core features, like live migration
> 
> Right.  Chunyan has some patches to implement migration against 4.1
> libxl, but IIRC she is still investigating a bug.  Chunyan, can you give
> George an update on your libvirt libxl migration patches?
> 
> > * It won't compile against 4.2's libxl
> 
> Right again.  Ondrej has been looking into this.  Ondrej, do you have
> any status to report?  Any questions for the Xen folks wrt 4.1 vs 4.2 libxl?

Hi,

I have libxl which compiles without errors under Xen 4.2, but I didn't test it much yet. I based my port on patch [1], but there 
were numerous other issues like replaced libxl_cpumap by libxl_bitmap, added async operations, etc.
Right now I'm focusing on how to, if even possible, to support both 4.1 and 4.2 in same source files. Right now my libxl_compat.h is dangerously
growing.

I would definitely appreciate any detailed overview what and why changed between 4.1 and 4.2 libxl iface.

[1] http://lists.xen.org/archives/html/xen-devel/2012-05/msg00565.html

> 
> > Is that right?
> >
> > So I guess it would be nice to know:
> > * What kind of Xen support is available in the most recent release
> > (0.10.2, I believe), both xend and libxl
> 
> I've provided a table below that lists all of the libvirt hypervisor
> driver functions and their implementation status for qemu/kvm, legacy
> xen, and libxl drivers.
> 
> > * What kind of Xen support for libxl is in the libvirt development
> > branch, and do you have an idea when full support for 4.2 (at least,
> > including migration, suspend/resume, &c) might be available?
> 
> Nothing has changed in git master over what is available in 0.10.2, but
> we are now starting to pick up this work.  Our priorities are to first
> get the libxl driver compiling against 4.2 and all of the existing
> functionality that works with 4.1 working with 4.2, followed by closing
> the feature gap with the legacy xen driver, and finally closing the
> feature gap with the qemu driver where it makes sense.  This is
> obviously quite a bit of work and any help would be appreciated :).
> 
> BTW, we don't have any motivation to add features to the 4.1 version of
> the libvirt libxl driver.  Bamvor recently sent a patchset to add
> finer-grained locking to the libxl driver, but this code is independent
> of underlying libxl version IMO
> 
> https://www.redhat.com/archives/libvir-list/2012-October/msg00503.html
> 
> 
> > * Whether it would be easy for distros to backport 4.2 libxl support
> > to whatever their release is?
> 
> Until we have patches to make the driver work with 4.2 libxl, I can't
> speculate on the effort to backport to previous libvirt releases.
> 
> Regards,
> Jim
> 
> > That would help us better advise distros whether to:
> > * Stick with Xen 4.1 for the next release
> > * Go with Xen 4.2 but suggest continuing to use xend if libvirt
> > support is wanted
> > * Go with Xen 4.2 and backport patches to make libvirt work with libxl
> > * Go with Xen 4.2 and expect that libxl support will show up without
> > too much effort
> >
> > Obviously change is the only constant, so you can't predict with
> > perfect certainty; but if we have an idea what's most likely, we can
> > plan on that and then adjust based on what actually happens.
> >
> > Thanks!
> >  -George
> >
> 
> libvirt hypervisor driver funcs         qemu  xend  libxl
> -----------------------------------------------------------------
> virDrvOpen                             |  x  |  x  |  x  |
> virDrvClose                            |  x  |  x  |  x  |
> virDrvDrvSupportsFeature               |  x  |  x  |     |
> virDrvGetType                          |  x  |  x  |  x  |
> virDrvGetVersion                       |  x  |  x  |  x  |
> virDrvGetLibVersion                    |  x  |  x  |  x  |
> virDrvGetHostname                      |  x  |  x  |  x  |
> virDrvGetSysinfo                       |  x  |     |     |
> virDrvGetMaxVcpus                      |  x  |  x  |  x  |
> virDrvNodeGetInfo                      |  x  |  x  |  x  |
> virDrvGetCapabilities                  |  x  |  x  |  x  |
> virDrvListDomains                      |  x  |  x  |  x  |
> virDrvNumOfDomains                     |  x  |  x  |  x  |
> virDrvListAllDomains                   |  x  |     |  x  |
> virDrvDomainCreateXML                  |  x  |  x  |  x  |
> virDrvDomainLookupByID                 |  x  |  x  |  x  |
> virDrvDomainLookupByUUID               |  x  |  x  |  x  |
> virDrvDomainLookupByName               |  x  |  x  |  x  |
> virDrvDomainSuspend                    |  x  |  x  |  x  |
> virDrvDomainResume                     |  x  |  x  |  x  |
> virDrvDomainPMSuspendForDuration       |  x  |     |     |
> virDrvDomainPMWakeup                   |  x  |     |     |
> virDrvDomainShutdown                   |  x  |  x  |  x  |
> virDrvDomainShutdownFlags              |  x  |  x  |  x  |
> virDrvDomainReboot                     |  x  |  x  |  x  |
> virDrvDomainReset                      |  x  |     |     |
> virDrvDomainDestroy                    |  x  |  x  |  x  |
> virDrvDomainDestroyFlags               |  x  |  x  |  x  |
> virDrvDomainGetOSType                  |  x  |  x  |  x  |
> virDrvDomainGetHostname                |     |     |     |
> virDrvDomainGetMaxMemory               |  x  |  x  |  x  |
> virDrvDomainSetMaxMemory               |  x  |  x  |  x  |
> virDrvDomainSetMemory                  |  x  |  x  |  x  |
> virDrvDomainSetMemoryFlags             |  x  |     |  x  |
> virDrvDomainSetMemoryParameters        |  x  |     |     |
> virDrvDomainGetMemoryParameters        |  x  |     |     |
> virDrvDomainSetNumaParameters          |  x  |     |     |
> virDrvDomainGetNumaParameters          |  x  |     |     |
> virDrvDomainSetBlkioParameters         |  x  |     |     |
> virDrvDomainGetBlkioParameters         |  x  |     |     |
> virDrvDomainGetInfo                    |  x  |  x  |  x  |
> virDrvDomainGetState                   |  x  |  x  |  x  |
> virDrvDomainGetControlInfo             |  x  |     |     |
> virDrvDomainSave                       |  x  |  x  |  x  |
> virDrvDomainSaveFlags                  |  x  |  x  |  x  |
> virDrvDomainRestore                    |  x  |  x  |  x  |
> virDrvDomainRestoreFlags               |  x  |  x  |  x  |
> virDrvDomainSaveImageGetXMLDesc        |  x  |     |     |
> virDrvDomainSaveImageDefineXML         |  x  |     |     |
> virDrvDomainCoreDump                   |  x  |  x  |  x  |
> virDrvDomainScreenshot                 |  x  |     |     |
> virDrvDomainSetVcpus                   |  x  |  x  |  x  |
> virDrvDomainSetVcpusFlags              |  x  |  x  |  x  |
> virDrvDomainGetVcpusFlags              |  x  |  x  |  x  |
> virDrvDomainPinVcpu                    |  x  |  x  |  x  |
> virDrvDomainPinVcpuFlags               |  x  |     |     |
> virDrvDomainGetVcpuPinInfo             |  x  |     |     |
> virDrvDomainPinEmulator                |  x  |     |     |
> virDrvDomainGetEmulatorPinInfo         |  x  |     |     |
> virDrvDomainGetVcpus                   |  x  |  x  |  x  |
> virDrvDomainGetMaxVcpus                |  x  |  x  |     |
> virDrvDomainGetSecurityLabel           |  x  |     |     |
> virDrvDomainGetSecurityLabelList       |  x  |     |     |
> virDrvNodeGetSecurityModel             |  x  |     |     |
> virDrvDomainGetXMLDesc                 |  x  |  x  |  x  |
> virDrvConnectDomainXMLFromNative       |  x  |  x  |  x  |
> virDrvConnectDomainXMLToNative         |  x  |  x  |  x  |
> virDrvListDefinedDomains               |  x  |  x  |  x  |
> virDrvNumOfDefinedDomains              |  x  |  x  |  x  |
> virDrvDomainCreate                     |  x  |  x  |  x  |
> virDrvDomainCreateWithFlags            |  x  |  x  |  x  |
> virDrvDomainDefineXML                  |  x  |  x  |  x  |
> virDrvDomainUndefine                   |  x  |  x  |  x  |
> virDrvDomainUndefineFlags              |  x  |  x  |  x  |
> virDrvDomainAttachDevice               |  x  |  x  |  x  |
> virDrvDomainAttachDeviceFlags          |  x  |  x  |  x  |
> virDrvDomainDetachDevice               |  x  |  x  |  x  |
> virDrvDomainDetachDeviceFlags          |  x  |  x  |  x  |
> virDrvDomainUpdateDeviceFlags          |  x  |  x  |  x  |
> virDrvDomainGetAutostart               |  x  |  x  |  x  |
> virDrvDomainSetAutostart               |  x  |  x  |  x  | 
> virDrvDomainGetSchedulerType           |  x  |  x  |  x  |
> virDrvDomainGetSchedulerParameters     |  x  |  x  |  x  |
> virDrvDomainGetSchedulerParametersFlags|  x  |  x  |  x  |
> virDrvDomainSetSchedulerParameters     |  x  |  x  |  x  |
> virDrvDomainSetSchedulerParametersFlags|  x  |  x  |  x  |
> virDrvDomainMigratePrepare             |     |  x  |     |
> virDrvDomainMigratePerform             |  x  |  x  |     |
> virDrvDomainMigrateFinish              |     |  x  |     |
> virDrvDomainBlockResize                |  x  |     |     |
> virDrvDomainBlockStats                 |  x  |     |     |
> virDrvDomainBlockStatsFlags            |  x  |     |     |
> virDrvDomainInterfaceStats             |  x  |  x  |     |
> virDrvDomainSetInterfaceParameters     |  x  |     |     |
> virDrvDomainGetInterfaceParameters     |  x  |     |     |
> virDrvDomainMemoryStats                |  x  |     |     |
> virDrvDomainBlockPeek                  |  x  |  x  |     |
> virDrvDomainMemoryPeek                 |  x  |     |     |
> virDrvDomainGetBlockInfo               |  x  |     |     |
> virDrvNodeGetCPUStats                  |  x  |     |     |
> virDrvNodeGetMemoryStats               |  x  |     |     |
> virDrvNodeGetCellsFreeMemory           |  x  |  x  |     |
> virDrvNodeGetFreeMemory                |  x  |  x  |  x  |
> virDrvDomainEventRegister              |  x  |  x  |  x  |
> virDrvDomainEventDeregister            |  x  |  x  |  x  |
> virDrvDomainMigratePrepare2            |  x  |     |     |
> virDrvDomainMigrateFinish2             |  x  |     |     |
> virDrvNodeDeviceDettach                |  x  |  x  |     |
> virDrvNodeDeviceReAttach               |  x  |  x  |     |
> virDrvNodeDeviceReset                  |  x  |  x  |     |
> virDrvDomainMigratePrepareTunnel       |  x  |     |     |
> virDrvConnectIsEncrypted               |  x  |  x  |     |
> virDrvConnectIsSecure                  |  x  |  x  |     |
> virDrvDomainIsActive                   |  x  |  x  |  x  |
> virDrvDomainIsPersistent               |  x  |  x  |  x  |
> virDrvDomainIsUpdated                  |  x  |  x  |  x  |
> virDrvCompareCPU                       |  x  |     |     |
> virDrvBaselineCPU                      |  x  |     |     |
> virDrvDomainGetJobInfo                 |  x  |     |     |
> virDrvDomainAbortJob                   |  x  |     |     |
> virDrvDomainMigrateSetMaxDowntime      |  x  |     |     |
> virDrvDomainMigrateGetMaxSpeed         |  x  |     |     |
> virDrvDomainMigrateSetMaxSpeed         |  x  |     |     |
> virDrvDomainEventRegisterAny           |  x  |     |  x  |
> virDrvDomainEventDeregisterAny         |  x  |     |  x  |
> virDrvDomainManagedSave                |  x  |     |  x  |
> virDrvDomainHasManagedSaveImage        |  x  |     |  x  |
> virDrvDomainManagedSaveRemove          |  x  |     |  x  |
> virDrvDomainSnapshotCreateXML          |  x  |     |     |
> virDrvDomainSnapshotGetXMLDesc         |  x  |     |     |
> virDrvDomainSnapshotNum                |  x  |     |     |
> virDrvDomainSnapshotListNames          |  x  |     |     |
> virDrvDomainListAllSnapshots           |  x  |     |     |
> virDrvDomainSnapshotNumChildren        |  x  |     |     |
> virDrvDomainSnapshotListChildrenNames  |  x  |     |     |
> virDrvDomainSnapshotListAllChildren    |  x  |     |     |
> virDrvDomainSnapshotLookupByName       |  x  |     |     |
> virDrvDomainHasCurrentSnapshot         |  x  |     |     |
> virDrvDomainSnapshotGetParent          |  x  |     |     |
> virDrvDomainSnapshotCurrent            |  x  |     |     |
> virDrvDomainSnapshotIsCurrent          |  x  |     |     |
> virDrvDomainSnapshotHasMetadata        |  x  |     |     |
> virDrvDomainRevertToSnapshot           |  x  |     |     |
> virDrvDomainSnapshotDelete             |  x  |     |     |
> virDrvDomainQemuMonitorCommand         |  x  |     |     |
> virDrvDomainQemuAttach                 |  x  |     |     |
> virDrvDomainQemuAgentCommand           |  x  |     |     |
> virDrvDomainOpenConsole                |  x  |  x  |     |
> virDrvDomainOpenGraphics               |  x  |     |     |
> virDrvDomainInjectNMI                  |  x  |     |     |
> virDrvDomainMigrateBegin3              |  x  |     |     |
> virDrvDomainMigratePrepare3            |  x  |     |     |
> virDrvDomainMigratePrepareTunnel3      |  x  |     |     |
> virDrvDomainMigratePerform3            |  x  |     |     |
> virDrvDomainMigrateFinish3             |  x  |     |     |
> virDrvDomainMigrateConfirm3            |  x  |     |     |
> virDrvDomainSendKey                    |  x  |     |     |
> virDrvDomainBlockJobAbort              |  x  |     |     |
> virDrvDomainGetBlockJobInfo            |  x  |     |     |
> virDrvDomainBlockJobSetSpeed           |  x  |     |     |
> virDrvDomainBlockPull                  |  x  |     |     |
> virDrvDomainBlockRebase                |  x  |     |     |
> virDrvDomainBlockCommit                |  x  |     |     |
> virDrvSetKeepAlive                     |     |     |     |
> virDrvConnectIsAlive                   |  x  |     |     |
> virDrvNodeSuspendForDuration           |  x  |  x  |     |
> virDrvDomainSetBlockIoTune             |  x  |     |     |
> virDrvDomainGetBlockIoTune             |  x  |     |     |
> virDrvDomainGetCPUStats                |  x  |     |     |
> virDrvDomainGetDiskErrors              |  x  |     |     |
> virDrvDomainSetMetadata                |  x  |     |     |
> virDrvDomainGetMetadata                |  x  |     |     |
> virDrvNodeGetMemoryParameters          |  x  |  x  |     |
> virDrvNodeSetMemoryParameters          |  x  |  x  |     |
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 13:00:46 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 13:00:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRjWO-00087L-KF; Fri, 26 Oct 2012 13:00:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRjWM-00087F-Vm
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 13:00:19 +0000
Received: from [85.158.143.35:20121] by server-3.bemta-4.messagelabs.com id
	DB/9B-24279-2698A805; Fri, 26 Oct 2012 13:00:18 +0000
X-Env-Sender: ijc@hellion.org.uk
X-Msg-Ref: server-11.tower-21.messagelabs.com!1351256408!11460864!1
X-Originating-IP: [212.110.190.137]
X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD,
	ML_RADAR_SPEW_LINKS_22,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9309 invoked from network); 26 Oct 2012 13:00:08 -0000
Received: from benson.vm.bytemark.co.uk (HELO benson.vm.bytemark.co.uk)
	(212.110.190.137)
	by server-11.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Oct 2012 13:00:08 -0000
Received: from cpc22-cmbg14-2-0-cust482.5-4.cable.virginmedia.com
	([86.6.25.227] helo=hopkins.hellion.org.uk)
	by benson.vm.bytemark.co.uk with esmtpsa
	(TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72)
	(envelope-from )
	id 1TRjWA-0003sN-Fu; Fri, 26 Oct 2012 14:00:06 +0100
Received: from firewall.ctxuk.citrix.com ([62.200.22.2] helo=[10.80.2.42])
	by hopkins.hellion.org.uk with esmtpsa (SSL3.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TRjW3-0000Ew-Pq; Fri, 26 Oct 2012 14:00:05 +0100
Message-ID: <1351256392.15162.76.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: xen-devel@lists.xen.org
Date: Fri, 26 Oct 2012 13:59:52 +0100
Content-Type: multipart/mixed; boundary="=-E0x8ea9EY6y+T/d7gUWv"
X-Mailer: Evolution 3.4.3-1 
Mime-Version: 1.0
X-SA-Exim-Connect-IP: 62.200.22.2
X-SA-Exim-Mail-From: ijc@hellion.org.uk
X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000)
X-SA-Exim-Scanned: Yes (on hopkins.hellion.org.uk)
Cc: 599161@bugs.debian.org
Subject: [Xen-devel] #599161: Xen debug patch for the "clock shifts by 50
	minutes" bug.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--=-E0x8ea9EY6y+T/d7gUWv
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

Hi all,

I've BCC'd a number of people who have reported seeing this bug at
various times in the past.

If you can still repro I'd appreciate it if you could give the patch in
http://marc.info/?l=xen-devel&m=135049062216685&w=2 (also attached) a go
and report back success/failure and the output of the debugging messages
produced.

Thanks,
Ian.

-- 
Ian Campbell
Current Noise: Death - Evil Dead

Executive ability is prominent in your make-up.

--=-E0x8ea9EY6y+T/d7gUWv
Content-Disposition: attachment; filename="00-tsc-debug"
Content-Type: text/x-patch; name="00-tsc-debug"; charset="UTF-8"
Content-Transfer-Encoding: 7bit

diff -r c1c549c4fe9e xen/arch/x86/time.c
--- a/xen/arch/x86/time.c	Mon Oct 15 16:51:44 2012 +0100
+++ b/xen/arch/x86/time.c	Wed Oct 17 17:13:22 2012 +0100
@@ -523,11 +523,12 @@ static s_time_t __read_platform_stime(u6
 static void plt_overflow(void *unused)
 {
     int i;
-    u64 count;
+    u64 count, old_stamp, tsc;
     s_time_t now, plt_now, plt_wrap;
 
     spin_lock_irq(&platform_timer_lock);
 
+    old_stamp = plt_stamp;
     count = plt_src.read_counter();
     plt_stamp64 += (count - plt_stamp) & plt_mask;
     plt_stamp = count;
@@ -540,6 +541,14 @@ static void plt_overflow(void *unused)
         plt_wrap = __read_platform_stime(plt_stamp64 + plt_mask + 1);
         if ( ABS(plt_wrap - now) > ABS(plt_now - now) )
             break;
+        rdtscll(tsc);
+        printk("XXX plt_overflow: plt_now=%"PRIx64" plt_wrap=%"PRIx64
+               " now=%"PRIx64" old_stamp=%"PRIx64" new_stamp=%"PRIx64
+               " plt_stamp64=%"PRIx64" plt_mask=%"PRIx64
+               " tsc=%"PRIx64" tsc_stamp=%"PRIx64"\n",
+               plt_now, plt_wrap, now, old_stamp, plt_stamp, plt_stamp64,
+               plt_mask, tsc, this_cpu(cpu_time).local_tsc_stamp);
+        break;
         plt_stamp64 += plt_mask + 1;
     }
     if ( i != 0 )

--=-E0x8ea9EY6y+T/d7gUWv
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=-E0x8ea9EY6y+T/d7gUWv--



From xen-devel-bounces@lists.xen.org Fri Oct 26 13:00:46 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 13:00:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRjWO-00087L-KF; Fri, 26 Oct 2012 13:00:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRjWM-00087F-Vm
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 13:00:19 +0000
Received: from [85.158.143.35:20121] by server-3.bemta-4.messagelabs.com id
	DB/9B-24279-2698A805; Fri, 26 Oct 2012 13:00:18 +0000
X-Env-Sender: ijc@hellion.org.uk
X-Msg-Ref: server-11.tower-21.messagelabs.com!1351256408!11460864!1
X-Originating-IP: [212.110.190.137]
X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD,
	ML_RADAR_SPEW_LINKS_22,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9309 invoked from network); 26 Oct 2012 13:00:08 -0000
Received: from benson.vm.bytemark.co.uk (HELO benson.vm.bytemark.co.uk)
	(212.110.190.137)
	by server-11.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Oct 2012 13:00:08 -0000
Received: from cpc22-cmbg14-2-0-cust482.5-4.cable.virginmedia.com
	([86.6.25.227] helo=hopkins.hellion.org.uk)
	by benson.vm.bytemark.co.uk with esmtpsa
	(TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72)
	(envelope-from )
	id 1TRjWA-0003sN-Fu; Fri, 26 Oct 2012 14:00:06 +0100
Received: from firewall.ctxuk.citrix.com ([62.200.22.2] helo=[10.80.2.42])
	by hopkins.hellion.org.uk with esmtpsa (SSL3.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TRjW3-0000Ew-Pq; Fri, 26 Oct 2012 14:00:05 +0100
Message-ID: <1351256392.15162.76.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: xen-devel@lists.xen.org
Date: Fri, 26 Oct 2012 13:59:52 +0100
Content-Type: multipart/mixed; boundary="=-E0x8ea9EY6y+T/d7gUWv"
X-Mailer: Evolution 3.4.3-1 
Mime-Version: 1.0
X-SA-Exim-Connect-IP: 62.200.22.2
X-SA-Exim-Mail-From: ijc@hellion.org.uk
X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000)
X-SA-Exim-Scanned: Yes (on hopkins.hellion.org.uk)
Cc: 599161@bugs.debian.org
Subject: [Xen-devel] #599161: Xen debug patch for the "clock shifts by 50
	minutes" bug.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--=-E0x8ea9EY6y+T/d7gUWv
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

Hi all,

I've BCC'd a number of people who have reported seeing this bug at
various times in the past.

If you can still repro I'd appreciate it if you could give the patch in
http://marc.info/?l=xen-devel&m=135049062216685&w=2 (also attached) a go
and report back success/failure and the output of the debugging messages
produced.

Thanks,
Ian.

-- 
Ian Campbell
Current Noise: Death - Evil Dead

Executive ability is prominent in your make-up.

--=-E0x8ea9EY6y+T/d7gUWv
Content-Disposition: attachment; filename="00-tsc-debug"
Content-Type: text/x-patch; name="00-tsc-debug"; charset="UTF-8"
Content-Transfer-Encoding: 7bit

diff -r c1c549c4fe9e xen/arch/x86/time.c
--- a/xen/arch/x86/time.c	Mon Oct 15 16:51:44 2012 +0100
+++ b/xen/arch/x86/time.c	Wed Oct 17 17:13:22 2012 +0100
@@ -523,11 +523,12 @@ static s_time_t __read_platform_stime(u6
 static void plt_overflow(void *unused)
 {
     int i;
-    u64 count;
+    u64 count, old_stamp, tsc;
     s_time_t now, plt_now, plt_wrap;
 
     spin_lock_irq(&platform_timer_lock);
 
+    old_stamp = plt_stamp;
     count = plt_src.read_counter();
     plt_stamp64 += (count - plt_stamp) & plt_mask;
     plt_stamp = count;
@@ -540,6 +541,14 @@ static void plt_overflow(void *unused)
         plt_wrap = __read_platform_stime(plt_stamp64 + plt_mask + 1);
         if ( ABS(plt_wrap - now) > ABS(plt_now - now) )
             break;
+        rdtscll(tsc);
+        printk("XXX plt_overflow: plt_now=%"PRIx64" plt_wrap=%"PRIx64
+               " now=%"PRIx64" old_stamp=%"PRIx64" new_stamp=%"PRIx64
+               " plt_stamp64=%"PRIx64" plt_mask=%"PRIx64
+               " tsc=%"PRIx64" tsc_stamp=%"PRIx64"\n",
+               plt_now, plt_wrap, now, old_stamp, plt_stamp, plt_stamp64,
+               plt_mask, tsc, this_cpu(cpu_time).local_tsc_stamp);
+        break;
         plt_stamp64 += plt_mask + 1;
     }
     if ( i != 0 )

--=-E0x8ea9EY6y+T/d7gUWv
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=-E0x8ea9EY6y+T/d7gUWv--



From xen-devel-bounces@lists.xen.org Fri Oct 26 13:09:56 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 13:09:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRjfL-0008Rc-QN; Fri, 26 Oct 2012 13:09:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRjfK-0008RX-Rk
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 13:09:35 +0000
Received: from [85.158.139.83:48510] by server-11.bemta-5.messagelabs.com id
	6C/7B-14870-D8B8A805; Fri, 26 Oct 2012 13:09:33 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1351256972!27379644!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODE4MDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7433 invoked from network); 26 Oct 2012 13:09:33 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 13:09:33 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="212549535"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 13:08:43 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 09:08:42 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TRjeU-0005Yy-Ap;
	Fri, 26 Oct 2012 14:08:42 +0100
Message-ID: <508A8A25.3010505@eu.citrix.com>
Date: Fri, 26 Oct 2012 14:03:33 +0100
From: George Dunlap 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: Jim Fehlig 
References: 
	<50882F59.6070203@suse.com>
In-Reply-To: <50882F59.6070203@suse.com>
Cc: Ian Campbell ,
	Dario Faggioli ,
	Ian Jackson , Chun Yan Liu ,
	"xen-devel@lists.xen.org" ,
	Ondrej Holecek , Bamvor Jian Zhang 
Subject: Re: [Xen-devel] libxl drivers for libvirt?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 24/10/12 19:11, Jim Fehlig wrote:
>> * What kind of Xen support for libxl is in the libvirt development
>> branch, and do you have an idea when full support for 4.2 (at least,
>> including migration, suspend/resume, &c) might be available?
> Nothing has changed in git master over what is available in 0.10.2, but
> we are now starting to pick up this work.  Our priorities are to first
> get the libxl driver compiling against 4.2 and all of the existing
> functionality that works with 4.1 working with 4.2, followed by closing
> the feature gap with the legacy xen driver, and finally closing the
> feature gap with the qemu driver where it makes sense.  This is
> obviously quite a bit of work and any help would be appreciated :).
>
> BTW, we don't have any motivation to add features to the 4.1 version of
> the libvirt libxl driver.

That sounds like a good plan.  For 4.1, xend is still the default 
toolstack, and libxl is a "tech preview"; for 4.2, xl is the default 
toolstack, and (if I understand correctly) we're officially going to be 
supporting the libxl interface in a backwards-compatible way from here 
forward.

It seems to me that if you have trouble supporting both libxl 4.2 and 
libxl 4.1, that it might be better just to drop 4.1 support and focus on 
4.2.  Ian Campbell / Jackson: Thoughts?

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 13:09:56 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 13:09:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRjfL-0008Rc-QN; Fri, 26 Oct 2012 13:09:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRjfK-0008RX-Rk
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 13:09:35 +0000
Received: from [85.158.139.83:48510] by server-11.bemta-5.messagelabs.com id
	6C/7B-14870-D8B8A805; Fri, 26 Oct 2012 13:09:33 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1351256972!27379644!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODE4MDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7433 invoked from network); 26 Oct 2012 13:09:33 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 13:09:33 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="212549535"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 13:08:43 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 09:08:42 -0400
Received: from elijah.uk.xensource.com ([10.80.2.24])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TRjeU-0005Yy-Ap;
	Fri, 26 Oct 2012 14:08:42 +0100
Message-ID: <508A8A25.3010505@eu.citrix.com>
Date: Fri, 26 Oct 2012 14:03:33 +0100
From: George Dunlap 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: Jim Fehlig 
References: 
	<50882F59.6070203@suse.com>
In-Reply-To: <50882F59.6070203@suse.com>
Cc: Ian Campbell ,
	Dario Faggioli ,
	Ian Jackson , Chun Yan Liu ,
	"xen-devel@lists.xen.org" ,
	Ondrej Holecek , Bamvor Jian Zhang 
Subject: Re: [Xen-devel] libxl drivers for libvirt?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 24/10/12 19:11, Jim Fehlig wrote:
>> * What kind of Xen support for libxl is in the libvirt development
>> branch, and do you have an idea when full support for 4.2 (at least,
>> including migration, suspend/resume, &c) might be available?
> Nothing has changed in git master over what is available in 0.10.2, but
> we are now starting to pick up this work.  Our priorities are to first
> get the libxl driver compiling against 4.2 and all of the existing
> functionality that works with 4.1 working with 4.2, followed by closing
> the feature gap with the legacy xen driver, and finally closing the
> feature gap with the qemu driver where it makes sense.  This is
> obviously quite a bit of work and any help would be appreciated :).
>
> BTW, we don't have any motivation to add features to the 4.1 version of
> the libvirt libxl driver.

That sounds like a good plan.  For 4.1, xend is still the default 
toolstack, and libxl is a "tech preview"; for 4.2, xl is the default 
toolstack, and (if I understand correctly) we're officially going to be 
supporting the libxl interface in a backwards-compatible way from here 
forward.

It seems to me that if you have trouble supporting both libxl 4.2 and 
libxl 4.1, that it might be better just to drop 4.1 support and focus on 
4.2.  Ian Campbell / Jackson: Thoughts?

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 13:13:39 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 13:13:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRjir-0000Bc-F4; Fri, 26 Oct 2012 13:13:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRjiq-0000BR-1r
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 13:13:12 +0000
Received: from [85.158.139.83:39084] by server-7.bemta-5.messagelabs.com id
	20/83-23102-76C8A805; Fri, 26 Oct 2012 13:13:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1351257190!26925473!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24860 invoked from network); 26 Oct 2012 13:13:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 13:13:10 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15411189"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 13:12:42 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 14:12:42 +0100
Message-ID: <1351257160.15162.82.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: =?UTF-8?Q?Ond=C5=99ej_Hole=C4=8Dek?= 
Date: Fri, 26 Oct 2012 14:12:40 +0100
In-Reply-To: <5728419.j1LincOg6h@aaannz-nb.suse.cz>
References: 
	<50882F59.6070203@suse.com> <5728419.j1LincOg6h@aaannz-nb.suse.cz>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: George Dunlap ,
	Dario Faggioli , Chun Yan Liu ,
	"xen-devel@lists.xen.org" ,
	Jim Fehlig , Bamvor Jian Zhang 
Subject: Re: [Xen-devel] libxl drivers for libvirt?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gRnJpLCAyMDEyLTEwLTI2IGF0IDEzOjU0ICswMTAwLCBPbmTFmWVqIEhvbGXEjWVrIHdyb3Rl
Ogo+IEkgd291bGQgZGVmaW5pdGVseSBhcHByZWNpYXRlIGFueSBkZXRhaWxlZCBvdmVydmlldyB3
aGF0IGFuZCB3aHkKPiBjaGFuZ2VkIGJldHdlZW4gNC4xIGFuZCA0LjIgbGlieGwgaWZhY2UuIAoK
QSB3aG9sZSB0b25uZSBvZiBzdHVmZiBJJ20gYWZyYWlkIDotLwoKVGhlIGJpZ2dlciB0aGluZ3Mg
d2hpY2ggc3ByaW5nIHRvIG1pbmQgYXJlOgogICAgICAqIFRoZSBldmVudCBoYW5kbGluZyBzdWJz
eXN0ZW0uIFRoaXMgd2FzIGRlc2lnbmVkIHNwZWNpZmljYWxseQogICAgICAgIHdpdGggbGlidmly
dCBpbiBtaW5kIHNvIEkgaG9wZSB0aGV5IHdvcmsgd2VsbCBmb3IgeW91LgogICAgICAqIE1ha2lu
ZyBBUElzIGNhcGFibGUgb2YgYmVpbmcgY2FsbGVkIGFzeW5jaHJvbm91c2x5IHdoZXJlCiAgICAg
ICAgbmVjZXNzYXJ5LiBUaGlzIHNob3VsZCBiZW5lZml0IHRvb2xzdGFja3Mgd2l0aCBhIGRhZW1v
biB3aGljaAogICAgICAgIG1hbmFnZXMgbXVsdGlwbGUgZG9tYWlucy4KICAgICAgKiBGaXhlcyB0
byB0aGUgaGFuZGxpbmcgb2YgZm9ya2luZyBhbmQgc2lnbmFscyBldGMuIFRoZXNlIGFyZQogICAg
ICAgIHByb2JsZW1hdGljIHRvIHVzZSBpbiBhIGxpYnJhcnkgYnV0IHdlIHRoaW5rIHdlJ3ZlIGNv
bWUgdXAgd2l0aAogICAgICAgIGEgc29sdXRpb24gd2hpY2ggd29ya3MuIElhbiBKIGJsb2dnZWQg
YWJvdXQgdGhpcyBbMV0uCiAgICAgICogVHdlYWtzIHRvIHRoZSBBUEkgdG8gbWFrZSB0aGVtIG1v
cmUgY29uc2lzdGVudCBhbmQgc3ltbWV0cmljLAogICAgICAgIG1vc3RseSB0byBmaWxlIHNvbWUg
b2YgdGhlIHJvdWdodCBlZGdlcy9nb3RjaGFzIHVzIGJlZm9yZQogICAgICAgIGNhbGxpbmcgdGhl
IEFQSSBzdGFibGUgYW5kIHRvIGdpdmUgdXMgc29tZXRoaW5nIHdoaWNoIHdlIHdlcmUKICAgICAg
ICBoYXBweSB0byBzdXBwb3J0IGdvaW5nIGZvcndhcmQuCgpUaGUgdXBzaWRlIGlzIHRoYXQgaW4g
NC4yIHdlIGhhdmUgYSBsaWJ4bCBBUEkgd2hpY2ggd2UgYXJlIGNvbW1pdHRlZCB0bwptYWludGFp
bmluZyBpbiBhIHN0YWJsZSAvIGJhY2t3YXJkcyBjb21wYXRpYmxlIG1hbm5lciwgYXMgZGVzY3Jp
YmVkIGluCmxpYnhsLmhbMF0uCgpJYW4uClswXQpodHRwOi8veGVuYml0cy54ZW4ub3JnL2hnL3hl
bi11bnN0YWJsZS5oZy9maWxlL3RpcC90b29scy9saWJ4bC9saWJ4bC5oI2wxNgpbMV0KaHR0cDov
L2Jsb2cueGVuLm9yZy9pbmRleC5waHAvMjAxMi8wNS8yMi9saWJ4bC1ldmVudC1hcGktaW1wcm92
ZW1lbnRzLwoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Clhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xp
c3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Fri Oct 26 13:13:39 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 13:13:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRjir-0000Bc-F4; Fri, 26 Oct 2012 13:13:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRjiq-0000BR-1r
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 13:13:12 +0000
Received: from [85.158.139.83:39084] by server-7.bemta-5.messagelabs.com id
	20/83-23102-76C8A805; Fri, 26 Oct 2012 13:13:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1351257190!26925473!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24860 invoked from network); 26 Oct 2012 13:13:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 13:13:10 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15411189"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 13:12:42 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 14:12:42 +0100
Message-ID: <1351257160.15162.82.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: =?UTF-8?Q?Ond=C5=99ej_Hole=C4=8Dek?= 
Date: Fri, 26 Oct 2012 14:12:40 +0100
In-Reply-To: <5728419.j1LincOg6h@aaannz-nb.suse.cz>
References: 
	<50882F59.6070203@suse.com> <5728419.j1LincOg6h@aaannz-nb.suse.cz>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: George Dunlap ,
	Dario Faggioli , Chun Yan Liu ,
	"xen-devel@lists.xen.org" ,
	Jim Fehlig , Bamvor Jian Zhang 
Subject: Re: [Xen-devel] libxl drivers for libvirt?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gRnJpLCAyMDEyLTEwLTI2IGF0IDEzOjU0ICswMTAwLCBPbmTFmWVqIEhvbGXEjWVrIHdyb3Rl
Ogo+IEkgd291bGQgZGVmaW5pdGVseSBhcHByZWNpYXRlIGFueSBkZXRhaWxlZCBvdmVydmlldyB3
aGF0IGFuZCB3aHkKPiBjaGFuZ2VkIGJldHdlZW4gNC4xIGFuZCA0LjIgbGlieGwgaWZhY2UuIAoK
QSB3aG9sZSB0b25uZSBvZiBzdHVmZiBJJ20gYWZyYWlkIDotLwoKVGhlIGJpZ2dlciB0aGluZ3Mg
d2hpY2ggc3ByaW5nIHRvIG1pbmQgYXJlOgogICAgICAqIFRoZSBldmVudCBoYW5kbGluZyBzdWJz
eXN0ZW0uIFRoaXMgd2FzIGRlc2lnbmVkIHNwZWNpZmljYWxseQogICAgICAgIHdpdGggbGlidmly
dCBpbiBtaW5kIHNvIEkgaG9wZSB0aGV5IHdvcmsgd2VsbCBmb3IgeW91LgogICAgICAqIE1ha2lu
ZyBBUElzIGNhcGFibGUgb2YgYmVpbmcgY2FsbGVkIGFzeW5jaHJvbm91c2x5IHdoZXJlCiAgICAg
ICAgbmVjZXNzYXJ5LiBUaGlzIHNob3VsZCBiZW5lZml0IHRvb2xzdGFja3Mgd2l0aCBhIGRhZW1v
biB3aGljaAogICAgICAgIG1hbmFnZXMgbXVsdGlwbGUgZG9tYWlucy4KICAgICAgKiBGaXhlcyB0
byB0aGUgaGFuZGxpbmcgb2YgZm9ya2luZyBhbmQgc2lnbmFscyBldGMuIFRoZXNlIGFyZQogICAg
ICAgIHByb2JsZW1hdGljIHRvIHVzZSBpbiBhIGxpYnJhcnkgYnV0IHdlIHRoaW5rIHdlJ3ZlIGNv
bWUgdXAgd2l0aAogICAgICAgIGEgc29sdXRpb24gd2hpY2ggd29ya3MuIElhbiBKIGJsb2dnZWQg
YWJvdXQgdGhpcyBbMV0uCiAgICAgICogVHdlYWtzIHRvIHRoZSBBUEkgdG8gbWFrZSB0aGVtIG1v
cmUgY29uc2lzdGVudCBhbmQgc3ltbWV0cmljLAogICAgICAgIG1vc3RseSB0byBmaWxlIHNvbWUg
b2YgdGhlIHJvdWdodCBlZGdlcy9nb3RjaGFzIHVzIGJlZm9yZQogICAgICAgIGNhbGxpbmcgdGhl
IEFQSSBzdGFibGUgYW5kIHRvIGdpdmUgdXMgc29tZXRoaW5nIHdoaWNoIHdlIHdlcmUKICAgICAg
ICBoYXBweSB0byBzdXBwb3J0IGdvaW5nIGZvcndhcmQuCgpUaGUgdXBzaWRlIGlzIHRoYXQgaW4g
NC4yIHdlIGhhdmUgYSBsaWJ4bCBBUEkgd2hpY2ggd2UgYXJlIGNvbW1pdHRlZCB0bwptYWludGFp
bmluZyBpbiBhIHN0YWJsZSAvIGJhY2t3YXJkcyBjb21wYXRpYmxlIG1hbm5lciwgYXMgZGVzY3Jp
YmVkIGluCmxpYnhsLmhbMF0uCgpJYW4uClswXQpodHRwOi8veGVuYml0cy54ZW4ub3JnL2hnL3hl
bi11bnN0YWJsZS5oZy9maWxlL3RpcC90b29scy9saWJ4bC9saWJ4bC5oI2wxNgpbMV0KaHR0cDov
L2Jsb2cueGVuLm9yZy9pbmRleC5waHAvMjAxMi8wNS8yMi9saWJ4bC1ldmVudC1hcGktaW1wcm92
ZW1lbnRzLwoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Clhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xp
c3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Fri Oct 26 13:18:45 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 13:18:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRjnx-0000M9-6w; Fri, 26 Oct 2012 13:18:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRjnv-0000M2-En
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 13:18:27 +0000
Received: from [85.158.143.99:51061] by server-1.bemta-4.messagelabs.com id
	45/90-19134-2AD8A805; Fri, 26 Oct 2012 13:18:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1351257503!26605730!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1848 invoked from network); 26 Oct 2012 13:18:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 13:18:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15411307"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 13:18:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 14:18:23 +0100
Message-ID: <1351257501.15162.85.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: George Dunlap 
Date: Fri, 26 Oct 2012 14:18:21 +0100
In-Reply-To: <508A8A25.3010505@eu.citrix.com>
References: 
	<50882F59.6070203@suse.com> <508A8A25.3010505@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Dario Faggioli ,
	Ian Jackson , Chun Yan Liu ,
	"xen-devel@lists.xen.org" ,
	Jim Fehlig , Ondrej Holecek ,
	Bamvor Jian Zhang 
Subject: Re: [Xen-devel] libxl drivers for libvirt?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-26 at 14:03 +0100, George Dunlap wrote:
> On 24/10/12 19:11, Jim Fehlig wrote:
> >> * What kind of Xen support for libxl is in the libvirt development
> >> branch, and do you have an idea when full support for 4.2 (at least,
> >> including migration, suspend/resume, &c) might be available?
> > Nothing has changed in git master over what is available in 0.10.2, but
> > we are now starting to pick up this work.  Our priorities are to first
> > get the libxl driver compiling against 4.2 and all of the existing
> > functionality that works with 4.1 working with 4.2, followed by closing
> > the feature gap with the legacy xen driver, and finally closing the
> > feature gap with the qemu driver where it makes sense.  This is
> > obviously quite a bit of work and any help would be appreciated :).
> >
> > BTW, we don't have any motivation to add features to the 4.1 version of
> > the libvirt libxl driver.
> 
> That sounds like a good plan.  For 4.1, xend is still the default 
> toolstack, and libxl is a "tech preview"; for 4.2, xl is the default 
> toolstack, and (if I understand correctly) we're officially going to be 
> supporting the libxl interface in a backwards-compatible way from here 
> forward.
> 
> It seems to me that if you have trouble supporting both libxl 4.2 and 
> libxl 4.1, that it might be better just to drop 4.1 support and focus on 
> 4.2.  Ian Campbell / Jackson: Thoughts?

That's what I would do if I were them ;-)

Another option would be to fork into 4.1 and 4.2+ versions and to stop
adding new stuff to the 4.1 copy. That has its own downsides though.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 13:18:45 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 13:18:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRjnx-0000M9-6w; Fri, 26 Oct 2012 13:18:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRjnv-0000M2-En
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 13:18:27 +0000
Received: from [85.158.143.99:51061] by server-1.bemta-4.messagelabs.com id
	45/90-19134-2AD8A805; Fri, 26 Oct 2012 13:18:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1351257503!26605730!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1848 invoked from network); 26 Oct 2012 13:18:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 13:18:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15411307"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 13:18:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 14:18:23 +0100
Message-ID: <1351257501.15162.85.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: George Dunlap 
Date: Fri, 26 Oct 2012 14:18:21 +0100
In-Reply-To: <508A8A25.3010505@eu.citrix.com>
References: 
	<50882F59.6070203@suse.com> <508A8A25.3010505@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Dario Faggioli ,
	Ian Jackson , Chun Yan Liu ,
	"xen-devel@lists.xen.org" ,
	Jim Fehlig , Ondrej Holecek ,
	Bamvor Jian Zhang 
Subject: Re: [Xen-devel] libxl drivers for libvirt?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-26 at 14:03 +0100, George Dunlap wrote:
> On 24/10/12 19:11, Jim Fehlig wrote:
> >> * What kind of Xen support for libxl is in the libvirt development
> >> branch, and do you have an idea when full support for 4.2 (at least,
> >> including migration, suspend/resume, &c) might be available?
> > Nothing has changed in git master over what is available in 0.10.2, but
> > we are now starting to pick up this work.  Our priorities are to first
> > get the libxl driver compiling against 4.2 and all of the existing
> > functionality that works with 4.1 working with 4.2, followed by closing
> > the feature gap with the legacy xen driver, and finally closing the
> > feature gap with the qemu driver where it makes sense.  This is
> > obviously quite a bit of work and any help would be appreciated :).
> >
> > BTW, we don't have any motivation to add features to the 4.1 version of
> > the libvirt libxl driver.
> 
> That sounds like a good plan.  For 4.1, xend is still the default 
> toolstack, and libxl is a "tech preview"; for 4.2, xl is the default 
> toolstack, and (if I understand correctly) we're officially going to be 
> supporting the libxl interface in a backwards-compatible way from here 
> forward.
> 
> It seems to me that if you have trouble supporting both libxl 4.2 and 
> libxl 4.1, that it might be better just to drop 4.1 support and focus on 
> 4.2.  Ian Campbell / Jackson: Thoughts?

That's what I would do if I were them ;-)

Another option would be to fork into 4.1 and 4.2+ versions and to stop
adding new stuff to the 4.1 copy. That has its own downsides though.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 14:00:53 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 14:00:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRkSe-0001nZ-JG; Fri, 26 Oct 2012 14:00:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRkSd-0001nU-CZ
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 14:00:31 +0000
Received: from [85.158.143.99:54314] by server-2.bemta-4.messagelabs.com id
	3D/6E-22268-E779A805; Fri, 26 Oct 2012 14:00:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1351260025!16311756!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22636 invoked from network); 26 Oct 2012 14:00:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 14:00:25 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15412393"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 14:00:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 26 Oct 2012 15:00:25 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TRkSW-0008AY-SW; Fri, 26 Oct 2012 14:00:24 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TRkSW-0002Cu-Lu;
	Fri, 26 Oct 2012 15:00:24 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20618.38776.290496.314961@mariner.uk.xensource.com>
Date: Fri, 26 Oct 2012 15:00:24 +0100
To: George Dunlap 
In-Reply-To: <508A8A25.3010505@eu.citrix.com>
References: 
	<50882F59.6070203@suse.com> <508A8A25.3010505@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Campbell ,
	Dario Faggioli , Chun Yan Liu ,
	"xen-devel@lists.xen.org" ,
	Jim Fehlig , Ondrej Holecek ,
	Bamvor Jian Zhang 
Subject: Re: [Xen-devel] libxl drivers for libvirt?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("Re: [Xen-devel] libxl drivers for libvirt?"):
> That sounds like a good plan.  For 4.1, xend is still the default 
> toolstack, and libxl is a "tech preview"; for 4.2, xl is the default 
> toolstack, and (if I understand correctly) we're officially going to be 
> supporting the libxl interface in a backwards-compatible way from here 
> forward.

Yes.

> It seems to me that if you have trouble supporting both libxl 4.2 and 
> libxl 4.1, that it might be better just to drop 4.1 support and focus on 
> 4.2.  Ian Campbell / Jackson: Thoughts?

Yes, I agree.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 14:00:53 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 14:00:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRkSe-0001nZ-JG; Fri, 26 Oct 2012 14:00:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRkSd-0001nU-CZ
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 14:00:31 +0000
Received: from [85.158.143.99:54314] by server-2.bemta-4.messagelabs.com id
	3D/6E-22268-E779A805; Fri, 26 Oct 2012 14:00:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1351260025!16311756!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22636 invoked from network); 26 Oct 2012 14:00:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 14:00:25 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15412393"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 14:00:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 26 Oct 2012 15:00:25 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TRkSW-0008AY-SW; Fri, 26 Oct 2012 14:00:24 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TRkSW-0002Cu-Lu;
	Fri, 26 Oct 2012 15:00:24 +0100
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20618.38776.290496.314961@mariner.uk.xensource.com>
Date: Fri, 26 Oct 2012 15:00:24 +0100
To: George Dunlap 
In-Reply-To: <508A8A25.3010505@eu.citrix.com>
References: 
	<50882F59.6070203@suse.com> <508A8A25.3010505@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Campbell ,
	Dario Faggioli , Chun Yan Liu ,
	"xen-devel@lists.xen.org" ,
	Jim Fehlig , Ondrej Holecek ,
	Bamvor Jian Zhang 
Subject: Re: [Xen-devel] libxl drivers for libvirt?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap writes ("Re: [Xen-devel] libxl drivers for libvirt?"):
> That sounds like a good plan.  For 4.1, xend is still the default 
> toolstack, and libxl is a "tech preview"; for 4.2, xl is the default 
> toolstack, and (if I understand correctly) we're officially going to be 
> supporting the libxl interface in a backwards-compatible way from here 
> forward.

Yes.

> It seems to me that if you have trouble supporting both libxl 4.2 and 
> libxl 4.1, that it might be better just to drop 4.1 support and focus on 
> 4.2.  Ian Campbell / Jackson: Thoughts?

Yes, I agree.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 14:02:38 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 14:02:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRkUK-0001vu-2g; Fri, 26 Oct 2012 14:02:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRkUI-0001vk-1E
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 14:02:14 +0000
Received: from [85.158.143.35:56632] by server-2.bemta-4.messagelabs.com id
	FA/21-22268-5E79A805; Fri, 26 Oct 2012 14:02:13 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1351260046!12564681!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzE1Njk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6201 invoked from network); 26 Oct 2012 14:00:49 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-12.tower-21.messagelabs.com with SMTP;
	26 Oct 2012 14:00:49 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 26 Oct 2012 07:00:45 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,654,1344236400"; 
	d="scan'208,223";a="232926308"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by orsmga002.jf.intel.com with ESMTP; 26 Oct 2012 07:00:40 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 26 Oct 2012 07:00:39 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.123]) with mapi id
	14.01.0355.002; Fri, 26 Oct 2012 22:00:37 +0800
From: "Liu, Jinsong" 
To: "konrad.wilk@oracle.com" , Jan Beulich
	
Thread-Topic: [Xen-devel] [PATCH 1/2] Xen acpi pad implement
Thread-Index: AQHNs3G2Ti91BiFLfUibRvXA4zlK85fLgkyggAAZxiA=
Date: Fri, 26 Oct 2012 14:00:36 +0000
Message-ID: 
References: 
	<5089676602000078000A4928@nat28.tlf.novell.com>
	
	<508A89CB020000780008E6ED@nat28.tlf.novell.com>
	
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC829233537292ESHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk ,
	"linux-kernel@vger.kernel.org" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 1/2] Xen acpi pad implement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC829233537292ESHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Updated per Jan's comments.

Thanks,
Jinsong

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

>From e6d4eceba9538c6873f9c970425e65e257fd9bf0 Mon Sep 17 00:00:00 2001
From: Liu, Jinsong 
Date: Sat, 27 Oct 2012 05:34:50 +0800
Subject: [PATCH 1/2] Xen acpi pad implement

PAD is acpi Processor Aggregator Device which provides a control point
that enables the platform to perform specific processor configuration
and control that applies to all processors in the platform.

This patch is to implement Xen acpi pad logic. When running under Xen
virt platform, native pad driver would not work. Instead Xen pad driver,
a self-contained and very thin logic level, would take over acpi pad staff.
When acpi pad notify OSPM, xen pad logic intercept and parse _PUR object
and then hypercall to hyervisor for the rest work, say, core parking.

Signed-off-by: Liu, Jinsong 
---
 drivers/xen/Makefile             |    1 +
 drivers/xen/xen_acpi_pad.c       |  201 ++++++++++++++++++++++++++++++++++=
++++
 include/xen/interface/platform.h |   17 +++
 3 files changed, 219 insertions(+), 0 deletions(-)
 create mode 100644 drivers/xen/xen_acpi_pad.c

diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 0e86370..a2af622 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_XEN_MCE_LOG)		+=3D mcelog.o
 obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+=3D xen-pciback/
 obj-$(CONFIG_XEN_PRIVCMD)		+=3D xen-privcmd.o
 obj-$(CONFIG_XEN_ACPI_PROCESSOR)	+=3D xen-acpi-processor.o
+obj-$(CONFIG_XEN_DOM0)			+=3D xen_acpi_pad.o
 xen-evtchn-y				:=3D evtchn.o
 xen-gntdev-y				:=3D gntdev.o
 xen-gntalloc-y				:=3D gntalloc.o
diff --git a/drivers/xen/xen_acpi_pad.c b/drivers/xen/xen_acpi_pad.c
new file mode 100644
index 0000000..0f1a1e6
--- /dev/null
+++ b/drivers/xen/xen_acpi_pad.c
@@ -0,0 +1,201 @@
+/*
+ * xen_acpi_pad.c - Xen pad interface
+ *
+ * Copyright (c) 2012, Intel Corporation.
+ *    Author: Liu, Jinsong 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License f=
or
+ * more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#if defined(CONFIG_ACPI_PROCESSOR_AGGREGATOR) || \
+		defined(CONFIG_ACPI_PROCESSOR_AGGREGATOR_MODULE)
+
+#define ACPI_PROCESSOR_AGGREGATOR_CLASS	"acpi_pad"
+#define ACPI_PROCESSOR_AGGREGATOR_DEVICE_NAME "Processor Aggregator"
+#define ACPI_PROCESSOR_AGGREGATOR_NOTIFY 0x80
+
+static DEFINE_MUTEX(xen_pad_lock);
+
+static int xen_pad_set_idle_cpus(int num_cpus)
+{
+	struct xen_platform_op op;
+
+	if (num_cpus < 0)
+		return -EINVAL;
+
+	/* set cpu nums expected to be idled */
+	op.cmd =3D XENPF_core_parking;
+	op.u.core_parking.type =3D XEN_CORE_PARKING_SET;
+	op.u.core_parking.idle_nums =3D num_cpus;
+
+	return HYPERVISOR_dom0_op(&op);
+}
+
+/*
+ * Cannot get idle cpus by using hypercall once (shared with _SET)
+ * because of the characteristic of Xen continue_hypercall_on_cpu
+ */
+static int xen_pad_get_idle_cpus(void)
+{
+	int ret;
+	struct xen_platform_op op;
+
+	/* get cpu nums actually be idled */
+	op.cmd =3D XENPF_core_parking;
+	op.u.core_parking.type =3D XEN_CORE_PARKING_GET;
+	ret =3D HYPERVISOR_dom0_op(&op);
+	if (ret < 0)
+		return ret;
+
+	return op.u.core_parking.idle_nums;
+}
+
+/*
+ * Query firmware how many CPUs should be idle
+ * return -1 on failure
+ */
+static int xen_acpi_pad_pur(acpi_handle handle)
+{
+	struct acpi_buffer buffer =3D {ACPI_ALLOCATE_BUFFER, NULL};
+	union acpi_object *package;
+	int num =3D -1;
+
+	if (ACPI_FAILURE(acpi_evaluate_object(handle, "_PUR", NULL, &buffer)))
+		return num;
+
+	if (!buffer.length || !buffer.pointer)
+		return num;
+
+	package =3D buffer.pointer;
+
+	if (package->type =3D=3D ACPI_TYPE_PACKAGE &&
+		package->package.count =3D=3D 2 &&
+		package->package.elements[0].integer.value =3D=3D 1) /* rev 1 */
+
+		num =3D package->package.elements[1].integer.value;
+
+	kfree(buffer.pointer);
+	return num;
+}
+
+/* Notify firmware how many CPUs are idle */
+static void xen_acpi_pad_ost(acpi_handle handle, int stat,
+	uint32_t idle_cpus)
+{
+	union acpi_object params[3] =3D {
+		{.type =3D ACPI_TYPE_INTEGER,},
+		{.type =3D ACPI_TYPE_INTEGER,},
+		{.type =3D ACPI_TYPE_BUFFER,},
+	};
+	struct acpi_object_list arg_list =3D {3, params};
+
+	params[0].integer.value =3D ACPI_PROCESSOR_AGGREGATOR_NOTIFY;
+	params[1].integer.value =3D  stat;
+	params[2].buffer.length =3D 4;
+	params[2].buffer.pointer =3D (void *)&idle_cpus;
+	acpi_evaluate_object(handle, "_OST", &arg_list, NULL);
+}
+
+static void xen_acpi_pad_handle_notify(acpi_handle handle)
+{
+	int num_cpus;
+
+	num_cpus =3D xen_acpi_pad_pur(handle);
+	if (num_cpus < 0)
+		return;
+
+	mutex_lock(&xen_pad_lock);
+	if (xen_pad_set_idle_cpus(num_cpus)) {
+		mutex_unlock(&xen_pad_lock);
+		return;
+	}
+
+	num_cpus =3D xen_pad_get_idle_cpus();
+	if (num_cpus < 0) {
+		mutex_unlock(&xen_pad_lock);
+		return;
+	}
+	mutex_unlock(&xen_pad_lock);
+
+	xen_acpi_pad_ost(handle, 0, num_cpus);
+}
+
+static void xen_acpi_pad_notify(acpi_handle handle, u32 event,
+	void *data)
+{
+	switch (event) {
+	case ACPI_PROCESSOR_AGGREGATOR_NOTIFY:
+		xen_acpi_pad_handle_notify(handle);
+		break;
+	default:
+		pr_warn("Unsupported event [0x%x]\n", event);
+		break;
+	}
+}
+
+static int xen_acpi_pad_add(struct acpi_device *device)
+{
+	acpi_status status;
+
+	strcpy(acpi_device_name(device), ACPI_PROCESSOR_AGGREGATOR_DEVICE_NAME);
+	strcpy(acpi_device_class(device), ACPI_PROCESSOR_AGGREGATOR_CLASS);
+
+	status =3D acpi_install_notify_handler(device->handle,
+		 ACPI_DEVICE_NOTIFY, xen_acpi_pad_notify, device);
+	if (ACPI_FAILURE(status))
+		return -ENODEV;
+
+	return 0;
+}
+
+static int xen_acpi_pad_remove(struct acpi_device *device,
+	int type)
+{
+	mutex_lock(&xen_pad_lock);
+	xen_pad_set_idle_cpus(0);
+	mutex_unlock(&xen_pad_lock);
+
+	acpi_remove_notify_handler(device->handle,
+		ACPI_DEVICE_NOTIFY, xen_acpi_pad_notify);
+	return 0;
+}
+
+static const struct acpi_device_id pad_device_ids[] =3D {
+	{"ACPI000C", 0},
+	{"", 0},
+};
+
+static struct acpi_driver xen_acpi_pad_driver =3D {
+	.name =3D "processor_aggregator",
+	.class =3D ACPI_PROCESSOR_AGGREGATOR_CLASS,
+	.ids =3D pad_device_ids,
+	.ops =3D {
+		.add =3D xen_acpi_pad_add,
+		.remove =3D xen_acpi_pad_remove,
+	},
+};
+
+static int __init xen_acpi_pad_init(void)
+{
+	/* Only DOM0 is responsible for Xen acpi pad */
+	if (xen_initial_domain())
+		return acpi_bus_register_driver(&xen_acpi_pad_driver);
+
+	return -ENODEV;
+}
+subsys_initcall(xen_acpi_pad_init);
+
+#endif
diff --git a/include/xen/interface/platform.h b/include/xen/interface/platf=
orm.h
index 4755b5f..0f44376 100644
--- a/include/xen/interface/platform.h
+++ b/include/xen/interface/platform.h
@@ -324,6 +324,22 @@ struct xenpf_cpu_ol {
 };
 DEFINE_GUEST_HANDLE_STRUCT(xenpf_cpu_ol);
=20
+/*
+ * CMD 58 and 59 are reserved for cpu hotadd and memory hotadd,
+ * which already occupied at Xen hypervisor side.
+ */
+#define XENPF_core_parking	60
+struct xenpf_core_parking {
+	/* IN variables */
+#define XEN_CORE_PARKING_SET	1
+#define XEN_CORE_PARKING_GET	2
+	uint32_t type;
+	/* IN variables:  set cpu nums expected to be idled */
+	/* OUT variables: get cpu nums actually be idled */
+	uint32_t idle_nums;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xenpf_core_parking);
+
 struct xen_platform_op {
 	uint32_t cmd;
 	uint32_t interface_version; /* XENPF_INTERFACE_VERSION */
@@ -341,6 +357,7 @@ struct xen_platform_op {
 		struct xenpf_set_processor_pminfo set_pminfo;
 		struct xenpf_pcpuinfo          pcpu_info;
 		struct xenpf_cpu_ol            cpu_ol;
+		struct xenpf_core_parking      core_parking;
 		uint8_t                        pad[128];
 	} u;
 };
--=20
1.7.1

--_002_DE8DF0795D48FD4CA783C40EC829233537292ESHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="0001-Xen-acpi-pad-implement.patch"
Content-Description: 0001-Xen-acpi-pad-implement.patch
Content-Disposition: attachment;
	filename="0001-Xen-acpi-pad-implement.patch"; size=7968;
	creation-date="Fri, 26 Oct 2012 13:48:06 GMT";
	modification-date="Fri, 26 Oct 2012 21:38:58 GMT"
Content-Transfer-Encoding: base64

RnJvbSBlNmQ0ZWNlYmE5NTM4YzY4NzNmOWM5NzA0MjVlNjVlMjU3ZmQ5YmYwIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4K
RGF0ZTogU2F0LCAyNyBPY3QgMjAxMiAwNTozNDo1MCArMDgwMApTdWJqZWN0OiBbUEFUQ0ggMS8y
XSBYZW4gYWNwaSBwYWQgaW1wbGVtZW50CgpQQUQgaXMgYWNwaSBQcm9jZXNzb3IgQWdncmVnYXRv
ciBEZXZpY2Ugd2hpY2ggcHJvdmlkZXMgYSBjb250cm9sIHBvaW50CnRoYXQgZW5hYmxlcyB0aGUg
cGxhdGZvcm0gdG8gcGVyZm9ybSBzcGVjaWZpYyBwcm9jZXNzb3IgY29uZmlndXJhdGlvbgphbmQg
Y29udHJvbCB0aGF0IGFwcGxpZXMgdG8gYWxsIHByb2Nlc3NvcnMgaW4gdGhlIHBsYXRmb3JtLgoK
VGhpcyBwYXRjaCBpcyB0byBpbXBsZW1lbnQgWGVuIGFjcGkgcGFkIGxvZ2ljLiBXaGVuIHJ1bm5p
bmcgdW5kZXIgWGVuCnZpcnQgcGxhdGZvcm0sIG5hdGl2ZSBwYWQgZHJpdmVyIHdvdWxkIG5vdCB3
b3JrLiBJbnN0ZWFkIFhlbiBwYWQgZHJpdmVyLAphIHNlbGYtY29udGFpbmVkIGFuZCB2ZXJ5IHRo
aW4gbG9naWMgbGV2ZWwsIHdvdWxkIHRha2Ugb3ZlciBhY3BpIHBhZCBzdGFmZi4KV2hlbiBhY3Bp
IHBhZCBub3RpZnkgT1NQTSwgeGVuIHBhZCBsb2dpYyBpbnRlcmNlcHQgYW5kIHBhcnNlIF9QVVIg
b2JqZWN0CmFuZCB0aGVuIGh5cGVyY2FsbCB0byBoeWVydmlzb3IgZm9yIHRoZSByZXN0IHdvcmss
IHNheSwgY29yZSBwYXJraW5nLgoKU2lnbmVkLW9mZi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25n
LmxpdUBpbnRlbC5jb20+Ci0tLQogZHJpdmVycy94ZW4vTWFrZWZpbGUgICAgICAgICAgICAgfCAg
ICAxICsKIGRyaXZlcnMveGVuL3hlbl9hY3BpX3BhZC5jICAgICAgIHwgIDIwMSArKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKwogaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3BsYXRm
b3JtLmggfCAgIDE3ICsrKwogMyBmaWxlcyBjaGFuZ2VkLCAyMTkgaW5zZXJ0aW9ucygrKSwgMCBk
ZWxldGlvbnMoLSkKIGNyZWF0ZSBtb2RlIDEwMDY0NCBkcml2ZXJzL3hlbi94ZW5fYWNwaV9wYWQu
YwoKZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVuL01ha2VmaWxlIGIvZHJpdmVycy94ZW4vTWFrZWZp
bGUKaW5kZXggMGU4NjM3MC4uYTJhZjYyMiAxMDA2NDQKLS0tIGEvZHJpdmVycy94ZW4vTWFrZWZp
bGUKKysrIGIvZHJpdmVycy94ZW4vTWFrZWZpbGUKQEAgLTI5LDYgKzI5LDcgQEAgb2JqLSQoQ09O
RklHX1hFTl9NQ0VfTE9HKQkJKz0gbWNlbG9nLm8KIG9iai0kKENPTkZJR19YRU5fUENJREVWX0JB
Q0tFTkQpCSs9IHhlbi1wY2liYWNrLwogb2JqLSQoQ09ORklHX1hFTl9QUklWQ01EKQkJKz0geGVu
LXByaXZjbWQubwogb2JqLSQoQ09ORklHX1hFTl9BQ1BJX1BST0NFU1NPUikJKz0geGVuLWFjcGkt
cHJvY2Vzc29yLm8KK29iai0kKENPTkZJR19YRU5fRE9NMCkJCQkrPSB4ZW5fYWNwaV9wYWQubwog
eGVuLWV2dGNobi15CQkJCTo9IGV2dGNobi5vCiB4ZW4tZ250ZGV2LXkJCQkJOj0gZ250ZGV2Lm8K
IHhlbi1nbnRhbGxvYy15CQkJCTo9IGdudGFsbG9jLm8KZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVu
L3hlbl9hY3BpX3BhZC5jIGIvZHJpdmVycy94ZW4veGVuX2FjcGlfcGFkLmMKbmV3IGZpbGUgbW9k
ZSAxMDA2NDQKaW5kZXggMDAwMDAwMC4uMGYxYTFlNgotLS0gL2Rldi9udWxsCisrKyBiL2RyaXZl
cnMveGVuL3hlbl9hY3BpX3BhZC5jCkBAIC0wLDAgKzEsMjAxIEBACisvKgorICogeGVuX2FjcGlf
cGFkLmMgLSBYZW4gcGFkIGludGVyZmFjZQorICoKKyAqIENvcHlyaWdodCAoYykgMjAxMiwgSW50
ZWwgQ29ycG9yYXRpb24uCisgKiAgICBBdXRob3I6IExpdSwgSmluc29uZyA8amluc29uZy5saXVA
aW50ZWwuY29tPgorICoKKyAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2Fu
IHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5IGl0CisgKiB1bmRlciB0aGUgdGVybXMgYW5k
IGNvbmRpdGlvbnMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlLAorICogdmVyc2lv
biAyLCBhcyBwdWJsaXNoZWQgYnkgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbi4KKyAqCisg
KiBUaGlzIHByb2dyYW0gaXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUgaXQgd2lsbCBiZSB1c2Vm
dWwsIGJ1dCBXSVRIT1VUCisgKiBBTlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0aGUgaW1wbGll
ZCB3YXJyYW50eSBvZiBNRVJDSEFOVEFCSUxJVFkgb3IKKyAqIEZJVE5FU1MgRk9SIEEgUEFSVElD
VUxBUiBQVVJQT1NFLiAgU2VlIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBmb3IKKyAq
IG1vcmUgZGV0YWlscy4KKyAqLworCisjaW5jbHVkZSA8bGludXgva2VybmVsLmg+CisjaW5jbHVk
ZSA8bGludXgvdHlwZXMuaD4KKyNpbmNsdWRlIDxhY3BpL2FjcGlfYnVzLmg+CisjaW5jbHVkZSA8
YWNwaS9hY3BpX2RyaXZlcnMuaD4KKyNpbmNsdWRlIDxhc20veGVuL2h5cGVyY2FsbC5oPgorCisj
aWYgZGVmaW5lZChDT05GSUdfQUNQSV9QUk9DRVNTT1JfQUdHUkVHQVRPUikgfHwgXAorCQlkZWZp
bmVkKENPTkZJR19BQ1BJX1BST0NFU1NPUl9BR0dSRUdBVE9SX01PRFVMRSkKKworI2RlZmluZSBB
Q1BJX1BST0NFU1NPUl9BR0dSRUdBVE9SX0NMQVNTCSJhY3BpX3BhZCIKKyNkZWZpbmUgQUNQSV9Q
Uk9DRVNTT1JfQUdHUkVHQVRPUl9ERVZJQ0VfTkFNRSAiUHJvY2Vzc29yIEFnZ3JlZ2F0b3IiCisj
ZGVmaW5lIEFDUElfUFJPQ0VTU09SX0FHR1JFR0FUT1JfTk9USUZZIDB4ODAKKworc3RhdGljIERF
RklORV9NVVRFWCh4ZW5fcGFkX2xvY2spOworCitzdGF0aWMgaW50IHhlbl9wYWRfc2V0X2lkbGVf
Y3B1cyhpbnQgbnVtX2NwdXMpCit7CisJc3RydWN0IHhlbl9wbGF0Zm9ybV9vcCBvcDsKKworCWlm
IChudW1fY3B1cyA8IDApCisJCXJldHVybiAtRUlOVkFMOworCisJLyogc2V0IGNwdSBudW1zIGV4
cGVjdGVkIHRvIGJlIGlkbGVkICovCisJb3AuY21kID0gWEVOUEZfY29yZV9wYXJraW5nOworCW9w
LnUuY29yZV9wYXJraW5nLnR5cGUgPSBYRU5fQ09SRV9QQVJLSU5HX1NFVDsKKwlvcC51LmNvcmVf
cGFya2luZy5pZGxlX251bXMgPSBudW1fY3B1czsKKworCXJldHVybiBIWVBFUlZJU09SX2RvbTBf
b3AoJm9wKTsKK30KKworLyoKKyAqIENhbm5vdCBnZXQgaWRsZSBjcHVzIGJ5IHVzaW5nIGh5cGVy
Y2FsbCBvbmNlIChzaGFyZWQgd2l0aCBfU0VUKQorICogYmVjYXVzZSBvZiB0aGUgY2hhcmFjdGVy
aXN0aWMgb2YgWGVuIGNvbnRpbnVlX2h5cGVyY2FsbF9vbl9jcHUKKyAqLworc3RhdGljIGludCB4
ZW5fcGFkX2dldF9pZGxlX2NwdXModm9pZCkKK3sKKwlpbnQgcmV0OworCXN0cnVjdCB4ZW5fcGxh
dGZvcm1fb3Agb3A7CisKKwkvKiBnZXQgY3B1IG51bXMgYWN0dWFsbHkgYmUgaWRsZWQgKi8KKwlv
cC5jbWQgPSBYRU5QRl9jb3JlX3Bhcmtpbmc7CisJb3AudS5jb3JlX3BhcmtpbmcudHlwZSA9IFhF
Tl9DT1JFX1BBUktJTkdfR0VUOworCXJldCA9IEhZUEVSVklTT1JfZG9tMF9vcCgmb3ApOworCWlm
IChyZXQgPCAwKQorCQlyZXR1cm4gcmV0OworCisJcmV0dXJuIG9wLnUuY29yZV9wYXJraW5nLmlk
bGVfbnVtczsKK30KKworLyoKKyAqIFF1ZXJ5IGZpcm13YXJlIGhvdyBtYW55IENQVXMgc2hvdWxk
IGJlIGlkbGUKKyAqIHJldHVybiAtMSBvbiBmYWlsdXJlCisgKi8KK3N0YXRpYyBpbnQgeGVuX2Fj
cGlfcGFkX3B1cihhY3BpX2hhbmRsZSBoYW5kbGUpCit7CisJc3RydWN0IGFjcGlfYnVmZmVyIGJ1
ZmZlciA9IHtBQ1BJX0FMTE9DQVRFX0JVRkZFUiwgTlVMTH07CisJdW5pb24gYWNwaV9vYmplY3Qg
KnBhY2thZ2U7CisJaW50IG51bSA9IC0xOworCisJaWYgKEFDUElfRkFJTFVSRShhY3BpX2V2YWx1
YXRlX29iamVjdChoYW5kbGUsICJfUFVSIiwgTlVMTCwgJmJ1ZmZlcikpKQorCQlyZXR1cm4gbnVt
OworCisJaWYgKCFidWZmZXIubGVuZ3RoIHx8ICFidWZmZXIucG9pbnRlcikKKwkJcmV0dXJuIG51
bTsKKworCXBhY2thZ2UgPSBidWZmZXIucG9pbnRlcjsKKworCWlmIChwYWNrYWdlLT50eXBlID09
IEFDUElfVFlQRV9QQUNLQUdFICYmCisJCXBhY2thZ2UtPnBhY2thZ2UuY291bnQgPT0gMiAmJgor
CQlwYWNrYWdlLT5wYWNrYWdlLmVsZW1lbnRzWzBdLmludGVnZXIudmFsdWUgPT0gMSkgLyogcmV2
IDEgKi8KKworCQludW0gPSBwYWNrYWdlLT5wYWNrYWdlLmVsZW1lbnRzWzFdLmludGVnZXIudmFs
dWU7CisKKwlrZnJlZShidWZmZXIucG9pbnRlcik7CisJcmV0dXJuIG51bTsKK30KKworLyogTm90
aWZ5IGZpcm13YXJlIGhvdyBtYW55IENQVXMgYXJlIGlkbGUgKi8KK3N0YXRpYyB2b2lkIHhlbl9h
Y3BpX3BhZF9vc3QoYWNwaV9oYW5kbGUgaGFuZGxlLCBpbnQgc3RhdCwKKwl1aW50MzJfdCBpZGxl
X2NwdXMpCit7CisJdW5pb24gYWNwaV9vYmplY3QgcGFyYW1zWzNdID0geworCQl7LnR5cGUgPSBB
Q1BJX1RZUEVfSU5URUdFUix9LAorCQl7LnR5cGUgPSBBQ1BJX1RZUEVfSU5URUdFUix9LAorCQl7
LnR5cGUgPSBBQ1BJX1RZUEVfQlVGRkVSLH0sCisJfTsKKwlzdHJ1Y3QgYWNwaV9vYmplY3RfbGlz
dCBhcmdfbGlzdCA9IHszLCBwYXJhbXN9OworCisJcGFyYW1zWzBdLmludGVnZXIudmFsdWUgPSBB
Q1BJX1BST0NFU1NPUl9BR0dSRUdBVE9SX05PVElGWTsKKwlwYXJhbXNbMV0uaW50ZWdlci52YWx1
ZSA9ICBzdGF0OworCXBhcmFtc1syXS5idWZmZXIubGVuZ3RoID0gNDsKKwlwYXJhbXNbMl0uYnVm
ZmVyLnBvaW50ZXIgPSAodm9pZCAqKSZpZGxlX2NwdXM7CisJYWNwaV9ldmFsdWF0ZV9vYmplY3Qo
aGFuZGxlLCAiX09TVCIsICZhcmdfbGlzdCwgTlVMTCk7Cit9CisKK3N0YXRpYyB2b2lkIHhlbl9h
Y3BpX3BhZF9oYW5kbGVfbm90aWZ5KGFjcGlfaGFuZGxlIGhhbmRsZSkKK3sKKwlpbnQgbnVtX2Nw
dXM7CisKKwludW1fY3B1cyA9IHhlbl9hY3BpX3BhZF9wdXIoaGFuZGxlKTsKKwlpZiAobnVtX2Nw
dXMgPCAwKQorCQlyZXR1cm47CisKKwltdXRleF9sb2NrKCZ4ZW5fcGFkX2xvY2spOworCWlmICh4
ZW5fcGFkX3NldF9pZGxlX2NwdXMobnVtX2NwdXMpKSB7CisJCW11dGV4X3VubG9jaygmeGVuX3Bh
ZF9sb2NrKTsKKwkJcmV0dXJuOworCX0KKworCW51bV9jcHVzID0geGVuX3BhZF9nZXRfaWRsZV9j
cHVzKCk7CisJaWYgKG51bV9jcHVzIDwgMCkgeworCQltdXRleF91bmxvY2soJnhlbl9wYWRfbG9j
ayk7CisJCXJldHVybjsKKwl9CisJbXV0ZXhfdW5sb2NrKCZ4ZW5fcGFkX2xvY2spOworCisJeGVu
X2FjcGlfcGFkX29zdChoYW5kbGUsIDAsIG51bV9jcHVzKTsKK30KKworc3RhdGljIHZvaWQgeGVu
X2FjcGlfcGFkX25vdGlmeShhY3BpX2hhbmRsZSBoYW5kbGUsIHUzMiBldmVudCwKKwl2b2lkICpk
YXRhKQoreworCXN3aXRjaCAoZXZlbnQpIHsKKwljYXNlIEFDUElfUFJPQ0VTU09SX0FHR1JFR0FU
T1JfTk9USUZZOgorCQl4ZW5fYWNwaV9wYWRfaGFuZGxlX25vdGlmeShoYW5kbGUpOworCQlicmVh
azsKKwlkZWZhdWx0OgorCQlwcl93YXJuKCJVbnN1cHBvcnRlZCBldmVudCBbMHgleF1cbiIsIGV2
ZW50KTsKKwkJYnJlYWs7CisJfQorfQorCitzdGF0aWMgaW50IHhlbl9hY3BpX3BhZF9hZGQoc3Ry
dWN0IGFjcGlfZGV2aWNlICpkZXZpY2UpCit7CisJYWNwaV9zdGF0dXMgc3RhdHVzOworCisJc3Ry
Y3B5KGFjcGlfZGV2aWNlX25hbWUoZGV2aWNlKSwgQUNQSV9QUk9DRVNTT1JfQUdHUkVHQVRPUl9E
RVZJQ0VfTkFNRSk7CisJc3RyY3B5KGFjcGlfZGV2aWNlX2NsYXNzKGRldmljZSksIEFDUElfUFJP
Q0VTU09SX0FHR1JFR0FUT1JfQ0xBU1MpOworCisJc3RhdHVzID0gYWNwaV9pbnN0YWxsX25vdGlm
eV9oYW5kbGVyKGRldmljZS0+aGFuZGxlLAorCQkgQUNQSV9ERVZJQ0VfTk9USUZZLCB4ZW5fYWNw
aV9wYWRfbm90aWZ5LCBkZXZpY2UpOworCWlmIChBQ1BJX0ZBSUxVUkUoc3RhdHVzKSkKKwkJcmV0
dXJuIC1FTk9ERVY7CisKKwlyZXR1cm4gMDsKK30KKworc3RhdGljIGludCB4ZW5fYWNwaV9wYWRf
cmVtb3ZlKHN0cnVjdCBhY3BpX2RldmljZSAqZGV2aWNlLAorCWludCB0eXBlKQoreworCW11dGV4
X2xvY2soJnhlbl9wYWRfbG9jayk7CisJeGVuX3BhZF9zZXRfaWRsZV9jcHVzKDApOworCW11dGV4
X3VubG9jaygmeGVuX3BhZF9sb2NrKTsKKworCWFjcGlfcmVtb3ZlX25vdGlmeV9oYW5kbGVyKGRl
dmljZS0+aGFuZGxlLAorCQlBQ1BJX0RFVklDRV9OT1RJRlksIHhlbl9hY3BpX3BhZF9ub3RpZnkp
OworCXJldHVybiAwOworfQorCitzdGF0aWMgY29uc3Qgc3RydWN0IGFjcGlfZGV2aWNlX2lkIHBh
ZF9kZXZpY2VfaWRzW10gPSB7CisJeyJBQ1BJMDAwQyIsIDB9LAorCXsiIiwgMH0sCit9OworCitz
dGF0aWMgc3RydWN0IGFjcGlfZHJpdmVyIHhlbl9hY3BpX3BhZF9kcml2ZXIgPSB7CisJLm5hbWUg
PSAicHJvY2Vzc29yX2FnZ3JlZ2F0b3IiLAorCS5jbGFzcyA9IEFDUElfUFJPQ0VTU09SX0FHR1JF
R0FUT1JfQ0xBU1MsCisJLmlkcyA9IHBhZF9kZXZpY2VfaWRzLAorCS5vcHMgPSB7CisJCS5hZGQg
PSB4ZW5fYWNwaV9wYWRfYWRkLAorCQkucmVtb3ZlID0geGVuX2FjcGlfcGFkX3JlbW92ZSwKKwl9
LAorfTsKKworc3RhdGljIGludCBfX2luaXQgeGVuX2FjcGlfcGFkX2luaXQodm9pZCkKK3sKKwkv
KiBPbmx5IERPTTAgaXMgcmVzcG9uc2libGUgZm9yIFhlbiBhY3BpIHBhZCAqLworCWlmICh4ZW5f
aW5pdGlhbF9kb21haW4oKSkKKwkJcmV0dXJuIGFjcGlfYnVzX3JlZ2lzdGVyX2RyaXZlcigmeGVu
X2FjcGlfcGFkX2RyaXZlcik7CisKKwlyZXR1cm4gLUVOT0RFVjsKK30KK3N1YnN5c19pbml0Y2Fs
bCh4ZW5fYWNwaV9wYWRfaW5pdCk7CisKKyNlbmRpZgpkaWZmIC0tZ2l0IGEvaW5jbHVkZS94ZW4v
aW50ZXJmYWNlL3BsYXRmb3JtLmggYi9pbmNsdWRlL3hlbi9pbnRlcmZhY2UvcGxhdGZvcm0uaApp
bmRleCA0NzU1YjVmLi4wZjQ0Mzc2IDEwMDY0NAotLS0gYS9pbmNsdWRlL3hlbi9pbnRlcmZhY2Uv
cGxhdGZvcm0uaAorKysgYi9pbmNsdWRlL3hlbi9pbnRlcmZhY2UvcGxhdGZvcm0uaApAQCAtMzI0
LDYgKzMyNCwyMiBAQCBzdHJ1Y3QgeGVucGZfY3B1X29sIHsKIH07CiBERUZJTkVfR1VFU1RfSEFO
RExFX1NUUlVDVCh4ZW5wZl9jcHVfb2wpOwogCisvKgorICogQ01EIDU4IGFuZCA1OSBhcmUgcmVz
ZXJ2ZWQgZm9yIGNwdSBob3RhZGQgYW5kIG1lbW9yeSBob3RhZGQsCisgKiB3aGljaCBhbHJlYWR5
IG9jY3VwaWVkIGF0IFhlbiBoeXBlcnZpc29yIHNpZGUuCisgKi8KKyNkZWZpbmUgWEVOUEZfY29y
ZV9wYXJraW5nCTYwCitzdHJ1Y3QgeGVucGZfY29yZV9wYXJraW5nIHsKKwkvKiBJTiB2YXJpYWJs
ZXMgKi8KKyNkZWZpbmUgWEVOX0NPUkVfUEFSS0lOR19TRVQJMQorI2RlZmluZSBYRU5fQ09SRV9Q
QVJLSU5HX0dFVAkyCisJdWludDMyX3QgdHlwZTsKKwkvKiBJTiB2YXJpYWJsZXM6ICBzZXQgY3B1
IG51bXMgZXhwZWN0ZWQgdG8gYmUgaWRsZWQgKi8KKwkvKiBPVVQgdmFyaWFibGVzOiBnZXQgY3B1
IG51bXMgYWN0dWFsbHkgYmUgaWRsZWQgKi8KKwl1aW50MzJfdCBpZGxlX251bXM7Cit9OworREVG
SU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QoeGVucGZfY29yZV9wYXJraW5nKTsKKwogc3RydWN0IHhl
bl9wbGF0Zm9ybV9vcCB7CiAJdWludDMyX3QgY21kOwogCXVpbnQzMl90IGludGVyZmFjZV92ZXJz
aW9uOyAvKiBYRU5QRl9JTlRFUkZBQ0VfVkVSU0lPTiAqLwpAQCAtMzQxLDYgKzM1Nyw3IEBAIHN0
cnVjdCB4ZW5fcGxhdGZvcm1fb3AgewogCQlzdHJ1Y3QgeGVucGZfc2V0X3Byb2Nlc3Nvcl9wbWlu
Zm8gc2V0X3BtaW5mbzsKIAkJc3RydWN0IHhlbnBmX3BjcHVpbmZvICAgICAgICAgIHBjcHVfaW5m
bzsKIAkJc3RydWN0IHhlbnBmX2NwdV9vbCAgICAgICAgICAgIGNwdV9vbDsKKwkJc3RydWN0IHhl
bnBmX2NvcmVfcGFya2luZyAgICAgIGNvcmVfcGFya2luZzsKIAkJdWludDhfdCAgICAgICAgICAg
ICAgICAgICAgICAgIHBhZFsxMjhdOwogCX0gdTsKIH07Ci0tIAoxLjcuMQoK

--_002_DE8DF0795D48FD4CA783C40EC829233537292ESHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC829233537292ESHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Fri Oct 26 14:02:38 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 14:02:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRkUK-0001vu-2g; Fri, 26 Oct 2012 14:02:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRkUI-0001vk-1E
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 14:02:14 +0000
Received: from [85.158.143.35:56632] by server-2.bemta-4.messagelabs.com id
	FA/21-22268-5E79A805; Fri, 26 Oct 2012 14:02:13 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1351260046!12564681!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzE1Njk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6201 invoked from network); 26 Oct 2012 14:00:49 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-12.tower-21.messagelabs.com with SMTP;
	26 Oct 2012 14:00:49 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 26 Oct 2012 07:00:45 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,654,1344236400"; 
	d="scan'208,223";a="232926308"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by orsmga002.jf.intel.com with ESMTP; 26 Oct 2012 07:00:40 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 26 Oct 2012 07:00:39 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.123]) with mapi id
	14.01.0355.002; Fri, 26 Oct 2012 22:00:37 +0800
From: "Liu, Jinsong" 
To: "konrad.wilk@oracle.com" , Jan Beulich
	
Thread-Topic: [Xen-devel] [PATCH 1/2] Xen acpi pad implement
Thread-Index: AQHNs3G2Ti91BiFLfUibRvXA4zlK85fLgkyggAAZxiA=
Date: Fri, 26 Oct 2012 14:00:36 +0000
Message-ID: 
References: 
	<5089676602000078000A4928@nat28.tlf.novell.com>
	
	<508A89CB020000780008E6ED@nat28.tlf.novell.com>
	
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC829233537292ESHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk ,
	"linux-kernel@vger.kernel.org" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 1/2] Xen acpi pad implement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC829233537292ESHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Updated per Jan's comments.

Thanks,
Jinsong

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

>From e6d4eceba9538c6873f9c970425e65e257fd9bf0 Mon Sep 17 00:00:00 2001
From: Liu, Jinsong 
Date: Sat, 27 Oct 2012 05:34:50 +0800
Subject: [PATCH 1/2] Xen acpi pad implement

PAD is acpi Processor Aggregator Device which provides a control point
that enables the platform to perform specific processor configuration
and control that applies to all processors in the platform.

This patch is to implement Xen acpi pad logic. When running under Xen
virt platform, native pad driver would not work. Instead Xen pad driver,
a self-contained and very thin logic level, would take over acpi pad staff.
When acpi pad notify OSPM, xen pad logic intercept and parse _PUR object
and then hypercall to hyervisor for the rest work, say, core parking.

Signed-off-by: Liu, Jinsong 
---
 drivers/xen/Makefile             |    1 +
 drivers/xen/xen_acpi_pad.c       |  201 ++++++++++++++++++++++++++++++++++=
++++
 include/xen/interface/platform.h |   17 +++
 3 files changed, 219 insertions(+), 0 deletions(-)
 create mode 100644 drivers/xen/xen_acpi_pad.c

diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 0e86370..a2af622 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_XEN_MCE_LOG)		+=3D mcelog.o
 obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+=3D xen-pciback/
 obj-$(CONFIG_XEN_PRIVCMD)		+=3D xen-privcmd.o
 obj-$(CONFIG_XEN_ACPI_PROCESSOR)	+=3D xen-acpi-processor.o
+obj-$(CONFIG_XEN_DOM0)			+=3D xen_acpi_pad.o
 xen-evtchn-y				:=3D evtchn.o
 xen-gntdev-y				:=3D gntdev.o
 xen-gntalloc-y				:=3D gntalloc.o
diff --git a/drivers/xen/xen_acpi_pad.c b/drivers/xen/xen_acpi_pad.c
new file mode 100644
index 0000000..0f1a1e6
--- /dev/null
+++ b/drivers/xen/xen_acpi_pad.c
@@ -0,0 +1,201 @@
+/*
+ * xen_acpi_pad.c - Xen pad interface
+ *
+ * Copyright (c) 2012, Intel Corporation.
+ *    Author: Liu, Jinsong 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License f=
or
+ * more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#if defined(CONFIG_ACPI_PROCESSOR_AGGREGATOR) || \
+		defined(CONFIG_ACPI_PROCESSOR_AGGREGATOR_MODULE)
+
+#define ACPI_PROCESSOR_AGGREGATOR_CLASS	"acpi_pad"
+#define ACPI_PROCESSOR_AGGREGATOR_DEVICE_NAME "Processor Aggregator"
+#define ACPI_PROCESSOR_AGGREGATOR_NOTIFY 0x80
+
+static DEFINE_MUTEX(xen_pad_lock);
+
+static int xen_pad_set_idle_cpus(int num_cpus)
+{
+	struct xen_platform_op op;
+
+	if (num_cpus < 0)
+		return -EINVAL;
+
+	/* set cpu nums expected to be idled */
+	op.cmd =3D XENPF_core_parking;
+	op.u.core_parking.type =3D XEN_CORE_PARKING_SET;
+	op.u.core_parking.idle_nums =3D num_cpus;
+
+	return HYPERVISOR_dom0_op(&op);
+}
+
+/*
+ * Cannot get idle cpus by using hypercall once (shared with _SET)
+ * because of the characteristic of Xen continue_hypercall_on_cpu
+ */
+static int xen_pad_get_idle_cpus(void)
+{
+	int ret;
+	struct xen_platform_op op;
+
+	/* get cpu nums actually be idled */
+	op.cmd =3D XENPF_core_parking;
+	op.u.core_parking.type =3D XEN_CORE_PARKING_GET;
+	ret =3D HYPERVISOR_dom0_op(&op);
+	if (ret < 0)
+		return ret;
+
+	return op.u.core_parking.idle_nums;
+}
+
+/*
+ * Query firmware how many CPUs should be idle
+ * return -1 on failure
+ */
+static int xen_acpi_pad_pur(acpi_handle handle)
+{
+	struct acpi_buffer buffer =3D {ACPI_ALLOCATE_BUFFER, NULL};
+	union acpi_object *package;
+	int num =3D -1;
+
+	if (ACPI_FAILURE(acpi_evaluate_object(handle, "_PUR", NULL, &buffer)))
+		return num;
+
+	if (!buffer.length || !buffer.pointer)
+		return num;
+
+	package =3D buffer.pointer;
+
+	if (package->type =3D=3D ACPI_TYPE_PACKAGE &&
+		package->package.count =3D=3D 2 &&
+		package->package.elements[0].integer.value =3D=3D 1) /* rev 1 */
+
+		num =3D package->package.elements[1].integer.value;
+
+	kfree(buffer.pointer);
+	return num;
+}
+
+/* Notify firmware how many CPUs are idle */
+static void xen_acpi_pad_ost(acpi_handle handle, int stat,
+	uint32_t idle_cpus)
+{
+	union acpi_object params[3] =3D {
+		{.type =3D ACPI_TYPE_INTEGER,},
+		{.type =3D ACPI_TYPE_INTEGER,},
+		{.type =3D ACPI_TYPE_BUFFER,},
+	};
+	struct acpi_object_list arg_list =3D {3, params};
+
+	params[0].integer.value =3D ACPI_PROCESSOR_AGGREGATOR_NOTIFY;
+	params[1].integer.value =3D  stat;
+	params[2].buffer.length =3D 4;
+	params[2].buffer.pointer =3D (void *)&idle_cpus;
+	acpi_evaluate_object(handle, "_OST", &arg_list, NULL);
+}
+
+static void xen_acpi_pad_handle_notify(acpi_handle handle)
+{
+	int num_cpus;
+
+	num_cpus =3D xen_acpi_pad_pur(handle);
+	if (num_cpus < 0)
+		return;
+
+	mutex_lock(&xen_pad_lock);
+	if (xen_pad_set_idle_cpus(num_cpus)) {
+		mutex_unlock(&xen_pad_lock);
+		return;
+	}
+
+	num_cpus =3D xen_pad_get_idle_cpus();
+	if (num_cpus < 0) {
+		mutex_unlock(&xen_pad_lock);
+		return;
+	}
+	mutex_unlock(&xen_pad_lock);
+
+	xen_acpi_pad_ost(handle, 0, num_cpus);
+}
+
+static void xen_acpi_pad_notify(acpi_handle handle, u32 event,
+	void *data)
+{
+	switch (event) {
+	case ACPI_PROCESSOR_AGGREGATOR_NOTIFY:
+		xen_acpi_pad_handle_notify(handle);
+		break;
+	default:
+		pr_warn("Unsupported event [0x%x]\n", event);
+		break;
+	}
+}
+
+static int xen_acpi_pad_add(struct acpi_device *device)
+{
+	acpi_status status;
+
+	strcpy(acpi_device_name(device), ACPI_PROCESSOR_AGGREGATOR_DEVICE_NAME);
+	strcpy(acpi_device_class(device), ACPI_PROCESSOR_AGGREGATOR_CLASS);
+
+	status =3D acpi_install_notify_handler(device->handle,
+		 ACPI_DEVICE_NOTIFY, xen_acpi_pad_notify, device);
+	if (ACPI_FAILURE(status))
+		return -ENODEV;
+
+	return 0;
+}
+
+static int xen_acpi_pad_remove(struct acpi_device *device,
+	int type)
+{
+	mutex_lock(&xen_pad_lock);
+	xen_pad_set_idle_cpus(0);
+	mutex_unlock(&xen_pad_lock);
+
+	acpi_remove_notify_handler(device->handle,
+		ACPI_DEVICE_NOTIFY, xen_acpi_pad_notify);
+	return 0;
+}
+
+static const struct acpi_device_id pad_device_ids[] =3D {
+	{"ACPI000C", 0},
+	{"", 0},
+};
+
+static struct acpi_driver xen_acpi_pad_driver =3D {
+	.name =3D "processor_aggregator",
+	.class =3D ACPI_PROCESSOR_AGGREGATOR_CLASS,
+	.ids =3D pad_device_ids,
+	.ops =3D {
+		.add =3D xen_acpi_pad_add,
+		.remove =3D xen_acpi_pad_remove,
+	},
+};
+
+static int __init xen_acpi_pad_init(void)
+{
+	/* Only DOM0 is responsible for Xen acpi pad */
+	if (xen_initial_domain())
+		return acpi_bus_register_driver(&xen_acpi_pad_driver);
+
+	return -ENODEV;
+}
+subsys_initcall(xen_acpi_pad_init);
+
+#endif
diff --git a/include/xen/interface/platform.h b/include/xen/interface/platf=
orm.h
index 4755b5f..0f44376 100644
--- a/include/xen/interface/platform.h
+++ b/include/xen/interface/platform.h
@@ -324,6 +324,22 @@ struct xenpf_cpu_ol {
 };
 DEFINE_GUEST_HANDLE_STRUCT(xenpf_cpu_ol);
=20
+/*
+ * CMD 58 and 59 are reserved for cpu hotadd and memory hotadd,
+ * which already occupied at Xen hypervisor side.
+ */
+#define XENPF_core_parking	60
+struct xenpf_core_parking {
+	/* IN variables */
+#define XEN_CORE_PARKING_SET	1
+#define XEN_CORE_PARKING_GET	2
+	uint32_t type;
+	/* IN variables:  set cpu nums expected to be idled */
+	/* OUT variables: get cpu nums actually be idled */
+	uint32_t idle_nums;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xenpf_core_parking);
+
 struct xen_platform_op {
 	uint32_t cmd;
 	uint32_t interface_version; /* XENPF_INTERFACE_VERSION */
@@ -341,6 +357,7 @@ struct xen_platform_op {
 		struct xenpf_set_processor_pminfo set_pminfo;
 		struct xenpf_pcpuinfo          pcpu_info;
 		struct xenpf_cpu_ol            cpu_ol;
+		struct xenpf_core_parking      core_parking;
 		uint8_t                        pad[128];
 	} u;
 };
--=20
1.7.1

--_002_DE8DF0795D48FD4CA783C40EC829233537292ESHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="0001-Xen-acpi-pad-implement.patch"
Content-Description: 0001-Xen-acpi-pad-implement.patch
Content-Disposition: attachment;
	filename="0001-Xen-acpi-pad-implement.patch"; size=7968;
	creation-date="Fri, 26 Oct 2012 13:48:06 GMT";
	modification-date="Fri, 26 Oct 2012 21:38:58 GMT"
Content-Transfer-Encoding: base64

RnJvbSBlNmQ0ZWNlYmE5NTM4YzY4NzNmOWM5NzA0MjVlNjVlMjU3ZmQ5YmYwIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4K
RGF0ZTogU2F0LCAyNyBPY3QgMjAxMiAwNTozNDo1MCArMDgwMApTdWJqZWN0OiBbUEFUQ0ggMS8y
XSBYZW4gYWNwaSBwYWQgaW1wbGVtZW50CgpQQUQgaXMgYWNwaSBQcm9jZXNzb3IgQWdncmVnYXRv
ciBEZXZpY2Ugd2hpY2ggcHJvdmlkZXMgYSBjb250cm9sIHBvaW50CnRoYXQgZW5hYmxlcyB0aGUg
cGxhdGZvcm0gdG8gcGVyZm9ybSBzcGVjaWZpYyBwcm9jZXNzb3IgY29uZmlndXJhdGlvbgphbmQg
Y29udHJvbCB0aGF0IGFwcGxpZXMgdG8gYWxsIHByb2Nlc3NvcnMgaW4gdGhlIHBsYXRmb3JtLgoK
VGhpcyBwYXRjaCBpcyB0byBpbXBsZW1lbnQgWGVuIGFjcGkgcGFkIGxvZ2ljLiBXaGVuIHJ1bm5p
bmcgdW5kZXIgWGVuCnZpcnQgcGxhdGZvcm0sIG5hdGl2ZSBwYWQgZHJpdmVyIHdvdWxkIG5vdCB3
b3JrLiBJbnN0ZWFkIFhlbiBwYWQgZHJpdmVyLAphIHNlbGYtY29udGFpbmVkIGFuZCB2ZXJ5IHRo
aW4gbG9naWMgbGV2ZWwsIHdvdWxkIHRha2Ugb3ZlciBhY3BpIHBhZCBzdGFmZi4KV2hlbiBhY3Bp
IHBhZCBub3RpZnkgT1NQTSwgeGVuIHBhZCBsb2dpYyBpbnRlcmNlcHQgYW5kIHBhcnNlIF9QVVIg
b2JqZWN0CmFuZCB0aGVuIGh5cGVyY2FsbCB0byBoeWVydmlzb3IgZm9yIHRoZSByZXN0IHdvcmss
IHNheSwgY29yZSBwYXJraW5nLgoKU2lnbmVkLW9mZi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25n
LmxpdUBpbnRlbC5jb20+Ci0tLQogZHJpdmVycy94ZW4vTWFrZWZpbGUgICAgICAgICAgICAgfCAg
ICAxICsKIGRyaXZlcnMveGVuL3hlbl9hY3BpX3BhZC5jICAgICAgIHwgIDIwMSArKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKwogaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3BsYXRm
b3JtLmggfCAgIDE3ICsrKwogMyBmaWxlcyBjaGFuZ2VkLCAyMTkgaW5zZXJ0aW9ucygrKSwgMCBk
ZWxldGlvbnMoLSkKIGNyZWF0ZSBtb2RlIDEwMDY0NCBkcml2ZXJzL3hlbi94ZW5fYWNwaV9wYWQu
YwoKZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVuL01ha2VmaWxlIGIvZHJpdmVycy94ZW4vTWFrZWZp
bGUKaW5kZXggMGU4NjM3MC4uYTJhZjYyMiAxMDA2NDQKLS0tIGEvZHJpdmVycy94ZW4vTWFrZWZp
bGUKKysrIGIvZHJpdmVycy94ZW4vTWFrZWZpbGUKQEAgLTI5LDYgKzI5LDcgQEAgb2JqLSQoQ09O
RklHX1hFTl9NQ0VfTE9HKQkJKz0gbWNlbG9nLm8KIG9iai0kKENPTkZJR19YRU5fUENJREVWX0JB
Q0tFTkQpCSs9IHhlbi1wY2liYWNrLwogb2JqLSQoQ09ORklHX1hFTl9QUklWQ01EKQkJKz0geGVu
LXByaXZjbWQubwogb2JqLSQoQ09ORklHX1hFTl9BQ1BJX1BST0NFU1NPUikJKz0geGVuLWFjcGkt
cHJvY2Vzc29yLm8KK29iai0kKENPTkZJR19YRU5fRE9NMCkJCQkrPSB4ZW5fYWNwaV9wYWQubwog
eGVuLWV2dGNobi15CQkJCTo9IGV2dGNobi5vCiB4ZW4tZ250ZGV2LXkJCQkJOj0gZ250ZGV2Lm8K
IHhlbi1nbnRhbGxvYy15CQkJCTo9IGdudGFsbG9jLm8KZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVu
L3hlbl9hY3BpX3BhZC5jIGIvZHJpdmVycy94ZW4veGVuX2FjcGlfcGFkLmMKbmV3IGZpbGUgbW9k
ZSAxMDA2NDQKaW5kZXggMDAwMDAwMC4uMGYxYTFlNgotLS0gL2Rldi9udWxsCisrKyBiL2RyaXZl
cnMveGVuL3hlbl9hY3BpX3BhZC5jCkBAIC0wLDAgKzEsMjAxIEBACisvKgorICogeGVuX2FjcGlf
cGFkLmMgLSBYZW4gcGFkIGludGVyZmFjZQorICoKKyAqIENvcHlyaWdodCAoYykgMjAxMiwgSW50
ZWwgQ29ycG9yYXRpb24uCisgKiAgICBBdXRob3I6IExpdSwgSmluc29uZyA8amluc29uZy5saXVA
aW50ZWwuY29tPgorICoKKyAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2Fu
IHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5IGl0CisgKiB1bmRlciB0aGUgdGVybXMgYW5k
IGNvbmRpdGlvbnMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlLAorICogdmVyc2lv
biAyLCBhcyBwdWJsaXNoZWQgYnkgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbi4KKyAqCisg
KiBUaGlzIHByb2dyYW0gaXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUgaXQgd2lsbCBiZSB1c2Vm
dWwsIGJ1dCBXSVRIT1VUCisgKiBBTlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0aGUgaW1wbGll
ZCB3YXJyYW50eSBvZiBNRVJDSEFOVEFCSUxJVFkgb3IKKyAqIEZJVE5FU1MgRk9SIEEgUEFSVElD
VUxBUiBQVVJQT1NFLiAgU2VlIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBmb3IKKyAq
IG1vcmUgZGV0YWlscy4KKyAqLworCisjaW5jbHVkZSA8bGludXgva2VybmVsLmg+CisjaW5jbHVk
ZSA8bGludXgvdHlwZXMuaD4KKyNpbmNsdWRlIDxhY3BpL2FjcGlfYnVzLmg+CisjaW5jbHVkZSA8
YWNwaS9hY3BpX2RyaXZlcnMuaD4KKyNpbmNsdWRlIDxhc20veGVuL2h5cGVyY2FsbC5oPgorCisj
aWYgZGVmaW5lZChDT05GSUdfQUNQSV9QUk9DRVNTT1JfQUdHUkVHQVRPUikgfHwgXAorCQlkZWZp
bmVkKENPTkZJR19BQ1BJX1BST0NFU1NPUl9BR0dSRUdBVE9SX01PRFVMRSkKKworI2RlZmluZSBB
Q1BJX1BST0NFU1NPUl9BR0dSRUdBVE9SX0NMQVNTCSJhY3BpX3BhZCIKKyNkZWZpbmUgQUNQSV9Q
Uk9DRVNTT1JfQUdHUkVHQVRPUl9ERVZJQ0VfTkFNRSAiUHJvY2Vzc29yIEFnZ3JlZ2F0b3IiCisj
ZGVmaW5lIEFDUElfUFJPQ0VTU09SX0FHR1JFR0FUT1JfTk9USUZZIDB4ODAKKworc3RhdGljIERF
RklORV9NVVRFWCh4ZW5fcGFkX2xvY2spOworCitzdGF0aWMgaW50IHhlbl9wYWRfc2V0X2lkbGVf
Y3B1cyhpbnQgbnVtX2NwdXMpCit7CisJc3RydWN0IHhlbl9wbGF0Zm9ybV9vcCBvcDsKKworCWlm
IChudW1fY3B1cyA8IDApCisJCXJldHVybiAtRUlOVkFMOworCisJLyogc2V0IGNwdSBudW1zIGV4
cGVjdGVkIHRvIGJlIGlkbGVkICovCisJb3AuY21kID0gWEVOUEZfY29yZV9wYXJraW5nOworCW9w
LnUuY29yZV9wYXJraW5nLnR5cGUgPSBYRU5fQ09SRV9QQVJLSU5HX1NFVDsKKwlvcC51LmNvcmVf
cGFya2luZy5pZGxlX251bXMgPSBudW1fY3B1czsKKworCXJldHVybiBIWVBFUlZJU09SX2RvbTBf
b3AoJm9wKTsKK30KKworLyoKKyAqIENhbm5vdCBnZXQgaWRsZSBjcHVzIGJ5IHVzaW5nIGh5cGVy
Y2FsbCBvbmNlIChzaGFyZWQgd2l0aCBfU0VUKQorICogYmVjYXVzZSBvZiB0aGUgY2hhcmFjdGVy
aXN0aWMgb2YgWGVuIGNvbnRpbnVlX2h5cGVyY2FsbF9vbl9jcHUKKyAqLworc3RhdGljIGludCB4
ZW5fcGFkX2dldF9pZGxlX2NwdXModm9pZCkKK3sKKwlpbnQgcmV0OworCXN0cnVjdCB4ZW5fcGxh
dGZvcm1fb3Agb3A7CisKKwkvKiBnZXQgY3B1IG51bXMgYWN0dWFsbHkgYmUgaWRsZWQgKi8KKwlv
cC5jbWQgPSBYRU5QRl9jb3JlX3Bhcmtpbmc7CisJb3AudS5jb3JlX3BhcmtpbmcudHlwZSA9IFhF
Tl9DT1JFX1BBUktJTkdfR0VUOworCXJldCA9IEhZUEVSVklTT1JfZG9tMF9vcCgmb3ApOworCWlm
IChyZXQgPCAwKQorCQlyZXR1cm4gcmV0OworCisJcmV0dXJuIG9wLnUuY29yZV9wYXJraW5nLmlk
bGVfbnVtczsKK30KKworLyoKKyAqIFF1ZXJ5IGZpcm13YXJlIGhvdyBtYW55IENQVXMgc2hvdWxk
IGJlIGlkbGUKKyAqIHJldHVybiAtMSBvbiBmYWlsdXJlCisgKi8KK3N0YXRpYyBpbnQgeGVuX2Fj
cGlfcGFkX3B1cihhY3BpX2hhbmRsZSBoYW5kbGUpCit7CisJc3RydWN0IGFjcGlfYnVmZmVyIGJ1
ZmZlciA9IHtBQ1BJX0FMTE9DQVRFX0JVRkZFUiwgTlVMTH07CisJdW5pb24gYWNwaV9vYmplY3Qg
KnBhY2thZ2U7CisJaW50IG51bSA9IC0xOworCisJaWYgKEFDUElfRkFJTFVSRShhY3BpX2V2YWx1
YXRlX29iamVjdChoYW5kbGUsICJfUFVSIiwgTlVMTCwgJmJ1ZmZlcikpKQorCQlyZXR1cm4gbnVt
OworCisJaWYgKCFidWZmZXIubGVuZ3RoIHx8ICFidWZmZXIucG9pbnRlcikKKwkJcmV0dXJuIG51
bTsKKworCXBhY2thZ2UgPSBidWZmZXIucG9pbnRlcjsKKworCWlmIChwYWNrYWdlLT50eXBlID09
IEFDUElfVFlQRV9QQUNLQUdFICYmCisJCXBhY2thZ2UtPnBhY2thZ2UuY291bnQgPT0gMiAmJgor
CQlwYWNrYWdlLT5wYWNrYWdlLmVsZW1lbnRzWzBdLmludGVnZXIudmFsdWUgPT0gMSkgLyogcmV2
IDEgKi8KKworCQludW0gPSBwYWNrYWdlLT5wYWNrYWdlLmVsZW1lbnRzWzFdLmludGVnZXIudmFs
dWU7CisKKwlrZnJlZShidWZmZXIucG9pbnRlcik7CisJcmV0dXJuIG51bTsKK30KKworLyogTm90
aWZ5IGZpcm13YXJlIGhvdyBtYW55IENQVXMgYXJlIGlkbGUgKi8KK3N0YXRpYyB2b2lkIHhlbl9h
Y3BpX3BhZF9vc3QoYWNwaV9oYW5kbGUgaGFuZGxlLCBpbnQgc3RhdCwKKwl1aW50MzJfdCBpZGxl
X2NwdXMpCit7CisJdW5pb24gYWNwaV9vYmplY3QgcGFyYW1zWzNdID0geworCQl7LnR5cGUgPSBB
Q1BJX1RZUEVfSU5URUdFUix9LAorCQl7LnR5cGUgPSBBQ1BJX1RZUEVfSU5URUdFUix9LAorCQl7
LnR5cGUgPSBBQ1BJX1RZUEVfQlVGRkVSLH0sCisJfTsKKwlzdHJ1Y3QgYWNwaV9vYmplY3RfbGlz
dCBhcmdfbGlzdCA9IHszLCBwYXJhbXN9OworCisJcGFyYW1zWzBdLmludGVnZXIudmFsdWUgPSBB
Q1BJX1BST0NFU1NPUl9BR0dSRUdBVE9SX05PVElGWTsKKwlwYXJhbXNbMV0uaW50ZWdlci52YWx1
ZSA9ICBzdGF0OworCXBhcmFtc1syXS5idWZmZXIubGVuZ3RoID0gNDsKKwlwYXJhbXNbMl0uYnVm
ZmVyLnBvaW50ZXIgPSAodm9pZCAqKSZpZGxlX2NwdXM7CisJYWNwaV9ldmFsdWF0ZV9vYmplY3Qo
aGFuZGxlLCAiX09TVCIsICZhcmdfbGlzdCwgTlVMTCk7Cit9CisKK3N0YXRpYyB2b2lkIHhlbl9h
Y3BpX3BhZF9oYW5kbGVfbm90aWZ5KGFjcGlfaGFuZGxlIGhhbmRsZSkKK3sKKwlpbnQgbnVtX2Nw
dXM7CisKKwludW1fY3B1cyA9IHhlbl9hY3BpX3BhZF9wdXIoaGFuZGxlKTsKKwlpZiAobnVtX2Nw
dXMgPCAwKQorCQlyZXR1cm47CisKKwltdXRleF9sb2NrKCZ4ZW5fcGFkX2xvY2spOworCWlmICh4
ZW5fcGFkX3NldF9pZGxlX2NwdXMobnVtX2NwdXMpKSB7CisJCW11dGV4X3VubG9jaygmeGVuX3Bh
ZF9sb2NrKTsKKwkJcmV0dXJuOworCX0KKworCW51bV9jcHVzID0geGVuX3BhZF9nZXRfaWRsZV9j
cHVzKCk7CisJaWYgKG51bV9jcHVzIDwgMCkgeworCQltdXRleF91bmxvY2soJnhlbl9wYWRfbG9j
ayk7CisJCXJldHVybjsKKwl9CisJbXV0ZXhfdW5sb2NrKCZ4ZW5fcGFkX2xvY2spOworCisJeGVu
X2FjcGlfcGFkX29zdChoYW5kbGUsIDAsIG51bV9jcHVzKTsKK30KKworc3RhdGljIHZvaWQgeGVu
X2FjcGlfcGFkX25vdGlmeShhY3BpX2hhbmRsZSBoYW5kbGUsIHUzMiBldmVudCwKKwl2b2lkICpk
YXRhKQoreworCXN3aXRjaCAoZXZlbnQpIHsKKwljYXNlIEFDUElfUFJPQ0VTU09SX0FHR1JFR0FU
T1JfTk9USUZZOgorCQl4ZW5fYWNwaV9wYWRfaGFuZGxlX25vdGlmeShoYW5kbGUpOworCQlicmVh
azsKKwlkZWZhdWx0OgorCQlwcl93YXJuKCJVbnN1cHBvcnRlZCBldmVudCBbMHgleF1cbiIsIGV2
ZW50KTsKKwkJYnJlYWs7CisJfQorfQorCitzdGF0aWMgaW50IHhlbl9hY3BpX3BhZF9hZGQoc3Ry
dWN0IGFjcGlfZGV2aWNlICpkZXZpY2UpCit7CisJYWNwaV9zdGF0dXMgc3RhdHVzOworCisJc3Ry
Y3B5KGFjcGlfZGV2aWNlX25hbWUoZGV2aWNlKSwgQUNQSV9QUk9DRVNTT1JfQUdHUkVHQVRPUl9E
RVZJQ0VfTkFNRSk7CisJc3RyY3B5KGFjcGlfZGV2aWNlX2NsYXNzKGRldmljZSksIEFDUElfUFJP
Q0VTU09SX0FHR1JFR0FUT1JfQ0xBU1MpOworCisJc3RhdHVzID0gYWNwaV9pbnN0YWxsX25vdGlm
eV9oYW5kbGVyKGRldmljZS0+aGFuZGxlLAorCQkgQUNQSV9ERVZJQ0VfTk9USUZZLCB4ZW5fYWNw
aV9wYWRfbm90aWZ5LCBkZXZpY2UpOworCWlmIChBQ1BJX0ZBSUxVUkUoc3RhdHVzKSkKKwkJcmV0
dXJuIC1FTk9ERVY7CisKKwlyZXR1cm4gMDsKK30KKworc3RhdGljIGludCB4ZW5fYWNwaV9wYWRf
cmVtb3ZlKHN0cnVjdCBhY3BpX2RldmljZSAqZGV2aWNlLAorCWludCB0eXBlKQoreworCW11dGV4
X2xvY2soJnhlbl9wYWRfbG9jayk7CisJeGVuX3BhZF9zZXRfaWRsZV9jcHVzKDApOworCW11dGV4
X3VubG9jaygmeGVuX3BhZF9sb2NrKTsKKworCWFjcGlfcmVtb3ZlX25vdGlmeV9oYW5kbGVyKGRl
dmljZS0+aGFuZGxlLAorCQlBQ1BJX0RFVklDRV9OT1RJRlksIHhlbl9hY3BpX3BhZF9ub3RpZnkp
OworCXJldHVybiAwOworfQorCitzdGF0aWMgY29uc3Qgc3RydWN0IGFjcGlfZGV2aWNlX2lkIHBh
ZF9kZXZpY2VfaWRzW10gPSB7CisJeyJBQ1BJMDAwQyIsIDB9LAorCXsiIiwgMH0sCit9OworCitz
dGF0aWMgc3RydWN0IGFjcGlfZHJpdmVyIHhlbl9hY3BpX3BhZF9kcml2ZXIgPSB7CisJLm5hbWUg
PSAicHJvY2Vzc29yX2FnZ3JlZ2F0b3IiLAorCS5jbGFzcyA9IEFDUElfUFJPQ0VTU09SX0FHR1JF
R0FUT1JfQ0xBU1MsCisJLmlkcyA9IHBhZF9kZXZpY2VfaWRzLAorCS5vcHMgPSB7CisJCS5hZGQg
PSB4ZW5fYWNwaV9wYWRfYWRkLAorCQkucmVtb3ZlID0geGVuX2FjcGlfcGFkX3JlbW92ZSwKKwl9
LAorfTsKKworc3RhdGljIGludCBfX2luaXQgeGVuX2FjcGlfcGFkX2luaXQodm9pZCkKK3sKKwkv
KiBPbmx5IERPTTAgaXMgcmVzcG9uc2libGUgZm9yIFhlbiBhY3BpIHBhZCAqLworCWlmICh4ZW5f
aW5pdGlhbF9kb21haW4oKSkKKwkJcmV0dXJuIGFjcGlfYnVzX3JlZ2lzdGVyX2RyaXZlcigmeGVu
X2FjcGlfcGFkX2RyaXZlcik7CisKKwlyZXR1cm4gLUVOT0RFVjsKK30KK3N1YnN5c19pbml0Y2Fs
bCh4ZW5fYWNwaV9wYWRfaW5pdCk7CisKKyNlbmRpZgpkaWZmIC0tZ2l0IGEvaW5jbHVkZS94ZW4v
aW50ZXJmYWNlL3BsYXRmb3JtLmggYi9pbmNsdWRlL3hlbi9pbnRlcmZhY2UvcGxhdGZvcm0uaApp
bmRleCA0NzU1YjVmLi4wZjQ0Mzc2IDEwMDY0NAotLS0gYS9pbmNsdWRlL3hlbi9pbnRlcmZhY2Uv
cGxhdGZvcm0uaAorKysgYi9pbmNsdWRlL3hlbi9pbnRlcmZhY2UvcGxhdGZvcm0uaApAQCAtMzI0
LDYgKzMyNCwyMiBAQCBzdHJ1Y3QgeGVucGZfY3B1X29sIHsKIH07CiBERUZJTkVfR1VFU1RfSEFO
RExFX1NUUlVDVCh4ZW5wZl9jcHVfb2wpOwogCisvKgorICogQ01EIDU4IGFuZCA1OSBhcmUgcmVz
ZXJ2ZWQgZm9yIGNwdSBob3RhZGQgYW5kIG1lbW9yeSBob3RhZGQsCisgKiB3aGljaCBhbHJlYWR5
IG9jY3VwaWVkIGF0IFhlbiBoeXBlcnZpc29yIHNpZGUuCisgKi8KKyNkZWZpbmUgWEVOUEZfY29y
ZV9wYXJraW5nCTYwCitzdHJ1Y3QgeGVucGZfY29yZV9wYXJraW5nIHsKKwkvKiBJTiB2YXJpYWJs
ZXMgKi8KKyNkZWZpbmUgWEVOX0NPUkVfUEFSS0lOR19TRVQJMQorI2RlZmluZSBYRU5fQ09SRV9Q
QVJLSU5HX0dFVAkyCisJdWludDMyX3QgdHlwZTsKKwkvKiBJTiB2YXJpYWJsZXM6ICBzZXQgY3B1
IG51bXMgZXhwZWN0ZWQgdG8gYmUgaWRsZWQgKi8KKwkvKiBPVVQgdmFyaWFibGVzOiBnZXQgY3B1
IG51bXMgYWN0dWFsbHkgYmUgaWRsZWQgKi8KKwl1aW50MzJfdCBpZGxlX251bXM7Cit9OworREVG
SU5FX0dVRVNUX0hBTkRMRV9TVFJVQ1QoeGVucGZfY29yZV9wYXJraW5nKTsKKwogc3RydWN0IHhl
bl9wbGF0Zm9ybV9vcCB7CiAJdWludDMyX3QgY21kOwogCXVpbnQzMl90IGludGVyZmFjZV92ZXJz
aW9uOyAvKiBYRU5QRl9JTlRFUkZBQ0VfVkVSU0lPTiAqLwpAQCAtMzQxLDYgKzM1Nyw3IEBAIHN0
cnVjdCB4ZW5fcGxhdGZvcm1fb3AgewogCQlzdHJ1Y3QgeGVucGZfc2V0X3Byb2Nlc3Nvcl9wbWlu
Zm8gc2V0X3BtaW5mbzsKIAkJc3RydWN0IHhlbnBmX3BjcHVpbmZvICAgICAgICAgIHBjcHVfaW5m
bzsKIAkJc3RydWN0IHhlbnBmX2NwdV9vbCAgICAgICAgICAgIGNwdV9vbDsKKwkJc3RydWN0IHhl
bnBmX2NvcmVfcGFya2luZyAgICAgIGNvcmVfcGFya2luZzsKIAkJdWludDhfdCAgICAgICAgICAg
ICAgICAgICAgICAgIHBhZFsxMjhdOwogCX0gdTsKIH07Ci0tIAoxLjcuMQoK

--_002_DE8DF0795D48FD4CA783C40EC829233537292ESHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC829233537292ESHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Fri Oct 26 14:08:44 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 14:08:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRkaH-0002Bk-2P; Fri, 26 Oct 2012 14:08:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRkaF-0002Bf-Uf
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 14:08:24 +0000
Received: from [85.158.143.99:31060] by server-1.bemta-4.messagelabs.com id
	AE/78-19134-7599A805; Fri, 26 Oct 2012 14:08:23 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-216.messagelabs.com!1351260502!17884261!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0NTA0ODA=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0NTA0ODA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29102 invoked from network); 26 Oct 2012 14:08:22 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Oct 2012 14:08:22 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll3s7vFSI=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-087-047.pools.arcor-ip.net [84.57.87.47])
	by smtp.strato.de (joses mo35) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id a02142o9QCuYZF ;
	Fri, 26 Oct 2012 16:08:22 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id AD31F18642; Fri, 26 Oct 2012 16:08:20 +0200 (CEST)
Date: Fri, 26 Oct 2012 16:08:20 +0200
From: Olaf Hering 
To: Konrad Rzeszutek Wilk 
Message-ID: <20121026140820.GA11453@aepfle.de>
References: 
	
	<20121025114645.GA7218@aepfle.de>
	<20121026115817.GA27383@localhost.localdomain>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20121026115817.GA27383@localhost.localdomain>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: Keir Fraser , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools/hvmloader: move shared_info to
 reserved memory area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 26, Konrad Rzeszutek Wilk wrote:

> On Thu, Oct 25, 2012 at 01:46:45PM +0200, Olaf Hering wrote:
> > On Thu, Oct 25, Keir Fraser wrote:
> > 
> > > To be honest, given that the XenPVHVM extensions to Linux won't have been
> > > tested on such old hypervisors, it wouldn't be a bad thing to bail on
> > > setting up the extensions when you detect running on a really old Xen
> > > version (e.g., earlier than 3.4.0) anyway. There's a fair chance of doing
> > > more harm than good?
> > 
> > I could stick such a check into
> > arch/x86/xen/enlighten.c:x86_hyper_xen_hvm->detect, by rearranging the
> > code of xen_hvm_platform and init_hvm_pv_info.  Konrad, what do you
> > think about that? Recent changes indicate that you did some testing on
> > 3.4 based hosts.
> 
> Sure. It might make sense to streamline this a bit. Meaning after the
> version check, have an int (or function) called 'xen_old_hypervisor()'
> which your code and the XenBus code could call?

Oh, my take would be to return false in xen_hvm_platform if the
hypervisor is 3.3 or older, so that the guest does not use the PVonHVM
extensions.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 14:08:44 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 14:08:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRkaH-0002Bk-2P; Fri, 26 Oct 2012 14:08:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRkaF-0002Bf-Uf
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 14:08:24 +0000
Received: from [85.158.143.99:31060] by server-1.bemta-4.messagelabs.com id
	AE/78-19134-7599A805; Fri, 26 Oct 2012 14:08:23 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-216.messagelabs.com!1351260502!17884261!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0NTA0ODA=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0NTA0ODA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29102 invoked from network); 26 Oct 2012 14:08:22 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Oct 2012 14:08:22 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll3s7vFSI=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-087-047.pools.arcor-ip.net [84.57.87.47])
	by smtp.strato.de (joses mo35) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id a02142o9QCuYZF ;
	Fri, 26 Oct 2012 16:08:22 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id AD31F18642; Fri, 26 Oct 2012 16:08:20 +0200 (CEST)
Date: Fri, 26 Oct 2012 16:08:20 +0200
From: Olaf Hering 
To: Konrad Rzeszutek Wilk 
Message-ID: <20121026140820.GA11453@aepfle.de>
References: 
	
	<20121025114645.GA7218@aepfle.de>
	<20121026115817.GA27383@localhost.localdomain>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20121026115817.GA27383@localhost.localdomain>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: Keir Fraser , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools/hvmloader: move shared_info to
 reserved memory area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 26, Konrad Rzeszutek Wilk wrote:

> On Thu, Oct 25, 2012 at 01:46:45PM +0200, Olaf Hering wrote:
> > On Thu, Oct 25, Keir Fraser wrote:
> > 
> > > To be honest, given that the XenPVHVM extensions to Linux won't have been
> > > tested on such old hypervisors, it wouldn't be a bad thing to bail on
> > > setting up the extensions when you detect running on a really old Xen
> > > version (e.g., earlier than 3.4.0) anyway. There's a fair chance of doing
> > > more harm than good?
> > 
> > I could stick such a check into
> > arch/x86/xen/enlighten.c:x86_hyper_xen_hvm->detect, by rearranging the
> > code of xen_hvm_platform and init_hvm_pv_info.  Konrad, what do you
> > think about that? Recent changes indicate that you did some testing on
> > 3.4 based hosts.
> 
> Sure. It might make sense to streamline this a bit. Meaning after the
> version check, have an int (or function) called 'xen_old_hypervisor()'
> which your code and the XenBus code could call?

Oh, my take would be to return false in xen_hvm_platform if the
hypervisor is 3.3 or older, so that the guest does not use the PVonHVM
extensions.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 15:25:46 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 15:25:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRlmd-000353-2O; Fri, 26 Oct 2012 15:25:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRlmc-00034y-58
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 15:25:14 +0000
Received: from [85.158.139.83:47602] by server-16.bemta-5.messagelabs.com id
	95/62-04786-95BAA805; Fri, 26 Oct 2012 15:25:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1351265112!23537337!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26510 invoked from network); 26 Oct 2012 15:25:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 15:25:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15414650"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 15:25:12 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 26 Oct 2012 16:25:11 +0100
Date: Fri, 26 Oct 2012 16:24:40 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1351253796.15162.63.camel@zakaz.uk.xensource.com>
Message-ID: 
References: 
	<1351091027-20740-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<1351159160.18035.147.camel@zakaz.uk.xensource.com>
	
	<1351236618.8558.4.camel@dagon.hellion.org.uk>
	
	<1351253796.15162.63.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" , "Tim
	\(Xen.org\)" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 5/7] xen/arm: wake up secondary cpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 26 Oct 2012, Ian Campbell wrote:
> On Fri, 2012-10-26 at 12:18 +0100, Stefano Stabellini wrote:
> > On Fri, 26 Oct 2012, Ian Campbell wrote:
> > > On Thu, 2012-10-25 at 18:45 +0100, Stefano Stabellini wrote:
> > > > > >  
> > > > > >  boot_cpu:
> > > > > > @@ -98,6 +98,10 @@ boot_cpu:
> > > > > >  	PRINT(" booting -\r\n")
> > > > > >  #endif
> > > > > >  
> > > > > > +	/* Wake up secondary cpus */
> > > > > > +	teq   r12, #0
> > > > > > +	bleq  kick_cpus
> > > > > 
> > > > > Does this have to be done this early? Couldn't we defer it to C land
> > > > > where it would be easier to isolate the processor/platform specific
> > > > > behaviour?
> > > > 
> > > > Yes, it does because we need to send an interrupt to cpus running in
> > > > secure mode, so this has to happen before we drop off secure state and we
> > > > enter hypervisor state.
> > > 
> > > Hrm, so maybe this stuff does belong in mode_switch.S after all?
> > > 
> > > Or is there perhaps some register (e.g. in the GIC?) which would allow
> > > non-secure hyp mode to sent an event to a processor in secure monitor
> > > mode?
> > 
> > Whether the target processor in secure mode receives the interrupt or
> > not, depends only on the GIC configuration on the target processor.
> > I don't think there is anything we can do from cpu0 in non-secure mode.
> 
> Isn't this controlled by the GICD_GROUP register, which can be set from
> cpu0 but affects all cpus?

GICD_GROUP0 is banked


> Or is it the case that we need to do this poke before mode_switch.S
> makes all interrupts into grp1 interrupts?

I don't think we can do that, it is the receiver cpu that would need to
do it

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 15:25:46 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 15:25:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRlmd-000353-2O; Fri, 26 Oct 2012 15:25:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRlmc-00034y-58
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 15:25:14 +0000
Received: from [85.158.139.83:47602] by server-16.bemta-5.messagelabs.com id
	95/62-04786-95BAA805; Fri, 26 Oct 2012 15:25:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1351265112!23537337!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26510 invoked from network); 26 Oct 2012 15:25:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 15:25:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15414650"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 15:25:12 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 26 Oct 2012 16:25:11 +0100
Date: Fri, 26 Oct 2012 16:24:40 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1351253796.15162.63.camel@zakaz.uk.xensource.com>
Message-ID: 
References: 
	<1351091027-20740-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<1351159160.18035.147.camel@zakaz.uk.xensource.com>
	
	<1351236618.8558.4.camel@dagon.hellion.org.uk>
	
	<1351253796.15162.63.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" , "Tim
	\(Xen.org\)" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 5/7] xen/arm: wake up secondary cpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 26 Oct 2012, Ian Campbell wrote:
> On Fri, 2012-10-26 at 12:18 +0100, Stefano Stabellini wrote:
> > On Fri, 26 Oct 2012, Ian Campbell wrote:
> > > On Thu, 2012-10-25 at 18:45 +0100, Stefano Stabellini wrote:
> > > > > >  
> > > > > >  boot_cpu:
> > > > > > @@ -98,6 +98,10 @@ boot_cpu:
> > > > > >  	PRINT(" booting -\r\n")
> > > > > >  #endif
> > > > > >  
> > > > > > +	/* Wake up secondary cpus */
> > > > > > +	teq   r12, #0
> > > > > > +	bleq  kick_cpus
> > > > > 
> > > > > Does this have to be done this early? Couldn't we defer it to C land
> > > > > where it would be easier to isolate the processor/platform specific
> > > > > behaviour?
> > > > 
> > > > Yes, it does because we need to send an interrupt to cpus running in
> > > > secure mode, so this has to happen before we drop off secure state and we
> > > > enter hypervisor state.
> > > 
> > > Hrm, so maybe this stuff does belong in mode_switch.S after all?
> > > 
> > > Or is there perhaps some register (e.g. in the GIC?) which would allow
> > > non-secure hyp mode to sent an event to a processor in secure monitor
> > > mode?
> > 
> > Whether the target processor in secure mode receives the interrupt or
> > not, depends only on the GIC configuration on the target processor.
> > I don't think there is anything we can do from cpu0 in non-secure mode.
> 
> Isn't this controlled by the GICD_GROUP register, which can be set from
> cpu0 but affects all cpus?

GICD_GROUP0 is banked


> Or is it the case that we need to do this poke before mode_switch.S
> makes all interrupts into grp1 interrupts?

I don't think we can do that, it is the receiver cpu that would need to
do it

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 15:33:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 15:33:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRlu8-0003Hd-3g; Fri, 26 Oct 2012 15:33:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRlu6-0003HY-S1
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 15:32:59 +0000
Received: from [85.158.143.35:17920] by server-1.bemta-4.messagelabs.com id
	9A/E5-19134-A2DAA805; Fri, 26 Oct 2012 15:32:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1351265572!13361896!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27113 invoked from network); 26 Oct 2012 15:32:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 15:32:52 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15414831"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 15:32:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 16:32:49 +0100
Message-ID: <1351265568.15162.88.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Fri, 26 Oct 2012 16:32:48 +0100
In-Reply-To: 
References: 
	<1351091027-20740-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<1351159160.18035.147.camel@zakaz.uk.xensource.com>
	
	<1351236618.8558.4.camel@dagon.hellion.org.uk>
	
	<1351253796.15162.63.camel@zakaz.uk.xensource.com>
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" , "Tim
	\(Xen.org\)" 
Subject: Re: [Xen-devel] [PATCH 5/7] xen/arm: wake up secondary cpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-26 at 16:24 +0100, Stefano Stabellini wrote:
> On Fri, 26 Oct 2012, Ian Campbell wrote:
> > On Fri, 2012-10-26 at 12:18 +0100, Stefano Stabellini wrote:
> > > On Fri, 26 Oct 2012, Ian Campbell wrote:
> > > > On Thu, 2012-10-25 at 18:45 +0100, Stefano Stabellini wrote:
> > > > > > >  
> > > > > > >  boot_cpu:
> > > > > > > @@ -98,6 +98,10 @@ boot_cpu:
> > > > > > >  	PRINT(" booting -\r\n")
> > > > > > >  #endif
> > > > > > >  
> > > > > > > +	/* Wake up secondary cpus */
> > > > > > > +	teq   r12, #0
> > > > > > > +	bleq  kick_cpus
> > > > > > 
> > > > > > Does this have to be done this early? Couldn't we defer it to C land
> > > > > > where it would be easier to isolate the processor/platform specific
> > > > > > behaviour?
> > > > > 
> > > > > Yes, it does because we need to send an interrupt to cpus running in
> > > > > secure mode, so this has to happen before we drop off secure state and we
> > > > > enter hypervisor state.
> > > > 
> > > > Hrm, so maybe this stuff does belong in mode_switch.S after all?
> > > > 
> > > > Or is there perhaps some register (e.g. in the GIC?) which would allow
> > > > non-secure hyp mode to sent an event to a processor in secure monitor
> > > > mode?
> > > 
> > > Whether the target processor in secure mode receives the interrupt or
> > > not, depends only on the GIC configuration on the target processor.
> > > I don't think there is anything we can do from cpu0 in non-secure mode.
> > 
> > Isn't this controlled by the GICD_GROUP register, which can be set from
> > cpu0 but affects all cpus?
> 
> GICD_GROUP0 is banked

Damn, right.

> 
> 
> > Or is it the case that we need to do this poke before mode_switch.S
> > makes all interrupts into grp1 interrupts?
> 
> I don't think we can do that, it is the receiver cpu that would need to
> do it



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 15:33:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 15:33:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRlu8-0003Hd-3g; Fri, 26 Oct 2012 15:33:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRlu6-0003HY-S1
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 15:32:59 +0000
Received: from [85.158.143.35:17920] by server-1.bemta-4.messagelabs.com id
	9A/E5-19134-A2DAA805; Fri, 26 Oct 2012 15:32:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1351265572!13361896!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27113 invoked from network); 26 Oct 2012 15:32:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 15:32:52 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15414831"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 15:32:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 16:32:49 +0100
Message-ID: <1351265568.15162.88.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Fri, 26 Oct 2012 16:32:48 +0100
In-Reply-To: 
References: 
	<1351091027-20740-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<1351159160.18035.147.camel@zakaz.uk.xensource.com>
	
	<1351236618.8558.4.camel@dagon.hellion.org.uk>
	
	<1351253796.15162.63.camel@zakaz.uk.xensource.com>
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" , "Tim
	\(Xen.org\)" 
Subject: Re: [Xen-devel] [PATCH 5/7] xen/arm: wake up secondary cpus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-26 at 16:24 +0100, Stefano Stabellini wrote:
> On Fri, 26 Oct 2012, Ian Campbell wrote:
> > On Fri, 2012-10-26 at 12:18 +0100, Stefano Stabellini wrote:
> > > On Fri, 26 Oct 2012, Ian Campbell wrote:
> > > > On Thu, 2012-10-25 at 18:45 +0100, Stefano Stabellini wrote:
> > > > > > >  
> > > > > > >  boot_cpu:
> > > > > > > @@ -98,6 +98,10 @@ boot_cpu:
> > > > > > >  	PRINT(" booting -\r\n")
> > > > > > >  #endif
> > > > > > >  
> > > > > > > +	/* Wake up secondary cpus */
> > > > > > > +	teq   r12, #0
> > > > > > > +	bleq  kick_cpus
> > > > > > 
> > > > > > Does this have to be done this early? Couldn't we defer it to C land
> > > > > > where it would be easier to isolate the processor/platform specific
> > > > > > behaviour?
> > > > > 
> > > > > Yes, it does because we need to send an interrupt to cpus running in
> > > > > secure mode, so this has to happen before we drop off secure state and we
> > > > > enter hypervisor state.
> > > > 
> > > > Hrm, so maybe this stuff does belong in mode_switch.S after all?
> > > > 
> > > > Or is there perhaps some register (e.g. in the GIC?) which would allow
> > > > non-secure hyp mode to sent an event to a processor in secure monitor
> > > > mode?
> > > 
> > > Whether the target processor in secure mode receives the interrupt or
> > > not, depends only on the GIC configuration on the target processor.
> > > I don't think there is anything we can do from cpu0 in non-secure mode.
> > 
> > Isn't this controlled by the GICD_GROUP register, which can be set from
> > cpu0 but affects all cpus?
> 
> GICD_GROUP0 is banked

Damn, right.

> 
> 
> > Or is it the case that we need to do this poke before mode_switch.S
> > makes all interrupts into grp1 interrupts?
> 
> I don't think we can do that, it is the receiver cpu that would need to
> do it



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 15:52:07 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 15:52:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRmC8-0003YL-Ro; Fri, 26 Oct 2012 15:51:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRmC7-0003YG-Ko
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 15:51:35 +0000
Received: from [85.158.138.51:25912] by server-16.bemta-3.messagelabs.com id
	F5/81-07461-381BA805; Fri, 26 Oct 2012 15:51:31 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-174.messagelabs.com!1351266690!23536982!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0NTA0ODA=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0NTA0ODA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26321 invoked from network); 26 Oct 2012 15:51:30 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Oct 2012 15:51:30 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll3s7vFSI=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-087-047.pools.arcor-ip.net [84.57.87.47])
	by smtp.strato.de (joses mo27) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id k01fc6o9QELKYt ;
	Fri, 26 Oct 2012 17:51:30 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 0723F18642; Fri, 26 Oct 2012 17:51:28 +0200 (CEST)
Date: Fri, 26 Oct 2012 17:51:28 +0200
From: Olaf Hering 
To: Konrad Rzeszutek Wilk 
Message-ID: <20121026155128.GA18615@aepfle.de>
References: 
	
	<20121025114645.GA7218@aepfle.de>
	<20121026115817.GA27383@localhost.localdomain>
	<20121026140820.GA11453@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20121026140820.GA11453@aepfle.de>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: Keir Fraser , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools/hvmloader: move shared_info to
 reserved memory area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 26, Olaf Hering wrote:

> Oh, my take would be to return false in xen_hvm_platform if the
> hypervisor is 3.3 or older, so that the guest does not use the PVonHVM
> extensions.

Like this untested patch:

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 0cc41f8..8566fa8 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1543,17 +1543,10 @@ static void __init xen_hvm_init_shared_info(void)
 
 static void __init init_hvm_pv_info(void)
 {
-	int major, minor;
 	uint32_t eax, ebx, ecx, edx, pages, msr, base;
 	u64 pfn;
 
 	base = xen_cpuid_base();
-	cpuid(base + 1, &eax, &ebx, &ecx, &edx);
-
-	major = eax >> 16;
-	minor = eax & 0xffff;
-	printk(KERN_INFO "Xen version %d.%d.\n", major, minor);
-
 	cpuid(base + 2, &pages, &msr, &ecx, &edx);
 
 	pfn = __pa(hypercall_page);
@@ -1604,13 +1597,29 @@ static void __init xen_hvm_guest_init(void)
 
 static bool __init xen_hvm_platform(void)
 {
+	int major, minor, old = 0;
+	uint32_t eax, ebx, ecx, edx, base;
+	bool usable = true;
+
 	if (xen_pv_domain())
 		return false;
 
-	if (!xen_cpuid_base())
+	base = xen_cpuid_base();
+	if (!base)
 		return false;
 
-	return true;
+	cpuid(base + 1, &eax, &ebx, &ecx, &edx);
+
+	major = eax >> 16;
+	minor = eax & 0xffff;
+
+	/* Require at least Xen 3.4 */
+	if (major < 3 || (major == 3 && minor < 4))
+		usable = false;
+	printk(KERN_INFO "Xen version %d.%d.%s\n",
+		major, minor, usable ? "" : " (too old)");
+
+	return usable;
 }
 
 bool xen_hvm_need_lapic(void)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 15:52:07 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 15:52:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRmC8-0003YL-Ro; Fri, 26 Oct 2012 15:51:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRmC7-0003YG-Ko
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 15:51:35 +0000
Received: from [85.158.138.51:25912] by server-16.bemta-3.messagelabs.com id
	F5/81-07461-381BA805; Fri, 26 Oct 2012 15:51:31 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-174.messagelabs.com!1351266690!23536982!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0NTA0ODA=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0NTA0ODA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26321 invoked from network); 26 Oct 2012 15:51:30 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Oct 2012 15:51:30 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll3s7vFSI=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-087-047.pools.arcor-ip.net [84.57.87.47])
	by smtp.strato.de (joses mo27) (RZmta 30.20 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id k01fc6o9QELKYt ;
	Fri, 26 Oct 2012 17:51:30 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 0723F18642; Fri, 26 Oct 2012 17:51:28 +0200 (CEST)
Date: Fri, 26 Oct 2012 17:51:28 +0200
From: Olaf Hering 
To: Konrad Rzeszutek Wilk 
Message-ID: <20121026155128.GA18615@aepfle.de>
References: 
	
	<20121025114645.GA7218@aepfle.de>
	<20121026115817.GA27383@localhost.localdomain>
	<20121026140820.GA11453@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20121026140820.GA11453@aepfle.de>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: Keir Fraser , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools/hvmloader: move shared_info to
 reserved memory area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 26, Olaf Hering wrote:

> Oh, my take would be to return false in xen_hvm_platform if the
> hypervisor is 3.3 or older, so that the guest does not use the PVonHVM
> extensions.

Like this untested patch:

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 0cc41f8..8566fa8 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1543,17 +1543,10 @@ static void __init xen_hvm_init_shared_info(void)
 
 static void __init init_hvm_pv_info(void)
 {
-	int major, minor;
 	uint32_t eax, ebx, ecx, edx, pages, msr, base;
 	u64 pfn;
 
 	base = xen_cpuid_base();
-	cpuid(base + 1, &eax, &ebx, &ecx, &edx);
-
-	major = eax >> 16;
-	minor = eax & 0xffff;
-	printk(KERN_INFO "Xen version %d.%d.\n", major, minor);
-
 	cpuid(base + 2, &pages, &msr, &ecx, &edx);
 
 	pfn = __pa(hypercall_page);
@@ -1604,13 +1597,29 @@ static void __init xen_hvm_guest_init(void)
 
 static bool __init xen_hvm_platform(void)
 {
+	int major, minor, old = 0;
+	uint32_t eax, ebx, ecx, edx, base;
+	bool usable = true;
+
 	if (xen_pv_domain())
 		return false;
 
-	if (!xen_cpuid_base())
+	base = xen_cpuid_base();
+	if (!base)
 		return false;
 
-	return true;
+	cpuid(base + 1, &eax, &ebx, &ecx, &edx);
+
+	major = eax >> 16;
+	minor = eax & 0xffff;
+
+	/* Require at least Xen 3.4 */
+	if (major < 3 || (major == 3 && minor < 4))
+		usable = false;
+	printk(KERN_INFO "Xen version %d.%d.%s\n",
+		major, minor, usable ? "" : " (too old)");
+
+	return usable;
 }
 
 bool xen_hvm_need_lapic(void)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 15:55:00 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 15:55:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRmF2-0003dz-EI; Fri, 26 Oct 2012 15:54:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRmF1-0003ds-3V
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 15:54:35 +0000
Received: from [85.158.139.211:17702] by server-9.bemta-5.messagelabs.com id
	7D/A1-23053-A32BA805; Fri, 26 Oct 2012 15:54:34 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1351266873!23860462!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15942 invoked from network); 26 Oct 2012 15:54:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 15:54:33 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15415226"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 15:53:45 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 26 Oct 2012 16:53:45 +0100
Date: Fri, 26 Oct 2012 16:53:14 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Tim Deegan 
In-Reply-To: <20121026090141.GB76080@ocelot.phlegethon.org>
Message-ID: 
References: 
	<1351091027-20740-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20121024155945.GD39126@ocelot.phlegethon.org>
	
	<20121026090141.GB76080@ocelot.phlegethon.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	Ian Campbell ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 6/7] xen/arm: flush D-cache and I-cache when
 appropriate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 26 Oct 2012, Tim Deegan wrote:
> At 18:35 +0100 on 24 Oct (1351103740), Stefano Stabellini wrote:
> > > I don't think this is necessary - why not just pass va directly to the
> > > inline asm?  We don't care what register it's in (and if we did I'm not
> > > convinced this would guarantee it was r0).
> > > 
> > > > +    asm volatile (
> > > > +        "dsb;"
> > > > +        STORE_CP32(0, DCCMVAC)
> > > > +        "isb;"
> > > > +        : : "r" (r0) : "memory");
> > > 
> > > Does this need a 'memory' clobber?  Can we get away with just saying it
> > > consumes *va as an input?  All we need to be sure of is that the
> > > particular thing we're flushing has been written out; no need to stop
> > > any other optimizations.
> > 
> > you are right on both points
> > 
> > > I guess it might need to be re-cast as a macro so the compiler knows how
> > > big *va is?
> > 
> > I don't think it is necessary, after all the size of a register has to
> > be the same of a virtual address
> 
> But it's the size of the thing in memory that's being flushed that
> matters, not the size of the pointer to it!
>
> E.g. after a PTE write we
> need a 64-bit memory input operand to stop the compiler from hoisting
> any part of the PTE write past the cache flush. (well OK we explicitly use
> a 64-bit atomic write for PTE writes, but YKWIM).

The implementation of write_pte is entirely in assembly so I doubt that
the compiler is going to reorder it.

However I see your point in case of flush_xen_dcache_va.
Wouldn't a barrier() at the beginning of the function be enough?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 15:55:00 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 15:55:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRmF2-0003dz-EI; Fri, 26 Oct 2012 15:54:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRmF1-0003ds-3V
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 15:54:35 +0000
Received: from [85.158.139.211:17702] by server-9.bemta-5.messagelabs.com id
	7D/A1-23053-A32BA805; Fri, 26 Oct 2012 15:54:34 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1351266873!23860462!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15942 invoked from network); 26 Oct 2012 15:54:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 15:54:33 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15415226"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 15:53:45 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 26 Oct 2012 16:53:45 +0100
Date: Fri, 26 Oct 2012 16:53:14 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Tim Deegan 
In-Reply-To: <20121026090141.GB76080@ocelot.phlegethon.org>
Message-ID: 
References: 
	<1351091027-20740-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20121024155945.GD39126@ocelot.phlegethon.org>
	
	<20121026090141.GB76080@ocelot.phlegethon.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	Ian Campbell ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 6/7] xen/arm: flush D-cache and I-cache when
 appropriate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 26 Oct 2012, Tim Deegan wrote:
> At 18:35 +0100 on 24 Oct (1351103740), Stefano Stabellini wrote:
> > > I don't think this is necessary - why not just pass va directly to the
> > > inline asm?  We don't care what register it's in (and if we did I'm not
> > > convinced this would guarantee it was r0).
> > > 
> > > > +    asm volatile (
> > > > +        "dsb;"
> > > > +        STORE_CP32(0, DCCMVAC)
> > > > +        "isb;"
> > > > +        : : "r" (r0) : "memory");
> > > 
> > > Does this need a 'memory' clobber?  Can we get away with just saying it
> > > consumes *va as an input?  All we need to be sure of is that the
> > > particular thing we're flushing has been written out; no need to stop
> > > any other optimizations.
> > 
> > you are right on both points
> > 
> > > I guess it might need to be re-cast as a macro so the compiler knows how
> > > big *va is?
> > 
> > I don't think it is necessary, after all the size of a register has to
> > be the same of a virtual address
> 
> But it's the size of the thing in memory that's being flushed that
> matters, not the size of the pointer to it!
>
> E.g. after a PTE write we
> need a 64-bit memory input operand to stop the compiler from hoisting
> any part of the PTE write past the cache flush. (well OK we explicitly use
> a 64-bit atomic write for PTE writes, but YKWIM).

The implementation of write_pte is entirely in assembly so I doubt that
the compiler is going to reorder it.

However I see your point in case of flush_xen_dcache_va.
Wouldn't a barrier() at the beginning of the function be enough?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 15:56:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 15:56:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRmGg-0003kX-VI; Fri, 26 Oct 2012 15:56:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRmGf-0003kN-Ty
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 15:56:18 +0000
Received: from [85.158.137.99:16986] by server-9.bemta-3.messagelabs.com id
	63/27-16841-1A2BA805; Fri, 26 Oct 2012 15:56:17 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1351266976!12545301!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3038 invoked from network); 26 Oct 2012 15:56:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 15:56:16 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15415284"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 15:56:16 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 26 Oct 2012 16:56:16 +0100
Date: Fri, 26 Oct 2012 16:55:44 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Stefano Stabellini 
In-Reply-To: 
Message-ID: 
References: 
	<1351091027-20740-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20121024155945.GD39126@ocelot.phlegethon.org>
	
	<20121026090141.GB76080@ocelot.phlegethon.org>
	
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	"Tim \(Xen.org\)" , Ian Campbell 
Subject: Re: [Xen-devel] [PATCH 6/7] xen/arm: flush D-cache and I-cache when
 appropriate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 26 Oct 2012, Stefano Stabellini wrote:
> On Fri, 26 Oct 2012, Tim Deegan wrote:
> > At 18:35 +0100 on 24 Oct (1351103740), Stefano Stabellini wrote:
> > > > I don't think this is necessary - why not just pass va directly to the
> > > > inline asm?  We don't care what register it's in (and if we did I'm not
> > > > convinced this would guarantee it was r0).
> > > > 
> > > > > +    asm volatile (
> > > > > +        "dsb;"
> > > > > +        STORE_CP32(0, DCCMVAC)
> > > > > +        "isb;"
> > > > > +        : : "r" (r0) : "memory");
> > > > 
> > > > Does this need a 'memory' clobber?  Can we get away with just saying it
> > > > consumes *va as an input?  All we need to be sure of is that the
> > > > particular thing we're flushing has been written out; no need to stop
> > > > any other optimizations.
> > > 
> > > you are right on both points
> > > 
> > > > I guess it might need to be re-cast as a macro so the compiler knows how
> > > > big *va is?
> > > 
> > > I don't think it is necessary, after all the size of a register has to
> > > be the same of a virtual address
> > 
> > But it's the size of the thing in memory that's being flushed that
> > matters, not the size of the pointer to it!
> >
> > E.g. after a PTE write we
> > need a 64-bit memory input operand to stop the compiler from hoisting
> > any part of the PTE write past the cache flush. (well OK we explicitly use
> > a 64-bit atomic write for PTE writes, but YKWIM).
> 
> The implementation of write_pte is entirely in assembly so I doubt that
> the compiler is going to reorder it.
> 
> However I see your point in case of flush_xen_dcache_va.
> Wouldn't a barrier() at the beginning of the function be enough?
>

Actually we already have a memory clobber in flush_xen_dcache_va,
shouldn't that prevent the compiler from reordering instructions?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 15:56:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 15:56:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRmGg-0003kX-VI; Fri, 26 Oct 2012 15:56:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRmGf-0003kN-Ty
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 15:56:18 +0000
Received: from [85.158.137.99:16986] by server-9.bemta-3.messagelabs.com id
	63/27-16841-1A2BA805; Fri, 26 Oct 2012 15:56:17 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1351266976!12545301!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3038 invoked from network); 26 Oct 2012 15:56:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 15:56:16 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15415284"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 15:56:16 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 26 Oct 2012 16:56:16 +0100
Date: Fri, 26 Oct 2012 16:55:44 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Stefano Stabellini 
In-Reply-To: 
Message-ID: 
References: 
	<1351091027-20740-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20121024155945.GD39126@ocelot.phlegethon.org>
	
	<20121026090141.GB76080@ocelot.phlegethon.org>
	
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	"Tim \(Xen.org\)" , Ian Campbell 
Subject: Re: [Xen-devel] [PATCH 6/7] xen/arm: flush D-cache and I-cache when
 appropriate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 26 Oct 2012, Stefano Stabellini wrote:
> On Fri, 26 Oct 2012, Tim Deegan wrote:
> > At 18:35 +0100 on 24 Oct (1351103740), Stefano Stabellini wrote:
> > > > I don't think this is necessary - why not just pass va directly to the
> > > > inline asm?  We don't care what register it's in (and if we did I'm not
> > > > convinced this would guarantee it was r0).
> > > > 
> > > > > +    asm volatile (
> > > > > +        "dsb;"
> > > > > +        STORE_CP32(0, DCCMVAC)
> > > > > +        "isb;"
> > > > > +        : : "r" (r0) : "memory");
> > > > 
> > > > Does this need a 'memory' clobber?  Can we get away with just saying it
> > > > consumes *va as an input?  All we need to be sure of is that the
> > > > particular thing we're flushing has been written out; no need to stop
> > > > any other optimizations.
> > > 
> > > you are right on both points
> > > 
> > > > I guess it might need to be re-cast as a macro so the compiler knows how
> > > > big *va is?
> > > 
> > > I don't think it is necessary, after all the size of a register has to
> > > be the same of a virtual address
> > 
> > But it's the size of the thing in memory that's being flushed that
> > matters, not the size of the pointer to it!
> >
> > E.g. after a PTE write we
> > need a 64-bit memory input operand to stop the compiler from hoisting
> > any part of the PTE write past the cache flush. (well OK we explicitly use
> > a 64-bit atomic write for PTE writes, but YKWIM).
> 
> The implementation of write_pte is entirely in assembly so I doubt that
> the compiler is going to reorder it.
> 
> However I see your point in case of flush_xen_dcache_va.
> Wouldn't a barrier() at the beginning of the function be enough?
>

Actually we already have a memory clobber in flush_xen_dcache_va,
shouldn't that prevent the compiler from reordering instructions?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 16:05:07 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 16:05:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRmOr-0004Wi-PH; Fri, 26 Oct 2012 16:04:45 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRmOq-0004Wd-Mb
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 16:04:44 +0000
Received: from [193.109.254.147:2921] by server-12.bemta-14.messagelabs.com id
	98/14-00510-B94BA805; Fri, 26 Oct 2012 16:04:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1351267480!8647921!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11720 invoked from network); 26 Oct 2012 16:04:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 16:04:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15415464"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 16:04:09 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 26 Oct 2012 17:04:09 +0100
Date: Fri, 26 Oct 2012 17:03:38 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Stefano Stabellini 
In-Reply-To: 
Message-ID: 
References: 
	<1351091027-20740-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20121024155945.GD39126@ocelot.phlegethon.org>
	
	<20121026090141.GB76080@ocelot.phlegethon.org>
	
	
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	"Tim \(Xen.org\)" , Ian Campbell 
Subject: Re: [Xen-devel] [PATCH 6/7] xen/arm: flush D-cache and I-cache when
 appropriate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 26 Oct 2012, Stefano Stabellini wrote:
> On Fri, 26 Oct 2012, Stefano Stabellini wrote:
> > On Fri, 26 Oct 2012, Tim Deegan wrote:
> > > At 18:35 +0100 on 24 Oct (1351103740), Stefano Stabellini wrote:
> > > > > I don't think this is necessary - why not just pass va directly to the
> > > > > inline asm?  We don't care what register it's in (and if we did I'm not
> > > > > convinced this would guarantee it was r0).
> > > > > 
> > > > > > +    asm volatile (
> > > > > > +        "dsb;"
> > > > > > +        STORE_CP32(0, DCCMVAC)
> > > > > > +        "isb;"
> > > > > > +        : : "r" (r0) : "memory");
> > > > > 
> > > > > Does this need a 'memory' clobber?  Can we get away with just saying it
> > > > > consumes *va as an input?  All we need to be sure of is that the
> > > > > particular thing we're flushing has been written out; no need to stop
> > > > > any other optimizations.
> > > > 
> > > > you are right on both points
> > > > 
> > > > > I guess it might need to be re-cast as a macro so the compiler knows how
> > > > > big *va is?
> > > > 
> > > > I don't think it is necessary, after all the size of a register has to
> > > > be the same of a virtual address
> > > 
> > > But it's the size of the thing in memory that's being flushed that
> > > matters, not the size of the pointer to it!
> > >
> > > E.g. after a PTE write we
> > > need a 64-bit memory input operand to stop the compiler from hoisting
> > > any part of the PTE write past the cache flush. (well OK we explicitly use
> > > a 64-bit atomic write for PTE writes, but YKWIM).
> > 
> > The implementation of write_pte is entirely in assembly so I doubt that
> > the compiler is going to reorder it.
> > 
> > However I see your point in case of flush_xen_dcache_va.
> > Wouldn't a barrier() at the beginning of the function be enough?
> >
> 
> Actually we already have a memory clobber in flush_xen_dcache_va,
> shouldn't that prevent the compiler from reordering instructions?
> 

After reading again the entire thread I think that I understand what you
meant: can't we get rid of the memory clobber and specify *va as input?

However in order to do that correctly we need to make clear how big *va is
otherwise the compiler could reorder things.

The problem is that we don't know at compile time how big a cacheline
is, so I think that we need to keep the memory clobber.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 16:05:07 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 16:05:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRmOr-0004Wi-PH; Fri, 26 Oct 2012 16:04:45 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRmOq-0004Wd-Mb
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 16:04:44 +0000
Received: from [193.109.254.147:2921] by server-12.bemta-14.messagelabs.com id
	98/14-00510-B94BA805; Fri, 26 Oct 2012 16:04:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1351267480!8647921!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11720 invoked from network); 26 Oct 2012 16:04:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 16:04:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15415464"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 16:04:09 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 26 Oct 2012 17:04:09 +0100
Date: Fri, 26 Oct 2012 17:03:38 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Stefano Stabellini 
In-Reply-To: 
Message-ID: 
References: 
	<1351091027-20740-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20121024155945.GD39126@ocelot.phlegethon.org>
	
	<20121026090141.GB76080@ocelot.phlegethon.org>
	
	
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	"Tim \(Xen.org\)" , Ian Campbell 
Subject: Re: [Xen-devel] [PATCH 6/7] xen/arm: flush D-cache and I-cache when
 appropriate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 26 Oct 2012, Stefano Stabellini wrote:
> On Fri, 26 Oct 2012, Stefano Stabellini wrote:
> > On Fri, 26 Oct 2012, Tim Deegan wrote:
> > > At 18:35 +0100 on 24 Oct (1351103740), Stefano Stabellini wrote:
> > > > > I don't think this is necessary - why not just pass va directly to the
> > > > > inline asm?  We don't care what register it's in (and if we did I'm not
> > > > > convinced this would guarantee it was r0).
> > > > > 
> > > > > > +    asm volatile (
> > > > > > +        "dsb;"
> > > > > > +        STORE_CP32(0, DCCMVAC)
> > > > > > +        "isb;"
> > > > > > +        : : "r" (r0) : "memory");
> > > > > 
> > > > > Does this need a 'memory' clobber?  Can we get away with just saying it
> > > > > consumes *va as an input?  All we need to be sure of is that the
> > > > > particular thing we're flushing has been written out; no need to stop
> > > > > any other optimizations.
> > > > 
> > > > you are right on both points
> > > > 
> > > > > I guess it might need to be re-cast as a macro so the compiler knows how
> > > > > big *va is?
> > > > 
> > > > I don't think it is necessary, after all the size of a register has to
> > > > be the same of a virtual address
> > > 
> > > But it's the size of the thing in memory that's being flushed that
> > > matters, not the size of the pointer to it!
> > >
> > > E.g. after a PTE write we
> > > need a 64-bit memory input operand to stop the compiler from hoisting
> > > any part of the PTE write past the cache flush. (well OK we explicitly use
> > > a 64-bit atomic write for PTE writes, but YKWIM).
> > 
> > The implementation of write_pte is entirely in assembly so I doubt that
> > the compiler is going to reorder it.
> > 
> > However I see your point in case of flush_xen_dcache_va.
> > Wouldn't a barrier() at the beginning of the function be enough?
> >
> 
> Actually we already have a memory clobber in flush_xen_dcache_va,
> shouldn't that prevent the compiler from reordering instructions?
> 

After reading again the entire thread I think that I understand what you
meant: can't we get rid of the memory clobber and specify *va as input?

However in order to do that correctly we need to make clear how big *va is
otherwise the compiler could reorder things.

The problem is that we don't know at compile time how big a cacheline
is, so I think that we need to keep the memory clobber.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 16:09:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 16:09:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRmT3-0004g4-Lu; Fri, 26 Oct 2012 16:09:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRmT1-0004fz-H9
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 16:09:03 +0000
Received: from [85.158.139.83:17107] by server-6.bemta-5.messagelabs.com id
	D2/84-32589-E95BA805; Fri, 26 Oct 2012 16:09:02 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1351267740!23620332!1
X-Originating-IP: [209.85.220.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23072 invoked from network); 26 Oct 2012 16:09:02 -0000
Received: from mail-pa0-f45.google.com (HELO mail-pa0-f45.google.com)
	(209.85.220.45)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 16:09:02 -0000
Received: by mail-pa0-f45.google.com with SMTP id fb10so2114364pad.32
	for ; Fri, 26 Oct 2012 09:08:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=WHOxF4IZKCBHIXvE1Xyd0ZGddYUIjPhDIVU05ceCcnE=;
	b=Adb/xyN2pg1UUWlTSf/jdrUbSzVYK/4y9XzJj5lNNalr9zoyMnArkNlAN3J9/EtaTS
	ILPjas6k9vwXuYWkYUnXqmjc/GO1Fk2u2XPJb3jq/DqwXeZpalvW0YxlPWF/huFxDBhZ
	ERYzmRTLF1EFjrXirUWUcFvnDAtfT2TOwF9gB6AayEbyye1ezDm1u83t/i8sxFsRsrEc
	CTXyG5UaapYGMdaId3Vqmvr0Bo+PV1FQtE20vMmvX2JijDpr1Sa9YpiTk4YKE413vFqh
	ReqDkdDNw9sDNa0tPnaYhnV5C99UqJyJmoKS9n0LPJkNeg3XGlpMl5w5FrPwhP2+LLN8
	gqqg==
Received: by 10.68.218.226 with SMTP id pj2mr71501471pbc.33.1351267739880;
	Fri, 26 Oct 2012 09:08:59 -0700 (PDT)
Received: from [10.128.0.122] (S0106001c25a066a0.vc.shawcable.net.
	[24.85.255.130])
	by mx.google.com with ESMTPS id op7sm1366949pbc.52.2012.10.26.09.08.55
	(version=SSLv3 cipher=OTHER); Fri, 26 Oct 2012 09:08:58 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Fri, 26 Oct 2012 09:08:51 -0700
From: Keir Fraser 
To: Olaf Hering ,
	Konrad Rzeszutek Wilk 
Message-ID: 
Thread-Topic: [Xen-devel] [PATCH] tools/hvmloader: move shared_info to
	reserved memory area
Thread-Index: Ac2zlDBFaLd//5QIy0GREJyDW/Nhgw==
In-Reply-To: <20121026155128.GA18615@aepfle.de>
Mime-version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools/hvmloader: move shared_info to
 reserved memory area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 26/10/2012 08:51, "Olaf Hering"  wrote:

> On Fri, Oct 26, Olaf Hering wrote:
> 
>> Oh, my take would be to return false in xen_hvm_platform if the
>> hypervisor is 3.3 or older, so that the guest does not use the PVonHVM
>> extensions.
> 
> Like this untested patch:

Looks okay to me.

 -- Keir

> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index 0cc41f8..8566fa8 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -1543,17 +1543,10 @@ static void __init xen_hvm_init_shared_info(void)
>  
>  static void __init init_hvm_pv_info(void)
>  {
> - int major, minor;
> uint32_t eax, ebx, ecx, edx, pages, msr, base;
> u64 pfn;
>  
> base = xen_cpuid_base();
> - cpuid(base + 1, &eax, &ebx, &ecx, &edx);
> -
> - major = eax >> 16;
> - minor = eax & 0xffff;
> - printk(KERN_INFO "Xen version %d.%d.\n", major, minor);
> -
> cpuid(base + 2, &pages, &msr, &ecx, &edx);
>  
> pfn = __pa(hypercall_page);
> @@ -1604,13 +1597,29 @@ static void __init xen_hvm_guest_init(void)
>  
>  static bool __init xen_hvm_platform(void)
>  {
> + int major, minor, old = 0;
> + uint32_t eax, ebx, ecx, edx, base;
> + bool usable = true;
> +
> if (xen_pv_domain())
> return false;
>  
> - if (!xen_cpuid_base())
> + base = xen_cpuid_base();
> + if (!base)
> return false;
>  
> - return true;
> + cpuid(base + 1, &eax, &ebx, &ecx, &edx);
> +
> + major = eax >> 16;
> + minor = eax & 0xffff;
> +
> + /* Require at least Xen 3.4 */
> + if (major < 3 || (major == 3 && minor < 4))
> +  usable = false;
> + printk(KERN_INFO "Xen version %d.%d.%s\n",
> +  major, minor, usable ? "" : " (too old)");
> +
> + return usable;
>  }
>  
>  bool xen_hvm_need_lapic(void)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 16:09:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 16:09:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRmT3-0004g4-Lu; Fri, 26 Oct 2012 16:09:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRmT1-0004fz-H9
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 16:09:03 +0000
Received: from [85.158.139.83:17107] by server-6.bemta-5.messagelabs.com id
	D2/84-32589-E95BA805; Fri, 26 Oct 2012 16:09:02 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1351267740!23620332!1
X-Originating-IP: [209.85.220.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23072 invoked from network); 26 Oct 2012 16:09:02 -0000
Received: from mail-pa0-f45.google.com (HELO mail-pa0-f45.google.com)
	(209.85.220.45)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 16:09:02 -0000
Received: by mail-pa0-f45.google.com with SMTP id fb10so2114364pad.32
	for ; Fri, 26 Oct 2012 09:08:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=WHOxF4IZKCBHIXvE1Xyd0ZGddYUIjPhDIVU05ceCcnE=;
	b=Adb/xyN2pg1UUWlTSf/jdrUbSzVYK/4y9XzJj5lNNalr9zoyMnArkNlAN3J9/EtaTS
	ILPjas6k9vwXuYWkYUnXqmjc/GO1Fk2u2XPJb3jq/DqwXeZpalvW0YxlPWF/huFxDBhZ
	ERYzmRTLF1EFjrXirUWUcFvnDAtfT2TOwF9gB6AayEbyye1ezDm1u83t/i8sxFsRsrEc
	CTXyG5UaapYGMdaId3Vqmvr0Bo+PV1FQtE20vMmvX2JijDpr1Sa9YpiTk4YKE413vFqh
	ReqDkdDNw9sDNa0tPnaYhnV5C99UqJyJmoKS9n0LPJkNeg3XGlpMl5w5FrPwhP2+LLN8
	gqqg==
Received: by 10.68.218.226 with SMTP id pj2mr71501471pbc.33.1351267739880;
	Fri, 26 Oct 2012 09:08:59 -0700 (PDT)
Received: from [10.128.0.122] (S0106001c25a066a0.vc.shawcable.net.
	[24.85.255.130])
	by mx.google.com with ESMTPS id op7sm1366949pbc.52.2012.10.26.09.08.55
	(version=SSLv3 cipher=OTHER); Fri, 26 Oct 2012 09:08:58 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Fri, 26 Oct 2012 09:08:51 -0700
From: Keir Fraser 
To: Olaf Hering ,
	Konrad Rzeszutek Wilk 
Message-ID: 
Thread-Topic: [Xen-devel] [PATCH] tools/hvmloader: move shared_info to
	reserved memory area
Thread-Index: Ac2zlDBFaLd//5QIy0GREJyDW/Nhgw==
In-Reply-To: <20121026155128.GA18615@aepfle.de>
Mime-version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools/hvmloader: move shared_info to
 reserved memory area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 26/10/2012 08:51, "Olaf Hering"  wrote:

> On Fri, Oct 26, Olaf Hering wrote:
> 
>> Oh, my take would be to return false in xen_hvm_platform if the
>> hypervisor is 3.3 or older, so that the guest does not use the PVonHVM
>> extensions.
> 
> Like this untested patch:

Looks okay to me.

 -- Keir

> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index 0cc41f8..8566fa8 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -1543,17 +1543,10 @@ static void __init xen_hvm_init_shared_info(void)
>  
>  static void __init init_hvm_pv_info(void)
>  {
> - int major, minor;
> uint32_t eax, ebx, ecx, edx, pages, msr, base;
> u64 pfn;
>  
> base = xen_cpuid_base();
> - cpuid(base + 1, &eax, &ebx, &ecx, &edx);
> -
> - major = eax >> 16;
> - minor = eax & 0xffff;
> - printk(KERN_INFO "Xen version %d.%d.\n", major, minor);
> -
> cpuid(base + 2, &pages, &msr, &ecx, &edx);
>  
> pfn = __pa(hypercall_page);
> @@ -1604,13 +1597,29 @@ static void __init xen_hvm_guest_init(void)
>  
>  static bool __init xen_hvm_platform(void)
>  {
> + int major, minor, old = 0;
> + uint32_t eax, ebx, ecx, edx, base;
> + bool usable = true;
> +
> if (xen_pv_domain())
> return false;
>  
> - if (!xen_cpuid_base())
> + base = xen_cpuid_base();
> + if (!base)
> return false;
>  
> - return true;
> + cpuid(base + 1, &eax, &ebx, &ecx, &edx);
> +
> + major = eax >> 16;
> + minor = eax & 0xffff;
> +
> + /* Require at least Xen 3.4 */
> + if (major < 3 || (major == 3 && minor < 4))
> +  usable = false;
> + printk(KERN_INFO "Xen version %d.%d.%s\n",
> +  major, minor, usable ? "" : " (too old)");
> +
> + return usable;
>  }
>  
>  bool xen_hvm_need_lapic(void)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 16:34:01 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 16:34:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRmqm-0004y6-RV; Fri, 26 Oct 2012 16:33:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRmqm-0004y1-5E
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 16:33:36 +0000
Received: from [85.158.139.83:23822] by server-9.bemta-5.messagelabs.com id
	54/EA-23053-F5BBA805; Fri, 26 Oct 2012 16:33:35 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1351269214!23622685!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24020 invoked from network); 26 Oct 2012 16:33:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 16:33:34 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15416513"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 16:33:32 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 26 Oct 2012 17:33:32 +0100
Date: Fri, 26 Oct 2012 17:33:01 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1351157246.18035.129.camel@zakaz.uk.xensource.com>
Message-ID: 
References: 
	<1351091027-20740-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1351157246.18035.129.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" , "Tim
	\(Xen.org\)" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 1/7] xen/arm: fix rank calculation in
 vgic_vcpu_inject_irq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 25 Oct 2012, Ian Campbell wrote:
> On Wed, 2012-10-24 at 16:03 +0100, Stefano Stabellini wrote:
> > Each rank holds 32 irqs, so we should divide by 32 rather than by 4.
> 
> I think this is wrong, because idx isn't used in the way your reasoning
> implies, when we use it we assume 8 bits-per-interrupt in the register
> not 1.
> 
> The accessor function vgix_irq_rank is couched in terms of
> GICD_, which is convenient where we are emulating register
> accesses but is very confusing in this one function where we aren't
> thinking in terms of registers!
> 
> vgic_irq_rank(v, 8, idx) is saying "find me the rank containing
> GICD_ where FOO has 8 bits per interrupt". Since 4 lots of 8
> bits goes into 32 we therefore need to divide by 4. This makes sense if
> you consider that FOO here is PRIORITY and that GICD_PRIORITY0 controls
> irq 0..3, GICD_PRIORITY1 irq 4..7 etc.
> 
> With idx = irq >> 2 you get:
> 
> IRQ00: idx = 00 REG_RANK_NR(08, 00) = 0, REG_RANK_INDEX(08, 00) = 0, BYTE = 0
> IRQ01: idx = 00 REG_RANK_NR(08, 00) = 0, REG_RANK_INDEX(08, 00) = 0, BYTE = 1
> IRQ02: idx = 00 REG_RANK_NR(08, 00) = 0, REG_RANK_INDEX(08, 00) = 0, BYTE = 2
> IRQ03: idx = 00 REG_RANK_NR(08, 00) = 0, REG_RANK_INDEX(08, 00) = 0, BYTE = 3
> IRQ04: idx = 01 REG_RANK_NR(08, 01) = 0, REG_RANK_INDEX(08, 01) = 1, BYTE = 0
> IRQ05: idx = 01 REG_RANK_NR(08, 01) = 0, REG_RANK_INDEX(08, 01) = 1, BYTE = 1
> [...]
> IRQ30: idx = 07 REG_RANK_NR(08, 07) = 0, REG_RANK_INDEX(08, 07) = 7, BYTE = 2
> IRQ31: idx = 07 REG_RANK_NR(08, 07) = 0, REG_RANK_INDEX(08, 07) = 7, BYTE = 3
> IRQ32: idx = 08 REG_RANK_NR(08, 08) = 1, REG_RANK_INDEX(08, 08) = 0, BYTE = 0
> IRQ33: idx = 08 REG_RANK_NR(08, 08) = 1, REG_RANK_INDEX(08, 08) = 0, BYTE = 1
> [...]
> IRQ62: idx = 15 REG_RANK_NR(08, 15) = 1, REG_RANK_INDEX(08, 15) = 7, BYTE = 2
> IRQ63: idx = 15 REG_RANK_NR(08, 15) = 1, REG_RANK_INDEX(08, 15) = 7, BYTE = 3
> IRQ64: idx = 16 REG_RANK_NR(08, 16) = 2, REG_RANK_INDEX(08, 16) = 0, BYTE = 0
> IRQ65: idx = 16 REG_RANK_NR(08, 16) = 2, REG_RANK_INDEX(08, 16) = 0, BYTE = 1
> [...]
> 
> IOW interrupts 0..31 are in rank 0, 32..63 are rank 1 etc, which is correct
> 
> With idx = irq / 32 you instead get:
> 
> IRQ00: idx = 00 REG_RANK_NR(08, 00) = 0, REG_RANK_INDEX(08, 00) = 0, BYTE = 0
> IRQ01: idx = 00 REG_RANK_NR(08, 00) = 0, REG_RANK_INDEX(08, 00) = 0, BYTE = 1
> IRQ02: idx = 00 REG_RANK_NR(08, 00) = 0, REG_RANK_INDEX(08, 00) = 0, BYTE = 2
> IRQ03: idx = 00 REG_RANK_NR(08, 00) = 0, REG_RANK_INDEX(08, 00) = 0, BYTE = 3
> IRQ04: idx = 00 REG_RANK_NR(08, 00) = 0, REG_RANK_INDEX(08, 00) = 0, BYTE = 0
> IRQ05: idx = 00 REG_RANK_NR(08, 00) = 0, REG_RANK_INDEX(08, 00) = 0, BYTE = 1
> [...]
> IRQ30: idx = 00 REG_RANK_NR(08, 00) = 0, REG_RANK_INDEX(08, 00) = 0, BYTE = 2
> IRQ31: idx = 00 REG_RANK_NR(08, 00) = 0, REG_RANK_INDEX(08, 00) = 0, BYTE = 3
> IRQ32: idx = 01 REG_RANK_NR(08, 01) = 0, REG_RANK_INDEX(08, 01) = 1, BYTE = 0
> IRQ33: idx = 01 REG_RANK_NR(08, 01) = 0, REG_RANK_INDEX(08, 01) = 1, BYTE = 1
> [...]
> IRQ62: idx = 01 REG_RANK_NR(08, 01) = 0, REG_RANK_INDEX(08, 01) = 1, BYTE = 2
> IRQ63: idx = 01 REG_RANK_NR(08, 01) = 0, REG_RANK_INDEX(08, 01) = 1, BYTE = 3
> IRQ64: idx = 02 REG_RANK_NR(08, 02) = 0, REG_RANK_INDEX(08, 02) = 2, BYTE = 0
> IRQ65: idx = 02 REG_RANK_NR(08, 02) = 0, REG_RANK_INDEX(08, 02) = 2, BYTE = 1
> [...]
> IRQ255: idx = 07 REG_RANK_NR(08, 07) = 0, REG_RANK_INDEX(08, 07) = 7, BYTE = 3
> IRQ256: idx = 08 REG_RANK_NR(08, 08) = 1, REG_RANK_INDEX(08, 08) = 0, BYTE = 0
> 
> Here allinterrupts up to 255 are in rank 0, which is wrong.
> 
> For idx = irq / 32 you would need to use REG_RANK_NR(1, idx) not (8,
> idx). (and you'd need to trivially fix REG_RANK_NR to handle b == 1).
> 
> Perhaps the way to think of it is not as "/ 32" but rather as ">> 5". 
> Since REG_RANK_NR(8, ) is effectively >> 3 when combined with the
> existing >> 2 we get >> 5 overall.
> 
> If you change it as you have done then you are doing >> 5 *and* >> 3,
> i.e. >> 8 aka "/ 256" -- which explains why interrupts up to 255 end up
> in rank 0 with your change.

Your explanation is sounds, but the fact remains that the code doesn't
work as is :)
It means that this patch hides the bug rather than fixing it...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 16:34:01 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 16:34:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRmqm-0004y6-RV; Fri, 26 Oct 2012 16:33:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRmqm-0004y1-5E
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 16:33:36 +0000
Received: from [85.158.139.83:23822] by server-9.bemta-5.messagelabs.com id
	54/EA-23053-F5BBA805; Fri, 26 Oct 2012 16:33:35 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1351269214!23622685!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24020 invoked from network); 26 Oct 2012 16:33:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 16:33:34 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15416513"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 16:33:32 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 26 Oct 2012 17:33:32 +0100
Date: Fri, 26 Oct 2012 17:33:01 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1351157246.18035.129.camel@zakaz.uk.xensource.com>
Message-ID: 
References: 
	<1351091027-20740-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1351157246.18035.129.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" , "Tim
	\(Xen.org\)" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 1/7] xen/arm: fix rank calculation in
 vgic_vcpu_inject_irq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 25 Oct 2012, Ian Campbell wrote:
> On Wed, 2012-10-24 at 16:03 +0100, Stefano Stabellini wrote:
> > Each rank holds 32 irqs, so we should divide by 32 rather than by 4.
> 
> I think this is wrong, because idx isn't used in the way your reasoning
> implies, when we use it we assume 8 bits-per-interrupt in the register
> not 1.
> 
> The accessor function vgix_irq_rank is couched in terms of
> GICD_, which is convenient where we are emulating register
> accesses but is very confusing in this one function where we aren't
> thinking in terms of registers!
> 
> vgic_irq_rank(v, 8, idx) is saying "find me the rank containing
> GICD_ where FOO has 8 bits per interrupt". Since 4 lots of 8
> bits goes into 32 we therefore need to divide by 4. This makes sense if
> you consider that FOO here is PRIORITY and that GICD_PRIORITY0 controls
> irq 0..3, GICD_PRIORITY1 irq 4..7 etc.
> 
> With idx = irq >> 2 you get:
> 
> IRQ00: idx = 00 REG_RANK_NR(08, 00) = 0, REG_RANK_INDEX(08, 00) = 0, BYTE = 0
> IRQ01: idx = 00 REG_RANK_NR(08, 00) = 0, REG_RANK_INDEX(08, 00) = 0, BYTE = 1
> IRQ02: idx = 00 REG_RANK_NR(08, 00) = 0, REG_RANK_INDEX(08, 00) = 0, BYTE = 2
> IRQ03: idx = 00 REG_RANK_NR(08, 00) = 0, REG_RANK_INDEX(08, 00) = 0, BYTE = 3
> IRQ04: idx = 01 REG_RANK_NR(08, 01) = 0, REG_RANK_INDEX(08, 01) = 1, BYTE = 0
> IRQ05: idx = 01 REG_RANK_NR(08, 01) = 0, REG_RANK_INDEX(08, 01) = 1, BYTE = 1
> [...]
> IRQ30: idx = 07 REG_RANK_NR(08, 07) = 0, REG_RANK_INDEX(08, 07) = 7, BYTE = 2
> IRQ31: idx = 07 REG_RANK_NR(08, 07) = 0, REG_RANK_INDEX(08, 07) = 7, BYTE = 3
> IRQ32: idx = 08 REG_RANK_NR(08, 08) = 1, REG_RANK_INDEX(08, 08) = 0, BYTE = 0
> IRQ33: idx = 08 REG_RANK_NR(08, 08) = 1, REG_RANK_INDEX(08, 08) = 0, BYTE = 1
> [...]
> IRQ62: idx = 15 REG_RANK_NR(08, 15) = 1, REG_RANK_INDEX(08, 15) = 7, BYTE = 2
> IRQ63: idx = 15 REG_RANK_NR(08, 15) = 1, REG_RANK_INDEX(08, 15) = 7, BYTE = 3
> IRQ64: idx = 16 REG_RANK_NR(08, 16) = 2, REG_RANK_INDEX(08, 16) = 0, BYTE = 0
> IRQ65: idx = 16 REG_RANK_NR(08, 16) = 2, REG_RANK_INDEX(08, 16) = 0, BYTE = 1
> [...]
> 
> IOW interrupts 0..31 are in rank 0, 32..63 are rank 1 etc, which is correct
> 
> With idx = irq / 32 you instead get:
> 
> IRQ00: idx = 00 REG_RANK_NR(08, 00) = 0, REG_RANK_INDEX(08, 00) = 0, BYTE = 0
> IRQ01: idx = 00 REG_RANK_NR(08, 00) = 0, REG_RANK_INDEX(08, 00) = 0, BYTE = 1
> IRQ02: idx = 00 REG_RANK_NR(08, 00) = 0, REG_RANK_INDEX(08, 00) = 0, BYTE = 2
> IRQ03: idx = 00 REG_RANK_NR(08, 00) = 0, REG_RANK_INDEX(08, 00) = 0, BYTE = 3
> IRQ04: idx = 00 REG_RANK_NR(08, 00) = 0, REG_RANK_INDEX(08, 00) = 0, BYTE = 0
> IRQ05: idx = 00 REG_RANK_NR(08, 00) = 0, REG_RANK_INDEX(08, 00) = 0, BYTE = 1
> [...]
> IRQ30: idx = 00 REG_RANK_NR(08, 00) = 0, REG_RANK_INDEX(08, 00) = 0, BYTE = 2
> IRQ31: idx = 00 REG_RANK_NR(08, 00) = 0, REG_RANK_INDEX(08, 00) = 0, BYTE = 3
> IRQ32: idx = 01 REG_RANK_NR(08, 01) = 0, REG_RANK_INDEX(08, 01) = 1, BYTE = 0
> IRQ33: idx = 01 REG_RANK_NR(08, 01) = 0, REG_RANK_INDEX(08, 01) = 1, BYTE = 1
> [...]
> IRQ62: idx = 01 REG_RANK_NR(08, 01) = 0, REG_RANK_INDEX(08, 01) = 1, BYTE = 2
> IRQ63: idx = 01 REG_RANK_NR(08, 01) = 0, REG_RANK_INDEX(08, 01) = 1, BYTE = 3
> IRQ64: idx = 02 REG_RANK_NR(08, 02) = 0, REG_RANK_INDEX(08, 02) = 2, BYTE = 0
> IRQ65: idx = 02 REG_RANK_NR(08, 02) = 0, REG_RANK_INDEX(08, 02) = 2, BYTE = 1
> [...]
> IRQ255: idx = 07 REG_RANK_NR(08, 07) = 0, REG_RANK_INDEX(08, 07) = 7, BYTE = 3
> IRQ256: idx = 08 REG_RANK_NR(08, 08) = 1, REG_RANK_INDEX(08, 08) = 0, BYTE = 0
> 
> Here allinterrupts up to 255 are in rank 0, which is wrong.
> 
> For idx = irq / 32 you would need to use REG_RANK_NR(1, idx) not (8,
> idx). (and you'd need to trivially fix REG_RANK_NR to handle b == 1).
> 
> Perhaps the way to think of it is not as "/ 32" but rather as ">> 5". 
> Since REG_RANK_NR(8, ) is effectively >> 3 when combined with the
> existing >> 2 we get >> 5 overall.
> 
> If you change it as you have done then you are doing >> 5 *and* >> 3,
> i.e. >> 8 aka "/ 256" -- which explains why interrupts up to 255 end up
> in rank 0 with your change.

Your explanation is sounds, but the fact remains that the code doesn't
work as is :)
It means that this patch hides the bug rather than fixing it...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 16:40:48 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 16:40:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRmxQ-0005CU-Oq; Fri, 26 Oct 2012 16:40:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRmxP-0005CN-9u
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 16:40:27 +0000
Received: from [193.109.254.147:51305] by server-14.bemta-14.messagelabs.com
	id 82/FA-14517-9FCBA805; Fri, 26 Oct 2012 16:40:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1351269624!6157449!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15283 invoked from network); 26 Oct 2012 16:40:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 16:40:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15416832"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 16:40:24 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 17:40:24 +0100
Message-ID: <1351269622.15162.105.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Fri, 26 Oct 2012 17:40:22 +0100
In-Reply-To: 
References: 
	<1351091027-20740-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1351157246.18035.129.camel@zakaz.uk.xensource.com>
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" , "Tim
	\(Xen.org\)" 
Subject: Re: [Xen-devel] [PATCH 1/7] xen/arm: fix rank calculation in
 vgic_vcpu_inject_irq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-26 at 17:33 +0100, Stefano Stabellini wrote:

> Your explanation is sounds, but the fact remains that the code doesn't
> work as is :)

;-)

> It means that this patch hides the bug rather than fixing it...

What are the symptoms?

BTW I noticed that "byte = irq & 0x3;" is redundant since byte_read also
has the & in it. But that won't cause problems.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 16:40:48 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 16:40:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRmxQ-0005CU-Oq; Fri, 26 Oct 2012 16:40:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRmxP-0005CN-9u
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 16:40:27 +0000
Received: from [193.109.254.147:51305] by server-14.bemta-14.messagelabs.com
	id 82/FA-14517-9FCBA805; Fri, 26 Oct 2012 16:40:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1351269624!6157449!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15283 invoked from network); 26 Oct 2012 16:40:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 16:40:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15416832"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 16:40:24 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 17:40:24 +0100
Message-ID: <1351269622.15162.105.camel@zakaz.uk.xensource.com>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Fri, 26 Oct 2012 17:40:22 +0100
In-Reply-To: 
References: 
	<1351091027-20740-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1351157246.18035.129.camel@zakaz.uk.xensource.com>
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" , "Tim
	\(Xen.org\)" 
Subject: Re: [Xen-devel] [PATCH 1/7] xen/arm: fix rank calculation in
 vgic_vcpu_inject_irq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-26 at 17:33 +0100, Stefano Stabellini wrote:

> Your explanation is sounds, but the fact remains that the code doesn't
> work as is :)

;-)

> It means that this patch hides the bug rather than fixing it...

What are the symptoms?

BTW I noticed that "byte = irq & 0x3;" is redundant since byte_read also
has the & in it. But that won't cause problems.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 16:46:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 16:46:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRn2s-0005OY-Ik; Fri, 26 Oct 2012 16:46:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TRn2o-0005OP-Fb
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 16:46:04 +0000
Received: from [85.158.138.51:12668] by server-4.bemta-3.messagelabs.com id
	75/2F-01405-94EBA805; Fri, 26 Oct 2012 16:46:01 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-174.messagelabs.com!1351269960!27552100!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1658 invoked from network); 26 Oct 2012 16:46:01 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Oct 2012 16:46:01 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TRn2m-000L0u-0u; Fri, 26 Oct 2012 16:46:00 +0000
Date: Fri, 26 Oct 2012 17:45:59 +0100
From: Tim Deegan 
To: Stefano Stabellini 
Message-ID: <20121026164559.GE76080@ocelot.phlegethon.org>
References: 
	<1351091027-20740-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20121024155945.GD39126@ocelot.phlegethon.org>
	
	<20121026090141.GB76080@ocelot.phlegethon.org>
	
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" ,
	Ian Campbell 
Subject: Re: [Xen-devel] [PATCH 6/7] xen/arm: flush D-cache and I-cache when
	appropriate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 16:53 +0100 on 26 Oct (1351270394), Stefano Stabellini wrote:
> On Fri, 26 Oct 2012, Tim Deegan wrote:
> > At 18:35 +0100 on 24 Oct (1351103740), Stefano Stabellini wrote:
> > > > I don't think this is necessary - why not just pass va directly to the
> > > > inline asm?  We don't care what register it's in (and if we did I'm not
> > > > convinced this would guarantee it was r0).
> > > > 
> > > > > +    asm volatile (
> > > > > +        "dsb;"
> > > > > +        STORE_CP32(0, DCCMVAC)
> > > > > +        "isb;"
> > > > > +        : : "r" (r0) : "memory");
> > > > 
> > > > Does this need a 'memory' clobber?  Can we get away with just saying it
> > > > consumes *va as an input?  All we need to be sure of is that the
> > > > particular thing we're flushing has been written out; no need to stop
> > > > any other optimizations.
> > > 
> > > you are right on both points
> > > 
> > > > I guess it might need to be re-cast as a macro so the compiler knows how
> > > > big *va is?
> > > 
> > > I don't think it is necessary, after all the size of a register has to
> > > be the same of a virtual address
> > 
> > But it's the size of the thing in memory that's being flushed that
> > matters, not the size of the pointer to it!
> >
> > E.g. after a PTE write we
> > need a 64-bit memory input operand to stop the compiler from hoisting
> > any part of the PTE write past the cache flush. (well OK we explicitly use
> > a 64-bit atomic write for PTE writes, but YKWIM).
> 
> The implementation of write_pte is entirely in assembly so I doubt that
> the compiler is going to reorder it.

Augh!  Yes, like I said, PTE writes are fine.

> However I see your point in case of flush_xen_dcache_va.
> Wouldn't a barrier() at the beginning of the function be enough?

More than enough.  That would be exactly equivalent to the "memory"
clobber above.  What I'm arguing for is a _less_ restrictive constraint,
that only restricts delaying writes, and only affects the thing actually
being flushed (whatever size that is).

For larger regions we should have a function with a single barrier at
the top and then a loop of DCCMVAC writes.  For single objects smaller
than a cacheline we need to pass the object itself as a memory input
operand.  Probably we should also have a compile-time check that the
object is smaller than the smallest supported cache-line (i.e. one
DCCMVAC is enough).

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 16:46:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 16:46:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRn2s-0005OY-Ik; Fri, 26 Oct 2012 16:46:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TRn2o-0005OP-Fb
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 16:46:04 +0000
Received: from [85.158.138.51:12668] by server-4.bemta-3.messagelabs.com id
	75/2F-01405-94EBA805; Fri, 26 Oct 2012 16:46:01 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-174.messagelabs.com!1351269960!27552100!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1658 invoked from network); 26 Oct 2012 16:46:01 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Oct 2012 16:46:01 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TRn2m-000L0u-0u; Fri, 26 Oct 2012 16:46:00 +0000
Date: Fri, 26 Oct 2012 17:45:59 +0100
From: Tim Deegan 
To: Stefano Stabellini 
Message-ID: <20121026164559.GE76080@ocelot.phlegethon.org>
References: 
	<1351091027-20740-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20121024155945.GD39126@ocelot.phlegethon.org>
	
	<20121026090141.GB76080@ocelot.phlegethon.org>
	
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" ,
	Ian Campbell 
Subject: Re: [Xen-devel] [PATCH 6/7] xen/arm: flush D-cache and I-cache when
	appropriate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 16:53 +0100 on 26 Oct (1351270394), Stefano Stabellini wrote:
> On Fri, 26 Oct 2012, Tim Deegan wrote:
> > At 18:35 +0100 on 24 Oct (1351103740), Stefano Stabellini wrote:
> > > > I don't think this is necessary - why not just pass va directly to the
> > > > inline asm?  We don't care what register it's in (and if we did I'm not
> > > > convinced this would guarantee it was r0).
> > > > 
> > > > > +    asm volatile (
> > > > > +        "dsb;"
> > > > > +        STORE_CP32(0, DCCMVAC)
> > > > > +        "isb;"
> > > > > +        : : "r" (r0) : "memory");
> > > > 
> > > > Does this need a 'memory' clobber?  Can we get away with just saying it
> > > > consumes *va as an input?  All we need to be sure of is that the
> > > > particular thing we're flushing has been written out; no need to stop
> > > > any other optimizations.
> > > 
> > > you are right on both points
> > > 
> > > > I guess it might need to be re-cast as a macro so the compiler knows how
> > > > big *va is?
> > > 
> > > I don't think it is necessary, after all the size of a register has to
> > > be the same of a virtual address
> > 
> > But it's the size of the thing in memory that's being flushed that
> > matters, not the size of the pointer to it!
> >
> > E.g. after a PTE write we
> > need a 64-bit memory input operand to stop the compiler from hoisting
> > any part of the PTE write past the cache flush. (well OK we explicitly use
> > a 64-bit atomic write for PTE writes, but YKWIM).
> 
> The implementation of write_pte is entirely in assembly so I doubt that
> the compiler is going to reorder it.

Augh!  Yes, like I said, PTE writes are fine.

> However I see your point in case of flush_xen_dcache_va.
> Wouldn't a barrier() at the beginning of the function be enough?

More than enough.  That would be exactly equivalent to the "memory"
clobber above.  What I'm arguing for is a _less_ restrictive constraint,
that only restricts delaying writes, and only affects the thing actually
being flushed (whatever size that is).

For larger regions we should have a function with a single barrier at
the top and then a loop of DCCMVAC writes.  For single objects smaller
than a cacheline we need to pass the object itself as a memory input
operand.  Probably we should also have a compile-time check that the
object is smaller than the smallest supported cache-line (i.e. one
DCCMVAC is enough).

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 16:56:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 16:56:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRnCL-0005cE-Ku; Fri, 26 Oct 2012 16:55:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TRnCK-0005c9-RQ
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 16:55:53 +0000
Received: from [85.158.139.83:50198] by server-3.bemta-5.messagelabs.com id
	B2/9C-28618-890CA805; Fri, 26 Oct 2012 16:55:52 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-182.messagelabs.com!1351270550!23226557!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29073 invoked from network); 26 Oct 2012 16:55:50 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Oct 2012 16:55:50 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TRnCH-000L3d-TD; Fri, 26 Oct 2012 16:55:49 +0000
Date: Fri, 26 Oct 2012 17:55:49 +0100
From: Tim Deegan 
To: Stefano Stabellini 
Message-ID: <20121026165549.GF76080@ocelot.phlegethon.org>
References: 
	<1351091027-20740-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20121024155945.GD39126@ocelot.phlegethon.org>
	
	<20121026090141.GB76080@ocelot.phlegethon.org>
	
	
	
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" ,
	Ian Campbell 
Subject: Re: [Xen-devel] [PATCH 6/7] xen/arm: flush D-cache and I-cache when
	appropriate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 17:03 +0100 on 26 Oct (1351271018), Stefano Stabellini wrote:
> On Fri, 26 Oct 2012, Stefano Stabellini wrote:
> > On Fri, 26 Oct 2012, Stefano Stabellini wrote:
> > > On Fri, 26 Oct 2012, Tim Deegan wrote:
> > > > At 18:35 +0100 on 24 Oct (1351103740), Stefano Stabellini wrote:
> > > > > > I don't think this is necessary - why not just pass va directly to the
> > > > > > inline asm?  We don't care what register it's in (and if we did I'm not
> > > > > > convinced this would guarantee it was r0).
> > > > > > 
> > > > > > > +    asm volatile (
> > > > > > > +        "dsb;"
> > > > > > > +        STORE_CP32(0, DCCMVAC)
> > > > > > > +        "isb;"
> > > > > > > +        : : "r" (r0) : "memory");
> > > > > > 
> > > > > > Does this need a 'memory' clobber?  Can we get away with just saying it
> > > > > > consumes *va as an input?  All we need to be sure of is that the
> > > > > > particular thing we're flushing has been written out; no need to stop
> > > > > > any other optimizations.
> > > > > 
> > > > > you are right on both points
> > > > > 
> > > > > > I guess it might need to be re-cast as a macro so the compiler knows how
> > > > > > big *va is?
> > > > > 
> > > > > I don't think it is necessary, after all the size of a register has to
> > > > > be the same of a virtual address
> > > > 
> > > > But it's the size of the thing in memory that's being flushed that
> > > > matters, not the size of the pointer to it!
> > > >
> > > > E.g. after a PTE write we
> > > > need a 64-bit memory input operand to stop the compiler from hoisting
> > > > any part of the PTE write past the cache flush. (well OK we explicitly use
> > > > a 64-bit atomic write for PTE writes, but YKWIM).
> > > 
> > > The implementation of write_pte is entirely in assembly so I doubt that
> > > the compiler is going to reorder it.
> > > 
> > > However I see your point in case of flush_xen_dcache_va.
> > > Wouldn't a barrier() at the beginning of the function be enough?
> > >
> > 
> > Actually we already have a memory clobber in flush_xen_dcache_va,
> > shouldn't that prevent the compiler from reordering instructions?
> > 
> 
> After reading again the entire thread I think that I understand what you
> meant: can't we get rid of the memory clobber and specify *va as input?
> 
> However in order to do that correctly we need to make clear how big *va is
> otherwise the compiler could reorder things.

Yes!

> The problem is that we don't know at compile time how big a cacheline
> is, so I think that we need to keep the memory clobber.

No!  It's always safe to flush the entire line -- regardless of what
other writes might be happening to it.  After all, the cache controller
might evict that line on its own at any time, so nothing can be relying
on its _not_ being flushed.

The only problem with not knowing how big a cacheline is is this: if the
object is _bigger_ than a cache line we might use one DCCMVAC where more
than one is needed.  We can avoid that by a compile-time check on some
sort of architectural minimum cacheline size.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 16:56:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 16:56:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRnCL-0005cE-Ku; Fri, 26 Oct 2012 16:55:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TRnCK-0005c9-RQ
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 16:55:53 +0000
Received: from [85.158.139.83:50198] by server-3.bemta-5.messagelabs.com id
	B2/9C-28618-890CA805; Fri, 26 Oct 2012 16:55:52 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-182.messagelabs.com!1351270550!23226557!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29073 invoked from network); 26 Oct 2012 16:55:50 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Oct 2012 16:55:50 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TRnCH-000L3d-TD; Fri, 26 Oct 2012 16:55:49 +0000
Date: Fri, 26 Oct 2012 17:55:49 +0100
From: Tim Deegan 
To: Stefano Stabellini 
Message-ID: <20121026165549.GF76080@ocelot.phlegethon.org>
References: 
	<1351091027-20740-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20121024155945.GD39126@ocelot.phlegethon.org>
	
	<20121026090141.GB76080@ocelot.phlegethon.org>
	
	
	
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" ,
	Ian Campbell 
Subject: Re: [Xen-devel] [PATCH 6/7] xen/arm: flush D-cache and I-cache when
	appropriate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 17:03 +0100 on 26 Oct (1351271018), Stefano Stabellini wrote:
> On Fri, 26 Oct 2012, Stefano Stabellini wrote:
> > On Fri, 26 Oct 2012, Stefano Stabellini wrote:
> > > On Fri, 26 Oct 2012, Tim Deegan wrote:
> > > > At 18:35 +0100 on 24 Oct (1351103740), Stefano Stabellini wrote:
> > > > > > I don't think this is necessary - why not just pass va directly to the
> > > > > > inline asm?  We don't care what register it's in (and if we did I'm not
> > > > > > convinced this would guarantee it was r0).
> > > > > > 
> > > > > > > +    asm volatile (
> > > > > > > +        "dsb;"
> > > > > > > +        STORE_CP32(0, DCCMVAC)
> > > > > > > +        "isb;"
> > > > > > > +        : : "r" (r0) : "memory");
> > > > > > 
> > > > > > Does this need a 'memory' clobber?  Can we get away with just saying it
> > > > > > consumes *va as an input?  All we need to be sure of is that the
> > > > > > particular thing we're flushing has been written out; no need to stop
> > > > > > any other optimizations.
> > > > > 
> > > > > you are right on both points
> > > > > 
> > > > > > I guess it might need to be re-cast as a macro so the compiler knows how
> > > > > > big *va is?
> > > > > 
> > > > > I don't think it is necessary, after all the size of a register has to
> > > > > be the same of a virtual address
> > > > 
> > > > But it's the size of the thing in memory that's being flushed that
> > > > matters, not the size of the pointer to it!
> > > >
> > > > E.g. after a PTE write we
> > > > need a 64-bit memory input operand to stop the compiler from hoisting
> > > > any part of the PTE write past the cache flush. (well OK we explicitly use
> > > > a 64-bit atomic write for PTE writes, but YKWIM).
> > > 
> > > The implementation of write_pte is entirely in assembly so I doubt that
> > > the compiler is going to reorder it.
> > > 
> > > However I see your point in case of flush_xen_dcache_va.
> > > Wouldn't a barrier() at the beginning of the function be enough?
> > >
> > 
> > Actually we already have a memory clobber in flush_xen_dcache_va,
> > shouldn't that prevent the compiler from reordering instructions?
> > 
> 
> After reading again the entire thread I think that I understand what you
> meant: can't we get rid of the memory clobber and specify *va as input?
> 
> However in order to do that correctly we need to make clear how big *va is
> otherwise the compiler could reorder things.

Yes!

> The problem is that we don't know at compile time how big a cacheline
> is, so I think that we need to keep the memory clobber.

No!  It's always safe to flush the entire line -- regardless of what
other writes might be happening to it.  After all, the cache controller
might evict that line on its own at any time, so nothing can be relying
on its _not_ being flushed.

The only problem with not knowing how big a cacheline is is this: if the
object is _bigger_ than a cache line we might use one DCCMVAC where more
than one is needed.  We can avoid that by a compile-time check on some
sort of architectural minimum cacheline size.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 17:31:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 17:31:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRnkP-0006ML-CD; Fri, 26 Oct 2012 17:31:05 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRnkN-0006MG-1X
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 17:31:03 +0000
Received: from [193.109.254.147:47430] by server-6.bemta-14.messagelabs.com id
	01/4C-17826-6D8CA805; Fri, 26 Oct 2012 17:31:02 +0000
X-Env-Sender: roger.cruz@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1351272658!3433180!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzkyODY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19449 invoked from network); 26 Oct 2012 17:30:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 17:30:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="42573351"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 17:30:46 +0000
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.210]) by
	FTLPMAILMX01.citrite.net ([10.13.107.65]) with mapi; Fri, 26 Oct 2012
	13:30:45 -0400
From: Roger Cruz 
To: "xen-devel@lists.xen.org" 
Date: Fri, 26 Oct 2012 13:30:45 -0400
Thread-Topic: Tracking down a boot speed issue
Thread-Index: AQHNs5+hUdvduh6F60mmJEja8l+oag==
Message-ID: <844D15D284C78547BB0DAEE12D33A1B67C212BB958@FTLPMAILBOX02.citrite.net>
References: <844D15D284C78547BB0DAEE12D33A1B67C212BB956@FTLPMAILBOX02.citrite.net>
In-Reply-To: <844D15D284C78547BB0DAEE12D33A1B67C212BB956@FTLPMAILBOX02.citrite.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: [Xen-devel] Tracking down a boot speed issue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


With a Linux 3.2.23 PVOPs and Xen 4.0.4, I am observing that boot speed takes a hit when the following per_cpu access is made  in arch/x86/xen/enlighthen.c:xen_vcpu_setup().  The slow down is caused by the term on the left of the equal sign, ie, access to the per cpu area.  As you see from the timed samples below, the access can take anywhere from .6 to 1.2 secs (though I have seen it take 1.6 secs every single time with  Linux 3.2.16 and Xen 4.0.3).  Subsequent iterations from the loop do not incur the expense.  It also doesn't happen on older CPUs from what I can tell, only in the newer Sandybridge Intel i-series processors.  My initial guess is that there is some sort of page fault taking place but I haven't been able to confirm that.  Any ideas on how to track this farther down into Xen to isolate and understand what is going on?

Thank you.  
Roger R. Cruz

            printk(KERN_ALERT "in cpu loop %d for shared info", cpu);
===>    per_cpu(xen_vcpu,cpu) = &HYPERVISOR_shared_info->vcpu_info[cpu];
            printk(KERN_ALERT "in cpu loop %d computed shared info", cpu);

Oct 25 20:24:11 23445LU-PBBFMWY kernel: [    0.000000] in cpu loop 0 for shared info
Oct 25 20:24:11 23445LU-PBBFMWY kernel: [    1.238877] in cpu loop 0 computed shared info

Oct 25 20:52:53 23445LU-PBBFMWY kernel: [    0.000000] in cpu loop 0 for shared info
Oct 25 20:52:53 23445LU-PBBFMWY kernel: [    0.718365] in cpu loop 0 computed shared info

Oct 25 20:41:27 23445LU-PBBFMWY kernel: [    0.000000] in cpu loop 0 for shared info
Oct 25 20:41:27 23445LU-PBBFMWY kernel: [    0.671690] in cpu loop 0 computed shared info



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 17:31:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 17:31:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRnkP-0006ML-CD; Fri, 26 Oct 2012 17:31:05 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRnkN-0006MG-1X
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 17:31:03 +0000
Received: from [193.109.254.147:47430] by server-6.bemta-14.messagelabs.com id
	01/4C-17826-6D8CA805; Fri, 26 Oct 2012 17:31:02 +0000
X-Env-Sender: roger.cruz@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1351272658!3433180!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzkyODY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19449 invoked from network); 26 Oct 2012 17:30:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 17:30:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="42573351"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 17:30:46 +0000
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.210]) by
	FTLPMAILMX01.citrite.net ([10.13.107.65]) with mapi; Fri, 26 Oct 2012
	13:30:45 -0400
From: Roger Cruz 
To: "xen-devel@lists.xen.org" 
Date: Fri, 26 Oct 2012 13:30:45 -0400
Thread-Topic: Tracking down a boot speed issue
Thread-Index: AQHNs5+hUdvduh6F60mmJEja8l+oag==
Message-ID: <844D15D284C78547BB0DAEE12D33A1B67C212BB958@FTLPMAILBOX02.citrite.net>
References: <844D15D284C78547BB0DAEE12D33A1B67C212BB956@FTLPMAILBOX02.citrite.net>
In-Reply-To: <844D15D284C78547BB0DAEE12D33A1B67C212BB956@FTLPMAILBOX02.citrite.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: [Xen-devel] Tracking down a boot speed issue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


With a Linux 3.2.23 PVOPs and Xen 4.0.4, I am observing that boot speed takes a hit when the following per_cpu access is made  in arch/x86/xen/enlighthen.c:xen_vcpu_setup().  The slow down is caused by the term on the left of the equal sign, ie, access to the per cpu area.  As you see from the timed samples below, the access can take anywhere from .6 to 1.2 secs (though I have seen it take 1.6 secs every single time with  Linux 3.2.16 and Xen 4.0.3).  Subsequent iterations from the loop do not incur the expense.  It also doesn't happen on older CPUs from what I can tell, only in the newer Sandybridge Intel i-series processors.  My initial guess is that there is some sort of page fault taking place but I haven't been able to confirm that.  Any ideas on how to track this farther down into Xen to isolate and understand what is going on?

Thank you.  
Roger R. Cruz

            printk(KERN_ALERT "in cpu loop %d for shared info", cpu);
===>    per_cpu(xen_vcpu,cpu) = &HYPERVISOR_shared_info->vcpu_info[cpu];
            printk(KERN_ALERT "in cpu loop %d computed shared info", cpu);

Oct 25 20:24:11 23445LU-PBBFMWY kernel: [    0.000000] in cpu loop 0 for shared info
Oct 25 20:24:11 23445LU-PBBFMWY kernel: [    1.238877] in cpu loop 0 computed shared info

Oct 25 20:52:53 23445LU-PBBFMWY kernel: [    0.000000] in cpu loop 0 for shared info
Oct 25 20:52:53 23445LU-PBBFMWY kernel: [    0.718365] in cpu loop 0 computed shared info

Oct 25 20:41:27 23445LU-PBBFMWY kernel: [    0.000000] in cpu loop 0 for shared info
Oct 25 20:41:27 23445LU-PBBFMWY kernel: [    0.671690] in cpu loop 0 computed shared info



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 18:26:21 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 18:26:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRobT-0007Dp-Gs; Fri, 26 Oct 2012 18:25:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRobR-0007Dk-HC
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 18:25:53 +0000
Received: from [85.158.137.99:5380] by server-5.bemta-3.messagelabs.com id
	81/3C-12440-0B5DA805; Fri, 26 Oct 2012 18:25:52 +0000
X-Env-Sender: mrsanna1@gmail.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1351275950!18412657!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=1.7 required=7.0 tests=INFO_TLD,
	ML_RADAR_SPEW_LINKS_14, ML_RADAR_SPEW_LINKS_22, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12927 invoked from network); 26 Oct 2012 18:25:51 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 18:25:51 -0000
Received: by mail-ob0-f173.google.com with SMTP id wc18so3706910obb.32
	for ; Fri, 26 Oct 2012 11:25:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=kdmRgQNPo8p2qIw7wbJ3+O6/pINch4vKFmun0Hc68O4=;
	b=ujjYLRsG46xRTf6npORMbm6Y1NvqO67+dXF2OPdAdqemNMKZNTjBU4ejNXT6CQmlLN
	J949L+WJ9NYF8vUez+XVkMNeEse4CitqNlF6yIc3BXmPcUSnOaXh2Pn5JyuwQ1XFbpZT
	/mKa39O+4vH5AhtkkzkyPF6F6oBAIEW1qgWSTxjUY0Y2QvoIDfZ796TR5lto5dcEVpbc
	tTM03O2LZnltJPjtMA1Cquu4jrCz8dG6FVH+expYLpS+FXgg8McFxItUiaPHpSlAQ6fW
	v9v4tx/xdeDMEfGJ6Hy17MeXtxcFD0eGYtkuqTrv7TIXLJFKIZjQtFPNkpzxS19GjVcZ
	ImJw==
MIME-Version: 1.0
Received: by 10.60.4.227 with SMTP id n3mr19769323oen.136.1351275949684; Fri,
	26 Oct 2012 11:25:49 -0700 (PDT)
Received: by 10.76.87.161 with HTTP; Fri, 26 Oct 2012 11:25:49 -0700 (PDT)
In-Reply-To: <1351256392.15162.76.camel@zakaz.uk.xensource.com>
References: <1351256392.15162.76.camel@zakaz.uk.xensource.com>
Date: Fri, 26 Oct 2012 20:25:49 +0200
Message-ID: 
From: Mauro 
To: Ian Campbell 
Cc: 599161@bugs.debian.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] #599161: Xen debug patch for the "clock shifts by
	50 minutes" bug.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 26 October 2012 14:59, Ian Campbell  wrote:
> Hi all,
>
> I've BCC'd a number of people who have reported seeing this bug at
> various times in the past.
>
> If you can still repro I'd appreciate it if you could give the patch in
> http://marc.info/?l=xen-devel&m=135049062216685&w=2 (also attached) a go
> and report back success/failure and the output of the debugging messages
> produced.

Is that patch for amd64 architectures?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 18:26:21 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 18:26:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRobT-0007Dp-Gs; Fri, 26 Oct 2012 18:25:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRobR-0007Dk-HC
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 18:25:53 +0000
Received: from [85.158.137.99:5380] by server-5.bemta-3.messagelabs.com id
	81/3C-12440-0B5DA805; Fri, 26 Oct 2012 18:25:52 +0000
X-Env-Sender: mrsanna1@gmail.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1351275950!18412657!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=1.7 required=7.0 tests=INFO_TLD,
	ML_RADAR_SPEW_LINKS_14, ML_RADAR_SPEW_LINKS_22, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12927 invoked from network); 26 Oct 2012 18:25:51 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 18:25:51 -0000
Received: by mail-ob0-f173.google.com with SMTP id wc18so3706910obb.32
	for ; Fri, 26 Oct 2012 11:25:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=kdmRgQNPo8p2qIw7wbJ3+O6/pINch4vKFmun0Hc68O4=;
	b=ujjYLRsG46xRTf6npORMbm6Y1NvqO67+dXF2OPdAdqemNMKZNTjBU4ejNXT6CQmlLN
	J949L+WJ9NYF8vUez+XVkMNeEse4CitqNlF6yIc3BXmPcUSnOaXh2Pn5JyuwQ1XFbpZT
	/mKa39O+4vH5AhtkkzkyPF6F6oBAIEW1qgWSTxjUY0Y2QvoIDfZ796TR5lto5dcEVpbc
	tTM03O2LZnltJPjtMA1Cquu4jrCz8dG6FVH+expYLpS+FXgg8McFxItUiaPHpSlAQ6fW
	v9v4tx/xdeDMEfGJ6Hy17MeXtxcFD0eGYtkuqTrv7TIXLJFKIZjQtFPNkpzxS19GjVcZ
	ImJw==
MIME-Version: 1.0
Received: by 10.60.4.227 with SMTP id n3mr19769323oen.136.1351275949684; Fri,
	26 Oct 2012 11:25:49 -0700 (PDT)
Received: by 10.76.87.161 with HTTP; Fri, 26 Oct 2012 11:25:49 -0700 (PDT)
In-Reply-To: <1351256392.15162.76.camel@zakaz.uk.xensource.com>
References: <1351256392.15162.76.camel@zakaz.uk.xensource.com>
Date: Fri, 26 Oct 2012 20:25:49 +0200
Message-ID: 
From: Mauro 
To: Ian Campbell 
Cc: 599161@bugs.debian.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] #599161: Xen debug patch for the "clock shifts by
	50 minutes" bug.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 26 October 2012 14:59, Ian Campbell  wrote:
> Hi all,
>
> I've BCC'd a number of people who have reported seeing this bug at
> various times in the past.
>
> If you can still repro I'd appreciate it if you could give the patch in
> http://marc.info/?l=xen-devel&m=135049062216685&w=2 (also attached) a go
> and report back success/failure and the output of the debugging messages
> produced.

Is that patch for amd64 architectures?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 18:39:06 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 18:39:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRonq-00084P-DS; Fri, 26 Oct 2012 18:38:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRonp-00084J-21
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 18:38:41 +0000
Received: from [85.158.143.99:32058] by server-1.bemta-4.messagelabs.com id
	29/C5-19134-0B8DA805; Fri, 26 Oct 2012 18:38:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1351276719!22289005!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2867 invoked from network); 26 Oct 2012 18:38:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 18:38:39 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15419014"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 18:38:38 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 19:38:38 +0100
Message-ID: <1351276718.12176.1.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Roger Cruz 
Date: Fri, 26 Oct 2012 19:38:38 +0100
In-Reply-To: <844D15D284C78547BB0DAEE12D33A1B67C212BB958@FTLPMAILBOX02.citrite.net>
References: <844D15D284C78547BB0DAEE12D33A1B67C212BB956@FTLPMAILBOX02.citrite.net>
	<844D15D284C78547BB0DAEE12D33A1B67C212BB958@FTLPMAILBOX02.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Tracking down a boot speed issue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-26 at 18:30 +0100, Roger Cruz wrote:
> As you see from the timed samples below, the access can take anywhere
> from .6 to 1.2 secs (though I have seen it take 1.6 secs every single
> time with  Linux 3.2.16 and Xen 4.0.3).

Isn't this just because setting up the per-cpu shared info makes the
time available to printk. Note that the timestamp is zero beforehand
(a big hint that time isn't setup yet). Also see xen_clocksource_read().

IOW I think what is being measured here is the time from start of day
until the second printk, not the time between the two prints.

[...]
>             printk(KERN_ALERT "in cpu loop %d for shared info", cpu);
> ===>    per_cpu(xen_vcpu,cpu) = &HYPERVISOR_shared_info->vcpu_info[cpu];
>             printk(KERN_ALERT "in cpu loop %d computed shared info", cpu);
> 
> Oct 25 20:24:11 23445LU-PBBFMWY kernel: [    0.000000] in cpu loop 0 for shared info
> Oct 25 20:24:11 23445LU-PBBFMWY kernel: [    1.238877] in cpu loop 0 computed shared info
> 
> Oct 25 20:52:53 23445LU-PBBFMWY kernel: [    0.000000] in cpu loop 0 for shared info
> Oct 25 20:52:53 23445LU-PBBFMWY kernel: [    0.718365] in cpu loop 0 computed shared info
> 
> Oct 25 20:41:27 23445LU-PBBFMWY kernel: [    0.000000] in cpu loop 0 for shared info
> Oct 25 20:41:27 23445LU-PBBFMWY kernel: [    0.671690] in cpu loop 0 computed shared info
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 18:39:06 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 18:39:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRonq-00084P-DS; Fri, 26 Oct 2012 18:38:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRonp-00084J-21
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 18:38:41 +0000
Received: from [85.158.143.99:32058] by server-1.bemta-4.messagelabs.com id
	29/C5-19134-0B8DA805; Fri, 26 Oct 2012 18:38:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1351276719!22289005!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2867 invoked from network); 26 Oct 2012 18:38:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 18:38:39 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15419014"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 18:38:38 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 19:38:38 +0100
Message-ID: <1351276718.12176.1.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Roger Cruz 
Date: Fri, 26 Oct 2012 19:38:38 +0100
In-Reply-To: <844D15D284C78547BB0DAEE12D33A1B67C212BB958@FTLPMAILBOX02.citrite.net>
References: <844D15D284C78547BB0DAEE12D33A1B67C212BB956@FTLPMAILBOX02.citrite.net>
	<844D15D284C78547BB0DAEE12D33A1B67C212BB958@FTLPMAILBOX02.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Tracking down a boot speed issue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-26 at 18:30 +0100, Roger Cruz wrote:
> As you see from the timed samples below, the access can take anywhere
> from .6 to 1.2 secs (though I have seen it take 1.6 secs every single
> time with  Linux 3.2.16 and Xen 4.0.3).

Isn't this just because setting up the per-cpu shared info makes the
time available to printk. Note that the timestamp is zero beforehand
(a big hint that time isn't setup yet). Also see xen_clocksource_read().

IOW I think what is being measured here is the time from start of day
until the second printk, not the time between the two prints.

[...]
>             printk(KERN_ALERT "in cpu loop %d for shared info", cpu);
> ===>    per_cpu(xen_vcpu,cpu) = &HYPERVISOR_shared_info->vcpu_info[cpu];
>             printk(KERN_ALERT "in cpu loop %d computed shared info", cpu);
> 
> Oct 25 20:24:11 23445LU-PBBFMWY kernel: [    0.000000] in cpu loop 0 for shared info
> Oct 25 20:24:11 23445LU-PBBFMWY kernel: [    1.238877] in cpu loop 0 computed shared info
> 
> Oct 25 20:52:53 23445LU-PBBFMWY kernel: [    0.000000] in cpu loop 0 for shared info
> Oct 25 20:52:53 23445LU-PBBFMWY kernel: [    0.718365] in cpu loop 0 computed shared info
> 
> Oct 25 20:41:27 23445LU-PBBFMWY kernel: [    0.000000] in cpu loop 0 for shared info
> Oct 25 20:41:27 23445LU-PBBFMWY kernel: [    0.671690] in cpu loop 0 computed shared info
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 18:40:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 18:40:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRopI-0008Bu-UJ; Fri, 26 Oct 2012 18:40:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRopH-0008Bj-Lj
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 18:40:11 +0000
Received: from [85.158.143.99:7048] by server-1.bemta-4.messagelabs.com id
	17/66-19134-B09DA805; Fri, 26 Oct 2012 18:40:11 +0000
X-Env-Sender: ijc@hellion.org.uk
X-Msg-Ref: server-6.tower-216.messagelabs.com!1351276809!20501446!1
X-Originating-IP: [212.110.190.137]
X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD,
	ML_RADAR_SPEW_LINKS_22,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14200 invoked from network); 26 Oct 2012 18:40:09 -0000
Received: from benson.vm.bytemark.co.uk (HELO benson.vm.bytemark.co.uk)
	(212.110.190.137)
	by server-6.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Oct 2012 18:40:09 -0000
Received: from cpc22-cmbg14-2-0-cust482.5-4.cable.virginmedia.com
	([86.6.25.227] helo=hopkins.hellion.org.uk)
	by benson.vm.bytemark.co.uk with esmtpsa
	(TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72)
	(envelope-from )
	id 1TRopC-0006rm-IQ; Fri, 26 Oct 2012 19:40:06 +0100
Received: from dagon.hellion.org.uk ([192.168.1.7])
	by hopkins.hellion.org.uk with esmtps (SSL3.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TRopA-0001WU-4P; Fri, 26 Oct 2012 19:40:06 +0100
Message-ID: <1351276803.12176.4.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Mauro 
Date: Fri, 26 Oct 2012 19:40:03 +0100
In-Reply-To: 
References: <1351256392.15162.76.camel@zakaz.uk.xensource.com>
	
Organization: 
X-Mailer: Evolution 3.4.3-1 
Mime-Version: 1.0
X-SA-Exim-Connect-IP: 192.168.1.7
X-SA-Exim-Mail-From: ijc@hellion.org.uk
X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000)
X-SA-Exim-Scanned: Yes (on hopkins.hellion.org.uk)
Cc: "599161@bugs.debian.org" <599161@bugs.debian.org>,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] #599161: Xen debug patch for the "clock shifts by
 50 minutes" bug.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-26 at 19:25 +0100, Mauro wrote:
> On 26 October 2012 14:59, Ian Campbell  wrote:
> > Hi all,
> >
> > I've BCC'd a number of people who have reported seeing this bug at
> > various times in the past.
> >
> > If you can still repro I'd appreciate it if you could give the patch in
> > http://marc.info/?l=xen-devel&m=135049062216685&w=2 (also attached) a go
> > and report back success/failure and the output of the debugging messages
> > produced.
> 
> Is that patch for amd64 architectures?

It is for 32 and 64 bit x86, so yes.

BTW, you were the original recipient of this patch in the thread linked
above.

Ian.
-- 
Ian Campbell


"I'd love to go out with you, but I'm having all my plants neutered."


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 18:40:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 18:40:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRopI-0008Bu-UJ; Fri, 26 Oct 2012 18:40:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRopH-0008Bj-Lj
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 18:40:11 +0000
Received: from [85.158.143.99:7048] by server-1.bemta-4.messagelabs.com id
	17/66-19134-B09DA805; Fri, 26 Oct 2012 18:40:11 +0000
X-Env-Sender: ijc@hellion.org.uk
X-Msg-Ref: server-6.tower-216.messagelabs.com!1351276809!20501446!1
X-Originating-IP: [212.110.190.137]
X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD,
	ML_RADAR_SPEW_LINKS_22,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14200 invoked from network); 26 Oct 2012 18:40:09 -0000
Received: from benson.vm.bytemark.co.uk (HELO benson.vm.bytemark.co.uk)
	(212.110.190.137)
	by server-6.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Oct 2012 18:40:09 -0000
Received: from cpc22-cmbg14-2-0-cust482.5-4.cable.virginmedia.com
	([86.6.25.227] helo=hopkins.hellion.org.uk)
	by benson.vm.bytemark.co.uk with esmtpsa
	(TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72)
	(envelope-from )
	id 1TRopC-0006rm-IQ; Fri, 26 Oct 2012 19:40:06 +0100
Received: from dagon.hellion.org.uk ([192.168.1.7])
	by hopkins.hellion.org.uk with esmtps (SSL3.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from )
	id 1TRopA-0001WU-4P; Fri, 26 Oct 2012 19:40:06 +0100
Message-ID: <1351276803.12176.4.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Mauro 
Date: Fri, 26 Oct 2012 19:40:03 +0100
In-Reply-To: 
References: <1351256392.15162.76.camel@zakaz.uk.xensource.com>
	
Organization: 
X-Mailer: Evolution 3.4.3-1 
Mime-Version: 1.0
X-SA-Exim-Connect-IP: 192.168.1.7
X-SA-Exim-Mail-From: ijc@hellion.org.uk
X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000)
X-SA-Exim-Scanned: Yes (on hopkins.hellion.org.uk)
Cc: "599161@bugs.debian.org" <599161@bugs.debian.org>,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] #599161: Xen debug patch for the "clock shifts by
 50 minutes" bug.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-26 at 19:25 +0100, Mauro wrote:
> On 26 October 2012 14:59, Ian Campbell  wrote:
> > Hi all,
> >
> > I've BCC'd a number of people who have reported seeing this bug at
> > various times in the past.
> >
> > If you can still repro I'd appreciate it if you could give the patch in
> > http://marc.info/?l=xen-devel&m=135049062216685&w=2 (also attached) a go
> > and report back success/failure and the output of the debugging messages
> > produced.
> 
> Is that patch for amd64 architectures?

It is for 32 and 64 bit x86, so yes.

BTW, you were the original recipient of this patch in the thread linked
above.

Ian.
-- 
Ian Campbell


"I'd love to go out with you, but I'm having all my plants neutered."


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 18:41:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 18:41:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRoq4-0008Gr-CX; Fri, 26 Oct 2012 18:41:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRoq2-0008GU-Kv
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 18:40:58 +0000
Received: from [85.158.139.211:24519] by server-16.bemta-5.messagelabs.com id
	2E/06-04786-939DA805; Fri, 26 Oct 2012 18:40:57 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1351276855!23935364!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzkyODY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22119 invoked from network); 26 Oct 2012 18:40:56 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 18:40:56 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="42582171"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 18:40:29 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 14:40:29 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TRopZ-0002OS-6m;
	Fri, 26 Oct 2012 19:40:29 +0100
Date: Fri, 26 Oct 2012 19:40:13 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Tim Deegan 
In-Reply-To: <20121026165549.GF76080@ocelot.phlegethon.org>
Message-ID: 
References: 
	<1351091027-20740-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20121024155945.GD39126@ocelot.phlegethon.org>
	
	<20121026090141.GB76080@ocelot.phlegethon.org>
	
	
	
	<20121026165549.GF76080@ocelot.phlegethon.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	Ian Campbell ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 6/7] xen/arm: flush D-cache and I-cache when
 appropriate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 26 Oct 2012, Tim Deegan wrote:
> At 17:03 +0100 on 26 Oct (1351271018), Stefano Stabellini wrote:
> > On Fri, 26 Oct 2012, Stefano Stabellini wrote:
> > > On Fri, 26 Oct 2012, Stefano Stabellini wrote:
> > > > On Fri, 26 Oct 2012, Tim Deegan wrote:
> > > > > At 18:35 +0100 on 24 Oct (1351103740), Stefano Stabellini wrote:
> > > > > > > I don't think this is necessary - why not just pass va directly to the
> > > > > > > inline asm?  We don't care what register it's in (and if we did I'm not
> > > > > > > convinced this would guarantee it was r0).
> > > > > > > 
> > > > > > > > +    asm volatile (
> > > > > > > > +        "dsb;"
> > > > > > > > +        STORE_CP32(0, DCCMVAC)
> > > > > > > > +        "isb;"
> > > > > > > > +        : : "r" (r0) : "memory");
> > > > > > > 
> > > > > > > Does this need a 'memory' clobber?  Can we get away with just saying it
> > > > > > > consumes *va as an input?  All we need to be sure of is that the
> > > > > > > particular thing we're flushing has been written out; no need to stop
> > > > > > > any other optimizations.
> > > > > > 
> > > > > > you are right on both points
> > > > > > 
> > > > > > > I guess it might need to be re-cast as a macro so the compiler knows how
> > > > > > > big *va is?
> > > > > > 
> > > > > > I don't think it is necessary, after all the size of a register has to
> > > > > > be the same of a virtual address
> > > > > 
> > > > > But it's the size of the thing in memory that's being flushed that
> > > > > matters, not the size of the pointer to it!
> > > > >
> > > > > E.g. after a PTE write we
> > > > > need a 64-bit memory input operand to stop the compiler from hoisting
> > > > > any part of the PTE write past the cache flush. (well OK we explicitly use
> > > > > a 64-bit atomic write for PTE writes, but YKWIM).
> > > > 
> > > > The implementation of write_pte is entirely in assembly so I doubt that
> > > > the compiler is going to reorder it.
> > > > 
> > > > However I see your point in case of flush_xen_dcache_va.
> > > > Wouldn't a barrier() at the beginning of the function be enough?
> > > >
> > > 
> > > Actually we already have a memory clobber in flush_xen_dcache_va,
> > > shouldn't that prevent the compiler from reordering instructions?
> > > 
> > 
> > After reading again the entire thread I think that I understand what you
> > meant: can't we get rid of the memory clobber and specify *va as input?
> > 
> > However in order to do that correctly we need to make clear how big *va is
> > otherwise the compiler could reorder things.
> 
> Yes!
> 
> > The problem is that we don't know at compile time how big a cacheline
> > is, so I think that we need to keep the memory clobber.
> 
> No!  It's always safe to flush the entire line -- regardless of what
> other writes might be happening to it.  After all, the cache controller
> might evict that line on its own at any time, so nothing can be relying
> on its _not_ being flushed.
> 
> The only problem with not knowing how big a cacheline is is this: if the
> object is _bigger_ than a cache line we might use one DCCMVAC where more
> than one is needed.  We can avoid that by a compile-time check on some
> sort of architectural minimum cacheline size.
 
If we want to do that then we need to pass a size argument to
flush_xen_dcache_va and have a loop in the function, each iteration
flushing a cacheline:


static inline void flush_xen_dcache_va(void *p, unsigned long size)
{
    unsigned long cacheline_size = READ_CP32(CCSIDR);
    unsigned long i;
    for (i = 0; i < size; i += cacheline_size, p += cacheline_size) {
        asm volatile (
            "dsb;"
            STORE_CP32(0, DCCMVAC)
            "dsb;"
            : : "r" (p));
    }
}


Even though I think that it is really unlikely that the compiler moves
the writes after the loop, in theory we would still need to specify the
correct size of the input parameter to the inline assembly.

Is there a better way?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 18:41:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 18:41:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRoq4-0008Gr-CX; Fri, 26 Oct 2012 18:41:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRoq2-0008GU-Kv
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 18:40:58 +0000
Received: from [85.158.139.211:24519] by server-16.bemta-5.messagelabs.com id
	2E/06-04786-939DA805; Fri, 26 Oct 2012 18:40:57 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1351276855!23935364!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzkyODY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22119 invoked from network); 26 Oct 2012 18:40:56 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 18:40:56 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="42582171"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 18:40:29 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 14:40:29 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TRopZ-0002OS-6m;
	Fri, 26 Oct 2012 19:40:29 +0100
Date: Fri, 26 Oct 2012 19:40:13 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Tim Deegan 
In-Reply-To: <20121026165549.GF76080@ocelot.phlegethon.org>
Message-ID: 
References: 
	<1351091027-20740-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20121024155945.GD39126@ocelot.phlegethon.org>
	
	<20121026090141.GB76080@ocelot.phlegethon.org>
	
	
	
	<20121026165549.GF76080@ocelot.phlegethon.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	Ian Campbell ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 6/7] xen/arm: flush D-cache and I-cache when
 appropriate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 26 Oct 2012, Tim Deegan wrote:
> At 17:03 +0100 on 26 Oct (1351271018), Stefano Stabellini wrote:
> > On Fri, 26 Oct 2012, Stefano Stabellini wrote:
> > > On Fri, 26 Oct 2012, Stefano Stabellini wrote:
> > > > On Fri, 26 Oct 2012, Tim Deegan wrote:
> > > > > At 18:35 +0100 on 24 Oct (1351103740), Stefano Stabellini wrote:
> > > > > > > I don't think this is necessary - why not just pass va directly to the
> > > > > > > inline asm?  We don't care what register it's in (and if we did I'm not
> > > > > > > convinced this would guarantee it was r0).
> > > > > > > 
> > > > > > > > +    asm volatile (
> > > > > > > > +        "dsb;"
> > > > > > > > +        STORE_CP32(0, DCCMVAC)
> > > > > > > > +        "isb;"
> > > > > > > > +        : : "r" (r0) : "memory");
> > > > > > > 
> > > > > > > Does this need a 'memory' clobber?  Can we get away with just saying it
> > > > > > > consumes *va as an input?  All we need to be sure of is that the
> > > > > > > particular thing we're flushing has been written out; no need to stop
> > > > > > > any other optimizations.
> > > > > > 
> > > > > > you are right on both points
> > > > > > 
> > > > > > > I guess it might need to be re-cast as a macro so the compiler knows how
> > > > > > > big *va is?
> > > > > > 
> > > > > > I don't think it is necessary, after all the size of a register has to
> > > > > > be the same of a virtual address
> > > > > 
> > > > > But it's the size of the thing in memory that's being flushed that
> > > > > matters, not the size of the pointer to it!
> > > > >
> > > > > E.g. after a PTE write we
> > > > > need a 64-bit memory input operand to stop the compiler from hoisting
> > > > > any part of the PTE write past the cache flush. (well OK we explicitly use
> > > > > a 64-bit atomic write for PTE writes, but YKWIM).
> > > > 
> > > > The implementation of write_pte is entirely in assembly so I doubt that
> > > > the compiler is going to reorder it.
> > > > 
> > > > However I see your point in case of flush_xen_dcache_va.
> > > > Wouldn't a barrier() at the beginning of the function be enough?
> > > >
> > > 
> > > Actually we already have a memory clobber in flush_xen_dcache_va,
> > > shouldn't that prevent the compiler from reordering instructions?
> > > 
> > 
> > After reading again the entire thread I think that I understand what you
> > meant: can't we get rid of the memory clobber and specify *va as input?
> > 
> > However in order to do that correctly we need to make clear how big *va is
> > otherwise the compiler could reorder things.
> 
> Yes!
> 
> > The problem is that we don't know at compile time how big a cacheline
> > is, so I think that we need to keep the memory clobber.
> 
> No!  It's always safe to flush the entire line -- regardless of what
> other writes might be happening to it.  After all, the cache controller
> might evict that line on its own at any time, so nothing can be relying
> on its _not_ being flushed.
> 
> The only problem with not knowing how big a cacheline is is this: if the
> object is _bigger_ than a cache line we might use one DCCMVAC where more
> than one is needed.  We can avoid that by a compile-time check on some
> sort of architectural minimum cacheline size.
 
If we want to do that then we need to pass a size argument to
flush_xen_dcache_va and have a loop in the function, each iteration
flushing a cacheline:


static inline void flush_xen_dcache_va(void *p, unsigned long size)
{
    unsigned long cacheline_size = READ_CP32(CCSIDR);
    unsigned long i;
    for (i = 0; i < size; i += cacheline_size, p += cacheline_size) {
        asm volatile (
            "dsb;"
            STORE_CP32(0, DCCMVAC)
            "dsb;"
            : : "r" (p));
    }
}


Even though I think that it is really unlikely that the compiler moves
the writes after the loop, in theory we would still need to specify the
correct size of the input parameter to the inline assembly.

Is there a better way?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 18:43:03 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 18:43:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRorn-00006P-Ta; Fri, 26 Oct 2012 18:42:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRorm-00006B-KP
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 18:42:46 +0000
Received: from [85.158.139.83:59661] by server-16.bemta-5.messagelabs.com id
	98/97-04786-5A9DA805; Fri, 26 Oct 2012 18:42:45 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1351276963!20164621!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzkyODY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14596 invoked from network); 26 Oct 2012 18:42:44 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 18:42:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="42582473"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 18:42:43 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 14:42:42 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TRori-0002QO-9b;
	Fri, 26 Oct 2012 19:42:42 +0100
Date: Fri, 26 Oct 2012 19:42:26 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1351269622.15162.105.camel@zakaz.uk.xensource.com>
Message-ID: 
References: 
	<1351091027-20740-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1351157246.18035.129.camel@zakaz.uk.xensource.com>
	
	<1351269622.15162.105.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" , "Tim
	\(Xen.org\)" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 1/7] xen/arm: fix rank calculation in
 vgic_vcpu_inject_irq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 26 Oct 2012, Ian Campbell wrote:
> > It means that this patch hides the bug rather than fixing it...
> 
> What are the symptoms?
> 
> BTW I noticed that "byte = irq & 0x3;" is redundant since byte_read also
> has the & in it. But that won't cause problems.

The ienable bit is wrong for irq > 32.

I think that the problem is the usage of vgic_irq_rank with registers
that have 1 bit per interrupt.
In fact the following patch fixes the issue.

---


xen/arm: pass the correct bit-per-interrupt argument to vgic_irq_rank

Use 1 for registers that have 1 bit per irq.

Signed-off-by: Stefano Stabellini 

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 3c3983f..92731b6 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -42,13 +42,7 @@
  */
 static inline int REG_RANK_NR(int b, uint32_t n)
 {
-    switch ( b )
-    {
-    case 8: return n >> 3;
-    case 4: return n >> 2;
-    case 2: return n >> 1;
-    default: BUG();
-    }
+    return n / b;
 }
 
 /*
@@ -199,7 +193,7 @@ static int vgic_distr_mmio_read(struct vcpu *v, mmio_info_t *info)
 
     case GICD_ISENABLER ... GICD_ISENABLERN:
         if ( dabt.size != 2 ) goto bad_width;
-        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ISENABLER);
+        rank = vgic_irq_rank(v, 1, gicd_reg - GICD_ISENABLER);
         if ( rank == NULL) goto read_as_zero;
         vgic_lock_rank(v, rank);
         *r = rank->ienable;
@@ -208,7 +202,7 @@ static int vgic_distr_mmio_read(struct vcpu *v, mmio_info_t *info)
 
     case GICD_ICENABLER ... GICD_ICENABLERN:
         if ( dabt.size != 2 ) goto bad_width;
-        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ICENABLER);
+        rank = vgic_irq_rank(v, 1, gicd_reg - GICD_ICENABLER);
         if ( rank == NULL) goto read_as_zero;
         vgic_lock_rank(v, rank);
         *r = rank->ienable;
@@ -217,7 +211,7 @@ static int vgic_distr_mmio_read(struct vcpu *v, mmio_info_t *info)
 
     case GICD_ISPENDR ... GICD_ISPENDRN:
         if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
-        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ISPENDR);
+        rank = vgic_irq_rank(v, 1, gicd_reg - GICD_ISPENDR);
         if ( rank == NULL) goto read_as_zero;
         vgic_lock_rank(v, rank);
         *r = byte_read(rank->ipend, dabt.sign, offset);
@@ -226,7 +220,7 @@ static int vgic_distr_mmio_read(struct vcpu *v, mmio_info_t *info)
 
     case GICD_ICPENDR ... GICD_ICPENDRN:
         if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
-        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ICPENDR);
+        rank = vgic_irq_rank(v, 1, gicd_reg - GICD_ICPENDR);
         if ( rank == NULL) goto read_as_zero;
         vgic_lock_rank(v, rank);
         *r = byte_read(rank->ipend, dabt.sign, offset);
@@ -235,7 +229,7 @@ static int vgic_distr_mmio_read(struct vcpu *v, mmio_info_t *info)
 
     case GICD_ISACTIVER ... GICD_ISACTIVERN:
         if ( dabt.size != 2 ) goto bad_width;
-        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ISACTIVER);
+        rank = vgic_irq_rank(v, 1, gicd_reg - GICD_ISACTIVER);
         if ( rank == NULL) goto read_as_zero;
         vgic_lock_rank(v, rank);
         *r = rank->iactive;
@@ -244,7 +238,7 @@ static int vgic_distr_mmio_read(struct vcpu *v, mmio_info_t *info)
 
     case GICD_ICACTIVER ... GICD_ICACTIVERN:
         if ( dabt.size != 2 ) goto bad_width;
-        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ICACTIVER);
+        rank = vgic_irq_rank(v, 1, gicd_reg - GICD_ICACTIVER);
         if ( rank == NULL) goto read_as_zero;
         vgic_lock_rank(v, rank);
         *r = rank->iactive;
@@ -296,7 +290,7 @@ static int vgic_distr_mmio_read(struct vcpu *v, mmio_info_t *info)
 
     case GICD_CPENDSGIR ... GICD_CPENDSGIRN:
         if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
-        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_CPENDSGIR);
+        rank = vgic_irq_rank(v, 1, gicd_reg - GICD_CPENDSGIR);
         if ( rank == NULL) goto read_as_zero;
         vgic_lock_rank(v, rank);
         *r = byte_read(rank->pendsgi, dabt.sign, offset);
@@ -305,7 +299,7 @@ static int vgic_distr_mmio_read(struct vcpu *v, mmio_info_t *info)
 
     case GICD_SPENDSGIR ... GICD_SPENDSGIRN:
         if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
-        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_SPENDSGIR);
+        rank = vgic_irq_rank(v, 1, gicd_reg - GICD_SPENDSGIR);
         if ( rank == NULL) goto read_as_zero;
         vgic_lock_rank(v, rank);
         *r = byte_read(rank->pendsgi, dabt.sign, offset);
@@ -400,7 +394,7 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
 
     case GICD_ISENABLER ... GICD_ISENABLERN:
         if ( dabt.size != 2 ) goto bad_width;
-        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ISENABLER);
+        rank = vgic_irq_rank(v, 1, gicd_reg - GICD_ISENABLER);
         if ( rank == NULL) goto write_ignore;
         vgic_lock_rank(v, rank);
         tr = rank->ienable;
@@ -411,7 +405,7 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
 
     case GICD_ICENABLER ... GICD_ICENABLERN:
         if ( dabt.size != 2 ) goto bad_width;
-        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ICENABLER);
+        rank = vgic_irq_rank(v, 1, gicd_reg - GICD_ICENABLER);
         if ( rank == NULL) goto write_ignore;
         vgic_lock_rank(v, rank);
         rank->ienable &= ~*r;
@@ -432,7 +426,7 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
 
     case GICD_ISACTIVER ... GICD_ISACTIVERN:
         if ( dabt.size != 2 ) goto bad_width;
-        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ISACTIVER);
+        rank = vgic_irq_rank(v, 1, gicd_reg - GICD_ISACTIVER);
         if ( rank == NULL) goto write_ignore;
         vgic_lock_rank(v, rank);
         rank->iactive &= ~*r;
@@ -441,7 +435,7 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
 
     case GICD_ICACTIVER ... GICD_ICACTIVERN:
         if ( dabt.size != 2 ) goto bad_width;
-        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ICACTIVER);
+        rank = vgic_irq_rank(v, 1, gicd_reg - GICD_ICACTIVER);
         if ( rank == NULL) goto write_ignore;
         vgic_lock_rank(v, rank);
         rank->iactive &= ~*r;
@@ -577,9 +571,9 @@ struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq)
 
 void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
 {
-    int idx = irq >> 2, byte = irq & 0x3;
+    int byte = irq & 0x3;
     uint8_t priority;
-    struct vgic_irq_rank *rank = vgic_irq_rank(v, 8, idx);
+    struct vgic_irq_rank *rank = vgic_irq_rank(v, 1, irq / 32);
     struct pending_irq *iter, *n = irq_to_pending(v, irq);
     unsigned long flags;
 
@@ -587,7 +581,7 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
     if (!list_empty(&n->inflight))
         return;
 
-    priority = byte_read(rank->ipriority[REG_RANK_INDEX(8, idx)], 0, byte);
+    priority = byte_read(rank->ipriority[REG_RANK_INDEX(8, irq / 4)], 0, byte);
 
     n->irq = irq;
     n->priority = priority;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 18:43:03 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 18:43:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRorn-00006P-Ta; Fri, 26 Oct 2012 18:42:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRorm-00006B-KP
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 18:42:46 +0000
Received: from [85.158.139.83:59661] by server-16.bemta-5.messagelabs.com id
	98/97-04786-5A9DA805; Fri, 26 Oct 2012 18:42:45 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1351276963!20164621!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzkyODY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14596 invoked from network); 26 Oct 2012 18:42:44 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 18:42:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="42582473"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 18:42:43 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 14:42:42 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TRori-0002QO-9b;
	Fri, 26 Oct 2012 19:42:42 +0100
Date: Fri, 26 Oct 2012 19:42:26 +0100
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Ian Campbell 
In-Reply-To: <1351269622.15162.105.camel@zakaz.uk.xensource.com>
Message-ID: 
References: 
	<1351091027-20740-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1351157246.18035.129.camel@zakaz.uk.xensource.com>
	
	<1351269622.15162.105.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" , "Tim
	\(Xen.org\)" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 1/7] xen/arm: fix rank calculation in
 vgic_vcpu_inject_irq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 26 Oct 2012, Ian Campbell wrote:
> > It means that this patch hides the bug rather than fixing it...
> 
> What are the symptoms?
> 
> BTW I noticed that "byte = irq & 0x3;" is redundant since byte_read also
> has the & in it. But that won't cause problems.

The ienable bit is wrong for irq > 32.

I think that the problem is the usage of vgic_irq_rank with registers
that have 1 bit per interrupt.
In fact the following patch fixes the issue.

---


xen/arm: pass the correct bit-per-interrupt argument to vgic_irq_rank

Use 1 for registers that have 1 bit per irq.

Signed-off-by: Stefano Stabellini 

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 3c3983f..92731b6 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -42,13 +42,7 @@
  */
 static inline int REG_RANK_NR(int b, uint32_t n)
 {
-    switch ( b )
-    {
-    case 8: return n >> 3;
-    case 4: return n >> 2;
-    case 2: return n >> 1;
-    default: BUG();
-    }
+    return n / b;
 }
 
 /*
@@ -199,7 +193,7 @@ static int vgic_distr_mmio_read(struct vcpu *v, mmio_info_t *info)
 
     case GICD_ISENABLER ... GICD_ISENABLERN:
         if ( dabt.size != 2 ) goto bad_width;
-        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ISENABLER);
+        rank = vgic_irq_rank(v, 1, gicd_reg - GICD_ISENABLER);
         if ( rank == NULL) goto read_as_zero;
         vgic_lock_rank(v, rank);
         *r = rank->ienable;
@@ -208,7 +202,7 @@ static int vgic_distr_mmio_read(struct vcpu *v, mmio_info_t *info)
 
     case GICD_ICENABLER ... GICD_ICENABLERN:
         if ( dabt.size != 2 ) goto bad_width;
-        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ICENABLER);
+        rank = vgic_irq_rank(v, 1, gicd_reg - GICD_ICENABLER);
         if ( rank == NULL) goto read_as_zero;
         vgic_lock_rank(v, rank);
         *r = rank->ienable;
@@ -217,7 +211,7 @@ static int vgic_distr_mmio_read(struct vcpu *v, mmio_info_t *info)
 
     case GICD_ISPENDR ... GICD_ISPENDRN:
         if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
-        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ISPENDR);
+        rank = vgic_irq_rank(v, 1, gicd_reg - GICD_ISPENDR);
         if ( rank == NULL) goto read_as_zero;
         vgic_lock_rank(v, rank);
         *r = byte_read(rank->ipend, dabt.sign, offset);
@@ -226,7 +220,7 @@ static int vgic_distr_mmio_read(struct vcpu *v, mmio_info_t *info)
 
     case GICD_ICPENDR ... GICD_ICPENDRN:
         if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
-        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ICPENDR);
+        rank = vgic_irq_rank(v, 1, gicd_reg - GICD_ICPENDR);
         if ( rank == NULL) goto read_as_zero;
         vgic_lock_rank(v, rank);
         *r = byte_read(rank->ipend, dabt.sign, offset);
@@ -235,7 +229,7 @@ static int vgic_distr_mmio_read(struct vcpu *v, mmio_info_t *info)
 
     case GICD_ISACTIVER ... GICD_ISACTIVERN:
         if ( dabt.size != 2 ) goto bad_width;
-        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ISACTIVER);
+        rank = vgic_irq_rank(v, 1, gicd_reg - GICD_ISACTIVER);
         if ( rank == NULL) goto read_as_zero;
         vgic_lock_rank(v, rank);
         *r = rank->iactive;
@@ -244,7 +238,7 @@ static int vgic_distr_mmio_read(struct vcpu *v, mmio_info_t *info)
 
     case GICD_ICACTIVER ... GICD_ICACTIVERN:
         if ( dabt.size != 2 ) goto bad_width;
-        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ICACTIVER);
+        rank = vgic_irq_rank(v, 1, gicd_reg - GICD_ICACTIVER);
         if ( rank == NULL) goto read_as_zero;
         vgic_lock_rank(v, rank);
         *r = rank->iactive;
@@ -296,7 +290,7 @@ static int vgic_distr_mmio_read(struct vcpu *v, mmio_info_t *info)
 
     case GICD_CPENDSGIR ... GICD_CPENDSGIRN:
         if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
-        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_CPENDSGIR);
+        rank = vgic_irq_rank(v, 1, gicd_reg - GICD_CPENDSGIR);
         if ( rank == NULL) goto read_as_zero;
         vgic_lock_rank(v, rank);
         *r = byte_read(rank->pendsgi, dabt.sign, offset);
@@ -305,7 +299,7 @@ static int vgic_distr_mmio_read(struct vcpu *v, mmio_info_t *info)
 
     case GICD_SPENDSGIR ... GICD_SPENDSGIRN:
         if ( dabt.size != 0 && dabt.size != 2 ) goto bad_width;
-        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_SPENDSGIR);
+        rank = vgic_irq_rank(v, 1, gicd_reg - GICD_SPENDSGIR);
         if ( rank == NULL) goto read_as_zero;
         vgic_lock_rank(v, rank);
         *r = byte_read(rank->pendsgi, dabt.sign, offset);
@@ -400,7 +394,7 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
 
     case GICD_ISENABLER ... GICD_ISENABLERN:
         if ( dabt.size != 2 ) goto bad_width;
-        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ISENABLER);
+        rank = vgic_irq_rank(v, 1, gicd_reg - GICD_ISENABLER);
         if ( rank == NULL) goto write_ignore;
         vgic_lock_rank(v, rank);
         tr = rank->ienable;
@@ -411,7 +405,7 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
 
     case GICD_ICENABLER ... GICD_ICENABLERN:
         if ( dabt.size != 2 ) goto bad_width;
-        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ICENABLER);
+        rank = vgic_irq_rank(v, 1, gicd_reg - GICD_ICENABLER);
         if ( rank == NULL) goto write_ignore;
         vgic_lock_rank(v, rank);
         rank->ienable &= ~*r;
@@ -432,7 +426,7 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
 
     case GICD_ISACTIVER ... GICD_ISACTIVERN:
         if ( dabt.size != 2 ) goto bad_width;
-        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ISACTIVER);
+        rank = vgic_irq_rank(v, 1, gicd_reg - GICD_ISACTIVER);
         if ( rank == NULL) goto write_ignore;
         vgic_lock_rank(v, rank);
         rank->iactive &= ~*r;
@@ -441,7 +435,7 @@ static int vgic_distr_mmio_write(struct vcpu *v, mmio_info_t *info)
 
     case GICD_ICACTIVER ... GICD_ICACTIVERN:
         if ( dabt.size != 2 ) goto bad_width;
-        rank = vgic_irq_rank(v, 8, gicd_reg - GICD_ICACTIVER);
+        rank = vgic_irq_rank(v, 1, gicd_reg - GICD_ICACTIVER);
         if ( rank == NULL) goto write_ignore;
         vgic_lock_rank(v, rank);
         rank->iactive &= ~*r;
@@ -577,9 +571,9 @@ struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq)
 
 void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
 {
-    int idx = irq >> 2, byte = irq & 0x3;
+    int byte = irq & 0x3;
     uint8_t priority;
-    struct vgic_irq_rank *rank = vgic_irq_rank(v, 8, idx);
+    struct vgic_irq_rank *rank = vgic_irq_rank(v, 1, irq / 32);
     struct pending_irq *iter, *n = irq_to_pending(v, irq);
     unsigned long flags;
 
@@ -587,7 +581,7 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
     if (!list_empty(&n->inflight))
         return;
 
-    priority = byte_read(rank->ipriority[REG_RANK_INDEX(8, idx)], 0, byte);
+    priority = byte_read(rank->ipriority[REG_RANK_INDEX(8, irq / 4)], 0, byte);
 
     n->irq = irq;
     n->priority = priority;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 18:45:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 18:45:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRotq-0000JF-Ee; Fri, 26 Oct 2012 18:44:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRoto-0000J0-L9
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 18:44:52 +0000
Received: from [193.109.254.147:9690] by server-7.bemta-14.messagelabs.com id
	DF/A1-24122-42ADA805; Fri, 26 Oct 2012 18:44:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1351277090!8564276!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24466 invoked from network); 26 Oct 2012 18:44:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 18:44:50 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15419200"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 18:44:49 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 26 Oct 2012 19:44:49 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TRotl-0001fN-KE;
	Fri, 26 Oct 2012 18:44:49 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TRotl-00053x-EN;
	Fri, 26 Oct 2012 19:44:49 +0100
To: 
Message-ID: 
From: xen.org 
Date: Fri, 26 Oct 2012 19:44:49 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14086: trouble: blocked/broken/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14086 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14086/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   2 host-install(2)         broken REGR. vs. 14079
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 14079

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a

version targeted for testing:
 xen                  37a8946eeb9d
baseline version:
 xen                  c26e1a79fe77

------------------------------------------------------------
People who touched revisions under test:
  Charles Arnold 
  Christoph Egger 
  Ian Campbell 
  Ian Jackson 
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26115:37a8946eeb9d
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:09:29 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    
    
changeset:   26114:6f9e46917eb8
user:        Charles Arnold 
date:        Fri Oct 26 12:05:08 2012 +0100
    
    pygrub: Add option to list grub entries
    
    The argument to "--entry" allows 2 syntaxes, either directly the entry
    number in menu.lst, or the whole string behind the "title" key word.
    This poses the following issue:
    
    From Dom0 there is no way to guess the number and, or the complete
    title string because this string contains the kernel version, which
    will change with a kernel update.
    
    This patch adds [-l|--list-entries] as an argument to pygrub.
    
    Signed-off-by: Charles Arnold 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26113:03af0abd2b72
user:        Ian Campbell 
date:        Fri Oct 26 12:03:12 2012 +0100
    
    xl: Do not leak events when a domain exits.
    
    The goto in both of these places misses the event free which would
    normally clean up.
    
    ==8655== 80 bytes in 1 blocks are definitely lost in loss record 1 of 1
    ==8655==    at 0x4024370: calloc (vg_replace_malloc.c:593)
    ==8655==    by 0x406EAAE: libxl__zalloc (libxl_internal.c:83)
    ==8655==    by 0x4078173: libxl__event_new (libxl_event.c:1167)
    ==8655==    by 0x4056373: domain_death_occurred (libxl.c:958)
    ==8655==    by 0x4058D06: domain_death_xswatch_callback (libxl.c:1038)
    ==8655==    by 0x4078EB5: watchfd_callback (libxl_event.c:458)
    ==8655==    by 0x407839E: afterpoll_internal (libxl_event.c:949)
    ==8655==    by 0x4079142: eventloop_iteration (libxl_event.c:1371)
    ==8655==    by 0x40799BB: libxl_event_wait (libxl_event.c:1396)
    ==8655==    by 0x805CC67: create_domain (xl_cmdimpl.c:1698)
    ==8655==    by 0x805E001: main_create (xl_cmdimpl.c:3986)
    ==8655==    by 0x804D43D: main (xl.c:285)
    
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26112:d07692b5c780
user:        Ian Jackson 
date:        Fri Oct 26 11:39:42 2012 +0100
    
    Revert 26109:6ccfe4d29f95
    
    This changeset was contaminated by changes hanging around in my
    working tree.  Sorry :-(.
    
    Signed-off-by: Ian Jackson 
    
    
changeset:   26111:c26e1a79fe77
user:        Christoph Egger 
date:        Thu Oct 25 17:12:55 2012 +0100
    
    libxl: NetBSD PCI passthrough support
    
    Add PCI passthrough support for HVM guests.
    
    Signed-off-by: Christoph Egger 
    Committed-by: Ian Jackson 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 18:45:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 18:45:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRotq-0000JF-Ee; Fri, 26 Oct 2012 18:44:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRoto-0000J0-L9
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 18:44:52 +0000
Received: from [193.109.254.147:9690] by server-7.bemta-14.messagelabs.com id
	DF/A1-24122-42ADA805; Fri, 26 Oct 2012 18:44:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1351277090!8564276!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24466 invoked from network); 26 Oct 2012 18:44:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 18:44:50 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15419200"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 18:44:49 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 26 Oct 2012 19:44:49 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TRotl-0001fN-KE;
	Fri, 26 Oct 2012 18:44:49 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TRotl-00053x-EN;
	Fri, 26 Oct 2012 19:44:49 +0100
To: 
Message-ID: 
From: xen.org 
Date: Fri, 26 Oct 2012 19:44:49 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14086: trouble: blocked/broken/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14086 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14086/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   2 host-install(2)         broken REGR. vs. 14079
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 14079

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a

version targeted for testing:
 xen                  37a8946eeb9d
baseline version:
 xen                  c26e1a79fe77

------------------------------------------------------------
People who touched revisions under test:
  Charles Arnold 
  Christoph Egger 
  Ian Campbell 
  Ian Jackson 
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26115:37a8946eeb9d
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:09:29 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    
    
changeset:   26114:6f9e46917eb8
user:        Charles Arnold 
date:        Fri Oct 26 12:05:08 2012 +0100
    
    pygrub: Add option to list grub entries
    
    The argument to "--entry" allows 2 syntaxes, either directly the entry
    number in menu.lst, or the whole string behind the "title" key word.
    This poses the following issue:
    
    From Dom0 there is no way to guess the number and, or the complete
    title string because this string contains the kernel version, which
    will change with a kernel update.
    
    This patch adds [-l|--list-entries] as an argument to pygrub.
    
    Signed-off-by: Charles Arnold 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26113:03af0abd2b72
user:        Ian Campbell 
date:        Fri Oct 26 12:03:12 2012 +0100
    
    xl: Do not leak events when a domain exits.
    
    The goto in both of these places misses the event free which would
    normally clean up.
    
    ==8655== 80 bytes in 1 blocks are definitely lost in loss record 1 of 1
    ==8655==    at 0x4024370: calloc (vg_replace_malloc.c:593)
    ==8655==    by 0x406EAAE: libxl__zalloc (libxl_internal.c:83)
    ==8655==    by 0x4078173: libxl__event_new (libxl_event.c:1167)
    ==8655==    by 0x4056373: domain_death_occurred (libxl.c:958)
    ==8655==    by 0x4058D06: domain_death_xswatch_callback (libxl.c:1038)
    ==8655==    by 0x4078EB5: watchfd_callback (libxl_event.c:458)
    ==8655==    by 0x407839E: afterpoll_internal (libxl_event.c:949)
    ==8655==    by 0x4079142: eventloop_iteration (libxl_event.c:1371)
    ==8655==    by 0x40799BB: libxl_event_wait (libxl_event.c:1396)
    ==8655==    by 0x805CC67: create_domain (xl_cmdimpl.c:1698)
    ==8655==    by 0x805E001: main_create (xl_cmdimpl.c:3986)
    ==8655==    by 0x804D43D: main (xl.c:285)
    
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26112:d07692b5c780
user:        Ian Jackson 
date:        Fri Oct 26 11:39:42 2012 +0100
    
    Revert 26109:6ccfe4d29f95
    
    This changeset was contaminated by changes hanging around in my
    working tree.  Sorry :-(.
    
    Signed-off-by: Ian Jackson 
    
    
changeset:   26111:c26e1a79fe77
user:        Christoph Egger 
date:        Thu Oct 25 17:12:55 2012 +0100
    
    libxl: NetBSD PCI passthrough support
    
    Add PCI passthrough support for HVM guests.
    
    Signed-off-by: Christoph Egger 
    Committed-by: Ian Jackson 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 18:59:33 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 18:59:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRp7f-0000c6-4j; Fri, 26 Oct 2012 18:59:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRp7d-0000c1-Rp
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 18:59:10 +0000
Received: from [85.158.139.211:38403] by server-10.bemta-5.messagelabs.com id
	67/2B-01025-D7DDA805; Fri, 26 Oct 2012 18:59:09 +0000
X-Env-Sender: roger.cruz@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1351277946!23813716!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODE4MDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6180 invoked from network); 26 Oct 2012 18:59:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 18:59:07 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="212596821"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 18:58:59 +0000
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.210]) by
	FTLPMAILMX02.citrite.net ([10.13.107.66]) with mapi; Fri, 26 Oct 2012
	14:58:59 -0400
From: Roger Cruz 
To: Ian Campbell 
Date: Fri, 26 Oct 2012 14:55:10 -0400
Thread-Topic: [Xen-devel] Tracking down a boot speed issue
Thread-Index: Ac2zqR4nR+gsRGedQp60jzYwiPFpvQAAk7NJ
Message-ID: <844D15D284C78547BB0DAEE12D33A1B67C212BB95A@FTLPMAILBOX02.citrite.net>
References: <844D15D284C78547BB0DAEE12D33A1B67C212BB956@FTLPMAILBOX02.citrite.net>
	<844D15D284C78547BB0DAEE12D33A1B67C212BB958@FTLPMAILBOX02.citrite.net>,
	<1351276718.12176.1.camel@dagon.hellion.org.uk>
In-Reply-To: <1351276718.12176.1.camel@dagon.hellion.org.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Tracking down a boot speed issue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Well, that may be a good clue or reason for what I have been thinking was a long time to setup the zonelists (that is how it shows up when looking at an untouched kernel).  So if I understand your response correctly.. the time displayed will always be zero until the per_cpu area is set up? 
________________________________________
From: Ian Campbell [Ian.Campbell@citrix.com]
Sent: Friday, October 26, 2012 2:38 PM
To: Roger Cruz
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Tracking down a boot speed issue

On Fri, 2012-10-26 at 18:30 +0100, Roger Cruz wrote:
> As you see from the timed samples below, the access can take anywhere
> from .6 to 1.2 secs (though I have seen it take 1.6 secs every single
> time with  Linux 3.2.16 and Xen 4.0.3).

Isn't this just because setting up the per-cpu shared info makes the
time available to printk. Note that the timestamp is zero beforehand
(a big hint that time isn't setup yet). Also see xen_clocksource_read().

IOW I think what is being measured here is the time from start of day
until the second printk, not the time between the two prints.

[...]
>             printk(KERN_ALERT "in cpu loop %d for shared info", cpu);
> ===>    per_cpu(xen_vcpu,cpu) = &HYPERVISOR_shared_info->vcpu_info[cpu];
>             printk(KERN_ALERT "in cpu loop %d computed shared info", cpu);
>
> Oct 25 20:24:11 23445LU-PBBFMWY kernel: [    0.000000] in cpu loop 0 for shared info
> Oct 25 20:24:11 23445LU-PBBFMWY kernel: [    1.238877] in cpu loop 0 computed shared info
>
> Oct 25 20:52:53 23445LU-PBBFMWY kernel: [    0.000000] in cpu loop 0 for shared info
> Oct 25 20:52:53 23445LU-PBBFMWY kernel: [    0.718365] in cpu loop 0 computed shared info
>
> Oct 25 20:41:27 23445LU-PBBFMWY kernel: [    0.000000] in cpu loop 0 for shared info
> Oct 25 20:41:27 23445LU-PBBFMWY kernel: [    0.671690] in cpu loop 0 computed shared info
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 18:59:33 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 18:59:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRp7f-0000c6-4j; Fri, 26 Oct 2012 18:59:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRp7d-0000c1-Rp
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 18:59:10 +0000
Received: from [85.158.139.211:38403] by server-10.bemta-5.messagelabs.com id
	67/2B-01025-D7DDA805; Fri, 26 Oct 2012 18:59:09 +0000
X-Env-Sender: roger.cruz@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1351277946!23813716!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODE4MDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6180 invoked from network); 26 Oct 2012 18:59:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 18:59:07 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="212596821"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 18:58:59 +0000
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.210]) by
	FTLPMAILMX02.citrite.net ([10.13.107.66]) with mapi; Fri, 26 Oct 2012
	14:58:59 -0400
From: Roger Cruz 
To: Ian Campbell 
Date: Fri, 26 Oct 2012 14:55:10 -0400
Thread-Topic: [Xen-devel] Tracking down a boot speed issue
Thread-Index: Ac2zqR4nR+gsRGedQp60jzYwiPFpvQAAk7NJ
Message-ID: <844D15D284C78547BB0DAEE12D33A1B67C212BB95A@FTLPMAILBOX02.citrite.net>
References: <844D15D284C78547BB0DAEE12D33A1B67C212BB956@FTLPMAILBOX02.citrite.net>
	<844D15D284C78547BB0DAEE12D33A1B67C212BB958@FTLPMAILBOX02.citrite.net>,
	<1351276718.12176.1.camel@dagon.hellion.org.uk>
In-Reply-To: <1351276718.12176.1.camel@dagon.hellion.org.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Tracking down a boot speed issue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Well, that may be a good clue or reason for what I have been thinking was a long time to setup the zonelists (that is how it shows up when looking at an untouched kernel).  So if I understand your response correctly.. the time displayed will always be zero until the per_cpu area is set up? 
________________________________________
From: Ian Campbell [Ian.Campbell@citrix.com]
Sent: Friday, October 26, 2012 2:38 PM
To: Roger Cruz
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Tracking down a boot speed issue

On Fri, 2012-10-26 at 18:30 +0100, Roger Cruz wrote:
> As you see from the timed samples below, the access can take anywhere
> from .6 to 1.2 secs (though I have seen it take 1.6 secs every single
> time with  Linux 3.2.16 and Xen 4.0.3).

Isn't this just because setting up the per-cpu shared info makes the
time available to printk. Note that the timestamp is zero beforehand
(a big hint that time isn't setup yet). Also see xen_clocksource_read().

IOW I think what is being measured here is the time from start of day
until the second printk, not the time between the two prints.

[...]
>             printk(KERN_ALERT "in cpu loop %d for shared info", cpu);
> ===>    per_cpu(xen_vcpu,cpu) = &HYPERVISOR_shared_info->vcpu_info[cpu];
>             printk(KERN_ALERT "in cpu loop %d computed shared info", cpu);
>
> Oct 25 20:24:11 23445LU-PBBFMWY kernel: [    0.000000] in cpu loop 0 for shared info
> Oct 25 20:24:11 23445LU-PBBFMWY kernel: [    1.238877] in cpu loop 0 computed shared info
>
> Oct 25 20:52:53 23445LU-PBBFMWY kernel: [    0.000000] in cpu loop 0 for shared info
> Oct 25 20:52:53 23445LU-PBBFMWY kernel: [    0.718365] in cpu loop 0 computed shared info
>
> Oct 25 20:41:27 23445LU-PBBFMWY kernel: [    0.000000] in cpu loop 0 for shared info
> Oct 25 20:41:27 23445LU-PBBFMWY kernel: [    0.671690] in cpu loop 0 computed shared info
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 19:03:23 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 19:03:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRpBS-0000nG-QM; Fri, 26 Oct 2012 19:03:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRpBR-0000nA-Me
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 19:03:05 +0000
Received: from [85.158.143.99:50384] by server-3.bemta-4.messagelabs.com id
	60/30-24279-96EDA805; Fri, 26 Oct 2012 19:03:05 +0000
X-Env-Sender: roger.cruz@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1351278178!22227017!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzkyODY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 375 invoked from network); 26 Oct 2012 19:03:00 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 19:03:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="42585696"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 19:02:47 +0000
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.210]) by
	FTLPMAILMX02.citrite.net ([10.13.107.66]) with mapi; Fri, 26 Oct 2012
	15:02:47 -0400
From: Roger Cruz 
To: Ian Campbell 
Date: Fri, 26 Oct 2012 15:02:07 -0400
Thread-Topic: [Xen-devel] Tracking down a boot speed issue
Thread-Index: Ac2zqR4nR+gsRGedQp60jzYwiPFpvQAA0cY5
Message-ID: <844D15D284C78547BB0DAEE12D33A1B67C212BB95B@FTLPMAILBOX02.citrite.net>
References: <844D15D284C78547BB0DAEE12D33A1B67C212BB956@FTLPMAILBOX02.citrite.net>
	<844D15D284C78547BB0DAEE12D33A1B67C212BB958@FTLPMAILBOX02.citrite.net>,
	<1351276718.12176.1.camel@dagon.hellion.org.uk>
In-Reply-To: <1351276718.12176.1.camel@dagon.hellion.org.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Tracking down a boot speed issue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

A question remains in my mind as why the times are variable.  Why does it take .67 secs and 1.6 secs other times for exactly the same boot code?
________________________________________
From: Ian Campbell [Ian.Campbell@citrix.com]
Sent: Friday, October 26, 2012 2:38 PM
To: Roger Cruz
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Tracking down a boot speed issue

On Fri, 2012-10-26 at 18:30 +0100, Roger Cruz wrote:
> As you see from the timed samples below, the access can take anywhere
> from .6 to 1.2 secs (though I have seen it take 1.6 secs every single
> time with  Linux 3.2.16 and Xen 4.0.3).

Isn't this just because setting up the per-cpu shared info makes the
time available to printk. Note that the timestamp is zero beforehand
(a big hint that time isn't setup yet). Also see xen_clocksource_read().

IOW I think what is being measured here is the time from start of day
until the second printk, not the time between the two prints.

[...]
>             printk(KERN_ALERT "in cpu loop %d for shared info", cpu);
> ===>    per_cpu(xen_vcpu,cpu) = &HYPERVISOR_shared_info->vcpu_info[cpu];
>             printk(KERN_ALERT "in cpu loop %d computed shared info", cpu);
>
> Oct 25 20:24:11 23445LU-PBBFMWY kernel: [    0.000000] in cpu loop 0 for shared info
> Oct 25 20:24:11 23445LU-PBBFMWY kernel: [    1.238877] in cpu loop 0 computed shared info
>
> Oct 25 20:52:53 23445LU-PBBFMWY kernel: [    0.000000] in cpu loop 0 for shared info
> Oct 25 20:52:53 23445LU-PBBFMWY kernel: [    0.718365] in cpu loop 0 computed shared info
>
> Oct 25 20:41:27 23445LU-PBBFMWY kernel: [    0.000000] in cpu loop 0 for shared info
> Oct 25 20:41:27 23445LU-PBBFMWY kernel: [    0.671690] in cpu loop 0 computed shared info
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 19:03:23 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 19:03:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRpBS-0000nG-QM; Fri, 26 Oct 2012 19:03:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRpBR-0000nA-Me
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 19:03:05 +0000
Received: from [85.158.143.99:50384] by server-3.bemta-4.messagelabs.com id
	60/30-24279-96EDA805; Fri, 26 Oct 2012 19:03:05 +0000
X-Env-Sender: roger.cruz@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1351278178!22227017!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzkyODY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 375 invoked from network); 26 Oct 2012 19:03:00 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 19:03:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="42585696"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 19:02:47 +0000
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.210]) by
	FTLPMAILMX02.citrite.net ([10.13.107.66]) with mapi; Fri, 26 Oct 2012
	15:02:47 -0400
From: Roger Cruz 
To: Ian Campbell 
Date: Fri, 26 Oct 2012 15:02:07 -0400
Thread-Topic: [Xen-devel] Tracking down a boot speed issue
Thread-Index: Ac2zqR4nR+gsRGedQp60jzYwiPFpvQAA0cY5
Message-ID: <844D15D284C78547BB0DAEE12D33A1B67C212BB95B@FTLPMAILBOX02.citrite.net>
References: <844D15D284C78547BB0DAEE12D33A1B67C212BB956@FTLPMAILBOX02.citrite.net>
	<844D15D284C78547BB0DAEE12D33A1B67C212BB958@FTLPMAILBOX02.citrite.net>,
	<1351276718.12176.1.camel@dagon.hellion.org.uk>
In-Reply-To: <1351276718.12176.1.camel@dagon.hellion.org.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Tracking down a boot speed issue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

A question remains in my mind as why the times are variable.  Why does it take .67 secs and 1.6 secs other times for exactly the same boot code?
________________________________________
From: Ian Campbell [Ian.Campbell@citrix.com]
Sent: Friday, October 26, 2012 2:38 PM
To: Roger Cruz
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Tracking down a boot speed issue

On Fri, 2012-10-26 at 18:30 +0100, Roger Cruz wrote:
> As you see from the timed samples below, the access can take anywhere
> from .6 to 1.2 secs (though I have seen it take 1.6 secs every single
> time with  Linux 3.2.16 and Xen 4.0.3).

Isn't this just because setting up the per-cpu shared info makes the
time available to printk. Note that the timestamp is zero beforehand
(a big hint that time isn't setup yet). Also see xen_clocksource_read().

IOW I think what is being measured here is the time from start of day
until the second printk, not the time between the two prints.

[...]
>             printk(KERN_ALERT "in cpu loop %d for shared info", cpu);
> ===>    per_cpu(xen_vcpu,cpu) = &HYPERVISOR_shared_info->vcpu_info[cpu];
>             printk(KERN_ALERT "in cpu loop %d computed shared info", cpu);
>
> Oct 25 20:24:11 23445LU-PBBFMWY kernel: [    0.000000] in cpu loop 0 for shared info
> Oct 25 20:24:11 23445LU-PBBFMWY kernel: [    1.238877] in cpu loop 0 computed shared info
>
> Oct 25 20:52:53 23445LU-PBBFMWY kernel: [    0.000000] in cpu loop 0 for shared info
> Oct 25 20:52:53 23445LU-PBBFMWY kernel: [    0.718365] in cpu loop 0 computed shared info
>
> Oct 25 20:41:27 23445LU-PBBFMWY kernel: [    0.000000] in cpu loop 0 for shared info
> Oct 25 20:41:27 23445LU-PBBFMWY kernel: [    0.671690] in cpu loop 0 computed shared info
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 19:35:48 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 19:35:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRpgm-0001aW-31; Fri, 26 Oct 2012 19:35:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRpgk-0001aR-8F
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 19:35:26 +0000
Received: from [85.158.138.51:28168] by server-1.bemta-3.messagelabs.com id
	11/28-31728-DF5EA805; Fri, 26 Oct 2012 19:35:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1351280123!18690626!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29493 invoked from network); 26 Oct 2012 19:35:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 19:35:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15419703"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 19:35:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 26 Oct 2012 20:35:22 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TRpgg-0001xM-J9;
	Fri, 26 Oct 2012 19:35:22 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TRpgg-0006iV-EC;
	Fri, 26 Oct 2012 20:35:22 +0100
To: 
Message-ID: 
From: xen.org 
Date: Fri, 26 Oct 2012 20:35:22 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 14084: trouble: broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14084 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14084/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  3 host-install(3)         broken REGR. vs. 13919
 test-i386-i386-win            3 host-install(3)         broken REGR. vs. 13919
 test-amd64-i386-win           3 host-install(3)         broken REGR. vs. 13919
 test-i386-i386-xl             3 host-install(3)         broken REGR. vs. 13919
 test-amd64-amd64-xl-qemuu-win7-amd64  3 host-install(3) broken REGR. vs. 13919
 test-amd64-i386-xl-win-vcpus1  3 host-install(3)        broken REGR. vs. 13919
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3)   broken REGR. vs. 13919
 test-amd64-i386-xl-win7-amd64  3 host-install(3)        broken REGR. vs. 13919
 test-i386-i386-pv             3 host-install(3)         broken REGR. vs. 13919
 test-amd64-amd64-xl-win7-amd64  3 host-install(3)       broken REGR. vs. 13919
 test-amd64-i386-xl-multivcpu  3 host-install(3)         broken REGR. vs. 13919
 test-amd64-amd64-pv           3 host-install(3)         broken REGR. vs. 13919
 test-amd64-amd64-win          3 host-install(3)         broken REGR. vs. 13919
 test-i386-i386-xl-winxpsp3    3 host-install(3)         broken REGR. vs. 13919
 test-amd64-i386-pv            3 host-install(3)         broken REGR. vs. 13919
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 13919
 test-amd64-amd64-xl-win       3 host-install(3)         broken REGR. vs. 13919
 test-amd64-i386-xend-winxpsp3  3 host-install(3)        broken REGR. vs. 13919
 test-amd64-amd64-xl-winxpsp3  3 host-install(3)         broken REGR. vs. 13919
 test-amd64-i386-xl            3 host-install(3)         broken REGR. vs. 13919
 test-amd64-i386-xl-winxpsp3-vcpus1  3 host-install(3)   broken REGR. vs. 13919
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)       broken REGR. vs. 13919
 test-i386-i386-xl-qemuu-winxpsp3  3 host-install(3)     broken REGR. vs. 13919
 test-amd64-i386-win-vcpus1    3 host-install(3)         broken REGR. vs. 13919
 test-amd64-i386-pair         4 host-install/dst_host(4) broken REGR. vs. 13919
 test-amd64-i386-pair         3 host-install/src_host(3) broken REGR. vs. 13919
 test-amd64-amd64-pair        3 host-install/src_host(3) broken REGR. vs. 13919
 test-amd64-amd64-pair        4 host-install/dst_host(4) broken REGR. vs. 13919
 test-i386-i386-pair          4 host-install/dst_host(4) broken REGR. vs. 13919
 test-i386-i386-pair          3 host-install/src_host(3) broken REGR. vs. 13919

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      3 host-install(3)         broken REGR. vs. 13919
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)         broken REGR. vs. 13919
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)      broken REGR. vs. 13919

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass

version targeted for testing:
 xen                  69d1cc78a5bd
baseline version:
 xen                  a15596a619ed

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           broken  
 test-i386-i386-xl                                            broken  
 test-amd64-i386-rhel6hvm-amd                                 broken  
 test-amd64-i386-qemuu-rhel6hvm-amd                           broken  
 test-amd64-amd64-xl-qemuu-win7-amd64                         broken  
 test-amd64-amd64-xl-win7-amd64                               broken  
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        broken  
 test-amd64-i386-pair                                         broken  
 test-i386-i386-pair                                          broken  
 test-amd64-amd64-xl-sedf-pin                                 broken  
 test-amd64-amd64-pv                                          broken  
 test-amd64-i386-pv                                           broken  
 test-i386-i386-pv                                            broken  
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   broken  
 test-amd64-i386-xl-win-vcpus1                                broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           broken  
 test-amd64-amd64-win                                         broken  
 test-amd64-i386-win                                          broken  
 test-i386-i386-win                                           broken  
 test-amd64-amd64-xl-win                                      broken  
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             broken  
 test-amd64-i386-xend-winxpsp3                                broken  
 test-amd64-amd64-xl-winxpsp3                                 broken  
 test-i386-i386-xl-winxpsp3                                   broken  


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   23385:69d1cc78a5bd
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:10:04 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    [ Includes 25589:60f09d1ab1fe for CVE-2012-2625 ]
    
    
changeset:   23384:a15596a619ed
user:        Daniel De Graaf 
date:        Thu Oct 04 10:44:43 2012 +0200
    
    x86: check remote MMIO remap permissions
    
    When a domain is mapping pages from a different pg_owner domain, the
    iomem_access checks are currently only applied to the pg_owner domain,
    potentially allowing a domain with a more restrictive iomem_access
    policy to have the pages mapped into its page tables. To catch this,
    also check the owner of the page tables. The current domain does not
    need to be checked because the ability to manipulate a domain's page
    tables implies full access to the target domain, so checking that
    domain's permission is sufficient.
    
    Signed-off-by: Daniel De Graaf 
    Acked-by: Jan Beulich 
    xen-unstable changeset: 25952:8278d7d8fa48
    xen-unstable date: Wed Sep 26 09:56:07 UTC 2012
    
    
========================================
commit d7d453f51459b591faa96d1c123b5bfff7c5b6b6
Author: Ian Jackson 
Date:   Thu Sep 6 17:05:30 2012 +0100

    Disable qemu monitor by default.  The qemu monitor is an overly
    powerful feature which must be protected from untrusted (guest)
    administrators.
    
    Neither xl nor xend expect qemu to produce this monitor unless it is
    explicitly requested.
    
    This is a security problem, XSA-19.  Previously it was CVE-2007-0998
    in Red Hat but we haven't dealt with it in upstream.  We hope to have
    a new CVE for it here but we don't have one yet.
    
    Signed-off-by: Ian Jackson 
    (cherry picked from commit bacc0d302445c75f18f4c826750fb5853b60e7ca)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 19:35:48 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 19:35:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRpgm-0001aW-31; Fri, 26 Oct 2012 19:35:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRpgk-0001aR-8F
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 19:35:26 +0000
Received: from [85.158.138.51:28168] by server-1.bemta-3.messagelabs.com id
	11/28-31728-DF5EA805; Fri, 26 Oct 2012 19:35:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1351280123!18690626!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29493 invoked from network); 26 Oct 2012 19:35:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 19:35:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15419703"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 19:35:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 26 Oct 2012 20:35:22 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TRpgg-0001xM-J9;
	Fri, 26 Oct 2012 19:35:22 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TRpgg-0006iV-EC;
	Fri, 26 Oct 2012 20:35:22 +0100
To: 
Message-ID: 
From: xen.org 
Date: Fri, 26 Oct 2012 20:35:22 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 14084: trouble: broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14084 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14084/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  3 host-install(3)         broken REGR. vs. 13919
 test-i386-i386-win            3 host-install(3)         broken REGR. vs. 13919
 test-amd64-i386-win           3 host-install(3)         broken REGR. vs. 13919
 test-i386-i386-xl             3 host-install(3)         broken REGR. vs. 13919
 test-amd64-amd64-xl-qemuu-win7-amd64  3 host-install(3) broken REGR. vs. 13919
 test-amd64-i386-xl-win-vcpus1  3 host-install(3)        broken REGR. vs. 13919
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3)   broken REGR. vs. 13919
 test-amd64-i386-xl-win7-amd64  3 host-install(3)        broken REGR. vs. 13919
 test-i386-i386-pv             3 host-install(3)         broken REGR. vs. 13919
 test-amd64-amd64-xl-win7-amd64  3 host-install(3)       broken REGR. vs. 13919
 test-amd64-i386-xl-multivcpu  3 host-install(3)         broken REGR. vs. 13919
 test-amd64-amd64-pv           3 host-install(3)         broken REGR. vs. 13919
 test-amd64-amd64-win          3 host-install(3)         broken REGR. vs. 13919
 test-i386-i386-xl-winxpsp3    3 host-install(3)         broken REGR. vs. 13919
 test-amd64-i386-pv            3 host-install(3)         broken REGR. vs. 13919
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 13919
 test-amd64-amd64-xl-win       3 host-install(3)         broken REGR. vs. 13919
 test-amd64-i386-xend-winxpsp3  3 host-install(3)        broken REGR. vs. 13919
 test-amd64-amd64-xl-winxpsp3  3 host-install(3)         broken REGR. vs. 13919
 test-amd64-i386-xl            3 host-install(3)         broken REGR. vs. 13919
 test-amd64-i386-xl-winxpsp3-vcpus1  3 host-install(3)   broken REGR. vs. 13919
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)       broken REGR. vs. 13919
 test-i386-i386-xl-qemuu-winxpsp3  3 host-install(3)     broken REGR. vs. 13919
 test-amd64-i386-win-vcpus1    3 host-install(3)         broken REGR. vs. 13919
 test-amd64-i386-pair         4 host-install/dst_host(4) broken REGR. vs. 13919
 test-amd64-i386-pair         3 host-install/src_host(3) broken REGR. vs. 13919
 test-amd64-amd64-pair        3 host-install/src_host(3) broken REGR. vs. 13919
 test-amd64-amd64-pair        4 host-install/dst_host(4) broken REGR. vs. 13919
 test-i386-i386-pair          4 host-install/dst_host(4) broken REGR. vs. 13919
 test-i386-i386-pair          3 host-install/src_host(3) broken REGR. vs. 13919

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      3 host-install(3)         broken REGR. vs. 13919
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)         broken REGR. vs. 13919
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)      broken REGR. vs. 13919

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass

version targeted for testing:
 xen                  69d1cc78a5bd
baseline version:
 xen                  a15596a619ed

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           broken  
 test-i386-i386-xl                                            broken  
 test-amd64-i386-rhel6hvm-amd                                 broken  
 test-amd64-i386-qemuu-rhel6hvm-amd                           broken  
 test-amd64-amd64-xl-qemuu-win7-amd64                         broken  
 test-amd64-amd64-xl-win7-amd64                               broken  
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        broken  
 test-amd64-i386-pair                                         broken  
 test-i386-i386-pair                                          broken  
 test-amd64-amd64-xl-sedf-pin                                 broken  
 test-amd64-amd64-pv                                          broken  
 test-amd64-i386-pv                                           broken  
 test-i386-i386-pv                                            broken  
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   broken  
 test-amd64-i386-xl-win-vcpus1                                broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           broken  
 test-amd64-amd64-win                                         broken  
 test-amd64-i386-win                                          broken  
 test-i386-i386-win                                           broken  
 test-amd64-amd64-xl-win                                      broken  
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             broken  
 test-amd64-i386-xend-winxpsp3                                broken  
 test-amd64-amd64-xl-winxpsp3                                 broken  
 test-i386-i386-xl-winxpsp3                                   broken  


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   23385:69d1cc78a5bd
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:10:04 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    [ Includes 25589:60f09d1ab1fe for CVE-2012-2625 ]
    
    
changeset:   23384:a15596a619ed
user:        Daniel De Graaf 
date:        Thu Oct 04 10:44:43 2012 +0200
    
    x86: check remote MMIO remap permissions
    
    When a domain is mapping pages from a different pg_owner domain, the
    iomem_access checks are currently only applied to the pg_owner domain,
    potentially allowing a domain with a more restrictive iomem_access
    policy to have the pages mapped into its page tables. To catch this,
    also check the owner of the page tables. The current domain does not
    need to be checked because the ability to manipulate a domain's page
    tables implies full access to the target domain, so checking that
    domain's permission is sufficient.
    
    Signed-off-by: Daniel De Graaf 
    Acked-by: Jan Beulich 
    xen-unstable changeset: 25952:8278d7d8fa48
    xen-unstable date: Wed Sep 26 09:56:07 UTC 2012
    
    
========================================
commit d7d453f51459b591faa96d1c123b5bfff7c5b6b6
Author: Ian Jackson 
Date:   Thu Sep 6 17:05:30 2012 +0100

    Disable qemu monitor by default.  The qemu monitor is an overly
    powerful feature which must be protected from untrusted (guest)
    administrators.
    
    Neither xl nor xend expect qemu to produce this monitor unless it is
    explicitly requested.
    
    This is a security problem, XSA-19.  Previously it was CVE-2007-0998
    in Red Hat but we haven't dealt with it in upstream.  We hope to have
    a new CVE for it here but we don't have one yet.
    
    Signed-off-by: Ian Jackson 
    (cherry picked from commit bacc0d302445c75f18f4c826750fb5853b60e7ca)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 19:36:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 19:36:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRphF-0001c5-GL; Fri, 26 Oct 2012 19:35:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRphE-0001bu-PA
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 19:35:57 +0000
Received: from [85.158.138.51:49776] by server-12.bemta-3.messagelabs.com id
	08/B9-27853-B16EA805; Fri, 26 Oct 2012 19:35:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1351280154!27651405!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27005 invoked from network); 26 Oct 2012 19:35:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 19:35:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15419706"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 19:35:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 26 Oct 2012 20:35:54 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TRphC-0001xY-Ay;
	Fri, 26 Oct 2012 19:35:54 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TRphC-0007x3-7p;
	Fri, 26 Oct 2012 20:35:54 +0100
To: 
Message-ID: 
From: xen.org 
Date: Fri, 26 Oct 2012 20:35:54 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14088: trouble: blocked/broken
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14088 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14088/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   2 host-install(2)         broken REGR. vs. 14079
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 14079
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 14079
 build-i386-pvops              2 host-install(2)         broken REGR. vs. 14079
 build-i386-oldkern            2 host-install(2)         broken REGR. vs. 14079
 build-i386                    2 host-install(2)         broken REGR. vs. 14079

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a

version targeted for testing:
 xen                  37a8946eeb9d
baseline version:
 xen                  c26e1a79fe77

------------------------------------------------------------
People who touched revisions under test:
  Charles Arnold 
  Christoph Egger 
  Ian Campbell 
  Ian Jackson 
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           broken  
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             broken  
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26115:37a8946eeb9d
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:09:29 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    
    
changeset:   26114:6f9e46917eb8
user:        Charles Arnold 
date:        Fri Oct 26 12:05:08 2012 +0100
    
    pygrub: Add option to list grub entries
    
    The argument to "--entry" allows 2 syntaxes, either directly the entry
    number in menu.lst, or the whole string behind the "title" key word.
    This poses the following issue:
    
    From Dom0 there is no way to guess the number and, or the complete
    title string because this string contains the kernel version, which
    will change with a kernel update.
    
    This patch adds [-l|--list-entries] as an argument to pygrub.
    
    Signed-off-by: Charles Arnold 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26113:03af0abd2b72
user:        Ian Campbell 
date:        Fri Oct 26 12:03:12 2012 +0100
    
    xl: Do not leak events when a domain exits.
    
    The goto in both of these places misses the event free which would
    normally clean up.
    
    ==8655== 80 bytes in 1 blocks are definitely lost in loss record 1 of 1
    ==8655==    at 0x4024370: calloc (vg_replace_malloc.c:593)
    ==8655==    by 0x406EAAE: libxl__zalloc (libxl_internal.c:83)
    ==8655==    by 0x4078173: libxl__event_new (libxl_event.c:1167)
    ==8655==    by 0x4056373: domain_death_occurred (libxl.c:958)
    ==8655==    by 0x4058D06: domain_death_xswatch_callback (libxl.c:1038)
    ==8655==    by 0x4078EB5: watchfd_callback (libxl_event.c:458)
    ==8655==    by 0x407839E: afterpoll_internal (libxl_event.c:949)
    ==8655==    by 0x4079142: eventloop_iteration (libxl_event.c:1371)
    ==8655==    by 0x40799BB: libxl_event_wait (libxl_event.c:1396)
    ==8655==    by 0x805CC67: create_domain (xl_cmdimpl.c:1698)
    ==8655==    by 0x805E001: main_create (xl_cmdimpl.c:3986)
    ==8655==    by 0x804D43D: main (xl.c:285)
    
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26112:d07692b5c780
user:        Ian Jackson 
date:        Fri Oct 26 11:39:42 2012 +0100
    
    Revert 26109:6ccfe4d29f95
    
    This changeset was contaminated by changes hanging around in my
    working tree.  Sorry :-(.
    
    Signed-off-by: Ian Jackson 
    
    
changeset:   26111:c26e1a79fe77
user:        Christoph Egger 
date:        Thu Oct 25 17:12:55 2012 +0100
    
    libxl: NetBSD PCI passthrough support
    
    Add PCI passthrough support for HVM guests.
    
    Signed-off-by: Christoph Egger 
    Committed-by: Ian Jackson 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 19:36:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 19:36:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRphF-0001c5-GL; Fri, 26 Oct 2012 19:35:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRphE-0001bu-PA
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 19:35:57 +0000
Received: from [85.158.138.51:49776] by server-12.bemta-3.messagelabs.com id
	08/B9-27853-B16EA805; Fri, 26 Oct 2012 19:35:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1351280154!27651405!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27005 invoked from network); 26 Oct 2012 19:35:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 19:35:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="15419706"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 19:35:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 26 Oct 2012 20:35:54 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TRphC-0001xY-Ay;
	Fri, 26 Oct 2012 19:35:54 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TRphC-0007x3-7p;
	Fri, 26 Oct 2012 20:35:54 +0100
To: 
Message-ID: 
From: xen.org 
Date: Fri, 26 Oct 2012 20:35:54 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14088: trouble: blocked/broken
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14088 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14088/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   2 host-install(2)         broken REGR. vs. 14079
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 14079
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 14079
 build-i386-pvops              2 host-install(2)         broken REGR. vs. 14079
 build-i386-oldkern            2 host-install(2)         broken REGR. vs. 14079
 build-i386                    2 host-install(2)         broken REGR. vs. 14079

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a

version targeted for testing:
 xen                  37a8946eeb9d
baseline version:
 xen                  c26e1a79fe77

------------------------------------------------------------
People who touched revisions under test:
  Charles Arnold 
  Christoph Egger 
  Ian Campbell 
  Ian Jackson 
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           broken  
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             broken  
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26115:37a8946eeb9d
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:09:29 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    
    
changeset:   26114:6f9e46917eb8
user:        Charles Arnold 
date:        Fri Oct 26 12:05:08 2012 +0100
    
    pygrub: Add option to list grub entries
    
    The argument to "--entry" allows 2 syntaxes, either directly the entry
    number in menu.lst, or the whole string behind the "title" key word.
    This poses the following issue:
    
    From Dom0 there is no way to guess the number and, or the complete
    title string because this string contains the kernel version, which
    will change with a kernel update.
    
    This patch adds [-l|--list-entries] as an argument to pygrub.
    
    Signed-off-by: Charles Arnold 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26113:03af0abd2b72
user:        Ian Campbell 
date:        Fri Oct 26 12:03:12 2012 +0100
    
    xl: Do not leak events when a domain exits.
    
    The goto in both of these places misses the event free which would
    normally clean up.
    
    ==8655== 80 bytes in 1 blocks are definitely lost in loss record 1 of 1
    ==8655==    at 0x4024370: calloc (vg_replace_malloc.c:593)
    ==8655==    by 0x406EAAE: libxl__zalloc (libxl_internal.c:83)
    ==8655==    by 0x4078173: libxl__event_new (libxl_event.c:1167)
    ==8655==    by 0x4056373: domain_death_occurred (libxl.c:958)
    ==8655==    by 0x4058D06: domain_death_xswatch_callback (libxl.c:1038)
    ==8655==    by 0x4078EB5: watchfd_callback (libxl_event.c:458)
    ==8655==    by 0x407839E: afterpoll_internal (libxl_event.c:949)
    ==8655==    by 0x4079142: eventloop_iteration (libxl_event.c:1371)
    ==8655==    by 0x40799BB: libxl_event_wait (libxl_event.c:1396)
    ==8655==    by 0x805CC67: create_domain (xl_cmdimpl.c:1698)
    ==8655==    by 0x805E001: main_create (xl_cmdimpl.c:3986)
    ==8655==    by 0x804D43D: main (xl.c:285)
    
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26112:d07692b5c780
user:        Ian Jackson 
date:        Fri Oct 26 11:39:42 2012 +0100
    
    Revert 26109:6ccfe4d29f95
    
    This changeset was contaminated by changes hanging around in my
    working tree.  Sorry :-(.
    
    Signed-off-by: Ian Jackson 
    
    
changeset:   26111:c26e1a79fe77
user:        Christoph Egger 
date:        Thu Oct 25 17:12:55 2012 +0100
    
    libxl: NetBSD PCI passthrough support
    
    Add PCI passthrough support for HVM guests.
    
    Signed-off-by: Christoph Egger 
    Committed-by: Ian Jackson 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 19:49:06 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 19:49:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRptZ-0001yb-4j; Fri, 26 Oct 2012 19:48:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRptX-0001yW-D1
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 19:48:39 +0000
Received: from [85.158.139.211:28940] by server-6.bemta-5.messagelabs.com id
	22/D7-32589-619EA805; Fri, 26 Oct 2012 19:48:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1351280917!23838779!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16064 invoked from network); 26 Oct 2012 19:48:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 19:48:38 -0000
X-IronPort-AV: E=Sophos;i="4.80,656,1344211200"; d="scan'208";a="15419798"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 19:48:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 26 Oct 2012 20:48:37 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TRptV-000237-DO;
	Fri, 26 Oct 2012 19:48:37 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TRptV-0000mx-Am;
	Fri, 26 Oct 2012 20:48:37 +0100
To: 
Message-ID: 
From: xen.org 
Date: Fri, 26 Oct 2012 20:48:37 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 14089: trouble: blocked/broken
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14089 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14089/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386                    2 host-install(2)         broken REGR. vs. 13919
 build-amd64                   2 host-install(2)         broken REGR. vs. 13919
 build-i386-pvops              2 host-install(2)         broken REGR. vs. 13919
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 13919
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13919
 build-i386-oldkern            2 host-install(2)         broken REGR. vs. 13919

Tests which did not succeed, but are not blocking:
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 xen                  69d1cc78a5bd
baseline version:
 xen                  a15596a619ed

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           broken  
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             broken  
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   23385:69d1cc78a5bd
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:10:04 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    [ Includes 25589:60f09d1ab1fe for CVE-2012-2625 ]
    
    
changeset:   23384:a15596a619ed
user:        Daniel De Graaf 
date:        Thu Oct 04 10:44:43 2012 +0200
    
    x86: check remote MMIO remap permissions
    
    When a domain is mapping pages from a different pg_owner domain, the
    iomem_access checks are currently only applied to the pg_owner domain,
    potentially allowing a domain with a more restrictive iomem_access
    policy to have the pages mapped into its page tables. To catch this,
    also check the owner of the page tables. The current domain does not
    need to be checked because the ability to manipulate a domain's page
    tables implies full access to the target domain, so checking that
    domain's permission is sufficient.
    
    Signed-off-by: Daniel De Graaf 
    Acked-by: Jan Beulich 
    xen-unstable changeset: 25952:8278d7d8fa48
    xen-unstable date: Wed Sep 26 09:56:07 UTC 2012
    
    
========================================
commit d7d453f51459b591faa96d1c123b5bfff7c5b6b6
Author: Ian Jackson 
Date:   Thu Sep 6 17:05:30 2012 +0100

    Disable qemu monitor by default.  The qemu monitor is an overly
    powerful feature which must be protected from untrusted (guest)
    administrators.
    
    Neither xl nor xend expect qemu to produce this monitor unless it is
    explicitly requested.
    
    This is a security problem, XSA-19.  Previously it was CVE-2007-0998
    in Red Hat but we haven't dealt with it in upstream.  We hope to have
    a new CVE for it here but we don't have one yet.
    
    Signed-off-by: Ian Jackson 
    (cherry picked from commit bacc0d302445c75f18f4c826750fb5853b60e7ca)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 19:49:06 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 19:49:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRptZ-0001yb-4j; Fri, 26 Oct 2012 19:48:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRptX-0001yW-D1
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 19:48:39 +0000
Received: from [85.158.139.211:28940] by server-6.bemta-5.messagelabs.com id
	22/D7-32589-619EA805; Fri, 26 Oct 2012 19:48:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1351280917!23838779!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16064 invoked from network); 26 Oct 2012 19:48:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 19:48:38 -0000
X-IronPort-AV: E=Sophos;i="4.80,656,1344211200"; d="scan'208";a="15419798"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 19:48:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 26 Oct 2012 20:48:37 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TRptV-000237-DO;
	Fri, 26 Oct 2012 19:48:37 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TRptV-0000mx-Am;
	Fri, 26 Oct 2012 20:48:37 +0100
To: 
Message-ID: 
From: xen.org 
Date: Fri, 26 Oct 2012 20:48:37 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 14089: trouble: blocked/broken
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14089 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14089/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386                    2 host-install(2)         broken REGR. vs. 13919
 build-amd64                   2 host-install(2)         broken REGR. vs. 13919
 build-i386-pvops              2 host-install(2)         broken REGR. vs. 13919
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 13919
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13919
 build-i386-oldkern            2 host-install(2)         broken REGR. vs. 13919

Tests which did not succeed, but are not blocking:
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 xen                  69d1cc78a5bd
baseline version:
 xen                  a15596a619ed

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           broken  
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             broken  
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   23385:69d1cc78a5bd
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:10:04 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    [ Includes 25589:60f09d1ab1fe for CVE-2012-2625 ]
    
    
changeset:   23384:a15596a619ed
user:        Daniel De Graaf 
date:        Thu Oct 04 10:44:43 2012 +0200
    
    x86: check remote MMIO remap permissions
    
    When a domain is mapping pages from a different pg_owner domain, the
    iomem_access checks are currently only applied to the pg_owner domain,
    potentially allowing a domain with a more restrictive iomem_access
    policy to have the pages mapped into its page tables. To catch this,
    also check the owner of the page tables. The current domain does not
    need to be checked because the ability to manipulate a domain's page
    tables implies full access to the target domain, so checking that
    domain's permission is sufficient.
    
    Signed-off-by: Daniel De Graaf 
    Acked-by: Jan Beulich 
    xen-unstable changeset: 25952:8278d7d8fa48
    xen-unstable date: Wed Sep 26 09:56:07 UTC 2012
    
    
========================================
commit d7d453f51459b591faa96d1c123b5bfff7c5b6b6
Author: Ian Jackson 
Date:   Thu Sep 6 17:05:30 2012 +0100

    Disable qemu monitor by default.  The qemu monitor is an overly
    powerful feature which must be protected from untrusted (guest)
    administrators.
    
    Neither xl nor xend expect qemu to produce this monitor unless it is
    explicitly requested.
    
    This is a security problem, XSA-19.  Previously it was CVE-2007-0998
    in Red Hat but we haven't dealt with it in upstream.  We hope to have
    a new CVE for it here but we don't have one yet.
    
    Signed-off-by: Ian Jackson 
    (cherry picked from commit bacc0d302445c75f18f4c826750fb5853b60e7ca)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 20:04:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 20:04:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRq88-0002HR-Ic; Fri, 26 Oct 2012 20:03:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRq86-0002HM-It
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 20:03:42 +0000
Received: from [85.158.143.99:42513] by server-2.bemta-4.messagelabs.com id
	10/38-22268-D9CEA805; Fri, 26 Oct 2012 20:03:41 +0000
X-Env-Sender: davidxu06@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1351281820!26645085!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16842 invoked from network); 26 Oct 2012 20:03:41 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 20:03:41 -0000
Received: by mail-qc0-f173.google.com with SMTP id b12so2063800qca.32
	for ; Fri, 26 Oct 2012 13:03:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=KAmlvloSc6XySz6WaUuvBZBsV71jrdMtVJTqeeSuCew=;
	b=KUjL2r4srGqhLXrcxgMyD6s582IPRQcUm4MDPwGVA0SOgcSpiyG3h2tPdIw1W5LIMm
	opSq7MO/iULlAdAMrVOyrdV0cYWhSnLxqCmd+0069rXfq4FJ4aKxciBpqQ01VGVrrAX9
	16r5/5NRjVENOH+YtW5juK6ICGQszx3rr1KqqQej1m1At71r10OPHXJJ4b2dXJMWcxYI
	hiRkD17iGJz8xAylHxZ3oTnJuNtW+M/g2ORFjFdwm80hgtSEJHhk+nsWzFiRACvdP969
	tfFBE0fD/w4e4ANuMcct/pQcZhbTMzMc/HPetgiLHzSlglRxoa+VxY9LZQTRK8CajDXb
	Dhwg==
MIME-Version: 1.0
Received: by 10.224.33.139 with SMTP id h11mr11735099qad.89.1351281819865;
	Fri, 26 Oct 2012 13:03:39 -0700 (PDT)
Received: by 10.49.1.116 with HTTP; Fri, 26 Oct 2012 13:03:39 -0700 (PDT)
Date: Fri, 26 Oct 2012 16:03:39 -0400
Message-ID: 
From: David Xu 
To: xen-devel@lists.xen.org
Subject: [Xen-devel] get vCPU state from guest kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============4103943401554083404=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4103943401554083404==
Content-Type: multipart/alternative; boundary=20cf3074d2d4dd540104ccfbd0b9

--20cf3074d2d4dd540104ccfbd0b9
Content-Type: text/plain; charset=ISO-8859-1

Hi all,

I am doing a project in which I need get some information of hypervisor in
guest kernel. For example, I need to read the state of each vCPU of current
VM in softirq context of guest OS kernel. Does any body has a idea in it?
How about share_info page? Thanks.

Regards,
Cong

--20cf3074d2d4dd540104ccfbd0b9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi all,

I am doing a project in which I need get some in=
formation of hypervisor in guest kernel. For example, I need to read the st=
ate of each vCPU of current VM in softirq context of guest OS kernel. Does =
any body has a idea in it? How about share_info page? Thanks.



Regards,
Cong


--20cf3074d2d4dd540104ccfbd0b9--


--===============4103943401554083404==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4103943401554083404==--


From xen-devel-bounces@lists.xen.org Fri Oct 26 20:04:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 20:04:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRq88-0002HR-Ic; Fri, 26 Oct 2012 20:03:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRq86-0002HM-It
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 20:03:42 +0000
Received: from [85.158.143.99:42513] by server-2.bemta-4.messagelabs.com id
	10/38-22268-D9CEA805; Fri, 26 Oct 2012 20:03:41 +0000
X-Env-Sender: davidxu06@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1351281820!26645085!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16842 invoked from network); 26 Oct 2012 20:03:41 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 20:03:41 -0000
Received: by mail-qc0-f173.google.com with SMTP id b12so2063800qca.32
	for ; Fri, 26 Oct 2012 13:03:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=KAmlvloSc6XySz6WaUuvBZBsV71jrdMtVJTqeeSuCew=;
	b=KUjL2r4srGqhLXrcxgMyD6s582IPRQcUm4MDPwGVA0SOgcSpiyG3h2tPdIw1W5LIMm
	opSq7MO/iULlAdAMrVOyrdV0cYWhSnLxqCmd+0069rXfq4FJ4aKxciBpqQ01VGVrrAX9
	16r5/5NRjVENOH+YtW5juK6ICGQszx3rr1KqqQej1m1At71r10OPHXJJ4b2dXJMWcxYI
	hiRkD17iGJz8xAylHxZ3oTnJuNtW+M/g2ORFjFdwm80hgtSEJHhk+nsWzFiRACvdP969
	tfFBE0fD/w4e4ANuMcct/pQcZhbTMzMc/HPetgiLHzSlglRxoa+VxY9LZQTRK8CajDXb
	Dhwg==
MIME-Version: 1.0
Received: by 10.224.33.139 with SMTP id h11mr11735099qad.89.1351281819865;
	Fri, 26 Oct 2012 13:03:39 -0700 (PDT)
Received: by 10.49.1.116 with HTTP; Fri, 26 Oct 2012 13:03:39 -0700 (PDT)
Date: Fri, 26 Oct 2012 16:03:39 -0400
Message-ID: 
From: David Xu 
To: xen-devel@lists.xen.org
Subject: [Xen-devel] get vCPU state from guest kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============4103943401554083404=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4103943401554083404==
Content-Type: multipart/alternative; boundary=20cf3074d2d4dd540104ccfbd0b9

--20cf3074d2d4dd540104ccfbd0b9
Content-Type: text/plain; charset=ISO-8859-1

Hi all,

I am doing a project in which I need get some information of hypervisor in
guest kernel. For example, I need to read the state of each vCPU of current
VM in softirq context of guest OS kernel. Does any body has a idea in it?
How about share_info page? Thanks.

Regards,
Cong

--20cf3074d2d4dd540104ccfbd0b9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi all,

I am doing a project in which I need get some in=
formation of hypervisor in guest kernel. For example, I need to read the st=
ate of each vCPU of current VM in softirq context of guest OS kernel. Does =
any body has a idea in it? How about share_info page? Thanks.



Regards,
Cong


--20cf3074d2d4dd540104ccfbd0b9--


--===============4103943401554083404==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4103943401554083404==--


From xen-devel-bounces@lists.xen.org Fri Oct 26 20:04:40 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 20:04:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRq8k-0002LN-W2; Fri, 26 Oct 2012 20:04:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRq8k-0002L3-7F
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 20:04:22 +0000
Received: from [85.158.143.35:33740] by server-3.bemta-4.messagelabs.com id
	00/8B-24279-5CCEA805; Fri, 26 Oct 2012 20:04:21 +0000
X-Env-Sender: hahn@univention.de
X-Msg-Ref: server-2.tower-21.messagelabs.com!1351281860!4721166!1
X-Originating-IP: [82.198.197.8]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24448 invoked from network); 26 Oct 2012 20:04:20 -0000
Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8)
	by server-2.tower-21.messagelabs.com with SMTP;
	26 Oct 2012 20:04:20 -0000
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id 2A4021413891;
	Fri, 26 Oct 2012 22:04:19 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id 1E1931413892;
	Fri, 26 Oct 2012 22:04:19 +0200 (CEST)
X-Virus-Scanned: by amavisd-new-2.6.1 (20080629) (Debian) at knut.univention.de
Received: from mail.univention.de ([127.0.0.1])
	by localhost (slugis.knut.univention.de [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id uNL1gcY6c0V0; Fri, 26 Oct 2012 22:04:18 +0200 (CEST)
Received: from stave.knut.univention.de (mail.univention.de [82.198.197.8])
	by slugis.knut.univention.de (Postfix) with ESMTPSA id 444961413891;
	Fri, 26 Oct 2012 22:04:18 +0200 (CEST)
From: Philipp Hahn 
Organization: Univention.de
To: xen-devel@lists.xen.org
Date: Fri, 26 Oct 2012 22:04:04 +0200
User-Agent: KMail/1.9.10 (enterprise35 20100903.1171286)
References: 
	<17eea5a9a20cc43d7de1.1351098146@makatos-desktop>
	<1351250701.15162.43.camel@zakaz.uk.xensource.com>
In-Reply-To: <1351250701.15162.43.camel@zakaz.uk.xensource.com>
X-KMail-QuotePrefix: > 
MIME-Version: 1.0
Message-Id: <201210262204.16165.hahn@univention.de>
Cc: Ian Campbell 
Subject: Re: [Xen-devel] [PATCH 07 of 16 RFC] blktap3: Introduce blktap3
	top-level Makefile
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============3854536101067521793=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3854536101067521793==
Content-Type: multipart/signed;
  boundary="nextPart2827913.jJTgYiI3eV";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart2827913.jJTgYiI3eV
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hello Ian,

On Friday 26 October 2012 13:25:01 Ian Campbell wrote:
> > +build: ;
>
> What does the ";" in this syntax do?

A Make trick to do (really) nothing:


Sincerely
Philipp
=2D-=20
Philipp Hahn           Open Source Software Engineer      hahn@univention.de
Univention GmbH        be open.                       fon: +49 421 22 232- 0
Mary-Somerville-Str.1  D-28359 Bremen                 fax: +49 421 22 232-99
                                                   http://www.univention.de/

--nextPart2827913.jJTgYiI3eV
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAlCK7LUACgkQYPlgoZpUDjkZlwCfW32ThnIGCPqOXYD3P7y2lZdL
risAn3IxUJTNsSXqTfnUVqbuDm67BEHB
=758a
-----END PGP SIGNATURE-----

--nextPart2827913.jJTgYiI3eV--


--===============3854536101067521793==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3854536101067521793==--


From xen-devel-bounces@lists.xen.org Fri Oct 26 20:04:40 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 20:04:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRq8k-0002LN-W2; Fri, 26 Oct 2012 20:04:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRq8k-0002L3-7F
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 20:04:22 +0000
Received: from [85.158.143.35:33740] by server-3.bemta-4.messagelabs.com id
	00/8B-24279-5CCEA805; Fri, 26 Oct 2012 20:04:21 +0000
X-Env-Sender: hahn@univention.de
X-Msg-Ref: server-2.tower-21.messagelabs.com!1351281860!4721166!1
X-Originating-IP: [82.198.197.8]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24448 invoked from network); 26 Oct 2012 20:04:20 -0000
Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8)
	by server-2.tower-21.messagelabs.com with SMTP;
	26 Oct 2012 20:04:20 -0000
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id 2A4021413891;
	Fri, 26 Oct 2012 22:04:19 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id 1E1931413892;
	Fri, 26 Oct 2012 22:04:19 +0200 (CEST)
X-Virus-Scanned: by amavisd-new-2.6.1 (20080629) (Debian) at knut.univention.de
Received: from mail.univention.de ([127.0.0.1])
	by localhost (slugis.knut.univention.de [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id uNL1gcY6c0V0; Fri, 26 Oct 2012 22:04:18 +0200 (CEST)
Received: from stave.knut.univention.de (mail.univention.de [82.198.197.8])
	by slugis.knut.univention.de (Postfix) with ESMTPSA id 444961413891;
	Fri, 26 Oct 2012 22:04:18 +0200 (CEST)
From: Philipp Hahn 
Organization: Univention.de
To: xen-devel@lists.xen.org
Date: Fri, 26 Oct 2012 22:04:04 +0200
User-Agent: KMail/1.9.10 (enterprise35 20100903.1171286)
References: 
	<17eea5a9a20cc43d7de1.1351098146@makatos-desktop>
	<1351250701.15162.43.camel@zakaz.uk.xensource.com>
In-Reply-To: <1351250701.15162.43.camel@zakaz.uk.xensource.com>
X-KMail-QuotePrefix: > 
MIME-Version: 1.0
Message-Id: <201210262204.16165.hahn@univention.de>
Cc: Ian Campbell 
Subject: Re: [Xen-devel] [PATCH 07 of 16 RFC] blktap3: Introduce blktap3
	top-level Makefile
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============3854536101067521793=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3854536101067521793==
Content-Type: multipart/signed;
  boundary="nextPart2827913.jJTgYiI3eV";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart2827913.jJTgYiI3eV
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hello Ian,

On Friday 26 October 2012 13:25:01 Ian Campbell wrote:
> > +build: ;
>
> What does the ";" in this syntax do?

A Make trick to do (really) nothing:


Sincerely
Philipp
=2D-=20
Philipp Hahn           Open Source Software Engineer      hahn@univention.de
Univention GmbH        be open.                       fon: +49 421 22 232- 0
Mary-Somerville-Str.1  D-28359 Bremen                 fax: +49 421 22 232-99
                                                   http://www.univention.de/

--nextPart2827913.jJTgYiI3eV
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAlCK7LUACgkQYPlgoZpUDjkZlwCfW32ThnIGCPqOXYD3P7y2lZdL
risAn3IxUJTNsSXqTfnUVqbuDm67BEHB
=758a
-----END PGP SIGNATURE-----

--nextPart2827913.jJTgYiI3eV--


--===============3854536101067521793==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3854536101067521793==--


From xen-devel-bounces@lists.xen.org Fri Oct 26 20:27:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 20:27:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRqUM-0002mi-0u; Fri, 26 Oct 2012 20:26:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRqUK-0002md-Mm
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 20:26:41 +0000
Received: from [85.158.137.99:49813] by server-1.bemta-3.messagelabs.com id
	FA/13-31728-FF1FA805; Fri, 26 Oct 2012 20:26:39 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1351283197!17860187!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgzMzI2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20416 invoked from network); 26 Oct 2012 20:26:38 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Oct 2012 20:26:38 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9QKQVv7002931
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 26 Oct 2012 20:26:32 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9QKQUMb020258
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 26 Oct 2012 20:26:31 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9QKQU4w000658; Fri, 26 Oct 2012 15:26:30 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 26 Oct 2012 13:26:30 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9EEE14042D; Fri, 26 Oct 2012 16:14:09 -0400 (EDT)
Date: Fri, 26 Oct 2012 16:14:09 -0400
From: Konrad Rzeszutek Wilk 
To: "Liu, Jinsong" 
Message-ID: <20121026201409.GF2708@phenom.dumpdata.com>
References: 
	<5089676602000078000A4928@nat28.tlf.novell.com>
	
	<508A89CB020000780008E6ED@nat28.tlf.novell.com>
	
	
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Konrad Rzeszutek Wilk ,
	"linux-kernel@vger.kernel.org" ,
	Jan Beulich ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 1/2] Xen acpi pad implement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 26, 2012 at 02:00:36PM +0000, Liu, Jinsong wrote:
> Updated per Jan's comments.
> 
> Thanks,
> Jinsong
> 
> ===============
> 
> >From e6d4eceba9538c6873f9c970425e65e257fd9bf0 Mon Sep 17 00:00:00 2001
> From: Liu, Jinsong 
> Date: Sat, 27 Oct 2012 05:34:50 +0800
> Subject: [PATCH 1/2] Xen acpi pad implement
> 
> PAD is acpi Processor Aggregator Device which provides a control point
> that enables the platform to perform specific processor configuration
> and control that applies to all processors in the platform.
> 
> This patch is to implement Xen acpi pad logic. When running under Xen
> virt platform, native pad driver would not work. Instead Xen pad driver,
> a self-contained and very thin logic level, would take over acpi pad staff.
> When acpi pad notify OSPM, xen pad logic intercept and parse _PUR object
> and then hypercall to hyervisor for the rest work, say, core parking.
> 
> Signed-off-by: Liu, Jinsong 
> ---
>  drivers/xen/Makefile             |    1 +
>  drivers/xen/xen_acpi_pad.c       |  201 ++++++++++++++++++++++++++++++++++++++
>  include/xen/interface/platform.h |   17 +++
>  3 files changed, 219 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/xen/xen_acpi_pad.c
> 
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index 0e86370..a2af622 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -29,6 +29,7 @@ obj-$(CONFIG_XEN_MCE_LOG)		+= mcelog.o
>  obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+= xen-pciback/
>  obj-$(CONFIG_XEN_PRIVCMD)		+= xen-privcmd.o
>  obj-$(CONFIG_XEN_ACPI_PROCESSOR)	+= xen-acpi-processor.o
> +obj-$(CONFIG_XEN_DOM0)			+= xen_acpi_pad.o

We should have a Kconfig option. In it, please mention what
version of hypervisor supports this functionality.

>  xen-evtchn-y				:= evtchn.o
>  xen-gntdev-y				:= gntdev.o
>  xen-gntalloc-y				:= gntalloc.o
> diff --git a/drivers/xen/xen_acpi_pad.c b/drivers/xen/xen_acpi_pad.c
> new file mode 100644
> index 0000000..0f1a1e6
> --- /dev/null
> +++ b/drivers/xen/xen_acpi_pad.c
> @@ -0,0 +1,201 @@
> +/*
> + * xen_acpi_pad.c - Xen pad interface
> + *
> + * Copyright (c) 2012, Intel Corporation.
> + *    Author: Liu, Jinsong 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#if defined(CONFIG_ACPI_PROCESSOR_AGGREGATOR) || \
> +		defined(CONFIG_ACPI_PROCESSOR_AGGREGATOR_MODULE)

I don't think you need that.

> +
> +#define ACPI_PROCESSOR_AGGREGATOR_CLASS	"acpi_pad"
> +#define ACPI_PROCESSOR_AGGREGATOR_DEVICE_NAME "Processor Aggregator"
> +#define ACPI_PROCESSOR_AGGREGATOR_NOTIFY 0x80
> +
> +static DEFINE_MUTEX(xen_pad_lock);
> +
> +static int xen_pad_set_idle_cpus(int num_cpus)
> +{
> +	struct xen_platform_op op;
> +
> +	if (num_cpus < 0)
> +		return -EINVAL;
> +
> +	/* set cpu nums expected to be idled */
> +	op.cmd = XENPF_core_parking;
> +	op.u.core_parking.type = XEN_CORE_PARKING_SET;
> +	op.u.core_parking.idle_nums = num_cpus;
> +
> +	return HYPERVISOR_dom0_op(&op);
> +}
> +
> +/*
> + * Cannot get idle cpus by using hypercall once (shared with _SET)
> + * because of the characteristic of Xen continue_hypercall_on_cpu
> + */
> +static int xen_pad_get_idle_cpus(void)
> +{
> +	int ret;
> +	struct xen_platform_op op;
> +
> +	/* get cpu nums actually be idled */
> +	op.cmd = XENPF_core_parking;
> +	op.u.core_parking.type = XEN_CORE_PARKING_GET;
> +	ret = HYPERVISOR_dom0_op(&op);
> +	if (ret < 0)
> +		return ret;
> +
> +	return op.u.core_parking.idle_nums;
> +}
> +
> +/*
> + * Query firmware how many CPUs should be idle
> + * return -1 on failure
> + */
> +static int xen_acpi_pad_pur(acpi_handle handle)
> +{
> +	struct acpi_buffer buffer = {ACPI_ALLOCATE_BUFFER, NULL};
> +	union acpi_object *package;
> +	int num = -1;
> +
> +	if (ACPI_FAILURE(acpi_evaluate_object(handle, "_PUR", NULL, &buffer)))
> +		return num;
> +
> +	if (!buffer.length || !buffer.pointer)
> +		return num;
> +
> +	package = buffer.pointer;
> +
> +	if (package->type == ACPI_TYPE_PACKAGE &&
> +		package->package.count == 2 &&
> +		package->package.elements[0].integer.value == 1) /* rev 1 */
> +
> +		num = package->package.elements[1].integer.value;
> +
> +	kfree(buffer.pointer);
> +	return num;
> +}
> +
> +/* Notify firmware how many CPUs are idle */
> +static void xen_acpi_pad_ost(acpi_handle handle, int stat,
> +	uint32_t idle_cpus)
> +{
> +	union acpi_object params[3] = {
> +		{.type = ACPI_TYPE_INTEGER,},
> +		{.type = ACPI_TYPE_INTEGER,},
> +		{.type = ACPI_TYPE_BUFFER,},
> +	};
> +	struct acpi_object_list arg_list = {3, params};
> +
> +	params[0].integer.value = ACPI_PROCESSOR_AGGREGATOR_NOTIFY;
> +	params[1].integer.value =  stat;
> +	params[2].buffer.length = 4;
> +	params[2].buffer.pointer = (void *)&idle_cpus;
> +	acpi_evaluate_object(handle, "_OST", &arg_list, NULL);
> +}
> +
> +static void xen_acpi_pad_handle_notify(acpi_handle handle)
> +{
> +	int num_cpus;
> +
> +	num_cpus = xen_acpi_pad_pur(handle);
> +	if (num_cpus < 0)
> +		return;
> +
> +	mutex_lock(&xen_pad_lock);
> +	if (xen_pad_set_idle_cpus(num_cpus)) {
> +		mutex_unlock(&xen_pad_lock);
> +		return;
> +	}
> +
> +	num_cpus = xen_pad_get_idle_cpus();
> +	if (num_cpus < 0) {
> +		mutex_unlock(&xen_pad_lock);
> +		return;
> +	}
> +	mutex_unlock(&xen_pad_lock);
> +
> +	xen_acpi_pad_ost(handle, 0, num_cpus);
> +}
> +
> +static void xen_acpi_pad_notify(acpi_handle handle, u32 event,
> +	void *data)
> +{
> +	switch (event) {
> +	case ACPI_PROCESSOR_AGGREGATOR_NOTIFY:
> +		xen_acpi_pad_handle_notify(handle);
> +		break;
> +	default:
> +		pr_warn("Unsupported event [0x%x]\n", event);
> +		break;
> +	}
> +}
> +
> +static int xen_acpi_pad_add(struct acpi_device *device)
> +{
> +	acpi_status status;
> +
> +	strcpy(acpi_device_name(device), ACPI_PROCESSOR_AGGREGATOR_DEVICE_NAME);
> +	strcpy(acpi_device_class(device), ACPI_PROCESSOR_AGGREGATOR_CLASS);
> +
> +	status = acpi_install_notify_handler(device->handle,
> +		 ACPI_DEVICE_NOTIFY, xen_acpi_pad_notify, device);
> +	if (ACPI_FAILURE(status))
> +		return -ENODEV;
> +
> +	return 0;
> +}
> +
> +static int xen_acpi_pad_remove(struct acpi_device *device,
> +	int type)
> +{
> +	mutex_lock(&xen_pad_lock);
> +	xen_pad_set_idle_cpus(0);
> +	mutex_unlock(&xen_pad_lock);
> +
> +	acpi_remove_notify_handler(device->handle,
> +		ACPI_DEVICE_NOTIFY, xen_acpi_pad_notify);
> +	return 0;
> +}
> +
> +static const struct acpi_device_id pad_device_ids[] = {
> +	{"ACPI000C", 0},
> +	{"", 0},
> +};
> +
> +static struct acpi_driver xen_acpi_pad_driver = {
> +	.name = "processor_aggregator",
> +	.class = ACPI_PROCESSOR_AGGREGATOR_CLASS,
> +	.ids = pad_device_ids,
> +	.ops = {
> +		.add = xen_acpi_pad_add,
> +		.remove = xen_acpi_pad_remove,
> +	},
> +};
> +
> +static int __init xen_acpi_pad_init(void)
> +{
> +	/* Only DOM0 is responsible for Xen acpi pad */
> +	if (xen_initial_domain())
> +		return acpi_bus_register_driver(&xen_acpi_pad_driver);
> +
> +	return -ENODEV;
> +}
> +subsys_initcall(xen_acpi_pad_init);


No way of making this a module? It would be nice - perhaps have a stub
function that registers the bus but does not do anything until this
proper module is loaded?

> +
> +#endif
> diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h
> index 4755b5f..0f44376 100644
> --- a/include/xen/interface/platform.h
> +++ b/include/xen/interface/platform.h
> @@ -324,6 +324,22 @@ struct xenpf_cpu_ol {
>  };
>  DEFINE_GUEST_HANDLE_STRUCT(xenpf_cpu_ol);
>  
> +/*
> + * CMD 58 and 59 are reserved for cpu hotadd and memory hotadd,
> + * which already occupied at Xen hypervisor side.
           ^- are

> + */
> +#define XENPF_core_parking	60
> +struct xenpf_core_parking {
> +	/* IN variables */
> +#define XEN_CORE_PARKING_SET	1
> +#define XEN_CORE_PARKING_GET	2
> +	uint32_t type;
> +	/* IN variables:  set cpu nums expected to be idled */
> +	/* OUT variables: get cpu nums actually be idled */
> +	uint32_t idle_nums;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xenpf_core_parking);
> +
>  struct xen_platform_op {
>  	uint32_t cmd;
>  	uint32_t interface_version; /* XENPF_INTERFACE_VERSION */
> @@ -341,6 +357,7 @@ struct xen_platform_op {
>  		struct xenpf_set_processor_pminfo set_pminfo;
>  		struct xenpf_pcpuinfo          pcpu_info;
>  		struct xenpf_cpu_ol            cpu_ol;
> +		struct xenpf_core_parking      core_parking;
>  		uint8_t                        pad[128];
>  	} u;
>  };
> -- 
> 1.7.1



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 20:27:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 20:27:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRqUM-0002mi-0u; Fri, 26 Oct 2012 20:26:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRqUK-0002md-Mm
	for xen-devel@lists.xen.org; Fri, 26 Oct 2012 20:26:41 +0000
Received: from [85.158.137.99:49813] by server-1.bemta-3.messagelabs.com id
	FA/13-31728-FF1FA805; Fri, 26 Oct 2012 20:26:39 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1351283197!17860187!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgzMzI2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20416 invoked from network); 26 Oct 2012 20:26:38 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Oct 2012 20:26:38 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9QKQVv7002931
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 26 Oct 2012 20:26:32 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9QKQUMb020258
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 26 Oct 2012 20:26:31 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9QKQU4w000658; Fri, 26 Oct 2012 15:26:30 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 26 Oct 2012 13:26:30 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9EEE14042D; Fri, 26 Oct 2012 16:14:09 -0400 (EDT)
Date: Fri, 26 Oct 2012 16:14:09 -0400
From: Konrad Rzeszutek Wilk 
To: "Liu, Jinsong" 
Message-ID: <20121026201409.GF2708@phenom.dumpdata.com>
References: 
	<5089676602000078000A4928@nat28.tlf.novell.com>
	
	<508A89CB020000780008E6ED@nat28.tlf.novell.com>
	
	
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Konrad Rzeszutek Wilk ,
	"linux-kernel@vger.kernel.org" ,
	Jan Beulich ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 1/2] Xen acpi pad implement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 26, 2012 at 02:00:36PM +0000, Liu, Jinsong wrote:
> Updated per Jan's comments.
> 
> Thanks,
> Jinsong
> 
> ===============
> 
> >From e6d4eceba9538c6873f9c970425e65e257fd9bf0 Mon Sep 17 00:00:00 2001
> From: Liu, Jinsong 
> Date: Sat, 27 Oct 2012 05:34:50 +0800
> Subject: [PATCH 1/2] Xen acpi pad implement
> 
> PAD is acpi Processor Aggregator Device which provides a control point
> that enables the platform to perform specific processor configuration
> and control that applies to all processors in the platform.
> 
> This patch is to implement Xen acpi pad logic. When running under Xen
> virt platform, native pad driver would not work. Instead Xen pad driver,
> a self-contained and very thin logic level, would take over acpi pad staff.
> When acpi pad notify OSPM, xen pad logic intercept and parse _PUR object
> and then hypercall to hyervisor for the rest work, say, core parking.
> 
> Signed-off-by: Liu, Jinsong 
> ---
>  drivers/xen/Makefile             |    1 +
>  drivers/xen/xen_acpi_pad.c       |  201 ++++++++++++++++++++++++++++++++++++++
>  include/xen/interface/platform.h |   17 +++
>  3 files changed, 219 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/xen/xen_acpi_pad.c
> 
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index 0e86370..a2af622 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -29,6 +29,7 @@ obj-$(CONFIG_XEN_MCE_LOG)		+= mcelog.o
>  obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+= xen-pciback/
>  obj-$(CONFIG_XEN_PRIVCMD)		+= xen-privcmd.o
>  obj-$(CONFIG_XEN_ACPI_PROCESSOR)	+= xen-acpi-processor.o
> +obj-$(CONFIG_XEN_DOM0)			+= xen_acpi_pad.o

We should have a Kconfig option. In it, please mention what
version of hypervisor supports this functionality.

>  xen-evtchn-y				:= evtchn.o
>  xen-gntdev-y				:= gntdev.o
>  xen-gntalloc-y				:= gntalloc.o
> diff --git a/drivers/xen/xen_acpi_pad.c b/drivers/xen/xen_acpi_pad.c
> new file mode 100644
> index 0000000..0f1a1e6
> --- /dev/null
> +++ b/drivers/xen/xen_acpi_pad.c
> @@ -0,0 +1,201 @@
> +/*
> + * xen_acpi_pad.c - Xen pad interface
> + *
> + * Copyright (c) 2012, Intel Corporation.
> + *    Author: Liu, Jinsong 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#if defined(CONFIG_ACPI_PROCESSOR_AGGREGATOR) || \
> +		defined(CONFIG_ACPI_PROCESSOR_AGGREGATOR_MODULE)

I don't think you need that.

> +
> +#define ACPI_PROCESSOR_AGGREGATOR_CLASS	"acpi_pad"
> +#define ACPI_PROCESSOR_AGGREGATOR_DEVICE_NAME "Processor Aggregator"
> +#define ACPI_PROCESSOR_AGGREGATOR_NOTIFY 0x80
> +
> +static DEFINE_MUTEX(xen_pad_lock);
> +
> +static int xen_pad_set_idle_cpus(int num_cpus)
> +{
> +	struct xen_platform_op op;
> +
> +	if (num_cpus < 0)
> +		return -EINVAL;
> +
> +	/* set cpu nums expected to be idled */
> +	op.cmd = XENPF_core_parking;
> +	op.u.core_parking.type = XEN_CORE_PARKING_SET;
> +	op.u.core_parking.idle_nums = num_cpus;
> +
> +	return HYPERVISOR_dom0_op(&op);
> +}
> +
> +/*
> + * Cannot get idle cpus by using hypercall once (shared with _SET)
> + * because of the characteristic of Xen continue_hypercall_on_cpu
> + */
> +static int xen_pad_get_idle_cpus(void)
> +{
> +	int ret;
> +	struct xen_platform_op op;
> +
> +	/* get cpu nums actually be idled */
> +	op.cmd = XENPF_core_parking;
> +	op.u.core_parking.type = XEN_CORE_PARKING_GET;
> +	ret = HYPERVISOR_dom0_op(&op);
> +	if (ret < 0)
> +		return ret;
> +
> +	return op.u.core_parking.idle_nums;
> +}
> +
> +/*
> + * Query firmware how many CPUs should be idle
> + * return -1 on failure
> + */
> +static int xen_acpi_pad_pur(acpi_handle handle)
> +{
> +	struct acpi_buffer buffer = {ACPI_ALLOCATE_BUFFER, NULL};
> +	union acpi_object *package;
> +	int num = -1;
> +
> +	if (ACPI_FAILURE(acpi_evaluate_object(handle, "_PUR", NULL, &buffer)))
> +		return num;
> +
> +	if (!buffer.length || !buffer.pointer)
> +		return num;
> +
> +	package = buffer.pointer;
> +
> +	if (package->type == ACPI_TYPE_PACKAGE &&
> +		package->package.count == 2 &&
> +		package->package.elements[0].integer.value == 1) /* rev 1 */
> +
> +		num = package->package.elements[1].integer.value;
> +
> +	kfree(buffer.pointer);
> +	return num;
> +}
> +
> +/* Notify firmware how many CPUs are idle */
> +static void xen_acpi_pad_ost(acpi_handle handle, int stat,
> +	uint32_t idle_cpus)
> +{
> +	union acpi_object params[3] = {
> +		{.type = ACPI_TYPE_INTEGER,},
> +		{.type = ACPI_TYPE_INTEGER,},
> +		{.type = ACPI_TYPE_BUFFER,},
> +	};
> +	struct acpi_object_list arg_list = {3, params};
> +
> +	params[0].integer.value = ACPI_PROCESSOR_AGGREGATOR_NOTIFY;
> +	params[1].integer.value =  stat;
> +	params[2].buffer.length = 4;
> +	params[2].buffer.pointer = (void *)&idle_cpus;
> +	acpi_evaluate_object(handle, "_OST", &arg_list, NULL);
> +}
> +
> +static void xen_acpi_pad_handle_notify(acpi_handle handle)
> +{
> +	int num_cpus;
> +
> +	num_cpus = xen_acpi_pad_pur(handle);
> +	if (num_cpus < 0)
> +		return;
> +
> +	mutex_lock(&xen_pad_lock);
> +	if (xen_pad_set_idle_cpus(num_cpus)) {
> +		mutex_unlock(&xen_pad_lock);
> +		return;
> +	}
> +
> +	num_cpus = xen_pad_get_idle_cpus();
> +	if (num_cpus < 0) {
> +		mutex_unlock(&xen_pad_lock);
> +		return;
> +	}
> +	mutex_unlock(&xen_pad_lock);
> +
> +	xen_acpi_pad_ost(handle, 0, num_cpus);
> +}
> +
> +static void xen_acpi_pad_notify(acpi_handle handle, u32 event,
> +	void *data)
> +{
> +	switch (event) {
> +	case ACPI_PROCESSOR_AGGREGATOR_NOTIFY:
> +		xen_acpi_pad_handle_notify(handle);
> +		break;
> +	default:
> +		pr_warn("Unsupported event [0x%x]\n", event);
> +		break;
> +	}
> +}
> +
> +static int xen_acpi_pad_add(struct acpi_device *device)
> +{
> +	acpi_status status;
> +
> +	strcpy(acpi_device_name(device), ACPI_PROCESSOR_AGGREGATOR_DEVICE_NAME);
> +	strcpy(acpi_device_class(device), ACPI_PROCESSOR_AGGREGATOR_CLASS);
> +
> +	status = acpi_install_notify_handler(device->handle,
> +		 ACPI_DEVICE_NOTIFY, xen_acpi_pad_notify, device);
> +	if (ACPI_FAILURE(status))
> +		return -ENODEV;
> +
> +	return 0;
> +}
> +
> +static int xen_acpi_pad_remove(struct acpi_device *device,
> +	int type)
> +{
> +	mutex_lock(&xen_pad_lock);
> +	xen_pad_set_idle_cpus(0);
> +	mutex_unlock(&xen_pad_lock);
> +
> +	acpi_remove_notify_handler(device->handle,
> +		ACPI_DEVICE_NOTIFY, xen_acpi_pad_notify);
> +	return 0;
> +}
> +
> +static const struct acpi_device_id pad_device_ids[] = {
> +	{"ACPI000C", 0},
> +	{"", 0},
> +};
> +
> +static struct acpi_driver xen_acpi_pad_driver = {
> +	.name = "processor_aggregator",
> +	.class = ACPI_PROCESSOR_AGGREGATOR_CLASS,
> +	.ids = pad_device_ids,
> +	.ops = {
> +		.add = xen_acpi_pad_add,
> +		.remove = xen_acpi_pad_remove,
> +	},
> +};
> +
> +static int __init xen_acpi_pad_init(void)
> +{
> +	/* Only DOM0 is responsible for Xen acpi pad */
> +	if (xen_initial_domain())
> +		return acpi_bus_register_driver(&xen_acpi_pad_driver);
> +
> +	return -ENODEV;
> +}
> +subsys_initcall(xen_acpi_pad_init);


No way of making this a module? It would be nice - perhaps have a stub
function that registers the bus but does not do anything until this
proper module is loaded?

> +
> +#endif
> diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h
> index 4755b5f..0f44376 100644
> --- a/include/xen/interface/platform.h
> +++ b/include/xen/interface/platform.h
> @@ -324,6 +324,22 @@ struct xenpf_cpu_ol {
>  };
>  DEFINE_GUEST_HANDLE_STRUCT(xenpf_cpu_ol);
>  
> +/*
> + * CMD 58 and 59 are reserved for cpu hotadd and memory hotadd,
> + * which already occupied at Xen hypervisor side.
           ^- are

> + */
> +#define XENPF_core_parking	60
> +struct xenpf_core_parking {
> +	/* IN variables */
> +#define XEN_CORE_PARKING_SET	1
> +#define XEN_CORE_PARKING_GET	2
> +	uint32_t type;
> +	/* IN variables:  set cpu nums expected to be idled */
> +	/* OUT variables: get cpu nums actually be idled */
> +	uint32_t idle_nums;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xenpf_core_parking);
> +
>  struct xen_platform_op {
>  	uint32_t cmd;
>  	uint32_t interface_version; /* XENPF_INTERFACE_VERSION */
> @@ -341,6 +357,7 @@ struct xen_platform_op {
>  		struct xenpf_set_processor_pminfo set_pminfo;
>  		struct xenpf_pcpuinfo          pcpu_info;
>  		struct xenpf_cpu_ol            cpu_ol;
> +		struct xenpf_core_parking      core_parking;
>  		uint8_t                        pad[128];
>  	} u;
>  };
> -- 
> 1.7.1



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 20:47:50 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 20:47:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRqoP-00037N-26; Fri, 26 Oct 2012 20:47:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRqoO-00037I-Ff
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 20:47:24 +0000
Received: from [193.109.254.147:14408] by server-13.bemta-14.messagelabs.com
	id 0B/92-11239-BD6FA805; Fri, 26 Oct 2012 20:47:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1351284441!8565675!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28459 invoked from network); 26 Oct 2012 20:47:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 20:47:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,656,1344211200"; d="scan'208";a="15420315"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 20:47:20 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 21:47:20 +0100
Message-ID: <1351284440.12176.9.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Fri, 26 Oct 2012 21:47:20 +0100
In-Reply-To: 
References: 
	<1351091027-20740-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1351157246.18035.129.camel@zakaz.uk.xensource.com>
	
	<1351269622.15162.105.camel@zakaz.uk.xensource.com>
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" , "Tim
	\(Xen.org\)" 
Subject: Re: [Xen-devel] [PATCH 1/7] xen/arm: fix rank calculation in
 vgic_vcpu_inject_irq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-26 at 19:42 +0100, Stefano Stabellini wrote:
> I think that the problem is the usage of vgic_irq_rank with registers
> that have 1 bit per interrupt.

That's very plausible indeed.

> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index 3c3983f..92731b6 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -42,13 +42,7 @@
>   */
>  static inline int REG_RANK_NR(int b, uint32_t n)
>  {
> -    switch ( b )
> -    {
> -    case 8: return n >> 3;
> -    case 4: return n >> 2;
> -    case 2: return n >> 1;
> -    default: BUG();
> -    }
> +    return n / b;

All the infrastructure will fall apart if b isn't a power of two, that's
why I used the switch. Can you just add the appropriate case 1 instead?
Probably the bug should be a call to an undefined function to make this
a compile time rather than runtime failure too.

> @@ -577,9 +571,9 @@ struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq)
>  
>  void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)

The changes to this function are all unnecessary, since it was already
consistent within itself. If you want to change it please add a helper
which takes an irq and hides the shifts.

I'd be inclined to rename the existing vgic_irq_rank to vgic_reg_rank
and then call the new helper vgic_irq_rank since that would better
reflect the purpose of both.

>  {
> -    int idx = irq >> 2, byte = irq & 0x3;
> +    int byte = irq & 0x3;

byte isn't actually needed either.

>      uint8_t priority;
> -    struct vgic_irq_rank *rank = vgic_irq_rank(v, 8, idx);
> +    struct vgic_irq_rank *rank = vgic_irq_rank(v, 1, irq / 32);
>      struct pending_irq *iter, *n = irq_to_pending(v, irq);
>      unsigned long flags;
>  
> @@ -587,7 +581,7 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
>      if (!list_empty(&n->inflight))
>          return;
>  
> -    priority = byte_read(rank->ipriority[REG_RANK_INDEX(8, idx)], 0, byte);
> +    priority = byte_read(rank->ipriority[REG_RANK_INDEX(8, irq / 4)], 0, byte);
>  
>      n->irq = irq;
>      n->priority = priority;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 20:47:50 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 20:47:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRqoP-00037N-26; Fri, 26 Oct 2012 20:47:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRqoO-00037I-Ff
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 20:47:24 +0000
Received: from [193.109.254.147:14408] by server-13.bemta-14.messagelabs.com
	id 0B/92-11239-BD6FA805; Fri, 26 Oct 2012 20:47:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1351284441!8565675!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28459 invoked from network); 26 Oct 2012 20:47:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 20:47:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,656,1344211200"; d="scan'208";a="15420315"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 20:47:20 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 26 Oct 2012 21:47:20 +0100
Message-ID: <1351284440.12176.9.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Stefano Stabellini 
Date: Fri, 26 Oct 2012 21:47:20 +0100
In-Reply-To: 
References: 
	<1351091027-20740-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1351157246.18035.129.camel@zakaz.uk.xensource.com>
	
	<1351269622.15162.105.camel@zakaz.uk.xensource.com>
	
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" , "Tim
	\(Xen.org\)" 
Subject: Re: [Xen-devel] [PATCH 1/7] xen/arm: fix rank calculation in
 vgic_vcpu_inject_irq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-26 at 19:42 +0100, Stefano Stabellini wrote:
> I think that the problem is the usage of vgic_irq_rank with registers
> that have 1 bit per interrupt.

That's very plausible indeed.

> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index 3c3983f..92731b6 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -42,13 +42,7 @@
>   */
>  static inline int REG_RANK_NR(int b, uint32_t n)
>  {
> -    switch ( b )
> -    {
> -    case 8: return n >> 3;
> -    case 4: return n >> 2;
> -    case 2: return n >> 1;
> -    default: BUG();
> -    }
> +    return n / b;

All the infrastructure will fall apart if b isn't a power of two, that's
why I used the switch. Can you just add the appropriate case 1 instead?
Probably the bug should be a call to an undefined function to make this
a compile time rather than runtime failure too.

> @@ -577,9 +571,9 @@ struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq)
>  
>  void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)

The changes to this function are all unnecessary, since it was already
consistent within itself. If you want to change it please add a helper
which takes an irq and hides the shifts.

I'd be inclined to rename the existing vgic_irq_rank to vgic_reg_rank
and then call the new helper vgic_irq_rank since that would better
reflect the purpose of both.

>  {
> -    int idx = irq >> 2, byte = irq & 0x3;
> +    int byte = irq & 0x3;

byte isn't actually needed either.

>      uint8_t priority;
> -    struct vgic_irq_rank *rank = vgic_irq_rank(v, 8, idx);
> +    struct vgic_irq_rank *rank = vgic_irq_rank(v, 1, irq / 32);
>      struct pending_irq *iter, *n = irq_to_pending(v, irq);
>      unsigned long flags;
>  
> @@ -587,7 +581,7 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int irq, int virtual)
>      if (!list_empty(&n->inflight))
>          return;
>  
> -    priority = byte_read(rank->ipriority[REG_RANK_INDEX(8, idx)], 0, byte);
> +    priority = byte_read(rank->ipriority[REG_RANK_INDEX(8, irq / 4)], 0, byte);
>  
>      n->irq = irq;
>      n->priority = priority;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 21:45:49 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 21:45:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRriQ-0003nY-QL; Fri, 26 Oct 2012 21:45:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRriP-0003nT-R5
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 21:45:18 +0000
Received: from [85.158.138.51:30609] by server-12.bemta-3.messagelabs.com id
	7A/CE-27853-5640B805; Fri, 26 Oct 2012 21:45:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1351287907!19517126!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31121 invoked from network); 26 Oct 2012 21:45:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 21:45:08 -0000
X-IronPort-AV: E=Sophos;i="4.80,657,1344211200"; d="scan'208";a="15420709"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 21:45:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 26 Oct 2012 22:45:06 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TRriE-0002p8-88;
	Fri, 26 Oct 2012 21:45:06 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TRriD-0004qT-TE;
	Fri, 26 Oct 2012 22:45:06 +0100
To: 
Message-ID: 
From: xen.org 
Date: Fri, 26 Oct 2012 22:45:05 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 14085: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14085 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14085/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pv            3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-pv             3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-xl-multivcpu  3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-xl            3 host-install(3)         broken REGR. vs. 14076
 test-amd64-amd64-pv           3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-rhel6hvm-amd  3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)       broken REGR. vs. 14076
 test-i386-i386-xl             3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-pair          4 host-install/dst_host(4) broken REGR. vs. 14076
 test-i386-i386-pair          3 host-install/src_host(3) broken REGR. vs. 14076
 test-amd64-i386-pair         4 host-install/dst_host(4) broken REGR. vs. 14076
 test-amd64-i386-pair         3 host-install/src_host(3) broken REGR. vs. 14076
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 14076
 test-amd64-amd64-pair        3 host-install/src_host(3) broken REGR. vs. 14076
 test-amd64-amd64-pair        4 host-install/dst_host(4) broken REGR. vs. 14076
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 14076
 test-amd64-amd64-xl-qemuu-win7-amd64  3 host-install(3) broken REGR. vs. 14076
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 14076
 test-amd64-i386-xend-winxpsp3  3 host-install(3)        broken REGR. vs. 14076
 test-amd64-i386-xl-win7-amd64  3 host-install(3)        broken REGR. vs. 14076
 test-amd64-i386-xl-winxpsp3-vcpus1  3 host-install(3)   broken REGR. vs. 14076
 test-amd64-i386-win           3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-win            7 windows-install           fail REGR. vs. 14076
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 14076
 test-amd64-amd64-xl-win       3 host-install(3)         broken REGR. vs. 14076

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)      broken REGR. vs. 14076
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)         broken REGR. vs. 14076
 test-amd64-amd64-xl-sedf      3 host-install(3)         broken REGR. vs. 14076

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass

version targeted for testing:
 xen                  25eda7e7b4e6
baseline version:
 xen                  40ccbee890e1

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla 
  Bastian Blank 
  Chuang Cao 
  George Dunlap 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jason McCarver 
  Joe Jin 
  Keir Fraser 
  Matt Wilson 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Sander Eikelenboom 
  Stefano Stabellini 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           broken  
 test-i386-i386-xl                                            broken  
 test-amd64-i386-rhel6hvm-amd                                 broken  
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         broken  
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        broken  
 test-amd64-i386-pair                                         broken  
 test-i386-i386-pair                                          broken  
 test-amd64-amd64-xl-sedf-pin                                 broken  
 test-amd64-amd64-pv                                          broken  
 test-amd64-i386-pv                                           broken  
 test-i386-i386-pv                                            broken  
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           broken  
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          broken  
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      broken  
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                broken  
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 612 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 21:45:49 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 21:45:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRriQ-0003nY-QL; Fri, 26 Oct 2012 21:45:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRriP-0003nT-R5
	for xen-devel@lists.xensource.com; Fri, 26 Oct 2012 21:45:18 +0000
Received: from [85.158.138.51:30609] by server-12.bemta-3.messagelabs.com id
	7A/CE-27853-5640B805; Fri, 26 Oct 2012 21:45:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1351287907!19517126!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31121 invoked from network); 26 Oct 2012 21:45:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Oct 2012 21:45:08 -0000
X-IronPort-AV: E=Sophos;i="4.80,657,1344211200"; d="scan'208";a="15420709"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Oct 2012 21:45:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 26 Oct 2012 22:45:06 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TRriE-0002p8-88;
	Fri, 26 Oct 2012 21:45:06 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TRriD-0004qT-TE;
	Fri, 26 Oct 2012 22:45:06 +0100
To: 
Message-ID: 
From: xen.org 
Date: Fri, 26 Oct 2012 22:45:05 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 14085: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14085 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14085/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pv            3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-pv             3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-xl-multivcpu  3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-xl            3 host-install(3)         broken REGR. vs. 14076
 test-amd64-amd64-pv           3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-rhel6hvm-amd  3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)       broken REGR. vs. 14076
 test-i386-i386-xl             3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-pair          4 host-install/dst_host(4) broken REGR. vs. 14076
 test-i386-i386-pair          3 host-install/src_host(3) broken REGR. vs. 14076
 test-amd64-i386-pair         4 host-install/dst_host(4) broken REGR. vs. 14076
 test-amd64-i386-pair         3 host-install/src_host(3) broken REGR. vs. 14076
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 14076
 test-amd64-amd64-pair        3 host-install/src_host(3) broken REGR. vs. 14076
 test-amd64-amd64-pair        4 host-install/dst_host(4) broken REGR. vs. 14076
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 14076
 test-amd64-amd64-xl-qemuu-win7-amd64  3 host-install(3) broken REGR. vs. 14076
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 14076
 test-amd64-i386-xend-winxpsp3  3 host-install(3)        broken REGR. vs. 14076
 test-amd64-i386-xl-win7-amd64  3 host-install(3)        broken REGR. vs. 14076
 test-amd64-i386-xl-winxpsp3-vcpus1  3 host-install(3)   broken REGR. vs. 14076
 test-amd64-i386-win           3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-win            7 windows-install           fail REGR. vs. 14076
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 14076
 test-amd64-amd64-xl-win       3 host-install(3)         broken REGR. vs. 14076

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)      broken REGR. vs. 14076
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)         broken REGR. vs. 14076
 test-amd64-amd64-xl-sedf      3 host-install(3)         broken REGR. vs. 14076

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass

version targeted for testing:
 xen                  25eda7e7b4e6
baseline version:
 xen                  40ccbee890e1

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla 
  Bastian Blank 
  Chuang Cao 
  George Dunlap 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jason McCarver 
  Joe Jin 
  Keir Fraser 
  Matt Wilson 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Sander Eikelenboom 
  Stefano Stabellini 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           broken  
 test-i386-i386-xl                                            broken  
 test-amd64-i386-rhel6hvm-amd                                 broken  
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         broken  
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        broken  
 test-amd64-i386-pair                                         broken  
 test-i386-i386-pair                                          broken  
 test-amd64-amd64-xl-sedf-pin                                 broken  
 test-amd64-amd64-pv                                          broken  
 test-amd64-i386-pv                                           broken  
 test-i386-i386-pv                                            broken  
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           broken  
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          broken  
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      broken  
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                broken  
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 612 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 22:43:48 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 22:43:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRscb-0004TT-G2; Fri, 26 Oct 2012 22:43:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRsca-0004TO-5B
	for Xen-devel@lists.xensource.com; Fri, 26 Oct 2012 22:43:20 +0000
Received: from [85.158.138.51:24394] by server-3.bemta-3.messagelabs.com id
	6C/E5-09368-6021B805; Fri, 26 Oct 2012 22:43:18 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1351291396!25847295!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMjM1Nw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13013 invoked from network); 26 Oct 2012 22:43:18 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Oct 2012 22:43:18 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9QMhDwV027443
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 26 Oct 2012 22:43:14 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9QMhDvI011815
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 26 Oct 2012 22:43:13 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9QMhCRr030212; Fri, 26 Oct 2012 17:43:12 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 26 Oct 2012 15:43:12 -0700
Date: Fri, 26 Oct 2012 15:43:11 -0700
From: Mukesh Rathor 
To: "Xen-devel@lists.xensource.com" , Konrad
	Rzeszutek Wilk , david.vrabel@citrix.com
Message-ID: <20121026154311.46607f20@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Subject: [Xen-devel] Huge perf degradation from missing xen_tlb_flush_all
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

A customer experienced huge degradation in migration performance moving
from 2.6.32 based dom0 to 2.6.39 based dom0. We tracked it down to
missing xen_tlb_flush_all() in 2.6.39/pv-ops kernel.

To summarize, in 2.6.32,  we had

#define flush_tlb_all xen_tlb_flush_all

As a result, when xen_remap_domain_mfn_range called flush_tlb_all(), 
it made a hypercall to xen: 

void xen_tlb_flush_all(void)
{
        struct mmuext_op op;
	op.cmd = MMUEXT_TLB_FLUSH_ALL;
	BUG_ON(HYPERVISOR_mmuext_op(&op, 1, NULL, DOMID_SELF) < 0);
}

xen optimized IPI to only relevant cpus. But in pvops/2.6.39 kernel,
the flush_tlb_all will IPI each VCPU whethere it's running or not:

void flush_tlb_all(void)
{
        on_each_cpu(do_flush_tlb_all, NULL, 1);
}

This results in each vcpu being scheduled to receive the event channel
at least. With large number of VCPUs the overhead is significant.

It seems the best solution would be to restore xen_tlb_flush_all().

Thoughts?

thanks
Mukesh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 22:43:48 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 22:43:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRscb-0004TT-G2; Fri, 26 Oct 2012 22:43:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRsca-0004TO-5B
	for Xen-devel@lists.xensource.com; Fri, 26 Oct 2012 22:43:20 +0000
Received: from [85.158.138.51:24394] by server-3.bemta-3.messagelabs.com id
	6C/E5-09368-6021B805; Fri, 26 Oct 2012 22:43:18 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1351291396!25847295!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyMjM1Nw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13013 invoked from network); 26 Oct 2012 22:43:18 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Oct 2012 22:43:18 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9QMhDwV027443
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 26 Oct 2012 22:43:14 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9QMhDvI011815
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 26 Oct 2012 22:43:13 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9QMhCRr030212; Fri, 26 Oct 2012 17:43:12 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 26 Oct 2012 15:43:12 -0700
Date: Fri, 26 Oct 2012 15:43:11 -0700
From: Mukesh Rathor 
To: "Xen-devel@lists.xensource.com" , Konrad
	Rzeszutek Wilk , david.vrabel@citrix.com
Message-ID: <20121026154311.46607f20@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Subject: [Xen-devel] Huge perf degradation from missing xen_tlb_flush_all
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

A customer experienced huge degradation in migration performance moving
from 2.6.32 based dom0 to 2.6.39 based dom0. We tracked it down to
missing xen_tlb_flush_all() in 2.6.39/pv-ops kernel.

To summarize, in 2.6.32,  we had

#define flush_tlb_all xen_tlb_flush_all

As a result, when xen_remap_domain_mfn_range called flush_tlb_all(), 
it made a hypercall to xen: 

void xen_tlb_flush_all(void)
{
        struct mmuext_op op;
	op.cmd = MMUEXT_TLB_FLUSH_ALL;
	BUG_ON(HYPERVISOR_mmuext_op(&op, 1, NULL, DOMID_SELF) < 0);
}

xen optimized IPI to only relevant cpus. But in pvops/2.6.39 kernel,
the flush_tlb_all will IPI each VCPU whethere it's running or not:

void flush_tlb_all(void)
{
        on_each_cpu(do_flush_tlb_all, NULL, 1);
}

This results in each vcpu being scheduled to receive the event channel
at least. With large number of VCPUs the overhead is significant.

It seems the best solution would be to restore xen_tlb_flush_all().

Thoughts?

thanks
Mukesh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 23:11:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 23:11:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRt34-0004ou-Ph; Fri, 26 Oct 2012 23:10:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRt33-0004op-1N
	for Xen-devel@lists.xensource.com; Fri, 26 Oct 2012 23:10:41 +0000
Received: from [85.158.138.51:18365] by server-13.bemta-3.messagelabs.com id
	CA/37-24887-0781B805; Fri, 26 Oct 2012 23:10:40 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1351293037!18702709!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgzMzI2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4329 invoked from network); 26 Oct 2012 23:10:39 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Oct 2012 23:10:39 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9QNAYdo032551
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 26 Oct 2012 23:10:35 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9QNAYAq006670
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 26 Oct 2012 23:10:34 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9QNAXb6013095; Fri, 26 Oct 2012 18:10:33 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 26 Oct 2012 16:10:33 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 895804042D; Fri, 26 Oct 2012 18:58:13 -0400 (EDT)
Date: Fri, 26 Oct 2012 18:58:13 -0400
From: Konrad Rzeszutek Wilk 
To: Mukesh Rathor 
Message-ID: <20121026225813.GJ2708@phenom.dumpdata.com>
References: <20121026154311.46607f20@mantra.us.oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20121026154311.46607f20@mantra.us.oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "Xen-devel@lists.xensource.com" ,
	david.vrabel@citrix.com
Subject: Re: [Xen-devel] Huge perf degradation from missing xen_tlb_flush_all
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 26, 2012 at 03:43:11PM -0700, Mukesh Rathor wrote:
> Hi,
> 
> A customer experienced huge degradation in migration performance moving
> from 2.6.32 based dom0 to 2.6.39 based dom0. We tracked it down to
> missing xen_tlb_flush_all() in 2.6.39/pv-ops kernel.
> 
> To summarize, in 2.6.32,  we had
> 
> #define flush_tlb_all xen_tlb_flush_all
> 
> As a result, when xen_remap_domain_mfn_range called flush_tlb_all(), 
> it made a hypercall to xen: 
> 
> void xen_tlb_flush_all(void)
> {
>         struct mmuext_op op;
> 	op.cmd = MMUEXT_TLB_FLUSH_ALL;
> 	BUG_ON(HYPERVISOR_mmuext_op(&op, 1, NULL, DOMID_SELF) < 0);
> }
> 
> xen optimized IPI to only relevant cpus. But in pvops/2.6.39 kernel,
> the flush_tlb_all will IPI each VCPU whethere it's running or not:
> 
> void flush_tlb_all(void)
> {
>         on_each_cpu(do_flush_tlb_all, NULL, 1);
> }
> 
> This results in each vcpu being scheduled to receive the event channel
> at least. With large number of VCPUs the overhead is significant.
> 
> It seems the best solution would be to restore xen_tlb_flush_all().
> 
> Thoughts?

Like this I presume (not compile tested):


diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 6226c99..dd91c3c 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1288,6 +1288,23 @@ unsigned long xen_read_cr2_direct(void)
 	return this_cpu_read(xen_vcpu_info.arch.cr2);
 }
 
+void xen_flush_tbl_all(void)
+{
+	struct mmuext_op *op;
+	struct multicall_space mcs;
+
+	preempt_disable();
+
+	mcs = xen_mc_entry(sizeof(*op));
+
+	op = mcs.args;
+	op->cmd = MMUEXT_TLB_FLUSH_ALL;
+	MULTI_mmuext_op(mcs.mc, op, 1, NULL, DOMID_SELF);
+
+	xen_mc_issue(PARAVIRT_LAZY_MMU);
+
+	preempt_enable();
+}
 static void xen_flush_tlb(void)
 {
 	struct mmuext_op *op;
@@ -2518,7 +2535,7 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 	err = 0;
 out:
 
-	flush_tlb_all();
+	xen_flush_tbl_all();
 
 	return err;
 }
> 
> thanks
> Mukesh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Oct 26 23:11:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 26 Oct 2012 23:11:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRt34-0004ou-Ph; Fri, 26 Oct 2012 23:10:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRt33-0004op-1N
	for Xen-devel@lists.xensource.com; Fri, 26 Oct 2012 23:10:41 +0000
Received: from [85.158.138.51:18365] by server-13.bemta-3.messagelabs.com id
	CA/37-24887-0781B805; Fri, 26 Oct 2012 23:10:40 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1351293037!18702709!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgzMzI2NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4329 invoked from network); 26 Oct 2012 23:10:39 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Oct 2012 23:10:39 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9QNAYdo032551
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 26 Oct 2012 23:10:35 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9QNAYAq006670
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 26 Oct 2012 23:10:34 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9QNAXb6013095; Fri, 26 Oct 2012 18:10:33 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 26 Oct 2012 16:10:33 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 895804042D; Fri, 26 Oct 2012 18:58:13 -0400 (EDT)
Date: Fri, 26 Oct 2012 18:58:13 -0400
From: Konrad Rzeszutek Wilk 
To: Mukesh Rathor 
Message-ID: <20121026225813.GJ2708@phenom.dumpdata.com>
References: <20121026154311.46607f20@mantra.us.oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20121026154311.46607f20@mantra.us.oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "Xen-devel@lists.xensource.com" ,
	david.vrabel@citrix.com
Subject: Re: [Xen-devel] Huge perf degradation from missing xen_tlb_flush_all
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Oct 26, 2012 at 03:43:11PM -0700, Mukesh Rathor wrote:
> Hi,
> 
> A customer experienced huge degradation in migration performance moving
> from 2.6.32 based dom0 to 2.6.39 based dom0. We tracked it down to
> missing xen_tlb_flush_all() in 2.6.39/pv-ops kernel.
> 
> To summarize, in 2.6.32,  we had
> 
> #define flush_tlb_all xen_tlb_flush_all
> 
> As a result, when xen_remap_domain_mfn_range called flush_tlb_all(), 
> it made a hypercall to xen: 
> 
> void xen_tlb_flush_all(void)
> {
>         struct mmuext_op op;
> 	op.cmd = MMUEXT_TLB_FLUSH_ALL;
> 	BUG_ON(HYPERVISOR_mmuext_op(&op, 1, NULL, DOMID_SELF) < 0);
> }
> 
> xen optimized IPI to only relevant cpus. But in pvops/2.6.39 kernel,
> the flush_tlb_all will IPI each VCPU whethere it's running or not:
> 
> void flush_tlb_all(void)
> {
>         on_each_cpu(do_flush_tlb_all, NULL, 1);
> }
> 
> This results in each vcpu being scheduled to receive the event channel
> at least. With large number of VCPUs the overhead is significant.
> 
> It seems the best solution would be to restore xen_tlb_flush_all().
> 
> Thoughts?

Like this I presume (not compile tested):


diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 6226c99..dd91c3c 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1288,6 +1288,23 @@ unsigned long xen_read_cr2_direct(void)
 	return this_cpu_read(xen_vcpu_info.arch.cr2);
 }
 
+void xen_flush_tbl_all(void)
+{
+	struct mmuext_op *op;
+	struct multicall_space mcs;
+
+	preempt_disable();
+
+	mcs = xen_mc_entry(sizeof(*op));
+
+	op = mcs.args;
+	op->cmd = MMUEXT_TLB_FLUSH_ALL;
+	MULTI_mmuext_op(mcs.mc, op, 1, NULL, DOMID_SELF);
+
+	xen_mc_issue(PARAVIRT_LAZY_MMU);
+
+	preempt_enable();
+}
 static void xen_flush_tlb(void)
 {
 	struct mmuext_op *op;
@@ -2518,7 +2535,7 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 	err = 0;
 out:
 
-	flush_tlb_all();
+	xen_flush_tbl_all();
 
 	return err;
 }
> 
> thanks
> Mukesh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 27 00:03:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 00:03:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRtrL-0005tZ-RH; Sat, 27 Oct 2012 00:02:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRtrK-0005tU-Q4
	for Xen-devel@lists.xensource.com; Sat, 27 Oct 2012 00:02:38 +0000
Received: from [85.158.143.99:27039] by server-1.bemta-4.messagelabs.com id
	AA/AF-19134-E942B805; Sat, 27 Oct 2012 00:02:38 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1351296156!27535673!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODI2MTI0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23056 invoked from network); 27 Oct 2012 00:02:37 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Oct 2012 00:02:37 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9R02Xej029235
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 27 Oct 2012 00:02:34 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9R02XXh003045
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 27 Oct 2012 00:02:33 GMT
Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9R02WXx004229; Fri, 26 Oct 2012 19:02:32 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 26 Oct 2012 17:02:32 -0700
Date: Fri, 26 Oct 2012 17:02:31 -0700
From: Mukesh Rathor 
To: Konrad Rzeszutek Wilk 
Message-ID: <20121026170231.31ad2ab8@mantra.us.oracle.com>
In-Reply-To: <20121026225813.GJ2708@phenom.dumpdata.com>
References: <20121026154311.46607f20@mantra.us.oracle.com>
	<20121026225813.GJ2708@phenom.dumpdata.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "Xen-devel@lists.xensource.com" ,
	david.vrabel@citrix.com
Subject: Re: [Xen-devel] Huge perf degradation from missing xen_tlb_flush_all
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 26 Oct 2012 18:58:13 -0400
Konrad Rzeszutek Wilk  wrote:

> On Fri, Oct 26, 2012 at 03:43:11PM -0700, Mukesh Rathor wrote:
> > Hi,
> > 
> Like this I presume (not compile tested):
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index 6226c99..dd91c3c 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -1288,6 +1288,23 @@ unsigned long xen_read_cr2_direct(void)
>  	return this_cpu_read(xen_vcpu_info.arch.cr2);
>  }
>  
> +void xen_flush_tbl_all(void)
> +{
> +	struct mmuext_op *op;
> +	struct multicall_space mcs;
> +
> +	preempt_disable();
> +
> +	mcs = xen_mc_entry(sizeof(*op));
> +
> +	op = mcs.args;
> +	op->cmd = MMUEXT_TLB_FLUSH_ALL;
> +	MULTI_mmuext_op(mcs.mc, op, 1, NULL, DOMID_SELF);
> +
> +	xen_mc_issue(PARAVIRT_LAZY_MMU);
> +
> +	preempt_enable();
> +}
>  static void xen_flush_tlb(void)
>  {
>  	struct mmuext_op *op;
> @@ -2518,7 +2535,7 @@ int xen_remap_domain_mfn_range(struct
> vm_area_struct *vma, err = 0;
>  out:
>  
> -	flush_tlb_all();
> +	xen_flush_tbl_all();

We should examine other places flush_tlb_all() is called from too.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 27 00:03:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 00:03:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRtrL-0005tZ-RH; Sat, 27 Oct 2012 00:02:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRtrK-0005tU-Q4
	for Xen-devel@lists.xensource.com; Sat, 27 Oct 2012 00:02:38 +0000
Received: from [85.158.143.99:27039] by server-1.bemta-4.messagelabs.com id
	AA/AF-19134-E942B805; Sat, 27 Oct 2012 00:02:38 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1351296156!27535673!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODI2MTI0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23056 invoked from network); 27 Oct 2012 00:02:37 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Oct 2012 00:02:37 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9R02Xej029235
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 27 Oct 2012 00:02:34 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9R02XXh003045
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 27 Oct 2012 00:02:33 GMT
Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9R02WXx004229; Fri, 26 Oct 2012 19:02:32 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 26 Oct 2012 17:02:32 -0700
Date: Fri, 26 Oct 2012 17:02:31 -0700
From: Mukesh Rathor 
To: Konrad Rzeszutek Wilk 
Message-ID: <20121026170231.31ad2ab8@mantra.us.oracle.com>
In-Reply-To: <20121026225813.GJ2708@phenom.dumpdata.com>
References: <20121026154311.46607f20@mantra.us.oracle.com>
	<20121026225813.GJ2708@phenom.dumpdata.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "Xen-devel@lists.xensource.com" ,
	david.vrabel@citrix.com
Subject: Re: [Xen-devel] Huge perf degradation from missing xen_tlb_flush_all
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 26 Oct 2012 18:58:13 -0400
Konrad Rzeszutek Wilk  wrote:

> On Fri, Oct 26, 2012 at 03:43:11PM -0700, Mukesh Rathor wrote:
> > Hi,
> > 
> Like this I presume (not compile tested):
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index 6226c99..dd91c3c 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -1288,6 +1288,23 @@ unsigned long xen_read_cr2_direct(void)
>  	return this_cpu_read(xen_vcpu_info.arch.cr2);
>  }
>  
> +void xen_flush_tbl_all(void)
> +{
> +	struct mmuext_op *op;
> +	struct multicall_space mcs;
> +
> +	preempt_disable();
> +
> +	mcs = xen_mc_entry(sizeof(*op));
> +
> +	op = mcs.args;
> +	op->cmd = MMUEXT_TLB_FLUSH_ALL;
> +	MULTI_mmuext_op(mcs.mc, op, 1, NULL, DOMID_SELF);
> +
> +	xen_mc_issue(PARAVIRT_LAZY_MMU);
> +
> +	preempt_enable();
> +}
>  static void xen_flush_tlb(void)
>  {
>  	struct mmuext_op *op;
> @@ -2518,7 +2535,7 @@ int xen_remap_domain_mfn_range(struct
> vm_area_struct *vma, err = 0;
>  out:
>  
> -	flush_tlb_all();
> +	xen_flush_tbl_all();

We should examine other places flush_tlb_all() is called from too.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 27 01:11:07 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 01:11:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRuv4-0001vs-61; Sat, 27 Oct 2012 01:10:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRuv2-0001vn-Ka
	for xen-devel@lists.xensource.com; Sat, 27 Oct 2012 01:10:32 +0000
Received: from [85.158.138.51:5771] by server-7.bemta-3.messagelabs.com id
	EC/8F-06991-7843B805; Sat, 27 Oct 2012 01:10:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1351300229!21263671!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28589 invoked from network); 27 Oct 2012 01:10:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Oct 2012 01:10:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,658,1344211200"; d="scan'208";a="15421346"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Oct 2012 01:10:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sat, 27 Oct 2012 02:10:28 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TRuuy-00043u-Q5;
	Sat, 27 Oct 2012 01:10:28 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TRuuy-0002HX-Pb;
	Sat, 27 Oct 2012 02:10:28 +0100
To: 
Message-ID: 
From: xen.org 
Date: Sat, 27 Oct 2012 02:10:28 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 14090: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14090 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14090/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pv            3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-pv             3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-xl-multivcpu  3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-xl            3 host-install(3)         broken REGR. vs. 14076
 test-amd64-amd64-pv           3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-rhel6hvm-amd  3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)       broken REGR. vs. 14076
 test-i386-i386-xl             3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-pair         3 host-install/src_host(3) broken REGR. vs. 14076
 test-amd64-i386-pair         4 host-install/dst_host(4) broken REGR. vs. 14076
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 14076
 test-amd64-amd64-xl-qemuu-win7-amd64  3 host-install(3) broken REGR. vs. 14076
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 14076
 test-amd64-i386-xend-winxpsp3  3 host-install(3)        broken REGR. vs. 14076
 test-amd64-i386-xl-win7-amd64  3 host-install(3)        broken REGR. vs. 14076
 test-amd64-i386-xl-winxpsp3-vcpus1  3 host-install(3)   broken REGR. vs. 14076
 test-amd64-i386-win           3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 14076
 test-amd64-amd64-xl-win       3 host-install(3)         broken REGR. vs. 14076

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3)   broken pass in 14085
 test-amd64-amd64-xl           3 host-install(3)           broken pass in 14085
 test-i386-i386-pair   4 host-install/dst_host(4) broken in 14085 pass in 14090
 test-i386-i386-pair   3 host-install/src_host(3) broken in 14085 pass in 14090
 test-amd64-amd64-pair 3 host-install/src_host(3) broken in 14085 pass in 14090
 test-amd64-amd64-pair 4 host-install/dst_host(4) broken in 14085 pass in 14090
 test-i386-i386-win            7 windows-install    fail in 14085 pass in 14090

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)      broken REGR. vs. 14076
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)         broken REGR. vs. 14076
 test-amd64-amd64-xl-sedf      3 host-install(3)         broken REGR. vs. 14076

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  25eda7e7b4e6
baseline version:
 xen                  40ccbee890e1

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla 
  Bastian Blank 
  Chuang Cao 
  George Dunlap 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jason McCarver 
  Joe Jin 
  Keir Fraser 
  Matt Wilson 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Sander Eikelenboom 
  Stefano Stabellini 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          broken  
 test-amd64-i386-xl                                           broken  
 test-i386-i386-xl                                            broken  
 test-amd64-i386-rhel6hvm-amd                                 broken  
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         broken  
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         broken  
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         broken  
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 broken  
 test-amd64-amd64-pv                                          broken  
 test-amd64-i386-pv                                           broken  
 test-i386-i386-pv                                            broken  
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           broken  
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          broken  
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      broken  
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                broken  
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 612 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 27 01:11:07 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 01:11:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRuv4-0001vs-61; Sat, 27 Oct 2012 01:10:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRuv2-0001vn-Ka
	for xen-devel@lists.xensource.com; Sat, 27 Oct 2012 01:10:32 +0000
Received: from [85.158.138.51:5771] by server-7.bemta-3.messagelabs.com id
	EC/8F-06991-7843B805; Sat, 27 Oct 2012 01:10:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1351300229!21263671!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYyNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28589 invoked from network); 27 Oct 2012 01:10:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Oct 2012 01:10:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,658,1344211200"; d="scan'208";a="15421346"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Oct 2012 01:10:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sat, 27 Oct 2012 02:10:28 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TRuuy-00043u-Q5;
	Sat, 27 Oct 2012 01:10:28 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TRuuy-0002HX-Pb;
	Sat, 27 Oct 2012 02:10:28 +0100
To: 
Message-ID: 
From: xen.org 
Date: Sat, 27 Oct 2012 02:10:28 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 14090: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14090 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14090/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pv            3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-pv             3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-xl-multivcpu  3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-xl            3 host-install(3)         broken REGR. vs. 14076
 test-amd64-amd64-pv           3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-rhel6hvm-amd  3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)       broken REGR. vs. 14076
 test-i386-i386-xl             3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-pair         3 host-install/src_host(3) broken REGR. vs. 14076
 test-amd64-i386-pair         4 host-install/dst_host(4) broken REGR. vs. 14076
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 14076
 test-amd64-amd64-xl-qemuu-win7-amd64  3 host-install(3) broken REGR. vs. 14076
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 14076
 test-amd64-i386-xend-winxpsp3  3 host-install(3)        broken REGR. vs. 14076
 test-amd64-i386-xl-win7-amd64  3 host-install(3)        broken REGR. vs. 14076
 test-amd64-i386-xl-winxpsp3-vcpus1  3 host-install(3)   broken REGR. vs. 14076
 test-amd64-i386-win           3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 14076
 test-amd64-amd64-xl-win       3 host-install(3)         broken REGR. vs. 14076

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3)   broken pass in 14085
 test-amd64-amd64-xl           3 host-install(3)           broken pass in 14085
 test-i386-i386-pair   4 host-install/dst_host(4) broken in 14085 pass in 14090
 test-i386-i386-pair   3 host-install/src_host(3) broken in 14085 pass in 14090
 test-amd64-amd64-pair 3 host-install/src_host(3) broken in 14085 pass in 14090
 test-amd64-amd64-pair 4 host-install/dst_host(4) broken in 14085 pass in 14090
 test-i386-i386-win            7 windows-install    fail in 14085 pass in 14090

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)      broken REGR. vs. 14076
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)         broken REGR. vs. 14076
 test-amd64-amd64-xl-sedf      3 host-install(3)         broken REGR. vs. 14076

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  25eda7e7b4e6
baseline version:
 xen                  40ccbee890e1

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla 
  Bastian Blank 
  Chuang Cao 
  George Dunlap 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jason McCarver 
  Joe Jin 
  Keir Fraser 
  Matt Wilson 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Sander Eikelenboom 
  Stefano Stabellini 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          broken  
 test-amd64-i386-xl                                           broken  
 test-i386-i386-xl                                            broken  
 test-amd64-i386-rhel6hvm-amd                                 broken  
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         broken  
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         broken  
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         broken  
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 broken  
 test-amd64-amd64-pv                                          broken  
 test-amd64-i386-pv                                           broken  
 test-i386-i386-pv                                            broken  
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           broken  
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          broken  
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      broken  
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                broken  
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 612 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 27 01:14:40 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 01:14:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRuyZ-00027w-0m; Sat, 27 Oct 2012 01:14:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRuyX-00027p-Uu
	for xen-devel@lists.xensource.com; Sat, 27 Oct 2012 01:14:10 +0000
Received: from [85.158.137.99:6839] by server-8.bemta-3.messagelabs.com id
	65/CB-10525-1653B805; Sat, 27 Oct 2012 01:14:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1351300448!23265939!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23535 invoked from network); 27 Oct 2012 01:14:08 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Oct 2012 01:14:08 -0000
X-IronPort-AV: E=Sophos;i="4.80,658,1344211200"; d="scan'208";a="15421842"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Oct 2012 01:13:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sat, 27 Oct 2012 02:13:24 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TRuxo-00045A-LZ;
	Sat, 27 Oct 2012 01:13:24 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TRuxo-0002py-Kl;
	Sat, 27 Oct 2012 02:13:24 +0100
To: 
Message-ID: 
From: xen.org 
Date: Sat, 27 Oct 2012 02:13:24 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 14092: trouble: blocked/broken
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14092 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14092/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386                    2 host-install(2)         broken REGR. vs. 13919
 build-amd64                   2 host-install(2)         broken REGR. vs. 13919
 build-i386-pvops              2 host-install(2)         broken REGR. vs. 13919
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 13919
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13919
 build-i386-oldkern            2 host-install(2)         broken REGR. vs. 13919

Tests which did not succeed, but are not blocking:
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 xen                  69d1cc78a5bd
baseline version:
 xen                  a15596a619ed

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           broken  
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             broken  
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   23385:69d1cc78a5bd
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:10:04 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    [ Includes 25589:60f09d1ab1fe for CVE-2012-2625 ]
    
    
changeset:   23384:a15596a619ed
user:        Daniel De Graaf 
date:        Thu Oct 04 10:44:43 2012 +0200
    
    x86: check remote MMIO remap permissions
    
    When a domain is mapping pages from a different pg_owner domain, the
    iomem_access checks are currently only applied to the pg_owner domain,
    potentially allowing a domain with a more restrictive iomem_access
    policy to have the pages mapped into its page tables. To catch this,
    also check the owner of the page tables. The current domain does not
    need to be checked because the ability to manipulate a domain's page
    tables implies full access to the target domain, so checking that
    domain's permission is sufficient.
    
    Signed-off-by: Daniel De Graaf 
    Acked-by: Jan Beulich 
    xen-unstable changeset: 25952:8278d7d8fa48
    xen-unstable date: Wed Sep 26 09:56:07 UTC 2012
    
    
========================================
commit d7d453f51459b591faa96d1c123b5bfff7c5b6b6
Author: Ian Jackson 
Date:   Thu Sep 6 17:05:30 2012 +0100

    Disable qemu monitor by default.  The qemu monitor is an overly
    powerful feature which must be protected from untrusted (guest)
    administrators.
    
    Neither xl nor xend expect qemu to produce this monitor unless it is
    explicitly requested.
    
    This is a security problem, XSA-19.  Previously it was CVE-2007-0998
    in Red Hat but we haven't dealt with it in upstream.  We hope to have
    a new CVE for it here but we don't have one yet.
    
    Signed-off-by: Ian Jackson 
    (cherry picked from commit bacc0d302445c75f18f4c826750fb5853b60e7ca)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 27 01:14:40 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 01:14:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRuyZ-00027w-0m; Sat, 27 Oct 2012 01:14:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRuyX-00027p-Uu
	for xen-devel@lists.xensource.com; Sat, 27 Oct 2012 01:14:10 +0000
Received: from [85.158.137.99:6839] by server-8.bemta-3.messagelabs.com id
	65/CB-10525-1653B805; Sat, 27 Oct 2012 01:14:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1351300448!23265939!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23535 invoked from network); 27 Oct 2012 01:14:08 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Oct 2012 01:14:08 -0000
X-IronPort-AV: E=Sophos;i="4.80,658,1344211200"; d="scan'208";a="15421842"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Oct 2012 01:13:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sat, 27 Oct 2012 02:13:24 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TRuxo-00045A-LZ;
	Sat, 27 Oct 2012 01:13:24 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TRuxo-0002py-Kl;
	Sat, 27 Oct 2012 02:13:24 +0100
To: 
Message-ID: 
From: xen.org 
Date: Sat, 27 Oct 2012 02:13:24 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 14092: trouble: blocked/broken
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14092 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14092/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386                    2 host-install(2)         broken REGR. vs. 13919
 build-amd64                   2 host-install(2)         broken REGR. vs. 13919
 build-i386-pvops              2 host-install(2)         broken REGR. vs. 13919
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 13919
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13919
 build-i386-oldkern            2 host-install(2)         broken REGR. vs. 13919

Tests which did not succeed, but are not blocking:
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 xen                  69d1cc78a5bd
baseline version:
 xen                  a15596a619ed

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           broken  
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             broken  
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   23385:69d1cc78a5bd
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:10:04 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    [ Includes 25589:60f09d1ab1fe for CVE-2012-2625 ]
    
    
changeset:   23384:a15596a619ed
user:        Daniel De Graaf 
date:        Thu Oct 04 10:44:43 2012 +0200
    
    x86: check remote MMIO remap permissions
    
    When a domain is mapping pages from a different pg_owner domain, the
    iomem_access checks are currently only applied to the pg_owner domain,
    potentially allowing a domain with a more restrictive iomem_access
    policy to have the pages mapped into its page tables. To catch this,
    also check the owner of the page tables. The current domain does not
    need to be checked because the ability to manipulate a domain's page
    tables implies full access to the target domain, so checking that
    domain's permission is sufficient.
    
    Signed-off-by: Daniel De Graaf 
    Acked-by: Jan Beulich 
    xen-unstable changeset: 25952:8278d7d8fa48
    xen-unstable date: Wed Sep 26 09:56:07 UTC 2012
    
    
========================================
commit d7d453f51459b591faa96d1c123b5bfff7c5b6b6
Author: Ian Jackson 
Date:   Thu Sep 6 17:05:30 2012 +0100

    Disable qemu monitor by default.  The qemu monitor is an overly
    powerful feature which must be protected from untrusted (guest)
    administrators.
    
    Neither xl nor xend expect qemu to produce this monitor unless it is
    explicitly requested.
    
    This is a security problem, XSA-19.  Previously it was CVE-2007-0998
    in Red Hat but we haven't dealt with it in upstream.  We hope to have
    a new CVE for it here but we don't have one yet.
    
    Signed-off-by: Ian Jackson 
    (cherry picked from commit bacc0d302445c75f18f4c826750fb5853b60e7ca)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 27 04:36:54 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 04:36:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRy8H-0004Uj-3R; Sat, 27 Oct 2012 04:36:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRy8F-0004Ue-5B
	for xen-devel@lists.xensource.com; Sat, 27 Oct 2012 04:36:23 +0000
Received: from [85.158.139.211:8954] by server-9.bemta-5.messagelabs.com id
	01/1A-23053-6C46B805; Sat, 27 Oct 2012 04:36:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1351312581!23906627!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21933 invoked from network); 27 Oct 2012 04:36:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Oct 2012 04:36:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,658,1344211200"; d="scan'208";a="15427857"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Oct 2012 04:36:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sat, 27 Oct 2012 05:36:20 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TRy8C-0005F3-58;
	Sat, 27 Oct 2012 04:36:20 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TRy8B-0003Al-Ry;
	Sat, 27 Oct 2012 05:36:20 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Sat, 27 Oct 2012 05:36:20 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14093: trouble: broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14093 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14093/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3)   broken REGR. vs. 14079
 test-amd64-amd64-pv           3 host-install(3)         broken REGR. vs. 14079
 test-amd64-i386-xl            3 host-install(3)         broken REGR. vs. 14079
 test-amd64-amd64-xl           3 host-install(3)         broken REGR. vs. 14079
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 14079
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)       broken REGR. vs. 14079
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3) broken REGR. vs. 14079
 test-amd64-i386-xl-win-vcpus1  3 host-install(3)        broken REGR. vs. 14079
 test-amd64-amd64-win          3 host-install(3)         broken REGR. vs. 14079
 test-amd64-i386-pv            3 host-install(3)         broken REGR. vs. 14079
 test-amd64-i386-xl-multivcpu  3 host-install(3)         broken REGR. vs. 14079
 test-amd64-i386-win-vcpus1    3 host-install(3)         broken REGR. vs. 14079
 test-amd64-i386-xl-win7-amd64  3 host-install(3)        broken REGR. vs. 14079
 test-amd64-amd64-xl-winxpsp3  3 host-install(3)         broken REGR. vs. 14079
 test-amd64-i386-pair         3 host-install/src_host(3) broken REGR. vs. 14079
 test-amd64-i386-pair         4 host-install/dst_host(4) broken REGR. vs. 14079

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)      broken REGR. vs. 14079
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 14079
 test-amd64-amd64-xl-sedf      3 host-install(3)         broken REGR. vs. 14079
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 14079
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 14079

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  37a8946eeb9d
baseline version:
 xen                  c26e1a79fe77

------------------------------------------------------------
People who touched revisions under test:
  Charles Arnold 
  Christoph Egger 
  Ian Campbell 
  Ian Jackson 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          broken  
 test-amd64-i386-xl                                           broken  
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           broken  
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         broken  
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         broken  
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          broken  
 test-amd64-i386-pv                                           broken  
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   broken  
 test-amd64-i386-xl-win-vcpus1                                broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         broken  
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 broken  


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26115:37a8946eeb9d
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:09:29 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    
    
changeset:   26114:6f9e46917eb8
user:        Charles Arnold 
date:        Fri Oct 26 12:05:08 2012 +0100
    
    pygrub: Add option to list grub entries
    
    The argument to "--entry" allows 2 syntaxes, either directly the entry
    number in menu.lst, or the whole string behind the "title" key word.
    This poses the following issue:
    
    From Dom0 there is no way to guess the number and, or the complete
    title string because this string contains the kernel version, which
    will change with a kernel update.
    
    This patch adds [-l|--list-entries] as an argument to pygrub.
    
    Signed-off-by: Charles Arnold 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26113:03af0abd2b72
user:        Ian Campbell 
date:        Fri Oct 26 12:03:12 2012 +0100
    
    xl: Do not leak events when a domain exits.
    
    The goto in both of these places misses the event free which would
    normally clean up.
    
    ==8655== 80 bytes in 1 blocks are definitely lost in loss record 1 of 1
    ==8655==    at 0x4024370: calloc (vg_replace_malloc.c:593)
    ==8655==    by 0x406EAAE: libxl__zalloc (libxl_internal.c:83)
    ==8655==    by 0x4078173: libxl__event_new (libxl_event.c:1167)
    ==8655==    by 0x4056373: domain_death_occurred (libxl.c:958)
    ==8655==    by 0x4058D06: domain_death_xswatch_callback (libxl.c:1038)
    ==8655==    by 0x4078EB5: watchfd_callback (libxl_event.c:458)
    ==8655==    by 0x407839E: afterpoll_internal (libxl_event.c:949)
    ==8655==    by 0x4079142: eventloop_iteration (libxl_event.c:1371)
    ==8655==    by 0x40799BB: libxl_event_wait (libxl_event.c:1396)
    ==8655==    by 0x805CC67: create_domain (xl_cmdimpl.c:1698)
    ==8655==    by 0x805E001: main_create (xl_cmdimpl.c:3986)
    ==8655==    by 0x804D43D: main (xl.c:285)
    
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26112:d07692b5c780
user:        Ian Jackson 
date:        Fri Oct 26 11:39:42 2012 +0100
    
    Revert 26109:6ccfe4d29f95
    
    This changeset was contaminated by changes hanging around in my
    working tree.  Sorry :-(.
    
    Signed-off-by: Ian Jackson 
    
    
changeset:   26111:c26e1a79fe77
user:        Christoph Egger 
date:        Thu Oct 25 17:12:55 2012 +0100
    
    libxl: NetBSD PCI passthrough support
    
    Add PCI passthrough support for HVM guests.
    
    Signed-off-by: Christoph Egger 
    Committed-by: Ian Jackson 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 27 04:36:54 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 04:36:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TRy8H-0004Uj-3R; Sat, 27 Oct 2012 04:36:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TRy8F-0004Ue-5B
	for xen-devel@lists.xensource.com; Sat, 27 Oct 2012 04:36:23 +0000
Received: from [85.158.139.211:8954] by server-9.bemta-5.messagelabs.com id
	01/1A-23053-6C46B805; Sat, 27 Oct 2012 04:36:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1351312581!23906627!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21933 invoked from network); 27 Oct 2012 04:36:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Oct 2012 04:36:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,658,1344211200"; d="scan'208";a="15427857"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Oct 2012 04:36:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sat, 27 Oct 2012 05:36:20 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TRy8C-0005F3-58;
	Sat, 27 Oct 2012 04:36:20 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TRy8B-0003Al-Ry;
	Sat, 27 Oct 2012 05:36:20 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Sat, 27 Oct 2012 05:36:20 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14093: trouble: broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14093 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14093/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3)   broken REGR. vs. 14079
 test-amd64-amd64-pv           3 host-install(3)         broken REGR. vs. 14079
 test-amd64-i386-xl            3 host-install(3)         broken REGR. vs. 14079
 test-amd64-amd64-xl           3 host-install(3)         broken REGR. vs. 14079
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 14079
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)       broken REGR. vs. 14079
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3) broken REGR. vs. 14079
 test-amd64-i386-xl-win-vcpus1  3 host-install(3)        broken REGR. vs. 14079
 test-amd64-amd64-win          3 host-install(3)         broken REGR. vs. 14079
 test-amd64-i386-pv            3 host-install(3)         broken REGR. vs. 14079
 test-amd64-i386-xl-multivcpu  3 host-install(3)         broken REGR. vs. 14079
 test-amd64-i386-win-vcpus1    3 host-install(3)         broken REGR. vs. 14079
 test-amd64-i386-xl-win7-amd64  3 host-install(3)        broken REGR. vs. 14079
 test-amd64-amd64-xl-winxpsp3  3 host-install(3)         broken REGR. vs. 14079
 test-amd64-i386-pair         3 host-install/src_host(3) broken REGR. vs. 14079
 test-amd64-i386-pair         4 host-install/dst_host(4) broken REGR. vs. 14079

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)      broken REGR. vs. 14079
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 14079
 test-amd64-amd64-xl-sedf      3 host-install(3)         broken REGR. vs. 14079
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 14079
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 14079

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  37a8946eeb9d
baseline version:
 xen                  c26e1a79fe77

------------------------------------------------------------
People who touched revisions under test:
  Charles Arnold 
  Christoph Egger 
  Ian Campbell 
  Ian Jackson 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          broken  
 test-amd64-i386-xl                                           broken  
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           broken  
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         broken  
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         broken  
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          broken  
 test-amd64-i386-pv                                           broken  
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   broken  
 test-amd64-i386-xl-win-vcpus1                                broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         broken  
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 broken  


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26115:37a8946eeb9d
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:09:29 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    
    
changeset:   26114:6f9e46917eb8
user:        Charles Arnold 
date:        Fri Oct 26 12:05:08 2012 +0100
    
    pygrub: Add option to list grub entries
    
    The argument to "--entry" allows 2 syntaxes, either directly the entry
    number in menu.lst, or the whole string behind the "title" key word.
    This poses the following issue:
    
    From Dom0 there is no way to guess the number and, or the complete
    title string because this string contains the kernel version, which
    will change with a kernel update.
    
    This patch adds [-l|--list-entries] as an argument to pygrub.
    
    Signed-off-by: Charles Arnold 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26113:03af0abd2b72
user:        Ian Campbell 
date:        Fri Oct 26 12:03:12 2012 +0100
    
    xl: Do not leak events when a domain exits.
    
    The goto in both of these places misses the event free which would
    normally clean up.
    
    ==8655== 80 bytes in 1 blocks are definitely lost in loss record 1 of 1
    ==8655==    at 0x4024370: calloc (vg_replace_malloc.c:593)
    ==8655==    by 0x406EAAE: libxl__zalloc (libxl_internal.c:83)
    ==8655==    by 0x4078173: libxl__event_new (libxl_event.c:1167)
    ==8655==    by 0x4056373: domain_death_occurred (libxl.c:958)
    ==8655==    by 0x4058D06: domain_death_xswatch_callback (libxl.c:1038)
    ==8655==    by 0x4078EB5: watchfd_callback (libxl_event.c:458)
    ==8655==    by 0x407839E: afterpoll_internal (libxl_event.c:949)
    ==8655==    by 0x4079142: eventloop_iteration (libxl_event.c:1371)
    ==8655==    by 0x40799BB: libxl_event_wait (libxl_event.c:1396)
    ==8655==    by 0x805CC67: create_domain (xl_cmdimpl.c:1698)
    ==8655==    by 0x805E001: main_create (xl_cmdimpl.c:3986)
    ==8655==    by 0x804D43D: main (xl.c:285)
    
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26112:d07692b5c780
user:        Ian Jackson 
date:        Fri Oct 26 11:39:42 2012 +0100
    
    Revert 26109:6ccfe4d29f95
    
    This changeset was contaminated by changes hanging around in my
    working tree.  Sorry :-(.
    
    Signed-off-by: Ian Jackson 
    
    
changeset:   26111:c26e1a79fe77
user:        Christoph Egger 
date:        Thu Oct 25 17:12:55 2012 +0100
    
    libxl: NetBSD PCI passthrough support
    
    Add PCI passthrough support for HVM guests.
    
    Signed-off-by: Christoph Egger 
    Committed-by: Ian Jackson 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 27 06:47:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 06:47:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TS0AP-00063b-40; Sat, 27 Oct 2012 06:46:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TS0AN-00063V-I7
	for xen-devel@lists.xensource.com; Sat, 27 Oct 2012 06:46:43 +0000
Received: from [85.158.139.211:10653] by server-15.bemta-5.messagelabs.com id
	C9/A0-26920-2538B805; Sat, 27 Oct 2012 06:46:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1351320401!23873040!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23770 invoked from network); 27 Oct 2012 06:46:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Oct 2012 06:46:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,659,1344211200"; d="scan'208";a="15428299"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Oct 2012 06:46:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sat, 27 Oct 2012 07:46:40 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TS0AK-0005xU-BE;
	Sat, 27 Oct 2012 06:46:40 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TS0AK-0005dH-Am;
	Sat, 27 Oct 2012 07:46:40 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Sat, 27 Oct 2012 07:46:40 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 14094: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14094 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14094/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pv            3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-pv             3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-xl-multivcpu  3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-xl            3 host-install(3)         broken REGR. vs. 14076
 test-amd64-amd64-pv           3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-rhel6hvm-amd  3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)       broken REGR. vs. 14076
 test-i386-i386-xl             3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-pair         4 host-install/dst_host(4) broken REGR. vs. 14076
 test-amd64-i386-pair         3 host-install/src_host(3) broken REGR. vs. 14076
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 14076
 test-amd64-amd64-xl-qemuu-win7-amd64  3 host-install(3) broken REGR. vs. 14076
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 14076
 test-amd64-i386-xend-winxpsp3  3 host-install(3)        broken REGR. vs. 14076
 test-amd64-i386-xl-win7-amd64  3 host-install(3)        broken REGR. vs. 14076
 test-amd64-i386-xl-winxpsp3-vcpus1  3 host-install(3)   broken REGR. vs. 14076
 test-amd64-i386-win           3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 14076
 test-amd64-amd64-xl-win       3 host-install(3)         broken REGR. vs. 14076

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3)     broken pass in 14090
 test-amd64-amd64-xl           3 host-install(3)           broken pass in 14085
 test-i386-i386-pair           4 host-install/dst_host(4)  broken pass in 14090
 test-i386-i386-pair           3 host-install/src_host(3)  broken pass in 14090
 test-amd64-amd64-pair         3 host-install/src_host(3)  broken pass in 14090
 test-amd64-amd64-pair         4 host-install/dst_host(4)  broken pass in 14090
 test-amd64-i386-qemuu-rhel6hvm-intel 3 host-install(3) broken in 14090 pass in 14094
 test-i386-i386-win            7 windows-install    fail in 14085 pass in 14094

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)      broken REGR. vs. 14076
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)         broken REGR. vs. 14076
 test-amd64-amd64-xl-sedf      3 host-install(3)         broken REGR. vs. 14076

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  25eda7e7b4e6
baseline version:
 xen                  40ccbee890e1

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla 
  Bastian Blank 
  Chuang Cao 
  George Dunlap 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jason McCarver 
  Joe Jin 
  Keir Fraser 
  Matt Wilson 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Sander Eikelenboom 
  Stefano Stabellini 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          broken  
 test-amd64-i386-xl                                           broken  
 test-i386-i386-xl                                            broken  
 test-amd64-i386-rhel6hvm-amd                                 broken  
 test-amd64-i386-qemuu-rhel6hvm-amd                           broken  
 test-amd64-amd64-xl-qemuu-win7-amd64                         broken  
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        broken  
 test-amd64-i386-pair                                         broken  
 test-i386-i386-pair                                          broken  
 test-amd64-amd64-xl-sedf-pin                                 broken  
 test-amd64-amd64-pv                                          broken  
 test-amd64-i386-pv                                           broken  
 test-i386-i386-pv                                            broken  
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           broken  
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          broken  
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      broken  
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                broken  
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 612 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 27 06:47:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 06:47:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TS0AP-00063b-40; Sat, 27 Oct 2012 06:46:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TS0AN-00063V-I7
	for xen-devel@lists.xensource.com; Sat, 27 Oct 2012 06:46:43 +0000
Received: from [85.158.139.211:10653] by server-15.bemta-5.messagelabs.com id
	C9/A0-26920-2538B805; Sat, 27 Oct 2012 06:46:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1351320401!23873040!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23770 invoked from network); 27 Oct 2012 06:46:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Oct 2012 06:46:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,659,1344211200"; d="scan'208";a="15428299"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Oct 2012 06:46:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sat, 27 Oct 2012 07:46:40 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TS0AK-0005xU-BE;
	Sat, 27 Oct 2012 06:46:40 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TS0AK-0005dH-Am;
	Sat, 27 Oct 2012 07:46:40 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Sat, 27 Oct 2012 07:46:40 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 14094: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14094 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14094/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pv            3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-pv             3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-xl-multivcpu  3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-xl            3 host-install(3)         broken REGR. vs. 14076
 test-amd64-amd64-pv           3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-rhel6hvm-amd  3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)       broken REGR. vs. 14076
 test-i386-i386-xl             3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-pair         4 host-install/dst_host(4) broken REGR. vs. 14076
 test-amd64-i386-pair         3 host-install/src_host(3) broken REGR. vs. 14076
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 14076
 test-amd64-amd64-xl-qemuu-win7-amd64  3 host-install(3) broken REGR. vs. 14076
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 14076
 test-amd64-i386-xend-winxpsp3  3 host-install(3)        broken REGR. vs. 14076
 test-amd64-i386-xl-win7-amd64  3 host-install(3)        broken REGR. vs. 14076
 test-amd64-i386-xl-winxpsp3-vcpus1  3 host-install(3)   broken REGR. vs. 14076
 test-amd64-i386-win           3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 14076
 test-amd64-amd64-xl-win       3 host-install(3)         broken REGR. vs. 14076

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3)     broken pass in 14090
 test-amd64-amd64-xl           3 host-install(3)           broken pass in 14085
 test-i386-i386-pair           4 host-install/dst_host(4)  broken pass in 14090
 test-i386-i386-pair           3 host-install/src_host(3)  broken pass in 14090
 test-amd64-amd64-pair         3 host-install/src_host(3)  broken pass in 14090
 test-amd64-amd64-pair         4 host-install/dst_host(4)  broken pass in 14090
 test-amd64-i386-qemuu-rhel6hvm-intel 3 host-install(3) broken in 14090 pass in 14094
 test-i386-i386-win            7 windows-install    fail in 14085 pass in 14094

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)      broken REGR. vs. 14076
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)         broken REGR. vs. 14076
 test-amd64-amd64-xl-sedf      3 host-install(3)         broken REGR. vs. 14076

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  25eda7e7b4e6
baseline version:
 xen                  40ccbee890e1

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla 
  Bastian Blank 
  Chuang Cao 
  George Dunlap 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jason McCarver 
  Joe Jin 
  Keir Fraser 
  Matt Wilson 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Sander Eikelenboom 
  Stefano Stabellini 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          broken  
 test-amd64-i386-xl                                           broken  
 test-i386-i386-xl                                            broken  
 test-amd64-i386-rhel6hvm-amd                                 broken  
 test-amd64-i386-qemuu-rhel6hvm-amd                           broken  
 test-amd64-amd64-xl-qemuu-win7-amd64                         broken  
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        broken  
 test-amd64-i386-pair                                         broken  
 test-i386-i386-pair                                          broken  
 test-amd64-amd64-xl-sedf-pin                                 broken  
 test-amd64-amd64-pv                                          broken  
 test-amd64-i386-pv                                           broken  
 test-i386-i386-pv                                            broken  
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           broken  
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          broken  
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      broken  
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                broken  
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 612 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 27 10:10:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 10:10:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TS3Kj-0000hN-Aa; Sat, 27 Oct 2012 10:09:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TS3Ki-0000hH-Fk
	for xen-devel@lists.xensource.com; Sat, 27 Oct 2012 10:09:36 +0000
Received: from [85.158.143.35:14256] by server-2.bemta-4.messagelabs.com id
	3E/37-22268-FD2BB805; Sat, 27 Oct 2012 10:09:35 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-21.messagelabs.com!1351332575!5308792!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1847 invoked from network); 27 Oct 2012 10:09:35 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Oct 2012 10:09:35 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TS3Kb-000NQE-N6; Sat, 27 Oct 2012 10:09:29 +0000
Date: Sat, 27 Oct 2012 11:09:29 +0100
From: Tim Deegan 
To: Ian Campbell 
Message-ID: <20121027100929.GA89901@ocelot.phlegethon.org>
References: 
	<1351091027-20740-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1351157246.18035.129.camel@zakaz.uk.xensource.com>
	
	<1351269622.15162.105.camel@zakaz.uk.xensource.com>
	
	<1351284440.12176.9.camel@dagon.hellion.org.uk>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1351284440.12176.9.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 1/7] xen/arm: fix rank calculation in
	vgic_vcpu_inject_irq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 21:47 +0100 on 26 Oct (1351288040), Ian Campbell wrote:
> On Fri, 2012-10-26 at 19:42 +0100, Stefano Stabellini wrote:
> > I think that the problem is the usage of vgic_irq_rank with registers
> > that have 1 bit per interrupt.
> 
> That's very plausible indeed.
> 
> > diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> > index 3c3983f..92731b6 100644
> > --- a/xen/arch/arm/vgic.c
> > +++ b/xen/arch/arm/vgic.c
> > @@ -42,13 +42,7 @@
> >   */
> >  static inline int REG_RANK_NR(int b, uint32_t n)
> >  {
> > -    switch ( b )
> > -    {
> > -    case 8: return n >> 3;
> > -    case 4: return n >> 2;
> > -    case 2: return n >> 1;
> > -    default: BUG();
> > -    }
> > +    return n / b;
> 
> All the infrastructure will fall apart if b isn't a power of two, that's
> why I used the switch. Can you just add the appropriate case 1 instead?
> Probably the bug should be a call to an undefined function to make this
> a compile time rather than runtime failure too.

BUILD_BUG_ON((b & -b) != b); ?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 27 10:10:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 10:10:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TS3Kj-0000hN-Aa; Sat, 27 Oct 2012 10:09:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TS3Ki-0000hH-Fk
	for xen-devel@lists.xensource.com; Sat, 27 Oct 2012 10:09:36 +0000
Received: from [85.158.143.35:14256] by server-2.bemta-4.messagelabs.com id
	3E/37-22268-FD2BB805; Sat, 27 Oct 2012 10:09:35 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-21.messagelabs.com!1351332575!5308792!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1847 invoked from network); 27 Oct 2012 10:09:35 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Oct 2012 10:09:35 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TS3Kb-000NQE-N6; Sat, 27 Oct 2012 10:09:29 +0000
Date: Sat, 27 Oct 2012 11:09:29 +0100
From: Tim Deegan 
To: Ian Campbell 
Message-ID: <20121027100929.GA89901@ocelot.phlegethon.org>
References: 
	<1351091027-20740-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1351157246.18035.129.camel@zakaz.uk.xensource.com>
	
	<1351269622.15162.105.camel@zakaz.uk.xensource.com>
	
	<1351284440.12176.9.camel@dagon.hellion.org.uk>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1351284440.12176.9.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 1/7] xen/arm: fix rank calculation in
	vgic_vcpu_inject_irq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 21:47 +0100 on 26 Oct (1351288040), Ian Campbell wrote:
> On Fri, 2012-10-26 at 19:42 +0100, Stefano Stabellini wrote:
> > I think that the problem is the usage of vgic_irq_rank with registers
> > that have 1 bit per interrupt.
> 
> That's very plausible indeed.
> 
> > diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> > index 3c3983f..92731b6 100644
> > --- a/xen/arch/arm/vgic.c
> > +++ b/xen/arch/arm/vgic.c
> > @@ -42,13 +42,7 @@
> >   */
> >  static inline int REG_RANK_NR(int b, uint32_t n)
> >  {
> > -    switch ( b )
> > -    {
> > -    case 8: return n >> 3;
> > -    case 4: return n >> 2;
> > -    case 2: return n >> 1;
> > -    default: BUG();
> > -    }
> > +    return n / b;
> 
> All the infrastructure will fall apart if b isn't a power of two, that's
> why I used the switch. Can you just add the appropriate case 1 instead?
> Probably the bug should be a call to an undefined function to make this
> a compile time rather than runtime failure too.

BUILD_BUG_ON((b & -b) != b); ?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 27 10:45:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 10:45:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TS3sX-0001Ts-LH; Sat, 27 Oct 2012 10:44:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TS3sW-0001Tn-Dy
	for xen-devel@lists.xensource.com; Sat, 27 Oct 2012 10:44:32 +0000
Received: from [85.158.139.83:40657] by server-8.bemta-5.messagelabs.com id
	1B/0E-23193-F0BBB805; Sat, 27 Oct 2012 10:44:31 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-182.messagelabs.com!1351334670!27846567!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32552 invoked from network); 27 Oct 2012 10:44:31 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Oct 2012 10:44:31 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TS3sT-000NV5-0i; Sat, 27 Oct 2012 10:44:29 +0000
Date: Sat, 27 Oct 2012 11:44:28 +0100
From: Tim Deegan 
To: Stefano Stabellini 
Message-ID: <20121027104428.GB89901@ocelot.phlegethon.org>
References: 
	<1351091027-20740-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20121024155945.GD39126@ocelot.phlegethon.org>
	
	<20121026090141.GB76080@ocelot.phlegethon.org>
	
	
	
	<20121026165549.GF76080@ocelot.phlegethon.org>
	
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" ,
	Ian Campbell 
Subject: Re: [Xen-devel] [PATCH 6/7] xen/arm: flush D-cache and I-cache when
	appropriate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 19:40 +0100 on 26 Oct (1351280413), Stefano Stabellini wrote:
> > No!  It's always safe to flush the entire line -- regardless of what
> > other writes might be happening to it.  After all, the cache controller
> > might evict that line on its own at any time, so nothing can be relying
> > on its _not_ being flushed.
> > 
> > The only problem with not knowing how big a cacheline is is this: if the
> > object is _bigger_ than a cache line we might use one DCCMVAC where more
> > than one is needed.  We can avoid that by a compile-time check on some
> > sort of architectural minimum cacheline size.
>  
> If we want to do that then we need to pass a size argument to
> flush_xen_dcache_va and have a loop in the function, each iteration
> flushing a cacheline:
> 
> static inline void flush_xen_dcache_va(void *p, unsigned long size)
> {
>     unsigned long cacheline_size = READ_CP32(CCSIDR);
>     unsigned long i;
>     for (i = 0; i < size; i += cacheline_size, p += cacheline_size) {
>         asm volatile (
>             "dsb;"
>             STORE_CP32(0, DCCMVAC)
>             "dsb;"
>             : : "r" (p));
>     }
> }

I think we should have two functions.  One should look almost like that
and be for flushing large ranges, and one much simpler for flushing
small items.  Like this (totally untested, uncompiled even):

 #define MIN_CACHELINE_BYTES 32 // or whatever

 /* In setup.c somewhere. */
 if ( READ_CP32(CCSIDR) < MIN_CACHELINE_BYTES )
     panic("CPU has preposterously small cache lines");

 /* Function for flushing medium-sized areas.
  * if 'range' is large enough we might want to use model-specific
  * full-cache flushes. */
 static inline void flush_xen_dcache_va_range(void *p, unsigned long size)
 {
     void *end;
     unsigned long cacheline_bytes = READ_CP32(CCSIDR);
     barrier();       /* So the compiler issues all writes to the range */
     dsb();           /* So the CPU issues all writes to the range */ 
     for ( end = p + size; p < end; p += cacheline_bytes )
         WRITE_CP32(DCCMVAC, p);
     dsb();           /* So we know the flushes happen before continuing */
 }

 /* Macro for flushing a single small item.  The predicate is always 
  * compile-time constant so this will compile down to 3 instructions in
  * the common case.  Make sure to call it with the correct type of
  * pointer! */
 #define flush_xen_dcache_va(p) do {                       \
     typeof(p) _p = (p);                                   \
     if ( (sizeof *_p) > MIN_CACHELINE_BYTES )             \
         flush_xen_dcache_va_range(_p, sizeof *_p);        \
     else                                                  \
         asm volatile (                                    \
             "dsb;"   /* Finish all earlier writes */      \
             STORE_CP32(0, DCCMVAC)                        \
             "dsb;"   /* Finish flush before continuing */ \
             : : "r" (_p), "m" (*_p));                     \
 } while (0)

What do you think?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 27 10:45:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 10:45:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TS3sX-0001Ts-LH; Sat, 27 Oct 2012 10:44:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TS3sW-0001Tn-Dy
	for xen-devel@lists.xensource.com; Sat, 27 Oct 2012 10:44:32 +0000
Received: from [85.158.139.83:40657] by server-8.bemta-5.messagelabs.com id
	1B/0E-23193-F0BBB805; Sat, 27 Oct 2012 10:44:31 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-182.messagelabs.com!1351334670!27846567!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32552 invoked from network); 27 Oct 2012 10:44:31 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Oct 2012 10:44:31 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TS3sT-000NV5-0i; Sat, 27 Oct 2012 10:44:29 +0000
Date: Sat, 27 Oct 2012 11:44:28 +0100
From: Tim Deegan 
To: Stefano Stabellini 
Message-ID: <20121027104428.GB89901@ocelot.phlegethon.org>
References: 
	<1351091027-20740-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20121024155945.GD39126@ocelot.phlegethon.org>
	
	<20121026090141.GB76080@ocelot.phlegethon.org>
	
	
	
	<20121026165549.GF76080@ocelot.phlegethon.org>
	
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" ,
	Ian Campbell 
Subject: Re: [Xen-devel] [PATCH 6/7] xen/arm: flush D-cache and I-cache when
	appropriate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 19:40 +0100 on 26 Oct (1351280413), Stefano Stabellini wrote:
> > No!  It's always safe to flush the entire line -- regardless of what
> > other writes might be happening to it.  After all, the cache controller
> > might evict that line on its own at any time, so nothing can be relying
> > on its _not_ being flushed.
> > 
> > The only problem with not knowing how big a cacheline is is this: if the
> > object is _bigger_ than a cache line we might use one DCCMVAC where more
> > than one is needed.  We can avoid that by a compile-time check on some
> > sort of architectural minimum cacheline size.
>  
> If we want to do that then we need to pass a size argument to
> flush_xen_dcache_va and have a loop in the function, each iteration
> flushing a cacheline:
> 
> static inline void flush_xen_dcache_va(void *p, unsigned long size)
> {
>     unsigned long cacheline_size = READ_CP32(CCSIDR);
>     unsigned long i;
>     for (i = 0; i < size; i += cacheline_size, p += cacheline_size) {
>         asm volatile (
>             "dsb;"
>             STORE_CP32(0, DCCMVAC)
>             "dsb;"
>             : : "r" (p));
>     }
> }

I think we should have two functions.  One should look almost like that
and be for flushing large ranges, and one much simpler for flushing
small items.  Like this (totally untested, uncompiled even):

 #define MIN_CACHELINE_BYTES 32 // or whatever

 /* In setup.c somewhere. */
 if ( READ_CP32(CCSIDR) < MIN_CACHELINE_BYTES )
     panic("CPU has preposterously small cache lines");

 /* Function for flushing medium-sized areas.
  * if 'range' is large enough we might want to use model-specific
  * full-cache flushes. */
 static inline void flush_xen_dcache_va_range(void *p, unsigned long size)
 {
     void *end;
     unsigned long cacheline_bytes = READ_CP32(CCSIDR);
     barrier();       /* So the compiler issues all writes to the range */
     dsb();           /* So the CPU issues all writes to the range */ 
     for ( end = p + size; p < end; p += cacheline_bytes )
         WRITE_CP32(DCCMVAC, p);
     dsb();           /* So we know the flushes happen before continuing */
 }

 /* Macro for flushing a single small item.  The predicate is always 
  * compile-time constant so this will compile down to 3 instructions in
  * the common case.  Make sure to call it with the correct type of
  * pointer! */
 #define flush_xen_dcache_va(p) do {                       \
     typeof(p) _p = (p);                                   \
     if ( (sizeof *_p) > MIN_CACHELINE_BYTES )             \
         flush_xen_dcache_va_range(_p, sizeof *_p);        \
     else                                                  \
         asm volatile (                                    \
             "dsb;"   /* Finish all earlier writes */      \
             STORE_CP32(0, DCCMVAC)                        \
             "dsb;"   /* Finish flush before continuing */ \
             : : "r" (_p), "m" (*_p));                     \
 } while (0)

What do you think?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 27 10:45:12 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 10:45:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TS3si-0001UL-1W; Sat, 27 Oct 2012 10:44:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TS3sg-0001UB-Sa
	for xen-devel@lists.xensource.com; Sat, 27 Oct 2012 10:44:42 +0000
Received: from [85.158.138.51:51354] by server-7.bemta-3.messagelabs.com id
	92/B2-06991-51BBB805; Sat, 27 Oct 2012 10:44:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1351334676!27702141!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY0NTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32176 invoked from network); 27 Oct 2012 10:44:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Oct 2012 10:44:37 -0000
X-IronPort-AV: E=Sophos;i="4.80,660,1344211200"; d="scan'208";a="15431419"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Oct 2012 10:44:36 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Sat, 27 Oct 2012 11:44:35 +0100
Message-ID: <1351334675.12176.13.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Tim Deegan 
Date: Sat, 27 Oct 2012 11:44:35 +0100
In-Reply-To: <20121027100929.GA89901@ocelot.phlegethon.org>
References: 
	<1351091027-20740-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1351157246.18035.129.camel@zakaz.uk.xensource.com>
	
	<1351269622.15162.105.camel@zakaz.uk.xensource.com>
	
	<1351284440.12176.9.camel@dagon.hellion.org.uk>
	<20121027100929.GA89901@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 1/7] xen/arm: fix rank calculation in
 vgic_vcpu_inject_irq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 2012-10-27 at 11:09 +0100, Tim Deegan wrote:
> At 21:47 +0100 on 26 Oct (1351288040), Ian Campbell wrote:
> > All the infrastructure will fall apart if b isn't a power of two, that's
> > why I used the switch. Can you just add the appropriate case 1 instead?
> > Probably the bug should be a call to an undefined function to make this
> > a compile time rather than runtime failure too.
> 
> BUILD_BUG_ON((b & -b) != b); ?

Sure.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 27 10:45:12 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 10:45:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TS3si-0001UL-1W; Sat, 27 Oct 2012 10:44:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TS3sg-0001UB-Sa
	for xen-devel@lists.xensource.com; Sat, 27 Oct 2012 10:44:42 +0000
Received: from [85.158.138.51:51354] by server-7.bemta-3.messagelabs.com id
	92/B2-06991-51BBB805; Sat, 27 Oct 2012 10:44:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1351334676!27702141!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY0NTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32176 invoked from network); 27 Oct 2012 10:44:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Oct 2012 10:44:37 -0000
X-IronPort-AV: E=Sophos;i="4.80,660,1344211200"; d="scan'208";a="15431419"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Oct 2012 10:44:36 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Sat, 27 Oct 2012 11:44:35 +0100
Message-ID: <1351334675.12176.13.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Tim Deegan 
Date: Sat, 27 Oct 2012 11:44:35 +0100
In-Reply-To: <20121027100929.GA89901@ocelot.phlegethon.org>
References: 
	<1351091027-20740-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1351157246.18035.129.camel@zakaz.uk.xensource.com>
	
	<1351269622.15162.105.camel@zakaz.uk.xensource.com>
	
	<1351284440.12176.9.camel@dagon.hellion.org.uk>
	<20121027100929.GA89901@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 1/7] xen/arm: fix rank calculation in
 vgic_vcpu_inject_irq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 2012-10-27 at 11:09 +0100, Tim Deegan wrote:
> At 21:47 +0100 on 26 Oct (1351288040), Ian Campbell wrote:
> > All the infrastructure will fall apart if b isn't a power of two, that's
> > why I used the switch. Can you just add the appropriate case 1 instead?
> > Probably the bug should be a call to an undefined function to make this
> > a compile time rather than runtime failure too.
> 
> BUILD_BUG_ON((b & -b) != b); ?

Sure.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 27 10:45:59 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 10:45:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TS3tS-0001ZG-FA; Sat, 27 Oct 2012 10:45:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TS3tR-0001Z5-Nz
	for xen-devel@lists.xen.org; Sat, 27 Oct 2012 10:45:29 +0000
Received: from [85.158.139.83:41837] by server-3.bemta-5.messagelabs.com id
	7A/85-28618-84BBB805; Sat, 27 Oct 2012 10:45:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1351334728!27027267!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY0NTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13038 invoked from network); 27 Oct 2012 10:45:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Oct 2012 10:45:28 -0000
X-IronPort-AV: E=Sophos;i="4.80,660,1344211200"; d="scan'208";a="15431425"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Oct 2012 10:45:28 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Sat, 27 Oct 2012 11:45:27 +0100
Message-ID: <1351334727.12176.14.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Roger Cruz 
Date: Sat, 27 Oct 2012 11:45:27 +0100
In-Reply-To: <844D15D284C78547BB0DAEE12D33A1B67C212BB95A@FTLPMAILBOX02.citrite.net>
References: <844D15D284C78547BB0DAEE12D33A1B67C212BB956@FTLPMAILBOX02.citrite.net>
	<844D15D284C78547BB0DAEE12D33A1B67C212BB958@FTLPMAILBOX02.citrite.net>
	,<1351276718.12176.1.camel@dagon.hellion.org.uk>
	<844D15D284C78547BB0DAEE12D33A1B67C212BB95A@FTLPMAILBOX02.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Tracking down a boot speed issue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Please don't top-post.

On Fri, 2012-10-26 at 19:55 +0100, Roger Cruz wrote:
> So if I understand your response correctly.. the time displayed will
> always be zero until the per_cpu area is set up? 

Correct.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 27 10:45:59 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 10:45:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TS3tS-0001ZG-FA; Sat, 27 Oct 2012 10:45:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TS3tR-0001Z5-Nz
	for xen-devel@lists.xen.org; Sat, 27 Oct 2012 10:45:29 +0000
Received: from [85.158.139.83:41837] by server-3.bemta-5.messagelabs.com id
	7A/85-28618-84BBB805; Sat, 27 Oct 2012 10:45:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1351334728!27027267!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY0NTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13038 invoked from network); 27 Oct 2012 10:45:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Oct 2012 10:45:28 -0000
X-IronPort-AV: E=Sophos;i="4.80,660,1344211200"; d="scan'208";a="15431425"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Oct 2012 10:45:28 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Sat, 27 Oct 2012 11:45:27 +0100
Message-ID: <1351334727.12176.14.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Roger Cruz 
Date: Sat, 27 Oct 2012 11:45:27 +0100
In-Reply-To: <844D15D284C78547BB0DAEE12D33A1B67C212BB95A@FTLPMAILBOX02.citrite.net>
References: <844D15D284C78547BB0DAEE12D33A1B67C212BB956@FTLPMAILBOX02.citrite.net>
	<844D15D284C78547BB0DAEE12D33A1B67C212BB958@FTLPMAILBOX02.citrite.net>
	,<1351276718.12176.1.camel@dagon.hellion.org.uk>
	<844D15D284C78547BB0DAEE12D33A1B67C212BB95A@FTLPMAILBOX02.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Tracking down a boot speed issue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Please don't top-post.

On Fri, 2012-10-26 at 19:55 +0100, Roger Cruz wrote:
> So if I understand your response correctly.. the time displayed will
> always be zero until the per_cpu area is set up? 

Correct.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 27 10:47:56 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 10:47:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TS3vT-0001kN-0r; Sat, 27 Oct 2012 10:47:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TS3vS-0001kF-1p
	for xen-devel@lists.xen.org; Sat, 27 Oct 2012 10:47:34 +0000
Received: from [85.158.138.51:58368] by server-9.bemta-3.messagelabs.com id
	64/1B-16841-5CBBB805; Sat, 27 Oct 2012 10:47:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1351334852!27671352!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY0NTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2667 invoked from network); 27 Oct 2012 10:47:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Oct 2012 10:47:32 -0000
X-IronPort-AV: E=Sophos;i="4.80,660,1344211200"; d="scan'208";a="15431431"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Oct 2012 10:46:17 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Sat, 27 Oct 2012 11:46:17 +0100
Message-ID: <1351334777.12176.15.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Roger Cruz 
Date: Sat, 27 Oct 2012 11:46:17 +0100
In-Reply-To: <844D15D284C78547BB0DAEE12D33A1B67C212BB95B@FTLPMAILBOX02.citrite.net>
References: <844D15D284C78547BB0DAEE12D33A1B67C212BB956@FTLPMAILBOX02.citrite.net>
	<844D15D284C78547BB0DAEE12D33A1B67C212BB958@FTLPMAILBOX02.citrite.net>
	,<1351276718.12176.1.camel@dagon.hellion.org.uk>
	<844D15D284C78547BB0DAEE12D33A1B67C212BB95B@FTLPMAILBOX02.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Tracking down a boot speed issue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-26 at 20:02 +0100, Roger Cruz wrote:
> A question remains in my mind as why the times are variable.  Why does
> it take .67 secs and 1.6 secs other times for exactly the same boot
> code?

Something before this point takes a variable amount of time perhaps? I
don't know what happens before this point in the boot.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 27 10:47:56 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 10:47:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TS3vT-0001kN-0r; Sat, 27 Oct 2012 10:47:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TS3vS-0001kF-1p
	for xen-devel@lists.xen.org; Sat, 27 Oct 2012 10:47:34 +0000
Received: from [85.158.138.51:58368] by server-9.bemta-3.messagelabs.com id
	64/1B-16841-5CBBB805; Sat, 27 Oct 2012 10:47:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1351334852!27671352!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY0NTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2667 invoked from network); 27 Oct 2012 10:47:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Oct 2012 10:47:32 -0000
X-IronPort-AV: E=Sophos;i="4.80,660,1344211200"; d="scan'208";a="15431431"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Oct 2012 10:46:17 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Sat, 27 Oct 2012 11:46:17 +0100
Message-ID: <1351334777.12176.15.camel@dagon.hellion.org.uk>
From: Ian Campbell 
To: Roger Cruz 
Date: Sat, 27 Oct 2012 11:46:17 +0100
In-Reply-To: <844D15D284C78547BB0DAEE12D33A1B67C212BB95B@FTLPMAILBOX02.citrite.net>
References: <844D15D284C78547BB0DAEE12D33A1B67C212BB956@FTLPMAILBOX02.citrite.net>
	<844D15D284C78547BB0DAEE12D33A1B67C212BB958@FTLPMAILBOX02.citrite.net>
	,<1351276718.12176.1.camel@dagon.hellion.org.uk>
	<844D15D284C78547BB0DAEE12D33A1B67C212BB95B@FTLPMAILBOX02.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Tracking down a boot speed issue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-26 at 20:02 +0100, Roger Cruz wrote:
> A question remains in my mind as why the times are variable.  Why does
> it take .67 secs and 1.6 secs other times for exactly the same boot
> code?

Something before this point takes a variable amount of time perhaps? I
don't know what happens before this point in the boot.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 27 11:06:44 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 11:06:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TS4Dd-0002Kq-PJ; Sat, 27 Oct 2012 11:06:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TS4Db-0002Kl-Nb
	for xen-devel@lists.xen.org; Sat, 27 Oct 2012 11:06:19 +0000
Received: from [85.158.143.35:47614] by server-1.bemta-4.messagelabs.com id
	DB/B8-19134-B20CB805; Sat, 27 Oct 2012 11:06:19 +0000
X-Env-Sender: mva@mva.name
X-Msg-Ref: server-15.tower-21.messagelabs.com!1351335976!14054925!1
X-Originating-IP: [77.88.61.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzcuODguNjEuNDkgPT4gMTU3Mjc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29676 invoked from network); 27 Oct 2012 11:06:17 -0000
Received: from forward10.mail.yandex.net (HELO forward10.mail.yandex.net)
	(77.88.61.49) by server-15.tower-21.messagelabs.com with SMTP;
	27 Oct 2012 11:06:17 -0000
Received: from smtp7.mail.yandex.net (smtp7.mail.yandex.net [77.88.61.55])
	by forward10.mail.yandex.net (Yandex) with ESMTP id B6C7310212F1
	for ; Sat, 27 Oct 2012 15:06:16 +0400 (MSK)
Received: from smtp7.mail.yandex.net (localhost [127.0.0.1])
	by smtp7.mail.yandex.net (Yandex) with ESMTP id A0DC61580715
	for ; Sat, 27 Oct 2012 15:06:16 +0400 (MSK)
Received: from host-109-171-17-91.bbcustomer.zsttk.net
	(host-109-171-17-91.bbcustomer.zsttk.net [109.171.17.91])
	by smtp7.mail.yandex.net (nwsmtp/Yandex) with ESMTP id
	6GPWLIaN-6GPKiBdm; Sat, 27 Oct 2012 15:06:16 +0400
Message-ID: <508BC02B.5040607@mva.name>
Date: Sat, 27 Oct 2012 18:06:19 +0700
From: "Vadim A. Misbakh-Soloviov" 
Organization: Alpha LLC
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120923 Firefox/15.0.1 Thunderbird/15.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" 
X-Enigmail-Version: 1.4.4
Subject: [Xen-devel] Problem with growing up dom0 memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============5168461267363430868=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============5168461267363430868==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig11FE9DC347CDF93AACE8D31F"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig11FE9DC347CDF93AACE8D31F
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello there!
I know, that it is "not so good practice", but anyway when I try to grow
up dom0 memory with xm =E2=80=94 I get following thing:

node1 mva % xm list
Name ID Mem VCPUs State Time(s)
Domain-0 0 14287 8 r----- 255128.8
node1 mva % xm mem-set Domain-0 24G
node1 mva % xm list
Name ID Mem VCPUs State Time(s)
Domain-0 0 13957 8 r----- 255131.4
node1 mva % xm mem-set Domain-0 24G
node1 mva % xm list
Name ID Mem VCPUs State Time(s)
Domain-0 0 13626 8 r----- 255138.9

And it shrinks more and more every time.

When I try to do it with xl =E2=80=94 i get following:

node1 ~mva % xl mem-set Domain-0 24g
libxl: error: libxl.c:2125:libxl_set_memory_target cannot get memory
info from /local/domain/0/memory/static-max
: No such file or directory



And, by the way, on another node I also have following issue:
node1 ~mva % xl cpupool-list
libxl: error: libxl.c:596:cpupool_info: failed to get info for cpupool1
: No such file or directory
Name               CPUs   Sched     Active   Domain count
Pool-0              12    credit       y         13


And it is some more places where I get errors with xl.

--
Best regards,
mva


--------------enig11FE9DC347CDF93AACE8D31F
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQi8ArAAoJECZQPTSbOzNLr3MQAMbLeNODTDRUlc3y5zFF9Mnt
9JgmMBJEZo6YtuJ7St6664PIsES0KBO/CLTd7f/uixJkCNem3YNSzw5TfDoXqlPW
RjRzHp6m90ksYNfErC+ifdMTYCUAxfwF9yG0EsTuFNdZWhqRO7zyIOrWverCcswo
ZpknOCvxt3bZe4Rr+WgqGni7WCQN47Nh9lOyROZTBcAKHFPojXglTwOUNcLiJM8s
sKvyAdCUW6y9mffnFcO/2DFCTs5sSqTMwap7yyHkowFsCFyBqTuHxSVR6G7PJ/p2
CypYe465Yrl5ouIBJPFozzxoh9t3hjoJ7v83qHj+rXpIWcAlGQ3P3Lcn8r+H8ks9
8HCd/RyU0Jf6aePpCT1i8zXrtB+dmZsxd1EVP+5F1tfcffnmVn7a/ogoajeG1Pjp
+gCovRn8SixCUIeh+Xym7a67V/90QjrYS/2NKaqhTBLhjMXQDmOQMX/Q2YASiZ6s
e7fJ+BbwezwEgB1Q6xY6QFypfJaevJv8+FkKfdm8STH5vojlX3eqdMQDQEraBnLD
AyUtOihynMNjwEG4MXDpiqnvsB/HgkW35EhBh7kWK1oqIF6gyH1281cwgHSk1or/
5QBH/NLGbPqImglAGjI+ZPhWDwvTZx/fICCv5VvkvlNSqJeuG2ZcVkOW74kqOURH
cDMDqXIkGIIIfM9SOM8V
=mH99
-----END PGP SIGNATURE-----

--------------enig11FE9DC347CDF93AACE8D31F--


--===============5168461267363430868==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5168461267363430868==--


From xen-devel-bounces@lists.xen.org Sat Oct 27 11:06:44 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 11:06:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TS4Dd-0002Kq-PJ; Sat, 27 Oct 2012 11:06:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TS4Db-0002Kl-Nb
	for xen-devel@lists.xen.org; Sat, 27 Oct 2012 11:06:19 +0000
Received: from [85.158.143.35:47614] by server-1.bemta-4.messagelabs.com id
	DB/B8-19134-B20CB805; Sat, 27 Oct 2012 11:06:19 +0000
X-Env-Sender: mva@mva.name
X-Msg-Ref: server-15.tower-21.messagelabs.com!1351335976!14054925!1
X-Originating-IP: [77.88.61.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzcuODguNjEuNDkgPT4gMTU3Mjc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29676 invoked from network); 27 Oct 2012 11:06:17 -0000
Received: from forward10.mail.yandex.net (HELO forward10.mail.yandex.net)
	(77.88.61.49) by server-15.tower-21.messagelabs.com with SMTP;
	27 Oct 2012 11:06:17 -0000
Received: from smtp7.mail.yandex.net (smtp7.mail.yandex.net [77.88.61.55])
	by forward10.mail.yandex.net (Yandex) with ESMTP id B6C7310212F1
	for ; Sat, 27 Oct 2012 15:06:16 +0400 (MSK)
Received: from smtp7.mail.yandex.net (localhost [127.0.0.1])
	by smtp7.mail.yandex.net (Yandex) with ESMTP id A0DC61580715
	for ; Sat, 27 Oct 2012 15:06:16 +0400 (MSK)
Received: from host-109-171-17-91.bbcustomer.zsttk.net
	(host-109-171-17-91.bbcustomer.zsttk.net [109.171.17.91])
	by smtp7.mail.yandex.net (nwsmtp/Yandex) with ESMTP id
	6GPWLIaN-6GPKiBdm; Sat, 27 Oct 2012 15:06:16 +0400
Message-ID: <508BC02B.5040607@mva.name>
Date: Sat, 27 Oct 2012 18:06:19 +0700
From: "Vadim A. Misbakh-Soloviov" 
Organization: Alpha LLC
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120923 Firefox/15.0.1 Thunderbird/15.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" 
X-Enigmail-Version: 1.4.4
Subject: [Xen-devel] Problem with growing up dom0 memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============5168461267363430868=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============5168461267363430868==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig11FE9DC347CDF93AACE8D31F"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig11FE9DC347CDF93AACE8D31F
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello there!
I know, that it is "not so good practice", but anyway when I try to grow
up dom0 memory with xm =E2=80=94 I get following thing:

node1 mva % xm list
Name ID Mem VCPUs State Time(s)
Domain-0 0 14287 8 r----- 255128.8
node1 mva % xm mem-set Domain-0 24G
node1 mva % xm list
Name ID Mem VCPUs State Time(s)
Domain-0 0 13957 8 r----- 255131.4
node1 mva % xm mem-set Domain-0 24G
node1 mva % xm list
Name ID Mem VCPUs State Time(s)
Domain-0 0 13626 8 r----- 255138.9

And it shrinks more and more every time.

When I try to do it with xl =E2=80=94 i get following:

node1 ~mva % xl mem-set Domain-0 24g
libxl: error: libxl.c:2125:libxl_set_memory_target cannot get memory
info from /local/domain/0/memory/static-max
: No such file or directory



And, by the way, on another node I also have following issue:
node1 ~mva % xl cpupool-list
libxl: error: libxl.c:596:cpupool_info: failed to get info for cpupool1
: No such file or directory
Name               CPUs   Sched     Active   Domain count
Pool-0              12    credit       y         13


And it is some more places where I get errors with xl.

--
Best regards,
mva


--------------enig11FE9DC347CDF93AACE8D31F
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQi8ArAAoJECZQPTSbOzNLr3MQAMbLeNODTDRUlc3y5zFF9Mnt
9JgmMBJEZo6YtuJ7St6664PIsES0KBO/CLTd7f/uixJkCNem3YNSzw5TfDoXqlPW
RjRzHp6m90ksYNfErC+ifdMTYCUAxfwF9yG0EsTuFNdZWhqRO7zyIOrWverCcswo
ZpknOCvxt3bZe4Rr+WgqGni7WCQN47Nh9lOyROZTBcAKHFPojXglTwOUNcLiJM8s
sKvyAdCUW6y9mffnFcO/2DFCTs5sSqTMwap7yyHkowFsCFyBqTuHxSVR6G7PJ/p2
CypYe465Yrl5ouIBJPFozzxoh9t3hjoJ7v83qHj+rXpIWcAlGQ3P3Lcn8r+H8ks9
8HCd/RyU0Jf6aePpCT1i8zXrtB+dmZsxd1EVP+5F1tfcffnmVn7a/ogoajeG1Pjp
+gCovRn8SixCUIeh+Xym7a67V/90QjrYS/2NKaqhTBLhjMXQDmOQMX/Q2YASiZ6s
e7fJ+BbwezwEgB1Q6xY6QFypfJaevJv8+FkKfdm8STH5vojlX3eqdMQDQEraBnLD
AyUtOihynMNjwEG4MXDpiqnvsB/HgkW35EhBh7kWK1oqIF6gyH1281cwgHSk1or/
5QBH/NLGbPqImglAGjI+ZPhWDwvTZx/fICCv5VvkvlNSqJeuG2ZcVkOW74kqOURH
cDMDqXIkGIIIfM9SOM8V
=mH99
-----END PGP SIGNATURE-----

--------------enig11FE9DC347CDF93AACE8D31F--


--===============5168461267363430868==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5168461267363430868==--


From xen-devel-bounces@lists.xen.org Sat Oct 27 11:41:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 11:41:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TS4kq-0002nW-MR; Sat, 27 Oct 2012 11:40:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TS4kp-0002nR-0G
	for xen-devel@lists.xensource.com; Sat, 27 Oct 2012 11:40:39 +0000
Received: from [85.158.139.211:16611] by server-11.bemta-5.messagelabs.com id
	17/5E-14870-638CB805; Sat, 27 Oct 2012 11:40:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1351338036!23930121!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY0NTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22457 invoked from network); 27 Oct 2012 11:40:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Oct 2012 11:40:36 -0000
X-IronPort-AV: E=Sophos;i="4.80,660,1344211200"; d="scan'208";a="15431620"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Oct 2012 11:40:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sat, 27 Oct 2012 12:40:34 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TS4kk-0007XC-R0;
	Sat, 27 Oct 2012 11:40:34 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TS4kk-00012p-PO;
	Sat, 27 Oct 2012 12:40:34 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Sat, 27 Oct 2012 12:40:34 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14098: trouble: blocked/broken/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14098 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14098/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   2 host-install(2)         broken REGR. vs. 14079
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 14079
 build-i386-oldkern            2 host-install(2)         broken REGR. vs. 14079

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a

version targeted for testing:
 xen                  37a8946eeb9d
baseline version:
 xen                  c26e1a79fe77

------------------------------------------------------------
People who touched revisions under test:
  Charles Arnold 
  Christoph Egger 
  Ian Campbell 
  Ian Jackson 
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   pass    
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           broken  
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26115:37a8946eeb9d
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:09:29 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    
    
changeset:   26114:6f9e46917eb8
user:        Charles Arnold 
date:        Fri Oct 26 12:05:08 2012 +0100
    
    pygrub: Add option to list grub entries
    
    The argument to "--entry" allows 2 syntaxes, either directly the entry
    number in menu.lst, or the whole string behind the "title" key word.
    This poses the following issue:
    
    From Dom0 there is no way to guess the number and, or the complete
    title string because this string contains the kernel version, which
    will change with a kernel update.
    
    This patch adds [-l|--list-entries] as an argument to pygrub.
    
    Signed-off-by: Charles Arnold 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26113:03af0abd2b72
user:        Ian Campbell 
date:        Fri Oct 26 12:03:12 2012 +0100
    
    xl: Do not leak events when a domain exits.
    
    The goto in both of these places misses the event free which would
    normally clean up.
    
    ==8655== 80 bytes in 1 blocks are definitely lost in loss record 1 of 1
    ==8655==    at 0x4024370: calloc (vg_replace_malloc.c:593)
    ==8655==    by 0x406EAAE: libxl__zalloc (libxl_internal.c:83)
    ==8655==    by 0x4078173: libxl__event_new (libxl_event.c:1167)
    ==8655==    by 0x4056373: domain_death_occurred (libxl.c:958)
    ==8655==    by 0x4058D06: domain_death_xswatch_callback (libxl.c:1038)
    ==8655==    by 0x4078EB5: watchfd_callback (libxl_event.c:458)
    ==8655==    by 0x407839E: afterpoll_internal (libxl_event.c:949)
    ==8655==    by 0x4079142: eventloop_iteration (libxl_event.c:1371)
    ==8655==    by 0x40799BB: libxl_event_wait (libxl_event.c:1396)
    ==8655==    by 0x805CC67: create_domain (xl_cmdimpl.c:1698)
    ==8655==    by 0x805E001: main_create (xl_cmdimpl.c:3986)
    ==8655==    by 0x804D43D: main (xl.c:285)
    
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26112:d07692b5c780
user:        Ian Jackson 
date:        Fri Oct 26 11:39:42 2012 +0100
    
    Revert 26109:6ccfe4d29f95
    
    This changeset was contaminated by changes hanging around in my
    working tree.  Sorry :-(.
    
    Signed-off-by: Ian Jackson 
    
    
changeset:   26111:c26e1a79fe77
user:        Christoph Egger 
date:        Thu Oct 25 17:12:55 2012 +0100
    
    libxl: NetBSD PCI passthrough support
    
    Add PCI passthrough support for HVM guests.
    
    Signed-off-by: Christoph Egger 
    Committed-by: Ian Jackson 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 27 11:41:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 11:41:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TS4kq-0002nW-MR; Sat, 27 Oct 2012 11:40:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TS4kp-0002nR-0G
	for xen-devel@lists.xensource.com; Sat, 27 Oct 2012 11:40:39 +0000
Received: from [85.158.139.211:16611] by server-11.bemta-5.messagelabs.com id
	17/5E-14870-638CB805; Sat, 27 Oct 2012 11:40:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1351338036!23930121!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY0NTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22457 invoked from network); 27 Oct 2012 11:40:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Oct 2012 11:40:36 -0000
X-IronPort-AV: E=Sophos;i="4.80,660,1344211200"; d="scan'208";a="15431620"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Oct 2012 11:40:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sat, 27 Oct 2012 12:40:34 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TS4kk-0007XC-R0;
	Sat, 27 Oct 2012 11:40:34 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TS4kk-00012p-PO;
	Sat, 27 Oct 2012 12:40:34 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Sat, 27 Oct 2012 12:40:34 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14098: trouble: blocked/broken/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14098 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14098/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   2 host-install(2)         broken REGR. vs. 14079
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 14079
 build-i386-oldkern            2 host-install(2)         broken REGR. vs. 14079

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a

version targeted for testing:
 xen                  37a8946eeb9d
baseline version:
 xen                  c26e1a79fe77

------------------------------------------------------------
People who touched revisions under test:
  Charles Arnold 
  Christoph Egger 
  Ian Campbell 
  Ian Jackson 
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   pass    
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           broken  
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26115:37a8946eeb9d
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:09:29 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    
    
changeset:   26114:6f9e46917eb8
user:        Charles Arnold 
date:        Fri Oct 26 12:05:08 2012 +0100
    
    pygrub: Add option to list grub entries
    
    The argument to "--entry" allows 2 syntaxes, either directly the entry
    number in menu.lst, or the whole string behind the "title" key word.
    This poses the following issue:
    
    From Dom0 there is no way to guess the number and, or the complete
    title string because this string contains the kernel version, which
    will change with a kernel update.
    
    This patch adds [-l|--list-entries] as an argument to pygrub.
    
    Signed-off-by: Charles Arnold 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26113:03af0abd2b72
user:        Ian Campbell 
date:        Fri Oct 26 12:03:12 2012 +0100
    
    xl: Do not leak events when a domain exits.
    
    The goto in both of these places misses the event free which would
    normally clean up.
    
    ==8655== 80 bytes in 1 blocks are definitely lost in loss record 1 of 1
    ==8655==    at 0x4024370: calloc (vg_replace_malloc.c:593)
    ==8655==    by 0x406EAAE: libxl__zalloc (libxl_internal.c:83)
    ==8655==    by 0x4078173: libxl__event_new (libxl_event.c:1167)
    ==8655==    by 0x4056373: domain_death_occurred (libxl.c:958)
    ==8655==    by 0x4058D06: domain_death_xswatch_callback (libxl.c:1038)
    ==8655==    by 0x4078EB5: watchfd_callback (libxl_event.c:458)
    ==8655==    by 0x407839E: afterpoll_internal (libxl_event.c:949)
    ==8655==    by 0x4079142: eventloop_iteration (libxl_event.c:1371)
    ==8655==    by 0x40799BB: libxl_event_wait (libxl_event.c:1396)
    ==8655==    by 0x805CC67: create_domain (xl_cmdimpl.c:1698)
    ==8655==    by 0x805E001: main_create (xl_cmdimpl.c:3986)
    ==8655==    by 0x804D43D: main (xl.c:285)
    
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26112:d07692b5c780
user:        Ian Jackson 
date:        Fri Oct 26 11:39:42 2012 +0100
    
    Revert 26109:6ccfe4d29f95
    
    This changeset was contaminated by changes hanging around in my
    working tree.  Sorry :-(.
    
    Signed-off-by: Ian Jackson 
    
    
changeset:   26111:c26e1a79fe77
user:        Christoph Egger 
date:        Thu Oct 25 17:12:55 2012 +0100
    
    libxl: NetBSD PCI passthrough support
    
    Add PCI passthrough support for HVM guests.
    
    Signed-off-by: Christoph Egger 
    Committed-by: Ian Jackson 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 27 11:44:40 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 11:44:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TS4oL-00030m-G7; Sat, 27 Oct 2012 11:44:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TS4oJ-00030Z-GW
	for xen-devel@lists.xen.org; Sat, 27 Oct 2012 11:44:15 +0000
Received: from [85.158.139.83:44792] by server-6.bemta-5.messagelabs.com id
	8A/96-32589-E09CB805; Sat, 27 Oct 2012 11:44:14 +0000
X-Env-Sender: mva@mva.name
X-Msg-Ref: server-7.tower-182.messagelabs.com!1351338253!23621534!1
X-Originating-IP: [95.108.130.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogOTUuMTA4LjEzMC45NCA9PiA0Njg5MA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15736 invoked from network); 27 Oct 2012 11:44:14 -0000
Received: from forward12.mail.yandex.net (HELO forward12.mail.yandex.net)
	(95.108.130.94) by server-7.tower-182.messagelabs.com with SMTP;
	27 Oct 2012 11:44:14 -0000
Received: from smtp13.mail.yandex.net (smtp13.mail.yandex.net [95.108.130.68])
	by forward12.mail.yandex.net (Yandex) with ESMTP id 67F2CC20F61
	for ; Sat, 27 Oct 2012 15:44:06 +0400 (MSK)
Received: from smtp13.mail.yandex.net (localhost [127.0.0.1])
	by smtp13.mail.yandex.net (Yandex) with ESMTP id 52C61E40517
	for ; Sat, 27 Oct 2012 15:44:06 +0400 (MSK)
Received: from host-109-171-17-91.bbcustomer.zsttk.net
	(host-109-171-17-91.bbcustomer.zsttk.net [109.171.17.91])
	by smtp13.mail.yandex.net (nwsmtp/Yandex) with ESMTP id
	i5kGPYSo-i6keRKlu; Sat, 27 Oct 2012 15:44:06 +0400
Message-ID: <508BC903.8050104@mva.name>
Date: Sat, 27 Oct 2012 18:44:03 +0700
From: "Vadim A. Misbakh-Soloviov" 
Organization: Alpha LLC
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120923 Firefox/15.0.1 Thunderbird/15.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" 
References: <508BC02B.5040607@mva.name>
In-Reply-To: <508BC02B.5040607@mva.name>
X-Enigmail-Version: 1.4.4
Subject: Re: [Xen-devel] Problem with growing up dom0 memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============5685107222906255163=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============5685107222906255163==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enigA0F9FB8E2C3628951C10BB49"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigA0F9FB8E2C3628951C10BB49
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Sorry, I forgot to tell:
Xen/Xen-tools version: 4.2.0
Kernel: 3.5.3 on the first node, and 3.6.3 on second (where I get
cpupool issue)

Also,
xl infos:
1)
node1 ~mva % xl info
host                   : node1
release                : 3.5.3
version                : #3 SMP PREEMPT Fri Sep 7 16:12:20 MSK 2012
machine                : x86_64
nr_cpus                : 12
nr_nodes               : 1
cores_per_socket       : 6
threads_per_core       : 2
cpu_mhz                : 3475
hw_caps                :
bfebfbff:2c100800:00000000:00003f40:029ae3bf:00000000:00000001:00000000
virt_caps              : hvm hvm_directio
total_memory           : 24567
free_memory            : 0
free_cpus              : 0
xen_major              : 4
xen_minor              : 1
xen_extra              : .3
xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
hvm-3.0-x86_32p hvm-3.0-x86_64
xen_scheduler          : credit
xen_pagesize           : 4096
platform_params        : virt_start=3D0xffff800000000000
xen_changeset          : unavailable
xen_commandline        : dom0_max_vcpus=3D8 dom0_vcpus_pin dom0_max_mem=3D=
24G
cc_compiler            : gcc version 4.5.4 (Gentoo 4.5.4 p1.0, pie-0.4.7)=

cc_compile_by          :
cc_compile_domain      :
cc_compile_date        : Sun Sep  2 05:07:49 MSK 2012
xend_config_format     : 4


2)
node1 ~mva % xl info
host                   : node1
release                : 3.6.3
version                : #1 SMP Fri Oct 26 05:58:21 MSK 2012
machine                : x86_64
nr_cpus                : 12
max_cpu_id             : 15
nr_nodes               : 1
cores_per_socket       : 6
threads_per_core       : 2
cpu_mhz                : 3200
hw_caps                :
bfebfbff:2c100800:00000000:00002f40:17bee3bf:00000000:00000001:00000000
virt_caps              : hvm hvm_directio
total_memory           : 64948
free_memory            : 100
sharing_freed_memory   : 0
sharing_used_memory    : 0
free_cpus              : 0
xen_major              : 4
xen_minor              : 2
xen_extra              : .0
xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
hvm-3.0-x86_32p hvm-3.0-x86_64
xen_scheduler          : credit
xen_pagesize           : 4096
platform_params        : virt_start=3D0xffff800000000000
xen_changeset          : unavailable
xen_commandline        : dom0_max_vcpus=3D12 dom0_max_mem=3D64G
cc_compiler            : x86_64-pc-linux-gnu-gcc (Gentoo 4.5.4 p1.0,
pie-0.4.7) 4.5.4
cc_compile_by          :
cc_compile_domain      : (none)
cc_compile_date        : Wed Oct 24 20:45:01 MSK 2012
xend_config_format     : 4


(yes, both nodes has hostname "node1" :P)


--------------enigA0F9FB8E2C3628951C10BB49
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQi8kDAAoJECZQPTSbOzNLXQMQAIlxrbx3BOcKMi5SUQy24y4J
89WOlTC4YvcDnG29XTDBWYvWgq7pyo8RsysFmOUDa98ChPb/kqetjDHIsGTh82AY
RzeOKw4lIBf57ICSpNGckbn+evqje44kdU1HnQpdxBKsyPlpvhqiyW3sb/Aa4QvV
0eCWIsB1in+vtrT46mUObTy0qXJLAGZDVQqaR/KDo9YI7ib2b4hfssjoAdOn5hUI
SAnU808jFiR8M8K7w8pv9CHiKqzSTx0vt5znJVdvzqqBZLpbO9sfBc3E4s2HKtuk
VH8v41PnVELr3RW2f+TAsyss1RsEPdsZ66aqe9/X/Q+y3x9rjtpn4ip/SjseHqyJ
y3+LjXT7TtmUAr4iWsACn/Lt/ItECXEFBI1pnrlh02q+ROeIF98QRDn32c0wWYMi
dks0sYiWzo9Z2qmltvmS9rfX6N4P/5m+ir8OUJOh1Uo7J4LmUa3QQmGEsvybYE24
qB7dcUAKp3GJT9fV7koTKj1WafnssKRe1ki9bO7ccsGIitbi45agL7Ddl8aap+Ls
aYY3kZ+xxIiGYOkBrZezJVT/kHX7vBXTKjQOj5ha7NQwRmSK0WVaaLO58UGjsyts
VZnZpPB+bxlurMZe9Fdk33n8RV+hJOYhRYPr1pOzLeGKkHN151TWjx1X+4EZlIh0
lEoJfAvVYnjHI3GHKFey
=VMxk
-----END PGP SIGNATURE-----

--------------enigA0F9FB8E2C3628951C10BB49--


--===============5685107222906255163==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5685107222906255163==--


From xen-devel-bounces@lists.xen.org Sat Oct 27 11:44:40 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 11:44:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TS4oL-00030m-G7; Sat, 27 Oct 2012 11:44:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TS4oJ-00030Z-GW
	for xen-devel@lists.xen.org; Sat, 27 Oct 2012 11:44:15 +0000
Received: from [85.158.139.83:44792] by server-6.bemta-5.messagelabs.com id
	8A/96-32589-E09CB805; Sat, 27 Oct 2012 11:44:14 +0000
X-Env-Sender: mva@mva.name
X-Msg-Ref: server-7.tower-182.messagelabs.com!1351338253!23621534!1
X-Originating-IP: [95.108.130.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogOTUuMTA4LjEzMC45NCA9PiA0Njg5MA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15736 invoked from network); 27 Oct 2012 11:44:14 -0000
Received: from forward12.mail.yandex.net (HELO forward12.mail.yandex.net)
	(95.108.130.94) by server-7.tower-182.messagelabs.com with SMTP;
	27 Oct 2012 11:44:14 -0000
Received: from smtp13.mail.yandex.net (smtp13.mail.yandex.net [95.108.130.68])
	by forward12.mail.yandex.net (Yandex) with ESMTP id 67F2CC20F61
	for ; Sat, 27 Oct 2012 15:44:06 +0400 (MSK)
Received: from smtp13.mail.yandex.net (localhost [127.0.0.1])
	by smtp13.mail.yandex.net (Yandex) with ESMTP id 52C61E40517
	for ; Sat, 27 Oct 2012 15:44:06 +0400 (MSK)
Received: from host-109-171-17-91.bbcustomer.zsttk.net
	(host-109-171-17-91.bbcustomer.zsttk.net [109.171.17.91])
	by smtp13.mail.yandex.net (nwsmtp/Yandex) with ESMTP id
	i5kGPYSo-i6keRKlu; Sat, 27 Oct 2012 15:44:06 +0400
Message-ID: <508BC903.8050104@mva.name>
Date: Sat, 27 Oct 2012 18:44:03 +0700
From: "Vadim A. Misbakh-Soloviov" 
Organization: Alpha LLC
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120923 Firefox/15.0.1 Thunderbird/15.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" 
References: <508BC02B.5040607@mva.name>
In-Reply-To: <508BC02B.5040607@mva.name>
X-Enigmail-Version: 1.4.4
Subject: Re: [Xen-devel] Problem with growing up dom0 memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============5685107222906255163=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============5685107222906255163==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enigA0F9FB8E2C3628951C10BB49"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigA0F9FB8E2C3628951C10BB49
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Sorry, I forgot to tell:
Xen/Xen-tools version: 4.2.0
Kernel: 3.5.3 on the first node, and 3.6.3 on second (where I get
cpupool issue)

Also,
xl infos:
1)
node1 ~mva % xl info
host                   : node1
release                : 3.5.3
version                : #3 SMP PREEMPT Fri Sep 7 16:12:20 MSK 2012
machine                : x86_64
nr_cpus                : 12
nr_nodes               : 1
cores_per_socket       : 6
threads_per_core       : 2
cpu_mhz                : 3475
hw_caps                :
bfebfbff:2c100800:00000000:00003f40:029ae3bf:00000000:00000001:00000000
virt_caps              : hvm hvm_directio
total_memory           : 24567
free_memory            : 0
free_cpus              : 0
xen_major              : 4
xen_minor              : 1
xen_extra              : .3
xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
hvm-3.0-x86_32p hvm-3.0-x86_64
xen_scheduler          : credit
xen_pagesize           : 4096
platform_params        : virt_start=3D0xffff800000000000
xen_changeset          : unavailable
xen_commandline        : dom0_max_vcpus=3D8 dom0_vcpus_pin dom0_max_mem=3D=
24G
cc_compiler            : gcc version 4.5.4 (Gentoo 4.5.4 p1.0, pie-0.4.7)=

cc_compile_by          :
cc_compile_domain      :
cc_compile_date        : Sun Sep  2 05:07:49 MSK 2012
xend_config_format     : 4


2)
node1 ~mva % xl info
host                   : node1
release                : 3.6.3
version                : #1 SMP Fri Oct 26 05:58:21 MSK 2012
machine                : x86_64
nr_cpus                : 12
max_cpu_id             : 15
nr_nodes               : 1
cores_per_socket       : 6
threads_per_core       : 2
cpu_mhz                : 3200
hw_caps                :
bfebfbff:2c100800:00000000:00002f40:17bee3bf:00000000:00000001:00000000
virt_caps              : hvm hvm_directio
total_memory           : 64948
free_memory            : 100
sharing_freed_memory   : 0
sharing_used_memory    : 0
free_cpus              : 0
xen_major              : 4
xen_minor              : 2
xen_extra              : .0
xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
hvm-3.0-x86_32p hvm-3.0-x86_64
xen_scheduler          : credit
xen_pagesize           : 4096
platform_params        : virt_start=3D0xffff800000000000
xen_changeset          : unavailable
xen_commandline        : dom0_max_vcpus=3D12 dom0_max_mem=3D64G
cc_compiler            : x86_64-pc-linux-gnu-gcc (Gentoo 4.5.4 p1.0,
pie-0.4.7) 4.5.4
cc_compile_by          :
cc_compile_domain      : (none)
cc_compile_date        : Wed Oct 24 20:45:01 MSK 2012
xend_config_format     : 4


(yes, both nodes has hostname "node1" :P)


--------------enigA0F9FB8E2C3628951C10BB49
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQi8kDAAoJECZQPTSbOzNLXQMQAIlxrbx3BOcKMi5SUQy24y4J
89WOlTC4YvcDnG29XTDBWYvWgq7pyo8RsysFmOUDa98ChPb/kqetjDHIsGTh82AY
RzeOKw4lIBf57ICSpNGckbn+evqje44kdU1HnQpdxBKsyPlpvhqiyW3sb/Aa4QvV
0eCWIsB1in+vtrT46mUObTy0qXJLAGZDVQqaR/KDo9YI7ib2b4hfssjoAdOn5hUI
SAnU808jFiR8M8K7w8pv9CHiKqzSTx0vt5znJVdvzqqBZLpbO9sfBc3E4s2HKtuk
VH8v41PnVELr3RW2f+TAsyss1RsEPdsZ66aqe9/X/Q+y3x9rjtpn4ip/SjseHqyJ
y3+LjXT7TtmUAr4iWsACn/Lt/ItECXEFBI1pnrlh02q+ROeIF98QRDn32c0wWYMi
dks0sYiWzo9Z2qmltvmS9rfX6N4P/5m+ir8OUJOh1Uo7J4LmUa3QQmGEsvybYE24
qB7dcUAKp3GJT9fV7koTKj1WafnssKRe1ki9bO7ccsGIitbi45agL7Ddl8aap+Ls
aYY3kZ+xxIiGYOkBrZezJVT/kHX7vBXTKjQOj5ha7NQwRmSK0WVaaLO58UGjsyts
VZnZpPB+bxlurMZe9Fdk33n8RV+hJOYhRYPr1pOzLeGKkHN151TWjx1X+4EZlIh0
lEoJfAvVYnjHI3GHKFey
=VMxk
-----END PGP SIGNATURE-----

--------------enigA0F9FB8E2C3628951C10BB49--


--===============5685107222906255163==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5685107222906255163==--


From xen-devel-bounces@lists.xen.org Sat Oct 27 11:54:49 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 11:54:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TS4yC-0003I8-KC; Sat, 27 Oct 2012 11:54:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TS4yA-0003I3-ID
	for xen-devel@lists.xensource.com; Sat, 27 Oct 2012 11:54:26 +0000
Received: from [85.158.139.83:40407] by server-5.bemta-5.messagelabs.com id
	DB/54-09732-17BCB805; Sat, 27 Oct 2012 11:54:25 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-182.messagelabs.com!1351338865!27560806!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1352 invoked from network); 27 Oct 2012 11:54:25 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Oct 2012 11:54:25 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TS4y7-000NeC-Di; Sat, 27 Oct 2012 11:54:23 +0000
Date: Sat, 27 Oct 2012 12:54:23 +0100
From: Tim Deegan 
To: Stefano Stabellini 
Message-ID: <20121027115423.GA90857@ocelot.phlegethon.org>
References: <1351091027-20740-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20121024155945.GD39126@ocelot.phlegethon.org>
	
	<20121026090141.GB76080@ocelot.phlegethon.org>
	
	
	
	<20121026165549.GF76080@ocelot.phlegethon.org>
	
	<20121027104428.GB89901@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20121027104428.GB89901@ocelot.phlegethon.org>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" ,
	Ian Campbell 
Subject: Re: [Xen-devel] [PATCH 6/7] xen/arm: flush D-cache and I-cache when
	appropriate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 11:44 +0100 on 27 Oct (1351338268), Tim Deegan wrote:
>  /* Function for flushing medium-sized areas.
>   * if 'range' is large enough we might want to use model-specific
>   * full-cache flushes. */
>  static inline void flush_xen_dcache_va_range(void *p, unsigned long size)
>  {
>      void *end;
>      unsigned long cacheline_bytes = READ_CP32(CCSIDR);
>      barrier();       /* So the compiler issues all writes to the range */
>      dsb();           /* So the CPU issues all writes to the range */ 

Oh - I just noticed that the way we've defined dsb() it includes a
memory clobber.   So I guess we don't need barrier() as well there.

We might want to look at the other users of dsb() and see if we want to
drop the memory clobber from it as well.  But OTOH we may be getting
way into premature optimization already. :)

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 27 11:54:49 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 11:54:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TS4yC-0003I8-KC; Sat, 27 Oct 2012 11:54:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TS4yA-0003I3-ID
	for xen-devel@lists.xensource.com; Sat, 27 Oct 2012 11:54:26 +0000
Received: from [85.158.139.83:40407] by server-5.bemta-5.messagelabs.com id
	DB/54-09732-17BCB805; Sat, 27 Oct 2012 11:54:25 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-182.messagelabs.com!1351338865!27560806!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1352 invoked from network); 27 Oct 2012 11:54:25 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Oct 2012 11:54:25 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TS4y7-000NeC-Di; Sat, 27 Oct 2012 11:54:23 +0000
Date: Sat, 27 Oct 2012 12:54:23 +0100
From: Tim Deegan 
To: Stefano Stabellini 
Message-ID: <20121027115423.GA90857@ocelot.phlegethon.org>
References: <1351091027-20740-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20121024155945.GD39126@ocelot.phlegethon.org>
	
	<20121026090141.GB76080@ocelot.phlegethon.org>
	
	
	
	<20121026165549.GF76080@ocelot.phlegethon.org>
	
	<20121027104428.GB89901@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20121027104428.GB89901@ocelot.phlegethon.org>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" ,
	Ian Campbell 
Subject: Re: [Xen-devel] [PATCH 6/7] xen/arm: flush D-cache and I-cache when
	appropriate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 11:44 +0100 on 27 Oct (1351338268), Tim Deegan wrote:
>  /* Function for flushing medium-sized areas.
>   * if 'range' is large enough we might want to use model-specific
>   * full-cache flushes. */
>  static inline void flush_xen_dcache_va_range(void *p, unsigned long size)
>  {
>      void *end;
>      unsigned long cacheline_bytes = READ_CP32(CCSIDR);
>      barrier();       /* So the compiler issues all writes to the range */
>      dsb();           /* So the CPU issues all writes to the range */ 

Oh - I just noticed that the way we've defined dsb() it includes a
memory clobber.   So I guess we don't need barrier() as well there.

We might want to look at the other users of dsb() and see if we want to
drop the memory clobber from it as well.  But OTOH we may be getting
way into premature optimization already. :)

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 27 12:00:15 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 12:00:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TS53P-0003QJ-C8; Sat, 27 Oct 2012 11:59:51 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TS53O-0003QC-0j
	for xen-devel@lists.xen.org; Sat, 27 Oct 2012 11:59:50 +0000
Received: from [193.109.254.147:43217] by server-15.bemta-14.messagelabs.com
	id 2C/8D-12105-5BCCB805; Sat, 27 Oct 2012 11:59:49 +0000
X-Env-Sender: mva@mva.name
X-Msg-Ref: server-4.tower-27.messagelabs.com!1351339188!8653462!1
X-Originating-IP: [95.108.253.142]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogOTUuMTA4LjI1My4xNDIgPT4gMzIwMDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30405 invoked from network); 27 Oct 2012 11:59:48 -0000
Received: from forward17.mail.yandex.net (HELO forward17.mail.yandex.net)
	(95.108.253.142) by server-4.tower-27.messagelabs.com with SMTP;
	27 Oct 2012 11:59:48 -0000
Received: from smtp17.mail.yandex.net (smtp17.mail.yandex.net [95.108.252.17])
	by forward17.mail.yandex.net (Yandex) with ESMTP id 5BBF410625DE
	for ; Sat, 27 Oct 2012 15:59:48 +0400 (MSK)
Received: from smtp17.mail.yandex.net (localhost [127.0.0.1])
	by smtp17.mail.yandex.net (Yandex) with ESMTP id 435611900214
	for ; Sat, 27 Oct 2012 15:59:48 +0400 (MSK)
Received: from host-109-171-17-91.bbcustomer.zsttk.net
	(host-109-171-17-91.bbcustomer.zsttk.net [109.171.17.91])
	by smtp17.mail.yandex.net (nwsmtp/Yandex) with ESMTP id
	xl7GjFcD-xl7q4jvK; Sat, 27 Oct 2012 15:59:47 +0400
Message-ID: <508BCCB6.7040708@mva.name>
Date: Sat, 27 Oct 2012 18:59:50 +0700
From: "Vadim A. Misbakh-Soloviov" 
Organization: Alpha LLC
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120923 Firefox/15.0.1 Thunderbird/15.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" 
References: <508BC02B.5040607@mva.name> <508BC903.8050104@mva.name>
In-Reply-To: <508BC903.8050104@mva.name>
X-Enigmail-Version: 1.4.4
Subject: Re: [Xen-devel] Problem with growing up dom0 memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============5168688055009758405=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============5168688055009758405==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enigCA2A0D74D24D2C0149F6DC29"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigCA2A0D74D24D2C0149F6DC29
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Uhm. It seems, it is 4.1.3 (as you can see from xl info) on 3.5.3-kernel
node, but I have all following issues even on 3.6.3-kernel node with 4.2.=
0.

P.S.:
By the way, I also has some network speed issues with domUs:

one_node ~mva % scp bkp.txz domU_on_another_node:/home/mva
bkp.txz

                                      3%  592KB 259.7KB/s   0.0KB/s
01:12 ETA^CKilled by signal 2.
one_node ~mva % scp bkp.txz another_node_itself:/home/mva
bkp.txz

                                    100%   19MB   3.8MB/s   6.2MB/s
00:05

almost the same for reversed process (downloading from that places)
it is rt8169 ethernet driver on "one_node", e1000e on "another_node" and
I dunno which driver Xen uses for domUs, but:
domU ~mva % dmesg|grep -i 'Xen.*eth'
Initialising Xen virtual ethernet driver


--------------enigCA2A0D74D24D2C0149F6DC29
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQi8y2AAoJECZQPTSbOzNLVlEP/RV0G0tY/zJq5Go9wf06FzVq
4pqMWbGg3u8yKWRvqpLLNiLCk9naM12WWGONjyf1JLvgH64LhOmV/eaYi/PLlqKf
lCrly2uIMsCZfZ9udMd5ROZNcCdQq6KYqfF+bKr71LTlsdwdVt+KqWVsvAgnrLDQ
wPsc7kcHyiB/RTOB8bfiuiPXJl7eNTj9L0vur/pAD2o4khEbBnk9KZUHQ/3Bm73B
vRrUyVm993Q48Kg0aDhrND+p30XCkeiCPu8BP0Vd6/yph7ViuCaxRJNEAWq7wz5/
I9AJ21I7RAoRl6p5nHn5Lo6SckW3rLn+z8DvV6NBfWDUmDRBm0fJ33e0h9op6VEa
ucqjs6ZetprOtqIkWaM6dVM+44JTVP9qa7Nx95xsYqudDJ6yn+V/b3udlk73EVrg
7kuS0lzLjqN74e90wZw+KZCko21OAExSQ7wdzce1qRYPdQ4z8CkCab09qevbsKvD
DlWJZ3ImOQln9Yk5MVGXvUqmlcNwN9rFbfEivh6OPx9yv6qw9wkv6M+5f4aSCY+y
7JCER7CtAp9HX90WkXEbEX8P1uSaFBIfu9PvQuixqMF/nI9BN+wbmmJYMdM3rgcl
xFZi5KDOHCpZP137bcdi/JVSnTRzyn1RJgvCHQhNfMrgKLx2iScspheQqlFWvaIS
GHqinSmqF8cCM/EfpbDB
=+E4J
-----END PGP SIGNATURE-----

--------------enigCA2A0D74D24D2C0149F6DC29--


--===============5168688055009758405==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5168688055009758405==--


From xen-devel-bounces@lists.xen.org Sat Oct 27 12:00:15 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 12:00:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TS53P-0003QJ-C8; Sat, 27 Oct 2012 11:59:51 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TS53O-0003QC-0j
	for xen-devel@lists.xen.org; Sat, 27 Oct 2012 11:59:50 +0000
Received: from [193.109.254.147:43217] by server-15.bemta-14.messagelabs.com
	id 2C/8D-12105-5BCCB805; Sat, 27 Oct 2012 11:59:49 +0000
X-Env-Sender: mva@mva.name
X-Msg-Ref: server-4.tower-27.messagelabs.com!1351339188!8653462!1
X-Originating-IP: [95.108.253.142]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogOTUuMTA4LjI1My4xNDIgPT4gMzIwMDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30405 invoked from network); 27 Oct 2012 11:59:48 -0000
Received: from forward17.mail.yandex.net (HELO forward17.mail.yandex.net)
	(95.108.253.142) by server-4.tower-27.messagelabs.com with SMTP;
	27 Oct 2012 11:59:48 -0000
Received: from smtp17.mail.yandex.net (smtp17.mail.yandex.net [95.108.252.17])
	by forward17.mail.yandex.net (Yandex) with ESMTP id 5BBF410625DE
	for ; Sat, 27 Oct 2012 15:59:48 +0400 (MSK)
Received: from smtp17.mail.yandex.net (localhost [127.0.0.1])
	by smtp17.mail.yandex.net (Yandex) with ESMTP id 435611900214
	for ; Sat, 27 Oct 2012 15:59:48 +0400 (MSK)
Received: from host-109-171-17-91.bbcustomer.zsttk.net
	(host-109-171-17-91.bbcustomer.zsttk.net [109.171.17.91])
	by smtp17.mail.yandex.net (nwsmtp/Yandex) with ESMTP id
	xl7GjFcD-xl7q4jvK; Sat, 27 Oct 2012 15:59:47 +0400
Message-ID: <508BCCB6.7040708@mva.name>
Date: Sat, 27 Oct 2012 18:59:50 +0700
From: "Vadim A. Misbakh-Soloviov" 
Organization: Alpha LLC
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120923 Firefox/15.0.1 Thunderbird/15.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" 
References: <508BC02B.5040607@mva.name> <508BC903.8050104@mva.name>
In-Reply-To: <508BC903.8050104@mva.name>
X-Enigmail-Version: 1.4.4
Subject: Re: [Xen-devel] Problem with growing up dom0 memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============5168688055009758405=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============5168688055009758405==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enigCA2A0D74D24D2C0149F6DC29"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigCA2A0D74D24D2C0149F6DC29
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Uhm. It seems, it is 4.1.3 (as you can see from xl info) on 3.5.3-kernel
node, but I have all following issues even on 3.6.3-kernel node with 4.2.=
0.

P.S.:
By the way, I also has some network speed issues with domUs:

one_node ~mva % scp bkp.txz domU_on_another_node:/home/mva
bkp.txz

                                      3%  592KB 259.7KB/s   0.0KB/s
01:12 ETA^CKilled by signal 2.
one_node ~mva % scp bkp.txz another_node_itself:/home/mva
bkp.txz

                                    100%   19MB   3.8MB/s   6.2MB/s
00:05

almost the same for reversed process (downloading from that places)
it is rt8169 ethernet driver on "one_node", e1000e on "another_node" and
I dunno which driver Xen uses for domUs, but:
domU ~mva % dmesg|grep -i 'Xen.*eth'
Initialising Xen virtual ethernet driver


--------------enigCA2A0D74D24D2C0149F6DC29
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQi8y2AAoJECZQPTSbOzNLVlEP/RV0G0tY/zJq5Go9wf06FzVq
4pqMWbGg3u8yKWRvqpLLNiLCk9naM12WWGONjyf1JLvgH64LhOmV/eaYi/PLlqKf
lCrly2uIMsCZfZ9udMd5ROZNcCdQq6KYqfF+bKr71LTlsdwdVt+KqWVsvAgnrLDQ
wPsc7kcHyiB/RTOB8bfiuiPXJl7eNTj9L0vur/pAD2o4khEbBnk9KZUHQ/3Bm73B
vRrUyVm993Q48Kg0aDhrND+p30XCkeiCPu8BP0Vd6/yph7ViuCaxRJNEAWq7wz5/
I9AJ21I7RAoRl6p5nHn5Lo6SckW3rLn+z8DvV6NBfWDUmDRBm0fJ33e0h9op6VEa
ucqjs6ZetprOtqIkWaM6dVM+44JTVP9qa7Nx95xsYqudDJ6yn+V/b3udlk73EVrg
7kuS0lzLjqN74e90wZw+KZCko21OAExSQ7wdzce1qRYPdQ4z8CkCab09qevbsKvD
DlWJZ3ImOQln9Yk5MVGXvUqmlcNwN9rFbfEivh6OPx9yv6qw9wkv6M+5f4aSCY+y
7JCER7CtAp9HX90WkXEbEX8P1uSaFBIfu9PvQuixqMF/nI9BN+wbmmJYMdM3rgcl
xFZi5KDOHCpZP137bcdi/JVSnTRzyn1RJgvCHQhNfMrgKLx2iScspheQqlFWvaIS
GHqinSmqF8cCM/EfpbDB
=+E4J
-----END PGP SIGNATURE-----

--------------enigCA2A0D74D24D2C0149F6DC29--


--===============5168688055009758405==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5168688055009758405==--


From xen-devel-bounces@lists.xen.org Sat Oct 27 14:12:39 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 14:12:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TS77L-0005OE-5A; Sat, 27 Oct 2012 14:12:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TS77J-0005O9-OS
	for xen-devel@lists.xensource.com; Sat, 27 Oct 2012 14:12:02 +0000
Received: from [85.158.143.99:41834] by server-3.bemta-4.messagelabs.com id
	25/F5-24279-0BBEB805; Sat, 27 Oct 2012 14:12:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1351347120!22290700!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY0NTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4630 invoked from network); 27 Oct 2012 14:12:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Oct 2012 14:12:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,662,1344211200"; d="scan'208";a="15439164"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Oct 2012 14:11:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sat, 27 Oct 2012 15:11:58 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TS77G-0008Ju-RV;
	Sat, 27 Oct 2012 14:11:58 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TS77G-000399-Qu;
	Sat, 27 Oct 2012 15:11:58 +0100
To: 
Message-ID: 
From: xen.org 
Date: Sat, 27 Oct 2012 15:11:58 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14100: trouble: blocked/broken
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14100 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14100/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   2 host-install(2)         broken REGR. vs. 14079
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 14079
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 14079
 build-i386-pvops              2 host-install(2)         broken REGR. vs. 14079
 build-i386-oldkern            2 host-install(2)         broken REGR. vs. 14079
 build-i386                    2 host-install(2)         broken REGR. vs. 14079

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a

version targeted for testing:
 xen                  37a8946eeb9d
baseline version:
 xen                  c26e1a79fe77

------------------------------------------------------------
People who touched revisions under test:
  Charles Arnold 
  Christoph Egger 
  Ian Campbell 
  Ian Jackson 
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           broken  
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             broken  
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26115:37a8946eeb9d
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:09:29 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    
    
changeset:   26114:6f9e46917eb8
user:        Charles Arnold 
date:        Fri Oct 26 12:05:08 2012 +0100
    
    pygrub: Add option to list grub entries
    
    The argument to "--entry" allows 2 syntaxes, either directly the entry
    number in menu.lst, or the whole string behind the "title" key word.
    This poses the following issue:
    
    From Dom0 there is no way to guess the number and, or the complete
    title string because this string contains the kernel version, which
    will change with a kernel update.
    
    This patch adds [-l|--list-entries] as an argument to pygrub.
    
    Signed-off-by: Charles Arnold 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26113:03af0abd2b72
user:        Ian Campbell 
date:        Fri Oct 26 12:03:12 2012 +0100
    
    xl: Do not leak events when a domain exits.
    
    The goto in both of these places misses the event free which would
    normally clean up.
    
    ==8655== 80 bytes in 1 blocks are definitely lost in loss record 1 of 1
    ==8655==    at 0x4024370: calloc (vg_replace_malloc.c:593)
    ==8655==    by 0x406EAAE: libxl__zalloc (libxl_internal.c:83)
    ==8655==    by 0x4078173: libxl__event_new (libxl_event.c:1167)
    ==8655==    by 0x4056373: domain_death_occurred (libxl.c:958)
    ==8655==    by 0x4058D06: domain_death_xswatch_callback (libxl.c:1038)
    ==8655==    by 0x4078EB5: watchfd_callback (libxl_event.c:458)
    ==8655==    by 0x407839E: afterpoll_internal (libxl_event.c:949)
    ==8655==    by 0x4079142: eventloop_iteration (libxl_event.c:1371)
    ==8655==    by 0x40799BB: libxl_event_wait (libxl_event.c:1396)
    ==8655==    by 0x805CC67: create_domain (xl_cmdimpl.c:1698)
    ==8655==    by 0x805E001: main_create (xl_cmdimpl.c:3986)
    ==8655==    by 0x804D43D: main (xl.c:285)
    
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26112:d07692b5c780
user:        Ian Jackson 
date:        Fri Oct 26 11:39:42 2012 +0100
    
    Revert 26109:6ccfe4d29f95
    
    This changeset was contaminated by changes hanging around in my
    working tree.  Sorry :-(.
    
    Signed-off-by: Ian Jackson 
    
    
changeset:   26111:c26e1a79fe77
user:        Christoph Egger 
date:        Thu Oct 25 17:12:55 2012 +0100
    
    libxl: NetBSD PCI passthrough support
    
    Add PCI passthrough support for HVM guests.
    
    Signed-off-by: Christoph Egger 
    Committed-by: Ian Jackson 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 27 14:12:39 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 14:12:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TS77L-0005OE-5A; Sat, 27 Oct 2012 14:12:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TS77J-0005O9-OS
	for xen-devel@lists.xensource.com; Sat, 27 Oct 2012 14:12:02 +0000
Received: from [85.158.143.99:41834] by server-3.bemta-4.messagelabs.com id
	25/F5-24279-0BBEB805; Sat, 27 Oct 2012 14:12:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1351347120!22290700!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY0NTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4630 invoked from network); 27 Oct 2012 14:12:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Oct 2012 14:12:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,662,1344211200"; d="scan'208";a="15439164"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Oct 2012 14:11:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sat, 27 Oct 2012 15:11:58 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TS77G-0008Ju-RV;
	Sat, 27 Oct 2012 14:11:58 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TS77G-000399-Qu;
	Sat, 27 Oct 2012 15:11:58 +0100
To: 
Message-ID: 
From: xen.org 
Date: Sat, 27 Oct 2012 15:11:58 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14100: trouble: blocked/broken
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14100 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14100/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   2 host-install(2)         broken REGR. vs. 14079
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 14079
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 14079
 build-i386-pvops              2 host-install(2)         broken REGR. vs. 14079
 build-i386-oldkern            2 host-install(2)         broken REGR. vs. 14079
 build-i386                    2 host-install(2)         broken REGR. vs. 14079

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a

version targeted for testing:
 xen                  37a8946eeb9d
baseline version:
 xen                  c26e1a79fe77

------------------------------------------------------------
People who touched revisions under test:
  Charles Arnold 
  Christoph Egger 
  Ian Campbell 
  Ian Jackson 
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           broken  
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             broken  
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26115:37a8946eeb9d
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:09:29 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    
    
changeset:   26114:6f9e46917eb8
user:        Charles Arnold 
date:        Fri Oct 26 12:05:08 2012 +0100
    
    pygrub: Add option to list grub entries
    
    The argument to "--entry" allows 2 syntaxes, either directly the entry
    number in menu.lst, or the whole string behind the "title" key word.
    This poses the following issue:
    
    From Dom0 there is no way to guess the number and, or the complete
    title string because this string contains the kernel version, which
    will change with a kernel update.
    
    This patch adds [-l|--list-entries] as an argument to pygrub.
    
    Signed-off-by: Charles Arnold 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26113:03af0abd2b72
user:        Ian Campbell 
date:        Fri Oct 26 12:03:12 2012 +0100
    
    xl: Do not leak events when a domain exits.
    
    The goto in both of these places misses the event free which would
    normally clean up.
    
    ==8655== 80 bytes in 1 blocks are definitely lost in loss record 1 of 1
    ==8655==    at 0x4024370: calloc (vg_replace_malloc.c:593)
    ==8655==    by 0x406EAAE: libxl__zalloc (libxl_internal.c:83)
    ==8655==    by 0x4078173: libxl__event_new (libxl_event.c:1167)
    ==8655==    by 0x4056373: domain_death_occurred (libxl.c:958)
    ==8655==    by 0x4058D06: domain_death_xswatch_callback (libxl.c:1038)
    ==8655==    by 0x4078EB5: watchfd_callback (libxl_event.c:458)
    ==8655==    by 0x407839E: afterpoll_internal (libxl_event.c:949)
    ==8655==    by 0x4079142: eventloop_iteration (libxl_event.c:1371)
    ==8655==    by 0x40799BB: libxl_event_wait (libxl_event.c:1396)
    ==8655==    by 0x805CC67: create_domain (xl_cmdimpl.c:1698)
    ==8655==    by 0x805E001: main_create (xl_cmdimpl.c:3986)
    ==8655==    by 0x804D43D: main (xl.c:285)
    
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26112:d07692b5c780
user:        Ian Jackson 
date:        Fri Oct 26 11:39:42 2012 +0100
    
    Revert 26109:6ccfe4d29f95
    
    This changeset was contaminated by changes hanging around in my
    working tree.  Sorry :-(.
    
    Signed-off-by: Ian Jackson 
    
    
changeset:   26111:c26e1a79fe77
user:        Christoph Egger 
date:        Thu Oct 25 17:12:55 2012 +0100
    
    libxl: NetBSD PCI passthrough support
    
    Add PCI passthrough support for HVM guests.
    
    Signed-off-by: Christoph Egger 
    Committed-by: Ian Jackson 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 27 15:00:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 15:00:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TS7rt-00060N-ST; Sat, 27 Oct 2012 15:00:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TS7rs-00060F-96; Sat, 27 Oct 2012 15:00:08 +0000
Received: from [85.158.138.51:15263] by server-3.bemta-3.messagelabs.com id
	58/9D-09368-7F6FB805; Sat, 27 Oct 2012 15:00:07 +0000
X-Env-Sender: singapore.mr.teo.en.ming@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1351350004!27628455!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5037 invoked from network); 27 Oct 2012 15:00:06 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Oct 2012 15:00:06 -0000
Received: by mail-pb0-f45.google.com with SMTP id rp2so3491191pbb.32
	for ; Sat, 27 Oct 2012 08:00:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:disposition-notification-to:date:from:user-agent
	:mime-version:to:subject:content-type:content-transfer-encoding;
	bh=mgNZgXBkTtlRpxTgPStoMLIU4IZ6tnWbcogGj0qOyYg=;
	b=dpCopABmsy4bGC0kLXyUKtvspCNt/xEB4J32GaogsRIlcpqEgC1ezAdffMo68fxS2d
	V8gXuM5wyOq8ecg425WmiC3buH/Eh3zIvj+EZCwgjbi6DEgy8idhI1VZWFHjqiyur8fR
	og6aKyYS5x62EjCK5+i5UfdNJpha/SbEI2bVEyVLXeRIZvkxW8xrVA2JfZnPUWNhZvha
	E0eyGg9EYvMSjX/YtlMMM5zmuyEbM0PFle8OXA3FGFLLawyfvdBPqao27qOQKymEkQU0
	4lvFqaiJQ2we42ye0CYf/PJMXFp/KEWnGbER/jJS660xW+wvQDYC5Ap0r7eMGr+sI5YE
	3oHA==
Received: by 10.66.77.105 with SMTP id r9mr70102411paw.76.1351350003845;
	Sat, 27 Oct 2012 08:00:03 -0700 (PDT)
Received: from [192.168.1.17] (cm152.gamma205.maxonline.com.sg.
	[202.156.205.152])
	by mx.google.com with ESMTPS id ho7sm2925274pbc.3.2012.10.27.08.00.00
	(version=SSLv3 cipher=OTHER); Sat, 27 Oct 2012 08:00:02 -0700 (PDT)
Message-ID: <508BF6EF.2050908@gmail.com>
Date: Sat, 27 Oct 2012 22:59:59 +0800
From: "Teo En Ming (Zhang Enming)" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: "xen-users@lists.xen.org" , 
	"xen-devel@lists.xen.org" ,
	"Teo En Ming (Zhang Enming)" , 
	Dariusz Krempa ,
	Casey DeLorme , 
	Tobias Geiger 
Subject: [Xen-devel] Is Xen VGA Passthrough to CentOS 6.3 x86-64 HVM domU
	successful?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

I have just passed through my NVIDIA Geforce GTX 560 to CentOS 6.3 
x86-64 HVM domU. I am wondering whether the Xen VGA Passthrough is 
successful.

The following information is obtained from inside CentOS 6.3 x86-64 HVM 
domU:

00:05.0 VGA compatible controller: NVIDIA Corporation GF114 [GeForce GTX 
560] (rev a1) (prog-if 00 [VGA controller])
     Subsystem: Giga-byte Technology Device 3527
     Physical Slot: 5
     Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
     Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- 
SERR- 
     Kernel driver in use: nouveau
     Kernel modules: nvidia, nouveau, nvidiafb



[root@centos63 ~]# lsmod | grep nouveau
nouveau               791165  2
ttm                    82562  1 nouveau
drm_kms_helper         34122  1 nouveau
drm                   250067  4 nouveau,ttm,drm_kms_helper
i2c_core               31276  14 
tuner_simple,tda9887,tda8290,wm8775,tuner,cx25840,pvrusb2,v4l2_common,videodev,tveeprom,i2c_piix4,nouveau,drm_kms_helper,drm
mxm_wmi                 1925  1 nouveau
video                  21032  1 nouveau
wmi                     6287  2 nouveau,mxm_wmi




Notice that the nouveau VGA driver is loaded and is in use. Is Xen VGA 
Passthrough 100% successful? I have successfully installed the NVIDIA 
driver but I couldn't get it to load, so I reverted back to the nouveau 
driver.

I have such tough time getting Xen VGA Passthrough to work successfully 
on Windows HVM domU that I am giving up on Xen VGA Passthrough to 
Windows HVM domU!!! Windows 7 and Windows 8 HVM domU device manager 
always report error code 43 with a yellow triangle. Windows XP HVM domU 
device manager always report error code 10 with a yellow circle.

-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 27 15:00:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 15:00:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TS7rt-00060N-ST; Sat, 27 Oct 2012 15:00:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TS7rs-00060F-96; Sat, 27 Oct 2012 15:00:08 +0000
Received: from [85.158.138.51:15263] by server-3.bemta-3.messagelabs.com id
	58/9D-09368-7F6FB805; Sat, 27 Oct 2012 15:00:07 +0000
X-Env-Sender: singapore.mr.teo.en.ming@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1351350004!27628455!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5037 invoked from network); 27 Oct 2012 15:00:06 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Oct 2012 15:00:06 -0000
Received: by mail-pb0-f45.google.com with SMTP id rp2so3491191pbb.32
	for ; Sat, 27 Oct 2012 08:00:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:disposition-notification-to:date:from:user-agent
	:mime-version:to:subject:content-type:content-transfer-encoding;
	bh=mgNZgXBkTtlRpxTgPStoMLIU4IZ6tnWbcogGj0qOyYg=;
	b=dpCopABmsy4bGC0kLXyUKtvspCNt/xEB4J32GaogsRIlcpqEgC1ezAdffMo68fxS2d
	V8gXuM5wyOq8ecg425WmiC3buH/Eh3zIvj+EZCwgjbi6DEgy8idhI1VZWFHjqiyur8fR
	og6aKyYS5x62EjCK5+i5UfdNJpha/SbEI2bVEyVLXeRIZvkxW8xrVA2JfZnPUWNhZvha
	E0eyGg9EYvMSjX/YtlMMM5zmuyEbM0PFle8OXA3FGFLLawyfvdBPqao27qOQKymEkQU0
	4lvFqaiJQ2we42ye0CYf/PJMXFp/KEWnGbER/jJS660xW+wvQDYC5Ap0r7eMGr+sI5YE
	3oHA==
Received: by 10.66.77.105 with SMTP id r9mr70102411paw.76.1351350003845;
	Sat, 27 Oct 2012 08:00:03 -0700 (PDT)
Received: from [192.168.1.17] (cm152.gamma205.maxonline.com.sg.
	[202.156.205.152])
	by mx.google.com with ESMTPS id ho7sm2925274pbc.3.2012.10.27.08.00.00
	(version=SSLv3 cipher=OTHER); Sat, 27 Oct 2012 08:00:02 -0700 (PDT)
Message-ID: <508BF6EF.2050908@gmail.com>
Date: Sat, 27 Oct 2012 22:59:59 +0800
From: "Teo En Ming (Zhang Enming)" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: "xen-users@lists.xen.org" , 
	"xen-devel@lists.xen.org" ,
	"Teo En Ming (Zhang Enming)" , 
	Dariusz Krempa ,
	Casey DeLorme , 
	Tobias Geiger 
Subject: [Xen-devel] Is Xen VGA Passthrough to CentOS 6.3 x86-64 HVM domU
	successful?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

I have just passed through my NVIDIA Geforce GTX 560 to CentOS 6.3 
x86-64 HVM domU. I am wondering whether the Xen VGA Passthrough is 
successful.

The following information is obtained from inside CentOS 6.3 x86-64 HVM 
domU:

00:05.0 VGA compatible controller: NVIDIA Corporation GF114 [GeForce GTX 
560] (rev a1) (prog-if 00 [VGA controller])
     Subsystem: Giga-byte Technology Device 3527
     Physical Slot: 5
     Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
     Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- 
SERR- 
     Kernel driver in use: nouveau
     Kernel modules: nvidia, nouveau, nvidiafb



[root@centos63 ~]# lsmod | grep nouveau
nouveau               791165  2
ttm                    82562  1 nouveau
drm_kms_helper         34122  1 nouveau
drm                   250067  4 nouveau,ttm,drm_kms_helper
i2c_core               31276  14 
tuner_simple,tda9887,tda8290,wm8775,tuner,cx25840,pvrusb2,v4l2_common,videodev,tveeprom,i2c_piix4,nouveau,drm_kms_helper,drm
mxm_wmi                 1925  1 nouveau
video                  21032  1 nouveau
wmi                     6287  2 nouveau,mxm_wmi




Notice that the nouveau VGA driver is loaded and is in use. Is Xen VGA 
Passthrough 100% successful? I have successfully installed the NVIDIA 
driver but I couldn't get it to load, so I reverted back to the nouveau 
driver.

I have such tough time getting Xen VGA Passthrough to work successfully 
on Windows HVM domU that I am giving up on Xen VGA Passthrough to 
Windows HVM domU!!! Windows 7 and Windows 8 HVM domU device manager 
always report error code 43 with a yellow triangle. Windows XP HVM domU 
device manager always report error code 10 with a yellow circle.

-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 27 15:17:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 15:17:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TS87s-0006zp-MA; Sat, 27 Oct 2012 15:16:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TS87r-0006zh-98
	for xen-devel@lists.xensource.com; Sat, 27 Oct 2012 15:16:39 +0000
Received: from [85.158.139.211:53782] by server-6.bemta-5.messagelabs.com id
	4B/25-32589-6DAFB805; Sat, 27 Oct 2012 15:16:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1351350997!24002369!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY0NTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3379 invoked from network); 27 Oct 2012 15:16:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Oct 2012 15:16:37 -0000
X-IronPort-AV: E=Sophos;i="4.80,662,1344211200"; d="scan'208";a="15439329"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Oct 2012 15:16:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sat, 27 Oct 2012 16:16:37 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TS87p-0000Dh-2Z;
	Sat, 27 Oct 2012 15:16:37 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TS87p-0004IU-1t;
	Sat, 27 Oct 2012 16:16:37 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Sat, 27 Oct 2012 16:16:37 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 14096: trouble: broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14096 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14096/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-win           3 host-install(3)         broken REGR. vs. 13919
 test-amd64-i386-rhel6hvm-amd  3 host-install(3)         broken REGR. vs. 13919
 test-amd64-i386-xl-win-vcpus1  3 host-install(3)        broken REGR. vs. 13919
 test-amd64-i386-xl-win7-amd64  3 host-install(3)        broken REGR. vs. 13919
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3)   broken REGR. vs. 13919
 test-i386-i386-xl             3 host-install(3)         broken REGR. vs. 13919
 test-i386-i386-win            3 host-install(3)         broken REGR. vs. 13919
 test-amd64-amd64-xl-win7-amd64  3 host-install(3)       broken REGR. vs. 13919
 test-i386-i386-xl-winxpsp3    3 host-install(3)         broken REGR. vs. 13919
 test-amd64-i386-xend-winxpsp3  3 host-install(3)        broken REGR. vs. 13919
 test-amd64-i386-xl-multivcpu  3 host-install(3)         broken REGR. vs. 13919
 test-amd64-amd64-xl-winxpsp3  3 host-install(3)         broken REGR. vs. 13919
 test-amd64-i386-xl            3 host-install(3)         broken REGR. vs. 13919
 test-amd64-i386-xl-winxpsp3-vcpus1  3 host-install(3)   broken REGR. vs. 13919
 test-amd64-amd64-pv           3 host-install(3)         broken REGR. vs. 13919
 test-i386-i386-xl-qemuu-winxpsp3  3 host-install(3)     broken REGR. vs. 13919
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 13919
 test-amd64-amd64-xl-win       3 host-install(3)         broken REGR. vs. 13919
 test-i386-i386-pv             3 host-install(3)         broken REGR. vs. 13919
 test-amd64-i386-win-vcpus1    3 host-install(3)         broken REGR. vs. 13919
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)       broken REGR. vs. 13919
 test-amd64-i386-pair         4 host-install/dst_host(4) broken REGR. vs. 13919
 test-amd64-i386-pair         3 host-install/src_host(3) broken REGR. vs. 13919
 test-amd64-amd64-pair        3 host-install/src_host(3) broken REGR. vs. 13919
 test-amd64-amd64-pair        4 host-install/dst_host(4) broken REGR. vs. 13919
 test-i386-i386-pair          4 host-install/dst_host(4) broken REGR. vs. 13919
 test-i386-i386-pair          3 host-install/src_host(3) broken REGR. vs. 13919

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      3 host-install(3)         broken REGR. vs. 13919
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)         broken REGR. vs. 13919
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)      broken REGR. vs. 13919

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass

version targeted for testing:
 xen                  69d1cc78a5bd
baseline version:
 xen                  a15596a619ed

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           broken  
 test-i386-i386-xl                                            broken  
 test-amd64-i386-rhel6hvm-amd                                 broken  
 test-amd64-i386-qemuu-rhel6hvm-amd                           broken  
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               broken  
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        broken  
 test-amd64-i386-pair                                         broken  
 test-i386-i386-pair                                          broken  
 test-amd64-amd64-xl-sedf-pin                                 broken  
 test-amd64-amd64-pv                                          broken  
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            broken  
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   broken  
 test-amd64-i386-xl-win-vcpus1                                broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           broken  
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          broken  
 test-i386-i386-win                                           broken  
 test-amd64-amd64-xl-win                                      broken  
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             broken  
 test-amd64-i386-xend-winxpsp3                                broken  
 test-amd64-amd64-xl-winxpsp3                                 broken  
 test-i386-i386-xl-winxpsp3                                   broken  


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   23385:69d1cc78a5bd
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:10:04 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    [ Includes 25589:60f09d1ab1fe for CVE-2012-2625 ]
    
    
changeset:   23384:a15596a619ed
user:        Daniel De Graaf 
date:        Thu Oct 04 10:44:43 2012 +0200
    
    x86: check remote MMIO remap permissions
    
    When a domain is mapping pages from a different pg_owner domain, the
    iomem_access checks are currently only applied to the pg_owner domain,
    potentially allowing a domain with a more restrictive iomem_access
    policy to have the pages mapped into its page tables. To catch this,
    also check the owner of the page tables. The current domain does not
    need to be checked because the ability to manipulate a domain's page
    tables implies full access to the target domain, so checking that
    domain's permission is sufficient.
    
    Signed-off-by: Daniel De Graaf 
    Acked-by: Jan Beulich 
    xen-unstable changeset: 25952:8278d7d8fa48
    xen-unstable date: Wed Sep 26 09:56:07 UTC 2012
    
    
========================================
commit d7d453f51459b591faa96d1c123b5bfff7c5b6b6
Author: Ian Jackson 
Date:   Thu Sep 6 17:05:30 2012 +0100

    Disable qemu monitor by default.  The qemu monitor is an overly
    powerful feature which must be protected from untrusted (guest)
    administrators.
    
    Neither xl nor xend expect qemu to produce this monitor unless it is
    explicitly requested.
    
    This is a security problem, XSA-19.  Previously it was CVE-2007-0998
    in Red Hat but we haven't dealt with it in upstream.  We hope to have
    a new CVE for it here but we don't have one yet.
    
    Signed-off-by: Ian Jackson 
    (cherry picked from commit bacc0d302445c75f18f4c826750fb5853b60e7ca)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 27 15:17:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 15:17:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TS87s-0006zp-MA; Sat, 27 Oct 2012 15:16:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TS87r-0006zh-98
	for xen-devel@lists.xensource.com; Sat, 27 Oct 2012 15:16:39 +0000
Received: from [85.158.139.211:53782] by server-6.bemta-5.messagelabs.com id
	4B/25-32589-6DAFB805; Sat, 27 Oct 2012 15:16:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1351350997!24002369!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY0NTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3379 invoked from network); 27 Oct 2012 15:16:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Oct 2012 15:16:37 -0000
X-IronPort-AV: E=Sophos;i="4.80,662,1344211200"; d="scan'208";a="15439329"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Oct 2012 15:16:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sat, 27 Oct 2012 16:16:37 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TS87p-0000Dh-2Z;
	Sat, 27 Oct 2012 15:16:37 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TS87p-0004IU-1t;
	Sat, 27 Oct 2012 16:16:37 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Sat, 27 Oct 2012 16:16:37 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 14096: trouble: broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14096 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14096/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-win           3 host-install(3)         broken REGR. vs. 13919
 test-amd64-i386-rhel6hvm-amd  3 host-install(3)         broken REGR. vs. 13919
 test-amd64-i386-xl-win-vcpus1  3 host-install(3)        broken REGR. vs. 13919
 test-amd64-i386-xl-win7-amd64  3 host-install(3)        broken REGR. vs. 13919
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3)   broken REGR. vs. 13919
 test-i386-i386-xl             3 host-install(3)         broken REGR. vs. 13919
 test-i386-i386-win            3 host-install(3)         broken REGR. vs. 13919
 test-amd64-amd64-xl-win7-amd64  3 host-install(3)       broken REGR. vs. 13919
 test-i386-i386-xl-winxpsp3    3 host-install(3)         broken REGR. vs. 13919
 test-amd64-i386-xend-winxpsp3  3 host-install(3)        broken REGR. vs. 13919
 test-amd64-i386-xl-multivcpu  3 host-install(3)         broken REGR. vs. 13919
 test-amd64-amd64-xl-winxpsp3  3 host-install(3)         broken REGR. vs. 13919
 test-amd64-i386-xl            3 host-install(3)         broken REGR. vs. 13919
 test-amd64-i386-xl-winxpsp3-vcpus1  3 host-install(3)   broken REGR. vs. 13919
 test-amd64-amd64-pv           3 host-install(3)         broken REGR. vs. 13919
 test-i386-i386-xl-qemuu-winxpsp3  3 host-install(3)     broken REGR. vs. 13919
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 13919
 test-amd64-amd64-xl-win       3 host-install(3)         broken REGR. vs. 13919
 test-i386-i386-pv             3 host-install(3)         broken REGR. vs. 13919
 test-amd64-i386-win-vcpus1    3 host-install(3)         broken REGR. vs. 13919
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)       broken REGR. vs. 13919
 test-amd64-i386-pair         4 host-install/dst_host(4) broken REGR. vs. 13919
 test-amd64-i386-pair         3 host-install/src_host(3) broken REGR. vs. 13919
 test-amd64-amd64-pair        3 host-install/src_host(3) broken REGR. vs. 13919
 test-amd64-amd64-pair        4 host-install/dst_host(4) broken REGR. vs. 13919
 test-i386-i386-pair          4 host-install/dst_host(4) broken REGR. vs. 13919
 test-i386-i386-pair          3 host-install/src_host(3) broken REGR. vs. 13919

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      3 host-install(3)         broken REGR. vs. 13919
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)         broken REGR. vs. 13919
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)      broken REGR. vs. 13919

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass

version targeted for testing:
 xen                  69d1cc78a5bd
baseline version:
 xen                  a15596a619ed

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           broken  
 test-i386-i386-xl                                            broken  
 test-amd64-i386-rhel6hvm-amd                                 broken  
 test-amd64-i386-qemuu-rhel6hvm-amd                           broken  
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               broken  
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        broken  
 test-amd64-i386-pair                                         broken  
 test-i386-i386-pair                                          broken  
 test-amd64-amd64-xl-sedf-pin                                 broken  
 test-amd64-amd64-pv                                          broken  
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            broken  
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   broken  
 test-amd64-i386-xl-win-vcpus1                                broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           broken  
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          broken  
 test-i386-i386-win                                           broken  
 test-amd64-amd64-xl-win                                      broken  
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             broken  
 test-amd64-i386-xend-winxpsp3                                broken  
 test-amd64-amd64-xl-winxpsp3                                 broken  
 test-i386-i386-xl-winxpsp3                                   broken  


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   23385:69d1cc78a5bd
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:10:04 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    [ Includes 25589:60f09d1ab1fe for CVE-2012-2625 ]
    
    
changeset:   23384:a15596a619ed
user:        Daniel De Graaf 
date:        Thu Oct 04 10:44:43 2012 +0200
    
    x86: check remote MMIO remap permissions
    
    When a domain is mapping pages from a different pg_owner domain, the
    iomem_access checks are currently only applied to the pg_owner domain,
    potentially allowing a domain with a more restrictive iomem_access
    policy to have the pages mapped into its page tables. To catch this,
    also check the owner of the page tables. The current domain does not
    need to be checked because the ability to manipulate a domain's page
    tables implies full access to the target domain, so checking that
    domain's permission is sufficient.
    
    Signed-off-by: Daniel De Graaf 
    Acked-by: Jan Beulich 
    xen-unstable changeset: 25952:8278d7d8fa48
    xen-unstable date: Wed Sep 26 09:56:07 UTC 2012
    
    
========================================
commit d7d453f51459b591faa96d1c123b5bfff7c5b6b6
Author: Ian Jackson 
Date:   Thu Sep 6 17:05:30 2012 +0100

    Disable qemu monitor by default.  The qemu monitor is an overly
    powerful feature which must be protected from untrusted (guest)
    administrators.
    
    Neither xl nor xend expect qemu to produce this monitor unless it is
    explicitly requested.
    
    This is a security problem, XSA-19.  Previously it was CVE-2007-0998
    in Red Hat but we haven't dealt with it in upstream.  We hope to have
    a new CVE for it here but we don't have one yet.
    
    Signed-off-by: Ian Jackson 
    (cherry picked from commit bacc0d302445c75f18f4c826750fb5853b60e7ca)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 27 15:28:07 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 15:28:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TS8Ib-0007Hy-1V; Sat, 27 Oct 2012 15:27:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TS5cy-0004BI-KR
	for xen-devel@lists.xen.org; Sat, 27 Oct 2012 12:36:37 +0000
Received: from [85.158.137.99:37782] by server-2.bemta-3.messagelabs.com id
	34/89-00604-055DB805; Sat, 27 Oct 2012 12:36:32 +0000
X-Env-Sender: slawek.k_xl@wp.pl
X-Msg-Ref: server-10.tower-217.messagelabs.com!1351341390!23166888!1
X-Originating-IP: [212.77.101.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuNzcuMTAxLjcgPT4gOTExNjY=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuNzcuMTAxLjcgPT4gOTExNjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18596 invoked from network); 27 Oct 2012 12:36:32 -0000
Received: from mx3.wp.pl (HELO mx3.wp.pl) (212.77.101.7)
	by server-10.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Oct 2012 12:36:32 -0000
Received: (wp-smtpd smtp.wp.pl 7682 invoked from network);
	27 Oct 2012 14:36:29 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wp.pl; s=1024a;
	t=1351341389; bh=PwxkuT0ETTcFx8417Met2U36F35+cDs8eLgVHI51xc4=;
	h=From:To:Cc:Subject;
	b=lPa6z/sw6g59kYYWbiOQ/qP/0lxSQ6VWd0WqyZOVP7PM7vN9kQ9R1C40P/EOHtjmi
	xs/uM2YHMR+rsr/8+u2KLW6E61XhNxo6010dGj5IH6g2AxGKFoSPKX2J6KAxE8qBo5
	lpQq4A6EeKByd4Tlgor3/5aE0fMSaEtMIPDffKXw=
Received: from out.poczta.wp.pl (HELO localhost) ([212.77.101.240])
	(envelope-sender )
	by smtp.wp.pl (WP-SMTPD) with SMTP
	for ; 27 Oct 2012 14:36:29 +0200
Date: Sat, 27 Oct 2012 14:36:29 +0200
From: =?ISO-8859-2?Q?S=B3awek_Kosowski?= 
To: Ian Campbell 
Message-ID: <508bd54daa7c16.24872119@wp.pl>
References: <5086e5740096e2.94910907@wp.pl>
	<1351068592.2237.104.camel@zakaz.uk.xensource.com>
In-reply-to: <5086e5740096e2.94910907@wp.pl>
	<1351068592.2237.104.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
X-Mailer: Interfejs WWW nowej poczty Wirtualnej Polski
X-User-Agent: Mozilla/5.0 (Windows NT 6.1;
	WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.94
	Safari/537.4
Organization: Poznaj Poczte WP http://poczta.wp.pl/info-start.html
X-WP-IP: 92.105.5.90
X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A.
X-WP-SPAM: NO 0000000 [UYOk]                               
X-Mailman-Approved-At: Sat, 27 Oct 2012 15:27:44 +0000
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Kernel paging request error
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thank you, now I don't have any errors after reboot, we'll see how it will =
be in the future.

Regards
Slawek

> On Tue, 2012-10-23 at 19:44 +0100, S=B3awek Kosowski wrote:
> > Reposting from xen-users (no response)
> > I'm having a problem with: http://pastebin.com/CuGHqwhy
> > It occurs on the reboot, but sometimes, when I try to start manually on=
e =

> of
> > my machines. Sometime, one of the machines does not want to start
> > permanently and I have to reinstall/restore it.
> =

> One experiment to try, based on Debian bug #642154 would be to try
> "noxsave" and/or "noxsaveopt" on your kernel command line. Please try
> each independently and both together.
> =

> I thought this sort of thing was ironed out before 3.2. Since you are
> running a bpo kernel you could also consider running a backport of Xen
> 4.1 from Wheezy as well.
> =

> > This problem comes for me randomly, but maybe there is a trigger.
> > I've tried to follow:
> > http://xen.1045712.n5.nabble.com/2-6-32-27-dom0-BUG-unable-to-handle-ke=
rnel-paging-request-td3323011.html
> > and raise /proc/sys/vm/min_free_kbytes, but it did not help.
> =

> That is a completely unrelated problem, "BUG unable to handle kernel
> paging request" is a very generic error message which is common to loads
> of different potential issues.
> =

> [...]
> =

> Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 27 15:28:07 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 15:28:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TS8Ib-0007Hy-1V; Sat, 27 Oct 2012 15:27:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TS5cy-0004BI-KR
	for xen-devel@lists.xen.org; Sat, 27 Oct 2012 12:36:37 +0000
Received: from [85.158.137.99:37782] by server-2.bemta-3.messagelabs.com id
	34/89-00604-055DB805; Sat, 27 Oct 2012 12:36:32 +0000
X-Env-Sender: slawek.k_xl@wp.pl
X-Msg-Ref: server-10.tower-217.messagelabs.com!1351341390!23166888!1
X-Originating-IP: [212.77.101.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuNzcuMTAxLjcgPT4gOTExNjY=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuNzcuMTAxLjcgPT4gOTExNjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18596 invoked from network); 27 Oct 2012 12:36:32 -0000
Received: from mx3.wp.pl (HELO mx3.wp.pl) (212.77.101.7)
	by server-10.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Oct 2012 12:36:32 -0000
Received: (wp-smtpd smtp.wp.pl 7682 invoked from network);
	27 Oct 2012 14:36:29 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wp.pl; s=1024a;
	t=1351341389; bh=PwxkuT0ETTcFx8417Met2U36F35+cDs8eLgVHI51xc4=;
	h=From:To:Cc:Subject;
	b=lPa6z/sw6g59kYYWbiOQ/qP/0lxSQ6VWd0WqyZOVP7PM7vN9kQ9R1C40P/EOHtjmi
	xs/uM2YHMR+rsr/8+u2KLW6E61XhNxo6010dGj5IH6g2AxGKFoSPKX2J6KAxE8qBo5
	lpQq4A6EeKByd4Tlgor3/5aE0fMSaEtMIPDffKXw=
Received: from out.poczta.wp.pl (HELO localhost) ([212.77.101.240])
	(envelope-sender )
	by smtp.wp.pl (WP-SMTPD) with SMTP
	for ; 27 Oct 2012 14:36:29 +0200
Date: Sat, 27 Oct 2012 14:36:29 +0200
From: =?ISO-8859-2?Q?S=B3awek_Kosowski?= 
To: Ian Campbell 
Message-ID: <508bd54daa7c16.24872119@wp.pl>
References: <5086e5740096e2.94910907@wp.pl>
	<1351068592.2237.104.camel@zakaz.uk.xensource.com>
In-reply-to: <5086e5740096e2.94910907@wp.pl>
	<1351068592.2237.104.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
X-Mailer: Interfejs WWW nowej poczty Wirtualnej Polski
X-User-Agent: Mozilla/5.0 (Windows NT 6.1;
	WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.94
	Safari/537.4
Organization: Poznaj Poczte WP http://poczta.wp.pl/info-start.html
X-WP-IP: 92.105.5.90
X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A.
X-WP-SPAM: NO 0000000 [UYOk]                               
X-Mailman-Approved-At: Sat, 27 Oct 2012 15:27:44 +0000
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Kernel paging request error
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thank you, now I don't have any errors after reboot, we'll see how it will =
be in the future.

Regards
Slawek

> On Tue, 2012-10-23 at 19:44 +0100, S=B3awek Kosowski wrote:
> > Reposting from xen-users (no response)
> > I'm having a problem with: http://pastebin.com/CuGHqwhy
> > It occurs on the reboot, but sometimes, when I try to start manually on=
e =

> of
> > my machines. Sometime, one of the machines does not want to start
> > permanently and I have to reinstall/restore it.
> =

> One experiment to try, based on Debian bug #642154 would be to try
> "noxsave" and/or "noxsaveopt" on your kernel command line. Please try
> each independently and both together.
> =

> I thought this sort of thing was ironed out before 3.2. Since you are
> running a bpo kernel you could also consider running a backport of Xen
> 4.1 from Wheezy as well.
> =

> > This problem comes for me randomly, but maybe there is a trigger.
> > I've tried to follow:
> > http://xen.1045712.n5.nabble.com/2-6-32-27-dom0-BUG-unable-to-handle-ke=
rnel-paging-request-td3323011.html
> > and raise /proc/sys/vm/min_free_kbytes, but it did not help.
> =

> That is a completely unrelated problem, "BUG unable to handle kernel
> paging request" is a very generic error message which is common to loads
> of different potential issues.
> =

> [...]
> =

> Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 27 15:29:40 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 15:29:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TS8K6-0007MI-HJ; Sat, 27 Oct 2012 15:29:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TS8K5-0007MC-35
	for xen-devel@lists.xensource.com; Sat, 27 Oct 2012 15:29:17 +0000
Received: from [85.158.143.35:51578] by server-3.bemta-4.messagelabs.com id
	9E/8B-24279-CCDFB805; Sat, 27 Oct 2012 15:29:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1351351755!14717977!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY0NTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21172 invoked from network); 27 Oct 2012 15:29:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Oct 2012 15:29:15 -0000
X-IronPort-AV: E=Sophos;i="4.80,662,1344211200"; d="scan'208";a="15439452"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Oct 2012 15:29:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sat, 27 Oct 2012 16:29:15 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TS8K3-0000Hk-6a;
	Sat, 27 Oct 2012 15:29:15 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TS8K3-0005OJ-5y;
	Sat, 27 Oct 2012 16:29:15 +0100
To: 
Message-ID: 
From: xen.org 
Date: Sat, 27 Oct 2012 16:29:15 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 14101: trouble: blocked/broken
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14101 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14101/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386                    2 host-install(2)         broken REGR. vs. 13919
 build-amd64                   2 host-install(2)         broken REGR. vs. 13919
 build-i386-pvops              2 host-install(2)         broken REGR. vs. 13919
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 13919
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13919
 build-i386-oldkern            2 host-install(2)         broken REGR. vs. 13919

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 xen                  69d1cc78a5bd
baseline version:
 xen                  a15596a619ed

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           broken  
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             broken  
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   23385:69d1cc78a5bd
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:10:04 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    [ Includes 25589:60f09d1ab1fe for CVE-2012-2625 ]
    
    
changeset:   23384:a15596a619ed
user:        Daniel De Graaf 
date:        Thu Oct 04 10:44:43 2012 +0200
    
    x86: check remote MMIO remap permissions
    
    When a domain is mapping pages from a different pg_owner domain, the
    iomem_access checks are currently only applied to the pg_owner domain,
    potentially allowing a domain with a more restrictive iomem_access
    policy to have the pages mapped into its page tables. To catch this,
    also check the owner of the page tables. The current domain does not
    need to be checked because the ability to manipulate a domain's page
    tables implies full access to the target domain, so checking that
    domain's permission is sufficient.
    
    Signed-off-by: Daniel De Graaf 
    Acked-by: Jan Beulich 
    xen-unstable changeset: 25952:8278d7d8fa48
    xen-unstable date: Wed Sep 26 09:56:07 UTC 2012
    
    
========================================
commit d7d453f51459b591faa96d1c123b5bfff7c5b6b6
Author: Ian Jackson 
Date:   Thu Sep 6 17:05:30 2012 +0100

    Disable qemu monitor by default.  The qemu monitor is an overly
    powerful feature which must be protected from untrusted (guest)
    administrators.
    
    Neither xl nor xend expect qemu to produce this monitor unless it is
    explicitly requested.
    
    This is a security problem, XSA-19.  Previously it was CVE-2007-0998
    in Red Hat but we haven't dealt with it in upstream.  We hope to have
    a new CVE for it here but we don't have one yet.
    
    Signed-off-by: Ian Jackson 
    (cherry picked from commit bacc0d302445c75f18f4c826750fb5853b60e7ca)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 27 15:29:40 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 15:29:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TS8K6-0007MI-HJ; Sat, 27 Oct 2012 15:29:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TS8K5-0007MC-35
	for xen-devel@lists.xensource.com; Sat, 27 Oct 2012 15:29:17 +0000
Received: from [85.158.143.35:51578] by server-3.bemta-4.messagelabs.com id
	9E/8B-24279-CCDFB805; Sat, 27 Oct 2012 15:29:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1351351755!14717977!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY0NTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21172 invoked from network); 27 Oct 2012 15:29:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Oct 2012 15:29:15 -0000
X-IronPort-AV: E=Sophos;i="4.80,662,1344211200"; d="scan'208";a="15439452"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Oct 2012 15:29:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sat, 27 Oct 2012 16:29:15 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TS8K3-0000Hk-6a;
	Sat, 27 Oct 2012 15:29:15 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TS8K3-0005OJ-5y;
	Sat, 27 Oct 2012 16:29:15 +0100
To: 
Message-ID: 
From: xen.org 
Date: Sat, 27 Oct 2012 16:29:15 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 14101: trouble: blocked/broken
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14101 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14101/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386                    2 host-install(2)         broken REGR. vs. 13919
 build-amd64                   2 host-install(2)         broken REGR. vs. 13919
 build-i386-pvops              2 host-install(2)         broken REGR. vs. 13919
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 13919
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13919
 build-i386-oldkern            2 host-install(2)         broken REGR. vs. 13919

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 xen                  69d1cc78a5bd
baseline version:
 xen                  a15596a619ed

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           broken  
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             broken  
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   23385:69d1cc78a5bd
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:10:04 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    [ Includes 25589:60f09d1ab1fe for CVE-2012-2625 ]
    
    
changeset:   23384:a15596a619ed
user:        Daniel De Graaf 
date:        Thu Oct 04 10:44:43 2012 +0200
    
    x86: check remote MMIO remap permissions
    
    When a domain is mapping pages from a different pg_owner domain, the
    iomem_access checks are currently only applied to the pg_owner domain,
    potentially allowing a domain with a more restrictive iomem_access
    policy to have the pages mapped into its page tables. To catch this,
    also check the owner of the page tables. The current domain does not
    need to be checked because the ability to manipulate a domain's page
    tables implies full access to the target domain, so checking that
    domain's permission is sufficient.
    
    Signed-off-by: Daniel De Graaf 
    Acked-by: Jan Beulich 
    xen-unstable changeset: 25952:8278d7d8fa48
    xen-unstable date: Wed Sep 26 09:56:07 UTC 2012
    
    
========================================
commit d7d453f51459b591faa96d1c123b5bfff7c5b6b6
Author: Ian Jackson 
Date:   Thu Sep 6 17:05:30 2012 +0100

    Disable qemu monitor by default.  The qemu monitor is an overly
    powerful feature which must be protected from untrusted (guest)
    administrators.
    
    Neither xl nor xend expect qemu to produce this monitor unless it is
    explicitly requested.
    
    This is a security problem, XSA-19.  Previously it was CVE-2007-0998
    in Red Hat but we haven't dealt with it in upstream.  We hope to have
    a new CVE for it here but we don't have one yet.
    
    Signed-off-by: Ian Jackson 
    (cherry picked from commit bacc0d302445c75f18f4c826750fb5853b60e7ca)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 27 15:36:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 15:36:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TS8QT-0007gg-Bq; Sat, 27 Oct 2012 15:35:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TS8QR-0007gY-Rp; Sat, 27 Oct 2012 15:35:52 +0000
Received: from [193.109.254.147:25003] by server-15.bemta-14.messagelabs.com
	id E0/6E-12105-75FFB805; Sat, 27 Oct 2012 15:35:51 +0000
X-Env-Sender: singapore.mr.teo.en.ming@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1351352146!2994298!1
X-Originating-IP: [209.85.210.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3381 invoked from network); 27 Oct 2012 15:35:48 -0000
Received: from mail-da0-f45.google.com (HELO mail-da0-f45.google.com)
	(209.85.210.45)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Oct 2012 15:35:48 -0000
Received: by mail-da0-f45.google.com with SMTP id n15so1797925dad.32
	for ; Sat, 27 Oct 2012 08:35:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=gjpF/GqFfTUNvyr1B7YCBdW9OvR2N+Vfap0ITIGiGgA=;
	b=tvaTuq53UdPEwmDhy0XL7R0S8dMb25OvZIe9p4G32tsHy0l7dCdczavgI/uOoHNGJs
	6zFiV+tbAzSD0VkvO58iCpwee1TG8bOu0xLHDs0HReQzb+UknA+olTm2xsZobAPvSUb7
	Z8ubEJdbO3MWvmzvIFOanFH7VRnekQLNhvol3PzQTakt0lj2WWJ98z4jNjG70g+m+UPw
	/YTyrt21LB1ouP+0+lY7E7iGanttnEYz4qmRCyRdPbvZ8G6SMqYdDE3kCaVtq8JUngP4
	nza0omd0/fpLo4D+QtDrPJeXxFPs4ZzshMbs4K6K2SuguX1iUz6GL5OVaHlCIIVIeQF1
	b3yw==
Received: by 10.66.87.133 with SMTP id ay5mr70535199pab.59.1351352146431;
	Sat, 27 Oct 2012 08:35:46 -0700 (PDT)
Received: from [192.168.1.17] (cm152.gamma205.maxonline.com.sg.
	[202.156.205.152])
	by mx.google.com with ESMTPS id c1sm2839345pav.23.2012.10.27.08.35.44
	(version=SSLv3 cipher=OTHER); Sat, 27 Oct 2012 08:35:45 -0700 (PDT)
Message-ID: <508BFF4F.7090402@gmail.com>
Date: Sat, 27 Oct 2012 23:35:43 +0800
From: "Teo En Ming (Zhang Enming)" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: "Teo En Ming (Zhang Enming)" 
References: <508BF6EF.2050908@gmail.com>
In-Reply-To: <508BF6EF.2050908@gmail.com>
Cc: "xen-users@lists.xen.org" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Is Xen VGA Passthrough to CentOS 6.3 x86-64 HVM
	domU successful?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

My CentOS 6.3 x86-64 HVM domU configuration:

# This configuration file will only work with Xen 4.1.3-rc1-pre and NOT
# Xen 4.2-unstable due to the disk parameter.
#
# XL domain configuration file for Ubuntu 12.04 Precise Pangolin Beta 1 
amd64 HVM domU
# Please refer to "man xl.cfg" for further explanations.
# See also docs/misc/xl-network-configuration.markdown and
# docs/misc/xl-disk-configuration.txt
# Written by Teo En Ming (Zhang Enming)
# Email #1: teo.en.ming@gmail.com
# Email #2: teo-en-ming@teo-en-ming.com
# Mobile Phone: +65-8369-2618
# Country: Singapore
# Date: 20 Mar 2012 Tue
name="CentOS"
builder="hvm"
vcpus=2
memory=1024
on_poweroff="destroy"
on_reboot="restart"
on_crash="destroy"
# Format compatible with Xen 4.2-unstable changeset 25070 only.
disk=[ 'format=raw, vdev=hda, access=rw, 
target=/etc/xen/images/centos63.img', 'format=raw, vdev=hdc, access=ro, 
devtype=cdrom, target=/home/teo-en-ming/CentOS-6.3-x86_64-bin-DVD1.iso' ]
# Format compatible with Xen 4.1.3-rc1-pre only.
#disk=[ 
'file:/var/lib/libvirt/images/Ubuntu-12.04-beta1-amd64.img,hda,w', 
'file:/home/teo-en-ming/Downloads/ubuntu-12.04-beta1-dvd-amd64.iso,hdc:cdrom,r' 
]
vif=[ 'bridge=eth0,type=ioemu,model=e1000' ]
#boot=[c|d|n]
#Selects the emulated virtual device to boot from. Options are hard disk 
(c), cd-rom (d) or network/PXE (n).
#Multiple options can be given and will be attempted in the order they 
are given. e.g. to boot from cd-rom
#but fallback to the hard disk you can give dc. The default is cd.
#boot="dc"
boot="c"
acpi=1
#xen_platform_pci=1
#viridian=1
stdvga=0
vnc=1
vnclisten="localhost"
vncdisplay=0
vncunused=1
vncpasswd=""
sdl=0
usb=1
usbdevice="tablet"
gfx_passthru=1
# VGA Passthrough Gigabyte Geforce GTX 560 1 GB GDDR5 PCI Express x16 
VGA card.
pci = [ 
'01:00.0','01:00.1','00:1b.0','00:1a.0','00:1a.1','00:1a.2','00:1a.7','00:1d.0','00:1d.1','00:1d.2','00:1d.7' 
]

-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore




On 10/27/2012 10:59 PM, Teo En Ming (Zhang Enming) wrote:
> Hi,
>
> I have just passed through my NVIDIA Geforce GTX 560 to CentOS 6.3 
> x86-64 HVM domU. I am wondering whether the Xen VGA Passthrough is 
> successful.
>
> The following information is obtained from inside CentOS 6.3 x86-64 
> HVM domU:
>
> 00:05.0 VGA compatible controller: NVIDIA Corporation GF114 [GeForce 
> GTX 560] (rev a1) (prog-if 00 [VGA controller])
>     Subsystem: Giga-byte Technology Device 3527
>     Physical Slot: 5
>     Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
> ParErr- Stepping- SERR- FastB2B- DisINTx-
>     Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- 
> SERR-      Latency: 64
>     Interrupt: pin A routed to IRQ 36
>     Region 0: Memory at dc000000 (32-bit, non-prefetchable) [size=32M]
>     Region 1: Memory at d0000000 (64-bit, prefetchable) [size=128M]
>     Region 3: Memory at d8000000 (64-bit, prefetchable) [size=64M]
>     Region 5: I/O ports at e000 [size=128]
>     [virtual] Expansion ROM at f1080000 [disabled] [size=512K]
>     Capabilities: [60] Power Management version 3
>         Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>         Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
>     Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
>         Address: 0000000000000000  Data: 0000
>     Capabilities: [78] Express (v1) Endpoint, MSI 00
>         DevCap:    MaxPayload 128 bytes, PhantFunc 0, Latency L0s 
> <4us, L1 <64us
>             ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
>         DevCtl:    Report errors: Correctable- Non-Fatal- Fatal- 
> Unsupported-
>             RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
>             MaxPayload 128 bytes, MaxReadReq 512 bytes
>         DevSta:    CorrErr- UncorrErr+ FatalErr- UnsuppReq+ AuxPwr- 
> TransPend-
>         LnkCap:    Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, 
> Latency L0 <256ns, L1 <4us
>             ClockPM+ Surprise- LLActRep- BwNot-
>         LnkCtl:    ASPM Disabled; RCB 64 bytes Disabled- Retrain- 
> CommClk-
>             ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>         LnkSta:    Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ 
> DLActive- BWMgmt- ABWMgmt-
>     Capabilities: [b4] Vendor Specific Information 
>     Kernel driver in use: nouveau
>     Kernel modules: nvidia, nouveau, nvidiafb
>
>
>
> [root@centos63 ~]# lsmod | grep nouveau
> nouveau               791165  2
> ttm                    82562  1 nouveau
> drm_kms_helper         34122  1 nouveau
> drm                   250067  4 nouveau,ttm,drm_kms_helper
> i2c_core               31276  14 
> tuner_simple,tda9887,tda8290,wm8775,tuner,cx25840,pvrusb2,v4l2_common,videodev,tveeprom,i2c_piix4,nouveau,drm_kms_helper,drm
> mxm_wmi                 1925  1 nouveau
> video                  21032  1 nouveau
> wmi                     6287  2 nouveau,mxm_wmi
>
>
>
>
> Notice that the nouveau VGA driver is loaded and is in use. Is Xen VGA 
> Passthrough 100% successful? I have successfully installed the NVIDIA 
> driver but I couldn't get it to load, so I reverted back to the 
> nouveau driver.
>
> I have such tough time getting Xen VGA Passthrough to work 
> successfully on Windows HVM domU that I am giving up on Xen VGA 
> Passthrough to Windows HVM domU!!! Windows 7 and Windows 8 HVM domU 
> device manager always report error code 43 with a yellow triangle. 
> Windows XP HVM domU device manager always report error code 10 with a 
> yellow circle.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 27 15:36:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 15:36:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TS8QT-0007gg-Bq; Sat, 27 Oct 2012 15:35:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TS8QR-0007gY-Rp; Sat, 27 Oct 2012 15:35:52 +0000
Received: from [193.109.254.147:25003] by server-15.bemta-14.messagelabs.com
	id E0/6E-12105-75FFB805; Sat, 27 Oct 2012 15:35:51 +0000
X-Env-Sender: singapore.mr.teo.en.ming@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1351352146!2994298!1
X-Originating-IP: [209.85.210.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3381 invoked from network); 27 Oct 2012 15:35:48 -0000
Received: from mail-da0-f45.google.com (HELO mail-da0-f45.google.com)
	(209.85.210.45)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Oct 2012 15:35:48 -0000
Received: by mail-da0-f45.google.com with SMTP id n15so1797925dad.32
	for ; Sat, 27 Oct 2012 08:35:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=gjpF/GqFfTUNvyr1B7YCBdW9OvR2N+Vfap0ITIGiGgA=;
	b=tvaTuq53UdPEwmDhy0XL7R0S8dMb25OvZIe9p4G32tsHy0l7dCdczavgI/uOoHNGJs
	6zFiV+tbAzSD0VkvO58iCpwee1TG8bOu0xLHDs0HReQzb+UknA+olTm2xsZobAPvSUb7
	Z8ubEJdbO3MWvmzvIFOanFH7VRnekQLNhvol3PzQTakt0lj2WWJ98z4jNjG70g+m+UPw
	/YTyrt21LB1ouP+0+lY7E7iGanttnEYz4qmRCyRdPbvZ8G6SMqYdDE3kCaVtq8JUngP4
	nza0omd0/fpLo4D+QtDrPJeXxFPs4ZzshMbs4K6K2SuguX1iUz6GL5OVaHlCIIVIeQF1
	b3yw==
Received: by 10.66.87.133 with SMTP id ay5mr70535199pab.59.1351352146431;
	Sat, 27 Oct 2012 08:35:46 -0700 (PDT)
Received: from [192.168.1.17] (cm152.gamma205.maxonline.com.sg.
	[202.156.205.152])
	by mx.google.com with ESMTPS id c1sm2839345pav.23.2012.10.27.08.35.44
	(version=SSLv3 cipher=OTHER); Sat, 27 Oct 2012 08:35:45 -0700 (PDT)
Message-ID: <508BFF4F.7090402@gmail.com>
Date: Sat, 27 Oct 2012 23:35:43 +0800
From: "Teo En Ming (Zhang Enming)" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: "Teo En Ming (Zhang Enming)" 
References: <508BF6EF.2050908@gmail.com>
In-Reply-To: <508BF6EF.2050908@gmail.com>
Cc: "xen-users@lists.xen.org" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Is Xen VGA Passthrough to CentOS 6.3 x86-64 HVM
	domU successful?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

My CentOS 6.3 x86-64 HVM domU configuration:

# This configuration file will only work with Xen 4.1.3-rc1-pre and NOT
# Xen 4.2-unstable due to the disk parameter.
#
# XL domain configuration file for Ubuntu 12.04 Precise Pangolin Beta 1 
amd64 HVM domU
# Please refer to "man xl.cfg" for further explanations.
# See also docs/misc/xl-network-configuration.markdown and
# docs/misc/xl-disk-configuration.txt
# Written by Teo En Ming (Zhang Enming)
# Email #1: teo.en.ming@gmail.com
# Email #2: teo-en-ming@teo-en-ming.com
# Mobile Phone: +65-8369-2618
# Country: Singapore
# Date: 20 Mar 2012 Tue
name="CentOS"
builder="hvm"
vcpus=2
memory=1024
on_poweroff="destroy"
on_reboot="restart"
on_crash="destroy"
# Format compatible with Xen 4.2-unstable changeset 25070 only.
disk=[ 'format=raw, vdev=hda, access=rw, 
target=/etc/xen/images/centos63.img', 'format=raw, vdev=hdc, access=ro, 
devtype=cdrom, target=/home/teo-en-ming/CentOS-6.3-x86_64-bin-DVD1.iso' ]
# Format compatible with Xen 4.1.3-rc1-pre only.
#disk=[ 
'file:/var/lib/libvirt/images/Ubuntu-12.04-beta1-amd64.img,hda,w', 
'file:/home/teo-en-ming/Downloads/ubuntu-12.04-beta1-dvd-amd64.iso,hdc:cdrom,r' 
]
vif=[ 'bridge=eth0,type=ioemu,model=e1000' ]
#boot=[c|d|n]
#Selects the emulated virtual device to boot from. Options are hard disk 
(c), cd-rom (d) or network/PXE (n).
#Multiple options can be given and will be attempted in the order they 
are given. e.g. to boot from cd-rom
#but fallback to the hard disk you can give dc. The default is cd.
#boot="dc"
boot="c"
acpi=1
#xen_platform_pci=1
#viridian=1
stdvga=0
vnc=1
vnclisten="localhost"
vncdisplay=0
vncunused=1
vncpasswd=""
sdl=0
usb=1
usbdevice="tablet"
gfx_passthru=1
# VGA Passthrough Gigabyte Geforce GTX 560 1 GB GDDR5 PCI Express x16 
VGA card.
pci = [ 
'01:00.0','01:00.1','00:1b.0','00:1a.0','00:1a.1','00:1a.2','00:1a.7','00:1d.0','00:1d.1','00:1d.2','00:1d.7' 
]

-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore




On 10/27/2012 10:59 PM, Teo En Ming (Zhang Enming) wrote:
> Hi,
>
> I have just passed through my NVIDIA Geforce GTX 560 to CentOS 6.3 
> x86-64 HVM domU. I am wondering whether the Xen VGA Passthrough is 
> successful.
>
> The following information is obtained from inside CentOS 6.3 x86-64 
> HVM domU:
>
> 00:05.0 VGA compatible controller: NVIDIA Corporation GF114 [GeForce 
> GTX 560] (rev a1) (prog-if 00 [VGA controller])
>     Subsystem: Giga-byte Technology Device 3527
>     Physical Slot: 5
>     Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
> ParErr- Stepping- SERR- FastB2B- DisINTx-
>     Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- 
> SERR-      Latency: 64
>     Interrupt: pin A routed to IRQ 36
>     Region 0: Memory at dc000000 (32-bit, non-prefetchable) [size=32M]
>     Region 1: Memory at d0000000 (64-bit, prefetchable) [size=128M]
>     Region 3: Memory at d8000000 (64-bit, prefetchable) [size=64M]
>     Region 5: I/O ports at e000 [size=128]
>     [virtual] Expansion ROM at f1080000 [disabled] [size=512K]
>     Capabilities: [60] Power Management version 3
>         Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>         Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
>     Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
>         Address: 0000000000000000  Data: 0000
>     Capabilities: [78] Express (v1) Endpoint, MSI 00
>         DevCap:    MaxPayload 128 bytes, PhantFunc 0, Latency L0s 
> <4us, L1 <64us
>             ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
>         DevCtl:    Report errors: Correctable- Non-Fatal- Fatal- 
> Unsupported-
>             RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
>             MaxPayload 128 bytes, MaxReadReq 512 bytes
>         DevSta:    CorrErr- UncorrErr+ FatalErr- UnsuppReq+ AuxPwr- 
> TransPend-
>         LnkCap:    Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, 
> Latency L0 <256ns, L1 <4us
>             ClockPM+ Surprise- LLActRep- BwNot-
>         LnkCtl:    ASPM Disabled; RCB 64 bytes Disabled- Retrain- 
> CommClk-
>             ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>         LnkSta:    Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ 
> DLActive- BWMgmt- ABWMgmt-
>     Capabilities: [b4] Vendor Specific Information 
>     Kernel driver in use: nouveau
>     Kernel modules: nvidia, nouveau, nvidiafb
>
>
>
> [root@centos63 ~]# lsmod | grep nouveau
> nouveau               791165  2
> ttm                    82562  1 nouveau
> drm_kms_helper         34122  1 nouveau
> drm                   250067  4 nouveau,ttm,drm_kms_helper
> i2c_core               31276  14 
> tuner_simple,tda9887,tda8290,wm8775,tuner,cx25840,pvrusb2,v4l2_common,videodev,tveeprom,i2c_piix4,nouveau,drm_kms_helper,drm
> mxm_wmi                 1925  1 nouveau
> video                  21032  1 nouveau
> wmi                     6287  2 nouveau,mxm_wmi
>
>
>
>
> Notice that the nouveau VGA driver is loaded and is in use. Is Xen VGA 
> Passthrough 100% successful? I have successfully installed the NVIDIA 
> driver but I couldn't get it to load, so I reverted back to the 
> nouveau driver.
>
> I have such tough time getting Xen VGA Passthrough to work 
> successfully on Windows HVM domU that I am giving up on Xen VGA 
> Passthrough to Windows HVM domU!!! Windows 7 and Windows 8 HVM domU 
> device manager always report error code 43 with a yellow triangle. 
> Windows XP HVM domU device manager always report error code 10 with a 
> yellow circle.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 27 15:41:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 15:41:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TS8VY-000897-ON; Sat, 27 Oct 2012 15:41:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TS8VW-00088X-Q0; Sat, 27 Oct 2012 15:41:07 +0000
Received: from [193.109.254.147:13828] by server-2.bemta-14.messagelabs.com id
	BD/CE-19917-1900C805; Sat, 27 Oct 2012 15:41:05 +0000
X-Env-Sender: singapore.mr.teo.en.ming@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1351352460!8630801!1
X-Originating-IP: [209.85.220.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29406 invoked from network); 27 Oct 2012 15:41:03 -0000
Received: from mail-pa0-f45.google.com (HELO mail-pa0-f45.google.com)
	(209.85.220.45)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Oct 2012 15:41:03 -0000
Received: by mail-pa0-f45.google.com with SMTP id fb10so2622602pad.32
	for ; Sat, 27 Oct 2012 08:41:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type;
	bh=FxtR+avgpTCrCct8TMZO9VRgh2PUYJHLWbTvGLY+9yw=;
	b=rsh/zP8Y5Fh0Wew7DxCKjh+u0/c7CGnUhhhpTKHZ8NPVJJTm3Rb4K33T9IZm3J1Faz
	lWlNiPfwZnhwpApYR/5lIKH47QudhpkpFFZeyzlbQfH1ONk621cI9qXnTsxoUhrrq50F
	XAuHz2lbq7GYvTS9yChjaGxFgtI01pIFlDgl9RmVbnh0qbytJw8W7y+suB65XLbmOQ8J
	eqAEKWwyoXgUzhbq9DhwP2ThxXlOfj6WAp5CNiOpWtiLMLa4reMCjwCUwJ4aEL4gkiiN
	CGLaCebgTVlDXmxn5qHlMpVYNC5WWfzN6hkvY5o5QPzvKoxj6RuC/c7QE9pkQAH3B+d5
	T8jg==
Received: by 10.68.227.162 with SMTP id sb2mr80408223pbc.4.1351352460239;
	Sat, 27 Oct 2012 08:41:00 -0700 (PDT)
Received: from [192.168.1.17] (cm152.gamma205.maxonline.com.sg.
	[202.156.205.152])
	by mx.google.com with ESMTPS id az8sm2844892pab.24.2012.10.27.08.40.58
	(version=SSLv3 cipher=OTHER); Sat, 27 Oct 2012 08:40:59 -0700 (PDT)
Message-ID: <508C0088.20006@gmail.com>
Date: Sat, 27 Oct 2012 23:40:56 +0800
From: "Teo En Ming (Zhang Enming)" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: "Teo En Ming (Zhang Enming)" 
References: <508BF6EF.2050908@gmail.com> <508BFF4F.7090402@gmail.com>
In-Reply-To: <508BFF4F.7090402@gmail.com>
Content-Type: multipart/mixed; boundary="------------010509070501050706070102"
Cc: "xen-users@lists.xen.org" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Is Xen VGA Passthrough to CentOS 6.3 x86-64 HVM
	domU successful?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--------------010509070501050706070102
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Attached CentOS 6.3 x86-64 HVM domU configuration file.

-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore



On 10/27/2012 11:35 PM, Teo En Ming (Zhang Enming) wrote:
> My CentOS 6.3 x86-64 HVM domU configuration:
>
> # This configuration file will only work with Xen 4.1.3-rc1-pre and NOT
> # Xen 4.2-unstable due to the disk parameter.
> #
> # XL domain configuration file for Ubuntu 12.04 Precise Pangolin Beta 
> 1 amd64 HVM domU
> # Please refer to "man xl.cfg" for further explanations.
> # See also docs/misc/xl-network-configuration.markdown and
> # docs/misc/xl-disk-configuration.txt
> # Written by Teo En Ming (Zhang Enming)
> # Email #1: teo.en.ming@gmail.com
> # Email #2: teo-en-ming@teo-en-ming.com
> # Mobile Phone: +65-8369-2618
> # Country: Singapore
> # Date: 20 Mar 2012 Tue
> name="CentOS"
> builder="hvm"
> vcpus=2
> memory=1024
> on_poweroff="destroy"
> on_reboot="restart"
> on_crash="destroy"
> # Format compatible with Xen 4.2-unstable changeset 25070 only.
> disk=[ 'format=raw, vdev=hda, access=rw, 
> target=/etc/xen/images/centos63.img', 'format=raw, vdev=hdc, 
> access=ro, devtype=cdrom, 
> target=/home/teo-en-ming/CentOS-6.3-x86_64-bin-DVD1.iso' ]
> # Format compatible with Xen 4.1.3-rc1-pre only.
> #disk=[ 
> 'file:/var/lib/libvirt/images/Ubuntu-12.04-beta1-amd64.img,hda,w', 
> 'file:/home/teo-en-ming/Downloads/ubuntu-12.04-beta1-dvd-amd64.iso,hdc:cdrom,r' 
> ]
> vif=[ 'bridge=eth0,type=ioemu,model=e1000' ]
> #boot=[c|d|n]
> #Selects the emulated virtual device to boot from. Options are hard 
> disk (c), cd-rom (d) or network/PXE (n).
> #Multiple options can be given and will be attempted in the order they 
> are given. e.g. to boot from cd-rom
> #but fallback to the hard disk you can give dc. The default is cd.
> #boot="dc"
> boot="c"
> acpi=1
> #xen_platform_pci=1
> #viridian=1
> stdvga=0
> vnc=1
> vnclisten="localhost"
> vncdisplay=0
> vncunused=1
> vncpasswd=""
> sdl=0
> usb=1
> usbdevice="tablet"
> gfx_passthru=1
> # VGA Passthrough Gigabyte Geforce GTX 560 1 GB GDDR5 PCI Express x16 
> VGA card.
> pci = [ 
> '01:00.0','01:00.1','00:1b.0','00:1a.0','00:1a.1','00:1a.2','00:1a.7','00:1d.0','00:1d.1','00:1d.2','00:1d.7' 
> ]
>



--------------010509070501050706070102
Content-Type: text/plain; charset=UTF-8;
 name="centos"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="centos"

# This configuration file will only work with Xen 4.1.3-rc1-pre and NOT
# Xen 4.2-unstable due to the disk parameter.
#
# XL domain configuration file for Ubuntu 12.04 Precise Pangolin Beta 1 amd64 HVM domU
# Please refer to "man xl.cfg" for further explanations.
# See also docs/misc/xl-network-configuration.markdown and
# docs/misc/xl-disk-configuration.txt
# Written by Teo En Ming (Zhang Enming)
# Email #1: teo.en.ming@gmail.com
# Email #2: teo-en-ming@teo-en-ming.com
# Mobile Phone: +65-8369-2618
# Country: Singapore
# Date: 20 Mar 2012 Tue
name="CentOS"
builder="hvm"
vcpus=2
memory=1024
on_poweroff="destroy"
on_reboot="restart"
on_crash="destroy"
# Format compatible with Xen 4.2-unstable changeset 25070 only.
disk=[ 'format=raw, vdev=hda, access=rw, target=/etc/xen/images/centos63.img', 'format=raw, vdev=hdc, access=ro, devtype=cdrom, target=/home/teo-en-ming/CentOS-6.3-x86_64-bin-DVD1.iso' ]
# Format compatible with Xen 4.1.3-rc1-pre only.
#disk=[ 'file:/var/lib/libvirt/images/Ubuntu-12.04-beta1-amd64.img,hda,w', 'file:/home/teo-en-ming/Downloads/ubuntu-12.04-beta1-dvd-amd64.iso,hdc:cdrom,r' ]
vif=[ 'bridge=eth0,type=ioemu,model=e1000' ]
#boot=[c|d|n]
#Selects the emulated virtual device to boot from. Options are hard disk (c), cd-rom (d) or network/PXE (n).
#Multiple options can be given and will be attempted in the order they are given. e.g. to boot from cd-rom
#but fallback to the hard disk you can give dc. The default is cd.
#boot="dc"
boot="c"
acpi=1
#xen_platform_pci=1
#viridian=1
stdvga=0
vnc=1
vnclisten="localhost"
vncdisplay=0
vncunused=1
vncpasswd=""
sdl=0
usb=1
usbdevice="tablet"
#gfx_passthru=1
# VGA Passthrough Gigabyte Geforce GTX 560 1 GB GDDR5 PCI Express x16 VGA card.
#pci = [ '01:00.0','01:00.1','00:1b.0','00:1a.0','00:1a.1','00:1a.2','00:1a.7','00:1d.0','00:1d.1','00:1d.2','00:1d.7' ]


--------------010509070501050706070102
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------010509070501050706070102--


From xen-devel-bounces@lists.xen.org Sat Oct 27 15:41:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 15:41:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TS8VY-000897-ON; Sat, 27 Oct 2012 15:41:08 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TS8VW-00088X-Q0; Sat, 27 Oct 2012 15:41:07 +0000
Received: from [193.109.254.147:13828] by server-2.bemta-14.messagelabs.com id
	BD/CE-19917-1900C805; Sat, 27 Oct 2012 15:41:05 +0000
X-Env-Sender: singapore.mr.teo.en.ming@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1351352460!8630801!1
X-Originating-IP: [209.85.220.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29406 invoked from network); 27 Oct 2012 15:41:03 -0000
Received: from mail-pa0-f45.google.com (HELO mail-pa0-f45.google.com)
	(209.85.220.45)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Oct 2012 15:41:03 -0000
Received: by mail-pa0-f45.google.com with SMTP id fb10so2622602pad.32
	for ; Sat, 27 Oct 2012 08:41:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type;
	bh=FxtR+avgpTCrCct8TMZO9VRgh2PUYJHLWbTvGLY+9yw=;
	b=rsh/zP8Y5Fh0Wew7DxCKjh+u0/c7CGnUhhhpTKHZ8NPVJJTm3Rb4K33T9IZm3J1Faz
	lWlNiPfwZnhwpApYR/5lIKH47QudhpkpFFZeyzlbQfH1ONk621cI9qXnTsxoUhrrq50F
	XAuHz2lbq7GYvTS9yChjaGxFgtI01pIFlDgl9RmVbnh0qbytJw8W7y+suB65XLbmOQ8J
	eqAEKWwyoXgUzhbq9DhwP2ThxXlOfj6WAp5CNiOpWtiLMLa4reMCjwCUwJ4aEL4gkiiN
	CGLaCebgTVlDXmxn5qHlMpVYNC5WWfzN6hkvY5o5QPzvKoxj6RuC/c7QE9pkQAH3B+d5
	T8jg==
Received: by 10.68.227.162 with SMTP id sb2mr80408223pbc.4.1351352460239;
	Sat, 27 Oct 2012 08:41:00 -0700 (PDT)
Received: from [192.168.1.17] (cm152.gamma205.maxonline.com.sg.
	[202.156.205.152])
	by mx.google.com with ESMTPS id az8sm2844892pab.24.2012.10.27.08.40.58
	(version=SSLv3 cipher=OTHER); Sat, 27 Oct 2012 08:40:59 -0700 (PDT)
Message-ID: <508C0088.20006@gmail.com>
Date: Sat, 27 Oct 2012 23:40:56 +0800
From: "Teo En Ming (Zhang Enming)" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: "Teo En Ming (Zhang Enming)" 
References: <508BF6EF.2050908@gmail.com> <508BFF4F.7090402@gmail.com>
In-Reply-To: <508BFF4F.7090402@gmail.com>
Content-Type: multipart/mixed; boundary="------------010509070501050706070102"
Cc: "xen-users@lists.xen.org" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Is Xen VGA Passthrough to CentOS 6.3 x86-64 HVM
	domU successful?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--------------010509070501050706070102
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Attached CentOS 6.3 x86-64 HVM domU configuration file.

-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore



On 10/27/2012 11:35 PM, Teo En Ming (Zhang Enming) wrote:
> My CentOS 6.3 x86-64 HVM domU configuration:
>
> # This configuration file will only work with Xen 4.1.3-rc1-pre and NOT
> # Xen 4.2-unstable due to the disk parameter.
> #
> # XL domain configuration file for Ubuntu 12.04 Precise Pangolin Beta 
> 1 amd64 HVM domU
> # Please refer to "man xl.cfg" for further explanations.
> # See also docs/misc/xl-network-configuration.markdown and
> # docs/misc/xl-disk-configuration.txt
> # Written by Teo En Ming (Zhang Enming)
> # Email #1: teo.en.ming@gmail.com
> # Email #2: teo-en-ming@teo-en-ming.com
> # Mobile Phone: +65-8369-2618
> # Country: Singapore
> # Date: 20 Mar 2012 Tue
> name="CentOS"
> builder="hvm"
> vcpus=2
> memory=1024
> on_poweroff="destroy"
> on_reboot="restart"
> on_crash="destroy"
> # Format compatible with Xen 4.2-unstable changeset 25070 only.
> disk=[ 'format=raw, vdev=hda, access=rw, 
> target=/etc/xen/images/centos63.img', 'format=raw, vdev=hdc, 
> access=ro, devtype=cdrom, 
> target=/home/teo-en-ming/CentOS-6.3-x86_64-bin-DVD1.iso' ]
> # Format compatible with Xen 4.1.3-rc1-pre only.
> #disk=[ 
> 'file:/var/lib/libvirt/images/Ubuntu-12.04-beta1-amd64.img,hda,w', 
> 'file:/home/teo-en-ming/Downloads/ubuntu-12.04-beta1-dvd-amd64.iso,hdc:cdrom,r' 
> ]
> vif=[ 'bridge=eth0,type=ioemu,model=e1000' ]
> #boot=[c|d|n]
> #Selects the emulated virtual device to boot from. Options are hard 
> disk (c), cd-rom (d) or network/PXE (n).
> #Multiple options can be given and will be attempted in the order they 
> are given. e.g. to boot from cd-rom
> #but fallback to the hard disk you can give dc. The default is cd.
> #boot="dc"
> boot="c"
> acpi=1
> #xen_platform_pci=1
> #viridian=1
> stdvga=0
> vnc=1
> vnclisten="localhost"
> vncdisplay=0
> vncunused=1
> vncpasswd=""
> sdl=0
> usb=1
> usbdevice="tablet"
> gfx_passthru=1
> # VGA Passthrough Gigabyte Geforce GTX 560 1 GB GDDR5 PCI Express x16 
> VGA card.
> pci = [ 
> '01:00.0','01:00.1','00:1b.0','00:1a.0','00:1a.1','00:1a.2','00:1a.7','00:1d.0','00:1d.1','00:1d.2','00:1d.7' 
> ]
>



--------------010509070501050706070102
Content-Type: text/plain; charset=UTF-8;
 name="centos"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="centos"

# This configuration file will only work with Xen 4.1.3-rc1-pre and NOT
# Xen 4.2-unstable due to the disk parameter.
#
# XL domain configuration file for Ubuntu 12.04 Precise Pangolin Beta 1 amd64 HVM domU
# Please refer to "man xl.cfg" for further explanations.
# See also docs/misc/xl-network-configuration.markdown and
# docs/misc/xl-disk-configuration.txt
# Written by Teo En Ming (Zhang Enming)
# Email #1: teo.en.ming@gmail.com
# Email #2: teo-en-ming@teo-en-ming.com
# Mobile Phone: +65-8369-2618
# Country: Singapore
# Date: 20 Mar 2012 Tue
name="CentOS"
builder="hvm"
vcpus=2
memory=1024
on_poweroff="destroy"
on_reboot="restart"
on_crash="destroy"
# Format compatible with Xen 4.2-unstable changeset 25070 only.
disk=[ 'format=raw, vdev=hda, access=rw, target=/etc/xen/images/centos63.img', 'format=raw, vdev=hdc, access=ro, devtype=cdrom, target=/home/teo-en-ming/CentOS-6.3-x86_64-bin-DVD1.iso' ]
# Format compatible with Xen 4.1.3-rc1-pre only.
#disk=[ 'file:/var/lib/libvirt/images/Ubuntu-12.04-beta1-amd64.img,hda,w', 'file:/home/teo-en-ming/Downloads/ubuntu-12.04-beta1-dvd-amd64.iso,hdc:cdrom,r' ]
vif=[ 'bridge=eth0,type=ioemu,model=e1000' ]
#boot=[c|d|n]
#Selects the emulated virtual device to boot from. Options are hard disk (c), cd-rom (d) or network/PXE (n).
#Multiple options can be given and will be attempted in the order they are given. e.g. to boot from cd-rom
#but fallback to the hard disk you can give dc. The default is cd.
#boot="dc"
boot="c"
acpi=1
#xen_platform_pci=1
#viridian=1
stdvga=0
vnc=1
vnclisten="localhost"
vncdisplay=0
vncunused=1
vncpasswd=""
sdl=0
usb=1
usbdevice="tablet"
#gfx_passthru=1
# VGA Passthrough Gigabyte Geforce GTX 560 1 GB GDDR5 PCI Express x16 VGA card.
#pci = [ '01:00.0','01:00.1','00:1b.0','00:1a.0','00:1a.1','00:1a.2','00:1a.7','00:1d.0','00:1d.1','00:1d.2','00:1d.7' ]


--------------010509070501050706070102
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------010509070501050706070102--


From xen-devel-bounces@lists.xen.org Sat Oct 27 17:12:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 17:12:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TS9vF-0001xL-2U; Sat, 27 Oct 2012 17:11:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TS9vD-0001xG-Di
	for xen-devel@lists.xensource.com; Sat, 27 Oct 2012 17:11:43 +0000
Received: from [85.158.143.99:37781] by server-3.bemta-4.messagelabs.com id
	27/D5-24279-EC51C805; Sat, 27 Oct 2012 17:11:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1351357901!27284727!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY0NTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19364 invoked from network); 27 Oct 2012 17:11:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Oct 2012 17:11:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,662,1344211200"; d="scan'208";a="15441645"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Oct 2012 17:11:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sat, 27 Oct 2012 18:11:40 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TS9vA-0000qj-VA;
	Sat, 27 Oct 2012 17:11:40 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TS9vA-0007w5-S5;
	Sat, 27 Oct 2012 18:11:40 +0100
To: 
Message-ID: 
From: xen.org 
Date: Sat, 27 Oct 2012 18:11:40 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 14097: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14097 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14097/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pv            3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-pv             3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-xl-multivcpu  3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-xl            3 host-install(3)         broken REGR. vs. 14076
 test-amd64-amd64-pv           3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-rhel6hvm-amd  3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)       broken REGR. vs. 14076
 test-i386-i386-xl             3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-pair         4 host-install/dst_host(4) broken REGR. vs. 14076
 test-amd64-i386-pair         3 host-install/src_host(3) broken REGR. vs. 14076
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 14076
 test-amd64-amd64-xl-qemuu-win7-amd64  3 host-install(3) broken REGR. vs. 14076
 test-amd64-i386-xend-winxpsp3  3 host-install(3)        broken REGR. vs. 14076
 test-amd64-i386-xl-win7-amd64  3 host-install(3)        broken REGR. vs. 14076
 test-amd64-i386-xl-winxpsp3-vcpus1  3 host-install(3)   broken REGR. vs. 14076
 test-amd64-i386-win           3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 14076
 test-amd64-amd64-xl-win       3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-xl-winxpsp3    7 windows-install  fail in 14090 REGR. vs. 14076

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3)     broken pass in 14090
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3)   broken pass in 14094
 test-amd64-amd64-xl           3 host-install(3)           broken pass in 14085
 test-i386-i386-pair           4 host-install/dst_host(4)  broken pass in 14090
 test-i386-i386-pair           3 host-install/src_host(3)  broken pass in 14090
 test-amd64-amd64-pair         3 host-install/src_host(3)  broken pass in 14090
 test-amd64-amd64-pair         4 host-install/dst_host(4)  broken pass in 14090
 test-i386-i386-xl-winxpsp3    3 host-install(3)           broken pass in 14094
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)  broken in 14090 pass in 14097
 test-i386-i386-win            7 windows-install    fail in 14085 pass in 14097

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)      broken REGR. vs. 14076
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10    fail REGR. vs. 14076
 test-amd64-amd64-xl-sedf      3 host-install(3)         broken REGR. vs. 14076

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  25eda7e7b4e6
baseline version:
 xen                  40ccbee890e1

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla 
  Bastian Blank 
  Chuang Cao 
  George Dunlap 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jason McCarver 
  Joe Jin 
  Keir Fraser 
  Matt Wilson 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Sander Eikelenboom 
  Stefano Stabellini 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          broken  
 test-amd64-i386-xl                                           broken  
 test-i386-i386-xl                                            broken  
 test-amd64-i386-rhel6hvm-amd                                 broken  
 test-amd64-i386-qemuu-rhel6hvm-amd                           broken  
 test-amd64-amd64-xl-qemuu-win7-amd64                         broken  
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         broken  
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        broken  
 test-amd64-i386-pair                                         broken  
 test-i386-i386-pair                                          broken  
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          broken  
 test-amd64-i386-pv                                           broken  
 test-i386-i386-pv                                            broken  
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           broken  
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          broken  
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      broken  
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                broken  
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   broken  


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 612 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 27 17:12:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 17:12:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TS9vF-0001xL-2U; Sat, 27 Oct 2012 17:11:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TS9vD-0001xG-Di
	for xen-devel@lists.xensource.com; Sat, 27 Oct 2012 17:11:43 +0000
Received: from [85.158.143.99:37781] by server-3.bemta-4.messagelabs.com id
	27/D5-24279-EC51C805; Sat, 27 Oct 2012 17:11:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1351357901!27284727!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY0NTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19364 invoked from network); 27 Oct 2012 17:11:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Oct 2012 17:11:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,662,1344211200"; d="scan'208";a="15441645"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Oct 2012 17:11:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sat, 27 Oct 2012 18:11:40 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TS9vA-0000qj-VA;
	Sat, 27 Oct 2012 17:11:40 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TS9vA-0007w5-S5;
	Sat, 27 Oct 2012 18:11:40 +0100
To: 
Message-ID: 
From: xen.org 
Date: Sat, 27 Oct 2012 18:11:40 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 14097: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14097 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14097/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pv            3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-pv             3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-xl-multivcpu  3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-xl            3 host-install(3)         broken REGR. vs. 14076
 test-amd64-amd64-pv           3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-rhel6hvm-amd  3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)       broken REGR. vs. 14076
 test-i386-i386-xl             3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-pair         4 host-install/dst_host(4) broken REGR. vs. 14076
 test-amd64-i386-pair         3 host-install/src_host(3) broken REGR. vs. 14076
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 14076
 test-amd64-amd64-xl-qemuu-win7-amd64  3 host-install(3) broken REGR. vs. 14076
 test-amd64-i386-xend-winxpsp3  3 host-install(3)        broken REGR. vs. 14076
 test-amd64-i386-xl-win7-amd64  3 host-install(3)        broken REGR. vs. 14076
 test-amd64-i386-xl-winxpsp3-vcpus1  3 host-install(3)   broken REGR. vs. 14076
 test-amd64-i386-win           3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 14076
 test-amd64-amd64-xl-win       3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-xl-winxpsp3    7 windows-install  fail in 14090 REGR. vs. 14076

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3)     broken pass in 14090
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3)   broken pass in 14094
 test-amd64-amd64-xl           3 host-install(3)           broken pass in 14085
 test-i386-i386-pair           4 host-install/dst_host(4)  broken pass in 14090
 test-i386-i386-pair           3 host-install/src_host(3)  broken pass in 14090
 test-amd64-amd64-pair         3 host-install/src_host(3)  broken pass in 14090
 test-amd64-amd64-pair         4 host-install/dst_host(4)  broken pass in 14090
 test-i386-i386-xl-winxpsp3    3 host-install(3)           broken pass in 14094
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)  broken in 14090 pass in 14097
 test-i386-i386-win            7 windows-install    fail in 14085 pass in 14097

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)      broken REGR. vs. 14076
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10    fail REGR. vs. 14076
 test-amd64-amd64-xl-sedf      3 host-install(3)         broken REGR. vs. 14076

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  25eda7e7b4e6
baseline version:
 xen                  40ccbee890e1

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla 
  Bastian Blank 
  Chuang Cao 
  George Dunlap 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jason McCarver 
  Joe Jin 
  Keir Fraser 
  Matt Wilson 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Sander Eikelenboom 
  Stefano Stabellini 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          broken  
 test-amd64-i386-xl                                           broken  
 test-i386-i386-xl                                            broken  
 test-amd64-i386-rhel6hvm-amd                                 broken  
 test-amd64-i386-qemuu-rhel6hvm-amd                           broken  
 test-amd64-amd64-xl-qemuu-win7-amd64                         broken  
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         broken  
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        broken  
 test-amd64-i386-pair                                         broken  
 test-i386-i386-pair                                          broken  
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          broken  
 test-amd64-i386-pv                                           broken  
 test-i386-i386-pv                                            broken  
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           broken  
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          broken  
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      broken  
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                broken  
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   broken  


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 612 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 27 17:59:53 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 17:59:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSAfF-0002hs-3g; Sat, 27 Oct 2012 17:59:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSAfD-0002hn-7g
	for xen-devel@lists.xensource.com; Sat, 27 Oct 2012 17:59:15 +0000
Received: from [193.109.254.147:54042] by server-3.bemta-14.messagelabs.com id
	07/EB-04486-2F02C805; Sat, 27 Oct 2012 17:59:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1351360753!8519097!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY0NTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13232 invoked from network); 27 Oct 2012 17:59:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Oct 2012 17:59:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,662,1344211200"; d="scan'208";a="15441773"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Oct 2012 17:59:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sat, 27 Oct 2012 18:59:12 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TSAfA-00016J-Kd;
	Sat, 27 Oct 2012 17:59:12 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TSAfA-0000xc-Eg;
	Sat, 27 Oct 2012 18:59:12 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Sat, 27 Oct 2012 18:59:12 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 14103: trouble:
	blocked/broken/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14103 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14103/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386                    2 host-install(2)         broken REGR. vs. 13919
 build-amd64                   2 host-install(2)         broken REGR. vs. 13919
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 13919
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13919

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 xen                  69d1cc78a5bd
baseline version:
 xen                  a15596a619ed

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   23385:69d1cc78a5bd
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:10:04 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    [ Includes 25589:60f09d1ab1fe for CVE-2012-2625 ]
    
    
changeset:   23384:a15596a619ed
user:        Daniel De Graaf 
date:        Thu Oct 04 10:44:43 2012 +0200
    
    x86: check remote MMIO remap permissions
    
    When a domain is mapping pages from a different pg_owner domain, the
    iomem_access checks are currently only applied to the pg_owner domain,
    potentially allowing a domain with a more restrictive iomem_access
    policy to have the pages mapped into its page tables. To catch this,
    also check the owner of the page tables. The current domain does not
    need to be checked because the ability to manipulate a domain's page
    tables implies full access to the target domain, so checking that
    domain's permission is sufficient.
    
    Signed-off-by: Daniel De Graaf 
    Acked-by: Jan Beulich 
    xen-unstable changeset: 25952:8278d7d8fa48
    xen-unstable date: Wed Sep 26 09:56:07 UTC 2012
    
    
========================================
commit d7d453f51459b591faa96d1c123b5bfff7c5b6b6
Author: Ian Jackson 
Date:   Thu Sep 6 17:05:30 2012 +0100

    Disable qemu monitor by default.  The qemu monitor is an overly
    powerful feature which must be protected from untrusted (guest)
    administrators.
    
    Neither xl nor xend expect qemu to produce this monitor unless it is
    explicitly requested.
    
    This is a security problem, XSA-19.  Previously it was CVE-2007-0998
    in Red Hat but we haven't dealt with it in upstream.  We hope to have
    a new CVE for it here but we don't have one yet.
    
    Signed-off-by: Ian Jackson 
    (cherry picked from commit bacc0d302445c75f18f4c826750fb5853b60e7ca)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 27 17:59:53 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 17:59:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSAfF-0002hs-3g; Sat, 27 Oct 2012 17:59:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSAfD-0002hn-7g
	for xen-devel@lists.xensource.com; Sat, 27 Oct 2012 17:59:15 +0000
Received: from [193.109.254.147:54042] by server-3.bemta-14.messagelabs.com id
	07/EB-04486-2F02C805; Sat, 27 Oct 2012 17:59:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1351360753!8519097!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY0NTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13232 invoked from network); 27 Oct 2012 17:59:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Oct 2012 17:59:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,662,1344211200"; d="scan'208";a="15441773"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Oct 2012 17:59:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sat, 27 Oct 2012 18:59:12 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TSAfA-00016J-Kd;
	Sat, 27 Oct 2012 17:59:12 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TSAfA-0000xc-Eg;
	Sat, 27 Oct 2012 18:59:12 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Sat, 27 Oct 2012 18:59:12 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 14103: trouble:
	blocked/broken/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14103 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14103/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386                    2 host-install(2)         broken REGR. vs. 13919
 build-amd64                   2 host-install(2)         broken REGR. vs. 13919
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 13919
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13919

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 xen                  69d1cc78a5bd
baseline version:
 xen                  a15596a619ed

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   23385:69d1cc78a5bd
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:10:04 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    [ Includes 25589:60f09d1ab1fe for CVE-2012-2625 ]
    
    
changeset:   23384:a15596a619ed
user:        Daniel De Graaf 
date:        Thu Oct 04 10:44:43 2012 +0200
    
    x86: check remote MMIO remap permissions
    
    When a domain is mapping pages from a different pg_owner domain, the
    iomem_access checks are currently only applied to the pg_owner domain,
    potentially allowing a domain with a more restrictive iomem_access
    policy to have the pages mapped into its page tables. To catch this,
    also check the owner of the page tables. The current domain does not
    need to be checked because the ability to manipulate a domain's page
    tables implies full access to the target domain, so checking that
    domain's permission is sufficient.
    
    Signed-off-by: Daniel De Graaf 
    Acked-by: Jan Beulich 
    xen-unstable changeset: 25952:8278d7d8fa48
    xen-unstable date: Wed Sep 26 09:56:07 UTC 2012
    
    
========================================
commit d7d453f51459b591faa96d1c123b5bfff7c5b6b6
Author: Ian Jackson 
Date:   Thu Sep 6 17:05:30 2012 +0100

    Disable qemu monitor by default.  The qemu monitor is an overly
    powerful feature which must be protected from untrusted (guest)
    administrators.
    
    Neither xl nor xend expect qemu to produce this monitor unless it is
    explicitly requested.
    
    This is a security problem, XSA-19.  Previously it was CVE-2007-0998
    in Red Hat but we haven't dealt with it in upstream.  We hope to have
    a new CVE for it here but we don't have one yet.
    
    Signed-off-by: Ian Jackson 
    (cherry picked from commit bacc0d302445c75f18f4c826750fb5853b60e7ca)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 27 19:15:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 19:15:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSBqw-00044V-15; Sat, 27 Oct 2012 19:15:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSBqu-00044Q-Hw
	for xen-devel@lists.xensource.com; Sat, 27 Oct 2012 19:15:24 +0000
Received: from [85.158.143.99:21055] by server-3.bemta-4.messagelabs.com id
	51/63-24279-BC23C805; Sat, 27 Oct 2012 19:15:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1351365322!22306070!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY0NTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25403 invoked from network); 27 Oct 2012 19:15:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Oct 2012 19:15:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,662,1344211200"; d="scan'208";a="15443924"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Oct 2012 19:15:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sat, 27 Oct 2012 20:15:21 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TSBqr-0001Ut-Rn;
	Sat, 27 Oct 2012 19:15:21 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TSBqr-0008DK-RD;
	Sat, 27 Oct 2012 20:15:21 +0100
To: 
Message-ID: 
From: xen.org 
Date: Sat, 27 Oct 2012 20:15:21 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 14107: trouble: blocked/broken
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14107 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14107/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386                    2 host-install(2)         broken REGR. vs. 13919
 build-amd64                   2 host-install(2)         broken REGR. vs. 13919
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 13919
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13919
 build-i386-pvops              2 host-install(2)         broken REGR. vs. 13919
 build-i386-oldkern            2 host-install(2)         broken REGR. vs. 13919

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 xen                  69d1cc78a5bd
baseline version:
 xen                  a15596a619ed

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           broken  
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             broken  
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   23385:69d1cc78a5bd
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:10:04 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    [ Includes 25589:60f09d1ab1fe for CVE-2012-2625 ]
    
    
changeset:   23384:a15596a619ed
user:        Daniel De Graaf 
date:        Thu Oct 04 10:44:43 2012 +0200
    
    x86: check remote MMIO remap permissions
    
    When a domain is mapping pages from a different pg_owner domain, the
    iomem_access checks are currently only applied to the pg_owner domain,
    potentially allowing a domain with a more restrictive iomem_access
    policy to have the pages mapped into its page tables. To catch this,
    also check the owner of the page tables. The current domain does not
    need to be checked because the ability to manipulate a domain's page
    tables implies full access to the target domain, so checking that
    domain's permission is sufficient.
    
    Signed-off-by: Daniel De Graaf 
    Acked-by: Jan Beulich 
    xen-unstable changeset: 25952:8278d7d8fa48
    xen-unstable date: Wed Sep 26 09:56:07 UTC 2012
    
    
========================================
commit d7d453f51459b591faa96d1c123b5bfff7c5b6b6
Author: Ian Jackson 
Date:   Thu Sep 6 17:05:30 2012 +0100

    Disable qemu monitor by default.  The qemu monitor is an overly
    powerful feature which must be protected from untrusted (guest)
    administrators.
    
    Neither xl nor xend expect qemu to produce this monitor unless it is
    explicitly requested.
    
    This is a security problem, XSA-19.  Previously it was CVE-2007-0998
    in Red Hat but we haven't dealt with it in upstream.  We hope to have
    a new CVE for it here but we don't have one yet.
    
    Signed-off-by: Ian Jackson 
    (cherry picked from commit bacc0d302445c75f18f4c826750fb5853b60e7ca)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 27 19:15:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 19:15:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSBqw-00044V-15; Sat, 27 Oct 2012 19:15:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSBqu-00044Q-Hw
	for xen-devel@lists.xensource.com; Sat, 27 Oct 2012 19:15:24 +0000
Received: from [85.158.143.99:21055] by server-3.bemta-4.messagelabs.com id
	51/63-24279-BC23C805; Sat, 27 Oct 2012 19:15:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1351365322!22306070!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY0NTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25403 invoked from network); 27 Oct 2012 19:15:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Oct 2012 19:15:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,662,1344211200"; d="scan'208";a="15443924"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Oct 2012 19:15:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sat, 27 Oct 2012 20:15:21 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TSBqr-0001Ut-Rn;
	Sat, 27 Oct 2012 19:15:21 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TSBqr-0008DK-RD;
	Sat, 27 Oct 2012 20:15:21 +0100
To: 
Message-ID: 
From: xen.org 
Date: Sat, 27 Oct 2012 20:15:21 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 14107: trouble: blocked/broken
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14107 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14107/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386                    2 host-install(2)         broken REGR. vs. 13919
 build-amd64                   2 host-install(2)         broken REGR. vs. 13919
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 13919
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13919
 build-i386-pvops              2 host-install(2)         broken REGR. vs. 13919
 build-i386-oldkern            2 host-install(2)         broken REGR. vs. 13919

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 xen                  69d1cc78a5bd
baseline version:
 xen                  a15596a619ed

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           broken  
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             broken  
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   23385:69d1cc78a5bd
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:10:04 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    [ Includes 25589:60f09d1ab1fe for CVE-2012-2625 ]
    
    
changeset:   23384:a15596a619ed
user:        Daniel De Graaf 
date:        Thu Oct 04 10:44:43 2012 +0200
    
    x86: check remote MMIO remap permissions
    
    When a domain is mapping pages from a different pg_owner domain, the
    iomem_access checks are currently only applied to the pg_owner domain,
    potentially allowing a domain with a more restrictive iomem_access
    policy to have the pages mapped into its page tables. To catch this,
    also check the owner of the page tables. The current domain does not
    need to be checked because the ability to manipulate a domain's page
    tables implies full access to the target domain, so checking that
    domain's permission is sufficient.
    
    Signed-off-by: Daniel De Graaf 
    Acked-by: Jan Beulich 
    xen-unstable changeset: 25952:8278d7d8fa48
    xen-unstable date: Wed Sep 26 09:56:07 UTC 2012
    
    
========================================
commit d7d453f51459b591faa96d1c123b5bfff7c5b6b6
Author: Ian Jackson 
Date:   Thu Sep 6 17:05:30 2012 +0100

    Disable qemu monitor by default.  The qemu monitor is an overly
    powerful feature which must be protected from untrusted (guest)
    administrators.
    
    Neither xl nor xend expect qemu to produce this monitor unless it is
    explicitly requested.
    
    This is a security problem, XSA-19.  Previously it was CVE-2007-0998
    in Red Hat but we haven't dealt with it in upstream.  We hope to have
    a new CVE for it here but we don't have one yet.
    
    Signed-off-by: Ian Jackson 
    (cherry picked from commit bacc0d302445c75f18f4c826750fb5853b60e7ca)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 27 20:45:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 20:45:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSDFK-0005JB-33; Sat, 27 Oct 2012 20:44:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSDFI-0005J6-2a
	for xen-devel@lists.xensource.com; Sat, 27 Oct 2012 20:44:40 +0000
Received: from [85.158.143.35:59227] by server-3.bemta-4.messagelabs.com id
	FF/0A-24279-7B74C805; Sat, 27 Oct 2012 20:44:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1351370678!13469000!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY0NTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5330 invoked from network); 27 Oct 2012 20:44:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Oct 2012 20:44:38 -0000
X-IronPort-AV: E=Sophos;i="4.80,662,1344211200"; d="scan'208";a="15445890"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Oct 2012 20:44:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sat, 27 Oct 2012 21:44:37 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TSDFF-0001xO-D2;
	Sat, 27 Oct 2012 20:44:37 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TSDFF-0003J4-CN;
	Sat, 27 Oct 2012 21:44:37 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Sat, 27 Oct 2012 21:44:37 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14104: trouble: broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14104 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14104/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3)   broken REGR. vs. 14079
 test-amd64-amd64-pv           3 host-install(3)         broken REGR. vs. 14079
 test-amd64-i386-xl            3 host-install(3)         broken REGR. vs. 14079
 test-amd64-amd64-xl           3 host-install(3)         broken REGR. vs. 14079
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 14079
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)       broken REGR. vs. 14079
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3) broken REGR. vs. 14079
 test-amd64-i386-xl-win-vcpus1  3 host-install(3)        broken REGR. vs. 14079
 test-amd64-amd64-win          3 host-install(3)         broken REGR. vs. 14079
 test-amd64-i386-xl-multivcpu  3 host-install(3)         broken REGR. vs. 14079
 test-amd64-i386-win-vcpus1    3 host-install(3)         broken REGR. vs. 14079
 test-amd64-i386-xl-win7-amd64  3 host-install(3)        broken REGR. vs. 14079
 test-amd64-amd64-xl-winxpsp3  3 host-install(3)         broken REGR. vs. 14079
 test-amd64-i386-pair         3 host-install/src_host(3) broken REGR. vs. 14079
 test-amd64-i386-pair         4 host-install/dst_host(4) broken REGR. vs. 14079

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)      broken REGR. vs. 14079
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 14079
 test-amd64-amd64-xl-sedf      3 host-install(3)         broken REGR. vs. 14079
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 14079
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 14079

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  37a8946eeb9d
baseline version:
 xen                  c26e1a79fe77

------------------------------------------------------------
People who touched revisions under test:
  Charles Arnold 
  Christoph Egger 
  Ian Campbell 
  Ian Jackson 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          broken  
 test-amd64-i386-xl                                           broken  
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           broken  
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         broken  
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         broken  
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          broken  
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   broken  
 test-amd64-i386-xl-win-vcpus1                                broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         broken  
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 broken  


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26115:37a8946eeb9d
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:09:29 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    
    
changeset:   26114:6f9e46917eb8
user:        Charles Arnold 
date:        Fri Oct 26 12:05:08 2012 +0100
    
    pygrub: Add option to list grub entries
    
    The argument to "--entry" allows 2 syntaxes, either directly the entry
    number in menu.lst, or the whole string behind the "title" key word.
    This poses the following issue:
    
    From Dom0 there is no way to guess the number and, or the complete
    title string because this string contains the kernel version, which
    will change with a kernel update.
    
    This patch adds [-l|--list-entries] as an argument to pygrub.
    
    Signed-off-by: Charles Arnold 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26113:03af0abd2b72
user:        Ian Campbell 
date:        Fri Oct 26 12:03:12 2012 +0100
    
    xl: Do not leak events when a domain exits.
    
    The goto in both of these places misses the event free which would
    normally clean up.
    
    ==8655== 80 bytes in 1 blocks are definitely lost in loss record 1 of 1
    ==8655==    at 0x4024370: calloc (vg_replace_malloc.c:593)
    ==8655==    by 0x406EAAE: libxl__zalloc (libxl_internal.c:83)
    ==8655==    by 0x4078173: libxl__event_new (libxl_event.c:1167)
    ==8655==    by 0x4056373: domain_death_occurred (libxl.c:958)
    ==8655==    by 0x4058D06: domain_death_xswatch_callback (libxl.c:1038)
    ==8655==    by 0x4078EB5: watchfd_callback (libxl_event.c:458)
    ==8655==    by 0x407839E: afterpoll_internal (libxl_event.c:949)
    ==8655==    by 0x4079142: eventloop_iteration (libxl_event.c:1371)
    ==8655==    by 0x40799BB: libxl_event_wait (libxl_event.c:1396)
    ==8655==    by 0x805CC67: create_domain (xl_cmdimpl.c:1698)
    ==8655==    by 0x805E001: main_create (xl_cmdimpl.c:3986)
    ==8655==    by 0x804D43D: main (xl.c:285)
    
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26112:d07692b5c780
user:        Ian Jackson 
date:        Fri Oct 26 11:39:42 2012 +0100
    
    Revert 26109:6ccfe4d29f95
    
    This changeset was contaminated by changes hanging around in my
    working tree.  Sorry :-(.
    
    Signed-off-by: Ian Jackson 
    
    
changeset:   26111:c26e1a79fe77
user:        Christoph Egger 
date:        Thu Oct 25 17:12:55 2012 +0100
    
    libxl: NetBSD PCI passthrough support
    
    Add PCI passthrough support for HVM guests.
    
    Signed-off-by: Christoph Egger 
    Committed-by: Ian Jackson 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 27 20:45:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 20:45:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSDFK-0005JB-33; Sat, 27 Oct 2012 20:44:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSDFI-0005J6-2a
	for xen-devel@lists.xensource.com; Sat, 27 Oct 2012 20:44:40 +0000
Received: from [85.158.143.35:59227] by server-3.bemta-4.messagelabs.com id
	FF/0A-24279-7B74C805; Sat, 27 Oct 2012 20:44:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1351370678!13469000!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY0NTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5330 invoked from network); 27 Oct 2012 20:44:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Oct 2012 20:44:38 -0000
X-IronPort-AV: E=Sophos;i="4.80,662,1344211200"; d="scan'208";a="15445890"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Oct 2012 20:44:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sat, 27 Oct 2012 21:44:37 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TSDFF-0001xO-D2;
	Sat, 27 Oct 2012 20:44:37 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TSDFF-0003J4-CN;
	Sat, 27 Oct 2012 21:44:37 +0100
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Sat, 27 Oct 2012 21:44:37 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14104: trouble: broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14104 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14104/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3)   broken REGR. vs. 14079
 test-amd64-amd64-pv           3 host-install(3)         broken REGR. vs. 14079
 test-amd64-i386-xl            3 host-install(3)         broken REGR. vs. 14079
 test-amd64-amd64-xl           3 host-install(3)         broken REGR. vs. 14079
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 14079
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)       broken REGR. vs. 14079
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3) broken REGR. vs. 14079
 test-amd64-i386-xl-win-vcpus1  3 host-install(3)        broken REGR. vs. 14079
 test-amd64-amd64-win          3 host-install(3)         broken REGR. vs. 14079
 test-amd64-i386-xl-multivcpu  3 host-install(3)         broken REGR. vs. 14079
 test-amd64-i386-win-vcpus1    3 host-install(3)         broken REGR. vs. 14079
 test-amd64-i386-xl-win7-amd64  3 host-install(3)        broken REGR. vs. 14079
 test-amd64-amd64-xl-winxpsp3  3 host-install(3)         broken REGR. vs. 14079
 test-amd64-i386-pair         3 host-install/src_host(3) broken REGR. vs. 14079
 test-amd64-i386-pair         4 host-install/dst_host(4) broken REGR. vs. 14079

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)      broken REGR. vs. 14079
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 14079
 test-amd64-amd64-xl-sedf      3 host-install(3)         broken REGR. vs. 14079
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 14079
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 14079

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  37a8946eeb9d
baseline version:
 xen                  c26e1a79fe77

------------------------------------------------------------
People who touched revisions under test:
  Charles Arnold 
  Christoph Egger 
  Ian Campbell 
  Ian Jackson 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          broken  
 test-amd64-i386-xl                                           broken  
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           broken  
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         broken  
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         broken  
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          broken  
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   broken  
 test-amd64-i386-xl-win-vcpus1                                broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         broken  
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 broken  


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26115:37a8946eeb9d
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:09:29 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    
    
changeset:   26114:6f9e46917eb8
user:        Charles Arnold 
date:        Fri Oct 26 12:05:08 2012 +0100
    
    pygrub: Add option to list grub entries
    
    The argument to "--entry" allows 2 syntaxes, either directly the entry
    number in menu.lst, or the whole string behind the "title" key word.
    This poses the following issue:
    
    From Dom0 there is no way to guess the number and, or the complete
    title string because this string contains the kernel version, which
    will change with a kernel update.
    
    This patch adds [-l|--list-entries] as an argument to pygrub.
    
    Signed-off-by: Charles Arnold 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26113:03af0abd2b72
user:        Ian Campbell 
date:        Fri Oct 26 12:03:12 2012 +0100
    
    xl: Do not leak events when a domain exits.
    
    The goto in both of these places misses the event free which would
    normally clean up.
    
    ==8655== 80 bytes in 1 blocks are definitely lost in loss record 1 of 1
    ==8655==    at 0x4024370: calloc (vg_replace_malloc.c:593)
    ==8655==    by 0x406EAAE: libxl__zalloc (libxl_internal.c:83)
    ==8655==    by 0x4078173: libxl__event_new (libxl_event.c:1167)
    ==8655==    by 0x4056373: domain_death_occurred (libxl.c:958)
    ==8655==    by 0x4058D06: domain_death_xswatch_callback (libxl.c:1038)
    ==8655==    by 0x4078EB5: watchfd_callback (libxl_event.c:458)
    ==8655==    by 0x407839E: afterpoll_internal (libxl_event.c:949)
    ==8655==    by 0x4079142: eventloop_iteration (libxl_event.c:1371)
    ==8655==    by 0x40799BB: libxl_event_wait (libxl_event.c:1396)
    ==8655==    by 0x805CC67: create_domain (xl_cmdimpl.c:1698)
    ==8655==    by 0x805E001: main_create (xl_cmdimpl.c:3986)
    ==8655==    by 0x804D43D: main (xl.c:285)
    
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26112:d07692b5c780
user:        Ian Jackson 
date:        Fri Oct 26 11:39:42 2012 +0100
    
    Revert 26109:6ccfe4d29f95
    
    This changeset was contaminated by changes hanging around in my
    working tree.  Sorry :-(.
    
    Signed-off-by: Ian Jackson 
    
    
changeset:   26111:c26e1a79fe77
user:        Christoph Egger 
date:        Thu Oct 25 17:12:55 2012 +0100
    
    libxl: NetBSD PCI passthrough support
    
    Add PCI passthrough support for HVM guests.
    
    Signed-off-by: Christoph Egger 
    Committed-by: Ian Jackson 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 27 21:45:00 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 21:45:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSEB6-0006Au-2L; Sat, 27 Oct 2012 21:44:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSEB4-0006Ap-D2
	for xen-devel@lists.xensource.com; Sat, 27 Oct 2012 21:44:22 +0000
Received: from [85.158.143.35:45068] by server-3.bemta-4.messagelabs.com id
	E0/17-24279-5B55C805; Sat, 27 Oct 2012 21:44:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1351374260!11942225!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY0NTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14066 invoked from network); 27 Oct 2012 21:44:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Oct 2012 21:44:20 -0000
X-IronPort-AV: E=Sophos;i="4.80,662,1344211200"; d="scan'208";a="15446030"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Oct 2012 21:44:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sat, 27 Oct 2012 22:44:19 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TSEB1-0002Ga-IO;
	Sat, 27 Oct 2012 21:44:19 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TSEB1-0005BP-Hz;
	Sat, 27 Oct 2012 22:44:19 +0100
To: 
Message-ID: 
From: xen.org 
Date: Sat, 27 Oct 2012 22:44:19 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14108: trouble: blocked/broken/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14108 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14108/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   2 host-install(2)         broken REGR. vs. 14079
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 14079
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 14079

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a

version targeted for testing:
 xen                  37a8946eeb9d
baseline version:
 xen                  c26e1a79fe77

------------------------------------------------------------
People who touched revisions under test:
  Charles Arnold 
  Christoph Egger 
  Ian Campbell 
  Ian Jackson 
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   pass    
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26115:37a8946eeb9d
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:09:29 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    
    
changeset:   26114:6f9e46917eb8
user:        Charles Arnold 
date:        Fri Oct 26 12:05:08 2012 +0100
    
    pygrub: Add option to list grub entries
    
    The argument to "--entry" allows 2 syntaxes, either directly the entry
    number in menu.lst, or the whole string behind the "title" key word.
    This poses the following issue:
    
    From Dom0 there is no way to guess the number and, or the complete
    title string because this string contains the kernel version, which
    will change with a kernel update.
    
    This patch adds [-l|--list-entries] as an argument to pygrub.
    
    Signed-off-by: Charles Arnold 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26113:03af0abd2b72
user:        Ian Campbell 
date:        Fri Oct 26 12:03:12 2012 +0100
    
    xl: Do not leak events when a domain exits.
    
    The goto in both of these places misses the event free which would
    normally clean up.
    
    ==8655== 80 bytes in 1 blocks are definitely lost in loss record 1 of 1
    ==8655==    at 0x4024370: calloc (vg_replace_malloc.c:593)
    ==8655==    by 0x406EAAE: libxl__zalloc (libxl_internal.c:83)
    ==8655==    by 0x4078173: libxl__event_new (libxl_event.c:1167)
    ==8655==    by 0x4056373: domain_death_occurred (libxl.c:958)
    ==8655==    by 0x4058D06: domain_death_xswatch_callback (libxl.c:1038)
    ==8655==    by 0x4078EB5: watchfd_callback (libxl_event.c:458)
    ==8655==    by 0x407839E: afterpoll_internal (libxl_event.c:949)
    ==8655==    by 0x4079142: eventloop_iteration (libxl_event.c:1371)
    ==8655==    by 0x40799BB: libxl_event_wait (libxl_event.c:1396)
    ==8655==    by 0x805CC67: create_domain (xl_cmdimpl.c:1698)
    ==8655==    by 0x805E001: main_create (xl_cmdimpl.c:3986)
    ==8655==    by 0x804D43D: main (xl.c:285)
    
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26112:d07692b5c780
user:        Ian Jackson 
date:        Fri Oct 26 11:39:42 2012 +0100
    
    Revert 26109:6ccfe4d29f95
    
    This changeset was contaminated by changes hanging around in my
    working tree.  Sorry :-(.
    
    Signed-off-by: Ian Jackson 
    
    
changeset:   26111:c26e1a79fe77
user:        Christoph Egger 
date:        Thu Oct 25 17:12:55 2012 +0100
    
    libxl: NetBSD PCI passthrough support
    
    Add PCI passthrough support for HVM guests.
    
    Signed-off-by: Christoph Egger 
    Committed-by: Ian Jackson 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 27 21:45:00 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 21:45:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSEB6-0006Au-2L; Sat, 27 Oct 2012 21:44:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSEB4-0006Ap-D2
	for xen-devel@lists.xensource.com; Sat, 27 Oct 2012 21:44:22 +0000
Received: from [85.158.143.35:45068] by server-3.bemta-4.messagelabs.com id
	E0/17-24279-5B55C805; Sat, 27 Oct 2012 21:44:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1351374260!11942225!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY0NTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14066 invoked from network); 27 Oct 2012 21:44:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Oct 2012 21:44:20 -0000
X-IronPort-AV: E=Sophos;i="4.80,662,1344211200"; d="scan'208";a="15446030"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Oct 2012 21:44:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sat, 27 Oct 2012 22:44:19 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TSEB1-0002Ga-IO;
	Sat, 27 Oct 2012 21:44:19 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TSEB1-0005BP-Hz;
	Sat, 27 Oct 2012 22:44:19 +0100
To: 
Message-ID: 
From: xen.org 
Date: Sat, 27 Oct 2012 22:44:19 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14108: trouble: blocked/broken/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14108 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14108/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   2 host-install(2)         broken REGR. vs. 14079
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 14079
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 14079

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a

version targeted for testing:
 xen                  37a8946eeb9d
baseline version:
 xen                  c26e1a79fe77

------------------------------------------------------------
People who touched revisions under test:
  Charles Arnold 
  Christoph Egger 
  Ian Campbell 
  Ian Jackson 
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   pass    
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26115:37a8946eeb9d
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:09:29 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    
    
changeset:   26114:6f9e46917eb8
user:        Charles Arnold 
date:        Fri Oct 26 12:05:08 2012 +0100
    
    pygrub: Add option to list grub entries
    
    The argument to "--entry" allows 2 syntaxes, either directly the entry
    number in menu.lst, or the whole string behind the "title" key word.
    This poses the following issue:
    
    From Dom0 there is no way to guess the number and, or the complete
    title string because this string contains the kernel version, which
    will change with a kernel update.
    
    This patch adds [-l|--list-entries] as an argument to pygrub.
    
    Signed-off-by: Charles Arnold 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26113:03af0abd2b72
user:        Ian Campbell 
date:        Fri Oct 26 12:03:12 2012 +0100
    
    xl: Do not leak events when a domain exits.
    
    The goto in both of these places misses the event free which would
    normally clean up.
    
    ==8655== 80 bytes in 1 blocks are definitely lost in loss record 1 of 1
    ==8655==    at 0x4024370: calloc (vg_replace_malloc.c:593)
    ==8655==    by 0x406EAAE: libxl__zalloc (libxl_internal.c:83)
    ==8655==    by 0x4078173: libxl__event_new (libxl_event.c:1167)
    ==8655==    by 0x4056373: domain_death_occurred (libxl.c:958)
    ==8655==    by 0x4058D06: domain_death_xswatch_callback (libxl.c:1038)
    ==8655==    by 0x4078EB5: watchfd_callback (libxl_event.c:458)
    ==8655==    by 0x407839E: afterpoll_internal (libxl_event.c:949)
    ==8655==    by 0x4079142: eventloop_iteration (libxl_event.c:1371)
    ==8655==    by 0x40799BB: libxl_event_wait (libxl_event.c:1396)
    ==8655==    by 0x805CC67: create_domain (xl_cmdimpl.c:1698)
    ==8655==    by 0x805E001: main_create (xl_cmdimpl.c:3986)
    ==8655==    by 0x804D43D: main (xl.c:285)
    
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26112:d07692b5c780
user:        Ian Jackson 
date:        Fri Oct 26 11:39:42 2012 +0100
    
    Revert 26109:6ccfe4d29f95
    
    This changeset was contaminated by changes hanging around in my
    working tree.  Sorry :-(.
    
    Signed-off-by: Ian Jackson 
    
    
changeset:   26111:c26e1a79fe77
user:        Christoph Egger 
date:        Thu Oct 25 17:12:55 2012 +0100
    
    libxl: NetBSD PCI passthrough support
    
    Add PCI passthrough support for HVM guests.
    
    Signed-off-by: Christoph Egger 
    Committed-by: Ian Jackson 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 27 22:55:18 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 22:55:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSFH9-00077Q-Pe; Sat, 27 Oct 2012 22:54:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSFH8-00077L-96
	for xen-devel@lists.xensource.com; Sat, 27 Oct 2012 22:54:42 +0000
Received: from [85.158.137.99:64526] by server-10.bemta-3.messagelabs.com id
	41/28-00901-1366C805; Sat, 27 Oct 2012 22:54:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1351378480!20925074!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY0NTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19993 invoked from network); 27 Oct 2012 22:54:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Oct 2012 22:54:40 -0000
X-IronPort-AV: E=Sophos;i="4.80,663,1344211200"; d="scan'208";a="15448139"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Oct 2012 22:54:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sat, 27 Oct 2012 23:54:39 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TSFH5-0002em-BU;
	Sat, 27 Oct 2012 22:54:39 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TSFH5-0006He-B1;
	Sat, 27 Oct 2012 23:54:39 +0100
To: 
Message-ID: 
From: xen.org 
Date: Sat, 27 Oct 2012 23:54:39 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 14105: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14105 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14105/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pv            3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-pv             3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-xl-multivcpu  3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-xl            3 host-install(3)         broken REGR. vs. 14076
 test-amd64-amd64-pv           3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-rhel6hvm-amd  3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)       broken REGR. vs. 14076
 test-i386-i386-xl             3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-pair         4 host-install/dst_host(4) broken REGR. vs. 14076
 test-amd64-i386-pair         3 host-install/src_host(3) broken REGR. vs. 14076
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 14076
 test-amd64-amd64-xl-qemuu-win7-amd64  3 host-install(3) broken REGR. vs. 14076
 test-amd64-i386-xend-winxpsp3  3 host-install(3)        broken REGR. vs. 14076
 test-amd64-i386-xl-win7-amd64  3 host-install(3)        broken REGR. vs. 14076
 test-amd64-i386-xl-winxpsp3-vcpus1  3 host-install(3)   broken REGR. vs. 14076
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 14076
 test-amd64-i386-win           3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 14076
 test-amd64-amd64-xl-win       3 host-install(3)         broken REGR. vs. 14076

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3)     broken pass in 14090
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3)   broken pass in 14094
 test-amd64-amd64-xl           3 host-install(3)           broken pass in 14085
 test-i386-i386-pair           4 host-install/dst_host(4)  broken pass in 14090
 test-i386-i386-pair           3 host-install/src_host(3)  broken pass in 14090
 test-amd64-amd64-pair         3 host-install/src_host(3)  broken pass in 14090
 test-amd64-amd64-pair         4 host-install/dst_host(4)  broken pass in 14090
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)  broken in 14090 pass in 14105
 test-i386-i386-win            7 windows-install    fail in 14085 pass in 14105

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)      broken REGR. vs. 14076
 test-amd64-amd64-xl-sedf      3 host-install(3)         broken REGR. vs. 14076

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  25eda7e7b4e6
baseline version:
 xen                  40ccbee890e1

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla 
  Bastian Blank 
  Chuang Cao 
  George Dunlap 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jason McCarver 
  Joe Jin 
  Keir Fraser 
  Matt Wilson 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Sander Eikelenboom 
  Stefano Stabellini 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          broken  
 test-amd64-i386-xl                                           broken  
 test-i386-i386-xl                                            broken  
 test-amd64-i386-rhel6hvm-amd                                 broken  
 test-amd64-i386-qemuu-rhel6hvm-amd                           broken  
 test-amd64-amd64-xl-qemuu-win7-amd64                         broken  
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         broken  
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        broken  
 test-amd64-i386-pair                                         broken  
 test-i386-i386-pair                                          broken  
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          broken  
 test-amd64-i386-pv                                           broken  
 test-i386-i386-pv                                            broken  
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           broken  
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          broken  
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      broken  
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                broken  
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 612 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Oct 27 22:55:18 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 27 Oct 2012 22:55:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSFH9-00077Q-Pe; Sat, 27 Oct 2012 22:54:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSFH8-00077L-96
	for xen-devel@lists.xensource.com; Sat, 27 Oct 2012 22:54:42 +0000
Received: from [85.158.137.99:64526] by server-10.bemta-3.messagelabs.com id
	41/28-00901-1366C805; Sat, 27 Oct 2012 22:54:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1351378480!20925074!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY0NTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19993 invoked from network); 27 Oct 2012 22:54:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Oct 2012 22:54:40 -0000
X-IronPort-AV: E=Sophos;i="4.80,663,1344211200"; d="scan'208";a="15448139"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Oct 2012 22:54:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sat, 27 Oct 2012 23:54:39 +0100
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TSFH5-0002em-BU;
	Sat, 27 Oct 2012 22:54:39 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TSFH5-0006He-B1;
	Sat, 27 Oct 2012 23:54:39 +0100
To: 
Message-ID: 
From: xen.org 
Date: Sat, 27 Oct 2012 23:54:39 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 14105: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14105 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14105/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pv            3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-pv             3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-xl-multivcpu  3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-xl            3 host-install(3)         broken REGR. vs. 14076
 test-amd64-amd64-pv           3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-rhel6hvm-amd  3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)       broken REGR. vs. 14076
 test-i386-i386-xl             3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-pair         4 host-install/dst_host(4) broken REGR. vs. 14076
 test-amd64-i386-pair         3 host-install/src_host(3) broken REGR. vs. 14076
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 14076
 test-amd64-amd64-xl-qemuu-win7-amd64  3 host-install(3) broken REGR. vs. 14076
 test-amd64-i386-xend-winxpsp3  3 host-install(3)        broken REGR. vs. 14076
 test-amd64-i386-xl-win7-amd64  3 host-install(3)        broken REGR. vs. 14076
 test-amd64-i386-xl-winxpsp3-vcpus1  3 host-install(3)   broken REGR. vs. 14076
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 14076
 test-amd64-i386-win           3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 14076
 test-amd64-amd64-xl-win       3 host-install(3)         broken REGR. vs. 14076

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3)     broken pass in 14090
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3)   broken pass in 14094
 test-amd64-amd64-xl           3 host-install(3)           broken pass in 14085
 test-i386-i386-pair           4 host-install/dst_host(4)  broken pass in 14090
 test-i386-i386-pair           3 host-install/src_host(3)  broken pass in 14090
 test-amd64-amd64-pair         3 host-install/src_host(3)  broken pass in 14090
 test-amd64-amd64-pair         4 host-install/dst_host(4)  broken pass in 14090
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)  broken in 14090 pass in 14105
 test-i386-i386-win            7 windows-install    fail in 14085 pass in 14105

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)      broken REGR. vs. 14076
 test-amd64-amd64-xl-sedf      3 host-install(3)         broken REGR. vs. 14076

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  25eda7e7b4e6
baseline version:
 xen                  40ccbee890e1

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla 
  Bastian Blank 
  Chuang Cao 
  George Dunlap 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jason McCarver 
  Joe Jin 
  Keir Fraser 
  Matt Wilson 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Sander Eikelenboom 
  Stefano Stabellini 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          broken  
 test-amd64-i386-xl                                           broken  
 test-i386-i386-xl                                            broken  
 test-amd64-i386-rhel6hvm-amd                                 broken  
 test-amd64-i386-qemuu-rhel6hvm-amd                           broken  
 test-amd64-amd64-xl-qemuu-win7-amd64                         broken  
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         broken  
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        broken  
 test-amd64-i386-pair                                         broken  
 test-i386-i386-pair                                          broken  
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          broken  
 test-amd64-i386-pv                                           broken  
 test-i386-i386-pv                                            broken  
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           broken  
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          broken  
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      broken  
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                broken  
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 612 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 28 01:14:23 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Oct 2012 01:14:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSHRj-0004eD-3Q; Sun, 28 Oct 2012 01:13:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSHRh-0004e5-3l
	for xen-devel@lists.xensource.com; Sun, 28 Oct 2012 01:13:45 +0000
Received: from [193.109.254.147:50909] by server-9.bemta-14.messagelabs.com id
	21/2A-30773-8C68C805; Sun, 28 Oct 2012 01:13:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1351386823!8539874!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY0NTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29362 invoked from network); 28 Oct 2012 01:13:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Oct 2012 01:13:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,663,1344211200"; d="scan'208";a="15448425"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Oct 2012 01:13:43 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sun, 28 Oct 2012 01:13:43 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TSHRe-0003Tn-UD;
	Sun, 28 Oct 2012 01:13:42 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TSHRe-00050h-Sj;
	Sun, 28 Oct 2012 01:13:42 +0000
To: 
Message-ID: 
From: xen.org 
Date: Sun, 28 Oct 2012 01:13:42 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 14111: trouble: blocked/broken
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14111 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14111/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386                    2 host-install(2)         broken REGR. vs. 13919
 build-amd64                   2 host-install(2)         broken REGR. vs. 13919
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 13919
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13919
 build-i386-pvops              2 host-install(2)         broken REGR. vs. 13919
 build-i386-oldkern            2 host-install(2)         broken REGR. vs. 13919

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 xen                  69d1cc78a5bd
baseline version:
 xen                  a15596a619ed

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           broken  
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             broken  
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   23385:69d1cc78a5bd
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:10:04 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    [ Includes 25589:60f09d1ab1fe for CVE-2012-2625 ]
    
    
changeset:   23384:a15596a619ed
user:        Daniel De Graaf 
date:        Thu Oct 04 10:44:43 2012 +0200
    
    x86: check remote MMIO remap permissions
    
    When a domain is mapping pages from a different pg_owner domain, the
    iomem_access checks are currently only applied to the pg_owner domain,
    potentially allowing a domain with a more restrictive iomem_access
    policy to have the pages mapped into its page tables. To catch this,
    also check the owner of the page tables. The current domain does not
    need to be checked because the ability to manipulate a domain's page
    tables implies full access to the target domain, so checking that
    domain's permission is sufficient.
    
    Signed-off-by: Daniel De Graaf 
    Acked-by: Jan Beulich 
    xen-unstable changeset: 25952:8278d7d8fa48
    xen-unstable date: Wed Sep 26 09:56:07 UTC 2012
    
    
========================================
commit d7d453f51459b591faa96d1c123b5bfff7c5b6b6
Author: Ian Jackson 
Date:   Thu Sep 6 17:05:30 2012 +0100

    Disable qemu monitor by default.  The qemu monitor is an overly
    powerful feature which must be protected from untrusted (guest)
    administrators.
    
    Neither xl nor xend expect qemu to produce this monitor unless it is
    explicitly requested.
    
    This is a security problem, XSA-19.  Previously it was CVE-2007-0998
    in Red Hat but we haven't dealt with it in upstream.  We hope to have
    a new CVE for it here but we don't have one yet.
    
    Signed-off-by: Ian Jackson 
    (cherry picked from commit bacc0d302445c75f18f4c826750fb5853b60e7ca)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 28 01:14:23 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Oct 2012 01:14:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSHRj-0004eD-3Q; Sun, 28 Oct 2012 01:13:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSHRh-0004e5-3l
	for xen-devel@lists.xensource.com; Sun, 28 Oct 2012 01:13:45 +0000
Received: from [193.109.254.147:50909] by server-9.bemta-14.messagelabs.com id
	21/2A-30773-8C68C805; Sun, 28 Oct 2012 01:13:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1351386823!8539874!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY0NTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29362 invoked from network); 28 Oct 2012 01:13:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Oct 2012 01:13:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,663,1344211200"; d="scan'208";a="15448425"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Oct 2012 01:13:43 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sun, 28 Oct 2012 01:13:43 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TSHRe-0003Tn-UD;
	Sun, 28 Oct 2012 01:13:42 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TSHRe-00050h-Sj;
	Sun, 28 Oct 2012 01:13:42 +0000
To: 
Message-ID: 
From: xen.org 
Date: Sun, 28 Oct 2012 01:13:42 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 14111: trouble: blocked/broken
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14111 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14111/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386                    2 host-install(2)         broken REGR. vs. 13919
 build-amd64                   2 host-install(2)         broken REGR. vs. 13919
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 13919
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13919
 build-i386-pvops              2 host-install(2)         broken REGR. vs. 13919
 build-i386-oldkern            2 host-install(2)         broken REGR. vs. 13919

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 xen                  69d1cc78a5bd
baseline version:
 xen                  a15596a619ed

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           broken  
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             broken  
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   23385:69d1cc78a5bd
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:10:04 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    [ Includes 25589:60f09d1ab1fe for CVE-2012-2625 ]
    
    
changeset:   23384:a15596a619ed
user:        Daniel De Graaf 
date:        Thu Oct 04 10:44:43 2012 +0200
    
    x86: check remote MMIO remap permissions
    
    When a domain is mapping pages from a different pg_owner domain, the
    iomem_access checks are currently only applied to the pg_owner domain,
    potentially allowing a domain with a more restrictive iomem_access
    policy to have the pages mapped into its page tables. To catch this,
    also check the owner of the page tables. The current domain does not
    need to be checked because the ability to manipulate a domain's page
    tables implies full access to the target domain, so checking that
    domain's permission is sufficient.
    
    Signed-off-by: Daniel De Graaf 
    Acked-by: Jan Beulich 
    xen-unstable changeset: 25952:8278d7d8fa48
    xen-unstable date: Wed Sep 26 09:56:07 UTC 2012
    
    
========================================
commit d7d453f51459b591faa96d1c123b5bfff7c5b6b6
Author: Ian Jackson 
Date:   Thu Sep 6 17:05:30 2012 +0100

    Disable qemu monitor by default.  The qemu monitor is an overly
    powerful feature which must be protected from untrusted (guest)
    administrators.
    
    Neither xl nor xend expect qemu to produce this monitor unless it is
    explicitly requested.
    
    This is a security problem, XSA-19.  Previously it was CVE-2007-0998
    in Red Hat but we haven't dealt with it in upstream.  We hope to have
    a new CVE for it here but we don't have one yet.
    
    Signed-off-by: Ian Jackson 
    (cherry picked from commit bacc0d302445c75f18f4c826750fb5853b60e7ca)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 28 02:18:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Oct 2012 02:18:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSIRW-0005lY-3w; Sun, 28 Oct 2012 02:17:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSIRV-0005lT-0c
	for xen-devel@lists.xensource.com; Sun, 28 Oct 2012 02:17:37 +0000
Received: from [85.158.137.99:21203] by server-6.bemta-3.messagelabs.com id
	FF/0F-32375-0C59C805; Sun, 28 Oct 2012 02:17:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1351390655!20182561!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY0NTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22232 invoked from network); 28 Oct 2012 02:17:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Oct 2012 02:17:35 -0000
X-IronPort-AV: E=Sophos;i="4.80,663,1344211200"; d="scan'208";a="15448530"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Oct 2012 02:17:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sun, 28 Oct 2012 02:17:34 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TSIRS-0003oi-Fk;
	Sun, 28 Oct 2012 02:17:34 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TSIRS-0007hX-2k;
	Sun, 28 Oct 2012 02:17:34 +0000
To: 
Message-ID: 
From: xen.org 
Date: Sun, 28 Oct 2012 02:17:34 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 14109: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14109 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14109/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pv            3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-pv             3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-xl-multivcpu  3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-xl            3 host-install(3)         broken REGR. vs. 14076
 test-amd64-amd64-pv           3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-rhel6hvm-amd  3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)       broken REGR. vs. 14076
 test-i386-i386-xl             9 guest-start               fail REGR. vs. 14076
 test-amd64-i386-pair         4 host-install/dst_host(4) broken REGR. vs. 14076
 test-amd64-i386-pair         3 host-install/src_host(3) broken REGR. vs. 14076
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 14076
 test-amd64-amd64-xl-qemuu-win7-amd64  3 host-install(3) broken REGR. vs. 14076
 test-amd64-i386-xend-winxpsp3  3 host-install(3)        broken REGR. vs. 14076
 test-amd64-i386-xl-win7-amd64  3 host-install(3)        broken REGR. vs. 14076
 test-amd64-i386-xl-winxpsp3-vcpus1  3 host-install(3)   broken REGR. vs. 14076
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 14076
 test-amd64-i386-win           3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 14076
 test-amd64-amd64-xl-win       3 host-install(3)         broken REGR. vs. 14076

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3)     broken pass in 14090
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)           broken pass in 14105
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3)   broken pass in 14094
 test-amd64-amd64-xl           3 host-install(3)           broken pass in 14085
 test-i386-i386-pair           4 host-install/dst_host(4)  broken pass in 14090
 test-i386-i386-pair           3 host-install/src_host(3)  broken pass in 14090
 test-amd64-i386-xl-win-vcpus1  3 host-install(3)          broken pass in 14105
 test-i386-i386-xl             3 host-install(3)  broken in 14090 pass in 14109
 test-amd64-amd64-pair 3 host-install/src_host(3) broken in 14105 pass in 14109
 test-amd64-amd64-pair 4 host-install/dst_host(4) broken in 14105 pass in 14109
 test-i386-i386-win            7 windows-install    fail in 14085 pass in 14109

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)      broken REGR. vs. 14076
 test-amd64-amd64-xl-sedf      3 host-install(3)         broken REGR. vs. 14076

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop           fail in 14090 never pass

version targeted for testing:
 xen                  25eda7e7b4e6
baseline version:
 xen                  40ccbee890e1

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla 
  Bastian Blank 
  Chuang Cao 
  George Dunlap 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jason McCarver 
  Joe Jin 
  Keir Fraser 
  Matt Wilson 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Sander Eikelenboom 
  Stefano Stabellini 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          broken  
 test-amd64-i386-xl                                           broken  
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 broken  
 test-amd64-i386-qemuu-rhel6hvm-amd                           broken  
 test-amd64-amd64-xl-qemuu-win7-amd64                         broken  
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         broken  
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         broken  
 test-i386-i386-pair                                          broken  
 test-amd64-amd64-xl-sedf-pin                                 broken  
 test-amd64-amd64-pv                                          broken  
 test-amd64-i386-pv                                           broken  
 test-i386-i386-pv                                            broken  
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           broken  
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          broken  
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      broken  
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                broken  
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 612 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 28 02:18:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Oct 2012 02:18:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSIRW-0005lY-3w; Sun, 28 Oct 2012 02:17:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSIRV-0005lT-0c
	for xen-devel@lists.xensource.com; Sun, 28 Oct 2012 02:17:37 +0000
Received: from [85.158.137.99:21203] by server-6.bemta-3.messagelabs.com id
	FF/0F-32375-0C59C805; Sun, 28 Oct 2012 02:17:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1351390655!20182561!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY0NTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22232 invoked from network); 28 Oct 2012 02:17:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Oct 2012 02:17:35 -0000
X-IronPort-AV: E=Sophos;i="4.80,663,1344211200"; d="scan'208";a="15448530"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Oct 2012 02:17:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sun, 28 Oct 2012 02:17:34 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TSIRS-0003oi-Fk;
	Sun, 28 Oct 2012 02:17:34 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TSIRS-0007hX-2k;
	Sun, 28 Oct 2012 02:17:34 +0000
To: 
Message-ID: 
From: xen.org 
Date: Sun, 28 Oct 2012 02:17:34 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 14109: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14109 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14109/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pv            3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-pv             3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-xl-multivcpu  3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-xl            3 host-install(3)         broken REGR. vs. 14076
 test-amd64-amd64-pv           3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-rhel6hvm-amd  3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)       broken REGR. vs. 14076
 test-i386-i386-xl             9 guest-start               fail REGR. vs. 14076
 test-amd64-i386-pair         4 host-install/dst_host(4) broken REGR. vs. 14076
 test-amd64-i386-pair         3 host-install/src_host(3) broken REGR. vs. 14076
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 14076
 test-amd64-amd64-xl-qemuu-win7-amd64  3 host-install(3) broken REGR. vs. 14076
 test-amd64-i386-xend-winxpsp3  3 host-install(3)        broken REGR. vs. 14076
 test-amd64-i386-xl-win7-amd64  3 host-install(3)        broken REGR. vs. 14076
 test-amd64-i386-xl-winxpsp3-vcpus1  3 host-install(3)   broken REGR. vs. 14076
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 14076
 test-amd64-i386-win           3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 14076
 test-amd64-amd64-xl-win       3 host-install(3)         broken REGR. vs. 14076

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3)     broken pass in 14090
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)           broken pass in 14105
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3)   broken pass in 14094
 test-amd64-amd64-xl           3 host-install(3)           broken pass in 14085
 test-i386-i386-pair           4 host-install/dst_host(4)  broken pass in 14090
 test-i386-i386-pair           3 host-install/src_host(3)  broken pass in 14090
 test-amd64-i386-xl-win-vcpus1  3 host-install(3)          broken pass in 14105
 test-i386-i386-xl             3 host-install(3)  broken in 14090 pass in 14109
 test-amd64-amd64-pair 3 host-install/src_host(3) broken in 14105 pass in 14109
 test-amd64-amd64-pair 4 host-install/dst_host(4) broken in 14105 pass in 14109
 test-i386-i386-win            7 windows-install    fail in 14085 pass in 14109

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)      broken REGR. vs. 14076
 test-amd64-amd64-xl-sedf      3 host-install(3)         broken REGR. vs. 14076

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop           fail in 14090 never pass

version targeted for testing:
 xen                  25eda7e7b4e6
baseline version:
 xen                  40ccbee890e1

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla 
  Bastian Blank 
  Chuang Cao 
  George Dunlap 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jason McCarver 
  Joe Jin 
  Keir Fraser 
  Matt Wilson 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Sander Eikelenboom 
  Stefano Stabellini 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          broken  
 test-amd64-i386-xl                                           broken  
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 broken  
 test-amd64-i386-qemuu-rhel6hvm-amd                           broken  
 test-amd64-amd64-xl-qemuu-win7-amd64                         broken  
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         broken  
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         broken  
 test-i386-i386-pair                                          broken  
 test-amd64-amd64-xl-sedf-pin                                 broken  
 test-amd64-amd64-pv                                          broken  
 test-amd64-i386-pv                                           broken  
 test-i386-i386-pv                                            broken  
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           broken  
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          broken  
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      broken  
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                broken  
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 612 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 28 02:22:49 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Oct 2012 02:22:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSIW4-0005yU-FR; Sun, 28 Oct 2012 02:22:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSIW3-0005yO-Lt
	for xen-devel@lists.xensource.com; Sun, 28 Oct 2012 02:22:20 +0000
Received: from [85.158.138.51:65009] by server-5.bemta-3.messagelabs.com id
	45/ED-12440-AD69C805; Sun, 28 Oct 2012 02:22:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1351390937!27596752!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY0NTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8367 invoked from network); 28 Oct 2012 02:22:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Oct 2012 02:22:17 -0000
X-IronPort-AV: E=Sophos;i="4.80,664,1344211200"; d="scan'208";a="15448540"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Oct 2012 02:22:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sun, 28 Oct 2012 02:22:16 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TSIW0-0003qH-UO;
	Sun, 28 Oct 2012 02:22:16 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TSIW0-00081M-TR;
	Sun, 28 Oct 2012 02:22:16 +0000
To: 
Message-ID: 
From: xen.org 
Date: Sun, 28 Oct 2012 02:22:16 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14112: trouble: blocked/broken/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14112 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14112/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   2 host-install(2)         broken REGR. vs. 14079
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 14079
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 14079
 build-i386-oldkern            2 host-install(2)         broken REGR. vs. 14079
 build-i386                    2 host-install(2)         broken REGR. vs. 14079

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a

version targeted for testing:
 xen                  37a8946eeb9d
baseline version:
 xen                  c26e1a79fe77

------------------------------------------------------------
People who touched revisions under test:
  Charles Arnold 
  Christoph Egger 
  Ian Campbell 
  Ian Jackson 
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           broken  
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26115:37a8946eeb9d
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:09:29 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    
    
changeset:   26114:6f9e46917eb8
user:        Charles Arnold 
date:        Fri Oct 26 12:05:08 2012 +0100
    
    pygrub: Add option to list grub entries
    
    The argument to "--entry" allows 2 syntaxes, either directly the entry
    number in menu.lst, or the whole string behind the "title" key word.
    This poses the following issue:
    
    From Dom0 there is no way to guess the number and, or the complete
    title string because this string contains the kernel version, which
    will change with a kernel update.
    
    This patch adds [-l|--list-entries] as an argument to pygrub.
    
    Signed-off-by: Charles Arnold 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26113:03af0abd2b72
user:        Ian Campbell 
date:        Fri Oct 26 12:03:12 2012 +0100
    
    xl: Do not leak events when a domain exits.
    
    The goto in both of these places misses the event free which would
    normally clean up.
    
    ==8655== 80 bytes in 1 blocks are definitely lost in loss record 1 of 1
    ==8655==    at 0x4024370: calloc (vg_replace_malloc.c:593)
    ==8655==    by 0x406EAAE: libxl__zalloc (libxl_internal.c:83)
    ==8655==    by 0x4078173: libxl__event_new (libxl_event.c:1167)
    ==8655==    by 0x4056373: domain_death_occurred (libxl.c:958)
    ==8655==    by 0x4058D06: domain_death_xswatch_callback (libxl.c:1038)
    ==8655==    by 0x4078EB5: watchfd_callback (libxl_event.c:458)
    ==8655==    by 0x407839E: afterpoll_internal (libxl_event.c:949)
    ==8655==    by 0x4079142: eventloop_iteration (libxl_event.c:1371)
    ==8655==    by 0x40799BB: libxl_event_wait (libxl_event.c:1396)
    ==8655==    by 0x805CC67: create_domain (xl_cmdimpl.c:1698)
    ==8655==    by 0x805E001: main_create (xl_cmdimpl.c:3986)
    ==8655==    by 0x804D43D: main (xl.c:285)
    
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26112:d07692b5c780
user:        Ian Jackson 
date:        Fri Oct 26 11:39:42 2012 +0100
    
    Revert 26109:6ccfe4d29f95
    
    This changeset was contaminated by changes hanging around in my
    working tree.  Sorry :-(.
    
    Signed-off-by: Ian Jackson 
    
    
changeset:   26111:c26e1a79fe77
user:        Christoph Egger 
date:        Thu Oct 25 17:12:55 2012 +0100
    
    libxl: NetBSD PCI passthrough support
    
    Add PCI passthrough support for HVM guests.
    
    Signed-off-by: Christoph Egger 
    Committed-by: Ian Jackson 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 28 02:22:49 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Oct 2012 02:22:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSIW4-0005yU-FR; Sun, 28 Oct 2012 02:22:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSIW3-0005yO-Lt
	for xen-devel@lists.xensource.com; Sun, 28 Oct 2012 02:22:20 +0000
Received: from [85.158.138.51:65009] by server-5.bemta-3.messagelabs.com id
	45/ED-12440-AD69C805; Sun, 28 Oct 2012 02:22:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1351390937!27596752!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY0NTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8367 invoked from network); 28 Oct 2012 02:22:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Oct 2012 02:22:17 -0000
X-IronPort-AV: E=Sophos;i="4.80,664,1344211200"; d="scan'208";a="15448540"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Oct 2012 02:22:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sun, 28 Oct 2012 02:22:16 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TSIW0-0003qH-UO;
	Sun, 28 Oct 2012 02:22:16 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TSIW0-00081M-TR;
	Sun, 28 Oct 2012 02:22:16 +0000
To: 
Message-ID: 
From: xen.org 
Date: Sun, 28 Oct 2012 02:22:16 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14112: trouble: blocked/broken/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14112 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14112/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   2 host-install(2)         broken REGR. vs. 14079
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 14079
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 14079
 build-i386-oldkern            2 host-install(2)         broken REGR. vs. 14079
 build-i386                    2 host-install(2)         broken REGR. vs. 14079

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a

version targeted for testing:
 xen                  37a8946eeb9d
baseline version:
 xen                  c26e1a79fe77

------------------------------------------------------------
People who touched revisions under test:
  Charles Arnold 
  Christoph Egger 
  Ian Campbell 
  Ian Jackson 
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           broken  
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26115:37a8946eeb9d
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:09:29 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    
    
changeset:   26114:6f9e46917eb8
user:        Charles Arnold 
date:        Fri Oct 26 12:05:08 2012 +0100
    
    pygrub: Add option to list grub entries
    
    The argument to "--entry" allows 2 syntaxes, either directly the entry
    number in menu.lst, or the whole string behind the "title" key word.
    This poses the following issue:
    
    From Dom0 there is no way to guess the number and, or the complete
    title string because this string contains the kernel version, which
    will change with a kernel update.
    
    This patch adds [-l|--list-entries] as an argument to pygrub.
    
    Signed-off-by: Charles Arnold 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26113:03af0abd2b72
user:        Ian Campbell 
date:        Fri Oct 26 12:03:12 2012 +0100
    
    xl: Do not leak events when a domain exits.
    
    The goto in both of these places misses the event free which would
    normally clean up.
    
    ==8655== 80 bytes in 1 blocks are definitely lost in loss record 1 of 1
    ==8655==    at 0x4024370: calloc (vg_replace_malloc.c:593)
    ==8655==    by 0x406EAAE: libxl__zalloc (libxl_internal.c:83)
    ==8655==    by 0x4078173: libxl__event_new (libxl_event.c:1167)
    ==8655==    by 0x4056373: domain_death_occurred (libxl.c:958)
    ==8655==    by 0x4058D06: domain_death_xswatch_callback (libxl.c:1038)
    ==8655==    by 0x4078EB5: watchfd_callback (libxl_event.c:458)
    ==8655==    by 0x407839E: afterpoll_internal (libxl_event.c:949)
    ==8655==    by 0x4079142: eventloop_iteration (libxl_event.c:1371)
    ==8655==    by 0x40799BB: libxl_event_wait (libxl_event.c:1396)
    ==8655==    by 0x805CC67: create_domain (xl_cmdimpl.c:1698)
    ==8655==    by 0x805E001: main_create (xl_cmdimpl.c:3986)
    ==8655==    by 0x804D43D: main (xl.c:285)
    
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26112:d07692b5c780
user:        Ian Jackson 
date:        Fri Oct 26 11:39:42 2012 +0100
    
    Revert 26109:6ccfe4d29f95
    
    This changeset was contaminated by changes hanging around in my
    working tree.  Sorry :-(.
    
    Signed-off-by: Ian Jackson 
    
    
changeset:   26111:c26e1a79fe77
user:        Christoph Egger 
date:        Thu Oct 25 17:12:55 2012 +0100
    
    libxl: NetBSD PCI passthrough support
    
    Add PCI passthrough support for HVM guests.
    
    Signed-off-by: Christoph Egger 
    Committed-by: Ian Jackson 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 28 06:19:35 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Oct 2012 06:19:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSMD9-0000qp-M3; Sun, 28 Oct 2012 06:19:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSMD8-0000qk-40
	for xen-devel@lists.xensource.com; Sun, 28 Oct 2012 06:19:02 +0000
Received: from [85.158.143.99:28974] by server-2.bemta-4.messagelabs.com id
	19/0A-22268-55ECC805; Sun, 28 Oct 2012 06:19:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1351405140!27674866!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY0NTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31378 invoked from network); 28 Oct 2012 06:19:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Oct 2012 06:19:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,665,1344211200"; d="scan'208";a="15449221"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Oct 2012 06:19:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sun, 28 Oct 2012 06:18:59 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TSMD5-00055o-Hh;
	Sun, 28 Oct 2012 06:18:59 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TSMD5-0001tc-8D;
	Sun, 28 Oct 2012 06:18:59 +0000
To: 
Message-ID: 
From: xen.org 
Date: Sun, 28 Oct 2012 06:18:59 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14116: trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14116 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14116/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-pv           3 host-install(3)         broken REGR. vs. 14079
 test-amd64-amd64-xl           3 host-install(3)         broken REGR. vs. 14079
 test-amd64-amd64-win          3 host-install(3)         broken REGR. vs. 14079
 test-amd64-amd64-xl-winxpsp3  3 host-install(3)         broken REGR. vs. 14079
 build-i386-oldkern            2 host-install(2)         broken REGR. vs. 14079
 build-i386                    2 host-install(2)         broken REGR. vs. 14079
 test-amd64-i386-qemuu-rhel6hvm-amd 3 host-install(3) broken in 14104 REGR. vs. 14079
 test-amd64-i386-xl           3 host-install(3) broken in 14104 REGR. vs. 14079
 test-amd64-i386-xl-credit2   3 host-install(3) broken in 14104 REGR. vs. 14079
 test-amd64-i386-rhel6hvm-intel 3 host-install(3) broken in 14104 REGR. vs. 14079
 test-amd64-i386-qemuu-rhel6hvm-intel 3 host-install(3) broken in 14104 REGR. vs. 14079
 test-amd64-i386-xl-win-vcpus1 3 host-install(3) broken in 14104 REGR. vs. 14079
 test-amd64-i386-xl-multivcpu 3 host-install(3) broken in 14104 REGR. vs. 14079
 test-amd64-i386-win-vcpus1   3 host-install(3) broken in 14104 REGR. vs. 14079
 test-amd64-i386-xl-win7-amd64 3 host-install(3) broken in 14104 REGR. vs. 14079
 test-amd64-i386-pair 3 host-install/src_host(3) broken in 14104 REGR. vs. 14079
 test-amd64-i386-pair 4 host-install/dst_host(4) broken in 14104 REGR. vs. 14079

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-pair         3 host-install/src_host(3)  broken pass in 14104
 test-amd64-amd64-pair         4 host-install/dst_host(4)  broken pass in 14104

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)      broken REGR. vs. 14079
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 14079
 test-amd64-amd64-xl-sedf      3 host-install(3)         broken REGR. vs. 14079
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 14079
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 14079

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-win          16 leak-check/check      fail in 14104 never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check     fail in 14104 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 14104 never pass

version targeted for testing:
 xen                  37a8946eeb9d
baseline version:
 xen                  c26e1a79fe77

------------------------------------------------------------
People who touched revisions under test:
  Charles Arnold 
  Christoph Egger 
  Ian Campbell 
  Ian Jackson 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   broken  
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           broken  
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          broken  
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        broken  
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          broken  
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         broken  
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 broken  


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26115:37a8946eeb9d
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:09:29 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    
    
changeset:   26114:6f9e46917eb8
user:        Charles Arnold 
date:        Fri Oct 26 12:05:08 2012 +0100
    
    pygrub: Add option to list grub entries
    
    The argument to "--entry" allows 2 syntaxes, either directly the entry
    number in menu.lst, or the whole string behind the "title" key word.
    This poses the following issue:
    
    From Dom0 there is no way to guess the number and, or the complete
    title string because this string contains the kernel version, which
    will change with a kernel update.
    
    This patch adds [-l|--list-entries] as an argument to pygrub.
    
    Signed-off-by: Charles Arnold 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26113:03af0abd2b72
user:        Ian Campbell 
date:        Fri Oct 26 12:03:12 2012 +0100
    
    xl: Do not leak events when a domain exits.
    
    The goto in both of these places misses the event free which would
    normally clean up.
    
    ==8655== 80 bytes in 1 blocks are definitely lost in loss record 1 of 1
    ==8655==    at 0x4024370: calloc (vg_replace_malloc.c:593)
    ==8655==    by 0x406EAAE: libxl__zalloc (libxl_internal.c:83)
    ==8655==    by 0x4078173: libxl__event_new (libxl_event.c:1167)
    ==8655==    by 0x4056373: domain_death_occurred (libxl.c:958)
    ==8655==    by 0x4058D06: domain_death_xswatch_callback (libxl.c:1038)
    ==8655==    by 0x4078EB5: watchfd_callback (libxl_event.c:458)
    ==8655==    by 0x407839E: afterpoll_internal (libxl_event.c:949)
    ==8655==    by 0x4079142: eventloop_iteration (libxl_event.c:1371)
    ==8655==    by 0x40799BB: libxl_event_wait (libxl_event.c:1396)
    ==8655==    by 0x805CC67: create_domain (xl_cmdimpl.c:1698)
    ==8655==    by 0x805E001: main_create (xl_cmdimpl.c:3986)
    ==8655==    by 0x804D43D: main (xl.c:285)
    
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26112:d07692b5c780
user:        Ian Jackson 
date:        Fri Oct 26 11:39:42 2012 +0100
    
    Revert 26109:6ccfe4d29f95
    
    This changeset was contaminated by changes hanging around in my
    working tree.  Sorry :-(.
    
    Signed-off-by: Ian Jackson 
    
    
changeset:   26111:c26e1a79fe77
user:        Christoph Egger 
date:        Thu Oct 25 17:12:55 2012 +0100
    
    libxl: NetBSD PCI passthrough support
    
    Add PCI passthrough support for HVM guests.
    
    Signed-off-by: Christoph Egger 
    Committed-by: Ian Jackson 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 28 06:19:35 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Oct 2012 06:19:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSMD9-0000qp-M3; Sun, 28 Oct 2012 06:19:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSMD8-0000qk-40
	for xen-devel@lists.xensource.com; Sun, 28 Oct 2012 06:19:02 +0000
Received: from [85.158.143.99:28974] by server-2.bemta-4.messagelabs.com id
	19/0A-22268-55ECC805; Sun, 28 Oct 2012 06:19:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1351405140!27674866!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY0NTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31378 invoked from network); 28 Oct 2012 06:19:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Oct 2012 06:19:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,665,1344211200"; d="scan'208";a="15449221"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Oct 2012 06:19:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sun, 28 Oct 2012 06:18:59 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TSMD5-00055o-Hh;
	Sun, 28 Oct 2012 06:18:59 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TSMD5-0001tc-8D;
	Sun, 28 Oct 2012 06:18:59 +0000
To: 
Message-ID: 
From: xen.org 
Date: Sun, 28 Oct 2012 06:18:59 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14116: trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14116 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14116/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-pv           3 host-install(3)         broken REGR. vs. 14079
 test-amd64-amd64-xl           3 host-install(3)         broken REGR. vs. 14079
 test-amd64-amd64-win          3 host-install(3)         broken REGR. vs. 14079
 test-amd64-amd64-xl-winxpsp3  3 host-install(3)         broken REGR. vs. 14079
 build-i386-oldkern            2 host-install(2)         broken REGR. vs. 14079
 build-i386                    2 host-install(2)         broken REGR. vs. 14079
 test-amd64-i386-qemuu-rhel6hvm-amd 3 host-install(3) broken in 14104 REGR. vs. 14079
 test-amd64-i386-xl           3 host-install(3) broken in 14104 REGR. vs. 14079
 test-amd64-i386-xl-credit2   3 host-install(3) broken in 14104 REGR. vs. 14079
 test-amd64-i386-rhel6hvm-intel 3 host-install(3) broken in 14104 REGR. vs. 14079
 test-amd64-i386-qemuu-rhel6hvm-intel 3 host-install(3) broken in 14104 REGR. vs. 14079
 test-amd64-i386-xl-win-vcpus1 3 host-install(3) broken in 14104 REGR. vs. 14079
 test-amd64-i386-xl-multivcpu 3 host-install(3) broken in 14104 REGR. vs. 14079
 test-amd64-i386-win-vcpus1   3 host-install(3) broken in 14104 REGR. vs. 14079
 test-amd64-i386-xl-win7-amd64 3 host-install(3) broken in 14104 REGR. vs. 14079
 test-amd64-i386-pair 3 host-install/src_host(3) broken in 14104 REGR. vs. 14079
 test-amd64-i386-pair 4 host-install/dst_host(4) broken in 14104 REGR. vs. 14079

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-pair         3 host-install/src_host(3)  broken pass in 14104
 test-amd64-amd64-pair         4 host-install/dst_host(4)  broken pass in 14104

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)      broken REGR. vs. 14079
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 14079
 test-amd64-amd64-xl-sedf      3 host-install(3)         broken REGR. vs. 14079
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 14079
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 14079

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-win          16 leak-check/check      fail in 14104 never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check     fail in 14104 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 14104 never pass

version targeted for testing:
 xen                  37a8946eeb9d
baseline version:
 xen                  c26e1a79fe77

------------------------------------------------------------
People who touched revisions under test:
  Charles Arnold 
  Christoph Egger 
  Ian Campbell 
  Ian Jackson 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   broken  
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           broken  
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          broken  
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        broken  
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          broken  
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         broken  
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 broken  


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26115:37a8946eeb9d
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:09:29 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    
    
changeset:   26114:6f9e46917eb8
user:        Charles Arnold 
date:        Fri Oct 26 12:05:08 2012 +0100
    
    pygrub: Add option to list grub entries
    
    The argument to "--entry" allows 2 syntaxes, either directly the entry
    number in menu.lst, or the whole string behind the "title" key word.
    This poses the following issue:
    
    From Dom0 there is no way to guess the number and, or the complete
    title string because this string contains the kernel version, which
    will change with a kernel update.
    
    This patch adds [-l|--list-entries] as an argument to pygrub.
    
    Signed-off-by: Charles Arnold 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26113:03af0abd2b72
user:        Ian Campbell 
date:        Fri Oct 26 12:03:12 2012 +0100
    
    xl: Do not leak events when a domain exits.
    
    The goto in both of these places misses the event free which would
    normally clean up.
    
    ==8655== 80 bytes in 1 blocks are definitely lost in loss record 1 of 1
    ==8655==    at 0x4024370: calloc (vg_replace_malloc.c:593)
    ==8655==    by 0x406EAAE: libxl__zalloc (libxl_internal.c:83)
    ==8655==    by 0x4078173: libxl__event_new (libxl_event.c:1167)
    ==8655==    by 0x4056373: domain_death_occurred (libxl.c:958)
    ==8655==    by 0x4058D06: domain_death_xswatch_callback (libxl.c:1038)
    ==8655==    by 0x4078EB5: watchfd_callback (libxl_event.c:458)
    ==8655==    by 0x407839E: afterpoll_internal (libxl_event.c:949)
    ==8655==    by 0x4079142: eventloop_iteration (libxl_event.c:1371)
    ==8655==    by 0x40799BB: libxl_event_wait (libxl_event.c:1396)
    ==8655==    by 0x805CC67: create_domain (xl_cmdimpl.c:1698)
    ==8655==    by 0x805E001: main_create (xl_cmdimpl.c:3986)
    ==8655==    by 0x804D43D: main (xl.c:285)
    
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26112:d07692b5c780
user:        Ian Jackson 
date:        Fri Oct 26 11:39:42 2012 +0100
    
    Revert 26109:6ccfe4d29f95
    
    This changeset was contaminated by changes hanging around in my
    working tree.  Sorry :-(.
    
    Signed-off-by: Ian Jackson 
    
    
changeset:   26111:c26e1a79fe77
user:        Christoph Egger 
date:        Thu Oct 25 17:12:55 2012 +0100
    
    libxl: NetBSD PCI passthrough support
    
    Add PCI passthrough support for HVM guests.
    
    Signed-off-by: Christoph Egger 
    Committed-by: Ian Jackson 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 28 07:16:49 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Oct 2012 07:16:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSN6a-0001rX-42; Sun, 28 Oct 2012 07:16:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSN6X-0001rS-Ip
	for xen-devel@lists.xensource.com; Sun, 28 Oct 2012 07:16:17 +0000
Received: from [85.158.139.211:25530] by server-6.bemta-5.messagelabs.com id
	84/B7-32589-0CBDC805; Sun, 28 Oct 2012 07:16:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1351408576!24010520!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY0NTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24175 invoked from network); 28 Oct 2012 07:16:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Oct 2012 07:16:16 -0000
X-IronPort-AV: E=Sophos;i="4.80,665,1344211200"; d="scan'208";a="15449403"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Oct 2012 07:16:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sun, 28 Oct 2012 07:16:14 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TSN6U-0005RT-Nv;
	Sun, 28 Oct 2012 07:16:14 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TSN6U-0002c7-M1;
	Sun, 28 Oct 2012 07:16:14 +0000
To: 
Message-ID: 
From: xen.org 
Date: Sun, 28 Oct 2012 07:16:14 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 14114: trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14114 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14114/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl             3 host-install(3)         broken REGR. vs. 13919
 test-i386-i386-xl-qemuu-winxpsp3  3 host-install(3)     broken REGR. vs. 13919
 test-i386-i386-pv             3 host-install(3)         broken REGR. vs. 13919
 test-i386-i386-win            3 host-install(3)         broken REGR. vs. 13919
 test-i386-i386-pair          4 host-install/dst_host(4) broken REGR. vs. 13919
 test-i386-i386-pair          3 host-install/src_host(3) broken REGR. vs. 13919
 build-amd64                   2 host-install(2)         broken REGR. vs. 13919
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 13919
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13919

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 xen                  69d1cc78a5bd
baseline version:
 xen                  a15596a619ed

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   pass    
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            broken  
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          broken  
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            broken  
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           broken  
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             broken  
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   23385:69d1cc78a5bd
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:10:04 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    [ Includes 25589:60f09d1ab1fe for CVE-2012-2625 ]
    
    
changeset:   23384:a15596a619ed
user:        Daniel De Graaf 
date:        Thu Oct 04 10:44:43 2012 +0200
    
    x86: check remote MMIO remap permissions
    
    When a domain is mapping pages from a different pg_owner domain, the
    iomem_access checks are currently only applied to the pg_owner domain,
    potentially allowing a domain with a more restrictive iomem_access
    policy to have the pages mapped into its page tables. To catch this,
    also check the owner of the page tables. The current domain does not
    need to be checked because the ability to manipulate a domain's page
    tables implies full access to the target domain, so checking that
    domain's permission is sufficient.
    
    Signed-off-by: Daniel De Graaf 
    Acked-by: Jan Beulich 
    xen-unstable changeset: 25952:8278d7d8fa48
    xen-unstable date: Wed Sep 26 09:56:07 UTC 2012
    
    
========================================
commit d7d453f51459b591faa96d1c123b5bfff7c5b6b6
Author: Ian Jackson 
Date:   Thu Sep 6 17:05:30 2012 +0100

    Disable qemu monitor by default.  The qemu monitor is an overly
    powerful feature which must be protected from untrusted (guest)
    administrators.
    
    Neither xl nor xend expect qemu to produce this monitor unless it is
    explicitly requested.
    
    This is a security problem, XSA-19.  Previously it was CVE-2007-0998
    in Red Hat but we haven't dealt with it in upstream.  We hope to have
    a new CVE for it here but we don't have one yet.
    
    Signed-off-by: Ian Jackson 
    (cherry picked from commit bacc0d302445c75f18f4c826750fb5853b60e7ca)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 28 07:16:49 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Oct 2012 07:16:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSN6a-0001rX-42; Sun, 28 Oct 2012 07:16:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSN6X-0001rS-Ip
	for xen-devel@lists.xensource.com; Sun, 28 Oct 2012 07:16:17 +0000
Received: from [85.158.139.211:25530] by server-6.bemta-5.messagelabs.com id
	84/B7-32589-0CBDC805; Sun, 28 Oct 2012 07:16:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1351408576!24010520!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY0NTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24175 invoked from network); 28 Oct 2012 07:16:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Oct 2012 07:16:16 -0000
X-IronPort-AV: E=Sophos;i="4.80,665,1344211200"; d="scan'208";a="15449403"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Oct 2012 07:16:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sun, 28 Oct 2012 07:16:14 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TSN6U-0005RT-Nv;
	Sun, 28 Oct 2012 07:16:14 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TSN6U-0002c7-M1;
	Sun, 28 Oct 2012 07:16:14 +0000
To: 
Message-ID: 
From: xen.org 
Date: Sun, 28 Oct 2012 07:16:14 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 14114: trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14114 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14114/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl             3 host-install(3)         broken REGR. vs. 13919
 test-i386-i386-xl-qemuu-winxpsp3  3 host-install(3)     broken REGR. vs. 13919
 test-i386-i386-pv             3 host-install(3)         broken REGR. vs. 13919
 test-i386-i386-win            3 host-install(3)         broken REGR. vs. 13919
 test-i386-i386-pair          4 host-install/dst_host(4) broken REGR. vs. 13919
 test-i386-i386-pair          3 host-install/src_host(3) broken REGR. vs. 13919
 build-amd64                   2 host-install(2)         broken REGR. vs. 13919
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 13919
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13919

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 xen                  69d1cc78a5bd
baseline version:
 xen                  a15596a619ed

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   pass    
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            broken  
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          broken  
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            broken  
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           broken  
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             broken  
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   23385:69d1cc78a5bd
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:10:04 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    [ Includes 25589:60f09d1ab1fe for CVE-2012-2625 ]
    
    
changeset:   23384:a15596a619ed
user:        Daniel De Graaf 
date:        Thu Oct 04 10:44:43 2012 +0200
    
    x86: check remote MMIO remap permissions
    
    When a domain is mapping pages from a different pg_owner domain, the
    iomem_access checks are currently only applied to the pg_owner domain,
    potentially allowing a domain with a more restrictive iomem_access
    policy to have the pages mapped into its page tables. To catch this,
    also check the owner of the page tables. The current domain does not
    need to be checked because the ability to manipulate a domain's page
    tables implies full access to the target domain, so checking that
    domain's permission is sufficient.
    
    Signed-off-by: Daniel De Graaf 
    Acked-by: Jan Beulich 
    xen-unstable changeset: 25952:8278d7d8fa48
    xen-unstable date: Wed Sep 26 09:56:07 UTC 2012
    
    
========================================
commit d7d453f51459b591faa96d1c123b5bfff7c5b6b6
Author: Ian Jackson 
Date:   Thu Sep 6 17:05:30 2012 +0100

    Disable qemu monitor by default.  The qemu monitor is an overly
    powerful feature which must be protected from untrusted (guest)
    administrators.
    
    Neither xl nor xend expect qemu to produce this monitor unless it is
    explicitly requested.
    
    This is a security problem, XSA-19.  Previously it was CVE-2007-0998
    in Red Hat but we haven't dealt with it in upstream.  We hope to have
    a new CVE for it here but we don't have one yet.
    
    Signed-off-by: Ian Jackson 
    (cherry picked from commit bacc0d302445c75f18f4c826750fb5853b60e7ca)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 28 09:26:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Oct 2012 09:26:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSP7h-00043M-FR; Sun, 28 Oct 2012 09:25:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSP7f-00043F-VC
	for xen-devel@lists.xensource.com; Sun, 28 Oct 2012 09:25:36 +0000
Received: from [85.158.143.35:16521] by server-2.bemta-4.messagelabs.com id
	3E/B6-22268-F0AFC805; Sun, 28 Oct 2012 09:25:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1351416333!10486036!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY0NTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3213 invoked from network); 28 Oct 2012 09:25:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Oct 2012 09:25:33 -0000
X-IronPort-AV: E=Sophos;i="4.80,665,1344211200"; d="scan'208";a="15450002"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Oct 2012 09:25:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sun, 28 Oct 2012 09:25:33 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TSP7d-000671-6v;
	Sun, 28 Oct 2012 09:25:33 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TSP7d-0004EV-4I;
	Sun, 28 Oct 2012 09:25:33 +0000
To: 
Message-ID: 
From: xen.org 
Date: Sun, 28 Oct 2012 09:25:33 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 14115: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14115 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14115/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pv            3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-pv             3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-xl-multivcpu  3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-xl            3 host-install(3)         broken REGR. vs. 14076
 test-amd64-amd64-pv           3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)       broken REGR. vs. 14076
 test-i386-i386-xl             9 guest-start               fail REGR. vs. 14076
 test-amd64-i386-pair         4 host-install/dst_host(4) broken REGR. vs. 14076
 test-amd64-i386-pair         3 host-install/src_host(3) broken REGR. vs. 14076
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 14076
 test-amd64-amd64-xl-qemuu-win7-amd64  3 host-install(3) broken REGR. vs. 14076
 test-amd64-i386-xend-winxpsp3  3 host-install(3)        broken REGR. vs. 14076
 test-amd64-i386-xl-win7-amd64  3 host-install(3)        broken REGR. vs. 14076
 test-amd64-i386-xl-winxpsp3-vcpus1  3 host-install(3)   broken REGR. vs. 14076
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 14076
 test-amd64-i386-win           3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 14076
 test-amd64-amd64-xl-win       3 host-install(3)         broken REGR. vs. 14076

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3)     broken pass in 14090
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore           fail pass in 14105
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3)   broken pass in 14094
 test-i386-i386-pair           4 host-install/dst_host(4)  broken pass in 14090
 test-i386-i386-pair           3 host-install/src_host(3)  broken pass in 14090
 test-amd64-amd64-pair         3 host-install/src_host(3)  broken pass in 14109
 test-amd64-amd64-pair         4 host-install/dst_host(4)  broken pass in 14109
 test-amd64-i386-rhel6hvm-amd  3 host-install(3)  broken in 14090 pass in 14115
 test-i386-i386-xl             3 host-install(3)  broken in 14090 pass in 14115
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)  broken in 14090 pass in 14115
 test-amd64-amd64-xl           3 host-install(3)  broken in 14090 pass in 14115
 test-amd64-amd64-xl-sedf      3 host-install(3)  broken in 14090 pass in 14115
 test-amd64-i386-xl-win-vcpus1  3 host-install(3) broken in 14109 pass in 14115

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)      broken REGR. vs. 14076

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  25eda7e7b4e6
baseline version:
 xen                  40ccbee890e1

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla 
  Bastian Blank 
  Chuang Cao 
  George Dunlap 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jason McCarver 
  Joe Jin 
  Keir Fraser 
  Matt Wilson 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Sander Eikelenboom 
  Stefano Stabellini 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           broken  
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           broken  
 test-amd64-amd64-xl-qemuu-win7-amd64                         broken  
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         broken  
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        broken  
 test-amd64-i386-pair                                         broken  
 test-i386-i386-pair                                          broken  
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          broken  
 test-amd64-i386-pv                                           broken  
 test-i386-i386-pv                                            broken  
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           broken  
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          broken  
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      broken  
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                broken  
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 612 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 28 09:26:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Oct 2012 09:26:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSP7h-00043M-FR; Sun, 28 Oct 2012 09:25:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSP7f-00043F-VC
	for xen-devel@lists.xensource.com; Sun, 28 Oct 2012 09:25:36 +0000
Received: from [85.158.143.35:16521] by server-2.bemta-4.messagelabs.com id
	3E/B6-22268-F0AFC805; Sun, 28 Oct 2012 09:25:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1351416333!10486036!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY0NTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3213 invoked from network); 28 Oct 2012 09:25:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Oct 2012 09:25:33 -0000
X-IronPort-AV: E=Sophos;i="4.80,665,1344211200"; d="scan'208";a="15450002"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Oct 2012 09:25:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sun, 28 Oct 2012 09:25:33 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TSP7d-000671-6v;
	Sun, 28 Oct 2012 09:25:33 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TSP7d-0004EV-4I;
	Sun, 28 Oct 2012 09:25:33 +0000
To: 
Message-ID: 
From: xen.org 
Date: Sun, 28 Oct 2012 09:25:33 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 14115: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14115 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14115/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pv            3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-pv             3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-xl-multivcpu  3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-xl            3 host-install(3)         broken REGR. vs. 14076
 test-amd64-amd64-pv           3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)       broken REGR. vs. 14076
 test-i386-i386-xl             9 guest-start               fail REGR. vs. 14076
 test-amd64-i386-pair         4 host-install/dst_host(4) broken REGR. vs. 14076
 test-amd64-i386-pair         3 host-install/src_host(3) broken REGR. vs. 14076
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 14076
 test-amd64-amd64-xl-qemuu-win7-amd64  3 host-install(3) broken REGR. vs. 14076
 test-amd64-i386-xend-winxpsp3  3 host-install(3)        broken REGR. vs. 14076
 test-amd64-i386-xl-win7-amd64  3 host-install(3)        broken REGR. vs. 14076
 test-amd64-i386-xl-winxpsp3-vcpus1  3 host-install(3)   broken REGR. vs. 14076
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 14076
 test-amd64-i386-win           3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 14076
 test-amd64-amd64-xl-win       3 host-install(3)         broken REGR. vs. 14076

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3)     broken pass in 14090
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore           fail pass in 14105
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3)   broken pass in 14094
 test-i386-i386-pair           4 host-install/dst_host(4)  broken pass in 14090
 test-i386-i386-pair           3 host-install/src_host(3)  broken pass in 14090
 test-amd64-amd64-pair         3 host-install/src_host(3)  broken pass in 14109
 test-amd64-amd64-pair         4 host-install/dst_host(4)  broken pass in 14109
 test-amd64-i386-rhel6hvm-amd  3 host-install(3)  broken in 14090 pass in 14115
 test-i386-i386-xl             3 host-install(3)  broken in 14090 pass in 14115
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)  broken in 14090 pass in 14115
 test-amd64-amd64-xl           3 host-install(3)  broken in 14090 pass in 14115
 test-amd64-amd64-xl-sedf      3 host-install(3)  broken in 14090 pass in 14115
 test-amd64-i386-xl-win-vcpus1  3 host-install(3) broken in 14109 pass in 14115

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)      broken REGR. vs. 14076

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  25eda7e7b4e6
baseline version:
 xen                  40ccbee890e1

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla 
  Bastian Blank 
  Chuang Cao 
  George Dunlap 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jason McCarver 
  Joe Jin 
  Keir Fraser 
  Matt Wilson 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Sander Eikelenboom 
  Stefano Stabellini 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           broken  
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           broken  
 test-amd64-amd64-xl-qemuu-win7-amd64                         broken  
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         broken  
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        broken  
 test-amd64-i386-pair                                         broken  
 test-i386-i386-pair                                          broken  
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          broken  
 test-amd64-i386-pv                                           broken  
 test-i386-i386-pv                                            broken  
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           broken  
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          broken  
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      broken  
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                broken  
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 612 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 28 12:13:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Oct 2012 12:13:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSRjk-0006Oz-UU; Sun, 28 Oct 2012 12:13:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSRjj-0006Ou-7B
	for xen-devel@lists.xensource.com; Sun, 28 Oct 2012 12:13:03 +0000
Received: from [85.158.139.211:22000] by server-8.bemta-5.messagelabs.com id
	D1/C6-23193-E412D805; Sun, 28 Oct 2012 12:13:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1351426381!23984671!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzOTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29153 invoked from network); 28 Oct 2012 12:13:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Oct 2012 12:13:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,665,1344211200"; d="scan'208";a="15450731"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Oct 2012 12:13:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sun, 28 Oct 2012 12:13:00 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TSRjg-00073E-GG;
	Sun, 28 Oct 2012 12:13:00 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TSRje-0004C9-W7;
	Sun, 28 Oct 2012 12:12:59 +0000
To: 
Message-ID: 
From: xen.org 
Date: Sun, 28 Oct 2012 12:12:58 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 14119: trouble: blocked/broken
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14119 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14119/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386                    2 host-install(2)         broken REGR. vs. 13919
 build-amd64                   2 host-install(2)         broken REGR. vs. 13919
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 13919
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13919
 build-i386-pvops              2 host-install(2)         broken REGR. vs. 13919
 build-i386-oldkern            2 host-install(2)         broken REGR. vs. 13919

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 xen                  69d1cc78a5bd
baseline version:
 xen                  a15596a619ed

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           broken  
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             broken  
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   23385:69d1cc78a5bd
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:10:04 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    [ Includes 25589:60f09d1ab1fe for CVE-2012-2625 ]
    
    
changeset:   23384:a15596a619ed
user:        Daniel De Graaf 
date:        Thu Oct 04 10:44:43 2012 +0200
    
    x86: check remote MMIO remap permissions
    
    When a domain is mapping pages from a different pg_owner domain, the
    iomem_access checks are currently only applied to the pg_owner domain,
    potentially allowing a domain with a more restrictive iomem_access
    policy to have the pages mapped into its page tables. To catch this,
    also check the owner of the page tables. The current domain does not
    need to be checked because the ability to manipulate a domain's page
    tables implies full access to the target domain, so checking that
    domain's permission is sufficient.
    
    Signed-off-by: Daniel De Graaf 
    Acked-by: Jan Beulich 
    xen-unstable changeset: 25952:8278d7d8fa48
    xen-unstable date: Wed Sep 26 09:56:07 UTC 2012
    
    
========================================
commit d7d453f51459b591faa96d1c123b5bfff7c5b6b6
Author: Ian Jackson 
Date:   Thu Sep 6 17:05:30 2012 +0100

    Disable qemu monitor by default.  The qemu monitor is an overly
    powerful feature which must be protected from untrusted (guest)
    administrators.
    
    Neither xl nor xend expect qemu to produce this monitor unless it is
    explicitly requested.
    
    This is a security problem, XSA-19.  Previously it was CVE-2007-0998
    in Red Hat but we haven't dealt with it in upstream.  We hope to have
    a new CVE for it here but we don't have one yet.
    
    Signed-off-by: Ian Jackson 
    (cherry picked from commit bacc0d302445c75f18f4c826750fb5853b60e7ca)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 28 12:13:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Oct 2012 12:13:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSRjk-0006Oz-UU; Sun, 28 Oct 2012 12:13:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSRjj-0006Ou-7B
	for xen-devel@lists.xensource.com; Sun, 28 Oct 2012 12:13:03 +0000
Received: from [85.158.139.211:22000] by server-8.bemta-5.messagelabs.com id
	D1/C6-23193-E412D805; Sun, 28 Oct 2012 12:13:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1351426381!23984671!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzOTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29153 invoked from network); 28 Oct 2012 12:13:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Oct 2012 12:13:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,665,1344211200"; d="scan'208";a="15450731"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Oct 2012 12:13:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sun, 28 Oct 2012 12:13:00 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TSRjg-00073E-GG;
	Sun, 28 Oct 2012 12:13:00 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TSRje-0004C9-W7;
	Sun, 28 Oct 2012 12:12:59 +0000
To: 
Message-ID: 
From: xen.org 
Date: Sun, 28 Oct 2012 12:12:58 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 14119: trouble: blocked/broken
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14119 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14119/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386                    2 host-install(2)         broken REGR. vs. 13919
 build-amd64                   2 host-install(2)         broken REGR. vs. 13919
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 13919
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13919
 build-i386-pvops              2 host-install(2)         broken REGR. vs. 13919
 build-i386-oldkern            2 host-install(2)         broken REGR. vs. 13919

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 xen                  69d1cc78a5bd
baseline version:
 xen                  a15596a619ed

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           broken  
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             broken  
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   23385:69d1cc78a5bd
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:10:04 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    [ Includes 25589:60f09d1ab1fe for CVE-2012-2625 ]
    
    
changeset:   23384:a15596a619ed
user:        Daniel De Graaf 
date:        Thu Oct 04 10:44:43 2012 +0200
    
    x86: check remote MMIO remap permissions
    
    When a domain is mapping pages from a different pg_owner domain, the
    iomem_access checks are currently only applied to the pg_owner domain,
    potentially allowing a domain with a more restrictive iomem_access
    policy to have the pages mapped into its page tables. To catch this,
    also check the owner of the page tables. The current domain does not
    need to be checked because the ability to manipulate a domain's page
    tables implies full access to the target domain, so checking that
    domain's permission is sufficient.
    
    Signed-off-by: Daniel De Graaf 
    Acked-by: Jan Beulich 
    xen-unstable changeset: 25952:8278d7d8fa48
    xen-unstable date: Wed Sep 26 09:56:07 UTC 2012
    
    
========================================
commit d7d453f51459b591faa96d1c123b5bfff7c5b6b6
Author: Ian Jackson 
Date:   Thu Sep 6 17:05:30 2012 +0100

    Disable qemu monitor by default.  The qemu monitor is an overly
    powerful feature which must be protected from untrusted (guest)
    administrators.
    
    Neither xl nor xend expect qemu to produce this monitor unless it is
    explicitly requested.
    
    This is a security problem, XSA-19.  Previously it was CVE-2007-0998
    in Red Hat but we haven't dealt with it in upstream.  We hope to have
    a new CVE for it here but we don't have one yet.
    
    Signed-off-by: Ian Jackson 
    (cherry picked from commit bacc0d302445c75f18f4c826750fb5853b60e7ca)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 28 13:06:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Oct 2012 13:06:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSSZK-00073z-5D; Sun, 28 Oct 2012 13:06:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSSZI-00073u-Ss
	for xen-devel@lists.xensource.com; Sun, 28 Oct 2012 13:06:21 +0000
Received: from [85.158.143.99:4002] by server-2.bemta-4.messagelabs.com id
	7D/A0-22268-CCD2D805; Sun, 28 Oct 2012 13:06:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1351429579!17905022!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzOTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11238 invoked from network); 28 Oct 2012 13:06:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Oct 2012 13:06:19 -0000
X-IronPort-AV: E=Sophos;i="4.80,665,1344211200"; d="scan'208";a="15450878"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Oct 2012 13:06:18 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sun, 28 Oct 2012 13:06:18 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TSSZG-0007KZ-EC;
	Sun, 28 Oct 2012 13:06:18 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TSSZG-00053r-BK;
	Sun, 28 Oct 2012 13:06:18 +0000
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Sun, 28 Oct 2012 13:06:18 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14120: trouble: blocked/broken/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14120 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14120/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   2 host-install(2)         broken REGR. vs. 14079
 build-i386-pvops              2 host-install(2)         broken REGR. vs. 14079
 build-i386                    2 host-install(2)         broken REGR. vs. 14079

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a

version targeted for testing:
 xen                  37a8946eeb9d
baseline version:
 xen                  c26e1a79fe77

------------------------------------------------------------
People who touched revisions under test:
  Charles Arnold 
  Christoph Egger 
  Ian Campbell 
  Ian Jackson 
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             broken  
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26115:37a8946eeb9d
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:09:29 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    
    
changeset:   26114:6f9e46917eb8
user:        Charles Arnold 
date:        Fri Oct 26 12:05:08 2012 +0100
    
    pygrub: Add option to list grub entries
    
    The argument to "--entry" allows 2 syntaxes, either directly the entry
    number in menu.lst, or the whole string behind the "title" key word.
    This poses the following issue:
    
    From Dom0 there is no way to guess the number and, or the complete
    title string because this string contains the kernel version, which
    will change with a kernel update.
    
    This patch adds [-l|--list-entries] as an argument to pygrub.
    
    Signed-off-by: Charles Arnold 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26113:03af0abd2b72
user:        Ian Campbell 
date:        Fri Oct 26 12:03:12 2012 +0100
    
    xl: Do not leak events when a domain exits.
    
    The goto in both of these places misses the event free which would
    normally clean up.
    
    ==8655== 80 bytes in 1 blocks are definitely lost in loss record 1 of 1
    ==8655==    at 0x4024370: calloc (vg_replace_malloc.c:593)
    ==8655==    by 0x406EAAE: libxl__zalloc (libxl_internal.c:83)
    ==8655==    by 0x4078173: libxl__event_new (libxl_event.c:1167)
    ==8655==    by 0x4056373: domain_death_occurred (libxl.c:958)
    ==8655==    by 0x4058D06: domain_death_xswatch_callback (libxl.c:1038)
    ==8655==    by 0x4078EB5: watchfd_callback (libxl_event.c:458)
    ==8655==    by 0x407839E: afterpoll_internal (libxl_event.c:949)
    ==8655==    by 0x4079142: eventloop_iteration (libxl_event.c:1371)
    ==8655==    by 0x40799BB: libxl_event_wait (libxl_event.c:1396)
    ==8655==    by 0x805CC67: create_domain (xl_cmdimpl.c:1698)
    ==8655==    by 0x805E001: main_create (xl_cmdimpl.c:3986)
    ==8655==    by 0x804D43D: main (xl.c:285)
    
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26112:d07692b5c780
user:        Ian Jackson 
date:        Fri Oct 26 11:39:42 2012 +0100
    
    Revert 26109:6ccfe4d29f95
    
    This changeset was contaminated by changes hanging around in my
    working tree.  Sorry :-(.
    
    Signed-off-by: Ian Jackson 
    
    
changeset:   26111:c26e1a79fe77
user:        Christoph Egger 
date:        Thu Oct 25 17:12:55 2012 +0100
    
    libxl: NetBSD PCI passthrough support
    
    Add PCI passthrough support for HVM guests.
    
    Signed-off-by: Christoph Egger 
    Committed-by: Ian Jackson 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 28 13:06:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Oct 2012 13:06:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSSZK-00073z-5D; Sun, 28 Oct 2012 13:06:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSSZI-00073u-Ss
	for xen-devel@lists.xensource.com; Sun, 28 Oct 2012 13:06:21 +0000
Received: from [85.158.143.99:4002] by server-2.bemta-4.messagelabs.com id
	7D/A0-22268-CCD2D805; Sun, 28 Oct 2012 13:06:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1351429579!17905022!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzOTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11238 invoked from network); 28 Oct 2012 13:06:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Oct 2012 13:06:19 -0000
X-IronPort-AV: E=Sophos;i="4.80,665,1344211200"; d="scan'208";a="15450878"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Oct 2012 13:06:18 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sun, 28 Oct 2012 13:06:18 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TSSZG-0007KZ-EC;
	Sun, 28 Oct 2012 13:06:18 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TSSZG-00053r-BK;
	Sun, 28 Oct 2012 13:06:18 +0000
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Sun, 28 Oct 2012 13:06:18 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14120: trouble: blocked/broken/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14120 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14120/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   2 host-install(2)         broken REGR. vs. 14079
 build-i386-pvops              2 host-install(2)         broken REGR. vs. 14079
 build-i386                    2 host-install(2)         broken REGR. vs. 14079

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a

version targeted for testing:
 xen                  37a8946eeb9d
baseline version:
 xen                  c26e1a79fe77

------------------------------------------------------------
People who touched revisions under test:
  Charles Arnold 
  Christoph Egger 
  Ian Campbell 
  Ian Jackson 
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             broken  
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26115:37a8946eeb9d
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:09:29 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    
    
changeset:   26114:6f9e46917eb8
user:        Charles Arnold 
date:        Fri Oct 26 12:05:08 2012 +0100
    
    pygrub: Add option to list grub entries
    
    The argument to "--entry" allows 2 syntaxes, either directly the entry
    number in menu.lst, or the whole string behind the "title" key word.
    This poses the following issue:
    
    From Dom0 there is no way to guess the number and, or the complete
    title string because this string contains the kernel version, which
    will change with a kernel update.
    
    This patch adds [-l|--list-entries] as an argument to pygrub.
    
    Signed-off-by: Charles Arnold 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26113:03af0abd2b72
user:        Ian Campbell 
date:        Fri Oct 26 12:03:12 2012 +0100
    
    xl: Do not leak events when a domain exits.
    
    The goto in both of these places misses the event free which would
    normally clean up.
    
    ==8655== 80 bytes in 1 blocks are definitely lost in loss record 1 of 1
    ==8655==    at 0x4024370: calloc (vg_replace_malloc.c:593)
    ==8655==    by 0x406EAAE: libxl__zalloc (libxl_internal.c:83)
    ==8655==    by 0x4078173: libxl__event_new (libxl_event.c:1167)
    ==8655==    by 0x4056373: domain_death_occurred (libxl.c:958)
    ==8655==    by 0x4058D06: domain_death_xswatch_callback (libxl.c:1038)
    ==8655==    by 0x4078EB5: watchfd_callback (libxl_event.c:458)
    ==8655==    by 0x407839E: afterpoll_internal (libxl_event.c:949)
    ==8655==    by 0x4079142: eventloop_iteration (libxl_event.c:1371)
    ==8655==    by 0x40799BB: libxl_event_wait (libxl_event.c:1396)
    ==8655==    by 0x805CC67: create_domain (xl_cmdimpl.c:1698)
    ==8655==    by 0x805E001: main_create (xl_cmdimpl.c:3986)
    ==8655==    by 0x804D43D: main (xl.c:285)
    
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26112:d07692b5c780
user:        Ian Jackson 
date:        Fri Oct 26 11:39:42 2012 +0100
    
    Revert 26109:6ccfe4d29f95
    
    This changeset was contaminated by changes hanging around in my
    working tree.  Sorry :-(.
    
    Signed-off-by: Ian Jackson 
    
    
changeset:   26111:c26e1a79fe77
user:        Christoph Egger 
date:        Thu Oct 25 17:12:55 2012 +0100
    
    libxl: NetBSD PCI passthrough support
    
    Add PCI passthrough support for HVM guests.
    
    Signed-off-by: Christoph Egger 
    Committed-by: Ian Jackson 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 28 13:19:50 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Oct 2012 13:19:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSSlm-0007Ib-FN; Sun, 28 Oct 2012 13:19:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSSlk-0007IW-OE
	for xen-devel@lists.xensource.com; Sun, 28 Oct 2012 13:19:13 +0000
Received: from [85.158.138.51:8455] by server-14.bemta-3.messagelabs.com id
	3A/F6-12788-FC03D805; Sun, 28 Oct 2012 13:19:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1351430350!27728954!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzOTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31504 invoked from network); 28 Oct 2012 13:19:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Oct 2012 13:19:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,665,1344211200"; d="scan'208";a="15450909"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Oct 2012 13:19:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sun, 28 Oct 2012 13:19:10 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TSSli-0007Ok-66;
	Sun, 28 Oct 2012 13:19:10 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TSSli-0005J5-52;
	Sun, 28 Oct 2012 13:19:10 +0000
To: 
Message-ID: 
From: xen.org 
Date: Sun, 28 Oct 2012 13:19:10 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 14117: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14117 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14117/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pv            3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-pv             3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-xl-multivcpu  3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-xl            3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)       broken REGR. vs. 14076
 test-i386-i386-xl             9 guest-start               fail REGR. vs. 14076
 test-amd64-i386-pair         4 host-install/dst_host(4) broken REGR. vs. 14076
 test-amd64-i386-pair         3 host-install/src_host(3) broken REGR. vs. 14076
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 14076
 test-amd64-amd64-xl-qemuu-win7-amd64  3 host-install(3) broken REGR. vs. 14076
 test-amd64-i386-xend-winxpsp3  3 host-install(3)        broken REGR. vs. 14076
 test-amd64-i386-xl-win7-amd64  3 host-install(3)        broken REGR. vs. 14076
 test-amd64-i386-xl-winxpsp3-vcpus1  3 host-install(3)   broken REGR. vs. 14076
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 14076
 test-amd64-i386-win           3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 14076
 test-amd64-amd64-xl-win       3 host-install(3)         broken REGR. vs. 14076

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-amd  3 host-install(3)           broken pass in 14115
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3)     broken pass in 14090
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore           fail pass in 14105
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3)   broken pass in 14094
 test-amd64-amd64-xl           3 host-install(3)           broken pass in 14115
 test-i386-i386-pair           4 host-install/dst_host(4)  broken pass in 14090
 test-i386-i386-pair           3 host-install/src_host(3)  broken pass in 14090
 test-amd64-amd64-pair         3 host-install/src_host(3)  broken pass in 14109
 test-amd64-amd64-pair         4 host-install/dst_host(4)  broken pass in 14109
 test-amd64-amd64-pv           3 host-install(3)  broken in 14115 pass in 14117
 test-i386-i386-xl             3 host-install(3)  broken in 14090 pass in 14117
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)  broken in 14090 pass in 14117
 test-amd64-amd64-xl-sedf      3 host-install(3)  broken in 14090 pass in 14117
 test-amd64-i386-xl-win-vcpus1  3 host-install(3) broken in 14109 pass in 14117

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)      broken REGR. vs. 14076

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  25eda7e7b4e6
baseline version:
 xen                  40ccbee890e1

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla 
  Bastian Blank 
  Chuang Cao 
  George Dunlap 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jason McCarver 
  Joe Jin 
  Keir Fraser 
  Matt Wilson 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Sander Eikelenboom 
  Stefano Stabellini 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          broken  
 test-amd64-i386-xl                                           broken  
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 broken  
 test-amd64-i386-qemuu-rhel6hvm-amd                           broken  
 test-amd64-amd64-xl-qemuu-win7-amd64                         broken  
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         broken  
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        broken  
 test-amd64-i386-pair                                         broken  
 test-i386-i386-pair                                          broken  
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           broken  
 test-i386-i386-pv                                            broken  
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           broken  
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          broken  
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      broken  
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                broken  
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 612 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 28 13:19:50 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Oct 2012 13:19:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSSlm-0007Ib-FN; Sun, 28 Oct 2012 13:19:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSSlk-0007IW-OE
	for xen-devel@lists.xensource.com; Sun, 28 Oct 2012 13:19:13 +0000
Received: from [85.158.138.51:8455] by server-14.bemta-3.messagelabs.com id
	3A/F6-12788-FC03D805; Sun, 28 Oct 2012 13:19:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1351430350!27728954!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzOTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31504 invoked from network); 28 Oct 2012 13:19:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Oct 2012 13:19:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,665,1344211200"; d="scan'208";a="15450909"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Oct 2012 13:19:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sun, 28 Oct 2012 13:19:10 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TSSli-0007Ok-66;
	Sun, 28 Oct 2012 13:19:10 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TSSli-0005J5-52;
	Sun, 28 Oct 2012 13:19:10 +0000
To: 
Message-ID: 
From: xen.org 
Date: Sun, 28 Oct 2012 13:19:10 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 14117: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14117 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14117/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pv            3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-pv             3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-xl-multivcpu  3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-xl            3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)       broken REGR. vs. 14076
 test-i386-i386-xl             9 guest-start               fail REGR. vs. 14076
 test-amd64-i386-pair         4 host-install/dst_host(4) broken REGR. vs. 14076
 test-amd64-i386-pair         3 host-install/src_host(3) broken REGR. vs. 14076
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 14076
 test-amd64-amd64-xl-qemuu-win7-amd64  3 host-install(3) broken REGR. vs. 14076
 test-amd64-i386-xend-winxpsp3  3 host-install(3)        broken REGR. vs. 14076
 test-amd64-i386-xl-win7-amd64  3 host-install(3)        broken REGR. vs. 14076
 test-amd64-i386-xl-winxpsp3-vcpus1  3 host-install(3)   broken REGR. vs. 14076
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 14076
 test-amd64-i386-win           3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 14076
 test-amd64-amd64-xl-win       3 host-install(3)         broken REGR. vs. 14076

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-amd  3 host-install(3)           broken pass in 14115
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3)     broken pass in 14090
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore           fail pass in 14105
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3)   broken pass in 14094
 test-amd64-amd64-xl           3 host-install(3)           broken pass in 14115
 test-i386-i386-pair           4 host-install/dst_host(4)  broken pass in 14090
 test-i386-i386-pair           3 host-install/src_host(3)  broken pass in 14090
 test-amd64-amd64-pair         3 host-install/src_host(3)  broken pass in 14109
 test-amd64-amd64-pair         4 host-install/dst_host(4)  broken pass in 14109
 test-amd64-amd64-pv           3 host-install(3)  broken in 14115 pass in 14117
 test-i386-i386-xl             3 host-install(3)  broken in 14090 pass in 14117
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)  broken in 14090 pass in 14117
 test-amd64-amd64-xl-sedf      3 host-install(3)  broken in 14090 pass in 14117
 test-amd64-i386-xl-win-vcpus1  3 host-install(3) broken in 14109 pass in 14117

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)      broken REGR. vs. 14076

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  25eda7e7b4e6
baseline version:
 xen                  40ccbee890e1

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla 
  Bastian Blank 
  Chuang Cao 
  George Dunlap 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jason McCarver 
  Joe Jin 
  Keir Fraser 
  Matt Wilson 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Sander Eikelenboom 
  Stefano Stabellini 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          broken  
 test-amd64-i386-xl                                           broken  
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 broken  
 test-amd64-i386-qemuu-rhel6hvm-amd                           broken  
 test-amd64-amd64-xl-qemuu-win7-amd64                         broken  
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         broken  
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        broken  
 test-amd64-i386-pair                                         broken  
 test-i386-i386-pair                                          broken  
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           broken  
 test-i386-i386-pv                                            broken  
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           broken  
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          broken  
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      broken  
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                broken  
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 612 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 28 15:14:20 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Oct 2012 15:14:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSUYh-00017g-9l; Sun, 28 Oct 2012 15:13:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSUYf-00017b-Me
	for xen-devel@lists.xensource.com; Sun, 28 Oct 2012 15:13:50 +0000
Received: from [85.158.137.99:5307] by server-6.bemta-3.messagelabs.com id
	8F/FB-32375-CAB4D805; Sun, 28 Oct 2012 15:13:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1351437227!23244747!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzOTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12044 invoked from network); 28 Oct 2012 15:13:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Oct 2012 15:13:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,667,1344211200"; d="scan'208";a="15451497"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Oct 2012 15:13:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sun, 28 Oct 2012 15:13:47 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TSUYd-0007za-4v;
	Sun, 28 Oct 2012 15:13:47 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TSUYc-0003k9-Uk;
	Sun, 28 Oct 2012 15:13:47 +0000
To: 
Message-ID: 
From: xen.org 
Date: Sun, 28 Oct 2012 15:13:47 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 14123: trouble: blocked/broken
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14123 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14123/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386                    2 host-install(2)         broken REGR. vs. 13919
 build-amd64                   2 host-install(2)         broken REGR. vs. 13919
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 13919
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13919
 build-i386-pvops              2 host-install(2)         broken REGR. vs. 13919
 build-i386-oldkern            2 host-install(2)         broken REGR. vs. 13919

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 xen                  69d1cc78a5bd
baseline version:
 xen                  a15596a619ed

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           broken  
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             broken  
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   23385:69d1cc78a5bd
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:10:04 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    [ Includes 25589:60f09d1ab1fe for CVE-2012-2625 ]
    
    
changeset:   23384:a15596a619ed
user:        Daniel De Graaf 
date:        Thu Oct 04 10:44:43 2012 +0200
    
    x86: check remote MMIO remap permissions
    
    When a domain is mapping pages from a different pg_owner domain, the
    iomem_access checks are currently only applied to the pg_owner domain,
    potentially allowing a domain with a more restrictive iomem_access
    policy to have the pages mapped into its page tables. To catch this,
    also check the owner of the page tables. The current domain does not
    need to be checked because the ability to manipulate a domain's page
    tables implies full access to the target domain, so checking that
    domain's permission is sufficient.
    
    Signed-off-by: Daniel De Graaf 
    Acked-by: Jan Beulich 
    xen-unstable changeset: 25952:8278d7d8fa48
    xen-unstable date: Wed Sep 26 09:56:07 UTC 2012
    
    
========================================
commit d7d453f51459b591faa96d1c123b5bfff7c5b6b6
Author: Ian Jackson 
Date:   Thu Sep 6 17:05:30 2012 +0100

    Disable qemu monitor by default.  The qemu monitor is an overly
    powerful feature which must be protected from untrusted (guest)
    administrators.
    
    Neither xl nor xend expect qemu to produce this monitor unless it is
    explicitly requested.
    
    This is a security problem, XSA-19.  Previously it was CVE-2007-0998
    in Red Hat but we haven't dealt with it in upstream.  We hope to have
    a new CVE for it here but we don't have one yet.
    
    Signed-off-by: Ian Jackson 
    (cherry picked from commit bacc0d302445c75f18f4c826750fb5853b60e7ca)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 28 15:14:20 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Oct 2012 15:14:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSUYh-00017g-9l; Sun, 28 Oct 2012 15:13:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSUYf-00017b-Me
	for xen-devel@lists.xensource.com; Sun, 28 Oct 2012 15:13:50 +0000
Received: from [85.158.137.99:5307] by server-6.bemta-3.messagelabs.com id
	8F/FB-32375-CAB4D805; Sun, 28 Oct 2012 15:13:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1351437227!23244747!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzOTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12044 invoked from network); 28 Oct 2012 15:13:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Oct 2012 15:13:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,667,1344211200"; d="scan'208";a="15451497"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Oct 2012 15:13:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sun, 28 Oct 2012 15:13:47 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TSUYd-0007za-4v;
	Sun, 28 Oct 2012 15:13:47 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TSUYc-0003k9-Uk;
	Sun, 28 Oct 2012 15:13:47 +0000
To: 
Message-ID: 
From: xen.org 
Date: Sun, 28 Oct 2012 15:13:47 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 14123: trouble: blocked/broken
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14123 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14123/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386                    2 host-install(2)         broken REGR. vs. 13919
 build-amd64                   2 host-install(2)         broken REGR. vs. 13919
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 13919
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13919
 build-i386-pvops              2 host-install(2)         broken REGR. vs. 13919
 build-i386-oldkern            2 host-install(2)         broken REGR. vs. 13919

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 xen                  69d1cc78a5bd
baseline version:
 xen                  a15596a619ed

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           broken  
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             broken  
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   23385:69d1cc78a5bd
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:10:04 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    [ Includes 25589:60f09d1ab1fe for CVE-2012-2625 ]
    
    
changeset:   23384:a15596a619ed
user:        Daniel De Graaf 
date:        Thu Oct 04 10:44:43 2012 +0200
    
    x86: check remote MMIO remap permissions
    
    When a domain is mapping pages from a different pg_owner domain, the
    iomem_access checks are currently only applied to the pg_owner domain,
    potentially allowing a domain with a more restrictive iomem_access
    policy to have the pages mapped into its page tables. To catch this,
    also check the owner of the page tables. The current domain does not
    need to be checked because the ability to manipulate a domain's page
    tables implies full access to the target domain, so checking that
    domain's permission is sufficient.
    
    Signed-off-by: Daniel De Graaf 
    Acked-by: Jan Beulich 
    xen-unstable changeset: 25952:8278d7d8fa48
    xen-unstable date: Wed Sep 26 09:56:07 UTC 2012
    
    
========================================
commit d7d453f51459b591faa96d1c123b5bfff7c5b6b6
Author: Ian Jackson 
Date:   Thu Sep 6 17:05:30 2012 +0100

    Disable qemu monitor by default.  The qemu monitor is an overly
    powerful feature which must be protected from untrusted (guest)
    administrators.
    
    Neither xl nor xend expect qemu to produce this monitor unless it is
    explicitly requested.
    
    This is a security problem, XSA-19.  Previously it was CVE-2007-0998
    in Red Hat but we haven't dealt with it in upstream.  We hope to have
    a new CVE for it here but we don't have one yet.
    
    Signed-off-by: Ian Jackson 
    (cherry picked from commit bacc0d302445c75f18f4c826750fb5853b60e7ca)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 28 15:24:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Oct 2012 15:24:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSUiG-0001IW-CD; Sun, 28 Oct 2012 15:23:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSUiF-0001IR-1l
	for xen-devel@lists.xensource.com; Sun, 28 Oct 2012 15:23:43 +0000
Received: from [85.158.143.99:55524] by server-2.bemta-4.messagelabs.com id
	64/21-22268-EFD4D805; Sun, 28 Oct 2012 15:23:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1351437821!22429049!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzOTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25405 invoked from network); 28 Oct 2012 15:23:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Oct 2012 15:23:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,667,1344211200"; d="scan'208";a="15451520"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Oct 2012 15:23:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sun, 28 Oct 2012 15:23:41 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TSUiD-00082z-7j;
	Sun, 28 Oct 2012 15:23:41 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TSUiC-0004Oq-UP;
	Sun, 28 Oct 2012 15:23:41 +0000
To: 
Message-ID: 
From: xen.org 
Date: Sun, 28 Oct 2012 15:23:41 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14124: trouble: blocked/broken
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14124 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14124/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   2 host-install(2)         broken REGR. vs. 14079
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 14079
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 14079
 build-i386-pvops              2 host-install(2)         broken REGR. vs. 14079
 build-i386-oldkern            2 host-install(2)         broken REGR. vs. 14079
 build-i386                    2 host-install(2)         broken REGR. vs. 14079

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a

version targeted for testing:
 xen                  37a8946eeb9d
baseline version:
 xen                  c26e1a79fe77

------------------------------------------------------------
People who touched revisions under test:
  Charles Arnold 
  Christoph Egger 
  Ian Campbell 
  Ian Jackson 
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           broken  
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             broken  
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26115:37a8946eeb9d
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:09:29 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    
    
changeset:   26114:6f9e46917eb8
user:        Charles Arnold 
date:        Fri Oct 26 12:05:08 2012 +0100
    
    pygrub: Add option to list grub entries
    
    The argument to "--entry" allows 2 syntaxes, either directly the entry
    number in menu.lst, or the whole string behind the "title" key word.
    This poses the following issue:
    
    From Dom0 there is no way to guess the number and, or the complete
    title string because this string contains the kernel version, which
    will change with a kernel update.
    
    This patch adds [-l|--list-entries] as an argument to pygrub.
    
    Signed-off-by: Charles Arnold 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26113:03af0abd2b72
user:        Ian Campbell 
date:        Fri Oct 26 12:03:12 2012 +0100
    
    xl: Do not leak events when a domain exits.
    
    The goto in both of these places misses the event free which would
    normally clean up.
    
    ==8655== 80 bytes in 1 blocks are definitely lost in loss record 1 of 1
    ==8655==    at 0x4024370: calloc (vg_replace_malloc.c:593)
    ==8655==    by 0x406EAAE: libxl__zalloc (libxl_internal.c:83)
    ==8655==    by 0x4078173: libxl__event_new (libxl_event.c:1167)
    ==8655==    by 0x4056373: domain_death_occurred (libxl.c:958)
    ==8655==    by 0x4058D06: domain_death_xswatch_callback (libxl.c:1038)
    ==8655==    by 0x4078EB5: watchfd_callback (libxl_event.c:458)
    ==8655==    by 0x407839E: afterpoll_internal (libxl_event.c:949)
    ==8655==    by 0x4079142: eventloop_iteration (libxl_event.c:1371)
    ==8655==    by 0x40799BB: libxl_event_wait (libxl_event.c:1396)
    ==8655==    by 0x805CC67: create_domain (xl_cmdimpl.c:1698)
    ==8655==    by 0x805E001: main_create (xl_cmdimpl.c:3986)
    ==8655==    by 0x804D43D: main (xl.c:285)
    
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26112:d07692b5c780
user:        Ian Jackson 
date:        Fri Oct 26 11:39:42 2012 +0100
    
    Revert 26109:6ccfe4d29f95
    
    This changeset was contaminated by changes hanging around in my
    working tree.  Sorry :-(.
    
    Signed-off-by: Ian Jackson 
    
    
changeset:   26111:c26e1a79fe77
user:        Christoph Egger 
date:        Thu Oct 25 17:12:55 2012 +0100
    
    libxl: NetBSD PCI passthrough support
    
    Add PCI passthrough support for HVM guests.
    
    Signed-off-by: Christoph Egger 
    Committed-by: Ian Jackson 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 28 15:24:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Oct 2012 15:24:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSUiG-0001IW-CD; Sun, 28 Oct 2012 15:23:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSUiF-0001IR-1l
	for xen-devel@lists.xensource.com; Sun, 28 Oct 2012 15:23:43 +0000
Received: from [85.158.143.99:55524] by server-2.bemta-4.messagelabs.com id
	64/21-22268-EFD4D805; Sun, 28 Oct 2012 15:23:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1351437821!22429049!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzOTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25405 invoked from network); 28 Oct 2012 15:23:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Oct 2012 15:23:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,667,1344211200"; d="scan'208";a="15451520"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Oct 2012 15:23:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sun, 28 Oct 2012 15:23:41 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TSUiD-00082z-7j;
	Sun, 28 Oct 2012 15:23:41 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TSUiC-0004Oq-UP;
	Sun, 28 Oct 2012 15:23:41 +0000
To: 
Message-ID: 
From: xen.org 
Date: Sun, 28 Oct 2012 15:23:41 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14124: trouble: blocked/broken
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14124 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14124/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   2 host-install(2)         broken REGR. vs. 14079
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 14079
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 14079
 build-i386-pvops              2 host-install(2)         broken REGR. vs. 14079
 build-i386-oldkern            2 host-install(2)         broken REGR. vs. 14079
 build-i386                    2 host-install(2)         broken REGR. vs. 14079

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a

version targeted for testing:
 xen                  37a8946eeb9d
baseline version:
 xen                  c26e1a79fe77

------------------------------------------------------------
People who touched revisions under test:
  Charles Arnold 
  Christoph Egger 
  Ian Campbell 
  Ian Jackson 
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           broken  
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             broken  
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26115:37a8946eeb9d
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:09:29 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    
    
changeset:   26114:6f9e46917eb8
user:        Charles Arnold 
date:        Fri Oct 26 12:05:08 2012 +0100
    
    pygrub: Add option to list grub entries
    
    The argument to "--entry" allows 2 syntaxes, either directly the entry
    number in menu.lst, or the whole string behind the "title" key word.
    This poses the following issue:
    
    From Dom0 there is no way to guess the number and, or the complete
    title string because this string contains the kernel version, which
    will change with a kernel update.
    
    This patch adds [-l|--list-entries] as an argument to pygrub.
    
    Signed-off-by: Charles Arnold 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26113:03af0abd2b72
user:        Ian Campbell 
date:        Fri Oct 26 12:03:12 2012 +0100
    
    xl: Do not leak events when a domain exits.
    
    The goto in both of these places misses the event free which would
    normally clean up.
    
    ==8655== 80 bytes in 1 blocks are definitely lost in loss record 1 of 1
    ==8655==    at 0x4024370: calloc (vg_replace_malloc.c:593)
    ==8655==    by 0x406EAAE: libxl__zalloc (libxl_internal.c:83)
    ==8655==    by 0x4078173: libxl__event_new (libxl_event.c:1167)
    ==8655==    by 0x4056373: domain_death_occurred (libxl.c:958)
    ==8655==    by 0x4058D06: domain_death_xswatch_callback (libxl.c:1038)
    ==8655==    by 0x4078EB5: watchfd_callback (libxl_event.c:458)
    ==8655==    by 0x407839E: afterpoll_internal (libxl_event.c:949)
    ==8655==    by 0x4079142: eventloop_iteration (libxl_event.c:1371)
    ==8655==    by 0x40799BB: libxl_event_wait (libxl_event.c:1396)
    ==8655==    by 0x805CC67: create_domain (xl_cmdimpl.c:1698)
    ==8655==    by 0x805E001: main_create (xl_cmdimpl.c:3986)
    ==8655==    by 0x804D43D: main (xl.c:285)
    
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26112:d07692b5c780
user:        Ian Jackson 
date:        Fri Oct 26 11:39:42 2012 +0100
    
    Revert 26109:6ccfe4d29f95
    
    This changeset was contaminated by changes hanging around in my
    working tree.  Sorry :-(.
    
    Signed-off-by: Ian Jackson 
    
    
changeset:   26111:c26e1a79fe77
user:        Christoph Egger 
date:        Thu Oct 25 17:12:55 2012 +0100
    
    libxl: NetBSD PCI passthrough support
    
    Add PCI passthrough support for HVM guests.
    
    Signed-off-by: Christoph Egger 
    Committed-by: Ian Jackson 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 28 16:24:01 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Oct 2012 16:24:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSVe8-00025O-3e; Sun, 28 Oct 2012 16:23:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSVe6-00025J-5d
	for xen-devel@lists.xensource.com; Sun, 28 Oct 2012 16:23:30 +0000
Received: from [85.158.143.35:33113] by server-1.bemta-4.messagelabs.com id
	CC/5D-19134-10C5D805; Sun, 28 Oct 2012 16:23:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1351441408!12861452!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzOTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28446 invoked from network); 28 Oct 2012 16:23:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Oct 2012 16:23:28 -0000
X-IronPort-AV: E=Sophos;i="4.80,667,1344211200"; d="scan'208";a="15451698"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Oct 2012 16:23:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sun, 28 Oct 2012 16:23:26 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TSVe2-0008M3-Nv;
	Sun, 28 Oct 2012 16:23:26 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TSVe2-0005j4-NJ;
	Sun, 28 Oct 2012 16:23:26 +0000
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Sun, 28 Oct 2012 16:23:26 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 14121: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14121 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14121/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pv            3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-pv             3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-xl-multivcpu  3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-xl            3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)       broken REGR. vs. 14076
 test-i386-i386-xl             9 guest-start               fail REGR. vs. 14076
 test-amd64-i386-pair         4 host-install/dst_host(4) broken REGR. vs. 14076
 test-amd64-i386-pair         3 host-install/src_host(3) broken REGR. vs. 14076
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 14076
 test-amd64-amd64-xl-qemuu-win7-amd64  3 host-install(3) broken REGR. vs. 14076
 test-amd64-i386-xend-winxpsp3  3 host-install(3)        broken REGR. vs. 14076
 test-amd64-i386-xl-win7-amd64  3 host-install(3)        broken REGR. vs. 14076
 test-amd64-i386-xl-winxpsp3-vcpus1  3 host-install(3)   broken REGR. vs. 14076
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 14076
 test-amd64-i386-win           3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 14076
 test-amd64-amd64-xl-win       3 host-install(3)         broken REGR. vs. 14076

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-pv           3 host-install(3)           broken pass in 14117
 test-amd64-i386-rhel6hvm-amd  3 host-install(3)           broken pass in 14115
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3)     broken pass in 14090
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore           fail pass in 14105
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3)   broken pass in 14094
 test-amd64-amd64-xl           3 host-install(3)           broken pass in 14115
 test-i386-i386-pair           4 host-install/dst_host(4)  broken pass in 14090
 test-i386-i386-pair           3 host-install/src_host(3)  broken pass in 14090
 test-amd64-amd64-xl-sedf      3 host-install(3)           broken pass in 14117
 test-amd64-amd64-pair         3 host-install/src_host(3)  broken pass in 14109
 test-amd64-amd64-pair         4 host-install/dst_host(4)  broken pass in 14109
 test-i386-i386-xl             3 host-install(3)  broken in 14090 pass in 14121
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)  broken in 14090 pass in 14121
 test-amd64-i386-xl-win-vcpus1  3 host-install(3) broken in 14109 pass in 14121

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)      broken REGR. vs. 14076

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  25eda7e7b4e6
baseline version:
 xen                  40ccbee890e1

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla 
  Bastian Blank 
  Chuang Cao 
  George Dunlap 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jason McCarver 
  Joe Jin 
  Keir Fraser 
  Matt Wilson 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Sander Eikelenboom 
  Stefano Stabellini 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          broken  
 test-amd64-i386-xl                                           broken  
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 broken  
 test-amd64-i386-qemuu-rhel6hvm-amd                           broken  
 test-amd64-amd64-xl-qemuu-win7-amd64                         broken  
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         broken  
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        broken  
 test-amd64-i386-pair                                         broken  
 test-i386-i386-pair                                          broken  
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          broken  
 test-amd64-i386-pv                                           broken  
 test-i386-i386-pv                                            broken  
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           broken  
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          broken  
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      broken  
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                broken  
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 612 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 28 16:24:01 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Oct 2012 16:24:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSVe8-00025O-3e; Sun, 28 Oct 2012 16:23:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSVe6-00025J-5d
	for xen-devel@lists.xensource.com; Sun, 28 Oct 2012 16:23:30 +0000
Received: from [85.158.143.35:33113] by server-1.bemta-4.messagelabs.com id
	CC/5D-19134-10C5D805; Sun, 28 Oct 2012 16:23:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1351441408!12861452!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzOTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28446 invoked from network); 28 Oct 2012 16:23:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Oct 2012 16:23:28 -0000
X-IronPort-AV: E=Sophos;i="4.80,667,1344211200"; d="scan'208";a="15451698"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Oct 2012 16:23:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sun, 28 Oct 2012 16:23:26 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TSVe2-0008M3-Nv;
	Sun, 28 Oct 2012 16:23:26 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TSVe2-0005j4-NJ;
	Sun, 28 Oct 2012 16:23:26 +0000
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Sun, 28 Oct 2012 16:23:26 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 14121: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14121 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14121/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pv            3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-pv             3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-xl-multivcpu  3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-xl            3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)       broken REGR. vs. 14076
 test-i386-i386-xl             9 guest-start               fail REGR. vs. 14076
 test-amd64-i386-pair         4 host-install/dst_host(4) broken REGR. vs. 14076
 test-amd64-i386-pair         3 host-install/src_host(3) broken REGR. vs. 14076
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 14076
 test-amd64-amd64-xl-qemuu-win7-amd64  3 host-install(3) broken REGR. vs. 14076
 test-amd64-i386-xend-winxpsp3  3 host-install(3)        broken REGR. vs. 14076
 test-amd64-i386-xl-win7-amd64  3 host-install(3)        broken REGR. vs. 14076
 test-amd64-i386-xl-winxpsp3-vcpus1  3 host-install(3)   broken REGR. vs. 14076
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 14076
 test-amd64-i386-win           3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 14076
 test-amd64-amd64-xl-win       3 host-install(3)         broken REGR. vs. 14076

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-pv           3 host-install(3)           broken pass in 14117
 test-amd64-i386-rhel6hvm-amd  3 host-install(3)           broken pass in 14115
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3)     broken pass in 14090
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore           fail pass in 14105
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3)   broken pass in 14094
 test-amd64-amd64-xl           3 host-install(3)           broken pass in 14115
 test-i386-i386-pair           4 host-install/dst_host(4)  broken pass in 14090
 test-i386-i386-pair           3 host-install/src_host(3)  broken pass in 14090
 test-amd64-amd64-xl-sedf      3 host-install(3)           broken pass in 14117
 test-amd64-amd64-pair         3 host-install/src_host(3)  broken pass in 14109
 test-amd64-amd64-pair         4 host-install/dst_host(4)  broken pass in 14109
 test-i386-i386-xl             3 host-install(3)  broken in 14090 pass in 14121
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)  broken in 14090 pass in 14121
 test-amd64-i386-xl-win-vcpus1  3 host-install(3) broken in 14109 pass in 14121

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)      broken REGR. vs. 14076

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  25eda7e7b4e6
baseline version:
 xen                  40ccbee890e1

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla 
  Bastian Blank 
  Chuang Cao 
  George Dunlap 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jason McCarver 
  Joe Jin 
  Keir Fraser 
  Matt Wilson 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Sander Eikelenboom 
  Stefano Stabellini 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          broken  
 test-amd64-i386-xl                                           broken  
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 broken  
 test-amd64-i386-qemuu-rhel6hvm-amd                           broken  
 test-amd64-amd64-xl-qemuu-win7-amd64                         broken  
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         broken  
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        broken  
 test-amd64-i386-pair                                         broken  
 test-i386-i386-pair                                          broken  
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          broken  
 test-amd64-i386-pv                                           broken  
 test-i386-i386-pv                                            broken  
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           broken  
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          broken  
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      broken  
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                broken  
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 612 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 28 18:05:33 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Oct 2012 18:05:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSXEI-0002jN-41; Sun, 28 Oct 2012 18:04:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSWuk-0002aJ-95
	for xen-devel@lists.xensource.com; Sun, 28 Oct 2012 17:44:46 +0000
Received: from [85.158.137.99:50277] by server-12.bemta-3.messagelabs.com id
	3A/F3-27853-D0F6D805; Sun, 28 Oct 2012 17:44:45 +0000
X-Env-Sender: hannes@stressinduktion.org
X-Msg-Ref: server-6.tower-217.messagelabs.com!1351446284!12711910!1
X-Originating-IP: [87.106.68.36]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1586 invoked from network); 28 Oct 2012 17:44:44 -0000
Received: from order.stressinduktion.org (HELO order.stressinduktion.org)
	(87.106.68.36)
	by server-6.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Oct 2012 17:44:44 -0000
Received: by order.stressinduktion.org (Postfix, from userid 500)
	id BEE901A0CCAA; Sun, 28 Oct 2012 18:44:41 +0100 (CET)
Date: Sun, 28 Oct 2012 18:44:41 +0100
From: Hannes Frederic Sowa 
To: xen-devel@lists.xensource.com
Message-ID: <20121028174441.GA30893@order.stressinduktion.org>
Mime-Version: 1.0
Content-Disposition: inline
X-Mailman-Approved-At: Sun, 28 Oct 2012 18:04:57 +0000
Cc: Jan Beulich 
Subject: [Xen-devel] [PATCH] dbgp: fix compile error on building
	EARLY_PRINTK_DBGP without USB_SUPPORT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch fixes following compile error:

drivers/built-in.o: In function `dbgp_reset_prep':
linux/drivers/usb/early/ehci-dbgp.c:984: undefined reference to `xen_dbgp_reset_prep'
drivers/built-in.o: In function `dbgp_external_startup':
linux/drivers/usb/early/ehci-dbgp.c:619: undefined reference to `xen_dbgp_external_startup'

EARLY_PRINTK_DBGP should work without USB_SUPPORT.

Cc: Jan Beulich 
Signed-off-by: Hannes Frederic Sowa 
---
 drivers/xen/Kconfig          | 3 +++
 drivers/xen/Makefile         | 2 +-
 include/linux/usb/ehci_def.h | 2 +-
 3 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 126d8ce..9bb3420 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -206,4 +206,7 @@ config XEN_MCE_LOG
 	  Allow kernel fetching MCE error from Xen platform and
 	  converting it into Linux mcelog format for mcelog tools
 
+config XEN_DBGP
+	def_bool y if XEN_DOM0 && (USB_SUPPORT || EARLY_PRINTK_DBGP)
+
 endmenu
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 0e863703..d23ed07 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -9,7 +9,7 @@ nostackp := $(call cc-option, -fno-stack-protector)
 CFLAGS_features.o			:= $(nostackp)
 
 dom0-$(CONFIG_PCI) += pci.o
-dom0-$(CONFIG_USB_SUPPORT) += dbgp.o
+dom0-$(CONFIG_XEN_DBGP) += dbgp.o
 dom0-$(CONFIG_ACPI) += acpi.o
 dom0-$(CONFIG_X86) += pcpu.o
 obj-$(CONFIG_XEN_DOM0)			+= $(dom0-y)
diff --git a/include/linux/usb/ehci_def.h b/include/linux/usb/ehci_def.h
index daec99a..7d8f7fe 100644
--- a/include/linux/usb/ehci_def.h
+++ b/include/linux/usb/ehci_def.h
@@ -223,7 +223,7 @@ extern struct console early_dbgp_console;
 
 struct usb_hcd;
 
-#ifdef CONFIG_XEN_DOM0
+#ifdef CONFIG_XEN_DBGP
 extern int xen_dbgp_reset_prep(struct usb_hcd *);
 extern int xen_dbgp_external_startup(struct usb_hcd *);
 #else

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 28 18:05:33 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Oct 2012 18:05:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSXEI-0002jN-41; Sun, 28 Oct 2012 18:04:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSWuk-0002aJ-95
	for xen-devel@lists.xensource.com; Sun, 28 Oct 2012 17:44:46 +0000
Received: from [85.158.137.99:50277] by server-12.bemta-3.messagelabs.com id
	3A/F3-27853-D0F6D805; Sun, 28 Oct 2012 17:44:45 +0000
X-Env-Sender: hannes@stressinduktion.org
X-Msg-Ref: server-6.tower-217.messagelabs.com!1351446284!12711910!1
X-Originating-IP: [87.106.68.36]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1586 invoked from network); 28 Oct 2012 17:44:44 -0000
Received: from order.stressinduktion.org (HELO order.stressinduktion.org)
	(87.106.68.36)
	by server-6.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Oct 2012 17:44:44 -0000
Received: by order.stressinduktion.org (Postfix, from userid 500)
	id BEE901A0CCAA; Sun, 28 Oct 2012 18:44:41 +0100 (CET)
Date: Sun, 28 Oct 2012 18:44:41 +0100
From: Hannes Frederic Sowa 
To: xen-devel@lists.xensource.com
Message-ID: <20121028174441.GA30893@order.stressinduktion.org>
Mime-Version: 1.0
Content-Disposition: inline
X-Mailman-Approved-At: Sun, 28 Oct 2012 18:04:57 +0000
Cc: Jan Beulich 
Subject: [Xen-devel] [PATCH] dbgp: fix compile error on building
	EARLY_PRINTK_DBGP without USB_SUPPORT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch fixes following compile error:

drivers/built-in.o: In function `dbgp_reset_prep':
linux/drivers/usb/early/ehci-dbgp.c:984: undefined reference to `xen_dbgp_reset_prep'
drivers/built-in.o: In function `dbgp_external_startup':
linux/drivers/usb/early/ehci-dbgp.c:619: undefined reference to `xen_dbgp_external_startup'

EARLY_PRINTK_DBGP should work without USB_SUPPORT.

Cc: Jan Beulich 
Signed-off-by: Hannes Frederic Sowa 
---
 drivers/xen/Kconfig          | 3 +++
 drivers/xen/Makefile         | 2 +-
 include/linux/usb/ehci_def.h | 2 +-
 3 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 126d8ce..9bb3420 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -206,4 +206,7 @@ config XEN_MCE_LOG
 	  Allow kernel fetching MCE error from Xen platform and
 	  converting it into Linux mcelog format for mcelog tools
 
+config XEN_DBGP
+	def_bool y if XEN_DOM0 && (USB_SUPPORT || EARLY_PRINTK_DBGP)
+
 endmenu
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 0e863703..d23ed07 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -9,7 +9,7 @@ nostackp := $(call cc-option, -fno-stack-protector)
 CFLAGS_features.o			:= $(nostackp)
 
 dom0-$(CONFIG_PCI) += pci.o
-dom0-$(CONFIG_USB_SUPPORT) += dbgp.o
+dom0-$(CONFIG_XEN_DBGP) += dbgp.o
 dom0-$(CONFIG_ACPI) += acpi.o
 dom0-$(CONFIG_X86) += pcpu.o
 obj-$(CONFIG_XEN_DOM0)			+= $(dom0-y)
diff --git a/include/linux/usb/ehci_def.h b/include/linux/usb/ehci_def.h
index daec99a..7d8f7fe 100644
--- a/include/linux/usb/ehci_def.h
+++ b/include/linux/usb/ehci_def.h
@@ -223,7 +223,7 @@ extern struct console early_dbgp_console;
 
 struct usb_hcd;
 
-#ifdef CONFIG_XEN_DOM0
+#ifdef CONFIG_XEN_DBGP
 extern int xen_dbgp_reset_prep(struct usb_hcd *);
 extern int xen_dbgp_external_startup(struct usb_hcd *);
 #else

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 28 18:14:15 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Oct 2012 18:14:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSXMl-0002ti-4h; Sun, 28 Oct 2012 18:13:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSXMj-0002tc-Qn
	for xen-devel@lists.xensource.com; Sun, 28 Oct 2012 18:13:42 +0000
Received: from [85.158.139.211:13668] by server-13.bemta-5.messagelabs.com id
	73/CC-27809-5D57D805; Sun, 28 Oct 2012 18:13:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1351448020!20052947!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzOTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4719 invoked from network); 28 Oct 2012 18:13:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Oct 2012 18:13:40 -0000
X-IronPort-AV: E=Sophos;i="4.80,667,1344211200"; d="scan'208";a="15452114"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Oct 2012 18:13:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sun, 28 Oct 2012 18:13:39 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TSXMh-0000US-8q;
	Sun, 28 Oct 2012 18:13:39 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TSXMh-0003qf-8S;
	Sun, 28 Oct 2012 18:13:39 +0000
To: 
Message-ID: 
From: xen.org 
Date: Sun, 28 Oct 2012 18:13:39 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 14127: trouble: blocked/broken
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14127 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14127/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386                    2 host-install(2)         broken REGR. vs. 13919
 build-amd64                   2 host-install(2)         broken REGR. vs. 13919
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 13919
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13919
 build-i386-pvops              2 host-install(2)         broken REGR. vs. 13919
 build-i386-oldkern            2 host-install(2)         broken REGR. vs. 13919

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 xen                  69d1cc78a5bd
baseline version:
 xen                  a15596a619ed

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           broken  
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             broken  
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   23385:69d1cc78a5bd
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:10:04 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    [ Includes 25589:60f09d1ab1fe for CVE-2012-2625 ]
    
    
changeset:   23384:a15596a619ed
user:        Daniel De Graaf 
date:        Thu Oct 04 10:44:43 2012 +0200
    
    x86: check remote MMIO remap permissions
    
    When a domain is mapping pages from a different pg_owner domain, the
    iomem_access checks are currently only applied to the pg_owner domain,
    potentially allowing a domain with a more restrictive iomem_access
    policy to have the pages mapped into its page tables. To catch this,
    also check the owner of the page tables. The current domain does not
    need to be checked because the ability to manipulate a domain's page
    tables implies full access to the target domain, so checking that
    domain's permission is sufficient.
    
    Signed-off-by: Daniel De Graaf 
    Acked-by: Jan Beulich 
    xen-unstable changeset: 25952:8278d7d8fa48
    xen-unstable date: Wed Sep 26 09:56:07 UTC 2012
    
    
========================================
commit d7d453f51459b591faa96d1c123b5bfff7c5b6b6
Author: Ian Jackson 
Date:   Thu Sep 6 17:05:30 2012 +0100

    Disable qemu monitor by default.  The qemu monitor is an overly
    powerful feature which must be protected from untrusted (guest)
    administrators.
    
    Neither xl nor xend expect qemu to produce this monitor unless it is
    explicitly requested.
    
    This is a security problem, XSA-19.  Previously it was CVE-2007-0998
    in Red Hat but we haven't dealt with it in upstream.  We hope to have
    a new CVE for it here but we don't have one yet.
    
    Signed-off-by: Ian Jackson 
    (cherry picked from commit bacc0d302445c75f18f4c826750fb5853b60e7ca)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 28 18:14:15 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Oct 2012 18:14:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSXMl-0002ti-4h; Sun, 28 Oct 2012 18:13:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSXMj-0002tc-Qn
	for xen-devel@lists.xensource.com; Sun, 28 Oct 2012 18:13:42 +0000
Received: from [85.158.139.211:13668] by server-13.bemta-5.messagelabs.com id
	73/CC-27809-5D57D805; Sun, 28 Oct 2012 18:13:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1351448020!20052947!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzOTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4719 invoked from network); 28 Oct 2012 18:13:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Oct 2012 18:13:40 -0000
X-IronPort-AV: E=Sophos;i="4.80,667,1344211200"; d="scan'208";a="15452114"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Oct 2012 18:13:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sun, 28 Oct 2012 18:13:39 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TSXMh-0000US-8q;
	Sun, 28 Oct 2012 18:13:39 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TSXMh-0003qf-8S;
	Sun, 28 Oct 2012 18:13:39 +0000
To: 
Message-ID: 
From: xen.org 
Date: Sun, 28 Oct 2012 18:13:39 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 14127: trouble: blocked/broken
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14127 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14127/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386                    2 host-install(2)         broken REGR. vs. 13919
 build-amd64                   2 host-install(2)         broken REGR. vs. 13919
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 13919
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13919
 build-i386-pvops              2 host-install(2)         broken REGR. vs. 13919
 build-i386-oldkern            2 host-install(2)         broken REGR. vs. 13919

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 xen                  69d1cc78a5bd
baseline version:
 xen                  a15596a619ed

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           broken  
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             broken  
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   23385:69d1cc78a5bd
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:10:04 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    [ Includes 25589:60f09d1ab1fe for CVE-2012-2625 ]
    
    
changeset:   23384:a15596a619ed
user:        Daniel De Graaf 
date:        Thu Oct 04 10:44:43 2012 +0200
    
    x86: check remote MMIO remap permissions
    
    When a domain is mapping pages from a different pg_owner domain, the
    iomem_access checks are currently only applied to the pg_owner domain,
    potentially allowing a domain with a more restrictive iomem_access
    policy to have the pages mapped into its page tables. To catch this,
    also check the owner of the page tables. The current domain does not
    need to be checked because the ability to manipulate a domain's page
    tables implies full access to the target domain, so checking that
    domain's permission is sufficient.
    
    Signed-off-by: Daniel De Graaf 
    Acked-by: Jan Beulich 
    xen-unstable changeset: 25952:8278d7d8fa48
    xen-unstable date: Wed Sep 26 09:56:07 UTC 2012
    
    
========================================
commit d7d453f51459b591faa96d1c123b5bfff7c5b6b6
Author: Ian Jackson 
Date:   Thu Sep 6 17:05:30 2012 +0100

    Disable qemu monitor by default.  The qemu monitor is an overly
    powerful feature which must be protected from untrusted (guest)
    administrators.
    
    Neither xl nor xend expect qemu to produce this monitor unless it is
    explicitly requested.
    
    This is a security problem, XSA-19.  Previously it was CVE-2007-0998
    in Red Hat but we haven't dealt with it in upstream.  We hope to have
    a new CVE for it here but we don't have one yet.
    
    Signed-off-by: Ian Jackson 
    (cherry picked from commit bacc0d302445c75f18f4c826750fb5853b60e7ca)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 28 19:32:57 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Oct 2012 19:32:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSYat-0003NK-Al; Sun, 28 Oct 2012 19:32:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSYaq-0003NF-Nk
	for xen-devel@lists.xensource.com; Sun, 28 Oct 2012 19:32:21 +0000
Received: from [85.158.143.35:16699] by server-3.bemta-4.messagelabs.com id
	08/8B-24279-4488D805; Sun, 28 Oct 2012 19:32:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1351452737!13541903!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzOTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2648 invoked from network); 28 Oct 2012 19:32:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Oct 2012 19:32:17 -0000
X-IronPort-AV: E=Sophos;i="4.80,667,1344211200"; d="scan'208";a="15452399"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Oct 2012 19:32:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sun, 28 Oct 2012 19:32:16 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TSYam-0000u9-DI;
	Sun, 28 Oct 2012 19:32:16 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TSYam-0005oC-CF;
	Sun, 28 Oct 2012 19:32:16 +0000
To: 
Message-ID: 
From: xen.org 
Date: Sun, 28 Oct 2012 19:32:16 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14128: trouble: blocked/broken/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14128 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14128/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   2 host-install(2)         broken REGR. vs. 14079
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 14079
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 14079

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a

version targeted for testing:
 xen                  37a8946eeb9d
baseline version:
 xen                  c26e1a79fe77

------------------------------------------------------------
People who touched revisions under test:
  Charles Arnold 
  Christoph Egger 
  Ian Campbell 
  Ian Jackson 
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   pass    
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26115:37a8946eeb9d
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:09:29 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    
    
changeset:   26114:6f9e46917eb8
user:        Charles Arnold 
date:        Fri Oct 26 12:05:08 2012 +0100
    
    pygrub: Add option to list grub entries
    
    The argument to "--entry" allows 2 syntaxes, either directly the entry
    number in menu.lst, or the whole string behind the "title" key word.
    This poses the following issue:
    
    From Dom0 there is no way to guess the number and, or the complete
    title string because this string contains the kernel version, which
    will change with a kernel update.
    
    This patch adds [-l|--list-entries] as an argument to pygrub.
    
    Signed-off-by: Charles Arnold 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26113:03af0abd2b72
user:        Ian Campbell 
date:        Fri Oct 26 12:03:12 2012 +0100
    
    xl: Do not leak events when a domain exits.
    
    The goto in both of these places misses the event free which would
    normally clean up.
    
    ==8655== 80 bytes in 1 blocks are definitely lost in loss record 1 of 1
    ==8655==    at 0x4024370: calloc (vg_replace_malloc.c:593)
    ==8655==    by 0x406EAAE: libxl__zalloc (libxl_internal.c:83)
    ==8655==    by 0x4078173: libxl__event_new (libxl_event.c:1167)
    ==8655==    by 0x4056373: domain_death_occurred (libxl.c:958)
    ==8655==    by 0x4058D06: domain_death_xswatch_callback (libxl.c:1038)
    ==8655==    by 0x4078EB5: watchfd_callback (libxl_event.c:458)
    ==8655==    by 0x407839E: afterpoll_internal (libxl_event.c:949)
    ==8655==    by 0x4079142: eventloop_iteration (libxl_event.c:1371)
    ==8655==    by 0x40799BB: libxl_event_wait (libxl_event.c:1396)
    ==8655==    by 0x805CC67: create_domain (xl_cmdimpl.c:1698)
    ==8655==    by 0x805E001: main_create (xl_cmdimpl.c:3986)
    ==8655==    by 0x804D43D: main (xl.c:285)
    
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26112:d07692b5c780
user:        Ian Jackson 
date:        Fri Oct 26 11:39:42 2012 +0100
    
    Revert 26109:6ccfe4d29f95
    
    This changeset was contaminated by changes hanging around in my
    working tree.  Sorry :-(.
    
    Signed-off-by: Ian Jackson 
    
    
changeset:   26111:c26e1a79fe77
user:        Christoph Egger 
date:        Thu Oct 25 17:12:55 2012 +0100
    
    libxl: NetBSD PCI passthrough support
    
    Add PCI passthrough support for HVM guests.
    
    Signed-off-by: Christoph Egger 
    Committed-by: Ian Jackson 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 28 19:32:57 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Oct 2012 19:32:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSYat-0003NK-Al; Sun, 28 Oct 2012 19:32:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSYaq-0003NF-Nk
	for xen-devel@lists.xensource.com; Sun, 28 Oct 2012 19:32:21 +0000
Received: from [85.158.143.35:16699] by server-3.bemta-4.messagelabs.com id
	08/8B-24279-4488D805; Sun, 28 Oct 2012 19:32:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1351452737!13541903!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzOTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2648 invoked from network); 28 Oct 2012 19:32:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Oct 2012 19:32:17 -0000
X-IronPort-AV: E=Sophos;i="4.80,667,1344211200"; d="scan'208";a="15452399"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Oct 2012 19:32:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sun, 28 Oct 2012 19:32:16 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TSYam-0000u9-DI;
	Sun, 28 Oct 2012 19:32:16 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TSYam-0005oC-CF;
	Sun, 28 Oct 2012 19:32:16 +0000
To: 
Message-ID: 
From: xen.org 
Date: Sun, 28 Oct 2012 19:32:16 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14128: trouble: blocked/broken/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14128 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14128/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   2 host-install(2)         broken REGR. vs. 14079
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 14079
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 14079

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a

version targeted for testing:
 xen                  37a8946eeb9d
baseline version:
 xen                  c26e1a79fe77

------------------------------------------------------------
People who touched revisions under test:
  Charles Arnold 
  Christoph Egger 
  Ian Campbell 
  Ian Jackson 
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   pass    
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26115:37a8946eeb9d
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:09:29 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    
    
changeset:   26114:6f9e46917eb8
user:        Charles Arnold 
date:        Fri Oct 26 12:05:08 2012 +0100
    
    pygrub: Add option to list grub entries
    
    The argument to "--entry" allows 2 syntaxes, either directly the entry
    number in menu.lst, or the whole string behind the "title" key word.
    This poses the following issue:
    
    From Dom0 there is no way to guess the number and, or the complete
    title string because this string contains the kernel version, which
    will change with a kernel update.
    
    This patch adds [-l|--list-entries] as an argument to pygrub.
    
    Signed-off-by: Charles Arnold 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26113:03af0abd2b72
user:        Ian Campbell 
date:        Fri Oct 26 12:03:12 2012 +0100
    
    xl: Do not leak events when a domain exits.
    
    The goto in both of these places misses the event free which would
    normally clean up.
    
    ==8655== 80 bytes in 1 blocks are definitely lost in loss record 1 of 1
    ==8655==    at 0x4024370: calloc (vg_replace_malloc.c:593)
    ==8655==    by 0x406EAAE: libxl__zalloc (libxl_internal.c:83)
    ==8655==    by 0x4078173: libxl__event_new (libxl_event.c:1167)
    ==8655==    by 0x4056373: domain_death_occurred (libxl.c:958)
    ==8655==    by 0x4058D06: domain_death_xswatch_callback (libxl.c:1038)
    ==8655==    by 0x4078EB5: watchfd_callback (libxl_event.c:458)
    ==8655==    by 0x407839E: afterpoll_internal (libxl_event.c:949)
    ==8655==    by 0x4079142: eventloop_iteration (libxl_event.c:1371)
    ==8655==    by 0x40799BB: libxl_event_wait (libxl_event.c:1396)
    ==8655==    by 0x805CC67: create_domain (xl_cmdimpl.c:1698)
    ==8655==    by 0x805E001: main_create (xl_cmdimpl.c:3986)
    ==8655==    by 0x804D43D: main (xl.c:285)
    
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26112:d07692b5c780
user:        Ian Jackson 
date:        Fri Oct 26 11:39:42 2012 +0100
    
    Revert 26109:6ccfe4d29f95
    
    This changeset was contaminated by changes hanging around in my
    working tree.  Sorry :-(.
    
    Signed-off-by: Ian Jackson 
    
    
changeset:   26111:c26e1a79fe77
user:        Christoph Egger 
date:        Thu Oct 25 17:12:55 2012 +0100
    
    libxl: NetBSD PCI passthrough support
    
    Add PCI passthrough support for HVM guests.
    
    Signed-off-by: Christoph Egger 
    Committed-by: Ian Jackson 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 28 20:35:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Oct 2012 20:35:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSZZX-0003t8-Av; Sun, 28 Oct 2012 20:35:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSZZV-0003t3-TU
	for xen-devel@lists.xensource.com; Sun, 28 Oct 2012 20:35:02 +0000
Received: from [85.158.138.51:13509] by server-10.bemta-3.messagelabs.com id
	0A/75-00901-5F69D805; Sun, 28 Oct 2012 20:35:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1351456500!18845820!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzOTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28145 invoked from network); 28 Oct 2012 20:35:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Oct 2012 20:35:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,667,1344211200"; d="scan'208";a="15452616"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Oct 2012 20:34:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sun, 28 Oct 2012 20:34:23 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TSZYt-0001Du-05;
	Sun, 28 Oct 2012 20:34:23 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TSZYs-00009i-Vv;
	Sun, 28 Oct 2012 20:34:22 +0000
To: 
Message-ID: 
From: xen.org 
Date: Sun, 28 Oct 2012 20:34:22 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 14125: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14125 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14125/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pv            3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-xl-multivcpu  3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-xl            3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-xl             9 guest-start               fail REGR. vs. 14076
 test-amd64-i386-pair         4 host-install/dst_host(4) broken REGR. vs. 14076
 test-amd64-i386-pair         3 host-install/src_host(3) broken REGR. vs. 14076
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 14076
 test-amd64-amd64-xl-qemuu-win7-amd64  3 host-install(3) broken REGR. vs. 14076
 test-amd64-i386-xend-winxpsp3  3 host-install(3)        broken REGR. vs. 14076
 test-amd64-i386-xl-win7-amd64  3 host-install(3)        broken REGR. vs. 14076
 test-amd64-i386-xl-winxpsp3-vcpus1  3 host-install(3)   broken REGR. vs. 14076
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 14076
 test-amd64-i386-win           3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 14076
 test-amd64-amd64-xl-win       3 host-install(3)         broken REGR. vs. 14076

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-pv           3 host-install(3)           broken pass in 14117
 test-amd64-i386-rhel6hvm-amd  3 host-install(3)           broken pass in 14115
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3)     broken pass in 14090
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore           fail pass in 14105
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3)   broken pass in 14094
 test-amd64-amd64-xl           3 host-install(3)           broken pass in 14115
 test-i386-i386-pair           4 host-install/dst_host(4)  broken pass in 14090
 test-i386-i386-pair           3 host-install/src_host(3)  broken pass in 14090
 test-amd64-amd64-xl-sedf      3 host-install(3)           broken pass in 14117
 test-amd64-amd64-pair         3 host-install/src_host(3)  broken pass in 14109
 test-amd64-amd64-pair         4 host-install/dst_host(4)  broken pass in 14109
 test-i386-i386-pv             3 host-install(3)  broken in 14117 pass in 14125
 test-amd64-i386-rhel6hvm-intel 3 host-install(3) broken in 14117 pass in 14125
 test-i386-i386-xl             3 host-install(3)  broken in 14090 pass in 14125
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)  broken in 14090 pass in 14125
 test-amd64-i386-xl-win-vcpus1  3 host-install(3) broken in 14109 pass in 14125

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)      broken REGR. vs. 14076

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  25eda7e7b4e6
baseline version:
 xen                  40ccbee890e1

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla 
  Bastian Blank 
  Chuang Cao 
  George Dunlap 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jason McCarver 
  Joe Jin 
  Keir Fraser 
  Matt Wilson 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Sander Eikelenboom 
  Stefano Stabellini 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          broken  
 test-amd64-i386-xl                                           broken  
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 broken  
 test-amd64-i386-qemuu-rhel6hvm-amd                           broken  
 test-amd64-amd64-xl-qemuu-win7-amd64                         broken  
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         broken  
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        broken  
 test-amd64-i386-pair                                         broken  
 test-i386-i386-pair                                          broken  
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          broken  
 test-amd64-i386-pv                                           broken  
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           broken  
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          broken  
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      broken  
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                broken  
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 612 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 28 20:35:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Oct 2012 20:35:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSZZX-0003t8-Av; Sun, 28 Oct 2012 20:35:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSZZV-0003t3-TU
	for xen-devel@lists.xensource.com; Sun, 28 Oct 2012 20:35:02 +0000
Received: from [85.158.138.51:13509] by server-10.bemta-3.messagelabs.com id
	0A/75-00901-5F69D805; Sun, 28 Oct 2012 20:35:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1351456500!18845820!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzOTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28145 invoked from network); 28 Oct 2012 20:35:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Oct 2012 20:35:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,667,1344211200"; d="scan'208";a="15452616"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Oct 2012 20:34:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sun, 28 Oct 2012 20:34:23 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TSZYt-0001Du-05;
	Sun, 28 Oct 2012 20:34:23 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TSZYs-00009i-Vv;
	Sun, 28 Oct 2012 20:34:22 +0000
To: 
Message-ID: 
From: xen.org 
Date: Sun, 28 Oct 2012 20:34:22 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 14125: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14125 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14125/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pv            3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-xl-multivcpu  3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-xl            3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-xl             9 guest-start               fail REGR. vs. 14076
 test-amd64-i386-pair         4 host-install/dst_host(4) broken REGR. vs. 14076
 test-amd64-i386-pair         3 host-install/src_host(3) broken REGR. vs. 14076
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 14076
 test-amd64-amd64-xl-qemuu-win7-amd64  3 host-install(3) broken REGR. vs. 14076
 test-amd64-i386-xend-winxpsp3  3 host-install(3)        broken REGR. vs. 14076
 test-amd64-i386-xl-win7-amd64  3 host-install(3)        broken REGR. vs. 14076
 test-amd64-i386-xl-winxpsp3-vcpus1  3 host-install(3)   broken REGR. vs. 14076
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 14076
 test-amd64-i386-win           3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 14076
 test-amd64-amd64-xl-win       3 host-install(3)         broken REGR. vs. 14076

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-pv           3 host-install(3)           broken pass in 14117
 test-amd64-i386-rhel6hvm-amd  3 host-install(3)           broken pass in 14115
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3)     broken pass in 14090
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore           fail pass in 14105
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3)   broken pass in 14094
 test-amd64-amd64-xl           3 host-install(3)           broken pass in 14115
 test-i386-i386-pair           4 host-install/dst_host(4)  broken pass in 14090
 test-i386-i386-pair           3 host-install/src_host(3)  broken pass in 14090
 test-amd64-amd64-xl-sedf      3 host-install(3)           broken pass in 14117
 test-amd64-amd64-pair         3 host-install/src_host(3)  broken pass in 14109
 test-amd64-amd64-pair         4 host-install/dst_host(4)  broken pass in 14109
 test-i386-i386-pv             3 host-install(3)  broken in 14117 pass in 14125
 test-amd64-i386-rhel6hvm-intel 3 host-install(3) broken in 14117 pass in 14125
 test-i386-i386-xl             3 host-install(3)  broken in 14090 pass in 14125
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)  broken in 14090 pass in 14125
 test-amd64-i386-xl-win-vcpus1  3 host-install(3) broken in 14109 pass in 14125

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)      broken REGR. vs. 14076

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  25eda7e7b4e6
baseline version:
 xen                  40ccbee890e1

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla 
  Bastian Blank 
  Chuang Cao 
  George Dunlap 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jason McCarver 
  Joe Jin 
  Keir Fraser 
  Matt Wilson 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Sander Eikelenboom 
  Stefano Stabellini 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          broken  
 test-amd64-i386-xl                                           broken  
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 broken  
 test-amd64-i386-qemuu-rhel6hvm-amd                           broken  
 test-amd64-amd64-xl-qemuu-win7-amd64                         broken  
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         broken  
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        broken  
 test-amd64-i386-pair                                         broken  
 test-i386-i386-pair                                          broken  
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          broken  
 test-amd64-i386-pv                                           broken  
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           broken  
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          broken  
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      broken  
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                broken  
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 612 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 28 23:21:59 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Oct 2012 23:21:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TScAX-0004or-Rp; Sun, 28 Oct 2012 23:21:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TScAW-0004om-76
	for xen-devel@lists.xensource.com; Sun, 28 Oct 2012 23:21:24 +0000
Received: from [193.109.254.147:4700] by server-10.bemta-14.messagelabs.com id
	0A/36-31741-3FDBD805; Sun, 28 Oct 2012 23:21:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1351466482!8770191!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzOTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20505 invoked from network); 28 Oct 2012 23:21:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Oct 2012 23:21:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,668,1344211200"; d="scan'208";a="15453003"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Oct 2012 23:21:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sun, 28 Oct 2012 23:21:21 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TScAT-00025a-9C;
	Sun, 28 Oct 2012 23:21:21 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TScAT-0001OU-14;
	Sun, 28 Oct 2012 23:21:21 +0000
To: 
Message-ID: 
From: xen.org 
Date: Sun, 28 Oct 2012 23:21:21 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 14130: trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14130 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14130/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl-qemuu-winxpsp3  3 host-install(3)     broken REGR. vs. 13919
 test-i386-i386-win            3 host-install(3)         broken REGR. vs. 13919
 test-i386-i386-pair          4 host-install/dst_host(4) broken REGR. vs. 13919
 test-i386-i386-pair          3 host-install/src_host(3) broken REGR. vs. 13919
 build-amd64                   2 host-install(2)         broken REGR. vs. 13919
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 13919
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13919

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 xen                  69d1cc78a5bd
baseline version:
 xen                  a15596a619ed

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   pass    
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          broken  
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           broken  
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             broken  
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   23385:69d1cc78a5bd
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:10:04 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    [ Includes 25589:60f09d1ab1fe for CVE-2012-2625 ]
    
    
changeset:   23384:a15596a619ed
user:        Daniel De Graaf 
date:        Thu Oct 04 10:44:43 2012 +0200
    
    x86: check remote MMIO remap permissions
    
    When a domain is mapping pages from a different pg_owner domain, the
    iomem_access checks are currently only applied to the pg_owner domain,
    potentially allowing a domain with a more restrictive iomem_access
    policy to have the pages mapped into its page tables. To catch this,
    also check the owner of the page tables. The current domain does not
    need to be checked because the ability to manipulate a domain's page
    tables implies full access to the target domain, so checking that
    domain's permission is sufficient.
    
    Signed-off-by: Daniel De Graaf 
    Acked-by: Jan Beulich 
    xen-unstable changeset: 25952:8278d7d8fa48
    xen-unstable date: Wed Sep 26 09:56:07 UTC 2012
    
    
========================================
commit d7d453f51459b591faa96d1c123b5bfff7c5b6b6
Author: Ian Jackson 
Date:   Thu Sep 6 17:05:30 2012 +0100

    Disable qemu monitor by default.  The qemu monitor is an overly
    powerful feature which must be protected from untrusted (guest)
    administrators.
    
    Neither xl nor xend expect qemu to produce this monitor unless it is
    explicitly requested.
    
    This is a security problem, XSA-19.  Previously it was CVE-2007-0998
    in Red Hat but we haven't dealt with it in upstream.  We hope to have
    a new CVE for it here but we don't have one yet.
    
    Signed-off-by: Ian Jackson 
    (cherry picked from commit bacc0d302445c75f18f4c826750fb5853b60e7ca)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Oct 28 23:21:59 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 28 Oct 2012 23:21:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TScAX-0004or-Rp; Sun, 28 Oct 2012 23:21:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TScAW-0004om-76
	for xen-devel@lists.xensource.com; Sun, 28 Oct 2012 23:21:24 +0000
Received: from [193.109.254.147:4700] by server-10.bemta-14.messagelabs.com id
	0A/36-31741-3FDBD805; Sun, 28 Oct 2012 23:21:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1351466482!8770191!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzOTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20505 invoked from network); 28 Oct 2012 23:21:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Oct 2012 23:21:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,668,1344211200"; d="scan'208";a="15453003"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Oct 2012 23:21:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sun, 28 Oct 2012 23:21:21 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TScAT-00025a-9C;
	Sun, 28 Oct 2012 23:21:21 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TScAT-0001OU-14;
	Sun, 28 Oct 2012 23:21:21 +0000
To: 
Message-ID: 
From: xen.org 
Date: Sun, 28 Oct 2012 23:21:21 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 14130: trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14130 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14130/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl-qemuu-winxpsp3  3 host-install(3)     broken REGR. vs. 13919
 test-i386-i386-win            3 host-install(3)         broken REGR. vs. 13919
 test-i386-i386-pair          4 host-install/dst_host(4) broken REGR. vs. 13919
 test-i386-i386-pair          3 host-install/src_host(3) broken REGR. vs. 13919
 build-amd64                   2 host-install(2)         broken REGR. vs. 13919
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 13919
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13919

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 xen                  69d1cc78a5bd
baseline version:
 xen                  a15596a619ed

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   pass    
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          broken  
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           broken  
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-i386-i386-xl-qemuu-winxpsp3                             broken  
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   23385:69d1cc78a5bd
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:10:04 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    [ Includes 25589:60f09d1ab1fe for CVE-2012-2625 ]
    
    
changeset:   23384:a15596a619ed
user:        Daniel De Graaf 
date:        Thu Oct 04 10:44:43 2012 +0200
    
    x86: check remote MMIO remap permissions
    
    When a domain is mapping pages from a different pg_owner domain, the
    iomem_access checks are currently only applied to the pg_owner domain,
    potentially allowing a domain with a more restrictive iomem_access
    policy to have the pages mapped into its page tables. To catch this,
    also check the owner of the page tables. The current domain does not
    need to be checked because the ability to manipulate a domain's page
    tables implies full access to the target domain, so checking that
    domain's permission is sufficient.
    
    Signed-off-by: Daniel De Graaf 
    Acked-by: Jan Beulich 
    xen-unstable changeset: 25952:8278d7d8fa48
    xen-unstable date: Wed Sep 26 09:56:07 UTC 2012
    
    
========================================
commit d7d453f51459b591faa96d1c123b5bfff7c5b6b6
Author: Ian Jackson 
Date:   Thu Sep 6 17:05:30 2012 +0100

    Disable qemu monitor by default.  The qemu monitor is an overly
    powerful feature which must be protected from untrusted (guest)
    administrators.
    
    Neither xl nor xend expect qemu to produce this monitor unless it is
    explicitly requested.
    
    This is a security problem, XSA-19.  Previously it was CVE-2007-0998
    in Red Hat but we haven't dealt with it in upstream.  We hope to have
    a new CVE for it here but we don't have one yet.
    
    Signed-off-by: Ian Jackson 
    (cherry picked from commit bacc0d302445c75f18f4c826750fb5853b60e7ca)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 01:23:49 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 01:23:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSe4P-0001EQ-6v; Mon, 29 Oct 2012 01:23:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSe4N-0001EL-HU
	for xen-devel@lists.xensource.com; Mon, 29 Oct 2012 01:23:11 +0000
Received: from [85.158.143.35:12008] by server-1.bemta-4.messagelabs.com id
	07/14-19134-E7ADD805; Mon, 29 Oct 2012 01:23:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1351473789!12890818!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzOTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31675 invoked from network); 29 Oct 2012 01:23:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Oct 2012 01:23:10 -0000
X-IronPort-AV: E=Sophos;i="4.80,668,1344211200"; d="scan'208";a="15453531"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Oct 2012 01:23:09 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Mon, 29 Oct 2012 01:23:08 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TSe4K-0002iq-UD;
	Mon, 29 Oct 2012 01:23:08 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TSe4K-0004dL-TL;
	Mon, 29 Oct 2012 01:23:08 +0000
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Mon, 29 Oct 2012 01:23:08 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14131: trouble: broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14131 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14131/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3)   broken REGR. vs. 14079
 test-amd64-amd64-pv           3 host-install(3)         broken REGR. vs. 14079
 test-amd64-i386-xl            3 host-install(3)         broken REGR. vs. 14079
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 14079
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)       broken REGR. vs. 14079
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3) broken REGR. vs. 14079
 test-amd64-i386-xl-win-vcpus1  3 host-install(3)        broken REGR. vs. 14079
 test-amd64-amd64-win          3 host-install(3)         broken REGR. vs. 14079
 test-amd64-i386-xl-multivcpu  3 host-install(3)         broken REGR. vs. 14079
 test-amd64-i386-win-vcpus1    3 host-install(3)         broken REGR. vs. 14079
 test-amd64-i386-xl-win7-amd64  3 host-install(3)        broken REGR. vs. 14079
 test-amd64-amd64-xl-winxpsp3  3 host-install(3)         broken REGR. vs. 14079
 test-amd64-i386-pair         3 host-install/src_host(3) broken REGR. vs. 14079
 test-amd64-i386-pair         4 host-install/dst_host(4) broken REGR. vs. 14079

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-amd  3 host-install(3)           broken pass in 14104
 test-amd64-i386-pv            3 host-install(3)           broken pass in 14104
 test-amd64-amd64-pair         3 host-install/src_host(3)  broken pass in 14104
 test-amd64-amd64-pair         4 host-install/dst_host(4)  broken pass in 14104
 test-amd64-amd64-xl           3 host-install(3)  broken in 14104 pass in 14131

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)      broken REGR. vs. 14079
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 14079
 test-amd64-amd64-xl-sedf      3 host-install(3)         broken REGR. vs. 14079
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 14079
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 14079

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  37a8946eeb9d
baseline version:
 xen                  c26e1a79fe77

------------------------------------------------------------
People who touched revisions under test:
  Charles Arnold 
  Christoph Egger 
  Ian Campbell 
  Ian Jackson 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           broken  
 test-amd64-i386-rhel6hvm-amd                                 broken  
 test-amd64-i386-qemuu-rhel6hvm-amd                           broken  
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         broken  
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        broken  
 test-amd64-i386-pair                                         broken  
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          broken  
 test-amd64-i386-pv                                           broken  
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   broken  
 test-amd64-i386-xl-win-vcpus1                                broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         broken  
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 broken  


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26115:37a8946eeb9d
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:09:29 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    
    
changeset:   26114:6f9e46917eb8
user:        Charles Arnold 
date:        Fri Oct 26 12:05:08 2012 +0100
    
    pygrub: Add option to list grub entries
    
    The argument to "--entry" allows 2 syntaxes, either directly the entry
    number in menu.lst, or the whole string behind the "title" key word.
    This poses the following issue:
    
    From Dom0 there is no way to guess the number and, or the complete
    title string because this string contains the kernel version, which
    will change with a kernel update.
    
    This patch adds [-l|--list-entries] as an argument to pygrub.
    
    Signed-off-by: Charles Arnold 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26113:03af0abd2b72
user:        Ian Campbell 
date:        Fri Oct 26 12:03:12 2012 +0100
    
    xl: Do not leak events when a domain exits.
    
    The goto in both of these places misses the event free which would
    normally clean up.
    
    ==8655== 80 bytes in 1 blocks are definitely lost in loss record 1 of 1
    ==8655==    at 0x4024370: calloc (vg_replace_malloc.c:593)
    ==8655==    by 0x406EAAE: libxl__zalloc (libxl_internal.c:83)
    ==8655==    by 0x4078173: libxl__event_new (libxl_event.c:1167)
    ==8655==    by 0x4056373: domain_death_occurred (libxl.c:958)
    ==8655==    by 0x4058D06: domain_death_xswatch_callback (libxl.c:1038)
    ==8655==    by 0x4078EB5: watchfd_callback (libxl_event.c:458)
    ==8655==    by 0x407839E: afterpoll_internal (libxl_event.c:949)
    ==8655==    by 0x4079142: eventloop_iteration (libxl_event.c:1371)
    ==8655==    by 0x40799BB: libxl_event_wait (libxl_event.c:1396)
    ==8655==    by 0x805CC67: create_domain (xl_cmdimpl.c:1698)
    ==8655==    by 0x805E001: main_create (xl_cmdimpl.c:3986)
    ==8655==    by 0x804D43D: main (xl.c:285)
    
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26112:d07692b5c780
user:        Ian Jackson 
date:        Fri Oct 26 11:39:42 2012 +0100
    
    Revert 26109:6ccfe4d29f95
    
    This changeset was contaminated by changes hanging around in my
    working tree.  Sorry :-(.
    
    Signed-off-by: Ian Jackson 
    
    
changeset:   26111:c26e1a79fe77
user:        Christoph Egger 
date:        Thu Oct 25 17:12:55 2012 +0100
    
    libxl: NetBSD PCI passthrough support
    
    Add PCI passthrough support for HVM guests.
    
    Signed-off-by: Christoph Egger 
    Committed-by: Ian Jackson 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 01:23:49 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 01:23:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSe4P-0001EQ-6v; Mon, 29 Oct 2012 01:23:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSe4N-0001EL-HU
	for xen-devel@lists.xensource.com; Mon, 29 Oct 2012 01:23:11 +0000
Received: from [85.158.143.35:12008] by server-1.bemta-4.messagelabs.com id
	07/14-19134-E7ADD805; Mon, 29 Oct 2012 01:23:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1351473789!12890818!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzOTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31675 invoked from network); 29 Oct 2012 01:23:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Oct 2012 01:23:10 -0000
X-IronPort-AV: E=Sophos;i="4.80,668,1344211200"; d="scan'208";a="15453531"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Oct 2012 01:23:09 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Mon, 29 Oct 2012 01:23:08 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TSe4K-0002iq-UD;
	Mon, 29 Oct 2012 01:23:08 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TSe4K-0004dL-TL;
	Mon, 29 Oct 2012 01:23:08 +0000
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Mon, 29 Oct 2012 01:23:08 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14131: trouble: broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14131 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14131/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3)   broken REGR. vs. 14079
 test-amd64-amd64-pv           3 host-install(3)         broken REGR. vs. 14079
 test-amd64-i386-xl            3 host-install(3)         broken REGR. vs. 14079
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 14079
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)       broken REGR. vs. 14079
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3) broken REGR. vs. 14079
 test-amd64-i386-xl-win-vcpus1  3 host-install(3)        broken REGR. vs. 14079
 test-amd64-amd64-win          3 host-install(3)         broken REGR. vs. 14079
 test-amd64-i386-xl-multivcpu  3 host-install(3)         broken REGR. vs. 14079
 test-amd64-i386-win-vcpus1    3 host-install(3)         broken REGR. vs. 14079
 test-amd64-i386-xl-win7-amd64  3 host-install(3)        broken REGR. vs. 14079
 test-amd64-amd64-xl-winxpsp3  3 host-install(3)         broken REGR. vs. 14079
 test-amd64-i386-pair         3 host-install/src_host(3) broken REGR. vs. 14079
 test-amd64-i386-pair         4 host-install/dst_host(4) broken REGR. vs. 14079

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-amd  3 host-install(3)           broken pass in 14104
 test-amd64-i386-pv            3 host-install(3)           broken pass in 14104
 test-amd64-amd64-pair         3 host-install/src_host(3)  broken pass in 14104
 test-amd64-amd64-pair         4 host-install/dst_host(4)  broken pass in 14104
 test-amd64-amd64-xl           3 host-install(3)  broken in 14104 pass in 14131

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)      broken REGR. vs. 14079
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 14079
 test-amd64-amd64-xl-sedf      3 host-install(3)         broken REGR. vs. 14079
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 14079
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 14079

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  37a8946eeb9d
baseline version:
 xen                  c26e1a79fe77

------------------------------------------------------------
People who touched revisions under test:
  Charles Arnold 
  Christoph Egger 
  Ian Campbell 
  Ian Jackson 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           broken  
 test-amd64-i386-rhel6hvm-amd                                 broken  
 test-amd64-i386-qemuu-rhel6hvm-amd                           broken  
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         broken  
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        broken  
 test-amd64-i386-pair                                         broken  
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          broken  
 test-amd64-i386-pv                                           broken  
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   broken  
 test-amd64-i386-xl-win-vcpus1                                broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         broken  
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 broken  


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26115:37a8946eeb9d
tag:         tip
user:        Ian Jackson 
date:        Fri Oct 26 16:09:29 2012 +0100
    
    libxc: builder: limit maximum size of kernel/ramdisk.
    
    Allowing user supplied kernels of arbitrary sizes, especially during
    decompression, can swallow up dom0 memory leading to either virtual
    address space exhaustion in the builder process or allocation
    failures/OOM killing of both toolstack and unrelated processes.
    
    We disable these checks when building in a stub domain for pvgrub
    since this uses the guest's own memory and is isolated.
    
    Decompression of gzip compressed kernels and ramdisks has been safe
    since 14954:58205257517d (Xen 3.1.0 onwards).
    
    This is XSA-25 / CVE-2012-4544.
    
    Also make explicit checks for buffer overflows in various
    decompression routines. These were already ruled out due to other
    properties of the code but check them as a belt-and-braces measure.
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    
    
changeset:   26114:6f9e46917eb8
user:        Charles Arnold 
date:        Fri Oct 26 12:05:08 2012 +0100
    
    pygrub: Add option to list grub entries
    
    The argument to "--entry" allows 2 syntaxes, either directly the entry
    number in menu.lst, or the whole string behind the "title" key word.
    This poses the following issue:
    
    From Dom0 there is no way to guess the number and, or the complete
    title string because this string contains the kernel version, which
    will change with a kernel update.
    
    This patch adds [-l|--list-entries] as an argument to pygrub.
    
    Signed-off-by: Charles Arnold 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26113:03af0abd2b72
user:        Ian Campbell 
date:        Fri Oct 26 12:03:12 2012 +0100
    
    xl: Do not leak events when a domain exits.
    
    The goto in both of these places misses the event free which would
    normally clean up.
    
    ==8655== 80 bytes in 1 blocks are definitely lost in loss record 1 of 1
    ==8655==    at 0x4024370: calloc (vg_replace_malloc.c:593)
    ==8655==    by 0x406EAAE: libxl__zalloc (libxl_internal.c:83)
    ==8655==    by 0x4078173: libxl__event_new (libxl_event.c:1167)
    ==8655==    by 0x4056373: domain_death_occurred (libxl.c:958)
    ==8655==    by 0x4058D06: domain_death_xswatch_callback (libxl.c:1038)
    ==8655==    by 0x4078EB5: watchfd_callback (libxl_event.c:458)
    ==8655==    by 0x407839E: afterpoll_internal (libxl_event.c:949)
    ==8655==    by 0x4079142: eventloop_iteration (libxl_event.c:1371)
    ==8655==    by 0x40799BB: libxl_event_wait (libxl_event.c:1396)
    ==8655==    by 0x805CC67: create_domain (xl_cmdimpl.c:1698)
    ==8655==    by 0x805E001: main_create (xl_cmdimpl.c:3986)
    ==8655==    by 0x804D43D: main (xl.c:285)
    
    
    Signed-off-by: Ian Campbell 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26112:d07692b5c780
user:        Ian Jackson 
date:        Fri Oct 26 11:39:42 2012 +0100
    
    Revert 26109:6ccfe4d29f95
    
    This changeset was contaminated by changes hanging around in my
    working tree.  Sorry :-(.
    
    Signed-off-by: Ian Jackson 
    
    
changeset:   26111:c26e1a79fe77
user:        Christoph Egger 
date:        Thu Oct 25 17:12:55 2012 +0100
    
    libxl: NetBSD PCI passthrough support
    
    Add PCI passthrough support for HVM guests.
    
    Signed-off-by: Christoph Egger 
    Committed-by: Ian Jackson 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 03:33:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 03:33:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSg5J-0002Ui-6J; Mon, 29 Oct 2012 03:32:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSg5H-0002Ud-Ne
	for xen-devel@lists.xensource.com; Mon, 29 Oct 2012 03:32:16 +0000
Received: from [85.158.143.99:40648] by server-1.bemta-4.messagelabs.com id
	1B/D4-19134-EB8FD805; Mon, 29 Oct 2012 03:32:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1351481534!24347310!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzOTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10503 invoked from network); 29 Oct 2012 03:32:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Oct 2012 03:32:14 -0000
X-IronPort-AV: E=Sophos;i="4.80,668,1344211200"; d="scan'208";a="15454156"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Oct 2012 03:32:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Mon, 29 Oct 2012 03:31:59 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TSg52-0003OV-2S;
	Mon, 29 Oct 2012 03:32:00 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TSg51-0006CP-WB;
	Mon, 29 Oct 2012 03:32:00 +0000
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Mon, 29 Oct 2012 03:31:59 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 14132: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14132 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14132/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pv            3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-xl-multivcpu  3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-xl            3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-xl             9 guest-start               fail REGR. vs. 14076
 test-amd64-i386-pair         4 host-install/dst_host(4) broken REGR. vs. 14076
 test-amd64-i386-pair         3 host-install/src_host(3) broken REGR. vs. 14076
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 14076
 test-amd64-amd64-xl-qemuu-win7-amd64  3 host-install(3) broken REGR. vs. 14076
 test-amd64-i386-xend-winxpsp3  3 host-install(3)        broken REGR. vs. 14076
 test-amd64-i386-xl-win7-amd64  3 host-install(3)        broken REGR. vs. 14076
 test-amd64-i386-xl-winxpsp3-vcpus1  3 host-install(3)   broken REGR. vs. 14076
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 14076
 test-amd64-i386-win           3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 14076
 test-amd64-amd64-xl-win       3 host-install(3)         broken REGR. vs. 14076

Tests which are failing intermittently (not blocking):
 test-i386-i386-pv             3 host-install(3)           broken pass in 14125
 test-amd64-amd64-pv           3 host-install(3)           broken pass in 14117
 test-amd64-i386-rhel6hvm-amd  3 host-install(3)           broken pass in 14115
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3)     broken pass in 14090
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)         broken pass in 14125
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore           fail pass in 14105
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3)   broken pass in 14094
 test-amd64-amd64-xl           3 host-install(3)           broken pass in 14115
 test-i386-i386-pair           4 host-install/dst_host(4)  broken pass in 14090
 test-i386-i386-pair           3 host-install/src_host(3)  broken pass in 14090
 test-amd64-amd64-xl-sedf      3 host-install(3)           broken pass in 14117
 test-amd64-amd64-pair         3 host-install/src_host(3)  broken pass in 14109
 test-amd64-amd64-pair         4 host-install/dst_host(4)  broken pass in 14109
 test-amd64-amd64-xl-win7-amd64 12 guest-localmigrate/x10    fail pass in 14125
 test-i386-i386-xl             3 host-install(3)  broken in 14090 pass in 14132
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)  broken in 14090 pass in 14132
 test-amd64-i386-xl-win-vcpus1  3 host-install(3) broken in 14109 pass in 14132

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)      broken REGR. vs. 14076

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 14125 never pass

version targeted for testing:
 xen                  25eda7e7b4e6
baseline version:
 xen                  40ccbee890e1

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla 
  Bastian Blank 
  Chuang Cao 
  George Dunlap 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jason McCarver 
  Joe Jin 
  Keir Fraser 
  Matt Wilson 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Sander Eikelenboom 
  Stefano Stabellini 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          broken  
 test-amd64-i386-xl                                           broken  
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 broken  
 test-amd64-i386-qemuu-rhel6hvm-amd                           broken  
 test-amd64-amd64-xl-qemuu-win7-amd64                         broken  
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         broken  
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        broken  
 test-amd64-i386-pair                                         broken  
 test-i386-i386-pair                                          broken  
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          broken  
 test-amd64-i386-pv                                           broken  
 test-i386-i386-pv                                            broken  
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           broken  
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          broken  
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      broken  
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                broken  
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 612 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 03:33:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 03:33:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSg5J-0002Ui-6J; Mon, 29 Oct 2012 03:32:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSg5H-0002Ud-Ne
	for xen-devel@lists.xensource.com; Mon, 29 Oct 2012 03:32:16 +0000
Received: from [85.158.143.99:40648] by server-1.bemta-4.messagelabs.com id
	1B/D4-19134-EB8FD805; Mon, 29 Oct 2012 03:32:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1351481534!24347310!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzOTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10503 invoked from network); 29 Oct 2012 03:32:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Oct 2012 03:32:14 -0000
X-IronPort-AV: E=Sophos;i="4.80,668,1344211200"; d="scan'208";a="15454156"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Oct 2012 03:32:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Mon, 29 Oct 2012 03:31:59 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TSg52-0003OV-2S;
	Mon, 29 Oct 2012 03:32:00 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TSg51-0006CP-WB;
	Mon, 29 Oct 2012 03:32:00 +0000
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Mon, 29 Oct 2012 03:31:59 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 14132: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14132 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14132/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pv            3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-xl-multivcpu  3 host-install(3)         broken REGR. vs. 14076
 test-amd64-i386-xl            3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-xl             9 guest-start               fail REGR. vs. 14076
 test-amd64-i386-pair         4 host-install/dst_host(4) broken REGR. vs. 14076
 test-amd64-i386-pair         3 host-install/src_host(3) broken REGR. vs. 14076
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 14076
 test-amd64-amd64-xl-qemuu-win7-amd64  3 host-install(3) broken REGR. vs. 14076
 test-amd64-i386-xend-winxpsp3  3 host-install(3)        broken REGR. vs. 14076
 test-amd64-i386-xl-win7-amd64  3 host-install(3)        broken REGR. vs. 14076
 test-amd64-i386-xl-winxpsp3-vcpus1  3 host-install(3)   broken REGR. vs. 14076
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 14076
 test-amd64-i386-win           3 host-install(3)         broken REGR. vs. 14076
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 14076
 test-amd64-amd64-xl-win       3 host-install(3)         broken REGR. vs. 14076

Tests which are failing intermittently (not blocking):
 test-i386-i386-pv             3 host-install(3)           broken pass in 14125
 test-amd64-amd64-pv           3 host-install(3)           broken pass in 14117
 test-amd64-i386-rhel6hvm-amd  3 host-install(3)           broken pass in 14115
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3)     broken pass in 14090
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)         broken pass in 14125
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore           fail pass in 14105
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3)   broken pass in 14094
 test-amd64-amd64-xl           3 host-install(3)           broken pass in 14115
 test-i386-i386-pair           4 host-install/dst_host(4)  broken pass in 14090
 test-i386-i386-pair           3 host-install/src_host(3)  broken pass in 14090
 test-amd64-amd64-xl-sedf      3 host-install(3)           broken pass in 14117
 test-amd64-amd64-pair         3 host-install/src_host(3)  broken pass in 14109
 test-amd64-amd64-pair         4 host-install/dst_host(4)  broken pass in 14109
 test-amd64-amd64-xl-win7-amd64 12 guest-localmigrate/x10    fail pass in 14125
 test-i386-i386-xl             3 host-install(3)  broken in 14090 pass in 14132
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)  broken in 14090 pass in 14132
 test-amd64-i386-xl-win-vcpus1  3 host-install(3) broken in 14109 pass in 14132

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)      broken REGR. vs. 14076

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 14125 never pass

version targeted for testing:
 xen                  25eda7e7b4e6
baseline version:
 xen                  40ccbee890e1

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla 
  Bastian Blank 
  Chuang Cao 
  George Dunlap 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jason McCarver 
  Joe Jin 
  Keir Fraser 
  Matt Wilson 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Sander Eikelenboom 
  Stefano Stabellini 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          broken  
 test-amd64-i386-xl                                           broken  
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 broken  
 test-amd64-i386-qemuu-rhel6hvm-amd                           broken  
 test-amd64-amd64-xl-qemuu-win7-amd64                         broken  
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               broken  
 test-amd64-i386-qemuu-rhel6hvm-intel                         broken  
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        broken  
 test-amd64-i386-pair                                         broken  
 test-i386-i386-pair                                          broken  
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          broken  
 test-amd64-i386-pv                                           broken  
 test-i386-i386-pv                                            broken  
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           broken  
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          broken  
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      broken  
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                broken  
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 612 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 03:39:34 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 03:39:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSgBu-0002em-7f; Mon, 29 Oct 2012 03:39:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSgBs-0002eg-4H
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 03:39:04 +0000
Received: from [85.158.139.211:34925] by server-12.bemta-5.messagelabs.com id
	D8/BC-26919-75AFD805; Mon, 29 Oct 2012 03:39:03 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1351481942!24033137!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjI0NjAy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29486 invoked from network); 29 Oct 2012 03:39:02 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-10.tower-206.messagelabs.com with SMTP;
	29 Oct 2012 03:39:02 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 28 Oct 2012 20:39:01 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,668,1344236400"; d="scan'208";a="161741111"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by AZSMGA002.ch.intel.com with ESMTP; 28 Oct 2012 20:39:00 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sun, 28 Oct 2012 20:38:46 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.186]) with mapi id
	14.01.0355.002; Mon, 29 Oct 2012 11:38:15 +0800
From: "Liu, Jinsong" 
To: Konrad Rzeszutek Wilk 
Thread-Topic: [Xen-devel] [PATCH 1/2] Xen acpi pad implement
Thread-Index: AQHNs7Z0Ti91BiFLfUibRvXA4zlK85fPmf1g
Date: Mon, 29 Oct 2012 03:38:14 +0000
Message-ID: 
References: 
	<5089676602000078000A4928@nat28.tlf.novell.com>
	
	<508A89CB020000780008E6ED@nat28.tlf.novell.com>
	
	
	<20121026201409.GF2708@phenom.dumpdata.com>
In-Reply-To: <20121026201409.GF2708@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk ,
	"linux-kernel@vger.kernel.org" ,
	Jan Beulich ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 1/2] Xen acpi pad implement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

It's doable to register a stub for xen. However, it's not preferred, say, to make xen pad as module, considering the case 'rmmod xen_acpi_pad' then 'insmod acpi_pad'? Under such case there is risk of mwait #UD, if we want to remove mwait check as 'patch 2/2: Revert-pad-config-check-in-xen_check_mwait.patch' did, advantages of which is to enjoy deep Cx.

IMHO to prevent mwait #UD, native pad should never have chance to register successfully when running under Xen. So it's better never unregister/disable xen pad.

Konrad Rzeszutek Wilk wrote:
>> --- a/drivers/xen/Makefile
>> +++ b/drivers/xen/Makefile
>> @@ -29,6 +29,7 @@ obj-$(CONFIG_XEN_MCE_LOG)		+= mcelog.o
>>  obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+= xen-pciback/
>>  obj-$(CONFIG_XEN_PRIVCMD)		+= xen-privcmd.o
>>  obj-$(CONFIG_XEN_ACPI_PROCESSOR)	+= xen-acpi-processor.o
>> +obj-$(CONFIG_XEN_DOM0)			+= xen_acpi_pad.o
> 
> We should have a Kconfig option. In it, please mention what
> version of hypervisor supports this functionality.
> 

Kconfig option for xen pad is not preferred, considering if we disable xen pad and then register native pad driver? (of course the precondition is that we do not register stub for xen).

>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#if defined(CONFIG_ACPI_PROCESSOR_AGGREGATOR) || \
>> +		defined(CONFIG_ACPI_PROCESSOR_AGGREGATOR_MODULE)
> 
> I don't think you need that.
> 

OK.

>> +
>> +static int __init xen_acpi_pad_init(void)
>> +{
>> +	/* Only DOM0 is responsible for Xen acpi pad */
>> +	if (xen_initial_domain())
>> +		return acpi_bus_register_driver(&xen_acpi_pad_driver); +
>> +	return -ENODEV;
>> +}
>> +subsys_initcall(xen_acpi_pad_init);
> 
> 
> No way of making this a module? It would be nice - perhaps have a stub
> function that registers the bus but does not do anything until this
> proper module is loaded?
> 

It's doable but not preferred, reason as above.

>> +
>> +#endif
>> diff --git a/include/xen/interface/platform.h
>> b/include/xen/interface/platform.h index 4755b5f..0f44376 100644 ---
>> a/include/xen/interface/platform.h +++
>> b/include/xen/interface/platform.h @@ -324,6 +324,22 @@ struct
>>  xenpf_cpu_ol { };
>>  DEFINE_GUEST_HANDLE_STRUCT(xenpf_cpu_ol);
>> 
>> +/*
>> + * CMD 58 and 59 are reserved for cpu hotadd and memory hotadd,
>> + * which already occupied at Xen hypervisor side.
>            ^- are
> 

Sure.

Thanks,
Jinsong


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 03:39:34 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 03:39:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSgBu-0002em-7f; Mon, 29 Oct 2012 03:39:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSgBs-0002eg-4H
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 03:39:04 +0000
Received: from [85.158.139.211:34925] by server-12.bemta-5.messagelabs.com id
	D8/BC-26919-75AFD805; Mon, 29 Oct 2012 03:39:03 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1351481942!24033137!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjI0NjAy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29486 invoked from network); 29 Oct 2012 03:39:02 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-10.tower-206.messagelabs.com with SMTP;
	29 Oct 2012 03:39:02 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 28 Oct 2012 20:39:01 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,668,1344236400"; d="scan'208";a="161741111"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by AZSMGA002.ch.intel.com with ESMTP; 28 Oct 2012 20:39:00 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sun, 28 Oct 2012 20:38:46 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.186]) with mapi id
	14.01.0355.002; Mon, 29 Oct 2012 11:38:15 +0800
From: "Liu, Jinsong" 
To: Konrad Rzeszutek Wilk 
Thread-Topic: [Xen-devel] [PATCH 1/2] Xen acpi pad implement
Thread-Index: AQHNs7Z0Ti91BiFLfUibRvXA4zlK85fPmf1g
Date: Mon, 29 Oct 2012 03:38:14 +0000
Message-ID: 
References: 
	<5089676602000078000A4928@nat28.tlf.novell.com>
	
	<508A89CB020000780008E6ED@nat28.tlf.novell.com>
	
	
	<20121026201409.GF2708@phenom.dumpdata.com>
In-Reply-To: <20121026201409.GF2708@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk ,
	"linux-kernel@vger.kernel.org" ,
	Jan Beulich ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 1/2] Xen acpi pad implement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

It's doable to register a stub for xen. However, it's not preferred, say, to make xen pad as module, considering the case 'rmmod xen_acpi_pad' then 'insmod acpi_pad'? Under such case there is risk of mwait #UD, if we want to remove mwait check as 'patch 2/2: Revert-pad-config-check-in-xen_check_mwait.patch' did, advantages of which is to enjoy deep Cx.

IMHO to prevent mwait #UD, native pad should never have chance to register successfully when running under Xen. So it's better never unregister/disable xen pad.

Konrad Rzeszutek Wilk wrote:
>> --- a/drivers/xen/Makefile
>> +++ b/drivers/xen/Makefile
>> @@ -29,6 +29,7 @@ obj-$(CONFIG_XEN_MCE_LOG)		+= mcelog.o
>>  obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+= xen-pciback/
>>  obj-$(CONFIG_XEN_PRIVCMD)		+= xen-privcmd.o
>>  obj-$(CONFIG_XEN_ACPI_PROCESSOR)	+= xen-acpi-processor.o
>> +obj-$(CONFIG_XEN_DOM0)			+= xen_acpi_pad.o
> 
> We should have a Kconfig option. In it, please mention what
> version of hypervisor supports this functionality.
> 

Kconfig option for xen pad is not preferred, considering if we disable xen pad and then register native pad driver? (of course the precondition is that we do not register stub for xen).

>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#if defined(CONFIG_ACPI_PROCESSOR_AGGREGATOR) || \
>> +		defined(CONFIG_ACPI_PROCESSOR_AGGREGATOR_MODULE)
> 
> I don't think you need that.
> 

OK.

>> +
>> +static int __init xen_acpi_pad_init(void)
>> +{
>> +	/* Only DOM0 is responsible for Xen acpi pad */
>> +	if (xen_initial_domain())
>> +		return acpi_bus_register_driver(&xen_acpi_pad_driver); +
>> +	return -ENODEV;
>> +}
>> +subsys_initcall(xen_acpi_pad_init);
> 
> 
> No way of making this a module? It would be nice - perhaps have a stub
> function that registers the bus but does not do anything until this
> proper module is loaded?
> 

It's doable but not preferred, reason as above.

>> +
>> +#endif
>> diff --git a/include/xen/interface/platform.h
>> b/include/xen/interface/platform.h index 4755b5f..0f44376 100644 ---
>> a/include/xen/interface/platform.h +++
>> b/include/xen/interface/platform.h @@ -324,6 +324,22 @@ struct
>>  xenpf_cpu_ol { };
>>  DEFINE_GUEST_HANDLE_STRUCT(xenpf_cpu_ol);
>> 
>> +/*
>> + * CMD 58 and 59 are reserved for cpu hotadd and memory hotadd,
>> + * which already occupied at Xen hypervisor side.
>            ^- are
> 

Sure.

Thanks,
Jinsong


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 06:32:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 06:32:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSisq-0003vL-HX; Mon, 29 Oct 2012 06:31:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSiso-0003ux-W9; Mon, 29 Oct 2012 06:31:35 +0000
Received: from [85.158.137.99:24998] by server-12.bemta-3.messagelabs.com id
	EE/95-27853-5C22E805; Mon, 29 Oct 2012 06:31:33 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1351492293!12754733!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19191 invoked from network); 29 Oct 2012 06:31:33 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Oct 2012 06:31:33 -0000
Received: by mail-bk0-f45.google.com with SMTP id jf3so1798823bkc.32
	for ; Sun, 28 Oct 2012 23:31:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:to
	:subject:content-type:content-transfer-encoding;
	bh=kPx1qiWjM96nVXUjZNSJSHdC3mSUs+62ILE7a/UdY6M=;
	b=GJlsOkH7d4N6orklgSaWAYhTgxlJBrWhMLqDl+wstxiRNFgufWEpIZiMITRefmoQ0y
	jPKm7VGDS2cT0Jd7HimCc5R6zh787Hze3q0E9GrnteA2hFW6aetN85s2+47q2k7Wb+LY
	IFjk1nyk0R0TfkllWqgOawfvYckpXUM51DzmVqscXXV7P8HnKugGa+gbV1rUOUQjf6yg
	aHvk/W5yOGr53O5ZWIqJOIZoaOV7yYhNNnmQ50dp0VVlXV7y1EB+xbMiYJXjwZPvlIdL
	PjoccDpGRO7qo5wi/0EIYy4LlFDltJjzJum4pGM+oFxyJ8Wni2xkbEDqYN4J91KfNh4r
	tUnA==
Received: by 10.204.146.10 with SMTP id f10mr8688758bkv.98.1351492293120;
	Sun, 28 Oct 2012 23:31:33 -0700 (PDT)
Received: from [172.16.26.11] ([91.224.174.71])
	by mx.google.com with ESMTPS id 1sm3062737bks.3.2012.10.28.23.31.32
	(version=SSLv3 cipher=OTHER); Sun, 28 Oct 2012 23:31:32 -0700 (PDT)
Message-ID: <508E22C3.8080504@xen.org>
Date: Mon, 29 Oct 2012 06:31:31 +0000
From: Lars Kurth 
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" , 
	"xen-api@lists.xen.org" ,
	xen-users@lists.xen.org, xen-arm@lists.xen.org
Subject: [Xen-devel] [Reminder] Xen Document Day on IRC freenode #xendocs
	today
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: lars.kurth@xen.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Good Morning,
we have another document day today! More information about docs day at 
http://wiki.xen.org/wiki/Xen_Document_Days
The TODO list is at http://wiki.xen.org/wiki/Xen_Document_Days/TODO
Regards
Lars

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 06:32:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 06:32:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSisq-0003vL-HX; Mon, 29 Oct 2012 06:31:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSiso-0003ux-W9; Mon, 29 Oct 2012 06:31:35 +0000
Received: from [85.158.137.99:24998] by server-12.bemta-3.messagelabs.com id
	EE/95-27853-5C22E805; Mon, 29 Oct 2012 06:31:33 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1351492293!12754733!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19191 invoked from network); 29 Oct 2012 06:31:33 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Oct 2012 06:31:33 -0000
Received: by mail-bk0-f45.google.com with SMTP id jf3so1798823bkc.32
	for ; Sun, 28 Oct 2012 23:31:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:to
	:subject:content-type:content-transfer-encoding;
	bh=kPx1qiWjM96nVXUjZNSJSHdC3mSUs+62ILE7a/UdY6M=;
	b=GJlsOkH7d4N6orklgSaWAYhTgxlJBrWhMLqDl+wstxiRNFgufWEpIZiMITRefmoQ0y
	jPKm7VGDS2cT0Jd7HimCc5R6zh787Hze3q0E9GrnteA2hFW6aetN85s2+47q2k7Wb+LY
	IFjk1nyk0R0TfkllWqgOawfvYckpXUM51DzmVqscXXV7P8HnKugGa+gbV1rUOUQjf6yg
	aHvk/W5yOGr53O5ZWIqJOIZoaOV7yYhNNnmQ50dp0VVlXV7y1EB+xbMiYJXjwZPvlIdL
	PjoccDpGRO7qo5wi/0EIYy4LlFDltJjzJum4pGM+oFxyJ8Wni2xkbEDqYN4J91KfNh4r
	tUnA==
Received: by 10.204.146.10 with SMTP id f10mr8688758bkv.98.1351492293120;
	Sun, 28 Oct 2012 23:31:33 -0700 (PDT)
Received: from [172.16.26.11] ([91.224.174.71])
	by mx.google.com with ESMTPS id 1sm3062737bks.3.2012.10.28.23.31.32
	(version=SSLv3 cipher=OTHER); Sun, 28 Oct 2012 23:31:32 -0700 (PDT)
Message-ID: <508E22C3.8080504@xen.org>
Date: Mon, 29 Oct 2012 06:31:31 +0000
From: Lars Kurth 
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" , 
	"xen-api@lists.xen.org" ,
	xen-users@lists.xen.org, xen-arm@lists.xen.org
Subject: [Xen-devel] [Reminder] Xen Document Day on IRC freenode #xendocs
	today
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: lars.kurth@xen.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Good Morning,
we have another document day today! More information about docs day at 
http://wiki.xen.org/wiki/Xen_Document_Days
The TODO list is at http://wiki.xen.org/wiki/Xen_Document_Days/TODO
Regards
Lars

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 08:12:48 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 08:12:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSkSK-0005Pq-9D; Mon, 29 Oct 2012 08:12:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSkSI-0005Pl-Nw
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 08:12:18 +0000
Received: from [85.158.143.99:27152] by server-1.bemta-4.messagelabs.com id
	31/AF-19134-16A3E805; Mon, 29 Oct 2012 08:12:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1351498336!21348424!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 608 invoked from network); 29 Oct 2012 08:12:16 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-216.messagelabs.com with SMTP;
	29 Oct 2012 08:12:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 29 Oct 2012 08:12:15 +0000
Message-Id: <508E489502000078000A4FC6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 29 Oct 2012 08:12:53 +0000
From: "Jan Beulich" 
To: "xen-devel" 
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] preparing for 4.2.1 and 4.1.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

All,

with the aim of getting both stable releases out the door in the
second half of November, please check the respective branches
for backports of bug fixes in -unstable that you think would
validly belong into those trees (an initial backport of some tools
side patches is known to be still missing).

My intention is to tag -rc1 on both trees towards the end of this
week (of course provided the trees get pushes from their staging
counterparts of everything that has got put there by then).

Jan




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 08:12:48 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 08:12:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSkSK-0005Pq-9D; Mon, 29 Oct 2012 08:12:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSkSI-0005Pl-Nw
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 08:12:18 +0000
Received: from [85.158.143.99:27152] by server-1.bemta-4.messagelabs.com id
	31/AF-19134-16A3E805; Mon, 29 Oct 2012 08:12:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1351498336!21348424!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 608 invoked from network); 29 Oct 2012 08:12:16 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-216.messagelabs.com with SMTP;
	29 Oct 2012 08:12:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 29 Oct 2012 08:12:15 +0000
Message-Id: <508E489502000078000A4FC6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 29 Oct 2012 08:12:53 +0000
From: "Jan Beulich" 
To: "xen-devel" 
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] preparing for 4.2.1 and 4.1.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

All,

with the aim of getting both stable releases out the door in the
second half of November, please check the respective branches
for backports of bug fixes in -unstable that you think would
validly belong into those trees (an initial backport of some tools
side patches is known to be still missing).

My intention is to tag -rc1 on both trees towards the end of this
week (of course provided the trees get pushes from their staging
counterparts of everything that has got put there by then).

Jan




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 09:05:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 09:05:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSlHS-0005ig-KG; Mon, 29 Oct 2012 09:05:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSlHQ-0005iY-L8
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 09:05:08 +0000
Received: from [85.158.139.83:54686] by server-11.bemta-5.messagelabs.com id
	AA/F3-14870-3C64E805; Mon, 29 Oct 2012 09:05:07 +0000
X-Env-Sender: gabrielx.wu@intel.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1351501506!27728225!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMzNzc5NA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25655 invoked from network); 29 Oct 2012 09:05:07 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-2.tower-182.messagelabs.com with SMTP;
	29 Oct 2012 09:05:07 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 29 Oct 2012 02:05:05 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,669,1344236400"; d="scan'208";a="239694740"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by fmsmga001.fm.intel.com with ESMTP; 29 Oct 2012 00:34:22 -0700
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 29 Oct 2012 00:34:22 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.123]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.134]) with mapi id
	14.01.0355.002; Mon, 29 Oct 2012 15:34:20 +0800
From: "Wu, GabrielX" 
To: "xen-devel@lists.xen.org" 
Thread-Topic: VMX status report. Xen:26102 & Dom0:3.6.3
Thread-Index: AQHNtafPFUy9eIY4K0CtXtMizzpoGw==
Date: Mon, 29 Oct 2012 07:34:20 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "Liu, SongtaoX" , "Ren,
	Yongjie" , "Liu,
	RongrongX" , "Zhou, Chao" 
Subject: [Xen-devel] VMX status report. Xen:26102 & Dom0:3.6.3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,

This is the test report of xen-unstable tree, no new issue found and no issue fixed.

Version Info:
=================================================================
xen-changeset:   26102:22e08c9ac770
Dom0:          linux.git  3.6.3
=================================================================

New issue(0)
==============

Fixed issue(0)
==============

Old issues(9)
==============
1. [ACPI]Dom0 (2.6.31) fail to do S3
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1707
2. [XL]"xl vcpu-set" causes dom0 crash or panic
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1730
3. [VT-D]fail to detach NIC from guest  
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1736
4. Sometimes Xen panic on ia32pae Sandybridge when restore guest
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1747
5. after detaching a VF from a guest, shutdown the guest is very slow
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1812
6. Poor performance when do guest save/restore and migration with linux 3.1 dom0
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1784
7. vcpu-set doesn't take effect on guest
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822
8. Dom0 cannot be shutdown before PCI device detachment from guest
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1826
9. xl pci-list shows one PCI device (PF or VF) could be assigned to two different guests
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1834

Best Regards,
Ronghui Wu(Gabriel)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 09:05:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 09:05:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSlHS-0005ig-KG; Mon, 29 Oct 2012 09:05:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSlHQ-0005iY-L8
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 09:05:08 +0000
Received: from [85.158.139.83:54686] by server-11.bemta-5.messagelabs.com id
	AA/F3-14870-3C64E805; Mon, 29 Oct 2012 09:05:07 +0000
X-Env-Sender: gabrielx.wu@intel.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1351501506!27728225!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMzNzc5NA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25655 invoked from network); 29 Oct 2012 09:05:07 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-2.tower-182.messagelabs.com with SMTP;
	29 Oct 2012 09:05:07 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 29 Oct 2012 02:05:05 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,669,1344236400"; d="scan'208";a="239694740"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by fmsmga001.fm.intel.com with ESMTP; 29 Oct 2012 00:34:22 -0700
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 29 Oct 2012 00:34:22 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.123]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.134]) with mapi id
	14.01.0355.002; Mon, 29 Oct 2012 15:34:20 +0800
From: "Wu, GabrielX" 
To: "xen-devel@lists.xen.org" 
Thread-Topic: VMX status report. Xen:26102 & Dom0:3.6.3
Thread-Index: AQHNtafPFUy9eIY4K0CtXtMizzpoGw==
Date: Mon, 29 Oct 2012 07:34:20 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "Liu, SongtaoX" , "Ren,
	Yongjie" , "Liu,
	RongrongX" , "Zhou, Chao" 
Subject: [Xen-devel] VMX status report. Xen:26102 & Dom0:3.6.3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,

This is the test report of xen-unstable tree, no new issue found and no issue fixed.

Version Info:
=================================================================
xen-changeset:   26102:22e08c9ac770
Dom0:          linux.git  3.6.3
=================================================================

New issue(0)
==============

Fixed issue(0)
==============

Old issues(9)
==============
1. [ACPI]Dom0 (2.6.31) fail to do S3
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1707
2. [XL]"xl vcpu-set" causes dom0 crash or panic
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1730
3. [VT-D]fail to detach NIC from guest  
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1736
4. Sometimes Xen panic on ia32pae Sandybridge when restore guest
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1747
5. after detaching a VF from a guest, shutdown the guest is very slow
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1812
6. Poor performance when do guest save/restore and migration with linux 3.1 dom0
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1784
7. vcpu-set doesn't take effect on guest
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822
8. Dom0 cannot be shutdown before PCI device detachment from guest
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1826
9. xl pci-list shows one PCI device (PF or VF) could be assigned to two different guests
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1834

Best Regards,
Ronghui Wu(Gabriel)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 09:37:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 09:37:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSlmB-0005wT-Dy; Mon, 29 Oct 2012 09:36:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSlmA-0005wO-IF
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 09:36:54 +0000
Received: from [85.158.137.99:20592] by server-3.bemta-3.messagelabs.com id
	33/A6-09368-53E4E805; Mon, 29 Oct 2012 09:36:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1351503412!23324201!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20074 invoked from network); 29 Oct 2012 09:36:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-217.messagelabs.com with SMTP;
	29 Oct 2012 09:36:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 29 Oct 2012 09:36:51 +0000
Message-Id: <508E5C6B02000078000A5011@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 29 Oct 2012 09:37:31 +0000
From: "Jan Beulich" 
To: "Jean Guyader" 
References: <1351187729-4681-1-git-send-email-jean.guyader@citrix.com>
In-Reply-To: <1351187729-4681-1-git-send-email-jean.guyader@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/2] Add V4V to Xen (v8)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 25.10.12 at 19:55, Jean Guyader  wrote:
> v8 changes:
>         - Move v4v private structures to v4v.c
>         - fix padding

I still spotted at least one bogus padding field (in struct
v4v_ring_message_header, where no field is more than 4-byte
aligned afaict). Did you really carefully walk through all of them?

Also, to validate the structures are really compatible between
native and compat mode guests, I'd strongly recommend adding
the leaf ones to xen/include/xlat.lst.

Further I don't think you sync-ed up your patches with the
XEN_GUEST_HANDLE_PARAM() changes done for ARM, yet you
also didn't mention that the patch set is against other than the
tip of unstable.

>         - Fix some coding style issues

There appear to be plenty left (space between function name and
opening parenthesis, indentation inside switch statement, missing
parenthesization of macro expansion, missing newline between
declarations and statements are which I noticed without specifically
looking for them).

Jan

>         - Drop the VIRQ_XC_RESERVED patch



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 09:37:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 09:37:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSlmB-0005wT-Dy; Mon, 29 Oct 2012 09:36:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSlmA-0005wO-IF
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 09:36:54 +0000
Received: from [85.158.137.99:20592] by server-3.bemta-3.messagelabs.com id
	33/A6-09368-53E4E805; Mon, 29 Oct 2012 09:36:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1351503412!23324201!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20074 invoked from network); 29 Oct 2012 09:36:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-217.messagelabs.com with SMTP;
	29 Oct 2012 09:36:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 29 Oct 2012 09:36:51 +0000
Message-Id: <508E5C6B02000078000A5011@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 29 Oct 2012 09:37:31 +0000
From: "Jan Beulich" 
To: "Jean Guyader" 
References: <1351187729-4681-1-git-send-email-jean.guyader@citrix.com>
In-Reply-To: <1351187729-4681-1-git-send-email-jean.guyader@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/2] Add V4V to Xen (v8)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 25.10.12 at 19:55, Jean Guyader  wrote:
> v8 changes:
>         - Move v4v private structures to v4v.c
>         - fix padding

I still spotted at least one bogus padding field (in struct
v4v_ring_message_header, where no field is more than 4-byte
aligned afaict). Did you really carefully walk through all of them?

Also, to validate the structures are really compatible between
native and compat mode guests, I'd strongly recommend adding
the leaf ones to xen/include/xlat.lst.

Further I don't think you sync-ed up your patches with the
XEN_GUEST_HANDLE_PARAM() changes done for ARM, yet you
also didn't mention that the patch set is against other than the
tip of unstable.

>         - Fix some coding style issues

There appear to be plenty left (space between function name and
opening parenthesis, indentation inside switch statement, missing
parenthesization of macro expansion, missing newline between
declarations and statements are which I noticed without specifically
looking for them).

Jan

>         - Drop the VIRQ_XC_RESERVED patch



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 09:41:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 09:41:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSlqA-00064E-1D; Mon, 29 Oct 2012 09:41:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSlq7-00063v-83
	for xen-devel@lists.xensource.com; Mon, 29 Oct 2012 09:40:59 +0000
Received: from [85.158.137.99:5884] by server-4.bemta-3.messagelabs.com id
	E8/24-01405-A2F4E805; Mon, 29 Oct 2012 09:40:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1351503655!18633922!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27367 invoked from network); 29 Oct 2012 09:40:56 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-217.messagelabs.com with SMTP;
	29 Oct 2012 09:40:56 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 29 Oct 2012 09:40:55 +0000
Message-Id: <508E5D5C02000078000A5028@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 29 Oct 2012 09:41:32 +0000
From: "Jan Beulich" 
To: ,
	"Hannes Frederic Sowa" 
References: <20121028174441.GA30893@order.stressinduktion.org>
In-Reply-To: <20121028174441.GA30893@order.stressinduktion.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel 
Subject: Re: [Xen-devel] [PATCH] dbgp: fix compile error on building
 EARLY_PRINTK_DBGP without USB_SUPPORT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 28.10.12 at 18:44, Hannes Frederic Sowa  wrote:
> This patch fixes following compile error:
> 
> drivers/built-in.o: In function `dbgp_reset_prep':
> linux/drivers/usb/early/ehci-dbgp.c:984: undefined reference to 
> `xen_dbgp_reset_prep'
> drivers/built-in.o: In function `dbgp_external_startup':
> linux/drivers/usb/early/ehci-dbgp.c:619: undefined reference to 
> `xen_dbgp_external_startup'
> 
> EARLY_PRINTK_DBGP should work without USB_SUPPORT.

An alternative patch was previously suggested to address this
build problem.

Jan

> Cc: Jan Beulich 
> Signed-off-by: Hannes Frederic Sowa 
> ---
>  drivers/xen/Kconfig          | 3 +++
>  drivers/xen/Makefile         | 2 +-
>  include/linux/usb/ehci_def.h | 2 +-
>  3 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index 126d8ce..9bb3420 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -206,4 +206,7 @@ config XEN_MCE_LOG
>  	  Allow kernel fetching MCE error from Xen platform and
>  	  converting it into Linux mcelog format for mcelog tools
>  
> +config XEN_DBGP
> +	def_bool y if XEN_DOM0 && (USB_SUPPORT || EARLY_PRINTK_DBGP)
> +
>  endmenu
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index 0e863703..d23ed07 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -9,7 +9,7 @@ nostackp := $(call cc-option, -fno-stack-protector)
>  CFLAGS_features.o			:= $(nostackp)
>  
>  dom0-$(CONFIG_PCI) += pci.o
> -dom0-$(CONFIG_USB_SUPPORT) += dbgp.o
> +dom0-$(CONFIG_XEN_DBGP) += dbgp.o
>  dom0-$(CONFIG_ACPI) += acpi.o
>  dom0-$(CONFIG_X86) += pcpu.o
>  obj-$(CONFIG_XEN_DOM0)			+= $(dom0-y)
> diff --git a/include/linux/usb/ehci_def.h b/include/linux/usb/ehci_def.h
> index daec99a..7d8f7fe 100644
> --- a/include/linux/usb/ehci_def.h
> +++ b/include/linux/usb/ehci_def.h
> @@ -223,7 +223,7 @@ extern struct console early_dbgp_console;
>  
>  struct usb_hcd;
>  
> -#ifdef CONFIG_XEN_DOM0
> +#ifdef CONFIG_XEN_DBGP
>  extern int xen_dbgp_reset_prep(struct usb_hcd *);
>  extern int xen_dbgp_external_startup(struct usb_hcd *);
>  #else




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 09:41:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 09:41:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSlqA-00064E-1D; Mon, 29 Oct 2012 09:41:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSlq7-00063v-83
	for xen-devel@lists.xensource.com; Mon, 29 Oct 2012 09:40:59 +0000
Received: from [85.158.137.99:5884] by server-4.bemta-3.messagelabs.com id
	E8/24-01405-A2F4E805; Mon, 29 Oct 2012 09:40:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1351503655!18633922!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27367 invoked from network); 29 Oct 2012 09:40:56 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-217.messagelabs.com with SMTP;
	29 Oct 2012 09:40:56 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 29 Oct 2012 09:40:55 +0000
Message-Id: <508E5D5C02000078000A5028@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 29 Oct 2012 09:41:32 +0000
From: "Jan Beulich" 
To: ,
	"Hannes Frederic Sowa" 
References: <20121028174441.GA30893@order.stressinduktion.org>
In-Reply-To: <20121028174441.GA30893@order.stressinduktion.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel 
Subject: Re: [Xen-devel] [PATCH] dbgp: fix compile error on building
 EARLY_PRINTK_DBGP without USB_SUPPORT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 28.10.12 at 18:44, Hannes Frederic Sowa  wrote:
> This patch fixes following compile error:
> 
> drivers/built-in.o: In function `dbgp_reset_prep':
> linux/drivers/usb/early/ehci-dbgp.c:984: undefined reference to 
> `xen_dbgp_reset_prep'
> drivers/built-in.o: In function `dbgp_external_startup':
> linux/drivers/usb/early/ehci-dbgp.c:619: undefined reference to 
> `xen_dbgp_external_startup'
> 
> EARLY_PRINTK_DBGP should work without USB_SUPPORT.

An alternative patch was previously suggested to address this
build problem.

Jan

> Cc: Jan Beulich 
> Signed-off-by: Hannes Frederic Sowa 
> ---
>  drivers/xen/Kconfig          | 3 +++
>  drivers/xen/Makefile         | 2 +-
>  include/linux/usb/ehci_def.h | 2 +-
>  3 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index 126d8ce..9bb3420 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -206,4 +206,7 @@ config XEN_MCE_LOG
>  	  Allow kernel fetching MCE error from Xen platform and
>  	  converting it into Linux mcelog format for mcelog tools
>  
> +config XEN_DBGP
> +	def_bool y if XEN_DOM0 && (USB_SUPPORT || EARLY_PRINTK_DBGP)
> +
>  endmenu
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index 0e863703..d23ed07 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -9,7 +9,7 @@ nostackp := $(call cc-option, -fno-stack-protector)
>  CFLAGS_features.o			:= $(nostackp)
>  
>  dom0-$(CONFIG_PCI) += pci.o
> -dom0-$(CONFIG_USB_SUPPORT) += dbgp.o
> +dom0-$(CONFIG_XEN_DBGP) += dbgp.o
>  dom0-$(CONFIG_ACPI) += acpi.o
>  dom0-$(CONFIG_X86) += pcpu.o
>  obj-$(CONFIG_XEN_DOM0)			+= $(dom0-y)
> diff --git a/include/linux/usb/ehci_def.h b/include/linux/usb/ehci_def.h
> index daec99a..7d8f7fe 100644
> --- a/include/linux/usb/ehci_def.h
> +++ b/include/linux/usb/ehci_def.h
> @@ -223,7 +223,7 @@ extern struct console early_dbgp_console;
>  
>  struct usb_hcd;
>  
> -#ifdef CONFIG_XEN_DOM0
> +#ifdef CONFIG_XEN_DBGP
>  extern int xen_dbgp_reset_prep(struct usb_hcd *);
>  extern int xen_dbgp_external_startup(struct usb_hcd *);
>  #else




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 09:41:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 09:41:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSlq7-00063x-3L; Mon, 29 Oct 2012 09:40:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSlq5-00063p-NF
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 09:40:57 +0000
Received: from [85.158.137.99:5864] by server-3.bemta-3.messagelabs.com id
	64/1D-09368-82F4E805; Mon, 29 Oct 2012 09:40:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1351503655!18633920!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27343 invoked from network); 29 Oct 2012 09:40:55 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-217.messagelabs.com with SMTP;
	29 Oct 2012 09:40:55 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 29 Oct 2012 09:40:55 +0000
Message-Id: <508E5D5C02000078000A5028@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 29 Oct 2012 09:41:32 +0000
From: "Jan Beulich" 
To: ,
	"Hannes Frederic Sowa" 
References: <20121028174441.GA30893@order.stressinduktion.org>
In-Reply-To: <20121028174441.GA30893@order.stressinduktion.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel 
Subject: Re: [Xen-devel] [PATCH] dbgp: fix compile error on building
 EARLY_PRINTK_DBGP without USB_SUPPORT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 28.10.12 at 18:44, Hannes Frederic Sowa  wrote:
> This patch fixes following compile error:
> 
> drivers/built-in.o: In function `dbgp_reset_prep':
> linux/drivers/usb/early/ehci-dbgp.c:984: undefined reference to 
> `xen_dbgp_reset_prep'
> drivers/built-in.o: In function `dbgp_external_startup':
> linux/drivers/usb/early/ehci-dbgp.c:619: undefined reference to 
> `xen_dbgp_external_startup'
> 
> EARLY_PRINTK_DBGP should work without USB_SUPPORT.

An alternative patch was previously suggested to address this
build problem.

Jan

> Cc: Jan Beulich 
> Signed-off-by: Hannes Frederic Sowa 
> ---
>  drivers/xen/Kconfig          | 3 +++
>  drivers/xen/Makefile         | 2 +-
>  include/linux/usb/ehci_def.h | 2 +-
>  3 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index 126d8ce..9bb3420 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -206,4 +206,7 @@ config XEN_MCE_LOG
>  	  Allow kernel fetching MCE error from Xen platform and
>  	  converting it into Linux mcelog format for mcelog tools
>  
> +config XEN_DBGP
> +	def_bool y if XEN_DOM0 && (USB_SUPPORT || EARLY_PRINTK_DBGP)
> +
>  endmenu
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index 0e863703..d23ed07 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -9,7 +9,7 @@ nostackp := $(call cc-option, -fno-stack-protector)
>  CFLAGS_features.o			:= $(nostackp)
>  
>  dom0-$(CONFIG_PCI) += pci.o
> -dom0-$(CONFIG_USB_SUPPORT) += dbgp.o
> +dom0-$(CONFIG_XEN_DBGP) += dbgp.o
>  dom0-$(CONFIG_ACPI) += acpi.o
>  dom0-$(CONFIG_X86) += pcpu.o
>  obj-$(CONFIG_XEN_DOM0)			+= $(dom0-y)
> diff --git a/include/linux/usb/ehci_def.h b/include/linux/usb/ehci_def.h
> index daec99a..7d8f7fe 100644
> --- a/include/linux/usb/ehci_def.h
> +++ b/include/linux/usb/ehci_def.h
> @@ -223,7 +223,7 @@ extern struct console early_dbgp_console;
>  
>  struct usb_hcd;
>  
> -#ifdef CONFIG_XEN_DOM0
> +#ifdef CONFIG_XEN_DBGP
>  extern int xen_dbgp_reset_prep(struct usb_hcd *);
>  extern int xen_dbgp_external_startup(struct usb_hcd *);
>  #else




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 09:41:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 09:41:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSlq7-00063x-3L; Mon, 29 Oct 2012 09:40:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSlq5-00063p-NF
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 09:40:57 +0000
Received: from [85.158.137.99:5864] by server-3.bemta-3.messagelabs.com id
	64/1D-09368-82F4E805; Mon, 29 Oct 2012 09:40:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1351503655!18633920!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27343 invoked from network); 29 Oct 2012 09:40:55 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-217.messagelabs.com with SMTP;
	29 Oct 2012 09:40:55 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 29 Oct 2012 09:40:55 +0000
Message-Id: <508E5D5C02000078000A5028@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 29 Oct 2012 09:41:32 +0000
From: "Jan Beulich" 
To: ,
	"Hannes Frederic Sowa" 
References: <20121028174441.GA30893@order.stressinduktion.org>
In-Reply-To: <20121028174441.GA30893@order.stressinduktion.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel 
Subject: Re: [Xen-devel] [PATCH] dbgp: fix compile error on building
 EARLY_PRINTK_DBGP without USB_SUPPORT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 28.10.12 at 18:44, Hannes Frederic Sowa  wrote:
> This patch fixes following compile error:
> 
> drivers/built-in.o: In function `dbgp_reset_prep':
> linux/drivers/usb/early/ehci-dbgp.c:984: undefined reference to 
> `xen_dbgp_reset_prep'
> drivers/built-in.o: In function `dbgp_external_startup':
> linux/drivers/usb/early/ehci-dbgp.c:619: undefined reference to 
> `xen_dbgp_external_startup'
> 
> EARLY_PRINTK_DBGP should work without USB_SUPPORT.

An alternative patch was previously suggested to address this
build problem.

Jan

> Cc: Jan Beulich 
> Signed-off-by: Hannes Frederic Sowa 
> ---
>  drivers/xen/Kconfig          | 3 +++
>  drivers/xen/Makefile         | 2 +-
>  include/linux/usb/ehci_def.h | 2 +-
>  3 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index 126d8ce..9bb3420 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -206,4 +206,7 @@ config XEN_MCE_LOG
>  	  Allow kernel fetching MCE error from Xen platform and
>  	  converting it into Linux mcelog format for mcelog tools
>  
> +config XEN_DBGP
> +	def_bool y if XEN_DOM0 && (USB_SUPPORT || EARLY_PRINTK_DBGP)
> +
>  endmenu
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index 0e863703..d23ed07 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -9,7 +9,7 @@ nostackp := $(call cc-option, -fno-stack-protector)
>  CFLAGS_features.o			:= $(nostackp)
>  
>  dom0-$(CONFIG_PCI) += pci.o
> -dom0-$(CONFIG_USB_SUPPORT) += dbgp.o
> +dom0-$(CONFIG_XEN_DBGP) += dbgp.o
>  dom0-$(CONFIG_ACPI) += acpi.o
>  dom0-$(CONFIG_X86) += pcpu.o
>  obj-$(CONFIG_XEN_DOM0)			+= $(dom0-y)
> diff --git a/include/linux/usb/ehci_def.h b/include/linux/usb/ehci_def.h
> index daec99a..7d8f7fe 100644
> --- a/include/linux/usb/ehci_def.h
> +++ b/include/linux/usb/ehci_def.h
> @@ -223,7 +223,7 @@ extern struct console early_dbgp_console;
>  
>  struct usb_hcd;
>  
> -#ifdef CONFIG_XEN_DOM0
> +#ifdef CONFIG_XEN_DBGP
>  extern int xen_dbgp_reset_prep(struct usb_hcd *);
>  extern int xen_dbgp_external_startup(struct usb_hcd *);
>  #else




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 09:49:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 09:49:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSlxq-0006Nf-38; Mon, 29 Oct 2012 09:48:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSlxo-0006Na-RT
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 09:48:56 +0000
Received: from [85.158.143.35:21818] by server-3.bemta-4.messagelabs.com id
	44/87-24279-8015E805; Mon, 29 Oct 2012 09:48:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1351504065!12073595!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28798 invoked from network); 29 Oct 2012 09:47:47 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-21.messagelabs.com with SMTP;
	29 Oct 2012 09:47:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 29 Oct 2012 09:47:44 +0000
Message-Id: <508E5EF702000078000A5039@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 29 Oct 2012 09:48:23 +0000
From: "Jan Beulich" 
To: "Christoph Egger" 
References: <508A490B.4050407@amd.com> <508A4935.6090801@amd.com>
In-Reply-To: <508A4935.6090801@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] MCE: consolidate AMD initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 26.10.12 at 10:26, Christoph Egger  wrote:
> On 10/26/12 10:25, Christoph Egger wrote:
>> 
>> Move AMD specific initialization to AMD files.
>> 
>> Signed-off-by: Christoph Egger 

Let's do this properly: There's no K7 supporting 64-bit mode afaict,
so rather than moving around the call to amd_k7_mcheck_init()
can't we just drop it and the whole (inconsistently named) k7.c file?

Also (not in this patch of course), I'd prefer mce_amd_quirks.c
to get merged into mce_amd.c now that we have the latter.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 09:49:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 09:49:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSlxq-0006Nf-38; Mon, 29 Oct 2012 09:48:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSlxo-0006Na-RT
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 09:48:56 +0000
Received: from [85.158.143.35:21818] by server-3.bemta-4.messagelabs.com id
	44/87-24279-8015E805; Mon, 29 Oct 2012 09:48:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1351504065!12073595!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28798 invoked from network); 29 Oct 2012 09:47:47 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-21.messagelabs.com with SMTP;
	29 Oct 2012 09:47:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 29 Oct 2012 09:47:44 +0000
Message-Id: <508E5EF702000078000A5039@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 29 Oct 2012 09:48:23 +0000
From: "Jan Beulich" 
To: "Christoph Egger" 
References: <508A490B.4050407@amd.com> <508A4935.6090801@amd.com>
In-Reply-To: <508A4935.6090801@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] MCE: consolidate AMD initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 26.10.12 at 10:26, Christoph Egger  wrote:
> On 10/26/12 10:25, Christoph Egger wrote:
>> 
>> Move AMD specific initialization to AMD files.
>> 
>> Signed-off-by: Christoph Egger 

Let's do this properly: There's no K7 supporting 64-bit mode afaict,
so rather than moving around the call to amd_k7_mcheck_init()
can't we just drop it and the whole (inconsistently named) k7.c file?

Also (not in this patch of course), I'd prefer mce_amd_quirks.c
to get merged into mce_amd.c now that we have the latter.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 09:53:03 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 09:53:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSm1Z-0006jo-42; Mon, 29 Oct 2012 09:52:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSm1X-0006jR-KB
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 09:52:47 +0000
Received: from [85.158.143.35:65380] by server-3.bemta-4.messagelabs.com id
	87/AE-24279-EE15E805; Mon, 29 Oct 2012 09:52:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1351504354!5095536!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2083 invoked from network); 29 Oct 2012 09:52:35 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-21.messagelabs.com with SMTP;
	29 Oct 2012 09:52:35 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 29 Oct 2012 09:52:34 +0000
Message-Id: <508E601902000078000A5042@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 29 Oct 2012 09:53:13 +0000
From: "Jan Beulich" 
To: "Ian Campbell" ,
	"Roger Cruz" 
References: <844D15D284C78547BB0DAEE12D33A1B67C212BB956@FTLPMAILBOX02.citrite.net>
	<844D15D284C78547BB0DAEE12D33A1B67C212BB958@FTLPMAILBOX02.citrite.net>
	,<1351276718.12176.1.camel@dagon.hellion.org.uk>
	<844D15D284C78547BB0DAEE12D33A1B67C212BB95B@FTLPMAILBOX02.citrite.net>
	<1351334777.12176.15.camel@dagon.hellion.org.uk>
In-Reply-To: <1351334777.12176.15.camel@dagon.hellion.org.uk>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Tracking down a boot speed issue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 27.10.12 at 12:46, Ian Campbell  wrote:
> On Fri, 2012-10-26 at 20:02 +0100, Roger Cruz wrote:
>> A question remains in my mind as why the times are variable.  Why does
>> it take .67 secs and 1.6 secs other times for exactly the same boot
>> code?
> 
> Something before this point takes a variable amount of time perhaps? I
> don't know what happens before this point in the boot.

This may be a direct effect of not being the only VM on the
underlying host (i.e. there can be any amount of stolen time
included in that initial time period).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 09:53:03 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 09:53:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSm1Z-0006jo-42; Mon, 29 Oct 2012 09:52:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSm1X-0006jR-KB
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 09:52:47 +0000
Received: from [85.158.143.35:65380] by server-3.bemta-4.messagelabs.com id
	87/AE-24279-EE15E805; Mon, 29 Oct 2012 09:52:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1351504354!5095536!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2083 invoked from network); 29 Oct 2012 09:52:35 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-21.messagelabs.com with SMTP;
	29 Oct 2012 09:52:35 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 29 Oct 2012 09:52:34 +0000
Message-Id: <508E601902000078000A5042@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 29 Oct 2012 09:53:13 +0000
From: "Jan Beulich" 
To: "Ian Campbell" ,
	"Roger Cruz" 
References: <844D15D284C78547BB0DAEE12D33A1B67C212BB956@FTLPMAILBOX02.citrite.net>
	<844D15D284C78547BB0DAEE12D33A1B67C212BB958@FTLPMAILBOX02.citrite.net>
	,<1351276718.12176.1.camel@dagon.hellion.org.uk>
	<844D15D284C78547BB0DAEE12D33A1B67C212BB95B@FTLPMAILBOX02.citrite.net>
	<1351334777.12176.15.camel@dagon.hellion.org.uk>
In-Reply-To: <1351334777.12176.15.camel@dagon.hellion.org.uk>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] Tracking down a boot speed issue
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 27.10.12 at 12:46, Ian Campbell  wrote:
> On Fri, 2012-10-26 at 20:02 +0100, Roger Cruz wrote:
>> A question remains in my mind as why the times are variable.  Why does
>> it take .67 secs and 1.6 secs other times for exactly the same boot
>> code?
> 
> Something before this point takes a variable amount of time perhaps? I
> don't know what happens before this point in the boot.

This may be a direct effect of not being the only VM on the
underlying host (i.e. there can be any amount of stolen time
included in that initial time period).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 09:53:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 09:53:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSm1t-0006nG-HA; Mon, 29 Oct 2012 09:53:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSm1s-0006my-Pm
	for xen-devel@lists.xensource.com; Mon, 29 Oct 2012 09:53:09 +0000
Received: from [85.158.137.99:13115] by server-9.bemta-3.messagelabs.com id
	0F/C7-16841-3025E805; Mon, 29 Oct 2012 09:53:07 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1351504374!23321223!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODIxNDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2927 invoked from network); 29 Oct 2012 09:52:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Oct 2012 09:52:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,670,1344211200"; d="scan'208";a="212702465"
Received: from unknown (HELO FTLPEX01CL03.citrite.net) ([10.13.107.80])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	29 Oct 2012 09:52:54 +0000
Received: from ukmail1.uk.xensource.com (10.9.154.239) by
	FTLPEX01CL03.citrite.net (10.13.107.77) with Microsoft SMTP Server id
	14.2.318.1; Mon, 29 Oct 2012 05:52:53 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TSm1Y-0006DE-3p;
	Mon, 29 Oct 2012 09:52:48 +0000
Date: Mon, 29 Oct 2012 09:52:29 +0000
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Tim Deegan 
In-Reply-To: <20121027104428.GB89901@ocelot.phlegethon.org>
Message-ID: 
References: 
	<1351091027-20740-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20121024155945.GD39126@ocelot.phlegethon.org>
	
	<20121026090141.GB76080@ocelot.phlegethon.org>
	
	
	
	<20121026165549.GF76080@ocelot.phlegethon.org>
	
	<20121027104428.GB89901@ocelot.phlegethon.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	Ian Campbell ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 6/7] xen/arm: flush D-cache and I-cache when
 appropriate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 27 Oct 2012, Tim Deegan wrote:
> At 19:40 +0100 on 26 Oct (1351280413), Stefano Stabellini wrote:
> > > No!  It's always safe to flush the entire line -- regardless of what
> > > other writes might be happening to it.  After all, the cache controller
> > > might evict that line on its own at any time, so nothing can be relying
> > > on its _not_ being flushed.
> > > 
> > > The only problem with not knowing how big a cacheline is is this: if the
> > > object is _bigger_ than a cache line we might use one DCCMVAC where more
> > > than one is needed.  We can avoid that by a compile-time check on some
> > > sort of architectural minimum cacheline size.
> >  
> > If we want to do that then we need to pass a size argument to
> > flush_xen_dcache_va and have a loop in the function, each iteration
> > flushing a cacheline:
> > 
> > static inline void flush_xen_dcache_va(void *p, unsigned long size)
> > {
> >     unsigned long cacheline_size = READ_CP32(CCSIDR);
> >     unsigned long i;
> >     for (i = 0; i < size; i += cacheline_size, p += cacheline_size) {
> >         asm volatile (
> >             "dsb;"
> >             STORE_CP32(0, DCCMVAC)
> >             "dsb;"
> >             : : "r" (p));
> >     }
> > }
> 
> I think we should have two functions.  One should look almost like that
> and be for flushing large ranges, and one much simpler for flushing
> small items.  Like this (totally untested, uncompiled even):
> 
>  #define MIN_CACHELINE_BYTES 32 // or whatever
> 
>  /* In setup.c somewhere. */
>  if ( READ_CP32(CCSIDR) < MIN_CACHELINE_BYTES )
>      panic("CPU has preposterously small cache lines");
> 
>  /* Function for flushing medium-sized areas.
>   * if 'range' is large enough we might want to use model-specific
>   * full-cache flushes. */
>  static inline void flush_xen_dcache_va_range(void *p, unsigned long size)
>  {
>      void *end;
>      unsigned long cacheline_bytes = READ_CP32(CCSIDR);
>      barrier();       /* So the compiler issues all writes to the range */
>      dsb();           /* So the CPU issues all writes to the range */ 
>      for ( end = p + size; p < end; p += cacheline_bytes )
>          WRITE_CP32(DCCMVAC, p);
>      dsb();           /* So we know the flushes happen before continuing */
>  }
> 
>  /* Macro for flushing a single small item.  The predicate is always 
>   * compile-time constant so this will compile down to 3 instructions in
>   * the common case.  Make sure to call it with the correct type of
>   * pointer! */
>  #define flush_xen_dcache_va(p) do {                       \
>      typeof(p) _p = (p);                                   \
>      if ( (sizeof *_p) > MIN_CACHELINE_BYTES )             \
>          flush_xen_dcache_va_range(_p, sizeof *_p);        \
>      else                                                  \
>          asm volatile (                                    \
>              "dsb;"   /* Finish all earlier writes */      \
>              STORE_CP32(0, DCCMVAC)                        \
>              "dsb;"   /* Finish flush before continuing */ \
>              : : "r" (_p), "m" (*_p));                     \
>  } while (0)
> 
> What do you think?
 
I think that's OK, the macro doesn't look as bad as I thought it would
:)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 09:53:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 09:53:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSm1t-0006nG-HA; Mon, 29 Oct 2012 09:53:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSm1s-0006my-Pm
	for xen-devel@lists.xensource.com; Mon, 29 Oct 2012 09:53:09 +0000
Received: from [85.158.137.99:13115] by server-9.bemta-3.messagelabs.com id
	0F/C7-16841-3025E805; Mon, 29 Oct 2012 09:53:07 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1351504374!23321223!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODIxNDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2927 invoked from network); 29 Oct 2012 09:52:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Oct 2012 09:52:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,670,1344211200"; d="scan'208";a="212702465"
Received: from unknown (HELO FTLPEX01CL03.citrite.net) ([10.13.107.80])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	29 Oct 2012 09:52:54 +0000
Received: from ukmail1.uk.xensource.com (10.9.154.239) by
	FTLPEX01CL03.citrite.net (10.13.107.77) with Microsoft SMTP Server id
	14.2.318.1; Mon, 29 Oct 2012 05:52:53 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TSm1Y-0006DE-3p;
	Mon, 29 Oct 2012 09:52:48 +0000
Date: Mon, 29 Oct 2012 09:52:29 +0000
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Tim Deegan 
In-Reply-To: <20121027104428.GB89901@ocelot.phlegethon.org>
Message-ID: 
References: 
	<1351091027-20740-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20121024155945.GD39126@ocelot.phlegethon.org>
	
	<20121026090141.GB76080@ocelot.phlegethon.org>
	
	
	
	<20121026165549.GF76080@ocelot.phlegethon.org>
	
	<20121027104428.GB89901@ocelot.phlegethon.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	Ian Campbell ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 6/7] xen/arm: flush D-cache and I-cache when
 appropriate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 27 Oct 2012, Tim Deegan wrote:
> At 19:40 +0100 on 26 Oct (1351280413), Stefano Stabellini wrote:
> > > No!  It's always safe to flush the entire line -- regardless of what
> > > other writes might be happening to it.  After all, the cache controller
> > > might evict that line on its own at any time, so nothing can be relying
> > > on its _not_ being flushed.
> > > 
> > > The only problem with not knowing how big a cacheline is is this: if the
> > > object is _bigger_ than a cache line we might use one DCCMVAC where more
> > > than one is needed.  We can avoid that by a compile-time check on some
> > > sort of architectural minimum cacheline size.
> >  
> > If we want to do that then we need to pass a size argument to
> > flush_xen_dcache_va and have a loop in the function, each iteration
> > flushing a cacheline:
> > 
> > static inline void flush_xen_dcache_va(void *p, unsigned long size)
> > {
> >     unsigned long cacheline_size = READ_CP32(CCSIDR);
> >     unsigned long i;
> >     for (i = 0; i < size; i += cacheline_size, p += cacheline_size) {
> >         asm volatile (
> >             "dsb;"
> >             STORE_CP32(0, DCCMVAC)
> >             "dsb;"
> >             : : "r" (p));
> >     }
> > }
> 
> I think we should have two functions.  One should look almost like that
> and be for flushing large ranges, and one much simpler for flushing
> small items.  Like this (totally untested, uncompiled even):
> 
>  #define MIN_CACHELINE_BYTES 32 // or whatever
> 
>  /* In setup.c somewhere. */
>  if ( READ_CP32(CCSIDR) < MIN_CACHELINE_BYTES )
>      panic("CPU has preposterously small cache lines");
> 
>  /* Function for flushing medium-sized areas.
>   * if 'range' is large enough we might want to use model-specific
>   * full-cache flushes. */
>  static inline void flush_xen_dcache_va_range(void *p, unsigned long size)
>  {
>      void *end;
>      unsigned long cacheline_bytes = READ_CP32(CCSIDR);
>      barrier();       /* So the compiler issues all writes to the range */
>      dsb();           /* So the CPU issues all writes to the range */ 
>      for ( end = p + size; p < end; p += cacheline_bytes )
>          WRITE_CP32(DCCMVAC, p);
>      dsb();           /* So we know the flushes happen before continuing */
>  }
> 
>  /* Macro for flushing a single small item.  The predicate is always 
>   * compile-time constant so this will compile down to 3 instructions in
>   * the common case.  Make sure to call it with the correct type of
>   * pointer! */
>  #define flush_xen_dcache_va(p) do {                       \
>      typeof(p) _p = (p);                                   \
>      if ( (sizeof *_p) > MIN_CACHELINE_BYTES )             \
>          flush_xen_dcache_va_range(_p, sizeof *_p);        \
>      else                                                  \
>          asm volatile (                                    \
>              "dsb;"   /* Finish all earlier writes */      \
>              STORE_CP32(0, DCCMVAC)                        \
>              "dsb;"   /* Finish flush before continuing */ \
>              : : "r" (_p), "m" (*_p));                     \
>  } while (0)
> 
> What do you think?
 
I think that's OK, the macro doesn't look as bad as I thought it would
:)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 09:53:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 09:53:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSm2R-0006vV-VB; Mon, 29 Oct 2012 09:53:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSm2Q-0006uw-DP
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 09:53:42 +0000
Received: from [85.158.143.99:20543] by server-1.bemta-4.messagelabs.com id
	37/20-19134-5225E805; Mon, 29 Oct 2012 09:53:41 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1351504419!26853482!1
X-Originating-IP: [65.55.88.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14587 invoked from network); 29 Oct 2012 09:53:41 -0000
Received: from tx2ehsobe003.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.13)
	by server-13.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	29 Oct 2012 09:53:41 -0000
Received: from mail107-tx2-R.bigfish.com (10.9.14.250) by
	TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id
	14.1.225.23; Mon, 29 Oct 2012 09:53:39 +0000
Received: from mail107-tx2 (localhost [127.0.0.1])	by
	mail107-tx2-R.bigfish.com (Postfix) with ESMTP id 32C804C0088;
	Mon, 29 Oct 2012 09:53:39 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: -3
X-BigFish: VPS-3(zzbb2dI98dI1432Izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h)
Received: from mail107-tx2 (localhost.localdomain [127.0.0.1]) by mail107-tx2
	(MessageSwitch) id 1351504416500520_5304;
	Mon, 29 Oct 2012 09:53:36 +0000 (UTC)
Received: from TX2EHSMHS032.bigfish.com (unknown [10.9.14.241])	by
	mail107-tx2.bigfish.com (Postfix) with ESMTP id 7000C3E006E;
	Mon, 29 Oct 2012 09:53:36 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS032.bigfish.com (10.9.99.132) with Microsoft SMTP Server id
	14.1.225.23; Mon, 29 Oct 2012 09:53:36 +0000
X-WSS-ID: 0MCNFH9-01-RDS-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2AA0D10282C6;	Mon, 29 Oct 2012 04:53:33 -0500 (CDT)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Mon, 29 Oct 2012 04:53:38 -0500
Received: from STOREXDAG02.amd.com (10.1.13.11) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Mon, 29 Oct 2012 04:53:33 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag02.amd.com
	(10.1.13.11) with Microsoft SMTP Server id 14.2.318.4; Mon, 29 Oct 2012
	05:53:31 -0400
Message-ID: <508E5219.5080900@amd.com>
Date: Mon, 29 Oct 2012 10:53:29 +0100
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich 
References: <508A490B.4050407@amd.com> <508A4935.6090801@amd.com>
	<508E5EF702000078000A5039@nat28.tlf.novell.com>
In-Reply-To: <508E5EF702000078000A5039@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] MCE: consolidate AMD initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/29/12 10:48, Jan Beulich wrote:
>>>> On 26.10.12 at 10:26, Christoph Egger  wrote:
>> On 10/26/12 10:25, Christoph Egger wrote:
>>>
>>> Move AMD specific initialization to AMD files.
>>>
>>> Signed-off-by: Christoph Egger 
> 
> Let's do this properly: There's no K7 supporting 64-bit mode afaict,
> so rather than moving around the call to amd_k7_mcheck_init()
> can't we just drop it and the whole (inconsistently named) k7.c file?

Yes.

> Also (not in this patch of course), I'd prefer mce_amd_quirks.c
> to get merged into mce_amd.c now that we have the latter.

Ok.

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 09:53:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 09:53:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSm2R-0006vV-VB; Mon, 29 Oct 2012 09:53:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSm2Q-0006uw-DP
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 09:53:42 +0000
Received: from [85.158.143.99:20543] by server-1.bemta-4.messagelabs.com id
	37/20-19134-5225E805; Mon, 29 Oct 2012 09:53:41 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1351504419!26853482!1
X-Originating-IP: [65.55.88.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14587 invoked from network); 29 Oct 2012 09:53:41 -0000
Received: from tx2ehsobe003.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.13)
	by server-13.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	29 Oct 2012 09:53:41 -0000
Received: from mail107-tx2-R.bigfish.com (10.9.14.250) by
	TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id
	14.1.225.23; Mon, 29 Oct 2012 09:53:39 +0000
Received: from mail107-tx2 (localhost [127.0.0.1])	by
	mail107-tx2-R.bigfish.com (Postfix) with ESMTP id 32C804C0088;
	Mon, 29 Oct 2012 09:53:39 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: -3
X-BigFish: VPS-3(zzbb2dI98dI1432Izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h)
Received: from mail107-tx2 (localhost.localdomain [127.0.0.1]) by mail107-tx2
	(MessageSwitch) id 1351504416500520_5304;
	Mon, 29 Oct 2012 09:53:36 +0000 (UTC)
Received: from TX2EHSMHS032.bigfish.com (unknown [10.9.14.241])	by
	mail107-tx2.bigfish.com (Postfix) with ESMTP id 7000C3E006E;
	Mon, 29 Oct 2012 09:53:36 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS032.bigfish.com (10.9.99.132) with Microsoft SMTP Server id
	14.1.225.23; Mon, 29 Oct 2012 09:53:36 +0000
X-WSS-ID: 0MCNFH9-01-RDS-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2AA0D10282C6;	Mon, 29 Oct 2012 04:53:33 -0500 (CDT)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Mon, 29 Oct 2012 04:53:38 -0500
Received: from STOREXDAG02.amd.com (10.1.13.11) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Mon, 29 Oct 2012 04:53:33 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag02.amd.com
	(10.1.13.11) with Microsoft SMTP Server id 14.2.318.4; Mon, 29 Oct 2012
	05:53:31 -0400
Message-ID: <508E5219.5080900@amd.com>
Date: Mon, 29 Oct 2012 10:53:29 +0100
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich 
References: <508A490B.4050407@amd.com> <508A4935.6090801@amd.com>
	<508E5EF702000078000A5039@nat28.tlf.novell.com>
In-Reply-To: <508E5EF702000078000A5039@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] MCE: consolidate AMD initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/29/12 10:48, Jan Beulich wrote:
>>>> On 26.10.12 at 10:26, Christoph Egger  wrote:
>> On 10/26/12 10:25, Christoph Egger wrote:
>>>
>>> Move AMD specific initialization to AMD files.
>>>
>>> Signed-off-by: Christoph Egger 
> 
> Let's do this properly: There's no K7 supporting 64-bit mode afaict,
> so rather than moving around the call to amd_k7_mcheck_init()
> can't we just drop it and the whole (inconsistently named) k7.c file?

Yes.

> Also (not in this patch of course), I'd prefer mce_amd_quirks.c
> to get merged into mce_amd.c now that we have the latter.

Ok.

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 09:54:03 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 09:54:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSm2c-0006yT-D5; Mon, 29 Oct 2012 09:53:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSm2b-0006xo-4d
	for xen-devel@lists.xensource.com; Mon, 29 Oct 2012 09:53:53 +0000
Received: from [85.158.139.211:14472] by server-10.bemta-5.messagelabs.com id
	8A/04-01025-0325E805; Mon, 29 Oct 2012 09:53:52 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1351504430!17971681!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODIxNDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11931 invoked from network); 29 Oct 2012 09:53:51 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Oct 2012 09:53:51 -0000
X-IronPort-AV: E=Sophos;i="4.80,670,1344211200"; d="scan'208";a="212702490"
Received: from unknown (HELO FTLPEX01CL03.citrite.net) ([10.13.107.80])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	29 Oct 2012 09:53:37 +0000
Received: from ukmail1.uk.xensource.com (10.9.154.239) by
	FTLPEX01CL03.citrite.net (10.13.107.77) with Microsoft SMTP Server id
	14.2.318.1; Mon, 29 Oct 2012 05:53:36 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TSm2F-0006Ek-E7;
	Mon, 29 Oct 2012 09:53:31 +0000
Date: Mon, 29 Oct 2012 09:53:13 +0000
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Tim Deegan 
In-Reply-To: <20121027115423.GA90857@ocelot.phlegethon.org>
Message-ID: 
References: <1351091027-20740-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20121024155945.GD39126@ocelot.phlegethon.org>
	
	<20121026090141.GB76080@ocelot.phlegethon.org>
	
	
	
	<20121026165549.GF76080@ocelot.phlegethon.org>
	
	<20121027104428.GB89901@ocelot.phlegethon.org>
	<20121027115423.GA90857@ocelot.phlegethon.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	Ian Campbell ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 6/7] xen/arm: flush D-cache and I-cache when
 appropriate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 27 Oct 2012, Tim Deegan wrote:
> At 11:44 +0100 on 27 Oct (1351338268), Tim Deegan wrote:
> >  /* Function for flushing medium-sized areas.
> >   * if 'range' is large enough we might want to use model-specific
> >   * full-cache flushes. */
> >  static inline void flush_xen_dcache_va_range(void *p, unsigned long size)
> >  {
> >      void *end;
> >      unsigned long cacheline_bytes = READ_CP32(CCSIDR);
> >      barrier();       /* So the compiler issues all writes to the range */
> >      dsb();           /* So the CPU issues all writes to the range */ 
> 
> Oh - I just noticed that the way we've defined dsb() it includes a
> memory clobber.   So I guess we don't need barrier() as well there.
> 
> We might want to look at the other users of dsb() and see if we want to
> drop the memory clobber from it as well.

> But OTOH we may be getting way into premature optimization already. :)
 
My thoughts exactly.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 09:54:03 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 09:54:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSm2c-0006yT-D5; Mon, 29 Oct 2012 09:53:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSm2b-0006xo-4d
	for xen-devel@lists.xensource.com; Mon, 29 Oct 2012 09:53:53 +0000
Received: from [85.158.139.211:14472] by server-10.bemta-5.messagelabs.com id
	8A/04-01025-0325E805; Mon, 29 Oct 2012 09:53:52 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1351504430!17971681!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODIxNDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11931 invoked from network); 29 Oct 2012 09:53:51 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Oct 2012 09:53:51 -0000
X-IronPort-AV: E=Sophos;i="4.80,670,1344211200"; d="scan'208";a="212702490"
Received: from unknown (HELO FTLPEX01CL03.citrite.net) ([10.13.107.80])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	29 Oct 2012 09:53:37 +0000
Received: from ukmail1.uk.xensource.com (10.9.154.239) by
	FTLPEX01CL03.citrite.net (10.13.107.77) with Microsoft SMTP Server id
	14.2.318.1; Mon, 29 Oct 2012 05:53:36 -0400
Received: from kaball.uk.xensource.com ([10.80.2.59])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TSm2F-0006Ek-E7;
	Mon, 29 Oct 2012 09:53:31 +0000
Date: Mon, 29 Oct 2012 09:53:13 +0000
From: Stefano Stabellini 
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Tim Deegan 
In-Reply-To: <20121027115423.GA90857@ocelot.phlegethon.org>
Message-ID: 
References: <1351091027-20740-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20121024155945.GD39126@ocelot.phlegethon.org>
	
	<20121026090141.GB76080@ocelot.phlegethon.org>
	
	
	
	<20121026165549.GF76080@ocelot.phlegethon.org>
	
	<20121027104428.GB89901@ocelot.phlegethon.org>
	<20121027115423.GA90857@ocelot.phlegethon.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" ,
	Ian Campbell ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 6/7] xen/arm: flush D-cache and I-cache when
 appropriate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 27 Oct 2012, Tim Deegan wrote:
> At 11:44 +0100 on 27 Oct (1351338268), Tim Deegan wrote:
> >  /* Function for flushing medium-sized areas.
> >   * if 'range' is large enough we might want to use model-specific
> >   * full-cache flushes. */
> >  static inline void flush_xen_dcache_va_range(void *p, unsigned long size)
> >  {
> >      void *end;
> >      unsigned long cacheline_bytes = READ_CP32(CCSIDR);
> >      barrier();       /* So the compiler issues all writes to the range */
> >      dsb();           /* So the CPU issues all writes to the range */ 
> 
> Oh - I just noticed that the way we've defined dsb() it includes a
> memory clobber.   So I guess we don't need barrier() as well there.
> 
> We might want to look at the other users of dsb() and see if we want to
> drop the memory clobber from it as well.

> But OTOH we may be getting way into premature optimization already. :)
 
My thoughts exactly.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 09:55:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 09:55:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSm49-0007L2-UY; Mon, 29 Oct 2012 09:55:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSm48-0007Kc-8V
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 09:55:28 +0000
Received: from [85.158.143.99:10920] by server-3.bemta-4.messagelabs.com id
	8C/83-24279-F825E805; Mon, 29 Oct 2012 09:55:27 +0000
X-Env-Sender: peter.maloney@brockmann-consult.de
X-Msg-Ref: server-8.tower-216.messagelabs.com!1351504526!17986013!1
X-Originating-IP: [212.227.17.8]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjE3LjggPT4gNjg5ODg=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjE3LjggPT4gNjg5ODg=\n,BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25369 invoked from network); 29 Oct 2012 09:55:26 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.17.8)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Oct 2012 09:55:26 -0000
Received: from [10.3.0.26] ([141.4.215.32])
	by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis)
	id 0LoZ6A-1SvLvT2m7u-00gbd2; Mon, 29 Oct 2012 10:55:25 +0100
Message-ID: <508E528C.7040006@brockmann-consult.de>
Date: Mon, 29 Oct 2012 10:55:24 +0100
From: Peter Maloney 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120825 Thunderbird/15.0
MIME-Version: 1.0
To: xen-devel@lists.xen.org
X-Enigmail-Version: 1.4.4
X-Provags-ID: V02:K0:V3Hh9e/0HL0huxFGNpvH0lYEk3cqqnmSKC0T4hTHgbD
	tBqJwEwzZBZB3x6rt4lvBBMB5d4SiGdLYyZOGbuSVPRS2JmQC4
	KFZA9ct+Br0zEPvzGfqp0XKvmyj8Gs/1jyAV19V+/xHa0LUNMA
	J6v3Z7Lm3sQ0ZO8sTsXquWSmjw5bCAkSXEx9oAcOIw8hrxKx23
	OwLc9HjTNrrOe5nCRnA9zeTsxQMacMSJ2Vyv7p4wZ5Zj3J0IPB
	egqjLZNReS7v2itipv9/3DYEY+pDCRQGJ1xnYPmP2nHeSfUJNh
	cHX87Msw+oaH/mb02h7vIncr+lnoefYiBeQMFSrxWwdb1VvXgw
	8Y4s9hGBPEQP8LYdip3EQ/zuKy9FlJTUJQI6SGZNQ
Subject: [Xen-devel] xendocs - config syntax errors should refer you to
	"xl.cfg" man page
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 I suggest every config syntax error message should refer you to the
"xl.cfg" man page (I used xen for months before knowing such a page exists)

The same should go for your loader, eg. qemu-dm's error messages should
tell you where to find the man page listing sound card names if you
specified one that doesn't exist which was not detected by xm/xl, but an
error when it gets to the loader.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 09:55:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 09:55:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSm49-0007L2-UY; Mon, 29 Oct 2012 09:55:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSm48-0007Kc-8V
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 09:55:28 +0000
Received: from [85.158.143.99:10920] by server-3.bemta-4.messagelabs.com id
	8C/83-24279-F825E805; Mon, 29 Oct 2012 09:55:27 +0000
X-Env-Sender: peter.maloney@brockmann-consult.de
X-Msg-Ref: server-8.tower-216.messagelabs.com!1351504526!17986013!1
X-Originating-IP: [212.227.17.8]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjE3LjggPT4gNjg5ODg=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjE3LjggPT4gNjg5ODg=\n,BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25369 invoked from network); 29 Oct 2012 09:55:26 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.17.8)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Oct 2012 09:55:26 -0000
Received: from [10.3.0.26] ([141.4.215.32])
	by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis)
	id 0LoZ6A-1SvLvT2m7u-00gbd2; Mon, 29 Oct 2012 10:55:25 +0100
Message-ID: <508E528C.7040006@brockmann-consult.de>
Date: Mon, 29 Oct 2012 10:55:24 +0100
From: Peter Maloney 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120825 Thunderbird/15.0
MIME-Version: 1.0
To: xen-devel@lists.xen.org
X-Enigmail-Version: 1.4.4
X-Provags-ID: V02:K0:V3Hh9e/0HL0huxFGNpvH0lYEk3cqqnmSKC0T4hTHgbD
	tBqJwEwzZBZB3x6rt4lvBBMB5d4SiGdLYyZOGbuSVPRS2JmQC4
	KFZA9ct+Br0zEPvzGfqp0XKvmyj8Gs/1jyAV19V+/xHa0LUNMA
	J6v3Z7Lm3sQ0ZO8sTsXquWSmjw5bCAkSXEx9oAcOIw8hrxKx23
	OwLc9HjTNrrOe5nCRnA9zeTsxQMacMSJ2Vyv7p4wZ5Zj3J0IPB
	egqjLZNReS7v2itipv9/3DYEY+pDCRQGJ1xnYPmP2nHeSfUJNh
	cHX87Msw+oaH/mb02h7vIncr+lnoefYiBeQMFSrxWwdb1VvXgw
	8Y4s9hGBPEQP8LYdip3EQ/zuKy9FlJTUJQI6SGZNQ
Subject: [Xen-devel] xendocs - config syntax errors should refer you to
	"xl.cfg" man page
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 I suggest every config syntax error message should refer you to the
"xl.cfg" man page (I used xen for months before knowing such a page exists)

The same should go for your loader, eg. qemu-dm's error messages should
tell you where to find the man page listing sound card names if you
specified one that doesn't exist which was not detected by xm/xl, but an
error when it gets to the loader.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 10:03:44 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 10:03:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSmBu-0008Ae-Ta; Mon, 29 Oct 2012 10:03:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSmBs-0008AM-Ta
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 10:03:29 +0000
Received: from [85.158.139.211:25949] by server-15.bemta-5.messagelabs.com id
	03/3A-26920-0745E805; Mon, 29 Oct 2012 10:03:28 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1351505006!18012325!1
X-Originating-IP: [216.32.180.30]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18540 invoked from network); 29 Oct 2012 10:03:27 -0000
Received: from va3ehsobe010.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.30)
	by server-3.tower-206.messagelabs.com with AES128-SHA encrypted SMTP;
	29 Oct 2012 10:03:27 -0000
Received: from mail208-va3-R.bigfish.com (10.7.14.239) by
	VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id
	14.1.225.23; Mon, 29 Oct 2012 10:03:26 +0000
Received: from mail208-va3 (localhost [127.0.0.1])	by
	mail208-va3-R.bigfish.com (Postfix) with ESMTP id 31151720141;
	Mon, 29 Oct 2012 10:03:26 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: -3
X-BigFish: VPS-3(zzbb2dI98dI1432Izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h)
Received: from mail208-va3 (localhost.localdomain [127.0.0.1]) by mail208-va3
	(MessageSwitch) id 1351505003522737_11652;
	Mon, 29 Oct 2012 10:03:23 +0000 (UTC)
Received: from VA3EHSMHS018.bigfish.com (unknown [10.7.14.251])	by
	mail208-va3.bigfish.com (Postfix) with ESMTP id 7BA22D40065;
	Mon, 29 Oct 2012 10:03:23 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS018.bigfish.com (10.7.99.28) with Microsoft SMTP Server id
	14.1.225.23; Mon, 29 Oct 2012 10:03:19 +0000
X-WSS-ID: 0MCNFXI-02-8EF-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2ADC9C82FB;	Mon, 29 Oct 2012 05:03:18 -0500 (CDT)
Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Mon, 29 Oct 2012 05:03:23 -0500
Received: from STOREXDAG01.amd.com (10.1.13.10) by sausexdag03.amd.com
	(163.181.55.3) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Mon, 29 Oct 2012 05:03:18 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag01.amd.com
	(10.1.13.10) with Microsoft SMTP Server id 14.2.318.4; Mon, 29 Oct 2012
	06:03:16 -0400
Message-ID: <508E5463.1040100@amd.com>
Date: Mon, 29 Oct 2012 11:03:15 +0100
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich 
References: <508A490B.4050407@amd.com> <508A4935.6090801@amd.com>
	<508E5EF702000078000A5039@nat28.tlf.novell.com>
In-Reply-To: <508E5EF702000078000A5039@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] MCE: consolidate AMD initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/29/12 10:48, Jan Beulich wrote:
>>>> On 26.10.12 at 10:26, Christoph Egger  wrote:
>> On 10/26/12 10:25, Christoph Egger wrote:
>>>
>>> Move AMD specific initialization to AMD files.
>>>
>>> Signed-off-by: Christoph Egger 
> 
> Let's do this properly: There's no K7 supporting 64-bit mode afaict,
> so rather than moving around the call to amd_k7_mcheck_init()
> can't we just drop it and the whole (inconsistently named) k7.c file?

I think it is better to apply this first and then remove k7 to
simplify backporting if needed/wanted.

> Also (not in this patch of course), I'd prefer mce_amd_quirks.c
> to get merged into mce_amd.c now that we have the latter.

After some thinking is there some good reason to do this?

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 10:03:44 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 10:03:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSmBu-0008Ae-Ta; Mon, 29 Oct 2012 10:03:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSmBs-0008AM-Ta
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 10:03:29 +0000
Received: from [85.158.139.211:25949] by server-15.bemta-5.messagelabs.com id
	03/3A-26920-0745E805; Mon, 29 Oct 2012 10:03:28 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1351505006!18012325!1
X-Originating-IP: [216.32.180.30]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18540 invoked from network); 29 Oct 2012 10:03:27 -0000
Received: from va3ehsobe010.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.30)
	by server-3.tower-206.messagelabs.com with AES128-SHA encrypted SMTP;
	29 Oct 2012 10:03:27 -0000
Received: from mail208-va3-R.bigfish.com (10.7.14.239) by
	VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id
	14.1.225.23; Mon, 29 Oct 2012 10:03:26 +0000
Received: from mail208-va3 (localhost [127.0.0.1])	by
	mail208-va3-R.bigfish.com (Postfix) with ESMTP id 31151720141;
	Mon, 29 Oct 2012 10:03:26 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: -3
X-BigFish: VPS-3(zzbb2dI98dI1432Izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h)
Received: from mail208-va3 (localhost.localdomain [127.0.0.1]) by mail208-va3
	(MessageSwitch) id 1351505003522737_11652;
	Mon, 29 Oct 2012 10:03:23 +0000 (UTC)
Received: from VA3EHSMHS018.bigfish.com (unknown [10.7.14.251])	by
	mail208-va3.bigfish.com (Postfix) with ESMTP id 7BA22D40065;
	Mon, 29 Oct 2012 10:03:23 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS018.bigfish.com (10.7.99.28) with Microsoft SMTP Server id
	14.1.225.23; Mon, 29 Oct 2012 10:03:19 +0000
X-WSS-ID: 0MCNFXI-02-8EF-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2ADC9C82FB;	Mon, 29 Oct 2012 05:03:18 -0500 (CDT)
Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Mon, 29 Oct 2012 05:03:23 -0500
Received: from STOREXDAG01.amd.com (10.1.13.10) by sausexdag03.amd.com
	(163.181.55.3) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Mon, 29 Oct 2012 05:03:18 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag01.amd.com
	(10.1.13.10) with Microsoft SMTP Server id 14.2.318.4; Mon, 29 Oct 2012
	06:03:16 -0400
Message-ID: <508E5463.1040100@amd.com>
Date: Mon, 29 Oct 2012 11:03:15 +0100
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich 
References: <508A490B.4050407@amd.com> <508A4935.6090801@amd.com>
	<508E5EF702000078000A5039@nat28.tlf.novell.com>
In-Reply-To: <508E5EF702000078000A5039@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] MCE: consolidate AMD initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/29/12 10:48, Jan Beulich wrote:
>>>> On 26.10.12 at 10:26, Christoph Egger  wrote:
>> On 10/26/12 10:25, Christoph Egger wrote:
>>>
>>> Move AMD specific initialization to AMD files.
>>>
>>> Signed-off-by: Christoph Egger 
> 
> Let's do this properly: There's no K7 supporting 64-bit mode afaict,
> so rather than moving around the call to amd_k7_mcheck_init()
> can't we just drop it and the whole (inconsistently named) k7.c file?

I think it is better to apply this first and then remove k7 to
simplify backporting if needed/wanted.

> Also (not in this patch of course), I'd prefer mce_amd_quirks.c
> to get merged into mce_amd.c now that we have the latter.

After some thinking is there some good reason to do this?

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 10:20:21 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 10:20:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSmRx-00005d-E7; Mon, 29 Oct 2012 10:20:05 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSmRv-00005Y-Uv
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 10:20:04 +0000
Received: from [193.109.254.147:6999] by server-15.bemta-14.messagelabs.com id
	2F/33-12105-3585E805; Mon, 29 Oct 2012 10:20:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1351506002!8808934!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6096 invoked from network); 29 Oct 2012 10:20:02 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-27.messagelabs.com with SMTP;
	29 Oct 2012 10:20:02 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 29 Oct 2012 10:20:01 +0000
Message-Id: <508E668702000078000A514D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 29 Oct 2012 10:20:39 +0000
From: "Jan Beulich" 
To: "Christoph Egger" 
References: <506EE9A7.6090009@amd.com>
In-Reply-To: <506EE9A7.6090009@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] tools/xen-mceinj: support AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 05.10.12 at 16:07, Christoph Egger  wrote:
> #define LOGFILE stdout
> 
> int dump;
>+int opt_exception;
> struct xen_mc_msrinject msr_inj;
>+int cpu_is_amd;
>+int cpu_is_intel;

Albeit I realize that this isn't the case with the context code here,
let's not continue bad habits: The newly added variables should
be static and - as long as not precluded by their use - bool.

>+
> 
> static void Lprintf(const char *fmt, ...)
> {
>...
>         case MCi_type_MISC:
>             addr = MSR_IA32_MC0_CTL + (bank * 4) + type;
>             break;
>+        case MC4_type_MISC1:
>+            addr = 0xc0000408;
>+            break;
>+        case MC4_type_MISC2:
>+            addr = 0xc0000409;
>+            break;
>+        case MC4_type_MISC3:
>+            addr = 0xc000040a;
>+            break;
>         case MCi_type_CTL2:
>             addr = MSR_IA32_MC0_CTL2 + bank;
>             break;

What makes it only bank 4 being added here? This question also
applies to the hypervisor side patch you sent on Friday.

>-    sprintf(path, "/local/domain/%d/memory/target", domid);
>+    snprintf(path, sizeof(path), "/local/domain/%d/memory/target", domid);
 
While fine with me, this is completely unrelated.

>+static void cpuid(const unsigned int *input, unsigned int *regs)

While it makes no difference to the treatment of the parameter or
the generated code, this should still be "unsigned int regs[4]" for
documentation purposes.

>+{
>+    unsigned int count = (input[1] == XEN_CPUID_INPUT_UNUSED) ? 0 : input[1];
>+    asm (
>+#ifdef __i386__
>+        "push %%ebx; push %%edx\n\t"
>+#else
>+        "push %%rbx; push %%rdx\n\t"
>+#endif
>+        "cpuid\n\t"
>+        "mov %%ebx,4(%4)\n\t"
>+        "mov %%edx,12(%4)\n\t"
>+#ifdef __i386__
>+        "pop %%edx; pop %%ebx\n\t"
>+#else
>+        "pop %%rdx; pop %%rbx\n\t"
>+#endif
>+        : "=a" (regs[0]), "=c" (regs[2])
>+        : "0" (input[0]), "1" (count), "S" (regs)
>+        : "memory" );
>+}

What did you clone this from? It re-introduces a bug long fixed in
libxc (use of push/pop here collides with the 64-bit red zone; see
tools/libxc/xc_cpuid_x86.c:cpuid() and its history).

>+static void cpuid_brand_get(char *str)
>+{
>+    unsigned int input[2] = { 0, 0 };
>+    unsigned int regs[4];
>+
>+    cpuid(input, regs);
>+
>+    *(uint32_t *)(str + 0) = regs[1];
>+    *(uint32_t *)(str + 4) = regs[3];
>+    *(uint32_t *)(str + 8) = regs[2];
>+    str[12] = '\0';
>+}

I believe that by way of using a suitably defined union you can
get away here without any type casts (which I would generally
expect the compiler to warn about, as I think [hope] that the
tools don't get built with -fno-strict-aliasing).

Also, the file use hypervisor coding style, so please follow that
in the adjustments you are doing (and in particular please don't
do any adjustments just to _remove_ that coding style).

>-    int type = MCE_SRAO_MEM;
>+    int type;
>...
>+    if (cpu_is_intel)
>+        type = INTEL_MCE_SRAO_MEM;

So on AMD "type" remains uninitialized unless the -t option was
used?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 10:20:21 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 10:20:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSmRx-00005d-E7; Mon, 29 Oct 2012 10:20:05 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSmRv-00005Y-Uv
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 10:20:04 +0000
Received: from [193.109.254.147:6999] by server-15.bemta-14.messagelabs.com id
	2F/33-12105-3585E805; Mon, 29 Oct 2012 10:20:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1351506002!8808934!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6096 invoked from network); 29 Oct 2012 10:20:02 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-27.messagelabs.com with SMTP;
	29 Oct 2012 10:20:02 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 29 Oct 2012 10:20:01 +0000
Message-Id: <508E668702000078000A514D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 29 Oct 2012 10:20:39 +0000
From: "Jan Beulich" 
To: "Christoph Egger" 
References: <506EE9A7.6090009@amd.com>
In-Reply-To: <506EE9A7.6090009@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] tools/xen-mceinj: support AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 05.10.12 at 16:07, Christoph Egger  wrote:
> #define LOGFILE stdout
> 
> int dump;
>+int opt_exception;
> struct xen_mc_msrinject msr_inj;
>+int cpu_is_amd;
>+int cpu_is_intel;

Albeit I realize that this isn't the case with the context code here,
let's not continue bad habits: The newly added variables should
be static and - as long as not precluded by their use - bool.

>+
> 
> static void Lprintf(const char *fmt, ...)
> {
>...
>         case MCi_type_MISC:
>             addr = MSR_IA32_MC0_CTL + (bank * 4) + type;
>             break;
>+        case MC4_type_MISC1:
>+            addr = 0xc0000408;
>+            break;
>+        case MC4_type_MISC2:
>+            addr = 0xc0000409;
>+            break;
>+        case MC4_type_MISC3:
>+            addr = 0xc000040a;
>+            break;
>         case MCi_type_CTL2:
>             addr = MSR_IA32_MC0_CTL2 + bank;
>             break;

What makes it only bank 4 being added here? This question also
applies to the hypervisor side patch you sent on Friday.

>-    sprintf(path, "/local/domain/%d/memory/target", domid);
>+    snprintf(path, sizeof(path), "/local/domain/%d/memory/target", domid);
 
While fine with me, this is completely unrelated.

>+static void cpuid(const unsigned int *input, unsigned int *regs)

While it makes no difference to the treatment of the parameter or
the generated code, this should still be "unsigned int regs[4]" for
documentation purposes.

>+{
>+    unsigned int count = (input[1] == XEN_CPUID_INPUT_UNUSED) ? 0 : input[1];
>+    asm (
>+#ifdef __i386__
>+        "push %%ebx; push %%edx\n\t"
>+#else
>+        "push %%rbx; push %%rdx\n\t"
>+#endif
>+        "cpuid\n\t"
>+        "mov %%ebx,4(%4)\n\t"
>+        "mov %%edx,12(%4)\n\t"
>+#ifdef __i386__
>+        "pop %%edx; pop %%ebx\n\t"
>+#else
>+        "pop %%rdx; pop %%rbx\n\t"
>+#endif
>+        : "=a" (regs[0]), "=c" (regs[2])
>+        : "0" (input[0]), "1" (count), "S" (regs)
>+        : "memory" );
>+}

What did you clone this from? It re-introduces a bug long fixed in
libxc (use of push/pop here collides with the 64-bit red zone; see
tools/libxc/xc_cpuid_x86.c:cpuid() and its history).

>+static void cpuid_brand_get(char *str)
>+{
>+    unsigned int input[2] = { 0, 0 };
>+    unsigned int regs[4];
>+
>+    cpuid(input, regs);
>+
>+    *(uint32_t *)(str + 0) = regs[1];
>+    *(uint32_t *)(str + 4) = regs[3];
>+    *(uint32_t *)(str + 8) = regs[2];
>+    str[12] = '\0';
>+}

I believe that by way of using a suitably defined union you can
get away here without any type casts (which I would generally
expect the compiler to warn about, as I think [hope] that the
tools don't get built with -fno-strict-aliasing).

Also, the file use hypervisor coding style, so please follow that
in the adjustments you are doing (and in particular please don't
do any adjustments just to _remove_ that coding style).

>-    int type = MCE_SRAO_MEM;
>+    int type;
>...
>+    if (cpu_is_intel)
>+        type = INTEL_MCE_SRAO_MEM;

So on AMD "type" remains uninitialized unless the -t option was
used?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 10:22:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 10:22:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSmU2-0000Do-3R; Mon, 29 Oct 2012 10:22:14 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSmU1-0000Dj-6I
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 10:22:13 +0000
Received: from [193.109.254.147:28392] by server-6.bemta-14.messagelabs.com id
	84/66-17826-4D85E805; Mon, 29 Oct 2012 10:22:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1351506131!1991368!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24572 invoked from network); 29 Oct 2012 10:22:11 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-27.messagelabs.com with SMTP;
	29 Oct 2012 10:22:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 29 Oct 2012 10:22:11 +0000
Message-Id: <508E670802000078000A5150@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 29 Oct 2012 10:22:48 +0000
From: "Jan Beulich" 
To: "Christoph Egger" 
References: <508A490B.4050407@amd.com> <508A4935.6090801@amd.com>
	<508E5EF702000078000A5039@nat28.tlf.novell.com>
	<508E5463.1040100@amd.com>
In-Reply-To: <508E5463.1040100@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] MCE: consolidate AMD initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 29.10.12 at 11:03, Christoph Egger  wrote:
> On 10/29/12 10:48, Jan Beulich wrote:
>>>>> On 26.10.12 at 10:26, Christoph Egger  wrote:
>>> On 10/26/12 10:25, Christoph Egger wrote:
>>>>
>>>> Move AMD specific initialization to AMD files.
>>>>
>>>> Signed-off-by: Christoph Egger 
>> 
>> Let's do this properly: There's no K7 supporting 64-bit mode afaict,
>> so rather than moving around the call to amd_k7_mcheck_init()
>> can't we just drop it and the whole (inconsistently named) k7.c file?
> 
> I think it is better to apply this first and then remove k7 to
> simplify backporting if needed/wanted.

I'm not seeing these changes as backporting candidates.

>> Also (not in this patch of course), I'd prefer mce_amd_quirks.c
>> to get merged into mce_amd.c now that we have the latter.
> 
> After some thinking is there some good reason to do this?

Imo it had been there simply because there was no mce_amd.c at
the time it got introduced (and afaics it should nevertheless have
been named mce_amd.c from the beginning).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 10:22:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 10:22:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSmU2-0000Do-3R; Mon, 29 Oct 2012 10:22:14 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSmU1-0000Dj-6I
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 10:22:13 +0000
Received: from [193.109.254.147:28392] by server-6.bemta-14.messagelabs.com id
	84/66-17826-4D85E805; Mon, 29 Oct 2012 10:22:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1351506131!1991368!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24572 invoked from network); 29 Oct 2012 10:22:11 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-27.messagelabs.com with SMTP;
	29 Oct 2012 10:22:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 29 Oct 2012 10:22:11 +0000
Message-Id: <508E670802000078000A5150@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 29 Oct 2012 10:22:48 +0000
From: "Jan Beulich" 
To: "Christoph Egger" 
References: <508A490B.4050407@amd.com> <508A4935.6090801@amd.com>
	<508E5EF702000078000A5039@nat28.tlf.novell.com>
	<508E5463.1040100@amd.com>
In-Reply-To: <508E5463.1040100@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] MCE: consolidate AMD initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 29.10.12 at 11:03, Christoph Egger  wrote:
> On 10/29/12 10:48, Jan Beulich wrote:
>>>>> On 26.10.12 at 10:26, Christoph Egger  wrote:
>>> On 10/26/12 10:25, Christoph Egger wrote:
>>>>
>>>> Move AMD specific initialization to AMD files.
>>>>
>>>> Signed-off-by: Christoph Egger 
>> 
>> Let's do this properly: There's no K7 supporting 64-bit mode afaict,
>> so rather than moving around the call to amd_k7_mcheck_init()
>> can't we just drop it and the whole (inconsistently named) k7.c file?
> 
> I think it is better to apply this first and then remove k7 to
> simplify backporting if needed/wanted.

I'm not seeing these changes as backporting candidates.

>> Also (not in this patch of course), I'd prefer mce_amd_quirks.c
>> to get merged into mce_amd.c now that we have the latter.
> 
> After some thinking is there some good reason to do this?

Imo it had been there simply because there was no mce_amd.c at
the time it got introduced (and afaics it should nevertheless have
been named mce_amd.c from the beginning).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 10:37:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 10:37:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSmik-0000TA-JJ; Mon, 29 Oct 2012 10:37:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSmii-0000T5-Q6
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 10:37:25 +0000
Received: from [85.158.143.35:15510] by server-2.bemta-4.messagelabs.com id
	C7/0E-22268-46C5E805; Mon, 29 Oct 2012 10:37:24 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1351506756!14878426!1
X-Originating-IP: [213.199.154.209]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20531 invoked from network); 29 Oct 2012 10:32:37 -0000
Received: from am1ehsobe006.messaging.microsoft.com (HELO
	am1outboundpool.messaging.microsoft.com) (213.199.154.209)
	by server-13.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	29 Oct 2012 10:32:37 -0000
Received: from mail27-am1-R.bigfish.com (10.3.201.249) by
	AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id
	14.1.225.23; Mon, 29 Oct 2012 10:32:36 +0000
Received: from mail27-am1 (localhost [127.0.0.1])	by mail27-am1-R.bigfish.com
	(Postfix) with ESMTP id 57F183A00DD;
	Mon, 29 Oct 2012 10:32:36 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: -3
X-BigFish: VPS-3(zzbb2dI98dI1432Izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h)
Received: from mail27-am1 (localhost.localdomain [127.0.0.1]) by mail27-am1
	(MessageSwitch) id 1351506754211768_15040;
	Mon, 29 Oct 2012 10:32:34 +0000 (UTC)
Received: from AM1EHSMHS004.bigfish.com (unknown [10.3.201.245])	by
	mail27-am1.bigfish.com (Postfix) with ESMTP id 27DB8C009C;
	Mon, 29 Oct 2012 10:32:34 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS004.bigfish.com (10.3.207.104) with Microsoft SMTP Server id
	14.1.225.23; Mon, 29 Oct 2012 10:32:33 +0000
X-WSS-ID: 0MCNHA7-01-T7N-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 29B1E10282CC;	Mon, 29 Oct 2012 05:32:30 -0500 (CDT)
Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Mon, 29 Oct 2012 05:32:35 -0500
Received: from STOREXDAG02.amd.com (10.1.13.11) by sausexdag03.amd.com
	(163.181.55.3) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Mon, 29 Oct 2012 05:32:30 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag02.amd.com
	(10.1.13.11) with Microsoft SMTP Server id 14.2.318.4; Mon, 29 Oct 2012
	06:32:29 -0400
Message-ID: <508E5B3C.6030801@amd.com>
Date: Mon, 29 Oct 2012 11:32:28 +0100
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich 
References: <508A490B.4050407@amd.com> <508A4935.6090801@amd.com>
	<508E5EF702000078000A5039@nat28.tlf.novell.com>
	<508E5463.1040100@amd.com>
	<508E670802000078000A5150@nat28.tlf.novell.com>
In-Reply-To: <508E670802000078000A5150@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] MCE: consolidate AMD initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/29/12 11:22, Jan Beulich wrote:
>>>> On 29.10.12 at 11:03, Christoph Egger  wrote:
>> On 10/29/12 10:48, Jan Beulich wrote:
>>>>>> On 26.10.12 at 10:26, Christoph Egger  wrote:
>>>> On 10/26/12 10:25, Christoph Egger wrote:
>>>>>
>>>>> Move AMD specific initialization to AMD files.
>>>>>
>>>>> Signed-off-by: Christoph Egger 
>>>
>>> Let's do this properly: There's no K7 supporting 64-bit mode afaict,
>>> so rather than moving around the call to amd_k7_mcheck_init()
>>> can't we just drop it and the whole (inconsistently named) k7.c file?
>>
>> I think it is better to apply this first and then remove k7 to
>> simplify backporting if needed/wanted.
> 
> I'm not seeing these changes as backporting candidates.

I had SLES in mind.

>>> Also (not in this patch of course), I'd prefer mce_amd_quirks.c
>>> to get merged into mce_amd.c now that we have the latter.
>>
>> After some thinking is there some good reason to do this?
> 
> Imo it had been there simply because there was no mce_amd.c at
> the time it got introduced (and afaics it should nevertheless have
> been named mce_amd.c from the beginning).

I have a patch ready that removes k7 support which is on top of this
init cleanup patch.
I also have a patch which merges mce_amd_quirks into mce_amd.c on
top of the k7 removal.
In which order do you want them?

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 10:37:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 10:37:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSmik-0000TA-JJ; Mon, 29 Oct 2012 10:37:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSmii-0000T5-Q6
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 10:37:25 +0000
Received: from [85.158.143.35:15510] by server-2.bemta-4.messagelabs.com id
	C7/0E-22268-46C5E805; Mon, 29 Oct 2012 10:37:24 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1351506756!14878426!1
X-Originating-IP: [213.199.154.209]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20531 invoked from network); 29 Oct 2012 10:32:37 -0000
Received: from am1ehsobe006.messaging.microsoft.com (HELO
	am1outboundpool.messaging.microsoft.com) (213.199.154.209)
	by server-13.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	29 Oct 2012 10:32:37 -0000
Received: from mail27-am1-R.bigfish.com (10.3.201.249) by
	AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id
	14.1.225.23; Mon, 29 Oct 2012 10:32:36 +0000
Received: from mail27-am1 (localhost [127.0.0.1])	by mail27-am1-R.bigfish.com
	(Postfix) with ESMTP id 57F183A00DD;
	Mon, 29 Oct 2012 10:32:36 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: -3
X-BigFish: VPS-3(zzbb2dI98dI1432Izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h)
Received: from mail27-am1 (localhost.localdomain [127.0.0.1]) by mail27-am1
	(MessageSwitch) id 1351506754211768_15040;
	Mon, 29 Oct 2012 10:32:34 +0000 (UTC)
Received: from AM1EHSMHS004.bigfish.com (unknown [10.3.201.245])	by
	mail27-am1.bigfish.com (Postfix) with ESMTP id 27DB8C009C;
	Mon, 29 Oct 2012 10:32:34 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS004.bigfish.com (10.3.207.104) with Microsoft SMTP Server id
	14.1.225.23; Mon, 29 Oct 2012 10:32:33 +0000
X-WSS-ID: 0MCNHA7-01-T7N-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 29B1E10282CC;	Mon, 29 Oct 2012 05:32:30 -0500 (CDT)
Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Mon, 29 Oct 2012 05:32:35 -0500
Received: from STOREXDAG02.amd.com (10.1.13.11) by sausexdag03.amd.com
	(163.181.55.3) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Mon, 29 Oct 2012 05:32:30 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag02.amd.com
	(10.1.13.11) with Microsoft SMTP Server id 14.2.318.4; Mon, 29 Oct 2012
	06:32:29 -0400
Message-ID: <508E5B3C.6030801@amd.com>
Date: Mon, 29 Oct 2012 11:32:28 +0100
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich 
References: <508A490B.4050407@amd.com> <508A4935.6090801@amd.com>
	<508E5EF702000078000A5039@nat28.tlf.novell.com>
	<508E5463.1040100@amd.com>
	<508E670802000078000A5150@nat28.tlf.novell.com>
In-Reply-To: <508E670802000078000A5150@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] MCE: consolidate AMD initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/29/12 11:22, Jan Beulich wrote:
>>>> On 29.10.12 at 11:03, Christoph Egger  wrote:
>> On 10/29/12 10:48, Jan Beulich wrote:
>>>>>> On 26.10.12 at 10:26, Christoph Egger  wrote:
>>>> On 10/26/12 10:25, Christoph Egger wrote:
>>>>>
>>>>> Move AMD specific initialization to AMD files.
>>>>>
>>>>> Signed-off-by: Christoph Egger 
>>>
>>> Let's do this properly: There's no K7 supporting 64-bit mode afaict,
>>> so rather than moving around the call to amd_k7_mcheck_init()
>>> can't we just drop it and the whole (inconsistently named) k7.c file?
>>
>> I think it is better to apply this first and then remove k7 to
>> simplify backporting if needed/wanted.
> 
> I'm not seeing these changes as backporting candidates.

I had SLES in mind.

>>> Also (not in this patch of course), I'd prefer mce_amd_quirks.c
>>> to get merged into mce_amd.c now that we have the latter.
>>
>> After some thinking is there some good reason to do this?
> 
> Imo it had been there simply because there was no mce_amd.c at
> the time it got introduced (and afaics it should nevertheless have
> been named mce_amd.c from the beginning).

I have a patch ready that removes k7 support which is on top of this
init cleanup patch.
I also have a patch which merges mce_amd_quirks into mce_amd.c on
top of the k7 removal.
In which order do you want them?

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 10:48:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 10:48:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSmtP-0000e9-QN; Mon, 29 Oct 2012 10:48:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSmtO-0000e4-0a
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 10:48:26 +0000
Received: from [85.158.137.99:33809] by server-12.bemta-3.messagelabs.com id
	CA/19-27853-9FE5E805; Mon, 29 Oct 2012 10:48:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1351507704!23401110!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7057 invoked from network); 29 Oct 2012 10:48:24 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-217.messagelabs.com with SMTP;
	29 Oct 2012 10:48:24 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 29 Oct 2012 10:48:23 +0000
Message-Id: <508E6D2E02000078000A51AD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 29 Oct 2012 10:49:02 +0000
From: "Jan Beulich" 
To: "Christoph Egger" 
References: <508A490B.4050407@amd.com> <508A4935.6090801@amd.com>
	<508E5EF702000078000A5039@nat28.tlf.novell.com>
	<508E5463.1040100@amd.com>
	<508E670802000078000A5150@nat28.tlf.novell.com>
	<508E5B3C.6030801@amd.com>
In-Reply-To: <508E5B3C.6030801@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] MCE: consolidate AMD initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 29.10.12 at 11:32, Christoph Egger  wrote:
> On 10/29/12 11:22, Jan Beulich wrote:
>>>>> On 29.10.12 at 11:03, Christoph Egger  wrote:
>>> On 10/29/12 10:48, Jan Beulich wrote:
>>>>>>> On 26.10.12 at 10:26, Christoph Egger  wrote:
>>>>> On 10/26/12 10:25, Christoph Egger wrote:
>>>>>>
>>>>>> Move AMD specific initialization to AMD files.
>>>>>>
>>>>>> Signed-off-by: Christoph Egger 
>>>>
>>>> Let's do this properly: There's no K7 supporting 64-bit mode afaict,
>>>> so rather than moving around the call to amd_k7_mcheck_init()
>>>> can't we just drop it and the whole (inconsistently named) k7.c file?
>>>
>>> I think it is better to apply this first and then remove k7 to
>>> simplify backporting if needed/wanted.
>> 
>> I'm not seeing these changes as backporting candidates.
> 
> I had SLES in mind.
> 
>>>> Also (not in this patch of course), I'd prefer mce_amd_quirks.c
>>>> to get merged into mce_amd.c now that we have the latter.
>>>
>>> After some thinking is there some good reason to do this?
>> 
>> Imo it had been there simply because there was no mce_amd.c at
>> the time it got introduced (and afaics it should nevertheless have
>> been named mce_amd.c from the beginning).
> 
> I have a patch ready that removes k7 support which is on top of this
> init cleanup patch.
> I also have a patch which merges mce_amd_quirks into mce_amd.c on
> top of the k7 removal.
> In which order do you want them?

Okay, if you got them done already, let's go with the order you
have.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 10:48:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 10:48:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSmtP-0000e9-QN; Mon, 29 Oct 2012 10:48:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSmtO-0000e4-0a
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 10:48:26 +0000
Received: from [85.158.137.99:33809] by server-12.bemta-3.messagelabs.com id
	CA/19-27853-9FE5E805; Mon, 29 Oct 2012 10:48:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1351507704!23401110!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7057 invoked from network); 29 Oct 2012 10:48:24 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-217.messagelabs.com with SMTP;
	29 Oct 2012 10:48:24 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 29 Oct 2012 10:48:23 +0000
Message-Id: <508E6D2E02000078000A51AD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 29 Oct 2012 10:49:02 +0000
From: "Jan Beulich" 
To: "Christoph Egger" 
References: <508A490B.4050407@amd.com> <508A4935.6090801@amd.com>
	<508E5EF702000078000A5039@nat28.tlf.novell.com>
	<508E5463.1040100@amd.com>
	<508E670802000078000A5150@nat28.tlf.novell.com>
	<508E5B3C.6030801@amd.com>
In-Reply-To: <508E5B3C.6030801@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] MCE: consolidate AMD initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 29.10.12 at 11:32, Christoph Egger  wrote:
> On 10/29/12 11:22, Jan Beulich wrote:
>>>>> On 29.10.12 at 11:03, Christoph Egger  wrote:
>>> On 10/29/12 10:48, Jan Beulich wrote:
>>>>>>> On 26.10.12 at 10:26, Christoph Egger  wrote:
>>>>> On 10/26/12 10:25, Christoph Egger wrote:
>>>>>>
>>>>>> Move AMD specific initialization to AMD files.
>>>>>>
>>>>>> Signed-off-by: Christoph Egger 
>>>>
>>>> Let's do this properly: There's no K7 supporting 64-bit mode afaict,
>>>> so rather than moving around the call to amd_k7_mcheck_init()
>>>> can't we just drop it and the whole (inconsistently named) k7.c file?
>>>
>>> I think it is better to apply this first and then remove k7 to
>>> simplify backporting if needed/wanted.
>> 
>> I'm not seeing these changes as backporting candidates.
> 
> I had SLES in mind.
> 
>>>> Also (not in this patch of course), I'd prefer mce_amd_quirks.c
>>>> to get merged into mce_amd.c now that we have the latter.
>>>
>>> After some thinking is there some good reason to do this?
>> 
>> Imo it had been there simply because there was no mce_amd.c at
>> the time it got introduced (and afaics it should nevertheless have
>> been named mce_amd.c from the beginning).
> 
> I have a patch ready that removes k7 support which is on top of this
> init cleanup patch.
> I also have a patch which merges mce_amd_quirks into mce_amd.c on
> top of the k7 removal.
> In which order do you want them?

Okay, if you got them done already, let's go with the order you
have.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 11:08:47 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 11:08:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSnCj-0000tG-Ub; Mon, 29 Oct 2012 11:08:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSnCi-0000tB-7K
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 11:08:24 +0000
Received: from [85.158.138.51:54011] by server-13.bemta-3.messagelabs.com id
	C9/98-24887-7A36E805; Mon, 29 Oct 2012 11:08:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1351508901!27790671!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzk2NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20505 invoked from network); 29 Oct 2012 11:08:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Oct 2012 11:08:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,671,1344211200"; d="scan'208";a="42728781"
Received: from unknown (HELO FTLPEX01CL02.citrite.net) ([10.13.107.79])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	29 Oct 2012 11:07:45 +0000
Received: from [127.0.0.1] (10.9.154.239) by FTLPEX01CL02.citrite.net
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 29 Oct 2012 07:07:45 -0400
Message-ID: <1351508749.16868.5.camel@hastur.hellion.org.uk>
From: Ian Campbell 
To: Philipp Hahn 
Date: Mon, 29 Oct 2012 12:05:49 +0100
In-Reply-To: <201210262204.16165.hahn@univention.de>
References: 
	<17eea5a9a20cc43d7de1.1351098146@makatos-desktop>
	<1351250701.15162.43.camel@zakaz.uk.xensource.com>
	<201210262204.16165.hahn@univention.de>
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
X-Originating-IP: [10.9.154.239]
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 07 of 16 RFC] blktap3: Introduce blktap3
 top-level Makefile
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-26 at 21:04 +0100, Philipp Hahn wrote:
> Hello Ian,
> 
> On Friday 26 October 2012 13:25:01 Ian Campbell wrote:
> > > +build: ;
> >
> > What does the ";" in this syntax do?
> 
> A Make trick to do (really) nothing:
> 

Ah OK, thanks for the link.

It does say that this doesn't make much sense for phony targets, which
all of these were.

Ian.


> Sincerely
> Philipp



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 11:08:47 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 11:08:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSnCj-0000tG-Ub; Mon, 29 Oct 2012 11:08:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSnCi-0000tB-7K
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 11:08:24 +0000
Received: from [85.158.138.51:54011] by server-13.bemta-3.messagelabs.com id
	C9/98-24887-7A36E805; Mon, 29 Oct 2012 11:08:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1351508901!27790671!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzk2NDE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20505 invoked from network); 29 Oct 2012 11:08:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Oct 2012 11:08:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,671,1344211200"; d="scan'208";a="42728781"
Received: from unknown (HELO FTLPEX01CL02.citrite.net) ([10.13.107.79])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	29 Oct 2012 11:07:45 +0000
Received: from [127.0.0.1] (10.9.154.239) by FTLPEX01CL02.citrite.net
	(10.13.107.79) with Microsoft SMTP Server id 14.2.318.1;
	Mon, 29 Oct 2012 07:07:45 -0400
Message-ID: <1351508749.16868.5.camel@hastur.hellion.org.uk>
From: Ian Campbell 
To: Philipp Hahn 
Date: Mon, 29 Oct 2012 12:05:49 +0100
In-Reply-To: <201210262204.16165.hahn@univention.de>
References: 
	<17eea5a9a20cc43d7de1.1351098146@makatos-desktop>
	<1351250701.15162.43.camel@zakaz.uk.xensource.com>
	<201210262204.16165.hahn@univention.de>
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
X-Originating-IP: [10.9.154.239]
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 07 of 16 RFC] blktap3: Introduce blktap3
 top-level Makefile
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-10-26 at 21:04 +0100, Philipp Hahn wrote:
> Hello Ian,
> 
> On Friday 26 October 2012 13:25:01 Ian Campbell wrote:
> > > +build: ;
> >
> > What does the ";" in this syntax do?
> 
> A Make trick to do (really) nothing:
> 

Ah OK, thanks for the link.

It does say that this doesn't make much sense for phony targets, which
all of these were.

Ian.


> Sincerely
> Philipp



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 11:10:28 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 11:10:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSnER-0000xq-FI; Mon, 29 Oct 2012 11:10:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSnEP-0000xg-Le
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 11:10:10 +0000
Received: from [85.158.137.99:29340] by server-12.bemta-3.messagelabs.com id
	50/19-27853-0146E805; Mon, 29 Oct 2012 11:10:08 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1351509007!21068837!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzNTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5197 invoked from network); 29 Oct 2012 11:10:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Oct 2012 11:10:07 -0000
X-IronPort-AV: E=Sophos;i="4.80,671,1344211200"; d="scan'208";a="15460834"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Oct 2012 11:10:03 +0000
Received: from mac.citrite.net (10.31.3.235) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 29 Oct 2012 11:10:02 +0000
From: Roger Pau Monne 
To: 
Date: Mon, 29 Oct 2012 12:09:56 +0100
Message-ID: <1351508996-54975-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
MIME-Version: 1.0
Cc: Roger Pau Monne 
Subject: [Xen-devel] [PATCH] docs: document persistent grants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Document the new persistent grants block-device feature.

Signed-off-by: Roger Pau Monne 
---
 xen/include/public/io/blkif.h |   29 +++++++++++++++++++++++++++++
 1 files changed, 29 insertions(+), 0 deletions(-)

diff --git a/xen/include/public/io/blkif.h b/xen/include/public/io/blkif.h
index d71c7f1..accdda4 100644
--- a/xen/include/public/io/blkif.h
+++ b/xen/include/public/io/blkif.h
@@ -126,6 +126,19 @@
  *      of this type may still be returned at any time with the
  *      BLKIF_RSP_EOPNOTSUPP result code.
  *
+ * feature-persistent
+ *      Values:         0/1 (boolean)
+ *      Default Value:  0
+ *      Notes: 7
+ *
+ *      A value of "1" indicates that the backend can keep the grants used
+ *      by the frontend driver mapped, so the same set of grants should be
+ *      used in all transactions. The maximum number of grants the backend
+ *      can map persistently depends on the implementation, but ideally it
+ *      should be RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST. Using this
+ *      feature the backend doesn't need to unmap each grant, preventing
+ *      costly TLB flushes.
+ *
  *----------------------- Request Transport Parameters ------------------------
  *
  * max-ring-page-order
@@ -242,6 +255,15 @@
  *      The size of the frontend allocated request ring buffer in units of
  *      machine pages.  The value must be a power of 2.
  *
+ * feature-persistent
+ *      Values:         0/1 (boolean)
+ *      Default Value:  0
+ *      Notes: 7, 8
+ *
+ *      A value of "1" indicates that the frontend will reuse the same grants
+ *      for all transactions, allowing the backend to map them with write
+ *      access (even when it should be read-only).
+ *
  *------------------------- Virtual Device Properties -------------------------
  *
  * device-type
@@ -279,6 +301,13 @@
  *     'ring-ref' is used to communicate the grant reference for this
  *     page to the backend.  When using a multi-page ring, the 'ring-ref'
  *     node is not created.  Instead 'ring-ref0' - 'ring-refN' are used.
+ * (7) When using persistent grants data has to be copied from/to the page
+ *     where the grant is currently mapped. The overhead of doing this copy
+ *     however doesn't suppress the speed improvement of not having to unmap
+ *     the grants.
+ * (8) The frontend driver has to allow the backend driver to map all grants
+ *     with write access, even when they should be mapped read-only, since
+ *     further requests may reuse this grants and require write permisions.
  */
 
 /*
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 11:10:28 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 11:10:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSnER-0000xq-FI; Mon, 29 Oct 2012 11:10:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSnEP-0000xg-Le
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 11:10:10 +0000
Received: from [85.158.137.99:29340] by server-12.bemta-3.messagelabs.com id
	50/19-27853-0146E805; Mon, 29 Oct 2012 11:10:08 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1351509007!21068837!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzNTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5197 invoked from network); 29 Oct 2012 11:10:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Oct 2012 11:10:07 -0000
X-IronPort-AV: E=Sophos;i="4.80,671,1344211200"; d="scan'208";a="15460834"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Oct 2012 11:10:03 +0000
Received: from mac.citrite.net (10.31.3.235) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 29 Oct 2012 11:10:02 +0000
From: Roger Pau Monne 
To: 
Date: Mon, 29 Oct 2012 12:09:56 +0100
Message-ID: <1351508996-54975-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
MIME-Version: 1.0
Cc: Roger Pau Monne 
Subject: [Xen-devel] [PATCH] docs: document persistent grants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Document the new persistent grants block-device feature.

Signed-off-by: Roger Pau Monne 
---
 xen/include/public/io/blkif.h |   29 +++++++++++++++++++++++++++++
 1 files changed, 29 insertions(+), 0 deletions(-)

diff --git a/xen/include/public/io/blkif.h b/xen/include/public/io/blkif.h
index d71c7f1..accdda4 100644
--- a/xen/include/public/io/blkif.h
+++ b/xen/include/public/io/blkif.h
@@ -126,6 +126,19 @@
  *      of this type may still be returned at any time with the
  *      BLKIF_RSP_EOPNOTSUPP result code.
  *
+ * feature-persistent
+ *      Values:         0/1 (boolean)
+ *      Default Value:  0
+ *      Notes: 7
+ *
+ *      A value of "1" indicates that the backend can keep the grants used
+ *      by the frontend driver mapped, so the same set of grants should be
+ *      used in all transactions. The maximum number of grants the backend
+ *      can map persistently depends on the implementation, but ideally it
+ *      should be RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST. Using this
+ *      feature the backend doesn't need to unmap each grant, preventing
+ *      costly TLB flushes.
+ *
  *----------------------- Request Transport Parameters ------------------------
  *
  * max-ring-page-order
@@ -242,6 +255,15 @@
  *      The size of the frontend allocated request ring buffer in units of
  *      machine pages.  The value must be a power of 2.
  *
+ * feature-persistent
+ *      Values:         0/1 (boolean)
+ *      Default Value:  0
+ *      Notes: 7, 8
+ *
+ *      A value of "1" indicates that the frontend will reuse the same grants
+ *      for all transactions, allowing the backend to map them with write
+ *      access (even when it should be read-only).
+ *
  *------------------------- Virtual Device Properties -------------------------
  *
  * device-type
@@ -279,6 +301,13 @@
  *     'ring-ref' is used to communicate the grant reference for this
  *     page to the backend.  When using a multi-page ring, the 'ring-ref'
  *     node is not created.  Instead 'ring-ref0' - 'ring-refN' are used.
+ * (7) When using persistent grants data has to be copied from/to the page
+ *     where the grant is currently mapped. The overhead of doing this copy
+ *     however doesn't suppress the speed improvement of not having to unmap
+ *     the grants.
+ * (8) The frontend driver has to allow the backend driver to map all grants
+ *     with write access, even when they should be mapped read-only, since
+ *     further requests may reuse this grants and require write permisions.
  */
 
 /*
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 11:14:57 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 11:14:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSnIo-00019m-60; Mon, 29 Oct 2012 11:14:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSnIm-00019d-Hp
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 11:14:40 +0000
Received: from [85.158.139.211:22292] by server-5.bemta-5.messagelabs.com id
	5B/17-09732-F156E805; Mon, 29 Oct 2012 11:14:39 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1351509277!18066179!1
X-Originating-IP: [216.32.181.184]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7482 invoked from network); 29 Oct 2012 11:14:38 -0000
Received: from ch1ehsobe004.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.184)
	by server-16.tower-206.messagelabs.com with AES128-SHA encrypted SMTP;
	29 Oct 2012 11:14:38 -0000
Received: from mail156-ch1-R.bigfish.com (10.43.68.232) by
	CH1EHSOBE001.bigfish.com (10.43.70.51) with Microsoft SMTP Server id
	14.1.225.23; Mon, 29 Oct 2012 11:14:36 +0000
Received: from mail156-ch1 (localhost [127.0.0.1])	by
	mail156-ch1-R.bigfish.com (Postfix) with ESMTP id 9739C600AC;
	Mon, 29 Oct 2012 11:14:36 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzc85fhc85dhzz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh34h1155h)
Received: from mail156-ch1 (localhost.localdomain [127.0.0.1]) by mail156-ch1
	(MessageSwitch) id 1351509274800259_1506;
	Mon, 29 Oct 2012 11:14:34 +0000 (UTC)
Received: from CH1EHSMHS039.bigfish.com (snatpool2.int.messaging.microsoft.com
	[10.43.68.230])	by mail156-ch1.bigfish.com (Postfix) with ESMTP id
	B768B320043;	Mon, 29 Oct 2012 11:14:34 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS039.bigfish.com (10.43.69.248) with Microsoft SMTP Server id
	14.1.225.23; Mon, 29 Oct 2012 11:14:34 +0000
X-WSS-ID: 0MCNJ89-01-1I5-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2DD4110282EB;	Mon, 29 Oct 2012 06:14:32 -0500 (CDT)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Mon, 29 Oct 2012 06:14:37 -0500
Received: from STOREXDAG03.amd.com (10.1.13.12) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Mon, 29 Oct 2012 06:14:32 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag03.amd.com
	(10.1.13.12) with Microsoft SMTP Server id 14.2.318.4; Mon, 29 Oct 2012
	07:14:31 -0400
Message-ID: <508E6516.6070805@amd.com>
Date: Mon, 29 Oct 2012 12:14:30 +0100
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" 
Content-Type: multipart/mixed; boundary="------------050005060500090601020508"
X-OriginatorOrg: amd.com
Cc: Jan Beulich 
Subject: [Xen-devel] [PATCH] MCE: remove K7 support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------050005060500090601020508
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit


Remove K7 support from MCE.

Signed-off-by: Christoph Egger 

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------050005060500090601020508
Content-Type: text/plain; charset="us-ascii"; name="xen_mce_rmk7.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_mce_rmk7.diff"
Content-Description: xen_mce_rmk7.diff

diff -r 3f6672b24d45 xen/arch/x86/cpu/mcheck/Makefile
--- a/xen/arch/x86/cpu/mcheck/Makefile	Mon Oct 29 09:44:49 2012 +0100
+++ b/xen/arch/x86/cpu/mcheck/Makefile	Mon Oct 29 10:40:51 2012 +0100
@@ -1,5 +1,4 @@
 obj-y += amd_nonfatal.o
-obj-y += k7.o
 obj-y += amd_k8.o
 obj-y += amd_f10.o
 obj-y += mce_amd.o
diff -r 3f6672b24d45 xen/arch/x86/cpu/mcheck/k7.c
--- a/xen/arch/x86/cpu/mcheck/k7.c	Mon Oct 29 09:44:49 2012 +0100
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,88 +0,0 @@
-/*
- * Athlon/Hammer specific Machine Check Exception Reporting
- * (C) Copyright 2002 Dave Jones 
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include  
-#include 
-#include 
-
-#include "mce.h"
-#include "x86_mca.h"
-
-/* Machine Check Handler For AMD Athlon/Duron */
-static void k7_machine_check(struct cpu_user_regs * regs, long error_code)
-{
-	int recover = 1;
-	uint64_t msr_content, mcgst;
-	int i;
-
-	rdmsrl(MSR_IA32_MCG_STATUS, mcgst);
-	if (mcgst & MCG_STATUS_RIPV)	/* Recoverable ? */
-		recover = 0;
-
-	printk(KERN_EMERG "CPU %d: Machine Check Exception: 0x%016"PRIx64"\n",
-		smp_processor_id(), mcgst);
-
-	for (i = 1; i < nr_mce_banks; i++) {
-		uint64_t value;
-
-		rdmsrl(MSR_IA32_MCx_STATUS(i), msr_content);
-		if (msr_content & MCi_STATUS_VAL) {
-			if (msr_content & MCi_STATUS_UC)
-				recover |= 1;
-			if (msr_content & MCi_STATUS_PCC)
-				recover |= 2;
-			printk(KERN_EMERG "Bank %d: 0x%16"PRIx64,
-				i, msr_content);
-			msr_content &= ~MCi_STATUS_VAL;
-			if (msr_content & MCi_STATUS_MISCV) {
-				rdmsrl(MSR_IA32_MCx_MISC(i), value);
-				printk("[0x%016"PRIx64"]", value);
-			}
-			if (msr_content & MCi_STATUS_ADDRV) {
-				rdmsrl(MSR_IA32_MCx_ADDR(i), value);
-				printk(" at 0x%016"PRIx64, value);
-			}
-			printk("\n");
-			/* Clear it */
-			wrmsrl(MSR_IA32_MCx_STATUS(i), 0x0ULL);
-			/* Serialize */
-			wmb();
-			add_taint(TAINT_MACHINE_CHECK);
-		}
-	}
-
-	if (recover & 2)
-		mc_panic("CPU context corrupt");
-	if (recover & 1)
-		mc_panic("Unable to continue");
-	printk(KERN_EMERG "Attempting to continue.\n");
-	mcgst &= ~MCG_STATUS_MCIP;
-	wrmsrl(MSR_IA32_MCG_STATUS, mcgst);
-}
-
-
-/* AMD K7 machine check */
-enum mcheck_type amd_k7_mcheck_init(struct cpuinfo_x86 *c)
-{
-	int i;
-
-	x86_mce_vector_register(k7_machine_check);
-
-	/* Clear status for MC index 0 separately, we don't touch CTL,
-	 * as some Athlons cause spurious MCEs when its enabled. */
-	wrmsrl(MSR_IA32_MC0_STATUS, 0x0ULL);
-	for (i = 1; i < nr_mce_banks; i++) {
-		wrmsrl(MSR_IA32_MCx_CTL(i), 0xffffffffffffffffULL);
-		wrmsrl(MSR_IA32_MCx_STATUS(i), 0x0ULL);
-	}
-
-	return mcheck_amd_k7;
-}
diff -r 3f6672b24d45 xen/arch/x86/cpu/mcheck/mce.c
--- a/xen/arch/x86/cpu/mcheck/mce.c	Mon Oct 29 09:44:49 2012 +0100
+++ b/xen/arch/x86/cpu/mcheck/mce.c	Mon Oct 29 10:40:51 2012 +0100
@@ -566,15 +566,12 @@ int mce_available(struct cpuinfo_x86 *c)
 }
 
 /*
- * Check if bank 0 is usable for MCE. It isn't for AMD K7,
- * and Intel P6 family before model 0x1a.
+ * Check if bank 0 is usable for MCE. It isn't for
+ * Intel P6 family before model 0x1a.
  */
 unsigned int mce_firstbank(struct cpuinfo_x86 *c)
 {
     if (c->x86 == 6) {
-        if (c->x86_vendor == X86_VENDOR_AMD)
-            return 1;
-
         if (c->x86_vendor == X86_VENDOR_INTEL && c->x86_model < 0x1a)
             return 1;
     }
@@ -590,7 +587,6 @@ int show_mca_info(int inited, struct cpu
         char prefix[20];
         static const char *const type_str[] = {
             [mcheck_amd_famXX] = "AMD",
-            [mcheck_amd_k7] = "AMD K7",
             [mcheck_amd_k8] = "AMD K8",
             [mcheck_intel] = "Intel"
         };
diff -r 3f6672b24d45 xen/arch/x86/cpu/mcheck/mce.h
--- a/xen/arch/x86/cpu/mcheck/mce.h	Mon Oct 29 09:44:49 2012 +0100
+++ b/xen/arch/x86/cpu/mcheck/mce.h	Mon Oct 29 10:40:51 2012 +0100
@@ -33,7 +33,6 @@ enum mcheck_type {
 	mcheck_unset = -1,
 	mcheck_none,
 	mcheck_amd_famXX,
-	mcheck_amd_k7,
 	mcheck_amd_k8,
 	mcheck_intel
 };
diff -r 3f6672b24d45 xen/arch/x86/cpu/mcheck/mce_amd.c
--- a/xen/arch/x86/cpu/mcheck/mce_amd.c	Mon Oct 29 09:44:49 2012 +0100
+++ b/xen/arch/x86/cpu/mcheck/mce_amd.c	Mon Oct 29 10:40:51 2012 +0100
@@ -105,10 +105,6 @@ amd_mcheck_init(struct cpuinfo_x86 *ci)
     enum mcheck_type rc = mcheck_none;
 
     switch (ci->x86) {
-    case 6:
-        rc = amd_k7_mcheck_init(ci);
-        break;
-
     default:
         /* Assume that machine check support is available.
          * The minimum provided support is at least the K8. */
diff -r 3f6672b24d45 xen/arch/x86/cpu/mcheck/mce_amd.h
--- a/xen/arch/x86/cpu/mcheck/mce_amd.h	Mon Oct 29 09:44:49 2012 +0100
+++ b/xen/arch/x86/cpu/mcheck/mce_amd.h	Mon Oct 29 10:40:51 2012 +0100
@@ -1,7 +1,6 @@
 #ifndef _MCHECK_AMD_H
 #define _MCHECK_AMD_H
 
-enum mcheck_type amd_k7_mcheck_init(struct cpuinfo_x86 *c);
 enum mcheck_type amd_k8_mcheck_init(struct cpuinfo_x86 *c);
 enum mcheck_type amd_f10_mcheck_init(struct cpuinfo_x86 *c);
 
diff -r 3f6672b24d45 xen/arch/x86/cpu/mcheck/mce_amd_quirks.c
--- a/xen/arch/x86/cpu/mcheck/mce_amd_quirks.c	Mon Oct 29 09:44:49 2012 +0100
+++ b/xen/arch/x86/cpu/mcheck/mce_amd_quirks.c	Mon Oct 29 10:40:51 2012 +0100
@@ -25,8 +25,6 @@
 #define ANY -1
 
 static const struct mce_quirkdata mce_amd_quirks[] = {
-	{ 0x6 /* cpu family */, ANY /* all models */, ANY /* all steppings */,
-	  MCEQUIRK_K7_BANK0 },
 	{ 0xf /* cpu family */, ANY /* all models */, ANY /* all steppings */,
 	  MCEQUIRK_K8_GART },
 	{ 0x10 /* cpu family */, ANY /* all models */, ANY /* all steppings */,
@@ -59,9 +57,6 @@ int mcequirk_amd_apply(enum mcequirk_amd
 	u64 val;
 
 	switch (flags) {
-	case MCEQUIRK_K7_BANK0:
-		return 1; /* first bank */
-
 	case MCEQUIRK_K8_GART:
 		/*
 		 * Enable error reporting for all errors except for GART
diff -r 3f6672b24d45 xen/arch/x86/cpu/mcheck/mce_quirks.h
--- a/xen/arch/x86/cpu/mcheck/mce_quirks.h	Mon Oct 29 09:44:49 2012 +0100
+++ b/xen/arch/x86/cpu/mcheck/mce_quirks.h	Mon Oct 29 10:40:51 2012 +0100
@@ -33,8 +33,7 @@ struct mce_quirkdata {
  */
 
 enum mcequirk_amd_flags {
-	MCEQUIRK_K7_BANK0 = 1,
-	MCEQUIRK_K8_GART,
+	MCEQUIRK_K8_GART = 2,
 	MCEQUIRK_F10_GART
 };
 
diff -r 3f6672b24d45 xen/arch/x86/cpu/mcheck/non-fatal.c
--- a/xen/arch/x86/cpu/mcheck/non-fatal.c	Mon Oct 29 09:44:49 2012 +0100
+++ b/xen/arch/x86/cpu/mcheck/non-fatal.c	Mon Oct 29 10:40:51 2012 +0100
@@ -102,12 +102,6 @@ static int __init init_nonfatal_mce_chec
 	 */
 	switch (c->x86_vendor) {
 	case X86_VENDOR_AMD:
-		if (c->x86 == 6) { /* K7 */
-			init_timer(&mce_timer, mce_work_fn, NULL, 0);
-			set_timer(&mce_timer, NOW() + MCE_PERIOD);
-			break;
-		}
-
 		/* Assume we are on K8 or newer AMD CPU here */
 		amd_nonfatal_mcheck_init(c);
 		break;
diff -r 3f6672b24d45 xen/arch/x86/cpu/mcheck/x86_mca.h
--- a/xen/arch/x86/cpu/mcheck/x86_mca.h	Mon Oct 29 09:44:49 2012 +0100
+++ b/xen/arch/x86/cpu/mcheck/x86_mca.h	Mon Oct 29 10:40:51 2012 +0100
@@ -1,6 +1,6 @@
 /*
- * MCA implementation for AMD K7/K8 CPUs
- * Copyright (c) 2007 Advanced Micro Devices, Inc. 
+ * MCA implementation for AMD CPUs
+ * Copyright (c) 2007-2012 Advanced Micro Devices, Inc. 
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by

--------------050005060500090601020508
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------050005060500090601020508--


From xen-devel-bounces@lists.xen.org Mon Oct 29 11:14:57 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 11:14:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSnIo-00019m-60; Mon, 29 Oct 2012 11:14:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSnIm-00019d-Hp
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 11:14:40 +0000
Received: from [85.158.139.211:22292] by server-5.bemta-5.messagelabs.com id
	5B/17-09732-F156E805; Mon, 29 Oct 2012 11:14:39 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1351509277!18066179!1
X-Originating-IP: [216.32.181.184]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7482 invoked from network); 29 Oct 2012 11:14:38 -0000
Received: from ch1ehsobe004.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.184)
	by server-16.tower-206.messagelabs.com with AES128-SHA encrypted SMTP;
	29 Oct 2012 11:14:38 -0000
Received: from mail156-ch1-R.bigfish.com (10.43.68.232) by
	CH1EHSOBE001.bigfish.com (10.43.70.51) with Microsoft SMTP Server id
	14.1.225.23; Mon, 29 Oct 2012 11:14:36 +0000
Received: from mail156-ch1 (localhost [127.0.0.1])	by
	mail156-ch1-R.bigfish.com (Postfix) with ESMTP id 9739C600AC;
	Mon, 29 Oct 2012 11:14:36 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzc85fhc85dhzz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh34h1155h)
Received: from mail156-ch1 (localhost.localdomain [127.0.0.1]) by mail156-ch1
	(MessageSwitch) id 1351509274800259_1506;
	Mon, 29 Oct 2012 11:14:34 +0000 (UTC)
Received: from CH1EHSMHS039.bigfish.com (snatpool2.int.messaging.microsoft.com
	[10.43.68.230])	by mail156-ch1.bigfish.com (Postfix) with ESMTP id
	B768B320043;	Mon, 29 Oct 2012 11:14:34 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS039.bigfish.com (10.43.69.248) with Microsoft SMTP Server id
	14.1.225.23; Mon, 29 Oct 2012 11:14:34 +0000
X-WSS-ID: 0MCNJ89-01-1I5-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2DD4110282EB;	Mon, 29 Oct 2012 06:14:32 -0500 (CDT)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Mon, 29 Oct 2012 06:14:37 -0500
Received: from STOREXDAG03.amd.com (10.1.13.12) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Mon, 29 Oct 2012 06:14:32 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag03.amd.com
	(10.1.13.12) with Microsoft SMTP Server id 14.2.318.4; Mon, 29 Oct 2012
	07:14:31 -0400
Message-ID: <508E6516.6070805@amd.com>
Date: Mon, 29 Oct 2012 12:14:30 +0100
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" 
Content-Type: multipart/mixed; boundary="------------050005060500090601020508"
X-OriginatorOrg: amd.com
Cc: Jan Beulich 
Subject: [Xen-devel] [PATCH] MCE: remove K7 support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------050005060500090601020508
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit


Remove K7 support from MCE.

Signed-off-by: Christoph Egger 

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------050005060500090601020508
Content-Type: text/plain; charset="us-ascii"; name="xen_mce_rmk7.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_mce_rmk7.diff"
Content-Description: xen_mce_rmk7.diff

diff -r 3f6672b24d45 xen/arch/x86/cpu/mcheck/Makefile
--- a/xen/arch/x86/cpu/mcheck/Makefile	Mon Oct 29 09:44:49 2012 +0100
+++ b/xen/arch/x86/cpu/mcheck/Makefile	Mon Oct 29 10:40:51 2012 +0100
@@ -1,5 +1,4 @@
 obj-y += amd_nonfatal.o
-obj-y += k7.o
 obj-y += amd_k8.o
 obj-y += amd_f10.o
 obj-y += mce_amd.o
diff -r 3f6672b24d45 xen/arch/x86/cpu/mcheck/k7.c
--- a/xen/arch/x86/cpu/mcheck/k7.c	Mon Oct 29 09:44:49 2012 +0100
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,88 +0,0 @@
-/*
- * Athlon/Hammer specific Machine Check Exception Reporting
- * (C) Copyright 2002 Dave Jones 
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include  
-#include 
-#include 
-
-#include "mce.h"
-#include "x86_mca.h"
-
-/* Machine Check Handler For AMD Athlon/Duron */
-static void k7_machine_check(struct cpu_user_regs * regs, long error_code)
-{
-	int recover = 1;
-	uint64_t msr_content, mcgst;
-	int i;
-
-	rdmsrl(MSR_IA32_MCG_STATUS, mcgst);
-	if (mcgst & MCG_STATUS_RIPV)	/* Recoverable ? */
-		recover = 0;
-
-	printk(KERN_EMERG "CPU %d: Machine Check Exception: 0x%016"PRIx64"\n",
-		smp_processor_id(), mcgst);
-
-	for (i = 1; i < nr_mce_banks; i++) {
-		uint64_t value;
-
-		rdmsrl(MSR_IA32_MCx_STATUS(i), msr_content);
-		if (msr_content & MCi_STATUS_VAL) {
-			if (msr_content & MCi_STATUS_UC)
-				recover |= 1;
-			if (msr_content & MCi_STATUS_PCC)
-				recover |= 2;
-			printk(KERN_EMERG "Bank %d: 0x%16"PRIx64,
-				i, msr_content);
-			msr_content &= ~MCi_STATUS_VAL;
-			if (msr_content & MCi_STATUS_MISCV) {
-				rdmsrl(MSR_IA32_MCx_MISC(i), value);
-				printk("[0x%016"PRIx64"]", value);
-			}
-			if (msr_content & MCi_STATUS_ADDRV) {
-				rdmsrl(MSR_IA32_MCx_ADDR(i), value);
-				printk(" at 0x%016"PRIx64, value);
-			}
-			printk("\n");
-			/* Clear it */
-			wrmsrl(MSR_IA32_MCx_STATUS(i), 0x0ULL);
-			/* Serialize */
-			wmb();
-			add_taint(TAINT_MACHINE_CHECK);
-		}
-	}
-
-	if (recover & 2)
-		mc_panic("CPU context corrupt");
-	if (recover & 1)
-		mc_panic("Unable to continue");
-	printk(KERN_EMERG "Attempting to continue.\n");
-	mcgst &= ~MCG_STATUS_MCIP;
-	wrmsrl(MSR_IA32_MCG_STATUS, mcgst);
-}
-
-
-/* AMD K7 machine check */
-enum mcheck_type amd_k7_mcheck_init(struct cpuinfo_x86 *c)
-{
-	int i;
-
-	x86_mce_vector_register(k7_machine_check);
-
-	/* Clear status for MC index 0 separately, we don't touch CTL,
-	 * as some Athlons cause spurious MCEs when its enabled. */
-	wrmsrl(MSR_IA32_MC0_STATUS, 0x0ULL);
-	for (i = 1; i < nr_mce_banks; i++) {
-		wrmsrl(MSR_IA32_MCx_CTL(i), 0xffffffffffffffffULL);
-		wrmsrl(MSR_IA32_MCx_STATUS(i), 0x0ULL);
-	}
-
-	return mcheck_amd_k7;
-}
diff -r 3f6672b24d45 xen/arch/x86/cpu/mcheck/mce.c
--- a/xen/arch/x86/cpu/mcheck/mce.c	Mon Oct 29 09:44:49 2012 +0100
+++ b/xen/arch/x86/cpu/mcheck/mce.c	Mon Oct 29 10:40:51 2012 +0100
@@ -566,15 +566,12 @@ int mce_available(struct cpuinfo_x86 *c)
 }
 
 /*
- * Check if bank 0 is usable for MCE. It isn't for AMD K7,
- * and Intel P6 family before model 0x1a.
+ * Check if bank 0 is usable for MCE. It isn't for
+ * Intel P6 family before model 0x1a.
  */
 unsigned int mce_firstbank(struct cpuinfo_x86 *c)
 {
     if (c->x86 == 6) {
-        if (c->x86_vendor == X86_VENDOR_AMD)
-            return 1;
-
         if (c->x86_vendor == X86_VENDOR_INTEL && c->x86_model < 0x1a)
             return 1;
     }
@@ -590,7 +587,6 @@ int show_mca_info(int inited, struct cpu
         char prefix[20];
         static const char *const type_str[] = {
             [mcheck_amd_famXX] = "AMD",
-            [mcheck_amd_k7] = "AMD K7",
             [mcheck_amd_k8] = "AMD K8",
             [mcheck_intel] = "Intel"
         };
diff -r 3f6672b24d45 xen/arch/x86/cpu/mcheck/mce.h
--- a/xen/arch/x86/cpu/mcheck/mce.h	Mon Oct 29 09:44:49 2012 +0100
+++ b/xen/arch/x86/cpu/mcheck/mce.h	Mon Oct 29 10:40:51 2012 +0100
@@ -33,7 +33,6 @@ enum mcheck_type {
 	mcheck_unset = -1,
 	mcheck_none,
 	mcheck_amd_famXX,
-	mcheck_amd_k7,
 	mcheck_amd_k8,
 	mcheck_intel
 };
diff -r 3f6672b24d45 xen/arch/x86/cpu/mcheck/mce_amd.c
--- a/xen/arch/x86/cpu/mcheck/mce_amd.c	Mon Oct 29 09:44:49 2012 +0100
+++ b/xen/arch/x86/cpu/mcheck/mce_amd.c	Mon Oct 29 10:40:51 2012 +0100
@@ -105,10 +105,6 @@ amd_mcheck_init(struct cpuinfo_x86 *ci)
     enum mcheck_type rc = mcheck_none;
 
     switch (ci->x86) {
-    case 6:
-        rc = amd_k7_mcheck_init(ci);
-        break;
-
     default:
         /* Assume that machine check support is available.
          * The minimum provided support is at least the K8. */
diff -r 3f6672b24d45 xen/arch/x86/cpu/mcheck/mce_amd.h
--- a/xen/arch/x86/cpu/mcheck/mce_amd.h	Mon Oct 29 09:44:49 2012 +0100
+++ b/xen/arch/x86/cpu/mcheck/mce_amd.h	Mon Oct 29 10:40:51 2012 +0100
@@ -1,7 +1,6 @@
 #ifndef _MCHECK_AMD_H
 #define _MCHECK_AMD_H
 
-enum mcheck_type amd_k7_mcheck_init(struct cpuinfo_x86 *c);
 enum mcheck_type amd_k8_mcheck_init(struct cpuinfo_x86 *c);
 enum mcheck_type amd_f10_mcheck_init(struct cpuinfo_x86 *c);
 
diff -r 3f6672b24d45 xen/arch/x86/cpu/mcheck/mce_amd_quirks.c
--- a/xen/arch/x86/cpu/mcheck/mce_amd_quirks.c	Mon Oct 29 09:44:49 2012 +0100
+++ b/xen/arch/x86/cpu/mcheck/mce_amd_quirks.c	Mon Oct 29 10:40:51 2012 +0100
@@ -25,8 +25,6 @@
 #define ANY -1
 
 static const struct mce_quirkdata mce_amd_quirks[] = {
-	{ 0x6 /* cpu family */, ANY /* all models */, ANY /* all steppings */,
-	  MCEQUIRK_K7_BANK0 },
 	{ 0xf /* cpu family */, ANY /* all models */, ANY /* all steppings */,
 	  MCEQUIRK_K8_GART },
 	{ 0x10 /* cpu family */, ANY /* all models */, ANY /* all steppings */,
@@ -59,9 +57,6 @@ int mcequirk_amd_apply(enum mcequirk_amd
 	u64 val;
 
 	switch (flags) {
-	case MCEQUIRK_K7_BANK0:
-		return 1; /* first bank */
-
 	case MCEQUIRK_K8_GART:
 		/*
 		 * Enable error reporting for all errors except for GART
diff -r 3f6672b24d45 xen/arch/x86/cpu/mcheck/mce_quirks.h
--- a/xen/arch/x86/cpu/mcheck/mce_quirks.h	Mon Oct 29 09:44:49 2012 +0100
+++ b/xen/arch/x86/cpu/mcheck/mce_quirks.h	Mon Oct 29 10:40:51 2012 +0100
@@ -33,8 +33,7 @@ struct mce_quirkdata {
  */
 
 enum mcequirk_amd_flags {
-	MCEQUIRK_K7_BANK0 = 1,
-	MCEQUIRK_K8_GART,
+	MCEQUIRK_K8_GART = 2,
 	MCEQUIRK_F10_GART
 };
 
diff -r 3f6672b24d45 xen/arch/x86/cpu/mcheck/non-fatal.c
--- a/xen/arch/x86/cpu/mcheck/non-fatal.c	Mon Oct 29 09:44:49 2012 +0100
+++ b/xen/arch/x86/cpu/mcheck/non-fatal.c	Mon Oct 29 10:40:51 2012 +0100
@@ -102,12 +102,6 @@ static int __init init_nonfatal_mce_chec
 	 */
 	switch (c->x86_vendor) {
 	case X86_VENDOR_AMD:
-		if (c->x86 == 6) { /* K7 */
-			init_timer(&mce_timer, mce_work_fn, NULL, 0);
-			set_timer(&mce_timer, NOW() + MCE_PERIOD);
-			break;
-		}
-
 		/* Assume we are on K8 or newer AMD CPU here */
 		amd_nonfatal_mcheck_init(c);
 		break;
diff -r 3f6672b24d45 xen/arch/x86/cpu/mcheck/x86_mca.h
--- a/xen/arch/x86/cpu/mcheck/x86_mca.h	Mon Oct 29 09:44:49 2012 +0100
+++ b/xen/arch/x86/cpu/mcheck/x86_mca.h	Mon Oct 29 10:40:51 2012 +0100
@@ -1,6 +1,6 @@
 /*
- * MCA implementation for AMD K7/K8 CPUs
- * Copyright (c) 2007 Advanced Micro Devices, Inc. 
+ * MCA implementation for AMD CPUs
+ * Copyright (c) 2007-2012 Advanced Micro Devices, Inc. 
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by

--------------050005060500090601020508
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------050005060500090601020508--


From xen-devel-bounces@lists.xen.org Mon Oct 29 12:48:56 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 12:48:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSolX-0001qW-PM; Mon, 29 Oct 2012 12:48:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSolW-0001qR-P0
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 12:48:27 +0000
Received: from [85.158.143.35:21112] by server-2.bemta-4.messagelabs.com id
	43/10-22268-91B7E805; Mon, 29 Oct 2012 12:48:25 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1351514904!11753572!1
X-Originating-IP: [216.32.180.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11541 invoked from network); 29 Oct 2012 12:48:25 -0000
Received: from va3ehsobe003.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.13)
	by server-11.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	29 Oct 2012 12:48:25 -0000
Received: from mail33-va3-R.bigfish.com (10.7.14.247) by
	VA3EHSOBE013.bigfish.com (10.7.40.63) with Microsoft SMTP Server id
	14.1.225.23; Mon, 29 Oct 2012 12:48:23 +0000
Received: from mail33-va3 (localhost [127.0.0.1])	by mail33-va3-R.bigfish.com
	(Postfix) with ESMTP id C70E03A0207;
	Mon, 29 Oct 2012 12:48:23 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzc85fhc85dhzz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh34h1155h)
Received: from mail33-va3 (localhost.localdomain [127.0.0.1]) by mail33-va3
	(MessageSwitch) id 1351514900740633_8125;
	Mon, 29 Oct 2012 12:48:20 +0000 (UTC)
Received: from VA3EHSMHS046.bigfish.com (unknown [10.7.14.244])	by
	mail33-va3.bigfish.com (Postfix) with ESMTP id A685A4A00DB;
	Mon, 29 Oct 2012 12:48:20 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS046.bigfish.com (10.7.99.56) with Microsoft SMTP Server id
	14.1.225.23; Mon, 29 Oct 2012 12:48:20 +0000
X-WSS-ID: 0MCNNKI-02-FJ7-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2B392C8347;	Mon, 29 Oct 2012 07:48:17 -0500 (CDT)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Mon, 29 Oct 2012 07:48:23 -0500
Received: from STOREXDAG03.amd.com (10.1.13.12) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Mon, 29 Oct 2012 07:48:18 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag03.amd.com
	(10.1.13.12) with Microsoft SMTP Server id 14.2.318.4; Mon, 29 Oct 2012
	08:48:16 -0400
Message-ID: <508E7B0F.7060906@amd.com>
Date: Mon, 29 Oct 2012 13:48:15 +0100
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" , Jan Beulich
	
Content-Type: multipart/mixed; boundary="------------000506030003080908010405"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] MCE: merge amd quirks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------000506030003080908010405
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit


merge mce_amd_quirks.c into mce_amd.c

Signed-off-by: Christoph Egger 

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------000506030003080908010405
Content-Type: text/plain; charset="us-ascii"; name="xen_mce_quirk.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_mce_quirk.diff"
Content-Description: xen_mce_quirk.diff

diff -r e0b0a0132d1b -r 37d7243229b7 xen/arch/x86/cpu/mcheck/Makefile
--- a/xen/arch/x86/cpu/mcheck/Makefile
+++ b/xen/arch/x86/cpu/mcheck/Makefile
@@ -8,7 +8,6 @@ obj-y += mctelem.o
 obj-y += mce.o
 obj-y += mce-apei.o
 obj-y += mce_intel.o
-obj-y += mce_amd_quirks.o
 obj-y += non-fatal.o
 obj-y += util.o
 obj-y += vmce.o
diff -r e0b0a0132d1b -r 37d7243229b7 xen/arch/x86/cpu/mcheck/mce_amd.c
--- a/xen/arch/x86/cpu/mcheck/mce_amd.c
+++ b/xen/arch/x86/cpu/mcheck/mce_amd.c
@@ -21,12 +21,24 @@
 #include 
 
 #include 
+#include 
 
 #include "mce.h"
 #include "x86_mca.h"
 #include "mce_amd.h"
 #include "mcaction.h"
 
+#include "mce_quirks.h"
+
+#define ANY -1
+
+static const struct mce_quirkdata mce_amd_quirks[] = {
+    { 0xf /* cpu family */, ANY /* all models */, ANY /* all steppings */,
+      MCEQUIRK_K8_GART },
+    { 0x10 /* cpu family */, ANY /* all models */, ANY /* all steppings */,
+      MCEQUIRK_F10_GART },
+};
+
 /* Error Code Types */
 enum mc_ec_type {
     MC_EC_TLB_TYPE = 0x0010,
@@ -99,6 +111,51 @@ mc_amd_addrcheck(uint64_t status, uint64
     return 0;
 }
 
+/* MC quirks */
+enum mcequirk_amd_flags
+mcequirk_lookup_amd_quirkdata(struct cpuinfo_x86 *c)
+{
+    int i;
+
+    BUG_ON(c->x86_vendor != X86_VENDOR_AMD);
+
+    for (i = 0; i < ARRAY_SIZE(mce_amd_quirks); i++) {
+        if (c->x86 != mce_amd_quirks[i].cpu_family)
+            continue;
+        if ( (mce_amd_quirks[i].cpu_model != ANY) &&
+             (mce_amd_quirks[i].cpu_model != c->x86_model) )
+            continue;
+        if ( (mce_amd_quirks[i].cpu_stepping != ANY) &&
+             (mce_amd_quirks[i].cpu_stepping != c->x86_mask) )
+                continue;
+        return mce_amd_quirks[i].quirk;
+    }
+    return 0;
+}
+
+int mcequirk_amd_apply(enum mcequirk_amd_flags flags)
+{
+    uint64_t val;
+
+    switch (flags) {
+    case MCEQUIRK_K8_GART:
+        /*
+         * Enable error reporting for all errors except for GART
+         * TBL walk error reporting, which trips off incorrectly
+         * with AGP GART & 3ware & Cerberus.
+         */
+        wrmsrl(MSR_IA32_MCx_CTL(4), ~(1ULL << 10));
+        wrmsrl(MSR_IA32_MCx_STATUS(4), 0ULL);
+        break;
+    case MCEQUIRK_F10_GART:
+        if (rdmsr_safe(MSR_AMD64_MCx_MASK(4), val) == 0)
+                wrmsr_safe(MSR_AMD64_MCx_MASK(4), val | (1 << 10));
+        break;
+    }
+
+    return 0;
+}
+
 enum mcheck_type
 amd_mcheck_init(struct cpuinfo_x86 *ci)
 {
diff -r e0b0a0132d1b -r 37d7243229b7 xen/arch/x86/cpu/mcheck/mce_amd_quirks.c
--- a/xen/arch/x86/cpu/mcheck/mce_amd_quirks.c
+++ /dev/null
@@ -1,76 +0,0 @@
-/*
- * MCA quirks for AMD CPUs
- * Copyright (c) 2009 Advanced Micro Devices, Inc.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
- */
-
-#include 
-#include 
-
-#include "mce_quirks.h"
-
-#define ANY -1
-
-static const struct mce_quirkdata mce_amd_quirks[] = {
-	{ 0xf /* cpu family */, ANY /* all models */, ANY /* all steppings */,
-	  MCEQUIRK_K8_GART },
-	{ 0x10 /* cpu family */, ANY /* all models */, ANY /* all steppings */,
-	  MCEQUIRK_F10_GART },
-};
-
-enum mcequirk_amd_flags
-mcequirk_lookup_amd_quirkdata(struct cpuinfo_x86 *c)
-{
-	int i;
-
-	BUG_ON(c->x86_vendor != X86_VENDOR_AMD);
-
-	for (i = 0; i < ARRAY_SIZE(mce_amd_quirks); i++) {
-		if (c->x86 != mce_amd_quirks[i].cpu_family)
-			continue;
-		if ( (mce_amd_quirks[i].cpu_model != ANY) &&
-		     (mce_amd_quirks[i].cpu_model != c->x86_model) )
-			continue;
-		if ( (mce_amd_quirks[i].cpu_stepping != ANY) &&
-		     (mce_amd_quirks[i].cpu_stepping != c->x86_mask) )
-			continue;
-		return mce_amd_quirks[i].quirk;
-	}
-	return 0;
-}
-
-int mcequirk_amd_apply(enum mcequirk_amd_flags flags)
-{
-	u64 val;
-
-	switch (flags) {
-	case MCEQUIRK_K8_GART:
-		/*
-		 * Enable error reporting for all errors except for GART
-		 * TBL walk error reporting, which trips off incorrectly
-		 * with AGP GART & 3ware & Cerberus.
-		 */
-		wrmsrl(MSR_IA32_MCx_CTL(4), ~(1ULL << 10));
-		wrmsrl(MSR_IA32_MCx_STATUS(4), 0ULL);
-		break;
-	case MCEQUIRK_F10_GART:
-		if (rdmsr_safe(MSR_AMD64_MCx_MASK(4), val) == 0)
-			wrmsr_safe(MSR_AMD64_MCx_MASK(4), val | (1 << 10));
-		break;
-	}
-
-	return 0;
-}

--------------000506030003080908010405
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------000506030003080908010405--


From xen-devel-bounces@lists.xen.org Mon Oct 29 12:48:56 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 12:48:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSolX-0001qW-PM; Mon, 29 Oct 2012 12:48:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSolW-0001qR-P0
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 12:48:27 +0000
Received: from [85.158.143.35:21112] by server-2.bemta-4.messagelabs.com id
	43/10-22268-91B7E805; Mon, 29 Oct 2012 12:48:25 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1351514904!11753572!1
X-Originating-IP: [216.32.180.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11541 invoked from network); 29 Oct 2012 12:48:25 -0000
Received: from va3ehsobe003.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.13)
	by server-11.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	29 Oct 2012 12:48:25 -0000
Received: from mail33-va3-R.bigfish.com (10.7.14.247) by
	VA3EHSOBE013.bigfish.com (10.7.40.63) with Microsoft SMTP Server id
	14.1.225.23; Mon, 29 Oct 2012 12:48:23 +0000
Received: from mail33-va3 (localhost [127.0.0.1])	by mail33-va3-R.bigfish.com
	(Postfix) with ESMTP id C70E03A0207;
	Mon, 29 Oct 2012 12:48:23 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzc85fhc85dhzz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh34h1155h)
Received: from mail33-va3 (localhost.localdomain [127.0.0.1]) by mail33-va3
	(MessageSwitch) id 1351514900740633_8125;
	Mon, 29 Oct 2012 12:48:20 +0000 (UTC)
Received: from VA3EHSMHS046.bigfish.com (unknown [10.7.14.244])	by
	mail33-va3.bigfish.com (Postfix) with ESMTP id A685A4A00DB;
	Mon, 29 Oct 2012 12:48:20 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS046.bigfish.com (10.7.99.56) with Microsoft SMTP Server id
	14.1.225.23; Mon, 29 Oct 2012 12:48:20 +0000
X-WSS-ID: 0MCNNKI-02-FJ7-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2B392C8347;	Mon, 29 Oct 2012 07:48:17 -0500 (CDT)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Mon, 29 Oct 2012 07:48:23 -0500
Received: from STOREXDAG03.amd.com (10.1.13.12) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Mon, 29 Oct 2012 07:48:18 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag03.amd.com
	(10.1.13.12) with Microsoft SMTP Server id 14.2.318.4; Mon, 29 Oct 2012
	08:48:16 -0400
Message-ID: <508E7B0F.7060906@amd.com>
Date: Mon, 29 Oct 2012 13:48:15 +0100
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" , Jan Beulich
	
Content-Type: multipart/mixed; boundary="------------000506030003080908010405"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] MCE: merge amd quirks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------000506030003080908010405
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit


merge mce_amd_quirks.c into mce_amd.c

Signed-off-by: Christoph Egger 

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------000506030003080908010405
Content-Type: text/plain; charset="us-ascii"; name="xen_mce_quirk.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_mce_quirk.diff"
Content-Description: xen_mce_quirk.diff

diff -r e0b0a0132d1b -r 37d7243229b7 xen/arch/x86/cpu/mcheck/Makefile
--- a/xen/arch/x86/cpu/mcheck/Makefile
+++ b/xen/arch/x86/cpu/mcheck/Makefile
@@ -8,7 +8,6 @@ obj-y += mctelem.o
 obj-y += mce.o
 obj-y += mce-apei.o
 obj-y += mce_intel.o
-obj-y += mce_amd_quirks.o
 obj-y += non-fatal.o
 obj-y += util.o
 obj-y += vmce.o
diff -r e0b0a0132d1b -r 37d7243229b7 xen/arch/x86/cpu/mcheck/mce_amd.c
--- a/xen/arch/x86/cpu/mcheck/mce_amd.c
+++ b/xen/arch/x86/cpu/mcheck/mce_amd.c
@@ -21,12 +21,24 @@
 #include 
 
 #include 
+#include 
 
 #include "mce.h"
 #include "x86_mca.h"
 #include "mce_amd.h"
 #include "mcaction.h"
 
+#include "mce_quirks.h"
+
+#define ANY -1
+
+static const struct mce_quirkdata mce_amd_quirks[] = {
+    { 0xf /* cpu family */, ANY /* all models */, ANY /* all steppings */,
+      MCEQUIRK_K8_GART },
+    { 0x10 /* cpu family */, ANY /* all models */, ANY /* all steppings */,
+      MCEQUIRK_F10_GART },
+};
+
 /* Error Code Types */
 enum mc_ec_type {
     MC_EC_TLB_TYPE = 0x0010,
@@ -99,6 +111,51 @@ mc_amd_addrcheck(uint64_t status, uint64
     return 0;
 }
 
+/* MC quirks */
+enum mcequirk_amd_flags
+mcequirk_lookup_amd_quirkdata(struct cpuinfo_x86 *c)
+{
+    int i;
+
+    BUG_ON(c->x86_vendor != X86_VENDOR_AMD);
+
+    for (i = 0; i < ARRAY_SIZE(mce_amd_quirks); i++) {
+        if (c->x86 != mce_amd_quirks[i].cpu_family)
+            continue;
+        if ( (mce_amd_quirks[i].cpu_model != ANY) &&
+             (mce_amd_quirks[i].cpu_model != c->x86_model) )
+            continue;
+        if ( (mce_amd_quirks[i].cpu_stepping != ANY) &&
+             (mce_amd_quirks[i].cpu_stepping != c->x86_mask) )
+                continue;
+        return mce_amd_quirks[i].quirk;
+    }
+    return 0;
+}
+
+int mcequirk_amd_apply(enum mcequirk_amd_flags flags)
+{
+    uint64_t val;
+
+    switch (flags) {
+    case MCEQUIRK_K8_GART:
+        /*
+         * Enable error reporting for all errors except for GART
+         * TBL walk error reporting, which trips off incorrectly
+         * with AGP GART & 3ware & Cerberus.
+         */
+        wrmsrl(MSR_IA32_MCx_CTL(4), ~(1ULL << 10));
+        wrmsrl(MSR_IA32_MCx_STATUS(4), 0ULL);
+        break;
+    case MCEQUIRK_F10_GART:
+        if (rdmsr_safe(MSR_AMD64_MCx_MASK(4), val) == 0)
+                wrmsr_safe(MSR_AMD64_MCx_MASK(4), val | (1 << 10));
+        break;
+    }
+
+    return 0;
+}
+
 enum mcheck_type
 amd_mcheck_init(struct cpuinfo_x86 *ci)
 {
diff -r e0b0a0132d1b -r 37d7243229b7 xen/arch/x86/cpu/mcheck/mce_amd_quirks.c
--- a/xen/arch/x86/cpu/mcheck/mce_amd_quirks.c
+++ /dev/null
@@ -1,76 +0,0 @@
-/*
- * MCA quirks for AMD CPUs
- * Copyright (c) 2009 Advanced Micro Devices, Inc.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
- */
-
-#include 
-#include 
-
-#include "mce_quirks.h"
-
-#define ANY -1
-
-static const struct mce_quirkdata mce_amd_quirks[] = {
-	{ 0xf /* cpu family */, ANY /* all models */, ANY /* all steppings */,
-	  MCEQUIRK_K8_GART },
-	{ 0x10 /* cpu family */, ANY /* all models */, ANY /* all steppings */,
-	  MCEQUIRK_F10_GART },
-};
-
-enum mcequirk_amd_flags
-mcequirk_lookup_amd_quirkdata(struct cpuinfo_x86 *c)
-{
-	int i;
-
-	BUG_ON(c->x86_vendor != X86_VENDOR_AMD);
-
-	for (i = 0; i < ARRAY_SIZE(mce_amd_quirks); i++) {
-		if (c->x86 != mce_amd_quirks[i].cpu_family)
-			continue;
-		if ( (mce_amd_quirks[i].cpu_model != ANY) &&
-		     (mce_amd_quirks[i].cpu_model != c->x86_model) )
-			continue;
-		if ( (mce_amd_quirks[i].cpu_stepping != ANY) &&
-		     (mce_amd_quirks[i].cpu_stepping != c->x86_mask) )
-			continue;
-		return mce_amd_quirks[i].quirk;
-	}
-	return 0;
-}
-
-int mcequirk_amd_apply(enum mcequirk_amd_flags flags)
-{
-	u64 val;
-
-	switch (flags) {
-	case MCEQUIRK_K8_GART:
-		/*
-		 * Enable error reporting for all errors except for GART
-		 * TBL walk error reporting, which trips off incorrectly
-		 * with AGP GART & 3ware & Cerberus.
-		 */
-		wrmsrl(MSR_IA32_MCx_CTL(4), ~(1ULL << 10));
-		wrmsrl(MSR_IA32_MCx_STATUS(4), 0ULL);
-		break;
-	case MCEQUIRK_F10_GART:
-		if (rdmsr_safe(MSR_AMD64_MCx_MASK(4), val) == 0)
-			wrmsr_safe(MSR_AMD64_MCx_MASK(4), val | (1 << 10));
-		break;
-	}
-
-	return 0;
-}

--------------000506030003080908010405
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------000506030003080908010405--


From xen-devel-bounces@lists.xen.org Mon Oct 29 12:51:50 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 12:51:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSooR-0001wa-DA; Mon, 29 Oct 2012 12:51:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSoj5-0001pb-6V
	for xen-devel@lists.xensource.com; Mon, 29 Oct 2012 12:45:55 +0000
Received: from [193.109.254.147:54571] by server-7.bemta-14.messagelabs.com id
	08/F8-24122-28A7E805; Mon, 29 Oct 2012 12:45:54 +0000
X-Env-Sender: hannes@stressinduktion.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1351514752!1142094!1
X-Originating-IP: [87.106.68.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16567 invoked from network); 29 Oct 2012 12:45:53 -0000
Received: from order.stressinduktion.org (HELO order.stressinduktion.org)
	(87.106.68.36)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Oct 2012 12:45:53 -0000
Received: by order.stressinduktion.org (Postfix, from userid 500)
	id 586C61A0CC97; Mon, 29 Oct 2012 13:45:52 +0100 (CET)
Date: Mon, 29 Oct 2012 13:45:52 +0100
From: Hannes Frederic Sowa 
To: Jan Beulich 
Message-ID: <20121029124552.GB18860@order.stressinduktion.org>
References: <20121028174441.GA30893@order.stressinduktion.org>
	<508E5D5C02000078000A5028@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <508E5D5C02000078000A5028@nat28.tlf.novell.com>
X-Mailman-Approved-At: Mon, 29 Oct 2012 12:51:25 +0000
Cc: xen-devel@lists.xensource.com, xen-devel 
Subject: Re: [Xen-devel] [PATCH] dbgp: fix compile error on building
	EARLY_PRINTK_DBGP without USB_SUPPORT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 29, 2012 at 09:41:32AM +0000, Jan Beulich wrote:
> >>> On 28.10.12 at 18:44, Hannes Frederic Sowa  wrote:
> > This patch fixes following compile error:
> > 
> > drivers/built-in.o: In function `dbgp_reset_prep':
> > linux/drivers/usb/early/ehci-dbgp.c:984: undefined reference to 
> > `xen_dbgp_reset_prep'
> > drivers/built-in.o: In function `dbgp_external_startup':
> > linux/drivers/usb/early/ehci-dbgp.c:619: undefined reference to 
> > `xen_dbgp_external_startup'
> > 
> > EARLY_PRINTK_DBGP should work without USB_SUPPORT.
> 
> An alternative patch was previously suggested to address this
> build problem.

Hm, ok. I searched for a patch in the archives but did not find one. Do you
have a link?

Greetings,

  Hannes


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 12:51:50 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 12:51:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSooR-0001wa-DA; Mon, 29 Oct 2012 12:51:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSoj5-0001pb-6V
	for xen-devel@lists.xensource.com; Mon, 29 Oct 2012 12:45:55 +0000
Received: from [193.109.254.147:54571] by server-7.bemta-14.messagelabs.com id
	08/F8-24122-28A7E805; Mon, 29 Oct 2012 12:45:54 +0000
X-Env-Sender: hannes@stressinduktion.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1351514752!1142094!1
X-Originating-IP: [87.106.68.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16567 invoked from network); 29 Oct 2012 12:45:53 -0000
Received: from order.stressinduktion.org (HELO order.stressinduktion.org)
	(87.106.68.36)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Oct 2012 12:45:53 -0000
Received: by order.stressinduktion.org (Postfix, from userid 500)
	id 586C61A0CC97; Mon, 29 Oct 2012 13:45:52 +0100 (CET)
Date: Mon, 29 Oct 2012 13:45:52 +0100
From: Hannes Frederic Sowa 
To: Jan Beulich 
Message-ID: <20121029124552.GB18860@order.stressinduktion.org>
References: <20121028174441.GA30893@order.stressinduktion.org>
	<508E5D5C02000078000A5028@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <508E5D5C02000078000A5028@nat28.tlf.novell.com>
X-Mailman-Approved-At: Mon, 29 Oct 2012 12:51:25 +0000
Cc: xen-devel@lists.xensource.com, xen-devel 
Subject: Re: [Xen-devel] [PATCH] dbgp: fix compile error on building
	EARLY_PRINTK_DBGP without USB_SUPPORT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 29, 2012 at 09:41:32AM +0000, Jan Beulich wrote:
> >>> On 28.10.12 at 18:44, Hannes Frederic Sowa  wrote:
> > This patch fixes following compile error:
> > 
> > drivers/built-in.o: In function `dbgp_reset_prep':
> > linux/drivers/usb/early/ehci-dbgp.c:984: undefined reference to 
> > `xen_dbgp_reset_prep'
> > drivers/built-in.o: In function `dbgp_external_startup':
> > linux/drivers/usb/early/ehci-dbgp.c:619: undefined reference to 
> > `xen_dbgp_external_startup'
> > 
> > EARLY_PRINTK_DBGP should work without USB_SUPPORT.
> 
> An alternative patch was previously suggested to address this
> build problem.

Hm, ok. I searched for a patch in the archives but did not find one. Do you
have a link?

Greetings,

  Hannes


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 12:51:51 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 12:51:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSooR-0001wi-O0; Mon, 29 Oct 2012 12:51:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSoj6-0001pg-BN
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 12:45:56 +0000
Received: from [85.158.143.35:61234] by server-3.bemta-4.messagelabs.com id
	D2/A5-24279-38A7E805; Mon, 29 Oct 2012 12:45:55 +0000
X-Env-Sender: hannes@stressinduktion.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1351514752!16220507!1
X-Originating-IP: [87.106.68.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28027 invoked from network); 29 Oct 2012 12:45:53 -0000
Received: from order.stressinduktion.org (HELO order.stressinduktion.org)
	(87.106.68.36)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Oct 2012 12:45:53 -0000
Received: by order.stressinduktion.org (Postfix, from userid 500)
	id 586C61A0CC97; Mon, 29 Oct 2012 13:45:52 +0100 (CET)
Date: Mon, 29 Oct 2012 13:45:52 +0100
From: Hannes Frederic Sowa 
To: Jan Beulich 
Message-ID: <20121029124552.GB18860@order.stressinduktion.org>
References: <20121028174441.GA30893@order.stressinduktion.org>
	<508E5D5C02000078000A5028@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <508E5D5C02000078000A5028@nat28.tlf.novell.com>
X-Mailman-Approved-At: Mon, 29 Oct 2012 12:51:25 +0000
Cc: xen-devel@lists.xensource.com, xen-devel 
Subject: Re: [Xen-devel] [PATCH] dbgp: fix compile error on building
	EARLY_PRINTK_DBGP without USB_SUPPORT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 29, 2012 at 09:41:32AM +0000, Jan Beulich wrote:
> >>> On 28.10.12 at 18:44, Hannes Frederic Sowa  wrote:
> > This patch fixes following compile error:
> > 
> > drivers/built-in.o: In function `dbgp_reset_prep':
> > linux/drivers/usb/early/ehci-dbgp.c:984: undefined reference to 
> > `xen_dbgp_reset_prep'
> > drivers/built-in.o: In function `dbgp_external_startup':
> > linux/drivers/usb/early/ehci-dbgp.c:619: undefined reference to 
> > `xen_dbgp_external_startup'
> > 
> > EARLY_PRINTK_DBGP should work without USB_SUPPORT.
> 
> An alternative patch was previously suggested to address this
> build problem.

Hm, ok. I searched for a patch in the archives but did not find one. Do you
have a link?

Greetings,

  Hannes


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 12:51:51 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 12:51:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSooR-0001wi-O0; Mon, 29 Oct 2012 12:51:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSoj6-0001pg-BN
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 12:45:56 +0000
Received: from [85.158.143.35:61234] by server-3.bemta-4.messagelabs.com id
	D2/A5-24279-38A7E805; Mon, 29 Oct 2012 12:45:55 +0000
X-Env-Sender: hannes@stressinduktion.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1351514752!16220507!1
X-Originating-IP: [87.106.68.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28027 invoked from network); 29 Oct 2012 12:45:53 -0000
Received: from order.stressinduktion.org (HELO order.stressinduktion.org)
	(87.106.68.36)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Oct 2012 12:45:53 -0000
Received: by order.stressinduktion.org (Postfix, from userid 500)
	id 586C61A0CC97; Mon, 29 Oct 2012 13:45:52 +0100 (CET)
Date: Mon, 29 Oct 2012 13:45:52 +0100
From: Hannes Frederic Sowa 
To: Jan Beulich 
Message-ID: <20121029124552.GB18860@order.stressinduktion.org>
References: <20121028174441.GA30893@order.stressinduktion.org>
	<508E5D5C02000078000A5028@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <508E5D5C02000078000A5028@nat28.tlf.novell.com>
X-Mailman-Approved-At: Mon, 29 Oct 2012 12:51:25 +0000
Cc: xen-devel@lists.xensource.com, xen-devel 
Subject: Re: [Xen-devel] [PATCH] dbgp: fix compile error on building
	EARLY_PRINTK_DBGP without USB_SUPPORT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 29, 2012 at 09:41:32AM +0000, Jan Beulich wrote:
> >>> On 28.10.12 at 18:44, Hannes Frederic Sowa  wrote:
> > This patch fixes following compile error:
> > 
> > drivers/built-in.o: In function `dbgp_reset_prep':
> > linux/drivers/usb/early/ehci-dbgp.c:984: undefined reference to 
> > `xen_dbgp_reset_prep'
> > drivers/built-in.o: In function `dbgp_external_startup':
> > linux/drivers/usb/early/ehci-dbgp.c:619: undefined reference to 
> > `xen_dbgp_external_startup'
> > 
> > EARLY_PRINTK_DBGP should work without USB_SUPPORT.
> 
> An alternative patch was previously suggested to address this
> build problem.

Hm, ok. I searched for a patch in the archives but did not find one. Do you
have a link?

Greetings,

  Hannes


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 12:52:50 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 12:52:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSopU-00024e-7D; Mon, 29 Oct 2012 12:52:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSopT-00024O-6x
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 12:52:31 +0000
Received: from [85.158.138.51:27137] by server-2.bemta-3.messagelabs.com id
	67/95-00604-E0C7E805; Mon, 29 Oct 2012 12:52:30 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1351515147!21487711!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODI4MTEw\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9214 invoked from network); 29 Oct 2012 12:52:29 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Oct 2012 12:52:29 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9TCqJIl013396
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 29 Oct 2012 12:52:20 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9TCqHeI026182
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 29 Oct 2012 12:52:18 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9TCqHqV017348; Mon, 29 Oct 2012 07:52:17 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 29 Oct 2012 05:52:17 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id F0A114042D; Mon, 29 Oct 2012 08:39:50 -0400 (EDT)
Date: Mon, 29 Oct 2012 08:39:50 -0400
From: Konrad Rzeszutek Wilk 
To: "Liu, Jinsong" 
Message-ID: <20121029123950.GK2708@phenom.dumpdata.com>
References: 
	<5089676602000078000A4928@nat28.tlf.novell.com>
	
	<508A89CB020000780008E6ED@nat28.tlf.novell.com>
	
	
	<20121026201409.GF2708@phenom.dumpdata.com>
	
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Konrad Rzeszutek Wilk ,
	"linux-kernel@vger.kernel.org" ,
	Jan Beulich ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 1/2] Xen acpi pad implement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 29, 2012 at 03:38:14AM +0000, Liu, Jinsong wrote:
> It's doable to register a stub for xen. However, it's not preferred, say, to make xen pad as module, considering the case 'rmmod xen_acpi_pad' then 'insmod acpi_pad'? Under such case there is risk of mwait #UD, if we want to remove mwait check as 'patch 2/2: Revert-pad-config-check-in-xen_check_mwait.patch' did, advantages of which is to enjoy deep Cx.

You are missing my point. This is what I was thinking off:


>From 5f30320b8a1c21d60a2c22e98bcf013b7773938b Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk 
Date: Mon, 29 Oct 2012 08:38:22 -0400
Subject: [PATCH] xen/acpi: Provide a stub function to register for ACPI PAD
 module.

TODO: Give more details.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 drivers/xen/Kconfig             |    5 ++
 drivers/xen/Makefile            |    3 +-
 drivers/xen/xen-acpi-pad-stub.c |  128 +++++++++++++++++++++++++++++++++++++++
 drivers/xen/xen-acpi.h          |    2 +
 4 files changed, 137 insertions(+), 1 deletions(-)
 create mode 100644 drivers/xen/xen-acpi-pad-stub.c
 create mode 100644 drivers/xen/xen-acpi.h

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index d4dffcd..9156a08 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -204,4 +204,9 @@ config XEN_MCE_LOG
 	  Allow kernel fetching MCE error from Xen platform and
 	  converting it into Linux mcelog format for mcelog tools
 
+config XEN_ACPI_PAD_STUB
+	bool
+	depends on XEN_DOM0 && X86_64 && ACPI
+	default n
+
 endmenu
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 0e863703..d1895d9 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -9,9 +9,10 @@ nostackp := $(call cc-option, -fno-stack-protector)
 CFLAGS_features.o			:= $(nostackp)
 
 dom0-$(CONFIG_PCI) += pci.o
-dom0-$(CONFIG_USB_SUPPORT) += dbgp.o
+dom0-$(CONFIG_USB_EHCI_HCD) += dbgp.o
 dom0-$(CONFIG_ACPI) += acpi.o
 dom0-$(CONFIG_X86) += pcpu.o
+dom0-$(CONFIG_XEN_ACPI_PAD_STUB)	+= xen-acpi-pad-stub.o
 obj-$(CONFIG_XEN_DOM0)			+= $(dom0-y)
 obj-$(CONFIG_BLOCK)			+= biomerge.o
 obj-$(CONFIG_XEN_XENCOMM)		+= xencomm.o
diff --git a/drivers/xen/xen-acpi-pad-stub.c b/drivers/xen/xen-acpi-pad-stub.c
new file mode 100644
index 0000000..cac9a39
--- /dev/null
+++ b/drivers/xen/xen-acpi-pad-stub.c
@@ -0,0 +1,128 @@
+/*
+ * Copyright 2012 by Oracle Inc
+ * Author: Konrad Rzeszutek Wilk 
+ *
+ * This code borrows ideas from https://lkml.org/lkml/2011/11/30/249
+ * so many thanks go to Kevin Tian 
+ * and Yu Ke .
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+/* TODO: Needs comments. */
+static struct acpi_device_ops *xen_acpi_pad_ops;
+static bool __read_mostly xen_acpi_pad_registered;
+static DEFINE_SPINLOCK(xen_acpi_pad_spinlock);
+
+int xen_register_acpi_pad_owner(struct acpi_device_ops *ops)
+{
+	if (xen_acpi_pad_ops)
+		return -EEXIST;
+
+	spin_lock(&xen_acpi_pad_spinlock);
+	xen_acpi_pad_ops = ops;
+	spin_unlock(&xen_acpi_pad_spinlock);
+	return 0;
+}
+int xen_unregister_acpi_pad_owner(struct acpi_device_ops *ops)
+{
+	spin_lock(&xen_acpi_pad_spinlock);
+	if (xen_acpi_pad_ops != ops) {
+		spin_unlock(&xen_acpi_pad_spinlock);
+		return -ENODEV;
+	}
+	xen_acpi_pad_ops = NULL;
+	spin_unlock(&xen_acpi_pad_spinlock);
+	return 0;
+}
+
+static int xen_acpi_pad_remove(struct acpi_device *device, int type)
+{
+	int ret = -ENOSYS;
+
+	spin_lock(&xen_acpi_pad_spinlock);
+	if (xen_acpi_pad_ops && xen_acpi_pad_ops->remove)
+		ret = xen_acpi_pad_ops->remove(device, type);
+	spin_unlock(&xen_acpi_pad_spinlock);
+	return ret;
+}
+static int xen_acpi_pad_add(struct acpi_device *device)
+{
+	int ret = -ENOSYS;
+	spin_lock(&xen_acpi_pad_spinlock);
+	if (xen_acpi_pad_ops && xen_acpi_pad_ops->add)
+		ret = xen_acpi_pad_ops->add(device);
+	spin_unlock(&xen_acpi_pad_spinlock);
+	return ret;
+}
+
+static const struct acpi_device_id pad_device_ids[] = {
+	{"ACPI000C", 0},
+	{"", 0},
+};
+MODULE_DEVICE_TABLE(acpi, pad_device_ids);
+#define ACPI_PROCESSOR_AGGREGATOR_CLASS "acpi_pad"
+
+static struct acpi_driver xen_acpi_pad_driver = {
+	.name = "processor_aggregator",
+	.class = ACPI_PROCESSOR_AGGREGATOR_CLASS,
+	.ids = pad_device_ids,
+	.ops = {
+		.add = xen_acpi_pad_add,
+		.remove = xen_acpi_pad_remove,
+	},
+};
+
+static int __init xen_acpi_pad_stub_init(void)
+{
+	int ret = -ENOSYS;
+	unsigned version;
+
+	if (!xen_initial_domain())
+		return -ENODEV;
+
+	version = HYPERVISOR_xen_version(XENVER_version, NULL);
+
+	if ((version >> 16 >= 4) && ((version & 0xffff) >= 2)) {
+        	ret = acpi_bus_register_driver(&xen_acpi_pad_driver);
+        	if (!ret)
+			xen_acpi_pad_registered = true;
+    	}
+    	return ret;
+}
+#if 0
+/* For testing purposes. */
+static void __exit xen_acpi_pad_stub_exit(void)
+{
+	if (xen_acpi_pad_registered)
+		acpi_bus_unregister_driver(&xen_acpi_pad_driver);
+	/* The driver should have unregistered first ! */
+	if (WARN_ON(xen_acpi_pad_ops))
+		xen_acpi_pad_ops = NULL;
+}
+#endif
+subsys_initcall(xen_acpi_pad_stub_init);
diff --git a/drivers/xen/xen-acpi.h b/drivers/xen/xen-acpi.h
new file mode 100644
index 0000000..a0867b2
--- /dev/null
+++ b/drivers/xen/xen-acpi.h
@@ -0,0 +1,2 @@
+int xen_register_acpi_pad_owner(struct acpi_device_ops *ops);
+int xen_unregister_acpi_pad_owner(struct acpi_device_ops *ops);
-- 
1.7.7.6

> 
> IMHO to prevent mwait #UD, native pad should never have chance to register successfully when running under Xen. So it's better never unregister/disable xen pad.

With the registration stub I mentioned that won't be a problem.

> 
> Konrad Rzeszutek Wilk wrote:
> >> --- a/drivers/xen/Makefile
> >> +++ b/drivers/xen/Makefile
> >> @@ -29,6 +29,7 @@ obj-$(CONFIG_XEN_MCE_LOG)		+= mcelog.o
> >>  obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+= xen-pciback/
> >>  obj-$(CONFIG_XEN_PRIVCMD)		+= xen-privcmd.o
> >>  obj-$(CONFIG_XEN_ACPI_PROCESSOR)	+= xen-acpi-processor.o
> >> +obj-$(CONFIG_XEN_DOM0)			+= xen_acpi_pad.o
> > 
> > We should have a Kconfig option. In it, please mention what
> > version of hypervisor supports this functionality.
> > 
> 
> Kconfig option for xen pad is not preferred, considering if we disable xen pad and then register native pad driver? (of course the precondition is that we do not register stub for xen).

That should be OK with the stub.

> 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +
> >> +#if defined(CONFIG_ACPI_PROCESSOR_AGGREGATOR) || \
> >> +		defined(CONFIG_ACPI_PROCESSOR_AGGREGATOR_MODULE)
> > 
> > I don't think you need that.
> > 
> 
> OK.
> 
> >> +
> >> +static int __init xen_acpi_pad_init(void)
> >> +{
> >> +	/* Only DOM0 is responsible for Xen acpi pad */
> >> +	if (xen_initial_domain())
> >> +		return acpi_bus_register_driver(&xen_acpi_pad_driver); +
> >> +	return -ENODEV;
> >> +}
> >> +subsys_initcall(xen_acpi_pad_init);
> > 
> > 
> > No way of making this a module? It would be nice - perhaps have a stub
> > function that registers the bus but does not do anything until this
> > proper module is loaded?
> > 
> 
> It's doable but not preferred, reason as above.
> 
> >> +
> >> +#endif
> >> diff --git a/include/xen/interface/platform.h
> >> b/include/xen/interface/platform.h index 4755b5f..0f44376 100644 ---
> >> a/include/xen/interface/platform.h +++
> >> b/include/xen/interface/platform.h @@ -324,6 +324,22 @@ struct
> >>  xenpf_cpu_ol { };
> >>  DEFINE_GUEST_HANDLE_STRUCT(xenpf_cpu_ol);
> >> 
> >> +/*
> >> + * CMD 58 and 59 are reserved for cpu hotadd and memory hotadd,
> >> + * which already occupied at Xen hypervisor side.
> >            ^- are
> > 
> 
> Sure.
> 
> Thanks,
> Jinsong

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 12:52:50 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 12:52:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSopU-00024e-7D; Mon, 29 Oct 2012 12:52:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSopT-00024O-6x
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 12:52:31 +0000
Received: from [85.158.138.51:27137] by server-2.bemta-3.messagelabs.com id
	67/95-00604-E0C7E805; Mon, 29 Oct 2012 12:52:30 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1351515147!21487711!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODI4MTEw\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9214 invoked from network); 29 Oct 2012 12:52:29 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Oct 2012 12:52:29 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9TCqJIl013396
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 29 Oct 2012 12:52:20 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9TCqHeI026182
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 29 Oct 2012 12:52:18 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9TCqHqV017348; Mon, 29 Oct 2012 07:52:17 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 29 Oct 2012 05:52:17 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id F0A114042D; Mon, 29 Oct 2012 08:39:50 -0400 (EDT)
Date: Mon, 29 Oct 2012 08:39:50 -0400
From: Konrad Rzeszutek Wilk 
To: "Liu, Jinsong" 
Message-ID: <20121029123950.GK2708@phenom.dumpdata.com>
References: 
	<5089676602000078000A4928@nat28.tlf.novell.com>
	
	<508A89CB020000780008E6ED@nat28.tlf.novell.com>
	
	
	<20121026201409.GF2708@phenom.dumpdata.com>
	
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Konrad Rzeszutek Wilk ,
	"linux-kernel@vger.kernel.org" ,
	Jan Beulich ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 1/2] Xen acpi pad implement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 29, 2012 at 03:38:14AM +0000, Liu, Jinsong wrote:
> It's doable to register a stub for xen. However, it's not preferred, say, to make xen pad as module, considering the case 'rmmod xen_acpi_pad' then 'insmod acpi_pad'? Under such case there is risk of mwait #UD, if we want to remove mwait check as 'patch 2/2: Revert-pad-config-check-in-xen_check_mwait.patch' did, advantages of which is to enjoy deep Cx.

You are missing my point. This is what I was thinking off:


>From 5f30320b8a1c21d60a2c22e98bcf013b7773938b Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk 
Date: Mon, 29 Oct 2012 08:38:22 -0400
Subject: [PATCH] xen/acpi: Provide a stub function to register for ACPI PAD
 module.

TODO: Give more details.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 drivers/xen/Kconfig             |    5 ++
 drivers/xen/Makefile            |    3 +-
 drivers/xen/xen-acpi-pad-stub.c |  128 +++++++++++++++++++++++++++++++++++++++
 drivers/xen/xen-acpi.h          |    2 +
 4 files changed, 137 insertions(+), 1 deletions(-)
 create mode 100644 drivers/xen/xen-acpi-pad-stub.c
 create mode 100644 drivers/xen/xen-acpi.h

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index d4dffcd..9156a08 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -204,4 +204,9 @@ config XEN_MCE_LOG
 	  Allow kernel fetching MCE error from Xen platform and
 	  converting it into Linux mcelog format for mcelog tools
 
+config XEN_ACPI_PAD_STUB
+	bool
+	depends on XEN_DOM0 && X86_64 && ACPI
+	default n
+
 endmenu
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 0e863703..d1895d9 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -9,9 +9,10 @@ nostackp := $(call cc-option, -fno-stack-protector)
 CFLAGS_features.o			:= $(nostackp)
 
 dom0-$(CONFIG_PCI) += pci.o
-dom0-$(CONFIG_USB_SUPPORT) += dbgp.o
+dom0-$(CONFIG_USB_EHCI_HCD) += dbgp.o
 dom0-$(CONFIG_ACPI) += acpi.o
 dom0-$(CONFIG_X86) += pcpu.o
+dom0-$(CONFIG_XEN_ACPI_PAD_STUB)	+= xen-acpi-pad-stub.o
 obj-$(CONFIG_XEN_DOM0)			+= $(dom0-y)
 obj-$(CONFIG_BLOCK)			+= biomerge.o
 obj-$(CONFIG_XEN_XENCOMM)		+= xencomm.o
diff --git a/drivers/xen/xen-acpi-pad-stub.c b/drivers/xen/xen-acpi-pad-stub.c
new file mode 100644
index 0000000..cac9a39
--- /dev/null
+++ b/drivers/xen/xen-acpi-pad-stub.c
@@ -0,0 +1,128 @@
+/*
+ * Copyright 2012 by Oracle Inc
+ * Author: Konrad Rzeszutek Wilk 
+ *
+ * This code borrows ideas from https://lkml.org/lkml/2011/11/30/249
+ * so many thanks go to Kevin Tian 
+ * and Yu Ke .
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+/* TODO: Needs comments. */
+static struct acpi_device_ops *xen_acpi_pad_ops;
+static bool __read_mostly xen_acpi_pad_registered;
+static DEFINE_SPINLOCK(xen_acpi_pad_spinlock);
+
+int xen_register_acpi_pad_owner(struct acpi_device_ops *ops)
+{
+	if (xen_acpi_pad_ops)
+		return -EEXIST;
+
+	spin_lock(&xen_acpi_pad_spinlock);
+	xen_acpi_pad_ops = ops;
+	spin_unlock(&xen_acpi_pad_spinlock);
+	return 0;
+}
+int xen_unregister_acpi_pad_owner(struct acpi_device_ops *ops)
+{
+	spin_lock(&xen_acpi_pad_spinlock);
+	if (xen_acpi_pad_ops != ops) {
+		spin_unlock(&xen_acpi_pad_spinlock);
+		return -ENODEV;
+	}
+	xen_acpi_pad_ops = NULL;
+	spin_unlock(&xen_acpi_pad_spinlock);
+	return 0;
+}
+
+static int xen_acpi_pad_remove(struct acpi_device *device, int type)
+{
+	int ret = -ENOSYS;
+
+	spin_lock(&xen_acpi_pad_spinlock);
+	if (xen_acpi_pad_ops && xen_acpi_pad_ops->remove)
+		ret = xen_acpi_pad_ops->remove(device, type);
+	spin_unlock(&xen_acpi_pad_spinlock);
+	return ret;
+}
+static int xen_acpi_pad_add(struct acpi_device *device)
+{
+	int ret = -ENOSYS;
+	spin_lock(&xen_acpi_pad_spinlock);
+	if (xen_acpi_pad_ops && xen_acpi_pad_ops->add)
+		ret = xen_acpi_pad_ops->add(device);
+	spin_unlock(&xen_acpi_pad_spinlock);
+	return ret;
+}
+
+static const struct acpi_device_id pad_device_ids[] = {
+	{"ACPI000C", 0},
+	{"", 0},
+};
+MODULE_DEVICE_TABLE(acpi, pad_device_ids);
+#define ACPI_PROCESSOR_AGGREGATOR_CLASS "acpi_pad"
+
+static struct acpi_driver xen_acpi_pad_driver = {
+	.name = "processor_aggregator",
+	.class = ACPI_PROCESSOR_AGGREGATOR_CLASS,
+	.ids = pad_device_ids,
+	.ops = {
+		.add = xen_acpi_pad_add,
+		.remove = xen_acpi_pad_remove,
+	},
+};
+
+static int __init xen_acpi_pad_stub_init(void)
+{
+	int ret = -ENOSYS;
+	unsigned version;
+
+	if (!xen_initial_domain())
+		return -ENODEV;
+
+	version = HYPERVISOR_xen_version(XENVER_version, NULL);
+
+	if ((version >> 16 >= 4) && ((version & 0xffff) >= 2)) {
+        	ret = acpi_bus_register_driver(&xen_acpi_pad_driver);
+        	if (!ret)
+			xen_acpi_pad_registered = true;
+    	}
+    	return ret;
+}
+#if 0
+/* For testing purposes. */
+static void __exit xen_acpi_pad_stub_exit(void)
+{
+	if (xen_acpi_pad_registered)
+		acpi_bus_unregister_driver(&xen_acpi_pad_driver);
+	/* The driver should have unregistered first ! */
+	if (WARN_ON(xen_acpi_pad_ops))
+		xen_acpi_pad_ops = NULL;
+}
+#endif
+subsys_initcall(xen_acpi_pad_stub_init);
diff --git a/drivers/xen/xen-acpi.h b/drivers/xen/xen-acpi.h
new file mode 100644
index 0000000..a0867b2
--- /dev/null
+++ b/drivers/xen/xen-acpi.h
@@ -0,0 +1,2 @@
+int xen_register_acpi_pad_owner(struct acpi_device_ops *ops);
+int xen_unregister_acpi_pad_owner(struct acpi_device_ops *ops);
-- 
1.7.7.6

> 
> IMHO to prevent mwait #UD, native pad should never have chance to register successfully when running under Xen. So it's better never unregister/disable xen pad.

With the registration stub I mentioned that won't be a problem.

> 
> Konrad Rzeszutek Wilk wrote:
> >> --- a/drivers/xen/Makefile
> >> +++ b/drivers/xen/Makefile
> >> @@ -29,6 +29,7 @@ obj-$(CONFIG_XEN_MCE_LOG)		+= mcelog.o
> >>  obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+= xen-pciback/
> >>  obj-$(CONFIG_XEN_PRIVCMD)		+= xen-privcmd.o
> >>  obj-$(CONFIG_XEN_ACPI_PROCESSOR)	+= xen-acpi-processor.o
> >> +obj-$(CONFIG_XEN_DOM0)			+= xen_acpi_pad.o
> > 
> > We should have a Kconfig option. In it, please mention what
> > version of hypervisor supports this functionality.
> > 
> 
> Kconfig option for xen pad is not preferred, considering if we disable xen pad and then register native pad driver? (of course the precondition is that we do not register stub for xen).

That should be OK with the stub.

> 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +
> >> +#if defined(CONFIG_ACPI_PROCESSOR_AGGREGATOR) || \
> >> +		defined(CONFIG_ACPI_PROCESSOR_AGGREGATOR_MODULE)
> > 
> > I don't think you need that.
> > 
> 
> OK.
> 
> >> +
> >> +static int __init xen_acpi_pad_init(void)
> >> +{
> >> +	/* Only DOM0 is responsible for Xen acpi pad */
> >> +	if (xen_initial_domain())
> >> +		return acpi_bus_register_driver(&xen_acpi_pad_driver); +
> >> +	return -ENODEV;
> >> +}
> >> +subsys_initcall(xen_acpi_pad_init);
> > 
> > 
> > No way of making this a module? It would be nice - perhaps have a stub
> > function that registers the bus but does not do anything until this
> > proper module is loaded?
> > 
> 
> It's doable but not preferred, reason as above.
> 
> >> +
> >> +#endif
> >> diff --git a/include/xen/interface/platform.h
> >> b/include/xen/interface/platform.h index 4755b5f..0f44376 100644 ---
> >> a/include/xen/interface/platform.h +++
> >> b/include/xen/interface/platform.h @@ -324,6 +324,22 @@ struct
> >>  xenpf_cpu_ol { };
> >>  DEFINE_GUEST_HANDLE_STRUCT(xenpf_cpu_ol);
> >> 
> >> +/*
> >> + * CMD 58 and 59 are reserved for cpu hotadd and memory hotadd,
> >> + * which already occupied at Xen hypervisor side.
> >            ^- are
> > 
> 
> Sure.
> 
> Thanks,
> Jinsong

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 13:00:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 13:00:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSowf-0002PG-4f; Mon, 29 Oct 2012 12:59:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSowd-0002P9-NM
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 12:59:55 +0000
Received: from [85.158.143.99:30163] by server-1.bemta-4.messagelabs.com id
	DC/9C-19134-ACD7E805; Mon, 29 Oct 2012 12:59:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1351515594!24412139!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2047 invoked from network); 29 Oct 2012 12:59:54 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-216.messagelabs.com with SMTP;
	29 Oct 2012 12:59:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 29 Oct 2012 12:59:53 +0000
Message-Id: <508E8C0102000078000A5234@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 29 Oct 2012 13:00:33 +0000
From: "Jan Beulich" 
To: "Hannes Frederic Sowa" 
References: <20121028174441.GA30893@order.stressinduktion.org>
	<508E5D5C02000078000A5028@nat28.tlf.novell.com>
	<20121029124552.GB18860@order.stressinduktion.org>
In-Reply-To: <20121029124552.GB18860@order.stressinduktion.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, xen-devel 
Subject: Re: [Xen-devel] [PATCH] dbgp: fix compile error on building
 EARLY_PRINTK_DBGP without USB_SUPPORT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 29.10.12 at 13:45, Hannes Frederic Sowa  wrote:
> On Mon, Oct 29, 2012 at 09:41:32AM +0000, Jan Beulich wrote:
>> >>> On 28.10.12 at 18:44, Hannes Frederic Sowa  
> wrote:
>> > This patch fixes following compile error:
>> > 
>> > drivers/built-in.o: In function `dbgp_reset_prep':
>> > linux/drivers/usb/early/ehci-dbgp.c:984: undefined reference to 
>> > `xen_dbgp_reset_prep'
>> > drivers/built-in.o: In function `dbgp_external_startup':
>> > linux/drivers/usb/early/ehci-dbgp.c:619: undefined reference to 
>> > `xen_dbgp_external_startup'
>> > 
>> > EARLY_PRINTK_DBGP should work without USB_SUPPORT.
>> 
>> An alternative patch was previously suggested to address this
>> build problem.
> 
> Hm, ok. I searched for a patch in the archives but did not find one. Do you
> have a link?

Looks like I forgot to Cc any of the possibly relevant lists. But the
patch is being debated upon still anyway.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 13:00:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 13:00:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSowf-0002PG-4f; Mon, 29 Oct 2012 12:59:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSowd-0002P9-NM
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 12:59:55 +0000
Received: from [85.158.143.99:30163] by server-1.bemta-4.messagelabs.com id
	DC/9C-19134-ACD7E805; Mon, 29 Oct 2012 12:59:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1351515594!24412139!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2047 invoked from network); 29 Oct 2012 12:59:54 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-216.messagelabs.com with SMTP;
	29 Oct 2012 12:59:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 29 Oct 2012 12:59:53 +0000
Message-Id: <508E8C0102000078000A5234@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 29 Oct 2012 13:00:33 +0000
From: "Jan Beulich" 
To: "Hannes Frederic Sowa" 
References: <20121028174441.GA30893@order.stressinduktion.org>
	<508E5D5C02000078000A5028@nat28.tlf.novell.com>
	<20121029124552.GB18860@order.stressinduktion.org>
In-Reply-To: <20121029124552.GB18860@order.stressinduktion.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, xen-devel 
Subject: Re: [Xen-devel] [PATCH] dbgp: fix compile error on building
 EARLY_PRINTK_DBGP without USB_SUPPORT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 29.10.12 at 13:45, Hannes Frederic Sowa  wrote:
> On Mon, Oct 29, 2012 at 09:41:32AM +0000, Jan Beulich wrote:
>> >>> On 28.10.12 at 18:44, Hannes Frederic Sowa  
> wrote:
>> > This patch fixes following compile error:
>> > 
>> > drivers/built-in.o: In function `dbgp_reset_prep':
>> > linux/drivers/usb/early/ehci-dbgp.c:984: undefined reference to 
>> > `xen_dbgp_reset_prep'
>> > drivers/built-in.o: In function `dbgp_external_startup':
>> > linux/drivers/usb/early/ehci-dbgp.c:619: undefined reference to 
>> > `xen_dbgp_external_startup'
>> > 
>> > EARLY_PRINTK_DBGP should work without USB_SUPPORT.
>> 
>> An alternative patch was previously suggested to address this
>> build problem.
> 
> Hm, ok. I searched for a patch in the archives but did not find one. Do you
> have a link?

Looks like I forgot to Cc any of the possibly relevant lists. But the
patch is being debated upon still anyway.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 13:00:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 13:00:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSowh-0002Pk-ME; Mon, 29 Oct 2012 12:59:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSowg-0002PX-L7
	for xen-devel@lists.xensource.com; Mon, 29 Oct 2012 12:59:58 +0000
Received: from [193.109.254.147:45335] by server-10.bemta-14.messagelabs.com
	id D3/AB-31741-DCD7E805; Mon, 29 Oct 2012 12:59:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1351515594!8843882!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6417 invoked from network); 29 Oct 2012 12:59:57 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-27.messagelabs.com with SMTP;
	29 Oct 2012 12:59:57 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 29 Oct 2012 12:59:53 +0000
Message-Id: <508E8C0102000078000A5234@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 29 Oct 2012 13:00:33 +0000
From: "Jan Beulich" 
To: "Hannes Frederic Sowa" 
References: <20121028174441.GA30893@order.stressinduktion.org>
	<508E5D5C02000078000A5028@nat28.tlf.novell.com>
	<20121029124552.GB18860@order.stressinduktion.org>
In-Reply-To: <20121029124552.GB18860@order.stressinduktion.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, xen-devel 
Subject: Re: [Xen-devel] [PATCH] dbgp: fix compile error on building
 EARLY_PRINTK_DBGP without USB_SUPPORT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 29.10.12 at 13:45, Hannes Frederic Sowa  wrote:
> On Mon, Oct 29, 2012 at 09:41:32AM +0000, Jan Beulich wrote:
>> >>> On 28.10.12 at 18:44, Hannes Frederic Sowa  
> wrote:
>> > This patch fixes following compile error:
>> > 
>> > drivers/built-in.o: In function `dbgp_reset_prep':
>> > linux/drivers/usb/early/ehci-dbgp.c:984: undefined reference to 
>> > `xen_dbgp_reset_prep'
>> > drivers/built-in.o: In function `dbgp_external_startup':
>> > linux/drivers/usb/early/ehci-dbgp.c:619: undefined reference to 
>> > `xen_dbgp_external_startup'
>> > 
>> > EARLY_PRINTK_DBGP should work without USB_SUPPORT.
>> 
>> An alternative patch was previously suggested to address this
>> build problem.
> 
> Hm, ok. I searched for a patch in the archives but did not find one. Do you
> have a link?

Looks like I forgot to Cc any of the possibly relevant lists. But the
patch is being debated upon still anyway.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 13:00:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 13:00:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSowh-0002Pk-ME; Mon, 29 Oct 2012 12:59:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSowg-0002PX-L7
	for xen-devel@lists.xensource.com; Mon, 29 Oct 2012 12:59:58 +0000
Received: from [193.109.254.147:45335] by server-10.bemta-14.messagelabs.com
	id D3/AB-31741-DCD7E805; Mon, 29 Oct 2012 12:59:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1351515594!8843882!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6417 invoked from network); 29 Oct 2012 12:59:57 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-27.messagelabs.com with SMTP;
	29 Oct 2012 12:59:57 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 29 Oct 2012 12:59:53 +0000
Message-Id: <508E8C0102000078000A5234@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 29 Oct 2012 13:00:33 +0000
From: "Jan Beulich" 
To: "Hannes Frederic Sowa" 
References: <20121028174441.GA30893@order.stressinduktion.org>
	<508E5D5C02000078000A5028@nat28.tlf.novell.com>
	<20121029124552.GB18860@order.stressinduktion.org>
In-Reply-To: <20121029124552.GB18860@order.stressinduktion.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, xen-devel 
Subject: Re: [Xen-devel] [PATCH] dbgp: fix compile error on building
 EARLY_PRINTK_DBGP without USB_SUPPORT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 29.10.12 at 13:45, Hannes Frederic Sowa  wrote:
> On Mon, Oct 29, 2012 at 09:41:32AM +0000, Jan Beulich wrote:
>> >>> On 28.10.12 at 18:44, Hannes Frederic Sowa  
> wrote:
>> > This patch fixes following compile error:
>> > 
>> > drivers/built-in.o: In function `dbgp_reset_prep':
>> > linux/drivers/usb/early/ehci-dbgp.c:984: undefined reference to 
>> > `xen_dbgp_reset_prep'
>> > drivers/built-in.o: In function `dbgp_external_startup':
>> > linux/drivers/usb/early/ehci-dbgp.c:619: undefined reference to 
>> > `xen_dbgp_external_startup'
>> > 
>> > EARLY_PRINTK_DBGP should work without USB_SUPPORT.
>> 
>> An alternative patch was previously suggested to address this
>> build problem.
> 
> Hm, ok. I searched for a patch in the archives but did not find one. Do you
> have a link?

Looks like I forgot to Cc any of the possibly relevant lists. But the
patch is being debated upon still anyway.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 13:35:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 13:35:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSpUR-0002s9-Iy; Mon, 29 Oct 2012 13:34:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSpUQ-0002s4-4j
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 13:34:50 +0000
Received: from [85.158.138.51:20679] by server-12.bemta-3.messagelabs.com id
	17/73-27853-9F58E805; Mon, 29 Oct 2012 13:34:49 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1351517687!27749012!1
X-Originating-IP: [216.32.180.11]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7072 invoked from network); 29 Oct 2012 13:34:48 -0000
Received: from va3ehsobe001.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.11)
	by server-16.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	29 Oct 2012 13:34:48 -0000
Received: from mail94-va3-R.bigfish.com (10.7.14.248) by
	VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id
	14.1.225.23; Mon, 29 Oct 2012 13:34:46 +0000
Received: from mail94-va3 (localhost [127.0.0.1])	by mail94-va3-R.bigfish.com
	(Postfix) with ESMTP id 8676020092;
	Mon, 29 Oct 2012 13:34:46 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: -3
X-BigFish: VPS-3(zzbb2dI98dI1432Izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h)
Received: from mail94-va3 (localhost.localdomain [127.0.0.1]) by mail94-va3
	(MessageSwitch) id 1351517685810044_16533;
	Mon, 29 Oct 2012 13:34:45 +0000 (UTC)
Received: from VA3EHSMHS010.bigfish.com (unknown [10.7.14.243])	by
	mail94-va3.bigfish.com (Postfix) with ESMTP id AFF26300054;
	Mon, 29 Oct 2012 13:34:45 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS010.bigfish.com (10.7.99.20) with Microsoft SMTP Server id
	14.1.225.23; Mon, 29 Oct 2012 13:34:45 +0000
X-WSS-ID: 0MCNPPU-01-8T7-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2F4DD1028311;	Mon, 29 Oct 2012 08:34:41 -0500 (CDT)
Received: from SAUSEXDAG06.amd.com (163.181.55.7) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Mon, 29 Oct 2012 08:34:47 -0500
Received: from STOREXDAG03.amd.com (10.1.13.12) by sausexdag06.amd.com
	(163.181.55.7) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Mon, 29 Oct 2012 08:34:41 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag03.amd.com
	(10.1.13.12) with Microsoft SMTP Server id 14.2.318.4; Mon, 29 Oct 2012
	09:34:40 -0400
Message-ID: <508E85EF.9060908@amd.com>
Date: Mon, 29 Oct 2012 14:34:39 +0100
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich 
References: <508A490B.4050407@amd.com> <508A4935.6090801@amd.com>
	<508E5EF702000078000A5039@nat28.tlf.novell.com>
	<508E5463.1040100@amd.com>
	<508E670802000078000A5150@nat28.tlf.novell.com>
	<508E5B3C.6030801@amd.com>
	<508E6D2E02000078000A51AD@nat28.tlf.novell.com>
In-Reply-To: <508E6D2E02000078000A51AD@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] MCE: consolidate AMD initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/29/12 11:49, Jan Beulich wrote:
>>>> On 29.10.12 at 11:32, Christoph Egger  wrote:
>> On 10/29/12 11:22, Jan Beulich wrote:
>>>>>> On 29.10.12 at 11:03, Christoph Egger  wrote:
>>>> On 10/29/12 10:48, Jan Beulich wrote:
>>>>>>>> On 26.10.12 at 10:26, Christoph Egger  wrote:
>>>>>> On 10/26/12 10:25, Christoph Egger wrote:
>>>>>>>
>>>>>>> Move AMD specific initialization to AMD files.
>>>>>>>
>>>>>>> Signed-off-by: Christoph Egger 
>>>>>
>>>>> Let's do this properly: There's no K7 supporting 64-bit mode afaict,
>>>>> so rather than moving around the call to amd_k7_mcheck_init()
>>>>> can't we just drop it and the whole (inconsistently named) k7.c file?
>>>>
>>>> I think it is better to apply this first and then remove k7 to
>>>> simplify backporting if needed/wanted.
>>>
>>> I'm not seeing these changes as backporting candidates.
>>
>> I had SLES in mind.
>>
>>>>> Also (not in this patch of course), I'd prefer mce_amd_quirks.c
>>>>> to get merged into mce_amd.c now that we have the latter.
>>>>
>>>> After some thinking is there some good reason to do this?
>>>
>>> Imo it had been there simply because there was no mce_amd.c at
>>> the time it got introduced (and afaics it should nevertheless have
>>> been named mce_amd.c from the beginning).
>>
>> I have a patch ready that removes k7 support which is on top of this
>> init cleanup patch.
>> I also have a patch which merges mce_amd_quirks into mce_amd.c on
>> top of the k7 removal.
>> In which order do you want them?
> 
> Okay, if you got them done already, let's go with the order you
> have.

Patches sent.

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 13:35:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 13:35:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSpUR-0002s9-Iy; Mon, 29 Oct 2012 13:34:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSpUQ-0002s4-4j
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 13:34:50 +0000
Received: from [85.158.138.51:20679] by server-12.bemta-3.messagelabs.com id
	17/73-27853-9F58E805; Mon, 29 Oct 2012 13:34:49 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1351517687!27749012!1
X-Originating-IP: [216.32.180.11]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7072 invoked from network); 29 Oct 2012 13:34:48 -0000
Received: from va3ehsobe001.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.11)
	by server-16.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	29 Oct 2012 13:34:48 -0000
Received: from mail94-va3-R.bigfish.com (10.7.14.248) by
	VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id
	14.1.225.23; Mon, 29 Oct 2012 13:34:46 +0000
Received: from mail94-va3 (localhost [127.0.0.1])	by mail94-va3-R.bigfish.com
	(Postfix) with ESMTP id 8676020092;
	Mon, 29 Oct 2012 13:34:46 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-SpamScore: -3
X-BigFish: VPS-3(zzbb2dI98dI1432Izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h)
Received: from mail94-va3 (localhost.localdomain [127.0.0.1]) by mail94-va3
	(MessageSwitch) id 1351517685810044_16533;
	Mon, 29 Oct 2012 13:34:45 +0000 (UTC)
Received: from VA3EHSMHS010.bigfish.com (unknown [10.7.14.243])	by
	mail94-va3.bigfish.com (Postfix) with ESMTP id AFF26300054;
	Mon, 29 Oct 2012 13:34:45 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS010.bigfish.com (10.7.99.20) with Microsoft SMTP Server id
	14.1.225.23; Mon, 29 Oct 2012 13:34:45 +0000
X-WSS-ID: 0MCNPPU-01-8T7-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2F4DD1028311;	Mon, 29 Oct 2012 08:34:41 -0500 (CDT)
Received: from SAUSEXDAG06.amd.com (163.181.55.7) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Mon, 29 Oct 2012 08:34:47 -0500
Received: from STOREXDAG03.amd.com (10.1.13.12) by sausexdag06.amd.com
	(163.181.55.7) with Microsoft SMTP Server (TLS) id 14.2.318.4;
	Mon, 29 Oct 2012 08:34:41 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexdag03.amd.com
	(10.1.13.12) with Microsoft SMTP Server id 14.2.318.4; Mon, 29 Oct 2012
	09:34:40 -0400
Message-ID: <508E85EF.9060908@amd.com>
Date: Mon, 29 Oct 2012 14:34:39 +0100
From: Christoph Egger 
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:15.0) Gecko/20121009 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich 
References: <508A490B.4050407@amd.com> <508A4935.6090801@amd.com>
	<508E5EF702000078000A5039@nat28.tlf.novell.com>
	<508E5463.1040100@amd.com>
	<508E670802000078000A5150@nat28.tlf.novell.com>
	<508E5B3C.6030801@amd.com>
	<508E6D2E02000078000A51AD@nat28.tlf.novell.com>
In-Reply-To: <508E6D2E02000078000A51AD@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] MCE: consolidate AMD initialization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/29/12 11:49, Jan Beulich wrote:
>>>> On 29.10.12 at 11:32, Christoph Egger  wrote:
>> On 10/29/12 11:22, Jan Beulich wrote:
>>>>>> On 29.10.12 at 11:03, Christoph Egger  wrote:
>>>> On 10/29/12 10:48, Jan Beulich wrote:
>>>>>>>> On 26.10.12 at 10:26, Christoph Egger  wrote:
>>>>>> On 10/26/12 10:25, Christoph Egger wrote:
>>>>>>>
>>>>>>> Move AMD specific initialization to AMD files.
>>>>>>>
>>>>>>> Signed-off-by: Christoph Egger 
>>>>>
>>>>> Let's do this properly: There's no K7 supporting 64-bit mode afaict,
>>>>> so rather than moving around the call to amd_k7_mcheck_init()
>>>>> can't we just drop it and the whole (inconsistently named) k7.c file?
>>>>
>>>> I think it is better to apply this first and then remove k7 to
>>>> simplify backporting if needed/wanted.
>>>
>>> I'm not seeing these changes as backporting candidates.
>>
>> I had SLES in mind.
>>
>>>>> Also (not in this patch of course), I'd prefer mce_amd_quirks.c
>>>>> to get merged into mce_amd.c now that we have the latter.
>>>>
>>>> After some thinking is there some good reason to do this?
>>>
>>> Imo it had been there simply because there was no mce_amd.c at
>>> the time it got introduced (and afaics it should nevertheless have
>>> been named mce_amd.c from the beginning).
>>
>> I have a patch ready that removes k7 support which is on top of this
>> init cleanup patch.
>> I also have a patch which merges mce_amd_quirks into mce_amd.c on
>> top of the k7 removal.
>> In which order do you want them?
> 
> Okay, if you got them done already, let's go with the order you
> have.

Patches sent.

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 14:00:07 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 14:00:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSpsP-00035F-QK; Mon, 29 Oct 2012 13:59:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSpsN-00035A-UY
	for xen-devel@lists.xensource.com; Mon, 29 Oct 2012 13:59:36 +0000
Received: from [85.158.139.211:14896] by server-4.bemta-5.messagelabs.com id
	10/55-01455-7CB8E805; Mon, 29 Oct 2012 13:59:35 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1351519173!18039527!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNDQxNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31959 invoked from network); 29 Oct 2012 13:59:34 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Oct 2012 13:59:34 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9TDxPPm009581
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 29 Oct 2012 13:59:26 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9TDxOke025779
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 29 Oct 2012 13:59:24 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9TDxODC012883; Mon, 29 Oct 2012 08:59:24 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 29 Oct 2012 06:59:23 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 8F5934042D; Mon, 29 Oct 2012 09:46:57 -0400 (EDT)
Date: Mon, 29 Oct 2012 09:46:57 -0400
From: Konrad Rzeszutek Wilk 
To: Ian Campbell 
Message-ID: <20121029134657.GV2708@phenom.dumpdata.com>
References: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
	<1351015931-16991-2-git-send-email-konrad.wilk@oracle.com>
	<1351071465.2237.128.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1351071465.2237.128.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 01/10] xen/pvh: Support ParaVirtualized
 Hardware extensions.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 24, 2012 at 10:37:45AM +0100, Ian Campbell wrote:
> On Tue, 2012-10-23 at 19:12 +0100, Konrad Rzeszutek Wilk wrote:
> > diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
> > index 1844d31..83050d3 100644
> > --- a/include/xen/interface/physdev.h
> > +++ b/include/xen/interface/physdev.h
> > @@ -274,6 +274,16 @@ struct physdev_dbgp_op {
> >      } u;
> >  };
> >  
> > +#define PHYSDEVOP_map_iomem        30
> > +struct physdev_map_iomem {
> > +    /* IN */
> > +    uint64_t first_gfn;
> > +    uint64_t first_mfn;
> > +    uint32_t nr_mfns;
> > +    uint32_t add_mapping; /* 1 == add mapping;  0 == unmap */
> 
> I think we would usually have map and unmap as separate ops.

Or an #define as a flag? Say:

#define PHYSDEV_MAP_IOMEM_ADD		(1<<1)
#define PHYSDEV_MAP_IOMEM_REMOVE	(1<<0)

which means that '0' is of course an invalid value and
alter the 'add_mapping' to a 'flag' value, as so:

struct physdev_map_iomem {
    /* IN */
    uint64_t first_gfn;
    uint64_t first_mfn;
    uint32_t nr_mfns;
    uint32_t flag;
}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 14:00:07 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 14:00:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSpsP-00035F-QK; Mon, 29 Oct 2012 13:59:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSpsN-00035A-UY
	for xen-devel@lists.xensource.com; Mon, 29 Oct 2012 13:59:36 +0000
Received: from [85.158.139.211:14896] by server-4.bemta-5.messagelabs.com id
	10/55-01455-7CB8E805; Mon, 29 Oct 2012 13:59:35 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1351519173!18039527!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNDQxNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31959 invoked from network); 29 Oct 2012 13:59:34 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Oct 2012 13:59:34 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9TDxPPm009581
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 29 Oct 2012 13:59:26 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9TDxOke025779
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 29 Oct 2012 13:59:24 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9TDxODC012883; Mon, 29 Oct 2012 08:59:24 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 29 Oct 2012 06:59:23 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 8F5934042D; Mon, 29 Oct 2012 09:46:57 -0400 (EDT)
Date: Mon, 29 Oct 2012 09:46:57 -0400
From: Konrad Rzeszutek Wilk 
To: Ian Campbell 
Message-ID: <20121029134657.GV2708@phenom.dumpdata.com>
References: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
	<1351015931-16991-2-git-send-email-konrad.wilk@oracle.com>
	<1351071465.2237.128.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1351071465.2237.128.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 01/10] xen/pvh: Support ParaVirtualized
 Hardware extensions.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 24, 2012 at 10:37:45AM +0100, Ian Campbell wrote:
> On Tue, 2012-10-23 at 19:12 +0100, Konrad Rzeszutek Wilk wrote:
> > diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
> > index 1844d31..83050d3 100644
> > --- a/include/xen/interface/physdev.h
> > +++ b/include/xen/interface/physdev.h
> > @@ -274,6 +274,16 @@ struct physdev_dbgp_op {
> >      } u;
> >  };
> >  
> > +#define PHYSDEVOP_map_iomem        30
> > +struct physdev_map_iomem {
> > +    /* IN */
> > +    uint64_t first_gfn;
> > +    uint64_t first_mfn;
> > +    uint32_t nr_mfns;
> > +    uint32_t add_mapping; /* 1 == add mapping;  0 == unmap */
> 
> I think we would usually have map and unmap as separate ops.

Or an #define as a flag? Say:

#define PHYSDEV_MAP_IOMEM_ADD		(1<<1)
#define PHYSDEV_MAP_IOMEM_REMOVE	(1<<0)

which means that '0' is of course an invalid value and
alter the 'add_mapping' to a 'flag' value, as so:

struct physdev_map_iomem {
    /* IN */
    uint64_t first_gfn;
    uint64_t first_mfn;
    uint32_t nr_mfns;
    uint32_t flag;
}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 14:03:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 14:03:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSpwE-0003Gl-F0; Mon, 29 Oct 2012 14:03:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSpwC-0003GY-4n
	for xen-devel@lists.xensource.com; Mon, 29 Oct 2012 14:03:32 +0000
Received: from [85.158.143.35:28380] by server-1.bemta-4.messagelabs.com id
	09/0D-19134-3BC8E805; Mon, 29 Oct 2012 14:03:31 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1351519382!12974642!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21324 invoked from network); 29 Oct 2012 14:03:04 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Oct 2012 14:03:04 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9TE2rG7012506
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 29 Oct 2012 14:02:54 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9TE2qvO023089
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 29 Oct 2012 14:02:53 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9TE2qSS018574; Mon, 29 Oct 2012 09:02:52 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 29 Oct 2012 07:02:52 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1999A4042D; Mon, 29 Oct 2012 09:50:26 -0400 (EDT)
Date: Mon, 29 Oct 2012 09:50:26 -0400
From: Konrad Rzeszutek Wilk 
To: Ian Campbell 
Message-ID: <20121029135025.GW2708@phenom.dumpdata.com>
References: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
	<1351015931-16991-4-git-send-email-konrad.wilk@oracle.com>
	<1351071622.2237.130.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1351071622.2237.130.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 03/10] xen/hypercall: Make
 xen_remove_from_physmap the same on 64/32 builds.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 24, 2012 at 10:40:22AM +0100, Ian Campbell wrote:
> On Tue, 2012-10-23 at 19:12 +0100, Konrad Rzeszutek Wilk wrote:
> > By making the structure exactly the same size and with the same
> > offsets on 64 and 32-bit builds we are future-proofing ourselves.
> > 
> > Signed-off-by: Konrad Rzeszutek Wilk 
> > ---
> >  include/xen/interface/memory.h |    7 ++++++-
> >  1 files changed, 6 insertions(+), 1 deletions(-)
> > 
> > diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
> > index 8beebdb..6b07b54 100644
> > --- a/include/xen/interface/memory.h
> > +++ b/include/xen/interface/memory.h
> > @@ -253,9 +253,14 @@ extern spinlock_t xen_reservation_lock;
> >  struct xen_remove_from_physmap {
> >      /* Which domain to change the mapping for. */
> >      domid_t domid;
> > -
> > +   /* To be used in the future if need to. */
> > +    uint8_t reserved[6];
> >      /* GPFN of the current mapping of the page. */
> >      xen_pfn_t gpfn;
> > +#ifdef CONFIG_X86_32
> > +    /* No need to do that on ARM as xen_pfn_t is always 8 bytes. */
> > +    uint8_t __pad[4];
> > +#endif
> 
> I'm not sure if this last one is necessary since this isn't a struct
> which would get used in an array. I guess it doesn't hurt though.

OK, we can always remove it later on?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 14:03:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 14:03:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSpwE-0003Gl-F0; Mon, 29 Oct 2012 14:03:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSpwC-0003GY-4n
	for xen-devel@lists.xensource.com; Mon, 29 Oct 2012 14:03:32 +0000
Received: from [85.158.143.35:28380] by server-1.bemta-4.messagelabs.com id
	09/0D-19134-3BC8E805; Mon, 29 Oct 2012 14:03:31 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1351519382!12974642!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21324 invoked from network); 29 Oct 2012 14:03:04 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Oct 2012 14:03:04 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9TE2rG7012506
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 29 Oct 2012 14:02:54 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9TE2qvO023089
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 29 Oct 2012 14:02:53 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9TE2qSS018574; Mon, 29 Oct 2012 09:02:52 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 29 Oct 2012 07:02:52 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1999A4042D; Mon, 29 Oct 2012 09:50:26 -0400 (EDT)
Date: Mon, 29 Oct 2012 09:50:26 -0400
From: Konrad Rzeszutek Wilk 
To: Ian Campbell 
Message-ID: <20121029135025.GW2708@phenom.dumpdata.com>
References: <1351015931-16991-1-git-send-email-konrad.wilk@oracle.com>
	<1351015931-16991-4-git-send-email-konrad.wilk@oracle.com>
	<1351071622.2237.130.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1351071622.2237.130.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 03/10] xen/hypercall: Make
 xen_remove_from_physmap the same on 64/32 builds.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 24, 2012 at 10:40:22AM +0100, Ian Campbell wrote:
> On Tue, 2012-10-23 at 19:12 +0100, Konrad Rzeszutek Wilk wrote:
> > By making the structure exactly the same size and with the same
> > offsets on 64 and 32-bit builds we are future-proofing ourselves.
> > 
> > Signed-off-by: Konrad Rzeszutek Wilk 
> > ---
> >  include/xen/interface/memory.h |    7 ++++++-
> >  1 files changed, 6 insertions(+), 1 deletions(-)
> > 
> > diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
> > index 8beebdb..6b07b54 100644
> > --- a/include/xen/interface/memory.h
> > +++ b/include/xen/interface/memory.h
> > @@ -253,9 +253,14 @@ extern spinlock_t xen_reservation_lock;
> >  struct xen_remove_from_physmap {
> >      /* Which domain to change the mapping for. */
> >      domid_t domid;
> > -
> > +   /* To be used in the future if need to. */
> > +    uint8_t reserved[6];
> >      /* GPFN of the current mapping of the page. */
> >      xen_pfn_t gpfn;
> > +#ifdef CONFIG_X86_32
> > +    /* No need to do that on ARM as xen_pfn_t is always 8 bytes. */
> > +    uint8_t __pad[4];
> > +#endif
> 
> I'm not sure if this last one is necessary since this isn't a struct
> which would get used in an array. I guess it doesn't hurt though.

OK, we can always remove it later on?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 14:10:33 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 14:10:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSq2b-0003Rl-AH; Mon, 29 Oct 2012 14:10:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSq2Z-0003Rg-Ew
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 14:10:07 +0000
Received: from [85.158.138.51:50535] by server-6.bemta-3.messagelabs.com id
	B2/55-32375-E3E8E805; Mon, 29 Oct 2012 14:10:06 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1351519803!21499653!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODI4MTEw\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20975 invoked from network); 29 Oct 2012 14:10:05 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Oct 2012 14:10:05 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9TEA0CM009571
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 29 Oct 2012 14:10:01 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9TEA0r0019101
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 29 Oct 2012 14:10:00 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9TEA0lP024043; Mon, 29 Oct 2012 09:10:00 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 29 Oct 2012 07:09:59 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 751014042D; Mon, 29 Oct 2012 09:57:33 -0400 (EDT)
Date: Mon, 29 Oct 2012 09:57:33 -0400
From: Konrad Rzeszutek Wilk 
To: Roger Pau Monne 
Message-ID: <20121029135733.GZ2708@phenom.dumpdata.com>
References: <1351097925-26221-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1351097925-26221-1-git-send-email-roger.pau@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Oliver Chick , linux-kernel@vger.kernel.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 24, 2012 at 06:58:45PM +0200, Roger Pau Monne wrote:
> This patch implements persistent grants for the xen-blk{front,back}
> mechanism. The effect of this change is to reduce the number of unmap
> operations performed, since they cause a (costly) TLB shootdown. This
> allows the I/O performance to scale better when a large number of VMs
> are performing I/O.
> 
> Previously, the blkfront driver was supplied a bvec[] from the request
> queue. This was granted to dom0; dom0 performed the I/O and wrote
> directly into the grant-mapped memory and unmapped it; blkfront then
> removed foreign access for that grant. The cost of unmapping scales
> badly with the number of CPUs in Dom0. An experiment showed that when
> Dom0 has 24 VCPUs, and guests are performing parallel I/O to a
> ramdisk, the IPIs from performing unmap's is a bottleneck at 5 guests
> (at which point 650,000 IOPS are being performed in total). If more
> than 5 guests are used, the performance declines. By 10 guests, only
> 400,000 IOPS are being performed.
> 
> This patch improves performance by only unmapping when the connection
> between blkfront and back is broken.
> 
> On startup blkfront notifies blkback that it is using persistent
> grants, and blkback will do the same. If blkback is not capable of
> persistent mapping, blkfront will still use the same grants, since it
> is compatible with the previous protocol, and simplifies the code
> complexity in blkfront.
> 
> To perform a read, in persistent mode, blkfront uses a separate pool
> of pages that it maps to dom0. When a request comes in, blkfront
> transmutes the request so that blkback will write into one of these
> free pages. Blkback keeps note of which grefs it has already
> mapped. When a new ring request comes to blkback, it looks to see if
> it has already mapped that page. If so, it will not map it again. If
> the page hasn't been previously mapped, it is mapped now, and a record
> is kept of this mapping. Blkback proceeds as usual. When blkfront is
> notified that blkback has completed a request, it memcpy's from the
> shared memory, into the bvec supplied. A record that the {gref, page}
> tuple is mapped, and not inflight is kept.
> 
> Writes are similar, except that the memcpy is peformed from the
> supplied bvecs, into the shared pages, before the request is put onto
> the ring.
> 
> Blkback stores a mapping of grefs=>{page mapped to by gref} in
> a red-black tree. As the grefs are not known apriori, and provide no
> guarantees on their ordering, we have to perform a search
> through this tree to find the page, for every gref we receive. This
> operation takes O(log n) time in the worst case. In blkfront grants
> are stored using a single linked list.
> 
> The maximum number of grants that blkback will persistenly map is
> currently set to RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, to
> prevent a malicios guest from attempting a DoS, by supplying fresh
> grefs, causing the Dom0 kernel to map excessively. If a guest
> is using persistent grants and exceeds the maximum number of grants to
> map persistenly the newly passed grefs will be mapped and unmaped.
> Using this approach, we can have requests that mix persistent and
> non-persistent grants, and we need to handle them correctly.
> This allows us to set the maximum number of persistent grants to a
> lower value than RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, although
> setting it will lead to unpredictable performance.
> 
> In writing this patch, the question arrises as to if the additional
> cost of performing memcpys in the guest (to/from the pool of granted
> pages) outweigh the gains of not performing TLB shootdowns. The answer
> to that question is `no'. There appears to be very little, if any
> additional cost to the guest of using persistent grants. There is
> perhaps a small saving, from the reduced number of hypercalls
> performed in granting, and ending foreign access.
> 
> Signed-off-by: Oliver Chick 
> Signed-off-by: Roger Pau Monne 
> Cc: 
> Cc: 
> ---
> Changes since v1:
>  * Changed the unmap_seg array to a bitmap.
>  * Only report using persistent grants in blkfront if blkback supports
>    it.
>  * Reword some comments.
>  * Fix a bug when setting the handler, index j was not incremented
>    correctly.
>  * Check that the tree of grants in blkback is not empty before
>    iterating over it when doing the cleanup.
>  * Rebase on top of linux-net.


It looks good to me. Going to stick it on my for-jens-3.8 branch.

> ---
> Benchmarks showing the impact of this patch in blk performance can be
> found at:
> 
> http://xenbits.xensource.com/people/royger/persistent_grants/
> ---
>  drivers/block/xen-blkback/blkback.c |  292 ++++++++++++++++++++++++++++++++---
>  drivers/block/xen-blkback/common.h  |   17 ++
>  drivers/block/xen-blkback/xenbus.c  |   23 +++-
>  drivers/block/xen-blkfront.c        |  197 ++++++++++++++++++++----
>  4 files changed, 474 insertions(+), 55 deletions(-)
> 
> diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
> index 280a138..663d42d 100644
> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -39,6 +39,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -79,6 +80,7 @@ struct pending_req {
>  	unsigned short		operation;
>  	int			status;
>  	struct list_head	free_list;
> +	DECLARE_BITMAP(unmap_seg, BLKIF_MAX_SEGMENTS_PER_REQUEST);
>  };
>  
>  #define BLKBACK_INVALID_HANDLE (~0)
> @@ -99,6 +101,36 @@ struct xen_blkbk {
>  static struct xen_blkbk *blkbk;
>  
>  /*
> + * Maximum number of grant pages that can be mapped in blkback.
> + * BLKIF_MAX_SEGMENTS_PER_REQUEST * RING_SIZE is the maximum number of
> + * pages that blkback will persistently map.
> + * Currently, this is:
> + * RING_SIZE = 32 (for all known ring types)
> + * BLKIF_MAX_SEGMENTS_PER_REQUEST = 11
> + * sizeof(struct persistent_gnt) = 48
> + * So the maximum memory used to store the grants is:
> + * 32 * 11 * 48 = 16896 bytes
> + */
> +static inline unsigned int max_mapped_grant_pages(enum blkif_protocol protocol)
> +{
> +	switch (protocol) {
> +	case BLKIF_PROTOCOL_NATIVE:
> +		return __CONST_RING_SIZE(blkif, PAGE_SIZE) *
> +			   BLKIF_MAX_SEGMENTS_PER_REQUEST;
> +	case BLKIF_PROTOCOL_X86_32:
> +		return __CONST_RING_SIZE(blkif_x86_32, PAGE_SIZE) *
> +			   BLKIF_MAX_SEGMENTS_PER_REQUEST;
> +	case BLKIF_PROTOCOL_X86_64:
> +		return __CONST_RING_SIZE(blkif_x86_64, PAGE_SIZE) *
> +			   BLKIF_MAX_SEGMENTS_PER_REQUEST;
> +	default:
> +		BUG();
> +	}
> +	return 0;
> +}
> +
> +
> +/*
>   * Little helpful macro to figure out the index and virtual address of the
>   * pending_pages[..]. For each 'pending_req' we have have up to
>   * BLKIF_MAX_SEGMENTS_PER_REQUEST (11) pages. The seg would be from 0 through
> @@ -129,6 +161,57 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>  static void make_response(struct xen_blkif *blkif, u64 id,
>  			  unsigned short op, int st);
>  
> +#define foreach_grant(pos, rbtree, node) \
> +	for ((pos) = container_of(rb_first((rbtree)), typeof(*(pos)), node); \
> +	     &(pos)->node != NULL; \
> +	     (pos) = container_of(rb_next(&(pos)->node), typeof(*(pos)), node))
> +
> +
> +static void add_persistent_gnt(struct rb_root *root,
> +			       struct persistent_gnt *persistent_gnt)
> +{
> +	struct rb_node **new = &(root->rb_node), *parent = NULL;
> +	struct persistent_gnt *this;
> +
> +	/* Figure out where to put new node */
> +	while (*new) {
> +		this = container_of(*new, struct persistent_gnt, node);
> +
> +		parent = *new;
> +		if (persistent_gnt->gnt < this->gnt)
> +			new = &((*new)->rb_left);
> +		else if (persistent_gnt->gnt > this->gnt)
> +			new = &((*new)->rb_right);
> +		else {
> +			pr_alert(DRV_PFX " trying to add a gref that's already in the tree\n");
> +			BUG();
> +		}
> +	}
> +
> +	/* Add new node and rebalance tree. */
> +	rb_link_node(&(persistent_gnt->node), parent, new);
> +	rb_insert_color(&(persistent_gnt->node), root);
> +}
> +
> +static struct persistent_gnt *get_persistent_gnt(struct rb_root *root,
> +						 grant_ref_t gref)
> +{
> +	struct persistent_gnt *data;
> +	struct rb_node *node = root->rb_node;
> +
> +	while (node) {
> +		data = container_of(node, struct persistent_gnt, node);
> +
> +		if (gref < data->gnt)
> +			node = node->rb_left;
> +		else if (gref > data->gnt)
> +			node = node->rb_right;
> +		else
> +			return data;
> +	}
> +	return NULL;
> +}
> +
>  /*
>   * Retrieve from the 'pending_reqs' a free pending_req structure to be used.
>   */
> @@ -275,6 +358,11 @@ int xen_blkif_schedule(void *arg)
>  {
>  	struct xen_blkif *blkif = arg;
>  	struct xen_vbd *vbd = &blkif->vbd;
> +	struct gnttab_unmap_grant_ref unmap[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct persistent_gnt *persistent_gnt;
> +	int ret = 0;
> +	int segs_to_unmap = 0;
>  
>  	xen_blkif_get(blkif);
>  
> @@ -302,6 +390,36 @@ int xen_blkif_schedule(void *arg)
>  			print_stats(blkif);
>  	}
>  
> +	/* Free all persistent grant pages */
> +	if (!RB_EMPTY_ROOT(&blkif->persistent_gnts)) {
> +		foreach_grant(persistent_gnt, &blkif->persistent_gnts, node) {
> +			BUG_ON(persistent_gnt->handle ==
> +				BLKBACK_INVALID_HANDLE);
> +			gnttab_set_unmap_op(&unmap[segs_to_unmap],
> +			    (unsigned long) pfn_to_kaddr(page_to_pfn(
> +				persistent_gnt->page)),
> +			    GNTMAP_host_map,
> +			    persistent_gnt->handle);
> +
> +			pages[segs_to_unmap] = persistent_gnt->page;
> +			rb_erase(&persistent_gnt->node,
> +				&blkif->persistent_gnts);
> +			kfree(persistent_gnt);
> +			blkif->persistent_gnt_c--;
> +
> +			if (++segs_to_unmap == BLKIF_MAX_SEGMENTS_PER_REQUEST ||
> +				!rb_next(&persistent_gnt->node)) {
> +				ret = gnttab_unmap_refs(unmap, NULL, pages,
> +							segs_to_unmap);
> +				BUG_ON(ret);
> +				segs_to_unmap = 0;
> +			}
> +		}
> +	}
> +
> +	BUG_ON(blkif->persistent_gnt_c != 0);
> +	BUG_ON(!RB_EMPTY_ROOT(&blkif->persistent_gnts));
> +
>  	if (log_stats)
>  		print_stats(blkif);
>  
> @@ -328,6 +446,8 @@ static void xen_blkbk_unmap(struct pending_req *req)
>  	int ret;
>  
>  	for (i = 0; i < req->nr_pages; i++) {
> +		if (!test_bit(i, req->unmap_seg))
> +			continue;
>  		handle = pending_handle(req, i);
>  		if (handle == BLKBACK_INVALID_HANDLE)
>  			continue;
> @@ -344,12 +464,26 @@ static void xen_blkbk_unmap(struct pending_req *req)
>  
>  static int xen_blkbk_map(struct blkif_request *req,
>  			 struct pending_req *pending_req,
> -			 struct seg_buf seg[])
> +			 struct seg_buf seg[],
> +			 struct page *pages[])
>  {
>  	struct gnttab_map_grant_ref map[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> -	int i;
> +	struct persistent_gnt *persistent_gnts[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct page *pages_to_gnt[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct persistent_gnt *persistent_gnt = NULL;
> +	struct xen_blkif *blkif = pending_req->blkif;
> +	phys_addr_t addr = 0;
> +	int i, j;
> +	bool new_map;
>  	int nseg = req->u.rw.nr_segments;
> +	int segs_to_map = 0;
>  	int ret = 0;
> +	int use_persistent_gnts;
> +
> +	use_persistent_gnts = (blkif->vbd.feature_gnt_persistent);
> +
> +	BUG_ON(blkif->persistent_gnt_c >
> +		   max_mapped_grant_pages(pending_req->blkif->blk_protocol));
>  
>  	/*
>  	 * Fill out preq.nr_sects with proper amount of sectors, and setup
> @@ -359,36 +493,143 @@ static int xen_blkbk_map(struct blkif_request *req,
>  	for (i = 0; i < nseg; i++) {
>  		uint32_t flags;
>  
> -		flags = GNTMAP_host_map;
> -		if (pending_req->operation != BLKIF_OP_READ)
> -			flags |= GNTMAP_readonly;
> -		gnttab_set_map_op(&map[i], vaddr(pending_req, i), flags,
> -				  req->u.rw.seg[i].gref,
> -				  pending_req->blkif->domid);
> +		if (use_persistent_gnts)
> +			persistent_gnt = get_persistent_gnt(
> +				&blkif->persistent_gnts,
> +				req->u.rw.seg[i].gref);
> +
> +		if (persistent_gnt) {
> +			/*
> +			 * We are using persistent grants and
> +			 * the grant is already mapped
> +			 */
> +			new_map = 0;
> +		} else if (use_persistent_gnts &&
> +			   blkif->persistent_gnt_c <
> +			   max_mapped_grant_pages(blkif->blk_protocol)) {
> +			/*
> +			 * We are using persistent grants, the grant is
> +			 * not mapped but we have room for it
> +			 */
> +			new_map = 1;
> +			persistent_gnt = kzalloc(
> +				sizeof(struct persistent_gnt),
> +				GFP_KERNEL);
> +			if (!persistent_gnt)
> +				return -ENOMEM;
> +			persistent_gnt->page = alloc_page(GFP_KERNEL);
> +			if (!persistent_gnt->page) {
> +				kfree(persistent_gnt);
> +				return -ENOMEM;
> +			}
> +			persistent_gnt->gnt = req->u.rw.seg[i].gref;
> +
> +			pages_to_gnt[segs_to_map] =
> +				persistent_gnt->page;
> +			addr = (unsigned long) pfn_to_kaddr(
> +				page_to_pfn(persistent_gnt->page));
> +
> +			add_persistent_gnt(&blkif->persistent_gnts,
> +				persistent_gnt);
> +			blkif->persistent_gnt_c++;
> +			pr_debug(DRV_PFX " grant %u added to the tree of persistent grants, using %u/%u\n",
> +				 persistent_gnt->gnt, blkif->persistent_gnt_c,
> +				 max_mapped_grant_pages(blkif->blk_protocol));
> +		} else {
> +			/*
> +			 * We are either using persistent grants and
> +			 * hit the maximum limit of grants mapped,
> +			 * or we are not using persistent grants.
> +			 */
> +			if (use_persistent_gnts &&
> +				!blkif->vbd.overflow_max_grants) {
> +				blkif->vbd.overflow_max_grants = 1;
> +				pr_alert(DRV_PFX " domain %u, device %#x is using maximum number of persistent grants\n",
> +					 blkif->domid, blkif->vbd.handle);
> +			}
> +			new_map = 1;
> +			pages[i] = blkbk->pending_page(pending_req, i);
> +			addr = vaddr(pending_req, i);
> +			pages_to_gnt[segs_to_map] =
> +				blkbk->pending_page(pending_req, i);
> +		}
> +
> +		if (persistent_gnt) {
> +			pages[i] = persistent_gnt->page;
> +			persistent_gnts[i] = persistent_gnt;
> +		} else {
> +			persistent_gnts[i] = NULL;
> +		}
> +
> +		if (new_map) {
> +			flags = GNTMAP_host_map;
> +			if (!persistent_gnt &&
> +			    (pending_req->operation != BLKIF_OP_READ))
> +				flags |= GNTMAP_readonly;
> +			gnttab_set_map_op(&map[segs_to_map++], addr,
> +					  flags, req->u.rw.seg[i].gref,
> +					  blkif->domid);
> +		}
>  	}
>  
> -	ret = gnttab_map_refs(map, NULL, &blkbk->pending_page(pending_req, 0), nseg);
> -	BUG_ON(ret);
> +	if (segs_to_map) {
> +		ret = gnttab_map_refs(map, NULL, pages_to_gnt, segs_to_map);
> +		BUG_ON(ret);
> +	}
>  
>  	/*
>  	 * Now swizzle the MFN in our domain with the MFN from the other domain
>  	 * so that when we access vaddr(pending_req,i) it has the contents of
>  	 * the page from the other domain.
>  	 */
> -	for (i = 0; i < nseg; i++) {
> -		if (unlikely(map[i].status != 0)) {
> -			pr_debug(DRV_PFX "invalid buffer -- could not remap it\n");
> -			map[i].handle = BLKBACK_INVALID_HANDLE;
> -			ret |= 1;
> +	bitmap_zero(pending_req->unmap_seg, BLKIF_MAX_SEGMENTS_PER_REQUEST);
> +	for (i = 0, j = 0; i < nseg; i++) {
> +		if (!persistent_gnts[i] || !persistent_gnts[i]->handle) {
> +			/* This is a newly mapped grant */
> +			BUG_ON(j >= segs_to_map);
> +			if (unlikely(map[j].status != 0)) {
> +				pr_debug(DRV_PFX "invalid buffer -- could not remap it\n");
> +				map[j].handle = BLKBACK_INVALID_HANDLE;
> +				ret |= 1;
> +				if (persistent_gnts[i]) {
> +					rb_erase(&persistent_gnts[i]->node,
> +						 &blkif->persistent_gnts);
> +					blkif->persistent_gnt_c--;
> +					kfree(persistent_gnts[i]);
> +					persistent_gnts[i] = NULL;
> +				}
> +			}
> +		}
> +		if (persistent_gnts[i]) {
> +			if (!persistent_gnts[i]->handle) {
> +				/*
> +				 * If this is a new persistent grant
> +				 * save the handler
> +				 */
> +				persistent_gnts[i]->handle = map[j].handle;
> +				persistent_gnts[i]->dev_bus_addr =
> +					map[j++].dev_bus_addr;
> +			}
> +			pending_handle(pending_req, i) =
> +				persistent_gnts[i]->handle;
> +
> +			if (ret)
> +				continue;
> +
> +			seg[i].buf = persistent_gnts[i]->dev_bus_addr |
> +				(req->u.rw.seg[i].first_sect << 9);
> +		} else {
> +			pending_handle(pending_req, i) = map[j].handle;
> +			bitmap_set(pending_req->unmap_seg, i, 1);
> +
> +			if (ret) {
> +				j++;
> +				continue;
> +			}
> +
> +			seg[i].buf = map[j++].dev_bus_addr |
> +				(req->u.rw.seg[i].first_sect << 9);
>  		}
> -
> -		pending_handle(pending_req, i) = map[i].handle;
> -
> -		if (ret)
> -			continue;
> -
> -		seg[i].buf  = map[i].dev_bus_addr |
> -			(req->u.rw.seg[i].first_sect << 9);
>  	}
>  	return ret;
>  }
> @@ -591,6 +832,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>  	int operation;
>  	struct blk_plug plug;
>  	bool drain = false;
> +	struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
>  
>  	switch (req->operation) {
>  	case BLKIF_OP_READ:
> @@ -677,7 +919,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>  	 * the hypercall to unmap the grants - that is all done in
>  	 * xen_blkbk_unmap.
>  	 */
> -	if (xen_blkbk_map(req, pending_req, seg))
> +	if (xen_blkbk_map(req, pending_req, seg, pages))
>  		goto fail_flush;
>  
>  	/*
> @@ -689,7 +931,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>  	for (i = 0; i < nseg; i++) {
>  		while ((bio == NULL) ||
>  		       (bio_add_page(bio,
> -				     blkbk->pending_page(pending_req, i),
> +				     pages[i],
>  				     seg[i].nsec << 9,
>  				     seg[i].buf & ~PAGE_MASK) == 0)) {
>  
> diff --git a/drivers/block/xen-blkback/common.h b/drivers/block/xen-blkback/common.h
> index 9ad3b5e..ae7951f 100644
> --- a/drivers/block/xen-blkback/common.h
> +++ b/drivers/block/xen-blkback/common.h
> @@ -34,6 +34,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -160,10 +161,22 @@ struct xen_vbd {
>  	sector_t		size;
>  	bool			flush_support;
>  	bool			discard_secure;
> +
> +	unsigned int		feature_gnt_persistent:1;
> +	unsigned int		overflow_max_grants:1;
>  };
>  
>  struct backend_info;
>  
> +
> +struct persistent_gnt {
> +	struct page *page;
> +	grant_ref_t gnt;
> +	grant_handle_t handle;
> +	uint64_t dev_bus_addr;
> +	struct rb_node node;
> +};
> +
>  struct xen_blkif {
>  	/* Unique identifier for this interface. */
>  	domid_t			domid;
> @@ -190,6 +203,10 @@ struct xen_blkif {
>  	struct task_struct	*xenblkd;
>  	unsigned int		waiting_reqs;
>  
> +	/* tree to store persistent grants */
> +	struct rb_root		persistent_gnts;
> +	unsigned int		persistent_gnt_c;
> +
>  	/* statistics */
>  	unsigned long		st_print;
>  	int			st_rd_req;
> diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c
> index 4f66171..b225026 100644
> --- a/drivers/block/xen-blkback/xenbus.c
> +++ b/drivers/block/xen-blkback/xenbus.c
> @@ -118,6 +118,7 @@ static struct xen_blkif *xen_blkif_alloc(domid_t domid)
>  	atomic_set(&blkif->drain, 0);
>  	blkif->st_print = jiffies;
>  	init_waitqueue_head(&blkif->waiting_to_free);
> +	blkif->persistent_gnts.rb_node = NULL;
>  
>  	return blkif;
>  }
> @@ -673,6 +674,13 @@ again:
>  
>  	xen_blkbk_barrier(xbt, be, be->blkif->vbd.flush_support);
>  
> +	err = xenbus_printf(xbt, dev->nodename, "feature-persistent", "%u", 1);
> +	if (err) {
> +		xenbus_dev_fatal(dev, err, "writing %s/feature-persistent",
> +				 dev->nodename);
> +		goto abort;
> +	}
> +
>  	err = xenbus_printf(xbt, dev->nodename, "sectors", "%llu",
>  			    (unsigned long long)vbd_sz(&be->blkif->vbd));
>  	if (err) {
> @@ -721,6 +729,7 @@ static int connect_ring(struct backend_info *be)
>  	struct xenbus_device *dev = be->dev;
>  	unsigned long ring_ref;
>  	unsigned int evtchn;
> +	unsigned int pers_grants;
>  	char protocol[64] = "";
>  	int err;
>  
> @@ -750,8 +759,18 @@ static int connect_ring(struct backend_info *be)
>  		xenbus_dev_fatal(dev, err, "unknown fe protocol %s", protocol);
>  		return -1;
>  	}
> -	pr_info(DRV_PFX "ring-ref %ld, event-channel %d, protocol %d (%s)\n",
> -		ring_ref, evtchn, be->blkif->blk_protocol, protocol);
> +	err = xenbus_gather(XBT_NIL, dev->otherend,
> +			    "feature-persistent-grants", "%u",
> +			    &pers_grants, NULL);
> +	if (err)
> +		pers_grants = 0;
> +
> +	be->blkif->vbd.feature_gnt_persistent = pers_grants;
> +	be->blkif->vbd.overflow_max_grants = 0;
> +
> +	pr_info(DRV_PFX "ring-ref %ld, event-channel %d, protocol %d (%s) %s\n",
> +		ring_ref, evtchn, be->blkif->blk_protocol, protocol,
> +		pers_grants ? "persistent grants" : "");
>  
>  	/* Map the shared frame, irq etc. */
>  	err = xen_blkif_map(be->blkif, ring_ref, evtchn);
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 007db89..911d733 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -44,6 +44,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -64,10 +65,17 @@ enum blkif_state {
>  	BLKIF_STATE_SUSPENDED,
>  };
>  
> +struct grant {
> +	grant_ref_t gref;
> +	unsigned long pfn;
> +	struct llist_node node;
> +};
> +
>  struct blk_shadow {
>  	struct blkif_request req;
>  	struct request *request;
>  	unsigned long frame[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct grant *grants_used[BLKIF_MAX_SEGMENTS_PER_REQUEST];
>  };
>  
>  static DEFINE_MUTEX(blkfront_mutex);
> @@ -97,6 +105,8 @@ struct blkfront_info
>  	struct work_struct work;
>  	struct gnttab_free_callback callback;
>  	struct blk_shadow shadow[BLK_RING_SIZE];
> +	struct llist_head persistent_gnts;
> +	unsigned int persistent_gnts_c;
>  	unsigned long shadow_free;
>  	unsigned int feature_flush;
>  	unsigned int flush_op;
> @@ -104,6 +114,7 @@ struct blkfront_info
>  	unsigned int feature_secdiscard:1;
>  	unsigned int discard_granularity;
>  	unsigned int discard_alignment;
> +	unsigned int feature_persistent:1;
>  	int is_ready;
>  };
>  
> @@ -287,21 +298,36 @@ static int blkif_queue_request(struct request *req)
>  	unsigned long id;
>  	unsigned int fsect, lsect;
>  	int i, ref;
> +
> +	/*
> +	 * Used to store if we are able to queue the request by just using
> +	 * existing persistent grants, or if we have to get new grants,
> +	 * as there are not sufficiently many free.
> +	 */
> +	bool new_persistent_gnts;
>  	grant_ref_t gref_head;
> +	struct page *granted_page;
> +	struct grant *gnt_list_entry = NULL;
>  	struct scatterlist *sg;
>  
>  	if (unlikely(info->connected != BLKIF_STATE_CONNECTED))
>  		return 1;
>  
> -	if (gnttab_alloc_grant_references(
> -		BLKIF_MAX_SEGMENTS_PER_REQUEST, &gref_head) < 0) {
> -		gnttab_request_free_callback(
> -			&info->callback,
> -			blkif_restart_queue_callback,
> -			info,
> -			BLKIF_MAX_SEGMENTS_PER_REQUEST);
> -		return 1;
> -	}
> +	/* Check if we have enought grants to allocate a requests */
> +	if (info->persistent_gnts_c < BLKIF_MAX_SEGMENTS_PER_REQUEST) {
> +		new_persistent_gnts = 1;
> +		if (gnttab_alloc_grant_references(
> +		    BLKIF_MAX_SEGMENTS_PER_REQUEST - info->persistent_gnts_c,
> +		    &gref_head) < 0) {
> +			gnttab_request_free_callback(
> +				&info->callback,
> +				blkif_restart_queue_callback,
> +				info,
> +				BLKIF_MAX_SEGMENTS_PER_REQUEST);
> +			return 1;
> +		}
> +	} else
> +		new_persistent_gnts = 0;
>  
>  	/* Fill out a communications ring structure. */
>  	ring_req = RING_GET_REQUEST(&info->ring, info->ring.req_prod_pvt);
> @@ -341,18 +367,73 @@ static int blkif_queue_request(struct request *req)
>  		       BLKIF_MAX_SEGMENTS_PER_REQUEST);
>  
>  		for_each_sg(info->sg, sg, ring_req->u.rw.nr_segments, i) {
> -			buffer_mfn = pfn_to_mfn(page_to_pfn(sg_page(sg)));
>  			fsect = sg->offset >> 9;
>  			lsect = fsect + (sg->length >> 9) - 1;
> -			/* install a grant reference. */
> -			ref = gnttab_claim_grant_reference(&gref_head);
> -			BUG_ON(ref == -ENOSPC);
>  
> -			gnttab_grant_foreign_access_ref(
> -					ref,
> +			if (info->persistent_gnts_c) {
> +				BUG_ON(llist_empty(&info->persistent_gnts));
> +				gnt_list_entry = llist_entry(
> +					llist_del_first(&info->persistent_gnts),
> +					struct grant, node);
> +
> +				ref = gnt_list_entry->gref;
> +				buffer_mfn = pfn_to_mfn(gnt_list_entry->pfn);
> +				info->persistent_gnts_c--;
> +			} else {
> +				ref = gnttab_claim_grant_reference(&gref_head);
> +				BUG_ON(ref == -ENOSPC);
> +
> +				gnt_list_entry =
> +					kmalloc(sizeof(struct grant),
> +							 GFP_ATOMIC);
> +				if (!gnt_list_entry)
> +					return -ENOMEM;
> +
> +				granted_page = alloc_page(GFP_ATOMIC);
> +				if (!granted_page) {
> +					kfree(gnt_list_entry);
> +					return -ENOMEM;
> +				}
> +
> +				gnt_list_entry->pfn =
> +					page_to_pfn(granted_page);
> +				gnt_list_entry->gref = ref;
> +
> +				buffer_mfn = pfn_to_mfn(page_to_pfn(
> +								granted_page));
> +				gnttab_grant_foreign_access_ref(ref,
>  					info->xbdev->otherend_id,
> -					buffer_mfn,
> -					rq_data_dir(req));
> +					buffer_mfn, 0);
> +			}
> +
> +			info->shadow[id].grants_used[i] = gnt_list_entry;
> +
> +			if (rq_data_dir(req)) {
> +				char *bvec_data;
> +				void *shared_data;
> +
> +				BUG_ON(sg->offset + sg->length > PAGE_SIZE);
> +
> +				shared_data = kmap_atomic(
> +					pfn_to_page(gnt_list_entry->pfn));
> +				bvec_data = kmap_atomic(sg_page(sg));
> +
> +				/*
> +				 * this does not wipe data stored outside the
> +				 * range sg->offset..sg->offset+sg->length.
> +				 * Therefore, blkback *could* see data from
> +				 * previous requests. This is OK as long as
> +				 * persistent grants are shared with just one
> +				 * domain. It may need refactoring if this
> +				 * changes
> +				 */
> +				memcpy(shared_data + sg->offset,
> +				       bvec_data   + sg->offset,
> +				       sg->length);
> +
> +				kunmap_atomic(bvec_data);
> +				kunmap_atomic(shared_data);
> +			}
>  
>  			info->shadow[id].frame[i] = mfn_to_pfn(buffer_mfn);
>  			ring_req->u.rw.seg[i] =
> @@ -368,7 +449,8 @@ static int blkif_queue_request(struct request *req)
>  	/* Keep a private copy so we can reissue requests when recovering. */
>  	info->shadow[id].req = *ring_req;
>  
> -	gnttab_free_grant_references(gref_head);
> +	if (new_persistent_gnts)
> +		gnttab_free_grant_references(gref_head);
>  
>  	return 0;
>  }
> @@ -480,12 +562,13 @@ static int xlvbd_init_blk_queue(struct gendisk *gd, u16 sector_size)
>  static void xlvbd_flush(struct blkfront_info *info)
>  {
>  	blk_queue_flush(info->rq, info->feature_flush);
> -	printk(KERN_INFO "blkfront: %s: %s: %s\n",
> +	printk(KERN_INFO "blkfront: %s: %s: %s %s\n",
>  	       info->gd->disk_name,
>  	       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
>  		"barrier" : (info->flush_op == BLKIF_OP_FLUSH_DISKCACHE ?
>  		"flush diskcache" : "barrier or flush"),
> -	       info->feature_flush ? "enabled" : "disabled");
> +	       info->feature_flush ? "enabled" : "disabled",
> +	       info->feature_persistent ? "using persistent grants" : "");
>  }
>  
>  static int xen_translate_vdev(int vdevice, int *minor, unsigned int *offset)
> @@ -707,6 +790,9 @@ static void blkif_restart_queue(struct work_struct *work)
>  
>  static void blkif_free(struct blkfront_info *info, int suspend)
>  {
> +	struct llist_node *all_gnts;
> +	struct grant *persistent_gnt;
> +
>  	/* Prevent new requests being issued until we fix things up. */
>  	spin_lock_irq(&info->io_lock);
>  	info->connected = suspend ?
> @@ -714,6 +800,17 @@ static void blkif_free(struct blkfront_info *info, int suspend)
>  	/* No more blkif_request(). */
>  	if (info->rq)
>  		blk_stop_queue(info->rq);
> +
> +	/* Remove all persistent grants */
> +	if (info->persistent_gnts_c) {
> +		all_gnts = llist_del_all(&info->persistent_gnts);
> +		llist_for_each_entry(persistent_gnt, all_gnts, node) {
> +			gnttab_end_foreign_access(persistent_gnt->gref, 0, 0UL);
> +			kfree(persistent_gnt);
> +		}
> +		info->persistent_gnts_c = 0;
> +	}
> +
>  	/* No more gnttab callback work. */
>  	gnttab_cancel_free_callback(&info->callback);
>  	spin_unlock_irq(&info->io_lock);
> @@ -734,13 +831,42 @@ static void blkif_free(struct blkfront_info *info, int suspend)
>  
>  }
>  
> -static void blkif_completion(struct blk_shadow *s)
> +static void blkif_completion(struct blk_shadow *s, struct blkfront_info *info,
> +			     struct blkif_response *bret)
>  {
>  	int i;
> -	/* Do not let BLKIF_OP_DISCARD as nr_segment is in the same place
> -	 * flag. */
> -	for (i = 0; i < s->req.u.rw.nr_segments; i++)
> -		gnttab_end_foreign_access(s->req.u.rw.seg[i].gref, 0, 0UL);
> +	struct bio_vec *bvec;
> +	struct req_iterator iter;
> +	unsigned long flags;
> +	char *bvec_data;
> +	void *shared_data;
> +	unsigned int offset = 0;
> +
> +	if (bret->operation == BLKIF_OP_READ) {
> +		/*
> +		 * Copy the data received from the backend into the bvec.
> +		 * Since bv_offset can be different than 0, and bv_len different
> +		 * than PAGE_SIZE, we have to keep track of the current offset,
> +		 * to be sure we are copying the data from the right shared page.
> +		 */
> +		rq_for_each_segment(bvec, s->request, iter) {
> +			BUG_ON((bvec->bv_offset + bvec->bv_len) > PAGE_SIZE);
> +			i = offset >> PAGE_SHIFT;
> +			shared_data = kmap_atomic(
> +				pfn_to_page(s->grants_used[i]->pfn));
> +			bvec_data = bvec_kmap_irq(bvec, &flags);
> +			memcpy(bvec_data, shared_data + bvec->bv_offset,
> +				bvec->bv_len);
> +			bvec_kunmap_irq(bvec_data, &flags);
> +			kunmap_atomic(shared_data);
> +			offset += bvec->bv_len;
> +		}
> +	}
> +	/* Add the persistent grant into the list of free grants */
> +	for (i = 0; i < s->req.u.rw.nr_segments; i++) {
> +		llist_add(&s->grants_used[i]->node, &info->persistent_gnts);
> +		info->persistent_gnts_c++;
> +	}
>  }
>  
>  static irqreturn_t blkif_interrupt(int irq, void *dev_id)
> @@ -783,7 +909,7 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
>  		req  = info->shadow[id].request;
>  
>  		if (bret->operation != BLKIF_OP_DISCARD)
> -			blkif_completion(&info->shadow[id]);
> +			blkif_completion(&info->shadow[id], info, bret);
>  
>  		if (add_id_to_freelist(info, id)) {
>  			WARN(1, "%s: response to %s (id %ld) couldn't be recycled!\n",
> @@ -942,6 +1068,11 @@ again:
>  		message = "writing protocol";
>  		goto abort_transaction;
>  	}
> +	err = xenbus_printf(xbt, dev->nodename,
> +			    "feature-persistent-grants", "%u", 1);
> +	if (err)
> +		dev_warn(&dev->dev,
> +			 "writing persistent grants feature to xenbus");
>  
>  	err = xenbus_transaction_end(xbt, 0);
>  	if (err) {
> @@ -1029,6 +1160,8 @@ static int blkfront_probe(struct xenbus_device *dev,
>  	spin_lock_init(&info->io_lock);
>  	info->xbdev = dev;
>  	info->vdevice = vdevice;
> +	init_llist_head(&info->persistent_gnts);
> +	info->persistent_gnts_c = 0;
>  	info->connected = BLKIF_STATE_DISCONNECTED;
>  	INIT_WORK(&info->work, blkif_restart_queue);
>  
> @@ -1093,7 +1226,7 @@ static int blkif_recover(struct blkfront_info *info)
>  					req->u.rw.seg[j].gref,
>  					info->xbdev->otherend_id,
>  					pfn_to_mfn(info->shadow[req->u.rw.id].frame[j]),
> -					rq_data_dir(info->shadow[req->u.rw.id].request));
> +					0);
>  		}
>  		info->shadow[req->u.rw.id].req = *req;
>  
> @@ -1225,7 +1358,7 @@ static void blkfront_connect(struct blkfront_info *info)
>  	unsigned long sector_size;
>  	unsigned int binfo;
>  	int err;
> -	int barrier, flush, discard;
> +	int barrier, flush, discard, persistent;
>  
>  	switch (info->connected) {
>  	case BLKIF_STATE_CONNECTED:
> @@ -1303,6 +1436,14 @@ static void blkfront_connect(struct blkfront_info *info)
>  	if (!err && discard)
>  		blkfront_setup_discard(info);
>  
> +	err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
> +			    "feature-persistent", "%u", &persistent,
> +			    NULL);
> +	if (err)
> +		info->feature_persistent = 0;
> +	else
> +		info->feature_persistent = persistent;
> +
>  	err = xlvbd_alloc_gendisk(sectors, info, binfo, sector_size);
>  	if (err) {
>  		xenbus_dev_fatal(info->xbdev, err, "xlvbd_add at %s",
> -- 
> 1.7.7.5 (Apple Git-26)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 14:10:33 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 14:10:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSq2b-0003Rl-AH; Mon, 29 Oct 2012 14:10:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSq2Z-0003Rg-Ew
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 14:10:07 +0000
Received: from [85.158.138.51:50535] by server-6.bemta-3.messagelabs.com id
	B2/55-32375-E3E8E805; Mon, 29 Oct 2012 14:10:06 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1351519803!21499653!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODI4MTEw\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20975 invoked from network); 29 Oct 2012 14:10:05 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Oct 2012 14:10:05 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9TEA0CM009571
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 29 Oct 2012 14:10:01 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9TEA0r0019101
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 29 Oct 2012 14:10:00 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9TEA0lP024043; Mon, 29 Oct 2012 09:10:00 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 29 Oct 2012 07:09:59 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 751014042D; Mon, 29 Oct 2012 09:57:33 -0400 (EDT)
Date: Mon, 29 Oct 2012 09:57:33 -0400
From: Konrad Rzeszutek Wilk 
To: Roger Pau Monne 
Message-ID: <20121029135733.GZ2708@phenom.dumpdata.com>
References: <1351097925-26221-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1351097925-26221-1-git-send-email-roger.pau@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Oliver Chick , linux-kernel@vger.kernel.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 24, 2012 at 06:58:45PM +0200, Roger Pau Monne wrote:
> This patch implements persistent grants for the xen-blk{front,back}
> mechanism. The effect of this change is to reduce the number of unmap
> operations performed, since they cause a (costly) TLB shootdown. This
> allows the I/O performance to scale better when a large number of VMs
> are performing I/O.
> 
> Previously, the blkfront driver was supplied a bvec[] from the request
> queue. This was granted to dom0; dom0 performed the I/O and wrote
> directly into the grant-mapped memory and unmapped it; blkfront then
> removed foreign access for that grant. The cost of unmapping scales
> badly with the number of CPUs in Dom0. An experiment showed that when
> Dom0 has 24 VCPUs, and guests are performing parallel I/O to a
> ramdisk, the IPIs from performing unmap's is a bottleneck at 5 guests
> (at which point 650,000 IOPS are being performed in total). If more
> than 5 guests are used, the performance declines. By 10 guests, only
> 400,000 IOPS are being performed.
> 
> This patch improves performance by only unmapping when the connection
> between blkfront and back is broken.
> 
> On startup blkfront notifies blkback that it is using persistent
> grants, and blkback will do the same. If blkback is not capable of
> persistent mapping, blkfront will still use the same grants, since it
> is compatible with the previous protocol, and simplifies the code
> complexity in blkfront.
> 
> To perform a read, in persistent mode, blkfront uses a separate pool
> of pages that it maps to dom0. When a request comes in, blkfront
> transmutes the request so that blkback will write into one of these
> free pages. Blkback keeps note of which grefs it has already
> mapped. When a new ring request comes to blkback, it looks to see if
> it has already mapped that page. If so, it will not map it again. If
> the page hasn't been previously mapped, it is mapped now, and a record
> is kept of this mapping. Blkback proceeds as usual. When blkfront is
> notified that blkback has completed a request, it memcpy's from the
> shared memory, into the bvec supplied. A record that the {gref, page}
> tuple is mapped, and not inflight is kept.
> 
> Writes are similar, except that the memcpy is peformed from the
> supplied bvecs, into the shared pages, before the request is put onto
> the ring.
> 
> Blkback stores a mapping of grefs=>{page mapped to by gref} in
> a red-black tree. As the grefs are not known apriori, and provide no
> guarantees on their ordering, we have to perform a search
> through this tree to find the page, for every gref we receive. This
> operation takes O(log n) time in the worst case. In blkfront grants
> are stored using a single linked list.
> 
> The maximum number of grants that blkback will persistenly map is
> currently set to RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, to
> prevent a malicios guest from attempting a DoS, by supplying fresh
> grefs, causing the Dom0 kernel to map excessively. If a guest
> is using persistent grants and exceeds the maximum number of grants to
> map persistenly the newly passed grefs will be mapped and unmaped.
> Using this approach, we can have requests that mix persistent and
> non-persistent grants, and we need to handle them correctly.
> This allows us to set the maximum number of persistent grants to a
> lower value than RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, although
> setting it will lead to unpredictable performance.
> 
> In writing this patch, the question arrises as to if the additional
> cost of performing memcpys in the guest (to/from the pool of granted
> pages) outweigh the gains of not performing TLB shootdowns. The answer
> to that question is `no'. There appears to be very little, if any
> additional cost to the guest of using persistent grants. There is
> perhaps a small saving, from the reduced number of hypercalls
> performed in granting, and ending foreign access.
> 
> Signed-off-by: Oliver Chick 
> Signed-off-by: Roger Pau Monne 
> Cc: 
> Cc: 
> ---
> Changes since v1:
>  * Changed the unmap_seg array to a bitmap.
>  * Only report using persistent grants in blkfront if blkback supports
>    it.
>  * Reword some comments.
>  * Fix a bug when setting the handler, index j was not incremented
>    correctly.
>  * Check that the tree of grants in blkback is not empty before
>    iterating over it when doing the cleanup.
>  * Rebase on top of linux-net.


It looks good to me. Going to stick it on my for-jens-3.8 branch.

> ---
> Benchmarks showing the impact of this patch in blk performance can be
> found at:
> 
> http://xenbits.xensource.com/people/royger/persistent_grants/
> ---
>  drivers/block/xen-blkback/blkback.c |  292 ++++++++++++++++++++++++++++++++---
>  drivers/block/xen-blkback/common.h  |   17 ++
>  drivers/block/xen-blkback/xenbus.c  |   23 +++-
>  drivers/block/xen-blkfront.c        |  197 ++++++++++++++++++++----
>  4 files changed, 474 insertions(+), 55 deletions(-)
> 
> diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
> index 280a138..663d42d 100644
> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -39,6 +39,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -79,6 +80,7 @@ struct pending_req {
>  	unsigned short		operation;
>  	int			status;
>  	struct list_head	free_list;
> +	DECLARE_BITMAP(unmap_seg, BLKIF_MAX_SEGMENTS_PER_REQUEST);
>  };
>  
>  #define BLKBACK_INVALID_HANDLE (~0)
> @@ -99,6 +101,36 @@ struct xen_blkbk {
>  static struct xen_blkbk *blkbk;
>  
>  /*
> + * Maximum number of grant pages that can be mapped in blkback.
> + * BLKIF_MAX_SEGMENTS_PER_REQUEST * RING_SIZE is the maximum number of
> + * pages that blkback will persistently map.
> + * Currently, this is:
> + * RING_SIZE = 32 (for all known ring types)
> + * BLKIF_MAX_SEGMENTS_PER_REQUEST = 11
> + * sizeof(struct persistent_gnt) = 48
> + * So the maximum memory used to store the grants is:
> + * 32 * 11 * 48 = 16896 bytes
> + */
> +static inline unsigned int max_mapped_grant_pages(enum blkif_protocol protocol)
> +{
> +	switch (protocol) {
> +	case BLKIF_PROTOCOL_NATIVE:
> +		return __CONST_RING_SIZE(blkif, PAGE_SIZE) *
> +			   BLKIF_MAX_SEGMENTS_PER_REQUEST;
> +	case BLKIF_PROTOCOL_X86_32:
> +		return __CONST_RING_SIZE(blkif_x86_32, PAGE_SIZE) *
> +			   BLKIF_MAX_SEGMENTS_PER_REQUEST;
> +	case BLKIF_PROTOCOL_X86_64:
> +		return __CONST_RING_SIZE(blkif_x86_64, PAGE_SIZE) *
> +			   BLKIF_MAX_SEGMENTS_PER_REQUEST;
> +	default:
> +		BUG();
> +	}
> +	return 0;
> +}
> +
> +
> +/*
>   * Little helpful macro to figure out the index and virtual address of the
>   * pending_pages[..]. For each 'pending_req' we have have up to
>   * BLKIF_MAX_SEGMENTS_PER_REQUEST (11) pages. The seg would be from 0 through
> @@ -129,6 +161,57 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>  static void make_response(struct xen_blkif *blkif, u64 id,
>  			  unsigned short op, int st);
>  
> +#define foreach_grant(pos, rbtree, node) \
> +	for ((pos) = container_of(rb_first((rbtree)), typeof(*(pos)), node); \
> +	     &(pos)->node != NULL; \
> +	     (pos) = container_of(rb_next(&(pos)->node), typeof(*(pos)), node))
> +
> +
> +static void add_persistent_gnt(struct rb_root *root,
> +			       struct persistent_gnt *persistent_gnt)
> +{
> +	struct rb_node **new = &(root->rb_node), *parent = NULL;
> +	struct persistent_gnt *this;
> +
> +	/* Figure out where to put new node */
> +	while (*new) {
> +		this = container_of(*new, struct persistent_gnt, node);
> +
> +		parent = *new;
> +		if (persistent_gnt->gnt < this->gnt)
> +			new = &((*new)->rb_left);
> +		else if (persistent_gnt->gnt > this->gnt)
> +			new = &((*new)->rb_right);
> +		else {
> +			pr_alert(DRV_PFX " trying to add a gref that's already in the tree\n");
> +			BUG();
> +		}
> +	}
> +
> +	/* Add new node and rebalance tree. */
> +	rb_link_node(&(persistent_gnt->node), parent, new);
> +	rb_insert_color(&(persistent_gnt->node), root);
> +}
> +
> +static struct persistent_gnt *get_persistent_gnt(struct rb_root *root,
> +						 grant_ref_t gref)
> +{
> +	struct persistent_gnt *data;
> +	struct rb_node *node = root->rb_node;
> +
> +	while (node) {
> +		data = container_of(node, struct persistent_gnt, node);
> +
> +		if (gref < data->gnt)
> +			node = node->rb_left;
> +		else if (gref > data->gnt)
> +			node = node->rb_right;
> +		else
> +			return data;
> +	}
> +	return NULL;
> +}
> +
>  /*
>   * Retrieve from the 'pending_reqs' a free pending_req structure to be used.
>   */
> @@ -275,6 +358,11 @@ int xen_blkif_schedule(void *arg)
>  {
>  	struct xen_blkif *blkif = arg;
>  	struct xen_vbd *vbd = &blkif->vbd;
> +	struct gnttab_unmap_grant_ref unmap[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct persistent_gnt *persistent_gnt;
> +	int ret = 0;
> +	int segs_to_unmap = 0;
>  
>  	xen_blkif_get(blkif);
>  
> @@ -302,6 +390,36 @@ int xen_blkif_schedule(void *arg)
>  			print_stats(blkif);
>  	}
>  
> +	/* Free all persistent grant pages */
> +	if (!RB_EMPTY_ROOT(&blkif->persistent_gnts)) {
> +		foreach_grant(persistent_gnt, &blkif->persistent_gnts, node) {
> +			BUG_ON(persistent_gnt->handle ==
> +				BLKBACK_INVALID_HANDLE);
> +			gnttab_set_unmap_op(&unmap[segs_to_unmap],
> +			    (unsigned long) pfn_to_kaddr(page_to_pfn(
> +				persistent_gnt->page)),
> +			    GNTMAP_host_map,
> +			    persistent_gnt->handle);
> +
> +			pages[segs_to_unmap] = persistent_gnt->page;
> +			rb_erase(&persistent_gnt->node,
> +				&blkif->persistent_gnts);
> +			kfree(persistent_gnt);
> +			blkif->persistent_gnt_c--;
> +
> +			if (++segs_to_unmap == BLKIF_MAX_SEGMENTS_PER_REQUEST ||
> +				!rb_next(&persistent_gnt->node)) {
> +				ret = gnttab_unmap_refs(unmap, NULL, pages,
> +							segs_to_unmap);
> +				BUG_ON(ret);
> +				segs_to_unmap = 0;
> +			}
> +		}
> +	}
> +
> +	BUG_ON(blkif->persistent_gnt_c != 0);
> +	BUG_ON(!RB_EMPTY_ROOT(&blkif->persistent_gnts));
> +
>  	if (log_stats)
>  		print_stats(blkif);
>  
> @@ -328,6 +446,8 @@ static void xen_blkbk_unmap(struct pending_req *req)
>  	int ret;
>  
>  	for (i = 0; i < req->nr_pages; i++) {
> +		if (!test_bit(i, req->unmap_seg))
> +			continue;
>  		handle = pending_handle(req, i);
>  		if (handle == BLKBACK_INVALID_HANDLE)
>  			continue;
> @@ -344,12 +464,26 @@ static void xen_blkbk_unmap(struct pending_req *req)
>  
>  static int xen_blkbk_map(struct blkif_request *req,
>  			 struct pending_req *pending_req,
> -			 struct seg_buf seg[])
> +			 struct seg_buf seg[],
> +			 struct page *pages[])
>  {
>  	struct gnttab_map_grant_ref map[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> -	int i;
> +	struct persistent_gnt *persistent_gnts[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct page *pages_to_gnt[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct persistent_gnt *persistent_gnt = NULL;
> +	struct xen_blkif *blkif = pending_req->blkif;
> +	phys_addr_t addr = 0;
> +	int i, j;
> +	bool new_map;
>  	int nseg = req->u.rw.nr_segments;
> +	int segs_to_map = 0;
>  	int ret = 0;
> +	int use_persistent_gnts;
> +
> +	use_persistent_gnts = (blkif->vbd.feature_gnt_persistent);
> +
> +	BUG_ON(blkif->persistent_gnt_c >
> +		   max_mapped_grant_pages(pending_req->blkif->blk_protocol));
>  
>  	/*
>  	 * Fill out preq.nr_sects with proper amount of sectors, and setup
> @@ -359,36 +493,143 @@ static int xen_blkbk_map(struct blkif_request *req,
>  	for (i = 0; i < nseg; i++) {
>  		uint32_t flags;
>  
> -		flags = GNTMAP_host_map;
> -		if (pending_req->operation != BLKIF_OP_READ)
> -			flags |= GNTMAP_readonly;
> -		gnttab_set_map_op(&map[i], vaddr(pending_req, i), flags,
> -				  req->u.rw.seg[i].gref,
> -				  pending_req->blkif->domid);
> +		if (use_persistent_gnts)
> +			persistent_gnt = get_persistent_gnt(
> +				&blkif->persistent_gnts,
> +				req->u.rw.seg[i].gref);
> +
> +		if (persistent_gnt) {
> +			/*
> +			 * We are using persistent grants and
> +			 * the grant is already mapped
> +			 */
> +			new_map = 0;
> +		} else if (use_persistent_gnts &&
> +			   blkif->persistent_gnt_c <
> +			   max_mapped_grant_pages(blkif->blk_protocol)) {
> +			/*
> +			 * We are using persistent grants, the grant is
> +			 * not mapped but we have room for it
> +			 */
> +			new_map = 1;
> +			persistent_gnt = kzalloc(
> +				sizeof(struct persistent_gnt),
> +				GFP_KERNEL);
> +			if (!persistent_gnt)
> +				return -ENOMEM;
> +			persistent_gnt->page = alloc_page(GFP_KERNEL);
> +			if (!persistent_gnt->page) {
> +				kfree(persistent_gnt);
> +				return -ENOMEM;
> +			}
> +			persistent_gnt->gnt = req->u.rw.seg[i].gref;
> +
> +			pages_to_gnt[segs_to_map] =
> +				persistent_gnt->page;
> +			addr = (unsigned long) pfn_to_kaddr(
> +				page_to_pfn(persistent_gnt->page));
> +
> +			add_persistent_gnt(&blkif->persistent_gnts,
> +				persistent_gnt);
> +			blkif->persistent_gnt_c++;
> +			pr_debug(DRV_PFX " grant %u added to the tree of persistent grants, using %u/%u\n",
> +				 persistent_gnt->gnt, blkif->persistent_gnt_c,
> +				 max_mapped_grant_pages(blkif->blk_protocol));
> +		} else {
> +			/*
> +			 * We are either using persistent grants and
> +			 * hit the maximum limit of grants mapped,
> +			 * or we are not using persistent grants.
> +			 */
> +			if (use_persistent_gnts &&
> +				!blkif->vbd.overflow_max_grants) {
> +				blkif->vbd.overflow_max_grants = 1;
> +				pr_alert(DRV_PFX " domain %u, device %#x is using maximum number of persistent grants\n",
> +					 blkif->domid, blkif->vbd.handle);
> +			}
> +			new_map = 1;
> +			pages[i] = blkbk->pending_page(pending_req, i);
> +			addr = vaddr(pending_req, i);
> +			pages_to_gnt[segs_to_map] =
> +				blkbk->pending_page(pending_req, i);
> +		}
> +
> +		if (persistent_gnt) {
> +			pages[i] = persistent_gnt->page;
> +			persistent_gnts[i] = persistent_gnt;
> +		} else {
> +			persistent_gnts[i] = NULL;
> +		}
> +
> +		if (new_map) {
> +			flags = GNTMAP_host_map;
> +			if (!persistent_gnt &&
> +			    (pending_req->operation != BLKIF_OP_READ))
> +				flags |= GNTMAP_readonly;
> +			gnttab_set_map_op(&map[segs_to_map++], addr,
> +					  flags, req->u.rw.seg[i].gref,
> +					  blkif->domid);
> +		}
>  	}
>  
> -	ret = gnttab_map_refs(map, NULL, &blkbk->pending_page(pending_req, 0), nseg);
> -	BUG_ON(ret);
> +	if (segs_to_map) {
> +		ret = gnttab_map_refs(map, NULL, pages_to_gnt, segs_to_map);
> +		BUG_ON(ret);
> +	}
>  
>  	/*
>  	 * Now swizzle the MFN in our domain with the MFN from the other domain
>  	 * so that when we access vaddr(pending_req,i) it has the contents of
>  	 * the page from the other domain.
>  	 */
> -	for (i = 0; i < nseg; i++) {
> -		if (unlikely(map[i].status != 0)) {
> -			pr_debug(DRV_PFX "invalid buffer -- could not remap it\n");
> -			map[i].handle = BLKBACK_INVALID_HANDLE;
> -			ret |= 1;
> +	bitmap_zero(pending_req->unmap_seg, BLKIF_MAX_SEGMENTS_PER_REQUEST);
> +	for (i = 0, j = 0; i < nseg; i++) {
> +		if (!persistent_gnts[i] || !persistent_gnts[i]->handle) {
> +			/* This is a newly mapped grant */
> +			BUG_ON(j >= segs_to_map);
> +			if (unlikely(map[j].status != 0)) {
> +				pr_debug(DRV_PFX "invalid buffer -- could not remap it\n");
> +				map[j].handle = BLKBACK_INVALID_HANDLE;
> +				ret |= 1;
> +				if (persistent_gnts[i]) {
> +					rb_erase(&persistent_gnts[i]->node,
> +						 &blkif->persistent_gnts);
> +					blkif->persistent_gnt_c--;
> +					kfree(persistent_gnts[i]);
> +					persistent_gnts[i] = NULL;
> +				}
> +			}
> +		}
> +		if (persistent_gnts[i]) {
> +			if (!persistent_gnts[i]->handle) {
> +				/*
> +				 * If this is a new persistent grant
> +				 * save the handler
> +				 */
> +				persistent_gnts[i]->handle = map[j].handle;
> +				persistent_gnts[i]->dev_bus_addr =
> +					map[j++].dev_bus_addr;
> +			}
> +			pending_handle(pending_req, i) =
> +				persistent_gnts[i]->handle;
> +
> +			if (ret)
> +				continue;
> +
> +			seg[i].buf = persistent_gnts[i]->dev_bus_addr |
> +				(req->u.rw.seg[i].first_sect << 9);
> +		} else {
> +			pending_handle(pending_req, i) = map[j].handle;
> +			bitmap_set(pending_req->unmap_seg, i, 1);
> +
> +			if (ret) {
> +				j++;
> +				continue;
> +			}
> +
> +			seg[i].buf = map[j++].dev_bus_addr |
> +				(req->u.rw.seg[i].first_sect << 9);
>  		}
> -
> -		pending_handle(pending_req, i) = map[i].handle;
> -
> -		if (ret)
> -			continue;
> -
> -		seg[i].buf  = map[i].dev_bus_addr |
> -			(req->u.rw.seg[i].first_sect << 9);
>  	}
>  	return ret;
>  }
> @@ -591,6 +832,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>  	int operation;
>  	struct blk_plug plug;
>  	bool drain = false;
> +	struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
>  
>  	switch (req->operation) {
>  	case BLKIF_OP_READ:
> @@ -677,7 +919,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>  	 * the hypercall to unmap the grants - that is all done in
>  	 * xen_blkbk_unmap.
>  	 */
> -	if (xen_blkbk_map(req, pending_req, seg))
> +	if (xen_blkbk_map(req, pending_req, seg, pages))
>  		goto fail_flush;
>  
>  	/*
> @@ -689,7 +931,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>  	for (i = 0; i < nseg; i++) {
>  		while ((bio == NULL) ||
>  		       (bio_add_page(bio,
> -				     blkbk->pending_page(pending_req, i),
> +				     pages[i],
>  				     seg[i].nsec << 9,
>  				     seg[i].buf & ~PAGE_MASK) == 0)) {
>  
> diff --git a/drivers/block/xen-blkback/common.h b/drivers/block/xen-blkback/common.h
> index 9ad3b5e..ae7951f 100644
> --- a/drivers/block/xen-blkback/common.h
> +++ b/drivers/block/xen-blkback/common.h
> @@ -34,6 +34,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -160,10 +161,22 @@ struct xen_vbd {
>  	sector_t		size;
>  	bool			flush_support;
>  	bool			discard_secure;
> +
> +	unsigned int		feature_gnt_persistent:1;
> +	unsigned int		overflow_max_grants:1;
>  };
>  
>  struct backend_info;
>  
> +
> +struct persistent_gnt {
> +	struct page *page;
> +	grant_ref_t gnt;
> +	grant_handle_t handle;
> +	uint64_t dev_bus_addr;
> +	struct rb_node node;
> +};
> +
>  struct xen_blkif {
>  	/* Unique identifier for this interface. */
>  	domid_t			domid;
> @@ -190,6 +203,10 @@ struct xen_blkif {
>  	struct task_struct	*xenblkd;
>  	unsigned int		waiting_reqs;
>  
> +	/* tree to store persistent grants */
> +	struct rb_root		persistent_gnts;
> +	unsigned int		persistent_gnt_c;
> +
>  	/* statistics */
>  	unsigned long		st_print;
>  	int			st_rd_req;
> diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c
> index 4f66171..b225026 100644
> --- a/drivers/block/xen-blkback/xenbus.c
> +++ b/drivers/block/xen-blkback/xenbus.c
> @@ -118,6 +118,7 @@ static struct xen_blkif *xen_blkif_alloc(domid_t domid)
>  	atomic_set(&blkif->drain, 0);
>  	blkif->st_print = jiffies;
>  	init_waitqueue_head(&blkif->waiting_to_free);
> +	blkif->persistent_gnts.rb_node = NULL;
>  
>  	return blkif;
>  }
> @@ -673,6 +674,13 @@ again:
>  
>  	xen_blkbk_barrier(xbt, be, be->blkif->vbd.flush_support);
>  
> +	err = xenbus_printf(xbt, dev->nodename, "feature-persistent", "%u", 1);
> +	if (err) {
> +		xenbus_dev_fatal(dev, err, "writing %s/feature-persistent",
> +				 dev->nodename);
> +		goto abort;
> +	}
> +
>  	err = xenbus_printf(xbt, dev->nodename, "sectors", "%llu",
>  			    (unsigned long long)vbd_sz(&be->blkif->vbd));
>  	if (err) {
> @@ -721,6 +729,7 @@ static int connect_ring(struct backend_info *be)
>  	struct xenbus_device *dev = be->dev;
>  	unsigned long ring_ref;
>  	unsigned int evtchn;
> +	unsigned int pers_grants;
>  	char protocol[64] = "";
>  	int err;
>  
> @@ -750,8 +759,18 @@ static int connect_ring(struct backend_info *be)
>  		xenbus_dev_fatal(dev, err, "unknown fe protocol %s", protocol);
>  		return -1;
>  	}
> -	pr_info(DRV_PFX "ring-ref %ld, event-channel %d, protocol %d (%s)\n",
> -		ring_ref, evtchn, be->blkif->blk_protocol, protocol);
> +	err = xenbus_gather(XBT_NIL, dev->otherend,
> +			    "feature-persistent-grants", "%u",
> +			    &pers_grants, NULL);
> +	if (err)
> +		pers_grants = 0;
> +
> +	be->blkif->vbd.feature_gnt_persistent = pers_grants;
> +	be->blkif->vbd.overflow_max_grants = 0;
> +
> +	pr_info(DRV_PFX "ring-ref %ld, event-channel %d, protocol %d (%s) %s\n",
> +		ring_ref, evtchn, be->blkif->blk_protocol, protocol,
> +		pers_grants ? "persistent grants" : "");
>  
>  	/* Map the shared frame, irq etc. */
>  	err = xen_blkif_map(be->blkif, ring_ref, evtchn);
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 007db89..911d733 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -44,6 +44,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -64,10 +65,17 @@ enum blkif_state {
>  	BLKIF_STATE_SUSPENDED,
>  };
>  
> +struct grant {
> +	grant_ref_t gref;
> +	unsigned long pfn;
> +	struct llist_node node;
> +};
> +
>  struct blk_shadow {
>  	struct blkif_request req;
>  	struct request *request;
>  	unsigned long frame[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct grant *grants_used[BLKIF_MAX_SEGMENTS_PER_REQUEST];
>  };
>  
>  static DEFINE_MUTEX(blkfront_mutex);
> @@ -97,6 +105,8 @@ struct blkfront_info
>  	struct work_struct work;
>  	struct gnttab_free_callback callback;
>  	struct blk_shadow shadow[BLK_RING_SIZE];
> +	struct llist_head persistent_gnts;
> +	unsigned int persistent_gnts_c;
>  	unsigned long shadow_free;
>  	unsigned int feature_flush;
>  	unsigned int flush_op;
> @@ -104,6 +114,7 @@ struct blkfront_info
>  	unsigned int feature_secdiscard:1;
>  	unsigned int discard_granularity;
>  	unsigned int discard_alignment;
> +	unsigned int feature_persistent:1;
>  	int is_ready;
>  };
>  
> @@ -287,21 +298,36 @@ static int blkif_queue_request(struct request *req)
>  	unsigned long id;
>  	unsigned int fsect, lsect;
>  	int i, ref;
> +
> +	/*
> +	 * Used to store if we are able to queue the request by just using
> +	 * existing persistent grants, or if we have to get new grants,
> +	 * as there are not sufficiently many free.
> +	 */
> +	bool new_persistent_gnts;
>  	grant_ref_t gref_head;
> +	struct page *granted_page;
> +	struct grant *gnt_list_entry = NULL;
>  	struct scatterlist *sg;
>  
>  	if (unlikely(info->connected != BLKIF_STATE_CONNECTED))
>  		return 1;
>  
> -	if (gnttab_alloc_grant_references(
> -		BLKIF_MAX_SEGMENTS_PER_REQUEST, &gref_head) < 0) {
> -		gnttab_request_free_callback(
> -			&info->callback,
> -			blkif_restart_queue_callback,
> -			info,
> -			BLKIF_MAX_SEGMENTS_PER_REQUEST);
> -		return 1;
> -	}
> +	/* Check if we have enought grants to allocate a requests */
> +	if (info->persistent_gnts_c < BLKIF_MAX_SEGMENTS_PER_REQUEST) {
> +		new_persistent_gnts = 1;
> +		if (gnttab_alloc_grant_references(
> +		    BLKIF_MAX_SEGMENTS_PER_REQUEST - info->persistent_gnts_c,
> +		    &gref_head) < 0) {
> +			gnttab_request_free_callback(
> +				&info->callback,
> +				blkif_restart_queue_callback,
> +				info,
> +				BLKIF_MAX_SEGMENTS_PER_REQUEST);
> +			return 1;
> +		}
> +	} else
> +		new_persistent_gnts = 0;
>  
>  	/* Fill out a communications ring structure. */
>  	ring_req = RING_GET_REQUEST(&info->ring, info->ring.req_prod_pvt);
> @@ -341,18 +367,73 @@ static int blkif_queue_request(struct request *req)
>  		       BLKIF_MAX_SEGMENTS_PER_REQUEST);
>  
>  		for_each_sg(info->sg, sg, ring_req->u.rw.nr_segments, i) {
> -			buffer_mfn = pfn_to_mfn(page_to_pfn(sg_page(sg)));
>  			fsect = sg->offset >> 9;
>  			lsect = fsect + (sg->length >> 9) - 1;
> -			/* install a grant reference. */
> -			ref = gnttab_claim_grant_reference(&gref_head);
> -			BUG_ON(ref == -ENOSPC);
>  
> -			gnttab_grant_foreign_access_ref(
> -					ref,
> +			if (info->persistent_gnts_c) {
> +				BUG_ON(llist_empty(&info->persistent_gnts));
> +				gnt_list_entry = llist_entry(
> +					llist_del_first(&info->persistent_gnts),
> +					struct grant, node);
> +
> +				ref = gnt_list_entry->gref;
> +				buffer_mfn = pfn_to_mfn(gnt_list_entry->pfn);
> +				info->persistent_gnts_c--;
> +			} else {
> +				ref = gnttab_claim_grant_reference(&gref_head);
> +				BUG_ON(ref == -ENOSPC);
> +
> +				gnt_list_entry =
> +					kmalloc(sizeof(struct grant),
> +							 GFP_ATOMIC);
> +				if (!gnt_list_entry)
> +					return -ENOMEM;
> +
> +				granted_page = alloc_page(GFP_ATOMIC);
> +				if (!granted_page) {
> +					kfree(gnt_list_entry);
> +					return -ENOMEM;
> +				}
> +
> +				gnt_list_entry->pfn =
> +					page_to_pfn(granted_page);
> +				gnt_list_entry->gref = ref;
> +
> +				buffer_mfn = pfn_to_mfn(page_to_pfn(
> +								granted_page));
> +				gnttab_grant_foreign_access_ref(ref,
>  					info->xbdev->otherend_id,
> -					buffer_mfn,
> -					rq_data_dir(req));
> +					buffer_mfn, 0);
> +			}
> +
> +			info->shadow[id].grants_used[i] = gnt_list_entry;
> +
> +			if (rq_data_dir(req)) {
> +				char *bvec_data;
> +				void *shared_data;
> +
> +				BUG_ON(sg->offset + sg->length > PAGE_SIZE);
> +
> +				shared_data = kmap_atomic(
> +					pfn_to_page(gnt_list_entry->pfn));
> +				bvec_data = kmap_atomic(sg_page(sg));
> +
> +				/*
> +				 * this does not wipe data stored outside the
> +				 * range sg->offset..sg->offset+sg->length.
> +				 * Therefore, blkback *could* see data from
> +				 * previous requests. This is OK as long as
> +				 * persistent grants are shared with just one
> +				 * domain. It may need refactoring if this
> +				 * changes
> +				 */
> +				memcpy(shared_data + sg->offset,
> +				       bvec_data   + sg->offset,
> +				       sg->length);
> +
> +				kunmap_atomic(bvec_data);
> +				kunmap_atomic(shared_data);
> +			}
>  
>  			info->shadow[id].frame[i] = mfn_to_pfn(buffer_mfn);
>  			ring_req->u.rw.seg[i] =
> @@ -368,7 +449,8 @@ static int blkif_queue_request(struct request *req)
>  	/* Keep a private copy so we can reissue requests when recovering. */
>  	info->shadow[id].req = *ring_req;
>  
> -	gnttab_free_grant_references(gref_head);
> +	if (new_persistent_gnts)
> +		gnttab_free_grant_references(gref_head);
>  
>  	return 0;
>  }
> @@ -480,12 +562,13 @@ static int xlvbd_init_blk_queue(struct gendisk *gd, u16 sector_size)
>  static void xlvbd_flush(struct blkfront_info *info)
>  {
>  	blk_queue_flush(info->rq, info->feature_flush);
> -	printk(KERN_INFO "blkfront: %s: %s: %s\n",
> +	printk(KERN_INFO "blkfront: %s: %s: %s %s\n",
>  	       info->gd->disk_name,
>  	       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
>  		"barrier" : (info->flush_op == BLKIF_OP_FLUSH_DISKCACHE ?
>  		"flush diskcache" : "barrier or flush"),
> -	       info->feature_flush ? "enabled" : "disabled");
> +	       info->feature_flush ? "enabled" : "disabled",
> +	       info->feature_persistent ? "using persistent grants" : "");
>  }
>  
>  static int xen_translate_vdev(int vdevice, int *minor, unsigned int *offset)
> @@ -707,6 +790,9 @@ static void blkif_restart_queue(struct work_struct *work)
>  
>  static void blkif_free(struct blkfront_info *info, int suspend)
>  {
> +	struct llist_node *all_gnts;
> +	struct grant *persistent_gnt;
> +
>  	/* Prevent new requests being issued until we fix things up. */
>  	spin_lock_irq(&info->io_lock);
>  	info->connected = suspend ?
> @@ -714,6 +800,17 @@ static void blkif_free(struct blkfront_info *info, int suspend)
>  	/* No more blkif_request(). */
>  	if (info->rq)
>  		blk_stop_queue(info->rq);
> +
> +	/* Remove all persistent grants */
> +	if (info->persistent_gnts_c) {
> +		all_gnts = llist_del_all(&info->persistent_gnts);
> +		llist_for_each_entry(persistent_gnt, all_gnts, node) {
> +			gnttab_end_foreign_access(persistent_gnt->gref, 0, 0UL);
> +			kfree(persistent_gnt);
> +		}
> +		info->persistent_gnts_c = 0;
> +	}
> +
>  	/* No more gnttab callback work. */
>  	gnttab_cancel_free_callback(&info->callback);
>  	spin_unlock_irq(&info->io_lock);
> @@ -734,13 +831,42 @@ static void blkif_free(struct blkfront_info *info, int suspend)
>  
>  }
>  
> -static void blkif_completion(struct blk_shadow *s)
> +static void blkif_completion(struct blk_shadow *s, struct blkfront_info *info,
> +			     struct blkif_response *bret)
>  {
>  	int i;
> -	/* Do not let BLKIF_OP_DISCARD as nr_segment is in the same place
> -	 * flag. */
> -	for (i = 0; i < s->req.u.rw.nr_segments; i++)
> -		gnttab_end_foreign_access(s->req.u.rw.seg[i].gref, 0, 0UL);
> +	struct bio_vec *bvec;
> +	struct req_iterator iter;
> +	unsigned long flags;
> +	char *bvec_data;
> +	void *shared_data;
> +	unsigned int offset = 0;
> +
> +	if (bret->operation == BLKIF_OP_READ) {
> +		/*
> +		 * Copy the data received from the backend into the bvec.
> +		 * Since bv_offset can be different than 0, and bv_len different
> +		 * than PAGE_SIZE, we have to keep track of the current offset,
> +		 * to be sure we are copying the data from the right shared page.
> +		 */
> +		rq_for_each_segment(bvec, s->request, iter) {
> +			BUG_ON((bvec->bv_offset + bvec->bv_len) > PAGE_SIZE);
> +			i = offset >> PAGE_SHIFT;
> +			shared_data = kmap_atomic(
> +				pfn_to_page(s->grants_used[i]->pfn));
> +			bvec_data = bvec_kmap_irq(bvec, &flags);
> +			memcpy(bvec_data, shared_data + bvec->bv_offset,
> +				bvec->bv_len);
> +			bvec_kunmap_irq(bvec_data, &flags);
> +			kunmap_atomic(shared_data);
> +			offset += bvec->bv_len;
> +		}
> +	}
> +	/* Add the persistent grant into the list of free grants */
> +	for (i = 0; i < s->req.u.rw.nr_segments; i++) {
> +		llist_add(&s->grants_used[i]->node, &info->persistent_gnts);
> +		info->persistent_gnts_c++;
> +	}
>  }
>  
>  static irqreturn_t blkif_interrupt(int irq, void *dev_id)
> @@ -783,7 +909,7 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
>  		req  = info->shadow[id].request;
>  
>  		if (bret->operation != BLKIF_OP_DISCARD)
> -			blkif_completion(&info->shadow[id]);
> +			blkif_completion(&info->shadow[id], info, bret);
>  
>  		if (add_id_to_freelist(info, id)) {
>  			WARN(1, "%s: response to %s (id %ld) couldn't be recycled!\n",
> @@ -942,6 +1068,11 @@ again:
>  		message = "writing protocol";
>  		goto abort_transaction;
>  	}
> +	err = xenbus_printf(xbt, dev->nodename,
> +			    "feature-persistent-grants", "%u", 1);
> +	if (err)
> +		dev_warn(&dev->dev,
> +			 "writing persistent grants feature to xenbus");
>  
>  	err = xenbus_transaction_end(xbt, 0);
>  	if (err) {
> @@ -1029,6 +1160,8 @@ static int blkfront_probe(struct xenbus_device *dev,
>  	spin_lock_init(&info->io_lock);
>  	info->xbdev = dev;
>  	info->vdevice = vdevice;
> +	init_llist_head(&info->persistent_gnts);
> +	info->persistent_gnts_c = 0;
>  	info->connected = BLKIF_STATE_DISCONNECTED;
>  	INIT_WORK(&info->work, blkif_restart_queue);
>  
> @@ -1093,7 +1226,7 @@ static int blkif_recover(struct blkfront_info *info)
>  					req->u.rw.seg[j].gref,
>  					info->xbdev->otherend_id,
>  					pfn_to_mfn(info->shadow[req->u.rw.id].frame[j]),
> -					rq_data_dir(info->shadow[req->u.rw.id].request));
> +					0);
>  		}
>  		info->shadow[req->u.rw.id].req = *req;
>  
> @@ -1225,7 +1358,7 @@ static void blkfront_connect(struct blkfront_info *info)
>  	unsigned long sector_size;
>  	unsigned int binfo;
>  	int err;
> -	int barrier, flush, discard;
> +	int barrier, flush, discard, persistent;
>  
>  	switch (info->connected) {
>  	case BLKIF_STATE_CONNECTED:
> @@ -1303,6 +1436,14 @@ static void blkfront_connect(struct blkfront_info *info)
>  	if (!err && discard)
>  		blkfront_setup_discard(info);
>  
> +	err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
> +			    "feature-persistent", "%u", &persistent,
> +			    NULL);
> +	if (err)
> +		info->feature_persistent = 0;
> +	else
> +		info->feature_persistent = persistent;
> +
>  	err = xlvbd_alloc_gendisk(sectors, info, binfo, sector_size);
>  	if (err) {
>  		xenbus_dev_fatal(info->xbdev, err, "xlvbd_add at %s",
> -- 
> 1.7.7.5 (Apple Git-26)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 14:21:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 14:21:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSqD0-0003gJ-52; Mon, 29 Oct 2012 14:20:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSqCy-0003fL-77
	for xen-devel@lists.xensource.com; Mon, 29 Oct 2012 14:20:52 +0000
Received: from [193.109.254.147:52280] by server-16.bemta-14.messagelabs.com
	id B5/E1-09215-3C09E805; Mon, 29 Oct 2012 14:20:51 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1351520449!6189937!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODI4MTEw\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31303 invoked from network); 29 Oct 2012 14:20:50 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Oct 2012 14:20:50 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9TEKm9H017754
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 29 Oct 2012 14:20:48 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9TEKlSo028255
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 29 Oct 2012 14:20:47 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9TEKkVl019884; Mon, 29 Oct 2012 09:20:46 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 29 Oct 2012 07:20:46 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 3B631402E8; Mon, 29 Oct 2012 10:08:20 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Date: Mon, 29 Oct 2012 10:08:17 -0400
Message-Id: <1351519698-11069-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1351519698-11069-1-git-send-email-konrad.wilk@oracle.com>
References: <1351519698-11069-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Jan Beulich ,
	Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 1/2] xen/hypercall: fix hypercall fallback code
	for very old hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Jan Beulich 

While copying the argument structures in HYPERVISOR_event_channel_op()
and HYPERVISOR_physdev_op() into the local variable is sufficiently
safe even if the actual structure is smaller than the container one,
copying back eventual output values the same way isn't: This may
collide with on-stack variables (particularly "rc") which may change
between the first and second memcpy() (i.e. the second memcpy() could
discard that change).

Move the fallback code into out-of-line functions, and handle all of
the operations known by this old a hypervisor individually: Some don't
require copying back anything at all, and for the rest use the
individual argument structures' sizes rather than the container's.

Reported-by: Dan Carpenter 
Signed-off-by: Jan Beulich 
[v2: Reduce #define/#undef usage in HYPERVISOR_physdev_op_compat().]
Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/include/asm/xen/hypercall.h |   21 +++------
 drivers/xen/Makefile                 |    2 +-
 drivers/xen/fallback.c               |   78 ++++++++++++++++++++++++++++++++++
 3 files changed, 86 insertions(+), 15 deletions(-)
 create mode 100644 drivers/xen/fallback.c

diff --git a/arch/x86/include/asm/xen/hypercall.h b/arch/x86/include/asm/xen/hypercall.h
index 59c226d..c812360 100644
--- a/arch/x86/include/asm/xen/hypercall.h
+++ b/arch/x86/include/asm/xen/hypercall.h
@@ -359,18 +359,14 @@ HYPERVISOR_update_va_mapping(unsigned long va, pte_t new_val,
 		return _hypercall4(int, update_va_mapping, va,
 				   new_val.pte, new_val.pte >> 32, flags);
 }
+int __must_check HYPERVISOR_event_channel_op_compat(int, void *);
 
 static inline int
 HYPERVISOR_event_channel_op(int cmd, void *arg)
 {
 	int rc = _hypercall2(int, event_channel_op, cmd, arg);
-	if (unlikely(rc == -ENOSYS)) {
-		struct evtchn_op op;
-		op.cmd = cmd;
-		memcpy(&op.u, arg, sizeof(op.u));
-		rc = _hypercall1(int, event_channel_op_compat, &op);
-		memcpy(arg, &op.u, sizeof(op.u));
-	}
+	if (unlikely(rc == -ENOSYS))
+		rc = HYPERVISOR_event_channel_op_compat(cmd, arg);
 	return rc;
 }
 
@@ -386,17 +382,14 @@ HYPERVISOR_console_io(int cmd, int count, char *str)
 	return _hypercall3(int, console_io, cmd, count, str);
 }
 
+int __must_check HYPERVISOR_physdev_op_compat(int, void *);
+
 static inline int
 HYPERVISOR_physdev_op(int cmd, void *arg)
 {
 	int rc = _hypercall2(int, physdev_op, cmd, arg);
-	if (unlikely(rc == -ENOSYS)) {
-		struct physdev_op op;
-		op.cmd = cmd;
-		memcpy(&op.u, arg, sizeof(op.u));
-		rc = _hypercall1(int, physdev_op_compat, &op);
-		memcpy(arg, &op.u, sizeof(op.u));
-	}
+	if (unlikely(rc == -ENOSYS))
+		rc = HYPERVISOR_physdev_op_compat(cmd, arg);
 	return rc;
 }
 
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 0e863703..46de6cd 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -2,7 +2,7 @@ ifneq ($(CONFIG_ARM),y)
 obj-y	+= manage.o balloon.o
 obj-$(CONFIG_HOTPLUG_CPU)		+= cpu_hotplug.o
 endif
-obj-y	+= grant-table.o features.o events.o
+obj-y	+= grant-table.o features.o events.o fallback.o
 obj-y	+= xenbus/
 
 nostackp := $(call cc-option, -fno-stack-protector)
diff --git a/drivers/xen/fallback.c b/drivers/xen/fallback.c
new file mode 100644
index 0000000..0bdc468
--- /dev/null
+++ b/drivers/xen/fallback.c
@@ -0,0 +1,78 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+
+int HYPERVISOR_event_channel_op_compat(int cmd, void *arg)
+{
+	struct evtchn_op op;
+	int rc;
+
+	op.cmd = cmd;
+	memcpy(&op.u, arg, sizeof(op.u));
+	rc = _hypercall1(int, event_channel_op_compat, &op);
+
+	switch (cmd) {
+	case EVTCHNOP_close:
+	case EVTCHNOP_send:
+	case EVTCHNOP_bind_vcpu:
+	case EVTCHNOP_unmask:
+		/* no output */
+		break;
+
+#define COPY_BACK(eop) \
+	case EVTCHNOP_##eop: \
+		memcpy(arg, &op.u.eop, sizeof(op.u.eop)); \
+		break
+
+	COPY_BACK(bind_interdomain);
+	COPY_BACK(bind_virq);
+	COPY_BACK(bind_pirq);
+	COPY_BACK(status);
+	COPY_BACK(alloc_unbound);
+	COPY_BACK(bind_ipi);
+#undef COPY_BACK
+
+	default:
+		WARN_ON(rc != -ENOSYS);
+		break;
+	}
+
+	return rc;
+}
+
+int HYPERVISOR_physdev_op_compat(int cmd, void *arg)
+{
+	struct physdev_op op;
+	int rc;
+
+	op.cmd = cmd;
+	memcpy(&op.u, arg, sizeof(op.u));
+	rc = _hypercall1(int, physdev_op_compat, &op);
+
+	switch (cmd) {
+	case PHYSDEVOP_IRQ_UNMASK_NOTIFY:
+	case PHYSDEVOP_set_iopl:
+	case PHYSDEVOP_set_iobitmap:
+	case PHYSDEVOP_apic_write:
+		/* no output */
+		break;
+
+#define COPY_BACK(pop, fld) \
+	case PHYSDEVOP_##pop: \
+		memcpy(arg, &op.u.fld, sizeof(op.u.fld)); \
+		break
+
+	COPY_BACK(irq_status_query, irq_status_query);
+	COPY_BACK(apic_read, apic_op);
+	COPY_BACK(ASSIGN_VECTOR, irq_op);
+#undef COPY_BACK
+
+	default:
+		WARN_ON(rc != -ENOSYS);
+		break;
+	}
+
+	return rc;
+}
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 14:21:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 14:21:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSqD0-0003gJ-52; Mon, 29 Oct 2012 14:20:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSqCy-0003fL-77
	for xen-devel@lists.xensource.com; Mon, 29 Oct 2012 14:20:52 +0000
Received: from [193.109.254.147:52280] by server-16.bemta-14.messagelabs.com
	id B5/E1-09215-3C09E805; Mon, 29 Oct 2012 14:20:51 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1351520449!6189937!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODI4MTEw\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31303 invoked from network); 29 Oct 2012 14:20:50 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Oct 2012 14:20:50 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9TEKm9H017754
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 29 Oct 2012 14:20:48 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9TEKlSo028255
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 29 Oct 2012 14:20:47 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9TEKkVl019884; Mon, 29 Oct 2012 09:20:46 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 29 Oct 2012 07:20:46 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 3B631402E8; Mon, 29 Oct 2012 10:08:20 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Date: Mon, 29 Oct 2012 10:08:17 -0400
Message-Id: <1351519698-11069-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1351519698-11069-1-git-send-email-konrad.wilk@oracle.com>
References: <1351519698-11069-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Jan Beulich ,
	Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 1/2] xen/hypercall: fix hypercall fallback code
	for very old hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Jan Beulich 

While copying the argument structures in HYPERVISOR_event_channel_op()
and HYPERVISOR_physdev_op() into the local variable is sufficiently
safe even if the actual structure is smaller than the container one,
copying back eventual output values the same way isn't: This may
collide with on-stack variables (particularly "rc") which may change
between the first and second memcpy() (i.e. the second memcpy() could
discard that change).

Move the fallback code into out-of-line functions, and handle all of
the operations known by this old a hypervisor individually: Some don't
require copying back anything at all, and for the rest use the
individual argument structures' sizes rather than the container's.

Reported-by: Dan Carpenter 
Signed-off-by: Jan Beulich 
[v2: Reduce #define/#undef usage in HYPERVISOR_physdev_op_compat().]
Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/include/asm/xen/hypercall.h |   21 +++------
 drivers/xen/Makefile                 |    2 +-
 drivers/xen/fallback.c               |   78 ++++++++++++++++++++++++++++++++++
 3 files changed, 86 insertions(+), 15 deletions(-)
 create mode 100644 drivers/xen/fallback.c

diff --git a/arch/x86/include/asm/xen/hypercall.h b/arch/x86/include/asm/xen/hypercall.h
index 59c226d..c812360 100644
--- a/arch/x86/include/asm/xen/hypercall.h
+++ b/arch/x86/include/asm/xen/hypercall.h
@@ -359,18 +359,14 @@ HYPERVISOR_update_va_mapping(unsigned long va, pte_t new_val,
 		return _hypercall4(int, update_va_mapping, va,
 				   new_val.pte, new_val.pte >> 32, flags);
 }
+int __must_check HYPERVISOR_event_channel_op_compat(int, void *);
 
 static inline int
 HYPERVISOR_event_channel_op(int cmd, void *arg)
 {
 	int rc = _hypercall2(int, event_channel_op, cmd, arg);
-	if (unlikely(rc == -ENOSYS)) {
-		struct evtchn_op op;
-		op.cmd = cmd;
-		memcpy(&op.u, arg, sizeof(op.u));
-		rc = _hypercall1(int, event_channel_op_compat, &op);
-		memcpy(arg, &op.u, sizeof(op.u));
-	}
+	if (unlikely(rc == -ENOSYS))
+		rc = HYPERVISOR_event_channel_op_compat(cmd, arg);
 	return rc;
 }
 
@@ -386,17 +382,14 @@ HYPERVISOR_console_io(int cmd, int count, char *str)
 	return _hypercall3(int, console_io, cmd, count, str);
 }
 
+int __must_check HYPERVISOR_physdev_op_compat(int, void *);
+
 static inline int
 HYPERVISOR_physdev_op(int cmd, void *arg)
 {
 	int rc = _hypercall2(int, physdev_op, cmd, arg);
-	if (unlikely(rc == -ENOSYS)) {
-		struct physdev_op op;
-		op.cmd = cmd;
-		memcpy(&op.u, arg, sizeof(op.u));
-		rc = _hypercall1(int, physdev_op_compat, &op);
-		memcpy(arg, &op.u, sizeof(op.u));
-	}
+	if (unlikely(rc == -ENOSYS))
+		rc = HYPERVISOR_physdev_op_compat(cmd, arg);
 	return rc;
 }
 
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 0e863703..46de6cd 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -2,7 +2,7 @@ ifneq ($(CONFIG_ARM),y)
 obj-y	+= manage.o balloon.o
 obj-$(CONFIG_HOTPLUG_CPU)		+= cpu_hotplug.o
 endif
-obj-y	+= grant-table.o features.o events.o
+obj-y	+= grant-table.o features.o events.o fallback.o
 obj-y	+= xenbus/
 
 nostackp := $(call cc-option, -fno-stack-protector)
diff --git a/drivers/xen/fallback.c b/drivers/xen/fallback.c
new file mode 100644
index 0000000..0bdc468
--- /dev/null
+++ b/drivers/xen/fallback.c
@@ -0,0 +1,78 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+
+int HYPERVISOR_event_channel_op_compat(int cmd, void *arg)
+{
+	struct evtchn_op op;
+	int rc;
+
+	op.cmd = cmd;
+	memcpy(&op.u, arg, sizeof(op.u));
+	rc = _hypercall1(int, event_channel_op_compat, &op);
+
+	switch (cmd) {
+	case EVTCHNOP_close:
+	case EVTCHNOP_send:
+	case EVTCHNOP_bind_vcpu:
+	case EVTCHNOP_unmask:
+		/* no output */
+		break;
+
+#define COPY_BACK(eop) \
+	case EVTCHNOP_##eop: \
+		memcpy(arg, &op.u.eop, sizeof(op.u.eop)); \
+		break
+
+	COPY_BACK(bind_interdomain);
+	COPY_BACK(bind_virq);
+	COPY_BACK(bind_pirq);
+	COPY_BACK(status);
+	COPY_BACK(alloc_unbound);
+	COPY_BACK(bind_ipi);
+#undef COPY_BACK
+
+	default:
+		WARN_ON(rc != -ENOSYS);
+		break;
+	}
+
+	return rc;
+}
+
+int HYPERVISOR_physdev_op_compat(int cmd, void *arg)
+{
+	struct physdev_op op;
+	int rc;
+
+	op.cmd = cmd;
+	memcpy(&op.u, arg, sizeof(op.u));
+	rc = _hypercall1(int, physdev_op_compat, &op);
+
+	switch (cmd) {
+	case PHYSDEVOP_IRQ_UNMASK_NOTIFY:
+	case PHYSDEVOP_set_iopl:
+	case PHYSDEVOP_set_iobitmap:
+	case PHYSDEVOP_apic_write:
+		/* no output */
+		break;
+
+#define COPY_BACK(pop, fld) \
+	case PHYSDEVOP_##pop: \
+		memcpy(arg, &op.u.fld, sizeof(op.u.fld)); \
+		break
+
+	COPY_BACK(irq_status_query, irq_status_query);
+	COPY_BACK(apic_read, apic_op);
+	COPY_BACK(ASSIGN_VECTOR, irq_op);
+#undef COPY_BACK
+
+	default:
+		WARN_ON(rc != -ENOSYS);
+		break;
+	}
+
+	return rc;
+}
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 14:21:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 14:21:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSqD0-0003gQ-HJ; Mon, 29 Oct 2012 14:20:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSqCz-0003fS-4q
	for xen-devel@lists.xensource.com; Mon, 29 Oct 2012 14:20:53 +0000
Received: from [193.109.254.147:52368] by server-8.bemta-14.messagelabs.com id
	8E/34-16549-4C09E805; Mon, 29 Oct 2012 14:20:52 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1351520449!8842088!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4088 invoked from network); 29 Oct 2012 14:20:51 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Oct 2012 14:20:51 -0000
Received: from ucsinet21.oracle.com ([156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9TEKmAt026147
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 29 Oct 2012 14:20:49 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9TEKlaW021302
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 29 Oct 2012 14:20:47 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9TEKkYD032511; Mon, 29 Oct 2012 09:20:46 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 29 Oct 2012 07:20:46 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 40AEA4042F; Mon, 29 Oct 2012 10:08:20 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Date: Mon, 29 Oct 2012 10:08:18 -0400
Message-Id: <1351519698-11069-3-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1351519698-11069-1-git-send-email-konrad.wilk@oracle.com>
References: <1351519698-11069-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: [156.151.31.93]
Cc: Jan Beulich ,
	Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 2/2] xen/xenbus: fix overflow check in
	xenbus_file_write()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Jan Beulich 

Acked-by: Ian Campbell 
Reported-by: Dan Carpenter 
Signed-off-by: Jan Beulich 
[v1: Rebased on upstream]
Signed-off-by: Konrad Rzeszutek Wilk 
---
 drivers/xen/xenbus/xenbus_dev_frontend.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_dev_frontend.c b/drivers/xen/xenbus/xenbus_dev_frontend.c
index 89f7625..ac72702 100644
--- a/drivers/xen/xenbus/xenbus_dev_frontend.c
+++ b/drivers/xen/xenbus/xenbus_dev_frontend.c
@@ -458,7 +458,7 @@ static ssize_t xenbus_file_write(struct file *filp,
 		goto out;
 
 	/* Can't write a xenbus message larger we can buffer */
-	if ((len + u->len) > sizeof(u->u.buffer)) {
+	if (len > sizeof(u->u.buffer) - u->len) {
 		/* On error, dump existing buffer */
 		u->len = 0;
 		rc = -EINVAL;
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 14:21:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 14:21:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSqD0-0003gQ-HJ; Mon, 29 Oct 2012 14:20:54 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSqCz-0003fS-4q
	for xen-devel@lists.xensource.com; Mon, 29 Oct 2012 14:20:53 +0000
Received: from [193.109.254.147:52368] by server-8.bemta-14.messagelabs.com id
	8E/34-16549-4C09E805; Mon, 29 Oct 2012 14:20:52 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1351520449!8842088!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4088 invoked from network); 29 Oct 2012 14:20:51 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Oct 2012 14:20:51 -0000
Received: from ucsinet21.oracle.com ([156.151.31.93])
	by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9TEKmAt026147
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 29 Oct 2012 14:20:49 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9TEKlaW021302
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 29 Oct 2012 14:20:47 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9TEKkYD032511; Mon, 29 Oct 2012 09:20:46 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 29 Oct 2012 07:20:46 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 40AEA4042F; Mon, 29 Oct 2012 10:08:20 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Date: Mon, 29 Oct 2012 10:08:18 -0400
Message-Id: <1351519698-11069-3-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1351519698-11069-1-git-send-email-konrad.wilk@oracle.com>
References: <1351519698-11069-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: [156.151.31.93]
Cc: Jan Beulich ,
	Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH 2/2] xen/xenbus: fix overflow check in
	xenbus_file_write()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: Jan Beulich 

Acked-by: Ian Campbell 
Reported-by: Dan Carpenter 
Signed-off-by: Jan Beulich 
[v1: Rebased on upstream]
Signed-off-by: Konrad Rzeszutek Wilk 
---
 drivers/xen/xenbus/xenbus_dev_frontend.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_dev_frontend.c b/drivers/xen/xenbus/xenbus_dev_frontend.c
index 89f7625..ac72702 100644
--- a/drivers/xen/xenbus/xenbus_dev_frontend.c
+++ b/drivers/xen/xenbus/xenbus_dev_frontend.c
@@ -458,7 +458,7 @@ static ssize_t xenbus_file_write(struct file *filp,
 		goto out;
 
 	/* Can't write a xenbus message larger we can buffer */
-	if ((len + u->len) > sizeof(u->u.buffer)) {
+	if (len > sizeof(u->u.buffer) - u->len) {
 		/* On error, dump existing buffer */
 		u->len = 0;
 		rc = -EINVAL;
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 14:21:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 14:21:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSqCz-0003fc-PN; Mon, 29 Oct 2012 14:20:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSqCx-0003fK-VG
	for xen-devel@lists.xensource.com; Mon, 29 Oct 2012 14:20:52 +0000
Received: from [85.158.139.211:42417] by server-12.bemta-5.messagelabs.com id
	32/7D-26919-3C09E805; Mon, 29 Oct 2012 14:20:51 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1351520448!16546424!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNDQxNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17657 invoked from network); 29 Oct 2012 14:20:50 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Oct 2012 14:20:50 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9TEKliY026728
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 29 Oct 2012 14:20:48 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9TEKkH9011010
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 29 Oct 2012 14:20:47 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9TEKkrE030214; Mon, 29 Oct 2012 09:20:46 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 29 Oct 2012 07:20:46 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 3565D4042E; Mon, 29 Oct 2012 10:08:20 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Date: Mon, 29 Oct 2012 10:08:16 -0400
Message-Id: <1351519698-11069-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Subject: [Xen-devel] [PATCH v1] Bug-fixes for v3.7 back-ported from Jan's
	postings.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

These are back-ports from the ones that Jan posted. Please
take a look  - I might have missed an email about one of the patches
and I can't find it my mailbox :-(

Either way, was thinking to put these in v3.7.

 arch/x86/include/asm/xen/hypercall.h     |   21 +++-----
 drivers/xen/Makefile                     |    2 +-
 drivers/xen/fallback.c                   |   78 ++++++++++++++++++++++++++++++
 drivers/xen/xenbus/xenbus_dev_frontend.c |    2 +-
 4 files changed, 87 insertions(+), 16 deletions(-)


Jan Beulich (2):
      xen/hypercall: fix hypercall fallback code for very old hypervisors
      xen/xenbus: fix overflow check in xenbus_file_write()


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 14:21:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 14:21:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSqCz-0003fc-PN; Mon, 29 Oct 2012 14:20:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSqCx-0003fK-VG
	for xen-devel@lists.xensource.com; Mon, 29 Oct 2012 14:20:52 +0000
Received: from [85.158.139.211:42417] by server-12.bemta-5.messagelabs.com id
	32/7D-26919-3C09E805; Mon, 29 Oct 2012 14:20:51 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1351520448!16546424!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNDQxNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17657 invoked from network); 29 Oct 2012 14:20:50 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Oct 2012 14:20:50 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9TEKliY026728
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 29 Oct 2012 14:20:48 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9TEKkH9011010
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 29 Oct 2012 14:20:47 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9TEKkrE030214; Mon, 29 Oct 2012 09:20:46 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 29 Oct 2012 07:20:46 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 3565D4042E; Mon, 29 Oct 2012 10:08:20 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Date: Mon, 29 Oct 2012 10:08:16 -0400
Message-Id: <1351519698-11069-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Subject: [Xen-devel] [PATCH v1] Bug-fixes for v3.7 back-ported from Jan's
	postings.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

These are back-ports from the ones that Jan posted. Please
take a look  - I might have missed an email about one of the patches
and I can't find it my mailbox :-(

Either way, was thinking to put these in v3.7.

 arch/x86/include/asm/xen/hypercall.h     |   21 +++-----
 drivers/xen/Makefile                     |    2 +-
 drivers/xen/fallback.c                   |   78 ++++++++++++++++++++++++++++++
 drivers/xen/xenbus/xenbus_dev_frontend.c |    2 +-
 4 files changed, 87 insertions(+), 16 deletions(-)


Jan Beulich (2):
      xen/hypercall: fix hypercall fallback code for very old hypervisors
      xen/xenbus: fix overflow check in xenbus_file_write()


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 14:33:12 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 14:33:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSqOg-00047h-QQ; Mon, 29 Oct 2012 14:32:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSqOf-00047c-5l
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 14:32:57 +0000
Received: from [85.158.137.99:61156] by server-5.bemta-3.messagelabs.com id
	6F/62-12440-7939E805; Mon, 29 Oct 2012 14:32:55 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1351521173!21102975!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27228 invoked from network); 29 Oct 2012 14:32:55 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-15.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Oct 2012 14:32:55 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9TEWp01005579
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 29 Oct 2012 14:32:51 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9TEWoRM007351
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 29 Oct 2012 14:32:51 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9TEWogV009855; Mon, 29 Oct 2012 09:32:50 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 29 Oct 2012 07:32:50 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D85164042D; Mon, 29 Oct 2012 10:20:23 -0400 (EDT)
Date: Mon, 29 Oct 2012 10:20:23 -0400
From: Konrad Rzeszutek Wilk 
To: Ian Campbell 
Message-ID: <20121029142023.GB2708@phenom.dumpdata.com>
References: <1351084756.18035.28.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1351084756.18035.28.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Stefano Stabellini ,
	linux-kernel ,
	xen-devel 
Subject: Re: [Xen-devel] [PATCH+GIT V3 0/5] arm: implement ballooning and
 privcmd foreign mappings based on x86 PVH
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 24, 2012 at 02:19:16PM +0100, Ian Campbell wrote:
> This is rebased onto 0e9e3e306c7e (AKA current Linus, which now includes
> the previously prerequisite series "xen: build fixes and interface
> tweaks") and Konrad's stable/pvh.v5 branch.
> 
> For convenience I've also pushed to 
>         git://xenbits.xen.org/people/ianc/linux.git
>         arm-privcmd-on-x86-pvh5
> Note that this contains my merge of Konrad's branch into Linus' tree at
> the base. You might want to cherry pick it rather than merge it.

Applied them and stuck them in 'devel/pvh.v6' - which is based on v3.7-rc3.

Will test them overnight.
> 
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 14:33:12 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 14:33:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSqOg-00047h-QQ; Mon, 29 Oct 2012 14:32:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSqOf-00047c-5l
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 14:32:57 +0000
Received: from [85.158.137.99:61156] by server-5.bemta-3.messagelabs.com id
	6F/62-12440-7939E805; Mon, 29 Oct 2012 14:32:55 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1351521173!21102975!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27228 invoked from network); 29 Oct 2012 14:32:55 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-15.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Oct 2012 14:32:55 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9TEWp01005579
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 29 Oct 2012 14:32:51 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9TEWoRM007351
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 29 Oct 2012 14:32:51 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9TEWogV009855; Mon, 29 Oct 2012 09:32:50 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 29 Oct 2012 07:32:50 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D85164042D; Mon, 29 Oct 2012 10:20:23 -0400 (EDT)
Date: Mon, 29 Oct 2012 10:20:23 -0400
From: Konrad Rzeszutek Wilk 
To: Ian Campbell 
Message-ID: <20121029142023.GB2708@phenom.dumpdata.com>
References: <1351084756.18035.28.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1351084756.18035.28.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Stefano Stabellini ,
	linux-kernel ,
	xen-devel 
Subject: Re: [Xen-devel] [PATCH+GIT V3 0/5] arm: implement ballooning and
 privcmd foreign mappings based on x86 PVH
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 24, 2012 at 02:19:16PM +0100, Ian Campbell wrote:
> This is rebased onto 0e9e3e306c7e (AKA current Linus, which now includes
> the previously prerequisite series "xen: build fixes and interface
> tweaks") and Konrad's stable/pvh.v5 branch.
> 
> For convenience I've also pushed to 
>         git://xenbits.xen.org/people/ianc/linux.git
>         arm-privcmd-on-x86-pvh5
> Note that this contains my merge of Konrad's branch into Linus' tree at
> the base. You might want to cherry pick it rather than merge it.

Applied them and stuck them in 'devel/pvh.v6' - which is based on v3.7-rc3.

Will test them overnight.
> 
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 15:22:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 15:22:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSr9p-0004SO-Pf; Mon, 29 Oct 2012 15:21:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSr9o-0004SJ-7d
	for xen-devel@lists.xensource.com; Mon, 29 Oct 2012 15:21:40 +0000
Received: from [85.158.139.83:34737] by server-4.bemta-5.messagelabs.com id
	9D/22-01455-30F9E805; Mon, 29 Oct 2012 15:21:39 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1351524096!27799500!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzYwNDMx\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22567 invoked from network); 29 Oct 2012 15:21:37 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-2.tower-182.messagelabs.com with SMTP;
	29 Oct 2012 15:21:37 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 29 Oct 2012 08:21:06 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,672,1344236400"; d="scan'208";a="212512669"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by orsmga001.jf.intel.com with ESMTP; 29 Oct 2012 08:21:35 -0700
Received: from fmsmsx101.amr.corp.intel.com (10.19.9.52) by
	FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 29 Oct 2012 08:21:34 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX101.amr.corp.intel.com (10.19.9.52) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 29 Oct 2012 08:21:34 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.186]) with mapi id
	14.01.0355.002; Mon, 29 Oct 2012 23:21:31 +0800
From: "Liu, Jinsong" 
To: George Dunlap , Ian Jackson
	
Thread-Topic: [Patch 4/5] X86/vMCE: handle broken page occurred before
	migration
Thread-Index: AQHNsEjdaBRa8rOqkUOTeDJn2J5LNJfQcOeQ
Date: Mon, 29 Oct 2012 15:21:31 +0000
Message-ID: 
References: 
	
	
	<50852EB6.4060705@eu.citrix.com>
In-Reply-To: <50852EB6.4060705@eu.citrix.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC8292335374280SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	Jan Beulich 
Subject: [Xen-devel] [Patch 4/5] X86/vMCE: handle broken page occurred
	before migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC8292335374280SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

X86/vMCE: handle broken page occurred before migration

This patch handles guest broken page which occur before migration.

At sender, the broken page would be mapped but not copied to target
(otherwise it may trigger more serious error, say, SRAR error).
While its pfn_type and pfn number would be transferred to target
so that target take appropriate action.

At target, it would set p2m as p2m_ram_broken for broken page, so that
if guest access the broken page again, it would kill itself as expected.

Signed-off-by: Liu, Jinsong 

diff -r e27a6d53ac15 tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c	Thu Oct 11 01:52:33 2012 +0800
+++ b/tools/libxc/xc_domain.c	Thu Oct 25 05:49:10 2012 +0800
@@ -283,6 +283,22 @@
     return ret;
 }
=20
+/* set broken page p2m */
+int xc_set_broken_page_p2m(xc_interface *xch,
+                           uint32_t domid,
+                           unsigned long pfn)
+{
+    int ret;
+    DECLARE_DOMCTL;
+
+    domctl.cmd =3D XEN_DOMCTL_set_broken_page_p2m;
+    domctl.domain =3D (domid_t)domid;
+    domctl.u.set_broken_page_p2m.pfn =3D pfn;
+    ret =3D do_domctl(xch, &domctl);
+
+    return ret ? -1 : 0;
+}
+
 /* get info from hvm guest for save */
 int xc_domain_hvm_getcontext(xc_interface *xch,
                              uint32_t domid,
diff -r e27a6d53ac15 tools/libxc/xc_domain_restore.c
--- a/tools/libxc/xc_domain_restore.c	Thu Oct 11 01:52:33 2012 +0800
+++ b/tools/libxc/xc_domain_restore.c	Thu Oct 25 05:49:10 2012 +0800
@@ -962,9 +962,15 @@
=20
     countpages =3D count;
     for (i =3D oldcount; i < buf->nr_pages; ++i)
-        if ((buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) =3D=3D XEN_D=
OMCTL_PFINFO_XTAB
-            ||(buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) =3D=3D XEN=
_DOMCTL_PFINFO_XALLOC)
+    {
+        unsigned long pagetype;
+
+        pagetype =3D buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK;
+        if ( pagetype =3D=3D XEN_DOMCTL_PFINFO_XTAB ||
+             pagetype =3D=3D XEN_DOMCTL_PFINFO_BROKEN ||
+             pagetype =3D=3D XEN_DOMCTL_PFINFO_XALLOC )
             --countpages;
+    }
=20
     if (!countpages)
         return count;
@@ -1200,6 +1206,17 @@
             /* a bogus/unmapped/allocate-only page: skip it */
             continue;
=20
+        if ( pagetype =3D=3D XEN_DOMCTL_PFINFO_BROKEN )
+        {
+            if ( xc_set_broken_page_p2m(xch, dom, pfn) )
+            {
+                ERROR("Set p2m for broken page failed, "
+                      "dom=3D%d, pfn=3D%lx\n", dom, pfn);
+                goto err_mapped;
+            }
+            continue;
+        }
+
         if (pfn_err[i])
         {
             ERROR("unexpected PFN mapping failure pfn %lx map_mfn %lx p2m_=
mfn %lx",
diff -r e27a6d53ac15 tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Thu Oct 11 01:52:33 2012 +0800
+++ b/tools/libxc/xc_domain_save.c	Thu Oct 25 05:49:10 2012 +0800
@@ -1277,6 +1277,13 @@
                 if ( !hvm )
                     gmfn =3D pfn_to_mfn(gmfn);
=20
+                if ( pfn_type[j] =3D=3D XEN_DOMCTL_PFINFO_BROKEN )
+                {
+                    pfn_type[j] |=3D pfn_batch[j];
+                    ++run;
+                    continue;
+                }
+
                 if ( pfn_err[j] )
                 {
                     if ( pfn_type[j] =3D=3D XEN_DOMCTL_PFINFO_XTAB )
@@ -1371,8 +1378,12 @@
                     }
                 }
=20
-                /* skip pages that aren't present or are alloc-only */
+                /*
+                 * skip pages that aren't present,
+                 * or are broken, or are alloc-only
+                 */
                 if ( pagetype =3D=3D XEN_DOMCTL_PFINFO_XTAB
+                    || pagetype =3D=3D XEN_DOMCTL_PFINFO_BROKEN
                     || pagetype =3D=3D XEN_DOMCTL_PFINFO_XALLOC )
                     continue;
=20
diff -r e27a6d53ac15 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Thu Oct 11 01:52:33 2012 +0800
+++ b/tools/libxc/xenctrl.h	Thu Oct 25 05:49:10 2012 +0800
@@ -575,6 +575,17 @@
                           xc_domaininfo_t *info);
=20
 /**
+ * This function set p2m for broken page
+ * &parm xch a handle to an open hypervisor interface
+ * @parm domid the domain id which broken page belong to
+ * @parm pfn the pfn number of the broken page
+ * @return 0 on success, -1 on failure
+ */
+int xc_set_broken_page_p2m(xc_interface *xch,
+                           uint32_t domid,
+                           unsigned long pfn);
+
+/**
  * This function returns information about the context of a hvm domain
  * @parm xch a handle to an open hypervisor interface
  * @parm domid the domain to get information from
diff -r e27a6d53ac15 xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c	Thu Oct 11 01:52:33 2012 +0800
+++ b/xen/arch/x86/domctl.c	Thu Oct 25 05:49:10 2012 +0800
@@ -209,12 +209,18 @@
                 for ( j =3D 0; j < k; j++ )
                 {
                     unsigned long type =3D 0;
+                    p2m_type_t t;
=20
-                    page =3D get_page_from_gfn(d, arr[j], NULL, P2M_ALLOC)=
;
+                    page =3D get_page_from_gfn(d, arr[j], &t, P2M_ALLOC);
=20
                     if ( unlikely(!page) ||
                          unlikely(is_xen_heap_page(page)) )
-                        type =3D XEN_DOMCTL_PFINFO_XTAB;
+                    {
+                        if ( p2m_is_broken(t) )
+                            type =3D XEN_DOMCTL_PFINFO_BROKEN;
+                        else
+                            type =3D XEN_DOMCTL_PFINFO_XTAB;
+                    }
                     else
                     {
                         switch( page->u.inuse.type_info & PGT_type_mask )
@@ -235,6 +241,9 @@
=20
                         if ( page->u.inuse.type_info & PGT_pinned )
                             type |=3D XEN_DOMCTL_PFINFO_LPINTAB;
+
+                        if ( page->count_info & PGC_broken )
+                            type =3D XEN_DOMCTL_PFINFO_BROKEN;
                     }
=20
                     if ( page )
@@ -1568,6 +1577,28 @@
     }
     break;
=20
+    case XEN_DOMCTL_set_broken_page_p2m:
+    {
+        struct domain *d;
+        p2m_type_t pt;
+        unsigned long pfn;
+
+        d =3D rcu_lock_domain_by_id(domctl->domain);
+        if ( d !=3D NULL )
+        {
+            pfn =3D domctl->u.set_broken_page_p2m.pfn;
+
+            get_gfn_query(d, pfn, &pt);
+            p2m_change_type(d, pfn, pt, p2m_ram_broken);
+            put_gfn(d, pfn);
+
+            rcu_unlock_domain(d);
+        }
+        else
+            ret =3D -ESRCH;
+    }
+    break;
+
     default:
         ret =3D iommu_do_domctl(domctl, u_domctl);
         break;
diff -r e27a6d53ac15 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h	Thu Oct 11 01:52:33 2012 +0800
+++ b/xen/include/public/domctl.h	Thu Oct 25 05:49:10 2012 +0800
@@ -136,6 +136,7 @@
 #define XEN_DOMCTL_PFINFO_LPINTAB (0x1U<<31)
 #define XEN_DOMCTL_PFINFO_XTAB    (0xfU<<28) /* invalid page */
 #define XEN_DOMCTL_PFINFO_XALLOC  (0xeU<<28) /* allocate-only page */
+#define XEN_DOMCTL_PFINFO_BROKEN  (0xdU<<28) /* broken page */
 #define XEN_DOMCTL_PFINFO_PAGEDTAB (0x8U<<28)
 #define XEN_DOMCTL_PFINFO_LTAB_MASK (0xfU<<28)
=20
@@ -835,6 +836,12 @@
 typedef struct xen_domctl_set_access_required xen_domctl_set_access_requir=
ed_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_access_required_t);
=20
+struct xen_domctl_set_broken_page_p2m {
+    uint64_aligned_t pfn;
+};
+typedef struct xen_domctl_set_broken_page_p2m xen_domctl_set_broken_page_p=
2m_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_broken_page_p2m_t);
+
 struct xen_domctl {
     uint32_t cmd;
 #define XEN_DOMCTL_createdomain                   1
@@ -900,6 +907,7 @@
 #define XEN_DOMCTL_set_access_required           64
 #define XEN_DOMCTL_audit_p2m                     65
 #define XEN_DOMCTL_set_virq_handler              66
+#define XEN_DOMCTL_set_broken_page_p2m           67
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -955,6 +963,7 @@
         struct xen_domctl_audit_p2m         audit_p2m;
         struct xen_domctl_set_virq_handler  set_virq_handler;
         struct xen_domctl_gdbsx_memio       gdbsx_guest_memio;
+        struct xen_domctl_set_broken_page_p2m set_broken_page_p2m;
         struct xen_domctl_gdbsx_pauseunp_vcpu gdbsx_pauseunp_vcpu;
         struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
         uint8_t                             pad[128];=

--_002_DE8DF0795D48FD4CA783C40EC8292335374280SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="4_vmce_before_migration.patch"
Content-Description: 4_vmce_before_migration.patch
Content-Disposition: attachment; filename="4_vmce_before_migration.patch";
	size=8474; creation-date="Mon, 29 Oct 2012 15:18:32 GMT";
	modification-date="Mon, 29 Oct 2012 23:04:06 GMT"
Content-Transfer-Encoding: base64

WDg2L3ZNQ0U6IGhhbmRsZSBicm9rZW4gcGFnZSBvY2N1cnJlZCBiZWZvcmUgbWlncmF0aW9uCgpU
aGlzIHBhdGNoIGhhbmRsZXMgZ3Vlc3QgYnJva2VuIHBhZ2Ugd2hpY2ggb2NjdXIgYmVmb3JlIG1p
Z3JhdGlvbi4KCkF0IHNlbmRlciwgdGhlIGJyb2tlbiBwYWdlIHdvdWxkIGJlIG1hcHBlZCBidXQg
bm90IGNvcGllZCB0byB0YXJnZXQKKG90aGVyd2lzZSBpdCBtYXkgdHJpZ2dlciBtb3JlIHNlcmlv
dXMgZXJyb3IsIHNheSwgU1JBUiBlcnJvcikuCldoaWxlIGl0cyBwZm5fdHlwZSBhbmQgcGZuIG51
bWJlciB3b3VsZCBiZSB0cmFuc2ZlcnJlZCB0byB0YXJnZXQKc28gdGhhdCB0YXJnZXQgdGFrZSBh
cHByb3ByaWF0ZSBhY3Rpb24uCgpBdCB0YXJnZXQsIGl0IHdvdWxkIHNldCBwMm0gYXMgcDJtX3Jh
bV9icm9rZW4gZm9yIGJyb2tlbiBwYWdlLCBzbyB0aGF0CmlmIGd1ZXN0IGFjY2VzcyB0aGUgYnJv
a2VuIHBhZ2UgYWdhaW4sIGl0IHdvdWxkIGtpbGwgaXRzZWxmIGFzIGV4cGVjdGVkLgoKU2lnbmVk
LW9mZi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+CgpkaWZmIC1yIGUy
N2E2ZDUzYWMxNSB0b29scy9saWJ4Yy94Y19kb21haW4uYwotLS0gYS90b29scy9saWJ4Yy94Y19k
b21haW4uYwlUaHUgT2N0IDExIDAxOjUyOjMzIDIwMTIgKzA4MDAKKysrIGIvdG9vbHMvbGlieGMv
eGNfZG9tYWluLmMJVGh1IE9jdCAyNSAwNTo0OToxMCAyMDEyICswODAwCkBAIC0yODMsNiArMjgz
LDIyIEBACiAgICAgcmV0dXJuIHJldDsKIH0KIAorLyogc2V0IGJyb2tlbiBwYWdlIHAybSAqLwor
aW50IHhjX3NldF9icm9rZW5fcGFnZV9wMm0oeGNfaW50ZXJmYWNlICp4Y2gsCisgICAgICAgICAg
ICAgICAgICAgICAgICAgICB1aW50MzJfdCBkb21pZCwKKyAgICAgICAgICAgICAgICAgICAgICAg
ICAgIHVuc2lnbmVkIGxvbmcgcGZuKQoreworICAgIGludCByZXQ7CisgICAgREVDTEFSRV9ET01D
VEw7CisKKyAgICBkb21jdGwuY21kID0gWEVOX0RPTUNUTF9zZXRfYnJva2VuX3BhZ2VfcDJtOwor
ICAgIGRvbWN0bC5kb21haW4gPSAoZG9taWRfdClkb21pZDsKKyAgICBkb21jdGwudS5zZXRfYnJv
a2VuX3BhZ2VfcDJtLnBmbiA9IHBmbjsKKyAgICByZXQgPSBkb19kb21jdGwoeGNoLCAmZG9tY3Rs
KTsKKworICAgIHJldHVybiByZXQgPyAtMSA6IDA7Cit9CisKIC8qIGdldCBpbmZvIGZyb20gaHZt
IGd1ZXN0IGZvciBzYXZlICovCiBpbnQgeGNfZG9tYWluX2h2bV9nZXRjb250ZXh0KHhjX2ludGVy
ZmFjZSAqeGNoLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJfdCBkb21pZCwK
ZGlmZiAtciBlMjdhNmQ1M2FjMTUgdG9vbHMvbGlieGMveGNfZG9tYWluX3Jlc3RvcmUuYwotLS0g
YS90b29scy9saWJ4Yy94Y19kb21haW5fcmVzdG9yZS5jCVRodSBPY3QgMTEgMDE6NTI6MzMgMjAx
MiArMDgwMAorKysgYi90b29scy9saWJ4Yy94Y19kb21haW5fcmVzdG9yZS5jCVRodSBPY3QgMjUg
MDU6NDk6MTAgMjAxMiArMDgwMApAQCAtOTYyLDkgKzk2MiwxNSBAQAogCiAgICAgY291bnRwYWdl
cyA9IGNvdW50OwogICAgIGZvciAoaSA9IG9sZGNvdW50OyBpIDwgYnVmLT5ucl9wYWdlczsgKytp
KQotICAgICAgICBpZiAoKGJ1Zi0+cGZuX3R5cGVzW2ldICYgWEVOX0RPTUNUTF9QRklORk9fTFRB
Ql9NQVNLKSA9PSBYRU5fRE9NQ1RMX1BGSU5GT19YVEFCCi0gICAgICAgICAgICB8fChidWYtPnBm
bl90eXBlc1tpXSAmIFhFTl9ET01DVExfUEZJTkZPX0xUQUJfTUFTSykgPT0gWEVOX0RPTUNUTF9Q
RklORk9fWEFMTE9DKQorICAgIHsKKyAgICAgICAgdW5zaWduZWQgbG9uZyBwYWdldHlwZTsKKwor
ICAgICAgICBwYWdldHlwZSA9IGJ1Zi0+cGZuX3R5cGVzW2ldICYgWEVOX0RPTUNUTF9QRklORk9f
TFRBQl9NQVNLOworICAgICAgICBpZiAoIHBhZ2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX1hU
QUIgfHwKKyAgICAgICAgICAgICBwYWdldHlwZSA9PSBYRU5fRE9NQ1RMX1BGSU5GT19CUk9LRU4g
fHwKKyAgICAgICAgICAgICBwYWdldHlwZSA9PSBYRU5fRE9NQ1RMX1BGSU5GT19YQUxMT0MgKQog
ICAgICAgICAgICAgLS1jb3VudHBhZ2VzOworICAgIH0KIAogICAgIGlmICghY291bnRwYWdlcykK
ICAgICAgICAgcmV0dXJuIGNvdW50OwpAQCAtMTIwMCw2ICsxMjA2LDE3IEBACiAgICAgICAgICAg
ICAvKiBhIGJvZ3VzL3VubWFwcGVkL2FsbG9jYXRlLW9ubHkgcGFnZTogc2tpcCBpdCAqLwogICAg
ICAgICAgICAgY29udGludWU7CiAKKyAgICAgICAgaWYgKCBwYWdldHlwZSA9PSBYRU5fRE9NQ1RM
X1BGSU5GT19CUk9LRU4gKQorICAgICAgICB7CisgICAgICAgICAgICBpZiAoIHhjX3NldF9icm9r
ZW5fcGFnZV9wMm0oeGNoLCBkb20sIHBmbikgKQorICAgICAgICAgICAgeworICAgICAgICAgICAg
ICAgIEVSUk9SKCJTZXQgcDJtIGZvciBicm9rZW4gcGFnZSBmYWlsZWQsICIKKyAgICAgICAgICAg
ICAgICAgICAgICAiZG9tPSVkLCBwZm49JWx4XG4iLCBkb20sIHBmbik7CisgICAgICAgICAgICAg
ICAgZ290byBlcnJfbWFwcGVkOworICAgICAgICAgICAgfQorICAgICAgICAgICAgY29udGludWU7
CisgICAgICAgIH0KKwogICAgICAgICBpZiAocGZuX2VycltpXSkKICAgICAgICAgewogICAgICAg
ICAgICAgRVJST1IoInVuZXhwZWN0ZWQgUEZOIG1hcHBpbmcgZmFpbHVyZSBwZm4gJWx4IG1hcF9t
Zm4gJWx4IHAybV9tZm4gJWx4IiwKZGlmZiAtciBlMjdhNmQ1M2FjMTUgdG9vbHMvbGlieGMveGNf
ZG9tYWluX3NhdmUuYwotLS0gYS90b29scy9saWJ4Yy94Y19kb21haW5fc2F2ZS5jCVRodSBPY3Qg
MTEgMDE6NTI6MzMgMjAxMiArMDgwMAorKysgYi90b29scy9saWJ4Yy94Y19kb21haW5fc2F2ZS5j
CVRodSBPY3QgMjUgMDU6NDk6MTAgMjAxMiArMDgwMApAQCAtMTI3Nyw2ICsxMjc3LDEzIEBACiAg
ICAgICAgICAgICAgICAgaWYgKCAhaHZtICkKICAgICAgICAgICAgICAgICAgICAgZ21mbiA9IHBm
bl90b19tZm4oZ21mbik7CiAKKyAgICAgICAgICAgICAgICBpZiAoIHBmbl90eXBlW2pdID09IFhF
Tl9ET01DVExfUEZJTkZPX0JST0tFTiApCisgICAgICAgICAgICAgICAgeworICAgICAgICAgICAg
ICAgICAgICBwZm5fdHlwZVtqXSB8PSBwZm5fYmF0Y2hbal07CisgICAgICAgICAgICAgICAgICAg
ICsrcnVuOworICAgICAgICAgICAgICAgICAgICBjb250aW51ZTsKKyAgICAgICAgICAgICAgICB9
CisKICAgICAgICAgICAgICAgICBpZiAoIHBmbl9lcnJbal0gKQogICAgICAgICAgICAgICAgIHsK
ICAgICAgICAgICAgICAgICAgICAgaWYgKCBwZm5fdHlwZVtqXSA9PSBYRU5fRE9NQ1RMX1BGSU5G
T19YVEFCICkKQEAgLTEzNzEsOCArMTM3OCwxMiBAQAogICAgICAgICAgICAgICAgICAgICB9CiAg
ICAgICAgICAgICAgICAgfQogCi0gICAgICAgICAgICAgICAgLyogc2tpcCBwYWdlcyB0aGF0IGFy
ZW4ndCBwcmVzZW50IG9yIGFyZSBhbGxvYy1vbmx5ICovCisgICAgICAgICAgICAgICAgLyoKKyAg
ICAgICAgICAgICAgICAgKiBza2lwIHBhZ2VzIHRoYXQgYXJlbid0IHByZXNlbnQsCisgICAgICAg
ICAgICAgICAgICogb3IgYXJlIGJyb2tlbiwgb3IgYXJlIGFsbG9jLW9ubHkKKyAgICAgICAgICAg
ICAgICAgKi8KICAgICAgICAgICAgICAgICBpZiAoIHBhZ2V0eXBlID09IFhFTl9ET01DVExfUEZJ
TkZPX1hUQUIKKyAgICAgICAgICAgICAgICAgICAgfHwgcGFnZXR5cGUgPT0gWEVOX0RPTUNUTF9Q
RklORk9fQlJPS0VOCiAgICAgICAgICAgICAgICAgICAgIHx8IHBhZ2V0eXBlID09IFhFTl9ET01D
VExfUEZJTkZPX1hBTExPQyApCiAgICAgICAgICAgICAgICAgICAgIGNvbnRpbnVlOwogCmRpZmYg
LXIgZTI3YTZkNTNhYzE1IHRvb2xzL2xpYnhjL3hlbmN0cmwuaAotLS0gYS90b29scy9saWJ4Yy94
ZW5jdHJsLmgJVGh1IE9jdCAxMSAwMTo1MjozMyAyMDEyICswODAwCisrKyBiL3Rvb2xzL2xpYnhj
L3hlbmN0cmwuaAlUaHUgT2N0IDI1IDA1OjQ5OjEwIDIwMTIgKzA4MDAKQEAgLTU3NSw2ICs1NzUs
MTcgQEAKICAgICAgICAgICAgICAgICAgICAgICAgICAgeGNfZG9tYWluaW5mb190ICppbmZvKTsK
IAogLyoqCisgKiBUaGlzIGZ1bmN0aW9uIHNldCBwMm0gZm9yIGJyb2tlbiBwYWdlCisgKiAmcGFy
bSB4Y2ggYSBoYW5kbGUgdG8gYW4gb3BlbiBoeXBlcnZpc29yIGludGVyZmFjZQorICogQHBhcm0g
ZG9taWQgdGhlIGRvbWFpbiBpZCB3aGljaCBicm9rZW4gcGFnZSBiZWxvbmcgdG8KKyAqIEBwYXJt
IHBmbiB0aGUgcGZuIG51bWJlciBvZiB0aGUgYnJva2VuIHBhZ2UKKyAqIEByZXR1cm4gMCBvbiBz
dWNjZXNzLCAtMSBvbiBmYWlsdXJlCisgKi8KK2ludCB4Y19zZXRfYnJva2VuX3BhZ2VfcDJtKHhj
X2ludGVyZmFjZSAqeGNoLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZG9t
aWQsCisgICAgICAgICAgICAgICAgICAgICAgICAgICB1bnNpZ25lZCBsb25nIHBmbik7CisKKy8q
KgogICogVGhpcyBmdW5jdGlvbiByZXR1cm5zIGluZm9ybWF0aW9uIGFib3V0IHRoZSBjb250ZXh0
IG9mIGEgaHZtIGRvbWFpbgogICogQHBhcm0geGNoIGEgaGFuZGxlIHRvIGFuIG9wZW4gaHlwZXJ2
aXNvciBpbnRlcmZhY2UKICAqIEBwYXJtIGRvbWlkIHRoZSBkb21haW4gdG8gZ2V0IGluZm9ybWF0
aW9uIGZyb20KZGlmZiAtciBlMjdhNmQ1M2FjMTUgeGVuL2FyY2gveDg2L2RvbWN0bC5jCi0tLSBh
L3hlbi9hcmNoL3g4Ni9kb21jdGwuYwlUaHUgT2N0IDExIDAxOjUyOjMzIDIwMTIgKzA4MDAKKysr
IGIveGVuL2FyY2gveDg2L2RvbWN0bC5jCVRodSBPY3QgMjUgMDU6NDk6MTAgMjAxMiArMDgwMApA
QCAtMjA5LDEyICsyMDksMTggQEAKICAgICAgICAgICAgICAgICBmb3IgKCBqID0gMDsgaiA8IGs7
IGorKyApCiAgICAgICAgICAgICAgICAgewogICAgICAgICAgICAgICAgICAgICB1bnNpZ25lZCBs
b25nIHR5cGUgPSAwOworICAgICAgICAgICAgICAgICAgICBwMm1fdHlwZV90IHQ7CiAKLSAgICAg
ICAgICAgICAgICAgICAgcGFnZSA9IGdldF9wYWdlX2Zyb21fZ2ZuKGQsIGFycltqXSwgTlVMTCwg
UDJNX0FMTE9DKTsKKyAgICAgICAgICAgICAgICAgICAgcGFnZSA9IGdldF9wYWdlX2Zyb21fZ2Zu
KGQsIGFycltqXSwgJnQsIFAyTV9BTExPQyk7CiAKICAgICAgICAgICAgICAgICAgICAgaWYgKCB1
bmxpa2VseSghcGFnZSkgfHwKICAgICAgICAgICAgICAgICAgICAgICAgICB1bmxpa2VseShpc194
ZW5faGVhcF9wYWdlKHBhZ2UpKSApCi0gICAgICAgICAgICAgICAgICAgICAgICB0eXBlID0gWEVO
X0RPTUNUTF9QRklORk9fWFRBQjsKKyAgICAgICAgICAgICAgICAgICAgeworICAgICAgICAgICAg
ICAgICAgICAgICAgaWYgKCBwMm1faXNfYnJva2VuKHQpICkKKyAgICAgICAgICAgICAgICAgICAg
ICAgICAgICB0eXBlID0gWEVOX0RPTUNUTF9QRklORk9fQlJPS0VOOworICAgICAgICAgICAgICAg
ICAgICAgICAgZWxzZQorICAgICAgICAgICAgICAgICAgICAgICAgICAgIHR5cGUgPSBYRU5fRE9N
Q1RMX1BGSU5GT19YVEFCOworICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAg
ICAgIGVsc2UKICAgICAgICAgICAgICAgICAgICAgewogICAgICAgICAgICAgICAgICAgICAgICAg
c3dpdGNoKCBwYWdlLT51LmludXNlLnR5cGVfaW5mbyAmIFBHVF90eXBlX21hc2sgKQpAQCAtMjM1
LDYgKzI0MSw5IEBACiAKICAgICAgICAgICAgICAgICAgICAgICAgIGlmICggcGFnZS0+dS5pbnVz
ZS50eXBlX2luZm8gJiBQR1RfcGlubmVkICkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0
eXBlIHw9IFhFTl9ET01DVExfUEZJTkZPX0xQSU5UQUI7CisKKyAgICAgICAgICAgICAgICAgICAg
ICAgIGlmICggcGFnZS0+Y291bnRfaW5mbyAmIFBHQ19icm9rZW4gKQorICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHR5cGUgPSBYRU5fRE9NQ1RMX1BGSU5GT19CUk9LRU47CiAgICAgICAgICAg
ICAgICAgICAgIH0KIAogICAgICAgICAgICAgICAgICAgICBpZiAoIHBhZ2UgKQpAQCAtMTU2OCw2
ICsxNTc3LDI4IEBACiAgICAgfQogICAgIGJyZWFrOwogCisgICAgY2FzZSBYRU5fRE9NQ1RMX3Nl
dF9icm9rZW5fcGFnZV9wMm06CisgICAgeworICAgICAgICBzdHJ1Y3QgZG9tYWluICpkOworICAg
ICAgICBwMm1fdHlwZV90IHB0OworICAgICAgICB1bnNpZ25lZCBsb25nIHBmbjsKKworICAgICAg
ICBkID0gcmN1X2xvY2tfZG9tYWluX2J5X2lkKGRvbWN0bC0+ZG9tYWluKTsKKyAgICAgICAgaWYg
KCBkICE9IE5VTEwgKQorICAgICAgICB7CisgICAgICAgICAgICBwZm4gPSBkb21jdGwtPnUuc2V0
X2Jyb2tlbl9wYWdlX3AybS5wZm47CisKKyAgICAgICAgICAgIGdldF9nZm5fcXVlcnkoZCwgcGZu
LCAmcHQpOworICAgICAgICAgICAgcDJtX2NoYW5nZV90eXBlKGQsIHBmbiwgcHQsIHAybV9yYW1f
YnJva2VuKTsKKyAgICAgICAgICAgIHB1dF9nZm4oZCwgcGZuKTsKKworICAgICAgICAgICAgcmN1
X3VubG9ja19kb21haW4oZCk7CisgICAgICAgIH0KKyAgICAgICAgZWxzZQorICAgICAgICAgICAg
cmV0ID0gLUVTUkNIOworICAgIH0KKyAgICBicmVhazsKKwogICAgIGRlZmF1bHQ6CiAgICAgICAg
IHJldCA9IGlvbW11X2RvX2RvbWN0bChkb21jdGwsIHVfZG9tY3RsKTsKICAgICAgICAgYnJlYWs7
CmRpZmYgLXIgZTI3YTZkNTNhYzE1IHhlbi9pbmNsdWRlL3B1YmxpYy9kb21jdGwuaAotLS0gYS94
ZW4vaW5jbHVkZS9wdWJsaWMvZG9tY3RsLmgJVGh1IE9jdCAxMSAwMTo1MjozMyAyMDEyICswODAw
CisrKyBiL3hlbi9pbmNsdWRlL3B1YmxpYy9kb21jdGwuaAlUaHUgT2N0IDI1IDA1OjQ5OjEwIDIw
MTIgKzA4MDAKQEAgLTEzNiw2ICsxMzYsNyBAQAogI2RlZmluZSBYRU5fRE9NQ1RMX1BGSU5GT19M
UElOVEFCICgweDFVPDwzMSkKICNkZWZpbmUgWEVOX0RPTUNUTF9QRklORk9fWFRBQiAgICAoMHhm
VTw8MjgpIC8qIGludmFsaWQgcGFnZSAqLwogI2RlZmluZSBYRU5fRE9NQ1RMX1BGSU5GT19YQUxM
T0MgICgweGVVPDwyOCkgLyogYWxsb2NhdGUtb25seSBwYWdlICovCisjZGVmaW5lIFhFTl9ET01D
VExfUEZJTkZPX0JST0tFTiAgKDB4ZFU8PDI4KSAvKiBicm9rZW4gcGFnZSAqLwogI2RlZmluZSBY
RU5fRE9NQ1RMX1BGSU5GT19QQUdFRFRBQiAoMHg4VTw8MjgpCiAjZGVmaW5lIFhFTl9ET01DVExf
UEZJTkZPX0xUQUJfTUFTSyAoMHhmVTw8MjgpCiAKQEAgLTgzNSw2ICs4MzYsMTIgQEAKIHR5cGVk
ZWYgc3RydWN0IHhlbl9kb21jdGxfc2V0X2FjY2Vzc19yZXF1aXJlZCB4ZW5fZG9tY3RsX3NldF9h
Y2Nlc3NfcmVxdWlyZWRfdDsKIERFRklORV9YRU5fR1VFU1RfSEFORExFKHhlbl9kb21jdGxfc2V0
X2FjY2Vzc19yZXF1aXJlZF90KTsKIAorc3RydWN0IHhlbl9kb21jdGxfc2V0X2Jyb2tlbl9wYWdl
X3AybSB7CisgICAgdWludDY0X2FsaWduZWRfdCBwZm47Cit9OwordHlwZWRlZiBzdHJ1Y3QgeGVu
X2RvbWN0bF9zZXRfYnJva2VuX3BhZ2VfcDJtIHhlbl9kb21jdGxfc2V0X2Jyb2tlbl9wYWdlX3Ay
bV90OworREVGSU5FX1hFTl9HVUVTVF9IQU5ETEUoeGVuX2RvbWN0bF9zZXRfYnJva2VuX3BhZ2Vf
cDJtX3QpOworCiBzdHJ1Y3QgeGVuX2RvbWN0bCB7CiAgICAgdWludDMyX3QgY21kOwogI2RlZmlu
ZSBYRU5fRE9NQ1RMX2NyZWF0ZWRvbWFpbiAgICAgICAgICAgICAgICAgICAxCkBAIC05MDAsNiAr
OTA3LDcgQEAKICNkZWZpbmUgWEVOX0RPTUNUTF9zZXRfYWNjZXNzX3JlcXVpcmVkICAgICAgICAg
ICA2NAogI2RlZmluZSBYRU5fRE9NQ1RMX2F1ZGl0X3AybSAgICAgICAgICAgICAgICAgICAgIDY1
CiAjZGVmaW5lIFhFTl9ET01DVExfc2V0X3ZpcnFfaGFuZGxlciAgICAgICAgICAgICAgNjYKKyNk
ZWZpbmUgWEVOX0RPTUNUTF9zZXRfYnJva2VuX3BhZ2VfcDJtICAgICAgICAgICA2NwogI2RlZmlu
ZSBYRU5fRE9NQ1RMX2dkYnN4X2d1ZXN0bWVtaW8gICAgICAgICAgICAxMDAwCiAjZGVmaW5lIFhF
Tl9ET01DVExfZ2Ric3hfcGF1c2V2Y3B1ICAgICAgICAgICAgIDEwMDEKICNkZWZpbmUgWEVOX0RP
TUNUTF9nZGJzeF91bnBhdXNldmNwdSAgICAgICAgICAgMTAwMgpAQCAtOTU1LDYgKzk2Myw3IEBA
CiAgICAgICAgIHN0cnVjdCB4ZW5fZG9tY3RsX2F1ZGl0X3AybSAgICAgICAgIGF1ZGl0X3AybTsK
ICAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfc2V0X3ZpcnFfaGFuZGxlciAgc2V0X3ZpcnFfaGFu
ZGxlcjsKICAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfZ2Ric3hfbWVtaW8gICAgICAgZ2Ric3hf
Z3Vlc3RfbWVtaW87CisgICAgICAgIHN0cnVjdCB4ZW5fZG9tY3RsX3NldF9icm9rZW5fcGFnZV9w
Mm0gc2V0X2Jyb2tlbl9wYWdlX3AybTsKICAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfZ2Ric3hf
cGF1c2V1bnBfdmNwdSBnZGJzeF9wYXVzZXVucF92Y3B1OwogICAgICAgICBzdHJ1Y3QgeGVuX2Rv
bWN0bF9nZGJzeF9kb21zdGF0dXMgICBnZGJzeF9kb21zdGF0dXM7CiAgICAgICAgIHVpbnQ4X3Qg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBhZFsxMjhdOwo=

--_002_DE8DF0795D48FD4CA783C40EC8292335374280SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC8292335374280SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Mon Oct 29 15:22:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 15:22:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSr9p-0004SO-Pf; Mon, 29 Oct 2012 15:21:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSr9o-0004SJ-7d
	for xen-devel@lists.xensource.com; Mon, 29 Oct 2012 15:21:40 +0000
Received: from [85.158.139.83:34737] by server-4.bemta-5.messagelabs.com id
	9D/22-01455-30F9E805; Mon, 29 Oct 2012 15:21:39 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1351524096!27799500!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzYwNDMx\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22567 invoked from network); 29 Oct 2012 15:21:37 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-2.tower-182.messagelabs.com with SMTP;
	29 Oct 2012 15:21:37 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 29 Oct 2012 08:21:06 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,672,1344236400"; d="scan'208";a="212512669"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by orsmga001.jf.intel.com with ESMTP; 29 Oct 2012 08:21:35 -0700
Received: from fmsmsx101.amr.corp.intel.com (10.19.9.52) by
	FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 29 Oct 2012 08:21:34 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX101.amr.corp.intel.com (10.19.9.52) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 29 Oct 2012 08:21:34 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.186]) with mapi id
	14.01.0355.002; Mon, 29 Oct 2012 23:21:31 +0800
From: "Liu, Jinsong" 
To: George Dunlap , Ian Jackson
	
Thread-Topic: [Patch 4/5] X86/vMCE: handle broken page occurred before
	migration
Thread-Index: AQHNsEjdaBRa8rOqkUOTeDJn2J5LNJfQcOeQ
Date: Mon, 29 Oct 2012 15:21:31 +0000
Message-ID: 
References: 
	
	
	<50852EB6.4060705@eu.citrix.com>
In-Reply-To: <50852EB6.4060705@eu.citrix.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC8292335374280SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	Jan Beulich 
Subject: [Xen-devel] [Patch 4/5] X86/vMCE: handle broken page occurred
	before migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC8292335374280SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

X86/vMCE: handle broken page occurred before migration

This patch handles guest broken page which occur before migration.

At sender, the broken page would be mapped but not copied to target
(otherwise it may trigger more serious error, say, SRAR error).
While its pfn_type and pfn number would be transferred to target
so that target take appropriate action.

At target, it would set p2m as p2m_ram_broken for broken page, so that
if guest access the broken page again, it would kill itself as expected.

Signed-off-by: Liu, Jinsong 

diff -r e27a6d53ac15 tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c	Thu Oct 11 01:52:33 2012 +0800
+++ b/tools/libxc/xc_domain.c	Thu Oct 25 05:49:10 2012 +0800
@@ -283,6 +283,22 @@
     return ret;
 }
=20
+/* set broken page p2m */
+int xc_set_broken_page_p2m(xc_interface *xch,
+                           uint32_t domid,
+                           unsigned long pfn)
+{
+    int ret;
+    DECLARE_DOMCTL;
+
+    domctl.cmd =3D XEN_DOMCTL_set_broken_page_p2m;
+    domctl.domain =3D (domid_t)domid;
+    domctl.u.set_broken_page_p2m.pfn =3D pfn;
+    ret =3D do_domctl(xch, &domctl);
+
+    return ret ? -1 : 0;
+}
+
 /* get info from hvm guest for save */
 int xc_domain_hvm_getcontext(xc_interface *xch,
                              uint32_t domid,
diff -r e27a6d53ac15 tools/libxc/xc_domain_restore.c
--- a/tools/libxc/xc_domain_restore.c	Thu Oct 11 01:52:33 2012 +0800
+++ b/tools/libxc/xc_domain_restore.c	Thu Oct 25 05:49:10 2012 +0800
@@ -962,9 +962,15 @@
=20
     countpages =3D count;
     for (i =3D oldcount; i < buf->nr_pages; ++i)
-        if ((buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) =3D=3D XEN_D=
OMCTL_PFINFO_XTAB
-            ||(buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) =3D=3D XEN=
_DOMCTL_PFINFO_XALLOC)
+    {
+        unsigned long pagetype;
+
+        pagetype =3D buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK;
+        if ( pagetype =3D=3D XEN_DOMCTL_PFINFO_XTAB ||
+             pagetype =3D=3D XEN_DOMCTL_PFINFO_BROKEN ||
+             pagetype =3D=3D XEN_DOMCTL_PFINFO_XALLOC )
             --countpages;
+    }
=20
     if (!countpages)
         return count;
@@ -1200,6 +1206,17 @@
             /* a bogus/unmapped/allocate-only page: skip it */
             continue;
=20
+        if ( pagetype =3D=3D XEN_DOMCTL_PFINFO_BROKEN )
+        {
+            if ( xc_set_broken_page_p2m(xch, dom, pfn) )
+            {
+                ERROR("Set p2m for broken page failed, "
+                      "dom=3D%d, pfn=3D%lx\n", dom, pfn);
+                goto err_mapped;
+            }
+            continue;
+        }
+
         if (pfn_err[i])
         {
             ERROR("unexpected PFN mapping failure pfn %lx map_mfn %lx p2m_=
mfn %lx",
diff -r e27a6d53ac15 tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Thu Oct 11 01:52:33 2012 +0800
+++ b/tools/libxc/xc_domain_save.c	Thu Oct 25 05:49:10 2012 +0800
@@ -1277,6 +1277,13 @@
                 if ( !hvm )
                     gmfn =3D pfn_to_mfn(gmfn);
=20
+                if ( pfn_type[j] =3D=3D XEN_DOMCTL_PFINFO_BROKEN )
+                {
+                    pfn_type[j] |=3D pfn_batch[j];
+                    ++run;
+                    continue;
+                }
+
                 if ( pfn_err[j] )
                 {
                     if ( pfn_type[j] =3D=3D XEN_DOMCTL_PFINFO_XTAB )
@@ -1371,8 +1378,12 @@
                     }
                 }
=20
-                /* skip pages that aren't present or are alloc-only */
+                /*
+                 * skip pages that aren't present,
+                 * or are broken, or are alloc-only
+                 */
                 if ( pagetype =3D=3D XEN_DOMCTL_PFINFO_XTAB
+                    || pagetype =3D=3D XEN_DOMCTL_PFINFO_BROKEN
                     || pagetype =3D=3D XEN_DOMCTL_PFINFO_XALLOC )
                     continue;
=20
diff -r e27a6d53ac15 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Thu Oct 11 01:52:33 2012 +0800
+++ b/tools/libxc/xenctrl.h	Thu Oct 25 05:49:10 2012 +0800
@@ -575,6 +575,17 @@
                           xc_domaininfo_t *info);
=20
 /**
+ * This function set p2m for broken page
+ * &parm xch a handle to an open hypervisor interface
+ * @parm domid the domain id which broken page belong to
+ * @parm pfn the pfn number of the broken page
+ * @return 0 on success, -1 on failure
+ */
+int xc_set_broken_page_p2m(xc_interface *xch,
+                           uint32_t domid,
+                           unsigned long pfn);
+
+/**
  * This function returns information about the context of a hvm domain
  * @parm xch a handle to an open hypervisor interface
  * @parm domid the domain to get information from
diff -r e27a6d53ac15 xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c	Thu Oct 11 01:52:33 2012 +0800
+++ b/xen/arch/x86/domctl.c	Thu Oct 25 05:49:10 2012 +0800
@@ -209,12 +209,18 @@
                 for ( j =3D 0; j < k; j++ )
                 {
                     unsigned long type =3D 0;
+                    p2m_type_t t;
=20
-                    page =3D get_page_from_gfn(d, arr[j], NULL, P2M_ALLOC)=
;
+                    page =3D get_page_from_gfn(d, arr[j], &t, P2M_ALLOC);
=20
                     if ( unlikely(!page) ||
                          unlikely(is_xen_heap_page(page)) )
-                        type =3D XEN_DOMCTL_PFINFO_XTAB;
+                    {
+                        if ( p2m_is_broken(t) )
+                            type =3D XEN_DOMCTL_PFINFO_BROKEN;
+                        else
+                            type =3D XEN_DOMCTL_PFINFO_XTAB;
+                    }
                     else
                     {
                         switch( page->u.inuse.type_info & PGT_type_mask )
@@ -235,6 +241,9 @@
=20
                         if ( page->u.inuse.type_info & PGT_pinned )
                             type |=3D XEN_DOMCTL_PFINFO_LPINTAB;
+
+                        if ( page->count_info & PGC_broken )
+                            type =3D XEN_DOMCTL_PFINFO_BROKEN;
                     }
=20
                     if ( page )
@@ -1568,6 +1577,28 @@
     }
     break;
=20
+    case XEN_DOMCTL_set_broken_page_p2m:
+    {
+        struct domain *d;
+        p2m_type_t pt;
+        unsigned long pfn;
+
+        d =3D rcu_lock_domain_by_id(domctl->domain);
+        if ( d !=3D NULL )
+        {
+            pfn =3D domctl->u.set_broken_page_p2m.pfn;
+
+            get_gfn_query(d, pfn, &pt);
+            p2m_change_type(d, pfn, pt, p2m_ram_broken);
+            put_gfn(d, pfn);
+
+            rcu_unlock_domain(d);
+        }
+        else
+            ret =3D -ESRCH;
+    }
+    break;
+
     default:
         ret =3D iommu_do_domctl(domctl, u_domctl);
         break;
diff -r e27a6d53ac15 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h	Thu Oct 11 01:52:33 2012 +0800
+++ b/xen/include/public/domctl.h	Thu Oct 25 05:49:10 2012 +0800
@@ -136,6 +136,7 @@
 #define XEN_DOMCTL_PFINFO_LPINTAB (0x1U<<31)
 #define XEN_DOMCTL_PFINFO_XTAB    (0xfU<<28) /* invalid page */
 #define XEN_DOMCTL_PFINFO_XALLOC  (0xeU<<28) /* allocate-only page */
+#define XEN_DOMCTL_PFINFO_BROKEN  (0xdU<<28) /* broken page */
 #define XEN_DOMCTL_PFINFO_PAGEDTAB (0x8U<<28)
 #define XEN_DOMCTL_PFINFO_LTAB_MASK (0xfU<<28)
=20
@@ -835,6 +836,12 @@
 typedef struct xen_domctl_set_access_required xen_domctl_set_access_requir=
ed_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_access_required_t);
=20
+struct xen_domctl_set_broken_page_p2m {
+    uint64_aligned_t pfn;
+};
+typedef struct xen_domctl_set_broken_page_p2m xen_domctl_set_broken_page_p=
2m_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_broken_page_p2m_t);
+
 struct xen_domctl {
     uint32_t cmd;
 #define XEN_DOMCTL_createdomain                   1
@@ -900,6 +907,7 @@
 #define XEN_DOMCTL_set_access_required           64
 #define XEN_DOMCTL_audit_p2m                     65
 #define XEN_DOMCTL_set_virq_handler              66
+#define XEN_DOMCTL_set_broken_page_p2m           67
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -955,6 +963,7 @@
         struct xen_domctl_audit_p2m         audit_p2m;
         struct xen_domctl_set_virq_handler  set_virq_handler;
         struct xen_domctl_gdbsx_memio       gdbsx_guest_memio;
+        struct xen_domctl_set_broken_page_p2m set_broken_page_p2m;
         struct xen_domctl_gdbsx_pauseunp_vcpu gdbsx_pauseunp_vcpu;
         struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
         uint8_t                             pad[128];=

--_002_DE8DF0795D48FD4CA783C40EC8292335374280SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="4_vmce_before_migration.patch"
Content-Description: 4_vmce_before_migration.patch
Content-Disposition: attachment; filename="4_vmce_before_migration.patch";
	size=8474; creation-date="Mon, 29 Oct 2012 15:18:32 GMT";
	modification-date="Mon, 29 Oct 2012 23:04:06 GMT"
Content-Transfer-Encoding: base64

WDg2L3ZNQ0U6IGhhbmRsZSBicm9rZW4gcGFnZSBvY2N1cnJlZCBiZWZvcmUgbWlncmF0aW9uCgpU
aGlzIHBhdGNoIGhhbmRsZXMgZ3Vlc3QgYnJva2VuIHBhZ2Ugd2hpY2ggb2NjdXIgYmVmb3JlIG1p
Z3JhdGlvbi4KCkF0IHNlbmRlciwgdGhlIGJyb2tlbiBwYWdlIHdvdWxkIGJlIG1hcHBlZCBidXQg
bm90IGNvcGllZCB0byB0YXJnZXQKKG90aGVyd2lzZSBpdCBtYXkgdHJpZ2dlciBtb3JlIHNlcmlv
dXMgZXJyb3IsIHNheSwgU1JBUiBlcnJvcikuCldoaWxlIGl0cyBwZm5fdHlwZSBhbmQgcGZuIG51
bWJlciB3b3VsZCBiZSB0cmFuc2ZlcnJlZCB0byB0YXJnZXQKc28gdGhhdCB0YXJnZXQgdGFrZSBh
cHByb3ByaWF0ZSBhY3Rpb24uCgpBdCB0YXJnZXQsIGl0IHdvdWxkIHNldCBwMm0gYXMgcDJtX3Jh
bV9icm9rZW4gZm9yIGJyb2tlbiBwYWdlLCBzbyB0aGF0CmlmIGd1ZXN0IGFjY2VzcyB0aGUgYnJv
a2VuIHBhZ2UgYWdhaW4sIGl0IHdvdWxkIGtpbGwgaXRzZWxmIGFzIGV4cGVjdGVkLgoKU2lnbmVk
LW9mZi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+CgpkaWZmIC1yIGUy
N2E2ZDUzYWMxNSB0b29scy9saWJ4Yy94Y19kb21haW4uYwotLS0gYS90b29scy9saWJ4Yy94Y19k
b21haW4uYwlUaHUgT2N0IDExIDAxOjUyOjMzIDIwMTIgKzA4MDAKKysrIGIvdG9vbHMvbGlieGMv
eGNfZG9tYWluLmMJVGh1IE9jdCAyNSAwNTo0OToxMCAyMDEyICswODAwCkBAIC0yODMsNiArMjgz
LDIyIEBACiAgICAgcmV0dXJuIHJldDsKIH0KIAorLyogc2V0IGJyb2tlbiBwYWdlIHAybSAqLwor
aW50IHhjX3NldF9icm9rZW5fcGFnZV9wMm0oeGNfaW50ZXJmYWNlICp4Y2gsCisgICAgICAgICAg
ICAgICAgICAgICAgICAgICB1aW50MzJfdCBkb21pZCwKKyAgICAgICAgICAgICAgICAgICAgICAg
ICAgIHVuc2lnbmVkIGxvbmcgcGZuKQoreworICAgIGludCByZXQ7CisgICAgREVDTEFSRV9ET01D
VEw7CisKKyAgICBkb21jdGwuY21kID0gWEVOX0RPTUNUTF9zZXRfYnJva2VuX3BhZ2VfcDJtOwor
ICAgIGRvbWN0bC5kb21haW4gPSAoZG9taWRfdClkb21pZDsKKyAgICBkb21jdGwudS5zZXRfYnJv
a2VuX3BhZ2VfcDJtLnBmbiA9IHBmbjsKKyAgICByZXQgPSBkb19kb21jdGwoeGNoLCAmZG9tY3Rs
KTsKKworICAgIHJldHVybiByZXQgPyAtMSA6IDA7Cit9CisKIC8qIGdldCBpbmZvIGZyb20gaHZt
IGd1ZXN0IGZvciBzYXZlICovCiBpbnQgeGNfZG9tYWluX2h2bV9nZXRjb250ZXh0KHhjX2ludGVy
ZmFjZSAqeGNoLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJfdCBkb21pZCwK
ZGlmZiAtciBlMjdhNmQ1M2FjMTUgdG9vbHMvbGlieGMveGNfZG9tYWluX3Jlc3RvcmUuYwotLS0g
YS90b29scy9saWJ4Yy94Y19kb21haW5fcmVzdG9yZS5jCVRodSBPY3QgMTEgMDE6NTI6MzMgMjAx
MiArMDgwMAorKysgYi90b29scy9saWJ4Yy94Y19kb21haW5fcmVzdG9yZS5jCVRodSBPY3QgMjUg
MDU6NDk6MTAgMjAxMiArMDgwMApAQCAtOTYyLDkgKzk2MiwxNSBAQAogCiAgICAgY291bnRwYWdl
cyA9IGNvdW50OwogICAgIGZvciAoaSA9IG9sZGNvdW50OyBpIDwgYnVmLT5ucl9wYWdlczsgKytp
KQotICAgICAgICBpZiAoKGJ1Zi0+cGZuX3R5cGVzW2ldICYgWEVOX0RPTUNUTF9QRklORk9fTFRB
Ql9NQVNLKSA9PSBYRU5fRE9NQ1RMX1BGSU5GT19YVEFCCi0gICAgICAgICAgICB8fChidWYtPnBm
bl90eXBlc1tpXSAmIFhFTl9ET01DVExfUEZJTkZPX0xUQUJfTUFTSykgPT0gWEVOX0RPTUNUTF9Q
RklORk9fWEFMTE9DKQorICAgIHsKKyAgICAgICAgdW5zaWduZWQgbG9uZyBwYWdldHlwZTsKKwor
ICAgICAgICBwYWdldHlwZSA9IGJ1Zi0+cGZuX3R5cGVzW2ldICYgWEVOX0RPTUNUTF9QRklORk9f
TFRBQl9NQVNLOworICAgICAgICBpZiAoIHBhZ2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX1hU
QUIgfHwKKyAgICAgICAgICAgICBwYWdldHlwZSA9PSBYRU5fRE9NQ1RMX1BGSU5GT19CUk9LRU4g
fHwKKyAgICAgICAgICAgICBwYWdldHlwZSA9PSBYRU5fRE9NQ1RMX1BGSU5GT19YQUxMT0MgKQog
ICAgICAgICAgICAgLS1jb3VudHBhZ2VzOworICAgIH0KIAogICAgIGlmICghY291bnRwYWdlcykK
ICAgICAgICAgcmV0dXJuIGNvdW50OwpAQCAtMTIwMCw2ICsxMjA2LDE3IEBACiAgICAgICAgICAg
ICAvKiBhIGJvZ3VzL3VubWFwcGVkL2FsbG9jYXRlLW9ubHkgcGFnZTogc2tpcCBpdCAqLwogICAg
ICAgICAgICAgY29udGludWU7CiAKKyAgICAgICAgaWYgKCBwYWdldHlwZSA9PSBYRU5fRE9NQ1RM
X1BGSU5GT19CUk9LRU4gKQorICAgICAgICB7CisgICAgICAgICAgICBpZiAoIHhjX3NldF9icm9r
ZW5fcGFnZV9wMm0oeGNoLCBkb20sIHBmbikgKQorICAgICAgICAgICAgeworICAgICAgICAgICAg
ICAgIEVSUk9SKCJTZXQgcDJtIGZvciBicm9rZW4gcGFnZSBmYWlsZWQsICIKKyAgICAgICAgICAg
ICAgICAgICAgICAiZG9tPSVkLCBwZm49JWx4XG4iLCBkb20sIHBmbik7CisgICAgICAgICAgICAg
ICAgZ290byBlcnJfbWFwcGVkOworICAgICAgICAgICAgfQorICAgICAgICAgICAgY29udGludWU7
CisgICAgICAgIH0KKwogICAgICAgICBpZiAocGZuX2VycltpXSkKICAgICAgICAgewogICAgICAg
ICAgICAgRVJST1IoInVuZXhwZWN0ZWQgUEZOIG1hcHBpbmcgZmFpbHVyZSBwZm4gJWx4IG1hcF9t
Zm4gJWx4IHAybV9tZm4gJWx4IiwKZGlmZiAtciBlMjdhNmQ1M2FjMTUgdG9vbHMvbGlieGMveGNf
ZG9tYWluX3NhdmUuYwotLS0gYS90b29scy9saWJ4Yy94Y19kb21haW5fc2F2ZS5jCVRodSBPY3Qg
MTEgMDE6NTI6MzMgMjAxMiArMDgwMAorKysgYi90b29scy9saWJ4Yy94Y19kb21haW5fc2F2ZS5j
CVRodSBPY3QgMjUgMDU6NDk6MTAgMjAxMiArMDgwMApAQCAtMTI3Nyw2ICsxMjc3LDEzIEBACiAg
ICAgICAgICAgICAgICAgaWYgKCAhaHZtICkKICAgICAgICAgICAgICAgICAgICAgZ21mbiA9IHBm
bl90b19tZm4oZ21mbik7CiAKKyAgICAgICAgICAgICAgICBpZiAoIHBmbl90eXBlW2pdID09IFhF
Tl9ET01DVExfUEZJTkZPX0JST0tFTiApCisgICAgICAgICAgICAgICAgeworICAgICAgICAgICAg
ICAgICAgICBwZm5fdHlwZVtqXSB8PSBwZm5fYmF0Y2hbal07CisgICAgICAgICAgICAgICAgICAg
ICsrcnVuOworICAgICAgICAgICAgICAgICAgICBjb250aW51ZTsKKyAgICAgICAgICAgICAgICB9
CisKICAgICAgICAgICAgICAgICBpZiAoIHBmbl9lcnJbal0gKQogICAgICAgICAgICAgICAgIHsK
ICAgICAgICAgICAgICAgICAgICAgaWYgKCBwZm5fdHlwZVtqXSA9PSBYRU5fRE9NQ1RMX1BGSU5G
T19YVEFCICkKQEAgLTEzNzEsOCArMTM3OCwxMiBAQAogICAgICAgICAgICAgICAgICAgICB9CiAg
ICAgICAgICAgICAgICAgfQogCi0gICAgICAgICAgICAgICAgLyogc2tpcCBwYWdlcyB0aGF0IGFy
ZW4ndCBwcmVzZW50IG9yIGFyZSBhbGxvYy1vbmx5ICovCisgICAgICAgICAgICAgICAgLyoKKyAg
ICAgICAgICAgICAgICAgKiBza2lwIHBhZ2VzIHRoYXQgYXJlbid0IHByZXNlbnQsCisgICAgICAg
ICAgICAgICAgICogb3IgYXJlIGJyb2tlbiwgb3IgYXJlIGFsbG9jLW9ubHkKKyAgICAgICAgICAg
ICAgICAgKi8KICAgICAgICAgICAgICAgICBpZiAoIHBhZ2V0eXBlID09IFhFTl9ET01DVExfUEZJ
TkZPX1hUQUIKKyAgICAgICAgICAgICAgICAgICAgfHwgcGFnZXR5cGUgPT0gWEVOX0RPTUNUTF9Q
RklORk9fQlJPS0VOCiAgICAgICAgICAgICAgICAgICAgIHx8IHBhZ2V0eXBlID09IFhFTl9ET01D
VExfUEZJTkZPX1hBTExPQyApCiAgICAgICAgICAgICAgICAgICAgIGNvbnRpbnVlOwogCmRpZmYg
LXIgZTI3YTZkNTNhYzE1IHRvb2xzL2xpYnhjL3hlbmN0cmwuaAotLS0gYS90b29scy9saWJ4Yy94
ZW5jdHJsLmgJVGh1IE9jdCAxMSAwMTo1MjozMyAyMDEyICswODAwCisrKyBiL3Rvb2xzL2xpYnhj
L3hlbmN0cmwuaAlUaHUgT2N0IDI1IDA1OjQ5OjEwIDIwMTIgKzA4MDAKQEAgLTU3NSw2ICs1NzUs
MTcgQEAKICAgICAgICAgICAgICAgICAgICAgICAgICAgeGNfZG9tYWluaW5mb190ICppbmZvKTsK
IAogLyoqCisgKiBUaGlzIGZ1bmN0aW9uIHNldCBwMm0gZm9yIGJyb2tlbiBwYWdlCisgKiAmcGFy
bSB4Y2ggYSBoYW5kbGUgdG8gYW4gb3BlbiBoeXBlcnZpc29yIGludGVyZmFjZQorICogQHBhcm0g
ZG9taWQgdGhlIGRvbWFpbiBpZCB3aGljaCBicm9rZW4gcGFnZSBiZWxvbmcgdG8KKyAqIEBwYXJt
IHBmbiB0aGUgcGZuIG51bWJlciBvZiB0aGUgYnJva2VuIHBhZ2UKKyAqIEByZXR1cm4gMCBvbiBz
dWNjZXNzLCAtMSBvbiBmYWlsdXJlCisgKi8KK2ludCB4Y19zZXRfYnJva2VuX3BhZ2VfcDJtKHhj
X2ludGVyZmFjZSAqeGNoLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZG9t
aWQsCisgICAgICAgICAgICAgICAgICAgICAgICAgICB1bnNpZ25lZCBsb25nIHBmbik7CisKKy8q
KgogICogVGhpcyBmdW5jdGlvbiByZXR1cm5zIGluZm9ybWF0aW9uIGFib3V0IHRoZSBjb250ZXh0
IG9mIGEgaHZtIGRvbWFpbgogICogQHBhcm0geGNoIGEgaGFuZGxlIHRvIGFuIG9wZW4gaHlwZXJ2
aXNvciBpbnRlcmZhY2UKICAqIEBwYXJtIGRvbWlkIHRoZSBkb21haW4gdG8gZ2V0IGluZm9ybWF0
aW9uIGZyb20KZGlmZiAtciBlMjdhNmQ1M2FjMTUgeGVuL2FyY2gveDg2L2RvbWN0bC5jCi0tLSBh
L3hlbi9hcmNoL3g4Ni9kb21jdGwuYwlUaHUgT2N0IDExIDAxOjUyOjMzIDIwMTIgKzA4MDAKKysr
IGIveGVuL2FyY2gveDg2L2RvbWN0bC5jCVRodSBPY3QgMjUgMDU6NDk6MTAgMjAxMiArMDgwMApA
QCAtMjA5LDEyICsyMDksMTggQEAKICAgICAgICAgICAgICAgICBmb3IgKCBqID0gMDsgaiA8IGs7
IGorKyApCiAgICAgICAgICAgICAgICAgewogICAgICAgICAgICAgICAgICAgICB1bnNpZ25lZCBs
b25nIHR5cGUgPSAwOworICAgICAgICAgICAgICAgICAgICBwMm1fdHlwZV90IHQ7CiAKLSAgICAg
ICAgICAgICAgICAgICAgcGFnZSA9IGdldF9wYWdlX2Zyb21fZ2ZuKGQsIGFycltqXSwgTlVMTCwg
UDJNX0FMTE9DKTsKKyAgICAgICAgICAgICAgICAgICAgcGFnZSA9IGdldF9wYWdlX2Zyb21fZ2Zu
KGQsIGFycltqXSwgJnQsIFAyTV9BTExPQyk7CiAKICAgICAgICAgICAgICAgICAgICAgaWYgKCB1
bmxpa2VseSghcGFnZSkgfHwKICAgICAgICAgICAgICAgICAgICAgICAgICB1bmxpa2VseShpc194
ZW5faGVhcF9wYWdlKHBhZ2UpKSApCi0gICAgICAgICAgICAgICAgICAgICAgICB0eXBlID0gWEVO
X0RPTUNUTF9QRklORk9fWFRBQjsKKyAgICAgICAgICAgICAgICAgICAgeworICAgICAgICAgICAg
ICAgICAgICAgICAgaWYgKCBwMm1faXNfYnJva2VuKHQpICkKKyAgICAgICAgICAgICAgICAgICAg
ICAgICAgICB0eXBlID0gWEVOX0RPTUNUTF9QRklORk9fQlJPS0VOOworICAgICAgICAgICAgICAg
ICAgICAgICAgZWxzZQorICAgICAgICAgICAgICAgICAgICAgICAgICAgIHR5cGUgPSBYRU5fRE9N
Q1RMX1BGSU5GT19YVEFCOworICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAg
ICAgIGVsc2UKICAgICAgICAgICAgICAgICAgICAgewogICAgICAgICAgICAgICAgICAgICAgICAg
c3dpdGNoKCBwYWdlLT51LmludXNlLnR5cGVfaW5mbyAmIFBHVF90eXBlX21hc2sgKQpAQCAtMjM1
LDYgKzI0MSw5IEBACiAKICAgICAgICAgICAgICAgICAgICAgICAgIGlmICggcGFnZS0+dS5pbnVz
ZS50eXBlX2luZm8gJiBQR1RfcGlubmVkICkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0
eXBlIHw9IFhFTl9ET01DVExfUEZJTkZPX0xQSU5UQUI7CisKKyAgICAgICAgICAgICAgICAgICAg
ICAgIGlmICggcGFnZS0+Y291bnRfaW5mbyAmIFBHQ19icm9rZW4gKQorICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHR5cGUgPSBYRU5fRE9NQ1RMX1BGSU5GT19CUk9LRU47CiAgICAgICAgICAg
ICAgICAgICAgIH0KIAogICAgICAgICAgICAgICAgICAgICBpZiAoIHBhZ2UgKQpAQCAtMTU2OCw2
ICsxNTc3LDI4IEBACiAgICAgfQogICAgIGJyZWFrOwogCisgICAgY2FzZSBYRU5fRE9NQ1RMX3Nl
dF9icm9rZW5fcGFnZV9wMm06CisgICAgeworICAgICAgICBzdHJ1Y3QgZG9tYWluICpkOworICAg
ICAgICBwMm1fdHlwZV90IHB0OworICAgICAgICB1bnNpZ25lZCBsb25nIHBmbjsKKworICAgICAg
ICBkID0gcmN1X2xvY2tfZG9tYWluX2J5X2lkKGRvbWN0bC0+ZG9tYWluKTsKKyAgICAgICAgaWYg
KCBkICE9IE5VTEwgKQorICAgICAgICB7CisgICAgICAgICAgICBwZm4gPSBkb21jdGwtPnUuc2V0
X2Jyb2tlbl9wYWdlX3AybS5wZm47CisKKyAgICAgICAgICAgIGdldF9nZm5fcXVlcnkoZCwgcGZu
LCAmcHQpOworICAgICAgICAgICAgcDJtX2NoYW5nZV90eXBlKGQsIHBmbiwgcHQsIHAybV9yYW1f
YnJva2VuKTsKKyAgICAgICAgICAgIHB1dF9nZm4oZCwgcGZuKTsKKworICAgICAgICAgICAgcmN1
X3VubG9ja19kb21haW4oZCk7CisgICAgICAgIH0KKyAgICAgICAgZWxzZQorICAgICAgICAgICAg
cmV0ID0gLUVTUkNIOworICAgIH0KKyAgICBicmVhazsKKwogICAgIGRlZmF1bHQ6CiAgICAgICAg
IHJldCA9IGlvbW11X2RvX2RvbWN0bChkb21jdGwsIHVfZG9tY3RsKTsKICAgICAgICAgYnJlYWs7
CmRpZmYgLXIgZTI3YTZkNTNhYzE1IHhlbi9pbmNsdWRlL3B1YmxpYy9kb21jdGwuaAotLS0gYS94
ZW4vaW5jbHVkZS9wdWJsaWMvZG9tY3RsLmgJVGh1IE9jdCAxMSAwMTo1MjozMyAyMDEyICswODAw
CisrKyBiL3hlbi9pbmNsdWRlL3B1YmxpYy9kb21jdGwuaAlUaHUgT2N0IDI1IDA1OjQ5OjEwIDIw
MTIgKzA4MDAKQEAgLTEzNiw2ICsxMzYsNyBAQAogI2RlZmluZSBYRU5fRE9NQ1RMX1BGSU5GT19M
UElOVEFCICgweDFVPDwzMSkKICNkZWZpbmUgWEVOX0RPTUNUTF9QRklORk9fWFRBQiAgICAoMHhm
VTw8MjgpIC8qIGludmFsaWQgcGFnZSAqLwogI2RlZmluZSBYRU5fRE9NQ1RMX1BGSU5GT19YQUxM
T0MgICgweGVVPDwyOCkgLyogYWxsb2NhdGUtb25seSBwYWdlICovCisjZGVmaW5lIFhFTl9ET01D
VExfUEZJTkZPX0JST0tFTiAgKDB4ZFU8PDI4KSAvKiBicm9rZW4gcGFnZSAqLwogI2RlZmluZSBY
RU5fRE9NQ1RMX1BGSU5GT19QQUdFRFRBQiAoMHg4VTw8MjgpCiAjZGVmaW5lIFhFTl9ET01DVExf
UEZJTkZPX0xUQUJfTUFTSyAoMHhmVTw8MjgpCiAKQEAgLTgzNSw2ICs4MzYsMTIgQEAKIHR5cGVk
ZWYgc3RydWN0IHhlbl9kb21jdGxfc2V0X2FjY2Vzc19yZXF1aXJlZCB4ZW5fZG9tY3RsX3NldF9h
Y2Nlc3NfcmVxdWlyZWRfdDsKIERFRklORV9YRU5fR1VFU1RfSEFORExFKHhlbl9kb21jdGxfc2V0
X2FjY2Vzc19yZXF1aXJlZF90KTsKIAorc3RydWN0IHhlbl9kb21jdGxfc2V0X2Jyb2tlbl9wYWdl
X3AybSB7CisgICAgdWludDY0X2FsaWduZWRfdCBwZm47Cit9OwordHlwZWRlZiBzdHJ1Y3QgeGVu
X2RvbWN0bF9zZXRfYnJva2VuX3BhZ2VfcDJtIHhlbl9kb21jdGxfc2V0X2Jyb2tlbl9wYWdlX3Ay
bV90OworREVGSU5FX1hFTl9HVUVTVF9IQU5ETEUoeGVuX2RvbWN0bF9zZXRfYnJva2VuX3BhZ2Vf
cDJtX3QpOworCiBzdHJ1Y3QgeGVuX2RvbWN0bCB7CiAgICAgdWludDMyX3QgY21kOwogI2RlZmlu
ZSBYRU5fRE9NQ1RMX2NyZWF0ZWRvbWFpbiAgICAgICAgICAgICAgICAgICAxCkBAIC05MDAsNiAr
OTA3LDcgQEAKICNkZWZpbmUgWEVOX0RPTUNUTF9zZXRfYWNjZXNzX3JlcXVpcmVkICAgICAgICAg
ICA2NAogI2RlZmluZSBYRU5fRE9NQ1RMX2F1ZGl0X3AybSAgICAgICAgICAgICAgICAgICAgIDY1
CiAjZGVmaW5lIFhFTl9ET01DVExfc2V0X3ZpcnFfaGFuZGxlciAgICAgICAgICAgICAgNjYKKyNk
ZWZpbmUgWEVOX0RPTUNUTF9zZXRfYnJva2VuX3BhZ2VfcDJtICAgICAgICAgICA2NwogI2RlZmlu
ZSBYRU5fRE9NQ1RMX2dkYnN4X2d1ZXN0bWVtaW8gICAgICAgICAgICAxMDAwCiAjZGVmaW5lIFhF
Tl9ET01DVExfZ2Ric3hfcGF1c2V2Y3B1ICAgICAgICAgICAgIDEwMDEKICNkZWZpbmUgWEVOX0RP
TUNUTF9nZGJzeF91bnBhdXNldmNwdSAgICAgICAgICAgMTAwMgpAQCAtOTU1LDYgKzk2Myw3IEBA
CiAgICAgICAgIHN0cnVjdCB4ZW5fZG9tY3RsX2F1ZGl0X3AybSAgICAgICAgIGF1ZGl0X3AybTsK
ICAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfc2V0X3ZpcnFfaGFuZGxlciAgc2V0X3ZpcnFfaGFu
ZGxlcjsKICAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfZ2Ric3hfbWVtaW8gICAgICAgZ2Ric3hf
Z3Vlc3RfbWVtaW87CisgICAgICAgIHN0cnVjdCB4ZW5fZG9tY3RsX3NldF9icm9rZW5fcGFnZV9w
Mm0gc2V0X2Jyb2tlbl9wYWdlX3AybTsKICAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfZ2Ric3hf
cGF1c2V1bnBfdmNwdSBnZGJzeF9wYXVzZXVucF92Y3B1OwogICAgICAgICBzdHJ1Y3QgeGVuX2Rv
bWN0bF9nZGJzeF9kb21zdGF0dXMgICBnZGJzeF9kb21zdGF0dXM7CiAgICAgICAgIHVpbnQ4X3Qg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBhZFsxMjhdOwo=

--_002_DE8DF0795D48FD4CA783C40EC8292335374280SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC8292335374280SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Mon Oct 29 15:23:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 15:23:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSrAs-0004WA-EB; Mon, 29 Oct 2012 15:22:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSrAq-0004Vz-OH
	for xen-devel@lists.xensource.com; Mon, 29 Oct 2012 15:22:45 +0000
Received: from [193.109.254.147:60444] by server-2.bemta-14.messagelabs.com id
	76/55-19917-34F9E805; Mon, 29 Oct 2012 15:22:43 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1351524161!6198552!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMzNzg3NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15223 invoked from network); 29 Oct 2012 15:22:42 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-5.tower-27.messagelabs.com with SMTP;
	29 Oct 2012 15:22:42 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 29 Oct 2012 08:22:40 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,672,1344236400"; d="scan'208";a="239839621"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by fmsmga001.fm.intel.com with ESMTP; 29 Oct 2012 08:22:40 -0700
Received: from FMSMSX110.amr.corp.intel.com (10.19.9.29) by
	FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 29 Oct 2012 08:22:39 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	fmsmsx110.amr.corp.intel.com (10.19.9.29) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 29 Oct 2012 08:22:39 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.186]) with mapi id
	14.01.0355.002; Mon, 29 Oct 2012 23:22:37 +0800
From: "Liu, Jinsong" 
To: George Dunlap , Ian Jackson
	
Thread-Topic: [PATCH 5/5] Xen/MCE: handle broken page occurs during migration
Thread-Index: AQHNsEjdaBRa8rOqkUOTeDJn2J5LNJfQcZkg
Date: Mon, 29 Oct 2012 15:22:37 +0000
Message-ID: 
References: 
	
	
	<50852EB6.4060705@eu.citrix.com>
In-Reply-To: <50852EB6.4060705@eu.citrix.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC8292335374296SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	Jan Beulich 
Subject: [Xen-devel] [PATCH 5/5] Xen/MCE: handle broken page occurs during
	migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC8292335374296SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Xen/MCE: handle broken page occurs during migration

This patch handles broken page which occurs during migration.

It monitors the critical area of live migration (from vMCE point of view,
the copypages stage of migration is the critical area while other areas are=
 not).

If a vMCE occur at the critical area of live migration, it marks the broken=
 page
to dirty map, so that at copypages stage of migration, its pfn_type
and pfn number would transfer to target and then take appropriate action.

At target, it would set p2m as p2m_ram_broken for broken page, so that if
guest access the broken page again, it would kill itself as expected.

Suggested-by: George Dunlap 
Signed-off-by: Liu, Jinsong 

diff -r 3313ee9f6142 tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c	Thu Oct 25 05:49:11 2012 +0800
+++ b/tools/libxc/xc_domain.c	Tue Oct 30 06:07:05 2012 +0800
@@ -299,6 +299,24 @@
     return ret ? -1 : 0;
 }
=20
+/* start/end vmce monitor */
+int xc_domain_vmce_monitor(xc_interface *xch,
+                           uint32_t domid,
+                           uint32_t start)
+{
+    int ret;
+    DECLARE_DOMCTL;
+
+    if ( start )
+        domctl.cmd =3D XEN_DOMCTL_vmce_monitor_start;
+    else
+        domctl.cmd =3D XEN_DOMCTL_vmce_monitor_end;
+    domctl.domain =3D (domid_t)domid;
+    ret =3D do_domctl(xch, &domctl);
+
+    return ret ? -1 : 0;
+}
+
 /* get info from hvm guest for save */
 int xc_domain_hvm_getcontext(xc_interface *xch,
                              uint32_t domid,
diff -r 3313ee9f6142 tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Thu Oct 25 05:49:11 2012 +0800
+++ b/tools/libxc/xc_domain_save.c	Tue Oct 30 06:07:05 2012 +0800
@@ -1109,6 +1109,13 @@
         goto out;
     }
=20
+    /* Start vmce monitor */
+    if ( xc_domain_vmce_monitor(xch, dom, 1) )
+    {
+        PERROR("Error starting vmce monitor");
+        goto out;
+    }
+
   copypages:
 #define wrexact(fd, buf, len) write_buffer(xch, last_iter, ob, (fd), (buf)=
, (len))
 #define wruncached(fd, live, buf, len) write_uncached(xch, last_iter, ob, =
(fd), (buf), (len))
@@ -1582,6 +1589,13 @@
=20
     DPRINTF("All memory is saved\n");
=20
+    /* End vmce monitor */
+    if ( xc_domain_vmce_monitor(xch, dom, 0) )
+    {
+        PERROR("Error ending vmce monitor");
+        goto out;
+    }
+
     /* After last_iter, buffer the rest of pagebuf & tailbuf data into a
      * separate output buffer and flush it after the compressed page chunk=
s.
      */
diff -r 3313ee9f6142 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Thu Oct 25 05:49:11 2012 +0800
+++ b/tools/libxc/xenctrl.h	Tue Oct 30 06:07:05 2012 +0800
@@ -586,6 +586,17 @@
                            unsigned long pfn);
=20
 /**
+ * This function start/end monitor vmce event.
+ * @parm xch a handle to an open hypervisor interface
+ * @parm domid the domain id monitored
+ * @parm flag to start/end monitor
+ * @return <0 on failure, 0 on success
+ */
+int xc_domain_vmce_monitor(xc_interface *xch,
+                           uint32_t domid,
+                           uint32_t start);
+
+/**
  * This function returns information about the context of a hvm domain
  * @parm xch a handle to an open hypervisor interface
  * @parm domid the domain to get information from
diff -r 3313ee9f6142 xen/arch/x86/cpu/mcheck/mce_intel.c
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c	Thu Oct 25 05:49:11 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c	Tue Oct 30 06:07:05 2012 +0800
@@ -342,6 +342,22 @@
                     goto vmce_failed;
                 }
=20
+                if ( unlikely(d->arch.vmce_monitor) )
+                {
+                    /*
+                     * vMCE occur during migration
+                     *
+                     * mark broken page to dirty bitmap, so that at copypa=
ges
+                     * stage of migration, its pfn_type and pfn number wou=
ld
+                     * transfer to target and then take appropriate action
+                     *
+                     * At target, it would set p2m as p2m_ram_broken for b=
roken
+                     * page, so that if guest access the broken page again=
, it
+                     * would kill itself as expected.
+                     */
+                    paging_mark_dirty(d, mfn);
+                }
+
                 if ( unmmap_broken_page(d, _mfn(mfn), gfn) )
                 {
                     printk("Unmap broken memory %lx for DOM%d failed\n",
diff -r 3313ee9f6142 xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c	Thu Oct 25 05:49:11 2012 +0800
+++ b/xen/arch/x86/domctl.c	Tue Oct 30 06:07:05 2012 +0800
@@ -1599,6 +1599,44 @@
     }
     break;
=20
+    case XEN_DOMCTL_vmce_monitor_start:
+    {
+        struct domain *d;
+
+        d =3D rcu_lock_domain_by_id(domctl->domain);
+        if ( d !=3D NULL )
+        {
+            if ( d->arch.vmce_monitor )
+                ret =3D -EBUSY;
+            else
+                d->arch.vmce_monitor =3D 1;
+
+            rcu_unlock_domain(d);
+        }
+        else
+            ret =3D -ESRCH;
+    }
+    break;
+
+    case XEN_DOMCTL_vmce_monitor_end:
+    {
+        struct domain *d;
+
+        d =3D rcu_lock_domain_by_id(domctl->domain);
+        if ( d !=3D NULL)
+        {
+            if ( !d->arch.vmce_monitor )
+                ret =3D -EINVAL;
+            else
+                d->arch.vmce_monitor =3D 0;
+
+            rcu_unlock_domain(d);
+        }
+        else
+            ret =3D -ESRCH;
+    }
+    break;
+
     default:
         ret =3D iommu_do_domctl(domctl, u_domctl);
         break;
diff -r 3313ee9f6142 xen/include/asm-x86/domain.h
--- a/xen/include/asm-x86/domain.h	Thu Oct 25 05:49:11 2012 +0800
+++ b/xen/include/asm-x86/domain.h	Tue Oct 30 06:07:05 2012 +0800
@@ -279,6 +279,10 @@
     bool_t has_32bit_shinfo;
     /* Domain cannot handle spurious page faults? */
     bool_t suppress_spurious_page_faults;
+    /* Monitoring guest memory copy of migration
+     * =3D 0 - not monitoring
+     * =3D 1 - monitoring */
+    bool_t vmce_monitor;
=20
     /* Continuable domain_relinquish_resources(). */
     enum {
diff -r 3313ee9f6142 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h	Thu Oct 25 05:49:11 2012 +0800
+++ b/xen/include/public/domctl.h	Tue Oct 30 06:07:05 2012 +0800
@@ -908,6 +908,8 @@
 #define XEN_DOMCTL_audit_p2m                     65
 #define XEN_DOMCTL_set_virq_handler              66
 #define XEN_DOMCTL_set_broken_page_p2m           67
+#define XEN_DOMCTL_vmce_monitor_start            68
+#define XEN_DOMCTL_vmce_monitor_end              69
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002=

--_002_DE8DF0795D48FD4CA783C40EC8292335374296SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="5_vmce_during_migration.patch"
Content-Description: 5_vmce_during_migration.patch
Content-Disposition: attachment; filename="5_vmce_during_migration.patch";
	size=6739; creation-date="Mon, 29 Oct 2012 15:18:32 GMT";
	modification-date="Mon, 29 Oct 2012 23:10:12 GMT"
Content-Transfer-Encoding: base64

WGVuL01DRTogaGFuZGxlIGJyb2tlbiBwYWdlIG9jY3VycyBkdXJpbmcgbWlncmF0aW9uCgpUaGlz
IHBhdGNoIGhhbmRsZXMgYnJva2VuIHBhZ2Ugd2hpY2ggb2NjdXJzIGR1cmluZyBtaWdyYXRpb24u
CgpJdCBtb25pdG9ycyB0aGUgY3JpdGljYWwgYXJlYSBvZiBsaXZlIG1pZ3JhdGlvbiAoZnJvbSB2
TUNFIHBvaW50IG9mIHZpZXcsCnRoZSBjb3B5cGFnZXMgc3RhZ2Ugb2YgbWlncmF0aW9uIGlzIHRo
ZSBjcml0aWNhbCBhcmVhIHdoaWxlIG90aGVyIGFyZWFzIGFyZSBub3QpLgoKSWYgYSB2TUNFIG9j
Y3VyIGF0IHRoZSBjcml0aWNhbCBhcmVhIG9mIGxpdmUgbWlncmF0aW9uLCBpdCBtYXJrcyB0aGUg
YnJva2VuIHBhZ2UKdG8gZGlydHkgbWFwLCBzbyB0aGF0IGF0IGNvcHlwYWdlcyBzdGFnZSBvZiBt
aWdyYXRpb24sIGl0cyBwZm5fdHlwZQphbmQgcGZuIG51bWJlciB3b3VsZCB0cmFuc2ZlciB0byB0
YXJnZXQgYW5kIHRoZW4gdGFrZSBhcHByb3ByaWF0ZSBhY3Rpb24uCgpBdCB0YXJnZXQsIGl0IHdv
dWxkIHNldCBwMm0gYXMgcDJtX3JhbV9icm9rZW4gZm9yIGJyb2tlbiBwYWdlLCBzbyB0aGF0IGlm
Cmd1ZXN0IGFjY2VzcyB0aGUgYnJva2VuIHBhZ2UgYWdhaW4sIGl0IHdvdWxkIGtpbGwgaXRzZWxm
IGFzIGV4cGVjdGVkLgoKU3VnZ2VzdGVkLWJ5OiBHZW9yZ2UgRHVubGFwIDxnZW9yZ2UuZHVubGFw
QGV1LmNpdHJpeC5jb20+ClNpZ25lZC1vZmYtYnk6IExpdSwgSmluc29uZyA8amluc29uZy5saXVA
aW50ZWwuY29tPgoKZGlmZiAtciAzMzEzZWU5ZjYxNDIgdG9vbHMvbGlieGMveGNfZG9tYWluLmMK
LS0tIGEvdG9vbHMvbGlieGMveGNfZG9tYWluLmMJVGh1IE9jdCAyNSAwNTo0OToxMSAyMDEyICsw
ODAwCisrKyBiL3Rvb2xzL2xpYnhjL3hjX2RvbWFpbi5jCVR1ZSBPY3QgMzAgMDY6MDc6MDUgMjAx
MiArMDgwMApAQCAtMjk5LDYgKzI5OSwyNCBAQAogICAgIHJldHVybiByZXQgPyAtMSA6IDA7CiB9
CiAKKy8qIHN0YXJ0L2VuZCB2bWNlIG1vbml0b3IgKi8KK2ludCB4Y19kb21haW5fdm1jZV9tb25p
dG9yKHhjX2ludGVyZmFjZSAqeGNoLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMy
X3QgZG9taWQsCisgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJfdCBzdGFydCkKK3sK
KyAgICBpbnQgcmV0OworICAgIERFQ0xBUkVfRE9NQ1RMOworCisgICAgaWYgKCBzdGFydCApCisg
ICAgICAgIGRvbWN0bC5jbWQgPSBYRU5fRE9NQ1RMX3ZtY2VfbW9uaXRvcl9zdGFydDsKKyAgICBl
bHNlCisgICAgICAgIGRvbWN0bC5jbWQgPSBYRU5fRE9NQ1RMX3ZtY2VfbW9uaXRvcl9lbmQ7Cisg
ICAgZG9tY3RsLmRvbWFpbiA9IChkb21pZF90KWRvbWlkOworICAgIHJldCA9IGRvX2RvbWN0bCh4
Y2gsICZkb21jdGwpOworCisgICAgcmV0dXJuIHJldCA/IC0xIDogMDsKK30KKwogLyogZ2V0IGlu
Zm8gZnJvbSBodm0gZ3Vlc3QgZm9yIHNhdmUgKi8KIGludCB4Y19kb21haW5faHZtX2dldGNvbnRl
eHQoeGNfaW50ZXJmYWNlICp4Y2gsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQz
Ml90IGRvbWlkLApkaWZmIC1yIDMzMTNlZTlmNjE0MiB0b29scy9saWJ4Yy94Y19kb21haW5fc2F2
ZS5jCi0tLSBhL3Rvb2xzL2xpYnhjL3hjX2RvbWFpbl9zYXZlLmMJVGh1IE9jdCAyNSAwNTo0OTox
MSAyMDEyICswODAwCisrKyBiL3Rvb2xzL2xpYnhjL3hjX2RvbWFpbl9zYXZlLmMJVHVlIE9jdCAz
MCAwNjowNzowNSAyMDEyICswODAwCkBAIC0xMTA5LDYgKzExMDksMTMgQEAKICAgICAgICAgZ290
byBvdXQ7CiAgICAgfQogCisgICAgLyogU3RhcnQgdm1jZSBtb25pdG9yICovCisgICAgaWYgKCB4
Y19kb21haW5fdm1jZV9tb25pdG9yKHhjaCwgZG9tLCAxKSApCisgICAgeworICAgICAgICBQRVJS
T1IoIkVycm9yIHN0YXJ0aW5nIHZtY2UgbW9uaXRvciIpOworICAgICAgICBnb3RvIG91dDsKKyAg
ICB9CisKICAgY29weXBhZ2VzOgogI2RlZmluZSB3cmV4YWN0KGZkLCBidWYsIGxlbikgd3JpdGVf
YnVmZmVyKHhjaCwgbGFzdF9pdGVyLCBvYiwgKGZkKSwgKGJ1ZiksIChsZW4pKQogI2RlZmluZSB3
cnVuY2FjaGVkKGZkLCBsaXZlLCBidWYsIGxlbikgd3JpdGVfdW5jYWNoZWQoeGNoLCBsYXN0X2l0
ZXIsIG9iLCAoZmQpLCAoYnVmKSwgKGxlbikpCkBAIC0xNTgyLDYgKzE1ODksMTMgQEAKIAogICAg
IERQUklOVEYoIkFsbCBtZW1vcnkgaXMgc2F2ZWRcbiIpOwogCisgICAgLyogRW5kIHZtY2UgbW9u
aXRvciAqLworICAgIGlmICggeGNfZG9tYWluX3ZtY2VfbW9uaXRvcih4Y2gsIGRvbSwgMCkgKQor
ICAgIHsKKyAgICAgICAgUEVSUk9SKCJFcnJvciBlbmRpbmcgdm1jZSBtb25pdG9yIik7CisgICAg
ICAgIGdvdG8gb3V0OworICAgIH0KKwogICAgIC8qIEFmdGVyIGxhc3RfaXRlciwgYnVmZmVyIHRo
ZSByZXN0IG9mIHBhZ2VidWYgJiB0YWlsYnVmIGRhdGEgaW50byBhCiAgICAgICogc2VwYXJhdGUg
b3V0cHV0IGJ1ZmZlciBhbmQgZmx1c2ggaXQgYWZ0ZXIgdGhlIGNvbXByZXNzZWQgcGFnZSBjaHVu
a3MuCiAgICAgICovCmRpZmYgLXIgMzMxM2VlOWY2MTQyIHRvb2xzL2xpYnhjL3hlbmN0cmwuaAot
LS0gYS90b29scy9saWJ4Yy94ZW5jdHJsLmgJVGh1IE9jdCAyNSAwNTo0OToxMSAyMDEyICswODAw
CisrKyBiL3Rvb2xzL2xpYnhjL3hlbmN0cmwuaAlUdWUgT2N0IDMwIDA2OjA3OjA1IDIwMTIgKzA4
MDAKQEAgLTU4Niw2ICs1ODYsMTcgQEAKICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVuc2ln
bmVkIGxvbmcgcGZuKTsKIAogLyoqCisgKiBUaGlzIGZ1bmN0aW9uIHN0YXJ0L2VuZCBtb25pdG9y
IHZtY2UgZXZlbnQuCisgKiBAcGFybSB4Y2ggYSBoYW5kbGUgdG8gYW4gb3BlbiBoeXBlcnZpc29y
IGludGVyZmFjZQorICogQHBhcm0gZG9taWQgdGhlIGRvbWFpbiBpZCBtb25pdG9yZWQKKyAqIEBw
YXJtIGZsYWcgdG8gc3RhcnQvZW5kIG1vbml0b3IKKyAqIEByZXR1cm4gPDAgb24gZmFpbHVyZSwg
MCBvbiBzdWNjZXNzCisgKi8KK2ludCB4Y19kb21haW5fdm1jZV9tb25pdG9yKHhjX2ludGVyZmFj
ZSAqeGNoLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZG9taWQsCisgICAg
ICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJfdCBzdGFydCk7CisKKy8qKgogICogVGhpcyBm
dW5jdGlvbiByZXR1cm5zIGluZm9ybWF0aW9uIGFib3V0IHRoZSBjb250ZXh0IG9mIGEgaHZtIGRv
bWFpbgogICogQHBhcm0geGNoIGEgaGFuZGxlIHRvIGFuIG9wZW4gaHlwZXJ2aXNvciBpbnRlcmZh
Y2UKICAqIEBwYXJtIGRvbWlkIHRoZSBkb21haW4gdG8gZ2V0IGluZm9ybWF0aW9uIGZyb20KZGlm
ZiAtciAzMzEzZWU5ZjYxNDIgeGVuL2FyY2gveDg2L2NwdS9tY2hlY2svbWNlX2ludGVsLmMKLS0t
IGEveGVuL2FyY2gveDg2L2NwdS9tY2hlY2svbWNlX2ludGVsLmMJVGh1IE9jdCAyNSAwNTo0OTox
MSAyMDEyICswODAwCisrKyBiL3hlbi9hcmNoL3g4Ni9jcHUvbWNoZWNrL21jZV9pbnRlbC5jCVR1
ZSBPY3QgMzAgMDY6MDc6MDUgMjAxMiArMDgwMApAQCAtMzQyLDYgKzM0MiwyMiBAQAogICAgICAg
ICAgICAgICAgICAgICBnb3RvIHZtY2VfZmFpbGVkOwogICAgICAgICAgICAgICAgIH0KIAorICAg
ICAgICAgICAgICAgIGlmICggdW5saWtlbHkoZC0+YXJjaC52bWNlX21vbml0b3IpICkKKyAgICAg
ICAgICAgICAgICB7CisgICAgICAgICAgICAgICAgICAgIC8qCisgICAgICAgICAgICAgICAgICAg
ICAqIHZNQ0Ugb2NjdXIgZHVyaW5nIG1pZ3JhdGlvbgorICAgICAgICAgICAgICAgICAgICAgKgor
ICAgICAgICAgICAgICAgICAgICAgKiBtYXJrIGJyb2tlbiBwYWdlIHRvIGRpcnR5IGJpdG1hcCwg
c28gdGhhdCBhdCBjb3B5cGFnZXMKKyAgICAgICAgICAgICAgICAgICAgICogc3RhZ2Ugb2YgbWln
cmF0aW9uLCBpdHMgcGZuX3R5cGUgYW5kIHBmbiBudW1iZXIgd291bGQKKyAgICAgICAgICAgICAg
ICAgICAgICogdHJhbnNmZXIgdG8gdGFyZ2V0IGFuZCB0aGVuIHRha2UgYXBwcm9wcmlhdGUgYWN0
aW9uCisgICAgICAgICAgICAgICAgICAgICAqCisgICAgICAgICAgICAgICAgICAgICAqIEF0IHRh
cmdldCwgaXQgd291bGQgc2V0IHAybSBhcyBwMm1fcmFtX2Jyb2tlbiBmb3IgYnJva2VuCisgICAg
ICAgICAgICAgICAgICAgICAqIHBhZ2UsIHNvIHRoYXQgaWYgZ3Vlc3QgYWNjZXNzIHRoZSBicm9r
ZW4gcGFnZSBhZ2FpbiwgaXQKKyAgICAgICAgICAgICAgICAgICAgICogd291bGQga2lsbCBpdHNl
bGYgYXMgZXhwZWN0ZWQuCisgICAgICAgICAgICAgICAgICAgICAqLworICAgICAgICAgICAgICAg
ICAgICBwYWdpbmdfbWFya19kaXJ0eShkLCBtZm4pOworICAgICAgICAgICAgICAgIH0KKwogICAg
ICAgICAgICAgICAgIGlmICggdW5tbWFwX2Jyb2tlbl9wYWdlKGQsIF9tZm4obWZuKSwgZ2ZuKSAp
CiAgICAgICAgICAgICAgICAgewogICAgICAgICAgICAgICAgICAgICBwcmludGsoIlVubWFwIGJy
b2tlbiBtZW1vcnkgJWx4IGZvciBET00lZCBmYWlsZWRcbiIsCmRpZmYgLXIgMzMxM2VlOWY2MTQy
IHhlbi9hcmNoL3g4Ni9kb21jdGwuYwotLS0gYS94ZW4vYXJjaC94ODYvZG9tY3RsLmMJVGh1IE9j
dCAyNSAwNTo0OToxMSAyMDEyICswODAwCisrKyBiL3hlbi9hcmNoL3g4Ni9kb21jdGwuYwlUdWUg
T2N0IDMwIDA2OjA3OjA1IDIwMTIgKzA4MDAKQEAgLTE1OTksNiArMTU5OSw0NCBAQAogICAgIH0K
ICAgICBicmVhazsKIAorICAgIGNhc2UgWEVOX0RPTUNUTF92bWNlX21vbml0b3Jfc3RhcnQ6Cisg
ICAgeworICAgICAgICBzdHJ1Y3QgZG9tYWluICpkOworCisgICAgICAgIGQgPSByY3VfbG9ja19k
b21haW5fYnlfaWQoZG9tY3RsLT5kb21haW4pOworICAgICAgICBpZiAoIGQgIT0gTlVMTCApCisg
ICAgICAgIHsKKyAgICAgICAgICAgIGlmICggZC0+YXJjaC52bWNlX21vbml0b3IgKQorICAgICAg
ICAgICAgICAgIHJldCA9IC1FQlVTWTsKKyAgICAgICAgICAgIGVsc2UKKyAgICAgICAgICAgICAg
ICBkLT5hcmNoLnZtY2VfbW9uaXRvciA9IDE7CisKKyAgICAgICAgICAgIHJjdV91bmxvY2tfZG9t
YWluKGQpOworICAgICAgICB9CisgICAgICAgIGVsc2UKKyAgICAgICAgICAgIHJldCA9IC1FU1JD
SDsKKyAgICB9CisgICAgYnJlYWs7CisKKyAgICBjYXNlIFhFTl9ET01DVExfdm1jZV9tb25pdG9y
X2VuZDoKKyAgICB7CisgICAgICAgIHN0cnVjdCBkb21haW4gKmQ7CisKKyAgICAgICAgZCA9IHJj
dV9sb2NrX2RvbWFpbl9ieV9pZChkb21jdGwtPmRvbWFpbik7CisgICAgICAgIGlmICggZCAhPSBO
VUxMKQorICAgICAgICB7CisgICAgICAgICAgICBpZiAoICFkLT5hcmNoLnZtY2VfbW9uaXRvciAp
CisgICAgICAgICAgICAgICAgcmV0ID0gLUVJTlZBTDsKKyAgICAgICAgICAgIGVsc2UKKyAgICAg
ICAgICAgICAgICBkLT5hcmNoLnZtY2VfbW9uaXRvciA9IDA7CisKKyAgICAgICAgICAgIHJjdV91
bmxvY2tfZG9tYWluKGQpOworICAgICAgICB9CisgICAgICAgIGVsc2UKKyAgICAgICAgICAgIHJl
dCA9IC1FU1JDSDsKKyAgICB9CisgICAgYnJlYWs7CisKICAgICBkZWZhdWx0OgogICAgICAgICBy
ZXQgPSBpb21tdV9kb19kb21jdGwoZG9tY3RsLCB1X2RvbWN0bCk7CiAgICAgICAgIGJyZWFrOwpk
aWZmIC1yIDMzMTNlZTlmNjE0MiB4ZW4vaW5jbHVkZS9hc20teDg2L2RvbWFpbi5oCi0tLSBhL3hl
bi9pbmNsdWRlL2FzbS14ODYvZG9tYWluLmgJVGh1IE9jdCAyNSAwNTo0OToxMSAyMDEyICswODAw
CisrKyBiL3hlbi9pbmNsdWRlL2FzbS14ODYvZG9tYWluLmgJVHVlIE9jdCAzMCAwNjowNzowNSAy
MDEyICswODAwCkBAIC0yNzksNiArMjc5LDEwIEBACiAgICAgYm9vbF90IGhhc18zMmJpdF9zaGlu
Zm87CiAgICAgLyogRG9tYWluIGNhbm5vdCBoYW5kbGUgc3B1cmlvdXMgcGFnZSBmYXVsdHM/ICov
CiAgICAgYm9vbF90IHN1cHByZXNzX3NwdXJpb3VzX3BhZ2VfZmF1bHRzOworICAgIC8qIE1vbml0
b3JpbmcgZ3Vlc3QgbWVtb3J5IGNvcHkgb2YgbWlncmF0aW9uCisgICAgICogPSAwIC0gbm90IG1v
bml0b3JpbmcKKyAgICAgKiA9IDEgLSBtb25pdG9yaW5nICovCisgICAgYm9vbF90IHZtY2VfbW9u
aXRvcjsKIAogICAgIC8qIENvbnRpbnVhYmxlIGRvbWFpbl9yZWxpbnF1aXNoX3Jlc291cmNlcygp
LiAqLwogICAgIGVudW0gewpkaWZmIC1yIDMzMTNlZTlmNjE0MiB4ZW4vaW5jbHVkZS9wdWJsaWMv
ZG9tY3RsLmgKLS0tIGEveGVuL2luY2x1ZGUvcHVibGljL2RvbWN0bC5oCVRodSBPY3QgMjUgMDU6
NDk6MTEgMjAxMiArMDgwMAorKysgYi94ZW4vaW5jbHVkZS9wdWJsaWMvZG9tY3RsLmgJVHVlIE9j
dCAzMCAwNjowNzowNSAyMDEyICswODAwCkBAIC05MDgsNiArOTA4LDggQEAKICNkZWZpbmUgWEVO
X0RPTUNUTF9hdWRpdF9wMm0gICAgICAgICAgICAgICAgICAgICA2NQogI2RlZmluZSBYRU5fRE9N
Q1RMX3NldF92aXJxX2hhbmRsZXIgICAgICAgICAgICAgIDY2CiAjZGVmaW5lIFhFTl9ET01DVExf
c2V0X2Jyb2tlbl9wYWdlX3AybSAgICAgICAgICAgNjcKKyNkZWZpbmUgWEVOX0RPTUNUTF92bWNl
X21vbml0b3Jfc3RhcnQgICAgICAgICAgICA2OAorI2RlZmluZSBYRU5fRE9NQ1RMX3ZtY2VfbW9u
aXRvcl9lbmQgICAgICAgICAgICAgIDY5CiAjZGVmaW5lIFhFTl9ET01DVExfZ2Ric3hfZ3Vlc3Rt
ZW1pbyAgICAgICAgICAgIDEwMDAKICNkZWZpbmUgWEVOX0RPTUNUTF9nZGJzeF9wYXVzZXZjcHUg
ICAgICAgICAgICAgMTAwMQogI2RlZmluZSBYRU5fRE9NQ1RMX2dkYnN4X3VucGF1c2V2Y3B1ICAg
ICAgICAgICAxMDAyCg==

--_002_DE8DF0795D48FD4CA783C40EC8292335374296SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC8292335374296SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Mon Oct 29 15:23:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 15:23:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSrAs-0004WA-EB; Mon, 29 Oct 2012 15:22:46 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSrAq-0004Vz-OH
	for xen-devel@lists.xensource.com; Mon, 29 Oct 2012 15:22:45 +0000
Received: from [193.109.254.147:60444] by server-2.bemta-14.messagelabs.com id
	76/55-19917-34F9E805; Mon, 29 Oct 2012 15:22:43 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1351524161!6198552!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMzNzg3NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15223 invoked from network); 29 Oct 2012 15:22:42 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-5.tower-27.messagelabs.com with SMTP;
	29 Oct 2012 15:22:42 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 29 Oct 2012 08:22:40 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,672,1344236400"; d="scan'208";a="239839621"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by fmsmga001.fm.intel.com with ESMTP; 29 Oct 2012 08:22:40 -0700
Received: from FMSMSX110.amr.corp.intel.com (10.19.9.29) by
	FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 29 Oct 2012 08:22:39 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	fmsmsx110.amr.corp.intel.com (10.19.9.29) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 29 Oct 2012 08:22:39 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.186]) with mapi id
	14.01.0355.002; Mon, 29 Oct 2012 23:22:37 +0800
From: "Liu, Jinsong" 
To: George Dunlap , Ian Jackson
	
Thread-Topic: [PATCH 5/5] Xen/MCE: handle broken page occurs during migration
Thread-Index: AQHNsEjdaBRa8rOqkUOTeDJn2J5LNJfQcZkg
Date: Mon, 29 Oct 2012 15:22:37 +0000
Message-ID: 
References: 
	
	
	<50852EB6.4060705@eu.citrix.com>
In-Reply-To: <50852EB6.4060705@eu.citrix.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC8292335374296SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	Jan Beulich 
Subject: [Xen-devel] [PATCH 5/5] Xen/MCE: handle broken page occurs during
	migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC8292335374296SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Xen/MCE: handle broken page occurs during migration

This patch handles broken page which occurs during migration.

It monitors the critical area of live migration (from vMCE point of view,
the copypages stage of migration is the critical area while other areas are=
 not).

If a vMCE occur at the critical area of live migration, it marks the broken=
 page
to dirty map, so that at copypages stage of migration, its pfn_type
and pfn number would transfer to target and then take appropriate action.

At target, it would set p2m as p2m_ram_broken for broken page, so that if
guest access the broken page again, it would kill itself as expected.

Suggested-by: George Dunlap 
Signed-off-by: Liu, Jinsong 

diff -r 3313ee9f6142 tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c	Thu Oct 25 05:49:11 2012 +0800
+++ b/tools/libxc/xc_domain.c	Tue Oct 30 06:07:05 2012 +0800
@@ -299,6 +299,24 @@
     return ret ? -1 : 0;
 }
=20
+/* start/end vmce monitor */
+int xc_domain_vmce_monitor(xc_interface *xch,
+                           uint32_t domid,
+                           uint32_t start)
+{
+    int ret;
+    DECLARE_DOMCTL;
+
+    if ( start )
+        domctl.cmd =3D XEN_DOMCTL_vmce_monitor_start;
+    else
+        domctl.cmd =3D XEN_DOMCTL_vmce_monitor_end;
+    domctl.domain =3D (domid_t)domid;
+    ret =3D do_domctl(xch, &domctl);
+
+    return ret ? -1 : 0;
+}
+
 /* get info from hvm guest for save */
 int xc_domain_hvm_getcontext(xc_interface *xch,
                              uint32_t domid,
diff -r 3313ee9f6142 tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Thu Oct 25 05:49:11 2012 +0800
+++ b/tools/libxc/xc_domain_save.c	Tue Oct 30 06:07:05 2012 +0800
@@ -1109,6 +1109,13 @@
         goto out;
     }
=20
+    /* Start vmce monitor */
+    if ( xc_domain_vmce_monitor(xch, dom, 1) )
+    {
+        PERROR("Error starting vmce monitor");
+        goto out;
+    }
+
   copypages:
 #define wrexact(fd, buf, len) write_buffer(xch, last_iter, ob, (fd), (buf)=
, (len))
 #define wruncached(fd, live, buf, len) write_uncached(xch, last_iter, ob, =
(fd), (buf), (len))
@@ -1582,6 +1589,13 @@
=20
     DPRINTF("All memory is saved\n");
=20
+    /* End vmce monitor */
+    if ( xc_domain_vmce_monitor(xch, dom, 0) )
+    {
+        PERROR("Error ending vmce monitor");
+        goto out;
+    }
+
     /* After last_iter, buffer the rest of pagebuf & tailbuf data into a
      * separate output buffer and flush it after the compressed page chunk=
s.
      */
diff -r 3313ee9f6142 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Thu Oct 25 05:49:11 2012 +0800
+++ b/tools/libxc/xenctrl.h	Tue Oct 30 06:07:05 2012 +0800
@@ -586,6 +586,17 @@
                            unsigned long pfn);
=20
 /**
+ * This function start/end monitor vmce event.
+ * @parm xch a handle to an open hypervisor interface
+ * @parm domid the domain id monitored
+ * @parm flag to start/end monitor
+ * @return <0 on failure, 0 on success
+ */
+int xc_domain_vmce_monitor(xc_interface *xch,
+                           uint32_t domid,
+                           uint32_t start);
+
+/**
  * This function returns information about the context of a hvm domain
  * @parm xch a handle to an open hypervisor interface
  * @parm domid the domain to get information from
diff -r 3313ee9f6142 xen/arch/x86/cpu/mcheck/mce_intel.c
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c	Thu Oct 25 05:49:11 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c	Tue Oct 30 06:07:05 2012 +0800
@@ -342,6 +342,22 @@
                     goto vmce_failed;
                 }
=20
+                if ( unlikely(d->arch.vmce_monitor) )
+                {
+                    /*
+                     * vMCE occur during migration
+                     *
+                     * mark broken page to dirty bitmap, so that at copypa=
ges
+                     * stage of migration, its pfn_type and pfn number wou=
ld
+                     * transfer to target and then take appropriate action
+                     *
+                     * At target, it would set p2m as p2m_ram_broken for b=
roken
+                     * page, so that if guest access the broken page again=
, it
+                     * would kill itself as expected.
+                     */
+                    paging_mark_dirty(d, mfn);
+                }
+
                 if ( unmmap_broken_page(d, _mfn(mfn), gfn) )
                 {
                     printk("Unmap broken memory %lx for DOM%d failed\n",
diff -r 3313ee9f6142 xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c	Thu Oct 25 05:49:11 2012 +0800
+++ b/xen/arch/x86/domctl.c	Tue Oct 30 06:07:05 2012 +0800
@@ -1599,6 +1599,44 @@
     }
     break;
=20
+    case XEN_DOMCTL_vmce_monitor_start:
+    {
+        struct domain *d;
+
+        d =3D rcu_lock_domain_by_id(domctl->domain);
+        if ( d !=3D NULL )
+        {
+            if ( d->arch.vmce_monitor )
+                ret =3D -EBUSY;
+            else
+                d->arch.vmce_monitor =3D 1;
+
+            rcu_unlock_domain(d);
+        }
+        else
+            ret =3D -ESRCH;
+    }
+    break;
+
+    case XEN_DOMCTL_vmce_monitor_end:
+    {
+        struct domain *d;
+
+        d =3D rcu_lock_domain_by_id(domctl->domain);
+        if ( d !=3D NULL)
+        {
+            if ( !d->arch.vmce_monitor )
+                ret =3D -EINVAL;
+            else
+                d->arch.vmce_monitor =3D 0;
+
+            rcu_unlock_domain(d);
+        }
+        else
+            ret =3D -ESRCH;
+    }
+    break;
+
     default:
         ret =3D iommu_do_domctl(domctl, u_domctl);
         break;
diff -r 3313ee9f6142 xen/include/asm-x86/domain.h
--- a/xen/include/asm-x86/domain.h	Thu Oct 25 05:49:11 2012 +0800
+++ b/xen/include/asm-x86/domain.h	Tue Oct 30 06:07:05 2012 +0800
@@ -279,6 +279,10 @@
     bool_t has_32bit_shinfo;
     /* Domain cannot handle spurious page faults? */
     bool_t suppress_spurious_page_faults;
+    /* Monitoring guest memory copy of migration
+     * =3D 0 - not monitoring
+     * =3D 1 - monitoring */
+    bool_t vmce_monitor;
=20
     /* Continuable domain_relinquish_resources(). */
     enum {
diff -r 3313ee9f6142 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h	Thu Oct 25 05:49:11 2012 +0800
+++ b/xen/include/public/domctl.h	Tue Oct 30 06:07:05 2012 +0800
@@ -908,6 +908,8 @@
 #define XEN_DOMCTL_audit_p2m                     65
 #define XEN_DOMCTL_set_virq_handler              66
 #define XEN_DOMCTL_set_broken_page_p2m           67
+#define XEN_DOMCTL_vmce_monitor_start            68
+#define XEN_DOMCTL_vmce_monitor_end              69
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002=

--_002_DE8DF0795D48FD4CA783C40EC8292335374296SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="5_vmce_during_migration.patch"
Content-Description: 5_vmce_during_migration.patch
Content-Disposition: attachment; filename="5_vmce_during_migration.patch";
	size=6739; creation-date="Mon, 29 Oct 2012 15:18:32 GMT";
	modification-date="Mon, 29 Oct 2012 23:10:12 GMT"
Content-Transfer-Encoding: base64

WGVuL01DRTogaGFuZGxlIGJyb2tlbiBwYWdlIG9jY3VycyBkdXJpbmcgbWlncmF0aW9uCgpUaGlz
IHBhdGNoIGhhbmRsZXMgYnJva2VuIHBhZ2Ugd2hpY2ggb2NjdXJzIGR1cmluZyBtaWdyYXRpb24u
CgpJdCBtb25pdG9ycyB0aGUgY3JpdGljYWwgYXJlYSBvZiBsaXZlIG1pZ3JhdGlvbiAoZnJvbSB2
TUNFIHBvaW50IG9mIHZpZXcsCnRoZSBjb3B5cGFnZXMgc3RhZ2Ugb2YgbWlncmF0aW9uIGlzIHRo
ZSBjcml0aWNhbCBhcmVhIHdoaWxlIG90aGVyIGFyZWFzIGFyZSBub3QpLgoKSWYgYSB2TUNFIG9j
Y3VyIGF0IHRoZSBjcml0aWNhbCBhcmVhIG9mIGxpdmUgbWlncmF0aW9uLCBpdCBtYXJrcyB0aGUg
YnJva2VuIHBhZ2UKdG8gZGlydHkgbWFwLCBzbyB0aGF0IGF0IGNvcHlwYWdlcyBzdGFnZSBvZiBt
aWdyYXRpb24sIGl0cyBwZm5fdHlwZQphbmQgcGZuIG51bWJlciB3b3VsZCB0cmFuc2ZlciB0byB0
YXJnZXQgYW5kIHRoZW4gdGFrZSBhcHByb3ByaWF0ZSBhY3Rpb24uCgpBdCB0YXJnZXQsIGl0IHdv
dWxkIHNldCBwMm0gYXMgcDJtX3JhbV9icm9rZW4gZm9yIGJyb2tlbiBwYWdlLCBzbyB0aGF0IGlm
Cmd1ZXN0IGFjY2VzcyB0aGUgYnJva2VuIHBhZ2UgYWdhaW4sIGl0IHdvdWxkIGtpbGwgaXRzZWxm
IGFzIGV4cGVjdGVkLgoKU3VnZ2VzdGVkLWJ5OiBHZW9yZ2UgRHVubGFwIDxnZW9yZ2UuZHVubGFw
QGV1LmNpdHJpeC5jb20+ClNpZ25lZC1vZmYtYnk6IExpdSwgSmluc29uZyA8amluc29uZy5saXVA
aW50ZWwuY29tPgoKZGlmZiAtciAzMzEzZWU5ZjYxNDIgdG9vbHMvbGlieGMveGNfZG9tYWluLmMK
LS0tIGEvdG9vbHMvbGlieGMveGNfZG9tYWluLmMJVGh1IE9jdCAyNSAwNTo0OToxMSAyMDEyICsw
ODAwCisrKyBiL3Rvb2xzL2xpYnhjL3hjX2RvbWFpbi5jCVR1ZSBPY3QgMzAgMDY6MDc6MDUgMjAx
MiArMDgwMApAQCAtMjk5LDYgKzI5OSwyNCBAQAogICAgIHJldHVybiByZXQgPyAtMSA6IDA7CiB9
CiAKKy8qIHN0YXJ0L2VuZCB2bWNlIG1vbml0b3IgKi8KK2ludCB4Y19kb21haW5fdm1jZV9tb25p
dG9yKHhjX2ludGVyZmFjZSAqeGNoLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMy
X3QgZG9taWQsCisgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJfdCBzdGFydCkKK3sK
KyAgICBpbnQgcmV0OworICAgIERFQ0xBUkVfRE9NQ1RMOworCisgICAgaWYgKCBzdGFydCApCisg
ICAgICAgIGRvbWN0bC5jbWQgPSBYRU5fRE9NQ1RMX3ZtY2VfbW9uaXRvcl9zdGFydDsKKyAgICBl
bHNlCisgICAgICAgIGRvbWN0bC5jbWQgPSBYRU5fRE9NQ1RMX3ZtY2VfbW9uaXRvcl9lbmQ7Cisg
ICAgZG9tY3RsLmRvbWFpbiA9IChkb21pZF90KWRvbWlkOworICAgIHJldCA9IGRvX2RvbWN0bCh4
Y2gsICZkb21jdGwpOworCisgICAgcmV0dXJuIHJldCA/IC0xIDogMDsKK30KKwogLyogZ2V0IGlu
Zm8gZnJvbSBodm0gZ3Vlc3QgZm9yIHNhdmUgKi8KIGludCB4Y19kb21haW5faHZtX2dldGNvbnRl
eHQoeGNfaW50ZXJmYWNlICp4Y2gsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQz
Ml90IGRvbWlkLApkaWZmIC1yIDMzMTNlZTlmNjE0MiB0b29scy9saWJ4Yy94Y19kb21haW5fc2F2
ZS5jCi0tLSBhL3Rvb2xzL2xpYnhjL3hjX2RvbWFpbl9zYXZlLmMJVGh1IE9jdCAyNSAwNTo0OTox
MSAyMDEyICswODAwCisrKyBiL3Rvb2xzL2xpYnhjL3hjX2RvbWFpbl9zYXZlLmMJVHVlIE9jdCAz
MCAwNjowNzowNSAyMDEyICswODAwCkBAIC0xMTA5LDYgKzExMDksMTMgQEAKICAgICAgICAgZ290
byBvdXQ7CiAgICAgfQogCisgICAgLyogU3RhcnQgdm1jZSBtb25pdG9yICovCisgICAgaWYgKCB4
Y19kb21haW5fdm1jZV9tb25pdG9yKHhjaCwgZG9tLCAxKSApCisgICAgeworICAgICAgICBQRVJS
T1IoIkVycm9yIHN0YXJ0aW5nIHZtY2UgbW9uaXRvciIpOworICAgICAgICBnb3RvIG91dDsKKyAg
ICB9CisKICAgY29weXBhZ2VzOgogI2RlZmluZSB3cmV4YWN0KGZkLCBidWYsIGxlbikgd3JpdGVf
YnVmZmVyKHhjaCwgbGFzdF9pdGVyLCBvYiwgKGZkKSwgKGJ1ZiksIChsZW4pKQogI2RlZmluZSB3
cnVuY2FjaGVkKGZkLCBsaXZlLCBidWYsIGxlbikgd3JpdGVfdW5jYWNoZWQoeGNoLCBsYXN0X2l0
ZXIsIG9iLCAoZmQpLCAoYnVmKSwgKGxlbikpCkBAIC0xNTgyLDYgKzE1ODksMTMgQEAKIAogICAg
IERQUklOVEYoIkFsbCBtZW1vcnkgaXMgc2F2ZWRcbiIpOwogCisgICAgLyogRW5kIHZtY2UgbW9u
aXRvciAqLworICAgIGlmICggeGNfZG9tYWluX3ZtY2VfbW9uaXRvcih4Y2gsIGRvbSwgMCkgKQor
ICAgIHsKKyAgICAgICAgUEVSUk9SKCJFcnJvciBlbmRpbmcgdm1jZSBtb25pdG9yIik7CisgICAg
ICAgIGdvdG8gb3V0OworICAgIH0KKwogICAgIC8qIEFmdGVyIGxhc3RfaXRlciwgYnVmZmVyIHRo
ZSByZXN0IG9mIHBhZ2VidWYgJiB0YWlsYnVmIGRhdGEgaW50byBhCiAgICAgICogc2VwYXJhdGUg
b3V0cHV0IGJ1ZmZlciBhbmQgZmx1c2ggaXQgYWZ0ZXIgdGhlIGNvbXByZXNzZWQgcGFnZSBjaHVu
a3MuCiAgICAgICovCmRpZmYgLXIgMzMxM2VlOWY2MTQyIHRvb2xzL2xpYnhjL3hlbmN0cmwuaAot
LS0gYS90b29scy9saWJ4Yy94ZW5jdHJsLmgJVGh1IE9jdCAyNSAwNTo0OToxMSAyMDEyICswODAw
CisrKyBiL3Rvb2xzL2xpYnhjL3hlbmN0cmwuaAlUdWUgT2N0IDMwIDA2OjA3OjA1IDIwMTIgKzA4
MDAKQEAgLTU4Niw2ICs1ODYsMTcgQEAKICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVuc2ln
bmVkIGxvbmcgcGZuKTsKIAogLyoqCisgKiBUaGlzIGZ1bmN0aW9uIHN0YXJ0L2VuZCBtb25pdG9y
IHZtY2UgZXZlbnQuCisgKiBAcGFybSB4Y2ggYSBoYW5kbGUgdG8gYW4gb3BlbiBoeXBlcnZpc29y
IGludGVyZmFjZQorICogQHBhcm0gZG9taWQgdGhlIGRvbWFpbiBpZCBtb25pdG9yZWQKKyAqIEBw
YXJtIGZsYWcgdG8gc3RhcnQvZW5kIG1vbml0b3IKKyAqIEByZXR1cm4gPDAgb24gZmFpbHVyZSwg
MCBvbiBzdWNjZXNzCisgKi8KK2ludCB4Y19kb21haW5fdm1jZV9tb25pdG9yKHhjX2ludGVyZmFj
ZSAqeGNoLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZG9taWQsCisgICAg
ICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJfdCBzdGFydCk7CisKKy8qKgogICogVGhpcyBm
dW5jdGlvbiByZXR1cm5zIGluZm9ybWF0aW9uIGFib3V0IHRoZSBjb250ZXh0IG9mIGEgaHZtIGRv
bWFpbgogICogQHBhcm0geGNoIGEgaGFuZGxlIHRvIGFuIG9wZW4gaHlwZXJ2aXNvciBpbnRlcmZh
Y2UKICAqIEBwYXJtIGRvbWlkIHRoZSBkb21haW4gdG8gZ2V0IGluZm9ybWF0aW9uIGZyb20KZGlm
ZiAtciAzMzEzZWU5ZjYxNDIgeGVuL2FyY2gveDg2L2NwdS9tY2hlY2svbWNlX2ludGVsLmMKLS0t
IGEveGVuL2FyY2gveDg2L2NwdS9tY2hlY2svbWNlX2ludGVsLmMJVGh1IE9jdCAyNSAwNTo0OTox
MSAyMDEyICswODAwCisrKyBiL3hlbi9hcmNoL3g4Ni9jcHUvbWNoZWNrL21jZV9pbnRlbC5jCVR1
ZSBPY3QgMzAgMDY6MDc6MDUgMjAxMiArMDgwMApAQCAtMzQyLDYgKzM0MiwyMiBAQAogICAgICAg
ICAgICAgICAgICAgICBnb3RvIHZtY2VfZmFpbGVkOwogICAgICAgICAgICAgICAgIH0KIAorICAg
ICAgICAgICAgICAgIGlmICggdW5saWtlbHkoZC0+YXJjaC52bWNlX21vbml0b3IpICkKKyAgICAg
ICAgICAgICAgICB7CisgICAgICAgICAgICAgICAgICAgIC8qCisgICAgICAgICAgICAgICAgICAg
ICAqIHZNQ0Ugb2NjdXIgZHVyaW5nIG1pZ3JhdGlvbgorICAgICAgICAgICAgICAgICAgICAgKgor
ICAgICAgICAgICAgICAgICAgICAgKiBtYXJrIGJyb2tlbiBwYWdlIHRvIGRpcnR5IGJpdG1hcCwg
c28gdGhhdCBhdCBjb3B5cGFnZXMKKyAgICAgICAgICAgICAgICAgICAgICogc3RhZ2Ugb2YgbWln
cmF0aW9uLCBpdHMgcGZuX3R5cGUgYW5kIHBmbiBudW1iZXIgd291bGQKKyAgICAgICAgICAgICAg
ICAgICAgICogdHJhbnNmZXIgdG8gdGFyZ2V0IGFuZCB0aGVuIHRha2UgYXBwcm9wcmlhdGUgYWN0
aW9uCisgICAgICAgICAgICAgICAgICAgICAqCisgICAgICAgICAgICAgICAgICAgICAqIEF0IHRh
cmdldCwgaXQgd291bGQgc2V0IHAybSBhcyBwMm1fcmFtX2Jyb2tlbiBmb3IgYnJva2VuCisgICAg
ICAgICAgICAgICAgICAgICAqIHBhZ2UsIHNvIHRoYXQgaWYgZ3Vlc3QgYWNjZXNzIHRoZSBicm9r
ZW4gcGFnZSBhZ2FpbiwgaXQKKyAgICAgICAgICAgICAgICAgICAgICogd291bGQga2lsbCBpdHNl
bGYgYXMgZXhwZWN0ZWQuCisgICAgICAgICAgICAgICAgICAgICAqLworICAgICAgICAgICAgICAg
ICAgICBwYWdpbmdfbWFya19kaXJ0eShkLCBtZm4pOworICAgICAgICAgICAgICAgIH0KKwogICAg
ICAgICAgICAgICAgIGlmICggdW5tbWFwX2Jyb2tlbl9wYWdlKGQsIF9tZm4obWZuKSwgZ2ZuKSAp
CiAgICAgICAgICAgICAgICAgewogICAgICAgICAgICAgICAgICAgICBwcmludGsoIlVubWFwIGJy
b2tlbiBtZW1vcnkgJWx4IGZvciBET00lZCBmYWlsZWRcbiIsCmRpZmYgLXIgMzMxM2VlOWY2MTQy
IHhlbi9hcmNoL3g4Ni9kb21jdGwuYwotLS0gYS94ZW4vYXJjaC94ODYvZG9tY3RsLmMJVGh1IE9j
dCAyNSAwNTo0OToxMSAyMDEyICswODAwCisrKyBiL3hlbi9hcmNoL3g4Ni9kb21jdGwuYwlUdWUg
T2N0IDMwIDA2OjA3OjA1IDIwMTIgKzA4MDAKQEAgLTE1OTksNiArMTU5OSw0NCBAQAogICAgIH0K
ICAgICBicmVhazsKIAorICAgIGNhc2UgWEVOX0RPTUNUTF92bWNlX21vbml0b3Jfc3RhcnQ6Cisg
ICAgeworICAgICAgICBzdHJ1Y3QgZG9tYWluICpkOworCisgICAgICAgIGQgPSByY3VfbG9ja19k
b21haW5fYnlfaWQoZG9tY3RsLT5kb21haW4pOworICAgICAgICBpZiAoIGQgIT0gTlVMTCApCisg
ICAgICAgIHsKKyAgICAgICAgICAgIGlmICggZC0+YXJjaC52bWNlX21vbml0b3IgKQorICAgICAg
ICAgICAgICAgIHJldCA9IC1FQlVTWTsKKyAgICAgICAgICAgIGVsc2UKKyAgICAgICAgICAgICAg
ICBkLT5hcmNoLnZtY2VfbW9uaXRvciA9IDE7CisKKyAgICAgICAgICAgIHJjdV91bmxvY2tfZG9t
YWluKGQpOworICAgICAgICB9CisgICAgICAgIGVsc2UKKyAgICAgICAgICAgIHJldCA9IC1FU1JD
SDsKKyAgICB9CisgICAgYnJlYWs7CisKKyAgICBjYXNlIFhFTl9ET01DVExfdm1jZV9tb25pdG9y
X2VuZDoKKyAgICB7CisgICAgICAgIHN0cnVjdCBkb21haW4gKmQ7CisKKyAgICAgICAgZCA9IHJj
dV9sb2NrX2RvbWFpbl9ieV9pZChkb21jdGwtPmRvbWFpbik7CisgICAgICAgIGlmICggZCAhPSBO
VUxMKQorICAgICAgICB7CisgICAgICAgICAgICBpZiAoICFkLT5hcmNoLnZtY2VfbW9uaXRvciAp
CisgICAgICAgICAgICAgICAgcmV0ID0gLUVJTlZBTDsKKyAgICAgICAgICAgIGVsc2UKKyAgICAg
ICAgICAgICAgICBkLT5hcmNoLnZtY2VfbW9uaXRvciA9IDA7CisKKyAgICAgICAgICAgIHJjdV91
bmxvY2tfZG9tYWluKGQpOworICAgICAgICB9CisgICAgICAgIGVsc2UKKyAgICAgICAgICAgIHJl
dCA9IC1FU1JDSDsKKyAgICB9CisgICAgYnJlYWs7CisKICAgICBkZWZhdWx0OgogICAgICAgICBy
ZXQgPSBpb21tdV9kb19kb21jdGwoZG9tY3RsLCB1X2RvbWN0bCk7CiAgICAgICAgIGJyZWFrOwpk
aWZmIC1yIDMzMTNlZTlmNjE0MiB4ZW4vaW5jbHVkZS9hc20teDg2L2RvbWFpbi5oCi0tLSBhL3hl
bi9pbmNsdWRlL2FzbS14ODYvZG9tYWluLmgJVGh1IE9jdCAyNSAwNTo0OToxMSAyMDEyICswODAw
CisrKyBiL3hlbi9pbmNsdWRlL2FzbS14ODYvZG9tYWluLmgJVHVlIE9jdCAzMCAwNjowNzowNSAy
MDEyICswODAwCkBAIC0yNzksNiArMjc5LDEwIEBACiAgICAgYm9vbF90IGhhc18zMmJpdF9zaGlu
Zm87CiAgICAgLyogRG9tYWluIGNhbm5vdCBoYW5kbGUgc3B1cmlvdXMgcGFnZSBmYXVsdHM/ICov
CiAgICAgYm9vbF90IHN1cHByZXNzX3NwdXJpb3VzX3BhZ2VfZmF1bHRzOworICAgIC8qIE1vbml0
b3JpbmcgZ3Vlc3QgbWVtb3J5IGNvcHkgb2YgbWlncmF0aW9uCisgICAgICogPSAwIC0gbm90IG1v
bml0b3JpbmcKKyAgICAgKiA9IDEgLSBtb25pdG9yaW5nICovCisgICAgYm9vbF90IHZtY2VfbW9u
aXRvcjsKIAogICAgIC8qIENvbnRpbnVhYmxlIGRvbWFpbl9yZWxpbnF1aXNoX3Jlc291cmNlcygp
LiAqLwogICAgIGVudW0gewpkaWZmIC1yIDMzMTNlZTlmNjE0MiB4ZW4vaW5jbHVkZS9wdWJsaWMv
ZG9tY3RsLmgKLS0tIGEveGVuL2luY2x1ZGUvcHVibGljL2RvbWN0bC5oCVRodSBPY3QgMjUgMDU6
NDk6MTEgMjAxMiArMDgwMAorKysgYi94ZW4vaW5jbHVkZS9wdWJsaWMvZG9tY3RsLmgJVHVlIE9j
dCAzMCAwNjowNzowNSAyMDEyICswODAwCkBAIC05MDgsNiArOTA4LDggQEAKICNkZWZpbmUgWEVO
X0RPTUNUTF9hdWRpdF9wMm0gICAgICAgICAgICAgICAgICAgICA2NQogI2RlZmluZSBYRU5fRE9N
Q1RMX3NldF92aXJxX2hhbmRsZXIgICAgICAgICAgICAgIDY2CiAjZGVmaW5lIFhFTl9ET01DVExf
c2V0X2Jyb2tlbl9wYWdlX3AybSAgICAgICAgICAgNjcKKyNkZWZpbmUgWEVOX0RPTUNUTF92bWNl
X21vbml0b3Jfc3RhcnQgICAgICAgICAgICA2OAorI2RlZmluZSBYRU5fRE9NQ1RMX3ZtY2VfbW9u
aXRvcl9lbmQgICAgICAgICAgICAgIDY5CiAjZGVmaW5lIFhFTl9ET01DVExfZ2Ric3hfZ3Vlc3Rt
ZW1pbyAgICAgICAgICAgIDEwMDAKICNkZWZpbmUgWEVOX0RPTUNUTF9nZGJzeF9wYXVzZXZjcHUg
ICAgICAgICAgICAgMTAwMQogI2RlZmluZSBYRU5fRE9NQ1RMX2dkYnN4X3VucGF1c2V2Y3B1ICAg
ICAgICAgICAxMDAyCg==

--_002_DE8DF0795D48FD4CA783C40EC8292335374296SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC8292335374296SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Mon Oct 29 15:35:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 15:35:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSrN0-0004nL-Ni; Mon, 29 Oct 2012 15:35:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSrMz-0004nG-BI
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 15:35:17 +0000
Received: from [85.158.139.83:30308] by server-1.bemta-5.messagelabs.com id
	EF/6F-21640-432AE805; Mon, 29 Oct 2012 15:35:16 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1351524910!27848636!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28681 invoked from network); 29 Oct 2012 15:35:12 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Oct 2012 15:35:12 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9TFYxfa023747
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 29 Oct 2012 15:35:00 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9TFYvtr003068
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 29 Oct 2012 15:34:58 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9TFYuOD031049; Mon, 29 Oct 2012 10:34:56 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 29 Oct 2012 08:34:55 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 506C740376; Mon, 29 Oct 2012 11:22:29 -0400 (EDT)
Date: Mon, 29 Oct 2012 11:22:29 -0400
From: Konrad Rzeszutek Wilk 
To: Alexandre Bezroutchko 
Message-ID: <20121029152229.GB14823@phenom.dumpdata.com>
References: 
	<20121017121115.GI8912@reaktio.net> <507EB52D.1040209@gremwell.com>
	<507EB7A1.1080907@gremwell.com>
	<20121017154109.GB7590@phenom.dumpdata.com>
	
	
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "nathanael@polymorpheus.com" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] pvusb with kernel 3.4 / 3.6
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Oct 20, 2012 at 09:21:25AM +0200, Alexandre Bezroutchko wrote:
> On Wed, Oct 17, 2012 at 6:08 PM, Alexandre Bezroutchko =
wrote:
> =

> > On 17 Oct 2012, at 17:41, Konrad Rzeszutek Wilk 
> > wrote:
> >
> > On Wed, Oct 17, 2012 at 03:50:25PM +0200, Alexandre Bezroutchko wrote:
> >
> > On 10/17/2012 03:39 PM, Alexandre Bezroutchko wrote:
> >
> > Thanks for the hint, found it, here it is:
> >
> >
> >
> > http://wiki.xen.org/wiki/Xen_Development_Projects#Upstreaming_Xen_PVUSB=
_drivers_to_mainline_Linux_kernel
> >
> >
> > On 10/17/2012 02:11 PM, Pasi K=E4rkk=E4inen wrote:
> >
> > On Wed, Oct 17, 2012 at 01:21:53PM +0200, Alexandre Bezroutchko wrote:
> >
> >   Hi Nathanael,
> >
> >
> >   Is it possible to use your patch [1] on newer kernels? I've tried to =
use
> >
> >   it but most devices are not usable and some cause kernel crash. Detai=
led
> >
> >   description of an attempt on kernel 3.4 is at [2] and (somewhat less
> >
> >   detailed) with 3.6 is at [3]. I'm motivated to make it work, any ideas
> >
> >   what can be done to fix this issue? Please tell me if you need any
> >
> >   additional info.
> >
> >
> >   I've added xen-devel and Pasi K=E4rkk=E4inen into Cc, hope this is ok.
> >
> >
> > I think Konrad has the pvusb drivers in his git tree..
> >
> > Konrad's repo seems to contain the same patch [1] as published by
> >
> > Nathanael. It does not work for me. I've put Konrad in Cc, hope he can
> >
> > comment...
> >
> >
> > So how does it not work?
> >
> >
> > Here is my original question, please tell me what additional info you n=
eed.
> >
> =

> Have I failed to provide enough information, or there is some gross mista=
ke
> in my setup?

Neither.
> =

> Could you please describe a setup for pvusb which linux 3.4 kernel and xen
> 4.1 having good chance to work?

I hadn't had a chance to look at it - and the only persons who would have
the expertise to do so are the authors of said patches. They seemed to
have moved on, so I think to answer your questions you would have to
wrap up your sleves and dig in the code yourself.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 15:35:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 15:35:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSrN0-0004nL-Ni; Mon, 29 Oct 2012 15:35:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSrMz-0004nG-BI
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 15:35:17 +0000
Received: from [85.158.139.83:30308] by server-1.bemta-5.messagelabs.com id
	EF/6F-21640-432AE805; Mon, 29 Oct 2012 15:35:16 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1351524910!27848636!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28681 invoked from network); 29 Oct 2012 15:35:12 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Oct 2012 15:35:12 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9TFYxfa023747
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 29 Oct 2012 15:35:00 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9TFYvtr003068
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 29 Oct 2012 15:34:58 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9TFYuOD031049; Mon, 29 Oct 2012 10:34:56 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 29 Oct 2012 08:34:55 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 506C740376; Mon, 29 Oct 2012 11:22:29 -0400 (EDT)
Date: Mon, 29 Oct 2012 11:22:29 -0400
From: Konrad Rzeszutek Wilk 
To: Alexandre Bezroutchko 
Message-ID: <20121029152229.GB14823@phenom.dumpdata.com>
References: 
	<20121017121115.GI8912@reaktio.net> <507EB52D.1040209@gremwell.com>
	<507EB7A1.1080907@gremwell.com>
	<20121017154109.GB7590@phenom.dumpdata.com>
	
	
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "nathanael@polymorpheus.com" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] pvusb with kernel 3.4 / 3.6
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Oct 20, 2012 at 09:21:25AM +0200, Alexandre Bezroutchko wrote:
> On Wed, Oct 17, 2012 at 6:08 PM, Alexandre Bezroutchko =
wrote:
> =

> > On 17 Oct 2012, at 17:41, Konrad Rzeszutek Wilk 
> > wrote:
> >
> > On Wed, Oct 17, 2012 at 03:50:25PM +0200, Alexandre Bezroutchko wrote:
> >
> > On 10/17/2012 03:39 PM, Alexandre Bezroutchko wrote:
> >
> > Thanks for the hint, found it, here it is:
> >
> >
> >
> > http://wiki.xen.org/wiki/Xen_Development_Projects#Upstreaming_Xen_PVUSB=
_drivers_to_mainline_Linux_kernel
> >
> >
> > On 10/17/2012 02:11 PM, Pasi K=E4rkk=E4inen wrote:
> >
> > On Wed, Oct 17, 2012 at 01:21:53PM +0200, Alexandre Bezroutchko wrote:
> >
> >   Hi Nathanael,
> >
> >
> >   Is it possible to use your patch [1] on newer kernels? I've tried to =
use
> >
> >   it but most devices are not usable and some cause kernel crash. Detai=
led
> >
> >   description of an attempt on kernel 3.4 is at [2] and (somewhat less
> >
> >   detailed) with 3.6 is at [3]. I'm motivated to make it work, any ideas
> >
> >   what can be done to fix this issue? Please tell me if you need any
> >
> >   additional info.
> >
> >
> >   I've added xen-devel and Pasi K=E4rkk=E4inen into Cc, hope this is ok.
> >
> >
> > I think Konrad has the pvusb drivers in his git tree..
> >
> > Konrad's repo seems to contain the same patch [1] as published by
> >
> > Nathanael. It does not work for me. I've put Konrad in Cc, hope he can
> >
> > comment...
> >
> >
> > So how does it not work?
> >
> >
> > Here is my original question, please tell me what additional info you n=
eed.
> >
> =

> Have I failed to provide enough information, or there is some gross mista=
ke
> in my setup?

Neither.
> =

> Could you please describe a setup for pvusb which linux 3.4 kernel and xen
> 4.1 having good chance to work?

I hadn't had a chance to look at it - and the only persons who would have
the expertise to do so are the authors of said patches. They seemed to
have moved on, so I think to answer your questions you would have to
wrap up your sleves and dig in the code yourself.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 15:56:06 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 15:56:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSrgn-0004zy-KX; Mon, 29 Oct 2012 15:55:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSrgm-0004zt-Dt
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 15:55:44 +0000
Received: from [85.158.143.99:48778] by server-3.bemta-4.messagelabs.com id
	6D/C8-24279-FF6AE805; Mon, 29 Oct 2012 15:55:43 +0000
X-Env-Sender: jfehlig@suse.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1351526140!18042616!1
X-Originating-IP: [137.65.250.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20333 invoked from network); 29 Oct 2012 15:55:42 -0000
Received: from victor.provo.novell.com (HELO victor.provo.novell.com)
	(137.65.250.26)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Oct 2012 15:55:42 -0000
Received: from [137.65.135.33] (prv-ext-foundry1int.gns.novell.com
	[137.65.251.240])
	by victor.provo.novell.com with ESMTP (TLS encrypted);
	Mon, 29 Oct 2012 09:55:29 -0600
Message-ID: <508EA6F0.2000504@suse.com>
Date: Mon, 29 Oct 2012 09:55:28 -0600
From: Jim Fehlig 
User-Agent: Thunderbird 2.0.0.24 (X11/20100302)
MIME-Version: 1.0
To: Ian Campbell 
References: 	<50882F59.6070203@suse.com>
	<508A8A25.3010505@eu.citrix.com>
	<1351257501.15162.85.camel@zakaz.uk.xensource.com>
In-Reply-To: <1351257501.15162.85.camel@zakaz.uk.xensource.com>
Cc: George Dunlap ,
	Dario Faggioli ,
	Ian Jackson , Chun Yan Liu ,
	"xen-devel@lists.xen.org" ,
	LibVir , Ondrej Holecek ,
	Bamvor Jian Zhang 
Subject: Re: [Xen-devel] libxl drivers for libvirt?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell wrote:
> On Fri, 2012-10-26 at 14:03 +0100, George Dunlap wrote:
>   
>> On 24/10/12 19:11, Jim Fehlig wrote:
>>     
>>>> * What kind of Xen support for libxl is in the libvirt development
>>>> branch, and do you have an idea when full support for 4.2 (at least,
>>>> including migration, suspend/resume, &c) might be available?
>>>>         
>>> Nothing has changed in git master over what is available in 0.10.2, but
>>> we are now starting to pick up this work.  Our priorities are to first
>>> get the libxl driver compiling against 4.2 and all of the existing
>>> functionality that works with 4.1 working with 4.2, followed by closing
>>> the feature gap with the legacy xen driver, and finally closing the
>>> feature gap with the qemu driver where it makes sense.  This is
>>> obviously quite a bit of work and any help would be appreciated :).
>>>
>>> BTW, we don't have any motivation to add features to the 4.1 version of
>>> the libvirt libxl driver.
>>>       
>> That sounds like a good plan.  For 4.1, xend is still the default 
>> toolstack, and libxl is a "tech preview"; for 4.2, xl is the default 
>> toolstack, and (if I understand correctly) we're officially going to be 
>> supporting the libxl interface in a backwards-compatible way from here 
>> forward.
>>
>> It seems to me that if you have trouble supporting both libxl 4.2 and 
>> libxl 4.1, that it might be better just to drop 4.1 support and focus on 
>> 4.2.  Ian Campbell / Jackson: Thoughts?
>>     

CC'ing libvirt community to get their input.

>
> That's what I would do if I were them ;-)
>   

I tend to agree that this might be the best approach.  The libxl in Xen
4.1 is essentially a one-off and I question whether we should pollute
the libvirt libxl driver code with support for a dead, tech preview
interface.  Xend is still the primary toolstack in Xen 4.1.x, and
libvirt has a stable, functional driver for this toolstack that can
(should) be used in Xen 4.1.x deployments.

Is anyone using the libvirt libxl driver with Xen 4.1 for anything other
than development or experimentation?

> Another option would be to fork into 4.1 and 4.2+ versions and to stop
> adding new stuff to the 4.1 copy. That has its own downsides though.
>   

I'd like to hear what the libvirt community thinks about only supporting
Xen >= 4.2 in the libxl driver.

Regards,
Jim

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 15:56:06 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 15:56:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSrgn-0004zy-KX; Mon, 29 Oct 2012 15:55:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSrgm-0004zt-Dt
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 15:55:44 +0000
Received: from [85.158.143.99:48778] by server-3.bemta-4.messagelabs.com id
	6D/C8-24279-FF6AE805; Mon, 29 Oct 2012 15:55:43 +0000
X-Env-Sender: jfehlig@suse.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1351526140!18042616!1
X-Originating-IP: [137.65.250.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20333 invoked from network); 29 Oct 2012 15:55:42 -0000
Received: from victor.provo.novell.com (HELO victor.provo.novell.com)
	(137.65.250.26)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Oct 2012 15:55:42 -0000
Received: from [137.65.135.33] (prv-ext-foundry1int.gns.novell.com
	[137.65.251.240])
	by victor.provo.novell.com with ESMTP (TLS encrypted);
	Mon, 29 Oct 2012 09:55:29 -0600
Message-ID: <508EA6F0.2000504@suse.com>
Date: Mon, 29 Oct 2012 09:55:28 -0600
From: Jim Fehlig 
User-Agent: Thunderbird 2.0.0.24 (X11/20100302)
MIME-Version: 1.0
To: Ian Campbell 
References: 	<50882F59.6070203@suse.com>
	<508A8A25.3010505@eu.citrix.com>
	<1351257501.15162.85.camel@zakaz.uk.xensource.com>
In-Reply-To: <1351257501.15162.85.camel@zakaz.uk.xensource.com>
Cc: George Dunlap ,
	Dario Faggioli ,
	Ian Jackson , Chun Yan Liu ,
	"xen-devel@lists.xen.org" ,
	LibVir , Ondrej Holecek ,
	Bamvor Jian Zhang 
Subject: Re: [Xen-devel] libxl drivers for libvirt?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell wrote:
> On Fri, 2012-10-26 at 14:03 +0100, George Dunlap wrote:
>   
>> On 24/10/12 19:11, Jim Fehlig wrote:
>>     
>>>> * What kind of Xen support for libxl is in the libvirt development
>>>> branch, and do you have an idea when full support for 4.2 (at least,
>>>> including migration, suspend/resume, &c) might be available?
>>>>         
>>> Nothing has changed in git master over what is available in 0.10.2, but
>>> we are now starting to pick up this work.  Our priorities are to first
>>> get the libxl driver compiling against 4.2 and all of the existing
>>> functionality that works with 4.1 working with 4.2, followed by closing
>>> the feature gap with the legacy xen driver, and finally closing the
>>> feature gap with the qemu driver where it makes sense.  This is
>>> obviously quite a bit of work and any help would be appreciated :).
>>>
>>> BTW, we don't have any motivation to add features to the 4.1 version of
>>> the libvirt libxl driver.
>>>       
>> That sounds like a good plan.  For 4.1, xend is still the default 
>> toolstack, and libxl is a "tech preview"; for 4.2, xl is the default 
>> toolstack, and (if I understand correctly) we're officially going to be 
>> supporting the libxl interface in a backwards-compatible way from here 
>> forward.
>>
>> It seems to me that if you have trouble supporting both libxl 4.2 and 
>> libxl 4.1, that it might be better just to drop 4.1 support and focus on 
>> 4.2.  Ian Campbell / Jackson: Thoughts?
>>     

CC'ing libvirt community to get their input.

>
> That's what I would do if I were them ;-)
>   

I tend to agree that this might be the best approach.  The libxl in Xen
4.1 is essentially a one-off and I question whether we should pollute
the libvirt libxl driver code with support for a dead, tech preview
interface.  Xend is still the primary toolstack in Xen 4.1.x, and
libvirt has a stable, functional driver for this toolstack that can
(should) be used in Xen 4.1.x deployments.

Is anyone using the libvirt libxl driver with Xen 4.1 for anything other
than development or experimentation?

> Another option would be to fork into 4.1 and 4.2+ versions and to stop
> adding new stuff to the 4.1 copy. That has its own downsides though.
>   

I'd like to hear what the libvirt community thinks about only supporting
Xen >= 4.2 in the libxl driver.

Regards,
Jim

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 15:56:34 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 15:56:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSrhK-00051g-1N; Mon, 29 Oct 2012 15:56:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSrhI-00051W-LM
	for xen-devel@lists.xensource.com; Mon, 29 Oct 2012 15:56:16 +0000
Received: from [85.158.143.99:8492] by server-3.bemta-4.messagelabs.com id
	29/99-24279-F17AE805; Mon, 29 Oct 2012 15:56:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1351526174!22535426!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzNTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1861 invoked from network); 29 Oct 2012 15:56:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Oct 2012 15:56:15 -0000
X-IronPort-AV: E=Sophos;i="4.80,672,1344211200"; d="scan'208";a="15468830"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Oct 2012 15:56:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Mon, 29 Oct 2012 15:56:13 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TSrhF-0007zg-CH	for xen-devel@lists.xensource.com;
	Mon, 29 Oct 2012 15:56:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TSrhF-00033B-91	for
	xen-devel@lists.xensource.com; Mon, 29 Oct 2012 15:56:13 +0000
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20622.42781.186248.63111@mariner.uk.xensource.com>
Date: Mon, 29 Oct 2012 15:56:13 +0000
To: "xen-devel@lists.xensource.com" 
In-Reply-To: 
References: 
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [xen-4.2-testing test] 14125: regressions -
 trouble: broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

xen.org writes ("[xen-4.2-testing test] 14125: regressions - trouble: broken/fail/pass"):
> flight 14125 xen-4.2-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/14125/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-pv            3 host-install(3)     broken REGR. vs. 14076

This was due to an infrastructure problem.  A database server was
accidentally power cycled on Friday.  We tried to recover things but
apparently not sufficiently.  And I only just noticed because my email
password had expired so I had to reset that first ...

I think things should be better now.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 15:56:34 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 15:56:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSrhK-00051g-1N; Mon, 29 Oct 2012 15:56:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSrhI-00051W-LM
	for xen-devel@lists.xensource.com; Mon, 29 Oct 2012 15:56:16 +0000
Received: from [85.158.143.99:8492] by server-3.bemta-4.messagelabs.com id
	29/99-24279-F17AE805; Mon, 29 Oct 2012 15:56:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1351526174!22535426!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzNTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1861 invoked from network); 29 Oct 2012 15:56:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Oct 2012 15:56:15 -0000
X-IronPort-AV: E=Sophos;i="4.80,672,1344211200"; d="scan'208";a="15468830"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Oct 2012 15:56:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Mon, 29 Oct 2012 15:56:13 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TSrhF-0007zg-CH	for xen-devel@lists.xensource.com;
	Mon, 29 Oct 2012 15:56:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TSrhF-00033B-91	for
	xen-devel@lists.xensource.com; Mon, 29 Oct 2012 15:56:13 +0000
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20622.42781.186248.63111@mariner.uk.xensource.com>
Date: Mon, 29 Oct 2012 15:56:13 +0000
To: "xen-devel@lists.xensource.com" 
In-Reply-To: 
References: 
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [xen-4.2-testing test] 14125: regressions -
 trouble: broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

xen.org writes ("[xen-4.2-testing test] 14125: regressions - trouble: broken/fail/pass"):
> flight 14125 xen-4.2-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/14125/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-pv            3 host-install(3)     broken REGR. vs. 14076

This was due to an infrastructure problem.  A database server was
accidentally power cycled on Friday.  We tried to recover things but
apparently not sufficiently.  And I only just noticed because my email
password had expired so I had to reset that first ...

I think things should be better now.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 16:06:21 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 16:06:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSrqk-0005jW-7y; Mon, 29 Oct 2012 16:06:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSrqi-0005jR-8y
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 16:06:00 +0000
Received: from [85.158.138.51:42920] by server-15.bemta-3.messagelabs.com id
	AF/4D-09445-369AE805; Mon, 29 Oct 2012 16:05:55 +0000
X-Env-Sender: berrange@redhat.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1351526753!18963307!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTgwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11286 invoked from network); 29 Oct 2012 16:05:54 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-7.tower-174.messagelabs.com with SMTP;
	29 Oct 2012 16:05:54 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q9TG5imo016863
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 29 Oct 2012 12:05:44 -0400
Received: from redhat.com (dhcp-1-196.lcy.redhat.com [10.32.224.196])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q9TG5ZIp012300
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Mon, 29 Oct 2012 12:05:37 -0400
Date: Mon, 29 Oct 2012 16:05:35 +0000
From: "Daniel P. Berrange" 
To: Jim Fehlig 
Message-ID: <20121029160534.GB5831@redhat.com>
References: 
	<50882F59.6070203@suse.com> <508A8A25.3010505@eu.citrix.com>
	<1351257501.15162.85.camel@zakaz.uk.xensource.com>
	<508EA6F0.2000504@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <508EA6F0.2000504@suse.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: Ian Campbell ,
	George Dunlap ,
	Dario Faggioli ,
	Ian Jackson ,
	"xen-devel@lists.xen.org" ,
	LibVir , Bamvor Jian Zhang 
Subject: Re: [Xen-devel] [libvirt]  libxl drivers for libvirt?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: "Daniel P. Berrange" 
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 29, 2012 at 09:55:28AM -0600, Jim Fehlig wrote:
> Ian Campbell wrote:
> > On Fri, 2012-10-26 at 14:03 +0100, George Dunlap wrote:
> >   
> >> On 24/10/12 19:11, Jim Fehlig wrote:
> >>     
> >>>> * What kind of Xen support for libxl is in the libvirt development
> >>>> branch, and do you have an idea when full support for 4.2 (at least,
> >>>> including migration, suspend/resume, &c) might be available?
> >>>>         
> >>> Nothing has changed in git master over what is available in 0.10.2, but
> >>> we are now starting to pick up this work.  Our priorities are to first
> >>> get the libxl driver compiling against 4.2 and all of the existing
> >>> functionality that works with 4.1 working with 4.2, followed by closing
> >>> the feature gap with the legacy xen driver, and finally closing the
> >>> feature gap with the qemu driver where it makes sense.  This is
> >>> obviously quite a bit of work and any help would be appreciated :).
> >>>
> >>> BTW, we don't have any motivation to add features to the 4.1 version of
> >>> the libvirt libxl driver.
> >>>       
> >> That sounds like a good plan.  For 4.1, xend is still the default 
> >> toolstack, and libxl is a "tech preview"; for 4.2, xl is the default 
> >> toolstack, and (if I understand correctly) we're officially going to be 
> >> supporting the libxl interface in a backwards-compatible way from here 
> >> forward.
> >>
> >> It seems to me that if you have trouble supporting both libxl 4.2 and 
> >> libxl 4.1, that it might be better just to drop 4.1 support and focus on 
> >> 4.2.  Ian Campbell / Jackson: Thoughts?
> >>     
> 
> CC'ing libvirt community to get their input.
> 
> >
> > That's what I would do if I were them ;-)
> >   
> 
> I tend to agree that this might be the best approach.  The libxl in Xen
> 4.1 is essentially a one-off and I question whether we should pollute
> the libvirt libxl driver code with support for a dead, tech preview
> interface.  Xend is still the primary toolstack in Xen 4.1.x, and
> libvirt has a stable, functional driver for this toolstack that can
> (should) be used in Xen 4.1.x deployments.
> 
> Is anyone using the libvirt libxl driver with Xen 4.1 for anything other
> than development or experimentation?
> 
> > Another option would be to fork into 4.1 and 4.2+ versions and to stop
> > adding new stuff to the 4.1 copy. That has its own downsides though.
> >   
> 
> I'd like to hear what the libvirt community thinks about only supporting
> Xen >= 4.2 in the libxl driver.

Given that libxl was "tech preview" in Xen 4.1, I'm fine with any
proposal to have libvirt libxl only work with Xen 4.2, if that's
what you feel is the most appropriate plan. You're the primary
maintainer if this libvirt driver, so I'll defer to your technical
knowledge here on the supportability issues here.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 16:06:21 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 16:06:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSrqk-0005jW-7y; Mon, 29 Oct 2012 16:06:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSrqi-0005jR-8y
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 16:06:00 +0000
Received: from [85.158.138.51:42920] by server-15.bemta-3.messagelabs.com id
	AF/4D-09445-369AE805; Mon, 29 Oct 2012 16:05:55 +0000
X-Env-Sender: berrange@redhat.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1351526753!18963307!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTgwMDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11286 invoked from network); 29 Oct 2012 16:05:54 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-7.tower-174.messagelabs.com with SMTP;
	29 Oct 2012 16:05:54 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q9TG5imo016863
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 29 Oct 2012 12:05:44 -0400
Received: from redhat.com (dhcp-1-196.lcy.redhat.com [10.32.224.196])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q9TG5ZIp012300
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Mon, 29 Oct 2012 12:05:37 -0400
Date: Mon, 29 Oct 2012 16:05:35 +0000
From: "Daniel P. Berrange" 
To: Jim Fehlig 
Message-ID: <20121029160534.GB5831@redhat.com>
References: 
	<50882F59.6070203@suse.com> <508A8A25.3010505@eu.citrix.com>
	<1351257501.15162.85.camel@zakaz.uk.xensource.com>
	<508EA6F0.2000504@suse.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <508EA6F0.2000504@suse.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: Ian Campbell ,
	George Dunlap ,
	Dario Faggioli ,
	Ian Jackson ,
	"xen-devel@lists.xen.org" ,
	LibVir , Bamvor Jian Zhang 
Subject: Re: [Xen-devel] [libvirt]  libxl drivers for libvirt?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: "Daniel P. Berrange" 
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 29, 2012 at 09:55:28AM -0600, Jim Fehlig wrote:
> Ian Campbell wrote:
> > On Fri, 2012-10-26 at 14:03 +0100, George Dunlap wrote:
> >   
> >> On 24/10/12 19:11, Jim Fehlig wrote:
> >>     
> >>>> * What kind of Xen support for libxl is in the libvirt development
> >>>> branch, and do you have an idea when full support for 4.2 (at least,
> >>>> including migration, suspend/resume, &c) might be available?
> >>>>         
> >>> Nothing has changed in git master over what is available in 0.10.2, but
> >>> we are now starting to pick up this work.  Our priorities are to first
> >>> get the libxl driver compiling against 4.2 and all of the existing
> >>> functionality that works with 4.1 working with 4.2, followed by closing
> >>> the feature gap with the legacy xen driver, and finally closing the
> >>> feature gap with the qemu driver where it makes sense.  This is
> >>> obviously quite a bit of work and any help would be appreciated :).
> >>>
> >>> BTW, we don't have any motivation to add features to the 4.1 version of
> >>> the libvirt libxl driver.
> >>>       
> >> That sounds like a good plan.  For 4.1, xend is still the default 
> >> toolstack, and libxl is a "tech preview"; for 4.2, xl is the default 
> >> toolstack, and (if I understand correctly) we're officially going to be 
> >> supporting the libxl interface in a backwards-compatible way from here 
> >> forward.
> >>
> >> It seems to me that if you have trouble supporting both libxl 4.2 and 
> >> libxl 4.1, that it might be better just to drop 4.1 support and focus on 
> >> 4.2.  Ian Campbell / Jackson: Thoughts?
> >>     
> 
> CC'ing libvirt community to get their input.
> 
> >
> > That's what I would do if I were them ;-)
> >   
> 
> I tend to agree that this might be the best approach.  The libxl in Xen
> 4.1 is essentially a one-off and I question whether we should pollute
> the libvirt libxl driver code with support for a dead, tech preview
> interface.  Xend is still the primary toolstack in Xen 4.1.x, and
> libvirt has a stable, functional driver for this toolstack that can
> (should) be used in Xen 4.1.x deployments.
> 
> Is anyone using the libvirt libxl driver with Xen 4.1 for anything other
> than development or experimentation?
> 
> > Another option would be to fork into 4.1 and 4.2+ versions and to stop
> > adding new stuff to the 4.1 copy. That has its own downsides though.
> >   
> 
> I'd like to hear what the libvirt community thinks about only supporting
> Xen >= 4.2 in the libxl driver.

Given that libxl was "tech preview" in Xen 4.1, I'm fine with any
proposal to have libvirt libxl only work with Xen 4.2, if that's
what you feel is the most appropriate plan. You're the primary
maintainer if this libvirt driver, so I'll defer to your technical
knowledge here on the supportability issues here.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 16:08:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 16:08:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSrsr-0005oQ-P1; Mon, 29 Oct 2012 16:08:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSrsp-0005oF-Nc
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 16:08:12 +0000
Received: from [85.158.138.51:14239] by server-5.bemta-3.messagelabs.com id
	85/41-12440-AE9AE805; Mon, 29 Oct 2012 16:08:10 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1351526886!27891515!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODI4MTEw\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21962 invoked from network); 29 Oct 2012 16:08:08 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Oct 2012 16:08:08 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9TG83e6008006
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 29 Oct 2012 16:08:04 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9TG82Ff020806
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 29 Oct 2012 16:08:03 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9TG82Q4024809; Mon, 29 Oct 2012 11:08:02 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 29 Oct 2012 09:08:02 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id EFCDE40376; Mon, 29 Oct 2012 11:55:35 -0400 (EDT)
Date: Mon, 29 Oct 2012 11:55:35 -0400
From: Konrad Rzeszutek Wilk 
To: Ian Campbell 
Message-ID: <20121029155535.GA25691@phenom.dumpdata.com>
References: <1350037688.14806.93.camel@zakaz.uk.xensource.com>
	<20121012115949.GB4028@localhost.localdomain>
	<20121012121049.GB4155@localhost.localdomain>
	<1350044296.14806.100.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="J/dobhs11T7y2rNN"
Content-Disposition: inline
In-Reply-To: <1350044296.14806.100.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel 
Subject: Re: [Xen-devel] Dom0 physical networking/swiotlb/something issue in
	3.7-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--J/dobhs11T7y2rNN
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Fri, Oct 12, 2012 at 01:18:16PM +0100, Ian Campbell wrote:
> On Fri, 2012-10-12 at 13:10 +0100, Konrad Rzeszutek Wilk wrote:
> > On Fri, Oct 12, 2012 at 07:59:49AM -0400, Konrad Rzeszutek Wilk wrote:
> > > On Fri, Oct 12, 2012 at 11:28:08AM +0100, Ian Campbell wrote:
> > > > Hi Konrad,
> > > > 
> > > > The following patch causes fairly large packet loss when transmitting
> > > > from dom0 to the physical network, at least with my tg3 hardware, but I
> > > > assume it can impact anything which uses this interface.
> > > 
> > > Ah, that would explain why one of my machines suddenly started
> > > developing checksum errors (and had a tg3 card). I hadn't gotten
> > > deep into it.
> > > > 
> > > > I suspect that the issue is that the compound pages allocated in this
> > > > way are not backed by contiguous mfns and so things fall apart when the
> > > > driver tries to do DMA.
> > > 
> > > So this should also be easily reproduced on barmetal with 'iommu=soft' then.
> > > > 
> > > > However I don't understand why the swiotlb is not fixing this up
> > > > successfully? The tg3 driver seems to use pci_map_single on this data.
> > > > Any thoughts? Perhaps the swiotlb (either generically or in the Xen
> > > > backend) doesn't correctly handle compound pages?
> > > 
> > > The assumption is that it is just a page. I am surprsed that the other
> > > IOMMUs aren't hitting this as well - ah, that is b/c they do handle
> > > a virtual address of more than one PAGE_SIZE..
> > 
> > So.. the GART one (AMD poor man IOTLB - was used for AGP card
> > translation, but can still be used as an IOMMU - and is still present on
> > some AMD machines), looks to suffer the same problem.
> > 
> > But perhaps not - can you explain to me if a compound page
> > is virtually contingous? One of the things the GART does for
> > pci_map_single is call page_to_phys(p), feeds the CPU physical address
> > (and size) into the GART engine to setup the mapping.
> > 
> > If compound pages are virtually (and physically on barmetal) contingous
> > - this ought to work. But if they are not, then this should also break on
> > AMD machines with tg3 and a AMD GART enabled.
> 
> AFAIK compound pages are always physically contiguous. i.e. given a
> "struct page *page" which is the head of a compound page you can do
> "page++" to walk through its constituent frames.
> 
> I'm not sure about virtually contiguous. Obviously if they are in lowmem
> then the 1-1 map combined with the fact that they are physically
> contiguous makes them virtually contiguous too. I'm not sure what
> happens if they are highmem -- since kmap (or whatever) would need to do
> some extra work in this case. I've not looked but I don't recall
> noticing this in the past...

So to double check this, I wrote this nice little module (attached)
that would allocate these type of pages and do 'DMA' on them.

>From the tests it seems to work OK - in some cases it uses a bounce
buffer and in some it does not. And the resulting buffers do contain
the data we expected.

# modprobe dma_test
modprobe dma_test
calling  dma_test_init+0x0/0x1000 [dma_test] @ 2875
initcall dma_test_init+0x0/0x1000 [dma_test] returned 0 after 309 usecs
fallback_bus: to_cpu: va: ffff8800642dd000 (pfn:642dd, mfn:53706) w.r.t prev mfn: 53707!
fallback_bus: to_cpu: va: ffff8800642de000 (pfn:642de, mfn:53705) w.r.t prev mfn: 53706!
fallback_bus: to_cpu: va: ffff8800642df000 (pfn:642df, mfn:53704) w.r.t prev mfn: 53705!
fallback_bus: to_cpu: ffff8800642dc000 (pfn:642dc, bus frame: 53707) <= ffff880070046000 (addr: 70046000, frame: 186)
fallback_bus: to_cpu: ffff8800642dd000 (pfn:642dd, bus frame: 53706) <= ffff880070047000 (addr: 70047000, frame: 187)
fallback_bus: to_cpu: ffff8800642de000 (pfn:642de, bus frame: 53705) <= ffff880070048000 (addr: 70048000, frame: 188)
fallback_bus: to_cpu: ffff8800642df000 (pfn:642df, bus frame: 53704) <= ffff880070049000 (addr: 70049000, frame: 189)
fallback_bus: to_dev: va: ffff880059521000 (pfn:59521, mfn:488c2) w.r.t prev mfn: 488c3!
fallback_bus: to_dev: va: ffff880059522000 (pfn:59522, mfn:488c1) w.r.t prev mfn: 488c2!
fallback_bus: to_dev: va: ffff880059523000 (pfn:59523, mfn:488c0) w.r.t prev mfn: 488c1!
fallback_bus: to_dev: va: ffff880059524000 (pfn:59524, mfn:488bf) w.r.t prev mfn: 488c0!
fallback_bus: to_dev: va: ffff880059525000 (pfn:59525, mfn:488be) w.r.t prev mfn: 488bf!
fallback_bus: to_dev: va: ffff880059526000 (pfn:59526, mfn:488bd) w.r.t prev mfn: 488be!
fallback_bus: to_dev: va: ffff880059527000 (pfn:59527, mfn:488bc) w.r.t prev mfn: 488bd!
fallback_bus: to_dev: 0xffff88007004a000(bounce)  <=  0xffff880059520000 (sz: 32768)
fallback_bus: to_dev: ffff880059520000 (pfn:59520, bus frame: 488c3) => ffff88007004a000 (addr: 7004a000, frame: 18a)
fallback_bus: to_dev: ffff880059521000 (pfn:59521, bus frame: 488c2) => ffff88007004b000 (addr: 7004b000, frame: 18b)
fallback_bus: to_dev: ffff880059522000 (pfn:59522, bus frame: 488c1) => ffff88007004c000 (addr: 7004c000, frame: 18c)
fallback_bus: to_dev: ffff880059523000 (pfn:59523, bus frame: 488c0) => ffff88007004d000 (addr: 7004d000, frame: 18d)
fallback_bus: to_dev: ffff880059524000 (pfn:59524, bus frame: 488bf) => ffff88007004e000 (addr: 7004e000, frame: 18e)
fallback_bus: to_dev: ffff880059525000 (pfn:59525, bus frame: 488be) => ffff88007004f000 (addr: 7004f000, frame: 18f)
fallback_bus: to_dev: ffff880059526000 (pfn:59526, bus frame: 488bd) => ffff880070050000 (addr: 70050000, frame: 190)
fallback_bus: to_dev: ffff880059527000 (pfn:59527, bus frame: 488bc) => ffff880070051000 (addr: 70051000, frame: 191)


fallback_bus: to_dev: ffff880059520000 with DMA (18a000) has ffffffcc (expected ffffffcc)
fallback_bus: to_dev: ffff880059521000 with DMA (18b000) has ffffffcc (expected ffffffcc)
fallback_bus: to_dev: ffff880059522000 with DMA (18c000) has ffffffcc (expected ffffffcc)
fallback_bus: to_dev: ffff880059523000 with DMA (18d000) has ffffffcc (expected ffffffcc)
fallback_bus: to_dev: ffff880059524000 with DMA (18e000) has ffffffcc (expected ffffffcc)
fallback_bus: to_dev: ffff880059525000 with DMA (18f000) has ffffffcc (expected ffffffcc)
fallback_bus: to_dev: ffff880059526000 with DMA (190000) has ffffffcc (expected ffffffcc)
fallback_bus: to_dev: ffff880059527000 with DMA (191000) has ffffffcc (expected ffffffcc)
fallback_bus: to_cpu: 0xffff880070046000(bounce)  =>  0xffff8800642dc000 (sz: 16384)
fallback_bus: to_cpu: ffff8800642dc000 with DMA (186000) has ffffffdd (expected ffffffdd)
fallback_bus: to_cpu: ffff8800642dd000 with DMA (187000) has ffffffdd (expected ffffffdd)
fallback_bus: to_cpu: ffff8800642de000 with DMA (188000) has ffffffdd (expected ffffffdd)
fallback_bus: to_cpu: ffff8800642df000 with DMA (189000) has ffffffdd (expected ffffffdd)
fallback_bus: to_cpu: 0xffff880070046000(bounce)  =>  0xffff8800642dc000 (sz: 16384)

> 
> Ian.

--J/dobhs11T7y2rNN
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="dma_test.c"

#include 
#include 
#include 
#include 
#include 
#include 
#include 

#define DMA_TEST  "0.1"

MODULE_AUTHOR("Konrad Rzeszutek Wilk ");
MODULE_DESCRIPTION("dma_test");
MODULE_LICENSE("GPL");
MODULE_VERSION(DMA_TEST);

static struct bus_type fallback_bus_type = {
	.name = "fallback_bus:",
};

static void fake_release(struct device *dev)
{
	/* No kfree as the device was allocated on stack. */
}

struct args {
	int len;
	enum dma_data_direction dir;
};

#define MAGIC_DEVICE 0xffffffdd
#define MAGIC_CPU 0xffffffcc

static int dma_test_thread(void *arg)
{
	struct page *page;
	dma_addr_t dma_addr = 0;
	struct device fake = {
		.coherent_dma_mask = DMA_BIT_MASK(32),
		.bus = &fallback_bus_type,
		.release = fake_release,
	};
	gfp_t gfp = __GFP_COMP | __GFP_NOWARN | GFP_ATOMIC;
	int ret;
	int i;
	void *addr;
	struct page *p;

	struct args *args = (struct args *)arg;
	int dir = args->dir;
	int len = args->len;

	dev_set_name(&fake, "%s", dir == DMA_TO_DEVICE ? "to_dev" : "to_cpu");
 	fake.dma_mask = &fake.coherent_dma_mask;
 	ret = device_register(&fake);
	if (ret)
		goto out;

	do {
		unsigned long prev_mfn = 0;
		bool bus_and_dma_same;

		page = alloc_pages(gfp, get_order(len));
		p = page;
		/* Check that the bus addresses are contingous. */
		for (i = 0; i < len / PAGE_SIZE; i++, p++) {
			unsigned long pfn, mfn;

			addr = page_address(p);
			pfn = PFN_DOWN(virt_to_phys(addr));
			if (xen_domain())
				mfn = pfn_to_mfn(pfn);
			else
				mfn = pfn;
			if (i != 0) {
				if (prev_mfn + 1 != mfn)
					dev_warn(&fake, "va: %lx (pfn:%lx, mfn:%lx) w.r.t prev mfn: %lx!\n",
						 (unsigned long)addr, pfn, mfn, prev_mfn);
			}
			prev_mfn = mfn;
		}
		dma_addr = dma_map_page(&fake, page, 0 /* no offset */, len, dir);
		/* Note, dma_addr is the physical address ! */
		if (dma_mapping_error(&fake, dma_addr)) {
			dev_warn(&fake, "DMA %lx for %lx is not right\n", (unsigned long)dma_addr,
				(unsigned long)page_address(page));
			__free_pages(page, get_order(len));
			page = NULL;
		}
		bus_and_dma_same = false;
		if (page) {
			unsigned long phys;
			unsigned long pfn, mfn, bus_addr_mfn;
			unsigned long bus_addr = 0;

			p = page;
			for (i = 0; i < len / PAGE_SIZE; i++, p++) {
				void *bus_va;

				addr = page_address(p);
				phys = virt_to_phys(addr);
				pfn = PFN_DOWN(phys);

				bus_va = (void *)(dma_addr + (i * PAGE_SIZE));

				if (xen_domain()) {
					void * tmp;

					/* Find the bus frame for the physical frame*/
					mfn = pfn_to_mfn(pfn);
					/* and .. voodoo time! */
					bus_addr_mfn = PFN_DOWN(dma_addr + (i * PAGE_SIZE));
					bus_addr = PFN_PHYS(mfn_to_pfn(bus_addr_mfn));
					tmp = __va(bus_addr);
					bus_va = mfn_to_virt(bus_addr_mfn);
					WARN(bus_va != tmp, "Expected %lx (%lx+%d*PAGE_SIZE), got: %lx (pfn: %lx, mfn: %lx)!\n",
						(unsigned long)bus_va, (unsigned long)dma_addr, i, (unsigned long)tmp, PFN_DOWN(bus_addr), bus_addr_mfn);
				} else {
					mfn = pfn;
					/* Assume DMA addr == physical addr */
					bus_addr_mfn = PFN_DOWN(bus_addr);
					bus_va = __va(PFN_PHYS(bus_addr_mfn));
				}

				dev_info(&fake, "%lx (pfn:%lx, bus frame: %lx) %s %lx (addr: %lx, frame: %lx)\n",
					(unsigned long)addr, pfn, mfn,
					dir == DMA_TO_DEVICE ? "=>" : "<=",
					(unsigned long)bus_va, bus_addr, bus_addr_mfn);

				if (!virt_addr_valid(bus_va))
					break;
				if (!virt_addr_valid(addr))
					break;

				/* CPU */
				memset(addr, 0xCC, PAGE_SIZE);

				/* Device */
				memset(bus_va, 0xDD, PAGE_SIZE);
				if (addr == bus_va)
					bus_and_dma_same = true;
			}
		}
		set_current_state(TASK_INTERRUPTIBLE);
		schedule_timeout_interruptible(5*HZ);

		if (!page)
			continue;
		p = page;

		for (i = 0; i < len / PAGE_SIZE; i++, p++) {
			if (bus_and_dma_same)
				continue;
			addr = page_address(p);
			if (((char *)addr)[0] != MAGIC_CPU)
				dev_warn(&fake, "%lx with DMA (%lx) has %x (expected %lx)\n",
					(unsigned long)addr, (unsigned long)(dma_addr + (i * PAGE_SIZE)),
					((char *)addr)[0], (unsigned long)MAGIC_CPU);
		}
		/* sync the page */
		dma_sync_single_for_cpu(&fake, dma_addr, len, dir);
		p = page;
		for (i = 0; i < len / PAGE_SIZE; i++, p++) {
			unsigned long check_val = MAGIC_DEVICE;

			addr = page_address(p);
			if (dir == DMA_TO_DEVICE)
				check_val = MAGIC_CPU;
			if (dir == DMA_FROM_DEVICE)
				check_val = MAGIC_DEVICE;

			dev_info(&fake, "%lx with DMA (%lx) has %x (expected %lx)\n",
				(unsigned long)addr, (unsigned long)(dma_addr + (i * PAGE_SIZE)),
				((char *)addr)[0], check_val);
		}
		dma_unmap_page(&fake, dma_addr, len, dir);
		dma_addr = 0;
		__free_pages(page, get_order(len));
		page = NULL;
	} while (!kthread_should_stop());

	if (dma_addr)
		dma_unmap_page(&fake, dma_addr, len, dir);
	if (page)
		__free_pages(page, get_order(len));
   	put_device(&fake);
 	device_unregister(&fake);
out:
	return 0;
}
static struct task_struct *t[2];
static struct args a[2];

static int __init dma_test_init(void)
{
	int ret;

	/* No point doing this without SWIOTLB */
	if (!swiotlb_nr_tbl())
		return -ENODEV;

	ret = bus_register(&fallback_bus_type);
	if (ret)
		return ret;

	a[0].dir = DMA_TO_DEVICE;
	a[0].len = 32768;
	t[0] = kthread_run(dma_test_thread, &a[0], "dma_test_dev");

	a[1].len = 16384;
	a[1].dir = DMA_FROM_DEVICE;
	t[1] = kthread_run(dma_test_thread, &a[1], "dma_test_cpu");
	return 0;
}
static void __exit dma_test_exit(void)
{
	if (t[0])
		kthread_stop(t[0]);
	if (t[1])
		kthread_stop(t[1]);

 	bus_unregister(&fallback_bus_type);
}
module_init(dma_test_init);
module_exit(dma_test_exit);

--J/dobhs11T7y2rNN
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="0001-swiotlb-Add-debugging.patch"

>From db63c863456f0914ad96db38544c364eaad787ab Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk 
Date: Mon, 29 Oct 2012 09:35:55 -0400
Subject: [PATCH] swiotlb: Add debugging.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 include/linux/swiotlb.h |    2 +-
 lib/swiotlb.c           |   25 ++++++++++++++++++++-----
 2 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 8d08b3e..0a17d79 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -46,7 +46,7 @@ extern void swiotlb_tbl_sync_single(struct device *hwdev, char *dma_addr,
 				    enum dma_sync_target target);
 
 /* Accessory functions. */
-extern void swiotlb_bounce(phys_addr_t phys, char *dma_addr, size_t size,
+extern void swiotlb_bounce(struct device *dev, phys_addr_t phys, char *dma_addr, size_t size,
 			   enum dma_data_direction dir);
 
 extern void
diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index f114bf6..e5d37a3 100644
--- a/lib/swiotlb.c
+++ b/lib/swiotlb.c
@@ -346,7 +346,7 @@ static int is_swiotlb_buffer(phys_addr_t paddr)
 /*
  * Bounce: copy the swiotlb buffer back to the original dma location
  */
-void swiotlb_bounce(phys_addr_t phys, char *dma_addr, size_t size,
+void swiotlb_bounce(struct device *dev, phys_addr_t phys, char *dma_addr, size_t size,
 		    enum dma_data_direction dir)
 {
 	unsigned long pfn = PFN_DOWN(phys);
@@ -376,6 +376,21 @@ void swiotlb_bounce(phys_addr_t phys, char *dma_addr, size_t size,
 			offset = 0;
 		}
 	} else {
+		if (size >= PAGE_SIZE) {
+			const char *type;
+
+			if (dir == DMA_TO_DEVICE)
+				type = " <= ";
+			else if (dir == DMA_FROM_DEVICE)
+				type = " => ";
+			else
+				type = " <=> ";
+			dev_info(dev, "0x%lx%s %s 0x%lx%s (sz: %ld)\n", (unsigned long)dma_addr,
+				is_swiotlb_buffer(virt_to_phys(dma_addr)) ? "(bounce)" : "",
+				type, (unsigned long)phys_to_virt(phys),
+				is_swiotlb_buffer(phys) ? "(bounce)" : "",
+				size);
+		}
 		if (dir == DMA_TO_DEVICE)
 			memcpy(dma_addr, phys_to_virt(phys), size);
 		else
@@ -483,7 +498,7 @@ found:
 	for (i = 0; i < nslots; i++)
 		io_tlb_orig_addr[index+i] = phys + (i << IO_TLB_SHIFT);
 	if (dir == DMA_TO_DEVICE || dir == DMA_BIDIRECTIONAL)
-		swiotlb_bounce(phys, dma_addr, size, DMA_TO_DEVICE);
+		swiotlb_bounce(hwdev, phys, dma_addr, size, DMA_TO_DEVICE);
 
 	return dma_addr;
 }
@@ -518,7 +533,7 @@ swiotlb_tbl_unmap_single(struct device *hwdev, char *dma_addr, size_t size,
 	 * First, sync the memory before unmapping the entry
 	 */
 	if (phys && ((dir == DMA_FROM_DEVICE) || (dir == DMA_BIDIRECTIONAL)))
-		swiotlb_bounce(phys, dma_addr, size, DMA_FROM_DEVICE);
+		swiotlb_bounce(hwdev, phys, dma_addr, size, DMA_FROM_DEVICE);
 
 	/*
 	 * Return the buffer to the free list by setting the corresponding
@@ -560,13 +575,13 @@ swiotlb_tbl_sync_single(struct device *hwdev, char *dma_addr, size_t size,
 	switch (target) {
 	case SYNC_FOR_CPU:
 		if (likely(dir == DMA_FROM_DEVICE || dir == DMA_BIDIRECTIONAL))
-			swiotlb_bounce(phys, dma_addr, size, DMA_FROM_DEVICE);
+			swiotlb_bounce(hwdev, phys, dma_addr, size, DMA_FROM_DEVICE);
 		else
 			BUG_ON(dir != DMA_TO_DEVICE);
 		break;
 	case SYNC_FOR_DEVICE:
 		if (likely(dir == DMA_TO_DEVICE || dir == DMA_BIDIRECTIONAL))
-			swiotlb_bounce(phys, dma_addr, size, DMA_TO_DEVICE);
+			swiotlb_bounce(hwdev, phys, dma_addr, size, DMA_TO_DEVICE);
 		else
 			BUG_ON(dir != DMA_FROM_DEVICE);
 		break;
-- 
1.7.7.6


--J/dobhs11T7y2rNN
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--J/dobhs11T7y2rNN--


From xen-devel-bounces@lists.xen.org Mon Oct 29 16:08:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 16:08:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSrsr-0005oQ-P1; Mon, 29 Oct 2012 16:08:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSrsp-0005oF-Nc
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 16:08:12 +0000
Received: from [85.158.138.51:14239] by server-5.bemta-3.messagelabs.com id
	85/41-12440-AE9AE805; Mon, 29 Oct 2012 16:08:10 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1351526886!27891515!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODI4MTEw\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21962 invoked from network); 29 Oct 2012 16:08:08 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Oct 2012 16:08:08 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9TG83e6008006
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 29 Oct 2012 16:08:04 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9TG82Ff020806
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 29 Oct 2012 16:08:03 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9TG82Q4024809; Mon, 29 Oct 2012 11:08:02 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 29 Oct 2012 09:08:02 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id EFCDE40376; Mon, 29 Oct 2012 11:55:35 -0400 (EDT)
Date: Mon, 29 Oct 2012 11:55:35 -0400
From: Konrad Rzeszutek Wilk 
To: Ian Campbell 
Message-ID: <20121029155535.GA25691@phenom.dumpdata.com>
References: <1350037688.14806.93.camel@zakaz.uk.xensource.com>
	<20121012115949.GB4028@localhost.localdomain>
	<20121012121049.GB4155@localhost.localdomain>
	<1350044296.14806.100.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="J/dobhs11T7y2rNN"
Content-Disposition: inline
In-Reply-To: <1350044296.14806.100.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel 
Subject: Re: [Xen-devel] Dom0 physical networking/swiotlb/something issue in
	3.7-rc1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--J/dobhs11T7y2rNN
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Fri, Oct 12, 2012 at 01:18:16PM +0100, Ian Campbell wrote:
> On Fri, 2012-10-12 at 13:10 +0100, Konrad Rzeszutek Wilk wrote:
> > On Fri, Oct 12, 2012 at 07:59:49AM -0400, Konrad Rzeszutek Wilk wrote:
> > > On Fri, Oct 12, 2012 at 11:28:08AM +0100, Ian Campbell wrote:
> > > > Hi Konrad,
> > > > 
> > > > The following patch causes fairly large packet loss when transmitting
> > > > from dom0 to the physical network, at least with my tg3 hardware, but I
> > > > assume it can impact anything which uses this interface.
> > > 
> > > Ah, that would explain why one of my machines suddenly started
> > > developing checksum errors (and had a tg3 card). I hadn't gotten
> > > deep into it.
> > > > 
> > > > I suspect that the issue is that the compound pages allocated in this
> > > > way are not backed by contiguous mfns and so things fall apart when the
> > > > driver tries to do DMA.
> > > 
> > > So this should also be easily reproduced on barmetal with 'iommu=soft' then.
> > > > 
> > > > However I don't understand why the swiotlb is not fixing this up
> > > > successfully? The tg3 driver seems to use pci_map_single on this data.
> > > > Any thoughts? Perhaps the swiotlb (either generically or in the Xen
> > > > backend) doesn't correctly handle compound pages?
> > > 
> > > The assumption is that it is just a page. I am surprsed that the other
> > > IOMMUs aren't hitting this as well - ah, that is b/c they do handle
> > > a virtual address of more than one PAGE_SIZE..
> > 
> > So.. the GART one (AMD poor man IOTLB - was used for AGP card
> > translation, but can still be used as an IOMMU - and is still present on
> > some AMD machines), looks to suffer the same problem.
> > 
> > But perhaps not - can you explain to me if a compound page
> > is virtually contingous? One of the things the GART does for
> > pci_map_single is call page_to_phys(p), feeds the CPU physical address
> > (and size) into the GART engine to setup the mapping.
> > 
> > If compound pages are virtually (and physically on barmetal) contingous
> > - this ought to work. But if they are not, then this should also break on
> > AMD machines with tg3 and a AMD GART enabled.
> 
> AFAIK compound pages are always physically contiguous. i.e. given a
> "struct page *page" which is the head of a compound page you can do
> "page++" to walk through its constituent frames.
> 
> I'm not sure about virtually contiguous. Obviously if they are in lowmem
> then the 1-1 map combined with the fact that they are physically
> contiguous makes them virtually contiguous too. I'm not sure what
> happens if they are highmem -- since kmap (or whatever) would need to do
> some extra work in this case. I've not looked but I don't recall
> noticing this in the past...

So to double check this, I wrote this nice little module (attached)
that would allocate these type of pages and do 'DMA' on them.

>From the tests it seems to work OK - in some cases it uses a bounce
buffer and in some it does not. And the resulting buffers do contain
the data we expected.

# modprobe dma_test
modprobe dma_test
calling  dma_test_init+0x0/0x1000 [dma_test] @ 2875
initcall dma_test_init+0x0/0x1000 [dma_test] returned 0 after 309 usecs
fallback_bus: to_cpu: va: ffff8800642dd000 (pfn:642dd, mfn:53706) w.r.t prev mfn: 53707!
fallback_bus: to_cpu: va: ffff8800642de000 (pfn:642de, mfn:53705) w.r.t prev mfn: 53706!
fallback_bus: to_cpu: va: ffff8800642df000 (pfn:642df, mfn:53704) w.r.t prev mfn: 53705!
fallback_bus: to_cpu: ffff8800642dc000 (pfn:642dc, bus frame: 53707) <= ffff880070046000 (addr: 70046000, frame: 186)
fallback_bus: to_cpu: ffff8800642dd000 (pfn:642dd, bus frame: 53706) <= ffff880070047000 (addr: 70047000, frame: 187)
fallback_bus: to_cpu: ffff8800642de000 (pfn:642de, bus frame: 53705) <= ffff880070048000 (addr: 70048000, frame: 188)
fallback_bus: to_cpu: ffff8800642df000 (pfn:642df, bus frame: 53704) <= ffff880070049000 (addr: 70049000, frame: 189)
fallback_bus: to_dev: va: ffff880059521000 (pfn:59521, mfn:488c2) w.r.t prev mfn: 488c3!
fallback_bus: to_dev: va: ffff880059522000 (pfn:59522, mfn:488c1) w.r.t prev mfn: 488c2!
fallback_bus: to_dev: va: ffff880059523000 (pfn:59523, mfn:488c0) w.r.t prev mfn: 488c1!
fallback_bus: to_dev: va: ffff880059524000 (pfn:59524, mfn:488bf) w.r.t prev mfn: 488c0!
fallback_bus: to_dev: va: ffff880059525000 (pfn:59525, mfn:488be) w.r.t prev mfn: 488bf!
fallback_bus: to_dev: va: ffff880059526000 (pfn:59526, mfn:488bd) w.r.t prev mfn: 488be!
fallback_bus: to_dev: va: ffff880059527000 (pfn:59527, mfn:488bc) w.r.t prev mfn: 488bd!
fallback_bus: to_dev: 0xffff88007004a000(bounce)  <=  0xffff880059520000 (sz: 32768)
fallback_bus: to_dev: ffff880059520000 (pfn:59520, bus frame: 488c3) => ffff88007004a000 (addr: 7004a000, frame: 18a)
fallback_bus: to_dev: ffff880059521000 (pfn:59521, bus frame: 488c2) => ffff88007004b000 (addr: 7004b000, frame: 18b)
fallback_bus: to_dev: ffff880059522000 (pfn:59522, bus frame: 488c1) => ffff88007004c000 (addr: 7004c000, frame: 18c)
fallback_bus: to_dev: ffff880059523000 (pfn:59523, bus frame: 488c0) => ffff88007004d000 (addr: 7004d000, frame: 18d)
fallback_bus: to_dev: ffff880059524000 (pfn:59524, bus frame: 488bf) => ffff88007004e000 (addr: 7004e000, frame: 18e)
fallback_bus: to_dev: ffff880059525000 (pfn:59525, bus frame: 488be) => ffff88007004f000 (addr: 7004f000, frame: 18f)
fallback_bus: to_dev: ffff880059526000 (pfn:59526, bus frame: 488bd) => ffff880070050000 (addr: 70050000, frame: 190)
fallback_bus: to_dev: ffff880059527000 (pfn:59527, bus frame: 488bc) => ffff880070051000 (addr: 70051000, frame: 191)


fallback_bus: to_dev: ffff880059520000 with DMA (18a000) has ffffffcc (expected ffffffcc)
fallback_bus: to_dev: ffff880059521000 with DMA (18b000) has ffffffcc (expected ffffffcc)
fallback_bus: to_dev: ffff880059522000 with DMA (18c000) has ffffffcc (expected ffffffcc)
fallback_bus: to_dev: ffff880059523000 with DMA (18d000) has ffffffcc (expected ffffffcc)
fallback_bus: to_dev: ffff880059524000 with DMA (18e000) has ffffffcc (expected ffffffcc)
fallback_bus: to_dev: ffff880059525000 with DMA (18f000) has ffffffcc (expected ffffffcc)
fallback_bus: to_dev: ffff880059526000 with DMA (190000) has ffffffcc (expected ffffffcc)
fallback_bus: to_dev: ffff880059527000 with DMA (191000) has ffffffcc (expected ffffffcc)
fallback_bus: to_cpu: 0xffff880070046000(bounce)  =>  0xffff8800642dc000 (sz: 16384)
fallback_bus: to_cpu: ffff8800642dc000 with DMA (186000) has ffffffdd (expected ffffffdd)
fallback_bus: to_cpu: ffff8800642dd000 with DMA (187000) has ffffffdd (expected ffffffdd)
fallback_bus: to_cpu: ffff8800642de000 with DMA (188000) has ffffffdd (expected ffffffdd)
fallback_bus: to_cpu: ffff8800642df000 with DMA (189000) has ffffffdd (expected ffffffdd)
fallback_bus: to_cpu: 0xffff880070046000(bounce)  =>  0xffff8800642dc000 (sz: 16384)

> 
> Ian.

--J/dobhs11T7y2rNN
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="dma_test.c"

#include 
#include 
#include 
#include 
#include 
#include 
#include 

#define DMA_TEST  "0.1"

MODULE_AUTHOR("Konrad Rzeszutek Wilk ");
MODULE_DESCRIPTION("dma_test");
MODULE_LICENSE("GPL");
MODULE_VERSION(DMA_TEST);

static struct bus_type fallback_bus_type = {
	.name = "fallback_bus:",
};

static void fake_release(struct device *dev)
{
	/* No kfree as the device was allocated on stack. */
}

struct args {
	int len;
	enum dma_data_direction dir;
};

#define MAGIC_DEVICE 0xffffffdd
#define MAGIC_CPU 0xffffffcc

static int dma_test_thread(void *arg)
{
	struct page *page;
	dma_addr_t dma_addr = 0;
	struct device fake = {
		.coherent_dma_mask = DMA_BIT_MASK(32),
		.bus = &fallback_bus_type,
		.release = fake_release,
	};
	gfp_t gfp = __GFP_COMP | __GFP_NOWARN | GFP_ATOMIC;
	int ret;
	int i;
	void *addr;
	struct page *p;

	struct args *args = (struct args *)arg;
	int dir = args->dir;
	int len = args->len;

	dev_set_name(&fake, "%s", dir == DMA_TO_DEVICE ? "to_dev" : "to_cpu");
 	fake.dma_mask = &fake.coherent_dma_mask;
 	ret = device_register(&fake);
	if (ret)
		goto out;

	do {
		unsigned long prev_mfn = 0;
		bool bus_and_dma_same;

		page = alloc_pages(gfp, get_order(len));
		p = page;
		/* Check that the bus addresses are contingous. */
		for (i = 0; i < len / PAGE_SIZE; i++, p++) {
			unsigned long pfn, mfn;

			addr = page_address(p);
			pfn = PFN_DOWN(virt_to_phys(addr));
			if (xen_domain())
				mfn = pfn_to_mfn(pfn);
			else
				mfn = pfn;
			if (i != 0) {
				if (prev_mfn + 1 != mfn)
					dev_warn(&fake, "va: %lx (pfn:%lx, mfn:%lx) w.r.t prev mfn: %lx!\n",
						 (unsigned long)addr, pfn, mfn, prev_mfn);
			}
			prev_mfn = mfn;
		}
		dma_addr = dma_map_page(&fake, page, 0 /* no offset */, len, dir);
		/* Note, dma_addr is the physical address ! */
		if (dma_mapping_error(&fake, dma_addr)) {
			dev_warn(&fake, "DMA %lx for %lx is not right\n", (unsigned long)dma_addr,
				(unsigned long)page_address(page));
			__free_pages(page, get_order(len));
			page = NULL;
		}
		bus_and_dma_same = false;
		if (page) {
			unsigned long phys;
			unsigned long pfn, mfn, bus_addr_mfn;
			unsigned long bus_addr = 0;

			p = page;
			for (i = 0; i < len / PAGE_SIZE; i++, p++) {
				void *bus_va;

				addr = page_address(p);
				phys = virt_to_phys(addr);
				pfn = PFN_DOWN(phys);

				bus_va = (void *)(dma_addr + (i * PAGE_SIZE));

				if (xen_domain()) {
					void * tmp;

					/* Find the bus frame for the physical frame*/
					mfn = pfn_to_mfn(pfn);
					/* and .. voodoo time! */
					bus_addr_mfn = PFN_DOWN(dma_addr + (i * PAGE_SIZE));
					bus_addr = PFN_PHYS(mfn_to_pfn(bus_addr_mfn));
					tmp = __va(bus_addr);
					bus_va = mfn_to_virt(bus_addr_mfn);
					WARN(bus_va != tmp, "Expected %lx (%lx+%d*PAGE_SIZE), got: %lx (pfn: %lx, mfn: %lx)!\n",
						(unsigned long)bus_va, (unsigned long)dma_addr, i, (unsigned long)tmp, PFN_DOWN(bus_addr), bus_addr_mfn);
				} else {
					mfn = pfn;
					/* Assume DMA addr == physical addr */
					bus_addr_mfn = PFN_DOWN(bus_addr);
					bus_va = __va(PFN_PHYS(bus_addr_mfn));
				}

				dev_info(&fake, "%lx (pfn:%lx, bus frame: %lx) %s %lx (addr: %lx, frame: %lx)\n",
					(unsigned long)addr, pfn, mfn,
					dir == DMA_TO_DEVICE ? "=>" : "<=",
					(unsigned long)bus_va, bus_addr, bus_addr_mfn);

				if (!virt_addr_valid(bus_va))
					break;
				if (!virt_addr_valid(addr))
					break;

				/* CPU */
				memset(addr, 0xCC, PAGE_SIZE);

				/* Device */
				memset(bus_va, 0xDD, PAGE_SIZE);
				if (addr == bus_va)
					bus_and_dma_same = true;
			}
		}
		set_current_state(TASK_INTERRUPTIBLE);
		schedule_timeout_interruptible(5*HZ);

		if (!page)
			continue;
		p = page;

		for (i = 0; i < len / PAGE_SIZE; i++, p++) {
			if (bus_and_dma_same)
				continue;
			addr = page_address(p);
			if (((char *)addr)[0] != MAGIC_CPU)
				dev_warn(&fake, "%lx with DMA (%lx) has %x (expected %lx)\n",
					(unsigned long)addr, (unsigned long)(dma_addr + (i * PAGE_SIZE)),
					((char *)addr)[0], (unsigned long)MAGIC_CPU);
		}
		/* sync the page */
		dma_sync_single_for_cpu(&fake, dma_addr, len, dir);
		p = page;
		for (i = 0; i < len / PAGE_SIZE; i++, p++) {
			unsigned long check_val = MAGIC_DEVICE;

			addr = page_address(p);
			if (dir == DMA_TO_DEVICE)
				check_val = MAGIC_CPU;
			if (dir == DMA_FROM_DEVICE)
				check_val = MAGIC_DEVICE;

			dev_info(&fake, "%lx with DMA (%lx) has %x (expected %lx)\n",
				(unsigned long)addr, (unsigned long)(dma_addr + (i * PAGE_SIZE)),
				((char *)addr)[0], check_val);
		}
		dma_unmap_page(&fake, dma_addr, len, dir);
		dma_addr = 0;
		__free_pages(page, get_order(len));
		page = NULL;
	} while (!kthread_should_stop());

	if (dma_addr)
		dma_unmap_page(&fake, dma_addr, len, dir);
	if (page)
		__free_pages(page, get_order(len));
   	put_device(&fake);
 	device_unregister(&fake);
out:
	return 0;
}
static struct task_struct *t[2];
static struct args a[2];

static int __init dma_test_init(void)
{
	int ret;

	/* No point doing this without SWIOTLB */
	if (!swiotlb_nr_tbl())
		return -ENODEV;

	ret = bus_register(&fallback_bus_type);
	if (ret)
		return ret;

	a[0].dir = DMA_TO_DEVICE;
	a[0].len = 32768;
	t[0] = kthread_run(dma_test_thread, &a[0], "dma_test_dev");

	a[1].len = 16384;
	a[1].dir = DMA_FROM_DEVICE;
	t[1] = kthread_run(dma_test_thread, &a[1], "dma_test_cpu");
	return 0;
}
static void __exit dma_test_exit(void)
{
	if (t[0])
		kthread_stop(t[0]);
	if (t[1])
		kthread_stop(t[1]);

 	bus_unregister(&fallback_bus_type);
}
module_init(dma_test_init);
module_exit(dma_test_exit);

--J/dobhs11T7y2rNN
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="0001-swiotlb-Add-debugging.patch"

>From db63c863456f0914ad96db38544c364eaad787ab Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk 
Date: Mon, 29 Oct 2012 09:35:55 -0400
Subject: [PATCH] swiotlb: Add debugging.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 include/linux/swiotlb.h |    2 +-
 lib/swiotlb.c           |   25 ++++++++++++++++++++-----
 2 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 8d08b3e..0a17d79 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -46,7 +46,7 @@ extern void swiotlb_tbl_sync_single(struct device *hwdev, char *dma_addr,
 				    enum dma_sync_target target);
 
 /* Accessory functions. */
-extern void swiotlb_bounce(phys_addr_t phys, char *dma_addr, size_t size,
+extern void swiotlb_bounce(struct device *dev, phys_addr_t phys, char *dma_addr, size_t size,
 			   enum dma_data_direction dir);
 
 extern void
diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index f114bf6..e5d37a3 100644
--- a/lib/swiotlb.c
+++ b/lib/swiotlb.c
@@ -346,7 +346,7 @@ static int is_swiotlb_buffer(phys_addr_t paddr)
 /*
  * Bounce: copy the swiotlb buffer back to the original dma location
  */
-void swiotlb_bounce(phys_addr_t phys, char *dma_addr, size_t size,
+void swiotlb_bounce(struct device *dev, phys_addr_t phys, char *dma_addr, size_t size,
 		    enum dma_data_direction dir)
 {
 	unsigned long pfn = PFN_DOWN(phys);
@@ -376,6 +376,21 @@ void swiotlb_bounce(phys_addr_t phys, char *dma_addr, size_t size,
 			offset = 0;
 		}
 	} else {
+		if (size >= PAGE_SIZE) {
+			const char *type;
+
+			if (dir == DMA_TO_DEVICE)
+				type = " <= ";
+			else if (dir == DMA_FROM_DEVICE)
+				type = " => ";
+			else
+				type = " <=> ";
+			dev_info(dev, "0x%lx%s %s 0x%lx%s (sz: %ld)\n", (unsigned long)dma_addr,
+				is_swiotlb_buffer(virt_to_phys(dma_addr)) ? "(bounce)" : "",
+				type, (unsigned long)phys_to_virt(phys),
+				is_swiotlb_buffer(phys) ? "(bounce)" : "",
+				size);
+		}
 		if (dir == DMA_TO_DEVICE)
 			memcpy(dma_addr, phys_to_virt(phys), size);
 		else
@@ -483,7 +498,7 @@ found:
 	for (i = 0; i < nslots; i++)
 		io_tlb_orig_addr[index+i] = phys + (i << IO_TLB_SHIFT);
 	if (dir == DMA_TO_DEVICE || dir == DMA_BIDIRECTIONAL)
-		swiotlb_bounce(phys, dma_addr, size, DMA_TO_DEVICE);
+		swiotlb_bounce(hwdev, phys, dma_addr, size, DMA_TO_DEVICE);
 
 	return dma_addr;
 }
@@ -518,7 +533,7 @@ swiotlb_tbl_unmap_single(struct device *hwdev, char *dma_addr, size_t size,
 	 * First, sync the memory before unmapping the entry
 	 */
 	if (phys && ((dir == DMA_FROM_DEVICE) || (dir == DMA_BIDIRECTIONAL)))
-		swiotlb_bounce(phys, dma_addr, size, DMA_FROM_DEVICE);
+		swiotlb_bounce(hwdev, phys, dma_addr, size, DMA_FROM_DEVICE);
 
 	/*
 	 * Return the buffer to the free list by setting the corresponding
@@ -560,13 +575,13 @@ swiotlb_tbl_sync_single(struct device *hwdev, char *dma_addr, size_t size,
 	switch (target) {
 	case SYNC_FOR_CPU:
 		if (likely(dir == DMA_FROM_DEVICE || dir == DMA_BIDIRECTIONAL))
-			swiotlb_bounce(phys, dma_addr, size, DMA_FROM_DEVICE);
+			swiotlb_bounce(hwdev, phys, dma_addr, size, DMA_FROM_DEVICE);
 		else
 			BUG_ON(dir != DMA_TO_DEVICE);
 		break;
 	case SYNC_FOR_DEVICE:
 		if (likely(dir == DMA_TO_DEVICE || dir == DMA_BIDIRECTIONAL))
-			swiotlb_bounce(phys, dma_addr, size, DMA_TO_DEVICE);
+			swiotlb_bounce(hwdev, phys, dma_addr, size, DMA_TO_DEVICE);
 		else
 			BUG_ON(dir != DMA_FROM_DEVICE);
 		break;
-- 
1.7.7.6


--J/dobhs11T7y2rNN
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--J/dobhs11T7y2rNN--


From xen-devel-bounces@lists.xen.org Mon Oct 29 16:33:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 16:33:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSsGz-00066m-V9; Mon, 29 Oct 2012 16:33:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSsGx-00066f-UV
	for xen-devel@lists.xensource.com; Mon, 29 Oct 2012 16:33:08 +0000
Received: from [85.158.138.51:29019] by server-14.bemta-3.messagelabs.com id
	C6/90-12788-3CFAE805; Mon, 29 Oct 2012 16:33:07 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1351528386!27946994!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzNTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4567 invoked from network); 29 Oct 2012 16:33:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Oct 2012 16:33:06 -0000
X-IronPort-AV: E=Sophos;i="4.80,673,1344211200"; d="scan'208";a="15470163"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Oct 2012 16:33:06 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Mon, 29 Oct 2012
	16:33:06 +0000
From: Thanos Makatos 
To: Ian Campbell 
Date: Mon, 29 Oct 2012 16:33:05 +0000
Thread-Topic: [Xen-devel] [PATCH 00 of 16 RFC] add libxl support for blktap3
	and introduce the blktap3 build system
Thread-Index: Ac2zax++3ghUMzWkTIyfjas4ESVk4gCh6/ow
Message-ID: <4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8C42@LONPMAILBOX01.citrite.net>
References: 
	<1351250092.15162.33.camel@zakaz.uk.xensource.com>
In-Reply-To: <1351250092.15162.33.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 00 of 16 RFC] add libxl support for blktap3
 and introduce the blktap3 build system
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Ian Campbell
> Sent: 26 October 2012 12:15
> To: Thanos Makatos
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 00 of 16 RFC] add libxl support for
> blktap3 and introduce the blktap3 build system
> 
> As it stands this series will break the build and/or xl functionality
> at various points. I recommend ordering them as:
>       * Stage 1: populate tools/blktap3, make it build with make -C
>         tools/blktap3 (build breakage within tools/blktap3 doesn't
>         matter during this stage)
>       * Stage 2: connect tools/blktap3 to the top-level build system,
>         but don't use it anywhere yet. At this point tools/blktap3 must
>         compile successfully.
>       * Third tranche: Patch libxl/xl etc to make them use blktap3
>         instead of blktap2.

OK this sounds plausible.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 16:33:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 16:33:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSsGz-00066m-V9; Mon, 29 Oct 2012 16:33:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSsGx-00066f-UV
	for xen-devel@lists.xensource.com; Mon, 29 Oct 2012 16:33:08 +0000
Received: from [85.158.138.51:29019] by server-14.bemta-3.messagelabs.com id
	C6/90-12788-3CFAE805; Mon, 29 Oct 2012 16:33:07 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1351528386!27946994!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzNTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4567 invoked from network); 29 Oct 2012 16:33:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Oct 2012 16:33:06 -0000
X-IronPort-AV: E=Sophos;i="4.80,673,1344211200"; d="scan'208";a="15470163"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Oct 2012 16:33:06 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Mon, 29 Oct 2012
	16:33:06 +0000
From: Thanos Makatos 
To: Ian Campbell 
Date: Mon, 29 Oct 2012 16:33:05 +0000
Thread-Topic: [Xen-devel] [PATCH 00 of 16 RFC] add libxl support for blktap3
	and introduce the blktap3 build system
Thread-Index: Ac2zax++3ghUMzWkTIyfjas4ESVk4gCh6/ow
Message-ID: <4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8C42@LONPMAILBOX01.citrite.net>
References: 
	<1351250092.15162.33.camel@zakaz.uk.xensource.com>
In-Reply-To: <1351250092.15162.33.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 00 of 16 RFC] add libxl support for blktap3
 and introduce the blktap3 build system
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Ian Campbell
> Sent: 26 October 2012 12:15
> To: Thanos Makatos
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 00 of 16 RFC] add libxl support for
> blktap3 and introduce the blktap3 build system
> 
> As it stands this series will break the build and/or xl functionality
> at various points. I recommend ordering them as:
>       * Stage 1: populate tools/blktap3, make it build with make -C
>         tools/blktap3 (build breakage within tools/blktap3 doesn't
>         matter during this stage)
>       * Stage 2: connect tools/blktap3 to the top-level build system,
>         but don't use it anywhere yet. At this point tools/blktap3 must
>         compile successfully.
>       * Third tranche: Patch libxl/xl etc to make them use blktap3
>         instead of blktap2.

OK this sounds plausible.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 16:36:13 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 16:36:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSsJd-0006C7-HL; Mon, 29 Oct 2012 16:35:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSsJb-0006Bz-Cl
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 16:35:51 +0000
Received: from [85.158.143.35:17549] by server-2.bemta-4.messagelabs.com id
	C1/8F-22268-660BE805; Mon, 29 Oct 2012 16:35:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1351528544!4470822!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13194 invoked from network); 29 Oct 2012 16:35:45 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-21.messagelabs.com with SMTP;
	29 Oct 2012 16:35:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 29 Oct 2012 16:34:44 +0000
Message-Id: <508EBE5C02000078000A5351@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 29 Oct 2012 16:35:24 +0000
From: "Jan Beulich" 
To: "Jinsong Liu" 
References: 
	
	
	<50852EB6.4060705@eu.citrix.com>
	
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: Christoph Egger ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	George Dunlap ,
	Ian Jackson ,
	xen-devel 
Subject: Re: [Xen-devel] [Patch 4/5] X86/vMCE: handle broken page occurred
 before migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 29.10.12 at 16:21, "Liu, Jinsong"  wrote:
> X86/vMCE: handle broken page occurred before migration
> 
> This patch handles guest broken page which occur before migration.
> 
> At sender, the broken page would be mapped but not copied to target
> (otherwise it may trigger more serious error, say, SRAR error).
> While its pfn_type and pfn number would be transferred to target
> so that target take appropriate action.
> 
> At target, it would set p2m as p2m_ram_broken for broken page, so that
> if guest access the broken page again, it would kill itself as expected.
> 
> Signed-off-by: Liu, Jinsong 

So I continue to be confused - wasn't the agreement you
reached with George that patch 5 re-done makes patch 4
unnecessary?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 16:36:13 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 16:36:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSsJd-0006C7-HL; Mon, 29 Oct 2012 16:35:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSsJb-0006Bz-Cl
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 16:35:51 +0000
Received: from [85.158.143.35:17549] by server-2.bemta-4.messagelabs.com id
	C1/8F-22268-660BE805; Mon, 29 Oct 2012 16:35:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1351528544!4470822!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13194 invoked from network); 29 Oct 2012 16:35:45 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-21.messagelabs.com with SMTP;
	29 Oct 2012 16:35:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 29 Oct 2012 16:34:44 +0000
Message-Id: <508EBE5C02000078000A5351@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 29 Oct 2012 16:35:24 +0000
From: "Jan Beulich" 
To: "Jinsong Liu" 
References: 
	
	
	<50852EB6.4060705@eu.citrix.com>
	
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: Christoph Egger ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	George Dunlap ,
	Ian Jackson ,
	xen-devel 
Subject: Re: [Xen-devel] [Patch 4/5] X86/vMCE: handle broken page occurred
 before migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 29.10.12 at 16:21, "Liu, Jinsong"  wrote:
> X86/vMCE: handle broken page occurred before migration
> 
> This patch handles guest broken page which occur before migration.
> 
> At sender, the broken page would be mapped but not copied to target
> (otherwise it may trigger more serious error, say, SRAR error).
> While its pfn_type and pfn number would be transferred to target
> so that target take appropriate action.
> 
> At target, it would set p2m as p2m_ram_broken for broken page, so that
> if guest access the broken page again, it would kill itself as expected.
> 
> Signed-off-by: Liu, Jinsong 

So I continue to be confused - wasn't the agreement you
reached with George that patch 5 re-done makes patch 4
unnecessary?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 16:45:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 16:45:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSsSk-0006RR-QL; Mon, 29 Oct 2012 16:45:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSsSj-0006RM-Oy
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 16:45:17 +0000
Received: from [85.158.139.83:51574] by server-14.bemta-5.messagelabs.com id
	65/36-21768-C92BE805; Mon, 29 Oct 2012 16:45:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1351529115!23949272!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8720 invoked from network); 29 Oct 2012 16:45:15 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-182.messagelabs.com with SMTP;
	29 Oct 2012 16:45:15 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 29 Oct 2012 16:45:14 +0000
Message-Id: <508EC0D202000078000A536A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 29 Oct 2012 16:45:54 +0000
From: "Jan Beulich" 
To: ,
	"Konrad Rzeszutek Wilk" 
Mime-Version: 1.0
Content-Disposition: inline
Cc: Randy Dunlap , xen-devel ,
	stern@rowland.harvard.edu, linux-usb@vger.kernel.org,
	Stefano Stabellini 
Subject: [Xen-devel] [PATCH,
 v2] fix build with XEN and EARLY_PRINTK_DBGP enabled but
 USB_SUPPORT disabled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Since there's no possible caller of dbgp_external_startup() and
dbgp_reset_prep() when !USB_EHCI_HCD, there's no point in building and
exporting these functions in that case. This eliminates a build error
under the conditions listed in the subject, introduced with the merge
f1c6872e4980bc4078cfaead05f892b3d78dea64.

Reported-by: Randy Dunlap 
Signed-off-by: Jan Beulich 
Cc: Stefano Stabellini 
Cc: Alan Stern 
---
v2: Switch the dependency from USB_SUPPORT to USB_EHCI_HCD as requested
    by Alan (albeit I don't really agree to that change).

---
 arch/x86/kernel/cpu/perf_event_p6.c |    2 +-
 drivers/usb/early/ehci-dbgp.c       |   15 +++++++++------
 2 files changed, 10 insertions(+), 7 deletions(-)

--- 3.7-rc3/drivers/usb/early/ehci-dbgp.c
+++ 3.7-rc3-ehci-dbgp-early-xen-no-usb/drivers/usb/early/ehci-dbgp.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -614,12 +615,6 @@ err:
 	return -ENODEV;
 }
 
-int dbgp_external_startup(struct usb_hcd *hcd)
-{
-	return xen_dbgp_external_startup(hcd) ?: _dbgp_external_startup();
-}
-EXPORT_SYMBOL_GPL(dbgp_external_startup);
-
 static int ehci_reset_port(int port)
 {
 	u32 portsc;
@@ -979,6 +974,7 @@ struct console early_dbgp_console = {
 	.index =	-1,
 };
 
+#if IS_ENABLED(CONFIG_USB_EHCI_HCD)
 int dbgp_reset_prep(struct usb_hcd *hcd)
 {
 	int ret = xen_dbgp_reset_prep(hcd);
@@ -1007,6 +1003,13 @@ int dbgp_reset_prep(struct usb_hcd *hcd)
 }
 EXPORT_SYMBOL_GPL(dbgp_reset_prep);
 
+int dbgp_external_startup(struct usb_hcd *hcd)
+{
+	return xen_dbgp_external_startup(hcd) ?: _dbgp_external_startup();
+}
+EXPORT_SYMBOL_GPL(dbgp_external_startup);
+#endif /* USB_EHCI_HCD */
+
 #ifdef CONFIG_KGDB
 
 static char kgdbdbgp_buf[DBGP_MAX_PACKET];




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 16:45:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 16:45:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSsSk-0006RR-QL; Mon, 29 Oct 2012 16:45:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSsSj-0006RM-Oy
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 16:45:17 +0000
Received: from [85.158.139.83:51574] by server-14.bemta-5.messagelabs.com id
	65/36-21768-C92BE805; Mon, 29 Oct 2012 16:45:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1351529115!23949272!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8720 invoked from network); 29 Oct 2012 16:45:15 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-182.messagelabs.com with SMTP;
	29 Oct 2012 16:45:15 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 29 Oct 2012 16:45:14 +0000
Message-Id: <508EC0D202000078000A536A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 29 Oct 2012 16:45:54 +0000
From: "Jan Beulich" 
To: ,
	"Konrad Rzeszutek Wilk" 
Mime-Version: 1.0
Content-Disposition: inline
Cc: Randy Dunlap , xen-devel ,
	stern@rowland.harvard.edu, linux-usb@vger.kernel.org,
	Stefano Stabellini 
Subject: [Xen-devel] [PATCH,
 v2] fix build with XEN and EARLY_PRINTK_DBGP enabled but
 USB_SUPPORT disabled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Since there's no possible caller of dbgp_external_startup() and
dbgp_reset_prep() when !USB_EHCI_HCD, there's no point in building and
exporting these functions in that case. This eliminates a build error
under the conditions listed in the subject, introduced with the merge
f1c6872e4980bc4078cfaead05f892b3d78dea64.

Reported-by: Randy Dunlap 
Signed-off-by: Jan Beulich 
Cc: Stefano Stabellini 
Cc: Alan Stern 
---
v2: Switch the dependency from USB_SUPPORT to USB_EHCI_HCD as requested
    by Alan (albeit I don't really agree to that change).

---
 arch/x86/kernel/cpu/perf_event_p6.c |    2 +-
 drivers/usb/early/ehci-dbgp.c       |   15 +++++++++------
 2 files changed, 10 insertions(+), 7 deletions(-)

--- 3.7-rc3/drivers/usb/early/ehci-dbgp.c
+++ 3.7-rc3-ehci-dbgp-early-xen-no-usb/drivers/usb/early/ehci-dbgp.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -614,12 +615,6 @@ err:
 	return -ENODEV;
 }
 
-int dbgp_external_startup(struct usb_hcd *hcd)
-{
-	return xen_dbgp_external_startup(hcd) ?: _dbgp_external_startup();
-}
-EXPORT_SYMBOL_GPL(dbgp_external_startup);
-
 static int ehci_reset_port(int port)
 {
 	u32 portsc;
@@ -979,6 +974,7 @@ struct console early_dbgp_console = {
 	.index =	-1,
 };
 
+#if IS_ENABLED(CONFIG_USB_EHCI_HCD)
 int dbgp_reset_prep(struct usb_hcd *hcd)
 {
 	int ret = xen_dbgp_reset_prep(hcd);
@@ -1007,6 +1003,13 @@ int dbgp_reset_prep(struct usb_hcd *hcd)
 }
 EXPORT_SYMBOL_GPL(dbgp_reset_prep);
 
+int dbgp_external_startup(struct usb_hcd *hcd)
+{
+	return xen_dbgp_external_startup(hcd) ?: _dbgp_external_startup();
+}
+EXPORT_SYMBOL_GPL(dbgp_external_startup);
+#endif /* USB_EHCI_HCD */
+
 #ifdef CONFIG_KGDB
 
 static char kgdbdbgp_buf[DBGP_MAX_PACKET];




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 16:51:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 16:51:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSsY9-0006bN-J0; Mon, 29 Oct 2012 16:50:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSsY8-0006bI-AK
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 16:50:52 +0000
Received: from [85.158.143.99:15120] by server-1.bemta-4.messagelabs.com id
	E4/49-19134-BE3BE805; Mon, 29 Oct 2012 16:50:51 +0000
X-Env-Sender: gregkh@linuxfoundation.org
X-Msg-Ref: server-8.tower-216.messagelabs.com!1351529450!18049122!1
X-Originating-IP: [198.145.19.201]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28658 invoked from network); 29 Oct 2012 16:50:51 -0000
Received: from mail.kernel.org (HELO mail.kernel.org) (198.145.19.201)
	by server-8.tower-216.messagelabs.com with SMTP;
	29 Oct 2012 16:50:51 -0000
Received: from mail.kernel.org (localhost [127.0.0.1])
	by mail.kernel.org (Postfix) with ESMTP id EDB612039E;
	Mon, 29 Oct 2012 16:50:48 +0000 (UTC)
Received: from localhost (c-67-168-183-230.hsd1.wa.comcast.net
	[67.168.183.230])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.kernel.org (Postfix) with ESMTPSA id 32F1520396;
	Mon, 29 Oct 2012 16:50:48 +0000 (UTC)
Date: Mon, 29 Oct 2012 09:50:47 -0700
From: Greg KH 
To: Jan Beulich 
Message-ID: <20121029165047.GA22984@kroah.com>
References: <508EC0D202000078000A536A@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <508EC0D202000078000A536A@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,UNPARSEABLE_RELAY
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org
X-Virus-Scanned: ClamAV using ClamSMTP
Cc: Konrad Rzeszutek Wilk ,
	Stefano Stabellini ,
	linux-usb@vger.kernel.org, xen-devel ,
	Randy Dunlap , stern@rowland.harvard.edu
Subject: Re: [Xen-devel] [PATCH,
 v2] fix build with XEN and EARLY_PRINTK_DBGP enabled but
 USB_SUPPORT disabled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 29, 2012 at 04:45:54PM +0000, Jan Beulich wrote:
> Since there's no possible caller of dbgp_external_startup() and
> dbgp_reset_prep() when !USB_EHCI_HCD, there's no point in building and
> exporting these functions in that case. This eliminates a build error
> under the conditions listed in the subject, introduced with the merge
> f1c6872e4980bc4078cfaead05f892b3d78dea64.

That's a merge commit, is that where the problem happened because Linus
did the merge resolution incorrectly, or is it really due to some other
patch that added this feature incorrectly?

If the latter, please provide that git commit id.

thanks,

greg k-h

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 16:51:08 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 16:51:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSsY9-0006bN-J0; Mon, 29 Oct 2012 16:50:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSsY8-0006bI-AK
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 16:50:52 +0000
Received: from [85.158.143.99:15120] by server-1.bemta-4.messagelabs.com id
	E4/49-19134-BE3BE805; Mon, 29 Oct 2012 16:50:51 +0000
X-Env-Sender: gregkh@linuxfoundation.org
X-Msg-Ref: server-8.tower-216.messagelabs.com!1351529450!18049122!1
X-Originating-IP: [198.145.19.201]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28658 invoked from network); 29 Oct 2012 16:50:51 -0000
Received: from mail.kernel.org (HELO mail.kernel.org) (198.145.19.201)
	by server-8.tower-216.messagelabs.com with SMTP;
	29 Oct 2012 16:50:51 -0000
Received: from mail.kernel.org (localhost [127.0.0.1])
	by mail.kernel.org (Postfix) with ESMTP id EDB612039E;
	Mon, 29 Oct 2012 16:50:48 +0000 (UTC)
Received: from localhost (c-67-168-183-230.hsd1.wa.comcast.net
	[67.168.183.230])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.kernel.org (Postfix) with ESMTPSA id 32F1520396;
	Mon, 29 Oct 2012 16:50:48 +0000 (UTC)
Date: Mon, 29 Oct 2012 09:50:47 -0700
From: Greg KH 
To: Jan Beulich 
Message-ID: <20121029165047.GA22984@kroah.com>
References: <508EC0D202000078000A536A@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <508EC0D202000078000A536A@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,UNPARSEABLE_RELAY
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org
X-Virus-Scanned: ClamAV using ClamSMTP
Cc: Konrad Rzeszutek Wilk ,
	Stefano Stabellini ,
	linux-usb@vger.kernel.org, xen-devel ,
	Randy Dunlap , stern@rowland.harvard.edu
Subject: Re: [Xen-devel] [PATCH,
 v2] fix build with XEN and EARLY_PRINTK_DBGP enabled but
 USB_SUPPORT disabled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 29, 2012 at 04:45:54PM +0000, Jan Beulich wrote:
> Since there's no possible caller of dbgp_external_startup() and
> dbgp_reset_prep() when !USB_EHCI_HCD, there's no point in building and
> exporting these functions in that case. This eliminates a build error
> under the conditions listed in the subject, introduced with the merge
> f1c6872e4980bc4078cfaead05f892b3d78dea64.

That's a merge commit, is that where the problem happened because Linus
did the merge resolution incorrectly, or is it really due to some other
patch that added this feature incorrectly?

If the latter, please provide that git commit id.

thanks,

greg k-h

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 16:59:06 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 16:59:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSsfn-0006kQ-Hw; Mon, 29 Oct 2012 16:58:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSsfl-0006kL-En
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 16:58:45 +0000
Received: from [85.158.137.99:4880] by server-3.bemta-3.messagelabs.com id
	CA/51-09368-4C5BE805; Mon, 29 Oct 2012 16:58:44 +0000
X-Env-Sender: sshtylyov@mvista.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1351529923!18704728!1
X-Originating-IP: [209.85.217.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13555 invoked from network); 29 Oct 2012 16:58:44 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Oct 2012 16:58:44 -0000
Received: by mail-lb0-f173.google.com with SMTP id gj3so4083794lbb.32
	for ; Mon, 29 Oct 2012 09:58:43 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding
	:x-gm-message-state;
	bh=tbgavoicSSE2aCKjnMyAx9vR0ApRjy5VzlkGThPIuvk=;
	b=KqLzICtD4fPHVwxNkHzuDNMsuzEgviUn2ko2Vb5MF6zTE9nYQgCJtsQd6oZgu4zPPl
	h3GtFD927Anegjzkry6NV7paIzW6oQtLAbMAoqYYdOTpTcKqKynVotSY0yxBBBGYtOx7
	LJhitIvKsEUfFB3d/lh9qAc6LTGnJpJwDSqBuiP4Apw4gQajMlLgZ6IBtNa2CFomrHkK
	Os1HE8N7LuZYvcG1HLX95V9LZG4bJ1ffidasZ33u58H2b3eQU+xdKVhl9IzZeUaGtzZ9
	5Mizke4+Gib3JHgpj54hqrgOTyLXnsdUenSXovj3uFfvNQbYOZIrpzNVWTFeB2cp550O
	z5ow==
Received: by 10.112.30.230 with SMTP id v6mr12389179lbh.18.1351529923042;
	Mon, 29 Oct 2012 09:58:43 -0700 (PDT)
Received: from wasted.dev.rtsoft.ru (mail.dev.rtsoft.ru. [213.79.90.226])
	by mx.google.com with ESMTPS id i7sm3375183lbg.13.2012.10.29.09.58.40
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 29 Oct 2012 09:58:42 -0700 (PDT)
Message-ID: <508EC391.2050400@mvista.com>
Date: Mon, 29 Oct 2012 20:57:37 +0300
From: Sergei Shtylyov 
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: Jan Beulich 
References: <508EC0D202000078000A536A@nat28.tlf.novell.com>
In-Reply-To: <508EC0D202000078000A536A@nat28.tlf.novell.com>
X-Gm-Message-State: ALoCoQkNF4sJopHnA5YFPq513zKzPP6wdsx6EX+8HQG9L/swk3cl3X2oJWvPLZBHxgzBonjFoNGk
Cc: Konrad Rzeszutek Wilk ,
	Stefano Stabellini ,
	gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
	xen-devel ,
	Randy Dunlap , stern@rowland.harvard.edu
Subject: Re: [Xen-devel] [PATCH,
 v2] fix build with XEN and EARLY_PRINTK_DBGP enabled but
 USB_SUPPORT disabled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello.

On 10/29/2012 07:45 PM, Jan Beulich wrote:

> Since there's no possible caller of dbgp_external_startup() and
> dbgp_reset_prep() when !USB_EHCI_HCD, there's no point in building and
> exporting these functions in that case. This eliminates a build error
> under the conditions listed in the subject, introduced with the merge
> f1c6872e4980bc4078cfaead05f892b3d78dea64.

   Summary of that merge needs to be quoted I think, as well as in the case it
was a normal commit...

> Reported-by: Randy Dunlap 
> Signed-off-by: Jan Beulich 
> Cc: Stefano Stabellini 
> Cc: Alan Stern 

WBR, Sergei


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 16:59:06 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 16:59:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSsfn-0006kQ-Hw; Mon, 29 Oct 2012 16:58:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSsfl-0006kL-En
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 16:58:45 +0000
Received: from [85.158.137.99:4880] by server-3.bemta-3.messagelabs.com id
	CA/51-09368-4C5BE805; Mon, 29 Oct 2012 16:58:44 +0000
X-Env-Sender: sshtylyov@mvista.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1351529923!18704728!1
X-Originating-IP: [209.85.217.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13555 invoked from network); 29 Oct 2012 16:58:44 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Oct 2012 16:58:44 -0000
Received: by mail-lb0-f173.google.com with SMTP id gj3so4083794lbb.32
	for ; Mon, 29 Oct 2012 09:58:43 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding
	:x-gm-message-state;
	bh=tbgavoicSSE2aCKjnMyAx9vR0ApRjy5VzlkGThPIuvk=;
	b=KqLzICtD4fPHVwxNkHzuDNMsuzEgviUn2ko2Vb5MF6zTE9nYQgCJtsQd6oZgu4zPPl
	h3GtFD927Anegjzkry6NV7paIzW6oQtLAbMAoqYYdOTpTcKqKynVotSY0yxBBBGYtOx7
	LJhitIvKsEUfFB3d/lh9qAc6LTGnJpJwDSqBuiP4Apw4gQajMlLgZ6IBtNa2CFomrHkK
	Os1HE8N7LuZYvcG1HLX95V9LZG4bJ1ffidasZ33u58H2b3eQU+xdKVhl9IzZeUaGtzZ9
	5Mizke4+Gib3JHgpj54hqrgOTyLXnsdUenSXovj3uFfvNQbYOZIrpzNVWTFeB2cp550O
	z5ow==
Received: by 10.112.30.230 with SMTP id v6mr12389179lbh.18.1351529923042;
	Mon, 29 Oct 2012 09:58:43 -0700 (PDT)
Received: from wasted.dev.rtsoft.ru (mail.dev.rtsoft.ru. [213.79.90.226])
	by mx.google.com with ESMTPS id i7sm3375183lbg.13.2012.10.29.09.58.40
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 29 Oct 2012 09:58:42 -0700 (PDT)
Message-ID: <508EC391.2050400@mvista.com>
Date: Mon, 29 Oct 2012 20:57:37 +0300
From: Sergei Shtylyov 
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: Jan Beulich 
References: <508EC0D202000078000A536A@nat28.tlf.novell.com>
In-Reply-To: <508EC0D202000078000A536A@nat28.tlf.novell.com>
X-Gm-Message-State: ALoCoQkNF4sJopHnA5YFPq513zKzPP6wdsx6EX+8HQG9L/swk3cl3X2oJWvPLZBHxgzBonjFoNGk
Cc: Konrad Rzeszutek Wilk ,
	Stefano Stabellini ,
	gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
	xen-devel ,
	Randy Dunlap , stern@rowland.harvard.edu
Subject: Re: [Xen-devel] [PATCH,
 v2] fix build with XEN and EARLY_PRINTK_DBGP enabled but
 USB_SUPPORT disabled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello.

On 10/29/2012 07:45 PM, Jan Beulich wrote:

> Since there's no possible caller of dbgp_external_startup() and
> dbgp_reset_prep() when !USB_EHCI_HCD, there's no point in building and
> exporting these functions in that case. This eliminates a build error
> under the conditions listed in the subject, introduced with the merge
> f1c6872e4980bc4078cfaead05f892b3d78dea64.

   Summary of that merge needs to be quoted I think, as well as in the case it
was a normal commit...

> Reported-by: Randy Dunlap 
> Signed-off-by: Jan Beulich 
> Cc: Stefano Stabellini 
> Cc: Alan Stern 

WBR, Sergei


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 17:06:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 17:06:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSsnN-0006wr-F5; Mon, 29 Oct 2012 17:06:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSsnM-0006wm-Es
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 17:06:36 +0000
Received: from [85.158.139.83:47931] by server-14.bemta-5.messagelabs.com id
	A8/0E-21768-B97BE805; Mon, 29 Oct 2012 17:06:35 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1351530393!27829023!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20763 invoked from network); 29 Oct 2012 17:06:34 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Oct 2012 17:06:34 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9TH6IXO031078
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 29 Oct 2012 17:06:19 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9TH6HfI029422
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 29 Oct 2012 17:06:18 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9TH6Gjj009205; Mon, 29 Oct 2012 12:06:17 -0500
MIME-Version: 1.0
Message-ID: <60d00f38-98a3-4ec2-acbd-b49dafaada56@default>
Date: Mon, 29 Oct 2012 10:06:15 -0700 (PDT)
From: Dan Magenheimer 
To: "Keir (Xen.org)" , Jan Beulich 
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Olaf Hering , Ian Campbell ,
	Konrad Wilk ,
	George Dunlap ,
	George Shuklin ,
	"Tim \(Xen.org\)" , xen-devel@lists.xen.org,
	Dario Faggioli , Kurt Hackel ,
	Zhigang Wang ,
	Ian Jackson 
Subject: [Xen-devel] Proposed new "memory capacity claim" hypercall/feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Keir, Jan (et al) --

In a recent long thread [1], there was a great deal of discussion
about the possible need for a "memory reservation" hypercall.
While there was some confusion due to the two worldviews of static
vs dynamic management of physical memory capacity, one worldview
definitely has a requirement for this new capability.  It is still
uncertain whether the other worldview will benefit as well, though
I believe it eventually will, especially when page sharing is
fully deployed.

Note that to avoid confusion with existing usages of various
terms (such as "reservation"), I am now using the distinct
word "claim" as in a "land claim" or "mining claim":
http://dictionary.cambridge.org/dictionary/british/stake-a-claim 
When a toolstack creates a domain, it can first "stake a claim"
to the amount of memory capacity necessary to ensure the domain
launch will succeed.

In order to explore feasibility, I wanted to propose a possible
hypervisor design and would very much appreciate feedback!

The objective of the design is to ensure that a multi-threaded
toolstack can atomically claim a specific amount of RAM capacity for a
domain, especially in the presence of independent dynamic memory demand
(such as tmem and selfballooning) which the toolstack is not able to track.
"Claim X 50G" means that, on completion of the call, either (A) 50G of
capacity has been claimed for use by domain X and the call returns
success or (B) the call returns failure.  Note that in the above,
"claim" explicitly does NOT mean that specific physical RAM pages have
been assigned, only that the 50G of RAM capacity is not available either
to a subsequent "claim" or for most[2] independent dynamic memory demands.

I think the underlying hypervisor issue is that the current process
of "reserving" memory capacity (which currently does assign specific
physical RAM pages) is, by necessity when used for large quantities of RAM,
batched and slow and, consequently, can NOT be atomic.  One way to think
of the newly proposed "claim" is as "lazy reserving":  The capacity is
set aside even though specific physical RAM pages have not been assigned.
In another way, claiming is really just an accounting illusion, similar
to how an accountant must "accrue" future liabilities.

Hypervisor design/implementation overview:

A domain currently does RAM accounting with two primary counters
"tot_pages" and "max_pages".  (For now, let's ignore shr_pages,
paged_pages, and xenheap_pages, and I hope Olaf/Andre/others can
provide further expertise and input.)

Tot_pages is a struct_domain element in the hypervisor that tracks
the number of physical RAM pageframes "owned" by the domain.  The
hypervisor enforces that tot_pages is never allowed to exceed another
struct_domain element called max_pages.

I would like to introduce a new counter, which records how
much capacity is claimed for a domain which may or may not yet be
mapped to physical RAM pageframes.  To do so, I'd like to split
the concept of tot_pages into two variables, tot_phys_pages and
tot_claimed_pages and require the hypervisor to also enforce:

d.tot_phys_pages <= d.tot_claimed_pages[3] <= d.max_pages

I'd also split the hypervisor global "total_avail_pages" into
"total_free_pages" and "total_unclaimed_pages".  (I'm definitely
going to need to study more the two-dimensional array "avail"...)
The hypervisor must now do additional accounting to keep track
of the sum of claims across all domains and also enforce the
global:

total_unclaimed_pages <= total_free_pages

I think the memory_op hypercall can be extended to add two
additional subops, XENMEM_claim and XENMEM_release.  (Note: To
support tmem, there will need to be two variations of XEN_claim,
"hard claim" and "soft claim" [3].)  The XEN_claim subop atomically
evaluates total_unclaimed_pages against the new claim, claims
the pages for the domain if possible and returns success or failure.
The XEN_release "unsets" the domain's tot_claimed_pages (to an
"illegal" value such as zero or MINUS_ONE).

The hypervisor must also enforce some semantics:  If an allocation
occurs such that a domain's tot_phys_pages would equal or exceed
d.tot_claimed_pages, then d.tot_claimed_pages becomes "unset".
This enforces the temporary nature of a claim:  Once a domain
fully "occupies" its claim, the claim silently expires.

In the case of a dying domain, a XENMEM_release operation
is implied and must be executed by the hypervisor.

Ideally, the quantity of unclaimed memory for each domain and
for the system should be query-able.  This may require additional
memory_op hypercalls.

I'd very much appreciate feedback on this proposed design!

Thanks,
Dan

[1] http://lists.xen.org/archives/html/xen-devel/2012-09/msg02229.html
    and continued in October (the archives don't thread across months)
    http://lists.xen.org/archives/html/xen-devel/2012-10/msg00080.html 
[2] Pages used to store tmem "ephemeral" data may be an exception
    because those pages are "free-on-demand".
[3] I'd be happy to explain the minor additional work necessary to
    support tmem but have mostly left it out of the proposal for clarity.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 17:06:52 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 17:06:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSsnN-0006wr-F5; Mon, 29 Oct 2012 17:06:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSsnM-0006wm-Es
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 17:06:36 +0000
Received: from [85.158.139.83:47931] by server-14.bemta-5.messagelabs.com id
	A8/0E-21768-B97BE805; Mon, 29 Oct 2012 17:06:35 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1351530393!27829023!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20763 invoked from network); 29 Oct 2012 17:06:34 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Oct 2012 17:06:34 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9TH6IXO031078
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 29 Oct 2012 17:06:19 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9TH6HfI029422
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 29 Oct 2012 17:06:18 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9TH6Gjj009205; Mon, 29 Oct 2012 12:06:17 -0500
MIME-Version: 1.0
Message-ID: <60d00f38-98a3-4ec2-acbd-b49dafaada56@default>
Date: Mon, 29 Oct 2012 10:06:15 -0700 (PDT)
From: Dan Magenheimer 
To: "Keir (Xen.org)" , Jan Beulich 
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Olaf Hering , Ian Campbell ,
	Konrad Wilk ,
	George Dunlap ,
	George Shuklin ,
	"Tim \(Xen.org\)" , xen-devel@lists.xen.org,
	Dario Faggioli , Kurt Hackel ,
	Zhigang Wang ,
	Ian Jackson 
Subject: [Xen-devel] Proposed new "memory capacity claim" hypercall/feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Keir, Jan (et al) --

In a recent long thread [1], there was a great deal of discussion
about the possible need for a "memory reservation" hypercall.
While there was some confusion due to the two worldviews of static
vs dynamic management of physical memory capacity, one worldview
definitely has a requirement for this new capability.  It is still
uncertain whether the other worldview will benefit as well, though
I believe it eventually will, especially when page sharing is
fully deployed.

Note that to avoid confusion with existing usages of various
terms (such as "reservation"), I am now using the distinct
word "claim" as in a "land claim" or "mining claim":
http://dictionary.cambridge.org/dictionary/british/stake-a-claim 
When a toolstack creates a domain, it can first "stake a claim"
to the amount of memory capacity necessary to ensure the domain
launch will succeed.

In order to explore feasibility, I wanted to propose a possible
hypervisor design and would very much appreciate feedback!

The objective of the design is to ensure that a multi-threaded
toolstack can atomically claim a specific amount of RAM capacity for a
domain, especially in the presence of independent dynamic memory demand
(such as tmem and selfballooning) which the toolstack is not able to track.
"Claim X 50G" means that, on completion of the call, either (A) 50G of
capacity has been claimed for use by domain X and the call returns
success or (B) the call returns failure.  Note that in the above,
"claim" explicitly does NOT mean that specific physical RAM pages have
been assigned, only that the 50G of RAM capacity is not available either
to a subsequent "claim" or for most[2] independent dynamic memory demands.

I think the underlying hypervisor issue is that the current process
of "reserving" memory capacity (which currently does assign specific
physical RAM pages) is, by necessity when used for large quantities of RAM,
batched and slow and, consequently, can NOT be atomic.  One way to think
of the newly proposed "claim" is as "lazy reserving":  The capacity is
set aside even though specific physical RAM pages have not been assigned.
In another way, claiming is really just an accounting illusion, similar
to how an accountant must "accrue" future liabilities.

Hypervisor design/implementation overview:

A domain currently does RAM accounting with two primary counters
"tot_pages" and "max_pages".  (For now, let's ignore shr_pages,
paged_pages, and xenheap_pages, and I hope Olaf/Andre/others can
provide further expertise and input.)

Tot_pages is a struct_domain element in the hypervisor that tracks
the number of physical RAM pageframes "owned" by the domain.  The
hypervisor enforces that tot_pages is never allowed to exceed another
struct_domain element called max_pages.

I would like to introduce a new counter, which records how
much capacity is claimed for a domain which may or may not yet be
mapped to physical RAM pageframes.  To do so, I'd like to split
the concept of tot_pages into two variables, tot_phys_pages and
tot_claimed_pages and require the hypervisor to also enforce:

d.tot_phys_pages <= d.tot_claimed_pages[3] <= d.max_pages

I'd also split the hypervisor global "total_avail_pages" into
"total_free_pages" and "total_unclaimed_pages".  (I'm definitely
going to need to study more the two-dimensional array "avail"...)
The hypervisor must now do additional accounting to keep track
of the sum of claims across all domains and also enforce the
global:

total_unclaimed_pages <= total_free_pages

I think the memory_op hypercall can be extended to add two
additional subops, XENMEM_claim and XENMEM_release.  (Note: To
support tmem, there will need to be two variations of XEN_claim,
"hard claim" and "soft claim" [3].)  The XEN_claim subop atomically
evaluates total_unclaimed_pages against the new claim, claims
the pages for the domain if possible and returns success or failure.
The XEN_release "unsets" the domain's tot_claimed_pages (to an
"illegal" value such as zero or MINUS_ONE).

The hypervisor must also enforce some semantics:  If an allocation
occurs such that a domain's tot_phys_pages would equal or exceed
d.tot_claimed_pages, then d.tot_claimed_pages becomes "unset".
This enforces the temporary nature of a claim:  Once a domain
fully "occupies" its claim, the claim silently expires.

In the case of a dying domain, a XENMEM_release operation
is implied and must be executed by the hypervisor.

Ideally, the quantity of unclaimed memory for each domain and
for the system should be query-able.  This may require additional
memory_op hypercalls.

I'd very much appreciate feedback on this proposed design!

Thanks,
Dan

[1] http://lists.xen.org/archives/html/xen-devel/2012-09/msg02229.html
    and continued in October (the archives don't thread across months)
    http://lists.xen.org/archives/html/xen-devel/2012-10/msg00080.html 
[2] Pages used to store tmem "ephemeral" data may be an exception
    because those pages are "free-on-demand".
[3] I'd be happy to explain the minor additional work necessary to
    support tmem but have mostly left it out of the proposal for clarity.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 17:30:03 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 17:30:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSt9j-0007Ad-H0; Mon, 29 Oct 2012 17:29:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSt9h-0007AY-Fz
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 17:29:41 +0000
Received: from [85.158.138.51:18406] by server-14.bemta-3.messagelabs.com id
	C5/7F-12788-40DBE805; Mon, 29 Oct 2012 17:29:40 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1351531775!9190922!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMzNzg3NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18594 invoked from network); 29 Oct 2012 17:29:40 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-13.tower-174.messagelabs.com with SMTP;
	29 Oct 2012 17:29:40 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 29 Oct 2012 10:29:34 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,673,1344236400"; d="scan'208";a="239886070"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by fmsmga001.fm.intel.com with ESMTP; 29 Oct 2012 10:19:30 -0700
Received: from fmsmsx151.amr.corp.intel.com (10.19.17.220) by
	FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 29 Oct 2012 10:19:30 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX151.amr.corp.intel.com (10.19.17.220) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 29 Oct 2012 10:19:30 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.186]) with mapi id
	14.01.0355.002; Tue, 30 Oct 2012 01:19:28 +0800
From: "Liu, Jinsong" 
To: Jan Beulich 
Thread-Topic: [Xen-devel] [Patch 4/5] X86/vMCE: handle broken page occurred
	before migration
Thread-Index: AQHNtfPCxMZxwfDs1kKQngMxENsF3pfQf/UQ
Date: Mon, 29 Oct 2012 17:19:28 +0000
Message-ID: 
References: 
	
	
	<50852EB6.4060705@eu.citrix.com>
	
	<508EBE5C02000078000A5351@nat28.tlf.novell.com>
In-Reply-To: <508EBE5C02000078000A5351@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Christoph Egger ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	George Dunlap ,
	Ian Jackson ,
	xen-devel 
Subject: Re: [Xen-devel] [Patch 4/5] X86/vMCE: handle broken page occurred
 before migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Jan Beulich wrote:
>>>> On 29.10.12 at 16:21, "Liu, Jinsong"  wrote:
>> X86/vMCE: handle broken page occurred before migration
>> 
>> This patch handles guest broken page which occur before migration.
>> 
>> At sender, the broken page would be mapped but not copied to target
>> (otherwise it may trigger more serious error, say, SRAR error).
>> While its pfn_type and pfn number would be transferred to target
>> so that target take appropriate action.
>> 
>> At target, it would set p2m as p2m_ram_broken for broken page, so
>> that if guest access the broken page again, it would kill itself as
>> expected. 
>> 
>> Signed-off-by: Liu, Jinsong 
> 
> So I continue to be confused - wasn't the agreement you
> reached with George that patch 5 re-done makes patch 4
> unnecessary?
> 

No, the agreement is,
old patch 5 don't need re-do, it's OK to handle 'vmce occur before migration',
old patch 4 need update a little, it's used to handle 'vmce occur during migration', but need updated as 'not abort migration';

===============
BTW, this time I adjust the sequence of patch 4 and 5, since the new approach for 'vmce occur during migration' rely on some logic of 'vmce occur before migration'.

So latest patch 4 and 5 are:
patch 4 (same as old patch 5, no update): handle 'vmce occurred before migration';
patch 5 (updated old patch 4, according to George's suggestion): handle 'vmce occurs during migration' -- it updated a little for old patch 4 -- it didn't abort migration, instead it mark the broken page to dirty bitmap, so that at copypages stage of migration, the pfn_type and pfn number of broken page would transfer to target and then take appropriate action;

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 17:30:03 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 17:30:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSt9j-0007Ad-H0; Mon, 29 Oct 2012 17:29:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSt9h-0007AY-Fz
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 17:29:41 +0000
Received: from [85.158.138.51:18406] by server-14.bemta-3.messagelabs.com id
	C5/7F-12788-40DBE805; Mon, 29 Oct 2012 17:29:40 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1351531775!9190922!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMzNzg3NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18594 invoked from network); 29 Oct 2012 17:29:40 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-13.tower-174.messagelabs.com with SMTP;
	29 Oct 2012 17:29:40 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 29 Oct 2012 10:29:34 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,673,1344236400"; d="scan'208";a="239886070"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by fmsmga001.fm.intel.com with ESMTP; 29 Oct 2012 10:19:30 -0700
Received: from fmsmsx151.amr.corp.intel.com (10.19.17.220) by
	FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 29 Oct 2012 10:19:30 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX151.amr.corp.intel.com (10.19.17.220) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 29 Oct 2012 10:19:30 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.186]) with mapi id
	14.01.0355.002; Tue, 30 Oct 2012 01:19:28 +0800
From: "Liu, Jinsong" 
To: Jan Beulich 
Thread-Topic: [Xen-devel] [Patch 4/5] X86/vMCE: handle broken page occurred
	before migration
Thread-Index: AQHNtfPCxMZxwfDs1kKQngMxENsF3pfQf/UQ
Date: Mon, 29 Oct 2012 17:19:28 +0000
Message-ID: 
References: 
	
	
	<50852EB6.4060705@eu.citrix.com>
	
	<508EBE5C02000078000A5351@nat28.tlf.novell.com>
In-Reply-To: <508EBE5C02000078000A5351@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Christoph Egger ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	George Dunlap ,
	Ian Jackson ,
	xen-devel 
Subject: Re: [Xen-devel] [Patch 4/5] X86/vMCE: handle broken page occurred
 before migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Jan Beulich wrote:
>>>> On 29.10.12 at 16:21, "Liu, Jinsong"  wrote:
>> X86/vMCE: handle broken page occurred before migration
>> 
>> This patch handles guest broken page which occur before migration.
>> 
>> At sender, the broken page would be mapped but not copied to target
>> (otherwise it may trigger more serious error, say, SRAR error).
>> While its pfn_type and pfn number would be transferred to target
>> so that target take appropriate action.
>> 
>> At target, it would set p2m as p2m_ram_broken for broken page, so
>> that if guest access the broken page again, it would kill itself as
>> expected. 
>> 
>> Signed-off-by: Liu, Jinsong 
> 
> So I continue to be confused - wasn't the agreement you
> reached with George that patch 5 re-done makes patch 4
> unnecessary?
> 

No, the agreement is,
old patch 5 don't need re-do, it's OK to handle 'vmce occur before migration',
old patch 4 need update a little, it's used to handle 'vmce occur during migration', but need updated as 'not abort migration';

===============
BTW, this time I adjust the sequence of patch 4 and 5, since the new approach for 'vmce occur during migration' rely on some logic of 'vmce occur before migration'.

So latest patch 4 and 5 are:
patch 4 (same as old patch 5, no update): handle 'vmce occurred before migration';
patch 5 (updated old patch 4, according to George's suggestion): handle 'vmce occurs during migration' -- it updated a little for old patch 4 -- it didn't abort migration, instead it mark the broken page to dirty bitmap, so that at copypages stage of migration, the pfn_type and pfn number of broken page would transfer to target and then take appropriate action;

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 17:34:33 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 17:34:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TStE3-0007Jf-8x; Mon, 29 Oct 2012 17:34:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TStE1-0007JU-Ei
	for xen-devel@lists.xensource.com; Mon, 29 Oct 2012 17:34:09 +0000
Received: from [193.109.254.147:53296] by server-7.bemta-14.messagelabs.com id
	60/DA-24122-01EBE805; Mon, 29 Oct 2012 17:34:08 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1351532047!2018969!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzNTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3658 invoked from network); 29 Oct 2012 17:34:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Oct 2012 17:34:08 -0000
X-IronPort-AV: E=Sophos;i="4.80,673,1344211200"; d="scan'208";a="15472429"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Oct 2012 17:34:07 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Mon, 29 Oct 2012
	17:34:07 +0000
From: Thanos Makatos 
To: Ian Campbell 
Date: Mon, 29 Oct 2012 17:34:05 +0000
Thread-Topic: [Xen-devel] [PATCH 10 of 16 RFC] blktap3: Introduce the blktap
	header file
Thread-Index: Ac2zbiqVBEdv1dynR4SX/d1cSUCowwCjQODQ
Message-ID: <4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8C5C@LONPMAILBOX01.citrite.net>
References: 
	
	<1351251399.15162.53.camel@zakaz.uk.xensource.com>
In-Reply-To: <1351251399.15162.53.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 10 of 16 RFC] blktap3: Introduce the blktap
 header file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Ian Campbell
> Sent: 26 October 2012 12:37
> To: Thanos Makatos
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 10 of 16 RFC] blktap3: Introduce the
> blktap header file
> 
> > +/*
> > + * TODO Document what each define is.
> > + */
> > +#define BLKTAP3_SYSFS_DIR                   "/sys/class/blktap3"
> 
> I thought there was no kernel side to blktap3?
> 
> > +#define BLKTAP3_CONTROL_NAME                "blktap-control"
> > +#define BLKTAP3_CONTROL_DIR
> "/var/run/"BLKTAP3_CONTROL_NAME
> > +#define BLKTAP3_CONTROL_SOCKET              "ctl"
> 
> > +#define BLKTAP3_DIRECTORY                   "/dev/xen/blktap-3"
> > +#define BLKTAP3_RING_DEVICE
> BLKTAP3_DIRECTORY"/blktap"
> 
> Likewise these two.

Correct, I removed them.

> 
> > +#define BLKTAP3_IO_DEVICEBLKTAP3_DIRECTORY  "/tapdev"
> > +#define BLKTAP3_ENOSPC_SIGNAL_FILE          "/var/run/tapdisk3-
> enospc"
> > +
> > +/*
> > + * TODO Can these be supplied from somewhere else?
> > + */
> > +#define likely(_cond)   __builtin_expect(!!(_cond), 1)
> > +#define unlikely(_cond) __builtin_expect(!!(_cond), 0)
> > +
> > +/*
> > + * FIXME taken from list.h
> > + */
> > +#define containerof(_ptr, _type, _memb) \
> > +    ((_type*)((void*)(_ptr) - offsetof(_type, _memb)))
> > +
> > +/*
> > + * FIXME shouldn't these be supplied from somewhere?
> > + */
> > +#define __printf(a, b) __attribute__((format(printf, a, b))) #define
> > +__scanf(_f, _a) __attribute__((format (scanf, _f, _a)))
> 
> These are all abstractions of gcc-isms (presumably to ease ports to
> other compilers). We generally don't bother with this sort of thing in
> the tools, although you can if you like. You might want to put into a
> compiler.h and add suitable #if like those in
> xen/include/xen/compiler.h.

I'll put them in a compiler.h

> 
> > +
> > +#define TAILQ_MOVE_HEAD(node, src, dst, entry)  \
> > +    TAILQ_REMOVE(src, node, entry);             \
> > +    TAILQ_INSERT_HEAD(dst, node, entry);
> > +
> > +#define TAILQ_MOVE_TAIL(node, src, dst, entry)  \
> > +    TAILQ_REMOVE(src, node, entry);             \
> > +    TAILQ_INSERT_TAIL(dst, node, entry);
> > +
> > +/*
> > + * TODO This is defined in xen/lib.h, use that instead of redefining
> > +it
> > + * here.
> 
> xen/lib.h is a hypervisor internal header so isn't available to you
> here. I think it is fine to define your own (although it should be in a
> private header, not part of the libblktap API)

Right I'll put them in a private header.

> 
> > + */
> > +#ifndef ARRAY_SIZE
> > +#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0])) #endif /*
> > +ARRAY_SIZE */
> > +
> > +#endif /* __BLKTAP_3_H__ */
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 17:34:33 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 17:34:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TStE3-0007Jf-8x; Mon, 29 Oct 2012 17:34:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TStE1-0007JU-Ei
	for xen-devel@lists.xensource.com; Mon, 29 Oct 2012 17:34:09 +0000
Received: from [193.109.254.147:53296] by server-7.bemta-14.messagelabs.com id
	60/DA-24122-01EBE805; Mon, 29 Oct 2012 17:34:08 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1351532047!2018969!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzNTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3658 invoked from network); 29 Oct 2012 17:34:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Oct 2012 17:34:08 -0000
X-IronPort-AV: E=Sophos;i="4.80,673,1344211200"; d="scan'208";a="15472429"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Oct 2012 17:34:07 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Mon, 29 Oct 2012
	17:34:07 +0000
From: Thanos Makatos 
To: Ian Campbell 
Date: Mon, 29 Oct 2012 17:34:05 +0000
Thread-Topic: [Xen-devel] [PATCH 10 of 16 RFC] blktap3: Introduce the blktap
	header file
Thread-Index: Ac2zbiqVBEdv1dynR4SX/d1cSUCowwCjQODQ
Message-ID: <4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8C5C@LONPMAILBOX01.citrite.net>
References: 
	
	<1351251399.15162.53.camel@zakaz.uk.xensource.com>
In-Reply-To: <1351251399.15162.53.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 10 of 16 RFC] blktap3: Introduce the blktap
 header file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Ian Campbell
> Sent: 26 October 2012 12:37
> To: Thanos Makatos
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 10 of 16 RFC] blktap3: Introduce the
> blktap header file
> 
> > +/*
> > + * TODO Document what each define is.
> > + */
> > +#define BLKTAP3_SYSFS_DIR                   "/sys/class/blktap3"
> 
> I thought there was no kernel side to blktap3?
> 
> > +#define BLKTAP3_CONTROL_NAME                "blktap-control"
> > +#define BLKTAP3_CONTROL_DIR
> "/var/run/"BLKTAP3_CONTROL_NAME
> > +#define BLKTAP3_CONTROL_SOCKET              "ctl"
> 
> > +#define BLKTAP3_DIRECTORY                   "/dev/xen/blktap-3"
> > +#define BLKTAP3_RING_DEVICE
> BLKTAP3_DIRECTORY"/blktap"
> 
> Likewise these two.

Correct, I removed them.

> 
> > +#define BLKTAP3_IO_DEVICEBLKTAP3_DIRECTORY  "/tapdev"
> > +#define BLKTAP3_ENOSPC_SIGNAL_FILE          "/var/run/tapdisk3-
> enospc"
> > +
> > +/*
> > + * TODO Can these be supplied from somewhere else?
> > + */
> > +#define likely(_cond)   __builtin_expect(!!(_cond), 1)
> > +#define unlikely(_cond) __builtin_expect(!!(_cond), 0)
> > +
> > +/*
> > + * FIXME taken from list.h
> > + */
> > +#define containerof(_ptr, _type, _memb) \
> > +    ((_type*)((void*)(_ptr) - offsetof(_type, _memb)))
> > +
> > +/*
> > + * FIXME shouldn't these be supplied from somewhere?
> > + */
> > +#define __printf(a, b) __attribute__((format(printf, a, b))) #define
> > +__scanf(_f, _a) __attribute__((format (scanf, _f, _a)))
> 
> These are all abstractions of gcc-isms (presumably to ease ports to
> other compilers). We generally don't bother with this sort of thing in
> the tools, although you can if you like. You might want to put into a
> compiler.h and add suitable #if like those in
> xen/include/xen/compiler.h.

I'll put them in a compiler.h

> 
> > +
> > +#define TAILQ_MOVE_HEAD(node, src, dst, entry)  \
> > +    TAILQ_REMOVE(src, node, entry);             \
> > +    TAILQ_INSERT_HEAD(dst, node, entry);
> > +
> > +#define TAILQ_MOVE_TAIL(node, src, dst, entry)  \
> > +    TAILQ_REMOVE(src, node, entry);             \
> > +    TAILQ_INSERT_TAIL(dst, node, entry);
> > +
> > +/*
> > + * TODO This is defined in xen/lib.h, use that instead of redefining
> > +it
> > + * here.
> 
> xen/lib.h is a hypervisor internal header so isn't available to you
> here. I think it is fine to define your own (although it should be in a
> private header, not part of the libblktap API)

Right I'll put them in a private header.

> 
> > + */
> > +#ifndef ARRAY_SIZE
> > +#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0])) #endif /*
> > +ARRAY_SIZE */
> > +
> > +#endif /* __BLKTAP_3_H__ */
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 17:35:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 17:35:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TStFV-0007QC-T9; Mon, 29 Oct 2012 17:35:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TStFU-0007Q1-H2
	for xen-devel@lists.xensource.com; Mon, 29 Oct 2012 17:35:40 +0000
Received: from [85.158.143.35:54504] by server-1.bemta-4.messagelabs.com id
	A3/96-19134-B6EBE805; Mon, 29 Oct 2012 17:35:39 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1351532136!4477611!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzNTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22189 invoked from network); 29 Oct 2012 17:35:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Oct 2012 17:35:37 -0000
X-IronPort-AV: E=Sophos;i="4.80,673,1344211200"; d="scan'208";a="15472467"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Oct 2012 17:35:36 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Mon, 29 Oct 2012
	17:35:36 +0000
From: Thanos Makatos 
To: Ian Campbell 
Date: Mon, 29 Oct 2012 17:35:35 +0000
Thread-Topic: [Xen-devel] [PATCH 01 of 16 RFC] blktap3: Introduce the
	blktap3 device type
Thread-Index: Ac2za3BqMJ6dDcmBSvKsOJYtWqhF/gCkDaKg
Message-ID: <4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8C5D@LONPMAILBOX01.citrite.net>
References: 
	
	<1351250227.15162.36.camel@zakaz.uk.xensource.com>
In-Reply-To: <1351250227.15162.36.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 01 of 16 RFC] blktap3: Introduce the blktap3
 device type
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Ian Campbell
> Sent: 26 October 2012 12:17
> To: Thanos Makatos
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 01 of 16 RFC] blktap3: Introduce the
> blktap3 device type
> 
> On Wed, 2012-10-24 at 18:02 +0100, Thanos Makatos wrote:
> > This device is used when tap is specifed as the disk backend, instead
> of vbd.
> >
> > diff -r 3cd5bf62ded7 -r fef81de66bf7 tools/libxl/libxl.c
> > --- a/tools/libxl/libxl.c	Wed Oct 24 17:22:39 2012 +0100
> > +++ b/tools/libxl/libxl.c	Wed Oct 24 17:24:01 2012 +0100
> > @@ -1742,7 +1742,7 @@ int libxl__device_from_disk(libxl__gc *g
> >              device->backend_kind = LIBXL__DEVICE_KIND_VBD;
> >              break;
> >          case LIBXL_DISK_BACKEND_TAP:
> > -            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
> > +            device->backend_kind = LIBXL__DEVICE_KIND_XENIO;
> 
> Presumably as well as this change a bunch of related infrastructure
> changes are needed? I'd suggest putting all those first and making this
> switch at the end, so that xl remains functional at each point in the
> series.

Ok these changes will be part of the final "switch to blktap3" patch.

> 
> >              break;
> >          case LIBXL_DISK_BACKEND_QDISK:
> >              device->backend_kind = LIBXL__DEVICE_KIND_QDISK; diff -r
> > 3cd5bf62ded7 -r fef81de66bf7 tools/libxl/libxl_types_internal.idl
> > --- a/tools/libxl/libxl_types_internal.idl	Wed Oct 24 17:22:39
> 2012 +0100
> > +++ b/tools/libxl/libxl_types_internal.idl	Wed Oct 24 17:24:01
> 2012 +0100
> > @@ -19,6 +19,7 @@ libxl__device_kind = Enumeration("device
> >      (5, "VFB"),
> >      (6, "VKBD"),
> >      (7, "CONSOLE"),
> > +    (8, "XENIO"),
> 
> I know this is what it is called internally but for libxl purposes can
> we use BLKTAP or something descriptive like that?

Sure.

> 
> >      ])
> >
> >  libxl__console_backend = Enumeration("console_backend", [
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 17:35:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 17:35:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TStFV-0007QC-T9; Mon, 29 Oct 2012 17:35:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TStFU-0007Q1-H2
	for xen-devel@lists.xensource.com; Mon, 29 Oct 2012 17:35:40 +0000
Received: from [85.158.143.35:54504] by server-1.bemta-4.messagelabs.com id
	A3/96-19134-B6EBE805; Mon, 29 Oct 2012 17:35:39 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1351532136!4477611!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzNTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22189 invoked from network); 29 Oct 2012 17:35:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Oct 2012 17:35:37 -0000
X-IronPort-AV: E=Sophos;i="4.80,673,1344211200"; d="scan'208";a="15472467"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Oct 2012 17:35:36 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Mon, 29 Oct 2012
	17:35:36 +0000
From: Thanos Makatos 
To: Ian Campbell 
Date: Mon, 29 Oct 2012 17:35:35 +0000
Thread-Topic: [Xen-devel] [PATCH 01 of 16 RFC] blktap3: Introduce the
	blktap3 device type
Thread-Index: Ac2za3BqMJ6dDcmBSvKsOJYtWqhF/gCkDaKg
Message-ID: <4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8C5D@LONPMAILBOX01.citrite.net>
References: 
	
	<1351250227.15162.36.camel@zakaz.uk.xensource.com>
In-Reply-To: <1351250227.15162.36.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 01 of 16 RFC] blktap3: Introduce the blktap3
 device type
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Ian Campbell
> Sent: 26 October 2012 12:17
> To: Thanos Makatos
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 01 of 16 RFC] blktap3: Introduce the
> blktap3 device type
> 
> On Wed, 2012-10-24 at 18:02 +0100, Thanos Makatos wrote:
> > This device is used when tap is specifed as the disk backend, instead
> of vbd.
> >
> > diff -r 3cd5bf62ded7 -r fef81de66bf7 tools/libxl/libxl.c
> > --- a/tools/libxl/libxl.c	Wed Oct 24 17:22:39 2012 +0100
> > +++ b/tools/libxl/libxl.c	Wed Oct 24 17:24:01 2012 +0100
> > @@ -1742,7 +1742,7 @@ int libxl__device_from_disk(libxl__gc *g
> >              device->backend_kind = LIBXL__DEVICE_KIND_VBD;
> >              break;
> >          case LIBXL_DISK_BACKEND_TAP:
> > -            device->backend_kind = LIBXL__DEVICE_KIND_VBD;
> > +            device->backend_kind = LIBXL__DEVICE_KIND_XENIO;
> 
> Presumably as well as this change a bunch of related infrastructure
> changes are needed? I'd suggest putting all those first and making this
> switch at the end, so that xl remains functional at each point in the
> series.

Ok these changes will be part of the final "switch to blktap3" patch.

> 
> >              break;
> >          case LIBXL_DISK_BACKEND_QDISK:
> >              device->backend_kind = LIBXL__DEVICE_KIND_QDISK; diff -r
> > 3cd5bf62ded7 -r fef81de66bf7 tools/libxl/libxl_types_internal.idl
> > --- a/tools/libxl/libxl_types_internal.idl	Wed Oct 24 17:22:39
> 2012 +0100
> > +++ b/tools/libxl/libxl_types_internal.idl	Wed Oct 24 17:24:01
> 2012 +0100
> > @@ -19,6 +19,7 @@ libxl__device_kind = Enumeration("device
> >      (5, "VFB"),
> >      (6, "VKBD"),
> >      (7, "CONSOLE"),
> > +    (8, "XENIO"),
> 
> I know this is what it is called internally but for libxl purposes can
> we use BLKTAP or something descriptive like that?

Sure.

> 
> >      ])
> >
> >  libxl__console_backend = Enumeration("console_backend", [
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 17:42:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 17:42:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TStLb-0007fR-NV; Mon, 29 Oct 2012 17:41:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TStLa-0007fK-5K
	for xen-devel@lists.xensource.com; Mon, 29 Oct 2012 17:41:58 +0000
Received: from [193.109.254.147:30400] by server-3.bemta-14.messagelabs.com id
	F6/FE-04486-5EFBE805; Mon, 29 Oct 2012 17:41:57 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1351532515!6215367!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzNTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28361 invoked from network); 29 Oct 2012 17:41:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Oct 2012 17:41:56 -0000
X-IronPort-AV: E=Sophos;i="4.80,673,1344211200"; d="scan'208";a="15472617"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Oct 2012 17:41:54 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Mon, 29 Oct 2012
	17:41:54 +0000
From: Thanos Makatos 
To: Ian Campbell 
Date: Mon, 29 Oct 2012 17:41:52 +0000
Thread-Topic: [Xen-devel] [PATCH 04 of 16 RFC] blktap3: change
	libxl__blktap_devpath prototype to return an error code
Thread-Index: Ac2zbBMAVb3rXHSOSESjgnXLrvXr7ACkCuPg
Message-ID: <4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8C60@LONPMAILBOX01.citrite.net>
References: 
	
	<1351250500.15162.40.camel@zakaz.uk.xensource.com>
In-Reply-To: <1351250500.15162.40.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 04 of 16 RFC] blktap3: change
 libxl__blktap_devpath prototype to return an error code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Ian Campbell
> Sent: 26 October 2012 12:22
> To: Thanos Makatos
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 04 of 16 RFC] blktap3: change
> libxl__blktap_devpath prototype to return an error code
> 
> On Wed, 2012-10-24 at 18:02 +0100, Thanos Makatos wrote:
> > Make libxl__blktap_devpath return an error code instead of the
> device,
> > since there is no device in dom0 any more.
> 
> Does this function eventually go away then? Or will it eventually
> return some sort of metadata which can be used to connect to the
> created tap device?

As in blktap2, it creates the tapdisk process, but doesn't return any metadata, so it's still required. I guess changing the name of the function would clarify it.

> 
> >  Amend the libxl code that uses this functions accordingly.
> >
> > diff -r 80e0bc67dcda -r bcb5a6182868 tools/libxl/libxl.c
> > --- a/tools/libxl/libxl.c	Wed Oct 24 17:24:53 2012 +0100
> > +++ b/tools/libxl/libxl.c	Wed Oct 24 17:25:02 2012 +0100
> > @@ -1844,13 +1844,14 @@ static void device_disk_add(libxl__egc *
> >                  break;
> >
> >              case LIBXL_DISK_BACKEND_TAP:
> > -                dev = libxl__blktap_devpath(gc, disk->pdev_path,
> disk->format);
> > -                if (!dev) {
> > -                    LOG(ERROR, "failed to get blktap devpath for
> %p\n",
> > -                        disk->pdev_path);
> > +                rc = libxl__blktap_devpath(gc, disk->pdev_path,
> disk->format);
> > +                if (rc) {
> > +                    LOG(ERROR, "failed to get blktap devpath for %s:
> %s\n",
> > +                        disk->pdev_path, strerror(rc));
> >                      rc = ERROR_FAIL;
> >                      goto out;
> >                  }
> > +                dev = NULL;
> >                  flexarray_append(back, "tapdisk-params");
> >                  flexarray_append(back, libxl__sprintf(gc, "%s:%s",
> >
> > libxl__device_disk_string_of_format(disk->format),
> > @@ -2277,8 +2278,13 @@ void libxl__device_disk_local_initiate_a
> >                  dev = disk->pdev_path;
> >                  break;
> >              case LIBXL_DISK_FORMAT_VHD:
> > -                dev = libxl__blktap_devpath(gc, disk->pdev_path,
> > -                                            disk->format);
> > +                rc = libxl__blktap_devpath(gc, disk->pdev_path,
> disk->format);
> > +                if (!rc) {
> > +                    LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> > +                           "error getting tapdisk: %s",
> strerror(rc));
> > +                    rc = ERROR_FAIL;
> > +                    goto out;
> > +                }
> >                  break;
> >              case LIBXL_DISK_FORMAT_QCOW:
> >              case LIBXL_DISK_FORMAT_QCOW2:
> > diff -r 80e0bc67dcda -r bcb5a6182868 tools/libxl/libxl_blktap3.c
> > --- a/tools/libxl/libxl_blktap3.c	Wed Oct 24 17:24:53 2012 +0100
> > +++ b/tools/libxl/libxl_blktap3.c	Wed Oct 24 17:25:02 2012 +0100
> > @@ -5,9 +5,9 @@ int libxl__blktap_enabled(libxl__gc *gc)
> >      return 1;
> >  }
> >
> > -char *libxl__blktap_devpath(libxl__gc *gc, const char *disk,
> > +int libxl__blktap_devpath(libxl__gc *gc, const char *disk,
> >      libxl_disk_format format) {
> > -    return NULL;
> > +    return -ENOSYS;
> >  }
> >
> >  int libxl__device_destroy_tapdisk(libxl__gc *gc, const char
> *be_path)
> > { diff -r 80e0bc67dcda -r bcb5a6182868 tools/libxl/libxl_internal.h
> > --- a/tools/libxl/libxl_internal.h	Wed Oct 24 17:24:53 2012
> +0100
> > +++ b/tools/libxl/libxl_internal.h	Wed Oct 24 17:25:02 2012
> +0100
> > @@ -1344,10 +1344,9 @@ struct libxl__cpuid_policy {
> >  /* libxl__blktap_devpath:
> >   *    Argument: path and disk image as specified in config file.
> >   *      The type specifies whether this is aio, qcow, qcow2, etc.
> > - *    returns device path xenstore wants to have. returns NULL
> > - *      if no device corresponds to the disk.
> > + *    returns 0 on success, an error code otherwise
> >   */
> > -_hidden char *libxl__blktap_devpath(libxl__gc *gc,
> > +_hidden int libxl__blktap_devpath(libxl__gc *gc,
> >                                      const char *disk,
> >                                      libxl_disk_format format);
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 17:42:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 17:42:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TStLb-0007fR-NV; Mon, 29 Oct 2012 17:41:59 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TStLa-0007fK-5K
	for xen-devel@lists.xensource.com; Mon, 29 Oct 2012 17:41:58 +0000
Received: from [193.109.254.147:30400] by server-3.bemta-14.messagelabs.com id
	F6/FE-04486-5EFBE805; Mon, 29 Oct 2012 17:41:57 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1351532515!6215367!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzNTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28361 invoked from network); 29 Oct 2012 17:41:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Oct 2012 17:41:56 -0000
X-IronPort-AV: E=Sophos;i="4.80,673,1344211200"; d="scan'208";a="15472617"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Oct 2012 17:41:54 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Mon, 29 Oct 2012
	17:41:54 +0000
From: Thanos Makatos 
To: Ian Campbell 
Date: Mon, 29 Oct 2012 17:41:52 +0000
Thread-Topic: [Xen-devel] [PATCH 04 of 16 RFC] blktap3: change
	libxl__blktap_devpath prototype to return an error code
Thread-Index: Ac2zbBMAVb3rXHSOSESjgnXLrvXr7ACkCuPg
Message-ID: <4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8C60@LONPMAILBOX01.citrite.net>
References: 
	
	<1351250500.15162.40.camel@zakaz.uk.xensource.com>
In-Reply-To: <1351250500.15162.40.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 04 of 16 RFC] blktap3: change
 libxl__blktap_devpath prototype to return an error code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Ian Campbell
> Sent: 26 October 2012 12:22
> To: Thanos Makatos
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 04 of 16 RFC] blktap3: change
> libxl__blktap_devpath prototype to return an error code
> 
> On Wed, 2012-10-24 at 18:02 +0100, Thanos Makatos wrote:
> > Make libxl__blktap_devpath return an error code instead of the
> device,
> > since there is no device in dom0 any more.
> 
> Does this function eventually go away then? Or will it eventually
> return some sort of metadata which can be used to connect to the
> created tap device?

As in blktap2, it creates the tapdisk process, but doesn't return any metadata, so it's still required. I guess changing the name of the function would clarify it.

> 
> >  Amend the libxl code that uses this functions accordingly.
> >
> > diff -r 80e0bc67dcda -r bcb5a6182868 tools/libxl/libxl.c
> > --- a/tools/libxl/libxl.c	Wed Oct 24 17:24:53 2012 +0100
> > +++ b/tools/libxl/libxl.c	Wed Oct 24 17:25:02 2012 +0100
> > @@ -1844,13 +1844,14 @@ static void device_disk_add(libxl__egc *
> >                  break;
> >
> >              case LIBXL_DISK_BACKEND_TAP:
> > -                dev = libxl__blktap_devpath(gc, disk->pdev_path,
> disk->format);
> > -                if (!dev) {
> > -                    LOG(ERROR, "failed to get blktap devpath for
> %p\n",
> > -                        disk->pdev_path);
> > +                rc = libxl__blktap_devpath(gc, disk->pdev_path,
> disk->format);
> > +                if (rc) {
> > +                    LOG(ERROR, "failed to get blktap devpath for %s:
> %s\n",
> > +                        disk->pdev_path, strerror(rc));
> >                      rc = ERROR_FAIL;
> >                      goto out;
> >                  }
> > +                dev = NULL;
> >                  flexarray_append(back, "tapdisk-params");
> >                  flexarray_append(back, libxl__sprintf(gc, "%s:%s",
> >
> > libxl__device_disk_string_of_format(disk->format),
> > @@ -2277,8 +2278,13 @@ void libxl__device_disk_local_initiate_a
> >                  dev = disk->pdev_path;
> >                  break;
> >              case LIBXL_DISK_FORMAT_VHD:
> > -                dev = libxl__blktap_devpath(gc, disk->pdev_path,
> > -                                            disk->format);
> > +                rc = libxl__blktap_devpath(gc, disk->pdev_path,
> disk->format);
> > +                if (!rc) {
> > +                    LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> > +                           "error getting tapdisk: %s",
> strerror(rc));
> > +                    rc = ERROR_FAIL;
> > +                    goto out;
> > +                }
> >                  break;
> >              case LIBXL_DISK_FORMAT_QCOW:
> >              case LIBXL_DISK_FORMAT_QCOW2:
> > diff -r 80e0bc67dcda -r bcb5a6182868 tools/libxl/libxl_blktap3.c
> > --- a/tools/libxl/libxl_blktap3.c	Wed Oct 24 17:24:53 2012 +0100
> > +++ b/tools/libxl/libxl_blktap3.c	Wed Oct 24 17:25:02 2012 +0100
> > @@ -5,9 +5,9 @@ int libxl__blktap_enabled(libxl__gc *gc)
> >      return 1;
> >  }
> >
> > -char *libxl__blktap_devpath(libxl__gc *gc, const char *disk,
> > +int libxl__blktap_devpath(libxl__gc *gc, const char *disk,
> >      libxl_disk_format format) {
> > -    return NULL;
> > +    return -ENOSYS;
> >  }
> >
> >  int libxl__device_destroy_tapdisk(libxl__gc *gc, const char
> *be_path)
> > { diff -r 80e0bc67dcda -r bcb5a6182868 tools/libxl/libxl_internal.h
> > --- a/tools/libxl/libxl_internal.h	Wed Oct 24 17:24:53 2012
> +0100
> > +++ b/tools/libxl/libxl_internal.h	Wed Oct 24 17:25:02 2012
> +0100
> > @@ -1344,10 +1344,9 @@ struct libxl__cpuid_policy {
> >  /* libxl__blktap_devpath:
> >   *    Argument: path and disk image as specified in config file.
> >   *      The type specifies whether this is aio, qcow, qcow2, etc.
> > - *    returns device path xenstore wants to have. returns NULL
> > - *      if no device corresponds to the disk.
> > + *    returns 0 on success, an error code otherwise
> >   */
> > -_hidden char *libxl__blktap_devpath(libxl__gc *gc,
> > +_hidden int libxl__blktap_devpath(libxl__gc *gc,
> >                                      const char *disk,
> >                                      libxl_disk_format format);
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 17:44:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 17:44:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TStOH-0007kw-AW; Mon, 29 Oct 2012 17:44:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TStOF-0007kp-I6
	for xen-devel@lists.xensource.com; Mon, 29 Oct 2012 17:44:43 +0000
Received: from [85.158.143.99:42045] by server-1.bemta-4.messagelabs.com id
	A6/4D-19134-A80CE805; Mon, 29 Oct 2012 17:44:42 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1351532682!27846030!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzNTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14947 invoked from network); 29 Oct 2012 17:44:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Oct 2012 17:44:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,673,1344211200"; d="scan'208";a="15472705"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Oct 2012 17:43:57 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Mon, 29 Oct 2012
	17:43:57 +0000
From: Thanos Makatos 
To: Ian Campbell 
Date: Mon, 29 Oct 2012 17:43:56 +0000
Thread-Topic: [Xen-devel] [PATCH 05 of 16 RFC] blktap3: Don't check if
	blktap is available
Thread-Index: Ac2zbF15b3B1KIhwRdyyZ/bxbTa+mwCkF2wA
Message-ID: <4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8C61@LONPMAILBOX01.citrite.net>
References: 
	<57896068356d4870c74a.1351098144@makatos-desktop>
	<1351250625.15162.42.camel@zakaz.uk.xensource.com>
In-Reply-To: <1351250625.15162.42.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 05 of 16 RFC] blktap3: Don't check if blktap
 is available
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Ian Campbell
> Sent: 26 October 2012 12:24
> To: Thanos Makatos
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 05 of 16 RFC] blktap3: Don't check if
> blktap is available
> 
> On Wed, 2012-10-24 at 18:02 +0100, Thanos Makatos wrote:
> > Don't check if blktap is enabled since it will always be enabled (no
> > blktap/blkback requirement anymore).
> 
> I think this needs to stay until the *BSD dom0's implement the
> necessary kernel drivers (gnttab/gntalloc etc) such that blktap3 can
> run on them.
> Currently we use libxl_noblktap2.c on those platforms and I think until
> then we need to retain a libxl_noblktap3.c for use there.

Ok.

> 
> Perhaps even on Linux we would want a sanity check that the drivers are
> present and loaded etc?

We could ensure that the tapdisk binaries are present, apart from that I don't see anything else we could check.

> 
> >
> > diff -r bcb5a6182868 -r 57896068356d tools/libxl/libxl_blktap3.c
> > --- a/tools/libxl/libxl_blktap3.c	Wed Oct 24 17:25:02 2012 +0100
> > +++ b/tools/libxl/libxl_blktap3.c	Wed Oct 24 17:25:12 2012 +0100
> > @@ -1,10 +1,6 @@
> >  #include "libxl_osdeps.h"
> >  #include "libxl_internal.h"
> >
> > -int libxl__blktap_enabled(libxl__gc *gc) {
> > -    return 1;
> > -}
> > -
> >  int libxl__blktap_devpath(libxl__gc *gc, const char *disk,
> >      libxl_disk_format format) {
> >      return -ENOSYS;
> > diff -r bcb5a6182868 -r 57896068356d tools/libxl/libxl_device.c
> > --- a/tools/libxl/libxl_device.c	Wed Oct 24 17:25:02 2012 +0100
> > +++ b/tools/libxl/libxl_device.c	Wed Oct 24 17:25:12 2012 +0100
> > @@ -177,13 +177,6 @@ static int disk_try_backend(disk_try_bac
> >
> >      case LIBXL_DISK_BACKEND_TAP:
> >          if (a->disk->script) goto bad_script;
> > -
> > -        if (!libxl__blktap_enabled(a->gc)) {
> > -            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, backend
> tap"
> > -                       " unsuitable because blktap not available",
> > -                       a->disk->vdev);
> > -            return 0;
> > -        }
> >          if (!(a->disk->format == LIBXL_DISK_FORMAT_RAW ||
> >                a->disk->format == LIBXL_DISK_FORMAT_VHD)) {
> >              goto bad_format;
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 17:44:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 17:44:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TStOH-0007kw-AW; Mon, 29 Oct 2012 17:44:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TStOF-0007kp-I6
	for xen-devel@lists.xensource.com; Mon, 29 Oct 2012 17:44:43 +0000
Received: from [85.158.143.99:42045] by server-1.bemta-4.messagelabs.com id
	A6/4D-19134-A80CE805; Mon, 29 Oct 2012 17:44:42 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1351532682!27846030!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzNTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14947 invoked from network); 29 Oct 2012 17:44:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Oct 2012 17:44:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,673,1344211200"; d="scan'208";a="15472705"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Oct 2012 17:43:57 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Mon, 29 Oct 2012
	17:43:57 +0000
From: Thanos Makatos 
To: Ian Campbell 
Date: Mon, 29 Oct 2012 17:43:56 +0000
Thread-Topic: [Xen-devel] [PATCH 05 of 16 RFC] blktap3: Don't check if
	blktap is available
Thread-Index: Ac2zbF15b3B1KIhwRdyyZ/bxbTa+mwCkF2wA
Message-ID: <4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8C61@LONPMAILBOX01.citrite.net>
References: 
	<57896068356d4870c74a.1351098144@makatos-desktop>
	<1351250625.15162.42.camel@zakaz.uk.xensource.com>
In-Reply-To: <1351250625.15162.42.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 05 of 16 RFC] blktap3: Don't check if blktap
 is available
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Ian Campbell
> Sent: 26 October 2012 12:24
> To: Thanos Makatos
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 05 of 16 RFC] blktap3: Don't check if
> blktap is available
> 
> On Wed, 2012-10-24 at 18:02 +0100, Thanos Makatos wrote:
> > Don't check if blktap is enabled since it will always be enabled (no
> > blktap/blkback requirement anymore).
> 
> I think this needs to stay until the *BSD dom0's implement the
> necessary kernel drivers (gnttab/gntalloc etc) such that blktap3 can
> run on them.
> Currently we use libxl_noblktap2.c on those platforms and I think until
> then we need to retain a libxl_noblktap3.c for use there.

Ok.

> 
> Perhaps even on Linux we would want a sanity check that the drivers are
> present and loaded etc?

We could ensure that the tapdisk binaries are present, apart from that I don't see anything else we could check.

> 
> >
> > diff -r bcb5a6182868 -r 57896068356d tools/libxl/libxl_blktap3.c
> > --- a/tools/libxl/libxl_blktap3.c	Wed Oct 24 17:25:02 2012 +0100
> > +++ b/tools/libxl/libxl_blktap3.c	Wed Oct 24 17:25:12 2012 +0100
> > @@ -1,10 +1,6 @@
> >  #include "libxl_osdeps.h"
> >  #include "libxl_internal.h"
> >
> > -int libxl__blktap_enabled(libxl__gc *gc) {
> > -    return 1;
> > -}
> > -
> >  int libxl__blktap_devpath(libxl__gc *gc, const char *disk,
> >      libxl_disk_format format) {
> >      return -ENOSYS;
> > diff -r bcb5a6182868 -r 57896068356d tools/libxl/libxl_device.c
> > --- a/tools/libxl/libxl_device.c	Wed Oct 24 17:25:02 2012 +0100
> > +++ b/tools/libxl/libxl_device.c	Wed Oct 24 17:25:12 2012 +0100
> > @@ -177,13 +177,6 @@ static int disk_try_backend(disk_try_bac
> >
> >      case LIBXL_DISK_BACKEND_TAP:
> >          if (a->disk->script) goto bad_script;
> > -
> > -        if (!libxl__blktap_enabled(a->gc)) {
> > -            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, backend
> tap"
> > -                       " unsuitable because blktap not available",
> > -                       a->disk->vdev);
> > -            return 0;
> > -        }
> >          if (!(a->disk->format == LIBXL_DISK_FORMAT_RAW ||
> >                a->disk->format == LIBXL_DISK_FORMAT_VHD)) {
> >              goto bad_format;
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 17:48:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 17:48:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TStRE-0007tb-UY; Mon, 29 Oct 2012 17:47:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TStRE-0007tQ-9V
	for xen-devel@lists.xensource.com; Mon, 29 Oct 2012 17:47:48 +0000
Received: from [85.158.143.35:30705] by server-1.bemta-4.messagelabs.com id
	9B/7F-19134-341CE805; Mon, 29 Oct 2012 17:47:47 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1351532866!13006635!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzNTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9101 invoked from network); 29 Oct 2012 17:47:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Oct 2012 17:47:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,673,1344211200"; d="scan'208";a="15472780"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Oct 2012 17:47:46 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Mon, 29 Oct 2012
	17:47:46 +0000
From: Thanos Makatos 
To: Ian Campbell 
Date: Mon, 29 Oct 2012 17:47:45 +0000
Thread-Topic: [Xen-devel] [PATCH 08 of 16 RFC] blktap3: Introduce message
	types and structures
Thread-Index: Ac2zbOqaT2ov97mCTcqk6hOUGqmZdgCkBdGQ
Message-ID: <4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8C62@LONPMAILBOX01.citrite.net>
References: 
	<23e2537c7257e0e5b00e.1351098147@makatos-desktop>
	<1351250861.15162.46.camel@zakaz.uk.xensource.com>
In-Reply-To: <1351250861.15162.46.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 08 of 16 RFC] blktap3: Introduce message
 types and structures
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Ian Campbell
> Sent: 26 October 2012 12:28
> To: Thanos Makatos
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 08 of 16 RFC] blktap3: Introduce
> message types and structures
> 
> On Wed, 2012-10-24 at 18:02 +0100, Thanos Makatos wrote:
> > The main difference over the the XEN version
> 
> what do you mean by "the XEN version"? Is there an existing version of
> this header somewhere?

I mean the blktap2 living in XEN, as opposed to the forked blktap2 living in github.

> 
> >  is the addition of the stats
> > structure (used for retrieving stats from a running tapdisk), and the
> > addition of the tapdisk_message_blkif struct, which is required for
> > the user-space counterpart of blktap/blkback to communicate with
> tapdisk.
> 
> Am I correct that the interface defined here is one which is private
> between the tapdisk processes and the supplied control tools,
> abstracted away via libblktapctl?

Yes, so this header should be private.

> 
> > +/**
> > + * Retrieves the human-readable representation of the type of the
> message.
> > + */
> > +static inline char *tapdisk_message_name(enum tapdisk_message_id id)
> > +{
> > +    switch (id) {
> 
> Would a static lookup table be nicer?

Definitely.

> 
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 17:48:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 17:48:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TStRE-0007tb-UY; Mon, 29 Oct 2012 17:47:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TStRE-0007tQ-9V
	for xen-devel@lists.xensource.com; Mon, 29 Oct 2012 17:47:48 +0000
Received: from [85.158.143.35:30705] by server-1.bemta-4.messagelabs.com id
	9B/7F-19134-341CE805; Mon, 29 Oct 2012 17:47:47 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1351532866!13006635!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzNTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9101 invoked from network); 29 Oct 2012 17:47:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Oct 2012 17:47:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,673,1344211200"; d="scan'208";a="15472780"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Oct 2012 17:47:46 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Mon, 29 Oct 2012
	17:47:46 +0000
From: Thanos Makatos 
To: Ian Campbell 
Date: Mon, 29 Oct 2012 17:47:45 +0000
Thread-Topic: [Xen-devel] [PATCH 08 of 16 RFC] blktap3: Introduce message
	types and structures
Thread-Index: Ac2zbOqaT2ov97mCTcqk6hOUGqmZdgCkBdGQ
Message-ID: <4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8C62@LONPMAILBOX01.citrite.net>
References: 
	<23e2537c7257e0e5b00e.1351098147@makatos-desktop>
	<1351250861.15162.46.camel@zakaz.uk.xensource.com>
In-Reply-To: <1351250861.15162.46.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 08 of 16 RFC] blktap3: Introduce message
 types and structures
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Ian Campbell
> Sent: 26 October 2012 12:28
> To: Thanos Makatos
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 08 of 16 RFC] blktap3: Introduce
> message types and structures
> 
> On Wed, 2012-10-24 at 18:02 +0100, Thanos Makatos wrote:
> > The main difference over the the XEN version
> 
> what do you mean by "the XEN version"? Is there an existing version of
> this header somewhere?

I mean the blktap2 living in XEN, as opposed to the forked blktap2 living in github.

> 
> >  is the addition of the stats
> > structure (used for retrieving stats from a running tapdisk), and the
> > addition of the tapdisk_message_blkif struct, which is required for
> > the user-space counterpart of blktap/blkback to communicate with
> tapdisk.
> 
> Am I correct that the interface defined here is one which is private
> between the tapdisk processes and the supplied control tools,
> abstracted away via libblktapctl?

Yes, so this header should be private.

> 
> > +/**
> > + * Retrieves the human-readable representation of the type of the
> message.
> > + */
> > +static inline char *tapdisk_message_name(enum tapdisk_message_id id)
> > +{
> > +    switch (id) {
> 
> Would a static lookup table be nicer?

Definitely.

> 
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 19:01:20 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 19:01:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSuZx-0008VF-OO; Mon, 29 Oct 2012 19:00:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSuZw-0008VA-Eq
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 19:00:52 +0000
Received: from [85.158.143.99:54863] by server-1.bemta-4.messagelabs.com id
	A8/6D-19134-362DE805; Mon, 29 Oct 2012 19:00:51 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1351537249!22516328!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNDQxNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10502 invoked from network); 29 Oct 2012 19:00:51 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Oct 2012 19:00:51 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9TJ0cFK028738
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 29 Oct 2012 19:00:39 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9TJ0cGC009086
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 29 Oct 2012 19:00:38 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9TJ0b1Q002869; Mon, 29 Oct 2012 14:00:37 -0500
Received: from localhost.localdomain (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 29 Oct 2012 12:00:37 -0700
Date: Mon, 29 Oct 2012 15:00:30 -0400
From: Konrad Rzeszutek Wilk 
To: Greg KH 
Message-ID: <20121029190030.GA2551@localhost.localdomain>
References: <508EC0D202000078000A536A@nat28.tlf.novell.com>
	<20121029165047.GA22984@kroah.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20121029165047.GA22984@kroah.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Stefano Stabellini ,
	linux-usb@vger.kernel.org, xen-devel ,
	Randy Dunlap , stern@rowland.harvard.edu,
	Jan Beulich 
Subject: Re: [Xen-devel] [PATCH,
 v2] fix build with XEN and EARLY_PRINTK_DBGP enabled but
 USB_SUPPORT disabled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 29, 2012 at 09:50:47AM -0700, Greg KH wrote:
> On Mon, Oct 29, 2012 at 04:45:54PM +0000, Jan Beulich wrote:
> > Since there's no possible caller of dbgp_external_startup() and
> > dbgp_reset_prep() when !USB_EHCI_HCD, there's no point in building and
> > exporting these functions in that case. This eliminates a build error
> > under the conditions listed in the subject, introduced with the merge
> > f1c6872e4980bc4078cfaead05f892b3d78dea64.
> 
> That's a merge commit, is that where the problem happened because Linus
> did the merge resolution incorrectly, or is it really due to some other

No. He did it based on what we (Stefano and me) thought was the correct
way that address the ARM and generic patches merge.

While it did work - Randy found via his random config generator
cronjob that it did not address all of the EHCI/EARLY/USB/PCI
combinations.

> patch that added this feature incorrectly?
> 
> If the latter, please provide that git commit id.
> 
> thanks,
> 
> greg k-h

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 19:01:20 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 19:01:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSuZx-0008VF-OO; Mon, 29 Oct 2012 19:00:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSuZw-0008VA-Eq
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 19:00:52 +0000
Received: from [85.158.143.99:54863] by server-1.bemta-4.messagelabs.com id
	A8/6D-19134-362DE805; Mon, 29 Oct 2012 19:00:51 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1351537249!22516328!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNDQxNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10502 invoked from network); 29 Oct 2012 19:00:51 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Oct 2012 19:00:51 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9TJ0cFK028738
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 29 Oct 2012 19:00:39 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9TJ0cGC009086
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 29 Oct 2012 19:00:38 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9TJ0b1Q002869; Mon, 29 Oct 2012 14:00:37 -0500
Received: from localhost.localdomain (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 29 Oct 2012 12:00:37 -0700
Date: Mon, 29 Oct 2012 15:00:30 -0400
From: Konrad Rzeszutek Wilk 
To: Greg KH 
Message-ID: <20121029190030.GA2551@localhost.localdomain>
References: <508EC0D202000078000A536A@nat28.tlf.novell.com>
	<20121029165047.GA22984@kroah.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20121029165047.GA22984@kroah.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Stefano Stabellini ,
	linux-usb@vger.kernel.org, xen-devel ,
	Randy Dunlap , stern@rowland.harvard.edu,
	Jan Beulich 
Subject: Re: [Xen-devel] [PATCH,
 v2] fix build with XEN and EARLY_PRINTK_DBGP enabled but
 USB_SUPPORT disabled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 29, 2012 at 09:50:47AM -0700, Greg KH wrote:
> On Mon, Oct 29, 2012 at 04:45:54PM +0000, Jan Beulich wrote:
> > Since there's no possible caller of dbgp_external_startup() and
> > dbgp_reset_prep() when !USB_EHCI_HCD, there's no point in building and
> > exporting these functions in that case. This eliminates a build error
> > under the conditions listed in the subject, introduced with the merge
> > f1c6872e4980bc4078cfaead05f892b3d78dea64.
> 
> That's a merge commit, is that where the problem happened because Linus
> did the merge resolution incorrectly, or is it really due to some other

No. He did it based on what we (Stefano and me) thought was the correct
way that address the ARM and generic patches merge.

While it did work - Randy found via his random config generator
cronjob that it did not address all of the EHCI/EARLY/USB/PCI
combinations.

> patch that added this feature incorrectly?
> 
> If the latter, please provide that git commit id.
> 
> thanks,
> 
> greg k-h

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 19:25:26 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 19:25:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSuwx-0000Ir-S5; Mon, 29 Oct 2012 19:24:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSuwv-0000Im-Tp
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 19:24:38 +0000
Received: from [193.109.254.147:8327] by server-5.bemta-14.messagelabs.com id
	C3/99-18309-5F7DE805; Mon, 29 Oct 2012 19:24:37 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1351538676!6223426!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13641 invoked from network); 29 Oct 2012 19:24:36 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Oct 2012 19:24:36 -0000
Received: by mail-wg0-f51.google.com with SMTP id ed3so2926987wgb.32
	for ; Mon, 29 Oct 2012 12:24:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=1kYFGkivJXm071XJTBiTzJdaNoZb5/22SoO2crnJ0ag=;
	b=Ttug250A29JaBnfEMFOSmaJLbhDgJC21vLXh2kAP5tgXV8qisX6M/jWoIXlSN1EyIe
	QpUWLHu4ywu+hjXEHpAs35otM5KrHRmW0iW31OrJDE8rMCTw/XKECCTjlQBLIE0VaydQ
	vUuB6my7VYEHaig/FQNeKp2udgbAUwDXyFzmOTYaxZt8MR0vXKLIFdu2exXlLYogBbYA
	5Hiy96jXTyFKhNxyYsixdmO1g7PIa3Ir5o70otouZXlGz8M/TKM6vrqRy11dgLNsbnvP
	nYuwfd3KrmeTjA7EWAZR27DV7CBS6PsR63Y31En+y0FO+SdwQIceER4/iJgw98OFnLb5
	mULw==
Received: by 10.216.212.232 with SMTP id y82mr15705921weo.120.1351538676247;
	Mon, 29 Oct 2012 12:24:36 -0700 (PDT)
Received: from [192.168.1.88] (host86-178-46-35.range86-178.btcentralplus.com.
	[86.178.46.35])
	by mx.google.com with ESMTPS id bn7sm12663604wib.8.2012.10.29.12.24.27
	(version=SSLv3 cipher=OTHER); Mon, 29 Oct 2012 12:24:35 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Mon, 29 Oct 2012 19:24:21 +0100
From: Keir Fraser 
To: Dan Magenheimer ,
	Jan Beulich 
Message-ID: 
Thread-Topic: Proposed new "memory capacity claim" hypercall/feature
Thread-Index: Ac22Cv8iA5icrGXy5UC3nQGiKTbJdg==
In-Reply-To: <60d00f38-98a3-4ec2-acbd-b49dafaada56@default>
Mime-version: 1.0
Cc: Olaf Hering , Ian Campbell ,
	Konrad Rzeszutek Wilk ,
	George Dunlap ,
	George Shuklin ,
	"Tim \(Xen.org\)" , xen-devel@lists.xen.org,
	Dario Faggioli , Kurt Hackel ,
	Zhigang Wang ,
	Ian Jackson 
Subject: Re: [Xen-devel] Proposed new "memory capacity claim"
	hypercall/feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 29/10/2012 18:06, "Dan Magenheimer"  wrote:

> The objective of the design is to ensure that a multi-threaded
> toolstack can atomically claim a specific amount of RAM capacity for a
> domain, especially in the presence of independent dynamic memory demand
> (such as tmem and selfballooning) which the toolstack is not able to track.
> "Claim X 50G" means that, on completion of the call, either (A) 50G of
> capacity has been claimed for use by domain X and the call returns
> success or (B) the call returns failure.  Note that in the above,
> "claim" explicitly does NOT mean that specific physical RAM pages have
> been assigned, only that the 50G of RAM capacity is not available either
> to a subsequent "claim" or for most[2] independent dynamic memory demands.

I don't really understand the problem it solves, to be honest. Why would you
not just allocate the RAM pages, rather than merely making that amount of
memory unallocatable for any other purpose?

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 19:25:26 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 19:25:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSuwx-0000Ir-S5; Mon, 29 Oct 2012 19:24:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSuwv-0000Im-Tp
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 19:24:38 +0000
Received: from [193.109.254.147:8327] by server-5.bemta-14.messagelabs.com id
	C3/99-18309-5F7DE805; Mon, 29 Oct 2012 19:24:37 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1351538676!6223426!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13641 invoked from network); 29 Oct 2012 19:24:36 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Oct 2012 19:24:36 -0000
Received: by mail-wg0-f51.google.com with SMTP id ed3so2926987wgb.32
	for ; Mon, 29 Oct 2012 12:24:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=1kYFGkivJXm071XJTBiTzJdaNoZb5/22SoO2crnJ0ag=;
	b=Ttug250A29JaBnfEMFOSmaJLbhDgJC21vLXh2kAP5tgXV8qisX6M/jWoIXlSN1EyIe
	QpUWLHu4ywu+hjXEHpAs35otM5KrHRmW0iW31OrJDE8rMCTw/XKECCTjlQBLIE0VaydQ
	vUuB6my7VYEHaig/FQNeKp2udgbAUwDXyFzmOTYaxZt8MR0vXKLIFdu2exXlLYogBbYA
	5Hiy96jXTyFKhNxyYsixdmO1g7PIa3Ir5o70otouZXlGz8M/TKM6vrqRy11dgLNsbnvP
	nYuwfd3KrmeTjA7EWAZR27DV7CBS6PsR63Y31En+y0FO+SdwQIceER4/iJgw98OFnLb5
	mULw==
Received: by 10.216.212.232 with SMTP id y82mr15705921weo.120.1351538676247;
	Mon, 29 Oct 2012 12:24:36 -0700 (PDT)
Received: from [192.168.1.88] (host86-178-46-35.range86-178.btcentralplus.com.
	[86.178.46.35])
	by mx.google.com with ESMTPS id bn7sm12663604wib.8.2012.10.29.12.24.27
	(version=SSLv3 cipher=OTHER); Mon, 29 Oct 2012 12:24:35 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Mon, 29 Oct 2012 19:24:21 +0100
From: Keir Fraser 
To: Dan Magenheimer ,
	Jan Beulich 
Message-ID: 
Thread-Topic: Proposed new "memory capacity claim" hypercall/feature
Thread-Index: Ac22Cv8iA5icrGXy5UC3nQGiKTbJdg==
In-Reply-To: <60d00f38-98a3-4ec2-acbd-b49dafaada56@default>
Mime-version: 1.0
Cc: Olaf Hering , Ian Campbell ,
	Konrad Rzeszutek Wilk ,
	George Dunlap ,
	George Shuklin ,
	"Tim \(Xen.org\)" , xen-devel@lists.xen.org,
	Dario Faggioli , Kurt Hackel ,
	Zhigang Wang ,
	Ian Jackson 
Subject: Re: [Xen-devel] Proposed new "memory capacity claim"
	hypercall/feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 29/10/2012 18:06, "Dan Magenheimer"  wrote:

> The objective of the design is to ensure that a multi-threaded
> toolstack can atomically claim a specific amount of RAM capacity for a
> domain, especially in the presence of independent dynamic memory demand
> (such as tmem and selfballooning) which the toolstack is not able to track.
> "Claim X 50G" means that, on completion of the call, either (A) 50G of
> capacity has been claimed for use by domain X and the call returns
> success or (B) the call returns failure.  Note that in the above,
> "claim" explicitly does NOT mean that specific physical RAM pages have
> been assigned, only that the 50G of RAM capacity is not available either
> to a subsequent "claim" or for most[2] independent dynamic memory demands.

I don't really understand the problem it solves, to be honest. Why would you
not just allocate the RAM pages, rather than merely making that amount of
memory unallocatable for any other purpose?

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 21:09:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 21:09:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSwZb-0001D0-PA; Mon, 29 Oct 2012 21:08:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSwZZ-0001Cv-Sc
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 21:08:38 +0000
Received: from [193.109.254.147:54526] by server-6.bemta-14.messagelabs.com id
	3C/5E-17826-550FE805; Mon, 29 Oct 2012 21:08:37 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1351544915!8881255!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgzNTIxNw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31061 invoked from network); 29 Oct 2012 21:08:36 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Oct 2012 21:08:36 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9TL8Keb016685
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 29 Oct 2012 21:08:21 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9TL8In5015140
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 29 Oct 2012 21:08:19 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9TL8IBf026865; Mon, 29 Oct 2012 16:08:18 -0500
MIME-Version: 1.0
Message-ID: <89c92e3f-8aeb-4c97-ab15-d282327f3a98@default>
Date: Mon, 29 Oct 2012 14:08:16 -0700 (PDT)
From: Dan Magenheimer 
To: Keir Fraser , Jan Beulich 
References: <60d00f38-98a3-4ec2-acbd-b49dafaada56@default>
	
In-Reply-To: 
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Olaf Hering , Ian Campbell ,
	Konrad Wilk ,
	George Dunlap ,
	George Shuklin ,
	"Tim \(Xen.org\)" , xen-devel@lists.xen.org,
	Dario Faggioli , Kurt Hackel ,
	Zhigang Wang ,
	Ian Jackson 
Subject: Re: [Xen-devel] Proposed new "memory capacity claim"
	hypercall/feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Keir Fraser [mailto:keir.xen@gmail.com]
> Subject: Re: Proposed new "memory capacity claim" hypercall/feature
> 
> On 29/10/2012 18:06, "Dan Magenheimer"  wrote:
> 
> > The objective of the design is to ensure that a multi-threaded
> > toolstack can atomically claim a specific amount of RAM capacity for a
> > domain, especially in the presence of independent dynamic memory demand
> > (such as tmem and selfballooning) which the toolstack is not able to track.
> > "Claim X 50G" means that, on completion of the call, either (A) 50G of
> > capacity has been claimed for use by domain X and the call returns
> > success or (B) the call returns failure.  Note that in the above,
> > "claim" explicitly does NOT mean that specific physical RAM pages have
> > been assigned, only that the 50G of RAM capacity is not available either
> > to a subsequent "claim" or for most[2] independent dynamic memory demands.
> 
> I don't really understand the problem it solves, to be honest. Why would you
> not just allocate the RAM pages, rather than merely making that amount of
> memory unallocatable for any other purpose?

Hi Keir --

Thanks for the response!

Sorry, I guess the answer to your question is buried in the
thread referenced (as [1]) plus a vague mention in this proposal.

The core issue is that, in the hypervisor, every current method of
"allocating RAM" is slow enough that if you want to allocate millions
of pages (e.g. for a large domain), the total RAM can't be allocated
atomically.  In fact, it may even take minutes, so currently a large
allocation is explicitly preemptible, not atomic.

The problems the proposal solves are (1) some toolstacks (including
Oracle's "cloud orchestration layer") want to launch domains in parallel;
currently xl/xapi require launches to be serialized which isn't very
scalable in a large data center; and (2) tmem and/or other dynamic
memory mechanisms may be asynchronously absorbing small-but-significant
portions of RAM for other purposes during an attempted domain launch.
In either case, this is a classic race, and a large allocation may
unexpectedly fail, possibly even after several minutes, which is
unacceptable for a data center operator or for automated tools trying
to launch any very large domain.

Does that make sense?  I'm very open to other solutions, but the
only one I've heard so far was essentially "disallow independent
dynamic memory allocations" plus keep track of all "claiming" in the
toolstack.

Thanks,
Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 21:09:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 21:09:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSwZb-0001D0-PA; Mon, 29 Oct 2012 21:08:39 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSwZZ-0001Cv-Sc
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 21:08:38 +0000
Received: from [193.109.254.147:54526] by server-6.bemta-14.messagelabs.com id
	3C/5E-17826-550FE805; Mon, 29 Oct 2012 21:08:37 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1351544915!8881255!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgzNTIxNw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31061 invoked from network); 29 Oct 2012 21:08:36 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Oct 2012 21:08:36 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9TL8Keb016685
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 29 Oct 2012 21:08:21 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9TL8In5015140
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 29 Oct 2012 21:08:19 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9TL8IBf026865; Mon, 29 Oct 2012 16:08:18 -0500
MIME-Version: 1.0
Message-ID: <89c92e3f-8aeb-4c97-ab15-d282327f3a98@default>
Date: Mon, 29 Oct 2012 14:08:16 -0700 (PDT)
From: Dan Magenheimer 
To: Keir Fraser , Jan Beulich 
References: <60d00f38-98a3-4ec2-acbd-b49dafaada56@default>
	
In-Reply-To: 
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Olaf Hering , Ian Campbell ,
	Konrad Wilk ,
	George Dunlap ,
	George Shuklin ,
	"Tim \(Xen.org\)" , xen-devel@lists.xen.org,
	Dario Faggioli , Kurt Hackel ,
	Zhigang Wang ,
	Ian Jackson 
Subject: Re: [Xen-devel] Proposed new "memory capacity claim"
	hypercall/feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Keir Fraser [mailto:keir.xen@gmail.com]
> Subject: Re: Proposed new "memory capacity claim" hypercall/feature
> 
> On 29/10/2012 18:06, "Dan Magenheimer"  wrote:
> 
> > The objective of the design is to ensure that a multi-threaded
> > toolstack can atomically claim a specific amount of RAM capacity for a
> > domain, especially in the presence of independent dynamic memory demand
> > (such as tmem and selfballooning) which the toolstack is not able to track.
> > "Claim X 50G" means that, on completion of the call, either (A) 50G of
> > capacity has been claimed for use by domain X and the call returns
> > success or (B) the call returns failure.  Note that in the above,
> > "claim" explicitly does NOT mean that specific physical RAM pages have
> > been assigned, only that the 50G of RAM capacity is not available either
> > to a subsequent "claim" or for most[2] independent dynamic memory demands.
> 
> I don't really understand the problem it solves, to be honest. Why would you
> not just allocate the RAM pages, rather than merely making that amount of
> memory unallocatable for any other purpose?

Hi Keir --

Thanks for the response!

Sorry, I guess the answer to your question is buried in the
thread referenced (as [1]) plus a vague mention in this proposal.

The core issue is that, in the hypervisor, every current method of
"allocating RAM" is slow enough that if you want to allocate millions
of pages (e.g. for a large domain), the total RAM can't be allocated
atomically.  In fact, it may even take minutes, so currently a large
allocation is explicitly preemptible, not atomic.

The problems the proposal solves are (1) some toolstacks (including
Oracle's "cloud orchestration layer") want to launch domains in parallel;
currently xl/xapi require launches to be serialized which isn't very
scalable in a large data center; and (2) tmem and/or other dynamic
memory mechanisms may be asynchronously absorbing small-but-significant
portions of RAM for other purposes during an attempted domain launch.
In either case, this is a classic race, and a large allocation may
unexpectedly fail, possibly even after several minutes, which is
unacceptable for a data center operator or for automated tools trying
to launch any very large domain.

Does that make sense?  I'm very open to other solutions, but the
only one I've heard so far was essentially "disallow independent
dynamic memory allocations" plus keep track of all "claiming" in the
toolstack.

Thanks,
Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 22:18:26 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 22:18:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSxef-0001ay-7F; Mon, 29 Oct 2012 22:17:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSxee-0001at-9v
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 22:17:56 +0000
Received: from [193.109.254.147:48698] by server-12.bemta-14.messagelabs.com
	id 7A/21-00510-3900F805; Mon, 29 Oct 2012 22:17:55 +0000
X-Env-Sender: stern+508a77b4@rowland.harvard.edu
X-Msg-Ref: server-8.tower-27.messagelabs.com!1351549074!8917786!1
X-Originating-IP: [192.131.102.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24486 invoked from network); 29 Oct 2012 22:17:55 -0000
Received: from netrider.rowland.org (HELO netrider.rowland.org) (192.131.102.5)
	by server-8.tower-27.messagelabs.com with SMTP;
	29 Oct 2012 22:17:55 -0000
Received: (qmail 31780 invoked by uid 500); 29 Oct 2012 18:17:53 -0400
Received: from localhost (sendmail-bs@127.0.0.1)
	by localhost with SMTP; 29 Oct 2012 18:17:53 -0400
Date: Mon, 29 Oct 2012 18:17:53 -0400 (EDT)
From: Alan Stern 
X-X-Sender: stern@netrider.rowland.org
To: Jan Beulich 
In-Reply-To: <508EC0D202000078000A536A@nat28.tlf.novell.com>
Message-ID: 
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk ,
	Stefano Stabellini ,
	gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
	xen-devel , Randy Dunlap 
Subject: Re: [Xen-devel] [PATCH,
 v2] fix build with XEN and EARLY_PRINTK_DBGP enabled but
 USB_SUPPORT disabled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 29 Oct 2012, Jan Beulich wrote:

> Since there's no possible caller of dbgp_external_startup() and
> dbgp_reset_prep() when !USB_EHCI_HCD, there's no point in building and
> exporting these functions in that case. This eliminates a build error
> under the conditions listed in the subject, introduced with the merge
> f1c6872e4980bc4078cfaead05f892b3d78dea64.
> 
> Reported-by: Randy Dunlap 
> Signed-off-by: Jan Beulich 
> Cc: Stefano Stabellini 
> Cc: Alan Stern 
> ---
> v2: Switch the dependency from USB_SUPPORT to USB_EHCI_HCD as requested
>     by Alan (albeit I don't really agree to that change).

Considering that the rest of ehci-dbgp.c is specific to EHCI hardware,
using USB_EHCI_HCD seems to me like a reasonable thing to do.

> ---
>  arch/x86/kernel/cpu/perf_event_p6.c |    2 +-

What's up with this?

>  drivers/usb/early/ehci-dbgp.c       |   15 +++++++++------
>  2 files changed, 10 insertions(+), 7 deletions(-)

Acked-by: Alan Stern 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 22:18:26 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 22:18:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSxef-0001ay-7F; Mon, 29 Oct 2012 22:17:57 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSxee-0001at-9v
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 22:17:56 +0000
Received: from [193.109.254.147:48698] by server-12.bemta-14.messagelabs.com
	id 7A/21-00510-3900F805; Mon, 29 Oct 2012 22:17:55 +0000
X-Env-Sender: stern+508a77b4@rowland.harvard.edu
X-Msg-Ref: server-8.tower-27.messagelabs.com!1351549074!8917786!1
X-Originating-IP: [192.131.102.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24486 invoked from network); 29 Oct 2012 22:17:55 -0000
Received: from netrider.rowland.org (HELO netrider.rowland.org) (192.131.102.5)
	by server-8.tower-27.messagelabs.com with SMTP;
	29 Oct 2012 22:17:55 -0000
Received: (qmail 31780 invoked by uid 500); 29 Oct 2012 18:17:53 -0400
Received: from localhost (sendmail-bs@127.0.0.1)
	by localhost with SMTP; 29 Oct 2012 18:17:53 -0400
Date: Mon, 29 Oct 2012 18:17:53 -0400 (EDT)
From: Alan Stern 
X-X-Sender: stern@netrider.rowland.org
To: Jan Beulich 
In-Reply-To: <508EC0D202000078000A536A@nat28.tlf.novell.com>
Message-ID: 
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk ,
	Stefano Stabellini ,
	gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
	xen-devel , Randy Dunlap 
Subject: Re: [Xen-devel] [PATCH,
 v2] fix build with XEN and EARLY_PRINTK_DBGP enabled but
 USB_SUPPORT disabled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 29 Oct 2012, Jan Beulich wrote:

> Since there's no possible caller of dbgp_external_startup() and
> dbgp_reset_prep() when !USB_EHCI_HCD, there's no point in building and
> exporting these functions in that case. This eliminates a build error
> under the conditions listed in the subject, introduced with the merge
> f1c6872e4980bc4078cfaead05f892b3d78dea64.
> 
> Reported-by: Randy Dunlap 
> Signed-off-by: Jan Beulich 
> Cc: Stefano Stabellini 
> Cc: Alan Stern 
> ---
> v2: Switch the dependency from USB_SUPPORT to USB_EHCI_HCD as requested
>     by Alan (albeit I don't really agree to that change).

Considering that the rest of ehci-dbgp.c is specific to EHCI hardware,
using USB_EHCI_HCD seems to me like a reasonable thing to do.

> ---
>  arch/x86/kernel/cpu/perf_event_p6.c |    2 +-

What's up with this?

>  drivers/usb/early/ehci-dbgp.c       |   15 +++++++++------
>  2 files changed, 10 insertions(+), 7 deletions(-)

Acked-by: Alan Stern 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 22:22:48 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 22:22:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSxiq-0001kC-Tv; Mon, 29 Oct 2012 22:22:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSxip-0001k5-L1
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 22:22:15 +0000
Received: from [85.158.139.83:27972] by server-1.bemta-5.messagelabs.com id
	E6/30-21640-6910F805; Mon, 29 Oct 2012 22:22:14 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1351549334!27889286!1
X-Originating-IP: [209.85.212.169]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23780 invoked from network); 29 Oct 2012 22:22:14 -0000
Received: from mail-wi0-f169.google.com (HELO mail-wi0-f169.google.com)
	(209.85.212.169)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Oct 2012 22:22:14 -0000
Received: by mail-wi0-f169.google.com with SMTP id hq4so2508472wib.2
	for ; Mon, 29 Oct 2012 15:22:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=pwIaazxEgKj0u373w+A+dM7N9KIrZCHkGtP1dp/4K4s=;
	b=N5yUFtneYosm9ev4bpDt+Gc3ECyQzkgW8ZrKQgPzsLaz816pRr3p0GOTBi9kmDsRcw
	XGBeYhZ6ypd0W1NSRIBS9cqNeaeGGLeZ+PFB5hJs5QdXrzOTQ4pMqWWboPZsw2k1Zzy+
	jDT6E0OniCvOR+6hOrIBFJeA+NeoLMbGssu8taecRPqb061r3UPUrKdOWwTniTxDCWCF
	7BrI4JtWgrKcxRb/RA/1swPj9ZJTD2MGXq095kWj4B3mT6TdqzOl++z4KWF77WvmoHkm
	sk9dtC1M8qb3FdYYcRqhNuczvumZxvzl5N/Gl6+zzp1yvd5LEztXoR/liYeWyfX3SxZK
	TMNg==
Received: by 10.180.80.100 with SMTP id q4mr17261920wix.20.1351549333893;
	Mon, 29 Oct 2012 15:22:13 -0700 (PDT)
Received: from [192.168.1.3] (host86-178-46-35.range86-178.btcentralplus.com.
	[86.178.46.35])
	by mx.google.com with ESMTPS id m14sm11626984wie.8.2012.10.29.15.22.10
	(version=SSLv3 cipher=OTHER); Mon, 29 Oct 2012 15:22:13 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Mon, 29 Oct 2012 22:22:07 +0000
From: Keir Fraser 
To: Dan Magenheimer ,
	Jan Beulich 
Message-ID: 
Thread-Topic: Proposed new "memory capacity claim" hypercall/feature
Thread-Index: Ac22I9SRmgisLJWzVkqej0sOxi32lg==
In-Reply-To: <89c92e3f-8aeb-4c97-ab15-d282327f3a98@default>
Mime-version: 1.0
Cc: Olaf Hering , Ian Campbell ,
	Konrad Rzeszutek Wilk ,
	George Dunlap ,
	George Shuklin ,
	"Tim \(Xen.org\)" , xen-devel@lists.xen.org,
	Dario Faggioli , Kurt Hackel ,
	Zhigang Wang ,
	Ian Jackson 
Subject: Re: [Xen-devel] Proposed new "memory capacity claim"
	hypercall/feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 29/10/2012 21:08, "Dan Magenheimer"  wrote:

> The core issue is that, in the hypervisor, every current method of
> "allocating RAM" is slow enough that if you want to allocate millions
> of pages (e.g. for a large domain), the total RAM can't be allocated
> atomically.  In fact, it may even take minutes, so currently a large
> allocation is explicitly preemptible, not atomic.
>
> The problems the proposal solves are (1) some toolstacks (including
> Oracle's "cloud orchestration layer") want to launch domains in parallel;
> currently xl/xapi require launches to be serialized which isn't very
> scalable in a large data center;

Well it does depend how scalable domain creation actually is as an
operation. If it is spending most of its time allocating memory then it is
quite likely that parallel creations will spend a lot of time competing for
the heap spinlock, and actually there will be little/no speedup compared
with serialising the creations. Further, if domain creation can take
minutes, it may be that we simply need to go optimise that -- we already
found one stupid thing in the heap allocator recently that was burining
loads of time during large-memory domain creations, and fixed it for a
massive speedup in that particular case.

> and (2) tmem and/or other dynamic
> memory mechanisms may be asynchronously absorbing small-but-significant
> portions of RAM for other purposes during an attempted domain launch.

This is an argument against allocate-rather-than-reserve? I don't think that
makes sense -- so is this instead an argument against
reservation-as-a-toolstack-only-mechanism? I'm not actually convinced yet we
need reservations *at all*, before we get down to where it should be
implemented.

 -- Keir

> In either case, this is a classic race, and a large allocation may
> unexpectedly fail, possibly even after several minutes, which is
> unacceptable for a data center operator or for automated tools trying
> to launch any very large domain.
> 
> Does that make sense?  I'm very open to other solutions, but the
> only one I've heard so far was essentially "disallow independent
> dynamic memory allocations" plus keep track of all "claiming" in the
> toolstack.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 22:22:48 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 22:22:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSxiq-0001kC-Tv; Mon, 29 Oct 2012 22:22:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSxip-0001k5-L1
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 22:22:15 +0000
Received: from [85.158.139.83:27972] by server-1.bemta-5.messagelabs.com id
	E6/30-21640-6910F805; Mon, 29 Oct 2012 22:22:14 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1351549334!27889286!1
X-Originating-IP: [209.85.212.169]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23780 invoked from network); 29 Oct 2012 22:22:14 -0000
Received: from mail-wi0-f169.google.com (HELO mail-wi0-f169.google.com)
	(209.85.212.169)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Oct 2012 22:22:14 -0000
Received: by mail-wi0-f169.google.com with SMTP id hq4so2508472wib.2
	for ; Mon, 29 Oct 2012 15:22:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=pwIaazxEgKj0u373w+A+dM7N9KIrZCHkGtP1dp/4K4s=;
	b=N5yUFtneYosm9ev4bpDt+Gc3ECyQzkgW8ZrKQgPzsLaz816pRr3p0GOTBi9kmDsRcw
	XGBeYhZ6ypd0W1NSRIBS9cqNeaeGGLeZ+PFB5hJs5QdXrzOTQ4pMqWWboPZsw2k1Zzy+
	jDT6E0OniCvOR+6hOrIBFJeA+NeoLMbGssu8taecRPqb061r3UPUrKdOWwTniTxDCWCF
	7BrI4JtWgrKcxRb/RA/1swPj9ZJTD2MGXq095kWj4B3mT6TdqzOl++z4KWF77WvmoHkm
	sk9dtC1M8qb3FdYYcRqhNuczvumZxvzl5N/Gl6+zzp1yvd5LEztXoR/liYeWyfX3SxZK
	TMNg==
Received: by 10.180.80.100 with SMTP id q4mr17261920wix.20.1351549333893;
	Mon, 29 Oct 2012 15:22:13 -0700 (PDT)
Received: from [192.168.1.3] (host86-178-46-35.range86-178.btcentralplus.com.
	[86.178.46.35])
	by mx.google.com with ESMTPS id m14sm11626984wie.8.2012.10.29.15.22.10
	(version=SSLv3 cipher=OTHER); Mon, 29 Oct 2012 15:22:13 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Mon, 29 Oct 2012 22:22:07 +0000
From: Keir Fraser 
To: Dan Magenheimer ,
	Jan Beulich 
Message-ID: 
Thread-Topic: Proposed new "memory capacity claim" hypercall/feature
Thread-Index: Ac22I9SRmgisLJWzVkqej0sOxi32lg==
In-Reply-To: <89c92e3f-8aeb-4c97-ab15-d282327f3a98@default>
Mime-version: 1.0
Cc: Olaf Hering , Ian Campbell ,
	Konrad Rzeszutek Wilk ,
	George Dunlap ,
	George Shuklin ,
	"Tim \(Xen.org\)" , xen-devel@lists.xen.org,
	Dario Faggioli , Kurt Hackel ,
	Zhigang Wang ,
	Ian Jackson 
Subject: Re: [Xen-devel] Proposed new "memory capacity claim"
	hypercall/feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 29/10/2012 21:08, "Dan Magenheimer"  wrote:

> The core issue is that, in the hypervisor, every current method of
> "allocating RAM" is slow enough that if you want to allocate millions
> of pages (e.g. for a large domain), the total RAM can't be allocated
> atomically.  In fact, it may even take minutes, so currently a large
> allocation is explicitly preemptible, not atomic.
>
> The problems the proposal solves are (1) some toolstacks (including
> Oracle's "cloud orchestration layer") want to launch domains in parallel;
> currently xl/xapi require launches to be serialized which isn't very
> scalable in a large data center;

Well it does depend how scalable domain creation actually is as an
operation. If it is spending most of its time allocating memory then it is
quite likely that parallel creations will spend a lot of time competing for
the heap spinlock, and actually there will be little/no speedup compared
with serialising the creations. Further, if domain creation can take
minutes, it may be that we simply need to go optimise that -- we already
found one stupid thing in the heap allocator recently that was burining
loads of time during large-memory domain creations, and fixed it for a
massive speedup in that particular case.

> and (2) tmem and/or other dynamic
> memory mechanisms may be asynchronously absorbing small-but-significant
> portions of RAM for other purposes during an attempted domain launch.

This is an argument against allocate-rather-than-reserve? I don't think that
makes sense -- so is this instead an argument against
reservation-as-a-toolstack-only-mechanism? I'm not actually convinced yet we
need reservations *at all*, before we get down to where it should be
implemented.

 -- Keir

> In either case, this is a classic race, and a large allocation may
> unexpectedly fail, possibly even after several minutes, which is
> unacceptable for a data center operator or for automated tools trying
> to launch any very large domain.
> 
> Does that make sense?  I'm very open to other solutions, but the
> only one I've heard so far was essentially "disallow independent
> dynamic memory allocations" plus keep track of all "claiming" in the
> toolstack.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 22:36:34 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 22:36:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSxwD-0001wF-AE; Mon, 29 Oct 2012 22:36:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TSxwA-0001wA-Sj
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 22:36:03 +0000
Received: from [85.158.139.83:6244] by server-5.bemta-5.messagelabs.com id
	4C/65-09732-2D40F805; Mon, 29 Oct 2012 22:36:02 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-182.messagelabs.com!1351550161!20510318!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28098 invoked from network); 29 Oct 2012 22:36:01 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Oct 2012 22:36:01 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TSxw3-0007nF-Kg; Mon, 29 Oct 2012 22:35:55 +0000
Date: Mon, 29 Oct 2012 22:35:55 +0000
From: Tim Deegan 
To: Dan Magenheimer 
Message-ID: <20121029223555.GA24388@ocelot.phlegethon.org>
References: <60d00f38-98a3-4ec2-acbd-b49dafaada56@default>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <60d00f38-98a3-4ec2-acbd-b49dafaada56@default>
User-Agent: Mutt/1.4.2.1i
Cc: Olaf Hering , "Keir \(Xen.org\)" ,
	Ian Campbell ,
	Konrad Wilk ,
	George Dunlap ,
	Kurt Hackel ,
	George Shuklin ,
	xen-devel@lists.xen.org, Dario Faggioli ,
	Zhigang Wang ,
	Ian Jackson 
Subject: Re: [Xen-devel] Proposed new "memory capacity claim"
	hypercall/feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 10:06 -0700 on 29 Oct (1351505175), Dan Magenheimer wrote:
> Hypervisor design/implementation overview:
> 
> A domain currently does RAM accounting with two primary counters
> "tot_pages" and "max_pages".  (For now, let's ignore shr_pages,
> paged_pages, and xenheap_pages, and I hope Olaf/Andre/others can
> provide further expertise and input.)
> 
> Tot_pages is a struct_domain element in the hypervisor that tracks
> the number of physical RAM pageframes "owned" by the domain.  The
> hypervisor enforces that tot_pages is never allowed to exceed another
> struct_domain element called max_pages.
> 
> I would like to introduce a new counter, which records how
> much capacity is claimed for a domain which may or may not yet be
> mapped to physical RAM pageframes.  To do so, I'd like to split
> the concept of tot_pages into two variables, tot_phys_pages and
> tot_claimed_pages and require the hypervisor to also enforce:
> 
> d.tot_phys_pages <= d.tot_claimed_pages[3] <= d.max_pages
> 
> I'd also split the hypervisor global "total_avail_pages" into
> "total_free_pages" and "total_unclaimed_pages".  (I'm definitely
> going to need to study more the two-dimensional array "avail"...)
> The hypervisor must now do additional accounting to keep track
> of the sum of claims across all domains and also enforce the
> global:
> 
> total_unclaimed_pages <= total_free_pages
> 
> I think the memory_op hypercall can be extended to add two
> additional subops, XENMEM_claim and XENMEM_release.  (Note: To
> support tmem, there will need to be two variations of XEN_claim,
> "hard claim" and "soft claim" [3].)  The XEN_claim subop atomically
> evaluates total_unclaimed_pages against the new claim, claims
> the pages for the domain if possible and returns success or failure.
> The XEN_release "unsets" the domain's tot_claimed_pages (to an
> "illegal" value such as zero or MINUS_ONE).
> 
> The hypervisor must also enforce some semantics:  If an allocation
> occurs such that a domain's tot_phys_pages would equal or exceed
> d.tot_claimed_pages, then d.tot_claimed_pages becomes "unset".
> This enforces the temporary nature of a claim:  Once a domain
> fully "occupies" its claim, the claim silently expires.

Why does that happen?  If I understand you correctly, releasing the
claim is something the toolstack should do once it knows it's no longer
needed.

> In the case of a dying domain, a XENMEM_release operation
> is implied and must be executed by the hypervisor.
> 
> Ideally, the quantity of unclaimed memory for each domain and
> for the system should be query-able.  This may require additional
> memory_op hypercalls.
> 
> I'd very much appreciate feedback on this proposed design!

As I said, I'm not opposed to this, though even after reading through
the other thread I'm not convinced that it's necessary (except in cases
where guest-controlled operations are allowed to consume unbounded
memory, which frankly gives me the heebie-jeebies).

I think it needs a plan for handling restricted memory allocations.
For example, some PV guests need their memory to come below a
certain machine address, or entirely in superpages, and certain
build-time allocations come from xenheap.  How would you handle that
sort of thing?

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 22:36:34 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 22:36:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSxwD-0001wF-AE; Mon, 29 Oct 2012 22:36:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TSxwA-0001wA-Sj
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 22:36:03 +0000
Received: from [85.158.139.83:6244] by server-5.bemta-5.messagelabs.com id
	4C/65-09732-2D40F805; Mon, 29 Oct 2012 22:36:02 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-182.messagelabs.com!1351550161!20510318!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28098 invoked from network); 29 Oct 2012 22:36:01 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Oct 2012 22:36:01 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TSxw3-0007nF-Kg; Mon, 29 Oct 2012 22:35:55 +0000
Date: Mon, 29 Oct 2012 22:35:55 +0000
From: Tim Deegan 
To: Dan Magenheimer 
Message-ID: <20121029223555.GA24388@ocelot.phlegethon.org>
References: <60d00f38-98a3-4ec2-acbd-b49dafaada56@default>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <60d00f38-98a3-4ec2-acbd-b49dafaada56@default>
User-Agent: Mutt/1.4.2.1i
Cc: Olaf Hering , "Keir \(Xen.org\)" ,
	Ian Campbell ,
	Konrad Wilk ,
	George Dunlap ,
	Kurt Hackel ,
	George Shuklin ,
	xen-devel@lists.xen.org, Dario Faggioli ,
	Zhigang Wang ,
	Ian Jackson 
Subject: Re: [Xen-devel] Proposed new "memory capacity claim"
	hypercall/feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 10:06 -0700 on 29 Oct (1351505175), Dan Magenheimer wrote:
> Hypervisor design/implementation overview:
> 
> A domain currently does RAM accounting with two primary counters
> "tot_pages" and "max_pages".  (For now, let's ignore shr_pages,
> paged_pages, and xenheap_pages, and I hope Olaf/Andre/others can
> provide further expertise and input.)
> 
> Tot_pages is a struct_domain element in the hypervisor that tracks
> the number of physical RAM pageframes "owned" by the domain.  The
> hypervisor enforces that tot_pages is never allowed to exceed another
> struct_domain element called max_pages.
> 
> I would like to introduce a new counter, which records how
> much capacity is claimed for a domain which may or may not yet be
> mapped to physical RAM pageframes.  To do so, I'd like to split
> the concept of tot_pages into two variables, tot_phys_pages and
> tot_claimed_pages and require the hypervisor to also enforce:
> 
> d.tot_phys_pages <= d.tot_claimed_pages[3] <= d.max_pages
> 
> I'd also split the hypervisor global "total_avail_pages" into
> "total_free_pages" and "total_unclaimed_pages".  (I'm definitely
> going to need to study more the two-dimensional array "avail"...)
> The hypervisor must now do additional accounting to keep track
> of the sum of claims across all domains and also enforce the
> global:
> 
> total_unclaimed_pages <= total_free_pages
> 
> I think the memory_op hypercall can be extended to add two
> additional subops, XENMEM_claim and XENMEM_release.  (Note: To
> support tmem, there will need to be two variations of XEN_claim,
> "hard claim" and "soft claim" [3].)  The XEN_claim subop atomically
> evaluates total_unclaimed_pages against the new claim, claims
> the pages for the domain if possible and returns success or failure.
> The XEN_release "unsets" the domain's tot_claimed_pages (to an
> "illegal" value such as zero or MINUS_ONE).
> 
> The hypervisor must also enforce some semantics:  If an allocation
> occurs such that a domain's tot_phys_pages would equal or exceed
> d.tot_claimed_pages, then d.tot_claimed_pages becomes "unset".
> This enforces the temporary nature of a claim:  Once a domain
> fully "occupies" its claim, the claim silently expires.

Why does that happen?  If I understand you correctly, releasing the
claim is something the toolstack should do once it knows it's no longer
needed.

> In the case of a dying domain, a XENMEM_release operation
> is implied and must be executed by the hypervisor.
> 
> Ideally, the quantity of unclaimed memory for each domain and
> for the system should be query-able.  This may require additional
> memory_op hypercalls.
> 
> I'd very much appreciate feedback on this proposed design!

As I said, I'm not opposed to this, though even after reading through
the other thread I'm not convinced that it's necessary (except in cases
where guest-controlled operations are allowed to consume unbounded
memory, which frankly gives me the heebie-jeebies).

I think it needs a plan for handling restricted memory allocations.
For example, some PV guests need their memory to come below a
certain machine address, or entirely in superpages, and certain
build-time allocations come from xenheap.  How would you handle that
sort of thing?

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 23:04:50 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 23:04:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSyNX-0002Cf-Od; Mon, 29 Oct 2012 23:04:19 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSyNW-0002Ca-Ea
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 23:04:18 +0000
Received: from [193.109.254.147:52119] by server-9.bemta-14.messagelabs.com id
	D2/71-30773-17B0F805; Mon, 29 Oct 2012 23:04:17 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1351551853!8858623!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgzNTgzNA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2383 invoked from network); 29 Oct 2012 23:04:14 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Oct 2012 23:04:14 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9TN40wq018581
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 29 Oct 2012 23:04:01 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9TN3x6f002503
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 29 Oct 2012 23:04:00 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9TN3wVk009015; Mon, 29 Oct 2012 18:03:58 -0500
MIME-Version: 1.0
Message-ID: <806ef32a-2ded-42b5-a2ff-5f84ac1c1d47@default>
Date: Mon, 29 Oct 2012 16:03:56 -0700 (PDT)
From: Dan Magenheimer 
To: Keir Fraser , Jan Beulich 
References: <89c92e3f-8aeb-4c97-ab15-d282327f3a98@default>
	
In-Reply-To: 
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Olaf Hering , Ian Campbell ,
	Konrad Wilk ,
	George Dunlap ,
	George Shuklin ,
	"Tim \(Xen.org\)" , xen-devel@lists.xen.org,
	Dario Faggioli , Kurt Hackel ,
	Zhigang Wang ,
	Ian Jackson 
Subject: Re: [Xen-devel] Proposed new "memory capacity claim"
	hypercall/feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Keir Fraser [mailto:keir@xen.org]
> Subject: Re: Proposed new "memory capacity claim" hypercall/feature
> 
> On 29/10/2012 21:08, "Dan Magenheimer"  wrote:
> 
> > The core issue is that, in the hypervisor, every current method of
> > "allocating RAM" is slow enough that if you want to allocate millions
> > of pages (e.g. for a large domain), the total RAM can't be allocated
> > atomically.  In fact, it may even take minutes, so currently a large
> > allocation is explicitly preemptible, not atomic.
> >
> > The problems the proposal solves are (1) some toolstacks (including
> > Oracle's "cloud orchestration layer") want to launch domains in parallel;
> > currently xl/xapi require launches to be serialized which isn't very
> > scalable in a large data center;
> 
> Well it does depend how scalable domain creation actually is as an
> operation. If it is spending most of its time allocating memory then it is
> quite likely that parallel creations will spend a lot of time competing for
> the heap spinlock, and actually there will be little/no speedup compared
> with serialising the creations. Further, if domain creation can take
> minutes, it may be that we simply need to go optimise that -- we already
> found one stupid thing in the heap allocator recently that was burining
> loads of time during large-memory domain creations, and fixed it for a
> massive speedup in that particular case.

I suppose ultimately it is a scalability question.  But Oracle's
measure of success here is based on how long a human or a tool
has to wait for confirmation to ensure that a domain will
successfully launch.  If two domains are launched in parallel
AND an indication is given that both will succeed, spinning on
the heaplock a bit just makes for a longer "boot" time, which is
just a cost of virtualization.  If they are launched in parallel
and, minutes later (or maybe even 20 seconds later), one or
both say "oops, I was wrong, there wasn't enough memory, so
try again", that's not OK for data center operations, especially if
there really was enough RAM for one, but not for both. Remember,
in the Oracle environment, we are talking about an administrator/automation
overseeing possibly hundreds of physical servers, not just a single
user/server.

Does that make more sense?

The "claim" approach immediately guarantees success or failure.
Unless there are enough "stupid things/optimisations" found that
you would be comfortable putting memory allocation for a domain
creation in a hypervisor spinlock, there will be a race unless
an atomic mechanism exists such as "claiming" where
only simple arithmetic must be done within a hypervisor lock.

Do you disagree?

> > and (2) tmem and/or other dynamic
> > memory mechanisms may be asynchronously absorbing small-but-significant
> > portions of RAM for other purposes during an attempted domain launch.
> 
> This is an argument against allocate-rather-than-reserve? I don't think that
> makes sense -- so is this instead an argument against
> reservation-as-a-toolstack-only-mechanism? I'm not actually convinced yet we
> need reservations *at all*, before we get down to where it should be
> implemented.

I'm not sure if we are defining terms the same, so that's hard
to answer.  If you define "allocation" as "a physical RAM page frame
number is selected (and possibly the physical page is zeroed)",
then I'm not sure how your definition of "reservation" differs
(because that's how increase/decrease_reservation are implemented
in the hypervisor, right?).

Or did you mean "allocate-rather-than-claim" (where "allocate" is
select a specific physical pageframe and "claim" means do accounting
only?  If so, see the atomicity argument above.

I'm not just arguing against reservation-as-a-toolstack-mechanism,
I'm stating I believe unequivocally that reservation-as-a-toolstack-
only-mechanism and tmem are incompatible.  (Well, not _totally_
incompatible... the existing workaround, tmem freeze/thaw, works
but is also single-threaded and has fairly severe unnecessary
performance repercussions.  So I'd like to solve both problems
at the same time.)

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 23:04:50 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 23:04:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSyNX-0002Cf-Od; Mon, 29 Oct 2012 23:04:19 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSyNW-0002Ca-Ea
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 23:04:18 +0000
Received: from [193.109.254.147:52119] by server-9.bemta-14.messagelabs.com id
	D2/71-30773-17B0F805; Mon, 29 Oct 2012 23:04:17 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1351551853!8858623!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgzNTgzNA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2383 invoked from network); 29 Oct 2012 23:04:14 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Oct 2012 23:04:14 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9TN40wq018581
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 29 Oct 2012 23:04:01 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9TN3x6f002503
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 29 Oct 2012 23:04:00 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9TN3wVk009015; Mon, 29 Oct 2012 18:03:58 -0500
MIME-Version: 1.0
Message-ID: <806ef32a-2ded-42b5-a2ff-5f84ac1c1d47@default>
Date: Mon, 29 Oct 2012 16:03:56 -0700 (PDT)
From: Dan Magenheimer 
To: Keir Fraser , Jan Beulich 
References: <89c92e3f-8aeb-4c97-ab15-d282327f3a98@default>
	
In-Reply-To: 
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Olaf Hering , Ian Campbell ,
	Konrad Wilk ,
	George Dunlap ,
	George Shuklin ,
	"Tim \(Xen.org\)" , xen-devel@lists.xen.org,
	Dario Faggioli , Kurt Hackel ,
	Zhigang Wang ,
	Ian Jackson 
Subject: Re: [Xen-devel] Proposed new "memory capacity claim"
	hypercall/feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Keir Fraser [mailto:keir@xen.org]
> Subject: Re: Proposed new "memory capacity claim" hypercall/feature
> 
> On 29/10/2012 21:08, "Dan Magenheimer"  wrote:
> 
> > The core issue is that, in the hypervisor, every current method of
> > "allocating RAM" is slow enough that if you want to allocate millions
> > of pages (e.g. for a large domain), the total RAM can't be allocated
> > atomically.  In fact, it may even take minutes, so currently a large
> > allocation is explicitly preemptible, not atomic.
> >
> > The problems the proposal solves are (1) some toolstacks (including
> > Oracle's "cloud orchestration layer") want to launch domains in parallel;
> > currently xl/xapi require launches to be serialized which isn't very
> > scalable in a large data center;
> 
> Well it does depend how scalable domain creation actually is as an
> operation. If it is spending most of its time allocating memory then it is
> quite likely that parallel creations will spend a lot of time competing for
> the heap spinlock, and actually there will be little/no speedup compared
> with serialising the creations. Further, if domain creation can take
> minutes, it may be that we simply need to go optimise that -- we already
> found one stupid thing in the heap allocator recently that was burining
> loads of time during large-memory domain creations, and fixed it for a
> massive speedup in that particular case.

I suppose ultimately it is a scalability question.  But Oracle's
measure of success here is based on how long a human or a tool
has to wait for confirmation to ensure that a domain will
successfully launch.  If two domains are launched in parallel
AND an indication is given that both will succeed, spinning on
the heaplock a bit just makes for a longer "boot" time, which is
just a cost of virtualization.  If they are launched in parallel
and, minutes later (or maybe even 20 seconds later), one or
both say "oops, I was wrong, there wasn't enough memory, so
try again", that's not OK for data center operations, especially if
there really was enough RAM for one, but not for both. Remember,
in the Oracle environment, we are talking about an administrator/automation
overseeing possibly hundreds of physical servers, not just a single
user/server.

Does that make more sense?

The "claim" approach immediately guarantees success or failure.
Unless there are enough "stupid things/optimisations" found that
you would be comfortable putting memory allocation for a domain
creation in a hypervisor spinlock, there will be a race unless
an atomic mechanism exists such as "claiming" where
only simple arithmetic must be done within a hypervisor lock.

Do you disagree?

> > and (2) tmem and/or other dynamic
> > memory mechanisms may be asynchronously absorbing small-but-significant
> > portions of RAM for other purposes during an attempted domain launch.
> 
> This is an argument against allocate-rather-than-reserve? I don't think that
> makes sense -- so is this instead an argument against
> reservation-as-a-toolstack-only-mechanism? I'm not actually convinced yet we
> need reservations *at all*, before we get down to where it should be
> implemented.

I'm not sure if we are defining terms the same, so that's hard
to answer.  If you define "allocation" as "a physical RAM page frame
number is selected (and possibly the physical page is zeroed)",
then I'm not sure how your definition of "reservation" differs
(because that's how increase/decrease_reservation are implemented
in the hypervisor, right?).

Or did you mean "allocate-rather-than-claim" (where "allocate" is
select a specific physical pageframe and "claim" means do accounting
only?  If so, see the atomicity argument above.

I'm not just arguing against reservation-as-a-toolstack-mechanism,
I'm stating I believe unequivocally that reservation-as-a-toolstack-
only-mechanism and tmem are incompatible.  (Well, not _totally_
incompatible... the existing workaround, tmem freeze/thaw, works
but is also single-threaded and has fairly severe unnecessary
performance repercussions.  So I'd like to solve both problems
at the same time.)

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 23:22:13 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 23:22:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSyeR-0002P4-DU; Mon, 29 Oct 2012 23:21:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSyeQ-0002Oy-2o
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 23:21:46 +0000
Received: from [85.158.137.99:10685] by server-13.bemta-3.messagelabs.com id
	CD/57-24887-88F0F805; Mon, 29 Oct 2012 23:21:44 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1351552901!22288960!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgzNTIxNw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15291 invoked from network); 29 Oct 2012 23:21:43 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Oct 2012 23:21:43 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9TNLUxm027342
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 29 Oct 2012 23:21:31 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9TNLSjV026697
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 29 Oct 2012 23:21:29 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9TNLSDc005314; Mon, 29 Oct 2012 18:21:28 -0500
MIME-Version: 1.0
Message-ID: 
Date: Mon, 29 Oct 2012 16:21:26 -0700 (PDT)
From: Dan Magenheimer 
To: Tim Deegan 
References: <60d00f38-98a3-4ec2-acbd-b49dafaada56@default>
	<20121029223555.GA24388@ocelot.phlegethon.org>
In-Reply-To: <20121029223555.GA24388@ocelot.phlegethon.org>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Olaf Hering , "Keir \(Xen.org\)" ,
	Ian Campbell ,
	Konrad Wilk ,
	George Dunlap ,
	Kurt Hackel ,
	George Shuklin ,
	xen-devel@lists.xen.org, Dario Faggioli ,
	Zhigang Wang ,
	Ian Jackson 
Subject: Re: [Xen-devel] Proposed new "memory capacity claim"
	hypercall/feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Tim Deegan [mailto:tim@xen.org]
> Sent: Monday, October 29, 2012 4:36 PM
> To: Dan Magenheimer
> Cc: Keir (Xen.org); Jan Beulich; George Dunlap; Olaf Hering; Ian Campbell; Konrad Wilk; xen-
> devel@lists.xen.org; George Shuklin; Dario Faggioli; Kurt Hackel; Ian Jackson; Zhigang Wang; Mukesh
> Rathor
> Subject: Re: Proposed new "memory capacity claim" hypercall/feature
> 
> > The hypervisor must also enforce some semantics:  If an allocation
> > occurs such that a domain's tot_phys_pages would equal or exceed
> > d.tot_claimed_pages, then d.tot_claimed_pages becomes "unset".
> > This enforces the temporary nature of a claim:  Once a domain
> > fully "occupies" its claim, the claim silently expires.
> 
> Why does that happen?  If I understand you correctly, releasing the
> claim is something the toolstack should do once it knows it's no longer
> needed.

Hi Tim --

Thanks for the feedback!

I haven't thought this all the way through yet, but I think this
part of the design allows the toolstack to avoid monitoring the
domain until "total_phys_pages" reaches "total_claimed" pages,
which should make the implementation of claims in the toolstack
simpler, especially in many-server environments.
 
> > In the case of a dying domain, a XENMEM_release operation
> > is implied and must be executed by the hypervisor.
> >
> > Ideally, the quantity of unclaimed memory for each domain and
> > for the system should be query-able.  This may require additional
> > memory_op hypercalls.
> >
> > I'd very much appreciate feedback on this proposed design!
> 
> As I said, I'm not opposed to this, though even after reading through
> the other thread I'm not convinced that it's necessary (except in cases
> where guest-controlled operations are allowed to consume unbounded
> memory, which frankly gives me the heebie-jeebies).

A really detailed discussion of tmem would probably be good but,
yes, with tmem, guest-controlled* operations can and frequently will
absorb ALL physical RAM.  However, this is "freeable" (ephemeral)
memory used by the hypervisor on behalf of domains, not domain-owned
memory.

* "guest-controlled" I suspect is the heebie-jeebie word... in
  tmem, a better description might be "guest-controls-which-data-
  and-hypervisor-controls-how-many-pages"
 
> I think it needs a plan for handling restricted memory allocations.
> For example, some PV guests need their memory to come below a
> certain machine address, or entirely in superpages, and certain
> build-time allocations come from xenheap.  How would you handle that
> sort of thing?

Good point.  I think there's always been some uncertainty about
how to account for different zones and xenheap... are they part of the
domain's memory or not?  Deserves some more thought...  if
you can enumerate all such cases, that would be very helpful
(and probably valuable long-term documentation as well).

Thanks,
Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 23:22:13 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 23:22:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSyeR-0002P4-DU; Mon, 29 Oct 2012 23:21:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSyeQ-0002Oy-2o
	for xen-devel@lists.xen.org; Mon, 29 Oct 2012 23:21:46 +0000
Received: from [85.158.137.99:10685] by server-13.bemta-3.messagelabs.com id
	CD/57-24887-88F0F805; Mon, 29 Oct 2012 23:21:44 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1351552901!22288960!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgzNTIxNw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15291 invoked from network); 29 Oct 2012 23:21:43 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Oct 2012 23:21:43 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9TNLUxm027342
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 29 Oct 2012 23:21:31 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9TNLSjV026697
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 29 Oct 2012 23:21:29 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9TNLSDc005314; Mon, 29 Oct 2012 18:21:28 -0500
MIME-Version: 1.0
Message-ID: 
Date: Mon, 29 Oct 2012 16:21:26 -0700 (PDT)
From: Dan Magenheimer 
To: Tim Deegan 
References: <60d00f38-98a3-4ec2-acbd-b49dafaada56@default>
	<20121029223555.GA24388@ocelot.phlegethon.org>
In-Reply-To: <20121029223555.GA24388@ocelot.phlegethon.org>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Olaf Hering , "Keir \(Xen.org\)" ,
	Ian Campbell ,
	Konrad Wilk ,
	George Dunlap ,
	Kurt Hackel ,
	George Shuklin ,
	xen-devel@lists.xen.org, Dario Faggioli ,
	Zhigang Wang ,
	Ian Jackson 
Subject: Re: [Xen-devel] Proposed new "memory capacity claim"
	hypercall/feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Tim Deegan [mailto:tim@xen.org]
> Sent: Monday, October 29, 2012 4:36 PM
> To: Dan Magenheimer
> Cc: Keir (Xen.org); Jan Beulich; George Dunlap; Olaf Hering; Ian Campbell; Konrad Wilk; xen-
> devel@lists.xen.org; George Shuklin; Dario Faggioli; Kurt Hackel; Ian Jackson; Zhigang Wang; Mukesh
> Rathor
> Subject: Re: Proposed new "memory capacity claim" hypercall/feature
> 
> > The hypervisor must also enforce some semantics:  If an allocation
> > occurs such that a domain's tot_phys_pages would equal or exceed
> > d.tot_claimed_pages, then d.tot_claimed_pages becomes "unset".
> > This enforces the temporary nature of a claim:  Once a domain
> > fully "occupies" its claim, the claim silently expires.
> 
> Why does that happen?  If I understand you correctly, releasing the
> claim is something the toolstack should do once it knows it's no longer
> needed.

Hi Tim --

Thanks for the feedback!

I haven't thought this all the way through yet, but I think this
part of the design allows the toolstack to avoid monitoring the
domain until "total_phys_pages" reaches "total_claimed" pages,
which should make the implementation of claims in the toolstack
simpler, especially in many-server environments.
 
> > In the case of a dying domain, a XENMEM_release operation
> > is implied and must be executed by the hypervisor.
> >
> > Ideally, the quantity of unclaimed memory for each domain and
> > for the system should be query-able.  This may require additional
> > memory_op hypercalls.
> >
> > I'd very much appreciate feedback on this proposed design!
> 
> As I said, I'm not opposed to this, though even after reading through
> the other thread I'm not convinced that it's necessary (except in cases
> where guest-controlled operations are allowed to consume unbounded
> memory, which frankly gives me the heebie-jeebies).

A really detailed discussion of tmem would probably be good but,
yes, with tmem, guest-controlled* operations can and frequently will
absorb ALL physical RAM.  However, this is "freeable" (ephemeral)
memory used by the hypervisor on behalf of domains, not domain-owned
memory.

* "guest-controlled" I suspect is the heebie-jeebie word... in
  tmem, a better description might be "guest-controls-which-data-
  and-hypervisor-controls-how-many-pages"
 
> I think it needs a plan for handling restricted memory allocations.
> For example, some PV guests need their memory to come below a
> certain machine address, or entirely in superpages, and certain
> build-time allocations come from xenheap.  How would you handle that
> sort of thing?

Good point.  I think there's always been some uncertainty about
how to account for different zones and xenheap... are they part of the
domain's memory or not?  Deserves some more thought...  if
you can enumerate all such cases, that would be very helpful
(and probably valuable long-term documentation as well).

Thanks,
Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 23:48:46 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 23:48:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSz3g-0002eu-1E; Mon, 29 Oct 2012 23:47:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSz3f-0002ep-0z
	for xen-devel@lists.xensource.com; Mon, 29 Oct 2012 23:47:51 +0000
Received: from [85.158.143.35:62134] by server-2.bemta-4.messagelabs.com id
	F8/B0-22268-6A51F805; Mon, 29 Oct 2012 23:47:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1351554468!13865236!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7876 invoked from network); 29 Oct 2012 23:47:49 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Oct 2012 23:47:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,675,1344211200"; d="scan'208";a="15477418"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Oct 2012 23:47:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Mon, 29 Oct 2012 23:47:47 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TSz3b-0002Ku-P5;
	Mon, 29 Oct 2012 23:47:47 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TSz3b-0007jp-5D;
	Mon, 29 Oct 2012 23:47:47 +0000
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Mon, 29 Oct 2012 23:47:47 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 14149: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14149 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14149/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10   fail blocked in 13919
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail like 13919

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass

version targeted for testing:
 xen                  700d0f03d50a
baseline version:
 xen                  a15596a619ed

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf 
  Ian Campbell 
  Ian Jackson 
  Jacob Shin 
  Jan Beulich 
  Keir Fraser 
  Olaf Hering 
  Tim Deegan 
  Wei Wang 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-4.1-testing
+ revision=700d0f03d50a
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.1-testing 700d0f03d50a
+ branch=xen-4.1-testing
+ revision=700d0f03d50a
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.1-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-4.1-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.1-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.1-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.1-testing.git
++ : daily-cron.xen-4.1-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.1-testing.git
+ info_linux_tree xen-4.1-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.1-testing.hg
+ hg push -r 700d0f03d50a ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 9 changesets with 13 changes to 12 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Oct 29 23:48:46 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 29 Oct 2012 23:48:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSz3g-0002eu-1E; Mon, 29 Oct 2012 23:47:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSz3f-0002ep-0z
	for xen-devel@lists.xensource.com; Mon, 29 Oct 2012 23:47:51 +0000
Received: from [85.158.143.35:62134] by server-2.bemta-4.messagelabs.com id
	F8/B0-22268-6A51F805; Mon, 29 Oct 2012 23:47:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1351554468!13865236!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7876 invoked from network); 29 Oct 2012 23:47:49 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Oct 2012 23:47:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,675,1344211200"; d="scan'208";a="15477418"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Oct 2012 23:47:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Mon, 29 Oct 2012 23:47:47 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TSz3b-0002Ku-P5;
	Mon, 29 Oct 2012 23:47:47 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TSz3b-0007jp-5D;
	Mon, 29 Oct 2012 23:47:47 +0000
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Mon, 29 Oct 2012 23:47:47 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 14149: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14149 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14149/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10   fail blocked in 13919
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail like 13919

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass

version targeted for testing:
 xen                  700d0f03d50a
baseline version:
 xen                  a15596a619ed

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf 
  Ian Campbell 
  Ian Jackson 
  Jacob Shin 
  Jan Beulich 
  Keir Fraser 
  Olaf Hering 
  Tim Deegan 
  Wei Wang 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-4.1-testing
+ revision=700d0f03d50a
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.1-testing 700d0f03d50a
+ branch=xen-4.1-testing
+ revision=700d0f03d50a
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.1-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-4.1-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.1-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.1-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.1-testing.git
++ : daily-cron.xen-4.1-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.1-testing.git
+ info_linux_tree xen-4.1-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.1-testing.hg
+ hg push -r 700d0f03d50a ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 9 changesets with 13 changes to 12 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 00:17:49 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 00:17:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSzWI-0003cZ-Cs; Tue, 30 Oct 2012 00:17:26 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSzWH-0003cU-IM
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 00:17:25 +0000
Received: from [193.109.254.147:40542] by server-14.bemta-14.messagelabs.com
	id 26/30-14517-49C1F805; Tue, 30 Oct 2012 00:17:24 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1351556243!2079779!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19220 invoked from network); 30 Oct 2012 00:17:24 -0000
Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com)
	(74.125.82.41)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 00:17:24 -0000
Received: by mail-wg0-f41.google.com with SMTP id ds1so1912008wgb.2
	for ; Mon, 29 Oct 2012 17:17:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=OA5Koqb5TzWUmv5NvyZ/s4P/ECQAOSeRQxRnV4zxJSA=;
	b=l0OWYStQ3qWDcwMPTrRgmr6hJNJEfAel849MXfgDfajfFU16gqnB8mJUgltFZ3/J5n
	eYoLSJFAYtRkFSgNMGB5uLzWU+K9dN2a1aoqZ70ygiMP4m1GziubXTh5Ht0gWCmVM773
	DsjtBjDGR009r0FXxMwPYM4X62whS2hWI/IXtTPsiOTAd1STBp4AIR0/RXbod8ev1ZGd
	TsA2QGpQLHEOxNF40bmzfmXs+310BG3CiZm3A1ZcFjba0GMnP0rGOkmuJQFgQvBQB0v3
	/Y7fuRczTECw3q6vdwp48rGYnr5oJ0FPUfK8pFeAaOcLj/gcWlsqzDqIBnfNluOwIE57
	vNug==
Received: by 10.180.75.161 with SMTP id d1mr17609519wiw.19.1351556243799;
	Mon, 29 Oct 2012 17:17:23 -0700 (PDT)
Received: from [192.168.1.88] (host86-178-46-35.range86-178.btcentralplus.com.
	[86.178.46.35])
	by mx.google.com with ESMTPS id o3sm9659920wiz.9.2012.10.29.17.17.18
	(version=SSLv3 cipher=OTHER); Mon, 29 Oct 2012 17:17:23 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Tue, 30 Oct 2012 00:17:12 +0100
From: Keir Fraser 
To: Dan Magenheimer ,
	Jan Beulich 
Message-ID: 
Thread-Topic: Proposed new "memory capacity claim" hypercall/feature
Thread-Index: Ac22M+hE+Q2v9f9VvUOEGjMYtQGLXw==
In-Reply-To: <806ef32a-2ded-42b5-a2ff-5f84ac1c1d47@default>
Mime-version: 1.0
Cc: Olaf Hering , Ian Campbell ,
	Konrad Rzeszutek Wilk ,
	George Dunlap ,
	George Shuklin ,
	"Tim \(Xen.org\)" , xen-devel@lists.xen.org,
	Dario Faggioli , Kurt Hackel ,
	Zhigang Wang ,
	Ian Jackson 
Subject: Re: [Xen-devel] Proposed new "memory capacity claim"
	hypercall/feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 30/10/2012 00:03, "Dan Magenheimer"  wrote:

>> From: Keir Fraser [mailto:keir@xen.org]
>> Subject: Re: Proposed new "memory capacity claim" hypercall/feature
>> 
>> On 29/10/2012 21:08, "Dan Magenheimer"  wrote:
>> 
>> Well it does depend how scalable domain creation actually is as an
>> operation. If it is spending most of its time allocating memory then it is
>> quite likely that parallel creations will spend a lot of time competing for
>> the heap spinlock, and actually there will be little/no speedup compared
>> with serialising the creations. Further, if domain creation can take
>> minutes, it may be that we simply need to go optimise that -- we already
>> found one stupid thing in the heap allocator recently that was burining
>> loads of time during large-memory domain creations, and fixed it for a
>> massive speedup in that particular case.
> 
> I suppose ultimately it is a scalability question.  But Oracle's
> measure of success here is based on how long a human or a tool
> has to wait for confirmation to ensure that a domain will
> successfully launch.  If two domains are launched in parallel
> AND an indication is given that both will succeed, spinning on
> the heaplock a bit just makes for a longer "boot" time, which is
> just a cost of virtualization.  If they are launched in parallel
> and, minutes later (or maybe even 20 seconds later), one or
> both say "oops, I was wrong, there wasn't enough memory, so
> try again", that's not OK for data center operations, especially if
> there really was enough RAM for one, but not for both. Remember,
> in the Oracle environment, we are talking about an administrator/automation
> overseeing possibly hundreds of physical servers, not just a single
> user/server.
> 
> Does that make more sense?

Yes, that makes sense.

> The "claim" approach immediately guarantees success or failure.
> Unless there are enough "stupid things/optimisations" found that
> you would be comfortable putting memory allocation for a domain
> creation in a hypervisor spinlock, there will be a race unless
> an atomic mechanism exists such as "claiming" where
> only simple arithmetic must be done within a hypervisor lock.
> 
> Do you disagree?
> 
>>> and (2) tmem and/or other dynamic
>>> memory mechanisms may be asynchronously absorbing small-but-significant
>>> portions of RAM for other purposes during an attempted domain launch.
>> 
>> This is an argument against allocate-rather-than-reserve? I don't think that
>> makes sense -- so is this instead an argument against
>> reservation-as-a-toolstack-only-mechanism? I'm not actually convinced yet we
>> need reservations *at all*, before we get down to where it should be
>> implemented.
> 
> I'm not sure if we are defining terms the same, so that's hard
> to answer.  If you define "allocation" as "a physical RAM page frame
> number is selected (and possibly the physical page is zeroed)",
> then I'm not sure how your definition of "reservation" differs
> (because that's how increase/decrease_reservation are implemented
> in the hypervisor, right?).
> 
> Or did you mean "allocate-rather-than-claim" (where "allocate" is
> select a specific physical pageframe and "claim" means do accounting
> only?  If so, see the atomicity argument above.
> 
> I'm not just arguing against reservation-as-a-toolstack-mechanism,
> I'm stating I believe unequivocally that reservation-as-a-toolstack-
> only-mechanism and tmem are incompatible.  (Well, not _totally_
> incompatible... the existing workaround, tmem freeze/thaw, works
> but is also single-threaded and has fairly severe unnecessary
> performance repercussions.  So I'd like to solve both problems
> at the same time.)

Okay, so why is tmem incompatible with implementing claims in the toolstack?

 -- Keir

> Dan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 00:17:49 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 00:17:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TSzWI-0003cZ-Cs; Tue, 30 Oct 2012 00:17:26 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TSzWH-0003cU-IM
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 00:17:25 +0000
Received: from [193.109.254.147:40542] by server-14.bemta-14.messagelabs.com
	id 26/30-14517-49C1F805; Tue, 30 Oct 2012 00:17:24 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1351556243!2079779!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19220 invoked from network); 30 Oct 2012 00:17:24 -0000
Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com)
	(74.125.82.41)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 00:17:24 -0000
Received: by mail-wg0-f41.google.com with SMTP id ds1so1912008wgb.2
	for ; Mon, 29 Oct 2012 17:17:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=OA5Koqb5TzWUmv5NvyZ/s4P/ECQAOSeRQxRnV4zxJSA=;
	b=l0OWYStQ3qWDcwMPTrRgmr6hJNJEfAel849MXfgDfajfFU16gqnB8mJUgltFZ3/J5n
	eYoLSJFAYtRkFSgNMGB5uLzWU+K9dN2a1aoqZ70ygiMP4m1GziubXTh5Ht0gWCmVM773
	DsjtBjDGR009r0FXxMwPYM4X62whS2hWI/IXtTPsiOTAd1STBp4AIR0/RXbod8ev1ZGd
	TsA2QGpQLHEOxNF40bmzfmXs+310BG3CiZm3A1ZcFjba0GMnP0rGOkmuJQFgQvBQB0v3
	/Y7fuRczTECw3q6vdwp48rGYnr5oJ0FPUfK8pFeAaOcLj/gcWlsqzDqIBnfNluOwIE57
	vNug==
Received: by 10.180.75.161 with SMTP id d1mr17609519wiw.19.1351556243799;
	Mon, 29 Oct 2012 17:17:23 -0700 (PDT)
Received: from [192.168.1.88] (host86-178-46-35.range86-178.btcentralplus.com.
	[86.178.46.35])
	by mx.google.com with ESMTPS id o3sm9659920wiz.9.2012.10.29.17.17.18
	(version=SSLv3 cipher=OTHER); Mon, 29 Oct 2012 17:17:23 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Tue, 30 Oct 2012 00:17:12 +0100
From: Keir Fraser 
To: Dan Magenheimer ,
	Jan Beulich 
Message-ID: 
Thread-Topic: Proposed new "memory capacity claim" hypercall/feature
Thread-Index: Ac22M+hE+Q2v9f9VvUOEGjMYtQGLXw==
In-Reply-To: <806ef32a-2ded-42b5-a2ff-5f84ac1c1d47@default>
Mime-version: 1.0
Cc: Olaf Hering , Ian Campbell ,
	Konrad Rzeszutek Wilk ,
	George Dunlap ,
	George Shuklin ,
	"Tim \(Xen.org\)" , xen-devel@lists.xen.org,
	Dario Faggioli , Kurt Hackel ,
	Zhigang Wang ,
	Ian Jackson 
Subject: Re: [Xen-devel] Proposed new "memory capacity claim"
	hypercall/feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 30/10/2012 00:03, "Dan Magenheimer"  wrote:

>> From: Keir Fraser [mailto:keir@xen.org]
>> Subject: Re: Proposed new "memory capacity claim" hypercall/feature
>> 
>> On 29/10/2012 21:08, "Dan Magenheimer"  wrote:
>> 
>> Well it does depend how scalable domain creation actually is as an
>> operation. If it is spending most of its time allocating memory then it is
>> quite likely that parallel creations will spend a lot of time competing for
>> the heap spinlock, and actually there will be little/no speedup compared
>> with serialising the creations. Further, if domain creation can take
>> minutes, it may be that we simply need to go optimise that -- we already
>> found one stupid thing in the heap allocator recently that was burining
>> loads of time during large-memory domain creations, and fixed it for a
>> massive speedup in that particular case.
> 
> I suppose ultimately it is a scalability question.  But Oracle's
> measure of success here is based on how long a human or a tool
> has to wait for confirmation to ensure that a domain will
> successfully launch.  If two domains are launched in parallel
> AND an indication is given that both will succeed, spinning on
> the heaplock a bit just makes for a longer "boot" time, which is
> just a cost of virtualization.  If they are launched in parallel
> and, minutes later (or maybe even 20 seconds later), one or
> both say "oops, I was wrong, there wasn't enough memory, so
> try again", that's not OK for data center operations, especially if
> there really was enough RAM for one, but not for both. Remember,
> in the Oracle environment, we are talking about an administrator/automation
> overseeing possibly hundreds of physical servers, not just a single
> user/server.
> 
> Does that make more sense?

Yes, that makes sense.

> The "claim" approach immediately guarantees success or failure.
> Unless there are enough "stupid things/optimisations" found that
> you would be comfortable putting memory allocation for a domain
> creation in a hypervisor spinlock, there will be a race unless
> an atomic mechanism exists such as "claiming" where
> only simple arithmetic must be done within a hypervisor lock.
> 
> Do you disagree?
> 
>>> and (2) tmem and/or other dynamic
>>> memory mechanisms may be asynchronously absorbing small-but-significant
>>> portions of RAM for other purposes during an attempted domain launch.
>> 
>> This is an argument against allocate-rather-than-reserve? I don't think that
>> makes sense -- so is this instead an argument against
>> reservation-as-a-toolstack-only-mechanism? I'm not actually convinced yet we
>> need reservations *at all*, before we get down to where it should be
>> implemented.
> 
> I'm not sure if we are defining terms the same, so that's hard
> to answer.  If you define "allocation" as "a physical RAM page frame
> number is selected (and possibly the physical page is zeroed)",
> then I'm not sure how your definition of "reservation" differs
> (because that's how increase/decrease_reservation are implemented
> in the hypervisor, right?).
> 
> Or did you mean "allocate-rather-than-claim" (where "allocate" is
> select a specific physical pageframe and "claim" means do accounting
> only?  If so, see the atomicity argument above.
> 
> I'm not just arguing against reservation-as-a-toolstack-mechanism,
> I'm stating I believe unequivocally that reservation-as-a-toolstack-
> only-mechanism and tmem are incompatible.  (Well, not _totally_
> incompatible... the existing workaround, tmem freeze/thaw, works
> but is also single-threaded and has fairly severe unnecessary
> performance repercussions.  So I'd like to solve both problems
> at the same time.)

Okay, so why is tmem incompatible with implementing claims in the toolstack?

 -- Keir

> Dan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 00:57:26 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 00:57:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT08X-0003uV-Lo; Tue, 30 Oct 2012 00:56:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT08W-0003uQ-5t
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 00:56:56 +0000
Received: from [85.158.139.211:34893] by server-3.bemta-5.messagelabs.com id
	FC/14-28618-7D52F805; Tue, 30 Oct 2012 00:56:55 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1351558614!18152502!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjI0OTA1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9616 invoked from network); 30 Oct 2012 00:56:54 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-16.tower-206.messagelabs.com with SMTP;
	30 Oct 2012 00:56:54 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 29 Oct 2012 17:56:53 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,675,1344236400"; d="scan'208";a="210991589"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by azsmga001.ch.intel.com with ESMTP; 29 Oct 2012 17:56:52 -0700
Received: from fmsmsx102.amr.corp.intel.com (10.19.9.53) by
	FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 29 Oct 2012 17:56:52 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX102.amr.corp.intel.com (10.19.9.53) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 29 Oct 2012 17:56:52 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.123]) with mapi id
	14.01.0355.002; Tue, 30 Oct 2012 08:56:50 +0800
From: "Zhang, Yang Z" 
To: Wei Wang , "xen-devel@lists.xensource.com"
	, Ian Campbell ,
	Ian Jackson , Jan Beulich ,
	Keir Fraser 
Thread-Topic: [Xen-devel] [PATCH 2 of 6 V6] amd iommu: call
	guest_iommu_set_base	from hvmloader
Thread-Index: AQHNm/XFR76YU1rhU0qFmiBjXgBxTJfROvAA
Date: Tue, 30 Oct 2012 00:56:49 +0000
Message-ID: 
References: <5063155A.4070307@amd.com>
In-Reply-To: <5063155A.4070307@amd.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH 2 of 6 V6] amd iommu: call
 guest_iommu_set_base	from hvmloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Wei Wang wrote on 2012-09-26:
>
@@ -3834,6 +3835,9 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
             case HVM_PARAM_BUFIOREQ_EVTCHN:
                 rc = -EINVAL;
                 break;
+            case HVM_PARAM_IOMMU_BASE:
+                rc = guest_iommu_set_base(d, a.value);
+                break;
             }
 
             if ( rc == 0 )

We also have the same function. It's better to use platform specific ops to call it in common file and just leave it as null in intel platform.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 00:57:26 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 00:57:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT08X-0003uV-Lo; Tue, 30 Oct 2012 00:56:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT08W-0003uQ-5t
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 00:56:56 +0000
Received: from [85.158.139.211:34893] by server-3.bemta-5.messagelabs.com id
	FC/14-28618-7D52F805; Tue, 30 Oct 2012 00:56:55 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1351558614!18152502!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjI0OTA1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9616 invoked from network); 30 Oct 2012 00:56:54 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-16.tower-206.messagelabs.com with SMTP;
	30 Oct 2012 00:56:54 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 29 Oct 2012 17:56:53 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,675,1344236400"; d="scan'208";a="210991589"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by azsmga001.ch.intel.com with ESMTP; 29 Oct 2012 17:56:52 -0700
Received: from fmsmsx102.amr.corp.intel.com (10.19.9.53) by
	FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 29 Oct 2012 17:56:52 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX102.amr.corp.intel.com (10.19.9.53) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 29 Oct 2012 17:56:52 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.123]) with mapi id
	14.01.0355.002; Tue, 30 Oct 2012 08:56:50 +0800
From: "Zhang, Yang Z" 
To: Wei Wang , "xen-devel@lists.xensource.com"
	, Ian Campbell ,
	Ian Jackson , Jan Beulich ,
	Keir Fraser 
Thread-Topic: [Xen-devel] [PATCH 2 of 6 V6] amd iommu: call
	guest_iommu_set_base	from hvmloader
Thread-Index: AQHNm/XFR76YU1rhU0qFmiBjXgBxTJfROvAA
Date: Tue, 30 Oct 2012 00:56:49 +0000
Message-ID: 
References: <5063155A.4070307@amd.com>
In-Reply-To: <5063155A.4070307@amd.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH 2 of 6 V6] amd iommu: call
 guest_iommu_set_base	from hvmloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Wei Wang wrote on 2012-09-26:
>
@@ -3834,6 +3835,9 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
             case HVM_PARAM_BUFIOREQ_EVTCHN:
                 rc = -EINVAL;
                 break;
+            case HVM_PARAM_IOMMU_BASE:
+                rc = guest_iommu_set_base(d, a.value);
+                break;
             }
 
             if ( rc == 0 )

We also have the same function. It's better to use platform specific ops to call it in common file and just leave it as null in intel platform.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 01:59:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 01:59:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT16Y-00088N-Mm; Tue, 30 Oct 2012 01:58:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT16X-00088I-AQ
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 01:58:57 +0000
Received: from [85.158.139.211:59417] by server-5.bemta-5.messagelabs.com id
	58/0F-09732-0643F805; Tue, 30 Oct 2012 01:58:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1351562335!18156018!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10903 invoked from network); 30 Oct 2012 01:58:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 01:58:56 -0000
X-IronPort-AV: E=Sophos;i="4.80,676,1344211200"; d="scan'208";a="15477995"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 01:58:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 30 Oct 2012 01:58:54 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TT16U-00031e-93;
	Tue, 30 Oct 2012 01:58:54 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TT16T-0004Lt-Pp;
	Tue, 30 Oct 2012 01:58:53 +0000
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Tue, 30 Oct 2012 01:58:53 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 14150: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14150 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14150/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl             9 guest-start               fail REGR. vs. 14076
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 14076
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 14076
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 14076

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore         fail REGR. vs. 14076

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  2bca7e58a3df
baseline version:
 xen                  40ccbee890e1

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla 
  Bastian Blank 
  Chuang Cao 
  George Dunlap 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jason McCarver 
  Joe Jin 
  Keir Fraser 
  Matt Wilson 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Sander Eikelenboom 
  Stefano Stabellini 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 632 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 01:59:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 01:59:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT16Y-00088N-Mm; Tue, 30 Oct 2012 01:58:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT16X-00088I-AQ
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 01:58:57 +0000
Received: from [85.158.139.211:59417] by server-5.bemta-5.messagelabs.com id
	58/0F-09732-0643F805; Tue, 30 Oct 2012 01:58:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1351562335!18156018!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10903 invoked from network); 30 Oct 2012 01:58:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 01:58:56 -0000
X-IronPort-AV: E=Sophos;i="4.80,676,1344211200"; d="scan'208";a="15477995"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 01:58:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 30 Oct 2012 01:58:54 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TT16U-00031e-93;
	Tue, 30 Oct 2012 01:58:54 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TT16T-0004Lt-Pp;
	Tue, 30 Oct 2012 01:58:53 +0000
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Tue, 30 Oct 2012 01:58:53 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 14150: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14150 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14150/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl             9 guest-start               fail REGR. vs. 14076
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 14076
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 14076
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 14076

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore         fail REGR. vs. 14076

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  2bca7e58a3df
baseline version:
 xen                  40ccbee890e1

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla 
  Bastian Blank 
  Chuang Cao 
  George Dunlap 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jason McCarver 
  Joe Jin 
  Keir Fraser 
  Matt Wilson 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Sander Eikelenboom 
  Stefano Stabellini 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 632 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 04:01:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 04:01:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT312-000117-Gd; Tue, 30 Oct 2012 04:01:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT310-00010m-KZ
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 04:01:22 +0000
Received: from [85.158.139.83:35515] by server-15.bemta-5.messagelabs.com id
	D1/A8-26920-1115F805; Tue, 30 Oct 2012 04:01:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1351569681!27607108!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27370 invoked from network); 30 Oct 2012 04:01:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 04:01:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,677,1344211200"; d="scan'208";a="15478575"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 04:01:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 30 Oct 2012 04:01:20 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TT30y-0003iL-0W;
	Tue, 30 Oct 2012 04:01:20 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TT30x-00066I-R9;
	Tue, 30 Oct 2012 04:01:19 +0000
To: 
Message-ID: 
From: xen.org 
Date: Tue, 30 Oct 2012 04:01:19 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14151: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14151 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14151/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 14079
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 14079
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 14079
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 14079

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  10feb0933708
baseline version:
 xen                  c26e1a79fe77

------------------------------------------------------------
People who touched revisions under test:
  Charles Arnold 
  Christoph Egger 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=10feb0933708
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 10feb0933708
+ branch=xen-unstable
+ revision=10feb0933708
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 10feb0933708 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 8 changesets with 28 changes to 15 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 04:01:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 04:01:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT312-000117-Gd; Tue, 30 Oct 2012 04:01:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT310-00010m-KZ
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 04:01:22 +0000
Received: from [85.158.139.83:35515] by server-15.bemta-5.messagelabs.com id
	D1/A8-26920-1115F805; Tue, 30 Oct 2012 04:01:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1351569681!27607108!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27370 invoked from network); 30 Oct 2012 04:01:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 04:01:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,677,1344211200"; d="scan'208";a="15478575"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 04:01:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 30 Oct 2012 04:01:20 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TT30y-0003iL-0W;
	Tue, 30 Oct 2012 04:01:20 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TT30x-00066I-R9;
	Tue, 30 Oct 2012 04:01:19 +0000
To: 
Message-ID: 
From: xen.org 
Date: Tue, 30 Oct 2012 04:01:19 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14151: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14151 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14151/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 14079
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 14079
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 14079
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 14079

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  10feb0933708
baseline version:
 xen                  c26e1a79fe77

------------------------------------------------------------
People who touched revisions under test:
  Charles Arnold 
  Christoph Egger 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=10feb0933708
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 10feb0933708
+ branch=xen-unstable
+ revision=10feb0933708
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 10feb0933708 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 8 changesets with 28 changes to 15 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 06:54:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 06:54:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT5hv-00029p-SY; Tue, 30 Oct 2012 06:53:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT5hu-00029k-DE
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 06:53:50 +0000
Received: from [85.158.143.99:12581] by server-1.bemta-4.messagelabs.com id
	6D/65-19134-D797F805; Tue, 30 Oct 2012 06:53:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1351580027!22623265!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODIyMjc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16530 invoked from network); 30 Oct 2012 06:53:48 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 06:53:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,677,1344211200"; d="scan'208";a="212819759"
Received: from unknown (HELO FTLPEX01CL03.citrite.net) ([10.13.107.80])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	30 Oct 2012 06:53:46 +0000
Received: from [127.0.0.1] (10.80.16.67) by FTLPEX01CL03.citrite.net
	(10.13.107.77) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 30 Oct 2012 02:53:45 -0400
Message-ID: <1351579909.16868.7.camel@hastur.hellion.org.uk>
From: Ian Campbell 
To: kbuild test robot , Konrad Rzeszutek Wilk
	
Date: Tue, 30 Oct 2012 07:51:49 +0100
In-Reply-To: <508f5e30.nBE8jAB0oQuFgwhi%fengguang.wu@intel.com>
References: <508f5e30.nBE8jAB0oQuFgwhi%fengguang.wu@intel.com>
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
X-Originating-IP: [10.80.16.67]
Cc: xen-devel 
Subject: Re: [Xen-devel] [xen:devel/pvh.v6 12/14]
 include/xen/xen-ops.h:29:11: error: unknown type name 'xen_pfn_t'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-30 at 04:57 +0000, kbuild test robot wrote:
> tree:   git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git devel/pvh.v6
> head:   a50658f644f72b42da86c9fd98bafc29fe00c039
> commit: 3b4afca66dc25918f6a48f30712a9dfec042fdf3 [12/14] xen: correctly use xen_pfn_t in remap_domain_mfn_range.
> config: x86_64-randconfig-x370 (attached as .config)
> 
> All error/warnings:
> 
> In file included from arch/x86/xen/xen-ops.h:7:0,
>                  from arch/x86/xen/platform-pci-unplug.c:27:
> include/xen/xen-ops.h:29:11: error: unknown type name 'xen_pfn_t'

Thanks Fengguang.

Konrad, here is the fix. If this is in a rebasing branch feel free to
fold into the relevant patch.

8<-------------------------------------------------------

>From 197db260e4821cb21cbd0a5f4f0b298ca9b05672 Mon Sep 17 00:00:00 2001
From: Ian Campbell 
Date: Tue, 30 Oct 2012 07:49:39 +0100
Subject: [PATCH] xen: include correct header for xen_pfn_t definition.

Fixes build breakage:

In file included from arch/x86/xen/xen-ops.h:7:0,
                 from arch/x86/xen/platform-pci-unplug.c:27:
include/xen/xen-ops.h:29:11: error: unknown type name 'xen_pfn_t'

Signed-off-by: Ian Campbell 
Reported-by: Fengguang Wu 
---
 include/xen/xen-ops.h |    1 +
 1 file changed, 1 insertion(+)

diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index ee188eb..a50e7be 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -2,6 +2,7 @@
 #define INCLUDE_XEN_OPS_H
 
 #include 
+#include 
 
 DECLARE_PER_CPU(struct vcpu_info *, xen_vcpu);
 
-- 
1.7.10.4




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 06:54:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 06:54:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT5hv-00029p-SY; Tue, 30 Oct 2012 06:53:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT5hu-00029k-DE
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 06:53:50 +0000
Received: from [85.158.143.99:12581] by server-1.bemta-4.messagelabs.com id
	6D/65-19134-D797F805; Tue, 30 Oct 2012 06:53:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1351580027!22623265!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODIyMjc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16530 invoked from network); 30 Oct 2012 06:53:48 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 06:53:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,677,1344211200"; d="scan'208";a="212819759"
Received: from unknown (HELO FTLPEX01CL03.citrite.net) ([10.13.107.80])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	30 Oct 2012 06:53:46 +0000
Received: from [127.0.0.1] (10.80.16.67) by FTLPEX01CL03.citrite.net
	(10.13.107.77) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 30 Oct 2012 02:53:45 -0400
Message-ID: <1351579909.16868.7.camel@hastur.hellion.org.uk>
From: Ian Campbell 
To: kbuild test robot , Konrad Rzeszutek Wilk
	
Date: Tue, 30 Oct 2012 07:51:49 +0100
In-Reply-To: <508f5e30.nBE8jAB0oQuFgwhi%fengguang.wu@intel.com>
References: <508f5e30.nBE8jAB0oQuFgwhi%fengguang.wu@intel.com>
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
X-Originating-IP: [10.80.16.67]
Cc: xen-devel 
Subject: Re: [Xen-devel] [xen:devel/pvh.v6 12/14]
 include/xen/xen-ops.h:29:11: error: unknown type name 'xen_pfn_t'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-30 at 04:57 +0000, kbuild test robot wrote:
> tree:   git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git devel/pvh.v6
> head:   a50658f644f72b42da86c9fd98bafc29fe00c039
> commit: 3b4afca66dc25918f6a48f30712a9dfec042fdf3 [12/14] xen: correctly use xen_pfn_t in remap_domain_mfn_range.
> config: x86_64-randconfig-x370 (attached as .config)
> 
> All error/warnings:
> 
> In file included from arch/x86/xen/xen-ops.h:7:0,
>                  from arch/x86/xen/platform-pci-unplug.c:27:
> include/xen/xen-ops.h:29:11: error: unknown type name 'xen_pfn_t'

Thanks Fengguang.

Konrad, here is the fix. If this is in a rebasing branch feel free to
fold into the relevant patch.

8<-------------------------------------------------------

>From 197db260e4821cb21cbd0a5f4f0b298ca9b05672 Mon Sep 17 00:00:00 2001
From: Ian Campbell 
Date: Tue, 30 Oct 2012 07:49:39 +0100
Subject: [PATCH] xen: include correct header for xen_pfn_t definition.

Fixes build breakage:

In file included from arch/x86/xen/xen-ops.h:7:0,
                 from arch/x86/xen/platform-pci-unplug.c:27:
include/xen/xen-ops.h:29:11: error: unknown type name 'xen_pfn_t'

Signed-off-by: Ian Campbell 
Reported-by: Fengguang Wu 
---
 include/xen/xen-ops.h |    1 +
 1 file changed, 1 insertion(+)

diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index ee188eb..a50e7be 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -2,6 +2,7 @@
 #define INCLUDE_XEN_OPS_H
 
 #include 
+#include 
 
 DECLARE_PER_CPU(struct vcpu_info *, xen_vcpu);
 
-- 
1.7.10.4




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 07:43:21 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 07:43:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT6TK-0002gk-66; Tue, 30 Oct 2012 07:42:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT6TI-0002gf-6W
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 07:42:48 +0000
Received: from [85.158.143.35:22611] by server-2.bemta-4.messagelabs.com id
	5E/37-22268-7F48F805; Tue, 30 Oct 2012 07:42:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1351582963!11632720!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzk3Mjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11972 invoked from network); 30 Oct 2012 07:42:44 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 07:42:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,677,1344211200"; d="scan'208";a="42844625"
Received: from unknown (HELO FTLPEX01CL03.citrite.net) ([10.13.107.80])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	30 Oct 2012 07:42:42 +0000
Received: from [127.0.0.1] (10.80.16.67) by FTLPEX01CL03.citrite.net
	(10.13.107.77) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 30 Oct 2012 03:42:41 -0400
Message-ID: <1351582845.16868.8.camel@hastur.hellion.org.uk>
From: Ian Campbell 
To: Thanos Makatos 
Date: Tue, 30 Oct 2012 08:40:45 +0100
In-Reply-To: <4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8C60@LONPMAILBOX01.citrite.net>
References: 
	
	<1351250500.15162.40.camel@zakaz.uk.xensource.com>
	<4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8C60@LONPMAILBOX01.citrite.net>
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
X-Originating-IP: [10.80.16.67]
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 04 of 16 RFC] blktap3: change
 libxl__blktap_devpath prototype to return an error code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-10-29 at 17:41 +0000, Thanos Makatos wrote:
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: 26 October 2012 12:22
> > To: Thanos Makatos
> > Cc: xen-devel@lists.xensource.com
> > Subject: Re: [Xen-devel] [PATCH 04 of 16 RFC] blktap3: change
> > libxl__blktap_devpath prototype to return an error code
> > 
> > On Wed, 2012-10-24 at 18:02 +0100, Thanos Makatos wrote:
> > > Make libxl__blktap_devpath return an error code instead of the
> > device,
> > > since there is no device in dom0 any more.
> > 
> > Does this function eventually go away then? Or will it eventually
> > return some sort of metadata which can be used to connect to the
> > created tap device?
> 
> As in blktap2, it creates the tapdisk process, but doesn't return any
> metadata, so it's still required. I guess changing the name of the
> function would clarify it.

Yes, I think that would be helpful.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 07:43:21 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 07:43:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT6TK-0002gk-66; Tue, 30 Oct 2012 07:42:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT6TI-0002gf-6W
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 07:42:48 +0000
Received: from [85.158.143.35:22611] by server-2.bemta-4.messagelabs.com id
	5E/37-22268-7F48F805; Tue, 30 Oct 2012 07:42:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1351582963!11632720!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzk3Mjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11972 invoked from network); 30 Oct 2012 07:42:44 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 07:42:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,677,1344211200"; d="scan'208";a="42844625"
Received: from unknown (HELO FTLPEX01CL03.citrite.net) ([10.13.107.80])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	30 Oct 2012 07:42:42 +0000
Received: from [127.0.0.1] (10.80.16.67) by FTLPEX01CL03.citrite.net
	(10.13.107.77) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 30 Oct 2012 03:42:41 -0400
Message-ID: <1351582845.16868.8.camel@hastur.hellion.org.uk>
From: Ian Campbell 
To: Thanos Makatos 
Date: Tue, 30 Oct 2012 08:40:45 +0100
In-Reply-To: <4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8C60@LONPMAILBOX01.citrite.net>
References: 
	
	<1351250500.15162.40.camel@zakaz.uk.xensource.com>
	<4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8C60@LONPMAILBOX01.citrite.net>
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
X-Originating-IP: [10.80.16.67]
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 04 of 16 RFC] blktap3: change
 libxl__blktap_devpath prototype to return an error code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-10-29 at 17:41 +0000, Thanos Makatos wrote:
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: 26 October 2012 12:22
> > To: Thanos Makatos
> > Cc: xen-devel@lists.xensource.com
> > Subject: Re: [Xen-devel] [PATCH 04 of 16 RFC] blktap3: change
> > libxl__blktap_devpath prototype to return an error code
> > 
> > On Wed, 2012-10-24 at 18:02 +0100, Thanos Makatos wrote:
> > > Make libxl__blktap_devpath return an error code instead of the
> > device,
> > > since there is no device in dom0 any more.
> > 
> > Does this function eventually go away then? Or will it eventually
> > return some sort of metadata which can be used to connect to the
> > created tap device?
> 
> As in blktap2, it creates the tapdisk process, but doesn't return any
> metadata, so it's still required. I guess changing the name of the
> function would clarify it.

Yes, I think that would be helpful.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 07:44:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 07:44:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT6UD-0002jH-L1; Tue, 30 Oct 2012 07:43:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT6UC-0002j9-Ou
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 07:43:44 +0000
Received: from [85.158.139.211:55102] by server-12.bemta-5.messagelabs.com id
	20/27-26919-F258F805; Tue, 30 Oct 2012 07:43:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1351583021!18111811!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODIyMjc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14142 invoked from network); 30 Oct 2012 07:43:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 07:43:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,677,1344211200"; d="scan'208";a="212822220"
Received: from unknown (HELO FTLPEX01CL03.citrite.net) ([10.13.107.80])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	30 Oct 2012 07:43:40 +0000
Received: from [127.0.0.1] (10.80.16.67) by FTLPEX01CL03.citrite.net
	(10.13.107.77) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 30 Oct 2012 03:43:40 -0400
Message-ID: <1351582903.16868.9.camel@hastur.hellion.org.uk>
From: Ian Campbell 
To: Thanos Makatos 
Date: Tue, 30 Oct 2012 08:41:43 +0100
In-Reply-To: <4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8C61@LONPMAILBOX01.citrite.net>
References: 
	<57896068356d4870c74a.1351098144@makatos-desktop>
	<1351250625.15162.42.camel@zakaz.uk.xensource.com>
	<4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8C61@LONPMAILBOX01.citrite.net>
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
X-Originating-IP: [10.80.16.67]
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 05 of 16 RFC] blktap3: Don't check if blktap
 is available
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > 
> > Perhaps even on Linux we would want a sanity check that the drivers are
> > present and loaded etc?
> 
> We could ensure that the tapdisk binaries are present, apart from that
> I don't see anything else we could check.

Could we check for /dev/xen/{evtchn,gntdev,...} or whatever else it
needs?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 07:44:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 07:44:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT6UD-0002jH-L1; Tue, 30 Oct 2012 07:43:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT6UC-0002j9-Ou
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 07:43:44 +0000
Received: from [85.158.139.211:55102] by server-12.bemta-5.messagelabs.com id
	20/27-26919-F258F805; Tue, 30 Oct 2012 07:43:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1351583021!18111811!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODIyMjc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14142 invoked from network); 30 Oct 2012 07:43:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 07:43:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,677,1344211200"; d="scan'208";a="212822220"
Received: from unknown (HELO FTLPEX01CL03.citrite.net) ([10.13.107.80])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	30 Oct 2012 07:43:40 +0000
Received: from [127.0.0.1] (10.80.16.67) by FTLPEX01CL03.citrite.net
	(10.13.107.77) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 30 Oct 2012 03:43:40 -0400
Message-ID: <1351582903.16868.9.camel@hastur.hellion.org.uk>
From: Ian Campbell 
To: Thanos Makatos 
Date: Tue, 30 Oct 2012 08:41:43 +0100
In-Reply-To: <4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8C61@LONPMAILBOX01.citrite.net>
References: 
	<57896068356d4870c74a.1351098144@makatos-desktop>
	<1351250625.15162.42.camel@zakaz.uk.xensource.com>
	<4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8C61@LONPMAILBOX01.citrite.net>
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
X-Originating-IP: [10.80.16.67]
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 05 of 16 RFC] blktap3: Don't check if blktap
 is available
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > 
> > Perhaps even on Linux we would want a sanity check that the drivers are
> > present and loaded etc?
> 
> We could ensure that the tapdisk binaries are present, apart from that
> I don't see anything else we could check.

Could we check for /dev/xen/{evtchn,gntdev,...} or whatever else it
needs?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 07:46:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 07:46:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT6WR-0002rk-7H; Tue, 30 Oct 2012 07:46:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT6WQ-0002rX-1m
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 07:46:02 +0000
Received: from [193.109.254.147:63875] by server-3.bemta-14.messagelabs.com id
	89/35-04486-9B58F805; Tue, 30 Oct 2012 07:46:01 +0000
X-Env-Sender: zpengxen@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1351583123!2062480!1
X-Originating-IP: [209.85.223.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16597 invoked from network); 30 Oct 2012 07:45:24 -0000
Received: from mail-ie0-f171.google.com (HELO mail-ie0-f171.google.com)
	(209.85.223.171)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 07:45:24 -0000
Received: by mail-ie0-f171.google.com with SMTP id s9so9918225iec.30
	for ;
	Tue, 30 Oct 2012 00:45:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=UtxLev6Ng8PecfmrnzhJjP8wCTSRbdbrHZ2RoErFwwY=;
	b=pnYjatnGiDe2WmxuSaicVjjP7R4RmMpbZdcBDwMlwdrkmOFje9qHm0qZipZBLqCEXb
	ZX5oueWgNEtzqLn/5oDnRJvj/VT6O6JV1YvyzsY3j12EP2PiCmrue9tdfqpSVEFzE9z6
	34tGNxPxzXfbFQx93VR6Q+meBfkSRzHOtlAMq2tVaA0S6H+zzaTcB/j7Q1wLufR6j1SK
	U1GudLpqN1XnUVfkoxIP3Ft6B80xGgTeXusJ5ZzNJjcwsUwISXmQqCv8nF5HNNn3pSa/
	woynP7pMZr7gCRn4nJIn5axkPo604mSOO3dikvIS4B5GKLJF7XIGvW69AkxhGBNvr25+
	chdw==
MIME-Version: 1.0
Received: by 10.50.33.147 with SMTP id r19mr626099igi.73.1351583123433; Tue,
	30 Oct 2012 00:45:23 -0700 (PDT)
Received: by 10.50.236.104 with HTTP; Tue, 30 Oct 2012 00:45:23 -0700 (PDT)
In-Reply-To: <5087EC58.8040904@eu.citrix.com>
References: 
	<1338987918.32319.84.camel@zakaz.uk.xensource.com>
	
	<1339049291.6557.11.camel@dagon.hellion.org.uk>
	
	<1341325462.21547.20.camel@zakaz.uk.xensource.com>
	
	
	
	<508559E8.10102@eu.citrix.com>
	
	<5087EC58.8040904@eu.citrix.com>
Date: Tue, 30 Oct 2012 15:45:23 +0800
Message-ID: 
From: ZhouPeng 
To: Ian Campbell 
Cc: George Dunlap ,
	"Xen-Devel \(E-mail\)" ,
	Ian Jackson ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 2/3] tools:libxl: Add qxl vga interface
 support v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

cGluZyBJYW4gQwpPbiBXZWQsIE9jdCAyNCwgMjAxMiBhdCA5OjI1IFBNLCBHZW9yZ2UgRHVubGFw
CjxnZW9yZ2UuZHVubGFwQGV1LmNpdHJpeC5jb20+IHdyb3RlOgo+IE9uIDI0LzEwLzEyIDA5OjA2
LCBaaG91UGVuZyB3cm90ZToKPj4KPj4gQ2FuIGJlIGNoYW5nZWQuQnV0IElhbiBDYW1wYmVsbCBh
bmQgbWUgaGF2ZSB0YWxrZWQgb24gc3RoIHJlbGF0ZWQgd2l0aAo+PiB0aGlzCj4+Cj4+IGNsb3Nl
bHkgYmVmb3JlLiBBbmQgd2UgYm90aCBhZ3JlZSB0byBqdXN0IHN1cHBvcnQgdGhlIGRlZmF1bHQg
aXMKPj4gZW5vdWdoIGluIG1vc3QgdGltZS4gWW91IGNhbiBnZXQgaXQgZnJvbSB0aGUgdXJsIGJl
bG93IHF1aWNrbHksIHBscwo+PiByZWFkIGZyb20gYm90dG9tIHVwLCB3aGljaCBjYW4gc2F2ZSB0
aW1lLgo+Cj4KPiBPSyAtLSBpbiB0aGF0IGNhc2UsIHY1IGxvb2tzIE9LIHRvIG1lOgo+Cj4gQWNr
ZWQtYnk6IEdlb3JnZSBEdW5sYXAgPGdlb3JnZS5kdW5sYXBAZXUuY2l0cml4LmNvbT4KPgo+IOiw
ouiwou+8jAo+IC1HZW9yZ2UKCgoKLS0gClpob3UgUGVuZwoKX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2
ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Oct 30 07:46:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 07:46:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT6WR-0002rk-7H; Tue, 30 Oct 2012 07:46:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT6WQ-0002rX-1m
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 07:46:02 +0000
Received: from [193.109.254.147:63875] by server-3.bemta-14.messagelabs.com id
	89/35-04486-9B58F805; Tue, 30 Oct 2012 07:46:01 +0000
X-Env-Sender: zpengxen@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1351583123!2062480!1
X-Originating-IP: [209.85.223.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16597 invoked from network); 30 Oct 2012 07:45:24 -0000
Received: from mail-ie0-f171.google.com (HELO mail-ie0-f171.google.com)
	(209.85.223.171)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 07:45:24 -0000
Received: by mail-ie0-f171.google.com with SMTP id s9so9918225iec.30
	for ;
	Tue, 30 Oct 2012 00:45:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=UtxLev6Ng8PecfmrnzhJjP8wCTSRbdbrHZ2RoErFwwY=;
	b=pnYjatnGiDe2WmxuSaicVjjP7R4RmMpbZdcBDwMlwdrkmOFje9qHm0qZipZBLqCEXb
	ZX5oueWgNEtzqLn/5oDnRJvj/VT6O6JV1YvyzsY3j12EP2PiCmrue9tdfqpSVEFzE9z6
	34tGNxPxzXfbFQx93VR6Q+meBfkSRzHOtlAMq2tVaA0S6H+zzaTcB/j7Q1wLufR6j1SK
	U1GudLpqN1XnUVfkoxIP3Ft6B80xGgTeXusJ5ZzNJjcwsUwISXmQqCv8nF5HNNn3pSa/
	woynP7pMZr7gCRn4nJIn5axkPo604mSOO3dikvIS4B5GKLJF7XIGvW69AkxhGBNvr25+
	chdw==
MIME-Version: 1.0
Received: by 10.50.33.147 with SMTP id r19mr626099igi.73.1351583123433; Tue,
	30 Oct 2012 00:45:23 -0700 (PDT)
Received: by 10.50.236.104 with HTTP; Tue, 30 Oct 2012 00:45:23 -0700 (PDT)
In-Reply-To: <5087EC58.8040904@eu.citrix.com>
References: 
	<1338987918.32319.84.camel@zakaz.uk.xensource.com>
	
	<1339049291.6557.11.camel@dagon.hellion.org.uk>
	
	<1341325462.21547.20.camel@zakaz.uk.xensource.com>
	
	
	
	<508559E8.10102@eu.citrix.com>
	
	<5087EC58.8040904@eu.citrix.com>
Date: Tue, 30 Oct 2012 15:45:23 +0800
Message-ID: 
From: ZhouPeng 
To: Ian Campbell 
Cc: George Dunlap ,
	"Xen-Devel \(E-mail\)" ,
	Ian Jackson ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH 2/3] tools:libxl: Add qxl vga interface
 support v2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

cGluZyBJYW4gQwpPbiBXZWQsIE9jdCAyNCwgMjAxMiBhdCA5OjI1IFBNLCBHZW9yZ2UgRHVubGFw
CjxnZW9yZ2UuZHVubGFwQGV1LmNpdHJpeC5jb20+IHdyb3RlOgo+IE9uIDI0LzEwLzEyIDA5OjA2
LCBaaG91UGVuZyB3cm90ZToKPj4KPj4gQ2FuIGJlIGNoYW5nZWQuQnV0IElhbiBDYW1wYmVsbCBh
bmQgbWUgaGF2ZSB0YWxrZWQgb24gc3RoIHJlbGF0ZWQgd2l0aAo+PiB0aGlzCj4+Cj4+IGNsb3Nl
bHkgYmVmb3JlLiBBbmQgd2UgYm90aCBhZ3JlZSB0byBqdXN0IHN1cHBvcnQgdGhlIGRlZmF1bHQg
aXMKPj4gZW5vdWdoIGluIG1vc3QgdGltZS4gWW91IGNhbiBnZXQgaXQgZnJvbSB0aGUgdXJsIGJl
bG93IHF1aWNrbHksIHBscwo+PiByZWFkIGZyb20gYm90dG9tIHVwLCB3aGljaCBjYW4gc2F2ZSB0
aW1lLgo+Cj4KPiBPSyAtLSBpbiB0aGF0IGNhc2UsIHY1IGxvb2tzIE9LIHRvIG1lOgo+Cj4gQWNr
ZWQtYnk6IEdlb3JnZSBEdW5sYXAgPGdlb3JnZS5kdW5sYXBAZXUuY2l0cml4LmNvbT4KPgo+IOiw
ouiwou+8jAo+IC1HZW9yZ2UKCgoKLS0gClpob3UgUGVuZwoKX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2
ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Oct 30 07:59:06 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 07:59:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT6ie-00039a-H6; Tue, 30 Oct 2012 07:58:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT6ic-00039V-B2
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 07:58:38 +0000
Received: from [85.158.139.211:48658] by server-11.bemta-5.messagelabs.com id
	42/A1-14870-DA88F805; Tue, 30 Oct 2012 07:58:37 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1351583915!18155453!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzE2NDk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13811 invoked from network); 30 Oct 2012 07:58:36 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-4.tower-206.messagelabs.com with SMTP;
	30 Oct 2012 07:58:36 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 30 Oct 2012 00:58:35 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,677,1344236400"; d="scan'208";a="234473147"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by orsmga002.jf.intel.com with ESMTP; 30 Oct 2012 00:58:18 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 30 Oct 2012 00:58:17 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.123]) with mapi id
	14.01.0355.002; Tue, 30 Oct 2012 15:58:16 +0800
From: "Liu, Jinsong" 
To: Konrad Rzeszutek Wilk 
Thread-Topic: [Xen-devel] [PATCH 1/2] Xen acpi pad implement
Thread-Index: AQHNtdJ8Ti91BiFLfUibRvXA4zlK85fRdOaA
Date: Tue, 30 Oct 2012 07:58:15 +0000
Message-ID: 
References: 
	<5089676602000078000A4928@nat28.tlf.novell.com>
	
	<508A89CB020000780008E6ED@nat28.tlf.novell.com>
	
	
	<20121026201409.GF2708@phenom.dumpdata.com>
	
	<20121029123950.GK2708@phenom.dumpdata.com>
In-Reply-To: <20121029123950.GK2708@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk ,
	"linux-kernel@vger.kernel.org" ,
	Jan Beulich ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 1/2] Xen acpi pad implement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad Rzeszutek Wilk wrote:
> On Mon, Oct 29, 2012 at 03:38:14AM +0000, Liu, Jinsong wrote:
>> It's doable to register a stub for xen. However, it's not preferred,
>> say, to make xen pad as module, considering the case 'rmmod
>> xen_acpi_pad' then 'insmod acpi_pad'? Under such case there is risk
>> of mwait #UD, if we want to remove mwait check as 'patch 2/2:
>> Revert-pad-config-check-in-xen_check_mwait.patch' did, advantages of
>> which is to enjoy deep Cx.     
> 
> You are missing my point. This is what I was thinking off:
> 
> 
> From 5f30320b8a1c21d60a2c22e98bcf013b7773938b Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk 
> Date: Mon, 29 Oct 2012 08:38:22 -0400
> Subject: [PATCH] xen/acpi: Provide a stub function to register for
>  ACPI PAD module.
> 
> TODO: Give more details.
> 
> Signed-off-by: Konrad Rzeszutek Wilk 
> ---
>  drivers/xen/Kconfig             |    5 ++
>  drivers/xen/Makefile            |    3 +-
>  drivers/xen/xen-acpi-pad-stub.c |  128
>  +++++++++++++++++++++++++++++++++++++++ drivers/xen/xen-acpi.h      
>  |    2 + 4 files changed, 137 insertions(+), 1 deletions(-)
>  create mode 100644 drivers/xen/xen-acpi-pad-stub.c
>  create mode 100644 drivers/xen/xen-acpi.h
> 
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index d4dffcd..9156a08 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -204,4 +204,9 @@ config XEN_MCE_LOG
>  	  Allow kernel fetching MCE error from Xen platform and
>  	  converting it into Linux mcelog format for mcelog tools
> 
> +config XEN_ACPI_PAD_STUB
> +	bool
> +	depends on XEN_DOM0 && X86_64 && ACPI
> +	default n
> +

This Kconfig is pointless, if CONFIG_XEN_ACPI_PAD_STUB = n, native pad would successfully registerred, and then mwait #UD (we would revert df88b2d96e36d9a9e325bfcd12eb45671cbbc937, right?). So xen stub logic should unconditionally built-in kernel.

>  endmenu
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index 0e863703..d1895d9 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -9,9 +9,10 @@ nostackp := $(call cc-option, -fno-stack-protector)
>  CFLAGS_features.o			:= $(nostackp)
> 
>  dom0-$(CONFIG_PCI) += pci.o
> -dom0-$(CONFIG_USB_SUPPORT) += dbgp.o
> +dom0-$(CONFIG_USB_EHCI_HCD) += dbgp.o
>  dom0-$(CONFIG_ACPI) += acpi.o
>  dom0-$(CONFIG_X86) += pcpu.o
> +dom0-$(CONFIG_XEN_ACPI_PAD_STUB)	+= xen-acpi-pad-stub.o
>  obj-$(CONFIG_XEN_DOM0)			+= $(dom0-y)
>  obj-$(CONFIG_BLOCK)			+= biomerge.o
>  obj-$(CONFIG_XEN_XENCOMM)		+= xencomm.o
> diff --git a/drivers/xen/xen-acpi-pad-stub.c
> b/drivers/xen/xen-acpi-pad-stub.c new file mode 100644
> index 0000000..cac9a39
> --- /dev/null
> +++ b/drivers/xen/xen-acpi-pad-stub.c
> @@ -0,0 +1,128 @@
> +/*
> + * Copyright 2012 by Oracle Inc
> + * Author: Konrad Rzeszutek Wilk 
> + *
> + * This code borrows ideas from https://lkml.org/lkml/2011/11/30/249
> + * so many thanks go to Kevin Tian 
> + * and Yu Ke .
> + *
> + * This program is free software; you can redistribute it and/or
> modify it + * under the terms and conditions of the GNU General
> Public License, + * version 2, as published by the Free Software
> Foundation. + *
> + * This program is distributed in the hope it will be useful, but
> WITHOUT + * ANY WARRANTY; without even the implied warranty of
> MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> General Public License for + * more details.
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* TODO: Needs comments. */
> +static struct acpi_device_ops *xen_acpi_pad_ops;
> +static bool __read_mostly xen_acpi_pad_registered;
> +static DEFINE_SPINLOCK(xen_acpi_pad_spinlock);
> +
> +int xen_register_acpi_pad_owner(struct acpi_device_ops *ops)
> +{
> +	if (xen_acpi_pad_ops)
> +		return -EEXIST;
> +
> +	spin_lock(&xen_acpi_pad_spinlock);
> +	xen_acpi_pad_ops = ops;
> +	spin_unlock(&xen_acpi_pad_spinlock);
> +	return 0;
> +}
> +int xen_unregister_acpi_pad_owner(struct acpi_device_ops *ops)
> +{
> +	spin_lock(&xen_acpi_pad_spinlock);
> +	if (xen_acpi_pad_ops != ops) {
> +		spin_unlock(&xen_acpi_pad_spinlock);
> +		return -ENODEV;
> +	}
> +	xen_acpi_pad_ops = NULL;
> +	spin_unlock(&xen_acpi_pad_spinlock);
> +	return 0;
> +}
> +
> +static int xen_acpi_pad_remove(struct acpi_device *device, int type)
> +{
> +	int ret = -ENOSYS;
> +
> +	spin_lock(&xen_acpi_pad_spinlock);
> +	if (xen_acpi_pad_ops && xen_acpi_pad_ops->remove)
> +		ret = xen_acpi_pad_ops->remove(device, type);
> +	spin_unlock(&xen_acpi_pad_spinlock);
> +	return ret;
> +}
> +static int xen_acpi_pad_add(struct acpi_device *device)
> +{
> +	int ret = -ENOSYS;
> +	spin_lock(&xen_acpi_pad_spinlock);
> +	if (xen_acpi_pad_ops && xen_acpi_pad_ops->add)
> +		ret = xen_acpi_pad_ops->add(device);
> +	spin_unlock(&xen_acpi_pad_spinlock);
> +	return ret;
> +}
> +
> +static const struct acpi_device_id pad_device_ids[] = {
> +	{"ACPI000C", 0},
> +	{"", 0},
> +};
> +MODULE_DEVICE_TABLE(acpi, pad_device_ids);
> +#define ACPI_PROCESSOR_AGGREGATOR_CLASS "acpi_pad"
> +
> +static struct acpi_driver xen_acpi_pad_driver = {
> +	.name = "processor_aggregator",
> +	.class = ACPI_PROCESSOR_AGGREGATOR_CLASS,
> +	.ids = pad_device_ids,
> +	.ops = {
> +		.add = xen_acpi_pad_add,
> +		.remove = xen_acpi_pad_remove,
> +	},
> +};
> +
> +static int __init xen_acpi_pad_stub_init(void)
> +{
> +	int ret = -ENOSYS;
> +	unsigned version;
> +
> +	if (!xen_initial_domain())
> +		return -ENODEV;
> +
> +	version = HYPERVISOR_xen_version(XENVER_version, NULL);
> +
> +	if ((version >> 16 >= 4) && ((version & 0xffff) >= 2)) {
> +        	ret = acpi_bus_register_driver(&xen_acpi_pad_driver);
> +        	if (!ret)
> +			xen_acpi_pad_registered = true;
> +    	}
> +    	return ret;
> +}
> +#if 0
> +/* For testing purposes. */
> +static void __exit xen_acpi_pad_stub_exit(void)
> +{
> +	if (xen_acpi_pad_registered)
> +		acpi_bus_unregister_driver(&xen_acpi_pad_driver);
> +	/* The driver should have unregistered first ! */
> +	if (WARN_ON(xen_acpi_pad_ops))
> +		xen_acpi_pad_ops = NULL;
> +}
> +#endif
> +subsys_initcall(xen_acpi_pad_stub_init);

I'm still confused. In this way there are xen-acpi-pad-stub.c and xen-acpi-pad.c, and you want to let xen-acpi-pad loaded as module, right? how can xen-acpi-pad logic work when it was insmoded?

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 07:59:06 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 07:59:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT6ie-00039a-H6; Tue, 30 Oct 2012 07:58:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT6ic-00039V-B2
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 07:58:38 +0000
Received: from [85.158.139.211:48658] by server-11.bemta-5.messagelabs.com id
	42/A1-14870-DA88F805; Tue, 30 Oct 2012 07:58:37 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1351583915!18155453!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzE2NDk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13811 invoked from network); 30 Oct 2012 07:58:36 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-4.tower-206.messagelabs.com with SMTP;
	30 Oct 2012 07:58:36 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 30 Oct 2012 00:58:35 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,677,1344236400"; d="scan'208";a="234473147"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by orsmga002.jf.intel.com with ESMTP; 30 Oct 2012 00:58:18 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 30 Oct 2012 00:58:17 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.123]) with mapi id
	14.01.0355.002; Tue, 30 Oct 2012 15:58:16 +0800
From: "Liu, Jinsong" 
To: Konrad Rzeszutek Wilk 
Thread-Topic: [Xen-devel] [PATCH 1/2] Xen acpi pad implement
Thread-Index: AQHNtdJ8Ti91BiFLfUibRvXA4zlK85fRdOaA
Date: Tue, 30 Oct 2012 07:58:15 +0000
Message-ID: 
References: 
	<5089676602000078000A4928@nat28.tlf.novell.com>
	
	<508A89CB020000780008E6ED@nat28.tlf.novell.com>
	
	
	<20121026201409.GF2708@phenom.dumpdata.com>
	
	<20121029123950.GK2708@phenom.dumpdata.com>
In-Reply-To: <20121029123950.GK2708@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk ,
	"linux-kernel@vger.kernel.org" ,
	Jan Beulich ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 1/2] Xen acpi pad implement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad Rzeszutek Wilk wrote:
> On Mon, Oct 29, 2012 at 03:38:14AM +0000, Liu, Jinsong wrote:
>> It's doable to register a stub for xen. However, it's not preferred,
>> say, to make xen pad as module, considering the case 'rmmod
>> xen_acpi_pad' then 'insmod acpi_pad'? Under such case there is risk
>> of mwait #UD, if we want to remove mwait check as 'patch 2/2:
>> Revert-pad-config-check-in-xen_check_mwait.patch' did, advantages of
>> which is to enjoy deep Cx.     
> 
> You are missing my point. This is what I was thinking off:
> 
> 
> From 5f30320b8a1c21d60a2c22e98bcf013b7773938b Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk 
> Date: Mon, 29 Oct 2012 08:38:22 -0400
> Subject: [PATCH] xen/acpi: Provide a stub function to register for
>  ACPI PAD module.
> 
> TODO: Give more details.
> 
> Signed-off-by: Konrad Rzeszutek Wilk 
> ---
>  drivers/xen/Kconfig             |    5 ++
>  drivers/xen/Makefile            |    3 +-
>  drivers/xen/xen-acpi-pad-stub.c |  128
>  +++++++++++++++++++++++++++++++++++++++ drivers/xen/xen-acpi.h      
>  |    2 + 4 files changed, 137 insertions(+), 1 deletions(-)
>  create mode 100644 drivers/xen/xen-acpi-pad-stub.c
>  create mode 100644 drivers/xen/xen-acpi.h
> 
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index d4dffcd..9156a08 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -204,4 +204,9 @@ config XEN_MCE_LOG
>  	  Allow kernel fetching MCE error from Xen platform and
>  	  converting it into Linux mcelog format for mcelog tools
> 
> +config XEN_ACPI_PAD_STUB
> +	bool
> +	depends on XEN_DOM0 && X86_64 && ACPI
> +	default n
> +

This Kconfig is pointless, if CONFIG_XEN_ACPI_PAD_STUB = n, native pad would successfully registerred, and then mwait #UD (we would revert df88b2d96e36d9a9e325bfcd12eb45671cbbc937, right?). So xen stub logic should unconditionally built-in kernel.

>  endmenu
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index 0e863703..d1895d9 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -9,9 +9,10 @@ nostackp := $(call cc-option, -fno-stack-protector)
>  CFLAGS_features.o			:= $(nostackp)
> 
>  dom0-$(CONFIG_PCI) += pci.o
> -dom0-$(CONFIG_USB_SUPPORT) += dbgp.o
> +dom0-$(CONFIG_USB_EHCI_HCD) += dbgp.o
>  dom0-$(CONFIG_ACPI) += acpi.o
>  dom0-$(CONFIG_X86) += pcpu.o
> +dom0-$(CONFIG_XEN_ACPI_PAD_STUB)	+= xen-acpi-pad-stub.o
>  obj-$(CONFIG_XEN_DOM0)			+= $(dom0-y)
>  obj-$(CONFIG_BLOCK)			+= biomerge.o
>  obj-$(CONFIG_XEN_XENCOMM)		+= xencomm.o
> diff --git a/drivers/xen/xen-acpi-pad-stub.c
> b/drivers/xen/xen-acpi-pad-stub.c new file mode 100644
> index 0000000..cac9a39
> --- /dev/null
> +++ b/drivers/xen/xen-acpi-pad-stub.c
> @@ -0,0 +1,128 @@
> +/*
> + * Copyright 2012 by Oracle Inc
> + * Author: Konrad Rzeszutek Wilk 
> + *
> + * This code borrows ideas from https://lkml.org/lkml/2011/11/30/249
> + * so many thanks go to Kevin Tian 
> + * and Yu Ke .
> + *
> + * This program is free software; you can redistribute it and/or
> modify it + * under the terms and conditions of the GNU General
> Public License, + * version 2, as published by the Free Software
> Foundation. + *
> + * This program is distributed in the hope it will be useful, but
> WITHOUT + * ANY WARRANTY; without even the implied warranty of
> MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> General Public License for + * more details.
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* TODO: Needs comments. */
> +static struct acpi_device_ops *xen_acpi_pad_ops;
> +static bool __read_mostly xen_acpi_pad_registered;
> +static DEFINE_SPINLOCK(xen_acpi_pad_spinlock);
> +
> +int xen_register_acpi_pad_owner(struct acpi_device_ops *ops)
> +{
> +	if (xen_acpi_pad_ops)
> +		return -EEXIST;
> +
> +	spin_lock(&xen_acpi_pad_spinlock);
> +	xen_acpi_pad_ops = ops;
> +	spin_unlock(&xen_acpi_pad_spinlock);
> +	return 0;
> +}
> +int xen_unregister_acpi_pad_owner(struct acpi_device_ops *ops)
> +{
> +	spin_lock(&xen_acpi_pad_spinlock);
> +	if (xen_acpi_pad_ops != ops) {
> +		spin_unlock(&xen_acpi_pad_spinlock);
> +		return -ENODEV;
> +	}
> +	xen_acpi_pad_ops = NULL;
> +	spin_unlock(&xen_acpi_pad_spinlock);
> +	return 0;
> +}
> +
> +static int xen_acpi_pad_remove(struct acpi_device *device, int type)
> +{
> +	int ret = -ENOSYS;
> +
> +	spin_lock(&xen_acpi_pad_spinlock);
> +	if (xen_acpi_pad_ops && xen_acpi_pad_ops->remove)
> +		ret = xen_acpi_pad_ops->remove(device, type);
> +	spin_unlock(&xen_acpi_pad_spinlock);
> +	return ret;
> +}
> +static int xen_acpi_pad_add(struct acpi_device *device)
> +{
> +	int ret = -ENOSYS;
> +	spin_lock(&xen_acpi_pad_spinlock);
> +	if (xen_acpi_pad_ops && xen_acpi_pad_ops->add)
> +		ret = xen_acpi_pad_ops->add(device);
> +	spin_unlock(&xen_acpi_pad_spinlock);
> +	return ret;
> +}
> +
> +static const struct acpi_device_id pad_device_ids[] = {
> +	{"ACPI000C", 0},
> +	{"", 0},
> +};
> +MODULE_DEVICE_TABLE(acpi, pad_device_ids);
> +#define ACPI_PROCESSOR_AGGREGATOR_CLASS "acpi_pad"
> +
> +static struct acpi_driver xen_acpi_pad_driver = {
> +	.name = "processor_aggregator",
> +	.class = ACPI_PROCESSOR_AGGREGATOR_CLASS,
> +	.ids = pad_device_ids,
> +	.ops = {
> +		.add = xen_acpi_pad_add,
> +		.remove = xen_acpi_pad_remove,
> +	},
> +};
> +
> +static int __init xen_acpi_pad_stub_init(void)
> +{
> +	int ret = -ENOSYS;
> +	unsigned version;
> +
> +	if (!xen_initial_domain())
> +		return -ENODEV;
> +
> +	version = HYPERVISOR_xen_version(XENVER_version, NULL);
> +
> +	if ((version >> 16 >= 4) && ((version & 0xffff) >= 2)) {
> +        	ret = acpi_bus_register_driver(&xen_acpi_pad_driver);
> +        	if (!ret)
> +			xen_acpi_pad_registered = true;
> +    	}
> +    	return ret;
> +}
> +#if 0
> +/* For testing purposes. */
> +static void __exit xen_acpi_pad_stub_exit(void)
> +{
> +	if (xen_acpi_pad_registered)
> +		acpi_bus_unregister_driver(&xen_acpi_pad_driver);
> +	/* The driver should have unregistered first ! */
> +	if (WARN_ON(xen_acpi_pad_ops))
> +		xen_acpi_pad_ops = NULL;
> +}
> +#endif
> +subsys_initcall(xen_acpi_pad_stub_init);

I'm still confused. In this way there are xen-acpi-pad-stub.c and xen-acpi-pad.c, and you want to let xen-acpi-pad loaded as module, right? how can xen-acpi-pad logic work when it was insmoded?

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 08:02:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 08:02:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT6lu-0003jo-HW; Tue, 30 Oct 2012 08:02:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT6ls-0003ji-IO
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 08:02:00 +0000
Received: from [193.109.254.147:43053] by server-16.bemta-14.messagelabs.com
	id 30/A4-09215-7798F805; Tue, 30 Oct 2012 08:01:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1351584114!8908373!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3Nzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25850 invoked from network); 30 Oct 2012 08:01:54 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-27.messagelabs.com with SMTP;
	30 Oct 2012 08:01:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 30 Oct 2012 08:01:53 +0000
Message-Id: <508F97A602000078000A5527@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 30 Oct 2012 08:02:30 +0000
From: "Jan Beulich" 
To: "Alan Stern" 
References: <508EC0D202000078000A536A@nat28.tlf.novell.com>
	
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk , gregkh@linuxfoundation.org,
	linux-usb@vger.kernel.org, xen-devel ,
	Randy Dunlap ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH,
 v2] fix build with XEN and EARLY_PRINTK_DBGP enabled but
 USB_SUPPORT disabled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 29.10.12 at 23:17, Alan Stern  wrote:
> On Mon, 29 Oct 2012, Jan Beulich wrote:
> 
>> Since there's no possible caller of dbgp_external_startup() and
>> dbgp_reset_prep() when !USB_EHCI_HCD, there's no point in building and
>> exporting these functions in that case. This eliminates a build error
>> under the conditions listed in the subject, introduced with the merge
>> f1c6872e4980bc4078cfaead05f892b3d78dea64.
>> 
>> Reported-by: Randy Dunlap 
>> Signed-off-by: Jan Beulich 
>> Cc: Stefano Stabellini 
>> Cc: Alan Stern 
>> ---
>> v2: Switch the dependency from USB_SUPPORT to USB_EHCI_HCD as requested
>>     by Alan (albeit I don't really agree to that change).
> 
> Considering that the rest of ehci-dbgp.c is specific to EHCI hardware,
> using USB_EHCI_HCD seems to me like a reasonable thing to do.
> 
>> ---
>>  arch/x86/kernel/cpu/perf_event_p6.c |    2 +-
> 
> What's up with this?

I had to fix an unrelated build issue, and while I removed the
resulting change from the patch, I forgot to update the diffstat
(I had lumped that change into the same patch). So please
ignore this wrong piece of information.

Jan

>>  drivers/usb/early/ehci-dbgp.c       |   15 +++++++++------
>>  2 files changed, 10 insertions(+), 7 deletions(-)
> 
> Acked-by: Alan Stern 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 08:02:29 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 08:02:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT6lu-0003jo-HW; Tue, 30 Oct 2012 08:02:02 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT6ls-0003ji-IO
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 08:02:00 +0000
Received: from [193.109.254.147:43053] by server-16.bemta-14.messagelabs.com
	id 30/A4-09215-7798F805; Tue, 30 Oct 2012 08:01:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1351584114!8908373!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3Nzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25850 invoked from network); 30 Oct 2012 08:01:54 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-27.messagelabs.com with SMTP;
	30 Oct 2012 08:01:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 30 Oct 2012 08:01:53 +0000
Message-Id: <508F97A602000078000A5527@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 30 Oct 2012 08:02:30 +0000
From: "Jan Beulich" 
To: "Alan Stern" 
References: <508EC0D202000078000A536A@nat28.tlf.novell.com>
	
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk , gregkh@linuxfoundation.org,
	linux-usb@vger.kernel.org, xen-devel ,
	Randy Dunlap ,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH,
 v2] fix build with XEN and EARLY_PRINTK_DBGP enabled but
 USB_SUPPORT disabled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 29.10.12 at 23:17, Alan Stern  wrote:
> On Mon, 29 Oct 2012, Jan Beulich wrote:
> 
>> Since there's no possible caller of dbgp_external_startup() and
>> dbgp_reset_prep() when !USB_EHCI_HCD, there's no point in building and
>> exporting these functions in that case. This eliminates a build error
>> under the conditions listed in the subject, introduced with the merge
>> f1c6872e4980bc4078cfaead05f892b3d78dea64.
>> 
>> Reported-by: Randy Dunlap 
>> Signed-off-by: Jan Beulich 
>> Cc: Stefano Stabellini 
>> Cc: Alan Stern 
>> ---
>> v2: Switch the dependency from USB_SUPPORT to USB_EHCI_HCD as requested
>>     by Alan (albeit I don't really agree to that change).
> 
> Considering that the rest of ehci-dbgp.c is specific to EHCI hardware,
> using USB_EHCI_HCD seems to me like a reasonable thing to do.
> 
>> ---
>>  arch/x86/kernel/cpu/perf_event_p6.c |    2 +-
> 
> What's up with this?

I had to fix an unrelated build issue, and while I removed the
resulting change from the patch, I forgot to update the diffstat
(I had lumped that change into the same patch). So please
ignore this wrong piece of information.

Jan

>>  drivers/usb/early/ehci-dbgp.c       |   15 +++++++++------
>>  2 files changed, 10 insertions(+), 7 deletions(-)
> 
> Acked-by: Alan Stern 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 08:04:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 08:04:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT6nS-0003qD-7Y; Tue, 30 Oct 2012 08:03:38 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT6nR-0003q6-Ch
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 08:03:37 +0000
Received: from [193.109.254.147:3689] by server-4.bemta-14.messagelabs.com id
	08/01-04248-8D98F805; Tue, 30 Oct 2012 08:03:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1351584216!8923025!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3Nzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5029 invoked from network); 30 Oct 2012 08:03:36 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-27.messagelabs.com with SMTP;
	30 Oct 2012 08:03:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 30 Oct 2012 08:03:35 +0000
Message-Id: <508F980E02000078000A552A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 30 Oct 2012 08:04:14 +0000
From: "Jan Beulich" 
To: "Greg KH" 
References: <508EC0D202000078000A536A@nat28.tlf.novell.com>
	<20121029165047.GA22984@kroah.com>
In-Reply-To: <20121029165047.GA22984@kroah.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk , linux-usb@vger.kernel.org,
	xen-devel ,
	Randy Dunlap , stern@rowland.harvard.edu,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH,
 v2] fix build with XEN and EARLY_PRINTK_DBGP enabled but
 USB_SUPPORT disabled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 29.10.12 at 17:50, Greg KH  wrote:
> On Mon, Oct 29, 2012 at 04:45:54PM +0000, Jan Beulich wrote:
>> Since there's no possible caller of dbgp_external_startup() and
>> dbgp_reset_prep() when !USB_EHCI_HCD, there's no point in building and
>> exporting these functions in that case. This eliminates a build error
>> under the conditions listed in the subject, introduced with the merge
>> f1c6872e4980bc4078cfaead05f892b3d78dea64.
> 
> That's a merge commit, is that where the problem happened because Linus
> did the merge resolution incorrectly, or is it really due to some other
> patch that added this feature incorrectly?

It was indeed the merge that broke things (Linus just followed
the recommendation from Stefano, which weren't consistent
with the rest of the code).

Jan

> If the latter, please provide that git commit id.
> 
> thanks,
> 
> greg k-h




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 08:04:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 08:04:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT6nS-0003qD-7Y; Tue, 30 Oct 2012 08:03:38 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT6nR-0003q6-Ch
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 08:03:37 +0000
Received: from [193.109.254.147:3689] by server-4.bemta-14.messagelabs.com id
	08/01-04248-8D98F805; Tue, 30 Oct 2012 08:03:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1351584216!8923025!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3Nzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5029 invoked from network); 30 Oct 2012 08:03:36 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-27.messagelabs.com with SMTP;
	30 Oct 2012 08:03:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 30 Oct 2012 08:03:35 +0000
Message-Id: <508F980E02000078000A552A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 30 Oct 2012 08:04:14 +0000
From: "Jan Beulich" 
To: "Greg KH" 
References: <508EC0D202000078000A536A@nat28.tlf.novell.com>
	<20121029165047.GA22984@kroah.com>
In-Reply-To: <20121029165047.GA22984@kroah.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk , linux-usb@vger.kernel.org,
	xen-devel ,
	Randy Dunlap , stern@rowland.harvard.edu,
	Stefano Stabellini 
Subject: Re: [Xen-devel] [PATCH,
 v2] fix build with XEN and EARLY_PRINTK_DBGP enabled but
 USB_SUPPORT disabled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 29.10.12 at 17:50, Greg KH  wrote:
> On Mon, Oct 29, 2012 at 04:45:54PM +0000, Jan Beulich wrote:
>> Since there's no possible caller of dbgp_external_startup() and
>> dbgp_reset_prep() when !USB_EHCI_HCD, there's no point in building and
>> exporting these functions in that case. This eliminates a build error
>> under the conditions listed in the subject, introduced with the merge
>> f1c6872e4980bc4078cfaead05f892b3d78dea64.
> 
> That's a merge commit, is that where the problem happened because Linus
> did the merge resolution incorrectly, or is it really due to some other
> patch that added this feature incorrectly?

It was indeed the merge that broke things (Linus just followed
the recommendation from Stefano, which weren't consistent
with the rest of the code).

Jan

> If the latter, please provide that git commit id.
> 
> thanks,
> 
> greg k-h




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 08:14:28 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 08:14:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT6xZ-00047h-B4; Tue, 30 Oct 2012 08:14:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TT6xY-00047c-2k
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 08:14:04 +0000
Received: from [85.158.139.83:45026] by server-12.bemta-5.messagelabs.com id
	0E/C8-26919-B4C8F805; Tue, 30 Oct 2012 08:14:03 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-182.messagelabs.com!1351584842!23626548!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2896 invoked from network); 30 Oct 2012 08:14:02 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Oct 2012 08:14:02 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TT6xR-00094Z-81; Tue, 30 Oct 2012 08:13:57 +0000
Date: Tue, 30 Oct 2012 08:13:57 +0000
From: Tim Deegan 
To: Dan Magenheimer 
Message-ID: <20121030081357.GA34613@ocelot.phlegethon.org>
References: <60d00f38-98a3-4ec2-acbd-b49dafaada56@default>
	<20121029223555.GA24388@ocelot.phlegethon.org>
	
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.1i
Cc: Olaf Hering , "Keir \(Xen.org\)" ,
	Ian Campbell ,
	Konrad Wilk ,
	George Dunlap ,
	Kurt Hackel ,
	George Shuklin ,
	xen-devel@lists.xen.org, Dario Faggioli ,
	Zhigang Wang ,
	Ian Jackson 
Subject: Re: [Xen-devel] Proposed new "memory capacity claim"
	hypercall/feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, 

At 16:21 -0700 on 29 Oct (1351527686), Dan Magenheimer wrote:
> > > The hypervisor must also enforce some semantics:  If an allocation
> > > occurs such that a domain's tot_phys_pages would equal or exceed
> > > d.tot_claimed_pages, then d.tot_claimed_pages becomes "unset".
> > > This enforces the temporary nature of a claim:  Once a domain
> > > fully "occupies" its claim, the claim silently expires.
> > 
> > Why does that happen?  If I understand you correctly, releasing the
> > claim is something the toolstack should do once it knows it's no longer
> > needed.
> 
> I haven't thought this all the way through yet, but I think this
> part of the design allows the toolstack to avoid monitoring the
> domain until "total_phys_pages" reaches "total_claimed" pages,
> which should make the implementation of claims in the toolstack
> simpler, especially in many-server environments.

I think the toolstack has to monitor the domain for that long anyway,
since it will have to unpause it once it's built.  Relying on an
implicit release seems fragile -- if the builder ends up using only
(total_claimed - 1) pages, or temporarily allocating total_claimed and
then releasing some memory, things could break.

> > I think it needs a plan for handling restricted memory allocations.
> > For example, some PV guests need their memory to come below a
> > certain machine address, or entirely in superpages, and certain
> > build-time allocations come from xenheap.  How would you handle that
> > sort of thing?
> 
> Good point.  I think there's always been some uncertainty about
> how to account for different zones and xenheap... are they part of the
> domain's memory or not?

Xenheap pages are not part of the domain memory for accounting purposes;
likewise other 'anonymous' allocations (that is, anywhere that
alloc_domheap_pages() & friends are called with a NULL domain pointer).
Pages with restricted addresses are just accounted like any other
memory, except when they're on the free lists.

Today, toolstacks use a rule of thumb of how much extra space to leave
to cover those things -- if you want to pre-allocate them, you'll have
to go through the hypervisor making sure _all_ memory allocations are
accounted to the right domain somehow (maybe by generalizing the
shadow-allocation pool to cover all per-domain overheads).  That seems
like a useful side-effect of adding your new feature.

> Deserves some more thought...  if you can enumerate all such cases,
> that would be very helpful (and probably valuable long-term
> documentation as well).

I'm afraid I can't, not without re-reading all the domain-builder code
and a fair chunk of the hypervisor, so it's up to you to figure it out.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 08:14:28 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 08:14:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT6xZ-00047h-B4; Tue, 30 Oct 2012 08:14:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TT6xY-00047c-2k
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 08:14:04 +0000
Received: from [85.158.139.83:45026] by server-12.bemta-5.messagelabs.com id
	0E/C8-26919-B4C8F805; Tue, 30 Oct 2012 08:14:03 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-182.messagelabs.com!1351584842!23626548!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2896 invoked from network); 30 Oct 2012 08:14:02 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Oct 2012 08:14:02 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TT6xR-00094Z-81; Tue, 30 Oct 2012 08:13:57 +0000
Date: Tue, 30 Oct 2012 08:13:57 +0000
From: Tim Deegan 
To: Dan Magenheimer 
Message-ID: <20121030081357.GA34613@ocelot.phlegethon.org>
References: <60d00f38-98a3-4ec2-acbd-b49dafaada56@default>
	<20121029223555.GA24388@ocelot.phlegethon.org>
	
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.1i
Cc: Olaf Hering , "Keir \(Xen.org\)" ,
	Ian Campbell ,
	Konrad Wilk ,
	George Dunlap ,
	Kurt Hackel ,
	George Shuklin ,
	xen-devel@lists.xen.org, Dario Faggioli ,
	Zhigang Wang ,
	Ian Jackson 
Subject: Re: [Xen-devel] Proposed new "memory capacity claim"
	hypercall/feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi, 

At 16:21 -0700 on 29 Oct (1351527686), Dan Magenheimer wrote:
> > > The hypervisor must also enforce some semantics:  If an allocation
> > > occurs such that a domain's tot_phys_pages would equal or exceed
> > > d.tot_claimed_pages, then d.tot_claimed_pages becomes "unset".
> > > This enforces the temporary nature of a claim:  Once a domain
> > > fully "occupies" its claim, the claim silently expires.
> > 
> > Why does that happen?  If I understand you correctly, releasing the
> > claim is something the toolstack should do once it knows it's no longer
> > needed.
> 
> I haven't thought this all the way through yet, but I think this
> part of the design allows the toolstack to avoid monitoring the
> domain until "total_phys_pages" reaches "total_claimed" pages,
> which should make the implementation of claims in the toolstack
> simpler, especially in many-server environments.

I think the toolstack has to monitor the domain for that long anyway,
since it will have to unpause it once it's built.  Relying on an
implicit release seems fragile -- if the builder ends up using only
(total_claimed - 1) pages, or temporarily allocating total_claimed and
then releasing some memory, things could break.

> > I think it needs a plan for handling restricted memory allocations.
> > For example, some PV guests need their memory to come below a
> > certain machine address, or entirely in superpages, and certain
> > build-time allocations come from xenheap.  How would you handle that
> > sort of thing?
> 
> Good point.  I think there's always been some uncertainty about
> how to account for different zones and xenheap... are they part of the
> domain's memory or not?

Xenheap pages are not part of the domain memory for accounting purposes;
likewise other 'anonymous' allocations (that is, anywhere that
alloc_domheap_pages() & friends are called with a NULL domain pointer).
Pages with restricted addresses are just accounted like any other
memory, except when they're on the free lists.

Today, toolstacks use a rule of thumb of how much extra space to leave
to cover those things -- if you want to pre-allocate them, you'll have
to go through the hypervisor making sure _all_ memory allocations are
accounted to the right domain somehow (maybe by generalizing the
shadow-allocation pool to cover all per-domain overheads).  That seems
like a useful side-effect of adding your new feature.

> Deserves some more thought...  if you can enumerate all such cases,
> that would be very helpful (and probably valuable long-term
> documentation as well).

I'm afraid I can't, not without re-reading all the domain-builder code
and a fair chunk of the hypervisor, so it's up to you to figure it out.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 08:29:12 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 08:29:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT7Be-0004KC-4t; Tue, 30 Oct 2012 08:28:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT7Bc-0004K7-Qa
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 08:28:37 +0000
Received: from [85.158.137.99:57753] by server-15.bemta-3.messagelabs.com id
	BA/FD-09445-4BF8F805; Tue, 30 Oct 2012 08:28:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1351585715!16976408!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3Nzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21879 invoked from network); 30 Oct 2012 08:28:35 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-217.messagelabs.com with SMTP;
	30 Oct 2012 08:28:35 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 30 Oct 2012 08:28:34 +0000
Message-Id: <508F9DE902000078000A5565@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 30 Oct 2012 08:29:13 +0000
From: "Jan Beulich" 
To: "Dan Magenheimer" 
References: <60d00f38-98a3-4ec2-acbd-b49dafaada56@default>
	<20121029223555.GA24388@ocelot.phlegethon.org>
	
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan , Olaf Hering ,
	"Keir \(Xen.org\)" , IanCampbell ,
	Konrad Wilk ,
	GeorgeDunlap ,
	IanJackson ,
	George Shuklin ,
	xen-devel@lists.xen.org, DarioFaggioli ,
	Kurt Hackel ,
	Zhigang Wang 
Subject: Re: [Xen-devel] Proposed new "memory capacity claim"
	hypercall/feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 30.10.12 at 00:21, Dan Magenheimer  wrote:
>>  From: Tim Deegan [mailto:tim@xen.org]
>> As I said, I'm not opposed to this, though even after reading through
>> the other thread I'm not convinced that it's necessary (except in cases
>> where guest-controlled operations are allowed to consume unbounded
>> memory, which frankly gives me the heebie-jeebies).
> 
> A really detailed discussion of tmem would probably be good but,
> yes, with tmem, guest-controlled* operations can and frequently will
> absorb ALL physical RAM.  However, this is "freeable" (ephemeral)
> memory used by the hypervisor on behalf of domains, not domain-owned
> memory.
> 
> * "guest-controlled" I suspect is the heebie-jeebie word... in
>   tmem, a better description might be "guest-controls-which-data-
>   and-hypervisor-controls-how-many-pages"

But isn't tmem use supposed to be transparent in this respect, i.e.
if a "normal" allocation cannot be satisfied, tmem would jump in
and free sufficient space? In which case there's no need to do
any accounting outside of the control tools (leaving aside the
smaller hypervisor internal allocations, which the tool stack needs
to provide room for anyway).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 08:29:12 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 08:29:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT7Be-0004KC-4t; Tue, 30 Oct 2012 08:28:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT7Bc-0004K7-Qa
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 08:28:37 +0000
Received: from [85.158.137.99:57753] by server-15.bemta-3.messagelabs.com id
	BA/FD-09445-4BF8F805; Tue, 30 Oct 2012 08:28:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1351585715!16976408!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3Nzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21879 invoked from network); 30 Oct 2012 08:28:35 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-217.messagelabs.com with SMTP;
	30 Oct 2012 08:28:35 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 30 Oct 2012 08:28:34 +0000
Message-Id: <508F9DE902000078000A5565@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 30 Oct 2012 08:29:13 +0000
From: "Jan Beulich" 
To: "Dan Magenheimer" 
References: <60d00f38-98a3-4ec2-acbd-b49dafaada56@default>
	<20121029223555.GA24388@ocelot.phlegethon.org>
	
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan , Olaf Hering ,
	"Keir \(Xen.org\)" , IanCampbell ,
	Konrad Wilk ,
	GeorgeDunlap ,
	IanJackson ,
	George Shuklin ,
	xen-devel@lists.xen.org, DarioFaggioli ,
	Kurt Hackel ,
	Zhigang Wang 
Subject: Re: [Xen-devel] Proposed new "memory capacity claim"
	hypercall/feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 30.10.12 at 00:21, Dan Magenheimer  wrote:
>>  From: Tim Deegan [mailto:tim@xen.org]
>> As I said, I'm not opposed to this, though even after reading through
>> the other thread I'm not convinced that it's necessary (except in cases
>> where guest-controlled operations are allowed to consume unbounded
>> memory, which frankly gives me the heebie-jeebies).
> 
> A really detailed discussion of tmem would probably be good but,
> yes, with tmem, guest-controlled* operations can and frequently will
> absorb ALL physical RAM.  However, this is "freeable" (ephemeral)
> memory used by the hypervisor on behalf of domains, not domain-owned
> memory.
> 
> * "guest-controlled" I suspect is the heebie-jeebie word... in
>   tmem, a better description might be "guest-controls-which-data-
>   and-hypervisor-controls-how-many-pages"

But isn't tmem use supposed to be transparent in this respect, i.e.
if a "normal" allocation cannot be satisfied, tmem would jump in
and free sufficient space? In which case there's no need to do
any accounting outside of the control tools (leaving aside the
smaller hypervisor internal allocations, which the tool stack needs
to provide room for anyway).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 08:44:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 08:44:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT7QC-0004W9-GN; Tue, 30 Oct 2012 08:43:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT7QB-0004W4-R6
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 08:43:40 +0000
Received: from [85.158.143.35:37489] by server-3.bemta-4.messagelabs.com id
	A8/29-24279-A339F805; Tue, 30 Oct 2012 08:43:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1351586617!5237464!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7271 invoked from network); 30 Oct 2012 08:43:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 08:43:37 -0000
X-IronPort-AV: E=Sophos;i="4.80,677,1344211200"; d="scan'208";a="15481347"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 08:43:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 30 Oct 2012 08:43:36 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TT7Q8-0005Sz-Id;
	Tue, 30 Oct 2012 08:43:36 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TT7Q8-0006hQ-AL;
	Tue, 30 Oct 2012 08:43:36 +0000
To: 
Message-ID: 
From: xen.org 
Date: Tue, 30 Oct 2012 08:43:36 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 14153: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14153 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14153/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl             9 guest-start               fail REGR. vs. 14076
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 14076
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 14076
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 14076

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore         fail REGR. vs. 14076

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  2bca7e58a3df
baseline version:
 xen                  40ccbee890e1

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla 
  Bastian Blank 
  Chuang Cao 
  George Dunlap 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jason McCarver 
  Joe Jin 
  Keir Fraser 
  Matt Wilson 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Sander Eikelenboom 
  Stefano Stabellini 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 632 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 08:44:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 08:44:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT7QC-0004W9-GN; Tue, 30 Oct 2012 08:43:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT7QB-0004W4-R6
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 08:43:40 +0000
Received: from [85.158.143.35:37489] by server-3.bemta-4.messagelabs.com id
	A8/29-24279-A339F805; Tue, 30 Oct 2012 08:43:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1351586617!5237464!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7271 invoked from network); 30 Oct 2012 08:43:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 08:43:37 -0000
X-IronPort-AV: E=Sophos;i="4.80,677,1344211200"; d="scan'208";a="15481347"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 08:43:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 30 Oct 2012 08:43:36 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TT7Q8-0005Sz-Id;
	Tue, 30 Oct 2012 08:43:36 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TT7Q8-0006hQ-AL;
	Tue, 30 Oct 2012 08:43:36 +0000
To: 
Message-ID: 
From: xen.org 
Date: Tue, 30 Oct 2012 08:43:36 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 14153: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14153 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14153/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl             9 guest-start               fail REGR. vs. 14076
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 14076
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 14076
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 14076

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore         fail REGR. vs. 14076

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  2bca7e58a3df
baseline version:
 xen                  40ccbee890e1

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla 
  Bastian Blank 
  Chuang Cao 
  George Dunlap 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jason McCarver 
  Joe Jin 
  Keir Fraser 
  Matt Wilson 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Sander Eikelenboom 
  Stefano Stabellini 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 632 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 09:05:18 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 09:05:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT7kd-0004mZ-GC; Tue, 30 Oct 2012 09:04:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT7kb-0004mR-Mk
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 09:04:45 +0000
Received: from [193.109.254.147:52191] by server-15.bemta-14.messagelabs.com
	id F4/93-12105-C289F805; Tue, 30 Oct 2012 09:04:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1351587683!8784490!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3Nzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10071 invoked from network); 30 Oct 2012 09:01:23 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-27.messagelabs.com with SMTP;
	30 Oct 2012 09:01:23 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 30 Oct 2012 09:01:22 +0000
Message-Id: <508FA59902000078000A55FB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 30 Oct 2012 09:02:01 +0000
From: "Jan Beulich" 
To: "Jinsong Liu" 
References: 
	
	
	<50852EB6.4060705@eu.citrix.com>
	
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	George Dunlap ,
	Ian Jackson 
Subject: Re: [Xen-devel] [Patch 4/5] X86/vMCE: handle broken page occurred
 before migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 29.10.12 at 16:21, "Liu, Jinsong"  wrote:
> @@ -1568,6 +1577,28 @@
>      }
>      break;
>  
> +    case XEN_DOMCTL_set_broken_page_p2m:
> +    {
> +        struct domain *d;
> +        p2m_type_t pt;
> +        unsigned long pfn;
> +
> +        d = rcu_lock_domain_by_id(domctl->domain);
> +        if ( d != NULL )
> +        {
> +            pfn = domctl->u.set_broken_page_p2m.pfn;
> +
> +            get_gfn_query(d, pfn, &pt);

Is it correct to ignore the return value here, and to act on any
value returned in "pt"?

> +            p2m_change_type(d, pfn, pt, p2m_ram_broken);

What if the operation failed (i.e. you get back a type not
matching "pt")? This can happen because __get_gfn_type_access(),
other than what p2m_change_type() does, is not just a plain call
to p2m->get_entry().

Jan

> +            put_gfn(d, pfn);
> +
> +            rcu_unlock_domain(d);
> +        }
> +        else
> +            ret = -ESRCH;
> +    }
> +    break;
> +
>      default:
>          ret = iommu_do_domctl(domctl, u_domctl);
>          break;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 09:05:18 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 09:05:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT7kd-0004mZ-GC; Tue, 30 Oct 2012 09:04:47 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT7kb-0004mR-Mk
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 09:04:45 +0000
Received: from [193.109.254.147:52191] by server-15.bemta-14.messagelabs.com
	id F4/93-12105-C289F805; Tue, 30 Oct 2012 09:04:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1351587683!8784490!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3Nzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10071 invoked from network); 30 Oct 2012 09:01:23 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-27.messagelabs.com with SMTP;
	30 Oct 2012 09:01:23 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 30 Oct 2012 09:01:22 +0000
Message-Id: <508FA59902000078000A55FB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 30 Oct 2012 09:02:01 +0000
From: "Jan Beulich" 
To: "Jinsong Liu" 
References: 
	
	
	<50852EB6.4060705@eu.citrix.com>
	
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	George Dunlap ,
	Ian Jackson 
Subject: Re: [Xen-devel] [Patch 4/5] X86/vMCE: handle broken page occurred
 before migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 29.10.12 at 16:21, "Liu, Jinsong"  wrote:
> @@ -1568,6 +1577,28 @@
>      }
>      break;
>  
> +    case XEN_DOMCTL_set_broken_page_p2m:
> +    {
> +        struct domain *d;
> +        p2m_type_t pt;
> +        unsigned long pfn;
> +
> +        d = rcu_lock_domain_by_id(domctl->domain);
> +        if ( d != NULL )
> +        {
> +            pfn = domctl->u.set_broken_page_p2m.pfn;
> +
> +            get_gfn_query(d, pfn, &pt);

Is it correct to ignore the return value here, and to act on any
value returned in "pt"?

> +            p2m_change_type(d, pfn, pt, p2m_ram_broken);

What if the operation failed (i.e. you get back a type not
matching "pt")? This can happen because __get_gfn_type_access(),
other than what p2m_change_type() does, is not just a plain call
to p2m->get_entry().

Jan

> +            put_gfn(d, pfn);
> +
> +            rcu_unlock_domain(d);
> +        }
> +        else
> +            ret = -ESRCH;
> +    }
> +    break;
> +
>      default:
>          ret = iommu_do_domctl(domctl, u_domctl);
>          break;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 09:07:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 09:07:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT7mv-0004t2-12; Tue, 30 Oct 2012 09:07:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT7mt-0004sv-DP
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 09:07:07 +0000
Received: from [85.158.143.99:49619] by server-3.bemta-4.messagelabs.com id
	38/DE-24279-AB89F805; Tue, 30 Oct 2012 09:07:06 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1351588026!27867325!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24788 invoked from network); 30 Oct 2012 09:07:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 09:07:06 -0000
X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="15481846"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 09:07:06 +0000
Received: from [192.168.1.30] (10.31.3.235) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 30 Oct 2012 09:07:05 +0000
Message-ID: <508F98B8.1030209@citrix.com>
Date: Tue, 30 Oct 2012 10:07:04 +0100
From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: Ian Campbell 
References: 
	<57896068356d4870c74a.1351098144@makatos-desktop>
	<1351250625.15162.42.camel@zakaz.uk.xensource.com>
	<4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8C61@LONPMAILBOX01.citrite.net>
	<1351582903.16868.9.camel@hastur.hellion.org.uk>
In-Reply-To: <1351582903.16868.9.camel@hastur.hellion.org.uk>
Cc: Thanos Makatos ,
	"xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 05 of 16 RFC] blktap3: Don't check if blktap
 is available
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 30/10/12 08:41, Ian Campbell wrote:
>>>
>>> Perhaps even on Linux we would want a sanity check that the drivers are
>>> present and loaded etc?
>>
>> We could ensure that the tapdisk binaries are present, apart from that
>> I don't see anything else we could check.
> 
> Could we check for /dev/xen/{evtchn,gntdev,...} or whatever else it
> needs?

We could also check with xc_gnttab_open, which will return an error on
NetBSD.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 09:07:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 09:07:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT7mv-0004t2-12; Tue, 30 Oct 2012 09:07:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT7mt-0004sv-DP
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 09:07:07 +0000
Received: from [85.158.143.99:49619] by server-3.bemta-4.messagelabs.com id
	38/DE-24279-AB89F805; Tue, 30 Oct 2012 09:07:06 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1351588026!27867325!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24788 invoked from network); 30 Oct 2012 09:07:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 09:07:06 -0000
X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="15481846"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 09:07:06 +0000
Received: from [192.168.1.30] (10.31.3.235) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 30 Oct 2012 09:07:05 +0000
Message-ID: <508F98B8.1030209@citrix.com>
Date: Tue, 30 Oct 2012 10:07:04 +0100
From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: Ian Campbell 
References: 
	<57896068356d4870c74a.1351098144@makatos-desktop>
	<1351250625.15162.42.camel@zakaz.uk.xensource.com>
	<4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8C61@LONPMAILBOX01.citrite.net>
	<1351582903.16868.9.camel@hastur.hellion.org.uk>
In-Reply-To: <1351582903.16868.9.camel@hastur.hellion.org.uk>
Cc: Thanos Makatos ,
	"xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 05 of 16 RFC] blktap3: Don't check if blktap
 is available
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 30/10/12 08:41, Ian Campbell wrote:
>>>
>>> Perhaps even on Linux we would want a sanity check that the drivers are
>>> present and loaded etc?
>>
>> We could ensure that the tapdisk binaries are present, apart from that
>> I don't see anything else we could check.
> 
> Could we check for /dev/xen/{evtchn,gntdev,...} or whatever else it
> needs?

We could also check with xc_gnttab_open, which will return an error on
NetBSD.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 09:11:56 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 09:11:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT7rD-000562-VN; Tue, 30 Oct 2012 09:11:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT7rC-00055u-4O
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 09:11:34 +0000
Received: from [85.158.137.99:2817] by server-9.bemta-3.messagelabs.com id
	75/34-16841-5C99F805; Tue, 30 Oct 2012 09:11:33 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1351588291!11903761!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21226 invoked from network); 30 Oct 2012 09:11:32 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 09:11:32 -0000
Received: by mail-wi0-f173.google.com with SMTP id hm4so2639444wib.14
	for ; Tue, 30 Oct 2012 02:11:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=vjTd81v9I8kPr6Jgmsh3fgblg/sDo/SBjnwtV2UntNs=;
	b=Q4P2GOLnn5W6XOKF7zl7Vy3eIUmBV9cYP9ntCCv8WUxV6dmMM373T0nnyKGzfS9c4Q
	p/VgL7Oau7GH3yJkLwFsn/T6ZRQqhgeg3joDOAlAHHUhQEPMnFgLWm2Kn5qFQZGcX6Pt
	vfRRIwkDC+jw7dzQzV81Nsqw8qk+VNp20Z/VRMGKiZVkQDHoE1shpyd5zLAszlqPqVM6
	4sL9r9lg5DSPBDNENEMoRZsF05pJ6dJAeSZkbLBNjTmA9cLpUrWWD7Ok6ncte/vZM10t
	FSSpAgmH1ECKDA705G0WEw0z1Lu+uYcYYa2n7FZsofzu3PNPEIQV4Y5oFocf4wHMg5pN
	wcQQ==
MIME-Version: 1.0
Received: by 10.216.200.150 with SMTP id z22mr16400763wen.97.1351588291580;
	Tue, 30 Oct 2012 02:11:31 -0700 (PDT)
Received: by 10.227.200.1 with HTTP; Tue, 30 Oct 2012 02:11:31 -0700 (PDT)
In-Reply-To: <806ef32a-2ded-42b5-a2ff-5f84ac1c1d47@default>
References: <89c92e3f-8aeb-4c97-ab15-d282327f3a98@default>
	
	<806ef32a-2ded-42b5-a2ff-5f84ac1c1d47@default>
Date: Tue, 30 Oct 2012 10:11:31 +0100
X-Google-Sender-Auth: n8HMyaR33BpyUnQ-ryIudJmj8sE
Message-ID: 
From: George Dunlap 
To: Dan Magenheimer 
Cc: Olaf Hering , Keir Fraser ,
	Ian Campbell ,
	Konrad Wilk , "Tim \(Xen.org\)" ,
	George Shuklin ,
	xen-devel@lists.xen.org, Dario Faggioli ,
	Kurt Hackel ,
	Zhigang Wang ,
	Ian Jackson 
Subject: Re: [Xen-devel] Proposed new "memory capacity claim"
	hypercall/feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 29, 2012 at 6:06 PM, Dan Magenheimer
 wrote:
> Keir, Jan (et al) --
>
> In a recent long thread [1], there was a great deal of discussion
> about the possible need for a "memory reservation" hypercall.
> While there was some confusion due to the two worldviews of static
> vs dynamic management of physical memory capacity, one worldview
> definitely has a requirement for this new capability.

No, it does not.


> I'm not just arguing against reservation-as-a-toolstack-mechanism,
> I'm stating I believe unequivocally that reservation-as-a-toolstack-
> only-mechanism and tmem are incompatible.  (Well, not _totally_
> incompatible... the existing workaround, tmem freeze/thaw, works
> but is also single-threaded and has fairly severe unnecessary
> performance repercussions.  So I'd like to solve both problems
> at the same time.)

No, it is not.

Look, the *only* reason you have this problem is that *you yourselves*
programmed in two incompatible assumptions:

1. You have a toolstack that assumes it can ask "how much free memory
is there" from the HV and have that be an accurate answer, rather than
keeping track of this itself

2. You wrote the tmem code to do "self-ballooning", which for no good
reason, gives memory back to the hypervisor, rather than just keeping
it itself.

Basically #2 breaks the assumption of #1.  It has absolutely nothing
at all to do with tmem.  It's just a quirk of your particular
implementation of self-ballooning.

This new hypercall you're introducing is just a hack to fix the fact
that you've baked in incompatible assumptions.  It's completely
unnecessary.  All of the functionality you're describing can be
implemented outside of the hypervisor in the toolstack -- this would
fix #1.  Doing that would have no effect on tmem whatsoever.

Alternately, you could fix #2 -- have the "self-ballooning" mechanism
just allocate the memory to force the swapping to happen, but *not
hand it back to the hypervisor*.

We don't need this new hypercall.  You should just fix your own bugs
rather than introducing new hacks to work around them.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 09:11:56 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 09:11:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT7rD-000562-VN; Tue, 30 Oct 2012 09:11:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT7rC-00055u-4O
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 09:11:34 +0000
Received: from [85.158.137.99:2817] by server-9.bemta-3.messagelabs.com id
	75/34-16841-5C99F805; Tue, 30 Oct 2012 09:11:33 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1351588291!11903761!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21226 invoked from network); 30 Oct 2012 09:11:32 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 09:11:32 -0000
Received: by mail-wi0-f173.google.com with SMTP id hm4so2639444wib.14
	for ; Tue, 30 Oct 2012 02:11:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=vjTd81v9I8kPr6Jgmsh3fgblg/sDo/SBjnwtV2UntNs=;
	b=Q4P2GOLnn5W6XOKF7zl7Vy3eIUmBV9cYP9ntCCv8WUxV6dmMM373T0nnyKGzfS9c4Q
	p/VgL7Oau7GH3yJkLwFsn/T6ZRQqhgeg3joDOAlAHHUhQEPMnFgLWm2Kn5qFQZGcX6Pt
	vfRRIwkDC+jw7dzQzV81Nsqw8qk+VNp20Z/VRMGKiZVkQDHoE1shpyd5zLAszlqPqVM6
	4sL9r9lg5DSPBDNENEMoRZsF05pJ6dJAeSZkbLBNjTmA9cLpUrWWD7Ok6ncte/vZM10t
	FSSpAgmH1ECKDA705G0WEw0z1Lu+uYcYYa2n7FZsofzu3PNPEIQV4Y5oFocf4wHMg5pN
	wcQQ==
MIME-Version: 1.0
Received: by 10.216.200.150 with SMTP id z22mr16400763wen.97.1351588291580;
	Tue, 30 Oct 2012 02:11:31 -0700 (PDT)
Received: by 10.227.200.1 with HTTP; Tue, 30 Oct 2012 02:11:31 -0700 (PDT)
In-Reply-To: <806ef32a-2ded-42b5-a2ff-5f84ac1c1d47@default>
References: <89c92e3f-8aeb-4c97-ab15-d282327f3a98@default>
	
	<806ef32a-2ded-42b5-a2ff-5f84ac1c1d47@default>
Date: Tue, 30 Oct 2012 10:11:31 +0100
X-Google-Sender-Auth: n8HMyaR33BpyUnQ-ryIudJmj8sE
Message-ID: 
From: George Dunlap 
To: Dan Magenheimer 
Cc: Olaf Hering , Keir Fraser ,
	Ian Campbell ,
	Konrad Wilk , "Tim \(Xen.org\)" ,
	George Shuklin ,
	xen-devel@lists.xen.org, Dario Faggioli ,
	Kurt Hackel ,
	Zhigang Wang ,
	Ian Jackson 
Subject: Re: [Xen-devel] Proposed new "memory capacity claim"
	hypercall/feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 29, 2012 at 6:06 PM, Dan Magenheimer
 wrote:
> Keir, Jan (et al) --
>
> In a recent long thread [1], there was a great deal of discussion
> about the possible need for a "memory reservation" hypercall.
> While there was some confusion due to the two worldviews of static
> vs dynamic management of physical memory capacity, one worldview
> definitely has a requirement for this new capability.

No, it does not.


> I'm not just arguing against reservation-as-a-toolstack-mechanism,
> I'm stating I believe unequivocally that reservation-as-a-toolstack-
> only-mechanism and tmem are incompatible.  (Well, not _totally_
> incompatible... the existing workaround, tmem freeze/thaw, works
> but is also single-threaded and has fairly severe unnecessary
> performance repercussions.  So I'd like to solve both problems
> at the same time.)

No, it is not.

Look, the *only* reason you have this problem is that *you yourselves*
programmed in two incompatible assumptions:

1. You have a toolstack that assumes it can ask "how much free memory
is there" from the HV and have that be an accurate answer, rather than
keeping track of this itself

2. You wrote the tmem code to do "self-ballooning", which for no good
reason, gives memory back to the hypervisor, rather than just keeping
it itself.

Basically #2 breaks the assumption of #1.  It has absolutely nothing
at all to do with tmem.  It's just a quirk of your particular
implementation of self-ballooning.

This new hypercall you're introducing is just a hack to fix the fact
that you've baked in incompatible assumptions.  It's completely
unnecessary.  All of the functionality you're describing can be
implemented outside of the hypervisor in the toolstack -- this would
fix #1.  Doing that would have no effect on tmem whatsoever.

Alternately, you could fix #2 -- have the "self-ballooning" mechanism
just allocate the memory to force the swapping to happen, but *not
hand it back to the hypervisor*.

We don't need this new hypercall.  You should just fix your own bugs
rather than introducing new hacks to work around them.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 09:23:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 09:23:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT81w-0005O7-5j; Tue, 30 Oct 2012 09:22:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT81u-0005O2-VN
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 09:22:39 +0000
Received: from [85.158.143.99:7825] by server-2.bemta-4.messagelabs.com id
	5F/9C-22268-E5C9F805; Tue, 30 Oct 2012 09:22:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1351588957!26994644!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5903 invoked from network); 30 Oct 2012 09:22:37 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-216.messagelabs.com with SMTP;
	30 Oct 2012 09:22:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 30 Oct 2012 09:22:37 +0000
Message-Id: <508FAA9402000078000A5612@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 30 Oct 2012 09:23:16 +0000
From: "Jan Beulich" 
To: "Andres Lagar-Cavilla" ,
	"Tim Deegan" 
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel 
Subject: [Xen-devel] get_gfn_query() locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Tim, Andres,

while looking at how "X86/vMCE: handle broken page occurred
before migration" uses the p2m code, I wondered whether the
comment

 * N.B. get_gfn_query() is the _only_ one guaranteed not to take the
 * p2m lock; none of the others can be called with the p2m or paging
 * lock held. */

isn't stale - afaict with get_gfn_type_access() passing "1" for the
"locked" parameter of __get_gfn_type_access(), there's no way
to avoid the locking without using __get_gfn_type_access()
directly. And then again, with the p2m lock being recursive these
days, I don't think there's any harm calling the other methods
here with that lock held.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 09:23:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 09:23:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT81w-0005O7-5j; Tue, 30 Oct 2012 09:22:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT81u-0005O2-VN
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 09:22:39 +0000
Received: from [85.158.143.99:7825] by server-2.bemta-4.messagelabs.com id
	5F/9C-22268-E5C9F805; Tue, 30 Oct 2012 09:22:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1351588957!26994644!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5903 invoked from network); 30 Oct 2012 09:22:37 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-216.messagelabs.com with SMTP;
	30 Oct 2012 09:22:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 30 Oct 2012 09:22:37 +0000
Message-Id: <508FAA9402000078000A5612@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 30 Oct 2012 09:23:16 +0000
From: "Jan Beulich" 
To: "Andres Lagar-Cavilla" ,
	"Tim Deegan" 
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel 
Subject: [Xen-devel] get_gfn_query() locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Tim, Andres,

while looking at how "X86/vMCE: handle broken page occurred
before migration" uses the p2m code, I wondered whether the
comment

 * N.B. get_gfn_query() is the _only_ one guaranteed not to take the
 * p2m lock; none of the others can be called with the p2m or paging
 * lock held. */

isn't stale - afaict with get_gfn_type_access() passing "1" for the
"locked" parameter of __get_gfn_type_access(), there's no way
to avoid the locking without using __get_gfn_type_access()
directly. And then again, with the p2m lock being recursive these
days, I don't think there's any harm calling the other methods
here with that lock held.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 09:23:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 09:23:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT824-0005Ot-TZ; Tue, 30 Oct 2012 09:22:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT823-0005OW-Ap
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 09:22:47 +0000
Received: from [85.158.137.99:43061] by server-16.bemta-3.messagelabs.com id
	6A/DD-07461-66C9F805; Tue, 30 Oct 2012 09:22:46 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1351588965!12223201!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16968 invoked from network); 30 Oct 2012 09:22:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 09:22:46 -0000
X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="15482219"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 09:22:45 +0000
Received: from mac.citrite.net (10.31.3.235) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 30 Oct 2012 09:22:45 +0000
From: Roger Pau Monne 
To: 
Date: Tue, 30 Oct 2012 10:22:38 +0100
Message-ID: <1351588958-75040-2-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1351588958-75040-1-git-send-email-roger.pau@citrix.com>
References: <1351588958-75040-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne 
Subject: [Xen-devel] [PATCH 2/2] autoconf: bash is not needed on NetBSD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Remove check for bash on NetBSD, since it is not needed for hotplug
scripts (NetBSD hotplug scripts use sh) or the build system.

Signed-off-by: Roger Pau Monne 
---
 tools/configure.ac |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/tools/configure.ac b/tools/configure.ac
index e708f01..47607ae 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -93,7 +93,11 @@ AS_IF([test "x$ocamltools" = "xy"], [
         ocamltools="n"
     ])
 ])
-AX_PATH_PROG_OR_FAIL([BASH], [bash])
+case "$host_os" in
+linux*)
+    AX_PATH_PROG_OR_FAIL([BASH], [bash])
+    ;;
+esac
 AS_IF([echo "$PYTHON" | grep -q "^/"], [
     PYTHONPATH=$PYTHON
     PYTHON=`basename $PYTHONPATH`
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 09:23:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 09:23:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT824-0005Ol-Ho; Tue, 30 Oct 2012 09:22:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT823-0005OU-7V
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 09:22:47 +0000
Received: from [85.158.137.99:41614] by server-14.bemta-3.messagelabs.com id
	35/39-12788-66C9F805; Tue, 30 Oct 2012 09:22:46 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1351588965!12223201!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16962 invoked from network); 30 Oct 2012 09:22:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 09:22:46 -0000
X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="15482218"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 09:22:45 +0000
Received: from mac.citrite.net (10.31.3.235) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 30 Oct 2012 09:22:44 +0000
From: Roger Pau Monne 
To: 
Date: Tue, 30 Oct 2012 10:22:37 +0100
Message-ID: <1351588958-75040-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
MIME-Version: 1.0
Cc: Christoph Egger ,
	Roger Pau Monne 
Subject: [Xen-devel] [PATCH 1/2] autoconf: check for wget and ftp
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Some OSes don't come with wget by default, so ftp should be choosen
on those. Add an autoconf check to check for wget and ftp, and
replace the usage of hardcoded wget in tools.

Signed-off-by: Christoph Egger 
Signed-off-by: Roger Pau Monne 
---
Please run autoconf after applying this patch.
---
 config/StdGNU.mk                  |    2 --
 config/Tools.mk.in                |    1 +
 tools/configure.ac                |    2 ++
 tools/firmware/etherboot/Makefile |    2 +-
 tools/m4/fetcher.m4               |   14 ++++++++++++++
 5 files changed, 18 insertions(+), 3 deletions(-)
 create mode 100644 tools/m4/fetcher.m4

diff --git a/config/StdGNU.mk b/config/StdGNU.mk
index b6adbbe..3febe8d 100644
--- a/config/StdGNU.mk
+++ b/config/StdGNU.mk
@@ -22,8 +22,6 @@ MSGMERGE   = msgmerge
 # Allow git to be wrappered in the environment
 GIT        ?= git
 
-WGET       ?= wget -c
-
 INSTALL      = install
 INSTALL_DIR  = $(INSTALL) -d -m0755 -p
 INSTALL_DATA = $(INSTALL) -m0644 -p
diff --git a/config/Tools.mk.in b/config/Tools.mk.in
index a6ecf48..a78f211 100644
--- a/config/Tools.mk.in
+++ b/config/Tools.mk.in
@@ -22,6 +22,7 @@ AS86                := @AS86@
 LD86                := @LD86@
 BCC                 := @BCC@
 IASL                := @IASL@
+FETCHER             := @FETCHER@
 
 # Extra folder for libs/includes
 PREPEND_INCLUDES    := @PREPEND_INCLUDES@
diff --git a/tools/configure.ac b/tools/configure.ac
index 3318fea..e708f01 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -35,6 +35,7 @@ m4_include([m4/curses.m4])
 m4_include([m4/pthread.m4])
 m4_include([m4/ptyfuncs.m4])
 m4_include([m4/extfs.m4])
+m4_include([m4/fetcher.m4])
 
 # Enable/disable options
 AX_ARG_DEFAULT_DISABLE([githttp], [Download GIT repositories via HTTP])
@@ -117,6 +118,7 @@ esac
  AX_CHECK_UUID
  AX_CHECK_CURSES
 PKG_CHECK_MODULES(glib, [glib-2.0 >= 2.12])
+AX_CHECK_FETCHER
 
 # Checks for libraries.
 AC_CHECK_HEADER([bzlib.h], [
diff --git a/tools/firmware/etherboot/Makefile b/tools/firmware/etherboot/Makefile
index a195888..15561fc 100644
--- a/tools/firmware/etherboot/Makefile
+++ b/tools/firmware/etherboot/Makefile
@@ -28,7 +28,7 @@ all: $(ROMS)
 	$(MAKE) -C $D/src bin/$(*F).rom
 
 $T:
-	if ! wget -O _$T $(IPXE_TARBALL_URL); then \
+	if ! $(FETCHER) _$T $(IPXE_TARBALL_URL); then \
 		$(GIT) clone $(IPXE_GIT_URL) $D.git; \
 		(cd $D.git && $(GIT) archive --format=tar --prefix=$D/ \
 		$(IPXE_GIT_TAG) | gzip >../_$T); \
diff --git a/tools/m4/fetcher.m4 b/tools/m4/fetcher.m4
new file mode 100644
index 0000000..86f33b3
--- /dev/null
+++ b/tools/m4/fetcher.m4
@@ -0,0 +1,14 @@
+AC_DEFUN([AX_CHECK_FETCHER], [
+AC_PATH_PROG([WGET],[wget], [no])
+AS_IF([test x"$WGET" != x"no"], [
+    FETCHER="$WGET -c -O"
+], [
+    AC_PATH_PROG([FTP],[ftp], [no])
+    AS_IF([test x"$FTP" != x"no"], [
+        FETCHER="$FTP -o"
+    ], [
+        AC_MSG_ERROR([cannot find wget or ftp])
+    ])
+])
+AC_SUBST(FETCHER)
+])
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 09:23:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 09:23:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT824-0005Ol-Ho; Tue, 30 Oct 2012 09:22:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT823-0005OU-7V
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 09:22:47 +0000
Received: from [85.158.137.99:41614] by server-14.bemta-3.messagelabs.com id
	35/39-12788-66C9F805; Tue, 30 Oct 2012 09:22:46 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1351588965!12223201!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16962 invoked from network); 30 Oct 2012 09:22:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 09:22:46 -0000
X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="15482218"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 09:22:45 +0000
Received: from mac.citrite.net (10.31.3.235) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 30 Oct 2012 09:22:44 +0000
From: Roger Pau Monne 
To: 
Date: Tue, 30 Oct 2012 10:22:37 +0100
Message-ID: <1351588958-75040-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
MIME-Version: 1.0
Cc: Christoph Egger ,
	Roger Pau Monne 
Subject: [Xen-devel] [PATCH 1/2] autoconf: check for wget and ftp
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Some OSes don't come with wget by default, so ftp should be choosen
on those. Add an autoconf check to check for wget and ftp, and
replace the usage of hardcoded wget in tools.

Signed-off-by: Christoph Egger 
Signed-off-by: Roger Pau Monne 
---
Please run autoconf after applying this patch.
---
 config/StdGNU.mk                  |    2 --
 config/Tools.mk.in                |    1 +
 tools/configure.ac                |    2 ++
 tools/firmware/etherboot/Makefile |    2 +-
 tools/m4/fetcher.m4               |   14 ++++++++++++++
 5 files changed, 18 insertions(+), 3 deletions(-)
 create mode 100644 tools/m4/fetcher.m4

diff --git a/config/StdGNU.mk b/config/StdGNU.mk
index b6adbbe..3febe8d 100644
--- a/config/StdGNU.mk
+++ b/config/StdGNU.mk
@@ -22,8 +22,6 @@ MSGMERGE   = msgmerge
 # Allow git to be wrappered in the environment
 GIT        ?= git
 
-WGET       ?= wget -c
-
 INSTALL      = install
 INSTALL_DIR  = $(INSTALL) -d -m0755 -p
 INSTALL_DATA = $(INSTALL) -m0644 -p
diff --git a/config/Tools.mk.in b/config/Tools.mk.in
index a6ecf48..a78f211 100644
--- a/config/Tools.mk.in
+++ b/config/Tools.mk.in
@@ -22,6 +22,7 @@ AS86                := @AS86@
 LD86                := @LD86@
 BCC                 := @BCC@
 IASL                := @IASL@
+FETCHER             := @FETCHER@
 
 # Extra folder for libs/includes
 PREPEND_INCLUDES    := @PREPEND_INCLUDES@
diff --git a/tools/configure.ac b/tools/configure.ac
index 3318fea..e708f01 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -35,6 +35,7 @@ m4_include([m4/curses.m4])
 m4_include([m4/pthread.m4])
 m4_include([m4/ptyfuncs.m4])
 m4_include([m4/extfs.m4])
+m4_include([m4/fetcher.m4])
 
 # Enable/disable options
 AX_ARG_DEFAULT_DISABLE([githttp], [Download GIT repositories via HTTP])
@@ -117,6 +118,7 @@ esac
  AX_CHECK_UUID
  AX_CHECK_CURSES
 PKG_CHECK_MODULES(glib, [glib-2.0 >= 2.12])
+AX_CHECK_FETCHER
 
 # Checks for libraries.
 AC_CHECK_HEADER([bzlib.h], [
diff --git a/tools/firmware/etherboot/Makefile b/tools/firmware/etherboot/Makefile
index a195888..15561fc 100644
--- a/tools/firmware/etherboot/Makefile
+++ b/tools/firmware/etherboot/Makefile
@@ -28,7 +28,7 @@ all: $(ROMS)
 	$(MAKE) -C $D/src bin/$(*F).rom
 
 $T:
-	if ! wget -O _$T $(IPXE_TARBALL_URL); then \
+	if ! $(FETCHER) _$T $(IPXE_TARBALL_URL); then \
 		$(GIT) clone $(IPXE_GIT_URL) $D.git; \
 		(cd $D.git && $(GIT) archive --format=tar --prefix=$D/ \
 		$(IPXE_GIT_TAG) | gzip >../_$T); \
diff --git a/tools/m4/fetcher.m4 b/tools/m4/fetcher.m4
new file mode 100644
index 0000000..86f33b3
--- /dev/null
+++ b/tools/m4/fetcher.m4
@@ -0,0 +1,14 @@
+AC_DEFUN([AX_CHECK_FETCHER], [
+AC_PATH_PROG([WGET],[wget], [no])
+AS_IF([test x"$WGET" != x"no"], [
+    FETCHER="$WGET -c -O"
+], [
+    AC_PATH_PROG([FTP],[ftp], [no])
+    AS_IF([test x"$FTP" != x"no"], [
+        FETCHER="$FTP -o"
+    ], [
+        AC_MSG_ERROR([cannot find wget or ftp])
+    ])
+])
+AC_SUBST(FETCHER)
+])
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 09:23:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 09:23:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT824-0005Ot-TZ; Tue, 30 Oct 2012 09:22:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT823-0005OW-Ap
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 09:22:47 +0000
Received: from [85.158.137.99:43061] by server-16.bemta-3.messagelabs.com id
	6A/DD-07461-66C9F805; Tue, 30 Oct 2012 09:22:46 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1351588965!12223201!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTYzOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16968 invoked from network); 30 Oct 2012 09:22:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 09:22:46 -0000
X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="15482219"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 09:22:45 +0000
Received: from mac.citrite.net (10.31.3.235) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 30 Oct 2012 09:22:45 +0000
From: Roger Pau Monne 
To: 
Date: Tue, 30 Oct 2012 10:22:38 +0100
Message-ID: <1351588958-75040-2-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1351588958-75040-1-git-send-email-roger.pau@citrix.com>
References: <1351588958-75040-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne 
Subject: [Xen-devel] [PATCH 2/2] autoconf: bash is not needed on NetBSD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Remove check for bash on NetBSD, since it is not needed for hotplug
scripts (NetBSD hotplug scripts use sh) or the build system.

Signed-off-by: Roger Pau Monne 
---
 tools/configure.ac |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/tools/configure.ac b/tools/configure.ac
index e708f01..47607ae 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -93,7 +93,11 @@ AS_IF([test "x$ocamltools" = "xy"], [
         ocamltools="n"
     ])
 ])
-AX_PATH_PROG_OR_FAIL([BASH], [bash])
+case "$host_os" in
+linux*)
+    AX_PATH_PROG_OR_FAIL([BASH], [bash])
+    ;;
+esac
 AS_IF([echo "$PYTHON" | grep -q "^/"], [
     PYTHONPATH=$PYTHON
     PYTHON=`basename $PYTHONPATH`
-- 
1.7.7.5 (Apple Git-26)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 09:26:01 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 09:26:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT850-0005gc-G0; Tue, 30 Oct 2012 09:25:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT84y-0005gO-1I
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 09:25:48 +0000
Received: from [85.158.137.99:21664] by server-10.bemta-3.messagelabs.com id
	11/F0-00901-B1D9F805; Tue, 30 Oct 2012 09:25:47 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1351589130!16977749!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzk3Mjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2856 invoked from network); 30 Oct 2012 09:25:32 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 09:25:32 -0000
X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="42850396"
Received: from ftlpex01cl01.citrite.net ([10.13.107.78])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	30 Oct 2012 09:25:29 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 30 Oct 2012 05:25:28 -0400
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[0.0.0.0])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TT84K-0006bb-Fr;
	Tue, 30 Oct 2012 09:25:08 +0000
Message-ID: <508F9CF3.3090706@eu.citrix.com>
Date: Tue, 30 Oct 2012 10:25:07 +0100
From: George Dunlap 
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: "Liu, Jinsong" 
References: 
	
	
	<50852EB6.4060705@eu.citrix.com>
	
In-Reply-To: 
Cc: Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	Ian Jackson , Jan Beulich 
Subject: Re: [Xen-devel] [Patch 4/5] X86/vMCE: handle broken page occurred
	before migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Jinsong,

I'm at UDS now, but I'll try to review the new patches in the next few days.

If you end up sending these patches again, could you please send them in 
a more normal "patchbomb-style" format?  I.e., with a "00/02" header 
describing what's new in the series, and then naming them 01/02 and 
02/02 (instead of 4 and 5, when 1-3 have been applied for months)?

The easiest way to do this is to use hg's patchbomb extension; there's a 
description of how to set it up here:

http://wiki.xen.org/wiki/SubmittingXenPatches

It's a few minutes to set up, but it's well worth it both for us and for 
you.

Thanks,
  -George

On 29/10/12 16:21, Liu, Jinsong wrote:
> X86/vMCE: handle broken page occurred before migration
>
> This patch handles guest broken page which occur before migration.
>
> At sender, the broken page would be mapped but not copied to target
> (otherwise it may trigger more serious error, say, SRAR error).
> While its pfn_type and pfn number would be transferred to target
> so that target take appropriate action.
>
> At target, it would set p2m as p2m_ram_broken for broken page, so that
> if guest access the broken page again, it would kill itself as expected.
>
> Signed-off-by: Liu, Jinsong 
>
> diff -r e27a6d53ac15 tools/libxc/xc_domain.c
> --- a/tools/libxc/xc_domain.c	Thu Oct 11 01:52:33 2012 +0800
> +++ b/tools/libxc/xc_domain.c	Thu Oct 25 05:49:10 2012 +0800
> @@ -283,6 +283,22 @@
>       return ret;
>   }
>   
> +/* set broken page p2m */
> +int xc_set_broken_page_p2m(xc_interface *xch,
> +                           uint32_t domid,
> +                           unsigned long pfn)
> +{
> +    int ret;
> +    DECLARE_DOMCTL;
> +
> +    domctl.cmd = XEN_DOMCTL_set_broken_page_p2m;
> +    domctl.domain = (domid_t)domid;
> +    domctl.u.set_broken_page_p2m.pfn = pfn;
> +    ret = do_domctl(xch, &domctl);
> +
> +    return ret ? -1 : 0;
> +}
> +
>   /* get info from hvm guest for save */
>   int xc_domain_hvm_getcontext(xc_interface *xch,
>                                uint32_t domid,
> diff -r e27a6d53ac15 tools/libxc/xc_domain_restore.c
> --- a/tools/libxc/xc_domain_restore.c	Thu Oct 11 01:52:33 2012 +0800
> +++ b/tools/libxc/xc_domain_restore.c	Thu Oct 25 05:49:10 2012 +0800
> @@ -962,9 +962,15 @@
>   
>       countpages = count;
>       for (i = oldcount; i < buf->nr_pages; ++i)
> -        if ((buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) == XEN_DOMCTL_PFINFO_XTAB
> -            ||(buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) == XEN_DOMCTL_PFINFO_XALLOC)
> +    {
> +        unsigned long pagetype;
> +
> +        pagetype = buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK;
> +        if ( pagetype == XEN_DOMCTL_PFINFO_XTAB ||
> +             pagetype == XEN_DOMCTL_PFINFO_BROKEN ||
> +             pagetype == XEN_DOMCTL_PFINFO_XALLOC )
>               --countpages;
> +    }
>   
>       if (!countpages)
>           return count;
> @@ -1200,6 +1206,17 @@
>               /* a bogus/unmapped/allocate-only page: skip it */
>               continue;
>   
> +        if ( pagetype == XEN_DOMCTL_PFINFO_BROKEN )
> +        {
> +            if ( xc_set_broken_page_p2m(xch, dom, pfn) )
> +            {
> +                ERROR("Set p2m for broken page failed, "
> +                      "dom=%d, pfn=%lx\n", dom, pfn);
> +                goto err_mapped;
> +            }
> +            continue;
> +        }
> +
>           if (pfn_err[i])
>           {
>               ERROR("unexpected PFN mapping failure pfn %lx map_mfn %lx p2m_mfn %lx",
> diff -r e27a6d53ac15 tools/libxc/xc_domain_save.c
> --- a/tools/libxc/xc_domain_save.c	Thu Oct 11 01:52:33 2012 +0800
> +++ b/tools/libxc/xc_domain_save.c	Thu Oct 25 05:49:10 2012 +0800
> @@ -1277,6 +1277,13 @@
>                   if ( !hvm )
>                       gmfn = pfn_to_mfn(gmfn);
>   
> +                if ( pfn_type[j] == XEN_DOMCTL_PFINFO_BROKEN )
> +                {
> +                    pfn_type[j] |= pfn_batch[j];
> +                    ++run;
> +                    continue;
> +                }
> +
>                   if ( pfn_err[j] )
>                   {
>                       if ( pfn_type[j] == XEN_DOMCTL_PFINFO_XTAB )
> @@ -1371,8 +1378,12 @@
>                       }
>                   }
>   
> -                /* skip pages that aren't present or are alloc-only */
> +                /*
> +                 * skip pages that aren't present,
> +                 * or are broken, or are alloc-only
> +                 */
>                   if ( pagetype == XEN_DOMCTL_PFINFO_XTAB
> +                    || pagetype == XEN_DOMCTL_PFINFO_BROKEN
>                       || pagetype == XEN_DOMCTL_PFINFO_XALLOC )
>                       continue;
>   
> diff -r e27a6d53ac15 tools/libxc/xenctrl.h
> --- a/tools/libxc/xenctrl.h	Thu Oct 11 01:52:33 2012 +0800
> +++ b/tools/libxc/xenctrl.h	Thu Oct 25 05:49:10 2012 +0800
> @@ -575,6 +575,17 @@
>                             xc_domaininfo_t *info);
>   
>   /**
> + * This function set p2m for broken page
> + * &parm xch a handle to an open hypervisor interface
> + * @parm domid the domain id which broken page belong to
> + * @parm pfn the pfn number of the broken page
> + * @return 0 on success, -1 on failure
> + */
> +int xc_set_broken_page_p2m(xc_interface *xch,
> +                           uint32_t domid,
> +                           unsigned long pfn);
> +
> +/**
>    * This function returns information about the context of a hvm domain
>    * @parm xch a handle to an open hypervisor interface
>    * @parm domid the domain to get information from
> diff -r e27a6d53ac15 xen/arch/x86/domctl.c
> --- a/xen/arch/x86/domctl.c	Thu Oct 11 01:52:33 2012 +0800
> +++ b/xen/arch/x86/domctl.c	Thu Oct 25 05:49:10 2012 +0800
> @@ -209,12 +209,18 @@
>                   for ( j = 0; j < k; j++ )
>                   {
>                       unsigned long type = 0;
> +                    p2m_type_t t;
>   
> -                    page = get_page_from_gfn(d, arr[j], NULL, P2M_ALLOC);
> +                    page = get_page_from_gfn(d, arr[j], &t, P2M_ALLOC);
>   
>                       if ( unlikely(!page) ||
>                            unlikely(is_xen_heap_page(page)) )
> -                        type = XEN_DOMCTL_PFINFO_XTAB;
> +                    {
> +                        if ( p2m_is_broken(t) )
> +                            type = XEN_DOMCTL_PFINFO_BROKEN;
> +                        else
> +                            type = XEN_DOMCTL_PFINFO_XTAB;
> +                    }
>                       else
>                       {
>                           switch( page->u.inuse.type_info & PGT_type_mask )
> @@ -235,6 +241,9 @@
>   
>                           if ( page->u.inuse.type_info & PGT_pinned )
>                               type |= XEN_DOMCTL_PFINFO_LPINTAB;
> +
> +                        if ( page->count_info & PGC_broken )
> +                            type = XEN_DOMCTL_PFINFO_BROKEN;
>                       }
>   
>                       if ( page )
> @@ -1568,6 +1577,28 @@
>       }
>       break;
>   
> +    case XEN_DOMCTL_set_broken_page_p2m:
> +    {
> +        struct domain *d;
> +        p2m_type_t pt;
> +        unsigned long pfn;
> +
> +        d = rcu_lock_domain_by_id(domctl->domain);
> +        if ( d != NULL )
> +        {
> +            pfn = domctl->u.set_broken_page_p2m.pfn;
> +
> +            get_gfn_query(d, pfn, &pt);
> +            p2m_change_type(d, pfn, pt, p2m_ram_broken);
> +            put_gfn(d, pfn);
> +
> +            rcu_unlock_domain(d);
> +        }
> +        else
> +            ret = -ESRCH;
> +    }
> +    break;
> +
>       default:
>           ret = iommu_do_domctl(domctl, u_domctl);
>           break;
> diff -r e27a6d53ac15 xen/include/public/domctl.h
> --- a/xen/include/public/domctl.h	Thu Oct 11 01:52:33 2012 +0800
> +++ b/xen/include/public/domctl.h	Thu Oct 25 05:49:10 2012 +0800
> @@ -136,6 +136,7 @@
>   #define XEN_DOMCTL_PFINFO_LPINTAB (0x1U<<31)
>   #define XEN_DOMCTL_PFINFO_XTAB    (0xfU<<28) /* invalid page */
>   #define XEN_DOMCTL_PFINFO_XALLOC  (0xeU<<28) /* allocate-only page */
> +#define XEN_DOMCTL_PFINFO_BROKEN  (0xdU<<28) /* broken page */
>   #define XEN_DOMCTL_PFINFO_PAGEDTAB (0x8U<<28)
>   #define XEN_DOMCTL_PFINFO_LTAB_MASK (0xfU<<28)
>   
> @@ -835,6 +836,12 @@
>   typedef struct xen_domctl_set_access_required xen_domctl_set_access_required_t;
>   DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_access_required_t);
>   
> +struct xen_domctl_set_broken_page_p2m {
> +    uint64_aligned_t pfn;
> +};
> +typedef struct xen_domctl_set_broken_page_p2m xen_domctl_set_broken_page_p2m_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_broken_page_p2m_t);
> +
>   struct xen_domctl {
>       uint32_t cmd;
>   #define XEN_DOMCTL_createdomain                   1
> @@ -900,6 +907,7 @@
>   #define XEN_DOMCTL_set_access_required           64
>   #define XEN_DOMCTL_audit_p2m                     65
>   #define XEN_DOMCTL_set_virq_handler              66
> +#define XEN_DOMCTL_set_broken_page_p2m           67
>   #define XEN_DOMCTL_gdbsx_guestmemio            1000
>   #define XEN_DOMCTL_gdbsx_pausevcpu             1001
>   #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
> @@ -955,6 +963,7 @@
>           struct xen_domctl_audit_p2m         audit_p2m;
>           struct xen_domctl_set_virq_handler  set_virq_handler;
>           struct xen_domctl_gdbsx_memio       gdbsx_guest_memio;
> +        struct xen_domctl_set_broken_page_p2m set_broken_page_p2m;
>           struct xen_domctl_gdbsx_pauseunp_vcpu gdbsx_pauseunp_vcpu;
>           struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
>           uint8_t                             pad[128];


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 09:26:01 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 09:26:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT850-0005gc-G0; Tue, 30 Oct 2012 09:25:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT84y-0005gO-1I
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 09:25:48 +0000
Received: from [85.158.137.99:21664] by server-10.bemta-3.messagelabs.com id
	11/F0-00901-B1D9F805; Tue, 30 Oct 2012 09:25:47 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1351589130!16977749!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzk3Mjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2856 invoked from network); 30 Oct 2012 09:25:32 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 09:25:32 -0000
X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="42850396"
Received: from ftlpex01cl01.citrite.net ([10.13.107.78])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	30 Oct 2012 09:25:29 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 30 Oct 2012 05:25:28 -0400
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[0.0.0.0])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TT84K-0006bb-Fr;
	Tue, 30 Oct 2012 09:25:08 +0000
Message-ID: <508F9CF3.3090706@eu.citrix.com>
Date: Tue, 30 Oct 2012 10:25:07 +0100
From: George Dunlap 
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: "Liu, Jinsong" 
References: 
	
	
	<50852EB6.4060705@eu.citrix.com>
	
In-Reply-To: 
Cc: Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	Ian Jackson , Jan Beulich 
Subject: Re: [Xen-devel] [Patch 4/5] X86/vMCE: handle broken page occurred
	before migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Jinsong,

I'm at UDS now, but I'll try to review the new patches in the next few days.

If you end up sending these patches again, could you please send them in 
a more normal "patchbomb-style" format?  I.e., with a "00/02" header 
describing what's new in the series, and then naming them 01/02 and 
02/02 (instead of 4 and 5, when 1-3 have been applied for months)?

The easiest way to do this is to use hg's patchbomb extension; there's a 
description of how to set it up here:

http://wiki.xen.org/wiki/SubmittingXenPatches

It's a few minutes to set up, but it's well worth it both for us and for 
you.

Thanks,
  -George

On 29/10/12 16:21, Liu, Jinsong wrote:
> X86/vMCE: handle broken page occurred before migration
>
> This patch handles guest broken page which occur before migration.
>
> At sender, the broken page would be mapped but not copied to target
> (otherwise it may trigger more serious error, say, SRAR error).
> While its pfn_type and pfn number would be transferred to target
> so that target take appropriate action.
>
> At target, it would set p2m as p2m_ram_broken for broken page, so that
> if guest access the broken page again, it would kill itself as expected.
>
> Signed-off-by: Liu, Jinsong 
>
> diff -r e27a6d53ac15 tools/libxc/xc_domain.c
> --- a/tools/libxc/xc_domain.c	Thu Oct 11 01:52:33 2012 +0800
> +++ b/tools/libxc/xc_domain.c	Thu Oct 25 05:49:10 2012 +0800
> @@ -283,6 +283,22 @@
>       return ret;
>   }
>   
> +/* set broken page p2m */
> +int xc_set_broken_page_p2m(xc_interface *xch,
> +                           uint32_t domid,
> +                           unsigned long pfn)
> +{
> +    int ret;
> +    DECLARE_DOMCTL;
> +
> +    domctl.cmd = XEN_DOMCTL_set_broken_page_p2m;
> +    domctl.domain = (domid_t)domid;
> +    domctl.u.set_broken_page_p2m.pfn = pfn;
> +    ret = do_domctl(xch, &domctl);
> +
> +    return ret ? -1 : 0;
> +}
> +
>   /* get info from hvm guest for save */
>   int xc_domain_hvm_getcontext(xc_interface *xch,
>                                uint32_t domid,
> diff -r e27a6d53ac15 tools/libxc/xc_domain_restore.c
> --- a/tools/libxc/xc_domain_restore.c	Thu Oct 11 01:52:33 2012 +0800
> +++ b/tools/libxc/xc_domain_restore.c	Thu Oct 25 05:49:10 2012 +0800
> @@ -962,9 +962,15 @@
>   
>       countpages = count;
>       for (i = oldcount; i < buf->nr_pages; ++i)
> -        if ((buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) == XEN_DOMCTL_PFINFO_XTAB
> -            ||(buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) == XEN_DOMCTL_PFINFO_XALLOC)
> +    {
> +        unsigned long pagetype;
> +
> +        pagetype = buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK;
> +        if ( pagetype == XEN_DOMCTL_PFINFO_XTAB ||
> +             pagetype == XEN_DOMCTL_PFINFO_BROKEN ||
> +             pagetype == XEN_DOMCTL_PFINFO_XALLOC )
>               --countpages;
> +    }
>   
>       if (!countpages)
>           return count;
> @@ -1200,6 +1206,17 @@
>               /* a bogus/unmapped/allocate-only page: skip it */
>               continue;
>   
> +        if ( pagetype == XEN_DOMCTL_PFINFO_BROKEN )
> +        {
> +            if ( xc_set_broken_page_p2m(xch, dom, pfn) )
> +            {
> +                ERROR("Set p2m for broken page failed, "
> +                      "dom=%d, pfn=%lx\n", dom, pfn);
> +                goto err_mapped;
> +            }
> +            continue;
> +        }
> +
>           if (pfn_err[i])
>           {
>               ERROR("unexpected PFN mapping failure pfn %lx map_mfn %lx p2m_mfn %lx",
> diff -r e27a6d53ac15 tools/libxc/xc_domain_save.c
> --- a/tools/libxc/xc_domain_save.c	Thu Oct 11 01:52:33 2012 +0800
> +++ b/tools/libxc/xc_domain_save.c	Thu Oct 25 05:49:10 2012 +0800
> @@ -1277,6 +1277,13 @@
>                   if ( !hvm )
>                       gmfn = pfn_to_mfn(gmfn);
>   
> +                if ( pfn_type[j] == XEN_DOMCTL_PFINFO_BROKEN )
> +                {
> +                    pfn_type[j] |= pfn_batch[j];
> +                    ++run;
> +                    continue;
> +                }
> +
>                   if ( pfn_err[j] )
>                   {
>                       if ( pfn_type[j] == XEN_DOMCTL_PFINFO_XTAB )
> @@ -1371,8 +1378,12 @@
>                       }
>                   }
>   
> -                /* skip pages that aren't present or are alloc-only */
> +                /*
> +                 * skip pages that aren't present,
> +                 * or are broken, or are alloc-only
> +                 */
>                   if ( pagetype == XEN_DOMCTL_PFINFO_XTAB
> +                    || pagetype == XEN_DOMCTL_PFINFO_BROKEN
>                       || pagetype == XEN_DOMCTL_PFINFO_XALLOC )
>                       continue;
>   
> diff -r e27a6d53ac15 tools/libxc/xenctrl.h
> --- a/tools/libxc/xenctrl.h	Thu Oct 11 01:52:33 2012 +0800
> +++ b/tools/libxc/xenctrl.h	Thu Oct 25 05:49:10 2012 +0800
> @@ -575,6 +575,17 @@
>                             xc_domaininfo_t *info);
>   
>   /**
> + * This function set p2m for broken page
> + * &parm xch a handle to an open hypervisor interface
> + * @parm domid the domain id which broken page belong to
> + * @parm pfn the pfn number of the broken page
> + * @return 0 on success, -1 on failure
> + */
> +int xc_set_broken_page_p2m(xc_interface *xch,
> +                           uint32_t domid,
> +                           unsigned long pfn);
> +
> +/**
>    * This function returns information about the context of a hvm domain
>    * @parm xch a handle to an open hypervisor interface
>    * @parm domid the domain to get information from
> diff -r e27a6d53ac15 xen/arch/x86/domctl.c
> --- a/xen/arch/x86/domctl.c	Thu Oct 11 01:52:33 2012 +0800
> +++ b/xen/arch/x86/domctl.c	Thu Oct 25 05:49:10 2012 +0800
> @@ -209,12 +209,18 @@
>                   for ( j = 0; j < k; j++ )
>                   {
>                       unsigned long type = 0;
> +                    p2m_type_t t;
>   
> -                    page = get_page_from_gfn(d, arr[j], NULL, P2M_ALLOC);
> +                    page = get_page_from_gfn(d, arr[j], &t, P2M_ALLOC);
>   
>                       if ( unlikely(!page) ||
>                            unlikely(is_xen_heap_page(page)) )
> -                        type = XEN_DOMCTL_PFINFO_XTAB;
> +                    {
> +                        if ( p2m_is_broken(t) )
> +                            type = XEN_DOMCTL_PFINFO_BROKEN;
> +                        else
> +                            type = XEN_DOMCTL_PFINFO_XTAB;
> +                    }
>                       else
>                       {
>                           switch( page->u.inuse.type_info & PGT_type_mask )
> @@ -235,6 +241,9 @@
>   
>                           if ( page->u.inuse.type_info & PGT_pinned )
>                               type |= XEN_DOMCTL_PFINFO_LPINTAB;
> +
> +                        if ( page->count_info & PGC_broken )
> +                            type = XEN_DOMCTL_PFINFO_BROKEN;
>                       }
>   
>                       if ( page )
> @@ -1568,6 +1577,28 @@
>       }
>       break;
>   
> +    case XEN_DOMCTL_set_broken_page_p2m:
> +    {
> +        struct domain *d;
> +        p2m_type_t pt;
> +        unsigned long pfn;
> +
> +        d = rcu_lock_domain_by_id(domctl->domain);
> +        if ( d != NULL )
> +        {
> +            pfn = domctl->u.set_broken_page_p2m.pfn;
> +
> +            get_gfn_query(d, pfn, &pt);
> +            p2m_change_type(d, pfn, pt, p2m_ram_broken);
> +            put_gfn(d, pfn);
> +
> +            rcu_unlock_domain(d);
> +        }
> +        else
> +            ret = -ESRCH;
> +    }
> +    break;
> +
>       default:
>           ret = iommu_do_domctl(domctl, u_domctl);
>           break;
> diff -r e27a6d53ac15 xen/include/public/domctl.h
> --- a/xen/include/public/domctl.h	Thu Oct 11 01:52:33 2012 +0800
> +++ b/xen/include/public/domctl.h	Thu Oct 25 05:49:10 2012 +0800
> @@ -136,6 +136,7 @@
>   #define XEN_DOMCTL_PFINFO_LPINTAB (0x1U<<31)
>   #define XEN_DOMCTL_PFINFO_XTAB    (0xfU<<28) /* invalid page */
>   #define XEN_DOMCTL_PFINFO_XALLOC  (0xeU<<28) /* allocate-only page */
> +#define XEN_DOMCTL_PFINFO_BROKEN  (0xdU<<28) /* broken page */
>   #define XEN_DOMCTL_PFINFO_PAGEDTAB (0x8U<<28)
>   #define XEN_DOMCTL_PFINFO_LTAB_MASK (0xfU<<28)
>   
> @@ -835,6 +836,12 @@
>   typedef struct xen_domctl_set_access_required xen_domctl_set_access_required_t;
>   DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_access_required_t);
>   
> +struct xen_domctl_set_broken_page_p2m {
> +    uint64_aligned_t pfn;
> +};
> +typedef struct xen_domctl_set_broken_page_p2m xen_domctl_set_broken_page_p2m_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_broken_page_p2m_t);
> +
>   struct xen_domctl {
>       uint32_t cmd;
>   #define XEN_DOMCTL_createdomain                   1
> @@ -900,6 +907,7 @@
>   #define XEN_DOMCTL_set_access_required           64
>   #define XEN_DOMCTL_audit_p2m                     65
>   #define XEN_DOMCTL_set_virq_handler              66
> +#define XEN_DOMCTL_set_broken_page_p2m           67
>   #define XEN_DOMCTL_gdbsx_guestmemio            1000
>   #define XEN_DOMCTL_gdbsx_pausevcpu             1001
>   #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
> @@ -955,6 +963,7 @@
>           struct xen_domctl_audit_p2m         audit_p2m;
>           struct xen_domctl_set_virq_handler  set_virq_handler;
>           struct xen_domctl_gdbsx_memio       gdbsx_guest_memio;
> +        struct xen_domctl_set_broken_page_p2m set_broken_page_p2m;
>           struct xen_domctl_gdbsx_pauseunp_vcpu gdbsx_pauseunp_vcpu;
>           struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
>           uint8_t                             pad[128];


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 09:28:12 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 09:28:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT878-0005qI-25; Tue, 30 Oct 2012 09:28:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT876-0005qA-Cu
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 09:28:00 +0000
Received: from [85.158.137.99:2389] by server-8.bemta-3.messagelabs.com id
	F9/09-10525-F9D9F805; Tue, 30 Oct 2012 09:27:59 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1351589278!13842695!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28763 invoked from network); 30 Oct 2012 09:27:58 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 09:27:58 -0000
Received: by mail-we0-f171.google.com with SMTP id s43so30598wey.30
	for ;
	Tue, 30 Oct 2012 02:27:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=lPocQHiHs7GS0MFdhRKRwY3ni48Aof3LTdMByBF0OK8=;
	b=o6Tya3RPLzwplIk+wHCSNtmTYCGOp08AjrLU1OPLCg/r1owK/uCvFJHBGdHZiC/b9b
	737YaLU1IgC2YLubvQ8cEjI7rjZNmBjbcHd3/rsd+/BgC+XULaTffQqv3bmbBOEuK2sa
	44XVtOZLCTGnpIUt/NWeWhdwOUNCK9kfgHNBJM4jD5dugn2UOrCbsibuT2Fk8HPoShvu
	Bo2n/fXpBzLQXOp/p1vBVUMUMurZu4eBw/OuGokf44rkXKCWlJh2ReIvrGZ54+LzJosZ
	ycznnsiYbghGASwydvpWEDdu3GnmRRS6FJvdiBcfmCD8CzxZkAoLXyYK26P/FnhqRRwN
	h1DA==
MIME-Version: 1.0
Received: by 10.180.91.71 with SMTP id cc7mr1576295wib.2.1351589277796; Tue,
	30 Oct 2012 02:27:57 -0700 (PDT)
Received: by 10.227.200.1 with HTTP; Tue, 30 Oct 2012 02:27:57 -0700 (PDT)
In-Reply-To: 
References: 
	
	
	<50852EB6.4060705@eu.citrix.com>
	
Date: Tue, 30 Oct 2012 10:27:57 +0100
X-Google-Sender-Auth: 0rdxfisFgAAlZ1hUEFjfFAvwj4Y
Message-ID: 
From: George Dunlap 
To: "Liu, Jinsong" 
Cc: Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	Ian Jackson , Jan Beulich 
Subject: Re: [Xen-devel] [Patch 4/5] X86/vMCE: handle broken page occurred
 before migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Jinsong,

I'm at UDS now, but I'll try to review the new patches in the next few days.

If you end up sending these patches again, could you please send them in
a more normal "patchbomb-style" format?  I.e., with a "00/02" header
describing what's new in the series, and then naming them 01/02 and
02/02 (instead of 4 and 5, when 1-3 have been applied for months)?

The easiest way to do this is to use hg's patchbomb extension; there's a
description of how to set it up here:

http://wiki.xen.org/wiki/SubmittingXenPatches

It's a few minutes to set up, but it's well worth it both for us and for
you.

Thanks,
  -George

On Mon, Oct 29, 2012 at 4:21 PM, Liu, Jinsong  wrote:
> X86/vMCE: handle broken page occurred before migration
>
> This patch handles guest broken page which occur before migration.
>
> At sender, the broken page would be mapped but not copied to target
> (otherwise it may trigger more serious error, say, SRAR error).
> While its pfn_type and pfn number would be transferred to target
> so that target take appropriate action.
>
> At target, it would set p2m as p2m_ram_broken for broken page, so that
> if guest access the broken page again, it would kill itself as expected.
>
> Signed-off-by: Liu, Jinsong 
>
> diff -r e27a6d53ac15 tools/libxc/xc_domain.c
> --- a/tools/libxc/xc_domain.c   Thu Oct 11 01:52:33 2012 +0800
> +++ b/tools/libxc/xc_domain.c   Thu Oct 25 05:49:10 2012 +0800
> @@ -283,6 +283,22 @@
>      return ret;
>  }
>
> +/* set broken page p2m */
> +int xc_set_broken_page_p2m(xc_interface *xch,
> +                           uint32_t domid,
> +                           unsigned long pfn)
> +{
> +    int ret;
> +    DECLARE_DOMCTL;
> +
> +    domctl.cmd = XEN_DOMCTL_set_broken_page_p2m;
> +    domctl.domain = (domid_t)domid;
> +    domctl.u.set_broken_page_p2m.pfn = pfn;
> +    ret = do_domctl(xch, &domctl);
> +
> +    return ret ? -1 : 0;
> +}
> +
>  /* get info from hvm guest for save */
>  int xc_domain_hvm_getcontext(xc_interface *xch,
>                               uint32_t domid,
> diff -r e27a6d53ac15 tools/libxc/xc_domain_restore.c
> --- a/tools/libxc/xc_domain_restore.c   Thu Oct 11 01:52:33 2012 +0800
> +++ b/tools/libxc/xc_domain_restore.c   Thu Oct 25 05:49:10 2012 +0800
> @@ -962,9 +962,15 @@
>
>      countpages = count;
>      for (i = oldcount; i < buf->nr_pages; ++i)
> -        if ((buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) == XEN_DOMCTL_PFINFO_XTAB
> -            ||(buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) == XEN_DOMCTL_PFINFO_XALLOC)
> +    {
> +        unsigned long pagetype;
> +
> +        pagetype = buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK;
> +        if ( pagetype == XEN_DOMCTL_PFINFO_XTAB ||
> +             pagetype == XEN_DOMCTL_PFINFO_BROKEN ||
> +             pagetype == XEN_DOMCTL_PFINFO_XALLOC )
>              --countpages;
> +    }
>
>      if (!countpages)
>          return count;
> @@ -1200,6 +1206,17 @@
>              /* a bogus/unmapped/allocate-only page: skip it */
>              continue;
>
> +        if ( pagetype == XEN_DOMCTL_PFINFO_BROKEN )
> +        {
> +            if ( xc_set_broken_page_p2m(xch, dom, pfn) )
> +            {
> +                ERROR("Set p2m for broken page failed, "
> +                      "dom=%d, pfn=%lx\n", dom, pfn);
> +                goto err_mapped;
> +            }
> +            continue;
> +        }
> +
>          if (pfn_err[i])
>          {
>              ERROR("unexpected PFN mapping failure pfn %lx map_mfn %lx p2m_mfn %lx",
> diff -r e27a6d53ac15 tools/libxc/xc_domain_save.c
> --- a/tools/libxc/xc_domain_save.c      Thu Oct 11 01:52:33 2012 +0800
> +++ b/tools/libxc/xc_domain_save.c      Thu Oct 25 05:49:10 2012 +0800
> @@ -1277,6 +1277,13 @@
>                  if ( !hvm )
>                      gmfn = pfn_to_mfn(gmfn);
>
> +                if ( pfn_type[j] == XEN_DOMCTL_PFINFO_BROKEN )
> +                {
> +                    pfn_type[j] |= pfn_batch[j];
> +                    ++run;
> +                    continue;
> +                }
> +
>                  if ( pfn_err[j] )
>                  {
>                      if ( pfn_type[j] == XEN_DOMCTL_PFINFO_XTAB )
> @@ -1371,8 +1378,12 @@
>                      }
>                  }
>
> -                /* skip pages that aren't present or are alloc-only */
> +                /*
> +                 * skip pages that aren't present,
> +                 * or are broken, or are alloc-only
> +                 */
>                  if ( pagetype == XEN_DOMCTL_PFINFO_XTAB
> +                    || pagetype == XEN_DOMCTL_PFINFO_BROKEN
>                      || pagetype == XEN_DOMCTL_PFINFO_XALLOC )
>                      continue;
>
> diff -r e27a6d53ac15 tools/libxc/xenctrl.h
> --- a/tools/libxc/xenctrl.h     Thu Oct 11 01:52:33 2012 +0800
> +++ b/tools/libxc/xenctrl.h     Thu Oct 25 05:49:10 2012 +0800
> @@ -575,6 +575,17 @@
>                            xc_domaininfo_t *info);
>
>  /**
> + * This function set p2m for broken page
> + * &parm xch a handle to an open hypervisor interface
> + * @parm domid the domain id which broken page belong to
> + * @parm pfn the pfn number of the broken page
> + * @return 0 on success, -1 on failure
> + */
> +int xc_set_broken_page_p2m(xc_interface *xch,
> +                           uint32_t domid,
> +                           unsigned long pfn);
> +
> +/**
>   * This function returns information about the context of a hvm domain
>   * @parm xch a handle to an open hypervisor interface
>   * @parm domid the domain to get information from
> diff -r e27a6d53ac15 xen/arch/x86/domctl.c
> --- a/xen/arch/x86/domctl.c     Thu Oct 11 01:52:33 2012 +0800
> +++ b/xen/arch/x86/domctl.c     Thu Oct 25 05:49:10 2012 +0800
> @@ -209,12 +209,18 @@
>                  for ( j = 0; j < k; j++ )
>                  {
>                      unsigned long type = 0;
> +                    p2m_type_t t;
>
> -                    page = get_page_from_gfn(d, arr[j], NULL, P2M_ALLOC);
> +                    page = get_page_from_gfn(d, arr[j], &t, P2M_ALLOC);
>
>                      if ( unlikely(!page) ||
>                           unlikely(is_xen_heap_page(page)) )
> -                        type = XEN_DOMCTL_PFINFO_XTAB;
> +                    {
> +                        if ( p2m_is_broken(t) )
> +                            type = XEN_DOMCTL_PFINFO_BROKEN;
> +                        else
> +                            type = XEN_DOMCTL_PFINFO_XTAB;
> +                    }
>                      else
>                      {
>                          switch( page->u.inuse.type_info & PGT_type_mask )
> @@ -235,6 +241,9 @@
>
>                          if ( page->u.inuse.type_info & PGT_pinned )
>                              type |= XEN_DOMCTL_PFINFO_LPINTAB;
> +
> +                        if ( page->count_info & PGC_broken )
> +                            type = XEN_DOMCTL_PFINFO_BROKEN;
>                      }
>
>                      if ( page )
> @@ -1568,6 +1577,28 @@
>      }
>      break;
>
> +    case XEN_DOMCTL_set_broken_page_p2m:
> +    {
> +        struct domain *d;
> +        p2m_type_t pt;
> +        unsigned long pfn;
> +
> +        d = rcu_lock_domain_by_id(domctl->domain);
> +        if ( d != NULL )
> +        {
> +            pfn = domctl->u.set_broken_page_p2m.pfn;
> +
> +            get_gfn_query(d, pfn, &pt);
> +            p2m_change_type(d, pfn, pt, p2m_ram_broken);
> +            put_gfn(d, pfn);
> +
> +            rcu_unlock_domain(d);
> +        }
> +        else
> +            ret = -ESRCH;
> +    }
> +    break;
> +
>      default:
>          ret = iommu_do_domctl(domctl, u_domctl);
>          break;
> diff -r e27a6d53ac15 xen/include/public/domctl.h
> --- a/xen/include/public/domctl.h       Thu Oct 11 01:52:33 2012 +0800
> +++ b/xen/include/public/domctl.h       Thu Oct 25 05:49:10 2012 +0800
> @@ -136,6 +136,7 @@
>  #define XEN_DOMCTL_PFINFO_LPINTAB (0x1U<<31)
>  #define XEN_DOMCTL_PFINFO_XTAB    (0xfU<<28) /* invalid page */
>  #define XEN_DOMCTL_PFINFO_XALLOC  (0xeU<<28) /* allocate-only page */
> +#define XEN_DOMCTL_PFINFO_BROKEN  (0xdU<<28) /* broken page */
>  #define XEN_DOMCTL_PFINFO_PAGEDTAB (0x8U<<28)
>  #define XEN_DOMCTL_PFINFO_LTAB_MASK (0xfU<<28)
>
> @@ -835,6 +836,12 @@
>  typedef struct xen_domctl_set_access_required xen_domctl_set_access_required_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_access_required_t);
>
> +struct xen_domctl_set_broken_page_p2m {
> +    uint64_aligned_t pfn;
> +};
> +typedef struct xen_domctl_set_broken_page_p2m xen_domctl_set_broken_page_p2m_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_broken_page_p2m_t);
> +
>  struct xen_domctl {
>      uint32_t cmd;
>  #define XEN_DOMCTL_createdomain                   1
> @@ -900,6 +907,7 @@
>  #define XEN_DOMCTL_set_access_required           64
>  #define XEN_DOMCTL_audit_p2m                     65
>  #define XEN_DOMCTL_set_virq_handler              66
> +#define XEN_DOMCTL_set_broken_page_p2m           67
>  #define XEN_DOMCTL_gdbsx_guestmemio            1000
>  #define XEN_DOMCTL_gdbsx_pausevcpu             1001
>  #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
> @@ -955,6 +963,7 @@
>          struct xen_domctl_audit_p2m         audit_p2m;
>          struct xen_domctl_set_virq_handler  set_virq_handler;
>          struct xen_domctl_gdbsx_memio       gdbsx_guest_memio;
> +        struct xen_domctl_set_broken_page_p2m set_broken_page_p2m;
>          struct xen_domctl_gdbsx_pauseunp_vcpu gdbsx_pauseunp_vcpu;
>          struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
>          uint8_t                             pad[128];
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 09:28:12 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 09:28:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT878-0005qI-25; Tue, 30 Oct 2012 09:28:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT876-0005qA-Cu
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 09:28:00 +0000
Received: from [85.158.137.99:2389] by server-8.bemta-3.messagelabs.com id
	F9/09-10525-F9D9F805; Tue, 30 Oct 2012 09:27:59 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1351589278!13842695!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28763 invoked from network); 30 Oct 2012 09:27:58 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 09:27:58 -0000
Received: by mail-we0-f171.google.com with SMTP id s43so30598wey.30
	for ;
	Tue, 30 Oct 2012 02:27:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=lPocQHiHs7GS0MFdhRKRwY3ni48Aof3LTdMByBF0OK8=;
	b=o6Tya3RPLzwplIk+wHCSNtmTYCGOp08AjrLU1OPLCg/r1owK/uCvFJHBGdHZiC/b9b
	737YaLU1IgC2YLubvQ8cEjI7rjZNmBjbcHd3/rsd+/BgC+XULaTffQqv3bmbBOEuK2sa
	44XVtOZLCTGnpIUt/NWeWhdwOUNCK9kfgHNBJM4jD5dugn2UOrCbsibuT2Fk8HPoShvu
	Bo2n/fXpBzLQXOp/p1vBVUMUMurZu4eBw/OuGokf44rkXKCWlJh2ReIvrGZ54+LzJosZ
	ycznnsiYbghGASwydvpWEDdu3GnmRRS6FJvdiBcfmCD8CzxZkAoLXyYK26P/FnhqRRwN
	h1DA==
MIME-Version: 1.0
Received: by 10.180.91.71 with SMTP id cc7mr1576295wib.2.1351589277796; Tue,
	30 Oct 2012 02:27:57 -0700 (PDT)
Received: by 10.227.200.1 with HTTP; Tue, 30 Oct 2012 02:27:57 -0700 (PDT)
In-Reply-To: 
References: 
	
	
	<50852EB6.4060705@eu.citrix.com>
	
Date: Tue, 30 Oct 2012 10:27:57 +0100
X-Google-Sender-Auth: 0rdxfisFgAAlZ1hUEFjfFAvwj4Y
Message-ID: 
From: George Dunlap 
To: "Liu, Jinsong" 
Cc: Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	Ian Jackson , Jan Beulich 
Subject: Re: [Xen-devel] [Patch 4/5] X86/vMCE: handle broken page occurred
 before migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Jinsong,

I'm at UDS now, but I'll try to review the new patches in the next few days.

If you end up sending these patches again, could you please send them in
a more normal "patchbomb-style" format?  I.e., with a "00/02" header
describing what's new in the series, and then naming them 01/02 and
02/02 (instead of 4 and 5, when 1-3 have been applied for months)?

The easiest way to do this is to use hg's patchbomb extension; there's a
description of how to set it up here:

http://wiki.xen.org/wiki/SubmittingXenPatches

It's a few minutes to set up, but it's well worth it both for us and for
you.

Thanks,
  -George

On Mon, Oct 29, 2012 at 4:21 PM, Liu, Jinsong  wrote:
> X86/vMCE: handle broken page occurred before migration
>
> This patch handles guest broken page which occur before migration.
>
> At sender, the broken page would be mapped but not copied to target
> (otherwise it may trigger more serious error, say, SRAR error).
> While its pfn_type and pfn number would be transferred to target
> so that target take appropriate action.
>
> At target, it would set p2m as p2m_ram_broken for broken page, so that
> if guest access the broken page again, it would kill itself as expected.
>
> Signed-off-by: Liu, Jinsong 
>
> diff -r e27a6d53ac15 tools/libxc/xc_domain.c
> --- a/tools/libxc/xc_domain.c   Thu Oct 11 01:52:33 2012 +0800
> +++ b/tools/libxc/xc_domain.c   Thu Oct 25 05:49:10 2012 +0800
> @@ -283,6 +283,22 @@
>      return ret;
>  }
>
> +/* set broken page p2m */
> +int xc_set_broken_page_p2m(xc_interface *xch,
> +                           uint32_t domid,
> +                           unsigned long pfn)
> +{
> +    int ret;
> +    DECLARE_DOMCTL;
> +
> +    domctl.cmd = XEN_DOMCTL_set_broken_page_p2m;
> +    domctl.domain = (domid_t)domid;
> +    domctl.u.set_broken_page_p2m.pfn = pfn;
> +    ret = do_domctl(xch, &domctl);
> +
> +    return ret ? -1 : 0;
> +}
> +
>  /* get info from hvm guest for save */
>  int xc_domain_hvm_getcontext(xc_interface *xch,
>                               uint32_t domid,
> diff -r e27a6d53ac15 tools/libxc/xc_domain_restore.c
> --- a/tools/libxc/xc_domain_restore.c   Thu Oct 11 01:52:33 2012 +0800
> +++ b/tools/libxc/xc_domain_restore.c   Thu Oct 25 05:49:10 2012 +0800
> @@ -962,9 +962,15 @@
>
>      countpages = count;
>      for (i = oldcount; i < buf->nr_pages; ++i)
> -        if ((buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) == XEN_DOMCTL_PFINFO_XTAB
> -            ||(buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) == XEN_DOMCTL_PFINFO_XALLOC)
> +    {
> +        unsigned long pagetype;
> +
> +        pagetype = buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK;
> +        if ( pagetype == XEN_DOMCTL_PFINFO_XTAB ||
> +             pagetype == XEN_DOMCTL_PFINFO_BROKEN ||
> +             pagetype == XEN_DOMCTL_PFINFO_XALLOC )
>              --countpages;
> +    }
>
>      if (!countpages)
>          return count;
> @@ -1200,6 +1206,17 @@
>              /* a bogus/unmapped/allocate-only page: skip it */
>              continue;
>
> +        if ( pagetype == XEN_DOMCTL_PFINFO_BROKEN )
> +        {
> +            if ( xc_set_broken_page_p2m(xch, dom, pfn) )
> +            {
> +                ERROR("Set p2m for broken page failed, "
> +                      "dom=%d, pfn=%lx\n", dom, pfn);
> +                goto err_mapped;
> +            }
> +            continue;
> +        }
> +
>          if (pfn_err[i])
>          {
>              ERROR("unexpected PFN mapping failure pfn %lx map_mfn %lx p2m_mfn %lx",
> diff -r e27a6d53ac15 tools/libxc/xc_domain_save.c
> --- a/tools/libxc/xc_domain_save.c      Thu Oct 11 01:52:33 2012 +0800
> +++ b/tools/libxc/xc_domain_save.c      Thu Oct 25 05:49:10 2012 +0800
> @@ -1277,6 +1277,13 @@
>                  if ( !hvm )
>                      gmfn = pfn_to_mfn(gmfn);
>
> +                if ( pfn_type[j] == XEN_DOMCTL_PFINFO_BROKEN )
> +                {
> +                    pfn_type[j] |= pfn_batch[j];
> +                    ++run;
> +                    continue;
> +                }
> +
>                  if ( pfn_err[j] )
>                  {
>                      if ( pfn_type[j] == XEN_DOMCTL_PFINFO_XTAB )
> @@ -1371,8 +1378,12 @@
>                      }
>                  }
>
> -                /* skip pages that aren't present or are alloc-only */
> +                /*
> +                 * skip pages that aren't present,
> +                 * or are broken, or are alloc-only
> +                 */
>                  if ( pagetype == XEN_DOMCTL_PFINFO_XTAB
> +                    || pagetype == XEN_DOMCTL_PFINFO_BROKEN
>                      || pagetype == XEN_DOMCTL_PFINFO_XALLOC )
>                      continue;
>
> diff -r e27a6d53ac15 tools/libxc/xenctrl.h
> --- a/tools/libxc/xenctrl.h     Thu Oct 11 01:52:33 2012 +0800
> +++ b/tools/libxc/xenctrl.h     Thu Oct 25 05:49:10 2012 +0800
> @@ -575,6 +575,17 @@
>                            xc_domaininfo_t *info);
>
>  /**
> + * This function set p2m for broken page
> + * &parm xch a handle to an open hypervisor interface
> + * @parm domid the domain id which broken page belong to
> + * @parm pfn the pfn number of the broken page
> + * @return 0 on success, -1 on failure
> + */
> +int xc_set_broken_page_p2m(xc_interface *xch,
> +                           uint32_t domid,
> +                           unsigned long pfn);
> +
> +/**
>   * This function returns information about the context of a hvm domain
>   * @parm xch a handle to an open hypervisor interface
>   * @parm domid the domain to get information from
> diff -r e27a6d53ac15 xen/arch/x86/domctl.c
> --- a/xen/arch/x86/domctl.c     Thu Oct 11 01:52:33 2012 +0800
> +++ b/xen/arch/x86/domctl.c     Thu Oct 25 05:49:10 2012 +0800
> @@ -209,12 +209,18 @@
>                  for ( j = 0; j < k; j++ )
>                  {
>                      unsigned long type = 0;
> +                    p2m_type_t t;
>
> -                    page = get_page_from_gfn(d, arr[j], NULL, P2M_ALLOC);
> +                    page = get_page_from_gfn(d, arr[j], &t, P2M_ALLOC);
>
>                      if ( unlikely(!page) ||
>                           unlikely(is_xen_heap_page(page)) )
> -                        type = XEN_DOMCTL_PFINFO_XTAB;
> +                    {
> +                        if ( p2m_is_broken(t) )
> +                            type = XEN_DOMCTL_PFINFO_BROKEN;
> +                        else
> +                            type = XEN_DOMCTL_PFINFO_XTAB;
> +                    }
>                      else
>                      {
>                          switch( page->u.inuse.type_info & PGT_type_mask )
> @@ -235,6 +241,9 @@
>
>                          if ( page->u.inuse.type_info & PGT_pinned )
>                              type |= XEN_DOMCTL_PFINFO_LPINTAB;
> +
> +                        if ( page->count_info & PGC_broken )
> +                            type = XEN_DOMCTL_PFINFO_BROKEN;
>                      }
>
>                      if ( page )
> @@ -1568,6 +1577,28 @@
>      }
>      break;
>
> +    case XEN_DOMCTL_set_broken_page_p2m:
> +    {
> +        struct domain *d;
> +        p2m_type_t pt;
> +        unsigned long pfn;
> +
> +        d = rcu_lock_domain_by_id(domctl->domain);
> +        if ( d != NULL )
> +        {
> +            pfn = domctl->u.set_broken_page_p2m.pfn;
> +
> +            get_gfn_query(d, pfn, &pt);
> +            p2m_change_type(d, pfn, pt, p2m_ram_broken);
> +            put_gfn(d, pfn);
> +
> +            rcu_unlock_domain(d);
> +        }
> +        else
> +            ret = -ESRCH;
> +    }
> +    break;
> +
>      default:
>          ret = iommu_do_domctl(domctl, u_domctl);
>          break;
> diff -r e27a6d53ac15 xen/include/public/domctl.h
> --- a/xen/include/public/domctl.h       Thu Oct 11 01:52:33 2012 +0800
> +++ b/xen/include/public/domctl.h       Thu Oct 25 05:49:10 2012 +0800
> @@ -136,6 +136,7 @@
>  #define XEN_DOMCTL_PFINFO_LPINTAB (0x1U<<31)
>  #define XEN_DOMCTL_PFINFO_XTAB    (0xfU<<28) /* invalid page */
>  #define XEN_DOMCTL_PFINFO_XALLOC  (0xeU<<28) /* allocate-only page */
> +#define XEN_DOMCTL_PFINFO_BROKEN  (0xdU<<28) /* broken page */
>  #define XEN_DOMCTL_PFINFO_PAGEDTAB (0x8U<<28)
>  #define XEN_DOMCTL_PFINFO_LTAB_MASK (0xfU<<28)
>
> @@ -835,6 +836,12 @@
>  typedef struct xen_domctl_set_access_required xen_domctl_set_access_required_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_access_required_t);
>
> +struct xen_domctl_set_broken_page_p2m {
> +    uint64_aligned_t pfn;
> +};
> +typedef struct xen_domctl_set_broken_page_p2m xen_domctl_set_broken_page_p2m_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_broken_page_p2m_t);
> +
>  struct xen_domctl {
>      uint32_t cmd;
>  #define XEN_DOMCTL_createdomain                   1
> @@ -900,6 +907,7 @@
>  #define XEN_DOMCTL_set_access_required           64
>  #define XEN_DOMCTL_audit_p2m                     65
>  #define XEN_DOMCTL_set_virq_handler              66
> +#define XEN_DOMCTL_set_broken_page_p2m           67
>  #define XEN_DOMCTL_gdbsx_guestmemio            1000
>  #define XEN_DOMCTL_gdbsx_pausevcpu             1001
>  #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
> @@ -955,6 +963,7 @@
>          struct xen_domctl_audit_p2m         audit_p2m;
>          struct xen_domctl_set_virq_handler  set_virq_handler;
>          struct xen_domctl_gdbsx_memio       gdbsx_guest_memio;
> +        struct xen_domctl_set_broken_page_p2m set_broken_page_p2m;
>          struct xen_domctl_gdbsx_pauseunp_vcpu gdbsx_pauseunp_vcpu;
>          struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
>          uint8_t                             pad[128];
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 09:30:28 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 09:30:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT89I-00060y-Py; Tue, 30 Oct 2012 09:30:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT89G-00060m-Qe
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 09:30:15 +0000
Received: from [85.158.143.99:48000] by server-3.bemta-4.messagelabs.com id
	20/26-24279-62E9F805; Tue, 30 Oct 2012 09:30:14 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1351589412!27918369!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3042 invoked from network); 30 Oct 2012 09:30:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 09:30:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="15482407"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 09:30:12 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Tue, 30 Oct 2012
	09:30:12 +0000
From: Thanos Makatos 
To: Ian Campbell 
Date: Tue, 30 Oct 2012 09:30:11 +0000
Thread-Topic: [Xen-devel] [PATCH 05 of 16 RFC] blktap3: Don't check if
	blktap is available
Thread-Index: Ac22ckjAGss8Zb47SKqZ08cZk5IF1wADtsZQ
Message-ID: <4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8CAD@LONPMAILBOX01.citrite.net>
References: 
	<57896068356d4870c74a.1351098144@makatos-desktop>
	<1351250625.15162.42.camel@zakaz.uk.xensource.com>
	<4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8C61@LONPMAILBOX01.citrite.net>
	<1351582903.16868.9.camel@hastur.hellion.org.uk>
In-Reply-To: <1351582903.16868.9.camel@hastur.hellion.org.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 05 of 16 RFC] blktap3: Don't check if blktap
 is available
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Ian Campbell
> Sent: 30 October 2012 07:42
> To: Thanos Makatos
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 05 of 16 RFC] blktap3: Don't check if
> blktap is available
> 
> > >
> > > Perhaps even on Linux we would want a sanity check that the drivers
> > > are present and loaded etc?
> >
> > We could ensure that the tapdisk binaries are present, apart from
> that
> > I don't see anything else we could check.
> 
> Could we check for /dev/xen/{evtchn,gntdev,...} or whatever else it
> needs?

Sure.

> 
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 09:30:28 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 09:30:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT89I-00060y-Py; Tue, 30 Oct 2012 09:30:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT89G-00060m-Qe
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 09:30:15 +0000
Received: from [85.158.143.99:48000] by server-3.bemta-4.messagelabs.com id
	20/26-24279-62E9F805; Tue, 30 Oct 2012 09:30:14 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1351589412!27918369!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3042 invoked from network); 30 Oct 2012 09:30:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 09:30:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="15482407"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 09:30:12 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Tue, 30 Oct 2012
	09:30:12 +0000
From: Thanos Makatos 
To: Ian Campbell 
Date: Tue, 30 Oct 2012 09:30:11 +0000
Thread-Topic: [Xen-devel] [PATCH 05 of 16 RFC] blktap3: Don't check if
	blktap is available
Thread-Index: Ac22ckjAGss8Zb47SKqZ08cZk5IF1wADtsZQ
Message-ID: <4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8CAD@LONPMAILBOX01.citrite.net>
References: 
	<57896068356d4870c74a.1351098144@makatos-desktop>
	<1351250625.15162.42.camel@zakaz.uk.xensource.com>
	<4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8C61@LONPMAILBOX01.citrite.net>
	<1351582903.16868.9.camel@hastur.hellion.org.uk>
In-Reply-To: <1351582903.16868.9.camel@hastur.hellion.org.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 05 of 16 RFC] blktap3: Don't check if blktap
 is available
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Ian Campbell
> Sent: 30 October 2012 07:42
> To: Thanos Makatos
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 05 of 16 RFC] blktap3: Don't check if
> blktap is available
> 
> > >
> > > Perhaps even on Linux we would want a sanity check that the drivers
> > > are present and loaded etc?
> >
> > We could ensure that the tapdisk binaries are present, apart from
> that
> > I don't see anything else we could check.
> 
> Could we check for /dev/xen/{evtchn,gntdev,...} or whatever else it
> needs?

Sure.

> 
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 09:36:47 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 09:36:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT8FO-0006Fa-LE; Tue, 30 Oct 2012 09:36:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TT8FN-0006FV-QO
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 09:36:33 +0000
Received: from [85.158.138.51:53563] by server-10.bemta-3.messagelabs.com id
	EB/E8-00901-0AF9F805; Tue, 30 Oct 2012 09:36:32 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1351589791!21604025!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15401 invoked from network); 30 Oct 2012 09:36:31 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Oct 2012 09:36:31 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TT8FG-0009FA-4g; Tue, 30 Oct 2012 09:36:26 +0000
Date: Tue, 30 Oct 2012 09:36:26 +0000
From: Tim Deegan 
To: Jan Beulich 
Message-ID: <20121030093626.GB34613@ocelot.phlegethon.org>
References: <508FAA9402000078000A5612@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <508FAA9402000078000A5612@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: Andres Lagar-Cavilla ,
	xen-devel 
Subject: Re: [Xen-devel] get_gfn_query() locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 09:23 +0000 on 30 Oct (1351588996), Jan Beulich wrote:
> while looking at how "X86/vMCE: handle broken page occurred
> before migration" uses the p2m code, I wondered whether the
> comment
> 
>  * N.B. get_gfn_query() is the _only_ one guaranteed not to take the
>  * p2m lock; none of the others can be called with the p2m or paging
>  * lock held. */
> 
> isn't stale 

Yes, it seems to be stale.  I think that even with the originally
proposed fine-grained p2m locking it would have been possible for this
to take the p2m lock. :(

> - afaict with get_gfn_type_access() passing "1" for the
> "locked" parameter of __get_gfn_type_access(), there's no way
> to avoid the locking without using __get_gfn_type_access()
> directly.

get_gfn_query_unlocked() is the way to do lookups without the lock, but
of course if you do that then you've no guarantee that the mfn it
returns won't get freed under your feet.

> And then again, with the p2m lock being recursive these
> days, I don't think there's any harm calling the other methods
> here with that lock held.

True, but it wouldn't be safe to call it with the paging lock held.
OTOH since we're not seeing any crashes from the lock-ordering
constraints maybe we don't do that.

Andres, what do you think?  Can we just drop/amend that comment?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 09:36:47 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 09:36:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT8FO-0006Fa-LE; Tue, 30 Oct 2012 09:36:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TT8FN-0006FV-QO
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 09:36:33 +0000
Received: from [85.158.138.51:53563] by server-10.bemta-3.messagelabs.com id
	EB/E8-00901-0AF9F805; Tue, 30 Oct 2012 09:36:32 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1351589791!21604025!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15401 invoked from network); 30 Oct 2012 09:36:31 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Oct 2012 09:36:31 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TT8FG-0009FA-4g; Tue, 30 Oct 2012 09:36:26 +0000
Date: Tue, 30 Oct 2012 09:36:26 +0000
From: Tim Deegan 
To: Jan Beulich 
Message-ID: <20121030093626.GB34613@ocelot.phlegethon.org>
References: <508FAA9402000078000A5612@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <508FAA9402000078000A5612@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: Andres Lagar-Cavilla ,
	xen-devel 
Subject: Re: [Xen-devel] get_gfn_query() locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 09:23 +0000 on 30 Oct (1351588996), Jan Beulich wrote:
> while looking at how "X86/vMCE: handle broken page occurred
> before migration" uses the p2m code, I wondered whether the
> comment
> 
>  * N.B. get_gfn_query() is the _only_ one guaranteed not to take the
>  * p2m lock; none of the others can be called with the p2m or paging
>  * lock held. */
> 
> isn't stale 

Yes, it seems to be stale.  I think that even with the originally
proposed fine-grained p2m locking it would have been possible for this
to take the p2m lock. :(

> - afaict with get_gfn_type_access() passing "1" for the
> "locked" parameter of __get_gfn_type_access(), there's no way
> to avoid the locking without using __get_gfn_type_access()
> directly.

get_gfn_query_unlocked() is the way to do lookups without the lock, but
of course if you do that then you've no guarantee that the mfn it
returns won't get freed under your feet.

> And then again, with the p2m lock being recursive these
> days, I don't think there's any harm calling the other methods
> here with that lock held.

True, but it wouldn't be safe to call it with the paging lock held.
OTOH since we're not seeing any crashes from the lock-ordering
constraints maybe we don't do that.

Andres, what do you think?  Can we just drop/amend that comment?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 10:04:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 10:04:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT8gS-0006oG-6M; Tue, 30 Oct 2012 10:04:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT8gR-0006oB-2e
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 10:04:31 +0000
Received: from [85.158.137.99:3573] by server-4.bemta-3.messagelabs.com id
	75/57-01405-E26AF805; Tue, 30 Oct 2012 10:04:30 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1351591469!16992958!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13255 invoked from network); 30 Oct 2012 10:04:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 10:04:29 -0000
X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="15483577"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 10:04:23 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Tue, 30 Oct 2012
	10:04:23 +0000
From: Thanos Makatos 
To: Ian Campbell 
Date: Tue, 30 Oct 2012 10:04:22 +0000
Thread-Topic: [Xen-devel] [PATCH 09 of 16 RFC] blktap3: Introduce the
	tapdisk control function prototypes
Thread-Index: Ac2zbZuBGvHvNk6VRPC1NQiH+W85GADFS+zw
Message-ID: <4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8CB7@LONPMAILBOX01.citrite.net>
References: 
	
	<1351251159.15162.50.camel@zakaz.uk.xensource.com>
In-Reply-To: <1351251159.15162.50.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 09 of 16 RFC] blktap3: Introduce the tapdisk
 control function prototypes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Ian Campbell
> Sent: 26 October 2012 12:33
> To: Thanos Makatos
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 09 of 16 RFC] blktap3: Introduce the
> tapdisk control function prototypes
> 
> On Wed, 2012-10-24 at 18:02 +0100, Thanos Makatos wrote:
> 
> > +    /**
> > +     * for linked lists
> > +     */
> > +    TAILQ_ENTRY(tap_list) entry;
> 
> This file doesn't seem to include the necessary header to define this?
> (Perhaps it is indirectly included?)

It's provided by blktap.h. My plan is to put commonly used header files in a single header file instead of repeating the inclusion in each and every source file.

> 
> Anyway, since I think this header is intended to be used by consumers
> of blktap (rather than internally) I think you need to namespace the
> macros. See tools/include/xen-external/bsd-sys-queue-h-seddery and its
> usages in tools/libxl/Makefile and extras/mini-os/Makefile to create
> local namespaced versions for libxl and mini-os.
> 
Just out of curiosity, what are the benefits of namespacing the macros? Google doesn't give anything relevant.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 10:04:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 10:04:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT8gS-0006oG-6M; Tue, 30 Oct 2012 10:04:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT8gR-0006oB-2e
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 10:04:31 +0000
Received: from [85.158.137.99:3573] by server-4.bemta-3.messagelabs.com id
	75/57-01405-E26AF805; Tue, 30 Oct 2012 10:04:30 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1351591469!16992958!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13255 invoked from network); 30 Oct 2012 10:04:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 10:04:29 -0000
X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="15483577"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 10:04:23 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Tue, 30 Oct 2012
	10:04:23 +0000
From: Thanos Makatos 
To: Ian Campbell 
Date: Tue, 30 Oct 2012 10:04:22 +0000
Thread-Topic: [Xen-devel] [PATCH 09 of 16 RFC] blktap3: Introduce the
	tapdisk control function prototypes
Thread-Index: Ac2zbZuBGvHvNk6VRPC1NQiH+W85GADFS+zw
Message-ID: <4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8CB7@LONPMAILBOX01.citrite.net>
References: 
	
	<1351251159.15162.50.camel@zakaz.uk.xensource.com>
In-Reply-To: <1351251159.15162.50.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 09 of 16 RFC] blktap3: Introduce the tapdisk
 control function prototypes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Ian Campbell
> Sent: 26 October 2012 12:33
> To: Thanos Makatos
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 09 of 16 RFC] blktap3: Introduce the
> tapdisk control function prototypes
> 
> On Wed, 2012-10-24 at 18:02 +0100, Thanos Makatos wrote:
> 
> > +    /**
> > +     * for linked lists
> > +     */
> > +    TAILQ_ENTRY(tap_list) entry;
> 
> This file doesn't seem to include the necessary header to define this?
> (Perhaps it is indirectly included?)

It's provided by blktap.h. My plan is to put commonly used header files in a single header file instead of repeating the inclusion in each and every source file.

> 
> Anyway, since I think this header is intended to be used by consumers
> of blktap (rather than internally) I think you need to namespace the
> macros. See tools/include/xen-external/bsd-sys-queue-h-seddery and its
> usages in tools/libxl/Makefile and extras/mini-os/Makefile to create
> local namespaced versions for libxl and mini-os.
> 
Just out of curiosity, what are the benefits of namespacing the macros? Google doesn't give anything relevant.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 10:30:46 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 10:30:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT95I-000773-Fi; Tue, 30 Oct 2012 10:30:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT95G-00076v-F2
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 10:30:10 +0000
Received: from [85.158.143.99:17957] by server-3.bemta-4.messagelabs.com id
	D3/74-24279-13CAF805; Tue, 30 Oct 2012 10:30:09 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1351593007!27928679!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31665 invoked from network); 30 Oct 2012 10:30:08 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 10:30:08 -0000
X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="15484328"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 10:29:41 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Tue, 30 Oct 2012
	10:29:42 +0000
From: Thanos Makatos 
To: Ian Campbell 
Date: Tue, 30 Oct 2012 10:29:40 +0000
Thread-Topic: [Xen-devel] [PATCH 11 of 16 RFC] blktap3: Provide empty
	implementation for the tap_ctl_list and tap_ctl_list_free functions
Thread-Index: Ac2zbkfKmi0Gfz/1Q3+XO8QukA0xuQDGvo4Q
Message-ID: <4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8CCB@LONPMAILBOX01.citrite.net>
References: 
	<7cbf20d7e4d6b72aa8d0.1351098150@makatos-desktop>
	<1351251446.15162.54.camel@zakaz.uk.xensource.com>
In-Reply-To: <1351251446.15162.54.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 11 of 16 RFC] blktap3: Provide empty
 implementation for the tap_ctl_list and tap_ctl_list_free functions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Ian Campbell
> Sent: 26 October 2012 12:37
> To: Thanos Makatos
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 11 of 16 RFC] blktap3: Provide empty
> implementation for the tap_ctl_list and tap_ctl_list_free functions
> 
> On Wed, 2012-10-24 at 18:02 +0100, Thanos Makatos wrote:
> > +#ifdef HAVE_CONFIG_H
> > +#include "config.h"
> > +#endif
> 
> I think the presence of config.h will be statically determined, wont
> it?

This piece of code is present in (almost) all blktap2 (the github one) files, I seems related to autoconf/automake. I'll remove it.

> 
> > +
> > +#include "tap-ctl.h"
> > +
> > +void tap_ctl_list_free(__attribute__((__unused__)) struct
> > +tqh_tap_list *list) {
> > +    return;
> > +}
> > +
> > +int tap_ctl_list(__attribute__((__unused__)) struct tqh_tap_list
> > +*list) {
> > +    return -ENOSYS;
> > +}
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 10:30:46 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 10:30:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT95I-000773-Fi; Tue, 30 Oct 2012 10:30:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT95G-00076v-F2
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 10:30:10 +0000
Received: from [85.158.143.99:17957] by server-3.bemta-4.messagelabs.com id
	D3/74-24279-13CAF805; Tue, 30 Oct 2012 10:30:09 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1351593007!27928679!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31665 invoked from network); 30 Oct 2012 10:30:08 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 10:30:08 -0000
X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="15484328"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 10:29:41 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Tue, 30 Oct 2012
	10:29:42 +0000
From: Thanos Makatos 
To: Ian Campbell 
Date: Tue, 30 Oct 2012 10:29:40 +0000
Thread-Topic: [Xen-devel] [PATCH 11 of 16 RFC] blktap3: Provide empty
	implementation for the tap_ctl_list and tap_ctl_list_free functions
Thread-Index: Ac2zbkfKmi0Gfz/1Q3+XO8QukA0xuQDGvo4Q
Message-ID: <4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8CCB@LONPMAILBOX01.citrite.net>
References: 
	<7cbf20d7e4d6b72aa8d0.1351098150@makatos-desktop>
	<1351251446.15162.54.camel@zakaz.uk.xensource.com>
In-Reply-To: <1351251446.15162.54.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 11 of 16 RFC] blktap3: Provide empty
 implementation for the tap_ctl_list and tap_ctl_list_free functions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Ian Campbell
> Sent: 26 October 2012 12:37
> To: Thanos Makatos
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 11 of 16 RFC] blktap3: Provide empty
> implementation for the tap_ctl_list and tap_ctl_list_free functions
> 
> On Wed, 2012-10-24 at 18:02 +0100, Thanos Makatos wrote:
> > +#ifdef HAVE_CONFIG_H
> > +#include "config.h"
> > +#endif
> 
> I think the presence of config.h will be statically determined, wont
> it?

This piece of code is present in (almost) all blktap2 (the github one) files, I seems related to autoconf/automake. I'll remove it.

> 
> > +
> > +#include "tap-ctl.h"
> > +
> > +void tap_ctl_list_free(__attribute__((__unused__)) struct
> > +tqh_tap_list *list) {
> > +    return;
> > +}
> > +
> > +int tap_ctl_list(__attribute__((__unused__)) struct tqh_tap_list
> > +*list) {
> > +    return -ENOSYS;
> > +}
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 10:46:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 10:46:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT9K1-0007Oo-3M; Tue, 30 Oct 2012 10:45:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT9Jz-0007Oj-B8
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 10:45:23 +0000
Received: from [193.109.254.147:20172] by server-8.bemta-14.messagelabs.com id
	C0/8C-16549-2CFAF805; Tue, 30 Oct 2012 10:45:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1351593919!8800813!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzk4OTc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1608 invoked from network); 30 Oct 2012 10:45:21 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 10:45:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="42857660"
Received: from unknown (HELO FTLPEX01CL03.citrite.net) ([10.13.107.80])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	30 Oct 2012 10:45:07 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 30 Oct 2012 06:45:06 -0400
Message-ID: <1351593784.16017.0.camel@hastur.hellion.org.uk>
From: Ian Campbell 
To: Thanos Makatos 
Date: Tue, 30 Oct 2012 11:43:04 +0100
In-Reply-To: <4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8CB7@LONPMAILBOX01.citrite.net>
References: 
	
	<1351251159.15162.50.camel@zakaz.uk.xensource.com>
	<4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8CB7@LONPMAILBOX01.citrite.net>
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 09 of 16 RFC] blktap3: Introduce the tapdisk
 control function prototypes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > Anyway, since I think this header is intended to be used by consumers
> > of blktap (rather than internally) I think you need to namespace the
> > macros. See tools/include/xen-external/bsd-sys-queue-h-seddery and its
> > usages in tools/libxl/Makefile and extras/mini-os/Makefile to create
> > local namespaced versions for libxl and mini-os.
> > 
> Just out of curiosity, what are the benefits of namespacing the
> macros? Google doesn't give anything relevant.

It's just good policy for libraries to avoid clashing with names defined
by the application which uses them, or with other libraries which that
library might be using simultaneously.

IOW an application might have it's own TAILQ_ENTRY macro which has
nothing to do with the one you would like to use. By naming it
BLKTAP_TAILQ_ENTRY in blktap (and in general avoiding generic sounding
names) you minimise the chances of this sort of thing.

Of course if a header/type is purely internal to blktap then this
doesn't matter.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 10:46:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 10:46:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT9K1-0007Oo-3M; Tue, 30 Oct 2012 10:45:25 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT9Jz-0007Oj-B8
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 10:45:23 +0000
Received: from [193.109.254.147:20172] by server-8.bemta-14.messagelabs.com id
	C0/8C-16549-2CFAF805; Tue, 30 Oct 2012 10:45:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1351593919!8800813!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzk4OTc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1608 invoked from network); 30 Oct 2012 10:45:21 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 10:45:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="42857660"
Received: from unknown (HELO FTLPEX01CL03.citrite.net) ([10.13.107.80])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	30 Oct 2012 10:45:07 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 30 Oct 2012 06:45:06 -0400
Message-ID: <1351593784.16017.0.camel@hastur.hellion.org.uk>
From: Ian Campbell 
To: Thanos Makatos 
Date: Tue, 30 Oct 2012 11:43:04 +0100
In-Reply-To: <4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8CB7@LONPMAILBOX01.citrite.net>
References: 
	
	<1351251159.15162.50.camel@zakaz.uk.xensource.com>
	<4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8CB7@LONPMAILBOX01.citrite.net>
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 09 of 16 RFC] blktap3: Introduce the tapdisk
 control function prototypes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > Anyway, since I think this header is intended to be used by consumers
> > of blktap (rather than internally) I think you need to namespace the
> > macros. See tools/include/xen-external/bsd-sys-queue-h-seddery and its
> > usages in tools/libxl/Makefile and extras/mini-os/Makefile to create
> > local namespaced versions for libxl and mini-os.
> > 
> Just out of curiosity, what are the benefits of namespacing the
> macros? Google doesn't give anything relevant.

It's just good policy for libraries to avoid clashing with names defined
by the application which uses them, or with other libraries which that
library might be using simultaneously.

IOW an application might have it's own TAILQ_ENTRY macro which has
nothing to do with the one you would like to use. By naming it
BLKTAP_TAILQ_ENTRY in blktap (and in general avoiding generic sounding
names) you minimise the chances of this sort of thing.

Of course if a header/type is purely internal to blktap then this
doesn't matter.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 10:50:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 10:50:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT9Nz-0007VW-Pg; Tue, 30 Oct 2012 10:49:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT9Ny-0007VP-JO
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 10:49:30 +0000
Received: from [85.158.138.51:54893] by server-14.bemta-3.messagelabs.com id
	49/E6-12788-9B0BF805; Tue, 30 Oct 2012 10:49:29 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1351594169!27871626!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21190 invoked from network); 30 Oct 2012 10:49:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 10:49:29 -0000
X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="15484877"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 10:49:28 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Tue, 30 Oct 2012
	10:49:28 +0000
From: Thanos Makatos 
To: Ian Campbell 
Date: Tue, 30 Oct 2012 10:49:28 +0000
Thread-Topic: [Xen-devel] [PATCH 03 of 16 RFC] blktap3: support for blktap3
	in libxl Makefile
Thread-Index: Ac2za79n7kMNZFSqQeePjtzcrLYGlgDHy0mw
Message-ID: <4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8CD9@LONPMAILBOX01.citrite.net>
References: 
	<80e0bc67dcdaadc40d3a.1351098142@makatos-desktop>
	<1351250360.15162.38.camel@zakaz.uk.xensource.com>
In-Reply-To: <1351250360.15162.38.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 03 of 16 RFC] blktap3: support for blktap3
 in libxl Makefile
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Ian Campbell
> Sent: 26 October 2012 12:19
> To: Thanos Makatos
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 03 of 16 RFC] blktap3: support for
> blktap3 in libxl Makefile
> 
> > diff -r 513739de43b5 -r 80e0bc67dcda tools/libxl/Makefile
> > --- a/tools/libxl/Makefile	Wed Oct 24 17:24:37 2012 +0100
> > +++ b/tools/libxl/Makefile	Wed Oct 24 17:24:53 2012 +0100
> > @@ -20,7 +20,7 @@ LIBUUID_LIBS += -luuid  endif
> >
> >  LIBXL_LIBS =
> > -LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest)
> > $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(PTYFUNCS_LIBS)
> > $(LIBUUID_LIBS)
> > +LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest)
> > +$(LDLIBS_libxenstore) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS)
> 
> What happened to LDLIBS_libblktapctl here?

It's temporarily removed since libxl_blktap3.c provides a dummy implementation and re-enabled at a later patch in this series; anyway this doesn't make sense anymore.

> 
> >  CFLAGS_LIBXL += $(CFLAGS_libxenctrl)
> >  CFLAGS_LIBXL += $(CFLAGS_libxenguest) @@ -77,7 +77,8 @@ LIBXL_OBJS =
> > flexarray.o libxl.o libxl_c
> >  			libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-
> y)  LIBXL_OBJS
> > += _libxl_types.o libxl_flask.o _libxl_types_internal.o
> >
> > -$(LIBXL_OBJS): CFLAGS += $(CFLAGS_LIBXL) -include
> > $(XEN_ROOT)/tools/config.h
> > +$(LIBXL_OBJS): CFLAGS += $(CFLAGS_LIBXL) -include
> $(XEN_ROOT)/tools/config.h \
> > +	$(CFLAGS_libblktapctl)
> 
> This Makefile already contains
> CFLAGS_LIBXL += $(CFLAGS_libblktapctl)
> so I think this change is redundant (or else incomplete).

Correct, I missed it.
> 
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 10:50:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 10:50:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT9Nz-0007VW-Pg; Tue, 30 Oct 2012 10:49:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT9Ny-0007VP-JO
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 10:49:30 +0000
Received: from [85.158.138.51:54893] by server-14.bemta-3.messagelabs.com id
	49/E6-12788-9B0BF805; Tue, 30 Oct 2012 10:49:29 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1351594169!27871626!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21190 invoked from network); 30 Oct 2012 10:49:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 10:49:29 -0000
X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="15484877"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 10:49:28 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Tue, 30 Oct 2012
	10:49:28 +0000
From: Thanos Makatos 
To: Ian Campbell 
Date: Tue, 30 Oct 2012 10:49:28 +0000
Thread-Topic: [Xen-devel] [PATCH 03 of 16 RFC] blktap3: support for blktap3
	in libxl Makefile
Thread-Index: Ac2za79n7kMNZFSqQeePjtzcrLYGlgDHy0mw
Message-ID: <4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8CD9@LONPMAILBOX01.citrite.net>
References: 
	<80e0bc67dcdaadc40d3a.1351098142@makatos-desktop>
	<1351250360.15162.38.camel@zakaz.uk.xensource.com>
In-Reply-To: <1351250360.15162.38.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 03 of 16 RFC] blktap3: support for blktap3
 in libxl Makefile
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Ian Campbell
> Sent: 26 October 2012 12:19
> To: Thanos Makatos
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 03 of 16 RFC] blktap3: support for
> blktap3 in libxl Makefile
> 
> > diff -r 513739de43b5 -r 80e0bc67dcda tools/libxl/Makefile
> > --- a/tools/libxl/Makefile	Wed Oct 24 17:24:37 2012 +0100
> > +++ b/tools/libxl/Makefile	Wed Oct 24 17:24:53 2012 +0100
> > @@ -20,7 +20,7 @@ LIBUUID_LIBS += -luuid  endif
> >
> >  LIBXL_LIBS =
> > -LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest)
> > $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(PTYFUNCS_LIBS)
> > $(LIBUUID_LIBS)
> > +LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest)
> > +$(LDLIBS_libxenstore) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS)
> 
> What happened to LDLIBS_libblktapctl here?

It's temporarily removed since libxl_blktap3.c provides a dummy implementation and re-enabled at a later patch in this series; anyway this doesn't make sense anymore.

> 
> >  CFLAGS_LIBXL += $(CFLAGS_libxenctrl)
> >  CFLAGS_LIBXL += $(CFLAGS_libxenguest) @@ -77,7 +77,8 @@ LIBXL_OBJS =
> > flexarray.o libxl.o libxl_c
> >  			libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-
> y)  LIBXL_OBJS
> > += _libxl_types.o libxl_flask.o _libxl_types_internal.o
> >
> > -$(LIBXL_OBJS): CFLAGS += $(CFLAGS_LIBXL) -include
> > $(XEN_ROOT)/tools/config.h
> > +$(LIBXL_OBJS): CFLAGS += $(CFLAGS_LIBXL) -include
> $(XEN_ROOT)/tools/config.h \
> > +	$(CFLAGS_libblktapctl)
> 
> This Makefile already contains
> CFLAGS_LIBXL += $(CFLAGS_libblktapctl)
> so I think this change is redundant (or else incomplete).

Correct, I missed it.
> 
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 10:51:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 10:51:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT9Q0-0007gB-BN; Tue, 30 Oct 2012 10:51:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT9Py-0007g1-HH
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 10:51:34 +0000
Received: from [193.109.254.147:21560] by server-7.bemta-14.messagelabs.com id
	C6/72-24122-531BF805; Tue, 30 Oct 2012 10:51:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1351594285!1266370!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12289 invoked from network); 30 Oct 2012 10:51:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 10:51:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="15484926"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 10:50:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 30 Oct 2012 10:50:57 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TT9PN-0006jQ-Tp;
	Tue, 30 Oct 2012 10:50:57 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TT9PN-0000X5-Lw;
	Tue, 30 Oct 2012 10:50:57 +0000
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Tue, 30 Oct 2012 10:50:57 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14154: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14154 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14154/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 14151
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 14151
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 14151
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 14151

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  10feb0933708
baseline version:
 xen                  10feb0933708

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 10:51:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 10:51:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT9Q0-0007gB-BN; Tue, 30 Oct 2012 10:51:36 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT9Py-0007g1-HH
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 10:51:34 +0000
Received: from [193.109.254.147:21560] by server-7.bemta-14.messagelabs.com id
	C6/72-24122-531BF805; Tue, 30 Oct 2012 10:51:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1351594285!1266370!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12289 invoked from network); 30 Oct 2012 10:51:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 10:51:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="15484926"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 10:50:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 30 Oct 2012 10:50:57 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TT9PN-0006jQ-Tp;
	Tue, 30 Oct 2012 10:50:57 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TT9PN-0000X5-Lw;
	Tue, 30 Oct 2012 10:50:57 +0000
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Tue, 30 Oct 2012 10:50:57 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14154: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14154 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14154/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 14151
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 14151
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 14151
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 14151

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  10feb0933708
baseline version:
 xen                  10feb0933708

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 11:12:12 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 11:12:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT9jY-000890-Hy; Tue, 30 Oct 2012 11:11:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT9jX-00088h-3J
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 11:11:47 +0000
Received: from [85.158.139.211:38626] by server-7.bemta-5.messagelabs.com id
	3A/AA-23102-2F5BF805; Tue, 30 Oct 2012 11:11:46 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1351595505!18146570!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15763 invoked from network); 30 Oct 2012 11:11:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 11:11:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="15485520"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 11:11:45 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Tue, 30 Oct 2012
	11:11:45 +0000
From: Thanos Makatos 
To: Ian Campbell 
Date: Tue, 30 Oct 2012 11:11:44 +0000
Thread-Topic: [Xen-devel] [PATCH 14 of 16 RFC] blktap3: Provide Makefile for
	compiling the blktap3 control library
Thread-Index: Ac2zbrlTfIWl4dgYQIyHz7bLTeDlBwDHcAEg
Message-ID: <4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8CED@LONPMAILBOX01.citrite.net>
References: 
	<9f5d1f1f979114cf41fc.1351098153@makatos-desktop>
	<1351251638.15162.56.camel@zakaz.uk.xensource.com>
In-Reply-To: <1351251638.15162.56.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 14 of 16 RFC] blktap3: Provide Makefile for
 compiling the blktap3 control library
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Ian Campbell
> Sent: 26 October 2012 12:41
> To: Thanos Makatos
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 14 of 16 RFC] blktap3: Provide Makefile
> for compiling the blktap3 control library
> 
> On Wed, 2012-10-24 at 18:02 +0100, Thanos Makatos wrote:
> > This library will be used by libxl to create/destroy tapdisks.
> >
> > diff -r 092fce05f530 -r 9f5d1f1f9791 tools/blktap3/control/Makefile
> > --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> > +++ b/tools/blktap3/control/Makefile	Wed Oct 24 17:27:38 2012
> +0100
> > @@ -0,0 +1,57 @@
> > +XEN_ROOT := $(CURDIR)/../../../
> > +include $(XEN_ROOT)/tools/Rules.mk
> > +
> > +LIBDIR ?= /usr/lib
> 
> This comes from configure via config/Tools.mk now.
> 
> > +
> > +MAJOR = 1.0
> > +MINOR = 0
> > +LIBNAME = libblktapctl
> > +LIBSONAME = $(LIBNAME).so.$(MAJOR)
> > +
> > +override CFLAGS += \
> > +	-I ../include \
> > +	$(CFLAGS_xeninclude)
> > +
> > +CTL_OBJS = \
> > +		   tap-ctl-destroy.o \
> > +		   tap-ctl-create.o \
> > +		   tap-ctl-list.o
> > +
> > +CTL_PICS  = $(patsubst %.o,%.opic,$(CTL_OBJS))
> > +
> > +OBJS = $(CTL_OBJS) tap-ctl.o
> > +PICS = $(CTL_PICS)
> > +
> > +LIB_STATIC = $(LIBNAME).a
> > +LIB_SHARED = $(LIBSONAME).$(MINOR)
> > +
> > +all: build
> > +
> > +build: $(LIB_STATIC) $(LIB_SHARED)
> > +
> > +$(LIBNAME).so: $(LIBSONAME)
> > +	ln -sf $< $@
> > +
> > +$(LIBSONAME): $(LIB_SHARED)
> > +	ln -sf $< $@
> > +
> > +$(LIB_STATIC): $(CTL_OBJS)
> > +	$(AR) r $@ $^
> > +
> > +$(LIB_SHARED): $(CTL_PICS)
> > +	$(CC) $(LDFLAGS) -fPIC  -Wl,$(SONAME_LDFLAG) -Wl,$(LIBSONAME) \
> > +		$(SHLIB_LDFLAGS) -rdynamic $^ -o $@
> > +
> > +# TODO install in /usr/sbin?
> > +install: $(LIB_STATIC) $(LIB_SHARED)
> > +	$(INSTALL_DIR) -p $(DESTDIR)$(SBINDIR)
> 
> Was this intended to be LIBDIR? At least until the TODO is resolved.

I'm confused, Which one?

> 
> > +	$(INSTALL_PROG) $(LIB_SHARED) $(DESTDIR)$(LIBDIR)
> > +	ln -sf $(LIBSONAME) $(DESTDIR)$(LIBDIR)/$(LIBNAME).so
> > +	ln -sf $(LIB_SHARED) $(DESTDIR)$(LIBDIR)/$(LIBSONAME)
> > +
> > +clean:
> > +	rm -f $(OBJS) $(PICS) $(LIB_STATIC) $(LIB_SHARED)
> > +	rm -f $(LIBNAME).so $(LIBSONAME)
> > +	rm -f *~
> > +
> > +.PHONY: all build clean install
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 11:12:12 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 11:12:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT9jY-000890-Hy; Tue, 30 Oct 2012 11:11:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT9jX-00088h-3J
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 11:11:47 +0000
Received: from [85.158.139.211:38626] by server-7.bemta-5.messagelabs.com id
	3A/AA-23102-2F5BF805; Tue, 30 Oct 2012 11:11:46 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1351595505!18146570!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15763 invoked from network); 30 Oct 2012 11:11:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 11:11:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="15485520"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 11:11:45 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Tue, 30 Oct 2012
	11:11:45 +0000
From: Thanos Makatos 
To: Ian Campbell 
Date: Tue, 30 Oct 2012 11:11:44 +0000
Thread-Topic: [Xen-devel] [PATCH 14 of 16 RFC] blktap3: Provide Makefile for
	compiling the blktap3 control library
Thread-Index: Ac2zbrlTfIWl4dgYQIyHz7bLTeDlBwDHcAEg
Message-ID: <4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8CED@LONPMAILBOX01.citrite.net>
References: 
	<9f5d1f1f979114cf41fc.1351098153@makatos-desktop>
	<1351251638.15162.56.camel@zakaz.uk.xensource.com>
In-Reply-To: <1351251638.15162.56.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 14 of 16 RFC] blktap3: Provide Makefile for
 compiling the blktap3 control library
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Ian Campbell
> Sent: 26 October 2012 12:41
> To: Thanos Makatos
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 14 of 16 RFC] blktap3: Provide Makefile
> for compiling the blktap3 control library
> 
> On Wed, 2012-10-24 at 18:02 +0100, Thanos Makatos wrote:
> > This library will be used by libxl to create/destroy tapdisks.
> >
> > diff -r 092fce05f530 -r 9f5d1f1f9791 tools/blktap3/control/Makefile
> > --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> > +++ b/tools/blktap3/control/Makefile	Wed Oct 24 17:27:38 2012
> +0100
> > @@ -0,0 +1,57 @@
> > +XEN_ROOT := $(CURDIR)/../../../
> > +include $(XEN_ROOT)/tools/Rules.mk
> > +
> > +LIBDIR ?= /usr/lib
> 
> This comes from configure via config/Tools.mk now.
> 
> > +
> > +MAJOR = 1.0
> > +MINOR = 0
> > +LIBNAME = libblktapctl
> > +LIBSONAME = $(LIBNAME).so.$(MAJOR)
> > +
> > +override CFLAGS += \
> > +	-I ../include \
> > +	$(CFLAGS_xeninclude)
> > +
> > +CTL_OBJS = \
> > +		   tap-ctl-destroy.o \
> > +		   tap-ctl-create.o \
> > +		   tap-ctl-list.o
> > +
> > +CTL_PICS  = $(patsubst %.o,%.opic,$(CTL_OBJS))
> > +
> > +OBJS = $(CTL_OBJS) tap-ctl.o
> > +PICS = $(CTL_PICS)
> > +
> > +LIB_STATIC = $(LIBNAME).a
> > +LIB_SHARED = $(LIBSONAME).$(MINOR)
> > +
> > +all: build
> > +
> > +build: $(LIB_STATIC) $(LIB_SHARED)
> > +
> > +$(LIBNAME).so: $(LIBSONAME)
> > +	ln -sf $< $@
> > +
> > +$(LIBSONAME): $(LIB_SHARED)
> > +	ln -sf $< $@
> > +
> > +$(LIB_STATIC): $(CTL_OBJS)
> > +	$(AR) r $@ $^
> > +
> > +$(LIB_SHARED): $(CTL_PICS)
> > +	$(CC) $(LDFLAGS) -fPIC  -Wl,$(SONAME_LDFLAG) -Wl,$(LIBSONAME) \
> > +		$(SHLIB_LDFLAGS) -rdynamic $^ -o $@
> > +
> > +# TODO install in /usr/sbin?
> > +install: $(LIB_STATIC) $(LIB_SHARED)
> > +	$(INSTALL_DIR) -p $(DESTDIR)$(SBINDIR)
> 
> Was this intended to be LIBDIR? At least until the TODO is resolved.

I'm confused, Which one?

> 
> > +	$(INSTALL_PROG) $(LIB_SHARED) $(DESTDIR)$(LIBDIR)
> > +	ln -sf $(LIBSONAME) $(DESTDIR)$(LIBDIR)/$(LIBNAME).so
> > +	ln -sf $(LIB_SHARED) $(DESTDIR)$(LIBDIR)/$(LIBSONAME)
> > +
> > +clean:
> > +	rm -f $(OBJS) $(PICS) $(LIB_STATIC) $(LIB_SHARED)
> > +	rm -f $(LIBNAME).so $(LIBSONAME)
> > +	rm -f *~
> > +
> > +.PHONY: all build clean install
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 11:25:01 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 11:25:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT9vt-0008P9-RJ; Tue, 30 Oct 2012 11:24:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT9vr-0008P4-TL
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 11:24:32 +0000
Received: from [85.158.138.51:4108] by server-5.bemta-3.messagelabs.com id
	E6/2B-12440-FE8BF805; Tue, 30 Oct 2012 11:24:31 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1351596270!23936764!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12371 invoked from network); 30 Oct 2012 11:24:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 11:24:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="15485819"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 11:24:30 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Tue, 30 Oct 2012
	11:24:29 +0000
From: Thanos Makatos 
To: Ian Campbell 
Date: Tue, 30 Oct 2012 11:24:28 +0000
Thread-Topic: [Xen-devel] [PATCH 16 of 16 RFC] blktap3: Implement
	libxl__blktap_devpath and libxl__device_destroy_tapdisk
Thread-Index: Ac2zb3wa9gzEDciuQMqaD+VRvyqBSADH+GcQ
Message-ID: <4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8CF5@LONPMAILBOX01.citrite.net>
References: 
	<0f87cc018fb689f212cb.1351098155@makatos-desktop>
	<1351251963.15162.61.camel@zakaz.uk.xensource.com>
In-Reply-To: <1351251963.15162.61.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 16 of 16 RFC] blktap3: Implement
 libxl__blktap_devpath and libxl__device_destroy_tapdisk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Ian Campbell
> Sent: 26 October 2012 12:46
> To: Thanos Makatos
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 16 of 16 RFC] blktap3: Implement
> libxl__blktap_devpath and libxl__device_destroy_tapdisk
> 
> On Wed, 2012-10-24 at 18:02 +0100, Thanos Makatos wrote:
> > Provide implementation for the libxl__blktap_devpath and
> > libxl__device_destroy_tapdisk functions: the former spawns the
> tapdisk
> > process, the latter destroys it. Both of these functions use the
> > blktap_find function, a function that lists all running tapdisks and
> > looks for one serving a specific file. Finally, link libxl with the
> blktap3 control library.
> >
> > diff -r b12c1bb767d3 -r 0f87cc018fb6 tools/libxl/Makefile
> > --- a/tools/libxl/Makefile	Wed Oct 24 17:28:12 2012 +0100
> > +++ b/tools/libxl/Makefile	Wed Oct 24 17:42:44 2012 +0100
> > @@ -20,7 +20,7 @@ LIBUUID_LIBS += -luuid  endif
> >
> >  LIBXL_LIBS =
> > -LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest)
> > $(LDLIBS_libxenstore) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS)
> > +LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest)
> > +$(LDLIBS_libxenstore) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS)
> > +$(LDLIBS_libblktapctl)
> 
> Is this adding back the thing I commented on earlier?

Yes.

> 
> >  CFLAGS_LIBXL += $(CFLAGS_libxenctrl)
> >  CFLAGS_LIBXL += $(CFLAGS_libxenguest) @@ -29,7 +29,9 @@ CFLAGS_LIBXL
> > += $(CFLAGS_libblktapctl)  CFLAGS_LIBXL += -Wshadow
> >
> >  CFLAGS += $(PTHREAD_CFLAGS)
> > -LDFLAGS += $(PTHREAD_LDFLAGS)
> > +override LDFLAGS += \
> > +	$(PTHREAD_LDFLAGS) \
> > +	-L $(XEN_BLKTAP3)/control
> 
> Please (defined and) use LDLIBS_libblktapctl. Also this change to use
> override looks very dubious to me -- what does it do?
> 
> >  LIBXL_LIBS += $(PTHREAD_LIBS)
> >
> >  LIBXLU_LIBS =
> > @@ -172,6 +174,7 @@ libxenlight.so.$(MAJOR): libxenlight.so.
> >  	ln -sf $< $@
> >
> >  libxenlight.so.$(MAJOR).$(MINOR): $(LIBXL_OBJS)
> > +	make -C $(XEN_BLKTAP3)
> 
> This shouldn't be needed if the tools/Makefile has things ordered
> correctly. It is reasonable for tools/libxl to assume that its
> prerequisites are already built. People who build with make -C
> tools/libxl need to take care of this themself.

I've added this so I can build libxl from within tools/libxl without worrying about building tools/blktap3, it simplifies development, doesn't it?

> 
> >  	$(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxenlight.so.$(MAJOR)
> > $(SHLIB_LDFLAGS) -o $@ $^ $(LIBXL_LIBS) $(APPEND_LDFLAGS)
> >
> >  libxenlight.a: $(LIBXL_OBJS)
> > diff -r b12c1bb767d3 -r 0f87cc018fb6 tools/libxl/libxl_blktap3.c
> > --- a/tools/libxl/libxl_blktap3.c	Wed Oct 24 17:28:12 2012 +0100
> > +++ b/tools/libxl/libxl_blktap3.c	Wed Oct 24 17:42:44 2012 +0100
> >
> > -int libxl__device_destroy_tapdisk(libxl__gc *gc, const char
> *be_path) {
> > -    return -ENOSYS;
> > +/**
> > + * Creates a tapdisk for the specified path.
> > + *
> > + * TODO document parameters
> > + *
> > + * @param gc
> > + * @param disk
> > + * @param format
> > + *
> > + * @returns 0 on success, an error code otherwise  */ int
> > +libxl__blktap_devpath(libxl__gc *gc, const char *disk,
> > +        libxl_disk_format format)
> > +{
> > +    const char *type = NULL;
> > +    char *params = NULL;
> > +    struct tap_list tap;
> > +    int err = 0;
> > +
> > +    type = libxl__device_disk_string_of_format(format);
> > +
> > +    /*
> > +     * Ensure that no other tapdisk is serving this path.
> > +     * XXX Does libxl protect us against race conditions?
> 
> Not AFAIK. Does tapdisk not open the file O_EXCL when necessary?

I don't think so, I'll have a look. This could be a problem if two guest VMs are created at the same time and they both use the same VDI, obviously a corner case. Should we protect against that or we're getting paranoid?

> 
> >  What if somebody
> > +     * manually attaches a tapdisk to this path?
> > +     */
> > +    if (!(err = blktap_find(gc, type, disk, &tap))) {
> > +        LOG(DEBUG, "tapdisk %d already serving %s\n", tap.pid,
> disk);
> > +        return 0;
> > +    }
> > +
> > +    LOG(DEBUG, "tapdisk not found\n");
> > +
> > +    /*
> > +     * TODO Should we worry about return codes other than ENOENT?
> > +     */
> > +
> > +    params = libxl__sprintf(gc, "%s:%s", type, disk);
> > +    if (!(err = tap_ctl_create(params, 0, -1, NULL))) {
> > +        LOG(DEBUG, "created tapdisk\n");
> > +        return 0;
> > +    }
> > +
> > +    LOG(ERROR, "error creating tapdisk: %s\n", strerror(err));
> 
> You can use LOGE or LOGEV here to get the errno type thing printed
> automatically in a consistent way.

Ok.

> 
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 11:25:01 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 11:25:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT9vt-0008P9-RJ; Tue, 30 Oct 2012 11:24:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT9vr-0008P4-TL
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 11:24:32 +0000
Received: from [85.158.138.51:4108] by server-5.bemta-3.messagelabs.com id
	E6/2B-12440-FE8BF805; Tue, 30 Oct 2012 11:24:31 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1351596270!23936764!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12371 invoked from network); 30 Oct 2012 11:24:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 11:24:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="15485819"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 11:24:30 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Tue, 30 Oct 2012
	11:24:29 +0000
From: Thanos Makatos 
To: Ian Campbell 
Date: Tue, 30 Oct 2012 11:24:28 +0000
Thread-Topic: [Xen-devel] [PATCH 16 of 16 RFC] blktap3: Implement
	libxl__blktap_devpath and libxl__device_destroy_tapdisk
Thread-Index: Ac2zb3wa9gzEDciuQMqaD+VRvyqBSADH+GcQ
Message-ID: <4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8CF5@LONPMAILBOX01.citrite.net>
References: 
	<0f87cc018fb689f212cb.1351098155@makatos-desktop>
	<1351251963.15162.61.camel@zakaz.uk.xensource.com>
In-Reply-To: <1351251963.15162.61.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 16 of 16 RFC] blktap3: Implement
 libxl__blktap_devpath and libxl__device_destroy_tapdisk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Ian Campbell
> Sent: 26 October 2012 12:46
> To: Thanos Makatos
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 16 of 16 RFC] blktap3: Implement
> libxl__blktap_devpath and libxl__device_destroy_tapdisk
> 
> On Wed, 2012-10-24 at 18:02 +0100, Thanos Makatos wrote:
> > Provide implementation for the libxl__blktap_devpath and
> > libxl__device_destroy_tapdisk functions: the former spawns the
> tapdisk
> > process, the latter destroys it. Both of these functions use the
> > blktap_find function, a function that lists all running tapdisks and
> > looks for one serving a specific file. Finally, link libxl with the
> blktap3 control library.
> >
> > diff -r b12c1bb767d3 -r 0f87cc018fb6 tools/libxl/Makefile
> > --- a/tools/libxl/Makefile	Wed Oct 24 17:28:12 2012 +0100
> > +++ b/tools/libxl/Makefile	Wed Oct 24 17:42:44 2012 +0100
> > @@ -20,7 +20,7 @@ LIBUUID_LIBS += -luuid  endif
> >
> >  LIBXL_LIBS =
> > -LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest)
> > $(LDLIBS_libxenstore) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS)
> > +LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest)
> > +$(LDLIBS_libxenstore) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS)
> > +$(LDLIBS_libblktapctl)
> 
> Is this adding back the thing I commented on earlier?

Yes.

> 
> >  CFLAGS_LIBXL += $(CFLAGS_libxenctrl)
> >  CFLAGS_LIBXL += $(CFLAGS_libxenguest) @@ -29,7 +29,9 @@ CFLAGS_LIBXL
> > += $(CFLAGS_libblktapctl)  CFLAGS_LIBXL += -Wshadow
> >
> >  CFLAGS += $(PTHREAD_CFLAGS)
> > -LDFLAGS += $(PTHREAD_LDFLAGS)
> > +override LDFLAGS += \
> > +	$(PTHREAD_LDFLAGS) \
> > +	-L $(XEN_BLKTAP3)/control
> 
> Please (defined and) use LDLIBS_libblktapctl. Also this change to use
> override looks very dubious to me -- what does it do?
> 
> >  LIBXL_LIBS += $(PTHREAD_LIBS)
> >
> >  LIBXLU_LIBS =
> > @@ -172,6 +174,7 @@ libxenlight.so.$(MAJOR): libxenlight.so.
> >  	ln -sf $< $@
> >
> >  libxenlight.so.$(MAJOR).$(MINOR): $(LIBXL_OBJS)
> > +	make -C $(XEN_BLKTAP3)
> 
> This shouldn't be needed if the tools/Makefile has things ordered
> correctly. It is reasonable for tools/libxl to assume that its
> prerequisites are already built. People who build with make -C
> tools/libxl need to take care of this themself.

I've added this so I can build libxl from within tools/libxl without worrying about building tools/blktap3, it simplifies development, doesn't it?

> 
> >  	$(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxenlight.so.$(MAJOR)
> > $(SHLIB_LDFLAGS) -o $@ $^ $(LIBXL_LIBS) $(APPEND_LDFLAGS)
> >
> >  libxenlight.a: $(LIBXL_OBJS)
> > diff -r b12c1bb767d3 -r 0f87cc018fb6 tools/libxl/libxl_blktap3.c
> > --- a/tools/libxl/libxl_blktap3.c	Wed Oct 24 17:28:12 2012 +0100
> > +++ b/tools/libxl/libxl_blktap3.c	Wed Oct 24 17:42:44 2012 +0100
> >
> > -int libxl__device_destroy_tapdisk(libxl__gc *gc, const char
> *be_path) {
> > -    return -ENOSYS;
> > +/**
> > + * Creates a tapdisk for the specified path.
> > + *
> > + * TODO document parameters
> > + *
> > + * @param gc
> > + * @param disk
> > + * @param format
> > + *
> > + * @returns 0 on success, an error code otherwise  */ int
> > +libxl__blktap_devpath(libxl__gc *gc, const char *disk,
> > +        libxl_disk_format format)
> > +{
> > +    const char *type = NULL;
> > +    char *params = NULL;
> > +    struct tap_list tap;
> > +    int err = 0;
> > +
> > +    type = libxl__device_disk_string_of_format(format);
> > +
> > +    /*
> > +     * Ensure that no other tapdisk is serving this path.
> > +     * XXX Does libxl protect us against race conditions?
> 
> Not AFAIK. Does tapdisk not open the file O_EXCL when necessary?

I don't think so, I'll have a look. This could be a problem if two guest VMs are created at the same time and they both use the same VDI, obviously a corner case. Should we protect against that or we're getting paranoid?

> 
> >  What if somebody
> > +     * manually attaches a tapdisk to this path?
> > +     */
> > +    if (!(err = blktap_find(gc, type, disk, &tap))) {
> > +        LOG(DEBUG, "tapdisk %d already serving %s\n", tap.pid,
> disk);
> > +        return 0;
> > +    }
> > +
> > +    LOG(DEBUG, "tapdisk not found\n");
> > +
> > +    /*
> > +     * TODO Should we worry about return codes other than ENOENT?
> > +     */
> > +
> > +    params = libxl__sprintf(gc, "%s:%s", type, disk);
> > +    if (!(err = tap_ctl_create(params, 0, -1, NULL))) {
> > +        LOG(DEBUG, "created tapdisk\n");
> > +        return 0;
> > +    }
> > +
> > +    LOG(ERROR, "error creating tapdisk: %s\n", strerror(err));
> 
> You can use LOGE or LOGEV here to get the errno type thing printed
> automatically in a consistent way.

Ok.

> 
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 11:25:03 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 11:25:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT9vx-0008PQ-7Z; Tue, 30 Oct 2012 11:24:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT9vw-0008PI-2f
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 11:24:36 +0000
Received: from [85.158.143.35:12881] by server-1.bemta-4.messagelabs.com id
	B7/1A-19134-3F8BF805; Tue, 30 Oct 2012 11:24:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1351596272!11890878!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzk4OTc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14430 invoked from network); 30 Oct 2012 11:24:34 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 11:24:34 -0000
X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="42860899"
Received: from ftlpex01cl01.citrite.net ([10.13.107.78])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	30 Oct 2012 11:24:32 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 30 Oct 2012 07:24:31 -0400
Message-ID: <1351596149.16017.6.camel@hastur.hellion.org.uk>
From: Ian Campbell 
To: Thanos Makatos 
Date: Tue, 30 Oct 2012 12:22:29 +0100
In-Reply-To: <4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8CED@LONPMAILBOX01.citrite.net>
References: 
	<9f5d1f1f979114cf41fc.1351098153@makatos-desktop>
	<1351251638.15162.56.camel@zakaz.uk.xensource.com>
	<4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8CED@LONPMAILBOX01.citrite.net>
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 14 of 16 RFC] blktap3: Provide Makefile for
 compiling the blktap3 control library
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-30 at 11:11 +0000, Thanos Makatos wrote:
> > > +
> > > +# TODO install in /usr/sbin?
> > > +install: $(LIB_STATIC) $(LIB_SHARED)
> > > +	$(INSTALL_DIR) -p $(DESTDIR)$(SBINDIR)
> > 
> > Was this intended to be LIBDIR? At least until the TODO is resolved.
> 
> I'm confused, Which one?

The use of SBINDIR here, was it supposed to be a LIBDIR? Because the
following lines all install to LIBDIR not SBINDIR.

> > > +	$(INSTALL_PROG) $(LIB_SHARED) $(DESTDIR)$(LIBDIR)
> > > +	ln -sf $(LIBSONAME) $(DESTDIR)$(LIBDIR)/$(LIBNAME).so
> > > +	ln -sf $(LIB_SHARED) $(DESTDIR)$(LIBDIR)/$(LIBSONAME)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 11:25:03 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 11:25:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT9vx-0008PQ-7Z; Tue, 30 Oct 2012 11:24:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT9vw-0008PI-2f
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 11:24:36 +0000
Received: from [85.158.143.35:12881] by server-1.bemta-4.messagelabs.com id
	B7/1A-19134-3F8BF805; Tue, 30 Oct 2012 11:24:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1351596272!11890878!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzk4OTc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14430 invoked from network); 30 Oct 2012 11:24:34 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 11:24:34 -0000
X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="42860899"
Received: from ftlpex01cl01.citrite.net ([10.13.107.78])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	30 Oct 2012 11:24:32 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 30 Oct 2012 07:24:31 -0400
Message-ID: <1351596149.16017.6.camel@hastur.hellion.org.uk>
From: Ian Campbell 
To: Thanos Makatos 
Date: Tue, 30 Oct 2012 12:22:29 +0100
In-Reply-To: <4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8CED@LONPMAILBOX01.citrite.net>
References: 
	<9f5d1f1f979114cf41fc.1351098153@makatos-desktop>
	<1351251638.15162.56.camel@zakaz.uk.xensource.com>
	<4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8CED@LONPMAILBOX01.citrite.net>
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 14 of 16 RFC] blktap3: Provide Makefile for
 compiling the blktap3 control library
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-10-30 at 11:11 +0000, Thanos Makatos wrote:
> > > +
> > > +# TODO install in /usr/sbin?
> > > +install: $(LIB_STATIC) $(LIB_SHARED)
> > > +	$(INSTALL_DIR) -p $(DESTDIR)$(SBINDIR)
> > 
> > Was this intended to be LIBDIR? At least until the TODO is resolved.
> 
> I'm confused, Which one?

The use of SBINDIR here, was it supposed to be a LIBDIR? Because the
following lines all install to LIBDIR not SBINDIR.

> > > +	$(INSTALL_PROG) $(LIB_SHARED) $(DESTDIR)$(LIBDIR)
> > > +	ln -sf $(LIBSONAME) $(DESTDIR)$(LIBDIR)/$(LIBNAME).so
> > > +	ln -sf $(LIB_SHARED) $(DESTDIR)$(LIBDIR)/$(LIBSONAME)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 11:28:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 11:28:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT9z1-00009L-Qx; Tue, 30 Oct 2012 11:27:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT9z0-000099-97
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 11:27:46 +0000
Received: from [85.158.139.211:43816] by server-5.bemta-5.messagelabs.com id
	C4/77-09732-1B9BF805; Tue, 30 Oct 2012 11:27:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1351596463!18122635!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODIzNzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11665 invoked from network); 30 Oct 2012 11:27:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 11:27:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="212837039"
Received: from unknown (HELO FTLPEX01CL03.citrite.net) ([10.13.107.80])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	30 Oct 2012 11:27:42 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 30 Oct 2012 07:27:41 -0400
Message-ID: <1351596344.16017.8.camel@hastur.hellion.org.uk>
From: Ian Campbell 
To: Thanos Makatos 
Date: Tue, 30 Oct 2012 12:25:44 +0100
In-Reply-To: <4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8CF5@LONPMAILBOX01.citrite.net>
References: 
	<0f87cc018fb689f212cb.1351098155@makatos-desktop>
	<1351251963.15162.61.camel@zakaz.uk.xensource.com>
	<4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8CF5@LONPMAILBOX01.citrite.net>
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 16 of 16 RFC] blktap3: Implement
 libxl__blktap_devpath and libxl__device_destroy_tapdisk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > >  LIBXL_LIBS += $(PTHREAD_LIBS)
> > >
> > >  LIBXLU_LIBS =
> > > @@ -172,6 +174,7 @@ libxenlight.so.$(MAJOR): libxenlight.so.
> > >  	ln -sf $< $@
> > >
> > >  libxenlight.so.$(MAJOR).$(MINOR): $(LIBXL_OBJS)
> > > +	make -C $(XEN_BLKTAP3)
> > 
> > This shouldn't be needed if the tools/Makefile has things ordered
> > correctly. It is reasonable for tools/libxl to assume that its
> > prerequisites are already built. People who build with make -C
> > tools/libxl need to take care of this themself.
> 
> I've added this so I can build libxl from within tools/libxl without
> worrying about building tools/blktap3, it simplifies development,
> doesn't it?

If we did this for everything our Makefiles would be an unholy mess.
Either just run "make -C tools/blktap3 && make -C tools/libxl" or carry
this patch locally.

> > > +libxl__blktap_devpath(libxl__gc *gc, const char *disk,
> > > +        libxl_disk_format format)
> > > +{
> > > +    const char *type = NULL;
> > > +    char *params = NULL;
> > > +    struct tap_list tap;
> > > +    int err = 0;
> > > +
> > > +    type = libxl__device_disk_string_of_format(format);
> > > +
> > > +    /*
> > > +     * Ensure that no other tapdisk is serving this path.
> > > +     * XXX Does libxl protect us against race conditions?
> > 
> > Not AFAIK. Does tapdisk not open the file O_EXCL when necessary?
> 
> I don't think so, I'll have a look. This could be a problem if two
> guest VMs are created at the same time and they both use the same VDI,
> obviously a corner case. Should we protect against that or we're
> getting paranoid?

TBH I'm not sure what the semantics of sharing these things are supposed
to be.

Ian


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 11:28:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 11:28:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TT9z1-00009L-Qx; Tue, 30 Oct 2012 11:27:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TT9z0-000099-97
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 11:27:46 +0000
Received: from [85.158.139.211:43816] by server-5.bemta-5.messagelabs.com id
	C4/77-09732-1B9BF805; Tue, 30 Oct 2012 11:27:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1351596463!18122635!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODIzNzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11665 invoked from network); 30 Oct 2012 11:27:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 11:27:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="212837039"
Received: from unknown (HELO FTLPEX01CL03.citrite.net) ([10.13.107.80])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	30 Oct 2012 11:27:42 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 30 Oct 2012 07:27:41 -0400
Message-ID: <1351596344.16017.8.camel@hastur.hellion.org.uk>
From: Ian Campbell 
To: Thanos Makatos 
Date: Tue, 30 Oct 2012 12:25:44 +0100
In-Reply-To: <4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8CF5@LONPMAILBOX01.citrite.net>
References: 
	<0f87cc018fb689f212cb.1351098155@makatos-desktop>
	<1351251963.15162.61.camel@zakaz.uk.xensource.com>
	<4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8CF5@LONPMAILBOX01.citrite.net>
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 16 of 16 RFC] blktap3: Implement
 libxl__blktap_devpath and libxl__device_destroy_tapdisk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > >  LIBXL_LIBS += $(PTHREAD_LIBS)
> > >
> > >  LIBXLU_LIBS =
> > > @@ -172,6 +174,7 @@ libxenlight.so.$(MAJOR): libxenlight.so.
> > >  	ln -sf $< $@
> > >
> > >  libxenlight.so.$(MAJOR).$(MINOR): $(LIBXL_OBJS)
> > > +	make -C $(XEN_BLKTAP3)
> > 
> > This shouldn't be needed if the tools/Makefile has things ordered
> > correctly. It is reasonable for tools/libxl to assume that its
> > prerequisites are already built. People who build with make -C
> > tools/libxl need to take care of this themself.
> 
> I've added this so I can build libxl from within tools/libxl without
> worrying about building tools/blktap3, it simplifies development,
> doesn't it?

If we did this for everything our Makefiles would be an unholy mess.
Either just run "make -C tools/blktap3 && make -C tools/libxl" or carry
this patch locally.

> > > +libxl__blktap_devpath(libxl__gc *gc, const char *disk,
> > > +        libxl_disk_format format)
> > > +{
> > > +    const char *type = NULL;
> > > +    char *params = NULL;
> > > +    struct tap_list tap;
> > > +    int err = 0;
> > > +
> > > +    type = libxl__device_disk_string_of_format(format);
> > > +
> > > +    /*
> > > +     * Ensure that no other tapdisk is serving this path.
> > > +     * XXX Does libxl protect us against race conditions?
> > 
> > Not AFAIK. Does tapdisk not open the file O_EXCL when necessary?
> 
> I don't think so, I'll have a look. This could be a problem if two
> guest VMs are created at the same time and they both use the same VDI,
> obviously a corner case. Should we protect against that or we're
> getting paranoid?

TBH I'm not sure what the semantics of sharing these things are supposed
to be.

Ian


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 11:29:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 11:29:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTA0H-0000GS-Gy; Tue, 30 Oct 2012 11:29:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTA0G-0000GH-Bb
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 11:29:04 +0000
Received: from [85.158.139.83:24782] by server-15.bemta-5.messagelabs.com id
	10/63-26920-FF9BF805; Tue, 30 Oct 2012 11:29:03 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1351596542!27929850!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16812 invoked from network); 30 Oct 2012 11:29:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 11:29:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="15485933"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 11:29:02 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Tue, 30 Oct 2012
	11:29:01 +0000
From: Thanos Makatos 
To: Ian Campbell 
Date: Tue, 30 Oct 2012 11:29:00 +0000
Thread-Topic: [Xen-devel] [PATCH 16 of 16 RFC] blktap3: Implement
	libxl__blktap_devpath and libxl__device_destroy_tapdisk
Thread-Index: Ac22kZRz2C5ng8CmRWWnXA28UFpHzQAACTEA
Message-ID: <4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8CF9@LONPMAILBOX01.citrite.net>
References: 
	<0f87cc018fb689f212cb.1351098155@makatos-desktop>
	<1351251963.15162.61.camel@zakaz.uk.xensource.com>
	<4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8CF5@LONPMAILBOX01.citrite.net>
	<1351596344.16017.8.camel@hastur.hellion.org.uk>
In-Reply-To: <1351596344.16017.8.camel@hastur.hellion.org.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 16 of 16 RFC] blktap3: Implement
 libxl__blktap_devpath and libxl__device_destroy_tapdisk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Ian Campbell [mailto:ian.campbell@citrix.com]
> Sent: 30 October 2012 11:26
> To: Thanos Makatos
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 16 of 16 RFC] blktap3: Implement
> libxl__blktap_devpath and libxl__device_destroy_tapdisk
> 
> > > >  LIBXL_LIBS += $(PTHREAD_LIBS)
> > > >
> > > >  LIBXLU_LIBS =
> > > > @@ -172,6 +174,7 @@ libxenlight.so.$(MAJOR): libxenlight.so.
> > > >  	ln -sf $< $@
> > > >
> > > >  libxenlight.so.$(MAJOR).$(MINOR): $(LIBXL_OBJS)
> > > > +	make -C $(XEN_BLKTAP3)
> > >
> > > This shouldn't be needed if the tools/Makefile has things ordered
> > > correctly. It is reasonable for tools/libxl to assume that its
> > > prerequisites are already built. People who build with make -C
> > > tools/libxl need to take care of this themself.
> >
> > I've added this so I can build libxl from within tools/libxl without
> > worrying about building tools/blktap3, it simplifies development,
> > doesn't it?
> 
> If we did this for everything our Makefiles would be an unholy mess.
> Either just run "make -C tools/blktap3 && make -C tools/libxl" or carry
> this patch locally.

Ok.

> 
> > > > +libxl__blktap_devpath(libxl__gc *gc, const char *disk,
> > > > +        libxl_disk_format format) {
> > > > +    const char *type = NULL;
> > > > +    char *params = NULL;
> > > > +    struct tap_list tap;
> > > > +    int err = 0;
> > > > +
> > > > +    type = libxl__device_disk_string_of_format(format);
> > > > +
> > > > +    /*
> > > > +     * Ensure that no other tapdisk is serving this path.
> > > > +     * XXX Does libxl protect us against race conditions?
> > >
> > > Not AFAIK. Does tapdisk not open the file O_EXCL when necessary?
> >
> > I don't think so, I'll have a look. This could be a problem if two
> > guest VMs are created at the same time and they both use the same
> VDI,
> > obviously a corner case. Should we protect against that or we're
> > getting paranoid?
> 
> TBH I'm not sure what the semantics of sharing these things are
> supposed to be.
> 
> Ian

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 11:29:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 11:29:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTA0H-0000GS-Gy; Tue, 30 Oct 2012 11:29:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTA0G-0000GH-Bb
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 11:29:04 +0000
Received: from [85.158.139.83:24782] by server-15.bemta-5.messagelabs.com id
	10/63-26920-FF9BF805; Tue, 30 Oct 2012 11:29:03 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1351596542!27929850!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16812 invoked from network); 30 Oct 2012 11:29:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 11:29:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="15485933"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 11:29:02 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Tue, 30 Oct 2012
	11:29:01 +0000
From: Thanos Makatos 
To: Ian Campbell 
Date: Tue, 30 Oct 2012 11:29:00 +0000
Thread-Topic: [Xen-devel] [PATCH 16 of 16 RFC] blktap3: Implement
	libxl__blktap_devpath and libxl__device_destroy_tapdisk
Thread-Index: Ac22kZRz2C5ng8CmRWWnXA28UFpHzQAACTEA
Message-ID: <4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8CF9@LONPMAILBOX01.citrite.net>
References: 
	<0f87cc018fb689f212cb.1351098155@makatos-desktop>
	<1351251963.15162.61.camel@zakaz.uk.xensource.com>
	<4B45B535F7F6BE4CB1C044ED5115CDDE012D54AB8CF5@LONPMAILBOX01.citrite.net>
	<1351596344.16017.8.camel@hastur.hellion.org.uk>
In-Reply-To: <1351596344.16017.8.camel@hastur.hellion.org.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [PATCH 16 of 16 RFC] blktap3: Implement
 libxl__blktap_devpath and libxl__device_destroy_tapdisk
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Ian Campbell [mailto:ian.campbell@citrix.com]
> Sent: 30 October 2012 11:26
> To: Thanos Makatos
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 16 of 16 RFC] blktap3: Implement
> libxl__blktap_devpath and libxl__device_destroy_tapdisk
> 
> > > >  LIBXL_LIBS += $(PTHREAD_LIBS)
> > > >
> > > >  LIBXLU_LIBS =
> > > > @@ -172,6 +174,7 @@ libxenlight.so.$(MAJOR): libxenlight.so.
> > > >  	ln -sf $< $@
> > > >
> > > >  libxenlight.so.$(MAJOR).$(MINOR): $(LIBXL_OBJS)
> > > > +	make -C $(XEN_BLKTAP3)
> > >
> > > This shouldn't be needed if the tools/Makefile has things ordered
> > > correctly. It is reasonable for tools/libxl to assume that its
> > > prerequisites are already built. People who build with make -C
> > > tools/libxl need to take care of this themself.
> >
> > I've added this so I can build libxl from within tools/libxl without
> > worrying about building tools/blktap3, it simplifies development,
> > doesn't it?
> 
> If we did this for everything our Makefiles would be an unholy mess.
> Either just run "make -C tools/blktap3 && make -C tools/libxl" or carry
> this patch locally.

Ok.

> 
> > > > +libxl__blktap_devpath(libxl__gc *gc, const char *disk,
> > > > +        libxl_disk_format format) {
> > > > +    const char *type = NULL;
> > > > +    char *params = NULL;
> > > > +    struct tap_list tap;
> > > > +    int err = 0;
> > > > +
> > > > +    type = libxl__device_disk_string_of_format(format);
> > > > +
> > > > +    /*
> > > > +     * Ensure that no other tapdisk is serving this path.
> > > > +     * XXX Does libxl protect us against race conditions?
> > >
> > > Not AFAIK. Does tapdisk not open the file O_EXCL when necessary?
> >
> > I don't think so, I'll have a look. This could be a problem if two
> > guest VMs are created at the same time and they both use the same
> VDI,
> > obviously a corner case. Should we protect against that or we're
> > getting paranoid?
> 
> TBH I'm not sure what the semantics of sharing these things are
> supposed to be.
> 
> Ian

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 13:08:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 13:08:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTBWx-0001qW-Ka; Tue, 30 Oct 2012 13:06:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTBWw-0001qR-BA
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 13:06:54 +0000
Received: from [85.158.138.51:19185] by server-1.bemta-3.messagelabs.com id
	D3/01-31728-DE0DF805; Tue, 30 Oct 2012 13:06:53 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-14.tower-174.messagelabs.com!1351602412!21641754!1
X-Originating-IP: [78.47.43.170]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3662 invoked from network); 30 Oct 2012 13:06:53 -0000
Received: from mail.vido.info (HELO mail.vido.info) (78.47.43.170)
	by server-14.tower-174.messagelabs.com with SMTP;
	30 Oct 2012 13:06:53 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id DCD0DD3425A
	for ;
	Tue, 30 Oct 2012 14:06:52 +0100 (CET)
X-Virus-Scanned: by amavis at mail.vido.info
Received: from mail.vido.info ([127.0.0.1])
	by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id SW8-DxLVYUz5 for ;
	Tue, 30 Oct 2012 14:06:43 +0100 (CET)
Received: from www.vido.info (www.vido.info [78.47.43.171])
	by mail.vido.info (Postfix) with ESMTP id 8CFAED341C3
	for ;
	Tue, 30 Oct 2012 14:06:43 +0100 (CET)
Received: from H/eQ8EJpgZT/xhr9WlUYa0DMTb8L7KzZcujiFut6sXff9YkADx59WQ==
	(rzy2ghqyzGAkER6qflieHhbbeEmsbFt3) by www.vido.info
	with HTTP (HTTP/1.1 POST); Tue, 30 Oct 2012 14:06:43 +0100
MIME-Version: 1.0
Date: Tue, 30 Oct 2012 14:06:43 +0100
From: Tobias Geiger 
To: 
Message-ID: <888d3a28f2d68acf4a6d1c0419df258c@vido.info>
X-Sender: tobias.geiger@vido.info
User-Agent: Roundcube Webmail
Subject: [Xen-devel] Upstream QEMU and GPU Passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello,

for us GPU Passthrough Customers there is one thing left for total 
happiness (at least for me):
Working Upstream QEMU - simply because it brings a sound device which 
hast working x64 drivers (intel-hda).

Afaik Upstream QEMU does not yet work with GPU-PCI Passthrough.

I have to admit i haven't tried it, but perhaps Anthony (or others) 
could clarify what's missing in Upstream QEMU (or xen) to make it work

Thanks!
Greetings
Tobias

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 13:08:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 13:08:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTBWx-0001qW-Ka; Tue, 30 Oct 2012 13:06:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTBWw-0001qR-BA
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 13:06:54 +0000
Received: from [85.158.138.51:19185] by server-1.bemta-3.messagelabs.com id
	D3/01-31728-DE0DF805; Tue, 30 Oct 2012 13:06:53 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-14.tower-174.messagelabs.com!1351602412!21641754!1
X-Originating-IP: [78.47.43.170]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3662 invoked from network); 30 Oct 2012 13:06:53 -0000
Received: from mail.vido.info (HELO mail.vido.info) (78.47.43.170)
	by server-14.tower-174.messagelabs.com with SMTP;
	30 Oct 2012 13:06:53 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id DCD0DD3425A
	for ;
	Tue, 30 Oct 2012 14:06:52 +0100 (CET)
X-Virus-Scanned: by amavis at mail.vido.info
Received: from mail.vido.info ([127.0.0.1])
	by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id SW8-DxLVYUz5 for ;
	Tue, 30 Oct 2012 14:06:43 +0100 (CET)
Received: from www.vido.info (www.vido.info [78.47.43.171])
	by mail.vido.info (Postfix) with ESMTP id 8CFAED341C3
	for ;
	Tue, 30 Oct 2012 14:06:43 +0100 (CET)
Received: from H/eQ8EJpgZT/xhr9WlUYa0DMTb8L7KzZcujiFut6sXff9YkADx59WQ==
	(rzy2ghqyzGAkER6qflieHhbbeEmsbFt3) by www.vido.info
	with HTTP (HTTP/1.1 POST); Tue, 30 Oct 2012 14:06:43 +0100
MIME-Version: 1.0
Date: Tue, 30 Oct 2012 14:06:43 +0100
From: Tobias Geiger 
To: 
Message-ID: <888d3a28f2d68acf4a6d1c0419df258c@vido.info>
X-Sender: tobias.geiger@vido.info
User-Agent: Roundcube Webmail
Subject: [Xen-devel] Upstream QEMU and GPU Passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello,

for us GPU Passthrough Customers there is one thing left for total 
happiness (at least for me):
Working Upstream QEMU - simply because it brings a sound device which 
hast working x64 drivers (intel-hda).

Afaik Upstream QEMU does not yet work with GPU-PCI Passthrough.

I have to admit i haven't tried it, but perhaps Anthony (or others) 
could clarify what's missing in Upstream QEMU (or xen) to make it work

Thanks!
Greetings
Tobias

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 13:31:33 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 13:31:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTBtI-0002D3-Mk; Tue, 30 Oct 2012 13:30:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTBtH-0002Cy-D8
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 13:29:59 +0000
Received: from [85.158.137.99:64350] by server-3.bemta-3.messagelabs.com id
	D7/64-09368-656DF805; Tue, 30 Oct 2012 13:29:58 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-217.messagelabs.com!1351603797!17040580!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MjQzMTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MjQzMTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31441 invoked from network); 30 Oct 2012 13:29:57 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-13.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Oct 2012 13:29:57 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr3c7sfw==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-064-007.pools.arcor-ip.net [84.57.64.7])
	by smtp.strato.de (jorabe mo29) (RZmta 30.21 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id u00a31o9UCgVQZ ;
	Tue, 30 Oct 2012 14:29:52 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 7953618642; Tue, 30 Oct 2012 14:29:51 +0100 (CET)
Date: Tue, 30 Oct 2012 14:29:51 +0100
From: Olaf Hering 
To: Jan Beulich 
Message-ID: <20121030132951.GA4192@aepfle.de>
References: <508E489502000078000A4FC6@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <508E489502000078000A4FC6@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: xen-devel 
Subject: Re: [Xen-devel] preparing for 4.2.1 and 4.1.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 29, Jan Beulich wrote:

> with the aim of getting both stable releases out the door in the
> second half of November, please check the respective branches
> for backports of bug fixes in -unstable that you think would
> validly belong into those trees (an initial backport of some tools
> side patches is known to be still missing).

What about these tools patches for 4.2.1?
The first one is also important for 4.1.4.

changeset:   26079:b3b03536789a
hotplug/Linux: close lockfd after lock attempt


changeset:   25941:795c493fe561
pygrub: always append --args
changeset:   26018:ecc7627ca6d7
pygrub: correct typo in --args assignment


changeset:   26006:8b6870d686d6
hotplug/Linux: Remove tracing (bash -x) from network-nat script

changeset:   26007:fe756682cc7f
xenballoond.init: remove 4 from default runlevel

changeset:   26008:eecb528583d7
xend/pvscsi: fix passing of SCSI control LUNs
changeset:   26009:2dbfa4d2e107
xend/pvscsi: fix usage of persistant device names for SCSI devices
changeset:   26010:cff10030c6ea
xend/pvscsi: update sysfs parser for Linux 3.0

changeset:   26011:b6fb4e63b946
stubdom: fix parallel build by expanding CROSS_MAKE

changeset:   26077:33348baecf37
stubdom: fix compile errors in grub

changeset:   26081:02064298ebcb
stubdom: fix rpmlint warning spurious-executable-perm

changeset:   26082:8cf26ace9ca0
blktap2/libvhd: fix rpmlint warning spurious-executable-perm

changeset:   26083:3fbeb019d522
blktap: fix rpmlint warning spurious-executable-perm

changeset:   26084:fe9a0eb9aaaa
hotplug: install hotplugpath.sh as data file

changeset:   26085:e32f4301f384
stubdom: install stubdompath.sh as data file

changeset:   26086:ba6b1db89ec8
hotplug/Linux: correct sysconfig tag in xendomains

changeset:   26087:6239ace16749
hotplug/Linux: install sysconfig files as data files



There are also two other HVM related patches, nice to have:

changeset:   26108:79185dcdf558
hvmloader: Reserve FE700000-FE800000 in physical memory map for guest use.

changeset:   26093:4ae08ca5500f
hvm: handle PoD and grant pages in HVMOP_get_mem_type


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 13:31:33 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 13:31:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTBtI-0002D3-Mk; Tue, 30 Oct 2012 13:30:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTBtH-0002Cy-D8
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 13:29:59 +0000
Received: from [85.158.137.99:64350] by server-3.bemta-3.messagelabs.com id
	D7/64-09368-656DF805; Tue, 30 Oct 2012 13:29:58 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-217.messagelabs.com!1351603797!17040580!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MjQzMTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MjQzMTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31441 invoked from network); 30 Oct 2012 13:29:57 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-13.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Oct 2012 13:29:57 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr3c7sfw==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-064-007.pools.arcor-ip.net [84.57.64.7])
	by smtp.strato.de (jorabe mo29) (RZmta 30.21 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id u00a31o9UCgVQZ ;
	Tue, 30 Oct 2012 14:29:52 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 7953618642; Tue, 30 Oct 2012 14:29:51 +0100 (CET)
Date: Tue, 30 Oct 2012 14:29:51 +0100
From: Olaf Hering 
To: Jan Beulich 
Message-ID: <20121030132951.GA4192@aepfle.de>
References: <508E489502000078000A4FC6@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <508E489502000078000A4FC6@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: xen-devel 
Subject: Re: [Xen-devel] preparing for 4.2.1 and 4.1.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 29, Jan Beulich wrote:

> with the aim of getting both stable releases out the door in the
> second half of November, please check the respective branches
> for backports of bug fixes in -unstable that you think would
> validly belong into those trees (an initial backport of some tools
> side patches is known to be still missing).

What about these tools patches for 4.2.1?
The first one is also important for 4.1.4.

changeset:   26079:b3b03536789a
hotplug/Linux: close lockfd after lock attempt


changeset:   25941:795c493fe561
pygrub: always append --args
changeset:   26018:ecc7627ca6d7
pygrub: correct typo in --args assignment


changeset:   26006:8b6870d686d6
hotplug/Linux: Remove tracing (bash -x) from network-nat script

changeset:   26007:fe756682cc7f
xenballoond.init: remove 4 from default runlevel

changeset:   26008:eecb528583d7
xend/pvscsi: fix passing of SCSI control LUNs
changeset:   26009:2dbfa4d2e107
xend/pvscsi: fix usage of persistant device names for SCSI devices
changeset:   26010:cff10030c6ea
xend/pvscsi: update sysfs parser for Linux 3.0

changeset:   26011:b6fb4e63b946
stubdom: fix parallel build by expanding CROSS_MAKE

changeset:   26077:33348baecf37
stubdom: fix compile errors in grub

changeset:   26081:02064298ebcb
stubdom: fix rpmlint warning spurious-executable-perm

changeset:   26082:8cf26ace9ca0
blktap2/libvhd: fix rpmlint warning spurious-executable-perm

changeset:   26083:3fbeb019d522
blktap: fix rpmlint warning spurious-executable-perm

changeset:   26084:fe9a0eb9aaaa
hotplug: install hotplugpath.sh as data file

changeset:   26085:e32f4301f384
stubdom: install stubdompath.sh as data file

changeset:   26086:ba6b1db89ec8
hotplug/Linux: correct sysconfig tag in xendomains

changeset:   26087:6239ace16749
hotplug/Linux: install sysconfig files as data files



There are also two other HVM related patches, nice to have:

changeset:   26108:79185dcdf558
hvmloader: Reserve FE700000-FE800000 in physical memory map for guest use.

changeset:   26093:4ae08ca5500f
hvm: handle PoD and grant pages in HVMOP_get_mem_type


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 13:41:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 13:41:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTC2r-0002QQ-Pv; Tue, 30 Oct 2012 13:39:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTC2p-0002QL-VQ
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 13:39:52 +0000
Received: from [193.109.254.147:20948] by server-1.bemta-14.messagelabs.com id
	7A/A9-20415-7A8DF805; Tue, 30 Oct 2012 13:39:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1351604390!2116575!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8746 invoked from network); 30 Oct 2012 13:39:50 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-27.messagelabs.com with SMTP;
	30 Oct 2012 13:39:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 30 Oct 2012 13:39:49 +0000
Message-Id: <508FE6DD02000078000A56CF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 30 Oct 2012 13:40:29 +0000
From: "Jan Beulich" 
To: "Olaf Hering" 
References: <508E489502000078000A4FC6@nat28.tlf.novell.com>
	<20121030132951.GA4192@aepfle.de>
In-Reply-To: <20121030132951.GA4192@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Jackson ,
	Ian Campbell , xen-devel 
Subject: Re: [Xen-devel] preparing for 4.2.1 and 4.1.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 30.10.12 at 14:29, Olaf Hering  wrote:
> On Mon, Oct 29, Jan Beulich wrote:
> 
>> with the aim of getting both stable releases out the door in the
>> second half of November, please check the respective branches
>> for backports of bug fixes in -unstable that you think would
>> validly belong into those trees (an initial backport of some tools
>> side patches is known to be still missing).
> 
> What about these tools patches for 4.2.1?

Tools patches get taken care of by IanJ (i.e. you should
probably have Cc-ed him) , but first of all - did you check what
is in 4.2-staging already (seems to me you didn't)?

Stubdom ones I'm not sure about - Ian, Ian?

> The first one is also important for 4.1.4.
> 
> changeset:   26079:b3b03536789a
> hotplug/Linux: close lockfd after lock attempt
> 
> 
> changeset:   25941:795c493fe561
> pygrub: always append --args
> changeset:   26018:ecc7627ca6d7
> pygrub: correct typo in --args assignment
> 
> 
> changeset:   26006:8b6870d686d6
> hotplug/Linux: Remove tracing (bash -x) from network-nat script
> 
> changeset:   26007:fe756682cc7f
> xenballoond.init: remove 4 from default runlevel
> 
> changeset:   26008:eecb528583d7
> xend/pvscsi: fix passing of SCSI control LUNs
> changeset:   26009:2dbfa4d2e107
> xend/pvscsi: fix usage of persistant device names for SCSI devices
> changeset:   26010:cff10030c6ea
> xend/pvscsi: update sysfs parser for Linux 3.0
> 
> changeset:   26011:b6fb4e63b946
> stubdom: fix parallel build by expanding CROSS_MAKE
> 
> changeset:   26077:33348baecf37
> stubdom: fix compile errors in grub
> 
> changeset:   26081:02064298ebcb
> stubdom: fix rpmlint warning spurious-executable-perm
> 
> changeset:   26082:8cf26ace9ca0
> blktap2/libvhd: fix rpmlint warning spurious-executable-perm
> 
> changeset:   26083:3fbeb019d522
> blktap: fix rpmlint warning spurious-executable-perm
> 
> changeset:   26084:fe9a0eb9aaaa
> hotplug: install hotplugpath.sh as data file
> 
> changeset:   26085:e32f4301f384
> stubdom: install stubdompath.sh as data file
> 
> changeset:   26086:ba6b1db89ec8
> hotplug/Linux: correct sysconfig tag in xendomains
> 
> changeset:   26087:6239ace16749
> hotplug/Linux: install sysconfig files as data files
> 
> 
> 
> There are also two other HVM related patches, nice to have:
> 
> changeset:   26108:79185dcdf558
> hvmloader: Reserve FE700000-FE800000 in physical memory map for guest use.

Isn't this just cosmetic?

> changeset:   26093:4ae08ca5500f
> hvm: handle PoD and grant pages in HVMOP_get_mem_type

This one even made it out of staging already (on both 4.2 and
4.1).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 13:41:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 13:41:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTC2r-0002QQ-Pv; Tue, 30 Oct 2012 13:39:53 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTC2p-0002QL-VQ
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 13:39:52 +0000
Received: from [193.109.254.147:20948] by server-1.bemta-14.messagelabs.com id
	7A/A9-20415-7A8DF805; Tue, 30 Oct 2012 13:39:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1351604390!2116575!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8746 invoked from network); 30 Oct 2012 13:39:50 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-27.messagelabs.com with SMTP;
	30 Oct 2012 13:39:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 30 Oct 2012 13:39:49 +0000
Message-Id: <508FE6DD02000078000A56CF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 30 Oct 2012 13:40:29 +0000
From: "Jan Beulich" 
To: "Olaf Hering" 
References: <508E489502000078000A4FC6@nat28.tlf.novell.com>
	<20121030132951.GA4192@aepfle.de>
In-Reply-To: <20121030132951.GA4192@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Jackson ,
	Ian Campbell , xen-devel 
Subject: Re: [Xen-devel] preparing for 4.2.1 and 4.1.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 30.10.12 at 14:29, Olaf Hering  wrote:
> On Mon, Oct 29, Jan Beulich wrote:
> 
>> with the aim of getting both stable releases out the door in the
>> second half of November, please check the respective branches
>> for backports of bug fixes in -unstable that you think would
>> validly belong into those trees (an initial backport of some tools
>> side patches is known to be still missing).
> 
> What about these tools patches for 4.2.1?

Tools patches get taken care of by IanJ (i.e. you should
probably have Cc-ed him) , but first of all - did you check what
is in 4.2-staging already (seems to me you didn't)?

Stubdom ones I'm not sure about - Ian, Ian?

> The first one is also important for 4.1.4.
> 
> changeset:   26079:b3b03536789a
> hotplug/Linux: close lockfd after lock attempt
> 
> 
> changeset:   25941:795c493fe561
> pygrub: always append --args
> changeset:   26018:ecc7627ca6d7
> pygrub: correct typo in --args assignment
> 
> 
> changeset:   26006:8b6870d686d6
> hotplug/Linux: Remove tracing (bash -x) from network-nat script
> 
> changeset:   26007:fe756682cc7f
> xenballoond.init: remove 4 from default runlevel
> 
> changeset:   26008:eecb528583d7
> xend/pvscsi: fix passing of SCSI control LUNs
> changeset:   26009:2dbfa4d2e107
> xend/pvscsi: fix usage of persistant device names for SCSI devices
> changeset:   26010:cff10030c6ea
> xend/pvscsi: update sysfs parser for Linux 3.0
> 
> changeset:   26011:b6fb4e63b946
> stubdom: fix parallel build by expanding CROSS_MAKE
> 
> changeset:   26077:33348baecf37
> stubdom: fix compile errors in grub
> 
> changeset:   26081:02064298ebcb
> stubdom: fix rpmlint warning spurious-executable-perm
> 
> changeset:   26082:8cf26ace9ca0
> blktap2/libvhd: fix rpmlint warning spurious-executable-perm
> 
> changeset:   26083:3fbeb019d522
> blktap: fix rpmlint warning spurious-executable-perm
> 
> changeset:   26084:fe9a0eb9aaaa
> hotplug: install hotplugpath.sh as data file
> 
> changeset:   26085:e32f4301f384
> stubdom: install stubdompath.sh as data file
> 
> changeset:   26086:ba6b1db89ec8
> hotplug/Linux: correct sysconfig tag in xendomains
> 
> changeset:   26087:6239ace16749
> hotplug/Linux: install sysconfig files as data files
> 
> 
> 
> There are also two other HVM related patches, nice to have:
> 
> changeset:   26108:79185dcdf558
> hvmloader: Reserve FE700000-FE800000 in physical memory map for guest use.

Isn't this just cosmetic?

> changeset:   26093:4ae08ca5500f
> hvm: handle PoD and grant pages in HVMOP_get_mem_type

This one even made it out of staging already (on both 4.2 and
4.1).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 13:51:39 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 13:51:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTCCa-0002tb-KQ; Tue, 30 Oct 2012 13:49:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTCCZ-0002tU-DU
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 13:49:55 +0000
Received: from [193.109.254.147:50425] by server-11.bemta-14.messagelabs.com
	id B4/4D-29027-20BDF805; Tue, 30 Oct 2012 13:49:54 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1351604992!8992331!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23477 invoked from network); 30 Oct 2012 13:49:53 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 13:49:53 -0000
Received: by mail-qa0-f45.google.com with SMTP id c10so2390158qae.11
	for ; Tue, 30 Oct 2012 06:49:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=s+TNz8bc7xELMoVeacvPLnonL1CfKDRAH2qb0rw0Oi4=;
	b=VHMnE38HMUc0w7a1ItamaKTW9vpaBNx/B1hiQ1S5vUWQg8R8DdVsorhGqEKYFltDG1
	9SFD6mGFNDvwrr2EcHkX4z/Ccz05CbWdQVx+9tsHEuEKxpW7ffXOcDiCvAD4SSgZpNFT
	O4v6CFzaMTufI8texAdNkLImop6c1WqyuaWvGFT1JexIyhl+EXOy36ApefmO4nTkS4+C
	Blya5Et4WTDEa8dPqvGU5/NFXaLlkbtpnxr3+zYQ2ULG8cL0X6aeMA9ZHKSLoFUdF+2F
	InvfFC/V3wN+1PVjrUjDBdOebk6L+V8VozTvV/bic05Ws8PwdvGUu3U4me4qivRyzebT
	/8Xw==
Received: by 10.224.107.3 with SMTP id z3mr12775968qao.9.1351604992533;
	Tue, 30 Oct 2012 06:49:52 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id cu14sm344954qab.1.2012.10.30.06.49.51
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 30 Oct 2012 06:49:52 -0700 (PDT)
Date: Tue, 30 Oct 2012 09:37:22 -0400
From: Konrad Rzeszutek Wilk 
To: "Liu, Jinsong" 
Message-ID: <20121030133720.GA27463@phenom.dumpdata.com>
References: 
	<5089676602000078000A4928@nat28.tlf.novell.com>
	
	<508A89CB020000780008E6ED@nat28.tlf.novell.com>
	
	
	<20121026201409.GF2708@phenom.dumpdata.com>
	
	<20121029123950.GK2708@phenom.dumpdata.com>
	
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xen.org" ,
	"linux-kernel@vger.kernel.org" ,
	Jan Beulich ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 1/2] Xen acpi pad implement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > +config XEN_ACPI_PAD_STUB
> > +	bool
> > +	depends on XEN_DOM0 && X86_64 && ACPI
> > +	default n
> > +
> 
> This Kconfig is pointless, if CONFIG_XEN_ACPI_PAD_STUB = n, native pad would successfully registerred, and then mwait #UD (we would revert df88b2d96e36d9a9e325bfcd12eb45671cbbc937, right?). So xen stub logic should unconditionally built-in kernel.


Potentially. Keep in mind that there is no need to built this if the
kernel is not built with ACPI.
.. snip.
> > +subsys_initcall(xen_acpi_pad_stub_init);
> 
> I'm still confused. In this way there are xen-acpi-pad-stub.c and xen-acpi-pad.c, and you want to let xen-acpi-pad loaded as module, right? how can xen-acpi-pad logic work when it was insmoded?

Via the register/unregister calls that this provides? Or does ACPI bus
drivers get immediately called once the call acpi_bus_register_driver?

Or can one 'poke' the 'add' and 'remove' calls so that once the "true"
PAD driver is loaded it will restart the ops->add call?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 13:51:39 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 13:51:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTCCa-0002tb-KQ; Tue, 30 Oct 2012 13:49:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTCCZ-0002tU-DU
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 13:49:55 +0000
Received: from [193.109.254.147:50425] by server-11.bemta-14.messagelabs.com
	id B4/4D-29027-20BDF805; Tue, 30 Oct 2012 13:49:54 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1351604992!8992331!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23477 invoked from network); 30 Oct 2012 13:49:53 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 13:49:53 -0000
Received: by mail-qa0-f45.google.com with SMTP id c10so2390158qae.11
	for ; Tue, 30 Oct 2012 06:49:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=s+TNz8bc7xELMoVeacvPLnonL1CfKDRAH2qb0rw0Oi4=;
	b=VHMnE38HMUc0w7a1ItamaKTW9vpaBNx/B1hiQ1S5vUWQg8R8DdVsorhGqEKYFltDG1
	9SFD6mGFNDvwrr2EcHkX4z/Ccz05CbWdQVx+9tsHEuEKxpW7ffXOcDiCvAD4SSgZpNFT
	O4v6CFzaMTufI8texAdNkLImop6c1WqyuaWvGFT1JexIyhl+EXOy36ApefmO4nTkS4+C
	Blya5Et4WTDEa8dPqvGU5/NFXaLlkbtpnxr3+zYQ2ULG8cL0X6aeMA9ZHKSLoFUdF+2F
	InvfFC/V3wN+1PVjrUjDBdOebk6L+V8VozTvV/bic05Ws8PwdvGUu3U4me4qivRyzebT
	/8Xw==
Received: by 10.224.107.3 with SMTP id z3mr12775968qao.9.1351604992533;
	Tue, 30 Oct 2012 06:49:52 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id cu14sm344954qab.1.2012.10.30.06.49.51
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 30 Oct 2012 06:49:52 -0700 (PDT)
Date: Tue, 30 Oct 2012 09:37:22 -0400
From: Konrad Rzeszutek Wilk 
To: "Liu, Jinsong" 
Message-ID: <20121030133720.GA27463@phenom.dumpdata.com>
References: 
	<5089676602000078000A4928@nat28.tlf.novell.com>
	
	<508A89CB020000780008E6ED@nat28.tlf.novell.com>
	
	
	<20121026201409.GF2708@phenom.dumpdata.com>
	
	<20121029123950.GK2708@phenom.dumpdata.com>
	
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xen.org" ,
	"linux-kernel@vger.kernel.org" ,
	Jan Beulich ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 1/2] Xen acpi pad implement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > +config XEN_ACPI_PAD_STUB
> > +	bool
> > +	depends on XEN_DOM0 && X86_64 && ACPI
> > +	default n
> > +
> 
> This Kconfig is pointless, if CONFIG_XEN_ACPI_PAD_STUB = n, native pad would successfully registerred, and then mwait #UD (we would revert df88b2d96e36d9a9e325bfcd12eb45671cbbc937, right?). So xen stub logic should unconditionally built-in kernel.


Potentially. Keep in mind that there is no need to built this if the
kernel is not built with ACPI.
.. snip.
> > +subsys_initcall(xen_acpi_pad_stub_init);
> 
> I'm still confused. In this way there are xen-acpi-pad-stub.c and xen-acpi-pad.c, and you want to let xen-acpi-pad loaded as module, right? how can xen-acpi-pad logic work when it was insmoded?

Via the register/unregister calls that this provides? Or does ACPI bus
drivers get immediately called once the call acpi_bus_register_driver?

Or can one 'poke' the 'add' and 'remove' calls so that once the "true"
PAD driver is loaded it will restart the ops->add call?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 14:19:44 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 14:19:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTCev-0003QO-D2; Tue, 30 Oct 2012 14:19:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTCet-0003QG-G3
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 14:19:11 +0000
Received: from [85.158.143.35:11762] by server-1.bemta-4.messagelabs.com id
	5A/50-19134-ED1EF805; Tue, 30 Oct 2012 14:19:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1351606744!13813248!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32385 invoked from network); 30 Oct 2012 14:19:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 14:19:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="15490920"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 14:18:18 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 30 Oct 2012 14:18:18 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TTCe2-0008Oz-Aa; Tue, 30 Oct 2012 14:18:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TTCe2-000407-2C;
	Tue, 30 Oct 2012 14:18:18 +0000
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20623.57765.463131.112836@mariner.uk.xensource.com>
Date: Tue, 30 Oct 2012 14:18:13 +0000
To: Jan Beulich 
In-Reply-To: <508FE6DD02000078000A56CF@nat28.tlf.novell.com>
References: <508E489502000078000A4FC6@nat28.tlf.novell.com>
	<20121030132951.GA4192@aepfle.de>
	<508FE6DD02000078000A56CF@nat28.tlf.novell.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Olaf Hering , Ian Campbell ,
	xen-devel 
Subject: Re: [Xen-devel] preparing for 4.2.1 and 4.1.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Jan Beulich writes ("Re: [Xen-devel] preparing for 4.2.1 and 4.1.4"):
> >>> On 30.10.12 at 14:29, Olaf Hering  wrote:
> > On Mon, Oct 29, Jan Beulich wrote:
> > 
> >> with the aim of getting both stable releases out the door in the
> >> second half of November, please check the respective branches
> >> for backports of bug fixes in -unstable that you think would
> >> validly belong into those trees (an initial backport of some tools
> >> side patches is known to be still missing).
> > 
> > What about these tools patches for 4.2.1?
> 
> Tools patches get taken care of by IanJ (i.e. you should
> probably have Cc-ed him) , but first of all - did you check what
> is in 4.2-staging already (seems to me you didn't)?

I think many of these are.  I haven't been through Olaf's whole list.

> Stubdom ones I'm not sure about - Ian, Ian?

Yes, that's tools and within my remit.

I did a huge pile of backports late last week which seem to have
broken some things.  The bisector is working on it and I'm hoping it
will report fairly shortly ...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 14:19:44 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 14:19:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTCev-0003QO-D2; Tue, 30 Oct 2012 14:19:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTCet-0003QG-G3
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 14:19:11 +0000
Received: from [85.158.143.35:11762] by server-1.bemta-4.messagelabs.com id
	5A/50-19134-ED1EF805; Tue, 30 Oct 2012 14:19:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1351606744!13813248!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32385 invoked from network); 30 Oct 2012 14:19:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 14:19:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="15490920"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 14:18:18 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 30 Oct 2012 14:18:18 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TTCe2-0008Oz-Aa; Tue, 30 Oct 2012 14:18:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TTCe2-000407-2C;
	Tue, 30 Oct 2012 14:18:18 +0000
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20623.57765.463131.112836@mariner.uk.xensource.com>
Date: Tue, 30 Oct 2012 14:18:13 +0000
To: Jan Beulich 
In-Reply-To: <508FE6DD02000078000A56CF@nat28.tlf.novell.com>
References: <508E489502000078000A4FC6@nat28.tlf.novell.com>
	<20121030132951.GA4192@aepfle.de>
	<508FE6DD02000078000A56CF@nat28.tlf.novell.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Olaf Hering , Ian Campbell ,
	xen-devel 
Subject: Re: [Xen-devel] preparing for 4.2.1 and 4.1.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Jan Beulich writes ("Re: [Xen-devel] preparing for 4.2.1 and 4.1.4"):
> >>> On 30.10.12 at 14:29, Olaf Hering  wrote:
> > On Mon, Oct 29, Jan Beulich wrote:
> > 
> >> with the aim of getting both stable releases out the door in the
> >> second half of November, please check the respective branches
> >> for backports of bug fixes in -unstable that you think would
> >> validly belong into those trees (an initial backport of some tools
> >> side patches is known to be still missing).
> > 
> > What about these tools patches for 4.2.1?
> 
> Tools patches get taken care of by IanJ (i.e. you should
> probably have Cc-ed him) , but first of all - did you check what
> is in 4.2-staging already (seems to me you didn't)?

I think many of these are.  I haven't been through Olaf's whole list.

> Stubdom ones I'm not sure about - Ian, Ian?

Yes, that's tools and within my remit.

I did a huge pile of backports late last week which seem to have
broken some things.  The bisector is working on it and I'm hoping it
will report fairly shortly ...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 14:20:12 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 14:20:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTCfU-0003S8-7g; Tue, 30 Oct 2012 14:19:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTCfS-0003Ro-PT
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 14:19:46 +0000
Received: from [193.109.254.147:7415] by server-9.bemta-14.messagelabs.com id
	D0/F4-30773-102EF805; Tue, 30 Oct 2012 14:19:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1351606784!2135620!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10187 invoked from network); 30 Oct 2012 14:19:45 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-27.messagelabs.com with SMTP;
	30 Oct 2012 14:19:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 30 Oct 2012 14:19:44 +0000
Message-Id: <508FF03702000078000A576D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 30 Oct 2012 14:20:23 +0000
From: "Jan Beulich" 
To: "xen-devel" 
References: <506B2268020000780009F273@nat28.tlf.novell.com>
In-Reply-To: <506B2268020000780009F273@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] [PATCH 0/2, v2] x86: adjust entry frame generation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 02.10.12 at 17:20, "Jan Beulich"  wrote:
This pair of patches converts the way frames gets created from
using PUSHes/POPs to using MOVes, thus allowing (in certain
cases) to avoid saving/restoring part of the register set.

While the exact place where the (small) win from this comes from
varies between CPUs, the net effect is a 1 to 2% reduction on a
combined interruption entry and exit when the full state save
can be avoided.

1: use MOV instead of PUSH/POP when saving/restoring register state
2: save only partial register state where possible

Signed-off-by: Jan Beulich 
---
NB: Patch 1 didn't change from its v1 submission, and what was
originally patch 2 (of 3) did already get committed.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 14:20:12 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 14:20:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTCfU-0003S8-7g; Tue, 30 Oct 2012 14:19:48 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTCfS-0003Ro-PT
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 14:19:46 +0000
Received: from [193.109.254.147:7415] by server-9.bemta-14.messagelabs.com id
	D0/F4-30773-102EF805; Tue, 30 Oct 2012 14:19:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1351606784!2135620!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10187 invoked from network); 30 Oct 2012 14:19:45 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-27.messagelabs.com with SMTP;
	30 Oct 2012 14:19:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 30 Oct 2012 14:19:44 +0000
Message-Id: <508FF03702000078000A576D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 30 Oct 2012 14:20:23 +0000
From: "Jan Beulich" 
To: "xen-devel" 
References: <506B2268020000780009F273@nat28.tlf.novell.com>
In-Reply-To: <506B2268020000780009F273@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] [PATCH 0/2, v2] x86: adjust entry frame generation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 02.10.12 at 17:20, "Jan Beulich"  wrote:
This pair of patches converts the way frames gets created from
using PUSHes/POPs to using MOVes, thus allowing (in certain
cases) to avoid saving/restoring part of the register set.

While the exact place where the (small) win from this comes from
varies between CPUs, the net effect is a 1 to 2% reduction on a
combined interruption entry and exit when the full state save
can be avoided.

1: use MOV instead of PUSH/POP when saving/restoring register state
2: save only partial register state where possible

Signed-off-by: Jan Beulich 
---
NB: Patch 1 didn't change from its v1 submission, and what was
originally patch 2 (of 3) did already get committed.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 14:20:28 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 14:20:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTCfQ-0003RJ-Qk; Tue, 30 Oct 2012 14:19:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTCfP-0003RB-RC
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 14:19:44 +0000
Received: from [85.158.138.51:6285] by server-7.bemta-3.messagelabs.com id
	E5/28-06991-EF1EF805; Tue, 30 Oct 2012 14:19:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1351606781!23966110!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8261 invoked from network); 30 Oct 2012 14:19:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 14:19:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="15490953"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 14:19:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 30 Oct 2012 14:19:41 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TTCfN-0008PO-1a	for xen-devel@lists.xensource.com;
	Tue, 30 Oct 2012 14:19:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TTCfM-00040K-R9	for
	xen-devel@lists.xensource.com; Tue, 30 Oct 2012 14:19:40 +0000
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20623.57852.686395.286906@mariner.uk.xensource.com>
Date: Tue, 30 Oct 2012 14:19:40 +0000
To: "xen-devel@lists.xensource.com" 
In-Reply-To: 
References: 
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [xen-4.2-testing test] 14153: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

xen.org writes ("[xen-4.2-testing test] 14153: regressions - FAIL"):
> flight 14153 xen-4.2-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/14153/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-i386-i386-xl             9 guest-start          fail REGR. vs. 14076

This seems to be a real bug:

2012-10-30 07:31:11 Z executing ssh ... root@10.80.250.26 xl create /etc/xen/win.guest.osstest.cfg
WARNING: ignoring "kernel" directive for HVM guest. Use "firmware_override" instead if you really want a non-default firmware
libxl: error: libxl.c:3660:libxl_get_physinfo: getting sharing freed pages
failed to free memory for the domain
Parsing config from /etc/xen/win.guest.osstest.cfg

I think it's probably a libxl bug since only the xl-based test jobs
failed.  I'm hoping the bisector will finger the specific changeset.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 14:20:28 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 14:20:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTCfQ-0003RJ-Qk; Tue, 30 Oct 2012 14:19:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTCfP-0003RB-RC
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 14:19:44 +0000
Received: from [85.158.138.51:6285] by server-7.bemta-3.messagelabs.com id
	E5/28-06991-EF1EF805; Tue, 30 Oct 2012 14:19:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1351606781!23966110!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8261 invoked from network); 30 Oct 2012 14:19:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 14:19:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="15490953"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 14:19:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 30 Oct 2012 14:19:41 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TTCfN-0008PO-1a	for xen-devel@lists.xensource.com;
	Tue, 30 Oct 2012 14:19:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TTCfM-00040K-R9	for
	xen-devel@lists.xensource.com; Tue, 30 Oct 2012 14:19:40 +0000
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20623.57852.686395.286906@mariner.uk.xensource.com>
Date: Tue, 30 Oct 2012 14:19:40 +0000
To: "xen-devel@lists.xensource.com" 
In-Reply-To: 
References: 
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [xen-4.2-testing test] 14153: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

xen.org writes ("[xen-4.2-testing test] 14153: regressions - FAIL"):
> flight 14153 xen-4.2-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/14153/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-i386-i386-xl             9 guest-start          fail REGR. vs. 14076

This seems to be a real bug:

2012-10-30 07:31:11 Z executing ssh ... root@10.80.250.26 xl create /etc/xen/win.guest.osstest.cfg
WARNING: ignoring "kernel" directive for HVM guest. Use "firmware_override" instead if you really want a non-default firmware
libxl: error: libxl.c:3660:libxl_get_physinfo: getting sharing freed pages
failed to free memory for the domain
Parsing config from /etc/xen/win.guest.osstest.cfg

I think it's probably a libxl bug since only the xl-based test jobs
failed.  I'm hoping the bisector will finger the specific changeset.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 14:26:06 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 14:26:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTCkx-0003rG-1m; Tue, 30 Oct 2012 14:25:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTCkv-0003r6-Dx
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 14:25:25 +0000
Received: from [193.109.254.147:56902] by server-5.bemta-14.messagelabs.com id
	03/B1-18309-453EF805; Tue, 30 Oct 2012 14:25:24 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1351607122!8966857!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3692 invoked from network); 30 Oct 2012 14:25:23 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-27.messagelabs.com with SMTP;
	30 Oct 2012 14:25:23 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 30 Oct 2012 14:25:22 +0000
Message-Id: <508FF18902000078000A5782@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 30 Oct 2012 14:26:01 +0000
From: "Jan Beulich" 
To: "Keir Fraser" 
References: <506C461E020000780008D00F@nat28.tlf.novell.com>
	
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3/3] x86: save/restore only partial register
 state where possible
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 03.10.12 at 16:35, Keir Fraser  wrote:
> On 03/10/2012 14:05, "Jan Beulich"  wrote:
> 
>>>>> Keir Fraser  10/02/12 7:02 PM >>>
>>> On 02/10/2012 16:27, "Jan Beulich"  wrote:
>>> 
>>>> ... and make restore conditional not only upon having saved the state,
>>>> but also upon whether saved state was actually modified (and register
>>>> values are known to have been preserved).
>>>> 
>>>> Note that RBP is unconditionally considered a volatile register (i.e.
>>>> irrespective of CONFIG_FRAME_POINTER), since the RBP handling would
>>>> become overly complicated due to the need to save/restore it on the
>>>> compat mode hypercall path [6th argument].
>>>> 
>>>> Note further that for compat mode code paths, saving/restoring R8...R15
>>>> is entirely unnecessary - we don't allow those guests to enter 64-bit
>>>> mode, and hence they have no way of seeing these registers' contents
>>>> (and there consequently also is no information leak, except if the
>>>> context saving domctl would be considered such).
>>>> 
>>>> Finally, note that this may not properly deal with gdbstub's needs, yet
>>>> (but if so, I can't really suggest adjustments, as I don't know that
>>>> code).
>>>> 
>>>> Signed-off-by: Jan Beulich 
>>> 
>>> Ugly. I'd prefer not to bother unless there really is a win we could care
>>> about here.
>> 
>> Without this patch, patch 1 doesn't make a lot of sense either (and patch 2
>> then is merely cleanup).
> 
> Okay, can you re-submit with some comments around what the new TRAP flag
> values mean and how they should be used? Maybe some comments for the
> save/restore macros, and their new arguments, would be nice too. And are you
> confident that this approach is maintainable/non-fragile (i.e., we're not
> going to be continually finding rare cases where registers are being dirtied
> but not saved/restored)?

To answer this last question of yours - I think we're safe, not the
least because no optimization is currently being done to the
(more fragile?) HVM entry points (and the TRAP_regs_* flags
are chosen so that by default any frame that gets created without
knowledge of these flags will be in proper state - "partial" and
"dirty" off (and "dirty" being set on exit is meaningless to code
restoring all registers anyway).

But as always - should it turn out I'm wrong with that assessment,
we should favor reverting these two patches over trying to fix
them.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 14:26:06 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 14:26:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTCkx-0003rG-1m; Tue, 30 Oct 2012 14:25:27 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTCkv-0003r6-Dx
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 14:25:25 +0000
Received: from [193.109.254.147:56902] by server-5.bemta-14.messagelabs.com id
	03/B1-18309-453EF805; Tue, 30 Oct 2012 14:25:24 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1351607122!8966857!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3692 invoked from network); 30 Oct 2012 14:25:23 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-27.messagelabs.com with SMTP;
	30 Oct 2012 14:25:23 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 30 Oct 2012 14:25:22 +0000
Message-Id: <508FF18902000078000A5782@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 30 Oct 2012 14:26:01 +0000
From: "Jan Beulich" 
To: "Keir Fraser" 
References: <506C461E020000780008D00F@nat28.tlf.novell.com>
	
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 3/3] x86: save/restore only partial register
 state where possible
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 03.10.12 at 16:35, Keir Fraser  wrote:
> On 03/10/2012 14:05, "Jan Beulich"  wrote:
> 
>>>>> Keir Fraser  10/02/12 7:02 PM >>>
>>> On 02/10/2012 16:27, "Jan Beulich"  wrote:
>>> 
>>>> ... and make restore conditional not only upon having saved the state,
>>>> but also upon whether saved state was actually modified (and register
>>>> values are known to have been preserved).
>>>> 
>>>> Note that RBP is unconditionally considered a volatile register (i.e.
>>>> irrespective of CONFIG_FRAME_POINTER), since the RBP handling would
>>>> become overly complicated due to the need to save/restore it on the
>>>> compat mode hypercall path [6th argument].
>>>> 
>>>> Note further that for compat mode code paths, saving/restoring R8...R15
>>>> is entirely unnecessary - we don't allow those guests to enter 64-bit
>>>> mode, and hence they have no way of seeing these registers' contents
>>>> (and there consequently also is no information leak, except if the
>>>> context saving domctl would be considered such).
>>>> 
>>>> Finally, note that this may not properly deal with gdbstub's needs, yet
>>>> (but if so, I can't really suggest adjustments, as I don't know that
>>>> code).
>>>> 
>>>> Signed-off-by: Jan Beulich 
>>> 
>>> Ugly. I'd prefer not to bother unless there really is a win we could care
>>> about here.
>> 
>> Without this patch, patch 1 doesn't make a lot of sense either (and patch 2
>> then is merely cleanup).
> 
> Okay, can you re-submit with some comments around what the new TRAP flag
> values mean and how they should be used? Maybe some comments for the
> save/restore macros, and their new arguments, would be nice too. And are you
> confident that this approach is maintainable/non-fragile (i.e., we're not
> going to be continually finding rare cases where registers are being dirtied
> but not saved/restored)?

To answer this last question of yours - I think we're safe, not the
least because no optimization is currently being done to the
(more fragile?) HVM entry points (and the TRAP_regs_* flags
are chosen so that by default any frame that gets created without
knowledge of these flags will be in proper state - "partial" and
"dirty" off (and "dirty" being set on exit is meaningless to code
restoring all registers anyway).

But as always - should it turn out I'm wrong with that assessment,
we should favor reverting these two patches over trying to fix
them.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 14:27:35 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 14:27:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTCmT-0003xW-M2; Tue, 30 Oct 2012 14:27:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTCmS-0003xH-1z
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 14:27:00 +0000
Received: from [85.158.143.99:8876] by server-1.bemta-4.messagelabs.com id
	43/4D-19134-3B3EF805; Tue, 30 Oct 2012 14:26:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1351607211!27046559!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2874 invoked from network); 30 Oct 2012 14:26:51 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-216.messagelabs.com with SMTP;
	30 Oct 2012 14:26:51 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 30 Oct 2012 14:26:51 +0000
Message-Id: <508FF1E202000078000A5786@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 30 Oct 2012 14:27:30 +0000
From: "Jan Beulich" 
To: "xen-devel" 
References: <506B2268020000780009F273@nat28.tlf.novell.com>
	<508FF03702000078000A576D@nat28.tlf.novell.com>
In-Reply-To: <508FF03702000078000A576D@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part96A744C2.0__="
Subject: [Xen-devel] [PATCH 1/2,
 v2] x86: use MOV instead of PUSH/POP when saving/restoring register
 state
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part96A744C2.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Signed-off-by: Jan Beulich 
Acked-by: Keir Fraser 
---
This patch did not change from its v1 submission.

--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -21,8 +21,7 @@ ENTRY(compat_hypercall)
 UNLIKELY_START(ne, msi_check)
         movl  $HYPERCALL_VECTOR,%edi
         call  check_for_unexpected_msi
-        RESTORE_ALL
-        SAVE_ALL
+        LOAD_C_CLOBBERED
 UNLIKELY_END(msi_check)
=20
         GET_CURRENT(%rbx)
@@ -173,8 +172,7 @@ compat_bad_hypercall:
 /* %rbx: struct vcpu, interrupts disabled */
 compat_restore_all_guest:
         ASSERT_INTERRUPTS_DISABLED
-        RESTORE_ALL
-        addq  $8,%rsp
+        RESTORE_ALL adj=3D8
 .Lft0:  iretq
=20
 .section .fixup,"ax"
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -47,12 +47,10 @@ restore_all_guest:
         cmpl  $1,%ecx
         ja    .Lforce_iret
=20
-        addq  $8,%rsp
-        popq  %rcx                    # RIP
-        popq  %r11                    # CS
-        cmpw  $FLAT_USER_CS32,%r11
-        popq  %r11                    # RFLAGS
-        popq  %rsp                    # RSP
+        cmpw  $FLAT_USER_CS32,16(%rsp)# CS
+        movq  8(%rsp),%rcx            # RIP
+        movq  24(%rsp),%r11           # RFLAGS
+        movq  32(%rsp),%rsp           # RSP
         je    1f
         sysretq
 1:      sysretl
@@ -101,8 +99,7 @@ failsafe_callback:
         ALIGN
 /* No special register assumptions. */
 restore_all_xen:
-        RESTORE_ALL
-        addq  $8,%rsp
+        RESTORE_ALL adj=3D8
         iretq
=20
 /*
@@ -311,8 +308,7 @@ ENTRY(int80_direct_trap)
 UNLIKELY_START(ne, msi_check)
         movl  $0x80,%edi
         call  check_for_unexpected_msi
-        RESTORE_ALL
-        SAVE_ALL
+        LOAD_C_CLOBBERED
 UNLIKELY_END(msi_check)
=20
         GET_CURRENT(%rbx)
--- a/xen/include/asm-x86/x86_64/asm_defns.h
+++ b/xen/include/asm-x86/x86_64/asm_defns.h
@@ -5,11 +5,11 @@
=20
 #ifdef CONFIG_FRAME_POINTER
 /* Indicate special exception stack frame by inverting the frame pointer. =
*/
-#define SETUP_EXCEPTION_FRAME_POINTER           \
-        movq  %rsp,%rbp;                        \
+#define SETUP_EXCEPTION_FRAME_POINTER(offs)     \
+        leaq  offs(%rsp),%rbp;                  \
         notq  %rbp
 #else
-#define SETUP_EXCEPTION_FRAME_POINTER
+#define SETUP_EXCEPTION_FRAME_POINTER(off)
 #endif
=20
 #ifndef NDEBUG
@@ -27,40 +27,49 @@
 #define ASSERT_INTERRUPTS_DISABLED ASSERT_INTERRUPT_STATUS(z)
=20
 #define SAVE_ALL                                \
+        addq  $-(UREGS_error_code-UREGS_r15), %rsp; \
         cld;                                    \
-        pushq %rdi;                             \
-        pushq %rsi;                             \
-        pushq %rdx;                             \
-        pushq %rcx;                             \
-        pushq %rax;                             \
-        pushq %r8;                              \
-        pushq %r9;                              \
-        pushq %r10;                             \
-        pushq %r11;                             \
-        pushq %rbx;                             \
-        pushq %rbp;                             \
-        SETUP_EXCEPTION_FRAME_POINTER;          \
-        pushq %r12;                             \
-        pushq %r13;                             \
-        pushq %r14;                             \
-        pushq %r15;
-
-#define RESTORE_ALL                             \
-        popq  %r15;                             \
-        popq  %r14;                             \
-        popq  %r13;                             \
-        popq  %r12;                             \
-        popq  %rbp;                             \
-        popq  %rbx;                             \
-        popq  %r11;                             \
-        popq  %r10;                             \
-        popq  %r9;                              \
-        popq  %r8;                              \
-        popq  %rax;                             \
-        popq  %rcx;                             \
-        popq  %rdx;                             \
-        popq  %rsi;                             \
-        popq  %rdi;
+        movq  %rdi,UREGS_rdi(%rsp);             \
+        movq  %rsi,UREGS_rsi(%rsp);             \
+        movq  %rdx,UREGS_rdx(%rsp);             \
+        movq  %rcx,UREGS_rcx(%rsp);             \
+        movq  %rax,UREGS_rax(%rsp);             \
+        movq  %r8,UREGS_r8(%rsp);               \
+        movq  %r9,UREGS_r9(%rsp);               \
+        movq  %r10,UREGS_r10(%rsp);             \
+        movq  %r11,UREGS_r11(%rsp);             \
+        movq  %rbx,UREGS_rbx(%rsp);             \
+        movq  %rbp,UREGS_rbp(%rsp);             \
+        SETUP_EXCEPTION_FRAME_POINTER(UREGS_rbp); \
+        movq  %r12,UREGS_r12(%rsp);             \
+        movq  %r13,UREGS_r13(%rsp);             \
+        movq  %r14,UREGS_r14(%rsp);             \
+        movq  %r15,UREGS_r15(%rsp);             \
+
+#ifdef __ASSEMBLY__
+.macro LOAD_C_CLOBBERED
+        movq  UREGS_r11(%rsp),%r11
+        movq  UREGS_r10(%rsp),%r10
+        movq  UREGS_r9(%rsp),%r9
+        movq  UREGS_r8(%rsp),%r8
+        movq  UREGS_rax(%rsp),%rax
+        movq  UREGS_rcx(%rsp),%rcx
+        movq  UREGS_rdx(%rsp),%rdx
+        movq  UREGS_rsi(%rsp),%rsi
+        movq  UREGS_rdi(%rsp),%rdi
+.endm
+
+.macro RESTORE_ALL adj=3D0
+        movq  UREGS_r15(%rsp),%r15
+        movq  UREGS_r14(%rsp),%r14
+        movq  UREGS_r13(%rsp),%r13
+        movq  UREGS_r12(%rsp),%r12
+        movq  UREGS_rbp(%rsp),%rbp
+        movq  UREGS_rbx(%rsp),%rbx
+        LOAD_C_CLOBBERED
+        subq  $-(UREGS_error_code-UREGS_r15+\adj), %rsp
+.endm
+#endif
=20
 #ifdef PERF_COUNTERS
 #define PERFC_INCR(_name,_idx,_cur)             \
@@ -94,7 +103,7 @@
 __asm__(                                        \
     "\n" __ALIGN_STR"\n"                        \
     "common_interrupt:\n\t"                     \
-    STR(SAVE_ALL)                               \
+    STR(SAVE_ALL) "\n\t"                        \
     "movq %rsp,%rdi\n\t"                        \
     "callq " STR(do_IRQ) "\n\t"                 \
     "jmp ret_from_intr\n");



--=__Part96A744C2.0__=
Content-Type: text/plain; name="x86-save-restore-all-mov.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-save-restore-all-mov.patch"

x86: use MOV instead of PUSH/POP when saving/restoring register state=0A=0A=
Signed-off-by: Jan Beulich =0AAcked-by: Keir Fraser =
=0A---=0AThis patch did not change from its v1 submission.=0A=
=0A--- a/xen/arch/x86/x86_64/compat/entry.S=0A+++ b/xen/arch/x86/x86_64/com=
pat/entry.S=0A@@ -21,8 +21,7 @@ ENTRY(compat_hypercall)=0A UNLIKELY_START(n=
e, msi_check)=0A         movl  $HYPERCALL_VECTOR,%edi=0A         call  =
check_for_unexpected_msi=0A-        RESTORE_ALL=0A-        SAVE_ALL=0A+    =
    LOAD_C_CLOBBERED=0A UNLIKELY_END(msi_check)=0A =0A         GET_CURRENT(=
%rbx)=0A@@ -173,8 +172,7 @@ compat_bad_hypercall:=0A /* %rbx: struct vcpu, =
interrupts disabled */=0A compat_restore_all_guest:=0A         ASSERT_INTER=
RUPTS_DISABLED=0A-        RESTORE_ALL=0A-        addq  $8,%rsp=0A+        =
RESTORE_ALL adj=3D8=0A .Lft0:  iretq=0A =0A .section .fixup,"ax"=0A--- =
a/xen/arch/x86/x86_64/entry.S=0A+++ b/xen/arch/x86/x86_64/entry.S=0A@@ =
-47,12 +47,10 @@ restore_all_guest:=0A         cmpl  $1,%ecx=0A         ja =
   .Lforce_iret=0A =0A-        addq  $8,%rsp=0A-        popq  %rcx         =
           # RIP=0A-        popq  %r11                    # CS=0A-        =
cmpw  $FLAT_USER_CS32,%r11=0A-        popq  %r11                    # =
RFLAGS=0A-        popq  %rsp                    # RSP=0A+        cmpw  =
$FLAT_USER_CS32,16(%rsp)# CS=0A+        movq  8(%rsp),%rcx            # =
RIP=0A+        movq  24(%rsp),%r11           # RFLAGS=0A+        movq  =
32(%rsp),%rsp           # RSP=0A         je    1f=0A         sysretq=0A 1: =
     sysretl=0A@@ -101,8 +99,7 @@ failsafe_callback:=0A         ALIGN=0A =
/* No special register assumptions. */=0A restore_all_xen:=0A-        =
RESTORE_ALL=0A-        addq  $8,%rsp=0A+        RESTORE_ALL adj=3D8=0A     =
    iretq=0A =0A /*=0A@@ -311,8 +308,7 @@ ENTRY(int80_direct_trap)=0A =
UNLIKELY_START(ne, msi_check)=0A         movl  $0x80,%edi=0A         call  =
check_for_unexpected_msi=0A-        RESTORE_ALL=0A-        SAVE_ALL=0A+    =
    LOAD_C_CLOBBERED=0A UNLIKELY_END(msi_check)=0A =0A         GET_CURRENT(=
%rbx)=0A--- a/xen/include/asm-x86/x86_64/asm_defns.h=0A+++ b/xen/include/as=
m-x86/x86_64/asm_defns.h=0A@@ -5,11 +5,11 @@=0A =0A #ifdef CONFIG_FRAME_POI=
NTER=0A /* Indicate special exception stack frame by inverting the frame =
pointer. */=0A-#define SETUP_EXCEPTION_FRAME_POINTER           \=0A-       =
 movq  %rsp,%rbp;                        \=0A+#define SETUP_EXCEPTION_FRAME=
_POINTER(offs)     \=0A+        leaq  offs(%rsp),%rbp;                  =
\=0A         notq  %rbp=0A #else=0A-#define SETUP_EXCEPTION_FRAME_POINTER=
=0A+#define SETUP_EXCEPTION_FRAME_POINTER(off)=0A #endif=0A =0A #ifndef =
NDEBUG=0A@@ -27,40 +27,49 @@=0A #define ASSERT_INTERRUPTS_DISABLED =
ASSERT_INTERRUPT_STATUS(z)=0A =0A #define SAVE_ALL                         =
       \=0A+        addq  $-(UREGS_error_code-UREGS_r15), %rsp; \=0A       =
  cld;                                    \=0A-        pushq %rdi;         =
                    \=0A-        pushq %rsi;                             =
\=0A-        pushq %rdx;                             \=0A-        pushq =
%rcx;                             \=0A-        pushq %rax;                 =
            \=0A-        pushq %r8;                              \=0A-     =
   pushq %r9;                              \=0A-        pushq %r10;        =
                     \=0A-        pushq %r11;                             =
\=0A-        pushq %rbx;                             \=0A-        pushq =
%rbp;                             \=0A-        SETUP_EXCEPTION_FRAME_POINTE=
R;          \=0A-        pushq %r12;                             \=0A-     =
   pushq %r13;                             \=0A-        pushq %r14;        =
                     \=0A-        pushq %r15;=0A-=0A-#define RESTORE_ALL   =
                          \=0A-        popq  %r15;                         =
    \=0A-        popq  %r14;                             \=0A-        popq =
 %r13;                             \=0A-        popq  %r12;                =
             \=0A-        popq  %rbp;                             \=0A-    =
    popq  %rbx;                             \=0A-        popq  %r11;       =
                      \=0A-        popq  %r10;                             =
\=0A-        popq  %r9;                              \=0A-        popq  =
%r8;                              \=0A-        popq  %rax;                 =
            \=0A-        popq  %rcx;                             \=0A-     =
   popq  %rdx;                             \=0A-        popq  %rsi;        =
                     \=0A-        popq  %rdi;=0A+        movq  %rdi,UREGS_r=
di(%rsp);             \=0A+        movq  %rsi,UREGS_rsi(%rsp);             =
\=0A+        movq  %rdx,UREGS_rdx(%rsp);             \=0A+        movq  =
%rcx,UREGS_rcx(%rsp);             \=0A+        movq  %rax,UREGS_rax(%rsp); =
            \=0A+        movq  %r8,UREGS_r8(%rsp);               \=0A+     =
   movq  %r9,UREGS_r9(%rsp);               \=0A+        movq  %r10,UREGS_r1=
0(%rsp);             \=0A+        movq  %r11,UREGS_r11(%rsp);             =
\=0A+        movq  %rbx,UREGS_rbx(%rsp);             \=0A+        movq  =
%rbp,UREGS_rbp(%rsp);             \=0A+        SETUP_EXCEPTION_FRAME_POINTE=
R(UREGS_rbp); \=0A+        movq  %r12,UREGS_r12(%rsp);             \=0A+   =
     movq  %r13,UREGS_r13(%rsp);             \=0A+        movq  %r14,UREGS_=
r14(%rsp);             \=0A+        movq  %r15,UREGS_r15(%rsp);            =
 \=0A+=0A+#ifdef __ASSEMBLY__=0A+.macro LOAD_C_CLOBBERED=0A+        movq  =
UREGS_r11(%rsp),%r11=0A+        movq  UREGS_r10(%rsp),%r10=0A+        movq =
 UREGS_r9(%rsp),%r9=0A+        movq  UREGS_r8(%rsp),%r8=0A+        movq  =
UREGS_rax(%rsp),%rax=0A+        movq  UREGS_rcx(%rsp),%rcx=0A+        movq =
 UREGS_rdx(%rsp),%rdx=0A+        movq  UREGS_rsi(%rsp),%rsi=0A+        =
movq  UREGS_rdi(%rsp),%rdi=0A+.endm=0A+=0A+.macro RESTORE_ALL adj=3D0=0A+  =
      movq  UREGS_r15(%rsp),%r15=0A+        movq  UREGS_r14(%rsp),%r14=0A+ =
       movq  UREGS_r13(%rsp),%r13=0A+        movq  UREGS_r12(%rsp),%r12=0A+=
        movq  UREGS_rbp(%rsp),%rbp=0A+        movq  UREGS_rbx(%rsp),%rbx=0A=
+        LOAD_C_CLOBBERED=0A+        subq  $-(UREGS_error_code-UREGS_r15+\a=
dj), %rsp=0A+.endm=0A+#endif=0A =0A #ifdef PERF_COUNTERS=0A #define =
PERFC_INCR(_name,_idx,_cur)             \=0A@@ -94,7 +103,7 @@=0A __asm__( =
                                       \=0A     "\n" __ALIGN_STR"\n"       =
                 \=0A     "common_interrupt:\n\t"                     =
\=0A-    STR(SAVE_ALL)                               \=0A+    STR(SAVE_ALL)=
 "\n\t"                        \=0A     "movq %rsp,%rdi\n\t"               =
         \=0A     "callq " STR(do_IRQ) "\n\t"                 \=0A     =
"jmp ret_from_intr\n");=0A
--=__Part96A744C2.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__Part96A744C2.0__=--


From xen-devel-bounces@lists.xen.org Tue Oct 30 14:27:35 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 14:27:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTCmT-0003xW-M2; Tue, 30 Oct 2012 14:27:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTCmS-0003xH-1z
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 14:27:00 +0000
Received: from [85.158.143.99:8876] by server-1.bemta-4.messagelabs.com id
	43/4D-19134-3B3EF805; Tue, 30 Oct 2012 14:26:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1351607211!27046559!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2874 invoked from network); 30 Oct 2012 14:26:51 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-216.messagelabs.com with SMTP;
	30 Oct 2012 14:26:51 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 30 Oct 2012 14:26:51 +0000
Message-Id: <508FF1E202000078000A5786@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 30 Oct 2012 14:27:30 +0000
From: "Jan Beulich" 
To: "xen-devel" 
References: <506B2268020000780009F273@nat28.tlf.novell.com>
	<508FF03702000078000A576D@nat28.tlf.novell.com>
In-Reply-To: <508FF03702000078000A576D@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part96A744C2.0__="
Subject: [Xen-devel] [PATCH 1/2,
 v2] x86: use MOV instead of PUSH/POP when saving/restoring register
 state
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part96A744C2.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Signed-off-by: Jan Beulich 
Acked-by: Keir Fraser 
---
This patch did not change from its v1 submission.

--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -21,8 +21,7 @@ ENTRY(compat_hypercall)
 UNLIKELY_START(ne, msi_check)
         movl  $HYPERCALL_VECTOR,%edi
         call  check_for_unexpected_msi
-        RESTORE_ALL
-        SAVE_ALL
+        LOAD_C_CLOBBERED
 UNLIKELY_END(msi_check)
=20
         GET_CURRENT(%rbx)
@@ -173,8 +172,7 @@ compat_bad_hypercall:
 /* %rbx: struct vcpu, interrupts disabled */
 compat_restore_all_guest:
         ASSERT_INTERRUPTS_DISABLED
-        RESTORE_ALL
-        addq  $8,%rsp
+        RESTORE_ALL adj=3D8
 .Lft0:  iretq
=20
 .section .fixup,"ax"
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -47,12 +47,10 @@ restore_all_guest:
         cmpl  $1,%ecx
         ja    .Lforce_iret
=20
-        addq  $8,%rsp
-        popq  %rcx                    # RIP
-        popq  %r11                    # CS
-        cmpw  $FLAT_USER_CS32,%r11
-        popq  %r11                    # RFLAGS
-        popq  %rsp                    # RSP
+        cmpw  $FLAT_USER_CS32,16(%rsp)# CS
+        movq  8(%rsp),%rcx            # RIP
+        movq  24(%rsp),%r11           # RFLAGS
+        movq  32(%rsp),%rsp           # RSP
         je    1f
         sysretq
 1:      sysretl
@@ -101,8 +99,7 @@ failsafe_callback:
         ALIGN
 /* No special register assumptions. */
 restore_all_xen:
-        RESTORE_ALL
-        addq  $8,%rsp
+        RESTORE_ALL adj=3D8
         iretq
=20
 /*
@@ -311,8 +308,7 @@ ENTRY(int80_direct_trap)
 UNLIKELY_START(ne, msi_check)
         movl  $0x80,%edi
         call  check_for_unexpected_msi
-        RESTORE_ALL
-        SAVE_ALL
+        LOAD_C_CLOBBERED
 UNLIKELY_END(msi_check)
=20
         GET_CURRENT(%rbx)
--- a/xen/include/asm-x86/x86_64/asm_defns.h
+++ b/xen/include/asm-x86/x86_64/asm_defns.h
@@ -5,11 +5,11 @@
=20
 #ifdef CONFIG_FRAME_POINTER
 /* Indicate special exception stack frame by inverting the frame pointer. =
*/
-#define SETUP_EXCEPTION_FRAME_POINTER           \
-        movq  %rsp,%rbp;                        \
+#define SETUP_EXCEPTION_FRAME_POINTER(offs)     \
+        leaq  offs(%rsp),%rbp;                  \
         notq  %rbp
 #else
-#define SETUP_EXCEPTION_FRAME_POINTER
+#define SETUP_EXCEPTION_FRAME_POINTER(off)
 #endif
=20
 #ifndef NDEBUG
@@ -27,40 +27,49 @@
 #define ASSERT_INTERRUPTS_DISABLED ASSERT_INTERRUPT_STATUS(z)
=20
 #define SAVE_ALL                                \
+        addq  $-(UREGS_error_code-UREGS_r15), %rsp; \
         cld;                                    \
-        pushq %rdi;                             \
-        pushq %rsi;                             \
-        pushq %rdx;                             \
-        pushq %rcx;                             \
-        pushq %rax;                             \
-        pushq %r8;                              \
-        pushq %r9;                              \
-        pushq %r10;                             \
-        pushq %r11;                             \
-        pushq %rbx;                             \
-        pushq %rbp;                             \
-        SETUP_EXCEPTION_FRAME_POINTER;          \
-        pushq %r12;                             \
-        pushq %r13;                             \
-        pushq %r14;                             \
-        pushq %r15;
-
-#define RESTORE_ALL                             \
-        popq  %r15;                             \
-        popq  %r14;                             \
-        popq  %r13;                             \
-        popq  %r12;                             \
-        popq  %rbp;                             \
-        popq  %rbx;                             \
-        popq  %r11;                             \
-        popq  %r10;                             \
-        popq  %r9;                              \
-        popq  %r8;                              \
-        popq  %rax;                             \
-        popq  %rcx;                             \
-        popq  %rdx;                             \
-        popq  %rsi;                             \
-        popq  %rdi;
+        movq  %rdi,UREGS_rdi(%rsp);             \
+        movq  %rsi,UREGS_rsi(%rsp);             \
+        movq  %rdx,UREGS_rdx(%rsp);             \
+        movq  %rcx,UREGS_rcx(%rsp);             \
+        movq  %rax,UREGS_rax(%rsp);             \
+        movq  %r8,UREGS_r8(%rsp);               \
+        movq  %r9,UREGS_r9(%rsp);               \
+        movq  %r10,UREGS_r10(%rsp);             \
+        movq  %r11,UREGS_r11(%rsp);             \
+        movq  %rbx,UREGS_rbx(%rsp);             \
+        movq  %rbp,UREGS_rbp(%rsp);             \
+        SETUP_EXCEPTION_FRAME_POINTER(UREGS_rbp); \
+        movq  %r12,UREGS_r12(%rsp);             \
+        movq  %r13,UREGS_r13(%rsp);             \
+        movq  %r14,UREGS_r14(%rsp);             \
+        movq  %r15,UREGS_r15(%rsp);             \
+
+#ifdef __ASSEMBLY__
+.macro LOAD_C_CLOBBERED
+        movq  UREGS_r11(%rsp),%r11
+        movq  UREGS_r10(%rsp),%r10
+        movq  UREGS_r9(%rsp),%r9
+        movq  UREGS_r8(%rsp),%r8
+        movq  UREGS_rax(%rsp),%rax
+        movq  UREGS_rcx(%rsp),%rcx
+        movq  UREGS_rdx(%rsp),%rdx
+        movq  UREGS_rsi(%rsp),%rsi
+        movq  UREGS_rdi(%rsp),%rdi
+.endm
+
+.macro RESTORE_ALL adj=3D0
+        movq  UREGS_r15(%rsp),%r15
+        movq  UREGS_r14(%rsp),%r14
+        movq  UREGS_r13(%rsp),%r13
+        movq  UREGS_r12(%rsp),%r12
+        movq  UREGS_rbp(%rsp),%rbp
+        movq  UREGS_rbx(%rsp),%rbx
+        LOAD_C_CLOBBERED
+        subq  $-(UREGS_error_code-UREGS_r15+\adj), %rsp
+.endm
+#endif
=20
 #ifdef PERF_COUNTERS
 #define PERFC_INCR(_name,_idx,_cur)             \
@@ -94,7 +103,7 @@
 __asm__(                                        \
     "\n" __ALIGN_STR"\n"                        \
     "common_interrupt:\n\t"                     \
-    STR(SAVE_ALL)                               \
+    STR(SAVE_ALL) "\n\t"                        \
     "movq %rsp,%rdi\n\t"                        \
     "callq " STR(do_IRQ) "\n\t"                 \
     "jmp ret_from_intr\n");



--=__Part96A744C2.0__=
Content-Type: text/plain; name="x86-save-restore-all-mov.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-save-restore-all-mov.patch"

x86: use MOV instead of PUSH/POP when saving/restoring register state=0A=0A=
Signed-off-by: Jan Beulich =0AAcked-by: Keir Fraser =
=0A---=0AThis patch did not change from its v1 submission.=0A=
=0A--- a/xen/arch/x86/x86_64/compat/entry.S=0A+++ b/xen/arch/x86/x86_64/com=
pat/entry.S=0A@@ -21,8 +21,7 @@ ENTRY(compat_hypercall)=0A UNLIKELY_START(n=
e, msi_check)=0A         movl  $HYPERCALL_VECTOR,%edi=0A         call  =
check_for_unexpected_msi=0A-        RESTORE_ALL=0A-        SAVE_ALL=0A+    =
    LOAD_C_CLOBBERED=0A UNLIKELY_END(msi_check)=0A =0A         GET_CURRENT(=
%rbx)=0A@@ -173,8 +172,7 @@ compat_bad_hypercall:=0A /* %rbx: struct vcpu, =
interrupts disabled */=0A compat_restore_all_guest:=0A         ASSERT_INTER=
RUPTS_DISABLED=0A-        RESTORE_ALL=0A-        addq  $8,%rsp=0A+        =
RESTORE_ALL adj=3D8=0A .Lft0:  iretq=0A =0A .section .fixup,"ax"=0A--- =
a/xen/arch/x86/x86_64/entry.S=0A+++ b/xen/arch/x86/x86_64/entry.S=0A@@ =
-47,12 +47,10 @@ restore_all_guest:=0A         cmpl  $1,%ecx=0A         ja =
   .Lforce_iret=0A =0A-        addq  $8,%rsp=0A-        popq  %rcx         =
           # RIP=0A-        popq  %r11                    # CS=0A-        =
cmpw  $FLAT_USER_CS32,%r11=0A-        popq  %r11                    # =
RFLAGS=0A-        popq  %rsp                    # RSP=0A+        cmpw  =
$FLAT_USER_CS32,16(%rsp)# CS=0A+        movq  8(%rsp),%rcx            # =
RIP=0A+        movq  24(%rsp),%r11           # RFLAGS=0A+        movq  =
32(%rsp),%rsp           # RSP=0A         je    1f=0A         sysretq=0A 1: =
     sysretl=0A@@ -101,8 +99,7 @@ failsafe_callback:=0A         ALIGN=0A =
/* No special register assumptions. */=0A restore_all_xen:=0A-        =
RESTORE_ALL=0A-        addq  $8,%rsp=0A+        RESTORE_ALL adj=3D8=0A     =
    iretq=0A =0A /*=0A@@ -311,8 +308,7 @@ ENTRY(int80_direct_trap)=0A =
UNLIKELY_START(ne, msi_check)=0A         movl  $0x80,%edi=0A         call  =
check_for_unexpected_msi=0A-        RESTORE_ALL=0A-        SAVE_ALL=0A+    =
    LOAD_C_CLOBBERED=0A UNLIKELY_END(msi_check)=0A =0A         GET_CURRENT(=
%rbx)=0A--- a/xen/include/asm-x86/x86_64/asm_defns.h=0A+++ b/xen/include/as=
m-x86/x86_64/asm_defns.h=0A@@ -5,11 +5,11 @@=0A =0A #ifdef CONFIG_FRAME_POI=
NTER=0A /* Indicate special exception stack frame by inverting the frame =
pointer. */=0A-#define SETUP_EXCEPTION_FRAME_POINTER           \=0A-       =
 movq  %rsp,%rbp;                        \=0A+#define SETUP_EXCEPTION_FRAME=
_POINTER(offs)     \=0A+        leaq  offs(%rsp),%rbp;                  =
\=0A         notq  %rbp=0A #else=0A-#define SETUP_EXCEPTION_FRAME_POINTER=
=0A+#define SETUP_EXCEPTION_FRAME_POINTER(off)=0A #endif=0A =0A #ifndef =
NDEBUG=0A@@ -27,40 +27,49 @@=0A #define ASSERT_INTERRUPTS_DISABLED =
ASSERT_INTERRUPT_STATUS(z)=0A =0A #define SAVE_ALL                         =
       \=0A+        addq  $-(UREGS_error_code-UREGS_r15), %rsp; \=0A       =
  cld;                                    \=0A-        pushq %rdi;         =
                    \=0A-        pushq %rsi;                             =
\=0A-        pushq %rdx;                             \=0A-        pushq =
%rcx;                             \=0A-        pushq %rax;                 =
            \=0A-        pushq %r8;                              \=0A-     =
   pushq %r9;                              \=0A-        pushq %r10;        =
                     \=0A-        pushq %r11;                             =
\=0A-        pushq %rbx;                             \=0A-        pushq =
%rbp;                             \=0A-        SETUP_EXCEPTION_FRAME_POINTE=
R;          \=0A-        pushq %r12;                             \=0A-     =
   pushq %r13;                             \=0A-        pushq %r14;        =
                     \=0A-        pushq %r15;=0A-=0A-#define RESTORE_ALL   =
                          \=0A-        popq  %r15;                         =
    \=0A-        popq  %r14;                             \=0A-        popq =
 %r13;                             \=0A-        popq  %r12;                =
             \=0A-        popq  %rbp;                             \=0A-    =
    popq  %rbx;                             \=0A-        popq  %r11;       =
                      \=0A-        popq  %r10;                             =
\=0A-        popq  %r9;                              \=0A-        popq  =
%r8;                              \=0A-        popq  %rax;                 =
            \=0A-        popq  %rcx;                             \=0A-     =
   popq  %rdx;                             \=0A-        popq  %rsi;        =
                     \=0A-        popq  %rdi;=0A+        movq  %rdi,UREGS_r=
di(%rsp);             \=0A+        movq  %rsi,UREGS_rsi(%rsp);             =
\=0A+        movq  %rdx,UREGS_rdx(%rsp);             \=0A+        movq  =
%rcx,UREGS_rcx(%rsp);             \=0A+        movq  %rax,UREGS_rax(%rsp); =
            \=0A+        movq  %r8,UREGS_r8(%rsp);               \=0A+     =
   movq  %r9,UREGS_r9(%rsp);               \=0A+        movq  %r10,UREGS_r1=
0(%rsp);             \=0A+        movq  %r11,UREGS_r11(%rsp);             =
\=0A+        movq  %rbx,UREGS_rbx(%rsp);             \=0A+        movq  =
%rbp,UREGS_rbp(%rsp);             \=0A+        SETUP_EXCEPTION_FRAME_POINTE=
R(UREGS_rbp); \=0A+        movq  %r12,UREGS_r12(%rsp);             \=0A+   =
     movq  %r13,UREGS_r13(%rsp);             \=0A+        movq  %r14,UREGS_=
r14(%rsp);             \=0A+        movq  %r15,UREGS_r15(%rsp);            =
 \=0A+=0A+#ifdef __ASSEMBLY__=0A+.macro LOAD_C_CLOBBERED=0A+        movq  =
UREGS_r11(%rsp),%r11=0A+        movq  UREGS_r10(%rsp),%r10=0A+        movq =
 UREGS_r9(%rsp),%r9=0A+        movq  UREGS_r8(%rsp),%r8=0A+        movq  =
UREGS_rax(%rsp),%rax=0A+        movq  UREGS_rcx(%rsp),%rcx=0A+        movq =
 UREGS_rdx(%rsp),%rdx=0A+        movq  UREGS_rsi(%rsp),%rsi=0A+        =
movq  UREGS_rdi(%rsp),%rdi=0A+.endm=0A+=0A+.macro RESTORE_ALL adj=3D0=0A+  =
      movq  UREGS_r15(%rsp),%r15=0A+        movq  UREGS_r14(%rsp),%r14=0A+ =
       movq  UREGS_r13(%rsp),%r13=0A+        movq  UREGS_r12(%rsp),%r12=0A+=
        movq  UREGS_rbp(%rsp),%rbp=0A+        movq  UREGS_rbx(%rsp),%rbx=0A=
+        LOAD_C_CLOBBERED=0A+        subq  $-(UREGS_error_code-UREGS_r15+\a=
dj), %rsp=0A+.endm=0A+#endif=0A =0A #ifdef PERF_COUNTERS=0A #define =
PERFC_INCR(_name,_idx,_cur)             \=0A@@ -94,7 +103,7 @@=0A __asm__( =
                                       \=0A     "\n" __ALIGN_STR"\n"       =
                 \=0A     "common_interrupt:\n\t"                     =
\=0A-    STR(SAVE_ALL)                               \=0A+    STR(SAVE_ALL)=
 "\n\t"                        \=0A     "movq %rsp,%rdi\n\t"               =
         \=0A     "callq " STR(do_IRQ) "\n\t"                 \=0A     =
"jmp ret_from_intr\n");=0A
--=__Part96A744C2.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__Part96A744C2.0__=--


From xen-devel-bounces@lists.xen.org Tue Oct 30 14:30:03 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 14:30:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTCoS-000477-TZ; Tue, 30 Oct 2012 14:29:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTCoQ-00046r-Rm
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 14:29:03 +0000
Received: from [85.158.143.99:32415] by server-3.bemta-4.messagelabs.com id
	56/F2-24279-E24EF805; Tue, 30 Oct 2012 14:29:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1351607341!21552839!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2957 invoked from network); 30 Oct 2012 14:29:01 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-216.messagelabs.com with SMTP;
	30 Oct 2012 14:29:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 30 Oct 2012 14:29:00 +0000
Message-Id: <508FF26402000078000A578A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 30 Oct 2012 14:29:40 +0000
From: "Jan Beulich" 
To: "xen-devel" 
References: <506B2268020000780009F273@nat28.tlf.novell.com>
	<508FF03702000078000A576D@nat28.tlf.novell.com>
In-Reply-To: <508FF03702000078000A576D@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part1726C544.0__="
Subject: [Xen-devel] [PATCH 2/2,
 v2] x86: save/restore only partial register state where possible
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part1726C544.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

... and make restore conditional not only upon having saved the state,
but also upon whether saved state was actually modified (and register
values are known to have been preserved).

Note that RBP is unconditionally considered a volatile register (i.e.
irrespective of CONFIG_FRAME_POINTER), since the RBP handling would
become overly complicated due to the need to save/restore it on the
compat mode hypercall path [6th argument].

Note further that for compat mode code paths, saving/restoring R8...R15
is entirely unnecessary - we don't allow those guests to enter 64-bit
mode, and hence they have no way of seeing these registers' contents
(and there consequently also is no information leak, except if the
context saving domctl would be considered such).

Finally, note that this may not properly deal with gdbstub's needs, yet
(but if so, I can't really suggest adjustments, as I don't know that
code).

Signed-off-by: Jan Beulich 
---
v2: Add a few comments.

This patch functionally depends on x86-drop-get_x86_gpr.patch.

--- a/tools/tests/x86_emulator/x86_emulate.c
+++ b/tools/tests/x86_emulator/x86_emulate.c
@@ -10,6 +10,7 @@ typedef bool bool_t;
 #define BUG() abort()
=20
 #define cpu_has_amd_erratum(nr) 0
+#define mark_regs_dirty(r) ((void)(r))
=20
 #include "x86_emulate/x86_emulate.h"
 #include "x86_emulate/x86_emulate.c"
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -143,6 +143,7 @@ static void continue_idle_domain(struct=20
 static void continue_nonidle_domain(struct vcpu *v)
 {
     check_wakeup_from_wait();
+    mark_regs_dirty(guest_cpu_user_regs());
     reset_stack_and_jump(ret_from_intr);
 }
=20
@@ -1312,7 +1313,7 @@ static void load_segments(struct vcpu *n
             if ( test_bit(_VGCF_failsafe_disables_events, &n->arch.vgc_fla=
gs) )
                 vcpu_info(n, evtchn_upcall_mask) =3D 1;
=20
-            regs->entry_vector  =3D TRAP_syscall;
+            regs->entry_vector |=3D TRAP_syscall;
             regs->_eflags      &=3D 0xFFFCBEFFUL;
             regs->ss            =3D FLAT_COMPAT_KERNEL_SS;
             regs->_esp          =3D (unsigned long)(esp-7);
@@ -1354,7 +1355,7 @@ static void load_segments(struct vcpu *n
         if ( test_bit(_VGCF_failsafe_disables_events, &n->arch.vgc_flags) =
)
             vcpu_info(n, evtchn_upcall_mask) =3D 1;
=20
-        regs->entry_vector  =3D TRAP_syscall;
+        regs->entry_vector |=3D TRAP_syscall;
         regs->rflags       &=3D ~(X86_EFLAGS_AC|X86_EFLAGS_VM|X86_EFLAGS_R=
F|
                                 X86_EFLAGS_NT|X86_EFLAGS_TF);
         regs->ss            =3D FLAT_KERNEL_SS;
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -704,7 +704,7 @@ void irq_complete_move(struct irq_desc *
     if (likely(!desc->arch.move_in_progress))
         return;
=20
-    vector =3D get_irq_regs()->entry_vector;
+    vector =3D (u8)get_irq_regs()->entry_vector;
     me =3D smp_processor_id();
=20
     if ( vector =3D=3D desc->arch.vector &&
@@ -798,7 +798,7 @@ void do_IRQ(struct cpu_user_regs *regs)
     struct irqaction *action;
     uint32_t          tsc_in;
     struct irq_desc  *desc;
-    unsigned int      vector =3D regs->entry_vector;
+    unsigned int      vector =3D (u8)regs->entry_vector;
     int irq =3D __get_cpu_var(vector_irq[vector]);
     struct cpu_user_regs *old_regs =3D set_irq_regs(regs);
    =20
@@ -892,7 +892,7 @@ void do_IRQ(struct cpu_user_regs *regs)
=20
  out:
     if ( desc->handler->end )
-        desc->handler->end(desc, regs->entry_vector);
+        desc->handler->end(desc, vector);
  out_no_end:
     spin_unlock(&desc->lock);
  out_no_unlock:
@@ -1113,7 +1113,7 @@ static void __do_IRQ_guest(int irq)
     struct domain      *d;
     int                 i, sp;
     struct pending_eoi *peoi =3D this_cpu(pending_eoi);
-    int vector =3D get_irq_regs()->entry_vector;
+    unsigned int        vector =3D (u8)get_irq_regs()->entry_vector;
=20
     if ( unlikely(action->nr_guests =3D=3D 0) )
     {
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -2082,6 +2082,7 @@ static int emulate_privileged_op(struct=20
             goto fail;
         if ( admin_io_okay(port, op_bytes, v, regs) )
         {
+            mark_regs_dirty(regs);
             io_emul(regs);           =20
         }
         else
@@ -2111,6 +2112,7 @@ static int emulate_privileged_op(struct=20
             goto fail;
         if ( admin_io_okay(port, op_bytes, v, regs) )
         {
+            mark_regs_dirty(regs);
             io_emul(regs);           =20
             if ( (op_bytes =3D=3D 1) && pv_post_outb_hook )
                 pv_post_outb_hook(port, regs->eax);
--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -14,8 +14,7 @@
=20
 ENTRY(compat_hypercall)
         pushq $0
-        movl  $TRAP_syscall,4(%rsp)
-        SAVE_ALL
+        SAVE_VOLATILE type=3DTRAP_syscall compat=3D1
=20
         cmpb  $0,untrusted_msi(%rip)
 UNLIKELY_START(ne, msi_check)
@@ -126,6 +125,7 @@ compat_test_guest_events:
 /* %rbx: struct vcpu */
 compat_process_softirqs:
         sti
+        andl  $~TRAP_regs_partial,UREGS_entry_vector(%rsp)
         call  do_softirq
         jmp   compat_test_all_events
=20
@@ -172,7 +172,7 @@ compat_bad_hypercall:
 /* %rbx: struct vcpu, interrupts disabled */
 compat_restore_all_guest:
         ASSERT_INTERRUPTS_DISABLED
-        RESTORE_ALL adj=3D8
+        RESTORE_ALL adj=3D8 compat=3D1
 .Lft0:  iretq
=20
 .section .fixup,"ax"
@@ -243,7 +243,7 @@ UNLIKELY_END(compat_syscall_gpf)
=20
 ENTRY(compat_sysenter)
         movq  VCPU_trap_ctxt(%rbx),%rcx
-        cmpl  $TRAP_gp_fault,UREGS_entry_vector(%rsp)
+        cmpb  $TRAP_gp_fault,UREGS_entry_vector(%rsp)
         movzwl VCPU_sysenter_sel(%rbx),%eax
         movzwl TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_cs(%rcx),%ecx
         cmovel %ecx,%eax
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -123,9 +123,8 @@ ENTRY(syscall_enter)
         movl  $FLAT_KERNEL_SS,24(%rsp)
         pushq %rcx
         pushq $0
-        movl  $TRAP_syscall,4(%rsp)
-        movq  24(%rsp),%r11 /* Re-load user RFLAGS into %r11 before =
SAVE_ALL */
-        SAVE_ALL
+        movq  24(%rsp),%r11 /* Re-load user RFLAGS into %r11 before =
saving */
+        SAVE_VOLATILE TRAP_syscall
         GET_CURRENT(%rbx)
         movq  VCPU_domain(%rbx),%rcx
         testb $1,DOMAIN_is_32bit_pv(%rcx)
@@ -222,6 +221,7 @@ test_guest_events:
 /* %rbx: struct vcpu */
 process_softirqs:
         sti      =20
+        SAVE_PRESERVED
         call do_softirq
         jmp  test_all_events
=20
@@ -275,8 +275,7 @@ sysenter_eflags_saved:
         pushq $3 /* ring 3 null cs */
         pushq $0 /* null rip */
         pushq $0
-        movl  $TRAP_syscall,4(%rsp)
-        SAVE_ALL
+        SAVE_VOLATILE TRAP_syscall
         GET_CURRENT(%rbx)
         cmpb  $0,VCPU_sysenter_disables_events(%rbx)
         movq  VCPU_sysenter_addr(%rbx),%rax
@@ -286,6 +285,7 @@ sysenter_eflags_saved:
         leal  (,%rcx,TBF_INTERRUPT),%ecx
 UNLIKELY_START(z, sysenter_gpf)
         movq  VCPU_trap_ctxt(%rbx),%rsi
+        SAVE_PRESERVED
         movl  $TRAP_gp_fault,UREGS_entry_vector(%rsp)
         movl  %eax,TRAPBOUNCE_error_code(%rdx)
         movq  TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_eip(%rsi),%rax
@@ -302,7 +302,7 @@ UNLIKELY_END(sysenter_gpf)
=20
 ENTRY(int80_direct_trap)
         pushq $0
-        SAVE_ALL
+        SAVE_VOLATILE 0x80
=20
         cmpb  $0,untrusted_msi(%rip)
 UNLIKELY_START(ne, msi_check)
@@ -331,6 +331,7 @@ int80_slow_path:
          * IDT entry with DPL=3D=3D0.
          */
         movl  $((0x80 << 3) | 0x2),UREGS_error_code(%rsp)
+        SAVE_PRESERVED
         movl  $TRAP_gp_fault,UREGS_entry_vector(%rsp)
         /* A GPF wouldn't have incremented the instruction pointer. */
         subq  $2,UREGS_rip(%rsp)
@@ -412,7 +413,7 @@ UNLIKELY_END(bounce_failsafe)
         /* Rewrite our stack frame and return to guest-OS mode. */
         /* IA32 Ref. Vol. 3: TF, VM, RF and NT flags are cleared on trap. =
*/
         /* Also clear AC: alignment checks shouldn't trigger in kernel =
mode. */
-        movl  $TRAP_syscall,UREGS_entry_vector+8(%rsp)
+        orl   $TRAP_syscall,UREGS_entry_vector+8(%rsp)
         andl  $~(X86_EFLAGS_AC|X86_EFLAGS_VM|X86_EFLAGS_RF|\
                  X86_EFLAGS_NT|X86_EFLAGS_TF),UREGS_eflags+8(%rsp)
         movq  $FLAT_KERNEL_SS,UREGS_ss+8(%rsp)
@@ -477,7 +478,7 @@ handle_exception_saved:
         jz    exception_with_ints_disabled
         sti
 1:      movq  %rsp,%rdi
-        movl  UREGS_entry_vector(%rsp),%eax
+        movzbl UREGS_entry_vector(%rsp),%eax
         leaq  exception_table(%rip),%rdx
         GET_CURRENT(%rbx)
         PERFC_INCR(exceptions, %rax, %rbx)
@@ -518,7 +519,7 @@ exception_with_ints_disabled:
=20
 /* No special register assumptions. */
 FATAL_exception_with_ints_disabled:
-        movl  UREGS_entry_vector(%rsp),%edi
+        movzbl UREGS_entry_vector(%rsp),%edi
         movq  %rsp,%rsi
         call  fatal_trap
         ud2
@@ -624,7 +625,7 @@ handle_ist_exception:
         movq  %rdi,%rsp
         rep   movsq
 1:      movq  %rsp,%rdi
-        movl  UREGS_entry_vector(%rsp),%eax
+        movzbl UREGS_entry_vector(%rsp),%eax
         leaq  exception_table(%rip),%rdx
         callq *(%rdx,%rax,8)
         jmp   ret_from_intr
--- a/xen/arch/x86/x86_64/traps.c
+++ b/xen/arch/x86/x86_64/traps.c
@@ -67,10 +67,15 @@ static void _show_registers(
            regs->rbp, regs->rsp, regs->r8);
     printk("r9:  %016lx   r10: %016lx   r11: %016lx\n",
            regs->r9,  regs->r10, regs->r11);
-    printk("r12: %016lx   r13: %016lx   r14: %016lx\n",
-           regs->r12, regs->r13, regs->r14);
-    printk("r15: %016lx   cr0: %016lx   cr4: %016lx\n",
-           regs->r15, crs[0], crs[4]);
+    if ( !(regs->entry_vector & TRAP_regs_partial) )
+    {
+        printk("r12: %016lx   r13: %016lx   r14: %016lx\n",
+               regs->r12, regs->r13, regs->r14);
+        printk("r15: %016lx   cr0: %016lx   cr4: %016lx\n",
+               regs->r15, crs[0], crs[4]);
+    }
+    else
+        printk("cr0: %016lx   cr4: %016lx\n", crs[0], crs[4]);
     printk("cr3: %016lx   cr2: %016lx\n", crs[3], crs[2]);
     printk("ds: %04x   es: %04x   fs: %04x   gs: %04x   "
            "ss: %04x   cs: %04x\n",
@@ -301,7 +306,7 @@ unsigned long do_iret(void)
=20
     if ( !(iret_saved.flags & VGCF_in_syscall) )
     {
-        regs->entry_vector =3D 0;
+        regs->entry_vector &=3D ~TRAP_syscall;
         regs->r11 =3D iret_saved.r11;
         regs->rcx =3D iret_saved.rcx;
     }
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1292,10 +1292,10 @@ decode_register(
     case  9: p =3D ®s->r9;  break;
     case 10: p =3D ®s->r10; break;
     case 11: p =3D ®s->r11; break;
-    case 12: p =3D ®s->r12; break;
-    case 13: p =3D ®s->r13; break;
-    case 14: p =3D ®s->r14; break;
-    case 15: p =3D ®s->r15; break;
+    case 12: mark_regs_dirty(regs); p =3D ®s->r12; break;
+    case 13: mark_regs_dirty(regs); p =3D ®s->r13; break;
+    case 14: mark_regs_dirty(regs); p =3D ®s->r14; break;
+    case 15: mark_regs_dirty(regs); p =3D ®s->r15; break;
 #endif
     default: BUG(); p =3D NULL; break;
     }
--- a/xen/arch/x86/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate.c
@@ -10,6 +10,7 @@
  */
=20
 #include 
+#include  /* mark_regs_dirty() */
 #include  /* current_cpu_info */
 #include  /* cpu_has_amd_erratum() */
=20
--- a/xen/common/wait.c
+++ b/xen/common/wait.c
@@ -124,10 +124,12 @@ void wake_up_all(struct waitqueue_head *
=20
 static void __prepare_to_wait(struct waitqueue_vcpu *wqv)
 {
-    char *cpu_info =3D (char *)get_cpu_info();
+    struct cpu_info *cpu_info =3D get_cpu_info();
     struct vcpu *curr =3D current;
     unsigned long dummy;
+    u32 entry_vector =3D cpu_info->guest_cpu_user_regs.entry_vector;
=20
+    cpu_info->guest_cpu_user_regs.entry_vector &=3D ~TRAP_regs_partial;
     ASSERT(wqv->esp =3D=3D 0);
=20
     /* Save current VCPU affinity; force wakeup on *this* CPU only. */
@@ -157,6 +159,8 @@ static void __prepare_to_wait(struct wai
         gdprintk(XENLOG_ERR, "Stack too large in %s\n", __FUNCTION__);
         domain_crash_synchronous();
     }
+
+    cpu_info->guest_cpu_user_regs.entry_vector =3D entry_vector;
 }
=20
 static void __finish_wait(struct waitqueue_vcpu *wqv)
--- a/xen/include/asm-x86/x86_64/asm_defns.h
+++ b/xen/include/asm-x86/x86_64/asm_defns.h
@@ -26,6 +26,31 @@
 #define ASSERT_INTERRUPTS_ENABLED  ASSERT_INTERRUPT_STATUS(nz)
 #define ASSERT_INTERRUPTS_DISABLED ASSERT_INTERRUPT_STATUS(z)
=20
+/*
+ * This flag is set in an exception frame when registers R12-R15 did not =
get
+ * saved.
+ */
+#define _TRAP_regs_partial 16
+#define TRAP_regs_partial  (1 << _TRAP_regs_partial)
+/*
+ * This flag gets set in an exception frame when registers R12-R15 =
possibly
+ * get modified from their originally saved values and hence need to be
+ * restored even if the normal call flow would restore register values.
+ *
+ * The flag being set implies _TRAP_regs_partial to be unset. Restoring
+ * R12-R15 thus is
+ * - required when this flag is set,
+ * - safe when _TRAP_regs_partial is unset.
+ */
+#define _TRAP_regs_dirty   17
+#define TRAP_regs_dirty    (1 << _TRAP_regs_dirty)
+
+#define mark_regs_dirty(r) ({ \
+        struct cpu_user_regs *r__ =3D (r); \
+        ASSERT(!((r__)->entry_vector & TRAP_regs_partial)); \
+        r__->entry_vector |=3D TRAP_regs_dirty; \
+})
+
 #define SAVE_ALL                                \
         addq  $-(UREGS_error_code-UREGS_r15), %rsp; \
         cld;                                    \
@@ -47,11 +72,66 @@
         movq  %r15,UREGS_r15(%rsp);             \
=20
 #ifdef __ASSEMBLY__
-.macro LOAD_C_CLOBBERED
+
+/*
+ * Save all registers not preserved by C code or used in entry/exit code. =
Mark
+ * the frame as partial.
+ *
+ * @type: exception type
+ * @compat: R8-R15 don't need saving, and the frame nevertheless is =
complete
+ */
+.macro SAVE_VOLATILE type compat=3D0
+.if \compat
+        movl  $\type,UREGS_entry_vector-UREGS_error_code(%rsp)
+.else
+        movl  $\type|TRAP_regs_partial,\
+              UREGS_entry_vector-UREGS_error_code(%rsp)
+.endif
+        addq  $-(UREGS_error_code-UREGS_r15),%rsp
+        cld
+        movq  %rdi,UREGS_rdi(%rsp)
+        movq  %rsi,UREGS_rsi(%rsp)
+        movq  %rdx,UREGS_rdx(%rsp)
+        movq  %rcx,UREGS_rcx(%rsp)
+        movq  %rax,UREGS_rax(%rsp)
+.if !\compat
+        movq  %r8,UREGS_r8(%rsp)
+        movq  %r9,UREGS_r9(%rsp)
+        movq  %r10,UREGS_r10(%rsp)
+        movq  %r11,UREGS_r11(%rsp)
+.endif
+        movq  %rbx,UREGS_rbx(%rsp)
+        movq  %rbp,UREGS_rbp(%rsp)
+        SETUP_EXCEPTION_FRAME_POINTER(UREGS_rbp)
+.endm
+
+/*
+ * Complete a frame potentially only partially saved.
+ */
+.macro SAVE_PRESERVED
+        btrl  $_TRAP_regs_partial,UREGS_entry_vector(%rsp)
+        jnc   987f
+        movq  %r12,UREGS_r12(%rsp)
+        movq  %r13,UREGS_r13(%rsp)
+        movq  %r14,UREGS_r14(%rsp)
+        movq  %r15,UREGS_r15(%rsp)
+987:
+.endm
+
+/*
+ * Reload registers not preserved by C code from frame.
+ *
+ * @compat: R8-R11 don't need reloading
+ *
+ * For the way it is used in RESTORE_ALL, this macro must preserve =
EFLAGS.ZF.
+ */
+.macro LOAD_C_CLOBBERED compat=3D0
+.if !\compat
         movq  UREGS_r11(%rsp),%r11
         movq  UREGS_r10(%rsp),%r10
         movq  UREGS_r9(%rsp),%r9
         movq  UREGS_r8(%rsp),%r8
+.endif
         movq  UREGS_rax(%rsp),%rax
         movq  UREGS_rcx(%rsp),%rcx
         movq  UREGS_rdx(%rsp),%rdx
@@ -59,16 +139,45 @@
         movq  UREGS_rdi(%rsp),%rdi
 .endm
=20
-.macro RESTORE_ALL adj=3D0
+/*
+ * Restore all previously saved registers.
+ *
+ * @adj: extra stack pointer adjustment to be folded into the adjustment =
done
+ *       anyway at the end of the macro
+ * @compat: R8-R15 don't need reloading
+ */
+.macro RESTORE_ALL adj=3D0 compat=3D0
+.if !\compat
+        testl $TRAP_regs_dirty,UREGS_entry_vector(%rsp)
+.endif
+        LOAD_C_CLOBBERED \compat
+.if !\compat
+        jz    987f
         movq  UREGS_r15(%rsp),%r15
         movq  UREGS_r14(%rsp),%r14
         movq  UREGS_r13(%rsp),%r13
         movq  UREGS_r12(%rsp),%r12
-        movq  UREGS_rbp(%rsp),%rbp
+#ifndef NDEBUG
+        .subsection 1
+987:    testl $TRAP_regs_partial,UREGS_entry_vector(%rsp)
+        jnz   987f
+        cmpq  UREGS_r15(%rsp),%r15
+        jne   789f
+        cmpq  UREGS_r14(%rsp),%r14
+        jne   789f
+        cmpq  UREGS_r13(%rsp),%r13
+        jne   789f
+        cmpq  UREGS_r12(%rsp),%r12
+        je    987f
+789:    ud2
+        .subsection 0
+#endif
+.endif
+987:    movq  UREGS_rbp(%rsp),%rbp
         movq  UREGS_rbx(%rsp),%rbx
-        LOAD_C_CLOBBERED
         subq  $-(UREGS_error_code-UREGS_r15+\adj), %rsp
 .endm
+
 #endif
=20
 #ifdef PERF_COUNTERS



--=__Part1726C544.0__=
Content-Type: text/plain; name="x86-save-restore-reduce.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-save-restore-reduce.patch"

x86: save/restore only partial register state where possible=0A=0A... and =
make restore conditional not only upon having saved the state,=0Abut also =
upon whether saved state was actually modified (and register=0Avalues are =
known to have been preserved).=0A=0ANote that RBP is unconditionally =
considered a volatile register (i.e.=0Airrespective of CONFIG_FRAME_POINTER=
), since the RBP handling would=0Abecome overly complicated due to the =
need to save/restore it on the=0Acompat mode hypercall path [6th argument].=
=0A=0ANote further that for compat mode code paths, saving/restoring =
R8...R15=0Ais entirely unnecessary - we don't allow those guests to enter =
64-bit=0Amode, and hence they have no way of seeing these registers' =
contents=0A(and there consequently also is no information leak, except if =
the=0Acontext saving domctl would be considered such).=0A=0AFinally, note =
that this may not properly deal with gdbstub's needs, yet=0A(but if so, I =
can't really suggest adjustments, as I don't know that=0Acode).=0A=0ASigned=
-off-by: Jan Beulich =0A---=0Av2: Add a few comments.=0A=
=0AThis patch functionally depends on x86-drop-get_x86_gpr.patch.=0A=0A--- =
a/tools/tests/x86_emulator/x86_emulate.c=0A+++ b/tools/tests/x86_emulator/x=
86_emulate.c=0A@@ -10,6 +10,7 @@ typedef bool bool_t;=0A #define BUG() =
abort()=0A =0A #define cpu_has_amd_erratum(nr) 0=0A+#define mark_regs_dirty=
(r) ((void)(r))=0A =0A #include "x86_emulate/x86_emulate.h"=0A #include =
"x86_emulate/x86_emulate.c"=0A--- a/xen/arch/x86/domain.c=0A+++ b/xen/arch/=
x86/domain.c=0A@@ -143,6 +143,7 @@ static void continue_idle_domain(struct =
=0A static void continue_nonidle_domain(struct vcpu *v)=0A {=0A     =
check_wakeup_from_wait();=0A+    mark_regs_dirty(guest_cpu_user_regs());=0A=
     reset_stack_and_jump(ret_from_intr);=0A }=0A =0A@@ -1312,7 +1313,7 @@ =
static void load_segments(struct vcpu *n=0A             if ( test_bit(_VGCF=
_failsafe_disables_events, &n->arch.vgc_flags) )=0A                 =
vcpu_info(n, evtchn_upcall_mask) =3D 1;=0A =0A-            regs->entry_vect=
or  =3D TRAP_syscall;=0A+            regs->entry_vector |=3D TRAP_syscall;=
=0A             regs->_eflags      &=3D 0xFFFCBEFFUL;=0A             =
regs->ss            =3D FLAT_COMPAT_KERNEL_SS;=0A             regs->_esp   =
       =3D (unsigned long)(esp-7);=0A@@ -1354,7 +1355,7 @@ static void =
load_segments(struct vcpu *n=0A         if ( test_bit(_VGCF_failsafe_disabl=
es_events, &n->arch.vgc_flags) )=0A             vcpu_info(n, evtchn_upcall_=
mask) =3D 1;=0A =0A-        regs->entry_vector  =3D TRAP_syscall;=0A+      =
  regs->entry_vector |=3D TRAP_syscall;=0A         regs->rflags       &=3D =
~(X86_EFLAGS_AC|X86_EFLAGS_VM|X86_EFLAGS_RF|=0A                            =
     X86_EFLAGS_NT|X86_EFLAGS_TF);=0A         regs->ss            =3D =
FLAT_KERNEL_SS;=0A--- a/xen/arch/x86/irq.c=0A+++ b/xen/arch/x86/irq.c=0A@@ =
-704,7 +704,7 @@ void irq_complete_move(struct irq_desc *=0A     if =
(likely(!desc->arch.move_in_progress))=0A         return;=0A =0A-    =
vector =3D get_irq_regs()->entry_vector;=0A+    vector =3D (u8)get_irq_regs=
()->entry_vector;=0A     me =3D smp_processor_id();=0A =0A     if ( vector =
=3D=3D desc->arch.vector &&=0A@@ -798,7 +798,7 @@ void do_IRQ(struct =
cpu_user_regs *regs)=0A     struct irqaction *action;=0A     uint32_t      =
    tsc_in;=0A     struct irq_desc  *desc;=0A-    unsigned int      vector =
=3D regs->entry_vector;=0A+    unsigned int      vector =3D (u8)regs->entry=
_vector;=0A     int irq =3D __get_cpu_var(vector_irq[vector]);=0A     =
struct cpu_user_regs *old_regs =3D set_irq_regs(regs);=0A     =0A@@ -892,7 =
+892,7 @@ void do_IRQ(struct cpu_user_regs *regs)=0A =0A  out:=0A     if ( =
desc->handler->end )=0A-        desc->handler->end(desc, regs->entry_vector=
);=0A+        desc->handler->end(desc, vector);=0A  out_no_end:=0A     =
spin_unlock(&desc->lock);=0A  out_no_unlock:=0A@@ -1113,7 +1113,7 @@ =
static void __do_IRQ_guest(int irq)=0A     struct domain      *d;=0A     =
int                 i, sp;=0A     struct pending_eoi *peoi =3D this_cpu(pen=
ding_eoi);=0A-    int vector =3D get_irq_regs()->entry_vector;=0A+    =
unsigned int        vector =3D (u8)get_irq_regs()->entry_vector;=0A =0A    =
 if ( unlikely(action->nr_guests =3D=3D 0) )=0A     {=0A--- a/xen/arch/x86/=
traps.c=0A+++ b/xen/arch/x86/traps.c=0A@@ -2082,6 +2082,7 @@ static int =
emulate_privileged_op(struct =0A             goto fail;=0A         if ( =
admin_io_okay(port, op_bytes, v, regs) )=0A         {=0A+            =
mark_regs_dirty(regs);=0A             io_emul(regs);            =0A        =
 }=0A         else=0A@@ -2111,6 +2112,7 @@ static int emulate_privileged_op=
(struct =0A             goto fail;=0A         if ( admin_io_okay(port, =
op_bytes, v, regs) )=0A         {=0A+            mark_regs_dirty(regs);=0A =
            io_emul(regs);            =0A             if ( (op_bytes =
=3D=3D 1) && pv_post_outb_hook )=0A                 pv_post_outb_hook(port,=
 regs->eax);=0A--- a/xen/arch/x86/x86_64/compat/entry.S=0A+++ b/xen/arch/x8=
6/x86_64/compat/entry.S=0A@@ -14,8 +14,7 @@=0A =0A ENTRY(compat_hypercall)=
=0A         pushq $0=0A-        movl  $TRAP_syscall,4(%rsp)=0A-        =
SAVE_ALL=0A+        SAVE_VOLATILE type=3DTRAP_syscall compat=3D1=0A =0A    =
     cmpb  $0,untrusted_msi(%rip)=0A UNLIKELY_START(ne, msi_check)=0A@@ =
-126,6 +125,7 @@ compat_test_guest_events:=0A /* %rbx: struct vcpu */=0A =
compat_process_softirqs:=0A         sti=0A+        andl  $~TRAP_regs_partia=
l,UREGS_entry_vector(%rsp)=0A         call  do_softirq=0A         jmp   =
compat_test_all_events=0A =0A@@ -172,7 +172,7 @@ compat_bad_hypercall:=0A =
/* %rbx: struct vcpu, interrupts disabled */=0A compat_restore_all_guest:=
=0A         ASSERT_INTERRUPTS_DISABLED=0A-        RESTORE_ALL adj=3D8=0A+  =
      RESTORE_ALL adj=3D8 compat=3D1=0A .Lft0:  iretq=0A =0A .section =
.fixup,"ax"=0A@@ -243,7 +243,7 @@ UNLIKELY_END(compat_syscall_gpf)=0A =0A =
ENTRY(compat_sysenter)=0A         movq  VCPU_trap_ctxt(%rbx),%rcx=0A-      =
  cmpl  $TRAP_gp_fault,UREGS_entry_vector(%rsp)=0A+        cmpb  $TRAP_gp_f=
ault,UREGS_entry_vector(%rsp)=0A         movzwl VCPU_sysenter_sel(%rbx),%ea=
x=0A         movzwl TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_cs(%rcx),%ec=
x=0A         cmovel %ecx,%eax=0A--- a/xen/arch/x86/x86_64/entry.S=0A+++ =
b/xen/arch/x86/x86_64/entry.S=0A@@ -123,9 +123,8 @@ ENTRY(syscall_enter)=0A=
         movl  $FLAT_KERNEL_SS,24(%rsp)=0A         pushq %rcx=0A         =
pushq $0=0A-        movl  $TRAP_syscall,4(%rsp)=0A-        movq  24(%rsp),%=
r11 /* Re-load user RFLAGS into %r11 before SAVE_ALL */=0A-        =
SAVE_ALL=0A+        movq  24(%rsp),%r11 /* Re-load user RFLAGS into %r11 =
before saving */=0A+        SAVE_VOLATILE TRAP_syscall=0A         =
GET_CURRENT(%rbx)=0A         movq  VCPU_domain(%rbx),%rcx=0A         testb =
$1,DOMAIN_is_32bit_pv(%rcx)=0A@@ -222,6 +221,7 @@ test_guest_events:=0A /* =
%rbx: struct vcpu */=0A process_softirqs:=0A         sti       =0A+        =
SAVE_PRESERVED=0A         call do_softirq=0A         jmp  test_all_events=
=0A =0A@@ -275,8 +275,7 @@ sysenter_eflags_saved:=0A         pushq $3 /* =
ring 3 null cs */=0A         pushq $0 /* null rip */=0A         pushq =
$0=0A-        movl  $TRAP_syscall,4(%rsp)=0A-        SAVE_ALL=0A+        =
SAVE_VOLATILE TRAP_syscall=0A         GET_CURRENT(%rbx)=0A         cmpb  =
$0,VCPU_sysenter_disables_events(%rbx)=0A         movq  VCPU_sysenter_addr(=
%rbx),%rax=0A@@ -286,6 +285,7 @@ sysenter_eflags_saved:=0A         leal  =
(,%rcx,TBF_INTERRUPT),%ecx=0A UNLIKELY_START(z, sysenter_gpf)=0A         =
movq  VCPU_trap_ctxt(%rbx),%rsi=0A+        SAVE_PRESERVED=0A         movl  =
$TRAP_gp_fault,UREGS_entry_vector(%rsp)=0A         movl  %eax,TRAPBOUNCE_er=
ror_code(%rdx)=0A         movq  TRAP_gp_fault * TRAPINFO_sizeof + =
TRAPINFO_eip(%rsi),%rax=0A@@ -302,7 +302,7 @@ UNLIKELY_END(sysenter_gpf)=0A=
 =0A ENTRY(int80_direct_trap)=0A         pushq $0=0A-        SAVE_ALL=0A+  =
      SAVE_VOLATILE 0x80=0A =0A         cmpb  $0,untrusted_msi(%rip)=0A =
UNLIKELY_START(ne, msi_check)=0A@@ -331,6 +331,7 @@ int80_slow_path:=0A    =
      * IDT entry with DPL=3D=3D0.=0A          */=0A         movl  $((0x80 =
<< 3) | 0x2),UREGS_error_code(%rsp)=0A+        SAVE_PRESERVED=0A         =
movl  $TRAP_gp_fault,UREGS_entry_vector(%rsp)=0A         /* A GPF wouldn't =
have incremented the instruction pointer. */=0A         subq  $2,UREGS_rip(=
%rsp)=0A@@ -412,7 +413,7 @@ UNLIKELY_END(bounce_failsafe)=0A         /* =
Rewrite our stack frame and return to guest-OS mode. */=0A         /* IA32 =
Ref. Vol. 3: TF, VM, RF and NT flags are cleared on trap. */=0A         /* =
Also clear AC: alignment checks shouldn't trigger in kernel mode. */=0A-   =
     movl  $TRAP_syscall,UREGS_entry_vector+8(%rsp)=0A+        orl   =
$TRAP_syscall,UREGS_entry_vector+8(%rsp)=0A         andl  $~(X86_EFLAGS_AC|=
X86_EFLAGS_VM|X86_EFLAGS_RF|\=0A                  X86_EFLAGS_NT|X86_EFLAGS_=
TF),UREGS_eflags+8(%rsp)=0A         movq  $FLAT_KERNEL_SS,UREGS_ss+8(%rsp)=
=0A@@ -477,7 +478,7 @@ handle_exception_saved:=0A         jz    exception_w=
ith_ints_disabled=0A         sti=0A 1:      movq  %rsp,%rdi=0A-        =
movl  UREGS_entry_vector(%rsp),%eax=0A+        movzbl UREGS_entry_vector(%r=
sp),%eax=0A         leaq  exception_table(%rip),%rdx=0A         GET_CURRENT=
(%rbx)=0A         PERFC_INCR(exceptions, %rax, %rbx)=0A@@ -518,7 +519,7 @@ =
exception_with_ints_disabled:=0A =0A /* No special register assumptions. =
*/=0A FATAL_exception_with_ints_disabled:=0A-        movl  UREGS_entry_vect=
or(%rsp),%edi=0A+        movzbl UREGS_entry_vector(%rsp),%edi=0A         =
movq  %rsp,%rsi=0A         call  fatal_trap=0A         ud2=0A@@ -624,7 =
+625,7 @@ handle_ist_exception:=0A         movq  %rdi,%rsp=0A         rep  =
 movsq=0A 1:      movq  %rsp,%rdi=0A-        movl  UREGS_entry_vector(%rsp)=
,%eax=0A+        movzbl UREGS_entry_vector(%rsp),%eax=0A         leaq  =
exception_table(%rip),%rdx=0A         callq *(%rdx,%rax,8)=0A         jmp  =
 ret_from_intr=0A--- a/xen/arch/x86/x86_64/traps.c=0A+++ b/xen/arch/x86/x86=
_64/traps.c=0A@@ -67,10 +67,15 @@ static void _show_registers(=0A          =
  regs->rbp, regs->rsp, regs->r8);=0A     printk("r9:  %016lx   r10: =
%016lx   r11: %016lx\n",=0A            regs->r9,  regs->r10, regs->r11);=0A=
-    printk("r12: %016lx   r13: %016lx   r14: %016lx\n",=0A-           =
regs->r12, regs->r13, regs->r14);=0A-    printk("r15: %016lx   cr0: %016lx =
  cr4: %016lx\n",=0A-           regs->r15, crs[0], crs[4]);=0A+    if ( =
!(regs->entry_vector & TRAP_regs_partial) )=0A+    {=0A+        printk("r12=
: %016lx   r13: %016lx   r14: %016lx\n",=0A+               regs->r12, =
regs->r13, regs->r14);=0A+        printk("r15: %016lx   cr0: %016lx   cr4: =
%016lx\n",=0A+               regs->r15, crs[0], crs[4]);=0A+    }=0A+    =
else=0A+        printk("cr0: %016lx   cr4: %016lx\n", crs[0], crs[4]);=0A  =
   printk("cr3: %016lx   cr2: %016lx\n", crs[3], crs[2]);=0A     printk("ds=
: %04x   es: %04x   fs: %04x   gs: %04x   "=0A            "ss: %04x   cs: =
%04x\n",=0A@@ -301,7 +306,7 @@ unsigned long do_iret(void)=0A =0A     if ( =
!(iret_saved.flags & VGCF_in_syscall) )=0A     {=0A-        regs->entry_vec=
tor =3D 0;=0A+        regs->entry_vector &=3D ~TRAP_syscall;=0A         =
regs->r11 =3D iret_saved.r11;=0A         regs->rcx =3D iret_saved.rcx;=0A  =
   }=0A--- a/xen/arch/x86/x86_emulate/x86_emulate.c=0A+++ b/xen/arch/x86/x8=
6_emulate/x86_emulate.c=0A@@ -1292,10 +1292,10 @@ decode_register(=0A     =
case  9: p =3D ®s->r9;  break;=0A     case 10: p =3D ®s->r10; =
break;=0A     case 11: p =3D ®s->r11; break;=0A-    case 12: p =3D =
®s->r12; break;=0A-    case 13: p =3D ®s->r13; break;=0A-    case =
14: p =3D ®s->r14; break;=0A-    case 15: p =3D ®s->r15; break;=0A+  =
  case 12: mark_regs_dirty(regs); p =3D ®s->r12; break;=0A+    case 13: =
mark_regs_dirty(regs); p =3D ®s->r13; break;=0A+    case 14: mark_regs_d=
irty(regs); p =3D ®s->r14; break;=0A+    case 15: mark_regs_dirty(regs);=
 p =3D ®s->r15; break;=0A #endif=0A     default: BUG(); p =3D NULL; =
break;=0A     }=0A--- a/xen/arch/x86/x86_emulate.c=0A+++ b/xen/arch/x86/x86=
_emulate.c=0A@@ -10,6 +10,7 @@=0A  */=0A =0A #include =
=0A+#include  /* mark_regs_dirty() */=0A #include =
 /* current_cpu_info */=0A #include  /* =
cpu_has_amd_erratum() */=0A =0A--- a/xen/common/wait.c=0A+++ b/xen/common/w=
ait.c=0A@@ -124,10 +124,12 @@ void wake_up_all(struct waitqueue_head *=0A =
=0A static void __prepare_to_wait(struct waitqueue_vcpu *wqv)=0A {=0A-    =
char *cpu_info =3D (char *)get_cpu_info();=0A+    struct cpu_info =
*cpu_info =3D get_cpu_info();=0A     struct vcpu *curr =3D current;=0A     =
unsigned long dummy;=0A+    u32 entry_vector =3D cpu_info->guest_cpu_user_r=
egs.entry_vector;=0A =0A+    cpu_info->guest_cpu_user_regs.entry_vector =
&=3D ~TRAP_regs_partial;=0A     ASSERT(wqv->esp =3D=3D 0);=0A =0A     /* =
Save current VCPU affinity; force wakeup on *this* CPU only. */=0A@@ =
-157,6 +159,8 @@ static void __prepare_to_wait(struct wai=0A         =
gdprintk(XENLOG_ERR, "Stack too large in %s\n", __FUNCTION__);=0A         =
domain_crash_synchronous();=0A     }=0A+=0A+    cpu_info->guest_cpu_user_re=
gs.entry_vector =3D entry_vector;=0A }=0A =0A static void __finish_wait(str=
uct waitqueue_vcpu *wqv)=0A--- a/xen/include/asm-x86/x86_64/asm_defns.h=0A+=
++ b/xen/include/asm-x86/x86_64/asm_defns.h=0A@@ -26,6 +26,31 @@=0A =
#define ASSERT_INTERRUPTS_ENABLED  ASSERT_INTERRUPT_STATUS(nz)=0A #define =
ASSERT_INTERRUPTS_DISABLED ASSERT_INTERRUPT_STATUS(z)=0A =0A+/*=0A+ * This =
flag is set in an exception frame when registers R12-R15 did not get=0A+ * =
saved.=0A+ */=0A+#define _TRAP_regs_partial 16=0A+#define TRAP_regs_partial=
  (1 << _TRAP_regs_partial)=0A+/*=0A+ * This flag gets set in an exception =
frame when registers R12-R15 possibly=0A+ * get modified from their =
originally saved values and hence need to be=0A+ * restored even if the =
normal call flow would restore register values.=0A+ *=0A+ * The flag being =
set implies _TRAP_regs_partial to be unset. Restoring=0A+ * R12-R15 thus =
is=0A+ * - required when this flag is set,=0A+ * - safe when _TRAP_regs_par=
tial is unset.=0A+ */=0A+#define _TRAP_regs_dirty   17=0A+#define =
TRAP_regs_dirty    (1 << _TRAP_regs_dirty)=0A+=0A+#define mark_regs_dirty(r=
) ({ \=0A+        struct cpu_user_regs *r__ =3D (r); \=0A+        =
ASSERT(!((r__)->entry_vector & TRAP_regs_partial)); \=0A+        r__->entry=
_vector |=3D TRAP_regs_dirty; \=0A+})=0A+=0A #define SAVE_ALL              =
                  \=0A         addq  $-(UREGS_error_code-UREGS_r15), %rsp; =
\=0A         cld;                                    \=0A@@ -47,11 +72,66 =
@@=0A         movq  %r15,UREGS_r15(%rsp);             \=0A =0A #ifdef =
__ASSEMBLY__=0A-.macro LOAD_C_CLOBBERED=0A+=0A+/*=0A+ * Save all registers =
not preserved by C code or used in entry/exit code. Mark=0A+ * the frame =
as partial.=0A+ *=0A+ * @type: exception type=0A+ * @compat: R8-R15 don't =
need saving, and the frame nevertheless is complete=0A+ */=0A+.macro =
SAVE_VOLATILE type compat=3D0=0A+.if \compat=0A+        movl  $\type,UREGS_=
entry_vector-UREGS_error_code(%rsp)=0A+.else=0A+        movl  $\type|TRAP_r=
egs_partial,\=0A+              UREGS_entry_vector-UREGS_error_code(%rsp)=0A=
+.endif=0A+        addq  $-(UREGS_error_code-UREGS_r15),%rsp=0A+        =
cld=0A+        movq  %rdi,UREGS_rdi(%rsp)=0A+        movq  %rsi,UREGS_rsi(%=
rsp)=0A+        movq  %rdx,UREGS_rdx(%rsp)=0A+        movq  %rcx,UREGS_rcx(=
%rsp)=0A+        movq  %rax,UREGS_rax(%rsp)=0A+.if !\compat=0A+        =
movq  %r8,UREGS_r8(%rsp)=0A+        movq  %r9,UREGS_r9(%rsp)=0A+        =
movq  %r10,UREGS_r10(%rsp)=0A+        movq  %r11,UREGS_r11(%rsp)=0A+.endif=
=0A+        movq  %rbx,UREGS_rbx(%rsp)=0A+        movq  %rbp,UREGS_rbp(%rsp=
)=0A+        SETUP_EXCEPTION_FRAME_POINTER(UREGS_rbp)=0A+.endm=0A+=0A+/*=0A=
+ * Complete a frame potentially only partially saved.=0A+ */=0A+.macro =
SAVE_PRESERVED=0A+        btrl  $_TRAP_regs_partial,UREGS_entry_vector(%rsp=
)=0A+        jnc   987f=0A+        movq  %r12,UREGS_r12(%rsp)=0A+        =
movq  %r13,UREGS_r13(%rsp)=0A+        movq  %r14,UREGS_r14(%rsp)=0A+       =
 movq  %r15,UREGS_r15(%rsp)=0A+987:=0A+.endm=0A+=0A+/*=0A+ * Reload =
registers not preserved by C code from frame.=0A+ *=0A+ * @compat: R8-R11 =
don't need reloading=0A+ *=0A+ * For the way it is used in RESTORE_ALL, =
this macro must preserve EFLAGS.ZF.=0A+ */=0A+.macro LOAD_C_CLOBBERED =
compat=3D0=0A+.if !\compat=0A         movq  UREGS_r11(%rsp),%r11=0A        =
 movq  UREGS_r10(%rsp),%r10=0A         movq  UREGS_r9(%rsp),%r9=0A         =
movq  UREGS_r8(%rsp),%r8=0A+.endif=0A         movq  UREGS_rax(%rsp),%rax=0A=
         movq  UREGS_rcx(%rsp),%rcx=0A         movq  UREGS_rdx(%rsp),%rdx=
=0A@@ -59,16 +139,45 @@=0A         movq  UREGS_rdi(%rsp),%rdi=0A .endm=0A =
=0A-.macro RESTORE_ALL adj=3D0=0A+/*=0A+ * Restore all previously saved =
registers.=0A+ *=0A+ * @adj: extra stack pointer adjustment to be folded =
into the adjustment done=0A+ *       anyway at the end of the macro=0A+ * =
@compat: R8-R15 don't need reloading=0A+ */=0A+.macro RESTORE_ALL adj=3D0 =
compat=3D0=0A+.if !\compat=0A+        testl $TRAP_regs_dirty,UREGS_entry_ve=
ctor(%rsp)=0A+.endif=0A+        LOAD_C_CLOBBERED \compat=0A+.if !\compat=0A=
+        jz    987f=0A         movq  UREGS_r15(%rsp),%r15=0A         movq  =
UREGS_r14(%rsp),%r14=0A         movq  UREGS_r13(%rsp),%r13=0A         movq =
 UREGS_r12(%rsp),%r12=0A-        movq  UREGS_rbp(%rsp),%rbp=0A+#ifndef =
NDEBUG=0A+        .subsection 1=0A+987:    testl $TRAP_regs_partial,UREGS_e=
ntry_vector(%rsp)=0A+        jnz   987f=0A+        cmpq  UREGS_r15(%rsp),%r=
15=0A+        jne   789f=0A+        cmpq  UREGS_r14(%rsp),%r14=0A+        =
jne   789f=0A+        cmpq  UREGS_r13(%rsp),%r13=0A+        jne   789f=0A+ =
       cmpq  UREGS_r12(%rsp),%r12=0A+        je    987f=0A+789:    ud2=0A+ =
       .subsection 0=0A+#endif=0A+.endif=0A+987:    movq  UREGS_rbp(%rsp),%=
rbp=0A         movq  UREGS_rbx(%rsp),%rbx=0A-        LOAD_C_CLOBBERED=0A   =
      subq  $-(UREGS_error_code-UREGS_r15+\adj), %rsp=0A .endm=0A+=0A =
#endif=0A =0A #ifdef PERF_COUNTERS=0A
--=__Part1726C544.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__Part1726C544.0__=--


From xen-devel-bounces@lists.xen.org Tue Oct 30 14:30:03 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 14:30:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTCoS-000477-TZ; Tue, 30 Oct 2012 14:29:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTCoQ-00046r-Rm
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 14:29:03 +0000
Received: from [85.158.143.99:32415] by server-3.bemta-4.messagelabs.com id
	56/F2-24279-E24EF805; Tue, 30 Oct 2012 14:29:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1351607341!21552839!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2957 invoked from network); 30 Oct 2012 14:29:01 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-216.messagelabs.com with SMTP;
	30 Oct 2012 14:29:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 30 Oct 2012 14:29:00 +0000
Message-Id: <508FF26402000078000A578A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 30 Oct 2012 14:29:40 +0000
From: "Jan Beulich" 
To: "xen-devel" 
References: <506B2268020000780009F273@nat28.tlf.novell.com>
	<508FF03702000078000A576D@nat28.tlf.novell.com>
In-Reply-To: <508FF03702000078000A576D@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part1726C544.0__="
Subject: [Xen-devel] [PATCH 2/2,
 v2] x86: save/restore only partial register state where possible
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part1726C544.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

... and make restore conditional not only upon having saved the state,
but also upon whether saved state was actually modified (and register
values are known to have been preserved).

Note that RBP is unconditionally considered a volatile register (i.e.
irrespective of CONFIG_FRAME_POINTER), since the RBP handling would
become overly complicated due to the need to save/restore it on the
compat mode hypercall path [6th argument].

Note further that for compat mode code paths, saving/restoring R8...R15
is entirely unnecessary - we don't allow those guests to enter 64-bit
mode, and hence they have no way of seeing these registers' contents
(and there consequently also is no information leak, except if the
context saving domctl would be considered such).

Finally, note that this may not properly deal with gdbstub's needs, yet
(but if so, I can't really suggest adjustments, as I don't know that
code).

Signed-off-by: Jan Beulich 
---
v2: Add a few comments.

This patch functionally depends on x86-drop-get_x86_gpr.patch.

--- a/tools/tests/x86_emulator/x86_emulate.c
+++ b/tools/tests/x86_emulator/x86_emulate.c
@@ -10,6 +10,7 @@ typedef bool bool_t;
 #define BUG() abort()
=20
 #define cpu_has_amd_erratum(nr) 0
+#define mark_regs_dirty(r) ((void)(r))
=20
 #include "x86_emulate/x86_emulate.h"
 #include "x86_emulate/x86_emulate.c"
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -143,6 +143,7 @@ static void continue_idle_domain(struct=20
 static void continue_nonidle_domain(struct vcpu *v)
 {
     check_wakeup_from_wait();
+    mark_regs_dirty(guest_cpu_user_regs());
     reset_stack_and_jump(ret_from_intr);
 }
=20
@@ -1312,7 +1313,7 @@ static void load_segments(struct vcpu *n
             if ( test_bit(_VGCF_failsafe_disables_events, &n->arch.vgc_fla=
gs) )
                 vcpu_info(n, evtchn_upcall_mask) =3D 1;
=20
-            regs->entry_vector  =3D TRAP_syscall;
+            regs->entry_vector |=3D TRAP_syscall;
             regs->_eflags      &=3D 0xFFFCBEFFUL;
             regs->ss            =3D FLAT_COMPAT_KERNEL_SS;
             regs->_esp          =3D (unsigned long)(esp-7);
@@ -1354,7 +1355,7 @@ static void load_segments(struct vcpu *n
         if ( test_bit(_VGCF_failsafe_disables_events, &n->arch.vgc_flags) =
)
             vcpu_info(n, evtchn_upcall_mask) =3D 1;
=20
-        regs->entry_vector  =3D TRAP_syscall;
+        regs->entry_vector |=3D TRAP_syscall;
         regs->rflags       &=3D ~(X86_EFLAGS_AC|X86_EFLAGS_VM|X86_EFLAGS_R=
F|
                                 X86_EFLAGS_NT|X86_EFLAGS_TF);
         regs->ss            =3D FLAT_KERNEL_SS;
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -704,7 +704,7 @@ void irq_complete_move(struct irq_desc *
     if (likely(!desc->arch.move_in_progress))
         return;
=20
-    vector =3D get_irq_regs()->entry_vector;
+    vector =3D (u8)get_irq_regs()->entry_vector;
     me =3D smp_processor_id();
=20
     if ( vector =3D=3D desc->arch.vector &&
@@ -798,7 +798,7 @@ void do_IRQ(struct cpu_user_regs *regs)
     struct irqaction *action;
     uint32_t          tsc_in;
     struct irq_desc  *desc;
-    unsigned int      vector =3D regs->entry_vector;
+    unsigned int      vector =3D (u8)regs->entry_vector;
     int irq =3D __get_cpu_var(vector_irq[vector]);
     struct cpu_user_regs *old_regs =3D set_irq_regs(regs);
    =20
@@ -892,7 +892,7 @@ void do_IRQ(struct cpu_user_regs *regs)
=20
  out:
     if ( desc->handler->end )
-        desc->handler->end(desc, regs->entry_vector);
+        desc->handler->end(desc, vector);
  out_no_end:
     spin_unlock(&desc->lock);
  out_no_unlock:
@@ -1113,7 +1113,7 @@ static void __do_IRQ_guest(int irq)
     struct domain      *d;
     int                 i, sp;
     struct pending_eoi *peoi =3D this_cpu(pending_eoi);
-    int vector =3D get_irq_regs()->entry_vector;
+    unsigned int        vector =3D (u8)get_irq_regs()->entry_vector;
=20
     if ( unlikely(action->nr_guests =3D=3D 0) )
     {
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -2082,6 +2082,7 @@ static int emulate_privileged_op(struct=20
             goto fail;
         if ( admin_io_okay(port, op_bytes, v, regs) )
         {
+            mark_regs_dirty(regs);
             io_emul(regs);           =20
         }
         else
@@ -2111,6 +2112,7 @@ static int emulate_privileged_op(struct=20
             goto fail;
         if ( admin_io_okay(port, op_bytes, v, regs) )
         {
+            mark_regs_dirty(regs);
             io_emul(regs);           =20
             if ( (op_bytes =3D=3D 1) && pv_post_outb_hook )
                 pv_post_outb_hook(port, regs->eax);
--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -14,8 +14,7 @@
=20
 ENTRY(compat_hypercall)
         pushq $0
-        movl  $TRAP_syscall,4(%rsp)
-        SAVE_ALL
+        SAVE_VOLATILE type=3DTRAP_syscall compat=3D1
=20
         cmpb  $0,untrusted_msi(%rip)
 UNLIKELY_START(ne, msi_check)
@@ -126,6 +125,7 @@ compat_test_guest_events:
 /* %rbx: struct vcpu */
 compat_process_softirqs:
         sti
+        andl  $~TRAP_regs_partial,UREGS_entry_vector(%rsp)
         call  do_softirq
         jmp   compat_test_all_events
=20
@@ -172,7 +172,7 @@ compat_bad_hypercall:
 /* %rbx: struct vcpu, interrupts disabled */
 compat_restore_all_guest:
         ASSERT_INTERRUPTS_DISABLED
-        RESTORE_ALL adj=3D8
+        RESTORE_ALL adj=3D8 compat=3D1
 .Lft0:  iretq
=20
 .section .fixup,"ax"
@@ -243,7 +243,7 @@ UNLIKELY_END(compat_syscall_gpf)
=20
 ENTRY(compat_sysenter)
         movq  VCPU_trap_ctxt(%rbx),%rcx
-        cmpl  $TRAP_gp_fault,UREGS_entry_vector(%rsp)
+        cmpb  $TRAP_gp_fault,UREGS_entry_vector(%rsp)
         movzwl VCPU_sysenter_sel(%rbx),%eax
         movzwl TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_cs(%rcx),%ecx
         cmovel %ecx,%eax
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -123,9 +123,8 @@ ENTRY(syscall_enter)
         movl  $FLAT_KERNEL_SS,24(%rsp)
         pushq %rcx
         pushq $0
-        movl  $TRAP_syscall,4(%rsp)
-        movq  24(%rsp),%r11 /* Re-load user RFLAGS into %r11 before =
SAVE_ALL */
-        SAVE_ALL
+        movq  24(%rsp),%r11 /* Re-load user RFLAGS into %r11 before =
saving */
+        SAVE_VOLATILE TRAP_syscall
         GET_CURRENT(%rbx)
         movq  VCPU_domain(%rbx),%rcx
         testb $1,DOMAIN_is_32bit_pv(%rcx)
@@ -222,6 +221,7 @@ test_guest_events:
 /* %rbx: struct vcpu */
 process_softirqs:
         sti      =20
+        SAVE_PRESERVED
         call do_softirq
         jmp  test_all_events
=20
@@ -275,8 +275,7 @@ sysenter_eflags_saved:
         pushq $3 /* ring 3 null cs */
         pushq $0 /* null rip */
         pushq $0
-        movl  $TRAP_syscall,4(%rsp)
-        SAVE_ALL
+        SAVE_VOLATILE TRAP_syscall
         GET_CURRENT(%rbx)
         cmpb  $0,VCPU_sysenter_disables_events(%rbx)
         movq  VCPU_sysenter_addr(%rbx),%rax
@@ -286,6 +285,7 @@ sysenter_eflags_saved:
         leal  (,%rcx,TBF_INTERRUPT),%ecx
 UNLIKELY_START(z, sysenter_gpf)
         movq  VCPU_trap_ctxt(%rbx),%rsi
+        SAVE_PRESERVED
         movl  $TRAP_gp_fault,UREGS_entry_vector(%rsp)
         movl  %eax,TRAPBOUNCE_error_code(%rdx)
         movq  TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_eip(%rsi),%rax
@@ -302,7 +302,7 @@ UNLIKELY_END(sysenter_gpf)
=20
 ENTRY(int80_direct_trap)
         pushq $0
-        SAVE_ALL
+        SAVE_VOLATILE 0x80
=20
         cmpb  $0,untrusted_msi(%rip)
 UNLIKELY_START(ne, msi_check)
@@ -331,6 +331,7 @@ int80_slow_path:
          * IDT entry with DPL=3D=3D0.
          */
         movl  $((0x80 << 3) | 0x2),UREGS_error_code(%rsp)
+        SAVE_PRESERVED
         movl  $TRAP_gp_fault,UREGS_entry_vector(%rsp)
         /* A GPF wouldn't have incremented the instruction pointer. */
         subq  $2,UREGS_rip(%rsp)
@@ -412,7 +413,7 @@ UNLIKELY_END(bounce_failsafe)
         /* Rewrite our stack frame and return to guest-OS mode. */
         /* IA32 Ref. Vol. 3: TF, VM, RF and NT flags are cleared on trap. =
*/
         /* Also clear AC: alignment checks shouldn't trigger in kernel =
mode. */
-        movl  $TRAP_syscall,UREGS_entry_vector+8(%rsp)
+        orl   $TRAP_syscall,UREGS_entry_vector+8(%rsp)
         andl  $~(X86_EFLAGS_AC|X86_EFLAGS_VM|X86_EFLAGS_RF|\
                  X86_EFLAGS_NT|X86_EFLAGS_TF),UREGS_eflags+8(%rsp)
         movq  $FLAT_KERNEL_SS,UREGS_ss+8(%rsp)
@@ -477,7 +478,7 @@ handle_exception_saved:
         jz    exception_with_ints_disabled
         sti
 1:      movq  %rsp,%rdi
-        movl  UREGS_entry_vector(%rsp),%eax
+        movzbl UREGS_entry_vector(%rsp),%eax
         leaq  exception_table(%rip),%rdx
         GET_CURRENT(%rbx)
         PERFC_INCR(exceptions, %rax, %rbx)
@@ -518,7 +519,7 @@ exception_with_ints_disabled:
=20
 /* No special register assumptions. */
 FATAL_exception_with_ints_disabled:
-        movl  UREGS_entry_vector(%rsp),%edi
+        movzbl UREGS_entry_vector(%rsp),%edi
         movq  %rsp,%rsi
         call  fatal_trap
         ud2
@@ -624,7 +625,7 @@ handle_ist_exception:
         movq  %rdi,%rsp
         rep   movsq
 1:      movq  %rsp,%rdi
-        movl  UREGS_entry_vector(%rsp),%eax
+        movzbl UREGS_entry_vector(%rsp),%eax
         leaq  exception_table(%rip),%rdx
         callq *(%rdx,%rax,8)
         jmp   ret_from_intr
--- a/xen/arch/x86/x86_64/traps.c
+++ b/xen/arch/x86/x86_64/traps.c
@@ -67,10 +67,15 @@ static void _show_registers(
            regs->rbp, regs->rsp, regs->r8);
     printk("r9:  %016lx   r10: %016lx   r11: %016lx\n",
            regs->r9,  regs->r10, regs->r11);
-    printk("r12: %016lx   r13: %016lx   r14: %016lx\n",
-           regs->r12, regs->r13, regs->r14);
-    printk("r15: %016lx   cr0: %016lx   cr4: %016lx\n",
-           regs->r15, crs[0], crs[4]);
+    if ( !(regs->entry_vector & TRAP_regs_partial) )
+    {
+        printk("r12: %016lx   r13: %016lx   r14: %016lx\n",
+               regs->r12, regs->r13, regs->r14);
+        printk("r15: %016lx   cr0: %016lx   cr4: %016lx\n",
+               regs->r15, crs[0], crs[4]);
+    }
+    else
+        printk("cr0: %016lx   cr4: %016lx\n", crs[0], crs[4]);
     printk("cr3: %016lx   cr2: %016lx\n", crs[3], crs[2]);
     printk("ds: %04x   es: %04x   fs: %04x   gs: %04x   "
            "ss: %04x   cs: %04x\n",
@@ -301,7 +306,7 @@ unsigned long do_iret(void)
=20
     if ( !(iret_saved.flags & VGCF_in_syscall) )
     {
-        regs->entry_vector =3D 0;
+        regs->entry_vector &=3D ~TRAP_syscall;
         regs->r11 =3D iret_saved.r11;
         regs->rcx =3D iret_saved.rcx;
     }
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1292,10 +1292,10 @@ decode_register(
     case  9: p =3D ®s->r9;  break;
     case 10: p =3D ®s->r10; break;
     case 11: p =3D ®s->r11; break;
-    case 12: p =3D ®s->r12; break;
-    case 13: p =3D ®s->r13; break;
-    case 14: p =3D ®s->r14; break;
-    case 15: p =3D ®s->r15; break;
+    case 12: mark_regs_dirty(regs); p =3D ®s->r12; break;
+    case 13: mark_regs_dirty(regs); p =3D ®s->r13; break;
+    case 14: mark_regs_dirty(regs); p =3D ®s->r14; break;
+    case 15: mark_regs_dirty(regs); p =3D ®s->r15; break;
 #endif
     default: BUG(); p =3D NULL; break;
     }
--- a/xen/arch/x86/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate.c
@@ -10,6 +10,7 @@
  */
=20
 #include 
+#include  /* mark_regs_dirty() */
 #include  /* current_cpu_info */
 #include  /* cpu_has_amd_erratum() */
=20
--- a/xen/common/wait.c
+++ b/xen/common/wait.c
@@ -124,10 +124,12 @@ void wake_up_all(struct waitqueue_head *
=20
 static void __prepare_to_wait(struct waitqueue_vcpu *wqv)
 {
-    char *cpu_info =3D (char *)get_cpu_info();
+    struct cpu_info *cpu_info =3D get_cpu_info();
     struct vcpu *curr =3D current;
     unsigned long dummy;
+    u32 entry_vector =3D cpu_info->guest_cpu_user_regs.entry_vector;
=20
+    cpu_info->guest_cpu_user_regs.entry_vector &=3D ~TRAP_regs_partial;
     ASSERT(wqv->esp =3D=3D 0);
=20
     /* Save current VCPU affinity; force wakeup on *this* CPU only. */
@@ -157,6 +159,8 @@ static void __prepare_to_wait(struct wai
         gdprintk(XENLOG_ERR, "Stack too large in %s\n", __FUNCTION__);
         domain_crash_synchronous();
     }
+
+    cpu_info->guest_cpu_user_regs.entry_vector =3D entry_vector;
 }
=20
 static void __finish_wait(struct waitqueue_vcpu *wqv)
--- a/xen/include/asm-x86/x86_64/asm_defns.h
+++ b/xen/include/asm-x86/x86_64/asm_defns.h
@@ -26,6 +26,31 @@
 #define ASSERT_INTERRUPTS_ENABLED  ASSERT_INTERRUPT_STATUS(nz)
 #define ASSERT_INTERRUPTS_DISABLED ASSERT_INTERRUPT_STATUS(z)
=20
+/*
+ * This flag is set in an exception frame when registers R12-R15 did not =
get
+ * saved.
+ */
+#define _TRAP_regs_partial 16
+#define TRAP_regs_partial  (1 << _TRAP_regs_partial)
+/*
+ * This flag gets set in an exception frame when registers R12-R15 =
possibly
+ * get modified from their originally saved values and hence need to be
+ * restored even if the normal call flow would restore register values.
+ *
+ * The flag being set implies _TRAP_regs_partial to be unset. Restoring
+ * R12-R15 thus is
+ * - required when this flag is set,
+ * - safe when _TRAP_regs_partial is unset.
+ */
+#define _TRAP_regs_dirty   17
+#define TRAP_regs_dirty    (1 << _TRAP_regs_dirty)
+
+#define mark_regs_dirty(r) ({ \
+        struct cpu_user_regs *r__ =3D (r); \
+        ASSERT(!((r__)->entry_vector & TRAP_regs_partial)); \
+        r__->entry_vector |=3D TRAP_regs_dirty; \
+})
+
 #define SAVE_ALL                                \
         addq  $-(UREGS_error_code-UREGS_r15), %rsp; \
         cld;                                    \
@@ -47,11 +72,66 @@
         movq  %r15,UREGS_r15(%rsp);             \
=20
 #ifdef __ASSEMBLY__
-.macro LOAD_C_CLOBBERED
+
+/*
+ * Save all registers not preserved by C code or used in entry/exit code. =
Mark
+ * the frame as partial.
+ *
+ * @type: exception type
+ * @compat: R8-R15 don't need saving, and the frame nevertheless is =
complete
+ */
+.macro SAVE_VOLATILE type compat=3D0
+.if \compat
+        movl  $\type,UREGS_entry_vector-UREGS_error_code(%rsp)
+.else
+        movl  $\type|TRAP_regs_partial,\
+              UREGS_entry_vector-UREGS_error_code(%rsp)
+.endif
+        addq  $-(UREGS_error_code-UREGS_r15),%rsp
+        cld
+        movq  %rdi,UREGS_rdi(%rsp)
+        movq  %rsi,UREGS_rsi(%rsp)
+        movq  %rdx,UREGS_rdx(%rsp)
+        movq  %rcx,UREGS_rcx(%rsp)
+        movq  %rax,UREGS_rax(%rsp)
+.if !\compat
+        movq  %r8,UREGS_r8(%rsp)
+        movq  %r9,UREGS_r9(%rsp)
+        movq  %r10,UREGS_r10(%rsp)
+        movq  %r11,UREGS_r11(%rsp)
+.endif
+        movq  %rbx,UREGS_rbx(%rsp)
+        movq  %rbp,UREGS_rbp(%rsp)
+        SETUP_EXCEPTION_FRAME_POINTER(UREGS_rbp)
+.endm
+
+/*
+ * Complete a frame potentially only partially saved.
+ */
+.macro SAVE_PRESERVED
+        btrl  $_TRAP_regs_partial,UREGS_entry_vector(%rsp)
+        jnc   987f
+        movq  %r12,UREGS_r12(%rsp)
+        movq  %r13,UREGS_r13(%rsp)
+        movq  %r14,UREGS_r14(%rsp)
+        movq  %r15,UREGS_r15(%rsp)
+987:
+.endm
+
+/*
+ * Reload registers not preserved by C code from frame.
+ *
+ * @compat: R8-R11 don't need reloading
+ *
+ * For the way it is used in RESTORE_ALL, this macro must preserve =
EFLAGS.ZF.
+ */
+.macro LOAD_C_CLOBBERED compat=3D0
+.if !\compat
         movq  UREGS_r11(%rsp),%r11
         movq  UREGS_r10(%rsp),%r10
         movq  UREGS_r9(%rsp),%r9
         movq  UREGS_r8(%rsp),%r8
+.endif
         movq  UREGS_rax(%rsp),%rax
         movq  UREGS_rcx(%rsp),%rcx
         movq  UREGS_rdx(%rsp),%rdx
@@ -59,16 +139,45 @@
         movq  UREGS_rdi(%rsp),%rdi
 .endm
=20
-.macro RESTORE_ALL adj=3D0
+/*
+ * Restore all previously saved registers.
+ *
+ * @adj: extra stack pointer adjustment to be folded into the adjustment =
done
+ *       anyway at the end of the macro
+ * @compat: R8-R15 don't need reloading
+ */
+.macro RESTORE_ALL adj=3D0 compat=3D0
+.if !\compat
+        testl $TRAP_regs_dirty,UREGS_entry_vector(%rsp)
+.endif
+        LOAD_C_CLOBBERED \compat
+.if !\compat
+        jz    987f
         movq  UREGS_r15(%rsp),%r15
         movq  UREGS_r14(%rsp),%r14
         movq  UREGS_r13(%rsp),%r13
         movq  UREGS_r12(%rsp),%r12
-        movq  UREGS_rbp(%rsp),%rbp
+#ifndef NDEBUG
+        .subsection 1
+987:    testl $TRAP_regs_partial,UREGS_entry_vector(%rsp)
+        jnz   987f
+        cmpq  UREGS_r15(%rsp),%r15
+        jne   789f
+        cmpq  UREGS_r14(%rsp),%r14
+        jne   789f
+        cmpq  UREGS_r13(%rsp),%r13
+        jne   789f
+        cmpq  UREGS_r12(%rsp),%r12
+        je    987f
+789:    ud2
+        .subsection 0
+#endif
+.endif
+987:    movq  UREGS_rbp(%rsp),%rbp
         movq  UREGS_rbx(%rsp),%rbx
-        LOAD_C_CLOBBERED
         subq  $-(UREGS_error_code-UREGS_r15+\adj), %rsp
 .endm
+
 #endif
=20
 #ifdef PERF_COUNTERS



--=__Part1726C544.0__=
Content-Type: text/plain; name="x86-save-restore-reduce.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-save-restore-reduce.patch"

x86: save/restore only partial register state where possible=0A=0A... and =
make restore conditional not only upon having saved the state,=0Abut also =
upon whether saved state was actually modified (and register=0Avalues are =
known to have been preserved).=0A=0ANote that RBP is unconditionally =
considered a volatile register (i.e.=0Airrespective of CONFIG_FRAME_POINTER=
), since the RBP handling would=0Abecome overly complicated due to the =
need to save/restore it on the=0Acompat mode hypercall path [6th argument].=
=0A=0ANote further that for compat mode code paths, saving/restoring =
R8...R15=0Ais entirely unnecessary - we don't allow those guests to enter =
64-bit=0Amode, and hence they have no way of seeing these registers' =
contents=0A(and there consequently also is no information leak, except if =
the=0Acontext saving domctl would be considered such).=0A=0AFinally, note =
that this may not properly deal with gdbstub's needs, yet=0A(but if so, I =
can't really suggest adjustments, as I don't know that=0Acode).=0A=0ASigned=
-off-by: Jan Beulich =0A---=0Av2: Add a few comments.=0A=
=0AThis patch functionally depends on x86-drop-get_x86_gpr.patch.=0A=0A--- =
a/tools/tests/x86_emulator/x86_emulate.c=0A+++ b/tools/tests/x86_emulator/x=
86_emulate.c=0A@@ -10,6 +10,7 @@ typedef bool bool_t;=0A #define BUG() =
abort()=0A =0A #define cpu_has_amd_erratum(nr) 0=0A+#define mark_regs_dirty=
(r) ((void)(r))=0A =0A #include "x86_emulate/x86_emulate.h"=0A #include =
"x86_emulate/x86_emulate.c"=0A--- a/xen/arch/x86/domain.c=0A+++ b/xen/arch/=
x86/domain.c=0A@@ -143,6 +143,7 @@ static void continue_idle_domain(struct =
=0A static void continue_nonidle_domain(struct vcpu *v)=0A {=0A     =
check_wakeup_from_wait();=0A+    mark_regs_dirty(guest_cpu_user_regs());=0A=
     reset_stack_and_jump(ret_from_intr);=0A }=0A =0A@@ -1312,7 +1313,7 @@ =
static void load_segments(struct vcpu *n=0A             if ( test_bit(_VGCF=
_failsafe_disables_events, &n->arch.vgc_flags) )=0A                 =
vcpu_info(n, evtchn_upcall_mask) =3D 1;=0A =0A-            regs->entry_vect=
or  =3D TRAP_syscall;=0A+            regs->entry_vector |=3D TRAP_syscall;=
=0A             regs->_eflags      &=3D 0xFFFCBEFFUL;=0A             =
regs->ss            =3D FLAT_COMPAT_KERNEL_SS;=0A             regs->_esp   =
       =3D (unsigned long)(esp-7);=0A@@ -1354,7 +1355,7 @@ static void =
load_segments(struct vcpu *n=0A         if ( test_bit(_VGCF_failsafe_disabl=
es_events, &n->arch.vgc_flags) )=0A             vcpu_info(n, evtchn_upcall_=
mask) =3D 1;=0A =0A-        regs->entry_vector  =3D TRAP_syscall;=0A+      =
  regs->entry_vector |=3D TRAP_syscall;=0A         regs->rflags       &=3D =
~(X86_EFLAGS_AC|X86_EFLAGS_VM|X86_EFLAGS_RF|=0A                            =
     X86_EFLAGS_NT|X86_EFLAGS_TF);=0A         regs->ss            =3D =
FLAT_KERNEL_SS;=0A--- a/xen/arch/x86/irq.c=0A+++ b/xen/arch/x86/irq.c=0A@@ =
-704,7 +704,7 @@ void irq_complete_move(struct irq_desc *=0A     if =
(likely(!desc->arch.move_in_progress))=0A         return;=0A =0A-    =
vector =3D get_irq_regs()->entry_vector;=0A+    vector =3D (u8)get_irq_regs=
()->entry_vector;=0A     me =3D smp_processor_id();=0A =0A     if ( vector =
=3D=3D desc->arch.vector &&=0A@@ -798,7 +798,7 @@ void do_IRQ(struct =
cpu_user_regs *regs)=0A     struct irqaction *action;=0A     uint32_t      =
    tsc_in;=0A     struct irq_desc  *desc;=0A-    unsigned int      vector =
=3D regs->entry_vector;=0A+    unsigned int      vector =3D (u8)regs->entry=
_vector;=0A     int irq =3D __get_cpu_var(vector_irq[vector]);=0A     =
struct cpu_user_regs *old_regs =3D set_irq_regs(regs);=0A     =0A@@ -892,7 =
+892,7 @@ void do_IRQ(struct cpu_user_regs *regs)=0A =0A  out:=0A     if ( =
desc->handler->end )=0A-        desc->handler->end(desc, regs->entry_vector=
);=0A+        desc->handler->end(desc, vector);=0A  out_no_end:=0A     =
spin_unlock(&desc->lock);=0A  out_no_unlock:=0A@@ -1113,7 +1113,7 @@ =
static void __do_IRQ_guest(int irq)=0A     struct domain      *d;=0A     =
int                 i, sp;=0A     struct pending_eoi *peoi =3D this_cpu(pen=
ding_eoi);=0A-    int vector =3D get_irq_regs()->entry_vector;=0A+    =
unsigned int        vector =3D (u8)get_irq_regs()->entry_vector;=0A =0A    =
 if ( unlikely(action->nr_guests =3D=3D 0) )=0A     {=0A--- a/xen/arch/x86/=
traps.c=0A+++ b/xen/arch/x86/traps.c=0A@@ -2082,6 +2082,7 @@ static int =
emulate_privileged_op(struct =0A             goto fail;=0A         if ( =
admin_io_okay(port, op_bytes, v, regs) )=0A         {=0A+            =
mark_regs_dirty(regs);=0A             io_emul(regs);            =0A        =
 }=0A         else=0A@@ -2111,6 +2112,7 @@ static int emulate_privileged_op=
(struct =0A             goto fail;=0A         if ( admin_io_okay(port, =
op_bytes, v, regs) )=0A         {=0A+            mark_regs_dirty(regs);=0A =
            io_emul(regs);            =0A             if ( (op_bytes =
=3D=3D 1) && pv_post_outb_hook )=0A                 pv_post_outb_hook(port,=
 regs->eax);=0A--- a/xen/arch/x86/x86_64/compat/entry.S=0A+++ b/xen/arch/x8=
6/x86_64/compat/entry.S=0A@@ -14,8 +14,7 @@=0A =0A ENTRY(compat_hypercall)=
=0A         pushq $0=0A-        movl  $TRAP_syscall,4(%rsp)=0A-        =
SAVE_ALL=0A+        SAVE_VOLATILE type=3DTRAP_syscall compat=3D1=0A =0A    =
     cmpb  $0,untrusted_msi(%rip)=0A UNLIKELY_START(ne, msi_check)=0A@@ =
-126,6 +125,7 @@ compat_test_guest_events:=0A /* %rbx: struct vcpu */=0A =
compat_process_softirqs:=0A         sti=0A+        andl  $~TRAP_regs_partia=
l,UREGS_entry_vector(%rsp)=0A         call  do_softirq=0A         jmp   =
compat_test_all_events=0A =0A@@ -172,7 +172,7 @@ compat_bad_hypercall:=0A =
/* %rbx: struct vcpu, interrupts disabled */=0A compat_restore_all_guest:=
=0A         ASSERT_INTERRUPTS_DISABLED=0A-        RESTORE_ALL adj=3D8=0A+  =
      RESTORE_ALL adj=3D8 compat=3D1=0A .Lft0:  iretq=0A =0A .section =
.fixup,"ax"=0A@@ -243,7 +243,7 @@ UNLIKELY_END(compat_syscall_gpf)=0A =0A =
ENTRY(compat_sysenter)=0A         movq  VCPU_trap_ctxt(%rbx),%rcx=0A-      =
  cmpl  $TRAP_gp_fault,UREGS_entry_vector(%rsp)=0A+        cmpb  $TRAP_gp_f=
ault,UREGS_entry_vector(%rsp)=0A         movzwl VCPU_sysenter_sel(%rbx),%ea=
x=0A         movzwl TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_cs(%rcx),%ec=
x=0A         cmovel %ecx,%eax=0A--- a/xen/arch/x86/x86_64/entry.S=0A+++ =
b/xen/arch/x86/x86_64/entry.S=0A@@ -123,9 +123,8 @@ ENTRY(syscall_enter)=0A=
         movl  $FLAT_KERNEL_SS,24(%rsp)=0A         pushq %rcx=0A         =
pushq $0=0A-        movl  $TRAP_syscall,4(%rsp)=0A-        movq  24(%rsp),%=
r11 /* Re-load user RFLAGS into %r11 before SAVE_ALL */=0A-        =
SAVE_ALL=0A+        movq  24(%rsp),%r11 /* Re-load user RFLAGS into %r11 =
before saving */=0A+        SAVE_VOLATILE TRAP_syscall=0A         =
GET_CURRENT(%rbx)=0A         movq  VCPU_domain(%rbx),%rcx=0A         testb =
$1,DOMAIN_is_32bit_pv(%rcx)=0A@@ -222,6 +221,7 @@ test_guest_events:=0A /* =
%rbx: struct vcpu */=0A process_softirqs:=0A         sti       =0A+        =
SAVE_PRESERVED=0A         call do_softirq=0A         jmp  test_all_events=
=0A =0A@@ -275,8 +275,7 @@ sysenter_eflags_saved:=0A         pushq $3 /* =
ring 3 null cs */=0A         pushq $0 /* null rip */=0A         pushq =
$0=0A-        movl  $TRAP_syscall,4(%rsp)=0A-        SAVE_ALL=0A+        =
SAVE_VOLATILE TRAP_syscall=0A         GET_CURRENT(%rbx)=0A         cmpb  =
$0,VCPU_sysenter_disables_events(%rbx)=0A         movq  VCPU_sysenter_addr(=
%rbx),%rax=0A@@ -286,6 +285,7 @@ sysenter_eflags_saved:=0A         leal  =
(,%rcx,TBF_INTERRUPT),%ecx=0A UNLIKELY_START(z, sysenter_gpf)=0A         =
movq  VCPU_trap_ctxt(%rbx),%rsi=0A+        SAVE_PRESERVED=0A         movl  =
$TRAP_gp_fault,UREGS_entry_vector(%rsp)=0A         movl  %eax,TRAPBOUNCE_er=
ror_code(%rdx)=0A         movq  TRAP_gp_fault * TRAPINFO_sizeof + =
TRAPINFO_eip(%rsi),%rax=0A@@ -302,7 +302,7 @@ UNLIKELY_END(sysenter_gpf)=0A=
 =0A ENTRY(int80_direct_trap)=0A         pushq $0=0A-        SAVE_ALL=0A+  =
      SAVE_VOLATILE 0x80=0A =0A         cmpb  $0,untrusted_msi(%rip)=0A =
UNLIKELY_START(ne, msi_check)=0A@@ -331,6 +331,7 @@ int80_slow_path:=0A    =
      * IDT entry with DPL=3D=3D0.=0A          */=0A         movl  $((0x80 =
<< 3) | 0x2),UREGS_error_code(%rsp)=0A+        SAVE_PRESERVED=0A         =
movl  $TRAP_gp_fault,UREGS_entry_vector(%rsp)=0A         /* A GPF wouldn't =
have incremented the instruction pointer. */=0A         subq  $2,UREGS_rip(=
%rsp)=0A@@ -412,7 +413,7 @@ UNLIKELY_END(bounce_failsafe)=0A         /* =
Rewrite our stack frame and return to guest-OS mode. */=0A         /* IA32 =
Ref. Vol. 3: TF, VM, RF and NT flags are cleared on trap. */=0A         /* =
Also clear AC: alignment checks shouldn't trigger in kernel mode. */=0A-   =
     movl  $TRAP_syscall,UREGS_entry_vector+8(%rsp)=0A+        orl   =
$TRAP_syscall,UREGS_entry_vector+8(%rsp)=0A         andl  $~(X86_EFLAGS_AC|=
X86_EFLAGS_VM|X86_EFLAGS_RF|\=0A                  X86_EFLAGS_NT|X86_EFLAGS_=
TF),UREGS_eflags+8(%rsp)=0A         movq  $FLAT_KERNEL_SS,UREGS_ss+8(%rsp)=
=0A@@ -477,7 +478,7 @@ handle_exception_saved:=0A         jz    exception_w=
ith_ints_disabled=0A         sti=0A 1:      movq  %rsp,%rdi=0A-        =
movl  UREGS_entry_vector(%rsp),%eax=0A+        movzbl UREGS_entry_vector(%r=
sp),%eax=0A         leaq  exception_table(%rip),%rdx=0A         GET_CURRENT=
(%rbx)=0A         PERFC_INCR(exceptions, %rax, %rbx)=0A@@ -518,7 +519,7 @@ =
exception_with_ints_disabled:=0A =0A /* No special register assumptions. =
*/=0A FATAL_exception_with_ints_disabled:=0A-        movl  UREGS_entry_vect=
or(%rsp),%edi=0A+        movzbl UREGS_entry_vector(%rsp),%edi=0A         =
movq  %rsp,%rsi=0A         call  fatal_trap=0A         ud2=0A@@ -624,7 =
+625,7 @@ handle_ist_exception:=0A         movq  %rdi,%rsp=0A         rep  =
 movsq=0A 1:      movq  %rsp,%rdi=0A-        movl  UREGS_entry_vector(%rsp)=
,%eax=0A+        movzbl UREGS_entry_vector(%rsp),%eax=0A         leaq  =
exception_table(%rip),%rdx=0A         callq *(%rdx,%rax,8)=0A         jmp  =
 ret_from_intr=0A--- a/xen/arch/x86/x86_64/traps.c=0A+++ b/xen/arch/x86/x86=
_64/traps.c=0A@@ -67,10 +67,15 @@ static void _show_registers(=0A          =
  regs->rbp, regs->rsp, regs->r8);=0A     printk("r9:  %016lx   r10: =
%016lx   r11: %016lx\n",=0A            regs->r9,  regs->r10, regs->r11);=0A=
-    printk("r12: %016lx   r13: %016lx   r14: %016lx\n",=0A-           =
regs->r12, regs->r13, regs->r14);=0A-    printk("r15: %016lx   cr0: %016lx =
  cr4: %016lx\n",=0A-           regs->r15, crs[0], crs[4]);=0A+    if ( =
!(regs->entry_vector & TRAP_regs_partial) )=0A+    {=0A+        printk("r12=
: %016lx   r13: %016lx   r14: %016lx\n",=0A+               regs->r12, =
regs->r13, regs->r14);=0A+        printk("r15: %016lx   cr0: %016lx   cr4: =
%016lx\n",=0A+               regs->r15, crs[0], crs[4]);=0A+    }=0A+    =
else=0A+        printk("cr0: %016lx   cr4: %016lx\n", crs[0], crs[4]);=0A  =
   printk("cr3: %016lx   cr2: %016lx\n", crs[3], crs[2]);=0A     printk("ds=
: %04x   es: %04x   fs: %04x   gs: %04x   "=0A            "ss: %04x   cs: =
%04x\n",=0A@@ -301,7 +306,7 @@ unsigned long do_iret(void)=0A =0A     if ( =
!(iret_saved.flags & VGCF_in_syscall) )=0A     {=0A-        regs->entry_vec=
tor =3D 0;=0A+        regs->entry_vector &=3D ~TRAP_syscall;=0A         =
regs->r11 =3D iret_saved.r11;=0A         regs->rcx =3D iret_saved.rcx;=0A  =
   }=0A--- a/xen/arch/x86/x86_emulate/x86_emulate.c=0A+++ b/xen/arch/x86/x8=
6_emulate/x86_emulate.c=0A@@ -1292,10 +1292,10 @@ decode_register(=0A     =
case  9: p =3D ®s->r9;  break;=0A     case 10: p =3D ®s->r10; =
break;=0A     case 11: p =3D ®s->r11; break;=0A-    case 12: p =3D =
®s->r12; break;=0A-    case 13: p =3D ®s->r13; break;=0A-    case =
14: p =3D ®s->r14; break;=0A-    case 15: p =3D ®s->r15; break;=0A+  =
  case 12: mark_regs_dirty(regs); p =3D ®s->r12; break;=0A+    case 13: =
mark_regs_dirty(regs); p =3D ®s->r13; break;=0A+    case 14: mark_regs_d=
irty(regs); p =3D ®s->r14; break;=0A+    case 15: mark_regs_dirty(regs);=
 p =3D ®s->r15; break;=0A #endif=0A     default: BUG(); p =3D NULL; =
break;=0A     }=0A--- a/xen/arch/x86/x86_emulate.c=0A+++ b/xen/arch/x86/x86=
_emulate.c=0A@@ -10,6 +10,7 @@=0A  */=0A =0A #include =
=0A+#include  /* mark_regs_dirty() */=0A #include =
 /* current_cpu_info */=0A #include  /* =
cpu_has_amd_erratum() */=0A =0A--- a/xen/common/wait.c=0A+++ b/xen/common/w=
ait.c=0A@@ -124,10 +124,12 @@ void wake_up_all(struct waitqueue_head *=0A =
=0A static void __prepare_to_wait(struct waitqueue_vcpu *wqv)=0A {=0A-    =
char *cpu_info =3D (char *)get_cpu_info();=0A+    struct cpu_info =
*cpu_info =3D get_cpu_info();=0A     struct vcpu *curr =3D current;=0A     =
unsigned long dummy;=0A+    u32 entry_vector =3D cpu_info->guest_cpu_user_r=
egs.entry_vector;=0A =0A+    cpu_info->guest_cpu_user_regs.entry_vector =
&=3D ~TRAP_regs_partial;=0A     ASSERT(wqv->esp =3D=3D 0);=0A =0A     /* =
Save current VCPU affinity; force wakeup on *this* CPU only. */=0A@@ =
-157,6 +159,8 @@ static void __prepare_to_wait(struct wai=0A         =
gdprintk(XENLOG_ERR, "Stack too large in %s\n", __FUNCTION__);=0A         =
domain_crash_synchronous();=0A     }=0A+=0A+    cpu_info->guest_cpu_user_re=
gs.entry_vector =3D entry_vector;=0A }=0A =0A static void __finish_wait(str=
uct waitqueue_vcpu *wqv)=0A--- a/xen/include/asm-x86/x86_64/asm_defns.h=0A+=
++ b/xen/include/asm-x86/x86_64/asm_defns.h=0A@@ -26,6 +26,31 @@=0A =
#define ASSERT_INTERRUPTS_ENABLED  ASSERT_INTERRUPT_STATUS(nz)=0A #define =
ASSERT_INTERRUPTS_DISABLED ASSERT_INTERRUPT_STATUS(z)=0A =0A+/*=0A+ * This =
flag is set in an exception frame when registers R12-R15 did not get=0A+ * =
saved.=0A+ */=0A+#define _TRAP_regs_partial 16=0A+#define TRAP_regs_partial=
  (1 << _TRAP_regs_partial)=0A+/*=0A+ * This flag gets set in an exception =
frame when registers R12-R15 possibly=0A+ * get modified from their =
originally saved values and hence need to be=0A+ * restored even if the =
normal call flow would restore register values.=0A+ *=0A+ * The flag being =
set implies _TRAP_regs_partial to be unset. Restoring=0A+ * R12-R15 thus =
is=0A+ * - required when this flag is set,=0A+ * - safe when _TRAP_regs_par=
tial is unset.=0A+ */=0A+#define _TRAP_regs_dirty   17=0A+#define =
TRAP_regs_dirty    (1 << _TRAP_regs_dirty)=0A+=0A+#define mark_regs_dirty(r=
) ({ \=0A+        struct cpu_user_regs *r__ =3D (r); \=0A+        =
ASSERT(!((r__)->entry_vector & TRAP_regs_partial)); \=0A+        r__->entry=
_vector |=3D TRAP_regs_dirty; \=0A+})=0A+=0A #define SAVE_ALL              =
                  \=0A         addq  $-(UREGS_error_code-UREGS_r15), %rsp; =
\=0A         cld;                                    \=0A@@ -47,11 +72,66 =
@@=0A         movq  %r15,UREGS_r15(%rsp);             \=0A =0A #ifdef =
__ASSEMBLY__=0A-.macro LOAD_C_CLOBBERED=0A+=0A+/*=0A+ * Save all registers =
not preserved by C code or used in entry/exit code. Mark=0A+ * the frame =
as partial.=0A+ *=0A+ * @type: exception type=0A+ * @compat: R8-R15 don't =
need saving, and the frame nevertheless is complete=0A+ */=0A+.macro =
SAVE_VOLATILE type compat=3D0=0A+.if \compat=0A+        movl  $\type,UREGS_=
entry_vector-UREGS_error_code(%rsp)=0A+.else=0A+        movl  $\type|TRAP_r=
egs_partial,\=0A+              UREGS_entry_vector-UREGS_error_code(%rsp)=0A=
+.endif=0A+        addq  $-(UREGS_error_code-UREGS_r15),%rsp=0A+        =
cld=0A+        movq  %rdi,UREGS_rdi(%rsp)=0A+        movq  %rsi,UREGS_rsi(%=
rsp)=0A+        movq  %rdx,UREGS_rdx(%rsp)=0A+        movq  %rcx,UREGS_rcx(=
%rsp)=0A+        movq  %rax,UREGS_rax(%rsp)=0A+.if !\compat=0A+        =
movq  %r8,UREGS_r8(%rsp)=0A+        movq  %r9,UREGS_r9(%rsp)=0A+        =
movq  %r10,UREGS_r10(%rsp)=0A+        movq  %r11,UREGS_r11(%rsp)=0A+.endif=
=0A+        movq  %rbx,UREGS_rbx(%rsp)=0A+        movq  %rbp,UREGS_rbp(%rsp=
)=0A+        SETUP_EXCEPTION_FRAME_POINTER(UREGS_rbp)=0A+.endm=0A+=0A+/*=0A=
+ * Complete a frame potentially only partially saved.=0A+ */=0A+.macro =
SAVE_PRESERVED=0A+        btrl  $_TRAP_regs_partial,UREGS_entry_vector(%rsp=
)=0A+        jnc   987f=0A+        movq  %r12,UREGS_r12(%rsp)=0A+        =
movq  %r13,UREGS_r13(%rsp)=0A+        movq  %r14,UREGS_r14(%rsp)=0A+       =
 movq  %r15,UREGS_r15(%rsp)=0A+987:=0A+.endm=0A+=0A+/*=0A+ * Reload =
registers not preserved by C code from frame.=0A+ *=0A+ * @compat: R8-R11 =
don't need reloading=0A+ *=0A+ * For the way it is used in RESTORE_ALL, =
this macro must preserve EFLAGS.ZF.=0A+ */=0A+.macro LOAD_C_CLOBBERED =
compat=3D0=0A+.if !\compat=0A         movq  UREGS_r11(%rsp),%r11=0A        =
 movq  UREGS_r10(%rsp),%r10=0A         movq  UREGS_r9(%rsp),%r9=0A         =
movq  UREGS_r8(%rsp),%r8=0A+.endif=0A         movq  UREGS_rax(%rsp),%rax=0A=
         movq  UREGS_rcx(%rsp),%rcx=0A         movq  UREGS_rdx(%rsp),%rdx=
=0A@@ -59,16 +139,45 @@=0A         movq  UREGS_rdi(%rsp),%rdi=0A .endm=0A =
=0A-.macro RESTORE_ALL adj=3D0=0A+/*=0A+ * Restore all previously saved =
registers.=0A+ *=0A+ * @adj: extra stack pointer adjustment to be folded =
into the adjustment done=0A+ *       anyway at the end of the macro=0A+ * =
@compat: R8-R15 don't need reloading=0A+ */=0A+.macro RESTORE_ALL adj=3D0 =
compat=3D0=0A+.if !\compat=0A+        testl $TRAP_regs_dirty,UREGS_entry_ve=
ctor(%rsp)=0A+.endif=0A+        LOAD_C_CLOBBERED \compat=0A+.if !\compat=0A=
+        jz    987f=0A         movq  UREGS_r15(%rsp),%r15=0A         movq  =
UREGS_r14(%rsp),%r14=0A         movq  UREGS_r13(%rsp),%r13=0A         movq =
 UREGS_r12(%rsp),%r12=0A-        movq  UREGS_rbp(%rsp),%rbp=0A+#ifndef =
NDEBUG=0A+        .subsection 1=0A+987:    testl $TRAP_regs_partial,UREGS_e=
ntry_vector(%rsp)=0A+        jnz   987f=0A+        cmpq  UREGS_r15(%rsp),%r=
15=0A+        jne   789f=0A+        cmpq  UREGS_r14(%rsp),%r14=0A+        =
jne   789f=0A+        cmpq  UREGS_r13(%rsp),%r13=0A+        jne   789f=0A+ =
       cmpq  UREGS_r12(%rsp),%r12=0A+        je    987f=0A+789:    ud2=0A+ =
       .subsection 0=0A+#endif=0A+.endif=0A+987:    movq  UREGS_rbp(%rsp),%=
rbp=0A         movq  UREGS_rbx(%rsp),%rbx=0A-        LOAD_C_CLOBBERED=0A   =
      subq  $-(UREGS_error_code-UREGS_r15+\adj), %rsp=0A .endm=0A+=0A =
#endif=0A =0A #ifdef PERF_COUNTERS=0A
--=__Part1726C544.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__Part1726C544.0__=--


From xen-devel-bounces@lists.xen.org Tue Oct 30 14:37:06 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 14:37:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTCvF-0004S3-2q; Tue, 30 Oct 2012 14:36:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTCvD-0004Rv-I5; Tue, 30 Oct 2012 14:36:03 +0000
Received: from [85.158.137.99:31942] by server-8.bemta-3.messagelabs.com id
	55/89-10525-2D5EF805; Tue, 30 Oct 2012 14:36:02 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-8.tower-217.messagelabs.com!1351607761!11670521!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27601 invoked from network); 30 Oct 2012 14:36:01 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-8.tower-217.messagelabs.com with SMTP;
	30 Oct 2012 14:36:01 -0000
Received: from [62.94.180.234] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 82745563; Tue, 30 Oct 2012 15:36:00 +0100
Message-ID: <1351607757.1346.32.camel@Abyss>
From: Dario Faggioli 
To: xen@lists.fedoraproject.org
Date: Tue, 30 Oct 2012 15:35:57 +0100
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
Mime-Version: 1.0
Cc: "xen-users@lists.xen.org" ,
	Konrad Rzeszutek Wilk ,
	M A Young , xen-devel 
Subject: [Xen-devel] Call for Participation to the Fedora Virt Test Day
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============6047506482080996640=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============6047506482080996640==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-zGtFt7JtK51ANB3tErmQ"


--=-zGtFt7JtK51ANB3tErmQ
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

As usual, the Fedora community has planned a number of Test Days for the
upcoming 18 release, including include a Virtualization Test Day on
November 1st (this Thursday):

  https://fedoraproject.org/wiki/Test_Day:2012-11-01_Virtualization

We are therefore calling all our community members to participate in the
test day as much as possible. Specific information regarding testing Xen
on Fedora can be found in this Wiki page:

  http://wiki.xen.org/wiki/Fedora_Test_Days

For participating, or just if attending, be sure you hang out on IRC at
#fedora-test-day (on Freenode) on Thursday !

Fedora 18 will be one of the first distros shipping Xen 4.2... So come
and help us making sure it will work great for all users !!

Thanks and Regards,
Dario
--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-zGtFt7JtK51ANB3tErmQ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlCP5c0ACgkQk4XaBE3IOsRlYwCgil8Rblm29C2kMnC70U5bn1JP
7dcAnAg/3ShuGpvTlQpalE3ZlPB1rKUi
=fZYK
-----END PGP SIGNATURE-----

--=-zGtFt7JtK51ANB3tErmQ--



--===============6047506482080996640==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6047506482080996640==--



From xen-devel-bounces@lists.xen.org Tue Oct 30 14:37:06 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 14:37:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTCvF-0004S3-2q; Tue, 30 Oct 2012 14:36:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTCvD-0004Rv-I5; Tue, 30 Oct 2012 14:36:03 +0000
Received: from [85.158.137.99:31942] by server-8.bemta-3.messagelabs.com id
	55/89-10525-2D5EF805; Tue, 30 Oct 2012 14:36:02 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-8.tower-217.messagelabs.com!1351607761!11670521!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27601 invoked from network); 30 Oct 2012 14:36:01 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-8.tower-217.messagelabs.com with SMTP;
	30 Oct 2012 14:36:01 -0000
Received: from [62.94.180.234] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 82745563; Tue, 30 Oct 2012 15:36:00 +0100
Message-ID: <1351607757.1346.32.camel@Abyss>
From: Dario Faggioli 
To: xen@lists.fedoraproject.org
Date: Tue, 30 Oct 2012 15:35:57 +0100
X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) 
Mime-Version: 1.0
Cc: "xen-users@lists.xen.org" ,
	Konrad Rzeszutek Wilk ,
	M A Young , xen-devel 
Subject: [Xen-devel] Call for Participation to the Fedora Virt Test Day
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============6047506482080996640=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============6047506482080996640==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-zGtFt7JtK51ANB3tErmQ"


--=-zGtFt7JtK51ANB3tErmQ
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

As usual, the Fedora community has planned a number of Test Days for the
upcoming 18 release, including include a Virtualization Test Day on
November 1st (this Thursday):

  https://fedoraproject.org/wiki/Test_Day:2012-11-01_Virtualization

We are therefore calling all our community members to participate in the
test day as much as possible. Specific information regarding testing Xen
on Fedora can be found in this Wiki page:

  http://wiki.xen.org/wiki/Fedora_Test_Days

For participating, or just if attending, be sure you hang out on IRC at
#fedora-test-day (on Freenode) on Thursday !

Fedora 18 will be one of the first distros shipping Xen 4.2... So come
and help us making sure it will work great for all users !!

Thanks and Regards,
Dario
--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-zGtFt7JtK51ANB3tErmQ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlCP5c0ACgkQk4XaBE3IOsRlYwCgil8Rblm29C2kMnC70U5bn1JP
7dcAnAg/3ShuGpvTlQpalE3ZlPB1rKUi
=fZYK
-----END PGP SIGNATURE-----

--=-zGtFt7JtK51ANB3tErmQ--



--===============6047506482080996640==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6047506482080996640==--



From xen-devel-bounces@lists.xen.org Tue Oct 30 14:53:53 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 14:53:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTDC7-000528-1x; Tue, 30 Oct 2012 14:53:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTDC5-000523-6y
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 14:53:29 +0000
Received: from [85.158.139.83:56984] by server-16.bemta-5.messagelabs.com id
	E3/15-04786-8E9EF805; Tue, 30 Oct 2012 14:53:28 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-16.tower-182.messagelabs.com!1351608805!20633352!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_30_40,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17875 invoked from network); 30 Oct 2012 14:53:27 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 14:53:27 -0000
Received: by mail-ie0-f173.google.com with SMTP id 17so645475iea.32
	for ; Tue, 30 Oct 2012 07:53:25 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=content-type:mime-version:subject:from:in-reply-to:date:cc
	:message-id:references:to:x-mailer:x-gm-message-state;
	bh=I3BpHKzT+AJHeuybv+iGJpoIhFA5mHRS4vfZd9LMaNU=;
	b=EjstoaTsUoS6+pKd7odxyuWbXm46yzFECWqdQlPaEtdKbH0XITnJ9Z5aKk+F660Met
	9+jn4jeYJRkNKQHOdvLYm+o2CrjKLXBvFumZfAh/Kr7cDmii8ZDdrqsnTOPS6bG9fQSj
	DJOxtjcVdOKyuYNkEkpGHXcRMz4zMtm6B9weGVQELt2ZWZDzZAXeV091p8Sk/6Uyl//h
	48cB+gPc4OQFHpccnL3AtBRZ+P4/lERCM0WnjR/4rF6sLeAbujexsKncnfNE1d2hHhwX
	vpC9ebvtwj39uSX1+WC7QerIiB5fWDEpyH9KAIVLrinfTclpV9ncuVijtJ2qwJZiQc+D
	FyMA==
Received: by 10.50.53.199 with SMTP id d7mr1720466igp.47.1351608805579;
	Tue, 30 Oct 2012 07:53:25 -0700 (PDT)
Received: from andress-macbook.gridcentric.ca ([206.223.182.18])
	by mx.google.com with ESMTPS id kp4sm674470igc.1.2012.10.30.07.53.22
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 30 Oct 2012 07:53:24 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Andres Lagar-Cavilla 
In-Reply-To: <20121030093626.GB34613@ocelot.phlegethon.org>
Date: Tue, 30 Oct 2012 10:53:21 -0400
Message-Id: <4E449D48-D643-46FB-91BD-B15EF21AAC57@gridcentric.ca>
References: <508FAA9402000078000A5612@nat28.tlf.novell.com>
	<20121030093626.GB34613@ocelot.phlegethon.org>
To: Tim Deegan 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQmZv7GVJM/35pKf8oLxMMQ1DhT8BeiJ5wdoqHaKWxnxp4xH6D4IQc9ZSP1ZbZEO9B4KKr1G
Cc: Andres Lagar-Cavilla ,
	Jan Beulich , xen-devel 
Subject: Re: [Xen-devel] get_gfn_query() locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============7676518462468636594=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============7676518462468636594==
Content-Type: multipart/alternative; boundary="Apple-Mail=_F5B0FDD1-A558-4022-ADD5-5A57EE9F27D1"


--Apple-Mail=_F5B0FDD1-A558-4022-ADD5-5A57EE9F27D1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

On Oct 30, 2012, at 5:36 AM, Tim Deegan  wrote:

> At 09:23 +0000 on 30 Oct (1351588996), Jan Beulich wrote:
>> while looking at how "X86/vMCE: handle broken page occurred
>> before migration" uses the p2m code, I wondered whether the
>> comment
>>=20
>> * N.B. get_gfn_query() is the _only_ one guaranteed not to take the
>> * p2m lock; none of the others can be called with the p2m or paging
>> * lock held. */
>>=20
>> isn't stale=20
>=20
> Yes, it seems to be stale.  I think that even with the originally
> proposed fine-grained p2m locking it would have been possible for this
> to take the p2m lock. :(

Stale comment indeed.
>=20
>> - afaict with get_gfn_type_access() passing "1" for the
>> "locked" parameter of __get_gfn_type_access(), there's no way
>> to avoid the locking without using __get_gfn_type_access()
>> directly.
>=20
> get_gfn_query_unlocked() is the way to do lookups without the lock, =
but
> of course if you do that then you've no guarantee that the mfn it
> returns won't get freed under your feet.

get_gfn_query_unlocked() is really only meant for debugging, domain is =
toast, etc. As Tim says, no guarantee that you are getting a live mfn =
and/or p2m type.

Having said that, we have a big XOR for domains that use IOMMU -- no =
paging or sharing. =46rom an mm p.o.v. they are fairly vanilla domains =
and under most circumstances one could perform unlocked queries. Still =
there are dangerous situations in which a p2m entry might change. I do =
not think we have an interlock in place for PoD, and if the domain were =
to run a balloon driver you'd have to trouble.

I say this because a similar interlock may apply for vMCE? Is there an =
expectation for a domain with vMCE turned on to be "land-locked" =
memory-wise?
>=20
>> And then again, with the p2m lock being recursive these
>> days, I don't think there's any harm calling the other methods
>> here with that lock held.

Is the patch you refer to =
http://www.gossamer-threads.com/lists/xen/devel/261025 and the hunk in =
question the following?
+ get_gfn_query(d, pfn, &pt);=20
+ p2m_change_type(d, pfn, pt, p2m_ram_broken);=20
+ put_gfn(d, pfn);=20

There really is no way to get rid of that p2m lock-protected critical =
section if the domain allows for paging etc. You might want to introduce =
a syntactically cleaner unconditional p2m_change_type variant that =
doesn't cmpxchg with the previous type -- that is effectively what goes =
on here. Should be a tiny amount of refactoring and the code will be =
cleaner, no need for query or put.

>=20
> True, but it wouldn't be safe to call it with the paging lock held.
> OTOH since we're not seeing any crashes from the lock-ordering
> constraints maybe we don't do that.
>=20
> Andres, what do you think?  Can we just drop/amend that comment?
>=20

If you refer to removing the ordering constraints, my opinion is to NACK =
that. I think once you remove the ordering constraints it's only a =
matter of time before deadlock-inducing code creeps in. These mm locks =
are loads of fun to get right (that kind of fun). The constraints ensure =
that any developer new to the mm code will get straightened out =
immediately.

Note that the ordering constraints allow you to, beyond recursively =
taking the p2m lock, to take p2m -> paging -> p2m locks. But they does =
*not* allow you to do get_page_from_gfn -> paging lock -> p2m lock.

Obviously we need more documentation in the .h files. I'll get to that =
next week. Jan, ping me if I haven't submitted something to the 4.2.1 =
tree by the close.

> Tim.


--Apple-Mail=_F5B0FDD1-A558-4022-ADD5-5A57EE9F27D1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

tim@xen.org> wrote:

At 09:23 =
+0000 on 30 Oct (1351588996), Jan Beulich wrote:
while looking at how "X86/vMCE: handle broken page =
occurred
before migration" uses the p2m code, I wondered whether =
the
comment

 * N.B. get_gfn_query() is the _only_ one =
guaranteed not to take the
 * p2m lock; none of the others can be =
called with the p2m or paging
 * lock held. */

isn't stale =


Yes, it seems to be stale.  I think that even =
with the originally
proposed fine-grained p2m locking it would have =
been possible for this
to take the p2m lock. =
:(

Stale comment indeed.

- afaict with =
get_gfn_type_access() passing "1" for the
"locked" parameter of =
__get_gfn_type_access(), there's no way
to avoid the locking without =
using =
__get_gfn_type_access()
directly.

get_gfn_query_unl=
ocked() is the way to do lookups without the lock, but
of course if =
you do that then you've no guarantee that the mfn it
returns won't =
get freed under your =
feet.

get_gfn_query_unlocked() is really =
only meant for debugging, domain is toast, etc. As Tim says, no =
guarantee that you are getting a live mfn and/or p2m =
type.

Having said that, we have a big XOR for =
domains that use IOMMU -- no paging or sharing. =46rom an mm p.o.v. they =
are fairly vanilla domains and under most circumstances one could =
perform unlocked queries. Still there are dangerous situations in which =
a p2m entry might change. I do not think we have an interlock in place =
for PoD, and if the domain were to run a balloon driver you'd have to =
trouble.

I say this because a similar interlock =
may apply for vMCE? Is there an expectation for a domain with vMCE =
turned on to be "land-locked" memory-wise?

And then again, with the p2m =
lock being recursive these
days, I don't think there's any harm =
calling the other methods
here with that lock =
held.

Is the patch you refer =
to http://www=
.gossamer-threads.com/lists/xen/devel/261025 and the hunk in =
question the following?
+ get_gfn_query(d, pfn, &pt); 
+ p2m_change_type(d, pfn, pt, =
p2m_ram_broken); 
+ put_gfn(d, =
pfn); 

There really is no way to get rid of =
that p2m lock-protected critical section if the domain allows for paging =
etc. You might want to introduce a syntactically cleaner unconditional =
p2m_change_type variant that doesn't cmpxchg with the previous type -- =
that is effectively what goes on here. Should be a tiny amount of =
refactoring and the code will be cleaner, no need for query or =
put.


True, but it =
wouldn't be safe to call it with the paging lock held.
OTOH since =
we're not seeing any crashes from the lock-ordering
constraints maybe =
we don't do that.

Andres, what =
do you think?  Can we just drop/amend that =
comment?


If you refer to removing the =
ordering constraints, my opinion is to NACK that. I think once you =
remove the ordering constraints it's only a matter of time before =
deadlock-inducing code creeps in. These mm locks are loads of fun to get =
right (that kind of fun). The constraints ensure that any developer new =
to the mm code will get straightened out =
immediately.

Note that the ordering constraints =
allow you to, beyond recursively taking the p2m lock, to take p2m -> =
paging -> p2m locks. But they does *not* allow you to do =
get_page_from_gfn -> paging lock -> p2m =
lock.

Obviously we need more documentation in =
the .h files. I'll get to that next week. Jan, ping me if I haven't =
submitted something to the 4.2.1 tree by the =
close.

Tim.

=

--Apple-Mail=_F5B0FDD1-A558-4022-ADD5-5A57EE9F27D1--


--===============7676518462468636594==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7676518462468636594==--


From xen-devel-bounces@lists.xen.org Tue Oct 30 14:53:53 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 14:53:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTDC7-000528-1x; Tue, 30 Oct 2012 14:53:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTDC5-000523-6y
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 14:53:29 +0000
Received: from [85.158.139.83:56984] by server-16.bemta-5.messagelabs.com id
	E3/15-04786-8E9EF805; Tue, 30 Oct 2012 14:53:28 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-16.tower-182.messagelabs.com!1351608805!20633352!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_30_40,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17875 invoked from network); 30 Oct 2012 14:53:27 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 14:53:27 -0000
Received: by mail-ie0-f173.google.com with SMTP id 17so645475iea.32
	for ; Tue, 30 Oct 2012 07:53:25 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=content-type:mime-version:subject:from:in-reply-to:date:cc
	:message-id:references:to:x-mailer:x-gm-message-state;
	bh=I3BpHKzT+AJHeuybv+iGJpoIhFA5mHRS4vfZd9LMaNU=;
	b=EjstoaTsUoS6+pKd7odxyuWbXm46yzFECWqdQlPaEtdKbH0XITnJ9Z5aKk+F660Met
	9+jn4jeYJRkNKQHOdvLYm+o2CrjKLXBvFumZfAh/Kr7cDmii8ZDdrqsnTOPS6bG9fQSj
	DJOxtjcVdOKyuYNkEkpGHXcRMz4zMtm6B9weGVQELt2ZWZDzZAXeV091p8Sk/6Uyl//h
	48cB+gPc4OQFHpccnL3AtBRZ+P4/lERCM0WnjR/4rF6sLeAbujexsKncnfNE1d2hHhwX
	vpC9ebvtwj39uSX1+WC7QerIiB5fWDEpyH9KAIVLrinfTclpV9ncuVijtJ2qwJZiQc+D
	FyMA==
Received: by 10.50.53.199 with SMTP id d7mr1720466igp.47.1351608805579;
	Tue, 30 Oct 2012 07:53:25 -0700 (PDT)
Received: from andress-macbook.gridcentric.ca ([206.223.182.18])
	by mx.google.com with ESMTPS id kp4sm674470igc.1.2012.10.30.07.53.22
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 30 Oct 2012 07:53:24 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Andres Lagar-Cavilla 
In-Reply-To: <20121030093626.GB34613@ocelot.phlegethon.org>
Date: Tue, 30 Oct 2012 10:53:21 -0400
Message-Id: <4E449D48-D643-46FB-91BD-B15EF21AAC57@gridcentric.ca>
References: <508FAA9402000078000A5612@nat28.tlf.novell.com>
	<20121030093626.GB34613@ocelot.phlegethon.org>
To: Tim Deegan 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQmZv7GVJM/35pKf8oLxMMQ1DhT8BeiJ5wdoqHaKWxnxp4xH6D4IQc9ZSP1ZbZEO9B4KKr1G
Cc: Andres Lagar-Cavilla ,
	Jan Beulich , xen-devel 
Subject: Re: [Xen-devel] get_gfn_query() locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============7676518462468636594=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============7676518462468636594==
Content-Type: multipart/alternative; boundary="Apple-Mail=_F5B0FDD1-A558-4022-ADD5-5A57EE9F27D1"


--Apple-Mail=_F5B0FDD1-A558-4022-ADD5-5A57EE9F27D1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

On Oct 30, 2012, at 5:36 AM, Tim Deegan  wrote:

> At 09:23 +0000 on 30 Oct (1351588996), Jan Beulich wrote:
>> while looking at how "X86/vMCE: handle broken page occurred
>> before migration" uses the p2m code, I wondered whether the
>> comment
>>=20
>> * N.B. get_gfn_query() is the _only_ one guaranteed not to take the
>> * p2m lock; none of the others can be called with the p2m or paging
>> * lock held. */
>>=20
>> isn't stale=20
>=20
> Yes, it seems to be stale.  I think that even with the originally
> proposed fine-grained p2m locking it would have been possible for this
> to take the p2m lock. :(

Stale comment indeed.
>=20
>> - afaict with get_gfn_type_access() passing "1" for the
>> "locked" parameter of __get_gfn_type_access(), there's no way
>> to avoid the locking without using __get_gfn_type_access()
>> directly.
>=20
> get_gfn_query_unlocked() is the way to do lookups without the lock, =
but
> of course if you do that then you've no guarantee that the mfn it
> returns won't get freed under your feet.

get_gfn_query_unlocked() is really only meant for debugging, domain is =
toast, etc. As Tim says, no guarantee that you are getting a live mfn =
and/or p2m type.

Having said that, we have a big XOR for domains that use IOMMU -- no =
paging or sharing. =46rom an mm p.o.v. they are fairly vanilla domains =
and under most circumstances one could perform unlocked queries. Still =
there are dangerous situations in which a p2m entry might change. I do =
not think we have an interlock in place for PoD, and if the domain were =
to run a balloon driver you'd have to trouble.

I say this because a similar interlock may apply for vMCE? Is there an =
expectation for a domain with vMCE turned on to be "land-locked" =
memory-wise?
>=20
>> And then again, with the p2m lock being recursive these
>> days, I don't think there's any harm calling the other methods
>> here with that lock held.

Is the patch you refer to =
http://www.gossamer-threads.com/lists/xen/devel/261025 and the hunk in =
question the following?
+ get_gfn_query(d, pfn, &pt);=20
+ p2m_change_type(d, pfn, pt, p2m_ram_broken);=20
+ put_gfn(d, pfn);=20

There really is no way to get rid of that p2m lock-protected critical =
section if the domain allows for paging etc. You might want to introduce =
a syntactically cleaner unconditional p2m_change_type variant that =
doesn't cmpxchg with the previous type -- that is effectively what goes =
on here. Should be a tiny amount of refactoring and the code will be =
cleaner, no need for query or put.

>=20
> True, but it wouldn't be safe to call it with the paging lock held.
> OTOH since we're not seeing any crashes from the lock-ordering
> constraints maybe we don't do that.
>=20
> Andres, what do you think?  Can we just drop/amend that comment?
>=20

If you refer to removing the ordering constraints, my opinion is to NACK =
that. I think once you remove the ordering constraints it's only a =
matter of time before deadlock-inducing code creeps in. These mm locks =
are loads of fun to get right (that kind of fun). The constraints ensure =
that any developer new to the mm code will get straightened out =
immediately.

Note that the ordering constraints allow you to, beyond recursively =
taking the p2m lock, to take p2m -> paging -> p2m locks. But they does =
*not* allow you to do get_page_from_gfn -> paging lock -> p2m lock.

Obviously we need more documentation in the .h files. I'll get to that =
next week. Jan, ping me if I haven't submitted something to the 4.2.1 =
tree by the close.

> Tim.


--Apple-Mail=_F5B0FDD1-A558-4022-ADD5-5A57EE9F27D1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

tim@xen.org> wrote:

At 09:23 =
+0000 on 30 Oct (1351588996), Jan Beulich wrote:
while looking at how "X86/vMCE: handle broken page =
occurred
before migration" uses the p2m code, I wondered whether =
the
comment

 * N.B. get_gfn_query() is the _only_ one =
guaranteed not to take the
 * p2m lock; none of the others can be =
called with the p2m or paging
 * lock held. */

isn't stale =


Yes, it seems to be stale.  I think that even =
with the originally
proposed fine-grained p2m locking it would have =
been possible for this
to take the p2m lock. =
:(

Stale comment indeed.

- afaict with =
get_gfn_type_access() passing "1" for the
"locked" parameter of =
__get_gfn_type_access(), there's no way
to avoid the locking without =
using =
__get_gfn_type_access()
directly.

get_gfn_query_unl=
ocked() is the way to do lookups without the lock, but
of course if =
you do that then you've no guarantee that the mfn it
returns won't =
get freed under your =
feet.

get_gfn_query_unlocked() is really =
only meant for debugging, domain is toast, etc. As Tim says, no =
guarantee that you are getting a live mfn and/or p2m =
type.

Having said that, we have a big XOR for =
domains that use IOMMU -- no paging or sharing. =46rom an mm p.o.v. they =
are fairly vanilla domains and under most circumstances one could =
perform unlocked queries. Still there are dangerous situations in which =
a p2m entry might change. I do not think we have an interlock in place =
for PoD, and if the domain were to run a balloon driver you'd have to =
trouble.

I say this because a similar interlock =
may apply for vMCE? Is there an expectation for a domain with vMCE =
turned on to be "land-locked" memory-wise?

And then again, with the p2m =
lock being recursive these
days, I don't think there's any harm =
calling the other methods
here with that lock =
held.

Is the patch you refer =
to http://www=
.gossamer-threads.com/lists/xen/devel/261025 and the hunk in =
question the following?
+ get_gfn_query(d, pfn, &pt); 
+ p2m_change_type(d, pfn, pt, =
p2m_ram_broken); 
+ put_gfn(d, =
pfn); 

There really is no way to get rid of =
that p2m lock-protected critical section if the domain allows for paging =
etc. You might want to introduce a syntactically cleaner unconditional =
p2m_change_type variant that doesn't cmpxchg with the previous type -- =
that is effectively what goes on here. Should be a tiny amount of =
refactoring and the code will be cleaner, no need for query or =
put.


True, but it =
wouldn't be safe to call it with the paging lock held.
OTOH since =
we're not seeing any crashes from the lock-ordering
constraints maybe =
we don't do that.

Andres, what =
do you think?  Can we just drop/amend that =
comment?


If you refer to removing the =
ordering constraints, my opinion is to NACK that. I think once you =
remove the ordering constraints it's only a matter of time before =
deadlock-inducing code creeps in. These mm locks are loads of fun to get =
right (that kind of fun). The constraints ensure that any developer new =
to the mm code will get straightened out =
immediately.

Note that the ordering constraints =
allow you to, beyond recursively taking the p2m lock, to take p2m -> =
paging -> p2m locks. But they does *not* allow you to do =
get_page_from_gfn -> paging lock -> p2m =
lock.

Obviously we need more documentation in =
the .h files. I'll get to that next week. Jan, ping me if I haven't =
submitted something to the 4.2.1 tree by the =
close.

Tim.

=

--Apple-Mail=_F5B0FDD1-A558-4022-ADD5-5A57EE9F27D1--


--===============7676518462468636594==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7676518462468636594==--


From xen-devel-bounces@lists.xen.org Tue Oct 30 14:54:40 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 14:54:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTDCY-00053P-Fm; Tue, 30 Oct 2012 14:53:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTDCW-00053A-Uh
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 14:53:57 +0000
Received: from [85.158.139.83:25326] by server-10.bemta-5.messagelabs.com id
	E4/2D-01025-40AEF805; Tue, 30 Oct 2012 14:53:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1351608835!16704931!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23311 invoked from network); 30 Oct 2012 14:53:55 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 14:53:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="15492016"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 14:53:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 30 Oct 2012 14:53:54 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TTDCU-0000Ej-MN; Tue, 30 Oct 2012 14:53:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TTDCU-00042R-I2;
	Tue, 30 Oct 2012 14:53:54 +0000
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20623.59904.454393.744971@mariner.uk.xensource.com>
Date: Tue, 30 Oct 2012 14:53:52 +0000
To: Roger Pau Monne 
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1351508996-54975-1-git-send-email-roger.pau@citrix.com>
References: <1351508996-54975-1-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] docs: document persistent grants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[Xen-devel] [PATCH] docs: document persistent grants"):
> Document the new persistent grants block-device feature.
> 
> Signed-off-by: Roger Pau Monne 

Acked-by: Ian Jackson 
Committed-by: Ian Jackson 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 14:54:40 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 14:54:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTDCY-00053P-Fm; Tue, 30 Oct 2012 14:53:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTDCW-00053A-Uh
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 14:53:57 +0000
Received: from [85.158.139.83:25326] by server-10.bemta-5.messagelabs.com id
	E4/2D-01025-40AEF805; Tue, 30 Oct 2012 14:53:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1351608835!16704931!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23311 invoked from network); 30 Oct 2012 14:53:55 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 14:53:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="15492016"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 14:53:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 30 Oct 2012 14:53:54 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TTDCU-0000Ej-MN; Tue, 30 Oct 2012 14:53:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TTDCU-00042R-I2;
	Tue, 30 Oct 2012 14:53:54 +0000
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20623.59904.454393.744971@mariner.uk.xensource.com>
Date: Tue, 30 Oct 2012 14:53:52 +0000
To: Roger Pau Monne 
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1351508996-54975-1-git-send-email-roger.pau@citrix.com>
References: <1351508996-54975-1-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] docs: document persistent grants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[Xen-devel] [PATCH] docs: document persistent grants"):
> Document the new persistent grants block-device feature.
> 
> Signed-off-by: Roger Pau Monne 

Acked-by: Ian Jackson 
Committed-by: Ian Jackson 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 15:00:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 15:00:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTDIm-0005Ph-Ap; Tue, 30 Oct 2012 15:00:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTDIl-0005Pc-0B
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 15:00:23 +0000
Received: from [85.158.143.35:46282] by server-3.bemta-4.messagelabs.com id
	FB/06-24279-68BEF805; Tue, 30 Oct 2012 15:00:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1351609106!15686308!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23749 invoked from network); 30 Oct 2012 14:58:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 14:58:27 -0000
X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="15492137"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 14:58:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 30 Oct 2012 14:58:26 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TTDGs-0000GN-Bn; Tue, 30 Oct 2012 14:58:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TTDGs-00043G-7I;
	Tue, 30 Oct 2012 14:58:26 +0000
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20623.60173.626691.929572@mariner.uk.xensource.com>
Date: Tue, 30 Oct 2012 14:58:21 +0000
To: Roger Pau Monne 
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1351588958-75040-2-git-send-email-roger.pau@citrix.com>
References: <1351588958-75040-1-git-send-email-roger.pau@citrix.com>
	<1351588958-75040-2-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2/2] autoconf: bash is not needed on NetBSD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[Xen-devel] [PATCH 2/2] autoconf: bash is not needed on NetBSD"):
> Remove check for bash on NetBSD, since it is not needed for hotplug
> scripts (NetBSD hotplug scripts use sh) or the build system.

Is it really the case that we have no bashisms in our build system ?
I'm not convinced that even if this is true it's a property worth the
effort to preserve.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 15:00:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 15:00:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTDIm-0005Ph-Ap; Tue, 30 Oct 2012 15:00:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTDIl-0005Pc-0B
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 15:00:23 +0000
Received: from [85.158.143.35:46282] by server-3.bemta-4.messagelabs.com id
	FB/06-24279-68BEF805; Tue, 30 Oct 2012 15:00:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1351609106!15686308!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23749 invoked from network); 30 Oct 2012 14:58:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 14:58:27 -0000
X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="15492137"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 14:58:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 30 Oct 2012 14:58:26 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TTDGs-0000GN-Bn; Tue, 30 Oct 2012 14:58:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TTDGs-00043G-7I;
	Tue, 30 Oct 2012 14:58:26 +0000
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20623.60173.626691.929572@mariner.uk.xensource.com>
Date: Tue, 30 Oct 2012 14:58:21 +0000
To: Roger Pau Monne 
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1351588958-75040-2-git-send-email-roger.pau@citrix.com>
References: <1351588958-75040-1-git-send-email-roger.pau@citrix.com>
	<1351588958-75040-2-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2/2] autoconf: bash is not needed on NetBSD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[Xen-devel] [PATCH 2/2] autoconf: bash is not needed on NetBSD"):
> Remove check for bash on NetBSD, since it is not needed for hotplug
> scripts (NetBSD hotplug scripts use sh) or the build system.

Is it really the case that we have no bashisms in our build system ?
I'm not convinced that even if this is true it's a property worth the
effort to preserve.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 15:03:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 15:03:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTDLE-0005Ys-T3; Tue, 30 Oct 2012 15:02:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTDLD-0005Ym-V4
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 15:02:56 +0000
Received: from [193.109.254.147:18209] by server-15.bemta-14.messagelabs.com
	id E2/24-12105-F1CEF805; Tue, 30 Oct 2012 15:02:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1351609368!2129011!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6390 invoked from network); 30 Oct 2012 15:02:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 15:02:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="15492237"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 15:02:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 30 Oct 2012 15:02:28 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TTDKm-0000Hl-F3; Tue, 30 Oct 2012 15:02:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TTDKm-00043p-A0;
	Tue, 30 Oct 2012 15:02:28 +0000
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20623.60420.97632.890498@mariner.uk.xensource.com>
Date: Tue, 30 Oct 2012 15:02:28 +0000
To: Roger Pau Monne 
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1351588958-75040-1-git-send-email-roger.pau@citrix.com>
References: <1351588958-75040-1-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Christoph Egger , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/2] autoconf: check for wget and ftp
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[Xen-devel] [PATCH 1/2] autoconf: check for wget and ftp"):
> Some OSes don't come with wget by default, so ftp should be choosen
> on those. Add an autoconf check to check for wget and ftp, and
> replace the usage of hardcoded wget in tools.

I don't think this can be right; wget is used in many more places.  At
the very least it looks like it will break the stubdom build since
that is full of WGET.  Did you grep for WGET ?

Does "ftp -o blah.tar.gz http://xenbits.xen.org/xen-extfiles/blah.tar.gz"
really work on NetBSD and download to the local file "blah.tar.gz" ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 15:03:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 15:03:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTDLE-0005Ys-T3; Tue, 30 Oct 2012 15:02:56 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTDLD-0005Ym-V4
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 15:02:56 +0000
Received: from [193.109.254.147:18209] by server-15.bemta-14.messagelabs.com
	id E2/24-12105-F1CEF805; Tue, 30 Oct 2012 15:02:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1351609368!2129011!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6390 invoked from network); 30 Oct 2012 15:02:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 15:02:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="15492237"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 15:02:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 30 Oct 2012 15:02:28 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TTDKm-0000Hl-F3; Tue, 30 Oct 2012 15:02:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TTDKm-00043p-A0;
	Tue, 30 Oct 2012 15:02:28 +0000
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20623.60420.97632.890498@mariner.uk.xensource.com>
Date: Tue, 30 Oct 2012 15:02:28 +0000
To: Roger Pau Monne 
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1351588958-75040-1-git-send-email-roger.pau@citrix.com>
References: <1351588958-75040-1-git-send-email-roger.pau@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Christoph Egger , xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/2] autoconf: check for wget and ftp
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("[Xen-devel] [PATCH 1/2] autoconf: check for wget and ftp"):
> Some OSes don't come with wget by default, so ftp should be choosen
> on those. Add an autoconf check to check for wget and ftp, and
> replace the usage of hardcoded wget in tools.

I don't think this can be right; wget is used in many more places.  At
the very least it looks like it will break the stubdom build since
that is full of WGET.  Did you grep for WGET ?

Does "ftp -o blah.tar.gz http://xenbits.xen.org/xen-extfiles/blah.tar.gz"
really work on NetBSD and download to the local file "blah.tar.gz" ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 15:06:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 15:06:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTDOe-0005jS-H1; Tue, 30 Oct 2012 15:06:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TTDOc-0005jL-Lp
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 15:06:26 +0000
Received: from [193.109.254.147:2901] by server-11.bemta-14.messagelabs.com id
	FC/99-29027-1FCEF805; Tue, 30 Oct 2012 15:06:25 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-27.messagelabs.com!1351609577!3326008!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18022 invoked from network); 30 Oct 2012 15:06:18 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Oct 2012 15:06:18 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TTDOO-0009yd-JO; Tue, 30 Oct 2012 15:06:12 +0000
Date: Tue, 30 Oct 2012 15:06:12 +0000
From: Tim Deegan 
To: Andres Lagar-Cavilla 
Message-ID: <20121030150612.GC34613@ocelot.phlegethon.org>
References: <508FAA9402000078000A5612@nat28.tlf.novell.com>
	<20121030093626.GB34613@ocelot.phlegethon.org>
	<4E449D48-D643-46FB-91BD-B15EF21AAC57@gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4E449D48-D643-46FB-91BD-B15EF21AAC57@gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: Andres Lagar-Cavilla ,
	Jan Beulich , xen-devel 
Subject: Re: [Xen-devel] get_gfn_query() locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 10:53 -0400 on 30 Oct (1351594401), Andres Lagar-Cavilla wrote:
> >> And then again, with the p2m lock being recursive these
> >> days, I don't think there's any harm calling the other methods
> >> here with that lock held.
> 
> Is the patch you refer to http://www.gossamer-threads.com/lists/xen/devel/261025 and the hunk in question the following?
> + get_gfn_query(d, pfn, &pt); 
> + p2m_change_type(d, pfn, pt, p2m_ram_broken); 
> + put_gfn(d, pfn); 
> 
> There really is no way to get rid of that p2m lock-protected critical
> section if the domain allows for paging etc. You might want to
> introduce a syntactically cleaner unconditional p2m_change_type
> variant that doesn't cmpxchg with the previous type -- that is
> effectively what goes on here. Should be a tiny amount of refactoring
> and the code will be cleaner, no need for query or put.

I don't think that change-type is even what's wanted here.  You want to
use some more raw form of set_p2m_entry(), since keeping the MFN is not
important.  How about:

 guest_physmap_add_entry(d, pfn, MFN_INVALID, p2m_ram_broken);

?

> > 
> > True, but it wouldn't be safe to call it with the paging lock held.
> > OTOH since we're not seeing any crashes from the lock-ordering
> > constraints maybe we don't do that.
> > 
> > Andres, what do you think?  Can we just drop/amend that comment?
> > 
> 
> If you refer to removing the ordering constraints

Noooooooooooooo! :)

I think we should drop the comment that says it's OK to call
get_gfn_query() with the paging lock held (and audit to check that we
don't do that anywhere).

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 15:06:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 15:06:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTDOe-0005jS-H1; Tue, 30 Oct 2012 15:06:28 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TTDOc-0005jL-Lp
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 15:06:26 +0000
Received: from [193.109.254.147:2901] by server-11.bemta-14.messagelabs.com id
	FC/99-29027-1FCEF805; Tue, 30 Oct 2012 15:06:25 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-27.messagelabs.com!1351609577!3326008!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18022 invoked from network); 30 Oct 2012 15:06:18 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Oct 2012 15:06:18 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TTDOO-0009yd-JO; Tue, 30 Oct 2012 15:06:12 +0000
Date: Tue, 30 Oct 2012 15:06:12 +0000
From: Tim Deegan 
To: Andres Lagar-Cavilla 
Message-ID: <20121030150612.GC34613@ocelot.phlegethon.org>
References: <508FAA9402000078000A5612@nat28.tlf.novell.com>
	<20121030093626.GB34613@ocelot.phlegethon.org>
	<4E449D48-D643-46FB-91BD-B15EF21AAC57@gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4E449D48-D643-46FB-91BD-B15EF21AAC57@gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: Andres Lagar-Cavilla ,
	Jan Beulich , xen-devel 
Subject: Re: [Xen-devel] get_gfn_query() locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 10:53 -0400 on 30 Oct (1351594401), Andres Lagar-Cavilla wrote:
> >> And then again, with the p2m lock being recursive these
> >> days, I don't think there's any harm calling the other methods
> >> here with that lock held.
> 
> Is the patch you refer to http://www.gossamer-threads.com/lists/xen/devel/261025 and the hunk in question the following?
> + get_gfn_query(d, pfn, &pt); 
> + p2m_change_type(d, pfn, pt, p2m_ram_broken); 
> + put_gfn(d, pfn); 
> 
> There really is no way to get rid of that p2m lock-protected critical
> section if the domain allows for paging etc. You might want to
> introduce a syntactically cleaner unconditional p2m_change_type
> variant that doesn't cmpxchg with the previous type -- that is
> effectively what goes on here. Should be a tiny amount of refactoring
> and the code will be cleaner, no need for query or put.

I don't think that change-type is even what's wanted here.  You want to
use some more raw form of set_p2m_entry(), since keeping the MFN is not
important.  How about:

 guest_physmap_add_entry(d, pfn, MFN_INVALID, p2m_ram_broken);

?

> > 
> > True, but it wouldn't be safe to call it with the paging lock held.
> > OTOH since we're not seeing any crashes from the lock-ordering
> > constraints maybe we don't do that.
> > 
> > Andres, what do you think?  Can we just drop/amend that comment?
> > 
> 
> If you refer to removing the ordering constraints

Noooooooooooooo! :)

I think we should drop the comment that says it's OK to call
get_gfn_query() with the paging lock held (and audit to check that we
don't do that anywhere).

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 15:09:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 15:09:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTDR5-0005q4-1Z; Tue, 30 Oct 2012 15:08:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTDR4-0005pz-Hu
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 15:08:58 +0000
Received: from [85.158.143.35:32299] by server-1.bemta-4.messagelabs.com id
	EC/61-19134-98DEF805; Tue, 30 Oct 2012 15:08:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1351609737!11927278!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17505 invoked from network); 30 Oct 2012 15:08:57 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-21.messagelabs.com with SMTP;
	30 Oct 2012 15:08:57 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 30 Oct 2012 15:08:56 +0000
Message-Id: <508FFBC202000078000A57DF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 30 Oct 2012 15:09:38 +0000
From: "Jan Beulich" 
To: "Andres Lagar-Cavilla" 
References: <508FAA9402000078000A5612@nat28.tlf.novell.com>
	<20121030093626.GB34613@ocelot.phlegethon.org>
	<4E449D48-D643-46FB-91BD-B15EF21AAC57@gridcentric.ca>
In-Reply-To: <4E449D48-D643-46FB-91BD-B15EF21AAC57@gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan , Andres Lagar-Cavilla ,
	xen-devel 
Subject: Re: [Xen-devel] get_gfn_query() locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 30.10.12 at 15:53, Andres Lagar-Cavilla  wrote:
> On Oct 30, 2012, at 5:36 AM, Tim Deegan  wrote:
> I say this because a similar interlock may apply for vMCE? Is there an 
> expectation for a domain with vMCE turned on to be "land-locked" memory-wise?

I don't think there's any dependency here, vMCE should be
transparent in that respect.

>>> And then again, with the p2m lock being recursive these
>>> days, I don't think there's any harm calling the other methods
>>> here with that lock held.
> 
> Is the patch you refer to 
> http://www.gossamer-threads.com/lists/xen/devel/261025 and the hunk in 
> question the following?
> + get_gfn_query(d, pfn, &pt); 
> + p2m_change_type(d, pfn, pt, p2m_ram_broken); 
> + put_gfn(d, pfn); 

Yes.

> There really is no way to get rid of that p2m lock-protected critical section 
> if the domain allows for paging etc.

I wasn't questioning the locking here. It was merely that code (and
the lack of error handling therein) that made me look at the definition
of the used p2m constructs.

> You might want to introduce a 
> syntactically cleaner unconditional p2m_change_type variant that doesn't 
> cmpxchg with the previous type -- that is effectively what goes on here. Should 
> be a tiny amount of refactoring and the code will be cleaner, no need for 
> query or put.

That might help here, yes.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 15:09:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 15:09:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTDR5-0005q4-1Z; Tue, 30 Oct 2012 15:08:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTDR4-0005pz-Hu
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 15:08:58 +0000
Received: from [85.158.143.35:32299] by server-1.bemta-4.messagelabs.com id
	EC/61-19134-98DEF805; Tue, 30 Oct 2012 15:08:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1351609737!11927278!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17505 invoked from network); 30 Oct 2012 15:08:57 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-21.messagelabs.com with SMTP;
	30 Oct 2012 15:08:57 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 30 Oct 2012 15:08:56 +0000
Message-Id: <508FFBC202000078000A57DF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 30 Oct 2012 15:09:38 +0000
From: "Jan Beulich" 
To: "Andres Lagar-Cavilla" 
References: <508FAA9402000078000A5612@nat28.tlf.novell.com>
	<20121030093626.GB34613@ocelot.phlegethon.org>
	<4E449D48-D643-46FB-91BD-B15EF21AAC57@gridcentric.ca>
In-Reply-To: <4E449D48-D643-46FB-91BD-B15EF21AAC57@gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan , Andres Lagar-Cavilla ,
	xen-devel 
Subject: Re: [Xen-devel] get_gfn_query() locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 30.10.12 at 15:53, Andres Lagar-Cavilla  wrote:
> On Oct 30, 2012, at 5:36 AM, Tim Deegan  wrote:
> I say this because a similar interlock may apply for vMCE? Is there an 
> expectation for a domain with vMCE turned on to be "land-locked" memory-wise?

I don't think there's any dependency here, vMCE should be
transparent in that respect.

>>> And then again, with the p2m lock being recursive these
>>> days, I don't think there's any harm calling the other methods
>>> here with that lock held.
> 
> Is the patch you refer to 
> http://www.gossamer-threads.com/lists/xen/devel/261025 and the hunk in 
> question the following?
> + get_gfn_query(d, pfn, &pt); 
> + p2m_change_type(d, pfn, pt, p2m_ram_broken); 
> + put_gfn(d, pfn); 

Yes.

> There really is no way to get rid of that p2m lock-protected critical section 
> if the domain allows for paging etc.

I wasn't questioning the locking here. It was merely that code (and
the lack of error handling therein) that made me look at the definition
of the used p2m constructs.

> You might want to introduce a 
> syntactically cleaner unconditional p2m_change_type variant that doesn't 
> cmpxchg with the previous type -- that is effectively what goes on here. Should 
> be a tiny amount of refactoring and the code will be cleaner, no need for 
> query or put.

That might help here, yes.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 15:14:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 15:14:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTDW6-00067s-W7; Tue, 30 Oct 2012 15:14:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTDW5-00067n-Uw
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 15:14:10 +0000
Received: from [85.158.138.51:35593] by server-6.bemta-3.messagelabs.com id
	4E/A9-32375-1CEEF805; Tue, 30 Oct 2012 15:14:09 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1351610046!28007482!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgzNjU3OA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30343 invoked from network); 30 Oct 2012 15:14:08 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Oct 2012 15:14:08 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9UFDirI016317
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 30 Oct 2012 15:13:45 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9UFDhph024782
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 30 Oct 2012 15:13:44 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9UFDgnx027489; Tue, 30 Oct 2012 10:13:42 -0500
MIME-Version: 1.0
Message-ID: <234774e0-45d5-4a4e-99f1-4e4c3eaee615@default>
Date: Tue, 30 Oct 2012 08:13:40 -0700 (PDT)
From: Dan Magenheimer 
To: Keir Fraser , Jan Beulich 
References: <806ef32a-2ded-42b5-a2ff-5f84ac1c1d47@default>
	
In-Reply-To: 
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Olaf Hering , Ian Campbell ,
	Konrad Wilk ,
	George Dunlap ,
	George Shuklin ,
	"Tim \(Xen.org\)" , xen-devel@lists.xen.org,
	Dario Faggioli , Kurt Hackel ,
	Zhigang Wang ,
	Ian Jackson 
Subject: Re: [Xen-devel] Proposed new "memory capacity claim"
	hypercall/feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Keir Fraser [mailto:keir.xen@gmail.com]
> Subject: Re: Proposed new "memory capacity claim" hypercall/feature
> 
> On 30/10/2012 00:03, "Dan Magenheimer"  wrote:
> 
> >> From: Keir Fraser [mailto:keir@xen.org]
> >> Subject: Re: Proposed new "memory capacity claim" hypercall/feature
> >>
> >> On 29/10/2012 21:08, "Dan Magenheimer"  wrote:
> >>
> >> Well it does depend how scalable domain creation actually is as an
> >> operation. If it is spending most of its time allocating memory then it is
> >> quite likely that parallel creations will spend a lot of time competing for
> >> the heap spinlock, and actually there will be little/no speedup compared
> >> with serialising the creations. Further, if domain creation can take
> >> minutes, it may be that we simply need to go optimise that -- we already
> >> found one stupid thing in the heap allocator recently that was burining
> >> loads of time during large-memory domain creations, and fixed it for a
> >> massive speedup in that particular case.
> >
> > I suppose ultimately it is a scalability question.  But Oracle's
> > measure of success here is based on how long a human or a tool
> > has to wait for confirmation to ensure that a domain will
> > successfully launch.  If two domains are launched in parallel
> > AND an indication is given that both will succeed, spinning on
> > the heaplock a bit just makes for a longer "boot" time, which is
> > just a cost of virtualization.  If they are launched in parallel
> > and, minutes later (or maybe even 20 seconds later), one or
> > both say "oops, I was wrong, there wasn't enough memory, so
> > try again", that's not OK for data center operations, especially if
> > there really was enough RAM for one, but not for both. Remember,
> > in the Oracle environment, we are talking about an administrator/automation
> > overseeing possibly hundreds of physical servers, not just a single
> > user/server.
> >
> > Does that make more sense?
> 
> Yes, that makes sense.

:)

So, not to beat a dead horse, but let me re-emphasize that the problem
exists even without considering tmem.  I wish to solve the problem,
but would like to do it in a way which also resolves a similar problem
for tmem.  I think the "claim" approach does that.
 
> > The "claim" approach immediately guarantees success or failure.
> > Unless there are enough "stupid things/optimisations" found that
> > you would be comfortable putting memory allocation for a domain
> > creation in a hypervisor spinlock, there will be a race unless
> > an atomic mechanism exists such as "claiming" where
> > only simple arithmetic must be done within a hypervisor lock.
> >
> > Do you disagree?
> >
> >>> and (2) tmem and/or other dynamic
> >>> memory mechanisms may be asynchronously absorbing small-but-significant
> >>> portions of RAM for other purposes during an attempted domain launch.
> >>
> >> This is an argument against allocate-rather-than-reserve? I don't think that
> >> makes sense -- so is this instead an argument against
> >> reservation-as-a-toolstack-only-mechanism? I'm not actually convinced yet we
> >> need reservations *at all*, before we get down to where it should be
> >> implemented.
> >
> > I'm not sure if we are defining terms the same, so that's hard
> > to answer.  If you define "allocation" as "a physical RAM page frame
> > number is selected (and possibly the physical page is zeroed)",
> > then I'm not sure how your definition of "reservation" differs
> > (because that's how increase/decrease_reservation are implemented
> > in the hypervisor, right?).
> >
> > Or did you mean "allocate-rather-than-claim" (where "allocate" is
> > select a specific physical pageframe and "claim" means do accounting
> > only?  If so, see the atomicity argument above.
> >
> > I'm not just arguing against reservation-as-a-toolstack-mechanism,
> > I'm stating I believe unequivocally that reservation-as-a-toolstack-
> > only-mechanism and tmem are incompatible.  (Well, not _totally_
> > incompatible... the existing workaround, tmem freeze/thaw, works
> > but is also single-threaded and has fairly severe unnecessary
> > performance repercussions.  So I'd like to solve both problems
> > at the same time.)
> 
> Okay, so why is tmem incompatible with implementing claims in the toolstack?

(Hmmm... maybe I could schedule the equivalent of a PhD qual exam
for tmem with all the core Xen developers as examiners?)

The short answer is tmem moves memory capacity around far too
frequently to be managed by a userland toolstack, especially if
the "controller" lives on a central "manager machine" in a
data center (Oracle's model).  The ebb and flow of memory supply
and demand for each guest is instead managed entirely dynamically.

The somewhat longer answer (and remember all of this is
implemented and upstream in Xen and Linux today):

First, in the tmem model, each guest is responsible for driving
its memory utilization (what Xen tools calls "current" and Xen
hypervisor calls "tot_pages") as low as it can.  This is done
in Linux with selfballooning.  At 50Hz (default), the guest
kernel will attempt to expand or contract the balloon to match
the guest kernel's current demand for memory.  Agreed, one guest
requesting changes at 50Hz could probably be handled by
a userland toolstack, but what about 100 guests?  Maybe...
but there's more.

Second, in the tmem model, each guest is making tmem hypercalls
at a rate of perhaps thousands per second, driven by the kernel
memory management internals.  Each call deals with a single
page of memory and each possibly may remove a page from (or
return a page to) Xen's free list.  Interacting with a userland
toolstack for each page is simply not feasible for this high
of a frequency, even in a single guest.

Third, tmem in Xen implements both compression and deduplication
so each attempt to put a page of data from the guest into
the hypervisor may or may not require a new physical page.
Only the hypervisor knows.

So, even on a single machine, tmem is tossing memory capacity
about at a very very high frequency.  A userland toolstack can't
possibly keep track, let alone hope to control it; that would
entirely defeat the value of tmem.  It would be like requiring
the toolstack to participate in every vcpu->pcpu transition
in the Xen cpu scheduler.

Does that make sense and answer your question?

Anyway, I think the proposed "claim" hypercall/subop neatly
solves the problem of races between large-chunk memory demands
(i.e. large domain launches) and small-chunk memory demands
(i.e. small domain launches and single-page tmem allocations).

Thanks,
Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 15:14:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 15:14:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTDW6-00067s-W7; Tue, 30 Oct 2012 15:14:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTDW5-00067n-Uw
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 15:14:10 +0000
Received: from [85.158.138.51:35593] by server-6.bemta-3.messagelabs.com id
	4E/A9-32375-1CEEF805; Tue, 30 Oct 2012 15:14:09 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1351610046!28007482!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgzNjU3OA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30343 invoked from network); 30 Oct 2012 15:14:08 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Oct 2012 15:14:08 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9UFDirI016317
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 30 Oct 2012 15:13:45 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9UFDhph024782
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 30 Oct 2012 15:13:44 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9UFDgnx027489; Tue, 30 Oct 2012 10:13:42 -0500
MIME-Version: 1.0
Message-ID: <234774e0-45d5-4a4e-99f1-4e4c3eaee615@default>
Date: Tue, 30 Oct 2012 08:13:40 -0700 (PDT)
From: Dan Magenheimer 
To: Keir Fraser , Jan Beulich 
References: <806ef32a-2ded-42b5-a2ff-5f84ac1c1d47@default>
	
In-Reply-To: 
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Olaf Hering , Ian Campbell ,
	Konrad Wilk ,
	George Dunlap ,
	George Shuklin ,
	"Tim \(Xen.org\)" , xen-devel@lists.xen.org,
	Dario Faggioli , Kurt Hackel ,
	Zhigang Wang ,
	Ian Jackson 
Subject: Re: [Xen-devel] Proposed new "memory capacity claim"
	hypercall/feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Keir Fraser [mailto:keir.xen@gmail.com]
> Subject: Re: Proposed new "memory capacity claim" hypercall/feature
> 
> On 30/10/2012 00:03, "Dan Magenheimer"  wrote:
> 
> >> From: Keir Fraser [mailto:keir@xen.org]
> >> Subject: Re: Proposed new "memory capacity claim" hypercall/feature
> >>
> >> On 29/10/2012 21:08, "Dan Magenheimer"  wrote:
> >>
> >> Well it does depend how scalable domain creation actually is as an
> >> operation. If it is spending most of its time allocating memory then it is
> >> quite likely that parallel creations will spend a lot of time competing for
> >> the heap spinlock, and actually there will be little/no speedup compared
> >> with serialising the creations. Further, if domain creation can take
> >> minutes, it may be that we simply need to go optimise that -- we already
> >> found one stupid thing in the heap allocator recently that was burining
> >> loads of time during large-memory domain creations, and fixed it for a
> >> massive speedup in that particular case.
> >
> > I suppose ultimately it is a scalability question.  But Oracle's
> > measure of success here is based on how long a human or a tool
> > has to wait for confirmation to ensure that a domain will
> > successfully launch.  If two domains are launched in parallel
> > AND an indication is given that both will succeed, spinning on
> > the heaplock a bit just makes for a longer "boot" time, which is
> > just a cost of virtualization.  If they are launched in parallel
> > and, minutes later (or maybe even 20 seconds later), one or
> > both say "oops, I was wrong, there wasn't enough memory, so
> > try again", that's not OK for data center operations, especially if
> > there really was enough RAM for one, but not for both. Remember,
> > in the Oracle environment, we are talking about an administrator/automation
> > overseeing possibly hundreds of physical servers, not just a single
> > user/server.
> >
> > Does that make more sense?
> 
> Yes, that makes sense.

:)

So, not to beat a dead horse, but let me re-emphasize that the problem
exists even without considering tmem.  I wish to solve the problem,
but would like to do it in a way which also resolves a similar problem
for tmem.  I think the "claim" approach does that.
 
> > The "claim" approach immediately guarantees success or failure.
> > Unless there are enough "stupid things/optimisations" found that
> > you would be comfortable putting memory allocation for a domain
> > creation in a hypervisor spinlock, there will be a race unless
> > an atomic mechanism exists such as "claiming" where
> > only simple arithmetic must be done within a hypervisor lock.
> >
> > Do you disagree?
> >
> >>> and (2) tmem and/or other dynamic
> >>> memory mechanisms may be asynchronously absorbing small-but-significant
> >>> portions of RAM for other purposes during an attempted domain launch.
> >>
> >> This is an argument against allocate-rather-than-reserve? I don't think that
> >> makes sense -- so is this instead an argument against
> >> reservation-as-a-toolstack-only-mechanism? I'm not actually convinced yet we
> >> need reservations *at all*, before we get down to where it should be
> >> implemented.
> >
> > I'm not sure if we are defining terms the same, so that's hard
> > to answer.  If you define "allocation" as "a physical RAM page frame
> > number is selected (and possibly the physical page is zeroed)",
> > then I'm not sure how your definition of "reservation" differs
> > (because that's how increase/decrease_reservation are implemented
> > in the hypervisor, right?).
> >
> > Or did you mean "allocate-rather-than-claim" (where "allocate" is
> > select a specific physical pageframe and "claim" means do accounting
> > only?  If so, see the atomicity argument above.
> >
> > I'm not just arguing against reservation-as-a-toolstack-mechanism,
> > I'm stating I believe unequivocally that reservation-as-a-toolstack-
> > only-mechanism and tmem are incompatible.  (Well, not _totally_
> > incompatible... the existing workaround, tmem freeze/thaw, works
> > but is also single-threaded and has fairly severe unnecessary
> > performance repercussions.  So I'd like to solve both problems
> > at the same time.)
> 
> Okay, so why is tmem incompatible with implementing claims in the toolstack?

(Hmmm... maybe I could schedule the equivalent of a PhD qual exam
for tmem with all the core Xen developers as examiners?)

The short answer is tmem moves memory capacity around far too
frequently to be managed by a userland toolstack, especially if
the "controller" lives on a central "manager machine" in a
data center (Oracle's model).  The ebb and flow of memory supply
and demand for each guest is instead managed entirely dynamically.

The somewhat longer answer (and remember all of this is
implemented and upstream in Xen and Linux today):

First, in the tmem model, each guest is responsible for driving
its memory utilization (what Xen tools calls "current" and Xen
hypervisor calls "tot_pages") as low as it can.  This is done
in Linux with selfballooning.  At 50Hz (default), the guest
kernel will attempt to expand or contract the balloon to match
the guest kernel's current demand for memory.  Agreed, one guest
requesting changes at 50Hz could probably be handled by
a userland toolstack, but what about 100 guests?  Maybe...
but there's more.

Second, in the tmem model, each guest is making tmem hypercalls
at a rate of perhaps thousands per second, driven by the kernel
memory management internals.  Each call deals with a single
page of memory and each possibly may remove a page from (or
return a page to) Xen's free list.  Interacting with a userland
toolstack for each page is simply not feasible for this high
of a frequency, even in a single guest.

Third, tmem in Xen implements both compression and deduplication
so each attempt to put a page of data from the guest into
the hypervisor may or may not require a new physical page.
Only the hypervisor knows.

So, even on a single machine, tmem is tossing memory capacity
about at a very very high frequency.  A userland toolstack can't
possibly keep track, let alone hope to control it; that would
entirely defeat the value of tmem.  It would be like requiring
the toolstack to participate in every vcpu->pcpu transition
in the Xen cpu scheduler.

Does that make sense and answer your question?

Anyway, I think the proposed "claim" hypercall/subop neatly
solves the problem of races between large-chunk memory demands
(i.e. large domain launches) and small-chunk memory demands
(i.e. small domain launches and single-page tmem allocations).

Thanks,
Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 15:19:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 15:19:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTDat-0006IV-N4; Tue, 30 Oct 2012 15:19:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTDas-0006IP-7S
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 15:19:06 +0000
Received: from [85.158.138.51:45017] by server-6.bemta-3.messagelabs.com id
	C9/D1-32375-9EFEF805; Tue, 30 Oct 2012 15:19:05 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1351610343!26254020!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjI1MTU2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28546 invoked from network); 30 Oct 2012 15:19:05 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-15.tower-174.messagelabs.com with SMTP;
	30 Oct 2012 15:19:05 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 30 Oct 2012 08:19:02 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,679,1344236400"; d="scan'208";a="211277022"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by azsmga001.ch.intel.com with ESMTP; 30 Oct 2012 08:19:02 -0700
Received: from FMSMSX110.amr.corp.intel.com (10.19.9.29) by
	FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 30 Oct 2012 08:19:01 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	fmsmsx110.amr.corp.intel.com (10.19.9.29) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 30 Oct 2012 08:19:01 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.186]) with mapi id
	14.01.0355.002; Tue, 30 Oct 2012 23:18:59 +0800
From: "Liu, Jinsong" 
To: Konrad Rzeszutek Wilk 
Thread-Topic: [Xen-devel] [PATCH 1/2] Xen acpi pad implement
Thread-Index: AQHNtqOwTi91BiFLfUibRvXA4zlK85fR5CRg
Date: Tue, 30 Oct 2012 15:18:59 +0000
Message-ID: 
References: 
	<5089676602000078000A4928@nat28.tlf.novell.com>
	
	<508A89CB020000780008E6ED@nat28.tlf.novell.com>
	
	
	<20121026201409.GF2708@phenom.dumpdata.com>
	
	<20121029123950.GK2708@phenom.dumpdata.com>
	
	<20121030133720.GA27463@phenom.dumpdata.com>
In-Reply-To: <20121030133720.GA27463@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" ,
	"linux-kernel@vger.kernel.org" ,
	Jan Beulich ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 1/2] Xen acpi pad implement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad Rzeszutek Wilk wrote:
>>> +config XEN_ACPI_PAD_STUB
>>> +	bool
>>> +	depends on XEN_DOM0 && X86_64 && ACPI
>>> +	default n
>>> +
>> 
>> This Kconfig is pointless, if CONFIG_XEN_ACPI_PAD_STUB = n, native
>> pad would successfully registerred, and then mwait #UD (we would
>> revert df88b2d96e36d9a9e325bfcd12eb45671cbbc937, right?). So xen
>> stub logic should unconditionally built-in kernel.   
> 
> 
> Potentially. Keep in mind that there is no need to built this if the
> kernel is not built with ACPI.

Sure, 'obj-$(CONFIG_XEN_DOM0) +=' is enough.
(XEN_DOM0 depends on ACPI).

>>> +subsys_initcall(xen_acpi_pad_stub_init);
>> 
>> I'm still confused. In this way there are xen-acpi-pad-stub.c and
>> xen-acpi-pad.c, and you want to let xen-acpi-pad loaded as module,
>> right? how can xen-acpi-pad logic work when it was insmoded?  
> 
> Via the register/unregister calls that this provides? Or does ACPI bus
> drivers get immediately called once the call acpi_bus_register_driver?

But when xen stub driver registerred, real xen pad ops has not been hooked to stub ops.

> 
> Or can one 'poke' the 'add' and 'remove' calls so that once the "true"
> PAD driver is loaded it will restart the ops->add call?

I think we'd better not to use xen pad stub approach. Technically it's complicated, say, how to match xen_acpi_pad driver w/ pad device? when and how to invoke .add method? how to avoid native pad loading risk? etc. I didn't find its obivous advantages, so how about keep simpler approach?

Thanks,
Jinsong

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 15:19:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 15:19:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTDat-0006IV-N4; Tue, 30 Oct 2012 15:19:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTDas-0006IP-7S
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 15:19:06 +0000
Received: from [85.158.138.51:45017] by server-6.bemta-3.messagelabs.com id
	C9/D1-32375-9EFEF805; Tue, 30 Oct 2012 15:19:05 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1351610343!26254020!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjI1MTU2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28546 invoked from network); 30 Oct 2012 15:19:05 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-15.tower-174.messagelabs.com with SMTP;
	30 Oct 2012 15:19:05 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 30 Oct 2012 08:19:02 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,679,1344236400"; d="scan'208";a="211277022"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by azsmga001.ch.intel.com with ESMTP; 30 Oct 2012 08:19:02 -0700
Received: from FMSMSX110.amr.corp.intel.com (10.19.9.29) by
	FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 30 Oct 2012 08:19:01 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	fmsmsx110.amr.corp.intel.com (10.19.9.29) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 30 Oct 2012 08:19:01 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.186]) with mapi id
	14.01.0355.002; Tue, 30 Oct 2012 23:18:59 +0800
From: "Liu, Jinsong" 
To: Konrad Rzeszutek Wilk 
Thread-Topic: [Xen-devel] [PATCH 1/2] Xen acpi pad implement
Thread-Index: AQHNtqOwTi91BiFLfUibRvXA4zlK85fR5CRg
Date: Tue, 30 Oct 2012 15:18:59 +0000
Message-ID: 
References: 
	<5089676602000078000A4928@nat28.tlf.novell.com>
	
	<508A89CB020000780008E6ED@nat28.tlf.novell.com>
	
	
	<20121026201409.GF2708@phenom.dumpdata.com>
	
	<20121029123950.GK2708@phenom.dumpdata.com>
	
	<20121030133720.GA27463@phenom.dumpdata.com>
In-Reply-To: <20121030133720.GA27463@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" ,
	"linux-kernel@vger.kernel.org" ,
	Jan Beulich ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH 1/2] Xen acpi pad implement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad Rzeszutek Wilk wrote:
>>> +config XEN_ACPI_PAD_STUB
>>> +	bool
>>> +	depends on XEN_DOM0 && X86_64 && ACPI
>>> +	default n
>>> +
>> 
>> This Kconfig is pointless, if CONFIG_XEN_ACPI_PAD_STUB = n, native
>> pad would successfully registerred, and then mwait #UD (we would
>> revert df88b2d96e36d9a9e325bfcd12eb45671cbbc937, right?). So xen
>> stub logic should unconditionally built-in kernel.   
> 
> 
> Potentially. Keep in mind that there is no need to built this if the
> kernel is not built with ACPI.

Sure, 'obj-$(CONFIG_XEN_DOM0) +=' is enough.
(XEN_DOM0 depends on ACPI).

>>> +subsys_initcall(xen_acpi_pad_stub_init);
>> 
>> I'm still confused. In this way there are xen-acpi-pad-stub.c and
>> xen-acpi-pad.c, and you want to let xen-acpi-pad loaded as module,
>> right? how can xen-acpi-pad logic work when it was insmoded?  
> 
> Via the register/unregister calls that this provides? Or does ACPI bus
> drivers get immediately called once the call acpi_bus_register_driver?

But when xen stub driver registerred, real xen pad ops has not been hooked to stub ops.

> 
> Or can one 'poke' the 'add' and 'remove' calls so that once the "true"
> PAD driver is loaded it will restart the ops->add call?

I think we'd better not to use xen pad stub approach. Technically it's complicated, say, how to match xen_acpi_pad driver w/ pad device? when and how to invoke .add method? how to avoid native pad loading risk? etc. I didn't find its obivous advantages, so how about keep simpler approach?

Thanks,
Jinsong

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 15:20:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 15:20:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTDbr-0006MP-4B; Tue, 30 Oct 2012 15:20:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTDbp-0006ME-SU
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 15:20:06 +0000
Received: from [85.158.143.99:20267] by server-1.bemta-4.messagelabs.com id
	86/C2-19134-520FF805; Tue, 30 Oct 2012 15:20:05 +0000
X-Env-Sender: mats.petersson@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1351610401!27625969!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzk4OTc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20274 invoked from network); 30 Oct 2012 15:20:03 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 15:20:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="42892594"
Received: from unknown (HELO FTLPEX01CL03.citrite.net) ([10.13.107.80])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	30 Oct 2012 15:19:47 +0000
Received: from [10.80.3.146] (10.80.3.146) by FTLPEX01CL03.citrite.net
	(10.13.107.77) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 30 Oct 2012 11:19:47 -0400
Message-ID: <508FF012.30901@citrix.com>
Date: Tue, 30 Oct 2012 15:19:46 +0000
From: Mats Petersson 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: 
References: <506B2268020000780009F273@nat28.tlf.novell.com>
	<508FF03702000078000A576D@nat28.tlf.novell.com>
	<508FF1E202000078000A5786@nat28.tlf.novell.com>
In-Reply-To: <508FF1E202000078000A5786@nat28.tlf.novell.com>
X-Originating-IP: [10.80.3.146]
Subject: Re: [Xen-devel] [PATCH 1/2,
 v2] x86: use MOV instead of PUSH/POP when saving/restoring register
 state
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 30/10/12 14:27, Jan Beulich wrote:
> Signed-off-by: Jan Beulich 
> Acked-by: Keir Fraser 
> ---
> This patch did not change from its v1 submission.
>
> --- a/xen/arch/x86/x86_64/compat/entry.S
> +++ b/xen/arch/x86/x86_64/compat/entry.S
> @@ -21,8 +21,7 @@ ENTRY(compat_hypercall)
>   UNLIKELY_START(ne, msi_check)
>           movl  $HYPERCALL_VECTOR,%edi
>           call  check_for_unexpected_msi
> -        RESTORE_ALL
> -        SAVE_ALL
> +        LOAD_C_CLOBBERED
>   UNLIKELY_END(msi_check)
>   
>           GET_CURRENT(%rbx)
> @@ -173,8 +172,7 @@ compat_bad_hypercall:
>   /* %rbx: struct vcpu, interrupts disabled */
>   compat_restore_all_guest:
>           ASSERT_INTERRUPTS_DISABLED
> -        RESTORE_ALL
> -        addq  $8,%rsp
> +        RESTORE_ALL adj=8
>   .Lft0:  iretq
>   
>   .section .fixup,"ax"
> --- a/xen/arch/x86/x86_64/entry.S
> +++ b/xen/arch/x86/x86_64/entry.S
> @@ -47,12 +47,10 @@ restore_all_guest:
>           cmpl  $1,%ecx
>           ja    .Lforce_iret
>   
> -        addq  $8,%rsp
> -        popq  %rcx                    # RIP
> -        popq  %r11                    # CS
> -        cmpw  $FLAT_USER_CS32,%r11
> -        popq  %r11                    # RFLAGS
> -        popq  %rsp                    # RSP
> +        cmpw  $FLAT_USER_CS32,16(%rsp)# CS
> +        movq  8(%rsp),%rcx            # RIP
> +        movq  24(%rsp),%r11           # RFLAGS
> +        movq  32(%rsp),%rsp           # RSP
>           je    1f
>           sysretq
>   1:      sysretl
> @@ -101,8 +99,7 @@ failsafe_callback:
>           ALIGN
>   /* No special register assumptions. */
>   restore_all_xen:
> -        RESTORE_ALL
> -        addq  $8,%rsp
> +        RESTORE_ALL adj=8
>           iretq
>   
>   /*
> @@ -311,8 +308,7 @@ ENTRY(int80_direct_trap)
>   UNLIKELY_START(ne, msi_check)
>           movl  $0x80,%edi
>           call  check_for_unexpected_msi
> -        RESTORE_ALL
> -        SAVE_ALL
> +        LOAD_C_CLOBBERED
>   UNLIKELY_END(msi_check)
>   
>           GET_CURRENT(%rbx)
> --- a/xen/include/asm-x86/x86_64/asm_defns.h
> +++ b/xen/include/asm-x86/x86_64/asm_defns.h
> @@ -5,11 +5,11 @@
>   
>   #ifdef CONFIG_FRAME_POINTER
>   /* Indicate special exception stack frame by inverting the frame pointer. */
> -#define SETUP_EXCEPTION_FRAME_POINTER           \
> -        movq  %rsp,%rbp;                        \
> +#define SETUP_EXCEPTION_FRAME_POINTER(offs)     \
> +        leaq  offs(%rsp),%rbp;                  \
>           notq  %rbp
>   #else
> -#define SETUP_EXCEPTION_FRAME_POINTER
> +#define SETUP_EXCEPTION_FRAME_POINTER(off)
Is it too pedantic to say that "off" here should be "offs"?
Just for consistency...

--
Mats


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 15:20:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 15:20:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTDbr-0006MP-4B; Tue, 30 Oct 2012 15:20:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTDbp-0006ME-SU
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 15:20:06 +0000
Received: from [85.158.143.99:20267] by server-1.bemta-4.messagelabs.com id
	86/C2-19134-520FF805; Tue, 30 Oct 2012 15:20:05 +0000
X-Env-Sender: mats.petersson@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1351610401!27625969!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzk4OTc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20274 invoked from network); 30 Oct 2012 15:20:03 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 15:20:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="42892594"
Received: from unknown (HELO FTLPEX01CL03.citrite.net) ([10.13.107.80])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	30 Oct 2012 15:19:47 +0000
Received: from [10.80.3.146] (10.80.3.146) by FTLPEX01CL03.citrite.net
	(10.13.107.77) with Microsoft SMTP Server id 14.2.318.1;
	Tue, 30 Oct 2012 11:19:47 -0400
Message-ID: <508FF012.30901@citrix.com>
Date: Tue, 30 Oct 2012 15:19:46 +0000
From: Mats Petersson 
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: 
References: <506B2268020000780009F273@nat28.tlf.novell.com>
	<508FF03702000078000A576D@nat28.tlf.novell.com>
	<508FF1E202000078000A5786@nat28.tlf.novell.com>
In-Reply-To: <508FF1E202000078000A5786@nat28.tlf.novell.com>
X-Originating-IP: [10.80.3.146]
Subject: Re: [Xen-devel] [PATCH 1/2,
 v2] x86: use MOV instead of PUSH/POP when saving/restoring register
 state
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 30/10/12 14:27, Jan Beulich wrote:
> Signed-off-by: Jan Beulich 
> Acked-by: Keir Fraser 
> ---
> This patch did not change from its v1 submission.
>
> --- a/xen/arch/x86/x86_64/compat/entry.S
> +++ b/xen/arch/x86/x86_64/compat/entry.S
> @@ -21,8 +21,7 @@ ENTRY(compat_hypercall)
>   UNLIKELY_START(ne, msi_check)
>           movl  $HYPERCALL_VECTOR,%edi
>           call  check_for_unexpected_msi
> -        RESTORE_ALL
> -        SAVE_ALL
> +        LOAD_C_CLOBBERED
>   UNLIKELY_END(msi_check)
>   
>           GET_CURRENT(%rbx)
> @@ -173,8 +172,7 @@ compat_bad_hypercall:
>   /* %rbx: struct vcpu, interrupts disabled */
>   compat_restore_all_guest:
>           ASSERT_INTERRUPTS_DISABLED
> -        RESTORE_ALL
> -        addq  $8,%rsp
> +        RESTORE_ALL adj=8
>   .Lft0:  iretq
>   
>   .section .fixup,"ax"
> --- a/xen/arch/x86/x86_64/entry.S
> +++ b/xen/arch/x86/x86_64/entry.S
> @@ -47,12 +47,10 @@ restore_all_guest:
>           cmpl  $1,%ecx
>           ja    .Lforce_iret
>   
> -        addq  $8,%rsp
> -        popq  %rcx                    # RIP
> -        popq  %r11                    # CS
> -        cmpw  $FLAT_USER_CS32,%r11
> -        popq  %r11                    # RFLAGS
> -        popq  %rsp                    # RSP
> +        cmpw  $FLAT_USER_CS32,16(%rsp)# CS
> +        movq  8(%rsp),%rcx            # RIP
> +        movq  24(%rsp),%r11           # RFLAGS
> +        movq  32(%rsp),%rsp           # RSP
>           je    1f
>           sysretq
>   1:      sysretl
> @@ -101,8 +99,7 @@ failsafe_callback:
>           ALIGN
>   /* No special register assumptions. */
>   restore_all_xen:
> -        RESTORE_ALL
> -        addq  $8,%rsp
> +        RESTORE_ALL adj=8
>           iretq
>   
>   /*
> @@ -311,8 +308,7 @@ ENTRY(int80_direct_trap)
>   UNLIKELY_START(ne, msi_check)
>           movl  $0x80,%edi
>           call  check_for_unexpected_msi
> -        RESTORE_ALL
> -        SAVE_ALL
> +        LOAD_C_CLOBBERED
>   UNLIKELY_END(msi_check)
>   
>           GET_CURRENT(%rbx)
> --- a/xen/include/asm-x86/x86_64/asm_defns.h
> +++ b/xen/include/asm-x86/x86_64/asm_defns.h
> @@ -5,11 +5,11 @@
>   
>   #ifdef CONFIG_FRAME_POINTER
>   /* Indicate special exception stack frame by inverting the frame pointer. */
> -#define SETUP_EXCEPTION_FRAME_POINTER           \
> -        movq  %rsp,%rbp;                        \
> +#define SETUP_EXCEPTION_FRAME_POINTER(offs)     \
> +        leaq  offs(%rsp),%rbp;                  \
>           notq  %rbp
>   #else
> -#define SETUP_EXCEPTION_FRAME_POINTER
> +#define SETUP_EXCEPTION_FRAME_POINTER(off)
Is it too pedantic to say that "off" here should be "offs"?
Just for consistency...

--
Mats


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 15:25:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 15:25:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTDge-0006eV-SC; Tue, 30 Oct 2012 15:25:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTDgd-0006eP-Pd
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 15:25:04 +0000
Received: from [85.158.143.35:60526] by server-2.bemta-4.messagelabs.com id
	0F/F3-22268-F41FF805; Tue, 30 Oct 2012 15:25:03 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-13.tower-21.messagelabs.com!1351610702!15076126!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17727 invoked from network); 30 Oct 2012 15:25:02 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Oct 2012 15:25:02 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id C447840146D
	for ;
	Tue, 30 Oct 2012 16:25:01 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 8mzhzF9xvcsQ for ;
	Tue, 30 Oct 2012 16:25:01 +0100 (CET)
Received: from [192.168.178.50]
	(host51-78-dynamic.2-87-r.retail.telecomitalia.it [87.2.78.51])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id 0ACE240145C
	for ;
	Tue, 30 Oct 2012 16:25:00 +0100 (CET)
Message-ID: <508FF14A.1090008@tiscali.it>
Date: Tue, 30 Oct 2012 16:24:58 +0100
From: Fabio Fantoni 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: xen-devel 
Subject: [Xen-devel] How to add spice build with qemu-xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: fantonifabio@tiscali.it
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============2705167744849868097=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============2705167744849868097==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050306070904070106000407"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms050306070904070106000407
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

Sometime ago I proposed a patch to build spice and/or other things into=20
qemu-xen (autoconf: add variable for pass arbitrary options to qemu=20
upstream) but it was not condisered the right way to solve the problem.
Now qemu upstream is more mature for use with xen (xen 4.3 and qemu=20
1.3), there is already spice support in xl and qxl will be added too, I=20
think it would be good to have the possibility to build it with spice.
How do you think we can do?
Thanks for any reply.



--------------ms050306070904070106000407
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Firma crittografica S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa
Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG
EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi
aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV
10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU
Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR
MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl
Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A
jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2
YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh
bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC
AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw
gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC
AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz
cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks
IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug
b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh
cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv
bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI
KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j
YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN
BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8
h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1
kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8
oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+
qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEyMTAzMDE1MjQ1OFowIwYJKoZIhvcNAQkEMRYEFF9wif0FldO4zw7Dg3pCkw+v
tb5rMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAgJVghi3nBU49NqGDT4+W7sui
BtEB3ybCTHrcpRl4zXbbx9MFcitRpElB24+7pcI1oc+uxLJCqLDAoAzTeDxyHd4fQUrSD+cG
kGTS0HnunWnDiyMAj/UYopux9ck5m3fELuhtyqe4g33VbAapt2OLnnvJdgef8tQ6Fn1HYuyZ
hRgDtIf8vqbmJBMpztmCnjuuezATKpQCo/4qGo+tgXdJFTCkswCKeHcLoyOkcfzrnnFlIxxM
T7RUsOpki0rXWrNsvlUVY+NtDWwLAwPf/KT5eiZtS2HH9EBdKTO4vmgT/Awuy0L4HnYcJ3Xd
sKG9BXLN/f1fcwN4kf0cCOvW7Fc9dgAAAAAAAA==
--------------ms050306070904070106000407--


--===============2705167744849868097==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2705167744849868097==--


From xen-devel-bounces@lists.xen.org Tue Oct 30 15:25:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 15:25:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTDge-0006eV-SC; Tue, 30 Oct 2012 15:25:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTDgd-0006eP-Pd
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 15:25:04 +0000
Received: from [85.158.143.35:60526] by server-2.bemta-4.messagelabs.com id
	0F/F3-22268-F41FF805; Tue, 30 Oct 2012 15:25:03 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-13.tower-21.messagelabs.com!1351610702!15076126!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17727 invoked from network); 30 Oct 2012 15:25:02 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Oct 2012 15:25:02 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id C447840146D
	for ;
	Tue, 30 Oct 2012 16:25:01 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 8mzhzF9xvcsQ for ;
	Tue, 30 Oct 2012 16:25:01 +0100 (CET)
Received: from [192.168.178.50]
	(host51-78-dynamic.2-87-r.retail.telecomitalia.it [87.2.78.51])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id 0ACE240145C
	for ;
	Tue, 30 Oct 2012 16:25:00 +0100 (CET)
Message-ID: <508FF14A.1090008@tiscali.it>
Date: Tue, 30 Oct 2012 16:24:58 +0100
From: Fabio Fantoni 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: xen-devel 
Subject: [Xen-devel] How to add spice build with qemu-xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: fantonifabio@tiscali.it
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============2705167744849868097=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============2705167744849868097==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050306070904070106000407"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms050306070904070106000407
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

Sometime ago I proposed a patch to build spice and/or other things into=20
qemu-xen (autoconf: add variable for pass arbitrary options to qemu=20
upstream) but it was not condisered the right way to solve the problem.
Now qemu upstream is more mature for use with xen (xen 4.3 and qemu=20
1.3), there is already spice support in xl and qxl will be added too, I=20
think it would be good to have the possibility to build it with spice.
How do you think we can do?
Thanks for any reply.



--------------ms050306070904070106000407
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Firma crittografica S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa
Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG
EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi
aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV
10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU
Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR
MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl
Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A
jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2
YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh
bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC
AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw
gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC
AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz
cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks
IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug
b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh
cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv
bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI
KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j
YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN
BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8
h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1
kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8
oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+
qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEyMTAzMDE1MjQ1OFowIwYJKoZIhvcNAQkEMRYEFF9wif0FldO4zw7Dg3pCkw+v
tb5rMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAgJVghi3nBU49NqGDT4+W7sui
BtEB3ybCTHrcpRl4zXbbx9MFcitRpElB24+7pcI1oc+uxLJCqLDAoAzTeDxyHd4fQUrSD+cG
kGTS0HnunWnDiyMAj/UYopux9ck5m3fELuhtyqe4g33VbAapt2OLnnvJdgef8tQ6Fn1HYuyZ
hRgDtIf8vqbmJBMpztmCnjuuezATKpQCo/4qGo+tgXdJFTCkswCKeHcLoyOkcfzrnnFlIxxM
T7RUsOpki0rXWrNsvlUVY+NtDWwLAwPf/KT5eiZtS2HH9EBdKTO4vmgT/Awuy0L4HnYcJ3Xd
sKG9BXLN/f1fcwN4kf0cCOvW7Fc9dgAAAAAAAA==
--------------ms050306070904070106000407--


--===============2705167744849868097==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2705167744849868097==--


From xen-devel-bounces@lists.xen.org Tue Oct 30 15:27:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 15:27:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTDid-0006lv-HK; Tue, 30 Oct 2012 15:27:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTDib-0006li-DP
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 15:27:05 +0000
Received: from [85.158.139.83:2591] by server-13.bemta-5.messagelabs.com id
	3A/B9-27809-8C1FF805; Tue, 30 Oct 2012 15:27:04 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1351610822!28258475!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODI5NDc0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21065 invoked from network); 30 Oct 2012 15:27:04 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Oct 2012 15:27:04 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9UFQkft030110
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 30 Oct 2012 15:26:46 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9UFQfbC021162
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 30 Oct 2012 15:26:42 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9UFQe9t018778; Tue, 30 Oct 2012 10:26:40 -0500
MIME-Version: 1.0
Message-ID: <216482f9-6d64-4693-822d-9d6078a2ccca@default>
Date: Tue, 30 Oct 2012 08:26:38 -0700 (PDT)
From: Dan Magenheimer 
To: Tim Deegan 
References: <60d00f38-98a3-4ec2-acbd-b49dafaada56@default>
	<20121029223555.GA24388@ocelot.phlegethon.org>
	
	<20121030081357.GA34613@ocelot.phlegethon.org>
In-Reply-To: <20121030081357.GA34613@ocelot.phlegethon.org>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Olaf Hering , "Keir \(Xen.org\)" ,
	Ian Campbell ,
	Konrad Wilk ,
	George Dunlap ,
	Kurt Hackel ,
	George Shuklin ,
	xen-devel@lists.xen.org, Dario Faggioli ,
	Zhigang Wang ,
	Ian Jackson 
Subject: Re: [Xen-devel] Proposed new "memory capacity claim"
	hypercall/feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Tim Deegan [mailto:tim@xen.org]
> Subject: Re: Proposed new "memory capacity claim" hypercall/feature
> 
> Hi,

Hi Tim!

> At 16:21 -0700 on 29 Oct (1351527686), Dan Magenheimer wrote:
> > > > The hypervisor must also enforce some semantics:  If an allocation
> > > > occurs such that a domain's tot_phys_pages would equal or exceed
> > > > d.tot_claimed_pages, then d.tot_claimed_pages becomes "unset".
> > > > This enforces the temporary nature of a claim:  Once a domain
> > > > fully "occupies" its claim, the claim silently expires.
> > >
> > > Why does that happen?  If I understand you correctly, releasing the
> > > claim is something the toolstack should do once it knows it's no longer
> > > needed.
> >
> > I haven't thought this all the way through yet, but I think this
> > part of the design allows the toolstack to avoid monitoring the
> > domain until "total_phys_pages" reaches "total_claimed" pages,
> > which should make the implementation of claims in the toolstack
> > simpler, especially in many-server environments.
> 
> I think the toolstack has to monitor the domain for that long anyway,
> since it will have to unpause it once it's built.

Could be.  This "claim auto-expire" feature is certainly not a
requirement but I thought it might be useful, especially for
multi-server toolstacks (such as Oracle's).  I may take a look at
implementing it anyway since it is probably only a few lines of code,
but will ensure I do so as a separately reviewable/rejectable patch.

> Relying on an
> implicit release seems fragile -- if the builder ends up using only
> (total_claimed - 1) pages, or temporarily allocating total_claimed and
> then releasing some memory, things could break.

I agree its fragile, though I don't see how things could actually
"break".  But, let's drop claim-auto-expire for now as I fear it is
detracting from the larger discussion.
 
> > > I think it needs a plan for handling restricted memory allocations.
> > > For example, some PV guests need their memory to come below a
> > > certain machine address, or entirely in superpages, and certain
> > > build-time allocations come from xenheap.  How would you handle that
> > > sort of thing?
> >
> > Good point.  I think there's always been some uncertainty about
> > how to account for different zones and xenheap... are they part of the
> > domain's memory or not?
> 
> Xenheap pages are not part of the domain memory for accounting purposes;
> likewise other 'anonymous' allocations (that is, anywhere that
> alloc_domheap_pages() & friends are called with a NULL domain pointer).
> Pages with restricted addresses are just accounted like any other
> memory, except when they're on the free lists.
> 
> Today, toolstacks use a rule of thumb of how much extra space to leave
> to cover those things -- if you want to pre-allocate them, you'll have
> to go through the hypervisor making sure _all_ memory allocations are
> accounted to the right domain somehow (maybe by generalizing the
> shadow-allocation pool to cover all per-domain overheads).  That seems
> like a useful side-effect of adding your new feature.

Hmmm... then I'm not quite sure how adding a simple "claim" changes
the need for accounting of these anonymous allocations.  I guess
it depends on the implementation... maybe the simple implementation
I have in mind can't co-exist with anonymous allocations but I think
it will.

> > Deserves some more thought...  if you can enumerate all such cases,
> > that would be very helpful (and probably valuable long-term
> > documentation as well).
> 
> I'm afraid I can't, not without re-reading all the domain-builder code
> and a fair chunk of the hypervisor, so it's up to you to figure it out.

Well, or at least to ensure that I haven't made it any worse ;-)

me adds "world peace" to the requirements list for the new claim
hypercall ;-)

Thanks much for the feedback!
Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 15:27:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 15:27:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTDid-0006lv-HK; Tue, 30 Oct 2012 15:27:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTDib-0006li-DP
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 15:27:05 +0000
Received: from [85.158.139.83:2591] by server-13.bemta-5.messagelabs.com id
	3A/B9-27809-8C1FF805; Tue, 30 Oct 2012 15:27:04 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1351610822!28258475!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODI5NDc0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21065 invoked from network); 30 Oct 2012 15:27:04 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Oct 2012 15:27:04 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9UFQkft030110
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 30 Oct 2012 15:26:46 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9UFQfbC021162
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 30 Oct 2012 15:26:42 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9UFQe9t018778; Tue, 30 Oct 2012 10:26:40 -0500
MIME-Version: 1.0
Message-ID: <216482f9-6d64-4693-822d-9d6078a2ccca@default>
Date: Tue, 30 Oct 2012 08:26:38 -0700 (PDT)
From: Dan Magenheimer 
To: Tim Deegan 
References: <60d00f38-98a3-4ec2-acbd-b49dafaada56@default>
	<20121029223555.GA24388@ocelot.phlegethon.org>
	
	<20121030081357.GA34613@ocelot.phlegethon.org>
In-Reply-To: <20121030081357.GA34613@ocelot.phlegethon.org>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Olaf Hering , "Keir \(Xen.org\)" ,
	Ian Campbell ,
	Konrad Wilk ,
	George Dunlap ,
	Kurt Hackel ,
	George Shuklin ,
	xen-devel@lists.xen.org, Dario Faggioli ,
	Zhigang Wang ,
	Ian Jackson 
Subject: Re: [Xen-devel] Proposed new "memory capacity claim"
	hypercall/feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Tim Deegan [mailto:tim@xen.org]
> Subject: Re: Proposed new "memory capacity claim" hypercall/feature
> 
> Hi,

Hi Tim!

> At 16:21 -0700 on 29 Oct (1351527686), Dan Magenheimer wrote:
> > > > The hypervisor must also enforce some semantics:  If an allocation
> > > > occurs such that a domain's tot_phys_pages would equal or exceed
> > > > d.tot_claimed_pages, then d.tot_claimed_pages becomes "unset".
> > > > This enforces the temporary nature of a claim:  Once a domain
> > > > fully "occupies" its claim, the claim silently expires.
> > >
> > > Why does that happen?  If I understand you correctly, releasing the
> > > claim is something the toolstack should do once it knows it's no longer
> > > needed.
> >
> > I haven't thought this all the way through yet, but I think this
> > part of the design allows the toolstack to avoid monitoring the
> > domain until "total_phys_pages" reaches "total_claimed" pages,
> > which should make the implementation of claims in the toolstack
> > simpler, especially in many-server environments.
> 
> I think the toolstack has to monitor the domain for that long anyway,
> since it will have to unpause it once it's built.

Could be.  This "claim auto-expire" feature is certainly not a
requirement but I thought it might be useful, especially for
multi-server toolstacks (such as Oracle's).  I may take a look at
implementing it anyway since it is probably only a few lines of code,
but will ensure I do so as a separately reviewable/rejectable patch.

> Relying on an
> implicit release seems fragile -- if the builder ends up using only
> (total_claimed - 1) pages, or temporarily allocating total_claimed and
> then releasing some memory, things could break.

I agree its fragile, though I don't see how things could actually
"break".  But, let's drop claim-auto-expire for now as I fear it is
detracting from the larger discussion.
 
> > > I think it needs a plan for handling restricted memory allocations.
> > > For example, some PV guests need their memory to come below a
> > > certain machine address, or entirely in superpages, and certain
> > > build-time allocations come from xenheap.  How would you handle that
> > > sort of thing?
> >
> > Good point.  I think there's always been some uncertainty about
> > how to account for different zones and xenheap... are they part of the
> > domain's memory or not?
> 
> Xenheap pages are not part of the domain memory for accounting purposes;
> likewise other 'anonymous' allocations (that is, anywhere that
> alloc_domheap_pages() & friends are called with a NULL domain pointer).
> Pages with restricted addresses are just accounted like any other
> memory, except when they're on the free lists.
> 
> Today, toolstacks use a rule of thumb of how much extra space to leave
> to cover those things -- if you want to pre-allocate them, you'll have
> to go through the hypervisor making sure _all_ memory allocations are
> accounted to the right domain somehow (maybe by generalizing the
> shadow-allocation pool to cover all per-domain overheads).  That seems
> like a useful side-effect of adding your new feature.

Hmmm... then I'm not quite sure how adding a simple "claim" changes
the need for accounting of these anonymous allocations.  I guess
it depends on the implementation... maybe the simple implementation
I have in mind can't co-exist with anonymous allocations but I think
it will.

> > Deserves some more thought...  if you can enumerate all such cases,
> > that would be very helpful (and probably valuable long-term
> > documentation as well).
> 
> I'm afraid I can't, not without re-reading all the domain-builder code
> and a fair chunk of the hypervisor, so it's up to you to figure it out.

Well, or at least to ensure that I haven't made it any worse ;-)

me adds "world peace" to the requirements list for the new claim
hypercall ;-)

Thanks much for the feedback!
Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 15:32:45 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 15:32:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTDns-000756-9C; Tue, 30 Oct 2012 15:32:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTDnq-000750-Ku
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 15:32:30 +0000
Received: from [85.158.139.211:24158] by server-14.bemta-5.messagelabs.com id
	A7/A3-21768-D03FF805; Tue, 30 Oct 2012 15:32:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1351611149!18163170!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3728 invoked from network); 30 Oct 2012 15:32:29 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-206.messagelabs.com with SMTP;
	30 Oct 2012 15:32:29 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 30 Oct 2012 15:32:28 +0000
Message-Id: <5090014F02000078000A580D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 30 Oct 2012 15:33:19 +0000
From: "Jan Beulich" 
To: "Mats Petersson" 
References: <506B2268020000780009F273@nat28.tlf.novell.com>
	<508FF03702000078000A576D@nat28.tlf.novell.com>
	<508FF1E202000078000A5786@nat28.tlf.novell.com>
	<508FF012.30901@citrix.com>
In-Reply-To: <508FF012.30901@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/2,
 v2] x86: use MOV instead of PUSH/POP when saving/restoring register
 state
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 30.10.12 at 16:19, Mats Petersson  wrote:
> On 30/10/12 14:27, Jan Beulich wrote:
>> --- a/xen/include/asm-x86/x86_64/asm_defns.h
>> +++ b/xen/include/asm-x86/x86_64/asm_defns.h
>> @@ -5,11 +5,11 @@
>>   
>>   #ifdef CONFIG_FRAME_POINTER
>>   /* Indicate special exception stack frame by inverting the frame pointer. 
> */
>> -#define SETUP_EXCEPTION_FRAME_POINTER           \
>> -        movq  %rsp,%rbp;                        \
>> +#define SETUP_EXCEPTION_FRAME_POINTER(offs)     \
>> +        leaq  offs(%rsp),%rbp;                  \
>>           notq  %rbp
>>   #else
>> -#define SETUP_EXCEPTION_FRAME_POINTER
>> +#define SETUP_EXCEPTION_FRAME_POINTER(off)
> Is it too pedantic to say that "off" here should be "offs"?
> Just for consistency...

It doesn't really matter, but I adjusted this in the copy that
may eventually get committed - for consistency, as you say.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 15:32:45 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 15:32:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTDns-000756-9C; Tue, 30 Oct 2012 15:32:32 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTDnq-000750-Ku
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 15:32:30 +0000
Received: from [85.158.139.211:24158] by server-14.bemta-5.messagelabs.com id
	A7/A3-21768-D03FF805; Tue, 30 Oct 2012 15:32:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1351611149!18163170!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3728 invoked from network); 30 Oct 2012 15:32:29 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-206.messagelabs.com with SMTP;
	30 Oct 2012 15:32:29 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 30 Oct 2012 15:32:28 +0000
Message-Id: <5090014F02000078000A580D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 30 Oct 2012 15:33:19 +0000
From: "Jan Beulich" 
To: "Mats Petersson" 
References: <506B2268020000780009F273@nat28.tlf.novell.com>
	<508FF03702000078000A576D@nat28.tlf.novell.com>
	<508FF1E202000078000A5786@nat28.tlf.novell.com>
	<508FF012.30901@citrix.com>
In-Reply-To: <508FF012.30901@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/2,
 v2] x86: use MOV instead of PUSH/POP when saving/restoring register
 state
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 30.10.12 at 16:19, Mats Petersson  wrote:
> On 30/10/12 14:27, Jan Beulich wrote:
>> --- a/xen/include/asm-x86/x86_64/asm_defns.h
>> +++ b/xen/include/asm-x86/x86_64/asm_defns.h
>> @@ -5,11 +5,11 @@
>>   
>>   #ifdef CONFIG_FRAME_POINTER
>>   /* Indicate special exception stack frame by inverting the frame pointer. 
> */
>> -#define SETUP_EXCEPTION_FRAME_POINTER           \
>> -        movq  %rsp,%rbp;                        \
>> +#define SETUP_EXCEPTION_FRAME_POINTER(offs)     \
>> +        leaq  offs(%rsp),%rbp;                  \
>>           notq  %rbp
>>   #else
>> -#define SETUP_EXCEPTION_FRAME_POINTER
>> +#define SETUP_EXCEPTION_FRAME_POINTER(off)
> Is it too pedantic to say that "off" here should be "offs"?
> Just for consistency...

It doesn't really matter, but I adjusted this in the copy that
may eventually get committed - for consistency, as you say.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 15:35:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 15:35:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTDqh-0007Bk-Rx; Tue, 30 Oct 2012 15:35:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTDqg-0007Bd-TK
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 15:35:27 +0000
Received: from [85.158.138.51:58780] by server-11.bemta-3.messagelabs.com id
	CD/A9-24008-EB3FF805; Tue, 30 Oct 2012 15:35:26 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1351611314!19930337!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7041 invoked from network); 30 Oct 2012 15:35:15 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 15:35:15 -0000
Received: by mail-we0-f173.google.com with SMTP id t11so233004wey.32
	for ; Tue, 30 Oct 2012 08:35:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=ln/zkrwUTOyLXRYBXe5VqRYadHzky6uX/fIsz2ZWsQg=;
	b=0wBI/jP94+t5fq6SAa6lwIXqswZVwI0BS0yX0l1fgZO9zaHJZZKEBQd9MpDMoCpIyN
	UNvbeQ8LFh+kO/VD7Tcs9yTkXwvnYQ8Y5ZF9uleer5cCJyK5SckYHPbTPv8GL9o799Eo
	8Bxm86o+shIY9D2BK+unwU7HCZWibq2XTXHVvj/+Y+Q0K35p70iNOxs261MrZ7UvlQtX
	4ZrBMUEAUulTzu3hGIGCQrX2M3B53ft0f2IU22sxCXpk0Fx7QBkeF/pVlIJYLCfV0wto
	pWPE7gYXhi2GEkdaV7X5a6+zESmGXkYCVQ4/fPmpH2KIz2A+5SgisAhoLfL2whyTGtpJ
	7Rjw==
Received: by 10.180.19.2 with SMTP id a2mr2643116wie.18.1351611314738;
	Tue, 30 Oct 2012 08:35:14 -0700 (PDT)
Received: from [192.168.1.88] (host86-178-46-35.range86-178.btcentralplus.com.
	[86.178.46.35])
	by mx.google.com with ESMTPS id fg6sm6740409wib.3.2012.10.30.08.35.12
	(version=SSLv3 cipher=OTHER); Tue, 30 Oct 2012 08:35:14 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Tue, 30 Oct 2012 15:35:11 +0100
From: Keir Fraser 
To: Jan Beulich ,
	xen-devel 
Message-ID: 
Thread-Topic: [Xen-devel] [PATCH 0/2, v2] x86: adjust entry frame generation
Thread-Index: Ac22tCXo7kUhceTghUO9JZ2QeLtq5Q==
In-Reply-To: <508FF03702000078000A576D@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 0/2, v2] x86: adjust entry frame generation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 30/10/2012 15:20, "Jan Beulich"  wrote:

>>>> On 02.10.12 at 17:20, "Jan Beulich"  wrote:
> This pair of patches converts the way frames gets created from
> using PUSHes/POPs to using MOVes, thus allowing (in certain
> cases) to avoid saving/restoring part of the register set.
> 
> While the exact place where the (small) win from this comes from
> varies between CPUs, the net effect is a 1 to 2% reduction on a
> combined interruption entry and exit when the full state save
> can be avoided.
> 
> 1: use MOV instead of PUSH/POP when saving/restoring register state
> 2: save only partial register state where possible
> 
> Signed-off-by: Jan Beulich 

Acked-by: Keir Fraser 

> ---
> NB: Patch 1 didn't change from its v1 submission, and what was
> originally patch 2 (of 3) did already get committed.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 15:35:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 15:35:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTDqh-0007Bk-Rx; Tue, 30 Oct 2012 15:35:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTDqg-0007Bd-TK
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 15:35:27 +0000
Received: from [85.158.138.51:58780] by server-11.bemta-3.messagelabs.com id
	CD/A9-24008-EB3FF805; Tue, 30 Oct 2012 15:35:26 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1351611314!19930337!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7041 invoked from network); 30 Oct 2012 15:35:15 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 15:35:15 -0000
Received: by mail-we0-f173.google.com with SMTP id t11so233004wey.32
	for ; Tue, 30 Oct 2012 08:35:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=ln/zkrwUTOyLXRYBXe5VqRYadHzky6uX/fIsz2ZWsQg=;
	b=0wBI/jP94+t5fq6SAa6lwIXqswZVwI0BS0yX0l1fgZO9zaHJZZKEBQd9MpDMoCpIyN
	UNvbeQ8LFh+kO/VD7Tcs9yTkXwvnYQ8Y5ZF9uleer5cCJyK5SckYHPbTPv8GL9o799Eo
	8Bxm86o+shIY9D2BK+unwU7HCZWibq2XTXHVvj/+Y+Q0K35p70iNOxs261MrZ7UvlQtX
	4ZrBMUEAUulTzu3hGIGCQrX2M3B53ft0f2IU22sxCXpk0Fx7QBkeF/pVlIJYLCfV0wto
	pWPE7gYXhi2GEkdaV7X5a6+zESmGXkYCVQ4/fPmpH2KIz2A+5SgisAhoLfL2whyTGtpJ
	7Rjw==
Received: by 10.180.19.2 with SMTP id a2mr2643116wie.18.1351611314738;
	Tue, 30 Oct 2012 08:35:14 -0700 (PDT)
Received: from [192.168.1.88] (host86-178-46-35.range86-178.btcentralplus.com.
	[86.178.46.35])
	by mx.google.com with ESMTPS id fg6sm6740409wib.3.2012.10.30.08.35.12
	(version=SSLv3 cipher=OTHER); Tue, 30 Oct 2012 08:35:14 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Tue, 30 Oct 2012 15:35:11 +0100
From: Keir Fraser 
To: Jan Beulich ,
	xen-devel 
Message-ID: 
Thread-Topic: [Xen-devel] [PATCH 0/2, v2] x86: adjust entry frame generation
Thread-Index: Ac22tCXo7kUhceTghUO9JZ2QeLtq5Q==
In-Reply-To: <508FF03702000078000A576D@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 0/2, v2] x86: adjust entry frame generation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 30/10/2012 15:20, "Jan Beulich"  wrote:

>>>> On 02.10.12 at 17:20, "Jan Beulich"  wrote:
> This pair of patches converts the way frames gets created from
> using PUSHes/POPs to using MOVes, thus allowing (in certain
> cases) to avoid saving/restoring part of the register set.
> 
> While the exact place where the (small) win from this comes from
> varies between CPUs, the net effect is a 1 to 2% reduction on a
> combined interruption entry and exit when the full state save
> can be avoided.
> 
> 1: use MOV instead of PUSH/POP when saving/restoring register state
> 2: save only partial register state where possible
> 
> Signed-off-by: Jan Beulich 

Acked-by: Keir Fraser 

> ---
> NB: Patch 1 didn't change from its v1 submission, and what was
> originally patch 2 (of 3) did already get committed.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 15:36:40 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 15:36:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTDrh-0007H8-AP; Tue, 30 Oct 2012 15:36:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTDrf-0007Gu-H7
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 15:36:27 +0000
Received: from [85.158.138.51:44917] by server-9.bemta-3.messagelabs.com id
	4F/4E-16841-AF3FF805; Tue, 30 Oct 2012 15:36:26 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1351611367!28087721!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,UPPERCASE_25_50,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6590 invoked from network); 30 Oct 2012 15:36:07 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 15:36:07 -0000
Received: by mail-wi0-f173.google.com with SMTP id hm4so2925659wib.14
	for ; Tue, 30 Oct 2012 08:36:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=QFPos0IJJqhEx/+HTDdReRXpShRv0SaY8+U4pw7+8mM=;
	b=oJyeEU3HLa2Cwo3KZvLKkVKwNP3UAo3w0+Da5US3eImLTcX6wKuJDBnY2M44ldAQsi
	8dVJq496z3OBNTvlnUXGHfZ0v2x8feiXnsLx1q7r/+rpKaohLX5+9+IuA8nTICJfxUfk
	9+T6va7pLv+syufdp2xo421Rap+6YbEy7tSGc9HSCiFF/0XN6x6RLBnE8n5QmkjrYhu/
	Y8Vur6k7s5drzvq0dTbz5PvRaADJhIa5fQ07lNsAjqn0Kl3NZtSwjeZOnUFZiLzx/Q9P
	t7i37u4u/9S8QvX0BQKbPNFwVgB/982oRR30U/z9+tw82Z7thgicb8gjHvgbXsSExe2R
	mRsA==
Received: by 10.216.90.129 with SMTP id e1mr18478607wef.87.1351611366844;
	Tue, 30 Oct 2012 08:36:06 -0700 (PDT)
Received: from [192.168.1.88] (host86-178-46-35.range86-178.btcentralplus.com.
	[86.178.46.35])
	by mx.google.com with ESMTPS id p4sm1726653wix.0.2012.10.30.08.36.04
	(version=SSLv3 cipher=OTHER); Tue, 30 Oct 2012 08:36:06 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Tue, 30 Oct 2012 15:36:01 +0100
From: Keir Fraser 
To: Mats Petersson ,
	
Message-ID: 
Thread-Topic: [Xen-devel] [PATCH 1/2, v2] x86: use MOV instead of PUSH/POP
	when saving/restoring register state
Thread-Index: Ac22tEO2J67cHk3Pak65NRvEmnKWtw==
In-Reply-To: <508FF012.30901@citrix.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 1/2,
 v2] x86: use MOV instead of PUSH/POP when saving/restoring register
 state
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 30/10/2012 16:19, "Mats Petersson"  wrote:

>>   #ifdef CONFIG_FRAME_POINTER
>>   /* Indicate special exception stack frame by inverting the frame pointer.
>> */
>> -#define SETUP_EXCEPTION_FRAME_POINTER           \
>> -        movq  %rsp,%rbp;                        \
>> +#define SETUP_EXCEPTION_FRAME_POINTER(offs)     \
>> +        leaq  offs(%rsp),%rbp;                  \
>>           notq  %rbp
>>   #else
>> -#define SETUP_EXCEPTION_FRAME_POINTER
>> +#define SETUP_EXCEPTION_FRAME_POINTER(off)
> Is it too pedantic to say that "off" here should be "offs"?
> Just for consistency...

No, it's a fair point. :)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 15:36:40 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 15:36:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTDrh-0007H8-AP; Tue, 30 Oct 2012 15:36:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTDrf-0007Gu-H7
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 15:36:27 +0000
Received: from [85.158.138.51:44917] by server-9.bemta-3.messagelabs.com id
	4F/4E-16841-AF3FF805; Tue, 30 Oct 2012 15:36:26 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1351611367!28087721!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,UPPERCASE_25_50,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6590 invoked from network); 30 Oct 2012 15:36:07 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 15:36:07 -0000
Received: by mail-wi0-f173.google.com with SMTP id hm4so2925659wib.14
	for ; Tue, 30 Oct 2012 08:36:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=QFPos0IJJqhEx/+HTDdReRXpShRv0SaY8+U4pw7+8mM=;
	b=oJyeEU3HLa2Cwo3KZvLKkVKwNP3UAo3w0+Da5US3eImLTcX6wKuJDBnY2M44ldAQsi
	8dVJq496z3OBNTvlnUXGHfZ0v2x8feiXnsLx1q7r/+rpKaohLX5+9+IuA8nTICJfxUfk
	9+T6va7pLv+syufdp2xo421Rap+6YbEy7tSGc9HSCiFF/0XN6x6RLBnE8n5QmkjrYhu/
	Y8Vur6k7s5drzvq0dTbz5PvRaADJhIa5fQ07lNsAjqn0Kl3NZtSwjeZOnUFZiLzx/Q9P
	t7i37u4u/9S8QvX0BQKbPNFwVgB/982oRR30U/z9+tw82Z7thgicb8gjHvgbXsSExe2R
	mRsA==
Received: by 10.216.90.129 with SMTP id e1mr18478607wef.87.1351611366844;
	Tue, 30 Oct 2012 08:36:06 -0700 (PDT)
Received: from [192.168.1.88] (host86-178-46-35.range86-178.btcentralplus.com.
	[86.178.46.35])
	by mx.google.com with ESMTPS id p4sm1726653wix.0.2012.10.30.08.36.04
	(version=SSLv3 cipher=OTHER); Tue, 30 Oct 2012 08:36:06 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Tue, 30 Oct 2012 15:36:01 +0100
From: Keir Fraser 
To: Mats Petersson ,
	
Message-ID: 
Thread-Topic: [Xen-devel] [PATCH 1/2, v2] x86: use MOV instead of PUSH/POP
	when saving/restoring register state
Thread-Index: Ac22tEO2J67cHk3Pak65NRvEmnKWtw==
In-Reply-To: <508FF012.30901@citrix.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 1/2,
 v2] x86: use MOV instead of PUSH/POP when saving/restoring register
 state
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 30/10/2012 16:19, "Mats Petersson"  wrote:

>>   #ifdef CONFIG_FRAME_POINTER
>>   /* Indicate special exception stack frame by inverting the frame pointer.
>> */
>> -#define SETUP_EXCEPTION_FRAME_POINTER           \
>> -        movq  %rsp,%rbp;                        \
>> +#define SETUP_EXCEPTION_FRAME_POINTER(offs)     \
>> +        leaq  offs(%rsp),%rbp;                  \
>>           notq  %rbp
>>   #else
>> -#define SETUP_EXCEPTION_FRAME_POINTER
>> +#define SETUP_EXCEPTION_FRAME_POINTER(off)
> Is it too pedantic to say that "off" here should be "offs"?
> Just for consistency...

No, it's a fair point. :)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 15:43:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 15:43:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTDyF-0007b3-5s; Tue, 30 Oct 2012 15:43:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTDyD-0007ay-1s
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 15:43:13 +0000
Received: from [85.158.139.83:58647] by server-4.bemta-5.messagelabs.com id
	DB/E6-01455-095FF805; Tue, 30 Oct 2012 15:43:12 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1351611791!27978583!1
X-Originating-IP: [209.85.212.169]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4808 invoked from network); 30 Oct 2012 15:43:11 -0000
Received: from mail-wi0-f169.google.com (HELO mail-wi0-f169.google.com)
	(209.85.212.169)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 15:43:11 -0000
Received: by mail-wi0-f169.google.com with SMTP id hq4so3080630wib.2
	for ; Tue, 30 Oct 2012 08:43:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=z/Es1JZEBmgikokMim3zR3If7LNHxiANLYyy4or50Ys=;
	b=O5MnBktgN70TgxC4mOXUgxzSnz3+dzhBxO5hX7RX3vfWJaG+cxyXGODWrszStWKnnF
	5Lxbq/fOP8PejXox2iy2PCzQlNjO9Xzl9lKIBWYP3B0z7eqDrA4Ty8f5AClMFyMlJNl6
	lVNnZ8blY9V+vPELZBUAcQ6HMfT9br9BcpuGlGa7DHlDzk1gWtwz4/FzXP0kZNu0uGy5
	pAEBKR6gUFTW0vKaONdQjagee4eOP9gFMEMuLXo6uGUm+PsfUIcqBnSWTb/z+ICVxnGk
	jJcqkWbrmXbzKLpZuubr5qPZ01464yQEbOK9RQyfbVbuM3nJuIuBa5DgwaO5uiEnBkMB
	JJ7g==
Received: by 10.180.100.130 with SMTP id ey2mr3625034wib.22.1351611791403;
	Tue, 30 Oct 2012 08:43:11 -0700 (PDT)
Received: from [192.168.1.88] (host86-178-46-35.range86-178.btcentralplus.com.
	[86.178.46.35])
	by mx.google.com with ESMTPS id eq2sm1747985wib.1.2012.10.30.08.43.07
	(version=SSLv3 cipher=OTHER); Tue, 30 Oct 2012 08:43:10 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Tue, 30 Oct 2012 15:43:01 +0100
From: Keir Fraser 
To: Dan Magenheimer ,
	Jan Beulich 
Message-ID: 
Thread-Topic: Proposed new "memory capacity claim" hypercall/feature
Thread-Index: Ac22tT4Ngjt+PF3tjkaiIuFELFnXVg==
In-Reply-To: <234774e0-45d5-4a4e-99f1-4e4c3eaee615@default>
Mime-version: 1.0
Cc: Olaf Hering , Ian Campbell ,
	Konrad Rzeszutek Wilk ,
	George Dunlap ,
	George Shuklin ,
	"Tim \(Xen.org\)" , xen-devel@lists.xen.org,
	Dario Faggioli , Kurt Hackel ,
	Zhigang Wang ,
	Ian Jackson 
Subject: Re: [Xen-devel] Proposed new "memory capacity claim"
	hypercall/feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 30/10/2012 16:13, "Dan Magenheimer"  wrote:

>> Okay, so why is tmem incompatible with implementing claims in the toolstack?
> 
> (Hmmm... maybe I could schedule the equivalent of a PhD qual exam
> for tmem with all the core Xen developers as examiners?)
> 
> The short answer is tmem moves memory capacity around far too
> frequently to be managed by a userland toolstack, especially if
> the "controller" lives on a central "manager machine" in a
> data center (Oracle's model).  The ebb and flow of memory supply
> and demand for each guest is instead managed entirely dynamically.

I don't know. I agree that fine-grained memory management is the duty of the
hypervisor, but it seems to me that the toolstack should be able to handle
admission control. It knows how much memory each existing guest is allowed
to consume at max, how much memory the new guest requires, how much memory
the system has total... Isn't the decision then simple? Tmem should be
fairly invisible to the toolstack, right?

 -- Keir

> The somewhat longer answer (and remember all of this is
> implemented and upstream in Xen and Linux today):
> 
> First, in the tmem model, each guest is responsible for driving
> its memory utilization (what Xen tools calls "current" and Xen
> hypervisor calls "tot_pages") as low as it can.  This is done
> in Linux with selfballooning.  At 50Hz (default), the guest
> kernel will attempt to expand or contract the balloon to match
> the guest kernel's current demand for memory.  Agreed, one guest
> requesting changes at 50Hz could probably be handled by
> a userland toolstack, but what about 100 guests?  Maybe...
> but there's more.
> 
> Second, in the tmem model, each guest is making tmem hypercalls
> at a rate of perhaps thousands per second, driven by the kernel
> memory management internals.  Each call deals with a single
> page of memory and each possibly may remove a page from (or
> return a page to) Xen's free list.  Interacting with a userland
> toolstack for each page is simply not feasible for this high
> of a frequency, even in a single guest.
> 
> Third, tmem in Xen implements both compression and deduplication
> so each attempt to put a page of data from the guest into
> the hypervisor may or may not require a new physical page.
> Only the hypervisor knows.
> 
> So, even on a single machine, tmem is tossing memory capacity
> about at a very very high frequency.  A userland toolstack can't
> possibly keep track, let alone hope to control it; that would
> entirely defeat the value of tmem.  It would be like requiring
> the toolstack to participate in every vcpu->pcpu transition
> in the Xen cpu scheduler.
> 
> Does that make sense and answer your question?
> 
> Anyway, I think the proposed "claim" hypercall/subop neatly
> solves the problem of races between large-chunk memory demands
> (i.e. large domain launches) and small-chunk memory demands
> (i.e. small domain launches and single-page tmem allocations).



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 15:43:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 15:43:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTDyF-0007b3-5s; Tue, 30 Oct 2012 15:43:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTDyD-0007ay-1s
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 15:43:13 +0000
Received: from [85.158.139.83:58647] by server-4.bemta-5.messagelabs.com id
	DB/E6-01455-095FF805; Tue, 30 Oct 2012 15:43:12 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1351611791!27978583!1
X-Originating-IP: [209.85.212.169]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4808 invoked from network); 30 Oct 2012 15:43:11 -0000
Received: from mail-wi0-f169.google.com (HELO mail-wi0-f169.google.com)
	(209.85.212.169)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 15:43:11 -0000
Received: by mail-wi0-f169.google.com with SMTP id hq4so3080630wib.2
	for ; Tue, 30 Oct 2012 08:43:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=z/Es1JZEBmgikokMim3zR3If7LNHxiANLYyy4or50Ys=;
	b=O5MnBktgN70TgxC4mOXUgxzSnz3+dzhBxO5hX7RX3vfWJaG+cxyXGODWrszStWKnnF
	5Lxbq/fOP8PejXox2iy2PCzQlNjO9Xzl9lKIBWYP3B0z7eqDrA4Ty8f5AClMFyMlJNl6
	lVNnZ8blY9V+vPELZBUAcQ6HMfT9br9BcpuGlGa7DHlDzk1gWtwz4/FzXP0kZNu0uGy5
	pAEBKR6gUFTW0vKaONdQjagee4eOP9gFMEMuLXo6uGUm+PsfUIcqBnSWTb/z+ICVxnGk
	jJcqkWbrmXbzKLpZuubr5qPZ01464yQEbOK9RQyfbVbuM3nJuIuBa5DgwaO5uiEnBkMB
	JJ7g==
Received: by 10.180.100.130 with SMTP id ey2mr3625034wib.22.1351611791403;
	Tue, 30 Oct 2012 08:43:11 -0700 (PDT)
Received: from [192.168.1.88] (host86-178-46-35.range86-178.btcentralplus.com.
	[86.178.46.35])
	by mx.google.com with ESMTPS id eq2sm1747985wib.1.2012.10.30.08.43.07
	(version=SSLv3 cipher=OTHER); Tue, 30 Oct 2012 08:43:10 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.34.0.120813
Date: Tue, 30 Oct 2012 15:43:01 +0100
From: Keir Fraser 
To: Dan Magenheimer ,
	Jan Beulich 
Message-ID: 
Thread-Topic: Proposed new "memory capacity claim" hypercall/feature
Thread-Index: Ac22tT4Ngjt+PF3tjkaiIuFELFnXVg==
In-Reply-To: <234774e0-45d5-4a4e-99f1-4e4c3eaee615@default>
Mime-version: 1.0
Cc: Olaf Hering , Ian Campbell ,
	Konrad Rzeszutek Wilk ,
	George Dunlap ,
	George Shuklin ,
	"Tim \(Xen.org\)" , xen-devel@lists.xen.org,
	Dario Faggioli , Kurt Hackel ,
	Zhigang Wang ,
	Ian Jackson 
Subject: Re: [Xen-devel] Proposed new "memory capacity claim"
	hypercall/feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 30/10/2012 16:13, "Dan Magenheimer"  wrote:

>> Okay, so why is tmem incompatible with implementing claims in the toolstack?
> 
> (Hmmm... maybe I could schedule the equivalent of a PhD qual exam
> for tmem with all the core Xen developers as examiners?)
> 
> The short answer is tmem moves memory capacity around far too
> frequently to be managed by a userland toolstack, especially if
> the "controller" lives on a central "manager machine" in a
> data center (Oracle's model).  The ebb and flow of memory supply
> and demand for each guest is instead managed entirely dynamically.

I don't know. I agree that fine-grained memory management is the duty of the
hypervisor, but it seems to me that the toolstack should be able to handle
admission control. It knows how much memory each existing guest is allowed
to consume at max, how much memory the new guest requires, how much memory
the system has total... Isn't the decision then simple? Tmem should be
fairly invisible to the toolstack, right?

 -- Keir

> The somewhat longer answer (and remember all of this is
> implemented and upstream in Xen and Linux today):
> 
> First, in the tmem model, each guest is responsible for driving
> its memory utilization (what Xen tools calls "current" and Xen
> hypervisor calls "tot_pages") as low as it can.  This is done
> in Linux with selfballooning.  At 50Hz (default), the guest
> kernel will attempt to expand or contract the balloon to match
> the guest kernel's current demand for memory.  Agreed, one guest
> requesting changes at 50Hz could probably be handled by
> a userland toolstack, but what about 100 guests?  Maybe...
> but there's more.
> 
> Second, in the tmem model, each guest is making tmem hypercalls
> at a rate of perhaps thousands per second, driven by the kernel
> memory management internals.  Each call deals with a single
> page of memory and each possibly may remove a page from (or
> return a page to) Xen's free list.  Interacting with a userland
> toolstack for each page is simply not feasible for this high
> of a frequency, even in a single guest.
> 
> Third, tmem in Xen implements both compression and deduplication
> so each attempt to put a page of data from the guest into
> the hypervisor may or may not require a new physical page.
> Only the hypervisor knows.
> 
> So, even on a single machine, tmem is tossing memory capacity
> about at a very very high frequency.  A userland toolstack can't
> possibly keep track, let alone hope to control it; that would
> entirely defeat the value of tmem.  It would be like requiring
> the toolstack to participate in every vcpu->pcpu transition
> in the Xen cpu scheduler.
> 
> Does that make sense and answer your question?
> 
> Anyway, I think the proposed "claim" hypercall/subop neatly
> solves the problem of races between large-chunk memory demands
> (i.e. large domain launches) and small-chunk memory demands
> (i.e. small domain launches and single-page tmem allocations).



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 15:43:49 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 15:43:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTDyY-0007cO-Ib; Tue, 30 Oct 2012 15:43:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTDyX-0007cG-KG
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 15:43:33 +0000
Received: from [85.158.143.35:31572] by server-2.bemta-4.messagelabs.com id
	33/8F-22268-4A5FF805; Tue, 30 Oct 2012 15:43:32 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1351611810!11703008!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgzNjU3OA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3459 invoked from network); 30 Oct 2012 15:43:31 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Oct 2012 15:43:31 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9UFhIwK007006
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 30 Oct 2012 15:43:19 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9UFhH57017691
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 30 Oct 2012 15:43:18 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9UFhHIk020843; Tue, 30 Oct 2012 10:43:17 -0500
MIME-Version: 1.0
Message-ID: 
Date: Tue, 30 Oct 2012 08:43:14 -0700 (PDT)
From: Dan Magenheimer 
To: Jan Beulich 
References: <60d00f38-98a3-4ec2-acbd-b49dafaada56@default>
	<20121029223555.GA24388@ocelot.phlegethon.org>
	
	<508F9DE902000078000A5565@nat28.tlf.novell.com>
In-Reply-To: <508F9DE902000078000A5565@nat28.tlf.novell.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Tim Deegan , Olaf Hering , "Keir
	\(Xen.org\)" , IanCampbell ,
	Konrad Wilk ,
	GeorgeDunlap ,
	IanJackson ,
	George Shuklin ,
	xen-devel@lists.xen.org, DarioFaggioli ,
	Kurt Hackel ,
	Zhigang Wang 
Subject: Re: [Xen-devel] Proposed new "memory capacity claim"
	hypercall/feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Tuesday, October 30, 2012 2:29 AM
> To: Dan Magenheimer
> Cc: Olaf Hering; IanCampbell; GeorgeDunlap; IanJackson; George Shuklin; DarioFaggioli; xen-
> devel@lists.xen.org; Konrad Wilk; Kurt Hackel; Mukesh Rathor; Zhigang Wang; Keir (Xen.org); Tim Deegan
> Subject: RE: Proposed new "memory capacity claim" hypercall/feature
> 
> >>> On 30.10.12 at 00:21, Dan Magenheimer  wrote:
> >>  From: Tim Deegan [mailto:tim@xen.org]
> >> As I said, I'm not opposed to this, though even after reading through
> >> the other thread I'm not convinced that it's necessary (except in cases
> >> where guest-controlled operations are allowed to consume unbounded
> >> memory, which frankly gives me the heebie-jeebies).
> >
> > A really detailed discussion of tmem would probably be good but,
> > yes, with tmem, guest-controlled* operations can and frequently will
> > absorb ALL physical RAM.  However, this is "freeable" (ephemeral)
> > memory used by the hypervisor on behalf of domains, not domain-owned
> > memory.
> >
> > * "guest-controlled" I suspect is the heebie-jeebie word... in
> >   tmem, a better description might be "guest-controls-which-data-
> >   and-hypervisor-controls-how-many-pages"
> 
> But isn't tmem use supposed to be transparent in this respect, i.e.
> if a "normal" allocation cannot be satisfied, tmem would jump in
> and free sufficient space? In which case there's no need to do
> any accounting outside of the control tools (leaving aside the
> smaller hypervisor internal allocations, which the tool stack needs
> to provide room for anyway).

Hi Jan --

Tmem can only "free sufficient space" up to the total amount
of ephemeral space of which it has control (ie. all "freeable"
memory).

Let me explain further:  Let's oversimplify a bit and say that
there are three types of pages:

a) Truly free memory (each free page is on the hypervisor free list)
b) Freeable memory ("ephmeral" memory managed by tmem)
c) Owned memory (pages allocated by the hypervisor or for a domain)

The sum of these three is always a constant: The total number of
RAM pages in the system.  However, when tmem is active, the values
of all _three_ of these change constantly.  So if at the start of a
domain launch, the sum of free+freeable exceeds the intended size
of the domain, the domain allocation/launch can start.  But then
if "owned" increases enough, there may no longer be enough memory
and the domain launch will fail.

With tmem, memory "owned" by domain (d.tot_pages) increases dynamically
in two ways: selfballooning and persistent puts (aka frontswap),
but is always capped by d.max_pages.  Neither of these communicate
to the toolstack.

Similarly, tmem (or selfballooning) may be dynamically freeing up lots
of memory without communicating to the toolstack, which could result in
the toolstack rejecting a domain launch believing there is insufficient
memory.

I am thinking the "claim" hypercall/subop eliminates these problems
and hope you agree!

Thanks,
Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 15:43:49 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 15:43:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTDyY-0007cO-Ib; Tue, 30 Oct 2012 15:43:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTDyX-0007cG-KG
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 15:43:33 +0000
Received: from [85.158.143.35:31572] by server-2.bemta-4.messagelabs.com id
	33/8F-22268-4A5FF805; Tue, 30 Oct 2012 15:43:32 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1351611810!11703008!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgzNjU3OA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3459 invoked from network); 30 Oct 2012 15:43:31 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Oct 2012 15:43:31 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9UFhIwK007006
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 30 Oct 2012 15:43:19 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9UFhH57017691
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 30 Oct 2012 15:43:18 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9UFhHIk020843; Tue, 30 Oct 2012 10:43:17 -0500
MIME-Version: 1.0
Message-ID: 
Date: Tue, 30 Oct 2012 08:43:14 -0700 (PDT)
From: Dan Magenheimer 
To: Jan Beulich 
References: <60d00f38-98a3-4ec2-acbd-b49dafaada56@default>
	<20121029223555.GA24388@ocelot.phlegethon.org>
	
	<508F9DE902000078000A5565@nat28.tlf.novell.com>
In-Reply-To: <508F9DE902000078000A5565@nat28.tlf.novell.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Tim Deegan , Olaf Hering , "Keir
	\(Xen.org\)" , IanCampbell ,
	Konrad Wilk ,
	GeorgeDunlap ,
	IanJackson ,
	George Shuklin ,
	xen-devel@lists.xen.org, DarioFaggioli ,
	Kurt Hackel ,
	Zhigang Wang 
Subject: Re: [Xen-devel] Proposed new "memory capacity claim"
	hypercall/feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Tuesday, October 30, 2012 2:29 AM
> To: Dan Magenheimer
> Cc: Olaf Hering; IanCampbell; GeorgeDunlap; IanJackson; George Shuklin; DarioFaggioli; xen-
> devel@lists.xen.org; Konrad Wilk; Kurt Hackel; Mukesh Rathor; Zhigang Wang; Keir (Xen.org); Tim Deegan
> Subject: RE: Proposed new "memory capacity claim" hypercall/feature
> 
> >>> On 30.10.12 at 00:21, Dan Magenheimer  wrote:
> >>  From: Tim Deegan [mailto:tim@xen.org]
> >> As I said, I'm not opposed to this, though even after reading through
> >> the other thread I'm not convinced that it's necessary (except in cases
> >> where guest-controlled operations are allowed to consume unbounded
> >> memory, which frankly gives me the heebie-jeebies).
> >
> > A really detailed discussion of tmem would probably be good but,
> > yes, with tmem, guest-controlled* operations can and frequently will
> > absorb ALL physical RAM.  However, this is "freeable" (ephemeral)
> > memory used by the hypervisor on behalf of domains, not domain-owned
> > memory.
> >
> > * "guest-controlled" I suspect is the heebie-jeebie word... in
> >   tmem, a better description might be "guest-controls-which-data-
> >   and-hypervisor-controls-how-many-pages"
> 
> But isn't tmem use supposed to be transparent in this respect, i.e.
> if a "normal" allocation cannot be satisfied, tmem would jump in
> and free sufficient space? In which case there's no need to do
> any accounting outside of the control tools (leaving aside the
> smaller hypervisor internal allocations, which the tool stack needs
> to provide room for anyway).

Hi Jan --

Tmem can only "free sufficient space" up to the total amount
of ephemeral space of which it has control (ie. all "freeable"
memory).

Let me explain further:  Let's oversimplify a bit and say that
there are three types of pages:

a) Truly free memory (each free page is on the hypervisor free list)
b) Freeable memory ("ephmeral" memory managed by tmem)
c) Owned memory (pages allocated by the hypervisor or for a domain)

The sum of these three is always a constant: The total number of
RAM pages in the system.  However, when tmem is active, the values
of all _three_ of these change constantly.  So if at the start of a
domain launch, the sum of free+freeable exceeds the intended size
of the domain, the domain allocation/launch can start.  But then
if "owned" increases enough, there may no longer be enough memory
and the domain launch will fail.

With tmem, memory "owned" by domain (d.tot_pages) increases dynamically
in two ways: selfballooning and persistent puts (aka frontswap),
but is always capped by d.max_pages.  Neither of these communicate
to the toolstack.

Similarly, tmem (or selfballooning) may be dynamically freeing up lots
of memory without communicating to the toolstack, which could result in
the toolstack rejecting a domain launch believing there is insufficient
memory.

I am thinking the "claim" hypercall/subop eliminates these problems
and hope you agree!

Thanks,
Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 15:45:23 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 15:45:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTE09-0007lM-7d; Tue, 30 Oct 2012 15:45:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTE07-0007lC-PU
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 15:45:12 +0000
Received: from [85.158.143.35:39759] by server-2.bemta-4.messagelabs.com id
	2C/91-22268-706FF805; Tue, 30 Oct 2012 15:45:11 +0000
X-Env-Sender: gbtux@126.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1351611903!4609930!1
X-Originating-IP: [220.181.15.56]
X-SpamReason: No, hits=0.9 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjU2ID0+IDkyMDU=\n,sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjU2ID0+IDkyMDU=\n,HTML_40_50,HTML_MESSAGE,
	MIME_BASE64_TEXT
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6471 invoked from network); 30 Oct 2012 15:45:05 -0000
Received: from m15-56.126.com (HELO m15-56.126.com) (220.181.15.56)
	by server-5.tower-21.messagelabs.com with SMTP;
	30 Oct 2012 15:45:05 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com;
	s=s110527; h=Received:Date:From:To:Subject:Content-Type:
	MIME-Version:Message-ID; bh=ML0i4Mi2cfadiKaRe1CBSkrASX2B2yP3Yk+e
	mM0R+9w=; b=aO+89izG7hVAdo3cQ7O5jAyDL7M4Lu0bisUy1tfiIOLvz0SWTvAp
	A68CjxI0SOx3BLwPVbbxxkHvtF0yc+ocmCYfCaS2FFVlLB6t1diybHBQ8YTgmOWU
	ID4V+eWlHKH9v35C07h+WBIUWK3c4mlh3wo1qZEjxwjnJR7yoC0CBFQ=
Received: from gbtux$126.com ( [124.16.139.198] ) by ajax-webmail-wmsvr56
	(Coremail) ; Tue, 30 Oct 2012 23:44:01 +0800 (CST)
X-Originating-IP: [124.16.139.198]
Date: Tue, 30 Oct 2012 23:44:01 +0800 (CST)
From: gavin  
To: xen-devel@lists.xen.org
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	20121016(20100.4985.4909) Copyright (c) 2002-2012 www.mailtech.cn
	126com
X-CM-CTRLDATA: cVyK2mZvb3Rlcl9odG09MTIxODo4MQ==
MIME-Version: 1.0
Message-ID: <50df9b92.3204f.13ab257fc59.Coremail.gbtux@126.com>
X-CM-TRANSID: OMqowEAZmkLC9Y9QLsNJAA--.8556W
X-CM-SenderInfo: pjew35a6rslhhfrp/1tbiVxJYnE3l+rUt3wABsV
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
Subject: [Xen-devel] How to get or measure the scheduled time of a VM
	accurately?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============8771889772525131408=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8771889772525131408==
Content-Type: multipart/alternative; 
	boundary="----=_Part_772572_1923303548.1351611841625"

------=_Part_772572_1923303548.1351611841625
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: base64

SGksCgoKSSBoYXZlIHNvbWUgcXVlc3Rpb25zIG9uIHRoZSBYZW4gY3JlZGl0IHNjaGVkdWxlci4K
SW4gdGhlIFhlbiBjcmVkaXQgc2NoZWR1bGVyLCBhIFZNIGlzIHNjaGVkdWxlZCB0byBydW4gYSBj
ZXJ0YWluIHRpbWUuIFRoaXMgdGltZSBtYXliZSBsYXN0IGZvciAzMG1zIG9yIGxlc3MgaWYgdGhl
IFZNIHdhcyBwcmVlbXB0ZWQuIFNvIGhvdyBjYW4gSSBnZXQgdGhpcyB0aW1lIG9mIGEgVk0gYWNj
dXJhdGVseT8gSW4gdGhlIHNvdXJjZSBjb2RlICh4ZW4vY29tbW9uL3NjaGVkX2NyZWRpdC5jKSBm
aWxlLCAgdGhlIG1ldGhvZCBjc2NoZWRfc2NoZWR1bGUgcmV0dXJucyBhIHRhc2tfc2xpY2UuIENh
biBJIHVzZSB0aGUgdGFza19zbGljZS50aW1lIGFzIHRoZSBhY2N1cmF0ZSBzY2hlZHVsZWQgdGlt
ZSBvZiBhIFZNo78KCgpJIGFsc28gd2FudCB0byBrbm93IHRoZSBhY2N1cmF0ZSBzY2hlZHVsZWQg
dGltZSBvZiBhIFZNIGluIGEgcGVyaW9kIG9mIHRpbWUsIHN1Y2ggYXMgMTAgc2Vjb25kcy4gU28s
IGhvdyBjYW4gZ2V0IGl0PyBJcyB0aGVyZSBhbnkgdXNlZnVsIHRvb2wgY2FuIGRvIHRoaXMgZm9y
IG1lPwoKTG9va2luZyBmb3J3YXJkIHRvIHlvdXIgcmVwbHkuIFRoYW5rIHlvdSB2ZXJ5IG11Y2gu
IAoKCkJlc3QgUmVnYXJkcywKR2F2aW4=
------=_Part_772572_1923303548.1351611841625
Content-Type: text/html; charset=GBK
Content-Transfer-Encoding: base64

PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS43O2NvbG9yOiMwMDAwMDA7Zm9udC1zaXplOjE0cHg7
Zm9udC1mYW1pbHk6YXJpYWwiPjxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDogMS43OyI+SGksPC9z
cGFuPjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBhcmlhbDsg
Zm9udC1zaXplOiAxNHB4OyBsaW5lLWhlaWdodDogMS43OyAiPjxicj48L2Rpdj48ZGl2IHN0eWxl
PSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogYXJpYWw7IGZvbnQtc2l6ZTogMTRw
eDsgbGluZS1oZWlnaHQ6IDEuNzsgIj5JIGhhdmUgc29tZSBxdWVzdGlvbnMgb24gdGhlIFhlbiBj
cmVkaXQgc2NoZWR1bGVyLjwvZGl2PjxkaXY+PHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiAxLjc7
Ij5JbiB0aGUgWGVuIGNyZWRpdCBzY2hlZHVsZXIsIGEgVk0gaXMgc2NoZWR1bGVkIHRvIHJ1biBh
IGNlcnRhaW4gdGltZS4gVGhpcyB0aW1lIG1heWJlIGxhc3QgZm9yIDMwbXMgb3IgbGVzcyBpZiB0
aGUgVk0gd2FzIHByZWVtcHRlZC4gU28gaG93IGNhbiBJIGdldCB0aGlzIHRpbWUgb2YgYSBWTSBh
Y2N1cmF0ZWx5PyBJbiB0aGUgc291cmNlIGNvZGUgKDwvc3Bhbj54ZW4vY29tbW9uL3NjaGVkX2Ny
ZWRpdC5jPHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiAxLjc7Ij4pIGZpbGUsICZuYnNwO3RoZSBt
ZXRob2QmbmJzcDs8L3NwYW4+Y3NjaGVkX3NjaGVkdWxlIHJldHVybnMgYSB0YXNrX3NsaWNlLiBD
YW4gSSB1c2UgdGhlIHRhc2tfc2xpY2UudGltZSBhcyB0aGUgYWNjdXJhdGUgc2NoZWR1bGVkIHRp
bWUgb2YgYSBWTaO/PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5JIGFsc28gd2FudCB0byBrbm93
IHRoZSBhY2N1cmF0ZSBzY2hlZHVsZWQgdGltZSBvZiBhIFZNIGluIGEgcGVyaW9kIG9mIHRpbWUs
IHN1Y2ggYXMgMTAgc2Vjb25kcy4gU28sIGhvdyBjYW4gZ2V0IGl0PyBJcyB0aGVyZSBhbnkgdXNl
ZnVsIHRvb2wgY2FuIGRvIHRoaXMgZm9yIG1lPzwvZGl2PjxkaXYgc3R5bGU9ImNvbG9yOiByZ2Io
MCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBhcmlhbDsgZm9udC1zaXplOiAxNHB4OyBsaW5lLWhlaWdo
dDogMS43OyAiPjxicj5Mb29raW5nIGZvcndhcmQgdG8geW91ciByZXBseS4mbmJzcDtUaGFuayB5
b3UgdmVyeSBtdWNoLiZuYnNwOzxicj48YnI+PGRpdj5CZXN0IFJlZ2FyZHMsPGRpdj5HYXZpbjwv
ZGl2PjwvZGl2PjwvZGl2PjwvZGl2Pjxicj48YnI+PHNwYW4gdGl0bGU9Im5ldGVhc2Vmb290ZXIi
PjxzcGFuIGlkPSJuZXRlYXNlX21haWxfZm9vdGVyIj48L3NwYW4+PC9zcGFuPg==
------=_Part_772572_1923303548.1351611841625--



--===============8771889772525131408==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8771889772525131408==--



From xen-devel-bounces@lists.xen.org Tue Oct 30 15:45:23 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 15:45:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTE09-0007lM-7d; Tue, 30 Oct 2012 15:45:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTE07-0007lC-PU
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 15:45:12 +0000
Received: from [85.158.143.35:39759] by server-2.bemta-4.messagelabs.com id
	2C/91-22268-706FF805; Tue, 30 Oct 2012 15:45:11 +0000
X-Env-Sender: gbtux@126.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1351611903!4609930!1
X-Originating-IP: [220.181.15.56]
X-SpamReason: No, hits=0.9 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjU2ID0+IDkyMDU=\n,sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjU2ID0+IDkyMDU=\n,HTML_40_50,HTML_MESSAGE,
	MIME_BASE64_TEXT
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6471 invoked from network); 30 Oct 2012 15:45:05 -0000
Received: from m15-56.126.com (HELO m15-56.126.com) (220.181.15.56)
	by server-5.tower-21.messagelabs.com with SMTP;
	30 Oct 2012 15:45:05 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com;
	s=s110527; h=Received:Date:From:To:Subject:Content-Type:
	MIME-Version:Message-ID; bh=ML0i4Mi2cfadiKaRe1CBSkrASX2B2yP3Yk+e
	mM0R+9w=; b=aO+89izG7hVAdo3cQ7O5jAyDL7M4Lu0bisUy1tfiIOLvz0SWTvAp
	A68CjxI0SOx3BLwPVbbxxkHvtF0yc+ocmCYfCaS2FFVlLB6t1diybHBQ8YTgmOWU
	ID4V+eWlHKH9v35C07h+WBIUWK3c4mlh3wo1qZEjxwjnJR7yoC0CBFQ=
Received: from gbtux$126.com ( [124.16.139.198] ) by ajax-webmail-wmsvr56
	(Coremail) ; Tue, 30 Oct 2012 23:44:01 +0800 (CST)
X-Originating-IP: [124.16.139.198]
Date: Tue, 30 Oct 2012 23:44:01 +0800 (CST)
From: gavin  
To: xen-devel@lists.xen.org
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	20121016(20100.4985.4909) Copyright (c) 2002-2012 www.mailtech.cn
	126com
X-CM-CTRLDATA: cVyK2mZvb3Rlcl9odG09MTIxODo4MQ==
MIME-Version: 1.0
Message-ID: <50df9b92.3204f.13ab257fc59.Coremail.gbtux@126.com>
X-CM-TRANSID: OMqowEAZmkLC9Y9QLsNJAA--.8556W
X-CM-SenderInfo: pjew35a6rslhhfrp/1tbiVxJYnE3l+rUt3wABsV
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
Subject: [Xen-devel] How to get or measure the scheduled time of a VM
	accurately?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============8771889772525131408=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8771889772525131408==
Content-Type: multipart/alternative; 
	boundary="----=_Part_772572_1923303548.1351611841625"

------=_Part_772572_1923303548.1351611841625
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: base64

SGksCgoKSSBoYXZlIHNvbWUgcXVlc3Rpb25zIG9uIHRoZSBYZW4gY3JlZGl0IHNjaGVkdWxlci4K
SW4gdGhlIFhlbiBjcmVkaXQgc2NoZWR1bGVyLCBhIFZNIGlzIHNjaGVkdWxlZCB0byBydW4gYSBj
ZXJ0YWluIHRpbWUuIFRoaXMgdGltZSBtYXliZSBsYXN0IGZvciAzMG1zIG9yIGxlc3MgaWYgdGhl
IFZNIHdhcyBwcmVlbXB0ZWQuIFNvIGhvdyBjYW4gSSBnZXQgdGhpcyB0aW1lIG9mIGEgVk0gYWNj
dXJhdGVseT8gSW4gdGhlIHNvdXJjZSBjb2RlICh4ZW4vY29tbW9uL3NjaGVkX2NyZWRpdC5jKSBm
aWxlLCAgdGhlIG1ldGhvZCBjc2NoZWRfc2NoZWR1bGUgcmV0dXJucyBhIHRhc2tfc2xpY2UuIENh
biBJIHVzZSB0aGUgdGFza19zbGljZS50aW1lIGFzIHRoZSBhY2N1cmF0ZSBzY2hlZHVsZWQgdGlt
ZSBvZiBhIFZNo78KCgpJIGFsc28gd2FudCB0byBrbm93IHRoZSBhY2N1cmF0ZSBzY2hlZHVsZWQg
dGltZSBvZiBhIFZNIGluIGEgcGVyaW9kIG9mIHRpbWUsIHN1Y2ggYXMgMTAgc2Vjb25kcy4gU28s
IGhvdyBjYW4gZ2V0IGl0PyBJcyB0aGVyZSBhbnkgdXNlZnVsIHRvb2wgY2FuIGRvIHRoaXMgZm9y
IG1lPwoKTG9va2luZyBmb3J3YXJkIHRvIHlvdXIgcmVwbHkuIFRoYW5rIHlvdSB2ZXJ5IG11Y2gu
IAoKCkJlc3QgUmVnYXJkcywKR2F2aW4=
------=_Part_772572_1923303548.1351611841625
Content-Type: text/html; charset=GBK
Content-Transfer-Encoding: base64

PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS43O2NvbG9yOiMwMDAwMDA7Zm9udC1zaXplOjE0cHg7
Zm9udC1mYW1pbHk6YXJpYWwiPjxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDogMS43OyI+SGksPC9z
cGFuPjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBhcmlhbDsg
Zm9udC1zaXplOiAxNHB4OyBsaW5lLWhlaWdodDogMS43OyAiPjxicj48L2Rpdj48ZGl2IHN0eWxl
PSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogYXJpYWw7IGZvbnQtc2l6ZTogMTRw
eDsgbGluZS1oZWlnaHQ6IDEuNzsgIj5JIGhhdmUgc29tZSBxdWVzdGlvbnMgb24gdGhlIFhlbiBj
cmVkaXQgc2NoZWR1bGVyLjwvZGl2PjxkaXY+PHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiAxLjc7
Ij5JbiB0aGUgWGVuIGNyZWRpdCBzY2hlZHVsZXIsIGEgVk0gaXMgc2NoZWR1bGVkIHRvIHJ1biBh
IGNlcnRhaW4gdGltZS4gVGhpcyB0aW1lIG1heWJlIGxhc3QgZm9yIDMwbXMgb3IgbGVzcyBpZiB0
aGUgVk0gd2FzIHByZWVtcHRlZC4gU28gaG93IGNhbiBJIGdldCB0aGlzIHRpbWUgb2YgYSBWTSBh
Y2N1cmF0ZWx5PyBJbiB0aGUgc291cmNlIGNvZGUgKDwvc3Bhbj54ZW4vY29tbW9uL3NjaGVkX2Ny
ZWRpdC5jPHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiAxLjc7Ij4pIGZpbGUsICZuYnNwO3RoZSBt
ZXRob2QmbmJzcDs8L3NwYW4+Y3NjaGVkX3NjaGVkdWxlIHJldHVybnMgYSB0YXNrX3NsaWNlLiBD
YW4gSSB1c2UgdGhlIHRhc2tfc2xpY2UudGltZSBhcyB0aGUgYWNjdXJhdGUgc2NoZWR1bGVkIHRp
bWUgb2YgYSBWTaO/PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5JIGFsc28gd2FudCB0byBrbm93
IHRoZSBhY2N1cmF0ZSBzY2hlZHVsZWQgdGltZSBvZiBhIFZNIGluIGEgcGVyaW9kIG9mIHRpbWUs
IHN1Y2ggYXMgMTAgc2Vjb25kcy4gU28sIGhvdyBjYW4gZ2V0IGl0PyBJcyB0aGVyZSBhbnkgdXNl
ZnVsIHRvb2wgY2FuIGRvIHRoaXMgZm9yIG1lPzwvZGl2PjxkaXYgc3R5bGU9ImNvbG9yOiByZ2Io
MCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBhcmlhbDsgZm9udC1zaXplOiAxNHB4OyBsaW5lLWhlaWdo
dDogMS43OyAiPjxicj5Mb29raW5nIGZvcndhcmQgdG8geW91ciByZXBseS4mbmJzcDtUaGFuayB5
b3UgdmVyeSBtdWNoLiZuYnNwOzxicj48YnI+PGRpdj5CZXN0IFJlZ2FyZHMsPGRpdj5HYXZpbjwv
ZGl2PjwvZGl2PjwvZGl2PjwvZGl2Pjxicj48YnI+PHNwYW4gdGl0bGU9Im5ldGVhc2Vmb290ZXIi
PjxzcGFuIGlkPSJuZXRlYXNlX21haWxfZm9vdGVyIj48L3NwYW4+PC9zcGFuPg==
------=_Part_772572_1923303548.1351611841625--



--===============8771889772525131408==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8771889772525131408==--



From xen-devel-bounces@lists.xen.org Tue Oct 30 15:48:07 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 15:48:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTE2k-0007yx-Qg; Tue, 30 Oct 2012 15:47:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTE2i-0007yn-Tu
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 15:47:53 +0000
Received: from [85.158.137.99:11509] by server-10.bemta-3.messagelabs.com id
	C1/A7-00901-7A6FF805; Tue, 30 Oct 2012 15:47:51 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-217.messagelabs.com!1351612071!17043308!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MjQzMTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MjQzMTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18187 invoked from network); 30 Oct 2012 15:47:51 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-4.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Oct 2012 15:47:51 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr3c7sfw==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-064-007.pools.arcor-ip.net [84.57.64.7])
	by smtp.strato.de (joses mo4) (RZmta 30.21 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id h00315o9UFXIzZ ;
	Tue, 30 Oct 2012 16:47:43 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id A270A18643; Tue, 30 Oct 2012 16:47:42 +0100 (CET)
From: Olaf Hering 
To: Jeremy Fitzhardinge ,
	Konrad Rzeszutek Wilk 
Date: Tue, 30 Oct 2012 16:47:37 +0100
Message-Id: <1351612057-21822-1-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 1.8.0
Cc: Olaf Hering , xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Subject: [Xen-devel] [PATCH v4] xen PVonHVM: move shared_info to reserved
	memory area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a respin of 00e37bdb0113a98408de42db85be002f21dbffd3
("xen PVonHVM: move shared_info to MMIO before kexec").

Currently kexec in a PVonHVM guest fails with a triple fault because the
new kernel overwrites the shared info page. The exact failure depends on
the size of the kernel image. This patch moves the pfn from RAM into an
E820 reserved memory area.

The pfn containing the shared_info is located somewhere in RAM. This will
cause trouble if the current kernel is doing a kexec boot into a new
kernel. The new kernel (and its startup code) can not know where the pfn
is, so it can not reserve the page. The hypervisor will continue to update
the pfn, and as a result memory corruption occours in the new kernel.

The toolstack marks the memory area FC000000-FFFFFFFF as reserved in the
E820 map. Within that range newer toolstacks will keep 1MB starting from
FE700000 as reserved for guest use. Older toolstacks will usually not
allocate areas up to FE700000, so FE700000 is expected to work also with
older toolstacks.

Signed-off-by: Olaf Hering 
---
v4:
 rebase to 3.7-rc3
v3:                                                                                                                                                                                                                                                                  
 make xen_hvm_init_shared_info static                                                                                                                                                                                                                                
v2:                                                                                                                                                                                                                                                                  
 add __init to xen_hvm_set_shared_info                                                                                                                                                                                                                               

 arch/x86/xen/enlighten.c | 46 ++++++++++++++++++++++++++++++----------------
 arch/x86/xen/suspend.c   |  2 +-
 arch/x86/xen/xen-ops.h   |  2 +-
 3 files changed, 32 insertions(+), 18 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 586d838..0cc41f8 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -101,7 +101,6 @@ struct shared_info xen_dummy_shared_info;
 
 void *xen_initial_gdt;
 
-RESERVE_BRK(shared_info_page_brk, PAGE_SIZE);
 __read_mostly int xen_have_vector_callback;
 EXPORT_SYMBOL_GPL(xen_have_vector_callback);
 
@@ -1495,38 +1494,53 @@ asmlinkage void __init xen_start_kernel(void)
 #endif
 }
 
-void __ref xen_hvm_init_shared_info(void)
+#ifdef CONFIG_XEN_PVHVM
+#define HVM_SHARED_INFO_ADDR 0xFE700000UL
+static struct shared_info *xen_hvm_shared_info;
+
+static void xen_hvm_connect_shared_info(unsigned long pfn)
 {
-	int cpu;
 	struct xen_add_to_physmap xatp;
-	static struct shared_info *shared_info_page = 0;
 
-	if (!shared_info_page)
-		shared_info_page = (struct shared_info *)
-			extend_brk(PAGE_SIZE, PAGE_SIZE);
 	xatp.domid = DOMID_SELF;
 	xatp.idx = 0;
 	xatp.space = XENMAPSPACE_shared_info;
-	xatp.gpfn = __pa(shared_info_page) >> PAGE_SHIFT;
+	xatp.gpfn = pfn;
 	if (HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp))
 		BUG();
 
-	HYPERVISOR_shared_info = (struct shared_info *)shared_info_page;
+}
+static void __init xen_hvm_set_shared_info(struct shared_info *sip)
+{
+	int cpu;
+
+	HYPERVISOR_shared_info = sip;
 
 	/* xen_vcpu is a pointer to the vcpu_info struct in the shared_info
 	 * page, we use it in the event channel upcall and in some pvclock
 	 * related functions. We don't need the vcpu_info placement
 	 * optimizations because we don't use any pv_mmu or pv_irq op on
-	 * HVM.
-	 * When xen_hvm_init_shared_info is run at boot time only vcpu 0 is
-	 * online but xen_hvm_init_shared_info is run at resume time too and
-	 * in that case multiple vcpus might be online. */
-	for_each_online_cpu(cpu) {
+	 * HVM. */
+	for_each_online_cpu(cpu)
 		per_cpu(xen_vcpu, cpu) = &HYPERVISOR_shared_info->vcpu_info[cpu];
-	}
 }
 
-#ifdef CONFIG_XEN_PVHVM
+/* Reconnect the shared_info pfn to a (new) mfn */
+void xen_hvm_resume_shared_info(void)
+{
+	xen_hvm_connect_shared_info(HVM_SHARED_INFO_ADDR >> PAGE_SHIFT);
+}
+
+/* Obtain an address to the pfn in reserved area */
+static void __init xen_hvm_init_shared_info(void)
+{
+	set_fixmap(FIX_PARAVIRT_BOOTMAP, HVM_SHARED_INFO_ADDR);
+	xen_hvm_shared_info =
+		(struct shared_info *)fix_to_virt(FIX_PARAVIRT_BOOTMAP);
+	xen_hvm_connect_shared_info(HVM_SHARED_INFO_ADDR >> PAGE_SHIFT);
+	xen_hvm_set_shared_info(xen_hvm_shared_info);
+}
+
 static void __init init_hvm_pv_info(void)
 {
 	int major, minor;
diff --git a/arch/x86/xen/suspend.c b/arch/x86/xen/suspend.c
index 45329c8..ae8a00c 100644
--- a/arch/x86/xen/suspend.c
+++ b/arch/x86/xen/suspend.c
@@ -30,7 +30,7 @@ void xen_arch_hvm_post_suspend(int suspend_cancelled)
 {
 #ifdef CONFIG_XEN_PVHVM
 	int cpu;
-	xen_hvm_init_shared_info();
+	xen_hvm_resume_shared_info();
 	xen_callback_vector();
 	xen_unplug_emulated_devices();
 	if (xen_feature(XENFEAT_hvm_safe_pvclock)) {
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index a95b417..d2e73d1 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -40,7 +40,7 @@ void xen_enable_syscall(void);
 void xen_vcpu_restore(void);
 
 void xen_callback_vector(void);
-void xen_hvm_init_shared_info(void);
+void xen_hvm_resume_shared_info(void);
 void xen_unplug_emulated_devices(void);
 
 void __init xen_build_dynamic_phys_to_machine(void);
-- 
1.8.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 15:48:07 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 15:48:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTE2k-0007yx-Qg; Tue, 30 Oct 2012 15:47:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTE2i-0007yn-Tu
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 15:47:53 +0000
Received: from [85.158.137.99:11509] by server-10.bemta-3.messagelabs.com id
	C1/A7-00901-7A6FF805; Tue, 30 Oct 2012 15:47:51 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-217.messagelabs.com!1351612071!17043308!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MjQzMTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MjQzMTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18187 invoked from network); 30 Oct 2012 15:47:51 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-4.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Oct 2012 15:47:51 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr3c7sfw==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-064-007.pools.arcor-ip.net [84.57.64.7])
	by smtp.strato.de (joses mo4) (RZmta 30.21 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id h00315o9UFXIzZ ;
	Tue, 30 Oct 2012 16:47:43 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id A270A18643; Tue, 30 Oct 2012 16:47:42 +0100 (CET)
From: Olaf Hering 
To: Jeremy Fitzhardinge ,
	Konrad Rzeszutek Wilk 
Date: Tue, 30 Oct 2012 16:47:37 +0100
Message-Id: <1351612057-21822-1-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 1.8.0
Cc: Olaf Hering , xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Subject: [Xen-devel] [PATCH v4] xen PVonHVM: move shared_info to reserved
	memory area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a respin of 00e37bdb0113a98408de42db85be002f21dbffd3
("xen PVonHVM: move shared_info to MMIO before kexec").

Currently kexec in a PVonHVM guest fails with a triple fault because the
new kernel overwrites the shared info page. The exact failure depends on
the size of the kernel image. This patch moves the pfn from RAM into an
E820 reserved memory area.

The pfn containing the shared_info is located somewhere in RAM. This will
cause trouble if the current kernel is doing a kexec boot into a new
kernel. The new kernel (and its startup code) can not know where the pfn
is, so it can not reserve the page. The hypervisor will continue to update
the pfn, and as a result memory corruption occours in the new kernel.

The toolstack marks the memory area FC000000-FFFFFFFF as reserved in the
E820 map. Within that range newer toolstacks will keep 1MB starting from
FE700000 as reserved for guest use. Older toolstacks will usually not
allocate areas up to FE700000, so FE700000 is expected to work also with
older toolstacks.

Signed-off-by: Olaf Hering 
---
v4:
 rebase to 3.7-rc3
v3:                                                                                                                                                                                                                                                                  
 make xen_hvm_init_shared_info static                                                                                                                                                                                                                                
v2:                                                                                                                                                                                                                                                                  
 add __init to xen_hvm_set_shared_info                                                                                                                                                                                                                               

 arch/x86/xen/enlighten.c | 46 ++++++++++++++++++++++++++++++----------------
 arch/x86/xen/suspend.c   |  2 +-
 arch/x86/xen/xen-ops.h   |  2 +-
 3 files changed, 32 insertions(+), 18 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 586d838..0cc41f8 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -101,7 +101,6 @@ struct shared_info xen_dummy_shared_info;
 
 void *xen_initial_gdt;
 
-RESERVE_BRK(shared_info_page_brk, PAGE_SIZE);
 __read_mostly int xen_have_vector_callback;
 EXPORT_SYMBOL_GPL(xen_have_vector_callback);
 
@@ -1495,38 +1494,53 @@ asmlinkage void __init xen_start_kernel(void)
 #endif
 }
 
-void __ref xen_hvm_init_shared_info(void)
+#ifdef CONFIG_XEN_PVHVM
+#define HVM_SHARED_INFO_ADDR 0xFE700000UL
+static struct shared_info *xen_hvm_shared_info;
+
+static void xen_hvm_connect_shared_info(unsigned long pfn)
 {
-	int cpu;
 	struct xen_add_to_physmap xatp;
-	static struct shared_info *shared_info_page = 0;
 
-	if (!shared_info_page)
-		shared_info_page = (struct shared_info *)
-			extend_brk(PAGE_SIZE, PAGE_SIZE);
 	xatp.domid = DOMID_SELF;
 	xatp.idx = 0;
 	xatp.space = XENMAPSPACE_shared_info;
-	xatp.gpfn = __pa(shared_info_page) >> PAGE_SHIFT;
+	xatp.gpfn = pfn;
 	if (HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp))
 		BUG();
 
-	HYPERVISOR_shared_info = (struct shared_info *)shared_info_page;
+}
+static void __init xen_hvm_set_shared_info(struct shared_info *sip)
+{
+	int cpu;
+
+	HYPERVISOR_shared_info = sip;
 
 	/* xen_vcpu is a pointer to the vcpu_info struct in the shared_info
 	 * page, we use it in the event channel upcall and in some pvclock
 	 * related functions. We don't need the vcpu_info placement
 	 * optimizations because we don't use any pv_mmu or pv_irq op on
-	 * HVM.
-	 * When xen_hvm_init_shared_info is run at boot time only vcpu 0 is
-	 * online but xen_hvm_init_shared_info is run at resume time too and
-	 * in that case multiple vcpus might be online. */
-	for_each_online_cpu(cpu) {
+	 * HVM. */
+	for_each_online_cpu(cpu)
 		per_cpu(xen_vcpu, cpu) = &HYPERVISOR_shared_info->vcpu_info[cpu];
-	}
 }
 
-#ifdef CONFIG_XEN_PVHVM
+/* Reconnect the shared_info pfn to a (new) mfn */
+void xen_hvm_resume_shared_info(void)
+{
+	xen_hvm_connect_shared_info(HVM_SHARED_INFO_ADDR >> PAGE_SHIFT);
+}
+
+/* Obtain an address to the pfn in reserved area */
+static void __init xen_hvm_init_shared_info(void)
+{
+	set_fixmap(FIX_PARAVIRT_BOOTMAP, HVM_SHARED_INFO_ADDR);
+	xen_hvm_shared_info =
+		(struct shared_info *)fix_to_virt(FIX_PARAVIRT_BOOTMAP);
+	xen_hvm_connect_shared_info(HVM_SHARED_INFO_ADDR >> PAGE_SHIFT);
+	xen_hvm_set_shared_info(xen_hvm_shared_info);
+}
+
 static void __init init_hvm_pv_info(void)
 {
 	int major, minor;
diff --git a/arch/x86/xen/suspend.c b/arch/x86/xen/suspend.c
index 45329c8..ae8a00c 100644
--- a/arch/x86/xen/suspend.c
+++ b/arch/x86/xen/suspend.c
@@ -30,7 +30,7 @@ void xen_arch_hvm_post_suspend(int suspend_cancelled)
 {
 #ifdef CONFIG_XEN_PVHVM
 	int cpu;
-	xen_hvm_init_shared_info();
+	xen_hvm_resume_shared_info();
 	xen_callback_vector();
 	xen_unplug_emulated_devices();
 	if (xen_feature(XENFEAT_hvm_safe_pvclock)) {
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index a95b417..d2e73d1 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -40,7 +40,7 @@ void xen_enable_syscall(void);
 void xen_vcpu_restore(void);
 
 void xen_callback_vector(void);
-void xen_hvm_init_shared_info(void);
+void xen_hvm_resume_shared_info(void);
 void xen_unplug_emulated_devices(void);
 
 void __init xen_build_dynamic_phys_to_machine(void);
-- 
1.8.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 15:56:01 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 15:56:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTEAF-0008Ie-QK; Tue, 30 Oct 2012 15:55:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTEAE-0008IZ-J8
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 15:55:38 +0000
Received: from [85.158.139.211:60727] by server-12.bemta-5.messagelabs.com id
	DC/1A-26919-978FF805; Tue, 30 Oct 2012 15:55:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1351612536!18212597!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8370 invoked from network); 30 Oct 2012 15:55:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 15:55:36 -0000
X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="15494330"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 15:55:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 30 Oct 2012 15:55:35 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TTEAB-0000cN-9b; Tue, 30 Oct 2012 15:55:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TTEAB-00048K-5i;
	Tue, 30 Oct 2012 15:55:35 +0000
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20623.63607.78337.449427@mariner.uk.xensource.com>
Date: Tue, 30 Oct 2012 15:55:35 +0000
To: Christoph Egger 
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <50896635.7000102@amd.com>
References: <5089493C.9020908@amd.com>
	<20617.25953.12308.24952@mariner.uk.xensource.com>
	<50896635.7000102@amd.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] ioemu: add pci passthrough support to NetBSD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Christoph Egger writes ("Re: [Xen-devel] [PATCH] ioemu: add pci passthrough support to NetBSD"):
> On 10/25/12 18:14, Ian Jackson wrote:
> > Hmm.  I'm a bit reluctant to add new features to
> > qemu-xen-traditional.  Does this work with the new upstream-based
> > qemu-xen ?
> 
> I do not know.

Certainly new features should go to the upstream qemu first.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 15:56:01 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 15:56:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTEAF-0008Ie-QK; Tue, 30 Oct 2012 15:55:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTEAE-0008IZ-J8
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 15:55:38 +0000
Received: from [85.158.139.211:60727] by server-12.bemta-5.messagelabs.com id
	DC/1A-26919-978FF805; Tue, 30 Oct 2012 15:55:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1351612536!18212597!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8370 invoked from network); 30 Oct 2012 15:55:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 15:55:36 -0000
X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="15494330"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 15:55:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 30 Oct 2012 15:55:35 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TTEAB-0000cN-9b; Tue, 30 Oct 2012 15:55:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TTEAB-00048K-5i;
	Tue, 30 Oct 2012 15:55:35 +0000
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20623.63607.78337.449427@mariner.uk.xensource.com>
Date: Tue, 30 Oct 2012 15:55:35 +0000
To: Christoph Egger 
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <50896635.7000102@amd.com>
References: <5089493C.9020908@amd.com>
	<20617.25953.12308.24952@mariner.uk.xensource.com>
	<50896635.7000102@amd.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] ioemu: add pci passthrough support to NetBSD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Christoph Egger writes ("Re: [Xen-devel] [PATCH] ioemu: add pci passthrough support to NetBSD"):
> On 10/25/12 18:14, Ian Jackson wrote:
> > Hmm.  I'm a bit reluctant to add new features to
> > qemu-xen-traditional.  Does this work with the new upstream-based
> > qemu-xen ?
> 
> I do not know.

Certainly new features should go to the upstream qemu first.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 16:00:21 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 16:00:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTEEb-0000Gu-Hw; Tue, 30 Oct 2012 16:00:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTEEY-0000Go-1n
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 16:00:07 +0000
Received: from [85.158.143.99:55159] by server-2.bemta-4.messagelabs.com id
	A8/B6-22268-589FF805; Tue, 30 Oct 2012 16:00:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1351612803!22707811!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11473 invoked from network); 30 Oct 2012 16:00:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 16:00:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="15494462"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 16:00:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 30 Oct 2012 16:00:03 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TTEEV-0000e6-FE;
	Tue, 30 Oct 2012 16:00:03 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TTEEV-0006km-2w;
	Tue, 30 Oct 2012 16:00:03 +0000
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Tue, 30 Oct 2012 16:00:03 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 14156: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14156 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14156/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl             9 guest-start               fail REGR. vs. 14076
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 14076
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 14076
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 14076

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore         fail REGR. vs. 14076

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  2bca7e58a3df
baseline version:
 xen                  40ccbee890e1

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla 
  Bastian Blank 
  Chuang Cao 
  George Dunlap 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jason McCarver 
  Joe Jin 
  Keir Fraser 
  Matt Wilson 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Sander Eikelenboom 
  Stefano Stabellini 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 632 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 16:00:21 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 16:00:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTEEb-0000Gu-Hw; Tue, 30 Oct 2012 16:00:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTEEY-0000Go-1n
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 16:00:07 +0000
Received: from [85.158.143.99:55159] by server-2.bemta-4.messagelabs.com id
	A8/B6-22268-589FF805; Tue, 30 Oct 2012 16:00:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1351612803!22707811!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11473 invoked from network); 30 Oct 2012 16:00:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 16:00:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="15494462"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 16:00:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 30 Oct 2012 16:00:03 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TTEEV-0000e6-FE;
	Tue, 30 Oct 2012 16:00:03 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TTEEV-0006km-2w;
	Tue, 30 Oct 2012 16:00:03 +0000
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Tue, 30 Oct 2012 16:00:03 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 14156: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14156 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14156/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl             9 guest-start               fail REGR. vs. 14076
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 14076
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 14076
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 14076

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore         fail REGR. vs. 14076

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  2bca7e58a3df
baseline version:
 xen                  40ccbee890e1

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla 
  Bastian Blank 
  Chuang Cao 
  George Dunlap 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jason McCarver 
  Joe Jin 
  Keir Fraser 
  Matt Wilson 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Sander Eikelenboom 
  Stefano Stabellini 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 632 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 16:03:54 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 16:03:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTEHz-0000cF-7G; Tue, 30 Oct 2012 16:03:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTEHx-0000c9-Qn
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 16:03:38 +0000
Received: from [85.158.138.51:38448] by server-5.bemta-3.messagelabs.com id
	36/0C-12440-95AFF805; Tue, 30 Oct 2012 16:03:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1351613016!27989227!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8532 invoked from network); 30 Oct 2012 16:03:36 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-174.messagelabs.com with SMTP;
	30 Oct 2012 16:03:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 30 Oct 2012 16:03:35 +0000
Message-Id: <509008A502000078000A584E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 30 Oct 2012 16:04:37 +0000
From: "Jan Beulich" 
To: "Dan Magenheimer" 
References: <60d00f38-98a3-4ec2-acbd-b49dafaada56@default>
	<20121029223555.GA24388@ocelot.phlegethon.org>
	
	<508F9DE902000078000A5565@nat28.tlf.novell.com>
	
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan , Olaf Hering ,
	"Keir\(Xen.org\)" , IanCampbell ,
	Konrad Wilk ,
	GeorgeDunlap ,
	IanJackson ,
	George Shuklin ,
	xen-devel@lists.xen.org, DarioFaggioli ,
	Kurt Hackel ,
	Zhigang Wang 
Subject: Re: [Xen-devel] Proposed new "memory capacity claim"
	hypercall/feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 30.10.12 at 16:43, Dan Magenheimer  wrote:
> With tmem, memory "owned" by domain (d.tot_pages) increases dynamically
> in two ways: selfballooning and persistent puts (aka frontswap),
> but is always capped by d.max_pages.  Neither of these communicate
> to the toolstack.
> 
> Similarly, tmem (or selfballooning) may be dynamically freeing up lots
> of memory without communicating to the toolstack, which could result in
> the toolstack rejecting a domain launch believing there is insufficient
> memory.
> 
> I am thinking the "claim" hypercall/subop eliminates these problems
> and hope you agree!

With tmem being the odd one here, wouldn't it make more sense
to force it into no-alloc mode (apparently not exactly the same as
freezing all pools) for the (infrequent?) time periods of domain
creation, thus not allowing the amount of free memory to drop
unexpectedly? Tmem could, during these time periods, still itself
internally recycle pages (e.g. fulfill a persistent put by discarding
an ephemeral page).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 16:03:54 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 16:03:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTEHz-0000cF-7G; Tue, 30 Oct 2012 16:03:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTEHx-0000c9-Qn
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 16:03:38 +0000
Received: from [85.158.138.51:38448] by server-5.bemta-3.messagelabs.com id
	36/0C-12440-95AFF805; Tue, 30 Oct 2012 16:03:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1351613016!27989227!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8532 invoked from network); 30 Oct 2012 16:03:36 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-174.messagelabs.com with SMTP;
	30 Oct 2012 16:03:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 30 Oct 2012 16:03:35 +0000
Message-Id: <509008A502000078000A584E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 30 Oct 2012 16:04:37 +0000
From: "Jan Beulich" 
To: "Dan Magenheimer" 
References: <60d00f38-98a3-4ec2-acbd-b49dafaada56@default>
	<20121029223555.GA24388@ocelot.phlegethon.org>
	
	<508F9DE902000078000A5565@nat28.tlf.novell.com>
	
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan , Olaf Hering ,
	"Keir\(Xen.org\)" , IanCampbell ,
	Konrad Wilk ,
	GeorgeDunlap ,
	IanJackson ,
	George Shuklin ,
	xen-devel@lists.xen.org, DarioFaggioli ,
	Kurt Hackel ,
	Zhigang Wang 
Subject: Re: [Xen-devel] Proposed new "memory capacity claim"
	hypercall/feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 30.10.12 at 16:43, Dan Magenheimer  wrote:
> With tmem, memory "owned" by domain (d.tot_pages) increases dynamically
> in two ways: selfballooning and persistent puts (aka frontswap),
> but is always capped by d.max_pages.  Neither of these communicate
> to the toolstack.
> 
> Similarly, tmem (or selfballooning) may be dynamically freeing up lots
> of memory without communicating to the toolstack, which could result in
> the toolstack rejecting a domain launch believing there is insufficient
> memory.
> 
> I am thinking the "claim" hypercall/subop eliminates these problems
> and hope you agree!

With tmem being the odd one here, wouldn't it make more sense
to force it into no-alloc mode (apparently not exactly the same as
freezing all pools) for the (infrequent?) time periods of domain
creation, thus not allowing the amount of free memory to drop
unexpectedly? Tmem could, during these time periods, still itself
internally recycle pages (e.g. fulfill a persistent put by discarding
an ephemeral page).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 16:05:51 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 16:05:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTEJb-0000hP-NQ; Tue, 30 Oct 2012 16:05:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTEJa-0000hF-KB
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 16:05:18 +0000
Received: from [85.158.139.83:51716] by server-7.bemta-5.messagelabs.com id
	C0/6C-23102-DBAFF805; Tue, 30 Oct 2012 16:05:17 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-182.messagelabs.com!1351613116!24042082!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MjQzMTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MjQzMTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30068 invoked from network); 30 Oct 2012 16:05:16 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Oct 2012 16:05:16 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr3c7sfw==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-064-007.pools.arcor-ip.net [84.57.64.7])
	by smtp.strato.de (jored mo21) (RZmta 30.21 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 601973o9UFuro6 ;
	Tue, 30 Oct 2012 17:05:09 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id D0C2518643; Tue, 30 Oct 2012 17:05:08 +0100 (CET)
From: Olaf Hering 
To: Jeremy Fitzhardinge ,
	Konrad Rzeszutek Wilk 
Date: Tue, 30 Oct 2012 17:05:05 +0100
Message-Id: <1351613105-24408-1-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 1.8.0
Cc: Olaf Hering , xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Subject: [Xen-devel] [PATCH] xen PVonHVM: require at least Xen 3.4 as dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The XenPVHVM extensions have not been tested much on very old
hypervisors. At least Xen 3.4 gets some testing with the pvops kernel.

Require at least Xen 3.4 for the PVonHVM extensions. If an older
hypervisor is detected the extensions will be disabled and the guest
will only see emulated hardware.

Signed-off-by: Olaf Hering 
---
 arch/x86/xen/enlighten.c | 27 ++++++++++++++++++---------
 1 file changed, 18 insertions(+), 9 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 0cc41f8..8566fa8 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1543,17 +1543,10 @@ static void __init xen_hvm_init_shared_info(void)
 
 static void __init init_hvm_pv_info(void)
 {
-	int major, minor;
 	uint32_t eax, ebx, ecx, edx, pages, msr, base;
 	u64 pfn;
 
 	base = xen_cpuid_base();
-	cpuid(base + 1, &eax, &ebx, &ecx, &edx);
-
-	major = eax >> 16;
-	minor = eax & 0xffff;
-	printk(KERN_INFO "Xen version %d.%d.\n", major, minor);
-
 	cpuid(base + 2, &pages, &msr, &ecx, &edx);
 
 	pfn = __pa(hypercall_page);
@@ -1604,13 +1597,29 @@ static void __init xen_hvm_guest_init(void)
 
 static bool __init xen_hvm_platform(void)
 {
+	int major, minor, old = 0;
+	uint32_t eax, ebx, ecx, edx, base;
+	bool usable = true;
+
 	if (xen_pv_domain())
 		return false;
 
-	if (!xen_cpuid_base())
+	base = xen_cpuid_base();
+	if (!base)
 		return false;
 
-	return true;
+	cpuid(base + 1, &eax, &ebx, &ecx, &edx);
+
+	major = eax >> 16;
+	minor = eax & 0xffff;
+
+	/* Require at least Xen 3.4 */
+	if (major < 3 || (major == 3 && minor < 4))
+		usable = false;
+	printk(KERN_INFO "Xen version %d.%d.%s\n",
+		major, minor, usable ? "" : " (too old)");
+
+	return usable;
 }
 
 bool xen_hvm_need_lapic(void)
-- 
1.8.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 16:05:51 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 16:05:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTEJb-0000hP-NQ; Tue, 30 Oct 2012 16:05:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTEJa-0000hF-KB
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 16:05:18 +0000
Received: from [85.158.139.83:51716] by server-7.bemta-5.messagelabs.com id
	C0/6C-23102-DBAFF805; Tue, 30 Oct 2012 16:05:17 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-182.messagelabs.com!1351613116!24042082!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MjQzMTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MjQzMTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30068 invoked from network); 30 Oct 2012 16:05:16 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Oct 2012 16:05:16 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr3c7sfw==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-064-007.pools.arcor-ip.net [84.57.64.7])
	by smtp.strato.de (jored mo21) (RZmta 30.21 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 601973o9UFuro6 ;
	Tue, 30 Oct 2012 17:05:09 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id D0C2518643; Tue, 30 Oct 2012 17:05:08 +0100 (CET)
From: Olaf Hering 
To: Jeremy Fitzhardinge ,
	Konrad Rzeszutek Wilk 
Date: Tue, 30 Oct 2012 17:05:05 +0100
Message-Id: <1351613105-24408-1-git-send-email-olaf@aepfle.de>
X-Mailer: git-send-email 1.8.0
Cc: Olaf Hering , xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Subject: [Xen-devel] [PATCH] xen PVonHVM: require at least Xen 3.4 as dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The XenPVHVM extensions have not been tested much on very old
hypervisors. At least Xen 3.4 gets some testing with the pvops kernel.

Require at least Xen 3.4 for the PVonHVM extensions. If an older
hypervisor is detected the extensions will be disabled and the guest
will only see emulated hardware.

Signed-off-by: Olaf Hering 
---
 arch/x86/xen/enlighten.c | 27 ++++++++++++++++++---------
 1 file changed, 18 insertions(+), 9 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 0cc41f8..8566fa8 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1543,17 +1543,10 @@ static void __init xen_hvm_init_shared_info(void)
 
 static void __init init_hvm_pv_info(void)
 {
-	int major, minor;
 	uint32_t eax, ebx, ecx, edx, pages, msr, base;
 	u64 pfn;
 
 	base = xen_cpuid_base();
-	cpuid(base + 1, &eax, &ebx, &ecx, &edx);
-
-	major = eax >> 16;
-	minor = eax & 0xffff;
-	printk(KERN_INFO "Xen version %d.%d.\n", major, minor);
-
 	cpuid(base + 2, &pages, &msr, &ecx, &edx);
 
 	pfn = __pa(hypercall_page);
@@ -1604,13 +1597,29 @@ static void __init xen_hvm_guest_init(void)
 
 static bool __init xen_hvm_platform(void)
 {
+	int major, minor, old = 0;
+	uint32_t eax, ebx, ecx, edx, base;
+	bool usable = true;
+
 	if (xen_pv_domain())
 		return false;
 
-	if (!xen_cpuid_base())
+	base = xen_cpuid_base();
+	if (!base)
 		return false;
 
-	return true;
+	cpuid(base + 1, &eax, &ebx, &ecx, &edx);
+
+	major = eax >> 16;
+	minor = eax & 0xffff;
+
+	/* Require at least Xen 3.4 */
+	if (major < 3 || (major == 3 && minor < 4))
+		usable = false;
+	printk(KERN_INFO "Xen version %d.%d.%s\n",
+		major, minor, usable ? "" : " (too old)");
+
+	return usable;
 }
 
 bool xen_hvm_need_lapic(void)
-- 
1.8.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 16:14:22 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 16:14:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTES8-00013J-Td; Tue, 30 Oct 2012 16:14:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTES7-000139-0y
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 16:14:07 +0000
Received: from [85.158.139.83:59698] by server-3.bemta-5.messagelabs.com id
	4B/55-28618-ECCFF805; Tue, 30 Oct 2012 16:14:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1351613645!27993471!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21422 invoked from network); 30 Oct 2012 16:14:05 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-182.messagelabs.com with SMTP;
	30 Oct 2012 16:14:05 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 30 Oct 2012 16:14:05 +0000
Message-Id: <50900B1D02000078000A586C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 30 Oct 2012 16:15:09 +0000
From: "Jan Beulich" 
To: "Olaf Hering" 
References: <1351612057-21822-1-git-send-email-olaf@aepfle.de>
In-Reply-To: <1351612057-21822-1-git-send-email-olaf@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeremy Fitzhardinge ,
	Konrad Rzeszutek Wilk ,
	linux-kernel@vger.kernel.org, xen-devel 
Subject: Re: [Xen-devel] [PATCH v4] xen PVonHVM: move shared_info to
 reserved memory area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 30.10.12 at 16:47, Olaf Hering  wrote:
> This is a respin of 00e37bdb0113a98408de42db85be002f21dbffd3
> ("xen PVonHVM: move shared_info to MMIO before kexec").
> 
> Currently kexec in a PVonHVM guest fails with a triple fault because the
> new kernel overwrites the shared info page. The exact failure depends on
> the size of the kernel image. This patch moves the pfn from RAM into an
> E820 reserved memory area.

One thing that occurred to me only now: How is this relocation
of the shared info going to help with the vCPU info placement?
You can't undo this, nor can you re-register these areas to be
put in a different location (of course, both of there could be
implemented in the hypervisor). Yet the hypervisor writes to
some of these areas' fields as much as it does write to the
shared info structure itself.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 16:14:22 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 16:14:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTES8-00013J-Td; Tue, 30 Oct 2012 16:14:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTES7-000139-0y
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 16:14:07 +0000
Received: from [85.158.139.83:59698] by server-3.bemta-5.messagelabs.com id
	4B/55-28618-ECCFF805; Tue, 30 Oct 2012 16:14:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1351613645!27993471!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21422 invoked from network); 30 Oct 2012 16:14:05 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-182.messagelabs.com with SMTP;
	30 Oct 2012 16:14:05 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 30 Oct 2012 16:14:05 +0000
Message-Id: <50900B1D02000078000A586C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 30 Oct 2012 16:15:09 +0000
From: "Jan Beulich" 
To: "Olaf Hering" 
References: <1351612057-21822-1-git-send-email-olaf@aepfle.de>
In-Reply-To: <1351612057-21822-1-git-send-email-olaf@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeremy Fitzhardinge ,
	Konrad Rzeszutek Wilk ,
	linux-kernel@vger.kernel.org, xen-devel 
Subject: Re: [Xen-devel] [PATCH v4] xen PVonHVM: move shared_info to
 reserved memory area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 30.10.12 at 16:47, Olaf Hering  wrote:
> This is a respin of 00e37bdb0113a98408de42db85be002f21dbffd3
> ("xen PVonHVM: move shared_info to MMIO before kexec").
> 
> Currently kexec in a PVonHVM guest fails with a triple fault because the
> new kernel overwrites the shared info page. The exact failure depends on
> the size of the kernel image. This patch moves the pfn from RAM into an
> E820 reserved memory area.

One thing that occurred to me only now: How is this relocation
of the shared info going to help with the vCPU info placement?
You can't undo this, nor can you re-register these areas to be
put in a different location (of course, both of there could be
implemented in the hypervisor). Yet the hypervisor writes to
some of these areas' fields as much as it does write to the
shared info structure itself.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 16:14:22 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 16:14:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTES9-00013Q-9B; Tue, 30 Oct 2012 16:14:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTES7-00013A-Eh
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 16:14:07 +0000
Received: from [85.158.143.35:14465] by server-3.bemta-4.messagelabs.com id
	FF/D7-24279-ECCFF805; Tue, 30 Oct 2012 16:14:06 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1351613628!5308604!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgzNjU3OA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24667 invoked from network); 30 Oct 2012 16:13:50 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Oct 2012 16:13:50 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9UGDcfK001409
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 30 Oct 2012 16:13:39 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9UGDaLg005346
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 30 Oct 2012 16:13:37 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9UGDa8v028233; Tue, 30 Oct 2012 11:13:36 -0500
MIME-Version: 1.0
Message-ID: <9a426fb3-cce3-49b0-8ac1-f8d1d4ba6e74@default>
Date: Tue, 30 Oct 2012 09:13:33 -0700 (PDT)
From: Dan Magenheimer 
To: George Dunlap 
References: <89c92e3f-8aeb-4c97-ab15-d282327f3a98@default>
	
	<806ef32a-2ded-42b5-a2ff-5f84ac1c1d47@default>
	
In-Reply-To: 
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Olaf Hering , Keir Fraser ,
	Ian Campbell ,
	Konrad Wilk , "Tim
	\(Xen.org\)" , George Shuklin ,
	xen-devel@lists.xen.org, Dario Faggioli ,
	Kurt Hackel ,
	Zhigang Wang ,
	Ian Jackson 
Subject: Re: [Xen-devel] Proposed new "memory capacity claim"
 hypercall/feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: George Dunlap [mailto:George.Dunlap@eu.citrix.com]
>    :
> No, it does not.
>    :
> No, it does not.
>    :
> We don't need this new hypercall.  You should just fix your own bugs
> rather than introducing new hacks to work around them.

Ouch.  I'm sorry if the previous discussion on this made you angry.
I wasn't sure if you were just absorbing the new information or
rejecting it or just too busy to reply, so decided to proceed with
a more specific proposal.  I wasn't intending to cut off the
discussion.

New paradigms and paradigm shifts always encounter resistance,
especially from those with a lot of investment in the old paradigm.

This "new" paradigm, tmem, has been in Xen for years now and the
final piece is now in upstream Linux as well.  Tmem is in many ways
a breakthrough in virtualized memory management, though admittedly
it is far from perfect (and, notably, will not help proprietary
or legacy guests).

I would hope you, as release manager, would either try to understand
the different paradigm or at least accept that there are different
paradigms than yours that can co-exist in an open source project.

To answer some of your points:

Dynamic handling of memory management is not a bug.  And selfballooning
is only a small (though important) part of the tmem story.  And
the Oracle "toolstack" manages hundreds of physical machines and
thousands of virtual machines across a physical network, not one
physical machine with a handful of virtual machines across Xenbus.
So we come from different perspectives.

As repeatedly pointed out (and confirmed by others), variations
of the memory "race" problem exist even without tmem.  I do agree
that if a toolstack insists that only it, the toolstack, can ever
allocate or free memory, the problem goes away.  You think that
restriction is reasonable, and I think it is not.

The "claim" proposal is very simple and (as far as I can tell so far)
shouldn't interfere with your paradigm.  Reinforcing your paradigm
by rejecting the proposal only cripples my paradigm.  Please ensure
you don't reject a proposal simply because you have a different
worldview.

Thanks,
Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 16:14:22 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 16:14:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTES9-00013Q-9B; Tue, 30 Oct 2012 16:14:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTES7-00013A-Eh
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 16:14:07 +0000
Received: from [85.158.143.35:14465] by server-3.bemta-4.messagelabs.com id
	FF/D7-24279-ECCFF805; Tue, 30 Oct 2012 16:14:06 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1351613628!5308604!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgzNjU3OA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24667 invoked from network); 30 Oct 2012 16:13:50 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Oct 2012 16:13:50 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9UGDcfK001409
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 30 Oct 2012 16:13:39 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9UGDaLg005346
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 30 Oct 2012 16:13:37 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9UGDa8v028233; Tue, 30 Oct 2012 11:13:36 -0500
MIME-Version: 1.0
Message-ID: <9a426fb3-cce3-49b0-8ac1-f8d1d4ba6e74@default>
Date: Tue, 30 Oct 2012 09:13:33 -0700 (PDT)
From: Dan Magenheimer 
To: George Dunlap 
References: <89c92e3f-8aeb-4c97-ab15-d282327f3a98@default>
	
	<806ef32a-2ded-42b5-a2ff-5f84ac1c1d47@default>
	
In-Reply-To: 
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Olaf Hering , Keir Fraser ,
	Ian Campbell ,
	Konrad Wilk , "Tim
	\(Xen.org\)" , George Shuklin ,
	xen-devel@lists.xen.org, Dario Faggioli ,
	Kurt Hackel ,
	Zhigang Wang ,
	Ian Jackson 
Subject: Re: [Xen-devel] Proposed new "memory capacity claim"
 hypercall/feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: George Dunlap [mailto:George.Dunlap@eu.citrix.com]
>    :
> No, it does not.
>    :
> No, it does not.
>    :
> We don't need this new hypercall.  You should just fix your own bugs
> rather than introducing new hacks to work around them.

Ouch.  I'm sorry if the previous discussion on this made you angry.
I wasn't sure if you were just absorbing the new information or
rejecting it or just too busy to reply, so decided to proceed with
a more specific proposal.  I wasn't intending to cut off the
discussion.

New paradigms and paradigm shifts always encounter resistance,
especially from those with a lot of investment in the old paradigm.

This "new" paradigm, tmem, has been in Xen for years now and the
final piece is now in upstream Linux as well.  Tmem is in many ways
a breakthrough in virtualized memory management, though admittedly
it is far from perfect (and, notably, will not help proprietary
or legacy guests).

I would hope you, as release manager, would either try to understand
the different paradigm or at least accept that there are different
paradigms than yours that can co-exist in an open source project.

To answer some of your points:

Dynamic handling of memory management is not a bug.  And selfballooning
is only a small (though important) part of the tmem story.  And
the Oracle "toolstack" manages hundreds of physical machines and
thousands of virtual machines across a physical network, not one
physical machine with a handful of virtual machines across Xenbus.
So we come from different perspectives.

As repeatedly pointed out (and confirmed by others), variations
of the memory "race" problem exist even without tmem.  I do agree
that if a toolstack insists that only it, the toolstack, can ever
allocate or free memory, the problem goes away.  You think that
restriction is reasonable, and I think it is not.

The "claim" proposal is very simple and (as far as I can tell so far)
shouldn't interfere with your paradigm.  Reinforcing your paradigm
by rejecting the proposal only cripples my paradigm.  Please ensure
you don't reject a proposal simply because you have a different
worldview.

Thanks,
Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 16:34:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 16:34:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTEkp-0001Yc-2i; Tue, 30 Oct 2012 16:33:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTEkn-0001YX-PJ
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 16:33:26 +0000
Received: from [85.158.139.83:19432] by server-5.bemta-5.messagelabs.com id
	DB/B2-09732-45100905; Tue, 30 Oct 2012 16:33:24 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1351614803!27724376!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14863 invoked from network); 30 Oct 2012 16:33:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 16:33:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,680,1344211200"; d="scan'208";a="15495449"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 16:32:30 +0000
Received: from [192.168.1.30] (10.31.3.235) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 30 Oct 2012 16:32:29 +0000
Message-ID: <5090011D.9080406@citrix.com>
Date: Tue, 30 Oct 2012 17:32:29 +0100
From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: Ian Jackson 
References: <1351588958-75040-1-git-send-email-roger.pau@citrix.com>
	<20623.60420.97632.890498@mariner.uk.xensource.com>
In-Reply-To: <20623.60420.97632.890498@mariner.uk.xensource.com>
Cc: Christoph Egger ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 1/2] autoconf: check for wget and ftp
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 30/10/12 16:02, Ian Jackson wrote:
> Roger Pau Monne writes ("[Xen-devel] [PATCH 1/2] autoconf: check for wget and ftp"):
>> Some OSes don't come with wget by default, so ftp should be choosen
>> on those. Add an autoconf check to check for wget and ftp, and
>> replace the usage of hardcoded wget in tools.
> 
> I don't think this can be right; wget is used in many more places.  At
> the very least it looks like it will break the stubdom build since
> that is full of WGET.  Did you grep for WGET ?

Does stubdom build import config/Tools.mk? I thought it was only used to
build the tools directory. If that's the case I don't think it will
break anything, since we define a new variable $FETCHER, that shouldn't
be used anywhere else, so the rest will continue to use the hardcoded
wget, or whatever it was using prior to this patch.

> Does "ftp -o blah.tar.gz http://xenbits.xen.org/xen-extfiles/blah.tar.gz"
> really work on NetBSD and download to the local file "blah.tar.gz" ?

Yes.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 16:34:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 16:34:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTEkp-0001Yc-2i; Tue, 30 Oct 2012 16:33:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTEkn-0001YX-PJ
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 16:33:26 +0000
Received: from [85.158.139.83:19432] by server-5.bemta-5.messagelabs.com id
	DB/B2-09732-45100905; Tue, 30 Oct 2012 16:33:24 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1351614803!27724376!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14863 invoked from network); 30 Oct 2012 16:33:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 16:33:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,680,1344211200"; d="scan'208";a="15495449"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 16:32:30 +0000
Received: from [192.168.1.30] (10.31.3.235) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 30 Oct 2012 16:32:29 +0000
Message-ID: <5090011D.9080406@citrix.com>
Date: Tue, 30 Oct 2012 17:32:29 +0100
From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: Ian Jackson 
References: <1351588958-75040-1-git-send-email-roger.pau@citrix.com>
	<20623.60420.97632.890498@mariner.uk.xensource.com>
In-Reply-To: <20623.60420.97632.890498@mariner.uk.xensource.com>
Cc: Christoph Egger ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 1/2] autoconf: check for wget and ftp
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 30/10/12 16:02, Ian Jackson wrote:
> Roger Pau Monne writes ("[Xen-devel] [PATCH 1/2] autoconf: check for wget and ftp"):
>> Some OSes don't come with wget by default, so ftp should be choosen
>> on those. Add an autoconf check to check for wget and ftp, and
>> replace the usage of hardcoded wget in tools.
> 
> I don't think this can be right; wget is used in many more places.  At
> the very least it looks like it will break the stubdom build since
> that is full of WGET.  Did you grep for WGET ?

Does stubdom build import config/Tools.mk? I thought it was only used to
build the tools directory. If that's the case I don't think it will
break anything, since we define a new variable $FETCHER, that shouldn't
be used anywhere else, so the rest will continue to use the hardcoded
wget, or whatever it was using prior to this patch.

> Does "ftp -o blah.tar.gz http://xenbits.xen.org/xen-extfiles/blah.tar.gz"
> really work on NetBSD and download to the local file "blah.tar.gz" ?

Yes.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 16:34:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 16:34:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTEl4-0001ZA-FB; Tue, 30 Oct 2012 16:33:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTEl3-0001Z5-8y
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 16:33:41 +0000
Received: from [85.158.143.35:37047] by server-2.bemta-4.messagelabs.com id
	55/93-22268-46100905; Tue, 30 Oct 2012 16:33:40 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1351614816!5311448!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNzI0Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2903 invoked from network); 30 Oct 2012 16:33:38 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Oct 2012 16:33:38 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9UGXKIT020925
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 30 Oct 2012 16:33:21 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9UGXJ4i029743
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 30 Oct 2012 16:33:20 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9UGXJhi011745; Tue, 30 Oct 2012 11:33:19 -0500
MIME-Version: 1.0
Message-ID: 
Date: Tue, 30 Oct 2012 09:33:16 -0700 (PDT)
From: Dan Magenheimer 
To: Keir Fraser , Jan Beulich 
References: <234774e0-45d5-4a4e-99f1-4e4c3eaee615@default>
	
In-Reply-To: 
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Olaf Hering , Ian Campbell ,
	Konrad Wilk ,
	George Dunlap ,
	George Shuklin ,
	"Tim \(Xen.org\)" , xen-devel@lists.xen.org,
	Dario Faggioli , Kurt Hackel ,
	Zhigang Wang ,
	Ian Jackson 
Subject: Re: [Xen-devel] Proposed new "memory capacity claim"
	hypercall/feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Keir Fraser [mailto:keir.xen@gmail.com]
> Subject: Re: Proposed new "memory capacity claim" hypercall/feature
> 
> On 30/10/2012 16:13, "Dan Magenheimer"  wrote:
> 
> >> Okay, so why is tmem incompatible with implementing claims in the toolstack?
> >
> > (Hmmm... maybe I could schedule the equivalent of a PhD qual exam
> > for tmem with all the core Xen developers as examiners?)
> >
> > The short answer is tmem moves memory capacity around far too
> > frequently to be managed by a userland toolstack, especially if
> > the "controller" lives on a central "manager machine" in a
> > data center (Oracle's model).  The ebb and flow of memory supply
> > and demand for each guest is instead managed entirely dynamically.
> 
> I don't know. I agree that fine-grained memory management is the duty of the
> hypervisor, but it seems to me that the toolstack should be able to handle
> admission control. It knows how much memory each existing guest is allowed
> to consume at max,
>   !!!!!!!!!!!how much memory the new guest requires!!!!!!!!!!
> how much memory
> the system has total... Isn't the decision then simple?

A fundamental assumption of tmem is that _nobody_ knows how much memory
a guest requires, not even the OS kernel running in the guest.  If you
have a toolstack that does know, please submit a paper to OSDI. ;-)
If you have a toolstack that can do it for thousands of guests across
hundreds of machines, please start up a company and allow me to invest. ;-)

One way to think of tmem is as a huge co-feedback loop that estimates
memory demand and deals effectively with the consequences of the (always
wrong) estimate using very fine-grained adjustments AND mechanisms that
allow maximum flexibility between guest memory demands while minimizing
impact on the running guests.

> Tmem should be fairly invisible to the toolstack, right?

It can be invisible, as long as the toolstack doesn't either make
the assumption that it controls every page allocated/freed by the
hypervisor or make the assumption that a large allocation can be
completed atomically.  The first of those assumptions is what is
generating all the controversy (George's worldview) and the second
is the problem I am trying to solve with the "claim" hypercall/subop.
And I'd like to solve it in a way that handles both tmem and non-tmem.

Thanks,
Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 16:34:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 16:34:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTEl4-0001ZA-FB; Tue, 30 Oct 2012 16:33:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTEl3-0001Z5-8y
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 16:33:41 +0000
Received: from [85.158.143.35:37047] by server-2.bemta-4.messagelabs.com id
	55/93-22268-46100905; Tue, 30 Oct 2012 16:33:40 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1351614816!5311448!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNzI0Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2903 invoked from network); 30 Oct 2012 16:33:38 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Oct 2012 16:33:38 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9UGXKIT020925
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 30 Oct 2012 16:33:21 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9UGXJ4i029743
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 30 Oct 2012 16:33:20 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9UGXJhi011745; Tue, 30 Oct 2012 11:33:19 -0500
MIME-Version: 1.0
Message-ID: 
Date: Tue, 30 Oct 2012 09:33:16 -0700 (PDT)
From: Dan Magenheimer 
To: Keir Fraser , Jan Beulich 
References: <234774e0-45d5-4a4e-99f1-4e4c3eaee615@default>
	
In-Reply-To: 
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Olaf Hering , Ian Campbell ,
	Konrad Wilk ,
	George Dunlap ,
	George Shuklin ,
	"Tim \(Xen.org\)" , xen-devel@lists.xen.org,
	Dario Faggioli , Kurt Hackel ,
	Zhigang Wang ,
	Ian Jackson 
Subject: Re: [Xen-devel] Proposed new "memory capacity claim"
	hypercall/feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Keir Fraser [mailto:keir.xen@gmail.com]
> Subject: Re: Proposed new "memory capacity claim" hypercall/feature
> 
> On 30/10/2012 16:13, "Dan Magenheimer"  wrote:
> 
> >> Okay, so why is tmem incompatible with implementing claims in the toolstack?
> >
> > (Hmmm... maybe I could schedule the equivalent of a PhD qual exam
> > for tmem with all the core Xen developers as examiners?)
> >
> > The short answer is tmem moves memory capacity around far too
> > frequently to be managed by a userland toolstack, especially if
> > the "controller" lives on a central "manager machine" in a
> > data center (Oracle's model).  The ebb and flow of memory supply
> > and demand for each guest is instead managed entirely dynamically.
> 
> I don't know. I agree that fine-grained memory management is the duty of the
> hypervisor, but it seems to me that the toolstack should be able to handle
> admission control. It knows how much memory each existing guest is allowed
> to consume at max,
>   !!!!!!!!!!!how much memory the new guest requires!!!!!!!!!!
> how much memory
> the system has total... Isn't the decision then simple?

A fundamental assumption of tmem is that _nobody_ knows how much memory
a guest requires, not even the OS kernel running in the guest.  If you
have a toolstack that does know, please submit a paper to OSDI. ;-)
If you have a toolstack that can do it for thousands of guests across
hundreds of machines, please start up a company and allow me to invest. ;-)

One way to think of tmem is as a huge co-feedback loop that estimates
memory demand and deals effectively with the consequences of the (always
wrong) estimate using very fine-grained adjustments AND mechanisms that
allow maximum flexibility between guest memory demands while minimizing
impact on the running guests.

> Tmem should be fairly invisible to the toolstack, right?

It can be invisible, as long as the toolstack doesn't either make
the assumption that it controls every page allocated/freed by the
hypervisor or make the assumption that a large allocation can be
completed atomically.  The first of those assumptions is what is
generating all the controversy (George's worldview) and the second
is the problem I am trying to solve with the "claim" hypercall/subop.
And I'd like to solve it in a way that handles both tmem and non-tmem.

Thanks,
Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 16:39:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 16:39:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTEqN-0001qQ-Bq; Tue, 30 Oct 2012 16:39:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTEqM-0001qI-29
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 16:39:10 +0000
Received: from [193.109.254.147:14196] by server-2.bemta-14.messagelabs.com id
	38/4C-19917-DA200905; Tue, 30 Oct 2012 16:39:09 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-27.messagelabs.com!1351614738!9015114!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MjQzMTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MjQzMTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21300 invoked from network); 30 Oct 2012 16:32:28 -0000
Received: from unknown (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Oct 2012 16:32:28 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr3c7sfw==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-064-007.pools.arcor-ip.net [84.57.64.7])
	by smtp.strato.de (josoe mo49) (RZmta 30.21 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id Y064cco9UFe8bE ;
	Tue, 30 Oct 2012 17:30:07 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id A523318643; Tue, 30 Oct 2012 17:30:06 +0100 (CET)
Date: Tue, 30 Oct 2012 17:30:06 +0100
From: Olaf Hering 
To: Jan Beulich 
Message-ID: <20121030163006.GA26404@aepfle.de>
References: <1351612057-21822-1-git-send-email-olaf@aepfle.de>
	<50900B1D02000078000A586C@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50900B1D02000078000A586C@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: Jeremy Fitzhardinge ,
	Konrad Rzeszutek Wilk ,
	linux-kernel@vger.kernel.org, xen-devel 
Subject: Re: [Xen-devel] [PATCH v4] xen PVonHVM: move shared_info to
 reserved memory area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 30, Jan Beulich wrote:

> >>> On 30.10.12 at 16:47, Olaf Hering  wrote:
> > This is a respin of 00e37bdb0113a98408de42db85be002f21dbffd3
> > ("xen PVonHVM: move shared_info to MMIO before kexec").
> > 
> > Currently kexec in a PVonHVM guest fails with a triple fault because the
> > new kernel overwrites the shared info page. The exact failure depends on
> > the size of the kernel image. This patch moves the pfn from RAM into an
> > E820 reserved memory area.
> 
> One thing that occurred to me only now: How is this relocation
> of the shared info going to help with the vCPU info placement?
> You can't undo this, nor can you re-register these areas to be
> put in a different location (of course, both of there could be
> implemented in the hypervisor). Yet the hypervisor writes to
> some of these areas' fields as much as it does write to the
> shared info structure itself.

Maybe the wording "move" is a bit misleading in this patch. 

A single "move" of the actual pfn happens during boot, that is when a
PVonHVM enabled guest kernel does the XENMAPSPACE_shared_info operation.
It moves the pfn of the shared info page from the location the hvmloader
initially configured to this new pfn (0xfffff -> 0xfe700).
Another relocation does not happen at runtime, AFAIK.

The "move" which this patch does is more a source level move in the
sense that RESERVE_BRK (which is somewhere in the middle of RAM) is not
used anymore. Instead a pfn in an E820_Reserved area is used, see
xen-unstable changeset 26108:79185dcdf558 "hvmloader: Reserve
FE700000-FE800000 in physical memory map for guest use."


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 16:39:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 16:39:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTEqN-0001qQ-Bq; Tue, 30 Oct 2012 16:39:11 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTEqM-0001qI-29
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 16:39:10 +0000
Received: from [193.109.254.147:14196] by server-2.bemta-14.messagelabs.com id
	38/4C-19917-DA200905; Tue, 30 Oct 2012 16:39:09 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-27.messagelabs.com!1351614738!9015114!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MjQzMTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MjQzMTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21300 invoked from network); 30 Oct 2012 16:32:28 -0000
Received: from unknown (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Oct 2012 16:32:28 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr3c7sfw==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-064-007.pools.arcor-ip.net [84.57.64.7])
	by smtp.strato.de (josoe mo49) (RZmta 30.21 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id Y064cco9UFe8bE ;
	Tue, 30 Oct 2012 17:30:07 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id A523318643; Tue, 30 Oct 2012 17:30:06 +0100 (CET)
Date: Tue, 30 Oct 2012 17:30:06 +0100
From: Olaf Hering 
To: Jan Beulich 
Message-ID: <20121030163006.GA26404@aepfle.de>
References: <1351612057-21822-1-git-send-email-olaf@aepfle.de>
	<50900B1D02000078000A586C@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50900B1D02000078000A586C@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: Jeremy Fitzhardinge ,
	Konrad Rzeszutek Wilk ,
	linux-kernel@vger.kernel.org, xen-devel 
Subject: Re: [Xen-devel] [PATCH v4] xen PVonHVM: move shared_info to
 reserved memory area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 30, Jan Beulich wrote:

> >>> On 30.10.12 at 16:47, Olaf Hering  wrote:
> > This is a respin of 00e37bdb0113a98408de42db85be002f21dbffd3
> > ("xen PVonHVM: move shared_info to MMIO before kexec").
> > 
> > Currently kexec in a PVonHVM guest fails with a triple fault because the
> > new kernel overwrites the shared info page. The exact failure depends on
> > the size of the kernel image. This patch moves the pfn from RAM into an
> > E820 reserved memory area.
> 
> One thing that occurred to me only now: How is this relocation
> of the shared info going to help with the vCPU info placement?
> You can't undo this, nor can you re-register these areas to be
> put in a different location (of course, both of there could be
> implemented in the hypervisor). Yet the hypervisor writes to
> some of these areas' fields as much as it does write to the
> shared info structure itself.

Maybe the wording "move" is a bit misleading in this patch. 

A single "move" of the actual pfn happens during boot, that is when a
PVonHVM enabled guest kernel does the XENMAPSPACE_shared_info operation.
It moves the pfn of the shared info page from the location the hvmloader
initially configured to this new pfn (0xfffff -> 0xfe700).
Another relocation does not happen at runtime, AFAIK.

The "move" which this patch does is more a source level move in the
sense that RESERVE_BRK (which is somewhere in the middle of RAM) is not
used anymore. Instead a pfn in an E820_Reserved area is used, see
xen-unstable changeset 26108:79185dcdf558 "hvmloader: Reserve
FE700000-FE800000 in physical memory map for guest use."


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 16:40:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 16:40:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTErE-0001tN-Q0; Tue, 30 Oct 2012 16:40:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTErD-0001sz-4T
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 16:40:03 +0000
Received: from [85.158.139.211:47503] by server-5.bemta-5.messagelabs.com id
	C5/7D-09732-0E200905; Tue, 30 Oct 2012 16:40:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1351615198!18232635!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19816 invoked from network); 30 Oct 2012 16:39:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 16:39:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,680,1344211200"; d="scan'208";a="15495602"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 16:39:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 30 Oct 2012 16:39:58 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TTEr8-0000sq-8n;
	Tue, 30 Oct 2012 16:39:58 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TTEr8-0008PL-80;
	Tue, 30 Oct 2012 16:39:58 +0000
To: 
Message-ID: 
From: xen.org 
Date: Tue, 30 Oct 2012 16:39:58 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 14157: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14157 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14157/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-pvops             4 kernel-build              fail REGR. vs. 14073
 build-i386-pvops              4 kernel-build              fail REGR. vs. 14073

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 linux                d9ee258b13506301b6da6450cf7a1692826b471e
baseline version:
 linux                9fc71703e9baa5b5174a72c053ae1ca736df2d42

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             fail    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit d9ee258b13506301b6da6450cf7a1692826b471e
Author: Greg Kroah-Hartman 
Date:   Sun Oct 28 10:03:00 2012 -0700

    Linux 3.0.49

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 16:40:24 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 16:40:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTErE-0001tN-Q0; Tue, 30 Oct 2012 16:40:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTErD-0001sz-4T
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 16:40:03 +0000
Received: from [85.158.139.211:47503] by server-5.bemta-5.messagelabs.com id
	C5/7D-09732-0E200905; Tue, 30 Oct 2012 16:40:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1351615198!18232635!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19816 invoked from network); 30 Oct 2012 16:39:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 16:39:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,680,1344211200"; d="scan'208";a="15495602"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 16:39:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 30 Oct 2012 16:39:58 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TTEr8-0000sq-8n;
	Tue, 30 Oct 2012 16:39:58 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TTEr8-0008PL-80;
	Tue, 30 Oct 2012 16:39:58 +0000
To: 
Message-ID: 
From: xen.org 
Date: Tue, 30 Oct 2012 16:39:58 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 14157: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14157 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14157/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-pvops             4 kernel-build              fail REGR. vs. 14073
 build-i386-pvops              4 kernel-build              fail REGR. vs. 14073

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 linux                d9ee258b13506301b6da6450cf7a1692826b471e
baseline version:
 linux                9fc71703e9baa5b5174a72c053ae1ca736df2d42

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             fail    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit d9ee258b13506301b6da6450cf7a1692826b471e
Author: Greg Kroah-Hartman 
Date:   Sun Oct 28 10:03:00 2012 -0700

    Linux 3.0.49

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 16:45:28 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 16:45:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTEvc-0002F8-MU; Tue, 30 Oct 2012 16:44:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTEvb-0002F3-II
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 16:44:35 +0000
Received: from [85.158.139.211:26113] by server-16.bemta-5.messagelabs.com id
	99/2B-04786-2F300905; Tue, 30 Oct 2012 16:44:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1351615473!18278578!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15654 invoked from network); 30 Oct 2012 16:44:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-206.messagelabs.com with SMTP;
	30 Oct 2012 16:44:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 30 Oct 2012 16:44:33 +0000
Message-Id: <5090124C02000078000A58AC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 30 Oct 2012 16:45:48 +0000
From: "Jan Beulich" 
To: "Olaf Hering" 
References: <1351612057-21822-1-git-send-email-olaf@aepfle.de>
	<50900B1D02000078000A586C@nat28.tlf.novell.com>
	<20121030163006.GA26404@aepfle.de>
In-Reply-To: <20121030163006.GA26404@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeremy Fitzhardinge ,
	Konrad Rzeszutek Wilk ,
	linux-kernel@vger.kernel.org, xen-devel 
Subject: Re: [Xen-devel] [PATCH v4] xen PVonHVM: move shared_info to
 reserved memory area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 30.10.12 at 17:30, Olaf Hering  wrote:
> On Tue, Oct 30, Jan Beulich wrote:
> 
>> >>> On 30.10.12 at 16:47, Olaf Hering  wrote:
>> > This is a respin of 00e37bdb0113a98408de42db85be002f21dbffd3
>> > ("xen PVonHVM: move shared_info to MMIO before kexec").
>> > 
>> > Currently kexec in a PVonHVM guest fails with a triple fault because the
>> > new kernel overwrites the shared info page. The exact failure depends on
>> > the size of the kernel image. This patch moves the pfn from RAM into an
>> > E820 reserved memory area.
>> 
>> One thing that occurred to me only now: How is this relocation
>> of the shared info going to help with the vCPU info placement?
>> You can't undo this, nor can you re-register these areas to be
>> put in a different location (of course, both of there could be
>> implemented in the hypervisor). Yet the hypervisor writes to
>> some of these areas' fields as much as it does write to the
>> shared info structure itself.
> 
> Maybe the wording "move" is a bit misleading in this patch. 
> 
> A single "move" of the actual pfn happens during boot, that is when a
> PVonHVM enabled guest kernel does the XENMAPSPACE_shared_info operation.
> It moves the pfn of the shared info page from the location the hvmloader
> initially configured to this new pfn (0xfffff -> 0xfe700).
> Another relocation does not happen at runtime, AFAIK.
> 
> The "move" which this patch does is more a source level move in the
> sense that RESERVE_BRK (which is somewhere in the middle of RAM) is not
> used anymore. Instead a pfn in an E820_Reserved area is used, see
> xen-unstable changeset 26108:79185dcdf558 "hvmloader: Reserve
> FE700000-FE800000 in physical memory map for guest use."

And iirc you're doing this relocation because otherwise the newly
booting kernel image may get overwritten at an (from its
perspective) arbitrary location. What I'm trying to point out is
that the shared info structure is not the only thing (potentially)
inside the kernel image that might get overwritten - the relocated
(by the old kernel) vCPU info may as well. Plus I think the new
kernel has no way of relocating it a second time (including back
into the shared info structure) with how the hypervisor works at
present.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 16:45:28 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 16:45:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTEvc-0002F8-MU; Tue, 30 Oct 2012 16:44:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTEvb-0002F3-II
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 16:44:35 +0000
Received: from [85.158.139.211:26113] by server-16.bemta-5.messagelabs.com id
	99/2B-04786-2F300905; Tue, 30 Oct 2012 16:44:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1351615473!18278578!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15654 invoked from network); 30 Oct 2012 16:44:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-206.messagelabs.com with SMTP;
	30 Oct 2012 16:44:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 30 Oct 2012 16:44:33 +0000
Message-Id: <5090124C02000078000A58AC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 30 Oct 2012 16:45:48 +0000
From: "Jan Beulich" 
To: "Olaf Hering" 
References: <1351612057-21822-1-git-send-email-olaf@aepfle.de>
	<50900B1D02000078000A586C@nat28.tlf.novell.com>
	<20121030163006.GA26404@aepfle.de>
In-Reply-To: <20121030163006.GA26404@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeremy Fitzhardinge ,
	Konrad Rzeszutek Wilk ,
	linux-kernel@vger.kernel.org, xen-devel 
Subject: Re: [Xen-devel] [PATCH v4] xen PVonHVM: move shared_info to
 reserved memory area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 30.10.12 at 17:30, Olaf Hering  wrote:
> On Tue, Oct 30, Jan Beulich wrote:
> 
>> >>> On 30.10.12 at 16:47, Olaf Hering  wrote:
>> > This is a respin of 00e37bdb0113a98408de42db85be002f21dbffd3
>> > ("xen PVonHVM: move shared_info to MMIO before kexec").
>> > 
>> > Currently kexec in a PVonHVM guest fails with a triple fault because the
>> > new kernel overwrites the shared info page. The exact failure depends on
>> > the size of the kernel image. This patch moves the pfn from RAM into an
>> > E820 reserved memory area.
>> 
>> One thing that occurred to me only now: How is this relocation
>> of the shared info going to help with the vCPU info placement?
>> You can't undo this, nor can you re-register these areas to be
>> put in a different location (of course, both of there could be
>> implemented in the hypervisor). Yet the hypervisor writes to
>> some of these areas' fields as much as it does write to the
>> shared info structure itself.
> 
> Maybe the wording "move" is a bit misleading in this patch. 
> 
> A single "move" of the actual pfn happens during boot, that is when a
> PVonHVM enabled guest kernel does the XENMAPSPACE_shared_info operation.
> It moves the pfn of the shared info page from the location the hvmloader
> initially configured to this new pfn (0xfffff -> 0xfe700).
> Another relocation does not happen at runtime, AFAIK.
> 
> The "move" which this patch does is more a source level move in the
> sense that RESERVE_BRK (which is somewhere in the middle of RAM) is not
> used anymore. Instead a pfn in an E820_Reserved area is used, see
> xen-unstable changeset 26108:79185dcdf558 "hvmloader: Reserve
> FE700000-FE800000 in physical memory map for guest use."

And iirc you're doing this relocation because otherwise the newly
booting kernel image may get overwritten at an (from its
perspective) arbitrary location. What I'm trying to point out is
that the shared info structure is not the only thing (potentially)
inside the kernel image that might get overwritten - the relocated
(by the old kernel) vCPU info may as well. Plus I think the new
kernel has no way of relocating it a second time (including back
into the shared info structure) with how the hypervisor works at
present.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 17:04:40 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 17:04:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTFE2-0002h6-F4; Tue, 30 Oct 2012 17:03:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTFE1-0002h1-0F
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 17:03:37 +0000
Received: from [85.158.139.83:25295] by server-10.bemta-5.messagelabs.com id
	24/88-01025-86800905; Tue, 30 Oct 2012 17:03:36 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-182.messagelabs.com!1351616615!28034351!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NjU2MTU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NjU2MTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9860 invoked from network); 30 Oct 2012 17:03:35 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Oct 2012 17:03:35 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr3c7sfw==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-064-007.pools.arcor-ip.net [84.57.64.7])
	by smtp.strato.de (joses mo23) (RZmta 30.21 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id I00869o9UGUj8T ;
	Tue, 30 Oct 2012 18:03:22 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 1300D18643; Tue, 30 Oct 2012 18:03:21 +0100 (CET)
Date: Tue, 30 Oct 2012 18:03:21 +0100
From: Olaf Hering 
To: Jan Beulich 
Message-ID: <20121030170321.GA1251@aepfle.de>
References: <1351612057-21822-1-git-send-email-olaf@aepfle.de>
	<50900B1D02000078000A586C@nat28.tlf.novell.com>
	<20121030163006.GA26404@aepfle.de>
	<5090124C02000078000A58AC@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5090124C02000078000A58AC@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: Jeremy Fitzhardinge ,
	Konrad Rzeszutek Wilk ,
	linux-kernel@vger.kernel.org, xen-devel 
Subject: Re: [Xen-devel] [PATCH v4] xen PVonHVM: move shared_info to
 reserved memory area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 30, Jan Beulich wrote:

> And iirc you're doing this relocation because otherwise the newly
> booting kernel image may get overwritten at an (from its
> perspective) arbitrary location. What I'm trying to point out is
> that the shared info structure is not the only thing (potentially)
> inside the kernel image that might get overwritten - the relocated
> (by the old kernel) vCPU info may as well. Plus I think the new
> kernel has no way of relocating it a second time (including back
> into the shared info structure) with how the hypervisor works at
> present.

Thanks, I have not looked at this, nor was I aware of it until now.
I will see what needs to be done.

Is this also an issue with the xenlinux based PVonHVM code?


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 17:04:40 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 17:04:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTFE2-0002h6-F4; Tue, 30 Oct 2012 17:03:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTFE1-0002h1-0F
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 17:03:37 +0000
Received: from [85.158.139.83:25295] by server-10.bemta-5.messagelabs.com id
	24/88-01025-86800905; Tue, 30 Oct 2012 17:03:36 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-182.messagelabs.com!1351616615!28034351!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NjU2MTU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0NjU2MTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9860 invoked from network); 30 Oct 2012 17:03:35 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Oct 2012 17:03:35 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr3c7sfw==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-064-007.pools.arcor-ip.net [84.57.64.7])
	by smtp.strato.de (joses mo23) (RZmta 30.21 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id I00869o9UGUj8T ;
	Tue, 30 Oct 2012 18:03:22 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 1300D18643; Tue, 30 Oct 2012 18:03:21 +0100 (CET)
Date: Tue, 30 Oct 2012 18:03:21 +0100
From: Olaf Hering 
To: Jan Beulich 
Message-ID: <20121030170321.GA1251@aepfle.de>
References: <1351612057-21822-1-git-send-email-olaf@aepfle.de>
	<50900B1D02000078000A586C@nat28.tlf.novell.com>
	<20121030163006.GA26404@aepfle.de>
	<5090124C02000078000A58AC@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5090124C02000078000A58AC@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: Jeremy Fitzhardinge ,
	Konrad Rzeszutek Wilk ,
	linux-kernel@vger.kernel.org, xen-devel 
Subject: Re: [Xen-devel] [PATCH v4] xen PVonHVM: move shared_info to
 reserved memory area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 30, Jan Beulich wrote:

> And iirc you're doing this relocation because otherwise the newly
> booting kernel image may get overwritten at an (from its
> perspective) arbitrary location. What I'm trying to point out is
> that the shared info structure is not the only thing (potentially)
> inside the kernel image that might get overwritten - the relocated
> (by the old kernel) vCPU info may as well. Plus I think the new
> kernel has no way of relocating it a second time (including back
> into the shared info structure) with how the hypervisor works at
> present.

Thanks, I have not looked at this, nor was I aware of it until now.
I will see what needs to be done.

Is this also an issue with the xenlinux based PVonHVM code?


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 17:15:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 17:15:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTFOL-0002x9-JY; Tue, 30 Oct 2012 17:14:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTFOJ-0002x4-Rp
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 17:14:16 +0000
Received: from [193.109.254.147:51557] by server-10.bemta-14.messagelabs.com
	id 77/0D-31741-7EA00905; Tue, 30 Oct 2012 17:14:15 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1351617250!9000684!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gNTE1Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18631 invoked from network); 30 Oct 2012 17:14:11 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Oct 2012 17:14:11 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9UHDn33015154
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 30 Oct 2012 17:13:49 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9UHDmgu002368
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 30 Oct 2012 17:13:48 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9UHDlSd012296; Tue, 30 Oct 2012 12:13:47 -0500
MIME-Version: 1.0
Message-ID: 
Date: Tue, 30 Oct 2012 10:13:44 -0700 (PDT)
From: Dan Magenheimer 
To: Jan Beulich 
References: <60d00f38-98a3-4ec2-acbd-b49dafaada56@default>
	<20121029223555.GA24388@ocelot.phlegethon.org>
	
	<508F9DE902000078000A5565@nat28.tlf.novell.com>
	
	<509008A502000078000A584E@nat28.tlf.novell.com>
In-Reply-To: <509008A502000078000A584E@nat28.tlf.novell.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Tim Deegan , Olaf Hering ,
	"Keir\(Xen.org\)" , IanCampbell ,
	Konrad Wilk ,
	GeorgeDunlap ,
	IanJackson ,
	George Shuklin ,
	xen-devel@lists.xen.org, DarioFaggioli ,
	Kurt Hackel ,
	Zhigang Wang 
Subject: Re: [Xen-devel] Proposed new "memory capacity claim"
	hypercall/feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Subject: RE: Proposed new "memory capacity claim" hypercall/feature
> 
> >>> On 30.10.12 at 16:43, Dan Magenheimer  wrote:
> > With tmem, memory "owned" by domain (d.tot_pages) increases dynamically
> > in two ways: selfballooning and persistent puts (aka frontswap),
> > but is always capped by d.max_pages.  Neither of these communicate
> > to the toolstack.
> >
> > Similarly, tmem (or selfballooning) may be dynamically freeing up lots
> > of memory without communicating to the toolstack, which could result in
> > the toolstack rejecting a domain launch believing there is insufficient
> > memory.
> >
> > I am thinking the "claim" hypercall/subop eliminates these problems
> > and hope you agree!
> 
> With tmem being the odd one here, wouldn't it make more sense
> to force it into no-alloc mode (apparently not exactly the same as
> freezing all pools) for the (infrequent?) time periods of domain
> creation, thus not allowing the amount of free memory to drop
> unexpectedly? Tmem could, during these time periods, still itself
> internally recycle pages (e.g. fulfill a persistent put by discarding
> an ephemeral page).

Hi Jan --

Freeze has some unattractive issues that "claim" would solve
(see below) and freeze (whether ephemeral pages are used or not)
blocks allocations due to tmem, but doesn't block allocations due
to selfballooning (or manual ballooning attempts by a guest user
with root access).  I suppose the tmem freeze implementation could
be extended to also block all non-domain-creation ballooning
attempts but I'm not sure if that's what you are proposing.

To digress for a moment first, the original problem exists both in
non-tmem systems AND tmem systems.  It has been seen in the wild on
non-tmem systems.  I am involved with proposing a solution primarily
because, if the solution is designed correctly, it _also_ solves a
tmem problem.  (And as long as we have digressed, I believe it _also_
solves a page-sharing problem on non-tmem systems.)  That said,
here's the unattractive tmem freeze/thaw issue, first with
the existing freeze implementation.

Suppose you have a huge 256GB machine and you have already launched
a 64GB tmem guest "A".  The guest is idle for now, so slowly
selfballoons down to maybe 4GB.  You start to launch another 64GB
guest "B" which, as we know, is going to take some time to complete.
In the middle of launching "B", "A" suddenly gets very active and
needs to balloon up as quickly as possible or it can't balloon fast
enough (or at all if "frozen" as suggested) so starts swapping (and,
thanks to Linux frontswap, the swapping tries to go to hypervisor/tmem
memory).  But ballooning and tmem are both blocked and so the
guest swaps its poor little butt off even though there's >100GB
of free physical memory available.

Let's add in your suggestion, that a persistent put can be fulfilled
by discarding an ephemeral page.  I see two issues:  First, it
requires the number of ephemeral pages available to be larger
than the number of persistent pages required; this may not always
be true, though most of the time it will be true.  Second, the second
domain creation activity may have been assuming that it could use
some (or all) of the freeable pages, which have now been absorbed by
the first guest's persistent puts.  So I think "claim" is still
needed anyway.

Comments?

Thanks,
Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 17:15:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 17:15:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTFOL-0002x9-JY; Tue, 30 Oct 2012 17:14:17 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTFOJ-0002x4-Rp
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 17:14:16 +0000
Received: from [193.109.254.147:51557] by server-10.bemta-14.messagelabs.com
	id 77/0D-31741-7EA00905; Tue, 30 Oct 2012 17:14:15 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1351617250!9000684!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gNTE1Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18631 invoked from network); 30 Oct 2012 17:14:11 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Oct 2012 17:14:11 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9UHDn33015154
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 30 Oct 2012 17:13:49 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9UHDmgu002368
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 30 Oct 2012 17:13:48 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9UHDlSd012296; Tue, 30 Oct 2012 12:13:47 -0500
MIME-Version: 1.0
Message-ID: 
Date: Tue, 30 Oct 2012 10:13:44 -0700 (PDT)
From: Dan Magenheimer 
To: Jan Beulich 
References: <60d00f38-98a3-4ec2-acbd-b49dafaada56@default>
	<20121029223555.GA24388@ocelot.phlegethon.org>
	
	<508F9DE902000078000A5565@nat28.tlf.novell.com>
	
	<509008A502000078000A584E@nat28.tlf.novell.com>
In-Reply-To: <509008A502000078000A584E@nat28.tlf.novell.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Tim Deegan , Olaf Hering ,
	"Keir\(Xen.org\)" , IanCampbell ,
	Konrad Wilk ,
	GeorgeDunlap ,
	IanJackson ,
	George Shuklin ,
	xen-devel@lists.xen.org, DarioFaggioli ,
	Kurt Hackel ,
	Zhigang Wang 
Subject: Re: [Xen-devel] Proposed new "memory capacity claim"
	hypercall/feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Subject: RE: Proposed new "memory capacity claim" hypercall/feature
> 
> >>> On 30.10.12 at 16:43, Dan Magenheimer  wrote:
> > With tmem, memory "owned" by domain (d.tot_pages) increases dynamically
> > in two ways: selfballooning and persistent puts (aka frontswap),
> > but is always capped by d.max_pages.  Neither of these communicate
> > to the toolstack.
> >
> > Similarly, tmem (or selfballooning) may be dynamically freeing up lots
> > of memory without communicating to the toolstack, which could result in
> > the toolstack rejecting a domain launch believing there is insufficient
> > memory.
> >
> > I am thinking the "claim" hypercall/subop eliminates these problems
> > and hope you agree!
> 
> With tmem being the odd one here, wouldn't it make more sense
> to force it into no-alloc mode (apparently not exactly the same as
> freezing all pools) for the (infrequent?) time periods of domain
> creation, thus not allowing the amount of free memory to drop
> unexpectedly? Tmem could, during these time periods, still itself
> internally recycle pages (e.g. fulfill a persistent put by discarding
> an ephemeral page).

Hi Jan --

Freeze has some unattractive issues that "claim" would solve
(see below) and freeze (whether ephemeral pages are used or not)
blocks allocations due to tmem, but doesn't block allocations due
to selfballooning (or manual ballooning attempts by a guest user
with root access).  I suppose the tmem freeze implementation could
be extended to also block all non-domain-creation ballooning
attempts but I'm not sure if that's what you are proposing.

To digress for a moment first, the original problem exists both in
non-tmem systems AND tmem systems.  It has been seen in the wild on
non-tmem systems.  I am involved with proposing a solution primarily
because, if the solution is designed correctly, it _also_ solves a
tmem problem.  (And as long as we have digressed, I believe it _also_
solves a page-sharing problem on non-tmem systems.)  That said,
here's the unattractive tmem freeze/thaw issue, first with
the existing freeze implementation.

Suppose you have a huge 256GB machine and you have already launched
a 64GB tmem guest "A".  The guest is idle for now, so slowly
selfballoons down to maybe 4GB.  You start to launch another 64GB
guest "B" which, as we know, is going to take some time to complete.
In the middle of launching "B", "A" suddenly gets very active and
needs to balloon up as quickly as possible or it can't balloon fast
enough (or at all if "frozen" as suggested) so starts swapping (and,
thanks to Linux frontswap, the swapping tries to go to hypervisor/tmem
memory).  But ballooning and tmem are both blocked and so the
guest swaps its poor little butt off even though there's >100GB
of free physical memory available.

Let's add in your suggestion, that a persistent put can be fulfilled
by discarding an ephemeral page.  I see two issues:  First, it
requires the number of ephemeral pages available to be larger
than the number of persistent pages required; this may not always
be true, though most of the time it will be true.  Second, the second
domain creation activity may have been assuming that it could use
some (or all) of the freeable pages, which have now been absorbed by
the first guest's persistent puts.  So I think "claim" is still
needed anyway.

Comments?

Thanks,
Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 17:27:23 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 17:27:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTFah-0003D6-Sn; Tue, 30 Oct 2012 17:27:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTFag-0003D1-SB
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 17:27:02 +0000
Received: from [85.158.143.99:41768] by server-3.bemta-4.messagelabs.com id
	B0/4E-24279-6ED00905; Tue, 30 Oct 2012 17:27:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1351618021!27411274!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12319 invoked from network); 30 Oct 2012 17:27:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 17:27:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,680,1344211200"; d="scan'208";a="15496580"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 17:27:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 30 Oct 2012 17:27:00 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TTFaf-00018x-67; Tue, 30 Oct 2012 17:27:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TTFaf-0004El-2K;
	Tue, 30 Oct 2012 17:27:01 +0000
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20624.3556.953004.124652@mariner.uk.xensource.com>
Date: Tue, 30 Oct 2012 17:27:00 +0000
To: xen.org 
In-Reply-To: 
References: 
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [linux-3.0 test] 14157: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

xen.org writes ("[linux-3.0 test] 14157: regressions - FAIL"):
> flight 14157 linux-3.0 real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/14157/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-amd64-pvops             4 kernel-build          fail REGR. vs. 14073
>  build-i386-pvops              4 kernel-build          fail REGR. vs. 14073

Looks like git.kernel.org is down or very slow.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 17:27:23 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 17:27:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTFah-0003D6-Sn; Tue, 30 Oct 2012 17:27:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTFag-0003D1-SB
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 17:27:02 +0000
Received: from [85.158.143.99:41768] by server-3.bemta-4.messagelabs.com id
	B0/4E-24279-6ED00905; Tue, 30 Oct 2012 17:27:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1351618021!27411274!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12319 invoked from network); 30 Oct 2012 17:27:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 17:27:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,680,1344211200"; d="scan'208";a="15496580"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 17:27:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 30 Oct 2012 17:27:00 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TTFaf-00018x-67; Tue, 30 Oct 2012 17:27:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TTFaf-0004El-2K;
	Tue, 30 Oct 2012 17:27:01 +0000
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20624.3556.953004.124652@mariner.uk.xensource.com>
Date: Tue, 30 Oct 2012 17:27:00 +0000
To: xen.org 
In-Reply-To: 
References: 
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] [linux-3.0 test] 14157: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

xen.org writes ("[linux-3.0 test] 14157: regressions - FAIL"):
> flight 14157 linux-3.0 real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/14157/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-amd64-pvops             4 kernel-build          fail REGR. vs. 14073
>  build-i386-pvops              4 kernel-build          fail REGR. vs. 14073

Looks like git.kernel.org is down or very slow.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 17:33:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 17:33:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTFg8-0003RJ-Lv; Tue, 30 Oct 2012 17:32:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTFg7-0003RE-8T
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 17:32:39 +0000
Received: from [85.158.139.211:45763] by server-8.bemta-5.messagelabs.com id
	52/D8-23193-63F00905; Tue, 30 Oct 2012 17:32:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1351618357!18201710!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4886 invoked from network); 30 Oct 2012 17:32:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 17:32:38 -0000
X-IronPort-AV: E=Sophos;i="4.80,680,1344211200"; d="scan'208";a="15496677"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 17:32:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 30 Oct 2012 17:32:36 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TTFg5-0001E3-32; Tue, 30 Oct 2012 17:32:37 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TTFg4-0004FZ-U9;
	Tue, 30 Oct 2012 17:32:36 +0000
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20624.3892.618566.138065@mariner.uk.xensource.com>
Date: Tue, 30 Oct 2012 17:32:36 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= 
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <5090011D.9080406@citrix.com>
References: <1351588958-75040-1-git-send-email-roger.pau@citrix.com>
	<20623.60420.97632.890498@mariner.uk.xensource.com>
	<5090011D.9080406@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Christoph Egger ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 1/2] autoconf: check for wget and ftp
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH 1/2] autoconf: check for =
wget and ftp"):
> On 30/10/12 16:02, Ian Jackson wrote:
> > I don't think this can be right; wget is used in many more places.  At
> > the very least it looks like it will break the stubdom build since
> > that is full of WGET.  Did you grep for WGET ?
> =

> Does stubdom build import config/Tools.mk? I thought it was only used to
> build the tools directory. If that's the case I don't think it will
> break anything, since we define a new variable $FETCHER, that shouldn't
> be used anywhere else, so the rest will continue to use the hardcoded
> wget, or whatever it was using prior to this patch.

Err, yes, it seems stubdom/Makefile has its own definition of wget.
But stubdom builds are still going to be broken without wget then ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 17:33:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 17:33:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTFg8-0003RJ-Lv; Tue, 30 Oct 2012 17:32:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTFg7-0003RE-8T
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 17:32:39 +0000
Received: from [85.158.139.211:45763] by server-8.bemta-5.messagelabs.com id
	52/D8-23193-63F00905; Tue, 30 Oct 2012 17:32:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1351618357!18201710!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4886 invoked from network); 30 Oct 2012 17:32:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 17:32:38 -0000
X-IronPort-AV: E=Sophos;i="4.80,680,1344211200"; d="scan'208";a="15496677"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 17:32:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 30 Oct 2012 17:32:36 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TTFg5-0001E3-32; Tue, 30 Oct 2012 17:32:37 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TTFg4-0004FZ-U9;
	Tue, 30 Oct 2012 17:32:36 +0000
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20624.3892.618566.138065@mariner.uk.xensource.com>
Date: Tue, 30 Oct 2012 17:32:36 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= 
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <5090011D.9080406@citrix.com>
References: <1351588958-75040-1-git-send-email-roger.pau@citrix.com>
	<20623.60420.97632.890498@mariner.uk.xensource.com>
	<5090011D.9080406@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Christoph Egger ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 1/2] autoconf: check for wget and ftp
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH 1/2] autoconf: check for =
wget and ftp"):
> On 30/10/12 16:02, Ian Jackson wrote:
> > I don't think this can be right; wget is used in many more places.  At
> > the very least it looks like it will break the stubdom build since
> > that is full of WGET.  Did you grep for WGET ?
> =

> Does stubdom build import config/Tools.mk? I thought it was only used to
> build the tools directory. If that's the case I don't think it will
> break anything, since we define a new variable $FETCHER, that shouldn't
> be used anywhere else, so the rest will continue to use the hardcoded
> wget, or whatever it was using prior to this patch.

Err, yes, it seems stubdom/Makefile has its own definition of wget.
But stubdom builds are still going to be broken without wget then ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 17:38:06 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 17:38:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTFkU-0003bH-H5; Tue, 30 Oct 2012 17:37:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTFkS-0003aU-A7
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 17:37:08 +0000
Received: from [85.158.139.211:15432] by server-8.bemta-5.messagelabs.com id
	9A/7E-23193-34010905; Tue, 30 Oct 2012 17:37:07 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1351618625!18202208!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gNTE1Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15416 invoked from network); 30 Oct 2012 17:37:06 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Oct 2012 17:37:06 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9UHb0To003291
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 30 Oct 2012 17:37:01 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9UHax0j010646
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 30 Oct 2012 17:37:00 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9UHaxSd017390; Tue, 30 Oct 2012 12:36:59 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 30 Oct 2012 10:36:59 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 133B8403C7; Tue, 30 Oct 2012 13:23:52 -0400 (EDT)
Date: Tue, 30 Oct 2012 13:23:52 -0400
From: Konrad Rzeszutek Wilk 
To: Eric Dumazet 
Message-ID: <20121030172352.GA31997@phenom.dumpdata.com>
References: <1351078936-14159-1-git-send-email-ian.campbell@citrix.com>
	<1351081703.6537.99.camel@edumazet-glaptop>
	<1351084618.18035.27.camel@zakaz.uk.xensource.com>
	<1351085403.6537.102.camel@edumazet-glaptop>
	<1351087326.18035.50.camel@zakaz.uk.xensource.com>
	<1351092068.6537.107.camel@edumazet-glaptop>
	<1351095739.18035.83.camel@zakaz.uk.xensource.com>
	<1351097000.6537.109.camel@edumazet-glaptop>
	<20121030165309.GA30483@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20121030165309.GA30483@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "netdev@vger.kernel.org" ,
	Eric Dumazet , Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] net: allow configuration of the size of
 page in __netdev_alloc_frag
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 30, 2012 at 12:53:09PM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Oct 24, 2012 at 06:43:20PM +0200, Eric Dumazet wrote:
> > On Wed, 2012-10-24 at 17:22 +0100, Ian Campbell wrote:
> > > On Wed, 2012-10-24 at 16:21 +0100, Eric Dumazet wrote:
> > 
> > > > If you really have such problems, why locally generated TCP traffic
> > > > doesnt also have it ?
> > > 
> > > I think it does. The reason I noticed the original problem was that ssh
> > > to the machine was virtually (no pun intended) unusable.
> > > 
> > > > Your patch doesnt touch sk_page_frag_refill(), does it ?
> > > 
> > > That's right. It doesn't. When is (sk->sk_allocation & __GFP_WAIT) true?
> > > Is it possible I'm just not hitting that case?
> > > 
> > 
> > I hope not. GFP_KERNEL has __GFP_WAIT.
> > 
> > > Is it possible that this only affects certain traffic patterns (I only
> > > really tried ssh/scp and ping)? Or perhaps its just that the swiotlb is
> > > only broken in one corner case and not the other.
> > 
> > Could you try a netperf -t TCP_STREAM ?
> 
> For fun I did a couple of tests - I setup two machines (one r8168, the other
> e1000e) and tried to do netperf/netserver. Both of them are running a baremetal
> kernel and one of them has 'iommu=soft swiotlb=force' to simulate the worst
> case. This is using v3.7-rc3.

I also did a test with the patch at the top, with the same setup and ... it
does look like it fixes some issues, but not the underlaying one.

The same test, with net.core.netdev_frag_page_max_order=0, the e1000e->r8169
gets ~124, but then on subsequent runs it picks up to ~933. If I let the
machine stay a bit idle and then do this again, it does around ~124 again.

Thoughts?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 17:38:06 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 17:38:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTFkU-0003bH-H5; Tue, 30 Oct 2012 17:37:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTFkS-0003aU-A7
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 17:37:08 +0000
Received: from [85.158.139.211:15432] by server-8.bemta-5.messagelabs.com id
	9A/7E-23193-34010905; Tue, 30 Oct 2012 17:37:07 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1351618625!18202208!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gNTE1Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15416 invoked from network); 30 Oct 2012 17:37:06 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Oct 2012 17:37:06 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9UHb0To003291
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 30 Oct 2012 17:37:01 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9UHax0j010646
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 30 Oct 2012 17:37:00 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9UHaxSd017390; Tue, 30 Oct 2012 12:36:59 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 30 Oct 2012 10:36:59 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 133B8403C7; Tue, 30 Oct 2012 13:23:52 -0400 (EDT)
Date: Tue, 30 Oct 2012 13:23:52 -0400
From: Konrad Rzeszutek Wilk 
To: Eric Dumazet 
Message-ID: <20121030172352.GA31997@phenom.dumpdata.com>
References: <1351078936-14159-1-git-send-email-ian.campbell@citrix.com>
	<1351081703.6537.99.camel@edumazet-glaptop>
	<1351084618.18035.27.camel@zakaz.uk.xensource.com>
	<1351085403.6537.102.camel@edumazet-glaptop>
	<1351087326.18035.50.camel@zakaz.uk.xensource.com>
	<1351092068.6537.107.camel@edumazet-glaptop>
	<1351095739.18035.83.camel@zakaz.uk.xensource.com>
	<1351097000.6537.109.camel@edumazet-glaptop>
	<20121030165309.GA30483@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20121030165309.GA30483@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "netdev@vger.kernel.org" ,
	Eric Dumazet , Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] net: allow configuration of the size of
 page in __netdev_alloc_frag
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 30, 2012 at 12:53:09PM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Oct 24, 2012 at 06:43:20PM +0200, Eric Dumazet wrote:
> > On Wed, 2012-10-24 at 17:22 +0100, Ian Campbell wrote:
> > > On Wed, 2012-10-24 at 16:21 +0100, Eric Dumazet wrote:
> > 
> > > > If you really have such problems, why locally generated TCP traffic
> > > > doesnt also have it ?
> > > 
> > > I think it does. The reason I noticed the original problem was that ssh
> > > to the machine was virtually (no pun intended) unusable.
> > > 
> > > > Your patch doesnt touch sk_page_frag_refill(), does it ?
> > > 
> > > That's right. It doesn't. When is (sk->sk_allocation & __GFP_WAIT) true?
> > > Is it possible I'm just not hitting that case?
> > > 
> > 
> > I hope not. GFP_KERNEL has __GFP_WAIT.
> > 
> > > Is it possible that this only affects certain traffic patterns (I only
> > > really tried ssh/scp and ping)? Or perhaps its just that the swiotlb is
> > > only broken in one corner case and not the other.
> > 
> > Could you try a netperf -t TCP_STREAM ?
> 
> For fun I did a couple of tests - I setup two machines (one r8168, the other
> e1000e) and tried to do netperf/netserver. Both of them are running a baremetal
> kernel and one of them has 'iommu=soft swiotlb=force' to simulate the worst
> case. This is using v3.7-rc3.

I also did a test with the patch at the top, with the same setup and ... it
does look like it fixes some issues, but not the underlaying one.

The same test, with net.core.netdev_frag_page_max_order=0, the e1000e->r8169
gets ~124, but then on subsequent runs it picks up to ~933. If I let the
machine stay a bit idle and then do this again, it does around ~124 again.

Thoughts?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 17:38:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 17:38:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTFkQ-0003a6-Br; Tue, 30 Oct 2012 17:37:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTFkO-0003Zx-9b
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 17:37:04 +0000
Received: from [85.158.143.35:28188] by server-3.bemta-4.messagelabs.com id
	01/D7-24279-F3010905; Tue, 30 Oct 2012 17:37:03 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1351618621!10800344!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgzNjU3OA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11806 invoked from network); 30 Oct 2012 17:37:02 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Oct 2012 17:37:02 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9UHaxkS017176
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 30 Oct 2012 17:37:00 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9UHaw0R010618
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 30 Oct 2012 17:36:59 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9UHawJB030166; Tue, 30 Oct 2012 12:36:58 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 30 Oct 2012 10:36:58 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id EDA1140A75; Tue, 30 Oct 2012 11:44:50 -0400 (EDT)
Date: Tue, 30 Oct 2012 11:44:50 -0400
From: Konrad Rzeszutek Wilk 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	jbeulich@suse.com
Message-ID: <20121030154450.GA3000@phenom.dumpdata.com>
References: <1351519698-11069-1-git-send-email-konrad.wilk@oracle.com>
	<1351519698-11069-2-git-send-email-konrad.wilk@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1351519698-11069-2-git-send-email-konrad.wilk@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 1/2] xen/hypercall: fix hypercall fallback
 code for very old hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 29, 2012 at 10:08:17AM -0400, Konrad Rzeszutek Wilk wrote:
> From: Jan Beulich 
> 
> While copying the argument structures in HYPERVISOR_event_channel_op()
> and HYPERVISOR_physdev_op() into the local variable is sufficiently
> safe even if the actual structure is smaller than the container one,
> copying back eventual output values the same way isn't: This may
> collide with on-stack variables (particularly "rc") which may change
> between the first and second memcpy() (i.e. the second memcpy() could
> discard that change).
> 
> Move the fallback code into out-of-line functions, and handle all of
> the operations known by this old a hypervisor individually: Some don't
> require copying back anything at all, and for the rest use the
> individual argument structures' sizes rather than the container's.
> 
> Reported-by: Dan Carpenter 
> Signed-off-by: Jan Beulich 
> [v2: Reduce #define/#undef usage in HYPERVISOR_physdev_op_compat().]
> Signed-off-by: Konrad Rzeszutek Wilk 

And it looks like I get 

ERROR: "HYPERVISOR_event_channel_op_compat" [drivers/xen/xen-evtchn.ko] undefined!

when I build xen-evtchn as module. Jan did you encounter this issue on 2.6.18?
> ---
>  arch/x86/include/asm/xen/hypercall.h |   21 +++------
>  drivers/xen/Makefile                 |    2 +-
>  drivers/xen/fallback.c               |   78 ++++++++++++++++++++++++++++++++++
>  3 files changed, 86 insertions(+), 15 deletions(-)
>  create mode 100644 drivers/xen/fallback.c
> 
> diff --git a/arch/x86/include/asm/xen/hypercall.h b/arch/x86/include/asm/xen/hypercall.h
> index 59c226d..c812360 100644
> --- a/arch/x86/include/asm/xen/hypercall.h
> +++ b/arch/x86/include/asm/xen/hypercall.h
> @@ -359,18 +359,14 @@ HYPERVISOR_update_va_mapping(unsigned long va, pte_t new_val,
>  		return _hypercall4(int, update_va_mapping, va,
>  				   new_val.pte, new_val.pte >> 32, flags);
>  }
> +int __must_check HYPERVISOR_event_channel_op_compat(int, void *);
>  
>  static inline int
>  HYPERVISOR_event_channel_op(int cmd, void *arg)
>  {
>  	int rc = _hypercall2(int, event_channel_op, cmd, arg);
> -	if (unlikely(rc == -ENOSYS)) {
> -		struct evtchn_op op;
> -		op.cmd = cmd;
> -		memcpy(&op.u, arg, sizeof(op.u));
> -		rc = _hypercall1(int, event_channel_op_compat, &op);
> -		memcpy(arg, &op.u, sizeof(op.u));
> -	}
> +	if (unlikely(rc == -ENOSYS))
> +		rc = HYPERVISOR_event_channel_op_compat(cmd, arg);
>  	return rc;
>  }
>  
> @@ -386,17 +382,14 @@ HYPERVISOR_console_io(int cmd, int count, char *str)
>  	return _hypercall3(int, console_io, cmd, count, str);
>  }
>  
> +int __must_check HYPERVISOR_physdev_op_compat(int, void *);
> +
>  static inline int
>  HYPERVISOR_physdev_op(int cmd, void *arg)
>  {
>  	int rc = _hypercall2(int, physdev_op, cmd, arg);
> -	if (unlikely(rc == -ENOSYS)) {
> -		struct physdev_op op;
> -		op.cmd = cmd;
> -		memcpy(&op.u, arg, sizeof(op.u));
> -		rc = _hypercall1(int, physdev_op_compat, &op);
> -		memcpy(arg, &op.u, sizeof(op.u));
> -	}
> +	if (unlikely(rc == -ENOSYS))
> +		rc = HYPERVISOR_physdev_op_compat(cmd, arg);
>  	return rc;
>  }
>  
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index 0e863703..46de6cd 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -2,7 +2,7 @@ ifneq ($(CONFIG_ARM),y)
>  obj-y	+= manage.o balloon.o
>  obj-$(CONFIG_HOTPLUG_CPU)		+= cpu_hotplug.o
>  endif
> -obj-y	+= grant-table.o features.o events.o
> +obj-y	+= grant-table.o features.o events.o fallback.o
>  obj-y	+= xenbus/
>  
>  nostackp := $(call cc-option, -fno-stack-protector)
> diff --git a/drivers/xen/fallback.c b/drivers/xen/fallback.c
> new file mode 100644
> index 0000000..0bdc468
> --- /dev/null
> +++ b/drivers/xen/fallback.c
> @@ -0,0 +1,78 @@
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +int HYPERVISOR_event_channel_op_compat(int cmd, void *arg)
> +{
> +	struct evtchn_op op;
> +	int rc;
> +
> +	op.cmd = cmd;
> +	memcpy(&op.u, arg, sizeof(op.u));
> +	rc = _hypercall1(int, event_channel_op_compat, &op);
> +
> +	switch (cmd) {
> +	case EVTCHNOP_close:
> +	case EVTCHNOP_send:
> +	case EVTCHNOP_bind_vcpu:
> +	case EVTCHNOP_unmask:
> +		/* no output */
> +		break;
> +
> +#define COPY_BACK(eop) \
> +	case EVTCHNOP_##eop: \
> +		memcpy(arg, &op.u.eop, sizeof(op.u.eop)); \
> +		break
> +
> +	COPY_BACK(bind_interdomain);
> +	COPY_BACK(bind_virq);
> +	COPY_BACK(bind_pirq);
> +	COPY_BACK(status);
> +	COPY_BACK(alloc_unbound);
> +	COPY_BACK(bind_ipi);
> +#undef COPY_BACK
> +
> +	default:
> +		WARN_ON(rc != -ENOSYS);
> +		break;
> +	}
> +
> +	return rc;
> +}
> +
> +int HYPERVISOR_physdev_op_compat(int cmd, void *arg)
> +{
> +	struct physdev_op op;
> +	int rc;
> +
> +	op.cmd = cmd;
> +	memcpy(&op.u, arg, sizeof(op.u));
> +	rc = _hypercall1(int, physdev_op_compat, &op);
> +
> +	switch (cmd) {
> +	case PHYSDEVOP_IRQ_UNMASK_NOTIFY:
> +	case PHYSDEVOP_set_iopl:
> +	case PHYSDEVOP_set_iobitmap:
> +	case PHYSDEVOP_apic_write:
> +		/* no output */
> +		break;
> +
> +#define COPY_BACK(pop, fld) \
> +	case PHYSDEVOP_##pop: \
> +		memcpy(arg, &op.u.fld, sizeof(op.u.fld)); \
> +		break
> +
> +	COPY_BACK(irq_status_query, irq_status_query);
> +	COPY_BACK(apic_read, apic_op);
> +	COPY_BACK(ASSIGN_VECTOR, irq_op);
> +#undef COPY_BACK
> +
> +	default:
> +		WARN_ON(rc != -ENOSYS);
> +		break;
> +	}
> +
> +	return rc;
> +}
> -- 
> 1.7.7.6

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 17:38:09 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 17:38:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTFkQ-0003a6-Br; Tue, 30 Oct 2012 17:37:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTFkO-0003Zx-9b
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 17:37:04 +0000
Received: from [85.158.143.35:28188] by server-3.bemta-4.messagelabs.com id
	01/D7-24279-F3010905; Tue, 30 Oct 2012 17:37:03 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1351618621!10800344!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgzNjU3OA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11806 invoked from network); 30 Oct 2012 17:37:02 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Oct 2012 17:37:02 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9UHaxkS017176
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 30 Oct 2012 17:37:00 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9UHaw0R010618
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 30 Oct 2012 17:36:59 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9UHawJB030166; Tue, 30 Oct 2012 12:36:58 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 30 Oct 2012 10:36:58 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id EDA1140A75; Tue, 30 Oct 2012 11:44:50 -0400 (EDT)
Date: Tue, 30 Oct 2012 11:44:50 -0400
From: Konrad Rzeszutek Wilk 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	jbeulich@suse.com
Message-ID: <20121030154450.GA3000@phenom.dumpdata.com>
References: <1351519698-11069-1-git-send-email-konrad.wilk@oracle.com>
	<1351519698-11069-2-git-send-email-konrad.wilk@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1351519698-11069-2-git-send-email-konrad.wilk@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Jan Beulich 
Subject: Re: [Xen-devel] [PATCH 1/2] xen/hypercall: fix hypercall fallback
 code for very old hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 29, 2012 at 10:08:17AM -0400, Konrad Rzeszutek Wilk wrote:
> From: Jan Beulich 
> 
> While copying the argument structures in HYPERVISOR_event_channel_op()
> and HYPERVISOR_physdev_op() into the local variable is sufficiently
> safe even if the actual structure is smaller than the container one,
> copying back eventual output values the same way isn't: This may
> collide with on-stack variables (particularly "rc") which may change
> between the first and second memcpy() (i.e. the second memcpy() could
> discard that change).
> 
> Move the fallback code into out-of-line functions, and handle all of
> the operations known by this old a hypervisor individually: Some don't
> require copying back anything at all, and for the rest use the
> individual argument structures' sizes rather than the container's.
> 
> Reported-by: Dan Carpenter 
> Signed-off-by: Jan Beulich 
> [v2: Reduce #define/#undef usage in HYPERVISOR_physdev_op_compat().]
> Signed-off-by: Konrad Rzeszutek Wilk 

And it looks like I get 

ERROR: "HYPERVISOR_event_channel_op_compat" [drivers/xen/xen-evtchn.ko] undefined!

when I build xen-evtchn as module. Jan did you encounter this issue on 2.6.18?
> ---
>  arch/x86/include/asm/xen/hypercall.h |   21 +++------
>  drivers/xen/Makefile                 |    2 +-
>  drivers/xen/fallback.c               |   78 ++++++++++++++++++++++++++++++++++
>  3 files changed, 86 insertions(+), 15 deletions(-)
>  create mode 100644 drivers/xen/fallback.c
> 
> diff --git a/arch/x86/include/asm/xen/hypercall.h b/arch/x86/include/asm/xen/hypercall.h
> index 59c226d..c812360 100644
> --- a/arch/x86/include/asm/xen/hypercall.h
> +++ b/arch/x86/include/asm/xen/hypercall.h
> @@ -359,18 +359,14 @@ HYPERVISOR_update_va_mapping(unsigned long va, pte_t new_val,
>  		return _hypercall4(int, update_va_mapping, va,
>  				   new_val.pte, new_val.pte >> 32, flags);
>  }
> +int __must_check HYPERVISOR_event_channel_op_compat(int, void *);
>  
>  static inline int
>  HYPERVISOR_event_channel_op(int cmd, void *arg)
>  {
>  	int rc = _hypercall2(int, event_channel_op, cmd, arg);
> -	if (unlikely(rc == -ENOSYS)) {
> -		struct evtchn_op op;
> -		op.cmd = cmd;
> -		memcpy(&op.u, arg, sizeof(op.u));
> -		rc = _hypercall1(int, event_channel_op_compat, &op);
> -		memcpy(arg, &op.u, sizeof(op.u));
> -	}
> +	if (unlikely(rc == -ENOSYS))
> +		rc = HYPERVISOR_event_channel_op_compat(cmd, arg);
>  	return rc;
>  }
>  
> @@ -386,17 +382,14 @@ HYPERVISOR_console_io(int cmd, int count, char *str)
>  	return _hypercall3(int, console_io, cmd, count, str);
>  }
>  
> +int __must_check HYPERVISOR_physdev_op_compat(int, void *);
> +
>  static inline int
>  HYPERVISOR_physdev_op(int cmd, void *arg)
>  {
>  	int rc = _hypercall2(int, physdev_op, cmd, arg);
> -	if (unlikely(rc == -ENOSYS)) {
> -		struct physdev_op op;
> -		op.cmd = cmd;
> -		memcpy(&op.u, arg, sizeof(op.u));
> -		rc = _hypercall1(int, physdev_op_compat, &op);
> -		memcpy(arg, &op.u, sizeof(op.u));
> -	}
> +	if (unlikely(rc == -ENOSYS))
> +		rc = HYPERVISOR_physdev_op_compat(cmd, arg);
>  	return rc;
>  }
>  
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index 0e863703..46de6cd 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -2,7 +2,7 @@ ifneq ($(CONFIG_ARM),y)
>  obj-y	+= manage.o balloon.o
>  obj-$(CONFIG_HOTPLUG_CPU)		+= cpu_hotplug.o
>  endif
> -obj-y	+= grant-table.o features.o events.o
> +obj-y	+= grant-table.o features.o events.o fallback.o
>  obj-y	+= xenbus/
>  
>  nostackp := $(call cc-option, -fno-stack-protector)
> diff --git a/drivers/xen/fallback.c b/drivers/xen/fallback.c
> new file mode 100644
> index 0000000..0bdc468
> --- /dev/null
> +++ b/drivers/xen/fallback.c
> @@ -0,0 +1,78 @@
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +int HYPERVISOR_event_channel_op_compat(int cmd, void *arg)
> +{
> +	struct evtchn_op op;
> +	int rc;
> +
> +	op.cmd = cmd;
> +	memcpy(&op.u, arg, sizeof(op.u));
> +	rc = _hypercall1(int, event_channel_op_compat, &op);
> +
> +	switch (cmd) {
> +	case EVTCHNOP_close:
> +	case EVTCHNOP_send:
> +	case EVTCHNOP_bind_vcpu:
> +	case EVTCHNOP_unmask:
> +		/* no output */
> +		break;
> +
> +#define COPY_BACK(eop) \
> +	case EVTCHNOP_##eop: \
> +		memcpy(arg, &op.u.eop, sizeof(op.u.eop)); \
> +		break
> +
> +	COPY_BACK(bind_interdomain);
> +	COPY_BACK(bind_virq);
> +	COPY_BACK(bind_pirq);
> +	COPY_BACK(status);
> +	COPY_BACK(alloc_unbound);
> +	COPY_BACK(bind_ipi);
> +#undef COPY_BACK
> +
> +	default:
> +		WARN_ON(rc != -ENOSYS);
> +		break;
> +	}
> +
> +	return rc;
> +}
> +
> +int HYPERVISOR_physdev_op_compat(int cmd, void *arg)
> +{
> +	struct physdev_op op;
> +	int rc;
> +
> +	op.cmd = cmd;
> +	memcpy(&op.u, arg, sizeof(op.u));
> +	rc = _hypercall1(int, physdev_op_compat, &op);
> +
> +	switch (cmd) {
> +	case PHYSDEVOP_IRQ_UNMASK_NOTIFY:
> +	case PHYSDEVOP_set_iopl:
> +	case PHYSDEVOP_set_iobitmap:
> +	case PHYSDEVOP_apic_write:
> +		/* no output */
> +		break;
> +
> +#define COPY_BACK(pop, fld) \
> +	case PHYSDEVOP_##pop: \
> +		memcpy(arg, &op.u.fld, sizeof(op.u.fld)); \
> +		break
> +
> +	COPY_BACK(irq_status_query, irq_status_query);
> +	COPY_BACK(apic_read, apic_op);
> +	COPY_BACK(ASSIGN_VECTOR, irq_op);
> +#undef COPY_BACK
> +
> +	default:
> +		WARN_ON(rc != -ENOSYS);
> +		break;
> +	}
> +
> +	return rc;
> +}
> -- 
> 1.7.7.6

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 17:38:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 17:38:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTFkr-0003eI-Vv; Tue, 30 Oct 2012 17:37:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTFkq-0003dz-7s
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 17:37:32 +0000
Received: from [85.158.138.51:37922] by server-15.bemta-3.messagelabs.com id
	C5/DB-09445-B5010905; Tue, 30 Oct 2012 17:37:31 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1351618623!27999784!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNzI0Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2758 invoked from network); 30 Oct 2012 17:37:30 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Oct 2012 17:37:30 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9UHb0mJ018847
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 30 Oct 2012 17:37:01 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9UHaxC8010650
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 30 Oct 2012 17:37:00 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9UHax4g030178; Tue, 30 Oct 2012 12:36:59 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 30 Oct 2012 10:36:59 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 0D1724037A; Tue, 30 Oct 2012 12:53:10 -0400 (EDT)
Date: Tue, 30 Oct 2012 12:53:10 -0400
From: Konrad Rzeszutek Wilk 
To: Eric Dumazet 
Message-ID: <20121030165309.GA30483@phenom.dumpdata.com>
References: <1351078936-14159-1-git-send-email-ian.campbell@citrix.com>
	<1351081703.6537.99.camel@edumazet-glaptop>
	<1351084618.18035.27.camel@zakaz.uk.xensource.com>
	<1351085403.6537.102.camel@edumazet-glaptop>
	<1351087326.18035.50.camel@zakaz.uk.xensource.com>
	<1351092068.6537.107.camel@edumazet-glaptop>
	<1351095739.18035.83.camel@zakaz.uk.xensource.com>
	<1351097000.6537.109.camel@edumazet-glaptop>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="0F1p//8PRICkK4MW"
Content-Disposition: inline
In-Reply-To: <1351097000.6537.109.camel@edumazet-glaptop>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "netdev@vger.kernel.org" ,
	Eric Dumazet , Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] net: allow configuration of the size of
 page in __netdev_alloc_frag
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--0F1p//8PRICkK4MW
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Wed, Oct 24, 2012 at 06:43:20PM +0200, Eric Dumazet wrote:
> On Wed, 2012-10-24 at 17:22 +0100, Ian Campbell wrote:
> > On Wed, 2012-10-24 at 16:21 +0100, Eric Dumazet wrote:
> 
> > > If you really have such problems, why locally generated TCP traffic
> > > doesnt also have it ?
> > 
> > I think it does. The reason I noticed the original problem was that ssh
> > to the machine was virtually (no pun intended) unusable.
> > 
> > > Your patch doesnt touch sk_page_frag_refill(), does it ?
> > 
> > That's right. It doesn't. When is (sk->sk_allocation & __GFP_WAIT) true?
> > Is it possible I'm just not hitting that case?
> > 
> 
> I hope not. GFP_KERNEL has __GFP_WAIT.
> 
> > Is it possible that this only affects certain traffic patterns (I only
> > really tried ssh/scp and ping)? Or perhaps its just that the swiotlb is
> > only broken in one corner case and not the other.
> 
> Could you try a netperf -t TCP_STREAM ?

For fun I did a couple of tests - I setup two machines (one r8168, the other
e1000e) and tried to do netperf/netserver. Both of them are running a baremetal
kernel and one of them has 'iommu=soft swiotlb=force' to simulate the worst
case. This is using v3.7-rc3.

The r8169 is booted without any arguments, the e1000e is using 'iommu=soft
swiotlb=force'.

So r8169 -> e1000e, I get ~940 (this is odd, I expected that the e1000e
on the recv side would be using the bounce buffer, but then I realized it
sets up using pci_alloc_coherent an 'dma' pool).

The other way - e1000e -> r8169 got me around ~128. So it is the sending
side that ends up using the bounce buffer and it slows down considerably.

I also swapped the machine that had e1000e with a tg3 - and got around
the same numbers.

So all of this points to the swiotlb and to just make sure that nothing
was amiss I wrote a little driver that would allocate a compound page,
setup DMA mapping, do some writes, sync and unmap the DMA page. And it works
correctly - so swiotlb (and the xen variant) work right just right.
Attached for your fun.

Then I decided to try v3.6.3, with the same exact parameters.. and
the problem went away.

The e1000e -> r8169 which got me around ~128, now gets ~940! Still
using the swiotlb bounce buffer.


> 
> Because ssh use small packets, and small TCP packets dont use frags but
> skb->head.
> 
> You mentioned a 70% drop of performance, but what test have you used
> exactly ?

Note, I did not provide any arguments to netperf, but it did pick the
test you wanted:

> netperf -H tst019
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to tst019.dumpdata.com (192.168.101.39) port 0 AF_INET

> 
> 

--0F1p//8PRICkK4MW
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="dma_test.c"

#include 
#include 
#include 
#include 
#include 
#include 
#include 

#define DMA_TEST  "0.1"

MODULE_AUTHOR("Konrad Rzeszutek Wilk ");
MODULE_DESCRIPTION("dma_test");
MODULE_LICENSE("GPL");
MODULE_VERSION(DMA_TEST);

static struct bus_type fallback_bus_type = {
	.name = "fallback_bus:",
};

static void fake_release(struct device *dev)
{
	/* No kfree as the device was allocated on stack. */
}

struct args {
	int len;
	enum dma_data_direction dir;
};

#define MAGIC_DEVICE 0xffffffdd
#define MAGIC_CPU 0xffffffcc

static int dma_test_thread(void *arg)
{
	struct page *page;
	dma_addr_t dma_addr = 0;
	struct device fake = {
		.coherent_dma_mask = DMA_BIT_MASK(32),
		.bus = &fallback_bus_type,
		.release = fake_release,
	};
	gfp_t gfp = __GFP_COMP | __GFP_NOWARN | GFP_ATOMIC;
	int ret;
	int i;
	void *addr;
	struct page *p;

	struct args *args = (struct args *)arg;
	int dir = args->dir;
	int len = args->len;

	dev_set_name(&fake, "%s", dir == DMA_TO_DEVICE ? "to_dev" : "to_cpu");
 	fake.dma_mask = &fake.coherent_dma_mask;
 	ret = device_register(&fake);
	if (ret)
		goto out;

	do {
		unsigned long prev_mfn = 0;
		bool bus_and_dma_same;

		page = alloc_pages(gfp, get_order(len));
		p = page;
		/* Check that the bus addresses are contingous. */
		for (i = 0; i < len / PAGE_SIZE; i++, p++) {
			unsigned long pfn, mfn;

			addr = page_address(p);
			pfn = PFN_DOWN(virt_to_phys(addr));
			if (xen_domain())
				mfn = pfn_to_mfn(pfn);
			else
				mfn = pfn;
			if (i != 0) {
				if (prev_mfn + 1 != mfn)
					dev_warn(&fake, "va: %lx (pfn:%lx, mfn:%lx) w.r.t prev mfn: %lx!\n",
						 (unsigned long)addr, pfn, mfn, prev_mfn);
			}
			prev_mfn = mfn;
		}
		dma_addr = dma_map_page(&fake, page, 0 /* no offset */, len, dir);
		/* Note, dma_addr is the physical address ! */
		if (dma_mapping_error(&fake, dma_addr)) {
			dev_warn(&fake, "DMA %lx for %lx is not right\n", (unsigned long)dma_addr,
				(unsigned long)page_address(page));
			__free_pages(page, get_order(len));
			page = NULL;
		}
		bus_and_dma_same = false;
		if (page) {
			unsigned long phys;
			unsigned long pfn, mfn, bus_addr_mfn;
			unsigned long bus_addr = 0;

			p = page;
			for (i = 0; i < len / PAGE_SIZE; i++, p++) {
				void *bus_va;

				addr = page_address(p);
				phys = virt_to_phys(addr);
				pfn = PFN_DOWN(phys);

				bus_va = (void *)(dma_addr + (i * PAGE_SIZE));

				if (xen_domain()) {
					void * tmp;

					/* Find the bus frame for the physical frame*/
					mfn = pfn_to_mfn(pfn);
					/* and .. voodoo time! */
					bus_addr_mfn = PFN_DOWN(dma_addr + (i * PAGE_SIZE));
					bus_addr = PFN_PHYS(mfn_to_pfn(bus_addr_mfn));
					tmp = __va(bus_addr);
					bus_va = mfn_to_virt(bus_addr_mfn);
					WARN(bus_va != tmp, "Expected %lx (%lx+%d*PAGE_SIZE), got: %lx (pfn: %lx, mfn: %lx)!\n",
						(unsigned long)bus_va, (unsigned long)dma_addr, i, (unsigned long)tmp, PFN_DOWN(bus_addr), bus_addr_mfn);
				} else {
					mfn = pfn;
					bus_addr = (unsigned long)bus_va;
					/* Assume DMA addr == physical addr */
					bus_addr_mfn = PFN_DOWN(bus_addr);
					bus_va = __va(PFN_PHYS(bus_addr_mfn));
				}

				dev_info(&fake, "%lx (pfn:%lx, bus frame: %lx) %s %lx (addr: %lx, frame: %lx)\n",
					(unsigned long)addr, pfn, mfn,
					dir == DMA_TO_DEVICE ? "=>" : "<=",
					(unsigned long)bus_va, bus_addr, bus_addr_mfn);

				if (!virt_addr_valid(bus_va))
					break;
				if (!virt_addr_valid(addr))
					break;

				/* CPU */
				memset(addr, 0xCC, PAGE_SIZE);

				/* Device */
				memset(bus_va, 0xDD, PAGE_SIZE);
				if (addr == bus_va)
					bus_and_dma_same = true;
			}
		}
		set_current_state(TASK_INTERRUPTIBLE);
		schedule_timeout_interruptible(5*HZ);

		if (!page)
			continue;
		p = page;

		for (i = 0; i < len / PAGE_SIZE; i++, p++) {
			if (bus_and_dma_same)
				continue;
			addr = page_address(p);
			if (((char *)addr)[0] != MAGIC_CPU)
				dev_warn(&fake, "%lx with DMA (%lx) has %x (expected %lx)\n",
					(unsigned long)addr, (unsigned long)(dma_addr + (i * PAGE_SIZE)),
					((char *)addr)[0], (unsigned long)MAGIC_CPU);
		}
		/* sync the page */
		dma_sync_single_for_cpu(&fake, dma_addr, len, dir);
		p = page;
		for (i = 0; i < len / PAGE_SIZE; i++, p++) {
			unsigned long check_val = MAGIC_DEVICE;

			addr = page_address(p);
			if (dir == DMA_TO_DEVICE)
				check_val = MAGIC_CPU;
			if (dir == DMA_FROM_DEVICE)
				check_val = MAGIC_DEVICE;

			dev_info(&fake, "%lx with DMA (%lx) has %x (expected %lx)\n",
				(unsigned long)addr, (unsigned long)(dma_addr + (i * PAGE_SIZE)),
				((char *)addr)[0], check_val);
		}
		dma_unmap_page(&fake, dma_addr, len, dir);
		dma_addr = 0;
		__free_pages(page, get_order(len));
		page = NULL;
	} while (!kthread_should_stop());

	if (dma_addr)
		dma_unmap_page(&fake, dma_addr, len, dir);
	if (page)
		__free_pages(page, get_order(len));
   	put_device(&fake);
 	device_unregister(&fake);
out:
	return 0;
}
static struct task_struct *t[2];
static struct args a[2];

static int __init dma_test_init(void)
{
	int ret;

	/* No point doing this without SWIOTLB */
	if (!swiotlb_nr_tbl())
		return -ENODEV;

	ret = bus_register(&fallback_bus_type);
	if (ret)
		return ret;

	a[0].dir = DMA_TO_DEVICE;
	a[0].len = 32768;
	t[0] = kthread_run(dma_test_thread, &a[0], "dma_test_dev");

	a[1].len = 16384;
	a[1].dir = DMA_FROM_DEVICE;
	t[1] = kthread_run(dma_test_thread, &a[1], "dma_test_cpu");
	return 0;
}
static void __exit dma_test_exit(void)
{
	if (t[0])
		kthread_stop(t[0]);
	if (t[1])
		kthread_stop(t[1]);

 	bus_unregister(&fallback_bus_type);
}
module_init(dma_test_init);
module_exit(dma_test_exit);

--0F1p//8PRICkK4MW
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--0F1p//8PRICkK4MW--


From xen-devel-bounces@lists.xen.org Tue Oct 30 17:38:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 17:38:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTFkr-0003eI-Vv; Tue, 30 Oct 2012 17:37:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTFkq-0003dz-7s
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 17:37:32 +0000
Received: from [85.158.138.51:37922] by server-15.bemta-3.messagelabs.com id
	C5/DB-09445-B5010905; Tue, 30 Oct 2012 17:37:31 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1351618623!27999784!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNzI0Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2758 invoked from network); 30 Oct 2012 17:37:30 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Oct 2012 17:37:30 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9UHb0mJ018847
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 30 Oct 2012 17:37:01 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9UHaxC8010650
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 30 Oct 2012 17:37:00 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9UHax4g030178; Tue, 30 Oct 2012 12:36:59 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 30 Oct 2012 10:36:59 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 0D1724037A; Tue, 30 Oct 2012 12:53:10 -0400 (EDT)
Date: Tue, 30 Oct 2012 12:53:10 -0400
From: Konrad Rzeszutek Wilk 
To: Eric Dumazet 
Message-ID: <20121030165309.GA30483@phenom.dumpdata.com>
References: <1351078936-14159-1-git-send-email-ian.campbell@citrix.com>
	<1351081703.6537.99.camel@edumazet-glaptop>
	<1351084618.18035.27.camel@zakaz.uk.xensource.com>
	<1351085403.6537.102.camel@edumazet-glaptop>
	<1351087326.18035.50.camel@zakaz.uk.xensource.com>
	<1351092068.6537.107.camel@edumazet-glaptop>
	<1351095739.18035.83.camel@zakaz.uk.xensource.com>
	<1351097000.6537.109.camel@edumazet-glaptop>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="0F1p//8PRICkK4MW"
Content-Disposition: inline
In-Reply-To: <1351097000.6537.109.camel@edumazet-glaptop>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "netdev@vger.kernel.org" ,
	Eric Dumazet , Ian Campbell ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] net: allow configuration of the size of
 page in __netdev_alloc_frag
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--0F1p//8PRICkK4MW
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Wed, Oct 24, 2012 at 06:43:20PM +0200, Eric Dumazet wrote:
> On Wed, 2012-10-24 at 17:22 +0100, Ian Campbell wrote:
> > On Wed, 2012-10-24 at 16:21 +0100, Eric Dumazet wrote:
> 
> > > If you really have such problems, why locally generated TCP traffic
> > > doesnt also have it ?
> > 
> > I think it does. The reason I noticed the original problem was that ssh
> > to the machine was virtually (no pun intended) unusable.
> > 
> > > Your patch doesnt touch sk_page_frag_refill(), does it ?
> > 
> > That's right. It doesn't. When is (sk->sk_allocation & __GFP_WAIT) true?
> > Is it possible I'm just not hitting that case?
> > 
> 
> I hope not. GFP_KERNEL has __GFP_WAIT.
> 
> > Is it possible that this only affects certain traffic patterns (I only
> > really tried ssh/scp and ping)? Or perhaps its just that the swiotlb is
> > only broken in one corner case and not the other.
> 
> Could you try a netperf -t TCP_STREAM ?

For fun I did a couple of tests - I setup two machines (one r8168, the other
e1000e) and tried to do netperf/netserver. Both of them are running a baremetal
kernel and one of them has 'iommu=soft swiotlb=force' to simulate the worst
case. This is using v3.7-rc3.

The r8169 is booted without any arguments, the e1000e is using 'iommu=soft
swiotlb=force'.

So r8169 -> e1000e, I get ~940 (this is odd, I expected that the e1000e
on the recv side would be using the bounce buffer, but then I realized it
sets up using pci_alloc_coherent an 'dma' pool).

The other way - e1000e -> r8169 got me around ~128. So it is the sending
side that ends up using the bounce buffer and it slows down considerably.

I also swapped the machine that had e1000e with a tg3 - and got around
the same numbers.

So all of this points to the swiotlb and to just make sure that nothing
was amiss I wrote a little driver that would allocate a compound page,
setup DMA mapping, do some writes, sync and unmap the DMA page. And it works
correctly - so swiotlb (and the xen variant) work right just right.
Attached for your fun.

Then I decided to try v3.6.3, with the same exact parameters.. and
the problem went away.

The e1000e -> r8169 which got me around ~128, now gets ~940! Still
using the swiotlb bounce buffer.


> 
> Because ssh use small packets, and small TCP packets dont use frags but
> skb->head.
> 
> You mentioned a 70% drop of performance, but what test have you used
> exactly ?

Note, I did not provide any arguments to netperf, but it did pick the
test you wanted:

> netperf -H tst019
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to tst019.dumpdata.com (192.168.101.39) port 0 AF_INET

> 
> 

--0F1p//8PRICkK4MW
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="dma_test.c"

#include 
#include 
#include 
#include 
#include 
#include 
#include 

#define DMA_TEST  "0.1"

MODULE_AUTHOR("Konrad Rzeszutek Wilk ");
MODULE_DESCRIPTION("dma_test");
MODULE_LICENSE("GPL");
MODULE_VERSION(DMA_TEST);

static struct bus_type fallback_bus_type = {
	.name = "fallback_bus:",
};

static void fake_release(struct device *dev)
{
	/* No kfree as the device was allocated on stack. */
}

struct args {
	int len;
	enum dma_data_direction dir;
};

#define MAGIC_DEVICE 0xffffffdd
#define MAGIC_CPU 0xffffffcc

static int dma_test_thread(void *arg)
{
	struct page *page;
	dma_addr_t dma_addr = 0;
	struct device fake = {
		.coherent_dma_mask = DMA_BIT_MASK(32),
		.bus = &fallback_bus_type,
		.release = fake_release,
	};
	gfp_t gfp = __GFP_COMP | __GFP_NOWARN | GFP_ATOMIC;
	int ret;
	int i;
	void *addr;
	struct page *p;

	struct args *args = (struct args *)arg;
	int dir = args->dir;
	int len = args->len;

	dev_set_name(&fake, "%s", dir == DMA_TO_DEVICE ? "to_dev" : "to_cpu");
 	fake.dma_mask = &fake.coherent_dma_mask;
 	ret = device_register(&fake);
	if (ret)
		goto out;

	do {
		unsigned long prev_mfn = 0;
		bool bus_and_dma_same;

		page = alloc_pages(gfp, get_order(len));
		p = page;
		/* Check that the bus addresses are contingous. */
		for (i = 0; i < len / PAGE_SIZE; i++, p++) {
			unsigned long pfn, mfn;

			addr = page_address(p);
			pfn = PFN_DOWN(virt_to_phys(addr));
			if (xen_domain())
				mfn = pfn_to_mfn(pfn);
			else
				mfn = pfn;
			if (i != 0) {
				if (prev_mfn + 1 != mfn)
					dev_warn(&fake, "va: %lx (pfn:%lx, mfn:%lx) w.r.t prev mfn: %lx!\n",
						 (unsigned long)addr, pfn, mfn, prev_mfn);
			}
			prev_mfn = mfn;
		}
		dma_addr = dma_map_page(&fake, page, 0 /* no offset */, len, dir);
		/* Note, dma_addr is the physical address ! */
		if (dma_mapping_error(&fake, dma_addr)) {
			dev_warn(&fake, "DMA %lx for %lx is not right\n", (unsigned long)dma_addr,
				(unsigned long)page_address(page));
			__free_pages(page, get_order(len));
			page = NULL;
		}
		bus_and_dma_same = false;
		if (page) {
			unsigned long phys;
			unsigned long pfn, mfn, bus_addr_mfn;
			unsigned long bus_addr = 0;

			p = page;
			for (i = 0; i < len / PAGE_SIZE; i++, p++) {
				void *bus_va;

				addr = page_address(p);
				phys = virt_to_phys(addr);
				pfn = PFN_DOWN(phys);

				bus_va = (void *)(dma_addr + (i * PAGE_SIZE));

				if (xen_domain()) {
					void * tmp;

					/* Find the bus frame for the physical frame*/
					mfn = pfn_to_mfn(pfn);
					/* and .. voodoo time! */
					bus_addr_mfn = PFN_DOWN(dma_addr + (i * PAGE_SIZE));
					bus_addr = PFN_PHYS(mfn_to_pfn(bus_addr_mfn));
					tmp = __va(bus_addr);
					bus_va = mfn_to_virt(bus_addr_mfn);
					WARN(bus_va != tmp, "Expected %lx (%lx+%d*PAGE_SIZE), got: %lx (pfn: %lx, mfn: %lx)!\n",
						(unsigned long)bus_va, (unsigned long)dma_addr, i, (unsigned long)tmp, PFN_DOWN(bus_addr), bus_addr_mfn);
				} else {
					mfn = pfn;
					bus_addr = (unsigned long)bus_va;
					/* Assume DMA addr == physical addr */
					bus_addr_mfn = PFN_DOWN(bus_addr);
					bus_va = __va(PFN_PHYS(bus_addr_mfn));
				}

				dev_info(&fake, "%lx (pfn:%lx, bus frame: %lx) %s %lx (addr: %lx, frame: %lx)\n",
					(unsigned long)addr, pfn, mfn,
					dir == DMA_TO_DEVICE ? "=>" : "<=",
					(unsigned long)bus_va, bus_addr, bus_addr_mfn);

				if (!virt_addr_valid(bus_va))
					break;
				if (!virt_addr_valid(addr))
					break;

				/* CPU */
				memset(addr, 0xCC, PAGE_SIZE);

				/* Device */
				memset(bus_va, 0xDD, PAGE_SIZE);
				if (addr == bus_va)
					bus_and_dma_same = true;
			}
		}
		set_current_state(TASK_INTERRUPTIBLE);
		schedule_timeout_interruptible(5*HZ);

		if (!page)
			continue;
		p = page;

		for (i = 0; i < len / PAGE_SIZE; i++, p++) {
			if (bus_and_dma_same)
				continue;
			addr = page_address(p);
			if (((char *)addr)[0] != MAGIC_CPU)
				dev_warn(&fake, "%lx with DMA (%lx) has %x (expected %lx)\n",
					(unsigned long)addr, (unsigned long)(dma_addr + (i * PAGE_SIZE)),
					((char *)addr)[0], (unsigned long)MAGIC_CPU);
		}
		/* sync the page */
		dma_sync_single_for_cpu(&fake, dma_addr, len, dir);
		p = page;
		for (i = 0; i < len / PAGE_SIZE; i++, p++) {
			unsigned long check_val = MAGIC_DEVICE;

			addr = page_address(p);
			if (dir == DMA_TO_DEVICE)
				check_val = MAGIC_CPU;
			if (dir == DMA_FROM_DEVICE)
				check_val = MAGIC_DEVICE;

			dev_info(&fake, "%lx with DMA (%lx) has %x (expected %lx)\n",
				(unsigned long)addr, (unsigned long)(dma_addr + (i * PAGE_SIZE)),
				((char *)addr)[0], check_val);
		}
		dma_unmap_page(&fake, dma_addr, len, dir);
		dma_addr = 0;
		__free_pages(page, get_order(len));
		page = NULL;
	} while (!kthread_should_stop());

	if (dma_addr)
		dma_unmap_page(&fake, dma_addr, len, dir);
	if (page)
		__free_pages(page, get_order(len));
   	put_device(&fake);
 	device_unregister(&fake);
out:
	return 0;
}
static struct task_struct *t[2];
static struct args a[2];

static int __init dma_test_init(void)
{
	int ret;

	/* No point doing this without SWIOTLB */
	if (!swiotlb_nr_tbl())
		return -ENODEV;

	ret = bus_register(&fallback_bus_type);
	if (ret)
		return ret;

	a[0].dir = DMA_TO_DEVICE;
	a[0].len = 32768;
	t[0] = kthread_run(dma_test_thread, &a[0], "dma_test_dev");

	a[1].len = 16384;
	a[1].dir = DMA_FROM_DEVICE;
	t[1] = kthread_run(dma_test_thread, &a[1], "dma_test_cpu");
	return 0;
}
static void __exit dma_test_exit(void)
{
	if (t[0])
		kthread_stop(t[0]);
	if (t[1])
		kthread_stop(t[1]);

 	bus_unregister(&fallback_bus_type);
}
module_init(dma_test_init);
module_exit(dma_test_exit);

--0F1p//8PRICkK4MW
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--0F1p//8PRICkK4MW--


From xen-devel-bounces@lists.xen.org Tue Oct 30 17:38:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 17:38:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTFkR-0003aV-T7; Tue, 30 Oct 2012 17:37:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTFkQ-0003a5-GI
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 17:37:07 +0000
Received: from [85.158.139.211:15332] by server-16.bemta-5.messagelabs.com id
	5F/43-04786-14010905; Tue, 30 Oct 2012 17:37:05 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1351618622!18242733!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNzI0Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17421 invoked from network); 30 Oct 2012 17:37:04 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-4.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Oct 2012 17:37:04 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9UHaxZw018832
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 30 Oct 2012 17:37:00 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9UHax6g017649
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 30 Oct 2012 17:36:59 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9UHaw2u017381; Tue, 30 Oct 2012 12:36:58 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 30 Oct 2012 10:36:58 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 038684042F; Tue, 30 Oct 2012 13:01:57 -0400 (EDT)
Date: Tue, 30 Oct 2012 13:01:57 -0400
From: Konrad Rzeszutek Wilk 
To: Roger Pau Monne 
Message-ID: <20121030170157.GA29485@phenom.dumpdata.com>
References: <1351097925-26221-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1351097925-26221-1-git-send-email-roger.pau@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Oliver Chick , linux-kernel@vger.kernel.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 24, 2012 at 06:58:45PM +0200, Roger Pau Monne wrote:
> This patch implements persistent grants for the xen-blk{front,back}
> mechanism. The effect of this change is to reduce the number of unmap
> operations performed, since they cause a (costly) TLB shootdown. This
> allows the I/O performance to scale better when a large number of VMs
> are performing I/O.
> 
> Previously, the blkfront driver was supplied a bvec[] from the request
> queue. This was granted to dom0; dom0 performed the I/O and wrote
> directly into the grant-mapped memory and unmapped it; blkfront then
> removed foreign access for that grant. The cost of unmapping scales
> badly with the number of CPUs in Dom0. An experiment showed that when
> Dom0 has 24 VCPUs, and guests are performing parallel I/O to a
> ramdisk, the IPIs from performing unmap's is a bottleneck at 5 guests
> (at which point 650,000 IOPS are being performed in total). If more
> than 5 guests are used, the performance declines. By 10 guests, only
> 400,000 IOPS are being performed.
> 
> This patch improves performance by only unmapping when the connection
> between blkfront and back is broken.
> 
> On startup blkfront notifies blkback that it is using persistent
> grants, and blkback will do the same. If blkback is not capable of
> persistent mapping, blkfront will still use the same grants, since it
> is compatible with the previous protocol, and simplifies the code
> complexity in blkfront.
> 
> To perform a read, in persistent mode, blkfront uses a separate pool
> of pages that it maps to dom0. When a request comes in, blkfront
> transmutes the request so that blkback will write into one of these
> free pages. Blkback keeps note of which grefs it has already
> mapped. When a new ring request comes to blkback, it looks to see if
> it has already mapped that page. If so, it will not map it again. If
> the page hasn't been previously mapped, it is mapped now, and a record
> is kept of this mapping. Blkback proceeds as usual. When blkfront is
> notified that blkback has completed a request, it memcpy's from the
> shared memory, into the bvec supplied. A record that the {gref, page}
> tuple is mapped, and not inflight is kept.
> 
> Writes are similar, except that the memcpy is peformed from the
> supplied bvecs, into the shared pages, before the request is put onto
> the ring.
> 
> Blkback stores a mapping of grefs=>{page mapped to by gref} in
> a red-black tree. As the grefs are not known apriori, and provide no
> guarantees on their ordering, we have to perform a search
> through this tree to find the page, for every gref we receive. This
> operation takes O(log n) time in the worst case. In blkfront grants
> are stored using a single linked list.
> 
> The maximum number of grants that blkback will persistenly map is
> currently set to RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, to
> prevent a malicios guest from attempting a DoS, by supplying fresh
> grefs, causing the Dom0 kernel to map excessively. If a guest
> is using persistent grants and exceeds the maximum number of grants to
> map persistenly the newly passed grefs will be mapped and unmaped.
> Using this approach, we can have requests that mix persistent and
> non-persistent grants, and we need to handle them correctly.
> This allows us to set the maximum number of persistent grants to a
> lower value than RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, although
> setting it will lead to unpredictable performance.
> 
> In writing this patch, the question arrises as to if the additional
> cost of performing memcpys in the guest (to/from the pool of granted
> pages) outweigh the gains of not performing TLB shootdowns. The answer
> to that question is `no'. There appears to be very little, if any
> additional cost to the guest of using persistent grants. There is
> perhaps a small saving, from the reduced number of hypercalls
> performed in granting, and ending foreign access.
> 
> Signed-off-by: Oliver Chick 
> Signed-off-by: Roger Pau Monne 
> Cc: 
> Cc: 
> ---
> Changes since v1:
>  * Changed the unmap_seg array to a bitmap.
>  * Only report using persistent grants in blkfront if blkback supports
>    it.
>  * Reword some comments.
>  * Fix a bug when setting the handler, index j was not incremented
>    correctly.
>  * Check that the tree of grants in blkback is not empty before
>    iterating over it when doing the cleanup.
>  * Rebase on top of linux-net.

I fixed the 'new_map = [1|0]' you had in and altered it to use 'true'
or 'false', but when running some tests (with a 64-bit PV guest) I got it
to bug.

[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.7.0-rc3upstream-00220-g37b7153 (konrad@build.dumpdata.com) (gcc version 4.4.4 20100503 (Red Hat 4.4.4-2) (GCC) ) #1 SMP Tue Oct 30 12:15:12 EDT 2012
[    0.000000] Command line: earlyprintk=xen debug nofb console=tty console=ttyS1,115200n8 xen-pciback.hide=(00:02:00) loglevel=10
[    0.000000] Freeing 9d-100 pfn range: 99 pages freed
[    0.000000] 1-1 mapping on 9d->100
[    0.000000] 1-1 mapping on cf7fb->cfb63
[    0.000000] 1-1 mapping on cfd15->cfd70
[    0.000000] 1-1 mapping on cfd71->cfef7
[    0.000000] 1-1 mapping on cff00->100001
[    0.000000] Released 99 pages of unused memory
[    0.000000] Set 198317 page(s) to 1-1 mapping
[    0.000000] Populating 3e700-3e763 pfn range: 99 pages added
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] Xen: [mem 0x0000000000000000-0x000000000009cfff] usable
[    0.000000] Xen: [mem 0x000000000009d800-0x00000000000fffff] reserved
[    0.000000] Xen: [mem 0x0000000000100000-0x000000004d062fff] usable
[    0.000000] Xen: [mem 0x000000004d063000-0x00000000cf7fafff] unusable
[    0.000000] Xen: [mem 0x00000000cf7fb000-0x00000000cf95ffff] reserved
[    0.000000] Xen: [mem 0x00000000cf960000-0x00000000cfb62fff] ACPI NVS
[    0.000000] Xen: [mem 0x00000000cfb63000-0x00000000cfd14fff] unusable
[    0.000000] Xen: [mem 0x00000000cfd15000-0x00000000cfd61fff] ACPI NVS
[    0.000000] Xen: [mem 0x00000000cfd62000-0x00000000cfd6cfff] ACPI data
[    0.000000] Xen: [mem 0x00000000cfd6d000-0x00000000cfd6ffff] ACPI NVS
[    0.000000] Xen: [mem 0x00000000cfd70000-0x00000000cfd70fff] unusable
[    0.000000] Xen: [mem 0x00000000cfd71000-0x00000000cfea8fff] reserved
[    0.000000] Xen: [mem 0x00000000cfea9000-0x00000000cfeb9fff] ACPI NVS
[    0.000000] Xen: [mem 0x00000000cfeba000-0x00000000cfecafff] reserved
[    0.000000] Xen: [mem 0x00000000cfecb000-0x00000000cfecbfff] ACPI NVS
[    0.000000] Xen: [mem 0x00000000cfecc000-0x00000000cfedbfff] reserved
[    0.000000] Xen: [mem 0x00000000cfedc000-0x00000000cfedcfff] ACPI NVS
[    0.000000] Xen: [mem 0x00000000cfedd000-0x00000000cfeddfff] reserved
[    0.000000] Xen: [mem 0x00000000cfede000-0x00000000cfee3fff] ACPI NVS
[    0.000000] Xen: [mem 0x00000000cfee4000-0x00000000cfef6fff] reserved
[    0.000000] Xen: [mem 0x00000000cfef7000-0x00000000cfefffff] unusable
[    0.000000] Xen: [mem 0x00000000e0000000-0x00000000efffffff] reserved
[    0.000000] Xen: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
[    0.000000] Xen: [mem 0x00000000fec10000-0x00000000fec10fff] reserved
[    0.000000] Xen: [mem 0x00000000fed00000-0x00000000fed00fff] reserved
[    0.000000] Xen: [mem 0x00000000fed40000-0x00000000fed44fff] reserved
[    0.000000] Xen: [mem 0x00000000fed61000-0x00000000fed70fff] reserved
[    0.000000] Xen: [mem 0x00000000fed80000-0x00000000fed8ffff] reserved
[    0.000000] Xen: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
[    0.000000] Xen: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
[    0.000000] Xen: [mem 0x0000000100001000-0x000000020effffff] unusable
[    0.000000] bootconsole [xenboot0] enabled
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI 2.6 present.
[    0.000000] DMI: System manufacturer System Product Name/F1A75-M, BIOS 0406 06/11/2011
[    0.000000] e820: update [mem 0x00000000-0x0000ffff] usable ==> reserved
[    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[    0.000000] No AGP bridge found
[    0.000000] e820: last_pfn = 0x4d063 max_arch_pfn = 0x400000000
[    0.000000] initial memory mapped: [mem 0x00000000-0x16bcdfff]
[    0.000000] Base memory trampoline at [ffff880000097000] 97000 size 24576
[    0.000000] init_memory_mapping: [mem 0x00000000-0x4d062fff]
[    0.000000]  [mem 0x00000000-0x4d062fff] page 4k
[    0.000000] kernel direct mapping tables up to 0x4d062fff @ [mem 0x01e21000-0x0208cfff]
[    0.000000] xen: setting RW the range 1fd3000 - 208d000
[    0.000000] RAMDISK: [mem 0x0208d000-0x16bcdfff]
[    0.000000] ACPI: RSDP 00000000000f0450 00024 (v02 ALASKA)
[    0.000000] ACPI: XSDT 00000000cfd62068 00054 (v01 ALASKA    A M I 01072009 AMI  00010013)
[    0.000000] ACPI: FACP 00000000cfd69a68 000F4 (v04 ALASKA    A M I 01072009 AMI  00010013)
[    0.000000] ACPI BIOS Bug: Warning: Optional FADT field Pm2ControlBlock has zero address or length: 0x0000000000000000/0x1 (20120913/tbfadt-598)
[    0.000000] ACPI: DSDT 00000000cfd62150 07917 (v02 ALASKA    A M I 00000000 INTL 20051117)
[    0.000000] ACPI: FACS 00000000cfedef80 00040
[    0.000000] ACPI: APIC 00000000cfd69b60 00072 (v03 ALASKA    A M I 01072009 AMI  00010013)
[    0.000000] ACPI: MCFG 00000000cfd69bd8 0003C (v01 A M I  GMCH945. 01072009 MSFT 00000097)
[    0.000000] ACPI: HPET 00000000cfd69c18 00038 (v01 ALASKA    A M I 01072009 AMI  00000004)
[    0.000000] ACPI: SSDT 00000000cfd69c50 00FD8 (v01 AMD    POWERNOW 00000001 AMD  00000001)
[    0.000000] ACPI: SSDT 00000000cfd6ac28 01923 (v02    AMD     ALIB 00000001 MSFT 04000000)
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] NUMA turned off
[    0.000000] Faking a node at [mem 0x0000000000000000-0x000000004d062fff]
[    0.000000] Initmem setup node 0 [mem 0x00000000-0x4d062fff]
[    0.000000]   NODE_DATA [mem 0x3e75f000-0x3e762fff]
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x00010000-0x00ffffff]
[    0.000000]   DMA32    [mem 0x01000000-0xffffffff]
[    0.000000]   Normal   empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x00010000-0x0009cfff]
[    0.000000]   node   0: [mem 0x00100000-0x4d062fff]
[    0.000000] On node 0 totalpages: 315376
[    0.000000]   DMA zone: 56 pages used for memmap
[    0.000000]   DMA zone: 6 pages reserved
[    0.000000]   DMA zone: 3919 pages, LIFO batch:0
[    0.000000]   DMA32 zone: 4258 pages used for memmap
[    0.000000]   DMA32 zone: 307137 pages, LIFO batch:31
[    0.000000] ACPI: PM-Timer IO Port: 0x808
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])
[    0.000000] ACPI: IOAPIC (id[0x05] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 5, version 33, address 0xfec00000, GSI 0-23
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
[    0.000000] ACPI: IRQ0 used by override.
[    0.000000] ACPI: IRQ2 used by override.
[    0.000000] ACPI: IRQ9 used by override.
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0xffffffff base: 0xfed00000
[    0.000000] smpboot: Allowing 4 CPUs, 0 hotplug CPUs
[    0.000000] nr_irqs_gsi: 40
[    0.000000] PM: Registered nosave memory: 000000000009d000 - 000000000009e000
[    0.000000] PM: Registered nosave memory: 000000000009e000 - 0000000000100000
[    0.000000] e820: [mem 0xcff00000-0xdfffffff] available for PCI devices
[    0.000000] Booting paravirtualized kernel on Xen
[    0.000000] Xen version: 4.1.4-pre (preserve-AD)
[    0.000000] setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:4 nr_node_ids:1
[    0.000000] PERCPU: Embedded 28 pages/cpu @ffff88003e000000 s84288 r8192 d22208 u524288
[    0.000000] pcpu-alloc: s84288 r8192 d22208 u524288 alloc=1*2097152
[    0.000000] pcpu-alloc: [0] 0 1 2 3 
[    2.763208] Built 1 zonelists in Node order, mobility grouping on.  Total pages: 311056
[    2.763213] Policy zone: DMA32
[    2.763218] Kernel command line: earlyprintk=xen debug nofb console=tty console=ttyS1,115200n8 xen-pciback.hide=(00:02:00) loglevel=10
[    2.763656] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    2.763663] __ex_table already sorted, skipping sort
[    2.808064] software IO TLB [mem 0x38a00000-0x3ca00000] (64MB) mapped at [ffff880038a00000-ffff88003c9fffff]
[    2.811300] Memory: 581728k/1261964k available (6413k kernel code, 460k absent, 679776k reserved, 4478k data, 752k init)
[    2.811414] Hierarchical RCU implementation.
[    2.811419] 	RCU restricting CPUs from NR_CPUS=512 to nr_cpu_ids=3.
[    2.811432] NR_IRQS:33024 nr_irqs:704 16
[    2.811514] xen: sci override: global_irq=9 trigger=0 polarity=1
[    2.811518] xen: registering gsi 9 triggering 0 polarity 1
[    2.811531] xen: --> pirq=9 -> irq=9 (gsi=9)
[    2.811539] xen: acpi sci 9
[    2.811546] xen: --> pirq=1 -> irq=1 (gsi=1)
[    2.811551] xen: --> pirq=2 -> irq=2 (gsi=2)
[    2.811557] xen: --> pirq=3 -> irq=3 (gsi=3)
[    2.811562] xen: --> pirq=4 -> irq=4 (gsi=4)
[    2.811568] xen: --> pirq=5 -> irq=5 (gsi=5)
[    2.811574] xen: --> pirq=6 -> irq=6 (gsi=6)
[    2.811579] xen: --> pirq=7 -> irq=7 (gsi=7)
[    2.811585] xen: --> pirq=8 -> irq=8 (gsi=8)
[    2.811590] xen: --> pirq=10 -> irq=10 (gsi=10)
[    2.811596] xen: --> pirq=11 -> irq=11 (gsi=11)
[    2.811602] xen: --> pirq=12 -> irq=12 (gsi=12)
[    2.811607] xen: --> pirq=13 -> irq=13 (gsi=13)
[    2.811613] xen: --> pirq=14 -> irq=14 (gsi=14)
[    2.811618] xen: --> pirq=15 -> irq=15 (gsi=15)
[    2.813454] Console: colour VGA+ 80x25
[    2.818363] console [tty0] enabled
[    2.818422] console [ttyS1] enabled, bootconsole disabled
[    2.818757] Xen: using vcpuop timer interface
[    2.819017] installing Xen timer for CPU 0
[    2.819285] tsc: Detected 2899.980 MHz processor
[    2.819555] Calibrating delay loop (skipped), value calculated using timer frequency.. 5799.96 BogoMIPS (lpj=2899980)
[    2.820151] pid_max: default: 32768 minimum: 301
[    2.820479] Security Framework initialized
[    2.820728] SELinux:  Initializing.
[    2.820948] SELinux:  Starting in permissive mode
[    2.821532] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
[    2.822565] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
[    2.823519] Mount-cache hash table entries: 256
[    2.824126] Initializing cgroup subsys cpuacct
[    2.824400] Initializing cgroup subsys freezer
[    2.824730] tseg: 00cff00000
[    2.824934] CPU: Physical Processor ID: 0
[    2.825186] CPU: Processor Core ID: 0
[    2.825417] mce: CPU supports 6 MCE banks
[    2.825696] Last level iTLB entries: 4KB 512, 2MB 16, 4MB 8
[    2.825696] Last level dTLB entries: 4KB 1024, 2MB 128, 4MB 64
[    2.825696] tlb_flushall_shift: 5
[    2.826625] Freeing SMP alternatives: 24k freed
[    2.829704] ACPI: Core revision 20120913
[    2.856787] cpu 0 spinlock event irq 41
[    2.857062] Performance Events: Broken PMU hardware detected, using software events only.
[    2.857602] Failed to access perfctr msr (MSR c0010004 is 0)
[    2.858234] MCE: In-kernel MCE decoding enabled.
[    2.858603] NMI watchdog: disabled (cpu0): hardware events not enabled
[    2.859223] installing Xen timer for CPU 1
[    2.859499] cpu 1 spinlock event irq 48
[    2.860218] installing Xen timer for CPU 2
[    2.860493] cpu 2 spinlock event irq 55
[    2.860951] Brought up 3 CPUs
[    2.864412] PM: Registering ACPI NVS region [mem 0xcf960000-0xcfb62fff] (2109440 bytes)
[    2.865989] PM: Registering ACPI NVS region [mem 0xcfd15000-0xcfd61fff] (315392 bytes)
[    2.866464] PM: Registering ACPI NVS region [mem 0xcfd6d000-0xcfd6ffff] (12288 bytes)
[    2.866931] PM: Registering ACPI NVS region [mem 0xcfea9000-0xcfeb9fff] (69632 bytes)
[    2.867404] PM: Registering ACPI NVS region [mem 0xcfecb000-0xcfecbfff] (4096 bytes)
[    2.867861] PM: Registering ACPI NVS region [mem 0xcfedc000-0xcfedcfff] (4096 bytes)
[    2.868321] PM: Registering ACPI NVS region [mem 0xcfede000-0xcfee3fff] (24576 bytes)
[    2.869081] kworker/u:0 (26) used greatest stack depth: 6120 bytes left
[    2.869105] Grant tables using version 2 layout.
[    2.869122] Grant table initialized
[    2.869164] RTC time: 16:43:55, date: 10/30/12
[    2.870366] NET: Registered protocol family 16
[    2.871181] kworker/u:0 (30) used greatest stack depth: 5504 bytes left
[    2.872440] ACPI: bus type pci registered
[    2.873480] dca service started, version 1.12.1
[    2.873891] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000)
[    2.874438] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in E820
[    2.914335] PCI: Using configuration type 1 for base access
[    2.932999] bio: create slab  at 0
[    2.933584] ACPI: Added _OSI(Module Device)
[    2.933866] ACPI: Added _OSI(Processor Device)
[    2.934145] ACPI: Added _OSI(3.0 _SCP Extensions)
[    2.934432] ACPI: Added _OSI(Processor Aggregator Device)
[    2.942011] ACPI: EC: Look up EC in DSDT
[    2.950054] ACPI: Executed 1 blocks of module-level executable AML code
[    2.956530] ACPI: Interpreter enabled
[    2.956772] ACPI: (supports S0 S3 S4 S5)
[    2.957218] ACPI: Using IOAPIC for interrupt routing
[    2.982389] ACPI: No dock devices found.
[    2.982650] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[    2.983552] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[    2.984298] PCI host bridge to bus 0000:00
[    2.984571] pci_bus 0000:00: root bus resource [bus 00-ff]
[    2.984906] pci_bus 0000:00: root bus resource [io  0x0000-0x03af]
[    2.985277] pci_bus 0000:00: root bus resource [io  0x03e0-0x0cf7]
[    2.985657] pci_bus 0000:00: root bus resource [io  0x03b0-0x03df]
[    2.986029] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
[    2.986399] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
[    2.986810] pci_bus 0000:00: root bus resource [mem 0x000c0000-0x000dffff]
[    2.987214] pci_bus 0000:00: root bus resource [mem 0xd0000000-0xffffffff]
[    2.987631] pci 0000:00:00.0: [1022:1705] type 00 class 0x060000
[    2.988106] pci 0000:00:01.0: [1002:9640] type 00 class 0x030000
[    2.988487] pci 0000:00:01.0: reg 10: [mem 0xd0000000-0xdfffffff pref]
[    2.988893] pci 0000:00:01.0: reg 14: [io  0xf000-0xf0ff]
[    2.989246] pci 0000:00:01.0: reg 18: [mem 0xfeb00000-0xfeb3ffff]
[    2.989743] pci 0000:00:01.0: supports D1 D2
[    2.990053] pci 0000:00:01.1: [1002:1714] type 00 class 0x040300
[    2.990442] pci 0000:00:01.1: reg 10: [mem 0xfeb44000-0xfeb47fff]
[    2.990965] pci 0000:00:01.1: supports D1 D2
[    2.991343] pci 0000:00:10.0: [1022:7812] type 00 class 0x0c0330
[    2.991752] pci 0000:00:10.0: reg 10: [mem 0xfeb4a000-0xfeb4bfff 64bit]
[    2.992355] pci 0000:00:10.0: PME# supported from D0 D3hot D3cold
[    2.992803] pci 0000:00:10.1: [1022:7812] type 00 class 0x0c0330
[    2.993201] pci 0000:00:10.1: reg 10: [mem 0xfeb48000-0xfeb49fff 64bit]
[    2.993793] pci 0000:00:10.1: PME# supported from D0 D3hot D3cold
[    2.994239] pci 0000:00:11.0: [1022:7801] type 00 class 0x010601
[    2.994637] pci 0000:00:11.0: reg 10: [io  0xf140-0xf147]
[    2.994982] pci 0000:00:11.0: reg 14: [io  0xf130-0xf133]
[    2.995333] pci 0000:00:11.0: reg 18: [io  0xf120-0xf127]
[    2.995678] pci 0000:00:11.0: reg 1c: [io  0xf110-0xf113]
[    2.996024] pci 0000:00:11.0: reg 20: [io  0xf100-0xf10f]
[    2.996374] pci 0000:00:11.0: reg 24: [mem 0xfeb51000-0xfeb517ff]
[    2.996850] pci 0000:00:12.0: [1022:7807] type 00 class 0x0c0310
[    2.997235] pci 0000:00:12.0: reg 10: [mem 0xfeb50000-0xfeb50fff]
[    2.997765] pci 0000:00:12.2: [1022:7808] type 00 class 0x0c0320
[    2.998161] pci 0000:00:12.2: reg 10: [mem 0xfeb4f000-0xfeb4f0ff]
[    2.998712] pci 0000:00:12.2: supports D1 D2
[    2.998977] pci 0000:00:12.2: PME# supported from D0 D1 D2 D3hot
[    2.999375] pci 0000:00:13.0: [1022:7807] type 00 class 0x0c0310
[    2.999768] pci 0000:00:13.0: reg 10: [mem 0xfeb4e000-0xfeb4efff]
[    3.000283] pci 0000:00:13.2: [1022:7808] type 00 class 0x0c0320
[    3.000681] pci 0000:00:13.2: reg 10: [mem 0xfeb4d000-0xfeb4d0ff]
[    3.001227] pci 0000:00:13.2: supports D1 D2
[    3.001495] pci 0000:00:13.2: PME# supported from D0 D1 D2 D3hot
[    3.001902] pci 0000:00:14.0: [1022:780b] type 00 class 0x0c0500
[    3.002433] pci 0000:00:14.2: [1022:780d] type 00 class 0x040300
[    3.002840] pci 0000:00:14.2: reg 10: [mem 0xfeb40000-0xfeb43fff 64bit]
[    3.003376] pci 0000:00:14.2: PME# supported from D0 D3hot D3cold
[    3.003761] pci 0000:00:14.3: [1022:780e] type 00 class 0x060100
[    3.004279] pci 0000:00:14.4: [1022:780f] type 01 class 0x060401
[    3.004730] pci 0000:00:14.5: [1022:7809] type 00 class 0x0c0310
[    3.005119] pci 0000:00:14.5: reg 10: [mem 0xfeb4c000-0xfeb4cfff]
[    3.005641] pci 0000:00:15.0: [1022:43a0] type 01 class 0x060400
[    3.006187] pci 0000:00:15.0: supports D1 D2
[    3.006515] pci 0000:00:15.1: [1022:43a1] type 01 class 0x060400
[    3.007059] pci 0000:00:15.1: supports D1 D2
[    3.007403] pci 0000:00:18.0: [1022:1700] type 00 class 0x060000
[    3.007868] pci 0000:00:18.1: [1022:1701] type 00 class 0x060000
[    3.008320] pci 0000:00:18.2: [1022:1702] type 00 class 0x060000
[    3.008778] pci 0000:00:18.3: [1022:1703] type 00 class 0x060000
[    3.009271] pci 0000:00:18.4: [1022:1704] type 00 class 0x060000
[    3.009716] pci 0000:00:18.5: [1022:1718] type 00 class 0x060000
[    3.010167] pci 0000:00:18.6: [1022:1716] type 00 class 0x060000
[    3.010615] pci 0000:00:18.7: [1022:1719] type 00 class 0x060000
[    3.011117] pci 0000:01:05.0: [9710:9835] type 00 class 0x070002
[    3.011513] pci 0000:01:05.0: reg 10: [io  0xe050-0xe057]
[    3.011861] pci 0000:01:05.0: reg 14: [io  0xe040-0xe047]
[    3.012210] pci 0000:01:05.0: reg 18: [io  0xe030-0xe037]
[    3.012563] pci 0000:01:05.0: reg 1c: [io  0xe020-0xe027]
[    3.012912] pci 0000:01:05.0: reg 20: [io  0xe010-0xe017]
[    3.013259] pci 0000:01:05.0: reg 24: [io  0xe000-0xe00f]
[    3.013710] pci 0000:00:14.4: PCI bridge to [bus 01] (subtractive decode)
[    3.014118] pci 0000:00:14.4:   bridge window [io  0xe000-0xefff]
[    3.014496] pci 0000:00:14.4:   bridge window [io  0x0000-0x03af] (subtractive decode)
[    3.014967] pci 0000:00:14.4:   bridge window [io  0x03e0-0x0cf7] (subtractive decode)
[    3.015422] pci 0000:00:14.4:   bridge window [io  0x03b0-0x03df] (subtractive decode)
[    3.015878] pci 0000:00:14.4:   bridge window [io  0x0d00-0xffff] (subtractive decode)
[    3.016343] pci 0000:00:14.4:   bridge window [mem 0x000a0000-0x000bffff] (subtractive decode)
[    3.016836] pci 0000:00:14.4:   bridge window [mem 0x000c0000-0x000dffff] (subtractive decode)
[    3.017326] pci 0000:00:14.4:   bridge window [mem 0xd0000000-0xffffffff] (subtractive decode)
[    3.017990] pci 0000:02:00.0: [8086:10d3] type 00 class 0x020000
[    3.018379] pci 0000:02:00.0: reg 10: [mem 0xfeac0000-0xfeadffff]
[    3.018769] pci 0000:02:00.0: reg 14: [mem 0xfea00000-0xfea7ffff]
[    3.019167] pci 0000:02:00.0: reg 18: [io  0xd000-0xd01f]
[    3.019522] pci 0000:02:00.0: reg 1c: [mem 0xfeae0000-0xfeae3fff]
[    3.019964] pci 0000:02:00.0: reg 30: [mem 0xfea80000-0xfeabffff pref]
[    3.020508] pci 0000:02:00.0: PME# supported from D0 D3hot D3cold
[    3.023962] pci 0000:00:15.0: PCI bridge to [bus 02]
[    3.024307] pci 0000:00:15.0:   bridge window [io  0xd000-0xdfff]
[    3.024689] pci 0000:00:15.0:   bridge window [mem 0xfea00000-0xfeafffff]
[    3.025293] pci 0000:03:00.0: [1969:1083] type 00 class 0x020000
[    3.025712] pci 0000:03:00.0: reg 10: [mem 0xfe900000-0xfe93ffff 64bit]
[    3.026139] pci 0000:03:00.0: reg 18: [io  0xc000-0xc07f]
[    3.026691] pci 0000:03:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[    3.028949] pci 0000:00:15.1: PCI bridge to [bus 03]
[    3.029290] pci 0000:00:15.1:   bridge window [io  0xc000-0xcfff]
[    3.029671] pci 0000:00:15.1:   bridge window [mem 0xfe900000-0xfe9fffff]
[    3.030148] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
[    3.030844] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PE20._PRT]
[    3.031280] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PE21._PRT]
[    3.031782] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0PC._PRT]
[    3.032377]  pci0000:00: Requesting ACPI _OSC control (0x1d)
[    3.032947]  pci0000:00: ACPI _OSC control (0x1d) granted
[    3.051344] ACPI: PCI Interrupt Link [LN24] (IRQs *24)
[    3.051852] ACPI: PCI Interrupt Link [LN25] (IRQs *25)
[    3.052329] ACPI: PCI Interrupt Link [LN26] (IRQs *26)
[    3.052821] ACPI: PCI Interrupt Link [LN27] (IRQs *27)
[    3.053298] ACPI: PCI Interrupt Link [LN28] (IRQs *28)
[    3.053787] ACPI: PCI Interrupt Link [LN29] (IRQs *29)
[    3.054271] ACPI: PCI Interrupt Link [LN30] (IRQs *30)
[    3.054747] ACPI: PCI Interrupt Link [LN31] (IRQs *31)
[    3.055243] ACPI: PCI Interrupt Link [LN32] (IRQs *32)
[    3.055724] ACPI: PCI Interrupt Link [LN33] (IRQs *33)
[    3.056211] ACPI: PCI Interrupt Link [LN34] (IRQs *34)
[    3.056692] ACPI: PCI Interrupt Link [LN35] (IRQs *35)
[    3.057187] ACPI: PCI Interrupt Link [LN36] (IRQs *36)
[    3.057673] ACPI: PCI Interrupt Link [LN37] (IRQs *37)
[    3.058165] ACPI: PCI Interrupt Link [LN38] (IRQs *38)
[    3.058660] ACPI: PCI Interrupt Link [LN39] (IRQs *39)
[    3.059154] ACPI: PCI Interrupt Link [LN40] (IRQs *40)
[    3.059643] ACPI: PCI Interrupt Link [LN41] (IRQs *41)
[    3.060128] ACPI: PCI Interrupt Link [LN42] (IRQs *42)
[    3.060618] ACPI: PCI Interrupt Link [LN43] (IRQs *43)
[    3.061095] ACPI: PCI Interrupt Link [LN44] (IRQs *44)
[    3.061575] ACPI: PCI Interrupt Link [LN45] (IRQs *45)
[    3.062059] ACPI: PCI Interrupt Link [LN46] (IRQs *46)
[    3.062543] ACPI: PCI Interrupt Link [LN47] (IRQs *47)
[    3.063029] ACPI: PCI Interrupt Link [LN48] (IRQs *48)
[    3.063506] ACPI: PCI Interrupt Link [LN49] (IRQs *49)
[    3.063989] ACPI: PCI Interrupt Link [LN50] (IRQs *50)
[    3.064473] ACPI: PCI Interrupt Link [LN51] (IRQs *51)
[    3.064950] ACPI: PCI Interrupt Link [LN52] (IRQs *52)
[    3.065440] ACPI: PCI Interrupt Link [LN53] (IRQs *53)
[    3.065918] ACPI: PCI Interrupt Link [LN54] (IRQs *54)
[    3.066402] ACPI: PCI Interrupt Link [LN55] (IRQs *55)
[    3.066889] ACPI: PCI Interrupt Link [LNKA] (IRQs 4 5 7 10 11 14 15) *0
[    3.068826] ACPI: PCI Interrupt Link [LNKB] (IRQs 4 5 7 10 11 14 15) *0
[    3.069717] ACPI: PCI Interrupt Link [LNKC] (IRQs 4 5 7 10 11 14 15) *0
[    3.070606] ACPI: PCI Interrupt Link [LNKD] (IRQs 4 5 7 10 11 14 15) *0
[    3.071479] ACPI: PCI Interrupt Link [LNKE] (IRQs 4 5 7 10 11 14 15) *0
[    3.072339] ACPI: PCI Interrupt Link [LNKF] (IRQs 4 5 7 10 11 14 15) *0
[    3.073195] ACPI: PCI Interrupt Link [LNKG] (IRQs 4 5 7 10 11 14 15) *0
[    3.074064] ACPI: PCI Interrupt Link [LNKH] (IRQs 4 5 7 10 11 14 15) *0
[    3.075123] xen/balloon: Initialising balloon driver.
[    3.076280] xen-balloon: Initialising balloon driver.
[    3.076885] xen/balloon: Xen selfballooning driver disabled for domain0.
[    3.077545] vgaarb: device added: PCI:0000:00:01.0,decodes=io+mem,owns=io+mem,locks=none
[    3.078080] vgaarb: loaded
[    3.078268] vgaarb: bridge control possible 0000:00:01.0
[    3.078970] ACPI: bus type usb registered
[    3.079409] usbcore: registered new interface driver usbfs
[    3.079813] usbcore: registered new interface driver hub
[    3.080257] usbcore: registered new device driver usb
[    3.081098] PCI: Using ACPI for IRQ routing
[    3.098106] PCI: pci_cache_line_size set to 64 bytes
[    3.098606] e820: reserve RAM buffer [mem 0x0009d000-0x0009ffff]
[    3.098972] e820: reserve RAM buffer [mem 0x4d063000-0x4fffffff]
[    3.099810] NetLabel: Initializing
[    3.100040] NetLabel:  domain hash size = 128
[    3.100313] NetLabel:  protocols = UNLABELED CIPSOv4
[    3.100639] NetLabel:  unlabeled traffic allowed by default
[    3.101361] Switching to clocksource xen
[    3.109135] pnp: PnP ACPI init
[    3.109362] ACPI: bus type pnp registered
[    3.109832] pnp 00:00: [bus 00-ff]
[    3.110058] pnp 00:00: [io  0x0cf8-0x0cff]
[    3.110319] pnp 00:00: [io  0x0000-0x03af window]
[    3.110611] pnp 00:00: [io  0x03e0-0x0cf7 window]
[    3.110912] pnp 00:00: [io  0x03b0-0x03df window]
[    3.111200] pnp 00:00: [io  0x0d00-0xffff window]
[    3.111492] pnp 00:00: [mem 0x000a0000-0x000bffff window]
[    3.111826] pnp 00:00: [mem 0x000c0000-0x000dffff window]
[    3.112154] pnp 00:00: [mem 0xd0000000-0xffffffff window]
[    3.112482] pnp 00:00: [mem 0x00000000 window]
[    3.113097] pnp 00:00: Plug and Play ACPI device, IDs PNP0a03 (active)
[    3.113537] pnp 00:01: [mem 0xe0000000-0xefffffff]
[    3.114213] system 00:01: [mem 0xe0000000-0xefffffff] has been reserved
[    3.114626] system 00:01: Plug and Play ACPI device, IDs PNP0c01 (active)
[    3.116690] pnp 00:02: [io  0x0010-0x001f]
[    3.116955] pnp 00:02: [io  0x0022-0x003f]
[    3.117210] pnp 00:02: [io  0x0063]
[    3.117439] pnp 00:02: [io  0x0065]
[    3.117667] pnp 00:02: [io  0x0067-0x006f]
[    3.117932] pnp 00:02: [io  0x0072-0x007f]
[    3.118191] pnp 00:02: [io  0x0080]
[    3.118415] pnp 00:02: [io  0x0084-0x0086]
[    3.118668] pnp 00:02: [io  0x0088]
[    3.118910] pnp 00:02: [io  0x008c-0x008e]
[    3.119174] pnp 00:02: [io  0x0090-0x009f]
[    3.119436] pnp 00:02: [io  0x00a2-0x00bf]
[    3.119706] pnp 00:02: [io  0x00b1]
[    3.119936] pnp 00:02: [io  0x00e0-0x00ef]
[    3.120194] pnp 00:02: [io  0x04d0-0x04d1]
[    3.120455] pnp 00:02: [io  0x040b]
[    3.120683] pnp 00:02: [io  0x04d6]
[    3.120916] pnp 00:02: [io  0x0c00-0x0c01]
[    3.121172] pnp 00:02: [io  0x0c14]
[    3.121397] pnp 00:02: [io  0x0c50-0x0c51]
[    3.121653] pnp 00:02: [io  0x0c52]
[    3.121885] pnp 00:02: [io  0x0c6c]
[    3.122109] pnp 00:02: [io  0x0c6f]
[    3.122335] pnp 00:02: [io  0x0cd0-0x0cd1]
[    3.122591] pnp 00:02: [io  0x0cd2-0x0cd3]
[    3.122860] pnp 00:02: [io  0x0cd4-0x0cd5]
[    3.123120] pnp 00:02: [io  0x0cd6-0x0cd7]
[    3.123377] pnp 00:02: [io  0x0cd8-0x0cdf]
[    3.123633] pnp 00:02: [io  0x0800-0x089f]
[    3.123898] pnp 00:02: [io  0x0000-0xffffffffffffffff disabled]
[    3.124249] pnp 00:02: [io  0x0000-0x000f]
[    3.124506] pnp 00:02: [io  0x0b20-0x0b3f]
[    3.124768] pnp 00:02: [io  0x0900-0x090f]
[    3.125026] pnp 00:02: [io  0x0910-0x091f]
[    3.125282] pnp 00:02: [io  0xfe00-0xfefe]
[    3.125537] pnp 00:02: [io  0x0060-0x005f disabled]
[    3.125841] pnp 00:02: [io  0x0064-0x0063 disabled]
[    3.126136] pnp 00:02: [mem 0xfec00000-0xfec00fff]
[    3.126426] pnp 00:02: [mem 0xfee00000-0xfee00fff]
[    3.126724] pnp 00:02: [mem 0xfed80000-0xfed8ffff]
[    3.127024] pnp 00:02: [mem 0xfed61000-0xfed70fff]
[    3.127321] pnp 00:02: [mem 0xfec10000-0xfec10fff]
[    3.127619] pnp 00:02: [mem 0xfed00000-0xfed00fff]
[    3.127920] pnp 00:02: [mem 0xff000000-0xffffffff]
[    3.128629] system 00:02: [io  0x04d0-0x04d1] has been reserved
[    3.129033] system 00:02: [io  0x040b] has been reserved
[    3.129358] system 00:02: [io  0x04d6] has been reserved
[    3.129680] system 00:02: [io  0x0c00-0x0c01] has been reserved
[    3.130042] system 00:02: [io  0x0c14] has been reserved
[    3.130365] system 00:02: [io  0x0c50-0x0c51] has been reserved
[    3.130727] system 00:02: [io  0x0c52] has been reserved
[    3.131046] system 00:02: [io  0x0c6c] has been reserved
[    3.131369] system 00:02: [io  0x0c6f] has been reserved
[    3.131692] system 00:02: [io  0x0cd0-0x0cd1] has been reserved
[    3.132047] system 00:02: [io  0x0cd2-0x0cd3] has been reserved
[    3.132401] system 00:02: [io  0x0cd4-0x0cd5] has been reserved
[    3.132756] system 00:02: [io  0x0cd6-0x0cd7] has been reserved
[    3.133111] system 00:02: [io  0x0cd8-0x0cdf] has been reserved
[    3.133460] system 00:02: [io  0x0800-0x089f] has been reserved
[    3.133814] system 00:02: [io  0x0b20-0x0b3f] has been reserved
[    3.134168] system 00:02: [io  0x0900-0x090f] has been reserved
[    3.134524] system 00:02: [io  0x0910-0x091f] has been reserved
[    3.134888] system 00:02: [io  0xfe00-0xfefe] has been reserved
[    3.135250] system 00:02: [mem 0xfec00000-0xfec00fff] could not be reserved
[    3.135651] system 00:02: [mem 0xfee00000-0xfee00fff] has been reserved
[    3.136053] system 00:02: [mem 0xfed80000-0xfed8ffff] has been reserved
[    3.136437] system 00:02: [mem 0xfed61000-0xfed70fff] has been reserved
[    3.136829] system 00:02: [mem 0xfec10000-0xfec10fff] has been reserved
[    3.137219] system 00:02: [mem 0xfed00000-0xfed00fff] has been reserved
[    3.137608] system 00:02: [mem 0xff000000-0xffffffff] has been reserved
[    3.138015] system 00:02: Plug and Play ACPI device, IDs PNP0c02 (active)
[    3.138611] pnp 00:03: [io  0x0000-0xffffffffffffffff disabled]
[    3.138981] pnp 00:03: [io  0x0300-0x031f]
[    3.139249] pnp 00:03: [io  0x0290-0x029f]
[    3.139512] pnp 00:03: [io  0x0230-0x023f]
[    3.140070] system 00:03: [io  0x0300-0x031f] has been reserved
[    3.140431] system 00:03: [io  0x0290-0x029f] has been reserved
[    3.140800] system 00:03: [io  0x0230-0x023f] has been reserved
[    3.141165] system 00:03: Plug and Play ACPI device, IDs PNP0c02 (active)
[    3.141595] pnp 00:04: [dma 4]
[    3.141809] pnp 00:04: [io  0x0000-0x000f]
[    3.142070] pnp 00:04: [io  0x0081-0x0083]
[    3.142330] pnp 00:04: [io  0x0087]
[    3.142557] pnp 00:04: [io  0x0089-0x008b]
[    3.142825] pnp 00:04: [io  0x008f]
[    3.143052] pnp 00:04: [io  0x00c0-0x00df]
[    3.143532] pnp 00:04: Plug and Play ACPI device, IDs PNP0200 (active)
[    3.143961] pnp 00:05: [io  0x0070-0x0071]
[    3.144222] xen: registering gsi 8 triggering 1 polarity 0
[    3.144562] pnp 00:05: [irq 8]
[    3.145001] pnp 00:05: Plug and Play ACPI device, IDs PNP0b00 (active)
[    3.145408] pnp 00:06: [io  0x0061]
[    3.145932] pnp 00:06: Plug and Play ACPI device, IDs PNP0800 (active)
[    3.146422] pnp 00:07: [io  0x0010-0x001f]
[    3.146682] pnp 00:07: [io  0x0022-0x003f]
[    3.146977] pnp 00:07: [io  0x0044-0x005f]
[    3.147238] pnp 00:07: [io  0x0072-0x007f]
[    3.147491] pnp 00:07: [io  0x0080]
[    3.147722] pnp 00:07: [io  0x0084-0x0086]
[    3.147980] pnp 00:07: [io  0x0088]
[    3.148211] pnp 00:07: [io  0x008c-0x008e]
[    3.148469] pnp 00:07: [io  0x0090-0x009f]
[    3.148734] pnp 00:07: [io  0x00a2-0x00bf]
[    3.148988] pnp 00:07: [io  0x00e0-0x00ef]
[    3.149250] pnp 00:07: [io  0x04d0-0x04d1]
[    3.149697] system 00:07: [io  0x04d0-0x04d1] has been reserved
[    3.150061] system 00:07: Plug and Play ACPI device, IDs PNP0c02 (active)
[    3.150478] pnp 00:08: [io  0x00f0-0x00ff]
[    3.150755] xen: registering gsi 13 triggering 1 polarity 0
[    3.151101] pnp 00:08: [irq 13]
[    3.151448] pnp 00:08: Plug and Play ACPI device, IDs PNP0c04 (active)
[    3.152100] system 00:09: Plug and Play ACPI device, IDs PNP0c02 (active)
[    3.152778] pnp 00:0a: [io  0x03f8-0x03ff]
[    3.153037] xen: registering gsi 4 triggering 1 polarity 0
[    3.153376] pnp 00:0a: [irq 4]
[    3.153581] pnp 00:0a: [dma 0 disabled]
[    3.153998] pnp 00:0a: Plug and Play ACPI device, IDs PNP0501 (active)
[    3.155394] pnp 00:0b: [mem 0xfed00000-0xfed003ff]
[    3.155978] pnp 00:0b: Plug and Play ACPI device, IDs PNP0103 (active)
[    3.156388] pnp: PnP ACPI: found 12 devices
[    3.156653] ACPI: ACPI bus type pnp unregistered
[    3.156953] xen-pciback: Error parsing pci_devs_to_hide at "(00:02:00)"
[    3.170459] PM-Timer failed consistency check  (0x0xffffff) - aborting.
[    3.170947] pci 0000:00:14.4: PCI bridge to [bus 01]
[    3.171261] pci 0000:00:14.4:   bridge window [io  0xe000-0xefff]
[    3.171655] pci 0000:00:15.0: PCI bridge to [bus 02]
[    3.171974] pci 0000:00:15.0:   bridge window [io  0xd000-0xdfff]
[    3.172345] pci 0000:00:15.0:   bridge window [mem 0xfea00000-0xfeafffff]
[    3.172762] pci 0000:00:15.1: PCI bridge to [bus 03]
[    3.173067] pci 0000:00:15.1:   bridge window [io  0xc000-0xcfff]
[    3.173436] pci 0000:00:15.1:   bridge window [mem 0xfe900000-0xfe9fffff]
[    3.173889] xen: registering gsi 16 triggering 0 polarity 1
[    3.174247] xen: --> pirq=16 -> irq=16 (gsi=16)
[    3.174547] xen: registering gsi 16 triggering 0 polarity 1
[    3.174894] Already setup the GSI :16
[    3.175131] pci_bus 0000:00: resource 4 [io  0x0000-0x03af]
[    3.175470] pci_bus 0000:00: resource 5 [io  0x03e0-0x0cf7]
[    3.176854] pci_bus 0000:00: resource 6 [io  0x03b0-0x03df]
[    3.177184] pci_bus 0000:00: resource 7 [io  0x0d00-0xffff]
[    3.177514] pci_bus 0000:00: resource 8 [mem 0x000a0000-0x000bffff]
[    3.177891] pci_bus 0000:00: resource 9 [mem 0x000c0000-0x000dffff]
[    3.178267] pci_bus 0000:00: resource 10 [mem 0xd0000000-0xffffffff]
[    3.178649] pci_bus 0000:01: resource 0 [io  0xe000-0xefff]
[    3.178994] pci_bus 0000:01: resource 4 [io  0x0000-0x03af]
[    3.179326] pci_bus 0000:01: resource 5 [io  0x03e0-0x0cf7]
[    3.179672] pci_bus 0000:01: resource 6 [io  0x03b0-0x03df]
[    3.180015] pci_bus 0000:01: resource 7 [io  0x0d00-0xffff]
[    3.180344] pci_bus 0000:01: resource 8 [mem 0x000a0000-0x000bffff]
[    3.180716] pci_bus 0000:01: resource 9 [mem 0x000c0000-0x000dffff]
[    3.181081] pci_bus 0000:01: resource 10 [mem 0xd0000000-0xffffffff]
[    3.181452] pci_bus 0000:02: resource 0 [io  0xd000-0xdfff]
[    3.181792] pci_bus 0000:02: resource 1 [mem 0xfea00000-0xfeafffff]
[    3.182168] pci_bus 0000:03: resource 0 [io  0xc000-0xcfff]
[    3.182505] pci_bus 0000:03: resource 1 [mem 0xfe900000-0xfe9fffff]
[    3.183045] NET: Registered protocol family 2
[    3.184322] TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
[    3.186023] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[    3.186732] TCP: Hash tables configured (established 262144 bind 65536)
[    3.187181] TCP: reno registered
[    3.187411] UDP hash table entries: 1024 (order: 3, 32768 bytes)
[    3.187803] UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes)
[    3.188405] NET: Registered protocol family 1
[    3.188924] RPC: Registered named UNIX socket transport module.
[    3.189285] RPC: Registered udp transport module.
[    3.189588] RPC: Registered tcp transport module.
[    3.189901] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    3.190306] pci 0000:00:01.0: Boot video device
[    3.190606] xen: registering gsi 18 triggering 0 polarity 1
[    3.190967] xen: --> pirq=18 -> irq=18 (gsi=18)
[    3.191310] xen: registering gsi 17 triggering 0 polarity 1
[    3.191651] xen: --> pirq=17 -> irq=17 (gsi=17)
[    3.191987] xen: registering gsi 18 triggering 0 polarity 1
[    3.192322] Already setup the GSI :18
[    3.779210] xen: registering gsi 17 triggering 0 polarity 1
[    3.779560] Already setup the GSI :17
[    3.779854] xen: registering gsi 18 triggering 0 polarity 1
[    3.780189] Already setup the GSI :18
[    3.852950] xen: registering gsi 17 triggering 0 polarity 1
[    3.853302] Already setup the GSI :17
[    3.853601] xen: registering gsi 18 triggering 0 polarity 1
[    3.853944] Already setup the GSI :18
[    3.927246] PCI: CLS 64 bytes, default 64
[    3.927731] Unpacking initramfs...
[    4.409499] Freeing initrd memory: 339204k freed
[    4.502233] Machine check injector initialized
[    4.504138] microcode: CPU0: patch_level=0x0300000f
[    4.504463] microcode: CPU1: patch_level=0x0300000f
[    4.504809] microcode: CPU2: patch_level=0x0300000f
[    4.505347] microcode: Microcode Update Driver: v2.00 , Peter Oruba
[    4.506684] audit: initializing netlink socket (disabled)
[    4.507060] type=2000 audit(1351615437.471:1): initialized
[    4.520849] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[    4.521549] VFS: Disk quotas dquot_6.5.2
[    4.521865] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    4.522596] NFS: Registering the id_resolver key type
[    4.522935] Key type id_resolver registered
[    4.523199] Key type id_legacy registered
[    4.523463] NTFS driver 2.1.30 [Flags: R/W].
[    4.523927] msgmni has been set to 1798
[    4.524230] SELinux:  Registering netfilter hooks
[    4.526131] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
[    4.526572] io scheduler noop registered
[    4.526834] io scheduler deadline registered
[    4.527129] io scheduler cfq registered (default)
[    4.528468] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[    4.529395] input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input0
[    4.529907] ACPI: Power Button [PWRB]
[    4.530299] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
[    4.530782] ACPI: Power Button [PWRF]
[    4.592637] GHES: HEST is not enabled!
[    4.592910] ioatdma: Intel(R) QuickData Technology Driver 4.00
[    4.594402] xen-pciback: backend is vpci
[    4.666851] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    4.688746] 00:0a: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[    4.692137] xen: registering gsi 20 triggering 0 polarity 1
[    4.692685] xen: --> pirq=20 -> irq=20 (gsi=20)
[    4.715090] 0000:01:05.0: ttyS1 at I/O 0xe050 (irq = 20) is a 16550A
[    4.723123] hpet_acpi_add: no address or irqs in _CRS
[    4.729073] Non-volatile memory driver v1.3
[    4.733807] Linux agpgart interface v0.103
[    4.739678] [drm] Initialized drm 1.1.0 20060810
[    4.747593] loop: module loaded
[    4.751865] libphy: Fixed MDIO Bus: probed
[    4.756157] tun: Universal TUN/TAP device driver, 1.6
[    4.761408] tun: (C) 1999-2004 Max Krasnyansky 
[    4.768474] ixgbevf: Intel(R) 10 Gigabit PCI Express Virtual Function Network Driver - version 2.6.0-k
[    4.778143] ixgbevf: Copyright (c) 2009 - 2012 Intel Corporation.
[    4.786308] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    4.793112] ehci_hcd: block sizes: qh 104 qtd 96 itd 192 sitd 96
[    4.799394] xen: registering gsi 17 triggering 0 polarity 1
[    4.805186] Already setup the GSI :17
[    4.809041] ehci_hcd 0000:00:12.2: EHCI Host Controller
[    4.814827] ehci_hcd 0000:00:12.2: new USB bus registered, assigned bus number 1
[    4.822582] QUIRK: Enable AMD PLL fix
[    4.826402] ehci_hcd 0000:00:12.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround
[    4.835422] ehci_hcd 0000:00:12.2: reset hcs_params 0x101505 dbg=1 cc=1 pcc=5 ordered !ppc ports=5
[    4.844716] ehci_hcd 0000:00:12.2: reset hcc_params a076 thresh 7 uframes 256/512/1024 park
[    4.853444] ehci_hcd 0000:00:12.2: park 0
[    4.857628] ehci_hcd 0000:00:12.2: reset command 0080b02  park=3 ithresh=8 period=1024 Reset HALT
[    4.866843] ehci_hcd 0000:00:12.2: debug port 1
[    4.871568] ehci_hcd 0000:00:12.2: MWI active
[    4.876100] ehci_hcd 0000:00:12.2: supports USB remote wakeup
[    4.882116] ehci_hcd 0000:00:12.2: irq 17, io mem 0xfeb4f000
[    4.887997] ehci_hcd 0000:00:12.2: init command 0010005 (park)=0 ithresh=1 period=512 RUN
[    4.901882] ehci_hcd 0000:00:12.2: USB 2.0 started, EHCI 1.00
[    4.907965] usb usb1: default language 0x0409
[    4.912513] usb usb1: udev 1, busnum 1, minor = 0
[    4.917409] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[    4.924454] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    4.931952] usb usb1: Product: EHCI Host Controller
[    4.937024] usb usb1: Manufacturer: Linux 3.7.0-rc3upstream-00220-g37b7153 ehci_hcd
[    4.944967] usb usb1: SerialNumber: 0000:00:12.2
[    4.950259] usb usb1: usb_probe_device
[    4.954193] usb usb1: configuration #1 chosen from 1 choice
[    4.959997] usb usb1: adding 1-0:1.0 (config #1, interface 0)
[    4.966339] hub 1-0:1.0: usb_probe_interface
[    4.970812] hub 1-0:1.0: usb_probe_interface - got id
[    4.976063] hub 1-0:1.0: USB hub found
[    4.979980] hub 1-0:1.0: 5 ports detected
[    4.984155] hub 1-0:1.0: standalone hub
[    4.988148] hub 1-0:1.0: no power switching (usb 1.0)
[    4.993398] hub 1-0:1.0: individual port over-current protection
[    4.999631] hub 1-0:1.0: power on to power good time: 20ms
[    5.005333] hub 1-0:1.0: local power source is good
[    5.010998] hub 1-0:1.0: trying to enable port power on non-switchable hub
[    5.018235] xen: registering gsi 17 triggering 0 polarity 1
[    5.024028] Already setup the GSI :17
[    5.027880] ehci_hcd 0000:00:13.2: EHCI Host Controller
[    5.033663] ehci_hcd 0000:00:13.2: new USB bus registered, assigned bus number 2
[    5.041377] ehci_hcd 0000:00:13.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround
[    5.050398] ehci_hcd 0000:00:13.2: reset hcs_params 0x101505 dbg=1 cc=1 pcc=5 ordered !ppc ports=5
[    5.059685] ehci_hcd 0000:00:13.2: reset hcc_params a076 thresh 7 uframes 256/512/1024 park
[    5.068427] ehci_hcd 0000:00:13.2: park 0
[    5.072610] ehci_hcd 0000:00:13.2: reset command 0080b02  park=3 ithresh=8 period=1024 Reset HALT
[    5.081823] ehci_hcd 0000:00:13.2: debug port 1
[    5.086547] ehci_hcd 0000:00:13.2: MWI active
[    5.091081] ehci_hcd 0000:00:13.2: supports USB remote wakeup
[    5.097059] ehci_hcd 0000:00:13.2: irq 17, io mem 0xfeb4d000
[    5.102937] ehci_hcd 0000:00:13.2: init command 0010005 (park)=0 ithresh=1 period=512 RUN
[    5.116889] ehci_hcd 0000:00:13.2: USB 2.0 started, EHCI 1.00
[    5.123004] usb usb2: default language 0x0409
[    5.127553] usb usb2: udev 1, busnum 2, minor = 128
[    5.132627] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
[    5.139668] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    5.147164] usb usb2: Product: EHCI Host Controller
[    5.152236] usb usb2: Manufacturer: Linux 3.7.0-rc3upstream-00220-g37b7153 ehci_hcd
[    5.160180] usb usb2: SerialNumber: 0000:00:13.2
[    5.165185] hub 1-0:1.0: state 7 ports 5 chg 0000 evt 0000
[    5.165547] usb usb2: usb_probe_device
[    5.165551] usb usb2: configuration #1 chosen from 1 choice
[    5.165570] usb usb2: adding 2-0:1.0 (config #1, interface 0)
[    5.165905] hub 2-0:1.0: usb_probe_interface
[    5.165908] hub 2-0:1.0: usb_probe_interface - got id
[    5.165911] hub 2-0:1.0: USB hub found
[    5.165929] hub 2-0:1.0: 5 ports detected
[    5.165930] hub 2-0:1.0: standalone hub
[    5.165931] hub 2-0:1.0: no power switching (usb 1.0)
[    5.165933] hub 2-0:1.0: individual port over-current protection
[    5.165935] hub 2-0:1.0: power on to power good time: 20ms
[    5.165942] hub 2-0:1.0: local power source is good
[    5.166518] hub 2-0:1.0: trying to enable port power on non-switchable hub
[    5.166966] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    5.166969] ohci_hcd: block sizes: ed 80 td 96
[    5.167028] xen: registering gsi 18 triggering 0 polarity 1
[    5.167033] Already setup the GSI :18
[    5.167075] ohci_hcd 0000:00:12.0: OHCI Host Controller
[    5.167260] ohci_hcd 0000:00:12.0: new USB bus registered, assigned bus number 3
[    5.167338] ohci_hcd 0000:00:12.0: created debug files
[    5.167340] ohci_hcd 0000:00:12.0: supports USB remote wakeup
[    5.167385] ohci_hcd 0000:00:12.0: irq 18, io mem 0xfeb50000
[    5.289966] hub 2-0:1.0: state 7 ports 5 chg 0000 evt 0000
[    5.293989] ohci_hcd 0000:00:12.0: OHCI controller state
[    5.293995] ohci_hcd 0000:00:12.0: OHCI 1.0, NO legacy support registers, rh state running
[    5.293999] ohci_hcd 0000:00:12.0: control 0x283 RWC HCFS=operational CBSR=3
[    5.294002] ohci_hcd 0000:00:12.0: cmdstatus 0x00000 SOC=0
[    5.294006] ohci_hcd 0000:00:12.0: intrstatus 0x00000004 SF
[    5.294009] ohci_hcd 0000:00:12.0: intrenable 0x8000005a MIE RHSC UE RD WDH
[    5.294019] ohci_hcd 0000:00:12.0: hcca frame #0005
[    5.294022] ohci_hcd 0000:00:12.0: roothub.a 02001205 POTPGT=2 NOCP NPS NDP=5(5)
[    5.294025] ohci_hcd 0000:00:12.0: roothub.b 00000000 PPCM=0000 DR=0000
[    5.294027] ohci_hcd 0000:00:12.0: roothub.status 00008000 DRWE
[    5.294031] ohci_hcd 0000:00:12.0: roothub.portstatus [0] 0x00000100 PPS
[    5.294034] ohci_hcd 0000:00:12.0: roothub.portstatus [1] 0x00000100 PPS
[    5.294037] ohci_hcd 0000:00:12.0: roothub.portstatus [2] 0x00000100 PPS
[    5.294041] ohci_hcd 0000:00:12.0: roothub.portstatus [3] 0x00000100 PPS
[    5.294044] ohci_hcd 0000:00:12.0: roothub.portstatus [4] 0x00000100 PPS
[    5.294080] usb usb3: default language 0x0409
[    5.294093] usb usb3: udev 1, busnum 3, minor = 256
[    5.294095] usb usb3: New USB device found, idVendor=1d6b, idProduct=0001
[    5.294097] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    5.294098] usb usb3: Product: OHCI Host Controller
[    5.294100] usb usb3: Manufacturer: Linux 3.7.0-rc3upstream-00220-g37b7153 ohci_hcd
[    5.294101] usb usb3: SerialNumber: 0000:00:12.0
[    5.294371] usb usb3: usb_probe_device
[    5.294374] usb usb3: configuration #1 chosen from 1 choice
[    5.294386] usb usb3: adding 3-0:1.0 (config #1, interface 0)
[    5.294481] hub 3-0:1.0: usb_probe_interface
[    5.294482] hub 3-0:1.0: usb_probe_interface - got id
[    5.294484] hub 3-0:1.0: USB hub found
[    5.294492] hub 3-0:1.0: 5 ports detected
[    5.294493] hub 3-0:1.0: standalone hub
[    5.294495] hub 3-0:1.0: no power switching (usb 1.0)
[    5.294496] hub 3-0:1.0: no over-current protection
[    5.294497] hub 3-0:1.0: power on to power good time: 4ms
[    5.294505] hub 3-0:1.0: local power source is good
[    5.295074] hub 3-0:1.0: trying to enable port power on non-switchable hub
[    5.295131] ehci_hcd 0000:00:12.2: HS companion for 0000:00:12.0
[    5.295174] xen: registering gsi 18 triggering 0 polarity 1
[    5.295178] Already setup the GSI :18
[    5.295219] ohci_hcd 0000:00:13.0: OHCI Host Controller
[    5.295337] ohci_hcd 0000:00:13.0: new USB bus registered, assigned bus number 4
[    5.295397] ohci_hcd 0000:00:13.0: created debug files
[    5.295399] ohci_hcd 0000:00:13.0: supports USB remote wakeup
[    5.295409] ohci_hcd 0000:00:13.0: irq 18, io mem 0xfeb4e000
[    5.549971] hub 3-0:1.0: state 7 ports 5 chg 0000 evt 0000
[    5.553975] ohci_hcd 0000:00:13.0: OHCI controller state
[    5.553980] ohci_hcd 0000:00:13.0: OHCI 1.0, NO legacy support registers, rh state running
[    5.553984] ohci_hcd 0000:00:13.0: control 0x283 RWC HCFS=operational CBSR=3
[    5.553987] ohci_hcd 0000:00:13.0: cmdstatus 0x00000 SOC=0
[    5.553990] ohci_hcd 0000:00:13.0: intrstatus 0x00000004 SF
[    5.553993] ohci_hcd 0000:00:13.0: intrenable 0x8000005a MIE RHSC UE RD WDH
[    5.554004] ohci_hcd 0000:00:13.0: hcca frame #0005
[    5.554008] ohci_hcd 0000:00:13.0: roothub.a 02001205 POTPGT=2 NOCP NPS NDP=5(5)
[    5.554011] ohci_hcd 0000:00:13.0: roothub.b 00000000 PPCM=0000 DR=0000
[    5.554014] ohci_hcd 0000:00:13.0: roothub.status 00008000 DRWE
[    5.554018] ohci_hcd 0000:00:13.0: roothub.portstatus [0] 0x00000100 PPS
[    5.554021] ohci_hcd 0000:00:13.0: roothub.portstatus [1] 0x00000100 PPS
[    5.554025] ohci_hcd 0000:00:13.0: roothub.portstatus [2] 0x00000100 PPS
[    5.554028] ohci_hcd 0000:00:13.0: roothub.portstatus [3] 0x00000100 PPS
[    5.554031] ohci_hcd 0000:00:13.0: roothub.portstatus [4] 0x00000100 PPS
[    5.554051] usb usb4: default language 0x0409
[    5.554064] usb usb4: udev 1, busnum 4, minor = 384
[    5.554066] usb usb4: New USB device found, idVendor=1d6b, idProduct=0001
[    5.554068] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    5.554070] usb usb4: Product: OHCI Host Controller
[    5.554071] usb usb4: Manufacturer: Linux 3.7.0-rc3upstream-00220-g37b7153 ohci_hcd
[    5.554072] usb usb4: SerialNumber: 0000:00:13.0
[    5.554538] usb usb4: usb_probe_device
[    5.554542] usb usb4: configuration #1 chosen from 1 choice
[    5.554559] usb usb4: adding 4-0:1.0 (config #1, interface 0)
[    5.554665] hub 4-0:1.0: usb_probe_interface
[    5.554667] hub 4-0:1.0: usb_probe_interface - got id
[    5.554669] hub 4-0:1.0: USB hub found
[    5.554678] hub 4-0:1.0: 5 ports detected
[    5.554679] hub 4-0:1.0: standalone hub
[    5.554681] hub 4-0:1.0: no power switching (usb 1.0)
[    5.554682] hub 4-0:1.0: no over-current protection
[    5.554683] hub 4-0:1.0: power on to power good time: 4ms
[    5.554691] hub 4-0:1.0: local power source is good
[    5.555283] hub 4-0:1.0: trying to enable port power on non-switchable hub
[    5.555346] ehci_hcd 0000:00:13.2: HS companion for 0000:00:13.0
[    5.555389] xen: registering gsi 18 triggering 0 polarity 1
[    5.555394] Already setup the GSI :18
[    5.555433] ohci_hcd 0000:00:14.5: OHCI Host Controller
[    5.555598] ohci_hcd 0000:00:14.5: new USB bus registered, assigned bus number 5
[    5.555670] ohci_hcd 0000:00:14.5: created debug files
[    5.555672] ohci_hcd 0000:00:14.5: supports USB remote wakeup
[    5.555685] ohci_hcd 0000:00:14.5: irq 18, io mem 0xfeb4c000
[    5.809859] hub 4-0:1.0: state 7 ports 5 chg 0000 evt 0000
[    5.813841] ohci_hcd 0000:00:14.5: OHCI controller state
[    5.813847] ohci_hcd 0000:00:14.5: OHCI 1.0, NO legacy support registers, rh state running
[    5.813851] ohci_hcd 0000:00:14.5: control 0x283 RWC HCFS=operational CBSR=3
[    5.813854] ohci_hcd 0000:00:14.5: cmdstatus 0x00000 SOC=0
[    5.813857] ohci_hcd 0000:00:14.5: intrstatus 0x00000004 SF
[    5.813860] ohci_hcd 0000:00:14.5: intrenable 0x8000005a MIE RHSC UE RD WDH
[    5.813871] ohci_hcd 0000:00:14.5: hcca frame #0004
[    5.813874] ohci_hcd 0000:00:14.5: roothub.a 02001202 POTPGT=2 NOCP NPS NDP=2(2)
[    5.813876] ohci_hcd 0000:00:14.5: roothub.b 00000000 PPCM=0000 DR=0000
[    5.813880] ohci_hcd 0000:00:14.5: roothub.status 00008000 DRWE
[    5.813884] ohci_hcd 0000:00:14.5: roothub.portstatus [0] 0x00000100 PPS
[    5.813886] ohci_hcd 0000:00:14.5: roothub.portstatus [1] 0x00000100 PPS
[    5.813923] usb usb5: default language 0x0409
[    5.813935] usb usb5: udev 1, busnum 5, minor = 512
[    5.813938] usb usb5: New USB device found, idVendor=1d6b, idProduct=0001
[    5.813939] usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    5.813941] usb usb5: Product: OHCI Host Controller
[    5.813942] usb usb5: Manufacturer: Linux 3.7.0-rc3upstream-00220-g37b7153 ohci_hcd
[    5.813944] usb usb5: SerialNumber: 0000:00:14.5
[    5.814220] usb usb5: usb_probe_device
[    5.814223] usb usb5: configuration #1 chosen from 1 choice
[    5.814238] usb usb5: adding 5-0:1.0 (config #1, interface 0)
[    5.814373] hub 5-0:1.0: usb_probe_interface
[    5.814375] hub 5-0:1.0: usb_probe_interface - got id
[    5.814377] hub 5-0:1.0: USB hub found
[    5.814390] hub 5-0:1.0: 2 ports detected
[    5.814392] hub 5-0:1.0: standalone hub
[    5.814393] hub 5-0:1.0: no power switching (usb 1.0)
[    5.814394] hub 5-0:1.0: no over-current protection
[    5.814396] hub 5-0:1.0: power on to power good time: 4ms
[    5.814405] hub 5-0:1.0: local power source is good
[    5.814425] hub 5-0:1.0: trying to enable port power on non-switchable hub
[    5.814584] uhci_hcd: USB Universal Host Controller Interface driver
[    6.009259] hub 5-0:1.0: state 7 ports 2 chg 0000 evt 0000
[    6.009372] usbcore: registered new interface driver usblp
[    6.009676] i8042: PNP: No PS/2 controller found. Probing ports directly.
[    6.010397] serio: i8042 KBD port at 0x60,0x64 irq 1
[    6.010409] serio: i8042 AUX port at 0x60,0x64 irq 12
[    6.010691] mousedev: PS/2 mouse device common for all mice
[    6.011327] rtc_cmos 00:05: RTC can wake from S4
[    6.011618] rtc_cmos 00:05: rtc core: registered rtc_cmos as rtc0
[    6.011662] rtc0: alarms up to one month, y3k, 114 bytes nvram
[    6.011868] EFI Variables Facility v0.08 2004-May-17
[    6.011957] zram: num_devices not specified. Using default: 1
[    6.011958] zram: Creating 1 devices ...
[    6.077064] Netfilter messages via NETLINK v0.30.
[    6.082006] nf_conntrack version 0.5.0 (7194 buckets, 28776 max)
[    6.088334] ctnetlink v0.93: registering with nfnetlink.
[    6.094201] ip_tables: (C) 2000-2006 Netfilter Core Team
[    6.099817] TCP: cubic registered
[    6.103279] Initializing XFRM netlink socket
[    6.107873] NET: Registered protocol family 10
[    6.112784] ip6_tables: (C) 2000-2006 Netfilter Core Team
[    6.119125] sit: IPv6 over IPv4 tunneling driver
[    6.124870] NET: Registered protocol family 17
[    6.129593] Key type dns_resolver registered
[    6.135108] PM: Hibernation image not present or could not be loaded.
[    6.141853] registered taskstats version 1
[    6.146837]   Magic number: 0:661:743
[    6.151899] Freeing unused kernel memory: 752k freed
[    6.157248] Write protecting the kernel read-only data: 10240k
[    6.169212] Freeing unused kernel memory: 1768k freed
[    6.175129] Freeing unused kernel memory: 168k freed
[    6.188257] consoletype (1257) used greatest stack depth: 5272 bytes left
[    6.524961] modprobe (1286) used greatest stack depth: 5256 bytes left
[    6.547403] core_filesystem (1258) used greatest stack depth: 4952 bytes left
[    6.592358] Initialising Xen virtual ethernet driver.
[    6.722568] wmi: Mapper loaded
[    6.796831] xen: registering gsi 17 triggering 0 polarity 1
[    6.802666] Already setup the GSI :17
[    6.808260] e1000e: Intel(R) PRO/1000 Network Driver - 2.1.4-k
[    6.814354] e1000e: Copyright(c) 1999 - 2012 Intel Corporation.
[    6.816573] SCSI subsystem initialized
[    6.824498] e1000e 0000:02:00.0: Disabling ASPM L0s L1
[    6.824524] xen: registering gsi 16 triggering 0 polarity 1
[    6.824531] Already setup the GSI :16
[    6.824740] e1000e 0000:02:00.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
[    6.859455] [drm] radeon defaulting to kernel modesetting.
[    6.866428] [drm] radeon kernel modesetting enabled.
[    6.873121] xen: registering gsi 18 triggering 0 polarity 1
[    6.873126] Already setup the GSI :18
[    6.883269] atl1c 0000:03:00.0: version 1.0.1.0-NAPI
[    6.883447] [drm] initializing kernel modesetting (SUMO 0x1002:0x9640 0x1043:0x84C8).
[    6.883509] [drm] register mmio base: 0xFEB00000
[    6.883511] [drm] register mmio size: 262144
[    6.883646] ATOM BIOS: General
[    6.883717] radeon 0000:00:01.0: VRAM: 512M 0x0000000000000000 - 0x000000001FFFFFFF (512M used)
[    6.883720] radeon 0000:00:01.0: GTT: 512M 0x0000000020000000 - 0x000000003FFFFFFF
[    6.883722] [drm] Detected VRAM RAM=512M, BAR=256M
[    6.883725] [drm] RAM width 32bits DDR
[    6.884463] [TTM] Zone  kernel: Available graphics memory: 461822 kiB
[    6.884466] [TTM] Initializing pool allocator
[    6.884476] [TTM] Initializing DMA pool allocator
[    6.884529] [drm] radeon: 512M of VRAM memory ready
[    6.884531] [drm] radeon: 512M of GTT memory ready.
[    6.884622] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[    6.884625] [drm] Driver supports precise vblank timestamp query.
[    6.884802] radeon 0000:00:01.0: radeon: using MSI.
[    6.884865] [drm] radeon: irq initialized.
[    6.884871] [drm] GART: num cpu pages 131072, num gpu pages 131072
[    6.895835] [drm] Loading SUMO Microcode
[    6.933742] ACPI: bus type scsi registered
[    6.941860] e1000e 0000:02:00.0 eth1: (PCI Express:2.5GT/s:Width x1) 00:1b:21:ab:c6:12
[    6.941862] e1000e 0000:02:00.0 eth1: Intel(R) PRO/1000 Network Connection
[    6.941882] e1000e 0000:02:00.0 eth1: MAC: 3, PHY: 8, PBA No: E46981-005
[    6.997612] ip (1909) used greatest stack depth: 3896 bytes left
[    7.048540] libata version 3.00 loaded.
[    7.144568] [drm] PCIE GART of 512M enabled (table at 0x0000000000040000).
[    7.151898] radeon 0000:00:01.0: WB enabled
[    7.156253] radeon 0000:00:01.0: fence driver on ring 0 use gpu addr 0x0000000020000c00 and cpu addr 0xffff880023235c00
[    7.185375] [drm] ring test on 0 succeeded in 1 usecs
[    7.191817] [drm] ib test on ring 0 succeeded in 0 usecs
[    7.209657] [drm] Radeon Display Connectors
[    7.214052] [drm] Connector 0:
[    7.217253] [drm]   VGA-1
[    7.220007] [drm]   HPD2
[    7.222674] [drm]   DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448 0x644c 0x644c
[    7.230416] [drm]   Encoders:
[    7.233539] [drm]     CRT1: INTERNAL_UNIPHY2
[    7.238001] [drm]     CRT1: NUTMEG
[    7.238003] [drm] Connector 1:
[    7.238005] [drm]   HDMI-A-1
[    7.238006] [drm]   HPD1
[    7.238009] [drm]   DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c 0x643c
[    7.238011] [drm]   Encoders:
[    7.238011] [drm]     DFP1: INTERNAL_UNIPHY2
[    7.255949] [drm] Internal thermal controller without fan control
[    7.259955] [drm] radeon: power management initialized
[    7.335529] No connectors reported connected with modes
[    7.340968] [drm] Cannot find any crtc or sizes - going 1024x768
[    7.350906] [drm] fb mappable at 0xD0142000
[    7.355261] [drm] vram apper at 0xD0000000
[    7.359523] [drm] size 3145728
[    7.362716] [drm] fb depth is 24
[    7.366146] [drm]    pitch is 4096
[    7.370065] fbcon: radeondrmfb (fb0) is primary device
[    7.376982] ttyS1: 1 input overrun(s)
[    7.411210] Console: switching to colour frame buffer device 128x48
[    7.424071] fb0: radeondrmfb frame buffer device
[    7.428949] drm: registered panic notifier
[    7.433284] [drm] Initialized radeon 2.24.0 20080528 for 0000:00:01.0 on minor 0
[    7.441164] ahci 0000:00:11.0: version 3.0
[    7.445546] xen: registering gsi 19 triggering 0 polarity 1
[    7.451464] xen: --> pirq=19 -> irq=19 (gsi=19)
[    7.456473] ahci 0000:00:11.0: AHCI 0001.0300 32 slots 6 ports 6 Gbps 0x3f impl SATA mode
[    7.465104] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part 
[    7.478140] scsi0 : ahci
[    7.481629] scsi1 : ahci
[    7.484929] scsi2 : ahci
[    7.488287] scsi3 : ahci
[    7.491496] scsi4 : ahci
[    7.494907] scsi5 : ahci
[    7.498649] ata1: SATA max UDMA/133 abar m2048@0xfeb51000 port 0xfeb51100 irq 71
[    7.507585] ata2: SATA max UDMA/133 abar m2048@0xfeb51000 port 0xfeb51180 irq 71
[    7.515392] ata3: SATA max UDMA/133 abar m2048@0xfeb51000 port 0xfeb51200 irq 71
[    7.523177] ata4: SATA max UDMA/133 abar m2048@0xfeb51000 port 0xfeb51280 irq 71
[    7.530982] ata5: SATA max UDMA/133 abar m2048@0xfeb51000 port 0xfeb51300 irq 71
[    7.538786] ata6: SATA max UDMA/133 abar m2048@0xfeb51000 port 0xfeb51380 irq 71
[    7.850775] ata1: SATA link down (SStatus 0 SControl 300)
[    7.856613] ata2: SATA link down (SStatus 0 SControl 300)
[    7.862497] ata6: SATA link down (SStatus 0 SControl 300)
[    7.871228] ata3: SATA link down (SStatus 0 SControl 300)
[    7.879887] ata5: SATA link down (SStatus 0 SControl 300)
[    8.038131] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[    8.062593] ata4.00: ATA-7: WDC WD800AAJS-18TDA0, 01.00A03, max UDMA/133
[    8.072417] ata4.00: 156250000 sectors, multi 16: LBA48 NCQ (depth 31/32), AA
[    8.082336] ata4.00: failed to get Identify Device Data, Emask 0x1
[    8.092297] ata4.00: failed to get Identify Device Data, Emask 0x1
[    8.100682] ata4.00: configured for UDMA/133
[    8.107497] scsi 3:0:0:0: Direct-Access     ATA      WDC WD800AAJS-18 01.0 PQ: 0 ANSI: 5
[    8.129843] sd 3:0:0:0: [sda] 156250000 512-byte logical blocks: (80.0 GB/74.5 GiB)
[    8.140007] sd 3:0:0:0: [sda] Write Protect is off
[    8.146945] sd 3:0:0:0: [sda] Mode Sense: 00 3a 00 00
[    8.154244] sd 3:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    8.199771]  sda: sda1 sda2 sda3 sda4
[    8.210772] sd 3:0:0:0: [sda] Attached SCSI disk
[    8.224663] sd 3:0:0:0: Attached scsi generic sg0 type 0
[    8.944409] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[    8.963120] device eth0 entered promiscuous mode
[    9.181754] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[   10.053518] atl1c 0000:03:00.0: atl1c: eth0 NIC Link is Up<1000 Mbps Full Duplex>
[   10.064785] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   11.555156] e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
[   11.566749] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[   13.964892] switch: port 1(eth0) entered forwarding state
[   13.973524] switch: port 1(eth0) entered forwarding state
[   16.232334] Loading iSCSI transport class v2.0-870.
[   16.248793] iscsi: registered transport (tcp)
[   16.306470] Event-channel device installed.
[   19.630065] mount.nfs (3143) used greatest stack depth: 3224 bytes left
[   21.157586] device-mapper: ioctl: 4.23.0-ioctl (2012-07-25) initialised: dm-devel@redhat.com
[   21.170420] device-mapper: multipath: version 1.5.0 loaded
[   21.450531] scsi6 : iSCSI Initiator over TCP/IP
[   21.731710] scsi 6:0:0:0: Direct-Access     LIO-ORG  IBLOCK           4.0  PQ: 0 ANSI: 5
[   21.747167] sd 6:0:0:0: [sdb] 503316480 512-byte logical blocks: (257 GB/240 GiB)
[   21.747211] sd 6:0:0:0: Attached scsi generic sg1 type 0
[   21.748648] scsi 6:0:0:1: Direct-Access     LIO-ORG  IBLOCK           4.0  PQ: 0 ANSI: 5
[   21.752968] sd 6:0:0:1: [sdc] 167772160 512-byte logical blocks: (85.8 GB/80.0 GiB)
[   21.753042] sd 6:0:0:1: Attached scsi generic sg2 type 0
[   21.755647] sd 6:0:0:1: [sdc] Write Protect is off
[   21.755655] sd 6:0:0:1: [sdc] Mode Sense: 2f 00 00 00
[   21.756638] sd 6:0:0:1: [sdc] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[   21.761219] scsi 6:0:0:2: Direct-Access     LIO-ORG  IBLOCK           4.0  PQ: 0 ANSI: 5
[   21.770871] sd 6:0:0:2: Attached scsi generic sg3 type 0
[   21.771168] sd 6:0:0:2: [sdd] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB)
[   21.775163] ttyS1: 1 input overrun(s)
[   21.776400] sd 6:0:0:2: [sdd] Write Protect is off
[   21.776405] sd 6:0:0:2: [sdd] Mode Sense: 2f 00 00 00
[   21.776884] sd 6:0:0:2: [sdd] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[   21.780001]  sdd: unknown partition table
[   21.781272] sd 6:0:0:2: [sdd] Attached SCSI disk
[   21.804226]  sdc: sdc1 sdc2 < sdc5 >
[   21.806353] sd 6:0:0:1: [sdc] Attached SCSI disk
[   21.918632] sd 6:0:0:0: [sdb] Write Protect is off
[   21.926413] sd 6:0:0:0: [sdb] Mode Sense: 2f 00 00 00
[   21.935417] sd 6:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[   21.963859]  sdb: unknown partition table
[   21.974284] sd 6:0:0:0: [sdb] Attached SCSI disk
[   28.589544] bio: create slab  at 1
[   28.997728] switch: port 1(eth0) entered forwarding state
[   57.703132] device vif1.0 entered promiscuous mode
[   57.715328] IPv6: ADDRCONF(NETDEV_UP): vif1.0: link is not ready
[   59.760909] IPv6: ADDRCONF(NETDEV_CHANGE): vif1.0: link becomes ready
[   59.770384] switch: port 2(vif1.0) entered forwarding state
[   59.778900] switch: port 2(vif1.0) entered forwarding state
[   59.876529] xen-blkback:ring-ref 10, event-channel 18, protocol 2 (x86_32-abi) persistent grants
[   65.135453] switch: port 2(vif1.0) entered disabled state
[   65.145638] device vif1.0 left promiscuous mode
[   65.154458] switch: port 2(vif1.0) entered disabled state
[   70.836602] device vif2.0 entered promiscuous mode
[   70.848191] IPv6: ADDRCONF(NETDEV_UP): vif2.0: link is not ready
[   72.285945] IPv6: ADDRCONF(NETDEV_CHANGE): vif2.0: link becomes ready
[   72.295310] switch: port 2(vif2.0) entered forwarding state
[   72.303597] switch: port 2(vif2.0) entered forwarding state
[   72.403140] xen-blkback:ring-ref 10, event-channel 11, protocol 1 (x86_64-abi) persistent grants
[   72.544101] ------------[ cut here ]------------
[   72.552932] kernel BUG at /home/konrad/linux/drivers/block/xen-blkback/blkback.c:589!
[   72.563680] invalid opcode: 0000 [#1] SMP 
[   72.570865] Modules linked in: dm_multipath dm_mod xen_evtchn iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi libcrc32c crc32c sg sd_mod ahci libahci libata radeon e1000e scsi_mod atl1c fbcon ttm tileblit font bitblit softcursor drm_kms_helper wmi xen_blkfront xen_netfront fb_sys_fops sysimgblt sysfillrect syscopyarea xenfs xen_privcmd [last unloaded: dump_dma]
[   72.617251] CPU 0 
[   72.619173] Pid: 3823, comm: blkback.2.xvda Tainted: G           O 3.7.0-rc3upstream-00220-g37b7153 #1 System manufacturer System Product Name/F1A75-M
[   72.641606] RIP: e030:[]  [] xen_blkbk_map+0x696/0x6e0
[   72.653181] RSP: e02b:ffff880027dd3728  EFLAGS: 00010246
[   72.661651] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[   72.672090] RDX: ffff8800232d7f40 RSI: 0000000000000000 RDI: ffff880027dd3d88
[   72.682437] RBP: ffff880027dd39e8 R08: 0000000000000000 R09: 0000000000000000
[   72.692835] R10: 0000000000000001 R11: dead000000200200 R12: 0000000000000000
[   72.703261] R13: 0000000000000000 R14: ffff88002b5e7070 R15: 0000000000000000
[   72.713560] FS:  00007f6cc62d5700(0000) GS:ffff88003e000000(0000) knlGS:0000000000000000
[   72.724921] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[   72.733811] CR2: 00000000006dd384 CR3: 0000000027b8f000 CR4: 0000000000000660
[   72.744131] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   72.754517] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[   72.764882] Process blkback.2.xvda (pid: 3823, threadinfo ffff880027dd2000, task ffff88002bb15040)
[   72.777140] Stack:
[   72.782184]  ffff880027dd3738 ffff880026081af0 ffff880027dd3798 ffffffff810ac7df
[   72.792960]  ffff880027dd3798 ffffffff8104c506 0000000000000117 ffff88002160d030
[   72.803712]  ffff880027dd3a38 ffff88002b5e7120 ffff88002160d000 ffff880027dd3d88
[   72.814469] Call Trace:
[   72.820094]  [] ? __queue_work+0xff/0x420
[   72.829023]  [] ? xen_spin_lock_flags+0xb6/0x120
[   72.838462]  [] ? queue_work_on+0x31/0x50
[   72.847279]  [] ? _raw_spin_unlock_irqrestore+0x19/0x30
[   72.854408] ttyS1: 2 input overrun(s)
[   72.864352]  [] ? pvclock_clocksource_read+0x58/0xd0
[   72.874471]  [] ? cpumask_next_and+0x23/0x40
[   72.883656]  [] ? cpumask_next_and+0x23/0x40
[   72.892716]  [] ? update_sd_lb_stats+0x157/0x6c0
[   72.902178]  [] ? _raw_spin_lock_irq+0x20/0x30
[   72.911486]  [] ? find_busiest_group+0x31/0x4d0
[   72.920849]  [] dispatch_rw_block_io+0x377/0x600
[   72.930187]  [] ? pvclock_clocksource_read+0x58/0xd0
[   72.939957]  [] ? xen_mc_flush+0xc0/0x1f0
[   72.948743]  [] ? xen_end_context_switch+0x19/0x20
[   72.958251]  [] ? pvclock_clocksource_read+0x58/0xd0
[   72.967917]  [] ? pvclock_clocksource_read+0x58/0xd0
[   72.977617]  [] ? pvclock_clocksource_read+0x58/0xd0
[   72.987474]  [] ? xen_clocksource_read+0x39/0x50
[   72.997278]  [] ? xen_spin_lock_flags+0xb6/0x120
[   73.006476]  [] xen_blkif_schedule+0x21e/0xa00
[   73.015493]  [] ? irq_to_desc+0x12/0x20
[   73.023833]  [] ? irq_get_irq_data+0x9/0x10
[   73.032418]  [] ? info_for_irq+0x9/0x20
[   73.040554]  [] ? notify_remote_via_irq+0x29/0x50
[   73.049523]  [] ? sched_clock_cpu+0xcd/0x110
[   73.058024]  [] ? pvclock_clocksource_read+0x58/0xd0
[   73.067191]  [] ? xen_mc_flush+0xc0/0x1f0
[   73.075338]  [] ? __schedule+0x3be/0x7c0
[   73.083311]  [] ? wake_up_bit+0x40/0x40
[   73.091108]  [] ? dispatch_rw_block_io+0x600/0x600
[   73.099902]  [] kthread+0xc6/0xd0
[   73.107124]  [] ? xen_end_context_switch+0x19/0x20
[   73.115845]  [] ? kthread_freezable_should_stop+0x80/0x80
[   73.125266]  [] ret_from_fork+0x7c/0xb0
[   73.133089]  [] ? kthread_freezable_should_stop+0x80/0x80
[   73.142576] Code: 48 89 d7 e8 ad 66 d8 ff 4a c7 84 3d 70 ff ff ff 00 00 00 00 4c 8b 85 60 fd ff ff 41 8b b0 e4 fd ff ff 41 83 cd 01 e9 ef fb ff ff <0f> 0b eb fe 48 8d 95 10 ff ff ff 48 8d bd b0 fd ff ff 31 f6 44 
[   73.167611] RIP  [] xen_blkbk_map+0x696/0x6e0
[   73.176081]  RSP 
[   73.182024] ---[ end trace 914a52d8b62134db ]---
[   87.339441] switch: port 2(vif2.0) entered forwarding state
[  315.067569] device tap3.0 entered promiscuous mode
[  315.074965] switch: port 3(tap3.0) entered forwarding state
[  315.083116] switch: port 3(tap3.0) entered forwarding state
[  315.142543] switch: port 3(tap3.0) entered disabled state
[  315.161150] switch: port 3(tap3.0) entered forwarding state
[  315.169097] switch: port 3(tap3.0) entered forwarding state
[  330.162411] switch: port 3(tap3.0) entered forwarding state
[  415.483626] switch: port 3(tap3.0) entered disabled state
[  415.491439] device tap3.0 left promiscuous mode
[  415.498191] switch: port 3(tap3.0) entered disabled state
[  658.839306] device tap4.0 entered promiscuous mode
[  658.846451] switch: port 3(tap4.0) entered forwarding state
[  658.854354] switch: port 3(tap4.0) entered forwarding state
[  658.923751] switch: port 3(tap4.0) entered disabled state
[  658.942642] switch: port 3(tap4.0) entered forwarding state
[  658.950492] switch: port 3(tap4.0) entered forwarding state
[  673.990219] switch: port 3(tap4.0) entered forwarding state
[  759.263762] switch: port 3(tap4.0) entered disabled state
[  759.271529] device tap4.0 left promiscuous mode
[  759.278257] switch: port 3(tap4.0) entered disabled state

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 17:38:27 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 17:38:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTFkR-0003aV-T7; Tue, 30 Oct 2012 17:37:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTFkQ-0003a5-GI
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 17:37:07 +0000
Received: from [85.158.139.211:15332] by server-16.bemta-5.messagelabs.com id
	5F/43-04786-14010905; Tue, 30 Oct 2012 17:37:05 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1351618622!18242733!1
X-Originating-IP: [156.151.31.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyNzI0Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17421 invoked from network); 30 Oct 2012 17:37:04 -0000
Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81)
	by server-4.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Oct 2012 17:37:04 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9UHaxZw018832
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 30 Oct 2012 17:37:00 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9UHax6g017649
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 30 Oct 2012 17:36:59 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9UHaw2u017381; Tue, 30 Oct 2012 12:36:58 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 30 Oct 2012 10:36:58 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 038684042F; Tue, 30 Oct 2012 13:01:57 -0400 (EDT)
Date: Tue, 30 Oct 2012 13:01:57 -0400
From: Konrad Rzeszutek Wilk 
To: Roger Pau Monne 
Message-ID: <20121030170157.GA29485@phenom.dumpdata.com>
References: <1351097925-26221-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1351097925-26221-1-git-send-email-roger.pau@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Oliver Chick , linux-kernel@vger.kernel.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 24, 2012 at 06:58:45PM +0200, Roger Pau Monne wrote:
> This patch implements persistent grants for the xen-blk{front,back}
> mechanism. The effect of this change is to reduce the number of unmap
> operations performed, since they cause a (costly) TLB shootdown. This
> allows the I/O performance to scale better when a large number of VMs
> are performing I/O.
> 
> Previously, the blkfront driver was supplied a bvec[] from the request
> queue. This was granted to dom0; dom0 performed the I/O and wrote
> directly into the grant-mapped memory and unmapped it; blkfront then
> removed foreign access for that grant. The cost of unmapping scales
> badly with the number of CPUs in Dom0. An experiment showed that when
> Dom0 has 24 VCPUs, and guests are performing parallel I/O to a
> ramdisk, the IPIs from performing unmap's is a bottleneck at 5 guests
> (at which point 650,000 IOPS are being performed in total). If more
> than 5 guests are used, the performance declines. By 10 guests, only
> 400,000 IOPS are being performed.
> 
> This patch improves performance by only unmapping when the connection
> between blkfront and back is broken.
> 
> On startup blkfront notifies blkback that it is using persistent
> grants, and blkback will do the same. If blkback is not capable of
> persistent mapping, blkfront will still use the same grants, since it
> is compatible with the previous protocol, and simplifies the code
> complexity in blkfront.
> 
> To perform a read, in persistent mode, blkfront uses a separate pool
> of pages that it maps to dom0. When a request comes in, blkfront
> transmutes the request so that blkback will write into one of these
> free pages. Blkback keeps note of which grefs it has already
> mapped. When a new ring request comes to blkback, it looks to see if
> it has already mapped that page. If so, it will not map it again. If
> the page hasn't been previously mapped, it is mapped now, and a record
> is kept of this mapping. Blkback proceeds as usual. When blkfront is
> notified that blkback has completed a request, it memcpy's from the
> shared memory, into the bvec supplied. A record that the {gref, page}
> tuple is mapped, and not inflight is kept.
> 
> Writes are similar, except that the memcpy is peformed from the
> supplied bvecs, into the shared pages, before the request is put onto
> the ring.
> 
> Blkback stores a mapping of grefs=>{page mapped to by gref} in
> a red-black tree. As the grefs are not known apriori, and provide no
> guarantees on their ordering, we have to perform a search
> through this tree to find the page, for every gref we receive. This
> operation takes O(log n) time in the worst case. In blkfront grants
> are stored using a single linked list.
> 
> The maximum number of grants that blkback will persistenly map is
> currently set to RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, to
> prevent a malicios guest from attempting a DoS, by supplying fresh
> grefs, causing the Dom0 kernel to map excessively. If a guest
> is using persistent grants and exceeds the maximum number of grants to
> map persistenly the newly passed grefs will be mapped and unmaped.
> Using this approach, we can have requests that mix persistent and
> non-persistent grants, and we need to handle them correctly.
> This allows us to set the maximum number of persistent grants to a
> lower value than RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, although
> setting it will lead to unpredictable performance.
> 
> In writing this patch, the question arrises as to if the additional
> cost of performing memcpys in the guest (to/from the pool of granted
> pages) outweigh the gains of not performing TLB shootdowns. The answer
> to that question is `no'. There appears to be very little, if any
> additional cost to the guest of using persistent grants. There is
> perhaps a small saving, from the reduced number of hypercalls
> performed in granting, and ending foreign access.
> 
> Signed-off-by: Oliver Chick 
> Signed-off-by: Roger Pau Monne 
> Cc: 
> Cc: 
> ---
> Changes since v1:
>  * Changed the unmap_seg array to a bitmap.
>  * Only report using persistent grants in blkfront if blkback supports
>    it.
>  * Reword some comments.
>  * Fix a bug when setting the handler, index j was not incremented
>    correctly.
>  * Check that the tree of grants in blkback is not empty before
>    iterating over it when doing the cleanup.
>  * Rebase on top of linux-net.

I fixed the 'new_map = [1|0]' you had in and altered it to use 'true'
or 'false', but when running some tests (with a 64-bit PV guest) I got it
to bug.

[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.7.0-rc3upstream-00220-g37b7153 (konrad@build.dumpdata.com) (gcc version 4.4.4 20100503 (Red Hat 4.4.4-2) (GCC) ) #1 SMP Tue Oct 30 12:15:12 EDT 2012
[    0.000000] Command line: earlyprintk=xen debug nofb console=tty console=ttyS1,115200n8 xen-pciback.hide=(00:02:00) loglevel=10
[    0.000000] Freeing 9d-100 pfn range: 99 pages freed
[    0.000000] 1-1 mapping on 9d->100
[    0.000000] 1-1 mapping on cf7fb->cfb63
[    0.000000] 1-1 mapping on cfd15->cfd70
[    0.000000] 1-1 mapping on cfd71->cfef7
[    0.000000] 1-1 mapping on cff00->100001
[    0.000000] Released 99 pages of unused memory
[    0.000000] Set 198317 page(s) to 1-1 mapping
[    0.000000] Populating 3e700-3e763 pfn range: 99 pages added
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] Xen: [mem 0x0000000000000000-0x000000000009cfff] usable
[    0.000000] Xen: [mem 0x000000000009d800-0x00000000000fffff] reserved
[    0.000000] Xen: [mem 0x0000000000100000-0x000000004d062fff] usable
[    0.000000] Xen: [mem 0x000000004d063000-0x00000000cf7fafff] unusable
[    0.000000] Xen: [mem 0x00000000cf7fb000-0x00000000cf95ffff] reserved
[    0.000000] Xen: [mem 0x00000000cf960000-0x00000000cfb62fff] ACPI NVS
[    0.000000] Xen: [mem 0x00000000cfb63000-0x00000000cfd14fff] unusable
[    0.000000] Xen: [mem 0x00000000cfd15000-0x00000000cfd61fff] ACPI NVS
[    0.000000] Xen: [mem 0x00000000cfd62000-0x00000000cfd6cfff] ACPI data
[    0.000000] Xen: [mem 0x00000000cfd6d000-0x00000000cfd6ffff] ACPI NVS
[    0.000000] Xen: [mem 0x00000000cfd70000-0x00000000cfd70fff] unusable
[    0.000000] Xen: [mem 0x00000000cfd71000-0x00000000cfea8fff] reserved
[    0.000000] Xen: [mem 0x00000000cfea9000-0x00000000cfeb9fff] ACPI NVS
[    0.000000] Xen: [mem 0x00000000cfeba000-0x00000000cfecafff] reserved
[    0.000000] Xen: [mem 0x00000000cfecb000-0x00000000cfecbfff] ACPI NVS
[    0.000000] Xen: [mem 0x00000000cfecc000-0x00000000cfedbfff] reserved
[    0.000000] Xen: [mem 0x00000000cfedc000-0x00000000cfedcfff] ACPI NVS
[    0.000000] Xen: [mem 0x00000000cfedd000-0x00000000cfeddfff] reserved
[    0.000000] Xen: [mem 0x00000000cfede000-0x00000000cfee3fff] ACPI NVS
[    0.000000] Xen: [mem 0x00000000cfee4000-0x00000000cfef6fff] reserved
[    0.000000] Xen: [mem 0x00000000cfef7000-0x00000000cfefffff] unusable
[    0.000000] Xen: [mem 0x00000000e0000000-0x00000000efffffff] reserved
[    0.000000] Xen: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
[    0.000000] Xen: [mem 0x00000000fec10000-0x00000000fec10fff] reserved
[    0.000000] Xen: [mem 0x00000000fed00000-0x00000000fed00fff] reserved
[    0.000000] Xen: [mem 0x00000000fed40000-0x00000000fed44fff] reserved
[    0.000000] Xen: [mem 0x00000000fed61000-0x00000000fed70fff] reserved
[    0.000000] Xen: [mem 0x00000000fed80000-0x00000000fed8ffff] reserved
[    0.000000] Xen: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
[    0.000000] Xen: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
[    0.000000] Xen: [mem 0x0000000100001000-0x000000020effffff] unusable
[    0.000000] bootconsole [xenboot0] enabled
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI 2.6 present.
[    0.000000] DMI: System manufacturer System Product Name/F1A75-M, BIOS 0406 06/11/2011
[    0.000000] e820: update [mem 0x00000000-0x0000ffff] usable ==> reserved
[    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[    0.000000] No AGP bridge found
[    0.000000] e820: last_pfn = 0x4d063 max_arch_pfn = 0x400000000
[    0.000000] initial memory mapped: [mem 0x00000000-0x16bcdfff]
[    0.000000] Base memory trampoline at [ffff880000097000] 97000 size 24576
[    0.000000] init_memory_mapping: [mem 0x00000000-0x4d062fff]
[    0.000000]  [mem 0x00000000-0x4d062fff] page 4k
[    0.000000] kernel direct mapping tables up to 0x4d062fff @ [mem 0x01e21000-0x0208cfff]
[    0.000000] xen: setting RW the range 1fd3000 - 208d000
[    0.000000] RAMDISK: [mem 0x0208d000-0x16bcdfff]
[    0.000000] ACPI: RSDP 00000000000f0450 00024 (v02 ALASKA)
[    0.000000] ACPI: XSDT 00000000cfd62068 00054 (v01 ALASKA    A M I 01072009 AMI  00010013)
[    0.000000] ACPI: FACP 00000000cfd69a68 000F4 (v04 ALASKA    A M I 01072009 AMI  00010013)
[    0.000000] ACPI BIOS Bug: Warning: Optional FADT field Pm2ControlBlock has zero address or length: 0x0000000000000000/0x1 (20120913/tbfadt-598)
[    0.000000] ACPI: DSDT 00000000cfd62150 07917 (v02 ALASKA    A M I 00000000 INTL 20051117)
[    0.000000] ACPI: FACS 00000000cfedef80 00040
[    0.000000] ACPI: APIC 00000000cfd69b60 00072 (v03 ALASKA    A M I 01072009 AMI  00010013)
[    0.000000] ACPI: MCFG 00000000cfd69bd8 0003C (v01 A M I  GMCH945. 01072009 MSFT 00000097)
[    0.000000] ACPI: HPET 00000000cfd69c18 00038 (v01 ALASKA    A M I 01072009 AMI  00000004)
[    0.000000] ACPI: SSDT 00000000cfd69c50 00FD8 (v01 AMD    POWERNOW 00000001 AMD  00000001)
[    0.000000] ACPI: SSDT 00000000cfd6ac28 01923 (v02    AMD     ALIB 00000001 MSFT 04000000)
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] NUMA turned off
[    0.000000] Faking a node at [mem 0x0000000000000000-0x000000004d062fff]
[    0.000000] Initmem setup node 0 [mem 0x00000000-0x4d062fff]
[    0.000000]   NODE_DATA [mem 0x3e75f000-0x3e762fff]
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x00010000-0x00ffffff]
[    0.000000]   DMA32    [mem 0x01000000-0xffffffff]
[    0.000000]   Normal   empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x00010000-0x0009cfff]
[    0.000000]   node   0: [mem 0x00100000-0x4d062fff]
[    0.000000] On node 0 totalpages: 315376
[    0.000000]   DMA zone: 56 pages used for memmap
[    0.000000]   DMA zone: 6 pages reserved
[    0.000000]   DMA zone: 3919 pages, LIFO batch:0
[    0.000000]   DMA32 zone: 4258 pages used for memmap
[    0.000000]   DMA32 zone: 307137 pages, LIFO batch:31
[    0.000000] ACPI: PM-Timer IO Port: 0x808
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])
[    0.000000] ACPI: IOAPIC (id[0x05] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 5, version 33, address 0xfec00000, GSI 0-23
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
[    0.000000] ACPI: IRQ0 used by override.
[    0.000000] ACPI: IRQ2 used by override.
[    0.000000] ACPI: IRQ9 used by override.
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0xffffffff base: 0xfed00000
[    0.000000] smpboot: Allowing 4 CPUs, 0 hotplug CPUs
[    0.000000] nr_irqs_gsi: 40
[    0.000000] PM: Registered nosave memory: 000000000009d000 - 000000000009e000
[    0.000000] PM: Registered nosave memory: 000000000009e000 - 0000000000100000
[    0.000000] e820: [mem 0xcff00000-0xdfffffff] available for PCI devices
[    0.000000] Booting paravirtualized kernel on Xen
[    0.000000] Xen version: 4.1.4-pre (preserve-AD)
[    0.000000] setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:4 nr_node_ids:1
[    0.000000] PERCPU: Embedded 28 pages/cpu @ffff88003e000000 s84288 r8192 d22208 u524288
[    0.000000] pcpu-alloc: s84288 r8192 d22208 u524288 alloc=1*2097152
[    0.000000] pcpu-alloc: [0] 0 1 2 3 
[    2.763208] Built 1 zonelists in Node order, mobility grouping on.  Total pages: 311056
[    2.763213] Policy zone: DMA32
[    2.763218] Kernel command line: earlyprintk=xen debug nofb console=tty console=ttyS1,115200n8 xen-pciback.hide=(00:02:00) loglevel=10
[    2.763656] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    2.763663] __ex_table already sorted, skipping sort
[    2.808064] software IO TLB [mem 0x38a00000-0x3ca00000] (64MB) mapped at [ffff880038a00000-ffff88003c9fffff]
[    2.811300] Memory: 581728k/1261964k available (6413k kernel code, 460k absent, 679776k reserved, 4478k data, 752k init)
[    2.811414] Hierarchical RCU implementation.
[    2.811419] 	RCU restricting CPUs from NR_CPUS=512 to nr_cpu_ids=3.
[    2.811432] NR_IRQS:33024 nr_irqs:704 16
[    2.811514] xen: sci override: global_irq=9 trigger=0 polarity=1
[    2.811518] xen: registering gsi 9 triggering 0 polarity 1
[    2.811531] xen: --> pirq=9 -> irq=9 (gsi=9)
[    2.811539] xen: acpi sci 9
[    2.811546] xen: --> pirq=1 -> irq=1 (gsi=1)
[    2.811551] xen: --> pirq=2 -> irq=2 (gsi=2)
[    2.811557] xen: --> pirq=3 -> irq=3 (gsi=3)
[    2.811562] xen: --> pirq=4 -> irq=4 (gsi=4)
[    2.811568] xen: --> pirq=5 -> irq=5 (gsi=5)
[    2.811574] xen: --> pirq=6 -> irq=6 (gsi=6)
[    2.811579] xen: --> pirq=7 -> irq=7 (gsi=7)
[    2.811585] xen: --> pirq=8 -> irq=8 (gsi=8)
[    2.811590] xen: --> pirq=10 -> irq=10 (gsi=10)
[    2.811596] xen: --> pirq=11 -> irq=11 (gsi=11)
[    2.811602] xen: --> pirq=12 -> irq=12 (gsi=12)
[    2.811607] xen: --> pirq=13 -> irq=13 (gsi=13)
[    2.811613] xen: --> pirq=14 -> irq=14 (gsi=14)
[    2.811618] xen: --> pirq=15 -> irq=15 (gsi=15)
[    2.813454] Console: colour VGA+ 80x25
[    2.818363] console [tty0] enabled
[    2.818422] console [ttyS1] enabled, bootconsole disabled
[    2.818757] Xen: using vcpuop timer interface
[    2.819017] installing Xen timer for CPU 0
[    2.819285] tsc: Detected 2899.980 MHz processor
[    2.819555] Calibrating delay loop (skipped), value calculated using timer frequency.. 5799.96 BogoMIPS (lpj=2899980)
[    2.820151] pid_max: default: 32768 minimum: 301
[    2.820479] Security Framework initialized
[    2.820728] SELinux:  Initializing.
[    2.820948] SELinux:  Starting in permissive mode
[    2.821532] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
[    2.822565] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
[    2.823519] Mount-cache hash table entries: 256
[    2.824126] Initializing cgroup subsys cpuacct
[    2.824400] Initializing cgroup subsys freezer
[    2.824730] tseg: 00cff00000
[    2.824934] CPU: Physical Processor ID: 0
[    2.825186] CPU: Processor Core ID: 0
[    2.825417] mce: CPU supports 6 MCE banks
[    2.825696] Last level iTLB entries: 4KB 512, 2MB 16, 4MB 8
[    2.825696] Last level dTLB entries: 4KB 1024, 2MB 128, 4MB 64
[    2.825696] tlb_flushall_shift: 5
[    2.826625] Freeing SMP alternatives: 24k freed
[    2.829704] ACPI: Core revision 20120913
[    2.856787] cpu 0 spinlock event irq 41
[    2.857062] Performance Events: Broken PMU hardware detected, using software events only.
[    2.857602] Failed to access perfctr msr (MSR c0010004 is 0)
[    2.858234] MCE: In-kernel MCE decoding enabled.
[    2.858603] NMI watchdog: disabled (cpu0): hardware events not enabled
[    2.859223] installing Xen timer for CPU 1
[    2.859499] cpu 1 spinlock event irq 48
[    2.860218] installing Xen timer for CPU 2
[    2.860493] cpu 2 spinlock event irq 55
[    2.860951] Brought up 3 CPUs
[    2.864412] PM: Registering ACPI NVS region [mem 0xcf960000-0xcfb62fff] (2109440 bytes)
[    2.865989] PM: Registering ACPI NVS region [mem 0xcfd15000-0xcfd61fff] (315392 bytes)
[    2.866464] PM: Registering ACPI NVS region [mem 0xcfd6d000-0xcfd6ffff] (12288 bytes)
[    2.866931] PM: Registering ACPI NVS region [mem 0xcfea9000-0xcfeb9fff] (69632 bytes)
[    2.867404] PM: Registering ACPI NVS region [mem 0xcfecb000-0xcfecbfff] (4096 bytes)
[    2.867861] PM: Registering ACPI NVS region [mem 0xcfedc000-0xcfedcfff] (4096 bytes)
[    2.868321] PM: Registering ACPI NVS region [mem 0xcfede000-0xcfee3fff] (24576 bytes)
[    2.869081] kworker/u:0 (26) used greatest stack depth: 6120 bytes left
[    2.869105] Grant tables using version 2 layout.
[    2.869122] Grant table initialized
[    2.869164] RTC time: 16:43:55, date: 10/30/12
[    2.870366] NET: Registered protocol family 16
[    2.871181] kworker/u:0 (30) used greatest stack depth: 5504 bytes left
[    2.872440] ACPI: bus type pci registered
[    2.873480] dca service started, version 1.12.1
[    2.873891] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000)
[    2.874438] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in E820
[    2.914335] PCI: Using configuration type 1 for base access
[    2.932999] bio: create slab  at 0
[    2.933584] ACPI: Added _OSI(Module Device)
[    2.933866] ACPI: Added _OSI(Processor Device)
[    2.934145] ACPI: Added _OSI(3.0 _SCP Extensions)
[    2.934432] ACPI: Added _OSI(Processor Aggregator Device)
[    2.942011] ACPI: EC: Look up EC in DSDT
[    2.950054] ACPI: Executed 1 blocks of module-level executable AML code
[    2.956530] ACPI: Interpreter enabled
[    2.956772] ACPI: (supports S0 S3 S4 S5)
[    2.957218] ACPI: Using IOAPIC for interrupt routing
[    2.982389] ACPI: No dock devices found.
[    2.982650] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[    2.983552] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[    2.984298] PCI host bridge to bus 0000:00
[    2.984571] pci_bus 0000:00: root bus resource [bus 00-ff]
[    2.984906] pci_bus 0000:00: root bus resource [io  0x0000-0x03af]
[    2.985277] pci_bus 0000:00: root bus resource [io  0x03e0-0x0cf7]
[    2.985657] pci_bus 0000:00: root bus resource [io  0x03b0-0x03df]
[    2.986029] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
[    2.986399] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
[    2.986810] pci_bus 0000:00: root bus resource [mem 0x000c0000-0x000dffff]
[    2.987214] pci_bus 0000:00: root bus resource [mem 0xd0000000-0xffffffff]
[    2.987631] pci 0000:00:00.0: [1022:1705] type 00 class 0x060000
[    2.988106] pci 0000:00:01.0: [1002:9640] type 00 class 0x030000
[    2.988487] pci 0000:00:01.0: reg 10: [mem 0xd0000000-0xdfffffff pref]
[    2.988893] pci 0000:00:01.0: reg 14: [io  0xf000-0xf0ff]
[    2.989246] pci 0000:00:01.0: reg 18: [mem 0xfeb00000-0xfeb3ffff]
[    2.989743] pci 0000:00:01.0: supports D1 D2
[    2.990053] pci 0000:00:01.1: [1002:1714] type 00 class 0x040300
[    2.990442] pci 0000:00:01.1: reg 10: [mem 0xfeb44000-0xfeb47fff]
[    2.990965] pci 0000:00:01.1: supports D1 D2
[    2.991343] pci 0000:00:10.0: [1022:7812] type 00 class 0x0c0330
[    2.991752] pci 0000:00:10.0: reg 10: [mem 0xfeb4a000-0xfeb4bfff 64bit]
[    2.992355] pci 0000:00:10.0: PME# supported from D0 D3hot D3cold
[    2.992803] pci 0000:00:10.1: [1022:7812] type 00 class 0x0c0330
[    2.993201] pci 0000:00:10.1: reg 10: [mem 0xfeb48000-0xfeb49fff 64bit]
[    2.993793] pci 0000:00:10.1: PME# supported from D0 D3hot D3cold
[    2.994239] pci 0000:00:11.0: [1022:7801] type 00 class 0x010601
[    2.994637] pci 0000:00:11.0: reg 10: [io  0xf140-0xf147]
[    2.994982] pci 0000:00:11.0: reg 14: [io  0xf130-0xf133]
[    2.995333] pci 0000:00:11.0: reg 18: [io  0xf120-0xf127]
[    2.995678] pci 0000:00:11.0: reg 1c: [io  0xf110-0xf113]
[    2.996024] pci 0000:00:11.0: reg 20: [io  0xf100-0xf10f]
[    2.996374] pci 0000:00:11.0: reg 24: [mem 0xfeb51000-0xfeb517ff]
[    2.996850] pci 0000:00:12.0: [1022:7807] type 00 class 0x0c0310
[    2.997235] pci 0000:00:12.0: reg 10: [mem 0xfeb50000-0xfeb50fff]
[    2.997765] pci 0000:00:12.2: [1022:7808] type 00 class 0x0c0320
[    2.998161] pci 0000:00:12.2: reg 10: [mem 0xfeb4f000-0xfeb4f0ff]
[    2.998712] pci 0000:00:12.2: supports D1 D2
[    2.998977] pci 0000:00:12.2: PME# supported from D0 D1 D2 D3hot
[    2.999375] pci 0000:00:13.0: [1022:7807] type 00 class 0x0c0310
[    2.999768] pci 0000:00:13.0: reg 10: [mem 0xfeb4e000-0xfeb4efff]
[    3.000283] pci 0000:00:13.2: [1022:7808] type 00 class 0x0c0320
[    3.000681] pci 0000:00:13.2: reg 10: [mem 0xfeb4d000-0xfeb4d0ff]
[    3.001227] pci 0000:00:13.2: supports D1 D2
[    3.001495] pci 0000:00:13.2: PME# supported from D0 D1 D2 D3hot
[    3.001902] pci 0000:00:14.0: [1022:780b] type 00 class 0x0c0500
[    3.002433] pci 0000:00:14.2: [1022:780d] type 00 class 0x040300
[    3.002840] pci 0000:00:14.2: reg 10: [mem 0xfeb40000-0xfeb43fff 64bit]
[    3.003376] pci 0000:00:14.2: PME# supported from D0 D3hot D3cold
[    3.003761] pci 0000:00:14.3: [1022:780e] type 00 class 0x060100
[    3.004279] pci 0000:00:14.4: [1022:780f] type 01 class 0x060401
[    3.004730] pci 0000:00:14.5: [1022:7809] type 00 class 0x0c0310
[    3.005119] pci 0000:00:14.5: reg 10: [mem 0xfeb4c000-0xfeb4cfff]
[    3.005641] pci 0000:00:15.0: [1022:43a0] type 01 class 0x060400
[    3.006187] pci 0000:00:15.0: supports D1 D2
[    3.006515] pci 0000:00:15.1: [1022:43a1] type 01 class 0x060400
[    3.007059] pci 0000:00:15.1: supports D1 D2
[    3.007403] pci 0000:00:18.0: [1022:1700] type 00 class 0x060000
[    3.007868] pci 0000:00:18.1: [1022:1701] type 00 class 0x060000
[    3.008320] pci 0000:00:18.2: [1022:1702] type 00 class 0x060000
[    3.008778] pci 0000:00:18.3: [1022:1703] type 00 class 0x060000
[    3.009271] pci 0000:00:18.4: [1022:1704] type 00 class 0x060000
[    3.009716] pci 0000:00:18.5: [1022:1718] type 00 class 0x060000
[    3.010167] pci 0000:00:18.6: [1022:1716] type 00 class 0x060000
[    3.010615] pci 0000:00:18.7: [1022:1719] type 00 class 0x060000
[    3.011117] pci 0000:01:05.0: [9710:9835] type 00 class 0x070002
[    3.011513] pci 0000:01:05.0: reg 10: [io  0xe050-0xe057]
[    3.011861] pci 0000:01:05.0: reg 14: [io  0xe040-0xe047]
[    3.012210] pci 0000:01:05.0: reg 18: [io  0xe030-0xe037]
[    3.012563] pci 0000:01:05.0: reg 1c: [io  0xe020-0xe027]
[    3.012912] pci 0000:01:05.0: reg 20: [io  0xe010-0xe017]
[    3.013259] pci 0000:01:05.0: reg 24: [io  0xe000-0xe00f]
[    3.013710] pci 0000:00:14.4: PCI bridge to [bus 01] (subtractive decode)
[    3.014118] pci 0000:00:14.4:   bridge window [io  0xe000-0xefff]
[    3.014496] pci 0000:00:14.4:   bridge window [io  0x0000-0x03af] (subtractive decode)
[    3.014967] pci 0000:00:14.4:   bridge window [io  0x03e0-0x0cf7] (subtractive decode)
[    3.015422] pci 0000:00:14.4:   bridge window [io  0x03b0-0x03df] (subtractive decode)
[    3.015878] pci 0000:00:14.4:   bridge window [io  0x0d00-0xffff] (subtractive decode)
[    3.016343] pci 0000:00:14.4:   bridge window [mem 0x000a0000-0x000bffff] (subtractive decode)
[    3.016836] pci 0000:00:14.4:   bridge window [mem 0x000c0000-0x000dffff] (subtractive decode)
[    3.017326] pci 0000:00:14.4:   bridge window [mem 0xd0000000-0xffffffff] (subtractive decode)
[    3.017990] pci 0000:02:00.0: [8086:10d3] type 00 class 0x020000
[    3.018379] pci 0000:02:00.0: reg 10: [mem 0xfeac0000-0xfeadffff]
[    3.018769] pci 0000:02:00.0: reg 14: [mem 0xfea00000-0xfea7ffff]
[    3.019167] pci 0000:02:00.0: reg 18: [io  0xd000-0xd01f]
[    3.019522] pci 0000:02:00.0: reg 1c: [mem 0xfeae0000-0xfeae3fff]
[    3.019964] pci 0000:02:00.0: reg 30: [mem 0xfea80000-0xfeabffff pref]
[    3.020508] pci 0000:02:00.0: PME# supported from D0 D3hot D3cold
[    3.023962] pci 0000:00:15.0: PCI bridge to [bus 02]
[    3.024307] pci 0000:00:15.0:   bridge window [io  0xd000-0xdfff]
[    3.024689] pci 0000:00:15.0:   bridge window [mem 0xfea00000-0xfeafffff]
[    3.025293] pci 0000:03:00.0: [1969:1083] type 00 class 0x020000
[    3.025712] pci 0000:03:00.0: reg 10: [mem 0xfe900000-0xfe93ffff 64bit]
[    3.026139] pci 0000:03:00.0: reg 18: [io  0xc000-0xc07f]
[    3.026691] pci 0000:03:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[    3.028949] pci 0000:00:15.1: PCI bridge to [bus 03]
[    3.029290] pci 0000:00:15.1:   bridge window [io  0xc000-0xcfff]
[    3.029671] pci 0000:00:15.1:   bridge window [mem 0xfe900000-0xfe9fffff]
[    3.030148] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
[    3.030844] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PE20._PRT]
[    3.031280] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PE21._PRT]
[    3.031782] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0PC._PRT]
[    3.032377]  pci0000:00: Requesting ACPI _OSC control (0x1d)
[    3.032947]  pci0000:00: ACPI _OSC control (0x1d) granted
[    3.051344] ACPI: PCI Interrupt Link [LN24] (IRQs *24)
[    3.051852] ACPI: PCI Interrupt Link [LN25] (IRQs *25)
[    3.052329] ACPI: PCI Interrupt Link [LN26] (IRQs *26)
[    3.052821] ACPI: PCI Interrupt Link [LN27] (IRQs *27)
[    3.053298] ACPI: PCI Interrupt Link [LN28] (IRQs *28)
[    3.053787] ACPI: PCI Interrupt Link [LN29] (IRQs *29)
[    3.054271] ACPI: PCI Interrupt Link [LN30] (IRQs *30)
[    3.054747] ACPI: PCI Interrupt Link [LN31] (IRQs *31)
[    3.055243] ACPI: PCI Interrupt Link [LN32] (IRQs *32)
[    3.055724] ACPI: PCI Interrupt Link [LN33] (IRQs *33)
[    3.056211] ACPI: PCI Interrupt Link [LN34] (IRQs *34)
[    3.056692] ACPI: PCI Interrupt Link [LN35] (IRQs *35)
[    3.057187] ACPI: PCI Interrupt Link [LN36] (IRQs *36)
[    3.057673] ACPI: PCI Interrupt Link [LN37] (IRQs *37)
[    3.058165] ACPI: PCI Interrupt Link [LN38] (IRQs *38)
[    3.058660] ACPI: PCI Interrupt Link [LN39] (IRQs *39)
[    3.059154] ACPI: PCI Interrupt Link [LN40] (IRQs *40)
[    3.059643] ACPI: PCI Interrupt Link [LN41] (IRQs *41)
[    3.060128] ACPI: PCI Interrupt Link [LN42] (IRQs *42)
[    3.060618] ACPI: PCI Interrupt Link [LN43] (IRQs *43)
[    3.061095] ACPI: PCI Interrupt Link [LN44] (IRQs *44)
[    3.061575] ACPI: PCI Interrupt Link [LN45] (IRQs *45)
[    3.062059] ACPI: PCI Interrupt Link [LN46] (IRQs *46)
[    3.062543] ACPI: PCI Interrupt Link [LN47] (IRQs *47)
[    3.063029] ACPI: PCI Interrupt Link [LN48] (IRQs *48)
[    3.063506] ACPI: PCI Interrupt Link [LN49] (IRQs *49)
[    3.063989] ACPI: PCI Interrupt Link [LN50] (IRQs *50)
[    3.064473] ACPI: PCI Interrupt Link [LN51] (IRQs *51)
[    3.064950] ACPI: PCI Interrupt Link [LN52] (IRQs *52)
[    3.065440] ACPI: PCI Interrupt Link [LN53] (IRQs *53)
[    3.065918] ACPI: PCI Interrupt Link [LN54] (IRQs *54)
[    3.066402] ACPI: PCI Interrupt Link [LN55] (IRQs *55)
[    3.066889] ACPI: PCI Interrupt Link [LNKA] (IRQs 4 5 7 10 11 14 15) *0
[    3.068826] ACPI: PCI Interrupt Link [LNKB] (IRQs 4 5 7 10 11 14 15) *0
[    3.069717] ACPI: PCI Interrupt Link [LNKC] (IRQs 4 5 7 10 11 14 15) *0
[    3.070606] ACPI: PCI Interrupt Link [LNKD] (IRQs 4 5 7 10 11 14 15) *0
[    3.071479] ACPI: PCI Interrupt Link [LNKE] (IRQs 4 5 7 10 11 14 15) *0
[    3.072339] ACPI: PCI Interrupt Link [LNKF] (IRQs 4 5 7 10 11 14 15) *0
[    3.073195] ACPI: PCI Interrupt Link [LNKG] (IRQs 4 5 7 10 11 14 15) *0
[    3.074064] ACPI: PCI Interrupt Link [LNKH] (IRQs 4 5 7 10 11 14 15) *0
[    3.075123] xen/balloon: Initialising balloon driver.
[    3.076280] xen-balloon: Initialising balloon driver.
[    3.076885] xen/balloon: Xen selfballooning driver disabled for domain0.
[    3.077545] vgaarb: device added: PCI:0000:00:01.0,decodes=io+mem,owns=io+mem,locks=none
[    3.078080] vgaarb: loaded
[    3.078268] vgaarb: bridge control possible 0000:00:01.0
[    3.078970] ACPI: bus type usb registered
[    3.079409] usbcore: registered new interface driver usbfs
[    3.079813] usbcore: registered new interface driver hub
[    3.080257] usbcore: registered new device driver usb
[    3.081098] PCI: Using ACPI for IRQ routing
[    3.098106] PCI: pci_cache_line_size set to 64 bytes
[    3.098606] e820: reserve RAM buffer [mem 0x0009d000-0x0009ffff]
[    3.098972] e820: reserve RAM buffer [mem 0x4d063000-0x4fffffff]
[    3.099810] NetLabel: Initializing
[    3.100040] NetLabel:  domain hash size = 128
[    3.100313] NetLabel:  protocols = UNLABELED CIPSOv4
[    3.100639] NetLabel:  unlabeled traffic allowed by default
[    3.101361] Switching to clocksource xen
[    3.109135] pnp: PnP ACPI init
[    3.109362] ACPI: bus type pnp registered
[    3.109832] pnp 00:00: [bus 00-ff]
[    3.110058] pnp 00:00: [io  0x0cf8-0x0cff]
[    3.110319] pnp 00:00: [io  0x0000-0x03af window]
[    3.110611] pnp 00:00: [io  0x03e0-0x0cf7 window]
[    3.110912] pnp 00:00: [io  0x03b0-0x03df window]
[    3.111200] pnp 00:00: [io  0x0d00-0xffff window]
[    3.111492] pnp 00:00: [mem 0x000a0000-0x000bffff window]
[    3.111826] pnp 00:00: [mem 0x000c0000-0x000dffff window]
[    3.112154] pnp 00:00: [mem 0xd0000000-0xffffffff window]
[    3.112482] pnp 00:00: [mem 0x00000000 window]
[    3.113097] pnp 00:00: Plug and Play ACPI device, IDs PNP0a03 (active)
[    3.113537] pnp 00:01: [mem 0xe0000000-0xefffffff]
[    3.114213] system 00:01: [mem 0xe0000000-0xefffffff] has been reserved
[    3.114626] system 00:01: Plug and Play ACPI device, IDs PNP0c01 (active)
[    3.116690] pnp 00:02: [io  0x0010-0x001f]
[    3.116955] pnp 00:02: [io  0x0022-0x003f]
[    3.117210] pnp 00:02: [io  0x0063]
[    3.117439] pnp 00:02: [io  0x0065]
[    3.117667] pnp 00:02: [io  0x0067-0x006f]
[    3.117932] pnp 00:02: [io  0x0072-0x007f]
[    3.118191] pnp 00:02: [io  0x0080]
[    3.118415] pnp 00:02: [io  0x0084-0x0086]
[    3.118668] pnp 00:02: [io  0x0088]
[    3.118910] pnp 00:02: [io  0x008c-0x008e]
[    3.119174] pnp 00:02: [io  0x0090-0x009f]
[    3.119436] pnp 00:02: [io  0x00a2-0x00bf]
[    3.119706] pnp 00:02: [io  0x00b1]
[    3.119936] pnp 00:02: [io  0x00e0-0x00ef]
[    3.120194] pnp 00:02: [io  0x04d0-0x04d1]
[    3.120455] pnp 00:02: [io  0x040b]
[    3.120683] pnp 00:02: [io  0x04d6]
[    3.120916] pnp 00:02: [io  0x0c00-0x0c01]
[    3.121172] pnp 00:02: [io  0x0c14]
[    3.121397] pnp 00:02: [io  0x0c50-0x0c51]
[    3.121653] pnp 00:02: [io  0x0c52]
[    3.121885] pnp 00:02: [io  0x0c6c]
[    3.122109] pnp 00:02: [io  0x0c6f]
[    3.122335] pnp 00:02: [io  0x0cd0-0x0cd1]
[    3.122591] pnp 00:02: [io  0x0cd2-0x0cd3]
[    3.122860] pnp 00:02: [io  0x0cd4-0x0cd5]
[    3.123120] pnp 00:02: [io  0x0cd6-0x0cd7]
[    3.123377] pnp 00:02: [io  0x0cd8-0x0cdf]
[    3.123633] pnp 00:02: [io  0x0800-0x089f]
[    3.123898] pnp 00:02: [io  0x0000-0xffffffffffffffff disabled]
[    3.124249] pnp 00:02: [io  0x0000-0x000f]
[    3.124506] pnp 00:02: [io  0x0b20-0x0b3f]
[    3.124768] pnp 00:02: [io  0x0900-0x090f]
[    3.125026] pnp 00:02: [io  0x0910-0x091f]
[    3.125282] pnp 00:02: [io  0xfe00-0xfefe]
[    3.125537] pnp 00:02: [io  0x0060-0x005f disabled]
[    3.125841] pnp 00:02: [io  0x0064-0x0063 disabled]
[    3.126136] pnp 00:02: [mem 0xfec00000-0xfec00fff]
[    3.126426] pnp 00:02: [mem 0xfee00000-0xfee00fff]
[    3.126724] pnp 00:02: [mem 0xfed80000-0xfed8ffff]
[    3.127024] pnp 00:02: [mem 0xfed61000-0xfed70fff]
[    3.127321] pnp 00:02: [mem 0xfec10000-0xfec10fff]
[    3.127619] pnp 00:02: [mem 0xfed00000-0xfed00fff]
[    3.127920] pnp 00:02: [mem 0xff000000-0xffffffff]
[    3.128629] system 00:02: [io  0x04d0-0x04d1] has been reserved
[    3.129033] system 00:02: [io  0x040b] has been reserved
[    3.129358] system 00:02: [io  0x04d6] has been reserved
[    3.129680] system 00:02: [io  0x0c00-0x0c01] has been reserved
[    3.130042] system 00:02: [io  0x0c14] has been reserved
[    3.130365] system 00:02: [io  0x0c50-0x0c51] has been reserved
[    3.130727] system 00:02: [io  0x0c52] has been reserved
[    3.131046] system 00:02: [io  0x0c6c] has been reserved
[    3.131369] system 00:02: [io  0x0c6f] has been reserved
[    3.131692] system 00:02: [io  0x0cd0-0x0cd1] has been reserved
[    3.132047] system 00:02: [io  0x0cd2-0x0cd3] has been reserved
[    3.132401] system 00:02: [io  0x0cd4-0x0cd5] has been reserved
[    3.132756] system 00:02: [io  0x0cd6-0x0cd7] has been reserved
[    3.133111] system 00:02: [io  0x0cd8-0x0cdf] has been reserved
[    3.133460] system 00:02: [io  0x0800-0x089f] has been reserved
[    3.133814] system 00:02: [io  0x0b20-0x0b3f] has been reserved
[    3.134168] system 00:02: [io  0x0900-0x090f] has been reserved
[    3.134524] system 00:02: [io  0x0910-0x091f] has been reserved
[    3.134888] system 00:02: [io  0xfe00-0xfefe] has been reserved
[    3.135250] system 00:02: [mem 0xfec00000-0xfec00fff] could not be reserved
[    3.135651] system 00:02: [mem 0xfee00000-0xfee00fff] has been reserved
[    3.136053] system 00:02: [mem 0xfed80000-0xfed8ffff] has been reserved
[    3.136437] system 00:02: [mem 0xfed61000-0xfed70fff] has been reserved
[    3.136829] system 00:02: [mem 0xfec10000-0xfec10fff] has been reserved
[    3.137219] system 00:02: [mem 0xfed00000-0xfed00fff] has been reserved
[    3.137608] system 00:02: [mem 0xff000000-0xffffffff] has been reserved
[    3.138015] system 00:02: Plug and Play ACPI device, IDs PNP0c02 (active)
[    3.138611] pnp 00:03: [io  0x0000-0xffffffffffffffff disabled]
[    3.138981] pnp 00:03: [io  0x0300-0x031f]
[    3.139249] pnp 00:03: [io  0x0290-0x029f]
[    3.139512] pnp 00:03: [io  0x0230-0x023f]
[    3.140070] system 00:03: [io  0x0300-0x031f] has been reserved
[    3.140431] system 00:03: [io  0x0290-0x029f] has been reserved
[    3.140800] system 00:03: [io  0x0230-0x023f] has been reserved
[    3.141165] system 00:03: Plug and Play ACPI device, IDs PNP0c02 (active)
[    3.141595] pnp 00:04: [dma 4]
[    3.141809] pnp 00:04: [io  0x0000-0x000f]
[    3.142070] pnp 00:04: [io  0x0081-0x0083]
[    3.142330] pnp 00:04: [io  0x0087]
[    3.142557] pnp 00:04: [io  0x0089-0x008b]
[    3.142825] pnp 00:04: [io  0x008f]
[    3.143052] pnp 00:04: [io  0x00c0-0x00df]
[    3.143532] pnp 00:04: Plug and Play ACPI device, IDs PNP0200 (active)
[    3.143961] pnp 00:05: [io  0x0070-0x0071]
[    3.144222] xen: registering gsi 8 triggering 1 polarity 0
[    3.144562] pnp 00:05: [irq 8]
[    3.145001] pnp 00:05: Plug and Play ACPI device, IDs PNP0b00 (active)
[    3.145408] pnp 00:06: [io  0x0061]
[    3.145932] pnp 00:06: Plug and Play ACPI device, IDs PNP0800 (active)
[    3.146422] pnp 00:07: [io  0x0010-0x001f]
[    3.146682] pnp 00:07: [io  0x0022-0x003f]
[    3.146977] pnp 00:07: [io  0x0044-0x005f]
[    3.147238] pnp 00:07: [io  0x0072-0x007f]
[    3.147491] pnp 00:07: [io  0x0080]
[    3.147722] pnp 00:07: [io  0x0084-0x0086]
[    3.147980] pnp 00:07: [io  0x0088]
[    3.148211] pnp 00:07: [io  0x008c-0x008e]
[    3.148469] pnp 00:07: [io  0x0090-0x009f]
[    3.148734] pnp 00:07: [io  0x00a2-0x00bf]
[    3.148988] pnp 00:07: [io  0x00e0-0x00ef]
[    3.149250] pnp 00:07: [io  0x04d0-0x04d1]
[    3.149697] system 00:07: [io  0x04d0-0x04d1] has been reserved
[    3.150061] system 00:07: Plug and Play ACPI device, IDs PNP0c02 (active)
[    3.150478] pnp 00:08: [io  0x00f0-0x00ff]
[    3.150755] xen: registering gsi 13 triggering 1 polarity 0
[    3.151101] pnp 00:08: [irq 13]
[    3.151448] pnp 00:08: Plug and Play ACPI device, IDs PNP0c04 (active)
[    3.152100] system 00:09: Plug and Play ACPI device, IDs PNP0c02 (active)
[    3.152778] pnp 00:0a: [io  0x03f8-0x03ff]
[    3.153037] xen: registering gsi 4 triggering 1 polarity 0
[    3.153376] pnp 00:0a: [irq 4]
[    3.153581] pnp 00:0a: [dma 0 disabled]
[    3.153998] pnp 00:0a: Plug and Play ACPI device, IDs PNP0501 (active)
[    3.155394] pnp 00:0b: [mem 0xfed00000-0xfed003ff]
[    3.155978] pnp 00:0b: Plug and Play ACPI device, IDs PNP0103 (active)
[    3.156388] pnp: PnP ACPI: found 12 devices
[    3.156653] ACPI: ACPI bus type pnp unregistered
[    3.156953] xen-pciback: Error parsing pci_devs_to_hide at "(00:02:00)"
[    3.170459] PM-Timer failed consistency check  (0x0xffffff) - aborting.
[    3.170947] pci 0000:00:14.4: PCI bridge to [bus 01]
[    3.171261] pci 0000:00:14.4:   bridge window [io  0xe000-0xefff]
[    3.171655] pci 0000:00:15.0: PCI bridge to [bus 02]
[    3.171974] pci 0000:00:15.0:   bridge window [io  0xd000-0xdfff]
[    3.172345] pci 0000:00:15.0:   bridge window [mem 0xfea00000-0xfeafffff]
[    3.172762] pci 0000:00:15.1: PCI bridge to [bus 03]
[    3.173067] pci 0000:00:15.1:   bridge window [io  0xc000-0xcfff]
[    3.173436] pci 0000:00:15.1:   bridge window [mem 0xfe900000-0xfe9fffff]
[    3.173889] xen: registering gsi 16 triggering 0 polarity 1
[    3.174247] xen: --> pirq=16 -> irq=16 (gsi=16)
[    3.174547] xen: registering gsi 16 triggering 0 polarity 1
[    3.174894] Already setup the GSI :16
[    3.175131] pci_bus 0000:00: resource 4 [io  0x0000-0x03af]
[    3.175470] pci_bus 0000:00: resource 5 [io  0x03e0-0x0cf7]
[    3.176854] pci_bus 0000:00: resource 6 [io  0x03b0-0x03df]
[    3.177184] pci_bus 0000:00: resource 7 [io  0x0d00-0xffff]
[    3.177514] pci_bus 0000:00: resource 8 [mem 0x000a0000-0x000bffff]
[    3.177891] pci_bus 0000:00: resource 9 [mem 0x000c0000-0x000dffff]
[    3.178267] pci_bus 0000:00: resource 10 [mem 0xd0000000-0xffffffff]
[    3.178649] pci_bus 0000:01: resource 0 [io  0xe000-0xefff]
[    3.178994] pci_bus 0000:01: resource 4 [io  0x0000-0x03af]
[    3.179326] pci_bus 0000:01: resource 5 [io  0x03e0-0x0cf7]
[    3.179672] pci_bus 0000:01: resource 6 [io  0x03b0-0x03df]
[    3.180015] pci_bus 0000:01: resource 7 [io  0x0d00-0xffff]
[    3.180344] pci_bus 0000:01: resource 8 [mem 0x000a0000-0x000bffff]
[    3.180716] pci_bus 0000:01: resource 9 [mem 0x000c0000-0x000dffff]
[    3.181081] pci_bus 0000:01: resource 10 [mem 0xd0000000-0xffffffff]
[    3.181452] pci_bus 0000:02: resource 0 [io  0xd000-0xdfff]
[    3.181792] pci_bus 0000:02: resource 1 [mem 0xfea00000-0xfeafffff]
[    3.182168] pci_bus 0000:03: resource 0 [io  0xc000-0xcfff]
[    3.182505] pci_bus 0000:03: resource 1 [mem 0xfe900000-0xfe9fffff]
[    3.183045] NET: Registered protocol family 2
[    3.184322] TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
[    3.186023] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[    3.186732] TCP: Hash tables configured (established 262144 bind 65536)
[    3.187181] TCP: reno registered
[    3.187411] UDP hash table entries: 1024 (order: 3, 32768 bytes)
[    3.187803] UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes)
[    3.188405] NET: Registered protocol family 1
[    3.188924] RPC: Registered named UNIX socket transport module.
[    3.189285] RPC: Registered udp transport module.
[    3.189588] RPC: Registered tcp transport module.
[    3.189901] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    3.190306] pci 0000:00:01.0: Boot video device
[    3.190606] xen: registering gsi 18 triggering 0 polarity 1
[    3.190967] xen: --> pirq=18 -> irq=18 (gsi=18)
[    3.191310] xen: registering gsi 17 triggering 0 polarity 1
[    3.191651] xen: --> pirq=17 -> irq=17 (gsi=17)
[    3.191987] xen: registering gsi 18 triggering 0 polarity 1
[    3.192322] Already setup the GSI :18
[    3.779210] xen: registering gsi 17 triggering 0 polarity 1
[    3.779560] Already setup the GSI :17
[    3.779854] xen: registering gsi 18 triggering 0 polarity 1
[    3.780189] Already setup the GSI :18
[    3.852950] xen: registering gsi 17 triggering 0 polarity 1
[    3.853302] Already setup the GSI :17
[    3.853601] xen: registering gsi 18 triggering 0 polarity 1
[    3.853944] Already setup the GSI :18
[    3.927246] PCI: CLS 64 bytes, default 64
[    3.927731] Unpacking initramfs...
[    4.409499] Freeing initrd memory: 339204k freed
[    4.502233] Machine check injector initialized
[    4.504138] microcode: CPU0: patch_level=0x0300000f
[    4.504463] microcode: CPU1: patch_level=0x0300000f
[    4.504809] microcode: CPU2: patch_level=0x0300000f
[    4.505347] microcode: Microcode Update Driver: v2.00 , Peter Oruba
[    4.506684] audit: initializing netlink socket (disabled)
[    4.507060] type=2000 audit(1351615437.471:1): initialized
[    4.520849] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[    4.521549] VFS: Disk quotas dquot_6.5.2
[    4.521865] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    4.522596] NFS: Registering the id_resolver key type
[    4.522935] Key type id_resolver registered
[    4.523199] Key type id_legacy registered
[    4.523463] NTFS driver 2.1.30 [Flags: R/W].
[    4.523927] msgmni has been set to 1798
[    4.524230] SELinux:  Registering netfilter hooks
[    4.526131] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
[    4.526572] io scheduler noop registered
[    4.526834] io scheduler deadline registered
[    4.527129] io scheduler cfq registered (default)
[    4.528468] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[    4.529395] input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input0
[    4.529907] ACPI: Power Button [PWRB]
[    4.530299] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
[    4.530782] ACPI: Power Button [PWRF]
[    4.592637] GHES: HEST is not enabled!
[    4.592910] ioatdma: Intel(R) QuickData Technology Driver 4.00
[    4.594402] xen-pciback: backend is vpci
[    4.666851] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    4.688746] 00:0a: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[    4.692137] xen: registering gsi 20 triggering 0 polarity 1
[    4.692685] xen: --> pirq=20 -> irq=20 (gsi=20)
[    4.715090] 0000:01:05.0: ttyS1 at I/O 0xe050 (irq = 20) is a 16550A
[    4.723123] hpet_acpi_add: no address or irqs in _CRS
[    4.729073] Non-volatile memory driver v1.3
[    4.733807] Linux agpgart interface v0.103
[    4.739678] [drm] Initialized drm 1.1.0 20060810
[    4.747593] loop: module loaded
[    4.751865] libphy: Fixed MDIO Bus: probed
[    4.756157] tun: Universal TUN/TAP device driver, 1.6
[    4.761408] tun: (C) 1999-2004 Max Krasnyansky 
[    4.768474] ixgbevf: Intel(R) 10 Gigabit PCI Express Virtual Function Network Driver - version 2.6.0-k
[    4.778143] ixgbevf: Copyright (c) 2009 - 2012 Intel Corporation.
[    4.786308] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    4.793112] ehci_hcd: block sizes: qh 104 qtd 96 itd 192 sitd 96
[    4.799394] xen: registering gsi 17 triggering 0 polarity 1
[    4.805186] Already setup the GSI :17
[    4.809041] ehci_hcd 0000:00:12.2: EHCI Host Controller
[    4.814827] ehci_hcd 0000:00:12.2: new USB bus registered, assigned bus number 1
[    4.822582] QUIRK: Enable AMD PLL fix
[    4.826402] ehci_hcd 0000:00:12.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround
[    4.835422] ehci_hcd 0000:00:12.2: reset hcs_params 0x101505 dbg=1 cc=1 pcc=5 ordered !ppc ports=5
[    4.844716] ehci_hcd 0000:00:12.2: reset hcc_params a076 thresh 7 uframes 256/512/1024 park
[    4.853444] ehci_hcd 0000:00:12.2: park 0
[    4.857628] ehci_hcd 0000:00:12.2: reset command 0080b02  park=3 ithresh=8 period=1024 Reset HALT
[    4.866843] ehci_hcd 0000:00:12.2: debug port 1
[    4.871568] ehci_hcd 0000:00:12.2: MWI active
[    4.876100] ehci_hcd 0000:00:12.2: supports USB remote wakeup
[    4.882116] ehci_hcd 0000:00:12.2: irq 17, io mem 0xfeb4f000
[    4.887997] ehci_hcd 0000:00:12.2: init command 0010005 (park)=0 ithresh=1 period=512 RUN
[    4.901882] ehci_hcd 0000:00:12.2: USB 2.0 started, EHCI 1.00
[    4.907965] usb usb1: default language 0x0409
[    4.912513] usb usb1: udev 1, busnum 1, minor = 0
[    4.917409] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[    4.924454] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    4.931952] usb usb1: Product: EHCI Host Controller
[    4.937024] usb usb1: Manufacturer: Linux 3.7.0-rc3upstream-00220-g37b7153 ehci_hcd
[    4.944967] usb usb1: SerialNumber: 0000:00:12.2
[    4.950259] usb usb1: usb_probe_device
[    4.954193] usb usb1: configuration #1 chosen from 1 choice
[    4.959997] usb usb1: adding 1-0:1.0 (config #1, interface 0)
[    4.966339] hub 1-0:1.0: usb_probe_interface
[    4.970812] hub 1-0:1.0: usb_probe_interface - got id
[    4.976063] hub 1-0:1.0: USB hub found
[    4.979980] hub 1-0:1.0: 5 ports detected
[    4.984155] hub 1-0:1.0: standalone hub
[    4.988148] hub 1-0:1.0: no power switching (usb 1.0)
[    4.993398] hub 1-0:1.0: individual port over-current protection
[    4.999631] hub 1-0:1.0: power on to power good time: 20ms
[    5.005333] hub 1-0:1.0: local power source is good
[    5.010998] hub 1-0:1.0: trying to enable port power on non-switchable hub
[    5.018235] xen: registering gsi 17 triggering 0 polarity 1
[    5.024028] Already setup the GSI :17
[    5.027880] ehci_hcd 0000:00:13.2: EHCI Host Controller
[    5.033663] ehci_hcd 0000:00:13.2: new USB bus registered, assigned bus number 2
[    5.041377] ehci_hcd 0000:00:13.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround
[    5.050398] ehci_hcd 0000:00:13.2: reset hcs_params 0x101505 dbg=1 cc=1 pcc=5 ordered !ppc ports=5
[    5.059685] ehci_hcd 0000:00:13.2: reset hcc_params a076 thresh 7 uframes 256/512/1024 park
[    5.068427] ehci_hcd 0000:00:13.2: park 0
[    5.072610] ehci_hcd 0000:00:13.2: reset command 0080b02  park=3 ithresh=8 period=1024 Reset HALT
[    5.081823] ehci_hcd 0000:00:13.2: debug port 1
[    5.086547] ehci_hcd 0000:00:13.2: MWI active
[    5.091081] ehci_hcd 0000:00:13.2: supports USB remote wakeup
[    5.097059] ehci_hcd 0000:00:13.2: irq 17, io mem 0xfeb4d000
[    5.102937] ehci_hcd 0000:00:13.2: init command 0010005 (park)=0 ithresh=1 period=512 RUN
[    5.116889] ehci_hcd 0000:00:13.2: USB 2.0 started, EHCI 1.00
[    5.123004] usb usb2: default language 0x0409
[    5.127553] usb usb2: udev 1, busnum 2, minor = 128
[    5.132627] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
[    5.139668] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    5.147164] usb usb2: Product: EHCI Host Controller
[    5.152236] usb usb2: Manufacturer: Linux 3.7.0-rc3upstream-00220-g37b7153 ehci_hcd
[    5.160180] usb usb2: SerialNumber: 0000:00:13.2
[    5.165185] hub 1-0:1.0: state 7 ports 5 chg 0000 evt 0000
[    5.165547] usb usb2: usb_probe_device
[    5.165551] usb usb2: configuration #1 chosen from 1 choice
[    5.165570] usb usb2: adding 2-0:1.0 (config #1, interface 0)
[    5.165905] hub 2-0:1.0: usb_probe_interface
[    5.165908] hub 2-0:1.0: usb_probe_interface - got id
[    5.165911] hub 2-0:1.0: USB hub found
[    5.165929] hub 2-0:1.0: 5 ports detected
[    5.165930] hub 2-0:1.0: standalone hub
[    5.165931] hub 2-0:1.0: no power switching (usb 1.0)
[    5.165933] hub 2-0:1.0: individual port over-current protection
[    5.165935] hub 2-0:1.0: power on to power good time: 20ms
[    5.165942] hub 2-0:1.0: local power source is good
[    5.166518] hub 2-0:1.0: trying to enable port power on non-switchable hub
[    5.166966] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    5.166969] ohci_hcd: block sizes: ed 80 td 96
[    5.167028] xen: registering gsi 18 triggering 0 polarity 1
[    5.167033] Already setup the GSI :18
[    5.167075] ohci_hcd 0000:00:12.0: OHCI Host Controller
[    5.167260] ohci_hcd 0000:00:12.0: new USB bus registered, assigned bus number 3
[    5.167338] ohci_hcd 0000:00:12.0: created debug files
[    5.167340] ohci_hcd 0000:00:12.0: supports USB remote wakeup
[    5.167385] ohci_hcd 0000:00:12.0: irq 18, io mem 0xfeb50000
[    5.289966] hub 2-0:1.0: state 7 ports 5 chg 0000 evt 0000
[    5.293989] ohci_hcd 0000:00:12.0: OHCI controller state
[    5.293995] ohci_hcd 0000:00:12.0: OHCI 1.0, NO legacy support registers, rh state running
[    5.293999] ohci_hcd 0000:00:12.0: control 0x283 RWC HCFS=operational CBSR=3
[    5.294002] ohci_hcd 0000:00:12.0: cmdstatus 0x00000 SOC=0
[    5.294006] ohci_hcd 0000:00:12.0: intrstatus 0x00000004 SF
[    5.294009] ohci_hcd 0000:00:12.0: intrenable 0x8000005a MIE RHSC UE RD WDH
[    5.294019] ohci_hcd 0000:00:12.0: hcca frame #0005
[    5.294022] ohci_hcd 0000:00:12.0: roothub.a 02001205 POTPGT=2 NOCP NPS NDP=5(5)
[    5.294025] ohci_hcd 0000:00:12.0: roothub.b 00000000 PPCM=0000 DR=0000
[    5.294027] ohci_hcd 0000:00:12.0: roothub.status 00008000 DRWE
[    5.294031] ohci_hcd 0000:00:12.0: roothub.portstatus [0] 0x00000100 PPS
[    5.294034] ohci_hcd 0000:00:12.0: roothub.portstatus [1] 0x00000100 PPS
[    5.294037] ohci_hcd 0000:00:12.0: roothub.portstatus [2] 0x00000100 PPS
[    5.294041] ohci_hcd 0000:00:12.0: roothub.portstatus [3] 0x00000100 PPS
[    5.294044] ohci_hcd 0000:00:12.0: roothub.portstatus [4] 0x00000100 PPS
[    5.294080] usb usb3: default language 0x0409
[    5.294093] usb usb3: udev 1, busnum 3, minor = 256
[    5.294095] usb usb3: New USB device found, idVendor=1d6b, idProduct=0001
[    5.294097] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    5.294098] usb usb3: Product: OHCI Host Controller
[    5.294100] usb usb3: Manufacturer: Linux 3.7.0-rc3upstream-00220-g37b7153 ohci_hcd
[    5.294101] usb usb3: SerialNumber: 0000:00:12.0
[    5.294371] usb usb3: usb_probe_device
[    5.294374] usb usb3: configuration #1 chosen from 1 choice
[    5.294386] usb usb3: adding 3-0:1.0 (config #1, interface 0)
[    5.294481] hub 3-0:1.0: usb_probe_interface
[    5.294482] hub 3-0:1.0: usb_probe_interface - got id
[    5.294484] hub 3-0:1.0: USB hub found
[    5.294492] hub 3-0:1.0: 5 ports detected
[    5.294493] hub 3-0:1.0: standalone hub
[    5.294495] hub 3-0:1.0: no power switching (usb 1.0)
[    5.294496] hub 3-0:1.0: no over-current protection
[    5.294497] hub 3-0:1.0: power on to power good time: 4ms
[    5.294505] hub 3-0:1.0: local power source is good
[    5.295074] hub 3-0:1.0: trying to enable port power on non-switchable hub
[    5.295131] ehci_hcd 0000:00:12.2: HS companion for 0000:00:12.0
[    5.295174] xen: registering gsi 18 triggering 0 polarity 1
[    5.295178] Already setup the GSI :18
[    5.295219] ohci_hcd 0000:00:13.0: OHCI Host Controller
[    5.295337] ohci_hcd 0000:00:13.0: new USB bus registered, assigned bus number 4
[    5.295397] ohci_hcd 0000:00:13.0: created debug files
[    5.295399] ohci_hcd 0000:00:13.0: supports USB remote wakeup
[    5.295409] ohci_hcd 0000:00:13.0: irq 18, io mem 0xfeb4e000
[    5.549971] hub 3-0:1.0: state 7 ports 5 chg 0000 evt 0000
[    5.553975] ohci_hcd 0000:00:13.0: OHCI controller state
[    5.553980] ohci_hcd 0000:00:13.0: OHCI 1.0, NO legacy support registers, rh state running
[    5.553984] ohci_hcd 0000:00:13.0: control 0x283 RWC HCFS=operational CBSR=3
[    5.553987] ohci_hcd 0000:00:13.0: cmdstatus 0x00000 SOC=0
[    5.553990] ohci_hcd 0000:00:13.0: intrstatus 0x00000004 SF
[    5.553993] ohci_hcd 0000:00:13.0: intrenable 0x8000005a MIE RHSC UE RD WDH
[    5.554004] ohci_hcd 0000:00:13.0: hcca frame #0005
[    5.554008] ohci_hcd 0000:00:13.0: roothub.a 02001205 POTPGT=2 NOCP NPS NDP=5(5)
[    5.554011] ohci_hcd 0000:00:13.0: roothub.b 00000000 PPCM=0000 DR=0000
[    5.554014] ohci_hcd 0000:00:13.0: roothub.status 00008000 DRWE
[    5.554018] ohci_hcd 0000:00:13.0: roothub.portstatus [0] 0x00000100 PPS
[    5.554021] ohci_hcd 0000:00:13.0: roothub.portstatus [1] 0x00000100 PPS
[    5.554025] ohci_hcd 0000:00:13.0: roothub.portstatus [2] 0x00000100 PPS
[    5.554028] ohci_hcd 0000:00:13.0: roothub.portstatus [3] 0x00000100 PPS
[    5.554031] ohci_hcd 0000:00:13.0: roothub.portstatus [4] 0x00000100 PPS
[    5.554051] usb usb4: default language 0x0409
[    5.554064] usb usb4: udev 1, busnum 4, minor = 384
[    5.554066] usb usb4: New USB device found, idVendor=1d6b, idProduct=0001
[    5.554068] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    5.554070] usb usb4: Product: OHCI Host Controller
[    5.554071] usb usb4: Manufacturer: Linux 3.7.0-rc3upstream-00220-g37b7153 ohci_hcd
[    5.554072] usb usb4: SerialNumber: 0000:00:13.0
[    5.554538] usb usb4: usb_probe_device
[    5.554542] usb usb4: configuration #1 chosen from 1 choice
[    5.554559] usb usb4: adding 4-0:1.0 (config #1, interface 0)
[    5.554665] hub 4-0:1.0: usb_probe_interface
[    5.554667] hub 4-0:1.0: usb_probe_interface - got id
[    5.554669] hub 4-0:1.0: USB hub found
[    5.554678] hub 4-0:1.0: 5 ports detected
[    5.554679] hub 4-0:1.0: standalone hub
[    5.554681] hub 4-0:1.0: no power switching (usb 1.0)
[    5.554682] hub 4-0:1.0: no over-current protection
[    5.554683] hub 4-0:1.0: power on to power good time: 4ms
[    5.554691] hub 4-0:1.0: local power source is good
[    5.555283] hub 4-0:1.0: trying to enable port power on non-switchable hub
[    5.555346] ehci_hcd 0000:00:13.2: HS companion for 0000:00:13.0
[    5.555389] xen: registering gsi 18 triggering 0 polarity 1
[    5.555394] Already setup the GSI :18
[    5.555433] ohci_hcd 0000:00:14.5: OHCI Host Controller
[    5.555598] ohci_hcd 0000:00:14.5: new USB bus registered, assigned bus number 5
[    5.555670] ohci_hcd 0000:00:14.5: created debug files
[    5.555672] ohci_hcd 0000:00:14.5: supports USB remote wakeup
[    5.555685] ohci_hcd 0000:00:14.5: irq 18, io mem 0xfeb4c000
[    5.809859] hub 4-0:1.0: state 7 ports 5 chg 0000 evt 0000
[    5.813841] ohci_hcd 0000:00:14.5: OHCI controller state
[    5.813847] ohci_hcd 0000:00:14.5: OHCI 1.0, NO legacy support registers, rh state running
[    5.813851] ohci_hcd 0000:00:14.5: control 0x283 RWC HCFS=operational CBSR=3
[    5.813854] ohci_hcd 0000:00:14.5: cmdstatus 0x00000 SOC=0
[    5.813857] ohci_hcd 0000:00:14.5: intrstatus 0x00000004 SF
[    5.813860] ohci_hcd 0000:00:14.5: intrenable 0x8000005a MIE RHSC UE RD WDH
[    5.813871] ohci_hcd 0000:00:14.5: hcca frame #0004
[    5.813874] ohci_hcd 0000:00:14.5: roothub.a 02001202 POTPGT=2 NOCP NPS NDP=2(2)
[    5.813876] ohci_hcd 0000:00:14.5: roothub.b 00000000 PPCM=0000 DR=0000
[    5.813880] ohci_hcd 0000:00:14.5: roothub.status 00008000 DRWE
[    5.813884] ohci_hcd 0000:00:14.5: roothub.portstatus [0] 0x00000100 PPS
[    5.813886] ohci_hcd 0000:00:14.5: roothub.portstatus [1] 0x00000100 PPS
[    5.813923] usb usb5: default language 0x0409
[    5.813935] usb usb5: udev 1, busnum 5, minor = 512
[    5.813938] usb usb5: New USB device found, idVendor=1d6b, idProduct=0001
[    5.813939] usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    5.813941] usb usb5: Product: OHCI Host Controller
[    5.813942] usb usb5: Manufacturer: Linux 3.7.0-rc3upstream-00220-g37b7153 ohci_hcd
[    5.813944] usb usb5: SerialNumber: 0000:00:14.5
[    5.814220] usb usb5: usb_probe_device
[    5.814223] usb usb5: configuration #1 chosen from 1 choice
[    5.814238] usb usb5: adding 5-0:1.0 (config #1, interface 0)
[    5.814373] hub 5-0:1.0: usb_probe_interface
[    5.814375] hub 5-0:1.0: usb_probe_interface - got id
[    5.814377] hub 5-0:1.0: USB hub found
[    5.814390] hub 5-0:1.0: 2 ports detected
[    5.814392] hub 5-0:1.0: standalone hub
[    5.814393] hub 5-0:1.0: no power switching (usb 1.0)
[    5.814394] hub 5-0:1.0: no over-current protection
[    5.814396] hub 5-0:1.0: power on to power good time: 4ms
[    5.814405] hub 5-0:1.0: local power source is good
[    5.814425] hub 5-0:1.0: trying to enable port power on non-switchable hub
[    5.814584] uhci_hcd: USB Universal Host Controller Interface driver
[    6.009259] hub 5-0:1.0: state 7 ports 2 chg 0000 evt 0000
[    6.009372] usbcore: registered new interface driver usblp
[    6.009676] i8042: PNP: No PS/2 controller found. Probing ports directly.
[    6.010397] serio: i8042 KBD port at 0x60,0x64 irq 1
[    6.010409] serio: i8042 AUX port at 0x60,0x64 irq 12
[    6.010691] mousedev: PS/2 mouse device common for all mice
[    6.011327] rtc_cmos 00:05: RTC can wake from S4
[    6.011618] rtc_cmos 00:05: rtc core: registered rtc_cmos as rtc0
[    6.011662] rtc0: alarms up to one month, y3k, 114 bytes nvram
[    6.011868] EFI Variables Facility v0.08 2004-May-17
[    6.011957] zram: num_devices not specified. Using default: 1
[    6.011958] zram: Creating 1 devices ...
[    6.077064] Netfilter messages via NETLINK v0.30.
[    6.082006] nf_conntrack version 0.5.0 (7194 buckets, 28776 max)
[    6.088334] ctnetlink v0.93: registering with nfnetlink.
[    6.094201] ip_tables: (C) 2000-2006 Netfilter Core Team
[    6.099817] TCP: cubic registered
[    6.103279] Initializing XFRM netlink socket
[    6.107873] NET: Registered protocol family 10
[    6.112784] ip6_tables: (C) 2000-2006 Netfilter Core Team
[    6.119125] sit: IPv6 over IPv4 tunneling driver
[    6.124870] NET: Registered protocol family 17
[    6.129593] Key type dns_resolver registered
[    6.135108] PM: Hibernation image not present or could not be loaded.
[    6.141853] registered taskstats version 1
[    6.146837]   Magic number: 0:661:743
[    6.151899] Freeing unused kernel memory: 752k freed
[    6.157248] Write protecting the kernel read-only data: 10240k
[    6.169212] Freeing unused kernel memory: 1768k freed
[    6.175129] Freeing unused kernel memory: 168k freed
[    6.188257] consoletype (1257) used greatest stack depth: 5272 bytes left
[    6.524961] modprobe (1286) used greatest stack depth: 5256 bytes left
[    6.547403] core_filesystem (1258) used greatest stack depth: 4952 bytes left
[    6.592358] Initialising Xen virtual ethernet driver.
[    6.722568] wmi: Mapper loaded
[    6.796831] xen: registering gsi 17 triggering 0 polarity 1
[    6.802666] Already setup the GSI :17
[    6.808260] e1000e: Intel(R) PRO/1000 Network Driver - 2.1.4-k
[    6.814354] e1000e: Copyright(c) 1999 - 2012 Intel Corporation.
[    6.816573] SCSI subsystem initialized
[    6.824498] e1000e 0000:02:00.0: Disabling ASPM L0s L1
[    6.824524] xen: registering gsi 16 triggering 0 polarity 1
[    6.824531] Already setup the GSI :16
[    6.824740] e1000e 0000:02:00.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
[    6.859455] [drm] radeon defaulting to kernel modesetting.
[    6.866428] [drm] radeon kernel modesetting enabled.
[    6.873121] xen: registering gsi 18 triggering 0 polarity 1
[    6.873126] Already setup the GSI :18
[    6.883269] atl1c 0000:03:00.0: version 1.0.1.0-NAPI
[    6.883447] [drm] initializing kernel modesetting (SUMO 0x1002:0x9640 0x1043:0x84C8).
[    6.883509] [drm] register mmio base: 0xFEB00000
[    6.883511] [drm] register mmio size: 262144
[    6.883646] ATOM BIOS: General
[    6.883717] radeon 0000:00:01.0: VRAM: 512M 0x0000000000000000 - 0x000000001FFFFFFF (512M used)
[    6.883720] radeon 0000:00:01.0: GTT: 512M 0x0000000020000000 - 0x000000003FFFFFFF
[    6.883722] [drm] Detected VRAM RAM=512M, BAR=256M
[    6.883725] [drm] RAM width 32bits DDR
[    6.884463] [TTM] Zone  kernel: Available graphics memory: 461822 kiB
[    6.884466] [TTM] Initializing pool allocator
[    6.884476] [TTM] Initializing DMA pool allocator
[    6.884529] [drm] radeon: 512M of VRAM memory ready
[    6.884531] [drm] radeon: 512M of GTT memory ready.
[    6.884622] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[    6.884625] [drm] Driver supports precise vblank timestamp query.
[    6.884802] radeon 0000:00:01.0: radeon: using MSI.
[    6.884865] [drm] radeon: irq initialized.
[    6.884871] [drm] GART: num cpu pages 131072, num gpu pages 131072
[    6.895835] [drm] Loading SUMO Microcode
[    6.933742] ACPI: bus type scsi registered
[    6.941860] e1000e 0000:02:00.0 eth1: (PCI Express:2.5GT/s:Width x1) 00:1b:21:ab:c6:12
[    6.941862] e1000e 0000:02:00.0 eth1: Intel(R) PRO/1000 Network Connection
[    6.941882] e1000e 0000:02:00.0 eth1: MAC: 3, PHY: 8, PBA No: E46981-005
[    6.997612] ip (1909) used greatest stack depth: 3896 bytes left
[    7.048540] libata version 3.00 loaded.
[    7.144568] [drm] PCIE GART of 512M enabled (table at 0x0000000000040000).
[    7.151898] radeon 0000:00:01.0: WB enabled
[    7.156253] radeon 0000:00:01.0: fence driver on ring 0 use gpu addr 0x0000000020000c00 and cpu addr 0xffff880023235c00
[    7.185375] [drm] ring test on 0 succeeded in 1 usecs
[    7.191817] [drm] ib test on ring 0 succeeded in 0 usecs
[    7.209657] [drm] Radeon Display Connectors
[    7.214052] [drm] Connector 0:
[    7.217253] [drm]   VGA-1
[    7.220007] [drm]   HPD2
[    7.222674] [drm]   DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448 0x644c 0x644c
[    7.230416] [drm]   Encoders:
[    7.233539] [drm]     CRT1: INTERNAL_UNIPHY2
[    7.238001] [drm]     CRT1: NUTMEG
[    7.238003] [drm] Connector 1:
[    7.238005] [drm]   HDMI-A-1
[    7.238006] [drm]   HPD1
[    7.238009] [drm]   DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c 0x643c
[    7.238011] [drm]   Encoders:
[    7.238011] [drm]     DFP1: INTERNAL_UNIPHY2
[    7.255949] [drm] Internal thermal controller without fan control
[    7.259955] [drm] radeon: power management initialized
[    7.335529] No connectors reported connected with modes
[    7.340968] [drm] Cannot find any crtc or sizes - going 1024x768
[    7.350906] [drm] fb mappable at 0xD0142000
[    7.355261] [drm] vram apper at 0xD0000000
[    7.359523] [drm] size 3145728
[    7.362716] [drm] fb depth is 24
[    7.366146] [drm]    pitch is 4096
[    7.370065] fbcon: radeondrmfb (fb0) is primary device
[    7.376982] ttyS1: 1 input overrun(s)
[    7.411210] Console: switching to colour frame buffer device 128x48
[    7.424071] fb0: radeondrmfb frame buffer device
[    7.428949] drm: registered panic notifier
[    7.433284] [drm] Initialized radeon 2.24.0 20080528 for 0000:00:01.0 on minor 0
[    7.441164] ahci 0000:00:11.0: version 3.0
[    7.445546] xen: registering gsi 19 triggering 0 polarity 1
[    7.451464] xen: --> pirq=19 -> irq=19 (gsi=19)
[    7.456473] ahci 0000:00:11.0: AHCI 0001.0300 32 slots 6 ports 6 Gbps 0x3f impl SATA mode
[    7.465104] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part 
[    7.478140] scsi0 : ahci
[    7.481629] scsi1 : ahci
[    7.484929] scsi2 : ahci
[    7.488287] scsi3 : ahci
[    7.491496] scsi4 : ahci
[    7.494907] scsi5 : ahci
[    7.498649] ata1: SATA max UDMA/133 abar m2048@0xfeb51000 port 0xfeb51100 irq 71
[    7.507585] ata2: SATA max UDMA/133 abar m2048@0xfeb51000 port 0xfeb51180 irq 71
[    7.515392] ata3: SATA max UDMA/133 abar m2048@0xfeb51000 port 0xfeb51200 irq 71
[    7.523177] ata4: SATA max UDMA/133 abar m2048@0xfeb51000 port 0xfeb51280 irq 71
[    7.530982] ata5: SATA max UDMA/133 abar m2048@0xfeb51000 port 0xfeb51300 irq 71
[    7.538786] ata6: SATA max UDMA/133 abar m2048@0xfeb51000 port 0xfeb51380 irq 71
[    7.850775] ata1: SATA link down (SStatus 0 SControl 300)
[    7.856613] ata2: SATA link down (SStatus 0 SControl 300)
[    7.862497] ata6: SATA link down (SStatus 0 SControl 300)
[    7.871228] ata3: SATA link down (SStatus 0 SControl 300)
[    7.879887] ata5: SATA link down (SStatus 0 SControl 300)
[    8.038131] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[    8.062593] ata4.00: ATA-7: WDC WD800AAJS-18TDA0, 01.00A03, max UDMA/133
[    8.072417] ata4.00: 156250000 sectors, multi 16: LBA48 NCQ (depth 31/32), AA
[    8.082336] ata4.00: failed to get Identify Device Data, Emask 0x1
[    8.092297] ata4.00: failed to get Identify Device Data, Emask 0x1
[    8.100682] ata4.00: configured for UDMA/133
[    8.107497] scsi 3:0:0:0: Direct-Access     ATA      WDC WD800AAJS-18 01.0 PQ: 0 ANSI: 5
[    8.129843] sd 3:0:0:0: [sda] 156250000 512-byte logical blocks: (80.0 GB/74.5 GiB)
[    8.140007] sd 3:0:0:0: [sda] Write Protect is off
[    8.146945] sd 3:0:0:0: [sda] Mode Sense: 00 3a 00 00
[    8.154244] sd 3:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    8.199771]  sda: sda1 sda2 sda3 sda4
[    8.210772] sd 3:0:0:0: [sda] Attached SCSI disk
[    8.224663] sd 3:0:0:0: Attached scsi generic sg0 type 0
[    8.944409] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[    8.963120] device eth0 entered promiscuous mode
[    9.181754] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[   10.053518] atl1c 0000:03:00.0: atl1c: eth0 NIC Link is Up<1000 Mbps Full Duplex>
[   10.064785] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   11.555156] e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
[   11.566749] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[   13.964892] switch: port 1(eth0) entered forwarding state
[   13.973524] switch: port 1(eth0) entered forwarding state
[   16.232334] Loading iSCSI transport class v2.0-870.
[   16.248793] iscsi: registered transport (tcp)
[   16.306470] Event-channel device installed.
[   19.630065] mount.nfs (3143) used greatest stack depth: 3224 bytes left
[   21.157586] device-mapper: ioctl: 4.23.0-ioctl (2012-07-25) initialised: dm-devel@redhat.com
[   21.170420] device-mapper: multipath: version 1.5.0 loaded
[   21.450531] scsi6 : iSCSI Initiator over TCP/IP
[   21.731710] scsi 6:0:0:0: Direct-Access     LIO-ORG  IBLOCK           4.0  PQ: 0 ANSI: 5
[   21.747167] sd 6:0:0:0: [sdb] 503316480 512-byte logical blocks: (257 GB/240 GiB)
[   21.747211] sd 6:0:0:0: Attached scsi generic sg1 type 0
[   21.748648] scsi 6:0:0:1: Direct-Access     LIO-ORG  IBLOCK           4.0  PQ: 0 ANSI: 5
[   21.752968] sd 6:0:0:1: [sdc] 167772160 512-byte logical blocks: (85.8 GB/80.0 GiB)
[   21.753042] sd 6:0:0:1: Attached scsi generic sg2 type 0
[   21.755647] sd 6:0:0:1: [sdc] Write Protect is off
[   21.755655] sd 6:0:0:1: [sdc] Mode Sense: 2f 00 00 00
[   21.756638] sd 6:0:0:1: [sdc] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[   21.761219] scsi 6:0:0:2: Direct-Access     LIO-ORG  IBLOCK           4.0  PQ: 0 ANSI: 5
[   21.770871] sd 6:0:0:2: Attached scsi generic sg3 type 0
[   21.771168] sd 6:0:0:2: [sdd] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB)
[   21.775163] ttyS1: 1 input overrun(s)
[   21.776400] sd 6:0:0:2: [sdd] Write Protect is off
[   21.776405] sd 6:0:0:2: [sdd] Mode Sense: 2f 00 00 00
[   21.776884] sd 6:0:0:2: [sdd] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[   21.780001]  sdd: unknown partition table
[   21.781272] sd 6:0:0:2: [sdd] Attached SCSI disk
[   21.804226]  sdc: sdc1 sdc2 < sdc5 >
[   21.806353] sd 6:0:0:1: [sdc] Attached SCSI disk
[   21.918632] sd 6:0:0:0: [sdb] Write Protect is off
[   21.926413] sd 6:0:0:0: [sdb] Mode Sense: 2f 00 00 00
[   21.935417] sd 6:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[   21.963859]  sdb: unknown partition table
[   21.974284] sd 6:0:0:0: [sdb] Attached SCSI disk
[   28.589544] bio: create slab  at 1
[   28.997728] switch: port 1(eth0) entered forwarding state
[   57.703132] device vif1.0 entered promiscuous mode
[   57.715328] IPv6: ADDRCONF(NETDEV_UP): vif1.0: link is not ready
[   59.760909] IPv6: ADDRCONF(NETDEV_CHANGE): vif1.0: link becomes ready
[   59.770384] switch: port 2(vif1.0) entered forwarding state
[   59.778900] switch: port 2(vif1.0) entered forwarding state
[   59.876529] xen-blkback:ring-ref 10, event-channel 18, protocol 2 (x86_32-abi) persistent grants
[   65.135453] switch: port 2(vif1.0) entered disabled state
[   65.145638] device vif1.0 left promiscuous mode
[   65.154458] switch: port 2(vif1.0) entered disabled state
[   70.836602] device vif2.0 entered promiscuous mode
[   70.848191] IPv6: ADDRCONF(NETDEV_UP): vif2.0: link is not ready
[   72.285945] IPv6: ADDRCONF(NETDEV_CHANGE): vif2.0: link becomes ready
[   72.295310] switch: port 2(vif2.0) entered forwarding state
[   72.303597] switch: port 2(vif2.0) entered forwarding state
[   72.403140] xen-blkback:ring-ref 10, event-channel 11, protocol 1 (x86_64-abi) persistent grants
[   72.544101] ------------[ cut here ]------------
[   72.552932] kernel BUG at /home/konrad/linux/drivers/block/xen-blkback/blkback.c:589!
[   72.563680] invalid opcode: 0000 [#1] SMP 
[   72.570865] Modules linked in: dm_multipath dm_mod xen_evtchn iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi libcrc32c crc32c sg sd_mod ahci libahci libata radeon e1000e scsi_mod atl1c fbcon ttm tileblit font bitblit softcursor drm_kms_helper wmi xen_blkfront xen_netfront fb_sys_fops sysimgblt sysfillrect syscopyarea xenfs xen_privcmd [last unloaded: dump_dma]
[   72.617251] CPU 0 
[   72.619173] Pid: 3823, comm: blkback.2.xvda Tainted: G           O 3.7.0-rc3upstream-00220-g37b7153 #1 System manufacturer System Product Name/F1A75-M
[   72.641606] RIP: e030:[]  [] xen_blkbk_map+0x696/0x6e0
[   72.653181] RSP: e02b:ffff880027dd3728  EFLAGS: 00010246
[   72.661651] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[   72.672090] RDX: ffff8800232d7f40 RSI: 0000000000000000 RDI: ffff880027dd3d88
[   72.682437] RBP: ffff880027dd39e8 R08: 0000000000000000 R09: 0000000000000000
[   72.692835] R10: 0000000000000001 R11: dead000000200200 R12: 0000000000000000
[   72.703261] R13: 0000000000000000 R14: ffff88002b5e7070 R15: 0000000000000000
[   72.713560] FS:  00007f6cc62d5700(0000) GS:ffff88003e000000(0000) knlGS:0000000000000000
[   72.724921] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[   72.733811] CR2: 00000000006dd384 CR3: 0000000027b8f000 CR4: 0000000000000660
[   72.744131] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   72.754517] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[   72.764882] Process blkback.2.xvda (pid: 3823, threadinfo ffff880027dd2000, task ffff88002bb15040)
[   72.777140] Stack:
[   72.782184]  ffff880027dd3738 ffff880026081af0 ffff880027dd3798 ffffffff810ac7df
[   72.792960]  ffff880027dd3798 ffffffff8104c506 0000000000000117 ffff88002160d030
[   72.803712]  ffff880027dd3a38 ffff88002b5e7120 ffff88002160d000 ffff880027dd3d88
[   72.814469] Call Trace:
[   72.820094]  [] ? __queue_work+0xff/0x420
[   72.829023]  [] ? xen_spin_lock_flags+0xb6/0x120
[   72.838462]  [] ? queue_work_on+0x31/0x50
[   72.847279]  [] ? _raw_spin_unlock_irqrestore+0x19/0x30
[   72.854408] ttyS1: 2 input overrun(s)
[   72.864352]  [] ? pvclock_clocksource_read+0x58/0xd0
[   72.874471]  [] ? cpumask_next_and+0x23/0x40
[   72.883656]  [] ? cpumask_next_and+0x23/0x40
[   72.892716]  [] ? update_sd_lb_stats+0x157/0x6c0
[   72.902178]  [] ? _raw_spin_lock_irq+0x20/0x30
[   72.911486]  [] ? find_busiest_group+0x31/0x4d0
[   72.920849]  [] dispatch_rw_block_io+0x377/0x600
[   72.930187]  [] ? pvclock_clocksource_read+0x58/0xd0
[   72.939957]  [] ? xen_mc_flush+0xc0/0x1f0
[   72.948743]  [] ? xen_end_context_switch+0x19/0x20
[   72.958251]  [] ? pvclock_clocksource_read+0x58/0xd0
[   72.967917]  [] ? pvclock_clocksource_read+0x58/0xd0
[   72.977617]  [] ? pvclock_clocksource_read+0x58/0xd0
[   72.987474]  [] ? xen_clocksource_read+0x39/0x50
[   72.997278]  [] ? xen_spin_lock_flags+0xb6/0x120
[   73.006476]  [] xen_blkif_schedule+0x21e/0xa00
[   73.015493]  [] ? irq_to_desc+0x12/0x20
[   73.023833]  [] ? irq_get_irq_data+0x9/0x10
[   73.032418]  [] ? info_for_irq+0x9/0x20
[   73.040554]  [] ? notify_remote_via_irq+0x29/0x50
[   73.049523]  [] ? sched_clock_cpu+0xcd/0x110
[   73.058024]  [] ? pvclock_clocksource_read+0x58/0xd0
[   73.067191]  [] ? xen_mc_flush+0xc0/0x1f0
[   73.075338]  [] ? __schedule+0x3be/0x7c0
[   73.083311]  [] ? wake_up_bit+0x40/0x40
[   73.091108]  [] ? dispatch_rw_block_io+0x600/0x600
[   73.099902]  [] kthread+0xc6/0xd0
[   73.107124]  [] ? xen_end_context_switch+0x19/0x20
[   73.115845]  [] ? kthread_freezable_should_stop+0x80/0x80
[   73.125266]  [] ret_from_fork+0x7c/0xb0
[   73.133089]  [] ? kthread_freezable_should_stop+0x80/0x80
[   73.142576] Code: 48 89 d7 e8 ad 66 d8 ff 4a c7 84 3d 70 ff ff ff 00 00 00 00 4c 8b 85 60 fd ff ff 41 8b b0 e4 fd ff ff 41 83 cd 01 e9 ef fb ff ff <0f> 0b eb fe 48 8d 95 10 ff ff ff 48 8d bd b0 fd ff ff 31 f6 44 
[   73.167611] RIP  [] xen_blkbk_map+0x696/0x6e0
[   73.176081]  RSP 
[   73.182024] ---[ end trace 914a52d8b62134db ]---
[   87.339441] switch: port 2(vif2.0) entered forwarding state
[  315.067569] device tap3.0 entered promiscuous mode
[  315.074965] switch: port 3(tap3.0) entered forwarding state
[  315.083116] switch: port 3(tap3.0) entered forwarding state
[  315.142543] switch: port 3(tap3.0) entered disabled state
[  315.161150] switch: port 3(tap3.0) entered forwarding state
[  315.169097] switch: port 3(tap3.0) entered forwarding state
[  330.162411] switch: port 3(tap3.0) entered forwarding state
[  415.483626] switch: port 3(tap3.0) entered disabled state
[  415.491439] device tap3.0 left promiscuous mode
[  415.498191] switch: port 3(tap3.0) entered disabled state
[  658.839306] device tap4.0 entered promiscuous mode
[  658.846451] switch: port 3(tap4.0) entered forwarding state
[  658.854354] switch: port 3(tap4.0) entered forwarding state
[  658.923751] switch: port 3(tap4.0) entered disabled state
[  658.942642] switch: port 3(tap4.0) entered forwarding state
[  658.950492] switch: port 3(tap4.0) entered forwarding state
[  673.990219] switch: port 3(tap4.0) entered forwarding state
[  759.263762] switch: port 3(tap4.0) entered disabled state
[  759.271529] device tap4.0 left promiscuous mode
[  759.278257] switch: port 3(tap4.0) entered disabled state

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 17:49:01 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 17:49:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTFv3-0004JT-50; Tue, 30 Oct 2012 17:48:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTFv2-0004JO-4Y
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 17:48:04 +0000
Received: from [85.158.139.211:26369] by server-1.bemta-5.messagelabs.com id
	12/DD-21640-3D210905; Tue, 30 Oct 2012 17:48:03 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1351619281!18285539!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30229 invoked from network); 30 Oct 2012 17:48:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 17:48:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,680,1344211200"; d="scan'208";a="15496933"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 17:48:01 +0000
Received: from [192.168.1.30] (10.31.3.235) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 30 Oct 2012 17:48:01 +0000
Message-ID: <509012D0.8030501@citrix.com>
Date: Tue, 30 Oct 2012 18:48:00 +0100
From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: Ian Jackson 
References: <1351588958-75040-1-git-send-email-roger.pau@citrix.com>
	<20623.60420.97632.890498@mariner.uk.xensource.com>
	<5090011D.9080406@citrix.com>
	<20624.3892.618566.138065@mariner.uk.xensource.com>
In-Reply-To: <20624.3892.618566.138065@mariner.uk.xensource.com>
Cc: Christoph Egger ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 1/2] autoconf: check for wget and ftp
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 30/10/12 18:32, Ian Jackson wrote:
> Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH 1/2] autoconf: check fo=
r wget and ftp"):
>> On 30/10/12 16:02, Ian Jackson wrote:
>>> I don't think this can be right; wget is used in many more places.  At
>>> the very least it looks like it will break the stubdom build since
>>> that is full of WGET.  Did you grep for WGET ?
>>
>> Does stubdom build import config/Tools.mk? I thought it was only used to
>> build the tools directory. If that's the case I don't think it will
>> break anything, since we define a new variable $FETCHER, that shouldn't
>> be used anywhere else, so the rest will continue to use the hardcoded
>> wget, or whatever it was using prior to this patch.
> =

> Err, yes, it seems stubdom/Makefile has its own definition of wget.
> But stubdom builds are still going to be broken without wget then ?

Yes, but I don't think we should check for the requirements of stubdoms
build process if we are not going to include config/Tools.mk to build
them. For example NetBSD cannot build stubdoms (for other reasons), so
we shouldn't enforce wget presence in configure.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 17:49:01 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 17:49:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTFv3-0004JT-50; Tue, 30 Oct 2012 17:48:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTFv2-0004JO-4Y
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 17:48:04 +0000
Received: from [85.158.139.211:26369] by server-1.bemta-5.messagelabs.com id
	12/DD-21640-3D210905; Tue, 30 Oct 2012 17:48:03 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1351619281!18285539!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30229 invoked from network); 30 Oct 2012 17:48:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 17:48:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,680,1344211200"; d="scan'208";a="15496933"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 17:48:01 +0000
Received: from [192.168.1.30] (10.31.3.235) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 30 Oct 2012 17:48:01 +0000
Message-ID: <509012D0.8030501@citrix.com>
Date: Tue, 30 Oct 2012 18:48:00 +0100
From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: Ian Jackson 
References: <1351588958-75040-1-git-send-email-roger.pau@citrix.com>
	<20623.60420.97632.890498@mariner.uk.xensource.com>
	<5090011D.9080406@citrix.com>
	<20624.3892.618566.138065@mariner.uk.xensource.com>
In-Reply-To: <20624.3892.618566.138065@mariner.uk.xensource.com>
Cc: Christoph Egger ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 1/2] autoconf: check for wget and ftp
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 30/10/12 18:32, Ian Jackson wrote:
> Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH 1/2] autoconf: check fo=
r wget and ftp"):
>> On 30/10/12 16:02, Ian Jackson wrote:
>>> I don't think this can be right; wget is used in many more places.  At
>>> the very least it looks like it will break the stubdom build since
>>> that is full of WGET.  Did you grep for WGET ?
>>
>> Does stubdom build import config/Tools.mk? I thought it was only used to
>> build the tools directory. If that's the case I don't think it will
>> break anything, since we define a new variable $FETCHER, that shouldn't
>> be used anywhere else, so the rest will continue to use the hardcoded
>> wget, or whatever it was using prior to this patch.
> =

> Err, yes, it seems stubdom/Makefile has its own definition of wget.
> But stubdom builds are still going to be broken without wget then ?

Yes, but I don't think we should check for the requirements of stubdoms
build process if we are not going to include config/Tools.mk to build
them. For example NetBSD cannot build stubdoms (for other reasons), so
we shouldn't enforce wget presence in configure.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 18:12:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 18:12:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTGHe-0004nw-Bo; Tue, 30 Oct 2012 18:11:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTGHd-0004nr-6k
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 18:11:25 +0000
Received: from [85.158.143.99:5345] by server-3.bemta-4.messagelabs.com id
	09/D2-24279-C4810905; Tue, 30 Oct 2012 18:11:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1351620683!22723520!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15682 invoked from network); 30 Oct 2012 18:11:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 18:11:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,682,1344211200"; d="scan'208";a="15497279"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 18:11:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 30 Oct 2012 18:11:22 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TTGHa-0001Q5-Bg; Tue, 30 Oct 2012 18:11:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TTGHa-0004PN-86;
	Tue, 30 Oct 2012 18:11:22 +0000
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20624.6217.908884.422774@mariner.uk.xensource.com>
Date: Tue, 30 Oct 2012 18:11:21 +0000
To: Roger Pau Monne 
In-Reply-To: <509012D0.8030501@citrix.com>
References: <1351588958-75040-1-git-send-email-roger.pau@citrix.com>
	<20623.60420.97632.890498@mariner.uk.xensource.com>
	<5090011D.9080406@citrix.com>
	<20624.3892.618566.138065@mariner.uk.xensource.com>
	<509012D0.8030501@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Christoph Egger ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 1/2] autoconf: check for wget and ftp
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("Re: [Xen-devel] [PATCH 1/2] autoconf: check for wget and ftp"):
> On 30/10/12 18:32, Ian Jackson wrote:
> > Err, yes, it seems stubdom/Makefile has its own definition of wget.
> > But stubdom builds are still going to be broken without wget then ?
> 
> Yes, but I don't think we should check for the requirements of stubdoms
> build process if we are not going to include config/Tools.mk to build
> them. For example NetBSD cannot build stubdoms (for other reasons), so
> we shouldn't enforce wget presence in configure.

Fair enough, thanks for the explanation.

Acked-by: Ian Jackson 
Committed-by: Ian Jackson 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 18:12:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 18:12:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTGHe-0004nw-Bo; Tue, 30 Oct 2012 18:11:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTGHd-0004nr-6k
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 18:11:25 +0000
Received: from [85.158.143.99:5345] by server-3.bemta-4.messagelabs.com id
	09/D2-24279-C4810905; Tue, 30 Oct 2012 18:11:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1351620683!22723520!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15682 invoked from network); 30 Oct 2012 18:11:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 18:11:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,682,1344211200"; d="scan'208";a="15497279"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 18:11:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 30 Oct 2012 18:11:22 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TTGHa-0001Q5-Bg; Tue, 30 Oct 2012 18:11:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TTGHa-0004PN-86;
	Tue, 30 Oct 2012 18:11:22 +0000
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20624.6217.908884.422774@mariner.uk.xensource.com>
Date: Tue, 30 Oct 2012 18:11:21 +0000
To: Roger Pau Monne 
In-Reply-To: <509012D0.8030501@citrix.com>
References: <1351588958-75040-1-git-send-email-roger.pau@citrix.com>
	<20623.60420.97632.890498@mariner.uk.xensource.com>
	<5090011D.9080406@citrix.com>
	<20624.3892.618566.138065@mariner.uk.xensource.com>
	<509012D0.8030501@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Christoph Egger ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 1/2] autoconf: check for wget and ftp
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Roger Pau Monne writes ("Re: [Xen-devel] [PATCH 1/2] autoconf: check for wget and ftp"):
> On 30/10/12 18:32, Ian Jackson wrote:
> > Err, yes, it seems stubdom/Makefile has its own definition of wget.
> > But stubdom builds are still going to be broken without wget then ?
> 
> Yes, but I don't think we should check for the requirements of stubdoms
> build process if we are not going to include config/Tools.mk to build
> them. For example NetBSD cannot build stubdoms (for other reasons), so
> we shouldn't enforce wget presence in configure.

Fair enough, thanks for the explanation.

Acked-by: Ian Jackson 
Committed-by: Ian Jackson 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 18:18:03 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 18:18:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTGNg-000531-5j; Tue, 30 Oct 2012 18:17:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTGNd-00052w-F5
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 18:17:38 +0000
Received: from [85.158.143.99:19808] by server-2.bemta-4.messagelabs.com id
	C5/16-22268-0C910905; Tue, 30 Oct 2012 18:17:36 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-3.tower-216.messagelabs.com!1351621055!27416272!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDQ2MTc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27938 invoked from network); 30 Oct 2012 18:17:36 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Oct 2012 18:17:36 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 179D227F9;
	Tue, 30 Oct 2012 20:17:33 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id EE0EC20059; Tue, 30 Oct 2012 20:17:32 +0200 (EET)
Date: Tue, 30 Oct 2012 20:17:32 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= 
To: Olaf Hering 
Message-ID: <20121030181732.GZ8912@reaktio.net>
References: <1351613105-24408-1-git-send-email-olaf@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1351613105-24408-1-git-send-email-olaf@aepfle.de>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH] xen PVonHVM: require at least Xen 3.4 as
 dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 30, 2012 at 05:05:05PM +0100, Olaf Hering wrote:
> The XenPVHVM extensions have not been tested much on very old
> hypervisors. At least Xen 3.4 gets some testing with the pvops kernel.
> 
> Require at least Xen 3.4 for the PVonHVM extensions. If an older
> hypervisor is detected the extensions will be disabled and the guest
> will only see emulated hardware.
> 
> Signed-off-by: Olaf Hering 
>

IIRC upstream Linux PVonHVM drivers do work OK today on RHEL5 Xen, 
which advertises itself as Xen 3.1.2-based..


-- Pasi


> ---
>  arch/x86/xen/enlighten.c | 27 ++++++++++++++++++---------
>  1 file changed, 18 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index 0cc41f8..8566fa8 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -1543,17 +1543,10 @@ static void __init xen_hvm_init_shared_info(void)
>  
>  static void __init init_hvm_pv_info(void)
>  {
> -	int major, minor;
>  	uint32_t eax, ebx, ecx, edx, pages, msr, base;
>  	u64 pfn;
>  
>  	base = xen_cpuid_base();
> -	cpuid(base + 1, &eax, &ebx, &ecx, &edx);
> -
> -	major = eax >> 16;
> -	minor = eax & 0xffff;
> -	printk(KERN_INFO "Xen version %d.%d.\n", major, minor);
> -
>  	cpuid(base + 2, &pages, &msr, &ecx, &edx);
>  
>  	pfn = __pa(hypercall_page);
> @@ -1604,13 +1597,29 @@ static void __init xen_hvm_guest_init(void)
>  
>  static bool __init xen_hvm_platform(void)
>  {
> +	int major, minor, old = 0;
> +	uint32_t eax, ebx, ecx, edx, base;
> +	bool usable = true;
> +
>  	if (xen_pv_domain())
>  		return false;
>  
> -	if (!xen_cpuid_base())
> +	base = xen_cpuid_base();
> +	if (!base)
>  		return false;
>  
> -	return true;
> +	cpuid(base + 1, &eax, &ebx, &ecx, &edx);
> +
> +	major = eax >> 16;
> +	minor = eax & 0xffff;
> +
> +	/* Require at least Xen 3.4 */
> +	if (major < 3 || (major == 3 && minor < 4))
> +		usable = false;
> +	printk(KERN_INFO "Xen version %d.%d.%s\n",
> +		major, minor, usable ? "" : " (too old)");
> +
> +	return usable;
>  }
>  
>  bool xen_hvm_need_lapic(void)
> -- 
> 1.8.0
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 18:18:03 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 18:18:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTGNg-000531-5j; Tue, 30 Oct 2012 18:17:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTGNd-00052w-F5
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 18:17:38 +0000
Received: from [85.158.143.99:19808] by server-2.bemta-4.messagelabs.com id
	C5/16-22268-0C910905; Tue, 30 Oct 2012 18:17:36 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-3.tower-216.messagelabs.com!1351621055!27416272!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDQ2MTc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27938 invoked from network); 30 Oct 2012 18:17:36 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Oct 2012 18:17:36 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 179D227F9;
	Tue, 30 Oct 2012 20:17:33 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id EE0EC20059; Tue, 30 Oct 2012 20:17:32 +0200 (EET)
Date: Tue, 30 Oct 2012 20:17:32 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= 
To: Olaf Hering 
Message-ID: <20121030181732.GZ8912@reaktio.net>
References: <1351613105-24408-1-git-send-email-olaf@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1351613105-24408-1-git-send-email-olaf@aepfle.de>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH] xen PVonHVM: require at least Xen 3.4 as
 dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 30, 2012 at 05:05:05PM +0100, Olaf Hering wrote:
> The XenPVHVM extensions have not been tested much on very old
> hypervisors. At least Xen 3.4 gets some testing with the pvops kernel.
> 
> Require at least Xen 3.4 for the PVonHVM extensions. If an older
> hypervisor is detected the extensions will be disabled and the guest
> will only see emulated hardware.
> 
> Signed-off-by: Olaf Hering 
>

IIRC upstream Linux PVonHVM drivers do work OK today on RHEL5 Xen, 
which advertises itself as Xen 3.1.2-based..


-- Pasi


> ---
>  arch/x86/xen/enlighten.c | 27 ++++++++++++++++++---------
>  1 file changed, 18 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index 0cc41f8..8566fa8 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -1543,17 +1543,10 @@ static void __init xen_hvm_init_shared_info(void)
>  
>  static void __init init_hvm_pv_info(void)
>  {
> -	int major, minor;
>  	uint32_t eax, ebx, ecx, edx, pages, msr, base;
>  	u64 pfn;
>  
>  	base = xen_cpuid_base();
> -	cpuid(base + 1, &eax, &ebx, &ecx, &edx);
> -
> -	major = eax >> 16;
> -	minor = eax & 0xffff;
> -	printk(KERN_INFO "Xen version %d.%d.\n", major, minor);
> -
>  	cpuid(base + 2, &pages, &msr, &ecx, &edx);
>  
>  	pfn = __pa(hypercall_page);
> @@ -1604,13 +1597,29 @@ static void __init xen_hvm_guest_init(void)
>  
>  static bool __init xen_hvm_platform(void)
>  {
> +	int major, minor, old = 0;
> +	uint32_t eax, ebx, ecx, edx, base;
> +	bool usable = true;
> +
>  	if (xen_pv_domain())
>  		return false;
>  
> -	if (!xen_cpuid_base())
> +	base = xen_cpuid_base();
> +	if (!base)
>  		return false;
>  
> -	return true;
> +	cpuid(base + 1, &eax, &ebx, &ecx, &edx);
> +
> +	major = eax >> 16;
> +	minor = eax & 0xffff;
> +
> +	/* Require at least Xen 3.4 */
> +	if (major < 3 || (major == 3 && minor < 4))
> +		usable = false;
> +	printk(KERN_INFO "Xen version %d.%d.%s\n",
> +		major, minor, usable ? "" : " (too old)");
> +
> +	return usable;
>  }
>  
>  bool xen_hvm_need_lapic(void)
> -- 
> 1.8.0
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 18:30:26 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 18:30:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTGYo-0005Jo-Cj; Tue, 30 Oct 2012 18:29:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTGYm-0005Jj-Q0
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 18:29:08 +0000
Received: from [85.158.139.211:42661] by server-1.bemta-5.messagelabs.com id
	81/C9-21640-37C10905; Tue, 30 Oct 2012 18:29:07 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-206.messagelabs.com!1351621747!18240627!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MzQxMTQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MzQxMTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19444 invoked from network); 30 Oct 2012 18:29:07 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Oct 2012 18:29:07 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr3c7sfw==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-064-007.pools.arcor-ip.net [84.57.64.7])
	by smtp.strato.de (jorabe mo33) (RZmta 30.21 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id c00b20o9UHL5Zy ;
	Tue, 30 Oct 2012 19:29:00 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id C1E6818643; Tue, 30 Oct 2012 19:28:59 +0100 (CET)
Date: Tue, 30 Oct 2012 19:28:59 +0100
From: Olaf Hering 
To: Pasi =?utf-8?B?S8Okcmtrw6RpbmVu?= 
Message-ID: <20121030182859.GA8775@aepfle.de>
References: <1351613105-24408-1-git-send-email-olaf@aepfle.de>
	<20121030181732.GZ8912@reaktio.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20121030181732.GZ8912@reaktio.net>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH] xen PVonHVM: require at least Xen 3.4 as
	dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCBPY3QgMzAsIFBhc2kgS8Okcmtrw6RpbmVuIHdyb3RlOgoKPiBPbiBUdWUsIE9jdCAz
MCwgMjAxMiBhdCAwNTowNTowNVBNICswMTAwLCBPbGFmIEhlcmluZyB3cm90ZToKPiA+IFRoZSBY
ZW5QVkhWTSBleHRlbnNpb25zIGhhdmUgbm90IGJlZW4gdGVzdGVkIG11Y2ggb24gdmVyeSBvbGQK
PiA+IGh5cGVydmlzb3JzLiBBdCBsZWFzdCBYZW4gMy40IGdldHMgc29tZSB0ZXN0aW5nIHdpdGgg
dGhlIHB2b3BzIGtlcm5lbC4KPiA+IAo+ID4gUmVxdWlyZSBhdCBsZWFzdCBYZW4gMy40IGZvciB0
aGUgUFZvbkhWTSBleHRlbnNpb25zLiBJZiBhbiBvbGRlcgo+ID4gaHlwZXJ2aXNvciBpcyBkZXRl
Y3RlZCB0aGUgZXh0ZW5zaW9ucyB3aWxsIGJlIGRpc2FibGVkIGFuZCB0aGUgZ3Vlc3QKPiA+IHdp
bGwgb25seSBzZWUgZW11bGF0ZWQgaGFyZHdhcmUuCj4gPiAKPiA+IFNpZ25lZC1vZmYtYnk6IE9s
YWYgSGVyaW5nIDxvbGFmQGFlcGZsZS5kZT4KPiA+Cj4gCj4gSUlSQyB1cHN0cmVhbSBMaW51eCBQ
Vm9uSFZNIGRyaXZlcnMgZG8gd29yayBPSyB0b2RheSBvbiBSSEVMNSBYZW4sIAo+IHdoaWNoIGFk
dmVydGlzZXMgaXRzZWxmIGFzIFhlbiAzLjEuMi1iYXNlZC4uCgpJZiB0aGF0cyB0aGUgY2FzZSwg
YW5kIGEgY29tYmluYXRpb24gdGhhdHMgc3VwcG9zZWQgdG8gd29yaywgdGhlIHBhdGNoCmNhbiBi
ZSBkcm9wcGVkIGlmIHRoZSBodm1sb2FkZXIgZG9lcyByZWFsbHkgbGVhdmUgcm9vbSBhdApGRTcw
MDAwMC1GRTgwMDAwMC4KCk9sYWYKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5v
cmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Oct 30 18:30:26 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 18:30:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTGYo-0005Jo-Cj; Tue, 30 Oct 2012 18:29:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTGYm-0005Jj-Q0
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 18:29:08 +0000
Received: from [85.158.139.211:42661] by server-1.bemta-5.messagelabs.com id
	81/C9-21640-37C10905; Tue, 30 Oct 2012 18:29:07 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-206.messagelabs.com!1351621747!18240627!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MzQxMTQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MzQxMTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19444 invoked from network); 30 Oct 2012 18:29:07 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Oct 2012 18:29:07 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr3c7sfw==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-064-007.pools.arcor-ip.net [84.57.64.7])
	by smtp.strato.de (jorabe mo33) (RZmta 30.21 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id c00b20o9UHL5Zy ;
	Tue, 30 Oct 2012 19:29:00 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id C1E6818643; Tue, 30 Oct 2012 19:28:59 +0100 (CET)
Date: Tue, 30 Oct 2012 19:28:59 +0100
From: Olaf Hering 
To: Pasi =?utf-8?B?S8Okcmtrw6RpbmVu?= 
Message-ID: <20121030182859.GA8775@aepfle.de>
References: <1351613105-24408-1-git-send-email-olaf@aepfle.de>
	<20121030181732.GZ8912@reaktio.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20121030181732.GZ8912@reaktio.net>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH] xen PVonHVM: require at least Xen 3.4 as
	dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCBPY3QgMzAsIFBhc2kgS8Okcmtrw6RpbmVuIHdyb3RlOgoKPiBPbiBUdWUsIE9jdCAz
MCwgMjAxMiBhdCAwNTowNTowNVBNICswMTAwLCBPbGFmIEhlcmluZyB3cm90ZToKPiA+IFRoZSBY
ZW5QVkhWTSBleHRlbnNpb25zIGhhdmUgbm90IGJlZW4gdGVzdGVkIG11Y2ggb24gdmVyeSBvbGQK
PiA+IGh5cGVydmlzb3JzLiBBdCBsZWFzdCBYZW4gMy40IGdldHMgc29tZSB0ZXN0aW5nIHdpdGgg
dGhlIHB2b3BzIGtlcm5lbC4KPiA+IAo+ID4gUmVxdWlyZSBhdCBsZWFzdCBYZW4gMy40IGZvciB0
aGUgUFZvbkhWTSBleHRlbnNpb25zLiBJZiBhbiBvbGRlcgo+ID4gaHlwZXJ2aXNvciBpcyBkZXRl
Y3RlZCB0aGUgZXh0ZW5zaW9ucyB3aWxsIGJlIGRpc2FibGVkIGFuZCB0aGUgZ3Vlc3QKPiA+IHdp
bGwgb25seSBzZWUgZW11bGF0ZWQgaGFyZHdhcmUuCj4gPiAKPiA+IFNpZ25lZC1vZmYtYnk6IE9s
YWYgSGVyaW5nIDxvbGFmQGFlcGZsZS5kZT4KPiA+Cj4gCj4gSUlSQyB1cHN0cmVhbSBMaW51eCBQ
Vm9uSFZNIGRyaXZlcnMgZG8gd29yayBPSyB0b2RheSBvbiBSSEVMNSBYZW4sIAo+IHdoaWNoIGFk
dmVydGlzZXMgaXRzZWxmIGFzIFhlbiAzLjEuMi1iYXNlZC4uCgpJZiB0aGF0cyB0aGUgY2FzZSwg
YW5kIGEgY29tYmluYXRpb24gdGhhdHMgc3VwcG9zZWQgdG8gd29yaywgdGhlIHBhdGNoCmNhbiBi
ZSBkcm9wcGVkIGlmIHRoZSBodm1sb2FkZXIgZG9lcyByZWFsbHkgbGVhdmUgcm9vbSBhdApGRTcw
MDAwMC1GRTgwMDAwMC4KCk9sYWYKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5v
cmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Oct 30 18:34:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 18:34:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTGd8-0005aH-85; Tue, 30 Oct 2012 18:33:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTGd6-0005Zt-LX
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 18:33:37 +0000
Received: from [85.158.143.35:25672] by server-1.bemta-4.messagelabs.com id
	E4/D5-19134-08D10905; Tue, 30 Oct 2012 18:33:36 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1351622015!4629687!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2104 invoked from network); 30 Oct 2012 18:33:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 18:33:35 -0000
X-IronPort-AV: E=Sophos;i="4.80,682,1344211200"; d="scan'208";a="15497723"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 18:33:17 +0000
Received: from [192.168.1.30] (10.31.3.235) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 30 Oct 2012 18:33:16 +0000
Message-ID: <50901D6C.6020500@citrix.com>
Date: Tue, 30 Oct 2012 19:33:16 +0100
From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk 
References: <1351097925-26221-1-git-send-email-roger.pau@citrix.com>
	<20121030170157.GA29485@phenom.dumpdata.com>
In-Reply-To: <20121030170157.GA29485@phenom.dumpdata.com>
Cc: "linux-kernel@vger.kernel.org" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH v2] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 30/10/12 18:01, Konrad Rzeszutek Wilk wrote:
> On Wed, Oct 24, 2012 at 06:58:45PM +0200, Roger Pau Monne wrote:
>> This patch implements persistent grants for the xen-blk{front,back}
>> mechanism. The effect of this change is to reduce the number of unmap
>> operations performed, since they cause a (costly) TLB shootdown. This
>> allows the I/O performance to scale better when a large number of VMs
>> are performing I/O.
>>
>> Previously, the blkfront driver was supplied a bvec[] from the request
>> queue. This was granted to dom0; dom0 performed the I/O and wrote
>> directly into the grant-mapped memory and unmapped it; blkfront then
>> removed foreign access for that grant. The cost of unmapping scales
>> badly with the number of CPUs in Dom0. An experiment showed that when
>> Dom0 has 24 VCPUs, and guests are performing parallel I/O to a
>> ramdisk, the IPIs from performing unmap's is a bottleneck at 5 guests
>> (at which point 650,000 IOPS are being performed in total). If more
>> than 5 guests are used, the performance declines. By 10 guests, only
>> 400,000 IOPS are being performed.
>>
>> This patch improves performance by only unmapping when the connection
>> between blkfront and back is broken.
>>
>> On startup blkfront notifies blkback that it is using persistent
>> grants, and blkback will do the same. If blkback is not capable of
>> persistent mapping, blkfront will still use the same grants, since it
>> is compatible with the previous protocol, and simplifies the code
>> complexity in blkfront.
>>
>> To perform a read, in persistent mode, blkfront uses a separate pool
>> of pages that it maps to dom0. When a request comes in, blkfront
>> transmutes the request so that blkback will write into one of these
>> free pages. Blkback keeps note of which grefs it has already
>> mapped. When a new ring request comes to blkback, it looks to see if
>> it has already mapped that page. If so, it will not map it again. If
>> the page hasn't been previously mapped, it is mapped now, and a record
>> is kept of this mapping. Blkback proceeds as usual. When blkfront is
>> notified that blkback has completed a request, it memcpy's from the
>> shared memory, into the bvec supplied. A record that the {gref, page}
>> tuple is mapped, and not inflight is kept.
>>
>> Writes are similar, except that the memcpy is peformed from the
>> supplied bvecs, into the shared pages, before the request is put onto
>> the ring.
>>
>> Blkback stores a mapping of grefs=>{page mapped to by gref} in
>> a red-black tree. As the grefs are not known apriori, and provide no
>> guarantees on their ordering, we have to perform a search
>> through this tree to find the page, for every gref we receive. This
>> operation takes O(log n) time in the worst case. In blkfront grants
>> are stored using a single linked list.
>>
>> The maximum number of grants that blkback will persistenly map is
>> currently set to RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, to
>> prevent a malicios guest from attempting a DoS, by supplying fresh
>> grefs, causing the Dom0 kernel to map excessively. If a guest
>> is using persistent grants and exceeds the maximum number of grants to
>> map persistenly the newly passed grefs will be mapped and unmaped.
>> Using this approach, we can have requests that mix persistent and
>> non-persistent grants, and we need to handle them correctly.
>> This allows us to set the maximum number of persistent grants to a
>> lower value than RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, although
>> setting it will lead to unpredictable performance.
>>
>> In writing this patch, the question arrises as to if the additional
>> cost of performing memcpys in the guest (to/from the pool of granted
>> pages) outweigh the gains of not performing TLB shootdowns. The answer
>> to that question is `no'. There appears to be very little, if any
>> additional cost to the guest of using persistent grants. There is
>> perhaps a small saving, from the reduced number of hypercalls
>> performed in granting, and ending foreign access.
>>
>> Signed-off-by: Oliver Chick 
>> Signed-off-by: Roger Pau Monne 
>> Cc: 
>> Cc: 
>> ---
>> Changes since v1:
>>  * Changed the unmap_seg array to a bitmap.
>>  * Only report using persistent grants in blkfront if blkback supports
>>    it.
>>  * Reword some comments.
>>  * Fix a bug when setting the handler, index j was not incremented
>>    correctly.
>>  * Check that the tree of grants in blkback is not empty before
>>    iterating over it when doing the cleanup.
>>  * Rebase on top of linux-net.
> 
> I fixed the 'new_map = [1|0]' you had in and altered it to use 'true'
> or 'false', but when running some tests (with a 64-bit PV guest) I got it
> to bug.

Thanks for the testing. I'm going to rebase on top of your linux-next
branch and see if I can reproduce it. Did you run any kind of specific
test/benchmark? I've been running with this patch for a long time (on
top of your previous linux-next branch), and I haven't been able to get
it to bug.

> [    0.000000] Initializing cgroup subsys cpuset
> [    0.000000] Initializing cgroup subsys cpu
> [    0.000000] Linux version 3.7.0-rc3upstream-00220-g37b7153 (konrad@build.dumpdata.com) (gcc version 4.4.4 20100503 (Red Hat 4.4.4-2) (GCC) ) #1 SMP Tue Oct 30 12:15:12 EDT 2012
> [    0.000000] Command line: earlyprintk=xen debug nofb console=tty console=ttyS1,115200n8 xen-pciback.hide=(00:02:00) loglevel=10
> [    0.000000] Freeing 9d-100 pfn range: 99 pages freed
> [    0.000000] 1-1 mapping on 9d->100
> [    0.000000] 1-1 mapping on cf7fb->cfb63
> [    0.000000] 1-1 mapping on cfd15->cfd70
> [    0.000000] 1-1 mapping on cfd71->cfef7
> [    0.000000] 1-1 mapping on cff00->100001
> [    0.000000] Released 99 pages of unused memory
> [    0.000000] Set 198317 page(s) to 1-1 mapping
> [    0.000000] Populating 3e700-3e763 pfn range: 99 pages added
> [    0.000000] e820: BIOS-provided physical RAM map:
> [    0.000000] Xen: [mem 0x0000000000000000-0x000000000009cfff] usable
> [    0.000000] Xen: [mem 0x000000000009d800-0x00000000000fffff] reserved
> [    0.000000] Xen: [mem 0x0000000000100000-0x000000004d062fff] usable
> [    0.000000] Xen: [mem 0x000000004d063000-0x00000000cf7fafff] unusable
> [    0.000000] Xen: [mem 0x00000000cf7fb000-0x00000000cf95ffff] reserved
> [    0.000000] Xen: [mem 0x00000000cf960000-0x00000000cfb62fff] ACPI NVS
> [    0.000000] Xen: [mem 0x00000000cfb63000-0x00000000cfd14fff] unusable
> [    0.000000] Xen: [mem 0x00000000cfd15000-0x00000000cfd61fff] ACPI NVS
> [    0.000000] Xen: [mem 0x00000000cfd62000-0x00000000cfd6cfff] ACPI data
> [    0.000000] Xen: [mem 0x00000000cfd6d000-0x00000000cfd6ffff] ACPI NVS
> [    0.000000] Xen: [mem 0x00000000cfd70000-0x00000000cfd70fff] unusable
> [    0.000000] Xen: [mem 0x00000000cfd71000-0x00000000cfea8fff] reserved
> [    0.000000] Xen: [mem 0x00000000cfea9000-0x00000000cfeb9fff] ACPI NVS
> [    0.000000] Xen: [mem 0x00000000cfeba000-0x00000000cfecafff] reserved
> [    0.000000] Xen: [mem 0x00000000cfecb000-0x00000000cfecbfff] ACPI NVS
> [    0.000000] Xen: [mem 0x00000000cfecc000-0x00000000cfedbfff] reserved
> [    0.000000] Xen: [mem 0x00000000cfedc000-0x00000000cfedcfff] ACPI NVS
> [    0.000000] Xen: [mem 0x00000000cfedd000-0x00000000cfeddfff] reserved
> [    0.000000] Xen: [mem 0x00000000cfede000-0x00000000cfee3fff] ACPI NVS
> [    0.000000] Xen: [mem 0x00000000cfee4000-0x00000000cfef6fff] reserved
> [    0.000000] Xen: [mem 0x00000000cfef7000-0x00000000cfefffff] unusable
> [    0.000000] Xen: [mem 0x00000000e0000000-0x00000000efffffff] reserved
> [    0.000000] Xen: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
> [    0.000000] Xen: [mem 0x00000000fec10000-0x00000000fec10fff] reserved
> [    0.000000] Xen: [mem 0x00000000fed00000-0x00000000fed00fff] reserved
> [    0.000000] Xen: [mem 0x00000000fed40000-0x00000000fed44fff] reserved
> [    0.000000] Xen: [mem 0x00000000fed61000-0x00000000fed70fff] reserved
> [    0.000000] Xen: [mem 0x00000000fed80000-0x00000000fed8ffff] reserved
> [    0.000000] Xen: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
> [    0.000000] Xen: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
> [    0.000000] Xen: [mem 0x0000000100001000-0x000000020effffff] unusable
> [    0.000000] bootconsole [xenboot0] enabled
> [    0.000000] NX (Execute Disable) protection: active
> [    0.000000] DMI 2.6 present.
> [    0.000000] DMI: System manufacturer System Product Name/F1A75-M, BIOS 0406 06/11/2011
> [    0.000000] e820: update [mem 0x00000000-0x0000ffff] usable ==> reserved
> [    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
> [    0.000000] No AGP bridge found
> [    0.000000] e820: last_pfn = 0x4d063 max_arch_pfn = 0x400000000
> [    0.000000] initial memory mapped: [mem 0x00000000-0x16bcdfff]
> [    0.000000] Base memory trampoline at [ffff880000097000] 97000 size 24576
> [    0.000000] init_memory_mapping: [mem 0x00000000-0x4d062fff]
> [    0.000000]  [mem 0x00000000-0x4d062fff] page 4k
> [    0.000000] kernel direct mapping tables up to 0x4d062fff @ [mem 0x01e21000-0x0208cfff]
> [    0.000000] xen: setting RW the range 1fd3000 - 208d000
> [    0.000000] RAMDISK: [mem 0x0208d000-0x16bcdfff]
> [    0.000000] ACPI: RSDP 00000000000f0450 00024 (v02 ALASKA)
> [    0.000000] ACPI: XSDT 00000000cfd62068 00054 (v01 ALASKA    A M I 01072009 AMI  00010013)
> [    0.000000] ACPI: FACP 00000000cfd69a68 000F4 (v04 ALASKA    A M I 01072009 AMI  00010013)
> [    0.000000] ACPI BIOS Bug: Warning: Optional FADT field Pm2ControlBlock has zero address or length: 0x0000000000000000/0x1 (20120913/tbfadt-598)
> [    0.000000] ACPI: DSDT 00000000cfd62150 07917 (v02 ALASKA    A M I 00000000 INTL 20051117)
> [    0.000000] ACPI: FACS 00000000cfedef80 00040
> [    0.000000] ACPI: APIC 00000000cfd69b60 00072 (v03 ALASKA    A M I 01072009 AMI  00010013)
> [    0.000000] ACPI: MCFG 00000000cfd69bd8 0003C (v01 A M I  GMCH945. 01072009 MSFT 00000097)
> [    0.000000] ACPI: HPET 00000000cfd69c18 00038 (v01 ALASKA    A M I 01072009 AMI  00000004)
> [    0.000000] ACPI: SSDT 00000000cfd69c50 00FD8 (v01 AMD    POWERNOW 00000001 AMD  00000001)
> [    0.000000] ACPI: SSDT 00000000cfd6ac28 01923 (v02    AMD     ALIB 00000001 MSFT 04000000)
> [    0.000000] ACPI: Local APIC address 0xfee00000
> [    0.000000] NUMA turned off
> [    0.000000] Faking a node at [mem 0x0000000000000000-0x000000004d062fff]
> [    0.000000] Initmem setup node 0 [mem 0x00000000-0x4d062fff]
> [    0.000000]   NODE_DATA [mem 0x3e75f000-0x3e762fff]
> [    0.000000] Zone ranges:
> [    0.000000]   DMA      [mem 0x00010000-0x00ffffff]
> [    0.000000]   DMA32    [mem 0x01000000-0xffffffff]
> [    0.000000]   Normal   empty
> [    0.000000] Movable zone start for each node
> [    0.000000] Early memory node ranges
> [    0.000000]   node   0: [mem 0x00010000-0x0009cfff]
> [    0.000000]   node   0: [mem 0x00100000-0x4d062fff]
> [    0.000000] On node 0 totalpages: 315376
> [    0.000000]   DMA zone: 56 pages used for memmap
> [    0.000000]   DMA zone: 6 pages reserved
> [    0.000000]   DMA zone: 3919 pages, LIFO batch:0
> [    0.000000]   DMA32 zone: 4258 pages used for memmap
> [    0.000000]   DMA32 zone: 307137 pages, LIFO batch:31
> [    0.000000] ACPI: PM-Timer IO Port: 0x808
> [    0.000000] ACPI: Local APIC address 0xfee00000
> [    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)
> [    0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])
> [    0.000000] ACPI: IOAPIC (id[0x05] address[0xfec00000] gsi_base[0])
> [    0.000000] IOAPIC[0]: apic_id 5, version 33, address 0xfec00000, GSI 0-23
> [    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
> [    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
> [    0.000000] ACPI: IRQ0 used by override.
> [    0.000000] ACPI: IRQ2 used by override.
> [    0.000000] ACPI: IRQ9 used by override.
> [    0.000000] Using ACPI (MADT) for SMP configuration information
> [    0.000000] ACPI: HPET id: 0xffffffff base: 0xfed00000
> [    0.000000] smpboot: Allowing 4 CPUs, 0 hotplug CPUs
> [    0.000000] nr_irqs_gsi: 40
> [    0.000000] PM: Registered nosave memory: 000000000009d000 - 000000000009e000
> [    0.000000] PM: Registered nosave memory: 000000000009e000 - 0000000000100000
> [    0.000000] e820: [mem 0xcff00000-0xdfffffff] available for PCI devices
> [    0.000000] Booting paravirtualized kernel on Xen
> [    0.000000] Xen version: 4.1.4-pre (preserve-AD)
> [    0.000000] setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:4 nr_node_ids:1
> [    0.000000] PERCPU: Embedded 28 pages/cpu @ffff88003e000000 s84288 r8192 d22208 u524288
> [    0.000000] pcpu-alloc: s84288 r8192 d22208 u524288 alloc=1*2097152
> [    0.000000] pcpu-alloc: [0] 0 1 2 3
> [    2.763208] Built 1 zonelists in Node order, mobility grouping on.  Total pages: 311056
> [    2.763213] Policy zone: DMA32
> [    2.763218] Kernel command line: earlyprintk=xen debug nofb console=tty console=ttyS1,115200n8 xen-pciback.hide=(00:02:00) loglevel=10
> [    2.763656] PID hash table entries: 4096 (order: 3, 32768 bytes)
> [    2.763663] __ex_table already sorted, skipping sort
> [    2.808064] software IO TLB [mem 0x38a00000-0x3ca00000] (64MB) mapped at [ffff880038a00000-ffff88003c9fffff]
> [    2.811300] Memory: 581728k/1261964k available (6413k kernel code, 460k absent, 679776k reserved, 4478k data, 752k init)
> [    2.811414] Hierarchical RCU implementation.
> [    2.811419]  RCU restricting CPUs from NR_CPUS=512 to nr_cpu_ids=3.
> [    2.811432] NR_IRQS:33024 nr_irqs:704 16
> [    2.811514] xen: sci override: global_irq=9 trigger=0 polarity=1
> [    2.811518] xen: registering gsi 9 triggering 0 polarity 1
> [    2.811531] xen: --> pirq=9 -> irq=9 (gsi=9)
> [    2.811539] xen: acpi sci 9
> [    2.811546] xen: --> pirq=1 -> irq=1 (gsi=1)
> [    2.811551] xen: --> pirq=2 -> irq=2 (gsi=2)
> [    2.811557] xen: --> pirq=3 -> irq=3 (gsi=3)
> [    2.811562] xen: --> pirq=4 -> irq=4 (gsi=4)
> [    2.811568] xen: --> pirq=5 -> irq=5 (gsi=5)
> [    2.811574] xen: --> pirq=6 -> irq=6 (gsi=6)
> [    2.811579] xen: --> pirq=7 -> irq=7 (gsi=7)
> [    2.811585] xen: --> pirq=8 -> irq=8 (gsi=8)
> [    2.811590] xen: --> pirq=10 -> irq=10 (gsi=10)
> [    2.811596] xen: --> pirq=11 -> irq=11 (gsi=11)
> [    2.811602] xen: --> pirq=12 -> irq=12 (gsi=12)
> [    2.811607] xen: --> pirq=13 -> irq=13 (gsi=13)
> [    2.811613] xen: --> pirq=14 -> irq=14 (gsi=14)
> [    2.811618] xen: --> pirq=15 -> irq=15 (gsi=15)
> [    2.813454] Console: colour VGA+ 80x25
> [    2.818363] console [tty0] enabled
> [    2.818422] console [ttyS1] enabled, bootconsole disabled
> [    2.818757] Xen: using vcpuop timer interface
> [    2.819017] installing Xen timer for CPU 0
> [    2.819285] tsc: Detected 2899.980 MHz processor
> [    2.819555] Calibrating delay loop (skipped), value calculated using timer frequency.. 5799.96 BogoMIPS (lpj=2899980)
> [    2.820151] pid_max: default: 32768 minimum: 301
> [    2.820479] Security Framework initialized
> [    2.820728] SELinux:  Initializing.
> [    2.820948] SELinux:  Starting in permissive mode
> [    2.821532] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
> [    2.822565] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
> [    2.823519] Mount-cache hash table entries: 256
> [    2.824126] Initializing cgroup subsys cpuacct
> [    2.824400] Initializing cgroup subsys freezer
> [    2.824730] tseg: 00cff00000
> [    2.824934] CPU: Physical Processor ID: 0
> [    2.825186] CPU: Processor Core ID: 0
> [    2.825417] mce: CPU supports 6 MCE banks
> [    2.825696] Last level iTLB entries: 4KB 512, 2MB 16, 4MB 8
> [    2.825696] Last level dTLB entries: 4KB 1024, 2MB 128, 4MB 64
> [    2.825696] tlb_flushall_shift: 5
> [    2.826625] Freeing SMP alternatives: 24k freed
> [    2.829704] ACPI: Core revision 20120913
> [    2.856787] cpu 0 spinlock event irq 41
> [    2.857062] Performance Events: Broken PMU hardware detected, using software events only.
> [    2.857602] Failed to access perfctr msr (MSR c0010004 is 0)
> [    2.858234] MCE: In-kernel MCE decoding enabled.
> [    2.858603] NMI watchdog: disabled (cpu0): hardware events not enabled
> [    2.859223] installing Xen timer for CPU 1
> [    2.859499] cpu 1 spinlock event irq 48
> [    2.860218] installing Xen timer for CPU 2
> [    2.860493] cpu 2 spinlock event irq 55
> [    2.860951] Brought up 3 CPUs
> [    2.864412] PM: Registering ACPI NVS region [mem 0xcf960000-0xcfb62fff] (2109440 bytes)
> [    2.865989] PM: Registering ACPI NVS region [mem 0xcfd15000-0xcfd61fff] (315392 bytes)
> [    2.866464] PM: Registering ACPI NVS region [mem 0xcfd6d000-0xcfd6ffff] (12288 bytes)
> [    2.866931] PM: Registering ACPI NVS region [mem 0xcfea9000-0xcfeb9fff] (69632 bytes)
> [    2.867404] PM: Registering ACPI NVS region [mem 0xcfecb000-0xcfecbfff] (4096 bytes)
> [    2.867861] PM: Registering ACPI NVS region [mem 0xcfedc000-0xcfedcfff] (4096 bytes)
> [    2.868321] PM: Registering ACPI NVS region [mem 0xcfede000-0xcfee3fff] (24576 bytes)
> [    2.869081] kworker/u:0 (26) used greatest stack depth: 6120 bytes left
> [    2.869105] Grant tables using version 2 layout.
> [    2.869122] Grant table initialized
> [    2.869164] RTC time: 16:43:55, date: 10/30/12
> [    2.870366] NET: Registered protocol family 16
> [    2.871181] kworker/u:0 (30) used greatest stack depth: 5504 bytes left
> [    2.872440] ACPI: bus type pci registered
> [    2.873480] dca service started, version 1.12.1
> [    2.873891] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000)
> [    2.874438] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in E820
> [    2.914335] PCI: Using configuration type 1 for base access
> [    2.932999] bio: create slab  at 0
> [    2.933584] ACPI: Added _OSI(Module Device)
> [    2.933866] ACPI: Added _OSI(Processor Device)
> [    2.934145] ACPI: Added _OSI(3.0 _SCP Extensions)
> [    2.934432] ACPI: Added _OSI(Processor Aggregator Device)
> [    2.942011] ACPI: EC: Look up EC in DSDT
> [    2.950054] ACPI: Executed 1 blocks of module-level executable AML code
> [    2.956530] ACPI: Interpreter enabled
> [    2.956772] ACPI: (supports S0 S3 S4 S5)
> [    2.957218] ACPI: Using IOAPIC for interrupt routing
> [    2.982389] ACPI: No dock devices found.
> [    2.982650] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
> [    2.983552] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
> [    2.984298] PCI host bridge to bus 0000:00
> [    2.984571] pci_bus 0000:00: root bus resource [bus 00-ff]
> [    2.984906] pci_bus 0000:00: root bus resource [io  0x0000-0x03af]
> [    2.985277] pci_bus 0000:00: root bus resource [io  0x03e0-0x0cf7]
> [    2.985657] pci_bus 0000:00: root bus resource [io  0x03b0-0x03df]
> [    2.986029] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
> [    2.986399] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
> [    2.986810] pci_bus 0000:00: root bus resource [mem 0x000c0000-0x000dffff]
> [    2.987214] pci_bus 0000:00: root bus resource [mem 0xd0000000-0xffffffff]
> [    2.987631] pci 0000:00:00.0: [1022:1705] type 00 class 0x060000
> [    2.988106] pci 0000:00:01.0: [1002:9640] type 00 class 0x030000
> [    2.988487] pci 0000:00:01.0: reg 10: [mem 0xd0000000-0xdfffffff pref]
> [    2.988893] pci 0000:00:01.0: reg 14: [io  0xf000-0xf0ff]
> [    2.989246] pci 0000:00:01.0: reg 18: [mem 0xfeb00000-0xfeb3ffff]
> [    2.989743] pci 0000:00:01.0: supports D1 D2
> [    2.990053] pci 0000:00:01.1: [1002:1714] type 00 class 0x040300
> [    2.990442] pci 0000:00:01.1: reg 10: [mem 0xfeb44000-0xfeb47fff]
> [    2.990965] pci 0000:00:01.1: supports D1 D2
> [    2.991343] pci 0000:00:10.0: [1022:7812] type 00 class 0x0c0330
> [    2.991752] pci 0000:00:10.0: reg 10: [mem 0xfeb4a000-0xfeb4bfff 64bit]
> [    2.992355] pci 0000:00:10.0: PME# supported from D0 D3hot D3cold
> [    2.992803] pci 0000:00:10.1: [1022:7812] type 00 class 0x0c0330
> [    2.993201] pci 0000:00:10.1: reg 10: [mem 0xfeb48000-0xfeb49fff 64bit]
> [    2.993793] pci 0000:00:10.1: PME# supported from D0 D3hot D3cold
> [    2.994239] pci 0000:00:11.0: [1022:7801] type 00 class 0x010601
> [    2.994637] pci 0000:00:11.0: reg 10: [io  0xf140-0xf147]
> [    2.994982] pci 0000:00:11.0: reg 14: [io  0xf130-0xf133]
> [    2.995333] pci 0000:00:11.0: reg 18: [io  0xf120-0xf127]
> [    2.995678] pci 0000:00:11.0: reg 1c: [io  0xf110-0xf113]
> [    2.996024] pci 0000:00:11.0: reg 20: [io  0xf100-0xf10f]
> [    2.996374] pci 0000:00:11.0: reg 24: [mem 0xfeb51000-0xfeb517ff]
> [    2.996850] pci 0000:00:12.0: [1022:7807] type 00 class 0x0c0310
> [    2.997235] pci 0000:00:12.0: reg 10: [mem 0xfeb50000-0xfeb50fff]
> [    2.997765] pci 0000:00:12.2: [1022:7808] type 00 class 0x0c0320
> [    2.998161] pci 0000:00:12.2: reg 10: [mem 0xfeb4f000-0xfeb4f0ff]
> [    2.998712] pci 0000:00:12.2: supports D1 D2
> [    2.998977] pci 0000:00:12.2: PME# supported from D0 D1 D2 D3hot
> [    2.999375] pci 0000:00:13.0: [1022:7807] type 00 class 0x0c0310
> [    2.999768] pci 0000:00:13.0: reg 10: [mem 0xfeb4e000-0xfeb4efff]
> [    3.000283] pci 0000:00:13.2: [1022:7808] type 00 class 0x0c0320
> [    3.000681] pci 0000:00:13.2: reg 10: [mem 0xfeb4d000-0xfeb4d0ff]
> [    3.001227] pci 0000:00:13.2: supports D1 D2
> [    3.001495] pci 0000:00:13.2: PME# supported from D0 D1 D2 D3hot
> [    3.001902] pci 0000:00:14.0: [1022:780b] type 00 class 0x0c0500
> [    3.002433] pci 0000:00:14.2: [1022:780d] type 00 class 0x040300
> [    3.002840] pci 0000:00:14.2: reg 10: [mem 0xfeb40000-0xfeb43fff 64bit]
> [    3.003376] pci 0000:00:14.2: PME# supported from D0 D3hot D3cold
> [    3.003761] pci 0000:00:14.3: [1022:780e] type 00 class 0x060100
> [    3.004279] pci 0000:00:14.4: [1022:780f] type 01 class 0x060401
> [    3.004730] pci 0000:00:14.5: [1022:7809] type 00 class 0x0c0310
> [    3.005119] pci 0000:00:14.5: reg 10: [mem 0xfeb4c000-0xfeb4cfff]
> [    3.005641] pci 0000:00:15.0: [1022:43a0] type 01 class 0x060400
> [    3.006187] pci 0000:00:15.0: supports D1 D2
> [    3.006515] pci 0000:00:15.1: [1022:43a1] type 01 class 0x060400
> [    3.007059] pci 0000:00:15.1: supports D1 D2
> [    3.007403] pci 0000:00:18.0: [1022:1700] type 00 class 0x060000
> [    3.007868] pci 0000:00:18.1: [1022:1701] type 00 class 0x060000
> [    3.008320] pci 0000:00:18.2: [1022:1702] type 00 class 0x060000
> [    3.008778] pci 0000:00:18.3: [1022:1703] type 00 class 0x060000
> [    3.009271] pci 0000:00:18.4: [1022:1704] type 00 class 0x060000
> [    3.009716] pci 0000:00:18.5: [1022:1718] type 00 class 0x060000
> [    3.010167] pci 0000:00:18.6: [1022:1716] type 00 class 0x060000
> [    3.010615] pci 0000:00:18.7: [1022:1719] type 00 class 0x060000
> [    3.011117] pci 0000:01:05.0: [9710:9835] type 00 class 0x070002
> [    3.011513] pci 0000:01:05.0: reg 10: [io  0xe050-0xe057]
> [    3.011861] pci 0000:01:05.0: reg 14: [io  0xe040-0xe047]
> [    3.012210] pci 0000:01:05.0: reg 18: [io  0xe030-0xe037]
> [    3.012563] pci 0000:01:05.0: reg 1c: [io  0xe020-0xe027]
> [    3.012912] pci 0000:01:05.0: reg 20: [io  0xe010-0xe017]
> [    3.013259] pci 0000:01:05.0: reg 24: [io  0xe000-0xe00f]
> [    3.013710] pci 0000:00:14.4: PCI bridge to [bus 01] (subtractive decode)
> [    3.014118] pci 0000:00:14.4:   bridge window [io  0xe000-0xefff]
> [    3.014496] pci 0000:00:14.4:   bridge window [io  0x0000-0x03af] (subtractive decode)
> [    3.014967] pci 0000:00:14.4:   bridge window [io  0x03e0-0x0cf7] (subtractive decode)
> [    3.015422] pci 0000:00:14.4:   bridge window [io  0x03b0-0x03df] (subtractive decode)
> [    3.015878] pci 0000:00:14.4:   bridge window [io  0x0d00-0xffff] (subtractive decode)
> [    3.016343] pci 0000:00:14.4:   bridge window [mem 0x000a0000-0x000bffff] (subtractive decode)
> [    3.016836] pci 0000:00:14.4:   bridge window [mem 0x000c0000-0x000dffff] (subtractive decode)
> [    3.017326] pci 0000:00:14.4:   bridge window [mem 0xd0000000-0xffffffff] (subtractive decode)
> [    3.017990] pci 0000:02:00.0: [8086:10d3] type 00 class 0x020000
> [    3.018379] pci 0000:02:00.0: reg 10: [mem 0xfeac0000-0xfeadffff]
> [    3.018769] pci 0000:02:00.0: reg 14: [mem 0xfea00000-0xfea7ffff]
> [    3.019167] pci 0000:02:00.0: reg 18: [io  0xd000-0xd01f]
> [    3.019522] pci 0000:02:00.0: reg 1c: [mem 0xfeae0000-0xfeae3fff]
> [    3.019964] pci 0000:02:00.0: reg 30: [mem 0xfea80000-0xfeabffff pref]
> [    3.020508] pci 0000:02:00.0: PME# supported from D0 D3hot D3cold
> [    3.023962] pci 0000:00:15.0: PCI bridge to [bus 02]
> [    3.024307] pci 0000:00:15.0:   bridge window [io  0xd000-0xdfff]
> [    3.024689] pci 0000:00:15.0:   bridge window [mem 0xfea00000-0xfeafffff]
> [    3.025293] pci 0000:03:00.0: [1969:1083] type 00 class 0x020000
> [    3.025712] pci 0000:03:00.0: reg 10: [mem 0xfe900000-0xfe93ffff 64bit]
> [    3.026139] pci 0000:03:00.0: reg 18: [io  0xc000-0xc07f]
> [    3.026691] pci 0000:03:00.0: PME# supported from D0 D1 D2 D3hot D3cold
> [    3.028949] pci 0000:00:15.1: PCI bridge to [bus 03]
> [    3.029290] pci 0000:00:15.1:   bridge window [io  0xc000-0xcfff]
> [    3.029671] pci 0000:00:15.1:   bridge window [mem 0xfe900000-0xfe9fffff]
> [    3.030148] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
> [    3.030844] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PE20._PRT]
> [    3.031280] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PE21._PRT]
> [    3.031782] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0PC._PRT]
> [    3.032377]  pci0000:00: Requesting ACPI _OSC control (0x1d)
> [    3.032947]  pci0000:00: ACPI _OSC control (0x1d) granted
> [    3.051344] ACPI: PCI Interrupt Link [LN24] (IRQs *24)
> [    3.051852] ACPI: PCI Interrupt Link [LN25] (IRQs *25)
> [    3.052329] ACPI: PCI Interrupt Link [LN26] (IRQs *26)
> [    3.052821] ACPI: PCI Interrupt Link [LN27] (IRQs *27)
> [    3.053298] ACPI: PCI Interrupt Link [LN28] (IRQs *28)
> [    3.053787] ACPI: PCI Interrupt Link [LN29] (IRQs *29)
> [    3.054271] ACPI: PCI Interrupt Link [LN30] (IRQs *30)
> [    3.054747] ACPI: PCI Interrupt Link [LN31] (IRQs *31)
> [    3.055243] ACPI: PCI Interrupt Link [LN32] (IRQs *32)
> [    3.055724] ACPI: PCI Interrupt Link [LN33] (IRQs *33)
> [    3.056211] ACPI: PCI Interrupt Link [LN34] (IRQs *34)
> [    3.056692] ACPI: PCI Interrupt Link [LN35] (IRQs *35)
> [    3.057187] ACPI: PCI Interrupt Link [LN36] (IRQs *36)
> [    3.057673] ACPI: PCI Interrupt Link [LN37] (IRQs *37)
> [    3.058165] ACPI: PCI Interrupt Link [LN38] (IRQs *38)
> [    3.058660] ACPI: PCI Interrupt Link [LN39] (IRQs *39)
> [    3.059154] ACPI: PCI Interrupt Link [LN40] (IRQs *40)
> [    3.059643] ACPI: PCI Interrupt Link [LN41] (IRQs *41)
> [    3.060128] ACPI: PCI Interrupt Link [LN42] (IRQs *42)
> [    3.060618] ACPI: PCI Interrupt Link [LN43] (IRQs *43)
> [    3.061095] ACPI: PCI Interrupt Link [LN44] (IRQs *44)
> [    3.061575] ACPI: PCI Interrupt Link [LN45] (IRQs *45)
> [    3.062059] ACPI: PCI Interrupt Link [LN46] (IRQs *46)
> [    3.062543] ACPI: PCI Interrupt Link [LN47] (IRQs *47)
> [    3.063029] ACPI: PCI Interrupt Link [LN48] (IRQs *48)
> [    3.063506] ACPI: PCI Interrupt Link [LN49] (IRQs *49)
> [    3.063989] ACPI: PCI Interrupt Link [LN50] (IRQs *50)
> [    3.064473] ACPI: PCI Interrupt Link [LN51] (IRQs *51)
> [    3.064950] ACPI: PCI Interrupt Link [LN52] (IRQs *52)
> [    3.065440] ACPI: PCI Interrupt Link [LN53] (IRQs *53)
> [    3.065918] ACPI: PCI Interrupt Link [LN54] (IRQs *54)
> [    3.066402] ACPI: PCI Interrupt Link [LN55] (IRQs *55)
> [    3.066889] ACPI: PCI Interrupt Link [LNKA] (IRQs 4 5 7 10 11 14 15) *0
> [    3.068826] ACPI: PCI Interrupt Link [LNKB] (IRQs 4 5 7 10 11 14 15) *0
> [    3.069717] ACPI: PCI Interrupt Link [LNKC] (IRQs 4 5 7 10 11 14 15) *0
> [    3.070606] ACPI: PCI Interrupt Link [LNKD] (IRQs 4 5 7 10 11 14 15) *0
> [    3.071479] ACPI: PCI Interrupt Link [LNKE] (IRQs 4 5 7 10 11 14 15) *0
> [    3.072339] ACPI: PCI Interrupt Link [LNKF] (IRQs 4 5 7 10 11 14 15) *0
> [    3.073195] ACPI: PCI Interrupt Link [LNKG] (IRQs 4 5 7 10 11 14 15) *0
> [    3.074064] ACPI: PCI Interrupt Link [LNKH] (IRQs 4 5 7 10 11 14 15) *0
> [    3.075123] xen/balloon: Initialising balloon driver.
> [    3.076280] xen-balloon: Initialising balloon driver.
> [    3.076885] xen/balloon: Xen selfballooning driver disabled for domain0.
> [    3.077545] vgaarb: device added: PCI:0000:00:01.0,decodes=io+mem,owns=io+mem,locks=none
> [    3.078080] vgaarb: loaded
> [    3.078268] vgaarb: bridge control possible 0000:00:01.0
> [    3.078970] ACPI: bus type usb registered
> [    3.079409] usbcore: registered new interface driver usbfs
> [    3.079813] usbcore: registered new interface driver hub
> [    3.080257] usbcore: registered new device driver usb
> [    3.081098] PCI: Using ACPI for IRQ routing
> [    3.098106] PCI: pci_cache_line_size set to 64 bytes
> [    3.098606] e820: reserve RAM buffer [mem 0x0009d000-0x0009ffff]
> [    3.098972] e820: reserve RAM buffer [mem 0x4d063000-0x4fffffff]
> [    3.099810] NetLabel: Initializing
> [    3.100040] NetLabel:  domain hash size = 128
> [    3.100313] NetLabel:  protocols = UNLABELED CIPSOv4
> [    3.100639] NetLabel:  unlabeled traffic allowed by default
> [    3.101361] Switching to clocksource xen
> [    3.109135] pnp: PnP ACPI init
> [    3.109362] ACPI: bus type pnp registered
> [    3.109832] pnp 00:00: [bus 00-ff]
> [    3.110058] pnp 00:00: [io  0x0cf8-0x0cff]
> [    3.110319] pnp 00:00: [io  0x0000-0x03af window]
> [    3.110611] pnp 00:00: [io  0x03e0-0x0cf7 window]
> [    3.110912] pnp 00:00: [io  0x03b0-0x03df window]
> [    3.111200] pnp 00:00: [io  0x0d00-0xffff window]
> [    3.111492] pnp 00:00: [mem 0x000a0000-0x000bffff window]
> [    3.111826] pnp 00:00: [mem 0x000c0000-0x000dffff window]
> [    3.112154] pnp 00:00: [mem 0xd0000000-0xffffffff window]
> [    3.112482] pnp 00:00: [mem 0x00000000 window]
> [    3.113097] pnp 00:00: Plug and Play ACPI device, IDs PNP0a03 (active)
> [    3.113537] pnp 00:01: [mem 0xe0000000-0xefffffff]
> [    3.114213] system 00:01: [mem 0xe0000000-0xefffffff] has been reserved
> [    3.114626] system 00:01: Plug and Play ACPI device, IDs PNP0c01 (active)
> [    3.116690] pnp 00:02: [io  0x0010-0x001f]
> [    3.116955] pnp 00:02: [io  0x0022-0x003f]
> [    3.117210] pnp 00:02: [io  0x0063]
> [    3.117439] pnp 00:02: [io  0x0065]
> [    3.117667] pnp 00:02: [io  0x0067-0x006f]
> [    3.117932] pnp 00:02: [io  0x0072-0x007f]
> [    3.118191] pnp 00:02: [io  0x0080]
> [    3.118415] pnp 00:02: [io  0x0084-0x0086]
> [    3.118668] pnp 00:02: [io  0x0088]
> [    3.118910] pnp 00:02: [io  0x008c-0x008e]
> [    3.119174] pnp 00:02: [io  0x0090-0x009f]
> [    3.119436] pnp 00:02: [io  0x00a2-0x00bf]
> [    3.119706] pnp 00:02: [io  0x00b1]
> [    3.119936] pnp 00:02: [io  0x00e0-0x00ef]
> [    3.120194] pnp 00:02: [io  0x04d0-0x04d1]
> [    3.120455] pnp 00:02: [io  0x040b]
> [    3.120683] pnp 00:02: [io  0x04d6]
> [    3.120916] pnp 00:02: [io  0x0c00-0x0c01]
> [    3.121172] pnp 00:02: [io  0x0c14]
> [    3.121397] pnp 00:02: [io  0x0c50-0x0c51]
> [    3.121653] pnp 00:02: [io  0x0c52]
> [    3.121885] pnp 00:02: [io  0x0c6c]
> [    3.122109] pnp 00:02: [io  0x0c6f]
> [    3.122335] pnp 00:02: [io  0x0cd0-0x0cd1]
> [    3.122591] pnp 00:02: [io  0x0cd2-0x0cd3]
> [    3.122860] pnp 00:02: [io  0x0cd4-0x0cd5]
> [    3.123120] pnp 00:02: [io  0x0cd6-0x0cd7]
> [    3.123377] pnp 00:02: [io  0x0cd8-0x0cdf]
> [    3.123633] pnp 00:02: [io  0x0800-0x089f]
> [    3.123898] pnp 00:02: [io  0x0000-0xffffffffffffffff disabled]
> [    3.124249] pnp 00:02: [io  0x0000-0x000f]
> [    3.124506] pnp 00:02: [io  0x0b20-0x0b3f]
> [    3.124768] pnp 00:02: [io  0x0900-0x090f]
> [    3.125026] pnp 00:02: [io  0x0910-0x091f]
> [    3.125282] pnp 00:02: [io  0xfe00-0xfefe]
> [    3.125537] pnp 00:02: [io  0x0060-0x005f disabled]
> [    3.125841] pnp 00:02: [io  0x0064-0x0063 disabled]
> [    3.126136] pnp 00:02: [mem 0xfec00000-0xfec00fff]
> [    3.126426] pnp 00:02: [mem 0xfee00000-0xfee00fff]
> [    3.126724] pnp 00:02: [mem 0xfed80000-0xfed8ffff]
> [    3.127024] pnp 00:02: [mem 0xfed61000-0xfed70fff]
> [    3.127321] pnp 00:02: [mem 0xfec10000-0xfec10fff]
> [    3.127619] pnp 00:02: [mem 0xfed00000-0xfed00fff]
> [    3.127920] pnp 00:02: [mem 0xff000000-0xffffffff]
> [    3.128629] system 00:02: [io  0x04d0-0x04d1] has been reserved
> [    3.129033] system 00:02: [io  0x040b] has been reserved
> [    3.129358] system 00:02: [io  0x04d6] has been reserved
> [    3.129680] system 00:02: [io  0x0c00-0x0c01] has been reserved
> [    3.130042] system 00:02: [io  0x0c14] has been reserved
> [    3.130365] system 00:02: [io  0x0c50-0x0c51] has been reserved
> [    3.130727] system 00:02: [io  0x0c52] has been reserved
> [    3.131046] system 00:02: [io  0x0c6c] has been reserved
> [    3.131369] system 00:02: [io  0x0c6f] has been reserved
> [    3.131692] system 00:02: [io  0x0cd0-0x0cd1] has been reserved
> [    3.132047] system 00:02: [io  0x0cd2-0x0cd3] has been reserved
> [    3.132401] system 00:02: [io  0x0cd4-0x0cd5] has been reserved
> [    3.132756] system 00:02: [io  0x0cd6-0x0cd7] has been reserved
> [    3.133111] system 00:02: [io  0x0cd8-0x0cdf] has been reserved
> [    3.133460] system 00:02: [io  0x0800-0x089f] has been reserved
> [    3.133814] system 00:02: [io  0x0b20-0x0b3f] has been reserved
> [    3.134168] system 00:02: [io  0x0900-0x090f] has been reserved
> [    3.134524] system 00:02: [io  0x0910-0x091f] has been reserved
> [    3.134888] system 00:02: [io  0xfe00-0xfefe] has been reserved
> [    3.135250] system 00:02: [mem 0xfec00000-0xfec00fff] could not be reserved
> [    3.135651] system 00:02: [mem 0xfee00000-0xfee00fff] has been reserved
> [    3.136053] system 00:02: [mem 0xfed80000-0xfed8ffff] has been reserved
> [    3.136437] system 00:02: [mem 0xfed61000-0xfed70fff] has been reserved
> [    3.136829] system 00:02: [mem 0xfec10000-0xfec10fff] has been reserved
> [    3.137219] system 00:02: [mem 0xfed00000-0xfed00fff] has been reserved
> [    3.137608] system 00:02: [mem 0xff000000-0xffffffff] has been reserved
> [    3.138015] system 00:02: Plug and Play ACPI device, IDs PNP0c02 (active)
> [    3.138611] pnp 00:03: [io  0x0000-0xffffffffffffffff disabled]
> [    3.138981] pnp 00:03: [io  0x0300-0x031f]
> [    3.139249] pnp 00:03: [io  0x0290-0x029f]
> [    3.139512] pnp 00:03: [io  0x0230-0x023f]
> [    3.140070] system 00:03: [io  0x0300-0x031f] has been reserved
> [    3.140431] system 00:03: [io  0x0290-0x029f] has been reserved
> [    3.140800] system 00:03: [io  0x0230-0x023f] has been reserved
> [    3.141165] system 00:03: Plug and Play ACPI device, IDs PNP0c02 (active)
> [    3.141595] pnp 00:04: [dma 4]
> [    3.141809] pnp 00:04: [io  0x0000-0x000f]
> [    3.142070] pnp 00:04: [io  0x0081-0x0083]
> [    3.142330] pnp 00:04: [io  0x0087]
> [    3.142557] pnp 00:04: [io  0x0089-0x008b]
> [    3.142825] pnp 00:04: [io  0x008f]
> [    3.143052] pnp 00:04: [io  0x00c0-0x00df]
> [    3.143532] pnp 00:04: Plug and Play ACPI device, IDs PNP0200 (active)
> [    3.143961] pnp 00:05: [io  0x0070-0x0071]
> [    3.144222] xen: registering gsi 8 triggering 1 polarity 0
> [    3.144562] pnp 00:05: [irq 8]
> [    3.145001] pnp 00:05: Plug and Play ACPI device, IDs PNP0b00 (active)
> [    3.145408] pnp 00:06: [io  0x0061]
> [    3.145932] pnp 00:06: Plug and Play ACPI device, IDs PNP0800 (active)
> [    3.146422] pnp 00:07: [io  0x0010-0x001f]
> [    3.146682] pnp 00:07: [io  0x0022-0x003f]
> [    3.146977] pnp 00:07: [io  0x0044-0x005f]
> [    3.147238] pnp 00:07: [io  0x0072-0x007f]
> [    3.147491] pnp 00:07: [io  0x0080]
> [    3.147722] pnp 00:07: [io  0x0084-0x0086]
> [    3.147980] pnp 00:07: [io  0x0088]
> [    3.148211] pnp 00:07: [io  0x008c-0x008e]
> [    3.148469] pnp 00:07: [io  0x0090-0x009f]
> [    3.148734] pnp 00:07: [io  0x00a2-0x00bf]
> [    3.148988] pnp 00:07: [io  0x00e0-0x00ef]
> [    3.149250] pnp 00:07: [io  0x04d0-0x04d1]
> [    3.149697] system 00:07: [io  0x04d0-0x04d1] has been reserved
> [    3.150061] system 00:07: Plug and Play ACPI device, IDs PNP0c02 (active)
> [    3.150478] pnp 00:08: [io  0x00f0-0x00ff]
> [    3.150755] xen: registering gsi 13 triggering 1 polarity 0
> [    3.151101] pnp 00:08: [irq 13]
> [    3.151448] pnp 00:08: Plug and Play ACPI device, IDs PNP0c04 (active)
> [    3.152100] system 00:09: Plug and Play ACPI device, IDs PNP0c02 (active)
> [    3.152778] pnp 00:0a: [io  0x03f8-0x03ff]
> [    3.153037] xen: registering gsi 4 triggering 1 polarity 0
> [    3.153376] pnp 00:0a: [irq 4]
> [    3.153581] pnp 00:0a: [dma 0 disabled]
> [    3.153998] pnp 00:0a: Plug and Play ACPI device, IDs PNP0501 (active)
> [    3.155394] pnp 00:0b: [mem 0xfed00000-0xfed003ff]
> [    3.155978] pnp 00:0b: Plug and Play ACPI device, IDs PNP0103 (active)
> [    3.156388] pnp: PnP ACPI: found 12 devices
> [    3.156653] ACPI: ACPI bus type pnp unregistered
> [    3.156953] xen-pciback: Error parsing pci_devs_to_hide at "(00:02:00)"
> [    3.170459] PM-Timer failed consistency check  (0x0xffffff) - aborting.
> [    3.170947] pci 0000:00:14.4: PCI bridge to [bus 01]
> [    3.171261] pci 0000:00:14.4:   bridge window [io  0xe000-0xefff]
> [    3.171655] pci 0000:00:15.0: PCI bridge to [bus 02]
> [    3.171974] pci 0000:00:15.0:   bridge window [io  0xd000-0xdfff]
> [    3.172345] pci 0000:00:15.0:   bridge window [mem 0xfea00000-0xfeafffff]
> [    3.172762] pci 0000:00:15.1: PCI bridge to [bus 03]
> [    3.173067] pci 0000:00:15.1:   bridge window [io  0xc000-0xcfff]
> [    3.173436] pci 0000:00:15.1:   bridge window [mem 0xfe900000-0xfe9fffff]
> [    3.173889] xen: registering gsi 16 triggering 0 polarity 1
> [    3.174247] xen: --> pirq=16 -> irq=16 (gsi=16)
> [    3.174547] xen: registering gsi 16 triggering 0 polarity 1
> [    3.174894] Already setup the GSI :16
> [    3.175131] pci_bus 0000:00: resource 4 [io  0x0000-0x03af]
> [    3.175470] pci_bus 0000:00: resource 5 [io  0x03e0-0x0cf7]
> [    3.176854] pci_bus 0000:00: resource 6 [io  0x03b0-0x03df]
> [    3.177184] pci_bus 0000:00: resource 7 [io  0x0d00-0xffff]
> [    3.177514] pci_bus 0000:00: resource 8 [mem 0x000a0000-0x000bffff]
> [    3.177891] pci_bus 0000:00: resource 9 [mem 0x000c0000-0x000dffff]
> [    3.178267] pci_bus 0000:00: resource 10 [mem 0xd0000000-0xffffffff]
> [    3.178649] pci_bus 0000:01: resource 0 [io  0xe000-0xefff]
> [    3.178994] pci_bus 0000:01: resource 4 [io  0x0000-0x03af]
> [    3.179326] pci_bus 0000:01: resource 5 [io  0x03e0-0x0cf7]
> [    3.179672] pci_bus 0000:01: resource 6 [io  0x03b0-0x03df]
> [    3.180015] pci_bus 0000:01: resource 7 [io  0x0d00-0xffff]
> [    3.180344] pci_bus 0000:01: resource 8 [mem 0x000a0000-0x000bffff]
> [    3.180716] pci_bus 0000:01: resource 9 [mem 0x000c0000-0x000dffff]
> [    3.181081] pci_bus 0000:01: resource 10 [mem 0xd0000000-0xffffffff]
> [    3.181452] pci_bus 0000:02: resource 0 [io  0xd000-0xdfff]
> [    3.181792] pci_bus 0000:02: resource 1 [mem 0xfea00000-0xfeafffff]
> [    3.182168] pci_bus 0000:03: resource 0 [io  0xc000-0xcfff]
> [    3.182505] pci_bus 0000:03: resource 1 [mem 0xfe900000-0xfe9fffff]
> [    3.183045] NET: Registered protocol family 2
> [    3.184322] TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
> [    3.186023] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
> [    3.186732] TCP: Hash tables configured (established 262144 bind 65536)
> [    3.187181] TCP: reno registered
> [    3.187411] UDP hash table entries: 1024 (order: 3, 32768 bytes)
> [    3.187803] UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes)
> [    3.188405] NET: Registered protocol family 1
> [    3.188924] RPC: Registered named UNIX socket transport module.
> [    3.189285] RPC: Registered udp transport module.
> [    3.189588] RPC: Registered tcp transport module.
> [    3.189901] RPC: Registered tcp NFSv4.1 backchannel transport module.
> [    3.190306] pci 0000:00:01.0: Boot video device
> [    3.190606] xen: registering gsi 18 triggering 0 polarity 1
> [    3.190967] xen: --> pirq=18 -> irq=18 (gsi=18)
> [    3.191310] xen: registering gsi 17 triggering 0 polarity 1
> [    3.191651] xen: --> pirq=17 -> irq=17 (gsi=17)
> [    3.191987] xen: registering gsi 18 triggering 0 polarity 1
> [    3.192322] Already setup the GSI :18
> [    3.779210] xen: registering gsi 17 triggering 0 polarity 1
> [    3.779560] Already setup the GSI :17
> [    3.779854] xen: registering gsi 18 triggering 0 polarity 1
> [    3.780189] Already setup the GSI :18
> [    3.852950] xen: registering gsi 17 triggering 0 polarity 1
> [    3.853302] Already setup the GSI :17
> [    3.853601] xen: registering gsi 18 triggering 0 polarity 1
> [    3.853944] Already setup the GSI :18
> [    3.927246] PCI: CLS 64 bytes, default 64
> [    3.927731] Unpacking initramfs...
> [    4.409499] Freeing initrd memory: 339204k freed
> [    4.502233] Machine check injector initialized
> [    4.504138] microcode: CPU0: patch_level=0x0300000f
> [    4.504463] microcode: CPU1: patch_level=0x0300000f
> [    4.504809] microcode: CPU2: patch_level=0x0300000f
> [    4.505347] microcode: Microcode Update Driver: v2.00 , Peter Oruba
> [    4.506684] audit: initializing netlink socket (disabled)
> [    4.507060] type=2000 audit(1351615437.471:1): initialized
> [    4.520849] HugeTLB registered 2 MB page size, pre-allocated 0 pages
> [    4.521549] VFS: Disk quotas dquot_6.5.2
> [    4.521865] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
> [    4.522596] NFS: Registering the id_resolver key type
> [    4.522935] Key type id_resolver registered
> [    4.523199] Key type id_legacy registered
> [    4.523463] NTFS driver 2.1.30 [Flags: R/W].
> [    4.523927] msgmni has been set to 1798
> [    4.524230] SELinux:  Registering netfilter hooks
> [    4.526131] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
> [    4.526572] io scheduler noop registered
> [    4.526834] io scheduler deadline registered
> [    4.527129] io scheduler cfq registered (default)
> [    4.528468] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
> [    4.529395] input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input0
> [    4.529907] ACPI: Power Button [PWRB]
> [    4.530299] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
> [    4.530782] ACPI: Power Button [PWRF]
> [    4.592637] GHES: HEST is not enabled!
> [    4.592910] ioatdma: Intel(R) QuickData Technology Driver 4.00
> [    4.594402] xen-pciback: backend is vpci
> [    4.666851] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
> [    4.688746] 00:0a: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
> [    4.692137] xen: registering gsi 20 triggering 0 polarity 1
> [    4.692685] xen: --> pirq=20 -> irq=20 (gsi=20)
> [    4.715090] 0000:01:05.0: ttyS1 at I/O 0xe050 (irq = 20) is a 16550A
> [    4.723123] hpet_acpi_add: no address or irqs in _CRS
> [    4.729073] Non-volatile memory driver v1.3
> [    4.733807] Linux agpgart interface v0.103
> [    4.739678] [drm] Initialized drm 1.1.0 20060810
> [    4.747593] loop: module loaded
> [    4.751865] libphy: Fixed MDIO Bus: probed
> [    4.756157] tun: Universal TUN/TAP device driver, 1.6
> [    4.761408] tun: (C) 1999-2004 Max Krasnyansky 
> [    4.768474] ixgbevf: Intel(R) 10 Gigabit PCI Express Virtual Function Network Driver - version 2.6.0-k
> [    4.778143] ixgbevf: Copyright (c) 2009 - 2012 Intel Corporation.
> [    4.786308] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> [    4.793112] ehci_hcd: block sizes: qh 104 qtd 96 itd 192 sitd 96
> [    4.799394] xen: registering gsi 17 triggering 0 polarity 1
> [    4.805186] Already setup the GSI :17
> [    4.809041] ehci_hcd 0000:00:12.2: EHCI Host Controller
> [    4.814827] ehci_hcd 0000:00:12.2: new USB bus registered, assigned bus number 1
> [    4.822582] QUIRK: Enable AMD PLL fix
> [    4.826402] ehci_hcd 0000:00:12.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround
> [    4.835422] ehci_hcd 0000:00:12.2: reset hcs_params 0x101505 dbg=1 cc=1 pcc=5 ordered !ppc ports=5
> [    4.844716] ehci_hcd 0000:00:12.2: reset hcc_params a076 thresh 7 uframes 256/512/1024 park
> [    4.853444] ehci_hcd 0000:00:12.2: park 0
> [    4.857628] ehci_hcd 0000:00:12.2: reset command 0080b02  park=3 ithresh=8 period=1024 Reset HALT
> [    4.866843] ehci_hcd 0000:00:12.2: debug port 1
> [    4.871568] ehci_hcd 0000:00:12.2: MWI active
> [    4.876100] ehci_hcd 0000:00:12.2: supports USB remote wakeup
> [    4.882116] ehci_hcd 0000:00:12.2: irq 17, io mem 0xfeb4f000
> [    4.887997] ehci_hcd 0000:00:12.2: init command 0010005 (park)=0 ithresh=1 period=512 RUN
> [    4.901882] ehci_hcd 0000:00:12.2: USB 2.0 started, EHCI 1.00
> [    4.907965] usb usb1: default language 0x0409
> [    4.912513] usb usb1: udev 1, busnum 1, minor = 0
> [    4.917409] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
> [    4.924454] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> [    4.931952] usb usb1: Product: EHCI Host Controller
> [    4.937024] usb usb1: Manufacturer: Linux 3.7.0-rc3upstream-00220-g37b7153 ehci_hcd
> [    4.944967] usb usb1: SerialNumber: 0000:00:12.2
> [    4.950259] usb usb1: usb_probe_device
> [    4.954193] usb usb1: configuration #1 chosen from 1 choice
> [    4.959997] usb usb1: adding 1-0:1.0 (config #1, interface 0)
> [    4.966339] hub 1-0:1.0: usb_probe_interface
> [    4.970812] hub 1-0:1.0: usb_probe_interface - got id
> [    4.976063] hub 1-0:1.0: USB hub found
> [    4.979980] hub 1-0:1.0: 5 ports detected
> [    4.984155] hub 1-0:1.0: standalone hub
> [    4.988148] hub 1-0:1.0: no power switching (usb 1.0)
> [    4.993398] hub 1-0:1.0: individual port over-current protection
> [    4.999631] hub 1-0:1.0: power on to power good time: 20ms
> [    5.005333] hub 1-0:1.0: local power source is good
> [    5.010998] hub 1-0:1.0: trying to enable port power on non-switchable hub
> [    5.018235] xen: registering gsi 17 triggering 0 polarity 1
> [    5.024028] Already setup the GSI :17
> [    5.027880] ehci_hcd 0000:00:13.2: EHCI Host Controller
> [    5.033663] ehci_hcd 0000:00:13.2: new USB bus registered, assigned bus number 2
> [    5.041377] ehci_hcd 0000:00:13.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround
> [    5.050398] ehci_hcd 0000:00:13.2: reset hcs_params 0x101505 dbg=1 cc=1 pcc=5 ordered !ppc ports=5
> [    5.059685] ehci_hcd 0000:00:13.2: reset hcc_params a076 thresh 7 uframes 256/512/1024 park
> [    5.068427] ehci_hcd 0000:00:13.2: park 0
> [    5.072610] ehci_hcd 0000:00:13.2: reset command 0080b02  park=3 ithresh=8 period=1024 Reset HALT
> [    5.081823] ehci_hcd 0000:00:13.2: debug port 1
> [    5.086547] ehci_hcd 0000:00:13.2: MWI active
> [    5.091081] ehci_hcd 0000:00:13.2: supports USB remote wakeup
> [    5.097059] ehci_hcd 0000:00:13.2: irq 17, io mem 0xfeb4d000
> [    5.102937] ehci_hcd 0000:00:13.2: init command 0010005 (park)=0 ithresh=1 period=512 RUN
> [    5.116889] ehci_hcd 0000:00:13.2: USB 2.0 started, EHCI 1.00
> [    5.123004] usb usb2: default language 0x0409
> [    5.127553] usb usb2: udev 1, busnum 2, minor = 128
> [    5.132627] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
> [    5.139668] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> [    5.147164] usb usb2: Product: EHCI Host Controller
> [    5.152236] usb usb2: Manufacturer: Linux 3.7.0-rc3upstream-00220-g37b7153 ehci_hcd
> [    5.160180] usb usb2: SerialNumber: 0000:00:13.2
> [    5.165185] hub 1-0:1.0: state 7 ports 5 chg 0000 evt 0000
> [    5.165547] usb usb2: usb_probe_device
> [    5.165551] usb usb2: configuration #1 chosen from 1 choice
> [    5.165570] usb usb2: adding 2-0:1.0 (config #1, interface 0)
> [    5.165905] hub 2-0:1.0: usb_probe_interface
> [    5.165908] hub 2-0:1.0: usb_probe_interface - got id
> [    5.165911] hub 2-0:1.0: USB hub found
> [    5.165929] hub 2-0:1.0: 5 ports detected
> [    5.165930] hub 2-0:1.0: standalone hub
> [    5.165931] hub 2-0:1.0: no power switching (usb 1.0)
> [    5.165933] hub 2-0:1.0: individual port over-current protection
> [    5.165935] hub 2-0:1.0: power on to power good time: 20ms
> [    5.165942] hub 2-0:1.0: local power source is good
> [    5.166518] hub 2-0:1.0: trying to enable port power on non-switchable hub
> [    5.166966] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
> [    5.166969] ohci_hcd: block sizes: ed 80 td 96
> [    5.167028] xen: registering gsi 18 triggering 0 polarity 1
> [    5.167033] Already setup the GSI :18
> [    5.167075] ohci_hcd 0000:00:12.0: OHCI Host Controller
> [    5.167260] ohci_hcd 0000:00:12.0: new USB bus registered, assigned bus number 3
> [    5.167338] ohci_hcd 0000:00:12.0: created debug files
> [    5.167340] ohci_hcd 0000:00:12.0: supports USB remote wakeup
> [    5.167385] ohci_hcd 0000:00:12.0: irq 18, io mem 0xfeb50000
> [    5.289966] hub 2-0:1.0: state 7 ports 5 chg 0000 evt 0000
> [    5.293989] ohci_hcd 0000:00:12.0: OHCI controller state
> [    5.293995] ohci_hcd 0000:00:12.0: OHCI 1.0, NO legacy support registers, rh state running
> [    5.293999] ohci_hcd 0000:00:12.0: control 0x283 RWC HCFS=operational CBSR=3
> [    5.294002] ohci_hcd 0000:00:12.0: cmdstatus 0x00000 SOC=0
> [    5.294006] ohci_hcd 0000:00:12.0: intrstatus 0x00000004 SF
> [    5.294009] ohci_hcd 0000:00:12.0: intrenable 0x8000005a MIE RHSC UE RD WDH
> [    5.294019] ohci_hcd 0000:00:12.0: hcca frame #0005
> [    5.294022] ohci_hcd 0000:00:12.0: roothub.a 02001205 POTPGT=2 NOCP NPS NDP=5(5)
> [    5.294025] ohci_hcd 0000:00:12.0: roothub.b 00000000 PPCM=0000 DR=0000
> [    5.294027] ohci_hcd 0000:00:12.0: roothub.status 00008000 DRWE
> [    5.294031] ohci_hcd 0000:00:12.0: roothub.portstatus [0] 0x00000100 PPS
> [    5.294034] ohci_hcd 0000:00:12.0: roothub.portstatus [1] 0x00000100 PPS
> [    5.294037] ohci_hcd 0000:00:12.0: roothub.portstatus [2] 0x00000100 PPS
> [    5.294041] ohci_hcd 0000:00:12.0: roothub.portstatus [3] 0x00000100 PPS
> [    5.294044] ohci_hcd 0000:00:12.0: roothub.portstatus [4] 0x00000100 PPS
> [    5.294080] usb usb3: default language 0x0409
> [    5.294093] usb usb3: udev 1, busnum 3, minor = 256
> [    5.294095] usb usb3: New USB device found, idVendor=1d6b, idProduct=0001
> [    5.294097] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> [    5.294098] usb usb3: Product: OHCI Host Controller
> [    5.294100] usb usb3: Manufacturer: Linux 3.7.0-rc3upstream-00220-g37b7153 ohci_hcd
> [    5.294101] usb usb3: SerialNumber: 0000:00:12.0
> [    5.294371] usb usb3: usb_probe_device
> [    5.294374] usb usb3: configuration #1 chosen from 1 choice
> [    5.294386] usb usb3: adding 3-0:1.0 (config #1, interface 0)
> [    5.294481] hub 3-0:1.0: usb_probe_interface
> [    5.294482] hub 3-0:1.0: usb_probe_interface - got id
> [    5.294484] hub 3-0:1.0: USB hub found
> [    5.294492] hub 3-0:1.0: 5 ports detected
> [    5.294493] hub 3-0:1.0: standalone hub
> [    5.294495] hub 3-0:1.0: no power switching (usb 1.0)
> [    5.294496] hub 3-0:1.0: no over-current protection
> [    5.294497] hub 3-0:1.0: power on to power good time: 4ms
> [    5.294505] hub 3-0:1.0: local power source is good
> [    5.295074] hub 3-0:1.0: trying to enable port power on non-switchable hub
> [    5.295131] ehci_hcd 0000:00:12.2: HS companion for 0000:00:12.0
> [    5.295174] xen: registering gsi 18 triggering 0 polarity 1
> [    5.295178] Already setup the GSI :18
> [    5.295219] ohci_hcd 0000:00:13.0: OHCI Host Controller
> [    5.295337] ohci_hcd 0000:00:13.0: new USB bus registered, assigned bus number 4
> [    5.295397] ohci_hcd 0000:00:13.0: created debug files
> [    5.295399] ohci_hcd 0000:00:13.0: supports USB remote wakeup
> [    5.295409] ohci_hcd 0000:00:13.0: irq 18, io mem 0xfeb4e000
> [    5.549971] hub 3-0:1.0: state 7 ports 5 chg 0000 evt 0000
> [    5.553975] ohci_hcd 0000:00:13.0: OHCI controller state
> [    5.553980] ohci_hcd 0000:00:13.0: OHCI 1.0, NO legacy support registers, rh state running
> [    5.553984] ohci_hcd 0000:00:13.0: control 0x283 RWC HCFS=operational CBSR=3
> [    5.553987] ohci_hcd 0000:00:13.0: cmdstatus 0x00000 SOC=0
> [    5.553990] ohci_hcd 0000:00:13.0: intrstatus 0x00000004 SF
> [    5.553993] ohci_hcd 0000:00:13.0: intrenable 0x8000005a MIE RHSC UE RD WDH
> [    5.554004] ohci_hcd 0000:00:13.0: hcca frame #0005
> [    5.554008] ohci_hcd 0000:00:13.0: roothub.a 02001205 POTPGT=2 NOCP NPS NDP=5(5)
> [    5.554011] ohci_hcd 0000:00:13.0: roothub.b 00000000 PPCM=0000 DR=0000
> [    5.554014] ohci_hcd 0000:00:13.0: roothub.status 00008000 DRWE
> [    5.554018] ohci_hcd 0000:00:13.0: roothub.portstatus [0] 0x00000100 PPS
> [    5.554021] ohci_hcd 0000:00:13.0: roothub.portstatus [1] 0x00000100 PPS
> [    5.554025] ohci_hcd 0000:00:13.0: roothub.portstatus [2] 0x00000100 PPS
> [    5.554028] ohci_hcd 0000:00:13.0: roothub.portstatus [3] 0x00000100 PPS
> [    5.554031] ohci_hcd 0000:00:13.0: roothub.portstatus [4] 0x00000100 PPS
> [    5.554051] usb usb4: default language 0x0409
> [    5.554064] usb usb4: udev 1, busnum 4, minor = 384
> [    5.554066] usb usb4: New USB device found, idVendor=1d6b, idProduct=0001
> [    5.554068] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> [    5.554070] usb usb4: Product: OHCI Host Controller
> [    5.554071] usb usb4: Manufacturer: Linux 3.7.0-rc3upstream-00220-g37b7153 ohci_hcd
> [    5.554072] usb usb4: SerialNumber: 0000:00:13.0
> [    5.554538] usb usb4: usb_probe_device
> [    5.554542] usb usb4: configuration #1 chosen from 1 choice
> [    5.554559] usb usb4: adding 4-0:1.0 (config #1, interface 0)
> [    5.554665] hub 4-0:1.0: usb_probe_interface
> [    5.554667] hub 4-0:1.0: usb_probe_interface - got id
> [    5.554669] hub 4-0:1.0: USB hub found
> [    5.554678] hub 4-0:1.0: 5 ports detected
> [    5.554679] hub 4-0:1.0: standalone hub
> [    5.554681] hub 4-0:1.0: no power switching (usb 1.0)
> [    5.554682] hub 4-0:1.0: no over-current protection
> [    5.554683] hub 4-0:1.0: power on to power good time: 4ms
> [    5.554691] hub 4-0:1.0: local power source is good
> [    5.555283] hub 4-0:1.0: trying to enable port power on non-switchable hub
> [    5.555346] ehci_hcd 0000:00:13.2: HS companion for 0000:00:13.0
> [    5.555389] xen: registering gsi 18 triggering 0 polarity 1
> [    5.555394] Already setup the GSI :18
> [    5.555433] ohci_hcd 0000:00:14.5: OHCI Host Controller
> [    5.555598] ohci_hcd 0000:00:14.5: new USB bus registered, assigned bus number 5
> [    5.555670] ohci_hcd 0000:00:14.5: created debug files
> [    5.555672] ohci_hcd 0000:00:14.5: supports USB remote wakeup
> [    5.555685] ohci_hcd 0000:00:14.5: irq 18, io mem 0xfeb4c000
> [    5.809859] hub 4-0:1.0: state 7 ports 5 chg 0000 evt 0000
> [    5.813841] ohci_hcd 0000:00:14.5: OHCI controller state
> [    5.813847] ohci_hcd 0000:00:14.5: OHCI 1.0, NO legacy support registers, rh state running
> [    5.813851] ohci_hcd 0000:00:14.5: control 0x283 RWC HCFS=operational CBSR=3
> [    5.813854] ohci_hcd 0000:00:14.5: cmdstatus 0x00000 SOC=0
> [    5.813857] ohci_hcd 0000:00:14.5: intrstatus 0x00000004 SF
> [    5.813860] ohci_hcd 0000:00:14.5: intrenable 0x8000005a MIE RHSC UE RD WDH
> [    5.813871] ohci_hcd 0000:00:14.5: hcca frame #0004
> [    5.813874] ohci_hcd 0000:00:14.5: roothub.a 02001202 POTPGT=2 NOCP NPS NDP=2(2)
> [    5.813876] ohci_hcd 0000:00:14.5: roothub.b 00000000 PPCM=0000 DR=0000
> [    5.813880] ohci_hcd 0000:00:14.5: roothub.status 00008000 DRWE
> [    5.813884] ohci_hcd 0000:00:14.5: roothub.portstatus [0] 0x00000100 PPS
> [    5.813886] ohci_hcd 0000:00:14.5: roothub.portstatus [1] 0x00000100 PPS
> [    5.813923] usb usb5: default language 0x0409
> [    5.813935] usb usb5: udev 1, busnum 5, minor = 512
> [    5.813938] usb usb5: New USB device found, idVendor=1d6b, idProduct=0001
> [    5.813939] usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> [    5.813941] usb usb5: Product: OHCI Host Controller
> [    5.813942] usb usb5: Manufacturer: Linux 3.7.0-rc3upstream-00220-g37b7153 ohci_hcd
> [    5.813944] usb usb5: SerialNumber: 0000:00:14.5
> [    5.814220] usb usb5: usb_probe_device
> [    5.814223] usb usb5: configuration #1 chosen from 1 choice
> [    5.814238] usb usb5: adding 5-0:1.0 (config #1, interface 0)
> [    5.814373] hub 5-0:1.0: usb_probe_interface
> [    5.814375] hub 5-0:1.0: usb_probe_interface - got id
> [    5.814377] hub 5-0:1.0: USB hub found
> [    5.814390] hub 5-0:1.0: 2 ports detected
> [    5.814392] hub 5-0:1.0: standalone hub
> [    5.814393] hub 5-0:1.0: no power switching (usb 1.0)
> [    5.814394] hub 5-0:1.0: no over-current protection
> [    5.814396] hub 5-0:1.0: power on to power good time: 4ms
> [    5.814405] hub 5-0:1.0: local power source is good
> [    5.814425] hub 5-0:1.0: trying to enable port power on non-switchable hub
> [    5.814584] uhci_hcd: USB Universal Host Controller Interface driver
> [    6.009259] hub 5-0:1.0: state 7 ports 2 chg 0000 evt 0000
> [    6.009372] usbcore: registered new interface driver usblp
> [    6.009676] i8042: PNP: No PS/2 controller found. Probing ports directly.
> [    6.010397] serio: i8042 KBD port at 0x60,0x64 irq 1
> [    6.010409] serio: i8042 AUX port at 0x60,0x64 irq 12
> [    6.010691] mousedev: PS/2 mouse device common for all mice
> [    6.011327] rtc_cmos 00:05: RTC can wake from S4
> [    6.011618] rtc_cmos 00:05: rtc core: registered rtc_cmos as rtc0
> [    6.011662] rtc0: alarms up to one month, y3k, 114 bytes nvram
> [    6.011868] EFI Variables Facility v0.08 2004-May-17
> [    6.011957] zram: num_devices not specified. Using default: 1
> [    6.011958] zram: Creating 1 devices ...
> [    6.077064] Netfilter messages via NETLINK v0.30.
> [    6.082006] nf_conntrack version 0.5.0 (7194 buckets, 28776 max)
> [    6.088334] ctnetlink v0.93: registering with nfnetlink.
> [    6.094201] ip_tables: (C) 2000-2006 Netfilter Core Team
> [    6.099817] TCP: cubic registered
> [    6.103279] Initializing XFRM netlink socket
> [    6.107873] NET: Registered protocol family 10
> [    6.112784] ip6_tables: (C) 2000-2006 Netfilter Core Team
> [    6.119125] sit: IPv6 over IPv4 tunneling driver
> [    6.124870] NET: Registered protocol family 17
> [    6.129593] Key type dns_resolver registered
> [    6.135108] PM: Hibernation image not present or could not be loaded.
> [    6.141853] registered taskstats version 1
> [    6.146837]   Magic number: 0:661:743
> [    6.151899] Freeing unused kernel memory: 752k freed
> [    6.157248] Write protecting the kernel read-only data: 10240k
> [    6.169212] Freeing unused kernel memory: 1768k freed
> [    6.175129] Freeing unused kernel memory: 168k freed
> [    6.188257] consoletype (1257) used greatest stack depth: 5272 bytes left
> [    6.524961] modprobe (1286) used greatest stack depth: 5256 bytes left
> [    6.547403] core_filesystem (1258) used greatest stack depth: 4952 bytes left
> [    6.592358] Initialising Xen virtual ethernet driver.
> [    6.722568] wmi: Mapper loaded
> [    6.796831] xen: registering gsi 17 triggering 0 polarity 1
> [    6.802666] Already setup the GSI :17
> [    6.808260] e1000e: Intel(R) PRO/1000 Network Driver - 2.1.4-k
> [    6.814354] e1000e: Copyright(c) 1999 - 2012 Intel Corporation.
> [    6.816573] SCSI subsystem initialized
> [    6.824498] e1000e 0000:02:00.0: Disabling ASPM L0s L1
> [    6.824524] xen: registering gsi 16 triggering 0 polarity 1
> [    6.824531] Already setup the GSI :16
> [    6.824740] e1000e 0000:02:00.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
> [    6.859455] [drm] radeon defaulting to kernel modesetting.
> [    6.866428] [drm] radeon kernel modesetting enabled.
> [    6.873121] xen: registering gsi 18 triggering 0 polarity 1
> [    6.873126] Already setup the GSI :18
> [    6.883269] atl1c 0000:03:00.0: version 1.0.1.0-NAPI
> [    6.883447] [drm] initializing kernel modesetting (SUMO 0x1002:0x9640 0x1043:0x84C8).
> [    6.883509] [drm] register mmio base: 0xFEB00000
> [    6.883511] [drm] register mmio size: 262144
> [    6.883646] ATOM BIOS: General
> [    6.883717] radeon 0000:00:01.0: VRAM: 512M 0x0000000000000000 - 0x000000001FFFFFFF (512M used)
> [    6.883720] radeon 0000:00:01.0: GTT: 512M 0x0000000020000000 - 0x000000003FFFFFFF
> [    6.883722] [drm] Detected VRAM RAM=512M, BAR=256M
> [    6.883725] [drm] RAM width 32bits DDR
> [    6.884463] [TTM] Zone  kernel: Available graphics memory: 461822 kiB
> [    6.884466] [TTM] Initializing pool allocator
> [    6.884476] [TTM] Initializing DMA pool allocator
> [    6.884529] [drm] radeon: 512M of VRAM memory ready
> [    6.884531] [drm] radeon: 512M of GTT memory ready.
> [    6.884622] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
> [    6.884625] [drm] Driver supports precise vblank timestamp query.
> [    6.884802] radeon 0000:00:01.0: radeon: using MSI.
> [    6.884865] [drm] radeon: irq initialized.
> [    6.884871] [drm] GART: num cpu pages 131072, num gpu pages 131072
> [    6.895835] [drm] Loading SUMO Microcode
> [    6.933742] ACPI: bus type scsi registered
> [    6.941860] e1000e 0000:02:00.0 eth1: (PCI Express:2.5GT/s:Width x1) 00:1b:21:ab:c6:12
> [    6.941862] e1000e 0000:02:00.0 eth1: Intel(R) PRO/1000 Network Connection
> [    6.941882] e1000e 0000:02:00.0 eth1: MAC: 3, PHY: 8, PBA No: E46981-005
> [    6.997612] ip (1909) used greatest stack depth: 3896 bytes left
> [    7.048540] libata version 3.00 loaded.
> [    7.144568] [drm] PCIE GART of 512M enabled (table at 0x0000000000040000).
> [    7.151898] radeon 0000:00:01.0: WB enabled
> [    7.156253] radeon 0000:00:01.0: fence driver on ring 0 use gpu addr 0x0000000020000c00 and cpu addr 0xffff880023235c00
> [    7.185375] [drm] ring test on 0 succeeded in 1 usecs
> [    7.191817] [drm] ib test on ring 0 succeeded in 0 usecs
> [    7.209657] [drm] Radeon Display Connectors
> [    7.214052] [drm] Connector 0:
> [    7.217253] [drm]   VGA-1
> [    7.220007] [drm]   HPD2
> [    7.222674] [drm]   DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448 0x644c 0x644c
> [    7.230416] [drm]   Encoders:
> [    7.233539] [drm]     CRT1: INTERNAL_UNIPHY2
> [    7.238001] [drm]     CRT1: NUTMEG
> [    7.238003] [drm] Connector 1:
> [    7.238005] [drm]   HDMI-A-1
> [    7.238006] [drm]   HPD1
> [    7.238009] [drm]   DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c 0x643c
> [    7.238011] [drm]   Encoders:
> [    7.238011] [drm]     DFP1: INTERNAL_UNIPHY2
> [    7.255949] [drm] Internal thermal controller without fan control
> [    7.259955] [drm] radeon: power management initialized
> [    7.335529] No connectors reported connected with modes
> [    7.340968] [drm] Cannot find any crtc or sizes - going 1024x768
> [    7.350906] [drm] fb mappable at 0xD0142000
> [    7.355261] [drm] vram apper at 0xD0000000
> [    7.359523] [drm] size 3145728
> [    7.362716] [drm] fb depth is 24
> [    7.366146] [drm]    pitch is 4096
> [    7.370065] fbcon: radeondrmfb (fb0) is primary device
> [    7.376982] ttyS1: 1 input overrun(s)
> [    7.411210] Console: switching to colour frame buffer device 128x48
> [    7.424071] fb0: radeondrmfb frame buffer device
> [    7.428949] drm: registered panic notifier
> [    7.433284] [drm] Initialized radeon 2.24.0 20080528 for 0000:00:01.0 on minor 0
> [    7.441164] ahci 0000:00:11.0: version 3.0
> [    7.445546] xen: registering gsi 19 triggering 0 polarity 1
> [    7.451464] xen: --> pirq=19 -> irq=19 (gsi=19)
> [    7.456473] ahci 0000:00:11.0: AHCI 0001.0300 32 slots 6 ports 6 Gbps 0x3f impl SATA mode
> [    7.465104] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part
> [    7.478140] scsi0 : ahci
> [    7.481629] scsi1 : ahci
> [    7.484929] scsi2 : ahci
> [    7.488287] scsi3 : ahci
> [    7.491496] scsi4 : ahci
> [    7.494907] scsi5 : ahci
> [    7.498649] ata1: SATA max UDMA/133 abar m2048@0xfeb51000 port 0xfeb51100 irq 71
> [    7.507585] ata2: SATA max UDMA/133 abar m2048@0xfeb51000 port 0xfeb51180 irq 71
> [    7.515392] ata3: SATA max UDMA/133 abar m2048@0xfeb51000 port 0xfeb51200 irq 71
> [    7.523177] ata4: SATA max UDMA/133 abar m2048@0xfeb51000 port 0xfeb51280 irq 71
> [    7.530982] ata5: SATA max UDMA/133 abar m2048@0xfeb51000 port 0xfeb51300 irq 71
> [    7.538786] ata6: SATA max UDMA/133 abar m2048@0xfeb51000 port 0xfeb51380 irq 71
> [    7.850775] ata1: SATA link down (SStatus 0 SControl 300)
> [    7.856613] ata2: SATA link down (SStatus 0 SControl 300)
> [    7.862497] ata6: SATA link down (SStatus 0 SControl 300)
> [    7.871228] ata3: SATA link down (SStatus 0 SControl 300)
> [    7.879887] ata5: SATA link down (SStatus 0 SControl 300)
> [    8.038131] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> [    8.062593] ata4.00: ATA-7: WDC WD800AAJS-18TDA0, 01.00A03, max UDMA/133
> [    8.072417] ata4.00: 156250000 sectors, multi 16: LBA48 NCQ (depth 31/32), AA
> [    8.082336] ata4.00: failed to get Identify Device Data, Emask 0x1
> [    8.092297] ata4.00: failed to get Identify Device Data, Emask 0x1
> [    8.100682] ata4.00: configured for UDMA/133
> [    8.107497] scsi 3:0:0:0: Direct-Access     ATA      WDC WD800AAJS-18 01.0 PQ: 0 ANSI: 5
> [    8.129843] sd 3:0:0:0: [sda] 156250000 512-byte logical blocks: (80.0 GB/74.5 GiB)
> [    8.140007] sd 3:0:0:0: [sda] Write Protect is off
> [    8.146945] sd 3:0:0:0: [sda] Mode Sense: 00 3a 00 00
> [    8.154244] sd 3:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
> [    8.199771]  sda: sda1 sda2 sda3 sda4
> [    8.210772] sd 3:0:0:0: [sda] Attached SCSI disk
> [    8.224663] sd 3:0:0:0: Attached scsi generic sg0 type 0
> [    8.944409] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
> [    8.963120] device eth0 entered promiscuous mode
> [    9.181754] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
> [   10.053518] atl1c 0000:03:00.0: atl1c: eth0 NIC Link is Up<1000 Mbps Full Duplex>
> [   10.064785] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> [   11.555156] e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
> [   11.566749] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
> [   13.964892] switch: port 1(eth0) entered forwarding state
> [   13.973524] switch: port 1(eth0) entered forwarding state
> [   16.232334] Loading iSCSI transport class v2.0-870.
> [   16.248793] iscsi: registered transport (tcp)
> [   16.306470] Event-channel device installed.
> [   19.630065] mount.nfs (3143) used greatest stack depth: 3224 bytes left
> [   21.157586] device-mapper: ioctl: 4.23.0-ioctl (2012-07-25) initialised: dm-devel@redhat.com
> [   21.170420] device-mapper: multipath: version 1.5.0 loaded
> [   21.450531] scsi6 : iSCSI Initiator over TCP/IP
> [   21.731710] scsi 6:0:0:0: Direct-Access     LIO-ORG  IBLOCK           4.0  PQ: 0 ANSI: 5
> [   21.747167] sd 6:0:0:0: [sdb] 503316480 512-byte logical blocks: (257 GB/240 GiB)
> [   21.747211] sd 6:0:0:0: Attached scsi generic sg1 type 0
> [   21.748648] scsi 6:0:0:1: Direct-Access     LIO-ORG  IBLOCK           4.0  PQ: 0 ANSI: 5
> [   21.752968] sd 6:0:0:1: [sdc] 167772160 512-byte logical blocks: (85.8 GB/80.0 GiB)
> [   21.753042] sd 6:0:0:1: Attached scsi generic sg2 type 0
> [   21.755647] sd 6:0:0:1: [sdc] Write Protect is off
> [   21.755655] sd 6:0:0:1: [sdc] Mode Sense: 2f 00 00 00
> [   21.756638] sd 6:0:0:1: [sdc] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
> [   21.761219] scsi 6:0:0:2: Direct-Access     LIO-ORG  IBLOCK           4.0  PQ: 0 ANSI: 5
> [   21.770871] sd 6:0:0:2: Attached scsi generic sg3 type 0
> [   21.771168] sd 6:0:0:2: [sdd] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB)
> [   21.775163] ttyS1: 1 input overrun(s)
> [   21.776400] sd 6:0:0:2: [sdd] Write Protect is off
> [   21.776405] sd 6:0:0:2: [sdd] Mode Sense: 2f 00 00 00
> [   21.776884] sd 6:0:0:2: [sdd] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
> [   21.780001]  sdd: unknown partition table
> [   21.781272] sd 6:0:0:2: [sdd] Attached SCSI disk
> [   21.804226]  sdc: sdc1 sdc2 < sdc5 >
> [   21.806353] sd 6:0:0:1: [sdc] Attached SCSI disk
> [   21.918632] sd 6:0:0:0: [sdb] Write Protect is off
> [   21.926413] sd 6:0:0:0: [sdb] Mode Sense: 2f 00 00 00
> [   21.935417] sd 6:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
> [   21.963859]  sdb: unknown partition table
> [   21.974284] sd 6:0:0:0: [sdb] Attached SCSI disk
> [   28.589544] bio: create slab  at 1
> [   28.997728] switch: port 1(eth0) entered forwarding state
> [   57.703132] device vif1.0 entered promiscuous mode
> [   57.715328] IPv6: ADDRCONF(NETDEV_UP): vif1.0: link is not ready
> [   59.760909] IPv6: ADDRCONF(NETDEV_CHANGE): vif1.0: link becomes ready
> [   59.770384] switch: port 2(vif1.0) entered forwarding state
> [   59.778900] switch: port 2(vif1.0) entered forwarding state
> [   59.876529] xen-blkback:ring-ref 10, event-channel 18, protocol 2 (x86_32-abi) persistent grants
> [   65.135453] switch: port 2(vif1.0) entered disabled state
> [   65.145638] device vif1.0 left promiscuous mode
> [   65.154458] switch: port 2(vif1.0) entered disabled state
> [   70.836602] device vif2.0 entered promiscuous mode
> [   70.848191] IPv6: ADDRCONF(NETDEV_UP): vif2.0: link is not ready
> [   72.285945] IPv6: ADDRCONF(NETDEV_CHANGE): vif2.0: link becomes ready
> [   72.295310] switch: port 2(vif2.0) entered forwarding state
> [   72.303597] switch: port 2(vif2.0) entered forwarding state
> [   72.403140] xen-blkback:ring-ref 10, event-channel 11, protocol 1 (x86_64-abi) persistent grants
> [   72.544101] ------------[ cut here ]------------
> [   72.552932] kernel BUG at /home/konrad/linux/drivers/block/xen-blkback/blkback.c:589!
> [   72.563680] invalid opcode: 0000 [#1] SMP
> [   72.570865] Modules linked in: dm_multipath dm_mod xen_evtchn iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi libcrc32c crc32c sg sd_mod ahci libahci libata radeon e1000e scsi_mod atl1c fbcon ttm tileblit font bitblit softcursor drm_kms_helper wmi xen_blkfront xen_netfront fb_sys_fops sysimgblt sysfillrect syscopyarea xenfs xen_privcmd [last unloaded: dump_dma]
> [   72.617251] CPU 0
> [   72.619173] Pid: 3823, comm: blkback.2.xvda Tainted: G           O 3.7.0-rc3upstream-00220-g37b7153 #1 System manufacturer System Product Name/F1A75-M
> [   72.641606] RIP: e030:[]  [] xen_blkbk_map+0x696/0x6e0
> [   72.653181] RSP: e02b:ffff880027dd3728  EFLAGS: 00010246
> [   72.661651] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
> [   72.672090] RDX: ffff8800232d7f40 RSI: 0000000000000000 RDI: ffff880027dd3d88
> [   72.682437] RBP: ffff880027dd39e8 R08: 0000000000000000 R09: 0000000000000000
> [   72.692835] R10: 0000000000000001 R11: dead000000200200 R12: 0000000000000000
> [   72.703261] R13: 0000000000000000 R14: ffff88002b5e7070 R15: 0000000000000000
> [   72.713560] FS:  00007f6cc62d5700(0000) GS:ffff88003e000000(0000) knlGS:0000000000000000
> [   72.724921] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> [   72.733811] CR2: 00000000006dd384 CR3: 0000000027b8f000 CR4: 0000000000000660
> [   72.744131] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [   72.754517] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [   72.764882] Process blkback.2.xvda (pid: 3823, threadinfo ffff880027dd2000, task ffff88002bb15040)
> [   72.777140] Stack:
> [   72.782184]  ffff880027dd3738 ffff880026081af0 ffff880027dd3798 ffffffff810ac7df
> [   72.792960]  ffff880027dd3798 ffffffff8104c506 0000000000000117 ffff88002160d030
> [   72.803712]  ffff880027dd3a38 ffff88002b5e7120 ffff88002160d000 ffff880027dd3d88
> [   72.814469] Call Trace:
> [   72.820094]  [] ? __queue_work+0xff/0x420
> [   72.829023]  [] ? xen_spin_lock_flags+0xb6/0x120
> [   72.838462]  [] ? queue_work_on+0x31/0x50
> [   72.847279]  [] ? _raw_spin_unlock_irqrestore+0x19/0x30
> [   72.854408] ttyS1: 2 input overrun(s)
> [   72.864352]  [] ? pvclock_clocksource_read+0x58/0xd0
> [   72.874471]  [] ? cpumask_next_and+0x23/0x40
> [   72.883656]  [] ? cpumask_next_and+0x23/0x40
> [   72.892716]  [] ? update_sd_lb_stats+0x157/0x6c0
> [   72.902178]  [] ? _raw_spin_lock_irq+0x20/0x30
> [   72.911486]  [] ? find_busiest_group+0x31/0x4d0
> [   72.920849]  [] dispatch_rw_block_io+0x377/0x600
> [   72.930187]  [] ? pvclock_clocksource_read+0x58/0xd0
> [   72.939957]  [] ? xen_mc_flush+0xc0/0x1f0
> [   72.948743]  [] ? xen_end_context_switch+0x19/0x20
> [   72.958251]  [] ? pvclock_clocksource_read+0x58/0xd0
> [   72.967917]  [] ? pvclock_clocksource_read+0x58/0xd0
> [   72.977617]  [] ? pvclock_clocksource_read+0x58/0xd0
> [   72.987474]  [] ? xen_clocksource_read+0x39/0x50
> [   72.997278]  [] ? xen_spin_lock_flags+0xb6/0x120
> [   73.006476]  [] xen_blkif_schedule+0x21e/0xa00
> [   73.015493]  [] ? irq_to_desc+0x12/0x20
> [   73.023833]  [] ? irq_get_irq_data+0x9/0x10
> [   73.032418]  [] ? info_for_irq+0x9/0x20
> [   73.040554]  [] ? notify_remote_via_irq+0x29/0x50
> [   73.049523]  [] ? sched_clock_cpu+0xcd/0x110
> [   73.058024]  [] ? pvclock_clocksource_read+0x58/0xd0
> [   73.067191]  [] ? xen_mc_flush+0xc0/0x1f0
> [   73.075338]  [] ? __schedule+0x3be/0x7c0
> [   73.083311]  [] ? wake_up_bit+0x40/0x40
> [   73.091108]  [] ? dispatch_rw_block_io+0x600/0x600
> [   73.099902]  [] kthread+0xc6/0xd0
> [   73.107124]  [] ? xen_end_context_switch+0x19/0x20
> [   73.115845]  [] ? kthread_freezable_should_stop+0x80/0x80
> [   73.125266]  [] ret_from_fork+0x7c/0xb0
> [   73.133089]  [] ? kthread_freezable_should_stop+0x80/0x80
> [   73.142576] Code: 48 89 d7 e8 ad 66 d8 ff 4a c7 84 3d 70 ff ff ff 00 00 00 00 4c 8b 85 60 fd ff ff 41 8b b0 e4 fd ff ff 41 83 cd 01 e9 ef fb ff ff <0f> 0b eb fe 48 8d 95 10 ff ff ff 48 8d bd b0 fd ff ff 31 f6 44
> [   73.167611] RIP  [] xen_blkbk_map+0x696/0x6e0
> [   73.176081]  RSP 
> [   73.182024] ---[ end trace 914a52d8b62134db ]---
> [   87.339441] switch: port 2(vif2.0) entered forwarding state
> [  315.067569] device tap3.0 entered promiscuous mode
> [  315.074965] switch: port 3(tap3.0) entered forwarding state
> [  315.083116] switch: port 3(tap3.0) entered forwarding state
> [  315.142543] switch: port 3(tap3.0) entered disabled state
> [  315.161150] switch: port 3(tap3.0) entered forwarding state
> [  315.169097] switch: port 3(tap3.0) entered forwarding state
> [  330.162411] switch: port 3(tap3.0) entered forwarding state
> [  415.483626] switch: port 3(tap3.0) entered disabled state
> [  415.491439] device tap3.0 left promiscuous mode
> [  415.498191] switch: port 3(tap3.0) entered disabled state
> [  658.839306] device tap4.0 entered promiscuous mode
> [  658.846451] switch: port 3(tap4.0) entered forwarding state
> [  658.854354] switch: port 3(tap4.0) entered forwarding state
> [  658.923751] switch: port 3(tap4.0) entered disabled state
> [  658.942642] switch: port 3(tap4.0) entered forwarding state
> [  658.950492] switch: port 3(tap4.0) entered forwarding state
> [  673.990219] switch: port 3(tap4.0) entered forwarding state
> [  759.263762] switch: port 3(tap4.0) entered disabled state
> [  759.271529] device tap4.0 left promiscuous mode
> [  759.278257] switch: port 3(tap4.0) entered disabled state
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 18:34:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 18:34:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTGd8-0005aH-85; Tue, 30 Oct 2012 18:33:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTGd6-0005Zt-LX
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 18:33:37 +0000
Received: from [85.158.143.35:25672] by server-1.bemta-4.messagelabs.com id
	E4/D5-19134-08D10905; Tue, 30 Oct 2012 18:33:36 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1351622015!4629687!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2104 invoked from network); 30 Oct 2012 18:33:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 18:33:35 -0000
X-IronPort-AV: E=Sophos;i="4.80,682,1344211200"; d="scan'208";a="15497723"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 18:33:17 +0000
Received: from [192.168.1.30] (10.31.3.235) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 30 Oct 2012 18:33:16 +0000
Message-ID: <50901D6C.6020500@citrix.com>
Date: Tue, 30 Oct 2012 19:33:16 +0100
From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk 
References: <1351097925-26221-1-git-send-email-roger.pau@citrix.com>
	<20121030170157.GA29485@phenom.dumpdata.com>
In-Reply-To: <20121030170157.GA29485@phenom.dumpdata.com>
Cc: "linux-kernel@vger.kernel.org" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH v2] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 30/10/12 18:01, Konrad Rzeszutek Wilk wrote:
> On Wed, Oct 24, 2012 at 06:58:45PM +0200, Roger Pau Monne wrote:
>> This patch implements persistent grants for the xen-blk{front,back}
>> mechanism. The effect of this change is to reduce the number of unmap
>> operations performed, since they cause a (costly) TLB shootdown. This
>> allows the I/O performance to scale better when a large number of VMs
>> are performing I/O.
>>
>> Previously, the blkfront driver was supplied a bvec[] from the request
>> queue. This was granted to dom0; dom0 performed the I/O and wrote
>> directly into the grant-mapped memory and unmapped it; blkfront then
>> removed foreign access for that grant. The cost of unmapping scales
>> badly with the number of CPUs in Dom0. An experiment showed that when
>> Dom0 has 24 VCPUs, and guests are performing parallel I/O to a
>> ramdisk, the IPIs from performing unmap's is a bottleneck at 5 guests
>> (at which point 650,000 IOPS are being performed in total). If more
>> than 5 guests are used, the performance declines. By 10 guests, only
>> 400,000 IOPS are being performed.
>>
>> This patch improves performance by only unmapping when the connection
>> between blkfront and back is broken.
>>
>> On startup blkfront notifies blkback that it is using persistent
>> grants, and blkback will do the same. If blkback is not capable of
>> persistent mapping, blkfront will still use the same grants, since it
>> is compatible with the previous protocol, and simplifies the code
>> complexity in blkfront.
>>
>> To perform a read, in persistent mode, blkfront uses a separate pool
>> of pages that it maps to dom0. When a request comes in, blkfront
>> transmutes the request so that blkback will write into one of these
>> free pages. Blkback keeps note of which grefs it has already
>> mapped. When a new ring request comes to blkback, it looks to see if
>> it has already mapped that page. If so, it will not map it again. If
>> the page hasn't been previously mapped, it is mapped now, and a record
>> is kept of this mapping. Blkback proceeds as usual. When blkfront is
>> notified that blkback has completed a request, it memcpy's from the
>> shared memory, into the bvec supplied. A record that the {gref, page}
>> tuple is mapped, and not inflight is kept.
>>
>> Writes are similar, except that the memcpy is peformed from the
>> supplied bvecs, into the shared pages, before the request is put onto
>> the ring.
>>
>> Blkback stores a mapping of grefs=>{page mapped to by gref} in
>> a red-black tree. As the grefs are not known apriori, and provide no
>> guarantees on their ordering, we have to perform a search
>> through this tree to find the page, for every gref we receive. This
>> operation takes O(log n) time in the worst case. In blkfront grants
>> are stored using a single linked list.
>>
>> The maximum number of grants that blkback will persistenly map is
>> currently set to RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, to
>> prevent a malicios guest from attempting a DoS, by supplying fresh
>> grefs, causing the Dom0 kernel to map excessively. If a guest
>> is using persistent grants and exceeds the maximum number of grants to
>> map persistenly the newly passed grefs will be mapped and unmaped.
>> Using this approach, we can have requests that mix persistent and
>> non-persistent grants, and we need to handle them correctly.
>> This allows us to set the maximum number of persistent grants to a
>> lower value than RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, although
>> setting it will lead to unpredictable performance.
>>
>> In writing this patch, the question arrises as to if the additional
>> cost of performing memcpys in the guest (to/from the pool of granted
>> pages) outweigh the gains of not performing TLB shootdowns. The answer
>> to that question is `no'. There appears to be very little, if any
>> additional cost to the guest of using persistent grants. There is
>> perhaps a small saving, from the reduced number of hypercalls
>> performed in granting, and ending foreign access.
>>
>> Signed-off-by: Oliver Chick 
>> Signed-off-by: Roger Pau Monne 
>> Cc: 
>> Cc: 
>> ---
>> Changes since v1:
>>  * Changed the unmap_seg array to a bitmap.
>>  * Only report using persistent grants in blkfront if blkback supports
>>    it.
>>  * Reword some comments.
>>  * Fix a bug when setting the handler, index j was not incremented
>>    correctly.
>>  * Check that the tree of grants in blkback is not empty before
>>    iterating over it when doing the cleanup.
>>  * Rebase on top of linux-net.
> 
> I fixed the 'new_map = [1|0]' you had in and altered it to use 'true'
> or 'false', but when running some tests (with a 64-bit PV guest) I got it
> to bug.

Thanks for the testing. I'm going to rebase on top of your linux-next
branch and see if I can reproduce it. Did you run any kind of specific
test/benchmark? I've been running with this patch for a long time (on
top of your previous linux-next branch), and I haven't been able to get
it to bug.

> [    0.000000] Initializing cgroup subsys cpuset
> [    0.000000] Initializing cgroup subsys cpu
> [    0.000000] Linux version 3.7.0-rc3upstream-00220-g37b7153 (konrad@build.dumpdata.com) (gcc version 4.4.4 20100503 (Red Hat 4.4.4-2) (GCC) ) #1 SMP Tue Oct 30 12:15:12 EDT 2012
> [    0.000000] Command line: earlyprintk=xen debug nofb console=tty console=ttyS1,115200n8 xen-pciback.hide=(00:02:00) loglevel=10
> [    0.000000] Freeing 9d-100 pfn range: 99 pages freed
> [    0.000000] 1-1 mapping on 9d->100
> [    0.000000] 1-1 mapping on cf7fb->cfb63
> [    0.000000] 1-1 mapping on cfd15->cfd70
> [    0.000000] 1-1 mapping on cfd71->cfef7
> [    0.000000] 1-1 mapping on cff00->100001
> [    0.000000] Released 99 pages of unused memory
> [    0.000000] Set 198317 page(s) to 1-1 mapping
> [    0.000000] Populating 3e700-3e763 pfn range: 99 pages added
> [    0.000000] e820: BIOS-provided physical RAM map:
> [    0.000000] Xen: [mem 0x0000000000000000-0x000000000009cfff] usable
> [    0.000000] Xen: [mem 0x000000000009d800-0x00000000000fffff] reserved
> [    0.000000] Xen: [mem 0x0000000000100000-0x000000004d062fff] usable
> [    0.000000] Xen: [mem 0x000000004d063000-0x00000000cf7fafff] unusable
> [    0.000000] Xen: [mem 0x00000000cf7fb000-0x00000000cf95ffff] reserved
> [    0.000000] Xen: [mem 0x00000000cf960000-0x00000000cfb62fff] ACPI NVS
> [    0.000000] Xen: [mem 0x00000000cfb63000-0x00000000cfd14fff] unusable
> [    0.000000] Xen: [mem 0x00000000cfd15000-0x00000000cfd61fff] ACPI NVS
> [    0.000000] Xen: [mem 0x00000000cfd62000-0x00000000cfd6cfff] ACPI data
> [    0.000000] Xen: [mem 0x00000000cfd6d000-0x00000000cfd6ffff] ACPI NVS
> [    0.000000] Xen: [mem 0x00000000cfd70000-0x00000000cfd70fff] unusable
> [    0.000000] Xen: [mem 0x00000000cfd71000-0x00000000cfea8fff] reserved
> [    0.000000] Xen: [mem 0x00000000cfea9000-0x00000000cfeb9fff] ACPI NVS
> [    0.000000] Xen: [mem 0x00000000cfeba000-0x00000000cfecafff] reserved
> [    0.000000] Xen: [mem 0x00000000cfecb000-0x00000000cfecbfff] ACPI NVS
> [    0.000000] Xen: [mem 0x00000000cfecc000-0x00000000cfedbfff] reserved
> [    0.000000] Xen: [mem 0x00000000cfedc000-0x00000000cfedcfff] ACPI NVS
> [    0.000000] Xen: [mem 0x00000000cfedd000-0x00000000cfeddfff] reserved
> [    0.000000] Xen: [mem 0x00000000cfede000-0x00000000cfee3fff] ACPI NVS
> [    0.000000] Xen: [mem 0x00000000cfee4000-0x00000000cfef6fff] reserved
> [    0.000000] Xen: [mem 0x00000000cfef7000-0x00000000cfefffff] unusable
> [    0.000000] Xen: [mem 0x00000000e0000000-0x00000000efffffff] reserved
> [    0.000000] Xen: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
> [    0.000000] Xen: [mem 0x00000000fec10000-0x00000000fec10fff] reserved
> [    0.000000] Xen: [mem 0x00000000fed00000-0x00000000fed00fff] reserved
> [    0.000000] Xen: [mem 0x00000000fed40000-0x00000000fed44fff] reserved
> [    0.000000] Xen: [mem 0x00000000fed61000-0x00000000fed70fff] reserved
> [    0.000000] Xen: [mem 0x00000000fed80000-0x00000000fed8ffff] reserved
> [    0.000000] Xen: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
> [    0.000000] Xen: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
> [    0.000000] Xen: [mem 0x0000000100001000-0x000000020effffff] unusable
> [    0.000000] bootconsole [xenboot0] enabled
> [    0.000000] NX (Execute Disable) protection: active
> [    0.000000] DMI 2.6 present.
> [    0.000000] DMI: System manufacturer System Product Name/F1A75-M, BIOS 0406 06/11/2011
> [    0.000000] e820: update [mem 0x00000000-0x0000ffff] usable ==> reserved
> [    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
> [    0.000000] No AGP bridge found
> [    0.000000] e820: last_pfn = 0x4d063 max_arch_pfn = 0x400000000
> [    0.000000] initial memory mapped: [mem 0x00000000-0x16bcdfff]
> [    0.000000] Base memory trampoline at [ffff880000097000] 97000 size 24576
> [    0.000000] init_memory_mapping: [mem 0x00000000-0x4d062fff]
> [    0.000000]  [mem 0x00000000-0x4d062fff] page 4k
> [    0.000000] kernel direct mapping tables up to 0x4d062fff @ [mem 0x01e21000-0x0208cfff]
> [    0.000000] xen: setting RW the range 1fd3000 - 208d000
> [    0.000000] RAMDISK: [mem 0x0208d000-0x16bcdfff]
> [    0.000000] ACPI: RSDP 00000000000f0450 00024 (v02 ALASKA)
> [    0.000000] ACPI: XSDT 00000000cfd62068 00054 (v01 ALASKA    A M I 01072009 AMI  00010013)
> [    0.000000] ACPI: FACP 00000000cfd69a68 000F4 (v04 ALASKA    A M I 01072009 AMI  00010013)
> [    0.000000] ACPI BIOS Bug: Warning: Optional FADT field Pm2ControlBlock has zero address or length: 0x0000000000000000/0x1 (20120913/tbfadt-598)
> [    0.000000] ACPI: DSDT 00000000cfd62150 07917 (v02 ALASKA    A M I 00000000 INTL 20051117)
> [    0.000000] ACPI: FACS 00000000cfedef80 00040
> [    0.000000] ACPI: APIC 00000000cfd69b60 00072 (v03 ALASKA    A M I 01072009 AMI  00010013)
> [    0.000000] ACPI: MCFG 00000000cfd69bd8 0003C (v01 A M I  GMCH945. 01072009 MSFT 00000097)
> [    0.000000] ACPI: HPET 00000000cfd69c18 00038 (v01 ALASKA    A M I 01072009 AMI  00000004)
> [    0.000000] ACPI: SSDT 00000000cfd69c50 00FD8 (v01 AMD    POWERNOW 00000001 AMD  00000001)
> [    0.000000] ACPI: SSDT 00000000cfd6ac28 01923 (v02    AMD     ALIB 00000001 MSFT 04000000)
> [    0.000000] ACPI: Local APIC address 0xfee00000
> [    0.000000] NUMA turned off
> [    0.000000] Faking a node at [mem 0x0000000000000000-0x000000004d062fff]
> [    0.000000] Initmem setup node 0 [mem 0x00000000-0x4d062fff]
> [    0.000000]   NODE_DATA [mem 0x3e75f000-0x3e762fff]
> [    0.000000] Zone ranges:
> [    0.000000]   DMA      [mem 0x00010000-0x00ffffff]
> [    0.000000]   DMA32    [mem 0x01000000-0xffffffff]
> [    0.000000]   Normal   empty
> [    0.000000] Movable zone start for each node
> [    0.000000] Early memory node ranges
> [    0.000000]   node   0: [mem 0x00010000-0x0009cfff]
> [    0.000000]   node   0: [mem 0x00100000-0x4d062fff]
> [    0.000000] On node 0 totalpages: 315376
> [    0.000000]   DMA zone: 56 pages used for memmap
> [    0.000000]   DMA zone: 6 pages reserved
> [    0.000000]   DMA zone: 3919 pages, LIFO batch:0
> [    0.000000]   DMA32 zone: 4258 pages used for memmap
> [    0.000000]   DMA32 zone: 307137 pages, LIFO batch:31
> [    0.000000] ACPI: PM-Timer IO Port: 0x808
> [    0.000000] ACPI: Local APIC address 0xfee00000
> [    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)
> [    0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])
> [    0.000000] ACPI: IOAPIC (id[0x05] address[0xfec00000] gsi_base[0])
> [    0.000000] IOAPIC[0]: apic_id 5, version 33, address 0xfec00000, GSI 0-23
> [    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
> [    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
> [    0.000000] ACPI: IRQ0 used by override.
> [    0.000000] ACPI: IRQ2 used by override.
> [    0.000000] ACPI: IRQ9 used by override.
> [    0.000000] Using ACPI (MADT) for SMP configuration information
> [    0.000000] ACPI: HPET id: 0xffffffff base: 0xfed00000
> [    0.000000] smpboot: Allowing 4 CPUs, 0 hotplug CPUs
> [    0.000000] nr_irqs_gsi: 40
> [    0.000000] PM: Registered nosave memory: 000000000009d000 - 000000000009e000
> [    0.000000] PM: Registered nosave memory: 000000000009e000 - 0000000000100000
> [    0.000000] e820: [mem 0xcff00000-0xdfffffff] available for PCI devices
> [    0.000000] Booting paravirtualized kernel on Xen
> [    0.000000] Xen version: 4.1.4-pre (preserve-AD)
> [    0.000000] setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:4 nr_node_ids:1
> [    0.000000] PERCPU: Embedded 28 pages/cpu @ffff88003e000000 s84288 r8192 d22208 u524288
> [    0.000000] pcpu-alloc: s84288 r8192 d22208 u524288 alloc=1*2097152
> [    0.000000] pcpu-alloc: [0] 0 1 2 3
> [    2.763208] Built 1 zonelists in Node order, mobility grouping on.  Total pages: 311056
> [    2.763213] Policy zone: DMA32
> [    2.763218] Kernel command line: earlyprintk=xen debug nofb console=tty console=ttyS1,115200n8 xen-pciback.hide=(00:02:00) loglevel=10
> [    2.763656] PID hash table entries: 4096 (order: 3, 32768 bytes)
> [    2.763663] __ex_table already sorted, skipping sort
> [    2.808064] software IO TLB [mem 0x38a00000-0x3ca00000] (64MB) mapped at [ffff880038a00000-ffff88003c9fffff]
> [    2.811300] Memory: 581728k/1261964k available (6413k kernel code, 460k absent, 679776k reserved, 4478k data, 752k init)
> [    2.811414] Hierarchical RCU implementation.
> [    2.811419]  RCU restricting CPUs from NR_CPUS=512 to nr_cpu_ids=3.
> [    2.811432] NR_IRQS:33024 nr_irqs:704 16
> [    2.811514] xen: sci override: global_irq=9 trigger=0 polarity=1
> [    2.811518] xen: registering gsi 9 triggering 0 polarity 1
> [    2.811531] xen: --> pirq=9 -> irq=9 (gsi=9)
> [    2.811539] xen: acpi sci 9
> [    2.811546] xen: --> pirq=1 -> irq=1 (gsi=1)
> [    2.811551] xen: --> pirq=2 -> irq=2 (gsi=2)
> [    2.811557] xen: --> pirq=3 -> irq=3 (gsi=3)
> [    2.811562] xen: --> pirq=4 -> irq=4 (gsi=4)
> [    2.811568] xen: --> pirq=5 -> irq=5 (gsi=5)
> [    2.811574] xen: --> pirq=6 -> irq=6 (gsi=6)
> [    2.811579] xen: --> pirq=7 -> irq=7 (gsi=7)
> [    2.811585] xen: --> pirq=8 -> irq=8 (gsi=8)
> [    2.811590] xen: --> pirq=10 -> irq=10 (gsi=10)
> [    2.811596] xen: --> pirq=11 -> irq=11 (gsi=11)
> [    2.811602] xen: --> pirq=12 -> irq=12 (gsi=12)
> [    2.811607] xen: --> pirq=13 -> irq=13 (gsi=13)
> [    2.811613] xen: --> pirq=14 -> irq=14 (gsi=14)
> [    2.811618] xen: --> pirq=15 -> irq=15 (gsi=15)
> [    2.813454] Console: colour VGA+ 80x25
> [    2.818363] console [tty0] enabled
> [    2.818422] console [ttyS1] enabled, bootconsole disabled
> [    2.818757] Xen: using vcpuop timer interface
> [    2.819017] installing Xen timer for CPU 0
> [    2.819285] tsc: Detected 2899.980 MHz processor
> [    2.819555] Calibrating delay loop (skipped), value calculated using timer frequency.. 5799.96 BogoMIPS (lpj=2899980)
> [    2.820151] pid_max: default: 32768 minimum: 301
> [    2.820479] Security Framework initialized
> [    2.820728] SELinux:  Initializing.
> [    2.820948] SELinux:  Starting in permissive mode
> [    2.821532] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
> [    2.822565] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
> [    2.823519] Mount-cache hash table entries: 256
> [    2.824126] Initializing cgroup subsys cpuacct
> [    2.824400] Initializing cgroup subsys freezer
> [    2.824730] tseg: 00cff00000
> [    2.824934] CPU: Physical Processor ID: 0
> [    2.825186] CPU: Processor Core ID: 0
> [    2.825417] mce: CPU supports 6 MCE banks
> [    2.825696] Last level iTLB entries: 4KB 512, 2MB 16, 4MB 8
> [    2.825696] Last level dTLB entries: 4KB 1024, 2MB 128, 4MB 64
> [    2.825696] tlb_flushall_shift: 5
> [    2.826625] Freeing SMP alternatives: 24k freed
> [    2.829704] ACPI: Core revision 20120913
> [    2.856787] cpu 0 spinlock event irq 41
> [    2.857062] Performance Events: Broken PMU hardware detected, using software events only.
> [    2.857602] Failed to access perfctr msr (MSR c0010004 is 0)
> [    2.858234] MCE: In-kernel MCE decoding enabled.
> [    2.858603] NMI watchdog: disabled (cpu0): hardware events not enabled
> [    2.859223] installing Xen timer for CPU 1
> [    2.859499] cpu 1 spinlock event irq 48
> [    2.860218] installing Xen timer for CPU 2
> [    2.860493] cpu 2 spinlock event irq 55
> [    2.860951] Brought up 3 CPUs
> [    2.864412] PM: Registering ACPI NVS region [mem 0xcf960000-0xcfb62fff] (2109440 bytes)
> [    2.865989] PM: Registering ACPI NVS region [mem 0xcfd15000-0xcfd61fff] (315392 bytes)
> [    2.866464] PM: Registering ACPI NVS region [mem 0xcfd6d000-0xcfd6ffff] (12288 bytes)
> [    2.866931] PM: Registering ACPI NVS region [mem 0xcfea9000-0xcfeb9fff] (69632 bytes)
> [    2.867404] PM: Registering ACPI NVS region [mem 0xcfecb000-0xcfecbfff] (4096 bytes)
> [    2.867861] PM: Registering ACPI NVS region [mem 0xcfedc000-0xcfedcfff] (4096 bytes)
> [    2.868321] PM: Registering ACPI NVS region [mem 0xcfede000-0xcfee3fff] (24576 bytes)
> [    2.869081] kworker/u:0 (26) used greatest stack depth: 6120 bytes left
> [    2.869105] Grant tables using version 2 layout.
> [    2.869122] Grant table initialized
> [    2.869164] RTC time: 16:43:55, date: 10/30/12
> [    2.870366] NET: Registered protocol family 16
> [    2.871181] kworker/u:0 (30) used greatest stack depth: 5504 bytes left
> [    2.872440] ACPI: bus type pci registered
> [    2.873480] dca service started, version 1.12.1
> [    2.873891] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000)
> [    2.874438] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in E820
> [    2.914335] PCI: Using configuration type 1 for base access
> [    2.932999] bio: create slab  at 0
> [    2.933584] ACPI: Added _OSI(Module Device)
> [    2.933866] ACPI: Added _OSI(Processor Device)
> [    2.934145] ACPI: Added _OSI(3.0 _SCP Extensions)
> [    2.934432] ACPI: Added _OSI(Processor Aggregator Device)
> [    2.942011] ACPI: EC: Look up EC in DSDT
> [    2.950054] ACPI: Executed 1 blocks of module-level executable AML code
> [    2.956530] ACPI: Interpreter enabled
> [    2.956772] ACPI: (supports S0 S3 S4 S5)
> [    2.957218] ACPI: Using IOAPIC for interrupt routing
> [    2.982389] ACPI: No dock devices found.
> [    2.982650] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
> [    2.983552] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
> [    2.984298] PCI host bridge to bus 0000:00
> [    2.984571] pci_bus 0000:00: root bus resource [bus 00-ff]
> [    2.984906] pci_bus 0000:00: root bus resource [io  0x0000-0x03af]
> [    2.985277] pci_bus 0000:00: root bus resource [io  0x03e0-0x0cf7]
> [    2.985657] pci_bus 0000:00: root bus resource [io  0x03b0-0x03df]
> [    2.986029] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
> [    2.986399] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
> [    2.986810] pci_bus 0000:00: root bus resource [mem 0x000c0000-0x000dffff]
> [    2.987214] pci_bus 0000:00: root bus resource [mem 0xd0000000-0xffffffff]
> [    2.987631] pci 0000:00:00.0: [1022:1705] type 00 class 0x060000
> [    2.988106] pci 0000:00:01.0: [1002:9640] type 00 class 0x030000
> [    2.988487] pci 0000:00:01.0: reg 10: [mem 0xd0000000-0xdfffffff pref]
> [    2.988893] pci 0000:00:01.0: reg 14: [io  0xf000-0xf0ff]
> [    2.989246] pci 0000:00:01.0: reg 18: [mem 0xfeb00000-0xfeb3ffff]
> [    2.989743] pci 0000:00:01.0: supports D1 D2
> [    2.990053] pci 0000:00:01.1: [1002:1714] type 00 class 0x040300
> [    2.990442] pci 0000:00:01.1: reg 10: [mem 0xfeb44000-0xfeb47fff]
> [    2.990965] pci 0000:00:01.1: supports D1 D2
> [    2.991343] pci 0000:00:10.0: [1022:7812] type 00 class 0x0c0330
> [    2.991752] pci 0000:00:10.0: reg 10: [mem 0xfeb4a000-0xfeb4bfff 64bit]
> [    2.992355] pci 0000:00:10.0: PME# supported from D0 D3hot D3cold
> [    2.992803] pci 0000:00:10.1: [1022:7812] type 00 class 0x0c0330
> [    2.993201] pci 0000:00:10.1: reg 10: [mem 0xfeb48000-0xfeb49fff 64bit]
> [    2.993793] pci 0000:00:10.1: PME# supported from D0 D3hot D3cold
> [    2.994239] pci 0000:00:11.0: [1022:7801] type 00 class 0x010601
> [    2.994637] pci 0000:00:11.0: reg 10: [io  0xf140-0xf147]
> [    2.994982] pci 0000:00:11.0: reg 14: [io  0xf130-0xf133]
> [    2.995333] pci 0000:00:11.0: reg 18: [io  0xf120-0xf127]
> [    2.995678] pci 0000:00:11.0: reg 1c: [io  0xf110-0xf113]
> [    2.996024] pci 0000:00:11.0: reg 20: [io  0xf100-0xf10f]
> [    2.996374] pci 0000:00:11.0: reg 24: [mem 0xfeb51000-0xfeb517ff]
> [    2.996850] pci 0000:00:12.0: [1022:7807] type 00 class 0x0c0310
> [    2.997235] pci 0000:00:12.0: reg 10: [mem 0xfeb50000-0xfeb50fff]
> [    2.997765] pci 0000:00:12.2: [1022:7808] type 00 class 0x0c0320
> [    2.998161] pci 0000:00:12.2: reg 10: [mem 0xfeb4f000-0xfeb4f0ff]
> [    2.998712] pci 0000:00:12.2: supports D1 D2
> [    2.998977] pci 0000:00:12.2: PME# supported from D0 D1 D2 D3hot
> [    2.999375] pci 0000:00:13.0: [1022:7807] type 00 class 0x0c0310
> [    2.999768] pci 0000:00:13.0: reg 10: [mem 0xfeb4e000-0xfeb4efff]
> [    3.000283] pci 0000:00:13.2: [1022:7808] type 00 class 0x0c0320
> [    3.000681] pci 0000:00:13.2: reg 10: [mem 0xfeb4d000-0xfeb4d0ff]
> [    3.001227] pci 0000:00:13.2: supports D1 D2
> [    3.001495] pci 0000:00:13.2: PME# supported from D0 D1 D2 D3hot
> [    3.001902] pci 0000:00:14.0: [1022:780b] type 00 class 0x0c0500
> [    3.002433] pci 0000:00:14.2: [1022:780d] type 00 class 0x040300
> [    3.002840] pci 0000:00:14.2: reg 10: [mem 0xfeb40000-0xfeb43fff 64bit]
> [    3.003376] pci 0000:00:14.2: PME# supported from D0 D3hot D3cold
> [    3.003761] pci 0000:00:14.3: [1022:780e] type 00 class 0x060100
> [    3.004279] pci 0000:00:14.4: [1022:780f] type 01 class 0x060401
> [    3.004730] pci 0000:00:14.5: [1022:7809] type 00 class 0x0c0310
> [    3.005119] pci 0000:00:14.5: reg 10: [mem 0xfeb4c000-0xfeb4cfff]
> [    3.005641] pci 0000:00:15.0: [1022:43a0] type 01 class 0x060400
> [    3.006187] pci 0000:00:15.0: supports D1 D2
> [    3.006515] pci 0000:00:15.1: [1022:43a1] type 01 class 0x060400
> [    3.007059] pci 0000:00:15.1: supports D1 D2
> [    3.007403] pci 0000:00:18.0: [1022:1700] type 00 class 0x060000
> [    3.007868] pci 0000:00:18.1: [1022:1701] type 00 class 0x060000
> [    3.008320] pci 0000:00:18.2: [1022:1702] type 00 class 0x060000
> [    3.008778] pci 0000:00:18.3: [1022:1703] type 00 class 0x060000
> [    3.009271] pci 0000:00:18.4: [1022:1704] type 00 class 0x060000
> [    3.009716] pci 0000:00:18.5: [1022:1718] type 00 class 0x060000
> [    3.010167] pci 0000:00:18.6: [1022:1716] type 00 class 0x060000
> [    3.010615] pci 0000:00:18.7: [1022:1719] type 00 class 0x060000
> [    3.011117] pci 0000:01:05.0: [9710:9835] type 00 class 0x070002
> [    3.011513] pci 0000:01:05.0: reg 10: [io  0xe050-0xe057]
> [    3.011861] pci 0000:01:05.0: reg 14: [io  0xe040-0xe047]
> [    3.012210] pci 0000:01:05.0: reg 18: [io  0xe030-0xe037]
> [    3.012563] pci 0000:01:05.0: reg 1c: [io  0xe020-0xe027]
> [    3.012912] pci 0000:01:05.0: reg 20: [io  0xe010-0xe017]
> [    3.013259] pci 0000:01:05.0: reg 24: [io  0xe000-0xe00f]
> [    3.013710] pci 0000:00:14.4: PCI bridge to [bus 01] (subtractive decode)
> [    3.014118] pci 0000:00:14.4:   bridge window [io  0xe000-0xefff]
> [    3.014496] pci 0000:00:14.4:   bridge window [io  0x0000-0x03af] (subtractive decode)
> [    3.014967] pci 0000:00:14.4:   bridge window [io  0x03e0-0x0cf7] (subtractive decode)
> [    3.015422] pci 0000:00:14.4:   bridge window [io  0x03b0-0x03df] (subtractive decode)
> [    3.015878] pci 0000:00:14.4:   bridge window [io  0x0d00-0xffff] (subtractive decode)
> [    3.016343] pci 0000:00:14.4:   bridge window [mem 0x000a0000-0x000bffff] (subtractive decode)
> [    3.016836] pci 0000:00:14.4:   bridge window [mem 0x000c0000-0x000dffff] (subtractive decode)
> [    3.017326] pci 0000:00:14.4:   bridge window [mem 0xd0000000-0xffffffff] (subtractive decode)
> [    3.017990] pci 0000:02:00.0: [8086:10d3] type 00 class 0x020000
> [    3.018379] pci 0000:02:00.0: reg 10: [mem 0xfeac0000-0xfeadffff]
> [    3.018769] pci 0000:02:00.0: reg 14: [mem 0xfea00000-0xfea7ffff]
> [    3.019167] pci 0000:02:00.0: reg 18: [io  0xd000-0xd01f]
> [    3.019522] pci 0000:02:00.0: reg 1c: [mem 0xfeae0000-0xfeae3fff]
> [    3.019964] pci 0000:02:00.0: reg 30: [mem 0xfea80000-0xfeabffff pref]
> [    3.020508] pci 0000:02:00.0: PME# supported from D0 D3hot D3cold
> [    3.023962] pci 0000:00:15.0: PCI bridge to [bus 02]
> [    3.024307] pci 0000:00:15.0:   bridge window [io  0xd000-0xdfff]
> [    3.024689] pci 0000:00:15.0:   bridge window [mem 0xfea00000-0xfeafffff]
> [    3.025293] pci 0000:03:00.0: [1969:1083] type 00 class 0x020000
> [    3.025712] pci 0000:03:00.0: reg 10: [mem 0xfe900000-0xfe93ffff 64bit]
> [    3.026139] pci 0000:03:00.0: reg 18: [io  0xc000-0xc07f]
> [    3.026691] pci 0000:03:00.0: PME# supported from D0 D1 D2 D3hot D3cold
> [    3.028949] pci 0000:00:15.1: PCI bridge to [bus 03]
> [    3.029290] pci 0000:00:15.1:   bridge window [io  0xc000-0xcfff]
> [    3.029671] pci 0000:00:15.1:   bridge window [mem 0xfe900000-0xfe9fffff]
> [    3.030148] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
> [    3.030844] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PE20._PRT]
> [    3.031280] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PE21._PRT]
> [    3.031782] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0PC._PRT]
> [    3.032377]  pci0000:00: Requesting ACPI _OSC control (0x1d)
> [    3.032947]  pci0000:00: ACPI _OSC control (0x1d) granted
> [    3.051344] ACPI: PCI Interrupt Link [LN24] (IRQs *24)
> [    3.051852] ACPI: PCI Interrupt Link [LN25] (IRQs *25)
> [    3.052329] ACPI: PCI Interrupt Link [LN26] (IRQs *26)
> [    3.052821] ACPI: PCI Interrupt Link [LN27] (IRQs *27)
> [    3.053298] ACPI: PCI Interrupt Link [LN28] (IRQs *28)
> [    3.053787] ACPI: PCI Interrupt Link [LN29] (IRQs *29)
> [    3.054271] ACPI: PCI Interrupt Link [LN30] (IRQs *30)
> [    3.054747] ACPI: PCI Interrupt Link [LN31] (IRQs *31)
> [    3.055243] ACPI: PCI Interrupt Link [LN32] (IRQs *32)
> [    3.055724] ACPI: PCI Interrupt Link [LN33] (IRQs *33)
> [    3.056211] ACPI: PCI Interrupt Link [LN34] (IRQs *34)
> [    3.056692] ACPI: PCI Interrupt Link [LN35] (IRQs *35)
> [    3.057187] ACPI: PCI Interrupt Link [LN36] (IRQs *36)
> [    3.057673] ACPI: PCI Interrupt Link [LN37] (IRQs *37)
> [    3.058165] ACPI: PCI Interrupt Link [LN38] (IRQs *38)
> [    3.058660] ACPI: PCI Interrupt Link [LN39] (IRQs *39)
> [    3.059154] ACPI: PCI Interrupt Link [LN40] (IRQs *40)
> [    3.059643] ACPI: PCI Interrupt Link [LN41] (IRQs *41)
> [    3.060128] ACPI: PCI Interrupt Link [LN42] (IRQs *42)
> [    3.060618] ACPI: PCI Interrupt Link [LN43] (IRQs *43)
> [    3.061095] ACPI: PCI Interrupt Link [LN44] (IRQs *44)
> [    3.061575] ACPI: PCI Interrupt Link [LN45] (IRQs *45)
> [    3.062059] ACPI: PCI Interrupt Link [LN46] (IRQs *46)
> [    3.062543] ACPI: PCI Interrupt Link [LN47] (IRQs *47)
> [    3.063029] ACPI: PCI Interrupt Link [LN48] (IRQs *48)
> [    3.063506] ACPI: PCI Interrupt Link [LN49] (IRQs *49)
> [    3.063989] ACPI: PCI Interrupt Link [LN50] (IRQs *50)
> [    3.064473] ACPI: PCI Interrupt Link [LN51] (IRQs *51)
> [    3.064950] ACPI: PCI Interrupt Link [LN52] (IRQs *52)
> [    3.065440] ACPI: PCI Interrupt Link [LN53] (IRQs *53)
> [    3.065918] ACPI: PCI Interrupt Link [LN54] (IRQs *54)
> [    3.066402] ACPI: PCI Interrupt Link [LN55] (IRQs *55)
> [    3.066889] ACPI: PCI Interrupt Link [LNKA] (IRQs 4 5 7 10 11 14 15) *0
> [    3.068826] ACPI: PCI Interrupt Link [LNKB] (IRQs 4 5 7 10 11 14 15) *0
> [    3.069717] ACPI: PCI Interrupt Link [LNKC] (IRQs 4 5 7 10 11 14 15) *0
> [    3.070606] ACPI: PCI Interrupt Link [LNKD] (IRQs 4 5 7 10 11 14 15) *0
> [    3.071479] ACPI: PCI Interrupt Link [LNKE] (IRQs 4 5 7 10 11 14 15) *0
> [    3.072339] ACPI: PCI Interrupt Link [LNKF] (IRQs 4 5 7 10 11 14 15) *0
> [    3.073195] ACPI: PCI Interrupt Link [LNKG] (IRQs 4 5 7 10 11 14 15) *0
> [    3.074064] ACPI: PCI Interrupt Link [LNKH] (IRQs 4 5 7 10 11 14 15) *0
> [    3.075123] xen/balloon: Initialising balloon driver.
> [    3.076280] xen-balloon: Initialising balloon driver.
> [    3.076885] xen/balloon: Xen selfballooning driver disabled for domain0.
> [    3.077545] vgaarb: device added: PCI:0000:00:01.0,decodes=io+mem,owns=io+mem,locks=none
> [    3.078080] vgaarb: loaded
> [    3.078268] vgaarb: bridge control possible 0000:00:01.0
> [    3.078970] ACPI: bus type usb registered
> [    3.079409] usbcore: registered new interface driver usbfs
> [    3.079813] usbcore: registered new interface driver hub
> [    3.080257] usbcore: registered new device driver usb
> [    3.081098] PCI: Using ACPI for IRQ routing
> [    3.098106] PCI: pci_cache_line_size set to 64 bytes
> [    3.098606] e820: reserve RAM buffer [mem 0x0009d000-0x0009ffff]
> [    3.098972] e820: reserve RAM buffer [mem 0x4d063000-0x4fffffff]
> [    3.099810] NetLabel: Initializing
> [    3.100040] NetLabel:  domain hash size = 128
> [    3.100313] NetLabel:  protocols = UNLABELED CIPSOv4
> [    3.100639] NetLabel:  unlabeled traffic allowed by default
> [    3.101361] Switching to clocksource xen
> [    3.109135] pnp: PnP ACPI init
> [    3.109362] ACPI: bus type pnp registered
> [    3.109832] pnp 00:00: [bus 00-ff]
> [    3.110058] pnp 00:00: [io  0x0cf8-0x0cff]
> [    3.110319] pnp 00:00: [io  0x0000-0x03af window]
> [    3.110611] pnp 00:00: [io  0x03e0-0x0cf7 window]
> [    3.110912] pnp 00:00: [io  0x03b0-0x03df window]
> [    3.111200] pnp 00:00: [io  0x0d00-0xffff window]
> [    3.111492] pnp 00:00: [mem 0x000a0000-0x000bffff window]
> [    3.111826] pnp 00:00: [mem 0x000c0000-0x000dffff window]
> [    3.112154] pnp 00:00: [mem 0xd0000000-0xffffffff window]
> [    3.112482] pnp 00:00: [mem 0x00000000 window]
> [    3.113097] pnp 00:00: Plug and Play ACPI device, IDs PNP0a03 (active)
> [    3.113537] pnp 00:01: [mem 0xe0000000-0xefffffff]
> [    3.114213] system 00:01: [mem 0xe0000000-0xefffffff] has been reserved
> [    3.114626] system 00:01: Plug and Play ACPI device, IDs PNP0c01 (active)
> [    3.116690] pnp 00:02: [io  0x0010-0x001f]
> [    3.116955] pnp 00:02: [io  0x0022-0x003f]
> [    3.117210] pnp 00:02: [io  0x0063]
> [    3.117439] pnp 00:02: [io  0x0065]
> [    3.117667] pnp 00:02: [io  0x0067-0x006f]
> [    3.117932] pnp 00:02: [io  0x0072-0x007f]
> [    3.118191] pnp 00:02: [io  0x0080]
> [    3.118415] pnp 00:02: [io  0x0084-0x0086]
> [    3.118668] pnp 00:02: [io  0x0088]
> [    3.118910] pnp 00:02: [io  0x008c-0x008e]
> [    3.119174] pnp 00:02: [io  0x0090-0x009f]
> [    3.119436] pnp 00:02: [io  0x00a2-0x00bf]
> [    3.119706] pnp 00:02: [io  0x00b1]
> [    3.119936] pnp 00:02: [io  0x00e0-0x00ef]
> [    3.120194] pnp 00:02: [io  0x04d0-0x04d1]
> [    3.120455] pnp 00:02: [io  0x040b]
> [    3.120683] pnp 00:02: [io  0x04d6]
> [    3.120916] pnp 00:02: [io  0x0c00-0x0c01]
> [    3.121172] pnp 00:02: [io  0x0c14]
> [    3.121397] pnp 00:02: [io  0x0c50-0x0c51]
> [    3.121653] pnp 00:02: [io  0x0c52]
> [    3.121885] pnp 00:02: [io  0x0c6c]
> [    3.122109] pnp 00:02: [io  0x0c6f]
> [    3.122335] pnp 00:02: [io  0x0cd0-0x0cd1]
> [    3.122591] pnp 00:02: [io  0x0cd2-0x0cd3]
> [    3.122860] pnp 00:02: [io  0x0cd4-0x0cd5]
> [    3.123120] pnp 00:02: [io  0x0cd6-0x0cd7]
> [    3.123377] pnp 00:02: [io  0x0cd8-0x0cdf]
> [    3.123633] pnp 00:02: [io  0x0800-0x089f]
> [    3.123898] pnp 00:02: [io  0x0000-0xffffffffffffffff disabled]
> [    3.124249] pnp 00:02: [io  0x0000-0x000f]
> [    3.124506] pnp 00:02: [io  0x0b20-0x0b3f]
> [    3.124768] pnp 00:02: [io  0x0900-0x090f]
> [    3.125026] pnp 00:02: [io  0x0910-0x091f]
> [    3.125282] pnp 00:02: [io  0xfe00-0xfefe]
> [    3.125537] pnp 00:02: [io  0x0060-0x005f disabled]
> [    3.125841] pnp 00:02: [io  0x0064-0x0063 disabled]
> [    3.126136] pnp 00:02: [mem 0xfec00000-0xfec00fff]
> [    3.126426] pnp 00:02: [mem 0xfee00000-0xfee00fff]
> [    3.126724] pnp 00:02: [mem 0xfed80000-0xfed8ffff]
> [    3.127024] pnp 00:02: [mem 0xfed61000-0xfed70fff]
> [    3.127321] pnp 00:02: [mem 0xfec10000-0xfec10fff]
> [    3.127619] pnp 00:02: [mem 0xfed00000-0xfed00fff]
> [    3.127920] pnp 00:02: [mem 0xff000000-0xffffffff]
> [    3.128629] system 00:02: [io  0x04d0-0x04d1] has been reserved
> [    3.129033] system 00:02: [io  0x040b] has been reserved
> [    3.129358] system 00:02: [io  0x04d6] has been reserved
> [    3.129680] system 00:02: [io  0x0c00-0x0c01] has been reserved
> [    3.130042] system 00:02: [io  0x0c14] has been reserved
> [    3.130365] system 00:02: [io  0x0c50-0x0c51] has been reserved
> [    3.130727] system 00:02: [io  0x0c52] has been reserved
> [    3.131046] system 00:02: [io  0x0c6c] has been reserved
> [    3.131369] system 00:02: [io  0x0c6f] has been reserved
> [    3.131692] system 00:02: [io  0x0cd0-0x0cd1] has been reserved
> [    3.132047] system 00:02: [io  0x0cd2-0x0cd3] has been reserved
> [    3.132401] system 00:02: [io  0x0cd4-0x0cd5] has been reserved
> [    3.132756] system 00:02: [io  0x0cd6-0x0cd7] has been reserved
> [    3.133111] system 00:02: [io  0x0cd8-0x0cdf] has been reserved
> [    3.133460] system 00:02: [io  0x0800-0x089f] has been reserved
> [    3.133814] system 00:02: [io  0x0b20-0x0b3f] has been reserved
> [    3.134168] system 00:02: [io  0x0900-0x090f] has been reserved
> [    3.134524] system 00:02: [io  0x0910-0x091f] has been reserved
> [    3.134888] system 00:02: [io  0xfe00-0xfefe] has been reserved
> [    3.135250] system 00:02: [mem 0xfec00000-0xfec00fff] could not be reserved
> [    3.135651] system 00:02: [mem 0xfee00000-0xfee00fff] has been reserved
> [    3.136053] system 00:02: [mem 0xfed80000-0xfed8ffff] has been reserved
> [    3.136437] system 00:02: [mem 0xfed61000-0xfed70fff] has been reserved
> [    3.136829] system 00:02: [mem 0xfec10000-0xfec10fff] has been reserved
> [    3.137219] system 00:02: [mem 0xfed00000-0xfed00fff] has been reserved
> [    3.137608] system 00:02: [mem 0xff000000-0xffffffff] has been reserved
> [    3.138015] system 00:02: Plug and Play ACPI device, IDs PNP0c02 (active)
> [    3.138611] pnp 00:03: [io  0x0000-0xffffffffffffffff disabled]
> [    3.138981] pnp 00:03: [io  0x0300-0x031f]
> [    3.139249] pnp 00:03: [io  0x0290-0x029f]
> [    3.139512] pnp 00:03: [io  0x0230-0x023f]
> [    3.140070] system 00:03: [io  0x0300-0x031f] has been reserved
> [    3.140431] system 00:03: [io  0x0290-0x029f] has been reserved
> [    3.140800] system 00:03: [io  0x0230-0x023f] has been reserved
> [    3.141165] system 00:03: Plug and Play ACPI device, IDs PNP0c02 (active)
> [    3.141595] pnp 00:04: [dma 4]
> [    3.141809] pnp 00:04: [io  0x0000-0x000f]
> [    3.142070] pnp 00:04: [io  0x0081-0x0083]
> [    3.142330] pnp 00:04: [io  0x0087]
> [    3.142557] pnp 00:04: [io  0x0089-0x008b]
> [    3.142825] pnp 00:04: [io  0x008f]
> [    3.143052] pnp 00:04: [io  0x00c0-0x00df]
> [    3.143532] pnp 00:04: Plug and Play ACPI device, IDs PNP0200 (active)
> [    3.143961] pnp 00:05: [io  0x0070-0x0071]
> [    3.144222] xen: registering gsi 8 triggering 1 polarity 0
> [    3.144562] pnp 00:05: [irq 8]
> [    3.145001] pnp 00:05: Plug and Play ACPI device, IDs PNP0b00 (active)
> [    3.145408] pnp 00:06: [io  0x0061]
> [    3.145932] pnp 00:06: Plug and Play ACPI device, IDs PNP0800 (active)
> [    3.146422] pnp 00:07: [io  0x0010-0x001f]
> [    3.146682] pnp 00:07: [io  0x0022-0x003f]
> [    3.146977] pnp 00:07: [io  0x0044-0x005f]
> [    3.147238] pnp 00:07: [io  0x0072-0x007f]
> [    3.147491] pnp 00:07: [io  0x0080]
> [    3.147722] pnp 00:07: [io  0x0084-0x0086]
> [    3.147980] pnp 00:07: [io  0x0088]
> [    3.148211] pnp 00:07: [io  0x008c-0x008e]
> [    3.148469] pnp 00:07: [io  0x0090-0x009f]
> [    3.148734] pnp 00:07: [io  0x00a2-0x00bf]
> [    3.148988] pnp 00:07: [io  0x00e0-0x00ef]
> [    3.149250] pnp 00:07: [io  0x04d0-0x04d1]
> [    3.149697] system 00:07: [io  0x04d0-0x04d1] has been reserved
> [    3.150061] system 00:07: Plug and Play ACPI device, IDs PNP0c02 (active)
> [    3.150478] pnp 00:08: [io  0x00f0-0x00ff]
> [    3.150755] xen: registering gsi 13 triggering 1 polarity 0
> [    3.151101] pnp 00:08: [irq 13]
> [    3.151448] pnp 00:08: Plug and Play ACPI device, IDs PNP0c04 (active)
> [    3.152100] system 00:09: Plug and Play ACPI device, IDs PNP0c02 (active)
> [    3.152778] pnp 00:0a: [io  0x03f8-0x03ff]
> [    3.153037] xen: registering gsi 4 triggering 1 polarity 0
> [    3.153376] pnp 00:0a: [irq 4]
> [    3.153581] pnp 00:0a: [dma 0 disabled]
> [    3.153998] pnp 00:0a: Plug and Play ACPI device, IDs PNP0501 (active)
> [    3.155394] pnp 00:0b: [mem 0xfed00000-0xfed003ff]
> [    3.155978] pnp 00:0b: Plug and Play ACPI device, IDs PNP0103 (active)
> [    3.156388] pnp: PnP ACPI: found 12 devices
> [    3.156653] ACPI: ACPI bus type pnp unregistered
> [    3.156953] xen-pciback: Error parsing pci_devs_to_hide at "(00:02:00)"
> [    3.170459] PM-Timer failed consistency check  (0x0xffffff) - aborting.
> [    3.170947] pci 0000:00:14.4: PCI bridge to [bus 01]
> [    3.171261] pci 0000:00:14.4:   bridge window [io  0xe000-0xefff]
> [    3.171655] pci 0000:00:15.0: PCI bridge to [bus 02]
> [    3.171974] pci 0000:00:15.0:   bridge window [io  0xd000-0xdfff]
> [    3.172345] pci 0000:00:15.0:   bridge window [mem 0xfea00000-0xfeafffff]
> [    3.172762] pci 0000:00:15.1: PCI bridge to [bus 03]
> [    3.173067] pci 0000:00:15.1:   bridge window [io  0xc000-0xcfff]
> [    3.173436] pci 0000:00:15.1:   bridge window [mem 0xfe900000-0xfe9fffff]
> [    3.173889] xen: registering gsi 16 triggering 0 polarity 1
> [    3.174247] xen: --> pirq=16 -> irq=16 (gsi=16)
> [    3.174547] xen: registering gsi 16 triggering 0 polarity 1
> [    3.174894] Already setup the GSI :16
> [    3.175131] pci_bus 0000:00: resource 4 [io  0x0000-0x03af]
> [    3.175470] pci_bus 0000:00: resource 5 [io  0x03e0-0x0cf7]
> [    3.176854] pci_bus 0000:00: resource 6 [io  0x03b0-0x03df]
> [    3.177184] pci_bus 0000:00: resource 7 [io  0x0d00-0xffff]
> [    3.177514] pci_bus 0000:00: resource 8 [mem 0x000a0000-0x000bffff]
> [    3.177891] pci_bus 0000:00: resource 9 [mem 0x000c0000-0x000dffff]
> [    3.178267] pci_bus 0000:00: resource 10 [mem 0xd0000000-0xffffffff]
> [    3.178649] pci_bus 0000:01: resource 0 [io  0xe000-0xefff]
> [    3.178994] pci_bus 0000:01: resource 4 [io  0x0000-0x03af]
> [    3.179326] pci_bus 0000:01: resource 5 [io  0x03e0-0x0cf7]
> [    3.179672] pci_bus 0000:01: resource 6 [io  0x03b0-0x03df]
> [    3.180015] pci_bus 0000:01: resource 7 [io  0x0d00-0xffff]
> [    3.180344] pci_bus 0000:01: resource 8 [mem 0x000a0000-0x000bffff]
> [    3.180716] pci_bus 0000:01: resource 9 [mem 0x000c0000-0x000dffff]
> [    3.181081] pci_bus 0000:01: resource 10 [mem 0xd0000000-0xffffffff]
> [    3.181452] pci_bus 0000:02: resource 0 [io  0xd000-0xdfff]
> [    3.181792] pci_bus 0000:02: resource 1 [mem 0xfea00000-0xfeafffff]
> [    3.182168] pci_bus 0000:03: resource 0 [io  0xc000-0xcfff]
> [    3.182505] pci_bus 0000:03: resource 1 [mem 0xfe900000-0xfe9fffff]
> [    3.183045] NET: Registered protocol family 2
> [    3.184322] TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
> [    3.186023] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
> [    3.186732] TCP: Hash tables configured (established 262144 bind 65536)
> [    3.187181] TCP: reno registered
> [    3.187411] UDP hash table entries: 1024 (order: 3, 32768 bytes)
> [    3.187803] UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes)
> [    3.188405] NET: Registered protocol family 1
> [    3.188924] RPC: Registered named UNIX socket transport module.
> [    3.189285] RPC: Registered udp transport module.
> [    3.189588] RPC: Registered tcp transport module.
> [    3.189901] RPC: Registered tcp NFSv4.1 backchannel transport module.
> [    3.190306] pci 0000:00:01.0: Boot video device
> [    3.190606] xen: registering gsi 18 triggering 0 polarity 1
> [    3.190967] xen: --> pirq=18 -> irq=18 (gsi=18)
> [    3.191310] xen: registering gsi 17 triggering 0 polarity 1
> [    3.191651] xen: --> pirq=17 -> irq=17 (gsi=17)
> [    3.191987] xen: registering gsi 18 triggering 0 polarity 1
> [    3.192322] Already setup the GSI :18
> [    3.779210] xen: registering gsi 17 triggering 0 polarity 1
> [    3.779560] Already setup the GSI :17
> [    3.779854] xen: registering gsi 18 triggering 0 polarity 1
> [    3.780189] Already setup the GSI :18
> [    3.852950] xen: registering gsi 17 triggering 0 polarity 1
> [    3.853302] Already setup the GSI :17
> [    3.853601] xen: registering gsi 18 triggering 0 polarity 1
> [    3.853944] Already setup the GSI :18
> [    3.927246] PCI: CLS 64 bytes, default 64
> [    3.927731] Unpacking initramfs...
> [    4.409499] Freeing initrd memory: 339204k freed
> [    4.502233] Machine check injector initialized
> [    4.504138] microcode: CPU0: patch_level=0x0300000f
> [    4.504463] microcode: CPU1: patch_level=0x0300000f
> [    4.504809] microcode: CPU2: patch_level=0x0300000f
> [    4.505347] microcode: Microcode Update Driver: v2.00 , Peter Oruba
> [    4.506684] audit: initializing netlink socket (disabled)
> [    4.507060] type=2000 audit(1351615437.471:1): initialized
> [    4.520849] HugeTLB registered 2 MB page size, pre-allocated 0 pages
> [    4.521549] VFS: Disk quotas dquot_6.5.2
> [    4.521865] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
> [    4.522596] NFS: Registering the id_resolver key type
> [    4.522935] Key type id_resolver registered
> [    4.523199] Key type id_legacy registered
> [    4.523463] NTFS driver 2.1.30 [Flags: R/W].
> [    4.523927] msgmni has been set to 1798
> [    4.524230] SELinux:  Registering netfilter hooks
> [    4.526131] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
> [    4.526572] io scheduler noop registered
> [    4.526834] io scheduler deadline registered
> [    4.527129] io scheduler cfq registered (default)
> [    4.528468] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
> [    4.529395] input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input0
> [    4.529907] ACPI: Power Button [PWRB]
> [    4.530299] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
> [    4.530782] ACPI: Power Button [PWRF]
> [    4.592637] GHES: HEST is not enabled!
> [    4.592910] ioatdma: Intel(R) QuickData Technology Driver 4.00
> [    4.594402] xen-pciback: backend is vpci
> [    4.666851] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
> [    4.688746] 00:0a: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
> [    4.692137] xen: registering gsi 20 triggering 0 polarity 1
> [    4.692685] xen: --> pirq=20 -> irq=20 (gsi=20)
> [    4.715090] 0000:01:05.0: ttyS1 at I/O 0xe050 (irq = 20) is a 16550A
> [    4.723123] hpet_acpi_add: no address or irqs in _CRS
> [    4.729073] Non-volatile memory driver v1.3
> [    4.733807] Linux agpgart interface v0.103
> [    4.739678] [drm] Initialized drm 1.1.0 20060810
> [    4.747593] loop: module loaded
> [    4.751865] libphy: Fixed MDIO Bus: probed
> [    4.756157] tun: Universal TUN/TAP device driver, 1.6
> [    4.761408] tun: (C) 1999-2004 Max Krasnyansky 
> [    4.768474] ixgbevf: Intel(R) 10 Gigabit PCI Express Virtual Function Network Driver - version 2.6.0-k
> [    4.778143] ixgbevf: Copyright (c) 2009 - 2012 Intel Corporation.
> [    4.786308] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> [    4.793112] ehci_hcd: block sizes: qh 104 qtd 96 itd 192 sitd 96
> [    4.799394] xen: registering gsi 17 triggering 0 polarity 1
> [    4.805186] Already setup the GSI :17
> [    4.809041] ehci_hcd 0000:00:12.2: EHCI Host Controller
> [    4.814827] ehci_hcd 0000:00:12.2: new USB bus registered, assigned bus number 1
> [    4.822582] QUIRK: Enable AMD PLL fix
> [    4.826402] ehci_hcd 0000:00:12.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround
> [    4.835422] ehci_hcd 0000:00:12.2: reset hcs_params 0x101505 dbg=1 cc=1 pcc=5 ordered !ppc ports=5
> [    4.844716] ehci_hcd 0000:00:12.2: reset hcc_params a076 thresh 7 uframes 256/512/1024 park
> [    4.853444] ehci_hcd 0000:00:12.2: park 0
> [    4.857628] ehci_hcd 0000:00:12.2: reset command 0080b02  park=3 ithresh=8 period=1024 Reset HALT
> [    4.866843] ehci_hcd 0000:00:12.2: debug port 1
> [    4.871568] ehci_hcd 0000:00:12.2: MWI active
> [    4.876100] ehci_hcd 0000:00:12.2: supports USB remote wakeup
> [    4.882116] ehci_hcd 0000:00:12.2: irq 17, io mem 0xfeb4f000
> [    4.887997] ehci_hcd 0000:00:12.2: init command 0010005 (park)=0 ithresh=1 period=512 RUN
> [    4.901882] ehci_hcd 0000:00:12.2: USB 2.0 started, EHCI 1.00
> [    4.907965] usb usb1: default language 0x0409
> [    4.912513] usb usb1: udev 1, busnum 1, minor = 0
> [    4.917409] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
> [    4.924454] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> [    4.931952] usb usb1: Product: EHCI Host Controller
> [    4.937024] usb usb1: Manufacturer: Linux 3.7.0-rc3upstream-00220-g37b7153 ehci_hcd
> [    4.944967] usb usb1: SerialNumber: 0000:00:12.2
> [    4.950259] usb usb1: usb_probe_device
> [    4.954193] usb usb1: configuration #1 chosen from 1 choice
> [    4.959997] usb usb1: adding 1-0:1.0 (config #1, interface 0)
> [    4.966339] hub 1-0:1.0: usb_probe_interface
> [    4.970812] hub 1-0:1.0: usb_probe_interface - got id
> [    4.976063] hub 1-0:1.0: USB hub found
> [    4.979980] hub 1-0:1.0: 5 ports detected
> [    4.984155] hub 1-0:1.0: standalone hub
> [    4.988148] hub 1-0:1.0: no power switching (usb 1.0)
> [    4.993398] hub 1-0:1.0: individual port over-current protection
> [    4.999631] hub 1-0:1.0: power on to power good time: 20ms
> [    5.005333] hub 1-0:1.0: local power source is good
> [    5.010998] hub 1-0:1.0: trying to enable port power on non-switchable hub
> [    5.018235] xen: registering gsi 17 triggering 0 polarity 1
> [    5.024028] Already setup the GSI :17
> [    5.027880] ehci_hcd 0000:00:13.2: EHCI Host Controller
> [    5.033663] ehci_hcd 0000:00:13.2: new USB bus registered, assigned bus number 2
> [    5.041377] ehci_hcd 0000:00:13.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround
> [    5.050398] ehci_hcd 0000:00:13.2: reset hcs_params 0x101505 dbg=1 cc=1 pcc=5 ordered !ppc ports=5
> [    5.059685] ehci_hcd 0000:00:13.2: reset hcc_params a076 thresh 7 uframes 256/512/1024 park
> [    5.068427] ehci_hcd 0000:00:13.2: park 0
> [    5.072610] ehci_hcd 0000:00:13.2: reset command 0080b02  park=3 ithresh=8 period=1024 Reset HALT
> [    5.081823] ehci_hcd 0000:00:13.2: debug port 1
> [    5.086547] ehci_hcd 0000:00:13.2: MWI active
> [    5.091081] ehci_hcd 0000:00:13.2: supports USB remote wakeup
> [    5.097059] ehci_hcd 0000:00:13.2: irq 17, io mem 0xfeb4d000
> [    5.102937] ehci_hcd 0000:00:13.2: init command 0010005 (park)=0 ithresh=1 period=512 RUN
> [    5.116889] ehci_hcd 0000:00:13.2: USB 2.0 started, EHCI 1.00
> [    5.123004] usb usb2: default language 0x0409
> [    5.127553] usb usb2: udev 1, busnum 2, minor = 128
> [    5.132627] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
> [    5.139668] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> [    5.147164] usb usb2: Product: EHCI Host Controller
> [    5.152236] usb usb2: Manufacturer: Linux 3.7.0-rc3upstream-00220-g37b7153 ehci_hcd
> [    5.160180] usb usb2: SerialNumber: 0000:00:13.2
> [    5.165185] hub 1-0:1.0: state 7 ports 5 chg 0000 evt 0000
> [    5.165547] usb usb2: usb_probe_device
> [    5.165551] usb usb2: configuration #1 chosen from 1 choice
> [    5.165570] usb usb2: adding 2-0:1.0 (config #1, interface 0)
> [    5.165905] hub 2-0:1.0: usb_probe_interface
> [    5.165908] hub 2-0:1.0: usb_probe_interface - got id
> [    5.165911] hub 2-0:1.0: USB hub found
> [    5.165929] hub 2-0:1.0: 5 ports detected
> [    5.165930] hub 2-0:1.0: standalone hub
> [    5.165931] hub 2-0:1.0: no power switching (usb 1.0)
> [    5.165933] hub 2-0:1.0: individual port over-current protection
> [    5.165935] hub 2-0:1.0: power on to power good time: 20ms
> [    5.165942] hub 2-0:1.0: local power source is good
> [    5.166518] hub 2-0:1.0: trying to enable port power on non-switchable hub
> [    5.166966] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
> [    5.166969] ohci_hcd: block sizes: ed 80 td 96
> [    5.167028] xen: registering gsi 18 triggering 0 polarity 1
> [    5.167033] Already setup the GSI :18
> [    5.167075] ohci_hcd 0000:00:12.0: OHCI Host Controller
> [    5.167260] ohci_hcd 0000:00:12.0: new USB bus registered, assigned bus number 3
> [    5.167338] ohci_hcd 0000:00:12.0: created debug files
> [    5.167340] ohci_hcd 0000:00:12.0: supports USB remote wakeup
> [    5.167385] ohci_hcd 0000:00:12.0: irq 18, io mem 0xfeb50000
> [    5.289966] hub 2-0:1.0: state 7 ports 5 chg 0000 evt 0000
> [    5.293989] ohci_hcd 0000:00:12.0: OHCI controller state
> [    5.293995] ohci_hcd 0000:00:12.0: OHCI 1.0, NO legacy support registers, rh state running
> [    5.293999] ohci_hcd 0000:00:12.0: control 0x283 RWC HCFS=operational CBSR=3
> [    5.294002] ohci_hcd 0000:00:12.0: cmdstatus 0x00000 SOC=0
> [    5.294006] ohci_hcd 0000:00:12.0: intrstatus 0x00000004 SF
> [    5.294009] ohci_hcd 0000:00:12.0: intrenable 0x8000005a MIE RHSC UE RD WDH
> [    5.294019] ohci_hcd 0000:00:12.0: hcca frame #0005
> [    5.294022] ohci_hcd 0000:00:12.0: roothub.a 02001205 POTPGT=2 NOCP NPS NDP=5(5)
> [    5.294025] ohci_hcd 0000:00:12.0: roothub.b 00000000 PPCM=0000 DR=0000
> [    5.294027] ohci_hcd 0000:00:12.0: roothub.status 00008000 DRWE
> [    5.294031] ohci_hcd 0000:00:12.0: roothub.portstatus [0] 0x00000100 PPS
> [    5.294034] ohci_hcd 0000:00:12.0: roothub.portstatus [1] 0x00000100 PPS
> [    5.294037] ohci_hcd 0000:00:12.0: roothub.portstatus [2] 0x00000100 PPS
> [    5.294041] ohci_hcd 0000:00:12.0: roothub.portstatus [3] 0x00000100 PPS
> [    5.294044] ohci_hcd 0000:00:12.0: roothub.portstatus [4] 0x00000100 PPS
> [    5.294080] usb usb3: default language 0x0409
> [    5.294093] usb usb3: udev 1, busnum 3, minor = 256
> [    5.294095] usb usb3: New USB device found, idVendor=1d6b, idProduct=0001
> [    5.294097] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> [    5.294098] usb usb3: Product: OHCI Host Controller
> [    5.294100] usb usb3: Manufacturer: Linux 3.7.0-rc3upstream-00220-g37b7153 ohci_hcd
> [    5.294101] usb usb3: SerialNumber: 0000:00:12.0
> [    5.294371] usb usb3: usb_probe_device
> [    5.294374] usb usb3: configuration #1 chosen from 1 choice
> [    5.294386] usb usb3: adding 3-0:1.0 (config #1, interface 0)
> [    5.294481] hub 3-0:1.0: usb_probe_interface
> [    5.294482] hub 3-0:1.0: usb_probe_interface - got id
> [    5.294484] hub 3-0:1.0: USB hub found
> [    5.294492] hub 3-0:1.0: 5 ports detected
> [    5.294493] hub 3-0:1.0: standalone hub
> [    5.294495] hub 3-0:1.0: no power switching (usb 1.0)
> [    5.294496] hub 3-0:1.0: no over-current protection
> [    5.294497] hub 3-0:1.0: power on to power good time: 4ms
> [    5.294505] hub 3-0:1.0: local power source is good
> [    5.295074] hub 3-0:1.0: trying to enable port power on non-switchable hub
> [    5.295131] ehci_hcd 0000:00:12.2: HS companion for 0000:00:12.0
> [    5.295174] xen: registering gsi 18 triggering 0 polarity 1
> [    5.295178] Already setup the GSI :18
> [    5.295219] ohci_hcd 0000:00:13.0: OHCI Host Controller
> [    5.295337] ohci_hcd 0000:00:13.0: new USB bus registered, assigned bus number 4
> [    5.295397] ohci_hcd 0000:00:13.0: created debug files
> [    5.295399] ohci_hcd 0000:00:13.0: supports USB remote wakeup
> [    5.295409] ohci_hcd 0000:00:13.0: irq 18, io mem 0xfeb4e000
> [    5.549971] hub 3-0:1.0: state 7 ports 5 chg 0000 evt 0000
> [    5.553975] ohci_hcd 0000:00:13.0: OHCI controller state
> [    5.553980] ohci_hcd 0000:00:13.0: OHCI 1.0, NO legacy support registers, rh state running
> [    5.553984] ohci_hcd 0000:00:13.0: control 0x283 RWC HCFS=operational CBSR=3
> [    5.553987] ohci_hcd 0000:00:13.0: cmdstatus 0x00000 SOC=0
> [    5.553990] ohci_hcd 0000:00:13.0: intrstatus 0x00000004 SF
> [    5.553993] ohci_hcd 0000:00:13.0: intrenable 0x8000005a MIE RHSC UE RD WDH
> [    5.554004] ohci_hcd 0000:00:13.0: hcca frame #0005
> [    5.554008] ohci_hcd 0000:00:13.0: roothub.a 02001205 POTPGT=2 NOCP NPS NDP=5(5)
> [    5.554011] ohci_hcd 0000:00:13.0: roothub.b 00000000 PPCM=0000 DR=0000
> [    5.554014] ohci_hcd 0000:00:13.0: roothub.status 00008000 DRWE
> [    5.554018] ohci_hcd 0000:00:13.0: roothub.portstatus [0] 0x00000100 PPS
> [    5.554021] ohci_hcd 0000:00:13.0: roothub.portstatus [1] 0x00000100 PPS
> [    5.554025] ohci_hcd 0000:00:13.0: roothub.portstatus [2] 0x00000100 PPS
> [    5.554028] ohci_hcd 0000:00:13.0: roothub.portstatus [3] 0x00000100 PPS
> [    5.554031] ohci_hcd 0000:00:13.0: roothub.portstatus [4] 0x00000100 PPS
> [    5.554051] usb usb4: default language 0x0409
> [    5.554064] usb usb4: udev 1, busnum 4, minor = 384
> [    5.554066] usb usb4: New USB device found, idVendor=1d6b, idProduct=0001
> [    5.554068] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> [    5.554070] usb usb4: Product: OHCI Host Controller
> [    5.554071] usb usb4: Manufacturer: Linux 3.7.0-rc3upstream-00220-g37b7153 ohci_hcd
> [    5.554072] usb usb4: SerialNumber: 0000:00:13.0
> [    5.554538] usb usb4: usb_probe_device
> [    5.554542] usb usb4: configuration #1 chosen from 1 choice
> [    5.554559] usb usb4: adding 4-0:1.0 (config #1, interface 0)
> [    5.554665] hub 4-0:1.0: usb_probe_interface
> [    5.554667] hub 4-0:1.0: usb_probe_interface - got id
> [    5.554669] hub 4-0:1.0: USB hub found
> [    5.554678] hub 4-0:1.0: 5 ports detected
> [    5.554679] hub 4-0:1.0: standalone hub
> [    5.554681] hub 4-0:1.0: no power switching (usb 1.0)
> [    5.554682] hub 4-0:1.0: no over-current protection
> [    5.554683] hub 4-0:1.0: power on to power good time: 4ms
> [    5.554691] hub 4-0:1.0: local power source is good
> [    5.555283] hub 4-0:1.0: trying to enable port power on non-switchable hub
> [    5.555346] ehci_hcd 0000:00:13.2: HS companion for 0000:00:13.0
> [    5.555389] xen: registering gsi 18 triggering 0 polarity 1
> [    5.555394] Already setup the GSI :18
> [    5.555433] ohci_hcd 0000:00:14.5: OHCI Host Controller
> [    5.555598] ohci_hcd 0000:00:14.5: new USB bus registered, assigned bus number 5
> [    5.555670] ohci_hcd 0000:00:14.5: created debug files
> [    5.555672] ohci_hcd 0000:00:14.5: supports USB remote wakeup
> [    5.555685] ohci_hcd 0000:00:14.5: irq 18, io mem 0xfeb4c000
> [    5.809859] hub 4-0:1.0: state 7 ports 5 chg 0000 evt 0000
> [    5.813841] ohci_hcd 0000:00:14.5: OHCI controller state
> [    5.813847] ohci_hcd 0000:00:14.5: OHCI 1.0, NO legacy support registers, rh state running
> [    5.813851] ohci_hcd 0000:00:14.5: control 0x283 RWC HCFS=operational CBSR=3
> [    5.813854] ohci_hcd 0000:00:14.5: cmdstatus 0x00000 SOC=0
> [    5.813857] ohci_hcd 0000:00:14.5: intrstatus 0x00000004 SF
> [    5.813860] ohci_hcd 0000:00:14.5: intrenable 0x8000005a MIE RHSC UE RD WDH
> [    5.813871] ohci_hcd 0000:00:14.5: hcca frame #0004
> [    5.813874] ohci_hcd 0000:00:14.5: roothub.a 02001202 POTPGT=2 NOCP NPS NDP=2(2)
> [    5.813876] ohci_hcd 0000:00:14.5: roothub.b 00000000 PPCM=0000 DR=0000
> [    5.813880] ohci_hcd 0000:00:14.5: roothub.status 00008000 DRWE
> [    5.813884] ohci_hcd 0000:00:14.5: roothub.portstatus [0] 0x00000100 PPS
> [    5.813886] ohci_hcd 0000:00:14.5: roothub.portstatus [1] 0x00000100 PPS
> [    5.813923] usb usb5: default language 0x0409
> [    5.813935] usb usb5: udev 1, busnum 5, minor = 512
> [    5.813938] usb usb5: New USB device found, idVendor=1d6b, idProduct=0001
> [    5.813939] usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> [    5.813941] usb usb5: Product: OHCI Host Controller
> [    5.813942] usb usb5: Manufacturer: Linux 3.7.0-rc3upstream-00220-g37b7153 ohci_hcd
> [    5.813944] usb usb5: SerialNumber: 0000:00:14.5
> [    5.814220] usb usb5: usb_probe_device
> [    5.814223] usb usb5: configuration #1 chosen from 1 choice
> [    5.814238] usb usb5: adding 5-0:1.0 (config #1, interface 0)
> [    5.814373] hub 5-0:1.0: usb_probe_interface
> [    5.814375] hub 5-0:1.0: usb_probe_interface - got id
> [    5.814377] hub 5-0:1.0: USB hub found
> [    5.814390] hub 5-0:1.0: 2 ports detected
> [    5.814392] hub 5-0:1.0: standalone hub
> [    5.814393] hub 5-0:1.0: no power switching (usb 1.0)
> [    5.814394] hub 5-0:1.0: no over-current protection
> [    5.814396] hub 5-0:1.0: power on to power good time: 4ms
> [    5.814405] hub 5-0:1.0: local power source is good
> [    5.814425] hub 5-0:1.0: trying to enable port power on non-switchable hub
> [    5.814584] uhci_hcd: USB Universal Host Controller Interface driver
> [    6.009259] hub 5-0:1.0: state 7 ports 2 chg 0000 evt 0000
> [    6.009372] usbcore: registered new interface driver usblp
> [    6.009676] i8042: PNP: No PS/2 controller found. Probing ports directly.
> [    6.010397] serio: i8042 KBD port at 0x60,0x64 irq 1
> [    6.010409] serio: i8042 AUX port at 0x60,0x64 irq 12
> [    6.010691] mousedev: PS/2 mouse device common for all mice
> [    6.011327] rtc_cmos 00:05: RTC can wake from S4
> [    6.011618] rtc_cmos 00:05: rtc core: registered rtc_cmos as rtc0
> [    6.011662] rtc0: alarms up to one month, y3k, 114 bytes nvram
> [    6.011868] EFI Variables Facility v0.08 2004-May-17
> [    6.011957] zram: num_devices not specified. Using default: 1
> [    6.011958] zram: Creating 1 devices ...
> [    6.077064] Netfilter messages via NETLINK v0.30.
> [    6.082006] nf_conntrack version 0.5.0 (7194 buckets, 28776 max)
> [    6.088334] ctnetlink v0.93: registering with nfnetlink.
> [    6.094201] ip_tables: (C) 2000-2006 Netfilter Core Team
> [    6.099817] TCP: cubic registered
> [    6.103279] Initializing XFRM netlink socket
> [    6.107873] NET: Registered protocol family 10
> [    6.112784] ip6_tables: (C) 2000-2006 Netfilter Core Team
> [    6.119125] sit: IPv6 over IPv4 tunneling driver
> [    6.124870] NET: Registered protocol family 17
> [    6.129593] Key type dns_resolver registered
> [    6.135108] PM: Hibernation image not present or could not be loaded.
> [    6.141853] registered taskstats version 1
> [    6.146837]   Magic number: 0:661:743
> [    6.151899] Freeing unused kernel memory: 752k freed
> [    6.157248] Write protecting the kernel read-only data: 10240k
> [    6.169212] Freeing unused kernel memory: 1768k freed
> [    6.175129] Freeing unused kernel memory: 168k freed
> [    6.188257] consoletype (1257) used greatest stack depth: 5272 bytes left
> [    6.524961] modprobe (1286) used greatest stack depth: 5256 bytes left
> [    6.547403] core_filesystem (1258) used greatest stack depth: 4952 bytes left
> [    6.592358] Initialising Xen virtual ethernet driver.
> [    6.722568] wmi: Mapper loaded
> [    6.796831] xen: registering gsi 17 triggering 0 polarity 1
> [    6.802666] Already setup the GSI :17
> [    6.808260] e1000e: Intel(R) PRO/1000 Network Driver - 2.1.4-k
> [    6.814354] e1000e: Copyright(c) 1999 - 2012 Intel Corporation.
> [    6.816573] SCSI subsystem initialized
> [    6.824498] e1000e 0000:02:00.0: Disabling ASPM L0s L1
> [    6.824524] xen: registering gsi 16 triggering 0 polarity 1
> [    6.824531] Already setup the GSI :16
> [    6.824740] e1000e 0000:02:00.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
> [    6.859455] [drm] radeon defaulting to kernel modesetting.
> [    6.866428] [drm] radeon kernel modesetting enabled.
> [    6.873121] xen: registering gsi 18 triggering 0 polarity 1
> [    6.873126] Already setup the GSI :18
> [    6.883269] atl1c 0000:03:00.0: version 1.0.1.0-NAPI
> [    6.883447] [drm] initializing kernel modesetting (SUMO 0x1002:0x9640 0x1043:0x84C8).
> [    6.883509] [drm] register mmio base: 0xFEB00000
> [    6.883511] [drm] register mmio size: 262144
> [    6.883646] ATOM BIOS: General
> [    6.883717] radeon 0000:00:01.0: VRAM: 512M 0x0000000000000000 - 0x000000001FFFFFFF (512M used)
> [    6.883720] radeon 0000:00:01.0: GTT: 512M 0x0000000020000000 - 0x000000003FFFFFFF
> [    6.883722] [drm] Detected VRAM RAM=512M, BAR=256M
> [    6.883725] [drm] RAM width 32bits DDR
> [    6.884463] [TTM] Zone  kernel: Available graphics memory: 461822 kiB
> [    6.884466] [TTM] Initializing pool allocator
> [    6.884476] [TTM] Initializing DMA pool allocator
> [    6.884529] [drm] radeon: 512M of VRAM memory ready
> [    6.884531] [drm] radeon: 512M of GTT memory ready.
> [    6.884622] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
> [    6.884625] [drm] Driver supports precise vblank timestamp query.
> [    6.884802] radeon 0000:00:01.0: radeon: using MSI.
> [    6.884865] [drm] radeon: irq initialized.
> [    6.884871] [drm] GART: num cpu pages 131072, num gpu pages 131072
> [    6.895835] [drm] Loading SUMO Microcode
> [    6.933742] ACPI: bus type scsi registered
> [    6.941860] e1000e 0000:02:00.0 eth1: (PCI Express:2.5GT/s:Width x1) 00:1b:21:ab:c6:12
> [    6.941862] e1000e 0000:02:00.0 eth1: Intel(R) PRO/1000 Network Connection
> [    6.941882] e1000e 0000:02:00.0 eth1: MAC: 3, PHY: 8, PBA No: E46981-005
> [    6.997612] ip (1909) used greatest stack depth: 3896 bytes left
> [    7.048540] libata version 3.00 loaded.
> [    7.144568] [drm] PCIE GART of 512M enabled (table at 0x0000000000040000).
> [    7.151898] radeon 0000:00:01.0: WB enabled
> [    7.156253] radeon 0000:00:01.0: fence driver on ring 0 use gpu addr 0x0000000020000c00 and cpu addr 0xffff880023235c00
> [    7.185375] [drm] ring test on 0 succeeded in 1 usecs
> [    7.191817] [drm] ib test on ring 0 succeeded in 0 usecs
> [    7.209657] [drm] Radeon Display Connectors
> [    7.214052] [drm] Connector 0:
> [    7.217253] [drm]   VGA-1
> [    7.220007] [drm]   HPD2
> [    7.222674] [drm]   DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448 0x644c 0x644c
> [    7.230416] [drm]   Encoders:
> [    7.233539] [drm]     CRT1: INTERNAL_UNIPHY2
> [    7.238001] [drm]     CRT1: NUTMEG
> [    7.238003] [drm] Connector 1:
> [    7.238005] [drm]   HDMI-A-1
> [    7.238006] [drm]   HPD1
> [    7.238009] [drm]   DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c 0x643c
> [    7.238011] [drm]   Encoders:
> [    7.238011] [drm]     DFP1: INTERNAL_UNIPHY2
> [    7.255949] [drm] Internal thermal controller without fan control
> [    7.259955] [drm] radeon: power management initialized
> [    7.335529] No connectors reported connected with modes
> [    7.340968] [drm] Cannot find any crtc or sizes - going 1024x768
> [    7.350906] [drm] fb mappable at 0xD0142000
> [    7.355261] [drm] vram apper at 0xD0000000
> [    7.359523] [drm] size 3145728
> [    7.362716] [drm] fb depth is 24
> [    7.366146] [drm]    pitch is 4096
> [    7.370065] fbcon: radeondrmfb (fb0) is primary device
> [    7.376982] ttyS1: 1 input overrun(s)
> [    7.411210] Console: switching to colour frame buffer device 128x48
> [    7.424071] fb0: radeondrmfb frame buffer device
> [    7.428949] drm: registered panic notifier
> [    7.433284] [drm] Initialized radeon 2.24.0 20080528 for 0000:00:01.0 on minor 0
> [    7.441164] ahci 0000:00:11.0: version 3.0
> [    7.445546] xen: registering gsi 19 triggering 0 polarity 1
> [    7.451464] xen: --> pirq=19 -> irq=19 (gsi=19)
> [    7.456473] ahci 0000:00:11.0: AHCI 0001.0300 32 slots 6 ports 6 Gbps 0x3f impl SATA mode
> [    7.465104] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part
> [    7.478140] scsi0 : ahci
> [    7.481629] scsi1 : ahci
> [    7.484929] scsi2 : ahci
> [    7.488287] scsi3 : ahci
> [    7.491496] scsi4 : ahci
> [    7.494907] scsi5 : ahci
> [    7.498649] ata1: SATA max UDMA/133 abar m2048@0xfeb51000 port 0xfeb51100 irq 71
> [    7.507585] ata2: SATA max UDMA/133 abar m2048@0xfeb51000 port 0xfeb51180 irq 71
> [    7.515392] ata3: SATA max UDMA/133 abar m2048@0xfeb51000 port 0xfeb51200 irq 71
> [    7.523177] ata4: SATA max UDMA/133 abar m2048@0xfeb51000 port 0xfeb51280 irq 71
> [    7.530982] ata5: SATA max UDMA/133 abar m2048@0xfeb51000 port 0xfeb51300 irq 71
> [    7.538786] ata6: SATA max UDMA/133 abar m2048@0xfeb51000 port 0xfeb51380 irq 71
> [    7.850775] ata1: SATA link down (SStatus 0 SControl 300)
> [    7.856613] ata2: SATA link down (SStatus 0 SControl 300)
> [    7.862497] ata6: SATA link down (SStatus 0 SControl 300)
> [    7.871228] ata3: SATA link down (SStatus 0 SControl 300)
> [    7.879887] ata5: SATA link down (SStatus 0 SControl 300)
> [    8.038131] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> [    8.062593] ata4.00: ATA-7: WDC WD800AAJS-18TDA0, 01.00A03, max UDMA/133
> [    8.072417] ata4.00: 156250000 sectors, multi 16: LBA48 NCQ (depth 31/32), AA
> [    8.082336] ata4.00: failed to get Identify Device Data, Emask 0x1
> [    8.092297] ata4.00: failed to get Identify Device Data, Emask 0x1
> [    8.100682] ata4.00: configured for UDMA/133
> [    8.107497] scsi 3:0:0:0: Direct-Access     ATA      WDC WD800AAJS-18 01.0 PQ: 0 ANSI: 5
> [    8.129843] sd 3:0:0:0: [sda] 156250000 512-byte logical blocks: (80.0 GB/74.5 GiB)
> [    8.140007] sd 3:0:0:0: [sda] Write Protect is off
> [    8.146945] sd 3:0:0:0: [sda] Mode Sense: 00 3a 00 00
> [    8.154244] sd 3:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
> [    8.199771]  sda: sda1 sda2 sda3 sda4
> [    8.210772] sd 3:0:0:0: [sda] Attached SCSI disk
> [    8.224663] sd 3:0:0:0: Attached scsi generic sg0 type 0
> [    8.944409] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
> [    8.963120] device eth0 entered promiscuous mode
> [    9.181754] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
> [   10.053518] atl1c 0000:03:00.0: atl1c: eth0 NIC Link is Up<1000 Mbps Full Duplex>
> [   10.064785] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> [   11.555156] e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
> [   11.566749] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
> [   13.964892] switch: port 1(eth0) entered forwarding state
> [   13.973524] switch: port 1(eth0) entered forwarding state
> [   16.232334] Loading iSCSI transport class v2.0-870.
> [   16.248793] iscsi: registered transport (tcp)
> [   16.306470] Event-channel device installed.
> [   19.630065] mount.nfs (3143) used greatest stack depth: 3224 bytes left
> [   21.157586] device-mapper: ioctl: 4.23.0-ioctl (2012-07-25) initialised: dm-devel@redhat.com
> [   21.170420] device-mapper: multipath: version 1.5.0 loaded
> [   21.450531] scsi6 : iSCSI Initiator over TCP/IP
> [   21.731710] scsi 6:0:0:0: Direct-Access     LIO-ORG  IBLOCK           4.0  PQ: 0 ANSI: 5
> [   21.747167] sd 6:0:0:0: [sdb] 503316480 512-byte logical blocks: (257 GB/240 GiB)
> [   21.747211] sd 6:0:0:0: Attached scsi generic sg1 type 0
> [   21.748648] scsi 6:0:0:1: Direct-Access     LIO-ORG  IBLOCK           4.0  PQ: 0 ANSI: 5
> [   21.752968] sd 6:0:0:1: [sdc] 167772160 512-byte logical blocks: (85.8 GB/80.0 GiB)
> [   21.753042] sd 6:0:0:1: Attached scsi generic sg2 type 0
> [   21.755647] sd 6:0:0:1: [sdc] Write Protect is off
> [   21.755655] sd 6:0:0:1: [sdc] Mode Sense: 2f 00 00 00
> [   21.756638] sd 6:0:0:1: [sdc] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
> [   21.761219] scsi 6:0:0:2: Direct-Access     LIO-ORG  IBLOCK           4.0  PQ: 0 ANSI: 5
> [   21.770871] sd 6:0:0:2: Attached scsi generic sg3 type 0
> [   21.771168] sd 6:0:0:2: [sdd] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB)
> [   21.775163] ttyS1: 1 input overrun(s)
> [   21.776400] sd 6:0:0:2: [sdd] Write Protect is off
> [   21.776405] sd 6:0:0:2: [sdd] Mode Sense: 2f 00 00 00
> [   21.776884] sd 6:0:0:2: [sdd] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
> [   21.780001]  sdd: unknown partition table
> [   21.781272] sd 6:0:0:2: [sdd] Attached SCSI disk
> [   21.804226]  sdc: sdc1 sdc2 < sdc5 >
> [   21.806353] sd 6:0:0:1: [sdc] Attached SCSI disk
> [   21.918632] sd 6:0:0:0: [sdb] Write Protect is off
> [   21.926413] sd 6:0:0:0: [sdb] Mode Sense: 2f 00 00 00
> [   21.935417] sd 6:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
> [   21.963859]  sdb: unknown partition table
> [   21.974284] sd 6:0:0:0: [sdb] Attached SCSI disk
> [   28.589544] bio: create slab  at 1
> [   28.997728] switch: port 1(eth0) entered forwarding state
> [   57.703132] device vif1.0 entered promiscuous mode
> [   57.715328] IPv6: ADDRCONF(NETDEV_UP): vif1.0: link is not ready
> [   59.760909] IPv6: ADDRCONF(NETDEV_CHANGE): vif1.0: link becomes ready
> [   59.770384] switch: port 2(vif1.0) entered forwarding state
> [   59.778900] switch: port 2(vif1.0) entered forwarding state
> [   59.876529] xen-blkback:ring-ref 10, event-channel 18, protocol 2 (x86_32-abi) persistent grants
> [   65.135453] switch: port 2(vif1.0) entered disabled state
> [   65.145638] device vif1.0 left promiscuous mode
> [   65.154458] switch: port 2(vif1.0) entered disabled state
> [   70.836602] device vif2.0 entered promiscuous mode
> [   70.848191] IPv6: ADDRCONF(NETDEV_UP): vif2.0: link is not ready
> [   72.285945] IPv6: ADDRCONF(NETDEV_CHANGE): vif2.0: link becomes ready
> [   72.295310] switch: port 2(vif2.0) entered forwarding state
> [   72.303597] switch: port 2(vif2.0) entered forwarding state
> [   72.403140] xen-blkback:ring-ref 10, event-channel 11, protocol 1 (x86_64-abi) persistent grants
> [   72.544101] ------------[ cut here ]------------
> [   72.552932] kernel BUG at /home/konrad/linux/drivers/block/xen-blkback/blkback.c:589!
> [   72.563680] invalid opcode: 0000 [#1] SMP
> [   72.570865] Modules linked in: dm_multipath dm_mod xen_evtchn iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi libcrc32c crc32c sg sd_mod ahci libahci libata radeon e1000e scsi_mod atl1c fbcon ttm tileblit font bitblit softcursor drm_kms_helper wmi xen_blkfront xen_netfront fb_sys_fops sysimgblt sysfillrect syscopyarea xenfs xen_privcmd [last unloaded: dump_dma]
> [   72.617251] CPU 0
> [   72.619173] Pid: 3823, comm: blkback.2.xvda Tainted: G           O 3.7.0-rc3upstream-00220-g37b7153 #1 System manufacturer System Product Name/F1A75-M
> [   72.641606] RIP: e030:[]  [] xen_blkbk_map+0x696/0x6e0
> [   72.653181] RSP: e02b:ffff880027dd3728  EFLAGS: 00010246
> [   72.661651] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
> [   72.672090] RDX: ffff8800232d7f40 RSI: 0000000000000000 RDI: ffff880027dd3d88
> [   72.682437] RBP: ffff880027dd39e8 R08: 0000000000000000 R09: 0000000000000000
> [   72.692835] R10: 0000000000000001 R11: dead000000200200 R12: 0000000000000000
> [   72.703261] R13: 0000000000000000 R14: ffff88002b5e7070 R15: 0000000000000000
> [   72.713560] FS:  00007f6cc62d5700(0000) GS:ffff88003e000000(0000) knlGS:0000000000000000
> [   72.724921] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> [   72.733811] CR2: 00000000006dd384 CR3: 0000000027b8f000 CR4: 0000000000000660
> [   72.744131] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [   72.754517] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [   72.764882] Process blkback.2.xvda (pid: 3823, threadinfo ffff880027dd2000, task ffff88002bb15040)
> [   72.777140] Stack:
> [   72.782184]  ffff880027dd3738 ffff880026081af0 ffff880027dd3798 ffffffff810ac7df
> [   72.792960]  ffff880027dd3798 ffffffff8104c506 0000000000000117 ffff88002160d030
> [   72.803712]  ffff880027dd3a38 ffff88002b5e7120 ffff88002160d000 ffff880027dd3d88
> [   72.814469] Call Trace:
> [   72.820094]  [] ? __queue_work+0xff/0x420
> [   72.829023]  [] ? xen_spin_lock_flags+0xb6/0x120
> [   72.838462]  [] ? queue_work_on+0x31/0x50
> [   72.847279]  [] ? _raw_spin_unlock_irqrestore+0x19/0x30
> [   72.854408] ttyS1: 2 input overrun(s)
> [   72.864352]  [] ? pvclock_clocksource_read+0x58/0xd0
> [   72.874471]  [] ? cpumask_next_and+0x23/0x40
> [   72.883656]  [] ? cpumask_next_and+0x23/0x40
> [   72.892716]  [] ? update_sd_lb_stats+0x157/0x6c0
> [   72.902178]  [] ? _raw_spin_lock_irq+0x20/0x30
> [   72.911486]  [] ? find_busiest_group+0x31/0x4d0
> [   72.920849]  [] dispatch_rw_block_io+0x377/0x600
> [   72.930187]  [] ? pvclock_clocksource_read+0x58/0xd0
> [   72.939957]  [] ? xen_mc_flush+0xc0/0x1f0
> [   72.948743]  [] ? xen_end_context_switch+0x19/0x20
> [   72.958251]  [] ? pvclock_clocksource_read+0x58/0xd0
> [   72.967917]  [] ? pvclock_clocksource_read+0x58/0xd0
> [   72.977617]  [] ? pvclock_clocksource_read+0x58/0xd0
> [   72.987474]  [] ? xen_clocksource_read+0x39/0x50
> [   72.997278]  [] ? xen_spin_lock_flags+0xb6/0x120
> [   73.006476]  [] xen_blkif_schedule+0x21e/0xa00
> [   73.015493]  [] ? irq_to_desc+0x12/0x20
> [   73.023833]  [] ? irq_get_irq_data+0x9/0x10
> [   73.032418]  [] ? info_for_irq+0x9/0x20
> [   73.040554]  [] ? notify_remote_via_irq+0x29/0x50
> [   73.049523]  [] ? sched_clock_cpu+0xcd/0x110
> [   73.058024]  [] ? pvclock_clocksource_read+0x58/0xd0
> [   73.067191]  [] ? xen_mc_flush+0xc0/0x1f0
> [   73.075338]  [] ? __schedule+0x3be/0x7c0
> [   73.083311]  [] ? wake_up_bit+0x40/0x40
> [   73.091108]  [] ? dispatch_rw_block_io+0x600/0x600
> [   73.099902]  [] kthread+0xc6/0xd0
> [   73.107124]  [] ? xen_end_context_switch+0x19/0x20
> [   73.115845]  [] ? kthread_freezable_should_stop+0x80/0x80
> [   73.125266]  [] ret_from_fork+0x7c/0xb0
> [   73.133089]  [] ? kthread_freezable_should_stop+0x80/0x80
> [   73.142576] Code: 48 89 d7 e8 ad 66 d8 ff 4a c7 84 3d 70 ff ff ff 00 00 00 00 4c 8b 85 60 fd ff ff 41 8b b0 e4 fd ff ff 41 83 cd 01 e9 ef fb ff ff <0f> 0b eb fe 48 8d 95 10 ff ff ff 48 8d bd b0 fd ff ff 31 f6 44
> [   73.167611] RIP  [] xen_blkbk_map+0x696/0x6e0
> [   73.176081]  RSP 
> [   73.182024] ---[ end trace 914a52d8b62134db ]---
> [   87.339441] switch: port 2(vif2.0) entered forwarding state
> [  315.067569] device tap3.0 entered promiscuous mode
> [  315.074965] switch: port 3(tap3.0) entered forwarding state
> [  315.083116] switch: port 3(tap3.0) entered forwarding state
> [  315.142543] switch: port 3(tap3.0) entered disabled state
> [  315.161150] switch: port 3(tap3.0) entered forwarding state
> [  315.169097] switch: port 3(tap3.0) entered forwarding state
> [  330.162411] switch: port 3(tap3.0) entered forwarding state
> [  415.483626] switch: port 3(tap3.0) entered disabled state
> [  415.491439] device tap3.0 left promiscuous mode
> [  415.498191] switch: port 3(tap3.0) entered disabled state
> [  658.839306] device tap4.0 entered promiscuous mode
> [  658.846451] switch: port 3(tap4.0) entered forwarding state
> [  658.854354] switch: port 3(tap4.0) entered forwarding state
> [  658.923751] switch: port 3(tap4.0) entered disabled state
> [  658.942642] switch: port 3(tap4.0) entered forwarding state
> [  658.950492] switch: port 3(tap4.0) entered forwarding state
> [  673.990219] switch: port 3(tap4.0) entered forwarding state
> [  759.263762] switch: port 3(tap4.0) entered disabled state
> [  759.271529] device tap4.0 left promiscuous mode
> [  759.278257] switch: port 3(tap4.0) entered disabled state
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 20:51:51 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 20:51:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTImB-0007tk-QC; Tue, 30 Oct 2012 20:51:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTImA-0007td-1A
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 20:51:06 +0000
Received: from [85.158.143.99:28516] by server-2.bemta-4.messagelabs.com id
	C2/33-22268-9BD30905; Tue, 30 Oct 2012 20:51:05 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1351630261!20456833!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gNTE1Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15761 invoked from network); 30 Oct 2012 20:51:03 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Oct 2012 20:51:03 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9UKoxnC023841
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 30 Oct 2012 20:51:00 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9UKow9N012518
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 30 Oct 2012 20:50:58 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9UKowbt011193; Tue, 30 Oct 2012 15:50:58 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 30 Oct 2012 13:50:57 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 020B840376; Tue, 30 Oct 2012 16:38:27 -0400 (EDT)
Date: Tue, 30 Oct 2012 16:38:27 -0400
From: Konrad Rzeszutek Wilk 
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= 
Message-ID: <20121030203827.GB16465@phenom.dumpdata.com>
References: <1351097925-26221-1-git-send-email-roger.pau@citrix.com>
	<20121030170157.GA29485@phenom.dumpdata.com>
	<50901D6C.6020500@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50901D6C.6020500@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "linux-kernel@vger.kernel.org" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH v2] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 30, 2012 at 07:33:16PM +0100, Roger Pau Monn=E9 wrote:
> On 30/10/12 18:01, Konrad Rzeszutek Wilk wrote:
> > On Wed, Oct 24, 2012 at 06:58:45PM +0200, Roger Pau Monne wrote:
> >> This patch implements persistent grants for the xen-blk{front,back}
> >> mechanism. The effect of this change is to reduce the number of unmap
> >> operations performed, since they cause a (costly) TLB shootdown. This
> >> allows the I/O performance to scale better when a large number of VMs
> >> are performing I/O.
> >>
> >> Previously, the blkfront driver was supplied a bvec[] from the request
> >> queue. This was granted to dom0; dom0 performed the I/O and wrote
> >> directly into the grant-mapped memory and unmapped it; blkfront then
> >> removed foreign access for that grant. The cost of unmapping scales
> >> badly with the number of CPUs in Dom0. An experiment showed that when
> >> Dom0 has 24 VCPUs, and guests are performing parallel I/O to a
> >> ramdisk, the IPIs from performing unmap's is a bottleneck at 5 guests
> >> (at which point 650,000 IOPS are being performed in total). If more
> >> than 5 guests are used, the performance declines. By 10 guests, only
> >> 400,000 IOPS are being performed.
> >>
> >> This patch improves performance by only unmapping when the connection
> >> between blkfront and back is broken.
> >>
> >> On startup blkfront notifies blkback that it is using persistent
> >> grants, and blkback will do the same. If blkback is not capable of
> >> persistent mapping, blkfront will still use the same grants, since it
> >> is compatible with the previous protocol, and simplifies the code
> >> complexity in blkfront.
> >>
> >> To perform a read, in persistent mode, blkfront uses a separate pool
> >> of pages that it maps to dom0. When a request comes in, blkfront
> >> transmutes the request so that blkback will write into one of these
> >> free pages. Blkback keeps note of which grefs it has already
> >> mapped. When a new ring request comes to blkback, it looks to see if
> >> it has already mapped that page. If so, it will not map it again. If
> >> the page hasn't been previously mapped, it is mapped now, and a record
> >> is kept of this mapping. Blkback proceeds as usual. When blkfront is
> >> notified that blkback has completed a request, it memcpy's from the
> >> shared memory, into the bvec supplied. A record that the {gref, page}
> >> tuple is mapped, and not inflight is kept.
> >>
> >> Writes are similar, except that the memcpy is peformed from the
> >> supplied bvecs, into the shared pages, before the request is put onto
> >> the ring.
> >>
> >> Blkback stores a mapping of grefs=3D>{page mapped to by gref} in
> >> a red-black tree. As the grefs are not known apriori, and provide no
> >> guarantees on their ordering, we have to perform a search
> >> through this tree to find the page, for every gref we receive. This
> >> operation takes O(log n) time in the worst case. In blkfront grants
> >> are stored using a single linked list.
> >>
> >> The maximum number of grants that blkback will persistenly map is
> >> currently set to RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, to
> >> prevent a malicios guest from attempting a DoS, by supplying fresh
> >> grefs, causing the Dom0 kernel to map excessively. If a guest
> >> is using persistent grants and exceeds the maximum number of grants to
> >> map persistenly the newly passed grefs will be mapped and unmaped.
> >> Using this approach, we can have requests that mix persistent and
> >> non-persistent grants, and we need to handle them correctly.
> >> This allows us to set the maximum number of persistent grants to a
> >> lower value than RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, although
> >> setting it will lead to unpredictable performance.
> >>
> >> In writing this patch, the question arrises as to if the additional
> >> cost of performing memcpys in the guest (to/from the pool of granted
> >> pages) outweigh the gains of not performing TLB shootdowns. The answer
> >> to that question is `no'. There appears to be very little, if any
> >> additional cost to the guest of using persistent grants. There is
> >> perhaps a small saving, from the reduced number of hypercalls
> >> performed in granting, and ending foreign access.
> >>
> >> Signed-off-by: Oliver Chick 
> >> Signed-off-by: Roger Pau Monne 
> >> Cc: 
> >> Cc: 
> >> ---
> >> Changes since v1:
> >>  * Changed the unmap_seg array to a bitmap.
> >>  * Only report using persistent grants in blkfront if blkback supports
> >>    it.
> >>  * Reword some comments.
> >>  * Fix a bug when setting the handler, index j was not incremented
> >>    correctly.
> >>  * Check that the tree of grants in blkback is not empty before
> >>    iterating over it when doing the cleanup.
> >>  * Rebase on top of linux-net.
> > =

> > I fixed the 'new_map =3D [1|0]' you had in and altered it to use 'true'
> > or 'false', but when running some tests (with a 64-bit PV guest) I got =
it
> > to bug.
> =

> Thanks for the testing. I'm going to rebase on top of your linux-next
> branch and see if I can reproduce it. Did you run any kind of specific
> test/benchmark? I've been running with this patch for a long time (on

None. Just booted a guest with a phy:/dev/vg_guest/blah.

> top of your previous linux-next branch), and I haven't been able to get
> it to bug.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 20:51:51 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 20:51:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTImB-0007tk-QC; Tue, 30 Oct 2012 20:51:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTImA-0007td-1A
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 20:51:06 +0000
Received: from [85.158.143.99:28516] by server-2.bemta-4.messagelabs.com id
	C2/33-22268-9BD30905; Tue, 30 Oct 2012 20:51:05 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1351630261!20456833!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gNTE1Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15761 invoked from network); 30 Oct 2012 20:51:03 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Oct 2012 20:51:03 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9UKoxnC023841
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 30 Oct 2012 20:51:00 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9UKow9N012518
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 30 Oct 2012 20:50:58 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9UKowbt011193; Tue, 30 Oct 2012 15:50:58 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 30 Oct 2012 13:50:57 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 020B840376; Tue, 30 Oct 2012 16:38:27 -0400 (EDT)
Date: Tue, 30 Oct 2012 16:38:27 -0400
From: Konrad Rzeszutek Wilk 
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= 
Message-ID: <20121030203827.GB16465@phenom.dumpdata.com>
References: <1351097925-26221-1-git-send-email-roger.pau@citrix.com>
	<20121030170157.GA29485@phenom.dumpdata.com>
	<50901D6C.6020500@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50901D6C.6020500@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "linux-kernel@vger.kernel.org" ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH v2] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 30, 2012 at 07:33:16PM +0100, Roger Pau Monn=E9 wrote:
> On 30/10/12 18:01, Konrad Rzeszutek Wilk wrote:
> > On Wed, Oct 24, 2012 at 06:58:45PM +0200, Roger Pau Monne wrote:
> >> This patch implements persistent grants for the xen-blk{front,back}
> >> mechanism. The effect of this change is to reduce the number of unmap
> >> operations performed, since they cause a (costly) TLB shootdown. This
> >> allows the I/O performance to scale better when a large number of VMs
> >> are performing I/O.
> >>
> >> Previously, the blkfront driver was supplied a bvec[] from the request
> >> queue. This was granted to dom0; dom0 performed the I/O and wrote
> >> directly into the grant-mapped memory and unmapped it; blkfront then
> >> removed foreign access for that grant. The cost of unmapping scales
> >> badly with the number of CPUs in Dom0. An experiment showed that when
> >> Dom0 has 24 VCPUs, and guests are performing parallel I/O to a
> >> ramdisk, the IPIs from performing unmap's is a bottleneck at 5 guests
> >> (at which point 650,000 IOPS are being performed in total). If more
> >> than 5 guests are used, the performance declines. By 10 guests, only
> >> 400,000 IOPS are being performed.
> >>
> >> This patch improves performance by only unmapping when the connection
> >> between blkfront and back is broken.
> >>
> >> On startup blkfront notifies blkback that it is using persistent
> >> grants, and blkback will do the same. If blkback is not capable of
> >> persistent mapping, blkfront will still use the same grants, since it
> >> is compatible with the previous protocol, and simplifies the code
> >> complexity in blkfront.
> >>
> >> To perform a read, in persistent mode, blkfront uses a separate pool
> >> of pages that it maps to dom0. When a request comes in, blkfront
> >> transmutes the request so that blkback will write into one of these
> >> free pages. Blkback keeps note of which grefs it has already
> >> mapped. When a new ring request comes to blkback, it looks to see if
> >> it has already mapped that page. If so, it will not map it again. If
> >> the page hasn't been previously mapped, it is mapped now, and a record
> >> is kept of this mapping. Blkback proceeds as usual. When blkfront is
> >> notified that blkback has completed a request, it memcpy's from the
> >> shared memory, into the bvec supplied. A record that the {gref, page}
> >> tuple is mapped, and not inflight is kept.
> >>
> >> Writes are similar, except that the memcpy is peformed from the
> >> supplied bvecs, into the shared pages, before the request is put onto
> >> the ring.
> >>
> >> Blkback stores a mapping of grefs=3D>{page mapped to by gref} in
> >> a red-black tree. As the grefs are not known apriori, and provide no
> >> guarantees on their ordering, we have to perform a search
> >> through this tree to find the page, for every gref we receive. This
> >> operation takes O(log n) time in the worst case. In blkfront grants
> >> are stored using a single linked list.
> >>
> >> The maximum number of grants that blkback will persistenly map is
> >> currently set to RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, to
> >> prevent a malicios guest from attempting a DoS, by supplying fresh
> >> grefs, causing the Dom0 kernel to map excessively. If a guest
> >> is using persistent grants and exceeds the maximum number of grants to
> >> map persistenly the newly passed grefs will be mapped and unmaped.
> >> Using this approach, we can have requests that mix persistent and
> >> non-persistent grants, and we need to handle them correctly.
> >> This allows us to set the maximum number of persistent grants to a
> >> lower value than RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST, although
> >> setting it will lead to unpredictable performance.
> >>
> >> In writing this patch, the question arrises as to if the additional
> >> cost of performing memcpys in the guest (to/from the pool of granted
> >> pages) outweigh the gains of not performing TLB shootdowns. The answer
> >> to that question is `no'. There appears to be very little, if any
> >> additional cost to the guest of using persistent grants. There is
> >> perhaps a small saving, from the reduced number of hypercalls
> >> performed in granting, and ending foreign access.
> >>
> >> Signed-off-by: Oliver Chick 
> >> Signed-off-by: Roger Pau Monne 
> >> Cc: 
> >> Cc: 
> >> ---
> >> Changes since v1:
> >>  * Changed the unmap_seg array to a bitmap.
> >>  * Only report using persistent grants in blkfront if blkback supports
> >>    it.
> >>  * Reword some comments.
> >>  * Fix a bug when setting the handler, index j was not incremented
> >>    correctly.
> >>  * Check that the tree of grants in blkback is not empty before
> >>    iterating over it when doing the cleanup.
> >>  * Rebase on top of linux-net.
> > =

> > I fixed the 'new_map =3D [1|0]' you had in and altered it to use 'true'
> > or 'false', but when running some tests (with a 64-bit PV guest) I got =
it
> > to bug.
> =

> Thanks for the testing. I'm going to rebase on top of your linux-next
> branch and see if I can reproduce it. Did you run any kind of specific
> test/benchmark? I've been running with this patch for a long time (on

None. Just booted a guest with a phy:/dev/vg_guest/blah.

> top of your previous linux-next branch), and I haven't been able to get
> it to bug.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 21:20:56 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 21:20:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTJE5-0008RS-CQ; Tue, 30 Oct 2012 21:19:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTJE3-0008RN-Jw
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 21:19:55 +0000
Received: from [85.158.143.35:58068] by server-3.bemta-4.messagelabs.com id
	8E/B6-24279-A7440905; Tue, 30 Oct 2012 21:19:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1351631994!5707883!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10140 invoked from network); 30 Oct 2012 21:19:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 21:19:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,682,1344211200"; d="scan'208";a="15499552"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 21:19:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 30 Oct 2012 21:19:50 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TTJDy-0002Yu-Rw;
	Tue, 30 Oct 2012 21:19:50 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TTJDy-0001MN-RJ;
	Tue, 30 Oct 2012 21:19:50 +0000
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Tue, 30 Oct 2012 21:19:50 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14159: trouble: broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14159 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14159/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-pair        3 host-install/src_host(3) broken REGR. vs. 14154

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 14154
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 14154
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 14154
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 14154

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  8a7f0f36462d
baseline version:
 xen                  10feb0933708

------------------------------------------------------------
People who touched revisions under test:
  Christoph Egger 
  Ian Jackson 
  Jan Beulich 
  Roger Pau Monne 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        broken  
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26120:8a7f0f36462d
tag:         tip
user:        Roger Pau Monne 
date:        Tue Oct 30 14:53:47 2012 +0000
    
    docs: document persistent grants
    
    Document the new persistent grants block-device feature.
    
    Signed-off-by: Roger Pau Monne 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26119:10feb0933708
user:        Christoph Egger 
date:        Mon Oct 29 15:08:56 2012 +0100
    
    MCE: remove unused MCA_MCE_HANDLER
    
    Remove unused MCA_MCE_HANDLER. MCA_MCE_SCAN is used everywhere instead.
    
    Signed-off-by: Christoph Egger 
    Committed-by: Jan Beulich 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 21:20:56 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 21:20:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTJE5-0008RS-CQ; Tue, 30 Oct 2012 21:19:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTJE3-0008RN-Jw
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 21:19:55 +0000
Received: from [85.158.143.35:58068] by server-3.bemta-4.messagelabs.com id
	8E/B6-24279-A7440905; Tue, 30 Oct 2012 21:19:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1351631994!5707883!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY1MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10140 invoked from network); 30 Oct 2012 21:19:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 21:19:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,682,1344211200"; d="scan'208";a="15499552"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 21:19:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 30 Oct 2012 21:19:50 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TTJDy-0002Yu-Rw;
	Tue, 30 Oct 2012 21:19:50 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TTJDy-0001MN-RJ;
	Tue, 30 Oct 2012 21:19:50 +0000
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Tue, 30 Oct 2012 21:19:50 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14159: trouble: broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14159 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14159/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-pair        3 host-install/src_host(3) broken REGR. vs. 14154

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 14154
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 14154
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 14154
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 14154

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  8a7f0f36462d
baseline version:
 xen                  10feb0933708

------------------------------------------------------------
People who touched revisions under test:
  Christoph Egger 
  Ian Jackson 
  Jan Beulich 
  Roger Pau Monne 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        broken  
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   26120:8a7f0f36462d
tag:         tip
user:        Roger Pau Monne 
date:        Tue Oct 30 14:53:47 2012 +0000
    
    docs: document persistent grants
    
    Document the new persistent grants block-device feature.
    
    Signed-off-by: Roger Pau Monne 
    Acked-by: Ian Jackson 
    Committed-by: Ian Jackson 
    
    
changeset:   26119:10feb0933708
user:        Christoph Egger 
date:        Mon Oct 29 15:08:56 2012 +0100
    
    MCE: remove unused MCA_MCE_HANDLER
    
    Remove unused MCA_MCE_HANDLER. MCA_MCE_SCAN is used everywhere instead.
    
    Signed-off-by: Christoph Egger 
    Committed-by: Jan Beulich 
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 21:21:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 21:21:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTJFa-0000A5-SL; Tue, 30 Oct 2012 21:21:30 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTJFZ-00009w-8o
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 21:21:29 +0000
Received: from [193.109.254.147:43269] by server-9.bemta-14.messagelabs.com id
	C4/37-30773-8D440905; Tue, 30 Oct 2012 21:21:28 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1351632086!9038924!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23778 invoked from network); 30 Oct 2012 21:21:27 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 21:21:27 -0000
Received: by mail-qc0-f173.google.com with SMTP id b12so640573qca.32
	for ; Tue, 30 Oct 2012 14:21:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=BQm9qFVx/PtBHZAcbBTzL+wCbb9ib4vHDT7hkEPu5tI=;
	b=Lt2H+aBLl1wyKgiN+U1nKCXY8A3sqOumbk9rX3/jGh+h5YyuEtRVjAjuDQ78SiReiy
	NT3MXkwMOQgnuwh+edYenWdL/JAeKnBgtd5D9JloN/FAZJRDY/7egdVpNcgLfUFKixmX
	J2LBPFUiiwjr+cO4XomafK0TWaX30OAjWbYsWyLAErdYFimenah0wPrKlPR7LZlabzj/
	aduYhPkRCNJxGk3LMXA4noCgJPG4WDkxyK2hizKxP+qby1HjX0eQxhvSpncS0tl8BPZV
	BNFuM3N8ohrGH1DThNWkkC55dd5bntBa5o5ikfm99ubVZbK1ZLLfxre28YnPd6YEzrpU
	GgOg==
Received: by 10.224.72.202 with SMTP id n10mr21776994qaj.94.1351632086248;
	Tue, 30 Oct 2012 14:21:26 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id cs3sm876104qab.10.2012.10.30.14.21.25
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 30 Oct 2012 14:21:25 -0700 (PDT)
Date: Tue, 30 Oct 2012 17:08:55 -0400
From: Konrad Rzeszutek Wilk 
To: Roger Pau Monne 
Message-ID: <20121030210854.GD21481@phenom.dumpdata.com>
References: <1351508996-54975-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1351508996-54975-1-git-send-email-roger.pau@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] docs: document persistent grants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 29, 2012 at 12:09:56PM +0100, Roger Pau Monne wrote:
> Document the new persistent grants block-device feature.
> 
> Signed-off-by: Roger Pau Monne 
> ---
>  xen/include/public/io/blkif.h |   29 +++++++++++++++++++++++++++++
>  1 files changed, 29 insertions(+), 0 deletions(-)
> 
> diff --git a/xen/include/public/io/blkif.h b/xen/include/public/io/blkif.h
> index d71c7f1..accdda4 100644
> --- a/xen/include/public/io/blkif.h
> +++ b/xen/include/public/io/blkif.h
> @@ -126,6 +126,19 @@
>   *      of this type may still be returned at any time with the
>   *      BLKIF_RSP_EOPNOTSUPP result code.
>   *
> + * feature-persistent
> + *      Values:         0/1 (boolean)

That is not a boolean strickly. That would be 'true/false'. Perhaps 'int'?

> + *      Default Value:  0
> + *      Notes: 7
> + *
> + *      A value of "1" indicates that the backend can keep the grants used
> + *      by the frontend driver mapped, so the same set of grants should be
> + *      used in all transactions. The maximum number of grants the backend
> + *      can map persistently depends on the implementation, but ideally it
> + *      should be RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST. Using this
> + *      feature the backend doesn't need to unmap each grant, preventing
> + *      costly TLB flushes.
> + *
>   *----------------------- Request Transport Parameters ------------------------
>   *
>   * max-ring-page-order
> @@ -242,6 +255,15 @@
>   *      The size of the frontend allocated request ring buffer in units of
>   *      machine pages.  The value must be a power of 2.
>   *
> + * feature-persistent
> + *      Values:         0/1 (boolean)
> + *      Default Value:  0
> + *      Notes: 7, 8
> + *
> + *      A value of "1" indicates that the frontend will reuse the same grants
> + *      for all transactions, allowing the backend to map them with write
> + *      access (even when it should be read-only).
> + *
>   *------------------------- Virtual Device Properties -------------------------
>   *
>   * device-type
> @@ -279,6 +301,13 @@
>   *     'ring-ref' is used to communicate the grant reference for this
>   *     page to the backend.  When using a multi-page ring, the 'ring-ref'
>   *     node is not created.  Instead 'ring-ref0' - 'ring-refN' are used.
> + * (7) When using persistent grants data has to be copied from/to the page
> + *     where the grant is currently mapped. The overhead of doing this copy
> + *     however doesn't suppress the speed improvement of not having to unmap
> + *     the grants.
> + * (8) The frontend driver has to allow the backend driver to map all grants
> + *     with write access, even when they should be mapped read-only, since
> + *     further requests may reuse this grants and require write permisions.
>   */
>  
>  /*
> -- 
> 1.7.7.5 (Apple Git-26)
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 21:21:58 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 21:21:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTJFa-0000A5-SL; Tue, 30 Oct 2012 21:21:30 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTJFZ-00009w-8o
	for xen-devel@lists.xen.org; Tue, 30 Oct 2012 21:21:29 +0000
Received: from [193.109.254.147:43269] by server-9.bemta-14.messagelabs.com id
	C4/37-30773-8D440905; Tue, 30 Oct 2012 21:21:28 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1351632086!9038924!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23778 invoked from network); 30 Oct 2012 21:21:27 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 21:21:27 -0000
Received: by mail-qc0-f173.google.com with SMTP id b12so640573qca.32
	for ; Tue, 30 Oct 2012 14:21:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=BQm9qFVx/PtBHZAcbBTzL+wCbb9ib4vHDT7hkEPu5tI=;
	b=Lt2H+aBLl1wyKgiN+U1nKCXY8A3sqOumbk9rX3/jGh+h5YyuEtRVjAjuDQ78SiReiy
	NT3MXkwMOQgnuwh+edYenWdL/JAeKnBgtd5D9JloN/FAZJRDY/7egdVpNcgLfUFKixmX
	J2LBPFUiiwjr+cO4XomafK0TWaX30OAjWbYsWyLAErdYFimenah0wPrKlPR7LZlabzj/
	aduYhPkRCNJxGk3LMXA4noCgJPG4WDkxyK2hizKxP+qby1HjX0eQxhvSpncS0tl8BPZV
	BNFuM3N8ohrGH1DThNWkkC55dd5bntBa5o5ikfm99ubVZbK1ZLLfxre28YnPd6YEzrpU
	GgOg==
Received: by 10.224.72.202 with SMTP id n10mr21776994qaj.94.1351632086248;
	Tue, 30 Oct 2012 14:21:26 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id cs3sm876104qab.10.2012.10.30.14.21.25
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 30 Oct 2012 14:21:25 -0700 (PDT)
Date: Tue, 30 Oct 2012 17:08:55 -0400
From: Konrad Rzeszutek Wilk 
To: Roger Pau Monne 
Message-ID: <20121030210854.GD21481@phenom.dumpdata.com>
References: <1351508996-54975-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1351508996-54975-1-git-send-email-roger.pau@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] docs: document persistent grants
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Oct 29, 2012 at 12:09:56PM +0100, Roger Pau Monne wrote:
> Document the new persistent grants block-device feature.
> 
> Signed-off-by: Roger Pau Monne 
> ---
>  xen/include/public/io/blkif.h |   29 +++++++++++++++++++++++++++++
>  1 files changed, 29 insertions(+), 0 deletions(-)
> 
> diff --git a/xen/include/public/io/blkif.h b/xen/include/public/io/blkif.h
> index d71c7f1..accdda4 100644
> --- a/xen/include/public/io/blkif.h
> +++ b/xen/include/public/io/blkif.h
> @@ -126,6 +126,19 @@
>   *      of this type may still be returned at any time with the
>   *      BLKIF_RSP_EOPNOTSUPP result code.
>   *
> + * feature-persistent
> + *      Values:         0/1 (boolean)

That is not a boolean strickly. That would be 'true/false'. Perhaps 'int'?

> + *      Default Value:  0
> + *      Notes: 7
> + *
> + *      A value of "1" indicates that the backend can keep the grants used
> + *      by the frontend driver mapped, so the same set of grants should be
> + *      used in all transactions. The maximum number of grants the backend
> + *      can map persistently depends on the implementation, but ideally it
> + *      should be RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST. Using this
> + *      feature the backend doesn't need to unmap each grant, preventing
> + *      costly TLB flushes.
> + *
>   *----------------------- Request Transport Parameters ------------------------
>   *
>   * max-ring-page-order
> @@ -242,6 +255,15 @@
>   *      The size of the frontend allocated request ring buffer in units of
>   *      machine pages.  The value must be a power of 2.
>   *
> + * feature-persistent
> + *      Values:         0/1 (boolean)
> + *      Default Value:  0
> + *      Notes: 7, 8
> + *
> + *      A value of "1" indicates that the frontend will reuse the same grants
> + *      for all transactions, allowing the backend to map them with write
> + *      access (even when it should be read-only).
> + *
>   *------------------------- Virtual Device Properties -------------------------
>   *
>   * device-type
> @@ -279,6 +301,13 @@
>   *     'ring-ref' is used to communicate the grant reference for this
>   *     page to the backend.  When using a multi-page ring, the 'ring-ref'
>   *     node is not created.  Instead 'ring-ref0' - 'ring-refN' are used.
> + * (7) When using persistent grants data has to be copied from/to the page
> + *     where the grant is currently mapped. The overhead of doing this copy
> + *     however doesn't suppress the speed improvement of not having to unmap
> + *     the grants.
> + * (8) The frontend driver has to allow the backend driver to map all grants
> + *     with write access, even when they should be mapped read-only, since
> + *     further requests may reuse this grants and require write permisions.
>   */
>  
>  /*
> -- 
> 1.7.7.5 (Apple Git-26)
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 22:54:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 22:54:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTKgy-0001Ve-Ru; Tue, 30 Oct 2012 22:53:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTKgy-0001VZ-0h
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 22:53:52 +0000
Received: from [85.158.143.35:42193] by server-3.bemta-4.messagelabs.com id
	DB/75-06841-F7A50905; Tue, 30 Oct 2012 22:53:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1351637630!13868665!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY2MzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25294 invoked from network); 30 Oct 2012 22:53:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 22:53:50 -0000
X-IronPort-AV: E=Sophos;i="4.80,683,1344211200"; d="scan'208";a="15500325"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 22:53:49 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 30 Oct 2012 22:53:49 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TTKgv-0003WI-8i;
	Tue, 30 Oct 2012 22:53:49 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TTKgv-000819-8J;
	Tue, 30 Oct 2012 22:53:49 +0000
To: 
Message-ID: 
From: xen.org 
Date: Tue, 30 Oct 2012 22:53:49 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 14160: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14160 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14160/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl             9 guest-start               fail REGR. vs. 14076
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 14076
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 14076
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 14076

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore         fail REGR. vs. 14076

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  2bca7e58a3df
baseline version:
 xen                  40ccbee890e1

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla 
  Bastian Blank 
  Chuang Cao 
  George Dunlap 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jason McCarver 
  Joe Jin 
  Keir Fraser 
  Matt Wilson 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Sander Eikelenboom 
  Stefano Stabellini 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 632 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Oct 30 22:54:37 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 30 Oct 2012 22:54:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTKgy-0001Ve-Ru; Tue, 30 Oct 2012 22:53:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTKgy-0001VZ-0h
	for xen-devel@lists.xensource.com; Tue, 30 Oct 2012 22:53:52 +0000
Received: from [85.158.143.35:42193] by server-3.bemta-4.messagelabs.com id
	DB/75-06841-F7A50905; Tue, 30 Oct 2012 22:53:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1351637630!13868665!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY2MzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25294 invoked from network); 30 Oct 2012 22:53:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Oct 2012 22:53:50 -0000
X-IronPort-AV: E=Sophos;i="4.80,683,1344211200"; d="scan'208";a="15500325"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Oct 2012 22:53:49 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 30 Oct 2012 22:53:49 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TTKgv-0003WI-8i;
	Tue, 30 Oct 2012 22:53:49 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TTKgv-000819-8J;
	Tue, 30 Oct 2012 22:53:49 +0000
To: 
Message-ID: 
From: xen.org 
Date: Tue, 30 Oct 2012 22:53:49 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 14160: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14160 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14160/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl             9 guest-start               fail REGR. vs. 14076
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 14076
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 14076
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 14076

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore         fail REGR. vs. 14076

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  2bca7e58a3df
baseline version:
 xen                  40ccbee890e1

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla 
  Bastian Blank 
  Chuang Cao 
  George Dunlap 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jason McCarver 
  Joe Jin 
  Keir Fraser 
  Matt Wilson 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Sander Eikelenboom 
  Stefano Stabellini 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 632 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 02:47:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 02:47:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTOKg-0008DY-Fx; Wed, 31 Oct 2012 02:47:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTOKe-0008DT-F8
	for xen-devel@lists.xensource.com; Wed, 31 Oct 2012 02:47:04 +0000
Received: from [85.158.139.83:60392] by server-6.bemta-5.messagelabs.com id
	41/6D-32589-72190905; Wed, 31 Oct 2012 02:47:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1351651622!28047892!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY2MzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14479 invoked from network); 31 Oct 2012 02:47:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Oct 2012 02:47:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,683,1344211200"; d="scan'208";a="15501504"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Oct 2012 02:47:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 31 Oct 2012 02:47:01 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TTOKb-0005Hh-AW;
	Wed, 31 Oct 2012 02:47:01 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TTOKb-0001L7-5Z;
	Wed, 31 Oct 2012 02:47:01 +0000
To: 
Message-ID: 
From: xen.org 
Date: Wed, 31 Oct 2012 02:47:01 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14167: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14167 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14167/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 14154
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 14154
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 14154
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 14154

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  bf249cd5f2c1
baseline version:
 xen                  10feb0933708

------------------------------------------------------------
People who touched revisions under test:
  Christoph Egger 
  Ian Jackson 
  Jan Beulich 
  Keir Fraser 
  Roger Pau Monne 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=bf249cd5f2c1
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable bf249cd5f2c1
+ branch=xen-unstable
+ revision=bf249cd5f2c1
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r bf249cd5f2c1 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 5 changesets with 21 changes to 18 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 02:47:42 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 02:47:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTOKg-0008DY-Fx; Wed, 31 Oct 2012 02:47:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTOKe-0008DT-F8
	for xen-devel@lists.xensource.com; Wed, 31 Oct 2012 02:47:04 +0000
Received: from [85.158.139.83:60392] by server-6.bemta-5.messagelabs.com id
	41/6D-32589-72190905; Wed, 31 Oct 2012 02:47:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1351651622!28047892!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY2MzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14479 invoked from network); 31 Oct 2012 02:47:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Oct 2012 02:47:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,683,1344211200"; d="scan'208";a="15501504"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Oct 2012 02:47:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 31 Oct 2012 02:47:01 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TTOKb-0005Hh-AW;
	Wed, 31 Oct 2012 02:47:01 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TTOKb-0001L7-5Z;
	Wed, 31 Oct 2012 02:47:01 +0000
To: 
Message-ID: 
From: xen.org 
Date: Wed, 31 Oct 2012 02:47:01 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14167: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14167 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14167/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 14154
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 14154
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 14154
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 14154

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  bf249cd5f2c1
baseline version:
 xen                  10feb0933708

------------------------------------------------------------
People who touched revisions under test:
  Christoph Egger 
  Ian Jackson 
  Jan Beulich 
  Keir Fraser 
  Roger Pau Monne 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=bf249cd5f2c1
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable bf249cd5f2c1
+ branch=xen-unstable
+ revision=bf249cd5f2c1
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r bf249cd5f2c1 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 5 changesets with 21 changes to 18 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 03:48:35 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 03:48:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTPHh-0000dz-1H; Wed, 31 Oct 2012 03:48:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTPHf-0000dp-8L
	for xen-devel@lists.xensource.com; Wed, 31 Oct 2012 03:48:03 +0000
Received: from [85.158.143.35:42493] by server-2.bemta-4.messagelabs.com id
	3B/49-28922-27F90905; Wed, 31 Oct 2012 03:48:02 +0000
X-Env-Sender: syi@websense.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1351655279!5220063!1
X-Originating-IP: [208.87.233.190]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljg3LjIzMy4xOTAgPT4gMTgwNDc4OA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1072 invoked from network); 31 Oct 2012 03:48:01 -0000
Received: from cluster-g.mailcontrol.com (HELO cluster-g.mailcontrol.com)
	(208.87.233.190)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 31 Oct 2012 03:48:01 -0000
Received: from ssdwbsnapp.websense.com (static-204-15-65-158.websense.com
	[204.15.65.158] (may be forged))
	by rly17g.srv.mailcontrol.com (MailControl) with ESMTP id
	q9V3lwFO022244
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Wed, 31 Oct 2012 03:47:58 GMT
Received: from SSDEXCH1B.websense.com (unknown [10.8.2.91])
	by Websense Email Security Gateway with ESMTP id 8BC251000003
	for ;
	Tue, 30 Oct 2012 20:47:41 -0700 (PDT)
Received: from ssdexch3b.websense.com (10.8.3.134) by SSDEXCH1B.websense.com
	(10.8.2.91) with Microsoft SMTP Server (TLS) id 14.2.283.3;
	Tue, 30 Oct 2012 20:47:56 -0700
Received: from SBJEXCH2A.websense.com (10.32.8.111) by ssdexch3b.websense.com
	(10.8.3.169) with Microsoft SMTP Server (TLS) id 14.2.283.3;
	Tue, 30 Oct 2012 20:47:56 -0700
Received: from SBJEXCH1A.websense.com ([169.254.1.110]) by
	SBJEXCH2A.websense.com ([::1]) with mapi id 14.02.0283.003;
	Wed, 31 Oct 2012 11:47:48 +0800
From: "Yi, Shunli" 
To: "xen-devel@lists.xensource.com" 
Thread-Topic: Xennet half die---netfront TX queue was stopped.
Thread-Index: Ac23Gm/GoGh3r8OSR5q8PANust8HvA==
Date: Wed, 31 Oct 2012 03:47:53 +0000
Message-ID: <961EE662BA396D43898AFA993C8F01B77174A010@SBJEXCH1A.websense.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.32.134.106]
MIME-Version: 1.0
X-Scanned-By: MailControl 10515.0 (www.mailcontrol.com) on 10.71.0.127
Subject: [Xen-devel] Xennet half die---netfront TX queue was stopped.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============4563199296891497540=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4563199296891497540==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_961EE662BA396D43898AFA993C8F01B77174A010SBJEXCH1Awebsen_"

--_000_961EE662BA396D43898AFA993C8F01B77174A010SBJEXCH1Awebsen_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,
I encountered a strange issue, the xennet interface in DomU stopped sending=
 out anything in some rare cases.
I got chance to get more information on one reproduce, here are some findin=
gs.

The netfront driver check there isn't available TX slot any more, and it st=
opped the TX queue.

static inline int netfront_tx_slot_available(struct netfront_info *np)
{
    return ((np->tx.req_prod_pvt - np->tx.rsp_cons) <
        (TX_MAX_TARGET - MAX_SKB_FRAGS - 2));
}

Here is some runtime debugging information after that issue occurred:
[3833225.489956] tx.req_prod_pvt=3D0x210daaa tx.rsp_cons=3D0x210d9be
[3833225.489958] TX_MAX_TARGET =3D 0x100, MAX_SKB_FRAGS =3D 0x12 dev->state=
=3D0x7
[3833225.489961] np->tx.sring->rsp_prod =3D 0x210d9be np->tx.sring->req_pro=
d=3D0x210daaa
[3833225.489964] np->tx.sring->req_event=3D0x210d9bf np->tx.sring->rsp_even=
t=3D0x210da35

The "dev->state" of  xennet interface in DomU:
[3833225.489968] __LINK_STATE_XOFF:                                        =
        yes
[3833225.489970] __LINK_STATE_START:                                       =
       yes
[3833225.489971] __LINK_STATE_PRESENT:                                     =
    yes
[3833225.489973] __LINK_STATE_SCHED:                                       =
      no
[3833225.489975] __LINK_STATE_NOCARRIER:                                   =
no
[3833225.489976] __LINK_STATE_RX_SCHED:                                    =
  no
[3833225.489978] __LINK_STATE_LINKWATCH_PENDING:             no
[3833225.489979] __LINK_STATE_DORMANT:                                     =
no
[3833225.489981] __LINK_STATE_QDISC_RUNNING:                        no

Due to  tx.rsp_cons =3D=3D np->tx.sring->rsp_prod  =3D=3D 0x210d9be, the ne=
twork_tx_buf_gc() will do nothing.
The problem is, the TX queue will never been enable any more.

Could anybody helps to understand this, any inputs are appreciated.

The platform information:
Xen:     3.4.2                                        x86_64  8GB MEM + 8 C=
PU cores.
Dom0: 2.6.28.8(xenified  kernel)        x86      1 GB MEM + 1 CPU cores
DomU: 2.6.28.8(xenified  kernel)        x86      3 GB MEM + 2 CPU cores


Thanks,

-Shunli





 Protected by Websense Hosted Email Security -- www.websense.com=20

--_000_961EE662BA396D43898AFA993C8F01B77174A010SBJEXCH1Awebsen_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi,


I enc=
ountered a strange issue, the xennet interface in DomU stopped sending out =
anything in some rare cases.


I got=
 chance to get more information on one reproduce, here are some findings.



=
 


The n=
etfront driver check there isn’t available TX slot any more, and it s=
topped the TX queue.


 


static inline int netfront_tx_slot_available(stru=
ct netfront_info *np)


{


    return ((np->tx.req_prod_pv=
t - np->tx.rsp_cons) < 



        (=
TX_MAX_TARGET - MAX_SKB_FRAGS - 2));


}


 


Here =
is some runtime debugging information after that issue occurred:=





[3833225.489956] tx.req_prod_pvt=3D0x210daaa tx.rsp_=
cons=3D0x210d9be


[3833225.489958] TX_MAX_TARGET =3D 0x100, MAX_SKB_FR=
AGS =3D 0x12 dev->state=3D0x7


[3833225.489961] np->tx.sring->rsp_prod =3D 0x=
210d9be np->tx.sring->req_prod=3D0x210daaa


[3833225.489964] np->tx.sring->req_event=3D0x2=
10d9bf np->tx.sring->rsp_event=3D0x210da35


 


The &=
#8220;dev->state” of  xennet interface in DomU:


[3833225.489968] __LINK_STATE_XOFF:   &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;      yes


[3833225.489970] __LINK_STATE_START:   &nb=
sp;            =
            &nb=
sp;             =
;    yes


[3833225.489971] __LINK_STATE_PRESENT:   &=
nbsp;           &nbs=
p;            &=
nbsp;            yes=



[3833225.489973] __LINK_STATE_SCHED:   &nb=
sp;            =
            &nb=
sp;            =
    no


[3833225.489975] __LINK_STATE_NOCARRIER:   =
;            &n=
bsp;            =
;       no


[3833225.489976] __LINK_STATE_RX_SCHED:   =
            &nb=
sp;            =
          no


[3833225.489978] __LINK_STATE_LINKWATCH_PENDING: &nb=
sp;           no


[3833225.489979] __LINK_STATE_DORMANT:   &=
nbsp;           &nbs=
p;            &=
nbsp;        no


[3833225.489981] __LINK_STATE_QDISC_RUNNING:  &=
nbsp;           &nbs=
p;         no


 


Due t=
o  tx.rsp_cons =3D=3D np->tx.sring->rsp_prod  =3D=3D 0x210d=
9be, the network_tx_buf_gc() will do nothing.


The p=
roblem is, the TX queue will never been enable any more.<=
/p>

=
 


Could=
 anybody helps to understand this, any inputs are appreciated.


=
 


The p=
latform information:


Xen:&=
nbsp;    3.4.2          &=
nbsp;           &nbs=
p;            &=
nbsp;    x86_64  8GB MEM + 8 CPU cores.<=
/span>


Dom0:=
 2.6.28.8(xenified  kernel)        x86&n=
bsp;     1 GB MEM + 1 CPU cores

DomU:=
 2.6.28.8(xenified  kernel)        x86&n=
bsp;     3 GB MEM + 2 CPU cores

<t=
here are other two DomUs running without any problems>=



=
 


Thank=
s,


=
 


-Shun=
li



 


 


 







Protected by Websense Hosted Email Security =
212; www.websense.com




--_000_961EE662BA396D43898AFA993C8F01B77174A010SBJEXCH1Awebsen_--


--===============4563199296891497540==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4563199296891497540==--


From xen-devel-bounces@lists.xen.org Wed Oct 31 03:48:35 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 03:48:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTPHh-0000dz-1H; Wed, 31 Oct 2012 03:48:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTPHf-0000dp-8L
	for xen-devel@lists.xensource.com; Wed, 31 Oct 2012 03:48:03 +0000
Received: from [85.158.143.35:42493] by server-2.bemta-4.messagelabs.com id
	3B/49-28922-27F90905; Wed, 31 Oct 2012 03:48:02 +0000
X-Env-Sender: syi@websense.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1351655279!5220063!1
X-Originating-IP: [208.87.233.190]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljg3LjIzMy4xOTAgPT4gMTgwNDc4OA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1072 invoked from network); 31 Oct 2012 03:48:01 -0000
Received: from cluster-g.mailcontrol.com (HELO cluster-g.mailcontrol.com)
	(208.87.233.190)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 31 Oct 2012 03:48:01 -0000
Received: from ssdwbsnapp.websense.com (static-204-15-65-158.websense.com
	[204.15.65.158] (may be forged))
	by rly17g.srv.mailcontrol.com (MailControl) with ESMTP id
	q9V3lwFO022244
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Wed, 31 Oct 2012 03:47:58 GMT
Received: from SSDEXCH1B.websense.com (unknown [10.8.2.91])
	by Websense Email Security Gateway with ESMTP id 8BC251000003
	for ;
	Tue, 30 Oct 2012 20:47:41 -0700 (PDT)
Received: from ssdexch3b.websense.com (10.8.3.134) by SSDEXCH1B.websense.com
	(10.8.2.91) with Microsoft SMTP Server (TLS) id 14.2.283.3;
	Tue, 30 Oct 2012 20:47:56 -0700
Received: from SBJEXCH2A.websense.com (10.32.8.111) by ssdexch3b.websense.com
	(10.8.3.169) with Microsoft SMTP Server (TLS) id 14.2.283.3;
	Tue, 30 Oct 2012 20:47:56 -0700
Received: from SBJEXCH1A.websense.com ([169.254.1.110]) by
	SBJEXCH2A.websense.com ([::1]) with mapi id 14.02.0283.003;
	Wed, 31 Oct 2012 11:47:48 +0800
From: "Yi, Shunli" 
To: "xen-devel@lists.xensource.com" 
Thread-Topic: Xennet half die---netfront TX queue was stopped.
Thread-Index: Ac23Gm/GoGh3r8OSR5q8PANust8HvA==
Date: Wed, 31 Oct 2012 03:47:53 +0000
Message-ID: <961EE662BA396D43898AFA993C8F01B77174A010@SBJEXCH1A.websense.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.32.134.106]
MIME-Version: 1.0
X-Scanned-By: MailControl 10515.0 (www.mailcontrol.com) on 10.71.0.127
Subject: [Xen-devel] Xennet half die---netfront TX queue was stopped.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============4563199296891497540=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4563199296891497540==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_961EE662BA396D43898AFA993C8F01B77174A010SBJEXCH1Awebsen_"

--_000_961EE662BA396D43898AFA993C8F01B77174A010SBJEXCH1Awebsen_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,
I encountered a strange issue, the xennet interface in DomU stopped sending=
 out anything in some rare cases.
I got chance to get more information on one reproduce, here are some findin=
gs.

The netfront driver check there isn't available TX slot any more, and it st=
opped the TX queue.

static inline int netfront_tx_slot_available(struct netfront_info *np)
{
    return ((np->tx.req_prod_pvt - np->tx.rsp_cons) <
        (TX_MAX_TARGET - MAX_SKB_FRAGS - 2));
}

Here is some runtime debugging information after that issue occurred:
[3833225.489956] tx.req_prod_pvt=3D0x210daaa tx.rsp_cons=3D0x210d9be
[3833225.489958] TX_MAX_TARGET =3D 0x100, MAX_SKB_FRAGS =3D 0x12 dev->state=
=3D0x7
[3833225.489961] np->tx.sring->rsp_prod =3D 0x210d9be np->tx.sring->req_pro=
d=3D0x210daaa
[3833225.489964] np->tx.sring->req_event=3D0x210d9bf np->tx.sring->rsp_even=
t=3D0x210da35

The "dev->state" of  xennet interface in DomU:
[3833225.489968] __LINK_STATE_XOFF:                                        =
        yes
[3833225.489970] __LINK_STATE_START:                                       =
       yes
[3833225.489971] __LINK_STATE_PRESENT:                                     =
    yes
[3833225.489973] __LINK_STATE_SCHED:                                       =
      no
[3833225.489975] __LINK_STATE_NOCARRIER:                                   =
no
[3833225.489976] __LINK_STATE_RX_SCHED:                                    =
  no
[3833225.489978] __LINK_STATE_LINKWATCH_PENDING:             no
[3833225.489979] __LINK_STATE_DORMANT:                                     =
no
[3833225.489981] __LINK_STATE_QDISC_RUNNING:                        no

Due to  tx.rsp_cons =3D=3D np->tx.sring->rsp_prod  =3D=3D 0x210d9be, the ne=
twork_tx_buf_gc() will do nothing.
The problem is, the TX queue will never been enable any more.

Could anybody helps to understand this, any inputs are appreciated.

The platform information:
Xen:     3.4.2                                        x86_64  8GB MEM + 8 C=
PU cores.
Dom0: 2.6.28.8(xenified  kernel)        x86      1 GB MEM + 1 CPU cores
DomU: 2.6.28.8(xenified  kernel)        x86      3 GB MEM + 2 CPU cores


Thanks,

-Shunli





 Protected by Websense Hosted Email Security -- www.websense.com=20

--_000_961EE662BA396D43898AFA993C8F01B77174A010SBJEXCH1Awebsen_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi,


I enc=
ountered a strange issue, the xennet interface in DomU stopped sending out =
anything in some rare cases.


I got=
 chance to get more information on one reproduce, here are some findings.



=
 


The n=
etfront driver check there isn’t available TX slot any more, and it s=
topped the TX queue.


 


static inline int netfront_tx_slot_available(stru=
ct netfront_info *np)


{


    return ((np->tx.req_prod_pv=
t - np->tx.rsp_cons) < 



        (=
TX_MAX_TARGET - MAX_SKB_FRAGS - 2));


}


 


Here =
is some runtime debugging information after that issue occurred:=





[3833225.489956] tx.req_prod_pvt=3D0x210daaa tx.rsp_=
cons=3D0x210d9be


[3833225.489958] TX_MAX_TARGET =3D 0x100, MAX_SKB_FR=
AGS =3D 0x12 dev->state=3D0x7


[3833225.489961] np->tx.sring->rsp_prod =3D 0x=
210d9be np->tx.sring->req_prod=3D0x210daaa


[3833225.489964] np->tx.sring->req_event=3D0x2=
10d9bf np->tx.sring->rsp_event=3D0x210da35


 


The &=
#8220;dev->state” of  xennet interface in DomU:


[3833225.489968] __LINK_STATE_XOFF:   &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;      yes


[3833225.489970] __LINK_STATE_START:   &nb=
sp;            =
            &nb=
sp;             =
;    yes


[3833225.489971] __LINK_STATE_PRESENT:   &=
nbsp;           &nbs=
p;            &=
nbsp;            yes=



[3833225.489973] __LINK_STATE_SCHED:   &nb=
sp;            =
            &nb=
sp;            =
    no


[3833225.489975] __LINK_STATE_NOCARRIER:   =
;            &n=
bsp;            =
;       no


[3833225.489976] __LINK_STATE_RX_SCHED:   =
            &nb=
sp;            =
          no


[3833225.489978] __LINK_STATE_LINKWATCH_PENDING: &nb=
sp;           no


[3833225.489979] __LINK_STATE_DORMANT:   &=
nbsp;           &nbs=
p;            &=
nbsp;        no


[3833225.489981] __LINK_STATE_QDISC_RUNNING:  &=
nbsp;           &nbs=
p;         no


 


Due t=
o  tx.rsp_cons =3D=3D np->tx.sring->rsp_prod  =3D=3D 0x210d=
9be, the network_tx_buf_gc() will do nothing.


The p=
roblem is, the TX queue will never been enable any more.<=
/p>

=
 


Could=
 anybody helps to understand this, any inputs are appreciated.


=
 


The p=
latform information:


Xen:&=
nbsp;    3.4.2          &=
nbsp;           &nbs=
p;            &=
nbsp;    x86_64  8GB MEM + 8 CPU cores.<=
/span>


Dom0:=
 2.6.28.8(xenified  kernel)        x86&n=
bsp;     1 GB MEM + 1 CPU cores

DomU:=
 2.6.28.8(xenified  kernel)        x86&n=
bsp;     3 GB MEM + 2 CPU cores

<t=
here are other two DomUs running without any problems>=



=
 


Thank=
s,


=
 


-Shun=
li



 


 


 







Protected by Websense Hosted Email Security =
212; www.websense.com




--_000_961EE662BA396D43898AFA993C8F01B77174A010SBJEXCH1Awebsen_--


--===============4563199296891497540==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4563199296891497540==--


From xen-devel-bounces@lists.xen.org Wed Oct 31 05:20:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 05:20:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTQiH-0001nV-23; Wed, 31 Oct 2012 05:19:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTQiG-0001nQ-3k
	for xen-devel@lists.xensource.com; Wed, 31 Oct 2012 05:19:36 +0000
Received: from [85.158.143.99:30739] by server-2.bemta-4.messagelabs.com id
	C0/E7-28922-7E4B0905; Wed, 31 Oct 2012 05:19:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1351660774!21626130!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY2MzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24574 invoked from network); 31 Oct 2012 05:19:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Oct 2012 05:19:34 -0000
X-IronPort-AV: E=Sophos;i="4.80,685,1344211200"; d="scan'208";a="15502418"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Oct 2012 05:19:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 31 Oct 2012 05:19:32 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TTQiD-0006Pe-1G;
	Wed, 31 Oct 2012 05:19:33 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TTQiC-00043I-Qh;
	Wed, 31 Oct 2012 05:19:32 +0000
To: 
Message-ID: 
From: xen.org 
Date: Wed, 31 Oct 2012 05:19:32 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 14173: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14173 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14173/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl             9 guest-start               fail REGR. vs. 14076
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 14076
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 14076
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 14076

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore         fail REGR. vs. 14076

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  2bca7e58a3df
baseline version:
 xen                  40ccbee890e1

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla 
  Bastian Blank 
  Chuang Cao 
  George Dunlap 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jason McCarver 
  Joe Jin 
  Keir Fraser 
  Matt Wilson 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Sander Eikelenboom 
  Stefano Stabellini 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 632 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 05:20:11 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 05:20:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTQiH-0001nV-23; Wed, 31 Oct 2012 05:19:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTQiG-0001nQ-3k
	for xen-devel@lists.xensource.com; Wed, 31 Oct 2012 05:19:36 +0000
Received: from [85.158.143.99:30739] by server-2.bemta-4.messagelabs.com id
	C0/E7-28922-7E4B0905; Wed, 31 Oct 2012 05:19:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1351660774!21626130!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY2MzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24574 invoked from network); 31 Oct 2012 05:19:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Oct 2012 05:19:34 -0000
X-IronPort-AV: E=Sophos;i="4.80,685,1344211200"; d="scan'208";a="15502418"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Oct 2012 05:19:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 31 Oct 2012 05:19:32 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TTQiD-0006Pe-1G;
	Wed, 31 Oct 2012 05:19:33 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TTQiC-00043I-Qh;
	Wed, 31 Oct 2012 05:19:32 +0000
To: 
Message-ID: 
From: xen.org 
Date: Wed, 31 Oct 2012 05:19:32 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 14173: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14173 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14173/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl             9 guest-start               fail REGR. vs. 14076
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 14076
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 14076
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 14076

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore         fail REGR. vs. 14076

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  2bca7e58a3df
baseline version:
 xen                  40ccbee890e1

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla 
  Bastian Blank 
  Chuang Cao 
  George Dunlap 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jason McCarver 
  Joe Jin 
  Keir Fraser 
  Matt Wilson 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Sander Eikelenboom 
  Stefano Stabellini 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 632 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 08:02:44 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 08:02:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTTFY-00041c-5e; Wed, 31 Oct 2012 08:02:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTTFX-00041C-Im
	for xen-devel@lists.xen.org; Wed, 31 Oct 2012 08:02:07 +0000
Received: from [85.158.139.211:15804] by server-3.bemta-5.messagelabs.com id
	FC/B4-28618-EFAD0905; Wed, 31 Oct 2012 08:02:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1351670526!18330406!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4MjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20191 invoked from network); 31 Oct 2012 08:02:06 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-206.messagelabs.com with SMTP;
	31 Oct 2012 08:02:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 31 Oct 2012 08:02:05 +0000
Message-Id: <5090E93302000078000A59C8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 31 Oct 2012 08:02:43 +0000
From: "Jan Beulich" 
To: "Olaf Hering" 
References: <1351612057-21822-1-git-send-email-olaf@aepfle.de>
	<50900B1D02000078000A586C@nat28.tlf.novell.com>
	<20121030163006.GA26404@aepfle.de>
	<5090124C02000078000A58AC@nat28.tlf.novell.com>
	<20121030170321.GA1251@aepfle.de>
In-Reply-To: <20121030170321.GA1251@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeremy Fitzhardinge ,
	Konrad Rzeszutek Wilk ,
	linux-kernel@vger.kernel.org, xen-devel 
Subject: Re: [Xen-devel] [PATCH v4] xen PVonHVM: move shared_info to
 reserved memory area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 30.10.12 at 18:03, Olaf Hering  wrote:
> On Tue, Oct 30, Jan Beulich wrote:
> 
>> And iirc you're doing this relocation because otherwise the newly
>> booting kernel image may get overwritten at an (from its
>> perspective) arbitrary location. What I'm trying to point out is
>> that the shared info structure is not the only thing (potentially)
>> inside the kernel image that might get overwritten - the relocated
>> (by the old kernel) vCPU info may as well. Plus I think the new
>> kernel has no way of relocating it a second time (including back
>> into the shared info structure) with how the hypervisor works at
>> present.
> 
> Thanks, I have not looked at this, nor was I aware of it until now.
> I will see what needs to be done.
> 
> Is this also an issue with the xenlinux based PVonHVM code?

No - this code doesn't make use of that feature (yet, we've got
a feature request that would involve doing so), as it only ever
touches vCPU 0's info.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 08:02:44 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 08:02:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTTFY-00041c-5e; Wed, 31 Oct 2012 08:02:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTTFX-00041C-Im
	for xen-devel@lists.xen.org; Wed, 31 Oct 2012 08:02:07 +0000
Received: from [85.158.139.211:15804] by server-3.bemta-5.messagelabs.com id
	FC/B4-28618-EFAD0905; Wed, 31 Oct 2012 08:02:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1351670526!18330406!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4MjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20191 invoked from network); 31 Oct 2012 08:02:06 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-206.messagelabs.com with SMTP;
	31 Oct 2012 08:02:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 31 Oct 2012 08:02:05 +0000
Message-Id: <5090E93302000078000A59C8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 31 Oct 2012 08:02:43 +0000
From: "Jan Beulich" 
To: "Olaf Hering" 
References: <1351612057-21822-1-git-send-email-olaf@aepfle.de>
	<50900B1D02000078000A586C@nat28.tlf.novell.com>
	<20121030163006.GA26404@aepfle.de>
	<5090124C02000078000A58AC@nat28.tlf.novell.com>
	<20121030170321.GA1251@aepfle.de>
In-Reply-To: <20121030170321.GA1251@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeremy Fitzhardinge ,
	Konrad Rzeszutek Wilk ,
	linux-kernel@vger.kernel.org, xen-devel 
Subject: Re: [Xen-devel] [PATCH v4] xen PVonHVM: move shared_info to
 reserved memory area
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 30.10.12 at 18:03, Olaf Hering  wrote:
> On Tue, Oct 30, Jan Beulich wrote:
> 
>> And iirc you're doing this relocation because otherwise the newly
>> booting kernel image may get overwritten at an (from its
>> perspective) arbitrary location. What I'm trying to point out is
>> that the shared info structure is not the only thing (potentially)
>> inside the kernel image that might get overwritten - the relocated
>> (by the old kernel) vCPU info may as well. Plus I think the new
>> kernel has no way of relocating it a second time (including back
>> into the shared info structure) with how the hypervisor works at
>> present.
> 
> Thanks, I have not looked at this, nor was I aware of it until now.
> I will see what needs to be done.
> 
> Is this also an issue with the xenlinux based PVonHVM code?

No - this code doesn't make use of that feature (yet, we've got
a feature request that would involve doing so), as it only ever
touches vCPU 0's info.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 08:14:40 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 08:14:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTTR6-0004Gf-M9; Wed, 31 Oct 2012 08:14:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTTR5-0004Ga-7Q
	for xen-devel@lists.xen.org; Wed, 31 Oct 2012 08:14:03 +0000
Received: from [85.158.143.35:50303] by server-3.bemta-4.messagelabs.com id
	CE/80-06841-ACDD0905; Wed, 31 Oct 2012 08:14:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1351671240!11774453!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4MjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23049 invoked from network); 31 Oct 2012 08:14:01 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-21.messagelabs.com with SMTP;
	31 Oct 2012 08:14:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 31 Oct 2012 08:13:59 +0000
Message-Id: <5090EBFE02000078000A59DD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 31 Oct 2012 08:14:38 +0000
From: "Jan Beulich" 
To: "Dan Magenheimer" 
References: <60d00f38-98a3-4ec2-acbd-b49dafaada56@default>
	<20121029223555.GA24388@ocelot.phlegethon.org>
	
	<508F9DE902000078000A5565@nat28.tlf.novell.com>
	
	<509008A502000078000A584E@nat28.tlf.novell.com>
	
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan , Olaf Hering ,
	"Keir\(Xen.org\)" , IanCampbell ,
	Konrad Wilk ,
	GeorgeDunlap ,
	IanJackson ,
	George Shuklin ,
	xen-devel@lists.xen.org, DarioFaggioli ,
	Kurt Hackel ,
	Zhigang Wang 
Subject: Re: [Xen-devel] Proposed new "memory capacity claim"
	hypercall/feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 30.10.12 at 18:13, Dan Magenheimer  wrote:
>>  From: Jan Beulich [mailto:JBeulich@suse.com]
>> With tmem being the odd one here, wouldn't it make more sense
>> to force it into no-alloc mode (apparently not exactly the same as
>> freezing all pools) for the (infrequent?) time periods of domain
>> creation, thus not allowing the amount of free memory to drop
>> unexpectedly? Tmem could, during these time periods, still itself
>> internally recycle pages (e.g. fulfill a persistent put by discarding
>> an ephemeral page).
> 
> Freeze has some unattractive issues that "claim" would solve
> (see below) and freeze (whether ephemeral pages are used or not)
> blocks allocations due to tmem, but doesn't block allocations due
> to selfballooning (or manual ballooning attempts by a guest user
> with root access).  I suppose the tmem freeze implementation could
> be extended to also block all non-domain-creation ballooning
> attempts but I'm not sure if that's what you are proposing.
> 
> To digress for a moment first, the original problem exists both in
> non-tmem systems AND tmem systems.  It has been seen in the wild on
> non-tmem systems.  I am involved with proposing a solution primarily
> because, if the solution is designed correctly, it _also_ solves a
> tmem problem.  (And as long as we have digressed, I believe it _also_
> solves a page-sharing problem on non-tmem systems.)  That said,
> here's the unattractive tmem freeze/thaw issue, first with
> the existing freeze implementation.
> 
> Suppose you have a huge 256GB machine and you have already launched
> a 64GB tmem guest "A".  The guest is idle for now, so slowly
> selfballoons down to maybe 4GB.  You start to launch another 64GB
> guest "B" which, as we know, is going to take some time to complete.
> In the middle of launching "B", "A" suddenly gets very active and
> needs to balloon up as quickly as possible or it can't balloon fast
> enough (or at all if "frozen" as suggested) so starts swapping (and,
> thanks to Linux frontswap, the swapping tries to go to hypervisor/tmem
> memory).  But ballooning and tmem are both blocked and so the
> guest swaps its poor little butt off even though there's >100GB
> of free physical memory available.

That's only one side of the overcommit situation you're striving
to get work right here: That same self ballooning guest, after
sufficiently more guest got started so that the rest of the memory
got absorbed by them would suffer the very same problems in
the described situation, so it has to be prepared for this case
anyway.

As long as the allocation times can get brought down to an
acceptable level, I continue to not see a need for the extra
"claim" approach you're proposing. So working on that one (or
showing that without unreasonable effort this cannot be
further improved) would be a higher priority thing from my pov
(without anyone arguing about its usefulness).

But yes, with all the factors you mention brought in, there is
certainly some improvement needed (whether your "claim"
proposal is a the right thing is another question, not to mention
that I currently don't see how this would get implemented in
a consistent way taking several orders of magnitude less time
to carry out).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 08:14:40 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 08:14:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTTR6-0004Gf-M9; Wed, 31 Oct 2012 08:14:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTTR5-0004Ga-7Q
	for xen-devel@lists.xen.org; Wed, 31 Oct 2012 08:14:03 +0000
Received: from [85.158.143.35:50303] by server-3.bemta-4.messagelabs.com id
	CE/80-06841-ACDD0905; Wed, 31 Oct 2012 08:14:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1351671240!11774453!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4MjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23049 invoked from network); 31 Oct 2012 08:14:01 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-21.messagelabs.com with SMTP;
	31 Oct 2012 08:14:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 31 Oct 2012 08:13:59 +0000
Message-Id: <5090EBFE02000078000A59DD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 31 Oct 2012 08:14:38 +0000
From: "Jan Beulich" 
To: "Dan Magenheimer" 
References: <60d00f38-98a3-4ec2-acbd-b49dafaada56@default>
	<20121029223555.GA24388@ocelot.phlegethon.org>
	
	<508F9DE902000078000A5565@nat28.tlf.novell.com>
	
	<509008A502000078000A584E@nat28.tlf.novell.com>
	
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan , Olaf Hering ,
	"Keir\(Xen.org\)" , IanCampbell ,
	Konrad Wilk ,
	GeorgeDunlap ,
	IanJackson ,
	George Shuklin ,
	xen-devel@lists.xen.org, DarioFaggioli ,
	Kurt Hackel ,
	Zhigang Wang 
Subject: Re: [Xen-devel] Proposed new "memory capacity claim"
	hypercall/feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 30.10.12 at 18:13, Dan Magenheimer  wrote:
>>  From: Jan Beulich [mailto:JBeulich@suse.com]
>> With tmem being the odd one here, wouldn't it make more sense
>> to force it into no-alloc mode (apparently not exactly the same as
>> freezing all pools) for the (infrequent?) time periods of domain
>> creation, thus not allowing the amount of free memory to drop
>> unexpectedly? Tmem could, during these time periods, still itself
>> internally recycle pages (e.g. fulfill a persistent put by discarding
>> an ephemeral page).
> 
> Freeze has some unattractive issues that "claim" would solve
> (see below) and freeze (whether ephemeral pages are used or not)
> blocks allocations due to tmem, but doesn't block allocations due
> to selfballooning (or manual ballooning attempts by a guest user
> with root access).  I suppose the tmem freeze implementation could
> be extended to also block all non-domain-creation ballooning
> attempts but I'm not sure if that's what you are proposing.
> 
> To digress for a moment first, the original problem exists both in
> non-tmem systems AND tmem systems.  It has been seen in the wild on
> non-tmem systems.  I am involved with proposing a solution primarily
> because, if the solution is designed correctly, it _also_ solves a
> tmem problem.  (And as long as we have digressed, I believe it _also_
> solves a page-sharing problem on non-tmem systems.)  That said,
> here's the unattractive tmem freeze/thaw issue, first with
> the existing freeze implementation.
> 
> Suppose you have a huge 256GB machine and you have already launched
> a 64GB tmem guest "A".  The guest is idle for now, so slowly
> selfballoons down to maybe 4GB.  You start to launch another 64GB
> guest "B" which, as we know, is going to take some time to complete.
> In the middle of launching "B", "A" suddenly gets very active and
> needs to balloon up as quickly as possible or it can't balloon fast
> enough (or at all if "frozen" as suggested) so starts swapping (and,
> thanks to Linux frontswap, the swapping tries to go to hypervisor/tmem
> memory).  But ballooning and tmem are both blocked and so the
> guest swaps its poor little butt off even though there's >100GB
> of free physical memory available.

That's only one side of the overcommit situation you're striving
to get work right here: That same self ballooning guest, after
sufficiently more guest got started so that the rest of the memory
got absorbed by them would suffer the very same problems in
the described situation, so it has to be prepared for this case
anyway.

As long as the allocation times can get brought down to an
acceptable level, I continue to not see a need for the extra
"claim" approach you're proposing. So working on that one (or
showing that without unreasonable effort this cannot be
further improved) would be a higher priority thing from my pov
(without anyone arguing about its usefulness).

But yes, with all the factors you mention brought in, there is
certainly some improvement needed (whether your "claim"
proposal is a the right thing is another question, not to mention
that I currently don't see how this would get implemented in
a consistent way taking several orders of magnitude less time
to carry out).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 08:32:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 08:32:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTTig-0004a9-Oh; Wed, 31 Oct 2012 08:32:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTTif-0004a4-3a
	for xen-devel@lists.xensource.com; Wed, 31 Oct 2012 08:32:13 +0000
Received: from [85.158.137.99:18809] by server-12.bemta-3.messagelabs.com id
	34/57-27853-C02E0905; Wed, 31 Oct 2012 08:32:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1351672330!13959142!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODI0Nzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23560 invoked from network); 31 Oct 2012 08:32:11 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Oct 2012 08:32:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,685,1344211200"; d="scan'208";a="212957791"
Received: from unknown (HELO FTLPEX01CL03.citrite.net) ([10.13.107.80])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	31 Oct 2012 08:32:10 +0000
Received: from [127.0.0.1] (10.80.16.67) by FTLPEX01CL03.citrite.net
	(10.13.107.77) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 31 Oct 2012 04:32:09 -0400
Message-ID: <1351672212.20470.7.camel@hastur.hellion.org.uk>
From: Ian Campbell 
To: Olaf Hering 
Date: Wed, 31 Oct 2012 09:30:12 +0100
In-Reply-To: <20121030182859.GA8775@aepfle.de>
References: <1351613105-24408-1-git-send-email-olaf@aepfle.de>
	<20121030181732.GZ8912@reaktio.net> <20121030182859.GA8775@aepfle.de>
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
X-Originating-IP: [10.80.16.67]
Cc: Jeremy Fitzhardinge ,
	"xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH] xen PVonHVM: require at least Xen 3.4 as
 dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCAyMDEyLTEwLTMwIGF0IDE4OjI4ICswMDAwLCBPbGFmIEhlcmluZyB3cm90ZToKPiBP
biBUdWUsIE9jdCAzMCwgUGFzaSBLw6Rya2vDpGluZW4gd3JvdGU6Cj4gCj4gPiBPbiBUdWUsIE9j
dCAzMCwgMjAxMiBhdCAwNTowNTowNVBNICswMTAwLCBPbGFmIEhlcmluZyB3cm90ZToKPiA+ID4g
VGhlIFhlblBWSFZNIGV4dGVuc2lvbnMgaGF2ZSBub3QgYmVlbiB0ZXN0ZWQgbXVjaCBvbiB2ZXJ5
IG9sZAo+ID4gPiBoeXBlcnZpc29ycy4gQXQgbGVhc3QgWGVuIDMuNCBnZXRzIHNvbWUgdGVzdGlu
ZyB3aXRoIHRoZSBwdm9wcyBrZXJuZWwuCj4gPiA+IAo+ID4gPiBSZXF1aXJlIGF0IGxlYXN0IFhl
biAzLjQgZm9yIHRoZSBQVm9uSFZNIGV4dGVuc2lvbnMuIElmIGFuIG9sZGVyCj4gPiA+IGh5cGVy
dmlzb3IgaXMgZGV0ZWN0ZWQgdGhlIGV4dGVuc2lvbnMgd2lsbCBiZSBkaXNhYmxlZCBhbmQgdGhl
IGd1ZXN0Cj4gPiA+IHdpbGwgb25seSBzZWUgZW11bGF0ZWQgaGFyZHdhcmUuCj4gPiA+IAo+ID4g
PiBTaWduZWQtb2ZmLWJ5OiBPbGFmIEhlcmluZyA8b2xhZkBhZXBmbGUuZGU+Cj4gPiA+Cj4gPiAK
PiA+IElJUkMgdXBzdHJlYW0gTGludXggUFZvbkhWTSBkcml2ZXJzIGRvIHdvcmsgT0sgdG9kYXkg
b24gUkhFTDUgWGVuLCAKPiA+IHdoaWNoIGFkdmVydGlzZXMgaXRzZWxmIGFzIFhlbiAzLjEuMi1i
YXNlZC4uCj4gCj4gSWYgdGhhdHMgdGhlIGNhc2UsIGFuZCBhIGNvbWJpbmF0aW9uIHRoYXRzIHN1
cHBvc2VkIHRvIHdvcmssIHRoZSBwYXRjaAo+IGNhbiBiZSBkcm9wcGVkIGlmIHRoZSBodm1sb2Fk
ZXIgZG9lcyByZWFsbHkgbGVhdmUgcm9vbSBhdAo+IEZFNzAwMDAwLUZFODAwMDAwLgoKSWYgSSB1
bmRlcnN0YW5kIGNvcnJlY3RseSB0aGlzIHJlcXVpcmVtZW50cyBjb21lcyBmcm9tIHRoZSBuZWVk
IHRvCnN1cHBvcnQgbW92aW5nIHRoZSBzaGFyZWQgaW5mbyBwYWdlIGluIG9yZGVyIHRvIHN1cHBv
cnQga2V4ZWM/CgpTbyBjb3VsZCB3ZSBkbyBzb21ldGhpbmcgbW9yZSBmaW5lIGdyYWluZWQgYW5k
IGxpbWl0IG9ubHkgdGhlIGtleGVjCnN1cHBvcnQgKGFuZCB0aGVyZWZvcmUgdGhlIG1vdmVtZW50
IG9mIHRoZSBTSSBpbnRvIHRoYXQgcmFuZ2UpIHRvIDMuNCs/CgpJYW4uCgo+IAo+IE9sYWYKPiAK
PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IFhlbi1k
ZXZlbCBtYWlsaW5nIGxpc3QKPiBYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwo+IGh0dHA6Ly9saXN0
cy54ZW4ub3JnL3hlbi1kZXZlbAoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4u
b3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Oct 31 08:32:41 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 08:32:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTTig-0004a9-Oh; Wed, 31 Oct 2012 08:32:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTTif-0004a4-3a
	for xen-devel@lists.xensource.com; Wed, 31 Oct 2012 08:32:13 +0000
Received: from [85.158.137.99:18809] by server-12.bemta-3.messagelabs.com id
	34/57-27853-C02E0905; Wed, 31 Oct 2012 08:32:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1351672330!13959142!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODI0Nzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23560 invoked from network); 31 Oct 2012 08:32:11 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Oct 2012 08:32:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,685,1344211200"; d="scan'208";a="212957791"
Received: from unknown (HELO FTLPEX01CL03.citrite.net) ([10.13.107.80])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	31 Oct 2012 08:32:10 +0000
Received: from [127.0.0.1] (10.80.16.67) by FTLPEX01CL03.citrite.net
	(10.13.107.77) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 31 Oct 2012 04:32:09 -0400
Message-ID: <1351672212.20470.7.camel@hastur.hellion.org.uk>
From: Ian Campbell 
To: Olaf Hering 
Date: Wed, 31 Oct 2012 09:30:12 +0100
In-Reply-To: <20121030182859.GA8775@aepfle.de>
References: <1351613105-24408-1-git-send-email-olaf@aepfle.de>
	<20121030181732.GZ8912@reaktio.net> <20121030182859.GA8775@aepfle.de>
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
X-Originating-IP: [10.80.16.67]
Cc: Jeremy Fitzhardinge ,
	"xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH] xen PVonHVM: require at least Xen 3.4 as
 dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCAyMDEyLTEwLTMwIGF0IDE4OjI4ICswMDAwLCBPbGFmIEhlcmluZyB3cm90ZToKPiBP
biBUdWUsIE9jdCAzMCwgUGFzaSBLw6Rya2vDpGluZW4gd3JvdGU6Cj4gCj4gPiBPbiBUdWUsIE9j
dCAzMCwgMjAxMiBhdCAwNTowNTowNVBNICswMTAwLCBPbGFmIEhlcmluZyB3cm90ZToKPiA+ID4g
VGhlIFhlblBWSFZNIGV4dGVuc2lvbnMgaGF2ZSBub3QgYmVlbiB0ZXN0ZWQgbXVjaCBvbiB2ZXJ5
IG9sZAo+ID4gPiBoeXBlcnZpc29ycy4gQXQgbGVhc3QgWGVuIDMuNCBnZXRzIHNvbWUgdGVzdGlu
ZyB3aXRoIHRoZSBwdm9wcyBrZXJuZWwuCj4gPiA+IAo+ID4gPiBSZXF1aXJlIGF0IGxlYXN0IFhl
biAzLjQgZm9yIHRoZSBQVm9uSFZNIGV4dGVuc2lvbnMuIElmIGFuIG9sZGVyCj4gPiA+IGh5cGVy
dmlzb3IgaXMgZGV0ZWN0ZWQgdGhlIGV4dGVuc2lvbnMgd2lsbCBiZSBkaXNhYmxlZCBhbmQgdGhl
IGd1ZXN0Cj4gPiA+IHdpbGwgb25seSBzZWUgZW11bGF0ZWQgaGFyZHdhcmUuCj4gPiA+IAo+ID4g
PiBTaWduZWQtb2ZmLWJ5OiBPbGFmIEhlcmluZyA8b2xhZkBhZXBmbGUuZGU+Cj4gPiA+Cj4gPiAK
PiA+IElJUkMgdXBzdHJlYW0gTGludXggUFZvbkhWTSBkcml2ZXJzIGRvIHdvcmsgT0sgdG9kYXkg
b24gUkhFTDUgWGVuLCAKPiA+IHdoaWNoIGFkdmVydGlzZXMgaXRzZWxmIGFzIFhlbiAzLjEuMi1i
YXNlZC4uCj4gCj4gSWYgdGhhdHMgdGhlIGNhc2UsIGFuZCBhIGNvbWJpbmF0aW9uIHRoYXRzIHN1
cHBvc2VkIHRvIHdvcmssIHRoZSBwYXRjaAo+IGNhbiBiZSBkcm9wcGVkIGlmIHRoZSBodm1sb2Fk
ZXIgZG9lcyByZWFsbHkgbGVhdmUgcm9vbSBhdAo+IEZFNzAwMDAwLUZFODAwMDAwLgoKSWYgSSB1
bmRlcnN0YW5kIGNvcnJlY3RseSB0aGlzIHJlcXVpcmVtZW50cyBjb21lcyBmcm9tIHRoZSBuZWVk
IHRvCnN1cHBvcnQgbW92aW5nIHRoZSBzaGFyZWQgaW5mbyBwYWdlIGluIG9yZGVyIHRvIHN1cHBv
cnQga2V4ZWM/CgpTbyBjb3VsZCB3ZSBkbyBzb21ldGhpbmcgbW9yZSBmaW5lIGdyYWluZWQgYW5k
IGxpbWl0IG9ubHkgdGhlIGtleGVjCnN1cHBvcnQgKGFuZCB0aGVyZWZvcmUgdGhlIG1vdmVtZW50
IG9mIHRoZSBTSSBpbnRvIHRoYXQgcmFuZ2UpIHRvIDMuNCs/CgpJYW4uCgo+IAo+IE9sYWYKPiAK
PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IFhlbi1k
ZXZlbCBtYWlsaW5nIGxpc3QKPiBYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwo+IGh0dHA6Ly9saXN0
cy54ZW4ub3JnL3hlbi1kZXZlbAoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4u
b3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Oct 31 08:55:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 08:55:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTU5D-0004w0-2M; Wed, 31 Oct 2012 08:55:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTU5B-0004vv-9R
	for xen-devel@lists.xen.org; Wed, 31 Oct 2012 08:55:29 +0000
Received: from [193.109.254.147:37436] by server-13.bemta-14.messagelabs.com
	id 9A/66-11239-087E0905; Wed, 31 Oct 2012 08:55:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1351673722!6424868!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4MjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2200 invoked from network); 31 Oct 2012 08:55:22 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-27.messagelabs.com with SMTP;
	31 Oct 2012 08:55:22 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 31 Oct 2012 08:55:17 +0000
Message-Id: <5090F5AA02000078000A5A0B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 31 Oct 2012 08:55:54 +0000
From: "Jan Beulich" 
To: "Konrad Rzeszutek Wilk" 
References: <1351519698-11069-1-git-send-email-konrad.wilk@oracle.com>
	<1351519698-11069-2-git-send-email-konrad.wilk@oracle.com>
	<20121030154450.GA3000@phenom.dumpdata.com>
In-Reply-To: <20121030154450.GA3000@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: linux-kernel@vger.kernel.org, xen-devel 
Subject: Re: [Xen-devel] [PATCH 1/2] xen/hypercall: fix hypercall fallback
 code for very old hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 30.10.12 at 16:44, Konrad Rzeszutek Wilk  wrote:
> On Mon, Oct 29, 2012 at 10:08:17AM -0400, Konrad Rzeszutek Wilk wrote:
>> From: Jan Beulich 
>> 
>> While copying the argument structures in HYPERVISOR_event_channel_op()
>> and HYPERVISOR_physdev_op() into the local variable is sufficiently
>> safe even if the actual structure is smaller than the container one,
>> copying back eventual output values the same way isn't: This may
>> collide with on-stack variables (particularly "rc") which may change
>> between the first and second memcpy() (i.e. the second memcpy() could
>> discard that change).
>> 
>> Move the fallback code into out-of-line functions, and handle all of
>> the operations known by this old a hypervisor individually: Some don't
>> require copying back anything at all, and for the rest use the
>> individual argument structures' sizes rather than the container's.
>> 
>> Reported-by: Dan Carpenter 
>> Signed-off-by: Jan Beulich 
>> [v2: Reduce #define/#undef usage in HYPERVISOR_physdev_op_compat().]
>> Signed-off-by: Konrad Rzeszutek Wilk 
> 
> And it looks like I get 
> 
> ERROR: "HYPERVISOR_event_channel_op_compat" [drivers/xen/xen-evtchn.ko] 
> undefined!
> 
> when I build xen-evtchn as module. Jan did you encounter this issue on 
> 2.6.18?

No - the event channel driver there can't be built as a module, and
for the forward ported kernels I apparently never tried to build with
a compat setting of 3.0.2 or less (and I didn't care that much either
because the oldest we're actually concerned about is 3.0.4 to cover
some of those very old EC2 systems; I'll add the export at the right
point nevertheless).

Jan

>> ---
>>  arch/x86/include/asm/xen/hypercall.h |   21 +++------
>>  drivers/xen/Makefile                 |    2 +-
>>  drivers/xen/fallback.c               |   78 
> ++++++++++++++++++++++++++++++++++
>>  3 files changed, 86 insertions(+), 15 deletions(-)
>>  create mode 100644 drivers/xen/fallback.c
>> 
>> diff --git a/arch/x86/include/asm/xen/hypercall.h 
> b/arch/x86/include/asm/xen/hypercall.h
>> index 59c226d..c812360 100644
>> --- a/arch/x86/include/asm/xen/hypercall.h
>> +++ b/arch/x86/include/asm/xen/hypercall.h
>> @@ -359,18 +359,14 @@ HYPERVISOR_update_va_mapping(unsigned long va, pte_t 
> new_val,
>>  		return _hypercall4(int, update_va_mapping, va,
>>  				   new_val.pte, new_val.pte >> 32, flags);
>>  }
>> +int __must_check HYPERVISOR_event_channel_op_compat(int, void *);
>>  
>>  static inline int
>>  HYPERVISOR_event_channel_op(int cmd, void *arg)
>>  {
>>  	int rc = _hypercall2(int, event_channel_op, cmd, arg);
>> -	if (unlikely(rc == -ENOSYS)) {
>> -		struct evtchn_op op;
>> -		op.cmd = cmd;
>> -		memcpy(&op.u, arg, sizeof(op.u));
>> -		rc = _hypercall1(int, event_channel_op_compat, &op);
>> -		memcpy(arg, &op.u, sizeof(op.u));
>> -	}
>> +	if (unlikely(rc == -ENOSYS))
>> +		rc = HYPERVISOR_event_channel_op_compat(cmd, arg);
>>  	return rc;
>>  }
>>  
>> @@ -386,17 +382,14 @@ HYPERVISOR_console_io(int cmd, int count, char *str)
>>  	return _hypercall3(int, console_io, cmd, count, str);
>>  }
>>  
>> +int __must_check HYPERVISOR_physdev_op_compat(int, void *);
>> +
>>  static inline int
>>  HYPERVISOR_physdev_op(int cmd, void *arg)
>>  {
>>  	int rc = _hypercall2(int, physdev_op, cmd, arg);
>> -	if (unlikely(rc == -ENOSYS)) {
>> -		struct physdev_op op;
>> -		op.cmd = cmd;
>> -		memcpy(&op.u, arg, sizeof(op.u));
>> -		rc = _hypercall1(int, physdev_op_compat, &op);
>> -		memcpy(arg, &op.u, sizeof(op.u));
>> -	}
>> +	if (unlikely(rc == -ENOSYS))
>> +		rc = HYPERVISOR_physdev_op_compat(cmd, arg);
>>  	return rc;
>>  }
>>  
>> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
>> index 0e863703..46de6cd 100644
>> --- a/drivers/xen/Makefile
>> +++ b/drivers/xen/Makefile
>> @@ -2,7 +2,7 @@ ifneq ($(CONFIG_ARM),y)
>>  obj-y	+= manage.o balloon.o
>>  obj-$(CONFIG_HOTPLUG_CPU)		+= cpu_hotplug.o
>>  endif
>> -obj-y	+= grant-table.o features.o events.o
>> +obj-y	+= grant-table.o features.o events.o fallback.o
>>  obj-y	+= xenbus/
>>  
>>  nostackp := $(call cc-option, -fno-stack-protector)
>> diff --git a/drivers/xen/fallback.c b/drivers/xen/fallback.c
>> new file mode 100644
>> index 0000000..0bdc468
>> --- /dev/null
>> +++ b/drivers/xen/fallback.c
>> @@ -0,0 +1,78 @@
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +int HYPERVISOR_event_channel_op_compat(int cmd, void *arg)
>> +{
>> +	struct evtchn_op op;
>> +	int rc;
>> +
>> +	op.cmd = cmd;
>> +	memcpy(&op.u, arg, sizeof(op.u));
>> +	rc = _hypercall1(int, event_channel_op_compat, &op);
>> +
>> +	switch (cmd) {
>> +	case EVTCHNOP_close:
>> +	case EVTCHNOP_send:
>> +	case EVTCHNOP_bind_vcpu:
>> +	case EVTCHNOP_unmask:
>> +		/* no output */
>> +		break;
>> +
>> +#define COPY_BACK(eop) \
>> +	case EVTCHNOP_##eop: \
>> +		memcpy(arg, &op.u.eop, sizeof(op.u.eop)); \
>> +		break
>> +
>> +	COPY_BACK(bind_interdomain);
>> +	COPY_BACK(bind_virq);
>> +	COPY_BACK(bind_pirq);
>> +	COPY_BACK(status);
>> +	COPY_BACK(alloc_unbound);
>> +	COPY_BACK(bind_ipi);
>> +#undef COPY_BACK
>> +
>> +	default:
>> +		WARN_ON(rc != -ENOSYS);
>> +		break;
>> +	}
>> +
>> +	return rc;
>> +}
>> +
>> +int HYPERVISOR_physdev_op_compat(int cmd, void *arg)
>> +{
>> +	struct physdev_op op;
>> +	int rc;
>> +
>> +	op.cmd = cmd;
>> +	memcpy(&op.u, arg, sizeof(op.u));
>> +	rc = _hypercall1(int, physdev_op_compat, &op);
>> +
>> +	switch (cmd) {
>> +	case PHYSDEVOP_IRQ_UNMASK_NOTIFY:
>> +	case PHYSDEVOP_set_iopl:
>> +	case PHYSDEVOP_set_iobitmap:
>> +	case PHYSDEVOP_apic_write:
>> +		/* no output */
>> +		break;
>> +
>> +#define COPY_BACK(pop, fld) \
>> +	case PHYSDEVOP_##pop: \
>> +		memcpy(arg, &op.u.fld, sizeof(op.u.fld)); \
>> +		break
>> +
>> +	COPY_BACK(irq_status_query, irq_status_query);
>> +	COPY_BACK(apic_read, apic_op);
>> +	COPY_BACK(ASSIGN_VECTOR, irq_op);
>> +#undef COPY_BACK
>> +
>> +	default:
>> +		WARN_ON(rc != -ENOSYS);
>> +		break;
>> +	}
>> +
>> +	return rc;
>> +}
>> -- 
>> 1.7.7.6



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 08:55:55 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 08:55:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTU5D-0004w0-2M; Wed, 31 Oct 2012 08:55:31 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTU5B-0004vv-9R
	for xen-devel@lists.xen.org; Wed, 31 Oct 2012 08:55:29 +0000
Received: from [193.109.254.147:37436] by server-13.bemta-14.messagelabs.com
	id 9A/66-11239-087E0905; Wed, 31 Oct 2012 08:55:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1351673722!6424868!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4MjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2200 invoked from network); 31 Oct 2012 08:55:22 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-27.messagelabs.com with SMTP;
	31 Oct 2012 08:55:22 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 31 Oct 2012 08:55:17 +0000
Message-Id: <5090F5AA02000078000A5A0B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 31 Oct 2012 08:55:54 +0000
From: "Jan Beulich" 
To: "Konrad Rzeszutek Wilk" 
References: <1351519698-11069-1-git-send-email-konrad.wilk@oracle.com>
	<1351519698-11069-2-git-send-email-konrad.wilk@oracle.com>
	<20121030154450.GA3000@phenom.dumpdata.com>
In-Reply-To: <20121030154450.GA3000@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: linux-kernel@vger.kernel.org, xen-devel 
Subject: Re: [Xen-devel] [PATCH 1/2] xen/hypercall: fix hypercall fallback
 code for very old hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 30.10.12 at 16:44, Konrad Rzeszutek Wilk  wrote:
> On Mon, Oct 29, 2012 at 10:08:17AM -0400, Konrad Rzeszutek Wilk wrote:
>> From: Jan Beulich 
>> 
>> While copying the argument structures in HYPERVISOR_event_channel_op()
>> and HYPERVISOR_physdev_op() into the local variable is sufficiently
>> safe even if the actual structure is smaller than the container one,
>> copying back eventual output values the same way isn't: This may
>> collide with on-stack variables (particularly "rc") which may change
>> between the first and second memcpy() (i.e. the second memcpy() could
>> discard that change).
>> 
>> Move the fallback code into out-of-line functions, and handle all of
>> the operations known by this old a hypervisor individually: Some don't
>> require copying back anything at all, and for the rest use the
>> individual argument structures' sizes rather than the container's.
>> 
>> Reported-by: Dan Carpenter 
>> Signed-off-by: Jan Beulich 
>> [v2: Reduce #define/#undef usage in HYPERVISOR_physdev_op_compat().]
>> Signed-off-by: Konrad Rzeszutek Wilk 
> 
> And it looks like I get 
> 
> ERROR: "HYPERVISOR_event_channel_op_compat" [drivers/xen/xen-evtchn.ko] 
> undefined!
> 
> when I build xen-evtchn as module. Jan did you encounter this issue on 
> 2.6.18?

No - the event channel driver there can't be built as a module, and
for the forward ported kernels I apparently never tried to build with
a compat setting of 3.0.2 or less (and I didn't care that much either
because the oldest we're actually concerned about is 3.0.4 to cover
some of those very old EC2 systems; I'll add the export at the right
point nevertheless).

Jan

>> ---
>>  arch/x86/include/asm/xen/hypercall.h |   21 +++------
>>  drivers/xen/Makefile                 |    2 +-
>>  drivers/xen/fallback.c               |   78 
> ++++++++++++++++++++++++++++++++++
>>  3 files changed, 86 insertions(+), 15 deletions(-)
>>  create mode 100644 drivers/xen/fallback.c
>> 
>> diff --git a/arch/x86/include/asm/xen/hypercall.h 
> b/arch/x86/include/asm/xen/hypercall.h
>> index 59c226d..c812360 100644
>> --- a/arch/x86/include/asm/xen/hypercall.h
>> +++ b/arch/x86/include/asm/xen/hypercall.h
>> @@ -359,18 +359,14 @@ HYPERVISOR_update_va_mapping(unsigned long va, pte_t 
> new_val,
>>  		return _hypercall4(int, update_va_mapping, va,
>>  				   new_val.pte, new_val.pte >> 32, flags);
>>  }
>> +int __must_check HYPERVISOR_event_channel_op_compat(int, void *);
>>  
>>  static inline int
>>  HYPERVISOR_event_channel_op(int cmd, void *arg)
>>  {
>>  	int rc = _hypercall2(int, event_channel_op, cmd, arg);
>> -	if (unlikely(rc == -ENOSYS)) {
>> -		struct evtchn_op op;
>> -		op.cmd = cmd;
>> -		memcpy(&op.u, arg, sizeof(op.u));
>> -		rc = _hypercall1(int, event_channel_op_compat, &op);
>> -		memcpy(arg, &op.u, sizeof(op.u));
>> -	}
>> +	if (unlikely(rc == -ENOSYS))
>> +		rc = HYPERVISOR_event_channel_op_compat(cmd, arg);
>>  	return rc;
>>  }
>>  
>> @@ -386,17 +382,14 @@ HYPERVISOR_console_io(int cmd, int count, char *str)
>>  	return _hypercall3(int, console_io, cmd, count, str);
>>  }
>>  
>> +int __must_check HYPERVISOR_physdev_op_compat(int, void *);
>> +
>>  static inline int
>>  HYPERVISOR_physdev_op(int cmd, void *arg)
>>  {
>>  	int rc = _hypercall2(int, physdev_op, cmd, arg);
>> -	if (unlikely(rc == -ENOSYS)) {
>> -		struct physdev_op op;
>> -		op.cmd = cmd;
>> -		memcpy(&op.u, arg, sizeof(op.u));
>> -		rc = _hypercall1(int, physdev_op_compat, &op);
>> -		memcpy(arg, &op.u, sizeof(op.u));
>> -	}
>> +	if (unlikely(rc == -ENOSYS))
>> +		rc = HYPERVISOR_physdev_op_compat(cmd, arg);
>>  	return rc;
>>  }
>>  
>> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
>> index 0e863703..46de6cd 100644
>> --- a/drivers/xen/Makefile
>> +++ b/drivers/xen/Makefile
>> @@ -2,7 +2,7 @@ ifneq ($(CONFIG_ARM),y)
>>  obj-y	+= manage.o balloon.o
>>  obj-$(CONFIG_HOTPLUG_CPU)		+= cpu_hotplug.o
>>  endif
>> -obj-y	+= grant-table.o features.o events.o
>> +obj-y	+= grant-table.o features.o events.o fallback.o
>>  obj-y	+= xenbus/
>>  
>>  nostackp := $(call cc-option, -fno-stack-protector)
>> diff --git a/drivers/xen/fallback.c b/drivers/xen/fallback.c
>> new file mode 100644
>> index 0000000..0bdc468
>> --- /dev/null
>> +++ b/drivers/xen/fallback.c
>> @@ -0,0 +1,78 @@
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +int HYPERVISOR_event_channel_op_compat(int cmd, void *arg)
>> +{
>> +	struct evtchn_op op;
>> +	int rc;
>> +
>> +	op.cmd = cmd;
>> +	memcpy(&op.u, arg, sizeof(op.u));
>> +	rc = _hypercall1(int, event_channel_op_compat, &op);
>> +
>> +	switch (cmd) {
>> +	case EVTCHNOP_close:
>> +	case EVTCHNOP_send:
>> +	case EVTCHNOP_bind_vcpu:
>> +	case EVTCHNOP_unmask:
>> +		/* no output */
>> +		break;
>> +
>> +#define COPY_BACK(eop) \
>> +	case EVTCHNOP_##eop: \
>> +		memcpy(arg, &op.u.eop, sizeof(op.u.eop)); \
>> +		break
>> +
>> +	COPY_BACK(bind_interdomain);
>> +	COPY_BACK(bind_virq);
>> +	COPY_BACK(bind_pirq);
>> +	COPY_BACK(status);
>> +	COPY_BACK(alloc_unbound);
>> +	COPY_BACK(bind_ipi);
>> +#undef COPY_BACK
>> +
>> +	default:
>> +		WARN_ON(rc != -ENOSYS);
>> +		break;
>> +	}
>> +
>> +	return rc;
>> +}
>> +
>> +int HYPERVISOR_physdev_op_compat(int cmd, void *arg)
>> +{
>> +	struct physdev_op op;
>> +	int rc;
>> +
>> +	op.cmd = cmd;
>> +	memcpy(&op.u, arg, sizeof(op.u));
>> +	rc = _hypercall1(int, physdev_op_compat, &op);
>> +
>> +	switch (cmd) {
>> +	case PHYSDEVOP_IRQ_UNMASK_NOTIFY:
>> +	case PHYSDEVOP_set_iopl:
>> +	case PHYSDEVOP_set_iobitmap:
>> +	case PHYSDEVOP_apic_write:
>> +		/* no output */
>> +		break;
>> +
>> +#define COPY_BACK(pop, fld) \
>> +	case PHYSDEVOP_##pop: \
>> +		memcpy(arg, &op.u.fld, sizeof(op.u.fld)); \
>> +		break
>> +
>> +	COPY_BACK(irq_status_query, irq_status_query);
>> +	COPY_BACK(apic_read, apic_op);
>> +	COPY_BACK(ASSIGN_VECTOR, irq_op);
>> +#undef COPY_BACK
>> +
>> +	default:
>> +		WARN_ON(rc != -ENOSYS);
>> +		break;
>> +	}
>> +
>> +	return rc;
>> +}
>> -- 
>> 1.7.7.6



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 09:15:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 09:15:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTUNo-0005G5-W9; Wed, 31 Oct 2012 09:14:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTUNn-0005G0-Aj
	for xen-devel@lists.xensource.com; Wed, 31 Oct 2012 09:14:43 +0000
Received: from [193.109.254.147:19657] by server-13.bemta-14.messagelabs.com
	id 4F/EF-11239-20CE0905; Wed, 31 Oct 2012 09:14:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1351674879!9040527!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxODAxOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24076 invoked from network); 31 Oct 2012 09:14:41 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Oct 2012 09:14:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,687,1344211200"; d="scan'208";a="42986586"
Received: from unknown (HELO FTLPEX01CL03.citrite.net) ([10.13.107.80])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	31 Oct 2012 09:14:39 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 31 Oct 2012 05:14:38 -0400
Message-ID: <1351674761.25014.0.camel@hastur.hellion.org.uk>
From: Ian Campbell 
To: "Yi, Shunli" 
Date: Wed, 31 Oct 2012 10:12:41 +0100
In-Reply-To: <961EE662BA396D43898AFA993C8F01B77174A010@SBJEXCH1A.websense.com>
References: <961EE662BA396D43898AFA993C8F01B77174A010@SBJEXCH1A.websense.com>
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] Xennet half die---netfront TX queue was stopped.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-31 at 03:47 +0000, Yi, Shunli wrote:
> 
> Dom0: 2.6.28.8(xenified  kernel)        x86      1 GB MEM + 1 CPU
> cores
> 
> DomU: 2.6.28.8(xenified  kernel)        x86      3 GB MEM + 2 CPU
> cores 

Those are both ancient and AFAIK not supported by any distro. I strongly
recommend you update to something more recent -- either a kernel
supported your distro or an up to date mainine version.

I see a commit in mainline "xen-netfront: correct MAX_TX_TARGET
calculation" which might be related.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 09:15:14 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 09:15:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTUNo-0005G5-W9; Wed, 31 Oct 2012 09:14:44 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTUNn-0005G0-Aj
	for xen-devel@lists.xensource.com; Wed, 31 Oct 2012 09:14:43 +0000
Received: from [193.109.254.147:19657] by server-13.bemta-14.messagelabs.com
	id 4F/EF-11239-20CE0905; Wed, 31 Oct 2012 09:14:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1351674879!9040527!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxODAxOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24076 invoked from network); 31 Oct 2012 09:14:41 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Oct 2012 09:14:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,687,1344211200"; d="scan'208";a="42986586"
Received: from unknown (HELO FTLPEX01CL03.citrite.net) ([10.13.107.80])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	31 Oct 2012 09:14:39 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.13.107.80) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 31 Oct 2012 05:14:38 -0400
Message-ID: <1351674761.25014.0.camel@hastur.hellion.org.uk>
From: Ian Campbell 
To: "Yi, Shunli" 
Date: Wed, 31 Oct 2012 10:12:41 +0100
In-Reply-To: <961EE662BA396D43898AFA993C8F01B77174A010@SBJEXCH1A.websense.com>
References: <961EE662BA396D43898AFA993C8F01B77174A010@SBJEXCH1A.websense.com>
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] Xennet half die---netfront TX queue was stopped.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-31 at 03:47 +0000, Yi, Shunli wrote:
> 
> Dom0: 2.6.28.8(xenified  kernel)        x86      1 GB MEM + 1 CPU
> cores
> 
> DomU: 2.6.28.8(xenified  kernel)        x86      3 GB MEM + 2 CPU
> cores 

Those are both ancient and AFAIK not supported by any distro. I strongly
recommend you update to something more recent -- either a kernel
supported your distro or an up to date mainine version.

I see a commit in mainline "xen-netfront: correct MAX_TX_TARGET
calculation" which might be related.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 09:16:46 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 09:16:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTUP5-0005Kr-EK; Wed, 31 Oct 2012 09:16:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTUP4-0005Kl-B1
	for xen-devel@lists.xensource.com; Wed, 31 Oct 2012 09:16:02 +0000
Received: from [193.109.254.147:35361] by server-7.bemta-14.messagelabs.com id
	B0/DD-24122-15CE0905; Wed, 31 Oct 2012 09:16:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1351674960!3415489!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY2MTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14146 invoked from network); 31 Oct 2012 09:16:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Oct 2012 09:16:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,687,1344211200"; d="scan'208";a="15505900"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Oct 2012 09:16:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 31 Oct 2012 09:16:00 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TTUP2-0007m4-2k;
	Wed, 31 Oct 2012 09:16:00 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TTUP1-0007oY-QP;
	Wed, 31 Oct 2012 09:15:59 +0000
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Wed, 31 Oct 2012 09:15:59 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14179: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14179 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14179/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check            fail pass in 14167

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 14167
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 14167
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 14167
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 14167

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  bf249cd5f2c1
baseline version:
 xen                  bf249cd5f2c1

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 09:16:46 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 09:16:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTUP5-0005Kr-EK; Wed, 31 Oct 2012 09:16:03 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTUP4-0005Kl-B1
	for xen-devel@lists.xensource.com; Wed, 31 Oct 2012 09:16:02 +0000
Received: from [193.109.254.147:35361] by server-7.bemta-14.messagelabs.com id
	B0/DD-24122-15CE0905; Wed, 31 Oct 2012 09:16:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1351674960!3415489!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY2MTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14146 invoked from network); 31 Oct 2012 09:16:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Oct 2012 09:16:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,687,1344211200"; d="scan'208";a="15505900"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Oct 2012 09:16:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 31 Oct 2012 09:16:00 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TTUP2-0007m4-2k;
	Wed, 31 Oct 2012 09:16:00 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TTUP1-0007oY-QP;
	Wed, 31 Oct 2012 09:15:59 +0000
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Wed, 31 Oct 2012 09:15:59 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 14179: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14179 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14179/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check            fail pass in 14167

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 14167
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 14167
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 14167
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 14167

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  bf249cd5f2c1
baseline version:
 xen                  bf249cd5f2c1

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 09:30:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 09:30:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTUcF-0005gv-1p; Wed, 31 Oct 2012 09:29:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTUcD-0005gq-Ef
	for xen-devel@lists.xensource.com; Wed, 31 Oct 2012 09:29:37 +0000
Received: from [85.158.138.51:35611] by server-7.bemta-3.messagelabs.com id
	28/AF-06991-08FE0905; Wed, 31 Oct 2012 09:29:36 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-174.messagelabs.com!1351675776!28176167!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MzY2NTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MzY2NTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20974 invoked from network); 31 Oct 2012 09:29:36 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 31 Oct 2012 09:29:36 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll2s7qFK2M
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-083-161.pools.arcor-ip.net [84.57.83.161])
	by smtp.strato.de (josoe mo21) (RZmta 30.21 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 605cddo9V8cgaw ;
	Wed, 31 Oct 2012 10:29:26 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 601D818643; Wed, 31 Oct 2012 10:29:25 +0100 (CET)
Date: Wed, 31 Oct 2012 10:29:25 +0100
From: Olaf Hering 
To: Ian Campbell 
Message-ID: <20121031092925.GA22587@aepfle.de>
References: <1351613105-24408-1-git-send-email-olaf@aepfle.de>
	<20121030181732.GZ8912@reaktio.net>
	<20121030182859.GA8775@aepfle.de>
	<1351672212.20470.7.camel@hastur.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1351672212.20470.7.camel@hastur.hellion.org.uk>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: Jeremy Fitzhardinge ,
	"xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH] xen PVonHVM: require at least Xen 3.4 as
	dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 31, Ian Campbell wrote:

> If I understand correctly this requirements comes from the need to
> support moving the shared info page in order to support kexec?
> 
> So could we do something more fine grained and limit only the kexec
> support (and therefore the movement of the SI into that range) to 3.4+?

Its not strictly about kexec. The other patch I sent out will place the
shared info page at 0xFE700000. If that range is not within a
E820_Reserved area and if the old hvmloader makes allocations within
that range, that other patch needs to be changed so that the shared info
page is done either at 0xFE700000 or within RESERVE_BRK (as it is done
currently).

Is the source code of that old RHEL available somewhere, did they patch
hvmloader at all? Providing a E820 map from a guest which was started on
such old dom0 would be a good start.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 09:30:02 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 09:30:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTUcF-0005gv-1p; Wed, 31 Oct 2012 09:29:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTUcD-0005gq-Ef
	for xen-devel@lists.xensource.com; Wed, 31 Oct 2012 09:29:37 +0000
Received: from [85.158.138.51:35611] by server-7.bemta-3.messagelabs.com id
	28/AF-06991-08FE0905; Wed, 31 Oct 2012 09:29:36 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-174.messagelabs.com!1351675776!28176167!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MzY2NTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MzY2NTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20974 invoked from network); 31 Oct 2012 09:29:36 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 31 Oct 2012 09:29:36 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll2s7qFK2M
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-083-161.pools.arcor-ip.net [84.57.83.161])
	by smtp.strato.de (josoe mo21) (RZmta 30.21 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 605cddo9V8cgaw ;
	Wed, 31 Oct 2012 10:29:26 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 601D818643; Wed, 31 Oct 2012 10:29:25 +0100 (CET)
Date: Wed, 31 Oct 2012 10:29:25 +0100
From: Olaf Hering 
To: Ian Campbell 
Message-ID: <20121031092925.GA22587@aepfle.de>
References: <1351613105-24408-1-git-send-email-olaf@aepfle.de>
	<20121030181732.GZ8912@reaktio.net>
	<20121030182859.GA8775@aepfle.de>
	<1351672212.20470.7.camel@hastur.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1351672212.20470.7.camel@hastur.hellion.org.uk>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: Jeremy Fitzhardinge ,
	"xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH] xen PVonHVM: require at least Xen 3.4 as
	dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 31, Ian Campbell wrote:

> If I understand correctly this requirements comes from the need to
> support moving the shared info page in order to support kexec?
> 
> So could we do something more fine grained and limit only the kexec
> support (and therefore the movement of the SI into that range) to 3.4+?

Its not strictly about kexec. The other patch I sent out will place the
shared info page at 0xFE700000. If that range is not within a
E820_Reserved area and if the old hvmloader makes allocations within
that range, that other patch needs to be changed so that the shared info
page is done either at 0xFE700000 or within RESERVE_BRK (as it is done
currently).

Is the source code of that old RHEL available somewhere, did they patch
hvmloader at all? Providing a E820 map from a guest which was started on
such old dom0 would be a good start.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 09:57:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 09:57:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTV2O-00064B-Eh; Wed, 31 Oct 2012 09:56:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTV2N-000646-71
	for xen-devel@lists.xensource.com; Wed, 31 Oct 2012 09:56:39 +0000
Received: from [85.158.139.83:60595] by server-14.bemta-5.messagelabs.com id
	F5/27-21768-6D5F0905; Wed, 31 Oct 2012 09:56:38 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-182.messagelabs.com!1351677396!28368220!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MjcwMDg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MjcwMDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14610 invoked from network); 31 Oct 2012 09:56:37 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 31 Oct 2012 09:56:37 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll2s7qFK2M
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-083-161.pools.arcor-ip.net [84.57.83.161])
	by smtp.strato.de (jored mo44) (RZmta 30.21 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id j01edfo9V95cee ;
	Wed, 31 Oct 2012 10:56:31 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 4D6BD18643; Wed, 31 Oct 2012 10:56:31 +0100 (CET)
Date: Wed, 31 Oct 2012 10:56:31 +0100
From: Olaf Hering 
To: Konrad Rzeszutek Wilk 
Message-ID: <20121031095631.GA27937@aepfle.de>
References: <1351613105-24408-1-git-send-email-olaf@aepfle.de>
	<20121030181732.GZ8912@reaktio.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20121030181732.GZ8912@reaktio.net>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen PVonHVM: require at least Xen 3.4 as
	dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCBPY3QgMzAsIFBhc2kgS8Okcmtrw6RpbmVuIHdyb3RlOgoKPiBPbiBUdWUsIE9jdCAz
MCwgMjAxMiBhdCAwNTowNTowNVBNICswMTAwLCBPbGFmIEhlcmluZyB3cm90ZToKPiA+IFRoZSBY
ZW5QVkhWTSBleHRlbnNpb25zIGhhdmUgbm90IGJlZW4gdGVzdGVkIG11Y2ggb24gdmVyeSBvbGQK
PiA+IGh5cGVydmlzb3JzLiBBdCBsZWFzdCBYZW4gMy40IGdldHMgc29tZSB0ZXN0aW5nIHdpdGgg
dGhlIHB2b3BzIGtlcm5lbC4KCj4gSUlSQyB1cHN0cmVhbSBMaW51eCBQVm9uSFZNIGRyaXZlcnMg
ZG8gd29yayBPSyB0b2RheSBvbiBSSEVMNSBYZW4sIAo+IHdoaWNoIGFkdmVydGlzZXMgaXRzZWxm
IGFzIFhlbiAzLjEuMi1iYXNlZC4uCgpLb25yYWQsCgpiYXNlZCBvbiB0aGlzIGluZm8sIHBsZWFz
ZSBkcm9wIHRoaXMgcGF0Y2guCkl0IGRvZXMgbm90IGZpeCBhIHJlYWwgYnVnLgoKT2xhZgoKX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1h
aWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94
ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Oct 31 09:57:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 09:57:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTV2O-00064B-Eh; Wed, 31 Oct 2012 09:56:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTV2N-000646-71
	for xen-devel@lists.xensource.com; Wed, 31 Oct 2012 09:56:39 +0000
Received: from [85.158.139.83:60595] by server-14.bemta-5.messagelabs.com id
	F5/27-21768-6D5F0905; Wed, 31 Oct 2012 09:56:38 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-182.messagelabs.com!1351677396!28368220!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MjcwMDg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MjcwMDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14610 invoked from network); 31 Oct 2012 09:56:37 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 31 Oct 2012 09:56:37 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/ll2s7qFK2M
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-083-161.pools.arcor-ip.net [84.57.83.161])
	by smtp.strato.de (jored mo44) (RZmta 30.21 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id j01edfo9V95cee ;
	Wed, 31 Oct 2012 10:56:31 +0100 (CET)
Received: by probook.site (Postfix, from userid 1000)
	id 4D6BD18643; Wed, 31 Oct 2012 10:56:31 +0100 (CET)
Date: Wed, 31 Oct 2012 10:56:31 +0100
From: Olaf Hering 
To: Konrad Rzeszutek Wilk 
Message-ID: <20121031095631.GA27937@aepfle.de>
References: <1351613105-24408-1-git-send-email-olaf@aepfle.de>
	<20121030181732.GZ8912@reaktio.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20121030181732.GZ8912@reaktio.net>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen PVonHVM: require at least Xen 3.4 as
	dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCBPY3QgMzAsIFBhc2kgS8Okcmtrw6RpbmVuIHdyb3RlOgoKPiBPbiBUdWUsIE9jdCAz
MCwgMjAxMiBhdCAwNTowNTowNVBNICswMTAwLCBPbGFmIEhlcmluZyB3cm90ZToKPiA+IFRoZSBY
ZW5QVkhWTSBleHRlbnNpb25zIGhhdmUgbm90IGJlZW4gdGVzdGVkIG11Y2ggb24gdmVyeSBvbGQK
PiA+IGh5cGVydmlzb3JzLiBBdCBsZWFzdCBYZW4gMy40IGdldHMgc29tZSB0ZXN0aW5nIHdpdGgg
dGhlIHB2b3BzIGtlcm5lbC4KCj4gSUlSQyB1cHN0cmVhbSBMaW51eCBQVm9uSFZNIGRyaXZlcnMg
ZG8gd29yayBPSyB0b2RheSBvbiBSSEVMNSBYZW4sIAo+IHdoaWNoIGFkdmVydGlzZXMgaXRzZWxm
IGFzIFhlbiAzLjEuMi1iYXNlZC4uCgpLb25yYWQsCgpiYXNlZCBvbiB0aGlzIGluZm8sIHBsZWFz
ZSBkcm9wIHRoaXMgcGF0Y2guCkl0IGRvZXMgbm90IGZpeCBhIHJlYWwgYnVnLgoKT2xhZgoKX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1h
aWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94
ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Oct 31 10:17:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 10:17:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTVLd-0006TC-IX; Wed, 31 Oct 2012 10:16:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTVLb-0006T7-P6
	for xen-devel@lists.xensource.com; Wed, 31 Oct 2012 10:16:31 +0000
Received: from [85.158.138.51:31072] by server-7.bemta-3.messagelabs.com id
	B6/59-06991-A7AF0905; Wed, 31 Oct 2012 10:16:26 +0000
X-Env-Sender: syi@websense.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1351678585!28018296!1
X-Originating-IP: [85.115.52.190]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4NS4xMTUuNTIuMTkwID0+IDg1MjQ1Mw==\n,sa_preprocessor: 
	QmFkIElQOiA4NS4xMTUuNTIuMTkwID0+IDg1MjQ1Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29564 invoked from network); 31 Oct 2012 10:16:25 -0000
Received: from cluster-a.mailcontrol.com (HELO cluster-a.mailcontrol.com)
	(85.115.52.190)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 31 Oct 2012 10:16:25 -0000
Received: from ssdwbsnapp.websense.com (static-204-15-65-158.websense.com
	[204.15.65.158] (may be forged))
	by rly22a.srv.mailcontrol.com (MailControl) with ESMTP id
	q9VAGAYi030464
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 31 Oct 2012 10:16:12 GMT
Received: from SSDEXCH1A.websense.com (unknown [10.8.1.91])
	by Websense Email Security Gateway with ESMTP id BA6B9100000D;
	Wed, 31 Oct 2012 03:16:08 -0700 (PDT)
Received: from SBJEXCH2A.websense.com (10.32.8.111) by SSDEXCH1A.websense.com
	(10.8.1.91) with Microsoft SMTP Server (TLS) id 14.2.283.3;
	Wed, 31 Oct 2012 03:16:10 -0700
Received: from SBJEXCH1A.websense.com ([169.254.1.38]) by
	SBJEXCH2A.websense.com ([::1]) with mapi id 14.02.0283.003;
	Wed, 31 Oct 2012 18:16:06 +0800
From: "Yi, Shunli" 
To: Ian Campbell 
Thread-Topic: [Xen-devel] Xennet half die---netfront TX queue was stopped.
Thread-Index: Ac23Gm/GoGh3r8OSR5q8PANust8HvP//1MaA//9zFJA=
Date: Wed, 31 Oct 2012 10:16:05 +0000
Message-ID: <961EE662BA396D43898AFA993C8F01B775058CBE@SBJEXCH1A.websense.com>
References: <961EE662BA396D43898AFA993C8F01B77174A010@SBJEXCH1A.websense.com>
	<1351674761.25014.0.camel@hastur.hellion.org.uk>
In-Reply-To: <1351674761.25014.0.camel@hastur.hellion.org.uk>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.32.134.106]
MIME-Version: 1.0
X-Scanned-By: MailControl 10515.0 (www.mailcontrol.com) on 10.65.0.132
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] Xennet half die---netfront TX queue was stopped.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian,
Thanks for your information.
And sorry for writing a wrong kernel version by mistake, we are using 2.6.18.8, which was downloaded from Xen.org when got Xen-3.4.2 release.

I've seen that patch, just don't think it can impacts this. (http://xenbits.xen.org/hg/linux-2.6.18-xen.hg/rev/ddb83aec5afc  )
You can see the " TX_MAX_TARGET = 0x100" in the log below, it's 256 already. 

Actually, we are doubting it's an overflow issue, I'm reading the netfront and netback to find the possibility of overflow.

>From one occurrence, I got the details from both netfront and netback. Wish it can help us to find something:
On backend interface:
[3357955.991282] rx.rsp_prod_pvt=0xc11734a0 rx.req_cons=0xf4d0eb80
[3357955.991283] tx.rsp_prod_pvt=0xc0af64 tx.req_cons=0xc0af64

On frontend interface:
[3363909.017567] tx.req_prod_pvt=0x12ef8f3 tx.rsp_cons=0x12ef807
[3363909.017569] TX_MAX_TARGET = 0x100, MAX_SKB_FRAGS = 0x12 dev->state=0x7
[3363909.017572] np->tx.sring->rsp_prod = 0x12ef807 np->tx.sring->req_prod=0x12ef8f3
[3363909.017575] np->tx.sring->req_event=0x12ef800 np->tx.sring->rsp_event=0x12ef87e

We have some rack servers in product encountered this rarely, no way to reproduce in lab now.
I've setup two rack servers to reproduce this in lab, both run about 20 days without reproducing.

Could somebody share some experience on this ?  Any sharing would be appreciated. 

Great thanks.

-Shunli


-----Original Message-----
From: Ian Campbell [mailto:ian.campbell@citrix.com] 
Sent: Wednesday, October 31, 2012 5:13 PM
To: Yi, Shunli
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Xennet half die---netfront TX queue was stopped.

On Wed, 2012-10-31 at 03:47 +0000, Yi, Shunli wrote:
> 
> Dom0: 2.6.28.8(xenified  kernel)        x86      1 GB MEM + 1 CPU
> cores
> 
> DomU: 2.6.28.8(xenified  kernel)        x86      3 GB MEM + 2 CPU
> cores

Those are both ancient and AFAIK not supported by any distro. I strongly recommend you update to something more recent -- either a kernel supported your distro or an up to date mainine version.

I see a commit in mainline "xen-netfront: correct MAX_TX_TARGET calculation" which might be related.

Ian.





 To report this as spam, please forward to spam@websense.com.  Thank you.


 Protected by Websense Hosted Email Security -- www.websense.com 
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 10:17:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 10:17:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTVLd-0006TC-IX; Wed, 31 Oct 2012 10:16:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTVLb-0006T7-P6
	for xen-devel@lists.xensource.com; Wed, 31 Oct 2012 10:16:31 +0000
Received: from [85.158.138.51:31072] by server-7.bemta-3.messagelabs.com id
	B6/59-06991-A7AF0905; Wed, 31 Oct 2012 10:16:26 +0000
X-Env-Sender: syi@websense.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1351678585!28018296!1
X-Originating-IP: [85.115.52.190]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4NS4xMTUuNTIuMTkwID0+IDg1MjQ1Mw==\n,sa_preprocessor: 
	QmFkIElQOiA4NS4xMTUuNTIuMTkwID0+IDg1MjQ1Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29564 invoked from network); 31 Oct 2012 10:16:25 -0000
Received: from cluster-a.mailcontrol.com (HELO cluster-a.mailcontrol.com)
	(85.115.52.190)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 31 Oct 2012 10:16:25 -0000
Received: from ssdwbsnapp.websense.com (static-204-15-65-158.websense.com
	[204.15.65.158] (may be forged))
	by rly22a.srv.mailcontrol.com (MailControl) with ESMTP id
	q9VAGAYi030464
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 31 Oct 2012 10:16:12 GMT
Received: from SSDEXCH1A.websense.com (unknown [10.8.1.91])
	by Websense Email Security Gateway with ESMTP id BA6B9100000D;
	Wed, 31 Oct 2012 03:16:08 -0700 (PDT)
Received: from SBJEXCH2A.websense.com (10.32.8.111) by SSDEXCH1A.websense.com
	(10.8.1.91) with Microsoft SMTP Server (TLS) id 14.2.283.3;
	Wed, 31 Oct 2012 03:16:10 -0700
Received: from SBJEXCH1A.websense.com ([169.254.1.38]) by
	SBJEXCH2A.websense.com ([::1]) with mapi id 14.02.0283.003;
	Wed, 31 Oct 2012 18:16:06 +0800
From: "Yi, Shunli" 
To: Ian Campbell 
Thread-Topic: [Xen-devel] Xennet half die---netfront TX queue was stopped.
Thread-Index: Ac23Gm/GoGh3r8OSR5q8PANust8HvP//1MaA//9zFJA=
Date: Wed, 31 Oct 2012 10:16:05 +0000
Message-ID: <961EE662BA396D43898AFA993C8F01B775058CBE@SBJEXCH1A.websense.com>
References: <961EE662BA396D43898AFA993C8F01B77174A010@SBJEXCH1A.websense.com>
	<1351674761.25014.0.camel@hastur.hellion.org.uk>
In-Reply-To: <1351674761.25014.0.camel@hastur.hellion.org.uk>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.32.134.106]
MIME-Version: 1.0
X-Scanned-By: MailControl 10515.0 (www.mailcontrol.com) on 10.65.0.132
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] Xennet half die---netfront TX queue was stopped.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian,
Thanks for your information.
And sorry for writing a wrong kernel version by mistake, we are using 2.6.18.8, which was downloaded from Xen.org when got Xen-3.4.2 release.

I've seen that patch, just don't think it can impacts this. (http://xenbits.xen.org/hg/linux-2.6.18-xen.hg/rev/ddb83aec5afc  )
You can see the " TX_MAX_TARGET = 0x100" in the log below, it's 256 already. 

Actually, we are doubting it's an overflow issue, I'm reading the netfront and netback to find the possibility of overflow.

>From one occurrence, I got the details from both netfront and netback. Wish it can help us to find something:
On backend interface:
[3357955.991282] rx.rsp_prod_pvt=0xc11734a0 rx.req_cons=0xf4d0eb80
[3357955.991283] tx.rsp_prod_pvt=0xc0af64 tx.req_cons=0xc0af64

On frontend interface:
[3363909.017567] tx.req_prod_pvt=0x12ef8f3 tx.rsp_cons=0x12ef807
[3363909.017569] TX_MAX_TARGET = 0x100, MAX_SKB_FRAGS = 0x12 dev->state=0x7
[3363909.017572] np->tx.sring->rsp_prod = 0x12ef807 np->tx.sring->req_prod=0x12ef8f3
[3363909.017575] np->tx.sring->req_event=0x12ef800 np->tx.sring->rsp_event=0x12ef87e

We have some rack servers in product encountered this rarely, no way to reproduce in lab now.
I've setup two rack servers to reproduce this in lab, both run about 20 days without reproducing.

Could somebody share some experience on this ?  Any sharing would be appreciated. 

Great thanks.

-Shunli


-----Original Message-----
From: Ian Campbell [mailto:ian.campbell@citrix.com] 
Sent: Wednesday, October 31, 2012 5:13 PM
To: Yi, Shunli
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Xennet half die---netfront TX queue was stopped.

On Wed, 2012-10-31 at 03:47 +0000, Yi, Shunli wrote:
> 
> Dom0: 2.6.28.8(xenified  kernel)        x86      1 GB MEM + 1 CPU
> cores
> 
> DomU: 2.6.28.8(xenified  kernel)        x86      3 GB MEM + 2 CPU
> cores

Those are both ancient and AFAIK not supported by any distro. I strongly recommend you update to something more recent -- either a kernel supported your distro or an up to date mainine version.

I see a commit in mainline "xen-netfront: correct MAX_TX_TARGET calculation" which might be related.

Ian.





 To report this as spam, please forward to spam@websense.com.  Thank you.


 Protected by Websense Hosted Email Security -- www.websense.com 
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 10:22:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 10:22:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTVQb-0006cI-AX; Wed, 31 Oct 2012 10:21:41 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTVQa-0006cC-Cl
	for xen-devel@lists.xensource.com; Wed, 31 Oct 2012 10:21:40 +0000
Received: from [193.109.254.147:4115] by server-9.bemta-14.messagelabs.com id
	CD/98-30773-3BBF0905; Wed, 31 Oct 2012 10:21:39 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-12.tower-27.messagelabs.com!1351678896!9101912!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDY1MzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8839 invoked from network); 31 Oct 2012 10:21:37 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 31 Oct 2012 10:21:37 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 391CC1742;
	Wed, 31 Oct 2012 12:21:29 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 0275B20059; Wed, 31 Oct 2012 12:21:28 +0200 (EET)
Date: Wed, 31 Oct 2012 12:21:28 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= 
To: Olaf Hering 
Message-ID: <20121031102128.GA8912@reaktio.net>
References: <1351613105-24408-1-git-send-email-olaf@aepfle.de>
	<20121030181732.GZ8912@reaktio.net>
	<20121030182859.GA8775@aepfle.de>
	<1351672212.20470.7.camel@hastur.hellion.org.uk>
	<20121031092925.GA22587@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20121031092925.GA22587@aepfle.de>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Jeremy Fitzhardinge ,
	"xen-devel@lists.xensource.com" ,
	Ian Campbell ,
	Konrad Rzeszutek Wilk ,
	"linux-kernel@vger.kernel.org" 
Subject: Re: [Xen-devel] [PATCH] xen PVonHVM: require at least Xen 3.4 as
 dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 31, 2012 at 10:29:25AM +0100, Olaf Hering wrote:
> On Wed, Oct 31, Ian Campbell wrote:
> 
> > If I understand correctly this requirements comes from the need to
> > support moving the shared info page in order to support kexec?
> > 
> > So could we do something more fine grained and limit only the kexec
> > support (and therefore the movement of the SI into that range) to 3.4+?
> 
> Its not strictly about kexec. The other patch I sent out will place the
> shared info page at 0xFE700000. If that range is not within a
> E820_Reserved area and if the old hvmloader makes allocations within
> that range, that other patch needs to be changed so that the shared info
> page is done either at 0xFE700000 or within RESERVE_BRK (as it is done
> currently).
> 
> Is the source code of that old RHEL available somewhere, did they patch
> hvmloader at all? Providing a E820 map from a guest which was started on
> such old dom0 would be a good start.
> 

http://ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/os/SRPMS/xen-3.0.3-135.el5_8.5.src.rpm
That's the userland, actual Xen hypervisor is in the kernel src.rpm.

I can provide a dmesg from a guest later today.

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 10:22:10 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 10:22:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTVQb-0006cI-AX; Wed, 31 Oct 2012 10:21:41 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTVQa-0006cC-Cl
	for xen-devel@lists.xensource.com; Wed, 31 Oct 2012 10:21:40 +0000
Received: from [193.109.254.147:4115] by server-9.bemta-14.messagelabs.com id
	CD/98-30773-3BBF0905; Wed, 31 Oct 2012 10:21:39 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-12.tower-27.messagelabs.com!1351678896!9101912!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDY1MzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8839 invoked from network); 31 Oct 2012 10:21:37 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 31 Oct 2012 10:21:37 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 391CC1742;
	Wed, 31 Oct 2012 12:21:29 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 0275B20059; Wed, 31 Oct 2012 12:21:28 +0200 (EET)
Date: Wed, 31 Oct 2012 12:21:28 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= 
To: Olaf Hering 
Message-ID: <20121031102128.GA8912@reaktio.net>
References: <1351613105-24408-1-git-send-email-olaf@aepfle.de>
	<20121030181732.GZ8912@reaktio.net>
	<20121030182859.GA8775@aepfle.de>
	<1351672212.20470.7.camel@hastur.hellion.org.uk>
	<20121031092925.GA22587@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20121031092925.GA22587@aepfle.de>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Jeremy Fitzhardinge ,
	"xen-devel@lists.xensource.com" ,
	Ian Campbell ,
	Konrad Rzeszutek Wilk ,
	"linux-kernel@vger.kernel.org" 
Subject: Re: [Xen-devel] [PATCH] xen PVonHVM: require at least Xen 3.4 as
 dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 31, 2012 at 10:29:25AM +0100, Olaf Hering wrote:
> On Wed, Oct 31, Ian Campbell wrote:
> 
> > If I understand correctly this requirements comes from the need to
> > support moving the shared info page in order to support kexec?
> > 
> > So could we do something more fine grained and limit only the kexec
> > support (and therefore the movement of the SI into that range) to 3.4+?
> 
> Its not strictly about kexec. The other patch I sent out will place the
> shared info page at 0xFE700000. If that range is not within a
> E820_Reserved area and if the old hvmloader makes allocations within
> that range, that other patch needs to be changed so that the shared info
> page is done either at 0xFE700000 or within RESERVE_BRK (as it is done
> currently).
> 
> Is the source code of that old RHEL available somewhere, did they patch
> hvmloader at all? Providing a E820 map from a guest which was started on
> such old dom0 would be a good start.
> 

http://ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/os/SRPMS/xen-3.0.3-135.el5_8.5.src.rpm
That's the userland, actual Xen hypervisor is in the kernel src.rpm.

I can provide a dmesg from a guest later today.

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 10:23:18 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 10:23:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTVRo-0006h4-Pm; Wed, 31 Oct 2012 10:22:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTVRn-0006gv-KG
	for xen-devel@lists.xensource.com; Wed, 31 Oct 2012 10:22:55 +0000
Received: from [85.158.143.99:3970] by server-3.bemta-4.messagelabs.com id
	E4/41-06841-EFBF0905; Wed, 31 Oct 2012 10:22:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1351678972!27494785!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxODAxOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32355 invoked from network); 31 Oct 2012 10:22:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Oct 2012 10:22:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,687,1344211200"; d="scan'208";a="42993474"
Received: from ftlpex01cl01.citrite.net ([10.13.107.78])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	31 Oct 2012 10:22:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 31 Oct 2012 06:22:51 -0400
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[127.0.0.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TTVRj-0006Rr-1a;
	Wed, 31 Oct 2012 10:22:51 +0000
Message-ID: <1351678854.25014.7.camel@hastur.hellion.org.uk>
From: Ian Campbell 
To: "Yi, Shunli" 
Date: Wed, 31 Oct 2012 11:20:54 +0100
In-Reply-To: <961EE662BA396D43898AFA993C8F01B775058CBE@SBJEXCH1A.websense.com>
References: <961EE662BA396D43898AFA993C8F01B77174A010@SBJEXCH1A.websense.com>
	<1351674761.25014.0.camel@hastur.hellion.org.uk>
	<961EE662BA396D43898AFA993C8F01B775058CBE@SBJEXCH1A.websense.com>
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] Xennet half die---netfront TX queue was stopped.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-31 at 10:16 +0000, Yi, Shunli wrote:
> Ian,
> Thanks for your information.
> And sorry for writing a wrong kernel version by mistake, we are using
> 2.6.18.8,

2.6.18.8 is even more ancient.

>  which was downloaded from Xen.org when got Xen-3.4.2 release.

Well, 3.4.2 is also pretty old too.

In general there is no requirement to use the kernel which is supplied
with a given version of Xen (we don't even supply one any more). So
there is no real reason to stick with the 2.6.18 that happened to come
with 3.4.2.

You should upgrade at least your kernel as I suggested.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 10:23:18 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 10:23:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTVRo-0006h4-Pm; Wed, 31 Oct 2012 10:22:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTVRn-0006gv-KG
	for xen-devel@lists.xensource.com; Wed, 31 Oct 2012 10:22:55 +0000
Received: from [85.158.143.99:3970] by server-3.bemta-4.messagelabs.com id
	E4/41-06841-EFBF0905; Wed, 31 Oct 2012 10:22:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1351678972!27494785!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxODAxOTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32355 invoked from network); 31 Oct 2012 10:22:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Oct 2012 10:22:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,687,1344211200"; d="scan'208";a="42993474"
Received: from ftlpex01cl01.citrite.net ([10.13.107.78])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	31 Oct 2012 10:22:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 31 Oct 2012 06:22:51 -0400
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[127.0.0.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TTVRj-0006Rr-1a;
	Wed, 31 Oct 2012 10:22:51 +0000
Message-ID: <1351678854.25014.7.camel@hastur.hellion.org.uk>
From: Ian Campbell 
To: "Yi, Shunli" 
Date: Wed, 31 Oct 2012 11:20:54 +0100
In-Reply-To: <961EE662BA396D43898AFA993C8F01B775058CBE@SBJEXCH1A.websense.com>
References: <961EE662BA396D43898AFA993C8F01B77174A010@SBJEXCH1A.websense.com>
	<1351674761.25014.0.camel@hastur.hellion.org.uk>
	<961EE662BA396D43898AFA993C8F01B775058CBE@SBJEXCH1A.websense.com>
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: Re: [Xen-devel] Xennet half die---netfront TX queue was stopped.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-31 at 10:16 +0000, Yi, Shunli wrote:
> Ian,
> Thanks for your information.
> And sorry for writing a wrong kernel version by mistake, we are using
> 2.6.18.8,

2.6.18.8 is even more ancient.

>  which was downloaded from Xen.org when got Xen-3.4.2 release.

Well, 3.4.2 is also pretty old too.

In general there is no requirement to use the kernel which is supplied
with a given version of Xen (we don't even supply one any more). So
there is no real reason to stick with the 2.6.18 that happened to come
with 3.4.2.

You should upgrade at least your kernel as I suggested.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 10:28:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 10:28:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTVWg-0006xd-HJ; Wed, 31 Oct 2012 10:27:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTVWe-0006xW-Tr
	for xen-devel@lists.xensource.com; Wed, 31 Oct 2012 10:27:57 +0000
Received: from [85.158.143.99:56331] by server-2.bemta-4.messagelabs.com id
	52/45-28922-C2DF0905; Wed, 31 Oct 2012 10:27:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1351679259!27726193!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODI2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1088 invoked from network); 31 Oct 2012 10:27:42 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Oct 2012 10:27:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,687,1344211200"; d="scan'208";a="212967125"
Received: from ftlpex01cl01.citrite.net ([10.13.107.78])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	31 Oct 2012 10:27:38 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 31 Oct 2012 06:27:38 -0400
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[127.0.0.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TTVWL-0006Vm-6y;
	Wed, 31 Oct 2012 10:27:38 +0000
Message-ID: <1351679139.25014.10.camel@hastur.hellion.org.uk>
From: Ian Campbell 
To: Olaf Hering 
Date: Wed, 31 Oct 2012 11:25:39 +0100
In-Reply-To: <20121031092925.GA22587@aepfle.de>
References: <1351613105-24408-1-git-send-email-olaf@aepfle.de>
	<20121030181732.GZ8912@reaktio.net> <20121030182859.GA8775@aepfle.de>
	<1351672212.20470.7.camel@hastur.hellion.org.uk>
	<20121031092925.GA22587@aepfle.de>
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge ,
	"xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH] xen PVonHVM: require at least Xen 3.4 as
 dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-31 at 09:29 +0000, Olaf Hering wrote:
> On Wed, Oct 31, Ian Campbell wrote:
> 
> > If I understand correctly this requirements comes from the need to
> > support moving the shared info page in order to support kexec?
> > 
> > So could we do something more fine grained and limit only the kexec
> > support (and therefore the movement of the SI into that range) to 3.4+?
> 
> Its not strictly about kexec. The other patch I sent out will place the
> shared info page at 0xFE700000.

Right, but it does this only in order to support kexec, right? Is there
any other reason to relocate the shinfo in this way?

>  If that range is not within a
> E820_Reserved area and if the old hvmloader makes allocations within
> that range, that other patch needs to be changed so that the shared info
> page is done either at 0xFE700000 or within RESERVE_BRK (as it is done
> currently).

Can it not do both, depending on the detected version of Xen? That's
what I was trying to suggest.

> Is the source code of that old RHEL available somewhere, did they patch
> hvmloader at all? Providing a E820 map from a guest which was started on
> such old dom0 would be a good start.

IIRC The .src.rpm's are available on ftp.redhat.com, or you could
probaly find the centos versions.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 10:28:19 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 10:28:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTVWg-0006xd-HJ; Wed, 31 Oct 2012 10:27:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTVWe-0006xW-Tr
	for xen-devel@lists.xensource.com; Wed, 31 Oct 2012 10:27:57 +0000
Received: from [85.158.143.99:56331] by server-2.bemta-4.messagelabs.com id
	52/45-28922-C2DF0905; Wed, 31 Oct 2012 10:27:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1351679259!27726193!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyODI2NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1088 invoked from network); 31 Oct 2012 10:27:42 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Oct 2012 10:27:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,687,1344211200"; d="scan'208";a="212967125"
Received: from ftlpex01cl01.citrite.net ([10.13.107.78])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA;
	31 Oct 2012 10:27:38 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.78) with Microsoft SMTP Server id 14.2.318.1;
	Wed, 31 Oct 2012 06:27:38 -0400
Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[127.0.0.1])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	)	id 1TTVWL-0006Vm-6y;
	Wed, 31 Oct 2012 10:27:38 +0000
Message-ID: <1351679139.25014.10.camel@hastur.hellion.org.uk>
From: Ian Campbell 
To: Olaf Hering 
Date: Wed, 31 Oct 2012 11:25:39 +0100
In-Reply-To: <20121031092925.GA22587@aepfle.de>
References: <1351613105-24408-1-git-send-email-olaf@aepfle.de>
	<20121030181732.GZ8912@reaktio.net> <20121030182859.GA8775@aepfle.de>
	<1351672212.20470.7.camel@hastur.hellion.org.uk>
	<20121031092925.GA22587@aepfle.de>
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge ,
	"xen-devel@lists.xensource.com" ,
	"linux-kernel@vger.kernel.org" ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH] xen PVonHVM: require at least Xen 3.4 as
 dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-31 at 09:29 +0000, Olaf Hering wrote:
> On Wed, Oct 31, Ian Campbell wrote:
> 
> > If I understand correctly this requirements comes from the need to
> > support moving the shared info page in order to support kexec?
> > 
> > So could we do something more fine grained and limit only the kexec
> > support (and therefore the movement of the SI into that range) to 3.4+?
> 
> Its not strictly about kexec. The other patch I sent out will place the
> shared info page at 0xFE700000.

Right, but it does this only in order to support kexec, right? Is there
any other reason to relocate the shinfo in this way?

>  If that range is not within a
> E820_Reserved area and if the old hvmloader makes allocations within
> that range, that other patch needs to be changed so that the shared info
> page is done either at 0xFE700000 or within RESERVE_BRK (as it is done
> currently).

Can it not do both, depending on the detected version of Xen? That's
what I was trying to suggest.

> Is the source code of that old RHEL available somewhere, did they patch
> hvmloader at all? Providing a E820 map from a guest which was started on
> such old dom0 would be a good start.

IIRC The .src.rpm's are available on ftp.redhat.com, or you could
probaly find the centos versions.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 10:58:35 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 10:58:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTVzq-0007NY-3n; Wed, 31 Oct 2012 10:58:06 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTVzp-0007NT-3u
	for xen-devel@lists.xensource.com; Wed, 31 Oct 2012 10:58:05 +0000
Received: from [193.109.254.147:12080] by server-9.bemta-14.messagelabs.com id
	A8/54-30773-C3401905; Wed, 31 Oct 2012 10:58:04 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1351680928!2196696!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjI1NTQy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18268 invoked from network); 31 Oct 2012 10:55:29 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-14.tower-27.messagelabs.com with SMTP;
	31 Oct 2012 10:55:29 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 31 Oct 2012 03:55:26 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,687,1344236400"; d="scan'208";a="211681639"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by azsmga001.ch.intel.com with ESMTP; 31 Oct 2012 03:55:26 -0700
Received: from fmsmsx102.amr.corp.intel.com (10.19.9.53) by
	FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 31 Oct 2012 03:55:25 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX102.amr.corp.intel.com (10.19.9.53) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 31 Oct 2012 03:55:25 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.186]) with mapi id
	14.01.0355.002; Wed, 31 Oct 2012 18:55:24 +0800
From: "Liu, Jinsong" 
To: Jan Beulich 
Thread-Topic: [Patch 4/5] X86/vMCE: handle broken page occurred before
	migration
Thread-Index: AQHNtn05aBRa8rOqkUOTeDJn2J5LNJfTPzbg
Date: Wed, 31 Oct 2012 10:55:23 +0000
Message-ID: 
References: 
	
	
	<50852EB6.4060705@eu.citrix.com>
	
	<508FA59902000078000A55FB@nat28.tlf.novell.com>
In-Reply-To: <508FA59902000078000A55FB@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	George Dunlap ,
	Ian Jackson 
Subject: Re: [Xen-devel] [Patch 4/5] X86/vMCE: handle broken page occurred
 before migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Jan Beulich wrote:
>>>> On 29.10.12 at 16:21, "Liu, Jinsong"  wrote:
>> @@ -1568,6 +1577,28 @@
>>      }
>>      break;
>> 
>> +    case XEN_DOMCTL_set_broken_page_p2m:
>> +    {
>> +        struct domain *d;
>> +        p2m_type_t pt;
>> +        unsigned long pfn;
>> +
>> +        d = rcu_lock_domain_by_id(domctl->domain); +        if ( d
>> != NULL ) +        {
>> +            pfn = domctl->u.set_broken_page_p2m.pfn; +
>> +            get_gfn_query(d, pfn, &pt);
> 
> Is it correct to ignore the return value here, and to act on any
> value returned in "pt"?
> 
>> +            p2m_change_type(d, pfn, pt, p2m_ram_broken);
> 
> What if the operation failed (i.e. you get back a type not
> matching "pt")? This can happen because __get_gfn_type_access(),
> other than what p2m_change_type() does, is not just a plain call
> to p2m->get_entry().
> 

Updated acordingly, add sanity check, will send out later.

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 10:58:35 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 10:58:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTVzq-0007NY-3n; Wed, 31 Oct 2012 10:58:06 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTVzp-0007NT-3u
	for xen-devel@lists.xensource.com; Wed, 31 Oct 2012 10:58:05 +0000
Received: from [193.109.254.147:12080] by server-9.bemta-14.messagelabs.com id
	A8/54-30773-C3401905; Wed, 31 Oct 2012 10:58:04 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1351680928!2196696!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjI1NTQy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18268 invoked from network); 31 Oct 2012 10:55:29 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-14.tower-27.messagelabs.com with SMTP;
	31 Oct 2012 10:55:29 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 31 Oct 2012 03:55:26 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,687,1344236400"; d="scan'208";a="211681639"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by azsmga001.ch.intel.com with ESMTP; 31 Oct 2012 03:55:26 -0700
Received: from fmsmsx102.amr.corp.intel.com (10.19.9.53) by
	FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 31 Oct 2012 03:55:25 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX102.amr.corp.intel.com (10.19.9.53) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 31 Oct 2012 03:55:25 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.186]) with mapi id
	14.01.0355.002; Wed, 31 Oct 2012 18:55:24 +0800
From: "Liu, Jinsong" 
To: Jan Beulich 
Thread-Topic: [Patch 4/5] X86/vMCE: handle broken page occurred before
	migration
Thread-Index: AQHNtn05aBRa8rOqkUOTeDJn2J5LNJfTPzbg
Date: Wed, 31 Oct 2012 10:55:23 +0000
Message-ID: 
References: 
	
	
	<50852EB6.4060705@eu.citrix.com>
	
	<508FA59902000078000A55FB@nat28.tlf.novell.com>
In-Reply-To: <508FA59902000078000A55FB@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	George Dunlap ,
	Ian Jackson 
Subject: Re: [Xen-devel] [Patch 4/5] X86/vMCE: handle broken page occurred
 before migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Jan Beulich wrote:
>>>> On 29.10.12 at 16:21, "Liu, Jinsong"  wrote:
>> @@ -1568,6 +1577,28 @@
>>      }
>>      break;
>> 
>> +    case XEN_DOMCTL_set_broken_page_p2m:
>> +    {
>> +        struct domain *d;
>> +        p2m_type_t pt;
>> +        unsigned long pfn;
>> +
>> +        d = rcu_lock_domain_by_id(domctl->domain); +        if ( d
>> != NULL ) +        {
>> +            pfn = domctl->u.set_broken_page_p2m.pfn; +
>> +            get_gfn_query(d, pfn, &pt);
> 
> Is it correct to ignore the return value here, and to act on any
> value returned in "pt"?
> 
>> +            p2m_change_type(d, pfn, pt, p2m_ram_broken);
> 
> What if the operation failed (i.e. you get back a type not
> matching "pt")? This can happen because __get_gfn_type_access(),
> other than what p2m_change_type() does, is not just a plain call
> to p2m->get_entry().
> 

Updated acordingly, add sanity check, will send out later.

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 10:59:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 10:59:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTW0T-0007Pz-Hi; Wed, 31 Oct 2012 10:58:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTW0R-0007Pn-RO
	for xen-devel@lists.xensource.com; Wed, 31 Oct 2012 10:58:44 +0000
Received: from [85.158.137.99:17359] by server-4.bemta-3.messagelabs.com id
	CD/C6-01405-26401905; Wed, 31 Oct 2012 10:58:42 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1351681121!17157819!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjI1NTQy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11218 invoked from network); 31 Oct 2012 10:58:41 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-10.tower-217.messagelabs.com with SMTP;
	31 Oct 2012 10:58:41 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 31 Oct 2012 03:58:40 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,687,1344236400"; d="scan'208";a="211682282"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by azsmga001.ch.intel.com with ESMTP; 31 Oct 2012 03:58:27 -0700
Received: from fmsmsx119.amr.corp.intel.com (10.18.22.143) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 31 Oct 2012 03:58:27 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	fmsmsx119.amr.corp.intel.com (10.18.22.143) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 31 Oct 2012 03:58:27 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.123]) with mapi id
	14.01.0355.002; Wed, 31 Oct 2012 18:58:25 +0800
From: "Liu, Jinsong" 
To: George Dunlap 
Thread-Topic: [Xen-devel] [Patch 4/5] X86/vMCE: handle broken page occurred
	before migration
Thread-Index: AQHNtoDYxMZxwfDs1kKQngMxENsF3pfTP4Qw
Date: Wed, 31 Oct 2012 10:58:24 +0000
Message-ID: 
References: 
	
	
	<50852EB6.4060705@eu.citrix.com>
	
	
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	Ian Jackson , Jan Beulich 
Subject: Re: [Xen-devel] [Patch 4/5] X86/vMCE: handle broken page occurred
 before migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap wrote:
> Jinsong,
> 
> I'm at UDS now, but I'll try to review the new patches in the next
> few days. 
> 
> If you end up sending these patches again, could you please send them
> in 
> a more normal "patchbomb-style" format?  I.e., with a "00/02" header
> describing what's new in the series, and then naming them 01/02 and
> 02/02 (instead of 4 and 5, when 1-3 have been applied for months)?
> 
> The easiest way to do this is to use hg's patchbomb extension;
> there's a description of how to set it up here:
> 
> http://wiki.xen.org/wiki/SubmittingXenPatches
> 
> It's a few minutes to set up, but it's well worth it both for us and
> for you.
> 
> Thanks,
>   -George


Thanks, just updated per Jan's comments, and will re-send them in patchbomb style.

Jinsong

> 
> On Mon, Oct 29, 2012 at 4:21 PM, Liu, Jinsong 
> wrote: 
>> X86/vMCE: handle broken page occurred before migration
>> 
>> This patch handles guest broken page which occur before migration.
>> 
>> At sender, the broken page would be mapped but not copied to target
>> (otherwise it may trigger more serious error, say, SRAR error).
>> While its pfn_type and pfn number would be transferred to target
>> so that target take appropriate action.
>> 
>> At target, it would set p2m as p2m_ram_broken for broken page, so
>> that 
>> if guest access the broken page again, it would kill itself as
>> expected. 
>> 
>> Signed-off-by: Liu, Jinsong 
>> 
>> diff -r e27a6d53ac15 tools/libxc/xc_domain.c
>> --- a/tools/libxc/xc_domain.c   Thu Oct 11 01:52:33 2012 +0800
>> +++ b/tools/libxc/xc_domain.c   Thu Oct 25 05:49:10 2012 +0800 @@
>>      -283,6 +283,22 @@ return ret;
>>  }
>> 
>> +/* set broken page p2m */
>> +int xc_set_broken_page_p2m(xc_interface *xch,
>> +                           uint32_t domid,
>> +                           unsigned long pfn)
>> +{
>> +    int ret;
>> +    DECLARE_DOMCTL;
>> +
>> +    domctl.cmd = XEN_DOMCTL_set_broken_page_p2m;
>> +    domctl.domain = (domid_t)domid;
>> +    domctl.u.set_broken_page_p2m.pfn = pfn;
>> +    ret = do_domctl(xch, &domctl);
>> +
>> +    return ret ? -1 : 0;
>> +}
>> +
>>  /* get info from hvm guest for save */
>>  int xc_domain_hvm_getcontext(xc_interface *xch,
>>                               uint32_t domid,
>> diff -r e27a6d53ac15 tools/libxc/xc_domain_restore.c
>> --- a/tools/libxc/xc_domain_restore.c   Thu Oct 11 01:52:33 2012
>> +0800 +++ b/tools/libxc/xc_domain_restore.c   Thu Oct 25 05:49:10
>> 2012 +0800 @@ -962,9 +962,15 @@ 
>> 
>>      countpages = count;
>>      for (i = oldcount; i < buf->nr_pages; ++i)
>> -        if ((buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) ==
>> XEN_DOMCTL_PFINFO_XTAB 
>> -            ||(buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) ==
>> XEN_DOMCTL_PFINFO_XALLOC) +    { +        unsigned long pagetype;
>> +
>> +        pagetype = buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK;
>> +        if ( pagetype == XEN_DOMCTL_PFINFO_XTAB ||
>> +             pagetype == XEN_DOMCTL_PFINFO_BROKEN ||
>> +             pagetype == XEN_DOMCTL_PFINFO_XALLOC )             
>> --countpages; +    }
>> 
>>      if (!countpages)
>>          return count;
>> @@ -1200,6 +1206,17 @@
>>              /* a bogus/unmapped/allocate-only page: skip it */     
>> continue; 
>> 
>> +        if ( pagetype == XEN_DOMCTL_PFINFO_BROKEN ) +        {
>> +            if ( xc_set_broken_page_p2m(xch, dom, pfn) ) +         
>> { +                ERROR("Set p2m for broken page failed, "
>> +                      "dom=%d, pfn=%lx\n", dom, pfn);
>> +                goto err_mapped;
>> +            }
>> +            continue;
>> +        }
>> +
>>          if (pfn_err[i])
>>          {
>>              ERROR("unexpected PFN mapping failure pfn %lx map_mfn
>> %lx p2m_mfn %lx", 
>> diff -r e27a6d53ac15 tools/libxc/xc_domain_save.c
>> --- a/tools/libxc/xc_domain_save.c      Thu Oct 11 01:52:33 2012
>> +0800 +++ b/tools/libxc/xc_domain_save.c      Thu Oct 25 05:49:10
>>                  2012 +0800 @@ -1277,6 +1277,13 @@ if ( !hvm )
>>                      gmfn = pfn_to_mfn(gmfn);
>> 
>> +                if ( pfn_type[j] == XEN_DOMCTL_PFINFO_BROKEN ) +   
>> { +                    pfn_type[j] |= pfn_batch[j];
>> +                    ++run;
>> +                    continue;
>> +                }
>> +
>>                  if ( pfn_err[j] )
>>                  {
>>                      if ( pfn_type[j] == XEN_DOMCTL_PFINFO_XTAB ) @@
>>                      -1371,8 +1378,12 @@ }
>>                  }
>> 
>> -                /* skip pages that aren't present or are alloc-only
>> */ +                /* +                 * skip pages that aren't
>> present, +                 * or are broken, or are alloc-only +     
>>                  */ if ( pagetype == XEN_DOMCTL_PFINFO_XTAB
>> +                    || pagetype == XEN_DOMCTL_PFINFO_BROKEN
>>                      || pagetype == XEN_DOMCTL_PFINFO_XALLOC )
>>                      continue;
>> 
>> diff -r e27a6d53ac15 tools/libxc/xenctrl.h
>> --- a/tools/libxc/xenctrl.h     Thu Oct 11 01:52:33 2012 +0800
>> +++ b/tools/libxc/xenctrl.h     Thu Oct 25 05:49:10 2012 +0800 @@
>>                            -575,6 +575,17 @@ xc_domaininfo_t *info);
>> 
>>  /**
>> + * This function set p2m for broken page
>> + * &parm xch a handle to an open hypervisor interface
>> + * @parm domid the domain id which broken page belong to
>> + * @parm pfn the pfn number of the broken page
>> + * @return 0 on success, -1 on failure
>> + */
>> +int xc_set_broken_page_p2m(xc_interface *xch,
>> +                           uint32_t domid,
>> +                           unsigned long pfn);
>> +
>> +/**
>>   * This function returns information about the context of a hvm
>> domain 
>>   * @parm xch a handle to an open hypervisor interface
>>   * @parm domid the domain to get information from
>> diff -r e27a6d53ac15 xen/arch/x86/domctl.c
>> --- a/xen/arch/x86/domctl.c     Thu Oct 11 01:52:33 2012 +0800
>> +++ b/xen/arch/x86/domctl.c     Thu Oct 25 05:49:10 2012 +0800 @@
>>                  -209,12 +209,18 @@ for ( j = 0; j < k; j++ )
>>                  {
>>                      unsigned long type = 0;
>> +                    p2m_type_t t;
>> 
>> -                    page = get_page_from_gfn(d, arr[j], NULL,
>> P2M_ALLOC); +                    page = get_page_from_gfn(d, arr[j],
>> &t, P2M_ALLOC); 
>> 
>>                      if ( unlikely(!page) ||
>>                           unlikely(is_xen_heap_page(page)) )
>> -                        type = XEN_DOMCTL_PFINFO_XTAB; +           
>> { +                        if ( p2m_is_broken(t) )
>> +                            type = XEN_DOMCTL_PFINFO_BROKEN; +     
>> else +                            type = XEN_DOMCTL_PFINFO_XTAB; +  
>>                      } else
>>                      {
>>                          switch( page->u.inuse.type_info &
>> PGT_type_mask ) @@ -235,6 +241,9 @@ 
>> 
>>                          if ( page->u.inuse.type_info & PGT_pinned )
>>                              type |= XEN_DOMCTL_PFINFO_LPINTAB; +
>> +                        if ( page->count_info & PGC_broken )
>> +                            type = XEN_DOMCTL_PFINFO_BROKEN;       
>> } 
>> 
>>                      if ( page )
>> @@ -1568,6 +1577,28 @@
>>      }
>>      break;
>> 
>> +    case XEN_DOMCTL_set_broken_page_p2m:
>> +    {
>> +        struct domain *d;
>> +        p2m_type_t pt;
>> +        unsigned long pfn;
>> +
>> +        d = rcu_lock_domain_by_id(domctl->domain); +        if ( d
>> != NULL ) +        {
>> +            pfn = domctl->u.set_broken_page_p2m.pfn; +
>> +            get_gfn_query(d, pfn, &pt);
>> +            p2m_change_type(d, pfn, pt, p2m_ram_broken); +         
>> put_gfn(d, pfn); +
>> +            rcu_unlock_domain(d);
>> +        }
>> +        else
>> +            ret = -ESRCH;
>> +    }
>> +    break;
>> +
>>      default:
>>          ret = iommu_do_domctl(domctl, u_domctl);
>>          break;
>> diff -r e27a6d53ac15 xen/include/public/domctl.h
>> --- a/xen/include/public/domctl.h       Thu Oct 11 01:52:33 2012
>> +0800 +++ b/xen/include/public/domctl.h       Thu Oct 25 05:49:10
>>  2012 +0800 @@ -136,6 +136,7 @@ #define XEN_DOMCTL_PFINFO_LPINTAB
>>  (0x1U<<31) #define XEN_DOMCTL_PFINFO_XTAB    (0xfU<<28) /* invalid
>>  page */ #define XEN_DOMCTL_PFINFO_XALLOC  (0xeU<<28) /*
>> allocate-only page */ +#define XEN_DOMCTL_PFINFO_BROKEN  (0xdU<<28)
>>  /* broken page */ #define XEN_DOMCTL_PFINFO_PAGEDTAB (0x8U<<28)
>>  #define XEN_DOMCTL_PFINFO_LTAB_MASK (0xfU<<28)
>> 
>> @@ -835,6 +836,12 @@
>>  typedef struct xen_domctl_set_access_required
>>  xen_domctl_set_access_required_t;
>> DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_access_required_t); 
>> 
>> +struct xen_domctl_set_broken_page_p2m {
>> +    uint64_aligned_t pfn;
>> +};
>> +typedef struct xen_domctl_set_broken_page_p2m
>> xen_domctl_set_broken_page_p2m_t;
>>  +DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_broken_page_p2m_t); +
>>      struct xen_domctl { uint32_t cmd;
>>  #define XEN_DOMCTL_createdomain                   1 @@ -900,6
>>  +907,7 @@ #define XEN_DOMCTL_set_access_required           64
>>  #define XEN_DOMCTL_audit_p2m                     65
>>  #define XEN_DOMCTL_set_virq_handler              66
>> +#define XEN_DOMCTL_set_broken_page_p2m           67
>>  #define XEN_DOMCTL_gdbsx_guestmemio            1000
>>  #define XEN_DOMCTL_gdbsx_pausevcpu             1001
>>  #define XEN_DOMCTL_gdbsx_unpausevcpu           1002 @@ -955,6
>>          +963,7 @@ struct xen_domctl_audit_p2m         audit_p2m;
>>          struct xen_domctl_set_virq_handler  set_virq_handler;
>>          struct xen_domctl_gdbsx_memio       gdbsx_guest_memio;
>> +        struct xen_domctl_set_broken_page_p2m set_broken_page_p2m;
>>          struct xen_domctl_gdbsx_pauseunp_vcpu gdbsx_pauseunp_vcpu;
>>          struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
>>          uint8_t                             pad[128];
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 10:59:04 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 10:59:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTW0T-0007Pz-Hi; Wed, 31 Oct 2012 10:58:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTW0R-0007Pn-RO
	for xen-devel@lists.xensource.com; Wed, 31 Oct 2012 10:58:44 +0000
Received: from [85.158.137.99:17359] by server-4.bemta-3.messagelabs.com id
	CD/C6-01405-26401905; Wed, 31 Oct 2012 10:58:42 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1351681121!17157819!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjI1NTQy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11218 invoked from network); 31 Oct 2012 10:58:41 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-10.tower-217.messagelabs.com with SMTP;
	31 Oct 2012 10:58:41 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 31 Oct 2012 03:58:40 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,687,1344236400"; d="scan'208";a="211682282"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by azsmga001.ch.intel.com with ESMTP; 31 Oct 2012 03:58:27 -0700
Received: from fmsmsx119.amr.corp.intel.com (10.18.22.143) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 31 Oct 2012 03:58:27 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	fmsmsx119.amr.corp.intel.com (10.18.22.143) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 31 Oct 2012 03:58:27 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.123]) with mapi id
	14.01.0355.002; Wed, 31 Oct 2012 18:58:25 +0800
From: "Liu, Jinsong" 
To: George Dunlap 
Thread-Topic: [Xen-devel] [Patch 4/5] X86/vMCE: handle broken page occurred
	before migration
Thread-Index: AQHNtoDYxMZxwfDs1kKQngMxENsF3pfTP4Qw
Date: Wed, 31 Oct 2012 10:58:24 +0000
Message-ID: 
References: 
	
	
	<50852EB6.4060705@eu.citrix.com>
	
	
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Christoph Egger ,
	"xen-devel@lists.xensource.com" ,
	"Keir \(Xen.org\)" , Ian Campbell ,
	Ian Jackson , Jan Beulich 
Subject: Re: [Xen-devel] [Patch 4/5] X86/vMCE: handle broken page occurred
 before migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap wrote:
> Jinsong,
> 
> I'm at UDS now, but I'll try to review the new patches in the next
> few days. 
> 
> If you end up sending these patches again, could you please send them
> in 
> a more normal "patchbomb-style" format?  I.e., with a "00/02" header
> describing what's new in the series, and then naming them 01/02 and
> 02/02 (instead of 4 and 5, when 1-3 have been applied for months)?
> 
> The easiest way to do this is to use hg's patchbomb extension;
> there's a description of how to set it up here:
> 
> http://wiki.xen.org/wiki/SubmittingXenPatches
> 
> It's a few minutes to set up, but it's well worth it both for us and
> for you.
> 
> Thanks,
>   -George


Thanks, just updated per Jan's comments, and will re-send them in patchbomb style.

Jinsong

> 
> On Mon, Oct 29, 2012 at 4:21 PM, Liu, Jinsong 
> wrote: 
>> X86/vMCE: handle broken page occurred before migration
>> 
>> This patch handles guest broken page which occur before migration.
>> 
>> At sender, the broken page would be mapped but not copied to target
>> (otherwise it may trigger more serious error, say, SRAR error).
>> While its pfn_type and pfn number would be transferred to target
>> so that target take appropriate action.
>> 
>> At target, it would set p2m as p2m_ram_broken for broken page, so
>> that 
>> if guest access the broken page again, it would kill itself as
>> expected. 
>> 
>> Signed-off-by: Liu, Jinsong 
>> 
>> diff -r e27a6d53ac15 tools/libxc/xc_domain.c
>> --- a/tools/libxc/xc_domain.c   Thu Oct 11 01:52:33 2012 +0800
>> +++ b/tools/libxc/xc_domain.c   Thu Oct 25 05:49:10 2012 +0800 @@
>>      -283,6 +283,22 @@ return ret;
>>  }
>> 
>> +/* set broken page p2m */
>> +int xc_set_broken_page_p2m(xc_interface *xch,
>> +                           uint32_t domid,
>> +                           unsigned long pfn)
>> +{
>> +    int ret;
>> +    DECLARE_DOMCTL;
>> +
>> +    domctl.cmd = XEN_DOMCTL_set_broken_page_p2m;
>> +    domctl.domain = (domid_t)domid;
>> +    domctl.u.set_broken_page_p2m.pfn = pfn;
>> +    ret = do_domctl(xch, &domctl);
>> +
>> +    return ret ? -1 : 0;
>> +}
>> +
>>  /* get info from hvm guest for save */
>>  int xc_domain_hvm_getcontext(xc_interface *xch,
>>                               uint32_t domid,
>> diff -r e27a6d53ac15 tools/libxc/xc_domain_restore.c
>> --- a/tools/libxc/xc_domain_restore.c   Thu Oct 11 01:52:33 2012
>> +0800 +++ b/tools/libxc/xc_domain_restore.c   Thu Oct 25 05:49:10
>> 2012 +0800 @@ -962,9 +962,15 @@ 
>> 
>>      countpages = count;
>>      for (i = oldcount; i < buf->nr_pages; ++i)
>> -        if ((buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) ==
>> XEN_DOMCTL_PFINFO_XTAB 
>> -            ||(buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) ==
>> XEN_DOMCTL_PFINFO_XALLOC) +    { +        unsigned long pagetype;
>> +
>> +        pagetype = buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK;
>> +        if ( pagetype == XEN_DOMCTL_PFINFO_XTAB ||
>> +             pagetype == XEN_DOMCTL_PFINFO_BROKEN ||
>> +             pagetype == XEN_DOMCTL_PFINFO_XALLOC )             
>> --countpages; +    }
>> 
>>      if (!countpages)
>>          return count;
>> @@ -1200,6 +1206,17 @@
>>              /* a bogus/unmapped/allocate-only page: skip it */     
>> continue; 
>> 
>> +        if ( pagetype == XEN_DOMCTL_PFINFO_BROKEN ) +        {
>> +            if ( xc_set_broken_page_p2m(xch, dom, pfn) ) +         
>> { +                ERROR("Set p2m for broken page failed, "
>> +                      "dom=%d, pfn=%lx\n", dom, pfn);
>> +                goto err_mapped;
>> +            }
>> +            continue;
>> +        }
>> +
>>          if (pfn_err[i])
>>          {
>>              ERROR("unexpected PFN mapping failure pfn %lx map_mfn
>> %lx p2m_mfn %lx", 
>> diff -r e27a6d53ac15 tools/libxc/xc_domain_save.c
>> --- a/tools/libxc/xc_domain_save.c      Thu Oct 11 01:52:33 2012
>> +0800 +++ b/tools/libxc/xc_domain_save.c      Thu Oct 25 05:49:10
>>                  2012 +0800 @@ -1277,6 +1277,13 @@ if ( !hvm )
>>                      gmfn = pfn_to_mfn(gmfn);
>> 
>> +                if ( pfn_type[j] == XEN_DOMCTL_PFINFO_BROKEN ) +   
>> { +                    pfn_type[j] |= pfn_batch[j];
>> +                    ++run;
>> +                    continue;
>> +                }
>> +
>>                  if ( pfn_err[j] )
>>                  {
>>                      if ( pfn_type[j] == XEN_DOMCTL_PFINFO_XTAB ) @@
>>                      -1371,8 +1378,12 @@ }
>>                  }
>> 
>> -                /* skip pages that aren't present or are alloc-only
>> */ +                /* +                 * skip pages that aren't
>> present, +                 * or are broken, or are alloc-only +     
>>                  */ if ( pagetype == XEN_DOMCTL_PFINFO_XTAB
>> +                    || pagetype == XEN_DOMCTL_PFINFO_BROKEN
>>                      || pagetype == XEN_DOMCTL_PFINFO_XALLOC )
>>                      continue;
>> 
>> diff -r e27a6d53ac15 tools/libxc/xenctrl.h
>> --- a/tools/libxc/xenctrl.h     Thu Oct 11 01:52:33 2012 +0800
>> +++ b/tools/libxc/xenctrl.h     Thu Oct 25 05:49:10 2012 +0800 @@
>>                            -575,6 +575,17 @@ xc_domaininfo_t *info);
>> 
>>  /**
>> + * This function set p2m for broken page
>> + * &parm xch a handle to an open hypervisor interface
>> + * @parm domid the domain id which broken page belong to
>> + * @parm pfn the pfn number of the broken page
>> + * @return 0 on success, -1 on failure
>> + */
>> +int xc_set_broken_page_p2m(xc_interface *xch,
>> +                           uint32_t domid,
>> +                           unsigned long pfn);
>> +
>> +/**
>>   * This function returns information about the context of a hvm
>> domain 
>>   * @parm xch a handle to an open hypervisor interface
>>   * @parm domid the domain to get information from
>> diff -r e27a6d53ac15 xen/arch/x86/domctl.c
>> --- a/xen/arch/x86/domctl.c     Thu Oct 11 01:52:33 2012 +0800
>> +++ b/xen/arch/x86/domctl.c     Thu Oct 25 05:49:10 2012 +0800 @@
>>                  -209,12 +209,18 @@ for ( j = 0; j < k; j++ )
>>                  {
>>                      unsigned long type = 0;
>> +                    p2m_type_t t;
>> 
>> -                    page = get_page_from_gfn(d, arr[j], NULL,
>> P2M_ALLOC); +                    page = get_page_from_gfn(d, arr[j],
>> &t, P2M_ALLOC); 
>> 
>>                      if ( unlikely(!page) ||
>>                           unlikely(is_xen_heap_page(page)) )
>> -                        type = XEN_DOMCTL_PFINFO_XTAB; +           
>> { +                        if ( p2m_is_broken(t) )
>> +                            type = XEN_DOMCTL_PFINFO_BROKEN; +     
>> else +                            type = XEN_DOMCTL_PFINFO_XTAB; +  
>>                      } else
>>                      {
>>                          switch( page->u.inuse.type_info &
>> PGT_type_mask ) @@ -235,6 +241,9 @@ 
>> 
>>                          if ( page->u.inuse.type_info & PGT_pinned )
>>                              type |= XEN_DOMCTL_PFINFO_LPINTAB; +
>> +                        if ( page->count_info & PGC_broken )
>> +                            type = XEN_DOMCTL_PFINFO_BROKEN;       
>> } 
>> 
>>                      if ( page )
>> @@ -1568,6 +1577,28 @@
>>      }
>>      break;
>> 
>> +    case XEN_DOMCTL_set_broken_page_p2m:
>> +    {
>> +        struct domain *d;
>> +        p2m_type_t pt;
>> +        unsigned long pfn;
>> +
>> +        d = rcu_lock_domain_by_id(domctl->domain); +        if ( d
>> != NULL ) +        {
>> +            pfn = domctl->u.set_broken_page_p2m.pfn; +
>> +            get_gfn_query(d, pfn, &pt);
>> +            p2m_change_type(d, pfn, pt, p2m_ram_broken); +         
>> put_gfn(d, pfn); +
>> +            rcu_unlock_domain(d);
>> +        }
>> +        else
>> +            ret = -ESRCH;
>> +    }
>> +    break;
>> +
>>      default:
>>          ret = iommu_do_domctl(domctl, u_domctl);
>>          break;
>> diff -r e27a6d53ac15 xen/include/public/domctl.h
>> --- a/xen/include/public/domctl.h       Thu Oct 11 01:52:33 2012
>> +0800 +++ b/xen/include/public/domctl.h       Thu Oct 25 05:49:10
>>  2012 +0800 @@ -136,6 +136,7 @@ #define XEN_DOMCTL_PFINFO_LPINTAB
>>  (0x1U<<31) #define XEN_DOMCTL_PFINFO_XTAB    (0xfU<<28) /* invalid
>>  page */ #define XEN_DOMCTL_PFINFO_XALLOC  (0xeU<<28) /*
>> allocate-only page */ +#define XEN_DOMCTL_PFINFO_BROKEN  (0xdU<<28)
>>  /* broken page */ #define XEN_DOMCTL_PFINFO_PAGEDTAB (0x8U<<28)
>>  #define XEN_DOMCTL_PFINFO_LTAB_MASK (0xfU<<28)
>> 
>> @@ -835,6 +836,12 @@
>>  typedef struct xen_domctl_set_access_required
>>  xen_domctl_set_access_required_t;
>> DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_access_required_t); 
>> 
>> +struct xen_domctl_set_broken_page_p2m {
>> +    uint64_aligned_t pfn;
>> +};
>> +typedef struct xen_domctl_set_broken_page_p2m
>> xen_domctl_set_broken_page_p2m_t;
>>  +DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_broken_page_p2m_t); +
>>      struct xen_domctl { uint32_t cmd;
>>  #define XEN_DOMCTL_createdomain                   1 @@ -900,6
>>  +907,7 @@ #define XEN_DOMCTL_set_access_required           64
>>  #define XEN_DOMCTL_audit_p2m                     65
>>  #define XEN_DOMCTL_set_virq_handler              66
>> +#define XEN_DOMCTL_set_broken_page_p2m           67
>>  #define XEN_DOMCTL_gdbsx_guestmemio            1000
>>  #define XEN_DOMCTL_gdbsx_pausevcpu             1001
>>  #define XEN_DOMCTL_gdbsx_unpausevcpu           1002 @@ -955,6
>>          +963,7 @@ struct xen_domctl_audit_p2m         audit_p2m;
>>          struct xen_domctl_set_virq_handler  set_virq_handler;
>>          struct xen_domctl_gdbsx_memio       gdbsx_guest_memio;
>> +        struct xen_domctl_set_broken_page_p2m set_broken_page_p2m;
>>          struct xen_domctl_gdbsx_pauseunp_vcpu gdbsx_pauseunp_vcpu;
>>          struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
>>          uint8_t                             pad[128];
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 11:02:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 11:02:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTW3d-0007g7-A6; Wed, 31 Oct 2012 11:02:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTW3b-0007fx-QP
	for xen-devel@lists.xen.org; Wed, 31 Oct 2012 11:02:00 +0000
Received: from [85.158.143.99:55702] by server-3.bemta-4.messagelabs.com id
	9B/B2-06841-72501905; Wed, 31 Oct 2012 11:01:59 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1351681317!27160021!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30090 invoked from network); 31 Oct 2012 11:01:58 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Oct 2012 11:01:58 -0000
Received: by mail-qc0-f173.google.com with SMTP id b12so1065869qca.32
	for ; Wed, 31 Oct 2012 04:01:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=Hn8jD77dw0k1C/GncObo1VOyumUXUVyS5jCMnUilA74=;
	b=K9ubE5SjqKWVdZN1ExyT5KzWbv2JIdx3JYHikFJ0WlWENZVgGnQ6JRawyZUgX6Q3rg
	fi92au+ymadPeYfzGPN8OUP81hZ1iUdhAkjs1DXZr8+uv0CVNW76N4OvyUGcXMYxKfFg
	jCZDNMxS0v/pAEpSuIJu+wiorwDzDbbWYwuEjtB5uPuXDKvgMrCRShhiVzznDcgQGGck
	w6QhYgQiBGfhE7wJPLISlkveqoCFZOdmYxOgfbL3aH2CeNIe0hy8pwMxLmbUEbwoG9pX
	383bpHM42CSh33d3aYxCYrIVGCiU/umouiJQ3KGZhXSo/Tf8c9Z3swwS3d0VpWe/Mt/W
	3giQ==
Received: by 10.224.33.135 with SMTP id h7mr20299393qad.26.1351681317260;
	Wed, 31 Oct 2012 04:01:57 -0700 (PDT)
Received: from localhost.localdomain
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id f3sm1602265qaj.7.2012.10.31.04.01.56
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 31 Oct 2012 04:01:56 -0700 (PDT)
Date: Wed, 31 Oct 2012 07:01:51 -0400
From: Konrad Rzeszutek Wilk 
To: Konrad Rzeszutek Wilk 
Message-ID: <20121031110149.GA6376@localhost.localdomain>
References: <1351078936-14159-1-git-send-email-ian.campbell@citrix.com>
	<1351081703.6537.99.camel@edumazet-glaptop>
	<1351084618.18035.27.camel@zakaz.uk.xensource.com>
	<1351085403.6537.102.camel@edumazet-glaptop>
	<1351087326.18035.50.camel@zakaz.uk.xensource.com>
	<1351092068.6537.107.camel@edumazet-glaptop>
	<1351095739.18035.83.camel@zakaz.uk.xensource.com>
	<1351097000.6537.109.camel@edumazet-glaptop>
	<20121030165309.GA30483@phenom.dumpdata.com>
	<20121030172352.GA31997@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20121030172352.GA31997@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "netdev@vger.kernel.org" ,
	Eric Dumazet , Ian Campbell ,
	Eric Dumazet ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] net: allow configuration of the size of
 page in __netdev_alloc_frag
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 30, 2012 at 01:23:52PM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Oct 30, 2012 at 12:53:09PM -0400, Konrad Rzeszutek Wilk wrote:
> > On Wed, Oct 24, 2012 at 06:43:20PM +0200, Eric Dumazet wrote:
> > > On Wed, 2012-10-24 at 17:22 +0100, Ian Campbell wrote:
> > > > On Wed, 2012-10-24 at 16:21 +0100, Eric Dumazet wrote:
> > > 
> > > > > If you really have such problems, why locally generated TCP traffic
> > > > > doesnt also have it ?
> > > > 
> > > > I think it does. The reason I noticed the original problem was that ssh
> > > > to the machine was virtually (no pun intended) unusable.
> > > > 
> > > > > Your patch doesnt touch sk_page_frag_refill(), does it ?
> > > > 
> > > > That's right. It doesn't. When is (sk->sk_allocation & __GFP_WAIT) true?
> > > > Is it possible I'm just not hitting that case?
> > > > 
> > > 
> > > I hope not. GFP_KERNEL has __GFP_WAIT.
> > > 
> > > > Is it possible that this only affects certain traffic patterns (I only
> > > > really tried ssh/scp and ping)? Or perhaps its just that the swiotlb is
> > > > only broken in one corner case and not the other.
> > > 
> > > Could you try a netperf -t TCP_STREAM ?
> > 
> > For fun I did a couple of tests - I setup two machines (one r8168, the other
> > e1000e) and tried to do netperf/netserver. Both of them are running a baremetal
> > kernel and one of them has 'iommu=soft swiotlb=force' to simulate the worst
> > case. This is using v3.7-rc3.
> 
> I also did a test with the patch at the top, with the same setup and ... it
> does look like it fixes some issues, but not the underlaying one.
> 
> The same test, with net.core.netdev_frag_page_max_order=0, the e1000e->r8169
> gets ~124, but then on subsequent runs it picks up to ~933. If I let the
> machine stay a bit idle and then do this again, it does around ~124 again.
> 
> Thoughts?

Argh. Please disregard this test. I added an extra patch in the kernel
tree to track the SWIOTLB bounce usage and print it.. and the printk was
going out to the FB, which was not too fast - so the whole test was being
slowed down by FB drivers :-)

Will re-run this test without the offending patch.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 11:02:17 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 11:02:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTW3d-0007g7-A6; Wed, 31 Oct 2012 11:02:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTW3b-0007fx-QP
	for xen-devel@lists.xen.org; Wed, 31 Oct 2012 11:02:00 +0000
Received: from [85.158.143.99:55702] by server-3.bemta-4.messagelabs.com id
	9B/B2-06841-72501905; Wed, 31 Oct 2012 11:01:59 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1351681317!27160021!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30090 invoked from network); 31 Oct 2012 11:01:58 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Oct 2012 11:01:58 -0000
Received: by mail-qc0-f173.google.com with SMTP id b12so1065869qca.32
	for ; Wed, 31 Oct 2012 04:01:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=Hn8jD77dw0k1C/GncObo1VOyumUXUVyS5jCMnUilA74=;
	b=K9ubE5SjqKWVdZN1ExyT5KzWbv2JIdx3JYHikFJ0WlWENZVgGnQ6JRawyZUgX6Q3rg
	fi92au+ymadPeYfzGPN8OUP81hZ1iUdhAkjs1DXZr8+uv0CVNW76N4OvyUGcXMYxKfFg
	jCZDNMxS0v/pAEpSuIJu+wiorwDzDbbWYwuEjtB5uPuXDKvgMrCRShhiVzznDcgQGGck
	w6QhYgQiBGfhE7wJPLISlkveqoCFZOdmYxOgfbL3aH2CeNIe0hy8pwMxLmbUEbwoG9pX
	383bpHM42CSh33d3aYxCYrIVGCiU/umouiJQ3KGZhXSo/Tf8c9Z3swwS3d0VpWe/Mt/W
	3giQ==
Received: by 10.224.33.135 with SMTP id h7mr20299393qad.26.1351681317260;
	Wed, 31 Oct 2012 04:01:57 -0700 (PDT)
Received: from localhost.localdomain
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id f3sm1602265qaj.7.2012.10.31.04.01.56
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 31 Oct 2012 04:01:56 -0700 (PDT)
Date: Wed, 31 Oct 2012 07:01:51 -0400
From: Konrad Rzeszutek Wilk 
To: Konrad Rzeszutek Wilk 
Message-ID: <20121031110149.GA6376@localhost.localdomain>
References: <1351078936-14159-1-git-send-email-ian.campbell@citrix.com>
	<1351081703.6537.99.camel@edumazet-glaptop>
	<1351084618.18035.27.camel@zakaz.uk.xensource.com>
	<1351085403.6537.102.camel@edumazet-glaptop>
	<1351087326.18035.50.camel@zakaz.uk.xensource.com>
	<1351092068.6537.107.camel@edumazet-glaptop>
	<1351095739.18035.83.camel@zakaz.uk.xensource.com>
	<1351097000.6537.109.camel@edumazet-glaptop>
	<20121030165309.GA30483@phenom.dumpdata.com>
	<20121030172352.GA31997@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20121030172352.GA31997@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "netdev@vger.kernel.org" ,
	Eric Dumazet , Ian Campbell ,
	Eric Dumazet ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH] net: allow configuration of the size of
 page in __netdev_alloc_frag
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 30, 2012 at 01:23:52PM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Oct 30, 2012 at 12:53:09PM -0400, Konrad Rzeszutek Wilk wrote:
> > On Wed, Oct 24, 2012 at 06:43:20PM +0200, Eric Dumazet wrote:
> > > On Wed, 2012-10-24 at 17:22 +0100, Ian Campbell wrote:
> > > > On Wed, 2012-10-24 at 16:21 +0100, Eric Dumazet wrote:
> > > 
> > > > > If you really have such problems, why locally generated TCP traffic
> > > > > doesnt also have it ?
> > > > 
> > > > I think it does. The reason I noticed the original problem was that ssh
> > > > to the machine was virtually (no pun intended) unusable.
> > > > 
> > > > > Your patch doesnt touch sk_page_frag_refill(), does it ?
> > > > 
> > > > That's right. It doesn't. When is (sk->sk_allocation & __GFP_WAIT) true?
> > > > Is it possible I'm just not hitting that case?
> > > > 
> > > 
> > > I hope not. GFP_KERNEL has __GFP_WAIT.
> > > 
> > > > Is it possible that this only affects certain traffic patterns (I only
> > > > really tried ssh/scp and ping)? Or perhaps its just that the swiotlb is
> > > > only broken in one corner case and not the other.
> > > 
> > > Could you try a netperf -t TCP_STREAM ?
> > 
> > For fun I did a couple of tests - I setup two machines (one r8168, the other
> > e1000e) and tried to do netperf/netserver. Both of them are running a baremetal
> > kernel and one of them has 'iommu=soft swiotlb=force' to simulate the worst
> > case. This is using v3.7-rc3.
> 
> I also did a test with the patch at the top, with the same setup and ... it
> does look like it fixes some issues, but not the underlaying one.
> 
> The same test, with net.core.netdev_frag_page_max_order=0, the e1000e->r8169
> gets ~124, but then on subsequent runs it picks up to ~933. If I let the
> machine stay a bit idle and then do this again, it does around ~124 again.
> 
> Thoughts?

Argh. Please disregard this test. I added an extra patch in the kernel
tree to track the SWIOTLB bounce usage and print it.. and the printk was
going out to the FB, which was not too fast - so the whole test was being
slowed down by FB drivers :-)

Will re-run this test without the offending patch.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 11:15:34 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 11:15:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTWGS-00085x-UT; Wed, 31 Oct 2012 11:15:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTWGR-00085s-1u
	for xen-devel@lists.xensource.com; Wed, 31 Oct 2012 11:15:15 +0000
Received: from [85.158.139.83:45933] by server-10.bemta-5.messagelabs.com id
	A5/4F-01025-24801905; Wed, 31 Oct 2012 11:15:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1351682112!28110661!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY2MTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20529 invoked from network); 31 Oct 2012 11:15:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Oct 2012 11:15:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,687,1344211200"; d="scan'208";a="15509488"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Oct 2012 11:15:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 31 Oct 2012 11:15:10 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TTWGN-0000Ns-1r;
	Wed, 31 Oct 2012 11:15:11 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TTWGN-0004JC-0Y;
	Wed, 31 Oct 2012 11:15:11 +0000
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Wed, 31 Oct 2012 11:15:11 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 14186: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14186 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14186/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl             9 guest-start               fail REGR. vs. 14076
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 14076
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 14076
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 14076

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore         fail REGR. vs. 14076

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  2bca7e58a3df
baseline version:
 xen                  40ccbee890e1

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla 
  Bastian Blank 
  Chuang Cao 
  George Dunlap 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jason McCarver 
  Joe Jin 
  Keir Fraser 
  Matt Wilson 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Sander Eikelenboom 
  Stefano Stabellini 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 632 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 11:15:34 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 11:15:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTWGS-00085x-UT; Wed, 31 Oct 2012 11:15:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTWGR-00085s-1u
	for xen-devel@lists.xensource.com; Wed, 31 Oct 2012 11:15:15 +0000
Received: from [85.158.139.83:45933] by server-10.bemta-5.messagelabs.com id
	A5/4F-01025-24801905; Wed, 31 Oct 2012 11:15:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1351682112!28110661!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY2MTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20529 invoked from network); 31 Oct 2012 11:15:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Oct 2012 11:15:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,687,1344211200"; d="scan'208";a="15509488"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Oct 2012 11:15:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 31 Oct 2012 11:15:10 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TTWGN-0000Ns-1r;
	Wed, 31 Oct 2012 11:15:11 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TTWGN-0004JC-0Y;
	Wed, 31 Oct 2012 11:15:11 +0000
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Wed, 31 Oct 2012 11:15:11 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 14186: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14186 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14186/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl             9 guest-start               fail REGR. vs. 14076
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 14076
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 14076
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 14076

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore         fail REGR. vs. 14076

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  2bca7e58a3df
baseline version:
 xen                  40ccbee890e1

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla 
  Bastian Blank 
  Chuang Cao 
  George Dunlap 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jason McCarver 
  Joe Jin 
  Keir Fraser 
  Matt Wilson 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Sander Eikelenboom 
  Stefano Stabellini 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 632 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 11:16:51 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 11:16:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTWHZ-0008AF-Cr; Wed, 31 Oct 2012 11:16:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTWHX-0008A9-LR
	for xen-devel@lists.xensource.com; Wed, 31 Oct 2012 11:16:23 +0000
Received: from [85.158.139.83:53819] by server-9.bemta-5.messagelabs.com id
	7F/CB-23053-68801905; Wed, 31 Oct 2012 11:16:22 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1351682181!28110893!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzE3Mjkx\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25715 invoked from network); 31 Oct 2012 11:16:22 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-12.tower-182.messagelabs.com with SMTP;
	31 Oct 2012 11:16:22 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 31 Oct 2012 04:16:20 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,687,1344236400"; d="scan'208";a="235110577"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by orsmga002.jf.intel.com with ESMTP; 31 Oct 2012 04:16:20 -0700
Received: from fmsmsx102.amr.corp.intel.com (10.19.9.53) by
	FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 31 Oct 2012 04:16:19 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX102.amr.corp.intel.com (10.19.9.53) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 31 Oct 2012 04:16:19 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.186]) with mapi id
	14.01.0355.002; Wed, 31 Oct 2012 19:16:17 +0800
From: "Liu, Jinsong" 
To: George Dunlap , Ian Jackson
	, Jan Beulich 
Thread-Topic: [PATCH 00/02] broken page handle wrt migration
Thread-Index: Ac23WSTT+7sI/+C1QESoHxco/0THgw==
Date: Wed, 31 Oct 2012 11:16:16 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: [Xen-devel] [PATCH 00/02] broken page handle wrt migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

These 2 patches are used to handle broken page wrt migration. Generally there are 2 cases: the broken page occur before migration, and the broken page occur during migration.

Patch 01 handles the case that broken page occurred before migration: At the sender, the broken page would not be copied to target while its pfn_type and pfn number would be transferred to target, so that at target, it would set p2m as p2m_ram_broken for broken page.

Patch 02 handles the case that broken page occurred during migration: At the sender, marks the broken page to dirty bitmap, so that at copypages stage of migration, its pfn_type and pfn number would transfer to target. At the target, it would set p2m as p2m_ram_broken for broken page.

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 11:16:51 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 11:16:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTWHZ-0008AF-Cr; Wed, 31 Oct 2012 11:16:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTWHX-0008A9-LR
	for xen-devel@lists.xensource.com; Wed, 31 Oct 2012 11:16:23 +0000
Received: from [85.158.139.83:53819] by server-9.bemta-5.messagelabs.com id
	7F/CB-23053-68801905; Wed, 31 Oct 2012 11:16:22 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1351682181!28110893!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzE3Mjkx\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25715 invoked from network); 31 Oct 2012 11:16:22 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-12.tower-182.messagelabs.com with SMTP;
	31 Oct 2012 11:16:22 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 31 Oct 2012 04:16:20 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,687,1344236400"; d="scan'208";a="235110577"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by orsmga002.jf.intel.com with ESMTP; 31 Oct 2012 04:16:20 -0700
Received: from fmsmsx102.amr.corp.intel.com (10.19.9.53) by
	FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 31 Oct 2012 04:16:19 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX102.amr.corp.intel.com (10.19.9.53) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 31 Oct 2012 04:16:19 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.186]) with mapi id
	14.01.0355.002; Wed, 31 Oct 2012 19:16:17 +0800
From: "Liu, Jinsong" 
To: George Dunlap , Ian Jackson
	, Jan Beulich 
Thread-Topic: [PATCH 00/02] broken page handle wrt migration
Thread-Index: Ac23WSTT+7sI/+C1QESoHxco/0THgw==
Date: Wed, 31 Oct 2012 11:16:16 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: [Xen-devel] [PATCH 00/02] broken page handle wrt migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

These 2 patches are used to handle broken page wrt migration. Generally there are 2 cases: the broken page occur before migration, and the broken page occur during migration.

Patch 01 handles the case that broken page occurred before migration: At the sender, the broken page would not be copied to target while its pfn_type and pfn number would be transferred to target, so that at target, it would set p2m as p2m_ram_broken for broken page.

Patch 02 handles the case that broken page occurred during migration: At the sender, marks the broken page to dirty bitmap, so that at copypages stage of migration, its pfn_type and pfn number would transfer to target. At the target, it would set p2m as p2m_ram_broken for broken page.

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 11:19:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 11:19:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTWKE-0008Ke-VQ; Wed, 31 Oct 2012 11:19:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTWKD-0008KP-NE
	for xen-devel@lists.xen.org; Wed, 31 Oct 2012 11:19:09 +0000
Received: from [85.158.139.211:12403] by server-5.bemta-5.messagelabs.com id
	2D/FE-09732-C2901905; Wed, 31 Oct 2012 11:19:08 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1351682348!18377446!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25125 invoked from network); 31 Oct 2012 11:19:08 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Oct 2012 11:19:08 -0000
Received: by mail-wg0-f51.google.com with SMTP id ed3so633181wgb.32
	for ; Wed, 31 Oct 2012 04:19:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:from:to:cc:in-reply-to:references:content-type:date
	:message-id:mime-version:x-mailer:content-transfer-encoding;
	bh=d/OZRenK7SQG2mhEp24MazT2l7ZZHQrazIas5Q9lPbw=;
	b=NIVtp8ra+gMCoEpB9jeMA+lxEkOdA3pg2iBHRT4bVysXd/T8TwKMj0e09SZMVbrHs2
	HIbYoSa0tQnGSWgKHQfAy0cMAgS+1jv5KgXugSwKxqisJXb8hXQ9vUaYFOWUBpTK56Us
	4jH8cedWY2TIWNXWn3OFogxLsqQl+97hMRA/KhEc0eQhFs+GNDKeZePEHXedaZAO9rO1
	AtGF4gheD4IDnPHh30Q1qsFtpPlGBjICvyf4G7cxHX71ax9AAos3G4uCryO6t5STZHxW
	8+VYAWtU+YNhU/piEjiWC0xH7wIC4GZwTkOdyuyp/TGpnysR4w3yoyqRtNYuf6U23c7S
	2YhA==
Received: by 10.216.207.170 with SMTP id n42mr18796164weo.173.1351682348094;
	Wed, 31 Oct 2012 04:19:08 -0700 (PDT)
Received: from [192.168.1.96] (223.144.72.86.rev.sfr.net. [86.72.144.223])
	by mx.google.com with ESMTPS id gg4sm5345530wib.6.2012.10.31.04.19.06
	(version=SSLv3 cipher=OTHER); Wed, 31 Oct 2012 04:19:07 -0700 (PDT)
From: Eric Dumazet 
To: Konrad Rzeszutek Wilk 
In-Reply-To: <20121031110149.GA6376@localhost.localdomain>
References: <1351078936-14159-1-git-send-email-ian.campbell@citrix.com>
	<1351081703.6537.99.camel@edumazet-glaptop>
	<1351084618.18035.27.camel@zakaz.uk.xensource.com>
	<1351085403.6537.102.camel@edumazet-glaptop>
	<1351087326.18035.50.camel@zakaz.uk.xensource.com>
	<1351092068.6537.107.camel@edumazet-glaptop>
	<1351095739.18035.83.camel@zakaz.uk.xensource.com>
	<1351097000.6537.109.camel@edumazet-glaptop>
	<20121030165309.GA30483@phenom.dumpdata.com>
	<20121030172352.GA31997@phenom.dumpdata.com>
	<20121031110149.GA6376@localhost.localdomain>
Date: Wed, 31 Oct 2012 12:19:06 +0100
Message-ID: <1351682346.32673.54.camel@edumazet-glaptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: "netdev@vger.kernel.org" ,
	Eric Dumazet ,
	"xen-devel@lists.xen.org" ,
	Ian Campbell ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH] net: allow configuration of the size of
 page in __netdev_alloc_frag
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-31 at 07:01 -0400, Konrad Rzeszutek Wilk wrote:

> Argh. Please disregard this test. I added an extra patch in the kernel
> tree to track the SWIOTLB bounce usage and print it.. and the printk was
> going out to the FB, which was not too fast - so the whole test was being
> slowed down by FB drivers :-)
> 
> Will re-run this test without the offending patch.

Anyway, I must confess I didnt understand what you did ;)




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 11:19:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 11:19:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTWKE-0008Ke-VQ; Wed, 31 Oct 2012 11:19:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTWKD-0008KP-NE
	for xen-devel@lists.xen.org; Wed, 31 Oct 2012 11:19:09 +0000
Received: from [85.158.139.211:12403] by server-5.bemta-5.messagelabs.com id
	2D/FE-09732-C2901905; Wed, 31 Oct 2012 11:19:08 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1351682348!18377446!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25125 invoked from network); 31 Oct 2012 11:19:08 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Oct 2012 11:19:08 -0000
Received: by mail-wg0-f51.google.com with SMTP id ed3so633181wgb.32
	for ; Wed, 31 Oct 2012 04:19:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:from:to:cc:in-reply-to:references:content-type:date
	:message-id:mime-version:x-mailer:content-transfer-encoding;
	bh=d/OZRenK7SQG2mhEp24MazT2l7ZZHQrazIas5Q9lPbw=;
	b=NIVtp8ra+gMCoEpB9jeMA+lxEkOdA3pg2iBHRT4bVysXd/T8TwKMj0e09SZMVbrHs2
	HIbYoSa0tQnGSWgKHQfAy0cMAgS+1jv5KgXugSwKxqisJXb8hXQ9vUaYFOWUBpTK56Us
	4jH8cedWY2TIWNXWn3OFogxLsqQl+97hMRA/KhEc0eQhFs+GNDKeZePEHXedaZAO9rO1
	AtGF4gheD4IDnPHh30Q1qsFtpPlGBjICvyf4G7cxHX71ax9AAos3G4uCryO6t5STZHxW
	8+VYAWtU+YNhU/piEjiWC0xH7wIC4GZwTkOdyuyp/TGpnysR4w3yoyqRtNYuf6U23c7S
	2YhA==
Received: by 10.216.207.170 with SMTP id n42mr18796164weo.173.1351682348094;
	Wed, 31 Oct 2012 04:19:08 -0700 (PDT)
Received: from [192.168.1.96] (223.144.72.86.rev.sfr.net. [86.72.144.223])
	by mx.google.com with ESMTPS id gg4sm5345530wib.6.2012.10.31.04.19.06
	(version=SSLv3 cipher=OTHER); Wed, 31 Oct 2012 04:19:07 -0700 (PDT)
From: Eric Dumazet 
To: Konrad Rzeszutek Wilk 
In-Reply-To: <20121031110149.GA6376@localhost.localdomain>
References: <1351078936-14159-1-git-send-email-ian.campbell@citrix.com>
	<1351081703.6537.99.camel@edumazet-glaptop>
	<1351084618.18035.27.camel@zakaz.uk.xensource.com>
	<1351085403.6537.102.camel@edumazet-glaptop>
	<1351087326.18035.50.camel@zakaz.uk.xensource.com>
	<1351092068.6537.107.camel@edumazet-glaptop>
	<1351095739.18035.83.camel@zakaz.uk.xensource.com>
	<1351097000.6537.109.camel@edumazet-glaptop>
	<20121030165309.GA30483@phenom.dumpdata.com>
	<20121030172352.GA31997@phenom.dumpdata.com>
	<20121031110149.GA6376@localhost.localdomain>
Date: Wed, 31 Oct 2012 12:19:06 +0100
Message-ID: <1351682346.32673.54.camel@edumazet-glaptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: "netdev@vger.kernel.org" ,
	Eric Dumazet ,
	"xen-devel@lists.xen.org" ,
	Ian Campbell ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH] net: allow configuration of the size of
 page in __netdev_alloc_frag
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-10-31 at 07:01 -0400, Konrad Rzeszutek Wilk wrote:

> Argh. Please disregard this test. I added an extra patch in the kernel
> tree to track the SWIOTLB bounce usage and print it.. and the printk was
> going out to the FB, which was not too fast - so the whole test was being
> slowed down by FB drivers :-)
> 
> Will re-run this test without the offending patch.

Anyway, I must confess I didnt understand what you did ;)




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 11:19:33 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 11:19:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTWKL-0008LK-C8; Wed, 31 Oct 2012 11:19:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTWKJ-0008L0-8f
	for xen-devel@lists.xensource.com; Wed, 31 Oct 2012 11:19:15 +0000
Received: from [85.158.139.83:17384] by server-11.bemta-5.messagelabs.com id
	86/CA-14870-23901905; Wed, 31 Oct 2012 11:19:14 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1351682348!28385131!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzE3Mjkx\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13328 invoked from network); 31 Oct 2012 11:19:09 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-10.tower-182.messagelabs.com with SMTP;
	31 Oct 2012 11:19:09 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 31 Oct 2012 04:19:08 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,687,1344236400"; d="scan'208";a="235111397"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by orsmga002.jf.intel.com with ESMTP; 31 Oct 2012 04:19:07 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 31 Oct 2012 04:19:07 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.186]) with mapi id
	14.01.0355.002; Wed, 31 Oct 2012 19:19:05 +0800
From: "Liu, Jinsong" 
To: George Dunlap , Ian Jackson
	, Jan Beulich 
Thread-Topic: [PATCH 01/02] Handles broken page occurred before migration
Thread-Index: Ac23WYlYIm/L3sGKQI2O8U05ITu8CA==
Date: Wed, 31 Oct 2012 11:19:05 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC829233537668DSHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: [Xen-devel] [PATCH 01/02] Handles broken page occurred before
	migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC829233537668DSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Handles broken page occurred before migration

This patch handles guest broken page which occurred before migration.

At sender, the broken page would be mapped but not copied to target
(otherwise it may trigger more serious error, say, SRAR error).
While its pfn_type and pfn number would be transferred to target
so that target take appropriate action.

At target, it would set p2m as p2m_ram_broken for broken page, so that
if guest access the broken page again, it would kill itself as expected.

Signed-off-by: Liu, Jinsong 

diff -r 199e829bf89c tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c	Tue Oct 30 21:26:56 2012 +0800
+++ b/tools/libxc/xc_domain.c	Thu Nov 01 00:36:38 2012 +0800
@@ -283,6 +283,22 @@
     return ret;
 }
=20
+/* set broken page p2m */
+int xc_set_broken_page_p2m(xc_interface *xch,
+                           uint32_t domid,
+                           unsigned long pfn)
+{
+    int ret;
+    DECLARE_DOMCTL;
+
+    domctl.cmd =3D XEN_DOMCTL_set_broken_page_p2m;
+    domctl.domain =3D (domid_t)domid;
+    domctl.u.set_broken_page_p2m.pfn =3D pfn;
+    ret =3D do_domctl(xch, &domctl);
+
+    return ret ? -1 : 0;
+}
+
 /* get info from hvm guest for save */
 int xc_domain_hvm_getcontext(xc_interface *xch,
                              uint32_t domid,
diff -r 199e829bf89c tools/libxc/xc_domain_restore.c
--- a/tools/libxc/xc_domain_restore.c	Tue Oct 30 21:26:56 2012 +0800
+++ b/tools/libxc/xc_domain_restore.c	Thu Nov 01 00:36:38 2012 +0800
@@ -962,9 +962,15 @@
=20
     countpages =3D count;
     for (i =3D oldcount; i < buf->nr_pages; ++i)
-        if ((buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) =3D=3D XEN_D=
OMCTL_PFINFO_XTAB
-            ||(buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) =3D=3D XEN=
_DOMCTL_PFINFO_XALLOC)
+    {
+        unsigned long pagetype;
+
+        pagetype =3D buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK;
+        if ( pagetype =3D=3D XEN_DOMCTL_PFINFO_XTAB ||
+             pagetype =3D=3D XEN_DOMCTL_PFINFO_BROKEN ||
+             pagetype =3D=3D XEN_DOMCTL_PFINFO_XALLOC )
             --countpages;
+    }
=20
     if (!countpages)
         return count;
@@ -1200,6 +1206,17 @@
             /* a bogus/unmapped/allocate-only page: skip it */
             continue;
=20
+        if ( pagetype =3D=3D XEN_DOMCTL_PFINFO_BROKEN )
+        {
+            if ( xc_set_broken_page_p2m(xch, dom, pfn) )
+            {
+                ERROR("Set p2m for broken page failed, "
+                      "dom=3D%d, pfn=3D%lx\n", dom, pfn);
+                goto err_mapped;
+            }
+            continue;
+        }
+
         if (pfn_err[i])
         {
             ERROR("unexpected PFN mapping failure pfn %lx map_mfn %lx p2m_=
mfn %lx",
diff -r 199e829bf89c tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Tue Oct 30 21:26:56 2012 +0800
+++ b/tools/libxc/xc_domain_save.c	Thu Nov 01 00:36:38 2012 +0800
@@ -1277,6 +1277,13 @@
                 if ( !hvm )
                     gmfn =3D pfn_to_mfn(gmfn);
=20
+                if ( pfn_type[j] =3D=3D XEN_DOMCTL_PFINFO_BROKEN )
+                {
+                    pfn_type[j] |=3D pfn_batch[j];
+                    ++run;
+                    continue;
+                }
+
                 if ( pfn_err[j] )
                 {
                     if ( pfn_type[j] =3D=3D XEN_DOMCTL_PFINFO_XTAB )
@@ -1371,8 +1378,12 @@
                     }
                 }
=20
-                /* skip pages that aren't present or are alloc-only */
+                /*
+                 * skip pages that aren't present,
+                 * or are broken, or are alloc-only
+                 */
                 if ( pagetype =3D=3D XEN_DOMCTL_PFINFO_XTAB
+                    || pagetype =3D=3D XEN_DOMCTL_PFINFO_BROKEN
                     || pagetype =3D=3D XEN_DOMCTL_PFINFO_XALLOC )
                     continue;
=20
diff -r 199e829bf89c tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Tue Oct 30 21:26:56 2012 +0800
+++ b/tools/libxc/xenctrl.h	Thu Nov 01 00:36:38 2012 +0800
@@ -575,6 +575,17 @@
                           xc_domaininfo_t *info);
=20
 /**
+ * This function set p2m for broken page
+ * &parm xch a handle to an open hypervisor interface
+ * @parm domid the domain id which broken page belong to
+ * @parm pfn the pfn number of the broken page
+ * @return 0 on success, -1 on failure
+ */
+int xc_set_broken_page_p2m(xc_interface *xch,
+                           uint32_t domid,
+                           unsigned long pfn);
+
+/**
  * This function returns information about the context of a hvm domain
  * @parm xch a handle to an open hypervisor interface
  * @parm domid the domain to get information from
diff -r 199e829bf89c xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c	Tue Oct 30 21:26:56 2012 +0800
+++ b/xen/arch/x86/domctl.c	Thu Nov 01 00:36:38 2012 +0800
@@ -209,12 +209,18 @@
                 for ( j =3D 0; j < k; j++ )
                 {
                     unsigned long type =3D 0;
+                    p2m_type_t t;
=20
-                    page =3D get_page_from_gfn(d, arr[j], NULL, P2M_ALLOC)=
;
+                    page =3D get_page_from_gfn(d, arr[j], &t, P2M_ALLOC);
=20
                     if ( unlikely(!page) ||
                          unlikely(is_xen_heap_page(page)) )
-                        type =3D XEN_DOMCTL_PFINFO_XTAB;
+                    {
+                        if ( p2m_is_broken(t) )
+                            type =3D XEN_DOMCTL_PFINFO_BROKEN;
+                        else
+                            type =3D XEN_DOMCTL_PFINFO_XTAB;
+                    }
                     else
                     {
                         switch( page->u.inuse.type_info & PGT_type_mask )
@@ -235,6 +241,9 @@
=20
                         if ( page->u.inuse.type_info & PGT_pinned )
                             type |=3D XEN_DOMCTL_PFINFO_LPINTAB;
+
+                        if ( page->count_info & PGC_broken )
+                            type =3D XEN_DOMCTL_PFINFO_BROKEN;
                     }
=20
                     if ( page )
@@ -1568,6 +1577,38 @@
     }
     break;
=20
+    case XEN_DOMCTL_set_broken_page_p2m:
+    {
+        struct domain *d;
+        p2m_type_t pt;
+        unsigned long pfn;
+        mfn_t mfn;
+
+        d =3D rcu_lock_domain_by_id(domctl->domain);
+        if ( d !=3D NULL )
+        {
+            pfn =3D domctl->u.set_broken_page_p2m.pfn;
+
+            mfn =3D get_gfn_query(d, pfn, &pt);
+            if ( !mfn_valid(mfn_x(mfn)) || !p2m_is_ram(pt) )
+            {
+                put_gfn(d, pfn);
+                rcu_unlock_domain(d);
+                ret =3D -EINVAL;
+                break;
+            }
+
+            if ( p2m_change_type(d, pfn, pt, p2m_ram_broken) !=3D pt )
+                ret =3D -EINVAL;
+
+            put_gfn(d, pfn);
+            rcu_unlock_domain(d);
+        }
+        else
+            ret =3D -ESRCH;
+    }
+    break;
+
     default:
         ret =3D iommu_do_domctl(domctl, u_domctl);
         break;
diff -r 199e829bf89c xen/include/public/domctl.h
--- a/xen/include/public/domctl.h	Tue Oct 30 21:26:56 2012 +0800
+++ b/xen/include/public/domctl.h	Thu Nov 01 00:36:38 2012 +0800
@@ -136,6 +136,7 @@
 #define XEN_DOMCTL_PFINFO_LPINTAB (0x1U<<31)
 #define XEN_DOMCTL_PFINFO_XTAB    (0xfU<<28) /* invalid page */
 #define XEN_DOMCTL_PFINFO_XALLOC  (0xeU<<28) /* allocate-only page */
+#define XEN_DOMCTL_PFINFO_BROKEN  (0xdU<<28) /* broken page */
 #define XEN_DOMCTL_PFINFO_PAGEDTAB (0x8U<<28)
 #define XEN_DOMCTL_PFINFO_LTAB_MASK (0xfU<<28)
=20
@@ -835,6 +836,12 @@
 typedef struct xen_domctl_set_access_required xen_domctl_set_access_requir=
ed_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_access_required_t);
=20
+struct xen_domctl_set_broken_page_p2m {
+    uint64_aligned_t pfn;
+};
+typedef struct xen_domctl_set_broken_page_p2m xen_domctl_set_broken_page_p=
2m_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_broken_page_p2m_t);
+
 struct xen_domctl {
     uint32_t cmd;
 #define XEN_DOMCTL_createdomain                   1
@@ -900,6 +907,7 @@
 #define XEN_DOMCTL_set_access_required           64
 #define XEN_DOMCTL_audit_p2m                     65
 #define XEN_DOMCTL_set_virq_handler              66
+#define XEN_DOMCTL_set_broken_page_p2m           67
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -955,6 +963,7 @@
         struct xen_domctl_audit_p2m         audit_p2m;
         struct xen_domctl_set_virq_handler  set_virq_handler;
         struct xen_domctl_gdbsx_memio       gdbsx_guest_memio;
+        struct xen_domctl_set_broken_page_p2m set_broken_page_p2m;
         struct xen_domctl_gdbsx_pauseunp_vcpu gdbsx_pauseunp_vcpu;
         struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
         uint8_t                             pad[128];=

--_002_DE8DF0795D48FD4CA783C40EC829233537668DSHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="broken_page_occur_before_migration.patch"
Content-Description: broken_page_occur_before_migration.patch
Content-Disposition: attachment;
	filename="broken_page_occur_before_migration.patch"; size=8761;
	creation-date="Wed, 31 Oct 2012 10:08:53 GMT";
	modification-date="Wed, 31 Oct 2012 17:38:56 GMT"
Content-Transfer-Encoding: base64

SGFuZGxlcyBicm9rZW4gcGFnZSBvY2N1cnJlZCBiZWZvcmUgbWlncmF0aW9uCgpUaGlzIHBhdGNo
IGhhbmRsZXMgZ3Vlc3QgYnJva2VuIHBhZ2Ugd2hpY2ggb2NjdXJyZWQgYmVmb3JlIG1pZ3JhdGlv
bi4KCkF0IHNlbmRlciwgdGhlIGJyb2tlbiBwYWdlIHdvdWxkIGJlIG1hcHBlZCBidXQgbm90IGNv
cGllZCB0byB0YXJnZXQKKG90aGVyd2lzZSBpdCBtYXkgdHJpZ2dlciBtb3JlIHNlcmlvdXMgZXJy
b3IsIHNheSwgU1JBUiBlcnJvcikuCldoaWxlIGl0cyBwZm5fdHlwZSBhbmQgcGZuIG51bWJlciB3
b3VsZCBiZSB0cmFuc2ZlcnJlZCB0byB0YXJnZXQKc28gdGhhdCB0YXJnZXQgdGFrZSBhcHByb3By
aWF0ZSBhY3Rpb24uCgpBdCB0YXJnZXQsIGl0IHdvdWxkIHNldCBwMm0gYXMgcDJtX3JhbV9icm9r
ZW4gZm9yIGJyb2tlbiBwYWdlLCBzbyB0aGF0CmlmIGd1ZXN0IGFjY2VzcyB0aGUgYnJva2VuIHBh
Z2UgYWdhaW4sIGl0IHdvdWxkIGtpbGwgaXRzZWxmIGFzIGV4cGVjdGVkLgoKU2lnbmVkLW9mZi1i
eTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+CgpkaWZmIC1yIDE5OWU4Mjli
Zjg5YyB0b29scy9saWJ4Yy94Y19kb21haW4uYwotLS0gYS90b29scy9saWJ4Yy94Y19kb21haW4u
YwlUdWUgT2N0IDMwIDIxOjI2OjU2IDIwMTIgKzA4MDAKKysrIGIvdG9vbHMvbGlieGMveGNfZG9t
YWluLmMJVGh1IE5vdiAwMSAwMDozNjozOCAyMDEyICswODAwCkBAIC0yODMsNiArMjgzLDIyIEBA
CiAgICAgcmV0dXJuIHJldDsKIH0KIAorLyogc2V0IGJyb2tlbiBwYWdlIHAybSAqLworaW50IHhj
X3NldF9icm9rZW5fcGFnZV9wMm0oeGNfaW50ZXJmYWNlICp4Y2gsCisgICAgICAgICAgICAgICAg
ICAgICAgICAgICB1aW50MzJfdCBkb21pZCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgIHVu
c2lnbmVkIGxvbmcgcGZuKQoreworICAgIGludCByZXQ7CisgICAgREVDTEFSRV9ET01DVEw7CisK
KyAgICBkb21jdGwuY21kID0gWEVOX0RPTUNUTF9zZXRfYnJva2VuX3BhZ2VfcDJtOworICAgIGRv
bWN0bC5kb21haW4gPSAoZG9taWRfdClkb21pZDsKKyAgICBkb21jdGwudS5zZXRfYnJva2VuX3Bh
Z2VfcDJtLnBmbiA9IHBmbjsKKyAgICByZXQgPSBkb19kb21jdGwoeGNoLCAmZG9tY3RsKTsKKwor
ICAgIHJldHVybiByZXQgPyAtMSA6IDA7Cit9CisKIC8qIGdldCBpbmZvIGZyb20gaHZtIGd1ZXN0
IGZvciBzYXZlICovCiBpbnQgeGNfZG9tYWluX2h2bV9nZXRjb250ZXh0KHhjX2ludGVyZmFjZSAq
eGNoLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJfdCBkb21pZCwKZGlmZiAt
ciAxOTllODI5YmY4OWMgdG9vbHMvbGlieGMveGNfZG9tYWluX3Jlc3RvcmUuYwotLS0gYS90b29s
cy9saWJ4Yy94Y19kb21haW5fcmVzdG9yZS5jCVR1ZSBPY3QgMzAgMjE6MjY6NTYgMjAxMiArMDgw
MAorKysgYi90b29scy9saWJ4Yy94Y19kb21haW5fcmVzdG9yZS5jCVRodSBOb3YgMDEgMDA6MzY6
MzggMjAxMiArMDgwMApAQCAtOTYyLDkgKzk2MiwxNSBAQAogCiAgICAgY291bnRwYWdlcyA9IGNv
dW50OwogICAgIGZvciAoaSA9IG9sZGNvdW50OyBpIDwgYnVmLT5ucl9wYWdlczsgKytpKQotICAg
ICAgICBpZiAoKGJ1Zi0+cGZuX3R5cGVzW2ldICYgWEVOX0RPTUNUTF9QRklORk9fTFRBQl9NQVNL
KSA9PSBYRU5fRE9NQ1RMX1BGSU5GT19YVEFCCi0gICAgICAgICAgICB8fChidWYtPnBmbl90eXBl
c1tpXSAmIFhFTl9ET01DVExfUEZJTkZPX0xUQUJfTUFTSykgPT0gWEVOX0RPTUNUTF9QRklORk9f
WEFMTE9DKQorICAgIHsKKyAgICAgICAgdW5zaWduZWQgbG9uZyBwYWdldHlwZTsKKworICAgICAg
ICBwYWdldHlwZSA9IGJ1Zi0+cGZuX3R5cGVzW2ldICYgWEVOX0RPTUNUTF9QRklORk9fTFRBQl9N
QVNLOworICAgICAgICBpZiAoIHBhZ2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX1hUQUIgfHwK
KyAgICAgICAgICAgICBwYWdldHlwZSA9PSBYRU5fRE9NQ1RMX1BGSU5GT19CUk9LRU4gfHwKKyAg
ICAgICAgICAgICBwYWdldHlwZSA9PSBYRU5fRE9NQ1RMX1BGSU5GT19YQUxMT0MgKQogICAgICAg
ICAgICAgLS1jb3VudHBhZ2VzOworICAgIH0KIAogICAgIGlmICghY291bnRwYWdlcykKICAgICAg
ICAgcmV0dXJuIGNvdW50OwpAQCAtMTIwMCw2ICsxMjA2LDE3IEBACiAgICAgICAgICAgICAvKiBh
IGJvZ3VzL3VubWFwcGVkL2FsbG9jYXRlLW9ubHkgcGFnZTogc2tpcCBpdCAqLwogICAgICAgICAg
ICAgY29udGludWU7CiAKKyAgICAgICAgaWYgKCBwYWdldHlwZSA9PSBYRU5fRE9NQ1RMX1BGSU5G
T19CUk9LRU4gKQorICAgICAgICB7CisgICAgICAgICAgICBpZiAoIHhjX3NldF9icm9rZW5fcGFn
ZV9wMm0oeGNoLCBkb20sIHBmbikgKQorICAgICAgICAgICAgeworICAgICAgICAgICAgICAgIEVS
Uk9SKCJTZXQgcDJtIGZvciBicm9rZW4gcGFnZSBmYWlsZWQsICIKKyAgICAgICAgICAgICAgICAg
ICAgICAiZG9tPSVkLCBwZm49JWx4XG4iLCBkb20sIHBmbik7CisgICAgICAgICAgICAgICAgZ290
byBlcnJfbWFwcGVkOworICAgICAgICAgICAgfQorICAgICAgICAgICAgY29udGludWU7CisgICAg
ICAgIH0KKwogICAgICAgICBpZiAocGZuX2VycltpXSkKICAgICAgICAgewogICAgICAgICAgICAg
RVJST1IoInVuZXhwZWN0ZWQgUEZOIG1hcHBpbmcgZmFpbHVyZSBwZm4gJWx4IG1hcF9tZm4gJWx4
IHAybV9tZm4gJWx4IiwKZGlmZiAtciAxOTllODI5YmY4OWMgdG9vbHMvbGlieGMveGNfZG9tYWlu
X3NhdmUuYwotLS0gYS90b29scy9saWJ4Yy94Y19kb21haW5fc2F2ZS5jCVR1ZSBPY3QgMzAgMjE6
MjY6NTYgMjAxMiArMDgwMAorKysgYi90b29scy9saWJ4Yy94Y19kb21haW5fc2F2ZS5jCVRodSBO
b3YgMDEgMDA6MzY6MzggMjAxMiArMDgwMApAQCAtMTI3Nyw2ICsxMjc3LDEzIEBACiAgICAgICAg
ICAgICAgICAgaWYgKCAhaHZtICkKICAgICAgICAgICAgICAgICAgICAgZ21mbiA9IHBmbl90b19t
Zm4oZ21mbik7CiAKKyAgICAgICAgICAgICAgICBpZiAoIHBmbl90eXBlW2pdID09IFhFTl9ET01D
VExfUEZJTkZPX0JST0tFTiApCisgICAgICAgICAgICAgICAgeworICAgICAgICAgICAgICAgICAg
ICBwZm5fdHlwZVtqXSB8PSBwZm5fYmF0Y2hbal07CisgICAgICAgICAgICAgICAgICAgICsrcnVu
OworICAgICAgICAgICAgICAgICAgICBjb250aW51ZTsKKyAgICAgICAgICAgICAgICB9CisKICAg
ICAgICAgICAgICAgICBpZiAoIHBmbl9lcnJbal0gKQogICAgICAgICAgICAgICAgIHsKICAgICAg
ICAgICAgICAgICAgICAgaWYgKCBwZm5fdHlwZVtqXSA9PSBYRU5fRE9NQ1RMX1BGSU5GT19YVEFC
ICkKQEAgLTEzNzEsOCArMTM3OCwxMiBAQAogICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAg
ICAgICAgICAgfQogCi0gICAgICAgICAgICAgICAgLyogc2tpcCBwYWdlcyB0aGF0IGFyZW4ndCBw
cmVzZW50IG9yIGFyZSBhbGxvYy1vbmx5ICovCisgICAgICAgICAgICAgICAgLyoKKyAgICAgICAg
ICAgICAgICAgKiBza2lwIHBhZ2VzIHRoYXQgYXJlbid0IHByZXNlbnQsCisgICAgICAgICAgICAg
ICAgICogb3IgYXJlIGJyb2tlbiwgb3IgYXJlIGFsbG9jLW9ubHkKKyAgICAgICAgICAgICAgICAg
Ki8KICAgICAgICAgICAgICAgICBpZiAoIHBhZ2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX1hU
QUIKKyAgICAgICAgICAgICAgICAgICAgfHwgcGFnZXR5cGUgPT0gWEVOX0RPTUNUTF9QRklORk9f
QlJPS0VOCiAgICAgICAgICAgICAgICAgICAgIHx8IHBhZ2V0eXBlID09IFhFTl9ET01DVExfUEZJ
TkZPX1hBTExPQyApCiAgICAgICAgICAgICAgICAgICAgIGNvbnRpbnVlOwogCmRpZmYgLXIgMTk5
ZTgyOWJmODljIHRvb2xzL2xpYnhjL3hlbmN0cmwuaAotLS0gYS90b29scy9saWJ4Yy94ZW5jdHJs
LmgJVHVlIE9jdCAzMCAyMToyNjo1NiAyMDEyICswODAwCisrKyBiL3Rvb2xzL2xpYnhjL3hlbmN0
cmwuaAlUaHUgTm92IDAxIDAwOjM2OjM4IDIwMTIgKzA4MDAKQEAgLTU3NSw2ICs1NzUsMTcgQEAK
ICAgICAgICAgICAgICAgICAgICAgICAgICAgeGNfZG9tYWluaW5mb190ICppbmZvKTsKIAogLyoq
CisgKiBUaGlzIGZ1bmN0aW9uIHNldCBwMm0gZm9yIGJyb2tlbiBwYWdlCisgKiAmcGFybSB4Y2gg
YSBoYW5kbGUgdG8gYW4gb3BlbiBoeXBlcnZpc29yIGludGVyZmFjZQorICogQHBhcm0gZG9taWQg
dGhlIGRvbWFpbiBpZCB3aGljaCBicm9rZW4gcGFnZSBiZWxvbmcgdG8KKyAqIEBwYXJtIHBmbiB0
aGUgcGZuIG51bWJlciBvZiB0aGUgYnJva2VuIHBhZ2UKKyAqIEByZXR1cm4gMCBvbiBzdWNjZXNz
LCAtMSBvbiBmYWlsdXJlCisgKi8KK2ludCB4Y19zZXRfYnJva2VuX3BhZ2VfcDJtKHhjX2ludGVy
ZmFjZSAqeGNoLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZG9taWQsCisg
ICAgICAgICAgICAgICAgICAgICAgICAgICB1bnNpZ25lZCBsb25nIHBmbik7CisKKy8qKgogICog
VGhpcyBmdW5jdGlvbiByZXR1cm5zIGluZm9ybWF0aW9uIGFib3V0IHRoZSBjb250ZXh0IG9mIGEg
aHZtIGRvbWFpbgogICogQHBhcm0geGNoIGEgaGFuZGxlIHRvIGFuIG9wZW4gaHlwZXJ2aXNvciBp
bnRlcmZhY2UKICAqIEBwYXJtIGRvbWlkIHRoZSBkb21haW4gdG8gZ2V0IGluZm9ybWF0aW9uIGZy
b20KZGlmZiAtciAxOTllODI5YmY4OWMgeGVuL2FyY2gveDg2L2RvbWN0bC5jCi0tLSBhL3hlbi9h
cmNoL3g4Ni9kb21jdGwuYwlUdWUgT2N0IDMwIDIxOjI2OjU2IDIwMTIgKzA4MDAKKysrIGIveGVu
L2FyY2gveDg2L2RvbWN0bC5jCVRodSBOb3YgMDEgMDA6MzY6MzggMjAxMiArMDgwMApAQCAtMjA5
LDEyICsyMDksMTggQEAKICAgICAgICAgICAgICAgICBmb3IgKCBqID0gMDsgaiA8IGs7IGorKyAp
CiAgICAgICAgICAgICAgICAgewogICAgICAgICAgICAgICAgICAgICB1bnNpZ25lZCBsb25nIHR5
cGUgPSAwOworICAgICAgICAgICAgICAgICAgICBwMm1fdHlwZV90IHQ7CiAKLSAgICAgICAgICAg
ICAgICAgICAgcGFnZSA9IGdldF9wYWdlX2Zyb21fZ2ZuKGQsIGFycltqXSwgTlVMTCwgUDJNX0FM
TE9DKTsKKyAgICAgICAgICAgICAgICAgICAgcGFnZSA9IGdldF9wYWdlX2Zyb21fZ2ZuKGQsIGFy
cltqXSwgJnQsIFAyTV9BTExPQyk7CiAKICAgICAgICAgICAgICAgICAgICAgaWYgKCB1bmxpa2Vs
eSghcGFnZSkgfHwKICAgICAgICAgICAgICAgICAgICAgICAgICB1bmxpa2VseShpc194ZW5faGVh
cF9wYWdlKHBhZ2UpKSApCi0gICAgICAgICAgICAgICAgICAgICAgICB0eXBlID0gWEVOX0RPTUNU
TF9QRklORk9fWFRBQjsKKyAgICAgICAgICAgICAgICAgICAgeworICAgICAgICAgICAgICAgICAg
ICAgICAgaWYgKCBwMm1faXNfYnJva2VuKHQpICkKKyAgICAgICAgICAgICAgICAgICAgICAgICAg
ICB0eXBlID0gWEVOX0RPTUNUTF9QRklORk9fQlJPS0VOOworICAgICAgICAgICAgICAgICAgICAg
ICAgZWxzZQorICAgICAgICAgICAgICAgICAgICAgICAgICAgIHR5cGUgPSBYRU5fRE9NQ1RMX1BG
SU5GT19YVEFCOworICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAgICAgIGVs
c2UKICAgICAgICAgICAgICAgICAgICAgewogICAgICAgICAgICAgICAgICAgICAgICAgc3dpdGNo
KCBwYWdlLT51LmludXNlLnR5cGVfaW5mbyAmIFBHVF90eXBlX21hc2sgKQpAQCAtMjM1LDYgKzI0
MSw5IEBACiAKICAgICAgICAgICAgICAgICAgICAgICAgIGlmICggcGFnZS0+dS5pbnVzZS50eXBl
X2luZm8gJiBQR1RfcGlubmVkICkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0eXBlIHw9
IFhFTl9ET01DVExfUEZJTkZPX0xQSU5UQUI7CisKKyAgICAgICAgICAgICAgICAgICAgICAgIGlm
ICggcGFnZS0+Y291bnRfaW5mbyAmIFBHQ19icm9rZW4gKQorICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHR5cGUgPSBYRU5fRE9NQ1RMX1BGSU5GT19CUk9LRU47CiAgICAgICAgICAgICAgICAg
ICAgIH0KIAogICAgICAgICAgICAgICAgICAgICBpZiAoIHBhZ2UgKQpAQCAtMTU2OCw2ICsxNTc3
LDM4IEBACiAgICAgfQogICAgIGJyZWFrOwogCisgICAgY2FzZSBYRU5fRE9NQ1RMX3NldF9icm9r
ZW5fcGFnZV9wMm06CisgICAgeworICAgICAgICBzdHJ1Y3QgZG9tYWluICpkOworICAgICAgICBw
Mm1fdHlwZV90IHB0OworICAgICAgICB1bnNpZ25lZCBsb25nIHBmbjsKKyAgICAgICAgbWZuX3Qg
bWZuOworCisgICAgICAgIGQgPSByY3VfbG9ja19kb21haW5fYnlfaWQoZG9tY3RsLT5kb21haW4p
OworICAgICAgICBpZiAoIGQgIT0gTlVMTCApCisgICAgICAgIHsKKyAgICAgICAgICAgIHBmbiA9
IGRvbWN0bC0+dS5zZXRfYnJva2VuX3BhZ2VfcDJtLnBmbjsKKworICAgICAgICAgICAgbWZuID0g
Z2V0X2dmbl9xdWVyeShkLCBwZm4sICZwdCk7CisgICAgICAgICAgICBpZiAoICFtZm5fdmFsaWQo
bWZuX3gobWZuKSkgfHwgIXAybV9pc19yYW0ocHQpICkKKyAgICAgICAgICAgIHsKKyAgICAgICAg
ICAgICAgICBwdXRfZ2ZuKGQsIHBmbik7CisgICAgICAgICAgICAgICAgcmN1X3VubG9ja19kb21h
aW4oZCk7CisgICAgICAgICAgICAgICAgcmV0ID0gLUVJTlZBTDsKKyAgICAgICAgICAgICAgICBi
cmVhazsKKyAgICAgICAgICAgIH0KKworICAgICAgICAgICAgaWYgKCBwMm1fY2hhbmdlX3R5cGUo
ZCwgcGZuLCBwdCwgcDJtX3JhbV9icm9rZW4pICE9IHB0ICkKKyAgICAgICAgICAgICAgICByZXQg
PSAtRUlOVkFMOworCisgICAgICAgICAgICBwdXRfZ2ZuKGQsIHBmbik7CisgICAgICAgICAgICBy
Y3VfdW5sb2NrX2RvbWFpbihkKTsKKyAgICAgICAgfQorICAgICAgICBlbHNlCisgICAgICAgICAg
ICByZXQgPSAtRVNSQ0g7CisgICAgfQorICAgIGJyZWFrOworCiAgICAgZGVmYXVsdDoKICAgICAg
ICAgcmV0ID0gaW9tbXVfZG9fZG9tY3RsKGRvbWN0bCwgdV9kb21jdGwpOwogICAgICAgICBicmVh
azsKZGlmZiAtciAxOTllODI5YmY4OWMgeGVuL2luY2x1ZGUvcHVibGljL2RvbWN0bC5oCi0tLSBh
L3hlbi9pbmNsdWRlL3B1YmxpYy9kb21jdGwuaAlUdWUgT2N0IDMwIDIxOjI2OjU2IDIwMTIgKzA4
MDAKKysrIGIveGVuL2luY2x1ZGUvcHVibGljL2RvbWN0bC5oCVRodSBOb3YgMDEgMDA6MzY6Mzgg
MjAxMiArMDgwMApAQCAtMTM2LDYgKzEzNiw3IEBACiAjZGVmaW5lIFhFTl9ET01DVExfUEZJTkZP
X0xQSU5UQUIgKDB4MVU8PDMxKQogI2RlZmluZSBYRU5fRE9NQ1RMX1BGSU5GT19YVEFCICAgICgw
eGZVPDwyOCkgLyogaW52YWxpZCBwYWdlICovCiAjZGVmaW5lIFhFTl9ET01DVExfUEZJTkZPX1hB
TExPQyAgKDB4ZVU8PDI4KSAvKiBhbGxvY2F0ZS1vbmx5IHBhZ2UgKi8KKyNkZWZpbmUgWEVOX0RP
TUNUTF9QRklORk9fQlJPS0VOICAoMHhkVTw8MjgpIC8qIGJyb2tlbiBwYWdlICovCiAjZGVmaW5l
IFhFTl9ET01DVExfUEZJTkZPX1BBR0VEVEFCICgweDhVPDwyOCkKICNkZWZpbmUgWEVOX0RPTUNU
TF9QRklORk9fTFRBQl9NQVNLICgweGZVPDwyOCkKIApAQCAtODM1LDYgKzgzNiwxMiBAQAogdHlw
ZWRlZiBzdHJ1Y3QgeGVuX2RvbWN0bF9zZXRfYWNjZXNzX3JlcXVpcmVkIHhlbl9kb21jdGxfc2V0
X2FjY2Vzc19yZXF1aXJlZF90OwogREVGSU5FX1hFTl9HVUVTVF9IQU5ETEUoeGVuX2RvbWN0bF9z
ZXRfYWNjZXNzX3JlcXVpcmVkX3QpOwogCitzdHJ1Y3QgeGVuX2RvbWN0bF9zZXRfYnJva2VuX3Bh
Z2VfcDJtIHsKKyAgICB1aW50NjRfYWxpZ25lZF90IHBmbjsKK307Cit0eXBlZGVmIHN0cnVjdCB4
ZW5fZG9tY3RsX3NldF9icm9rZW5fcGFnZV9wMm0geGVuX2RvbWN0bF9zZXRfYnJva2VuX3BhZ2Vf
cDJtX3Q7CitERUZJTkVfWEVOX0dVRVNUX0hBTkRMRSh4ZW5fZG9tY3RsX3NldF9icm9rZW5fcGFn
ZV9wMm1fdCk7CisKIHN0cnVjdCB4ZW5fZG9tY3RsIHsKICAgICB1aW50MzJfdCBjbWQ7CiAjZGVm
aW5lIFhFTl9ET01DVExfY3JlYXRlZG9tYWluICAgICAgICAgICAgICAgICAgIDEKQEAgLTkwMCw2
ICs5MDcsNyBAQAogI2RlZmluZSBYRU5fRE9NQ1RMX3NldF9hY2Nlc3NfcmVxdWlyZWQgICAgICAg
ICAgIDY0CiAjZGVmaW5lIFhFTl9ET01DVExfYXVkaXRfcDJtICAgICAgICAgICAgICAgICAgICAg
NjUKICNkZWZpbmUgWEVOX0RPTUNUTF9zZXRfdmlycV9oYW5kbGVyICAgICAgICAgICAgICA2Ngor
I2RlZmluZSBYRU5fRE9NQ1RMX3NldF9icm9rZW5fcGFnZV9wMm0gICAgICAgICAgIDY3CiAjZGVm
aW5lIFhFTl9ET01DVExfZ2Ric3hfZ3Vlc3RtZW1pbyAgICAgICAgICAgIDEwMDAKICNkZWZpbmUg
WEVOX0RPTUNUTF9nZGJzeF9wYXVzZXZjcHUgICAgICAgICAgICAgMTAwMQogI2RlZmluZSBYRU5f
RE9NQ1RMX2dkYnN4X3VucGF1c2V2Y3B1ICAgICAgICAgICAxMDAyCkBAIC05NTUsNiArOTYzLDcg
QEAKICAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfYXVkaXRfcDJtICAgICAgICAgYXVkaXRfcDJt
OwogICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF9zZXRfdmlycV9oYW5kbGVyICBzZXRfdmlycV9o
YW5kbGVyOwogICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF9nZGJzeF9tZW1pbyAgICAgICBnZGJz
eF9ndWVzdF9tZW1pbzsKKyAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfc2V0X2Jyb2tlbl9wYWdl
X3AybSBzZXRfYnJva2VuX3BhZ2VfcDJtOwogICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF9nZGJz
eF9wYXVzZXVucF92Y3B1IGdkYnN4X3BhdXNldW5wX3ZjcHU7CiAgICAgICAgIHN0cnVjdCB4ZW5f
ZG9tY3RsX2dkYnN4X2RvbXN0YXR1cyAgIGdkYnN4X2RvbXN0YXR1czsKICAgICAgICAgdWludDhf
dCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcGFkWzEyOF07Cg==

--_002_DE8DF0795D48FD4CA783C40EC829233537668DSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC829233537668DSHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Wed Oct 31 11:19:33 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 11:19:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTWKL-0008LK-C8; Wed, 31 Oct 2012 11:19:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTWKJ-0008L0-8f
	for xen-devel@lists.xensource.com; Wed, 31 Oct 2012 11:19:15 +0000
Received: from [85.158.139.83:17384] by server-11.bemta-5.messagelabs.com id
	86/CA-14870-23901905; Wed, 31 Oct 2012 11:19:14 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1351682348!28385131!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzE3Mjkx\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13328 invoked from network); 31 Oct 2012 11:19:09 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-10.tower-182.messagelabs.com with SMTP;
	31 Oct 2012 11:19:09 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 31 Oct 2012 04:19:08 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,687,1344236400"; d="scan'208";a="235111397"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by orsmga002.jf.intel.com with ESMTP; 31 Oct 2012 04:19:07 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 31 Oct 2012 04:19:07 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.186]) with mapi id
	14.01.0355.002; Wed, 31 Oct 2012 19:19:05 +0800
From: "Liu, Jinsong" 
To: George Dunlap , Ian Jackson
	, Jan Beulich 
Thread-Topic: [PATCH 01/02] Handles broken page occurred before migration
Thread-Index: Ac23WYlYIm/L3sGKQI2O8U05ITu8CA==
Date: Wed, 31 Oct 2012 11:19:05 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC829233537668DSHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: [Xen-devel] [PATCH 01/02] Handles broken page occurred before
	migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC829233537668DSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Handles broken page occurred before migration

This patch handles guest broken page which occurred before migration.

At sender, the broken page would be mapped but not copied to target
(otherwise it may trigger more serious error, say, SRAR error).
While its pfn_type and pfn number would be transferred to target
so that target take appropriate action.

At target, it would set p2m as p2m_ram_broken for broken page, so that
if guest access the broken page again, it would kill itself as expected.

Signed-off-by: Liu, Jinsong 

diff -r 199e829bf89c tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c	Tue Oct 30 21:26:56 2012 +0800
+++ b/tools/libxc/xc_domain.c	Thu Nov 01 00:36:38 2012 +0800
@@ -283,6 +283,22 @@
     return ret;
 }
=20
+/* set broken page p2m */
+int xc_set_broken_page_p2m(xc_interface *xch,
+                           uint32_t domid,
+                           unsigned long pfn)
+{
+    int ret;
+    DECLARE_DOMCTL;
+
+    domctl.cmd =3D XEN_DOMCTL_set_broken_page_p2m;
+    domctl.domain =3D (domid_t)domid;
+    domctl.u.set_broken_page_p2m.pfn =3D pfn;
+    ret =3D do_domctl(xch, &domctl);
+
+    return ret ? -1 : 0;
+}
+
 /* get info from hvm guest for save */
 int xc_domain_hvm_getcontext(xc_interface *xch,
                              uint32_t domid,
diff -r 199e829bf89c tools/libxc/xc_domain_restore.c
--- a/tools/libxc/xc_domain_restore.c	Tue Oct 30 21:26:56 2012 +0800
+++ b/tools/libxc/xc_domain_restore.c	Thu Nov 01 00:36:38 2012 +0800
@@ -962,9 +962,15 @@
=20
     countpages =3D count;
     for (i =3D oldcount; i < buf->nr_pages; ++i)
-        if ((buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) =3D=3D XEN_D=
OMCTL_PFINFO_XTAB
-            ||(buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) =3D=3D XEN=
_DOMCTL_PFINFO_XALLOC)
+    {
+        unsigned long pagetype;
+
+        pagetype =3D buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK;
+        if ( pagetype =3D=3D XEN_DOMCTL_PFINFO_XTAB ||
+             pagetype =3D=3D XEN_DOMCTL_PFINFO_BROKEN ||
+             pagetype =3D=3D XEN_DOMCTL_PFINFO_XALLOC )
             --countpages;
+    }
=20
     if (!countpages)
         return count;
@@ -1200,6 +1206,17 @@
             /* a bogus/unmapped/allocate-only page: skip it */
             continue;
=20
+        if ( pagetype =3D=3D XEN_DOMCTL_PFINFO_BROKEN )
+        {
+            if ( xc_set_broken_page_p2m(xch, dom, pfn) )
+            {
+                ERROR("Set p2m for broken page failed, "
+                      "dom=3D%d, pfn=3D%lx\n", dom, pfn);
+                goto err_mapped;
+            }
+            continue;
+        }
+
         if (pfn_err[i])
         {
             ERROR("unexpected PFN mapping failure pfn %lx map_mfn %lx p2m_=
mfn %lx",
diff -r 199e829bf89c tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Tue Oct 30 21:26:56 2012 +0800
+++ b/tools/libxc/xc_domain_save.c	Thu Nov 01 00:36:38 2012 +0800
@@ -1277,6 +1277,13 @@
                 if ( !hvm )
                     gmfn =3D pfn_to_mfn(gmfn);
=20
+                if ( pfn_type[j] =3D=3D XEN_DOMCTL_PFINFO_BROKEN )
+                {
+                    pfn_type[j] |=3D pfn_batch[j];
+                    ++run;
+                    continue;
+                }
+
                 if ( pfn_err[j] )
                 {
                     if ( pfn_type[j] =3D=3D XEN_DOMCTL_PFINFO_XTAB )
@@ -1371,8 +1378,12 @@
                     }
                 }
=20
-                /* skip pages that aren't present or are alloc-only */
+                /*
+                 * skip pages that aren't present,
+                 * or are broken, or are alloc-only
+                 */
                 if ( pagetype =3D=3D XEN_DOMCTL_PFINFO_XTAB
+                    || pagetype =3D=3D XEN_DOMCTL_PFINFO_BROKEN
                     || pagetype =3D=3D XEN_DOMCTL_PFINFO_XALLOC )
                     continue;
=20
diff -r 199e829bf89c tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Tue Oct 30 21:26:56 2012 +0800
+++ b/tools/libxc/xenctrl.h	Thu Nov 01 00:36:38 2012 +0800
@@ -575,6 +575,17 @@
                           xc_domaininfo_t *info);
=20
 /**
+ * This function set p2m for broken page
+ * &parm xch a handle to an open hypervisor interface
+ * @parm domid the domain id which broken page belong to
+ * @parm pfn the pfn number of the broken page
+ * @return 0 on success, -1 on failure
+ */
+int xc_set_broken_page_p2m(xc_interface *xch,
+                           uint32_t domid,
+                           unsigned long pfn);
+
+/**
  * This function returns information about the context of a hvm domain
  * @parm xch a handle to an open hypervisor interface
  * @parm domid the domain to get information from
diff -r 199e829bf89c xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c	Tue Oct 30 21:26:56 2012 +0800
+++ b/xen/arch/x86/domctl.c	Thu Nov 01 00:36:38 2012 +0800
@@ -209,12 +209,18 @@
                 for ( j =3D 0; j < k; j++ )
                 {
                     unsigned long type =3D 0;
+                    p2m_type_t t;
=20
-                    page =3D get_page_from_gfn(d, arr[j], NULL, P2M_ALLOC)=
;
+                    page =3D get_page_from_gfn(d, arr[j], &t, P2M_ALLOC);
=20
                     if ( unlikely(!page) ||
                          unlikely(is_xen_heap_page(page)) )
-                        type =3D XEN_DOMCTL_PFINFO_XTAB;
+                    {
+                        if ( p2m_is_broken(t) )
+                            type =3D XEN_DOMCTL_PFINFO_BROKEN;
+                        else
+                            type =3D XEN_DOMCTL_PFINFO_XTAB;
+                    }
                     else
                     {
                         switch( page->u.inuse.type_info & PGT_type_mask )
@@ -235,6 +241,9 @@
=20
                         if ( page->u.inuse.type_info & PGT_pinned )
                             type |=3D XEN_DOMCTL_PFINFO_LPINTAB;
+
+                        if ( page->count_info & PGC_broken )
+                            type =3D XEN_DOMCTL_PFINFO_BROKEN;
                     }
=20
                     if ( page )
@@ -1568,6 +1577,38 @@
     }
     break;
=20
+    case XEN_DOMCTL_set_broken_page_p2m:
+    {
+        struct domain *d;
+        p2m_type_t pt;
+        unsigned long pfn;
+        mfn_t mfn;
+
+        d =3D rcu_lock_domain_by_id(domctl->domain);
+        if ( d !=3D NULL )
+        {
+            pfn =3D domctl->u.set_broken_page_p2m.pfn;
+
+            mfn =3D get_gfn_query(d, pfn, &pt);
+            if ( !mfn_valid(mfn_x(mfn)) || !p2m_is_ram(pt) )
+            {
+                put_gfn(d, pfn);
+                rcu_unlock_domain(d);
+                ret =3D -EINVAL;
+                break;
+            }
+
+            if ( p2m_change_type(d, pfn, pt, p2m_ram_broken) !=3D pt )
+                ret =3D -EINVAL;
+
+            put_gfn(d, pfn);
+            rcu_unlock_domain(d);
+        }
+        else
+            ret =3D -ESRCH;
+    }
+    break;
+
     default:
         ret =3D iommu_do_domctl(domctl, u_domctl);
         break;
diff -r 199e829bf89c xen/include/public/domctl.h
--- a/xen/include/public/domctl.h	Tue Oct 30 21:26:56 2012 +0800
+++ b/xen/include/public/domctl.h	Thu Nov 01 00:36:38 2012 +0800
@@ -136,6 +136,7 @@
 #define XEN_DOMCTL_PFINFO_LPINTAB (0x1U<<31)
 #define XEN_DOMCTL_PFINFO_XTAB    (0xfU<<28) /* invalid page */
 #define XEN_DOMCTL_PFINFO_XALLOC  (0xeU<<28) /* allocate-only page */
+#define XEN_DOMCTL_PFINFO_BROKEN  (0xdU<<28) /* broken page */
 #define XEN_DOMCTL_PFINFO_PAGEDTAB (0x8U<<28)
 #define XEN_DOMCTL_PFINFO_LTAB_MASK (0xfU<<28)
=20
@@ -835,6 +836,12 @@
 typedef struct xen_domctl_set_access_required xen_domctl_set_access_requir=
ed_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_access_required_t);
=20
+struct xen_domctl_set_broken_page_p2m {
+    uint64_aligned_t pfn;
+};
+typedef struct xen_domctl_set_broken_page_p2m xen_domctl_set_broken_page_p=
2m_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_broken_page_p2m_t);
+
 struct xen_domctl {
     uint32_t cmd;
 #define XEN_DOMCTL_createdomain                   1
@@ -900,6 +907,7 @@
 #define XEN_DOMCTL_set_access_required           64
 #define XEN_DOMCTL_audit_p2m                     65
 #define XEN_DOMCTL_set_virq_handler              66
+#define XEN_DOMCTL_set_broken_page_p2m           67
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -955,6 +963,7 @@
         struct xen_domctl_audit_p2m         audit_p2m;
         struct xen_domctl_set_virq_handler  set_virq_handler;
         struct xen_domctl_gdbsx_memio       gdbsx_guest_memio;
+        struct xen_domctl_set_broken_page_p2m set_broken_page_p2m;
         struct xen_domctl_gdbsx_pauseunp_vcpu gdbsx_pauseunp_vcpu;
         struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
         uint8_t                             pad[128];=

--_002_DE8DF0795D48FD4CA783C40EC829233537668DSHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="broken_page_occur_before_migration.patch"
Content-Description: broken_page_occur_before_migration.patch
Content-Disposition: attachment;
	filename="broken_page_occur_before_migration.patch"; size=8761;
	creation-date="Wed, 31 Oct 2012 10:08:53 GMT";
	modification-date="Wed, 31 Oct 2012 17:38:56 GMT"
Content-Transfer-Encoding: base64

SGFuZGxlcyBicm9rZW4gcGFnZSBvY2N1cnJlZCBiZWZvcmUgbWlncmF0aW9uCgpUaGlzIHBhdGNo
IGhhbmRsZXMgZ3Vlc3QgYnJva2VuIHBhZ2Ugd2hpY2ggb2NjdXJyZWQgYmVmb3JlIG1pZ3JhdGlv
bi4KCkF0IHNlbmRlciwgdGhlIGJyb2tlbiBwYWdlIHdvdWxkIGJlIG1hcHBlZCBidXQgbm90IGNv
cGllZCB0byB0YXJnZXQKKG90aGVyd2lzZSBpdCBtYXkgdHJpZ2dlciBtb3JlIHNlcmlvdXMgZXJy
b3IsIHNheSwgU1JBUiBlcnJvcikuCldoaWxlIGl0cyBwZm5fdHlwZSBhbmQgcGZuIG51bWJlciB3
b3VsZCBiZSB0cmFuc2ZlcnJlZCB0byB0YXJnZXQKc28gdGhhdCB0YXJnZXQgdGFrZSBhcHByb3By
aWF0ZSBhY3Rpb24uCgpBdCB0YXJnZXQsIGl0IHdvdWxkIHNldCBwMm0gYXMgcDJtX3JhbV9icm9r
ZW4gZm9yIGJyb2tlbiBwYWdlLCBzbyB0aGF0CmlmIGd1ZXN0IGFjY2VzcyB0aGUgYnJva2VuIHBh
Z2UgYWdhaW4sIGl0IHdvdWxkIGtpbGwgaXRzZWxmIGFzIGV4cGVjdGVkLgoKU2lnbmVkLW9mZi1i
eTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+CgpkaWZmIC1yIDE5OWU4Mjli
Zjg5YyB0b29scy9saWJ4Yy94Y19kb21haW4uYwotLS0gYS90b29scy9saWJ4Yy94Y19kb21haW4u
YwlUdWUgT2N0IDMwIDIxOjI2OjU2IDIwMTIgKzA4MDAKKysrIGIvdG9vbHMvbGlieGMveGNfZG9t
YWluLmMJVGh1IE5vdiAwMSAwMDozNjozOCAyMDEyICswODAwCkBAIC0yODMsNiArMjgzLDIyIEBA
CiAgICAgcmV0dXJuIHJldDsKIH0KIAorLyogc2V0IGJyb2tlbiBwYWdlIHAybSAqLworaW50IHhj
X3NldF9icm9rZW5fcGFnZV9wMm0oeGNfaW50ZXJmYWNlICp4Y2gsCisgICAgICAgICAgICAgICAg
ICAgICAgICAgICB1aW50MzJfdCBkb21pZCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgIHVu
c2lnbmVkIGxvbmcgcGZuKQoreworICAgIGludCByZXQ7CisgICAgREVDTEFSRV9ET01DVEw7CisK
KyAgICBkb21jdGwuY21kID0gWEVOX0RPTUNUTF9zZXRfYnJva2VuX3BhZ2VfcDJtOworICAgIGRv
bWN0bC5kb21haW4gPSAoZG9taWRfdClkb21pZDsKKyAgICBkb21jdGwudS5zZXRfYnJva2VuX3Bh
Z2VfcDJtLnBmbiA9IHBmbjsKKyAgICByZXQgPSBkb19kb21jdGwoeGNoLCAmZG9tY3RsKTsKKwor
ICAgIHJldHVybiByZXQgPyAtMSA6IDA7Cit9CisKIC8qIGdldCBpbmZvIGZyb20gaHZtIGd1ZXN0
IGZvciBzYXZlICovCiBpbnQgeGNfZG9tYWluX2h2bV9nZXRjb250ZXh0KHhjX2ludGVyZmFjZSAq
eGNoLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJfdCBkb21pZCwKZGlmZiAt
ciAxOTllODI5YmY4OWMgdG9vbHMvbGlieGMveGNfZG9tYWluX3Jlc3RvcmUuYwotLS0gYS90b29s
cy9saWJ4Yy94Y19kb21haW5fcmVzdG9yZS5jCVR1ZSBPY3QgMzAgMjE6MjY6NTYgMjAxMiArMDgw
MAorKysgYi90b29scy9saWJ4Yy94Y19kb21haW5fcmVzdG9yZS5jCVRodSBOb3YgMDEgMDA6MzY6
MzggMjAxMiArMDgwMApAQCAtOTYyLDkgKzk2MiwxNSBAQAogCiAgICAgY291bnRwYWdlcyA9IGNv
dW50OwogICAgIGZvciAoaSA9IG9sZGNvdW50OyBpIDwgYnVmLT5ucl9wYWdlczsgKytpKQotICAg
ICAgICBpZiAoKGJ1Zi0+cGZuX3R5cGVzW2ldICYgWEVOX0RPTUNUTF9QRklORk9fTFRBQl9NQVNL
KSA9PSBYRU5fRE9NQ1RMX1BGSU5GT19YVEFCCi0gICAgICAgICAgICB8fChidWYtPnBmbl90eXBl
c1tpXSAmIFhFTl9ET01DVExfUEZJTkZPX0xUQUJfTUFTSykgPT0gWEVOX0RPTUNUTF9QRklORk9f
WEFMTE9DKQorICAgIHsKKyAgICAgICAgdW5zaWduZWQgbG9uZyBwYWdldHlwZTsKKworICAgICAg
ICBwYWdldHlwZSA9IGJ1Zi0+cGZuX3R5cGVzW2ldICYgWEVOX0RPTUNUTF9QRklORk9fTFRBQl9N
QVNLOworICAgICAgICBpZiAoIHBhZ2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX1hUQUIgfHwK
KyAgICAgICAgICAgICBwYWdldHlwZSA9PSBYRU5fRE9NQ1RMX1BGSU5GT19CUk9LRU4gfHwKKyAg
ICAgICAgICAgICBwYWdldHlwZSA9PSBYRU5fRE9NQ1RMX1BGSU5GT19YQUxMT0MgKQogICAgICAg
ICAgICAgLS1jb3VudHBhZ2VzOworICAgIH0KIAogICAgIGlmICghY291bnRwYWdlcykKICAgICAg
ICAgcmV0dXJuIGNvdW50OwpAQCAtMTIwMCw2ICsxMjA2LDE3IEBACiAgICAgICAgICAgICAvKiBh
IGJvZ3VzL3VubWFwcGVkL2FsbG9jYXRlLW9ubHkgcGFnZTogc2tpcCBpdCAqLwogICAgICAgICAg
ICAgY29udGludWU7CiAKKyAgICAgICAgaWYgKCBwYWdldHlwZSA9PSBYRU5fRE9NQ1RMX1BGSU5G
T19CUk9LRU4gKQorICAgICAgICB7CisgICAgICAgICAgICBpZiAoIHhjX3NldF9icm9rZW5fcGFn
ZV9wMm0oeGNoLCBkb20sIHBmbikgKQorICAgICAgICAgICAgeworICAgICAgICAgICAgICAgIEVS
Uk9SKCJTZXQgcDJtIGZvciBicm9rZW4gcGFnZSBmYWlsZWQsICIKKyAgICAgICAgICAgICAgICAg
ICAgICAiZG9tPSVkLCBwZm49JWx4XG4iLCBkb20sIHBmbik7CisgICAgICAgICAgICAgICAgZ290
byBlcnJfbWFwcGVkOworICAgICAgICAgICAgfQorICAgICAgICAgICAgY29udGludWU7CisgICAg
ICAgIH0KKwogICAgICAgICBpZiAocGZuX2VycltpXSkKICAgICAgICAgewogICAgICAgICAgICAg
RVJST1IoInVuZXhwZWN0ZWQgUEZOIG1hcHBpbmcgZmFpbHVyZSBwZm4gJWx4IG1hcF9tZm4gJWx4
IHAybV9tZm4gJWx4IiwKZGlmZiAtciAxOTllODI5YmY4OWMgdG9vbHMvbGlieGMveGNfZG9tYWlu
X3NhdmUuYwotLS0gYS90b29scy9saWJ4Yy94Y19kb21haW5fc2F2ZS5jCVR1ZSBPY3QgMzAgMjE6
MjY6NTYgMjAxMiArMDgwMAorKysgYi90b29scy9saWJ4Yy94Y19kb21haW5fc2F2ZS5jCVRodSBO
b3YgMDEgMDA6MzY6MzggMjAxMiArMDgwMApAQCAtMTI3Nyw2ICsxMjc3LDEzIEBACiAgICAgICAg
ICAgICAgICAgaWYgKCAhaHZtICkKICAgICAgICAgICAgICAgICAgICAgZ21mbiA9IHBmbl90b19t
Zm4oZ21mbik7CiAKKyAgICAgICAgICAgICAgICBpZiAoIHBmbl90eXBlW2pdID09IFhFTl9ET01D
VExfUEZJTkZPX0JST0tFTiApCisgICAgICAgICAgICAgICAgeworICAgICAgICAgICAgICAgICAg
ICBwZm5fdHlwZVtqXSB8PSBwZm5fYmF0Y2hbal07CisgICAgICAgICAgICAgICAgICAgICsrcnVu
OworICAgICAgICAgICAgICAgICAgICBjb250aW51ZTsKKyAgICAgICAgICAgICAgICB9CisKICAg
ICAgICAgICAgICAgICBpZiAoIHBmbl9lcnJbal0gKQogICAgICAgICAgICAgICAgIHsKICAgICAg
ICAgICAgICAgICAgICAgaWYgKCBwZm5fdHlwZVtqXSA9PSBYRU5fRE9NQ1RMX1BGSU5GT19YVEFC
ICkKQEAgLTEzNzEsOCArMTM3OCwxMiBAQAogICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAg
ICAgICAgICAgfQogCi0gICAgICAgICAgICAgICAgLyogc2tpcCBwYWdlcyB0aGF0IGFyZW4ndCBw
cmVzZW50IG9yIGFyZSBhbGxvYy1vbmx5ICovCisgICAgICAgICAgICAgICAgLyoKKyAgICAgICAg
ICAgICAgICAgKiBza2lwIHBhZ2VzIHRoYXQgYXJlbid0IHByZXNlbnQsCisgICAgICAgICAgICAg
ICAgICogb3IgYXJlIGJyb2tlbiwgb3IgYXJlIGFsbG9jLW9ubHkKKyAgICAgICAgICAgICAgICAg
Ki8KICAgICAgICAgICAgICAgICBpZiAoIHBhZ2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX1hU
QUIKKyAgICAgICAgICAgICAgICAgICAgfHwgcGFnZXR5cGUgPT0gWEVOX0RPTUNUTF9QRklORk9f
QlJPS0VOCiAgICAgICAgICAgICAgICAgICAgIHx8IHBhZ2V0eXBlID09IFhFTl9ET01DVExfUEZJ
TkZPX1hBTExPQyApCiAgICAgICAgICAgICAgICAgICAgIGNvbnRpbnVlOwogCmRpZmYgLXIgMTk5
ZTgyOWJmODljIHRvb2xzL2xpYnhjL3hlbmN0cmwuaAotLS0gYS90b29scy9saWJ4Yy94ZW5jdHJs
LmgJVHVlIE9jdCAzMCAyMToyNjo1NiAyMDEyICswODAwCisrKyBiL3Rvb2xzL2xpYnhjL3hlbmN0
cmwuaAlUaHUgTm92IDAxIDAwOjM2OjM4IDIwMTIgKzA4MDAKQEAgLTU3NSw2ICs1NzUsMTcgQEAK
ICAgICAgICAgICAgICAgICAgICAgICAgICAgeGNfZG9tYWluaW5mb190ICppbmZvKTsKIAogLyoq
CisgKiBUaGlzIGZ1bmN0aW9uIHNldCBwMm0gZm9yIGJyb2tlbiBwYWdlCisgKiAmcGFybSB4Y2gg
YSBoYW5kbGUgdG8gYW4gb3BlbiBoeXBlcnZpc29yIGludGVyZmFjZQorICogQHBhcm0gZG9taWQg
dGhlIGRvbWFpbiBpZCB3aGljaCBicm9rZW4gcGFnZSBiZWxvbmcgdG8KKyAqIEBwYXJtIHBmbiB0
aGUgcGZuIG51bWJlciBvZiB0aGUgYnJva2VuIHBhZ2UKKyAqIEByZXR1cm4gMCBvbiBzdWNjZXNz
LCAtMSBvbiBmYWlsdXJlCisgKi8KK2ludCB4Y19zZXRfYnJva2VuX3BhZ2VfcDJtKHhjX2ludGVy
ZmFjZSAqeGNoLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZG9taWQsCisg
ICAgICAgICAgICAgICAgICAgICAgICAgICB1bnNpZ25lZCBsb25nIHBmbik7CisKKy8qKgogICog
VGhpcyBmdW5jdGlvbiByZXR1cm5zIGluZm9ybWF0aW9uIGFib3V0IHRoZSBjb250ZXh0IG9mIGEg
aHZtIGRvbWFpbgogICogQHBhcm0geGNoIGEgaGFuZGxlIHRvIGFuIG9wZW4gaHlwZXJ2aXNvciBp
bnRlcmZhY2UKICAqIEBwYXJtIGRvbWlkIHRoZSBkb21haW4gdG8gZ2V0IGluZm9ybWF0aW9uIGZy
b20KZGlmZiAtciAxOTllODI5YmY4OWMgeGVuL2FyY2gveDg2L2RvbWN0bC5jCi0tLSBhL3hlbi9h
cmNoL3g4Ni9kb21jdGwuYwlUdWUgT2N0IDMwIDIxOjI2OjU2IDIwMTIgKzA4MDAKKysrIGIveGVu
L2FyY2gveDg2L2RvbWN0bC5jCVRodSBOb3YgMDEgMDA6MzY6MzggMjAxMiArMDgwMApAQCAtMjA5
LDEyICsyMDksMTggQEAKICAgICAgICAgICAgICAgICBmb3IgKCBqID0gMDsgaiA8IGs7IGorKyAp
CiAgICAgICAgICAgICAgICAgewogICAgICAgICAgICAgICAgICAgICB1bnNpZ25lZCBsb25nIHR5
cGUgPSAwOworICAgICAgICAgICAgICAgICAgICBwMm1fdHlwZV90IHQ7CiAKLSAgICAgICAgICAg
ICAgICAgICAgcGFnZSA9IGdldF9wYWdlX2Zyb21fZ2ZuKGQsIGFycltqXSwgTlVMTCwgUDJNX0FM
TE9DKTsKKyAgICAgICAgICAgICAgICAgICAgcGFnZSA9IGdldF9wYWdlX2Zyb21fZ2ZuKGQsIGFy
cltqXSwgJnQsIFAyTV9BTExPQyk7CiAKICAgICAgICAgICAgICAgICAgICAgaWYgKCB1bmxpa2Vs
eSghcGFnZSkgfHwKICAgICAgICAgICAgICAgICAgICAgICAgICB1bmxpa2VseShpc194ZW5faGVh
cF9wYWdlKHBhZ2UpKSApCi0gICAgICAgICAgICAgICAgICAgICAgICB0eXBlID0gWEVOX0RPTUNU
TF9QRklORk9fWFRBQjsKKyAgICAgICAgICAgICAgICAgICAgeworICAgICAgICAgICAgICAgICAg
ICAgICAgaWYgKCBwMm1faXNfYnJva2VuKHQpICkKKyAgICAgICAgICAgICAgICAgICAgICAgICAg
ICB0eXBlID0gWEVOX0RPTUNUTF9QRklORk9fQlJPS0VOOworICAgICAgICAgICAgICAgICAgICAg
ICAgZWxzZQorICAgICAgICAgICAgICAgICAgICAgICAgICAgIHR5cGUgPSBYRU5fRE9NQ1RMX1BG
SU5GT19YVEFCOworICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAgICAgIGVs
c2UKICAgICAgICAgICAgICAgICAgICAgewogICAgICAgICAgICAgICAgICAgICAgICAgc3dpdGNo
KCBwYWdlLT51LmludXNlLnR5cGVfaW5mbyAmIFBHVF90eXBlX21hc2sgKQpAQCAtMjM1LDYgKzI0
MSw5IEBACiAKICAgICAgICAgICAgICAgICAgICAgICAgIGlmICggcGFnZS0+dS5pbnVzZS50eXBl
X2luZm8gJiBQR1RfcGlubmVkICkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0eXBlIHw9
IFhFTl9ET01DVExfUEZJTkZPX0xQSU5UQUI7CisKKyAgICAgICAgICAgICAgICAgICAgICAgIGlm
ICggcGFnZS0+Y291bnRfaW5mbyAmIFBHQ19icm9rZW4gKQorICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHR5cGUgPSBYRU5fRE9NQ1RMX1BGSU5GT19CUk9LRU47CiAgICAgICAgICAgICAgICAg
ICAgIH0KIAogICAgICAgICAgICAgICAgICAgICBpZiAoIHBhZ2UgKQpAQCAtMTU2OCw2ICsxNTc3
LDM4IEBACiAgICAgfQogICAgIGJyZWFrOwogCisgICAgY2FzZSBYRU5fRE9NQ1RMX3NldF9icm9r
ZW5fcGFnZV9wMm06CisgICAgeworICAgICAgICBzdHJ1Y3QgZG9tYWluICpkOworICAgICAgICBw
Mm1fdHlwZV90IHB0OworICAgICAgICB1bnNpZ25lZCBsb25nIHBmbjsKKyAgICAgICAgbWZuX3Qg
bWZuOworCisgICAgICAgIGQgPSByY3VfbG9ja19kb21haW5fYnlfaWQoZG9tY3RsLT5kb21haW4p
OworICAgICAgICBpZiAoIGQgIT0gTlVMTCApCisgICAgICAgIHsKKyAgICAgICAgICAgIHBmbiA9
IGRvbWN0bC0+dS5zZXRfYnJva2VuX3BhZ2VfcDJtLnBmbjsKKworICAgICAgICAgICAgbWZuID0g
Z2V0X2dmbl9xdWVyeShkLCBwZm4sICZwdCk7CisgICAgICAgICAgICBpZiAoICFtZm5fdmFsaWQo
bWZuX3gobWZuKSkgfHwgIXAybV9pc19yYW0ocHQpICkKKyAgICAgICAgICAgIHsKKyAgICAgICAg
ICAgICAgICBwdXRfZ2ZuKGQsIHBmbik7CisgICAgICAgICAgICAgICAgcmN1X3VubG9ja19kb21h
aW4oZCk7CisgICAgICAgICAgICAgICAgcmV0ID0gLUVJTlZBTDsKKyAgICAgICAgICAgICAgICBi
cmVhazsKKyAgICAgICAgICAgIH0KKworICAgICAgICAgICAgaWYgKCBwMm1fY2hhbmdlX3R5cGUo
ZCwgcGZuLCBwdCwgcDJtX3JhbV9icm9rZW4pICE9IHB0ICkKKyAgICAgICAgICAgICAgICByZXQg
PSAtRUlOVkFMOworCisgICAgICAgICAgICBwdXRfZ2ZuKGQsIHBmbik7CisgICAgICAgICAgICBy
Y3VfdW5sb2NrX2RvbWFpbihkKTsKKyAgICAgICAgfQorICAgICAgICBlbHNlCisgICAgICAgICAg
ICByZXQgPSAtRVNSQ0g7CisgICAgfQorICAgIGJyZWFrOworCiAgICAgZGVmYXVsdDoKICAgICAg
ICAgcmV0ID0gaW9tbXVfZG9fZG9tY3RsKGRvbWN0bCwgdV9kb21jdGwpOwogICAgICAgICBicmVh
azsKZGlmZiAtciAxOTllODI5YmY4OWMgeGVuL2luY2x1ZGUvcHVibGljL2RvbWN0bC5oCi0tLSBh
L3hlbi9pbmNsdWRlL3B1YmxpYy9kb21jdGwuaAlUdWUgT2N0IDMwIDIxOjI2OjU2IDIwMTIgKzA4
MDAKKysrIGIveGVuL2luY2x1ZGUvcHVibGljL2RvbWN0bC5oCVRodSBOb3YgMDEgMDA6MzY6Mzgg
MjAxMiArMDgwMApAQCAtMTM2LDYgKzEzNiw3IEBACiAjZGVmaW5lIFhFTl9ET01DVExfUEZJTkZP
X0xQSU5UQUIgKDB4MVU8PDMxKQogI2RlZmluZSBYRU5fRE9NQ1RMX1BGSU5GT19YVEFCICAgICgw
eGZVPDwyOCkgLyogaW52YWxpZCBwYWdlICovCiAjZGVmaW5lIFhFTl9ET01DVExfUEZJTkZPX1hB
TExPQyAgKDB4ZVU8PDI4KSAvKiBhbGxvY2F0ZS1vbmx5IHBhZ2UgKi8KKyNkZWZpbmUgWEVOX0RP
TUNUTF9QRklORk9fQlJPS0VOICAoMHhkVTw8MjgpIC8qIGJyb2tlbiBwYWdlICovCiAjZGVmaW5l
IFhFTl9ET01DVExfUEZJTkZPX1BBR0VEVEFCICgweDhVPDwyOCkKICNkZWZpbmUgWEVOX0RPTUNU
TF9QRklORk9fTFRBQl9NQVNLICgweGZVPDwyOCkKIApAQCAtODM1LDYgKzgzNiwxMiBAQAogdHlw
ZWRlZiBzdHJ1Y3QgeGVuX2RvbWN0bF9zZXRfYWNjZXNzX3JlcXVpcmVkIHhlbl9kb21jdGxfc2V0
X2FjY2Vzc19yZXF1aXJlZF90OwogREVGSU5FX1hFTl9HVUVTVF9IQU5ETEUoeGVuX2RvbWN0bF9z
ZXRfYWNjZXNzX3JlcXVpcmVkX3QpOwogCitzdHJ1Y3QgeGVuX2RvbWN0bF9zZXRfYnJva2VuX3Bh
Z2VfcDJtIHsKKyAgICB1aW50NjRfYWxpZ25lZF90IHBmbjsKK307Cit0eXBlZGVmIHN0cnVjdCB4
ZW5fZG9tY3RsX3NldF9icm9rZW5fcGFnZV9wMm0geGVuX2RvbWN0bF9zZXRfYnJva2VuX3BhZ2Vf
cDJtX3Q7CitERUZJTkVfWEVOX0dVRVNUX0hBTkRMRSh4ZW5fZG9tY3RsX3NldF9icm9rZW5fcGFn
ZV9wMm1fdCk7CisKIHN0cnVjdCB4ZW5fZG9tY3RsIHsKICAgICB1aW50MzJfdCBjbWQ7CiAjZGVm
aW5lIFhFTl9ET01DVExfY3JlYXRlZG9tYWluICAgICAgICAgICAgICAgICAgIDEKQEAgLTkwMCw2
ICs5MDcsNyBAQAogI2RlZmluZSBYRU5fRE9NQ1RMX3NldF9hY2Nlc3NfcmVxdWlyZWQgICAgICAg
ICAgIDY0CiAjZGVmaW5lIFhFTl9ET01DVExfYXVkaXRfcDJtICAgICAgICAgICAgICAgICAgICAg
NjUKICNkZWZpbmUgWEVOX0RPTUNUTF9zZXRfdmlycV9oYW5kbGVyICAgICAgICAgICAgICA2Ngor
I2RlZmluZSBYRU5fRE9NQ1RMX3NldF9icm9rZW5fcGFnZV9wMm0gICAgICAgICAgIDY3CiAjZGVm
aW5lIFhFTl9ET01DVExfZ2Ric3hfZ3Vlc3RtZW1pbyAgICAgICAgICAgIDEwMDAKICNkZWZpbmUg
WEVOX0RPTUNUTF9nZGJzeF9wYXVzZXZjcHUgICAgICAgICAgICAgMTAwMQogI2RlZmluZSBYRU5f
RE9NQ1RMX2dkYnN4X3VucGF1c2V2Y3B1ICAgICAgICAgICAxMDAyCkBAIC05NTUsNiArOTYzLDcg
QEAKICAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfYXVkaXRfcDJtICAgICAgICAgYXVkaXRfcDJt
OwogICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF9zZXRfdmlycV9oYW5kbGVyICBzZXRfdmlycV9o
YW5kbGVyOwogICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF9nZGJzeF9tZW1pbyAgICAgICBnZGJz
eF9ndWVzdF9tZW1pbzsKKyAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfc2V0X2Jyb2tlbl9wYWdl
X3AybSBzZXRfYnJva2VuX3BhZ2VfcDJtOwogICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF9nZGJz
eF9wYXVzZXVucF92Y3B1IGdkYnN4X3BhdXNldW5wX3ZjcHU7CiAgICAgICAgIHN0cnVjdCB4ZW5f
ZG9tY3RsX2dkYnN4X2RvbXN0YXR1cyAgIGdkYnN4X2RvbXN0YXR1czsKICAgICAgICAgdWludDhf
dCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcGFkWzEyOF07Cg==

--_002_DE8DF0795D48FD4CA783C40EC829233537668DSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC829233537668DSHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Wed Oct 31 11:21:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 11:21:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTWMJ-00009m-3h; Wed, 31 Oct 2012 11:21:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTWMH-00009Q-NP
	for xen-devel@lists.xensource.com; Wed, 31 Oct 2012 11:21:18 +0000
Received: from [85.158.143.35:52936] by server-2.bemta-4.messagelabs.com id
	C2/1B-28922-CA901905; Wed, 31 Oct 2012 11:21:16 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1351682472!15799848!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjI1NTQy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17603 invoked from network); 31 Oct 2012 11:21:14 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-6.tower-21.messagelabs.com with SMTP;
	31 Oct 2012 11:21:14 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 31 Oct 2012 04:21:11 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,687,1344236400"; d="scan'208";a="211689927"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by azsmga001.ch.intel.com with ESMTP; 31 Oct 2012 04:21:10 -0700
Received: from fmsmsx101.amr.corp.intel.com (10.19.9.52) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 31 Oct 2012 04:21:10 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX101.amr.corp.intel.com (10.19.9.52) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 31 Oct 2012 04:21:10 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.186]) with mapi id
	14.01.0355.002; Wed, 31 Oct 2012 19:21:08 +0800
From: "Liu, Jinsong" 
To: George Dunlap , Ian Jackson
	, Jan Beulich 
Thread-Topic: [PATCH 02/02] Handles broken page occurred during migration
Thread-Index: Ac23WdJ0ST9jWMNZSlWheBhAdddc/Q==
Date: Wed, 31 Oct 2012 11:21:07 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC82923353766A5SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: [Xen-devel] [PATCH 02/02] Handles broken page occurred during
	migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC82923353766A5SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Handles broken page occurred during migration

This patch handles broken page which occurred during migration.

It monitors the critical area of live migration (from vMCE point of view,
the copypages stage of migration is the critical area while other areas are=
 not).

If a vMCE occur at the critical area of live migration, it marks the broken=
 page
to dirty map, so that at copypages stage of migration, its pfn_type
and pfn number would transfer to target and then take appropriate action.

At target, it would set p2m as p2m_ram_broken for broken page, so that if
guest access the broken page again, it would kill itself as expected.

Suggested-by: George Dunlap 
Signed-off-by: Liu, Jinsong 

diff -r 3313ee9f6142 tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c	Thu Oct 25 05:49:11 2012 +0800
+++ b/tools/libxc/xc_domain.c	Tue Oct 30 06:07:05 2012 +0800
@@ -299,6 +299,24 @@
     return ret ? -1 : 0;
 }
=20
+/* start/end vmce monitor */
+int xc_domain_vmce_monitor(xc_interface *xch,
+                           uint32_t domid,
+                           uint32_t start)
+{
+    int ret;
+    DECLARE_DOMCTL;
+
+    if ( start )
+        domctl.cmd =3D XEN_DOMCTL_vmce_monitor_start;
+    else
+        domctl.cmd =3D XEN_DOMCTL_vmce_monitor_end;
+    domctl.domain =3D (domid_t)domid;
+    ret =3D do_domctl(xch, &domctl);
+
+    return ret ? -1 : 0;
+}
+
 /* get info from hvm guest for save */
 int xc_domain_hvm_getcontext(xc_interface *xch,
                              uint32_t domid,
diff -r 3313ee9f6142 tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Thu Oct 25 05:49:11 2012 +0800
+++ b/tools/libxc/xc_domain_save.c	Tue Oct 30 06:07:05 2012 +0800
@@ -1109,6 +1109,13 @@
         goto out;
     }
=20
+    /* Start vmce monitor */
+    if ( xc_domain_vmce_monitor(xch, dom, 1) )
+    {
+        PERROR("Error starting vmce monitor");
+        goto out;
+    }
+
   copypages:
 #define wrexact(fd, buf, len) write_buffer(xch, last_iter, ob, (fd), (buf)=
, (len))
 #define wruncached(fd, live, buf, len) write_uncached(xch, last_iter, ob, =
(fd), (buf), (len))
@@ -1582,6 +1589,13 @@
=20
     DPRINTF("All memory is saved\n");
=20
+    /* End vmce monitor */
+    if ( xc_domain_vmce_monitor(xch, dom, 0) )
+    {
+        PERROR("Error ending vmce monitor");
+        goto out;
+    }
+
     /* After last_iter, buffer the rest of pagebuf & tailbuf data into a
      * separate output buffer and flush it after the compressed page chunk=
s.
      */
diff -r 3313ee9f6142 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Thu Oct 25 05:49:11 2012 +0800
+++ b/tools/libxc/xenctrl.h	Tue Oct 30 06:07:05 2012 +0800
@@ -586,6 +586,17 @@
                            unsigned long pfn);
=20
 /**
+ * This function start/end monitor vmce event.
+ * @parm xch a handle to an open hypervisor interface
+ * @parm domid the domain id monitored
+ * @parm flag to start/end monitor
+ * @return <0 on failure, 0 on success
+ */
+int xc_domain_vmce_monitor(xc_interface *xch,
+                           uint32_t domid,
+                           uint32_t start);
+
+/**
  * This function returns information about the context of a hvm domain
  * @parm xch a handle to an open hypervisor interface
  * @parm domid the domain to get information from
diff -r 3313ee9f6142 xen/arch/x86/cpu/mcheck/mce_intel.c
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c	Thu Oct 25 05:49:11 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c	Tue Oct 30 06:07:05 2012 +0800
@@ -342,6 +342,22 @@
                     goto vmce_failed;
                 }
=20
+                if ( unlikely(d->arch.vmce_monitor) )
+                {
+                    /*
+                     * vMCE occur during migration
+                     *
+                     * mark broken page to dirty bitmap, so that at copypa=
ges
+                     * stage of migration, its pfn_type and pfn number wou=
ld
+                     * transfer to target and then take appropriate action
+                     *
+                     * At target, it would set p2m as p2m_ram_broken for b=
roken
+                     * page, so that if guest access the broken page again=
, it
+                     * would kill itself as expected.
+                     */
+                    paging_mark_dirty(d, mfn);
+                }
+
                 if ( unmmap_broken_page(d, _mfn(mfn), gfn) )
                 {
                     printk("Unmap broken memory %lx for DOM%d failed\n",
diff -r 3313ee9f6142 xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c	Thu Oct 25 05:49:11 2012 +0800
+++ b/xen/arch/x86/domctl.c	Tue Oct 30 06:07:05 2012 +0800
@@ -1599,6 +1599,44 @@
     }
     break;
=20
+    case XEN_DOMCTL_vmce_monitor_start:
+    {
+        struct domain *d;
+
+        d =3D rcu_lock_domain_by_id(domctl->domain);
+        if ( d !=3D NULL )
+        {
+            if ( d->arch.vmce_monitor )
+                ret =3D -EBUSY;
+            else
+                d->arch.vmce_monitor =3D 1;
+
+            rcu_unlock_domain(d);
+        }
+        else
+            ret =3D -ESRCH;
+    }
+    break;
+
+    case XEN_DOMCTL_vmce_monitor_end:
+    {
+        struct domain *d;
+
+        d =3D rcu_lock_domain_by_id(domctl->domain);
+        if ( d !=3D NULL)
+        {
+            if ( !d->arch.vmce_monitor )
+                ret =3D -EINVAL;
+            else
+                d->arch.vmce_monitor =3D 0;
+
+            rcu_unlock_domain(d);
+        }
+        else
+            ret =3D -ESRCH;
+    }
+    break;
+
     default:
         ret =3D iommu_do_domctl(domctl, u_domctl);
         break;
diff -r 3313ee9f6142 xen/include/asm-x86/domain.h
--- a/xen/include/asm-x86/domain.h	Thu Oct 25 05:49:11 2012 +0800
+++ b/xen/include/asm-x86/domain.h	Tue Oct 30 06:07:05 2012 +0800
@@ -279,6 +279,10 @@
     bool_t has_32bit_shinfo;
     /* Domain cannot handle spurious page faults? */
     bool_t suppress_spurious_page_faults;
+    /* Monitoring guest memory copy of migration
+     * =3D 0 - not monitoring
+     * =3D 1 - monitoring */
+    bool_t vmce_monitor;
=20
     /* Continuable domain_relinquish_resources(). */
     enum {
diff -r 3313ee9f6142 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h	Thu Oct 25 05:49:11 2012 +0800
+++ b/xen/include/public/domctl.h	Tue Oct 30 06:07:05 2012 +0800
@@ -908,6 +908,8 @@
 #define XEN_DOMCTL_audit_p2m                     65
 #define XEN_DOMCTL_set_virq_handler              66
 #define XEN_DOMCTL_set_broken_page_p2m           67
+#define XEN_DOMCTL_vmce_monitor_start            68
+#define XEN_DOMCTL_vmce_monitor_end              69
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002=

--_002_DE8DF0795D48FD4CA783C40EC82923353766A5SHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="broken_page_occur_during_migration.patch"
Content-Description: broken_page_occur_during_migration.patch
Content-Disposition: attachment;
	filename="broken_page_occur_during_migration.patch"; size=6735;
	creation-date="Wed, 31 Oct 2012 10:08:53 GMT";
	modification-date="Wed, 31 Oct 2012 17:39:42 GMT"
Content-Transfer-Encoding: base64

SGFuZGxlcyBicm9rZW4gcGFnZSBvY2N1cnJlZCBkdXJpbmcgbWlncmF0aW9uCgpUaGlzIHBhdGNo
IGhhbmRsZXMgYnJva2VuIHBhZ2Ugd2hpY2ggb2NjdXJyZWQgZHVyaW5nIG1pZ3JhdGlvbi4KCkl0
IG1vbml0b3JzIHRoZSBjcml0aWNhbCBhcmVhIG9mIGxpdmUgbWlncmF0aW9uIChmcm9tIHZNQ0Ug
cG9pbnQgb2YgdmlldywKdGhlIGNvcHlwYWdlcyBzdGFnZSBvZiBtaWdyYXRpb24gaXMgdGhlIGNy
aXRpY2FsIGFyZWEgd2hpbGUgb3RoZXIgYXJlYXMgYXJlIG5vdCkuCgpJZiBhIHZNQ0Ugb2NjdXIg
YXQgdGhlIGNyaXRpY2FsIGFyZWEgb2YgbGl2ZSBtaWdyYXRpb24sIGl0IG1hcmtzIHRoZSBicm9r
ZW4gcGFnZQp0byBkaXJ0eSBtYXAsIHNvIHRoYXQgYXQgY29weXBhZ2VzIHN0YWdlIG9mIG1pZ3Jh
dGlvbiwgaXRzIHBmbl90eXBlCmFuZCBwZm4gbnVtYmVyIHdvdWxkIHRyYW5zZmVyIHRvIHRhcmdl
dCBhbmQgdGhlbiB0YWtlIGFwcHJvcHJpYXRlIGFjdGlvbi4KCkF0IHRhcmdldCwgaXQgd291bGQg
c2V0IHAybSBhcyBwMm1fcmFtX2Jyb2tlbiBmb3IgYnJva2VuIHBhZ2UsIHNvIHRoYXQgaWYKZ3Vl
c3QgYWNjZXNzIHRoZSBicm9rZW4gcGFnZSBhZ2FpbiwgaXQgd291bGQga2lsbCBpdHNlbGYgYXMg
ZXhwZWN0ZWQuCgpTdWdnZXN0ZWQtYnk6IEdlb3JnZSBEdW5sYXAgPGdlb3JnZS5kdW5sYXBAZXUu
Y2l0cml4LmNvbT4KU2lnbmVkLW9mZi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRl
bC5jb20+CgpkaWZmIC1yIDMzMTNlZTlmNjE0MiB0b29scy9saWJ4Yy94Y19kb21haW4uYwotLS0g
YS90b29scy9saWJ4Yy94Y19kb21haW4uYwlUaHUgT2N0IDI1IDA1OjQ5OjExIDIwMTIgKzA4MDAK
KysrIGIvdG9vbHMvbGlieGMveGNfZG9tYWluLmMJVHVlIE9jdCAzMCAwNjowNzowNSAyMDEyICsw
ODAwCkBAIC0yOTksNiArMjk5LDI0IEBACiAgICAgcmV0dXJuIHJldCA/IC0xIDogMDsKIH0KIAor
Lyogc3RhcnQvZW5kIHZtY2UgbW9uaXRvciAqLworaW50IHhjX2RvbWFpbl92bWNlX21vbml0b3Io
eGNfaW50ZXJmYWNlICp4Y2gsCisgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJfdCBk
b21pZCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IHN0YXJ0KQoreworICAg
IGludCByZXQ7CisgICAgREVDTEFSRV9ET01DVEw7CisKKyAgICBpZiAoIHN0YXJ0ICkKKyAgICAg
ICAgZG9tY3RsLmNtZCA9IFhFTl9ET01DVExfdm1jZV9tb25pdG9yX3N0YXJ0OworICAgIGVsc2UK
KyAgICAgICAgZG9tY3RsLmNtZCA9IFhFTl9ET01DVExfdm1jZV9tb25pdG9yX2VuZDsKKyAgICBk
b21jdGwuZG9tYWluID0gKGRvbWlkX3QpZG9taWQ7CisgICAgcmV0ID0gZG9fZG9tY3RsKHhjaCwg
JmRvbWN0bCk7CisKKyAgICByZXR1cm4gcmV0ID8gLTEgOiAwOworfQorCiAvKiBnZXQgaW5mbyBm
cm9tIGh2bSBndWVzdCBmb3Igc2F2ZSAqLwogaW50IHhjX2RvbWFpbl9odm1fZ2V0Y29udGV4dCh4
Y19pbnRlcmZhY2UgKnhjaCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3Qg
ZG9taWQsCmRpZmYgLXIgMzMxM2VlOWY2MTQyIHRvb2xzL2xpYnhjL3hjX2RvbWFpbl9zYXZlLmMK
LS0tIGEvdG9vbHMvbGlieGMveGNfZG9tYWluX3NhdmUuYwlUaHUgT2N0IDI1IDA1OjQ5OjExIDIw
MTIgKzA4MDAKKysrIGIvdG9vbHMvbGlieGMveGNfZG9tYWluX3NhdmUuYwlUdWUgT2N0IDMwIDA2
OjA3OjA1IDIwMTIgKzA4MDAKQEAgLTExMDksNiArMTEwOSwxMyBAQAogICAgICAgICBnb3RvIG91
dDsKICAgICB9CiAKKyAgICAvKiBTdGFydCB2bWNlIG1vbml0b3IgKi8KKyAgICBpZiAoIHhjX2Rv
bWFpbl92bWNlX21vbml0b3IoeGNoLCBkb20sIDEpICkKKyAgICB7CisgICAgICAgIFBFUlJPUigi
RXJyb3Igc3RhcnRpbmcgdm1jZSBtb25pdG9yIik7CisgICAgICAgIGdvdG8gb3V0OworICAgIH0K
KwogICBjb3B5cGFnZXM6CiAjZGVmaW5lIHdyZXhhY3QoZmQsIGJ1ZiwgbGVuKSB3cml0ZV9idWZm
ZXIoeGNoLCBsYXN0X2l0ZXIsIG9iLCAoZmQpLCAoYnVmKSwgKGxlbikpCiAjZGVmaW5lIHdydW5j
YWNoZWQoZmQsIGxpdmUsIGJ1ZiwgbGVuKSB3cml0ZV91bmNhY2hlZCh4Y2gsIGxhc3RfaXRlciwg
b2IsIChmZCksIChidWYpLCAobGVuKSkKQEAgLTE1ODIsNiArMTU4OSwxMyBAQAogCiAgICAgRFBS
SU5URigiQWxsIG1lbW9yeSBpcyBzYXZlZFxuIik7CiAKKyAgICAvKiBFbmQgdm1jZSBtb25pdG9y
ICovCisgICAgaWYgKCB4Y19kb21haW5fdm1jZV9tb25pdG9yKHhjaCwgZG9tLCAwKSApCisgICAg
eworICAgICAgICBQRVJST1IoIkVycm9yIGVuZGluZyB2bWNlIG1vbml0b3IiKTsKKyAgICAgICAg
Z290byBvdXQ7CisgICAgfQorCiAgICAgLyogQWZ0ZXIgbGFzdF9pdGVyLCBidWZmZXIgdGhlIHJl
c3Qgb2YgcGFnZWJ1ZiAmIHRhaWxidWYgZGF0YSBpbnRvIGEKICAgICAgKiBzZXBhcmF0ZSBvdXRw
dXQgYnVmZmVyIGFuZCBmbHVzaCBpdCBhZnRlciB0aGUgY29tcHJlc3NlZCBwYWdlIGNodW5rcy4K
ICAgICAgKi8KZGlmZiAtciAzMzEzZWU5ZjYxNDIgdG9vbHMvbGlieGMveGVuY3RybC5oCi0tLSBh
L3Rvb2xzL2xpYnhjL3hlbmN0cmwuaAlUaHUgT2N0IDI1IDA1OjQ5OjExIDIwMTIgKzA4MDAKKysr
IGIvdG9vbHMvbGlieGMveGVuY3RybC5oCVR1ZSBPY3QgMzAgMDY6MDc6MDUgMjAxMiArMDgwMApA
QCAtNTg2LDYgKzU4NiwxNyBAQAogICAgICAgICAgICAgICAgICAgICAgICAgICAgdW5zaWduZWQg
bG9uZyBwZm4pOwogCiAvKioKKyAqIFRoaXMgZnVuY3Rpb24gc3RhcnQvZW5kIG1vbml0b3Igdm1j
ZSBldmVudC4KKyAqIEBwYXJtIHhjaCBhIGhhbmRsZSB0byBhbiBvcGVuIGh5cGVydmlzb3IgaW50
ZXJmYWNlCisgKiBAcGFybSBkb21pZCB0aGUgZG9tYWluIGlkIG1vbml0b3JlZAorICogQHBhcm0g
ZmxhZyB0byBzdGFydC9lbmQgbW9uaXRvcgorICogQHJldHVybiA8MCBvbiBmYWlsdXJlLCAwIG9u
IHN1Y2Nlc3MKKyAqLworaW50IHhjX2RvbWFpbl92bWNlX21vbml0b3IoeGNfaW50ZXJmYWNlICp4
Y2gsCisgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJfdCBkb21pZCwKKyAgICAgICAg
ICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IHN0YXJ0KTsKKworLyoqCiAgKiBUaGlzIGZ1bmN0
aW9uIHJldHVybnMgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGNvbnRleHQgb2YgYSBodm0gZG9tYWlu
CiAgKiBAcGFybSB4Y2ggYSBoYW5kbGUgdG8gYW4gb3BlbiBoeXBlcnZpc29yIGludGVyZmFjZQog
ICogQHBhcm0gZG9taWQgdGhlIGRvbWFpbiB0byBnZXQgaW5mb3JtYXRpb24gZnJvbQpkaWZmIC1y
IDMzMTNlZTlmNjE0MiB4ZW4vYXJjaC94ODYvY3B1L21jaGVjay9tY2VfaW50ZWwuYwotLS0gYS94
ZW4vYXJjaC94ODYvY3B1L21jaGVjay9tY2VfaW50ZWwuYwlUaHUgT2N0IDI1IDA1OjQ5OjExIDIw
MTIgKzA4MDAKKysrIGIveGVuL2FyY2gveDg2L2NwdS9tY2hlY2svbWNlX2ludGVsLmMJVHVlIE9j
dCAzMCAwNjowNzowNSAyMDEyICswODAwCkBAIC0zNDIsNiArMzQyLDIyIEBACiAgICAgICAgICAg
ICAgICAgICAgIGdvdG8gdm1jZV9mYWlsZWQ7CiAgICAgICAgICAgICAgICAgfQogCisgICAgICAg
ICAgICAgICAgaWYgKCB1bmxpa2VseShkLT5hcmNoLnZtY2VfbW9uaXRvcikgKQorICAgICAgICAg
ICAgICAgIHsKKyAgICAgICAgICAgICAgICAgICAgLyoKKyAgICAgICAgICAgICAgICAgICAgICog
dk1DRSBvY2N1ciBkdXJpbmcgbWlncmF0aW9uCisgICAgICAgICAgICAgICAgICAgICAqCisgICAg
ICAgICAgICAgICAgICAgICAqIG1hcmsgYnJva2VuIHBhZ2UgdG8gZGlydHkgYml0bWFwLCBzbyB0
aGF0IGF0IGNvcHlwYWdlcworICAgICAgICAgICAgICAgICAgICAgKiBzdGFnZSBvZiBtaWdyYXRp
b24sIGl0cyBwZm5fdHlwZSBhbmQgcGZuIG51bWJlciB3b3VsZAorICAgICAgICAgICAgICAgICAg
ICAgKiB0cmFuc2ZlciB0byB0YXJnZXQgYW5kIHRoZW4gdGFrZSBhcHByb3ByaWF0ZSBhY3Rpb24K
KyAgICAgICAgICAgICAgICAgICAgICoKKyAgICAgICAgICAgICAgICAgICAgICogQXQgdGFyZ2V0
LCBpdCB3b3VsZCBzZXQgcDJtIGFzIHAybV9yYW1fYnJva2VuIGZvciBicm9rZW4KKyAgICAgICAg
ICAgICAgICAgICAgICogcGFnZSwgc28gdGhhdCBpZiBndWVzdCBhY2Nlc3MgdGhlIGJyb2tlbiBw
YWdlIGFnYWluLCBpdAorICAgICAgICAgICAgICAgICAgICAgKiB3b3VsZCBraWxsIGl0c2VsZiBh
cyBleHBlY3RlZC4KKyAgICAgICAgICAgICAgICAgICAgICovCisgICAgICAgICAgICAgICAgICAg
IHBhZ2luZ19tYXJrX2RpcnR5KGQsIG1mbik7CisgICAgICAgICAgICAgICAgfQorCiAgICAgICAg
ICAgICAgICAgaWYgKCB1bm1tYXBfYnJva2VuX3BhZ2UoZCwgX21mbihtZm4pLCBnZm4pICkKICAg
ICAgICAgICAgICAgICB7CiAgICAgICAgICAgICAgICAgICAgIHByaW50aygiVW5tYXAgYnJva2Vu
IG1lbW9yeSAlbHggZm9yIERPTSVkIGZhaWxlZFxuIiwKZGlmZiAtciAzMzEzZWU5ZjYxNDIgeGVu
L2FyY2gveDg2L2RvbWN0bC5jCi0tLSBhL3hlbi9hcmNoL3g4Ni9kb21jdGwuYwlUaHUgT2N0IDI1
IDA1OjQ5OjExIDIwMTIgKzA4MDAKKysrIGIveGVuL2FyY2gveDg2L2RvbWN0bC5jCVR1ZSBPY3Qg
MzAgMDY6MDc6MDUgMjAxMiArMDgwMApAQCAtMTU5OSw2ICsxNTk5LDQ0IEBACiAgICAgfQogICAg
IGJyZWFrOwogCisgICAgY2FzZSBYRU5fRE9NQ1RMX3ZtY2VfbW9uaXRvcl9zdGFydDoKKyAgICB7
CisgICAgICAgIHN0cnVjdCBkb21haW4gKmQ7CisKKyAgICAgICAgZCA9IHJjdV9sb2NrX2RvbWFp
bl9ieV9pZChkb21jdGwtPmRvbWFpbik7CisgICAgICAgIGlmICggZCAhPSBOVUxMICkKKyAgICAg
ICAgeworICAgICAgICAgICAgaWYgKCBkLT5hcmNoLnZtY2VfbW9uaXRvciApCisgICAgICAgICAg
ICAgICAgcmV0ID0gLUVCVVNZOworICAgICAgICAgICAgZWxzZQorICAgICAgICAgICAgICAgIGQt
PmFyY2gudm1jZV9tb25pdG9yID0gMTsKKworICAgICAgICAgICAgcmN1X3VubG9ja19kb21haW4o
ZCk7CisgICAgICAgIH0KKyAgICAgICAgZWxzZQorICAgICAgICAgICAgcmV0ID0gLUVTUkNIOwor
ICAgIH0KKyAgICBicmVhazsKKworICAgIGNhc2UgWEVOX0RPTUNUTF92bWNlX21vbml0b3JfZW5k
OgorICAgIHsKKyAgICAgICAgc3RydWN0IGRvbWFpbiAqZDsKKworICAgICAgICBkID0gcmN1X2xv
Y2tfZG9tYWluX2J5X2lkKGRvbWN0bC0+ZG9tYWluKTsKKyAgICAgICAgaWYgKCBkICE9IE5VTEwp
CisgICAgICAgIHsKKyAgICAgICAgICAgIGlmICggIWQtPmFyY2gudm1jZV9tb25pdG9yICkKKyAg
ICAgICAgICAgICAgICByZXQgPSAtRUlOVkFMOworICAgICAgICAgICAgZWxzZQorICAgICAgICAg
ICAgICAgIGQtPmFyY2gudm1jZV9tb25pdG9yID0gMDsKKworICAgICAgICAgICAgcmN1X3VubG9j
a19kb21haW4oZCk7CisgICAgICAgIH0KKyAgICAgICAgZWxzZQorICAgICAgICAgICAgcmV0ID0g
LUVTUkNIOworICAgIH0KKyAgICBicmVhazsKKwogICAgIGRlZmF1bHQ6CiAgICAgICAgIHJldCA9
IGlvbW11X2RvX2RvbWN0bChkb21jdGwsIHVfZG9tY3RsKTsKICAgICAgICAgYnJlYWs7CmRpZmYg
LXIgMzMxM2VlOWY2MTQyIHhlbi9pbmNsdWRlL2FzbS14ODYvZG9tYWluLmgKLS0tIGEveGVuL2lu
Y2x1ZGUvYXNtLXg4Ni9kb21haW4uaAlUaHUgT2N0IDI1IDA1OjQ5OjExIDIwMTIgKzA4MDAKKysr
IGIveGVuL2luY2x1ZGUvYXNtLXg4Ni9kb21haW4uaAlUdWUgT2N0IDMwIDA2OjA3OjA1IDIwMTIg
KzA4MDAKQEAgLTI3OSw2ICsyNzksMTAgQEAKICAgICBib29sX3QgaGFzXzMyYml0X3NoaW5mbzsK
ICAgICAvKiBEb21haW4gY2Fubm90IGhhbmRsZSBzcHVyaW91cyBwYWdlIGZhdWx0cz8gKi8KICAg
ICBib29sX3Qgc3VwcHJlc3Nfc3B1cmlvdXNfcGFnZV9mYXVsdHM7CisgICAgLyogTW9uaXRvcmlu
ZyBndWVzdCBtZW1vcnkgY29weSBvZiBtaWdyYXRpb24KKyAgICAgKiA9IDAgLSBub3QgbW9uaXRv
cmluZworICAgICAqID0gMSAtIG1vbml0b3JpbmcgKi8KKyAgICBib29sX3Qgdm1jZV9tb25pdG9y
OwogCiAgICAgLyogQ29udGludWFibGUgZG9tYWluX3JlbGlucXVpc2hfcmVzb3VyY2VzKCkuICov
CiAgICAgZW51bSB7CmRpZmYgLXIgMzMxM2VlOWY2MTQyIHhlbi9pbmNsdWRlL3B1YmxpYy9kb21j
dGwuaAotLS0gYS94ZW4vaW5jbHVkZS9wdWJsaWMvZG9tY3RsLmgJVGh1IE9jdCAyNSAwNTo0OTox
MSAyMDEyICswODAwCisrKyBiL3hlbi9pbmNsdWRlL3B1YmxpYy9kb21jdGwuaAlUdWUgT2N0IDMw
IDA2OjA3OjA1IDIwMTIgKzA4MDAKQEAgLTkwOCw2ICs5MDgsOCBAQAogI2RlZmluZSBYRU5fRE9N
Q1RMX2F1ZGl0X3AybSAgICAgICAgICAgICAgICAgICAgIDY1CiAjZGVmaW5lIFhFTl9ET01DVExf
c2V0X3ZpcnFfaGFuZGxlciAgICAgICAgICAgICAgNjYKICNkZWZpbmUgWEVOX0RPTUNUTF9zZXRf
YnJva2VuX3BhZ2VfcDJtICAgICAgICAgICA2NworI2RlZmluZSBYRU5fRE9NQ1RMX3ZtY2VfbW9u
aXRvcl9zdGFydCAgICAgICAgICAgIDY4CisjZGVmaW5lIFhFTl9ET01DVExfdm1jZV9tb25pdG9y
X2VuZCAgICAgICAgICAgICAgNjkKICNkZWZpbmUgWEVOX0RPTUNUTF9nZGJzeF9ndWVzdG1lbWlv
ICAgICAgICAgICAgMTAwMAogI2RlZmluZSBYRU5fRE9NQ1RMX2dkYnN4X3BhdXNldmNwdSAgICAg
ICAgICAgICAxMDAxCiAjZGVmaW5lIFhFTl9ET01DVExfZ2Ric3hfdW5wYXVzZXZjcHUgICAgICAg
ICAgIDEwMDIK

--_002_DE8DF0795D48FD4CA783C40EC82923353766A5SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC82923353766A5SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Wed Oct 31 11:21:30 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 11:21:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTWMJ-00009m-3h; Wed, 31 Oct 2012 11:21:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTWMH-00009Q-NP
	for xen-devel@lists.xensource.com; Wed, 31 Oct 2012 11:21:18 +0000
Received: from [85.158.143.35:52936] by server-2.bemta-4.messagelabs.com id
	C2/1B-28922-CA901905; Wed, 31 Oct 2012 11:21:16 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1351682472!15799848!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjI1NTQy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17603 invoked from network); 31 Oct 2012 11:21:14 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-6.tower-21.messagelabs.com with SMTP;
	31 Oct 2012 11:21:14 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 31 Oct 2012 04:21:11 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,687,1344236400"; d="scan'208";a="211689927"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by azsmga001.ch.intel.com with ESMTP; 31 Oct 2012 04:21:10 -0700
Received: from fmsmsx101.amr.corp.intel.com (10.19.9.52) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 31 Oct 2012 04:21:10 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX101.amr.corp.intel.com (10.19.9.52) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 31 Oct 2012 04:21:10 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.186]) with mapi id
	14.01.0355.002; Wed, 31 Oct 2012 19:21:08 +0800
From: "Liu, Jinsong" 
To: George Dunlap , Ian Jackson
	, Jan Beulich 
Thread-Topic: [PATCH 02/02] Handles broken page occurred during migration
Thread-Index: Ac23WdJ0ST9jWMNZSlWheBhAdddc/Q==
Date: Wed, 31 Oct 2012 11:21:07 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC82923353766A5SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" 
Subject: [Xen-devel] [PATCH 02/02] Handles broken page occurred during
	migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC82923353766A5SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Handles broken page occurred during migration

This patch handles broken page which occurred during migration.

It monitors the critical area of live migration (from vMCE point of view,
the copypages stage of migration is the critical area while other areas are=
 not).

If a vMCE occur at the critical area of live migration, it marks the broken=
 page
to dirty map, so that at copypages stage of migration, its pfn_type
and pfn number would transfer to target and then take appropriate action.

At target, it would set p2m as p2m_ram_broken for broken page, so that if
guest access the broken page again, it would kill itself as expected.

Suggested-by: George Dunlap 
Signed-off-by: Liu, Jinsong 

diff -r 3313ee9f6142 tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c	Thu Oct 25 05:49:11 2012 +0800
+++ b/tools/libxc/xc_domain.c	Tue Oct 30 06:07:05 2012 +0800
@@ -299,6 +299,24 @@
     return ret ? -1 : 0;
 }
=20
+/* start/end vmce monitor */
+int xc_domain_vmce_monitor(xc_interface *xch,
+                           uint32_t domid,
+                           uint32_t start)
+{
+    int ret;
+    DECLARE_DOMCTL;
+
+    if ( start )
+        domctl.cmd =3D XEN_DOMCTL_vmce_monitor_start;
+    else
+        domctl.cmd =3D XEN_DOMCTL_vmce_monitor_end;
+    domctl.domain =3D (domid_t)domid;
+    ret =3D do_domctl(xch, &domctl);
+
+    return ret ? -1 : 0;
+}
+
 /* get info from hvm guest for save */
 int xc_domain_hvm_getcontext(xc_interface *xch,
                              uint32_t domid,
diff -r 3313ee9f6142 tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Thu Oct 25 05:49:11 2012 +0800
+++ b/tools/libxc/xc_domain_save.c	Tue Oct 30 06:07:05 2012 +0800
@@ -1109,6 +1109,13 @@
         goto out;
     }
=20
+    /* Start vmce monitor */
+    if ( xc_domain_vmce_monitor(xch, dom, 1) )
+    {
+        PERROR("Error starting vmce monitor");
+        goto out;
+    }
+
   copypages:
 #define wrexact(fd, buf, len) write_buffer(xch, last_iter, ob, (fd), (buf)=
, (len))
 #define wruncached(fd, live, buf, len) write_uncached(xch, last_iter, ob, =
(fd), (buf), (len))
@@ -1582,6 +1589,13 @@
=20
     DPRINTF("All memory is saved\n");
=20
+    /* End vmce monitor */
+    if ( xc_domain_vmce_monitor(xch, dom, 0) )
+    {
+        PERROR("Error ending vmce monitor");
+        goto out;
+    }
+
     /* After last_iter, buffer the rest of pagebuf & tailbuf data into a
      * separate output buffer and flush it after the compressed page chunk=
s.
      */
diff -r 3313ee9f6142 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Thu Oct 25 05:49:11 2012 +0800
+++ b/tools/libxc/xenctrl.h	Tue Oct 30 06:07:05 2012 +0800
@@ -586,6 +586,17 @@
                            unsigned long pfn);
=20
 /**
+ * This function start/end monitor vmce event.
+ * @parm xch a handle to an open hypervisor interface
+ * @parm domid the domain id monitored
+ * @parm flag to start/end monitor
+ * @return <0 on failure, 0 on success
+ */
+int xc_domain_vmce_monitor(xc_interface *xch,
+                           uint32_t domid,
+                           uint32_t start);
+
+/**
  * This function returns information about the context of a hvm domain
  * @parm xch a handle to an open hypervisor interface
  * @parm domid the domain to get information from
diff -r 3313ee9f6142 xen/arch/x86/cpu/mcheck/mce_intel.c
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c	Thu Oct 25 05:49:11 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c	Tue Oct 30 06:07:05 2012 +0800
@@ -342,6 +342,22 @@
                     goto vmce_failed;
                 }
=20
+                if ( unlikely(d->arch.vmce_monitor) )
+                {
+                    /*
+                     * vMCE occur during migration
+                     *
+                     * mark broken page to dirty bitmap, so that at copypa=
ges
+                     * stage of migration, its pfn_type and pfn number wou=
ld
+                     * transfer to target and then take appropriate action
+                     *
+                     * At target, it would set p2m as p2m_ram_broken for b=
roken
+                     * page, so that if guest access the broken page again=
, it
+                     * would kill itself as expected.
+                     */
+                    paging_mark_dirty(d, mfn);
+                }
+
                 if ( unmmap_broken_page(d, _mfn(mfn), gfn) )
                 {
                     printk("Unmap broken memory %lx for DOM%d failed\n",
diff -r 3313ee9f6142 xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c	Thu Oct 25 05:49:11 2012 +0800
+++ b/xen/arch/x86/domctl.c	Tue Oct 30 06:07:05 2012 +0800
@@ -1599,6 +1599,44 @@
     }
     break;
=20
+    case XEN_DOMCTL_vmce_monitor_start:
+    {
+        struct domain *d;
+
+        d =3D rcu_lock_domain_by_id(domctl->domain);
+        if ( d !=3D NULL )
+        {
+            if ( d->arch.vmce_monitor )
+                ret =3D -EBUSY;
+            else
+                d->arch.vmce_monitor =3D 1;
+
+            rcu_unlock_domain(d);
+        }
+        else
+            ret =3D -ESRCH;
+    }
+    break;
+
+    case XEN_DOMCTL_vmce_monitor_end:
+    {
+        struct domain *d;
+
+        d =3D rcu_lock_domain_by_id(domctl->domain);
+        if ( d !=3D NULL)
+        {
+            if ( !d->arch.vmce_monitor )
+                ret =3D -EINVAL;
+            else
+                d->arch.vmce_monitor =3D 0;
+
+            rcu_unlock_domain(d);
+        }
+        else
+            ret =3D -ESRCH;
+    }
+    break;
+
     default:
         ret =3D iommu_do_domctl(domctl, u_domctl);
         break;
diff -r 3313ee9f6142 xen/include/asm-x86/domain.h
--- a/xen/include/asm-x86/domain.h	Thu Oct 25 05:49:11 2012 +0800
+++ b/xen/include/asm-x86/domain.h	Tue Oct 30 06:07:05 2012 +0800
@@ -279,6 +279,10 @@
     bool_t has_32bit_shinfo;
     /* Domain cannot handle spurious page faults? */
     bool_t suppress_spurious_page_faults;
+    /* Monitoring guest memory copy of migration
+     * =3D 0 - not monitoring
+     * =3D 1 - monitoring */
+    bool_t vmce_monitor;
=20
     /* Continuable domain_relinquish_resources(). */
     enum {
diff -r 3313ee9f6142 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h	Thu Oct 25 05:49:11 2012 +0800
+++ b/xen/include/public/domctl.h	Tue Oct 30 06:07:05 2012 +0800
@@ -908,6 +908,8 @@
 #define XEN_DOMCTL_audit_p2m                     65
 #define XEN_DOMCTL_set_virq_handler              66
 #define XEN_DOMCTL_set_broken_page_p2m           67
+#define XEN_DOMCTL_vmce_monitor_start            68
+#define XEN_DOMCTL_vmce_monitor_end              69
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002=

--_002_DE8DF0795D48FD4CA783C40EC82923353766A5SHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="broken_page_occur_during_migration.patch"
Content-Description: broken_page_occur_during_migration.patch
Content-Disposition: attachment;
	filename="broken_page_occur_during_migration.patch"; size=6735;
	creation-date="Wed, 31 Oct 2012 10:08:53 GMT";
	modification-date="Wed, 31 Oct 2012 17:39:42 GMT"
Content-Transfer-Encoding: base64

SGFuZGxlcyBicm9rZW4gcGFnZSBvY2N1cnJlZCBkdXJpbmcgbWlncmF0aW9uCgpUaGlzIHBhdGNo
IGhhbmRsZXMgYnJva2VuIHBhZ2Ugd2hpY2ggb2NjdXJyZWQgZHVyaW5nIG1pZ3JhdGlvbi4KCkl0
IG1vbml0b3JzIHRoZSBjcml0aWNhbCBhcmVhIG9mIGxpdmUgbWlncmF0aW9uIChmcm9tIHZNQ0Ug
cG9pbnQgb2YgdmlldywKdGhlIGNvcHlwYWdlcyBzdGFnZSBvZiBtaWdyYXRpb24gaXMgdGhlIGNy
aXRpY2FsIGFyZWEgd2hpbGUgb3RoZXIgYXJlYXMgYXJlIG5vdCkuCgpJZiBhIHZNQ0Ugb2NjdXIg
YXQgdGhlIGNyaXRpY2FsIGFyZWEgb2YgbGl2ZSBtaWdyYXRpb24sIGl0IG1hcmtzIHRoZSBicm9r
ZW4gcGFnZQp0byBkaXJ0eSBtYXAsIHNvIHRoYXQgYXQgY29weXBhZ2VzIHN0YWdlIG9mIG1pZ3Jh
dGlvbiwgaXRzIHBmbl90eXBlCmFuZCBwZm4gbnVtYmVyIHdvdWxkIHRyYW5zZmVyIHRvIHRhcmdl
dCBhbmQgdGhlbiB0YWtlIGFwcHJvcHJpYXRlIGFjdGlvbi4KCkF0IHRhcmdldCwgaXQgd291bGQg
c2V0IHAybSBhcyBwMm1fcmFtX2Jyb2tlbiBmb3IgYnJva2VuIHBhZ2UsIHNvIHRoYXQgaWYKZ3Vl
c3QgYWNjZXNzIHRoZSBicm9rZW4gcGFnZSBhZ2FpbiwgaXQgd291bGQga2lsbCBpdHNlbGYgYXMg
ZXhwZWN0ZWQuCgpTdWdnZXN0ZWQtYnk6IEdlb3JnZSBEdW5sYXAgPGdlb3JnZS5kdW5sYXBAZXUu
Y2l0cml4LmNvbT4KU2lnbmVkLW9mZi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRl
bC5jb20+CgpkaWZmIC1yIDMzMTNlZTlmNjE0MiB0b29scy9saWJ4Yy94Y19kb21haW4uYwotLS0g
YS90b29scy9saWJ4Yy94Y19kb21haW4uYwlUaHUgT2N0IDI1IDA1OjQ5OjExIDIwMTIgKzA4MDAK
KysrIGIvdG9vbHMvbGlieGMveGNfZG9tYWluLmMJVHVlIE9jdCAzMCAwNjowNzowNSAyMDEyICsw
ODAwCkBAIC0yOTksNiArMjk5LDI0IEBACiAgICAgcmV0dXJuIHJldCA/IC0xIDogMDsKIH0KIAor
Lyogc3RhcnQvZW5kIHZtY2UgbW9uaXRvciAqLworaW50IHhjX2RvbWFpbl92bWNlX21vbml0b3Io
eGNfaW50ZXJmYWNlICp4Y2gsCisgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJfdCBk
b21pZCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IHN0YXJ0KQoreworICAg
IGludCByZXQ7CisgICAgREVDTEFSRV9ET01DVEw7CisKKyAgICBpZiAoIHN0YXJ0ICkKKyAgICAg
ICAgZG9tY3RsLmNtZCA9IFhFTl9ET01DVExfdm1jZV9tb25pdG9yX3N0YXJ0OworICAgIGVsc2UK
KyAgICAgICAgZG9tY3RsLmNtZCA9IFhFTl9ET01DVExfdm1jZV9tb25pdG9yX2VuZDsKKyAgICBk
b21jdGwuZG9tYWluID0gKGRvbWlkX3QpZG9taWQ7CisgICAgcmV0ID0gZG9fZG9tY3RsKHhjaCwg
JmRvbWN0bCk7CisKKyAgICByZXR1cm4gcmV0ID8gLTEgOiAwOworfQorCiAvKiBnZXQgaW5mbyBm
cm9tIGh2bSBndWVzdCBmb3Igc2F2ZSAqLwogaW50IHhjX2RvbWFpbl9odm1fZ2V0Y29udGV4dCh4
Y19pbnRlcmZhY2UgKnhjaCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3Qg
ZG9taWQsCmRpZmYgLXIgMzMxM2VlOWY2MTQyIHRvb2xzL2xpYnhjL3hjX2RvbWFpbl9zYXZlLmMK
LS0tIGEvdG9vbHMvbGlieGMveGNfZG9tYWluX3NhdmUuYwlUaHUgT2N0IDI1IDA1OjQ5OjExIDIw
MTIgKzA4MDAKKysrIGIvdG9vbHMvbGlieGMveGNfZG9tYWluX3NhdmUuYwlUdWUgT2N0IDMwIDA2
OjA3OjA1IDIwMTIgKzA4MDAKQEAgLTExMDksNiArMTEwOSwxMyBAQAogICAgICAgICBnb3RvIG91
dDsKICAgICB9CiAKKyAgICAvKiBTdGFydCB2bWNlIG1vbml0b3IgKi8KKyAgICBpZiAoIHhjX2Rv
bWFpbl92bWNlX21vbml0b3IoeGNoLCBkb20sIDEpICkKKyAgICB7CisgICAgICAgIFBFUlJPUigi
RXJyb3Igc3RhcnRpbmcgdm1jZSBtb25pdG9yIik7CisgICAgICAgIGdvdG8gb3V0OworICAgIH0K
KwogICBjb3B5cGFnZXM6CiAjZGVmaW5lIHdyZXhhY3QoZmQsIGJ1ZiwgbGVuKSB3cml0ZV9idWZm
ZXIoeGNoLCBsYXN0X2l0ZXIsIG9iLCAoZmQpLCAoYnVmKSwgKGxlbikpCiAjZGVmaW5lIHdydW5j
YWNoZWQoZmQsIGxpdmUsIGJ1ZiwgbGVuKSB3cml0ZV91bmNhY2hlZCh4Y2gsIGxhc3RfaXRlciwg
b2IsIChmZCksIChidWYpLCAobGVuKSkKQEAgLTE1ODIsNiArMTU4OSwxMyBAQAogCiAgICAgRFBS
SU5URigiQWxsIG1lbW9yeSBpcyBzYXZlZFxuIik7CiAKKyAgICAvKiBFbmQgdm1jZSBtb25pdG9y
ICovCisgICAgaWYgKCB4Y19kb21haW5fdm1jZV9tb25pdG9yKHhjaCwgZG9tLCAwKSApCisgICAg
eworICAgICAgICBQRVJST1IoIkVycm9yIGVuZGluZyB2bWNlIG1vbml0b3IiKTsKKyAgICAgICAg
Z290byBvdXQ7CisgICAgfQorCiAgICAgLyogQWZ0ZXIgbGFzdF9pdGVyLCBidWZmZXIgdGhlIHJl
c3Qgb2YgcGFnZWJ1ZiAmIHRhaWxidWYgZGF0YSBpbnRvIGEKICAgICAgKiBzZXBhcmF0ZSBvdXRw
dXQgYnVmZmVyIGFuZCBmbHVzaCBpdCBhZnRlciB0aGUgY29tcHJlc3NlZCBwYWdlIGNodW5rcy4K
ICAgICAgKi8KZGlmZiAtciAzMzEzZWU5ZjYxNDIgdG9vbHMvbGlieGMveGVuY3RybC5oCi0tLSBh
L3Rvb2xzL2xpYnhjL3hlbmN0cmwuaAlUaHUgT2N0IDI1IDA1OjQ5OjExIDIwMTIgKzA4MDAKKysr
IGIvdG9vbHMvbGlieGMveGVuY3RybC5oCVR1ZSBPY3QgMzAgMDY6MDc6MDUgMjAxMiArMDgwMApA
QCAtNTg2LDYgKzU4NiwxNyBAQAogICAgICAgICAgICAgICAgICAgICAgICAgICAgdW5zaWduZWQg
bG9uZyBwZm4pOwogCiAvKioKKyAqIFRoaXMgZnVuY3Rpb24gc3RhcnQvZW5kIG1vbml0b3Igdm1j
ZSBldmVudC4KKyAqIEBwYXJtIHhjaCBhIGhhbmRsZSB0byBhbiBvcGVuIGh5cGVydmlzb3IgaW50
ZXJmYWNlCisgKiBAcGFybSBkb21pZCB0aGUgZG9tYWluIGlkIG1vbml0b3JlZAorICogQHBhcm0g
ZmxhZyB0byBzdGFydC9lbmQgbW9uaXRvcgorICogQHJldHVybiA8MCBvbiBmYWlsdXJlLCAwIG9u
IHN1Y2Nlc3MKKyAqLworaW50IHhjX2RvbWFpbl92bWNlX21vbml0b3IoeGNfaW50ZXJmYWNlICp4
Y2gsCisgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJfdCBkb21pZCwKKyAgICAgICAg
ICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IHN0YXJ0KTsKKworLyoqCiAgKiBUaGlzIGZ1bmN0
aW9uIHJldHVybnMgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGNvbnRleHQgb2YgYSBodm0gZG9tYWlu
CiAgKiBAcGFybSB4Y2ggYSBoYW5kbGUgdG8gYW4gb3BlbiBoeXBlcnZpc29yIGludGVyZmFjZQog
ICogQHBhcm0gZG9taWQgdGhlIGRvbWFpbiB0byBnZXQgaW5mb3JtYXRpb24gZnJvbQpkaWZmIC1y
IDMzMTNlZTlmNjE0MiB4ZW4vYXJjaC94ODYvY3B1L21jaGVjay9tY2VfaW50ZWwuYwotLS0gYS94
ZW4vYXJjaC94ODYvY3B1L21jaGVjay9tY2VfaW50ZWwuYwlUaHUgT2N0IDI1IDA1OjQ5OjExIDIw
MTIgKzA4MDAKKysrIGIveGVuL2FyY2gveDg2L2NwdS9tY2hlY2svbWNlX2ludGVsLmMJVHVlIE9j
dCAzMCAwNjowNzowNSAyMDEyICswODAwCkBAIC0zNDIsNiArMzQyLDIyIEBACiAgICAgICAgICAg
ICAgICAgICAgIGdvdG8gdm1jZV9mYWlsZWQ7CiAgICAgICAgICAgICAgICAgfQogCisgICAgICAg
ICAgICAgICAgaWYgKCB1bmxpa2VseShkLT5hcmNoLnZtY2VfbW9uaXRvcikgKQorICAgICAgICAg
ICAgICAgIHsKKyAgICAgICAgICAgICAgICAgICAgLyoKKyAgICAgICAgICAgICAgICAgICAgICog
dk1DRSBvY2N1ciBkdXJpbmcgbWlncmF0aW9uCisgICAgICAgICAgICAgICAgICAgICAqCisgICAg
ICAgICAgICAgICAgICAgICAqIG1hcmsgYnJva2VuIHBhZ2UgdG8gZGlydHkgYml0bWFwLCBzbyB0
aGF0IGF0IGNvcHlwYWdlcworICAgICAgICAgICAgICAgICAgICAgKiBzdGFnZSBvZiBtaWdyYXRp
b24sIGl0cyBwZm5fdHlwZSBhbmQgcGZuIG51bWJlciB3b3VsZAorICAgICAgICAgICAgICAgICAg
ICAgKiB0cmFuc2ZlciB0byB0YXJnZXQgYW5kIHRoZW4gdGFrZSBhcHByb3ByaWF0ZSBhY3Rpb24K
KyAgICAgICAgICAgICAgICAgICAgICoKKyAgICAgICAgICAgICAgICAgICAgICogQXQgdGFyZ2V0
LCBpdCB3b3VsZCBzZXQgcDJtIGFzIHAybV9yYW1fYnJva2VuIGZvciBicm9rZW4KKyAgICAgICAg
ICAgICAgICAgICAgICogcGFnZSwgc28gdGhhdCBpZiBndWVzdCBhY2Nlc3MgdGhlIGJyb2tlbiBw
YWdlIGFnYWluLCBpdAorICAgICAgICAgICAgICAgICAgICAgKiB3b3VsZCBraWxsIGl0c2VsZiBh
cyBleHBlY3RlZC4KKyAgICAgICAgICAgICAgICAgICAgICovCisgICAgICAgICAgICAgICAgICAg
IHBhZ2luZ19tYXJrX2RpcnR5KGQsIG1mbik7CisgICAgICAgICAgICAgICAgfQorCiAgICAgICAg
ICAgICAgICAgaWYgKCB1bm1tYXBfYnJva2VuX3BhZ2UoZCwgX21mbihtZm4pLCBnZm4pICkKICAg
ICAgICAgICAgICAgICB7CiAgICAgICAgICAgICAgICAgICAgIHByaW50aygiVW5tYXAgYnJva2Vu
IG1lbW9yeSAlbHggZm9yIERPTSVkIGZhaWxlZFxuIiwKZGlmZiAtciAzMzEzZWU5ZjYxNDIgeGVu
L2FyY2gveDg2L2RvbWN0bC5jCi0tLSBhL3hlbi9hcmNoL3g4Ni9kb21jdGwuYwlUaHUgT2N0IDI1
IDA1OjQ5OjExIDIwMTIgKzA4MDAKKysrIGIveGVuL2FyY2gveDg2L2RvbWN0bC5jCVR1ZSBPY3Qg
MzAgMDY6MDc6MDUgMjAxMiArMDgwMApAQCAtMTU5OSw2ICsxNTk5LDQ0IEBACiAgICAgfQogICAg
IGJyZWFrOwogCisgICAgY2FzZSBYRU5fRE9NQ1RMX3ZtY2VfbW9uaXRvcl9zdGFydDoKKyAgICB7
CisgICAgICAgIHN0cnVjdCBkb21haW4gKmQ7CisKKyAgICAgICAgZCA9IHJjdV9sb2NrX2RvbWFp
bl9ieV9pZChkb21jdGwtPmRvbWFpbik7CisgICAgICAgIGlmICggZCAhPSBOVUxMICkKKyAgICAg
ICAgeworICAgICAgICAgICAgaWYgKCBkLT5hcmNoLnZtY2VfbW9uaXRvciApCisgICAgICAgICAg
ICAgICAgcmV0ID0gLUVCVVNZOworICAgICAgICAgICAgZWxzZQorICAgICAgICAgICAgICAgIGQt
PmFyY2gudm1jZV9tb25pdG9yID0gMTsKKworICAgICAgICAgICAgcmN1X3VubG9ja19kb21haW4o
ZCk7CisgICAgICAgIH0KKyAgICAgICAgZWxzZQorICAgICAgICAgICAgcmV0ID0gLUVTUkNIOwor
ICAgIH0KKyAgICBicmVhazsKKworICAgIGNhc2UgWEVOX0RPTUNUTF92bWNlX21vbml0b3JfZW5k
OgorICAgIHsKKyAgICAgICAgc3RydWN0IGRvbWFpbiAqZDsKKworICAgICAgICBkID0gcmN1X2xv
Y2tfZG9tYWluX2J5X2lkKGRvbWN0bC0+ZG9tYWluKTsKKyAgICAgICAgaWYgKCBkICE9IE5VTEwp
CisgICAgICAgIHsKKyAgICAgICAgICAgIGlmICggIWQtPmFyY2gudm1jZV9tb25pdG9yICkKKyAg
ICAgICAgICAgICAgICByZXQgPSAtRUlOVkFMOworICAgICAgICAgICAgZWxzZQorICAgICAgICAg
ICAgICAgIGQtPmFyY2gudm1jZV9tb25pdG9yID0gMDsKKworICAgICAgICAgICAgcmN1X3VubG9j
a19kb21haW4oZCk7CisgICAgICAgIH0KKyAgICAgICAgZWxzZQorICAgICAgICAgICAgcmV0ID0g
LUVTUkNIOworICAgIH0KKyAgICBicmVhazsKKwogICAgIGRlZmF1bHQ6CiAgICAgICAgIHJldCA9
IGlvbW11X2RvX2RvbWN0bChkb21jdGwsIHVfZG9tY3RsKTsKICAgICAgICAgYnJlYWs7CmRpZmYg
LXIgMzMxM2VlOWY2MTQyIHhlbi9pbmNsdWRlL2FzbS14ODYvZG9tYWluLmgKLS0tIGEveGVuL2lu
Y2x1ZGUvYXNtLXg4Ni9kb21haW4uaAlUaHUgT2N0IDI1IDA1OjQ5OjExIDIwMTIgKzA4MDAKKysr
IGIveGVuL2luY2x1ZGUvYXNtLXg4Ni9kb21haW4uaAlUdWUgT2N0IDMwIDA2OjA3OjA1IDIwMTIg
KzA4MDAKQEAgLTI3OSw2ICsyNzksMTAgQEAKICAgICBib29sX3QgaGFzXzMyYml0X3NoaW5mbzsK
ICAgICAvKiBEb21haW4gY2Fubm90IGhhbmRsZSBzcHVyaW91cyBwYWdlIGZhdWx0cz8gKi8KICAg
ICBib29sX3Qgc3VwcHJlc3Nfc3B1cmlvdXNfcGFnZV9mYXVsdHM7CisgICAgLyogTW9uaXRvcmlu
ZyBndWVzdCBtZW1vcnkgY29weSBvZiBtaWdyYXRpb24KKyAgICAgKiA9IDAgLSBub3QgbW9uaXRv
cmluZworICAgICAqID0gMSAtIG1vbml0b3JpbmcgKi8KKyAgICBib29sX3Qgdm1jZV9tb25pdG9y
OwogCiAgICAgLyogQ29udGludWFibGUgZG9tYWluX3JlbGlucXVpc2hfcmVzb3VyY2VzKCkuICov
CiAgICAgZW51bSB7CmRpZmYgLXIgMzMxM2VlOWY2MTQyIHhlbi9pbmNsdWRlL3B1YmxpYy9kb21j
dGwuaAotLS0gYS94ZW4vaW5jbHVkZS9wdWJsaWMvZG9tY3RsLmgJVGh1IE9jdCAyNSAwNTo0OTox
MSAyMDEyICswODAwCisrKyBiL3hlbi9pbmNsdWRlL3B1YmxpYy9kb21jdGwuaAlUdWUgT2N0IDMw
IDA2OjA3OjA1IDIwMTIgKzA4MDAKQEAgLTkwOCw2ICs5MDgsOCBAQAogI2RlZmluZSBYRU5fRE9N
Q1RMX2F1ZGl0X3AybSAgICAgICAgICAgICAgICAgICAgIDY1CiAjZGVmaW5lIFhFTl9ET01DVExf
c2V0X3ZpcnFfaGFuZGxlciAgICAgICAgICAgICAgNjYKICNkZWZpbmUgWEVOX0RPTUNUTF9zZXRf
YnJva2VuX3BhZ2VfcDJtICAgICAgICAgICA2NworI2RlZmluZSBYRU5fRE9NQ1RMX3ZtY2VfbW9u
aXRvcl9zdGFydCAgICAgICAgICAgIDY4CisjZGVmaW5lIFhFTl9ET01DVExfdm1jZV9tb25pdG9y
X2VuZCAgICAgICAgICAgICAgNjkKICNkZWZpbmUgWEVOX0RPTUNUTF9nZGJzeF9ndWVzdG1lbWlv
ICAgICAgICAgICAgMTAwMAogI2RlZmluZSBYRU5fRE9NQ1RMX2dkYnN4X3BhdXNldmNwdSAgICAg
ICAgICAgICAxMDAxCiAjZGVmaW5lIFhFTl9ET01DVExfZ2Ric3hfdW5wYXVzZXZjcHUgICAgICAg
ICAgIDEwMDIK

--_002_DE8DF0795D48FD4CA783C40EC82923353766A5SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC82923353766A5SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Wed Oct 31 11:48:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 11:48:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTWmN-0000mG-HL; Wed, 31 Oct 2012 11:48:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTWmM-0000mB-1D
	for xen-devel@lists.xensource.com; Wed, 31 Oct 2012 11:48:14 +0000
Received: from [85.158.138.51:64900] by server-8.bemta-3.messagelabs.com id
	3F/10-10525-DFF01905; Wed, 31 Oct 2012 11:48:13 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-4.tower-174.messagelabs.com!1351684092!28099890!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDY1MzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5184 invoked from network); 31 Oct 2012 11:48:12 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 31 Oct 2012 11:48:12 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 4AE1518D9;
	Wed, 31 Oct 2012 13:48:10 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id E183B20059; Wed, 31 Oct 2012 13:48:09 +0200 (EET)
Date: Wed, 31 Oct 2012 13:48:09 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= 
To: Olaf Hering 
Message-ID: <20121031114809.GB8912@reaktio.net>
References: <1351613105-24408-1-git-send-email-olaf@aepfle.de>
	<20121030181732.GZ8912@reaktio.net>
	<20121030182859.GA8775@aepfle.de>
	<1351672212.20470.7.camel@hastur.hellion.org.uk>
	<20121031092925.GA22587@aepfle.de>
	<20121031102128.GA8912@reaktio.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20121031102128.GA8912@reaktio.net>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "linux-kernel@vger.kernel.org" ,
	Jeremy Fitzhardinge ,
	"xen-devel@lists.xensource.com" ,
	Ian Campbell ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH] xen PVonHVM: require at least Xen 3.4 as
 dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 31, 2012 at 12:21:28PM +0200, Pasi K=E4rkk=E4inen wrote:
> On Wed, Oct 31, 2012 at 10:29:25AM +0100, Olaf Hering wrote:
> > On Wed, Oct 31, Ian Campbell wrote:
> > =

> > > If I understand correctly this requirements comes from the need to
> > > support moving the shared info page in order to support kexec?
> > > =

> > > So could we do something more fine grained and limit only the kexec
> > > support (and therefore the movement of the SI into that range) to 3.4=
+?
> > =

> > Its not strictly about kexec. The other patch I sent out will place the
> > shared info page at 0xFE700000. If that range is not within a
> > E820_Reserved area and if the old hvmloader makes allocations within
> > that range, that other patch needs to be changed so that the shared info
> > page is done either at 0xFE700000 or within RESERVE_BRK (as it is done
> > currently).
> > =

> > Is the source code of that old RHEL available somewhere, did they patch
> > hvmloader at all? Providing a E820 map from a guest which was started on
> > such old dom0 would be a good start.
> > =

> =

> http://ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/os/SRPMS/xen=
-3.0.3-135.el5_8.5.src.rpm
> That's the userland, actual Xen hypervisor is in the kernel src.rpm.
> =

> I can provide a dmesg from a guest later today.
> =


dmesg from a Fedora 17 PVHVM guest with Linux 3.5.4, running on RHEL 5.8 Xe=
n dom0:



[    0.000000] Linux version 3.5.4-1.fc17.x86_64 (mockbuild@) (gcc version =
4.7.0 20120507 (Red Hat 4.7.0-5) (GCC) ) #1 SMP Mon Sep 17 15:03:59 UTC 2012
[    0.000000] Command line: BOOT_IMAGE=3D/vmlinuz-3.5.4-1.fc17.x86_64 root=
=3D/dev/mapper/vg_f17x64hvm01-lv_root ro rd.lvm.lv=3Dvg_f17x64hvm01/lv_root=
 rd.md=3D0 rd.dm=3D0 SYSFONT=3DT
rue KEYTABLE=3Dfi rd.luks=3D0 rd.lvm.lv=3Dvg_f17x64hvm01/lv_swap LANG=3Den_=
US.UTF-8 rhgb
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
[    0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reser=
ved
[    0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reser=
ved
[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000003fffabff] usable
[    0.000000] BIOS-e820: [mem 0x000000003fffac00-0x000000003fffffff] reser=
ved
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI 2.4 present.
[    0.000000] DMI: Red Hat HVM domU, BIOS 3.1.2-308.13.1.el5 09/27/2012
[    0.000000] Hypervisor detected: Xen HVM
[    0.000000] Xen version 3.1.
[    0.000000] Xen Platform PCI: I/O protocol version 1
[    0.000000] Netfront and the Xen platform PCI driver have been compiled =
for this kernel: unplug emulated NICs.
[    0.000000] Blkfront and the Xen platform PCI driver have been compiled =
for this kernel: unplug emulated disks.
[    0.000000] You might have to change the root device
[    0.000000] from /dev/hd[a-d] to /dev/xvd[a-d]
[    0.000000] in your root=3D kernel command line option
[    0.000000] HVMOP_pagetable_dying not supported
[    0.000000] e820: update [mem 0x00000000-0x0000ffff] usable =3D=3D> rese=
rved
[    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[    0.000000] No AGP bridge found
[    0.000000] e820: last_pfn =3D 0x3fffa max_arch_pfn =3D 0x400000000
[    0.000000] MTRR default type: uncachable
[    0.000000] MTRR fixed ranges enabled:
[    0.000000]   00000-9FFFF write-back
[    0.000000]   A0000-BFFFF uncachable
[    0.000000]   C0000-CBFFF write-protect
[    0.000000]   CC000-D3FFF write-back
[    0.000000]   D4000-EBFFF uncachable
[    0.000000]   EC000-FFFFF write-protect
[    0.000000] MTRR variable ranges enabled:
[    0.000000]   0 base 0000000000 mask FF80000000 write-back
[    0.000000]   1 base 0080000000 mask FFC0000000 write-back
[    0.000000]   2 base 00C0000000 mask FFF0000000 write-back
[    0.000000]   3 base 0100000000 mask FF00000000 write-back
[    0.000000]   4 base 0200000000 mask FE00000000 write-back
[    0.000000]   5 base 0400000000 mask FC00000000 write-back
[    0.000000]   6 base 0800000000 mask FC00000000 write-back
[    0.000000]   7 base 0C00000000 mask FFC0000000 write-back
[    0.000000]   8 disabled
[    0.000000]   9 disabled
[    0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x701060007=
0106
[    0.000000] e820: update [mem 0xd0000000-0xffffffff] usable =3D=3D> rese=
rved
[    0.000000] found SMP MP-table at [mem 0x000fccd0-0x000fccdf] mapped at =
[ffff8800000fccd0]
[    0.000000] initial memory mapped: [mem 0x00000000-0x1fffffff]
[    0.000000] Base memory trampoline at [ffff880000099000] 99000 size 24576
[    0.000000] init_memory_mapping: [mem 0x00000000-0x3fff9fff]
[    0.000000]  [mem 0x00000000-0x3fdfffff] page 2M
[    0.000000]  [mem 0x3fe00000-0x3fff9fff] page 4k
[    0.000000] kernel direct mapping tables up to 0x3fff9fff @ [mem 0x1fdfe=
000-0x1fffffff]
[    0.000000] RAMDISK: [mem 0x36398000-0x371c3fff]
[    0.000000] ACPI: RSDP 00000000000eb340 00024 (v02    Xen)
[    0.000000] ACPI: XSDT 00000000000eb2b0 00044 (v01    Xen      HVM 00000=
000 HVML 00000000)
[    0.000000] ACPI: FACP 00000000000eb0c0 000F4 (v04    Xen      HVM 00000=
000 HVML 00000000)
[    0.000000] ACPI: DSDT 00000000000ea050 00FEA (v02    Xen      HVM 00000=
000 INTL 20110413)
[    0.000000] ACPI: FACS 00000000000ea010 00040
[    0.000000] ACPI: APIC 00000000000eb1c0 00072 (v02    Xen      HVM 00000=
000 HVML 00000000)
[    0.000000] ACPI: HPET 00000000000eb240 00038 (v01    Xen      HVM 00000=
000 HVML 00000000)
[    0.000000] ACPI: SSDT 00000000000eb278 00038 (v02    Xen      HVM 00000=
000 HVML 00000000)
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] No NUMA configuration found
[    0.000000] Faking a node at [mem 0x0000000000000000-0x000000003fff9fff]
[    0.000000] Initmem setup node 0 [mem 0x00000000-0x3fff9fff]
[    0.000000]   NODE_DATA [mem 0x3ffe6000-0x3fff9fff]
[    0.000000]  [ffffea0000000000-ffffea0000ffffff] PMD -> [ffff88003e60000=
0-ffff88003f5fffff] on node 0
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x00010000-0x00ffffff]
[    0.000000]   DMA32    [mem 0x01000000-0xffffffff]
[    0.000000]   Normal   empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x00010000-0x0009efff]
[    0.000000]   node   0: [mem 0x00100000-0x3fff9fff]
[    0.000000] On node 0 totalpages: 262025
[    0.000000]   DMA zone: 64 pages used for memmap
[    0.000000]   DMA zone: 6 pages reserved
[    0.000000]   DMA zone: 3913 pages, LIFO batch:0
[    0.000000]   DMA32 zone: 4032 pages used for memmap
[    0.000000]   DMA32 zone: 254010 pages, LIFO batch:31
[    0.000000] ACPI: PM-Timer IO Port: 0x1f48
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[    0.000000] ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 1, version 17, address 0xfec00000, GSI 0-=
47
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 low level)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 7 global_irq 7 low level)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 low level)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 low level)
[    0.000000] ACPI: IRQ0 used by override.
[    0.000000] ACPI: IRQ2 used by override.
[    0.000000] ACPI: IRQ5 used by override.
[    0.000000] ACPI: IRQ7 used by override.
[    0.000000] ACPI: IRQ9 used by override.
[    0.000000] ACPI: IRQ10 used by override.
[    0.000000] ACPI: IRQ11 used by override.
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000
[    0.000000] SMP: Allowing 1 CPUs, 0 hotplug CPUs
[    0.000000] nr_irqs_gsi: 64
[    0.000000] PM: Registered nosave memory: 000000000009f000 - 00000000000=
a0000
[    0.000000] PM: Registered nosave memory: 00000000000a0000 - 00000000000=
e0000
[    0.000000] PM: Registered nosave memory: 00000000000e0000 - 00000000001=
00000
[    0.000000] e820: [mem 0x40000000-0xffffffff] available for PCI devices
[    0.000000] Booting paravirtualized kernel on Xen HVM
[    0.000000] setup_percpu: NR_CPUS:128 nr_cpumask_bits:128 nr_cpu_ids:1 n=
r_node_ids:1
[    0.000000] PERCPU: Embedded 28 pages/cpu @ffff88003fc00000 s83136 r8192=
 d23360 u2097152
[    0.000000] pcpu-alloc: s83136 r8192 d23360 u2097152 alloc=3D1*2097152
[    0.000000] pcpu-alloc: [0] 0
[    0.000000] Built 1 zonelists in Node order, mobility grouping on.  Tota=
l pages: 257923
[    0.000000] Policy zone: DMA32
[    0.000000] Kernel command line: BOOT_IMAGE=3D/vmlinuz-3.5.4-1.fc17.x86_=
64 root=3D/dev/mapper/vg_f17x64hvm01-lv_root ro rd.lvm.lv=3Dvg_f17x64hvm01/=
lv_root rd.md=3D0 rd.dm=3D0 SYSFONT=3DTrue KEYTABLE=3Dfi rd.luks=3D0 rd.lvm=
.lv=3Dvg_f17x64hvm01/lv_swap LANG=3Den_US.UTF-8 rhgb
[    0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    0.000000] __ex_table already sorted, skipping sort
[    0.000000] Checking aperture...
[    0.000000] No AGP bridge found
[    0.000000] Memory: 1000920k/1048552k available (6243k kernel code, 452k=
 absent, 47180k reserved, 6940k data, 1016k init)
[    0.000000] SLUB: Genslabs=3D15, HWalign=3D64, Order=3D0-3, MinObjects=
=3D0, CPUs=3D1, Nodes=3D1
[    0.000000] Hierarchical RCU implementation.
[    0.000000] NR_IRQS:8448 nr_irqs:256 16
[    0.000000] Console: colour dummy device 80x25
[    0.000000] console [tty0] enabled
[    0.000000] Cannot get hvm parameter 18: -22!
[    0.000000] allocated 4194304 bytes of page_cgroup
[    0.000000] please try 'cgroup_disable=3Dmemory' option if you don't wan=
t memory cgroups
[    0.000000] hpet clockevent registered
[    0.000000] Fast TSC calibration using PIT
[    0.000000] Detected 2266.865 MHz processor.
[    0.002002] Calibrating delay loop (skipped), value calculated using tim=
er frequency.. 4533.73 BogoMIPS (lpj=3D2266865)
[    0.002011] pid_max: default: 32768 minimum: 301
[    0.002042] Security Framework initialized
[    0.002051] SELinux:  Initializing.
[    0.002064] SELinux:  Starting in permissive mode
[    0.002246] Dentry cache hash table entries: 131072 (order: 8, 1048576 b=
ytes)
[    0.002574] Inode-cache hash table entries: 65536 (order: 7, 524288 byte=
s)
[    0.003077] Mount-cache hash table entries: 256
[    0.003313] Initializing cgroup subsys cpuacct
[    0.003320] Initializing cgroup subsys memory
[    0.003334] Initializing cgroup subsys devices
[    0.003339] Initializing cgroup subsys freezer
[    0.003343] Initializing cgroup subsys net_cls
[    0.003347] Initializing cgroup subsys blkio
[    0.003351] Initializing cgroup subsys perf_event
[    0.003453] mce: CPU supports 0 MCE banks
[    0.003693] SMP alternatives: switching to UP code
[    0.025713] Freeing SMP alternatives: 24k freed
[    0.025736] ACPI: Core revision 20120320
[    0.026449] ftrace: allocating 23073 entries in 91 pages
[    0.039831] ..TIMER: vector=3D0x30 apic1=3D0 pin1=3D2 apic2=3D-1 pin2=3D=
-1
[    0.049847] CPU0: Intel(R) Xeon(R) CPU           L5640  @ 2.27GHz steppi=
ng 02
[    0.049996] Performance Events: unsupported p6 CPU model 44 no PMU drive=
r, software events only.
[    0.049996] NMI watchdog: disabled (cpu0): hardware events not enabled
[    0.049996] Brought up 1 CPUs
[    0.049996] Total of 1 processors activated (4533.73 BogoMIPS).
[    0.051186] devtmpfs: initialized
[    0.052641] atomic64 test passed for x86-64 platform with CX8 and with S=
SE
[    0.052680] RTC time: 11:39:09, date: 10/31/12
[    0.052726] NET: Registered protocol family 16
[    0.053044] ACPI: bus type pci registered
[    0.053398] PCI: Using configuration type 1 for base access
[    0.054494] bio: create slab  at 0
[    0.054574] ACPI: Added _OSI(Module Device)
[    0.054579] ACPI: Added _OSI(Processor Device)
[    0.054583] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.054587] ACPI: Added _OSI(Processor Aggregator Device)
[    0.055150] ACPI: EC: Look up EC in DSDT
[    0.056561] ACPI: Interpreter enabled
[    0.056569] ACPI: (supports S0 S5)
[    0.056586] ACPI: Using IOAPIC for interrupt routing
[    0.058580] ACPI: No dock devices found.
[    0.058589] PCI: Using host bridge windows from ACPI; if necessary, use =
"pci=3Dnocrs" and report a bug
[    0.058623] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[    0.058662] pci_root PNP0A03:00: host bridge window [io  0x0000-0x0cf7]
[    0.058668] pci_root PNP0A03:00: host bridge window [io  0x0d00-0xffff]
[    0.058674] pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x00=
0bffff]
[    0.058680] pci_root PNP0A03:00: host bridge window [mem 0xf0000000-0xf4=
ffffff]
[    0.058719] PCI host bridge to bus 0000:00
[    0.058725] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7]
[    0.058730] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
[    0.058734] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bfff=
f]
[    0.058740] pci_bus 0000:00: root bus resource [mem 0xf0000000-0xf4fffff=
f]
[    0.058888] pci 0000:00:00.0: [8086:1237] type 00 class 0x060000
[    0.060341] pci 0000:00:01.0: [8086:7000] type 00 class 0x060100
[    0.062468] pci 0000:00:01.1: [8086:7010] type 00 class 0x010180
[    0.063798] pci 0000:00:01.1: reg 20: [io  0xc000-0xc00f]
[    0.064737] pci 0000:00:01.2: [8086:7113] type 00 class 0x068000
[    0.066604] pci 0000:00:01.2: quirk: [io  0x1f40-0x1f7f] claimed by PIIX=
4 ACPI
[    0.067167] pci 0000:00:01.3: [8086:7020] type 00 class 0x0c0300
[    0.068505] pci 0000:00:01.3: reg 20: [io  0xc020-0xc03f]
[    0.069531] pci 0000:00:02.0: [1013:00b8] type 00 class 0x030000
[    0.069840] pci 0000:00:02.0: reg 10: [mem 0xf0000000-0xf1ffffff pref]
[    0.070066] pci 0000:00:02.0: reg 14: [mem 0xf2000000-0xf2000fff]
[    0.071671] pci 0000:00:03.0: [5853:0001] type 00 class 0x010000
[    0.072032] pci 0000:00:03.0: reg 10: [io  0xc100-0xc1ff]
[    0.072275] pci 0000:00:03.0: reg 14: [mem 0xf3000000-0xf3ffffff pref]
[    0.074114] pci 0000:00:06.0: [8086:10ed] type 00 class 0x020000
[    0.075080] pci 0000:00:06.0: reg 10: [mem 0xf4020000-0xf4023fff 64bit]
[    0.076389] pci 0000:00:06.0: reg 1c: [mem 0xf4024000-0xf4027fff 64bit]
[    0.079467] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
[    0.079705]  pci0000:00: Unable to request _OSC control (_OSC support ma=
sk: 0x1e)
[    0.083474] ACPI: PCI Interrupt Link [LNKA] (IRQs *5 7 10 11)
[    0.083650] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *7 10 11)
[    0.083822] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 7 *10 11)
[    0.084068] ACPI: PCI Interrupt Link [LNKD] (IRQs 5 7 10 *11)
[    0.084195] xen/balloon: Initialising balloon driver.
[    0.084212] xen-balloon: Initialising balloon driver.
[    0.084340] vgaarb: device added: PCI:0000:00:02.0,decodes=3Dio+mem,owns=
=3Dio+mem,locks=3Dnone
[    0.084348] vgaarb: loaded
[    0.084351] vgaarb: bridge control possible 0000:00:02.0
[    0.084431] SCSI subsystem initialized
[    0.084468] libata version 3.00 loaded.
[    0.084501] ACPI: bus type usb registered
[    0.084524] usbcore: registered new interface driver usbfs
[    0.084537] usbcore: registered new interface driver hub
[    0.084562] usbcore: registered new device driver usb
[    0.084626] PCI: Using ACPI for IRQ routing
[    0.084631] PCI: pci_cache_line_size set to 64 bytes
[    0.085209] e820: reserve RAM buffer [mem 0x0009fc00-0x0009ffff]
[    0.085212] e820: reserve RAM buffer [mem 0x3fffac00-0x3fffffff]
[    0.085323] NetLabel: Initializing
[    0.085328] NetLabel:  domain hash size =3D 128
[    0.085331] NetLabel:  protocols =3D UNLABELED CIPSOv4
[    0.085344] NetLabel:  unlabeled traffic allowed by default
[    0.085416] HPET: 3 timers in total, 0 timers will be used for per-cpu t=
imer
[    0.085431] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
[    0.085438] hpet0: 3 comparators, 64-bit 70.836816 MHz counter
[    0.088026] Switching to clocksource hpet
[    0.096355] pnp: PnP ACPI init
[    0.096371] ACPI: bus type pnp registered
[    0.096392] pnp 00:00: [mem 0x00000000-0x0009ffff]
[    0.096425] system 00:00: [mem 0x00000000-0x0009ffff] could not be reser=
ved
[    0.096433] system 00:00: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.096465] pnp 00:01: [bus 00-ff]
[    0.096468] pnp 00:01: [io  0x0cf8-0x0cff]
[    0.096471] pnp 00:01: [io  0x0000-0x0cf7 window]
[    0.096473] pnp 00:01: [io  0x0d00-0xffff window]
[    0.096476] pnp 00:01: [mem 0x000a0000-0x000bffff window]
[    0.096479] pnp 00:01: [mem 0xf0000000-0xf4ffffff]
[    0.096503] pnp 00:01: Plug and Play ACPI device, IDs PNP0a03 (active)
[    0.096513] pnp 00:02: [io  0x10c0-0x10c2]
[    0.096516] pnp 00:02: [io  0xb044-0xb047]
[    0.096545] system 00:02: [io  0x10c0-0x10c2] has been reserved
[    0.096551] system 00:02: [io  0xb044-0xb047] has been reserved
[    0.096557] system 00:02: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.096811] pnp 00:03: [mem 0xfed00000-0xfed003ff]
[    0.096835] pnp 00:03: Plug and Play ACPI device, IDs PNP0103 (active)
[    0.096857] pnp 00:04: [io  0x0010-0x001f]
[    0.096859] pnp 00:04: [io  0x0022-0x002d]
[    0.096862] pnp 00:04: [io  0x0030-0x003f]
[    0.096864] pnp 00:04: [io  0x0044-0x005f]
[    0.096866] pnp 00:04: [io  0x0062-0x0063]
[    0.096868] pnp 00:04: [io  0x0065-0x006f]
[    0.096871] pnp 00:04: [io  0x0072-0x007f]
[    0.096873] pnp 00:04: [io  0x0080]
[    0.096875] pnp 00:04: [io  0x0084-0x0086]
[    0.096877] pnp 00:04: [io  0x0088]
[    0.096879] pnp 00:04: [io  0x008c-0x008e]
[    0.096882] pnp 00:04: [io  0x0090-0x009f]
[    0.096884] pnp 00:04: [io  0x00a2-0x00bd]
[    0.096886] pnp 00:04: [io  0x00e0-0x00ef]
[    0.096888] pnp 00:04: [io  0x08a0-0x08a3]
[    0.096891] pnp 00:04: [io  0x0cc0-0x0ccf]
[    0.096893] pnp 00:04: [io  0x04d0-0x04d1]
[    0.096932] system 00:04: [io  0x08a0-0x08a3] has been reserved
[    0.096939] system 00:04: [io  0x0cc0-0x0ccf] has been reserved
[    0.096944] system 00:04: [io  0x04d0-0x04d1] has been reserved
[    0.096950] system 00:04: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.096964] pnp 00:05: [dma 4]
[    0.096966] pnp 00:05: [io  0x0000-0x000f]
[    0.096969] pnp 00:05: [io  0x0081-0x0083]
[    0.096971] pnp 00:05: [io  0x0087]
[    0.096973] pnp 00:05: [io  0x0089-0x008b]
[    0.096976] pnp 00:05: [io  0x008f]
[    0.096978] pnp 00:05: [io  0x00c0-0x00df]
[    0.096980] pnp 00:05: [io  0x0480-0x048f]
[    0.097002] pnp 00:05: Plug and Play ACPI device, IDs PNP0200 (active)
[    0.097063] pnp 00:06: [io  0x0070-0x0071]
[    0.097084] pnp 00:06: [irq 8]
[    0.097115] pnp 00:06: Plug and Play ACPI device, IDs PNP0b00 (active)
[    0.097125] pnp 00:07: [io  0x0061]
[    0.097147] pnp 00:07: Plug and Play ACPI device, IDs PNP0800 (active)
[    0.097185] pnp 00:08: [irq 12]
[    0.097212] pnp 00:08: Plug and Play ACPI device, IDs PNP0f13 (active)
[    0.097230] pnp 00:09: [io  0x0060]
[    0.097232] pnp 00:09: [io  0x0064]
[    0.097251] pnp 00:09: [irq 1]
[    0.097279] pnp 00:09: Plug and Play ACPI device, IDs PNP0303 PNP030b (a=
ctive)
[    0.097299] pnp 00:0a: [io  0x03f0-0x03f5]
[    0.097301] pnp 00:0a: [io  0x03f7]
[    0.097319] pnp 00:0a: [irq 6]
[    0.097322] pnp 00:0a: [dma 2]
[    0.097346] pnp 00:0a: Plug and Play ACPI device, IDs PNP0700 (active)
[    0.097372] pnp 00:0b: [io  0x03f8-0x03ff]
[    0.097391] pnp 00:0b: [irq 4]
[    0.097419] pnp 00:0b: Plug and Play ACPI device, IDs PNP0501 (active)
[    0.097565] pnp: PnP ACPI: found 12 devices
[    0.097570] ACPI: ACPI bus type pnp unregistered
[    0.103895] pci_bus 0000:00: resource 4 [io  0x0000-0x0cf7]
[    0.103899] pci_bus 0000:00: resource 5 [io  0x0d00-0xffff]
[    0.103902] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff]
[    0.103904] pci_bus 0000:00: resource 7 [mem 0xf0000000-0xf4ffffff]
[    0.103942] NET: Registered protocol family 2
[    0.104059] IP route cache hash table entries: 32768 (order: 6, 262144 b=
ytes)
[    0.104396] TCP established hash table entries: 131072 (order: 9, 209715=
2 bytes)
[    0.104917] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[    0.105164] TCP: Hash tables configured (established 131072 bind 65536)
[    0.105169] TCP: reno registered
[    0.105178] UDP hash table entries: 512 (order: 2, 16384 bytes)
[    0.105191] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
[    0.105254] NET: Registered protocol family 1
[    0.105268] pci 0000:00:00.0: Limiting direct PCI/PCI transfers
[    0.105329] pci 0000:00:01.0: PIIX3: Enabling Passive Release
[    0.105405] pci 0000:00:01.0: Activating ISA DMA hang workarounds
[    0.105882] pci 0000:00:02.0: Boot video device
[    0.106032] PCI: CLS 0 bytes, default 64
[    0.106076] Unpacking initramfs...
[    0.514071] Freeing initrd memory: 14512k freed
[    0.520187] alg: No test for __gcm-aes-aesni (__driver-gcm-aes-aesni)
[    0.520475] audit: initializing netlink socket (disabled)
[    0.520493] type=3D2000 audit(1351683549.519:1): initialized
[    0.548550] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[    0.550379] VFS: Disk quotas dquot_6.5.2
[    0.550435] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    0.550892] msgmni has been set to 1983
[    0.550959] SELinux:  Registering netfilter hooks
[    0.551447] alg: No test for stdrng (krng)
[    0.551455] NET: Registered protocol family 38
[    0.551501] Block layer SCSI generic (bsg) driver version 0.4 loaded (ma=
jor 252)
[    0.551540] io scheduler noop registered
[    0.551544] io scheduler deadline registered
[    0.551580] io scheduler cfq registered (default)
[    0.551684] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[    0.551709] pciehp: PCI Express Hot Plug Controller Driver version: 0.4
[    0.551714] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
[    0.551777] acpiphp: Slot [1] registered
[    0.551797] acpiphp: Slot [2] registered
[    0.551909] efifb: probing for efifb
[    0.552061] efifb: framebuffer at 0xf0000000, mapped to 0xffffc900005000=
00, using 1408k, total 1408k
[    0.552068] efifb: mode is 800x600x24, linelength=3D2400, pages=3D1
[    0.552071] efifb: scrolling: redraw
[    0.552075] efifb: Truecolor: size=3D0:8:8:8, shift=3D0:16:8:0
[    0.554963] Console: switching to colour frame buffer device 100x37
[    0.557505] fb0: EFI VGA frame buffer device
[    0.557558] intel_idle: does not run on family 6 model 44
[    0.559150] GHES: HEST is not enabled!
[    0.560329] Grant tables using version 1 layout.
[    0.561053] Grant table initialized
[    0.563974] Cannot get hvm parameter 18: -22!
[    0.564057] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    0.564761] serial8250: ttyS0 at I/O 0x3f8 (irq =3D 4) is a 16450
[    0.567223] 00:0b: ttyS0 at I/O 0x3f8 (irq =3D 4) is a 16450
[    0.568715] Non-volatile memory driver v1.3
[    0.569901] Linux agpgart interface v0.103
[    0.571940] loop: module loaded
[    0.573169] ata_piix 0000:00:01.1: version 2.13
[    0.573412] ata_piix 0000:00:01.1: setting latency timer to 64
[    0.573953] scsi0 : ata_piix
[    0.575153] scsi1 : ata_piix
[    0.576294] ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xc000 irq 14
[    0.577438] ata2: PATA max MWDMA2 cmd 0x170 ctl 0x376 bmdma 0xc008 irq 15
[    0.579517] Fixed MDIO Bus: probed
[    0.581517] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    0.582644] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    0.583781] uhci_hcd: USB Universal Host Controller Interface driver
[    0.585135] uhci_hcd 0000:00:01.3: setting latency timer to 64
[    0.585173] uhci_hcd 0000:00:01.3: UHCI Host Controller
[    0.586346] uhci_hcd 0000:00:01.3: new USB bus registered, assigned bus =
number 1
[    0.587784] uhci_hcd 0000:00:01.3: irq 23, io base 0x0000c020
[    0.589922] usb usb1: New USB device found, idVendor=3D1d6b, idProduct=
=3D0001
[    0.591061] usb usb1: New USB device strings: Mfr=3D3, Product=3D2, Seri=
alNumber=3D1
[    0.592231] usb usb1: Product: UHCI Host Controller
[    0.593403] usb usb1: Manufacturer: Linux 3.5.4-1.fc17.x86_64 uhci_hcd
[    0.594585] usb usb1: SerialNumber: 0000:00:01.3
[    0.595842] hub 1-0:1.0: USB hub found
[    0.597033] hub 1-0:1.0: 2 ports detected
[    0.598354] usbcore: registered new interface driver usbserial
[    0.599501] usbcore: registered new interface driver usbserial_generic
[    0.600611] USB Serial support registered for generic
[    0.601705] usbserial: USB Serial Driver core
[    0.602837] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0=
x60,0x64 irq 1,12
[    0.606311] serio: i8042 KBD port at 0x60,0x64 irq 1
[    0.607478] serio: i8042 AUX port at 0x60,0x64 irq 12
[    0.608710] mousedev: PS/2 mouse device common for all mice
[    0.610891] input: AT Translated Set 2 keyboard as /devices/platform/i80=
42/serio0/input/input0
[    0.618267] rtc_cmos 00:06: rtc core: registered rtc_cmos as rtc0
[    0.619536] rtc0: alarms up to one day, 114 bytes nvram, hpet irqs
[    0.626404] device-mapper: uevent: version 1.0.3
[    0.629046] device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised:=
 dm-devel@redhat.com
[    0.630380] cpuidle: using governor ladder
[    0.631644] cpuidle: using governor menu
[    0.632955] EFI Variables Facility v0.08 2004-May-17
[    0.634343] usbcore: registered new interface driver usbhid
[    0.635674] usbhid: USB HID core driver
[    0.636960] drop_monitor: Initializing network drop monitor service
[    0.638351] ip_tables: (C) 2000-2006 Netfilter Core Team
[    0.639670] TCP: cubic registered
[    0.640945] Initializing XFRM netlink socket
[    0.642333] NET: Registered protocol family 10
[    0.643824] mip6: Mobile IPv6
[    0.645084] NET: Registered protocol family 17
[    0.646337] Key type dns_resolver registered
[    0.647724] PM: Hibernation image not present or could not be loaded.
[    0.647735] registered taskstats version 1
[    0.649679] XENBUS: Device with no driver: device/vbd/768
[    0.650905] XENBUS: Device with no driver: device/vbd/5632
[    0.652099] XENBUS: Device with no driver: device/pci/0
[    0.653302] XENBUS: Device with no driver: device/vif/0
[    0.654508]   Magic number: 0:653:682
[    0.655758] rtc_cmos 00:06: setting system clock to 2012-10-31 11:39:09 =
UTC (1351683549)
[    0.734310] ata2.00: ATAPI: QEMU CD-ROM, 0.8.2, max UDMA/100
[    0.737067] ata2.00: configured for MWDMA2
[    0.740507] scsi 1:0:0:0: CD-ROM            QEMU     QEMU CD-ROM      0.=
8. PQ: 0 ANSI: 5
[    0.743836] ata2: drained 28 bytes to clear DRQ
[    0.743841] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 fr=
ozen
[    0.745072] ata2.00: BMDMA stat 0x5
[    0.746296] sr 1:0:0:0: CDB:
[    0.747495] Mode Sense(10): 5a 00 2a 00 00 00 00 00 80 00
[    0.748728] ata2.00: cmd a0/01:00:00:80:00/00:00:00:00:00/a0 tag 0 dma 1=
6512 in
[    0.748728]          res 48/00:02:00:1c:00/00:00:00:00:00/a0 Emask 0x2 (=
HSM violation)
[    0.751056] ata2.00: status: { DRDY DRQ }
[    0.752576] ata2: soft resetting link
[    0.900093] usb 1-2: new full-speed USB device number 2 using uhci_hcd
[    0.908193] ata2.00: configured for MWDMA2
[    0.909947] ata2: EH complete
[    0.911089] sr0: scsi-1 drive
[    0.912203] cdrom: Uniform CD-ROM driver Revision: 3.20
[    0.913431] sr 1:0:0:0: Attached scsi CD-ROM sr0
[    0.913907] sr 1:0:0:0: Attached scsi generic sg0 type 5
[    0.917115] Freeing unused kernel memory: 1016k freed
[    0.918435] Write protecting the kernel read-only data: 12288k
[    0.927222] Freeing unused kernel memory: 1936k freed
[    0.936163] Freeing unused kernel memory: 1464k freed
[    0.995483] dracut: dracut-018-98.git20120813.fc17
[    1.044758] udevd[118]: starting version 182
[    1.065510] input: ImExPS/2 Generic Explorer Mouse as /devices/platform/=
i8042/serio1/input/input1
[    1.118295] dracut: Starting plymouth daemon
[    1.312103] blkfront: xvda: barrier or flush: disabled
[    1.313300] vbd vbd-5632: 19 xenbus_dev_probe on device/vbd/5632
[    1.320460]  xvda: xvda1 xvda2
[    1.364359] usb 1-2: New USB device found, idVendor=3D0627, idProduct=3D=
0001
[    1.364364] usb 1-2: New USB device strings: Mfr=3D3, Product=3D2, Seria=
lNumber=3D1
[    1.364367] usb 1-2: Product: QEMU USB Tablet
[    1.364369] usb 1-2: Manufacturer: QEMU 0.8.2
[    1.364372] usb 1-2: SerialNumber: 1
[    1.518082] Refined TSC clocksource calibration: 2266.775 MHz.
[    1.518088] Switching to clocksource tsc
[    1.524582] input: QEMU 0.8.2 QEMU USB Tablet as /devices/pci0000:00/000=
0:00:01.3/usb1/1-2/1-2:1.0/input/input2
[    1.524691] hid-generic 0003:0627:0001.0001: input,hidraw0: USB HID v0.0=
1 Pointer [QEMU 0.8.2 QEMU USB Tablet] on usb-0000:00:01.3-2/input0
[    1.565662] dracut: Scanning devices xvda2  for LVM logical volumes vg_f=
17x64hvm01/lv_root vg_f17x64hvm01/lv_swap
[    1.576180] dracut: inactive '/dev/vg_f17x64hvm01/lv_swap' [1.97 GiB] in=
herit
[    1.576412] dracut: inactive '/dev/vg_f17x64hvm01/lv_root' [15.53 GiB] i=
nherit
[    1.726230] EXT4-fs (dm-1): mounted filesystem with ordered data mode. O=
pts: (null)
[    1.784148] dracut: Checking ext4: /dev/mapper/vg_f17x64hvm01-lv_root
[    1.784351] dracut: issuing e2fsck -a  /dev/mapper/vg_f17x64hvm01-lv_root
[    1.801138] dracut: /dev/mapper/vg_f17x64hvm01-lv_root: clean, 28180/101=
8000 files, 327793/4071424 blocks
[    1.802385] dracut: Remounting /dev/mapper/vg_f17x64hvm01-lv_root with -=
o ro
[    1.822950] EXT4-fs (dm-1): mounted filesystem with ordered data mode. O=
pts: (null)
[    1.854460] dracut: Mounted root filesystem /dev/mapper/vg_f17x64hvm01-l=
v_root
[    1.935263] dracut: Switching root


-- Pasi



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 11:48:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 11:48:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTWmN-0000mG-HL; Wed, 31 Oct 2012 11:48:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTWmM-0000mB-1D
	for xen-devel@lists.xensource.com; Wed, 31 Oct 2012 11:48:14 +0000
Received: from [85.158.138.51:64900] by server-8.bemta-3.messagelabs.com id
	3F/10-10525-DFF01905; Wed, 31 Oct 2012 11:48:13 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-4.tower-174.messagelabs.com!1351684092!28099890!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDY1MzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5184 invoked from network); 31 Oct 2012 11:48:12 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 31 Oct 2012 11:48:12 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 4AE1518D9;
	Wed, 31 Oct 2012 13:48:10 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id E183B20059; Wed, 31 Oct 2012 13:48:09 +0200 (EET)
Date: Wed, 31 Oct 2012 13:48:09 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= 
To: Olaf Hering 
Message-ID: <20121031114809.GB8912@reaktio.net>
References: <1351613105-24408-1-git-send-email-olaf@aepfle.de>
	<20121030181732.GZ8912@reaktio.net>
	<20121030182859.GA8775@aepfle.de>
	<1351672212.20470.7.camel@hastur.hellion.org.uk>
	<20121031092925.GA22587@aepfle.de>
	<20121031102128.GA8912@reaktio.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20121031102128.GA8912@reaktio.net>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "linux-kernel@vger.kernel.org" ,
	Jeremy Fitzhardinge ,
	"xen-devel@lists.xensource.com" ,
	Ian Campbell ,
	Konrad Rzeszutek Wilk 
Subject: Re: [Xen-devel] [PATCH] xen PVonHVM: require at least Xen 3.4 as
 dom0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Oct 31, 2012 at 12:21:28PM +0200, Pasi K=E4rkk=E4inen wrote:
> On Wed, Oct 31, 2012 at 10:29:25AM +0100, Olaf Hering wrote:
> > On Wed, Oct 31, Ian Campbell wrote:
> > =

> > > If I understand correctly this requirements comes from the need to
> > > support moving the shared info page in order to support kexec?
> > > =

> > > So could we do something more fine grained and limit only the kexec
> > > support (and therefore the movement of the SI into that range) to 3.4=
+?
> > =

> > Its not strictly about kexec. The other patch I sent out will place the
> > shared info page at 0xFE700000. If that range is not within a
> > E820_Reserved area and if the old hvmloader makes allocations within
> > that range, that other patch needs to be changed so that the shared info
> > page is done either at 0xFE700000 or within RESERVE_BRK (as it is done
> > currently).
> > =

> > Is the source code of that old RHEL available somewhere, did they patch
> > hvmloader at all? Providing a E820 map from a guest which was started on
> > such old dom0 would be a good start.
> > =

> =

> http://ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/os/SRPMS/xen=
-3.0.3-135.el5_8.5.src.rpm
> That's the userland, actual Xen hypervisor is in the kernel src.rpm.
> =

> I can provide a dmesg from a guest later today.
> =


dmesg from a Fedora 17 PVHVM guest with Linux 3.5.4, running on RHEL 5.8 Xe=
n dom0:



[    0.000000] Linux version 3.5.4-1.fc17.x86_64 (mockbuild@) (gcc version =
4.7.0 20120507 (Red Hat 4.7.0-5) (GCC) ) #1 SMP Mon Sep 17 15:03:59 UTC 2012
[    0.000000] Command line: BOOT_IMAGE=3D/vmlinuz-3.5.4-1.fc17.x86_64 root=
=3D/dev/mapper/vg_f17x64hvm01-lv_root ro rd.lvm.lv=3Dvg_f17x64hvm01/lv_root=
 rd.md=3D0 rd.dm=3D0 SYSFONT=3DT
rue KEYTABLE=3Dfi rd.luks=3D0 rd.lvm.lv=3Dvg_f17x64hvm01/lv_swap LANG=3Den_=
US.UTF-8 rhgb
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
[    0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reser=
ved
[    0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reser=
ved
[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000003fffabff] usable
[    0.000000] BIOS-e820: [mem 0x000000003fffac00-0x000000003fffffff] reser=
ved
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI 2.4 present.
[    0.000000] DMI: Red Hat HVM domU, BIOS 3.1.2-308.13.1.el5 09/27/2012
[    0.000000] Hypervisor detected: Xen HVM
[    0.000000] Xen version 3.1.
[    0.000000] Xen Platform PCI: I/O protocol version 1
[    0.000000] Netfront and the Xen platform PCI driver have been compiled =
for this kernel: unplug emulated NICs.
[    0.000000] Blkfront and the Xen platform PCI driver have been compiled =
for this kernel: unplug emulated disks.
[    0.000000] You might have to change the root device
[    0.000000] from /dev/hd[a-d] to /dev/xvd[a-d]
[    0.000000] in your root=3D kernel command line option
[    0.000000] HVMOP_pagetable_dying not supported
[    0.000000] e820: update [mem 0x00000000-0x0000ffff] usable =3D=3D> rese=
rved
[    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[    0.000000] No AGP bridge found
[    0.000000] e820: last_pfn =3D 0x3fffa max_arch_pfn =3D 0x400000000
[    0.000000] MTRR default type: uncachable
[    0.000000] MTRR fixed ranges enabled:
[    0.000000]   00000-9FFFF write-back
[    0.000000]   A0000-BFFFF uncachable
[    0.000000]   C0000-CBFFF write-protect
[    0.000000]   CC000-D3FFF write-back
[    0.000000]   D4000-EBFFF uncachable
[    0.000000]   EC000-FFFFF write-protect
[    0.000000] MTRR variable ranges enabled:
[    0.000000]   0 base 0000000000 mask FF80000000 write-back
[    0.000000]   1 base 0080000000 mask FFC0000000 write-back
[    0.000000]   2 base 00C0000000 mask FFF0000000 write-back
[    0.000000]   3 base 0100000000 mask FF00000000 write-back
[    0.000000]   4 base 0200000000 mask FE00000000 write-back
[    0.000000]   5 base 0400000000 mask FC00000000 write-back
[    0.000000]   6 base 0800000000 mask FC00000000 write-back
[    0.000000]   7 base 0C00000000 mask FFC0000000 write-back
[    0.000000]   8 disabled
[    0.000000]   9 disabled
[    0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x701060007=
0106
[    0.000000] e820: update [mem 0xd0000000-0xffffffff] usable =3D=3D> rese=
rved
[    0.000000] found SMP MP-table at [mem 0x000fccd0-0x000fccdf] mapped at =
[ffff8800000fccd0]
[    0.000000] initial memory mapped: [mem 0x00000000-0x1fffffff]
[    0.000000] Base memory trampoline at [ffff880000099000] 99000 size 24576
[    0.000000] init_memory_mapping: [mem 0x00000000-0x3fff9fff]
[    0.000000]  [mem 0x00000000-0x3fdfffff] page 2M
[    0.000000]  [mem 0x3fe00000-0x3fff9fff] page 4k
[    0.000000] kernel direct mapping tables up to 0x3fff9fff @ [mem 0x1fdfe=
000-0x1fffffff]
[    0.000000] RAMDISK: [mem 0x36398000-0x371c3fff]
[    0.000000] ACPI: RSDP 00000000000eb340 00024 (v02    Xen)
[    0.000000] ACPI: XSDT 00000000000eb2b0 00044 (v01    Xen      HVM 00000=
000 HVML 00000000)
[    0.000000] ACPI: FACP 00000000000eb0c0 000F4 (v04    Xen      HVM 00000=
000 HVML 00000000)
[    0.000000] ACPI: DSDT 00000000000ea050 00FEA (v02    Xen      HVM 00000=
000 INTL 20110413)
[    0.000000] ACPI: FACS 00000000000ea010 00040
[    0.000000] ACPI: APIC 00000000000eb1c0 00072 (v02    Xen      HVM 00000=
000 HVML 00000000)
[    0.000000] ACPI: HPET 00000000000eb240 00038 (v01    Xen      HVM 00000=
000 HVML 00000000)
[    0.000000] ACPI: SSDT 00000000000eb278 00038 (v02    Xen      HVM 00000=
000 HVML 00000000)
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] No NUMA configuration found
[    0.000000] Faking a node at [mem 0x0000000000000000-0x000000003fff9fff]
[    0.000000] Initmem setup node 0 [mem 0x00000000-0x3fff9fff]
[    0.000000]   NODE_DATA [mem 0x3ffe6000-0x3fff9fff]
[    0.000000]  [ffffea0000000000-ffffea0000ffffff] PMD -> [ffff88003e60000=
0-ffff88003f5fffff] on node 0
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x00010000-0x00ffffff]
[    0.000000]   DMA32    [mem 0x01000000-0xffffffff]
[    0.000000]   Normal   empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x00010000-0x0009efff]
[    0.000000]   node   0: [mem 0x00100000-0x3fff9fff]
[    0.000000] On node 0 totalpages: 262025
[    0.000000]   DMA zone: 64 pages used for memmap
[    0.000000]   DMA zone: 6 pages reserved
[    0.000000]   DMA zone: 3913 pages, LIFO batch:0
[    0.000000]   DMA32 zone: 4032 pages used for memmap
[    0.000000]   DMA32 zone: 254010 pages, LIFO batch:31
[    0.000000] ACPI: PM-Timer IO Port: 0x1f48
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[    0.000000] ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 1, version 17, address 0xfec00000, GSI 0-=
47
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 low level)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 7 global_irq 7 low level)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 low level)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 low level)
[    0.000000] ACPI: IRQ0 used by override.
[    0.000000] ACPI: IRQ2 used by override.
[    0.000000] ACPI: IRQ5 used by override.
[    0.000000] ACPI: IRQ7 used by override.
[    0.000000] ACPI: IRQ9 used by override.
[    0.000000] ACPI: IRQ10 used by override.
[    0.000000] ACPI: IRQ11 used by override.
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000
[    0.000000] SMP: Allowing 1 CPUs, 0 hotplug CPUs
[    0.000000] nr_irqs_gsi: 64
[    0.000000] PM: Registered nosave memory: 000000000009f000 - 00000000000=
a0000
[    0.000000] PM: Registered nosave memory: 00000000000a0000 - 00000000000=
e0000
[    0.000000] PM: Registered nosave memory: 00000000000e0000 - 00000000001=
00000
[    0.000000] e820: [mem 0x40000000-0xffffffff] available for PCI devices
[    0.000000] Booting paravirtualized kernel on Xen HVM
[    0.000000] setup_percpu: NR_CPUS:128 nr_cpumask_bits:128 nr_cpu_ids:1 n=
r_node_ids:1
[    0.000000] PERCPU: Embedded 28 pages/cpu @ffff88003fc00000 s83136 r8192=
 d23360 u2097152
[    0.000000] pcpu-alloc: s83136 r8192 d23360 u2097152 alloc=3D1*2097152
[    0.000000] pcpu-alloc: [0] 0
[    0.000000] Built 1 zonelists in Node order, mobility grouping on.  Tota=
l pages: 257923
[    0.000000] Policy zone: DMA32
[    0.000000] Kernel command line: BOOT_IMAGE=3D/vmlinuz-3.5.4-1.fc17.x86_=
64 root=3D/dev/mapper/vg_f17x64hvm01-lv_root ro rd.lvm.lv=3Dvg_f17x64hvm01/=
lv_root rd.md=3D0 rd.dm=3D0 SYSFONT=3DTrue KEYTABLE=3Dfi rd.luks=3D0 rd.lvm=
.lv=3Dvg_f17x64hvm01/lv_swap LANG=3Den_US.UTF-8 rhgb
[    0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    0.000000] __ex_table already sorted, skipping sort
[    0.000000] Checking aperture...
[    0.000000] No AGP bridge found
[    0.000000] Memory: 1000920k/1048552k available (6243k kernel code, 452k=
 absent, 47180k reserved, 6940k data, 1016k init)
[    0.000000] SLUB: Genslabs=3D15, HWalign=3D64, Order=3D0-3, MinObjects=
=3D0, CPUs=3D1, Nodes=3D1
[    0.000000] Hierarchical RCU implementation.
[    0.000000] NR_IRQS:8448 nr_irqs:256 16
[    0.000000] Console: colour dummy device 80x25
[    0.000000] console [tty0] enabled
[    0.000000] Cannot get hvm parameter 18: -22!
[    0.000000] allocated 4194304 bytes of page_cgroup
[    0.000000] please try 'cgroup_disable=3Dmemory' option if you don't wan=
t memory cgroups
[    0.000000] hpet clockevent registered
[    0.000000] Fast TSC calibration using PIT
[    0.000000] Detected 2266.865 MHz processor.
[    0.002002] Calibrating delay loop (skipped), value calculated using tim=
er frequency.. 4533.73 BogoMIPS (lpj=3D2266865)
[    0.002011] pid_max: default: 32768 minimum: 301
[    0.002042] Security Framework initialized
[    0.002051] SELinux:  Initializing.
[    0.002064] SELinux:  Starting in permissive mode
[    0.002246] Dentry cache hash table entries: 131072 (order: 8, 1048576 b=
ytes)
[    0.002574] Inode-cache hash table entries: 65536 (order: 7, 524288 byte=
s)
[    0.003077] Mount-cache hash table entries: 256
[    0.003313] Initializing cgroup subsys cpuacct
[    0.003320] Initializing cgroup subsys memory
[    0.003334] Initializing cgroup subsys devices
[    0.003339] Initializing cgroup subsys freezer
[    0.003343] Initializing cgroup subsys net_cls
[    0.003347] Initializing cgroup subsys blkio
[    0.003351] Initializing cgroup subsys perf_event
[    0.003453] mce: CPU supports 0 MCE banks
[    0.003693] SMP alternatives: switching to UP code
[    0.025713] Freeing SMP alternatives: 24k freed
[    0.025736] ACPI: Core revision 20120320
[    0.026449] ftrace: allocating 23073 entries in 91 pages
[    0.039831] ..TIMER: vector=3D0x30 apic1=3D0 pin1=3D2 apic2=3D-1 pin2=3D=
-1
[    0.049847] CPU0: Intel(R) Xeon(R) CPU           L5640  @ 2.27GHz steppi=
ng 02
[    0.049996] Performance Events: unsupported p6 CPU model 44 no PMU drive=
r, software events only.
[    0.049996] NMI watchdog: disabled (cpu0): hardware events not enabled
[    0.049996] Brought up 1 CPUs
[    0.049996] Total of 1 processors activated (4533.73 BogoMIPS).
[    0.051186] devtmpfs: initialized
[    0.052641] atomic64 test passed for x86-64 platform with CX8 and with S=
SE
[    0.052680] RTC time: 11:39:09, date: 10/31/12
[    0.052726] NET: Registered protocol family 16
[    0.053044] ACPI: bus type pci registered
[    0.053398] PCI: Using configuration type 1 for base access
[    0.054494] bio: create slab  at 0
[    0.054574] ACPI: Added _OSI(Module Device)
[    0.054579] ACPI: Added _OSI(Processor Device)
[    0.054583] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.054587] ACPI: Added _OSI(Processor Aggregator Device)
[    0.055150] ACPI: EC: Look up EC in DSDT
[    0.056561] ACPI: Interpreter enabled
[    0.056569] ACPI: (supports S0 S5)
[    0.056586] ACPI: Using IOAPIC for interrupt routing
[    0.058580] ACPI: No dock devices found.
[    0.058589] PCI: Using host bridge windows from ACPI; if necessary, use =
"pci=3Dnocrs" and report a bug
[    0.058623] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[    0.058662] pci_root PNP0A03:00: host bridge window [io  0x0000-0x0cf7]
[    0.058668] pci_root PNP0A03:00: host bridge window [io  0x0d00-0xffff]
[    0.058674] pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x00=
0bffff]
[    0.058680] pci_root PNP0A03:00: host bridge window [mem 0xf0000000-0xf4=
ffffff]
[    0.058719] PCI host bridge to bus 0000:00
[    0.058725] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7]
[    0.058730] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
[    0.058734] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bfff=
f]
[    0.058740] pci_bus 0000:00: root bus resource [mem 0xf0000000-0xf4fffff=
f]
[    0.058888] pci 0000:00:00.0: [8086:1237] type 00 class 0x060000
[    0.060341] pci 0000:00:01.0: [8086:7000] type 00 class 0x060100
[    0.062468] pci 0000:00:01.1: [8086:7010] type 00 class 0x010180
[    0.063798] pci 0000:00:01.1: reg 20: [io  0xc000-0xc00f]
[    0.064737] pci 0000:00:01.2: [8086:7113] type 00 class 0x068000
[    0.066604] pci 0000:00:01.2: quirk: [io  0x1f40-0x1f7f] claimed by PIIX=
4 ACPI
[    0.067167] pci 0000:00:01.3: [8086:7020] type 00 class 0x0c0300
[    0.068505] pci 0000:00:01.3: reg 20: [io  0xc020-0xc03f]
[    0.069531] pci 0000:00:02.0: [1013:00b8] type 00 class 0x030000
[    0.069840] pci 0000:00:02.0: reg 10: [mem 0xf0000000-0xf1ffffff pref]
[    0.070066] pci 0000:00:02.0: reg 14: [mem 0xf2000000-0xf2000fff]
[    0.071671] pci 0000:00:03.0: [5853:0001] type 00 class 0x010000
[    0.072032] pci 0000:00:03.0: reg 10: [io  0xc100-0xc1ff]
[    0.072275] pci 0000:00:03.0: reg 14: [mem 0xf3000000-0xf3ffffff pref]
[    0.074114] pci 0000:00:06.0: [8086:10ed] type 00 class 0x020000
[    0.075080] pci 0000:00:06.0: reg 10: [mem 0xf4020000-0xf4023fff 64bit]
[    0.076389] pci 0000:00:06.0: reg 1c: [mem 0xf4024000-0xf4027fff 64bit]
[    0.079467] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
[    0.079705]  pci0000:00: Unable to request _OSC control (_OSC support ma=
sk: 0x1e)
[    0.083474] ACPI: PCI Interrupt Link [LNKA] (IRQs *5 7 10 11)
[    0.083650] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *7 10 11)
[    0.083822] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 7 *10 11)
[    0.084068] ACPI: PCI Interrupt Link [LNKD] (IRQs 5 7 10 *11)
[    0.084195] xen/balloon: Initialising balloon driver.
[    0.084212] xen-balloon: Initialising balloon driver.
[    0.084340] vgaarb: device added: PCI:0000:00:02.0,decodes=3Dio+mem,owns=
=3Dio+mem,locks=3Dnone
[    0.084348] vgaarb: loaded
[    0.084351] vgaarb: bridge control possible 0000:00:02.0
[    0.084431] SCSI subsystem initialized
[    0.084468] libata version 3.00 loaded.
[    0.084501] ACPI: bus type usb registered
[    0.084524] usbcore: registered new interface driver usbfs
[    0.084537] usbcore: registered new interface driver hub
[    0.084562] usbcore: registered new device driver usb
[    0.084626] PCI: Using ACPI for IRQ routing
[    0.084631] PCI: pci_cache_line_size set to 64 bytes
[    0.085209] e820: reserve RAM buffer [mem 0x0009fc00-0x0009ffff]
[    0.085212] e820: reserve RAM buffer [mem 0x3fffac00-0x3fffffff]
[    0.085323] NetLabel: Initializing
[    0.085328] NetLabel:  domain hash size =3D 128
[    0.085331] NetLabel:  protocols =3D UNLABELED CIPSOv4
[    0.085344] NetLabel:  unlabeled traffic allowed by default
[    0.085416] HPET: 3 timers in total, 0 timers will be used for per-cpu t=
imer
[    0.085431] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
[    0.085438] hpet0: 3 comparators, 64-bit 70.836816 MHz counter
[    0.088026] Switching to clocksource hpet
[    0.096355] pnp: PnP ACPI init
[    0.096371] ACPI: bus type pnp registered
[    0.096392] pnp 00:00: [mem 0x00000000-0x0009ffff]
[    0.096425] system 00:00: [mem 0x00000000-0x0009ffff] could not be reser=
ved
[    0.096433] system 00:00: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.096465] pnp 00:01: [bus 00-ff]
[    0.096468] pnp 00:01: [io  0x0cf8-0x0cff]
[    0.096471] pnp 00:01: [io  0x0000-0x0cf7 window]
[    0.096473] pnp 00:01: [io  0x0d00-0xffff window]
[    0.096476] pnp 00:01: [mem 0x000a0000-0x000bffff window]
[    0.096479] pnp 00:01: [mem 0xf0000000-0xf4ffffff]
[    0.096503] pnp 00:01: Plug and Play ACPI device, IDs PNP0a03 (active)
[    0.096513] pnp 00:02: [io  0x10c0-0x10c2]
[    0.096516] pnp 00:02: [io  0xb044-0xb047]
[    0.096545] system 00:02: [io  0x10c0-0x10c2] has been reserved
[    0.096551] system 00:02: [io  0xb044-0xb047] has been reserved
[    0.096557] system 00:02: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.096811] pnp 00:03: [mem 0xfed00000-0xfed003ff]
[    0.096835] pnp 00:03: Plug and Play ACPI device, IDs PNP0103 (active)
[    0.096857] pnp 00:04: [io  0x0010-0x001f]
[    0.096859] pnp 00:04: [io  0x0022-0x002d]
[    0.096862] pnp 00:04: [io  0x0030-0x003f]
[    0.096864] pnp 00:04: [io  0x0044-0x005f]
[    0.096866] pnp 00:04: [io  0x0062-0x0063]
[    0.096868] pnp 00:04: [io  0x0065-0x006f]
[    0.096871] pnp 00:04: [io  0x0072-0x007f]
[    0.096873] pnp 00:04: [io  0x0080]
[    0.096875] pnp 00:04: [io  0x0084-0x0086]
[    0.096877] pnp 00:04: [io  0x0088]
[    0.096879] pnp 00:04: [io  0x008c-0x008e]
[    0.096882] pnp 00:04: [io  0x0090-0x009f]
[    0.096884] pnp 00:04: [io  0x00a2-0x00bd]
[    0.096886] pnp 00:04: [io  0x00e0-0x00ef]
[    0.096888] pnp 00:04: [io  0x08a0-0x08a3]
[    0.096891] pnp 00:04: [io  0x0cc0-0x0ccf]
[    0.096893] pnp 00:04: [io  0x04d0-0x04d1]
[    0.096932] system 00:04: [io  0x08a0-0x08a3] has been reserved
[    0.096939] system 00:04: [io  0x0cc0-0x0ccf] has been reserved
[    0.096944] system 00:04: [io  0x04d0-0x04d1] has been reserved
[    0.096950] system 00:04: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.096964] pnp 00:05: [dma 4]
[    0.096966] pnp 00:05: [io  0x0000-0x000f]
[    0.096969] pnp 00:05: [io  0x0081-0x0083]
[    0.096971] pnp 00:05: [io  0x0087]
[    0.096973] pnp 00:05: [io  0x0089-0x008b]
[    0.096976] pnp 00:05: [io  0x008f]
[    0.096978] pnp 00:05: [io  0x00c0-0x00df]
[    0.096980] pnp 00:05: [io  0x0480-0x048f]
[    0.097002] pnp 00:05: Plug and Play ACPI device, IDs PNP0200 (active)
[    0.097063] pnp 00:06: [io  0x0070-0x0071]
[    0.097084] pnp 00:06: [irq 8]
[    0.097115] pnp 00:06: Plug and Play ACPI device, IDs PNP0b00 (active)
[    0.097125] pnp 00:07: [io  0x0061]
[    0.097147] pnp 00:07: Plug and Play ACPI device, IDs PNP0800 (active)
[    0.097185] pnp 00:08: [irq 12]
[    0.097212] pnp 00:08: Plug and Play ACPI device, IDs PNP0f13 (active)
[    0.097230] pnp 00:09: [io  0x0060]
[    0.097232] pnp 00:09: [io  0x0064]
[    0.097251] pnp 00:09: [irq 1]
[    0.097279] pnp 00:09: Plug and Play ACPI device, IDs PNP0303 PNP030b (a=
ctive)
[    0.097299] pnp 00:0a: [io  0x03f0-0x03f5]
[    0.097301] pnp 00:0a: [io  0x03f7]
[    0.097319] pnp 00:0a: [irq 6]
[    0.097322] pnp 00:0a: [dma 2]
[    0.097346] pnp 00:0a: Plug and Play ACPI device, IDs PNP0700 (active)
[    0.097372] pnp 00:0b: [io  0x03f8-0x03ff]
[    0.097391] pnp 00:0b: [irq 4]
[    0.097419] pnp 00:0b: Plug and Play ACPI device, IDs PNP0501 (active)
[    0.097565] pnp: PnP ACPI: found 12 devices
[    0.097570] ACPI: ACPI bus type pnp unregistered
[    0.103895] pci_bus 0000:00: resource 4 [io  0x0000-0x0cf7]
[    0.103899] pci_bus 0000:00: resource 5 [io  0x0d00-0xffff]
[    0.103902] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff]
[    0.103904] pci_bus 0000:00: resource 7 [mem 0xf0000000-0xf4ffffff]
[    0.103942] NET: Registered protocol family 2
[    0.104059] IP route cache hash table entries: 32768 (order: 6, 262144 b=
ytes)
[    0.104396] TCP established hash table entries: 131072 (order: 9, 209715=
2 bytes)
[    0.104917] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[    0.105164] TCP: Hash tables configured (established 131072 bind 65536)
[    0.105169] TCP: reno registered
[    0.105178] UDP hash table entries: 512 (order: 2, 16384 bytes)
[    0.105191] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
[    0.105254] NET: Registered protocol family 1
[    0.105268] pci 0000:00:00.0: Limiting direct PCI/PCI transfers
[    0.105329] pci 0000:00:01.0: PIIX3: Enabling Passive Release
[    0.105405] pci 0000:00:01.0: Activating ISA DMA hang workarounds
[    0.105882] pci 0000:00:02.0: Boot video device
[    0.106032] PCI: CLS 0 bytes, default 64
[    0.106076] Unpacking initramfs...
[    0.514071] Freeing initrd memory: 14512k freed
[    0.520187] alg: No test for __gcm-aes-aesni (__driver-gcm-aes-aesni)
[    0.520475] audit: initializing netlink socket (disabled)
[    0.520493] type=3D2000 audit(1351683549.519:1): initialized
[    0.548550] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[    0.550379] VFS: Disk quotas dquot_6.5.2
[    0.550435] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    0.550892] msgmni has been set to 1983
[    0.550959] SELinux:  Registering netfilter hooks
[    0.551447] alg: No test for stdrng (krng)
[    0.551455] NET: Registered protocol family 38
[    0.551501] Block layer SCSI generic (bsg) driver version 0.4 loaded (ma=
jor 252)
[    0.551540] io scheduler noop registered
[    0.551544] io scheduler deadline registered
[    0.551580] io scheduler cfq registered (default)
[    0.551684] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[    0.551709] pciehp: PCI Express Hot Plug Controller Driver version: 0.4
[    0.551714] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
[    0.551777] acpiphp: Slot [1] registered
[    0.551797] acpiphp: Slot [2] registered
[    0.551909] efifb: probing for efifb
[    0.552061] efifb: framebuffer at 0xf0000000, mapped to 0xffffc900005000=
00, using 1408k, total 1408k
[    0.552068] efifb: mode is 800x600x24, linelength=3D2400, pages=3D1
[    0.552071] efifb: scrolling: redraw
[    0.552075] efifb: Truecolor: size=3D0:8:8:8, shift=3D0:16:8:0
[    0.554963] Console: switching to colour frame buffer device 100x37
[    0.557505] fb0: EFI VGA frame buffer device
[    0.557558] intel_idle: does not run on family 6 model 44
[    0.559150] GHES: HEST is not enabled!
[    0.560329] Grant tables using version 1 layout.
[    0.561053] Grant table initialized
[    0.563974] Cannot get hvm parameter 18: -22!
[    0.564057] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    0.564761] serial8250: ttyS0 at I/O 0x3f8 (irq =3D 4) is a 16450
[    0.567223] 00:0b: ttyS0 at I/O 0x3f8 (irq =3D 4) is a 16450
[    0.568715] Non-volatile memory driver v1.3
[    0.569901] Linux agpgart interface v0.103
[    0.571940] loop: module loaded
[    0.573169] ata_piix 0000:00:01.1: version 2.13
[    0.573412] ata_piix 0000:00:01.1: setting latency timer to 64
[    0.573953] scsi0 : ata_piix
[    0.575153] scsi1 : ata_piix
[    0.576294] ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xc000 irq 14
[    0.577438] ata2: PATA max MWDMA2 cmd 0x170 ctl 0x376 bmdma 0xc008 irq 15
[    0.579517] Fixed MDIO Bus: probed
[    0.581517] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    0.582644] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    0.583781] uhci_hcd: USB Universal Host Controller Interface driver
[    0.585135] uhci_hcd 0000:00:01.3: setting latency timer to 64
[    0.585173] uhci_hcd 0000:00:01.3: UHCI Host Controller
[    0.586346] uhci_hcd 0000:00:01.3: new USB bus registered, assigned bus =
number 1
[    0.587784] uhci_hcd 0000:00:01.3: irq 23, io base 0x0000c020
[    0.589922] usb usb1: New USB device found, idVendor=3D1d6b, idProduct=
=3D0001
[    0.591061] usb usb1: New USB device strings: Mfr=3D3, Product=3D2, Seri=
alNumber=3D1
[    0.592231] usb usb1: Product: UHCI Host Controller
[    0.593403] usb usb1: Manufacturer: Linux 3.5.4-1.fc17.x86_64 uhci_hcd
[    0.594585] usb usb1: SerialNumber: 0000:00:01.3
[    0.595842] hub 1-0:1.0: USB hub found
[    0.597033] hub 1-0:1.0: 2 ports detected
[    0.598354] usbcore: registered new interface driver usbserial
[    0.599501] usbcore: registered new interface driver usbserial_generic
[    0.600611] USB Serial support registered for generic
[    0.601705] usbserial: USB Serial Driver core
[    0.602837] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0=
x60,0x64 irq 1,12
[    0.606311] serio: i8042 KBD port at 0x60,0x64 irq 1
[    0.607478] serio: i8042 AUX port at 0x60,0x64 irq 12
[    0.608710] mousedev: PS/2 mouse device common for all mice
[    0.610891] input: AT Translated Set 2 keyboard as /devices/platform/i80=
42/serio0/input/input0
[    0.618267] rtc_cmos 00:06: rtc core: registered rtc_cmos as rtc0
[    0.619536] rtc0: alarms up to one day, 114 bytes nvram, hpet irqs
[    0.626404] device-mapper: uevent: version 1.0.3
[    0.629046] device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised:=
 dm-devel@redhat.com
[    0.630380] cpuidle: using governor ladder
[    0.631644] cpuidle: using governor menu
[    0.632955] EFI Variables Facility v0.08 2004-May-17
[    0.634343] usbcore: registered new interface driver usbhid
[    0.635674] usbhid: USB HID core driver
[    0.636960] drop_monitor: Initializing network drop monitor service
[    0.638351] ip_tables: (C) 2000-2006 Netfilter Core Team
[    0.639670] TCP: cubic registered
[    0.640945] Initializing XFRM netlink socket
[    0.642333] NET: Registered protocol family 10
[    0.643824] mip6: Mobile IPv6
[    0.645084] NET: Registered protocol family 17
[    0.646337] Key type dns_resolver registered
[    0.647724] PM: Hibernation image not present or could not be loaded.
[    0.647735] registered taskstats version 1
[    0.649679] XENBUS: Device with no driver: device/vbd/768
[    0.650905] XENBUS: Device with no driver: device/vbd/5632
[    0.652099] XENBUS: Device with no driver: device/pci/0
[    0.653302] XENBUS: Device with no driver: device/vif/0
[    0.654508]   Magic number: 0:653:682
[    0.655758] rtc_cmos 00:06: setting system clock to 2012-10-31 11:39:09 =
UTC (1351683549)
[    0.734310] ata2.00: ATAPI: QEMU CD-ROM, 0.8.2, max UDMA/100
[    0.737067] ata2.00: configured for MWDMA2
[    0.740507] scsi 1:0:0:0: CD-ROM            QEMU     QEMU CD-ROM      0.=
8. PQ: 0 ANSI: 5
[    0.743836] ata2: drained 28 bytes to clear DRQ
[    0.743841] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 fr=
ozen
[    0.745072] ata2.00: BMDMA stat 0x5
[    0.746296] sr 1:0:0:0: CDB:
[    0.747495] Mode Sense(10): 5a 00 2a 00 00 00 00 00 80 00
[    0.748728] ata2.00: cmd a0/01:00:00:80:00/00:00:00:00:00/a0 tag 0 dma 1=
6512 in
[    0.748728]          res 48/00:02:00:1c:00/00:00:00:00:00/a0 Emask 0x2 (=
HSM violation)
[    0.751056] ata2.00: status: { DRDY DRQ }
[    0.752576] ata2: soft resetting link
[    0.900093] usb 1-2: new full-speed USB device number 2 using uhci_hcd
[    0.908193] ata2.00: configured for MWDMA2
[    0.909947] ata2: EH complete
[    0.911089] sr0: scsi-1 drive
[    0.912203] cdrom: Uniform CD-ROM driver Revision: 3.20
[    0.913431] sr 1:0:0:0: Attached scsi CD-ROM sr0
[    0.913907] sr 1:0:0:0: Attached scsi generic sg0 type 5
[    0.917115] Freeing unused kernel memory: 1016k freed
[    0.918435] Write protecting the kernel read-only data: 12288k
[    0.927222] Freeing unused kernel memory: 1936k freed
[    0.936163] Freeing unused kernel memory: 1464k freed
[    0.995483] dracut: dracut-018-98.git20120813.fc17
[    1.044758] udevd[118]: starting version 182
[    1.065510] input: ImExPS/2 Generic Explorer Mouse as /devices/platform/=
i8042/serio1/input/input1
[    1.118295] dracut: Starting plymouth daemon
[    1.312103] blkfront: xvda: barrier or flush: disabled
[    1.313300] vbd vbd-5632: 19 xenbus_dev_probe on device/vbd/5632
[    1.320460]  xvda: xvda1 xvda2
[    1.364359] usb 1-2: New USB device found, idVendor=3D0627, idProduct=3D=
0001
[    1.364364] usb 1-2: New USB device strings: Mfr=3D3, Product=3D2, Seria=
lNumber=3D1
[    1.364367] usb 1-2: Product: QEMU USB Tablet
[    1.364369] usb 1-2: Manufacturer: QEMU 0.8.2
[    1.364372] usb 1-2: SerialNumber: 1
[    1.518082] Refined TSC clocksource calibration: 2266.775 MHz.
[    1.518088] Switching to clocksource tsc
[    1.524582] input: QEMU 0.8.2 QEMU USB Tablet as /devices/pci0000:00/000=
0:00:01.3/usb1/1-2/1-2:1.0/input/input2
[    1.524691] hid-generic 0003:0627:0001.0001: input,hidraw0: USB HID v0.0=
1 Pointer [QEMU 0.8.2 QEMU USB Tablet] on usb-0000:00:01.3-2/input0
[    1.565662] dracut: Scanning devices xvda2  for LVM logical volumes vg_f=
17x64hvm01/lv_root vg_f17x64hvm01/lv_swap
[    1.576180] dracut: inactive '/dev/vg_f17x64hvm01/lv_swap' [1.97 GiB] in=
herit
[    1.576412] dracut: inactive '/dev/vg_f17x64hvm01/lv_root' [15.53 GiB] i=
nherit
[    1.726230] EXT4-fs (dm-1): mounted filesystem with ordered data mode. O=
pts: (null)
[    1.784148] dracut: Checking ext4: /dev/mapper/vg_f17x64hvm01-lv_root
[    1.784351] dracut: issuing e2fsck -a  /dev/mapper/vg_f17x64hvm01-lv_root
[    1.801138] dracut: /dev/mapper/vg_f17x64hvm01-lv_root: clean, 28180/101=
8000 files, 327793/4071424 blocks
[    1.802385] dracut: Remounting /dev/mapper/vg_f17x64hvm01-lv_root with -=
o ro
[    1.822950] EXT4-fs (dm-1): mounted filesystem with ordered data mode. O=
pts: (null)
[    1.854460] dracut: Mounted root filesystem /dev/mapper/vg_f17x64hvm01-l=
v_root
[    1.935263] dracut: Switching root


-- Pasi



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 12:36:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 12:36:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTXWj-0001bM-1b; Wed, 31 Oct 2012 12:36:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTXWh-0001bH-Rk
	for xen-devel@lists.xensource.com; Wed, 31 Oct 2012 12:36:08 +0000
Received: from [85.158.143.35:2763] by server-3.bemta-4.messagelabs.com id
	EA/0C-06841-73B11905; Wed, 31 Oct 2012 12:36:07 +0000
X-Env-Sender: syi@websense.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1351686954!5427786!1
X-Originating-IP: [208.87.234.190]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljg3LjIzNC4xOTAgPT4gMTUzODQ2Ng==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23592 invoked from network); 31 Oct 2012 12:35:56 -0000
Received: from cluster-h.mailcontrol.com (HELO cluster-h.mailcontrol.com)
	(208.87.234.190)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 31 Oct 2012 12:35:56 -0000
Received: from ssdwbsnapp.websense.com (static-204-15-65-158.websense.com
	[204.15.65.158] (may be forged))
	by rly24h.srv.mailcontrol.com (MailControl) with ESMTP id
	q9VCZp1o000984
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 31 Oct 2012 12:35:52 GMT
Received: from SSDEXCH1A.websense.com (unknown [10.8.1.91])
	by Websense Email Security Gateway with ESMTP id 509771000011;
	Wed, 31 Oct 2012 05:35:48 -0700 (PDT)
Received: from ssdexch3b.websense.com (10.8.3.134) by SSDEXCH1A.websense.com
	(10.8.1.91) with Microsoft SMTP Server (TLS) id 14.2.283.3;
	Wed, 31 Oct 2012 05:35:51 -0700
Received: from SBJEXCH2A.websense.com (10.32.8.111) by ssdexch3b.websense.com
	(10.8.3.169) with Microsoft SMTP Server (TLS) id 14.2.283.3;
	Wed, 31 Oct 2012 05:35:51 -0700
Received: from SBJEXCH1A.websense.com ([169.254.1.38]) by
	SBJEXCH2A.websense.com ([::1]) with mapi id 14.02.0283.003;
	Wed, 31 Oct 2012 20:35:47 +0800
From: "Yi, Shunli" 
To: Ian Campbell 
Thread-Topic: [Xen-devel] Xennet half die---netfront TX queue was stopped.
Thread-Index: Ac23Gm/GoGh3r8OSR5q8PANust8HvP//1MaA//9zFJCAAJ/7AIAAqQ36
Date: Wed, 31 Oct 2012 12:35:46 +0000
Message-ID: <961EE662BA396D43898AFA993C8F01B77505AD2B@SBJEXCH1A.websense.com>
References: <961EE662BA396D43898AFA993C8F01B77174A010@SBJEXCH1A.websense.com>
	<1351674761.25014.0.camel@hastur.hellion.org.uk>
	<961EE662BA396D43898AFA993C8F01B775058CBE@SBJEXCH1A.websense.com>,
	<1351678854.25014.7.camel@hastur.hellion.org.uk>
In-Reply-To: <1351678854.25014.7.camel@hastur.hellion.org.uk>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.64.80.131]
MIME-Version: 1.0
X-Scanned-By: MailControl 10515.0 (www.mailcontrol.com) on 10.72.0.134
Cc: "xen-devel@lists.xensource.com" 
Subject: [Xen-devel] =?big5?b?tarOYDogIFhlbm5ldCBoYWxmIGRpZS0tLW5ldGZyb250?=
 =?big5?b?IFRYIHF1ZXVlIHdhcyBzdG9wcGVkLg==?=
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>> Ian,
>> Thanks for your information.
>> And sorry for writing a wrong kernel version by mistake, we are using
>> 2.6.18.8,

>2.6.18.8 is even more ancient.

>>  which was downloaded from Xen.org when got Xen-3.4.2 release.

>Well, 3.4.2 is also pretty old too.

>In general there is no requirement to use the kernel which is supplied
>with a given version of Xen (we don't even supply one any more). So
>there is no real reason to stick with the 2.6.18 that happened to come
>with 3.4.2.

>You should upgrade at least your kernel as I suggested.

Yes, I agree and we are planning to migrate to the newer version(include the Xen and kernel).
But before that, I'm still trying to find a quick fix for that. 


Thanks for your time . ^_^

-Shunli



 Protected by Websense Hosted Email Security -- www.websense.com 
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 12:36:36 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 12:36:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTXWj-0001bM-1b; Wed, 31 Oct 2012 12:36:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTXWh-0001bH-Rk
	for xen-devel@lists.xensource.com; Wed, 31 Oct 2012 12:36:08 +0000
Received: from [85.158.143.35:2763] by server-3.bemta-4.messagelabs.com id
	EA/0C-06841-73B11905; Wed, 31 Oct 2012 12:36:07 +0000
X-Env-Sender: syi@websense.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1351686954!5427786!1
X-Originating-IP: [208.87.234.190]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljg3LjIzNC4xOTAgPT4gMTUzODQ2Ng==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23592 invoked from network); 31 Oct 2012 12:35:56 -0000
Received: from cluster-h.mailcontrol.com (HELO cluster-h.mailcontrol.com)
	(208.87.234.190)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 31 Oct 2012 12:35:56 -0000
Received: from ssdwbsnapp.websense.com (static-204-15-65-158.websense.com
	[204.15.65.158] (may be forged))
	by rly24h.srv.mailcontrol.com (MailControl) with ESMTP id
	q9VCZp1o000984
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 31 Oct 2012 12:35:52 GMT
Received: from SSDEXCH1A.websense.com (unknown [10.8.1.91])
	by Websense Email Security Gateway with ESMTP id 509771000011;
	Wed, 31 Oct 2012 05:35:48 -0700 (PDT)
Received: from ssdexch3b.websense.com (10.8.3.134) by SSDEXCH1A.websense.com
	(10.8.1.91) with Microsoft SMTP Server (TLS) id 14.2.283.3;
	Wed, 31 Oct 2012 05:35:51 -0700
Received: from SBJEXCH2A.websense.com (10.32.8.111) by ssdexch3b.websense.com
	(10.8.3.169) with Microsoft SMTP Server (TLS) id 14.2.283.3;
	Wed, 31 Oct 2012 05:35:51 -0700
Received: from SBJEXCH1A.websense.com ([169.254.1.38]) by
	SBJEXCH2A.websense.com ([::1]) with mapi id 14.02.0283.003;
	Wed, 31 Oct 2012 20:35:47 +0800
From: "Yi, Shunli" 
To: Ian Campbell 
Thread-Topic: [Xen-devel] Xennet half die---netfront TX queue was stopped.
Thread-Index: Ac23Gm/GoGh3r8OSR5q8PANust8HvP//1MaA//9zFJCAAJ/7AIAAqQ36
Date: Wed, 31 Oct 2012 12:35:46 +0000
Message-ID: <961EE662BA396D43898AFA993C8F01B77505AD2B@SBJEXCH1A.websense.com>
References: <961EE662BA396D43898AFA993C8F01B77174A010@SBJEXCH1A.websense.com>
	<1351674761.25014.0.camel@hastur.hellion.org.uk>
	<961EE662BA396D43898AFA993C8F01B775058CBE@SBJEXCH1A.websense.com>,
	<1351678854.25014.7.camel@hastur.hellion.org.uk>
In-Reply-To: <1351678854.25014.7.camel@hastur.hellion.org.uk>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.64.80.131]
MIME-Version: 1.0
X-Scanned-By: MailControl 10515.0 (www.mailcontrol.com) on 10.72.0.134
Cc: "xen-devel@lists.xensource.com" 
Subject: [Xen-devel] =?big5?b?tarOYDogIFhlbm5ldCBoYWxmIGRpZS0tLW5ldGZyb250?=
 =?big5?b?IFRYIHF1ZXVlIHdhcyBzdG9wcGVkLg==?=
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>> Ian,
>> Thanks for your information.
>> And sorry for writing a wrong kernel version by mistake, we are using
>> 2.6.18.8,

>2.6.18.8 is even more ancient.

>>  which was downloaded from Xen.org when got Xen-3.4.2 release.

>Well, 3.4.2 is also pretty old too.

>In general there is no requirement to use the kernel which is supplied
>with a given version of Xen (we don't even supply one any more). So
>there is no real reason to stick with the 2.6.18 that happened to come
>with 3.4.2.

>You should upgrade at least your kernel as I suggested.

Yes, I agree and we are planning to migrate to the newer version(include the Xen and kernel).
But before that, I'm still trying to find a quick fix for that. 


Thanks for your time . ^_^

-Shunli



 Protected by Websense Hosted Email Security -- www.websense.com 
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 14:05:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 14:05:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTYuG-0002mg-9E; Wed, 31 Oct 2012 14:04:32 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTYuF-0002mb-Hv
	for xen-devel@lists.xen.org; Wed, 31 Oct 2012 14:04:31 +0000
Received: from [193.109.254.147:26365] by server-15.bemta-14.messagelabs.com
	id 05/1D-12105-EEF21905; Wed, 31 Oct 2012 14:04:30 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1351692268!9196335!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODMwODE2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5629 invoked from network); 31 Oct 2012 14:04:30 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 31 Oct 2012 14:04:30 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9VE4Mrg019050
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 31 Oct 2012 14:04:23 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9VE4MhN028809
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 31 Oct 2012 14:04:22 GMT
Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9VE4LrT023105; Wed, 31 Oct 2012 09:04:22 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 31 Oct 2012 07:04:21 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 0170F40364; Wed, 31 Oct 2012 09:51:50 -0400 (EDT)
Date: Wed, 31 Oct 2012 09:51:50 -0400
From: Konrad Rzeszutek Wilk 
To: "Liu, Jinsong" 
Message-ID: <20121031135150.GA28699@phenom.dumpdata.com>
References: 
	<508A89CB020000780008E6ED@nat28.tlf.novell.com>
	
	
	<20121026201409.GF2708@phenom.dumpdata.com>
	
	<20121029123950.GK2708@phenom.dumpdata.com>
	
	<20121030133720.GA27463@phenom.dumpdata.com>
	
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Konrad Rzeszutek Wilk ,
	"linux-kernel@vger.kernel.org" ,
	Jan Beulich ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 1/2] Xen acpi pad implement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 30, 2012 at 03:18:59PM +0000, Liu, Jinsong wrote:
> Konrad Rzeszutek Wilk wrote:
> >>> +config XEN_ACPI_PAD_STUB
> >>> +	bool
> >>> +	depends on XEN_DOM0 && X86_64 && ACPI
> >>> +	default n
> >>> +
> >> 
> >> This Kconfig is pointless, if CONFIG_XEN_ACPI_PAD_STUB = n, native
> >> pad would successfully registerred, and then mwait #UD (we would
> >> revert df88b2d96e36d9a9e325bfcd12eb45671cbbc937, right?). So xen
> >> stub logic should unconditionally built-in kernel.   
> > 
> > 
> > Potentially. Keep in mind that there is no need to built this if the
> > kernel is not built with ACPI.
> 
> Sure, 'obj-$(CONFIG_XEN_DOM0) +=' is enough.
> (XEN_DOM0 depends on ACPI).
> 
> >>> +subsys_initcall(xen_acpi_pad_stub_init);
> >> 
> >> I'm still confused. In this way there are xen-acpi-pad-stub.c and
> >> xen-acpi-pad.c, and you want to let xen-acpi-pad loaded as module,
> >> right? how can xen-acpi-pad logic work when it was insmoded?  
> > 
> > Via the register/unregister calls that this provides? Or does ACPI bus
> > drivers get immediately called once the call acpi_bus_register_driver?
> 
> But when xen stub driver registerred, real xen pad ops has not been hooked to stub ops.
> 
> > 
> > Or can one 'poke' the 'add' and 'remove' calls so that once the "true"
> > PAD driver is loaded it will restart the ops->add call?
> 
> I think we'd better not to use xen pad stub approach. Technically it's complicated, say, how to match xen_acpi_pad driver w/ pad device? when and how to invoke .add method? how to avoid native pad loading risk? etc. I didn't find its obivous advantages, so how about keep simpler approach?

OK. Lets go with that one for right now. The one thing I don't like about it is
that it is built-in. It would be so much better if it was a module, but I am just
not sure how to make that work with the acpi_pad. Unless the mwait CPUID capability
is not exported (so drop your patch 1 that reverts a commit).

Perhaps there is a way to make it a module/built-in with some Kconfig
magic options? Say if ACPI_PROCESSOR_AGGREGATOR is not set, then we can
make it a module. But if ACPI_PROCESSOR_AGGREGATOR=m|y then we do it
as built-in?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 14:05:05 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 14:05:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTYuG-0002mg-9E; Wed, 31 Oct 2012 14:04:32 +0000
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTYuF-0002mb-Hv
	for xen-devel@lists.xen.org; Wed, 31 Oct 2012 14:04:31 +0000
Received: from [193.109.254.147:26365] by server-15.bemta-14.messagelabs.com
	id 05/1D-12105-EEF21905; Wed, 31 Oct 2012 14:04:30 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1351692268!9196335!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gODMwODE2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5629 invoked from network); 31 Oct 2012 14:04:30 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 31 Oct 2012 14:04:30 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9VE4Mrg019050
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 31 Oct 2012 14:04:23 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9VE4MhN028809
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 31 Oct 2012 14:04:22 GMT
Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9VE4LrT023105; Wed, 31 Oct 2012 09:04:22 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 31 Oct 2012 07:04:21 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 0170F40364; Wed, 31 Oct 2012 09:51:50 -0400 (EDT)
Date: Wed, 31 Oct 2012 09:51:50 -0400
From: Konrad Rzeszutek Wilk 
To: "Liu, Jinsong" 
Message-ID: <20121031135150.GA28699@phenom.dumpdata.com>
References: 
	<508A89CB020000780008E6ED@nat28.tlf.novell.com>
	
	
	<20121026201409.GF2708@phenom.dumpdata.com>
	
	<20121029123950.GK2708@phenom.dumpdata.com>
	
	<20121030133720.GA27463@phenom.dumpdata.com>
	
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Konrad Rzeszutek Wilk ,
	"linux-kernel@vger.kernel.org" ,
	Jan Beulich ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 1/2] Xen acpi pad implement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Oct 30, 2012 at 03:18:59PM +0000, Liu, Jinsong wrote:
> Konrad Rzeszutek Wilk wrote:
> >>> +config XEN_ACPI_PAD_STUB
> >>> +	bool
> >>> +	depends on XEN_DOM0 && X86_64 && ACPI
> >>> +	default n
> >>> +
> >> 
> >> This Kconfig is pointless, if CONFIG_XEN_ACPI_PAD_STUB = n, native
> >> pad would successfully registerred, and then mwait #UD (we would
> >> revert df88b2d96e36d9a9e325bfcd12eb45671cbbc937, right?). So xen
> >> stub logic should unconditionally built-in kernel.   
> > 
> > 
> > Potentially. Keep in mind that there is no need to built this if the
> > kernel is not built with ACPI.
> 
> Sure, 'obj-$(CONFIG_XEN_DOM0) +=' is enough.
> (XEN_DOM0 depends on ACPI).
> 
> >>> +subsys_initcall(xen_acpi_pad_stub_init);
> >> 
> >> I'm still confused. In this way there are xen-acpi-pad-stub.c and
> >> xen-acpi-pad.c, and you want to let xen-acpi-pad loaded as module,
> >> right? how can xen-acpi-pad logic work when it was insmoded?  
> > 
> > Via the register/unregister calls that this provides? Or does ACPI bus
> > drivers get immediately called once the call acpi_bus_register_driver?
> 
> But when xen stub driver registerred, real xen pad ops has not been hooked to stub ops.
> 
> > 
> > Or can one 'poke' the 'add' and 'remove' calls so that once the "true"
> > PAD driver is loaded it will restart the ops->add call?
> 
> I think we'd better not to use xen pad stub approach. Technically it's complicated, say, how to match xen_acpi_pad driver w/ pad device? when and how to invoke .add method? how to avoid native pad loading risk? etc. I didn't find its obivous advantages, so how about keep simpler approach?

OK. Lets go with that one for right now. The one thing I don't like about it is
that it is built-in. It would be so much better if it was a module, but I am just
not sure how to make that work with the acpi_pad. Unless the mwait CPUID capability
is not exported (so drop your patch 1 that reverts a commit).

Perhaps there is a way to make it a module/built-in with some Kconfig
magic options? Say if ACPI_PROCESSOR_AGGREGATOR is not set, then we can
make it a module. But if ACPI_PROCESSOR_AGGREGATOR=m|y then we do it
as built-in?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 14:32:47 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 14:32:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTZL7-0003BO-Mk; Wed, 31 Oct 2012 14:32:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTZL5-0003BJ-Rk
	for xen-devel@lists.xen.org; Wed, 31 Oct 2012 14:32:16 +0000
Received: from [85.158.139.83:55005] by server-3.bemta-5.messagelabs.com id
	62/92-28618-F6631905; Wed, 31 Oct 2012 14:32:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1351693934!16874586!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4MDA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30649 invoked from network); 31 Oct 2012 14:32:14 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-182.messagelabs.com with SMTP;
	31 Oct 2012 14:32:14 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 31 Oct 2012 12:44:24 +0000
Message-Id: <50912B5F02000078000A5B8E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 31 Oct 2012 12:45:03 +0000
From: "Jan Beulich" 
To: "Jinsong Liu" 
References: 
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: George Dunlap ,
	Ian Jackson ,
	xen-devel 
Subject: Re: [Xen-devel] [PATCH 01/02] Handles broken page occurred before
 migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 31.10.12 at 12:19, "Liu, Jinsong"  wrote:
> @@ -1568,6 +1577,38 @@
>      }
>      break;
>  
> +    case XEN_DOMCTL_set_broken_page_p2m:
> +    {
> +        struct domain *d;
> +        p2m_type_t pt;
> +        unsigned long pfn;
> +        mfn_t mfn;

If you use scope restricted local variables (which I appreciate),
please declare them in the innermost possible scope, ...

> +
> +        d = rcu_lock_domain_by_id(domctl->domain);
> +        if ( d != NULL )
> +        {
> +            pfn = domctl->u.set_broken_page_p2m.pfn;
> +
> +            mfn = get_gfn_query(d, pfn, &pt);

... i.e. here (and then both assignments can become initializers
at once).

> +            if ( !mfn_valid(mfn_x(mfn)) || !p2m_is_ram(pt) )
> +            {
> +                put_gfn(d, pfn);
> +                rcu_unlock_domain(d);
> +                ret = -EINVAL;
> +                break;
> +            }
> +
> +            if ( p2m_change_type(d, pfn, pt, p2m_ram_broken) != pt )
> +                ret = -EINVAL;

The two if() conditions can be easily joined (the more that they
both produce -EINVAL).

> +
> +            put_gfn(d, pfn);
> +            rcu_unlock_domain(d);
> +        }
> +        else
> +            ret = -ESRCH;
> +    }
> +    break;
> +
>      default:
>          ret = iommu_do_domctl(domctl, u_domctl);
>          break;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 14:32:47 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 14:32:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTZL7-0003BO-Mk; Wed, 31 Oct 2012 14:32:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTZL5-0003BJ-Rk
	for xen-devel@lists.xen.org; Wed, 31 Oct 2012 14:32:16 +0000
Received: from [85.158.139.83:55005] by server-3.bemta-5.messagelabs.com id
	62/92-28618-F6631905; Wed, 31 Oct 2012 14:32:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1351693934!16874586!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4MDA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30649 invoked from network); 31 Oct 2012 14:32:14 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-182.messagelabs.com with SMTP;
	31 Oct 2012 14:32:14 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 31 Oct 2012 12:44:24 +0000
Message-Id: <50912B5F02000078000A5B8E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 31 Oct 2012 12:45:03 +0000
From: "Jan Beulich" 
To: "Jinsong Liu" 
References: 
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: George Dunlap ,
	Ian Jackson ,
	xen-devel 
Subject: Re: [Xen-devel] [PATCH 01/02] Handles broken page occurred before
 migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 31.10.12 at 12:19, "Liu, Jinsong"  wrote:
> @@ -1568,6 +1577,38 @@
>      }
>      break;
>  
> +    case XEN_DOMCTL_set_broken_page_p2m:
> +    {
> +        struct domain *d;
> +        p2m_type_t pt;
> +        unsigned long pfn;
> +        mfn_t mfn;

If you use scope restricted local variables (which I appreciate),
please declare them in the innermost possible scope, ...

> +
> +        d = rcu_lock_domain_by_id(domctl->domain);
> +        if ( d != NULL )
> +        {
> +            pfn = domctl->u.set_broken_page_p2m.pfn;
> +
> +            mfn = get_gfn_query(d, pfn, &pt);

... i.e. here (and then both assignments can become initializers
at once).

> +            if ( !mfn_valid(mfn_x(mfn)) || !p2m_is_ram(pt) )
> +            {
> +                put_gfn(d, pfn);
> +                rcu_unlock_domain(d);
> +                ret = -EINVAL;
> +                break;
> +            }
> +
> +            if ( p2m_change_type(d, pfn, pt, p2m_ram_broken) != pt )
> +                ret = -EINVAL;

The two if() conditions can be easily joined (the more that they
both produce -EINVAL).

> +
> +            put_gfn(d, pfn);
> +            rcu_unlock_domain(d);
> +        }
> +        else
> +            ret = -ESRCH;
> +    }
> +    break;
> +
>      default:
>          ret = iommu_do_domctl(domctl, u_domctl);
>          break;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 14:35:50 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 14:35:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTZO8-0003LQ-9s; Wed, 31 Oct 2012 14:35:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTZO6-0003LG-Tl
	for xen-devel@lists.xen.org; Wed, 31 Oct 2012 14:35:23 +0000
Received: from [85.158.137.99:28119] by server-6.bemta-3.messagelabs.com id
	48/29-32375-A2731905; Wed, 31 Oct 2012 14:35:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1351694120!14021750!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY2MTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 574 invoked from network); 31 Oct 2012 14:35:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Oct 2012 14:35:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,687,1344211200"; d="scan'208";a="15515049"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Oct 2012 14:35:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 31 Oct 2012 14:35:19 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TTZO4-00020e-0k; Wed, 31 Oct 2012 14:35:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TTZO3-0007bo-Pj;
	Wed, 31 Oct 2012 14:35:19 +0000
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20625.14119.662345.683945@mariner.uk.xensource.com>
Date: Wed, 31 Oct 2012 14:35:19 +0000
To: Jan Beulich , Olaf Hering ,
	Ian Campbell , xen-devel 
In-Reply-To: <20623.57765.463131.112836@mariner.uk.xensource.com>
References: <508E489502000078000A4FC6@nat28.tlf.novell.com>
	<20121030132951.GA4192@aepfle.de>
	<508FE6DD02000078000A56CF@nat28.tlf.novell.com>
	<20623.57765.463131.112836@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] preparing for 4.2.1 and 4.1.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson writes ("Re: [Xen-devel] preparing for 4.2.1 and 4.1.4"):
> I did a huge pile of backports late last week which seem to have
> broken some things.  The bisector is working on it and I'm hoping it
> will report fairly shortly ...

I'm sorry to report that the bisector has been having some internal
troubles.  It's taking less-trodden paths, mainly because it hasn't
tackled a stable branch like 4.2 for a long time (if at all).

I've been fixing the problems with the bisector.  If we don't have a
result from it by tomorrow morning I'll investigate the bug by
traditional methods...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 14:35:50 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 14:35:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTZO8-0003LQ-9s; Wed, 31 Oct 2012 14:35:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTZO6-0003LG-Tl
	for xen-devel@lists.xen.org; Wed, 31 Oct 2012 14:35:23 +0000
Received: from [85.158.137.99:28119] by server-6.bemta-3.messagelabs.com id
	48/29-32375-A2731905; Wed, 31 Oct 2012 14:35:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1351694120!14021750!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY2MTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 574 invoked from network); 31 Oct 2012 14:35:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Oct 2012 14:35:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,687,1344211200"; d="scan'208";a="15515049"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Oct 2012 14:35:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 31 Oct 2012 14:35:19 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from )	id
	1TTZO4-00020e-0k; Wed, 31 Oct 2012 14:35:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from )	id 1TTZO3-0007bo-Pj;
	Wed, 31 Oct 2012 14:35:19 +0000
From: Ian Jackson 
MIME-Version: 1.0
Message-ID: <20625.14119.662345.683945@mariner.uk.xensource.com>
Date: Wed, 31 Oct 2012 14:35:19 +0000
To: Jan Beulich , Olaf Hering ,
	Ian Campbell , xen-devel 
In-Reply-To: <20623.57765.463131.112836@mariner.uk.xensource.com>
References: <508E489502000078000A4FC6@nat28.tlf.novell.com>
	<20121030132951.GA4192@aepfle.de>
	<508FE6DD02000078000A56CF@nat28.tlf.novell.com>
	<20623.57765.463131.112836@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] preparing for 4.2.1 and 4.1.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Jackson writes ("Re: [Xen-devel] preparing for 4.2.1 and 4.1.4"):
> I did a huge pile of backports late last week which seem to have
> broken some things.  The bisector is working on it and I'm hoping it
> will report fairly shortly ...

I'm sorry to report that the bisector has been having some internal
troubles.  It's taking less-trodden paths, mainly because it hasn't
tackled a stable branch like 4.2 for a long time (if at all).

I've been fixing the problems with the bisector.  If we don't have a
result from it by tomorrow morning I'll investigate the bug by
traditional methods...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 15:08:21 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 15:08:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTZtc-0003pB-2I; Wed, 31 Oct 2012 15:07:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTZtb-0003p6-6Y
	for xen-devel@lists.xensource.com; Wed, 31 Oct 2012 15:07:55 +0000
Received: from [85.158.139.83:49598] by server-1.bemta-5.messagelabs.com id
	9E/30-21640-ACE31905; Wed, 31 Oct 2012 15:07:54 +0000
X-Env-Sender: shakirov@cg.ru
X-Msg-Ref: server-12.tower-182.messagelabs.com!1351696073!28156535!1
X-Originating-IP: [217.198.1.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3504 invoked from network); 31 Oct 2012 15:07:53 -0000
Received: from zarafa.cg.ru (HELO zarafa.cg.ru) (217.198.1.89)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 31 Oct 2012 15:07:53 -0000
Received: by zarafa.cg.ru (Postfix, from userid 117)
	id 417514031D; Wed, 31 Oct 2012 19:07:52 +0400 (MSK)
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on zarafa.cg.ru
X-Spam-Level: 
X-Spam-ASN: 
X-Spam-Status: No, score=-101.0 required=6.0 tests=ALL_TRUSTED,AWL,
	HTML_MESSAGE,
	USER_IN_WHITELIST shortcircuit=no autolearn=ham version=3.3.1
Received: from shakirovpc.center.cg (unknown [10.10.19.50])
	by zarafa.cg.ru (Postfix) with ESMTPSA id F03C94031A;
	Wed, 31 Oct 2012 19:07:50 +0400 (MSK)
Message-ID: <50913EC6.3040105@zarafa.cg.ru>
Date: Wed, 31 Oct 2012 19:07:50 +0400
From: Lenar Shakirov 
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
Cc: =?UTF-8?B?0K7RgdGD0L/QvtCyINCg0LDQtNC40Lo=?= 
Subject: [Xen-devel] Xen 4.1.3 booting VM from phy:/dev/cdrom regression
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============2953219127770285013=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============2953219127770285013==
Content-Type: multipart/alternative;
 boundary="------------010402060309040907080302"

This is a multi-part message in MIME format.
--------------010402060309040907080302
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

I have the regression with booting VM from "phy:/dev/cdrom" on xen 
4.1.3, but it works with 4.1.2.

Backport of commit 
http://xenbits.xen.org/gitweb/?p=qemu-xen-4.2-testing.git;a=commit;h=effd5676225761abdab90becac519716515c3be4 
to 4.1.3 fix my trouble.

--
Best regards,
Lenar Shakirov


--------------010402060309040907080302
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit


  

    
  
  
    Hi,

    

    I have the regression with booting VM from "phy:/dev/cdrom" on xen
    4.1.3, but it works with 4.1.2.

    

    Backport of commit
    
    http://xenbits.xen.org/gitweb/?p=qemu-xen-4.2-testing.git;a=commit;h=effd5676225761abdab90becac519716515c3be4
    to 4.1.3 fix my trouble.

    

    
--
Best regards,
Lenar Shakirov

  


--------------010402060309040907080302--


--===============2953219127770285013==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2953219127770285013==--


From xen-devel-bounces@lists.xen.org Wed Oct 31 15:08:21 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 15:08:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTZtc-0003pB-2I; Wed, 31 Oct 2012 15:07:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTZtb-0003p6-6Y
	for xen-devel@lists.xensource.com; Wed, 31 Oct 2012 15:07:55 +0000
Received: from [85.158.139.83:49598] by server-1.bemta-5.messagelabs.com id
	9E/30-21640-ACE31905; Wed, 31 Oct 2012 15:07:54 +0000
X-Env-Sender: shakirov@cg.ru
X-Msg-Ref: server-12.tower-182.messagelabs.com!1351696073!28156535!1
X-Originating-IP: [217.198.1.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3504 invoked from network); 31 Oct 2012 15:07:53 -0000
Received: from zarafa.cg.ru (HELO zarafa.cg.ru) (217.198.1.89)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 31 Oct 2012 15:07:53 -0000
Received: by zarafa.cg.ru (Postfix, from userid 117)
	id 417514031D; Wed, 31 Oct 2012 19:07:52 +0400 (MSK)
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on zarafa.cg.ru
X-Spam-Level: 
X-Spam-ASN: 
X-Spam-Status: No, score=-101.0 required=6.0 tests=ALL_TRUSTED,AWL,
	HTML_MESSAGE,
	USER_IN_WHITELIST shortcircuit=no autolearn=ham version=3.3.1
Received: from shakirovpc.center.cg (unknown [10.10.19.50])
	by zarafa.cg.ru (Postfix) with ESMTPSA id F03C94031A;
	Wed, 31 Oct 2012 19:07:50 +0400 (MSK)
Message-ID: <50913EC6.3040105@zarafa.cg.ru>
Date: Wed, 31 Oct 2012 19:07:50 +0400
From: Lenar Shakirov 
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
Cc: =?UTF-8?B?0K7RgdGD0L/QvtCyINCg0LDQtNC40Lo=?= 
Subject: [Xen-devel] Xen 4.1.3 booting VM from phy:/dev/cdrom regression
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============2953219127770285013=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============2953219127770285013==
Content-Type: multipart/alternative;
 boundary="------------010402060309040907080302"

This is a multi-part message in MIME format.
--------------010402060309040907080302
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

I have the regression with booting VM from "phy:/dev/cdrom" on xen 
4.1.3, but it works with 4.1.2.

Backport of commit 
http://xenbits.xen.org/gitweb/?p=qemu-xen-4.2-testing.git;a=commit;h=effd5676225761abdab90becac519716515c3be4 
to 4.1.3 fix my trouble.

--
Best regards,
Lenar Shakirov


--------------010402060309040907080302
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit


  

    
  
  
    Hi,

    

    I have the regression with booting VM from "phy:/dev/cdrom" on xen
    4.1.3, but it works with 4.1.2.

    

    Backport of commit
    
    http://xenbits.xen.org/gitweb/?p=qemu-xen-4.2-testing.git;a=commit;h=effd5676225761abdab90becac519716515c3be4
    to 4.1.3 fix my trouble.

    

    
--
Best regards,
Lenar Shakirov

  


--------------010402060309040907080302--


--===============2953219127770285013==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2953219127770285013==--


From xen-devel-bounces@lists.xen.org Wed Oct 31 15:08:26 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 15:08:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTZte-0003pN-ET; Wed, 31 Oct 2012 15:07:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTZtc-0003pF-J3
	for xen-devel@lists.xen.org; Wed, 31 Oct 2012 15:07:56 +0000
Received: from [85.158.139.211:42705] by server-14.bemta-5.messagelabs.com id
	C7/49-21768-BCE31905; Wed, 31 Oct 2012 15:07:55 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1351696073!18313287!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjI1NTQy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16696 invoked from network); 31 Oct 2012 15:07:54 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-12.tower-206.messagelabs.com with SMTP;
	31 Oct 2012 15:07:54 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 31 Oct 2012 08:07:52 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,687,1344236400"; d="scan'208";a="211771856"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by azsmga001.ch.intel.com with ESMTP; 31 Oct 2012 08:07:52 -0700
Received: from FMSMSX110.amr.corp.intel.com (10.19.9.29) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 31 Oct 2012 08:07:51 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	fmsmsx110.amr.corp.intel.com (10.19.9.29) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 31 Oct 2012 08:07:51 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.123]) with mapi id
	14.01.0355.002; Wed, 31 Oct 2012 23:07:49 +0800
From: "Liu, Jinsong" 
To: Konrad Rzeszutek Wilk 
Thread-Topic: [Xen-devel] [PATCH 1/2] Xen acpi pad implement
Thread-Index: AQHNt27gTi91BiFLfUibRvXA4zlK85fTgYow
Date: Wed, 31 Oct 2012 15:07:49 +0000
Message-ID: 
References: 
	<508A89CB020000780008E6ED@nat28.tlf.novell.com>
	
	
	<20121026201409.GF2708@phenom.dumpdata.com>
	
	<20121029123950.GK2708@phenom.dumpdata.com>
	
	<20121030133720.GA27463@phenom.dumpdata.com>
	
	<20121031135150.GA28699@phenom.dumpdata.com>
In-Reply-To: <20121031135150.GA28699@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk ,
	"linux-kernel@vger.kernel.org" ,
	Jan Beulich ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 1/2] Xen acpi pad implement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad Rzeszutek Wilk wrote:
> On Tue, Oct 30, 2012 at 03:18:59PM +0000, Liu, Jinsong wrote:
>> Konrad Rzeszutek Wilk wrote:
>>>>> +config XEN_ACPI_PAD_STUB
>>>>> +	bool
>>>>> +	depends on XEN_DOM0 && X86_64 && ACPI
>>>>> +	default n
>>>>> +
>>>> 
>>>> This Kconfig is pointless, if CONFIG_XEN_ACPI_PAD_STUB = n, native
>>>> pad would successfully registerred, and then mwait #UD (we would
>>>> revert df88b2d96e36d9a9e325bfcd12eb45671cbbc937, right?). So xen
>>>> stub logic should unconditionally built-in kernel.
>>> 
>>> 
>>> Potentially. Keep in mind that there is no need to built this if the
>>> kernel is not built with ACPI.
>> 
>> Sure, 'obj-$(CONFIG_XEN_DOM0) +=' is enough.
>> (XEN_DOM0 depends on ACPI).
>> 
>>>>> +subsys_initcall(xen_acpi_pad_stub_init);
>>>> 
>>>> I'm still confused. In this way there are xen-acpi-pad-stub.c and
>>>> xen-acpi-pad.c, and you want to let xen-acpi-pad loaded as module,
>>>> right? how can xen-acpi-pad logic work when it was insmoded?
>>> 
>>> Via the register/unregister calls that this provides? Or does ACPI
>>> bus drivers get immediately called once the call
>>> acpi_bus_register_driver? 
>> 
>> But when xen stub driver registerred, real xen pad ops has not been
>> hooked to stub ops. 
>> 
>>> 
>>> Or can one 'poke' the 'add' and 'remove' calls so that once the
>>> "true" PAD driver is loaded it will restart the ops->add call?
>> 
>> I think we'd better not to use xen pad stub approach. Technically
>> it's complicated, say, how to match xen_acpi_pad driver w/ pad
>> device? when and how to invoke .add method? how to avoid native pad
>> loading risk? etc. I didn't find its obivous advantages, so how
>> about keep simpler approach?    
> 
> OK. Lets go with that one for right now. The one thing I don't like
> about it is that it is built-in. It would be so much better if it was
> a module, but I am just not sure how to make that work with the
> acpi_pad. Unless the mwait CPUID capability is not exported (so drop
> your patch 1 that reverts a commit). 

Yes, but considering mwait case and its benefit to hypervisor, xen pad built-in kernel seems to be the price we have to pay. At least currently I didn't find better way.

> 
> Perhaps there is a way to make it a module/built-in with some Kconfig
> magic options? Say if ACPI_PROCESSOR_AGGREGATOR is not set, then we
> can 
> make it a module. But if ACPI_PROCESSOR_AGGREGATOR=m|y then we do it
> as built-in?

Hmm, seems it's hard to express this logic in Kconfig, and that would make xen pad logic very complicated :)

Thanks,
Jinsong


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 15:08:26 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 15:08:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTZte-0003pN-ET; Wed, 31 Oct 2012 15:07:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTZtc-0003pF-J3
	for xen-devel@lists.xen.org; Wed, 31 Oct 2012 15:07:56 +0000
Received: from [85.158.139.211:42705] by server-14.bemta-5.messagelabs.com id
	C7/49-21768-BCE31905; Wed, 31 Oct 2012 15:07:55 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1351696073!18313287!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjI1NTQy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16696 invoked from network); 31 Oct 2012 15:07:54 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-12.tower-206.messagelabs.com with SMTP;
	31 Oct 2012 15:07:54 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 31 Oct 2012 08:07:52 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,687,1344236400"; d="scan'208";a="211771856"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by azsmga001.ch.intel.com with ESMTP; 31 Oct 2012 08:07:52 -0700
Received: from FMSMSX110.amr.corp.intel.com (10.19.9.29) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 31 Oct 2012 08:07:51 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	fmsmsx110.amr.corp.intel.com (10.19.9.29) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 31 Oct 2012 08:07:51 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.123]) with mapi id
	14.01.0355.002; Wed, 31 Oct 2012 23:07:49 +0800
From: "Liu, Jinsong" 
To: Konrad Rzeszutek Wilk 
Thread-Topic: [Xen-devel] [PATCH 1/2] Xen acpi pad implement
Thread-Index: AQHNt27gTi91BiFLfUibRvXA4zlK85fTgYow
Date: Wed, 31 Oct 2012 15:07:49 +0000
Message-ID: 
References: 
	<508A89CB020000780008E6ED@nat28.tlf.novell.com>
	
	
	<20121026201409.GF2708@phenom.dumpdata.com>
	
	<20121029123950.GK2708@phenom.dumpdata.com>
	
	<20121030133720.GA27463@phenom.dumpdata.com>
	
	<20121031135150.GA28699@phenom.dumpdata.com>
In-Reply-To: <20121031135150.GA28699@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk ,
	"linux-kernel@vger.kernel.org" ,
	Jan Beulich ,
	"xen-devel@lists.xen.org" 
Subject: Re: [Xen-devel] [PATCH 1/2] Xen acpi pad implement
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad Rzeszutek Wilk wrote:
> On Tue, Oct 30, 2012 at 03:18:59PM +0000, Liu, Jinsong wrote:
>> Konrad Rzeszutek Wilk wrote:
>>>>> +config XEN_ACPI_PAD_STUB
>>>>> +	bool
>>>>> +	depends on XEN_DOM0 && X86_64 && ACPI
>>>>> +	default n
>>>>> +
>>>> 
>>>> This Kconfig is pointless, if CONFIG_XEN_ACPI_PAD_STUB = n, native
>>>> pad would successfully registerred, and then mwait #UD (we would
>>>> revert df88b2d96e36d9a9e325bfcd12eb45671cbbc937, right?). So xen
>>>> stub logic should unconditionally built-in kernel.
>>> 
>>> 
>>> Potentially. Keep in mind that there is no need to built this if the
>>> kernel is not built with ACPI.
>> 
>> Sure, 'obj-$(CONFIG_XEN_DOM0) +=' is enough.
>> (XEN_DOM0 depends on ACPI).
>> 
>>>>> +subsys_initcall(xen_acpi_pad_stub_init);
>>>> 
>>>> I'm still confused. In this way there are xen-acpi-pad-stub.c and
>>>> xen-acpi-pad.c, and you want to let xen-acpi-pad loaded as module,
>>>> right? how can xen-acpi-pad logic work when it was insmoded?
>>> 
>>> Via the register/unregister calls that this provides? Or does ACPI
>>> bus drivers get immediately called once the call
>>> acpi_bus_register_driver? 
>> 
>> But when xen stub driver registerred, real xen pad ops has not been
>> hooked to stub ops. 
>> 
>>> 
>>> Or can one 'poke' the 'add' and 'remove' calls so that once the
>>> "true" PAD driver is loaded it will restart the ops->add call?
>> 
>> I think we'd better not to use xen pad stub approach. Technically
>> it's complicated, say, how to match xen_acpi_pad driver w/ pad
>> device? when and how to invoke .add method? how to avoid native pad
>> loading risk? etc. I didn't find its obivous advantages, so how
>> about keep simpler approach?    
> 
> OK. Lets go with that one for right now. The one thing I don't like
> about it is that it is built-in. It would be so much better if it was
> a module, but I am just not sure how to make that work with the
> acpi_pad. Unless the mwait CPUID capability is not exported (so drop
> your patch 1 that reverts a commit). 

Yes, but considering mwait case and its benefit to hypervisor, xen pad built-in kernel seems to be the price we have to pay. At least currently I didn't find better way.

> 
> Perhaps there is a way to make it a module/built-in with some Kconfig
> magic options? Say if ACPI_PROCESSOR_AGGREGATOR is not set, then we
> can 
> make it a module. But if ACPI_PROCESSOR_AGGREGATOR=m|y then we do it
> as built-in?

Hmm, seems it's hard to express this logic in Kconfig, and that would make xen pad logic very complicated :)

Thanks,
Jinsong


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 16:05:40 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 16:05:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTan4-0005IK-MB; Wed, 31 Oct 2012 16:05:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTan3-0005IC-GG
	for xen-devel@lists.xen.org; Wed, 31 Oct 2012 16:05:13 +0000
Received: from [85.158.138.51:48411] by server-10.bemta-3.messagelabs.com id
	E4/E5-00901-53C41905; Wed, 31 Oct 2012 16:05:09 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1351699506!19270320!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgzNzk1Ng==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13182 invoked from network); 31 Oct 2012 16:05:08 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 31 Oct 2012 16:05:08 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9VG4qWq021300
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 31 Oct 2012 16:04:53 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9VG4pHg020455
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 31 Oct 2012 16:04:51 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9VG4ojg026736; Wed, 31 Oct 2012 11:04:50 -0500
MIME-Version: 1.0
Message-ID: <83bb902d-8e49-41cf-ad1e-c07c62d6e5f8@default>
Date: Wed, 31 Oct 2012 09:04:47 -0700 (PDT)
From: Dan Magenheimer 
To: Jan Beulich , "Keir(Xen.org)" 
References: <60d00f38-98a3-4ec2-acbd-b49dafaada56@default>
	<20121029223555.GA24388@ocelot.phlegethon.org>
	
	<508F9DE902000078000A5565@nat28.tlf.novell.com>
	
	<509008A502000078000A584E@nat28.tlf.novell.com>
	
	<5090EBFE02000078000A59DD@nat28.tlf.novell.com>
In-Reply-To: <5090EBFE02000078000A59DD@nat28.tlf.novell.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Tim Deegan , Olaf Hering ,
	IanCampbell ,
	Konrad Wilk ,
	GeorgeDunlap ,
	IanJackson ,
	George Shuklin ,
	xen-devel@lists.xen.org, DarioFaggioli ,
	Kurt Hackel ,
	Zhigang Wang 
Subject: Re: [Xen-devel] Proposed new "memory capacity claim"
	hypercall/feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Subject: RE: Proposed new "memory capacity claim" hypercall/feature
> 
> >>> On 30.10.12 at 18:13, Dan Magenheimer  wrote:
> >>  From: Jan Beulich [mailto:JBeulich@suse.com]

(NOTE TO KEIR: Input from you requested in first stanza below.)

Hi Jan --

Thanks for the continued feedback!

I've slightly re-ordered the email to focus on the problem
(moved tmem-specific discussion to the end).

> As long as the allocation times can get brought down to an
> acceptable level, I continue to not see a need for the extra
> "claim" approach you're proposing. So working on that one (or
> showing that without unreasonable effort this cannot be
> further improved) would be a higher priority thing from my pov
> (without anyone arguing about its usefulness).

Fair enough.  I will do some measurement and analysis of this
code.  However, let me ask something of you and Keir as well:
Please estimate how long (in usec) you think it is acceptable
to hold the heap_lock.  If your limit is very small (as I expect),
doing anything "N" times in a loop with the lock held (for N==2^26,
which is a 256GB domain) may make the analysis moot.

> But yes, with all the factors you mention brought in, there is
> certainly some improvement needed (whether your "claim"
> proposal is a the right thing is another question, not to mention
> that I currently don't see how this would get implemented in
> a consistent way taking several orders of magnitude less time
> to carry out).

OK, I will start on the next step... proof-of-concept.
I'm envisioning simple arithmetic, but maybe you are
right and arithmetic will not be sufficient.

> > Suppose you have a huge 256GB machine and you have already launched
> > a 64GB tmem guest "A".  The guest is idle for now, so slowly
> > selfballoons down to maybe 4GB.  You start to launch another 64GB
> > guest "B" which, as we know, is going to take some time to complete.
> > In the middle of launching "B", "A" suddenly gets very active and
> > needs to balloon up as quickly as possible or it can't balloon fast
> > enough (or at all if "frozen" as suggested) so starts swapping (and,
> > thanks to Linux frontswap, the swapping tries to go to hypervisor/tmem
> > memory).  But ballooning and tmem are both blocked and so the
> > guest swaps its poor little butt off even though there's >100GB
> > of free physical memory available.
> 
> That's only one side of the overcommit situation you're striving
> to get work right here: That same self ballooning guest, after
> sufficiently more guest got started so that the rest of the memory
> got absorbed by them would suffer the very same problems in
> the described situation, so it has to be prepared for this case
> anyway.

The tmem design does ensure the guest is prepared for this case
anyway... the guest swaps.  And, unlike page-sharing, the guest
determines which pages to swap, not the host, and there is no
possibility of double-paging.

In your scenario, the host memory is truly oversubscribed.  This
scenario is ultimately a weakness of virtualization in general;
trying to statistically-share an oversubscribed fixed resource
among a number of guests will sometimes cause a performance
degradation, whether the resource is CPU or LAN bandwidth or,
in this case, physical memory.  That very generic problem
is I think not one any of us can solve.  Toolstacks need to
be able to recognize the problem (whether CPU, LAN, or memory)
and act accordingly (report, or auto-migrate).

In my scenario, guest performance is hammered only because of
the unfortunate deficiency in the existing hypervisor memory
allocation mechanisms, namely that small allocations must
be artificially "frozen" until a large allocation can complete.
That specific problem is one I am trying to solve.

BTW, with tmem, some future toolstack might monitor various
available tmem statistics and predict/avoid your scenario.

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 16:05:40 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 16:05:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTan4-0005IK-MB; Wed, 31 Oct 2012 16:05:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTan3-0005IC-GG
	for xen-devel@lists.xen.org; Wed, 31 Oct 2012 16:05:13 +0000
Received: from [85.158.138.51:48411] by server-10.bemta-3.messagelabs.com id
	E4/E5-00901-53C41905; Wed, 31 Oct 2012 16:05:09 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1351699506!19270320!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgzNzk1Ng==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13182 invoked from network); 31 Oct 2012 16:05:08 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 31 Oct 2012 16:05:08 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9VG4qWq021300
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 31 Oct 2012 16:04:53 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9VG4pHg020455
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 31 Oct 2012 16:04:51 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9VG4ojg026736; Wed, 31 Oct 2012 11:04:50 -0500
MIME-Version: 1.0
Message-ID: <83bb902d-8e49-41cf-ad1e-c07c62d6e5f8@default>
Date: Wed, 31 Oct 2012 09:04:47 -0700 (PDT)
From: Dan Magenheimer 
To: Jan Beulich , "Keir(Xen.org)" 
References: <60d00f38-98a3-4ec2-acbd-b49dafaada56@default>
	<20121029223555.GA24388@ocelot.phlegethon.org>
	
	<508F9DE902000078000A5565@nat28.tlf.novell.com>
	
	<509008A502000078000A584E@nat28.tlf.novell.com>
	
	<5090EBFE02000078000A59DD@nat28.tlf.novell.com>
In-Reply-To: <5090EBFE02000078000A59DD@nat28.tlf.novell.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Tim Deegan , Olaf Hering ,
	IanCampbell ,
	Konrad Wilk ,
	GeorgeDunlap ,
	IanJackson ,
	George Shuklin ,
	xen-devel@lists.xen.org, DarioFaggioli ,
	Kurt Hackel ,
	Zhigang Wang 
Subject: Re: [Xen-devel] Proposed new "memory capacity claim"
	hypercall/feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Subject: RE: Proposed new "memory capacity claim" hypercall/feature
> 
> >>> On 30.10.12 at 18:13, Dan Magenheimer  wrote:
> >>  From: Jan Beulich [mailto:JBeulich@suse.com]

(NOTE TO KEIR: Input from you requested in first stanza below.)

Hi Jan --

Thanks for the continued feedback!

I've slightly re-ordered the email to focus on the problem
(moved tmem-specific discussion to the end).

> As long as the allocation times can get brought down to an
> acceptable level, I continue to not see a need for the extra
> "claim" approach you're proposing. So working on that one (or
> showing that without unreasonable effort this cannot be
> further improved) would be a higher priority thing from my pov
> (without anyone arguing about its usefulness).

Fair enough.  I will do some measurement and analysis of this
code.  However, let me ask something of you and Keir as well:
Please estimate how long (in usec) you think it is acceptable
to hold the heap_lock.  If your limit is very small (as I expect),
doing anything "N" times in a loop with the lock held (for N==2^26,
which is a 256GB domain) may make the analysis moot.

> But yes, with all the factors you mention brought in, there is
> certainly some improvement needed (whether your "claim"
> proposal is a the right thing is another question, not to mention
> that I currently don't see how this would get implemented in
> a consistent way taking several orders of magnitude less time
> to carry out).

OK, I will start on the next step... proof-of-concept.
I'm envisioning simple arithmetic, but maybe you are
right and arithmetic will not be sufficient.

> > Suppose you have a huge 256GB machine and you have already launched
> > a 64GB tmem guest "A".  The guest is idle for now, so slowly
> > selfballoons down to maybe 4GB.  You start to launch another 64GB
> > guest "B" which, as we know, is going to take some time to complete.
> > In the middle of launching "B", "A" suddenly gets very active and
> > needs to balloon up as quickly as possible or it can't balloon fast
> > enough (or at all if "frozen" as suggested) so starts swapping (and,
> > thanks to Linux frontswap, the swapping tries to go to hypervisor/tmem
> > memory).  But ballooning and tmem are both blocked and so the
> > guest swaps its poor little butt off even though there's >100GB
> > of free physical memory available.
> 
> That's only one side of the overcommit situation you're striving
> to get work right here: That same self ballooning guest, after
> sufficiently more guest got started so that the rest of the memory
> got absorbed by them would suffer the very same problems in
> the described situation, so it has to be prepared for this case
> anyway.

The tmem design does ensure the guest is prepared for this case
anyway... the guest swaps.  And, unlike page-sharing, the guest
determines which pages to swap, not the host, and there is no
possibility of double-paging.

In your scenario, the host memory is truly oversubscribed.  This
scenario is ultimately a weakness of virtualization in general;
trying to statistically-share an oversubscribed fixed resource
among a number of guests will sometimes cause a performance
degradation, whether the resource is CPU or LAN bandwidth or,
in this case, physical memory.  That very generic problem
is I think not one any of us can solve.  Toolstacks need to
be able to recognize the problem (whether CPU, LAN, or memory)
and act accordingly (report, or auto-migrate).

In my scenario, guest performance is hammered only because of
the unfortunate deficiency in the existing hypervisor memory
allocation mechanisms, namely that small allocations must
be artificially "frozen" until a large allocation can complete.
That specific problem is one I am trying to solve.

BTW, with tmem, some future toolstack might monitor various
available tmem statistics and predict/avoid your scenario.

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 16:15:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 16:15:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTawV-0005ZB-6C; Wed, 31 Oct 2012 16:14:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTawT-0005Z6-QG
	for xen-devel@lists.xen.org; Wed, 31 Oct 2012 16:14:58 +0000
Received: from [85.158.139.83:43692] by server-10.bemta-5.messagelabs.com id
	CB/11-01025-08E41905; Wed, 31 Oct 2012 16:14:56 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1351700090!20941513!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjI1NTQy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30826 invoked from network); 31 Oct 2012 16:14:51 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-11.tower-182.messagelabs.com with SMTP;
	31 Oct 2012 16:14:51 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 31 Oct 2012 09:14:48 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,687,1344236400"; d="scan'208";a="162927283"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by AZSMGA002.ch.intel.com with ESMTP; 31 Oct 2012 09:14:48 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 31 Oct 2012 09:14:47 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.186]) with mapi id
	14.01.0355.002; Thu, 1 Nov 2012 00:14:46 +0800
From: "Liu, Jinsong" 
To: Jan Beulich 
Thread-Topic: [PATCH 01/02] Handles broken page occurred before migration
Thread-Index: AQHNt2WLIm/L3sGKQI2O8U05ITu8CJfTlb+w
Date: Wed, 31 Oct 2012 16:14:45 +0000
Message-ID: 
References: 
	<50912B5F02000078000A5B8E@nat28.tlf.novell.com>
In-Reply-To: <50912B5F02000078000A5B8E@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC8292335376A97SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: George Dunlap ,
	Ian Jackson ,
	xen-devel 
Subject: Re: [Xen-devel] [PATCH 01/02] Handles broken page occurred before
	migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC8292335376A97SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

[snip]
>=20
> If you use scope restricted local variables (which I appreciate),
> please declare them in the innermost possible scope, ...
>=20
>> +
>> +        d =3D rcu_lock_domain_by_id(domctl->domain); +        if ( d
>> !=3D NULL ) +        {
>> +            pfn =3D domctl->u.set_broken_page_p2m.pfn; +
>> +            mfn =3D get_gfn_query(d, pfn, &pt);
>=20
> ... i.e. here (and then both assignments can become initializers
> at once).
>=20
>> +            if ( !mfn_valid(mfn_x(mfn)) || !p2m_is_ram(pt) ) +    =20
>> { +                put_gfn(d, pfn);
>> +                rcu_unlock_domain(d);
>> +                ret =3D -EINVAL;
>> +                break;
>> +            }
>> +
>> +            if ( p2m_change_type(d, pfn, pt, p2m_ram_broken) !=3D pt )
>> +                ret =3D -EINVAL;
>=20
> The two if() conditions can be easily joined (the more that they
> both produce -EINVAL).
>=20

Thanks, updated as attached.

Jinsong

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Handles broken page occurred before migration

This patch handles guest broken page which occurred before migration.

At sender, the broken page would be mapped but not copied to target
(otherwise it may trigger more serious error, say, SRAR error).
While its pfn_type and pfn number would be transferred to target
so that target take appropriate action.

At target, it would set p2m as p2m_ram_broken for broken page, so that
if guest access the broken page again, it would kill itself as expected.

Signed-off-by: Liu, Jinsong 

diff -r e84a79d11d7a tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c	Thu Nov 01 01:41:03 2012 +0800
+++ b/tools/libxc/xc_domain.c	Thu Nov 01 07:52:41 2012 +0800
@@ -283,6 +283,22 @@
     return ret;
 }
=20
+/* set broken page p2m */
+int xc_set_broken_page_p2m(xc_interface *xch,
+                           uint32_t domid,
+                           unsigned long pfn)
+{
+    int ret;
+    DECLARE_DOMCTL;
+
+    domctl.cmd =3D XEN_DOMCTL_set_broken_page_p2m;
+    domctl.domain =3D (domid_t)domid;
+    domctl.u.set_broken_page_p2m.pfn =3D pfn;
+    ret =3D do_domctl(xch, &domctl);
+
+    return ret ? -1 : 0;
+}
+
 /* get info from hvm guest for save */
 int xc_domain_hvm_getcontext(xc_interface *xch,
                              uint32_t domid,
diff -r e84a79d11d7a tools/libxc/xc_domain_restore.c
--- a/tools/libxc/xc_domain_restore.c	Thu Nov 01 01:41:03 2012 +0800
+++ b/tools/libxc/xc_domain_restore.c	Thu Nov 01 07:52:41 2012 +0800
@@ -962,9 +962,15 @@
=20
     countpages =3D count;
     for (i =3D oldcount; i < buf->nr_pages; ++i)
-        if ((buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) =3D=3D XEN_D=
OMCTL_PFINFO_XTAB
-            ||(buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) =3D=3D XEN=
_DOMCTL_PFINFO_XALLOC)
+    {
+        unsigned long pagetype;
+
+        pagetype =3D buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK;
+        if ( pagetype =3D=3D XEN_DOMCTL_PFINFO_XTAB ||
+             pagetype =3D=3D XEN_DOMCTL_PFINFO_BROKEN ||
+             pagetype =3D=3D XEN_DOMCTL_PFINFO_XALLOC )
             --countpages;
+    }
=20
     if (!countpages)
         return count;
@@ -1200,6 +1206,17 @@
             /* a bogus/unmapped/allocate-only page: skip it */
             continue;
=20
+        if ( pagetype =3D=3D XEN_DOMCTL_PFINFO_BROKEN )
+        {
+            if ( xc_set_broken_page_p2m(xch, dom, pfn) )
+            {
+                ERROR("Set p2m for broken page failed, "
+                      "dom=3D%d, pfn=3D%lx\n", dom, pfn);
+                goto err_mapped;
+            }
+            continue;
+        }
+
         if (pfn_err[i])
         {
             ERROR("unexpected PFN mapping failure pfn %lx map_mfn %lx p2m_=
mfn %lx",
diff -r e84a79d11d7a tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Thu Nov 01 01:41:03 2012 +0800
+++ b/tools/libxc/xc_domain_save.c	Thu Nov 01 07:52:41 2012 +0800
@@ -1277,6 +1277,13 @@
                 if ( !hvm )
                     gmfn =3D pfn_to_mfn(gmfn);
=20
+                if ( pfn_type[j] =3D=3D XEN_DOMCTL_PFINFO_BROKEN )
+                {
+                    pfn_type[j] |=3D pfn_batch[j];
+                    ++run;
+                    continue;
+                }
+
                 if ( pfn_err[j] )
                 {
                     if ( pfn_type[j] =3D=3D XEN_DOMCTL_PFINFO_XTAB )
@@ -1371,8 +1378,12 @@
                     }
                 }
=20
-                /* skip pages that aren't present or are alloc-only */
+                /*
+                 * skip pages that aren't present,
+                 * or are broken, or are alloc-only
+                 */
                 if ( pagetype =3D=3D XEN_DOMCTL_PFINFO_XTAB
+                    || pagetype =3D=3D XEN_DOMCTL_PFINFO_BROKEN
                     || pagetype =3D=3D XEN_DOMCTL_PFINFO_XALLOC )
                     continue;
=20
diff -r e84a79d11d7a tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Thu Nov 01 01:41:03 2012 +0800
+++ b/tools/libxc/xenctrl.h	Thu Nov 01 07:52:41 2012 +0800
@@ -575,6 +575,17 @@
                           xc_domaininfo_t *info);
=20
 /**
+ * This function set p2m for broken page
+ * &parm xch a handle to an open hypervisor interface
+ * @parm domid the domain id which broken page belong to
+ * @parm pfn the pfn number of the broken page
+ * @return 0 on success, -1 on failure
+ */
+int xc_set_broken_page_p2m(xc_interface *xch,
+                           uint32_t domid,
+                           unsigned long pfn);
+
+/**
  * This function returns information about the context of a hvm domain
  * @parm xch a handle to an open hypervisor interface
  * @parm domid the domain to get information from
diff -r e84a79d11d7a xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c	Thu Nov 01 01:41:03 2012 +0800
+++ b/xen/arch/x86/domctl.c	Thu Nov 01 07:52:41 2012 +0800
@@ -209,12 +209,18 @@
                 for ( j =3D 0; j < k; j++ )
                 {
                     unsigned long type =3D 0;
+                    p2m_type_t t;
=20
-                    page =3D get_page_from_gfn(d, arr[j], NULL, P2M_ALLOC)=
;
+                    page =3D get_page_from_gfn(d, arr[j], &t, P2M_ALLOC);
=20
                     if ( unlikely(!page) ||
                          unlikely(is_xen_heap_page(page)) )
-                        type =3D XEN_DOMCTL_PFINFO_XTAB;
+                    {
+                        if ( p2m_is_broken(t) )
+                            type =3D XEN_DOMCTL_PFINFO_BROKEN;
+                        else
+                            type =3D XEN_DOMCTL_PFINFO_XTAB;
+                    }
                     else
                     {
                         switch( page->u.inuse.type_info & PGT_type_mask )
@@ -235,6 +241,9 @@
=20
                         if ( page->u.inuse.type_info & PGT_pinned )
                             type |=3D XEN_DOMCTL_PFINFO_LPINTAB;
+
+                        if ( page->count_info & PGC_broken )
+                            type =3D XEN_DOMCTL_PFINFO_BROKEN;
                     }
=20
                     if ( page )
@@ -1568,6 +1577,29 @@
     }
     break;
=20
+    case XEN_DOMCTL_set_broken_page_p2m:
+    {
+        struct domain *d;
+       =20
+        d =3D rcu_lock_domain_by_id(domctl->domain);
+        if ( d !=3D NULL )
+        {
+            p2m_type_t pt;
+            unsigned long pfn =3D domctl->u.set_broken_page_p2m.pfn;
+            mfn_t mfn =3D get_gfn_query(d, pfn, &pt);
+
+            if ( unlikely(!mfn_valid(mfn_x(mfn)) || !p2m_is_ram(pt) ||
+                         (p2m_change_type(d, pfn, pt, p2m_ram_broken) !=3D=
 pt)) )
+                ret =3D -EINVAL;
+
+            put_gfn(d, pfn);
+            rcu_unlock_domain(d);
+        }
+        else
+            ret =3D -ESRCH;
+    }
+    break;
+
     default:
         ret =3D iommu_do_domctl(domctl, u_domctl);
         break;
diff -r e84a79d11d7a xen/include/public/domctl.h
--- a/xen/include/public/domctl.h	Thu Nov 01 01:41:03 2012 +0800
+++ b/xen/include/public/domctl.h	Thu Nov 01 07:52:41 2012 +0800
@@ -136,6 +136,7 @@
 #define XEN_DOMCTL_PFINFO_LPINTAB (0x1U<<31)
 #define XEN_DOMCTL_PFINFO_XTAB    (0xfU<<28) /* invalid page */
 #define XEN_DOMCTL_PFINFO_XALLOC  (0xeU<<28) /* allocate-only page */
+#define XEN_DOMCTL_PFINFO_BROKEN  (0xdU<<28) /* broken page */
 #define XEN_DOMCTL_PFINFO_PAGEDTAB (0x8U<<28)
 #define XEN_DOMCTL_PFINFO_LTAB_MASK (0xfU<<28)
=20
@@ -835,6 +836,12 @@
 typedef struct xen_domctl_set_access_required xen_domctl_set_access_requir=
ed_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_access_required_t);
=20
+struct xen_domctl_set_broken_page_p2m {
+    uint64_aligned_t pfn;
+};
+typedef struct xen_domctl_set_broken_page_p2m xen_domctl_set_broken_page_p=
2m_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_broken_page_p2m_t);
+
 struct xen_domctl {
     uint32_t cmd;
 #define XEN_DOMCTL_createdomain                   1
@@ -900,6 +907,7 @@
 #define XEN_DOMCTL_set_access_required           64
 #define XEN_DOMCTL_audit_p2m                     65
 #define XEN_DOMCTL_set_virq_handler              66
+#define XEN_DOMCTL_set_broken_page_p2m           67
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -955,6 +963,7 @@
         struct xen_domctl_audit_p2m         audit_p2m;
         struct xen_domctl_set_virq_handler  set_virq_handler;
         struct xen_domctl_gdbsx_memio       gdbsx_guest_memio;
+        struct xen_domctl_set_broken_page_p2m set_broken_page_p2m;
         struct xen_domctl_gdbsx_pauseunp_vcpu gdbsx_pauseunp_vcpu;
         struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
         uint8_t                             pad[128];=

--_002_DE8DF0795D48FD4CA783C40EC8292335376A97SHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="broken_page_occur_before_migration.patch"
Content-Description: broken_page_occur_before_migration.patch
Content-Disposition: attachment;
	filename="broken_page_occur_before_migration.patch"; size=8605;
	creation-date="Wed, 31 Oct 2012 16:05:52 GMT";
	modification-date="Wed, 31 Oct 2012 23:52:42 GMT"
Content-Transfer-Encoding: base64

SGFuZGxlcyBicm9rZW4gcGFnZSBvY2N1cnJlZCBiZWZvcmUgbWlncmF0aW9uCgpUaGlzIHBhdGNo
IGhhbmRsZXMgZ3Vlc3QgYnJva2VuIHBhZ2Ugd2hpY2ggb2NjdXJyZWQgYmVmb3JlIG1pZ3JhdGlv
bi4KCkF0IHNlbmRlciwgdGhlIGJyb2tlbiBwYWdlIHdvdWxkIGJlIG1hcHBlZCBidXQgbm90IGNv
cGllZCB0byB0YXJnZXQKKG90aGVyd2lzZSBpdCBtYXkgdHJpZ2dlciBtb3JlIHNlcmlvdXMgZXJy
b3IsIHNheSwgU1JBUiBlcnJvcikuCldoaWxlIGl0cyBwZm5fdHlwZSBhbmQgcGZuIG51bWJlciB3
b3VsZCBiZSB0cmFuc2ZlcnJlZCB0byB0YXJnZXQKc28gdGhhdCB0YXJnZXQgdGFrZSBhcHByb3By
aWF0ZSBhY3Rpb24uCgpBdCB0YXJnZXQsIGl0IHdvdWxkIHNldCBwMm0gYXMgcDJtX3JhbV9icm9r
ZW4gZm9yIGJyb2tlbiBwYWdlLCBzbyB0aGF0CmlmIGd1ZXN0IGFjY2VzcyB0aGUgYnJva2VuIHBh
Z2UgYWdhaW4sIGl0IHdvdWxkIGtpbGwgaXRzZWxmIGFzIGV4cGVjdGVkLgoKU2lnbmVkLW9mZi1i
eTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+CgpkaWZmIC1yIGU4NGE3OWQx
MWQ3YSB0b29scy9saWJ4Yy94Y19kb21haW4uYwotLS0gYS90b29scy9saWJ4Yy94Y19kb21haW4u
YwlUaHUgTm92IDAxIDAxOjQxOjAzIDIwMTIgKzA4MDAKKysrIGIvdG9vbHMvbGlieGMveGNfZG9t
YWluLmMJVGh1IE5vdiAwMSAwNzo1Mjo0MSAyMDEyICswODAwCkBAIC0yODMsNiArMjgzLDIyIEBA
CiAgICAgcmV0dXJuIHJldDsKIH0KIAorLyogc2V0IGJyb2tlbiBwYWdlIHAybSAqLworaW50IHhj
X3NldF9icm9rZW5fcGFnZV9wMm0oeGNfaW50ZXJmYWNlICp4Y2gsCisgICAgICAgICAgICAgICAg
ICAgICAgICAgICB1aW50MzJfdCBkb21pZCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgIHVu
c2lnbmVkIGxvbmcgcGZuKQoreworICAgIGludCByZXQ7CisgICAgREVDTEFSRV9ET01DVEw7CisK
KyAgICBkb21jdGwuY21kID0gWEVOX0RPTUNUTF9zZXRfYnJva2VuX3BhZ2VfcDJtOworICAgIGRv
bWN0bC5kb21haW4gPSAoZG9taWRfdClkb21pZDsKKyAgICBkb21jdGwudS5zZXRfYnJva2VuX3Bh
Z2VfcDJtLnBmbiA9IHBmbjsKKyAgICByZXQgPSBkb19kb21jdGwoeGNoLCAmZG9tY3RsKTsKKwor
ICAgIHJldHVybiByZXQgPyAtMSA6IDA7Cit9CisKIC8qIGdldCBpbmZvIGZyb20gaHZtIGd1ZXN0
IGZvciBzYXZlICovCiBpbnQgeGNfZG9tYWluX2h2bV9nZXRjb250ZXh0KHhjX2ludGVyZmFjZSAq
eGNoLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJfdCBkb21pZCwKZGlmZiAt
ciBlODRhNzlkMTFkN2EgdG9vbHMvbGlieGMveGNfZG9tYWluX3Jlc3RvcmUuYwotLS0gYS90b29s
cy9saWJ4Yy94Y19kb21haW5fcmVzdG9yZS5jCVRodSBOb3YgMDEgMDE6NDE6MDMgMjAxMiArMDgw
MAorKysgYi90b29scy9saWJ4Yy94Y19kb21haW5fcmVzdG9yZS5jCVRodSBOb3YgMDEgMDc6NTI6
NDEgMjAxMiArMDgwMApAQCAtOTYyLDkgKzk2MiwxNSBAQAogCiAgICAgY291bnRwYWdlcyA9IGNv
dW50OwogICAgIGZvciAoaSA9IG9sZGNvdW50OyBpIDwgYnVmLT5ucl9wYWdlczsgKytpKQotICAg
ICAgICBpZiAoKGJ1Zi0+cGZuX3R5cGVzW2ldICYgWEVOX0RPTUNUTF9QRklORk9fTFRBQl9NQVNL
KSA9PSBYRU5fRE9NQ1RMX1BGSU5GT19YVEFCCi0gICAgICAgICAgICB8fChidWYtPnBmbl90eXBl
c1tpXSAmIFhFTl9ET01DVExfUEZJTkZPX0xUQUJfTUFTSykgPT0gWEVOX0RPTUNUTF9QRklORk9f
WEFMTE9DKQorICAgIHsKKyAgICAgICAgdW5zaWduZWQgbG9uZyBwYWdldHlwZTsKKworICAgICAg
ICBwYWdldHlwZSA9IGJ1Zi0+cGZuX3R5cGVzW2ldICYgWEVOX0RPTUNUTF9QRklORk9fTFRBQl9N
QVNLOworICAgICAgICBpZiAoIHBhZ2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX1hUQUIgfHwK
KyAgICAgICAgICAgICBwYWdldHlwZSA9PSBYRU5fRE9NQ1RMX1BGSU5GT19CUk9LRU4gfHwKKyAg
ICAgICAgICAgICBwYWdldHlwZSA9PSBYRU5fRE9NQ1RMX1BGSU5GT19YQUxMT0MgKQogICAgICAg
ICAgICAgLS1jb3VudHBhZ2VzOworICAgIH0KIAogICAgIGlmICghY291bnRwYWdlcykKICAgICAg
ICAgcmV0dXJuIGNvdW50OwpAQCAtMTIwMCw2ICsxMjA2LDE3IEBACiAgICAgICAgICAgICAvKiBh
IGJvZ3VzL3VubWFwcGVkL2FsbG9jYXRlLW9ubHkgcGFnZTogc2tpcCBpdCAqLwogICAgICAgICAg
ICAgY29udGludWU7CiAKKyAgICAgICAgaWYgKCBwYWdldHlwZSA9PSBYRU5fRE9NQ1RMX1BGSU5G
T19CUk9LRU4gKQorICAgICAgICB7CisgICAgICAgICAgICBpZiAoIHhjX3NldF9icm9rZW5fcGFn
ZV9wMm0oeGNoLCBkb20sIHBmbikgKQorICAgICAgICAgICAgeworICAgICAgICAgICAgICAgIEVS
Uk9SKCJTZXQgcDJtIGZvciBicm9rZW4gcGFnZSBmYWlsZWQsICIKKyAgICAgICAgICAgICAgICAg
ICAgICAiZG9tPSVkLCBwZm49JWx4XG4iLCBkb20sIHBmbik7CisgICAgICAgICAgICAgICAgZ290
byBlcnJfbWFwcGVkOworICAgICAgICAgICAgfQorICAgICAgICAgICAgY29udGludWU7CisgICAg
ICAgIH0KKwogICAgICAgICBpZiAocGZuX2VycltpXSkKICAgICAgICAgewogICAgICAgICAgICAg
RVJST1IoInVuZXhwZWN0ZWQgUEZOIG1hcHBpbmcgZmFpbHVyZSBwZm4gJWx4IG1hcF9tZm4gJWx4
IHAybV9tZm4gJWx4IiwKZGlmZiAtciBlODRhNzlkMTFkN2EgdG9vbHMvbGlieGMveGNfZG9tYWlu
X3NhdmUuYwotLS0gYS90b29scy9saWJ4Yy94Y19kb21haW5fc2F2ZS5jCVRodSBOb3YgMDEgMDE6
NDE6MDMgMjAxMiArMDgwMAorKysgYi90b29scy9saWJ4Yy94Y19kb21haW5fc2F2ZS5jCVRodSBO
b3YgMDEgMDc6NTI6NDEgMjAxMiArMDgwMApAQCAtMTI3Nyw2ICsxMjc3LDEzIEBACiAgICAgICAg
ICAgICAgICAgaWYgKCAhaHZtICkKICAgICAgICAgICAgICAgICAgICAgZ21mbiA9IHBmbl90b19t
Zm4oZ21mbik7CiAKKyAgICAgICAgICAgICAgICBpZiAoIHBmbl90eXBlW2pdID09IFhFTl9ET01D
VExfUEZJTkZPX0JST0tFTiApCisgICAgICAgICAgICAgICAgeworICAgICAgICAgICAgICAgICAg
ICBwZm5fdHlwZVtqXSB8PSBwZm5fYmF0Y2hbal07CisgICAgICAgICAgICAgICAgICAgICsrcnVu
OworICAgICAgICAgICAgICAgICAgICBjb250aW51ZTsKKyAgICAgICAgICAgICAgICB9CisKICAg
ICAgICAgICAgICAgICBpZiAoIHBmbl9lcnJbal0gKQogICAgICAgICAgICAgICAgIHsKICAgICAg
ICAgICAgICAgICAgICAgaWYgKCBwZm5fdHlwZVtqXSA9PSBYRU5fRE9NQ1RMX1BGSU5GT19YVEFC
ICkKQEAgLTEzNzEsOCArMTM3OCwxMiBAQAogICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAg
ICAgICAgICAgfQogCi0gICAgICAgICAgICAgICAgLyogc2tpcCBwYWdlcyB0aGF0IGFyZW4ndCBw
cmVzZW50IG9yIGFyZSBhbGxvYy1vbmx5ICovCisgICAgICAgICAgICAgICAgLyoKKyAgICAgICAg
ICAgICAgICAgKiBza2lwIHBhZ2VzIHRoYXQgYXJlbid0IHByZXNlbnQsCisgICAgICAgICAgICAg
ICAgICogb3IgYXJlIGJyb2tlbiwgb3IgYXJlIGFsbG9jLW9ubHkKKyAgICAgICAgICAgICAgICAg
Ki8KICAgICAgICAgICAgICAgICBpZiAoIHBhZ2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX1hU
QUIKKyAgICAgICAgICAgICAgICAgICAgfHwgcGFnZXR5cGUgPT0gWEVOX0RPTUNUTF9QRklORk9f
QlJPS0VOCiAgICAgICAgICAgICAgICAgICAgIHx8IHBhZ2V0eXBlID09IFhFTl9ET01DVExfUEZJ
TkZPX1hBTExPQyApCiAgICAgICAgICAgICAgICAgICAgIGNvbnRpbnVlOwogCmRpZmYgLXIgZTg0
YTc5ZDExZDdhIHRvb2xzL2xpYnhjL3hlbmN0cmwuaAotLS0gYS90b29scy9saWJ4Yy94ZW5jdHJs
LmgJVGh1IE5vdiAwMSAwMTo0MTowMyAyMDEyICswODAwCisrKyBiL3Rvb2xzL2xpYnhjL3hlbmN0
cmwuaAlUaHUgTm92IDAxIDA3OjUyOjQxIDIwMTIgKzA4MDAKQEAgLTU3NSw2ICs1NzUsMTcgQEAK
ICAgICAgICAgICAgICAgICAgICAgICAgICAgeGNfZG9tYWluaW5mb190ICppbmZvKTsKIAogLyoq
CisgKiBUaGlzIGZ1bmN0aW9uIHNldCBwMm0gZm9yIGJyb2tlbiBwYWdlCisgKiAmcGFybSB4Y2gg
YSBoYW5kbGUgdG8gYW4gb3BlbiBoeXBlcnZpc29yIGludGVyZmFjZQorICogQHBhcm0gZG9taWQg
dGhlIGRvbWFpbiBpZCB3aGljaCBicm9rZW4gcGFnZSBiZWxvbmcgdG8KKyAqIEBwYXJtIHBmbiB0
aGUgcGZuIG51bWJlciBvZiB0aGUgYnJva2VuIHBhZ2UKKyAqIEByZXR1cm4gMCBvbiBzdWNjZXNz
LCAtMSBvbiBmYWlsdXJlCisgKi8KK2ludCB4Y19zZXRfYnJva2VuX3BhZ2VfcDJtKHhjX2ludGVy
ZmFjZSAqeGNoLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZG9taWQsCisg
ICAgICAgICAgICAgICAgICAgICAgICAgICB1bnNpZ25lZCBsb25nIHBmbik7CisKKy8qKgogICog
VGhpcyBmdW5jdGlvbiByZXR1cm5zIGluZm9ybWF0aW9uIGFib3V0IHRoZSBjb250ZXh0IG9mIGEg
aHZtIGRvbWFpbgogICogQHBhcm0geGNoIGEgaGFuZGxlIHRvIGFuIG9wZW4gaHlwZXJ2aXNvciBp
bnRlcmZhY2UKICAqIEBwYXJtIGRvbWlkIHRoZSBkb21haW4gdG8gZ2V0IGluZm9ybWF0aW9uIGZy
b20KZGlmZiAtciBlODRhNzlkMTFkN2EgeGVuL2FyY2gveDg2L2RvbWN0bC5jCi0tLSBhL3hlbi9h
cmNoL3g4Ni9kb21jdGwuYwlUaHUgTm92IDAxIDAxOjQxOjAzIDIwMTIgKzA4MDAKKysrIGIveGVu
L2FyY2gveDg2L2RvbWN0bC5jCVRodSBOb3YgMDEgMDc6NTI6NDEgMjAxMiArMDgwMApAQCAtMjA5
LDEyICsyMDksMTggQEAKICAgICAgICAgICAgICAgICBmb3IgKCBqID0gMDsgaiA8IGs7IGorKyAp
CiAgICAgICAgICAgICAgICAgewogICAgICAgICAgICAgICAgICAgICB1bnNpZ25lZCBsb25nIHR5
cGUgPSAwOworICAgICAgICAgICAgICAgICAgICBwMm1fdHlwZV90IHQ7CiAKLSAgICAgICAgICAg
ICAgICAgICAgcGFnZSA9IGdldF9wYWdlX2Zyb21fZ2ZuKGQsIGFycltqXSwgTlVMTCwgUDJNX0FM
TE9DKTsKKyAgICAgICAgICAgICAgICAgICAgcGFnZSA9IGdldF9wYWdlX2Zyb21fZ2ZuKGQsIGFy
cltqXSwgJnQsIFAyTV9BTExPQyk7CiAKICAgICAgICAgICAgICAgICAgICAgaWYgKCB1bmxpa2Vs
eSghcGFnZSkgfHwKICAgICAgICAgICAgICAgICAgICAgICAgICB1bmxpa2VseShpc194ZW5faGVh
cF9wYWdlKHBhZ2UpKSApCi0gICAgICAgICAgICAgICAgICAgICAgICB0eXBlID0gWEVOX0RPTUNU
TF9QRklORk9fWFRBQjsKKyAgICAgICAgICAgICAgICAgICAgeworICAgICAgICAgICAgICAgICAg
ICAgICAgaWYgKCBwMm1faXNfYnJva2VuKHQpICkKKyAgICAgICAgICAgICAgICAgICAgICAgICAg
ICB0eXBlID0gWEVOX0RPTUNUTF9QRklORk9fQlJPS0VOOworICAgICAgICAgICAgICAgICAgICAg
ICAgZWxzZQorICAgICAgICAgICAgICAgICAgICAgICAgICAgIHR5cGUgPSBYRU5fRE9NQ1RMX1BG
SU5GT19YVEFCOworICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAgICAgIGVs
c2UKICAgICAgICAgICAgICAgICAgICAgewogICAgICAgICAgICAgICAgICAgICAgICAgc3dpdGNo
KCBwYWdlLT51LmludXNlLnR5cGVfaW5mbyAmIFBHVF90eXBlX21hc2sgKQpAQCAtMjM1LDYgKzI0
MSw5IEBACiAKICAgICAgICAgICAgICAgICAgICAgICAgIGlmICggcGFnZS0+dS5pbnVzZS50eXBl
X2luZm8gJiBQR1RfcGlubmVkICkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0eXBlIHw9
IFhFTl9ET01DVExfUEZJTkZPX0xQSU5UQUI7CisKKyAgICAgICAgICAgICAgICAgICAgICAgIGlm
ICggcGFnZS0+Y291bnRfaW5mbyAmIFBHQ19icm9rZW4gKQorICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHR5cGUgPSBYRU5fRE9NQ1RMX1BGSU5GT19CUk9LRU47CiAgICAgICAgICAgICAgICAg
ICAgIH0KIAogICAgICAgICAgICAgICAgICAgICBpZiAoIHBhZ2UgKQpAQCAtMTU2OCw2ICsxNTc3
LDI5IEBACiAgICAgfQogICAgIGJyZWFrOwogCisgICAgY2FzZSBYRU5fRE9NQ1RMX3NldF9icm9r
ZW5fcGFnZV9wMm06CisgICAgeworICAgICAgICBzdHJ1Y3QgZG9tYWluICpkOworICAgICAgICAK
KyAgICAgICAgZCA9IHJjdV9sb2NrX2RvbWFpbl9ieV9pZChkb21jdGwtPmRvbWFpbik7CisgICAg
ICAgIGlmICggZCAhPSBOVUxMICkKKyAgICAgICAgeworICAgICAgICAgICAgcDJtX3R5cGVfdCBw
dDsKKyAgICAgICAgICAgIHVuc2lnbmVkIGxvbmcgcGZuID0gZG9tY3RsLT51LnNldF9icm9rZW5f
cGFnZV9wMm0ucGZuOworICAgICAgICAgICAgbWZuX3QgbWZuID0gZ2V0X2dmbl9xdWVyeShkLCBw
Zm4sICZwdCk7CisKKyAgICAgICAgICAgIGlmICggdW5saWtlbHkoIW1mbl92YWxpZChtZm5feCht
Zm4pKSB8fCAhcDJtX2lzX3JhbShwdCkgfHwKKyAgICAgICAgICAgICAgICAgICAgICAgICAocDJt
X2NoYW5nZV90eXBlKGQsIHBmbiwgcHQsIHAybV9yYW1fYnJva2VuKSAhPSBwdCkpICkKKyAgICAg
ICAgICAgICAgICByZXQgPSAtRUlOVkFMOworCisgICAgICAgICAgICBwdXRfZ2ZuKGQsIHBmbik7
CisgICAgICAgICAgICByY3VfdW5sb2NrX2RvbWFpbihkKTsKKyAgICAgICAgfQorICAgICAgICBl
bHNlCisgICAgICAgICAgICByZXQgPSAtRVNSQ0g7CisgICAgfQorICAgIGJyZWFrOworCiAgICAg
ZGVmYXVsdDoKICAgICAgICAgcmV0ID0gaW9tbXVfZG9fZG9tY3RsKGRvbWN0bCwgdV9kb21jdGwp
OwogICAgICAgICBicmVhazsKZGlmZiAtciBlODRhNzlkMTFkN2EgeGVuL2luY2x1ZGUvcHVibGlj
L2RvbWN0bC5oCi0tLSBhL3hlbi9pbmNsdWRlL3B1YmxpYy9kb21jdGwuaAlUaHUgTm92IDAxIDAx
OjQxOjAzIDIwMTIgKzA4MDAKKysrIGIveGVuL2luY2x1ZGUvcHVibGljL2RvbWN0bC5oCVRodSBO
b3YgMDEgMDc6NTI6NDEgMjAxMiArMDgwMApAQCAtMTM2LDYgKzEzNiw3IEBACiAjZGVmaW5lIFhF
Tl9ET01DVExfUEZJTkZPX0xQSU5UQUIgKDB4MVU8PDMxKQogI2RlZmluZSBYRU5fRE9NQ1RMX1BG
SU5GT19YVEFCICAgICgweGZVPDwyOCkgLyogaW52YWxpZCBwYWdlICovCiAjZGVmaW5lIFhFTl9E
T01DVExfUEZJTkZPX1hBTExPQyAgKDB4ZVU8PDI4KSAvKiBhbGxvY2F0ZS1vbmx5IHBhZ2UgKi8K
KyNkZWZpbmUgWEVOX0RPTUNUTF9QRklORk9fQlJPS0VOICAoMHhkVTw8MjgpIC8qIGJyb2tlbiBw
YWdlICovCiAjZGVmaW5lIFhFTl9ET01DVExfUEZJTkZPX1BBR0VEVEFCICgweDhVPDwyOCkKICNk
ZWZpbmUgWEVOX0RPTUNUTF9QRklORk9fTFRBQl9NQVNLICgweGZVPDwyOCkKIApAQCAtODM1LDYg
KzgzNiwxMiBAQAogdHlwZWRlZiBzdHJ1Y3QgeGVuX2RvbWN0bF9zZXRfYWNjZXNzX3JlcXVpcmVk
IHhlbl9kb21jdGxfc2V0X2FjY2Vzc19yZXF1aXJlZF90OwogREVGSU5FX1hFTl9HVUVTVF9IQU5E
TEUoeGVuX2RvbWN0bF9zZXRfYWNjZXNzX3JlcXVpcmVkX3QpOwogCitzdHJ1Y3QgeGVuX2RvbWN0
bF9zZXRfYnJva2VuX3BhZ2VfcDJtIHsKKyAgICB1aW50NjRfYWxpZ25lZF90IHBmbjsKK307Cit0
eXBlZGVmIHN0cnVjdCB4ZW5fZG9tY3RsX3NldF9icm9rZW5fcGFnZV9wMm0geGVuX2RvbWN0bF9z
ZXRfYnJva2VuX3BhZ2VfcDJtX3Q7CitERUZJTkVfWEVOX0dVRVNUX0hBTkRMRSh4ZW5fZG9tY3Rs
X3NldF9icm9rZW5fcGFnZV9wMm1fdCk7CisKIHN0cnVjdCB4ZW5fZG9tY3RsIHsKICAgICB1aW50
MzJfdCBjbWQ7CiAjZGVmaW5lIFhFTl9ET01DVExfY3JlYXRlZG9tYWluICAgICAgICAgICAgICAg
ICAgIDEKQEAgLTkwMCw2ICs5MDcsNyBAQAogI2RlZmluZSBYRU5fRE9NQ1RMX3NldF9hY2Nlc3Nf
cmVxdWlyZWQgICAgICAgICAgIDY0CiAjZGVmaW5lIFhFTl9ET01DVExfYXVkaXRfcDJtICAgICAg
ICAgICAgICAgICAgICAgNjUKICNkZWZpbmUgWEVOX0RPTUNUTF9zZXRfdmlycV9oYW5kbGVyICAg
ICAgICAgICAgICA2NgorI2RlZmluZSBYRU5fRE9NQ1RMX3NldF9icm9rZW5fcGFnZV9wMm0gICAg
ICAgICAgIDY3CiAjZGVmaW5lIFhFTl9ET01DVExfZ2Ric3hfZ3Vlc3RtZW1pbyAgICAgICAgICAg
IDEwMDAKICNkZWZpbmUgWEVOX0RPTUNUTF9nZGJzeF9wYXVzZXZjcHUgICAgICAgICAgICAgMTAw
MQogI2RlZmluZSBYRU5fRE9NQ1RMX2dkYnN4X3VucGF1c2V2Y3B1ICAgICAgICAgICAxMDAyCkBA
IC05NTUsNiArOTYzLDcgQEAKICAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfYXVkaXRfcDJtICAg
ICAgICAgYXVkaXRfcDJtOwogICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF9zZXRfdmlycV9oYW5k
bGVyICBzZXRfdmlycV9oYW5kbGVyOwogICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF9nZGJzeF9t
ZW1pbyAgICAgICBnZGJzeF9ndWVzdF9tZW1pbzsKKyAgICAgICAgc3RydWN0IHhlbl9kb21jdGxf
c2V0X2Jyb2tlbl9wYWdlX3AybSBzZXRfYnJva2VuX3BhZ2VfcDJtOwogICAgICAgICBzdHJ1Y3Qg
eGVuX2RvbWN0bF9nZGJzeF9wYXVzZXVucF92Y3B1IGdkYnN4X3BhdXNldW5wX3ZjcHU7CiAgICAg
ICAgIHN0cnVjdCB4ZW5fZG9tY3RsX2dkYnN4X2RvbXN0YXR1cyAgIGdkYnN4X2RvbXN0YXR1czsK
ICAgICAgICAgdWludDhfdCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcGFkWzEyOF07Cg==

--_002_DE8DF0795D48FD4CA783C40EC8292335376A97SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC8292335376A97SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Wed Oct 31 16:15:43 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 16:15:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTawV-0005ZB-6C; Wed, 31 Oct 2012 16:14:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTawT-0005Z6-QG
	for xen-devel@lists.xen.org; Wed, 31 Oct 2012 16:14:58 +0000
Received: from [85.158.139.83:43692] by server-10.bemta-5.messagelabs.com id
	CB/11-01025-08E41905; Wed, 31 Oct 2012 16:14:56 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1351700090!20941513!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjI1NTQy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30826 invoked from network); 31 Oct 2012 16:14:51 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-11.tower-182.messagelabs.com with SMTP;
	31 Oct 2012 16:14:51 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 31 Oct 2012 09:14:48 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,687,1344236400"; d="scan'208";a="162927283"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by AZSMGA002.ch.intel.com with ESMTP; 31 Oct 2012 09:14:48 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 31 Oct 2012 09:14:47 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.186]) with mapi id
	14.01.0355.002; Thu, 1 Nov 2012 00:14:46 +0800
From: "Liu, Jinsong" 
To: Jan Beulich 
Thread-Topic: [PATCH 01/02] Handles broken page occurred before migration
Thread-Index: AQHNt2WLIm/L3sGKQI2O8U05ITu8CJfTlb+w
Date: Wed, 31 Oct 2012 16:14:45 +0000
Message-ID: 
References: 
	<50912B5F02000078000A5B8E@nat28.tlf.novell.com>
In-Reply-To: <50912B5F02000078000A5B8E@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: multipart/mixed;
	boundary="_002_DE8DF0795D48FD4CA783C40EC8292335376A97SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: George Dunlap ,
	Ian Jackson ,
	xen-devel 
Subject: Re: [Xen-devel] [PATCH 01/02] Handles broken page occurred before
	migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC8292335376A97SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

[snip]
>=20
> If you use scope restricted local variables (which I appreciate),
> please declare them in the innermost possible scope, ...
>=20
>> +
>> +        d =3D rcu_lock_domain_by_id(domctl->domain); +        if ( d
>> !=3D NULL ) +        {
>> +            pfn =3D domctl->u.set_broken_page_p2m.pfn; +
>> +            mfn =3D get_gfn_query(d, pfn, &pt);
>=20
> ... i.e. here (and then both assignments can become initializers
> at once).
>=20
>> +            if ( !mfn_valid(mfn_x(mfn)) || !p2m_is_ram(pt) ) +    =20
>> { +                put_gfn(d, pfn);
>> +                rcu_unlock_domain(d);
>> +                ret =3D -EINVAL;
>> +                break;
>> +            }
>> +
>> +            if ( p2m_change_type(d, pfn, pt, p2m_ram_broken) !=3D pt )
>> +                ret =3D -EINVAL;
>=20
> The two if() conditions can be easily joined (the more that they
> both produce -EINVAL).
>=20

Thanks, updated as attached.

Jinsong

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Handles broken page occurred before migration

This patch handles guest broken page which occurred before migration.

At sender, the broken page would be mapped but not copied to target
(otherwise it may trigger more serious error, say, SRAR error).
While its pfn_type and pfn number would be transferred to target
so that target take appropriate action.

At target, it would set p2m as p2m_ram_broken for broken page, so that
if guest access the broken page again, it would kill itself as expected.

Signed-off-by: Liu, Jinsong 

diff -r e84a79d11d7a tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c	Thu Nov 01 01:41:03 2012 +0800
+++ b/tools/libxc/xc_domain.c	Thu Nov 01 07:52:41 2012 +0800
@@ -283,6 +283,22 @@
     return ret;
 }
=20
+/* set broken page p2m */
+int xc_set_broken_page_p2m(xc_interface *xch,
+                           uint32_t domid,
+                           unsigned long pfn)
+{
+    int ret;
+    DECLARE_DOMCTL;
+
+    domctl.cmd =3D XEN_DOMCTL_set_broken_page_p2m;
+    domctl.domain =3D (domid_t)domid;
+    domctl.u.set_broken_page_p2m.pfn =3D pfn;
+    ret =3D do_domctl(xch, &domctl);
+
+    return ret ? -1 : 0;
+}
+
 /* get info from hvm guest for save */
 int xc_domain_hvm_getcontext(xc_interface *xch,
                              uint32_t domid,
diff -r e84a79d11d7a tools/libxc/xc_domain_restore.c
--- a/tools/libxc/xc_domain_restore.c	Thu Nov 01 01:41:03 2012 +0800
+++ b/tools/libxc/xc_domain_restore.c	Thu Nov 01 07:52:41 2012 +0800
@@ -962,9 +962,15 @@
=20
     countpages =3D count;
     for (i =3D oldcount; i < buf->nr_pages; ++i)
-        if ((buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) =3D=3D XEN_D=
OMCTL_PFINFO_XTAB
-            ||(buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) =3D=3D XEN=
_DOMCTL_PFINFO_XALLOC)
+    {
+        unsigned long pagetype;
+
+        pagetype =3D buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK;
+        if ( pagetype =3D=3D XEN_DOMCTL_PFINFO_XTAB ||
+             pagetype =3D=3D XEN_DOMCTL_PFINFO_BROKEN ||
+             pagetype =3D=3D XEN_DOMCTL_PFINFO_XALLOC )
             --countpages;
+    }
=20
     if (!countpages)
         return count;
@@ -1200,6 +1206,17 @@
             /* a bogus/unmapped/allocate-only page: skip it */
             continue;
=20
+        if ( pagetype =3D=3D XEN_DOMCTL_PFINFO_BROKEN )
+        {
+            if ( xc_set_broken_page_p2m(xch, dom, pfn) )
+            {
+                ERROR("Set p2m for broken page failed, "
+                      "dom=3D%d, pfn=3D%lx\n", dom, pfn);
+                goto err_mapped;
+            }
+            continue;
+        }
+
         if (pfn_err[i])
         {
             ERROR("unexpected PFN mapping failure pfn %lx map_mfn %lx p2m_=
mfn %lx",
diff -r e84a79d11d7a tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Thu Nov 01 01:41:03 2012 +0800
+++ b/tools/libxc/xc_domain_save.c	Thu Nov 01 07:52:41 2012 +0800
@@ -1277,6 +1277,13 @@
                 if ( !hvm )
                     gmfn =3D pfn_to_mfn(gmfn);
=20
+                if ( pfn_type[j] =3D=3D XEN_DOMCTL_PFINFO_BROKEN )
+                {
+                    pfn_type[j] |=3D pfn_batch[j];
+                    ++run;
+                    continue;
+                }
+
                 if ( pfn_err[j] )
                 {
                     if ( pfn_type[j] =3D=3D XEN_DOMCTL_PFINFO_XTAB )
@@ -1371,8 +1378,12 @@
                     }
                 }
=20
-                /* skip pages that aren't present or are alloc-only */
+                /*
+                 * skip pages that aren't present,
+                 * or are broken, or are alloc-only
+                 */
                 if ( pagetype =3D=3D XEN_DOMCTL_PFINFO_XTAB
+                    || pagetype =3D=3D XEN_DOMCTL_PFINFO_BROKEN
                     || pagetype =3D=3D XEN_DOMCTL_PFINFO_XALLOC )
                     continue;
=20
diff -r e84a79d11d7a tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Thu Nov 01 01:41:03 2012 +0800
+++ b/tools/libxc/xenctrl.h	Thu Nov 01 07:52:41 2012 +0800
@@ -575,6 +575,17 @@
                           xc_domaininfo_t *info);
=20
 /**
+ * This function set p2m for broken page
+ * &parm xch a handle to an open hypervisor interface
+ * @parm domid the domain id which broken page belong to
+ * @parm pfn the pfn number of the broken page
+ * @return 0 on success, -1 on failure
+ */
+int xc_set_broken_page_p2m(xc_interface *xch,
+                           uint32_t domid,
+                           unsigned long pfn);
+
+/**
  * This function returns information about the context of a hvm domain
  * @parm xch a handle to an open hypervisor interface
  * @parm domid the domain to get information from
diff -r e84a79d11d7a xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c	Thu Nov 01 01:41:03 2012 +0800
+++ b/xen/arch/x86/domctl.c	Thu Nov 01 07:52:41 2012 +0800
@@ -209,12 +209,18 @@
                 for ( j =3D 0; j < k; j++ )
                 {
                     unsigned long type =3D 0;
+                    p2m_type_t t;
=20
-                    page =3D get_page_from_gfn(d, arr[j], NULL, P2M_ALLOC)=
;
+                    page =3D get_page_from_gfn(d, arr[j], &t, P2M_ALLOC);
=20
                     if ( unlikely(!page) ||
                          unlikely(is_xen_heap_page(page)) )
-                        type =3D XEN_DOMCTL_PFINFO_XTAB;
+                    {
+                        if ( p2m_is_broken(t) )
+                            type =3D XEN_DOMCTL_PFINFO_BROKEN;
+                        else
+                            type =3D XEN_DOMCTL_PFINFO_XTAB;
+                    }
                     else
                     {
                         switch( page->u.inuse.type_info & PGT_type_mask )
@@ -235,6 +241,9 @@
=20
                         if ( page->u.inuse.type_info & PGT_pinned )
                             type |=3D XEN_DOMCTL_PFINFO_LPINTAB;
+
+                        if ( page->count_info & PGC_broken )
+                            type =3D XEN_DOMCTL_PFINFO_BROKEN;
                     }
=20
                     if ( page )
@@ -1568,6 +1577,29 @@
     }
     break;
=20
+    case XEN_DOMCTL_set_broken_page_p2m:
+    {
+        struct domain *d;
+       =20
+        d =3D rcu_lock_domain_by_id(domctl->domain);
+        if ( d !=3D NULL )
+        {
+            p2m_type_t pt;
+            unsigned long pfn =3D domctl->u.set_broken_page_p2m.pfn;
+            mfn_t mfn =3D get_gfn_query(d, pfn, &pt);
+
+            if ( unlikely(!mfn_valid(mfn_x(mfn)) || !p2m_is_ram(pt) ||
+                         (p2m_change_type(d, pfn, pt, p2m_ram_broken) !=3D=
 pt)) )
+                ret =3D -EINVAL;
+
+            put_gfn(d, pfn);
+            rcu_unlock_domain(d);
+        }
+        else
+            ret =3D -ESRCH;
+    }
+    break;
+
     default:
         ret =3D iommu_do_domctl(domctl, u_domctl);
         break;
diff -r e84a79d11d7a xen/include/public/domctl.h
--- a/xen/include/public/domctl.h	Thu Nov 01 01:41:03 2012 +0800
+++ b/xen/include/public/domctl.h	Thu Nov 01 07:52:41 2012 +0800
@@ -136,6 +136,7 @@
 #define XEN_DOMCTL_PFINFO_LPINTAB (0x1U<<31)
 #define XEN_DOMCTL_PFINFO_XTAB    (0xfU<<28) /* invalid page */
 #define XEN_DOMCTL_PFINFO_XALLOC  (0xeU<<28) /* allocate-only page */
+#define XEN_DOMCTL_PFINFO_BROKEN  (0xdU<<28) /* broken page */
 #define XEN_DOMCTL_PFINFO_PAGEDTAB (0x8U<<28)
 #define XEN_DOMCTL_PFINFO_LTAB_MASK (0xfU<<28)
=20
@@ -835,6 +836,12 @@
 typedef struct xen_domctl_set_access_required xen_domctl_set_access_requir=
ed_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_access_required_t);
=20
+struct xen_domctl_set_broken_page_p2m {
+    uint64_aligned_t pfn;
+};
+typedef struct xen_domctl_set_broken_page_p2m xen_domctl_set_broken_page_p=
2m_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_broken_page_p2m_t);
+
 struct xen_domctl {
     uint32_t cmd;
 #define XEN_DOMCTL_createdomain                   1
@@ -900,6 +907,7 @@
 #define XEN_DOMCTL_set_access_required           64
 #define XEN_DOMCTL_audit_p2m                     65
 #define XEN_DOMCTL_set_virq_handler              66
+#define XEN_DOMCTL_set_broken_page_p2m           67
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -955,6 +963,7 @@
         struct xen_domctl_audit_p2m         audit_p2m;
         struct xen_domctl_set_virq_handler  set_virq_handler;
         struct xen_domctl_gdbsx_memio       gdbsx_guest_memio;
+        struct xen_domctl_set_broken_page_p2m set_broken_page_p2m;
         struct xen_domctl_gdbsx_pauseunp_vcpu gdbsx_pauseunp_vcpu;
         struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
         uint8_t                             pad[128];=

--_002_DE8DF0795D48FD4CA783C40EC8292335376A97SHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="broken_page_occur_before_migration.patch"
Content-Description: broken_page_occur_before_migration.patch
Content-Disposition: attachment;
	filename="broken_page_occur_before_migration.patch"; size=8605;
	creation-date="Wed, 31 Oct 2012 16:05:52 GMT";
	modification-date="Wed, 31 Oct 2012 23:52:42 GMT"
Content-Transfer-Encoding: base64

SGFuZGxlcyBicm9rZW4gcGFnZSBvY2N1cnJlZCBiZWZvcmUgbWlncmF0aW9uCgpUaGlzIHBhdGNo
IGhhbmRsZXMgZ3Vlc3QgYnJva2VuIHBhZ2Ugd2hpY2ggb2NjdXJyZWQgYmVmb3JlIG1pZ3JhdGlv
bi4KCkF0IHNlbmRlciwgdGhlIGJyb2tlbiBwYWdlIHdvdWxkIGJlIG1hcHBlZCBidXQgbm90IGNv
cGllZCB0byB0YXJnZXQKKG90aGVyd2lzZSBpdCBtYXkgdHJpZ2dlciBtb3JlIHNlcmlvdXMgZXJy
b3IsIHNheSwgU1JBUiBlcnJvcikuCldoaWxlIGl0cyBwZm5fdHlwZSBhbmQgcGZuIG51bWJlciB3
b3VsZCBiZSB0cmFuc2ZlcnJlZCB0byB0YXJnZXQKc28gdGhhdCB0YXJnZXQgdGFrZSBhcHByb3By
aWF0ZSBhY3Rpb24uCgpBdCB0YXJnZXQsIGl0IHdvdWxkIHNldCBwMm0gYXMgcDJtX3JhbV9icm9r
ZW4gZm9yIGJyb2tlbiBwYWdlLCBzbyB0aGF0CmlmIGd1ZXN0IGFjY2VzcyB0aGUgYnJva2VuIHBh
Z2UgYWdhaW4sIGl0IHdvdWxkIGtpbGwgaXRzZWxmIGFzIGV4cGVjdGVkLgoKU2lnbmVkLW9mZi1i
eTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+CgpkaWZmIC1yIGU4NGE3OWQx
MWQ3YSB0b29scy9saWJ4Yy94Y19kb21haW4uYwotLS0gYS90b29scy9saWJ4Yy94Y19kb21haW4u
YwlUaHUgTm92IDAxIDAxOjQxOjAzIDIwMTIgKzA4MDAKKysrIGIvdG9vbHMvbGlieGMveGNfZG9t
YWluLmMJVGh1IE5vdiAwMSAwNzo1Mjo0MSAyMDEyICswODAwCkBAIC0yODMsNiArMjgzLDIyIEBA
CiAgICAgcmV0dXJuIHJldDsKIH0KIAorLyogc2V0IGJyb2tlbiBwYWdlIHAybSAqLworaW50IHhj
X3NldF9icm9rZW5fcGFnZV9wMm0oeGNfaW50ZXJmYWNlICp4Y2gsCisgICAgICAgICAgICAgICAg
ICAgICAgICAgICB1aW50MzJfdCBkb21pZCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgIHVu
c2lnbmVkIGxvbmcgcGZuKQoreworICAgIGludCByZXQ7CisgICAgREVDTEFSRV9ET01DVEw7CisK
KyAgICBkb21jdGwuY21kID0gWEVOX0RPTUNUTF9zZXRfYnJva2VuX3BhZ2VfcDJtOworICAgIGRv
bWN0bC5kb21haW4gPSAoZG9taWRfdClkb21pZDsKKyAgICBkb21jdGwudS5zZXRfYnJva2VuX3Bh
Z2VfcDJtLnBmbiA9IHBmbjsKKyAgICByZXQgPSBkb19kb21jdGwoeGNoLCAmZG9tY3RsKTsKKwor
ICAgIHJldHVybiByZXQgPyAtMSA6IDA7Cit9CisKIC8qIGdldCBpbmZvIGZyb20gaHZtIGd1ZXN0
IGZvciBzYXZlICovCiBpbnQgeGNfZG9tYWluX2h2bV9nZXRjb250ZXh0KHhjX2ludGVyZmFjZSAq
eGNoLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJfdCBkb21pZCwKZGlmZiAt
ciBlODRhNzlkMTFkN2EgdG9vbHMvbGlieGMveGNfZG9tYWluX3Jlc3RvcmUuYwotLS0gYS90b29s
cy9saWJ4Yy94Y19kb21haW5fcmVzdG9yZS5jCVRodSBOb3YgMDEgMDE6NDE6MDMgMjAxMiArMDgw
MAorKysgYi90b29scy9saWJ4Yy94Y19kb21haW5fcmVzdG9yZS5jCVRodSBOb3YgMDEgMDc6NTI6
NDEgMjAxMiArMDgwMApAQCAtOTYyLDkgKzk2MiwxNSBAQAogCiAgICAgY291bnRwYWdlcyA9IGNv
dW50OwogICAgIGZvciAoaSA9IG9sZGNvdW50OyBpIDwgYnVmLT5ucl9wYWdlczsgKytpKQotICAg
ICAgICBpZiAoKGJ1Zi0+cGZuX3R5cGVzW2ldICYgWEVOX0RPTUNUTF9QRklORk9fTFRBQl9NQVNL
KSA9PSBYRU5fRE9NQ1RMX1BGSU5GT19YVEFCCi0gICAgICAgICAgICB8fChidWYtPnBmbl90eXBl
c1tpXSAmIFhFTl9ET01DVExfUEZJTkZPX0xUQUJfTUFTSykgPT0gWEVOX0RPTUNUTF9QRklORk9f
WEFMTE9DKQorICAgIHsKKyAgICAgICAgdW5zaWduZWQgbG9uZyBwYWdldHlwZTsKKworICAgICAg
ICBwYWdldHlwZSA9IGJ1Zi0+cGZuX3R5cGVzW2ldICYgWEVOX0RPTUNUTF9QRklORk9fTFRBQl9N
QVNLOworICAgICAgICBpZiAoIHBhZ2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX1hUQUIgfHwK
KyAgICAgICAgICAgICBwYWdldHlwZSA9PSBYRU5fRE9NQ1RMX1BGSU5GT19CUk9LRU4gfHwKKyAg
ICAgICAgICAgICBwYWdldHlwZSA9PSBYRU5fRE9NQ1RMX1BGSU5GT19YQUxMT0MgKQogICAgICAg
ICAgICAgLS1jb3VudHBhZ2VzOworICAgIH0KIAogICAgIGlmICghY291bnRwYWdlcykKICAgICAg
ICAgcmV0dXJuIGNvdW50OwpAQCAtMTIwMCw2ICsxMjA2LDE3IEBACiAgICAgICAgICAgICAvKiBh
IGJvZ3VzL3VubWFwcGVkL2FsbG9jYXRlLW9ubHkgcGFnZTogc2tpcCBpdCAqLwogICAgICAgICAg
ICAgY29udGludWU7CiAKKyAgICAgICAgaWYgKCBwYWdldHlwZSA9PSBYRU5fRE9NQ1RMX1BGSU5G
T19CUk9LRU4gKQorICAgICAgICB7CisgICAgICAgICAgICBpZiAoIHhjX3NldF9icm9rZW5fcGFn
ZV9wMm0oeGNoLCBkb20sIHBmbikgKQorICAgICAgICAgICAgeworICAgICAgICAgICAgICAgIEVS
Uk9SKCJTZXQgcDJtIGZvciBicm9rZW4gcGFnZSBmYWlsZWQsICIKKyAgICAgICAgICAgICAgICAg
ICAgICAiZG9tPSVkLCBwZm49JWx4XG4iLCBkb20sIHBmbik7CisgICAgICAgICAgICAgICAgZ290
byBlcnJfbWFwcGVkOworICAgICAgICAgICAgfQorICAgICAgICAgICAgY29udGludWU7CisgICAg
ICAgIH0KKwogICAgICAgICBpZiAocGZuX2VycltpXSkKICAgICAgICAgewogICAgICAgICAgICAg
RVJST1IoInVuZXhwZWN0ZWQgUEZOIG1hcHBpbmcgZmFpbHVyZSBwZm4gJWx4IG1hcF9tZm4gJWx4
IHAybV9tZm4gJWx4IiwKZGlmZiAtciBlODRhNzlkMTFkN2EgdG9vbHMvbGlieGMveGNfZG9tYWlu
X3NhdmUuYwotLS0gYS90b29scy9saWJ4Yy94Y19kb21haW5fc2F2ZS5jCVRodSBOb3YgMDEgMDE6
NDE6MDMgMjAxMiArMDgwMAorKysgYi90b29scy9saWJ4Yy94Y19kb21haW5fc2F2ZS5jCVRodSBO
b3YgMDEgMDc6NTI6NDEgMjAxMiArMDgwMApAQCAtMTI3Nyw2ICsxMjc3LDEzIEBACiAgICAgICAg
ICAgICAgICAgaWYgKCAhaHZtICkKICAgICAgICAgICAgICAgICAgICAgZ21mbiA9IHBmbl90b19t
Zm4oZ21mbik7CiAKKyAgICAgICAgICAgICAgICBpZiAoIHBmbl90eXBlW2pdID09IFhFTl9ET01D
VExfUEZJTkZPX0JST0tFTiApCisgICAgICAgICAgICAgICAgeworICAgICAgICAgICAgICAgICAg
ICBwZm5fdHlwZVtqXSB8PSBwZm5fYmF0Y2hbal07CisgICAgICAgICAgICAgICAgICAgICsrcnVu
OworICAgICAgICAgICAgICAgICAgICBjb250aW51ZTsKKyAgICAgICAgICAgICAgICB9CisKICAg
ICAgICAgICAgICAgICBpZiAoIHBmbl9lcnJbal0gKQogICAgICAgICAgICAgICAgIHsKICAgICAg
ICAgICAgICAgICAgICAgaWYgKCBwZm5fdHlwZVtqXSA9PSBYRU5fRE9NQ1RMX1BGSU5GT19YVEFC
ICkKQEAgLTEzNzEsOCArMTM3OCwxMiBAQAogICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAg
ICAgICAgICAgfQogCi0gICAgICAgICAgICAgICAgLyogc2tpcCBwYWdlcyB0aGF0IGFyZW4ndCBw
cmVzZW50IG9yIGFyZSBhbGxvYy1vbmx5ICovCisgICAgICAgICAgICAgICAgLyoKKyAgICAgICAg
ICAgICAgICAgKiBza2lwIHBhZ2VzIHRoYXQgYXJlbid0IHByZXNlbnQsCisgICAgICAgICAgICAg
ICAgICogb3IgYXJlIGJyb2tlbiwgb3IgYXJlIGFsbG9jLW9ubHkKKyAgICAgICAgICAgICAgICAg
Ki8KICAgICAgICAgICAgICAgICBpZiAoIHBhZ2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX1hU
QUIKKyAgICAgICAgICAgICAgICAgICAgfHwgcGFnZXR5cGUgPT0gWEVOX0RPTUNUTF9QRklORk9f
QlJPS0VOCiAgICAgICAgICAgICAgICAgICAgIHx8IHBhZ2V0eXBlID09IFhFTl9ET01DVExfUEZJ
TkZPX1hBTExPQyApCiAgICAgICAgICAgICAgICAgICAgIGNvbnRpbnVlOwogCmRpZmYgLXIgZTg0
YTc5ZDExZDdhIHRvb2xzL2xpYnhjL3hlbmN0cmwuaAotLS0gYS90b29scy9saWJ4Yy94ZW5jdHJs
LmgJVGh1IE5vdiAwMSAwMTo0MTowMyAyMDEyICswODAwCisrKyBiL3Rvb2xzL2xpYnhjL3hlbmN0
cmwuaAlUaHUgTm92IDAxIDA3OjUyOjQxIDIwMTIgKzA4MDAKQEAgLTU3NSw2ICs1NzUsMTcgQEAK
ICAgICAgICAgICAgICAgICAgICAgICAgICAgeGNfZG9tYWluaW5mb190ICppbmZvKTsKIAogLyoq
CisgKiBUaGlzIGZ1bmN0aW9uIHNldCBwMm0gZm9yIGJyb2tlbiBwYWdlCisgKiAmcGFybSB4Y2gg
YSBoYW5kbGUgdG8gYW4gb3BlbiBoeXBlcnZpc29yIGludGVyZmFjZQorICogQHBhcm0gZG9taWQg
dGhlIGRvbWFpbiBpZCB3aGljaCBicm9rZW4gcGFnZSBiZWxvbmcgdG8KKyAqIEBwYXJtIHBmbiB0
aGUgcGZuIG51bWJlciBvZiB0aGUgYnJva2VuIHBhZ2UKKyAqIEByZXR1cm4gMCBvbiBzdWNjZXNz
LCAtMSBvbiBmYWlsdXJlCisgKi8KK2ludCB4Y19zZXRfYnJva2VuX3BhZ2VfcDJtKHhjX2ludGVy
ZmFjZSAqeGNoLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZG9taWQsCisg
ICAgICAgICAgICAgICAgICAgICAgICAgICB1bnNpZ25lZCBsb25nIHBmbik7CisKKy8qKgogICog
VGhpcyBmdW5jdGlvbiByZXR1cm5zIGluZm9ybWF0aW9uIGFib3V0IHRoZSBjb250ZXh0IG9mIGEg
aHZtIGRvbWFpbgogICogQHBhcm0geGNoIGEgaGFuZGxlIHRvIGFuIG9wZW4gaHlwZXJ2aXNvciBp
bnRlcmZhY2UKICAqIEBwYXJtIGRvbWlkIHRoZSBkb21haW4gdG8gZ2V0IGluZm9ybWF0aW9uIGZy
b20KZGlmZiAtciBlODRhNzlkMTFkN2EgeGVuL2FyY2gveDg2L2RvbWN0bC5jCi0tLSBhL3hlbi9h
cmNoL3g4Ni9kb21jdGwuYwlUaHUgTm92IDAxIDAxOjQxOjAzIDIwMTIgKzA4MDAKKysrIGIveGVu
L2FyY2gveDg2L2RvbWN0bC5jCVRodSBOb3YgMDEgMDc6NTI6NDEgMjAxMiArMDgwMApAQCAtMjA5
LDEyICsyMDksMTggQEAKICAgICAgICAgICAgICAgICBmb3IgKCBqID0gMDsgaiA8IGs7IGorKyAp
CiAgICAgICAgICAgICAgICAgewogICAgICAgICAgICAgICAgICAgICB1bnNpZ25lZCBsb25nIHR5
cGUgPSAwOworICAgICAgICAgICAgICAgICAgICBwMm1fdHlwZV90IHQ7CiAKLSAgICAgICAgICAg
ICAgICAgICAgcGFnZSA9IGdldF9wYWdlX2Zyb21fZ2ZuKGQsIGFycltqXSwgTlVMTCwgUDJNX0FM
TE9DKTsKKyAgICAgICAgICAgICAgICAgICAgcGFnZSA9IGdldF9wYWdlX2Zyb21fZ2ZuKGQsIGFy
cltqXSwgJnQsIFAyTV9BTExPQyk7CiAKICAgICAgICAgICAgICAgICAgICAgaWYgKCB1bmxpa2Vs
eSghcGFnZSkgfHwKICAgICAgICAgICAgICAgICAgICAgICAgICB1bmxpa2VseShpc194ZW5faGVh
cF9wYWdlKHBhZ2UpKSApCi0gICAgICAgICAgICAgICAgICAgICAgICB0eXBlID0gWEVOX0RPTUNU
TF9QRklORk9fWFRBQjsKKyAgICAgICAgICAgICAgICAgICAgeworICAgICAgICAgICAgICAgICAg
ICAgICAgaWYgKCBwMm1faXNfYnJva2VuKHQpICkKKyAgICAgICAgICAgICAgICAgICAgICAgICAg
ICB0eXBlID0gWEVOX0RPTUNUTF9QRklORk9fQlJPS0VOOworICAgICAgICAgICAgICAgICAgICAg
ICAgZWxzZQorICAgICAgICAgICAgICAgICAgICAgICAgICAgIHR5cGUgPSBYRU5fRE9NQ1RMX1BG
SU5GT19YVEFCOworICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAgICAgIGVs
c2UKICAgICAgICAgICAgICAgICAgICAgewogICAgICAgICAgICAgICAgICAgICAgICAgc3dpdGNo
KCBwYWdlLT51LmludXNlLnR5cGVfaW5mbyAmIFBHVF90eXBlX21hc2sgKQpAQCAtMjM1LDYgKzI0
MSw5IEBACiAKICAgICAgICAgICAgICAgICAgICAgICAgIGlmICggcGFnZS0+dS5pbnVzZS50eXBl
X2luZm8gJiBQR1RfcGlubmVkICkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0eXBlIHw9
IFhFTl9ET01DVExfUEZJTkZPX0xQSU5UQUI7CisKKyAgICAgICAgICAgICAgICAgICAgICAgIGlm
ICggcGFnZS0+Y291bnRfaW5mbyAmIFBHQ19icm9rZW4gKQorICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHR5cGUgPSBYRU5fRE9NQ1RMX1BGSU5GT19CUk9LRU47CiAgICAgICAgICAgICAgICAg
ICAgIH0KIAogICAgICAgICAgICAgICAgICAgICBpZiAoIHBhZ2UgKQpAQCAtMTU2OCw2ICsxNTc3
LDI5IEBACiAgICAgfQogICAgIGJyZWFrOwogCisgICAgY2FzZSBYRU5fRE9NQ1RMX3NldF9icm9r
ZW5fcGFnZV9wMm06CisgICAgeworICAgICAgICBzdHJ1Y3QgZG9tYWluICpkOworICAgICAgICAK
KyAgICAgICAgZCA9IHJjdV9sb2NrX2RvbWFpbl9ieV9pZChkb21jdGwtPmRvbWFpbik7CisgICAg
ICAgIGlmICggZCAhPSBOVUxMICkKKyAgICAgICAgeworICAgICAgICAgICAgcDJtX3R5cGVfdCBw
dDsKKyAgICAgICAgICAgIHVuc2lnbmVkIGxvbmcgcGZuID0gZG9tY3RsLT51LnNldF9icm9rZW5f
cGFnZV9wMm0ucGZuOworICAgICAgICAgICAgbWZuX3QgbWZuID0gZ2V0X2dmbl9xdWVyeShkLCBw
Zm4sICZwdCk7CisKKyAgICAgICAgICAgIGlmICggdW5saWtlbHkoIW1mbl92YWxpZChtZm5feCht
Zm4pKSB8fCAhcDJtX2lzX3JhbShwdCkgfHwKKyAgICAgICAgICAgICAgICAgICAgICAgICAocDJt
X2NoYW5nZV90eXBlKGQsIHBmbiwgcHQsIHAybV9yYW1fYnJva2VuKSAhPSBwdCkpICkKKyAgICAg
ICAgICAgICAgICByZXQgPSAtRUlOVkFMOworCisgICAgICAgICAgICBwdXRfZ2ZuKGQsIHBmbik7
CisgICAgICAgICAgICByY3VfdW5sb2NrX2RvbWFpbihkKTsKKyAgICAgICAgfQorICAgICAgICBl
bHNlCisgICAgICAgICAgICByZXQgPSAtRVNSQ0g7CisgICAgfQorICAgIGJyZWFrOworCiAgICAg
ZGVmYXVsdDoKICAgICAgICAgcmV0ID0gaW9tbXVfZG9fZG9tY3RsKGRvbWN0bCwgdV9kb21jdGwp
OwogICAgICAgICBicmVhazsKZGlmZiAtciBlODRhNzlkMTFkN2EgeGVuL2luY2x1ZGUvcHVibGlj
L2RvbWN0bC5oCi0tLSBhL3hlbi9pbmNsdWRlL3B1YmxpYy9kb21jdGwuaAlUaHUgTm92IDAxIDAx
OjQxOjAzIDIwMTIgKzA4MDAKKysrIGIveGVuL2luY2x1ZGUvcHVibGljL2RvbWN0bC5oCVRodSBO
b3YgMDEgMDc6NTI6NDEgMjAxMiArMDgwMApAQCAtMTM2LDYgKzEzNiw3IEBACiAjZGVmaW5lIFhF
Tl9ET01DVExfUEZJTkZPX0xQSU5UQUIgKDB4MVU8PDMxKQogI2RlZmluZSBYRU5fRE9NQ1RMX1BG
SU5GT19YVEFCICAgICgweGZVPDwyOCkgLyogaW52YWxpZCBwYWdlICovCiAjZGVmaW5lIFhFTl9E
T01DVExfUEZJTkZPX1hBTExPQyAgKDB4ZVU8PDI4KSAvKiBhbGxvY2F0ZS1vbmx5IHBhZ2UgKi8K
KyNkZWZpbmUgWEVOX0RPTUNUTF9QRklORk9fQlJPS0VOICAoMHhkVTw8MjgpIC8qIGJyb2tlbiBw
YWdlICovCiAjZGVmaW5lIFhFTl9ET01DVExfUEZJTkZPX1BBR0VEVEFCICgweDhVPDwyOCkKICNk
ZWZpbmUgWEVOX0RPTUNUTF9QRklORk9fTFRBQl9NQVNLICgweGZVPDwyOCkKIApAQCAtODM1LDYg
KzgzNiwxMiBAQAogdHlwZWRlZiBzdHJ1Y3QgeGVuX2RvbWN0bF9zZXRfYWNjZXNzX3JlcXVpcmVk
IHhlbl9kb21jdGxfc2V0X2FjY2Vzc19yZXF1aXJlZF90OwogREVGSU5FX1hFTl9HVUVTVF9IQU5E
TEUoeGVuX2RvbWN0bF9zZXRfYWNjZXNzX3JlcXVpcmVkX3QpOwogCitzdHJ1Y3QgeGVuX2RvbWN0
bF9zZXRfYnJva2VuX3BhZ2VfcDJtIHsKKyAgICB1aW50NjRfYWxpZ25lZF90IHBmbjsKK307Cit0
eXBlZGVmIHN0cnVjdCB4ZW5fZG9tY3RsX3NldF9icm9rZW5fcGFnZV9wMm0geGVuX2RvbWN0bF9z
ZXRfYnJva2VuX3BhZ2VfcDJtX3Q7CitERUZJTkVfWEVOX0dVRVNUX0hBTkRMRSh4ZW5fZG9tY3Rs
X3NldF9icm9rZW5fcGFnZV9wMm1fdCk7CisKIHN0cnVjdCB4ZW5fZG9tY3RsIHsKICAgICB1aW50
MzJfdCBjbWQ7CiAjZGVmaW5lIFhFTl9ET01DVExfY3JlYXRlZG9tYWluICAgICAgICAgICAgICAg
ICAgIDEKQEAgLTkwMCw2ICs5MDcsNyBAQAogI2RlZmluZSBYRU5fRE9NQ1RMX3NldF9hY2Nlc3Nf
cmVxdWlyZWQgICAgICAgICAgIDY0CiAjZGVmaW5lIFhFTl9ET01DVExfYXVkaXRfcDJtICAgICAg
ICAgICAgICAgICAgICAgNjUKICNkZWZpbmUgWEVOX0RPTUNUTF9zZXRfdmlycV9oYW5kbGVyICAg
ICAgICAgICAgICA2NgorI2RlZmluZSBYRU5fRE9NQ1RMX3NldF9icm9rZW5fcGFnZV9wMm0gICAg
ICAgICAgIDY3CiAjZGVmaW5lIFhFTl9ET01DVExfZ2Ric3hfZ3Vlc3RtZW1pbyAgICAgICAgICAg
IDEwMDAKICNkZWZpbmUgWEVOX0RPTUNUTF9nZGJzeF9wYXVzZXZjcHUgICAgICAgICAgICAgMTAw
MQogI2RlZmluZSBYRU5fRE9NQ1RMX2dkYnN4X3VucGF1c2V2Y3B1ICAgICAgICAgICAxMDAyCkBA
IC05NTUsNiArOTYzLDcgQEAKICAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfYXVkaXRfcDJtICAg
ICAgICAgYXVkaXRfcDJtOwogICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF9zZXRfdmlycV9oYW5k
bGVyICBzZXRfdmlycV9oYW5kbGVyOwogICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF9nZGJzeF9t
ZW1pbyAgICAgICBnZGJzeF9ndWVzdF9tZW1pbzsKKyAgICAgICAgc3RydWN0IHhlbl9kb21jdGxf
c2V0X2Jyb2tlbl9wYWdlX3AybSBzZXRfYnJva2VuX3BhZ2VfcDJtOwogICAgICAgICBzdHJ1Y3Qg
eGVuX2RvbWN0bF9nZGJzeF9wYXVzZXVucF92Y3B1IGdkYnN4X3BhdXNldW5wX3ZjcHU7CiAgICAg
ICAgIHN0cnVjdCB4ZW5fZG9tY3RsX2dkYnN4X2RvbXN0YXR1cyAgIGdkYnN4X2RvbXN0YXR1czsK
ICAgICAgICAgdWludDhfdCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcGFkWzEyOF07Cg==

--_002_DE8DF0795D48FD4CA783C40EC8292335376A97SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_002_DE8DF0795D48FD4CA783C40EC8292335376A97SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Wed Oct 31 16:19:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 16:19:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTb0O-0005hz-Se; Wed, 31 Oct 2012 16:19:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTb0N-0005ht-4b
	for xen-devel@lists.xen.org; Wed, 31 Oct 2012 16:18:59 +0000
Received: from [85.158.139.211:60680] by server-14.bemta-5.messagelabs.com id
	DB/37-21768-27F41905; Wed, 31 Oct 2012 16:18:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1351700337!18377109!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4MDA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9984 invoked from network); 31 Oct 2012 16:18:58 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-206.messagelabs.com with SMTP;
	31 Oct 2012 16:18:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 31 Oct 2012 16:18:56 +0000
Message-Id: <50915DA702000078000A5C75@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 31 Oct 2012 16:19:35 +0000
From: "Jan Beulich" 
To: "Dan Magenheimer" 
References: <60d00f38-98a3-4ec2-acbd-b49dafaada56@default>
	<20121029223555.GA24388@ocelot.phlegethon.org>
	
	<508F9DE902000078000A5565@nat28.tlf.novell.com>
	
	<509008A502000078000A584E@nat28.tlf.novell.com>
	
	<5090EBFE02000078000A59DD@nat28.tlf.novell.com>
	<83bb902d-8e49-41cf-ad1e-c07c62d6e5f8@default>
In-Reply-To: <83bb902d-8e49-41cf-ad1e-c07c62d6e5f8@default>
Mime-Version: 1.0
Content-Disposition: inline
Cc: TimDeegan , Olaf Hering ,
	"Keir\(Xen.org\)" , IanCampbell ,
	Konrad Wilk ,
	GeorgeDunlap ,
	IanJackson ,
	George Shuklin ,
	xen-devel@lists.xen.org, DarioFaggioli ,
	Kurt Hackel ,
	Zhigang Wang 
Subject: Re: [Xen-devel] Proposed new "memory capacity claim"
	hypercall/feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 31.10.12 at 17:04, Dan Magenheimer  wrote:
>>  From: Jan Beulich [mailto:JBeulich@suse.com]
>> Subject: RE: Proposed new "memory capacity claim" hypercall/feature
>> 
>> >>> On 30.10.12 at 18:13, Dan Magenheimer  wrote:
>> >>  From: Jan Beulich [mailto:JBeulich@suse.com]
> 
> (NOTE TO KEIR: Input from you requested in first stanza below.)
> 
> Hi Jan --
> 
> Thanks for the continued feedback!
> 
> I've slightly re-ordered the email to focus on the problem
> (moved tmem-specific discussion to the end).
> 
>> As long as the allocation times can get brought down to an
>> acceptable level, I continue to not see a need for the extra
>> "claim" approach you're proposing. So working on that one (or
>> showing that without unreasonable effort this cannot be
>> further improved) would be a higher priority thing from my pov
>> (without anyone arguing about its usefulness).
> 
> Fair enough.  I will do some measurement and analysis of this
> code.  However, let me ask something of you and Keir as well:
> Please estimate how long (in usec) you think it is acceptable
> to hold the heap_lock.  If your limit is very small (as I expect),
> doing anything "N" times in a loop with the lock held (for N==2^26,
> which is a 256GB domain) may make the analysis moot.

I think your thoughts here simply go a different route than mine:
Of course it is wrong to hold _any_ lock for extended periods of
time. But extending what was done by c/s 26056:177fdda0be56
might, considering the effect that change had, buy you quite a
bit of allocation efficiency.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 16:19:25 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 16:19:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTb0O-0005hz-Se; Wed, 31 Oct 2012 16:19:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTb0N-0005ht-4b
	for xen-devel@lists.xen.org; Wed, 31 Oct 2012 16:18:59 +0000
Received: from [85.158.139.211:60680] by server-14.bemta-5.messagelabs.com id
	DB/37-21768-27F41905; Wed, 31 Oct 2012 16:18:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1351700337!18377109!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4MDA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9984 invoked from network); 31 Oct 2012 16:18:58 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-206.messagelabs.com with SMTP;
	31 Oct 2012 16:18:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 31 Oct 2012 16:18:56 +0000
Message-Id: <50915DA702000078000A5C75@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 31 Oct 2012 16:19:35 +0000
From: "Jan Beulich" 
To: "Dan Magenheimer" 
References: <60d00f38-98a3-4ec2-acbd-b49dafaada56@default>
	<20121029223555.GA24388@ocelot.phlegethon.org>
	
	<508F9DE902000078000A5565@nat28.tlf.novell.com>
	
	<509008A502000078000A584E@nat28.tlf.novell.com>
	
	<5090EBFE02000078000A59DD@nat28.tlf.novell.com>
	<83bb902d-8e49-41cf-ad1e-c07c62d6e5f8@default>
In-Reply-To: <83bb902d-8e49-41cf-ad1e-c07c62d6e5f8@default>
Mime-Version: 1.0
Content-Disposition: inline
Cc: TimDeegan , Olaf Hering ,
	"Keir\(Xen.org\)" , IanCampbell ,
	Konrad Wilk ,
	GeorgeDunlap ,
	IanJackson ,
	George Shuklin ,
	xen-devel@lists.xen.org, DarioFaggioli ,
	Kurt Hackel ,
	Zhigang Wang 
Subject: Re: [Xen-devel] Proposed new "memory capacity claim"
	hypercall/feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 31.10.12 at 17:04, Dan Magenheimer  wrote:
>>  From: Jan Beulich [mailto:JBeulich@suse.com]
>> Subject: RE: Proposed new "memory capacity claim" hypercall/feature
>> 
>> >>> On 30.10.12 at 18:13, Dan Magenheimer  wrote:
>> >>  From: Jan Beulich [mailto:JBeulich@suse.com]
> 
> (NOTE TO KEIR: Input from you requested in first stanza below.)
> 
> Hi Jan --
> 
> Thanks for the continued feedback!
> 
> I've slightly re-ordered the email to focus on the problem
> (moved tmem-specific discussion to the end).
> 
>> As long as the allocation times can get brought down to an
>> acceptable level, I continue to not see a need for the extra
>> "claim" approach you're proposing. So working on that one (or
>> showing that without unreasonable effort this cannot be
>> further improved) would be a higher priority thing from my pov
>> (without anyone arguing about its usefulness).
> 
> Fair enough.  I will do some measurement and analysis of this
> code.  However, let me ask something of you and Keir as well:
> Please estimate how long (in usec) you think it is acceptable
> to hold the heap_lock.  If your limit is very small (as I expect),
> doing anything "N" times in a loop with the lock held (for N==2^26,
> which is a 256GB domain) may make the analysis moot.

I think your thoughts here simply go a different route than mine:
Of course it is wrong to hold _any_ lock for extended periods of
time. But extending what was done by c/s 26056:177fdda0be56
might, considering the effect that change had, buy you quite a
bit of allocation efficiency.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 16:52:07 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 16:52:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTbW0-0006fB-9I; Wed, 31 Oct 2012 16:51:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTbVy-0006ex-Ku
	for xen-devel@lists.xen.org; Wed, 31 Oct 2012 16:51:38 +0000
Received: from [85.158.143.35:5281] by server-1.bemta-4.messagelabs.com id
	1F/D5-27934-91751905; Wed, 31 Oct 2012 16:51:37 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1351702295!13992205!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMTAxOTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30982 invoked from network); 31 Oct 2012 16:51:37 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 31 Oct 2012 16:51:37 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9VGpMHE009364
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 31 Oct 2012 16:51:23 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9VGpJ9x021060
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 31 Oct 2012 16:51:20 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9VGpIOP001873; Wed, 31 Oct 2012 11:51:18 -0500
MIME-Version: 1.0
Message-ID: <5a1fef58-be52-464d-8f86-b65dffb32431@default>
Date: Wed, 31 Oct 2012 09:51:15 -0700 (PDT)
From: Dan Magenheimer 
To: Jan Beulich 
References: <60d00f38-98a3-4ec2-acbd-b49dafaada56@default>
	<20121029223555.GA24388@ocelot.phlegethon.org>
	
	<508F9DE902000078000A5565@nat28.tlf.novell.com>
	
	<509008A502000078000A584E@nat28.tlf.novell.com>
	
	<5090EBFE02000078000A59DD@nat28.tlf.novell.com>
	<83bb902d-8e49-41cf-ad1e-c07c62d6e5f8@default>
	<50915DA702000078000A5C75@nat28.tlf.novell.com>
In-Reply-To: <50915DA702000078000A5C75@nat28.tlf.novell.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: TimDeegan , Olaf Hering ,
	"Keir\(Xen.org\)" , IanCampbell ,
	Konrad Wilk ,
	GeorgeDunlap ,
	IanJackson ,
	George Shuklin ,
	xen-devel@lists.xen.org, DarioFaggioli ,
	Kurt Hackel ,
	Zhigang Wang 
Subject: Re: [Xen-devel] Proposed new "memory capacity claim"
	hypercall/feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Subject: RE: Proposed new "memory capacity claim" hypercall/feature
> 
> >>> On 31.10.12 at 17:04, Dan Magenheimer  wrote:
> >>  From: Jan Beulich [mailto:JBeulich@suse.com]
> >> Subject: RE: Proposed new "memory capacity claim" hypercall/feature
> >>
> >> As long as the allocation times can get brought down to an
> >> acceptable level, I continue to not see a need for the extra
> >> "claim" approach you're proposing. So working on that one (or
> >> showing that without unreasonable effort this cannot be
> >> further improved) would be a higher priority thing from my pov
> >> (without anyone arguing about its usefulness).
> >
> > Fair enough.  I will do some measurement and analysis of this
> > code.  However, let me ask something of you and Keir as well:
> > Please estimate how long (in usec) you think it is acceptable
> > to hold the heap_lock.  If your limit is very small (as I expect),
> > doing anything "N" times in a loop with the lock held (for N==2^26,
> > which is a 256GB domain) may make the analysis moot.
> 
> I think your thoughts here simply go a different route than mine:
> Of course it is wrong to hold _any_ lock for extended periods of
> time. But extending what was done by c/s 26056:177fdda0be56
> might, considering the effect that change had, buy you quite a
> bit of allocation efficiency.

No, I think we are on the same route, except that maybe I
am trying to take a shortcut to the end. :-)

I did follow the discussion that led to that changeset
and highly recommended to the Oracle product folks that
we integrate it asap.

But reducing the domain allocation time "massively" from
30 sec to 3 sec doesn't help solve my issue because, in
essence, my issue says that the heap_lock must still be
held for most of that 3 sec.  Even reducing it by _another_
factor of 10 to 0.3 sec or a factor of 100 to 30msec
doesn't solve my problem.

To look at it another way, the code in alloc_heap_page()
contained within the loop:

	for ( i = 0; i < (1 << order); i++ )

may be already unacceptable, even _after_ the patch, if
order==26 (a fictional page size just for this illustration)
because the heap_lock will be held for a very very long time.
(In fact for order==20, 1GB pages, it could already be a
problem.)

The claim hypercall/subop would allocate _capacity_ only,
and then the actual physical pages are "lazily" allocated
from that pre-allocated capacity.

Anyway, I am still planning on proceeding with some
of the measurement/analysis _and_ proof-of-concept.

Thanks,
Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 16:52:07 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 16:52:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTbW0-0006fB-9I; Wed, 31 Oct 2012 16:51:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTbVy-0006ex-Ku
	for xen-devel@lists.xen.org; Wed, 31 Oct 2012 16:51:38 +0000
Received: from [85.158.143.35:5281] by server-1.bemta-4.messagelabs.com id
	1F/D5-27934-91751905; Wed, 31 Oct 2012 16:51:37 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1351702295!13992205!1
X-Originating-IP: [141.146.126.69]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMTAxOTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30982 invoked from network); 31 Oct 2012 16:51:37 -0000
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com)
	(141.146.126.69)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 31 Oct 2012 16:51:37 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9VGpMHE009364
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 31 Oct 2012 16:51:23 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9VGpJ9x021060
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 31 Oct 2012 16:51:20 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9VGpIOP001873; Wed, 31 Oct 2012 11:51:18 -0500
MIME-Version: 1.0
Message-ID: <5a1fef58-be52-464d-8f86-b65dffb32431@default>
Date: Wed, 31 Oct 2012 09:51:15 -0700 (PDT)
From: Dan Magenheimer 
To: Jan Beulich 
References: <60d00f38-98a3-4ec2-acbd-b49dafaada56@default>
	<20121029223555.GA24388@ocelot.phlegethon.org>
	
	<508F9DE902000078000A5565@nat28.tlf.novell.com>
	
	<509008A502000078000A584E@nat28.tlf.novell.com>
	
	<5090EBFE02000078000A59DD@nat28.tlf.novell.com>
	<83bb902d-8e49-41cf-ad1e-c07c62d6e5f8@default>
	<50915DA702000078000A5C75@nat28.tlf.novell.com>
In-Reply-To: <50915DA702000078000A5C75@nat28.tlf.novell.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: TimDeegan , Olaf Hering ,
	"Keir\(Xen.org\)" , IanCampbell ,
	Konrad Wilk ,
	GeorgeDunlap ,
	IanJackson ,
	George Shuklin ,
	xen-devel@lists.xen.org, DarioFaggioli ,
	Kurt Hackel ,
	Zhigang Wang 
Subject: Re: [Xen-devel] Proposed new "memory capacity claim"
	hypercall/feature
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Subject: RE: Proposed new "memory capacity claim" hypercall/feature
> 
> >>> On 31.10.12 at 17:04, Dan Magenheimer  wrote:
> >>  From: Jan Beulich [mailto:JBeulich@suse.com]
> >> Subject: RE: Proposed new "memory capacity claim" hypercall/feature
> >>
> >> As long as the allocation times can get brought down to an
> >> acceptable level, I continue to not see a need for the extra
> >> "claim" approach you're proposing. So working on that one (or
> >> showing that without unreasonable effort this cannot be
> >> further improved) would be a higher priority thing from my pov
> >> (without anyone arguing about its usefulness).
> >
> > Fair enough.  I will do some measurement and analysis of this
> > code.  However, let me ask something of you and Keir as well:
> > Please estimate how long (in usec) you think it is acceptable
> > to hold the heap_lock.  If your limit is very small (as I expect),
> > doing anything "N" times in a loop with the lock held (for N==2^26,
> > which is a 256GB domain) may make the analysis moot.
> 
> I think your thoughts here simply go a different route than mine:
> Of course it is wrong to hold _any_ lock for extended periods of
> time. But extending what was done by c/s 26056:177fdda0be56
> might, considering the effect that change had, buy you quite a
> bit of allocation efficiency.

No, I think we are on the same route, except that maybe I
am trying to take a shortcut to the end. :-)

I did follow the discussion that led to that changeset
and highly recommended to the Oracle product folks that
we integrate it asap.

But reducing the domain allocation time "massively" from
30 sec to 3 sec doesn't help solve my issue because, in
essence, my issue says that the heap_lock must still be
held for most of that 3 sec.  Even reducing it by _another_
factor of 10 to 0.3 sec or a factor of 100 to 30msec
doesn't solve my problem.

To look at it another way, the code in alloc_heap_page()
contained within the loop:

	for ( i = 0; i < (1 << order); i++ )

may be already unacceptable, even _after_ the patch, if
order==26 (a fictional page size just for this illustration)
because the heap_lock will be held for a very very long time.
(In fact for order==20, 1GB pages, it could already be a
problem.)

The claim hypercall/subop would allocate _capacity_ only,
and then the actual physical pages are "lazily" allocated
from that pre-allocated capacity.

Anyway, I am still planning on proceeding with some
of the measurement/analysis _and_ proof-of-concept.

Thanks,
Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 16:54:56 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 16:54:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTbYi-0006oU-3k; Wed, 31 Oct 2012 16:54:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTbYg-0006oO-PQ
	for xen-devel@lists.xensource.com; Wed, 31 Oct 2012 16:54:27 +0000
Received: from [85.158.138.51:30103] by server-7.bemta-3.messagelabs.com id
	2A/E9-06991-2C751905; Wed, 31 Oct 2012 16:54:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1351702459!9489242!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgzNzk1Ng==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26290 invoked from network); 31 Oct 2012 16:54:21 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 31 Oct 2012 16:54:21 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9VGrJq0000990
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 31 Oct 2012 16:53:19 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9VGrIWO024494
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 31 Oct 2012 16:53:18 GMT
Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9VGrHO7003538; Wed, 31 Oct 2012 11:53:17 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 31 Oct 2012 09:53:17 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 09B1A40366; Wed, 31 Oct 2012 12:40:47 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Date: Wed, 31 Oct 2012 12:40:40 -0400
Message-Id: <1351701640-18786-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: jingjie.jiang@oracle.com, stable@vger.kernel.org,
	Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH] xen/mmu: Use Xen specific TLB flush instead of
	the generic one.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

As Mukesh explained it, the MMUEXT_TLB_FLUSH_ALL allows the
hypervisor to do a TLB flush on all active vCPUs. If instead
we were using the generic one (which ends up being xen_flush_tlb)
we end up making the MMUEXT_TLB_FLUSH_LOCAL hypercall. But
before we make that hypercall the kernel will IPI all of the
vCPUs (even those that were asleep from the hypervisor
perspective). The end result is that we needlessly wake them
up and do a TLB flush when we can just let the hypervisor
do it correctly.

This patch gives around 50% speed improvement when migrating
idle guest's from one host to another.

Oracle-bug: 14630170

CC: stable@vger.kernel.org
Tested-by:  Jingjie Jiang 
Suggested-by:  Mukesh Rathor 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/xen/mmu.c         |   21 ++++++++++++++++++++-
 include/trace/events/xen.h |    8 ++++++++
 2 files changed, 28 insertions(+), 1 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 6226c99..dcf5f2d 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1288,6 +1288,25 @@ unsigned long xen_read_cr2_direct(void)
 	return this_cpu_read(xen_vcpu_info.arch.cr2);
 }
 
+void xen_flush_tlb_all(void)
+{
+	struct mmuext_op *op;
+	struct multicall_space mcs;
+
+	trace_xen_mmu_flush_tlb_all(0);
+
+	preempt_disable();
+
+	mcs = xen_mc_entry(sizeof(*op));
+
+	op = mcs.args;
+	op->cmd = MMUEXT_TLB_FLUSH_ALL;
+	MULTI_mmuext_op(mcs.mc, op, 1, NULL, DOMID_SELF);
+
+	xen_mc_issue(PARAVIRT_LAZY_MMU);
+
+	preempt_enable();
+}
 static void xen_flush_tlb(void)
 {
 	struct mmuext_op *op;
@@ -2518,7 +2537,7 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 	err = 0;
 out:
 
-	flush_tlb_all();
+	xen_flush_tlb_all();
 
 	return err;
 }
diff --git a/include/trace/events/xen.h b/include/trace/events/xen.h
index 15ba03b..d06b6da 100644
--- a/include/trace/events/xen.h
+++ b/include/trace/events/xen.h
@@ -377,6 +377,14 @@ DECLARE_EVENT_CLASS(xen_mmu_pgd,
 DEFINE_XEN_MMU_PGD_EVENT(xen_mmu_pgd_pin);
 DEFINE_XEN_MMU_PGD_EVENT(xen_mmu_pgd_unpin);
 
+TRACE_EVENT(xen_mmu_flush_tlb_all,
+	    TP_PROTO(int x),
+	    TP_ARGS(x),
+	    TP_STRUCT__entry(__array(char, x, 0)),
+	    TP_fast_assign((void)x),
+	    TP_printk("%s", "")
+	);
+
 TRACE_EVENT(xen_mmu_flush_tlb,
 	    TP_PROTO(int x),
 	    TP_ARGS(x),
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 16:54:56 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 16:54:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTbYi-0006oU-3k; Wed, 31 Oct 2012 16:54:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTbYg-0006oO-PQ
	for xen-devel@lists.xensource.com; Wed, 31 Oct 2012 16:54:27 +0000
Received: from [85.158.138.51:30103] by server-7.bemta-3.messagelabs.com id
	2A/E9-06991-2C751905; Wed, 31 Oct 2012 16:54:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1351702459!9489242!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDgzNzk1Ng==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26290 invoked from network); 31 Oct 2012 16:54:21 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 31 Oct 2012 16:54:21 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q9VGrJq0000990
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 31 Oct 2012 16:53:19 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q9VGrIWO024494
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 31 Oct 2012 16:53:18 GMT
Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q9VGrHO7003538; Wed, 31 Oct 2012 11:53:17 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 31 Oct 2012 09:53:17 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 09B1A40366; Wed, 31 Oct 2012 12:40:47 -0400 (EDT)
From: Konrad Rzeszutek Wilk 
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Date: Wed, 31 Oct 2012 12:40:40 -0400
Message-Id: <1351701640-18786-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: jingjie.jiang@oracle.com, stable@vger.kernel.org,
	Konrad Rzeszutek Wilk 
Subject: [Xen-devel] [PATCH] xen/mmu: Use Xen specific TLB flush instead of
	the generic one.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

As Mukesh explained it, the MMUEXT_TLB_FLUSH_ALL allows the
hypervisor to do a TLB flush on all active vCPUs. If instead
we were using the generic one (which ends up being xen_flush_tlb)
we end up making the MMUEXT_TLB_FLUSH_LOCAL hypercall. But
before we make that hypercall the kernel will IPI all of the
vCPUs (even those that were asleep from the hypervisor
perspective). The end result is that we needlessly wake them
up and do a TLB flush when we can just let the hypervisor
do it correctly.

This patch gives around 50% speed improvement when migrating
idle guest's from one host to another.

Oracle-bug: 14630170

CC: stable@vger.kernel.org
Tested-by:  Jingjie Jiang 
Suggested-by:  Mukesh Rathor 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 arch/x86/xen/mmu.c         |   21 ++++++++++++++++++++-
 include/trace/events/xen.h |    8 ++++++++
 2 files changed, 28 insertions(+), 1 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 6226c99..dcf5f2d 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1288,6 +1288,25 @@ unsigned long xen_read_cr2_direct(void)
 	return this_cpu_read(xen_vcpu_info.arch.cr2);
 }
 
+void xen_flush_tlb_all(void)
+{
+	struct mmuext_op *op;
+	struct multicall_space mcs;
+
+	trace_xen_mmu_flush_tlb_all(0);
+
+	preempt_disable();
+
+	mcs = xen_mc_entry(sizeof(*op));
+
+	op = mcs.args;
+	op->cmd = MMUEXT_TLB_FLUSH_ALL;
+	MULTI_mmuext_op(mcs.mc, op, 1, NULL, DOMID_SELF);
+
+	xen_mc_issue(PARAVIRT_LAZY_MMU);
+
+	preempt_enable();
+}
 static void xen_flush_tlb(void)
 {
 	struct mmuext_op *op;
@@ -2518,7 +2537,7 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 	err = 0;
 out:
 
-	flush_tlb_all();
+	xen_flush_tlb_all();
 
 	return err;
 }
diff --git a/include/trace/events/xen.h b/include/trace/events/xen.h
index 15ba03b..d06b6da 100644
--- a/include/trace/events/xen.h
+++ b/include/trace/events/xen.h
@@ -377,6 +377,14 @@ DECLARE_EVENT_CLASS(xen_mmu_pgd,
 DEFINE_XEN_MMU_PGD_EVENT(xen_mmu_pgd_pin);
 DEFINE_XEN_MMU_PGD_EVENT(xen_mmu_pgd_unpin);
 
+TRACE_EVENT(xen_mmu_flush_tlb_all,
+	    TP_PROTO(int x),
+	    TP_ARGS(x),
+	    TP_STRUCT__entry(__array(char, x, 0)),
+	    TP_fast_assign((void)x),
+	    TP_printk("%s", "")
+	);
+
 TRACE_EVENT(xen_mmu_flush_tlb,
 	    TP_PROTO(int x),
 	    TP_ARGS(x),
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 17:05:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 17:05:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTbiZ-0007Rj-Qe; Wed, 31 Oct 2012 17:04:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTbiY-0007RT-21
	for xen-devel@lists.xen.org; Wed, 31 Oct 2012 17:04:38 +0000
Received: from [85.158.138.51:44090] by server-16.bemta-3.messagelabs.com id
	D0/61-07461-52A51905; Wed, 31 Oct 2012 17:04:37 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-15.tower-174.messagelabs.com!1351703075!26419966!1
X-Originating-IP: [209.85.210.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28129 invoked from network); 31 Oct 2012 17:04:36 -0000
Received: from mail-ia0-f173.google.com (HELO mail-ia0-f173.google.com)
	(209.85.210.173)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Oct 2012 17:04:36 -0000
Received: by mail-ia0-f173.google.com with SMTP id m10so1525484iam.32
	for ; Wed, 31 Oct 2012 10:04:34 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=content-type:mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=Rq8yKpQaiPinPvXZCeYzz0XjWgWIfU8xz4v0OoNTJLI=;
	b=ivf8RtbKnDOzEmv6NewFBf0XRsZUXkXVcKVMk5olsA5ngDW/VMR3ushwerFJcrflfc
	CkG65cYIPu0WoDo3xhuR/8uOgxNDAemqvoI0NWSJmvXD36WKmqojDJpqaBN251/X1IRw
	KdmmumpyW0VgvfRBfOvCa+mxdwYbN/u6Uth8StZ91XAEggGjV1Mq3/QhZgGLyKzZE56k
	g+pq5D7JQExsdSFGDaDZDI3+KcoYHMqN2+u+Hch7BW78p3S+Bdr/V8iXHF5aQl2ACPju
	Qow4b4xvENVZynmOlBzvpxxy0AmNAcXeLsV7pB7ys6DmEMcrsfAHttxNBga8mYFD318+
	MZrw==
Received: by 10.42.176.194 with SMTP id bf2mr16283010icb.50.1351703074642;
	Wed, 31 Oct 2012 10:04:34 -0700 (PDT)
Received: from andress-macbook.gridcentric.ca ([206.223.182.18])
	by mx.google.com with ESMTPS id y10sm10869704igc.13.2012.10.31.10.04.31
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 31 Oct 2012 10:04:33 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Andres Lagar-Cavilla 
In-Reply-To: <20121030150612.GC34613@ocelot.phlegethon.org>
Date: Wed, 31 Oct 2012 13:04:33 -0400
Message-Id: <8CED7AA4-7C18-488E-8CA0-918254EDA444@gridcentric.ca>
References: <508FAA9402000078000A5612@nat28.tlf.novell.com>
	<20121030093626.GB34613@ocelot.phlegethon.org>
	<4E449D48-D643-46FB-91BD-B15EF21AAC57@gridcentric.ca>
	<20121030150612.GC34613@ocelot.phlegethon.org>
To: Tim Deegan 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQkOCcr4+rU8Twwyi/q0FpKKE2pXBFg7bU1n3ZUizmjcFpVsSRDSh8nGdQCUp/6iOu9NZMmC
Cc: Andres Lagar-Cavilla ,
	Jan Beulich , xen-devel 
Subject: Re: [Xen-devel] get_gfn_query() locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Oct 30, 2012, at 11:06 AM, Tim Deegan  wrote:

> At 10:53 -0400 on 30 Oct (1351594401), Andres Lagar-Cavilla wrote:
>>>> And then again, with the p2m lock being recursive these
>>>> days, I don't think there's any harm calling the other methods
>>>> here with that lock held.
>> 
>> Is the patch you refer to http://www.gossamer-threads.com/lists/xen/devel/261025 and the hunk in question the following?
>> + get_gfn_query(d, pfn, &pt); 
>> + p2m_change_type(d, pfn, pt, p2m_ram_broken); 
>> + put_gfn(d, pfn); 
>> 
>> There really is no way to get rid of that p2m lock-protected critical
>> section if the domain allows for paging etc. You might want to
>> introduce a syntactically cleaner unconditional p2m_change_type
>> variant that doesn't cmpxchg with the previous type -- that is
>> effectively what goes on here. Should be a tiny amount of refactoring
>> and the code will be cleaner, no need for query or put.
> 
> I don't think that change-type is even what's wanted here.  You want to
> use some more raw form of set_p2m_entry(), since keeping the MFN is not
> important.  How about:
> 
> guest_physmap_add_entry(d, pfn, MFN_INVALID, p2m_ram_broken);
> 
Has the side effect of leaking the current mfn (if any) in the p2m entry for the remainder of the lifetime of the domain.

Digression: is this something we want to just go ahead and fix? Or is that semantic intended?

> ?
> 
>>> 
>>> True, but it wouldn't be safe to call it with the paging lock held.
>>> OTOH since we're not seeing any crashes from the lock-ordering
>>> constraints maybe we don't do that.
>>> 
>>> Andres, what do you think?  Can we just drop/amend that comment?
>>> 
>> 
>> If you refer to removing the ordering constraints
> 
> Noooooooooooooo! :)
> 
> I think we should drop the comment that says it's OK to call
> get_gfn_query() with the paging lock held (and audit to check that we
> don't do that anywhere).

Good, same page then, phew
Andres

> 
> Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 17:05:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 17:05:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTbiZ-0007Rj-Qe; Wed, 31 Oct 2012 17:04:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTbiY-0007RT-21
	for xen-devel@lists.xen.org; Wed, 31 Oct 2012 17:04:38 +0000
Received: from [85.158.138.51:44090] by server-16.bemta-3.messagelabs.com id
	D0/61-07461-52A51905; Wed, 31 Oct 2012 17:04:37 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-15.tower-174.messagelabs.com!1351703075!26419966!1
X-Originating-IP: [209.85.210.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28129 invoked from network); 31 Oct 2012 17:04:36 -0000
Received: from mail-ia0-f173.google.com (HELO mail-ia0-f173.google.com)
	(209.85.210.173)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Oct 2012 17:04:36 -0000
Received: by mail-ia0-f173.google.com with SMTP id m10so1525484iam.32
	for ; Wed, 31 Oct 2012 10:04:34 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=content-type:mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=Rq8yKpQaiPinPvXZCeYzz0XjWgWIfU8xz4v0OoNTJLI=;
	b=ivf8RtbKnDOzEmv6NewFBf0XRsZUXkXVcKVMk5olsA5ngDW/VMR3ushwerFJcrflfc
	CkG65cYIPu0WoDo3xhuR/8uOgxNDAemqvoI0NWSJmvXD36WKmqojDJpqaBN251/X1IRw
	KdmmumpyW0VgvfRBfOvCa+mxdwYbN/u6Uth8StZ91XAEggGjV1Mq3/QhZgGLyKzZE56k
	g+pq5D7JQExsdSFGDaDZDI3+KcoYHMqN2+u+Hch7BW78p3S+Bdr/V8iXHF5aQl2ACPju
	Qow4b4xvENVZynmOlBzvpxxy0AmNAcXeLsV7pB7ys6DmEMcrsfAHttxNBga8mYFD318+
	MZrw==
Received: by 10.42.176.194 with SMTP id bf2mr16283010icb.50.1351703074642;
	Wed, 31 Oct 2012 10:04:34 -0700 (PDT)
Received: from andress-macbook.gridcentric.ca ([206.223.182.18])
	by mx.google.com with ESMTPS id y10sm10869704igc.13.2012.10.31.10.04.31
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 31 Oct 2012 10:04:33 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Andres Lagar-Cavilla 
In-Reply-To: <20121030150612.GC34613@ocelot.phlegethon.org>
Date: Wed, 31 Oct 2012 13:04:33 -0400
Message-Id: <8CED7AA4-7C18-488E-8CA0-918254EDA444@gridcentric.ca>
References: <508FAA9402000078000A5612@nat28.tlf.novell.com>
	<20121030093626.GB34613@ocelot.phlegethon.org>
	<4E449D48-D643-46FB-91BD-B15EF21AAC57@gridcentric.ca>
	<20121030150612.GC34613@ocelot.phlegethon.org>
To: Tim Deegan 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQkOCcr4+rU8Twwyi/q0FpKKE2pXBFg7bU1n3ZUizmjcFpVsSRDSh8nGdQCUp/6iOu9NZMmC
Cc: Andres Lagar-Cavilla ,
	Jan Beulich , xen-devel 
Subject: Re: [Xen-devel] get_gfn_query() locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Oct 30, 2012, at 11:06 AM, Tim Deegan  wrote:

> At 10:53 -0400 on 30 Oct (1351594401), Andres Lagar-Cavilla wrote:
>>>> And then again, with the p2m lock being recursive these
>>>> days, I don't think there's any harm calling the other methods
>>>> here with that lock held.
>> 
>> Is the patch you refer to http://www.gossamer-threads.com/lists/xen/devel/261025 and the hunk in question the following?
>> + get_gfn_query(d, pfn, &pt); 
>> + p2m_change_type(d, pfn, pt, p2m_ram_broken); 
>> + put_gfn(d, pfn); 
>> 
>> There really is no way to get rid of that p2m lock-protected critical
>> section if the domain allows for paging etc. You might want to
>> introduce a syntactically cleaner unconditional p2m_change_type
>> variant that doesn't cmpxchg with the previous type -- that is
>> effectively what goes on here. Should be a tiny amount of refactoring
>> and the code will be cleaner, no need for query or put.
> 
> I don't think that change-type is even what's wanted here.  You want to
> use some more raw form of set_p2m_entry(), since keeping the MFN is not
> important.  How about:
> 
> guest_physmap_add_entry(d, pfn, MFN_INVALID, p2m_ram_broken);
> 
Has the side effect of leaking the current mfn (if any) in the p2m entry for the remainder of the lifetime of the domain.

Digression: is this something we want to just go ahead and fix? Or is that semantic intended?

> ?
> 
>>> 
>>> True, but it wouldn't be safe to call it with the paging lock held.
>>> OTOH since we're not seeing any crashes from the lock-ordering
>>> constraints maybe we don't do that.
>>> 
>>> Andres, what do you think?  Can we just drop/amend that comment?
>>> 
>> 
>> If you refer to removing the ordering constraints
> 
> Noooooooooooooo! :)
> 
> I think we should drop the comment that says it's OK to call
> get_gfn_query() with the paging lock held (and audit to check that we
> don't do that anywhere).

Good, same page then, phew
Andres

> 
> Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 17:05:28 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 17:05:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTbj4-0007Vb-8K; Wed, 31 Oct 2012 17:05:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTbj3-0007VI-0P
	for xen-devel@lists.xen.org; Wed, 31 Oct 2012 17:05:09 +0000
Received: from [85.158.139.211:60219] by server-11.bemta-5.messagelabs.com id
	8D/96-14870-44A51905; Wed, 31 Oct 2012 17:05:08 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-8.tower-206.messagelabs.com!1351703106!18349030!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2671 invoked from network); 31 Oct 2012 17:05:07 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Oct 2012 17:05:07 -0000
Received: by mail-ie0-f173.google.com with SMTP id 17so3025543iea.32
	for ; Wed, 31 Oct 2012 10:05:05 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=content-type:mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=pmiEPJl+/aD2NCEn/uezrLlFHzSodT001TYszDIpcr8=;
	b=nrYUWHDHYMlVz+MqheDG5CzTDyvx/mhFRaYbq6GpTRcHASqEfkO2zAed1eiVruQ3/R
	Cl+r3uNZwTC3BeC3nw1fAYLsJqi/PdwoUbjamKkbGd5HijxXL2U6YlLZCqK4i8qMDLSm
	YSQJL4vk6CcQ1TJzTf8wiN5d53Ko96MSfMon/yaecfAy5NzMfuPvMlcutvHaeEw16gKK
	ILbu+XONLMJ8Lp5tlZzZBupMTBnfIUZ9K/3vF5ihdUoKy9YgCk3V+6/XJMsQxaywAnzS
	mQ2fzkbnd4UEIsnLJMkTQQhkDnMLs3FXNnsNR8bclGKk4vFMbHowLuVruIKtHMxf2M5q
	G4eQ==
Received: by 10.50.140.104 with SMTP id rf8mr1871682igb.40.1351703105747;
	Wed, 31 Oct 2012 10:05:05 -0700 (PDT)
Received: from andress-macbook.gridcentric.ca ([206.223.182.18])
	by mx.google.com with ESMTPS id y10sm10869704igc.13.2012.10.31.10.05.03
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 31 Oct 2012 10:05:04 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Andres Lagar-Cavilla 
In-Reply-To: <508FFBC202000078000A57DF@nat28.tlf.novell.com>
Date: Wed, 31 Oct 2012 13:05:05 -0400
Message-Id: 
References: <508FAA9402000078000A5612@nat28.tlf.novell.com>
	<20121030093626.GB34613@ocelot.phlegethon.org>
	<4E449D48-D643-46FB-91BD-B15EF21AAC57@gridcentric.ca>
	<508FFBC202000078000A57DF@nat28.tlf.novell.com>
To: Jan Beulich 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQmBydxHDe3m4SmdiSL+wHS7E9PI83CnzT6WbVHrXOT810+U32fhvCYFnL0uwB63JIMSgdLQ
Cc: Tim Deegan , Andres Lagar-Cavilla ,
	xen-devel 
Subject: Re: [Xen-devel] get_gfn_query() locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Oct 30, 2012, at 11:09 AM, Jan Beulich  wrote:

>>>> On 30.10.12 at 15:53, Andres Lagar-Cavilla  wrote:
>> On Oct 30, 2012, at 5:36 AM, Tim Deegan  wrote:
>> I say this because a similar interlock may apply for vMCE? Is there an 
>> expectation for a domain with vMCE turned on to be "land-locked" memory-wise?
> 
> I don't think there's any dependency here, vMCE should be
> transparent in that respect.
> 
>>>> And then again, with the p2m lock being recursive these
>>>> days, I don't think there's any harm calling the other methods
>>>> here with that lock held.
>> 
>> Is the patch you refer to 
>> http://www.gossamer-threads.com/lists/xen/devel/261025 and the hunk in 
>> question the following?
>> + get_gfn_query(d, pfn, &pt); 
>> + p2m_change_type(d, pfn, pt, p2m_ram_broken); 
>> + put_gfn(d, pfn); 
> 
> Yes.
> 
>> There really is no way to get rid of that p2m lock-protected critical section 
>> if the domain allows for paging etc.
> 
> I wasn't questioning the locking here. It was merely that code (and
> the lack of error handling therein) that made me look at the definition
> of the used p2m constructs.

Remind if I don't get around to adding this to a cleanup

Andres

> 
>> You might want to introduce a 
>> syntactically cleaner unconditional p2m_change_type variant that doesn't 
>> cmpxchg with the previous type -- that is effectively what goes on here. Should 
>> be a tiny amount of refactoring and the code will be cleaner, no need for 
>> query or put.
> 
> That might help here, yes.
> 
> Jan
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 17:05:28 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 17:05:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTbj4-0007Vb-8K; Wed, 31 Oct 2012 17:05:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTbj3-0007VI-0P
	for xen-devel@lists.xen.org; Wed, 31 Oct 2012 17:05:09 +0000
Received: from [85.158.139.211:60219] by server-11.bemta-5.messagelabs.com id
	8D/96-14870-44A51905; Wed, 31 Oct 2012 17:05:08 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-8.tower-206.messagelabs.com!1351703106!18349030!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2671 invoked from network); 31 Oct 2012 17:05:07 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Oct 2012 17:05:07 -0000
Received: by mail-ie0-f173.google.com with SMTP id 17so3025543iea.32
	for ; Wed, 31 Oct 2012 10:05:05 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=content-type:mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=pmiEPJl+/aD2NCEn/uezrLlFHzSodT001TYszDIpcr8=;
	b=nrYUWHDHYMlVz+MqheDG5CzTDyvx/mhFRaYbq6GpTRcHASqEfkO2zAed1eiVruQ3/R
	Cl+r3uNZwTC3BeC3nw1fAYLsJqi/PdwoUbjamKkbGd5HijxXL2U6YlLZCqK4i8qMDLSm
	YSQJL4vk6CcQ1TJzTf8wiN5d53Ko96MSfMon/yaecfAy5NzMfuPvMlcutvHaeEw16gKK
	ILbu+XONLMJ8Lp5tlZzZBupMTBnfIUZ9K/3vF5ihdUoKy9YgCk3V+6/XJMsQxaywAnzS
	mQ2fzkbnd4UEIsnLJMkTQQhkDnMLs3FXNnsNR8bclGKk4vFMbHowLuVruIKtHMxf2M5q
	G4eQ==
Received: by 10.50.140.104 with SMTP id rf8mr1871682igb.40.1351703105747;
	Wed, 31 Oct 2012 10:05:05 -0700 (PDT)
Received: from andress-macbook.gridcentric.ca ([206.223.182.18])
	by mx.google.com with ESMTPS id y10sm10869704igc.13.2012.10.31.10.05.03
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 31 Oct 2012 10:05:04 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Andres Lagar-Cavilla 
In-Reply-To: <508FFBC202000078000A57DF@nat28.tlf.novell.com>
Date: Wed, 31 Oct 2012 13:05:05 -0400
Message-Id: 
References: <508FAA9402000078000A5612@nat28.tlf.novell.com>
	<20121030093626.GB34613@ocelot.phlegethon.org>
	<4E449D48-D643-46FB-91BD-B15EF21AAC57@gridcentric.ca>
	<508FFBC202000078000A57DF@nat28.tlf.novell.com>
To: Jan Beulich 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQmBydxHDe3m4SmdiSL+wHS7E9PI83CnzT6WbVHrXOT810+U32fhvCYFnL0uwB63JIMSgdLQ
Cc: Tim Deegan , Andres Lagar-Cavilla ,
	xen-devel 
Subject: Re: [Xen-devel] get_gfn_query() locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Oct 30, 2012, at 11:09 AM, Jan Beulich  wrote:

>>>> On 30.10.12 at 15:53, Andres Lagar-Cavilla  wrote:
>> On Oct 30, 2012, at 5:36 AM, Tim Deegan  wrote:
>> I say this because a similar interlock may apply for vMCE? Is there an 
>> expectation for a domain with vMCE turned on to be "land-locked" memory-wise?
> 
> I don't think there's any dependency here, vMCE should be
> transparent in that respect.
> 
>>>> And then again, with the p2m lock being recursive these
>>>> days, I don't think there's any harm calling the other methods
>>>> here with that lock held.
>> 
>> Is the patch you refer to 
>> http://www.gossamer-threads.com/lists/xen/devel/261025 and the hunk in 
>> question the following?
>> + get_gfn_query(d, pfn, &pt); 
>> + p2m_change_type(d, pfn, pt, p2m_ram_broken); 
>> + put_gfn(d, pfn); 
> 
> Yes.
> 
>> There really is no way to get rid of that p2m lock-protected critical section 
>> if the domain allows for paging etc.
> 
> I wasn't questioning the locking here. It was merely that code (and
> the lack of error handling therein) that made me look at the definition
> of the used p2m constructs.

Remind if I don't get around to adding this to a cleanup

Andres

> 
>> You might want to introduce a 
>> syntactically cleaner unconditional p2m_change_type variant that doesn't 
>> cmpxchg with the previous type -- that is effectively what goes on here. Should 
>> be a tiny amount of refactoring and the code will be cleaner, no need for 
>> query or put.
> 
> That might help here, yes.
> 
> Jan
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 17:08:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 17:08:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTblo-0007lV-WD; Wed, 31 Oct 2012 17:08:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TTblo-0007lI-5K
	for xen-devel@lists.xen.org; Wed, 31 Oct 2012 17:08:00 +0000
Received: from [85.158.138.51:42003] by server-13.bemta-3.messagelabs.com id
	2B/D3-24887-FEA51905; Wed, 31 Oct 2012 17:07:59 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-174.messagelabs.com!1351703278!20233606!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21566 invoked from network); 31 Oct 2012 17:07:58 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 31 Oct 2012 17:07:58 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TTblh-000DbX-RY; Wed, 31 Oct 2012 17:07:53 +0000
Date: Wed, 31 Oct 2012 17:07:53 +0000
From: Tim Deegan 
To: Andres Lagar-Cavilla 
Message-ID: <20121031170753.GE34613@ocelot.phlegethon.org>
References: <508FAA9402000078000A5612@nat28.tlf.novell.com>
	<20121030093626.GB34613@ocelot.phlegethon.org>
	<4E449D48-D643-46FB-91BD-B15EF21AAC57@gridcentric.ca>
	<20121030150612.GC34613@ocelot.phlegethon.org>
	<8CED7AA4-7C18-488E-8CA0-918254EDA444@gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <8CED7AA4-7C18-488E-8CA0-918254EDA444@gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: Andres Lagar-Cavilla ,
	Jan Beulich , xen-devel 
Subject: Re: [Xen-devel] get_gfn_query() locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 13:04 -0400 on 31 Oct (1351688673), Andres Lagar-Cavilla wrote:
> On Oct 30, 2012, at 11:06 AM, Tim Deegan  wrote:
> 
> > At 10:53 -0400 on 30 Oct (1351594401), Andres Lagar-Cavilla wrote:
> >>>> And then again, with the p2m lock being recursive these
> >>>> days, I don't think there's any harm calling the other methods
> >>>> here with that lock held.
> >> 
> >> Is the patch you refer to http://www.gossamer-threads.com/lists/xen/devel/261025 and the hunk in question the following?
> >> + get_gfn_query(d, pfn, &pt); 
> >> + p2m_change_type(d, pfn, pt, p2m_ram_broken); 
> >> + put_gfn(d, pfn); 
> >> 
> >> There really is no way to get rid of that p2m lock-protected critical
> >> section if the domain allows for paging etc. You might want to
> >> introduce a syntactically cleaner unconditional p2m_change_type
> >> variant that doesn't cmpxchg with the previous type -- that is
> >> effectively what goes on here. Should be a tiny amount of refactoring
> >> and the code will be cleaner, no need for query or put.
> > 
> > I don't think that change-type is even what's wanted here.  You want to
> > use some more raw form of set_p2m_entry(), since keeping the MFN is not
> > important.  How about:
> > 
> > guest_physmap_add_entry(d, pfn, MFN_INVALID, p2m_ram_broken);
> > 
> Has the side effect of leaking the current mfn (if any) in the p2m entry for the remainder of the lifetime of the domain.
> 

Since this call is made whren the underlying MFN is broken and must
never be touched, that's actually a good thing. :)

> Digression: is this something we want to just go ahead and fix? Or is
> that semantic intended?

The xenmem_add_to_physmap() code is basically a wrapper around this that
DTRT with the thing that was there before.  It Would Be Nice to audit
all the various users of that code an make them consistent, though.
Goes on the list...

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 17:08:16 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 17:08:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTblo-0007lV-WD; Wed, 31 Oct 2012 17:08:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from )
	id 1TTblo-0007lI-5K
	for xen-devel@lists.xen.org; Wed, 31 Oct 2012 17:08:00 +0000
Received: from [85.158.138.51:42003] by server-13.bemta-3.messagelabs.com id
	2B/D3-24887-FEA51905; Wed, 31 Oct 2012 17:07:59 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-174.messagelabs.com!1351703278!20233606!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21566 invoked from network); 31 Oct 2012 17:07:58 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 31 Oct 2012 17:07:58 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from )
	id 1TTblh-000DbX-RY; Wed, 31 Oct 2012 17:07:53 +0000
Date: Wed, 31 Oct 2012 17:07:53 +0000
From: Tim Deegan 
To: Andres Lagar-Cavilla 
Message-ID: <20121031170753.GE34613@ocelot.phlegethon.org>
References: <508FAA9402000078000A5612@nat28.tlf.novell.com>
	<20121030093626.GB34613@ocelot.phlegethon.org>
	<4E449D48-D643-46FB-91BD-B15EF21AAC57@gridcentric.ca>
	<20121030150612.GC34613@ocelot.phlegethon.org>
	<8CED7AA4-7C18-488E-8CA0-918254EDA444@gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <8CED7AA4-7C18-488E-8CA0-918254EDA444@gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: Andres Lagar-Cavilla ,
	Jan Beulich , xen-devel 
Subject: Re: [Xen-devel] get_gfn_query() locking
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 13:04 -0400 on 31 Oct (1351688673), Andres Lagar-Cavilla wrote:
> On Oct 30, 2012, at 11:06 AM, Tim Deegan  wrote:
> 
> > At 10:53 -0400 on 30 Oct (1351594401), Andres Lagar-Cavilla wrote:
> >>>> And then again, with the p2m lock being recursive these
> >>>> days, I don't think there's any harm calling the other methods
> >>>> here with that lock held.
> >> 
> >> Is the patch you refer to http://www.gossamer-threads.com/lists/xen/devel/261025 and the hunk in question the following?
> >> + get_gfn_query(d, pfn, &pt); 
> >> + p2m_change_type(d, pfn, pt, p2m_ram_broken); 
> >> + put_gfn(d, pfn); 
> >> 
> >> There really is no way to get rid of that p2m lock-protected critical
> >> section if the domain allows for paging etc. You might want to
> >> introduce a syntactically cleaner unconditional p2m_change_type
> >> variant that doesn't cmpxchg with the previous type -- that is
> >> effectively what goes on here. Should be a tiny amount of refactoring
> >> and the code will be cleaner, no need for query or put.
> > 
> > I don't think that change-type is even what's wanted here.  You want to
> > use some more raw form of set_p2m_entry(), since keeping the MFN is not
> > important.  How about:
> > 
> > guest_physmap_add_entry(d, pfn, MFN_INVALID, p2m_ram_broken);
> > 
> Has the side effect of leaking the current mfn (if any) in the p2m entry for the remainder of the lifetime of the domain.
> 

Since this call is made whren the underlying MFN is broken and must
never be touched, that's actually a good thing. :)

> Digression: is this something we want to just go ahead and fix? Or is
> that semantic intended?

The xenmem_add_to_physmap() code is basically a wrapper around this that
DTRT with the thing that was there before.  It Would Be Nice to audit
all the various users of that code an make them consistent, though.
Goes on the list...

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 17:55:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 17:55:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTcVR-0000dN-B0; Wed, 31 Oct 2012 17:55:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTcVP-0000dI-Dy
	for xen-devel@lists.xensource.com; Wed, 31 Oct 2012 17:55:07 +0000
Received: from [85.158.143.99:4208] by server-2.bemta-4.messagelabs.com id
	53/9E-28922-AF561905; Wed, 31 Oct 2012 17:55:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1351706105!22810640!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY2MTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25031 invoked from network); 31 Oct 2012 17:55:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Oct 2012 17:55:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,687,1344211200"; d="scan'208";a="15521444"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Oct 2012 17:54:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 31 Oct 2012 17:54:04 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TTcUO-00040a-VZ;
	Wed, 31 Oct 2012 17:54:05 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TTcUO-0004yZ-VD;
	Wed, 31 Oct 2012 17:54:04 +0000
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Wed, 31 Oct 2012 17:54:04 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 14192: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14192 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14192/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl             9 guest-start               fail REGR. vs. 14076
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 14076
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 14076
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 14076

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10      fail pass in 14186

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore         fail REGR. vs. 14076

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  2bca7e58a3df
baseline version:
 xen                  40ccbee890e1

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla 
  Bastian Blank 
  Chuang Cao 
  George Dunlap 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jason McCarver 
  Joe Jin 
  Keir Fraser 
  Matt Wilson 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Sander Eikelenboom 
  Stefano Stabellini 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 632 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 17:55:32 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 17:55:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTcVR-0000dN-B0; Wed, 31 Oct 2012 17:55:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTcVP-0000dI-Dy
	for xen-devel@lists.xensource.com; Wed, 31 Oct 2012 17:55:07 +0000
Received: from [85.158.143.99:4208] by server-2.bemta-4.messagelabs.com id
	53/9E-28922-AF561905; Wed, 31 Oct 2012 17:55:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1351706105!22810640!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY2MTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25031 invoked from network); 31 Oct 2012 17:55:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Oct 2012 17:55:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,687,1344211200"; d="scan'208";a="15521444"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Oct 2012 17:54:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 31 Oct 2012 17:54:04 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TTcUO-00040a-VZ;
	Wed, 31 Oct 2012 17:54:05 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TTcUO-0004yZ-VD;
	Wed, 31 Oct 2012 17:54:04 +0000
To: xen-devel@lists.xensource.com
Message-ID: 
From: xen.org 
Date: Wed, 31 Oct 2012 17:54:04 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 14192: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14192 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14192/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl             9 guest-start               fail REGR. vs. 14076
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install       fail REGR. vs. 14076
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 14076
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 14076

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10      fail pass in 14186

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore         fail REGR. vs. 14076

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  2bca7e58a3df
baseline version:
 xen                  40ccbee890e1

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla 
  Bastian Blank 
  Chuang Cao 
  George Dunlap 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jason McCarver 
  Joe Jin 
  Keir Fraser 
  Matt Wilson 
  Matthew Fioravante 
  Olaf Hering 
  Roger Pau Monne 
  Sander Eikelenboom 
  Stefano Stabellini 
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 632 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 19:12:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 19:12:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTdht-0002Jv-Ps; Wed, 31 Oct 2012 19:12:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTdhs-0002Jl-8q; Wed, 31 Oct 2012 19:12:05 +0000
Received: from [85.158.137.99:17234] by server-8.bemta-3.messagelabs.com id
	E5/91-07786-30871905; Wed, 31 Oct 2012 19:12:03 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1351710722!12417362!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24744 invoked from network); 31 Oct 2012 19:12:02 -0000
Received: from mail-ea0-f173.google.com (HELO mail-ea0-f173.google.com)
	(209.85.215.173)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Oct 2012 19:12:02 -0000
Received: by mail-ea0-f173.google.com with SMTP id a1so844059eaa.32
	for ; Wed, 31 Oct 2012 12:12:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:subject:from:to:cc:date:in-reply-to:references
	:content-type:x-mailer:mime-version;
	bh=rXXqa9vWZam4QqVtrqNn1mX1spmnVZpC+yUrmcipg08=;
	b=RNmTSlLkKyrveycn6CBcfBwzK+cMkPy1a9GKEF607hXA62OJ2ARrYFG4HJeq6iWJQA
	+BzWVIt+mlqdduFwrWd1cjNp5r+cHJEf3io+jA1ofXsGW5yEDrBrAMmlO1mWV7R11h5s
	XQlcf5g53cf25lHwp2g1jsvlKIbYn9va2f845cG6xjgFuTkKRuAsTIOGT6/qZZPji7ud
	vNxTLNrzHyWw6hcZcde6kgJ6rr6BDN/5lP6Inzsf3PHpe8dPpXuAWJCHkD2acdtlgrnN
	3FyuQr42YwszpFv91Sf2iOPuWRXdQ6BBy3SBiEJvXthZzXw7fqwL6xNdjdYshLEotF0O
	eprw==
Received: by 10.14.205.3 with SMTP id i3mr88400139eeo.18.1351710722269;
	Wed, 31 Oct 2012 12:12:02 -0700 (PDT)
Received: from [192.168.0.40] (ip-143-31.sn3.eutelia.it. [213.136.143.31])
	by mx.google.com with ESMTPS id g5sm9614651eem.4.2012.10.31.12.12.00
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 31 Oct 2012 12:12:01 -0700 (PDT)
Message-ID: <1351710714.18330.125.camel@Solace>
From: Dario Faggioli 
To: xen@lists.fedoraproject.org
Date: Wed, 31 Oct 2012 20:11:54 +0100
In-Reply-To: <1351607757.1346.32.camel@Abyss>
References: <1351607757.1346.32.camel@Abyss>
X-Mailer: Evolution 3.4.4-1
Mime-Version: 1.0
Cc: "xen-users@lists.xen.org" ,
	"konrad.r.wilk" ,
	xen-devel 
Subject: Re: [Xen-devel] [Fedora-xen] Call for Participation to the Fedora
	Virt Test Day
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============2130106695794710969=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============2130106695794710969==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-70HU0K3Gtqu5rhw5ELfV"


--=-70HU0K3Gtqu5rhw5ELfV
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2012-10-30 at 15:35 +0100, Dario Faggioli wrote:
> Specific information regarding testing Xen
> on Fedora can be found in this Wiki page:
>=20
>   http://wiki.xen.org/wiki/Fedora_Test_Days
>=20
And let me just add that we also have a Fedora-Xen LiveCD.

I just finished cooking it, tested it, and it seems to be working!

If you decide to try it, it will bring you into a Fedora 18 Beta TC6
Dom0, with Xen 4.2.0 as hypervisor (as per F18 updates-testing
repository).

I'm putting it here [*]:
 http://xenbits.xen.org/people/dariof/Live/Fedora/Virt-TestDay-Xen.iso

Go download it and enjoy being able to start creating VMs with Xen on
Fedora without the need to install anything!!

Feel free to report to me (dario.faggioli@citrix.com) anything you think
could be related to the LiveCD itself (rather than other kind of bugs,
that you should report to the proper mailing-lists :-D).

Regards,
Dario

[*] Just don't go there right now... Give it a couple of hours from the
time I'm sending this e-mail. I'm uploading it there with my residential
ADSL, which is quite of slow in that direction. :-(

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-70HU0K3Gtqu5rhw5ELfV
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlCRd/oACgkQk4XaBE3IOsTW3gCeIeCwvQZooNdrJpSSUmjy1Pj0
mPUAnjjdisjE5f33+YichV3MM6k1uRCY
=g8Ah
-----END PGP SIGNATURE-----

--=-70HU0K3Gtqu5rhw5ELfV--



--===============2130106695794710969==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2130106695794710969==--



From xen-devel-bounces@lists.xen.org Wed Oct 31 19:12:31 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 19:12:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTdht-0002Jv-Ps; Wed, 31 Oct 2012 19:12:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTdhs-0002Jl-8q; Wed, 31 Oct 2012 19:12:05 +0000
Received: from [85.158.137.99:17234] by server-8.bemta-3.messagelabs.com id
	E5/91-07786-30871905; Wed, 31 Oct 2012 19:12:03 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1351710722!12417362!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24744 invoked from network); 31 Oct 2012 19:12:02 -0000
Received: from mail-ea0-f173.google.com (HELO mail-ea0-f173.google.com)
	(209.85.215.173)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Oct 2012 19:12:02 -0000
Received: by mail-ea0-f173.google.com with SMTP id a1so844059eaa.32
	for ; Wed, 31 Oct 2012 12:12:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:subject:from:to:cc:date:in-reply-to:references
	:content-type:x-mailer:mime-version;
	bh=rXXqa9vWZam4QqVtrqNn1mX1spmnVZpC+yUrmcipg08=;
	b=RNmTSlLkKyrveycn6CBcfBwzK+cMkPy1a9GKEF607hXA62OJ2ARrYFG4HJeq6iWJQA
	+BzWVIt+mlqdduFwrWd1cjNp5r+cHJEf3io+jA1ofXsGW5yEDrBrAMmlO1mWV7R11h5s
	XQlcf5g53cf25lHwp2g1jsvlKIbYn9va2f845cG6xjgFuTkKRuAsTIOGT6/qZZPji7ud
	vNxTLNrzHyWw6hcZcde6kgJ6rr6BDN/5lP6Inzsf3PHpe8dPpXuAWJCHkD2acdtlgrnN
	3FyuQr42YwszpFv91Sf2iOPuWRXdQ6BBy3SBiEJvXthZzXw7fqwL6xNdjdYshLEotF0O
	eprw==
Received: by 10.14.205.3 with SMTP id i3mr88400139eeo.18.1351710722269;
	Wed, 31 Oct 2012 12:12:02 -0700 (PDT)
Received: from [192.168.0.40] (ip-143-31.sn3.eutelia.it. [213.136.143.31])
	by mx.google.com with ESMTPS id g5sm9614651eem.4.2012.10.31.12.12.00
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 31 Oct 2012 12:12:01 -0700 (PDT)
Message-ID: <1351710714.18330.125.camel@Solace>
From: Dario Faggioli 
To: xen@lists.fedoraproject.org
Date: Wed, 31 Oct 2012 20:11:54 +0100
In-Reply-To: <1351607757.1346.32.camel@Abyss>
References: <1351607757.1346.32.camel@Abyss>
X-Mailer: Evolution 3.4.4-1
Mime-Version: 1.0
Cc: "xen-users@lists.xen.org" ,
	"konrad.r.wilk" ,
	xen-devel 
Subject: Re: [Xen-devel] [Fedora-xen] Call for Participation to the Fedora
	Virt Test Day
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============2130106695794710969=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============2130106695794710969==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-70HU0K3Gtqu5rhw5ELfV"


--=-70HU0K3Gtqu5rhw5ELfV
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2012-10-30 at 15:35 +0100, Dario Faggioli wrote:
> Specific information regarding testing Xen
> on Fedora can be found in this Wiki page:
>=20
>   http://wiki.xen.org/wiki/Fedora_Test_Days
>=20
And let me just add that we also have a Fedora-Xen LiveCD.

I just finished cooking it, tested it, and it seems to be working!

If you decide to try it, it will bring you into a Fedora 18 Beta TC6
Dom0, with Xen 4.2.0 as hypervisor (as per F18 updates-testing
repository).

I'm putting it here [*]:
 http://xenbits.xen.org/people/dariof/Live/Fedora/Virt-TestDay-Xen.iso

Go download it and enjoy being able to start creating VMs with Xen on
Fedora without the need to install anything!!

Feel free to report to me (dario.faggioli@citrix.com) anything you think
could be related to the LiveCD itself (rather than other kind of bugs,
that you should report to the proper mailing-lists :-D).

Regards,
Dario

[*] Just don't go there right now... Give it a couple of hours from the
time I'm sending this e-mail. I'm uploading it there with my residential
ADSL, which is quite of slow in that direction. :-(

--=20
<> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-70HU0K3Gtqu5rhw5ELfV
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlCRd/oACgkQk4XaBE3IOsTW3gCeIeCwvQZooNdrJpSSUmjy1Pj0
mPUAnjjdisjE5f33+YichV3MM6k1uRCY
=g8Ah
-----END PGP SIGNATURE-----

--=-70HU0K3Gtqu5rhw5ELfV--



--===============2130106695794710969==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2130106695794710969==--



From xen-devel-bounces@lists.xen.org Wed Oct 31 19:38:13 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 19:38:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTe6k-0003Ft-Bs; Wed, 31 Oct 2012 19:37:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTe6j-0003Fo-48
	for xen-devel@lists.xensource.com; Wed, 31 Oct 2012 19:37:45 +0000
Received: from [85.158.138.51:44235] by server-9.bemta-3.messagelabs.com id
	DF/CA-02388-80E71905; Wed, 31 Oct 2012 19:37:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1351712263!20248271!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY2MTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21836 invoked from network); 31 Oct 2012 19:37:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Oct 2012 19:37:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,687,1344211200"; d="scan'208";a="15522889"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Oct 2012 19:37:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 31 Oct 2012 19:37:42 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TTe6g-0004v5-8k;
	Wed, 31 Oct 2012 19:37:42 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TTe6f-0007Q2-WF;
	Wed, 31 Oct 2012 19:37:42 +0000
To: 
Message-ID: 
From: xen.org 
Date: Wed, 31 Oct 2012 19:37:42 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 14199: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14199 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14199/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 14073
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 14073
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 14073
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 14073

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 linux                d9ee258b13506301b6da6450cf7a1692826b471e
baseline version:
 linux                9fc71703e9baa5b5174a72c053ae1ca736df2d42

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=linux-3.0
+ revision=d9ee258b13506301b6da6450cf7a1692826b471e
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push linux-3.0 d9ee258b13506301b6da6450cf7a1692826b471e
+ branch=linux-3.0
+ revision=d9ee258b13506301b6da6450cf7a1692826b471e
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=linux
+ xenbranch=xen-unstable
+ '[' xlinux = xlinux ']'
+ linuxbranch=linux-3.0
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.linux-3.0
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux-3.0
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree linux-3.0
+ case $1 in
+ : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
+ : linux-3.0.y
+ : linux-3.0.y
+ : git
+ : git
+ : git://xenbits.xen.org/linux-pvops.git
+ : xen@xenbits.xensource.com:git/linux-pvops.git
+ : tested/linux-3.0
+ : tested/linux-3.0
+ return 0
+ cd /export/home/osstest/repos/linux
+ git push xen@xenbits.xensource.com:git/linux-pvops.git d9ee258b13506301b6da6450cf7a1692826b471e:tested/linux-3.0
Counting objects: 1   
Counting objects: 132   
Counting objects: 251, done.
Compressing objects:   3% (1/33)   
Compressing objects:   6% (2/33)   
Compressing objects:   9% (3/33)   
Compressing objects:  12% (4/33)   
Compressing objects:  15% (5/33)   
Compressing objects:  18% (6/33)   
Compressing objects:  21% (7/33)   
Compressing objects:  24% (8/33)   
Compressing objects:  27% (9/33)   
Compressing objects:  30% (10/33)   
Compressing objects:  33% (11/33)   
Compressing objects:  36% (12/33)   
Compressing objects:  39% (13/33)   
Compressing objects:  42% (14/33)   
Compressing objects:  45% (15/33)   
Compressing objects:  48% (16/33)   
Compressing objects:  51% (17/33)   
Compressing objects:  54% (18/33)   
Compressing objects:  57% (19/33)   
Compressing objects:  60% (20/33)   
Compressing objects:  63% (21/33)   
Compressing objects:  66% (22/33)   
Compressing objects:  69% (23/33)   
Compressing objects:  72% (24/33)   
Compressing objects:  75% (25/33)   
Compressing objects:  78% (26/33)   
Compressing objects:  81% (27/33)   
Compressing objects:  84% (28/33)   
Compressing objects:  87% (29/33)   
Compressing objects:  90% (30/33)   
Compressing objects:  93% (31/33)   
Compressing objects:  96% (32/33)   
Compressing objects: 100% (33/33)   
Compressing objects: 100% (33/33), done.
Writing objects:   0% (1/187)   
Writing objects:   1% (2/187)   
Writing objects:   2% (4/187)   
Writing objects:   3% (6/187)   
Writing objects:   4% (8/187)   
Writing objects:   5% (10/187)   
Writing objects:   6% (12/187)   
Writing objects:   7% (14/187)   
Writing objects:   8% (15/187)   
Writing objects:   9% (17/187)   
Writing objects:  10% (19/187)   
Writing objects:  11% (21/187)   
Writing objects:  12% (23/187)   
Writing objects:  13% (25/187)   
Writing objects:  14% (27/187)   
Writing objects:  15% (29/187)   
Writing objects:  16% (30/187)   
Writing objects:  17% (32/187)   
Writing objects:  18% (34/187)   
Writing objects:  19% (36/187)   
Writing objects:  20% (38/187)   
Writing objects:  21% (40/187)   
Writing objects:  22% (42/187)   
Writing objects:  23% (44/187)   
Writing objects:  24% (45/187)   
Writing objects:  25% (47/187)   
Writing objects:  26% (49/187)   
Writing objects:  27% (51/187)   
Writing objects:  28% (53/187)   
Writing objects:  29% (55/187)   
Writing objects:  30% (57/187)   
Writing objects:  31% (58/187)   
Writing objects:  32% (60/187)   
Writing objects:  33% (62/187)   
Writing objects:  34% (64/187)   
Writing objects:  35% (66/187)   
Writing objects:  36% (68/187)   
Writing objects:  37% (70/187)   
Writing objects:  38% (72/187)   
Writing objects:  39% (73/187)   
Writing objects:  40% (75/187)   
Writing objects:  41% (77/187)   
Writing objects:  42% (79/187)   
Writing objects:  43% (81/187)   
Writing objects:  44% (83/187)   
Writing objects:  45% (86/187)   
Writing objects:  46% (87/187)   
Writing objects:  47% (88/187)   
Writing objects:  48% (90/187)   
Writing objects:  49% (92/187)   
Writing objects:  50% (94/187)   
Writing objects:  51% (96/187)   
Writing objects:  52% (98/187)   
Writing objects:  53% (100/187)   
Writing objects:  54% (101/187)   
Writing objects:  55% (103/187)   
Writing objects:  56% (105/187)   
Writing objects:  57% (107/187)   
Writing objects:  58% (110/187)   
Writing objects:  59% (111/187)   
Writing objects:  60% (113/187)   
Writing objects:  61% (115/187)   
Writing objects:  62% (116/187)   
Writing objects:  63% (118/187)   
Writing objects:  64% (120/187)   
Writing objects:  65% (122/187)   
Writing objects:  66% (124/187)   
Writing objects:  67% (126/187)   
Writing objects:  68% (128/187)   
Writing objects:  69% (130/187)   
Writing objects:  70% (131/187)   
Writing objects:  71% (133/187)   
Writing objects:  72% (135/187)   
Writing objects:  73% (137/187)   
Writing objects:  74% (139/187)   
Writing objects:  75% (141/187)   
Writing objects:  76% (143/187)   
Writing objects:  77% (144/187)   
Writing objects:  78% (146/187)   
Writing objects:  79% (148/187)   
Writing objects:  80% (150/187)   
Writing objects:  81% (152/187)   
Writing objects:  82% (154/187)   
Writing objects:  83% (156/187)   
Writing objects:  84% (158/187)   
Writing objects:  85% (159/187)   
Writing objects:  86% (161/187)   
Writing objects:  87% (163/187)   
Writing objects:  88% (165/187)   
Writing objects:  89% (167/187)   
Writing objects:  90% (169/187)   
Writing objects:  91% (171/187)   
Writing objects:  92% (173/187)   
Writing objects:  93% (174/187)   
Writing objects:  94% (176/187)   
Writing objects:  95% (178/187)   
Writing objects:  96% (180/187)   
Writing objects:  97% (182/187)   
Writing objects:  98% (184/187)   
Writing objects:  99% (186/187)   
Writing objects: 100% (187/187)   
Writing objects: 100% (187/187), 34.42 KiB, done.
Total 187 (delta 154), reused 187 (delta 154)
To xen@xenbits.xensource.com:git/linux-pvops.git
   9fc7170..d9ee258  d9ee258b13506301b6da6450cf7a1692826b471e -> tested/linux-3.0
+ exit 0

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Oct 31 19:38:13 2012
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 31 Oct 2012 19:38:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from )
	id 1TTe6k-0003Ft-Bs; Wed, 31 Oct 2012 19:37:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from ) id 1TTe6j-0003Fo-48
	for xen-devel@lists.xensource.com; Wed, 31 Oct 2012 19:37:45 +0000
Received: from [85.158.138.51:44235] by server-9.bemta-3.messagelabs.com id
	DF/CA-02388-80E71905; Wed, 31 Oct 2012 19:37:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1351712263!20248271!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTY2MTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.8; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21836 invoked from network); 31 Oct 2012 19:37:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Oct 2012 19:37:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,687,1344211200"; d="scan'208";a="15522889"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Oct 2012 19:37:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 31 Oct 2012 19:37:42 +0000
Received: from [10.80.248.135] (helo=woking.cam.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	)	id 1TTe6g-0004v5-8k;
	Wed, 31 Oct 2012 19:37:42 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from )	id 1TTe6f-0007Q2-WF;
	Wed, 31 Oct 2012 19:37:42 +0000
To: 
Message-ID: 
From: xen.org 
Date: Wed, 31 Oct 2012 19:37:42 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 14199: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 14199 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14199/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 14073
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 14073
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 14073
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 14073

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 linux                d9ee258b13506301b6da6450cf7a1692826b471e
baseline version:
 linux                9fc71703e9baa5b5174a72c053ae1ca736df2d42

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=linux-3.0
+ revision=d9ee258b13506301b6da6450cf7a1692826b471e
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push linux-3.0 d9ee258b13506301b6da6450cf7a1692826b471e
+ branch=linux-3.0
+ revision=d9ee258b13506301b6da6450cf7a1692826b471e
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=linux
+ xenbranch=xen-unstable
+ '[' xlinux = xlinux ']'
+ linuxbranch=linux-3.0
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.linux-3.0
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux-3.0
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree linux-3.0
+ case $1 in
+ : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
+ : linux-3.0.y
+ : linux-3.0.y
+ : git
+ : git
+ : git://xenbits.xen.org/linux-pvops.git
+ : xen@xenbits.xensource.com:git/linux-pvops.git
+ : tested/linux-3.0
+ : tested/linux-3.0
+ return 0
+ cd /export/home/osstest/repos/linux
+ git push xen@xenbits.xensource.com:git/linux-pvops.git d9ee258b13506301b6da6450cf7a1692826b471e:tested/linux-3.0
Counting objects: 1   
Counting objects: 132   
Counting objects: 251, done.
Compressing objects:   3% (1/33)   
Compressing objects:   6% (2/33)   
Compressing objects:   9% (3/33)   
Compressing objects:  12% (4/33)   
Compressing objects:  15% (5/33)   
Compressing objects:  18% (6/33)   
Compressing objects:  21% (7/33)   
Compressing objects:  24% (8/33)   
Compressing objects:  27% (9/33)   
Compressing objects:  30% (10/33)   
Compressing objects:  33% (11/33)   
Compressing objects:  36% (12/33)   
Compressing objects:  39% (13/33)   
Compressing objects:  42% (14/33)   
Compressing objects:  45% (15/33)   
Compressing objects:  48% (16/33)   
Compressing objects:  51% (17/33)   
Compressing objects:  54% (18/33)   
Compressing objects:  57% (19/33)   
Compressing objects:  60% (20/33)   
Compressing objects:  63% (21/33)   
Compressing objects:  66% (22/33)   
Compressing objects:  69% (23/33)   
Compressing objects:  72% (24/33)   
Compressing objects:  75% (25/33)   
Compressing objects:  78% (26/33)   
Compressing objects:  81% (27/33)   
Compressing objects:  84% (28/33)   
Compressing objects:  87% (29/33)   
Compressing objects:  90% (30/33)   
Compressing objects:  93% (31/33)   
Compressing objects:  96% (32/33)   
Compressing objects: 100% (33/33)   
Compressing objects: 100% (33/33), done.
Writing objects:   0% (1/187)   
Writing objects:   1% (2/187)   
Writing objects:   2% (4/187)   
Writing objects:   3% (6/187)   
Writing objects:   4% (8/187)   
Writing objects:   5% (10/187)   
Writing objects:   6% (12/187)   
Writing objects:   7% (14/187)   
Writing objects:   8% (15/187)   
Writing objects:   9% (17/187)   
Writing objects:  10% (19/187)   
Writing objects:  11% (21/187)   
Writing objects:  12% (23/187)   
Writing objects:  13% (25/187)   
Writing objects:  14% (27/187)   
Writing objects:  15% (29/187)   
Writing objects:  16% (30/187)   
Writing objects:  17% (32/187)   
Writing objects:  18% (34/187)   
Writing objects:  19% (36/187)   
Writing objects:  20% (38/187)   
Writing objects:  21% (40/187)   
Writing objects:  22% (42/187)   
Writing objects:  23% (44/187)   
Writing objects:  24% (45/187)   
Writing objects:  25% (47/187)   
Writing objects:  26% (49/187)   
Writing objects:  27% (51/187)   
Writing objects:  28% (53/187)   
Writing objects:  29% (55/187)   
Writing objects:  30% (57/187)   
Writing objects:  31% (58/187)   
Writing objects:  32% (60/187)   
Writing objects:  33% (62/187)   
Writing objects:  34% (64/187)   
Writing objects:  35% (66/187)   
Writing objects:  36% (68/187)   
Writing objects:  37% (70/187)   
Writing objects:  38% (72/187)   
Writing objects:  39% (73/187)   
Writing objects:  40% (75/187)   
Writing objects:  41% (77/187)   
Writing objects:  42% (79/187)   
Writing objects:  43% (81/187)   
Writing objects:  44% (83/187)   
Writing objects:  45% (86/187)   
Writing objects:  46% (87/187)   
Writing objects:  47% (88/187)   
Writing objects:  48% (90/187)   
Writing objects:  49% (92/187)   
Writing objects:  50% (94/187)   
Writing objects:  51% (96/187)   
Writing objects:  52% (98/187)   
Writing objects:  53% (100/187)   
Writing objects:  54% (101/187)   
Writing objects:  55% (103/187)   
Writing objects:  56% (105/187)   
Writing objects:  57% (107/187)   
Writing objects:  58% (110/187)   
Writing objects:  59% (111/187)   
Writing objects:  60% (113/187)   
Writing objects:  61% (115/187)   
Writing objects:  62% (116/187)   
Writing objects:  63% (118/187)   
Writing objects:  64% (120/187)   
Writing objects:  65% (122/187)   
Writing objects:  66% (124/187)   
Writing objects:  67% (126/187)   
Writing objects:  68% (128/187)   
Writing objects:  69% (130/187)   
Writing objects:  70% (131/187)   
Writing objects:  71% (133/187)   
Writing objects:  72% (135/187)   
Writing objects:  73% (137/187)   
Writing objects:  74% (139/187)   
Writing objects:  75% (141/187)   
Writing objects:  76% (143/187)   
Writing objects:  77% (144/187)   
Writing objects:  78% (146/187)   
Writing objects:  79% (148/187)   
Writing objects:  80% (150/187)   
Writing objects:  81% (152/187)   
Writing objects:  82% (154/187)   
Writing objects:  83% (156/187)   
Writing objects:  84% (158/187)   
Writing objects:  85% (159/187)   
Writing objects:  86% (161/187)   
Writing objects:  87% (163/187)   
Writing objects:  88% (165/187)   
Writing objects:  89% (167/187)   
Writing objects:  90% (169/187)   
Writing objects:  91% (171/187)   
Writing objects:  92% (173/187)   
Writing objects:  93% (174/187)   
Writing objects:  94% (176/187)   
Writing objects:  95% (178/187)   
Writing objects:  96% (180/187)   
Writing objects:  97% (182/187)   
Writing objects:  98% (184/187)   
Writing objects:  99% (186/187)   
Writing objects: 100% (187/187)   
Writing objects: 100% (187/187), 34.42 KiB, done.
Total 187 (delta 154), reused 187 (delta 154)
To xen@xenbits.xensource.com:git/linux-pvops.git
   9fc7170..d9ee258  d9ee258b13506301b6da6450cf7a1692826b471e -> tested/linux-3.0
+ exit 0

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel